Proč projekty vývoje software selhávají a jak se tomu vyhnout

Většina softwarových projektů neselhává kvůli špatnému kódu. Selhává kvůli špatné komunikaci, nejasným očekáváním a rozhodnutím, která se udělala — nebo neudělala — ještě před napsáním prvního řádku. Tady jsou nejčastější důvody a jak se jim vyhnout.

Absence analýzy

Nejčastější a nejdražší chyba. Firma přijde za vývojářem a řekne „chceme aplikaci na správu objednávek”. Vývojář začne kódovat. Po dvou měsících se ukáže, že polovina předpokladů neplatí, požadavky jsou jiné a celá architektura se musí předělat.

Analýza není zbytečná byrokracie. Je to pojistka:

• Zmapuje reálné procesy — ne jak si myslíte, že fungujete, ale jak skutečně fungujete
• Odhalí skryté požadavky — integrace, výjimky, oprávnění, které na první pohled nejsou vidět
• Definuje rozsah — co je v projektu a co ne. Bez toho nemůže existovat realistický odhad

Přeskočit analýzu je jako stavět dům bez projektu. Možná to půjde, ale pravděpodobně to budete bourat a stavět znovu.

Jak se tomu vyhnout: Trvejte na analýze. I když máte pocit, že víte, co chcete. I krátká analýza za týden je nekonečně lepší než žádná.

Špatné zadání

Zadání „potřebujeme systém, který bude intuitivní a moderní” není zadání. Je to přání. A přání se nedá naprogramovat.

Špatné zadání má typicky tyto znaky:

1. Je vágní — „chceme něco jako Booking, ale jednodušší.” Co to znamená konkrétně? Které funkce? Pro koho?
2. Je příliš ambiciózní — seznam 80 funkcí, z nichž 60 nikdo nebude používat. Ale všechny musí být v první verzi
3. Nemá priority — všechno je důležité. Což v praxi znamená, že nic není důležité
4. Nepopisuje uživatele — kdo bude aplikaci používat? Kolik lidí? Jak často? Na jakých zařízeních?

Příklad z praxe: Klient přišel s dvacetistránkovým zadáním. Po analýze se ukázalo, že 70 % požadavků vycházelo z toho, že neznali možnosti technologie — chtěli řešit problémy, které moderní framework vyřeší automaticky. Reálný rozsah byl třetinový.

Jak se tomu vyhnout: Místo detailního zadání popište problém, který řešíte. Nechte vývojáře navrhnout řešení. Na to jste si ho najali.

Špatný dodavatel

Ne každý, kdo umí kódovat, umí vést projekt. A ne každá agentura, která má hezký web, dodá kvalitní software.

Signály, že jste vybrali špatně:

• Slíbí všechno — žádná otázka, žádná pochybnost, žádný pushback. Profesionál říká „tohle nedoporučuji” nebo „tohle zvýší rozpočet o X”
• Nemá proces — hned začne kódovat, bez analýzy, bez návrhu, bez plánu
• Nekomunikuje proaktivně — musíte se sami ptát, jak to vypadá. Dobrý dodavatel vám posílá aktualizace bez vyzvání
• Nedokáže ukázat reference — ne mockupy, ale fungující aplikace v produkci s reálnými uživateli
• Mění lidi na projektu — každý měsíc pracuje někdo jiný, nikdo nezná kontext

Jak se tomu vyhnout: Ptejte se na proces, ne na technologie. Podívejte se na reference. A hlavně — ověřte, jak komunikují, ještě před podpisem smlouvy.

Podcenění rozpočtu

Firma má rozpočet 300 000 Kč na projekt, který realisticky stojí 800 000. Vývojář to ví, ale chce zakázku — tak slíbí, že to zvládne. Výsledek: po vyčerpání rozpočtu je hotová polovina, která sama o sobě nefunguje.

Rozpočet je problém ve dvou rovinách:

• Nerealistický odhad — buď od vývojáře, který chce zakázku, nebo od klienta, který netuší, kolik software stojí
• Nepočítá s rezervou — žádný projekt neskončí přesně podle plánu. Minimálně 15–20 % rezerva by měla být standard

Příklad z praxe: Klient chtěl marketplace za 500 000 Kč. Po upřímném rozhovoru jsme se domluvili na MVP za 600 000, které pokrylo jádro funkcionality. Plný marketplace by stál trojnásobek. Bez toho upřímného rozhovoru by dostal za 500 000 nedokončený projekt, se kterým by nemohl nic dělat.

