Szerző: HIRDETÉS

2021. december 8. 13:17

Amikor a technológiai és az üzleti oldal találkozik

Hogyan lehet egy eredményeket produkáló és inspiráló megoldásokat felvonultató, stabil működést kialakítani a fejlesztő csapatok számára? Jó gyakorlatok, kihívások és konkrét példák Gubucz Esztertől, a Jófogás és Használtautó.hu portálokat üzemeltető Adevinta CTO-jától.

Napjainkban szinte minden nagyobb cég az agilis transzformáció valamelyik fázisában van: valaki már élvezi az áldásokat, valaki épp a közepében dolgozik gőzerővel, valaki pedig az előszobában áll. Választható módszertanból nincs hiány. SAFe, DaD, Less, Spotify, nagy tanácsadó cégek hibrid modelljei, széles a paletta. Ember és vezető legyen a talpán, aki ki tudja választani, melyikre tegye le a voksát. 

A PEAK egy tailor-made, vagyis egyedi módszertan – vagy filozófia, ahogy tetszik –, amit a spanyol illetőségű Actio Global nevű cég vitt és visz el rengeteg vállalathoz, köztük az Adevintához is. Alapvető tulajdonságaiban egy érdekes elegye a fent felsorol módszertanoknak, némi saját ízvilággal megfűszerezve.

gubuczeszter
gubucz eszter

Negyedéves tervezési ciklusok (amik ebben a rendszerben a Quarterly Direction Meetings nevet viselik), OKR-ek (Objectives and Key Results), squadok, tribe-ok, cross-functional csapatok, autonómia, felhatalmazás, kollaboráció – az összes buzzword megjelenik, nemcsak a munkában, hanem magában a betűszóban is:

P: Prioritize Outcomes

E: Empower Autonomy

A: Align Collaboration

K: Know to Discover & Deliver

Lehetne hosszan és részletesen elemezni, hogy a PEAK mint kulturális rendszer és skálázott agilis működés milyen építőelemekből áll, miben hasonlít és miben különbözik a többi helyen alkalmazott módszertanoktól, de inkább nézzük meg, hogy mi az Adevinta magyar szervezeténél hogyan fogadtuk a bevezetését, milyen kihívásokkal szembesültünk, és hogyan oldottuk meg azokat – vagy tanultunk meg együtt élni velük.

ÉLETÜNK A PEAK VIGYÁZÓ ÖLELÉSÉBEN

A PEAK egy nagyon megengedő rendszer. Nem merül el az operatív részletekben, nagyon szabad keretet ad minden szinten, ugyanakkor tartalmaz pár ajánlást, amik általánosak, és mivel az egész erre építkezik, ezért elengedhetetlenek.

Az egyik ilyen ajánlás az OKR-ek használata, amik manapság egyre szélesebb körben elterjedtek, és jó is, hogy a PEAK beáll ebbe sorba, mert egyszerűsíti az újonnan érkezőknek a megértést, van hozzá bőven irodalom, ahol utána lehet ennek olvasni. Kaszkádosított OKR-ekkel dolgozik, tehát a nagy stratégiai OKR-eket bontjuk egyre lejjebb és lejjebb, míg végül elérünk a csapatok szintjére, és így elméletben mindenki pontosan tudja, hogy az ő munkája hogyan járul hozzá a cég high level stratégiai céljaihoz. 

Ami a PEAK érdekes adaléka az OKR-ekhez, az az ún. Health Metrics, ami egy talán kevésbé ismert, de nagyon hasznos kiegészítés: míg az OKR-ek a stratégiai célok elérésében mutatnak irányt, addig ezek a metrikák arra szolgálnak, hogy a fél szemünket folyamatosan rajtuk tartva monitorozzuk a legfontosabb alapvető mutatók „egészségét”, és ha ez a mutató egy előre megállapított küszöbérték alá csökken, akkor az OKR-eket eldobva mentsük a beteg páciens (cég, termék, department) egészségét, mert nagy baj van. Egy valós példa: szeretnénk javítani a release-ek minőségén, ezért a technológián közösen megegyezünk a change failure rate-ben, mint az egyik key resultban. Megvan, hogy mit szeretnénk elérni, megegyezünk, hogy milyen tevékenységek mentén érjük el a javulást, de miközben üldözzük a change failure rate leszorítását, nem szeretnénk, hogy mindezt úgy érjük el, hogy egyáltalán nincs release, vagy havonta egy release van, amit három hétig tesztelünk. Ezért megegyeztünk a health metrics-ekben, ebben a konkrét esetben a lead time to change, és a deploymentek gyakorisága volt a célravezető. Ezeken a területeken eddig nagyon szép, stabil és konzisztens eredményeket produkált csapat, amit fenn akartunk tartani, illetve jó ellenpontjai a quality OKR-nek. Szeretnénk elérni a célt, de nem azon az áron, hogy cserébe rontunk az eddigi eredményeinken.

