Úvod
Chci pomoci se zadáním
Tvorba zadáníŠipkaWaterfall

Co je Waterfall?

Způsob vývoje softwaru, při kterém na začátku znáte kompletní zadání, termíny a cenu. Vyžaduje proto před zahájením obrovskou přípravu, aby bylo možné odhadnout všechny proměnné, které proces přinese. Špatně definované počáteční zadání přenáší velké množství rizika na dodavatele a na celkový úspěch projektu.

Co je Waterfall?

Výhody Waterfallu

  • Předem stanovený fixní plán
  • Predikovatelnost rozsahu projektu, ceny a postupu
  • Lépe měřitelné, zda se zakázka zpožďuje, či je v předstihu
  • Snadnější koordinace práce a subjektů

Nevýhody Waterfallu

  • 87 % projektů nedodrží kvůli špatnému zadání rozsah, čas nebo rozpočet
  • Fixní rozsah již před začátkem zakázky znamená riziko víceprací
  • Těžce se zanášejí změny
  • Potřeba velice detailního návrhu již na začátku projektu

1. Rozděl role na zakázce

Důležité: Na každou roli je dobré vybrat JINÉHO DODAVATELE. Analytik, vývojář i dozor by měl být pro vzájemnou kontrolovatelnost vždy od tří různých firem či vývojářských agentur. Potřebujete-li s kritérii, dle kterých jakou roli vybrat poradit, neváhejte se obrátit na naší asociaci.

*jednotlivé role jsou pro zjednodušení reprezentovány jako jednotlivec, jedná se však o firmy nebo společnosti.

Analytik

Analytik

Vytváří základní komponenty projektu. Výsledky jeho analýz jsou veřejné, což především v případě státních zakázek zajišťuje kontrolovatelnost, závaznost a tlak na kvalitu. Jeho cílem je pro projekt vytvořit:

  • Byznys analýzu

    Validuje nápad a vytváří základní rámec pro digitální produkt (odpovídá například na otázky kolik má být dodavatelů, jaké jsou části systému, jak má vypadat uživatelské rozhraní...).

  • Technickou analýzu

    Hledá správné technologické řešení a vytvoří detailní specifikaci, podle které dokáže programátor programovat.

Programátor

Programátor

Vyvíjí samotný software, který je mu předán formou technické a byznys analýzy vytvořené Analytikem. Dopředu definuje milníky, na jejichž základě pravidelně předává Zadavateli splněné části zakázky.

Stavební dozor

Stavební dozor

Slouží jako kontrolní mechanismus, aby nedocházelo k úzce definovanému zadání, které by vysoutěžila pouze firma zaměstnávající Analytika. Zároveň sleduje úroveň výstupů Analytika i Programátora. Dozor musí mít stejnou úroveň znalostí a schopností jako Analytik.

Dozorčí rada

Dozorčí rada

Je sestavena ze Zadavatele zakázky, Analytika, Stavebního dozoru. Jejím úkolem a účelem je rozhodnout o výběru Programátora, podmínek akceptace dílčích dodávek softwaru a také stanovit situace odstoupení od smlouvy s Programátorem.

2. Rozdělte zakázku na fáze

1. Vytvořte výběrové řízení pro analytika a stavební dozor

1. Vytvořte výběrové řízení pro analytika a stavební dozor

Doporučujeme vybírat tyto role na základě referencí a případových studií z podobných zakázek. Nebojte se ale také kontaktovat naší asociaci, která s výběrem těchto rolí ráda pomůže.

2. Sestavte dozorčí radu

2. Sestavte dozorčí radu

Dozorčí rada je seskupení Zadavatele, Analytika a Stavebního dozoru.

3. Vyberte Programátora

3. Vyberte Programátora

Po vytvoření analýzy sestavte na základě doporučení Analytika výběrové řízení na firmu, která vyvine váš produkt. O výběru Programátora rozhoduje právě výše zmíněná Dozorčí rada.

