Prototyp aplikácie pred vývojom: prečo zadanie nestačí

Firma niekoľko mesiacov pripravuje zadanie. Dokument má vyše sto strán a pripomienkovali ho obchod, prevádzka, financie aj IT. Po podpise zmluvy s dodávateľom nasledujú mesiace vývoja a na prvej ukážke zaznie: „Takto sme to nemysleli.“

Scenár je modelový, no problém za ním je reálny. V medzinárodnom prieskume NaPiRE, ktorý dokončilo 228 organizácií z 10 krajín, respondenti vyberali najkritickejšie problémy pri práci s požiadavkami. Najčastejšie uviedli neúplné alebo skryté požiadavky (48 % respondentov). Komunikačné nedostatky medzi tímom a zákazníkom uviedlo 41 % a v prvej desiatke problémov ich respondenti najčastejšie označili za závažnú príčinu zlyhania projektu.

Rozsiahle zadanie vytvára pocit istoty, no to podstatné sa na ňom otestovať nedá: či ľudia riešeniu porozumejú a zvládnu s ním svoju prácu. Prototyp aplikácie to ukáže za niekoľko dní až týždňov, keď je oprava ešte lacná, a nie až po mesiacoch vývoja.

Prečo podpis pod zadaním nechráni pred nedorozumením

Podpis potvrdzuje súhlas s textom, nie to, že si obe strany pod ním predstavujú to isté. Frederick P. Brooks Jr. v eseji No Silver Bullet z roku 1987 napísal, že najťažšou časťou tvorby softvéru je presne rozhodnúť, čo sa má postaviť, a žiadnu inú časť nie je neskôr ťažšie napraviť. Podľa neho je pre zákazníka v skutočnosti nemožné úplne, presne a správne špecifikovať požiadavky moderného softvéru skôr, než vyskúša niekoľko jeho verzií.

Hrubý dokument tento problém podľa nás skôr zakrýva. S každou stranou rastie pocit úplnosti, no každé oddelenie číta najmä svoju kapitolu a samozrejmosti nenapíše nikto. Prvú spätnú väzbu z niečoho hmatateľného firma dostane, až keď na nedorozumení stojí kód. Brooks v tej istej eseji označil za zásadne chybný predpoklad vtedajšieho obstarávania softvéru, že systém sa dá vopred uspokojivo špecifikovať, vysúťažiť, postaviť a nainštalovať.

Rovnaká veta, rôzne obrazovky

Text sa nedá používať, a preto na ňom neoveríte, či mu všetci rozumejú rovnako. Vezmite modelovú požiadavku „objednávky nad limit schvaľuje vedúci“. Finančná riaditeľka si predstaví ranný prehľad na hromadné schválenie, vedúci skladu upozornenie v mobile, programátor stavové pole v tabuľke. Všetky predstavy sú s vetou v súlade a každá vedie k inej pracnosti aj cene.

Výnimky sa ukážu, až keď sa úloha naozaj vykonáva. Kto schvaľuje, keď je vedúci na dovolenke? Platí schválenie aj po zmene množstva?

Štvrtina respondentov NaPiRE navyše zaradila medzi najkritickejšie problémy to, že zainteresované strany ťažko oddeľujú požiadavky od riešení, ktoré už poznajú. Britská vládna príručka GOV.UK Service Manual radí v discovery fáze, teda pri skúmaní problému ešte pred stavbou, vopred určené riešenie preformulovať na problém: nie „postaviť interaktívnu mapu kontaktných centier“, ale „ako ľuďom uľahčiť nájdenie najbližšieho centra“.

Čo je prototyp a čo nie je

Prototyp je zjednodušená podoba budúceho produktu, na ktorej sa dá riešenie vyskúšať skôr, než sa naprogramuje. Kara Pernice z Nielsen Norman Group ho opisuje ako hypotézu, teda kandidátne riešenie, ktoré sa najpriamejšie overí tak, že sledujete ľudí pri práci s ním. Nie je to minimálny životaschopný produkt (MVP), teda podľa Erica Riesa verzia nového produktu, ktorá tímu s najmenším úsilím prinesie maximum overeného poznania o zákazníkoch. Prototyp je užší nástroj: overuje navrhnuté riešenie ešte pred jeho stavbou.

Vernosť prototypu je podľa Pernice miera, do akej sa podobá výslednému systému, a to v interaktivite, vizuáli aj v obsahu a príkazoch. Pre rozhodnutie pred vývojom v praxi rozlišujeme tri úrovne:

