Jak připravit zadání softwarového projektu

Napište dvě až tři věty o tom, co dnes nefunguje a koho se to týká. Například obchodní tým přepisuje údaje ze dvou systémů a po opravě objednávky neví, který záznam platí. To je lepší začátek než požadavek na nový dashboard: z problému lze odvodit potřebná data, odpovědnosti i správný první test. Přidejte, jak často situace nastává a co stojí v čase, chybách nebo ztracených příležitostech. Pokud nemáte čísla, označte odhad jako odhad.

Uveďte, co má být po projektu jinak pro konkrétního člověka. Kdo zadává informaci, kdo ji schvaluje a kdo řeší výjimku? Popište jednu běžnou cestu a jednu situaci, kdy se něco pokazí. Rozlišujte povinný výsledek od nápadu na řešení. Tím umožníte porovnat úpravu stávajícího systému, integraci a nový produkt podle stejného cíle. Technologii nemusíte vybírat předem; pokud už je daná smlouvou či prostředím, napište proč.

Seznamte systémy, z nichž proces čerpá, a vlastníka každého důležitého údaje. Pro každý přenos napište, kdo může číst, kdo může měnit a co se stane, když druhá strana neodpoví. U plateb odlište přijatou žádost od potvrzeného výsledku; u interního CRM určete, kdo opravuje nesoulad; u AI vysvětlete, zda může jen navrhovat, nebo také vykonávat akce. Přidejte příklady vstupů bez skutečných osobních údajů a označte informace, které se nesmějí posílat do veřejných nástrojů.

Omezení napište jako fakta, která ovlivní návrh: používaný software, licence, smluvní rozhraní, počet uživatelských rolí, požadované jazyky, práce v terénu, dostupnost a interní pravidla. Nejasné položky neskrývejte. Vedle každé napište, kdo ji ověří a kdy. Pokud je projekt v regulovaném prostředí, uveďte odpovědnou osobu pro právní a bezpečnostní posouzení; obecná nabídka dodavatele sama neurčuje konkrétní povinnosti. Zaznamenejte také závislosti na jiných týmech a případný termín, který má skutečný obchodní důvod.

Vyberte jednu klíčovou uživatelskou cestu, kterou lze dokončit od začátku do konce. Uveďte, co přesně znamená úspěch, jak se projeví chyba a kdo výsledek schválí. První verze nemusí obsahovat všechny role, reporty a automatizace, ale nemůže ignorovat identitu, citlivá data, základní obnovu nebo chování při výpadku, pokud jsou pro danou cestu kritické. Součástí zadání může být malý pilot či technické ověření největší neznámé ještě před plnou implementací.

Napište tři měřitelné signály úspěchu. Mohou to být počet ručních přepisů, čas vyřízení požadavku, podíl chybně spárovaných záznamů nebo dokončení důležitého kroku uživatelem. U každého určete dnešní výchozí stav, nebo plán, jak ho získat. Vyvarujte se slibu procentního zlepšení bez dat. Při výběru první verze se ptejte, co by bylo možné po měsíci ukázat a co by tento výsledek změnil na dalším rozhodnutí.

Do prvního e-mailu nebo formuláře stačí šest položek: problém a jeho dopad, hlavní uživatelé, dnešní proces a systémy, důležitá omezení, jedna očekávaná cesta první verze a kontaktní osoba pro rozhodnutí. Přidejte, zda už existuje podklad, který lze bezpečně sdílet. Nezasílejte hesla, neveřejné klientské údaje ani produkční exporty. Neznámé otázky označte otevřeně. Dobrá úvodní poptávka má umožnit smysluplný rozhovor, ne předstírat úplnou jistotu.

Při rozhovoru požádejte o návrh první ověřovací etapy, potřebné vstupy od vás, způsob odhadu a předání. Ptejte se, jak bude tým zacházet se změnou rozsahu, chybovým stavem a provozní odpovědností. Cena a termín dávají smysl až vzhledem k dohodnutému rozsahu a známým závislostem; přesnou cenu z obecného návodu nelze poctivě odvodit. Na konci si zapište, kdo dodá chybějící fakta, jaký bude další výstup a podle čeho rozhodnete, zda pokračovat. Pokud odpověď stále závisí na neznámém rozhraní nebo kvalitě dat, sjednejte krátké technické ověření se srozumitelným výstupem. Písemně zachyťte rozhodnutí a předpoklady, aby příští jednání nezačínalo od nuly.