„Üksnes” arendusmeeskonnas: kas kasu või kahju?

Tere kõigile! Minu nimi on Lyudmila Makarova, olen arenduse juht UBRiR-is ja kolmandik minu meeskonnast koosneb „ülesannete täitjatest”.

Tunnistage, iga Tech Lead unistab oma meeskonnas ristfunktsionaalsusest. See on ju nii äge, kui üks inimene suudab asendada kolme ning teha seda kvaliteetselt, aegadega ei venita. Ja mis on oluline, see tagab ressursside kokkuhoiu!
See kõlab väga ahvatlevalt, kuid kas see on tõesti nii? Proovime välja selgitada.

Kes on siis meie ootuste rahuldaja?

Mõiste „ülesannete täitja” tähistab tavaliselt meeskonna liikmeid, kes omavad mitut rolli, näiteks arendaja-analüütik.

Meeskonna koostöö ja töö tulemused sõltuvad osaliste professionaalsetest ja isiksuse omadustest.

Hard skills on selged, kuid soft skills väärivad erilist tähelepanu. Need aitavad leida lähenemise töötajale ja suunata ta just sellisele ülesandele, kus ta osutub kõige kasulikumaks.

On palju artikleid erinevate IT-tööstuse isiksusetüüpide kohta. Oma kogemusele tuginedes jagaksin IT-ülesannete täitjad nelja kategooriasse:

1. „Ülesannete täitja – kõikvõimas”

Need on igal pool. Nad näitavad alati suurt aktiivsust, tahavad olla tähelepanu keskpunktis, küsivad pidevalt kolleegidelt, kas nad vajavad abi, mõnikord isegi võivad ärritada. Nad huvituvad ainult olulistest ülesannetest, mille osas saavad nad loovust rakendada ja oma uhkust rahuldada.

Nende tugevused:

• suudavad lahendada keerulisi ülesandeid;
• sügavale probleemiga sukeldudes ‘kaevavad’ nad ja saavutavad tulemusi;
• on uudishimu ja teadmiste isikud.

Kuid:

• emotsionaalselt labile;
• halvasti juhitavad;
• omavad oma kindlat arvamust, mida on väga raske muuta;
• on keeruline panna lihtsat asja tegema. Lihtsad ülesanded riivavad kõikvõimaste uhkust.

2. „Ülesannete täitja – ma saan hakkama ja teen ära”

Neil inimestel piisab juhendist ja natukesest ajast – ja nad lahendavad probleemi. Tavaliselt on neil suur kogemus DevOps-is. Need ülesannete täitjad ei koorma end projekteerimisega ja eelistavad kasutada arendusmeetodeid, tuginedes ainult oma kogemusele. Nad võivad hõlpsasti tehisintellekti (Tech Lead) vastu vaielda üle valitud lahenduse.

Nende tugevused:

• iseseisvad;
• stressitaluvad;
• on kompetentsed paljudes küsimustes;
• on eruditseeritud – nendega on alati millestki rääkida.

Kuid:

• rikkuvad sageli kohustusi;
• kalduvad kõike keeruliseks tegema: lahendavad korrutustabeleid osade kaupa integreerimise teel;
• töö kvaliteet on madal, kõik tuleb välja 2-3 katsega;
• tõukavad pidevalt tähtaegu edasi, sest tegelikult osutub kõik mitte nii lihtsaks.

3. "Universaal – hästi, las ma teen, kuna kedagi muud ei ole"

K personeel tunneb end mitmes valdkonnas piisavalt hästi ja omab vastavat kogemust. Kuid ei suuda milleski professionaaliks saada, kuna teda kasutatakse tihti päästerõngana, et lappida hetkeprobleeme. On paindlik, täidab ülesandeid, arvab end olevat nõutud, kuid selliseks ei ole.

Praktiliselt ideaalne töötaja. Tõenäoliselt on tal suund, mis talle rohkem meeldib, kuid suutmatuse tõttu oma oskusi selgelt piiritleda areng ei toimu. Selle tulemuseks on, et inimene riskib jääda kasutuks ja emotsionaalselt kurnatuks.

Nende tugevused:

• on vastutustundlikud;
• on tulemustele suunatud;
• on rahulikud;
• on täielikult kontrollitavad.

Kuid:

• annavad keskmise tulemuse madala oskuste taseme tõttu;
• ei suuda lahendada keerulisi ja abstraktseid ülesandeid.

4. "Universaal – oma ala meister"

