Początkująca

Moimi ulubionymi ludźmi – tak zupełnie personalnie – są ci, którzy są zupełnie zafiksowani na punkcie jakiegoś bardzo specyficznego zainteresowania. Taką osobą jest np. mój chłopak, który buduje konstrukcje z LEGO nawet podczas snu, ale również wiele moich znajomych specjalizujących się np. w astronomii, mechanice, automatyce, górnictwie czy matematyce. Naprawdę, zazdroszczę im tego, co pcha ich naprzód – tego, że potrafią przez długie godziny oddawać się swojej pasji – budować, tworzyć, uczyć się, czytać o bardzo konkretnej rzeczy. Nie jestem pewna, na ile to jest kwestia charakteru, na ile tego, że miało się szczęście odnaleźć to, co ich interesuje, a na ile wynik decyzji, że odtąd będą sterować swoimi zachowaniami tak, żeby poświęcić się konkretnej działce – cokolwiek by to nie było, nie zmienia to faktu, że uwielbiam oglądać ich podczas pracy, słuchać ich opowieści i uczyć się od nich nowych rzeczy w tematach, które ich fascynują.

…

Są też ludzie, których interesuje wszystko – i z definicji nie jest to nic złego, chociaż powiedzenie jack of all trades, master of none ma wydźwięk zdecydowanie negatywny. Zaliczyłabym się właśnie do takiej kategorii i naprawdę nie chcę, żeby było to odebrane jako przechwałki, bo uważam to właśnie w pewnym sensie za swój problem. W swojej biblioteczce mam książki na tematy zupełnie ze sobą niepowiązane, swój czas wolny w weekendy dzielę na hobby których nie rozwijam do mistrzostwa, a jedynie do good enough, bardzo lubię dyskutować na różne tematy, ale wiem, że daleko mi do ekspertki w zdecydowanej większości z nich.

Mój (negatywny) pogląd na tego typu predyspozycje zmienił się chyba najbardziej po przeczytaniu książki Jamesa Cleara “Atomowe nawyki”. Autor wskazuje tam, że często stawiamy sobie w życiu jakiś ambitny cel, który nie do końca jest dopasowany do naszych uwarunkowań fizycznych czy naszego charakteru. Możemy co prawda ciężko pracować nad osiągnięciem mistrzostwa w pewnej wąskiej działce, ale o ile nie mamy pewnych predyspozycji, często możemy się rozczarować osiąganymi wynikami. Sukces można za to osiągnąć wtedy, kiedy obszary, w których czujemy się relatywnie dobrze, połączymy w coś, w czym możemy być najlepsi. W książce pokazane jest to na przykładzie twórcy „Dilberta”, który – jak sam o sobie mówi – jest średnim rysownikiem, średnim komikiem, ale niewiele osób potrafi jako-tako rysować i jako-tako opowiadać żarty. Mając dodatkowo doświadczenie w korporacji ma on materiał do komiksów, które wielu z nas lubi przeglądać przy porannej korpokawie. Z tego podejścia do życia, chęci nauki nowych rzeczy i łączenia wielu różnych dziedzin w pracy wywodzi się zresztą nazwa mojego bloga – Początkująca – i tę cechę mojego charakteru staram się wykorzystać na swoją korzyść. Nie oznacza to, że nie umiem ciężko pracować nad wąską, konkretną dziedziną – tylko to, że lepiej czuję się w rolach interdyscyplinarnych, a taka praca przychodzi mi łatwiej i bardziej naturalnie.

Skąd w ogóle ten temat? Stąd, że obserwuję że to, jakim “typem” jesteśmy, przekłada się dość mocno na nasze życie zawodowe. Z racji różnorodności stanowisk, na których pracowałam przez ostatnie kilka lat, miałam okazję rozmawiać zarówno z członkami zespołu deweloperskiego, jak i z managerami różnego szczebla. Pomimo tego, jak bardzo ich praca różni się od siebie, w pewnym sensie denerwują ich podobne rzeczy – w szczególności jest to brak zrozumienia i empatii u tej drugiej strony. I tak, programistów potrafi denerwować to, że manager nie umie wyciągnąć sobie prostego raportu z bazy danych lub nie rozumie, że ta jedna prosta zmiana, której wymaga od zespołu, potrafi pociągnąć za sobą poważne konsekwencje w architekturze lub wymaga refaktoryzacji sporej części kodu. Analitycy czy managerowie z kolei wskazują na zbytnie przywiązanie programistów do tego, żeby budowane przez nich rozwiązania były technicznie efektowne (a niekoniecznie rozwiązywały problem biznesowy) lub na nikłe zainteresowanie domeną i tym, po co tak naprawdę budują to, co budują. Odbija się to również na szacunku, jaki czują do siebie obydwie strony – bo śmieszki z managerów zdarzają się głównie tam, gdzie programiści mają poczucie, że managerowie są odklejeni od rzeczywistości, a śmieszki z programistów tam, gdzie biznes opisuje ich jako ludzi, którzy może i są świetnymi specjalistami, ale nie dowożą – bo na przykład skupieni są na dopracowywaniu swojego rozwiązania tak, żeby działało o 0.01% szybciej. Mając to wszystko na uwadze, pomyślałam, że to, co przez tak długi czas uważałam za swoją wadę jest czymś, co może mnie wyróżnić – i na tej podstawie ustalam sobie swój plan nauki.

