Prototyp aplikace před vývojem: proč zadání nestačí

Firma několik měsíců připravuje zadání. Dokument má přes sto stran a připomínkovali ho lidé z obchodu, provozu, financí i IT. Po podpisu smlouvy s dodavatelem následují měsíce vývoje a na první ukázce zazní: „Takhle jsme to nemysleli.“

Scénář je modelový, problém za ním je ale skutečný. V mezinárodním průzkumu NaPiRE, který vyplnilo 228 organizací z 10 zemí, vybírali respondenti nejkritičtější problémy při práci s požadavky. Nejčastěji uváděli neúplné nebo skryté požadavky (48 % respondentů). Nedostatky v komunikaci mezi týmem a zákazníkem uvedlo 41 % a ze všech problémů v první desítce je respondenti nejčastěji označili za závažnou příčinu selhání projektu.

Rozsáhlé zadání vytváří pocit jistoty, to podstatné se na něm ale otestovat nedá: zda lidé řešení pochopí a zvládnou s ním svou práci. Prototyp aplikace to ukáže během několika dnů až týdnů, kdy je oprava ještě levná, a ne až po měsících vývoje.

Proč podpis pod zadáním nechrání před nedorozuměním

Podpis potvrzuje souhlas s textem, ne to, že si pod ním obě strany představují totéž. Frederick P. Brooks Jr. v eseji No Silver Bullet z roku 1987 napsal, že nejtěžší částí tvorby softwaru je přesně rozhodnout, co se má postavit, a žádnou jinou část není později těžší napravit. Podle něj je pro zákazníka ve skutečnosti nemožné úplně, přesně a správně specifikovat požadavky na moderní software dřív, než vyzkouší několik jeho verzí.

Objemný dokument tento problém podle nás spíš zakrývá. S každou stranou roste pocit úplnosti, jenže každé oddělení čte hlavně svou kapitolu a samozřejmosti nikdo nesepíše. První zpětnou vazbu k něčemu hmatatelnému firma dostane, až když na nedorozumění stojí kód. Brooks ve stejné eseji označil za zásadně chybný předpoklad, na kterém tehdy stálo pořizování softwaru: že systém lze předem uspokojivě specifikovat, vysoutěžit, postavit a nainstalovat.

Stejná věta, různé obrazovky

Text se nedá používat, a proto na něm neověříte, zda mu všichni rozumějí stejně. Vezměte si modelový požadavek „objednávky nad limit schvaluje vedoucí“. Finanční ředitelka si představí ranní přehled k hromadnému schválení, vedoucí skladu upozornění v mobilu, programátor stavové pole v tabulce. Všechny představy jsou s větou v souladu a každá vede k jiné pracnosti i ceně.

Výjimky se ukážou, až když se úkol skutečně provádí. Kdo schvaluje, když je vedoucí na dovolené? Platí schválení i po změně množství?

Čtvrtina respondentů NaPiRE navíc zařadila mezi nejkritičtější problémy to, že zainteresované strany jen obtížně oddělují požadavky od řešení, která už znají. Britská vládní příručka GOV.UK Service Manual doporučuje v discovery fázi, tedy při zkoumání problému ještě předtím, než se začne cokoli stavět, přeformulovat předem určené řešení na problém: ne „postavit interaktivní mapu kontaktních center“, ale „jak lidem usnadnit nalezení nejbližšího centra“.

Co je prototyp a co není

Prototyp je zjednodušená podoba budoucího produktu, na které se dá řešení vyzkoušet dřív, než se naprogramuje. Kara Pernice z Nielsen Norman Group ho popisuje jako hypotézu, tedy kandidátní řešení, které nejpříměji ověříte tak, že sledujete lidi při práci s ním. Nejde o minimální životaschopný produkt (MVP), tedy podle Erica Riese o verzi nového produktu, která týmu s nejmenším úsilím přinese maximum ověřených poznatků o zákaznících. Prototyp je užší nástroj: ověřuje navržené řešení ještě předtím, než se postaví.

Věrnost (fidelity) prototypu je podle Pernice míra, do jaké se podobá výslednému systému, a to v interaktivitě, vizuální stránce i v obsahu a příkazech. Pro rozhodování před vývojem v praxi rozlišujeme tři úrovně:

