Kako pripremiti projekt za razvoj aplikacije (vodič za uspjeh prije prvog reda koda)

Najbolji projekti ne počinju kad razvojni tim počne kodirati. Počinju 4 – 8 tjedana ranije, kad klijent napravi pripremni rad tj. famozni Project Scope koji 90 % drugih klijenata preskoči. Razlika je dramatična — projekti s dobro pripremljenim klijentom završe u roku, projekti s nepripremljenim klijentom kasne mjesecima i koštaju puno više.

Dobra vijest: priprema nije teška. To nije pisanje 50-stranične specifikacije. To je nekoliko jasnih dokumenata i nekoliko donesenih odluka. Ovaj vodič razlaže točno što napraviti prije nego što potpišete ugovor s razvojnim timom — i zašto to štedi tisuće eura kasnije.

Zašto priprema toliko važna

Loša priprema je razlog zašto:

• Projekti kasne 30 – 50 % od početne procjene
• Budžeti se prebijaju za 20 – 60 %
• Tijekom razvoja treba 5 – 10 puta više sastanaka nego što je trebalo
• Tim i klijent se međusobno frustriraju jer “drugi ne razumije”
• Konačni proizvod ne radi ono što je klijent zamišljao

Sve te probleme možete spriječiti za 4 – 8 tjedana pripreme prije razvoja, što je dramatično jeftinije od 12 tjedana zbunjenosti tijekom razvoja.

Korak 1: Definicija problema u jednoj rečenici (1 dan)

Prije bilo čega drugog: napišite jednu rečenicu koja opisuje problem koji rješavate.

Ne dvije rečenice. Ne odlomak. Jednu rečenicu.

Slabe primjere:

• “Trebamo platformu za digitalizaciju našeg poslovanja”
• “Želimo modernizirati način kako radimo s klijentima”
• “Trebamo aplikaciju za bolju efikasnost”

Jake primjere:

• “Naš tim troši 6 sati tjedno ručno šaljući statuse projekata klijentima preko e-maila.”
• “Naši klijenti ne mogu vidjeti dostupne termine bez da nas zovu telefonom, što gubi 40 % rezervacija u nerealnom vremenu.”
• “Voditelji prodaje gube prosječno 2 sata dnevno tražeći podatke razasute između 5 različitih sustava.”

Slabi opisi su općeniti. Jaki opisi su konkretni — imaju brojke, vrijeme, frekvenciju, posljedicu.

Test koji odvaja jedno od drugog: ako tri osobe u vašem timu napišu istu rečenicu kad ih pitate “koji problem rješavamo?” — imate dobru definiciju. Ako pišu različite stvari — niste još tu.

Korak 2: Definirajte korisnike (2 – 3 dana)

Aplikacija nikad nije za “sve”. Aplikacija je za specifične ljude koji rade specifične stvari.

Što napisati za svakog tipa korisnika:

• Tko su (uloga, kontekst, demografija)
• Što sad rade umjesto vašeg rješenja
• Koliko puta tjedno bi koristili aplikaciju
• Koje će akcije obavljati
• Koje informacije trebaju vidjeti
• Što se mijenja u njihovom radu kad imaju ovu aplikaciju

Primjer (B2B portal za konzultantsku tvrtku):

Korisnik 1: Klijent

• Voditelj projekta u srednjoj tvrtki, korisnik vaših konzultantskih usluga
• Sad: prima e-mail statuse jednom tjedno, traži dokumente preko e-maila
• Frekvencija: 2 – 4 puta tjedno
• Akcije: pregled statusa, preuzimanje dokumenata, eventualno postavljanje pitanja
• Informacije: status projekta, sljedeći koraci, lista dokumenata, fakture

Korisnik 2: Voditelj projekta s vaše strane

• Konzultant u vašoj tvrtki
• Sad: ručno šalje e-mailove i WhatsApp poruke
• Frekvencija: 5 – 10 puta dnevno
• Akcije: postavljanje statusa, upload dokumenata, slanje notifikacija
• Informacije: pregled svih svojih projekata, popis dokumenata, log aktivnosti

