Rád bych zde na fóru rozvířil diskusi ohledně tématu, které mi v souvislosti s pirátským programem přijde velmi důležité. Jak známo, statní (ale i soukromé, lze aplikovat klidně i na Piráty jako takové) zakázky na dodávky SW jsou dlouhodobě zdrojem problémů, neefektivity a vyhozených finančních prostředků.
Nejprve krátký úvod
Jako logické řešení výše uvedeného problému se nabízí na všechny takové zakázky uskutečňovat kvalitně připravená výběrová řízení, která zajistí, že ten, kdo výběrko vyhraje, bude vhodným dodavatelem. Zde ale narážíme na problém. Ve světě softwaru se již poměrně dlouho tuší, že tzv. waterfall model, často navíc spojený s fix time -- fix price zadáním v mnoha projektech selhává.
Důvodem je především to, že vývoj softwaru není to samé jako vyrábění bot. Každý software je jedinečný a jeho výroba je svým způsobem blíž kreativní tvorbě než repetitivnímu výrobnímu procesu. Proto je takřka vždy nemožné odhadnout, kolik práce vývoj zakázky nakonec zabere. Dodavatelé to tedy řeší jedním z následujících způsobů:
- do cenové nabídky si dají dostatečný buffer, aby v případě problémů "neprotekli"
- jdou do vlastního rizika a doufají, že to nějak vyjde
- zakázku raději odmítnou než riskovat reputační riziko, nebo ztrátu peněz
- nabobtnání nákladů na několikanásobek
- prodloužení délky implementace na několikanásobek
- soudní spory mezi objednatelem a dodavatelem
Jak to řešit jinak
Již dlouhou dobu se ví, že výše uvedené problémy jsou inheretně spojeny s waterfallem a v rámci jeho konceptu nemají žádné řešení. Jako odpověď na to vzniklo v roce 2001 Agile manifesto, které doporučuje k vývoji softwaru přistupovat zcela jinak. Klíčové charakteristiky tzv. agilního vývoje jsou mj.:
- vývoj je iterativní, v každém cyklu se odbaví kousek (tzv. sprinty)
- upfront analýza se nedělá, stačí mít big picture a analýzu dělat v rámci každé iterace
- testování je průběžné v každé iteraci
- na konci každé iterace je software v produkční kvalitě a potenciálně ho lze vypustit na veřejnost
- klíčové je sledování business value a rizik: nejprve se implementuje to nejpodstatnější a eliminuje se tím častý jev u waterfallu, kdy se čas mnohdy utrácí na kravinách
- kontrakty nejsou na dodávku celku, ale na jednotlivé iterace
- objednatel může kdykoliv říct "stop, tohle už mi stačí"
Pokud máte pochybnosti jestli tohle lze aplikovat na cokoliv většího než eshopy, tak vězte, že to lze. Použili ho např. v FBI při implementaci softwaru na sledování jednotlivých casů, další info např. zde a zde.
Další info o tom jak to funguje lze nalézt třeba tady.
Super, takže proč je tady tohle vlákno?
S agilním vývojem je ale jeden problém. A to konkrétně ona zmiňovaná výběrová řízení. Narozdíl od FTFP projektů, kdy se dají kritéria jako cena a délka dodání napsat do podmínek, u agile vývoje tohle jednoduše nejde. Znovu zmiňuji: kontrakty se neobjednávají na celou dodávku, ale na odvedenou práci. A to je problém. Jak tohle zakotvit do výběrka?
Nad problémem jsem chvíli uvažoval a jediné co mě napadlo by byl následující mechanismus:
- nad zakázkami by drželo záštitu např. ministerstvo informatiky
- ministerstvo by si objednávalo jednotlivé dodavatelské týmy
- primárním hodnotícím kritériem jsou: reference, cena za MD, zkušenosti
Napadá vás jak tomu přistoupit nějak jinak?
Díky za pozornost. Pojďme být leadery i v přístupu k SW zakázkám!