…

Modnym ostatnio stwierdzeniem obecnym w korporacyjnym bingo jest “T-shaped person” – są to osoby o wielu umiejętnościach, ale rozwijanych na różnym poziomie. Mają one swoją specjalizację (to ta pionowa “nóżka” w T), w której dążą do osiągnięcia poziomu eksperta, ale jednocześnie posiadają wiedzę na wiele różnych tematów, powiązanych ze stanowiskiem, jakie zajmują. I nawet, jeżeli ta wiedza nie pozwala im np. na samodzielną pracę na stanowisku z obszaru “płytkiej” specjalizacji, to jest ona na takim poziomie, który pozwala im na postawienie się na miejscu osoby, z którą pracują i zrozumienie jej punktu widzenia. Rozmawiając np. z różnymi product managerami często słyszałam, że chociaż nie byliby w stanie napisać danej funkcjonalności sami, to umieją czytać kod, czytać schematy architektury i dokładnie rozumieją, jak działają poszczególne komponenty składające się na ich produkt. Kim Scott w swojej książce Radical Candor określa podobne podejście jako keeping the dirt behind your nails – żeby być efektywnymi i szanowanymi liderami, managerowie powinni uczestniczyć w codziennych zadaniach zespołu, który dane rozwiązanie buduje – choćby przez job shadowing, zdobycie wiedzy o poszczególnych elementach architektury, czy przejrzenie kodu źródłowego. Działa to w obie strony – bo jednocześnie wiem, że wśród programistów czy testerów szczególnie cenione są osoby, które poza umiejętnościami technicznymi posiadają na przykład jakąś wiedzę domenową – a przynajmniej interesują się nią na tyle, żeby w razie niejasności umieć zadawać odważne pytania i upewnić się, że zespół rzeczywiście buduje coś, co rozwiąże problem biznesowy.

Zrozumienie, że kariera, do której dążę, wymaga właśnie tego typu złożenia umiejętności bardzo pomogło mi zaplanować to, w jaki sposób chcę się rozwijać. I tak, specjalizacją nad którą pracuję jest inżynieria wymagań, co samo w sobie można rozbić na wiele komponentów, między innymi:

• Techniki, narzędzia pozwalające na dojście do problemu biznesowego i opracowanie rozwiązania – takie, jak mapowanie wpływu, event storming, wstrzykiwanie funkcjonalności,
• Koncepcje takie, jak np. programowanie sterowane zachowaniami (BDD) i wykorzystanie ich do jasnego sformułowania historyjek użytkownika,
• Tworzenie zrozumiałej dokumentacji, raportów, pomoc w zdefiniowaniu KPI i kryteriów akceptacji
• Frameworki takie, jak Cucumber, JBehave i inne służące do tworzenia scenariuszy testowych,
• Umiejętności miękkie, takie jak aktywne słuchanie, różne podejścia do rozwiązywania problemów itd.

Powyższa lista nie wyczerpuje oczywiście komponentów składających się na opanowanie inżynierii wymagań, może się także znacznie różnić w zależności od domeny i środowiska, w jakim dany analityk biznesowy pracuje. Jeżeli poznaję jakąś ciekawą technikę lub koncepcję, to staram się dodać ją do swojego analitycznego “portfolio”, żeby pogłębić swoją znajomość wybranej przeze mnie specjalizacji.

…

Jednocześnie zdaję sobie sprawę, że żeby robić to efektywnie, muszę mieć wiedzę z wielu różnych dziedzin “wspierających” – i w moim przypadku są to m.in.:

• Programowanie: zarówno front-end jak i back-end
• UX 
• Testowanie (najprawdopodobniej będzie to “najgłębsza z płytkich” umiejętności, bo testowanie bardzo mocno wiąże się z pracą product ownera/analityka biznesowego)
• Deployment aplikacji, zarządzanie środowiskami, infrastrukturą (co pewnie można ubrać w umbrella-term o nazwie DevOps)
• Bazy danych
• Architektura aplikacji
• Cloud computing
• Data science
• Zarządzanie ludźmi
• Prezentacja i przemówienia publiczne
• Angielski biznesowy

