V minulosti jsme u většiny zakázkových úprav software pro státní správu používali metodiku klasického waterfallu. Dodavatel dostane zadání, termín a fixní odměnu. Na začátku projektu většinou sepíše specifikaci, jak bude požadavky realizovat, zákazník dokument schválí, proběhne vývoj a nakonec přijde slavnostní odhalení, kdy obě strany zjistí, jak moc se dodavatel s realizací trefil do potřeb koncových uživatelů.
U menších projektů to funguje. Tentokrát ale před námi stál mnohem větší projekt a my nechtěli riskovat, že to nedopadne a zákazník nebude spokojený. Nešlo se spokojit s tím, že dokumentace za nás vyřeší vzájemné porozumění požadavkům. Nešlo naivně předpokládat, že se požadavky v průběhu projektu nezmění. Domluvili jsme si tedy se zákazníkem pravidelné schůzky s cílem pochopit jeho potřeby a vyjasnit zadání.
Hned po prvních několika schůzkách se projevily nevýhody waterfallu. V našem případě měly formu dotazů: “A nešlo by udělat ještě tohle? A nemohlo by se tamto dělat automaticky? …” Většinou šlo o relevantní připomínky s přidanou hodnotou pro uživatele. Navíc ani nic moc pracného. Takže jasně, šlo by to. Problém byl, že takových připomínek bylo moc. Byli jsme sotva na začátku, mluvili jsme o prvním smluvním požadavku a už nám naskákaly další čtyři drobnosti navíc.
Jak tohle dopadne? Kolik takových věcí budeme dělat? Kdy se to zastaví? A jak to zastavíme? Jak řekneme zákazníkovi, že doteď bylo možné všechny drobnosti dělat, ale teď už to nejde, protože došly rezervy/peníze? A co když narazíme na něco opravdu důležitého, co nebudeme moct implementovat, protože jsme budget vyplýtvali na maličkosti? Vznikla potřeba řídit proces drobných vylepšení a nastartovat aktivní spolupráci se zákazníkem na prioritách požadavků.
A tak se zrodil projektový backlog. Původně zamýšlená drobná pomůcka, která se záhy ukázala jako naprosto stěžejní a nepostradatelný nástroj, který nám víceméně sám od sebe odřídil většinu projektu.
Projektový backlog obsahoval všechny požadavky - ze smlouvy i nové návrhy. Každý požadavek měl odhadnutou pracnost ve story pointech (SP). Součástí backlogu byl také tzv, SP budget - maximální hodnota SP, kterou bychom na projektu nechtěli překročit. SP budget zahrnoval rezervu pro případ chyb při odhadech, upřesnění zadání zákazníkem nebo doplnění nových požadavků.
Pro každý záznam v backlogu bylo možné nastavit prioritu. Výchozí nastavení bylo “won’t do”. Tímto krokem jsme chtěli zákazníka povzbudit k tomu, aby s dokumentem aktivně pracoval a přemýšlel o tom, který z požadavků je opravdu důležitý a dostane se do vývoje.
Dokument jsme nasdíleli zákazníkovi a pravidelně aktualizovali. Transparentně, se všemi informacemi, které zahrnoval.
Spolu s backlogem jsme zavedli i pravidelná review hotových funkčností a další mechanismy na podporu komunikace při vyjasňování požadavků. Protože šlo o velké změny ve způsobu práce, bylo potřeba zákazníkovi nejprve vše vysvětlit. Vyhradili jsme si na to extra schůzku a věnovali potřebný čas tomu, abychom se zákazníkem všechno krok za krokem prošli. A hlavně, aby to zákazník pochopil.
To se povedlo. Zákazník si vzal za své hospodaření se SP a všechny nové požadavky pravidelně validoval vzhledem k jejich prioritě a pracnosti. Díky sdílení backlogu měl okamžitě přehled, na čem pracujeme a jestli se pohybujeme v budgetu. Tahle spolupráce výrazně posílila vzájemnou důvěru. Najednou jsme pracovali jako bychom všichni byli jeden tým se společným cílem - dodat koncovým uživatelům něco, co má smysl a pomůže jim při každodenní práci.
Text: Jakub Krahula