Radionica za otkrivanje i definiranje web aplikacije: kako postavljamo opseg, rizike i realan plan

# Što ćete naučiti#

Radionica discoveryja za web aplikaciju je mjesto gdje opseg postaje konkretan, rizici se otkrivaju rano, a isporuka se pretvara u plan koji se zaista može provesti.

Ovaj vodič prikazuje praktičan discovery proces koji koristimo u Samiodi, uključujući mapiranje dionika, korisničke tokove, tehnička ograničenja i metrike uspjeha. Također ćete dobiti predloške i checkliste koje možete kopirati u vlastiti workflow.

Ako još birate partnera, pročitajte Kako odabrati agenciju za razvoj weba. Ako procjenjujete vanjsku isporuku, Vodič za outsourcing web razvoja pomaže postaviti očekivanja prije potpisivanja.

# Zašto radionica discoveryja sprječava prekoračenja#

Većina prekoračenja događa se zbog predvidljivih razloga: nejasan opseg, skrivene ovisnosti, propušteni dionici i nerealni rokovi. Discovery to smanjuje tako što tjera na rane odluke, dok su još jeftine.

Industrijski podaci dosljedno pokazuju da su kasne promjene skupe. Često citirani nalaz iz Boehmove krivulje troška promjene kaže da rješavanje problema kasnije može koštati red veličine više nego rješavanje rano. Čak i ako se vaš tim ne drži striktno te krivulje, operativna stvarnost je jasna: kad kod već postoji, promjena smjera znači prepravke kroz dizajn, razvoj, QA i koordinaciju.

Radionica discoveryja za web aplikaciju nije “kazalište planiranja”. To je strukturiran način da se proizvede:

• zajednička definicija uspjeha
• opseg usklađen s vremenskim i budžetskim ograničenjima
• roadmap isporuke upravljan rizicima
• backlog napisan tako da ga inženjeri mogu implementirati, a QA provjeriti

🎯 Ključna poruka: Discovery je najjeftiniji trenutak za eliminirati loše ideje, smanjiti neizvjesnost i spriječiti prepravke u svakoj sljedećoj fazi.

# Kada vam treba discovery, a kada ga možete preskočiti#

Discovery je najvrjedniji kada je istinito barem jedno od sljedećeg:

• Više od 2 skupine dionika treba se uskladiti, npr. operacije, prodaja, compliance i IT.
• Aplikacija ima integracije, npr. pružatelje plaćanja, ERP-ove, CRM-ove, identity providere ili interne API-je.
• Postoji neizvjesnost oko MVP-a, modela cijena ili ciljnih korisničkih tokova.
• Imate fiksan budžet ili fiksan datum lansiranja.
• Nefunkcionalni zahtjevi su važni, npr. sigurnost, audit logovi, performanse, dostupnost ili rezidentnost podataka.

Discovery često može biti “lagan” kada:

• gradite mali interni alat s jednim vlasnikom i jasnim workflowima
• već imate validirane dizajne i detaljnu, testabilnu specifikaciju
• nema integracija ni značajnih compliance potreba

Praktičan pristup je vremenski ograničiti discovery. Ako se jasnoća pojavi brzo, stanete. Ako neizvjesnost ostaje, produžite uz jasan cilj.

# Format discovery radionice koji koristimo#

Discovery najbolje funkcionira kao kombinacija kratkih radnih sesija i offline sinteze. Većina timova je produktivnija s 2 do 4 sesije, svaka 60 do 120 minuta, nego s jednim dugim sastankom.

Preporučeni raspored i sesije#

ℹ️ Napomena: Discovery ne zamjenjuje disciplinu procesa isporuke. On je temelj. Ako vam je lifecycle isporuke slab, krenite s jasnim procesom poput našeg vodiča: Proces razvoja weba korak po korak.

# Korak 0: Pre-discovery intake i priprema#

Prije radionice tražimo assete i pristupe. Tako vrijeme radionice ostaje fokusirano na odluke, a ne na “arheologiju”.

Checklist ulaznih informacija od klijenta#

Ako nešto nedostaje, i dalje nastavljamo, ali to eksplicitno bilježimo kao rizik ili pretpostavku.

⚠️ Upozorenje: Čest način propadanja je krenuti u razvoj s “integracije ćemo riješiti kasnije”. Integracije obično nose najveću neizvjesnost i najviše vanjske ovisnosti, pa ih treba validirati rano.

# Korak 1: Usklađivanje dionika i pravila donošenja odluka#

