Archiwa kategorii: Organizacja pracy

Zarządzanie czasem, narzędzia, interakcje w pracy

Technical Product Manager, czyli kto? 10 pytań i odpowiedzi

Technical Product Manager – tak nazywa się rola, którą pełnię w obecnej pracy. W tym wpisie trochę o niej opowiadam i staram się odpowiedzieć na najczęściej zadawane pytania na ten temat.  Wśród nich także „Co to za manager, który nie ma żadnych bezpośrednich podwładnych?!”. Miłej lektury.

Co robi Product Manager?

Najważniejsze zadania Product Managera, czyli po polsku kierownika produktu, to pozyskiwanie wymagań i ich priorytetyzacja. Product Manager powinien wiedzieć, co tak naprawdę jest istotne dla klienta (niezależnie od tego, czy jest nim zewnętrzna firma, użytkownicy aplikacji czy inni programiści w tej samej firmie i tego, czy klient jest jeden czy jest ich wielu). Wiedzę tę strukturyzuje i przekazuje zespołowi programistów w postaci uporządkowanej listy (możliwie) precyzyjnie zdefiniowanych zadań. Współpracuje z zespołem, dbając o terminy i zakres produktu. Pozostaje w ciągłym kontakcie z klientem i dopasowuje końcowy efekt do jego potrzeb. Dba o wizję rozwoju (firmy, produktu) i o to, żeby programiści rozumieli dlaczego każe im się robić akurat to, co robią. Wszędzie tam, gdzie to możliwe,  jego decyzje powinny być poparte twardymi danymi.

W portalu Coursera dostępna jest całkiem ciekawa sześcioczęściowa specjalizacja poświęcona zarządzaniu produktem. Niestety, możliwość korzystania z całości materiałów jest płatna (same nagrania wykładów są dostępne za darmo).

Czym różni się Technical Product Manager od „zwykłego” Product Managera?

Rola jest zasadniczo ta sama. Inny jest człowiek, który ją wykonuje. Wielu lub nawet większość Product Managerów to osoby bez wykształcenia technicznego, które nie jest niezbędne do zrozumienia wymagań klienta i priorytetyzacji kolejnych funkcji do zaimplementowania w systemie.

Istnieją jednak zespoły, których produkt jest bardzo techniczny/niskopoziomowy. Odbiorcą ich produktu nie są końcowi użytkownicy aplikacji, tylko na przykład inni programiści (członkowie innych zespołów w tej samej firmie lub użytkownicy publicznego API). W takiej sytuacji Product Manager musi znać się na technologii, bo nowe wymagania to na przykład zmiana funkcji haszującej albo obsługa nowego standardu języka.

Czym różni się Product Manager od Project Managera?

Najłatwiej podać przykład z metodologii Scrum, chociaż w szczegółach może on być trochę mylący. Product Manager przypomina Product Ownera, Project Manager – Scrum Mastera. Najważniejsze jest to, że Product Manager odpowiada za produkt, czyli to, nad czym pracuje zespół. Project Manager odpowiada za proces i to, jak zespół pracuje. Żeby zwiększyć stopień skomplikowania, wiele firm odróżnia jeszcze rolę Line Managera lub Engineering Managera, czyli osoby, która zarządza personelem, odpowiada za rozwój pracowników i układa ich urlopy.

Czy Product Manager ma podwładnych?

Z reguły nie, chyba że jest przełożonym innych, mniej doświadczonych Product Managerów. Product Manager mówi programistom, co mają robić, ale nie jest ich przełożonym. Nie odpowiada za ich rozwój osobisty (co nie musi znaczyć, że się nim nie interesuje), nie zatwierdza urlopów. Innymi słowy, jest to rola, w której trzeba przekonać zespół do wykonania pracy, bez możliwości wydania im definitywnego polecenia służbowego!

Co jest fajnego w tej pracy?

  • Pracuję z kilkoma zespołami, które robią bardzo różne rzeczy. Dzięki temu poznaję nowe technologie i wyzwania w kilku dziedzinach jednocześnie.
  • Uczę się biznesu i patrzenia na projekty z punktu widzenia ich znaczenia dla rozwoju firmy.
  • Taka dualna techniczno-zarządzająca rola doprowadziła do tego, że firma wysłała mnie i na konferencję developerską (z zespołem programistów) i na produktową (z zespołem produktowym). Żyć nie umierać! 🙂
  • Widzę efekty, czyli skończone projekty, które są w użyciu i którymi można się pochwalić. To duża satysfakcja.
  • Przynajmniej dla mnie, taka praca jest mniej stresująca od programowania. Jako programista czuję się odpowiedzialna za kod, który właściwie nigdy nie jest dokończony i zawsze może się okazać, że coś jest nie tak. Jako PM ufam zespołowi i potrafię odsunąć się emocjonalnie od kodu na tyle, żeby uznać, że zadanie zostało wykonane „wystarczająco dobrze”.

Co (mnie) drażni w tej pracy?

  • Rola jest z gatunku niewdzięcznych, bo zyski (ukończone projekty, postęp prac, kierunek) widzą przede wszystkim przełożeni moi i mojego zespołu. Programiści czasem się frustrują, kiedy muszą zrobić coś, co jest dla nich nudne, albo coś, czego nie uważają za najważniejsze. Nie lubią szacować pracochłonności zadań, o co ich proszę. Frustrują się też kierownicy innych zespołów, którzy wcześniej (kiedy nie było PM) po prostu w dowolnym momencie odrywali zespół od pracy i prosili o przysługi, a teraz w większości przypadków muszą liczyć się z okresem oczekiwania.
  • Spośród masy potencjalnych projektów trzeba wybrać najważniejsze. Niektóre propozycje zostaną odrzucone lub przesunięte na później. Nie zawsze spotyka się ze zrozumieniem zainteresowanych osób.
  • Product Manager pracuje z zespołem programistów (lub kilkoma) ale nie do końca jest jego pełnoprawnym członkiem.
  • Pojęcie MVP (Minimum Viable Product), lub dalej projektu zrobionego „wystarczająco dobrze” bywa odmiennie rozumiane przez biznes i przez programistów. PM musi łagodzić te napięcia i negocjować z obiema stronami.
  • Podział zadań pomiędzy Line Managerem, Project Managerem i Product Managerem teoretycznie jest dość jasny, ale mimo wszystko czasem wdeptujemy sobie na odcisk. Zwłaszcza, kiedy nie ma Project Managera i jego rola jest dzielona przez dwie pozostałe osoby.

Jakie cechy powinna mieć osoba na tym stanowisku?

  • Doskonała organizacja.
  • Umiejętność zajmowania się kilkoma wątkami naraz przy jednoczesnym dbaniu o koncentrację zespołu.
  • Umiejętność delegowania.
  • Asertywność.
  • Umiejętność brania odpowiedzialności za swoje decyzje i porażki.
  • Wrażliwość na potrzeby innych.
  • Znajomość metodologii wytwarzania oprogramowania.
  • Znajomość (lub gotowość do nauczenia się) statystyki.
  • Umiejętność (lub chęć poznania) narzędzi pozwalających na dostęp do danych na temat aplikacji, użytkowników i ich zachowania.
  • Umiejętność skutecznego streszczania problemów.

Czego się nauczyć, żeby się przekwalifikować?

Temat przekwalifikowania się był na tym blogu poruszany wielokrotnie. Technical Product Manager to rola wymagająca wykształcenia bądź doświadczenia informatycznego. Natomiast do zostania „zwykłym” Product Managerem wystarczy posiadanie (lub wyrobienie sobie) cech z powyższego punktu. Jeśli rozważasz spróbowanie sił w takiej roli, a nie masz jeszcze doświadczenia, radzę zapoznać się z następującymi tematami:

  • Nowoczesne metodologie wytwarzania oprogramowania. Najlepiej zacząć od najpopularniejszej obecnie metodologii zwinnej, czyli Scruma. Oryginalna definicja (Manifest programowania zwinnego) jest dość krótka, ale znajdziesz dziesiątki książek na ten temat.
  • Wspomniany na samym początku pakiet kursów na Courserze (nawet same wykłady).
  • Przyda się jakaś lektura na temat analizy i planowania w biznesie. Mnie polecono How to Measure Anything.
  • Warto zapoznać się z jakimś systemem zarządzania zadaniami, jak JIRA. Uzyskanie dostępu do działającej aplikacji może być trudne, ale w Internecie znajdziesz trochę instrukcji i filmików.
  • Podobnie Google Analytics, chociaż tego można się po prostu szybko nauczyć w pracy.

Czy Product Manager może programować?

