Sziasztok! A nevem Ljudmila Makarova, fejlesztési menedzser vagyok az UBRD-nél, és a csapatom egyharmada „generalisták”.
Valljuk be: minden Tech Lead keresztfunkcionalitásról álmodik csapatán belül. Nagyon klassz, amikor egy ember képes hármat lecserélni, sőt hatékonyan, határidők elhúzódása nélkül. És ami a legfontosabb, erőforrásokat takarít meg!
Nagyon csábítóan hangzik, de tényleg így van? Próbáljuk meg kitalálni.
Ki ő, az elvárások előfutára?
Az „általános” kifejezés általában azokra a csapattagokra vonatkozik, akik egynél több szerepet töltenek be, például fejlesztő-elemző.
A csapat interakciója és munkájának eredménye a résztvevők szakmai és személyes tulajdonságaitól függ.
A kemény képességekkel kapcsolatban minden világos, de a soft skillek külön figyelmet érdemelnek. Segítenek megtalálni az alkalmazott megközelítését, és arra a feladatra irányítják, ahol a leghasznosabb lesz.
Sok cikk található az IT-ipar mindenféle személyiségtípusáról. Tapasztalataim alapján az informatikai általánosokat négy kategóriába sorolnám:
1. „Univerzális – mindenható”
Ezek mindenhol vannak. Mindig nagyon aktívak, a figyelem középpontjába szeretnének kerülni, állandóan megkérdezik kollégáikat, szükségük van-e a segítségükre, sőt néha idegesítőek is tudnak lenni. Csak az értelmes feladatok érdeklik őket, amelyekben való részvétel teret ad a kreativitásnak és szórakoztathatja büszkeségüket.
Miben erősek:
- képesek összetett problémák megoldására;
- mélyen belemerülni a problémába, „ásni” és eredményeket elérni;
- érdeklődő elméje van.
de:
- érzelmileg labilis;
- rosszul kezelt;
- saját megingathatatlan nézőpontjuk van, amelyet nagyon nehéz megváltoztatni;
- Nehéz rávenni valakit egy egyszerű dologra. A könnyű feladatok bántják a mindenható egóját.
2. „Univerzális – kitalálom és megcsinálom”
Az ilyen embereknek csak egy kézikönyvre és egy kis időre van szükségük - és megoldják a problémát. Általában erős háttérrel rendelkeznek a DevOps terén. Az ilyen generalisták nem foglalkoznak a tervezéssel, és szívesebben alkalmaznak olyan fejlesztési módszert, amely kizárólag a tapasztalataik alapján történik. Könnyen megbeszélést folytathatnak a műszaki vezetővel a feladat végrehajtásának választott lehetőségéről.
Miben erősek:
- független;
- stresszálló;
- számos kérdésben kompetens;
- művelt – mindig van miről beszélni velük.
de:
- gyakran megszegik kötelezettségeiket;
- hajlamosak mindent bonyolítani: oldja meg a szorzótáblát részenkénti integrálással;
- a munka minősége alacsony, minden 2-3 alkalommal működik;
- Folyamatosan tologatják a határidőket, mert a valóságban nem minden olyan egyszerű.
3. „Univerzális – oké, hadd csináljam, mert nincs más”
A munkatárs több területen jártas és releváns tapasztalattal rendelkezik. De egyikben sem sikerül profivá válnia, mert gyakran használják mentőövként, lyukakat tömve be az aktuális feladatokba. Rugalmas, hatékony, igényesnek tartja magát, de nem az.
Praktikus ideális alkalmazott. Valószínűleg van olyan iránya, ami a legjobban tetszik neki, de a kompetenciák összemosódása miatt nem történik fejlődés. Ennek eredményeképpen egy személy azt kockáztatja, hogy igénytelenné válik és érzelmileg kiég.
Miben erősek:
- felelős;
- eredményorientált;
- nyugodt;
- teljesen irányított.
de:
- az alacsony kompetenciaszint miatt átlagos eredményeket mutatni;
- nem tud bonyolult és elvont problémákat megoldani.
4. „A sokoldalú játékos mestere a mesterségének”
Egy komoly fejlesztői múlttal rendelkező ember rendszerszemléletű. Pedáns, igényes önmagával és csapatával szemben. Bármilyen feladat, amely őt érinti, korlátlanul növekedhet, ha nincsenek meghatározva a határok.
Jól ismeri az építészetet, kiválasztja a műszaki megvalósítás módját, alaposan elemezve a választott megoldás hatását a jelenlegi architektúrára. Szerény, nem ambiciózus.
Miben erősek:
- magas színvonalú munkát mutatnak;
- képes bármilyen probléma megoldására;
- nagyon hatékony.
de:
- intoleráns mások véleményével szemben;
- maximalisták. Igyekeznek mindent jól csinálni, és ez megnöveli a fejlesztési időt.
Mi van a gyakorlatban?
Lássuk, hogyan kombinálódnak leggyakrabban a szerepek és a kompetenciák. Vegyünk kiindulópontnak egy szabványos fejlesztőcsapatot: PO, fejlesztési vezető (tech vezető), elemzők, programozók, tesztelők. Nem vesszük figyelembe a termék tulajdonosát és a műszaki vezetőt. Az első a technikai kompetenciák hiánya miatt. A második, ha problémák vannak a csapatban, mindenre képes.
A kompetenciák kombinálására/egyesítésére/egyesítésére a leggyakoribb lehetőség a fejlesztő-elemző. A tesztelő elemző és a „három az egyben” is nagyon gyakori.
Példaként a csapatomat felhasználva bemutatom általánosító társaim előnyeit és hátrányait. Harmaduk van a csapatomban, és nagyon szeretem őket.
A PO sürgős feladatot kapott, hogy új tarifákat vezessenek be egy meglévő termékbe. A csapatomnak 4 elemzője van. Ekkor az egyik nyaralt, a másik beteg, a többiek pedig stratégiai feladatok végrehajtásával foglalkoztak. Ha kihúznám őket, az elkerülhetetlenül megzavarná a megvalósítási határidőket. Csak egy kiút volt: a „titkos fegyver” használata - egy sokoldalú fejlesztő-elemző, aki elsajátította a szükséges témakört. Nevezzük Anatolijnak.
A személyiségtípusa az „univerzális – kitalálom és megcsinálom”. Természetesen sokáig próbálta magyarázni, hogy „teljes lemaradása van a feladatainak”, de határozott döntésemre egy sürgős probléma megoldására küldték. És Anatolij megcsinálta! A kivitelezést és a kivitelezést határidőre elvégezte, a megrendelők elégedettek voltak.
Első pillantásra minden sikerült. Néhány hét elteltével azonban ismét felmerültek a fejlesztési követelmények ennél a terméknél. Most ennek a problémának a megfogalmazását egy „tiszta” elemző végezte. Az új fejlesztés tesztelési szakaszában sokáig nem értettük, miért hibázunk az új tarifák összekapcsolásakor, és csak ezután, a teljes szövevény feltárásával jutottunk az igazság mélyére. Rengeteg időt vesztegettünk, és elmulasztottuk a határidőket.
A probléma az volt, hogy sok rejtett pillanat és buktató csak a kombi fejében maradt, és nem került át papírra. Ahogy Anatolij később elmagyarázta, túlságosan sietett. De a legvalószínűbb lehetőség az, hogy már a fejlesztés során találkozott problémákkal, és egyszerűen megkerülte azokat anélkül, hogy ezt sehol tükrözte volna.
Volt egy másik helyzet is. Most már csak egy tesztelőnk van, így egyes feladatokat elemzőknek kell tesztelniük, beleértve a generalistákat is. Ezért egy feladatot adtam a feltételes Fedornak - „univerzális – oké, hadd csináljam, mert nincs más”.
A Fedor egy „három az egyben”, de erre a feladatra már kijelöltek egy fejlesztőt. Ez azt jelenti, hogy Fedyának csak egy elemzőt és egy tesztelőt kellett kombinálnia.
A követelmények összegyűjtve, a specifikáció fejlesztésre került, ideje tesztelni. Fedor „mint a tenyerét” ismeri a módosítandó rendszert, és alaposan kidolgozta a jelenlegi követelményeket. Ezért nem foglalkozott tesztszkriptek írásával, hanem tesztelte, hogy „hogyan működjön a rendszer”, majd továbbadta a felhasználóknak.
A teszt befejeződött, a revízió gyártásba került. Később kiderült, hogy a rendszer nemcsak bizonyos egyenlegszámlákra történő kifizetéseket függesztette fel, hanem nagyon ritka belső számlákról is letiltotta a kifizetéseket, amelyeknek ebben nem kellett volna részt venniük.
Ez annak köszönhető, hogy a Fedor nem ellenőrizte, hogyan „ne működjön a rendszer”, nem készített teszttervet vagy ellenőrző listákat. Úgy döntött, spórol az időzítésen, és saját ösztöneire hagyatkozik.
Hogyan kezeljük a problémákat?
Az ehhez hasonló helyzetek hatással vannak a csapat teljesítményére, a kiadás minőségére és az ügyfelek elégedettségére. Ezért nem maradhatnak odafigyelés és az okok elemzése nélkül.
1. Minden nehézséget okozó feladathoz kérem, hogy töltsön ki egy egységes űrlapot: hibatérképet, amely lehetővé teszi, hogy azonosítsa a „leállás” szakaszát:
2. A szűk keresztmetszetek azonosítása után ötletbörze kerül megrendezésre minden olyan alkalmazottal, aki befolyásolta a problémát: „Mit változtassunk?” (speciális eseteket utólag nem veszünk figyelembe), aminek eredményeként konkrét cselekvések születnek (személyiségtípusonként sajátosan) határidőkkel.
3. Szabályokat vezettünk be a csapaton belüli interakcióra. Például megállapodtunk abban, hogy a feladat előrehaladásáról minden információt feltétlenül rögzítünk a projektmenedzsment rendszerben. Ha a fejlesztési folyamat során a műtermékeket megváltoztatják/azonosítják, ennek tükröződnie kell a tudásbázisban és a műszaki specifikáció végleges változatában.
4. Az ellenőrzést minden szakaszban elkezdték végrehajtani (különös figyelmet fordítanak a múltbeli problémás szakaszokra), és automatikusan a következő feladat eredményei alapján.
5. Ha a következő feladatnál nem változott az eredmény, akkor a kérdéses generalistát nem teszem abba a szerepbe, amelyben rosszul birkózik meg. Igyekszem felmérni képességét és vágyát a kompetenciák fejlesztésére ebben a szerepkörben. Ha nem találok választ, abban a szerepben hagyom, ami közelebb áll hozzá.
Mi történt a végén?
A fejlesztési folyamat átláthatóbbá vált. A BUS-tényező csökkent. A hibákon dolgozó csapattagok motiváltabbá válnak, és javítják karmájukat. Kiadásaink minőségét fokozatosan javítjuk.
Álláspontja
A generalista alkalmazottaknak megvannak az előnyei és hátrányai.
Előnyök:
- bármikor bezárhat egy megereszkedett feladatot, vagy rövid időn belül megoldhat egy sürgős hibát;
- a probléma megoldásának integrált megközelítése: az előadó minden szerep szemszögéből néz rá;
- a generalisták szinte mindent egyformán jól tudnak csinálni.
Hátrányok:
- BUSZ-tényező nő;
- a szerepben rejlő alapvető kompetenciák erodálódnak. Emiatt csökken a munka minősége;
- a határidők eltolódásának valószínűsége nő, mert nincs ellenőrzés minden szakaszban. A „sztár” növekedésének kockázatai is vannak: a munkavállaló biztos abban, hogy jobban tudja, hogy profi;
- nő a szakmai kiégés kockázata;
- a projektről sok fontos információ csak a munkavállaló „fejében” maradhat meg.
Mint látható, több hiányosság is van. Ezért csak akkor használok generalistákat, ha nincs elég forrás, és elég sürgős a feladat. Vagy az embernek vannak olyan kompetenciái, amelyek másoknak hiányoznak, de a minőség a tét.
Ha egy feladat közös munkája során betartjuk a szerepek elosztásának szabályát, akkor a munka minősége javul. Különböző oldalról nézzük a problémákat, nem homályos a látásmódunk, mindig friss gondolatok jelennek meg. Ugyanakkor minden csapattagnak minden lehetősége megvan a szakmai fejlődésre és kompetenciáinak bővítésére.
Úgy gondolom, hogy a legfontosabb, hogy érezze magát a folyamatban, végezze a munkáját, fokozatosan növelve a kompetenciáit. Azonban a generalisták egy csapatban előnyöket hoznak: a lényeg az, hogy hatékonyan kombinálják a különböző szerepeket.
Mindenkinek önszerveződő csapatot kívánok „mesterségük egyetemes mestereiből”!
Forrás: will.com