Skica nebo papírový prototyp. Místo systému reaguje člověk, který návrh zná a podává uživateli další nakreslené obrazovky. U příbuzné metody Wizard of Oz ovládá obrazovku člověk z jiné místnosti, takže lze vyzkoušet i chování, které ještě nikdo nenaprogramoval. Jakob Nielsen řadí papírové prototypování mezi nejrychlejší a nejlevnější techniky. Hodí se k ověření základního přístupu a průchodu aplikací.
Klikací prototyp. Propojené obrazovky, které reagují jako aplikace, i když za nimi nic neběží. Ověří, zda lidé zvládnou klíčové úkoly bez pomoci.
Funkční prototyp na reálných datech. Omezený kus skutečného kódu napojený na vzorek dat nebo rizikovou integraci. Hodí se, když nejistota není v rozhraní, ale v datech či technologii.

Naše pravidlo pro výběr: nejnižší věrnost, která ještě odpoví na aktuální otázku. Podle Nielsena má brzký test před pozdním takový náskok, že převáží i rozdíl v kvalitě prototypu. Design Kit od IDEO.org počítá u rychlého prototypování s několika dny až týdny podle toho, co se testuje.

Co musí prototyp aplikace prokázat

Prototyp je test, ne prezentace. Podle příručky GOV.UK není nutné prototypovat celou uživatelskou cestu, často stačí zaměřit se na nejnáročnější části a otestovat nejrizikovější předpoklady. Před vývojem by měl prototyp odpovědět na tyto otázky:

Pochopí lidé průchod aplikací? Zvládne úkol od začátku do konce i člověk, který u návrhu neseděl? Každé zaváhání v testu může v provozu znamenat telefonát na podporu nebo chybu v objednávce.
Padla klíčová rozhodnutí? Text dovolí spor odložit, obrazovka ne. Co se rozhodne teď, nezůstane jako nejistota v cenové nabídce.
Obstojí návrh s reálnými daty? Skutečné názvy bývají delší než v ukázce, pole nevyplněná a záznamy duplicitní.
Funguje nejrizikovější integrace? Integrace je propojení s jiným systémem, například s účetnictvím. Britská služba Register to vote by nefungovala bez API, tedy rozhraní pro výměnu dat, napojeného na registrační systémy více než 400 místních samospráv. Tým se proto na něj zaměřil už v alfa fázi, která je určená pro prototypy.
Přijmou to uživatelé? Prototyp adopci nezaručí, ale naznačí, zda by lidé nový postup upřednostnili před dnešními obezličkami. Proč na tom záleží, rozebírá článek Nejdražší systém je ten, který vaši lidé nepoužívají.

Testování s uživateli: pozorovat, ne se ptát

Uživatelské testování znamená, že člověk z cílové skupiny řeší na prototypu reálný úkol, například modelové zadání „vystavte dobropis k této faktuře“, a vy sledujete, kde zaváhá a co pochopí jinak. Dotazník zachytí, co si lidé myslí, že by udělali. Pozorování ukáže, co skutečně udělají.

Jakob Nielsen vychází z modelu, podle kterého první studie s pěti účastníky odhalí přibližně 85 % problémů použitelnosti, tedy míst, kde se lidé zaseknou nebo spletou. Místo jedné studie s 15 lidmi doporučuje tři kola po pěti, protože každé další ověří opravy a odhalí hlubší problémy. Platí to pro srovnatelné uživatele: u dvou výrazně odlišných skupin doporučuje tři až čtyři lidi z každé.

Kdy je pozdní změna opravdu drahá

Cena změny vyjadřuje, kolik stojí úprava rozhodnutí v dané fázi projektu. Barry Boehm a Victor Basili v článku z roku 2001 uvedli, že najít a opravit softwarový problém po dodání je často 100krát dražší než ve fázi požadavků a návrhu. Slovo „často“ doplnili záměrně: u malých nekritických systémů je poměr podle nich spíš 5:1. Uvedli také, že tehdejší projekty vynakládaly asi 40 až 50 % úsilí na přepracování, kterému se dalo vyhnout, a mezi jeho dva hlavní zdroje zařadili narychlo specifikované požadavky.

Růst ceny v čase ale neplatí univerzálně. Tim Menzies a spoluautoři na 171 projektech nenašli důkaz, že by řešení problémů v pozdější fázi stálo konzistentně nebo podstatně více úsilí než krátce po jejich vzniku. Šlo přitom převážně o malé až středně velké projekty s metodikou Team Software Process, bez dat z období po dodání. Autoři sami upozorňují, že se tento efekt může objevovat jen u některých typů projektů.

Podle nás pozdní změnu nezdražuje kalendář, ale to, co mezitím na chybném rozhodnutí vyrostlo: kód, integrace, dokumentace, školení i datový model. Kara Pernice připomíná, že zahodit kód je velmi drahé, zahodit prototyp ne. Neopravené nedorozumění navíc firma po spuštění platí každý den jako tření v běžné práci, jehož výpočet ukazuje článek Dobrý design není dekorace.