Jeśli wystarczy mu czasu. Sama przez chwilę myślałam, że mi się uda… Wtedy dostałam pod opiekę kolejny zespół. Nie znaczy to, że moje zdolności programistyczne leżą odłogiem. Po pierwsze, bardzo dużo uczę się, widząc, jak pracuje zespół. Po drugie, w ramach ułatwiania sobie życia i postępowania zgodnie z zasadą „jeśli robisz dokładnie to samo po raz trzeci, pora to zautomatyzować” napisałam w pracy trochę kodu w Javie i Pythonie, który komunikuje się z API Jiry i Google Docs.

Co naprawdę robi Product Manager?

W praktyce głównym moim zadaniem na co dzień jest pilnowanie, żeby zespół potrafił skoncentrować się na tym, co ważne, i kończył rozpoczętą pracę. Niepilnowane, moje zespoły mają tendencję do prowadzenia pięciu projektów naraz (gdyż ciągle ktoś czegoś od nich potrzebuje) i niezorganizowanego łatania mniejszych i większych dziur. W efekcie żaden z projektów nie jest zrobiony do końca i jego klienci nie mogą z niego skutecznie korzystać. Pełnię także rolę tłumacza i opowiadacza dla Product Managerów innych zespołów, którzy nie zawsze rozumieją, co i dlaczego dzieje się na backendzie.

Brzmi jak wyzwanie, które masz ochotę podjąć? Do dzieła! Widzę sporo ogłoszeń firm szukających Product Managerów. Wiele z nich kieruje ogłoszenia do osób, które mają już doświadczenie w tej roli – ale nie wszystkie.

Jeśli masz dodatkowe pytania – chętnie odpowiem.

Doktorat z informatyki – warto?

Rozmawiałam ostatnio z kolegą, który zakończył edukację na etapie licencjatu. Uznał, że pozostałych przydatnych rzeczy szybciej i lepiej nauczy się w pracy. Taka decyzja wydaje mi się egzotyczna, pewnie dlatego, że za moich czasów studia trwały całe pięć lat.  (Chyba że ktoś bardzo się starał i do każdego semestru analizy matematycznej podchodził po dwa razy). Kolega i ja pracujemy w tej samej firmie. Dla niego równie zaskakujący był mój dyplom doktorski.

Kilka lat od opuszczenia progów Alma Mater, dzielę się swoimi przemyśleniami na temat tego, kiedy warto zdecydować się na ten krok.

TAK, doktorat to dobry pomysł, jeśli:

1. rozważasz pracę na uczelni
Doktorat jest warunkiem koniecznym do pracy naukowo-dydaktycznej na dobrej uczelni, więc jeśli czujesz, że to właśnie jest Twoim życiowym powołaniem… Nie ma nad czym się zastanawiać. Pamiętaj tylko, że pracownik polskiej uczelni (na świecie niekoniecznie tak jest) jest zobowiązany habilitować się w ciągu 8 lat od rozpoczęcia pracy – nie da się osiąść na laurach.

2. rozważasz pracę w R&D
R&D, czyli Research and Development (prace badawczo-rozwojowe), to trochę nadużywany termin określający pracę i zagadnienia na styku nauki i nowych technologii. Jeśli nie interesuje Cię stworzenie kolejnego sklepu internetowego albo aplikacji dla banku, możesz spróbować zatrudnić się w centrum R&D – państwowym (jak poznański PCSS) albo należącym do wielkiej korporacji. Tu doktorat się przydaje. Wiele projektów wymaga publikowania, występowania na konferencjach, poprawnego mierzenia i opisywania wyników oraz ogólnej naukowej wiarygodności.

3. znajdziesz super ciekawy zespół
Większość spraw w życiu sprowadza się do znalezienia odpowiednich ludzi. Jeśli możesz dołączyć do istniejącego, sprawnie działającego, zmieniającego status quo zespołu zajmującego się interesującą Cię dziedziną – nie ma się co wahać.

4. nie chcesz czuć presji wyników finansowych
Doktorat to nie wakacje. Od terminów nie uciekniesz: sprawdzanie prac, terminy wysłania artykułów, oceny roczne, warunki grantów. Mimo wszystko masz o wiele większą dowolność niż w jakiejkolwiek firmie. Możesz eksperymentować bez obawy o to, że wprowadzone przez Ciebie rozwiązanie wystraszy klientów i doprowadzi firmę do ruiny. W najgorszym razie napiszesz artykuł o tym, co poszło nie tak… 😉

5. chcesz przyczynić się do rozwoju nauki
Doktorat nie jest do tego konieczny, ale jeśli dobrze wybierzesz, poznasz warsztat niezbędny do „uprawiania nauki”.

NIE, nie rób tego, jeśli:

1. chcesz się rozwinąć i możliwie dużo nauczyć
Do tego nie trzeba uczelni. Zwłaszcza w informatyce, w odpowiednich warunkach, znacznie więcej zyskasz na pracy w ciekawej, nowoczesnej firmie, niż w kazamatach uczelni.

2. nie lubisz prowadzić zajęć (albo w ogóle nie lubisz ludzi)
Prowadzenie zajęć jest obowiązkowe dla pracowników naukowych na uniwersytetach. Istnieje pewna furtka – niektóre instytuty (np. należące do Polskiej Akademii Nauk, jak IPI PAN) umożliwiają pracę naukową bez dydaktyki. Na uczelni jednak nie ma ucieczki. O ile mi wiadomo, co jakiś czas wraca dyskusja o rozdzieleniu pracowników na naukowych i dydaktycznych. Ci pierwsi mieliby niedużo zajęć, ci drudzy nie musieliby przejmować się habilitacją. Póki co jednak nic się w tym temacie nie dzieje.

3. chcesz tylko przedłużyć studiowanie
Od doktoratu zabawniejszy będzie drugi kierunek.

4. zależy Ci na statusie
Doktorant na większości polskich uczelni plasuje się w połowie drogi pomiędzy pracownikiem a studentem. Pracownikiem jest wtedy, kiedy trzeba przypilnować rekrutacji albo na ostatnią chwilę napisać artykuł. Studentem, kiedy mowa o zarobkach albo przydziale miejsc w gabinetach.

5. Chcesz spełnić czyjeś marzenia
To zawsze bardzo zły pomysł.

Na co zwrócić uwagę, jeśli decydujesz się studia doktoranckie?

1. Starannie wybierz promotora
Na podstawie przygód własnych oraz moich przyjaciół wiem, że całokształt wrażeń, samopoczucia i wyników osiągniętych podczas studiów w Polsce jest w przeważającej mierze definiowany przez promotora. Ten może być wspierający, inspirujący i opiekuńczy, może też być egoistycznym tyranem rzucającym ochłapy i żerującym na wynikach podwładnych. Na większości uczelni nikt tego nie kontroluje! Jak sobie pościelisz, tak się wyśpisz.

Co zrobić, żeby nie wpakować się w tarapaty? Przejdź się na prowadzony przez potencjalnego promotora wykład. Podpytaj obecnych doktorantów o to, jak im się pracuje. Sprawdź, ilu spośród doktorantów danego profesora uzyskało tytuł i ile im to zajęło czasu.

2. Dowiedz się, jakie są możliwości wyjazdów i współpracy z innymi ośrodkami
Moim zdaniem każdy student i doktorant powinien spędzić przynajmniej semestr na innej uczelni, najlepiej za granicą, chociażby dla porównania.

3. Dowiedz się, co finansuje uczelnia
W informatyce częściej niż w innych dziedzinach artykuły publikuje się tomach pokonferencyjnych, a nie w czasopismach. Wyjazd na konferencję kosztuje: wpisowe, bilety, nocleg. Dowiedz się jakie są zasady pozyskiwania takich środków na Twojej uczelni.

4. Jeśli masz własny światopogląd, zastanów się nad tym, czy jest kompatybilny ze światopoglądem uczelni
Żebyś nie wstydził się przez zapraszanych gości albo nie zżymał przy religijnych uroczystościach.

5. Fail fast
W przypadku doktoratu warto zastosować zasadę znaną z inżynierii oprogramowania i środowiska start-upów. Jeśli coś się nie zgadza, nie działa – reaguj szybko i w razie czego równie szybko uciekaj. Nie daj się nabrać na regułę utopionych kosztów, która każe kontynuować przedsięwzięcie skazane na niepowodzenie. Studia doktoranckie to kolejne kilka lat Twojego życia – zastanów się, czy wykorzystujesz je najlepiej, jak się da. Wytrwałość nie zawsze jest cnotą.

Parę osobistych słów od autorki

Jak było u mnie? Jakie błędy popełniłam? Co zrobiłabym inaczej?

Po pierwsze,sprawdziłam, czym zajmuje się mój potencjalny promotor, ale nie jaki ma styl pracy. Ostatecznie, przez niedopasowanie na tym polu, przysporzyliśmy sobie nawzajem niemało nerwów. Po drugie, kiedy zorientowałam się, że nie najlepiej funkcjonuję w tym środowisku, było mi żal poświęconego roku… więc włożyłam w to jeszcze trzy!!!

