Projektni menadžment digitalnih projekata: vodič za klijente bez tehničkog znanja

Digitalni projekt koji krene bez jasne strukture upravljanja gotovo uvijek završi s jednim od tri ishoda: kašnjenjem koje nitko nije anticipirao, proračunom koji je prekoračen bez da je itko točno razumio zašto, ili isporukom koja tehnički funkcionira ali ne rješava problem koji je klijent imao na umu. Nijedan od tih ishoda nije neizbježan i nijedan nije isključivo tehnički problem — svi oni imaju korijen u načinu na koji je projekt vođen od prvog dana, u tome kako su definirani zahtjevi, kako su postavljeni rokovi, kako su komunicirane promjene i kako su donošene odluke kada su se pojavile situacije koje specifikacija nije predvidjela. Klijent koji nema tehničko znanje nije hendikepiran u upravljanju digitalnim projektom ako razumije nekoliko ključnih principa koji određuju razliku između projekta koji se isporučuje prema planu i onog koji se pretvori u izvor frustracije za sve uključene strane.

Kako upravljati digitalnim projektom bez tehničkog znanja

Upravljanje digitalnim projektom bez tehničkog znanja ne znači prepuštanje svih odluka razvojnom timu nego razumijevanje vlastitih odgovornosti u procesu i jasno razgraničenje između odluka koje su tehničke i koje razvojni tim mora donijeti, i odluka koje su poslovne i koje klijent mora donijeti jer nitko drugi ne razumije poslovni kontekst dovoljno dobro. Klijentova primarna odgovornost u digitalnom projektu jest definirati što sustav mora postići za korisnika i za poslovanje, prioritizirati zahtjeve kada ih je više nego što se može isporučiti u dostupnom roku i proračunu, davati pravovremene povratne informacije u definiranim preglednim točkama i donositi odluke o promjenama opsega svjesno, s razumijevanjem njihovog utjecaja na rok i trošak. Komunikacija koja je strukturirana i predvidiva, s jasno definiranim kanalima, učestalošću i formatom izvještavanja, jedan je od ključnih faktora uspjeha digitalnih projekata jer nesigurnost o statusu projekta gotovo uvijek vodi prema eskalaciji koja oduzima više vremena od redovnog izvještavanja koje bi tu nesigurnost spriječilo. Dokumentacija odluka, uključujući što je dogovoreno, tko je donio odluku i kada, nije birokratska formalnost nego zaštita obje strane u trenutku kada se pojavi pitanje zašto je nešto napravljeno na određeni način ili tko je odobrio određenu promjenu. Razvojni tim koji radi s klijentom bez tehničkog znanja ima odgovornost komunicirati tehničke odluke i njihove poslovne implikacije na način koji je razumljiv, a ne skrivati kompleksnost iza tehničkog žargona koji klijentu ne daje informacije potrebne za donošenje odluka.

Waterfall, Agile i Scrum: što znači za vas kao klijenta