peak_es_dd

A negyedéves tervezés szintén része a keretrendszernek. A különbségek a Spotify-hoz vagy akár a SAFe-hez képest főleg az elnevezésekben rejlenek: Quarterly Direction Meetings és quarterly drumbeat (becenevén “W”) a QBR és a PI helyett. A megengedő szellem a negyedéves tervezésben is megjelenik, hiszen, bár minden lényeges lépést definiál ((1) menedzsment guidance, (2) csapatok első javaslata a negyedévre, (3) menedzsment visszajelzés, (4) újabb iteráció a csapatok tervén, majd a végén (5) a formális megegyezés), sem a tervezési ciklus hosszát, sem a lépések lebonyolításának módját nem vési kőbe. Rábízza az adott szervezetre/cégre, hogy mi a kultúrához és a szakemberekhez leginkább illő módszer.

A fentieken kívül pedig még mindenképpen kiemelném  a heti Gemba Walk intézményét is. Maga az ötlet nem a PEAK-et jegyző cégtől származik, hanem a Toyotánál indult, ahol a gyár vezetősége szépen lement a gyártósorhoz és körbejárták azt. Így közelről látták a mindennapi operatív munkát, beszélgettek a csapatokkal, és ezáltal nemcsak a számokat nézték az asztaluk mögül, hanem közvetlen kapcsolatuk volt a valósággal és ezzel együtt az emberekkel is. Egy nemzetközi cégnél, ahol gyakori a külföldön ülő csapattag, illetve a hazai kollégák közül is sokan otthonról dolgoznak, elég nagy kihívás úgy megtartani ezt a hétindító eseményt, hogy a csapatok számára transzparens legyen a többiek munkája, a menedzsment is kapjon egy általános képet arról, hogy mi történik a csapatokban, és közben ne csapjon át az egész egy újabb különleges elnevezésű státuszba, többek között ez is egy olyan esemény, amit rendszeresen tartunk, és folyamatosan formálunk, javítunk a kollégák visszajelzései és saját benyomásaink alapján.

A MINDENNAPI ÉLET KIHÍVÁSAI

A Gemba Walk leírásánál már sugalltam, hogy a PEAK, részben a nagyon megengedő volta miatt, rengeteg kérdésre nem ad választ, amivel nem jobb vagy rosszabb a többi hasonló módszertannál, hanem szépen belesimul a sorba. Talán túlzó is elvárni azt, hogy egy bonyolult és komplex, egész cégekre kitalált felskálázott agilis működés adjon praktikus válaszokat a kínzó napi operatív kérdésekre, de ettől még a szenvedés, a kulturális (és teljesítménybeli) törés nem lesz kisebb mértékű. Néhány példa a mindennapi élet „unalmasabb” kihívásaira az Adevinta életéből, és a rájuk adott válaszokból:

1. Értjük, hogy kell OKR, de hogyan lesz nekünk OKR-ünk, és főleg, hogyan lesz jó OKR-ünk?

A lehetséges megoldások sora szinte végtelen: küldjünk el mindenkit OKR író tanfolyamra, autodidakta módon beletanulunk, esetleg megfogjuk a KPI-okat, és átnevezzük azokat OKR-nek? 

Az Adevintánál még közel sem vagyunk az út végén, de ami itt beválni látszik, az az, hogy a stratégiai irányok megadása után a product menedzserekkel, engineering menedzserekkel, architectekkel, és amennyiben szükséges, egyéb szereplőkkel is leül a termék és technológiai terület vezetője és fél-egy nap alatt megszületnek a csapatok és területek negyedéves (év elején pedig éves) OKR-jei. Ezeket aztán összefésüljük, hogy a technológia és a termék, valamint az egyes csapat célok támogassák, ne pedig akadályozzák egymást, és ellenőrizzük, hogy valóban támogatják-e a stratégiai irányokat.