Jak se tomu vyhnout: Požadujte rozfázovaný odhad. Pokud nemáte rozpočet na celý projekt, říkejte to otevřeně. Dobrý dodavatel navrhne, co se za daný rozpočet dá postavit.

Změny během vývoje

Změny jsou normální. Problém není v tom, že se zadání mění — problém je, když se mění bez vědomí dopadu.

„Přidejte ještě export do PDF” zní jednoduše. V praxi to může znamenat týden práce navíc. Deset takových „drobností” je dva měsíce zpoždění.

Jak změny fungují ve zdravém projektu:

1. Klient navrhne změnu — to je legitimní a běžné
2. Vývojář vyhodnotí dopad — kolik to stojí, jak to ovlivní termín, jestli to nenarušuje architekturu
3. Společné rozhodnutí — přidáme to a posuneme termín? Nebo to odložíme do další fáze?

Problém nastává, když se kroky 2 a 3 přeskočí a změny se tiše přidávají, dokud projekt nepřeteče přes všechny hranice.

Jak se tomu vyhnout: Zaveďte jasný proces pro změny. Žádná změna bez vyhodnocení dopadu. A mějte odvahu říct „to odložíme do fáze 2”.

Špatný návrh

Někdy je analýza dobrá, zadání jasné, rozpočet realistický — ale architektura systému je špatná. A špatnou architekturu pozná klient až za rok, kdy systém potřebuje novou funkci a vývojář řekne „to se nedá, museli bychom to přepsat.”

Špatný návrh se projevuje:

• Systém je pomalý — a nedá se to jednoduše opravit, protože je to v základech
• Každá změna rozbije něco jiného — kód je provázaný tak, že úprava na jednom místě způsobí problém na pěti dalších
• Nedá se rozšířit — nová funkce vyžaduje přepis poloviny systému
• Nejde nasadit postupně — všechno nebo nic

Jak se tomu vyhnout: Ptejte se dodavatele, jak přemýšlí o budoucnosti systému. Jak snadné bude přidat novou funkci za rok? Jak se systém chová pod zátěží? Profesionál na tyto otázky odpoví konkrétně.

Nedostatečné testování

„Vypadá to dobře, spustíme to.” A první den v produkci se ukáže, že registrace nefunguje na mobilu, platební brána odmítá karty s nestandardním formátem a report generuje špatná čísla.

Testování není volitelný krok. Ale firmy ho podceňují, protože:

• Stojí čas a peníze navíc
• Výsledek není vidět — žádná nová funkce, žádné nové tlačítko
• „Vždyť jsme to zkoušeli a funguje to”

Jenže „funguje” a „funguje spolehlivě pro všechny scénáře” jsou dvě zásadně odlišné věci.

Jak se tomu vyhnout: Vyžadujte, aby testování bylo součástí každé fáze vývoje. Ne jednorázová aktivita na konci. A zúčastněte se ho — nikdo nezná byznys scénáře lépe než vy.

Checklist: jak předejít selhání projektu

• Začínáme analýzou, ne kódováním
• Máme jasně definovaný rozsah první verze
• Rozpočet je realistický a obsahuje rezervu
• Máme jednoho zodpovědného člověka za rozhodování
• Dodavatel má jasný proces a komunikuje proaktivně
• Změny v zadání procházejí vyhodnocením dopadu
• Testování je součástí každé fáze, ne jednorázový krok na konci
• Myslíme na údržbu a provoz po spuštění
• Máme realistická očekávání — vývoj není lineární proces
• Komunikujeme průběžně, ne jen na začátku a na konci

Zaškrtli jste 8 a víc? Máte velmi dobré předpoklady pro úspěšný projekt. Méně než 5? Zastavte se a vyřešte mezery dřív, než investujete do vývoje.

Závěr

Software projekty neselhávají kvůli technologiím. Selhávají kvůli chybějící analýze, nejasným očekáváním, špatné komunikaci a podcenění toho, co vývoj obnáší. Dobrá zpráva je, že většině těchto problémů se dá předejít — stačí správný proces a upřímná komunikace od prvního dne.

Pokud plánujete softwarový projekt a chcete se vyhnout typickým pastem, rád si to s vámi projdu a řeknu vám, na co si dát pozor konkrétně ve vaší situaci.