Tooteomaniku 8 suurimat viga

Tooteomaniku roll on kõige tähtsam roll tarkvaraarenduse meeskonnas. See roll ei ole kaugeltki lihtne, vastutusvaldkond on suur ja kirju, töökoormus tavaliselt samuti ja nii võibki juhtuda, et kuskilt hakkavad “õmblused kärisema”. Olen kokku pannud kaheksa enim levinud tooteomaniku viga, mis on tootearenduses kõige suurema mõjuga. Et kogu jutt väga negatiivseks ei kisuks, lisasin juurde ka konkreetsed nõuanded kuidas olukordi lahendada.

• Viga nr 1: Tooteomanik ei kogu või ignoreerib lõppkasutajate tagasisidet
• Viga nr 2: Tooteomanik on arendusmeeskonnast kaugel
• Viga nr 3: Tooteomanikul ei ole piisavalt otsustusõigust ja mandaati
• Viga nr 4: Tooteomanik ütleb kõigele “JAH” ning ei oska öelda “EI”
• Viga nr 5: Tooteomanik unustab suure pildi
• Viga nr 6: Tooteomanik teeb liiga detailseid plaane
• Viga nr 7: Tooteomanik ütleb tiimile kuidas nad peaksid töötama
• Viga nr 8: Tooteomanik keskendub toodangule ja mitte tulemusele

Tooteomaniku roll agiilses meeskonnas

Enne tooteomaniku liistule võtmist ja vigade juurde sukeldumist vaatame kiirelt üle agiilse tarkvaraarenduse meeskonna rollid. Rangelt võttes on tegu küll Scrum meeskonnaga, aga aja jooksul on Scrum metoodika rollid laialt levinud ka Scrumist väljaspoole ja tooteomaniku roll on jõudnud pea kõigisse agiilsetesse meeskondadesse.

Agiilse meeskonna rollid jagunevad laias laastus kolmeks:

• Tooteomanik (Product Owner ehk PO)
  Kes annab tootearendusele suuna ja valideerib lahenduse (ja ei ole projektijuht)
• Arendajad (Developers)
  Kes ehitavad kvaliteetse lahenduse, siia kuuluvad nii teenusdisainerid, arhitektid, programmeerijad, testijad, jpt – kõik toodet reaalselt arendavad meeskonnaliikmed
• Scrum Master
  Kes loob efektiivse arendusprotsessi (vt rohkem Kes on Scrum Master?)

Tooteomaniku roll on kõige tähtsam roll agiilses meeskonnas. Just tema õigeaegsed ja läbimõeldud otsused on eduka toote loomise aluseks.

Hea tooteomanik:

• tunneb hästi lõppkasutajaid ja kogub tagasisidet
• vastutab äriväärtuse loomise eest, seades pidevalt prioriteete
• määrab toote visiooni ja ärieesmärgid
• teeb otsuseid selle kohta, mida tootes arendada ja mida mitte
• vastutab selge ja läbipaistva Product Backlogi eest
• jälgib ja analüüsib ärieesmärkide täitmist.

Tooteomaniku vastutus on suur ja tegevusvaldkond kirju, seepärast on mõistetav miks kõiki ülesandeid koguaeg ka täita ei jõua. Osad tooteomaniku tegematajätmised võivad aga olla fataalse mõjuga kogu projektile ja seepärast on neid hea aeg-ajalt meelde tuletada.

Viga nr 1: Tooteomanik ei kogu või ignoreerib lõppkasutajate tagasisidet

Hoolimata sellest, et kasutajakeskne lähenemine on ammuilma laialt levinud ja populariseeritud, kohtab lõppkasutajate arvamuse ignoreerimist üllatavalt palju. Seda esineb nii startuppides kui ka küpsetes toodetes ja see esineb alati vähem või rohkem peidetud kujul. Olukordi on peamiselt kaks:

1. Tooteomanik on kindel, et ta teab täpselt mida kasutajad tahavad ja ei vaevu seda üle kontrollima.
   Sõnades on ta küll loomulikult kasutajate huvile orienteeritud, aga numbrilisi tõestuseid kasutajate huvi kohta olemas ei ole, selle asemel on ainult tooteomaniku sügav isiklik veendumus. Heaks näiteks on siin startupi juht, kes oma ideed potentsiaalsete kasutajatega ei valideeri ja on vankumatult kindel, et tema tootelahendus on algusest peale perfektne. Või riigi suure e-teenuse tooteomanik, kellel on oma ala professionaalina tekkinud omamoodi tunnelnägemine, mis triivib järjest kaugemale tavaliste lõppkasutajate lihtsatest oskustest ja tegelikest vajadustest.
