Závěrečná faktura a nekonečné požadavky: Scope creep v praxi

Existuje věta, která je v IT vývoji nebezpečnější než jakýkoli malware. Nevyžaduje žádné technické znalosti. Neobchází žádný firewall. Přesto dokáže zničit rozpočet, harmonogram a motivaci celého týmu. Ta věta zní:

"Když už jste u toho..."

Scope creep -- plíživé rozšiřování rozsahu projektu -- je nejčastější příčinou toho, proč projekty překročí rozpočet a termín. Ne špatná technologie. Ne nekompetentní vývojáři. Ale nezvládnuté očekávání a neschopnost říct "ne". Nebo přesněji: "ano, ale to bude stát extra."

Tady je pár příběhů o tom, jak projekty rostou nad všechny meze.

"Jen ještě jednu funkci"

Klient chtěl jednoduchý rezervační systém pro svůj salon. Výběr služby, výběr termínu, potvrzení. Tři kroky. Odhadli jsme to na šest týdnů.

Týden dva: "Bylo by skvělé, kdyby systém posílal SMS připomínky." Jasně, to dává smysl. Přidáme SMS. Malý scope creep, ale rozumný.

Týden tři: "Co kdyby si zákazníci mohli vytvořit účet a vidět historii rezervací?" No dobře, uživatelský systém. To už je větší věc, ale pochopitelná.

Týden čtyři: "Potřebujeme věrnostní program. Každá desátá návštěva zdarma." Takže bodový systém, sledování návštěv, automatické slevy.

Týden pět: "Konkurence má e-shop s kosmetikou přímo v aplikaci. Nemůžeme to taky mít?" E-shop. V rezervačním systému.

Týden šest (původní deadline): "A ještě by to chtělo napojení na účetní systém a automatické vystavování faktur."

Z jednoduchého rezervačního systému se stal komplex zahrnující SMS bránu, uživatelský portál, věrnostní program, e-shop a účetní integraci. Šest týdnů se proměnilo v pět měsíců. A klient byl upřímně překvapený, že to stojí víc, než byl původní odhad. "Vždyť to byly jen drobnosti," řekl.

Každá jednotlivá funkce byla drobnost. Ale drobnosti se sčítají. Padesát "drobností" je velký projekt.

Bug, nebo feature?

Máme oblíbený žánr e-mailů od klientů: hlášení "bugů", které jsou ve skutečnosti požadavky na nové funkce.

"Našel jsem bug -- aplikace nepodporuje export do PDF." To není bug. Export do PDF nikdy nebyl v zadání. To je nová funkce.

"Je to chyba, že systém nepodporuje patnáct jazyků." Zadání říkalo čeština a angličtina. Patnáct jazyků není chyba. Je to třináct nových jazyků.

"Nefunguje mi vyhledávání podle barvy produktu." Protože vyhledávání podle barvy nebylo v zadání. Máte vyhledávání podle názvu a kategorie, přesně jak bylo domluveno.

Tohle je klasická taktika -- vědomá nebo nevědomá -- jak obejít change request proces. Pokud je to bug, musíte to opravit v rámci záruky. Pokud je to feature, stojí to peníze. A tak se z features stávají "bugy".

Nejlepší příklad, který si pamatujeme: klient nahlásil bug, že aplikace "nefunguje na Apple Watch." Aplikace byla webový portál pro správu nemovitostí. Na Apple Watch ji nikdo nikdy neměl v plánu provozovat.

MVP, které se stalo enterprise platformou

Startup přišel s jasnou vizí: MVP aplikace pro sdílení pracovních prostor. Minimum funkcí, rychle na trh, ověřit hypotézu. Skvělý přístup.

Jenže pak přišli investoři. A investoři měli nápady. "Co kdybychom přidali video hovory přímo v appce?" "A co integrace s Google Calendar a Outlook?" "Měli bychom mít vlastní platební systém místo Stripe." "A co kdyby to fungovalo i jako sociální síť pro coworking komunitu?"