Ostatecznie nie wyszło źle. W mojej drugiej po uczelni pracy zajmowałam się dokładnie tym samym, czym w rozprawie doktorskiej (agentami dialogowymi), w związku z czym już na starcie otrzymałam dość wysokie stanowisko i przyzwoitą pensję. Praca dydaktyczna do dzisiaj sprawie mi ogromną przyjemność (w umiarkowanej ilości). W pewnym momencie rozważałam nawet powrót na uczelnię… Ale to już zupełnie inna historia 🙂

Eksperyment: rekrutacja (2/2)

czyli: drugie pięć z moich dziesięciu rekrutacyjnych oświeceń
czyli: nigdy więcej tą drogą

To druga część wpisu rekrutacyjnego, którego rozmiar wymknął się nieco spod kontroli. W poprzednim odcinku zdradziłam trochę informacji o pracodawcach, do których aplikowałam i przedstawiłam pierwszą połowę moich rekrutacyjnych „oświeceń”. Dotykały one tematów dość uniwersalnych. W tej części przedstawiam odkrycia bardziej osobiste oraz wyjaśniam, jak się to wszystko skończyło.

Lista 10 odkryć, ciekawostek i sensacji

Miejsca 6-10.

(to oczywiście nie jest moje zdjęcie, tylko screen z serialu Misfits)
(Ekipa przy pracy. Oczywiście nie jest to moje zdjęcie, tylko scena z serialu. Którego pierwsza połowa była całkiem niezła. Tak samo może być w przypadku tego wpisu.)

6. Facepalm. Operacja odczytu z HashMapy nie jest bezpieczna dla wątków

Miałam kilka takich technicznych eurek. Jeden rekruter na etapie programowania live wymusił na mnie użycie interfejsu funkcyjnego, dzięki czemu zrozumiałam, co w nim fajnego (można zaimplementować go jedną lambdą!). Inny przypomniał mi podstawowe fakty na temat modelu pamięci w języku, który uważam za ulubiony. Ale najbardziej wstrząsający był moment, w którym młodszy ode mnie o jakieś dziesięć lat* chłopak opowiedział mi o dziurze w moim kodzie. Wielowątkowy kod synchronizował dostęp do metody zapisującej dane w javowyom obiekcie HashMap, ale nie ograniczał odczytu. Efekt: możliwość zgubienia obiektu przy pobieraniu go z mapy, jeżeli w międzyczasie dodanie nowej wartości powoduje zmianę podziału obiektów pomiędzy kubełki. Yeah.

7. Państwowa uczelnia to świat po drugiej stronie lustra

Startując w konkursie na adiunkta wiedziałam, że mam do czynienia z budżetówką. Zero benefitów, skromniejsze płace. Po stronie plusów, w moim wyobrażeniu: inspirujące towarzystwo mądrych ludzi, wymiana wiedzy, prowadzenie badań bez dyszących w kark terminów wdrożeń. Zakończenie tej historii relacjonuję w ostatniej części tego tekstu. Tu przedstawiam „czerwone flagi”, które mimo mojej początkowej ekscytacji i perspektywy pracy z osobami, które podziwiam i uwielbiam, odwiodły mnie od pracy w tym miejscu:

  • Flaga 1: poczta pantoflowa, zwana inaczej wiedzą plemienną. Większość istotnych informacji nie jest dostępna publicznie. Gdyby nie znajomości na wydziale, nie wiedziałabym na przykład o tym, że…
  • Flaga 2: petenci czekają w kolejce. Dzień przed kwalifikacjami podano mi godzinę. Tę samą podano pozostałym kandydatom. Było nas, nomen omen, siedmioro… Wchodziliśmy do sali w kolejności alfabetycznej. Moje nazwisko zaczyna się od litery „W”. Cień nadziei zamigotał w postaci kandydata na „Ż”, ale ponieważ akurat trwały narodziny jego dziecka, poproszono go jako pierwszego. Na czekaniu spędziłam trzy owocne godziny, podczas których moim dzieckiem opiekowała się dobrze opłacona niania. #optymalnewykorzystanieczasu
  • Flaga 3: cisza. Pomyślnego nieoficjalnego wyniku konkursu gratulowano mi jeszcze tego samego dnia, ale musiał on zostać oficjalnie zatwierdzony przez rektora. Przez kolejne półtora miesiąca instytucja, która (jak się ostatecznie okazało) zdecydowała się mnie zatrudnić, nie wystosowała żadnego komunikatu na ten temat. Nie odebrałam maila, pisma ani telefonu, mimo że podałam te dane w dokumentach aplikacyjnych, tuż obok numeru PESEL i stanu cywilnego.

8. Odkrycie personalne: patologicznie nienawidzę rozczarowywać

Pierwszy sygnał pojawił się już w styczniu, kiedy zaczęłam przepytywać potencjalne nianie. Do sprawy podeszłam biznesowo – wystawiłam ogłoszenie, przejrzałam odpowiedzi, umówiłam spotkania. W pracy regularnie prowadziłam rozmowy kwalifikacyjne – była to da mnie emocjonalnie obojętna rutyna. Okazało się jednak, że kiedy nie mogę się zasłonić firmą, sprawy mają się zgoła inaczej, .

Podczas spotkań poznałam kilka ciepłych, doświadczonych, zdeterminowanych, bezrobotnych (lub pracujących na ochronie), kobiet, spośród których wybrać mogłam tylko jedną. Było to dla mnie naprawdę trudne do zniesienia. Pod koniec modliłam się, żeby staropolskim zwyczajem kilka kandydatek bez uprzedzenia nie pojawiło się na umówionej rozmowie.

Obiecałam sobie ten temat przepracować. Zanim się jednak do tego zabrałam, ruszyłam we własne tournée rekrutacyjne. A tam czekała mnie powtórka z rozrywki.

Rozumiem, że korporacje są bezduszne. Że w razie przejściowych kłopotów (czy relokacji) większość z nich nie będzie miała wobec mnie żadnych skrupułów. A jednak nie potrafię tej przerośniętej empatii dezaktywować. Prowadząc równoległe rozmowy z różnymi firmami, które nie zdążyły nawet jednoznacznie określić swoich intencji, i tak czułam się jak zdrajca. Wcześniej wyobrażałam sobie, jak siedzę z lampką wina nad stertą propozycji. W praktyce nie potrafiłam z pokerową twarzą odpowiadać na powtarzające się pytanie „co przekonałoby panią do pracy w naszej firmie”, zwłaszcza kiedy czułam już, gdzie najbardziej mi się podoba. Ostatecznie przez to nie wszystkie procesy doprowadziłam do końca.

9. Najtrudniejsze pytanie

Jak wyżej.

Kilka razy na końcowym etapie rekrutacji usłyszałam pytanie, jaka byłaby moja wymarzona praca, albo jak firma mogłaby przygotować stanowisko dla mnie.

Od lat jednym z moich największych problemów jest to, że interesuje mnie za dużo rzeczy i w zbyt wielu dziedzinach jestem w miarę dobra. Do niedawna nazywało się to „słomiany zapał” (ewentualnie „trzymanie pięciu srok za ogon”), ale w tym roku poznałam o wiele lepiej brzmiące słowo „multipotencjalista”. Myślę, że wkrótce napiszę o tym więcej.

W każdym razie, wyobrażałam sobie, że dostanę gotowe oferty i wybiorę najciekawszą. Programowanie, prowadzenie projektów, wykładanie – chciałam zobaczyć komplet propozycji i wtedy zdecydować. Zadawane w dobrej wierze pytania o moje osobiste preferencje przymuszały mnie do przejęcia inicjatywy i dokonania wyborów, przed którymi od dawna uciekam.

10. Tygodnie maglowania pozwalają lepiej poznać samego siebie

Kolejne sztampowe i okryte niesławą pytanie rekruterów to „gdzie widzisz siebie za pięć lat?”. Plan pięcioletni próbowałam w swoim życiu stworzyć więcej niż raz. Efekt zawsze wyglądał jak pajęczyna, z masą strzałek, warunków, wyjątków i zastrzeżeń. A jednak kiedy to pytanie wróciło do mnie na sam koniec, i kiedy musiałam dokonać wyboru pomiędzy dwoma proponowanymi mi dość różnymi stanowiskami, okazało się, że tygodnie maglowania i wytrącania mnie ze strefy komfortu pozwoliły mi odkryć kilka prawd swój temat. Podczas zupełnie ostatniej rozmowy byłam już w stanie uczciwie i ze sporym przekonanie na to pytanie odpowiedzieć. Co uważam za jedną z największych wartości w całej tej przygodzie.

(to z kolei z wpisu o rekrutacji do przedszkola)
(cudze  materiały rekrutacyjne)