Korisnik 3: Administrator

• Voditelj operacija u vašoj tvrtki
• Sad: nema centraliziran pregled
• Frekvencija: 1 – 2 puta tjedno
• Akcije: dodavanje novih klijenata, postavljanje uloga, pregled statistike
• Informacije: pregled svih klijenata, korisnika, audit logi

Bez ovog dokumenta, razvojni tim će dizajnirati za apstraktnog “korisnika”. To gotovo nikad ne radi.

Korak 3: Glavni korisnički tijekovi (3 – 5 dana)

Što korisnik konkretno radi od početka do kraja? Mapirajte 3 – 5 ključnih tijekova korak po korak.

Format:

Tijek 1: Klijent provjerava status svojih projekata

1. Klijent dobiva e-mail notifikaciju da postoji novi update
2. Klijent klikne link u e-mailu, prebacuje se na portal
3. Login (ako nije već prijavljen)
4. Vidi dashboard s listom svojih projekata
5. Klikne na projekt s novim updateom
6. Pregleda novi status i dokumente
7. Eventualno postavlja pitanje voditelju projekta

Svaki korak je potencijalno mjesto za odluku, dizajn, friction. Mapiranje ovoga unaprijed znači:

• Razvojni tim točno zna što gradi
• Vi unaprijed identificirate korake gdje korisnik može odustati
• Dizajn može optimizirati svaki korak
• Procjena trajanja postaje realnija

Najveći benefit: kad razvojni tim pita “što se točno događa kada korisnik…?”, imate odgovor unaprijed. Ne morate sazvati sastanak da odlučite. Razvoj se ne zaustavlja.

Korak 4: Lista “što ne radimo” (1 dan, ali težak)

Najvažniji dokument u projektu. Zašto težak: jer morate odustati od ideja koje volite kako biste lansirali u realnom vremenu.

Format:

Što ne radimo u v1:

• NE gradimo mobilnu aplikaciju (samo responsive web)
• NE radimo integraciju s ERP sustavom (planirano za v2)
• NE podržavamo SSO (samo standardna autentikacija)
• NE gradimo chat funkcionalnost (e-mail i telefon ostaju)
• NE gradimo izvještajni dashboard za upravu (samo basic listu)
• NE podržavamo više jezika (samo hrvatski)
• NE gradimo automatske podsjetnike (manualne notifikacije za sad)

Zašto je ovaj dokument tako moćan:

• Sprječava scope creep tijekom razvoja
• Daje jasan odgovor kada netko predloži “možemo li samo dodati…”
• Definira jasan v1 — proizvod koji možete lansirati za 4 mjeseca, ne za 12
• Stavlja v2 funkcionalnosti u backlog (gdje pripadaju), ne u sadašnji projekt

Test koji to provjerava: pokažite listu trima ljudima u svom timu. Ako se nitko ne pobuni protiv neke stavke — vjerojatno niste dovoljno hrabri u odlukama. Lista koja bolne za odustajanje od dijelova obično je realna.

Korak 5: Tehnička pitanja koja morate odgovoriti (3 – 5 dana)

Razvojni tim trebat će odgovore na stvari koje vi vjerojatno niste razmišljali. Bolje pripremiti odgovore unaprijed nego improvizirati tijekom razvoja.

Pitanja koja se uvijek postavljaju:

• Korisnička autentikacija: kako se korisnik prijavljuje? E-mail i lozinka? Google login? Magic link?
• Plaćanja (ako su relevantna): koje načine plaćanja podržavate? Kartice? SEPA? Mjesečne pretplate?
• Notifikacije: kako notificirate korisnike? E-mail? SMS? Push notifikacije? In-app?
• Izvještavanje: koje izvještaje korisnici trebaju? Tjedne? Mjesečne? PDF? Excel?
• Integracije: s kojim vanjskim sustavima se aplikacija povezuje? CRM? ERP? Slack? Calendar?
• Multi-tenancy: imate li jednu instancu za sve klijente, ili svaki klijent ima zaseban prostor?
• Privatnost podataka: GDPR? Specifične zahtjeve industrije?
• Hosting: imate li preferencije gdje aplikacija živi? EU? Hrvatska?