Skica alebo papierový prototyp. Namiesto systému reaguje človek, ktorý návrh pozná a podáva používateľovi ďalšie nakreslené obrazovky. Pri príbuznej metóde Wizard of Oz riadi obrazovku človek z inej miestnosti, takže sa dá vyskúšať aj správanie, ktoré ešte nikto nenaprogramoval. Jakob Nielsen radí papierové prototypovanie medzi najrýchlejšie a najlacnejšie techniky. Hodí sa na overenie základného prístupu a toku.
Klikateľný prototyp. Prepojené obrazovky, ktoré reagujú ako aplikácia, hoci za nimi nič nebeží. Overí, či ľudia zvládnu kľúčové úlohy bez pomoci.
Funkčný prototyp na reálnych dátach. Obmedzený kus skutočného kódu napojený na vzorku dát alebo rizikovú integráciu. Hodí sa, keď neistota nie je v rozhraní, ale v dátach či technológii.

Naše pravidlo výberu: najnižšia vernosť, ktorá ešte odpovie na aktuálnu otázku. Podľa Nielsena má skorý test pred neskorým taký náskok, že prevýši aj rozdiel v kvalite prototypu. Design Kit od IDEO.org počíta pri rýchlom prototypovaní s niekoľkými dňami až týždňami podľa toho, čo sa testuje.

Čo musí prototyp aplikácie preukázať

Prototyp je test, nie prezentácia. Podľa príručky GOV.UK netreba prototypovať celú cestu používateľa, často stačí sústrediť sa na najnáročnejšie časti a otestovať najrizikovejšie predpoklady. Pred vývojom by mal prototyp odpovedať na tieto otázky:

Pochopia ľudia tok? Zvládne úlohu od začiatku do konca aj človek, ktorý pri návrhu nesedel? Každé zaváhanie v teste môže byť v prevádzke telefonát na podporu alebo chyba v objednávke.
Padli kľúčové rozhodnutia? Text dovolí spor odložiť, obrazovka nie. Čo sa rozhodne teraz, nezostane ako neistota v cenovej ponuke.
Obstojí návrh s reálnymi dátami? Skutočné názvy bývajú dlhšie než v ukážke, polia prázdne a záznamy duplicitné.
Funguje najrizikovejšia integrácia? Integrácia je prepojenie s iným systémom, napríklad s účtovníctvom. Britská služba Register to vote by nefungovala bez API, teda rozhrania na výmenu dát, napojeného na registračné systémy viac než 400 miestnych samospráv. Tím sa preto naň sústredil už v alfa fáze, určenej na prototypy.
Prijmú to používatelia? Prototyp adopciu nezaručí, no naznačí, či by ľudia nový postup uprednostnili pred dnešnými obchádzkami. Prečo na tom záleží, rozoberá článok Najdrahší systém je ten, ktorý vaši ľudia nepoužívajú.

Testovanie s používateľmi: pozorovať, nie sa pýtať

Používateľské testovanie znamená, že človek z cieľovej skupiny rieši na prototype reálnu úlohu, napríklad modelové zadanie „vystavte dobropis k tejto faktúre“, a vy sledujete, kde zaváha a čo pochopí inak. Dotazník zachytí, čo si ľudia myslia, že by urobili. Pozorovanie ukáže, čo naozaj urobia.

Jakob Nielsen vychádza z modelu, podľa ktorého prvá štúdia s piatimi účastníkmi odhalí približne 85 % problémov použiteľnosti, teda miest, kde sa ľudia zaseknú alebo pomýlia. Namiesto jednej štúdie s 15 ľuďmi odporúča tri kolá po piatich, lebo každé ďalšie overí opravy a odhalí hlbšie problémy. Platí to pre porovnateľných používateľov: pri dvoch výrazne odlišných skupinách odporúča troch až štyroch ľudí z každej.

Kedy je neskorá zmena naozaj drahá

Cena zmeny je to, koľko stojí úprava rozhodnutia v danej fáze projektu. Barry Boehm a Victor Basili v článku z roku 2001 uviedli, že nájsť a opraviť softvérový problém po dodaní je často 100-krát drahšie než vo fáze požiadaviek a návrhu. Slovo „často“ doplnili zámerne: pri malých nekritických systémoch je pomer podľa nich skôr 5:1. Uviedli tiež, že vtedajšie projekty míňali asi 40 až 50 % úsilia na prepracovanie, ktorému sa dalo vyhnúť, a medzi jeho dva hlavné zdroje zaradili narýchlo špecifikované požiadavky.

Rast ceny s časom však nie je univerzálny. Tim Menzies a spoluautori na 171 projektoch nenašli dôkaz, že by riešenie problémov v neskoršej fáze stálo konzistentne alebo podstatne viac úsilia než krátko po ich vzniku. Išlo pritom prevažne o malé až stredné projekty s metodikou Team Software Process, bez dát z obdobia po dodaní. Autori sami upozorňujú, že efekt sa môže objavovať len pri niektorých typoch projektov.

Podľa nás neskorú zmenu nezdražuje kalendár, ale to, čo na chybnom rozhodnutí medzitým vyrástlo: kód, integrácie, dokumentácia, školenia aj dátový model. Kara Pernice pripomína, že zahodiť kód je veľmi drahé, zahodiť prototyp nie. Neopravené nedorozumenie firma po spustení navyše platí každý deň ako trenie v bežnej práci, ktorého výpočet ukazuje článok Dobrý dizajn nie je dekorácia.

