Představte si, že si necháte naplánovat dům do posledního šroubku, podepíšete to a stavbu otevřete za rok. Jenže za ten rok se vám narodí druhé dítě, práce se přesune domů a vy najednou potřebujete úplně jiný dům, než jaký se staví. U softwaru se tohle děje pořád. Velký plán dopředu vypadá jako jistota, ale ve skutečnosti je to sázka na to, že se za rok nic nezmění. A to se nikdy nestane.

Tahle lekce je o tom, jak místo velkého plánu napsat zadání, které drží, osekat ho na nejmenší užitečný kus a stavět po krocích, které reálně dojedete.

Proč velké „naplánujeme všechno dopředu“ projekty padají

Klasický scénář: půl roku se píše tlustá specifikace, všichni ji odsouhlasí, pak se rok mlčky programuje a na konci se odhalí výsledek. Tomuhle se říká vodopád a v softwaru funguje mizerně. Důvod je prostý: ten dokument zastará dřív, než ho dopíšete.

Mezitím se totiž změní trh, přijde nový konkurent, zákazníci začnou chtít něco jiného a vy sami zjistíte, že to, co jste si na začátku představovali, vůbec nepotřebujete. Jenže smlouva i kód už jedou podle starého plánu.

Riziko se hromadí na konec. Když se na první ostré uživatele čeká rok, rok nevíte, jestli stavíte správnou věc. To je nejdražší možný způsob, jak se mýlit.
Změna se trestá. U pevné specifikace je každá úprava „vícepráce“ a dohadování. Lidé pak raději mlčí a nechají vzniknout něco, co nechtěli, než aby otevírali boj.
Hotovo neznamená užitečné. Dají se odškrtat všechny body ze zadání a stejně mít software, který nikdo nepoužívá.

Dobré zadání popisuje problém, ne řešení

Nejčastější chyba v zadání je, že rovnou diktuje řešení: „chceme tlačítko, které vyexportuje objednávky do Excelu“. To je odpověď, ne otázka. Tomu, kdo software staví, řekněte hlavně dvě věci: co má být výsledek a proč.

V tomhle případě je skutečný problém třeba: „účetní každý pátek dvě hodiny ručně přepisuje objednávky a dělá v tom chyby“. Tohle zadání je k nezaplacení, protože dobrý řešitel z něj vytáhne lepší nápad, než byl ten váš export. Možná se data mají posílat rovnou do účetního systému a žádný Excel ani tlačítko netřeba.

Dobré zadání zní: (kdo) potřebuje (čeho dosáhnout), protože dnes (co ho brzdí). Omezení: (rozpočet, termín, co nesmí chybět).

Připište k tomu mantinely, ne postup. Tedy: do kdy to potřebujete, kolik na to máte, s čím to musí umět spolupracovat a co je naopak jednoznačně mimo. Jak přesně se to postaví, nechte na tom, kdo umí stavět. Za to mu platíte.

MVP: nejmenší užitečný krok, na který si někdo sáhne

MVP není „nedodělaná verze“. Je to nejmenší kus, který už reálnému uživateli vyřeší reálný problém a vy se z jeho používání něco dozvíte. Nestavíte celý firemní systém, abyste zjistili, jestli vůbec míříte správně. Postavíte jednu věc, která zabolí nejvíc, a tu doženete do konce.

Vezměme tu účetní. MVP není kompletní firemní systém. Je to jedna obrazovka, kam se sype pátečních dvacet objednávek a tlačítko, které je správně předá dál. Žádné role uživatelů, žádné reporty, žádný dashboard. Jen ta jedna bolest, vyřešená.

Smysl je v tom, že na MVP se dá sáhnout. Účetní ho měsíc používá a vy se dozvíte věci, které by v žádné specifikaci nebyly: že polovina objednávek chodí ještě e-mailem, že někdy je potřeba je opravit, že páteční rutina je vlastně středeční. Tohle se nedá vymyslet u stolu. Dá se jen zjistit provozem a pak na to navázat.

Roadmapa není kámen, je to seřazený seznam

Jakmile MVP žije, nápady se začnou hrnout. Od vás, od kolegů, od uživatelů. Roadmapa je živý seznam toho, co dál, seřazený podle jediného poctivého kritéria: kolik to přinese versus kolik to stojí práce.

Velký přínos, málo práce. Děláte hned. Tady je skrytá většina hodnoty.
Velký přínos, hodně práce. Plánujete pořádně, krájíte na menší kusy.
Malý přínos, málo práce. Když zbude čas. Klidně nikdy.
Malý přínos, hodně práce. Sem patří většina „skvělých nápadů“. Řekněte ne nahlas.

To „ne nahlas“ je důležité. Nevyřčené sliby („to časem doděláme“) jsou jed, protože zůstávají viset jako dluh, který nikdo nesplatí. Mnohem zdravější je říct: tohle teď ne, a tady je proč. Roadmapa, kterou půl roku neměníte, není roadmapa, ale přání. Měla by se hýbat pokaždé, když se z provozu něco nového dozvíte.

Priorizace bolí. Znamená to říkat ne věcem, do kterých se někomu z týmu chce. Bez toho ale software nabobtná do něčeho, co nikdo neunese ani nezaplatí.

Jak poznáte, že je hotovo: dohodněte si metriku předem

Cíl bez metriky je jen přání. Než se napíše první řádek, dohodněte se, podle čeho poznáte, že to vyšlo. U té účetní třeba: „páteční přepisování spadne ze dvou hodin pod patnáct minut a zmizí chyby v částkách“. To je číslo, na které se dá ukázat.

A pak je tu způsob práce, na kterém si u nás ve FRGTN zakládáme: vidět průběh každý týden je nekonečně lepší než velké odhalení po třech měsících. Týdenní ukázka, na kterou si můžete sáhnout, dělá dvě věci. Drží projekt v realitě, protože hned vidíte, jestli to jede správným směrem. A zabíjí riziko po malých kouscích, místo aby ho schovávala až na konec.

Software totiž nikdy není „hotový“ ve smyslu, že se na něj zavře dveře. Je hotový tehdy, když dělá svoji práci a vy víte, jaký bude další krok. To je celé. Začněte malým zadáním problému, postavte nejmenší užitečný kus a zbytek si nechte ukázat trhem.