Još od prvih dana moje karijere kao projekt menadžera, uživao sam čitajući vodiče i priručnike dobre prakse o tome kako najbolje organizovati radne procese. Verujem da je važno tačno znati koji su koraci potrebni za završetak datog radnog procesa, kako bi se osiguralo da je projekat završen, funkcionalan i profitabilan.
Svakodnevni izazov je prilagoditi procese na pravi način, kako bi došli do željenih rezultata i, što je još važnije, kako ta prilagođavanja i organizacione procese preneti kolegama.
U ovom postu ću predstaviti prakse koje se koriste u Studio Present. Smernice date u nastavku namenjene su iskusnim PM, mlađim PM i, naravno, klijentima. Kao što svi znamo, proces učenja se nikad ne završava. I danas, sa više od 15 godina iskustva iza sebe, još uvek učim od iskusnih lidera, investitora i projekt menadžera.
Protekla decenija i po provedena u radu na ovom polju učinila me je dovoljno sigurnim u sebe tako da sam sada u stanju da prenesem neko svoje znanje na mlađu generaciju projekt menadžera ili možda pomognem nekome da nadogradi njihove procese.
Pa, počnimo. Uvek postoji onaj čuveni prvi e-mail ili telefonski poziv, koji pokreće saradnju i dovodi do sledećih koraka:
Inicijalni sastanak
Uvek se zalažem za to da prvi sastanak bude lično. Ako iz bilo kog razloga to nije moguće, sastanak bi trebalo da se održi putem video poziva.
Izrazi lica i govor tela su presudni faktori za neometanu komunikaciju i bolje razumevanje. Na kraju krajeva, ne želite nikakve nesporazume, posebno ne u ovoj vitalnoj, prvoj fazi saradnje.
Na prvom sastanku pokušavamo da prikupimo što više informacija: o kompaniji, zainteresovanim stranama i željenoj aplikaciji. Šta tačno klijenti žele da postignu ili poboljšaju? Koji je to trenutni problem koji žele da reše uz našu podršku stvaranjem ove nove aplikacije?
Kako će aplikacija pomoći u stvaranju većeg profita ili smanjenju troškova?
Dakle, nakon što su postavljeni početni ciljevi, prelazimo na drugi deo sastanka, koji predstavlja prezentaciju naše kompanije. Moramo pažljivo predstaviti koja su naša pravila i procesi, kakav je tok proizvodnje i kakva su naša očekivanja. Uverite se da klijent razume smernice vaše kompanije kako bi izbegli kasnije zablude.
Na kraju sastanka moramo saznati o glavnoj ideji aplikacije, njenoj osnovnoj funkcionalnosti, bez toga da ulazimo u detalje, jer će kasnije biti dovoljno vremena za to.
Ako projekat treba da ima nekoliko faza (budimo iskreni, većina projekata ima), tada moramo otprilike znati koje su to faze. Na primer, ako klijent želi aplikaciju za upravljanje skladištima, ali već zna da bi aplikacija u budućnosti trebalo da bude povezana sa CRM softverom, dobra ideja je podeliti ovu informaciju sa nama, jer će biti od pomoći celokupnom radu koji će rezultirati boljom aplikacijom.
Na sastanku je važno da svu svoju pažnju posvetimo klijentu. Govoreći o tome, napomenuo bih, da sam uz dozvolu klijenata, imao običaj da snimam naš razovor. Audio snimak je izuzetno koristan kada je u pitanju priprema:
Tehnička dokumentacija i dijagrami
Kada se stvaraju složene web aplikacije, uvek tražim od kompanije da mi dodeli jednu ili više osoba, koje će blisko sarađivati sa nama i biti u stalnoj komunikaciji. Jednostavno je nemoguće razviti dobru tehničku dokumentaciju i postaviti čvrste temelje bez ovoga.
U većini slučajeva dokumentacija se priprema uz pomoć Google dokumenata. Na ovaj način mogu da iskoristim svoje iskustvo u stvaranju prvih nacrta naslova i podnaslova, odeljaka, sve, počevši od prvog sastanka.
Google dokumenti se dele sa klijentom samo radi pregleda i komentarisanja.
Takođe, ovo olakšava uvid u komentare i omogućava brzo dobijanje odgovora na moja pitanja koja se pojavljuju tokom pisanja, mada je i e-mail opcija.
Ako klijent nema nikakvu dokumentaciju, to znači da ću morati da preuzmem ulogu glavnog pisca, s tim da mi klijent obezbedi sve bitne podatke. U ovoj fazi počinjem da postavljam pitanja svom seniorskom timu.
Ako je razvoj aplikacije složen i postoje brojne reference, najbolji način je crtanje dijagrama. Viizuelnim elementima, je mnogo lakše objasniti timu ili klijentu kako određene stavke treba da funkcionišu. Uz dijagram, svi možemo videti glavne blokove aplikacije i njihove međusobne odnose.
Za dijagrame i wireframe obično koristim Axure RP zbog njegovih sjajnih mogućnosti deljenja.
Ponuda za izradu wireframe-a i UI / UX dizajna
Zbog složenosti aplikacija i neizvesnosti, poslednjih nekoliko meseci odlučujemo se za novi tok rada.
Pre nego što ponudimo grubu procenu celokupnog razvoja aplikacije, prvo kreiramo wireframe i dizajn aplikacije (prototip).
Na osnovu ranijih poslova i prethodnog iskustva možemo lako predvideti koliko vremena će dati projekat zahtevati.
Kada završimo sa dizajnom, i klijent i moje kolege mogu videti širu sliku. U poređenju sa jednostavnim dijagramima, ove vizuelizacije sa njihovim detaljima mogu nam pružiti mnogo bolje razumevanje da li treba ukloniti određenu karakteristiku ili umesto nje dodati neku drugu funkciju.
Wireframe
Ovo je faza kada započinjemo kreiranje kostura web aplikacije.
Na osnovu dokumentacije, dijagrama i prioriteta, kreiramo wireframe, a ponekada je ovo prototip na koji je moguće kliknuti.
Svaka stranica koja treba da prikupi neke ulazne podatke ili povuče neke podatke iz baze podataka kreira se s najvećom pažnjom.
U ovom procesu takođe pozdravljamo bilo koji oblik doprinosa klijenata, jer tako dobijamo neprocenjive povratne informacije i potvrdu da su sva polja i zahtevi na mestu. Ovo je presudan momenat, jer u ovom procesu želimo da prosvetlimo klijente, tj. naučimo ih, da su razmena znanja i njihova posvećenost od velike važnosti.
Wireframe je gruba skica, bez ikakvih elemenata dizajna, tako da se naša pažnja može usmeriti samo na osnovnu funkcionalnost.
Ovo je trenutak u procesu kada se najčešće događaju prve promene u poređenju sa početnom tehničkom dokumentacijom.
Dizajnn UX / UI
Čim se odobri wireframe, dizajner može započeti pripremu budućeg dizajna.
Ovo je korak kada biramo odgovarajuće boje, fontove, „ton“ aplikacije, specifične za uređaje na kojima će aplikacija sada biti u upotrebi.
Ključno je obratiti pažnju na određenu korisničku grupaciju (starost, pol, tip posla ...), tj. kojoj ciljnoj grupi je namenjena ova aplikacija.
Kada je dizajnirano nekoliko stranica, ponovo zasedamo sa klijentom. U ovoj fazi pozivamo klijenta da pruži povratne informacije, takođe, menjamo određene postavke, dodajemo ili uklanjamo opcije.
Većini ljudi je teško zamisliti konačni rezultat zasnovan samo na pisanoj dokumentaciji, jer se čini previše apstraktnim ili previše tehničkim... Međutim, kad jednom vide dizajnirane elemente, projekat odjednom postaje vizuelno opipljiv, a samim tim i lakše stvaramo utisak o njemu.
Za prezentaciju dizajna razvili smo našu internu platformu. To je nešto poput stranice profila klijenta, gde čuvamo sve dizajnirane stranice, verzije i wireframe-ove za određeni projekat. U ovom odeljku klijent može imati zasebnu biblioteku za logotipe ili druga sredstva za kasniju upotrebu.
U zavisnosti od upotrebe aplikacije, ponekad započnemo sa dizajnom za mobilne uređaje, ponekad sa desktop dizajnom.
Tokom ovog procesa, dizajner može proizvesti logotip i druge brendirane materijale, kao što su piktogrami.
Koliko ljudi treba da radi na datom projektu?
Čim imamo projektnu dokumentaciju, wireframe i dizajn, mogu da predstavim projekat programerima. Ovo mi daje priliku da izložim širu sliku projekta i ukažem na moguće slabe tačke.
Moj posao je da pomognem i izolujem delove koje nikada pre nismo stvorili, jer moramo izračunati vreme za istraživanje. Senior programeri su ključni faktori u ovom procesu.
Razgovaramo o tehnologiji koja će se koristiti i načinu na koji će se aplikacija razvijati.
Programeri front-end-a i back-end-a će takođe dodati svoje komentare, pa smo na kraju ovog sastanka 80% sigurni koliko je ljudi zapravo potrebno za završetak ovog projekta i koje zadatke mogu da rade naši junior programeri.
Sada možemo da obavestimo klijenta o tome kada je moguće započeti proces kodiranja aplikacije.
Ponuda za razvoj web aplikacije
U ovoj fazi imamo sve informacije potrebne za iznošenje inicijalne ponude klijentu.
Poslednje 3 godine većina naših projekata bila je uključena u stvaranje složenih web aplikacija. Obično se odlučujemo za rad pomoću Agile metode sa Scrum ili Kanban elementima. To znači da je naš glavni cilj da isporučimo MVP što je brže moguće, da vidimo koliko je dobar i da imamo rane povratne informacije.
Tokom procesa izrade aplikacije klijent može da vrši promene u aplikaciji. Moj posao je da objasnim klijentu šta će biti drugačije nakon trenutne promene.
Kako će se ove promene odraziti na vreme / cenu i funkcionalnost?
Ova fleksibilnost ima jednu „manu“. Cena projekta ne može biti fiksna. Cena navedena u inicijalnoj ponudi je isključivo u informativne svrhe i u 99% slučajeva biće veća.
Sasvim je normalno da klijent ne zna šta će mu trebati u budućnosti (ili ne može znati pre nego što to vidi na delu). Štaviše, programeri ne mogu da predvide svaki pojedinačni korak u procesu razvoja. Nemoguće je tačno proceniti vreme kada je data aplikacija tako složena.
Čak i s obzirom na naše zajedničko iskustvo od 10 godina, uvek se suočavamo sa nekim nepredvidivim situacijama ili izazovima.
Razgovor sa klijentom je ponovo presudan element u ovoj fazi. Predstavljamo različite opcije, koje mogu uključiti odbacivanje određene funkcije za MVP verziju ili prenošenje nekih zadataka u sledeću razvojnu fazu.
Česta i iskrena komunikacija podrazumeva uzajamno poštovanje između klijenta i agencije, a to je od vitalnog značaja za završetak projekta. U ovom procesu nastojimo da imamo dugotrajan poslovni odnos.
U zavisnosti od složenosti projekta, nudimo više nivoa za pakete održavanja:
Održavanje uključuje:
- Mesečna provera web sajta
- Održavanje servera i usluga na njemu
- Bezbednosna ažuriranja
- Brz odgovor na tekuće probleme
Kada se klijent složi sa ugovorom o održavanju, to praktično znači da je klijent rezervisao naše vreme i osigurao se da ćemo odmah postupiti.
Ugovor
Lični dogovori i rukovanja su nam važniji od stvarnih ugovora. Ipak, u poslovnom svetu postoje određena pravila koja se moraju poštovati, poput potpisivanja ugovora.
Naš ugovor je napisan jednostavnim jezikom, bez previše komplikovanih advokatskih izraza. Objašnjava prava i obaveze obe strane.
Tokom postojanja Studio Present-a (od 2006. godine) nikada nismo imali pravnih problema, zapravo smo izuzetno ponosni na to.
Bilo je situacija u kojima smo imali neslaganja sa klijentom, jer se ispostavilo da imamo različite ciljeve. U tim slučajevima je uvek bolje na vreme prekinuti saradnju.
Određivanje i delegiranje zadataka
Studio Present je podeljen u nekoliko timova:
- Projekt menadžeri
- Dizajneri
- Site bilderi
- Backend developeri
- Frontend developei
- QA tim
- Server tim
- Tim za kreaciju sadržaja
- Digitalni marketing
Menadžeri timova i članovi tima odgovorni su za kreiranje zadataka i sada razgovaramo o pravom trenutku za početak. Pa kako taj proces funkcioniše? Na primer, QA tim nema šta da radi pre nego što programeri završe svoj posao. Sekvence su pažljivo koordinirane kako bi čitav proces rada tekao nesmetano.
Tokom izrade jednog zadatka procenjujemo vreme potrebno za razvoj određene funkcionalnosti. Ponekad su veći zadaci podeljeni na manje i tada moramo da odredimo prioritete. Često se desi da naletimo na određeni problem, koji ranije nije bilo vidljiv ili poznat, i to zahteva brzu reakciju.
Ekipa seniora je od presudnog značaja u ovoj fazi, jer njihovo iskustvo pruža vitalne informacije o tome koliko će vremena biti utrošeno ili koje su slabe tačke za koje će se verovatno utrošiti više vremena.
Kada se ovaj proces planiranja završi, imamo realniju procenu vremena za razvoj aplikacije.
Timski “kick-off” sastanak
Vreme je da ceo tim zasedne kako bi još jednom porazgovarali o kompletnom konceptu aplikacije.
Međutim, pored ovog početnog sastanka, postoje redovni kratki brifinzi o tome koji su glavni ciljevi.
Prolazimo kroz svaki zadatak i po potrebi vršimo dodatna prilagođavanja. Ovo je vreme u kojem biramo prioritete za prve dve nedelje razvoja.
Senior programeri imaju zadatak da pruže dodatna objašnjenja junior programerima.
Ovo je takođe prilika da se identifikuju novi izazovi povezani sa datim projektom i razrade moguća rešenja.
Priprema razvojnog okruženja
Naš kolega je odgovoran za to da serverska strana napravi lokalnu kopiju CMS-a, tako da ga svaki programer može povući i početi da radi.
Konfigurisan je sistem kontrole verzija, što znači da klijent može početi da prati napredak razvoja aplikacije na domenu programera.
Međutim, važno je napomenuti da je deljenje procesa razvoja aplikacije u tako ranoj fazi moguće samo ako je klijent donekle tehnički obrazovan.
Sitebuild & Frontend
Sitebuilder - čovek koji gradi temelje aplikacije
Njihov zadatak je da kreira osnovna polja, tipove sadržaja, regije, blokove, prikaz za frontend i backend programere.
Nakon nekoliko dana izrade web sajta, ostatak tima može početi da radi na samoj aplikaciji.
Frontend programeri su zaduženi za prenošenje dizajna na radni proizvod. Takođe razvijaju dinamiku i korisničko iskustvo sa CSS i JS u stalnoj saradnji sa dizajnerom.
Primeri:
- Sajt bilder kreira sva polja za unos podataka, konfiguriše osnovne module koji će se koristiti, konfiguriše osnovna podešavanja sajta ...
- Frontend programer postavlja opšti stil aplikacije koji je definisan dizajnom. Zadatak je da se naprave pravila tipografije, tip tastera i definiše stil svih HTML elemenata koji će biti u upotrebi.
Programiranje
Prvo i najvažnije, moramo biti sigurni da je programer razumeo dati zadatak.
Sledeći korak je stvaranje šeme baze podataka, kako bi se videlo koji su odnosi i elementi ključni.
Kada se izvrši neka funkcionalnost, možemo je predstaviti klijentu na test domenu. Ovo daje klijentu priliku da testira da li sve funkcioniše onako kako treba. Na primer, klijent mora da proveri da li je formula koja se koristi za izračunavanje cene isporuke na osnovu težine tačna.
U ovoj fazi ne treba da bude spreman celokupan dizajn. Ovo je lepota Agile razvoja gde možemo testirati izolovanu funkcionalnost u ovoj ranoj fazi.
Jedan od najčešćih zadataka programera je stvaranje veze aplikacije sa nezavisnim aplikacijama treće strane. To se radi putem API-ja i može se, između ostalog, povezati sa CRM softverom, ERP-om ili sistemom biltena.
Statički sadržaj
Kada kreiramo web aplikaciju, sadržaj se ne smatra ključnim elementom koji se mora rešavati na samom početku.
Međutim, do trenutka testiranja određenih funkcionalnosti možda će biti potrebno da se sadržaj otpremi u aplikaciju.
Nekoliko primera za statički sadržaj:
- Demo proizvodi
- Cenovnici
- Članovi tima
- Lokacije prodavnica
- ...
Quality Assurance - kontrola kvaliteta
Prema našem ugovoru, svi zaposleni moraju izvršiti QA za svoje zadatke.
Rukovodilac projekta će testirati neke delove aplikacija.
Naš QA tim testira celokupan rad programera i dizajnera.
Verujemo da je najbolji pristup imati četvrtu kariku u ovom procesu, a to je osoba iz klijentove kompanije. Novi par očiju ponekad može uočiti probleme koji su do tada bili neotkriveni, dajući priliku razvojnom timu da reaguje.
Kombinacija sve ove provere znači da već imamo funkcionalnu i dobro testiranu aplikaciju. Konačnu potvrdu da sve funkcioniše kako treba, daće korisnici aplikacije.
Live server (produkcija)
Jednom kada dobijemo potvrdu da sistem radi neometano i da je svaka greška otklonjena, započinjemo sa procesom prenosa podataka na javni server.
Od ovog trenutka aplikacija je povezana sa stvarnim domenom i svi mogu da joj pristupe.
Administrator servera konfiguriše SSL (https) sertifikat, e-mail i mi unosimo stvarne podatke, na primer za plaćanja kreditnom karticom.
Održavanje
Pod pretpostavkom da je cilj da aplikacija ili web sajt u dogledno vreme neometano rade, neophodno je postići dogovor sa klijentom u vezi sa nekim oblikom paketa održavanja.
U teoriji je stvaranje stabilnog sistema jednostavno. Međutim, postoji mnogo faktora koji programerima mogu da poremete čak i najbolji web sajt i izazovu neuspeh aplikacije.
Toplo preporučujemo našim klijentima da se pokriju tehničkim ugovorom za ovaj deo kako bi mogli tražiti podršku za eventualne popravke.
Ako je posao dobro urađen, tada će, osim održavanja, uvek biti prostora za poboljšanje aplikacije. Ovim paketom održavanja vi kao klijent ste u stvari rezervisali naše vreme za popravke i nadogradnje.
Nadogradnje i nove funkcije
Dozvolite mi da se nadovežem sledećom rečenicom. U većini slučajeva internet poslovanje se menja gotovo svakodnevno. Pojavljuju se nove potrebe za nekom novom automatizacijom i zbog njih morate da nadogradite svoje web prisustvo ili aplikaciju.
Trenutna praksa u Studio Present je da se razgovara sa klijentima o njihovim planovima za budućnost: šta žele da razviju u naredne dve nedelje.
Klijent može promeniti prioritete i imati uvid u sav posao koji radimo. Ovaj nivo transparentnosti je dobar, jer klijent može da reaguje odmah ukoliko se pojavi neka prepreka ili kada su nam potrebni određeni podaci ili informacije da bismo nastavili sa zadatkom.
Naravno, vodimo računa da svog klijenta držimo u toku i dajemo savete o tome šta bi, prema našem iskustvu, bila dobra strategija.
Do ove faze razvoja aplikacije, klijent i Studio Present su se dobro upoznali i ovaj „poslovni brak“ može nastaviti da raste prirodno.
Marketing
Ponekad su vaše poslovanje i vaša aplikacija jedinstveni i vi ste poput monopolista, ali kako uvek postoje i slične usluge, moraćete da se borite za svoj udeo. To znači da se neka vrsta marketinga mora uključiti.
U Studio Present imamo snažnu marketinšku sekciju koja je zadužena za digitalno prisustvo vaše kompanije, brenda ili aplikacije. Na našim zvaničnim stranicama možete saznati više o našim marketinškim pristupima.
https://www.studiopresent.com
Prilikom sastanka sa klijentom dovodimo marketinški tim, jer oni mogu pomoći u definisanju:
- koje su osnovne vrednosti koje treba da promovišemo
- ono što moramo naglasiti na novom sajtu
- usklađivanje, fokus na potrebe vlasnika preduzeća i njihovih kupaca.
Drugi slučaj kada je učešće marketinškog tima neprocenjivo je kada treba da obnovimo neki stari web sajt / projekat. Marketinški tim može da ukaže na tehničke potrebe za boljim promotivnim aktivnostima, na osnovu analize istorijskih podataka. Ulaz tima će nam reći kako da optimizujemo web sajt za društvene medije, određene korisnike ili pretraživače.
Isplata
Znam da su rasprave o fakturisanju i novcu obično zabranjene teme. Ipak, želeo bih da vam objasnim kako poslujemo.
Ako je aplikacija složena, klijentu će se poslati račun za tehničku dokumentaciju.
Druga faktura odnosiće se na wireframe i dizajn zasnovan na radnom vremenu.
Kada utvrdimo procenu projekta, klijent mora unapred da plati trećinu tog iznosa.
Sledeći mesec pripremamo račune za prethodni mesec, zasnovane na vremenu koje smo proveli na projektu prethodni mesec.
Zaključak
Sada ste stekli uvid u naš trenutni radni proces. Prema našem iskustvu, svakih 6 meseci ili pre, pojavi se nešto što će se verovatno promeniti ili treba nadograditi. Kao i u bilo kojoj drugoj grani, i u IT poslu stalne promene su neizbežne.
Stalno govorimo našim klijentima: ne bojte se promena, promovišite ih među svojim kolegama i objašnjavajte im zašto je nešto bolje na ovaj novi način. Kada klijentu objasnimo zašto su neke promene neophodne ili kada kolegi predstavite neku promenu, generalno postoji veći procenat prihvatanja.
Ponekad promene mogu produžiti vreme razvoja, ali zauzvrat ćete dobiti stabilniji proizvod i mnogo bolji kvalitet.