Ne morate na sva pitanja imati odgovor. Ali na 70 % ih morate imati prije nego što razvojni tim krene s discoverijem. Ostalo se može razjasniti tijekom discoveryja, ali ako je sve nepoznato, discovery će trajati duže nego treba.

Korak 6: Vizualni materijali (5 – 10 dana)

Dizajneri rade brže kad imaju početni materijal. Što više vizualnih primjera možete prikupiti unaprijed, to bolje.

Što prikupiti:

• Vaš branding: logo, boje, fontovi, ako postoje
• Reference koje volite: 5 – 10 stranica i aplikacija koje izgledaju “ovako bi trebalo biti”
• Reference koje ne volite: 2 – 3 primjeri kako ne bi trebalo izgledati i zašto
• Konkurentski proizvodi: što rade dobro, što loše
• Postojeći materijali: stari logo, marketinški materijali, brošure, vizitke

Format: Notion stranica, Google Doc, ili Figma board — sve gdje se može lako referencirati.

Ovo nije “želim da izgleda baš ovako”. Ovo su signali dizajneru o vašem osjećaju i preferencijama. Bez ovih signala, dizajner improvizira i vi pet puta govorite “to nije ono što sam zamišljao”.

Korak 7: Internalna dogovaranja (1 – 2 tjedna)

Najmanje glamurozan, ali možda najvažniji korak. Prije nego što počnete s vanjskom agencijom, dogovorite se interno.

Koje odluke morate donijeti unutra:

• Tko je vlasnik proizvoda? Jedna osoba s ovlasti za odluke o opsegu, dizajnu, prioritetima.
• Tko se odaziva na pitanja u 24 sata? Razvojni tim će imati pitanja. Tko odgovara?
• Tko ima ovlast promjenjivati opseg? Mora biti jasno.
• Tko sudjeluje na demo sastancima? Mora biti dosljedno isti tim, ne rotacija.
• Kako vi donosite odluke kad se ne slažete interno? Komitet? Glasanje? Ja kažem zadnju riječ?
• Što je apsolutni minimum koji proizvod mora raditi? Pristanite na to interno prije nego što razgovarate izvan.
• Što je apsolutni maksimum budžeta i roka? Ne marketinška brojka — pravo crveno linija.

Realan signal da niste spremni: ako svaki put kad razvojni tim nešto pita, vi morate “provjeriti s upravom” i odgovor stigne za tjedan. To je projekt koji će kasniti 50 % bez bilo koje druge greške.

Korak 8: Kratki interni brief (3 – 5 stranica)

Sve gore staje u jedan dokument. Ne 50 stranica. 3 – 5 stranica koji opisuju projekt na visokoj razini.

Predložak:

PROJEKT: [Naziv]

PROBLEM:
[Jedna rečenica problema]

CILJANE OSOBE:
- Korisnik 1: [opis]
- Korisnik 2: [opis]

GLAVNI TIJEKOVI:
1. [Tijek 1 ukratko]
2. [Tijek 2 ukratko]
3. [Tijek 3 ukratko]

ŠTO RADIMO U V1:
- [funkcionalnost 1]
- [funkcionalnost 2]
- ...

ŠTO NE RADIMO U V1:
- [izričito izostavljeno 1]
- [izričito izostavljeno 2]
- ...

USPJEH IZGLEDA OVAKO:
- [Konkretan mjerljivi rezultat 1]
- [Konkretan mjerljivi rezultat 2]

TEHNIČKE NAPOMENE:
- [Bitne odluke ili ograničenja]

BUDŽET I ROK:
- Budžet: [raspon]
- Rok: [datum]

