Tere kõigile! Minu nimi on Ljudmila Makarova, olen UBRD arendusjuht ja kolmandik minu meeskonnast on “generalistid”.
Tunnistage: iga tehniline juht unistab oma meeskonna ristfunktsionaalsusest. See on nii lahe, kui üks inimene suudab asendada kolm ja isegi teha seda tõhusalt, ilma tähtaegu viivitamata. Ja mis kõige tähtsam, see säästab ressursse!
Kõlab väga ahvatlevalt, aga kas see on tõesti nii? Proovime selle välja mõelda.
Kes ta on, meie ootuste eelkäija?
Mõiste “üldine” viitab tavaliselt meeskonnaliikmetele, kes ühendavad rohkem kui ühe rolli, näiteks arendaja-analüütik.
Meeskonna koostoime ja selle töö tulemus sõltuvad osalejate professionaalsetest ja isikuomadustest.
Kõvade oskuste osas on kõik selge, kuid pehmed oskused väärivad erilist tähelepanu. Need aitavad leida lähenemist töötajale ja suunavad ta ülesande juurde, kus temast kõige rohkem kasu on.
IT-tööstuses on palju artikleid igasuguste isiksusetüüpide kohta. Oma kogemuse põhjal jagaksin IT-üldspetsialistid nelja kategooriasse:
1. "Universaalne – kõikvõimas"
Neid on igal pool. Nad on alati väga aktiivsed, tahavad olla tähelepanu keskpunktis, küsivad pidevalt kolleegidelt, kas neil on nende abi vaja, ja mõnikord võivad nad olla isegi tüütud. Neid huvitavad ainult sisukad ülesanded, milles osalemine annab ruumi loovusele ja võib lõbustada nende uhkust.
Mille poolest nad tugevad on:
- oskab lahendada keerulisi probleeme;
- sukelduge probleemi sügavale, "kaevake" ja saavutage tulemusi;
- on uudishimuliku meelega.
Kuid:
- emotsionaalselt labiilne;
- halvasti juhitud;
- neil on oma vankumatu vaatenurk, mida on väga raske muuta;
- Kedagi on raske panna tegema lihtsat asja. Lihtsad ülesanded kahjustavad kõigeväelise ego.
2. "Universaalne – ma mõtlen selle välja ja teen ära"
Sellised inimesed vajavad lihtsalt käsiraamatut ja natuke aega - ja nad lahendavad probleemi. Tavaliselt on neil DevOpsis tugev taust. Sellised generalistid ei vaeva end disainiga ja eelistavad kasutada arendusmeetodit, mis põhineb ainult oma kogemustel. Nad saavad hõlpsasti arutada tehnilise juhiga ülesande elluviimise valitud variandi üle.
Mille poolest nad tugevad on:
- sõltumatu;
- stressikindel;
- pädev paljudes küsimustes;
- erudeeritud – nendega on alati millest rääkida.
Kuid:
- rikuvad sageli kohustusi;
- kipuvad kõike keeruliseks tegema: lahenda korrutustabel osade kaupa integreerimise teel;
- töö kvaliteet on madal, kõik töötab 2-3 korda;
- Nad nihutavad pidevalt tähtaegu, sest tegelikult pole kõik nii lihtne.
3. „Universaalne – olgu, las ma teen seda, sest kedagi teist pole”
Töötaja on mitme valdkonnaga hästi kursis ja vastava kogemusega. Kuid tal ei õnnestu üheski neist professionaaliks saada, sest teda kasutatakse sageli päästerõngana, ummistades auke jooksvates ülesannetes. Paindlik, tõhus, peab end nõutuks, aga ei ole.
Praktiline ideaalne töötaja. Suure tõenäosusega on tal suund, mis talle kõige rohkem meeldib, kuid pädevuste hägustumise tõttu arengut ei toimu. Selle tulemusena on inimesel oht muutuda nõudmatuks ja emotsionaalselt läbi põleda.
Mille poolest nad tugevad on:
- vastutav;
- tulemusele orienteeritud;
- rahulik;
- täielikult kontrollitud.
Kuid:
- näitama keskmisi tulemusi tänu madalale pädevustasemele;
- ei suuda lahendada keerulisi ja abstraktseid probleeme.
4. "Kõikvõistleja on oma töö meister"
Tõsise arendaja taustaga inimesel on süsteemne mõtlemine. Pedantne, nõudlik enda ja oma meeskonna suhtes. Iga temaga seotud ülesanne võib lõputult kasvada, kui piire ei määratleta.
Ta tunneb hästi arhitektuuri, valib tehnilise teostuse meetodi, analüüsides hoolikalt valitud lahenduse mõju praegusele arhitektuurile. Tagasihoidlik, mitte ambitsioonikas.
Mille poolest nad tugevad on:
- näidata töö kõrget kvaliteeti;
- võimeline lahendama mis tahes probleemi;
- väga tõhus.
Kuid:
- sallimatus teiste arvamuste suhtes;
- maksimalistid. Nad püüavad teha kõike õigesti ja see pikendab arendusaega.
Mis meil praktikas on?
Vaatame, kuidas rollid ja pädevused kõige sagedamini kombineeritakse. Võtame lähtekohaks standardse arendusmeeskonna: PO, arendusjuht (tehniline juht), analüütikud, programmeerijad, testijad. Me ei võta arvesse toote omanikku ja tehnilist juhti. Esimene on tingitud tehniliste pädevuste puudumisest. Teine, kui meeskonnas on probleeme, peaks kõigega hakkama saama.
Kõige levinum võimalus kompetentside ühendamiseks/liitmiseks/ühendamiseks on arendaja-analüütik. Testimine analüütik ja "kolm ühes" on samuti väga levinud.
Oma meeskonna näitel näitan teile oma kolleegide plusse ja miinuseid. Minu meeskonnas on neid kolmandik ja ma armastan neid väga.
PO sai kiireloomulise ülesande kehtestada olemasolevale tootele uued tariifid. Minu meeskonnas on 4 analüütikut. Sel ajal oli üks puhkusel, teine haige ja ülejäänud tegelesid strateegiliste ülesannete täitmisega. Kui ma need välja tõmbaksin, rikuks see paratamatult elluviimise tähtaegu. Oli ainult üks väljapääs: kasutada “salarelva” - mitmekülgset arendaja-analüütikut, kes valdas vajalikku ainevaldkonda. Nimetagem teda Anatoliks.
Tema isiksusetüüp on "Universaalne – ma mõtlen selle välja ja teen ära". Muidugi püüdis ta pikka aega selgitada, et tal on "ülesannete täitmata jätmine", kuid minu tahtejõulise otsusega saadeti ta kiireloomulist probleemi lahendama. Ja Anatoli tegi seda! Ta viis lavastamise ja teostuse õigeks ajaks valmis ning kliendid jäid rahule.
Esmapilgul kõik klappis. Kuid mõne nädala pärast tekkisid selle toote jaoks taas parendusnõuded. Nüüd sõnastas selle probleemi "puhas" analüütik. Uusarenduse testimise etapis ei saanud me pikka aega aru, miks meil uute tariifide sidumisel vigu tekkis, ja alles siis, olles kogu sasipundar lahti harutanud, jõudsime tõe põhja. Raiskasime palju aega ja jätsime tähtaegadest mööda.
Probleem oli selles, et paljud varjatud hetked ja lõksud jäid ainult meie universaali pähe ega kandunud paberile. Nagu Anatoli hiljem selgitas, oli tal liiga kiire. Kuid kõige tõenäolisem variant on see, et ta puutus probleemidega kokku juba arenduse käigus ja läks neist lihtsalt mööda, ilma seda kuskil kajastamata.
Oli teine olukord. Nüüd on meil ainult üks testija, nii et mõningaid ülesandeid peavad testima analüütikud, sealhulgas generalistid. Seetõttu andsin tingimuslikule Fedorile ühe ülesande - "Universaalne – olgu, las ma teen seda, sest kedagi teist pole".
Fedor on "kolm ühes", kuid selle ülesande jaoks on juba arendaja määratud. See tähendab, et Fedya pidi ühendama ainult analüütiku ja testija.
Nõuded kogutud, spetsifikatsioon arendusse antud, aeg katsetada. Fedor tunneb muudetavat süsteemi "nagu oma viit sõrme" ja on praegused nõuded põhjalikult välja töötanud. Seetõttu ei hakanud ta vaeva nägema testskriptide kirjutamisega, vaid tegi testimise teemal “kuidas süsteem peaks töötama”, seejärel edastas selle kasutajatele.
Test sai läbi, redaktsioon läks tootmisse. Hiljem selgus, et süsteem mitte ainult ei peatanud makseid teatud saldokontodele, vaid blokeeris ka maksed väga haruldastelt sisekontodelt, mis ei pidanud selles osalema.
See juhtus seetõttu, et Fedor ei kontrollinud, kuidas "süsteem ei peaks töötama", ei koostanud testiplaani ega kontrollnimekirju. Ta otsustas ajaarvelt kokku hoida ja loota oma sisetundele.
Kuidas me probleemidega toime tuleme?
Sellised olukorrad mõjutavad meeskonna jõudlust, väljalaske kvaliteeti ja klientide rahulolu. Seetõttu ei saa neid jätta tähelepanuta ja põhjuste analüüsita.
1. Iga raskusi tekitanud ülesande puhul palun täita ühtne vorm: veakaart, mis võimaldab tuvastada, millises etapis „tõmbus“ aset leidis:
2. Pärast kitsaskohtade tuvastamist korraldatakse iga probleemi mõjutanud töötajaga ajurünnak: “Mida muuta?” (erijuhtumeid me tagantjärele ei käsitle), mille tulemusena sünnivad konkreetsed (igale isiksusetüübile omased) teod koos tähtaegadega.
3. Oleme kehtestanud meeskonnasisese suhtluse reeglid. Näiteks leppisime kokku, et salvestame kogu teabe ülesande edenemise kohta projektihaldussüsteemi. Kui arendusprotsessi käigus artefakte muudetakse/tuvastatakse, peab see kajastuma teadmistebaasis ja tehniliste kirjelduste lõplikus versioonis.
4. Kontrolli hakati läbi viima igas etapis (erilist tähelepanu pööratakse varem probleemsetele etappidele) ja automaatselt järgmise ülesande tulemuste põhjal.
5. Kui järgmise ülesande tulemus pole muutunud, siis ma ei pane üldistajat sellesse rolli, milles ta halvasti hakkama saab. Püüan hinnata tema võimet ja soovi selles rollis pädevusi arendada. Kui ma vastust ei leia, jätan ta rolli, mis on talle lähedasem.
Mis lõpus juhtus?
Arendusprotsess on muutunud läbipaistvamaks. BUS-tegur on vähenenud. Meeskonnaliikmed, kes töötavad vigade kallal, muutuvad motiveeritumaks ja parandavad oma karmat. Parandame järk-järgult oma väljaannete kvaliteeti.
Järeldused
Üldist töötajatel on oma plussid ja miinused.
Plussid:
- saate igal ajal langeva ülesande sulgeda või kiireloomulise vea lühikese aja jooksul lahendada;
- integreeritud lähenemine probleemi lahendamisele: esineja vaatab seda kõigi rollide vaatenurgast;
- generalistid saavad peaaegu kõigega võrdselt hästi hakkama.
Puudused:
- BUSi tegur suureneb;
- rollile omased põhipädevused on murenenud. Selle tõttu langeb töö kvaliteet;
- tähtaegade nihkumise tõenäosus suureneb, kuna igas etapis puudub kontroll. “Täheks” kasvamisega kaasnevad ka riskid: töötaja on kindel, et teab paremini, et ta on proff;
- suureneb professionaalse läbipõlemise oht;
- palju olulist infot projekti kohta võib jääda vaid töötaja “pähe”.
Nagu näete, on puudusi veelgi. Seetõttu kasutan generaliste ainult siis, kui ressursse napib ja ülesanne on üsna kiireloomuline. Või on inimesel kompetentsid, mis teistel puuduvad, aga kaalul on kvaliteet.
Kui ülesandega ühistöös järgitakse rollide jaotuse reeglit, siis töö kvaliteet tõuseb. Vaatame probleeme erinevate nurkade alt, meie vaade ei ole hägune, alati tekivad värsked mõtted. Samas on igal meeskonnaliikmel kõik võimalused professionaalseks kasvuks ja oma pädevuste avardumiseks.
Usun, et kõige olulisem on tunda end protsessis kaasatuna, teha oma tööd, suurendades järk-järgult oma pädevusi. Generalistid meeskonnas toovad aga kasu: peamine on tagada, et nad kombineeriksid erinevaid rolle tõhusalt.
Soovin kõigile iseorganiseeruvat meeskonda “oma eriala universaalsed meistrid”!
Allikas: www.habr.com