fbpx

Korisnici, vrijeme je za korak naprijed – Kristijan Trbojević

Možemo li korisničke zahtjeve ponekad poistovjetiti s ljudima? Naravno, ne doslovno, ali možemo istaknuti zajedničke nazivnike u navedenoj usporedbi. Ne znamo što se skriva iza istih te što od pojedinog možemo očekivati „sutra“. Gledamo li u detalje, oni su često promjenjivi i nepredvidivi. Razvijanje sustava „iz nule“ nije uvijek lagan posao. Olakotnom okolnošću možemo smatrati mogućnost da postavimo stvari „iz korijena“ onako kako smatramo da je najbolje što će nam kasnije olakšati održavanje sustava.

Međutim, na putu do istog stoji nekolicina prepreka koje moramo svladati i još k tome imati suglasnost korisnika prilikom zaključivanja pojedine funkcionalnosti ili kompletne funkcionalne specifikacije. Na početku projekta bitno je razlikovati sve važne stakeholdere te istaknuti sve bitne user, buyer i druge persone. Samim time možemo zaključiti da su naša priprema i pravovremena komunikacija jedni od najznačajnijih parametara kako bi se osigurali svi preduvjeti za prikupljanje korisničkih zahtjeva.

Kako (ne) početi?

Workshopovi, odnosno radionice s korisnicima trebaju biti isplanirane u detalje ukoliko želimo dobiti kvalitetan feedback korisnika koji će nam u početku dati dovoljan uvid u trenutnu situaciju. U tom slučaju, idealno bi bilo imati Project Managera s korisničke strane. Glavna zadaća istog bi bila razdvojiti korisničke želje i očekivanja od njihovih stvarnih potreba. Ovo je task koji bi se trebao odraditi na internoj razini, prije samih radionica s korisnikom. Navedenim bismo postigli efikasnije radionice, korisnik bi bio usmjereniji na funkcionalnosti koje su zaista potrebne (i unutar scopea) te bi njihove interne rasprave na samim radionicama bile svedene na minimum.

Ukoliko imamo neadekvatan početak poslovne analize i samog razvoja sustava, vrlo lako možemo „preko noći“ stvoriti dodatne barijere na putu do isporuke softvera. Primjerice, imali smo slučaj da smo bili primorani umjesto s analizom funkcionalnosti i stvarnih potreba korisnika, krenuti s dizajnom i vizualnim identitetom aplikacije što u konačnici i nije najispravniji put. Kada na navedeno dodamo vrlo nerealne, u konačnici bih rekao „imaginarne“ rokove, dolazimo do situacije gdje nam razvoj poprima stresan, nervozan i buran pravac.

Edukacija korisnika

Korisnikovu (ne)percepciju je li mjesec ili dva dovoljno da se implementiraju određeni zahtjevi možemo shvatiti. Jednostavno, s korisničke strane to ne možemo „po defaultu“ očekivati. Međutim, trebamo ih na vrijeme educirati te ih voditi kroz proces razvoja softvera. Moramo osigurati da je korisnik kvalitetno informiran o svim fazama implementacije sustava. U tom slučaju, prvi sastanak u „fazi upoznavanja“ bi trebala biti prezentacija, odnosno demonstracija svih dijelova projektnog razvoja.

Naglasak same prezentacije treba biti dodatno stavljen na testiranje i samu kontrolu kvalitete softvera. Osim poslovne analize, to su faze u kojima će korisnik biti najviše uključen. Možemo ih čak nazvati i ključnim fazama u isporuci jer je bitno da je korisnik detaljno informiran o testiranju s obzirom da je on taj koji daje „zeleno svjetlo“ da sustav može biti postavljen na produkcijsku okolinu. Općenito, važnost testiranja se s korisničke strane obično ignorira i podcjenjuje pogotovo u slučaju da je krajnji rok isporuke vrlo blizu.

Datumi, vrijeme, rokovi…

Po pitanju rokova za isporuku, zasigurno svi imamo različita iskustva, ali što se dogodi kada nam isti postanu prioritet i kada su nam stalno negdje „iznad glave“? Umjesto na kvaliteti, fokus je na vremenu, odnosno na „utrci“ s istim. Agilne metodologije, planirani i strukturirani rad su de facto „bačeni u vodu“. Iako korisnik smatra da razvoj i projekt u konačnici idu u dobrom smjeru, posljedice će biti vidljive u završnoj fazi projekta.

Što je rezultat ovakvog rada? Mijenjanje prioriteta na dnevnoj bazi, zahtjevni deployevi aplikacije, korisnik ne odrađuje testiranje pravovremeno i slično. Količina stresa i nervoze svakim je danom sve veća. Ali, ovdje se nameće pitanje, je li ovo optimalan put razvoja softvera? Zašto ponekad gledamo više na kalendar umjesto na kvalitetu? Naravno, teško je pronaći odgovore na takva pitanja u današnjem užurbanom svijetu.

Shodno navedenom, možemo li navedeni proces rada smatrati činjenicom, a ne problemom? Smatram da ne smijemo dopustiti da takav pristup postane nešto sasvim u redu, već posegnuti za promjenama.

Što smo naučili? Što promijeniti?

Ono što mi se nameće kao prvotni potez je uključiti razvojni tim u (pre)sales dio ugovaranja projekta, ukoliko za isto imamo mogućnosti. Nisam detaljno upućen u sve faze ugovaranja projekta, no osobe koje nisu direktno vezane u implementaciju sustava teško mogu predvidjeti koliko će trebati za razvoj određenog dijela sustava (što u globalu i nije njihov posao). Budimo iskreni, procjene su segment razvoja sustava kojim se svi „u neku ruku“ nerado bavimo.

Nadalje, moramo educirati korisnike o razvoju softvera i načinu na koji mi to radimo. Neophodno je voditi korisnika kroz proces implementacije. Fokusiranje na navedeno će omogućiti organiziraniji rad za naš razvojni tim i nas same kao poslovne analitičare ili product ownere.

Također, otvorena, odnosno iskrena komunikacija u oba smjera (korisnik <-> razvojni tim) i upravljanje očekivanjima korisnika su jedne od bitnih značajki za održavanje dobrog balansa u između razvojnog tima i preostalih stakeholdera. Možda možemo smatrati da upravljanjem očekivanjima korisnika ulazimo u sferu posla Project Managera, no, mišljenja sam da bismo u tome trebali aktivno sudjelovati jer smo ipak mi najbliži razvojnom timu, odnosno korisniku kada su funkcionalnosti u pitanju.

Za kraj, odnosno početak…

U konačnici, uspostavljanje opisanog procesa definitivno nije lak posao i zasigurno zahtijeva ogromnu količinu truda, rada, vremena te razumijevanja. Moramo inzistirati na navedenom jer isto kao produkt donosi kvalitetan proizvod koji čini korisnikov „život“ lakšim, a razvojnom timu osjećaj ponosa i satisfakcije.