Projektni management

Blog, debatni večeri, raziskave, knjiga…

Uspešnost (in učinkovita izvedba) IT projektov v Sloveniji

Najbrž ste opazili, da sem prispevke na tem blogu aktivneje objavljal le dve obdobji – v času pisanja obeh knjig. Z željo, da bi pomagal slovenskim projektnim timom k uspešnejši izvedbi projektov, sem vsebino knjig na blogu predstavil v strnjeni obliki – praktično je tretjina knjig prikazana tukaj, knjigi pa sta bogatejši za podrobnejšo razlago, moja razmišljana, predloge za prakso in primere iz prakse.

Pred časom pa sem prejel zanimivo vprašanje: »Ali imate morda kakšne novejše podatke glede uspešnosti IT projektov v Sloveniji?« Ker menim, da odgovor na to vprašanje zanima več ljudi, sem se odločil, da ga objavim tukaj na blogu. Odgovor sloni na moji raziskavi iz leta 2020, ko sem pripravljal knjigo »Agilno!?«. V raziskavi je sodelovalo 286 podjetij in drugih združb (tukaj je nekaj ključnih ugotovitev), med temi pa se je četrtina odgovorov nanašala na IT projekte.

Preden pa predstavim ugotovitve raziskave, pa naj še enkrat opozorim na razlikovanje pojmov učinkovito in uspešno (kar sem podrobneje razložil tukaj). Uspešen projekt naj bi bil tisti, pri katerem – finančno gledano – koristi, ki izhajajo iz rezultatov projekta (prihranki, prihodki), povrnejo investiran denar. Če pa govorimo o tem, ali je bil projekt zaključen pravočasno (in v proračunu), pa uporabljamo pojem učinkovite izvedbe. Seveda obstaja tudi vrsta nefinančnih sodil uspešnosti projektov, ki si jih tudi lahko ogledate v že omenjenem prispevku.

Dilema glede pojma »uspešnost« IT projektov pa ni prisotna le v Sloveniji, zato priporočam, da vedno, ko preberete, da je npr. “le 37% projektov uspešno zaključenih“, preverite, na osnovi katerih sodil so prišli do te ocene. Lahko, da je projekt zamudil za petino planiranega časa, a je prinesel zelo zadovoljive rezultate – torej je bil uspešen, kljub neučinkoviti izvedbi.  Razlikovanje obeh pojmov je pomembno tudi z vidika odgovornosti – manager projekta je predvsem odgovoren za učinkovito izvedbo, uspešnost pa je odvisna tudi od drugih deležnikov oz. dejavnikov.

No, po daljšem uvodu poglejmo, kako smo IT projekte izvajali v letu 2020. Kot sem omenil, je vzorec je vseboval 77 podjetij, katerih predstavnike sem pozval, naj navedejo povprečne vrednosti sodil za svoje projekte – stanja torej ne prikazujemo na osnovi 77 projektov, ampak na osnovi kakih 3500 (povprečje števila izpeljanih projektov na leto v obravnavanih podjetjih je skoraj 50). Naj povem še to, da je bilo govora o širokem naboru IT projektov (razvoj in uvajanje IT rešitev, razvoj aplikacij za osebne računalnike in pametne telefone, ERP sistemske rešitve, podpora obvladovanju dokumentacije, postavitev spletnih strani, ipd.).

Prva slika prikazuje odstotek projektov, ki so bili (po posameznih sodilih) izpeljani po planu, druga pa povprečno odstopanje projektov, ki niso bili izpeljani po planu. Naj še omenim, da je 27 (35%) sodelujočih navedlo, da projekte izvajajo ciklično (agilno), zato na slikah prikazujem tri podatke.

Seveda me je zanimala tudi uspešnost projektov. Ker sem raziskoval različne tipe projektov (ne le IT), žal nisem uporabil poglobljenega nabora sodil uspešnosti, ki jih predlaga Atkinson (to prepuščam drugim raziskovalcem). Zato prikazane ugotovitve mogoče niso ravno najbolj uporabne (majhen razpon ocen, med 2,3 in 2,8), vseeno pa lahko ugotovimo, da je pred nami še kar nekaj dela, da bi dosegli raven »vzorno«.

Ocena uspešnosti: 1 – manj zadovoljivo, 2 – zadovoljivo, 3 – dokaj zadovoljivo, 4 – vzorno

V nadaljevanju pa prikazujem še nekaj zanimivih ugotovitev glede dejavnikov, ki vplivajo na učinkovito izvedbo in uspešnost projektov. Če pogledamo (ne)sistematičnost uporabe metod projektnega dela, lahko rečemo, da je stanje dokaj zaskrbljujoče, hkrati pa to nekako pojasnjuje nizek odstotek učinkovito izpeljanih projektov. Gledano z bolj optimističnega vidika pa lahko rečemo, da dobro vemo, kje in kako se lahko izboljšamo 😊, kar je odlična osnova za začetek izboljševanja našega delovanja.

Pa še pojasnilo ocen v spodnjih slikah. Anketiranci so ocenili pogostost uporabe pristopov, metod in tehnik: 1 pomeni nikoli, 2 redko, 3 pogosto, 4 pa redno.

Agilno!?

Z velikim veseljem in radostjo naznanjam izid svoje druge knjige!

AGILNO!? Projekti, zaposleni, podjetja

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).

Če bi jo želeli dobiti še pred prazniki ali jo komu podariti kot novoletno darilo, vabljeni v spletno knjigarno Agencije Poti.

Do četrtka, 18.12., imate novoletni popust…

Projektna pisarna v agilnih organizacijah

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 😊.

Agilni strateški management in management portfelja (agilnih) projektov

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).

Dejavniki izbire (agilnega) strateškega managementa

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).

Agilna organizacija

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…

Pogodbena razmerja agilnih projektov 2

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. Capped Time & 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!

Pogodbena razmerja agilnih projektov 1

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).

Tradicionalna pogodbena razmerja

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:

Strošek naročnika = cena storitve = stroški izvajalca + provizija izvajalca

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.

Mednarodni virtualni (agilni) timi

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.

Komuniciranje v (agilnem) timu

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.

Page 1 of 12

Powered by WordPress & Theme by Anders Norén