Inimesel on arendaja tugev taust, tal on süsteemne mõtlemine. Täpsustav, nõudlik enda ja meeskonna vastu. Iga ülesanne, milles ta osaleb, võib kasvada lõpmatuks, kui piire ei seadeta.

Tunneb hästi arhitektuuri, valib tehnilise rakendamise meetodi, analüüsides hoolikalt valitud lahenduse mõju praegusele arhitektuurile. On tagasihoidlik, mitte ambitsioonikas.

Nende tugevused:

• annavad kõrge töö kvaliteedi;
• on võimelised lahendama mis tahes ülesande;
• on väga töökad.

Kuid:

• on teiste arvamuste suhtes talumatud;
• on maksimaalsed. Üritavad kõike õigesti teha, mis pikendab arendusaega.

Mida me praktikas näeme?

Vaadakem, kuidas rollid ja oskused kõige sagedamini kokku langevad. Võtame aluseks tavalise arendustiimi: PO, arenduse juht (tech lead), analüütikud, programmeerijad, testijad. Toote omaniku ja tech leadi arvestama ei hakka. Esimene – tehniliste oskuste puudumise tõttu. Teine, kui tiimis probleemid, peab olema suuteline tegema kõike.

Kõige levinum oskuste ühendamine on arendaja-analüütik. Samuti esinevad sageli analüütik-testija ja "kolmes ühes".

Näitan oma meeskonna näitel, millised on universaalsete kolleegide eelised ja puudused. Minu meeskonnas on neid kolmandik ja ma armastan neid väga.

PO-lt tuli kiiresti ülesanne uusate hindade integreerimise osas olemasolevasse tootesse. Minu meeskonnas on 4 analüütikut. Sel hetkel oli üks puhkusel, teine haige ja ülejäänud tegelesid strateegiliste ülesannetega. Kui oleksin nad välja tõmmanud, oleks see paratamatult mõjutanud rakendamise tähtaegu. Ainsaks võimalikuks lahenduseks jäi kasutada "salajast relva" – universaalset arendaja-analüütikut, kes tunneis vajalikku valdkonda. Nimeks oleme kutsunud teda Anatoli.

Tema isiksuse tüüp – „universaal – ma mõistan ja teen”. Loomulikult üritas ta pikka aega selgitada, et tal on „oma ülesannete täielik backlog”, kuid minu tahtega saadeti ta lahendama kiirusülesannet. Ja Anatoli sai hakkama! Ta viis läbi ülesande seadistamise ja tegi rakendamise õigeks ajaks ning tellijad jäid rahule.

Esmapilgul kõik õnnestus. Kuid paar nädalat hiljem tekkis selle toote suhtes taas vajadus täiendamiseks. Nüüd tegeles selle ülesande seadistamisega „puhtalt” analüütik. Uue arenduse testimise etapis ei suutnud me pikka aega aru saada, miks tekivad meil vead uute hindade seadistamisel ja alles hiljem, klubi lahendades, jõudsime tõeni. Kulutasime sellele palju aega ja rikkusime tähtaegu.

Probleem oli selles, et paljusid varjatud hetki ja altkäemaksu ei olnud meie universaali peast õiget paberile viidud. Nagu Anatoli hiljem selgitas, kiirustas ta liiga palju. Kuid kõige tõenäolisem variant on see, et ta sattus probleemidesse juba arendamise ajal ja lihtsalt möödus neist, kajastamata neid kusagil.

Oli ka teine olukord. Praegu on meil ainult üks testija, seetõttu tuleb mõningaid ülesandeid testida analüütikutel, sealhulgas – universaalsetel. Seetõttu andsin ühe ülesande hüpoteetilisele Fedotile – „universaal – okei, ma teen, kui kedagi muud ei ole”.
Fedor on „kolmes ühes”, kuid selle ülesande jaoks oli juba määratud arendaja. See tähendab, et Fedor pidi olema ainult analüütik ja testija.

Nõuded on kokku kogutud, spetsifikatsioon on arendusse edastatud, on aeg testida. Fedja tunneb arendatavat süsteemi "nagu oma viit sõrme" ja on praeguseid nõudeid põhjalikult töötanud. Seetõttu ei pidanud ta end vaevama teststsenaariumite kirjutamisega, vaid viis läbi katsetamise selle kohta, "kuidas süsteem peaks töötama", seejärel edastas tulemused kasutajatele.
Test lõppes, täiendused viidi tootmisesse. Hiljem selgus, et süsteem mitte ainult ei peata maksete tegemist teatud kontodele, vaid blokeerib ka maksete tegemist väga haruldastelt sisekontodeelt, mis ei pidanud olema selles osalised.

