Programowanie jest fajne. Jako programiści dostajemy problem do rozwiązania, zastanawiamy się nad realizacją, a jak już wymyślimy, jak to zrobić – często ucząc się nowych rzeczy – dostarczamy działający kawałek cyfrowego produktu.
A jak coś działa, to daje nam satysfakcję. Dotykając różnych obszarów z dziedziny wytwarzania oprogramowania, poznajemy coraz więcej narzędzi, technologii i zagadnień. Naturalnym, kolejnym krokiem w zawodowej ścieżce programisty wydaje się zostanie Liderem Technicznym, a następnie, prawdopodobnie, Architektem.
Objęcie takiej roli zazwyczaj wiąże się ze zmianą tego, na czym polega nasza codzienna praca. Okazuje się, że trzeba więcej rozmawiać z ludźmi, więcej planować i organizować. I tutaj pojawiają się dwie możliwości.
„Nie po to zostałem programistą, żeby teraz rozmawiać z ludźmi”
Choć powyższe stwierdzenie można uznać za żart, wielu z nas rzeczywiście preferuje otrzymanie dobrze opisanego zadania, z którym można zasiąść w zaciszu swojego biurka i po prostu je wykonać. Najlepiej tak, aby o nic nie trzeba było już pytać. Bycie liderem wymaga jednak czegoś więcej. O ile wiedza techniczna jest tutaj bardzo potrzebna, to tym, co liczy się równie mocno albo nawet bardziej, jest szersze spojrzenie na wytwarzany produkt i wzięcie odpowiedzialności za to, jak będzie on ostatecznie wyglądał – zarówno technologicznie, jak i biznesowo.
Próba pójścia tą ścieżką może uświadomić nam, że jednak nie chcemy tego robić, gdyż wolimy realizować to, co ktoś dla nas wstępnie przygotuje. Może być też wręcz przeciwnie – odkryjemy, że czujemy się dobrze, kiedy to my mamy realny wpływ na wytwarzany produkt.
A może by tak przestać programować i zostać Analitykiem?
Prawie każdy programista w pewnym momencie dochodzi do wniosku, że naprodukował już tyle kodu, że pora na jakąś zmianę. Może więc zacząć rozwijać się w kierunku wspomnianego wcześniej architekta? Będzie się to wiązało z koniecznością bycia na bieżąco z ciągle pojawiającymi się nowymi technologiami i rozwiązaniami.
Uczenie się i ciągłe doskonalenie umiejętności jest nieodzownym elementem pracy każdego specjalisty w branży IT. Często jednak spotyka się programistów z wieloletnim stażem, twierdzących, że są już „za starzy”, aby nadążyć za ciągłymi nowinkami. Jednocześnie, posiadana wiedza i doświadczenie skłaniają do podjęcia kroków w kierunku zarządzania projektami IT. Alternatywnie – co najmniej odcięcia się od programowania i przesunięciu się poziom wyżej – do fazy projektowania, analizy i definiowania wymagań.
Jestem już Analitykiem i co teraz?
Kiedy wskoczy się w buty Analityka, mając doświadczeniem programisty, dużo łatwiej wyobrazić sobie, jak wygląda techniczna realizacja biznesowego wymagania Stakeholderów. Przekładanie User Stories na konkretne wymagania i zadania w Backlogu może być bardziej efektywne, gdyż używany język, najprawdopodobniej, będzie prostszy do zrozumienia dla programistów.
Jeśli wszystko pójdzie dobrze, a Analityk znajdzie uznanie i zdobędzie zaufanie strony biznesowej, to nierzadko dostaje propozycję objęcia dodatkowo funkcji Product Ownera. Łączy więc teraz dwie role i dodatkowo posiada „bagaż” wiedzy i doświadczenia programisty. O tym, czym się różni zakres obowiązków Analityka od tych należących do Product Ownera, przeczytacie w artykule dot. obu stanowisk.
Teraz natomiast zastanówmy się, czy ktoś, będący przez wiele lat programistą, sprawdzi się w roli PO.
Co programista może wiedzieć o roli Product Ownera?
Zakładamy, że programista podczas swej wieloletniej przygody z pisaniem kodu miał okazję pracować w projektach, w których mniej lub bardziej skutecznie stosowany był Scrum. Co się z tym wiąże – współpracował z Product Ownerem. Dzięki temu jest w stanie ocenić na czym polega ta rola – co było robione dobrze, a czego zabrakło.
Pokrótce przypomnijmy, jakie są podstawowe zadania Product Ownera:
- Zbieranie wymagań od Biznesu, ale też proponowanie własnych udoskonaleń na podstawie posiadanej domenowej wiedzy lub przewidywania oczekiwań końcowych użytkowników.
- Komunikowanie zespołowi jakie są cele i wizja produktu.
- Zarządzanie Backlogiem – zespół musi mieć zawsze odpowiednią liczbę gotowych zadań do realizacji. Zadania muszą być dokładnie opisane i ustawione w odpowiedniej kolejności.
- Maksymalizowanie wartości – spośród zazwyczaj długiej listy wymagań trzeba umieć wybrać te, dzięki którym powstający produkt przyniesie największą korzyść np. finansową.
- Monitorowanie postępów i odpowiednia adaptacja dalszej pracy.
A jak by sobie z tym poradził programista?
Postaram się odnieść wyzwania stojące przed Product Ownerem do wiedzy i doświadczenia, jakie powinien posiadać programista.
Negocjowanie zakresu
Jeżeli nie brakuje nam umiejętności komunikacyjnych, rozmawianie z przedstawicielami biznesu nie powinno być trudne, ale istnieje całkiem realne ryzyko, że liczba Stakeholderów oraz definiowanych przez nich wymagań będzie większa niż możliwości zespołu.
W tym momencie musimy umieć wybrać i wynegocjować zakres, dzięki któremu produkt w naszej opinii jest możliwie najbliższy realnym potrzebom użytkowników.
Można to porównać do sytuacji, kiedy programista ma ograniczony czas na realizację zadania i dostarcza rozwiązanie wystarczająco dobre – spełniające założenia Definiton of Done – ale nie takie jak początkowo zakładano – np. pojawił się pomysł na użycie jakiejś nowszej technologii, która jednak nie była mu dobrze znana.
Prezentowanie wizji
Rozmowa z zespołem i prezentowanie wizji z biznesowego punktu widzenia, porównana może być z wizją architektury czy rozwiązania technicznego w dostarczanym systemie.
Tutaj może się pojawić pierwszy problem: ze względu na wcześniejsze doświadczenie z technologią – Product Owner, będacy ex-programistą, może sugerować konkretne rozwiązania – co z założenia nie powinno mieć miejsca. Z drugiej jednak strony, może być to cenna wiedza, dzięki której zespół zaoszczędzi trochę czasu, jeśli sam nie ma pomysłu.
User Stories
User Stories mogą być napisane tak, aby biznes mógł je zweryfikować oraz aby zespół deweloperski je rozumiał. Product Owner może jednak pójść krok dalej i sam rozbić je na bardziej szczegółowe zadania. Może to jednak być kolejnym problem, ponieważ znowu – to zespół deweloperski powinien decydować, jak coś zostanie zrobione.
Oszacowanie czasu dostarczenia produktu
Kiedy odbywa się planowanie i uszczegóławianie wymagań (refinementy), ex-programista nie ma problemu z wytłumaczeniem, czym jest usuwanie długu technicznego. Rozumie zasadność pisania testów jednostkowych oraz potrafi ocenić wszelkiego rodzaju zadania dodatkowe, które pozornie nie mają wartości same w sobie, ale są konieczne do osiągnięcia sukcesu w dostarczeniu działającego produktu. Łatwiej mu też zrozumieć skąd wynika ich czasochłonność i skomplikowanie wyrażone w Story Pointach. Lepiej można zatem przewidzieć czas dostarczenia kolejnych elementów rozwiązania.
Pokusa dostarczenia produktu
O ile proponowanie pewnych konkretnych sposobów realizacji czy narzędzi nie jest takie złe, zdarzyć się może, że z jakiegoś powodu zespół nie może sobie poradzić z niektórymi zadaniami – najczęściej z powodu braku czasu. Istnieje ryzyko, że to sam Product Owner może spróbować dostarczyć całe rozwiązanie. Czy jest w tym coś złego? Niby nie, ale dlaczego zostaliśmy Product Ownerem? Czy nie po to, żeby odejść od programowania?
Product Owner – czy to dobry kierunek dla programisty, czy jednak nie?
Jak często można wyczytać, Scrum to nie jest metoda prowadzenia projektu, a „jedynie” zbiór zasad jak postępować, aby zwiększyć szansę na dostarczenie wartościowego produktu.
I chociaż zakłada się również, że nie powinno się wybierać ze Scruma tylko tych elementów, które nam pasują (a odrzucać tych niewygodnych), bardzo często organizacje wychodzą trochę poza ramy, aby zaadresować swoje realne potrzeby. Zwłaszcza w większych projektach tworzone są stanowiska tzw. Technical Product Ownerów, w których osoba taka zazwyczaj odpowiada w pełni za jeden lub kilka komponentów – zarówno za funkcjonalność, jak i techniczną stronę.
W takiej roli programista może się odnaleźć całkiem nieźle. Można poczuć odpowiedzialność za zakres, być częścią procesu decyzyjnego, a jednocześnie nie odcinać się od tej inżynierskiej cząstki, która gdzieś tam w nas siedzi już na dobre.
Podsumowując: Tak – zdeterminowany programista da radę, ale tym, czego może zabraknąć, aby był bardzo dobrym (ale nie technicznym) Product Ownerem, może być niedobór wiedzy dziedzinowej, bardziej biznesowe spojrzenie na produkt i nieumiejętność odcięcia się od ingerowania w część techniczną – bo programowanie jest fajne! ?
PS. Wszystko, co zostało tutaj opisane, bazuje na doświadczeniu własnym i kilku znajomych z branży. Nie jest poparte żadnymi badaniami. Jeżeli macie inne doświadczenia lub ciekawe przemyślenia, zapraszam do podzielenia się nimi w komentarzach.
***
Jeśli chcecie dowiedzieć się więcej o roli Team Leadera, Sprawdzających technicznie, Agile Coacha i Resource Managera, zachęcamy do lektury artykułów naszych specjalistów.
Fajnie opisane. I jak zawsze są pros i cons takiej ściezki. Jedna mała uwaga:
„…, może być niedobór wiedzy dziedzinowej, bardziej biznesowe spojrzenie na produkt i nieumiejętność odcięcia się od ingerowania w część techniczną – bo programowanie jest fajne! ?”
Ten aspekt dotyczy nie tylko programistów, ale POs’ów w ogóle. Szczególnie brak wiedzy dziedzinowej, stwarza duże trudności w tworzeniu wizji, określaniu celów produktu nie mówiąc o priorytetach.
Pozdr