Waterfall je metodologija u kojoj se projekt prolazi kroz sekvencijalne faze, od analize zahtjeva i dizajna do razvoja, testiranja i isporuke, pri čemu svaka faza mora biti završena prije nego sljedeća počne i promjene zahtjeva nakon što je faza zatvorena generiraju formalne zahtjeve za promjenom koji utječu na rok i proračun. Za klijenta Waterfall znači veću predvidivost na početku projekta jer su zahtjevi definirani detaljno unaprijed, ali i manju fleksibilnost u tijeku projekta jer svaka promjena ima formalni i vremenski i financijski trošak, i rizik da se isporučeno rješenje na kraju projekta pokaže manje relevantnim nego što je izgledalo kada su zahtjevi bili definirani jer se poslovni kontekst u međuvremenu mogao promijeniti. Agile je skup principa koji naglašava iterativni razvoj, kontinuiranu isporuku vrijednosti i prilagodbu zahtjeva temeljem povratnih informacija umjesto slijeđenja fiksnog plana definiranog na početku, što za klijenta znači veću fleksibilnost i raniju vidljivost rezultata, ali i zahtijeva aktivniji angažman klijenta kroz projekt jer se prioriteti i zahtjevi redovito preispituju. Scrum je najčešće korišteni Agile okvir koji projekt organizira u sprintove, kratke razvojne cikluse koji traju tipično dva do četiri tjedna, na čijem kraju tim isporučuje funkcionalni increment proizvoda koji klijent može pregledati i ocijeniti, a prioriteti za sljedeći sprint definiraju se na temelju te ocjene i promjena u poslovnom kontekstu. Za klijenta bez tehničkog znanja najvažnije je razumjeti da metodologija nije sama sebi svrha nego alat koji mora odgovarati prirodi projekta, timu i klijentovim kapacitetima za angažman, jer Scrum koji zahtijeva aktivnog product ownera na strani klijenta neće funkcionirati dobro ako klijent nema vremena ili kapaciteta za tu ulogu.

Kako postaviti realne rokove za razvoj web stranice ili aplikacije

Nerealni rokovi jedan su od najčešćih uzroka neuspjeha digitalnih projekata i gotovo uvijek nastaju iz jednog od tri razloga: klijent je postavio rok bez konzultacije s razvojnim timom, razvojni tim je pristao na rok koji je znao da je prenaponat kako bi dobio projekt, ili su obje strane ignorirale poznate rizike i pretpostavile da će projekt ići glatko. Realni rok za razvoj web stranice ili aplikacije ne može biti definiran bez specifikacije jer je rok funkcija opsega, a opseg koji nije definiran ne može biti realno procijenjen, što znači da svaki rok koji se dogovori prije nego je specifikacija završena jest u osnovi nagađanje koje može biti više ili manje informirano ali nikad stvarno pouzdano. Faktori koji sustavno produžuju projekte a koji se rijetko uzimaju u obzir pri inicijalnoj procjeni uključuju vrijeme za povratne informacije i odobrenja na strani klijenta, integracije s vanjskim sustavima koje ovise o dostupnosti i dokumentaciji treće strane, iteracije dizajna koje nastaju kada klijent vidi implementirani dizajn u kontekstu koji je drugačiji od statičnih mockupova, testiranje i ispravak grešaka koje je teže procijeniti nego razvoj funkcionalnosti i deploy i konfiguracija produkcijskog okruženja koja često otkrije probleme koji nisu bili vidljivi u razvojnom okruženju. Rezerva za nepredviđeno koja iznosi dvadeset do trideset posto procijenjenog trajanja projekta nije pesimizam nego realistično uvažavanje činjenice da svaki projekt otkrije nešto što specifikacija nije predvidjela, i razvojni tim koji ne uključuje tu rezervu ili laže klijentu ili laže sebi.

Kako smanjiti scope creep na digitalnim projektima

Scope creep, postupno širenje opsega projekta izvan inicijalno dogovorenih granica, jedan je od najčešćih uzroka prekoračenja rokova i proračuna i posebno je čest u projektima gdje nije bilo precizne specifikacije na početku ili gdje nije uspostavljen formalni proces za upravljanje promjenama. Svaka promjena opsega, bila ona velika ili mala, ima trošak koji nije samo u vremenu potrebnom za implementaciju nego i u vremenu za analizu, planiranje, testiranje i integraciju s ostatkom sustava, i zbrajanje više malih promjena koje su se svaka zasebno činile trivijalnima može rezultirati tjednima dodatnog razvoja koji nisu bili planirani ni naplaćeni. Formalni change request proces, koji zahtijeva da svaka promjena opsega bude dokumentirana, procijenjena i odobrena od strane klijenta s eksplicitnim razumijevanjem utjecaja na rok i trošak, nije birokratska prepreka nego mehanizam koji štiti obje strane jer razvojnom timu daje osnovu za replaniranje, a klijentu daje vidljivost u to za što plaća i koliko svaka promjena zapravo košta. Jasna definicija što je u opsegu u specifikaciji, koja eksplicitno navodi i što nije u opsegu, najjači je alat za sprječavanje scope creep jer eliminira prostor za interpretaciju koji je izvor većine nesporazuma o tome je li neka funkcionalnost bila dogovorena ili nije. Prioritizacija zahtjeva u backlogu koja jasno razlikuje must-have od nice-to-have od won't-have u ovoj verziji pomaže klijentu donijeti svjesnu odluku o tome što želi u prvoj verziji sustava, umjesto da svaku ideju koja se pojavi u tijeku projekta tretira kao nešto što mora biti u finalnoj isporuci.

