01
Kiinduló helyzet
Egy új adatréteg és több rendszerkapcsolat kialakítása indult el. Az érintett alkalmazásismereti csapat csak akkor került képbe, amikor a projekt már futott.
Esettanulmány · Business analysis
Amikor egy technikai projektből üzleti újratervezés lesz
Egy technikai háttérváltozásnak induló projekt későn érte el az érintett üzleti és alkalmazásismereti csapatot. A végeredmény nem egyszerű illesztés lett, hanem egy teljes felhasználói flow gyors újratervezése és leszállítása.
Röviden
A projekt nem ott kezdett fájni, ahol elindították.
A háttérrendszeri változás papíron technikai feladatnak tűnt. A valós hatás viszont egy meglévő üzleti alkalmazás felhasználói flow-jában, képernyőiben, mezőiben és szállítási kapacitásában jelent meg.
02
Valódi probléma
Nem történt időben hatásfelmérés. Az érintett felület, user flow és üzleti működés méretét olyan szereplők becsülték, akik nem ismerték a meglévő alkalmazást.
03
Eredmény
A megoldás végül elkészült és stabilan működött, de csak gyors újratervezéssel, jelentős szervezési teherrel és komoly kapacitásnyomással.
Kontextus
Nem minden technikai projekt marad technikai.
A projekt egy új háttérrendszeri és adatkapcsolati működés kialakításaként indult. A fókusz eleinte az volt, hogy az új adatréteg milyen rendszerekkel kommunikál, milyen új mezőkre, hívásokra és backend oldali kapcsolatokra lesz szükség.
Az érintett üzleti / alkalmazásismereti csapat viszont csak később került be a képbe. Ekkor derült ki, hogy a változás nem egyszerű adat- vagy mezőbővítés lesz: a meglévő alkalmazás felhasználói működését is jelentősen át kell alakítani.
A változás méretét az mutatta meg igazán, hogy az eredetileg egyképernyős alkalmazásból végül nagyjából 5–6 képernyős, új felhasználói flow-val működő megoldás lett. Ez már nem egyszerű front-end igazítás volt, hanem egy teljes alkalmazásrész újratervezése és leszállítása.
A sikeres szállítás nem mentesíti a projektet a rossz előkészítés költségei alól.
Diagnózis
Három ponton csúszott el a projektindítás.
A probléma nem az volt, hogy a projekt ne lett volna fontos. Hanem az, hogy az érintettség, a munkaméret és a szállítási modell túl későn lett látható.
Késői bevonás
Az érintett alkalmazásismereti csapat akkor kapta meg a feladatot, amikor a projekt már elindult, és más rendszerekkel már zajlottak az egyeztetések.
Kialakult helyzet
- a projekt technikai rendszerkapcsolati fókuszból indult;
- az érintett üzleti / alkalmazásismereti csapat későn került be;
- nem készült előzetes hatásfelmérés a meglévő alkalmazásra;
- a projekt azt várta, hogy a feladat gyorsan beilleszthető lesz a futó munkák közé.
Ez miért baj?
- nem látszott a valós munkaméret;
- nem volt időben becsült kapacitásigény;
- a projekt elvárása és a csapat valós szállítási lehetősége eltért;
- a késői felismerés kapkodást és plusz szervezési terhet okozott.
Javaslat
- projektindítás előtt érintettségi térképet kell készíteni;
- minden érintett alkalmazás mellé üzleti / alkalmazásismereti felelőst kell bevonni;
- már az előkészítésben jelezni kell, ha felület, user flow vagy üzleti működés változik;
- a hatásfelmérés legyen döntési pont, ne utólagos tűzoltás.
Hiányzó üzleti elemzés
A projektben eleinte nem volt olyan szereplő, aki a felhasználói flow-t, képernyőlogikát, mezőket és üzleti szabályokat végig tudta volna gondolni.
Kialakult helyzet
- a fókusz a backend, adatkapcsolatok és rendszerintegrációk oldalán volt;
- a user flow, képernyők, mezők és validációk nem voltak időben kidolgozva;
- az eredetileg egyszerű alkalmazásból többképernyős működés lett;
- a részleteket gyorsított tempóban kellett utólag megtervezni.
Ez miért baj?
- a technikai megoldás önmagában nem írja le a felhasználói működést;
- későn derül ki, hány képernyő, mező és döntési pont szükséges;
- a fejlesztés előtt hiányzik az üzleti értelmezés;
- a csapat a tervezést, elemzést és fejlesztést egyszerre próbálja behozni.
Javaslat
- ha egy technikai változás felületet érint, BA / PO szerep bevonása kötelező legyen;
- a user flow, képernyők, mezők és üzleti szabályok legyenek külön deliverable-ek;
- a fejlesztés előtt legyen közös walkthrough az érintett csapatokkal;
- a „csak technikai változás” feltételezést minden esetben ellenőrizni kell.
Waterfall projekt és agilis szállítócsapat
A projekt vízesés logikával tervezett, miközben az érintett fejlesztői csapat kéthetes agilis szállításban, párhuzamos feladatok mellett működött.
Kialakult helyzet
- a projekt eleinte dedikált, azonnali fejlesztői kapacitással számolt;
- az érintett csapatnak közben más futó feladatokat is szállítania kellett;
- a kéthetes agilis szállítási ritmust először külön meg kellett védeni;
- a projektterv nem számolt eléggé azzal, hogyan illeszkedik a feladat a csapat roadmapjébe.
Ez miért baj?
- a projekt elvárása irreálisnak tűnhet a szállítócsapat oldaláról;
- a csapat roadmapje sérülhet;
- a kapacitásviták elviszik az energiát az érdemi tervezéstől;
- a késői nyomás túlórához és kapkodó döntésekhez vezethet.
Javaslat
- a waterfall projektterv és az agilis csapat sprintterve között legyen explicit illesztési pont;
- a kapacitásról nem feltételezés, hanem közös tervezés alapján kell dönteni;
- a nagyobb feladatot fejleszthető szeletekre kell bontani;
- a határidőt, scope-ot és párhuzamos munkákat együtt kell kezelni.
Összegzés
Elkészült, de túl nagy áron.
A megoldás végül a kívánt időre elkészült és stabilan működött. Ez azonban nem jelenti azt, hogy a projektindítás jó volt: a sikeres szállítás mögött késői elemzés, gyors újratervezés, extra szervezési teher és kapacitásnyomás állt.
1 → 5–6
Képernyők száma
Az eredetileg egyszerű alkalmazásból többképernyős, új user flow-val működő megoldás lett.
későn
Érintetti bevonás
Az alkalmazásismereti csapat csak a projekt elindulása után került érdemben képbe.
2 hét
Agilis szállítás
A csapat sprintlogikája nem volt összehangolva a projekt eredeti elvárásaival.
0 hiba
Végső működés
A leszállított megoldás stabil lett, de a siker sok utólagos tűzoltást igényelt.
Tanulság
A hatásfelmérés nem adminisztráció. Kockázatcsökkentés.
Egy technikai projekt is érinthet teljes üzleti folyamatot. Ha a projekt csak rendszerekben, adatbázisokban és integrációkban gondolkodik, könnyen túl későn derül ki, hogy valójában felhasználói működést, képernyőket és üzleti szabályokat is újra kell tervezni.
Az ilyen helyzetekben a BA / PO szerep nem későbbi dokumentációs feladat, hanem korai kockázatcsökkentés. Segít megérteni, hogy mit jelent a változás a felhasználónak, az alkalmazásnak, a tesztelésnek és a szállítócsapat kapacitásának.
Attól, hogy egy projekt végül sikeresen lezárul, még lehet, hogy túl nagy terhet tett a csapatra. A cél nem csak az, hogy valami elkészüljön, hanem hogy ne utólag kelljen kitalálni, mekkora munkát jelentett volna már az elején látni.