Žádný projekt se nerozbije jedním velkým požadavkem. Rozbije se dvaceti malými. „Ještě by to chtělo export do Excelu.“ „Můžete tam přidat filtr podle data?“ „Šéf by rád viděl ještě jeden graf.“ Každý požadavek zvlášť zní rozumně a zabere „jen pár hodin“. Dohromady posunou termín o dva měsíce a z projektu s fixní cenou udělají ztrátový. Tomu se říká scope creep – nekontrolované rozšiřování rozsahu projektu bez posouzení dopadu a bez schválení. Podívejme se, jak je ten problém velký a jak ho v softwarové firmě držet pod kontrolou.
Jak velký problém scope creep je
Project Management Institute (PMI) se na rozsah ptá ve svém každoročním průzkumu Pulse of the Profession. Podle vydání z roku 2018 zažilo scope creep nebo nekontrolované změny rozsahu 52 % projektů dokončených v předchozích 12 měsících. O pět let dříve to bylo 43 %. Problém tedy neubývá, spíš naopak – PMI to přičítá vyšším očekáváním zákazníků a rychlejšímu tempu dodávek.
U velkých IT projektů jsou následky drahé. McKinsey ve spolupráci s Oxfordskou univerzitou analyzoval přes 5 400 IT projektů. Velké projekty (s počátečním rozpočtem nad 15 milionů dolarů) v průměru překročily rozpočet o 45 %, termín o 7 % a přinesly o 56 % menší hodnotu, než se čekalo. Nestabilní rozsah studie spojuje hlavně s tím, že se tým se zadavatelem málo baví o nových požadavcích a změnách.
Všimněte si, že časový skluz je „jen“ 7 %, ale rozpočet +45 %. Firmy často termín udrží tak, že na projekt přihodí lidi a přesčasy. Zaplatí to marže dodavatele nebo rozpočet zákazníka.
Odkud se scope creep bere
Atlassian ve svém průvodci řízením projektů uvádí čtyři typické příčiny:
- Špatná komunikace. Každý si zadání vyloží jinak a rozhodnutí z e-mailů a chodbových rozhovorů se ztrácejí.
- Nejasné cíle. Když není jasné, co znamená „hotovo“, nedá se posoudit, jestli nový požadavek k cíli patří.
- Příliš mnoho lidí na straně zadavatele. Každý má své nápady a chybí jeden člověk, který rozhoduje.
- Žádné řízení změn. Požadavky přicházejí „jen tak mimochodem“ a nikdo neposoudí jejich dopad.
PMI k tomu přidává ještě jednu past typickou pro softwarové firmy: agilní vývoj chápaný jako licence k neomezeným změnám. Pružnost backlogu neznamená, že se do něj dá donekonečna přidávat bez kompromisu.
Řízení změn: pět kroků místo „no jo, uděláme to“
Lékem není odmítat každou změnu. Zákazník se během projektu dozví víc a některé jeho nové požadavky jsou cennější než původní plán. Lékem je, aby každá změna prošla stejným jednoduchým procesem. Atlassian ho popisuje takto:
- Požadavek – zapsaný, s konkrétním vlastníkem a obchodním důvodem.
- Posouzení dopadu – co změna udělá s termínem, rozpočtem a lidmi.
- Rozhodnutí – schválit, zamítnout, odložit, nebo vyměnit za něco jiného. Každé „ano“ je spojené s kompromisem.
- Záznam – kdo rozhodl a proč.
- Aktualizace – plánu, termínů a komunikace se všemi zúčastněnými.
Na začátku projektu k tomu patří stručný popis rozsahu – co dodáte, a stejně důležité, co výslovně nedodáte. A podpis zadavatele. PMI doporučuje mít postup pro změny přímo ve smlouvě; pak se o každém dalším požadavku jedná podle pravidel, ne podle nálady.
Kdy změna není scope creep
V agilním projektu se změny čekají. Elena Yatzeck z Thoughtworks proto navrhuje jednoduchý test: změna není scope creep, pokud nikomu nepřidá práci navíc. Konkrétně:
- Změna předtím, než tým začne řešit detaily, je v pořádku. Story zůstávají stručné, dokud se na nich nezačne pracovat.
- Story je možné vyměnit za jinou se stejnou odhadovanou pracností.
- Do plánu vydání si nechte rezervu kolem 20 % na práci, o které zatím nevíte. Dokud ji nevyčerpáte, je všechno v pořádku.
Scope creep naopak je předělávání už hotové práce (čas, který jste do ní dali, se nevrátí), výměna malé funkce za mnohem větší při stejném termínu a rozpočtu a obecně přidávání práce bez kompromisu jinde. Pro jednání se zákazníkem Yatzeck doporučuje argumentovat daty: co už je hotové, jakým tempem tým doručuje a jak by nový požadavek posunul termín vydání.
Sprint a pevný termín jako ochrana rozsahu
Dvě zavedené metodiky řeší rozsah překvapivě podobně – pevným časem.
Scrum. Scrum Guide říká, že během sprintu se nedělají žádné změny, které by ohrozily cíl sprintu, a kvalita neklesá. Rozsah se smí upřesňovat a znovu vyjednávat s product ownerem, jak se tým dozvídá víc. Nový požadavek tedy jde do backlogu a o jeho pořadí se rozhoduje při plánování dalšího sprintu, ne v úterý odpoledne po telefonu se zákazníkem. Sprint trvá nejvýš měsíc, takže zákazník nečeká dlouho.
Shape Up. Metodika firmy Basecamp pracuje s pojmem appetite – kolik času jste ochotní do věci investovat, nikoli kolik podle odhadu zabere. Princip zní „fixed time, variable scope“: termín se nehýbe a rozsah se mu přizpůsobí. Věci, které jsou „hezké mít“, se dělají až na konci cyklu, a když na ně nezbude čas, vypadnou.
Pro šéfa softwarové firmy z toho plyne praktická rada: dohodněte se se zákazníkem, co je pevné. Buď termín a rozpočet (a rozsah se přizpůsobí), nebo rozsah (a pak každá změna znamená nový odhad a novou cenu). Nejhorší varianta je, když je pevné všechno – tu zaplatíte vy.
Kontrolní seznam proti scope creep
- Na začátku napište, co je v rozsahu i mimo něj, a nechte si to odsouhlasit.
- Na straně zákazníka mějte jednoho člověka, který o změnách rozhoduje.
- Každý nový požadavek zapište jako samostatnou položku s odhadem, ne jako poznámku do e-mailu.
- Ke každému „ano“ řekněte, co se posune nebo vypadne.
- Nechte si v plánu rezervu a sledujte, jak rychle ji čerpáte.
- Odpracované hodiny evidujte u konkrétních úkolů – jen tak zákazníkovi doložíte, kolik změny skutečně stály.
Jak s tím pomůže mcptask.online
V mcptask.online rozložíte projekt na Epic → Story → Task a každý úkol ohodnotíte scrum pointy, ze kterých se automaticky počítá odhad hodin. Nový požadavek zákazníka tak hned dostane vlastní úkol s odhadem a vy vidíte, o kolik roste rozsah. Pro nápady, o kterých se teprve rozhodne, je typ úkolu „nápad“, takže nemusí skončit rovnou ve sprintu. Závislosti mezi úkoly evidujete jako skutečné blokující vazby, takže je vidět, co změna posune.
Čas se loguje u konkrétních úkolů – ručně nebo z commitů s odkazem na úkol – a timesheety vyexportujete do JSON, CSV nebo PDF. Zákazníkovi tak doložíte, co stála každá změna, a podklady pro fakturaci můžete posílat do Fakturoidu nebo iDokladu. Úkoly z Jiry, Trella nebo Redmine převezmete importem.
A když už změnu schválíte, nemusí ji nutně dělat váš vývojář. Malé, dobře popsané úkoly s akceptačními kritérii může ze stejné fronty zpracovat autonomní AI vývojář (runner) na vaší infrastruktuře: napíše kód i testy, otevře pull request a o merge rozhodujete vy.
Chcete mít rozsah projektů pod kontrolou? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.
Zdroje
- Scope Patrol, PMI Learning Library (data z PMI Pulse of the Profession 2018)
- Delivering large-scale IT projects on time, on budget, and on value, Michael Bloch, Sven Blumberg, Jürgen Laartz, McKinsey & Company, 2012
- Scope Creep in Project Management: How to Manage It, Atlassian
- How to Control Scope Creep in Agile, Elena Yatzeck, Thoughtworks
- The Scrum Guide, Ken Schwaber, Jeff Sutherland, 2020
- Shape Up: Set Boundaries, Ryan Singer, Basecamp