ITÉlet

Egy érdekes beszélgetés a PMSZ rendezvényen

Egy érdekes beszélgetés a PMSZ rendezvényen

A minap részt vettem a PMSZ Szakmai teadélutánján, amelynek témája az Agilis PM gyakorlat volt.

A teadélután szakított a „hagyományos” felállással – ahol ugye az előadó/előadók tartanak egy prezentációt – hanem kiscsoportos foglalkozások és játékok keretében interaktívan dolgoztak a résztvevők.

Az egyik ilyen csoportról és beszélgetésről szeretnék most írni, ahol is a játékos feladat-végrehajtás kapcsán előkerült a priorizálás kérdése.

Tegyük fel, hogy az ügyfelünk egy csomó mindent szeretne kérni tőlünk. Az erőforrások száma azonban kötött, nem lehet mindent egyszerre csinálni, tehát valamilyen módon ütemezni kellene a feladatokat. Gyakorlatilag egy fontossági listát kellene készíteni, mit csinálunk meg ebben a hónapban, a következőben, mit csinálunk meg idén és jövőre.

A kedves Olvasóknak ez a téma ismerős lehet, hiszen már írtam a priorizálásról, illetve írtam a 0 értékű projektek kezeléséről.

Amikor az ember efféle ütemezési feladatba ütközik, akkor értelemszerűen megpróbálja üzleti érték szerint rendezni a munkát. Ugyanis szeretnénk, hogy az informatikai értéket termeljen, az ügyfél jól járjon és elégedett legyen.

Minden esetben, minden feladathoz meghatározható, hogy mennyi idő alatt, mekkora költséggel/erőforrással valósítható meg, és utána mekkora bevételt hoz – azaz mennyi lesz a megtérülés. Csinálni kell egy táblázatot, kiszámolgatni a megtérülést, sorba rendezni az elemeket, és nagyjából kész is.

Egy kicsit még persze játszani kell, hiszen a megtérülést pénzügyi évre kell vetíteni, kisebb elemeket ki lehet venni és átrakni, de a koncepció alapvetően adott.

De az élet nem ilyen egyszerű! Mondhatnánk azt is, hogy az élet nem olyan, mint ahogy egy Excel táblából látszik.

Az első probléma az üzleti érték meghatározása. Ugyebár nem mi, informatikusok döntjük el, hogy egy munka mennyit fog hozni a konyhára – ezt az üzleti terület szakértőjének, tehát magának a megrendelőnek kell tudnia. Teljesen rá vagyunk utalva.

A második probléma az, hogy minden tisztességes cégnél létezik VÍZIÓ, azaz hogy a cég körülbelül mit szeretne magával kezdeni, milyen területre, piaci szegmensre pozícionálja magát. Ez ellentmondásban lehet a megtérüléssel. Például szálloda építésnél lehet, hogy egy éjszakai bár jó pénzt hoz, de a szálloda alapvetően családbarátként határozza meg magát, abba pedig nem fér bele az éjszakai bár.

A harmadik dolog a kockázatok kezelése. Az Excel tábla csak azt mondja meg, hogy mennyi lesz a bevétel azt feltételezve, hogy minden a TERV SZERINT ALAKUL. De nem fog, minél nagyobb a projekt annál inkább nem fog. Meglehet, hogy egy magas hozamú munkát hátrébb kell sorolni, mert a magas hozam magas kockázattal társul – mi pedig szeretnénk, hogy az ügyfelünk BIZTOSAN jól járjon.

A negyedik dolog az, hogy bár az üzleti érték és megtérülés objektív dolog, de létezik belső céges politika és lobbi tevékenység. Pillanatnyi érdekek felülírhatják a tervet.
Például tegyük fel, hogy egy multi egész Európában értékesít. A feladatlistán szerepel két változáskérelem, az egyik Szlovákiából, a másik Franciaországból. A francia piac sokkal nagyobb, mint a szlovák, tehát hiába lenne a szlovák kérésnek nagyobb a megtérülése, de lehet, hogy a francia igény fog beelőzni.
Aztán előfordulhat, hogy a szlovák igény elnapolása miatt a multi nem tud teljesíteni bizonyos szlovák előírásokat, amik miatt a fogyasztóvédelem rászáll, és hirtelen az igény sokkal fontosabb lesz a multi számára, mint bármi más.

Látható, hogy ezek a prioritások időben folyamatosan változnak, és nem lehet objektív, egységes mérőszámot adni a végrehajtás ütemezésére.

A sorrend mindig is szubjektív véleményt fog tükrözni. Éppen ezért a mérőszámok és a megtérülés helyett fontos, hogy a sorrend megállapítása az ügyféltől, a megfelelő felhatalmazottól jöjjön. És itt bizony egyszemélyi döntésre, egyszemélyi felelősségre van szükség! A bizottságosdi nem fog működni, és az sem fog működni, hogy ugyanazon IT csapat egyszerre több ügyfél csoport igényei után szaladjon.
A helyes felépítés az, hogy a több ügyfél csoport meghatalmaz 1 darab valakit – mindegy hogy kit – és utána majd ezzel az 1 emberrel egyeztetik le a végrehajtandó feladatokat. Amikor pedig valaki közvetlenül megkeresi a fejlesztőket egy fejlesztési igénnyel, akkor át kell irányítani a meghatalmazotthoz.
(Megj: a meghatalmazott pozíciója hivatalosan „application owner” vagy alkalmazásgazda – az ő szava dönt az alkalmazást illetően)

Zárszóként még annyi: elindultunk egy objektív, világos problémától, és eljutottunk oda, hogy az informatika mennyire az egyes embereken, szubjektív véleményen és pillanatnyi politikai érdekeken múlik.