Usklađivanje dionika je mjesto gdje većina projekata “tiho” propada. Ne zato što se ljudi ne slažu, nego zato što prava odlučivanja nisu jasna.

Predložak mape dionika#

Koristite ovu tablicu za hvatanje uloga i sprječavanje kasnih veta.

Checklist pravila odlučivanja#

1. 1
   Definirajte “jednog odgovornog vlasnika” za odluke o opsegu.
2. 2
   Definirajte što traži formalno odobrenje, npr. promjena budžeta, promjena roka ili sigurnosne promjene.
3. 3
   Definirajte rokove za review, npr. review dizajna u 48 sati, review backloga u 72 sata.
4. 4
   Definirajte eskalaciju: tko presijeca kad se product i engineering ne slažu.

Samo ovo smanjuje klizanje rokova jer “čekanje povratne informacije” postaje mjerljivo i provedivo.

# Korak 2: Definirajte problem, a ne popis funkcionalnosti#

Popisi funkcionalnosti su primamljivi jer djeluju konkretno. No obično miješaju simptome i rješenja.

Jasnoću forsiramo kroz tri izlaza:

• izjavu problema (problem statement)
• ciljeve i nečiljeve (goals i non-goals)
• ograničenja i pretpostavke

Predložak izjave problema#

Napišite jedan odlomak i držite ga mjerljivim.

• Trenutna situacija: što se danas događa
• Bol: što puca, koga pogađa i koliko često
• Utjecaj: trošak, kašnjenja, izgubljen prihod ili rizik
• Željeni ishod: što se mijenja nakon lansiranja

Primjer strukture:

• “Danas {{user}} izvršava {{workflow}} koristeći {{tools}}, što traje {{time}} i uzrokuje {{issues}}. Želimo smanjiti {{metric}} za {{target}} unutar {{timeframe}}.”

Ciljevi, nečiljevi, ograničenja#

# Korak 3: Korisnički tokovi i kriteriji prihvaćanja#

Korisnički tokovi prevode nejasne ideje u implementabilan opseg. Fokusiramo se na nekoliko tokova koji stvaraju većinu vrijednosti.

Praktično pravilo je mapirati:

• 3 do 5 primarnih tokova
• 2 do 3 “break glass” rubna slučaja po toku
• uključene podatkovne objekte

Predložak korisničkog toka#

Checklist “Definition of Done” za svaki tok#

💡 Savjet: Ako napišete kriterije prihvaćanja tijekom discoveryja, procjena postaje brža i točnija. Inženjeri procjenjuju nejasnoću, ne trud.

# Korak 4: Tehnička ograničenja i kontekst sustava#

Ovdje discovery postaje stvaran. Većina web aplikacija nije “samo React frontend”. To je sustav s identitetom, podacima, integracijama i operacijama.

Pitanja o kontekstu sustava koja kasnije štede tjedne#

Primjer: hvatanje nefunkcionalnih zahtjeva#

Brzi vodič za odluku o tech stacku#

Obično usklađujemo odabir stacka s ograničenjima:

• React i Next.js za brzu iteraciju, SSR gdje treba i snažan ekosustav.
• Flutter kada trebate dijeljeni codebase za mobile i web i kada je UI konzistentnost važna.
• n8n za automatizaciju workflowa i orkestraciju integracija, posebno kada se poslovna logika često mijenja.

Ključ nije alat, nego odabrati ga prema operativnim ograničenjima, zapošljavanju i dugoročnoj održivosti.

# Korak 5: Metrike uspjeha i plan mjerenja#

Ako ne možete mjeriti uspjeh, ne možete upravljati opsegom. Metrike pretvaraju “bilo bi lijepo” u “radi li to ono što treba”.

Definiramo tri sloja:

• poslovne metrike, npr. prihod, churn, konverzija
• produkt metrike, npr. activation rate, time-to-first-value
• operativne metrike, npr. support ticketi, vrijeme obrade, stopa grešaka

Predložak metrika#

Također definiramo konvencije imenovanja evenata i minimalne zahtjeve praćenja kako se analytics ne bi odgađao unedogled.

# Korak 6: Registar rizika i plan mitigacije#

Svaki projekt ima rizike. Razlika je u tome vidite li ih dovoljno rano da možete djelovati.

Predložak registra rizika#

Dobra discovery radionica ne eliminira rizik. Ona ga čini eksplicitnim i moguće ga je planirati u budžetu.

# Korak 7: Kako discovery pretvoriti u roadmap koji se može isporučiti#

Roadmap nije slajd. To je slijed ishoda, s ovisnostima i vjerodostojnom procjenom.

