Pavel Harikov az ukrán Kyivstar (a VEON Group tagja, ami világ 13. legnagyobb mobilszolgáltatója) projektmenedzsment-részlegének vezetője, és több mint 10 éves tapasztalattal rendelkezik nemzetközi vállalatok projekt- és portfóliókezelésében. Az eddigi pályafutása során olyan nagyszabású projekteket valósított meg, amelyek értéke a 150 millió dollárt is elérte. Pavel a hatékony agilis projektmenedzsmentről fejtette ki a gondolatait a LABA számára készített írásában.
Miben különböznek az agilis projektek a konzervatív projektektől?
Nézzük meg a különbségeket négy komponens segítségével: üzleti érték, kockázat, átláthatóság és alkalmazkodóképesség.
#1. Üzleti érték
A projektmenedzsment klasszikus megközelítésében a termék üzleti értéke a legvégén nyilvánul meg - ráadásul hatalmas erőfeszítés és egy jó adag szerencse eredményeként. Agilis megközelítéssel viszont az üzleti érték minden egyes új változatban realizálódik.
Hogyan történik ez? Egy klasszikus projektben sok erőforrást használsz fel, de ennek csak sokára lesz eredménye. Vagyis a megrendelő pénzt fektet be, hogy csak a végén tegyen szert haszonra. Az agilis megközelítés ehhez képest rendszeres többletértéket biztosít, vagyis azonnal létrehozol a vállalkozás szempontjából hasznos dolgokat.
#2. Kockázat
Mivel a klasszikus megközelítésben az eredményt a projekt végén kapod meg, végig jelen lesz a bizonytalanság érzése, hogy a felhasználók hogyan fogadják majd a termékedet. Ez magas kockázatot jelent.
Az agilis megközelítésben az összes kockázati tényezőt a megvalósítás során dolgozod ki, visszajelzést kapva a felhasználótól. Alapvetően minden egyes iterációnál lehetőséged van egy kicsit változtatni az irányt, hogy elkerüld a kockázatokat. Ezért a kockázatok itt meglehetősen alacsony szinten vannak.
A legnagyobb kockázat minden projekt megvalósítása során abban rejlik, amikor a megrendelő nem találja el az irányt, és olyan terméket hoz létre, amelyre senkinek nincs szüksége. Ez elkerülhető az agilis módszertannal, mert már a projekt korai szakaszában megmutatod a vállalkozásnak, hogy mit hozol létre, és alkalmazkodsz a visszajelzésekhez.
Kapcsolódó kurzusok:
#3. Átláthatóság
Az átláthatóság a projekt előrehaladtával növekszik. Kezdetben minden olyan, mintha ködben lenne – érthetetlen célok, nem tudni pontosan, kivel és kinek dolgozol. De a projekt előrehaladtával fokozatosan nő az átláthatóság.
Az agilis megközelítésekben ez egyszerűbb – itt kis sprintekben haladsz, és csak a legközelebbi távlatokat dolgozod ki részletesen.
#4. Alkalmazkodóképesség
Agilis megközelítéssel az egész projekt során itt-ott változtathatsz a dolgok menetén külső vagy piaci körülményekhez alkalmazkodva.
A klasszikus változatban erre csak az elején van lehetőséged – amikor megtervezed a projektet. Ezt követően, amikor már mindent lefixáltál, határozottan a terv szerint fogsz haladni. Ezért ebben az esetben az alkalmazkodóképesség alacsony szintű.
Még egy fontos különbség
Minden projektet a korlátok háromszöge jellemez – ezek a költségvetés, az ütemterv és a tartalom.
A klasszikus projektmenedzsment ütemterven és költségvetésen alapul – szükség esetén ezek módosíthatóak. Például, ha fontos, hogy az ütemterv szerint végezz, akkor megnöveled a költségvetést, és mindent megteszel azért, hogy ez összejöjjön. Ha fontosabb a költségvetés betartása, akkor meg tudod hosszabbítani az ütemtervet. A projekt tartalma itt rögzített, nem változik.
Az agilis megközelítésben ez a háromszög fordított. Itt az ütemterv és a költségvetés általában állandó marad: van egy végső dátum, ameddig a projektnek le kell zárulnia, és megvan a pénzösszeg, amelybe bele kell férni.
Ugyanakkor a tartalom nincs fixálva, és mindig készen állunk rá, hogy változtassunk valamin, hogy végeredményben a lehető legértékesebb terméket kapjuk.
Hogyan tervezzünk az agilis projektekben?
Úgy tűnhet, hogy az agilis projektekből hiányzik a tervezés. Ez azonban nem így van – egyszerűen másképp zajlik.
Az agilis projektekben a tervezés folyamatosan történik – minden egyes iterációhoz. A projektet kis szakaszokra bontjuk, és átgondoljuk mindegyik megvalósítását. Ebben a megközelítésben a projektmenedzsernek több munkája van – folyamatosan a pulzuson kell tartania az ujját, és módosítani a terveket, ha szükséges.
A legfontosabb itt a prioritások meghatározása. Elsősorban a lehető legértékesebb terméket próbálod meg létrehozni az ügyfél számára, ezután fokozatosan új funkciókat adsz hozzá.
Ez biztosítja, hogy a megrendelő a maximális megtérülést kapja minden elköltött erőforrás után, és azonnal használhassa a létrehozott terméket.
MVP koncepció
Az MVP jelentése: minimálisan életképes termék (Minimum Viable Product). Nem tökéletes, de elegendő az ügyfél alapvető igényeinek kielégítésére.
Az MVP-t a legjobban a következő kép illusztrálja:
Ezen két megközelítést látunk az autóépítéshez.
Az első megközelítésben fokozatosan hozzuk létre a terméket, amely kizárólag az utolsó szakaszban jelent értéket, az azt megelőzőkben nem.
A második megközelítés szerint minden egyes szakaszban értéket hozol létre a felhasználó számára. Kezdetben az egy gördeszka, majd egy roller, bicikli, motorkerékpár és végül egy autó. Igen, az ügyfél nem azonnal kapja meg, amit akart. De azonnal olyan terméket kap, amivel az alapvető szükségleteit ki tudja elégíteni.
Képzeld el, hogy éttermet szeretnél nyitni. Milyen alapvető funkciókat kell megvalósítani hozzá? Rendelés fogadása, főzés, fizetés és kiszállítás.
Valószínűleg ezeket a területeket már a legapróbb részletekig átgondoltad – az online rendelés lehetősége, a bőséges ételkínálat és a különböző fizetési módok. Először azonban úgy kell ezt megvalósítanod, hogy minden a minimálisan elegendő szinten működjön, és elegendő visszajelzést gyűjthess az ügyfelektől. Ezután fokozatosan hozzáadhatsz új funkciókat, és a megfelelő irányba fejlődhetsz.
Hogyan dolgozz a Scrum rendszer szerint?
Az agilis projektmenedzsment egyik legismertebb keretrendszere a Scrum. Olyan szabályokat ír le, amelyek szerint a hatékony csapatok működnek. A Scrum három alappillére az átláthatóság, az ellenőrzés és az alkalmazkodás.
Átláthatóság. A folyamat fontos szempontjai mindazok számára elérhetőek, akik befolyással vannak a végeredményre. Van egy egységes szabvány, amely érthetővé teszi, hogyan mennek a dolgok, és hogy ki miért felelős. Mindenki egyformán érti a munka felépítését.
Ellenőrzés. Tanulmányozni kell a haladást minden egyes sprintcél felé, és be kell tudni azonosítani a nem kívánt eltéréseket. Az ellenőrzésnek azonban nem szabad túl gyakorinak lennie, hogy ne zavarja a munkát.
Alkalmazkodás. Ha jelen vannak olyan problémák, amelyek lassítják a munkát, akkor valamin változtatni kell. Fontos ezt a lehető leghamarabb megtenni az eltérések minimalizálása érdekében.
A Scrum fő szabálya a 3-5-3: három szerep, öt esemény és három artifaktum.
A három szerepkör a scrum master, a product owner és a fejlesztői csapat. Az agilis megközelítéseknek nincs projektmenedzsere, de a funkcióik meg vannak osztva a scrum master és a product owner között.
A scrum master azért felel, hogy a csapat betartsa a Scrum szabályait. Ismeri az összes eseményt, és biztosítja a csapat megfelelő munkáját. Ellenőrzi a folyamatokat, hogy a feladatok időben és kellő minőségben történjenek, és nem engedi, hogy az érintettek megszegjék a megállapított szabályokat.
A product owner a termékért felel. Tanulmányozza a piacot, érti, hogyan lehet növelni a keresletet egy termék iránt, és folyamatosan fejleszti azt.
Vagyis a scrum master felel a csapatért, biztosítva a hatékony munkát, a product owner pedig a teendőkért és azok priorizálásáért felel, és feladatokat állapít meg a csapat számára.
A harmadik szerep a fejlesztői csapat. Itt különböző szakemberek lehetnek – attól függően, hogy milyen terméket hozol létre. Ideális esetben ez a csapat 7-9 főből áll.
Az öt esemény: sprint, tervezés, napi scrum (daily stand-up), demó és retrospektív.
A product owner a „kívánságlistájával” érkezik a csapathoz, és közösen megtervezik, hogyan tudják megvalósítani őket. A teljes munka több sprintre oszlik, amelyek mindegyike 1-4 hétig tart.
A tervezés után a csapat munkához lát. Minden reggel egy scrum master vezetésével mindenki egy napi scrumra gyűlik össze. Megnézik a Kanban táblát, és eldöntik, hogy milyen feladatokkal fognak foglalkozni. A napi scrum nem tarthat tovább 15 percnél.
Amikor az első sprint véget ér, egy demóra kerül sor. Ezen részt vesz a megrendelő, és minden érdekelt fél. Megnézik, hogy mit hozott össze a csapat ez idő alatt, és visszajelzést adnak. A product owner meghallgatja a visszajelzéseket, és módosítja a teendők listáját.
Az események fontos része a sprint retrospektív. Ez egy olyan találkozó, amelyet a scrum master vezet, hogy közösen megvitassák, mi volt jó és rossz az elmúlt sprintben. A scrum master rögzíti a hiányosságokat, hogy legközelebb még hatékonyabbá tegye a munkát.
A három Scrum-artifaktum a következő:
- termék backlog (egy végtelen teendőlista a tennivalókról),
- sprint backlog (egy egyértelmű lista a csapat által kiválasztott feladatokról) és
- increment (kivitelezett érték, növekedés. Ez az a termék, amelyet a demóban mutattunk meg az ügyfélnek).
A feladatok értékelése a Scrumban
Kézenfekvő lenne a feladatokat az idő alapján értékelni, amit a csapat a megoldásukra fordít, ezt azonban nem így szokás. A leggyakrabban a feladatokat story pointokban értékelik – annak függvényében, hogy milyen munkamennyiséget vállalt be a csapat.
Használhatod a mindenki számára egyértelmű jellemzőket – S, M, L – kis, közepes és nagy feladat. Így a csapat érteni fogja, hogy egy kéthetes sprint alatt például 20 kis feladatot vagy 10 kicsit és 4 közepeset tudnak teljesíteni.
Hogyan mérjük a csapat sebességét?
Készíthetsz grafikont, amelyen nyomon követheted, hogy a csapat hány story pointot ért el egy iteráció (sprint) során. Például így:
A scrum master feladata, hogy úgy szervezze a csapatmunkát, hogy a munka sebessége nőjön, vagy elérjen egy bizonyos szintet, és utána ne csökkenjen.
A csapat teljesítménye egy úgynevezett burndown diagramon keresztül is bemutatható. Például azt gondoltad, hogy egy sprintben a munka mennyisége 120 story pointot vesz igénybe, és ezt hét nap alatt csinálod meg.
De a valóságban minden másképp alakulhat. Az első nap nem 20 story pointot „égetsz el”, ahogy tervezted, hanem csak 12-t. Ezután utol kell érni magad, és ki kell deríteni, hogy miért csökkent a hatékonyság. Így látod, hogyan dolgoztok a tervhez képest.
Az agilitásban az a lényeg, hogy a forma ne érvényesüljön a lényeg felett. Ez csak akkor működik, ha az egész szervezet osztja az Agilis Kiáltványban lefektetett elveket:
#1. Az egyének és a személyes kommunikáció fontosabbak, mint a módszertanok és az eszközök.
#2. A működő termék fontosabb, mint az átfogó dokumentáció.
#3. Az ügyféllel történő együttműködés fontosabb, mint a szerződéses egyeztetés.
#4. A változás iránti készség fontosabb, mint az eredeti terv szolgai követése.
