Programowanie jest fajne. Jako programi\u015bci dostajemy problem do rozwi\u0105zania, zastanawiamy si\u0119 nad realizacj\u0105, a jak ju\u017c wymy\u015blimy, jak to zrobi\u0107 \u2013 cz\u0119sto ucz\u0105c si\u0119 nowych rzeczy \u2013 dostarczamy dzia\u0142aj\u0105cy kawa\u0142ek cyfrowego produktu.<\/p>\n\n\n\n
A jak co\u015b dzia\u0142a, to daje nam satysfakcj\u0119. Dotykaj\u0105c r\u00f3\u017cnych obszar\u00f3w z dziedziny wytwarzania oprogramowania, poznajemy coraz wi\u0119cej narz\u0119dzi, technologii i zagadnie\u0144. Naturalnym, kolejnym krokiem w zawodowej \u015bcie\u017cce programisty wydaje si\u0119 zostanie Liderem Technicznym, a nast\u0119pnie, prawdopodobnie, Architektem.<\/p>\n\n\n\n
Obj\u0119cie takiej roli zazwyczaj wi\u0105\u017ce si\u0119 ze zmian\u0105 tego, na czym polega nasza codzienna praca. Okazuje si\u0119, \u017ce trzeba wi\u0119cej rozmawia\u0107 z lud\u017ami, wi\u0119cej planowa\u0107 i organizowa\u0107. I tutaj pojawiaj\u0105 si\u0119 dwie mo\u017cliwo\u015bci.<\/p>\n\n\n\n
Cho\u0107 powy\u017csze stwierdzenie mo\u017cna uzna\u0107 za \u017cart, wielu z nas rzeczywi\u015bcie preferuje otrzymanie dobrze opisanego zadania, z kt\u00f3rym mo\u017cna zasi\u0105\u015b\u0107 w zaciszu swojego biurka i po prostu je wykona\u0107. Najlepiej tak, aby o nic nie trzeba by\u0142o ju\u017c pyta\u0107. Bycie liderem wymaga jednak czego\u015b wi\u0119cej. O ile wiedza techniczna jest tutaj bardzo potrzebna, to tym, co liczy si\u0119 r\u00f3wnie mocno albo nawet bardziej, jest szersze spojrzenie na wytwarzany produkt i wzi\u0119cie odpowiedzialno\u015bci za to, jak b\u0119dzie on ostatecznie wygl\u0105da\u0142 \u2013 zar\u00f3wno technologicznie, jak i biznesowo.<\/p>\n\n\n\n
Pr\u00f3ba p\u00f3j\u015bcia t\u0105 \u015bcie\u017ck\u0105 mo\u017ce u\u015bwiadomi\u0107 nam, \u017ce jednak nie chcemy tego robi\u0107, gdy\u017c wolimy realizowa\u0107 to, co kto\u015b dla nas wst\u0119pnie przygotuje. Mo\u017ce by\u0107 te\u017c wr\u0119cz przeciwnie \u2013 odkryjemy, \u017ce czujemy si\u0119 dobrze, kiedy to my mamy realny wp\u0142yw na wytwarzany produkt.<\/p>\n\n\n\n
Prawie ka\u017cdy programista w pewnym momencie dochodzi do wniosku, \u017ce naprodukowa\u0142 ju\u017c tyle kodu, \u017ce pora na jak\u0105\u015b zmian\u0119. Mo\u017ce wi\u0119c zacz\u0105\u0107 rozwija\u0107 si\u0119 w kierunku wspomnianego wcze\u015bniej architekta? B\u0119dzie si\u0119 to wi\u0105za\u0142o z konieczno\u015bci\u0105 bycia na bie\u017c\u0105co z ci\u0105gle pojawiaj\u0105cymi si\u0119 nowymi technologiami i rozwi\u0105zaniami.<\/p>\n\n\n\n
Uczenie si\u0119 i ci\u0105g\u0142e doskonalenie umiej\u0119tno\u015bci jest nieodzownym elementem pracy ka\u017cdego specjalisty w bran\u017cy IT. Cz\u0119sto jednak spotyka si\u0119 programist\u00f3w z wieloletnim sta\u017cem, twierdz\u0105cych, \u017ce s\u0105 ju\u017c \u201eza starzy\u201d, aby nad\u0105\u017cy\u0107 za ci\u0105g\u0142ymi nowinkami. Jednocze\u015bnie, posiadana wiedza i do\u015bwiadczenie sk\u0142aniaj\u0105 do podj\u0119cia krok\u00f3w w kierunku zarz\u0105dzania projektami IT. Alternatywnie \u2013 co najmniej odci\u0119cia si\u0119 od programowania i przesuni\u0119ciu si\u0119 poziom wy\u017cej \u2013 do fazy projektowania, analizy i definiowania wymaga\u0144.<\/p>\n\n\n\n
Kiedy wskoczy si\u0119 w buty Analityka, maj\u0105c do\u015bwiadczeniem programisty, du\u017co \u0142atwiej wyobrazi\u0107 sobie, jak wygl\u0105da techniczna realizacja biznesowego wymagania Stakeholder\u00f3w. Przek\u0142adanie User Stories na konkretne wymagania i zadania w Backlogu mo\u017ce by\u0107 bardziej efektywne, gdy\u017c u\u017cywany j\u0119zyk, najprawdopodobniej, b\u0119dzie prostszy do zrozumienia dla programist\u00f3w.<\/p>\n\n\n\n
Je\u015bli wszystko p\u00f3jdzie dobrze, a Analityk znajdzie uznanie i zdob\u0119dzie zaufanie strony biznesowej, to nierzadko dostaje propozycj\u0119 obj\u0119cia dodatkowo funkcji Product Ownera. \u0141\u0105czy wi\u0119c teraz dwie role i dodatkowo posiada \u201ebaga\u017c\u201d wiedzy i do\u015bwiadczenia programisty. O tym, czym si\u0119 r\u00f3\u017cni zakres obowi\u0105zk\u00f3w Analityka od tych nale\u017c\u0105cych do Product Ownera<\/a>, przeczytacie w artykule dot. obu stanowisk.<\/p>\n\n\n\n Teraz natomiast zastan\u00f3wmy si\u0119, czy kto\u015b, b\u0119d\u0105cy przez wiele lat programist\u0105, sprawdzi si\u0119 w roli PO.<\/p>\n\n\n\n Zak\u0142adamy, \u017ce programista podczas swej wieloletniej przygody z pisaniem kodu mia\u0142 okazj\u0119 pracowa\u0107 w projektach, w kt\u00f3rych mniej lub bardziej skutecznie stosowany by\u0142 Scrum. Co si\u0119 z tym wi\u0105\u017ce \u2013 wsp\u00f3\u0142pracowa\u0142 z Product Ownerem. Dzi\u0119ki temu jest w stanie oceni\u0107 na czym polega ta rola \u2013 co by\u0142o robione dobrze, a czego zabrak\u0142o.<\/p>\n\n\n\n Pokr\u00f3tce przypomnijmy, jakie s\u0105 podstawowe zadania Product Ownera<\/strong>:<\/p>\n\n\n\n Postaram si\u0119 odnie\u015b\u0107 wyzwania stoj\u0105ce przed Product Ownerem do wiedzy i do\u015bwiadczenia, jakie powinien posiada\u0107 programista.<\/p>\n\n\n\n Je\u017celi nie brakuje nam umiej\u0119tno\u015bci komunikacyjnych, rozmawianie z przedstawicielami biznesu nie powinno by\u0107 trudne, ale istnieje ca\u0142kiem realne ryzyko, \u017ce liczba Stakeholder\u00f3w oraz definiowanych przez nich wymaga\u0144 b\u0119dzie wi\u0119ksza ni\u017c mo\u017cliwo\u015bci zespo\u0142u.<\/p>\n\n\n\n W tym momencie musimy umie\u0107 wybra\u0107 i wynegocjowa\u0107 zakres, dzi\u0119ki kt\u00f3remu produkt w naszej opinii jest mo\u017cliwie najbli\u017cszy realnym potrzebom u\u017cytkownik\u00f3w.<\/p>\n\n\n\n Mo\u017cna to por\u00f3wna\u0107 do sytuacji, kiedy programista ma ograniczony czas na realizacj\u0119 zadania i dostarcza rozwi\u0105zanie wystarczaj\u0105co dobre<\/strong> \u2013 spe\u0142niaj\u0105ce za\u0142o\u017cenia Definiton of Done \u2013 ale nie takie jak pocz\u0105tkowo zak\u0142adano \u2013 np. pojawi\u0142 si\u0119 pomys\u0142 na u\u017cycie jakiej\u015b nowszej technologii, kt\u00f3ra jednak nie by\u0142a mu dobrze znana.<\/p>\n\n\n\n Rozmowa z zespo\u0142em i prezentowanie wizji z biznesowego punktu widzenia, por\u00f3wnana mo\u017ce by\u0107 z wizj\u0105 architektury czy rozwi\u0105zania technicznego w dostarczanym systemie.<\/p>\n\n\n\n Tutaj mo\u017ce si\u0119 pojawi\u0107 pierwszy problem: ze wzgl\u0119du na wcze\u015bniejsze do\u015bwiadczenie z technologi\u0105 \u2013 Product Owner, b\u0119dacy ex-programist\u0105, mo\u017ce sugerowa\u0107 konkretne rozwi\u0105zania<\/strong> \u2013 co z za\u0142o\u017cenia nie powinno mie\u0107 miejsca. Z drugiej jednak strony, mo\u017ce by\u0107 to cenna wiedza, dzi\u0119ki kt\u00f3rej zesp\u00f3\u0142 zaoszcz\u0119dzi troch\u0119 czasu, je\u015bli sam nie ma pomys\u0142u.<\/p>\n\n\n\n User Stories mog\u0105 by\u0107 napisane tak, aby biznes m\u00f3g\u0142 je zweryfikowa\u0107 oraz aby zesp\u00f3\u0142 deweloperski je rozumia\u0142. Product Owner mo\u017ce jednak p\u00f3j\u015b\u0107 krok dalej i sam rozbi\u0107 je na bardziej szczeg\u00f3\u0142owe zadania<\/strong>. Mo\u017ce to jednak by\u0107 kolejnym problem, poniewa\u017c znowu \u2013 to zesp\u00f3\u0142 deweloperski powinien decydowa\u0107, jak co\u015b zostanie zrobione.<\/p>\n\n\n\n Kiedy odbywa si\u0119 planowanie i uszczeg\u00f3\u0142awianie wymaga\u0144 (refinementy), ex-programista nie ma problemu z wyt\u0142umaczeniem, czym jest usuwanie d\u0142ugu technicznego. Rozumie zasadno\u015b\u0107 pisania test\u00f3w jednostkowych oraz potrafi oceni\u0107 wszelkiego rodzaju zadania dodatkowe, kt\u00f3re pozornie nie maj\u0105 warto\u015bci same w sobie, ale s\u0105 konieczne do osi\u0105gni\u0119cia sukcesu w dostarczeniu dzia\u0142aj\u0105cego produktu. \u0141atwiej mu te\u017c zrozumie\u0107 sk\u0105d wynika ich czasoch\u0142onno\u015b\u0107 i skomplikowanie wyra\u017cone w Story Pointach.<\/strong> Lepiej mo\u017cna zatem przewidzie\u0107 czas dostarczenia kolejnych element\u00f3w rozwi\u0105zania.<\/p>\n\n\n\n O ile proponowanie pewnych konkretnych sposob\u00f3w realizacji czy narz\u0119dzi nie jest takie z\u0142e, zdarzy\u0107 si\u0119 mo\u017ce, \u017ce z jakiego\u015b powodu zesp\u00f3\u0142 nie mo\u017ce sobie poradzi\u0107 z niekt\u00f3rymi zadaniami \u2013 najcz\u0119\u015bciej z powodu braku czasu. Istnieje ryzyko<\/strong>, \u017ce to sam Product Owner mo\u017ce spr\u00f3bowa\u0107 dostarczy\u0107 ca\u0142e rozwi\u0105zanie. Czy jest w tym co\u015b z\u0142ego? Niby nie, ale dlaczego zostali\u015bmy Product Ownerem? Czy nie po to, \u017ceby odej\u015b\u0107 od programowania?<\/p>\n\n\n\n Jak cz\u0119sto mo\u017cna wyczyta\u0107, Scrum<\/strong> to nie jest metoda prowadzenia projektu, a \u201ejedynie\u201d zbi\u00f3r zasad jak post\u0119powa\u0107<\/strong>, aby zwi\u0119kszy\u0107 szans\u0119 na dostarczenie warto\u015bciowego produktu.<\/p>\n\n\n\n I chocia\u017c zak\u0142ada si\u0119 r\u00f3wnie\u017c, \u017ce nie powinno si\u0119 wybiera\u0107 ze Scruma tylko tych element\u00f3w, kt\u00f3re nam pasuj\u0105 (a odrzuca\u0107 tych niewygodnych), bardzo cz\u0119sto organizacje wychodz\u0105 troch\u0119 poza ramy, aby zaadresowa\u0107 swoje realne potrzeby. Zw\u0142aszcza w wi\u0119kszych projektach tworzone s\u0105 stanowiska tzw. Technical Product Owner\u00f3w<\/strong>, w kt\u00f3rych osoba taka zazwyczaj odpowiada w pe\u0142ni za jeden lub kilka komponent\u00f3w \u2013 zar\u00f3wno za funkcjonalno\u015b\u0107, jak i techniczn\u0105 stron\u0119<\/strong>.<\/p>\n\n\n\n W takiej roli programista mo\u017ce si\u0119 odnale\u017a\u0107 ca\u0142kiem nie\u017ale<\/strong>. Mo\u017cna poczu\u0107 odpowiedzialno\u015b\u0107 za zakres, by\u0107 cz\u0119\u015bci\u0105 procesu decyzyjnego, a jednocze\u015bnie nie odcina\u0107 si\u0119 od tej in\u017cynierskiej cz\u0105stki, kt\u00f3ra gdzie\u015b tam w nas siedzi ju\u017c na dobre.<\/p>\n\n\n\n Podsumowuj\u0105c: Tak \u2013 zdeterminowany programista da rad\u0119<\/strong>, ale tym, czego mo\u017ce zabrakn\u0105\u0107, aby by\u0142 bardzo dobrym (ale nie technicznym) Product Ownerem, mo\u017ce by\u0107 niedob\u00f3r wiedzy dziedzinowej, bardziej biznesowe spojrzenie na produkt i nieumiej\u0119tno\u015b\u0107 odci\u0119cia si\u0119 od ingerowania w cz\u0119\u015b\u0107 techniczn\u0105 \u2013 bo programowanie jest fajne! ?<\/p>\n\n\n\n PS. Wszystko, co zosta\u0142o tutaj opisane, bazuje na do\u015bwiadczeniu w\u0142asnym i kilku znajomych z bran\u017cy. Nie jest poparte \u017cadnymi badaniami. Je\u017celi macie inne do\u015bwiadczenia lub ciekawe przemy\u015blenia, zapraszam do podzielenia si\u0119 nimi w komentarzach.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli chcecie dowiedzie\u0107 si\u0119 wi\u0119cej o roli Team Leadera<\/a>, Sprawdzaj\u0105cych technicznie<\/a>, Agile Coacha<\/a> i Resource Managera<\/a>, zach\u0119camy do lektury artyku\u0142\u00f3w naszych specjalist\u00f3w.<\/p>\n\n\nCo programista mo\u017ce wiedzie\u0107 o roli Product Ownera?<\/h2>\n\n\n\n
\n
A jak by sobie z tym poradzi\u0142 programista?<\/h2>\n\n\n\n
Negocjowanie zakresu<\/h3>\n\n\n\n
Prezentowanie wizji<\/h3>\n\n\n\n
User Stories<\/h3>\n\n\n\n
Oszacowanie czasu dostarczenia produktu<\/h3>\n\n\n\n
Pokusa dostarczenia produktu<\/h3>\n\n\n\n
Product Owner \u2013 czy to dobry kierunek dla programisty, czy jednak nie?<\/h2>\n\n\n\n