Emir Sadiković Team Development Model

Jedan od modela upravljanja projektima koji je ostavio dubok trag ne samo u oblasti informacionih tehnologija (IT), već u industriji uopšte je svakako projekt menadžment (Project Management). Danas se kvalitet i mogućnosti tog pristupa uveliko preispituju i promovišu novi modeli koji su u stanju da otklone primećene nedostatke. Naravno da takve stvari uvek sa sobom nose određenu kontraverzu i izazivaju otpore. Bez namere da doliva ulje na vatru, ovaj članak nema ambiciju da nudi ad hoc rešenja, već samo razmatra problematiku iz realnog okruženja. Ipak, hajde da vidimo o čemu je reč.
Radi boljeg razumevanja, podsetimo se definicije projekt menadžmenta koja ga označava kao oblast znanja, veština, alata i tehnika koje se koriste za postizanje definisanih ciljeva projekta, određenih parametrima kvaliteta, troškova, vremenom i ostalim realnim ograničenjima [1].

Slika 1

Ono što karakteriše projekt menadžment (slika 1.) je upravljanje po vertikali, što podrazumeva jasnu hijerarhijsku strukturu i prenošenje odgovornosti s vrha na niže. To samo po sebi ne može predstavljati nedostatak, jer dopušta kontrolu nad planiranjem i praćenjem projekta, upravljanje troškovima, ljudskim resursima (Human Resource Management), upravljanje rizicima, kvalitetom i ostalo što spada u opis odgovornosti projekt menadžera.

Problemi projekt menadžmenta u IT industriji

S pravom se pitate, u čemu bi se onda sadržao problem? Biće da je odgovor u statistici, prema kojoj na globalnom nivou, uključujući SAD, Evropu i Japan, od svih IT projekata koji se izvode, svega 16% spada u grupu Just In Time (JIT), što znači da se realizuju u predviđenom vremenu, u okviru očekivanih troškova i tačno definisanih funkcionalnosti (izvor: Standish Group). Čak 53% IT projekata bude završeno izvan parametara plana, dok 31% IT projekata nikada ne ugleda svetlost. Sve u svemu, isuviše izgubljenog novca da se ništa ne bi preduzelo po tom pitanju.

Slika 2

Analiza je pokazala da su savremeni sistemi (enterprise applications) i njihovi zahtevi isuviše kompleksni da bi pojedinac, ma kako stručan, energičan i sposoban, bio u stanju da stvori koherentnu sliku o datom projektu. Niko nije u stanju da postigne jednak fokus po svim zahtevima sistema i da jednakom pažnjom razmotri sve opcije koje su na raspolaganju. Dakle, sama vertikala hijerarhijskog modela predstavlja usko grlo, a rešenja koja se proizvode u takvom ambijentu su subjektivna i zavise od iskustva i percepcije projekt menadžera.
Nije to ono što našem sistemu, odnosno našem klijentu treba. Njemu treba rešenje tačno određenog poslovnog problema, znači objektivno rešenje, a ukoliko je ono promaklo fokusu projekt menadžera, neće ga ni biti. E, baš tu se krije tajna pomenutih 31% promašenih IT projekata, odnosno 53% projekata koji su probili rokove, premašili planirane troškove ili isporučeni bez dela zahtevanih funkcionalnosti.

Microsoft Solution Framework (MSF) – zvezda je rođena

