Projektvisszamérés – sikerkritérium vagy felesleges adminisztráció?

2023.04.12-én újra BA TALK meetupot tartottunk, ezúttal az Óbudai Egyetemen. Besnyő Réka segítségével a projektvisszamérés gyakorlatát jártuk körbe. Vajon ez áldás vagy átok?

Köszönöm Besnyő Rékának a szuper előadást, Csiszárik-Kocsir Ágnesnek pedig a meghívást és a szervezést.

A meetupról Vékony Nelli összefoglalóját olvashatjátok.

2023.04.12-én az Óbudai Egyetemen megrendezésre került a BATALK meetup legújabb eseménye. A találkozón fejlődni vágyó üzleti elemzők gyűltek össze, valamint az Óbudai Egyetem néhány nebulója is csatlakozott hozzánk.

Az esemény témája a projekt visszamérés volt, amely Besnyő Réka által került bemutatásra számunkra. Az előadás természetesen nem száraz tankönyvi jellegű volt, hanem megfűszerezte saját tapasztalataival, valamint egy konkrét szituáción keresztül mi is megnézhettük, hogy az adott esetben milyen szempontok alapján mértük volna a projektet. Személy szerint az esemény előtt kicsit szkeptikusan álltam a projekt visszaméréshez. Felesleges adminisztrációnak éreztem a korábbi tapasztalataim alapján, viszont ebben az új perspektívában már én is látom benne a lehetőséget és keresni is fogom az alkalmat, hogy használhassam őket és profitálhassak belőle a munkám során.

Az esemény elején előre rávilágítottak arra, hogy a projekt mérőszámok esetében nem az a lényeg, hogy minden mérőszámot oda-vissza bemagolva tudjunk (bár ez egy lehetetlen küldetés is egyben, mert elég szerteágazó, hogy mi az amit mérünk). Bőven elég számunkra, hogyha van egy általános rálátásunk a témára és egy adott helyzetben tudjuk azt, hogy milyen eszközöket tudunk használni.

Az alábbiakban az előadás főbb pontjait szeretném ismertetni egy úgymond gyors esszenciaként, hogy elővehető lehessen, amennyiben a későbbiekben gondolkoznánk, hogyan mérjük a projektünket egy hasznos útmutató lehessen. Vágjunk is bele!

Mi is a projekt?

A projekt egy átmeneti erőfeszítés, ami értéket teremt. Ezek egyedi termékeken, szolgáltatásokon és folyamatokon keresztül valósul meg. Egy projekthez hosszabb vagy rövidebb időre van szükség.

Az előadáson a projekt fogalma szűkítésre került, amely a későbbiekben a mérőszámok taglalásánál fontos lesz. A fogalom szűkítése során a következő feltételezéssel éltünk: A projekthez minden esetben tartozik egy szoftver, amelyen változást szeretnénk eszközölni.

Mi is a projekt visszamérés?

A projekt visszamérés a meghatározott mutatószámok mellett a projekt tevékenységek teljesítményének a monitorozása. A projekt visszamérése nem csak arról szól, hogy a végén összegezzük a mutatószámokat, hanem folyamatosan nyomon kell követnünk őket.

A mutatószámok kiválasztásánál lényeges, hogy teljeskörű képet kapjunk a projektről, és semmilyen kulcsfontosságú részletet ne hagyjunk figyelmen kívül. Ugyanakkor a projekt célját sosem szabad veszélyeztetni a visszamérési folyamat során. Az ideális mérőszámok olyan adatokat tartalmaznak, amelyek könnyen elérhetőek, és amelyek segítségével szükség esetén azonnal be tudunk avatkozni a folyamat menetébe.

A projekt visszaméréséhez szükséges meghatároznunk a mérendő mérőszámokat, ezek cél értékeit, hogy a méréseket mikor fogjuk elvégezni (ezek lehetnek mérföldkövek vagy meghatározott időszakok), valamint fontos ügyelnünk arra, hogy a méréseinket olyan formátumban prezentáljuk, amely a célközönségnek komfortos.

Mutatószámok

Ezek után pedig egy általános ismertetőt kaptunk a mutatószámokról. Milyen típusú mutatószámok léteznek és azokat mikor is érdemes mérni.

