Jak dlouho reálně trvá vývoj softwaru (a co ho zdržuje)

Zákazník dostane dva nabídky. Jeden tým říká tři měsíce, druhý rok. Obě nabídky popisují stejný produkt. Kdo lže? Možná ani jeden. Možná oba.

Tohle je téma, o kterém se nemluví rovně. Odhady se nafukují, ale ne vždy záměrně. Pojďme se podívat, proč to tak je a jak to vypadá v praxi.

Jak vypadá realita

V roce 2024 jsme postavili Carivio — kompletní dispečerskou platformu pro taxi. Tři aplikace (web, iOS, Android), backend s 128 000 řádky kódu, 48 feature modulů, 107 databázových migrací, 6 uživatelských rolí, real-time přes SignalR. Dnes to řídí zhruba 50 vozů v Praze (transportprague.com).

MVP byl hotový za 4 měsíce.

Porovnáme-li to se standardními odhady pro srovnatelný scope, pohybujeme se obvykle mezi 12 a 18 měsíci. To je 3× až 4× více. Neřezali jsme rohy. Není to tím, že bychom pracovali 80 hodin týdně. Je to tím, že jsme určité věci udělali jinak — a jinak dřív.

Co projekt reálně zdržuje

Rychlost nepřichází ze zkrácených sprintů. Přichází z toho, co se udělá — nebo neudělá — na začátku.

Specifikace, která chybí. Toto je zdaleka nejčastější příčina. Vývojáři začnou bez jasného zadání, implementují podle domněnek a pak se vrací. Každý rework stojí 3× více času než správná implementace napoprvé. Ne proto, že by se špatně kódovalo, ale proto, že se mění věci, na kterých závisí jiné věci.

Architektonická rozhodnutí odkládaná na „později". Databázové schema, autentizační model, způsob real-time komunikace — to jsou věci, kde pozdní změna přepisuje desítky souborů. Když je toto rozhodnuté správně na začátku, zbytek stavění je mechanický. Když není, každý sprint přidává technický dluh.

Integrační překvapení. Platební brána, státní systém, ERP — to jsou místa, kde odhad bývá nejméně realistický. Dokumentace říká jedno, realita API říká druhé. Bez průzkumu předem se tohle zjistí až při implementaci.

Nerozhodnosti na straně zákazníka. Tohle se neřekne nahlas, ale je to pravda: projekt se zpomalí pokaždé, když se čeká týden na odpověď na klíčovou otázku. Rychlý vývoj vyžaduje rychlé rozhodování na obou stranách.

Rychlost ≠ zkratky

Nejčastější mylná představa: rychlý vývoj znamená špatný kód. Opak je pravda.

Když je základ navržený správně od začátku, přidávání dalších modulů je jednoduché. Naopak — špatný základ zpomalí každou následující funkcionalitu. Po šesti měsících takového projektu nestíháte ne proto, že máte špatné lidi, ale proto, že každá změna táhne za sebou tři další.

U Carivio nás správně navržená architektura od prvního dne umožnila přidávat feature moduly bez přepisování předchozích. Kdyby základ nebyl správný, 4 měsíce by nestačily ani na half scope.

Stejný princip platí i při jiných typech práce. Pro jednoho zákazníka jsme zrychlili generování smluv z 2 hodin na 3 minuty — to je 40× — přepsáním šablonového enginu, který byl navržen špatně od začátku. Nešlo o optimalizaci parametrů, šlo o přepsání přístupu. U jiného projektu jsme zkrátili SAP pipeline z dnů na zhruba 4 hodiny přepsáním SQL dotazů — o 80 % méně dat se přesune po síti.

V obou případech nešlo o víc práce, ale o jinak navrženou práci.

Kde AI skutečně pomáhá

AI-assisted vývoj jsem začal používat systematicky přibližně před dvěma lety. Zjistil jsem jedno jednoduché pravidlo: pomáhá tam, kde je problém dobře definovaný.

Boilerplate, testy k existující logice, dokumentace, jednoduché transformace — tam AI ušetří hodiny denně. Není to hyperbola, to je měřitelné.

Tam, kde AI nepomůže: zamotaná legacy integrace, kde nikdo neví, co kód vlastně dělá. Compliance-citlivé části, kde chyba stojí víc než ušetřený čas. Architektonická rozhodnutí, kde špatná volba přepisuje týdny práce. Tady potřebujete zkušenost, ne nástroj.

AI zrychlí tam, kde je dobré zadání. Špatné zadání nezachrání ani nejlepší nástroj.

Upřímně: 4 měsíce nejsou vždy možné

Bylo by nečestné říct, že každý projekt jde takto rychle. Záleží na třech věcech.

Jasný scope. Carivio mělo od začátku definovaný MVP — co je v něm a co ne. Bez toho se rozsah rozrůstá průběžně a žádný odhad nedrží.

Rozhodování v reálném čase. Zákazník byl dostupný, odpovědi přicházely rychle. Kde se čeká na rozhodnutí, tam se čeká celý tým.

Základ napoprvé. Ušetřený čas na spec a architektuře se projeví v každém dalším sprintu. Zkrátit tuto fázi je sice lákavé, ale obvykle se to prodraží trojnásobně.

Když tyhle tři věci nejsou splněné, projekt se vleče. Bez ohledu na nástroje, frameworky nebo velikost týmu.

Co z toho vyplývá

Odhady se nafukují nejčastěji ze dvou důvodů: buď se počítá s reworkem (protože spec chybí), nebo se přidává polštář pro případ problémů (protože integrace jsou neprozkoumané). Obojí je racionální v kontextu, kde zákazník nepřijde s připraveným zadáním.

Řešení není tlačit vývojáře, aby odhadli méně. Řešení je přijít připravený: s jasným scopem, klíčovými rozhodnutími udělanými, a ochotou rozhodovat rychle i v průběhu.

Pak se odhady mění — ne o procenta, ale o řády.

---

FAQ

Proč jeden odhad říká 3 měsíce a druhý rok?

Protože každý z nich počítá s jiným množstvím neznámých. Tým, který odhaduje rok, pravděpodobně kalkuluje s reworkem, integrační nejistotou a čekáním na rozhodnutí. Tým, který říká 3 měsíce, buď má zkušenost s tím, jak neznámé eliminovat dopředu, nebo podcení scope a nestihne. Bez přečtení zadání a způsobu práce obou týmů to z čísla nezjistíte.

Zrychlí AI vývoj?

Závisí na tom, co děláte. U dobře definované práce — testy, boilerplate, dokumentace — ano, znatelně. U architektonických rozhodnutí, legacy integrace nebo compliance logiky ne. AI nenahradí špatné zadání. Pokud nevíte přesně, co chcete, AI vám to rychleji vygeneruje špatně.

Jde MVP za 4 měsíce vždy?

Ne. Závisí na jasném scope, rychlém rozhodování zákazníka a správně navrženém základu. Pokud jedno z toho chybí, 4 měsíce reálně nestačí. Co ale platí vždy: čas strávený na specifikaci a architektuře na začátku se vrátí v každém dalším sprintu. Přeskočit ho je nejdražší zkratka, jakou projekt může udělat.