Od ideje do produkcije: Realan vremenski okvir digitalnog projekta

"Kada će biti gotovo?"

Naravno, ovo pitanje je nezaobilazno kada se planira projekt. Moramo znati barem otprilike kada će digitalni proizvod ugledati svjetlo dana. Ali, što je realno? I zašto "što prije" nije opcija ako radimo kako treba.

Provedba projekta može se odvijati na više načina, ali uvijek ima dijelove koje ne treba zaobilaziti ako želimo uspješan projekt. Koje bi oni bili, pogledat ćemo na prosječnom projektu srednje kompleksnosti.

Discovery faza: 2-3 tjedna

Prije nego što napišemo jednu liniju koda, moramo znati ŠTO gradimo.

Discovery nije nepotrebna birokracija, bez obzira na elegantno ime. To je proces u kojem zapravo definiramo projekt. Razgovaramo s klientom, upoznajemo korisnike, mapiramo poslovne procese, identificiramo rizike.

Konkretno:

• Radionica s dionicima koji dobro poznaju svoju publiku
• Analiza postojećih rješenja (ako ih ima)
• Definiranje korisničkih priča
• Tehnička analiza i arhitektura
• Kreiranje početnog popisa zadataka

Preskaču li klijenti ovu fazu? Često. Žale li se kasnije? Uvijek.

E-mail nije dovoljan. Može biti za sitnicu, popravak, grešku, nešto. Ali za projekt nije opcija. Otprilike kao kad šaljete nekog u dućan. Ako treba kupiti isti kruh kao uvijek, reći ćete "1 kruh molim" i najvjerojatnije dobiti što ste tražili. Ako napišete "1 kruh", a zapravo trebate onaj elegantan bez glutena, posut mrvicama od bućine esencije, spremljen u kalup od kirurškog čelika broj 6.2 - trebamo pričati da bi do toga došli. Možda otkrijemo i da trebate da se prilikom rezanja opire nožu točno 12% s prosječnom brzinom rezanja od 2 cm po sekundi, nikad ne znate… Zato pričamo, zato analiziramo, zato upoznajemo vaše sustave, zato nam treba vrijeme.

Savjeti za bolju discovery fazu:

Tko zna - zna. Na radionici trebaju biti ljudi koji - znaju. Ne samo menadžment - trebamo (a i vi) ljude koji će stvarno koristiti aplikaciju ili one koji su s krajnjim korisnikom kroz godine već postali jedno. One koji znaju svu problematiku koju rješavamo u dušu. Jer oni će reći što im zapravo treba. U ovoj fazi je ključno da svi kažu svoje želje i pozdrave. Ako 1 osoba zna sve što treba, super. Ali ako ne - vrijeme je za izlet.

Dokumentiramo sve u stvarnom vremenu. Što nije zapisano ne postoji. Kratkoročno pamćenje prosječnog radnog čovjeka nije nešto na što se možemo osloniti. Radionica se treba snimati, a bilješke sa sastanka s jasno navedenim tko, što i kada trebaju dospjeti na e-mail svih bitnih što prije. Jer - zamah je ultimativni spasitelj vremena. Nakon radionice smo svi uronjeni u materiju i entuzijazam je na visini. Ne trošimo vrijeme već ovdje, krenimo, i klijent i agencija, odmah po stavkama s popisa zadataka.

Što je uspjeh. Kako ćemo znati je li projekt uspješan? 20% manje vremena za proces? 30% više konverzija? Brojke na stol. Ali realne. Nećemo nikad dobiti 100% stopu otvaranja newslettera ili 1 sat prosječnog vremena provedenog na webu. Budimo realni. Inače moramo izazvati klijenta, a nismo baš za borbe već na početku procesa, makar nam se šef bavio boksom.

Dizajn i UX: 1 mjesec