Pénzügyi mutatószámok

  • Költségek: Ha más területre nem tudunk hatást gyakorolni, akkor érdemes a közvetlen költségeket figyelni, azaz azokat a költségeket, amelyek direktben a projekt során merülnek fel, mint például a fejlesztők órabére vagy az elhasznált eszközök költsége.
  • Bevételek: Fontos, hogy csak akkor mérjük ezeket, ha ezekre tudunk hatást gyakorolni. Azonban ha a bevétel maga a projekt céljához kapcsolódik (például ha a változástól adott százalékban bevétel növekedést várunk), abban az esetben ezt mérni szükséges.
  • Eredmény: Az eredmények szempontjából a közvetlen eredmény jellemzően az üzemi eredmény, míg a közvetett eredmény a céges eredmény.A cégek az eredményt gyakran figyelik, mivel ez határozza meg, hogy a cég egy adott időszakot milyen eredménnyel zár.

Származtatott mutatószámok

  • NPV (Net Present Value): A jelenérték számolásának akkor van értelme, ha a projekt hosszabb távon hat (2-3-5 év).
  • ROA (Return on Assets): Arra mutat rá, hogy a cég az összes eszközén milyen megtérülést ér el egy adott évben. Az NPV és ROA közti különbség, hogy a ROA egy évre számol. A ROA arányszámot jelöl, míg az NPV összeget.
  • Az EVA (Economic Value Added) a gazdasági hozzáadott értékre utal. Az EVA kalkulációja különösen akkor hasznos, ha egy cég egy termékfejlesztésen dolgozik (pl. startup), és a befektetőknek van egy meghatározott kilépési pontja. Az EVA ilyenkor segít a cég értékének meghatározásában.

Teljesítmény jellegű mutatószámok

A teljesítmény a projekt alatti teljesítményre értendők. Ebben a felsorolásban már a projekt szűkebb értelmezése van jelen, amennyiben a projekt nem szoftver fejlesztési jellegű, abban az esetben ezen mutatószámok eltérőek lehetnek.

  • Elvégzett feladatok száma
  • Elvégzett sztoripontok száma
  • Becslés és tény összevetése
  • Backlog (a projekt végén mekkora munkamennyiség marad vissza)
  • Csoport elégedettsége (a legfeszítettebb időszakokban is érdemes arra figyelni, hogy a csoport elégedettsége jó legyen)
  • Egyszerre nyitva lévő feladatok száma (a túl sok nyitott feladat kiégéshez vezethet ezért érdemes mérni)
  • Burn down diagram
  • Hibák vs. új fejlesztések aránya (érdemes vizsgálni, hogy mennyit hibáztunk, valamint megvizsgálni azt is, hogy hol és miért hibáztunk)
  • Feladatok visszanyitásának száma
  • CR-ek száma

A vízesés modellben és az agilis módszertanban a mutató számok eltérhetnek, hogy mit érdemes mérni.

Projekt specifikus mérőszámok

Ezalatt olyan mutatószámokat értünk, amelyek a projekt céljára mutatnak. Ezeket már a projekt elején érdemes rögzíteni, ezáltal mindenki tudni fogja, hogy mihez kell igazodni. Ez már a projekt scope definiálásának egy módja. Egyes helyeken nem csak a projektnek határoznak meg mérőszámokat, hanem a változással érintett területeknek is.

A dolgok igazán akkor kerülnek bevésődésre egy embernél, amikor azt a gyakorlatban is alkalmazza, ezért a mérőszámok ismertetése után sort került egy közös munkára, amelyben egy esetet dolgoztunk fel. Az eset egy hiteligénylést és hitelkezelési folyamatokat támogató egyedi szoftverfejlesztésről szólt, amelyben Réka maga is részt vett. A közös munka során 3-as csoportokban kellett mérőszámokat meghatároznunk. A vizsgált projekt részletes bemutatását a meetup résztvevői megkapták.
A csoportoknak két szempont alapján két kérdést kellett megfontolni a rendelkezésre álló 20 percben:

  • Alkalmazható általános mutatók
  • A HITREG projekthez kapcsolódó kérdések és ezen kérdésekre mely mutatókkal lehet válaszolni

A 20 perc után az eredmények megbeszélésre kerültek közösen és a következő mutatók kerültek ajánlásra a csoportok által.

Mérhető általános mutatók a projekten:

  • Közvetlen költségek
  • Közvetlen eredmény
  • Becslés és tény összevetés
  • CR-ek száma
  • Babysitting időszak alatt megoldandó feladatok száma

A projekthez kapcsolódó mérhető mutatók:

  • Puffer méretének pontossága
  • Újratervezések száma
  • Hibák és igények aránya
  • Sprintbe tervezett feladatok teljesítése
  • Keretrendszeri fejlesztő bevonásának szükségessége
  • Pilot csoport elégedettsége
  • Tervezett el nem végzett feladat blokkolt-e további megvalósítást
  • Adatszolgáltatási kötelezettségek kiváltása
  • Backlog mérete
  • Visszanyitások száma

 

Ezután Réka prezentálta számunkra, hogy az adott projekten a projekt lefutásakor pontosan milyen mérőszámok voltak alkalmazva és azokkal milyen következtetéseket sikerült levonnia, valamint azt is, hogy a kitűzött célértéket sikerült-e elérniük.

A méréshez szükséges adatok kinyerése a JIRA adatbázisából, munkaidő nyilvántartásból és egyéb adatokból sikerült. Az egyéb adatok alatt az ünnepnap naptárak valamint az értendő, hogy az egyes munkavállalók, hány órás munkaidőben dolgoztak az adott időszakban.

Pénzügyi eredmények tekintetében a projekten bevételt lehetett számolni. A közvetlen költségek is számolva lettek, viszont a közvetett költségek nem kerültek visszaosztásra. Ezenkívül még a közvetlen eredménykerült előállításra.

Projekten mért sikerkritériumok:

  • Szabály rendszer integráltsága: A HITREG által elvárt adatkonzisztencia teljes mértékben megvalósult.
  • Meghatározott időn belül teljesüljön a strukturált gyűjtés: Tervezési csúszás miatt a fejlesztés is egy héttel csúszott, de a végén sikerült a legvégső határidőn belül maradni.
  • Az ügyletek rögzítési ideje ne növekedjen 30 másodperccel többel: Az ügyletek rögzítésén 15 másodperces növekedés volt mérhető, így a 30 másodperces cél teljesült.
  • Döntések átfutási ideje ne növekedjen: Ez a mutatószám az ügyletekkel kapcsolatos döntéseket foglalta magában, és bár a projekt csúszása miatt volt egy időszak, amikor az adatokat kézzel kellett bevinni (és ezen időszak alatt az átfutási idő növekedett), így ezt a célt nem sikerült maradéktalanul teljesíteni.

Általános mutatószámok:

  • Pénzügyi eredmények: A projekt pénzügyi szempontból sikeres volt, hiszen minden megtérült, így az eredményesség megfelelt a várakozásoknak.
  • Becslés megfelel a ténynek: A becsült értékek és a tényleges eredmények szinte teljesen megegyeztek a projekt során. Bár voltak átstrukturálások a szereplők között, de összességében a célt sikerült teljesíteni.
  • Backlog nem keletkezik: A backlogban keletkező elemek száma 14 volt, azonban ezek nem voltak blokkoló elemek a projekt haladásának szempontjából.
  • Sprintenként a feladatok elfogynak: Minden sprint végére sikerült befejezni az összes feladatot, habár az egyes sprintekben tapasztalt előrehaladás eltért az egyenletes eloszlástól.
  • A feladatok darabszámának megoszlása: A feladatok eloszlása során a hibák és igények aránya nem változott a fejlesztési ciklusban, tehát nem történt eltolódás a hibák arányában.
  • Visszanyitás aránya: A visszanyitási arány egy esetben tért el a meghatározott 50%-tól, de összeségében alatta maradt. Az újranyitások aránya mindig 20% alatt volt.
  • Feladatok nem lettek 1,5-nél (átlagosan) többször visszanyitva: A feladatok nem lettek 1,5-nél többször visszanyitva, ami azt jelenti, hogy összeségében teljesült. Ugyanakkor, az egyik fejlesztő esetében ez az érték magasabb volt.
  • Maximum 5 feladat van nyitva egy fejlesztőnél: Ez az elvárás több esetben nem teljesült. Bár a munka színvonalán nem látszódott a széttagozódás, de hosszú távon nem fenntartható a nagy számú nyitott feladat.
  • Átfutási idők kiegyensúlyozottak: Az átfutási idő a feladat elindításától a leadásáig tartott. Ezek a fejlesztők között nem voltak egyenlőek, 6-ból 2 fejlesztő esetén nem volt megfelelő az egyensúly.

Üzleti elemzők mérőszámai

