Temat: Co umieć, aby zrobić karierę?
Myślę, że dobrym przykładem do wątku głównego jest fragment z książki Getting Things Done Davida Allena
“W naszej pracy nie ma już klarownego zakresu obowiązków
Głównym czynnikiem wpływającym na rosnący poziom towarzyszącego nam stresu jest fakt, że charakter naszej pracy zmienił się w sposób bardziej zdecydowany i raptowny niż nasze wyszkolenie i umiejętności radzenia sobie z nowymi obowiązkami. Tylko w ciągu drugiej połowy dwudziestego wieku rozumienie “pracy” ukształtowane przez świat przemysłu zmieniło się z czynności wykonywanych przy linii produkcyjnej w systemie “wykonaj i przekaż dalej” na, jak to trafnie określi Peter Drucker, “pracę opartą na wiedzy.”
W minionych czasach praca była czymś oczywistym, przejrzystym. Pola miały być zaorane, maszyny obsłużone, pudła zapakowane, krowy wydojone a “wihajstry” przekręcone. Wiedziałeś, co należało zrobić – to było klarowne. Łatwo było ocenić, czy praca została wykonana, czy nie.
Dziś wielu z nas pracuje nad projektami, które nie mają określonych ram. Większość ludzi, których znam, zajmuje się aktualnie kilkoma sprawami jednocześnie, i choćby starali się do końca swoich dni, to nie uda im się perfekcyjnie zrealizować wszystkich z nich”
Odnosząc to do całej branży IT osobiście nie uznaje aby dało się ją opisać w zero jedynkowy sposób a chcąc rozmawiać w tym wątku trzeba uszczegółowić gdzie tą karierę chcemy zrobić. Temat został umieszczony na grupie "Analitycy IT" w raz z linkiem więc uznaje iż skoro nikt nie zadał sobie trudu na tym forum aby w jakiś sposób uszczegółowić i wyklarować to o czym rozmawiamy, to rozmawiamy o CAŁEJ branży IT w kontekście tego co jest zawarte w artykule.
W IT jest cała masa technologii, języków, metodyk, architektur, wzorców etc.
Gdyby wszystko było zero jedynkowe nie było by np. takiej dyskusji:
http://www.goldenline.pl/forum/2933344/analityk-biznes...
bo była by tylko jedna definicja i koniec, jeden zakres obowiązków i koniec a tak w BABOKu w punkcie 1.2. mamy piękną bardzo ogólną definicje tego czym zajmuje się "analiza biznesowa"
fajnym przykładem jest następny akapit z wyżej wymienionej książki:
“Nasze obowiązki ciągle ewoluują
Coraz bardziej rozmyte zakresu realizowanych przez nas projektów i generalnie naszych stanowisko pracy same w sobie byłyby wystarczającym wyzwaniem dla każdego. Ale dziś musimy dorzucić do tego stale rozbudowywaną definicję naszej pracy. Często pytam moich seminarzystów: “Kto z Was zajmuje się tylko tym, do czego został zatrudniony?”. Bardzo rzadko widzę podniesione ręce. Jakkolwiek nieokreślona i nieograniczona byłaby Twoja praca, to jeśli miałbyś szanse wystarczająco długo zajmować się precyzyjnie określonym zadaniem, prawdopodobnie zorientowałbyś się, co musisz robić (jak intensywnie, na jakim poziomie), aby nie stracić psychicznej równowagi.
Niestety, niewielu może doświadczyć takiego luksusu, a dzieje się tak z dwóch powodów:
1. Organizacje, w których pracujemy, wydają się funkcjonować w trybie ciągłych przekształceń, z permanentnie zmieniającymi się celami do osiągnięcia, produktami, partnerami, klientami, rynkami, technologiami czy właścicielami. Wszystko to nieuchronnie wstrząsa strukturami firm, ich formami, funkcjami i obowiązkami.
2. Przeciętny pracownik jest dziś, bardziej niż kiedykolwiek, kimś w rodzaju niezależnego agenta, który zmienia ścieżki kariery równie często jak kiedyś jego rodzice zmieniali stanowiska pracy.
[...]
W odniesieniu do tego, czym jest nasz praca i jak duży wkład należy wnieść, aby wykonywać ją dobrze, na dłuższą metę coraz mniej rzeczy wydaje się być klarownymi. Dopuszczamy do siebie ogromny strumień informacji i komunikacji ze świata zewnętrznego i jednocześnie generujemy równie wielkie ilości pomysłów i uzgodnień z samym sobą.”
Ciągle pojawia się coś nowego, ciągle coś się zmienia, uważam, że branża IT na tle innych ewoluuje najszybciej ze wszystkich innych co pociąga za sobą ciągłe poszerzanie wiedzy i nabywanie nowych doświadczeń.
Formy specjalizacji będą coraz bardziej uwidocznionym trendem i to nie tylko w “mega projektach” z prostego powodu bo “technologii” jako takiej jest coraz więcej. Przykładem - strzelam teraz - może być SOA czy Cloud Computing gdzie w tej pierwszej pojawiają takie terminy jak: BPEL, JAX-WS, SOAP, SOAP MTOM, WS-Addressing, WS-Policy, WS-Reliable Messaging, QoS to wszystko jest pięknie opakowane hardware’m w postaci np. szaf 19’ z procesorami z VT oraz SVM, na których zainstalowana jest platforma wirtualizacyjna z dwoma systemami operacyjnymi... błagam jak tu się nie specjalizować?
Przecież jedna osoba tego wszystkiego nie ogarnie – analityk biznesowy, systemowy, architekt, programista? Całość przypomina mi trochę wygląd tęczy jak pojawia się na niebie. Całość IT to cała tęcza a wybrane technologie, stanowiska, role, procesy współpracy etc. to poszczególne kolory. Tylko te kolory przenikają się płynnie pomiędzy sobą, jeden przechodzi w drugi itd. tak samo biorąc pod uwagę umiejętności czy role w projektach informatycznych. Typowy programista nie musi - a oczywiście może - w cudzysłowie "wymiatać" w UMLu ale musi go znać na takim poziomie aby jego praca jak najbardziej efektywna czy uwzględniając tylko jego pracę czy całość projektu. Idąc dalej architekt akurat nie będzie znowu najwyższej klasy ekspertem w C# ale musi mieć jakieś pojęcie o programowaniu (kawałku inżynierii) - a to "jakieś" i o jakim kawałku tej tęczy już jest indywidualną sprawą w każdym projekcie, zespole, firmie i podchodzi bardziej pod kwestie zarządzania i swego rodzaju efektywności. Gdyby każdy umiał wszystko i wiedział wszystko w skali 10/10 to zespoły projektowe składały by się z mega ekspertów od wszystkich klocków wymienionych na schemacie z
linku pierwotnej wiadomości.
Odnosząc to do pytania “Co umieć, aby zrobić karierę?” oraz oraz artykułu z pierwszego postu wydaje mi się, że trzeba w jakimś stopniu – mniejszym lub większym – specjalizować się albo inaczej profilować.
A to czy w mniejszym czy większym stopniu i jak to wpłynie na ścieżkę zawodową tego nie powie nam nikt (chyba, że wróżbici z Gartnera ;-). Trzeba uważnie obserwować rynek i zmiany w nim zachodzące to już od nas zależy, w którym kawałku tęczy chcemy się znajdować czy pójść w stronę bardziej menadżerską czy bardziej specjalistyczną i jak chcemy się po tej tęczy poruszać w trakcie ścieżki zawodowej.
Mówiąc specjalistyczna czy menadżerską też nie chce szufladkować pojęć ponieważ pomiędzy tymi pojęciami odwołując się to przykładu jest wiele "kolorów" (technologii, wiedzy, doświadczeń, certyfikatów etc. - ubieram to teraz bardzo ogólnie ponieważ IT jest długie i szerokie), o które można by "zahaczyć" własną osobę. Osobiście, uważam, że taki szufladkowanie powoduje właśnie takie opinie "demonicznej dychotomii" o której pisze nasz magiczny przyjaciel.
Dobrym pomysłem jest korzystanie z doświadczeń innych, który już coś przeżyli np. Pana Jarka, który twierdzi, że pewne książka o ULM jest do bani :), lub znajomego, który przeszedł kurs zarządzania projektami i w jaki sposób to wpłynęło na niego.
Podstawowym problemem wszelkiego rodzaju certyfikatów - a w zasadzie kursów - jest to, że nie da się w łatwy sposób przedstawić mierzalnymi czynnikami zysków z wiedzy
potwierdzonej certyfikatem, no bo o ile szybciej projekt X zakończył by się prowadzony przez człowieka z certyfikatem a o ile bez? O ile szybciej programista z certyfikatem .NET napiszę działający moduł? Może szybciej może nie? Może zapaleniec, który siedział i programował w domu mógłby zjeść na śniadanie tego pierwszego z certyfikatem?
O ile lepszy będzie "Analityk Biznesowy", który skończył
podyplomowe studia na SGH w zakresie "analizy biznesowej" o tego, który ich nie ma? Mamy tutaj masę czynników takich jak doświadczenie, odbyte projekty, przeczytane publikacje, książki, odbyte rozmowy, spotkana etc.
Tu jest przykład pewnego artykułu - nie wiem na ile obiektywnie oddaje realia, umieszczam go tylko:
http://www.computerworld.pl/artykuly/381042/Miekkie.um...
Jeśli mówimy już o certyfikatach to pewnie będą skrajne poglądy w postaci iż jest to "niezła kasa dla firm certyfikujących" ile ludzi tyle opinii.
Jeśli chodzi o szkolenia to dziele ja na bardziej ogólne i bardziej specjalistyczne
np. M_o_R Management of Risk (bo ryzyko jest wszędzie także w inżynierii oprogramowania) albo specjalistycznie IREB (stricte software)
Sprawa kolejną jest to, że typy ogłoszeń o których wspomniał Pan Paweł w postaci:
"potrzebny Architekt IT, wygania:
- zarządzanie zespołem programistów
- programowanie (50% czasu)
- kontakty z klientem
- prowadzenie projektu"
są albo fejkami służącymi do zbierania CVek przez headhunterów czy firmy
albo - ujmijmy to bardzo ogólnie - małego doświadczenia zamieszczającego ogłoszenie.
I w takim wypadku nie się co sugerować czym takim można się zupełnie rozdrobnić w ścieżce zawodowej opierając dalszy rozwój na zamieszczonych tam wymaganiach.
пропозиції роботи
