Z čeho vycházím: U specializovaných desktopových, webových a publikačních nástrojů jsem opakovaně řešil stejnou otázku: co musí fungovat v první verzi, aby šlo ověřit přínos bez stavby celého produktu.
„Potřebujeme aplikaci“ není ještě zadání
Taková věta popisuje řešení, ne problém. Před návrhem si potřebuji ujasnit, kdo proces spouští, jaká data přicházejí, podle čeho se rozhoduje a co je na konci považováno za úspěch.
Pokud se tento rozdíl přeskočí, vznikne často hezké rozhraní bez jasné odpovědi na otázku, co má po jeho použití přestat dělat člověk ručně.
Začínám jedním pracovním tokem
První verzi stavím kolem jedné konkrétní události: přijde požadavek, uživatel vybere data, systém připraví podklady nebo se provede kontrolovaný krok. Tento tok musí mít začátek, výsledek a popsané výjimky.
- Co je vstupem a kdo ho vytváří?
- Jaké podmínky musí platit před zpracováním?
- Kdo rozhoduje v nejasné situaci?
- Jak poznáme, že je úloha opravdu dokončená?
Co do první verze patří
Minimum není jen o počtu obrazovek. Patří do něj i věci, bez kterých řešení nebude bezpečně použitelné:
- jedna hlavní cesta procesem,
- role a oprávnění pro skutečné uživatele,
- historie důležitých změn,
- stav úlohy a důvod selhání,
- způsob ručního převzetí výjimky.
Naopak není nutné hned stavět univerzální dashboard, deset typů exportu nebo nastavení každého myslitelného pravidla.
Co záměrně odkládám
Odkládám funkce, které zatím nemají jasného uživatele nebo nemění rozhodování. Neznamená to, že nikdy nevzniknou. Znamená to, že jejich přínos nejdřív porovnáme s cenou, údržbou a rizikem, že rozšíří původní problém.
U publikačních a datových systémů je například lepší nejdřív stabilně zpracovat jeden typ obsahu než připravit obecný editor pro všechny budoucí formáty.
První verze jako rozhodnutí, ne jako kompromis
Dobře vymezený pilot má po dokončení odpovědět na tři otázky: ušetřil proces měřitelnou práci, funguje technická cesta i v chybových stavech a stojí další rozšíření za investici?
Proto v nabídce odděluji discovery, první provozní verzi a možné další fáze. Klient pak neplatí nejasný balík funkcí, ale kupuje si konkrétní rozhodnutí a výsledek.
Řešíte podobný proces?
Napište mi, jak funguje dnes a co má být výsledkem. Nejdřív vymezíme problém a rizika, potom teprve vybereme technologii.
Popsat proces ↗