Skillek a csapatokon belül

Több visszajelzést kaptunk a “Scrum versus egyéni fejlődés, karrierút” posztunkra, amiket köszönünk. Ebben a bejegyzésben összeszedtük válszainkat:

Szerző: hrgy

“Csupán annyit jelent, hogy ne az határozza meg, mit csinálunk, hogy mire van emberünk, hanem az, hogy mire van szükségünk az üzleti sikerhez.” Jujj, ezt nagyon gyorsan tisztaba kell tenni, mert eleg nagy gondok szoktak abbol szarmazni, hogy ezt emberek szo szerint veszik, es olyasmiket is bevallalnak projektbe, amire egyaltalan nincs szakertelem a csapatban…

Köszönjük a pontosítást! Az eredeti cikk a csapatban már meglévő skillekről szólt, a teljesen hiányzó tudásról nem szóltunk, bár valóban fontos kérdés. Amennyiben a felmerülő üzleti igények új szaktudást igényelnek, a következő szempontokat szoktuk figyelembe venni:

• Biztosan kényszerítő erejűek a körülmények? Például ha egy java fejlesztőcsapat kap egy feladatot, amit python-ban kell megcsinálni, honnan jön ez az igény és valós-e?

• Ha igen, akkor kérdés, hogy milyen sűrűn várható a jövőben ezt az új tudást igénylő feladat, illetve mennyi a betanulás költsége. Ha a betanulás drága, de ritkán lesz ilyen feladat, egyszerűen nem éri meg – túl nagy lesz az opportunity cost. Ebben az esetben érdemes a feladatot átadni másnak, akár cégen kívül is. De akár, ahogy hrgy a hozzászólása folytatásában írja, a feladat elengedése is opció.

• Ami tovább árnyalhatja a döntést, az az új feladat elvárt minősége. István kedvenc példája, hogy ha egy 2 hétig élő promóciós website-ot fejlesztünk, amin termékvonalkódokat lehet feltölteni és ezzel pólót nyerni, ez egy olyan termék, aminél az elvárt minőségi szint nem feltétlen kell, hogy magas legyen. Rövid életű termék, tehát a továbbfejleszthetőség nem fontos, és valljuk be, nem is olyan kritikus termék, hogy egy-két hibától összedőljön a világ. Ellenben ha egy vakbélműtétet végző robotot programozunk, egészen más az elvárt minőségi szint. Az elsőhöz hasonló esetekben akár még a “pár óra google” utáni összetákolt megoldás is elegendő lehet – csak tisztán kommunikáljuk, mit lehet és mit nem lehet elvárni az elkészült terméktől.

Szerző: tnsnames.ora

Nekem más problémám van a posztbeli üzenettel. Nekem nagyon hiányoznak a számok. Létezik egy valid(?) prekoncepció, hogy gazdaságilag a projekt szempontjából így lehet a legolcsóbb, csak sosem látom hozzá a valós és teljeskörű, pláne projektekre is aggregált visszaméréseket. Számok nélkül ködszurkálás is lehet az egészből: “vagy talált vagy nem”. A projektmódszertanon, megrendelőn, illetve gazdasági lehetőségeken felül vannak egyéb komponensek is a teljes rendszerben: pl:: résztvevő emberek és jövőik. Több lesz-e az ember és jövője avgy sem az ilyen szemlélet mentén? Akar-e, tud-e erre bárki is figyelmet fordítani? Arról nemis beszélve létezhet-e elfogadható optimum, pláne konszenzus, a felmerült szempontok felett?

Személyes tapasztalataink vannak a kérdésekkel kapcsolatban, sajnos publikálható (élő NDA-kat nem sértő) számaink nincsenek. És természetesen nincs is egyértelmű szabály sem, minden helyzet egyedi és átfogó megértést igényel. Vannak viszont konkrét példáink, amik segíthetnek alátámasztani az álláspontunkat

• Az “így lehet a legolcsóbb” mellett fontos szempont az is, hogy így lehet a leggyorsabb. Dolgoztunk olyan, 4 fős termékfejlesztő csapattal, ahol a termék négy modulra volt bontva, és mindegyik modulnak volt egy felelőse; csak ahhoz értett. A Product Owner minden sprint planningen küzdött, mert egyszerűen az üzleti célok és igények nem egyenlő arányban oszlottak el a négy modul között, volt olyan modul, aminek a fejlesztését a következő negyedévben egyáltalán nem tervezték. Természetesen nem akarták elengedni a megbízható fejlesztőt, aki az aktuálisan alacsony prioritású modul felelőse volt; szerencsére a csapat is gyorsan megértette a problémát, nyitott volt a változásra és mindenki megtanult egy másik modult.

• “Résztvevő emberek és jövőik” – A fenti példában ugyanabban az eszközben fejlesztett modulokról van szó. Ilyenkor is felmerülhet az ízlés kérdése – van olyan fejlesztő, aki csak back-endet, vagy csak front-endet szeret fejleszteni. Azokban az esetekben viszont, ahol már más eszköz megtanulása a kérdés, ez még nehezebb lehet. Személyesen ismerünk olyan ex-blackberry fejlesztőt, aki ha annak idején nem lett volna nyitott arra, hogy megtanuljon androidot fejleszteni, most lehet, hogy munkanélküli lenne. Ha elengedjük azt a – szerintünk irreális – célt, hogy mindenki mindenhez értsen, és behelyettesítjük azzal, hogy minél több csapattag minél több dologhoz értsen, akkor tapasztalatunk szerint megfelelően kommunikált célok mentén, a megfelelő körülmények (idő, támogatás, energia) biztosítása esetén a csapattagok nyitottá tudnak válni a tanulásra.

Hisszük, hogy létezhet pillanatnyi optimum, de mivel változó világban élünk, az ideális skill-elosztás is változhat (ahogy az első komment is utal erre). Erre megoldásként mi a skill matrix-ot szoktuk használni:

• összegyűjtjük, hogy milyen technikai és soft skillek szükségesek a csapatban

• minden csapattagnál bejelöljük, mennyire ért az adott témához – saját bevallás alapján, de a csapaton belül szinkronizálva, hogy reális képet kapjunk

Ez alapján látszik, milyen tudás hiányzik, mi az, ami megvan, de kockázatosan kevesen értenek hozzá. Fontos viszont, hogy csak akkor működik a skill matrix, ha rendszeresen – mondjuk negyedévente – frissítjük. Mind az aktuális tudásszinteket, mind pedig a szükséges skill-ek listáját.

Tréningen egy közismert csapatra elkészített skill matrix-szal szoktuk bemutatni az eszközt: