avagy hogyan írjunk és hogyan ne írjunk folyamatábrát
Sokszor felmerül a kérdés informatikai fejlesztési feladatok kapcsán, hogy kell-e, hogy fejlesztői múltja legyen a Product Owner-nek (továbbiakban: PO). Lehet-e hátrányos, ha egy PO nem rendelkezik műszaki végzettséggel? Az én kérdésem ezzel szemben inkább az:
Lehet-e hátrány, ha túl sok fejlesztői tapasztalata van a PO-nak?
Mi lehet az első gondolatunk erre a kérdésre? Hát, hogy lenne már ez baj, hiszen komoly informatikai, műszaki terméket fejlesztünk, tudnia kell a PO-nak mi az, ami működik, mi az, ami nem. Hogyan lehet valamit jobban és hatékonyabban megcsinálni. A különböző problémákra milyen már létező megoldások vannak. Tudnia kell ellenőrizni az elkészült munka minőségét.
Itt álljunk meg egy pillanatra és gondoljuk át: mire van akkor a kiváló szakemberekből álló fejlesztőcsapat, ha nem a fentiek tisztázására (feltételezzük, hogy kiváló szakemberek, nem kiváló szakemberekkel ugyanis bármilyen szigorú ellenőrzés mellett sem lehet kiváló termékeket fejleszteni).
(minősített eset, ha azért akarjuk, hogy a PO-nak műszaki háttere legyen, hogy „ne verje át a csapata” – ez már inkább recruitment és szervezési kérdés. Miért nem bízunk azokban a szakemberekben, akiket mi magunk vettünk fel?)
Mi tehát a PO feladata? A scrumguide szerint:
- Elősegíti és félreérthetetlenül kommunikálja a termék célokat,
- Létrehozza és világosan kommunikálja a Product Backlog elemeket,
- Rendezi (priorizálja) a Product Backlog elemeket,
- Biztosítja, hogy a Product Backlog transzparens, látható és érthető.
Tehát elsődlegesen azért felel, hogy a termékkel/projekttel különböző üzleti célokat érjen el a csapat transzparensen, jól láthatóan, és érthetően.
Természetesen alapvetően és feltétlenül nem okoz problémát, ha a fentiek mellett még műszaki háttere is van a PO-nak (sőt, minden bizonnyal számos előnye is van). Ha félre tudja tenni a tudását (ami már egyébként lehet, hogy el is avult), és nem kezdi el mikromenedzselni a csapatot, akkor még akár javítja is az együttműködést, és segíti a közös együtt gondolkozást.
De mégis milyen hátrány lehet belőle?
Nemrég közösen dolgoztam egy termékfejlesztésen egy kedves Ügyféllel. Az Ügyfélről azt kell tudni, hogy nagyon komoly fejlesztői háttere van – konkrétan tevékenyen részt vett a termék addigi építésében mint szoftverfejlesztő. Közösen dolgoztunk a Roadmap, Storymap, Backlog összeállításán, ehhez pedig sok más eszköz mellett természetesen folyamatábrát is használtunk.
A Miért készíts folyamatábrát? című blogcikkben írtam róla, mire jó és hogyan érdemes használni a folyamatábrát. Ha bővebben érdekel a téma, a linken el tudod olvasni. Röviden: az a legfőbb célja, hogy világosan és közérthetően bemutasson valamilyen folyamatot
A folyamatábra készítésénél az a jónak tűnő ötletünk támadt, hogy csináljuk meg úgy a folyamatábrát, hogy abból eleve könnyen lehessen majd később kódot írni. Éreztem, hogy nem biztos, hogy ez a jó irány, de mivel még nem próbáltam, nem tudtam pontosan megmondani, mi lehet ezzel a probléma.
Ilyesmik születtek:
Sok folyamatábrát rajzoltunk, sokat dolgoztunk vele, de egyre nehezebben haladtunk. Nagyon nehéz volt értelmezni, amiket írtunk, mire dekódoltunk egy lépést fejben, már el is felejtettük az előző lépéseket. Odáig jutottunk, hogy már kiegészítő magyarázó cetliket tettünk az egyes lépésekhez, hogy értsük mi történik. Egy folyamatábrán, aminek az lenne a fő célja, hogy bárki egyszerűen és gyorsan értelmezni tudja!
Levontuk a következtetést, fontos, hogy megmaradjon a fő lényeg: a közérthetőség. A folyamatábra nagyon fontos eszköz, de mindig tartsuk szem előtt, mi a célja. Lehet olyan eset is, amikor nagyon fontos a műszakilag pontos megfogalmazás. De ha az vele a célunk, hogy mindenki a legszélesebb körben értse, mi a folyamat, akkor inkább fogalmazzunk kicsit „pongyolán”, de érthetően. Mint azok a levelek amiket például a NAV-tól szoktunk kapni: jó hosszú, tele van jogszabályi hivatkozásokkal, ezer százalék, hogy minden nagyon pontosan ott van, és nem lehet belekötni. De öt oldal hosszú, és mire a közepére érünk, már nem emlékszünk, mit olvastunk az elején. Pedig csak annyi lenne az üzenet: nem töltötted ki a neved a bevallás XY pontjában, kérlek, pótold. A fenti folyamatábra például így nézne ki emberi nyelven:
Zárás: jó, ha van műszaki hátterünk, de néha bezavarhat, ha az üzleti kérdésekkel egy időben a technikai problémákat is meg akarjuk oldani. Az egyszerűbb sorrend, ha felmérjük milyen problémára szeretnék választ kapni (mi az üzleti igény), majd ezután foglalkozunk csak azzal, hogyan is lehetséges ezt megvalósítani.
