Szerző: Behán László | Olvasási idő: 7 perc
Amikor egy nagyvállalat elkezdi az agilis átállást, szinte törvényszerűen bekövetkezik egy pillanat: valaki megkérdezi, hogy "akkor most mi lesz a BA-kkal?"
A válaszok általában két kategóriába esnek. Az egyik: "a BA-ból lesz a Product Owner." A másik: "a BA megmarad, de most már agilis módszertannal dolgozik." Mindkét válasz részben helyes — és részben pontosan az a félreértés, ami miatt sok agilis transzformáció elakad a pénzügyi szektorban.
A FrontX-nél az elmúlt években több olyan projektbe csöppenünk bele, ahol a BA és PO szerepek keveredése okozta a legtöbb problémát. Nem technikai adósság, nem rossz architektúra, nem lassú fejlesztők. Szerepzavar.
Ebben a cikkben pontosan körüljárjuk, hogy mi a különbség a két szerep között, mikor kell melyik, és mi történik ha összekeverik őket.
Mi a Business Analyst valódi szerepe?
A Business Analyst az üzleti igény gazdája. Ez egyszerűen hangzik, de a valóságban rendkívül összetett feladatot takar.
A BA feladata nem a dokumentumírás — a dokumentum csak az eszköz. A BA valódi munkája az, hogy feltárja az üzleti igény mögötti szükségletet, azonosítsa az érintett folyamatokat és rendszereket, és olyan pontossággal fogalmazza meg a követelményeket, amelyből a fejlesztők és tesztelők félreérthetetlenül tudnak dolgozni.
Egy biztosítói projektben például a BA nem csak azt rögzíti, hogy "az ügyfélnek be kell tudnia nyújtani a kárbejelentést online." A BA feltárja, hogy a kárbejelentési folyamat hány osztályt érint, milyen adatokat kell validálni, milyen rendszerekkel kell integrálni, milyen kivételkezelési szabályok vannak, és hogyan illeszkedik ez a meglévő contact center folyamathoz. Ez nem egy ülés munkája — ez hetekig tartó elemzés, stakeholder interjúk, folyamattérképezés.
Amit a BA nem csinál — legalábbis ideális esetben: nem priorizálja a fejlesztési backlogot, nem dönt üzleti trade-offokról önállóan, és nem vezeti a sprinteket.
Mi a Product Owner valódi szerepe?
A Product Owner a termék gazdája. Egy agilis keretrendszerben — ahol a Scrum az alap — a PO az egyetlen személy, aki dönt arról, hogy a csapat mit fejleszt és milyen sorrendben.
A PO backlogot kezel, priorizál, döntéseket hoz. Amikor a fejlesztőknek választaniuk kell két feature között, a PO dönt. Amikor a sprint végén a stakeholderek újabb igényeket hoznak, a PO szűr és priorizál. Ez egy felelősségteljes, döntéshozatali szerep.
Amit a PO nem csinál: nem specifikál részletesen, nem végez gap analysist, nem dokumentálja a folyamatokat. A PO meghatározza, mit kell fejleszteni — de nem feltétlenül azt, hogy pontosan hogyan kell működnie.
Ez az a pont ahol a két szerep közötti határ a legélesebb: a BA a hogyan működjön kérdés gazdája, a PO a mit fejlesszünk most kérdés gazdája.
Ahol a két szerep összefolyik — és miért veszélyes ez
A probléma nem az, hogy a két szerep átfed. Bizonyos mértékű átfedés természetes és egészséges. A probléma az, amikor a két szerep helyett áll valaki — egyedül, mindkét felelősséggel.
A pénzügyi szektorban ez különösen kritikus, mert az üzleti folyamatok összetettsége megkívánja a mély elemzést. Egy biztosítási termék bevezetésnél nem lehet a requirement részletezését a sprint review-ra halasztani. Egy banki core rendszer integrációnál nem lehet "majd menet közben kiderül" alapon dolgozni.
Három konkrét tünetet látunk rendszeresen azoknál az ügyfeleknél, ahol a BA és PO szerepek keverednek:
Az első tünet: a fejlesztők nem tudják kinek tegyék fel a kérdést. Ha egy fejlesztőnek üzleti logikával kapcsolatos kérdése van, és nem egyértelmű, hogy a BA-hoz vagy a PO-hoz forduljon, óhatatlanul késlekedés vagy félreértelmezés következik. A legtöbb esetben a fejlesztő a "könnyebb elérhetőségű" személyt kérdezi meg — aki nem feltétlenül a megfelelő választ adja.
A második tünet: a specifikáció hiányos, mert "majd a sprintben kiderül." Ez az agilis módszertan leggyakoribb félreértése. Az iterativitás nem azt jelenti, hogy nem kell gondolkodni előre — azt jelenti, hogy a részletek finomíthatók. De az alapvető üzleti logikának, a folyamathatároknak és az integrációs pontoknak tisztának kell lenniük a fejlesztés megkezdése előtt.
A harmadik tünet: a tesztelők nem tudják mi az elvárt viselkedés. Ha a QA csapat nem tudja a specifikációból levezetni a teszteseteket — hanem saját értelmezést készít, vagy a fejlesztőktől kérdezi meg, hogy "ez így jó?" — az azt jelenti, hogy a requirements nem elég konkrétak. Ez nem tesztelési probléma. Ez BA probléma.
Mikor kell BA, mikor PO — és mikor mindkettő?
Nincs egyetlen helyes válasz, de van egy használható döntési keretrendszer.
Csak PO elegendő, ha: a termék jól körülhatárolt, az üzleti igény egyértelmű, a csapat ismeri a domaint, és a projektek rövid iterációkban, kis kockázattal haladnak. Tipikusan: belső eszközök fejlesztése, jól ismert B2C termékek iterálása.
BA mindenképpen szükséges, ha: több üzleti terület érintett, compliance vagy szabályozói követelmények vannak, a rendszer meglévő legacy rendszerekkel integrálódik, a projekt 3 hónapnál hosszabb, vagy az ügyfél maga sem tudja pontosan mit akar — csak azt, hogy mit szeretne elérni. Ez a pénzügyi szektoros projektek túlnyomó többségét lefedi.
Mindkettő szükséges, ha: nagyobb agilis transzformációban vagyunk, ahol egyszerre kell az üzleti igény mély elemzése és a fejlesztési backlog folyamatos priorizálása. Ebben az esetben a BA és a PO nem egymás konkurensei — hanem egymás nélkül hiányosak.
A legeredményesebb felállást, amit a FrontX-nél láttunk: a BA feltárja és specifikálja az igényt, a PO priorizálja és a sprintbe tervezi. A BA ott van az implementáció során felmerülő kérdéseknél, a PO ott van a stakeholder egyeztetéseknél. Nem versengés — munkamegosztás.
Amit ez a FrontX-nél jelent a gyakorlatban
Amikor egy pénzügyi nagyvállalatnál bekapcsolódunk egy projektbe, az egyik első kérdésünk: ki a BA és ki a PO — és értik-e egymás szerepét?
Ha a válasz az, hogy "nálunk ezeket egy ember csinálja", az nem feltétlenül baj — de tudatosan kell kezelni. Egy ember nem tud egyszerre mélyen elemezni és folyamatosan priorizálni. Valamelyik szenved.
A FrontX BA-i nem adják át a dokumentumot és lépnek tovább. Ott vannak az implementáció során, ott vannak az első demókon, és ott vannak akkor is, amikor a tesztelők megtalálják az első ellentmondást a specifikációban. Mert ez nem hiba — ez a munka természetes része.
Ha senior BA szakértőt keresel aki érti a pénzügyi szektor folyamatait — vagy ha olyan BA-ként dolgozol, aki komoly projekteken szeretne dolgozni ahol a szerepe valóban számít — nézd meg hogyan dolgozunk: frontx.hu/allasajanlatok
Gyakran ismételt kérdések
Mi a legfontosabb különbség a Business Analyst és a Product Owner között?A Business Analyst az üzleti igény feltárásának és dokumentálásának gazdája — a hogyan működjön kérdést válaszolja meg. A Product Owner a fejlesztési prioritások gazdája — a mit fejlesszünk most kérdést dönti el. Egy egészséges agilis projektben a két szerep kiegészíti egymást, nem helyettesíti egymást.
Lehet egy ember egyszerre BA és PO?Kis projekteknél igen, de nagy szervezetekben és összetett pénzügyi folyamatoknál ez kockázatos. A két szerep egyidejű betöltése esetén valamelyik terület szenved — általában a mély elemzés és specifikáció az, ami elmarad.
Mikor szükséges Business Analyst egy IT projektbe?Biztosan szükséges, ha több üzleti terület érintett, ha compliance vagy szabályozói követelmények vannak, ha a rendszer legacy rendszerekkel integrálódik, vagy ha a projekt 3 hónapnál hosszabb. A pénzügyi szektoros projektek többségénél ez mind teljesül.
Hogyan oldható meg a BA-PO szerepzavar egy nagyvállalatnál?Az első lépés a szerepek explicit definiálása és kommunikálása a csapaton belül. A második lépés, hogy minden döntési helyzetben egyértelmű legyen, ki a felelős — az üzleti igény pontosítása a BA-hoz, a priorizálás a PO-hoz tartozik. Ha a szervezetnek nincs tapasztalt BA-ja, külső senior BA bevonása gyorsan rendezi a helyzetet.
Mit csinál a FrontX BA-ja másképp?A FrontX BA-i nem adják át a dokumentumot és lépnek tovább — az implementáció teljes ideje alatt jelen vannak. Minden FrontX BA-nak van pénzügyi szektoros háttere, ezért a biztosítói, banki vagy lízinges folyamatokat nem kell elmagyarázni. Ez gyorsabb specifikációt és kevesebb félreértést jelent a fejlesztés során.
Behán László a FrontX Kft. ügyvezetője. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési vezetője és a LeasePlan Hungaria igazgatóságának tagja volt. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban.LinkedIn profil | FrontX blog
