Tęsiant straipsnių ciklą apie Scrum pagrindus laikas papasakoti apie produkto šeimininką (Product Owner). Produkto šeimininkas Scrum komandoje yra atsakinga už tai, KĄ komanda įgyvendins. Taigi ant jo pečių gula atsakomybė išsiaiškinti, aprašyti ir nuolat prioretizuotikuriamą funkcionalumą taip, kad pirmiausiai rinką pasiektų (būtų įgyvendintas) daugiausiai vertės klientui atnešančios funkcijos. Skamba labai paprastai, bet pažiūrėkime kas slypi po šia didžiule atsakomybe.
Produkto užduočių sąrašo valdymas
Produkto šeimininkas yra vienintelis asmuo atsakingas už produkto užduočių sąrašą (Product Backlog). Šis žmogus rūpinasi, kad produkto užduočių sąrašas visada būtų paruoštas, lengvai prieinamas ir matomas visai organizacijai. Visi turi žinoti koks funkcionalumas yra aukščiausio prioriteto tam, kad visi žinotų prie ko reikės dirbti.
Atsakingas vienas žmogus
Idėjos funkcionalumui ateina iš daugelio šaltinių: klientų, pardavėjų, marketingo specialistų, vadovų, techninių žmonių ir t.t. Produkto šeimininkas, turi dirbti su visais jais, išklausyti jų nuomones ir siūlymus. Tačiau tik produkto šeimininko atsakomybėje yra nuspręsti funkcionalumo prioritetą. Taigi produkto šeimininkas yra asmuo, jokiu būdu ne komitetas ar asmenų grupė.
Prioritetai visiems matomi ir suprantami
Visa organizacija turi gerbti produkto šeimininko sprendimus, jeigu nori, jog produkto šeimininkas ir Scrum kompanijai neštų naudos. Niekas negali liepti komandai dirbti pagal kitokius prioritetus ar padaryti „tą mažą užduotėlę”. Komanda visus tokius „prašytojus” turi nukreipti pas produkto šeimininką. Savo ruožtu, produkto šeimininkas turi pasirūpinti, kad jo sprendimai (prioretizuotas Produkto užduočių sąrašas) yra matomas ir suprantamas visai organizacijai. Šis matomumas reikalauja, kad produkto šeimininkas darbą atliktų gerai. Matomumas taip pat padaro šią rolę gan sunkia (visiems reikia viską paaiškinti, su visais susitarti), tačiau be galo svarbia organizacijai, jei įgyvendinta teisingai.
Kas tampa Produktų šeimininkais
Idealiausias produkto šeimininkas be abejo yra užsakovas ar klientas. Tik jis geriausiai supranta, kuris funkcionalumas jam atneš daugiausiai naudos. Tik jis greičiausiai sužino apie besikeičiančią situaciją ir gali atitinkamai reaguoti keičiant produkto užduočių sąrašą. Standartinių projektų atveju gali ne visada pavykti įtikinti klientą skirti tiek laiko, kiek reikalauja produkto šeimininko rolė. Ypač jei tai pirmieji jūsų bandymai projektą vykdyti naudojant Scrum. Šiuo atveju jūsų projektų vadovas, verslo analitikas ar sistemų analitikas turėtų atlikti šią rolę. Kaip ir Scrum meistro atveju, renkantis, kurį žmogų paskirti produkto šeimininku, labiausiai atkreipkite dėmesį ne į jo dabartines pareigas, bet į asmenines savybes ir ar jis sugebės prisiimti atsakomybę bei priimti tuos labai svarbius sprendimus, kuriuos produkto šeimininkas privalo priimti.
Jei jūs kuriate komercinį produktą, jūsų produkto šeimininku galėtų tapti produkto vadovas(Product Manager). Tačiau būkite atidūs, tradicinė produkto vadovo rolė daugiausia fokusuojasi į darbą su išore (rinka, klientais, marketingu). Produkto šeimininkui taip pat reikia dirbti su išore, tačiau jis privalo didelę laiko dalį skirti ir tiesioginiam darbui su komanda. Na, o jei jūs kuriate programinę įrangą, pavyzdžiui kitam organizacijos skyriui, geriausias produkto šeimininkas būtų to skyriaus ar tos verslo funkcijos, kuri automatizuojama, vadovas.
Produkto šeimininko tobulėjimas
Naujiems produktų šeimininkams gerai atlikti jų darbą turėtų padėti Scrum mokytojas – Scrum meistras. Be abejo, patys produktų šeimininkai turėtų būti suinteresuoti skaityti knygas, tinklaraščius, dalyvauti konferencijose ir mokymuose, kad tobulinti savo įgūdžius. Pradedantiesiems produktų šeimininkams galėčiau parekomenduoti šią knygą: „Agile Product Management with Scrum: Creating Products that Customers Love” – Roman Pichler. Taip pat siūlyčiau nuvažiuoti į Scrum sertifikuotų produkto šeimininkų (CSPO) mokymus/sertifikaciją. Na, o Lietuvoje prisijungti prie Agile ir Scrum naudotojų grupės Lietuvoje. Trečiasis susitikimas bus būtent apie Agile reikalavimų valdymą, taigi praktiškai apie pagrindinį produkto šeimininko darbą. Informaciją apie susitikimą paskelbsime netrukus.
Asmeninė patirtis
Man produkto šeimininku teko dirbti nuo pat pirmos dienos kai pradėjome taikyti Scrum Lavasoft kompanijoje Švedijoje, taigi jau treti metai. Iš šios savo patirties galiu pasakyti kad produkto šeimininkui yra sunkiausi du dalykai.
Pirmiausia, yra gan sunku susitarti su visais įtakojančiais tavo produkto užduočių sąrašą, kad visi sutiktų dėl galutinių prioritetų. Tai sunkiausia daryti pradedant Scrum, kai visi dar yra įpratę, jog viską reikia pradėti daryti šiandien ir niekas palaukti negali. Čia padeda paaiškinimai ir mokymai apie darbo procese (Work In Progress) valdymą (užpildžius kelią, tam tikru kiekiu automobilių, pasidaro kamštis) ir apie fokusavimosi prie vienos užduoties (no multitasking) naudą (kai užduotis net pradėta vėliau pabaigiama greičiau).
Antra sunkiausia produkto šeimininko darbo dalis: surasti bendrą kalbą ir darbo metodus su komanda. Reikia susitarti, kad užduotys nebūtų detaliai sudokumentuotos prieš sprintą, kai komandai nelieka net mažiausių klausimų (turime atliktą tradicinę analizės fazę), bet tuo pačiu, kad užduotys būtų ir ne per abstrakčiai aprašytos, kai komandai neaišku nuo ko net pradėti. Kiek pasakoti komandai apie tolimesnį funkcionalumą produkto užduočių sąraše, kad komanda galėtų greitai pateikti funkcionalumo dydžio įvertinimus ir neužstrigtų prie detalių. Mano išvada: šis bendravimas su komanda labai priklauso nuo pačios komandos, taigi atsakymo vienareikšmiško čia nėra. Retrospektyvų metu reikia atvirai diskutuoti koks yra mūsų tikslas, ir kaip mes jo galime pasiekti kartu. Tai atveda prie teisingų atsakymų, susikalbėjimo ir puikių rezultatų. Sėkmės!
Ką gali pridėti/papildyti/pakomentuoti kiti produktų šeimininkai? Gal kažką labai svarbaus užmiršau? Su kažkuo ne visai sutinkate? Lauksiu komentarų.
Kiti Scrum pagrindai ciklo straipsniai: