Po vpeljavi AI je večina produktnih vodij zakopana pod plazom novih funkcionalnosti, ki čakajo na verifikacijo z uporabniki in kasnejši release. Nekatera podjetja ta problem rešujejo tako, da novih funkcionalnosti enostavno več ne testirajo z uporabniki, ampak jih takoj vključijo v produkt. Po načelu, da bosta od desetih novih funkcionalnosti verjetno vsaj dve takšni, ki bosta uporabnikom všeč. Seveda takšen pristop vodi v produkt, ki je funkcionalno prenapihnjen, nepregleden in tehnično neobvladljiv.
V prejšnjem članku sem pokazal, da AI ozkega grla razvoja ni odpravil, ampak ga je premaknil: prototipe zdaj lahko izdelamo hitreje, kot jih lahko preverimo z uporabniki. Zato moramo pred testiranjem določiti, kakšen rezultat želimo doseči, po katerih kazalnikih bomo izbirali med alternativami in kdaj bomo z nadaljnjim razvojem prenehali. AI lahko nekatere oblike testiranja pospeši, vendar še vedno potrebujemo uporabnike za odkrivanje novih potreb, njihove pravilne interpretacije in identifikacijo nepričakovanih odzivov.
Članek je postavil funkcionalne okvirje za testiranje (kako), ni pa naslovil temeljnega vzroka preobremenjenosti produktnega vodje in dela ekipe, ki rešitve preverja z uporabniki in primarno polni product backlog.
Poglejmo si, kaj se glede tega da narediti.
Manjšanje števila članov v razvojnih timih
Klasični Scrum razvojni timi so iz praktičnih razlogov omejeni na deset članov. Običajno so sestavljeni iz 6-8 razvojnikov (arhitekt, programerji, testerji, UX/UI), Scrum Mastra in Product Ownerja.
Pri višjem številu postane medsebojna koordinacija že tako kompleksna, da dodajanje novih članov več ne prinese bistvenega dviga timske produktivnosti. Še več, množica študij navaja, da je optimalno število članov precej nižje od deset. Pogosta referenca glede tega je študija iz leta 1970 kjer Richard Hackman and Neil Vidmar ugotavljata, da so statistično člani najugodnejšo velikost tima ocenili na 4,6 članov. Ker je v praksi težko dobiti funkcionalnega 0,6 člana, se je številka ustalila na 5. To je tudi število članov, ki jih zagovarja Scrum@Scale, ki je dokazano uspešen scaled agile framework.
Ker so z uvedbo AI, razvojniki postali veliko produktivnejši, za ohranjanje kadence, v praksi potrebujemo manj razvojnikov in posledično lahko sestavimo več manjših razvojnih timov.
To organizaciji omogoča:
- širjenje produktnega portfelja brez bistvenega višanja razvojnih stroškov,
- prekvalifikacijo “odvečnih” razvojnikov v deficitarne vloge kot na primer DevOps, AI integrator, AppSec, platformni inženir in legacy code integrator.
Manjšanje razvojnih timov je realna rešitev za organizacije kjer nerazvojne dejavnosti (product discovery) že sedaj opravljajo druge organizacijske strukture. To sicer ni optimalna rešitev, je pa legitimna adaptacija na uvedbo AI.
Kako veliki naj bojo po novem AI podprti razvojni timi?
Tako majhni, da se bo kadenca razvoja rešitev uskladila s kadenco njihovega preverjanja s strani produktnega vodje.
Dodatni pozitivni faktor pri tej rešitvi je tudi večja koordinacijska učinkovitost manjših timov.
Drugačna struktura razvojnih timov
Kot sem omenil v prejšnjem poglavju, naj bi Scrum tim imel deset ali manj članov.
V tipičnem razvojnem timu so do sedaj prevladovali razvojniki. Razlog za to je bil enostavno ta, da je njihova razvojna faza bila časovno najzahtevnejša.
Ravno ta sestava tima je bila do zdaj ena večjih bolečin Scruma. Poglejmo zakaj.
Uspešno usmerjanje razvoja tehnoloških produktov zahteva angažiranost razvojnega tima od identifikacije potreb, pa do predstavitve naročniku in zbiranja povratnih informacij (funkcijski timi*). Ne samo programiranja rešitve.
* Funkcijski timi so tisti, ki lahko funkcionalnost realizirajo čez vse potrebne komponente, od ideje do uporabe. So nasprotje komponentnim timom, ki so organizirani okoli posameznih tehničnih komponent.
Iz tega razloga komponentne time neprestano poizkušamo zamenjati s funkcijskimi, ki so sposobni ohranjanja stika z naročnikom skozi celoten razvojni cikel rešitve.
Problem je v tem, da funkcijski timi za izvajanje omenjenih nalog, med člani potrebujejo tudi analitike (tržnega, poslovnega, podatkovnega), običajno pa tudi predstavnika marketinga, prodaje in operative. V praksi je to vedno pomenilo, da v “pravem” funkcijskem timu, ki bi bil funkcionalnost sposoben pripeljati od ideje do monetizacije, enostavno ni bilo prostora za potrebno število razvojnikov.
Po eni strani je bil klasični Scrum tim torej vedno pod pritiskom, da razvije celotno funkcionalnost od ideje do monetizacije, po drugi pa, da ohranja članstvo znotraj obvladljivih meja. Posledica je bila, da je redko katera organizacija v resnici prakticirala funkcionalne time. Rezultati so bili predvidljivi in so se gibali od tega, da smo razvijali nekaj kar je naročnik razumel drugače, pa do podvajanja dela vzporednih razvojnih timov.
AI je to težavo odpravil. Zaradi višje produktivnosti programerjev, sedaj razvojni tim lahko napolnimo z ostalimi vlogami, ki so potrebne za izvedbo celotnega življenjskega cikla funkcionalnosti in s tem ne prekoračimo praktične omejitve desetih članov.
Osebno zagovarjam to rešitev, ker optimizira delo razvojnih timov na tisto, kar naročnik v resnici potrebuje in želi. Istočasno takšna organizacija omogoča enoznačno vzpostavitev value streams in njihovo relativno neodvisnost, kar povečuje odpornost organizacije.
Produktni vodja je pri tej rešitvi razbremenjen z naslova prevzemanja product discovery aktivnosti v same razvojne time.