Nikdo neřekl ne. Ani startup, ani my (to byla naše chyba). Každý nápad zněl rozumně v izolaci. V součtu to byl úplně jiný produkt.

Z MVP za tři měsíce se stal enterprise projekt na rok a půl. Z rozpočtu na statisíce se staly miliony. A to nejhorší: když produkt konečně vyšel, trh se už posunul a konkurence, která spustila jednodušší MVP před rokem, měla náskok.

Paradox: snaha udělat všechno vedla k tomu, že se neudělalo nic včas.

Čtyřicet sedm e-mailů

Máme v archivu e-mailový řetězec, který je dokonalou případovou studií scope creepu. Začal takto:

E-mail 1: "Potřebujeme jednoduchý kontaktní formulář."

E-mail 5: "A co kdyby formulář uměl i přílohy?"

E-mail 12: "Bylo by dobré, kdyby se přílohy automaticky ukládaly na Google Drive."

E-mail 19: "Mohli bychom přidat CRM funkce? Ať vidíme historii komunikace s klientem."

E-mail 27: "A pipeline pro obchodní příležitosti by byl super."

E-mail 35: "Potřebujeme reporting. Grafy, export do Excelu."

E-mail 41: "Co integrace s fakturačním systémem?"

E-mail 47: "Kolik to vlastně bude stát? Původní odhad za kontaktní formulář byl 15 tisíc."

Z kontaktního formuláře se v průběhu čtyřiceti sedmi e-mailů stal CRM systém. A klient pořád mluvil o "tom formuláři". V jeho hlavě to byly postupné malé úpravy jednoduché věci. V realitě to byl kompletně nový produkt.

Jak to řešíme

Nejsme zlí. Nechceme říkat ne. Chceme klientům pomoct realizovat jejich vize. Ale roky zkušeností nás naučily, že neřízený scope creep neublíží jen nám -- ublíží hlavně klientovi. Projekt se prodraží, zpozdí a výsledek je často horší, než kdyby se dodalo méně, ale pořádně.

Change request proces. Každý nový požadavek, který není v původním zadání, projde formálním procesem. Popíšeme dopad na rozpočet a harmonogram. Klient se rozhodne, zda to chce zaplatit. Žádné "to přidáme za pochodu."

Analýza dopadů. "Jen přidejte jedno pole do formuláře" může znamenat změnu databáze, API, validace, testů a dokumentace. Vysvětlujeme, co konkrétní změna obnáší, aby klient rozuměl, proč "jedno pole" trvá dva dny.

Sprintové hranice. Co je naplánované na sprint, se nemění. Nové požadavky jdou do backlogu a prioritizují se na další sprint. Žádné "rychle to tam ještě přihoďte."

Rozlišení mezi "musí být" a "bylo by hezké." Ne každý nápad musí být v první verzi. MVP je minimum viable product -- ne maximum possible product. Většina funkcí může počkat na verzi dvě.

Umění říct "ano, ale..."

Scope creep není o tom, že by klienti byli špatní nebo měli hloupé nápady. Většinou jsou jejich požadavky rozumné. Problém je v tom, že každý rozumný požadavek přidává čas a peníze. A pokud se to nekomunikuje transparentně, vznikne propast mezi očekáváním a realitou.

Říct "ne" je nepříjemné. Říct "ano, ale to bude stát X korun a posune termín o Y týdnů" je profesionální. Klient dostane informaci pro rozhodnutí. Může říct: "Stojí to za to, pojďme do toho." Nebo: "To ne, to počká." Obojí je v pořádku.

Co není v pořádku, je říkat "jasně, to přidáme" ke každému požadavku a pak se divit, proč je projekt dvojnásobně drahý a třikrát delší. To není služba klientovi. To je cesta ke zklamání na obou stranách.

Scope creep se nedá úplně eliminovat. Projekty se vyvíjejí, požadavky se mění, a to je normální. Ale dá se řídit. A řízený scope creep je jen jiné slovo pro "iterativní vývoj".