Tere kõigile! Minu nimi on Ljudmila Makarova, olen arenduse juht UBRiR-is, ja kolmandik mu meeskonnast on „ühekordsed”.
Tunnistage: iga tehniline juht unistab oma meeskonnas ristfunktsionaalsusest. See on tõeliselt äge, kui üks inimene suudab asendada kolme ja lisaks sellele teha seda kvaliteetselt, ilma tähtaegu rikkumata. Ja mis väga oluline, see tagab ka ressursside kokkuhoiu!
See kõlab tõeliselt ahvatlevana, kuid kas see on tõeliselt nii? Proovime selgust saavutada.
Kes on meie ootusi ületav?
Mõistet „ühekordne” mõistetakse tavaliselt kui meeskonna liikmeid, kes saavad täita rohkem kui ühte rolli, näiteks arendaja-analüütik.
Meeskonna koostöö ja nende töö tulemus sõltuvad osalejate professionaalsetest ja isiklikest omadustest.
Hard skills on selged, kuid soft skills väärivad erilist tähelepanu. Need aitavad leida töötajale sobiva lähenemise ja suunata ta täpselt sellele ülesandele, kus ta saab olla kõige kasulikum.
IT-tööstuse esindajate erinevate isiksusetüüpide kohta on palju artikleid. Omandades oma kogemusi, jagaksin IT- universaale nelja kategooriasse:
1. «Universaal – kõikvõimas»
Sellised inimesed on igal pool. Nad on alati aktiivsed, soovivad olla tähelepanu keskpunktis, küsivad pidevalt kolleegidelt, kas nad vajavad abi, ja mõnikord võivad nad isegi häirida. Neid huvitavad ainult olulised ülesanded, mille osalemine annab loovuse väljundi ja rahuldab nende egot.
Nendes on tugevused:
- nad suudavad lahendada keerulisi probleeme;
- kuuluvad sügavale probleemidesse, «kaevavad» ja saavutavad tulemusi;
- nad on uudishimuliku meelega.
Kuid:
- nad on emotsionaalselt ebastabiilsed;
- nad on raskesti juhitavad;
- nad peavad järjepidevat seisukohta, mida on väga raske muuta;
- neid on raske sundida lihtsat asja tegema. Lihtsad ülesanded solgutavad kõikvõimsate uhkust.
2. «Universaal – selgitan välja ja teen»
Sellistele inimestele piisab juhendist ja veidi ajast, et nad probleemi lahendaks. Neil on tavaliselt suur DevOpsi taust. Need universaalid ei vaevu projekteerimisega ja eelistavad arendust meetodit, mis põhineb ainult nende omal kogemusel. Nad saavad kergesti tehnilise juhtiga vaidlema minna valitud lahenduse üle.
Nendes on tugevused:
- iseseisvad;
- stressikindlad;
- paljuski pädevad;
- haritud – nendega on alati millestki rääkida.
Kuid:
- tihti ei täida kohustusi;
- kalduvad kõike keeruliseks muutma: lahendavad korrutustabelit osade kaupa integreerimise teel;
- töö kvaliteet on madal, kõik tuleb teha 2-3 korda;
- lõppetähtaegade pidev nihkumine, kuna tegelikult on kõik palju keerulisem.
3. "Universaal – no olgu, las ma teen, kui rohkem kedagi ei ole"
Töötaja mõistab mitmeid valdkondi ja omab vastavat kogemust. Kuid tal ei õnnestu igas neist tõeliselt professionaalne olla, kuna teda kasutatakse sageli päästerõngana, et täita jooksvate ülesannete lünki. Ta on paindlik, täidab oma ülesandeid, arvab end olevat nõutud, kuid see ei vasta tõele.
Praktiline ideaalne töötaja. Tõenäoliselt on tal mõni suund, mis talle rohkem meeldib, kuid kompetentside hajumise tõttu ei toimu arengut. Tulemuseks on see, et inimene riskib saama tööta ja vaimselt läbi põlema.
Nendes on tugevused:
- vastutustundlikud;
- tulemustele suunatud;
- rahulikud;
- täielikult kontrollitavad.
Kuid:
- näitavad keskmist tulemust madala kompetentsi taseme tõttu;
- ei oska lahendada keerulisi ja abstraktseid ülesandeid.
4. "Universaal – oma ala meister"
Inimene, kellel on tõsine arendaja taust ja kes omab süsteemset mõtlemist. Ta on pedantne, nõuab endalt ja meeskonnalt palju. Iga ülesanne tema osalusel võib kasvada lõpmatuseni, kui piire ei seata.
Tuntud arhitektuuriga, valib tehnilise teostuse meetodi, analüüsides hoolikalt valitud lahenduse mõju praegusele arhitektuurile. Alandlik, mitte ambitsioonikas.
Nendes on tugevused:
- näitavad kõrget töö kvaliteeti;
- suudavad lahendada iga probleemi;
- väga töökad.
Kuid:
- ei talu teiste arvamusi;
- maksimaalsed. Püüavad kõik õigesti teha, mis pikendab arendusprotsessi.
Mida me praktikas näeme?
Vaadakem, kuidas kõige sagedamini liidetakse rolle ja kompetentse. Võtame aluseks tavalise arendusmeeskonna: PO, arenduse juht (tehnoloogia juht), analüütikud, programmeerijad, testaajad. Toote omanikku ja tehnoloogia juhti ei arvesta, esimest tehniliste kompetentside puudumise tõttu. Teine, kui meeskonnas on probleeme, peab justkui oskama kõike teha.
Kõige levinum kompetentside ühendamise/liitmise/koondamise variant on arendaja-analüütik. Samuti esinevad väga tihti analüütik-testaaja ja "kolmes ühes".
Oma meeskonna näitel näitan, millised on universaalsete kolleegide plussid ja miinused. Minu meeskonnas on neid kolmandik ja ma armastan neid väga.
PO-lt tuli kiire ülesanne uute tariifide rakendamiseks olemasolevas tootes. Minu meeskonnas on 4 analüütikut. Sel hetkel viibis üks puhkusel, teine oli haige, ülejäänud tegelesid strateegiliste ülesannete täitmisega. Kui ma oleksin nad välja tõmmanud, oleks see kindlasti viibinud teostamisaega. Jäi ainult üks väljapääs: kasutada "salajast relva" – universaalset arendaja-analüütikut, kellel oli vajalik valdkondlik teadmus. Nimetame teda Anatoliiks.
Tema isiksusetüüp – "universaal – saan hakkama ja teen ära". Loomulikult püüdis ta pikalt seletada, et tal on "täis oma ülesannete backlog", kuid minu tahte korral saadeti ta kiire ülesande lahendamiseks. Ja Anatoli tegi seda! Ta viis ülesande edasi ja täitis teostuse õigeks ajaks ning tellijad jäid rahule.
Esimene pilk kõigel tundus õnnestuvat. Kuid paar nädalat hiljem tuli sellele tootele uuesti kaasaegne nõudmine. Nüüd tegeleb selle ülesande seadistamisega „puhtalt“ analüütik. Uue arenduse testimise etapis ei suutnud me pikka aega aru saada, miks meil on probleeme uute hindade sidumisega, ja alles hiljem, kõik lahti harutades, jõudsime tõeni. Kulutasime tohutult aega ja tähtaegade rikkumist.
Probleem oli selles, et paljud varjatud detailid ja konksud jäid ainult meie universaali pähe ja ei olnud paberile pandud. Nagu hiljem Anatoli selgitas, kiirustas ta liiga palju. Kuid kõige tõenäolisem on, et ta sattus probleemide otsa juba arenduse käigus ja lihtsalt möödus neist, kajastamata neid kusagil.
Oli ka teine olukord. Praegu on meil ainult üks testija, seega tuleb mõned ülesanded testida ka analüütikutel, sealhulgas – universaalsetel. Seetõttu andsin ühe ülesande tingimisi Fedorile – „universaal, okei, las ma teen, kuna rohkem kedagi ei ole“.
Fedor on «kolm ühes», kuid selle ülesande jaoks oli arendaja juba määratud. See tähendab, et Fedor pidi endas ühendama ainult analüütiku ja testija.
Nõuded on kogutud, spetsifikatsioon on edasi antud arendusse, on aeg testida. Fedor tunneb toimetatavat süsteemi «nagu oma viit sõrme» ja on põhjalikult uurinud praeguseid nõudeid. Seetõttu ei pidanud ta vaevama end teststsenaariumide kirjutamisega, vaid viis läbi testi selle kohta, «kuidas süsteem peaks toimima», ja edastas seejärel kasutajatele.
Test lõppes, täiendamine läks tootmisse. Hiljem selgus, et süsteem mitte ainult ei peata maksete tegemist teatud kontodele, vaid blokeerib ka maksete tegemise väga haruldastelt siseedetelt, mis ei oleks pidanud selles osalema.
See juhtus seetõttu, et Fedor ei viinud läbi kontrolli selle üle, «kuidas süsteem ei peaks töötama», ei koostanud testplaani ega kontrollnimekirju. Ta otsustas ajakulu kokku hoida ja usaldas oma intuitsiooni.
Kuidas me probleemidega tegeleme?
Taolised olukorrad mõjutavad meeskonna töö efektiivsust, välja antud väljaande kvaliteeti ja tellijate rahulolu. Seetõttu ei tohi neid tähelepanuta jätta ega analüüsimata.
1. Iga probleemi korral palun täita standardiseeritud vorm: veakaarte, mis aitab tuvastada etappi, kus toimus "langus":
2. Pärast kitsaskohtade tuvastamist toimub iga töötajaga, kes probleemiga seotud, ajurünnak "Mida muuta?" (erilised juhtumid ei ole olema arutluse all retrospektiivis), mille tulemuseks sünnivad konkreetsed tegevused (iga isiksuse tüübi jaoks omad) koos tähtaegadega.
3. Oleme kehtestanud meeskonna sees suhtlemise reeglid. Näiteks oleme kokku leppinud, et kogu teave ülesande käigu kohta tuleb kindlasti fikseerida projektijuhtimissüsteemis. Arendamise käigus toimuvate artefaktide muutmise/välja selgitamise korral on vaja need kajastada teadmusbaasis ja lõplikus TÄF versioonis.
4. Kontrollimist tehakse igal etapil (eriti tähelepanu pööratakse eelmistele probleemsetele etappidele) ja automaatselt järgmise ülesande täitmise tulemuste põhjal.
5. Kui järgmise ülesande tulemus ei ole muutunud, siis ei pane ma arutatavat universaali rolli, millega ta halvasti toime tuleb. Püüan hinnata tema võimet ja soovi kompetentside arendamiseks selles rollis. Kui vastukaja puudub, jätan ta sellesse rolli, mis talle rohkem sobib.
Mis on lõpptulemus?
Arendusprotsess on muutunud läbipaistvamaks. BUS-faktor on vähenenud. Meeskonna liikmed, töötades vigade kallal, muutuvad motiveeritumaks ja parandavad oma karmaa. Aja jooksul tõstame meie väljalaskete kvaliteeti.
Järeldused
Universaalsetel töötajatel on omad plusid ja miinused.
Eelised:
- saab igal ajal lõpetada veniva ülesande või lahendada kiireid vigu lühikese ajaga;
- kompleksne lähenemine ülesande lahendamisele: täitja vaatab sellele kõigi rollide vaatenurgast;
- universaalid suudavad praktiliselt kõike sama hästi teha.
Puudused:
- BUS-faktor kasvab;
- peamised kompetentsid, mis on rikka rollide jaotuse tõttu, hajuvad. Seetõttu väheneb töö kvaliteet;
- aegade nihke tõenäosus suureneb, kuna puudub kontroll iga etapi üle. Samuti tekivad riskid 'tähe' kasvatamiseks: töötaja on kindel, et ta teab paremini, et ta on professionaal;
- tõuseb professionaalse läbipõlemise risk;
- palju olulist teavet projekti kohta võib jääda ainult töötaja „peavale“.
Nagu näete, on puudusi rohkem. Seetõttu kasutan universaale ainult siis, kui ressursse on vähe ja ülesanne on piisavalt kiire. Või kui inimene omab oskusi, mida teistel pole piisavalt, ja kvaliteet on ohus.
Kui ülesande ühiselt töötamisel järgime rollide jaotamise reeglit, tõuseb töö kvaliteet. Probleemidele lähenetakse erinevatest külgedest, pilk ei hakka harjuma, alati tulevad esile värsked mõtted. Samuti on igal meeskonna liikmel kõik võimalused professionaalseks arenguks ja oma oskuste laiendamiseks.
Pean oluliseks, et tunneksin end protsessis osalejana, tegeleksin oma tööga ja järk-järgult suurendaksin oma oskuste ulatust. Siiski toovad universaalid meeskonda kasu: peamine on, et nad suudaksid tõhusalt ühendada erinevaid rolle.
Soovin kõigile iseorganiseeruvatele „universaalide-oma-ala-meistrite“ meeskondadele!
Allikas: habr.com