2. Hogyan szervezzük a csapatok napi operatív munkáját?

Jön rá a válasz, hogy hát az OKR-ek megmutatják! Az irányt valóban megmutatják, de a hogyanról sem az OKR nem nyilatkozik, sem a PEAK. Beszéljen egymással minden héten az Engineering Manager és a Product Manager? Hívják az architectet is? Ha már cross-functional team, akkor erre jöjjön a marketinges és a UX-es is? Sprintekben dolgozzanak a csapatok, vagy kanbanozzanak? Ha sprintek, akkor összehangolva, vagy sem? 

A kérdések száma itt is szinte végtelen. Ami mellett mi végül letettük a voksunkat, az egy nagyon lightweight, lecsupaszított scrum of scrums működés, beágyazva a PEAK adta keretekbe.

3. Hogyan érjük el, hogy a discovery megfelelően legyen kezelve?

A PEAK módszertan ezt a kérdést azzal zárja rövidre, hogy folyamatosan és iteratívan kell csinálni. Ez teljes mértékben igaz, de ismét jönnek a földhözragadt kérdések: van külön discovery és delivery backlog? Legyenek discovery sprintek, vagy a csapat folyamatosan dolgozzon két szálon? Mikor és kit kell bevonni a discovery folyamatba? Esetleg az egész csapat, a kezdetektől részt vesz benne?

A mi válaszunk a dual track agile lett, amely terén minden negyedévvel egyre jobb és jobb eredményeket érünk el. A megfelelő emberek bevonása csak látszólag egyszerűbb kérdés. Valószínűleg minden cég küzd azzal a problémával, hogy ugyanazokra a kollégákra van szükség discovery közben, akik a delivery területén is elengedhetetlenek a felmerülő problémák megoldásában. Az egyik természetes válasz az, hogy képzésekkel el kell érni, hogy ne mindig ugyanazokat az embereket akarja minden csapat egyszerre elvinni, de ez nem megy egyik napról a másikra. A másik lehetséges megoldás, ami nyugodtan és jó eredményeket hozott, az az aszinkron kollaborációs eszközök (slack, gsuite stb.) hatékony használata, illetve az okosan szervezett megbeszélések, és általánosságban a kiszámíthatóság. 

4. Hogyan bánunk (el) a függőségekkel?

PEAK: A függőségek gonoszok, nem szeretjük őket. Autonóm csapatok kellenek az agilis működéshez, és ha vannak függőségek, azokat kezelni kell.  

Teljesen igaz állítások, de egy valóságos cégben mindig lesznek függőségek. Egy már létező szervezetet nagyon nehéz, ha nem is teljesen lehetetlen, úgy csapatokra osztani, hogy azok teljesen önállóan tudjanak működni. A függőségek operatív kezelésére szintén jó megoldást nyújtott a scrum of scrums, de a problémát meg akartuk fogni a gyökerénél is, és igyekeztünk úgy felosztani a csapatokat, hogy már maga a szervezet is minél inkább magában hordozhassa az autonóm működést.

DOMAIN DRIVEN MŰKÖDÉS, EGY EREDMÉNYES KÍSÉRLET

Amikor a csapatok közötti függőségeket próbáltuk minimalizálni az Adevinta Hungary-nél, akkor több módszerrel próbálkoztunk a csapatok felosztásánál. Természetesen itt is volt a klasszikus projektalapú osztás, ami tud jól működni, de problémás lehet az emberek projektre allokálása (melyik a legmagasabb prioritású a listából, hogyan motiváljuk a kevésbé fontos projekten dolgozó kollégákat stb.). 

Ezután következett a vertikumok szerinti osztás, ami nálunk azt jelentette, hogy volt csapat, aki például az ingatlanos apróhirdetésekért felelt, egy másik az autós hirdetésekért, egy harmadik pedig a generalista részekért és így tovább. Ez már kevésbé volt fájó, üzleti szinten csökkent is a függőség, de technológiai szinten ugyanúgy egymás lábára léptek a csapatok. 