Prototyp sa preto oplatí hlavne tam, kde by na chybnom rozhodnutí vyrástlo najviac: pri mnohých používateľoch, viacerých integráciách a dlhom vývoji. Jeho rozsah aj cena sa dajú vopred ohraničiť, cena omylu nie.

Prototyp ako podklad pre ponuku a odhad

Keď dodávatelia oceňujú stostranový text, každý oceňuje vlastný výklad a vlastnú rezervu na neistotu. Opatrný cenu nadsadí, menej opatrný ju podhodnotí a rozdiel sa neskôr prejaví v zmenových požiadavkách, teda prácach mimo pôvodnej dohody, ktoré sa fakturujú zvlášť.

Klikateľný prototyp s akceptačnými kritériami mení východisko. Akceptačné kritériá sú podľa príručky GOV.UK súpis výsledkov, ktorý slúži ako kontrolný zoznam na potvrdenie, že služba splnila svoju úlohu a naplnila potrebu používateľa. Často sa píšu vo forme „hotové je, keď…“, napríklad pri službe Register to vote: používateľ vie, ako sa zaregistrovať online. Prototyp ukazuje, ako to má fungovať, kritériá určujú, kedy je hotovo, a dodávatelia tak oceňujú to isté.

Príručka tiež radí prehodnotiť, prečo funkciu potrebujete, ak sa jej cieľ nedarí sformulovať. Nepostavená funkcia nestojí nič na vývoji ani na údržbe.

Riziká prototypu

Zámena za hotový produkt. Klikateľný prototyp vyzerá hotovo, no chýba mu zabezpečenie, práca s dátami aj ošetrenie chýb. Pernice upozorňuje, že pri vyleštenom dizajne vedenie ľahko podľahne pokušeniu spustiť ho rovno naostro.
Prílišné ladenie vizuálu. Pri nízkej vernosti podľa Pernice používatelia skôr vyjadria negatívne reakcie, dizajnéri na návrhu menej lipnú a zainteresované strany vidia, že práca nie je hotová. Leštenie teda úprimnú spätnú väzbu skôr tlmí.
Nejasný osud prototypu. GOV.UK radí stavať v alfa fáze len to, čo stačí na otestovanie nápadov, nie kód v produkčnej kvalite, a počítať so zahodením kódu na jej konci. Či sa prototyp zahodí, alebo rozvinie, treba rozhodnúť pred jeho stavbou. Inak sa zotrvačnosťou môže stať základom produktu aj s technickým dlhom, teda skratkami, ktoré predražujú každú ďalšiu zmenu.

Kedy prototyp netreba

Prototyp znižuje neistotu. Kde žiadna nie je alebo sa dá znížiť lacnejšie, je zbytočným nákladom.

Kupujete hotový softvér bez úprav. Úlohu prototypu splní skúšobná verzia alebo demo, na ktorom ľudia vyskúšajú svoje reálne úlohy.
Systém je malý a nekritický. Boehm a Basili píšu, že takéto systémy sa dajú efektívnejšie vyvíjať v menej formálnom režime priebežného prototypovania. Oddelený prototyp tu nahradí samotný produkt vyvíjaný v krátkych krokoch.
Otázka neznie ako, ale či o to niekto stojí. Vtedy môže stačiť smoke test, teda overenie záujmu skôr, než riešenie existuje. Eric Ries opisuje, ako jeho tím strávil dva týždne stavaním funkcie, o ktorú nikto nestál, hoci by to podľa neho odhalil už jednoduchý smoke test cez reklamu v AdWords.
Problém nie je v softvéri. Ak proces obsahuje zbytočný krok, prototyp aplikácie ho len prenesie na obrazovku. Krok treba najprv odstrániť. Či sa vlastný systém vôbec oplatí, rozoberá článok Dobrý interný systém sa môže zaplatiť skôr než nový zamestnanec.

Podľa GOV.UK nie je zlyhaním zastaviť projekt na konci discovery fázy, ak výskum ukáže, že je to najlepšie rozhodnutie: ušetrí sa čas aj peniaze. O prototype preto rozhodujte podľa toho, kde je v projekte najväčšia neistota a koľko by stál omyl.

Čo si z toho zobrať

Pred podpisom rozsiahleho zadania overte prototypom najrizikovejšiu časť: najčastejší tok, spornú výnimku alebo neoverenú integráciu.
Každému prototypu dajte vopred otázku a kritérium úspechu, inak z testu zostane prezentácia.
Testujte s piatimi porovnateľnými ľuďmi na reálnych úlohách a po opravách spravte ďalšie kolo.
Zadanie aj výber dodávateľa stavajte na otestovanom prototype a akceptačných kritériách, aby všetci oceňovali to isté.
Najprv pomenujte neistotu, ktorú riešite. Niekedy ju lacnejšie odstráni skúšobná verzia hotového softvéru, smoke test alebo úprava procesu.