Rešenje nameće elementarna logika koja nalaže ravnanje hijerarhijske strukture. Tehnički rečeno, potrebno je smanjiti hijerarhiju po vertikali, a povećati raspon rukovođenja. Sasvim uprošćeno, preuzeti sve odgovornosti od projekt menadžera i jednako ih raspodeliti na uloge (role) koje učestvuju u vođenju projekta. Tako smo došli do koncepta Team Development-a, odnosno tima jednakih (Team of Peers). Ovaj model provocira veliki broj pitanja i stvara strahovite probleme projekt menadžerima sa velikim i značajnim iskustvom. Probaćemo da kroz članak prodiskutujemo najčešća pitanja i probleme koji se javljaju, ali pre toga, upoznajmo se sa samim konceptom i njegovim elementima.
Iako već naziv modela (Microsoft Solution Framework) implicira tvorca, istine radi, valja reći da je koncept razvijan na više različitih strana (upućujem čitaoca na izdanja Addison-Wesley), a Microsoft je uspešno sistematizovao sva znanja i iskustva, kako svoja tako i tuđa, u pomenuti model. Da ne bude zabune, MSF nikako nije metodologija vođenja projekata, jer bi svaki pokušaj da se propiše receptura za uspešno vođenje projekata bio unapred osuđen na propast, zbog ogromnog broja mogućnosti koje stoje na raspolaganju. Umesto toga, MSF predstavlja koncept ili model za definisanje jedinstvenih rešenja koja se odnose na jedinstvene sisteme ili organizacije.
Kroz seriju članaka ćemo se detaljno pozabaviti sadržajem čitavog modela, a za njegovu početnu tačku možemo usvojiti MSF Team Model for Application Development. Složiće te se da ima logike u tome, jer svaki posao počinje odabirom i organizovanjem ljudi koji će ga obaviti.
U cilju širenja raspona rukovođenja, ovaj model promoviše dva principa. S jedne strane princip jasne podele zadataka i ciljeva u okviru IT projekta (clear accountability), a s druge princip deljene odgovornosti (shared responsibility). Da bi bilo moguće objasniti šta tačno znače navedeni principi, upoznajmo se prvo sa ulogama u Team Development modelu i sa njihovim odgovornostima.
Model definiše šest uloga (role clusters): Product Management, Program Management, Development, Testing, User Experience (ranije User Education) i Release Management (ranije Logistic Management).

Slika 3

