Az egyik kedves kollégámmal, Verával volt múltkor egy beszélgetésünk, amiben feljött bennem egy pár érdekes gondolat. Projektek kezeléséről volt szó, és szóba került pár dolog, ami szerintem neked is hasznos lehet. Én elsősorban szoftverfejlesztési projektekből indulok ki, de nagyon sok minden, amit írok, teljesen általános, szóval remélem, ez a bejegyzés akkor is érdekes lehet, ha úgy érzed, semmi közöd az informatikához.

Mi is egy projekt? Én egy nagyon egyszerű definíciót használok, amit a GTD-ből vettem. Minden olyan dolog projekt, amit nem lehet egy lépésben végrehajtani. Nem kell itt semmi bonyolult dologra gondolni – ebben az értelemben még az is projektnek számít, hogyha akarsz sütni pár muffint. Egész rakás apróbb lépés kell hozzá, nem igaz? Meg kell keresned, hogy hova is tetted azt a frankó receptet amit találtál a múltkor; meg kell venni az alapanyagokat; össze kell állítani a tésztát; be kell melegíteni a sütőt; és így tovább. Tehát ez is egy projekt 😄

Minél bonyolultabb egy projekt, egyre kevésbé valószínű, hogy egyedül képes leszel végrehajtani azt. Továbbmegyek, sokszor még akkor sem érdemes egyedül végigvinni valamit, ha amúgy képes lennél rá. (Például azért, mert másoknak is fontos lenne, hogy gyakoroljanak, és ezért delegálni szeretnél nekik feladatokat. Vagy akár csak azért, mert egyedül végigvinni a dolgokat túlságosan megterhelő vagy unalmas lenne.) Azt te is pontosan tudod, hogy a mindennapos munkánkban egy csomó embertől, eszköztől, mások munkájától függünk. Egy projektnek a levezénylése sokszor főleg ezeknek a függőségeknek a kezeléséről szól.

A projekt, mint a bizonytalanságok hálózata

Amiről ebben a bejegyzésben főleg szerettem volna írni, azok a projektek közben fellépő bizonytalanságok. Amikor elindul egy projekt, mindig van egy csomó láthatatlan dolog: bizonytalanságok, rejtett feltételezések, meg olyan nehézségek, amiket még nem is ismersz. Veheted úgy is, hogy egy projekt végrehajtása arról szól, hogy ezeket a bizonytalanságokat szisztematikusan felderítjük, kezeljük és feloldjuk.

Hogyha kellett már bármilyen nagyobb projekten dolgoznod, pontosan tudod például, hogy az egyik alapvető lépés egy projekt elején az, hogy a nagy, nehéz, megfoghatatlan projektet kisebb, beláthatóbb, jól kezelhető feladatokra kell bontani. (Például: felújítani egy fürdőszobát akkora meló, hogy elsőre megtippelni se tudom, hány részfeladatból állhat. De azzal, hogy keresni kell egy burkolót, vagy találni kell egy ízléses járólapot, talán már tudnék kezdeni valamit.) Ezek a kisebb feladatok, mivel egymásra épülnek, egy hálózatot alkotnak, a bennük rejlő bizonytalanságokkal együtt - innen a címe a bejegyzésnek.

A bizonyossági szint

Minden egyes feladatnak megvan a maga bizonyossági szintje – az, hogy mennyire érzed azt, hogy meg tudjátok majd oldani. Valami olyan feladatról van szó, amit becsukott szemmel is meg tudnál csinálni? Akkor ez nyilván magas lesz, mondjuk 90%. Olyan esetben viszont, amikor még soha korábban nem csináltál hasonlót, és azt se tudod, hogyan kezdj hozzá, ez sokkal alacsonyabb lesz, akár valahol a nulla közelében. (Remélem azért, hogy nem nulla, mert az azt jelentené, hogy el sem tudod képzelni, hogy bárhogyan véghez tudd vinni a feladatot!) A most következő gondolat most egy kicsit elvontnak tűnhet, de várd ki a végét légyszi… 😄 Azt gondolom, hogy addig, ameddig egy feladat nincsen kész, a hozzá tartozó bizonyossági szint sosem érheti el a 100%-ot. Hogy miért? Azért, mert mindig közbejöhet valami váratlan. Lehet valami annyira egyszerű, mint főzni magadnak egy csésze teát, de ha hirtelen bejön egy áramszünet, máris nem tudod használni a vízforralót, és hirtelen bonyolultabbá változnak a dolgok… Szóval, ha innen nézed, 100%-os bizonyosságot csak akkor nyerhetünk, ha már kész van a feladat.

Amikor dolgozol egy feladaton, a bizonyossági szint folyamatosan változik valamilyen irányba. Lehet például, hogy belefutsz egy váratlan nehézségbe, ami lecsökkenti, de az is lehet, hogy rájössz, hogy igazából egyszerűbb a feladat mint vártad, és megnő. Nyilván azt szeretjük, ha ez a mutató folyamatosan növekszik. 😎

Rejtőzködő feltételezések

