ā€œUniversālsā€ izstrādes komandā: labums vai kaitējums?

ā€œUniversālsā€ izstrādes komandā: labums vai kaitējums?

Sveiki visiem! Mani sauc Ludmila Makarova, es esmu UBRD attÄ«stÄ«bas vadÄ«tāja, un treŔā daļa manas komandas ir ā€œÄ£enerālistiā€.

AtzÄ«stiet: katrs tehniskais vadÄ«tājs sapņo par savstarpēju funkcionalitāti savā komandā. Tas ir tik forÅ”i, kad viens cilvēks spēj nomainÄ«t trÄ«s un pat darÄ«t to efektÄ«vi, neaizkavējot termiņus. Un, galvenais, tas ietaupa resursus!
Tas izklausās ļoti vilinoÅ”i, bet vai tieŔām tā ir? Mēģināsim to izdomāt.

Kas viņŔ ir, mÅ«su cerÄ«bu priekÅ”tecis?

Termins ā€œÄ£enerālistsā€ parasti attiecas uz komandas locekļiem, kuri apvieno vairāk nekā vienu lomu, piemēram, izstrādātājs-analÄ«tiÄ·is.

Komandas mijiedarbība un tās darba rezultāts ir atkarīgs no dalībnieku profesionālajām un personiskajām īpaŔībām.

Par cietajām prasmēm viss ir skaidrs, taču mÄ«kstās prasmes ir pelnÄ«juÅ”as Ä«paÅ”u uzmanÄ«bu. Tie palÄ«dz atrast pieeju darbiniekam un virzÄ«t uz uzdevumu, kurā viņŔ bÅ«s visnoderÄ«gākais.

Ir daudz rakstu par visu veidu personības tipiem IT nozarē. Pamatojoties uz savu pieredzi, es iedalītu IT vispārīgos speciālistus četrās kategorijās:

1. ā€œUniversāls ā€” visvarenaisā€

Tādas ir visur. Viņi vienmēr ir ļoti aktÄ«vi, vēlas bÅ«t uzmanÄ«bas centrā, pastāvÄ«gi jautā kolēģiem, vai viņiem nepiecieÅ”ama viņu palÄ«dzÄ«ba, un dažreiz viņi var bÅ«t pat kaitinoÅ”i. Viņus interesē tikai jēgpilni uzdevumi, kuru piedalÄ«Å”anās dos vietu radoÅ”umam un var uzjautrināt viņu lepnumu.

Ar ko viņi ir spēcīgi:

  • spēj risināt sarežģītas problēmas;
  • dziļi ienirt problēmā, ā€œraktā€ un sasniegt rezultātus;
  • ir zinātkārs prāts.

Bet:

  • emocionāli labila;
  • slikti pārvaldÄ«ts;
  • ir savs nesatricināms viedoklis, kuru ir ļoti grÅ«ti mainÄ«t;
  • Ir grÅ«ti piespiest kādu izdarÄ«t vienkārÅ”u lietu. Viegli uzdevumi ievaino visvarenā ego.

2. ā€œUniversāli ā€” es izdomāŔu un izdarÄ«Å”uā€

Šādiem cilvēkiem ir nepiecieÅ”ama tikai rokasgrāmata un nedaudz laika - un viņi atrisinās problēmu. Viņiem parasti ir spēcÄ«ga DevOps pieredze. Šādi vispārÄ«gi speciālisti neapgrÅ«tina sevi ar dizainu un dod priekÅ”roku izstrādes metodei, kas balstÄ«ta tikai uz viņu pieredzi. Viņi var viegli apspriesties ar tehnisko vadÄ«tāju par izvēlēto uzdevuma izpildes variantu.

Ar ko viņi ir spēcīgi:

  • neatkarÄ«gs;
  • izturÄ«gs pret stresu;
  • kompetents daudzos jautājumos;
  • erudÄ«ts - ar viņiem vienmēr ir par ko parunāt.

Bet:

  • bieži pārkāpj pienākumus;
  • mēdz visu sarežģīt: atrisināt reizināŔanas tabulu, integrējot pa daļām;
  • darba kvalitāte zema, viss strādā 2-3 reizes;
  • Viņi pastāvÄ«gi pārbÄ«da termiņus, jo patiesÄ«bā viss izrādās nemaz tik vienkārÅ”i.

