Ma már szerencsére teljesen általánossá, sőt szükséggé vált a Product Owner-ek munkája a különböző IT fejlesztési területeken. Ennek ellenére ez a kérdés fel szokott merülni, különösen olyankor, ha egy szervezet külső beszállító segítségét veszi igénybe a céljai eléréséhez. Ilyenkor a gondolatmenet valami hasonló: Szeretnék rendelni egy szoftvert, pontosan tudom mit szeretnék, csak nincs hozzá szabad fejlesztési kapacitásom. Össze is írtam egy specifikációba, milyen legyen, már „csak meg kell csinálni”. Nem szeretnék azért fizetni még pluszban valakit, csak azért, hogy „szétdarabolja a specifikációt user storykká”. Ez önmagában igaz is lehetne, ha csak ennyit tenne hozzá a Product Owner, de ennél jóval szélesebb körű feladatokat is ellát.

Rendben, kell a PO, de tud-e jönni akkor legalább a megrendelő szervezetén belülről? Természetesen lehetséges kinevezni valakit erre a fontos funkcióra, olyan domain ismerettel fog rendelkezni, amit szállító oldalon sok idő lenne felépíteni (ha lehetséges egyáltalán).

De egyértelműen jobb-e annál, mintha a szállító adja?

Milyen előnyei vannak egy megrendelő oldali PO-nak?

Közelség a szponzorokhoz és a különböző érintettekhez (stakeholderek)

Nagy eséllyel jól ismerik egymást a szervezeteden belül az emberek. Így a belülről kinevezett PO tudja, kitől milyen kérdésekre, hogyan kaphat választ. Az információk beszerzésének sebességén pedig sok múlhat.

Belső üzleti tudás

Egy belső ember jól ismeri az ügyfél saját piacát és kultúráját, tudja kik a versenytársak és ők mit kínálnak. Ezáltal megalapozott döntéseket tud hozni.

Magasabb felhatalmazás a fejlesztő csapat felé

Mint a megrendelő cég képviselője, azonnal bizalmat kap a döntések meghozatalakor mind a szállító oldalon, mind a saját üzleti oldalán.

Jobb rálátás a készülő funkciók tényleges hasznára

A rengeteg belsős információ birtokában sokkal inkább el tudja dönteni mely funkciók lehetnek hasznosak, mint egy szállító által delegált PO.

Milyen előnyei vannak a szállító oldali PO-nak?

Készségszinten használja a különböző PO technikákat és eszközöket

Arra specializálódott, hogy szofter termékeket állítson elő a fejlesztőcsapattal karöltve. Ehhez sok, a világon már bizonyított eszközt használ, folyamatosan képzi magát a területen. Ez a foglalkozása.

Magasabb az elszámoltathatósága

A fejlesztő csapat könnyebben számon tudja kérni rajta, ha nincs megfelelő mennyiségű előkészített feladat. A megrendelő is könnyen tudja számonkérni, hiszen ezért fizeti.

Jobb rálátása van a projekt haladására, jobb együttműködése van a fejlesztő csapattal

Ismeri a csapattagokat, dolgoztak már együtt, fél szavakból is megértik egymást. Hasonló előny, mint ami a másik oldalon a megrendelő oldali PO és a stakeholderek között jelentkezik.

Tapasztalata van a szoftverfejlesztésben

Ez talán a legfontosabb: tudja mik lehetnek a buktatók, amikre figyelni kell. Tudja, hogyan kell úgy priorizálni már a munka elején, hogy abból a végén szuper eredmény tudjon születni. Rátalál azokra az elvárásokra, amiket az ügyfél nem írt le a specifikációban (ha van), mert „magától értetődő”, de mindenképpen szeretné, ha elkészülne.

Elérhető

 A Product Owner-nek sok feladata van: többek között user story-kat kell írnia, sprintek és release-ek tartalmát tervezni, folyamatosan priorizálnia kell a backlogot, mindeközben elérhetőnek kell lennie a stakeholderek és különösen a csapat számára, hogy válaszolni tudjon a napi munka során felmerülő kérdésekre… ez egy teljes munkaidős állás. A megrendelő oldali Product Owner-nek sokszor olyan személyt jelölnek ki, aki az adott szervezetben más, magas pozíciót is betölt. Ez gyakran azt eredményezi, hogy a megrendelő PO-ja nem elérhető időben a csapatnak, ami késéseket és alacsonyabb szállítási sebességet, legrosszabb esetben alacsonyabb előállított üzleti értéket jelenthet.

Akkor melyik a jobb? 

Mint láthatjuk, mindkét verziónak vannak egyaránt előnyei és hátrányai, jellemzően, ami egyik oldalon előny, az a másikon hátrány. A kérdés, hogy mennyire ér rá az ügyfél, mennyire vannak olyan tapasztalatai, amelyek kellenek a termékfejlesztéshez

Akkor mindenképpen a szállító oldali Product Ownert javasoljuk.

Működőképes lehet egyébként az is, ha mindkét oldalon van PO, így mindkét oldali előnyöket megnyerjük magunknak (persze mint mindig, az éremnek két oldala van: sokkal nagyobb figyelmet kell fordítani ilyenkor a két PO közötti szinkronizálásra). Ebben az esetben a szállító oldali PO jobban fókuszál az operatív teendőkre, míg az ügyfélnek csak a termék stratégiával kell foglalkoznia.

Ha szívesen beszélgetnél velem a fenti témáról, vagy bármi másban tudnék segíteni, keress LinkedIn-en és írj!

Balázs Lánchidi

Balázs közel 10 éve dolgozik informatikai projekteken. Eleinte projekt menedzserként vízesés modellben dolgozva, majd leginkább szállító oldalon különböző agilis módszertanok mentén főleg PO-ként, néha SM-ként. Kiemelten fontosnak tartja a felhasználók minél korábbi bevonását a termékfejlesztésbe, hogy megfelelően validálva, a lehető legnagyobb értéket tudjon nekik szállítani csapatával.