S postopno evolucijo Agila se Product Discovery aktivnosti vse bolj selijo v same razvojne teame. (dual-track Agile)
Razloga za to sta dva:
- Agile zagovarja multifunkcijske teame, ki so sposobni brez zunanje pomoči realizirati identificirane PBIje (Product Backlog Item). Takšna sestava teamov eliminira zunanje odvisnosti, ki so pogosto ozka grla v razvojnem procesu.
- Vloga Product Ownerja se počasi izenačuje z vlogo produktnega managerja, kar pomeni, da pod svoje okrilje prevzema tudi product discovery funkcije.
Posledice opisanih sprememb so tako pozitivne kot negativne. Po eni strani razvojnikom ostaja manj časa za sam tehnični razvoj rešitve, po drugi strani pa je njihovo obširnejše sodelovanje z uporabniki vir ustvarjalnih idej, kot posledice boljšega vpogleda v poslovne funkcije. To rezultira v višji motivaciji razvojnikov, ki sedaj rešujejo konkretne probleme s človeškim obrazom.
Tako kot klasični Agilni razvoj, se tudi product discovery izvaja ciklično. Oglejmo si kako ta dva cikla sestaviti in aplicirati na isti razvojni team.
Razvojni cikel
Klasični Agilni cikel se osredotoča na učinkovit razvoj produkta in/ali njegovih funkcionalnosti. Predstavljamo si ga lahko na naslednji način:
- Začnemo s planiranjem, ki se najpogosteje izvaja na Backlog Refinement in Sprint planning dogodkih (Scrum) ali na queue replenishment in release planning dogodkih (Kanban).
- Sledi kvazi linearni proces designa, razvoja in testiranja. Če nismo previdni, ta proces lahko postane mini waterfall v Agilu, kar nikakor ni priporočljivo. Več o tej pasti si lahko preberete v tem članku.
- Funkcionalnosti, ki prestanejo testiranje, so skladne z Definition of Done in jih stranka potrdi, se nato vključijo v produkcijo.
- Sledi faza introspekcije in predlogov izboljšav na nivoju produkta, procesov in osebnih interakcij. Ta se v Scrumu izvede na Sprint Retrospective dogodku. Kanban ekvivalentnega dogodka nima.
- Cikel se nato ponovi z novim planiranjem*…
* Opomba: opis je rahlo poenostavljen, saj se Backlog Refinement dogodki izvajajo tekom celotnega Sprinta.
Product discovery cikel
To je cikel ugotavljanja strankinih potreb ter iskanja in verifikacije zamišljenih rešitev.
Običajno ga vodi produktni trojček, ki ga sestavljajo:
- produktni manager (Product Owner)
- glavni razvojnik (lead developer)
- produktni designer (product designer)
Če delujemo v Kanbanu, zgornji nazivi niso problematični, saj Kanban pretežno ohranja hierarhično strukturo organizacije. V Scrumu pa so vsi člani teama enaki. Poznamo samo razvojnike, Scrum Mastra in Product Ownerja. V tem primeru mora zastopstvo v produktnem trojčku prevzeti eden od izkušenejših designerjev in eden od razvojnikov s čim širšim tehničnim znanjem.
V Discovery dejavnosti so vključeni tudi ostali člani teama, ni pa to njihova primarna dejavnost. Na tej točki lahko pride do trenj, zato je najbolje v naprej določiti minimalen delež časa, ki ga bojo razvojniki posvetili product discovery dejavnostim.
Cilj discovery procesa je čim cenejša verifikacija mogočih rešitev strankinih problemov. Za to se običajno uporablja prototipe, ki so vsaj za razred cenejši od MVPjev. Verificirane rešitve se nato dodajo v Product Backlog in na ta način predajo v razvojni cikel.
Zakaj v produktnem trojčku sodelujejo naštete funkcije?
Vsaka od treh funkcij namreč naslovi določen del produktnih rizikov. Pač glede na svojo specializacijo.
- Produktni manager (Product Owner) obvladuje:
- Business viability risk (ali je produkt skladen z usmeritvijo podjetja)
- Value risk (ali bojo stranke produkt kupile)
- (Glavni) razvojnik obvladuje:
- Feasibility risk (ali je funkcionalnost glede na obstoječe omejitve mogoče razviti)
- Produktni designer obvladuje:
- Usability risk (ali bo stranka zamišljeno rešitev znala uporabiti)
Pripravo prototipov in njihovo verifikacijo s strani strank idealno izvaja celoten razvojni team. Rezultat te dejavnosti je veliko zavrnjenih rešitev (iz katerih se vseeno nekaj naučimo) in nekaj potencialnih rešitev, ki se jih splača predati v razvojni cikel, kjer se s feedbackom stranke skozi iteracije rafinirajo dalje. Razviti razvojni teami tedensko pripravijo in verificirajo tudi do pet prototipov.
Dual-track Agile: združevanje razvojnega in discovery cikla
Razvojni in discovery cikel torej izvajajo isti ljudje, tečeta pa vzporedno. Njuna kadenca ni treba da je usklajena, je pa potrebno poskrbeti, da discovery cikel rahlo prehiteva razvojnega, saj njegov output delno polni Product Backlog.
- Product discovery cikel se začne z idejo rešitve za strankin problem.
- Zamišljeno rešitev stranki nato predstavimo v obliki prototipa, ki je lahko le simulacija zamišljene funkcionalnosti. Na primer interaktivna PowerPoint simulacija z gumbi, ki testnega uporabnika vodijo preko zamišljenega zaporedja Android zaslonov. Vrst prototipov obstaja veliko (wizard of Oz, smoke test, fake door…). Njihovo bistvo je v čim cenejši validaciji zamišljene rešitve s stranko.
- Če stranka potrdi potencial zamišljene rešitve, se ideja preda v razvojni cikel kjer se vključi v Product Backlog kot nov PBI. Pozicija PBIja v backlogu je odvisna od njegove poslovne vrednosti.
- Višje kot se omenjeni PBI vzpenja v Product Backlogu, bolj konkretiziran postaja. Za to poskrbi Product Owner, ki zamišljeno rešitev rafinira z deležniki iniciative.
- Sledi klasični Agilni razvojni cikel, ki se zaključi s Sprint Review kjer naročnik realizirano rešitev potrdi (se jo vključi v produkcijo) ali zavrne (se jo kot PBI vrne v Product Backlog).
Člani produktnega trojčka preživijo večino časa v discovery ciklu, medtem, ko ostali člani teama svoj čas delijo med cikloma glede na dogovor. Seveda je razvojni cikel pri njih prevladujoč.
Primer
Demonstrirajmo povedano na imaginarnem primeru razvoja novega kavnega aparata.
Discovery cikel
- Produktni trojček opravi intervjuje z baristi, da ugotovi, kaj jih moti pri trenutnih kavnih aparatih.
- UX designer skicira nov dizajn: večji rezervoar za vodo, samodejno čiščenje, hitrejše segrevanje vode, preprostejši UI.
- Razvojni team (ali njegov del) izdela hiter prototip in na njegovi osnovi pridobi povratne informacije. Izkaže se, da je zamišljen aparat preglobok za standardne pulte in ga bo potrebno preoblikovati.
- Team določi nov design, pripravi prototip in ga ponovno predstavi končnim uporabnikom.
- Na osnovi pozitivnega feedbacka team pripravi specifikacije novega produkta in ga vključi v Product Backlog.
Razvojni cikel
- Razvojniki prevzamejo PBI in začnejo razvijati strojno ter programsko opremo.
- QA člani teama testirajo varnost, zmogljivost in uporabnost.
- DevOps vzpostavi sistem za on-line firmware upgrade.
- Da razvoj nebi zašel v neželjeno smer, se vaka iteracija še vedno preverja s potencialnimi strankami. Ko so ti nad izdelkom navdušeni, gre le ta v proizvodnjo.
Medtem ko del teama ugotavlja, kaj je potrebno, drugi del gradi že potrjeno rešitev. Istočasno produktni trojček že identificira funkcionalnosti, ki jih bojo vključili v verzijo 2.0 svojega produkta. Discovery in razvojni cikel tečeta vzporedno, ne zaporedno.
Zaključek
Na prvi pogled se zdi, da “obremenjevanje” razvojnikov z discovery dejavnostmi zavira razvojni proces. Pri večini organizacij, ki prakticirajo dual-track Agile se je izkazalo, da temu ni tako. Boljši vpogled razvojnikov v strankin problem in poslovni kontekst namreč omogočata učinkovitejši razvoj, ki temelji na prodornejših idejah in bolj prilagojenih rešitvah.
Lahko rečemo da dual-track Agile:
- Omogoča testiranje idej predno začnemo vlagati v konkreten razvoj.
- Preprečuje razvoj produktov in funkcionalnosti, ki jih stranke ne želijo.
- Angažira teame na smiselnih razvojnih aktivnostih, medtem, ko se vzporedno odvija discovery proces. To pomeni tudi, da člani teama, ki niso neposredni razvojniki ostanejo koristno zaposleni.
- Zmanjšuje potrebo po ponavljanju razvoja slabo razumljenih funkcionalnosti (gulf of evaluation).
- Na osnovi konkretnega feedbacka olajšuje prioritizacijo zamišljenih rešitev. S tem tudi zmanjšuje vpliv subjektivnih preferenc odločevalcev.
- Izboljša sodelovanje znotraj teama in odnos s strankami.
- Vzpostavi skupno razumevanje ZAKAJ se produkt razvija. Ne samo kako.
