V enem prejšnjih člankov sem se razpisal o nevarnostih vtihotapljanja waterfalla v Agilni razvojni ciklus. Sedaj pa si bomo ogledali širšo sliko in ugotavljali kako organizacije nenamenoma omejujejo Agile z zastarelim procesom produktnega managementa. Ker je produktni management primarni proces večine razvojnih podjetij, si organizacije na ta način pogosto žagajo vejo na kateri sedijo.
Kako običajno delamo
Tipični proces razvoja novega produkta je prikazan na spodnji sliki.
- Začnemo z idejo, ki običajno prihaja od managementa ali končnih uporabnikov.
- Nato relevantni posamezniki in oddelki pripravijo business case, ki je ocena rentabilnosti vlaganja v projekt.
- Podjetje (glede na donosnost) planirane projekte razporedi v roadmap. Ta določa kdaj okvirno se bo določen projekt začel in koliko časa bo trajal. Po zaključku enega projekta, se njegovi resursi preusmerijo v naslednjega.
- Za vsak projekt se definirajo uporabniške zahteve. Običajno se to naredi z anketami, fokusnimi skupinami ter intervjuji s končnimi uporabniki in njihovim vodstvom (če gre za interni projekt).
- Na osnovi zbranih uporabniških zahtev UX designerji določijo uporabniške poti skozi produkt (customer journey). Te so na področju razvoja programske opreme običajno podane v obliki sitemaps in wireframes ter z njimi povezanih person.
- Razvojniki nato zamišljeno rešitev razvijejo (arhitektura, programiranje).
- Razvita rešitev se preda v testiranje.
- Na koncu se testirana koda vključi v produkcijo.
Vloge so v tem procesu razdeljene kot na sliki:
Če opisana organizacija slučajno “prakticira” Agile, je ta pri opisanem pristopu zreduciran na korak v drugače prevladujočem waterfall procesu razvoja produkta. Takšno podjetje žanje le del prednosti, ki jih nudi polno razviti Agilni pristop.
Posledice so:
- Višji delež produktov zavrnjenih s strani trga.
- Visoka vlaganja v negotove MVPje.
- Otežkočeno iteriranje produktov, ki so pokazali potencial.
Težave zgornjega procesa si oglejmo po točkah.
Realnost najuspešnejših rešitev na trgu je pokazala, da je večina resnično prodornih idej prišla s strani razvojnikov. Končni uporabniki običajno niti ne vejo, kaj vse je tehnično mogoče izvesti, management pa pogosto nima dovolj tesnega stika z uporabniki.
Na tej stopnji je nemogoče planirati višino prihodkov, saj je ta odvisna od primernosti (market fit) in kvalitete zamišljene (še neobstoječe) rešitve. Pravtako je skoraj nemogoče določiti stroške, saj razvojni projekti praviloma operirajo z nepreizkušenimi rešitvami. Poleg tega je za solidno monetizacijo nove rešitve običajno potrebnih nekaj iteracij. Podrobni business case je na tej stopnji nesmiseln. Namesto tega zamišljeno rešitev raje testirajmo s prototipom še predno vanjo vložimo veliko sredstev
Roadmapi na nivoju projektnih portfeljev so omejujoči. Praksa je pokazala, da vsaj 50% idej tržno ne bo uspešnih, tiste, ki pa bojo pokazale potencial, bojo za tržni uspeh potrebovale več iteracij. Roadmapi naj ne bojo časovno omejujoči in naj ne vsebujejo projektov, temveč poslovne probleme, ki jih želimo rešiti. To zaporedje naj bo v skladu s produktno strategijo, ki opisuje korake za dosego produktne vizije (…ki je v skladu z organizacijsko vizijo).
Zbiranje uporabniških zahtev je čisti waterfall produktni management. Zbrane funkcionalnosti se potem vključijo v projektni plan, ki gre v izvedbo.
Takšen način dela ima dve pomanjkljivosti:
- Kot sem že omenil. Uporabniki pogosto ne poznajo najboljših načinov za rešitev problemov.
- Ta pristop je namesto v poslovni rezultat, usmerjen v kvantitativen output (feature factory). Produktni manager mora identificirati uporabniške probleme, ne samo funkcionalnosti, ki jih ti zahtevajo za njihovo rešitev.
To nikakor ne pomeni, da rešitve predlagane s strani uporabnikov ignoriramo. Oni so namreč najbližje problemu. Pomeni le to, da njihove rešitve vrednotimo tudi s stališča širšega znanja in večje količine informacij, ki nam je na voljo.
Delo UX designerjev je zagotovitev, da bojo končni uporabniki z veseljem uporabljali ponujeno rešitev, ter da bo ta razumljiva in intuitivna za uporabo. Na tej stopnji, ko so zahteve že definirane, je UX designer že tako omejen, da več ne more izraziti svojega potenciala. Tako se pogosto lahko omeji le še na UI design in ne na logiko aplikacije, ki bi zagotovila navdušenje uporabnikov.
UX designerji morajo biti v proces razvoja rešitve vključeni od vsega začetka.
Če inženirje organizacija uporablja le za kodiranje, od njih dobi le polovico njihove vrednosti. Inženirji so eni najpametnejših ljudi v organizaciji. Zakaj podjetja ne izkoriščajo njihovega polnega potenciala? Kako pogosto se dogaja, da tehnično odlična aplikacija ne pritegne tržnega zanimanja? Inženirji morajo biti v razvoj produkta vključeni od samega začetka. Najbolje je, da so osebno soočeni z uporabniškim problemom, ki ga nameravajo rešiti.
V tej fazi organizacije običajno začnejo prakticirati “Agile”. Razvoj poteka v Sprintih, kjer se izvajajo določene Scrum ceremonije. Vpetost Agila v predstavljeni waterfall proces produktnega managementa, podjetju nudi le 20% vrednosti obljube Agila.
Testerji naj bi bili del Agilnega teama. Če delujejo kot ločena enota, je to še dodaten korak nazaj. Pogosto v takšnih okoljih programerji ne prakticirajo niti unit testinga, ki je osnova TDD in ga specializirani testerji programerjem v praksi ne morejo pripravljati. V pravih multifunkcionalnih razvojnih teamih se kompetence med seboj delno prekrivajo. Testerji so del razvojnega teama in po potrebi tudi kodirajo. Pravtako pa razvojniki znajo pisati osnovne teste.
Testirano rešitev nato prevzame sistemska administracija ali IT operativa, ki jo integrira v produkcijo. To je zaradi mnogih razvojnih iniciativ v organizaciji lahko zamuden proces, saj ima IT operativa pogosto velik backlog. Ta proces v nekaterih organizacijah traja mesece, kar izjemno zmanjša fleksibilnost in odzivnost rešitve na feedback končnih uporabnikov. Vpeljava DevOps pristopa se organizacijam, kljub zahtevnosti, v tej fazi hitro izplača.
Neprilagojen waterfall produktni management celoten rizik projekta prenesle na konec, ko so sredstva že porabljena. Takšna produktna organizacija dobi kvalitetni (tržni) feedback na svojo rešitev šele na koncu dolgotrajnega procesa, kjer se lahko pokaže, da smo mogoče razvijali napačno rešitev, ali da je ta prekomplicirana za ciljne uporabnike. V takšnem primeru smo zavrgli mesece in mesece dela. Ne samo, da so nas ti meseci stali veliko denarja. Govorimo tudi o opportunity cost. Naši razvojniki bi lahko v tem času namreč razvijali bolje zamišljeno, tržno uspešno rešitev.
Če je bila rešitev delno uspešna, se bo waterfall produktna organizacija (po zapovedi roadmapa) takoj fokusirala na naslednji projekt, namesto da bi iterirala obetajočo rešitev in jo polno monetizirala.
Kako smo prišli v ta položaj?
Z zastarelimi pristopi, ki niso prilagojeni modernemu dinamičnemu in zahtevnemu poslovnemu okolju.
Poleg zgoraj omenjenih, so rešitve:
- Agile naj ne bo omejen le na razvojni proces, ampak naj inženirji sodelujejo tudi v vseh predhodnih fazah od ideacije do iskanja rešitev. Prilagojen proces bi izgledal tako:
Tudi dejavnosti, ki se izvajajo pred konkretnim razvojem produkta, se da izvajati ciklično v Sprintih. Ta proces nam nudi pogoste feedbacke in nam omogoča pravočasno prilagajanje rešitve, pristopa, ciljne skupine, trga ipd..
- Primernost zamišljenega produkta preverjamo s prototipi še pred začetkom razvoja MVPja. MVPji so pogosto dragi. Prototip naj bi bil vsaj za faktor 10 cenejši od MVPja.
- Cilj procesa produktnega razvoja naj bo reševanje uporabniškega/poslovnega problema, ne razvijanje funkcionalnosti.
- Kvalitetna organizacijska in z njo usklajena produktna vizija, ki motivirata in usmerjata delo zaposlenih.
- Pred začetkom konkretnega razvoja (6. korak), mora produktna organizacija odgovoriti na 4 ključna vprašanja:
- Ali bo kupec zamišljeno rešitev pripravljen kupiti?
- Ali zamišljeno rešitev znamo realizirati?
- Ali bo zamišljeno rešitev kupec znal uporabljati?
- Ali naša organizacija podpira razvoj zamišljene rešitve?
Product discovery orodja, ki nam pomagajo odgovoriti na ta vprašanja, so izven obsega članka in so pri mojem delu tema individualnih svetovanj. Pri načinih zbiranja teh informacij imamo veliko svobode. Pomembno pa je, da na zgornja vprašanja odgovorimo predno začnemo vlagati v konkreten razvoj.
Zaključek
Ali opisane tehnike produktnega managementa v resnici lahko smatramo za Agile, ali pa je to le moderni produktni management, ki je kompatibilen za Agilom niti ni preveč pomembno. Ključno je zavedanje, da iz procesa razvoja tehnoloških produktov moramo odstraniti čim več waterfall elementov, ki zamikajo feedback in zvišujejo stroške razvoja.
Ta premik ni tako zahteven, kot se zdi na prvi pogled. Obstaja metoda, ki nam proces od ideacije pa do testiranja prototipa z uporabniki pomaga opraviti v petih dneh. Če koga zanima več, je metoda opisana v knjigi Sprint (Jake Knapp).
