O koncepcji “T-shaped person”, która pomaga mi w zaplanowaniu własnej nauki

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.

“P” to umiejętności “płytkie”, które dobudowujemy do swojej specjalizacji

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” 🙂