🥇'Universal' në ekipin e zhvillimit: përfitim apo dëm?

Përshëndetje të gjithëve! Emri im është Lyudmila Makarova, unë jam menaxhere zhvillimi në UBRiR dhe një e treta e ekipit tim janë «universalistë».

Pranoni: çdo Tech Lead ka ëndërruar për kros-funksionalitet brenda ekipit të tij. Sepse është kaq e mrekullueshme kur një person është në gjendje të zëvendësojë tre, dhe këtë ta bëjë cilësisht, pa e zhvendosur afatin. Dhe, që është e rëndësishme, kjo siguron kursim burimesh!
Dëgjohet shumë tërheqëse, por a është kështu në të vërtetë? Le të përpiqemi ta kuptojmë.

Kush është ai, parashikuesi ynë i pritshmërive?

Me termin «universal» zakonisht kuptojmë anëtarë të ekipit që kombinojnë më shumë se një rol, për shembull, zhvillues-analist.

Ndërveprimi i ekipit dhe rezultatet e tij varen nga cilësitë profesionale dhe personale të pjesëtarëve.

E gjithë çështja në hard skills është e qartë, por soft skills meritojnë një vëmendje të veçantë. Ato ndihmojnë në gjetjen e mënyrës për të punuar me punonjësin dhe në orientimin e tij pikërisht në atë detyrë ku do të jetë sa më i dobishëm.

Ekzistojnë shumë artikuj mbi të gjitha llojet e personaliteteve të përfaqësuesve të industrisë IT. Duke u mbështetur në përvojën time, do t'i ndaja IT-universalistët në katër kategori:

1. «Universali – i pafuqishëm»

Këta janë të pranishëm kudo. Ata gjithmonë tregojnë aktivitet të madh, duan të jenë në qendër të vëmendjes, gjithmonë pyesin kolegët nëse u nevojitet ndihma, ndonjëherë madje mund të bezdisin. I interesojnë vetëm detyrat e rëndësishme, pjesëmarrja në të cilat do t'u ofrojë hapësirë për krijimtari dhe do të kënaqë egon e tyre.

Në çfarë janë të fortë:

janë të aftë të zgjidhin probleme të komplikuara;
thellësisht përfshihen në problem, «gërmojnë» dhe arrijnë rezultate;
kanë një mendje kurioze.

Por:

janë emocionalisht të labil;
janë pak të menaxhueshëm;
kanë një pikëpamje të paluhatshme që është shumë e vështirë të ndryshohet;
është e vështirë t'i bësh të bëjnë një punë të thjeshtë. Detyrat e lehta prekin egon e të pafuqishmëve.

2. «Universali – do ta kuptoj dhe do ta bëj»

Këtyre njerëzve u mjafton një manual dhe pak kohë – dhe ata do ta zgjidhin çështjen. Zakonisht kanë një përvojë të madhe si DevOps. Këta universalistë nuk i ngarkojnë veten me projektimin dhe preferojnë të përdorin metodën e zhvillimit bazuar vetëm në përvojën e tyre. Mund të hasin në kundërshtime me tech lead-in lidhur me opsionin e zgjidhjes së detyrës.

Në çfarë janë të fortë:

janë të pavarur;
janë të qëndrueshëm ndaj stresit;
janë kompetentë në shumë çështje;
të ditur – gjithmonë ka diçka për të biseduar me ta.

Por:

shpesh shkelin angazhimet;
janë të prirur të komplikohet gjithçka: zgjidhin tabelat e shumzimit duke i integruar pjesërisht;
cilësia e punës është e ulët, gjithçka kërkon 2-3 herë;
përherë vonojnë afatet, sepse në të vërtetë gjithçka del të jetë më e ndërlikuar se sa mendohej.

3. "Universali – mirë, le të cilin unë, pasi nuk ka kush tjetër"

Punonjësi ka njohuri të mira në disa fusha dhe përvojën përkatëse. Por nuk arrin të bëhet profesionist në asnjërën prej tyre, sepse shpesh përdoret si një rreth shpëtimi, duke mbushur boshllëqet në detyrat aktuale. Është i përshtatshëm, i ekzekutueshëm, mendon se është i kërkuar, megjithatë nuk është një i tillë.

Punonjësi praktikisht ideal. Më së shumti, ai ka një drejtim, të cilin e preferon më shumë, por për shkak të shkrirjes së kompetencave nuk ka zhvillim. Si rezultat, ndonëse, personi rrezikon të bëhet i pavlerë dhe emocionalisht i vyshkur.

Në çfarë janë të fortë:

të përgjegjshëm;
të orientuar drejt rezultateve;
të qetë;
plotësisht të kontrollueshëm.

Por:

tregojnë rezultate mesatare për shkak të nivelit të ulët të kompetencave;
nuk mund të zgjidhin detyra të ndërlikuara dhe abstrakte.

4. "Universali – mjeshtër i punës së tij"

