Az agilitás se nem varázsszer, se nem szitokszó, hanem a vállalati túlélés egyik záloga. Kicsiben is el lehet kezdeni, jól ötvözhető más fejlesztési és működési modellekkel, de sikeréhez mindenképpen szükség van a korábbi gondolkodás átformálására.
◼︎ Agilitás
Olyan léptékű és sebességű változások történnek körülöttünk, hogy a „business as usual” fogalma halott. Nincs többé olyan, hogy a megszokott medrükben mennek a dolgok, az a cégvezető pedig, aki nem tesz aktívan azért, hogy vállalata képes legyen reagálni az exponenciálisan gyorsulva változó világra, bukásra van ítélve – figyelmeztette a hallgatóságot Földházi Csaba, a Shiwaforce agilitási vezetője.
„Ezért aztán ma már nem elég művelni az agilitást, a teljes szervezetnek agilisnak is kell lennie”, tette hozzá. Ennek egyik fontos eleme a célok folyamatos újragondolása, vagyis az adaptív célrendszer alkalmazása. A szakember szerint a vállalat irányítása is sokkal könnyebbé válik, ha mindenki tisztában van a célokkal, nem csak a közvetlen feladataikat látják. Lényeges a vezetői attitűd, a sikerkritériumok újragondolása is. Nem az az igazi vezetői siker, ha a kollégák végrehajtják a kiadott utasításokat, hanem az, ha az irányítása alatt működő csapatok és egyének önállóan is sikeresen tudnak tevékenykedni. Végül pedig a harmadik nélkülözhetetlen összetevő az egységes adatok alapján történő döntéshozatal. Ha az adatokat minden szervezeti egység külön kezeli, és a maga vélt igazsága alapján hoz döntést, óriási bajok keletkezhetnek a cégnél. Szükség van olyan eszközre, amely vezetői szinten aggregálja az adatokat, és azokból előrejelzéseket is tud adni – így a vezetőség az utat is figyelheti maga előtt, nem csak a visszapillantó tükörből kell kormányoznia.
Félni azonban nem kell az agilitástól: a szervezet agilis átállítása ugyan rögös és hosszú utat jelent, de kicsiben, kis lépésekkel is el lehet kezdeni, mondta végül a Shiwaforce szakértője.
Hibrid modellben
Nem mindig könnyű agilitásról beszélni, mert mindenkinek mást jelent – erre már előadásának címében („Ahány ház, annyi agilitás”) is utalt Fodor Andrea, a Projektcoach Consulting alapító ügyvezetője. A cégvezetés számára leginkább szemléletmód: gyors reagálás a piaci változásokra, értékteremtés, kockázatcsökkentés a működésben. A technológiával foglalkozók számára módszertan, ezért „scrumot” és „kanbant” emlegetnek, és a munka megszervezésében látják a legnagyobb hasznot. A tanácsadókat a szervezeti modell átalakítása fogja meg, a HR-t pedig a munkavállalókra gyakorolt hatás – ők azt várják, hogy mindenki motivált és együttműködő lesz.
Fodor Andrea számára az agilitás annyit jelent „hogy a lehető legrövidebb idő alatt a lehető legmagasabb értéket szállítjuk, megszabadulunk a feleslegestől, nem fordítunk erőforrásokat olyan dolgokra, amelyek senkinek nem jelentenek értéket. Ez azt is jelenti, hogy minden egyes követelményről, minden egyes funkcióról, minden egyes feladatról tudom, hogy az kinek, miért és milyen értéket fog jelenteni”.
A modern nagyvállalat azonban nem feltétlenül tud teljesen agilisan működni – ezeknél általában valamilyen hibrid modellre van szükség. Jó az agilitás, ha kevés az információ, sok a külső bizonytalanság és nincs előre meghatározható végtermék. Ha ennek az ellenkezője igaz – például sok összefüggést, számos külső fél igényeit, követelményeit kell figyelembe venni, a fejlesztéshez szükséges információ elérhető, nagy projektről van szó –, akkor sokkal hasznosabb összefésülni az agilis és a klasszikus terméktervezést, tanácsolta Fodor Andrea.
Tesztelni muszáj
Ma már a mosógéptől a sütőig szinte minden eszközben található számítógép, vagy legalább elektronika. Ebből viszont az is következik, hogy a mai termékek minőségét egyre inkább a szoftver határozza meg – emlékeztetett előadásában Hargitai Zsolt, a TesterLab alapítója.
A szoftverek pedig egyre hosszabbak, bonyolultabbak, nem ritkák a több millió kódsorból álló programok. Ez annyiban aggasztó, hogy az iparági konszenzus szerint minden 10 kódsorban található egy hiba, és hiába a tesztelés, a hibák mintegy 15 százaléka eljut a végfelhasználókhoz, sok száz milliárd dolláros károkat okozva a vállalatoknak, a gazdaságnak. Vagyis a tesztelőknek egyre komplexebb környezetben kell megállniuk a helyüket. Szerencsére vannak módszertanok, amelyek révén kisebb és nagyobb, agilis és nem agilis szervezetekben is kontrollálhatóvá válnak a fejlesztési és tesztelési folyamatok.
„Az a fontos, hogy ezt a döntéshozók is felismerjék”, hangsúlyozta Hargitai Zsolt. Megfelelő szervezéssel, jó módszertanok alkalmazásával úgy lehet csökkenteni a költségeket, hogy közben a szoftverminőség is javul. Szükséges, hogy a stratégiai gondolkodásba épüljön be a minőségbiztosítás, vagyis már a fejlesztési folyamat tervezésekor gondoljanak arra, mit és hogyan fognak tesztelni.
Kell az ügyfél is
Az előadásokat követő panelbeszélgetésen a felhasználói oldalról is érkeztek az észrevételek az agilitásról. Both András, az IdomSoft vezérigazgatója abban az agilitásban hisz, amely szállít is valami értékeset az üzlet és a felhasználók számára. „Ha a felhasználónak nincs szüksége arra, amit kap, akkor mindegy, hogy a fejlesztők milyen gyorsan és milyen módszertan szerint dolgoztak”, mondta. Ezért aztán arra törekednek az általuk végzett államigazgatási fejlesztések során is, hogy már a folyamat elején ismerjék a felhasználók igényeit, problémáját, mert azok amúgy is ritkábban változnak. Később hozzátette: az államigazgatásban már sokszor az is eredménynek számít, ha a megrendelő már néhány havonta működő verzióban láthatja, hol tart a fejlesztése.
A beszélgetés során kiderült az is, hogy nagyon nem mindegy, hogy miként kezd hozzá a szervezet az agilitás megvalósításához. Hargitai Zsolt számos vállalatnál figyelhette meg, hogy a vezetés „nyomja” felülről az agilis működést: ilyenkor mindig nagyobb az ellenállás, mint amikor alulról, organikusan jelenik meg az igény. Mindkettő lehet sikeres, de fontos, hogy kövessék a lefektetett agilis módszertanokat. Rabatin József, a Porsche Finance Group informatikai vezetőjének tapasztalatai szerint nagy hiba, ha egy szervezet csak a módszertant próbálja bevezetni, és nem igyekszik ezzel párhuzamosan a gondolkodásmódot, a kultúrát is megváltoztatni. Náluk akkor lett sikeres a dolog, amikor az utóbbival kezdtek el először foglalkozni.
Hiába dolgozna a szállító agilisan, ha az ügyfelek erre kevésbé kaphatók – világította meg a történet másik oldalát Tresch András, a Quattrosoft ügyvezető igazgatója. Ha valaki egy fejlesztés kapcsán funkcionalitásban, költségkeretben és határidőben gondolkodik, nehéz lesz meggyőzni arról, hogy az indulásnál még nem kell tisztán látni a végeredményt. Segíthet, ha a klasszikus nagy projektet szétszedik pár hónapos szakaszokra – ezzel biztosítható, hogy a végeredmény inkább a végcéllal legyen összhangban, ne pedig az eredeti, gyakran már elavult elképzelésekkel. Fodor Andrea szerint is maximum 3-4 hónapra szabad előre tervezni, mert egy specifikáció annyi idő alatt idejétmúlttá válik.
