Előzmény az óraelszámolás nehézségeiről: itt
Amit legtöbb esetben szeretnének megteremteni az óra alapú elszámolással az a transzparencia. Az ügyfél, a vezető és maga a dolgozó is szeretné, ha a munka átláthatóvá válna, ezzel biztosítva az elszámoltathatóságot is. Ha egy munkavállaló ettől retteg és nem az a belső késztetése, hogy minél láthatóbb legyen a teljesítménye, eredményei, amiket elért, akkor gyanús, hogy valójában nem ezt értékeli a rendszer és ő nem motivált, nem büszke az eredményeire. Valamint, ha nem látják és értik egymás haladását a csapattagok, akkor a csapatkohézió, együttműködési készség, csapat teljesítmény is nagyon fejletlen, ami a munkatársi viszonyokra és a légkörre is rányomhatja a bélyegét.
A transzparenciára az agilis munkakörnyezet valóban azt a megoldást kínálja, hogy a lehető legkisebb egységekre daraboljuk fel a munkát. Erre időben fix keretet nyújtanak a sprintek, illetve a napi, heti rendszerességű események, viszont ezek a lehető legszűkebb egységek a tervezést, visszacsatolást hivatottak keretezni. A keretezés célja a gyors és tudatos javítás és optimalizálás, amit az óra szintű és hosszú távú szerződéses keretek gyengíthetnek.
Amit valójában az ügyfél kifizet, az a business value. Azok a funkciók, megoldások, amik az ügyfél számára értéket teremtenek. Ha veszünk egy BMW-t, egy élesztős vagy kovászos kenyeret, egy új hűtőszekrényt vagy egy okos applikációt, az ár/érték arányt sosem a termék elkészítésének ideje alapján ítélem meg, - erről fogalmam sincs, - hanem azok a funkciók adják ki az árat, amik számomra fontosak. Az áru minősége és megbízhatósága pedig szintén különbséget tud tenni egy drágább és egy olcsóbb tárgy vagy akár szolgáltatás között.
Ezeknek az értékeknek, követelményeknek a megvalósítása érdekében a product ownerek user storykat szoktak megfogalmazni, melyek egy-egy tipikus persona, felhasználó egy-egy külön határolható igényét specifikálja. Ezeket a storykat érdemes storypoint-okban mérni, amely a megvalósítás bizonytalanságát, kockázatait, a komplexitását mutatják, valamint azt, hogy milyen mennyiségű munkát kell erre szánni.
A storykat végül a szakértőkből álló csapat kisebb feladatokra osztja, ezzel tervezik meg a megvalósítás hogyanját. Ezek bizonyossága és kiszámíthatósága a munka előrehaladtával arányosan növekszik, de átlátható időintervallumon belül a feleslegessé vált- , valamint az előre nem látott feladatok száma kiegyenlíti egymást. Ezért is ajánlott a tervezést minél kisebb egységekre előre tervezni (sprint). Persze olyan mértékben kell darabolni, hogy az adott idő alatt értékelhető és visszamérhető, tesztelhető működő funkciót tudjon a csapat előállítani és az üzleti értékét lehessen vizsgálni.
Az, ami időben mérhető, az a csapat és az egyének sprintre vonatkozó kapacitása. Ahhoz, hogy minél pontosabban meg tudjuk becsülni, mi fér bele egy sprintbe, ahhoz minél jobban kell ismernünk a konkrét kapacitást és a korábbi teljesítményeket. Az időben való megközelítés leginkább csak a becslésre hasznosítható, a becslés pedig becslés, nem vállalás és nem is elszámoltatható érték. Ezt az számot akár le is törölhetnénk a feladatokról egy sprint betervezése után. Ami miatt érdemes megtartani, az a tanulság és a becslési készségünk fejlődése, ill hogy a sprint közbeni apróbb módosítások időköltségét is jól meg tudjuk ítélni és a meghatározott kereteken belül tudjunk maradni.
Tehát minél nagyobb egységre kívánunk előrejelzést, költségvetést jósolni, annál nagyobb torzulást okozhat a terv előre való lefixálása és az óra szintű megfeleltetés.
A fejlesztés során a fő cél, ami mind az ügyfél, mind a vezető, mind a csapat motiváció legfőbb érdeke, az az üzleti érték (business value) folyamatos növelése és a felesleges tevékenységek kiküszöbölése. Ott, ahol napi rutin a transzparens, kreatív, minőség és érték javító ötletek kivitelezése, ott tud igazán az ügyfél megelégedésére szolgáló brand és az inspiráló, megtartó munkalégkör megszületni.
A fentieknek ellentmondva még mindig a klasszikus, waterfall alapú szerződések mozgatják a gazdaság szálait. És nagyon kevés működő megoldást láttam még arra, hogy az erőforrást és határidőt rögzítik a megállapodáskor, nem pedig a szállítandó funkciók, követelmények végleges és pontos listáját.
Ha a fejlesztés szkópja rugalmas, tárgyalható, a megrendelő és a szállító szorosan és folyamatosan együttműködik, akkor egy ilyen keretrendszer a munka menetével egyre jobban kikristályosodó lehető legoptimálisabb megoldásoknak adhat teret.
Kíváncsi vagyok, van-e valakinek előre mutató tapasztalata a fenti kérdésekben. Várom kommentjeiteket :)
Comments