A következő és eddig nagyon jó eredményeket hozó próbálkozásunk a csapatok üzleti domainek szerint felosztása volt, ami bár látszólag képez nagyobb átfedést a vertikumokkal, valójában viszont egy teljesen másik filozófiát vall. Azt az elvet követtük, hogy a jól működő üzleti alkalmazások alapjai az üzleti objektumok, és a való élet kihívásait és feladatait kell leképezni olyan egységekre, amelyek jól körülhatárolt üzleti tulajdonságokat és üzleti logikát tartalmaznak. A kitalálástól a megvalósításig eseménydús út vezetett, de végül a termékmenedzsmenttel karöltve elkészült a domain térkép. Egy talán triviális példa egy domainre és subdomainekre: a hirdetéseket valós, vagy jogi személyekhez kötöttük (ez az üzleti igény), ennek a megvalósításához szükséges az autentikáció, illetve a felhasználói profil mint egy-egy domain, amiken belül a subdomainek például a különböző autentikációs szintek, vagy a felhasználói profil szerkesztése, annak moderációja. Az egyes felhasználók mentett keresései logikailag kapcsolódnak a felhasználói profilhoz, de üzletileg más érdek vezérli őket, más prioritásokkal, így a mentett keresést külön domainként azonosítottuk. Ezeket és a többi hasonló elven azonosított domaint szétosztottuk a csapatok között, figyelve arra, hogy azon domainek, amik üzletileg kéz a kézben járnak (pl. hirdetésfeladás és hirdetésmoderálás) egy csapathoz kerüljenek, egyik csapatot se terheljük túl, és mindegyik csapathoz olyan domain csoportosítás kerüljön, amiket önmagukban fejlesztve valós üzleti értéket lehet szállítani. 

Ezeket olvasva talán még nincs meg a heuréka érzés, ez akkor érkezik meg, amikor a csapatok közötti függőségek száma szemmel láthatóan csökken, egyre kevesebb energia megy el az egyeztetésekkel és különböző fedőnevű sync megbeszélésekkel. A csapatok közvetlenül tudnak hatni akár a céges szintű OKR-ekre is, és a csapat bármely tagja pontosan tudja, hogy hogyan és miként szállítottak értéket a felhasználóknak.

SEMMI SEM VÉGLEGES ÉS SEMMI SEM TÖKÉLETES

A Domain Driven működés nagyon jó eredményeket hozott, de nem mondhatjuk azt, hogy akkor ezt megcsináltuk és hátradőlhetünk, innentől minden megvan. A domain modell rendszeres karbantartást igényel, hiszen az üzlet folyamatosan változik is, az architektúra is hatással van az üzleti objektumokra.

Az eredményes Domain Driven működés egyik fontos pillére a domain mély ismerete mind technológiai, mind üzleti oldalról, tehát a csapattagok gyakori cserélgetése ront a hatékonyságon. Ez hátrány lehet olyan cégnél, ahol a csapatok méretét szinte negyedévente igazítják ahhoz, hogy éppen akkor mi a legfontosabb, viszont előnyt jelenthet ott, ahol konzisztens a tervezés, és a csapat méretéhez szabják a leszállítandók mennyiségét.

JÓ EZ NEKÜNK?

Az őszinte és pontos válasz erre az, hogy „igen, most már jó”. A vezetők és csapatok részéről is kitartás, állhatatosság, rugalmasság, alkalmazkodóképesség, sok próbálkozás, kudarc és újrakezdés kellett ahhoz, hogy eljussunk eddig a pontig. A munkánk azonban még nem ért véget, mindig vannak olyan elemek a működésünkben, amin lehet és érdemes is javítani.

Egy skálázott agilis módszertan bevezetése után az adott cég általában több kérdéssel szembesül, mint amennyi választ kapott. Sem a modell készítői, sem a bevezetést végző csapat nem láthatja előre, hogy a tervezőasztal mellett jól hangzó ötletből mi lesz a mindennapokban, amikor egy cégben, egy kultúrkörben a kollégák elkezdik használni. Az igazi transzformáció és kemény munka a bevezetés után jön, amikor a modellt, a benne szereplő ajánlásokat és a kollégákat is addig kell gyúrni és alakítani, míg a „Ti hogyan dolgoztok?” kérdésre nem egy mély, lemondó sóhajtással kezdődik a válasz, hanem egy mosollyal. 

Ha érdekelnek az Adevinta nyitott állásajánlatai, látogass el a karrier.jofogas.hu oldalra! Android és iOS developerek, backend és frontend fejlesztők, senior CRM managerek és tesztelő mérnökök – lehet, hogy egymást keressük.

[Az Adevinta megbízásából készített, fizetett anyag.]

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról