Lakásfelújítás VS Agilitás

Már gyűlnek a jegyzeteim a demokrácia VS agilitás posztomhoz, ennek előfutáraként vájkáljunk egy kicsit a melóslélekben, és nézzük meg, hogy egy lakás vagy ház felújítása során milyen szomorú megfigyeléseink lehetnek Agile Coachként. Based on true stories - az esetek és a szereplők nem kitaláltak, a valósággal egyezés szándékos, és megrendelőként üzenem az ezt olvasó, eltűnt melósoknak, hogy nem sértődtem meg, és visszajöhetnek kijavítani az összes elbaszást.

Decentralizált szellőztetést terveztünk a házunkba. Ami annyit tesz, hogy több helyen egy nagy lyukat fúrunk a falba, ami átmegy a teljes falon a szabadba, a lyukba pedig egy csövet rakunk, amiben egy ventillátor pörög, szűrőkkel, így a levegőt beengedve, a hideget és a port pedig kinntartva.

Na, hát hogy is megy ez felhasználóként.

Nézzük a jó kis User Story formátumot: én mint a házamban életvitel szerűen tartozkodó, középkorú de fiatalos háztulajdonos, azt szeretném, hogy valamilyen rendszer folyamatosan keringtesse a levegőt a házban, a hideg és kosz beengedése nélkül, azért, hogy folyamatosan legyen elegendő oxigén a házban, mert az eddigi lakásaimban a légmentesen záró műanyag ablakok okán előálló magas CO2 szint miatt fájt a fejem, könnyen levert lettem, és különben is, az oxigén állítólag egészséges.

Jó, ez egy túl hosszú User Story leírás, de a JIRA Enterprise elbírja.

Nos ehhez képest a valóság azt dobta, hogy mivel itthon nem annyira széles a termékválaszték, ezért külföldről, egy olyan cégtől rendeltük meg a szellőztetőt, akik az installálással nem foglalkoznak.

Pedig az installálás jó közel van a felhasználóhoz.

Az installálás ugyanis, mondjuk a release-eléshez hasonlóan, ebben a példában a legközelebb áll a felhasználó számára értelmezhető értékteremtéshez. Amihez pedig több szakterület tudása, azaz több melós, azaz több squad member kell. Van egy kőműves aki keresztülfúrja a falat és bepurhabozza a szellőztetőt, van egy villanyos aki beköti, és jó esetben van egy burkoló, aki elvégzi az esztétikai simításokat. Végül szereztünk is mindenre egy melóst, viszont valami így is hiányzik:

A melóst nem érdekli a felhasználói élmény.

A melóst, 13 év alatt, 4 ingatlanfelújítás után tapasztalva, csak egy dolog érdekli:

Elvégezni a saját munkáját, oszt jónapot.

Az, hogy amúgy működik-e, vagy azt, hogy úgy működik-e, ahogy a felhasználónak örömet okoz - egyiküket sem érdekli. Soha. Így áll össze a rendszer.

Silós működés.

Egy megtörtént eset ezzel: nem ment az egyik szellőztető, ezért kihívtuk a villanyos arcot, amikor még nem laktunk a házban. Kiment, lejelentette, hogy minden rendeltetésszerű, és hazament. Másnap kimentünk megnézni, és ugyanúgy nem ment a szellőztető. Felhívtuk, mire azt mondta, hogy persze, a szellőztető nem megy. De a villanybekötés jó!

LOL.

Micsoda boldogság felhasználóként, hogy a villanybekötés jó. Ha nem megy a cucc. Én vagyok az idióta, hogy nem örülök. Jó, nem megy a cucc, nem szellőztet, dehát ha egy villanybekötésnek nem tudok örülni, akkor tényleg egy savanyú magyar vagyok. Vagy egy banki online felület példával élve: a hiteligénylés leadó felület nem ad le semmilyen hiteligénylést, de a kód mögötte, na az viszont milyen szépen meg van csinálva!

A fenti esetnél az történt, hogy a kőműves túl sok purhabot rakott a szellőztetető köré, ami egy kicsit összenyomta a szellőztető burkolatát, amitől a ventillátor nem tudott forogni. Azaz nem ment. És ezt a villanyos arc mondta el nekem. Igen, látta hogy össze van nyomva, de az nem a villanyszerelés része. Úgyhogy hazament. Egy elvetemült ötlet:

Akár levághatott volna ő is a purhabból, hogy menjen a cucc.

Dehát ő nem kőműves. Squad példában: hát én nem vagyok tesztelő. Teszteljen a tesztelő! Én szoftverfejlesztő vagyok. És az én kódom kész.

Pí láb növesztés.

Na de, itt egy másik példa: feleségem cége egy kisebb openspace szobában szerette volna az egymáshoz közel ülő kollégák zaját csökkenteni, hogy kevésbé zavarják egymást a munkában, ezért azt gondolták, hangfogó paneleket vesznek az asztalokra. Ezt a felhasználói problémát és az igényt megfogalmazták egy irodaberendezéssel foglalkozó cégnek, akik ezt meghallgatva adtak egy ajánlatot, asztalra szerelhető panelekre, amik megfogják a hangot. Meg is vették, fel is szerelték, és semmit nem használt. Ezért vissza akarták adni a cégnek a paneleket. Akik viszont azt mondták:

Mi adásvétellel foglalkozunk, nem zajmérnökök vagyunk.

Az adásvétel létrejött, feleségem cége aláírta a megrendelőt, az irodaberendezés cég kiszállította. Tehát kérik a pénzt.

A paneleket szállították ki. Nem a megoldást. Azt mi nem szállítunk. Csak termékeket.

És egy hihetetlenül furcsa gondolat volt nekik, hogy mi közük van ahhoz, hogy milyen hang hol, hogy megy, és hogy nem működik. Kár, hogy nem Scrumban dolgoznak. Mert a Scrum nem eszközöket akar gyártatni. Nem feladatokat akar megcsinálni. A Scrum, ha jól van összerakva, akkor User Storykon keresztül problémákra akar megoldást gyártani.

Megoldás szállítás. OMG. Micsoda újító ötlet.

Na de tele vagyok még példákkal. Egy 15 éves kazánt örököltünk meg, amit senki se tud rendesen beprogramozni. És ezzel egyből egy olyan mikro szintre ugrottam, ami számomra érdektelen.

Én meleget szeretnék a házban.

Viszont a kazánhoz a kazános ért, a programozásához a Buderus vagy a Bosch hazai képviseletétől egy darab ember, a radiátorhoz egy másik ember. Így történt az, hogy mindenki megcsinálta a munkáját, ám a végén senki sem tette fel a kérdést:

Amúgy meleg van a lakásban?

Hát nem volt az. Ugyanis senki nem tesztelte le. A rendszer egyben nem működött. Persze régi motorosként senkit sem fizetünk már ki, míg magát a végső működéseket nem teszteljük le.

User Acceptance Test.

Már biztos feltettétek a kérdést: hát miért nem adjátok oda ezt az egészet egy kivitelezőnek?

Jó ötlet.

Ha minden jól működik, akkor a kivitelező lehetne egy vízió nélküli Product Owner. Aki az én víziómat képviseli, és segíti lebontani a projejtet, valamint segít képviselni a víziómat a teljes felújítás alatt, míg a végén én tényleg boldog leszek. Valójában azonban a kivitelezők nagy része maximum csak egy Chapter Lead, vagy egy minden szakterülethez értő csapattag, aki az összes szakterület által elkészülő munkát reviewzza.

De a legtöbb esetben a kivitelezőnek pontosan ugyanúgy eszébe sem jut a felhasználó igénye.

Ő csak fuvarozgatja a melósokat, ha reggel beisznak, akkor kicsit ingatja a fejét, legjobb esetben ha nincs meg a derékszög, akkor észreveszi, és kijavíttatja. És a végén ki jár rosszul megint? Én. A felhasználó. A melósok pedig elvégezték a dolgukat, és őket ugyanúgy ki kell fizetni. Mert ebben a rendszerben a subtaskokért fizetsz. Nem a User Storyért.

De képzeljük ma azt, hogy a kivitelezői szakmának, ha jól végzik, ez a célja - összekötni a felhasználó igényeit a megvalósítással. Jó álmodást a következő felújításotokhoz.

Poszt: Gyulai István