Hogyan kell jól és hatékonyan priorizálni, feladatlistákat szervezni?

Hogyan kell jól és hatékonyan priorizálni, feladatlistákat szervezni?

Informatikai projektekben mindig van valamilyen feladatlista. A szoftverben hibákat találunk, amiket ki kell javítani – ezek egy hibalistán, jó esetben egy hibakövető rendszerben (pl. Bugzilla) jelennek meg.

Másrészt pedig ahogy a projekt halad előre, úgy érkeznek az ügyfél részéről újabb és újabb ötletek (a kezdeti elképzeléshez képest), amiket meg kellene valósítani. Különösen amikor a szoftver első verziója/prototípusa elérhető, akkor nyílik ki az ötletláda. Ezek az ötletek változtatások, amiket valamilyen módon követni kell.

Hibák vagy változtatások, de lesz egy csomó feladat. Ötletelni könnyű, megvalósítani sokkal nehezebb, na meg a keretek (pénzügyi+időbeni) is korlátozottak, ezért a feladatok biztosan messze túlszárnyalják a kapacitásokat.

Ezért a feladatokat össze kell gyűjteni egy helyre (egy dokumentumba vagy egy hibakövető rendszerbe), ott sorba rendezni fontosság alapján, és a csapat majd nekiáll azokat megvalósítani felülről lefelé.

Ez a rendezés az, amit priorizálásnak hívok, és ami nagyon-nagyon fontos a projekt sikerének szempontjából.

Miért ennyire fontos? Mert ahogy írtam, az erőforrásaink végesek, és ezért jól kell őket használni, hogy minél rövidebb idő alatt minél nagyobb értéket teremtsenek. „Érték” alatt üzleti értéket értek, tehát ami az ügyfél számára hasznos vagy annak ítél.

Sajnos ezt lehet rosszul is csinálni. Előfordulhat, hogy a csapat ugyan dolgozik, de nem azon, ami az ügyfél számára fontos. Esetleg az ügyfél úgy érzi, hogy a kérései nem találtak nyitott fülekre, és elveszíti a bizalmát a projekt és a csapat iránt. Mindez ugyanannyira végzetes lehet, mintha a csapat egyáltalán nem is csinálni semmit.

Szóval fontos, hogy a feladatlista kezelése jól menjen. Ehhez összeszedem – teljesség igénye nélkül – a típushibákat, és adok tippet azok helyes kezelésére.

Az ügyfél úgy érzi, hogy a csapat nem azon dolgozik, ami neki kell: Feltehetőleg az áll a háttérben, hogy nem létezik közös feladatlista, vagy legalábbis az ügyfél és a beszállító nem azonos listát használ. Ezért meg kell állapodni abban, hogy legyen egy közös lista, amire az ügyfél felveheti az igényeit, és a beszállító majd ezek alapján dolgozik. Fontos, hogy ehhez a listához mindkét fél állandóan hozzáférjen, és időről időre frissítsék (pl az ügyfél új kéréseket rakhat rá).

Megjegyzem, hogy projekt menedzsment területen „hivatalból” léteznek ilyen listák: change log és issue log.

Az ügyfél nem látja, mi történik: Gyenge a beszállító->ügyfél kommunikáció. Ezért célszerű rendszeresen (pl hetente) áttekinteni a listát, és arra a beszállító adjon helyzetjelentést: mi a helyzet az egyes feladatokkal, mi a tervezett határidő.

Az ügyfél nem bízik benne, hogy a kérései el fognak készülni: Itt pusztán bizalomról van szó. Ha az ügyfél nem bízik a beszállítóban, akkor arra a beszállító feltehetőleg okot adott. A bizalmat úgy lehet visszaszerezni, ha a vállalt teljesítés időben megtörténik. Ha az ügyfél látja az eredményeket és a folyamat halad, akkor bízni fog benne.

Túl sok a munka: Alapvetően az normális, hogy több a feladat, mint amit egy adott pillanatban meg lehet csinálni. Ezért a feladatokat sorba kell rendezni. A beszállító a sorrendnek megfelelően dolgozzon a feladatokon. A sorrendet csakis és kizárólag az ügyfél döntse el üzleti alapon.

Ütköző prioritások: Biztosan mindenki belekerült abba a 22-es csapdába, hogy egyszerre 2 darab 1-es prioritású ügye érkezett „dobjatok el minden más munkát” utasítással. Ebből csakis rosszul lehet kijönni – a kettő közül valamelyik nem készül el. Ezért ragaszkodni kell hozzá, hogy minden prioritás legyen a listán, a sorrend legye szigorú (tehát csak 1 darab 1-es van, 1 darab 2-es, stb), és nincsenek 0-s prioritások vagy egyéb feladatok.

Több különböző ügyfél: Klasszikus hiba, hogy a projekt több szervezeti egység számára is fontos, ezért a projektnek több ügyfele van. Ezek a szervezeti egységek egymástól függetlenül saját kéréseket fogalmaznak meg, ezeket saját maguknak priorizálják. Tehát egyszerre több 1-es prioritású feladat lesz. Ezt úgy lehet megoldani, hogy meg kell állapodni az összes féllel: a listán sorrendet beállítani csak 1 azaz egy személynek van joga, erre ki kell jelölni valakit az ügyfél oldalon. És majd ez a személy koordinál a szervezeti egységek között. Pont, mint ahogy a projektnek 1 megrendelője és 1 szponzora van.

Túl hosszú lista: Mint írtam, a kérések/hibák száma biztos sok lesz, több mint amennyi ember. Tipikusan az ilyen listák nyúlnak, mint a rétestészta, és kezelhetetlen hosszúságúvá válnak. Felesleges egy hosszú listát hétről hétre áttekinteni, hogy a felső néhány kivételével a többi állapota hétről hétre ugyanaz. Ezért a listát valahol vágni kell. Meg kell állapodni, hogy a lista maximum hány elemű (tipikusan 10, 20 vagy 30, mérettől függően). Ami nem fontos, az legyen alacsony prioritású és rakjuk félre.

Túl sok magas prioritás: Az ügyfél azt látja, hogy ami kiemelt fontosságú ügy, arra a beszállító rámozdul, ezért egy idő után minden magas prioritású lesz. Ennek nincs értelme, hiszen a csapat hétről hétre csak adott mennyiségű munkát tud elvégezni. A prioritásnak pont az a lényege, hogy megmutassa, mivel kell először foglalkozni és mivel később. Ha minden magas prioritású, akkor a prioritás elveszíti értelmét, és ennyi erővel lehet minden normál prioritású is.

Aki hangosabban kiabál, annak az ügye halad: Ha van egy priorizált feladatlistánk, akkor előfordulhat, hogy egyes emberek „megkeresnek” bennünket, és szívességet kérnek, hogy az ő ügyük – ami egyébként nincs a lista élén – az is haladjon. Vannak, akik kevésbé szívélyesen fognak megkérni: kiabálnak és követelőznek, hogy márpedig az ő kérésük mindenképpen haladjon mert baj lesz. Ezeket megelőzendő, meg kell állapodni, hogy a sorrendet ki hagyja jóvá. Nem csak az fontos, hogy az egyetlen személy kezelje az ügyfél oldalon, hanem azt a megfelelő szinten jóvá is hagyják. Ezután ha valakinek baja van a sorrenddel, menjen a jóváhagyóhoz panaszkodni. Aki kiabál és fenyegetőzik, azt el kell küldeni.

Megjegyzem, hogy ha az látják, hogy a hangosan kiabáló menedzser eléri célját (mert az illető a cég egyik „erős embere”), akkor utána mindenki kiabálni fog – és egyre hangosabban.

Nem látszik az eredményesség: Könnyen előfordulhat, hogy miközben a fejlesztők majd megszakadnak a munkában és zárják le a fejlesztési kéréseket, addig az ügyfél úgy látja, hogy semmi sem halad. Ezért szigorúan vezetni kell, melyik kérés mikor készült erről, ezt a listával együtt vagy vele párhuzamosan vezetni és ledokumentálni. A teljesített kéréseket is ugyanúgy jelenteni kell, tényszerűen megmutatni azt a sebességet, ahogyan a projekt vagy a csapat halad. És itt megemlíteném a release note fontosságát, ami tartalmazza az adott csomagban átadott új funkciókat vagy kijavított hibákat. Ha a lezárt kéréseket jól dokumentáltuk, akkor az ilyen vádakat vagy félreértéseket könnyedén megoldhatjuk.

Nem az 1-es prioritású feladat készül el elsőnek: Az ügyfél azt látja, hogy adott egy fontossági lista, ahol elkészül a 2-es és 3-as feladat, de az 1-es nem. El kell neki magyarázni, hogy ez normális. Az egyes feladatok nem azonos nehézségűek. A csapat nagy, ezért egyszerre több ember több feladaton dolgozik, és meglehet, hogy egy alacsonyabb prioritású hamarabb készül el. A prioritás nem arra garancia, hogy milyen sorrendben fognak elkészülni, hanem arra, hogy milyen sorrendben kezdünk el rajta dolgozni, milyen figyelmet kap a feladat. Ezen felül előfordulhat, hogy az egyes feladatok összevonhatók vagy egymástól függenek, esetleg adódik egy logikus megvalósítási sorrend. Ezt minden ügyfél meg szokta érteni, hiszen nem az a fontos, hogy az 1-es készüljön el elsőre, hanem az, hogy a munka minél gyorsabban haladjon.

A tanácsokon felül két fontos kérdéssel foglalkoznék még. Ezek egyike a hibajegyek priorizálása. A hibákat hibaosztályokba szoktuk sorolni (általában 5), tehát nem 10-es listákkal dolgozunk. Előfordulhat, hogy rossz minőségű a szoftver, és ezért sok a magas prioritású (blokkoló vagy szoftverösszeomlást okozó) hiba. A sok magas prioritású hibán aztán jól össze tud veszni a megrendelő és a beszállító. Ezt megelőzendő, a hibák osztályozását előre rögzíteni kell. Ez a meghatározás legyen objektív és világos.

A másik fontos kérdés az, hogy mikor leszünk kész, jól haladunk-e? A menedzserek nagyon szeretnek nézegetni egy hibalistát vagy feladatlistát, majd olyan következtetéseket levonni, hogy a projekt katasztrofálisan halad.

Pedig az az igazság, hogy a hibák száma vagy az aktuális feladatlista nem fogja megmondani, hogyan áll a projekt. Nem fog kiderülni, hogy jó haladunk-e, és az sem, hogy mikor leszünk kész. Ezek a listák aktuális állapotokat jelentenek, de azt nem mondják meg, hogy az egészhez képest (a leszállítandókat tekintve) hol állunk. Nem mindegy, hogy tesztelés előtt vagy hibajavítás után nézzük meg a listát.

Az igazat megvallva a szoftver állapotát a teszteléssel mérném (hány use case tud lefutni), illetve azzal, hogy az üzleti célokat milyen mértékben elégíti ki. Vannak területek, ahol inkább gyorsan akarnak egy működő szoftvert, az sem baj, ha hibákat tartalmaz. Mások számára viszont a stabilitás és a hibamentesség fontos. Minden relatív.