4. Kontrolujte jednotlivé milníky

4. Kontrolujte jednotlivé milníky

Výstupy Programátora akceptuje Dozorčí rada, která porovnává stav analýzy a reality. Dozorčí rada akceptuje jednotlivé Milníky vývoje prezentované Programátorem.

5. Provoz a rozvoj

Je třeba myslet dopředu na to, že váš software bude potřebovat pravidelnou údržbu, popř. rozvoj a tvorbu nových funkcí. Zajistěte si tedy provoz a rozvoj dalších funkcí systému ideálně od stejného dodavatele. Promyslete, jak bude probíhat předání a akceptace a jak následně bude probíhat údržba systému.

Důležité:Provoz a rozvoj systému by naopak měl ideálně zabezpečit STEJNÝ DODAVATEL jako vývoj pro ušetření nákladů a dodržení kvality. To ale neznamená, že by se na provoz a rozvoj nemělo dělat výběrové řízení.

3. Můžete vybrat různé dodavatele na různé moduly

Důležité: Jak tomu rozumět? Vývojářské studio by se například nemělo starat o chod call centra, ačkoliv je na něj v aplikaci odkaz a je lepší soutěžit tuto roli zvlášť. Na druhou stranu, pokud vysoutěžíte jednoho dodavatele na frontend, jiného na backend a třetího na vývoj mobilní aplikace, může nastat zásadní problém při komunikaci mezi subjekty a zbavování se zodpovědnosti. Analytik by měl tyto problémy dopředu odhadnout a dle toho navrhnout soutěžení částí.

Často nemusí být celá zakázka realizována pouze jedním dodavatelem. Analytik by měl rozhodnout, které části je dobré ponechat na jednom dodavateli a které je lepší soutěžit zvlášť.

4. Definujte MVP – minimalistickou životaschopnou verzi

Ne vždy je potřeba mít hned v prvním vydáním projektu všechny představitelné funkce.

Popište tedy analytikovi 1-3 problémy, které má váš produkt řešit a spolu s ním definujte MVP (minimum viable product), který budou uživatelé pár měsíců testovat a na základě kterého se budou upravovat detaily ke spokojenosti všech. Na zbytek funkcí se pak naplánují další fáze vývoje.

5. Pohlídejte si licenční a technologické parametry softwaru

Důležité: Jak tomu rozumět? Firma se uchází o tendr a navrhuje vytvořit řešení v zastaralém programovacím jazyku, ve kterém programuje již pouze hrstka lidí na trhu. Hrozí tak, že po dokončení prací nebude nikdo jiný schopen tento systém dále udržovat a rozvíjet a zadavatel se stává rukojmím dodavatele. To vývojářské firmě umožňuje libovolně navyšovat cenu své práce za byť i minimální úpravy systému. Úkolem Analytika a Stavebního dozoru je toto riziko eliminovat.

Pokud se jedná o vývoj na zakázku, je nezbytné, aby licence připadla zadavateli.

Pokud se jedná o “krabicový předpřipravený SW”, tedy to, co není vyvinuto na zakázku, je zásadní zjistit detailně podmínky a cenu licence. Zejména pak závislost ceny a počtu uživatelů, počtu instancí, stažení, počtu dokumentů, počtu připojení.

Postavte řešení na otevřených technologiích, aby produkt a zadavatel nebyli rukojmím dodavatele.

6. Nehodnoťte jen dle ceny

Obzvláště u softwaru neplatí, že čím levnější, tím lepší, mnohdy je to přesně naopak. Proto je třeba zařadit i jiná vyhodnocovací kritéria, která ideálně určí Analytik v souladu s Dozorčí radou. Může se jednat o předchozí reference či kvalitu kódu a použité architektury.

Mějte softwarový svět v malíku

Přihlaste se k newsletteru. Žádný spam. Jen důležité novinky.