Dizajn nije samo "da bude lijepo". To je proces u kojem definiramo kako će korisnici zapravo koristiti aplikaciju. Klijent često vidi boje i slike i lijep font, "pogled iz ptičje perspektive" weba ili aplikacije. Mi vidimo "kako prezentirati brend na najljepši mogući način, a da korisnik svejedno u 3 klika pronađe ono što ga zanima u šumi ponude". Ovo se ne požuruje. Ovo je bitno.

Skice, korisničke putanje, prototip, sustav dizajna - sve to zahtijeva vrijeme. I iteracije. Jer prvi je prijedlog rijetko konačan. I tu je trik uštede vremena: klijent treba tjedan dana za povratnu informaciju, mi onda tjedan za reviziju, opet čekamo povratnu informaciju... I eto dodatna dva do tri tjedna.

Savjeti za efikasniju dizajn fazu:

Stavite povratne informacije direktno u Figmu. Ne šaljite e-mailove "pomakni taj gumb malo lijevo". Komentar direktno na element u Figmi, dizajner vidi kontekst odmah.

Grupirajte runde povratnih informacija. Nemojte slati povratne informacije svaki dan po malo. Sjednite jednom tjedno, pregledajte sve, dajte sveobuhvatnu povratnu informaciju odjednom. Tko je ikad naručivao ručak za cijelu firmu zna kakvu frustraciju donosi alternativa.

Testirajte prototip prije finalnog dizajna. Pokažite klikabilni prototip nekolicini korisnika. Saznat ćete je li navigacija logična, jesu li ključne funkcionalnosti lako dostupne, gdje se gube, gdje se nalaze.

Uskladite očekivanja oko broja revizija. Dogovorite koliko iteracija dizajna je uključeno u projekt. Inače se revizije mogu otegnuti u nedogled.

Development: Ovdje postaje zanimljivo

Ovo je dio gdje klijenti obično misle "sad će brzo". Ali razvoj nije linearan proces.

MVP (minimalno održiv proizvod): 2-3 mjeseca

Prvo stvaramo verziju s osnovnim funkcionalnostima - ono što MORA raditi da bi proizvod bio upotrebljiv.

Primjer: Ako radimo sustav za rezervacije, MVP uključuje pregled dostupnih termina i rezervaciju. Ne uključuje program vjernosti, integraciju s CRM-om, napredne izvještaje i 15 drugih značajki koje su navedene u punoj specifikaciji.

Savjeti za fazu razvoja:

Sudjelujte u planiranjima. Tim smo. Klijenti ne moraju biti na svakom dnevnom sastanku, pogotovo ako se radi o iskusnoj agenciji i faza planiranja je dobro odrađena, ali neka svi dionici budu na sastancima isporuke i planiranjima. Važno je znati što će se raditi i vidjeti što je napravljeno da se što prije uoče problemi.

Testirajte kontinuirano. Ne čekajte kraj projekta. Nakon svake isporuke se ulogirajte, klikajte, probajte. Naporno je. Ali greške je lakše ispravljati dok je kod još svjež. Vratimo se na kruh. Dodati malo vode dok se mijesi - nema problema. Promijeniti koliko je kruh tvrd kad je već pečen? Nek se javi tko je uspio.

Prioritizirajte greške. Ne mora sve biti popravljeno odmah. Nije sve Prioritet 1. Kritična greška koja blokira osnovnu funkcionalnost? Hitno i bitno. Onaj gumbić malo pomaknuti? Može pričekati fazu 2.

Budite realni oko promjena. "Brza izmjena" često nije brza. Svaka promjena zahtijeva razvoj, testiranje, postavljanje. Pitajte koliko zapravo dodatak ili promjena košta vremena prije nego kažete "ajmo dodati još to". Barem ako hoćete stići vremenski okvir.

Planirajte rezervu. Nikad ne ide sve po planu. Uvijek će nešto biti kompliciranije nego se činilo. Računajte na 10-20% dodatnog vremena.

Što raditi kad nešto krene po zlu:

Jer će nešto krenuti po zlu. Uvijek se dogodi barem jedna neplanirana situacija, negdje vrijeme malo procuri i evo nas u problemu.