Definicija MVP-a koja izdrži pritisak#

MVP definiramo kao:

• najmanji skup tokova koji daje mjerljivu vrijednost
• uz nefunkcionalne zahtjeve potrebne za stvarno korištenje
• uz integracijske stubove ili stvarne integracije, ovisno o riziku

Ako stavka ne podržava primarni tok ili kritični nefunkcionalni zahtjev, ide u Phase 2.

Predložak roadmapa#

Procjena: učinite pretpostavke eksplicitnima#

Procjene padaju kad su pretpostavke skrivene. Pretpostavke vežemo direktno uz stavke opsega.

Primjeri eksplicitnih pretpostavki:

• “API pruža webhook za promjene, inače polling dodaje 1 tjedan.”
• “SSO koristi OIDC, ne SAML, inače setup dodaje 3 do 5 dana.”
• “Klijent dostavlja copy do 3. tjedna, inače se dovršetak UI-ja pomiče.”

Ako želite širu sliku kako se ovo uklapa u isporuku, pogledajte Proces razvoja weba korak po korak.

# Deliverablei koje klijenti trebaju očekivati od discovery radionice#

Discovery bi trebao završiti artefaktima koje možete odmah koristiti, čak i ako kasnije promijenite vendor. To je snažan signal kvalitete.

Checklist deliverablea#

⚠️ Upozorenje: Budite oprezni ako vendor ponudi procjenu nakon jednog poziva bez dokumentiranja pretpostavki. Takva procjena je obično prodajni broj, ne broj za isporuku.

# Predlošci koje možete kopirati u svoj sljedeći discovery#

Dizajnirani su da budu praktični i lagani. Zalijepite ih u Notion, Confluence ili Google Docs.

Predložak dnevnog reda (agenda) za discovery#

1. 1
   Kontekst i ciljevi
2. 2
   Korisnici i primarni tokovi
3. 3
   Podaci i integracije
4. 4
   Ograničenja i nefunkcionalni zahtjevi
5. 5
   Rizici i otvorena pitanja
6. 6
   MVP opseg i prioriteti
7. 7
   Sljedeći koraci i vlasnici

Predložak loga otvorenih pitanja#

Checklist guardrails za MVP opseg#

1. 1
   Svaka funkcionalnost mora podržavati primarni tok ili kritični NFR.
2. 2
   Svaki epic mora imati kriterije prihvaćanja i mjerljiv uspjeh.
3. 3
   Svaka integracija mora imati test plan i fallback ponašanje.
4. 4
   Svaki novi zahtjev mora biti kategoriziran kao MVP, Phase 2 ili odbijen, uz obrazloženje.

# Kako discovery smanjuje prepravke i budžetska iznenađenja#

Discovery smanjuje prekoračenja uklanjanjem dva skupa obrasca: izgradnju pogrešne stvari i ponovnu izgradnju ispravne stvari na pogrešan način.

Česti izvori prepravki i discovery rješenje#

Praktičan način kvantificiranja učinka je pratiti change requestove i njihove uzroke. Ako discovery smanji change requestove za samo 20 do 30 posto, često se brzo isplati, posebno na projektima s više integracija.

# Ključne poruke#

• Vodite radionicu discoveryja za web aplikaciju kao vremenski ograničen proces koji proizvodi odluke, a ne samo bilješke.
• Rano mapirajte dionike i prava odlučivanja kako biste spriječili uska grla u odobravanju u kasnoj fazi.
• Prevedite opseg u korisničke tokove s kriterijima prihvaćanja, uključujući rubne slučajeve i nefunkcionalne zahtjeve.
• Dokumentirajte tehnička ograničenja i integracije unaprijed, jer oni upravljaju arhitekturom i rizikom rokova.
• Završite discovery s konkretnim deliverableima: MVP backlog, roadmap, registar rizika i procjena s eksplicitnim pretpostavkama.
• Koristite predloške poput registra rizika i loga otvorenih pitanja kako biste smanjili prekoračenja i prepravke kroz cijelu isporuku.

# Zaključak#

Radionica discoveryja za web aplikaciju najbrži je način da ideju pretvorite u plan spreman za isporuku, s jasnim opsegom, mjerljivim metrikama uspjeha i realnim roadmapom.

Ako želite da Samioda facilitira vaš discovery i izradi roadmap prema kojem vaš tim može graditi, kontaktirajte nas i podijelite svoj context brief. Odgovorit ćemo s predloženim formatom radionice, vremenskim okvirom i točnim deliverableima koje možete očekivati.