Cała ta lista wygląda dość przerażająco, ale tak jak pisałam wyżej – nie zamierzam stać się ekspertką w żadnej z tych dziedzin (ani mieć “bezpośredniego”, praktycznego doświadczenia we wszystkich). W niektórych z nich wystarczy mi solidne zrozumienie, jak coś działa i zobaczenie tego działania w rzeczywistości. Od prawie roku jestem częścią programu managerskiego w GE dla młodych liderów i swoją ścieżkę kreuję właśnie tak, żeby spróbować ‘pobawić się’ jak największą ilością rzeczy – zdążyłam już zbudować MVP swojej własnej aplikacji z wykorzystaniem m.in. Reacta i ElasticSearch, spędziłam ostatnie kilka miesięcy jako testerka aplikacji do monitorowania dostaw sprzętu, a na kolejnej rotacji planuję sprawdzić się jako programistka back-endowa. W poprzedniej firmie byłam scrum masterką, umiem wyciągnąć niezbędne dane z bazy, żeby przygotować raport, skończyłam podyplomówkę z analizy danych, zdarzało mi się przygotowywać mock-upy, a jak trzeba, to improwizuję i piszę rozwiązanie, które pozwoli mi osiągnąć dany cel (tak jak ostatnio, kiedy musiałam na szybko napisać webscraper, żeby uzyskać dane potrzebne mi do dostarczenia wniosków naszej product ownerce).

…

Wiedza o wszystkich tych rzeczach przydaje się z wielu powodów – jestem w stanie zweryfikować, czy dane wymaganie jest wykonalne, jak bardzo jest skomplikowane, ile czasu może zająć oraz o czym powinnam pamiętać tworząc kryteria akceptacji. Na podstawie obserwacji różnych zespołów zdaję sobie również sprawę z tego, że im bardziej ludzie, z którymi pracuję, mają świadomość, że rozumiem “ich świat” i wiem, o czym mówię, tym więcej szacunku do mnie mają i tym bardziej są skłonni pracować razem nad rozwiązaniem danego problemu biznesowego. 

Swoje “I” buduję poprzez czytanie książek o inżynierii wymagań, rozmowy z innymi analitykami czy product managerami, inspiracje z konferencji czy z postów na blogach ‘branżowych’. Swoje “—” komponuję za to na przykład na podstawie rozmów z członkami zespołu, poprzez przegląd stacku technologicznego w różnych projektach w firmie, czytanie ogłoszeń o pracę na interesujących mnie stanowiskach czy dyskusję ze znajomymi programistami i testerami z innych firm. Tak jak w przypadku swojej specjalizacji, każdą umiejętność “płytką” da się (i raczej – powinno się) rozbić na mniejsze, bardziej konkretne elementy – na przykład tak, jak na podstawie roli product managera opisuje to Valentine Stefferz w poście na HackerNoon.

…

Czy wszyscy powinni przejmować się rozwijaniem umiejętności, które nie są stricte związane z ich stanowiskiem pracy? Myślę, że nie – bo w wielu przypadkach mocna ekspertyza i skupienie się tylko na swojej działce jest pożądanym zjawiskiem – ale zaryzykuję stwierdzenie, że w korporacyjnym IT posiadanie dodatkowej wiedzy na tematy pokrewne może być tym, co wyróżni nas na rynku. Oczywiście, jak to zwykle bywa z każdą sensowną ideą, zawsze da się ją sprowadzić do jakiejś dziwnej korporacyjnej metryki i czytałam już o przykładach firm, które badają “T-factor” swoich pracowników – jeżeli uważają, że nie są oni dość interdyscyplinarni, są im przypisywane obowiązkowe kursy online. Całą koncepcję “T-shaped people” wykorzystuje się również podczas budowania zespołów cross-funkcjonalnych, ale to już dość inny temat – mam jednak nadzieję, że sam pomysł pomoże Wam w rozeznaniu, jakie umiejętności powinniście dodać do swojego portfolio.

…

PS testuję nową wtyczkę do subskrypcji e-mail – jeżeli chcesz dostawać powiadomienia e-mailowe o nowych postach, zapisz się poprzez formularz po prawej stronie. Obiecuję zero spamu, a nowe posty tworzę co ok. 2 tygodnie. Weekend spędziłam również na dopracowywaniu różnych elementów bloga, instalacji certyfikatu SSL i tak dalej – jeżeli masz jakieś sugestie, co powinnam poprawić (lub pomysły na kolejne posty) daj mi znać wysyłając mi wiadomość przez formularz w zakładce “Kontakt” 🙂