Bermuda-háromszög, ami elnyeli az IT projekteket: BA, PM és Architekt

Írta Szabó Katalin 

Voltál már olyan projektben, ahol volt BA, PM és architekt is… mégsem volt teljesen világos, mit építetek?

Sok szervezetben tapasztalhatod azt, hogy nem teljeskörűen használják ki a Business Analyst szerepkört, hanem egyfajta dokumentációt író munkatársként tekintenek rá. Számos ilyen példát láthatunk, amikor a Projekt Menedzser vagy az Architekt veszi át a Business Analyst egyes feladatait, azaz a PM írja a requirementeket, az Architekt dönti el, mi legyen és a BA pedig dokumentál. Ismerős a helyzet? Ez a klasszikus helyzet ahhoz vezethet, hogy a requirementek nem tiszták, a stakeholderek félreértik egymást, és végül mindenki mást hibáztat. A legnagyobb kockázat pedig, hogy nem valódi értéket szállítunk az üzletnek.

Egy tipikus – de nem ideális – projektfolyamat

Nézzünk meg egy tipikus projekt flow-t, amely számos szervezetnél megjelenik, viszont nem ideális:

  1. Projekt előkészítő szakasz: az üzlet a projektekért felelős tanács elé tár egy problémát, vagy igényt, amelyre szeretnének megoldást kapni.
  2. Zöld út: A tanács a bemutatottak alapján zöld utat ad a projektnek
  3. Erőforrás-bevonás: Jobb esetben a háromszög mindhárom szereplője be van rögtön vonva a projektbe, rosszabb esetben a BA-t később rakják rá.
  4. És itt kezdődik a közös munka.

Gyakori buktatók a közös munka során:

  • Megoldás az igény helyett: Az üzlet nem igényt fogalmaz meg, hanem rögtön megoldást, amelyet követelményként jegyeznek fel: “Indítsunk egy projektet egy olyan applikációra, amely a munkavállalók képzését monitorozza.” Itt a valódi igény a munkaerő szakmai fejlesztése lenne.
  • A BA kihagyása: A BA-t „elfelejtik” meghívni az egyeztetésekre, így az üzleti meetingen a PM jegyzetel, majd a jegyzetelt listát átadja a BA-nak: “Beszéltem az üzlettel, itt van a jegyzetem, írjuk be a backlogba.” Itt még azt sem tudjuk, tényleg applikációt kell-e fejlesztenünk.
  • Azonnali technikai fókusz: A megismert megoldást az Architekt rögtön technikailag értelmezi: “Az applikációhoz akkor AD felhasználási jogosultság fog kelleni?”

Mi történik, ha elmarad a valódi elemzés?

Ebben az esetben nem készül valódi igényfelmérés, nem lesznek összehasonlítva a különböző alternatívák, és az igények nem lesznek visszavalidálva. Ennek következtében későbbi rework lesz szükséges, amely plusz erőforrásbevonást fog igényelni. A történet végén mindenki szomorú vagy bosszús lesz, hogy nem azt kapta, amit kért.

  • A fő kérdés: Nem az, hogy ki és hogyan készíti el a dokumentációt, hanem hogy ki a felelős a probléma megértéséért és strukturálásáért.

Egy hatékony folyamatban már a projekt előkészítő szakaszában tanácsos egy üzleti elemzőt bevonni azért, hogy segítse az igény formálódását, felmérje a jövőbeli stakeholdereket és facilitálja az üzleti szereplőket.

Ki miért felel?
1. Business Analyst (BA): Fő felelőssége, hogy az igénylőnek értéket teremtsen.
  • Üzleti igények feltárása (a requirement nem attól kész, hogy le van írva!)
  • A probléma strukturálása és a stakeholderek összehangolása.
  • Igények tisztázása, validálása és kockázatok számon tartása a PM-el együtt.

2. Project Manager (PM): A projekt lefolyásáért, a szállítandók időben érkezéséért felel.

  • Scope meghatározása.
  • Timeline és budget tervezése, betartása és allokálása.
  • Stakeholder kommunikáció.

3. Architekt: A technikai megvalósításért felelős.

  • Technikai megoldás felvázolása és IT feasibility.
  • Design döntések meghozatala.

Útmutató az ideális működéshez – Mit tehetünk?

Ahhoz, hogy a feladatok elosztása optimális legyen, érdemes megfogadni az alábbiakat:
  • Tisztázzuk a szerepeket: Expliciten le kell írni és be kell tartani a felelősségi köröket.
  • Definiáljuk a sikert: A BA-nak tisztáznia kell a business goal-t, a várt outcome-ot és a siker mérését – enélkül nincs kész egy requirement.
  • Discovery vs. Delivery: Ne keverjük a két szakaszt! A discovery-nél a BA és a stakeholderek, a delivery-nél a PM, az architekt és a fejlesztők játsszák a főszerepet.
  • Facilitálás: A BA vezesse az üzleti workshopokat és oldja fel a konfliktusokat. Ki kell küszöbölni, hogy átpasszolt jegyzetekből kelljen igényeket leírni.

Záró gondolat: A BA szerep nem tűnt el, csak sok helyen leegyszerűsödött. A projekt végén nem a dokumentáció az érték, hanem az, hogy megértettük a problémát és olyan megoldást szállítottunk, amely az üzletnek is értéket képvisel.


business analystBusiness Analyst eszköztárprojektmenedzsmentsolution architect