I żyli długo i szczęśliwie

Stworzyłam sobie następujący plan A: uczelnia w połączeniu ze zdalną pracą w polskim startupie o ugruntowanej pozycji, zajmującym się dokładnie „moją” naukową dziedziną. Plan legł jednak w gruzach przez problemy opisane w punkcie 7, a doprawione wymianą kilku maili z dziekanatem. Nie jestem gotowa na skoki ciśnienia o takiej amplitudzie.

W dalszej kolejności nie bez żalu wycofałam się także z długoterminowej współpracy ze wspomnianym startupem. Zdalny etat przestał być kuszący w zestawieniu z nową pracą mojego męża, w której spędza trzy lub cztery dni w tygodniu poza Poznaniem. Cały dzień w domu, przy biurku, cały wieczór w domu, nad śpiącym dzieckiem… Mój ekstrawertyzm potrzebuje ujścia.

W ramach mocnego planu B zgłosiłam się na finalizację rozmów do najfajniejszej z odwiedzonych przeze mnie poznańskich firm. Na szczęście się na mnie nie obrazili. W październiku, a więc już za kilka dni, zaczynam nową pracę jako Technical Product Manager w firmie z fajnym produktem, miłymi ludźmi, wygodnym biurem, w odległości 15 minut na rowerze od mojego domu. Już nie mogę się doczekać!

I mam nadzieję, że przez wiele najbliższych lat nie będę musiała kolejny raz przechodzić przez rekrutacyjną mękę.

Notatka na przyszłość

Szalenie ciekawe doświadczenie. Szansa na odkrycia na temat siebie, rynku pracy, innych ludzi. Nigdy więcej nie robić tego w ten sposób.

Przypisy

* Ponieważ dzisiaj jest to mój kolega z pracy, wiem już, że jest ode mnie młodszy o jedyne cztery wiosny.

Eksperyment: rekrutacja (1/2)

Czyli pierwsze pięć z moich dziesięciu rekrutacyjnych oświeceń.
Czyli chcę największy kawałek tortu.

O tym, że po urlopie macierzyńskim będę szukała nowej pracy, wiedziałam od dawna. Data pojawienia się na świecie mojego dziecka zbiegła się z datą relokacji biura, w którym pracowałam, z Poznania do Warszawy. Gdybyfm już miała gdzieś się przenosić, na pewno nie wybrałabym miasta oddalonego o trzysta kilometrów od domu i przyjaciół. Trzy albo osiem tysięcy –o, to byłaby zupełnie inna rozmowa.

Postanowiłam podejść do sprawy metodycznie. Nie zdawać się na przypadek, nie ograniczać się do firm, które akurat nasłały na mnie headhunterów. Skoro firmom wolno przepytywać wielu kandydatów na to samo stanowisko – kombinowałam – to ja mogę porozmawiać z wieloma firmami i wybrać najbardziej do mnie dopasowaną spośród nich. No, wiadomo, spośród tych, które będą chciały współpracować ze mną. Akcję rozpoczęłam z czteromiesięcznym wyprzedzeniem.

Przygoda była długa i obfitowała w zwroty akcji. Dowiedziałam się sporo o sobie, innych ludziach, technologii, rynku pracy IT. Poniżej krótki bilans i parę moich przemyśleń / odkryć.

Zdecydowałam podzielić ten wpis na dwie części, kiedy rozlał się na piątą stronę i dziesiąty ekran.

Bilans

Ostatecznie wdałam się w rozmowy z siedmioma (!) potencjalnymi pracodawcami. Nie zależy mi przesadnie na utrzymaniu w tajemnicy ich tożsamości, ale nie chcę, żeby ten wpis pojawił się wśród wyników wyszukiwania informacji o którejkolwiek z nich. Odpowiem na dobrze uargumentowane pytania osób, które w tej chwili same szukają pracy. Zadbałam o to, żeby moja lista była zróżnicowana, choć koncentrowałam się na stanowiskach wymagających znajomości Javy, NLP i zarządzania zespołami. Na liście znalazły się, między innymi: dwie firmy pozwalające na pracę zdalną, jedna wymagająca relokacji do innego miasta, jeden polski startup, dwaj światowi giganci, jeden znany gracz wagi średniej, jedna państwowa uczelnia, dwa software houses z ambicjami.

Wyniki rekrutacji: jedna z firm odrzuciła moją kandydaturę na ostatnim etapie rekrutacji, nie oferując żadnej informacji zwrotnej, co uważam za dość perfidne i co stanowi oczywiście bogatą podstawę do wpadnięcia w obsesję. W pozostałych przypadkach zapoznałam się z ofertą lub przerwałam rekrutację w momencie, kiedy podjęłam decyzję o przyjęciu innej propozycji. Decyzja została potem poddana korekcie… Ale o tym poniżej.

Lista (5 z) 10 odkryć, ciekawostek i sensacji

1. Rekruterzy mogą walić drzwiami i oknami, ale większość z nich i tak chce przepuścić kandydata przez wszystkie etapy rekrutacyjnego młyna

Mimo że w większości przypadków to nie ja nawiązywałam kontakt, a szukająca pracownika firma, większość z nich i tak oczekiwała, że kandydat przejdzie przez wszystkie etapy czasem bardzo złożonego rekrutacyjnego sita. W zależności od przypadku, procesy rekrutacyjne obejmowały:

  • Od jednego do pięciu spotkań testujących rozmaite aspekty umiejętności i charakteru kandydata, oczywiście z nieśmiertelnym „dlaczego wybrała pani naszą firmę?”
  • Sprawdzanie umiejętności programowania poprzez: zadania domowe, zadania na sprawdzarce, płatne mini-zadania na rzecz firmy, programowanie flamastrem na tablicy, programowanie na kartce, programowanie przy kimś (sędzia i kibic w jednej osobie), pisemne testy.
  • Sprawdzanie determinacji kandydata poprzez wymaganie własnego, rozbuchanego formatu CV.

Przy odrobinie determinacji na pewno można wynegocjować pominięcie części etapów. Tak było zresztą było przy mojej poprzedniej zmianie pracy. Czułam się na tyle dobrze tam, gdzie byłam, że nie zdecydowałabym się na udział w rozbudowanej rekrutacji do innej firmy. Decyzja zapadła wtedy po jednym spotkaniu. Więc się da.

2. Przepływ informacji pomiędzy działami HR i technicznymi często pozostawia wiele do życzenia

Zapowiedzi osób z HR nie zawsze pokrywały się z rzeczywistym przebiegiem spotkań, na które byłam zapraszana. Nie zgadzały się nazwiska osób z którymi rozmawiałam, zapowiadana długość spotkań, tematy. W najbardziej ekstremalnych przypadkach:

  • Spotkanie trwało dwie i pół godziny zamiast jednej, przez co zresztą dostałam mandat za parkowanie (anulowano mi go w końcu, ale to temat na osobną opowieść).
  • Na „luźnym, nietechnicznym spotkaniu” (upewniałam się dwa razy po wcześniejszych przygodach) położono przede mną test z programowania i baz danych.
  • Nieobecnego menedżera zespołu zastąpiono programistą – kolegą z byłej pracy. Szalenie niekomfortowa sytuacja.

3. O symetrię trudno

Nieliczne firmy pytają wprost o to, czy kandydat uczestniczy równolegle w innej rekrutacji. Robią to głównie po to, żeby potencjalny pracownik nie zrezygnował przez terminy narzucane w drugiej firmie zgodnie z zasadą „lepszy wróbel w garści”.

Właściwie nie do końca wiadomo, jaka jest dobra odpowiedź na to pytanie. (Pewnie prawdziwa). Czy to plus, że mam inne opcje i trzeba się o mnie postarać? A może minus, bo po kosztownym i żmudnym procesie mogę na koniec podjąć inną decyzję?

W tej odsłonie rekrutacyjnych przygód moje wyznanie, że prowadzę rozmowy z kilkoma pracodawcami, spośród których chcę wybrać najbardziej dopasowanego, z którym zostanę dobrych kilka lat, dawało prawie zawsze ten sam efekt. Chwila konsternacji, podziękowanie za szczerość, a następnie kompletne tej informacji ignorowanie.

4. W Poznaniu istnieją biura doskonałe

Podczas swojego krótkiego tournée napotkałam: prysznice w biurze, parkingi dla rowerów, kuchnię z darmowym jedzeniem (screen z odcinka girls), biurka z elektrycznie podnoszonymi blatami, muzykę w wc, piłkarzyki i instrumenty muzyczne (wiem, że akurat na ten temat opinie są mieszane), możliwość przyprowadzenia do pracy dziecka albo psa.

Może nie aż tak, jak u Hanny...
Może nie aż tak, jak u Hanny…

5. Mroczne widmo GitHuba