Ezek után megvitattuk, hogy mely mérőszámok lennének alkalmasak az üzleti elemzők mérésére. Réka hozott pár mérőszámot és azokkal kapcsolatban beszélgettünk róla, hogy mi használnánk-e ezeket a számokat ilyen céllal:

A CR-ek száma mérheti az üzleti elemző munkáját, azonban nem szabad önmagában nézni őket. Fontos a tipizálás utáni vizsgálat, hogy ki melyikre tudott volna hatással lenni, valamint az igény félreértése vagy kevés kérdés esetén is több CR merülhet fel a végén. Amennyiben túl sok CR merül fel, az azt jelezheti, hogy valami elcsúszott a felmérés során.

A backlog mérete a projekt végén nem feltétlenül az üzleti elemző vagy a product owner (PO) felelőssége. A PO feladata az igények felvétele, de hogy ezekből mennyi valósul meg az ügyfél keretei vagy a pénzügyi keretek között, az már nem a BA vagy PO felelőssége. A HITREG projekt esetében ezek a visszamaradt backlog elemek között nagyrészt működést abszolút nem befolyásoló hibák voltak. A backlog mérete inkább az ügyfél kreativását mérheti és nem feltétlenül a BA teljesítményét tükrözi.

A probléma megoldása a projekttel pedig szintén nem biztos, hogy a BA számára egy jó mérőszám lehet. Ebben az esetben több különböző nézőpont is érkezett a résztvevők részéről. Egyrészt ez átfordításra került, hogy ez azt jelenti, hogy a cél megvalósult-e. Viszont ez csak abban az esetben teljesül, amennyiben a célhoz a probléma jól került illesztésre. A változást, maga a scope írja le és a BA-t leginkább azzal lehet mérni, hogy az adott scope megvalósult-e. Azt, hogy ez a scope megoldja-e az adott problémát sokan nem érezték a BA mérőszámának. A végén pedig még megemlítésre került, hogy a BA-t a transzparenciával lehet mérni, amely alatt az értendő, hogy világos volt-e maga a probléma és ebből a problémából mi került megvalósításra és mi nem.

Az előadás befejeztével áttekintettük a BA szerepét a visszamérés folyamatában. Mint üzleti elemzők, segítünk a KPI-k meghatározásában és a hozzájuk kapcsolódó követelmények facilitálásában, valamint a probléma és a cél definiálásában. Fontos, hogy minden érintett személy tisztában legyen ezekkel a mutatókkal. A mutatók nem csak a projekt sikerességét mutatják, hanem arról is tanulhatunk, hogy miként fejlődhetünk, ha a mutatók saját magunkra vonatkoztatva is megnézzük. A mérés során a cél fontosabb, mint az eszköz és csak a szükséges és elégséges mutatókat érdemes mérnünk.

Az előadás anyagát ITT éred el.

Köszönjük Vékony Nellinek a részletes összefoglalót. Bízom benne, hogy hamarosan találkozunk a következő meetupon. ?

Mennyire volt értékes, hasznos számodra ez a tartalom?

Mivel hasznosnak, értékesnek találtad...

Oszd meg bátran másokkal is! 🙂

Sajnálom, hogy ez a tartalom most nem nyerte el a tetszésed...

Köszönöm a visszajelzésed, a szavazatod rögzítettük!

Kérlek segítsd a munkámat, és pár mondatban írd meg mit hiányoltál vagy hogyan lenne számodra hasznosabb ez a tartalom?

A fejlődésedhez a következő tréningekkel tudlak hozzásegíteni:

Vékony Nelli

2023. június 14.

Szia! Vékony Petronella vagyok és üzleti elemzőként tevékenykedek. A célom az, hogy a közös munkával a csapatom és az ügyfelek számára értéket teremtsek és a sikereket közösen érjük el.

korábbi írások

címkék

ez megvan már neked?

Decomposition diagram

Decomposition diagram

Biztosan ismered, biztosan használtad már, hiszen a JPÉ gondolkodás egyik legegyszerűbb megjelenési formája. Mégis érdemes közösen átgondolni, mi mindenre lehet használni.

itt követhetsz

Ba Talk - Üzleti elemzés nem csak üzleti elemzőknek

Mária Gintl-Reszegi PMI-PBA

Üzleti elemzés tréner / Mentor / Professional Business Analyst / Insprl alapítója

osztani ér