2. Tooteomanik ei tea kuidas täpselt kasutajatelt tagasisidet küsida.
   See on parem variant kui eelmine, sest vähemalt ei ole tooteomanik ignorantne, tal lihtsalt puudub vajalik tööriistakast. Tagasiside kogumise vahendeid ja tööriistu on palju, aga keeruline on valida neist õige variant, mis sobib situatsiooniga. Intensiivse arendustegevuse ajal on efektiivsemad ühed moodused (nt kasutajate testgrupp, intervjuud, jm), küpse toote rahulikuma jätkuarenduse ajal teised (nt rahuloluküsitlused, külastusstatistika, jm). Arvestama peab ka sihtgruppide arvu ja suurustega.

Mida teha?

Küsi eksperdilt nõu (või guugelda) ja vali endale sobivad tööriistad. Alusta läbimõeldud ja süsteemse lõppkasutajate ja huvigruppide tagasiside kogumisega ja muidugi ka tagasiside analüüsiga. Boonusena on sul edaspidi olemas numbrilised tõendid, millega arendusotsuseid põhjendada või näiteks juhatuselt eelarve ressursse taotleda.

Lõpetuseks, ära unusta klassikalist kuldreeglit: “Ärge uskuge mida kasutajad teile ütlevad vaid vaadake mida nad teevad.”

Viga nr 2: Tooteomanik on arendusmeeskonnast kaugel

Projekte, kus tooteomanik arendajaid kas ei näe üldse või näeb väga harva, on tihedamini näha avalikus sektoris ja suuremate projektide korral (riigihanked), aga võib kohata ka erasektoris kui tellija ja täitja on eri ettevõtted.

Klassikaline on järgmine olukord (ja see on väga visa kaduma): tellija tooteomanik suhtleb peamiselt arendusettevõtte IT projektijuhiga (suuremates projektides lisaks ka ärianalüütikutega), kes on osapoolte “tõlgiks”. Arendajatega tooteomanik tavaliselt ei kohtu ega ei suhtle. Selle kohta on väljend, et “arendajaid hoitakse müüri taga”.

Selline “katkise telefoni” stiilis töökorraldus on kaugel agiilsetest põhimõtetest ja pidurdab arendust tohutult, rääkimata “tõlkes kaduma läinud” ja vale funktsionaalsuse loomise kõrgest riskist.

Arendajatel peab olema võimalik küsida arenduste mõtte ja sisu kohta otse allikast ja saada tooteomanikult kiireid ja pädevaid vastuseid. Kui seda võimalust ei ole ja arendust alustatakse pelgalt user story kirjelduse põhjal (mis pole kunagi piisav), siis on sunnitud arendajad ise oma küsimustele vastuseid leiutama. Või nad küsivad oma projektijuhilt, kes ootab viisakalt järgmise suhtluskorrani ja küsib küsimuse tooteomanikult, kes siis vastab ja projektijuht saadab vastuse tagasi arendajale, mis tekitab arendajal juurde kaks uut küsimust ja .. tempot näete?

Mida teha?

Kaasake tooteomanik regulaarsetesse (nt 1x nädalas või üle nädala) arendusmeeskonna planeerimiskoosolekutele, kus arendajatele tutvustatakse järgmiseid arendusi, millega tuleb tööd alustada.

Teiselt poolt kaasake arendajad tooteomanikule suunatud ülevaatekoosolekutele, kus arendajad saavad tooteomanikult otse hinnalist tagasisidet ja saavad vajadusel ka kohapeal hinnata tooteomaniku muudatussoovide keerukust.

Kindlasti looge ühine projekti chat, kus on kohal kogu arendusmeeskond ja tooteomanik, kes saab seal jooksvatele küsimustele kiirelt vastata.

Juhul kui tooteomanik planeerimis- ja ülevaatekoosolekuteks või chatis suhtlemiseks aega alati ei leia, peab ta määrama selleks volitatud inimese (proxyPO) ja andma talle otsusteks vajaliku mandaadi.

