Delujoč prototip spremeni pogovor o razvoju izdelka

Na sestanku se vsi strinjajo, da mora biti nova rešitev »preprosta za uporabo«. Ko jo prvič preizkusijo, pa se pokaže, da so si predstavljali različne stvari. Nekdo pričakuje en korak, drugi dodatno preverjanje, tretji pa opazi, da sistem sploh ne obravnava izjeme, s katero se srečuje vsak teden.

Delujoč prototip omogoči, da te razlike obravnavamo na konkretnem primeru. V skupinski razpravi RE:moat #43 je opisan potek, pri katerem najprej nastane prototip v kodi, oblikovalec pa nato izboljša uporabniško izkušnjo. Isti prototip postane podlaga za sodelovanje, nadaljnji razvoj in postopno uvajanje sprememb.

Za vodje je pri tem pomembno vprašanje: katero negotovost želimo s prototipom razjasniti in kaj moramo preveriti, preden rešitev uporabimo pri resničnem delu?

Skupna predstava nastane med uporabo

Predstavljajmo si, da podjetje razvija interno orodje za odobravanje nabav. To je ponazoritveni primer, ne primer iz epizode.

V opisu procesa piše, da zaposleni odda zahtevek, vodja ga potrdi, finance pa preverijo proračun. Ko ekipa preizkusi prototip, se pojavijo konkretna vprašanja. Kaj vidi zaposleni, če finance zahtevek vrnejo? Kdo lahko spremeni znesek? Ali mora vodja po spremembi ponovno potrditi nakup? Kaj se zgodi, če je odsoten?

O takšnih vprašanjih se je mogoče pogovarjati tudi brez programske opreme. Prototip pa omogoča, da vsi spremljajo isti potek in neposredno pokažejo, kje se zatakne. Namesto več različnih predstav imajo pred sabo nekaj, kar lahko skupaj preverijo.

Njegova uporabnost je odvisna od tega, kaj preizkus vključuje. Če ekipa pokaže samo uspešno oddan zahtevek, še ne ve veliko o vračanju v dopolnitev, spremembah ali napakah.

Vloga oblikovanja je odvisna od odprtega vprašanja

Opisani vrstni red je lahko smiseln, kadar je problem dovolj jasen, prvi preizkus poceni in je mogoče spremembe hitro narediti. Oblikovalec lahko delujoči prototip uporabi za presojo navigacije, razumljivosti korakov in odzivov sistema.

Toda tudi pred prvim prototipom je lahko potrebno raziskovanje. Če ekipa ne ve, kdo bo rešitev uporabljal, kaj želi doseči ali zakaj obstoječi postopek odpoveduje, hiter razvoj kode teh vprašanj ne razreši. Lahko jih samo skrije za prepričljiv vmesnik.

Oblikovalec zato ne sme dobiti zgolj naloge, naj že sprejeto rešitev polepša. Imeti mora prostor, da spremeni vrstni red korakov, opozori na manjkajoče informacije ali predlaga drugačen potek. Enako velja za razvijalce, ki odkrijejo tehnične omejitve, in ljudi iz poslovnega procesa, ki poznajo njegove izjeme.

Za vodjo to pomeni, da pri načrtovanju sodelovanja izhaja iz odprtih vprašanj. Nekatera je mogoče razjasniti s skico, druga s pogovorom z uporabniki, tretja šele z delujočim preizkusom.

Prototip potrebuje jasno opredeljen namen

Pred izdelavo zapišite, kaj želite izvedeti. Pri orodju za nabave bi to lahko bilo: ali zaposleni razume, kaj mora dopolniti, in ali lahko odgovorna oseba odloči brez dodatnega dopisovanja?

Za tak preizkus ne potrebujete nujno vseh povezav z obstoječimi sistemi. Potrebujete dovolj verodostojen potek in reprezentativne primere. Uporabite lahko izmišljene podatke, vendar jasno označite, katere funkcije so simulirane.

Zabeležite tudi, kaj še ni preverjeno: pravice dostopa, ravnanje s podatki, zanesljivost povezav, odziv ob napaki ali delovanje pri večjem številu zahtevkov. Predstavitev brez zapletov lahko hitro ustvari pričakovanje, da je rešitev že pripravljena za uporabo. Seznam odprtih preverjanj pomaga ohraniti realno sliko.

Uvajanje naj vključuje možnost umika

V razpravi je izpostavljeno tudi postopno uvajanje in vračanje sprememb. Praktičen način uporabe te ideje je omejen pilot: določena skupina uporabnikov, jasen obseg dela in oseba, ki spremlja težave ter odloča o nadaljevanju.

Pred začetkom določite, po čem boste presojali rezultat. Pri nabavah bi spremljali nejasne zahtevke, število potrebnih dopolnitev, napačne odobritve in čas do odločitve. Samo število prijav v orodje pove malo o tem, ali je delo lažje.

Pripravite tudi postopek za vrnitev na prejšnji način dela. Vrnitev na prejšnjo različico programa ne izbriše že poslanega sporočila ali izniči izvedenega nakupa. Za takšne posledice potrebujete ločen dogovor, zato naj bo prvi preizkus omejen tudi glede dejanj, ki jih lahko sproži.

Pred naslednjim razvojnim sestankom izberite eno odprto vprašanje in najcenejši preizkus, ki vam lahko pomaga pri odločitvi. Delujoč prototip je vreden izdelave, ko je jasno, kaj se boste iz njega naučili in kako bo to vplivalo na naslednji korak.

Če želite v ekipi preizkusiti takšen način dela z AI, si oglejte GenAI izobraževanja FaciliTribe. V povpraševanju opišite proces ali rešitev, pri kateri bi radi hitreje prišli do uporabnega preizkusa in konkretne povratne informacije.

Izhodišče: skupinska razprava v RE:moat #43. Primer nabav in predlogi za preizkušanje so praktična razdelava teme. Stran epizode · Posnetek pogovora.