Od ideje do lansiranja: kako stvarno izgleda razvoj proizvoda u vremenu

“Koliko će trajati?” prvo je pitanje koje svaki osnivač postavi i najteže za iskreno odgovoriti. Iskren odgovor — “ovisi” — nije zadovoljavajući. Ali vremenski okvir izgrađen na lažnoj preciznosti je gori.

Razlog zašto su iskreni rokovi rijetki jest taj što su komercijalno neugodni. Agencije navedu kratki rok da dobiju posao, osnivači pretpostavljaju kratki rok da umire investitore, a interni timovi prihvaćaju kratki rok da izbjegnu pritisak vodstva. Svi imaju razlog skratiti broj, a nitko nema razloga ga produžiti — sve dok projekt ne krene i stvarni opseg ne postane vidljiv. Tada je renegocijacija bolan razgovor koji svi radije odgađaju, pa tim potajno počinje rezati uglove.

Evo kako stvarni razvoj proizvoda zaista izgleda, faza po faza, s vremenskim rasponima koji odgovaraju stvarnosti — ne prodajnim prezentacijama.

Iskren vremenski okvir

Za prvu verziju digitalnog proizvoda (web aplikacija, SaaS alat ili platforma), s fokusiranim timom od 3 do 5 ljudi:

Ovo pretpostavlja fokusiran opseg (jedan ključni problem, jedan tip korisnika), kompetentan tim i donositelja odluka koji može brzo odobriti dizajne i postaviti prioritete.

Faza 1: Discovery i scoping (1–2 tjedna)

Ovdje većina projekata postavlja temelje uspjeha ili tiho jamči neuspjeh. Cilj nije sve dokumentirati — cilj je nemilosrdno razjasniti četiri pitanja:

1. Koji problem rješavamo?
2. Tko ima taj problem?
3. Što prva verzija mora raditi?
4. Što izričito NE gradimo?

Rezultati: Izjava o problemu, profil ciljnog korisnika, dokument o opsegu, lista “ne radimo”, preporuka o tehničkoj arhitekturi.

Česta greška: Provesti 4–6 tjedana na discoveryju. Ako vam treba dulje od dva tjedna da definirate što gradite, opseg je prevelik ili problem nije dovoljno jasan. Produljeni discovery gotovo uvijek je simptom izbjegavanja — tim ne želi pristati na opseg jer pristajanje znači rezanje, a rezanje je neugodno. Lijek nije više istraživanja; to je donošenje odluke s informacijama koje već imate.

Faza 2: Dizajn (2–4 tjedna)

Dizajn i razvoj trebaju se preklapati, ali dizajn treba prednost. Cilj je definirati korisničko iskustvo prije nego što se napiše kod — ne stvarati savršene mockupove svakog ekrana.

Tjedan 1: Wireframeovi ključnog korisničkog puta. Niska razina detalja, fokus na tijek i hijerarhiju informacija. Pregled sa stakeholderima i korisnicima.

Tjedan 2: UI dizajn primarnih ekrana. Postavite vizualni jezik — boje, tipografiju, razmake, obrasce komponenti. Izgradite mali design system, ne sveobuhvatan.

Tjedni 3–4 (ako je potrebno): Sekundarni ekrani, rubni slučajevi, responzivni layouti. Korisničko testiranje s klikabilnim prototipom.

Česta greška: Dizajnirati svaki ekran prije početka razvoja. Dizajnirajte ključno putovanje prvo, pa sekundarne ekrane paralelno s razvojem. Dizajn u izolaciji od engineeringa način je da se završi s prekrasnim mockupovima koje je skupo implementirati. Svaki ekran dizajniran prije nego što se napiše kod ulog je — a opklade koje uspijevaju jesu one gdje su dizajner i inženjer pričali tijekom procesa, ne one gdje je Figma bačena preko zida.

Faza 3: Razvoj sprint 1 (3–4 tjedna)

Prvi sprint gradi kostur: ključni model podataka, autentikaciju korisnika, primarni korisnički tijek i infrastrukturu.

Do kraja sprinta 1, trebate imati radnu aplikaciju koja od početka do kraja obrađuje ključni slučaj korištenja. Neće biti lijepa. Neće obraditi rubne slučajeve. Ali korisnik se može prijaviti, izvršiti primarnu radnju i vidjeti rezultat.

Što se gradi:

• Šema baze i API sloj
• Autentikacija i osnovno upravljanje računom
• 2–3 ekrana koji čine ključni tijek
• Osnovni deployment pipeline (staging okruženje)

Česta greška: Pokušati graditi sve odjednom umjesto isporučiti kritičnu putanju prvo. Ako ključni tijek ne radi, ništa drugo nije važno. Druga zamka u ovoj fazi jest pretjerano dotjeravanje arhitekture — provođenje sprinta 1 na mikroservise, redove i multi-region infrastrukturu za proizvod koji još nije validirao prvog korisnika. Uvijek možete refaktorirati u sofisticiraniju arhitekturu kada postoji opterećenje koje to opravdava; ne možete uvijek refaktorirati šest izgubljenih tjedana natrag u kalendar.

Faza 4: Razvoj sprint 2 (3–4 tjedna)