DECISION MAKERS:
- Vlasnik proizvoda: [ime, kontakt]
- Tehnička pitanja: [ime, kontakt]
- Eskalacija: [ime, kontakt]

Ovaj dokument pošaljete agenciji kao prvi materijal. Razlika između prvog razgovora s agencijom uz ovaj dokument i prvog razgovora bez njega je dramatična. Sa: razgovor je o specifičnostima i rješenjima. Bez: razgovor je o osnovama koje biste već trebali znati.

Korak 9: Razgovor s 2 – 3 agencije (1 – 2 tjedna)

Ne biljke s prvom agencijom. Razgovarajte s 2 – 3, dajte im isti brief, usporedite kako reagiraju.

Što tražite u razgovoru:

• Postavljaju li nezgodna, konkretna pitanja?
• Predlažu li alternative vašim pretpostavkama?
• Spominju li trade-offove?
• Govore li o stvarima koje neće raditi?
• Imaju li slične projekte u portfolju?
• Tehnički razgovor s nekim tko stvarno gradi (ne samo prodajnim ljudima)?

Detaljnije o ovome pišemo u članku Kako odabrati agenciju za razvoj web aplikacije.

Što izbjegavati u pripremi

Pisanje 50-stranične specifikacije. Više dokumenata ne znači bolja priprema. Dokumenti koje nitko ne čita su gori od kratkih dokumenata koji se redovito referenciraju.

Definiranje detalja koje treba odlučiti tim. Niste vi ti koji odlučujete koji framework koristi. Vi odlučujete o problemu i opsegu — tim odlučuje o tehnologiji.

Pretpostavljanje da znate što korisnici žele. Razgovarajte s 5 stvarnih korisnika prije nego što finalizirate brief. Otkrit ćete pretpostavke koje su pogrešne.

Beskonačno usavršavanje briefa. Brief mora biti “dovoljno dobar” za razgovor s agencijom, ne savršen. Ostatak će se razjasniti u discoveryju. Mjesec posvećen pisanju briefa koji se nakon razgovora ipak mijenja je izgubljeno vrijeme.

Ignoriranje internih dogovaranja. Najbolji brief na svijetu propada ako vaš interni tim nije usklađen. Provjerite to prije izlaska prema agencijama.

Realan timeline pripreme

Za standardan projekt:

Ukupno: 8 tjedana priprema prije nego što ijedan red koda postoji.

Zvuči puno? Da. Ali alternativa je 12+ tjedana zbunjenosti tijekom razvoja, kasnijeg roka i prebijenog budžeta. Priprema je investicija s najvišom stopom povrata u cijelom projektu.

Suština

Najbolji razvojni projekti počinju prije razvoja. Devet koraka pripreme — definicija problema, korisnici, tijekovi, lista “što ne radimo”, tehnička pitanja, vizualni materijali, internalna dogovaranja, brief, razgovori s agencijama — može trajati 4 – 8 tjedana, ali štedi mjesece kasnije.

Najveće zamke: pisanje preopsežne specifikacije, definiranje tehnoloških odluka koje treba tim, ignoriranje internih dogovora, krenuti s prvom agencijom bez usporedbe.

Najpametniji pristup: tretirajte pripremu kao prvi korak razvoja, ne kao formalnost. 8 tjedana ovog rada vrijedno je 80.000 € trošak razvoja. Klijenti koji to naprave dobivaju proizvode u roku, u budžetu, koji rade ono što stvarno trebaju. Klijenti koji preskoče — ne dobiva tako često.

Pripremate projekt razvoja i želite ga dovesti u dobru poziciju prije nego što potpišete ugovor? Možemo s vama proći discovery razgovor u kojem ćemo strukturirati vaše ideje, identificirati ključna pitanja i pomoći vam pripremiti brief koji će izgladiti put razvoju. Javite nam se. Više o našem pristupu pogledajte na stranici Razvoj web aplikacija.