See juhtus selle tõttu, et Fedja ei teinud kontrolli selle üle, "kuidas süsteem ei peaks töötama", ei koostanud testplaani ega kontrollnimekirju. Ta otsustas ajakava pealt kokku hoida ja toetuda oma intuitsioonile.

Kuidas me probleemidega töötame?

Sellised olukorrad mõjutavad meeskonna töö efektiivsust, vabastatavate versioonide kvaliteeti ja klientide rahulolu. Seetõttu ei saa neid tähelepanuta jätta ega põhjuseid analüüsimata jätta.

1. Iga ülesande puhul, mis tegi raskusi, palun mul täita ühtlustatud vorm: veahindamise kaart, mis võimaldab tuvastada etapi, kus toimus "langus":

2. Pärast kitsaskohtade tuvastamist korraldatakse iga töötajaga, kes probleemi mõjutas, ajurünnak "Mida muuta?" (erilised juhud ei ole tagasivaatamisel arutluseks) ja sellega sünnivad konkreetsed tegevused (iga isiksusetüübi jaoks erinevad) koos tähtaegadega.

3. Oleme sisse viinud reeglid meeskonna sisese suhtlemise kohta. Näiteks leppisime kokku, et kõik ülesande edenemisega seotud teave peab olema fikseeritud projektijuhtimise süsteemis. Arenduse käigus muutuste/väärkasutuste tuvastamisel tuleb see kajastada teadmistebaasis ja lõppversioonis.

4. Kontroll on toimunud igas etapis (eriti tähelepanu pööratakse probleemsetele etappidele minevikus) ja automaatselt järgmise ülesande täitmise tulemuste järgi.

5. Kui järgmise ülesande tulemus ei ole muutunud, ei pane ma arvesse vaadeldavat universaali sellesse rolli, millega ta halvasti toime tuleb. Püüan hinnata tema võimet ja soovi arendada antud rollis oskusi. Kui ei leia vastukaja, jätan ta sinna rolli, mis on talle lähemal.

Mida lõpuks saavutati?

Arenduse protsess on muutunud selgemaks. BUS-faktor on vähenenud. Meeskonna liikmed, töötades vigade kallal, tunnevad end motiveerituna ja parandavad oma karma. Me tõstame järk-järgult oma väljaannete kvaliteeti.

Järeldused

Üksikute töötajate universaalsusel on omad plussid ja miinused.

Eelised:

• saab igal hetkel lõpetada veniva ülesande või lahendada kiires korras tõsise vea;
• kompleksne lähenemine ülesande lahendamisele: teostaja vaatab sellele kõigi rollide poolt;
• universaalid saavad peaaegu kõike teha sama hästi.

Puudused:

• BUS-faktor kasvab;
• põhilised kompetentsid, mis on rollile iseloomulikud, hajuvad. Selle tõttu langeb töö kvaliteet;
• toodete tähtaegade nihke tõenäosus tõuseb, kuna puudub kontroll igal etapil. Tekivad ka riskid, et genereeritakse 'täht': töötaja on kindel, et teab paremini, et on proff;
• kutses põlemise risk suureneb;
• projeedi kohta võib jääda palju olulist teavet ainult töötaja 'meeles'.

Nagu näete, on puudusi rohkem. Seetõttu kasutan universaale ainult siis, kui ressursse ei piisa ja ülesanne on piisavalt kiire. Või kui inimesel on oskusi, mida teistel napib ning kvaliteet on mängus.

Kui ülesande koostöös järgitakse rollide jaotamise reeglit, siis töö kvaliteet tõuseb. Probleemidele vaatame erinevatelt poolt, vaade ei muutu ühtlaseks, alati tulevad esile värsked ideed. Samuti on igal meeskonna liikmel võimalused professionaalseks kasvuks ja oma kompetentside laiendamiseks.

Pean kõige olulisemaks tunnetada oma kuuluvust protsessi, tegeleda oma tööga, järk-järgult laiendades oma kompetentside ulatust. Siiski toovad universaalid meeskonda kasu: oluline on teha nii, et nad tõhusalt kombineeriksid erinevaid rolle.

Soovin kõigile iseorganiseeruva meeskonna 'universaalide-meistrite' headelt tegusid!

Allikas: habr.com