Nincs jó ember a piacon!!!

Szerző: | 2018. 12. 18. | Agilis transzformáció az IT-ban

Pár hete beszélgettem egy magyar szoftverfejlesztő cég ügyvezetőjével. Az ügyvezető arról panaszkodott, hogy nem tudnak jó (szak)embereket felvenni a céghez.

„Á, csak jó employer branding kell!” – vághatnák rá sokan manapság, és akkor ugye minden meg lenne oldva.

Hát, sajnos nem.

Mi van a háttérben?

➔ A fenti cég egy középvállalkozás, és egyedi megoldásokat fejlesztenek egy specifikus nagyvállalati szektorban, magyar és nemzetközi környezetben. A nagyobb projektek volumene a százmilliós vagy milliárdos nagyságrendben mozog (forintban).

Az elmúlt években nagy volt a cégnél a fluktuáció: sokan jöttek-mentek. Hogy miért, azzal kapcsolatban bizony több lehetséges okot is meg lehetne nevezni.

Véleményem szerint a fő probléma az, hogy a nagy volumenű projektek óriási stresszt okoznak a szervezetben dolgozók számára. Az ügyvezetőnek magas politikai motivációja van, aminek eredményeképpen egy átlagos vezetőhöz képest sokkal nagyobb felelősséget vállal magára (és a cégére) – ezért is vannak a cégnek nagy megrendelései. Azonban ezt a felelősséget utána a szervezetben tovább is hárítja, ezáltal irányítva a teljes szervezetet. Ez a fajta motiváció nem ritka felső vezetők körében. Ott vannak ugyan a kereszt-funkcionális, szállításképes scrumcsapatok, de a csapatok mellett dolgozó BA-k és PO-k az ügyvezető irányítását közvetítik, így a csapatok csak látszólag autonómok. Az állandó nyomás és az elvárások rátelepszenek a csapatokra.

Sokszor a csapatok csak látszólag autonómok.Az állandó nyomás és az elvárások rájuk telepszenek.

A csapatoknak meghatározott sztoripontokat kell sprintenként szállítaniuk. Sztoripontok alapján vannak az agilis szerződések megkötve, így ezek alapján értékelik a csapatokat és mérik a teljesítményüket is. A csapatok teljesítményét pedig a cégen belül folyamatosan összehasonlítják egymással.

A product backloggal kapcsolatban a csapatoknak nincs sok szavuk, azt a BA/PO állítja elő, sokszor a backlog elemeit is ő tervezi meg, készíti elő. A csapatok feladata csupán az, hogy sprintről sprintre szállítsák a feature-ökhöz tartozó sztoripontokat.

Megértem az ügyvezető helyzetét, hiszen az ő vállára nehezedő óriási tehernek és felelősségnek valamilyen biztosítékot szeretne teremteni a szervezetében. A csapatok teljesítményének mérésével, valaminta BA/PO folyamatos jelenlétével és irányításának köszönhetően a szállításon tarthatja a szemét.

Ennek viszont hatalmas ára van. Az üzleti domain extrém bonyolult, és az azt leképező szoftvermegoldás emiatt szintúgy. (Egy év, mire egy új fejlesztő megérti az üzleti domaint, és fél év, mire produktív munkaerő válik belőle.) A top-down irányítás (CEO – PO/BA – csapat) a csapatok szintjén már csak a végrehajtás kapcsán ad valamennyi mozgásteret. A csapatnak nincs lehetősége challenge-elni a product backlogot, vagy egyszerűsítési törekvéseit, technical debt csökkentési szándékát érvényesíteni. Nem is érti meg őket senki, hiszen ezek mind technológiai dolgok. Ha a csapat már lázad, hogy jelentősen refaktorálni kellene a kódot, akkor a BA/PO/ügyvezető – a korábbi rossz tapasztalatokra hivatkozva amúgy érthetően – ezt a törekvést kritikusan fogadja, és gyakran letöri.

Az eredmény egy irtózatosan bonyolult design, amit senki nem lát át, amiben senki nem dolgozik szívesen, a csapatok pedig belassulnak.

Mi a megoldás?

➔ Egyetlen járható utat látok ilyen esetben, mégpedig a fenntarthatóságra való törekvést: A csapatoknak valódi autonómiát kell kapniuk, a PO/BA-nak üzleti célokat kell hoznia konkrét, sokszor már kidolgozott feature-ök helyett. (Feltételezve, hogy ehhez van egy megfelelő agilis szerződés is a háttérben az ügyféllel.) A csapatnak jelentős beleszólása kell hogy legyen a product backlogba. A csapatoknak csak akkor van lehetőségük az egyszerűsítési törekvéseik és a szakmai érveik érvényesítésére, ha valóban autonóm módon dolgozhatnak.