3. ā€œUniversāli ā€” labi, ļaujiet man to izdarÄ«t, jo nav neviena citaā€

Darbinieks labi pārzina vairākas jomas un viņam ir atbilstoÅ”a pieredze. Taču viņam neizdodas kļūt par profesionāli nevienā no tiem, jo ā€‹ā€‹viņŔ bieži tiek izmantots kā glābÅ”anas riņķis, aizbāžot caurumus aktuālajos uzdevumos. ElastÄ«gs, efektÄ«vs, uzskata sevi par pieprasÄ«tu, bet nav.

Praktisks ideāls darbinieks. Visticamāk, viņam ir kāds virziens, kas viņam patÄ«k vislabāk, taču kompetenču izplÅ«Å”anas dēļ attÄ«stÄ«ba nenotiek. Tā rezultātā cilvēks riskē kļūt nepieprasÄ«ts un emocionāli izdegts.

Ar ko viņi ir spēcīgi:

  • atbildÄ«gs;
  • uz rezultātu orientēts;
  • mierÄ«gs;
  • pilnÄ«bā kontrolēts.

Bet:

  • uzrāda vidējos rezultātus zemā kompetenču lÄ«meņa dēļ;
  • nevar atrisināt sarežģītas un abstraktas problēmas.

4. ā€œVispusÄ«gs cilvēks ir sava amata meistarsā€

Personai ar nopietnu izstrādātāja pieredzi ir sistēmiskā domāŔana. Pedantisks, prasÄ«gs pret sevi un savu komandu. JebkurÅ” uzdevums, kas saistÄ«ts ar viņu, var pieaugt bezgalÄ«gi, ja nav noteiktas robežas.

ViņŔ labi pārzina arhitektÅ«ru, izvēlas tehniskās realizācijas metodi, rÅ«pÄ«gi analizējot izvēlētā risinājuma ietekmi uz paÅ”reizējo arhitektÅ«ru. PieticÄ«gs, ne ambiciozs.

Ar ko viņi ir spēcīgi:

  • parādÄ«t augstu darba kvalitāti;
  • spēj atrisināt jebkuru problēmu;
  • ļoti efektÄ«va.

Bet:

  • neiecietÄ«ba pret citu viedokli;
  • maksimālisti. Viņi cenÅ”as visu darÄ«t pareizi, un tas palielina izstrādes laiku.

Kas mums ir praksē?

ApskatÄ«sim, kā lomas un kompetences visbiežāk tiek apvienotas. Ņemsim par sākumpunktu standarta izstrādes komandu: PO, izstrādes vadÄ«tājs (tehnoloÄ£ijas vadÄ«tājs), analÄ«tiÄ·i, programmētāji, testētāji. Mēs neņemsim vērā produkta Ä«paÅ”nieku un tehnisko vadÄ«tāju. Pirmais ir saistÄ«ts ar tehnisko kompetenču trÅ«kumu. Otrajam, ja komandā ir problēmas, jāspēj visu.

VisizplatÄ«tākā kompetenču apvienoÅ”anas/apvienoÅ”anas/apvienoÅ”anas iespēja ir izstrādātājs-analÄ«tiÄ·is. Ä»oti bieži ir arÄ« testÄ“Å”anas analÄ«tiÄ·is un ā€œtrÄ«s vienāā€.

Izmantojot savu komandu kā piemēru, es jums parādÄ«Å”u savu kolēģu vispārÄ«go speciālistu plusus un mÄ«nusus. Manā komandā ir treŔā daļa no viņiem, un es viņus ļoti mÄ«lu.

PO saņēma steidzamu uzdevumu ieviest jaunus tarifus esoÅ”ajā produktā. Manā komandā ir 4 analÄ«tiÄ·i. TobrÄ«d viens bija atvaļinājumā, otrs slimoja, pārējie nodarbojās ar stratēģisko uzdevumu izpildi. Ja es tos izvilktu, tas neizbēgami izjauktu ievieÅ”anas termiņus. Bija tikai viena izeja: izmantot "slepeno ieroci" - daudzpusÄ«gu izstrādātāju-analÄ«tiÄ·i, kurÅ” apguva nepiecieÅ”amo priekÅ”metu jomu. Sauksim viņu par Anatoliju.

