Každý program bude jen tak dobrý, jak dobré je zadání k němu. Nepodceňujte proto strategickou přípravu. Čím přesnější budou vámi požadované parametry, tím lépe bude výsledná architektura odpovídat reálným potřebám. Zadání má pomoci vývojářům pochopit, proč nový software vzniká, jaké problémy a komu pomůže řešit a jaké cíle má plnit.

„Dobře připravené zadání není jen technický dokument, ale základní kontrolní mechanismus vendor managementu, který mění vágní přání na měřitelné výsledky. Měl by určovat, kdo má jaké kompetence, a bránit nabobtnání iterací a rozsahu do monstrózních rozměrů,“ vysvětluje Karel Diviš.

První a nejdůležitější otázkou není, co má software dělat, ale jaký konkrétní byznys problém má vyřešit a jaký přínos má mít pro společnost. Příliš obecné cíle (např. „zvýšit efektivitu“) mohou vést k alibismu během vývoje. V zadání je nutné specifikovat, kdo konkrétně bude software používat, jak je technicky zdatný a jak bude s novou aplikací pracovat. Uveďte také, zda v oboru existuje nějaký benchmark nebo řešení, kterým se chcete inspirovat.

Specifikace funkcionalit musí být vždy podřízena strategickému řízení rozsahu. Největší riziko z prodražení a zpoždění plyne z pokusu dodat vše najednou. Rozdělte proto požadavky na MUST HAVE (funkcionality nezbytné pro start), SHOULD HAVE (důležité pro druhou fázi) a COULD HAVE (nápady pro budoucí rozvoj).

Zadejte dodavateli, co je naprosté minimum pro spuštění první funkční verze. To slouží jako pevný milník. 

„Určete předem, zda jsou všechny funkcionality nutné ihned při spuštění, nebo je můžete doplnit později. Díky prioritizaci je možné spustit zjednodušenou funkční verzi, tzv. MVP (neboli Minimum Viable Product), kterou lze postupně rozšiřovat. Je to často levnější a snáze odladíte funkční chyby,“ radí Diviš.

Technické a provozní parametry nejsou jen funkční požadavky, ale kritické smluvní závazky, které určují budoucí náklady na údržbu a rizika. V zadání uveďte, s jakými existujícími systémy (CRM, ERP, Sklad) je potřeba novou aplikaci propojit, zda k nim máte API a jak bude probíhat synchronizace dat. Zmiňte vývojářům i požadavky, které souvisí s legislativou ve vašem oboru (například GDPR, NIS2, OWASP). Zmiňte, jakou zátěž, tedy kolik uživatelů nebo jaký datový tok, musí systém zvládat.

„Z požadavků na funkčnost by mělo vyplynout, zda potřebujete webovou, nebo mobilní službu. Neméně důležité je určit si, jak chcete aplikaci provozovat, zda v cloudu, on-premise nebo hybridně. Případně vám s tím vendor může poradit,“ dodává Diviš. „Nepodceňte ani nároky na výkon a uživatelskou přívětivost. Jinak může vzniknout software, který neobstojí při větší zátěži nebo je složitý na používání. To vše by měla architektura programu zohlednit.“

Bez jasného postupu pro práci se změnami dochází k tzv. scope creepu, tedy bobtnání práce a rozsahu bez změn v termínech a rozpočtu. Zadání musí definovat: kdo změnu navrhuje, kdo ji schvaluje a jaký dopad má schválená změna na rozpočet a termín. To je základní obranou proti nekontrolovatelnému růstu nákladů.

Definujte také jasné, ověřitelné podmínky, které musí hotový software splnit, aby mohl být považován za dokončený a převzatý. Tím kontrolujete výsledek, nikoli jen proces.

„Hodně nedorozumění vzniká v komunikaci. Proto v zadání jasně napište také, jaké jsou vaše možnosti, kolik lidí například může aplikaci testovat. Kdy potřebujete mít různé fáze spuštěné, a – to je základ, na který se zapomíná – kdo úkoly schvaluje, kdo má rozhodovací pravomoc a jak s vývojáři bude v kontaktu,“ uzavírá Diviš.