Përshëndetje të gjithëve! Jam Lyudmila Makarova, menaxhere e zhvillimit në UBRiR dhe një e treta e ekipit tim janë "universale".
Pranoni: çdo Tech Lead ëndërron për kros-funksionalitetin brenda ekipit të tij. E pra, është kaq e shkëlqyer kur një person mund të zëvendësojë tre të tjerë, madje duke e bërë këtë cilësisht dhe pa i vonuar afatet. Dhe, e rëndësishme, kjo siguron kursimin e burimeve!
Dëgjohet shumë joshëse, por a është kështu në të vërtetë? Le të përpiqemi të zbërthejmë.
Kush është ai, parashikuesi ynë të pritshmërive?
Nën kuptimin "universal" zakonisht kuptojmë anëtarët e ekipit që kombinojnë më shumë se një rol, për shembull, zhvillues-analist.
Ndërveprimi i ekipit dhe rezultati i punës së tij varen nga cilësitë profesionale dhe personale të pjesëmarrësve.
Për hard skills gjithçka është e qartë, por soft skills meritojnë vëmendje të veçantë. Ato ndihmojnë në gjetjen e qasjes së duhur ndaj punonjësve dhe në drejtimin e tyre pikërisht në atë detyrë, për të cilën do të jenë sa më të dobishëm.
EkzistojnĂ« shumĂ« artikuj mbi llojet e ndryshme tĂ« personaliteteve tĂ« pĂ«rfaqĂ«suesve tĂ« industrisĂ« IT. Duke u mbĂ«shtetur nĂ« pĂ«rvojĂ«n time, do tâi ndaja IT-universalĂ«t nĂ« katĂ«r kategori:
1. "Universal â i pafuqishĂ«m"
Ka disa 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ë irritojnë. I interesojnë vetëm detyrat e rëndësishme, pjesëmarrja në të cilat do t'i japë hapësirë për krijimtari dhe do t'i njohë vetveten.
ĂfarĂ« janĂ« tĂ« fortĂ«:
- kanë aftësi për të zgjidhur probleme të komplikuara;
- thellësisht përfshihen në problem, "gërmojnë" dhe arrijnë rezultate;
- kanë një mendje kurioze.
Por:
- janë emocionalisht të paqëndrueshëm;
- janë të menaxhueshëm;
- kanë pikëpamje të palëkundura, të cilat është shumë e vështirë t'i ndryshosh;
- është e vështirë t'i bësh të kryejnë një punë të thjeshtë. Detyrat e lehta prekin krenarinë e të pafuqishmëve.
2. "Universal â do ta zgjidh dhe do ta bĂ«j"
Për këta njerëz, një manual dhe pak kohë janë të mjaftueshme për të zgjidhur problemin. Zakonisht kanë një përvojë të madhe si DevOps. Këta universalë nuk lodhen me projektimin dhe preferojnë të përdorin metodën e zhvillimit bazuar vetëm në përvojën e tyre. Mund të njihen lehtësisht me tech lead përsa i përket opsionit të realizimit të detyrës.
ĂfarĂ« janĂ« tĂ« fortĂ«:
- janë të pavarur;
- janë rezistent ndaj stresit;
- janë të kompetentë në shumë çështje;
- janĂ« tĂ« shkathĂ«t â gjithmonĂ« ka çfarĂ« tĂ« diskutohet me ta.
Por:
- shpesh shkelin angazhimet;
- kanë tendencën për të komplikuar gjithçka: zgjidhin tabelën e shumzimit duke integruar sipas pjesëve;
- cilësia e punës është e ulët, gjithçka del me 2-3 herë;
- përgjatë kohës shpesh e vonojnë, sepse në të vërtetë gjithçka ndodh më e komplikuar nga sa pritej.
3. "Universal â mirĂ«, le tĂ« shoh unĂ«, sepse nuk ka kush tjetĂ«r"
PunonjĂ«si ka njĂ« njohuri tĂ« mirĂ« nĂ« disa fusha dhe ka 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Ă« shpĂ«timtar, mbushur boshllĂ«qet nĂ« detyrat aktuale. ĂshtĂ« i shkathĂ«t, i pĂ«rshtatshĂ«m, mendon se Ă«shtĂ« i kĂ«rkuar, por nuk Ă«shtĂ«.
Punonjësi praktik ideal. Shumë mundësi për t'u zhvilluar në një fushë, por për shkak të shpërbërjes së aftësive, zhvillimi nuk ndodh. Si rezultat, njeriu rrezikon të bëhet i padëshiruar dhe emocionalisht i djegur.
ĂfarĂ« janĂ« tĂ« fortĂ«:
- janë të përgjegjshëm;
- kanë një fokus në rezultat;
- janë të qetë;
- janë të plotë në menaxhim.
Por:
- tregojnë rezultate mesatare për shkak të nivelit të ulët të kompetencës;
- nuk mund të zgjidhin detyra të komplikuara dhe abstrakte.
4. "Universal â mjeshtĂ«r i zanatit tĂ« vet"
NjĂ« njeri me njĂ« pasbackground serioz si zhvillues, posedon mendimin sistemor. Ka njĂ« etikĂ« tĂ« lartĂ«, kĂ«rkon nga vetvetja dhe ekipi. Ădo detyrĂ« me pjesĂ«marrjen e tij mund tĂ« zgjasĂ« pafundĂ«sisht nĂ«se kufijtĂ« nuk janĂ« tĂ« qarta.
Njihet 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.
ĂfarĂ« janĂ« tĂ« fortĂ«:
- tregojnë cilësi të lartë pune;
- kanë aftësi për të zgjidhur çdo detyrë;
- janë shumë të punësuar.
Por:
- janë të padurueshëm ndaj mendimeve të tjerëve;
- janë maksimalistë. Përpiqen të bëjnë gjithçka siç duhet, dhe kjo e rrit kohën e zhvillimit.
ĂfarĂ« kemi nĂ« praktikĂ«?
TĂ« shohim se si shpesh bashkohen rolet dhe kompetencat. TĂ« marrim si pikĂ« tĂ« nisjes njĂ« ekip standard zhvillimi: PO, menaxher zhvillimi (tech lead), analistĂ«, programues, testues. Nuk do ta konsiderojmĂ« pronarin e produktit dhe tech lead. TĂ« parin â pĂ«r shkak tĂ« mungesĂ«s sĂ« kompetencave teknike. TĂ« dytin, nĂ«se ka probleme nĂ« ekip, duhet tĂ« jetĂ« nĂ« gjendje tĂ« bĂ«jĂ« gjithçka.
Varianti më i zakonshëm i kombinimit të kompetencave është zhvillues-analist. Shumë shpesh hasen gjithashtu analist-tester dhe "tre në një".
Me shembullin e ekipit tim, do të tregoj se cilat janë përfitimet dhe disavantazhet e kolegëve universale. Në ekipin tim ata përbëjnë një të tretën, dhe unë i dua shumë.
Nga PO morĂ«m njĂ« detyrĂ« urgjente pĂ«r tĂ« zbatuar tarifat e reja nĂ« produktin ekzistues. NĂ« ekipin tim janĂ« 4 analistĂ«. NĂ« atĂ« kohĂ«, njĂ«ri ishte nĂ« pushim, tjetri ishte i sĂ«murĂ«, ndĂ«rsa tĂ« tjerĂ«t po merreshin me realizimin e detyrave strategjike. NĂ«se do tĂ« merrja ndonjĂ« prej tyre, sigurisht qĂ« do tĂ« vononte realizimin. Ka mbetur njĂ« zgjidhje e vetme: tĂ« pĂ«rdorim "armĂ«n sekrete" â njĂ« zhvillues-analist universal, i cili zotĂ«ronte fushĂ«n e nevojshme. Ta quajmĂ« atĂ« Anatol.
Tipi i tij i personalitetit Ă«shtĂ« "universal â do ta kuptoj dhe do ta bĂ«j". Sigurisht, ai pĂ«rpiqej gjatĂ« tĂ« shpjegonte se kishte "njĂ« back-log tĂ« plotĂ«" tĂ« detyrave tĂ« tij, por me vendimin tim tĂ« fortĂ« u dĂ«rgua pĂ«r tĂ« zgjidhur detyrĂ«n urgjente. Dhe Anatoli e pĂ«rfundoi! Ai realizoi dhe pĂ«rfundoi detyrĂ«n nĂ« kohĂ«, dhe klientĂ«t mbetĂ«n tĂ« kĂ«naqur.
Në pamje të parë gjithçka arriti. Por disa javë më vonë u shfaqën kërkesa për përshtatjen e këtij produkti. Tani postimi për këtë detyrë e bënte një "analist i pastër". Në fazën e testimit të zhvillimit të ri, ne nuk mundëm për një kohë të gjatë të kuptonim pse kishim gabime me lidhjen e tarifave të reja dhe vetëm më pas, duke deshifruar të gjithë këtë palë, arritëm në të vërtetën. Ne shpërdoruam shumë kohë dhe vonuam afatet.
Problemi ishte se shumë momente të fshehura dhe pengesa u mbajtën vetëm në mendjen e universales tonë dhe nuk u transferuan në letër. Siç shpjegoi më vonë Anatoli, ai ishte shumë i nxituar. Por varianti më i mundshëm është se ai u përball me probleme gjatë zhvillimit dhe thjesht i anashkaloi, pa i reflektuar askund.
Ishte edhe njĂ« situatĂ« tjetĂ«r. Tani kemi vetĂ«m njĂ« tester, prandaj disa detyra duhet tĂ« testohen nga analistĂ«t, pĂ«rfshirĂ« â universale. Prandaj, njĂ« detyrĂ« ia dhashĂ« Fedorit â "universale â mirĂ«, le tĂ« bĂ«j unĂ«, pasi nuk ka askĂ«nd tjetĂ«r".
Fedori është "tre në një", por për këtë detyrë ishte caktuar një zhvillues. Këshillohet që Fedori të kombinojë vetëm analistin dhe testerin në vetvete.
Kërkesat janë mbledhur, specifikimi iu kalua zhvillimit, është koha për të testuar. Fedori e njeh sistemin e përmirësuar "si pesë gishta" dhe ka përpunuar në detaje kërkesat aktuale. Prandaj, ai nuk e ndjeu nevojën për të shkruar skenarët e testimit, por bëri testimin për atë "si sistemi duhet të punojë", pastaj e kaloi tek përdoruesit.
Testi përfundoi, përmirësimi u dërgua në prodhim. Më vonë doli se sistemi jo vetëm që ndalon kryerjen e pagesave në llogaritë e caktuara të bilancit, por gjithashtu bllokon kryerjen e pagesave nga llogaritë e brendshme shumë të rralla, të cilat nuk duhej të ishin përfshirë në këtë.
Kjo ndodhi për shkak se Fedori nuk e bëri kontrollin se si "nuk duhet të punojë sistemi", nuk e përgatiti planin e testit, listat e kontrollit. Ai u përpoq të kursente në kohë dhe u mbështet në instinktin e tij.
Si punojmë me problemet?
Situata të tilla ndikojnë në efikasitetin e ekipit, cilësinë e sënjarëve të lëshuar 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ë shkaktoi vështirësi, kërkoj të plotësohet një formular i standardizuar: karta e gabimeve, e cila ndihmon në identifikimin e fazës, ku ndodhi "rrëshqitja":
2. Pas identifikimit tĂ« ngushticave, me çdo punonjĂ«s qĂ« ndikoi nĂ« problemin, zhvillohet njĂ« brain-storm "ĂfarĂ« tĂ« ndryshojmĂ«?" (rastet specifike nuk diskutohet nĂ« retrom), pas tĂ« cilit lindin veprime konkrete (pĂ«r çdo lloj personaliteti tĂ« vetat) me afatet.
3. Ne kemi futur rregulla bashkĂ«punimi brenda ekipit. PĂ«r shembull, u dakorduam tĂ« regjistrojmĂ« gjithmonĂ« tĂ« gjitha informacionet mbi ecurinĂ« e detyrĂ«s nĂ« sistemin e menaxhimit tĂ« projekteve. NĂ«se ka ndryshime ose zbulohet artefakte gjatĂ« zhvillimit, kĂ«to duhet tĂ« reflektohen nĂ« bazĂ«n e tĂ« dhĂ«nave dhe versionin pĂ«rfundimtar tĂ« TĂ.
4. Kontrolli u bë në çdo fazë (vëmendje të veçantë i kushtohet fazave problematike në të kaluarën) dhe automatikisht sipas rezultateve të realizimit të detyrës tjetër.
5. Nëse rezultati për detyrën tjetër nuk është ndryshuar, atëherë nuk e caktova universalen e shqyrtuar në rolin ku ai ka performuar keq. Përpiqem 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 tij.
ĂfarĂ« doli nĂ« fund?
Procesi i zhvillimit është bërë më transparent. Faktorët e BUS janë zvogëluar. 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 e rrisim cilësinë e lëshimeve tona.
PĂ«rfundimet
Punonjësit multi-funksionalë kanë avantazhet dhe disavantazhet e tyre.
Përparësitë:
- mund të mbyllej çdoherë një detyrë që vonohet ose të zgjidhim një bug urgjent në kohë të shkurtër;
- qasje holistike në zgjidhjen e problemit: ekzekutuesi e sheh atë nga të gjitha këndvështrimet;
- multi-funksionalët mund të bëjnë praktikisht gjithçka po aq mirë.
Disavantazhet:
- rritet faktori BUS;
- kompetencat kryesore që i përkasin rolit zbuten. Kjo shkakton një ulje të cilësisë së punës;
- rritet probabiliteti i shtyrjes së afateve, pasi mungon kontrolli në secilën fazë. Gjithashtu lidhen rreziqe për rritjen e "yjeve": punonjësi është i sigurt se di më mirë, se është profesionist;
- rritet rreziku i shterjes profesionale;
- shumë informacion të rëndësishëm për projektin mund të mbetet vetëm në "kokën" e punonjësit.
Siç e shihni, ka më shumë disavantazhe. Prandaj, unë përdor multi-funksionalët vetëm kur ka mungesë burimesh dhe detyra është mjaft urgjente. Ose kur një person ka kompetenca që mungojnë te të tjerët, dhe cila është cilësia që është në rrezik.
Nëse gjatë punës së përbashkët mbi detyrën, respektohet rregulli i shpërndarjes së roleve, atëherë cilësia e punës rritet. Ne i shqyrtojmë problemet nga këndvështime të ndryshme, pamja nuk nxjerr sy të mbyllur, gjithmonë shfaqen ide të freskëta. Në të njëjtën kohë, çdo pjesëtar i ekipit ka të gjitha mundësitë për rritje profesionale dhe zgjerimin e kompetencave të tij.
Unë besoj se më e rëndësishmja është të ndiheni të lidhur me procesin, të bëni punën tuaj dhe gradualisht të rrisni gjerësinë e kompetencave tuaja. Megjithatë, multi-funksionalët në ekip sjellin përfitim: e rëndësishmja është të bëni që ata të kombinojnë efektivisht role të ndryshme.
Uroj gjithë ekipet vetë-organizuese të "multi-funksionalëve të mjeshtrave të tyre!"
Burimi: habr.com