Komunikacija, komunikacija, komunikacija. Ako se sazna nešto novo, ako se rok pomiče, ako znamo da ćemo negdje imati rupu u produkciji - to svi trebaju znati odmah. Jer, ako klijent planira godišnje od 2 tjedna za 3 mjeseca usred razvoja, onda npr. i agencija može tako posložiti razvojni tim pa se ne gubi duplo vrijeme. Da, stvarno, ta razina sitnice može utjecati na rok.

Fokusirajmo se na rješenja, ne krivnju. Je li važnije znati tko je kriv ili kako riješiti problem? Nije da se to neće utvrditi, znati. Mora se znati da bi se izbjegle iste greške u budućnosti. Ali razglabati o tome kako je do nečeg došlo je sekundarno. Prioritet je - rješenje. Barem za rok.

Reprioretizacija ako treba. Ako voda dođe do grla, na primjer rok je neodgodiv, 100 se stvari zakompliciralo i kasnimo, treba pogledati je li stvarno svaka značajka na popisu zadataka kritična za lansiranje.

Testiranje i QA: 2-3 tjedna

Osiguranje kvalitete nije nešto što radimo "na kraju kad je sve gotovo". Testiramo kontinuirano kroz cijeli razvoj, to smo već rekli.

Ali prije produkcije, trebamo i:

• Regresijsko testiranje (jesu li nove funkcionalnosti pokvarile stare)
• Testiranje prihvaćanja korisnika (testiraju stvarni ili "stvarni" korisnici)
• Testiranje performansi
• Sigurnosno testiranje

Realno: računajte na 2-3 tjedna intenzivnog testiranja prije pokretanja.

Savjeti za fazu osiguranja kvalitete:

Uključimo stvarne korisnike. 5-10 ljudi koji će zapravo koristiti aplikaciju. Dat će nam povratne informacije koje nikad ne bismo dobili od internog testiranja.

Ne zaboravimo rubne slučajeve. Što se dogodi kad korisnik unese 500 znakova u polje gdje očekujete 50? Što ako učitaju sliku od 50 MB? Aplikacija mora graciozno rješavati takve slučajeve.

Dokumentirajte greške jasno. "Ne radi" nije dobar izvještaj o grešci. Treba: što ste radili, što se dogodilo, što ste očekivali, snimka zaslona ili video, na kojem uređaju/pregledniku. Vrijeme koje se gubi na dopisivanje što se stvarno događa jede vrijeme kao čovjek na dijeti na “cheat day”. 

Postavljanje i lansiranje: 1-2 tjedna

Nije samo "stavimo to na poslužitelj i gotovo".

Postavljanje uključuje:

• Postavljanje produkcijskog okruženja
• Migraciju podataka (ako postoje)
• Konfiguraciju poslužitelja i sigurnosnih postavki
• Integracije s trećim sustavima
• Postavljanje praćenja i upozorenja
• Dokumentaciju za podršku

Plus, obično radimo meko lansiranje - puštamo aplikaciju manjoj grupi korisnika prvo, pratimo kako se ponaša, tražimo greške koje nismo vidjeli u testiranju.

Savjeti za sigurno postavljanje:

Izvan radnog vremena. Dok korisnici bezbrižno spavaju u svojim krevetima, mi idemo van. Također, jedina situacija gdje "Što ne znaš, ne boli" nema negativan kontekst.

Plan povratka. Ako postavljanje pukne, moramo moći brzo vratiti sve na prethodnu verziju.

Praćenje 24/7 prva dva tjedna. Netko mora biti dostupan ako nešto pukne. To ne znači da netko sjedi i gleda ekran, ali mora biti dostupan.

Komunicirajte s korisnicima. Ako radimo održavanje ili ako su moguća kratka isključenja, javite unaprijed svima kojima je to bitno.

Česta pitanja i dokumentacija za podršku. Prvog dana će biti puno pitanja. Bolje da imamo spremne odgovore.

