Mindenki üdvözöl! A nevem Ljudmila Makarova, az UBRiR fejlesztési menedzsere vagyok, és a csapatom harmada – „univerzális” személy.
Ismerjük el: minden Tech Lead arról álmodik, hogy a csapatán belül keresztfunkcionális legyen. Hiszen mennyire klassz, amikor egy ember képes hármat helyettesíteni, ráadásul ezt minőségben is megtenni, anélkül hogy csúszna a határidő. És ami nagyon fontos, ezzel erőforrásokat takarít meg!
Csábítóan hangzik, de vajon tényleg így van? Próbáljuk meg kideríteni.
Ki is ő, a várakozásainkat felülmúló személy?
Az „univerzális” kifejezés alatt általában olyan csapattagokat értünk, akik egyidejűleg több szerepet is betöltenek, például fejlesztő-analitikust.
A csapat együttműködése és a munkájuk eredménye függ a tagok szakmai és személyes tulajdonságaitól.
A hard skillek világosak, de a soft skillek külön figyelmet érdemelnek. Ezek segítenek megtalálni a megfelelő megközelítést a munkavállalóhoz, és irányítani őt a feladatra, ahol maximálisan hasznos lehet.
Sok cikk létezik az IT-ipar különféle személyiségtípusairól. A tapasztalatom alapján négy kategóriába sorolnám az IT-univerzálisokat:
1. „Univerzális – mindenható”
Ilyenek mindenhol előfordulnak. Mindig aktívan részt vesznek, a figyelem középpontjában akarnak lenni, folyamatosan érdeklődnek kollégáiknál, szükségük van-e segítségükre, néha még irritálóak is lehetnek. Csak a jelentős feladatok érdeklik őket, amelyek lehetőséget adnak a kreativitásra és táplálhatják az önérzetüket.
Miben erősek:
- képesek összetett feladatok megoldására;
- mélyen belemerülnek a problémába, „ásnak” és elérik az eredményt;
- kérdő szellemmel rendelkeznek.
De:
- érzelmileg labilisak;
- nehéz őket irányítani;
- van egy megváltoztathatatlan véleményük, amelyet nagyon nehéz megváltoztatni;
- nehéz őket rábírni egy egyszerű feladat elvégzésére. Az egyszerű feladatok sértik a mindenhatóak önérzetét.
2. „Univerzális – megoldom és elkészítem”
Ezeknek az embereknek elegendő egy kézikönyv és egy kis idő – és megoldják a kérdést. Általában jelentős DevOps háttérrel rendelkeznek. Ezek az univerzálisok nem terhelik magukat a tervezéssel, és inkább a saját tapasztalataikra alapozva dolgoznak. Könnyedén összecsaphatnak a tech lead-del a feladat megvalósításának választott módja miatt.
Miben erősek:
- önállóak;
- stresszállóak;
- sok ügyben kompetensek;
- Ismertek – mindig van miről beszélni velük.
De:
- Gyakran megszegik a kötelezettségeket;
- Mindent bonyolítaniuk kell: a szorzótáblát részletek szerint integrálják;
- A munka minősége alacsony, mindent 2-3 próbálkozással sikerül megoldani;
- Folyamatosan tolják a határidőket, mert valójában minden nem olyan egyszerű.
3. „Egyetemes – rendben, vállalom, ha más nem tudja”
A munkatárs jól ért több területhez és van megfelelő tapasztalata. De nem sikerül szakértővé válnia egyetlen területen sem, mert gyakran mentőövként használják a folyamatban lévő feladatok ellátására. Alkalmazkodó, megbízható, úgy érzi, igénylik, bár valójában nem az.
Gyakorlatilag tökéletes alkalmazott. Valószínű, hogy van egy irány, ami jobban tetszik neki, de a kompetenciák elmosódása miatt nem fejlődik. Ennek eredményeként az ember veszélybe kerülhet, hogy nem talál munkát és emocionálisan kiég.
Miben erősek:
- felelős;
- eredményorientáltak;
- nyugodtak;
- teljes mértékben kontrollálhatóak.
De:
- Közepes eredményeket mutatnak a kompetenciák alacsony szintje miatt;
- Nem képesek bonyolult és elvont feladatokat megoldani.
4. „Egyetemes – mester a szakmájában”
Ember komoly fejlesztői háttérrel, rendszerszemlélettel rendelkezik. Precíz, és követelményeket támaszt magával és a csapattal szemben. Bármilyen feladat, amiben részt vesz, végtelenül elhúzódhat, ha nem jelölik ki a határokat.
Jól ismeri az architektúrát, megválasztja a technikai megvalósítás módszerét, alaposan elemzi a választott megoldás hatását a jelenlegi architektúrára. Modest, nem ambiciózus.
Miben erősek:
- Magas munkaminőséget mutatnak;
- Bármilyen feladatot képesek megoldani;
- Nagyon szorgalmasak.
De:
- Nem tolerálják mások véleményét;
- maximalisták. Mindent helyesen próbálnak megcsinálni, ami meghosszabbítja a fejlesztési időt.
Mit tapasztalunk a gyakorlatban?
Nézzük meg, hogyan egyesülnek a szerepek és kompetenciák a leggyakrabban. Kiindulási pontként vegyük egy tipikus fejlesztőcsapatot: PO, fejlesztési menedzser (techlead), elemzők, programozók, tesztelők. A termék tulajdonosát és a techleadet nem számítjuk. Az elsőt, mert nincs technikai kompetenciája. A másodiknak, ha a csapatnak problémái vannak, éppen tudnia kell mindent csinálni.
A leggyakoribb kompetenciák kombinálásának / összevonásának / egyesítésének módja a fejlesztő-analitikus. Nagyon gyakran előfordul az analitikus-tesztelő és a „három az egyben” is.
Csapatom példáján megmutatom, mik a univerzális kollégák előnyei és hátrányai. A csapatomban egyharmaduk van, és nagyon kedvelem őket.
A PO sürgős feladatot adott az új díjak bevezetésére a meglévő termékbe. A csapatomban négy analitikus dolgozik. Abban az időben az egyik szabadságon volt, a másik megbetegedett, a többiek pedig stratégiai feladatokkal foglalkoztak. Ha kirántom őket, az elkerülhetetlenül megbízhatatlan időkereteket eredményezett volna. Az egyetlen megoldás maradt: használni a „titkos fegyvert” – a világmegváltó fejlesztő-analitikust, aki rendelkezett a szükséges szakterületi tudással. Hívjuk őt Anatolijnak.
Az ő személyiségtípusa – „univerzális – megértem és megoldom”. Természetesen sokáig próbálta magyarázni, hogy neki „teljes a backlogja”, de az én akaratommal sürgős feladat megoldására küldtem. Anatolij sikerrel járt! Megfogalmazta a feladatot, és a határidőn belül megvalósította, az ügyfelek pedig elégedettek voltak.
Első pillantásra minden rendben ment. De néhány hét elteltével ezen a terméken újabb fejlesztési követelmények merültek fel. Most már a „tiszta” analitikus foglalkozott a feladat megfogalmazásával. Az új fejlesztés tesztelési fázisában sokáig nem értettük, miért lépnek fel hibák az új díjak hozzárendelésénél, és csak később, amikor kibogoztuk az egészet, jöttünk rá az igazságra. Rengeteg időt vesztegettünk, és túlléptük a határidőket.
A probléma az volt, hogy sok rejtett pillanat és buktató csak univerzális kollégánk fejében maradt, és nem került papírra. Ahogy később Anatolij magyarázta, túl sietett. De a legvalószínűbb, hogy a fejlesztés során találkozott a problémákkal, és egyszerűen elkerülte őket, ezeket sehol nem tükrözve.
Volt egy másik helyzet is. Jelenleg csak egy tesztelőnk van, ezért egyes feladatokat az analitikusoknak, így az univerzálisoknak is tesztelniük kell. Ezért egy feladatot átadtam a hipotetikus Fjodor – „univerzális – rendben, csinálom, mivel más nem tudja”.
Fjodor „három az egyben”, de ehhez a feladathoz már kijelöltek egy fejlesztőt. Tehát Fjodor feladata az volt, hogy ötvözze magában az analitikus és a tesztelő szerepét.
A követelmények összegyűjtésre kerültek, a specifikáció átkerült a fejlesztésbe, és itt az ideje a tesztelésnek. Fedor a módosítandó rendszert „mint a tenyerét” ismeri, és alaposan kidolgozta a jelenlegi követelményeket. Ezért nem vette a fáradságot tesztforgatókönyvek írására, hanem a rendszer „hogyan kell működnie” tesztelését végezte el, majd átadta a felhasználóknak.
A teszt befejeződött, a módosítás átkerült a termelésbe. Később kiderült, hogy a rendszer nemcsak a bizonyos egyenlegű számlákra történő kifizetések végrehajtását állítja le, hanem blokkolja a nagyon ritka belső számlákról történő kifizetéseket is, amelyek nem kellett volna részt vegyenek ebben.
Ez azért történt, mert Fedor nem ellenőrizte, hogy a rendszer „hogyan nem működik”, nem készített teszttervet, ellenőrzőlistákat. A határidők megtakarítása érdekében a saját megérzésére támaszkodott.
Hogyan kezeljük a problémákat?
Az ilyen helyzetek hatással vannak a csapat munkájának hatékonyságára, a kiadott verziók minőségére és az ügyfelek elégedettségére. Ezért ezeket nem szabad figyelmen kívül hagyni, és meg kell vizsgálni az okokat.
1. Minden olyan feladathoz, amely komplikációt okozott, kérlek töltsd ki az egységes űrlapot: hibakártyát, amely lehetővé teszi a „leszívás” szakaszának megállapítását:
2. A szűk keresztmetszetek azonosítása után minden érintett munkatárssal agytornát tartunk „Mit kell megváltoztatni?” (a különleges eseteket nem tárgyaljuk a retrospektíván), aminek végén konkrét lépések születnek (személyiségtípusonként eltérően) határidőkkel.
3. Bevezettük a csapaton belüli interakciós szabályokat. Például megállapodtunk abban, hogy minden feladatról rögzíteni kell az információkat a projektmenedzsment rendszerben. A fejlesztési folyamat során bekövetkezett módosításokat/artefaktumokat rögzíteni kell a tudásbázisban és a végső műszaki specifikációban.
4. A kontroll minden szakaszban zajlik (főleg a múlt problémás szakaszaira figyelünk), és automatikusan a következő feladat teljesítési eredményei alapján.
5. Ha a következő feladat eredménye nem változott, akkor a megvizsgált univerzális személyt nem helyezem abba a szerepbe, amellyel nem boldogul. Próbálom értékelni a képességét és a fejlődési vágyát ebben a szerepben. Ha nem érzékelek visszhangot, akkor abban a szerepben hagyom, ami közelebb áll hozzá.
Mi lett végül az eredmény?
A fejlesztési folyamat átláthatóbbá vált. Csökkent a BUS-faktor. A csapattagok, miközben a hibákon dolgoznak, motiváltabbá válnak, javítják a karmajukat. Fokozatosan növeljük a kiadásaink minőségét.
Következtetések
Az univerzális munkatársaknak megvannak a maguk előnyei és hátrányai.
Előnyök:
- bármikor lezárhatjuk a megakadt feladatot, vagy gyorsan megoldhatjuk a sürgős hibát;
- komplex megközelítés a feladat megoldásában: a végrehajtó minden szerep szempontjából nézi a problémát;
- az univerzálisok szinte mindent egyformán jól tudnak csinálni.
Hátrányok:
- növekszik a BUS-faktor;
- elmosódik a szerepkörökhöz tartozó alapvető kompetenciák; ennek következtében csökken a munk minősége;
- növekszik a határidők csúszásának valószínűsége, mivel nincs kontroll minden lépésnél. Emellett felmerül a „csillag” kockázata is: a munkatárs biztos abban, hogy jobban tudja, ő az igazi profi;
- növekszik a szakmai kiégés kockázata;
- sok fontos információ a projektről csak a munkatárs „fejében” maradhat.
Ahogy látjátok, több a hátrány. Ezért univerzálisokat csak akkor használok, ha hiányoznak az erőforrások, és a feladat elég sürgős. Vagy ha az adott személy olyan kompetenciákkal rendelkezik, amelyek másoknak nincsenek, és a minőség a tét.
Ha a feladat közös megoldása során betartjuk a szerepek elosztásának szabályát, a munka minősége nő. A problémákra különböző szögből tekintünk, a nézőpont nem tompul el, mindig új ötletek merülnek fel. Eközben minden csapattagnak lehetősége van a szakmai fejlődésre és kompetenciái bővítésére.
Úgy gondolom, hogy a legfontosabb az, hogy érezzük a részvételünket a folyamatban, végezzük a munkánkat, fokozatosan bővítve kompetenciáinkat. Mindazonáltal az univerzálisok a csapatban hasznosak, a lényeg az, hogy hatékonyan ötvözzék a különféle szerepeket.
Kívánok mindenkinek egy önszerveződő csapatot az "universális mesterek"!
Forrás: habr.com