Wolne oprogramowanie jest super. Dostępność kodu prawdziwych, wdrożonych projektów jest nie do przecenienia z edukacyjnego punktu widzenia. GitHub jest także coraz częściej wykorzystywany przez portale takie jak Coursera jako miejsce, w którym uczestnicy kursów mogą wzajemnie oceniać swoją pracę w procesie peer evaluation. Jednak ta otwartość ma swoje minusy. Jeden (tylko jeden, co w sumie zaskakuje) z rekruterów skrupulatnie przyjrzał się mojej githubowej twórczości – na tyle skrupulatnie, że wytknął mi błąd z obszaru synchronizacji wątków. Jezu, co za wstyd! Na GitHubie trzymam głównie wprawki – kod, który tworzę „na poważnie” w ramach pracy rzadko kiedy jest dostępny, a po pracy lubię zająć się hobby z nieco innej dziedziny. Tak czy inaczej, chcesz czy nie, GitHub staje się oficjalną wizytówką programisty.

W następnym odcinku

Kolejne pięć odkryć, w tym kilka na własny temat, oraz informacja o tym, jak się to wszystko skończyło.

Eksperyment: rekrutacja (2/2)

Bonus: czego szukają rekruterzy

W miarę wiadomo: wiedzy, pomysłowości, umiejętności pracy w zespole i radzenia sobie z nienapotkanymi wcześniej problemami.

Podczas mojej odysei udało mi się wyciągnąć z jednego z kierowników ciekawą informację na temat wymagań, które jego firma stawia programistom. Kandydaci dostają kartkę z opisem kilku zadań i chwilę na ich przemyślenie, a potem, już w obecności pracownika firmy, muszą zaproponować rozwiązania. Jedno z zadań zawiera przydługi opis systemu, który należy zaprojektować. Według relacji, większość potencjalnych programistów bardzo pobieżnie czyta tekst, po czym ochoczo zabiera się za projektowanie. Co z tego wychodzi – wiadomo. Pięknie zaprojektowany, zgodny z wzorcami, pełen fajerwerków projekt, który nie ma nic wspólnego ze specyfikacją.

Warto mieć na uwadze.

Przewodnik po kategoriach

Ponieważ mój udział w konkursie „Daj się poznać” zaburzy nieco równowagę na blogu, chciałam zwrócić uwagę na kategorie, które mają ułatwić rozpoznawanie i wyszukiwanie wpisów.

Nazwa Znaczenie Przykładowy wpis
Ciekawostki Jednorazowe (nie tworzące żadnych serii) wpisy na ciekawy lub zabawny temat okołoinformatyczny Kup swojemu dziecku sobie robota Lego Mindstorms
Konferencje Relacje z konferencji O różnicy pomiędzy konferencją naukową a programistyczną, czyli wyprawiłam się z dzieckiem (i mężem) na 4Developers
Nie na temat Żale pozainformatyczne Wsadźcie sobie w **** ten apostrof
Ogólnie o programowaniu Artykuły na temat programowania, które mogą być czytane przez nieinformatyków Wieża Babel. Skąd tyle języków programowania? (część 1 z 3)
Organizacja pracy Zarządzanie czasem, narzędzia, interakcje w pracy 10 rad z obu stron frontu dla początkujących liderów projektów IT
Populizm Wpisy lekkie i nie zawsze poważne 7 powodów, dla których warto zostać programist(k)ą
Średnio zaawansowane Wpisy dla programistów (także początkujących) Ciągła Integracja: anioł stróż dobrego programisty
Tajemne szyfry (zaawansowane) Bardzo techniczne wpisy dla programistów; niekoniecznie bardzo trudne, raczej – związane z konkretną technologią i mało uniwersalne Własny formularz logowania Spring Security

 

Ekshibicjonistyczny wpis o prokrastynacji i diecie informacyjnej

Dziś o marnowaniu czasu w Internecie.

Zaczęło się od tego, że…

Postanowiłam wziąć udział w konkursie Daj się poznać. Konkurs wymaga utworzenia projektu open source i blogowania o postępach prac. Jako że różnych hobby[1] mam więcej niż Java bibliotek ORM (hłe, hłe), a moment w życiu nie zachęca do rzucania się z motyką na cokolwiek – potrzebowałam zewnętrznej motywacji do działania.

Czas pokaże, czy wystarczy mi determinacji do samego końca. Póki co, rozmyślam o prokrastynacji i szkodliwych nawykach. Z tej okazji kolejny raz wróciłam do przełomowej dla mnie książki Information Diet Claya A. Johnsona.

Jeszcze jeden brzydki wyraz

Prokrastynacja” to nie jest ładne słowo. Nie ma go w „Słowniku języka polskiego” PWN, a to prawie zawsze oznacza, że istnieje już poprawne polskie słowo oznaczające dokładnie to samo. Najpiękniejszy wolny przekład, z jakim się spotkałam, to „kunktatorstwo”, ale bliżej sedna jest chyba zwykłe „zwlekanie”.

Prokrastynację najczęściej powoduje niepokój (przed porażką lub, o dziwo, sukcesem), a jej najbliższym pomagierem jest, oczywiście, Internet.

Najlepsze remedium na prokrastynację…

… to sprawowanie opieki nad niemowlęciem. Takie odkrycie z ostatnich trzech miesięcy 🙂 Mimo że mam „aniołka”, który płacze tylko, gdy ma realny problem, to znalezienie chwili na kreatywny namysł graniczy z niemożliwością. W efekcie wiem, że kliknięcie w ten jeden kuszący link istotnie zwiększy ryzyko, że pracę nad kolejną linijką (gdy wreszcie się za nią zabiorę) przerwie rozdzierający wrzask. To naprawdę skuteczny wspomagacz dyscypliny.

Siła nawyku i obiecany ekshibicjonizm

Czas się przyznać. Nawet przy dziecku mam potężny problem z pozbyciem się jednego szalenie szkodliwego i trochę wstydliwego nawyku. Czytam w wannie. Uwielbiam czytać w wannie. Nie od święta i nie zawsze przy świecach. Prawie codziennie. Rano. Książkę, ale także głupoty w Internecie.

Mądrzejsi od mnie twierdzą, że nawyk składa się z trzech elementów: wyzwalacza, reakcji oraz nagrody, i że można tę sekwencję wykorzystać do świadomego wytworzenia nawyków pożądanych. Chciałabym, po dzwonku budzika, na autopilocie lądować w lesie na przebieżce z psem (póki mąż w domu), a nie w wannie w stanie półhibernacji! Trzymaj za mnie kciuki.

Czy nabijasz się z milionów Polaków bezmyślnie wpatrzonych w telewizor?

Jak wielu moich przyjaciół, nie oglądam telewizji. Mogę sobie gratulować, że wiele dzieli mnie od statystycznego Polaka, który spędza przed telewizorem zatrważające 4,5 godziny dziennie. Tylko że… Nie czarujmy się. Internet niekoniecznie jest lepszy, a w wydaniu większości (do której pewnie należę) zdecydowanie taki nie jest.

Internet to największy zasób wiedzy na świecie, a jednocześnie największy zasób głupoty.

Pamiętaj, że mózg staje się najlepszy w tym, w czym regularnie go ćwiczysz. Czy warto wyspecjalizować się w podążaniu za clickbaitem (odmieniłam, a co)?

Dieta informacyjna

Autor Information Diet porównuje konsumpcję informacji do konsumpcji żywności.

Tak jak w przypadku jedzenia, najzdrowsza jest informacja nieprzetworzona, pochodząca z samego źródła. Zatem nie wiadomości na portalach i w tygodnikach opinii, tylko artykuły naukowe, notatki agencji prasowych, potwierdzone relacje świadków, poparte źródłami analizy ekspertów. Porównanie wbrew pierwszemu wrażeniu nie jest na wyrost. Autor wskazuje informacyjne odpowiedniki śmieciowego jedzenia i tłumaczy, jakie mechanizmy sprawiają, że nabieramy się na jedno i drugie.

Co ciekawe, problemu nie rozwiązuje samo publiczne udostępnienie źródeł (np. rządowych raportów na temat wydatków), ponieważ czytelnik musiałby jeszcze do nich sięgnąć. Porównanie z książki: zalanie rynku brokułami nie sprawi, że ludzie zaczną odżywiać się zdrowo. Musimy zdobyć się na świadomy wysiłek.

Tak jak w przypadku jedzenia, w przypadku informacji również można przejść na dietę.

  • Odmawiać sobie klikania linków w stylu „a wtedy stało się TO”.
  • Trenować interwałami utrzymywanie uwagi i koncentracji.
  • Sięgać do źródeł.
  • Sprawdzać pochodzenie zdjęć (w Google Images można szukać zdjęć podobnych do danego zdjęcia oraz wcześniejszych wystąpień tego samego zdjęcia w artykułach).
  • Zaglądać do magazynów prezentujących przeciwną opcję polityczną.