Dakle, koliko STVARNO traje?

Za prosječnu web/mobilnu aplikaciju srednje kompleksnosti:

• Minimalno: 4-6 mjeseci od početka do produkcije
• Realno: 6-7 mjeseci
• Sa svim komplikacijama: neodređeno

Što usporava projekte?

Iz iskustva, ovo najčešće produljuje vremenski okvir:

Neodlučnost na strani klijenta - čekanje na odluke, promjene prioriteta, dodatni dionici koji se pojave u zadnji tren

Povećanje opsega - "ajde da dodamo još samo ovo jedno, brzo je" (nije brzo, neće biti jedno i riječ "samo" ne postoji)

Tehnički dug postojećih sustava - integracija sa zastarjelim sustavom je kompleksnija nego smo mislili

Nedostupnost resursa - ljudi koji trebaju biti uključeni u projekt nemaju vremena

Previše revizija dizajna - svaka značajna promjena dizajna znači dodatno vrijeme razvoja

Loša komunikacija - informacije se gube između timova, ljudi rade na krivim stvarima

Podcjenjivanje kompleksnosti - "to je samo ekran za prijavu" (nije samo ekran za prijavu kada uključuje dvofaktorsku autentifikaciju, društvenu prijavu, oporavak lozinke, upravljanje sesijama...)

Kako ubrzati proces?

Ne možemo zaobići faze, ali možemo biti efikasniji:

Dostupnost klijenta - brze povratne informacije i odluke drastično skraćuju vrijeme. Responzivnost na pitanja i zahtjeve za pojašnjenja čini ogromnu razliku.

Jasni i realni prioriteti - što MORA biti u minimalnom održivom proizvodu, a što može kasnije. Verzija 1.0 ne mora imati sve što zamišljamo za budućnost.

Donositelj odluka - jedna osoba koja može donositi odluke bez potrebe za dodatnim sastancima. Ne "moram pitati šefa" za svaku sitnicu.

Priprema materijala unaprijed - trebamo materijale, sadržaj, pristupe sustavima - to je sigurno. Pa ajmo to osigurati odmah.

Vjerujmo procesu - postoji razlog zašto radimo analizu, testiranje, osiguranje kvalitete. Preskakanje faza ne ubrzava projekt, samo stvara probleme kasnije.

Fleksibilnost - možda boja gumba nije kritična za lansiranje. Možda možemo živjeti s malo drugačijim rasporedom. Birajmo bitke.

Nakon lansiranja: To nije kraj, to je početak

Još jedna stvarnost koju klijenti često ne očekuju: lansiranje aplikacije nije kraj projekta.

Prvi tjedan nakon lansiranja obično je najintenzivniji. Dolaze greške koje nismo vidjeli u testiranju (jer 10 testera ne može simulirati 1000 pravih korisnika). Dolaze zahtjevi za značajke ("zašto nismo dodali to?"). Dolaze pitanja za podršku.

Planirajte:

• Periode za ispravljanje grešaka - prva 2-4 tjedna nakon lansiranja
• Iteracije na temelju povratnih informacija - što korisnici stvarno koriste, gdje se zbunjuju
• Kontinuirano održavanje - sigurnosna ažuriranja, održavanje poslužitelja, ažuriranja ovisnosti
• Razvoj značajki - verzije 1.1, 1.2, 2.0...

Dobar digitalni proizvod je živi organizam. Razvija se, mijenja, poboljšava. I to tako treba biti.

Zaključak

Znamo da nitko ne želi čuti "trebat će 6 mjeseci". Ali bolje je imati realnu sliku od početka nego obećavati 2 mjeseca i onda se pravdati svaki sprint zašto kasni.

Digitalni projekt nije samo pisanje koda. To je kompleksan proces. Ali kad je gotov - imamo proizvod koji radi, koji je testiran, koji korisnici razumiju i koji možemo skalirati. I to vrijedi čekanja.

Dobro napravljeno traje, brzo napravljeno se popravlja.