Knjiga je nastala na osnovi literature (članki, knjige, internet) in obsežne raziskave, v kateri je sodelovalo 250 slovenskih podjetij, institucij in drugih združb.
VSEBINA: Agilna miselnost in delovanje * Agilne metode * Agilni pristopi za obsežnejše projekte * Hibridni agilno-tradicionalni pristop * Pogodbena razmerja agilnih projektov * Agilni timi in ljudje * Agilna podjetja in druge združbe (270 strani).
Projektna pisarna (PMO, angl. project management office) je oddelek, ki v združbah ustvarja okolje, v katerem motivirani projektni timi učinkovito izvajajo projekte, ki podjetju (oziroma drugi vrsti združbe – instituciji, agenciji, društvu, ipd.) dolgoročno prinašajo koristi. O projektnih pisarnah smo pisali že ob pripravi prve knjige in takrat ugotovili, da:
obstajajo 4 ravni projektne pisarne – administrativna, center odličnosti, managerska in strateška;
svoje poslanstvo opravljajo v okviru naslednjih sklopov aktivnosti – administrativa pomoč, razvoj in uveljavljanje metodologije, usposabljanje in svetovanje, kadrovanje, baza znanja, nadzor projektov, management projektov in podporo procesu strateškega managementa.
Seveda vse PMO v vseh združbah ne opravljajo vseh navedenih
nalog. Poudarimo naj, da je PMO »v službi« vodstva združbe in managerjev
projektov, ki naj bi opredelili, katere od navedenih nalog bi potrebovali za
boljše opravljanje svojega dela. Načeloma pa PMO za oboje ustvarja ustrezno »projektno
okolje«, ob tem pa vrhnjemu vodstvu priporoča najustreznejše kandidate za
prevzem managementa prihajajočih projektov
ter ga informira o izvajanju
projektov, managerjem projektov prav lahko pomaga z administrativno podporo, informacijami
s preteklih projektov in mentorstvom.
Vse to naj bi veljalo za PMO, ki delujejo v združbah, kjer
projekte izvajajo tradicionalno, torej ne-ciklično. V tokratni raziskavi pa nas
je zanimalo ali (in v čem) se PMO, ki podpira agilne projekte, razlikuje od tistih,
ki delujejo v okolju tradicionalnih projektov.
Pri proučevanju literature smo najprej ugotovili, da je ključna naloga PMO v agilnih organizacijah management portfelja projektov – torej vse tisto, kar smo obravnavali pod tem področjem v prejšnjem prispevku. Avtorji najpogosteje omenjajo poročanje in skrb za »table«, kjer je prikazan napredek projektov oziroma posameznih nalog (angl. feature, user story; običajno so to Kanban table), spremljanje stroškov, skrb za enakomerno obremenitev ljudi ter skrb, da so projekti / naloge skladni s strateškimi usmeritvami.
Nabor nalog 121 slovenskih projektnih pisarn (raziskava maj 2020, prikazan je % PMO, ki opravljajo posamezne naloge)
In kaj drugega še dela? Pri različnih avtorjih smo našli
naslednje naloge:
opredelitev vizije projektov (čemur v »tradicionalnem projektnem žargonu« pravimo namen in učinki), pomoč pri določanju ciljev, planiranju, kadrovanju timov
administrativne naloge (npr. javna naročila)
usklajevanje urnikov ciklov in odvisnosti med timi
periodični pregled in prilagajanje planov (in pristopov)
razvoj in uveljavljanje agilnih procesov in standardov (npr. razvoj metrik)
skrb za agilno organizacijsko kulturo
analiza potreb po usposabljanju in organizacija usposabljanj
podpora – mentorstvo, osebni trening (angl. coaching)
V osnovi so navedene naloge zelo podobne tisti v
tradicionalnih PMO, pri čeme se pri »agilnih« večkrat omenja agilnost (metode,
procesi, kultura), kaj je povsem razumljivo.
In kakšno je stanje v slovenskih PMO? Pri majski raziskavi
smo sledili ključnih skupinam nalog, ki smo jih povzeli po avtorjih »tradicionalnih«
pisarn. Naj najprej omenim osnovne ugotovitve: od 231 anketirancev jih je 121 (53%)
navedlo, da imajo vzpostavljeno projektno pisarno, pri čemer je le-teh nekoliko
več tam, kjer projekte izvajajo tradicionalno – PMO imajo v 54% takih združb, med
tem ko jih je v 47% tistih s cikličnimi projekti.
Naloge PMO prikazujemo v grafu, pri čemer smo posebej
prikazali odstotek PMO, ki določene naloge opravljajo v okolju tradicionalnih oziroma
cikličnih projektov. Kot vidimo, nikjer ni razlike več kot 15%, in le dve skupini
nalog odstopata za več kot 10% (skrbništvo projektnega informacijskega in vzdrževanje
baz preteklih projektov), kar pa tudi ni omembe vredna razlika. Lahko torej
ugotovimo, da so naše ugotovitve dokaj skladne s priporočili iz literature in
da naše PMO delajo prave stvari! Žal pa nismo raziskovali, kako kakovostno
opravljajo navedene naloge in koliko njihove napore cenijo (ter predloge
upoštevajo) njihove stranke – vodstvo in managerji projektov. Mlajši
raziskovalci – tu je ideja za vaše raziskave 😊.
Poleg agilnejše organizacije, ki smo jo obravnavali prejšnjič, je agilno (agilnejše) delovanje podjetja odvisno tudi od managementa podjetja in njegovega poslovnega modela. Kot vemo, pa se management podjetja deli na strateški management (dolgoročno umerjanje), ki je predvsem v domeni vrhnjega managementa (uprave), in operativni management, ki ga uprava prepušča srednjemu managementu. Pod pojmom operativni management smatramo skrb za tekoče zadovoljevanje strank (proizvodnja in dobava izdelkov, odličnost storitev).
Ko je govora o slednjem, moderne organizacije vse bolj sledijo načelom vitke proizvodnje, razvitih v japonski Toyoti. Ta načela se osredotočajo na zmanjševanje stvari/nalog, ki ne dodajajo vrednosti (oz. naj jih kupec ne bi plačal): preveč narejenega, zaloge, čakanje, gibanje, transport, popravila in dodelave, prevelika funkcionalnost in kakovost ter neizkoriščen potencial zaposlenih. Ko govorimo o vitkosti, je govora tako o poslovnih kot proizvodnih procesih. Sprememb procesov se lotevamo z majhnimi koraki (Kaizen) ali projekti, pri tem pa se pogosto sledi metodi Six Sigma.
Ko je govora o projektih, v bistvu poznamo štiri ključne tipe glede na vire (od kod izhajajo oz. kdo bo koristil rezultate). Trije tipi običajno izhajajo iz strateških usmeritev in dolgoročno zagotavljajo korist združbi – razvojni (raziskave in razvoj izdelkov in storitev), investicijski (gradnja, vzdrževanje, nakup opreme) in organizacijski (spremembe organiziranosti in delovanja, nove metode dela). Četrti tip projektov izhaja neposredno iz trga – to so prodajni projekti, ki jih podjetja izvajajo za znane kupce na osnovi povpraševanj (razpisov) in pogodbenih razmerij.
To delitev izpostavljamo zaradi zavedanja, da v nekaterih
združbah lahko obstajajo vsi omenjeni tipi projektov, v nekaterih pa večinoma
le slednji. To so npr. podjetja, ki za druge razvijajo programske rešitve (kjer
se je v prvi vrsti razvil agilni pristop) ali ponujajo storitve (spletnega)
marketinga, kjer se agilnost tudi hitro uveljavlja. Ena od pomembnih
predpostavk, ki smo jo zaznali ob proučevanju primerov in literature, pa je, da
se je agilni pristop uveljavil predvsem na področjih »virtualnih« rešitev –
kjer rezultati projektov niso fizični (stavbe, oprema, izdelki).
Združbe običajno nimajo zadosti ljudi in sredstev, da bi izvedle vse želene projekte. Strateški management na podlagi ocen koristi, stroškov in poslovnih tveganj projekta odloča, katere projekte izvesti in katere ne, ter kateri projekti imajo prednost pri izvedbi. Projektni pristop je organizacijsko orodje, ki zagotavlja učinkovito doseganje želenih rezultatov, da pa se učinkovitost ne slabša ob izvajanju množice projektov (ki jih velikokrat izvajajo isti ljudje), pa skrbi management portfelja projektov.
Strateški management v agilnih združbah se po navedbah strokovnjakov razlikuje od tistega v tradicionalnih. Scanlandova (2020) ugotavlja, da odločitev za tradicionalni ali agilni pristop sloni predvsem na pogostosti sprememb na področju delovanja podjetja, kompleksnosti zahtev strank, številu možnih virov prihodkov podjetja, številu konkurentov in v kako inovativni branži delujejo (prva slika). Bolj, ko so navedeni dejavniki kompleksni, bolj smiselno je izbrati agilni pristop. Po mnenju avtorice se od tradicionalnega razlikuje v treh pomembnih stvareh:
pri agilnem pobude za novitete prihajajo od vseh zaposlenih, katerim je tudi sicer omogočeno komentirati predlagane strateške usmeritve (zakaj so za, zakaj proti, pomembnost / nujnost),
strateške analize so manj sistematične in natančne (in s tem manj časovno potratne),
strateške »delavnice« in s tem posodobitve strateških planov pa so pogostejše (vsaj na pol leta).
Kammeyer (2020) poudarja, da odločanje za nove izdelke
(storitve) sloni bolj na intuiciji in preverjanju prototipov na trgu, kot na
(obsežnih) tržnih raziskavah. Pri tem prisegajo na preverjanje vseh idej,
nekako po vzoru Edisona, ki je dejal, da mu ni 1000x spodletelo, ampak je
odkril 1000 načinov, ki ne delujejo. Prisegajo tudi na trajnostno učenje na
napakah in pretekli praksi, prednostni projekti pa so tisti z višjo pričakovano
dodano vrednostjo.
Kot smo že omenili, zagovorniki agilnosti v sklopu agilnih projektov ne omenjajo vloge projektnega managerja (samo-organizirani timi!), podobno pa v sklopu literature o agilnem strateškem managementu (in portfelju projektov) projekte pogosto imenujejo “pobuda” (angl. initiative) ali celo “ep”, namesto faz / mejnikov projekta, pa je govora o »izdaji« (angl. release). Slednje je razumljivo, glede na to, da poudarjajo redno in pogosto dobavo uporabnih (pol)izdelkov, ki naročniku že lahko prinesejo koristi. Poleg tega pa pojem »release« izhaja iz IT projektov, kjer je možnost koriščenja delnih rezultatov veliko pogostejša, kot npr. pri gradnji objektov.
Management portfelja in ravni planiranja v agilnih podjetjih
Podobno management portfelja projektov pogosto imenujejo upravljanje
(angl. governance). Davies (2016), ki se je usmeril v vlogo IT v
poslovanju združb, navaja, da upravljanje zagotavlja strateško usklajenost IT s
poslovanjem in zmanjšuje tveganja slabih rezultatov. Vključuje skrb za
skladnost projektov s strateškimi usmeritvami združbe, zagotavljanje dodatne
vrednosti, obvladovanje tveganj, obvladovanje virov ter merjenje učinkovitosti izvedbe
(preglednost procesov in napredka ter poročanje na podlagi rezultatov). Tudi Steinle
(2015) omenja skrb za prioritete in poslovno vrednost, poudarja pa pomen vizualizacije
pri koordinaciji ljudi in spremljanju napredka projektov.
Manager portfelja (Thompson, 2014, ga imenuje »lastnik«)
največ sodeluje z lastniki izdelkov (pri odločanju in spremljanju napredka), pa
tudi s poslovnimi analitiki, vodji programov in ključnimi inženirji (razvoj,
kakovost). Manager portfelja skrbi tudi za organizacijsko kulturo – uveljavlja
kulturo preglednosti in zaupanja, podprto s strani vrhnjega vodstva (Accenture,
2018).
V zadnjih letih se je močno uveljavil pojem »VUCA« svet.
VUCA je kratica besed nestanovitnost, negotovost, kompleksnost in nejasnost
(angl. volatility,
uncertainty, complexity, ambiguity). Načeloma pa že kakih 30 let
govorimo o tem, da je sprememba edina stalnica našega službenega in privatnega
življenja. Informacijska revolucija je res »vrgla svet s tečajev«.
Seveda je vsem jasno, da se je spremembam v okolju treba
prilagajati, če želiš preživeti in biti konkurenčen, zato se spreminja tudi
organiziranost podjetij in drugih združb (organizacij). Res je, da se vse
branže ne spreminjajo enako hitro, pa tudi velikost podjetja (in s tem povezan tržni
položaj) vpliva na nujnost in hitrost spreminjanja. Sicer nismo nikjer zasledili
trditev, da bi se morale vse združbe nujno prestrukturirati, poglejmo pa, kaj razumemo
pod pojmom agilna organizacija in na kakšen način se tradicionalne prelevijo v
agilne.
Ob proučevanju literature smo se hitro spomnili na projekte informatiziranja poslovnih procesov, ki so se začeli v 90-tih letih prejšnjega stoletja. Informatizacija je seveda zahtevala tudi prenovo poslovnih procesov, saj je programska oprema avtomatizirala mnoge postopke in procese. Zgodila pa se je tudi velika sprememba v delu managerjev. Naj spomnimo, ključna vloga managerjev je usklajevanje (aktivnosti, zaposlenih, sredstev) ter odločanje (organizacijsko, vsebinsko in strokovno), procesno gledano pa management vključuje planiranje izvajanja nalog, organiziranje ljudi, vodenje ljudi in kontroliranje izvedbe. Pomembno »vsebinsko« področje je tudi skrb za zadovoljivo usposobljenost podrejenih, kar pomeni, da skrbijo za redna dodatna izobraževanja in usposabljanja.
Ukinitev managerskih ravni za večjo agilnost organizacije
V omenjenem času informatizacije pa se je obremenjenost managerjev
z navedenimi nalogami močno zmanjšala, saj so njihovi podrejeni začeli dobivati
mnogo nalog mimo njih (poslovni procesi!), z opolnomočenjem ljudi pa se je
veliko odločanja delegiralo na nižje ravni – manager je po uvedenih spremembah npr.
odločal le še o 20% izjemnih primerih, med tem, ko je podrejeni sam sprejel 80%
strokovnih (vsebinskih) odločitev. Z manj usklajevanja (kdo bo kaj naredil) in
odločanja se je obremenitev managerjev z operativnim delom znižala, zato so
mnogi strokovnjaki takrat trdili, da bi morali managerji po novem 50% svojega
časa posvetiti razmišljanju, kako bi svojim podrejenim olajšali delo (sistem,
metode, dodatna znanja, ipd).
Po drugi strani se je – vsaj tako je slutiti iz mnogih »agilnih«
člankov – odvijala borba med izvajalci aktivnosti in managerji projektov (če se
omejimo le na projekte, kjer se je agilni pristop najprej uveljavil). Po mnenju
prvih, so managerji postavljali nerazumne roke in pozabili, da odličnega
managerja – poleg organizacijskih – krasijo predvsem njegove voditeljske
veščine. Ne trdimo, da je to ključni vzrok, da so »agilneži« začeli zagovarjati
samo-organizirane time (v smislu »postite nas pri miru, mi bolje vemo, kako je
treba kaj narediti, kot vi«), je pa vsekakor eden od pomembnejših razlogov.
Žal pa tudi pri samo-organiziranih timih ne gre vse brez težav, poleg tega se v »agilnem svetu« nekako zanemarjajo osebnostne lastnosti ljudi – predpostavlja se, da so vsi ljudje enaki ali vsaj zelo podobni, ne glede na to, da je nekdo bolj ustvarjalec, drugi voditelj, tretji analitik in četrti »prodajalec«. Da ne govorimo o tem, da so nekateri bolj timski delavci, kot drugi, eni bolj uživajo v svojem delu, eni živijo za kariero, ipd. Tako se je pojavila »formalna vloga« uslužnega vodje (o čemer smo že pisali), torej nekoga, ki je koordinator tima, katerega član je, ne pa kot nadrejeni manager.
Vse navedeno je nekako pripeljalo do tega, da so moderne
agilne organizacije zmanjšale število managerski ravni, managerji pa so se
pridružili timom, katerimi so bili prej nadrejeni (slika 1). No, težko je reči,
da so se take spremembe res dogajale v večjih starejših organizacijah, vsekakor
pa so mlajše organizirane bolj plosko. Opozorimo pa še na to, da je o agilni
organizaciji veliko lažje govoriti v primeru »virtualnih« izdelkov oz. storitev
(torej, kadar podjetja ne proizvajajo fizičnih izdelkov) – IT podjetja,
storitve bančništva in zavarovalništva, marketinške agencije, spletne rešitve,
ipd…
Kot trdi Holub (2015), je šel proces prestrukturiranja še
naprej. Kot vidite na desni strani prve slike, so »nadrejeni« narisani pod izvajalskimi
timi. Avtor trdi, da »nadrejeni« v agilnih organizacijah ne ukazujejo,
delegirajo in kontrolirajo, ampak »uslužno« skrbijo, da timi ustvarjajo š čim
manj težavami. No, nekdo mora tudi poskrbeti, da timi proizvajajo »prave stvari«,
kar pomeni, da imajo nadrejeni še vedno pristojnosti odločanja, kateri projekti
se bodo izvajali.
Agilna organizacija – managerji se preselijo v time
Mnogi »agilni« avtorji tudi omenjajo »silose«, kot
značilnost zastarelih organizacij. Saj veste, gre za sindrom »mi in oni … mi
smo najboljši, z njimi si ne moremo pomagati«, kar naj bi pomenilo, da se
oddelki brigajo le za svoje naloge in težko sodelujejo z drugimi. Res se to še
dogaja, a v bolj mili obliki, kot včasih. Predvsem pa so več-disciplinarni
projektni timi (ki se niso pojavili šele z agilnostjo) promotorji in
spodbujevalci sodelovanja med različnimi strokami in oddelki. No, poleg
projektne matrične organizacije obstajata tudi produktno ali regijsko matrična
organizacija, ki spodbujata sodelovanje in rušita silose in nevidne zidove med oddelki.
»Agilna nadgradnja« matričnih organizacij pa je prej omenjeno
vključevanje managerjev / vodij v delo timov (desna stran slike 2). Managerji
projektov so tako postali uslužni vodje timov, managerji področij (funkcijski,
regijski, produktni) pa strokovni koordinatorji svojih področij. Poleg tega, da
na enem projektu opravljajo svojo strokovno nalogo (kot član tima), so
povezovalci vseh zaposlenih iz svojega področja, kjer skrbijo za razvoj stroke
in medsebojni prenos dobre prakse (ter opozarjanje na težave in slabo prakso).
Naj omenimo še to, da so v nekaterih agilnih organizacijah time preimenovali v
moštvo (angl. squad),
če pa ima projekt več timov, pa se skupaj imenujejo pleme (angl. tribe).
Za konec pa še – bolj za šalo, kot zares – pohvalimo
»agilno« zavest slovenskih managerjev. Čeprav strokovnjaki stalno poudarjamo
nujnost profesionalizacije projektnega managementa (zaradi potrebnih
organizacijsko vodstvenih veščin managerjev), se v naši praksi to relativno
slabo upošteva. Tako projekte – poleg svojega strokovnega dela – vodijo ključni
strokovnjaki, kar je v vseh pogledih agilno. Ali pa imajo najboljši »kreativci«
tudi sposobnosti uslužnega vodje, je pa že druga zgodba…
Vrste pogodb, ki smo jih obravnavali v prejšnjem prispevku, smo povzeli po priročniku ameriškega globalnega združenja PMI (Agile practice guide, 2017). Poglejmo pa si še nekaj drugih vrst. Pogodbo »Čas in material« (angl. Time & Materials), sicer pogosteje uvrščajo med »tradicionalne« pogodbe, a se uporablja tudi pri agilnem pristopu, pri čemer se pri slednjem več omenja nekoliko modificirana različica »Omejen čas in material« (angl. CappedTime & Materials). Ta tip pogodbe, ki je neke vrste hibrid med »Fiksno ceno« in »Stroški+«, se najpogosteje uporablja, kadar obseg projekta ni zadosti jasno opredeljen, da bi omogočal dober plan izvedbe (in s tem plan stroškov). Tipični projekti so raziskovalni in svetovalni, pa tudi nekateri IT projekti.
Medtem, ko naročnik material plačuje na podlagi faktur, ki jih je plačeval izvajalec, se delo slednjega obračunava po v pogodbi opredeljenih urnih ali dnevnih postavkah – izvajalec npr. v ponudbi zapiše, kolikšen je strošek ure dela programerja (poslovnega analitika, arhitekta,…), naročnik pa izvajalcu plača število ur posameznih izvajalcev v dogovorjenem obračunskem obdobju (cikel, mesec, faza projekta). Če pa predpostavimo, da imajo izvajalci v teh urnih (dnevnih) postavkah že vračunan pričakovan dobiček (provizijo), je ta pogodba v delu, ki se nanaša na delo zaposlenih, v bistvu pogodba »Fiksni stroški +« oziroma še celo bolje »Fiksni dobiček« (angl. Fix profit), kjer dobiček raste s številom ur dela. Odlično za izvajalca – tveganja napak, sprememb in vsega dodatnega dela prevzema naročnik.
Za naročnika podpis take pogodbe pomeni, da mora skrbno nadzirati delo izvajalca, predvsem učinkovitost ljudi. Če naročnik nima strokovnjaka, da bi kompetentno ocenil realnost planiranih in porabljenih ur dela izvajalca, mu pač ostane le zaupanje, da izvajalec ne bo pretiraval s količino ur dela… Ponovno pa opozarjamo na težavnost izbire pravega ponudnika na podlagi urne postavke, saj v ponudbi ni navedbe količine ur. No, tveganje se nekoliko zniža pri pogodbi »Omejen čas in material«.
Pogodba “Omejena cena in material”
Tudi agilni projekti poznajo pogodbe s fiksno ceno, vendar se cena ne določi za celoten projekt, ampak za del projekta (vsebinsko ali časovno). Obstajajo pogodbe z določeno fiksno ceno na točko uporabniške zgodbe, cikel ali fazo. Plačevanje po fazah smo omenili že prejšnjič, a takrat smo govorili o faznih pogodbah (z različnimi cenami). V primeru pogodbe s fiksno ceno na cikel se cikli izvajajo, dokler je naročnik pripravljen plačevati izvajalca, dokler ni zadovoljen s funkcionalnostjo proizvoda oziroma ko je dosežena želena dodana vrednost. Za naročnika je ta vrsta pogodbe še posebej uporabna v pogojih stalne dobave uporabnih delov končnega proizvoda (angl. Incremental Delivery), če mu vsak cikel prinese dodano vrednost. Nekateri celo odsvetujejo agilne pogodbe, če ni možno projekta razdeliti v več inkrementalnih dobav (www.people10.com).
Sicer pa, kot smo že omenili v enem od uvodnih »agilnih«
prispevkov: dokler vsak cikel prinese naročniku več denarja, kot je plačal izvajalcu
(takoj, kmalu oz. v razumnem časovnem obdobju), ne bo želel zaključiti
projekta. No, v tradicionalnem pogledu to ni več projekt (ker zaključek ni
vnaprej opredeljen), je pa zato vsak cikel neke vrste mini projekt.
Pogodba “Fiksna cena na cikel”
Omenili smo tudi fiksno ceno na točko zgodbe (angl. story point). Tudi ta je podobna pogodbi »Fiksna cena +«, s to razliko, da je tam že na začetku določena cena za uporabniške zgodbe, pri tej pa se določi le vrednost točke, zahtevnost uporabniške zgodbe pa se določa na začetku ciklov. Seveda ni potrebno posebno poudarjati, da naročnik pri izbiri izvajalca ne more vedeti, koliko ga bo projekt stal, in tudi ne more primerjati ponudb izvajalcev – ceno na točko lahko primerja, a ne ve, s koliko točkami bo posamezno zgodbo ocenil izvajalec.
Za konec pokomentirajmo še tisto od štirih vrednot agilnega manifesta, ki se nanaša na pogodbena razmerja: »Sodelovanje s stranko pred pogodbenimi pogajanji!« Jen-Chieh Ko (2017) recimo trdi, da če prepustimo pripravo pogodb pravnikom (poimenuje jih »Pravni vojščaki«, angl. Legal Warriors), bo pogodba za obe strani slaba (angl. Lose-Lose), saj naj bi bila po njegovih besedah (in po videnju pravnikov) dobra pogodba tista, ki je nobena stran noče z veseljem podpisati. Kot mnogi, tudi on poudarja zaupanje, ki je dejansko po našem mnenju ključna vrednota v ozadju agilnih pristopov. Zaupamo, da so člani tima samo-motivirani in da bodo v čim krajšem času prinesli naročniku ogromno dodano vrednost, naročnik pa jih bo za to pošteno nagradil.
Pa vendar, če smo vsi korektni in si zaupamo, potem brez težav podpišemo pogodbo, ki naše namere formalno zabeleži. Saj poznate tisto: »Čisti računi, dobri prijatelji«. Imamo pa Slovenci mogoče malo težav glede »poštenosti«, ker smo se zaradi tujih vladarjev v zgodovini naučili, da goljufanje (oblasti in tujih lastnikov) ni grdo neetično opravilo, ampak »iznajdljivost« in neke vrste »poslovna igra«. Pa vendar, če želimo uspešno uveljaviti agilne pristope izvajanja projektov, bo treba delati na etičnosti tako naročnika, kot izvajalcev. Sodelovanje, transparentnost in zaupanje … pa ne pozabite: če ni nevoščljivosti, bomo vsi pridobili!
Ko smo že omenili, naj bi na odločitev o uporabi tradicionalnega ali agilnega pristopa najbolj vplivala jasnost opredelitve končnih ciljev na začetku projekta in s tem povezana (ne)rutinska izvedba projekta, dodaten pomemben dejavnik pa je možnost koriščenja vmesnih rezultatov in s tem povezane dodane vrednosti, ki jo prinaša projekt. Ta naj bi pri agilnem pristopu rasla ves čas trajanja projekta, pri tradicionalnem pa dodano vrednost prinese šele povsem zaključen projekt.
Ker našteti dejavniki vplivajo na možnost jasne ocene (opredelitve) časa in stroškov izvedbe, ki skupaj z obsegom (ki naj bi bil pri agilnih projektih manj natančno opredeljen) predstavljajo ključne postavke pogodbe med naročnikom in izvajalcem, potem je jasno, da se tradicionalne pogodbe zelo težko uporabljajo za agilne projekte. Razlika v »jeklenih projektnih trikotnikih« (obseg, čas, stroški) je lepo prikazana na prvi sliki, pri čemer bi opozoril na trditev avtorjev, da agilni pristop temelji na viziji projekta, kar bi pomenilo, da sledi predvsem dodani vrednosti, ki jo prinaša projekt.
Razlike med pristopi, ki vplivajo na izbiro tipa pogodbe (povzeto po AOE.com)
Ena od oblike pogodb, ki poudarja usmerjenost v ustvarjanje koristi, je, da se pogodba ne podpiše za celoten projekt, ampak za vsako fazo posebej, cene pa se opredelijo na osnovi dodane vrednosti rezultatov faz. Faze načeloma niso cikli (sprinti), ampak več teh skupaj (pri IT projektih je npr. cilj faze izdaja (ang. release) nove verzije programske opreme z dodatnimi funkcijami). Ta tip pogodbe je lahko del obsežnejše več-nivojske pogodbe, kjer se pogodbeni odnos doreče z več dokumenti – v glavnem so dorečene zadeve, ki se ne spreminjajo (npr. garancije, arbitraža); zadeve, ki se lahko spreminjajo (npr. cene storitev, opisi izdelkov) se opredelijo v terminskem planu storitev, dinamične postavke, kot so obseg, časovni razpored in proračun, pa se formalizirajo v izjavi o delu. Ključna težava faznih pogodb pa je v tem, da težko primerjamo ponudbe različnih izvajalcev, ko izbiramo najustreznejšega.
Dodatna težava pogodb, ki slonijo na dodani vrednosti, pa je
tudi merjenje slednje, kar je lahko velik izziv. Eno je merjenje neposrednih in
posrednih koristi. Če razvijamo programsko opremo za podporo procesu reklamacij,
so neposredni učinki manjše število reklamacij, hitri odzivni čas, manj ur dela
ljudi, ne moremo pa pomeriti dviga ugleda firme, posledično več naročil, ipd. Seveda
je težava lahko tudi v tem, da izvajalec ne sme videti določenih poslovnih
kazalnikov (poslovne skrivnosti). Taka pogodba torej zahteva veliko stopnjo
zaupanja med naročnikom in izvajalcem. Je pa res, da ima običajno v takem
pogodbenem (partnerskem) odnosu izvajalec obsežnejšo nalogo – če je pri
tradicionalnem razvoju programske opreme le »razvijalec«, je pri agilnem tudi »ustvarjalec«
(sodeluje pri razvoju »poslovne« rešitve, ne le programske opreme). Če je govora
o dolgoročnem sodelovanju (brez časovne omejitve), kjer izvajalec pomaga
naročniku že pri analizi delovanja in iskanju smotrnih sprememb, ki jih potem
skupaj razvijejo in uveljavijo, govorimo o pogodbi »Razširjena ekipa«.
Naslednji tip pogodbe je »Fiksna cena +«. Obseg projekta se razdeli na mikro-rezultate (npr. uporabniške zgodbe) s fiksnimi cenami. Naročniku omogoča večjo kontrolo porabe denarja, izvajalcu pa zniža finančno tveganje prekomernega dela na raven posamezne funkcije. Veliko težavo pa vidimo v tem, da se uporabniške zgodbe jasno opredelijo šele na začetku posameznih ciklov. Kako naj torej izvajalec lahko realno oceni strošek razvoja uporabniških zgodb, če te še niso opredeljene?
Pogodba »Fiksiran rok in proračun« je oblika, ki popolnoma sledi temu, kar smo jo prikazali na prvi sliki. Prilagodljiv obseg projekta pomeni, da lahko naročnik – v okviru dogovorjenega časa in proračuna – v projekt vključi nove zahteve (funkcije, opravila), ki prvotno niso bile načrtovane, pri čemer naj bi te zamenjale nekatere prvotno planirane. Ta način sloni na pristopu, da lastnik izdelka na začetku vsakega cikla izbere v tistem trenutku najbolj pomembne funkcije … do porabe vseh sredstev in/ali do dogovorjenega roka, najmanj pomembne funkcije pa se ne razvijejo. Zasledili smo tudi poimenovanje Pogodba z dinamičnim obsegom, poznana pa je tudi pod nazivom »Money for nothing, change for free.«. Nekateri avtorji pa priporočajo tudi, da proračun, poleg planiranih stroškov, vsebuje tudi rezervni sklad za primer dodatnih ur dela. Dodatna možnost je deljenje finančnega tveganja, po pogodbi »Dosežen čas in proračun«. Izvajalca je mogoče nagraditi z višjo urno postavko v primeru dobave pred dogovorjenim rokom oz. dobi manjše plačilo v primeru zamude izvedbe.
Večino dodane vrednosti projekta lahko prinese le polovica predvidenih funkcij
Na predpostavki, da lahko želeno dodano vrednost projekta dosežemo v manj funkcijami, kot smo jih opredelili na začetku, sloni pogodba »Možnost predčasne odpovedi«. Če izvajalec pred rokom (tudi na polovici projekta) zadovolji potrebe naročnika, slednjemu ni potrebno plačati preostalega pogodbenega zneska (v pogodbi se določi nadomestilo za prekinitev pogodbe). Naročnik zniža stroške projekta, izvajalec pa dobi plačilo za storitve, ki jih ni potrebno izvesti. Smiselnost predčasnega zaključka projekta je prikazana na drugi sliki, ki izpostavlja tudi pomembno značilnost projekta, ki vpliva na odločitev, ali se projekta lotiti tradicionalno ali agilno – stalno rast dodane vrednosti. Uporaba agilnega pristopa je zelo priporočljiva, če je možno koristiti vmesne rezultate! To je možno pri razvoju programske opreme, novozgrajenega objekta pa ne moremo (ne smemo) uporabljati, če vsa dela niso zaključena! Na pol razvitega avta pa tudi ne moremo začeti tržiti.
Vrste pogodb smo povzeli po priročniku Agile practice guide (PMI, 2017).
Pri vseh tipih projektov investitorji del projekta pogosto zaupajo
v izvedbo pogodbenim izvajalcem, lahko bi celo trdili, da večina projektov
vsebuje vsaj nekaj pogodbenega dela. Za podjetja, katerih ključni posel pa je
izvajanje projektov za druge (gradbena in druga inženiring podjetja, IT
podjetja, organizatorji dogodkov, svetovalna podjetja, odvetniške pisarne,
ipd.), pa vse projekte izvedejo na podlagi pogodb z naročnikom.
Poleg jasne opredelitve obsega projekta in nedvoumnih
specifikacij ciljev (s kriteriji kakovosti), pogodbe vključujejo tudi ključna
kriterija učinkovite izvedbe – rok in ceno izvedbe. Pri tem seveda velja, da
ceno storitve sestavljajo stroški izvedbe in provizija izvajalca (dobiček, ki
ga ustvari s projektom), za naročnika pa cena predstavlja njegov strošek po
naslednji formuli:
Zelo redko pa se zgodi, da so dejanski stroški izvajalca
enaki planiranim. Eden od možnih razlogov je seveda neustrezna ocena izvajalca,
obstaja pa še kar nekaj drugih virov spreminjanja stroškov: spremembe zahtev
naročnika, dražitev / pocenitev materiala, tehnične težave, nepredvidena dela,
itd. V primeru višjih dejanskih stroškov od planiranih bo izvajalec zaslužil
manj (manjša provizija), lahko pa se tudi zgodi, da bo projekt izvedel z
izgubo. Zato se želi s pogodbo zavarovati tako, ne bo kril vseh dodatnih
stroškov, ki niso neposredno njegova krivda (kot je npr. napačna ocena), ampak
si kritje le-teh razdeli z naročnikom.
Po drugi strani želi naročnik s pogodbo znižati možnost
zamude izvedbe s strani izvajalca, najpogosteje pa se to izvede s stimulativno »nagrado«
– ob izvedbi pred rokom, je lahko plačilo višje, ob zamudi pa manjše. To je
torej še dodatni dejavnik dejanske končne cene in dodatna pomembna postavka
pogodbe.
Poglejmo najprej »tradicionalne« pogodbe (največkrat
uporabljanje v gradbeništvu, pa tudi pri »neagilnem« razvoju programske opreme)
in ocenimo primernost le-teh za agilne projekte. Poznamo dve osnovni skupini
pogodb – pri prvi se v pogodbi določi cena, pri drugi pa stroški in provizija
izvajalca.
Verikalna črtkana črta prikaže delitev denarja v določeni situaciji
Najbolj poznana je Pogodba s fiksno ceno. Izvajalec
prevzame celotno tveganje s tem, ko sprejme nespremenljivo plačilo za delo, ne
glede na dejanske stroške. Pogodba je značilna za projekte “na ključ”, kjer
izvajalec prevzame celotno odgovornost, naročnik pa na samo izvedbo nima vpliva,
kjer je zelo jasno opredeljen končni cilj (in se večjih sprememb ne pričakuje),
poleg tega pa je način izvedbe dokaj »rutinski«. V primeru sprememb obsega in
specifikacij sledijo dodatna pogajanja in podpis aneksa. Ker zahteva ta vrsta
pogodbe jasno dorečene cilje in »fiksiran« končni rok, je neprimerna za agilne projekte.
Če želimo izvajalca stimulirali za učinkovitejše
obvladovanje stroškov in izvedbo pred rokom, izberemo pogodbo s Fiksno (maksimalno)
ceno in stimulativno provizijo (ang. Fixed price incentive fee, FPIF).
Poleg bonusa za izvajalca, če zaključi izvedbo pred rokom, oz. penalov v
primeru zamude, pogodba opredeli tudi kdo krije morebitne dodatne stroške. Izvajalcu
ta tip pogodbe ustreza prav z vidika skupnega prevzemanja tveganj, pri čemer se
v pogodbi doreče delež prevzema tveganj (npr. 40/60%). Priporoča se, da večji
delež prevzame stranka, ki laže obvladuje več tveganj (npr. napake pri izvedbi
veliko lažje obvladuje izvajalec, kot naročnik). V razmerju, kot je zabeleženo
v pogodbi, tako stranki pokrijeta prekoračitev stroškov ali pa si razdelita
prihranek, če so dejanski stroški manjši od planiranih). Velikokrat take
pogodbe vključujejo tudi nabor ključnih tveganj in oceno pomembnosti le-teh. Ta
pogodba je nekoliko primernejša za agilne projekte, saj vsebuje mehanizem
prilagajanja cene ob spreminjanju količine dela, vseeno pa zahteva jasno
opredelitev ciljev ob podpisu pogodbe, kar ni značilno za agilne pristope.
Obstaja pa še tretji tip pogodbe s fiksno ceno, imenujmo jo Prilagodljiva fiksna cena (ang. Fixed price economic price adjustment, FP_EPA), ki prvi tip pogodbe (Fiksna cena) nadgradi z možnostjo spremembe cene zaradi sprememb cen materialov in vrednosti denarja. Govora je o morebitni inflaciji, nihanju valut, spreminjanju cen surovin, ipd. Uporablja se predvsem za daljše mednarodne projekte, kjer je več možnosti inflacije in sprememb cen. Kljub prilagajanju je ta pogodba, iz istih razlogov, kot prva, neprimerna za agilne projekte.
Drugi tip tradicionalnih pogodb ima za osnovo stroške
projekta, poznamo pa jih pod nazivom »Stroški+«. Osnovna opcija je pogodba Stroški+
s fiksno provizijo. Izvajalec poroča naročniku o stroških izvedbe, ki mu
jih naročnik povrne, ob tem pa še vnaprej dogovorjen dodatek (provizijo, kot %
planiranih stroškov). Ne glede na višino stroškov je provizija izvajalca enaka.
Ta pogodba je primernejša za agilne projekte, če predpostavimo, da se stroški spreminjajo
z spremembami zahtev (obsega). Je pa res, da se donosnost projekta z
naraščanjem stroškov (pri nespremenjeni proviziji) manjša, kar ni motivacijsko
za izvajalca. Zato obstaja še opcija, kjer »fiksna provizija« pomeni fiksen % dejanskih
stroškov (večji stroški > večja provizija), a o tem več v knjigi.
Drugi tip pogodbe je Stroški+ s stimulativno provizijo,
pri katerem se provizija spreminja z višino dejanskih stroškov. Pri nižjih
stroških od planiranih je dodatek višji, pri višjih pa nižji. Npr. izvedba po
planu prinaša izvajalcu provizijo v višini 4% stroškov, v primeru prihranka 6%,
ob presežku pa le 1%). Lestvica pa je lahko še bolj progresivna, kjer presežek
lahko pomeni tudi izgubo za izvajalca (glej sliko). Zaradi slednjega je pogodba
nesprejemljiva za izvajalce agilnih projektov.
Tretji tip pogodbe – Ciljni stroški – je v določenem tolerančnem
polju planiranih stroškov podoben pogodbi s fiksno ceno – izvajalec dobi
nespremenljivo plačilo kadar so stroški npr. za največ 10% višji ali manjši od
planiranih (prihranki gredo izvajalcu, ki krije tudi presežke), v primeru
večjih prihrankov ali presežkov pa si izvajalec in naročnik te razdelita v
vnaprej dogovorjenem razmerju (kot je to veljalo pri pogodbi s Fiksno ceno in
stimulativno provizijo). Tudi ta tip pogodbe je značilen za pogodbe, ki
vključujejo tudi oceno tveganj in se običajno uporablja pri razvojnih
projektih, ko je rezultat relativno dobro poznan, a ne v celoti (zato je
primeren tudi za agilne projekte). Izvajalec se lahko dogovori tudi za odstotke
trženja izdelka.
V prejšnjih prispevkih smo pisali o tem, da zagovorniki agilnih pristopov priporočajo, da so agilni timi majhni, da so med delom locirani v skupnem prostoru, najboljša komunikacija pa je pogovor ob tabli. Za primere obsežnejših projektov pa priporočajo, da se projekt izvaja v večjem številu (majhnih) timov, kar je sicer podobno običajni organizaciji večjih projektov. Zelo pomembna razlika pa je v tem (vsaj kolikor smo uspeli razumeti priporočila stroke), da naj bi pri agilnem pristopu ljudje 100% delali le pri enem projektu, kar pa je v naši projektni praksi žal bolj izjema, kot pravilo. Večina projektov je organizirana matrično, pri čemer ljudje istočasno delajo v več timih (več-projektno okolje), timi pa so več-disciplinarni (sodelujejo ljudje iz različnih strok, časovno pa so različni strokovnjaki različno obremenjeni). Ker so oddelki locirani na različnih lokacijah (lahko v objektu, lahko v enem kraju, lahko po celem svetu), se združbe vse bolj poslužujejo različnih medijev za komuniciranje na daljavo, namesto da bi izgubljali čas in denar za potovanja. Ne smemo pa zanemarjati niti komuniciranja z naročnikom in podizvajalci.
Kadar člani tima niso locirani skupaj, govorimo o virtualnem timu in delu (sodelovanju) na daljavo. Komuniciranje je delno osiromašeno (razlaga), a moderna orodja za video komuniciranje zagotavljajo dokaj zadovoljivo sodelovanje. Pri proučevanju literature smo našli kopico priporočil za uspešno delovanje virtualnega tima. Čeprav ljudje delajo na daljavo, je priporočljivo, da se na začetku projekta srečajo v živo, da se med seboj bolje spoznajo. Uvodni sestanek (ang. kick-off meeting) izkoristimo tudi za pogovor o problemih (in dobrih praksah) v predhodnih virtualnih timih, na podlagi česar tim skupaj doreče pravila komuniciranja, določijo pa se tudi enotna orodja za sodelovanje na daljavo.
Priporočljivo je, da se uvodni sestanek nadaljuje z
izgradnjo tima (ang. team building). Vsekakor priporočamo, da vodja tima
opravi tudi individualne pogovore s člani tima – o njihovih vrlinah, slabostih,
(de)motivatorjih, ter o tem, kaj jim pomeni projekt (izziv, priložnost za
razvoj ali dodatno delo).
Virtualni tim in sodelovanje na daljavo
Med samo izvedbo je potrebno skrbeti za redno komunikacijo.
Pri virtualnih timih se še bolj kot sicer priporoča izvedba kratih dnevnih
sestankov (ang. daily Scrum),
nekateri avtorji pa priporočajo tudi »virtualne kave« (pitje kave na daljavo ob
pogovoru, ki ni vezan na delo), pa tedensko proslavitev uspehov tima (zaključevanje
težjih nalog ali tistih nalog, ki so bile zelo dobro izvedene v zadnjem tednu).
Redno komuniciranje, poleg strokovnih usklajevanj in debat, tudi dviguje pripadnost
timu in projektu. Poleg osebnega komuniciranja pa ne smemo pozabiti na
obvladovanje dokumentacije!
Moramo pa opozoriti tudi na različne oblike virtualnih
timov, ki vplivajo na razmerja in naloge managerja projekta. Ena oblika so
partnerski projekti, kjer manager le koordinira delo timov (pri čemer večine ljudi
ne vodi (ang. leadership),
prisotnega je manj timskega dela, razmerja pa so dorečena s pogodbami). Druga
oblika ne vključuje pogodbenih odnosov, vsi člani tima pa so interni sodelavci
(lahko tudi iz sestrskih / hčerinskih podjetij), kar pomeni, da manager tudi
vodi (motivira) ljudi, več pa je tudi (med)timskega sodelovanja (ustvarjalne
delavnice in soodvisne / skupne aktivnosti na daljavo). Tretja oblika je kombinacije
prej navedenih. Razlika je tudi v tem, ali imamo dislociran tim (z vodjem na
lokaciji) ali posameznike (ang. freelancer), ali delajo v službi ali od doma, itd. O tem več
v knjigi…
Lewisov model med-kulturnega komuniciranja
In če še malo dodatno zakompliciramo situacijo, ne smemo pozabiti na mednarodne virtualne time, ki so pogosti v partnerskih projektih, če ima podjetje hčerinske / sestrske podjetja na različnih kontinentih, pa tudi če iz drugega kontinenta prihaja naročnik ali kak podizvajalec. Poleg težave z različnimi časovnimi conami, velikokrat naletimo na druge kulture, kjer imajo različne stile komuniciranja (če se omejimo le na ta pokazatelj med-kulturnih razlik). Najbolj poznan je Lewisov model, v katerem je opredelil tri ključne kulture (glej sliko), države pa razporedil kot tipične za en stil ali med te. Seveda je za dobro sodelovanje potrebno poznati čim več značilnih dejavnikov kulture (znana je npr. Hofstedejeva teorija dimenzij kulture). Za uspešno komuniciranje se je treba zavedati značilnosti kultur, pri čemer pa ni zadosti le prilagoditi stila pogovora – ne smemo niti dopustiti, da nas sogovornikov način moti in nas spravlja ob živce, ker potem manj pogosto komuniciramo oz. pogovore (pre)hitro zaključimo. Nekateri celo na ljudi, ki ne komunicirajo »kot bi morali«, gledajo z viška in z njimi ne želijo sodelovati.
Naj omenimo še težavo z znanjem angleščine, slabšo izgovorjavo (kot posledica sinhroniziranih filmov) in naglase (Indija). Včasih je v teh primerih boljša komunikacija preko e-pošte, še boje pa je uporaba video konference, kjer se slišimo in vidimo, za boljše razumevanje pa še kaj napišemo ali narišemo na tablo.
Ob pregledu literature o posebnostih komuniciranja v agilnih timih smo prišli do zanimive dileme. Medtem, ko je v zadnjih dveh desetletjih v porastu število partnerskih projektov, ki slonijo na virtualnih timih in delu na daljavo (ki se je zaradi znanih okoliščin še posebej uveljavilo v letošnjem letu), agilni pristopi slonijo na timih, ki delajo v enem prostoru. Pisali smo že, da se priporoča, da so agilni timi majhni, zasledili pa smo trditve, da je pogoj za učinkovito (so)delovanje tima, da delajo skupaj (ang. co-located) in da je z dislociranimi člani agilnega tima težko sodelovati.
V projektnem timu imamo, ne glede na pristop (tradicionalni ali agilni), naslednje vrste komuniciranja: medsebojno strokovno/vsebinsko usklajevanje članov tima, organizirane ustvarjalne delavnice (iskanje idej, reševanje težav), koordiniranje dela (razdeljevanje nalog) in poročanje o izvedbi. Pri tradicionalnih projektih imamo še planske sestanke v fazi priprave projekta ter obravnavo sprememb med izvedbo, pri agilnem pristopu pa so planski sestanki v vsakem ciklu, ki se konča s skupno revizijo in retrospektivo.
Za vse navedeno velja, da na kakovost komuniciranja in izmenjave informacij vplivajo trije »mediji«, ki se dopolnjujejo: napisana ali povedana informacija (pisna ali ustna), telesna govorica ob ustnem podajanju informacije (ki je pri pisnem komuniciranju ni, pri telefonskem pogovoru pa je okrnjena), ter vizualizacija, ko »tekst« nadgradimo z »grafiko« – komuniciranje je veliko učinkovitejše, če ob debati še kaj narišemo na tablo, pa naj bo to pot dokumenta v podjetju, proces dela prodajnega referenta, tloris naprav in transportnih poti v proizvodni hali, skica novega izdelka ali tiskanega vezja, ali pa le zapišemo ključna dejstva, npr. prednosti in slabosti neke ideje (da so članom tima stalno pred očmi, ko se odločajo za »pravo« idejo).
Načini komuniciranja (Prince, 2017)
Vse navedeno je lepo prikazano v grafu, ki smo ga povzeli po Princeu. Zvočni posnetek je boljša informacija, kot le napisan tekst, saj dodaja ton izgovorjenega, delno pa se zazna tudi obrazna mimika (ali se je govoreči pri podajanju informacije smehljal ali je govoril jezno »skozi zobe«). Mnogi se ob tem spomnijo na Mehrabianovo pravilo 7-38-55, ki govori o tem, da sporočilo, ki ga dobimo od nekoga, sestavljeno takole: 7% besede + 38% ton govora + 55% obrazna mimika. Vendar pa moramo opozoriti, da pravilo ni splošno veljavno, ampak velja le za primer izražanja čustev in stališč (všeč mi je, ni mi všeč). Nekje sem našel zanimiv primer glede (ne)veljavnosti pravila v vseh primerih: nemogoče je razumeti informacijo, če na TV poslušate in gledate nekoga (38%+55%), ki govori v nekem afriškem jeziku (le 7%).
Vsekakor zaznavanje tona govora in opazovanje telesne
govorice vpliva na komuniciranje v timih, a ne v takšni meri, kot navaja Mehrabian.
Pokaže nam, kako sodelavec sprejme neko delo v izvedbo, kako je navdušen nad
neko idejo (ali če mu ni všeč), opazimo, kdaj je brezbrižen ob neki debati, koliko
ga je neka težava ali napaka vrgla s tira, in konec koncev tudi, če pošteno poroča
o opravljenem delu. Glede slednjega si lahko veliko preberete na internetu
(znaki, da nekdo laže).
Video posnetek je torej še boljši od zvočnega, na grafu pa opazimo, da je med njima e-pošta, ki pa je na začetku druge krivulje. Razlika med krivuljama je v tem, da prva nakazuje enosmerno komunikacijo, druga pa dvosmerno. V primeru e-pošte je torej pisna, telefonski klic pa ustna. Ključna prednost dvosmerne komunikacije (pogovora) je, da nam omogoča postavljanje dodatnih vprašanj za pojasnjevanje slišanega, preverjanje razumevanja in s tem niža možnost nesporazuma. Komunikacija je hitrejša in omogoča povratni odziv prejemnika informacije (ki pri e-pošti ni samoumeven). Veliko bolj verjetno je, da bo nekdo nekaj naredil, če ob prejetju naloge potrdi izvedbo.
In če se vrnemo na prej omenjeno govorico telesa, prek
telefona slišimo ton glasu, na video konferenci pa tudi obrazno mimiko (seveda
odvisno od tehnike in nastavitev – včasih vidimo le množico majhnih obrazov na
ekranu telefona, kjer gledamo tudi risbe…). Zato je najboljša komunikacija iz
oči v oči, ki omogoča vse prej našteto, lahko pa spremljamo celo telo sogovornika.
Kot že rečeno, pa je komuniciranje še učinkoviteje, če si zraven še kaj
narišemo ali napišemo – zadnja raven v grafu: iz oči v oči ob tabli.
Zdaj torej razumemo, zakaj se priporoča, da naj bodo agilni timi locirani skupaj in zakaj je tipična fotografija agilnega tima tista, ki jih kaže, kako debatirajo ob tabli. Našli pa smo še nekaj navodil glede komuniciranja v agilnem timu:
čim več se osebno pogovarjajte (ang. face to
face)
ob težavah čim prej načnite debato (s skrivanjem
ali zanemarjanjem se težava veča)
ne sme vas biti strah povedati svojega mnenja oziroma
podati predlog ali idejo (tudi ob tveganju, da bodo drugi mnenje zavrnili)
pomembno je stalno učenje od drugih ter širjenje
svojega znanja in izkušenj
bodite »potrpežljivi poslušalci« (razmišljate
širše, o različnih možnostih … resno razmislite, preden kategorično zavrnete
idejo)
vedno podajte povratno informacijo – pohvalite
dobro delo, povejte, če kaj ni bilo v redu (ne zatrite v sebi)
Člani agilnega tima se morajo medsebojno “vzgajati”, da se uveljavi kultura komuniciranja, kot je prikazana v zgornjih alinejah. Seveda, če imamo formalnega vodjo tima, se to pričakuje od njega ali pa je to naloga Scrum mojstra. Vsekakor bi vse našteto veljajo tudi za delo v »tradicionalnih« timih, “tradicionalna” priporočila pa veljajo za agilne time. Pri tem pa ne pozabimo na uslužno vodenje tima, ki ga seveda priporočamo tudi tradicionalnim (projektnim) managerjem.
Na internetu smo našli zanimivo predavanje Esther Derby o tem, kako pomembna sta sestava tima in uvodni dnevi sodelovanja, pri čemer ji je kot osnova služilo Hackmanovo 60-30-10 pravilo. Avtor je na podlagi raziskav ugotovil, da je 60% uspešnosti tima določeno še preden se člani srečajo – s sestavo tima. O uspešnosti tima torej v večini odločajo tisti, ki določijo sodelujoče v timu – večinoma linijsko-funkcijski managerji, v nekaterih primerih pa manager projekta (v združbah z visoko projektno organizacijsko kulturo, oziroma tam, kjer je tako opredeljeno z internimi pravili). 30% uspešnosti je odvisno od uvodnih korakov – spoznavanja, kako se člani tima »začutijo«, iskanja kompromisov glede različnih navad in vrednot, ipd. (faza zagona tima), le na 10% uspešnosti pa lahko vplivamo z vodenjem tima med izvajanjem projektnih aktivnosti. Seveda navedeno sloni na predpostavki, da večina članov še nikoli ni delala skupaj v oddelku ali projektu.
Derbyeva je podala še nekaj priporočil za vodenje tima v posameznih fazah. Pri sestavi tima je potrebno iskati ljudi, ki morajo – poleg tega, da imajo potrebna strokovna znanja in veščine – tudi razumeti »soodvisnost« pri delu in se zavedati skupinske odgovornosti. Tim naj bo majhen: idealno je 5 ljudi! Teoretično vsak dodaten član prinaša višjo produktivnost tima, a hkrati viša potrebe po urejanju medsebojnih razmerij in zahteva več komuniciranja. Raziskave kažejo, da pri največ 10 ljudeh produktivnost še »nadvlada« usklajevanje, potem pa se produktivnost tima začne manjšati.
Timu je potrebno omogočiti dostop do znanja in informacij izven tima (nemogoče je sestaviti tim z vsem potrebnim znanjem). Pri zagonu tima je predvsem pomembno jasno določiti meje odločanja! Npr. tim sprejema vse tehnične odločitve, ki ne vplivajo na delo drugih timov, na druge komponente izdelka ali na druge izdelke. Skupaj z managerji pa se odločajo npr. kdo se bo pridružil timu, kdo bo šel na kakšno dodatno usposabljanje, ipd. Jasno je treba opredeliti, kaj pomeni pojem »narejeno« (ang. definition of done) – ne za posameznike ampak za tim (člani medsebojno prevzemajo naloge, da bi čim prej predali skupen izdelek).
Uspešen agilni tim (hibrid po Hackmanu, Belbinu & Hodi)
Priporoča se tudi pregledna vizualizacija napredovanja projekta! Nadrejeni težko zaupajo, če nimajo informacij, zato pogosto sprašujejo o stanju in napredku, kar timu ni všeč (občutek, da hočejo izvajati »micro-management«). Zato mora tim poskrbeti za vizualizacijo (npr. Kanban tabla, informacijski sistem), ki mora biti na voljo tudi naročniku. Med izvedbo je pomembno, da se manager zna pravočasno vključiti v delo tima – ne prezgodaj in ne prepozno. Vedno lahko vpraša tim, če rabijo kakšno pomoč (in predlaga rešitev), ne pa, da jim govori, kaj in/ali kako morajo delati, da morajo pohiteti…
Ko je govora o vlogah v timu, moramo razlikovati funkcionalne
vloge, ki so vezane na delo, ki ga nekdo opravlja (programer, tesni inženir,
Scrum mojster, ipd.) in pa »timske« vloge, ki naj bi vplivale na delovanje
tima. Najbolj poznane so vloge po Belbinu, ki je leta 1981 po večletnih študijah
v svoji knjigi Management Teams: Why They Succeed or Fail pojasnil, da
naj bi imel uspešen tim pokritih devet timskih vlog (ki sicer niso enake
osebnostnim tipom ljudi s psihološkega vidika, a so povezane). Belbin predlaga
naslednje vloge: koordinator, sodelavec in iskalec virov; izvajalec, dovrševalec
(zaključevalec nalog) in tvorec; ter snovalec, strokovnjak in opazovalec/ocenjevalec.
Navedene vloge je razvrstil v tri skupine – prve tri so usmerjene v ljudi in
sodelovanje, druge tri v akcijo, zadnje tri pa v ustvarjalnost in iskanje rešitev
za morebitne težave.
Če verjamemo, da je vsak od nas »nosilec« ene ali dveh vlog, potem se najbrž tudi v samo-organiziranem timu vedno najde kakšen koordinator, ki skrbi za usklajeno delovanje tima. Seveda tim brez drugih vlog ne bo deloval optimalno. Najbrž pa se vsi strinjamo, da bi bilo koristno, če bi kadrovski oddelek z ustreznimi testi (in intervjuji) za vsakega zaposlenega ugotovil, kakšne timske vloge se skrivajo v njem, da bi bili potem timi bolj smiselno sestavljeni – velja tako za tradicionalne, kot agilne time. Razen, če ne verjamete v vloge in teste ter verjamete le v sposobnosti vodje tima?
Za konec predpostavimo, da so vloge v agilnih samo-organiziranih
timih drugačne. Žal smo pri iskanju vlog naleteli na težavo: večina virov
navaja funkcionalne vloge, ne pa timskih. No, našli smo raziskavo Rashine Hoda,
ki izpostavi šest vlog. Žal jih ne primerja z Belbinovimi, ampak prikaže drugačen
vidik – njene vloge bolj slonijo na vsebinskem delu in manj na osebnosti članov
tima. Ena vloga ima sicer isti naziv – koordinator, a ima drugo poslanstvo – v agilnih
timih skrbi za ustrezno komunikacijo z naročnikom in usklajuje predloge
sprememb. Žal Hoda tudi ni navedla ali se njene in Belbinove vloge izključujejo
ali se nadgrajujejo.
Poglejmo še ostalih pet vlog: mentor pomaga pri osvajanju agilnih metod in spodbuja redno upoštevanje pretekle prakse. Prevajalec poskrbi, da se naročnik in izvajalci razumejo – prevaja med poslovnim jezikom uporabnikov in tehničnim jezikom članov tima. Dve vlogi skrbita za uveljavljanje agilne miselnosti izven tima ter s tem zagotavljata podporo (samo-organiziranemu) timu: prvak (ang. champion) pri najvišjem vodstvu, promotor pri naročniku. Terminator prepoznava člane tima, ki ogrožajo produktivnost tima in kakovost rezultatov ter se dogovarja z nadrejenimi, da bi te člane zamenjali.
Hoda tudi predlaga, kdo naj bi prevzel določeno vlogo. Agilni
trener (ang. coach) naj bi bil mentor, prvak, promotor in terminator,
poslovni analitik pa koordinator in prevajalec. Zanimiva pa je ugotovitev, da vloge
mentorja, koordinatorja in prevajalca pri izkušenejših timih lahko prevzamejo
tudi sami razvijalci. Mentorstvo vsekakor omogoča večletna agilna praksa,
ostali dve pa razvijejo, ker v agilnem okolju veliko pogosteje sodelujejo z
naročnikom, kot pri tradicionalnem pristopu.
