Początkująca

Dzisiejszy post w dużej mierze będzie się odnosił do specyfiki branży, w której pracuję – stąd jest możliwe, że ci z was, którzy są zainteresowani stricte tematami uczenia się, nie do końca znajdą tu coś dla siebie. Pisząc ten post zastanawiałam się, kto jest jego docelowym odbiorcą – a wyniki moich przemyśleń prezentują się następująco:

1. Ludzie, którzy chcą pracować w roli twórcy wymagań w branży IT, ale nie wiedzą, jak zacząć
2. Ludzie, którzy pracują przy inżynierii wymagań, ale wiedzą, że brakuje im wiedzy technicznej / szukają pomysłów na rozwój swoich umiejętności
3. Ludzie, którzy są ciekawi, jak w zasadzie wygląda praca z wymaganiami w kwestii oprogramowania
4. Ludzie, którzy są specjalistami w roli X, ale zastanawiają się, czy zdobycie doświadczenia w roli pokrewnej pomogłoby im wykonywać swoją pracę lepiej

Jeżeli zaliczasz się do któryś z powyższych, istnieje szansa, że spodoba Ci się ten post, a słownictwo wykorzystywane w branży nie będzie Cię kłuć w oczy. Jeżeli nie – archiwum innych postów pozostaje do Twojej dyspozycji 😉 Ponieważ jednak moim celem zawodowym jest pozycja czołowej specjalistki w kwestii inżynierii wymagań w IT w Polsce (na ekspansję przyjdzie czas po 30.), chcę pisać również o rzeczach związanych z tą branżą – jest to w końcu moja “gwiazda polarna” jeżeli chodzi o dobór rzeczy, których się uczę. 

…

Zmieniając firmę rok temu i dołączając do programu dla młodych liderów w IT moją główną motywacją była możliwość nabycia technicznych umiejętności, które pozwoliłyby mi lepiej wykonywać swoją pracę jako ktoś pracujący przy wymaganiach dla zespołu programistycznego. Taką osobę zwykle nazywa się analitykiem biznesowym, product ownerem, managerem czy innym Product Evangelist Visionary Value Maximizerem  (nigdy nie przestanę zachwycać się tytułami niektórych użytkowników LinkedIn) – a na potrzeby tego posta pozostanę przy nazwie product owner. Życie jak zwykle zweryfikowało moje plany i szykuję się obecnie do kolejnej dużej zmiany – udało mi się za to spędzić 6 miesięcy na rotacji, na której zależało mi chyba najbardziej i przez ten czas pod przewodnictwem naprawdę świetnego mentora uczyłam się testować oprogramowanie.

Dlaczego chciałam spędzić trochę czasu jako testerka? Obserwując znajomych pracujących w rolach QA zdałam sobie sprawę, że zarówno testerzy jak i “produktowcy” powinni dzielić ze sobą kilka przydatnych umiejętności, choć będą je wykorzystywać w różnych celach. Dla kogoś, kto chce pracować jako twórca wymagań dla zespołu, rola testera może być dobrym punktem zaczepienia właśnie dlatego, że może nauczyć się następujących rzeczy:

1. Umiejętność odnalezienia “unhappy paths”. Pomijając podejścia “test first”, TDD i im podobne, testerzy będą nakreślać sobie możliwe ścieżki, jakimi może pójść użytkownik oraz to, co może pójść nie tak – ale będą działać “reaktywnie” (czyli znajdować istniejące błędy). Twórcy wymagań za to powinni umieć robić to samo, żeby być pewni, że pokryją możliwie najwięcej scenariuszy w wymaganiach, aby do tych błędów nie dopuszczać. Wygląda więc na to, że do działań po “obu stronach barykady” potrzebne są bardzo podobne umiejętności wczucia się w użytkownika i drążenia “co, jeśli…” do momentu, aż poziom pokrycia scenariuszami lub testami będzie zadowalający. Dodatkowo, w wielu zespołach (a przynajmniej tych zafascynowanych behaviour-driven development)  to właśnie analityk czy product owner jest odpowiedzialny za stworzenie scenariuszy testowych – sami swego czasu próbowaliśmy w poprzedniej firmie tak robić, o czym możecie przeczytać tutaj. Umiejętność wyobrażenia sobie, co może się po drodze spieprzyć przydaje się również na przykład podczas event storming, w którym uczestniczy również product owner.
2. Komunikacja. Bycie testerem wymaga – o czym się przekonałam na własnej skórze – naprawdę dobrych umiejętności komunikacji. Tyczy się to zarówno rozmów o funkcjonalnościach, wyjaśniania nieścisłości, jak i negocjacji z developerami czy właśnie managerami / product ownerami w kwestii tego, jakie defekty należy naprawić, a jakie można pominąć. Umiejętność ta jest również niezbędna w momencie, kiedy znalezione błędy musimy udokumentować – “wczucie” się w osobę, która dany błąd będzie naprawiać i zrozumienie, czego będzie do tego potrzebować (zrzutów ekranu, komunikatu o błędach, informacji o środowisku, na którym dany błąd wystąpił, kroków, które należy podjąć, żeby dany błąd zreprodukować itd.) to kolejna rzecz, której starałam się przez te kilka miesięcy nauczyć.
3. Tłumaczenie skomplikowanych rzeczy w prosty sposób. Jednym z zadań testerów jest często tworzenie dokumentacji testów – zarówno konkretnej funkcjonalności, jak i na przykład testów regresyjnych. W moim przypadku było to szczególnie istotne, ponieważ pracowaliśmy w jednym, dużym zespole, który miał kilka swoich “wewnętrznych” projektów. Zarówno developerzy jak i testerzy byli często przerzucani między nimi, stąd też dokumentacja musiała być napisana tak, żeby pomogła w szybkim wdrożeniu osób, które nad danymi funkcjonalnościami nie pracowały od początku. Podobna umiejętność przydaje się twórcy wymagań zarówno podczas tworzenia historyjek użytkownika, jak i dyskusji z zespołem czy ze stakeholderami na temat konkretnych funkcjonalności.
4. Umiejętności techniczne. Przez 6 miesięcy bycia testerką miałam okazję zobaczyć, jak działa system do automatyzacji testów (i czym w ogóle ta automatyzacja testów jest), testować API, odświeżyć moją znajomość SQL-a, zobaczyć trochę schematów architektury, “osłuchać się” z językiem technicznym i napisać skrypt do webscrapingu, kiedy niektórych danych potrzebnych do udokumentowania błędu nie mogłam wyciągnąć z bazy. Chociaż w większości projektów product owner nie musi być specjalistą od tworzenia oprogramowania, to z moich doświadczeń wynika, że zakres jego umiejętności technicznych jest wprost proporcjonalny nie tylko do jego umiejętności stworzenia dobrych scenariuszy działania użytkownika aplikacji, ale również do szacunku, jakim darzy go zespół, z którym pracuje.

