Dohodli jste se v zásadě na tom, že zakázkový software dává pro vaši firmu smysl. Proběhl první rozhovor s vývojářskou firmou a všechno vypadá slibně. Pak přijde věta: „Začneme discovery fází."
Pro mnoho majitelů firem to je moment, kdy přichází zmatek. Co to vlastně znamená? Jak dlouho to potrvá? Proč prostě nezačnou rovnou vyvíjet?
Tento článek vysvětluje, jak discovery fáze vypadá z vaší strany stolu — co se skutečně děje, co budete potřebovat udělat a co byste měli mít na konci v ruce.
Co je discovery fáze
Discovery fáze — někdy nazývaná sběr požadavků, analýza nebo scoping — je strukturovaný proces zjišťování toho, co přesně je potřeba postavit, ještě než kdokoli napíše jediný řádek kódu.
Jde o pracovní fázi, nikoli administrativní. Probíhají skutečné rozhovory. Přijímají se skutečná rozhodnutí. A výsledkem není jen dokument — je to sdílené pochopení mezi vaším týmem a vývojovým týmem o tom, co má systém dělat, proč to má dělat a jak to má fungovat.
Dobře provedená discovery eliminuje nejdražší typ softwarového problému: postavit špatnou věc. Cena za změnu směru během vývoje se měří v týdnech a rozpočtu. Cena za změnu směru během discovery se měří v hodinách.
Co se během discovery děje
Discovery zpravidla trvá dva až šest týdnů u většiny projektů podnikového softwaru, u komplexních nebo rozsáhlých systémů může být delší. Takto vypadá tato doba v praxi.
Strukturované rozhovory a workshopy
Discovery proces je silně zaměřen na rozhovory. Budete se setkávat s vývojovým týmem — zpravidla s business analytikem, solution architektem a někdy UX designérem — a procházet strukturovanou sadu otázek.
Tyto rozhovory pokrývají mnoho oblastí: jak vaše současné procesy vypadají, kde jsou bolestivá místa, kdo systém používá a jak, jaké jsou výjimky a okrajové případy, jak vypadá úspěch a jaká omezení máte (rozpočet, termíny, regulatorní požadavky, stávající systémy).
Nepřekvapujte se, pokud budou otázky širší, než jste čekali. Dobrý analytik se nebude ptát pouze na povrchní požadavky, ale bude zkoumat hlubší obchodní problém. Řešení, které jste popsali v zadání, může být přesně správné — nebo může existovat lepší přístup, který se ukáže, až bude celý obrázek viditelný.
Mapování současného stavu
Než tým navrhne nový systém, potřebuje porozumět tomu, co existuje dnes — formálnímu i neformálnímu. To znamená zdokumentovat, jak vaše procesy skutečně fungují, ne jak by fungovaly podle papírů.
Tady na majitele firem čeká překvapení: rozdíl mezi dokumentovaným procesem a skutečnou praxí je téměř vždy větší, než se čekalo. Lidé si vytvořili vlastní postupy, neformální nástroje (nejčastěji tabulky v Excelu) a znalosti, které nikdy nebyly nikde zaznamenány. Discovery toto vše vynoří na povrch.
Definice budoucího stavu
Jakmile je současný stav pochopen, rozhovor se přesune k budoucnosti. Co má nový systém dělat? Jak má vypadat práce s ním pro uživatele? Co jsou must-have, co jsou nice-to-have a co je explicitně mimo rozsah?
Zde se píší požadavky — nikoli jako rigidní specifikace, která zamrazí každý detail, ale jako strukturovaný popis toho, čeho má systém dosáhnout. Dobré požadavky obsahují i obchodní logiku za každou funkcí, nejenom funkci samotnou. Tento kontext umožňuje vývojářům přijímat správná rozhodnutí, když se v průběhu vývoje vyskytnou okrajové případy.
Technické posouzení
Souběžně s obchodními rozhovory technický tým hodnotí architekturu: s čím se systém musí integrovat, jaké požadavky na výkon nebo bezpečnost platí, jak vypadá prostředí pro nasazení a jaká technická rizika existují.
Pro vás jako klienta je to z velké části neviditelné, ale přímo to ovlivňuje přesnost odhadu, který na konci dostanete.
Co je potřeba přinést do discovery
Discovery je spolupráce. Vývojový tým přináší strukturu a metodologii; vy přinášíte znalost svého podnikání. Ani jedna strana to bez té druhé nezvládne.
Dostupnost správných lidí. Největší příčinou pomalé nebo povrchní discovery je absence správných lidí. Ten, kdo podepisuje smlouvu, není vždy ten, kdo ví, jak procesy v praxi fungují. Zapojte lidi, kteří práci skutečně dělají, spolu s těmi, kdo rozhodují.
Otevřenost vůči nepořádným částem. Každá firma má procesy, které jsou trapně manuální, systémy, kterým nikdo úplně nerozumí, nebo postupy závislé na znalostech jednoho člověka. Discovery funguje nejlépe, když jsou tyto věci vyneseny na světlo, nikoli skryty. Žádné hodnocení tu nehrozí — jde jen o užitečné informace.
Jasnost ohledně omezení. Rozpočet a termín nejsou témata, kterým je třeba se vyhýbat. Pokud existuje pevný termín nebo finanční strop, řekněte to hned na začátku. To formuje, co tým může realisticky navrhnout. Dobrý vývojový partner navrhne řešení v rámci vašich omezení, ne že bude předstírat, že neexistují.
Trpělivost s procesem. Majitelé firem někdy vnímají discovery jako frustraci, protože to vypadá jako zdržení. Instinkt je začít budovat. Ale čas strávený ve fázi discovery se téměř vždy vrátí v průběhu vývoje — a často několikanásobně. Projekt, který přeskočí discovery a okamžitě začne vyvíjet, téměř jistě vynaloží více času a peněz na pozdější opravy.
Co byste měli mít na konci
Dokončená discovery fáze by vám měla přinést několik konkrétních výstupů, nejen pocit sdíleného pochopení.
Funkční specifikace. Tento dokument popisuje, co systém bude dělat — funkce, pracovní postupy, obchodní logiku, uživatelské role a integrace. Nejde o technický plán (ten přijde později), ale je dostatečně konkrétní na to, abyste ho mohli zkontrolovat, opravit a s jistotou odsouhlasit.
Drátěné modely nebo uživatelské toky. U většiny systémů určených pro klienty nebo komplexních interních systémů discovery přináší hrubé vizuální náčrty toho, jak bude rozhraní fungovat. Nejde o design — jde o strukturu. Abstraktní požadavky se stávají konkrétními a odhalují mezery, které písemné popisy přehlédnou.
Orozsahovaný a oceněný odhad. Jakmile je rozsah definován, vývojový tým může vydat přesný odhad. Toto číslo je zásadně jiné než přibližný rozpočtový rozsah, který mohl zaznít na začátku — vychází ze skutečných požadavků a je základem pro smlouvu na projekt.
Prioritizovaný seznam funkcí. Dobrá discovery přináší i jasnost v tom, co je nejdůležitější. Pokud rozpočet nebo termín vyžadují zúžení rozsahu, měli byste vědět přesně, které funkce jsou pro produkt klíčové a které mohou počkat na pozdější fázi.
Časté obavy — a upřímné odpovědi
„Přesně víme, co chceme. Proč trávit týdny analýzou?"
Někdy firmy skutečně vědí přesně, co potřebují, a discovery je v takovém případě kratší. Ale i tehdy potřebuje technický tým dostatečně hluboce porozumět požadavkům, aby mohl přesně odhadnout a správně postavit. Otázka není, zda discovery proběhne — ale kolik jí je potřeba.
„Dělali jsme to i bez discovery fáze."
Některé projekty formální discovery přeskočí a přesto uspějí — zpravidla tehdy, kdy je rozsah velmi úzký, tým má zkušenosti s podobnými systémy nebo jsou požadavky skutečně jednoduché. Ale většina překročení rozpočtu a sporů o rozsah v softwarových projektech se přímočaře váže k požadavkům, které nebyly na začátku správně definovány.
„Může být discovery součástí hlavní smlouvy?"
Ano, a v mnoha případech by tak mělo být. Některé vývojářské firmy nabízejí discovery jako samostatný závazek se separátní smlouvou. To oběma stranám umožňuje zhodnotit pracovní vztah ještě před závazkem k plnému vývoji — což je zpravidla chytřejší struktura, zejména pokud s partnerem spolupracujete poprvé.
Poznámka k firmám, které to přeskakují
Pokud vývojářská firma nabídne okamžité zahájení vývoje bez jakéhokoliv procesu zjišťování požadavků, zpozorněte. Není to nutně varovný signál — některé týmy pracují iterativně a některé projekty jsou skutečně dostatečně jednoduché. Ale mělo by to vyvolat otázku: jak budou vědět, co postavit?
Pokud je odpověď „přijdeme na to za pochodu", tento přístup přenáší riziko na vás. Iterativní vývoj funguje, ale vyžaduje dohodnutý backlog, pravidelné přezkoumání a strukturovaná rozhodnutí o rozsahu a prioritách. Neformálnost není totéž co agilita.
Nejlepší vývojové partnery nepovažují discovery za režijní náklady, ale za základ důvěryhodného projektu. Když víte, co stavíte a proč, ještě před zahájením vývoje, je vše, co následuje, předvídatelnější — termín, náklady i výsledek.
Každý softwarový projekt začíná rozhovorem. Discovery fáze zajišťuje, aby ten rozhovor zašel dostatečně hluboko — ještě než začne tikot hodin drahé části.