Viņa personÄ«bas tips ir ā€œUniversāli ā€“ es izdomāŔu un izdarÄ«Å”uā€. Protams, viņŔ ilgu laiku mēģināja paskaidrot, ka viņam "ir pilns uzdevumu atlikums", bet pēc mana stingrā lēmuma viņŔ tika nosÅ«tÄ«ts steidzami atrisināt problēmu. Un Anatolijs to izdarÄ«ja! ViņŔ veica iestudējumu un pabeidza ievieÅ”anu laikā, un klienti bija apmierināti.

No pirmā acu uzmetiena viss izdevās. Bet pēc dažām nedēļām Å”im produktam atkal radās prasÄ«bas pēc uzlabojumiem. Tagad Ŕīs problēmas formulējumu veica ā€œtÄ«rsā€ analÄ«tiÄ·is. Jaunizstrādes testÄ“Å”anas stadijā mēs ilgi nevarējām saprast, kāpēc rodas kļūdas jauno tarifu sasaistÄ«Å”anā, un tikai tad, visu jucekli atŔķetinājuÅ”i, nonācām lÄ«dz patiesÄ«bai. Mēs iztērējām daudz laika un nokavējām termiņus.

Problēma bija tā, ka daudzi slēptie momenti un slazds palika tikai mÅ«su universāla galvā un netika pārnesti uz papÄ«ra. Kā vēlāk paskaidroja Anatolijs, viņŔ pārāk steidzās. Bet visticamākais variants ir tāds, ka viņŔ jau izstrādes laikā saskārās ar problēmām un vienkārÅ”i tās apieta, to nekur neatspoguļojot.

Bija cita situācija. Tagad mums ir tikai viens testētājs, tāpēc daži uzdevumi ir jāpārbauda analītiķiem, tostarp vispārējiem. Tāpēc es uzdevu vienu uzdevumu nosacītajam Fjodoram - "Universāls - labi, ļaujiet man to izdarīt, jo nav neviena cita".
Fjodors ir ā€œtrÄ«s vienāā€, taču Å”im uzdevumam jau ir pieŔķirts izstrādātājs. Tas nozÄ«mē, ka Fedjai bija jāapvieno tikai analÄ«tiÄ·is un testētājs.

PrasÄ«bas savāktas, specifikācija nodota izstrādei, laiks testēt. Fjodors zina, ka sistēma tiek modificēta ā€œkā savu rokuā€ un ir rÅ«pÄ«gi izstrādājis paÅ”reizējās prasÄ«bas. Tāpēc viņŔ neapgrÅ«tināja sevi ar testa skriptu rakstÄ«Å”anu, bet veica testÄ“Å”anu, ā€œkā sistēmai jādarbojasā€, pēc tam nodeva to lietotājiem.
Pārbaude tika pabeigta, pārskatÄ«Å”ana nonāca ražoÅ”anā. Vēlāk izrādÄ«jās, ka sistēma ne tikai apturēja maksājumus uz noteiktiem bilances kontiem, bet arÄ« bloķēja maksājumus no ļoti retiem iekŔējiem kontiem, kuriem nebija paredzēts tajā piedalÄ«ties.

Tas notika tāpēc, ka Fjodors nepārbaudÄ«ja, kā ā€œsistēmai nevajadzētu darbotiesā€, nesagatavoja testa plānu vai kontrolsarakstus. ViņŔ nolēma ietaupÄ«t laiku un paļauties uz saviem instinktiem.

Kā tiekam galā ar problēmām?

Šādas situācijas ietekmē komandas darbību, izlaiduma kvalitāti un klientu apmierinātību. Tāpēc tos nevar atstāt bez uzmanības un iemeslu analīzes.

1. Katram uzdevumam, kas radÄ«ja grÅ«tÄ«bas, lÅ«dzu aizpildÄ«t vienotu veidlapu: kļūdu karti, kas ļauj identificēt posmu, kurā notikusi ā€œizņemÅ”anaā€:

ā€œUniversālsā€ izstrādes komandā: labums vai kaitējums?

