Avagy mi kell ahhoz, hogy a beszállítód / alvállalkozód nettó üzleti előnyt jelentsen. Csak.
A probléma
Több cégtulajdonossal beszélgetve az az általános fájó pont jött vissza a szoftverfejlesztési projektek kiszervezéséről, hogy az alvállalkozót vagy a beszállítót rengeteget kell szoros kézzel menedzselni. Ez a kényszerű mikromenedzsment elképesztő mennyiségű értékes stratégiai erőforrást emészt fel. Ennek oka, hogy a megrendelő felé a fővállalkozó renoméja van az asztalon, és probléma esetén a fővállalkozó az, akit első körben meg is kötbéreznek. Márpedig a szoftverfejlesztési projektek jelentős részében borítékolható a szállítási nehézségek garmadája.
A probléma másik fele, hogy, érthető okokból, senki nem szeret harmadik vagy negyedik prioritás lenni. Amíg a beszállítónak több ügyfele van, és nem követi az Agile Delivery Team szemléletét, ez mindig bajok forrása lesz .
Az a fővállalkozó, aki kiszervezi a projektet, feltételezhető, hogy olyan problémás helyzetben van, ami miatt ezt kénytelen volt megtenni. Egy ilyen állapotban harmadik vagy negyedik prioritásnak lenni kiszolgáltatott érzés.
Ha mint fővállalkozó problémám lesz és a beszállítóm másik ügyfelének is egyidejűleg van problémája (mindig lesz ilyen), akkor a beszállítóm csak akkor fog az én problémámmal foglalkozni, ha az neki a nagyobb üzleti előnyt jelenti. Ezzel kialakul egy megnyerhetetlen játék: láthatatlan felek folyamatos vak licitje senki érdekét nem szolgálja.
Az Agile Delivery Team válasza
Egy jól működtetett Agile Delivery Team-et (továbbiakban ADT) nem kell mikromenedzselni. Miattuk egy fővállalkozót üzleti hátrány vagy presztízsveszteség nem érhet. Hogyan érjük el?
Minden ADT a fejlesztők mellett három további szereplővel rendelkezik. A Scrum Master / Agile Coach, az automatizált tesztmérnök és a Product Owner.
Pár mondatban fussunk át a szereplőkön és utána jöhet a megoldás.
Scrum Master / Agile Coach
A Scrum Master az, aki a transzparens működést képes biztositani, fenntartani és erről kellő hitelességgel kommunikálni.
Ő mozgatja és képzi a szereplőket a módszertani elemek sajátosságai szerint. A megbízó és a szállító csapat közötti kommunikációt és információáramlást működteti és fejleszti.
Automata-teszt mérnök
Az automata-teszt mérnök a kulcs, hogy egy Agile Delivery Team (ADT) csak és kizárólag kiváló minőségű működő szoftverterméket adjon át.
Ha a csapat a módszertan által megkövetelt transzparencia és szakmai kiválóság szerint szállít, feleslegessé válik a mikromenedzsment.
Az automata-teszt mérnök az, aki az öt tervezési szinthez tartozó automatizált tesztelési megoldásokat működtetni, tanítani és fejleszteni képes.
Nem a tesztmérnök kizárólagos feladata a tesztek megírása. Az a csapat felelőssége. A teszmérnöknek az a dolga, hogy a csapatot a lehető legalkalmasabbá tegye mind az öt tervezési szinten értelmezhető tesztek megírására.
Product Owner
A csapat mellé rendelt Product Owner az üzleti logikáért, a backlog építéséért és a szereplők motiválásáért felelős. Hogy ki adja a Product Ownert másodlagos kérdés, ha amúgy kellően hiteles személy ahhoz, hogy a megrendelő, a megbízó és a szállító is elismerje, és bízzanak benne annyira, hogy döntéseket hozhasson a projektben. Így a csapat nem szenved el várakozási veszteséget, ha kérdéseik vannak. Márpedig lesznek.
Bízz, bízz de sűrűn ellenőrizz!
Természetesen fontos, hogy ellenőrizve legyenek a csapatok. Azonban az ellenőrzés és mikromenedzselés között nagyon sok millió forintnyi jobban is elkölthető erőforrás a különbség.
Egyetlen Agile Delivery Teamnek sem sérelmes, ha rendszeresen ellenőrzik. Sőt! Igényli ezt, hisz csak így lehet érdemi visszajelzések alapján folyamatosan korrigálni és javítani a szállítás minőségén.
Sok szoftverfejlesztő beszállítónál van meg az a rendkívül hibás reflex, hogy privát boszorkánykonyhának tekintik a fejlesztést, ami miatt szükségtelen zaklatásnak élik meg a számonkérést, ellenőrzést, érdeklődő kérdéseket. Nem egyszer láttam már, hogy egy beszállító cég az erőforrásaival játszik, és amíg elvállal egy munkát, addig ugyanazon a projekten ugyanazok az emberek egyéb szoftverfejlesztéseket is csinálnak. Így gyakorlatilag minden megrendelő a saját szoftverén túl a többiekét is finanszírozza. A megrendelők ismerik ezt a játékot. És őszintén értem, hogy miért nincs kedvük belemenni.
Egy Agile Delivery Team mindig dedikált! Azaz egy ADT mindig egy és csak egy megbízónak dolgozik! Ezen belül is, ritka kivételtől eltekintve, egyszerre egy projekten. Nincsenek játékok, csak folyamatos értékszállítás.
Dedikált csapat
Nem lehet eleget hangsúlyozni: egy ADT szállító csapat mindig dedikált. Azaz egy ügyfele van. Ez akkor lehetséges, ha a megbízó projektje alkalmas arra, hogy kiszervezhető legyen egy agile teamnek.
Ha a projekt kiforratlan és/vagy a szükséges szereplők rendelkezésre állása és hozzáférhetősége kétséges, akkor a projekt valójában egy tessék-lássék munka tud csak lenni. Bárki is vállalja.
Úgy kell tudni projektet előkészíteni hogy az egy Agile Delivery Teamnek átadható legyen. Igaz ez akkor is, ha nem ADT csinálja!
Kommunikációs lánc
A megbízó-beszállító kapcsolatát hétköznapi viszonyok között a bizalmatlanság jellemzi. Ezért a beszállító csapat nem kerül közvetlen kapcsolatba a megbízó ügyfelével. De legalábbis ez a lehetőség mesterségesen “hűtve” van. Mennyire más lenne a helyzet, ha a megbízó nyíltan büszke lehetne arra, hogy milyen beszállítója van!
Amíg azonban ezt az állapotot elérik, a beszállítónak gyakorlatilag csak közvetett hozzáférése van ahhoz az üzleti tudáshoz, ami a projekthez kell(ene). Mesterségesen lassítja az alvállalkozót ha a fővállalkozó úgy érzi, hogy be kell iktatni a rendszerbe még egy kommunikációs állomást. Ne tegyük!
A Bizalom eléréséhez a transzparencia a kulcs
Ahhoz hogy ezen az alapvető bizalmi válságon átlendüljünk, még a személyes kapcsolatokon nyugvó megbízói- beszállítói kapcsolat is kevés. Elengedhetetlen, de semmiképpen sem elegendő. Az az állapot a cél, amikor a beszállítói csapat tud agile értelemben transzparens lenni.
Ennek első feltétele, hogy nem szabad elvállalni olyan projektet ami nem alkalmas arra, hogy transzparens működés mellett szállítható legyen. Ha még nem olvastad “Backlog vs Specifikáció” és “Agile Tervezés 5 szintje” blogcikkeinket, a jobb megértés érdekében ez egy remek alkalom.
Az Agile Delivery Team kellő transzparencia mellett akkor működtethető, ha a benne levő szereplők a helyükön vannak, rendelkeznek azzal a tudással, hozzáféréssel és döntési jogkörrel ami ahhoz kell, hogy az egyes tervezési szinteken meg lehessen lépni azt, amit az Agile Tervezés 5 szintje megkövetel (lásd blogcikk).
A transzparencia működtetése
Hiába van egy agile szállításra alkalmas projektem, ha a csapat maga nem transzparens. Különösen 3rd party fejlesztéseknél fontos, hogy a teljes agile transzparencia állapotában dolgozzon a csapat. Ez azt jelenti, hogy a csapatról bármikor, bármelyik időpillanatban megállapítható, hogy éppen min dolgozik, hol tart vele, mikor lesz kész, mikor lesznek a különböző módszertani események, mik azok, amik hátráltatják a szállítást.
Beszéltünk arról hogy egy agile csapat mindenképpen dedikált, tehát együgyfeles csapatokról van szó. Ha a csapatnak korábbról hozott support feladatai is vannak, (ilyen előfordulhat) akkor azt nem szabad a véka alá rejteni. Pontosan meg kell mondani a megbízónak hogy a csapatnak milyen kontingens van supportra félretéve. Ez azt jelenti, hogy supportra dedikált kontingensnél többet a csapat semmiképp sem költ!
Ha a csapat követte az agile módszertant a korábbi szállításoknál, akkor ez eleve nem kérdés: hibajavítási support igen ritka.
Preferáljuk azokat a beszállítókat, akik értik és művelik az agile módszertan szerinti szállítást. Mindannyian jobban járunk vele!
A Transzparencia forrásai
SOR azaz a “Spent”, “Original” és “Remaining” idők kezelése.
Original – az ADT által valamilyen idő mértékegységben a feladat tényleges megkezdése pillanatáig megadott becslés
Spent – az az idő- és erőforrásmennyiség, amit a csapat eddig a feladatra elköltött
Remaining – Egy adott időpillanatban a csapat által az eddig elköltött erőforrások és eddigi előrehaladás függvényében adott becslés a feladatból még hátralévő erőforrás szükségletre
A SOR-t úgy működtetjük, hogy folyamatosan láttatjuk a megbízónál. Tehát kérünk egy tévét, jó nagyot, ahova kamerával folyamatosan közvetítjük a beszállítói csapat Kanban tábláját.
A megbízót meg kell tanítani értelmezni a Kanban táblát. Ezzel a transzparencia alap lépését meg is tettük.
.
A következő fejezet a folyamatos Demózás.
Elengedhetetlen annak az infrastruktúrának a felépítése és hibátlan működtetése ami ahhoz kell, hogy folyamatosan, működés közben vizsgálhatjuk a definition of done szerint elkészült elemeket és a megbízó lássa, hogy átadható, potenciálisan élesíthető kész terméket fejleszt az ADT minden iterációban (általában kéthetes intervallumot jelent).
Nagy feladatnak tűnik, de az agile tervezés öt szintjének a működtetésével relatív olcsón és kellő pontossággal elérhető állapot.
Minél messzebb van az ügyfél, érdemes annál sűrűbben Demózni. Abban a pillanatban, hogy valamit a csapat késznek gondol, gondoskodni kell az élesíthetőségéről.
Végül
A megbízó-beszállító kapcsolat problémáit, különösen szoftverfejlesztési projektekben, amik kifejezetten magas kockázatúnak számítanak, egytől-egyig, a transzparencia, a minőségbiztosítás és a folyamatos, meggyőző értékszállítás tudja csak kezelni. Az, hogy így lehessen dolgozni azon múlik, hogy a megbízó és beszállító módszertani felkészültsége és közös üzleti akarata adott-e.
Amíg a módszertani tudás behozható kívülről, a közös üzleti akaratnak belülről kell fakadnia. A kettő csak együtt képes eredményt hozni.
A nap végén mindig csak a működő késztermék számít valójában!