Viga nr 3: Tooteomanikul ei ole piisavalt otsustusõigust ja mandaati

Suuremates organisatsioonides võib juhtuda, et tooteomaniku rolli on määratud isik, kellel sisuline otsustusõigus toote arendamise üle tegelikkuses puudub. See tõsiasi ilmneb muidugi kiiresti, sest arendajad ei saa oma küsimustele vastuseid ja tooteomanik väldib otsuste tegemist igal võimalikul moel.

Kui tooteomaniku enamik vastuseid on stiilis “ma räägin selle majas üle ja siis annan teada”, siis on selge, et otsustusõigus on tegelikult kellegil teisel või halvemal juhul puudub tooteomanikul endal julgus otsustada.

Muidugi on teemasid kuhu tuleks aeg-ajalt kaasata tellija laiem ring, aga tooteomanikul peab olema nii tugev visioon ja arusaam tootest, et lõviosa otsuseid julgeb ja oskab ta ise teha.

Mida teha?

Tooteomanik peab endale küsima ja saama otsustamise mandaadi, kas juhatuselt või oma ülemuselt. Kui sellist mandaati ei taheta anda, siis tuleb tegelik otsuste tegija projekti kaasata tooteomaniku rollis või tooteomanik välja vahetada. Kahjuks tuleb tooteomaniku vahetus ette võtta ka siis kui tooteomanikul on täievoliline mandaat küll olemas, aga julgus otsustada puudub.

Viga nr 4: Tooteomanik ütleb kõigele “JAH” ning ei oska öelda “EI”

Seda probleemi esineb ühtlaselt palju kõigis sektorites ja eri suurusega projektides. Arendust teostav ettevõte kurdab, et “klient tahab kõike saada, aga rahakotti piisavalt ei ole” või siis majasisese arendustiimi korral “äripool tahab kõike saada, aga meil inimesi piisavalt ei ole”. Tooteomanik on aga omakorda rahulolematu: “ma tahan ehitada vinget toodet, aga arendajad on nii aeglased” või siis “nad on liiga kallid”.

Kui jätame hetkel kõrvale liiga aeglased ja kallid arendusfirmad (jah, ka neid turul paraku leidub), siis reeglina on siin koht, kus tooteomanik peab ise väga sügavalt ja pikalt peeglisse vaatama.

Allpool on slaid, mille juures veedan tooteomaniku koolitustel päris kaua aega. Pareto printsiip on nagu loodusseadus, mis sobib hästi paljudes eri kontekstides. Siin pildil on peidus kaks sõnumit, üks neist on hea uudis ja teine … mitte nii hea.

Hea uudis on, et “vinge toote” loomiseks ei ole vaja valmis teha 100% võimalikku funktsionaalsust, piisab ainult kõige väärtuslikumatest. Ja rahakott ei pea olema põhjatu.

Teine, karmim reaalsus on, et selle võiduka 20% üles leidmine ja välja valimine on väga keeruline. Isegi 20/80 printsiipi teadvustades peab edukas tooteomanik tegema sadu või isegi tuhandeid õigeid prioritiseerimise otsuseid – milline featuur on väärtuslikum ja milline mitte? Mida teostada ja mida mitte? Millises järjekorras featuure teha? Mida teha põhjalikumalt ja mida minimaalselt? Mille jaoks mul eelarvet jätkub ja mille jaoks mitte?

See on lõputu ja pidev prioriteetide seadmine ja seda peab tegema just tooteomanik ja ei keegi teine.

Mitte ühelgi tooteomanikul ei saa kunagi olema piisavalt eelarvet, et teostada tootes kõik potentsiaalsed ideed ja unistused. See oleks ka täielik raha raiskamine. Tooteomaniku tähtsaim ülesanne on leida üles ja teostada kõige väärtuslikum 20% suurune osa ja jätta ülejäänud 80% tegemata. Tuleb osata öelda “EI”.

Protsendid 20/80 ei pruugi loomulikult alati täpselt sellised olla, aga üldjoontes jääb mõte samaks.

Mida teha?