Mi a garancia arra, hogy minden elkészül időre, és a minőség valóban sokkal jobb lesz?
Erre csak akkor lehet garanciát vállalni, ha az alá-fölé rendeltségi viszony helyett bizalmat sikerül kiépíteni a csapat és a CEO között. Ehhez persze megfelelő emberek, szakemberek is kellenek.

Jelenleg a BA-k/PO-k képezik a hidat a CEO és a csapat között. Azonban ők csak tovább közvetítik a top-down irányítást, hiszen a technológiai részleteket már nem értik. Véleményem szerint a megoldást egy olyan, a csapat által elismert vezető fejlesztő jelentheti, aki képes hidat építeni a csapat és a CEO között, aki képes megfelelően kezelve, tompítani a felülről érkező vezetői nyomást. Ennek a vezető fejlesztőnek kívülről-belülről ismerni kell az üzleti domaint, a technológiát és a csapatot is, továbbá megfelelő empátiával és jó gyakorlati érzékkel is kell rendelkeznie. Nagyon fontos továbbá, hogy a vezető fejlesztő minél kevesebb kontrollt akarjon gyakorolni a csapatán, maradjon maximálisan nyitott, különben az önszerveződés nem fog megtörténni. A BA/PO feladata pedig az marad, hogy segít mindenkinek megérteni az üzleti domaint, az ügyfélelvárásokat és a prioritásokat.

Ha sikerülne a fentről érkező nyomáson tompítani, a csapatok nagyobb önszerveződésre lehetnének képesek.

Két másik példa

➔ Egy másik, immár külföldi ügyfelem hasonló, de mégis más problémával küzd: jelentős a fluktuáció a szervezetben. Egy olyan terméken dolgoznak, amely több kisebb termékből áll. Mindegyik terméken egy-egy csapat dolgozik. Itt még megrendelő sincs, B2C projektről van szó.

A projekt technikai komplexitása ebben az esetben is nagyfokú, de itt más ok miatt. Az üzleti probléma egyszerű (bárki megértheti, előképzettség nélkül is), viszont több százezer felhasználót kell tudni kiszolgálni.

A fluktuáció oka itt a szervezetben (véleményem szerint) az, hogy a technikai megoldás igencsak túlbonyolított. Workaroundok épülnek workaroundokra, ami miatt állandó tűzoltásra kényszerül a szervezet. Az új fejlesztések vagy átalakítások jelentős kockázatot rejtenek magukban, mert sosem lehet tudni, hogy mi fog kilyukadni. Gyakorlatilag ilyen ebben a szervezetben a mindennapi élet, mindenki megszokta már, de attól még ez nagy frusztrációt okoz nap mint nap.

A probléma hátterében véleményem szerint az áll, hogy a PO – az első példához hasonlóan – irányítani próbálja a csapatait. A szakmai érveket, a hosszú távú fenntarthatóságra vonatkozó szempontokat általában lesöpri az asztalról, mindig a legolcsóbb megoldásra törekszik. „Ha pedig később valamiből probléma lesz, akkor majd azt akkor megoldjuk” – ez a filozófiája. Az, hogy miért viselkedik így a PO (nem lehet ezért kizárólag őt hibáztatni), egy másik kérdés, de az tisztán látszik, hogy nem bízik a csapatai szakértelmében. Ennek eredményeként jelentkeznek a workaround megoldások, amik átláthatatlan rendszert, bonyolult folyamatokat, állandó tűzoltási kényszert, és így stresszt okoznak. Ez pedig nagy fluktuációhoz vezet a szervezetben.

Harmadik példaként említeném, hogy a múltkor olvastam egy hazai cikket, amiben arról írtak, hogy a bankoknál azért is nehéz az agilitás bevezetése, mert iszonyatosan fragmentált az informatikai rendszer, amit így senki sem képes átlátni. A bankok arról beszélnek, hogy az alaprendszereket le kellene cserélni, új IT-architektúrára van szükség.

Konklúzió

➔ Onnan indultunk, hogy kevés a jó szakember, és kiderült, hogy a problémát a túlbonyolított rendszerek okozzák, amik úgy kerültek kifejlesztésre, hogy a folyamat során nem tudtak/akartak megbízni a fejlesztőkben. Manapság a fejlesztők nagyon keresettek mindenütt, így könnyen tovább állhatnak egy másik céghez/projekthez, ha már nincs kedvük a lehetetlenül túlbonyolított rendszereken dolgozniuk. A cég/üzlet meg ott marad a rossz rendszereivel, amikhez alig tud új szakembereket felvenni. A fejlesztői béreket már jelentősen nem tudják tovább emelni, és egyébként nem is hiszem, hogy az megoldaná a problémát. Hát akkor mi a megoldás? Nincs megfelelő bizalom a fejlesztők és a management között. Ezen a problémán kellene dolgozni.

Az Agiluu támogatja a szervezeteket, hogy agilisabbá váljanak.

Tetszett az írás? Iratkozz fel a blogra, hogy mindig értesülj az új írásokról!