Z nejasných požadavků do produkce za 2 týdny

Skoro každý projekt u mě začíná stejně: klient ví, že ho něco bolí, má hrubou představu o řešení, a přesné zadání sepsat neumí. To není jeho selhání — to je normální stav skutečné práce. Nejasnost je normální. Trik je rozbít ji na sled malých, ověřitelných rozhodnutí, místo čekání na dokonalou specifikaci, která nikdy nepřijde.

Tady je postup, kterým se dostávám od mlhavého prvního hovoru k softwaru běžícímu v produkci za dva týdny.

Začněte nejrizikovějšími předpoklady

Každé nejasné zadání skrývá pár předpokladů, které mohou projekt zabít. Hledám je dřív, než napíšu první řádek produktového kódu. Pořád dokola se objevují tři kategorie: dostupnost dat (existují data, která potřebujeme, a jsou dost čistá, aby se dala použít?), limity integrací (umí API třetí strany opravdu operace, se kterými počítáme, a v potřebném objemu?) a reálné workflow uživatelů (odpovídá proces, který si představujeme, tomu, co lidé celý den skutečně dělají?).

Seřaďte neznámé podle škody, kterou mohou napáchat, ne podle toho, jak jsou zajímavé. Ty smrtící pak ověřte nejlevnějším možným experimentem: jedním curl požadavkem na API, jedním dotazem nad exportem produkčních dat, čtvrthodinovým hovorem s člověkem, který bude nástroj denně používat. Blokátor objevený druhý den stojí jeden telefonát. Objevený dvanáctý den stojí termín.

Pište pro výsledek, ne pro úkoly

Když jsou rizika na stole, sepíšu specifikaci — a držím ji na jedné stránce. Jednostránková specifikace se success kritérii porazí dlouhý seznam úkolů, protože seznam úkolů zastará v okamžiku, kdy se realita pohne, zatímco výsledek platí dál. Cílem té stránky je shoda na tom, co znamená „hotovo“ — slovy, která vývojář i zadavatel čtou stejně.

Moje verze má vždy čtyři bloky: cíl v jedné větě, měřitelná kritéria „hotovo“, tvrdá omezení a explicitní seznam toho, co v rozsahu není. Vypadá zhruba takhle:

Cíl: skladníci potvrzují objednávky bez Excelu
Hotovo znamená:
- objednávka přejde z „nová“ na „potvrzená“ do 30 sekund
- chyby se ukážou uživateli, ne v logu, který nikdo nečte
- běží na tabletech se čtečkou, které už ve skladu jsou
Mimo rozsah: reporting, vícejazyčnost, hromadný import

Tuhle stránku si všichni odsouhlasí nejpozději třetí den. Když se uprostřed projektu objeví nový nápad — a on se objeví vždycky — přiložíme ho ke stránce: mění definici „hotovo“, nebo je to verze dvě? V devíti případech z deseti je to verze dvě.

Dvou‑týdenní kadence

S ověřenými riziky a definovaným „hotovo“ běží stavba v pevném rytmu. Čtrnáct dní, čtyři fáze, žádné výjimky:

• Dny 1–2: discovery, omezení a tenký prototyp. Potvrďte rizikové předpoklady, zafixujte omezení a nasaďte walking skeleton — jednu šťastnou cestu od začátku do konce, na staging URL, na kterou klient může kliknout.
• Dny 3–7: core implementace a automatické testy. Stavějte funkce, které naplňují výsledek, a nic jiného. Každé chování ze success kritérií dostane test — „hotovo“ je pak ověřitelné, ne diskutabilní.
• Dny 8–10: polish, edge‑cases a QA. Ošetřete ošklivé vstupy, prázdné stavy a chybové cesty. Projděte aplikaci s daty skutečného uživatele, ne s demo fixtures.
• Dny 11–14: release, monitoring a feedback loop. Vypouštějte postupně, sledujte logy a metriky a buďte u prvních session s uživateli. První den v produkci naučí víc než týden schůzek.

Ta kadence funguje, protože převádí nejasnost na rozhodnutí podle kalendáře. Dva týdny jsou dost krátké na to, aby nikdo nestihl uhnout jinam, a dost dlouhé na to, aby vzniklo něco skutečného. A demo na konci je nejlepší specifikační nástroj, jaký znám: klient, který neumí popsat, co chce, vám vždycky přesně řekne, co je špatně na věci, kterou má před sebou.

• Zaútočte na předpoklady, které mohou projekt zabít, dřív než začnete psát produktový kód.
• Definujte „hotovo“ na jedné stránce s měřitelnými kritérii; všechno ostatní je rozsah k vyjednávání.
• Dodávejte v pevném čtrnáctidenním rytmu — skutečnou specifikací je zpětná vazba z produkce.