Siin sobib sama soovitus, mis vea nr 1 juures – kui oled tooteomaniku rollis, siis kogu ja analüüsi pidevalt lõppkasutajate ja teiste huvigruppide tagasisidet (koos numbritega!), tee otsused lähtuvalt toote visioonist ja saadud tagasisidest. Ära kuku rongilt maha, ära loobu prioriteetide seadmisest isegi kui see on tüütu ja raske, tee vähe JAH-otsuseid ja palju EI-otsuseid, ole tugev ja otsusekindel. Ainult nii saab sinust tõeliselt suurepärane tooteomanik 🙂

Viga nr 5: Tooteomanik unustab suure pildi

Kaua aega sama tootega töötanud tooteomanikud võivad märkamatult kinni jääda liiga lühikesse ajahorisonti. Sama võib juhtuda ka detailitäpsust armastava või tehnilise taustaga tooteomaniku korral.

Seepärast on kasulik tõusta aeg-ajalt igapäevatööde tasemest kõrgemale ja vaadata tervikuna üle kogu toote arendussuund, visioon ja ärieesmärgid – kas me liigume ikka õiges suunas, kas product roadmap on realistlik, kas me loome ikka maksimaalset väärtust või äkki oleme kõrvale kaldunud, kas me saavutame seatud ärieesmärgid?

Mida teha?

Korralda regulaarsed toote visioonikoosolekud (nt kord kvartalis), mis oleksid olulised verstapostid ja kus tehakse pikaajalises plaanis vajalikke otsuseid. Suurt pilti ja product roadmapi uuendusi tuleks kindlasti tutvustada ka arendusmeeskonnale ja mitte ainult projekti alguses vaid ka pärast iga suuremat muudatust. Suure pildi mõistmine on arendajatele väga oluline ja väärtuslik.

Viga nr 6: Tooteomanik teeb liiga detailseid plaane

Tooteomaniku loomulik vastutus on toodet planeerida, seda nii pika- kui ka lühiajalises ajaplaanis. Planeerimine on agiilses lähenemises kriitilise tähtsusega, seejuures ei planeerita kogu projekti detailselt ette ära vaid detailidesse minnakse ainult lähituleviku vaates. Kaugemat tulevikku detailselt planeerida ei ole mõtet, sest ootamatud muutused juhtuvad niikuinii varem või hiljem.

Kõik agiilse projekti plaanid on avatud muutustele ja midagi ei ole kivisse raiutud (tavaliselt eelarve siiski on), aga plaanid on alati olemas ja uuendatud (vaata rohkem agiilse planeerimise  kohta Müüt nr 4: Agiilses arenduses ei ole planeerimist).

Samuti ärge kirjutage enne projekti liiga pikka detailanalüüsi dokumenti nagu tehti vanasti kosemeetodi (waterfall) ajastul. See ei tähenda, et korralik analüüs ei oleks enne projekti vajalik. Eelistage pigem eelanalüüsi varianti, mis kaardistab üldiselt kogu vajaliku funktsionaalsuse ja lisab neile ärivajadustest lähtuvad prioriteedid, aga ei lähe liiga detailseks.

Agiilses projektis ei nõua tooteomanik enam arendajatelt täht-tähelt detailse lähteülesande dokumendi järgimist nagu vanasti waterfall-projektide korral, selle asemel täpsustatakse detailid enne iga arendustsükli algust ja kirjutatakse Product Backlogi (mis on oma olemuselt samuti dokumentatsiooni osa). Selline lähenemine annab võimaluse jooksvalt kohaneda uute muudatustega ja luua lõppkokkuvõttes oluliselt suuremat väärtust.

Mida teha?

Rakendage toote lähteülesande loomisel agiilseid põhimõtteid ja projekti kestel agiilset planeerimist. Võtke ootamatud muudatused teadlikult ja rahulikult vastu ning  kohendage plaane vastavalt.

Viga nr 7: Tooteomanik ütleb tiimile kuidas nad peaksid töötama

See viga ei pruugi olla nii fataalse mõjuga kui eelmised, aga tööõhkkonnale ja motivatsioonile see kindlasti hästi ei mõju.

Agiilse meeskonna rollide vastutus paneb kõik hästi paika:

• tooteomanik vastutab, MIDA ehitatakse
• arendajad vastutavad KUIDAS ehitatakse

(vaata uuesti agiilsete rollide pilti loo alguses)

