Technická specifikace

Fungující verze má šest částí: problém ve dvou větách, rozsah, výslovný seznam toho, co v rozsahu není, hlavní toky s okrajovými případy, datový model a napojené služby a nakonec akceptační kritéria. Seznam „co tam není“ je nejcennější stránka dokumentu. Napsané „host checkout v tuhle verzi není, příští kvartál“ vyřeší hádku v říjnu, místo aby výšla najevo v listopadu.

Co nepatří dovnitř: diagramy všeho, kompletní grafický návrh, když ho má design dokument, nebo specifikace psaná dodatečně jen proto, aby byl vyplněný formulář. Dobrá specifikace je ta, kterou vývojář skutečně dvakrát přečte a klient ji podepíše.

Se specifikací je rozhovor milý a krátký: „Tohle jsme odsouhlasili. Ta změna přesune dvě obrazovky, vyjde na tři dny a posune spuštění o týden. Udělám ji, když budete chtít — vyhodíme něco jiného, nebo přidáme čas?“ To je skutečné rozhodnutí se skutečnou cenou, které dělá ten, kdo platí.

Bez specifikace se stejný okamžik změní v debatu o tom, co bylo odsouhlasené, pak v „však víte, jak jsem to myslel“ a nakonec ve slevu na konci. Nikdy nejde o kód. Jde o to, mít očekávání napsaná, dokud se všichni měli ještě rádi.

Dvouhodinová oprava interního nástroje, experiment, na kterém se nikdo nedohodl, funkce, která musí být hotová do zítřka — v těch případech stačí jednostránková poznámka s tím, co v rozsahu není, a tři řádky akceptačních kritérií. Psát dvanáctistránkovou specifikaci na tlačítko je divadlo, a divadlo stojí důvěru stejně jako nesplacený dluh.

Pravidlo: čím delší stavba a čím víc lidí rozhodnutím projde, tím větší smysl specifikace má. Cokoli nad dva týdny práce by mělo mít písemnou dohodu, ať je jakkoli krátká.