Poptáte vývoj aplikace u tří dodavatelů a dostanete tři nabídky, které se nedají porovnat. První firma slibuje fixní cenu a pevný termín. Druhá navrhuje agilní spolupráci s hodinovou sazbou a dodává, že seriózní odhad předem prostě neexistuje. Třetí posílá tabulku, ze které není jasné vůbec nic.
Pokud jste v téhle situaci, máte oprávněný pocit, že srovnáváte jablka s hruškami. A přesně proto vzniká tenhle článek. Vysvětlíme v něm, co oba modely spolupráce skutečně znamenají, jaká rizika se za nimi skrývají a podle čeho se rozhodnout. Ne z pohledu metodické teorie, ale z pohledu firmy, která za software platí a potřebuje, aby jí fungoval.
Dopředu prozradíme závěr. Mezi agilním vývojem a fixní cenou nevede ostrá hranice dobra a zla, oba modely mají své místo. Rozdíl mezi povedeným a nepovedeným projektem obvykle nedělá zvolená metodika, ale kvalita analýzy, jasnost zadání a to, jak si s dodavatelem předem nastavíte pravidla pro změny.
Dva modely, dva různé druhy jistoty
Oba přístupy se snaží vyřešit stejný problém: nejistotu, která k vývoji softwaru neodmyslitelně patří. Nikdy totiž předem nevíte úplně přesně, co všechno projekt obnáší. Každý model tuhle nejistotu uchopí jinak. Fixní cena ji přesouvá na dodavatele, agilní vývoj ji přiznává a průběžně řídí.
Fix time & fix price: co přesně kupujete
Fix time & fix price znamená, že se s dodavatelem předem dohodnete na třech věcech najednou: co se udělá, za kolik a do kdy. Rozsah, cena i termín jsou zafixované ve smlouvě. Když dodavatel práci podcení, rozdíl jde za ním. Riziko špatného odhadu tedy nese on, ne vy.
Zní to jako ideální stav. Má to ale jednu zásadní podmínku: rozsah musí být opravdu přesně popsaný. Fixovat se dá jen to, co je jasně definované. Jakmile smlouva stojí na třech odstavcích obecného popisu, výsledek bude nejistý. Každá funkce, na kterou se při zadání zapomnělo, se později řeší jako vícepráce. A projekt, který začal jako fixní, postupně obroste dodatky, u kterých už žádnou vyjednávací pozici nemáte, protože měnit dodavatele uprostřed vývoje se prostě nevyplatí.
Proto seriózní fixní nabídka nikdy nevzniká z jednoho telefonátu ani z první schůzky. Vzniká z analýzy. Dodavatel musí nejdřív pochopit, jak vaše firma funguje, co má aplikace řešit, kdo s ní bude pracovat a kde jsou hranice první verze.
Agilní vývoj (time & materials)
V agilním modelu nekupujete předem sepsaný balík funkcí. Kupujete kapacitu vývojového týmu a průběžné výsledky. Vývoj běží v krátkých cyklech, obvykle dvoutýdenních (tzv. sprinty), a po každém cyklu vidíte funkční kus aplikace. Můžete si ho osahat, dát zpětnou vazbu a společně s dodavatelem rozhodnout, co se bude dělat dál.
Jistota tady nesedí v celkové ceně, ale v kontrole. Platíte za skutečně odvedenou práci, průběžně vidíte, co za své peníze dostáváte, a směr můžete kdykoli upravit. Když se ukáže, že polovina původně plánovaných funkcí nikoho nezajímá, jednoduše je neuděláte. Rozpočet místo toho věnujete tomu, co má skutečnou hodnotu. U fixního projektu byste je zaplatili, protože jsou ve smlouvě.
Agilní model má ovšem svou daň. Vyžaduje váš čas. Někdo na vaší straně musí pravidelně rozhodovat o prioritách, odpovídat na dotazy a dívat se na průběžné verze. Bez toho agilní vývoj prostě nefunguje.
Nejčastější mýty
Kolem obou modelů koluje pár tvrzení, která zní logicky, ale v praxi neplatí. Stojí za to si je vyjasnit dřív, než podle nich vyberete dodavatele.
„Fixní cena znamená, že neneseme žádné riziko.“ Riziko nikdy nezmizí, jen se přesune a přecení. Dodavatel si ho započítá do ceny jako rezervu, u nejasného zadání klidně dvacet až čtyřicet procent navíc. Platíte tedy pojistku proti vlastnímu nepřesnému zadání. A pokud dodavatel rezervu nedá a projekt se mu do rozpočtu nevejde, začne šetřit tam, kde to hned nevidíte: na testech, dokumentaci a kvalitě kódu. Účet za takové šetření přijde později, typicky ve chvíli, kdy každá další úprava aplikace něco dalšího rozbije. Proč se to děje a jak se tomu bránit, jsme podrobně popsali v článku o tom, jak poznat kvalitní vývoj softwaru.
„Agilní vývoj je bianco šek pro dodavatele.“ Špatně vedený agilní projekt tak skutečně dopadnout může. Dobře vedený je ale pravý opak. Každé dva týdny vidíte hotovou práci, víte, kolik stála, a můžete kdykoli říct dost. Paradoxně větší bianco šek podepisujete u špatně připraveného fixního projektu. Půl roku nevidíte nic a na konci teprve zjistíte, jestli dodavatel vaše zadání pochopil stejně jako vy.
„U velkých projektů je fixní cena bezpečnější.“ Intuice říká, že čím víc peněz, tím víc jistoty potřebujete. Praxe říká opak. Čím větší a delší projekt, tím víc se toho během vývoje změní: trh, legislativa, priority firmy i vaše vlastní představa o produktu. Rozsah zafixovaný v lednu může být v říjnu z poloviny zbytečný.
„Agilně znamená bez plánu a bez termínu.“ Agilní vývoj neznamená, že nikdo neví, kdy bude hotovo. Znamená, že se plánuje průběžně a po menších celcích, které se dají odhadnout mnohem spolehlivěji než celý projekt najednou. Dobrý dodavatel vám i v agilním režimu řekne, co reálně stihne do konce kvartálu a co ne.
Kdy dává smysl fixní cena a termín
Fixní model funguje dobře tam, kde se dá nejistota stlačit na minimum ještě před podpisem smlouvy. V praxi to znamená situace, kdy je rozsah menší a dobře popsatelný, proces, který digitalizujete, už ve firmě běží a všichni mu rozumí, a během vývoje se toho nejspíš moc nezmění.
Typickým příkladem je mikroaplikace pro jeden konkrétní proces: interní nástroj na schvalování dovolených, jednoduchý portál pro hlášení závad nebo formulářová aplikace napojená na jeden systém. Právě u nich je fixní rámec obvykle rozumný, protože rizika jsou přehledná a obě strany vědí, co se staví.
Fixní cena dává smysl i tehdy, když máte rozpočet, ze kterého nesmíte uhnout, třeba kvůli internímu schvalování nebo dotačnímu projektu. V takovém případě je ale o to důležitější investovat do pořádné analýzy před podpisem. Co všechno výslednou cenu ovlivňuje, rozebíráme v článku Kolik stojí vývoj aplikace na míru.
A ještě jedna situace, kde fixace funguje dobře: první fáze většího projektu. Jasně ohraničené MVP s pevnou cenou vám umožní ověřit spolupráci s dodavatelem na něčem hmatatelném, než se rozhodnete pro dlouhodobý vztah.
Kdy dává smysl agilní model
Agilní spolupráce se vyplatí všude tam, kde je nejistota přirozenou součástí projektu a fixace na papíře by ji reálně neodstranila.
Nejčastější případ je nový produkt. Stavíte něco, co na trhu v této podobě není, a teprve ověřujete, co uživatelé skutečně potřebují. Fixovat rozsah v této fázi znamená fixovat vlastní domněnky. A pak je draze všechny zrealizovat, včetně těch mylných. Iterativní postup vám naopak dovolí levně zjistit, co funguje, a rozpočet směřovat podle skutečné zpětné vazby.
Druhý typický případ jsou projekty s těžko odhadnutelnými částmi. Integrace na systémy třetích stran, u kterých nikdo přesně neví, v jakém stavu je jejich dokumentace. Funkce postavené na AI, kde se výsledná kvalita ladí experimentováním. Migrace dat z letitého systému, který zná jen jeden člověk ve firmě. Tam, kde se pracnost nedá seriózně odhadnout, je fixní cena buď risk dodavatele, a nebo zbytečně předražený projekt.
A třetí případ, na který se často zapomíná: dlouhodobý rozvoj aplikace, která už běží. Po spuštění se pevný rozsah definuje čím dál hůř, protože priority určuje provoz. Rozhoduje to, co říkají uživatelé, co ukazují data a co zrovna potřebuje obchod. Pravidelný rytmus iterací s jasně řízeným zásobníkem požadavků tu funguje výrazně lépe než smlouvání o každé změně zvlášť. S provozem souvisí i údržba, monitoring a podpora a s ní související potřeba mít s dodavatelem vyřešenou podobu SLA a servisních služeb.
Podmínkou zůstává vaše zapojení. Pokud na své straně nemáte nikoho, kdo bude věnovat vývoji pár hodin týdně, agilní model vám hodnotu nepřinese.
Jak se teda rozhodnout?
Hybridní model: jistota rozpočtu i prostor pro změny
V praxi se nám nejvíc osvědčuje nestavět oba modely proti sobě, ale kombinovat je podle fáze projektu. Typický průběh vypadá takto.
Na začátku stojí placená analýza s jasným výstupem. Než padne jakékoli číslo, je potřeba pochopit, jak firma skutečně funguje, co má software řešit a co naopak řešit nemá. Výstupem analýzy je zadání, návrh řešení a podložený odhad. Takový dokument má hodnotu sám o sobě, i kdybyste se nakonec rozhodli pro jiného dodavatele.
Na analýzu navazuje první fáze za fixní cenu a termín. Jasně ohraničené MVP, u kterého fixace dává smysl. Vy získáte jistotu rozpočtu a hmatatelný výsledek v dohledném čase, dodavatel má zadání, za které může ručit. Průběžně přitom vidíte funkční verze a dáváte zpětnou vazbu. Fixní cena totiž nemusí znamenat, že půl roku nevíte, co se na straně vývoje děje.
Jakmile aplikace běží, přechází projekt do agilního rozvoje. Zpětná vazba z provozu je vždycky cennější než rok starý dokument, takže další funkce se prioritizují podle skutečných potřeb, ne podle původního plánu. A paralelně běží provoz podle servisní smlouvy: monitoring, bezpečnostní aktualizace a podpora v předem dohodnutém režimu.
Na co se ptát dodavatele, než podepíšete smlouvu
Ať už vám dodavatel nabízí kterýkoli model, jeho odpovědi na několik otázek prozradí o budoucí spolupráci víc než název metodiky v nabídce.
Zeptejte se, z čeho vychází cena. Seriózní fixní nabídka stojí na analýze, ne na dojmu z jedné schůzky. Pokud vám někdo zafixuje cenu rozsáhlého systému po hodinovém hovoru, nekupujete jistotu. Kupujete jeho ochotu riskovat, a to obvykle na váš účet.
Zeptejte se, jak se řeší změny zadání. Chtějte konkrétní mechanismus: jak se změna ocení, kdo ji schvaluje a co se stane s termínem. Odpověď „to se pak nějak domluvíme“ je varovný signál v obou modelech.
Zeptejte se, jak často uvidíte funkční výsledek. Čekat na první ukázku tři měsíce je zbytečné riziko i u fixního projektu. Průběžné verze nejsou vlastnost agilního vývoje, ale ukazatel dobrého dodavatele.
Zeptejte se, co je v ceně kromě samotného programování. Testy, dokumentace, nasazení, záruční opravy a podpora po spuštění. Právě tady se nejčastěji schovává rozdíl mezi levnou a férovou nabídkou.
A zeptejte se, komu bude patřit kód a data. Správná odpověď je, že vám. Cokoli jiného si nechte podrobně vysvětlit, protože to zásadně ovlivňuje vaši budoucí nezávislost na dodavateli.
Model spolupráce jako nástroj
Fix time & fix price vám dá jistotu rozpočtu, ale jen tehdy, když stojí na kvalitní analýze a přesném zadání. Agilní vývoj vám dá kontrolu a flexibilitu, ale jen tehdy, když se do projektu sami zapojíte. Ani jeden model není univerzálně lepší a ani jeden vás nezachrání před dodavatelem, který neumí naslouchat, odhadovat a průběžně vykazovat výsledky.
Praktické doporučení na závěr? Menší a jasně definované projekty fixujte. U nejistých a dlouhodobých projektů plaťte za iterace a výsledky. U větších záměrů oba přístupy kombinujte: fixní první fáze po důkladné analýze a agilní rozvoj potom. A dodavatele vybírejte podle toho, jak odpovídá na nepříjemné otázky, ne podle toho, jak se prezentuje v nabídce.
Řešíte, jestli je pro váš projekt lepší fixní nabídka, nebo agilní spolupráce? Napište nám a projdeme s vámi zadání. Pomůžeme vám posoudit, jaký model spolupráce dává pro váš projekt smysl. Jak podobné projekty vypadají v praxi, si můžete prohlédnout v našich referencích. A pokud jste teprve ve fázi výběru dodavatele, pomůže vám i naše IT poradenství.