Tooteomanik peab võimalikult hästi kirjeldama ärivajadusi, mida ja miks on vaja tootes teha. Võimalikke tehnilisi lahendusi on aga tavaliselt mitu ja otsus, milline neist valida, peab olema arendajate kompetentsis.

Arendustöö on väga loominguline ja professionaalne tooteomanik (isegi kui tal on tehniline taust) ei hakka arendajatelt loomerõõmu ära võtma ja oma lahendusi peale suruma. Juba ainuüksi ärivajaduste kirjeldamine on piisavalt mahukas töö.

Mida teha?

Tooteomaniku rollis anna oma parim, et väga täpselt kirjeldada ärivajadusi – kellele ja miks funktsionaalsus kasu toob, millist probleemi see lahendab, milline peab olema oodatav lõpptulemus. Aga ära dikteeri kuidas seda peaks tehniliselt teostama, usalda oma arendajaid. Kasutusmugavuse spetsialistid loovad koostöös programmeerijatega mockup-id ja tooteomanik saab neile tagasisidet ja soovitusi anda.

Viga nr 8: Tooteomanik keskendub toodangule ja mitte tulemusele

Kui tooteomanik teatab uhkusega, et “Minu projekt valmis tähtajaks ja eelarveks!” või “Me püsime alati aasta eelarves!”, siis olen uurinud lähemalt. Kas need olid ainsad mõõdikud, mis olid olulised? Mis oli põhiline edukriteerium? Kui muid mõõdikuid lauale juurde ei tule, siis on asi kehvasti.

Sel juhul ma pole nimelt veendunud, et see toode ikka maailma mingit väärtust juurde loob. Kui seda väärtust ei mõõdetud ja oluliseks ei peetud, siis on paraku tõenäoline, et tulemuseks oli “yet another product”, kehvik kehvikute seas. Oleme tagasi 20 aastat vanas minevikus.

Mida teha?

Määratle ja mõõda ärilisi eesmärke nii uue toote loomisel kui ka jätkuarenduste käigus. Ärilised eesmärgid peavad muuhulgas peegeldama ka toote kasutamise aktiivsust ja kasutajate rahulolu. Ära kunagi unusta valideerida, kas valminud toode ikka on lõppkasutajatele/organisatsioonile/maailmale väärtuslik.

Kokkuvõte

Tooteomaniku roll on keerukas ja nõuab palju pühendumist. Samas on tootearenduse juhtimine IT sektoris üks unistuste töökohti. Kogemused tulevad küll ajaga, aga seni saab õppida teiste vigadest ja püüda neid vältida.

• Viga nr 1: Tooteomanik ei kogu või ignoreerib lõppkasutajate tagasisidet
  Mida teha? Alusta läbimõeldud ja süsteemset tagasiside kogumist ja analüüsimist
• Viga nr 2: Tooteomanik on arendusmeeskonnast kaugel
  Mida teha? Kaasa planeerimis- ja ülevaatekoosolekutele kogu meeskond
• Viga nr 3: Tooteomanikul ei ole piisavalt otsustusõigust ja mandaati
  Mida teha? Taotle vajalikku mandaati või vii läbi tooteomaniku vahetus
• Viga nr 4: Tooteomanik ütleb kõigele “JAH” ning ei oska öelda “EI”
  Mida teha? Tee otsused lähtuvalt toote visioonist ja saadud tagasisidest. Hoia meeles 20/80 printsiipi.
• Viga nr 5: Tooteomanik unustab suure pildi
  Mida teha? Vii sisse regulaarsed visioonikoosolekud korra kvartalis.
• Viga nr 6: Tooteomanik teeb liiga detailseid plaane
  Mida teha? Rakenda agiilset lähenemist planeerimisel ja lähteülesande loomisel
• Viga nr 7: Tooteomanik ütleb tiimile kuidas nad peaksid töötama
  Mida teha? Kirjelda ärivajadusi, aga jäta tehniline lahendus arendajate otsustada
• Viga nr 8: Tooteomanik keskendub toodangule ja mitte tulemusele
  Mida teha? Veendu, et toote ärieesmärgid peegeldavad ka toote kasutamise aktiivsust ja kasutajate rahulolu.

Soovin sulle tooteomaniku rollis edu! Milliseid õppetunde oled sa ise kogenud?