Egy fejlesztőcsapat feladatai gyakran elhúzódnak – nagyobbnak, komplexebbnek bizonyulnak, mint gondoltuk. Ismerős a mondat: ‘majdnem kész, de… (tetszőleges valós indok)’. És mire észbe kapunk, a projekt nemhogy közelebb nem került a befejezéshez, de egyre mélyebbre süllyed a komplexitásban. Egy szempillantás alatt egy pár órásnak hitt sztoriból hónapokig húzódó szörnyeteg lesz. Mit lehet ilyenkor tenni? A következőkben Hibsch Sándor osztja meg tapasztalatait és tanácsait egy hasonló eset kapcsán – fókuszban a késés kezelése!
Egy jó csapatban nem szeretjük, mikor ilyen történik. Bár hivatkozhatnánk a külső körülményekre, vagy lazíthatnánk a szabályainkon (“nem baj, ha egy sprint alatt nem készül el, majd folytatjuk a következőben”), nem szeretnénk feladni a kontrollt, és ezáltal:
- limitálni jövőbeli opcióinkat – olyan elemeken dolgozni, amik helyett szállíthatnánk értékesebbet
- növelni a kockázatot – határidő előtt két nappal belefutni hasonló szituációba
- rontani a kiszámíthatóságot – csökkenteni az esélyét, hogy mindig egyenletes sebességgel haladunk.
A PROBLÉMA FELTÉRKÉPEZÉSE
Amikor a minap három sprint után végre sikerült lezárni egy eredetileg néhány órásnak gondolt sztorit, úgy döntöttünk, jobban megértjük, mi történt. Az idővonalat felrajzolva észrevettük, hogy nahát, mindig majdnem készen voltunk:
ELSÜLLYEDT KÖLTSÉG – „már annyit dolgoztunk vele, biztos mindjárt kész”
Amikor rávetítettük az idővonalra az implementáció rengeteg elágazását, megértettük, hogyan növekedett észrevétlenül és menedzseletlenül a komplexitás:
A NÖVEKVŐ KOMPLEXITÁS CSAPDÁJA – elágazások és zsákutcák a megoldásban
A HEURISZTIKA* SEGÍT
Az ehhez hasonló sokrétegű, komplex problémák nem adják magukat könnyen. “Minden eset egyedi”, mondjuk, és ez igaz is. Ilyenkor segíthet a heurisztika – a korábbi tapasztalataink alapján megfogalmazott kérdések, melyek tudatos használatával, folyamatunkba való beépítésével fenntarthatjuk a kontrollt a késés felett. Mi ezeket találtuk:
ELŐTTE (TERVEZÉS)
- Mennyire ismerjük a technológiát? Kell-e használnunk ismeretlen technológiát a fejlesztés során?
- Vannak-e függőségek? Kell-e segítség másik csapattól? Függünk-e külső rendszertől?
- Mit mond a zsigeri megérzés? Gyanús a sztori? Volt már hasonló szituáció, mikor gyorsnak gondoltuk és nem lett az?
Ha ezekre a kérdésekre több bizonytalan vagy negatív válasz érkezik, érdemes megállni és újratervezni.
KÖZBEN (IMPLEMENTÁCIÓ ÉS TESZT)
- Hányszor bővült a scope? Ha már harmadszor, megállítjuk a sztorit, spike-olunk (kutatunk, tanulunk)
- Hányszor hangzott el, hogy “ma kész lesz”? A harmadik alkalomnál megállunk. Spike.
- Mennyire fontos, hogy elkészüljön? Paradox, de ha nagy a nyomás, le kell lassítani. Megállunk. Spike.
- Elhangzott, hogy nem lesz több ilyen? Ha igen, megállunk, spike, tudásmegosztás. Mert lesz.
UTÁNA (POST-MORTEM)
- Retrospektív – visszanézünk a sztorira, és megnézzük, mit tanultunk belőle, és legközelebb mit csináljunk másképp.
- Esettanulmány – dokumentáljuk magunknak (és esetleg másoknak), mi történt. Milyen döntéseket hoztunk? Milyen nehézségekbe futottunk bele?
A heurisztikák nem csodafegyverek, de segítenek tudatosítani a késés veszélyeit, mielőtt túl késő lenne. A fentiek nekünk segítettek kiszámíthatóbbá tenni a csapat működését, csökkenteni a csapattagok frusztrációját, és nyitva tartani az opciókat.
Ti mivel bővítenétek a listát?
*A heurisztika olyan gondolkodási módszer, amely segít gyorsan és hatékonyan megoldani problémákat, de nem mindig garantálja a legjobb vagy optimális megoldást. Nem szigorú logikai következtetésekre támaszkodik, hanem tapasztalatokra és próbálkozásokra. Gondolj rá úgy, mint egy rövidített útra, amely elvezet egy elfogadható eredményhez, de nem feltétlenül a legrövidebb vagy legjobb útra.
