Čo je discovery fáza projektu a kedy ju potrebujete
Discovery fáza pred vývojom spresní rozsah, priority, integrácie a riziká. Pozrite si, ako prebieha v praxi a čo z nej firma získava.

Čo je discovery fáza projektu?
Discovery fáza projektu je úvodná analytická a rozhodovacia etapa, v ktorej si firma s dodávateľom pred vývojom ujasní problém, cieľ, rozsah, riziká a spôsob realizácie. Jej účelom nie je projekt spomaliť, ale znížiť počet nákladných omylov počas samotnej realizácie.
V praxi ide o bod, v ktorom sa biznisová predstava mení na konkrétne zadanie. Nestačí vedieť, že firma potrebuje nový systém, aplikáciu alebo web. Potrebné je určiť, pre koho sa riešenie tvorí, ktorý proces má zlepšiť, čo patrí do prvej verzie, na čo sa musí napojiť a podľa čoho sa vyhodnotí úspech.

Discovery fáza preto odpovedá na otázky, ktoré sú pre projekt často rozhodujúce:
- Aký problém riešime a prečo je dôležitý práve teraz
- Kto bude systém používať a aké má reálne pracovné scenáre
- Ktoré funkcionality sú nevyhnutné a ktoré môžu počkať
- Aké technické, procesné alebo dátové obmedzenia existujú už dnes
- Či sa zámer dá postaviť v rozumnom čase, rozpočte a rozsahu
Pre firmy je podstatné aj to, že discovery nie je iba úvodné stretnutie. Nie je to štandardný kick-off ani krátky zber požiadaviek. Je to pracovná fáza, v ktorej sa triedia požiadavky, overujú predpoklady a pripravuje pevný základ pre delivery.
Najväčšia hodnota discovery spočíva v tom, že kľúčové rozhodnutia nevznikajú naslepo. Pri projekte ako CRM, interný portál, mobilná aplikácia, firemný web či AI automatizácia často rozhoduje o rozdiele medzi riešením, ktoré podporí reálny proces, a riešením, ktoré síce technicky funguje, ale nezasiahne potrebu firmy.
Ako discovery fáza projektu funguje v praxi?
Discovery v praxi prebieha ako séria riadených krokov, v ktorých zbierame informácie, pomenúvame priority, preverujeme realizovateľnosť a pripravujeme podklady pre vývoj. Výstupom nemá byť iba lepšia predstava, ale konkrétny plán: čo sa bude robiť, v akom poradí, pre koho a na akej technickej logike.
Typický priebeh vyzerá takto:
Zber kontextu a cieľov
Na začiatku sa pomenúva obchodný cieľ projektu, aktuálny stav, slabé miesta a očakávania vedenia aj tímov, ktoré budú riešenie používať.Rozhovory a workshopy so stakeholdermi
V tejto časti sa spresňujú procesy, výnimky, interné pravidlá, schvaľovania a praktické scenáre používania.Analýza procesov, dát a systémov
Tu sa preveruje, čo už vo firme existuje, odkiaľ prichádzajú dáta, kde vznikajú duplicity a aké API prepojenia systémov bude treba riešiť.Návrh riešenia a priorít
Tím rozdelí požiadavky na nevyhnutné, dôležité a voliteľné. Súbežne sa navrhuje používateľská logika, základ architektúry a prvá roadmapa.Výstupy pre delivery
Na konci býva jasnejší rozsah, zoznam funkcií, používateľské roly, integračné body, wireframy alebo prototyp, orientačný odhad náročnosti a odporúčané ďalšie kroky.
Ako vyzerá discovery na konkrétnom CRM projekte?
Firma chce CRM na mieru, pretože obchod beží cez e-maily, telefonáty a tabuľky. Na prvý pohľad ide o jednoduchú potrebu: evidenciu klientov. V discovery sa však často ukáže, že projekt zahŕňa aj leady z webu, follow-up pripomienky, schvaľovanie cenových ponúk, servisné požiadavky, prepojenie na fakturáciu a rozdielne prístupy pre obchod, servis aj manažment.