…

Koniec końców, jestem z tego doświadczenia naprawdę bardzo zadowolona, bo zdecydowanie widzę różnicę w swoich umiejętnościach produktowych “przed” i “po”. Oprócz tego, o czym pisałam powyżej, nauczyłam się również między innymi:

1. Nigdy nie zakładać, że coś jest zrozumiałe dla wszystkich – lub że ktoś wie o czymś, o czym my wiemy. Tyczy się to zarówno spraw dotyczących działania konkretnej funkcjonalności, jak i zachowania się konkretnych osób. Wpisuje się to trochę w filozofię płynącą z książki Radical Candor, którą obecnie czytam – lepiej powiedzieć coś, co wydaje się oczywiste i upewnić się, że dana osoba jest tego świadoma, niż zakładać, że tak jest i mocno się przejechać, jeżeli się mylimy.
2. Spróbować rozwiązać problem sama, zanim poproszę o pomoc – ale jeżeli w rozsądnym czasie nie jestem w stanie nic sensownego zrobić, to jednak o tą pomoc należy poprosić. Zdałam sobie sprawę, że mam problem z tym, że jak się uprę na rozwiązanie jakiegoś problemu, to będę nad nim siedzieć do skutku – ale poproszenie innych o pomoc często jest w moich oczach synonimem porażki. Jak się jednak okazało, zdecydowanie więcej rzeczy spartoliłam przez swoją dumę, niż przez swój brak umiejętności, stąd też ta rotacja nauczyła mnie, że warto tę dumę schować do kieszeni i nie bać się prosić o pomoc, jak i zadawać pytania dotąd, aż rzeczywiście zrozumiem, o co w danym problemie chodzi.
3. Da się nauczyć czerpać przyjemność z zadań, które są nudne, jeżeli czegoś się z nich uczymy. Każdy, kto miał okazję przeprowadzać po raz kolejny manualne testy regresyjne aplikacji raczej zgodzi się ze mną, że zabawy w tym niewiele. Takich zadań podczas tej rotacji było całkiem sporo i chociaż motywacji do wykonania tych rzeczy miałam okrągłe zero (poza tą, że moją pasją jest nieumieranie z głodu), to ich skończenie przychodziło mi łatwiej, jeżeli zapisywałam sobie coś, czego się nauczyłam w trakcie – a coś takiego zawsze można znaleźć.

…

Pomysł przejścia od testera do product ownera nie jest najwyraźniej moim własnym wynalazkiem (można o tym na przykład przeczytać tutaj lub posłuchać tutaj). Sama na ten moment najpewniej polecałabym zacząć od tej roli osobom, które uważają, że chcą kiedyś pracować z wymaganiami, ale nie chcą wrzucać się na głęboką wodę i szukać od razu pracy jako PO (już pomijając, że będąc osobą niedoświadczoną, odsetek odpowiedzi na wysłane CV będzie niższy niż wynik Korwina w poprzednich wyborach parlamentarnych). Rola PO (jak sporo innych ról zresztą) to trochę rola rekurencyjna – żeby pracować jako product owner musisz pracować jako product owner i często łatwiej będzie przenieść się wewnętrznie z innej roli, niż startować od zupełnego zera. 

To doświadczenie dało mi do myślenia również w kontekście jednego z moich poprzednich postów o T-shaped skills – chcąc być specjalistą w danej dziedzinie często tym, co nas wyróżni, będzie posiadanie umiejętności pokrewnych – a testowanie jest właśnie czymś takim dla umiejętności tworzenia wymagań dla zespołu. Nie jestem jeszcze co prawda product ownerką z dużym doświadczeniem (choć gwiazdy wskazują na to, że będzie się to szybko zmieniać – szczegóły w przyszłym miesiącu ( ͡° ͜ʖ ͡°)) ale polecałabym zaangażować się w testowanie tym, którzy jako product ownerowie już pracują – może w formie krótkiej “rotacji” (pamiętam, że moja poprzednia firma coś takiego organizowała)? Niezależnie od roli, którą pełnicie, zainteresowanie się rolą pokrewną może najprawdopodobniej pokazać Wam inną perspektywę patrzenia na te same zadania i postawienia sobie pytań, nad którymi się wcześniej nie zastanawialiście. Ja swoją rotację testerską zakończyłam i poza szlifowaniem core’owych umiejętności product ownera zamierzam odświeżyć swoje skille programistyczne – o czym również będę z pewnością pisać w nadchodzących postach.