Istnieją narzędzia pozwalające zwiększyć produktywność przy komputerze. Jednym z nich jest RescueTime, które śledzi naszą aktywność i przedstawia raporty na temat czynności wartościowych i nie. Narzędzie jest konfigurowalne i podobno bezpieczne.

Zadanie domowe

Chciałabym zaproponować Ci zadanie domowe.

Jeśli jeszcze tego nie robisz: następnym razem, kiedy poruszy Cię wiadomość przeczytana w Internecie, postaraj się dotrzeć do samego źródła. Znajdź nagranie, cytat, raport z badań. W wersji „z gwiazdką” sprawdź dodatkowo, czy w ogóle i w jaki sposób piszą na ten sam temat media z przeciwnej opcji.

Dzielę się swoimi wynikami: news, który mnie zbulwersował, okazał się niestety niepodkolorowaną prawdą. Kandydat na prezydenta, poseł i ojciec trzech córek faktycznie insynuował że nieatrakcyjna (jego zdaniem) kobieta powinna cieszyć się z molestowania.

 

[1] Do bardzo niedawna sądziłam, że mój nadmiar zainteresowań jest głęboką patologią. Natknęłam się jednak na cudowne wystąpienie Emilie Wapnick na TED i odetchnęłam z ulgą. Polecam.

[2] Obrazek w nagłówku pochodzi stąd: https://sketchport-hrd.appspot.com/drawing/5795385024970752/hotdog. Okazało się, że nie potrafię narysować hot doga.

Przekwalifikowanie – mrzonka czy realna szansa?

Chociaż nie zawsze da się to rozpoznać po ubiorze bądź stylu życia* i niekoniecznie jest to sprawiedliwe, zarobki w miarę doświadczonych programistów czynią z nich jednych z najlepiej wynagradzanych ludzi w Polsce.

Nie wszyscy zajęli się informatyką z powodu absolutnej pasji. Kodowanie to bardzo przyjemna, satysfakcjonująca i stanowiąca wyzwanie praca – jednak wielu znanych mi programistów do poczucia osobistego spełnienia potrzebuje również samorealizacji w nieco bardziej humanistycznych dyscyplinach.** Być może dlatego nierzadko słyszę kolegów po fachu sarkających na bezrobotnych absolwentów kierunków miękkich. „Po co szedł na takie studia?”, „Wiadomo, że praca jest gdzie indziej”, „Niech się przekwalifikuje, przecież my też co chwilę od podstaw uczymy się czegoś nowego”.

Opinie te bywają powtarzane zdecydowanie i bez zastanowienia. A jednak nie tak dawno byłam świadkiem sytuacji, w której absolwent teatrologii (nie wymyślam tego!) zapytał zaprzyjaźnionego programistę, od czego zacząć przekwalifikowanie się… a programista zbladł. Co innego teoretyzować o zmianie w cudzym życiu, a co kogoś przekonać i przyjąć choć część odpowiedzialności za jego rozwój, a ostatecznie także sukces bądź porażkę.

W tym wpisie postaram się odpowiedzieć na pytanie, czy da się zostać programistą na późniejszym etapie życia i podzielę się wskazówkami na temat tego, jak zacząć.

Warunki konieczne

Skoro popyt jest tak duży, czy programistą może zostać każdy? Skrócona odpowiedź brzmi: absolutnie nie!!! Jednak z powodzeniem może się to udać całkiem sporej grupie osób, które wcześniej nie rozważały tej profesji.

Następujące cechy i umiejętności uważam za konieczne do rozpoczęcia nauki w tym kierunku:

1. Analityczne, uporządkowane myślenie

Programowanie to w dużej mierze praca kreatywna, ale ten rodzaj kreatywności ma niewiele wspólnego z twórczym chaosem. Musisz być w stanie myśleć algorytmicznie: wyraźnie definiować kroki prowadzące do uzyskania wyznaczonego celu. Musisz przykładać uwagę do szczegółów. Musisz przewidywać, co może pójść nie tak, jak niestandardowo może się zachować klient, jakie problemy mogą wystąpić. W dużej mierze sprowadza się to do tego, że programista powinien mieć stosunkowo wysoki iloraz „matematycznej” („tradycyjnej”) inteligencji.

2. Cierpliwość

Materiału do przyswojenia jest dużo. Tworzenie prawdziwych, złożonych aplikacji trwa i wymaga współpracy wielu osób. Co prawda istnieją trendy wytwarzania oprogramowania od strony interfejsu użytkownika, gdzie od razu widać włożony wysiłek, jednak musisz być gotowy na żmudną pracę, która długo nie przynosi widocznych efektów (oprócz przechodzących testów – bo oczywiście będziesz pisać testy).

3. Radość z pisania kodu