Írtam korábban a projektek mélyén rejtőző feltételezésekről is. Van egy csomó módszer ilyen jól hangzó nevekkel, mint a prototípusozás, proof-of-concept készítés, minimum viable product építés stb. Ezek igazából mind arról szólnak, hogy egy konkrét módot adjanak arra, hogy hatékonyan kiismerjük és megerősítsük a feltételezéseinket anélkül, hogy túl sokat kellene feleslegesen dolgozni. Azért foglalkoznak ezzel ennyit az emberek, mert az, hogy egy projekt közben tisztába kerülj a háttérben rejtőző feltételezésekkel, kritikusan fontos, és eldöntheti, hogy sikerrel jársz-e majd. A hétköznapi életben például feltétezések egész garmadáját hordozzuk a fejünkben anélkül, hogy bármikor gondolkodnánk róluk. Aztán amikor ezek elkezdenek megdőlni, ezt nagyon sokszor tragédiaként éljük meg, és ilyenkor könnyen előfordulhat, hogy egy csomó mindent újra kell tervezni. (Feltételezzük például, hogy akármikor lehetőségünk van arra, hogy kimenjünk a lakásból sétálni egyet. Aztán hirtelen jön egy COVID, és megtanuljuk, hogy ez korántsem annyira egyértelmű…)

Igazából az én munkám a Preziben a csapataimmal mondhatni semmi másról sem szól, csak ezekről a feltételezésekről.

• Gyártunk egy rakás feltétezést arról, hogy hogyan mehetne jobban az üzlet,
• megkeressük, hogy hogyan lehetne megnézni, hogy igazak-e ezek,
• megpróbáljuk lefejleszteni a legegyszerűbb megoldást, ami még elegendő arra, hogy teszteljük az elképzelést,
• kimérjük, hogy teljesültek-e a feltétezések,
• a végén pedig végiggondoljuk, hogy mit is sikerült tanulni ebből.

Majd kezdődik az egész előről.

Mikor vagyunk kész? Kell, hogy legyen egy ellenőrzési terv

Amikor ezekről a bizonytalanságokról meg feltételezésekről beszélünk, femerül egy nagyon fontos kérdés. Mégis honnan fogjuk tudni egyáltalán, hogy készen vagyunk? Mit jelent az, hogy valami ténylegesen kész? Rengeteg félreértés adódhat ebből, ha csapatmunkában, neadjisten alvállalkozókkal kell dolgoznod. Sok helyen használunk erre egy bevett gyakorlatot: írunk egy definíciót a csapattal, hogy mikor fogadunk el késznek egy munkadarabot. Ennek egy egészen természetes része az, hogy… amúgy működik, amit csináltunk? Ahhoz, hogy ezt tudjuk, tesztelni kell. Ahhoz pedig, hogy tudjunk tesztelni, kell egy tesztelési terv: ilyenekre gondolok, mint hogy milyen lépéseket kell végrehajtani a munka ellenőrzéséhez, és hogy ki fogja ezeket az ellenőrzéseket elvégezni. Ez a legegyszerűbb formájában egy egyszerű ellenőrzőlista is lehet. A lényeg, hogy konkrét és jól érthető legyen. Nekem és a csapatomnak rengeteget segít az, hogy megpróbáljuk ezeket a tesztelési terveket minél hamarabb kialakítani. Ha tudod, mire kell ügyelni, a munka elvégzése közben is tudod magadat ellenőrizni, és így el lehet kerülni azt, hogy többször kelljen a nulláról újrakezdeni lépéseket. Márpedig az, hogyha nulláról kell újrakezdeni, a világ egyik legbosszantóbb dolga, úgyhogy magad miatt is érdemes erre figyelni 😆

Ha nincs tervetek arra, hogy hogyan fogjátok ellenőrizni a munkát, szinte biztosra veheted, hogy valahol félre fognak csúszni dolgok. Hogy miért? Azért, mert ennek az ellenőrzési tervnek a hiánya azt is jelenti, hogy rengeteg mindent nem tisztáztatok egymás között – nincsenek meg a megállapodások a résztvevők között, és így a felelősségi körök sincsenek elég jól tisztázva. Ez bármikor káoszhoz vezethet. (A fenti gondolat egyébként annak az általánosabb elvemnek egy változata, ami valahogy így néz ki: hogyha nem tudod, hogy jól mennek a dolgok, feltételezned kell, hogy nem mennek jól! Úgy is mondhatnám, hogy ez a “ne hitegesd magad”-elv).

Amúgy ha egy feladattal kapcsolatban a bizonytalanság annyira magas, hogy még a pontos tesztelési lépések meghatározása sem megy, az egy nagyon erős jel arra, hogy valójában fogalmunk sincs arról hogy mekkora feladattal van dolgunk. Ezen a ponton becslésekről még beszélni se nagyon érdemes, mert valószínűleg nem ismerjük az összes lehetséges kockázatot, amit a projekt közben kezelni kell majd.

Nyilván nem azt akarom mondani amúgy, hogy mindig a te feladatod kéne hogy legyen az, hogy mindig mindent ellenőrizz. (Ha ezt akarnád csinálni, elég gyorsan beleesnél a mikromenedzselés csapdájába, ami miatt előbb-utóbb mindenkivel utálni fogjátok egymást. 😂 ) Egy projekt vezetőjeként az viszont a te feladatod, hogy minden feladatra megtaláld a megfelelő embereket, akiknek igenis le kellene ellenőrizniük az összes dolgot neked, amire szükség van ahhoz, hogy sikerrel járjatok. Ha ezeket a bizonytalanságokat és feltételezéseket, amikről írtam, a kezedben tudod tartani, biztos vagyok benne, hogy könnyebb dolgotok lesz.