Što je MVP i zašto biste trebali početi s njim

MVP, minimalno održivi proizvod, jedan je od koncepta koji se u razgovorima o digitalnim projektima često spominje ali rijetko precizno definira, što vodi prema dvjema suprotnim greškama: klijentima koji MVP razumiju kao gotov ali siromašan proizvod koji nije dovoljan za tržište, i razvojnim timovima koji MVP koriste kao opravdanje za isporuku nedovršenog sustava koji ne može funkcionirati u produkciji. Pravi MVP je najmanji skup funkcionalnosti koji rješava stvarni problem stvarnih korisnika na način koji je dovoljno dobar da ti korisnici žele koristiti sustav, daje tim povratne informacije o tome što funkcionira a što ne, i validira ili opovrgava ključne pretpostavke o kojima ovisi ostatak razvoja. Vrijednost MVP pristupa nije u tome da je jeftiniji od razvoja punog sustava, iako često jest, nego u tome da omogućuje učenje iz stvarnog korištenja prije nego se ulože resursi u razvoj funkcionalnosti koje možda nisu tako vrijedne kao što su izgledale u fazi planiranja. Tvrtka koja pokrene web shop s minimalnim setom kategorija, bez složene pretrage, bez loyalty programa i bez napredne filtracije, ali s pouzdanim procesom narudžbe i isporuke, može naučiti koji proizvodi se prodaju, koji korisnici kupuju i koji koraci u procesu narudžbe stvaraju frikciju, i te informacije direktno oblikuju odluke o sljedećim fazama razvoja koje su temeljene na podacima a ne na pretpostavkama. Prolink pri planiranju projekata aktivno pomaže klijentima definirati MVP koji je dovoljno mali da bude isporučen brzo i dovoljno velik da bude koristan, jer ta ravnoteža određuje koliko brzo investicija počinje generirati povrat.

Kako Prolink vodi digitalne projekte

Prolink primjenjuje strukturirani pristup upravljanju projektima koji kombinira jasnu specifikaciju i dogovoreni opseg na početku projekta s fleksibilnošću iterativnog razvoja u tijeku, a klijentu daje kontinuiranu vidljivost u napredak bez potrebe da razumije tehničke detalje implementacije. Svaki projekt počinje fazom definicije u kojoj se zahtjevi razjašnjavaju, prioritiziraju i pretvaraju u specifikaciju koja je dovoljno precizna za realnu procjenu rokova i troškova, a klijent u svakom trenutku ima pristup razvojnom okruženju gdje može vidjeti što je napravljeno i davati povratne informacije. Promjene opsega koje nastaju u tijeku projekta, a one uvijek nastaju, obrađuju se kroz dokumentirani proces koji klijentu daje jasnu informaciju o tome što svaka promjena znači za rok i trošak, bez iznenađenja pri finalnoj isporuci. Klijenti koji planiraju digitalni projekt i žele razgovor o tome kako strukturirati upravljanje projektom, definirati realne rokove i izbjeći najčešće greške mogu kontaktirati Prolink tim za besplatnu konzultaciju u kojoj se definira pristup koji odgovara konkretnom projektu i klijentovim kapacitetima za angažman.