Sprint 2 dodaje značajke koje proizvod čine upotrebljivim za stvarne ljude: notifikacije, postavke, izvoz podataka, integracije, obradu grešaka i responzivni dizajn.

Ovo je i mjesto gdje proizvod počinje izgledati dotjerano. Tranzicije, loading stanja, prazna stanja, poruke o uspjehu — detalji koji odvajaju prototip od proizvoda.

Što se gradi:

• Sekundarne značajke iz dokumenta o opsegu
• Integracije trećih strana (plaćanje, e-mail, analytics)
• Obrada grešaka i rubnih slučajeva
• Responzivni dizajn i mobilna optimizacija
• Admin panel ili dashboard (ako je potrebno)

Česta greška: Dodavati značajke koje nisu bile u izvornom opsegu. Sprint 2 je za dovršavanje plana, ne za njegovo proširenje. Nove ideje idu u v2 backlog. Sprint 2 je i faza u kojoj je tim najviše u iskušenju spustiti kvalitetu zbog broja značajki. Odoljite tome. Proizvod s pet značajki koje izgledaju promišljeno preraći će proizvod s deset značajki koje izgledaju polovično — korisnici svoj dojam stvaraju iz najslabijeg ekrana koji vide, ne iz najjačeg.

Faza 5: QA i otklanjanje bugova (1–2 tjedna)

Posvećeno vrijeme za testiranje nije neobavezno. Čak i s testiranjem tijekom razvoja, fokusirano QA razdoblje hvata probleme koji su prošli.

Što se događa:

• Sustavno testiranje svakog korisničkog tijeka
• Cross-browser i cross-device testiranje
• Testiranje performansi (vrijeme učitavanja, upiti baze, vrijeme odgovora API-ja)
• Sigurnosni pregled (autentikacija, autorizacija, validacija unosa)
• Provjera pristupačnosti (navigacija tipkovnicom, screen readeri, kontrast)
• Prioritizacija i popravak bugova

Česta greška: Tretirati QA kao kvačicu, a ne stvarni filter kvalitete. Ako se nađu kritični bugovi, datum lansiranja se pomiče. Kvaliteta nije pregovarljiva. Najteži trenutak u projektu jest odluka o odgodi lansiranja zbog problema pronađenih u QA-u. Bit će pritiska — od stakeholdera, od kalendara, od umora samog tima. Ali isporuka proizvoda s poznatim kritičnim bugovima započinje odnos s korisnicima na krivoj nozi, a taj prvi dojam skup je za poništiti.

Faza 6: Priprema lansiranja (1 tjedan)

Posljednji tjedan prije lansiranja operativan je, ne razvojni. Bez novih značajki. Bez “samo još jednu stvar”.

Što se događa:

• Postavljanje i konfiguracija produkcijskog okruženja
• DNS, SSL i konfiguracija domene
• Postavljanje monitoringa i alertinga (uptime, stopa grešaka, performanse)
• Instalacija analytics alata i praćenje događaja
• Procedure za backup i oporavak
• Korisnička dokumentacija ili onboarding tijek
• Plan komunikacije lansiranja

Česta greška: Tretirati produkcijski deployment kao naknadnu misao. Infrastrukturni problemi na dan lansiranja mogu se spriječiti tjednom pripreme.

Što produžuje vrijeme

Ovi faktori mogu pretvoriti tromjesečni razvoj u šestomjesečni ili duži:

• Nejasno donošenje odluka: ako odobrenja traju tjedan umjesto dan, svaka se faza udvostručuje
• Širenje opsega: svaki “mali dodatak” dodaje 2–5 dana
• Polovični timovi: tim podijeljen na više projekata traje 2–3 puta duže od posvećenog
• Tehnička složenost: AI integracija, real-time funkcije ili kompleksna obrada podataka dodaju tjedne
• Regulativa: zdravstvo, financije i državni projekti dodaju faze sukladnosti
• Više tipova korisnika: svaka različita uloga množi dizajnerski i razvojni rad

Što skraćuje vrijeme

• Donositelj odluka koji odgovara u satima, ne danima
• Predefinirani design system ili UI framework
• Ponovno upotrebljiva infrastruktura iz prošlih projekata
• Tim koji je već radio zajedno
• Agresivno upravljanje opsegom (lista “ne radimo” je dugačka)
• Korištenje provjerene tehnologije, ne bleeding-edge eksperimenata

Suština

Fokusiran razvoj proizvoda traje 3–4 mjeseca s malim, posvećenim timom. Ne 2 tjedna (to je prototip), i ne 12 mjeseci (to je znak problema s opsegom ili procesom).

Timovi koji pogode taj rok imaju jednu zajedničku stvar: odlučili su što odbaciti prije nego što su počeli graditi. Brzina dolazi iz fokusa, ne iz težeg rada. Projekti koji odu preko četiri mjeseca gotovo uvijek imaju vidljivu prijelomnu točku — tjedan u kojem je odobren “mali dodatak”, sastanak na kojem je opseg tiho proširen, odluku koja je odgađana jednom previše. Disciplina rokova nije o žurbi s poslom; o ranom hvatanju tih trenutaka i držanju linije.