Glavni zadatak Product Management uloge je da obezbedi zadovoljstvo klijenata (customer satisfaction) u užem smislu, dok je šire posmatrano možemo povezati sa kompleksnijim delovima TQM-a i marketinga, kao što su customer retention ili migration management, što svakako izlazi izvan fokusa ovog članka. Shvatite pojam klijenta krajnje uslovno u ovom slučaju, jer klijent može biti naručilac sa strane, ali i preduzeće koje od svog IT sektora očekuje rešenje poslovnog problema. Isto tako, napravite jasnu razliku između klijenta i korisnika, jer prvi plaća isporučeno rešenje, dok ga drugi samo koristi.
Realizacija zadataka Product Management-a se ostvaruje dvosmernim delovanjem. Prvo prema timu, zastupajući potrebe i zahteve klijenta, ali i prema klijentu, zastupajući tim i njegove mogućnosti. Lider ove uloge je odgovoran za identifikaciju i razumevanje zahteva klijenta, uspostavljanje zajedničke vizije između članova tima i klijenta, obezbeđenje da će se rešenje koje razvije projektni tim odnositi na realne poslovne probleme klijenta. Drugi važan zadatak je intenzivna komunikacija sa klijentom i usmeravanje njegovih očekivanja. Dakle, jasno je da Product Management identifikuje i promoviše poslovnu vrednost IT projekta.
Fokus uloge Program Management je da ispuni ciljeve i obezbedi isporuku rešenja u predviđenom roku, sa definisanim funkcionalnostima, odnosno pravi proizvod u pravo vreme. Lider ove uloge upravlja planom projekta, koji je napravljen uz učešće svih rola u modelu. Sva odstupanja od plana, bilo da se radi o zaostatku ili prednjačenju, prijavljuju se program menadžeru koji određuje kakav uticaj to može da ima na ostale uloge u timu i koordinira izmene u planu. Ova uloga inkorporira i zadatke projekt menadžera, kroz praćenje i upravljanje troškovima, upravljanje Master Project Plan-om, upravljanje rizicima, resursima itd. Ipak, U koordinaciji sa Product Management-om, ova uloga ima jak uticaj na samu arhitekturu poslovnog rešenja.
Zadatak uloge Development se odnosi na izradu proizvoda, odnosno implementaciju rešenja, kao i na tehnološki konsalting. Jako je važno da članovi ove role ne budu fokusirani samo na izradu kôda prema funkcionalnoj specifikaciji, već imaju u vidu i sam poslovni problem koji se rešava. Inače, česta je pojava da programeri razvijaju kôd prema dokumentaciji koja im se dostavi, ali da pri tome ne znaju ništa o kontekstu u kome će se to rešenje primenjivati. To sigurno ne može doprineti kvalitetu rešenja.
Ostale uloge imaju zadatak da obezbede potreban kvalitet rešenja, olakšaju i unaprede upotrebu proizvoda, kao i da olakšaju uvođenje i održavanje.
Nakon ovog kratkog pregleda uloga u Team Development modelu, jasan je princip podele zadataka, gde svako tačno zna šta mu je činiti, ali se pri tome ni za tren ne gubi fokus sa poslovnog problema koji se rešava. Tome služi princip deljene odgovornosti, gde su sve uloge u međusobnoj zavisnosti i balansu. Problem se brzo uočava onoga trena kada dođe do neravnoteže. Zbog intenzivne komunikacije među liderima uloga, svi su upoznati sa delovanjem ostatka tima, a pri tome uspevaju da ostanu fokusirani na svoj zadatak. To je odličan način da se stekne koherentna slika o projektu, a da se pri tome ne gubi dodatna energija i vreme.
Važno je napomenuti da u Team Development modelu ne postoji glavna uloga. niti postoji osoba koja kontroliše rad tima. Deljena odgovornost podrazumeva zajedničku viziju i zajedničko razumevanje poslovnog problema, tako da su svi u funkciji njegovog rešenja. To podrazumeva jednakost svih uloga u projektu (Team of Peers), što nas dovodi do pitanja koje se najčešće postavlja: Ko je u tom modelu odgovoran za izvođenje projekta? Upravo to je ona prelomna tačka nerazumevanja koncepta i odbijanja da se uloži dodatni napor u istraživanje, već se lakonski zaključuje da niko nije odgovoran, a to već liči na neorganizovani sistem koji treba izbegavati.
Ipak, odgovor je nešto drugačiji. Odgovornost leži na celom timu, odnosno na liderima definisanih uloga u timu koji su odgovorni za kvalitet obavljenog posla koji njima pripada. U ovom delu dolazi do izražaja princip jasne podele poslova (clear accountability). Drugi princip, deljena odgovornost (shared responsibility), upućuje na međusobnu zavisnost svih definisanih rola, najmanje iz dva razloga. Prvi je neophodnost, jer je nemoguće izolovati rad jedne grupe od ostatka tima, a drugi je korist, jer je tim efektivniji ako svaka grupa u potpunosti razume kontekst, odnosno ako ima koherentnu sliku o celom poslu.
Iako svaka uloga u timu ima jednaku vrednost, koncept tima jednakih ne treba shvatati bukvalno, jer se odluke koje su važne za projekat ne donose konsenzusom, već je odgovornost za njihovo donošenje jasno definisana i dodeljena u samim rolama.
Još jedno od pitanja koje domaći projekt menadžeri rado postavljaju je: Da li je moguće raditi na dva ili više projekata istovremeno primenom Team Develoment modela?
Ne želeći da ulazim u lavirinte organizacionih struktura, pokušaću da dam odgovor sa stanovišta zadovoljstva klijenata, i to retoričkim pitanjem: da li je moguće imati ženu i ljubavnicu u isto vreme? Koliko bi naš klijent bio zadovoljan saznanjem da se njegov poslovni problem rešava polovičnim angažmanom, nije previše teško naslutiti, baš kao ni reakciju žene.
Ne bih voleo da se stekne pogrešan utisak da imam nešto protiv uloge projekt menadžera, pogotovo domaćih. Naprotiv, mislim da bi njihovo znanje i iskustvo bilo od presudnog značaja za implementaciju koncepta kakav je MSF. Samo je potrebno malo volje i hrabrosti da se napravi iskorak iz sigurnosti koju im pruža oprobani model. Na kraju, zar inovacija i usavršavanje nije obaveza svih ljudi koji su preuzeli odgovornost za obavljanje nekog posla?

Zaključak

I pored činjenice da uslovi poslovanja kod nas nisu još uvek sasvim regulisani i da kvalitet proizvoda ili usluge još nema onu težinu kakvu bi morao da ima, verujem da je jako važno uložiti napor i poboljšati svoje poslovne procese u budućnosti i na taj način se pripremiti za promene u okruženju koje su neminovne. IT menadžeri bi morali da budu vođeni poslovnim ciljevima i poslovnim strategijama organizacije, a informatička rešenja koja isporučuju moraju da ih podrže. Model MSF je upravo okvir u kome svaka organizacija može da pronađe put do svog jedinstvenog poslovnog rešenja.

Verzija za štampu