Një person me një background të rëndësishëm si zhvillues, ka mendje sistematike. Është pedant, kërkon shumë nga vetja dhe nga ekipi. Çdo detyrë me përfshirjen e tij mund të zgjerohet deri në pafundësi, nëse nuk përcaktohen kufijtë.

I njohur mirë me arkitekturën, zgjedh metodën e realizimit teknik, duke analizuar me kujdes ndikimin e zgjidhjes së zgjedhur në arkitekturën aktuale. Është modest, pa ambicie.

Në çfarë janë të fortë:

tregojnë cilësi të lartë të punës;
janë në gjendje të zgjidhin çdo detyrë;
janë shumë të punësuar.

Por:

të padurueshëm ndaj mendimeve të të tjerëve;
maksimalistë. Mundohen të bëjnë gjithçka siç duhet, dhe kjo rrit afatet e zhvillimit.

Çfarë kemi në praktikë?

Të shohim se si zakonisht bashkohen rolet dhe kompetencat. Të marrim si pikë fillimi një ekip standard zhvillimi: PO, menaxheri i zhvillimit (lideri teknik), analistët, programuesit, testuesit. Nuk do ta llogarisim pronarin e produktit dhe liderin teknik. I pari – për shkak të mungesës së kompetencave teknike. I dyti, nëse ekipi ka probleme, duhet me të vërtetë të dijë të bëjë gjithçka.

Varianti më i zakonshëm i bashkimit / përzierjes / përmbajtjes së kompetencave është zhvillues-analist. Gjithashtu, shumë shpesh hasen analist-tester dhe "tre në një".

Duke u bazuar në ekipin tim, do të tregoj se çfarë janë përfitimet dhe disavantazhet e kolegëve universale. Në ekipin tim, ata përbëjnë një të tretën dhe i dua shumë.

Nga PO më erdhi një detyrë urgjente për të implementuar tarifa të reja në produktin ekzistues. Në ekipin tim ka 4 analistë. Në atë moment, njëri ishte në pushim, tjetri kishte marrë sëmundje, ndërsa të tjerët po merreshin me realizimin e detyrave strategjike. Po të isha tërhequr ata, do të kishin vonuar afrimin e afateve. Një zgjidhje e vetme mbeti: të përdorja "armën sekrete" – universalin zhvillues-analist, i cili kishte njohuritë e nevojshme për fushën përkatëse. Ta quajmë atë Anatoli.

Tipi i tij të karakterit është "universal - do ta kuptoj dhe do ta bëj". Natyrisht, ai përpiqej gjatë për të shpjeguar se kishte "një backlog të plotë të detyrave të tij", por me një vendim të forcës time u dërgua për të zgjidhur këtë detyrë urgjente. Dhe Anatoli ia doli! Ai zhvilloi postimin dhe përfundoi realizimin në kohë, dhe porositësit mbetën të kënaqur.

Në shikim të parë, gjithçka shkoi mirë. Por pas disa javësh, kërkesat për rregullime në këtë produkt u shfaqën sërish. Tani, për këtë detyrë u merrej një analist "i pastër". Në fazën e testimit të zhvillimit të ri, nuk mundëm për një kohë të gjatë të kuptonim pse kishim gabime në lidhjen e tarifave të reja dhe vetëm më pas, duke zbardhur të gjithë ngatërrimin, arritëm në të vërtetën. Ne kaluam shumë kohë dhe humbëm afatet.

Problemi ishte se shumë momente të fshehura dhe çështje delikate mbetën vetëm në mendjen e universali tonë dhe nuk u shkruan kurrë. Siç shpjegoi më vonë Anatoli, ai u nxituar shumë. Por varianti më i mundshëm është se ai u përball me probleme gjatë zhvillimit dhe thjesht i anashkaloi ato, pa i shkruar kurrë.

Ishte dhe një situatë tjetër. Tani kemi vetëm një tester, kështu që disa detyra duhet t'i testojnë analistët, përfshirë - universalet. Prandaj, një detyrë ia dhashë një Fedorit hipotetik - "universal - mirë, le të bëj unë, pasi askush tjetër s‘është".
Fedori është "tre në një", por për këtë detyrë tashmë ishte caktuar një zhvillues. Kështu, Fedori duhej të bashkëngjiste vetëm analistin dhe testerin në vete.

Kërkesat janë mbledhur, specifikimi është dorëzuar për zhvillim, tani është koha për të testuar. Fyodor e njeh sistemin që po zhvillohet "si pesë gishta" dhe e ka punuar me hollësi kërkesat aktuale. Prandaj, ai nuk e shqetësoi veten me hartimin e skenarëve të testimit, por kryen testimin se "si duhet të punojë sistemi", më pas – ia dorëzoi përdoruesve.
Testi përfundoi, zhvillimi është dërguar në prodhim. Më vonë u zbulua se sistemi jo vetëm pezullon pagesat për llogaritë e caktuara të bilancit, por gjithashtu bllokon pagesat nga llogari të brendshme shumë të rralla, të cilat nuk duhej të ishin përfshirë në këtë.

