Bevezetés
2024-et írtunk, és egy biztosítói ügyféllel dolgoztunk egy kárbejelentési folyamat digitalizálásán. A specifikáció kész volt, a fejlesztőcsapat megkapta, mindenki bólintott. Hat héttel később, az első demón az ügyfél megkérdezte: "De hol van a kárügyintéző jóváhagyási lépése?"
Senki nem feledkezett meg róla szándékosan. A BA dokumentumban szerepelt — de más szóhasználattal, más kontextusban, és az ügyfél és a fejlesztők másképp értelmezték. Három nap újratervezés, két hét késés, és egy kínos megbeszélés következett.
Ez nem fejlesztői hiba volt. Nem is ügyféli hiba. Ez annak az illúziónak az ára volt, hogy a BA munkája véget ér amikor a dokumentum el van küldve.
Azóta sokat gondolkoztam ezen — és arra jutottam, hogy a BA munkájának nincs valódi zárópontja. De ez, ellentétben azzal amit először gondolnál, nem panasz.
A dokumentum illúziója
Az IT projektek többségében a BA szerepét valahogy így képzelik el: az elemző összegyűjti az igényeket, megírja a specifikációt, átadja a fejlesztőknek, és innen már az ő dolguk. A BA "kész van."
Ez a modell papíron logikus. A valóságban szinte soha nem működik.
Nem azért, mert a BA rosszul dolgozik. Hanem mert az üzleti igény természeténél fogva élő dolog. Változik, amikor a piaci körülmények változnak. Változik, amikor a stakeholder megváltoztatja a prioritásait. Változik, amikor a fejlesztés során kiderül, hogy egy folyamat a valóságban máshogy működik mint ahogy leírták.
Egy pénzügyi szektoros projekten — ahol compliance követelmények, több érintett osztály és komplex rendszerintegrációk vannak — ez hatványozottan igaz. Amit január elején specifikáltál, februárban már részben elavult. Nem mert rosszul dolgoztál, hanem mert a szervezet tanult közben.
A dokumentum nem a BA munkájának eredménye. A dokumentum a BA munkájának egy pillanatfelvétele.
A BA mint fordító — és miért nehezebb ez, mint gondolod
A BA szerepét szokás "hídként" leírni az üzlet és az IT között. Ez igaz, de leegyszerűsíti a helyzetet. Egy híd statikus. A BA valójában egy folyamatos fordítást végez két olyan fél között, akik különböző fogalmi rendszerben gondolkoznak — és mindkét fél azt hiszi, hogy teljesen érthetően kommunikál.
Álljon itt egy konkrét példa. Amikor egy biztosítói compliance vezető azt mondja, hogy egy folyamatnak "azonnal" kell lefutnia, ezt érti alatta: a kárbejelentés napján, munkaidőben, mielőtt az ügyintéző hazamegy. A fejlesztő ugyanerre a szóra azt érti: aszinkron feldolgozás, néhány perces késleltetéssel, technikai szempontból ez "real-time." Az ügyfél pedig azt érti: ha este 10-kor bejelentik a kárt, reggel 8-ra legyen feldolgozva.
Három különböző értelmezés, ugyanarra az egyetlen szóra. A BA feladata felismerni ezt a szakadékot — és nem csak egyszer, hanem a projekt teljes életciklusa alatt, folyamatosan.
Ez nem adminisztratív munka. Ez aktív, kritikus gondolkodás, ami sosem kapcsolható ki.
Három jel, hogy a BA munkája valóban hatékony
Nem szeretem a mérőszám-alapú megközelítést a BA hatékonyságának értékelésére. Az "elkészített dokumentumok száma" vagy a "lezárt requirementek aránya" félrevezető. Inkább viselkedési jeleket figyelek.
Az első jel: a fejlesztők a BA-t kérdezik, nem a projektmenedzsert. Ha egy fejlesztőnek kérdése van az üzleti logikával kapcsolatban, és az első ösztöne az, hogy a BA-hoz fordul — ez azt jelenti, hogy a BA valódi autoritással bír a requirements felett. Ez nem magától értetődő. Ez bizalomból épül fel, lassan, projekt közben.
A második jel: az üzleti oldal a BA-t hívja, mielőtt döntést hoz. Amikor az ügyfél egy új igénnyel vagy változtatással kapcsolatban nem a projektvezetőhöz, hanem a BA-hoz fordul először — ez azt jelzi, hogy a BA-t valódi partnerként látják, nem adminisztrátorként.
A harmadik jel: a tesztelők értik a specifikációt első olvasásra. Ez az egyik legőszintébb visszajelzés a BA munkájának minőségéről. Ha a QA csapatnak hosszas magyarázat kell ahhoz, hogy teszteseteket tudjon írni, a specifikáció nem elég konkrét. Ha az első olvasásra tudnak dolgozni belőle — a BA jól végezte a munkáját.
Amit én másképp csinálok mostanra
25 évvel ezelőtt, amikor elkezdtem IT projektek közelében dolgozni, azt hittem, hogy a jó specifikáció a cél. Ma már tudom, hogy a jó specifikáció csak egy eszköz — és nem is mindig a legfontosabb.
Amit ma másképp csinálok: sokkal korábban kezdem el a fejlesztőkkel és tesztelőkkel való együttműködést. Nem várom meg amíg a dokumentum "kész" — mert az soha nincs kész, csak "elég jó a következő lépéshez."
Amit ma másképp csinálok: az üzleti igény mögé kérdezek, nem csak a felszínen dolgozom. "Miért kell ez a funkció?" sokszor fontosabb kérdés mint "Pontosan hogyan kell működnie?" Az első kérdésre adott válasz sokszor gyökeresen megváltoztatja a másodikat.
Amit ma másképp csinálok: elfogadom, hogy a BA munkájának nincs lezárási pillanata — és ezt nem tehernként élem meg, hanem a szerep természeteként. Egy jó BA nem "befejezi" a munkáját és továbblép. Egy jó BA gazdája marad az igénynek addig, amíg az implementáció el nem éri azt a pontot, ahol az üzleti igény valóban meg van valósítva.
Ez a szemlélet formálta azt, ahogy a FrontX-nél a BA szerepét értelmezzük. Nálunk a BA nem adja át a dokumentumot és lép tovább a következő projektre. A BA ott van az implementáció során felmerülő kérdéseknél, ott van az első demókon, és ott van amikor a tesztelők megtalálják az első ellentmondást a specifikációban. Mert ezek nem hibák — ezek a munka részei.
Kérdés hozzád
Szerinted mikor mondhatja el egy BA, hogy kész van?
Én arra jutottam, hogy legkorábban akkor, amikor az első éles felhasználó sikeresen elvégzi azt a folyamatot, amit a BA specifikált — és nem kell hozzá magyarázat, segítség, vagy kerülőút.
Ha van más véleményed, vagy más tapasztalatod — szívesen olvasom a kommentben.
