A legtöbb hozzászólás eddig a “Scrum versus egyéni fejlődés, karrierút” postunkhoz érkezett. Köszönjük a hozzászólóknak az aktivitást, mivel az évvégi hajrában elmaradtunk a válaszadással, most hadd reagáljunk komment helyett inkább egy teljes postban.
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:
