Vaba mikrofon 3: Tooteomaniku roll agiilses arendusmeeskonnas
Nagu tuntud kõnekäänd ütleb - töö on tellija materjalist. Agiilsetest meeskondadest enamus kasutab scrum arendusmeetodit. Scrum meeskonnas on tooteomanik tellija ehk projekti rahastaja volitatud esindaja. Tooteomaniku roll on:
- tunda lõppkasutajaid ja koguda nende tagasisidet
- määrata toote visioon ja äriväärtused
- vastutada toote äriväärtuse loomise eest ja seada prioriteete
- teha otsuseid, mida arendada
- vastutada selge ja läbipaistva backlogi eest ja seada backlogis prioriteedid
Tihti aga esineb tooteomanikega mitmeid probleeme, mis võivad tuleneda sellest, et omanikul puudub selge arusaam oma rollist arendusmeeskonnas.
Enamlevinumateks võiks tuua järgnevad:
- Probleemid lõppkasutajate soovidest arusaamise ja/või nende edastamisega. Selles osas võib olla mitu suuremat probleemi. Üks neist on see, et tooteomanik on veendunud selles, et ta teab, mida lõppkasutajad soovivad, kuid ei valideeri seda tegelikult kasutajatega või ei võta kasutajate tagasisidet kuulda. Kindlasti ei tasu siin ka unustada head ütlust - "ärge uskuge mida kasutajad teile ütlevad, vaid vaadake, mida nad teevad". Teine probleem võib olla see, et tooteomanikul puudub arusaam kasutajate soovidest või ta ei oska tagasisidet koguda. Mõlema puhul on tulemuseks sisuliselt lõppkasutajate jaoks vale toote arendamine.
- Tooteomanik ütleb arendusmeeskonnale kuidas nad peaksid töötama. Tooteomanikul enamasti pole ning ei peagi olema piisavalt tehnilisi teadmisi, et öelda ette, kuidas mingile probleemile lahendust leida. See peaks jääma arendusmeeskonnale. Tooteomanik peaks keskenduma vaid sellele mida on vaja ja mis järjekorras. Kui lisaks probleemidele lahenduste leidmisele peavad arendajad ka tehniliselt vähem kursis olevatele osapooltele selgitama, miks üks või teine lahendus ei sobi ja kuidas oleks parem, siis kulutab see mõtetult mõlema osapoole aega. Alternatiivina aga lihtsalt ahvikese kombel etteantud lahenduse implementeerimine võib viia nii ebasobiliku lahenduse kasutamise kui ka rahulolematute arendajateni, kes tunnevad, et neist on lihtsalt trükkalid tehtud.
- Tooteomanikul ei ole piisavalt otsustusõigust või julgust otsuseid langetada. Kui tooteomanikul ei ole selget toote visiooni, arusaama oma rollist või piisavalt õiguseid, siis on tulemuseks see, et ta peab pidevalt otsuseid kellegi teisega üle valideerima ning arendusprotsess venib. Tooteomanik muutub sellisel juhul lihtsalt vahendajaks tegeliku otsustaja vahel, kuigi reaalselt peaks temal olema võimalus ja julgus otsustaja olla.
- Tooteomanik ei suuda seada prioriteete. Pareto printsiibi kohaselt tuleb 80% toote väärtusest 20% funktsionaalsusest. Lihtne on kinni jääda "kelladesse ja viledesse" ning öelda, et need kõik on olulised, kuid tulemuseks on kaks rahulolematut poolt - tooteomanik leiab, et arendusmeeskond on aeglane ning arendusmeeskond leiab, et tooteomanik soovib kõike ja korraga saada, isegi kui ressurssi selleks pole. Samuti on halb variant ka prioriteetide pidev muutumine, see põhjustab pidevaid ümberkirjutamisi ja ümberkorraldusi, sest töösolevad ülesanded tuleb pooleli jätta ning tegeleda teistega. Ühelt ülesandelt teisele ümberlülitumine võtab aga alati lisaaega ning lisaks hägustub arendusmeeskonna tootevisioon ning motivatsioon, sest nad ei ole kunagi kindlad, kas see, mis nad teevad, on üldse oluline, või võib see homme juba tähtsusetu olla.
- Tooteomanik unustab suure pildi ja laskub detailidesse. Olgugi, et nii lühi- kui ka pikaajaline planeerimine on ka agiilses meeskonnas oluline, siis ei tasu nendesse kunagi väga kinni jääda, sest alati tuleb silmas pidada, et plaanid võivad muutuda.
Olles ka ise mitmes meeskonnas töötanud ja ka teiste meeskondade tööd kõrvalt näinud, on kindlasti näha, et tooteomaniku rollis võib küll olla keeruline õiget tasakaalu leida, kuid nii hea kui ka halb tooteomanik mõjutab arendusmeeskonna tulemusi üsna tugevalt ühele või teisele poole.
Comments
Post a Comment