F**kupy na produkci #3:
Málo vývojářů, velký problém: Jak špatný odhad kapacit zabije i dobrý softwarový projekt

Autor: Unnits

Začíná to nevinně. Projekt má jasné zadání, termín, rozpočet. Vývoj rozjíždí jeden, dva programátoři, očekávání jsou vysoká. Jenže po pár týdnech se něco láme. Backlog narůstá, dodávky se zpožďují a klient začíná být nervózní. Co se stalo?

Nejde o nešikovný tým, ani o složitý kód. Příčinou je podcenění kapacit.

V tomhle článku se podíváme na konkrétní scénář, jeho příčiny a hlavně - jak se mu vyhnout.

Typický průšvih: use case z praxe

MVP (Minimum Viable Product) aplikace má být hotová do tří měsíců. Klient očekává první verzi během osmi týdnů.

Tým? Jeden senior vývojář na backend, jeden junior na frontend. Produkťák navazuje přímo na vedení firmy.

Po dvou sprintech:

• Backend vývojář nestíhá pull requesty.
• Odhady se ukazují jako nereálné.
• Klient žádá první demo. Není co ukázat.

Dostáváme se do spirály reaktivních rozhodnutí: hasíme místo toho, abychom plánovali. Technický dluh roste. Lidé jsou frustrovaní. Projekt visí na vlásku.

Proč k tomu dochází?

Není to o neschopnosti - je to o systému. Tady jsou čtyři nejčastější chyby:

1. Odhady na základě „pocitu“

Rozpočet se tvoří podle intuice a přání klienta, ne podle dat. Chybí práce s historickou rychlostí dodávek (velocity), komplexitou backlogu, rezervou pro změny.

2. Neexistence plánovací metodiky

Bez základních nástrojů jako kapacitní plán, burndown chart nebo burn rate není jasné, kolik práce zvládne tým skutečně dodat.

3. Záměna MVP za „mini verzi všeho“

MVP není zmenšená verze plné aplikace. Pokud to tak klient chápe, nedostane se do produkce nic pořádného.

4. Lidé nejsou roboti

Nemoci, dovolené, onboarding juniorů - to všechno se děje. A když tým nemá rezervu, stačí malý výkyv a projekt se zastaví.

Kolik to opravdu stojí?

Podcenění kapacit není jen „zdržení“. Přináší konkrétní náklady:

• Zpomalení vývoje o 25–35 % = o desítky až stovky hodin navíc
• Prodloužený time-to-market = přicházíte o příležitosti
• Přepálený tým = riziko fluktuace
• Drahé „dohánění“ = najímání seniorů na poslední chvíli
• Ztráta důvěry klienta = projektová nedůvěra se těžko získává zpět

Jak to řešit: osvědčené přístupy od seniorních týmů

Používejte projektové nástroje a techniky

Plánování vývoje bez nástrojů je jako stavět dům bez stavebního plánu. V praxi se osvědčuje:

• Pracovat s kapacitními plány, které ukazují dostupnost a vytížení členů týmu.
• Sledovat velocity týmu v rámci iterací - reálné výstupy jsou důležitější než to, co „by mělo jít“.
• Pracovat s roadmapou, závislostmi a prioritami - buď v nástroji nebo alespoň v dobře vedeném vizuálním plánu.
• Používat dashboardy a přehledy, které vám ukáží, kde hrozí úzké hrdlo nebo přetížení.

Klíčové není konkrétní nástroj, ale to, že máte proces, který kapacity nejen plánuje, ale i pravidelně vyhodnocuje.

Iterativní přístup s revizí kapacit

• Agilní přístup umožňuje reagovat.
• Každý sprint je šance korigovat rozsah nebo navýšit tým.
• Sprintová retrospektiva je prostor pro ladění výkonu i pohody v týmu.

Škálujte tým chytře

Ne všechno musí dělat váš core tým.

• Pro testování, DevOps nebo napojení na ERP může dávat smysl externí specialista.
• Model: in-house core → externí specialisté na špičky

Jak to děláme v Unnits

Víme, že každý projekt začíná správným plánem - a že ten se nedělá bez lidí, kteří vývoji rozumí. Proto:

• Už v nabídce zapojujeme projektové manažery se zkušeností z reálného vývoje.
• Odhad děláme datově - na základě velocity, typových projektů, reálné dostupnosti lidí.
• Klientům pomáháme vyjednat rozsah MVP tak, aby ho reálně šlo dodat.
• Pokud dojde na krizový scénář? Máme připravené posily i procesy pro re-plánování.

Výsledek: Klienti s námi zkrátili dobu vývoje v průměru o 20 %, bez nutnosti „dojíždět“ projekty přes víkendy.

Shrnutí: Nejde jen o kapacity. Jde o důvěru a výsledek.

Pokud nemáte odhad kapacit pod kontrolou, nemáte pod kontrolou vývoj. A bez kontroly přichází nejistota, chaos a ztráty.

• Neplánujte jen lidi. Plánujte jejich reálný výkon v čase.
• Využívejte nástroje. Věci, co neměříte, neřídíte.
• Nebojte se říct klientovi „s tímto rozsahem to ve dvou lidech nedáme“.