Prototyp se proto vyplatí hlavně tam, kde by na chybném rozhodnutí vyrostlo nejvíc: při velkém počtu uživatelů, více integracích a dlouhém vývoji. Jeho rozsah i cenu lze předem vymezit, cenu omylu ne.

Prototyp jako podklad pro nabídku a odhad

Když dodavatelé naceňují stostránkový text, každý naceňuje vlastní výklad a vlastní rezervu na nejistotu. Opatrný cenu nadsadí, méně opatrný ji podhodnotí a rozdíl se později projeví ve změnových požadavcích, tedy vícepracích nad rámec původní dohody, které se fakturují zvlášť.

Klikací prototyp s akceptačními kritérii mění výchozí situaci. Akceptační kritéria jsou podle příručky GOV.UK soupis výsledků, který slouží jako kontrolní seznam k potvrzení, že služba splnila svůj účel a naplnila potřebu uživatele. Často se píší ve tvaru „hotovo je, když…“, například u služby Register to vote: uživatel ví, jak se zaregistrovat online. Prototyp ukazuje, jak to má fungovat, kritéria určují, kdy je hotovo, a dodavatelé tak naceňují totéž.

Příručka také radí znovu zvážit, proč funkci potřebujete, pokud se její cíl nedaří zformulovat. Funkce, kterou nepostavíte, nestojí nic na vývoji ani na údržbě.

Rizika prototypu

Záměna za hotový produkt. Klikací prototyp vypadá hotově, chybí mu ale zabezpečení, práce s daty i ošetření chyb. Pernice upozorňuje, že u vyleštěného designu vedení snadno podlehne pokušení spustit ho rovnou naostro.
Přílišné ladění vizuálu. Při nízké věrnosti podle Pernice uživatelé spíš vyjádří negativní reakce, designéři na návrhu méně lpí a zainteresované strany vidí, že práce není hotová. Leštění vizuálu tedy upřímnou zpětnou vazbu spíš tlumí.
Nejasný osud prototypu. GOV.UK doporučuje stavět v alfa fázi jen to, co stačí k otestování nápadů, ne kód v produkční kvalitě, a počítat s tím, že se kód na konci této fáze zahodí. Zda se prototyp zahodí, nebo dál rozvine, je třeba rozhodnout ještě před jeho stavbou. Jinak se ze setrvačnosti může stát základem produktu i s technickým dluhem, tedy zkratkami, které prodražují každou další změnu.

Kdy prototyp není potřeba

Prototyp snižuje nejistotu. Kde žádná není nebo ji lze snížit levněji, je zbytečným nákladem.

Kupujete hotový software bez úprav. Roli prototypu splní zkušební verze nebo demo, na kterém si lidé vyzkoušejí své reálné úkoly.
Systém je malý a nekritický. Boehm a Basili píší, že takové systémy lze efektivněji vyvíjet v méně formálním režimu průběžného prototypování. Oddělený prototyp tu nahradí přímo produkt vyvíjený v krátkých krocích.
Otázka nezní jak, ale zda o to někdo stojí. Pak může stačit smoke test, tedy ověření zájmu dřív, než řešení existuje. Eric Ries popisuje, jak jeho tým strávil dva týdny vývojem funkce, o kterou nikdo nestál, přestože by to podle něj odhalil už jednoduchý smoke test přes reklamu v AdWords.
Problém není v softwaru. Pokud proces obsahuje zbytečný krok, prototyp aplikace ho jen přenese na obrazovku. Ten krok je třeba nejdřív odstranit. Zda se vlastní systém vůbec vyplatí, rozebírá článek Dobrý interní systém se může zaplatit dřív než nový zaměstnanec.

Podle GOV.UK není selháním zastavit projekt na konci discovery fáze, pokud výzkum ukáže, že je to nejlepší rozhodnutí: ušetří se čas i peníze. O prototypu proto rozhodujte podle toho, kde je v projektu největší nejistota a kolik by stál omyl.

Co si z toho vzít

Před podpisem rozsáhlého zadání ověřte prototypem nejrizikovější část: nejčastější průchod aplikací, spornou výjimku nebo neověřenou integraci.
Každému prototypu předem stanovte otázku a kritérium úspěchu, jinak se z testu stane prezentace.
Testujte s pěti srovnatelnými lidmi na reálných úkolech a po opravách udělejte další kolo.
Zadání i výběr dodavatele opřete o otestovaný prototyp a akceptační kritéria, aby všichni naceňovali totéž.
Nejdřív pojmenujte nejistotu, kterou řešíte. Někdy ji levněji odstraní zkušební verze hotového softwaru, smoke test nebo úprava procesu.