2. Pēc vājo vietu noteikÅ”anas tiek rÄ«kota prāta vētras sesija ar katru darbinieku, kurÅ” ietekmējis problēmu: ā€œKo mainÄ«t?ā€ (ipaÅ”us gadÄ«jumus retrospektÄ«vi neapskatām), kā rezultātā dzimst konkrētas darbÄ«bas (katram personÄ«bas tipam specifiskas) ar termiņiem.

3. Mēs esam ieviesuÅ”i noteikumus mijiedarbÄ«bai komandā. Piemēram, mēs vienojāmies, ka visu informāciju par uzdevuma gaitu obligāti ierakstÄ«sim projekta vadÄ«bas sistēmā. Ja izstrādes procesā tiek mainÄ«ti/identificēti artefakti, tas ir jāatspoguļo zināŔanu bāzē un tehnisko specifikāciju galÄ«gajā versijā.

4. Kontroli sāka veikt katrā posmā (Ä«paÅ”a uzmanÄ«ba tiek pievērsta problemātiskajiem posmiem pagātnē) un automātiski, pamatojoties uz nākamā uzdevuma rezultātiem.

5. Ja rezultāts nākamajā uzdevumā nav mainÄ«jies, es nelieku apÅ”aubāmo Ä£enerālistu lomā, kurā viņŔ tiek galā slikti. Es cenÅ”os novērtēt viņa spējas un vēlmi attÄ«stÄ«t kompetences Å”ajā amatā. Ja neatrodu atbildi, atstāju viņu lomā, kas viņam ir tuvāka.

Kas beigās notika?

Attīstības process ir kļuvis caurskatāmāks. BUS faktors ir samazinājies. Komandas dalībnieki, strādājot pie kļūdām, kļūst motivētāki un uzlabo savu karmu. Mēs pakāpeniski uzlabojam savu izlaidumu kvalitāti.

ā€œUniversālsā€ izstrādes komandā: labums vai kaitējums?

Atzinumi

Vispārīgajiem darbiniekiem ir savi plusi un mīnusi.

priekŔrocības:

  • jÅ«s jebkurā laikā varat aizvērt noslÄ«dējuÅ”u uzdevumu vai Ä«sā laikā novērst steidzamu kļūdu;
  • integrēta pieeja problēmas risināŔanai: izpildÄ«tājs uz to raugās no visu lomu perspektÄ«vas;
  • Ä£enerālisti var darÄ«t gandrÄ«z visu vienlÄ«dz labi.

Trūkumi:

  • BUS faktors palielinās;
  • lomai raksturÄ«gās pamatkompetences ir sagrautas. Sakarā ar to samazinās darba kvalitāte;
  • termiņu nobÄ«des iespējamÄ«ba palielinās, jo katrā posmā nav kontroles. Pastāv arÄ« ā€œzvaigznesā€ izaugÅ”anas riski: darbinieks ir pārliecināts, ka viņŔ labāk zina, ka ir profesionālis;
  • palielinās profesionālās izdegÅ”anas risks;
  • daudz svarÄ«gas informācijas par projektu var palikt tikai darbinieka ā€œgalvāā€.

Kā redzat, ir vairāk trūkumu. Tāpēc es izmantoju vispārīgus tikai tad, ja nepietiek resursu un uzdevums ir diezgan steidzams. Vai arī cilvēkam ir kompetences, kuru citiem trūkst, bet uz spēles ir likta kvalitāte.

Ja kopÄ«gā darbā pie uzdevuma tiek ievērots lomu sadales likums, tad darba kvalitāte paaugstinās. Mēs skatāmies uz problēmām no dažādiem rakursiem, mÅ«su skats nav izplÅ«dis, vienmēr parādās svaigas domas. Tajā paŔā laikā katram komandas loceklim ir visas iespējas profesionālai izaugsmei un kompetenču paplaÅ”ināŔanai.

Uzskatu, ka svarÄ«gākais ir justies iesaistÄ«tam procesā, darÄ«t savu darbu, pakāpeniski palielinot savu kompetenču plaÅ”umu. Tomēr Ä£enerālistiem komandā ir priekÅ”rocÄ«bas: galvenais ir nodroÅ”ināt, ka viņi efektÄ«vi apvieno dažādas lomas.

Novēlu visiem paÅ”organizējoÅ”u ā€œuniversālu sava amata meistaruā€ komandu!

Avots: www.habr.com

Pievieno komentāru