arrow_backVšechny články
odhad softwarového projektuřízení projektůsoftwarová firmaplánovánímonte carlo

Odhad softwarového projektu – proč se projekty zpožďují a jak odhadovat lépe

· Josef Chmel

Velké IT projekty překračují rozpočet v průměru o 45 % a každý šestý se promění v katastrofu. Proč odhady selhávají a jaké postupy fungují i v malé softwarové firmě.

„Kolik to bude stát a kdy to bude hotové?“ Na tuhle otázku odpovídá šéf softwarové firmy téměř každý týden – zákazníkovi, investorovi nebo sám sobě. A téměř každý má zkušenost, že skutečnost byla nakonec jiná. Nejde o selhání jednotlivců. Data ukazují, že odhadování softwaru je systematicky těžké, a proto potřebuje systém, ne lepší intuici.

Jak moc se IT projekty mýlí

McKinsey ve spolupráci s Oxfordskou univerzitou analyzovala přes 5 400 velkých IT projektů. Výsledek:

  • v průměru o 45 % dražší, než se plánovalo,
  • o 7 % delší, než se plánovalo,
  • a doručily o 56 % méně hodnoty, než se předpokládalo.

Ještě důležitější je druhé zjištění. Bent Flyvbjerg a Alexander Budzier z Oxfordu prošli 1 471 IT projektů a zjistili, že průměrné překročení rozpočtu (27 %) vlastně není ten hlavní problém. Problémem jsou extrémy: zhruba každý šestý projekt byl tzv. „černá labuť“ s průměrným překročením nákladů o 200 % a harmonogramu téměř o 70 %. Stejné číslo – 17 % projektů, které mohou ohrozit samotnou existenci firmy – uvádí i studie McKinsey.

Pro malou softwarovou firmu to znamená jednu věc: nepočítejte s „průměrným“ zpožděním. Počítejte s tím, že jeden z vašich projektů se může vymknout úplně, a plánujte tak, aby vás to nepoložilo.

Jak moc se IT projekty mýlí v rozpočtu a hodnotě

Proč odhady selhávají

1. Kužel nejistoty. Barry Boehm a později Steve McConnell popsali, že na začátku projektu může být skutečná pracnost až čtyřikrát vyšší nebo čtyřikrát nižší než odhad. Nejistota se zmenšuje jen tím, že se o projektu dozvídáte víc a děláte rozhodnutí – o rozsahu, architektuře, prioritách. Pokud se rozsah později znovu otevře, kužel se zase rozšíří.

Kužel nejistoty – na začátku se odhad může splést až 4× oběma směry

2. Optimismus plánování. Lidé odhadují „z vnitřního pohledu“ – představí si, jak projekt poběží, když všechno půjde podle plánu. Daniel Kahneman to nazval planning fallacy a právě na ní postavil Flyvbjerg metodu referenčních tříd (viz níže).

3. Velké dávky. Čím větší celek, tím víc skrytých závislostí a tím později se ukáže problém. Obě oxfordské studie shodně doporučují dělit velké projekty na menší etapy s krátkými dodacími cykly.

Postupy, které fungují

Odhadujte podle toho, co už se stalo (referenční třídy)

Místo otázky „jak dlouho bude trvat tenhle projekt?“ se zeptejte: „jak dlouho trvaly podobné projekty, které jsme už dělali, a o kolik se odchýlily od původního odhadu?“ Tomu se říká reference class forecasting. Když víte, že vaše e-shopové integrace historicky trvaly o 40 % déle, než jste slíbili, přičtěte těch 40 % rovnou. Podmínka je jediná: musíte mít data o tom, kolik práce projekty skutečně stály.

Mluvte v pravděpodobnostech, ne v datech

Místo jednoho data („hotovo 15. listopadu“) dejte rozsah s pravděpodobností. Pomůže metoda Monte Carlo: vezmete historickou propustnost týmu (kolik úkolů nebo story pointů dokončil za sprint), mnohokrát náhodně nasimulujete, jak rychle „odpálí“ zbývající backlog, a dostanete rozdělení možných termínů. Inženýrský blog Expedia Group ukazuje typický výstup: 50% šance na dokončení k jednomu datu, 85% šance k datu o několik týdnů pozdějšímu. Zákazník pak dostane poctivou odpověď a vy víte, jakou rezervu si nechat ve smlouvě.

Zmenšujte úkoly

Malé úkoly s jasnými akceptačními kritérii se odhadují přesněji, rychleji se dokončují a chyby se ukážou dřív. Zároveň dávají víc datových bodů pro Monte Carlo – dvacet dokončených malých úkolů řekne o rychlosti týmu víc než dva velké.

Sledujte závislosti jako závislosti

Hodně zpoždění nevzniká pomalou prací, ale čekáním – na zákazníka, na jiný tým, na rozhodnutí. Když jsou blokující vztahy mezi úkoly zapsané explicitně, a ne schované v popisu, vidíte včas, co drží projekt na místě.

Počítejte s černou labutí

Flyvbjerg a Budzier doporučují jednoduchý zátěžový test: ustála by firma, kdyby jeden velký projekt stál čtyřikrát víc a přinesl jen polovinu přínosů? Pokud ne, projekt rozdělte, přidejte fázi ověření nebo změňte smluvní model (například fixní cenu jen za první etapu).

Jak na to v praxi

  1. Zapisujte odhad i skutečnost u každého úkolu – bez toho nemáte z čeho se učit.
  2. Po každém projektu si spočítejte poměr skutečnost / odhad a použijte ho jako koeficient pro příští nabídku.
  3. Termíny komunikujte jako rozsah s pravděpodobností.
  4. Velké zakázky rozdělte do etap a fixní cenu dávejte jen na tu, kterou umíte dobře odhadnout.
  5. Každý týden kontrolujte zablokované úkoly – jsou to nejčastější skryté zdroje zpoždění.

Kde pomůže mcptask.online

mcptask.online vznikl jako nástroj pro řízení softwarové firmy a přesně tahle data sbírá průběžně. Úkoly odhadujete scrum pointy (S, M, L, XL…) a systém z nich automaticky dopočítá odhad hodin. Skutečný čas se loguje přímo z commitů (například „#Task-47 2h“) a v timesheetech (JSON, CSV, PDF) pak porovnáte odhad se skutečností po projektech i sprintech. Závislosti mezi úkoly jsou skutečné blokující vazby – zablokovaný úkol vypadne z fronty a po vyřešení blokeru se sám vrátí. A pokud část rutinních úkolů předáte autonomnímu AI vývojáři, jeho práce se eviduje stejně jako práce lidí.

Chcete odhadovat podle vlastních dat místo podle pocitu? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.

Zdroje