Až po takomto rozkrytí má zmysel rozhodovať o rozsahu prvej verzie. Pri menšom zadaní môže discovery trvať niekoľko dní a pár workshopov, pri komplexnejšom CRM, integračnom alebo produktovom projekte často 2 až 8 týždňov. Rozdiel je v miere neistoty, nie v názve projektu.
Aké typy discovery fázy existujú?
Discovery fáza nemá jednu univerzálnu podobu. Inak prebieha pri novom digitálnom produkte, inak pri CRM, redizajne webu alebo projekte s viacerými integráciami. Vždy sa má prispôsobiť miestu najväčšej neistoty: biznisu, používateľom, technológii, procesom alebo dátam.
Najčastejšie sa vo firemnej praxi stretávame s týmito podobami:
Biznisové discovery
Zameriava sa na cieľ projektu, priority vedenia, očakávaný prínos a hranice rozsahu. Je vhodné tam, kde existuje dobrý nápad, ale zatiaľ chýba jasné zadanie.Produktové a UX discovery
Rieši používateľov, pracovné scenáre, informačnú architektúru, obsah, používateľské toky a prototypy. Je dôležité pri aplikáciách, klientskej zóne alebo novom firemnom webe, kde nestačí iba pekný dizajn.Technické discovery
Overuje architektúru, technológie, integračné obmedzenia, bezpečnostné požiadavky, výkon a závislosti od tretích strán. Práve tu sa často ukáže, čo je vhodné riešiť v prvej fáze a čo neskôr.Procesné a integračné discovery
V centre pozornosti sú interné workflowy, ručné kroky, schvaľovania, dátové toky a napojenia na existujúce systémy. Typicky sa využíva pri CRM, ERP nadstavbách, zákazníckych portáloch či automatizáciách.Commerce discovery
Pri e-commerce projektoch rieši katalóg produktov, checkout, sklad, dopravu, platby, marketingové nástroje a prevádzkové scenáre. Najväčší zmysel má pri novom alebo prerábanom e-shope, kde nestačí rozhodnúť iba o šablóne a dizajne.

Dôležitý postreh je, že firma nemusí absolvovať všetky podoby v rovnakej hĺbke. Ak sú procesy jasné, ale neistota je v integráciách, discovery sa viac opiera o technickú analýzu. Ak je technológia zrejmá, no potreby používateľov nie sú dostatočne jasné, väčší priestor dostane UX a prioritizácia.
Preto je kvalitná discovery fáza skôr cielená než rozsiahla. Nezbiera informácie pre istotu, ale iba tie, ktoré posunú projekt k lepšiemu rozhodnutiu.
Kedy discovery fázu projektu naozaj potrebujete?
Discovery fázu potrebujete vtedy, keď je zlý odhad drahší než čas venovaný príprave. Platí to najmä pri projektoch s nejasným rozsahom, viacerými oddeleniami, integráciami, vlastnými procesmi alebo očakávaním, že riešenie bude rásť spolu s firmou.
V praxi je discovery veľmi užitočná, ak sa spoznávate v niektorej z týchto situácií:
- zadanie je zatiaľ opísané skôr víziou než konkrétnymi požiadavkami
- do projektu vstupuje viac stakeholderov s rozdielnymi očakávaniami
- systém sa má napojiť na ďalšie nástroje, databázy alebo externé služby
- firma chce nahradiť tabuľky, e-maily a ručné kroky vlastným workflowom
- rozpočet a termín sú dôležité, ale rozsah ešte nie je pevne určený
- pripravuje sa CRM, klientsky portál, interný nástroj, mobilná aplikácia alebo AI automatizácia
- vedenie chce rozhodovať podľa dát, nie podľa pocitu, čo by asi malo fungovať
Discovery naopak nezávisí od veľkosti firmy. Potrebuje ju aj menší tím, ak má zložité procesy alebo viac závislostí. Rovnako ju potrebuje väčšia firma, ak nechce prerábať nesprávne rozhodnutia až počas vývoja.
Z pohľadu realizácie ide často o najlacnejší spôsob, ako získať istotu pred vývojom. Namiesto toho, aby sa problémy odhaľovali počas programovania, identifikujú sa ešte pred začiatkom čerpania najdrahšej kapacity.
Ak potrebujete partnera, ktorý najprv rozkreslí procesy, dáta, priority a technické možnosti a až potom navrhne samotné riešenie, dáva zmysel začať krátkym úvodným rozhovorom s BeCode. Pri projektoch na mieru býva práve toto bod, v ktorom sa rozhoduje, či bude vývoj plynulý alebo plný zbytočných návratov.
Časté otázky
Aké aktivity a workshopy patria do discovery fázy?
Do discovery fázy najčastejšie patria stakeholder workshopy, rozhovory s používateľmi alebo internými tímami, mapovanie procesov, audit existujúcich systémov, analýza dátových tokov, prioritizácia požiadaviek, návrh používateľských scenárov a prvé wireframy či prototypy. Cieľom je zmeniť neurčitý nápad na zadanie, o ktorom sa dá rozhodovať.
Pre aké typy projektov je discovery fáza najdôležitejšia?
Najväčší prínos má pri projektoch, kde sa prepája viac procesov, rolí a systémov: CRM na mieru, interné nástroje, klientske portály, mobilné aplikácie, e-shopy, weby s komplexnejšou logikou a AI automatizácie. Čím viac nejasností a závislostí projekt obsahuje, tým väčší zmysel discovery dáva.
Čo je výstupom discovery fázy?
Výstupom discovery fázy zvyčajne nie je jedna poznámka zo stretnutia, ale súbor podkladov pre ďalšie rozhodnutie a vývoj. Typicky ide o spresnený rozsah, priority funkcií, popis používateľských rolí, návrh riešenia, integračné požiadavky, wireframy alebo prototyp, roadmapu a odhad ďalšieho postupu.