Kjo ndodhi për shkak se Fyodor nuk e realizoi kontrollin se si "nuk duhet të punojë sistemi", nuk përpiloi plan testimi, lista kontrolluese. Ai vendosi të kursejë kohë dhe u mbështet në intuitën e tij.

Si merren me problemet?

Situata të tilla ndikojnë në efikasitetin e punës së ekipit, cilësinë e versioneve që lëshohen dhe kënaqësinë e klientëve. Prandaj, ato nuk duhet lënë pa vëmendje dhe analizë të shkaqeve.

1. Për çdo detyrë që ka shkaktuar vështirësi, kërkoj të plotësohet një formular i unifikuar: një hartë gabimesh, e cila lejon të identifikohet faza në të cilën ndodhi "prishja":

2. Pas identifikimit të pikave të ngushta, një brainstorming "Çfarë të ndryshohet?" (rastet specifike nuk shqyrtohen në retro) zhvillohet me çdo punonjës që ka ndikuar në problem, duke lindur kështu veprime konkrete (për çdo lloj personaliteti të ndryshme) me afate.

3. Kemi vendosur rregulla për ndërveprimin brenda ekipit. Për shembull, kemi rënë dakord të regjistrojmë gjithmonë të gjitha informacionet për avancimin e detyrës në sistemin e menaxhimit të projekteve. Kur ndodhin ndryshime/identifikime të artefakteve gjatë procesit të zhvillimit, kjo duhet të shfaqet në bazën e njohurive dhe versionin përfundimtar të specifikimit të kërkesave.

4. Kontrolli tani kryhet në çdo fazë (vëmendje të veçantë i kushtohet fazave problematike në të kaluarën) dhe automatikisht në përputhje me rezultatet e realizimit të detyrës së ardhshme.

5. Nëse rezultati për detyrën e ardhshme nuk ka ndryshuar, atëherë nuk e vendos universalin e shqyrtuar në rolin në të cilin nuk po performon mirë. Mundohem të vlerësoj aftësinë dhe dëshirën e tij për të zhvilluar kompetencat në këtë rol. Nëse nuk gjej reagim, e lë atë në rolin që është më afër.

Çfarë ne fund kemi arritur?

Procesi i zhvillimit është bërë më transparent. Faktori BUS është reduktuar. Anëtarët e ekipit, duke punuar mbi gabimet, bëhen më të motivuar dhe përmirësojnë karmën e tyre. Ne gradualisht po rritim cilësinë e lëshimeve tona.

Përfundimet

Punonjësit universale kanë avantazhet dhe disavantazhet e tyre.

Avantazhet:

mund të mbyllet në çdo moment një detyrë që ngec ose të zgjidhet një bug urgjent në kohë të shpejtë;
qasje gjithëpërfshirëse në zgjidhjen e problemeve: ekzekutuesi e shikon atë nga të gjitha rolet;
universalet mund të bëjnë pothuajse gjithçka po aq mirë.

Disavantazhet:

nënshkruhet faktori BUS;
kompetencat kryesore, të cilat i takojnë rolit, shuhen. Për këtë arsye, cilësia e punës bie;
rritet probabiliteti i vonesës së afateve, pasi mungon kontrolli në çdo fazë. Gjithashtu lindin rreziqe për krijimin e një 'ylli': punonjësi është i sigurt se ai e di më mirë, se ai është një profesionist;
rritet rreziku i shterjes profesionale;
shumë informacion të rëndësishëm mbi projektin mund të mbetet vetëm 'në mendjen' e punonjësit.

Siç e shihni, disavantazhet janë më të shumta. Prandaj, unë përdor universale vetëm nëse mungojnë burimet dhe detyra është mjaft urgjente. Ose nëse personi ka kompetenca që mungojnë te të tjerët, ndërsa cilësia është në rrezik.

Nëse në punën e përbashkët mbi një detyrë respektohet rregulli i shpërndarjes së roleve, atëherë cilësia e punës rritet. Ne i shohim problemet nga këndvështrime të ndryshme, pamja nuk bëhet e mjegullt, gjithmonë shfaqen mendime të reja. Në të njëjtën kohë, çdo anëtar i ekipit ka të gjitha mundësitë për rritje profesionale dhe zgjerimin e kompetencave të tij.

Unë mendoj se gjëja më e rëndësishme është ndjenja e lidhjes me procesin, të angazhoheni në punën tuaj, duke rritur gradualisht gjërësinë e kompetencave tuaja. Megjithatë, universalet në ekip sjellin përfitime: më e rëndësishmja është të bëni që ata të kombinojnë efektivisht rollet e ndryshme.

U uroj të gjithëve një ekip të vetorganizuar 'universalesh-mjeshtrave të zanatçeve të tyre'!

Burimi: habr.com