Większość znanych mi programistów bardzo wcześnie zaczęła zdradzać smykałkę do kodowania. Sama spędziłam długie godziny nad otrzymanym na komunię Commodore 64, programując quizy i przelatujące przez ekran rakiety ASCII Art (następnie mój rozwój zatrzymał się na lata na tym etapie). Jeśli jednak nie zostałeś odpowiednio zachęcony za młodu, postaraj się możliwie szybko znaleźć odpowiedź na pytanie: „czy sprawia mi to przyjemność?”. Po pierwszym kursie programowania lub po pierwszej przeczytanej książce – spróbuj rozwiązać prosty problem programistyczny (np. na sprawdzarce takiej jak ta: http://acm.timus.ru/). Jak było? Udało Ci się? Co czułeś, kiedy program działał coraz lepiej? Ogromną satysfakcję, a może ulgę, że wreszcie koniec? To bardzo ważne.

4. Znajomość angielskiego

W dzisiejszych czasach nie da się programować bez dobrej (biernej) znajomości (pisanego) angielskiego. Większość kursów (o których zaraz) jest po angielsku. Dokumentacja, którą będziesz czytać jest prawie zawsze po angielsku. Gotowe rozwiązania popularnych problemów są opisane po angielsku, np. na http://stackoverflow.com/. Być może uda Ci się dorwać podręcznik po polsku (warto), ale większość ratujących tyłek, aktualnych treści istnieje jedynie w języku angielskim.

Przydadzą się

Po pierwsze, na pewno przyda Ci się mentor. Życzliwa osoba już pracująca w zawodzie, o którym myślisz, skłonna poświęcić Ci trochę czasu i wskazać kierunki rozwoju. Znasz kogoś takiego? Doskonale. Nie znasz? Jeśli mieszkasz w większym mieście, przejdź się kilka razy na spotkania lokalnych User Groups***. W przeciwnym razie możesz spróbować uzyskać wsparcie w grupach i na forach w Internecie.

Po drugie – czy znasz języki obce? Jeśli tak, to tym lepiej dla Ciebie. Im więcej tym lepiej. Język programowania to też język, który ma swoją składnię i semantykę. Jeśli zdołałeś opanować język obcy (analitycznie, czyli potrafisz narysować drzewo składniowe zdania), w Twoim mózgu powinny już być wydeptane najważniejsze ścieżki umożliwiające korzystanie z języka programowania.

Jak się nauczyć?

O ile znasz angielski, a jak tłumaczyłam powyżej, właściwie musisz go znać, to masz do dyspozycji ogrom wiedzy przedstawionej w portalach MOOC (Massive Open Online Course, czyli masowe otwarte kursy online), takich jak Edx czy Coursera. W większości przypadków kursy składają się z wykładów, ćwiczeń praktycznych (w postaci testów) oraz zadań programistycznych, sprawdzanych albo automatycznie, albo przez innych uczestników kursu. To doskonały punkt startowy.

Oprócz tego są podręczniki, dokumentacje języków programowania, a także warsztaty**** (często darmowe) organizowane przez różne społeczności, np. Geek Girls Carrots.*****

Jaki język?

Uparcie utrzymuję, że najbardziej przyszłościowy (liczba ofert pracy, przeznaczenie) język, którego można się w miarę szybko nauczyć od podstaw, to Python. Ale możesz rozejrzeć się, czego potrzebują i uczą w Twojej okolicy.

Rozmowa o pracę

Są firmy, które nigdy nie zatrudnią początkującego programisty. Są szefowie gotowi pracować tylko z pasjonatami, od podstawówki piszącymi wirusy. W niektórych przypadkach takie wymagania mają sens, w innych niekoniecznie. Uwierz jednak, że istnieje masa firm gotowych podjąć ryzyko przyjęcia kogoś niezbyt doświadczonego i przeszkolenia go.

Nie będę tu powtarzać tradycyjnych porad na temat pisania CV i przygotowania do rozmowy rekrutacyjnej. Najważniejsze: nie ściemniaj! Jeśli jesteś w stanie psychicznie znieść porażkę, po nieudanej rekrutacji dopytaj, czego Ci zabrakło i spróbuj rozwinąć się trochę w tym kierunku.

Warto pamiętać, że informatycy w firmach wytwarzających oprogramowanie to nie tylko programiści. Do branży możesz wejść trochę „od tyłu”, na przykład jako tester. Mimo wszystko zachęcam do rozpoczęcia procesu zmian od przyswojenia jednego przynajmniej języka programowania.

Licz się z tym, że…

1. Będziesz się ciągle uczyć

Taki zawód. Jeśli chcesz coś w nim osiągnąć i mieć pewność zatrudnienia, będziesz co jakiś czas przerabiać nową książkę, nowy blog, nowe kursy. Nawet jeśli w pracy nie będziesz siedzieć po godzinach (rozsądni szefowie wiedzą, że liczba błędów wprowadzonych podczas nadgodzin często niweluje jakąkolwiek płynącą z nich wartość dodaną), ale czasem po pracy,  w prywatnym czasie, będziesz musiał przysiąść nad nową technologią.

2. Twoja głowa będzie stale w pracy

To również wynika ze specyfiki zawodu. Nierozwiązane problemy będą się za Tobą wlekły. Spędzisz wiele wieczorów, zastanawiając się, dlaczego to u licha nie działa. Dobra strona medalu: niejednokrotnie przekonasz się, że Twój mózg pracował, kiedy spałeś, a że niemożliwy do rozwiązania problem następnego dnia okaże się trywialny.

3. Koledzy z pracy nie raz zdziwią się, że czegoś nie wiesz

Nauczyłeś się pierwszego języka programowania. Na trzeciej z rzędu rozmowie rekrutacyjnej napisałeś test na 80%, pokazałeś, że jesteś odpowiedzialnym i zdeterminowanym człowiekiem – i dostałeś pracę. Pierwszego dnia przychodzisz do biura, dostajesz swoje pierwsze zadanie i nagle okazuje się, że kompletnie nie wiesz, jak zacząć. Znasz język, ale co oni mówią o LDAP, kontroli wersji, bazie danych…? W tym momencie wróć do punktu 1. Będziesz się ciągle uczyć. W obliczu nieznanych problemów spróbuj najpierw skorzystać z Google. Jeśli nie dajesz rady – poproś o pomoc. Zadbaj o to, żeby nigdy nie pytać dwa razy o to samo.

Studia informatyczne trwają pięć lat i nie polegają jedynie na nauce programowania. Ich absolwenci często sami nie zdają sobie sprawy, że niektóre zagadnienia nie wchodzą w zakres wiedzy ogólnej i mogą być komuś (bądź co bądź) w branży kompletnie nieznane. Przełknij dumę, uzupełnij luki, znajdź sobie miejsce w organizacji. Będzie dobrze.

4. Na początku możesz zarabiać mniej niż dotychczas

Nie tylko możesz zarabiać mniej niż dotychczas, ale na dodatek może to być mniej, niż zarabia o połowę od Ciebie młodszy dzieciak w sąsiednim kubiku. Nie przejmuj się, to tymczasowe. Nie ma lepszej metody nauki programowania niż w prawdziwej pracy – potraktuj to jako (opłacaną przecież!) inwestycję w siebie.

Uwaga: z awansami i podwyżkami w firmach informatycznych różnie bywa. Czasami jedyną metodą na zauważalną podwyżkę jest przejście do innej firmy.

Czy płeć ma znaczenie?

Serio, nie wiem.

Kobiecie, która chce się przekwalifikować, tak samo jak początkującej praktykantce, paradoksalnie może pomóc stereotyp „damy w opałach”. W zmaskulinizowanym biurze możesz pozwolić otoczyć się mentorską, dżentelmeńską i trochę protekcjonalną opieką, o ile całe Twoje jestestwo nie protestuje przeciwko takiemu stawaniu sprawy. Ostrzegam jednak – takie łatki trudno potem zgubić.

Czy znam ludzi, którym się udało?

Tak!!!

Słowa klucze: odwaga, wytrwałość, inteligencja, ciekawość.

A jeśli się nie uda?

Wysiłek włożony w przyswojenie tych kwestii i tak nie pójdzie na marne. Podstawy programowania będą coraz bardziej potrzebne do wykonywania innych zawodów. Wyraźnie to widać np. w dziedzinie biotechnologii.

Przypisy


* Nie piję tu przesadnie do stereotypu niedomytego informatyka. Uważam się za informatyka domytego, a jednak mam na koncie kuriozalne doświadczenie ze sklepu Zara, gdzie na podstawie nieformalnego i powyciąganego ubioru zostałam potraktowana jak złodziejka.

** Zdaniem wielu, stanie w takim rozkroku jest przepisem na porażkę. Polecam wystąpienie Larry’ego Smitha na TED, zatytułowane „Dlaczego nie zrobisz wielkiej kariery”. Jako świeżo upieczona matka karmiąca mam ostatnio dużo czasu na oglądanie takich wykładów, więc od czasu do czas będę się dzielić perełkami 🙂

*** Od razu ostrzegam, że poziom i kultura lokalnych społeczności programistycznych bywają różne. Niektóre są bardzo przyjazne dla początkujących, inne pielęgnują profesjonalny poziom i zadzierają nosa 😉

**** Odmienne od mojego zdanie na temat szkół programowania ma autor tego artykułu w portalu TechCrunch: Coding Academies Are Nonsense. Wrzucam jako ciekawostkę.

***** Powiem szczerze, że cykliczne spotkania Geek Girls Carrots nieco mnie rozczarowują, ponieważ są dużo bardziej startupowe niż programistyczne. Niezależnie od tego, organizacja tworzy i promuje sporo wartościowych kursów programowania dla początkujących.

10 rad z obu stron frontu dla początkujących liderów projektów IT

W obliczu czekających mnie niebawem zmian – trochę mniej pracy, trochę więcej rodziny – koncentruję się na porządkach i podsumowaniach. Dziś pozwolę sobie znów oddryfować od kwestii technicznych, tym razem po to, by podzielić się spostrzeżeniami na temat wyzwań stanowiących codzienność liderów w projektach informatycznych. Piszę z własnego doświadczenia w tej roli, ale wplatam tu również garść przygód i wniosków podpatrzonych u swoich szefów oraz znajomych. W końcu uczyć się można nie tylko na własnych błędach.

1. Nie traktuj utraty pracownika w kategoriach osobistej porażki.

Punkt najdłuższy, bo najtrudniejszy.

Są ludzie (bardzo cenni), którzy muszą czuć, że stale się rozwijają. Istnieją firmy (bardzo cenni), które potrafią zapewnić ciągły rozwój pracownikom każdego szczebla.

W większości przypadków główną motywacją pracownika są pieniądze. Można doceniać miłą atmosferę w pracy i bogatą ofertę szkoleń, ale większość osób wstaje co rano do roboty, żeby po powrocie móc prowadzić (wy)godne życie. Pracodawca z kolei może dbać o morale i przydzielać rozwojowe zadania, jednak jego nadrzędnym celem musi być osiąganie zysków. Zyski zaś często pochodzą z najnudniejszych projektów w dobrze rozpoznanych, trywialnych obszarach.

Choćby lider posiadł umiejętność stawania na rzęsach, z każdego zespołu, zwłaszcza większego, w którymś momencie ktoś odejdzie. Potencjalnych przyczyn jest bez liku. Zmęczenie niejasnymi procedurami w firmie. Zbyt niskie zarobki. Ciekawsza oferta z innej firmy, bliższa zainteresowań danej osoby. Rozwój prowadzący do poszukiwań większych wyzwań. Kryzys w życiu prywatnym. No najgorsza z opcji z punktu widzenia lidera: jego koszmarny, chaotyczny styl zarządzania.

Oczywiście, pytanie o przyczynę zawsze warto zadać i sobie, i podwładnemu. Odejście pracownika bywa zaskoczeniem, z kategorii przykrych. Łatwo dać się ponieść emocjom i wznieść się na poziom niemalże oskarżeń o zdradę. Mimo że sama padłam kiedyś ofiarą agresywnego oskarżenia o brak lojalności podczas zmiany pracy, to postawiona po raz pierwszy i drugi wobec czyjegoś wypowiedzenia, musiałam świadomie zdusić w sobie urazę i silną atawistyczną chęć odwetu.

Jestem przekonana, że warto wspierać rozwój swoich podopiecznych, nawet jeśli ostatecznie przerosną przez to macierzystą firmę. Pracownikowi należy się wdzięczność za poświęcony czas i realne osiągnięcia, a nie wypominanie (niewypowiedzianych najczęściej) zadań, których przez swoje odejście nie zdążył zrealizować.

Co z pracownikiem, który faktycznie zniknął z dnia na dzień i zostawił za sobą zgliszcza? Proponuję uczcić jego zniknięcie kieliszkiem szampana. A potem załatać procedurę rekrutacji.

2. Wspieraj rozwój swoich podopiecznych.

Jak wyżej. Niech czują, że oprócz pieniędzy praca daje im coś jeszcze. Stawiaj przed nimi wyzwania, którym zdołają podołać, jeśli się wysilą. Możliwe, że w końcu przerosną firmę i odejdą, ale w takiej sytuacji będą wspominać ją – i Ciebie jako lidera – z wdzięcznością.

3. Krytykuj konstruktywnie.

Zarówno wygłaszanie, jak i przyjmowanie krytyki jest trudne. Istnieje sporo literatury i kursów dedykowanych temu zagadnieniu. Można stosować obciachowe triki, np. „na kanapkę”: pochwała, gorzkie słowo, na koniec znów coś na podniesienie na duchu. Moim zdaniem najważniejsze jest trzymanie się jednej humanitarnej zasady: słowa krytyki mają służyć rozwojowi. Przekazanie negatywnej oceny nie ma być okazją do odreagowania. Spróbujcie razem zrozumieć, co poszło nie tak i dlaczego. Jak uniknąć problemów w przyszłości? W jakim obszarze dana osoba powinna się dokształcić, jakie reguły poznać? Jakich zadań zwyczajnie nie należy jej przydzielać?

Beznadziejne przypadki są rzadkie. Najtrudniejsze sytuacja, z jaką sama się spotkałam, to osoba omyłkowo zatrudniona powyżej swoich kwalifikacji: kontaktowa, pracowita, ale niezdolna do efektywnego ogarnięcia przydzielonej jej odpowiedzialności.

4. W piętrowej korporacyjnej strukturze dbaj o równowagę lojalności wobec szefa i wobec podwładnych.

Ochrona plemiennych interesów i rodzinna atmosfera w zespole projektowym to jedno, ale nie możesz też w nieskończoność ukrywać niekompetencji sympatycznego członka zespołu przed wspólnym szefem. Za niepowodzenie ostatecznie zapłacicie wszyscy. Zakładam, że mój szef powinien mieć ogólne wyobrażenie na temat mocniejszych i słabszych stron osób, z którymi pracuję – głównie po to, żeby mógł w razie potrzeby sensownie przesuwać je pomiędzy projektami. Absolutnie bez skarżenia, kto akurat dzisiaj się spóźnił albo wypchnął kod do repozytorium bez przeprowadzenia elementarnych testów.

Uważaj również na zasłanianie się szefem. Musisz ogłosić niepopularną decyzję, a może nawet sam się do jej podjęcia przyczyniłeś? Najłatwiej powiedzieć „cierpię z wami, ale góra tak chciała”. Są rzadkie sytuacje, w których takie podejście to najmniejsze zło – decyzja jest nieodwołalna, a czasu na dyskusję brak. Staraj się jednak zachować uczciwość i nie maluj szefa jako wcielonego diabła, gdy faktycznie robisz z niego kozła ofiarnego. Uczciwość nakazuje przyjąć odpowiedzialność za własne decyzje. Poza tym, brak zaufania do wyższych szefów i przekonanie o życiu w oblężonej twierdzy pogorszy poczucie bezpieczeństwa członków zespołu, a ostatecznie także ich wydajność i lojalność wobec pracodawcy.

5. Wysyłaj maile z podsumowaniem, w obie strony.

Szefowi (bądź klientowi) regularnie ślij maile podsumowujące status projektu i pytania o sprawy wymagające jego decyzji bądź opinii. Polecam wypunktowanie najważniejszych elementów na samym początku.

Do „dzieci” pisz przede wszystkim po spotkaniach. Przypominaj najważniejsze poruszone kwestie (np. terminy) oraz wysokopoziomowy przydział zadań (do niskopoziomowych zadań jest specjalny system, prawda?). Na wypadek gdyby ktoś nie uważał, nie zrozumiał, był nieobecny.

6. Dbaj o kulturę szczerości i odpowiedzialności.

Deleguj. Nie musisz wszystkiego robić sam. Sprawdzaj na koniec – ale deleguj też sprawdzanie (np. przeglądy kodu pomiędzy programistami). Wstydliwe wpadki omawiaj prywatnie. Jeśli się powtarzają – na forum, najlepiej bez wskazywania winnych.

Stwórz atmosferę, w której pracownik będzie wolał od razu przyznać się do błędu, niż tygodniami go tuszować.

7. Konflikty duś w zarodku.

Znam menedżerów całkowicie obojętnych na konflikty pomiędzy pracownikami. Niektórzy w ogóle ich nie widzą, inni decydują się nie wtrącać.

Dla mnie przyjazna atmosfera w pracy (a przynajmniej w podstawowej komórce rodzinnej jaką jest jeden projekt) to absolutny priorytet. Chcę, żeby pracownicy mogli nawzajem na siebie liczyć. Energia utracona na konflikty i „polityczne” rozgrywki to niepowetowana strata dla wszystkich zaangażowanych stron.

Z własnego doświadczenia dorzucę jeszcze to: ufaj swojej intuicji i w razie czego szybko pozbądź się zakały. Ktoś jest trudny we współpracy, ale nie potrafisz sprecyzować dlaczego i myślisz, że może tylko Tobie się tak wydaje? Odrzuć taką osobę od razu. Trudno tu nawet polegać na podpytywaniu zespołu – źle pojęta lojalność i niechęć do donosicielstwa zachwiała kiedyś posadami mojego projektu.

8.Nie ignoruj praw i spraw mniejszości.

Miło i wygodnie żyje się w gronie osób bardzo podobnych do nas. Nikt nikogo nie zmusza do weryfikacji zastałych poglądów, wszyscy śmieją się z tych samych żartów. Niemało menedżerów zatrudnia według tego klucza – O, lubi Star Wars i Philipa Dicka! Wpisuje się w nasz kulturowy kod, więc na pewno będzie dobrym programistą.

Różnorodność bywa jednak otrzeźwiająca. Inne tło społeczne może wygenerować przydatne refleksje niedostępne dla monolitycznego kulturowo zespołu. To zysk, ale wprowadzenie do zespołu kogoś odmiennego (pierwszej kobiety, przedstawiciela innej religii, obcokrajowca, skrajnego introwertyka) wymaga przebudowania codzienności i chwilowego z(a)burzenia komfortu. Nie chcę powtarzać wywodów na temat seksizmu w miejscu pracy, ale dzięki własnym nieprzyjemnym doświadczeniom doskonale rozumiem osoby narażone na (najczęściej niezamierzone) przejawy dyskryminacji.

Dla mnie jako lidera stresującym momentem było dodanie do regularnie żartującego z Kościoła zespołu osoby, która w CV pochwaliła się religią. Ostatecznie jakość wspólnych obiadów nie ucierpiała na odpuszczeniu tego akurat tematu.

Odmienności kulturowej nie należy, rzecz jasna, mylić z brakiem kultury.

9. Przyznawaj się do własnych błędów. Zwłaszcza, jeśli są zabawne.

Dobry humor zawsze w cenie. Poza tym, jak zdążyłam już wspomnieć, wierzę, że uczyć się można nie tylko na własnych błędach, więc te ciekawsze lub zabawne warto pokazać. Wreszcie, jeśli przyznasz się sam, zmniejszasz szanse, że ktoś znajdzie błąd i wprost ci go wytknie 🙂

10. Ciągle się kształć, ale pogódź się z tym, że w pewnych obszarach będziesz wiedzieć mniej od swoich podwładnych.

Lider w projekcie informatycznym musi mieć wiedzę techniczną. Programiści nie szanują szefów, którzy kompletnie nie znają się na rzeczy.

Oczywiście, w skomplikowanym projekcie z dziesięcioma inżynierami trudno się spodziewać, żeby każdy był w stanie zastąpić każdego. Lider nie może wszystkiego zrobić sam, a dziesięciu liderów niekoniecznie stworzy działający projekt. Powinien jednak wiedzieć, czym zajmuje się i na jakim jest etapie każdy z podwładnych. Czy wykonuje swoją pracę wystarczająco dobrze? Dlaczego korzysta z takich, a nie innych rozwiązań?

Jeśli czujesz, że zaczynasz się gubić w pracach programisty lub podprojektu, poproś o prezentację dla laików.

Rada numer 10 zadziała też po odwróceniu:

10′. Pogódź się z tym, że w pewnych obszarach będziesz wiedzieć mniej od swoich podwładnych, ale ciągle się kształć.

—-

Jakie są Wasze doświadczenia w tej dziedzinie? Pominęłam coś ważnego? Napisałam głupoty? Może dla Was liczą się zupełnie inne aspekty? Chętnie poczytam.