"Universal" sa development team: benepisyo o pinsala?

"Universal" sa development team: benepisyo o pinsala?

Kamusta kayong lahat! Ang pangalan ko ay Lyudmila Makarova, ako ay isang development manager sa UBRD at ang ikatlong bahagi ng aking koponan ay "mga heneral".

Aminin mo: bawat Tech Lead ay nangangarap ng cross-functionality sa loob ng kanilang team. Napakahusay kapag ang isang tao ay kayang palitan ang tatlo, at kahit na gawin ito nang mahusay, nang hindi naaantala ang mga deadline. At, mahalaga, nakakatipid ito ng mga mapagkukunan!
Parang napaka tempting, pero ganun ba talaga? Subukan nating malaman ito.

Sino siya, ang ating tagapagpauna sa mga inaasahan?

Ang terminong "generalist" ay karaniwang tumutukoy sa mga miyembro ng koponan na pinagsama ang higit sa isang tungkulin, halimbawa, developer-analyst.

Ang pakikipag-ugnayan ng koponan at ang resulta ng trabaho nito ay nakasalalay sa mga propesyonal at personal na katangian ng mga kalahok.

Ang lahat ay malinaw tungkol sa matapang na kasanayan, ngunit ang mga malambot na kasanayan ay nararapat na espesyal na atensyon. Tumutulong sila upang makahanap ng isang diskarte sa isang empleyado at idirekta siya sa gawain kung saan siya ay magiging pinaka-kapaki-pakinabang.

Maraming mga artikulo tungkol sa lahat ng uri ng personalidad sa industriya ng IT. Batay sa aking karanasan, hahatiin ko ang mga IT generalist sa apat na kategorya:

1. β€œUniversal – Makapangyarihan sa lahat”

Ang mga ito ay nasa lahat ng dako. Sila ay palaging napaka-aktibo, nais na maging sentro ng atensyon, patuloy na tanungin ang kanilang mga kasamahan kung kailangan nila ang kanilang tulong, at kung minsan ay nakakainis pa nga sila. Interesado lamang sila sa mga makabuluhang gawain, ang pakikilahok kung saan ay magbibigay ng puwang para sa pagkamalikhain at makapagpapasaya sa kanilang pagmamataas.

Ano ang kanilang malakas sa:

  • kayang lutasin ang mga kumplikadong problema;
  • sumisid nang malalim sa problema, "hukay" at makamit ang mga resulta;
  • magkaroon ng matanong na isip.

Ngunit:

  • emosyonal na labile;
  • hindi maayos na pinamamahalaan;
  • magkaroon ng sariling di-natitinag na pananaw, na napakahirap baguhin;
  • Mahirap magpagawa ng isang simpleng bagay. Ang mga madaling gawain ay nakakasakit sa ego ng makapangyarihan.

2. β€œUniversal – Aalamin ko at gagawin ko”

Ang ganitong mga tao ay nangangailangan lamang ng isang manwal at kaunting oras - at malulutas nila ang problema. Karaniwan silang may malakas na background sa DevOps. Ang ganitong mga generalist ay hindi nag-abala sa kanilang sarili sa disenyo at mas gusto nilang gumamit ng isang paraan ng pag-unlad batay lamang sa kanilang karanasan. Madali silang magkaroon ng talakayan sa teknikal na lead tungkol sa napiling opsyon para sa pagpapatupad ng gawain.

Ano ang kanilang malakas sa:

  • malaya;
  • lumalaban sa stress;
  • may kakayahan sa maraming isyu;
  • erudite - laging may pag-uusapan sa kanila.

Ngunit:

  • madalas na lumalabag sa mga obligasyon;
  • may posibilidad na gawing kumplikado ang lahat: lutasin ang talahanayan ng multiplikasyon sa pamamagitan ng pagsasama ng mga bahagi;
  • ang kalidad ng trabaho ay mababa, ang lahat ay gumagana ng 2-3 beses;
  • Patuloy silang nagbabago ng mga deadline, dahil sa katotohanan ang lahat ay lumalabas na hindi ganoon kasimple.

3. "Universal - okay, hayaan mo akong gawin ito, dahil walang iba"

Ang empleyado ay bihasa sa maraming lugar at may kaugnay na karanasan. Ngunit nabigo siyang maging isang propesyonal sa alinman sa mga ito, dahil madalas siyang ginagamit bilang isang salbabida, na nagbubutas sa mga kasalukuyang gawain. Pliable, mahusay, isinasaalang-alang ang kanyang sarili sa demand, ngunit hindi.

Isang praktikal na ideal na empleyado. Malamang, mayroon siyang direksyon na pinakagusto niya, ngunit dahil sa paglabo ng mga kakayahan, hindi nangyayari ang pag-unlad. Bilang resulta, ang isang tao ay nanganganib na maging hindi inaangkin at emosyonal na masunog.

Ano ang kanilang malakas sa:

  • responsable;
  • nakatuon sa resulta;
  • mahinahon;
  • ganap na kontrolado.

Ngunit:

  • ipakita ang mga average na resulta dahil sa mababang antas ng mga kakayahan;
  • hindi malulutas ang masalimuot at abstract na mga problema.

4. "Ang isang all-rounder ay isang master ng kanyang craft"

Ang isang taong may seryosong background bilang isang developer ay may pag-iisip ng system. Pedantic, hinihingi ang kanyang sarili at ang kanyang koponan. Anumang gawain na kinasasangkutan niya ay maaaring lumago nang walang katiyakan kung ang mga hangganan ay hindi tinukoy.

Kilalang-kilala niya ang arkitektura, pumipili ng isang paraan ng teknikal na pagpapatupad, maingat na sinusuri ang epekto ng napiling solusyon sa kasalukuyang arkitektura. Mahinhin, hindi ambisyoso.

Ano ang kanilang malakas sa:

  • ipakita ang mataas na kalidad ng trabaho;
  • may kakayahang malutas ang anumang problema;
  • napaka episyente.

Ngunit:

  • hindi pagpaparaan sa mga opinyon ng iba;
  • mga maximalist. Sinisikap nilang gawin ang lahat ng tama, at pinatataas nito ang oras ng pag-unlad.

Ano ang mayroon tayo sa pagsasanay?

Tingnan natin kung paano madalas na pinagsama ang mga tungkulin at kakayahan. Kunin natin ang isang standard development team bilang panimulang punto: PO, development manager (tech lead), analyst, programmer, tester. Hindi namin isasaalang-alang ang may-ari ng produkto at teknikal na lead. Ang una ay dahil sa kakulangan ng mga teknikal na kakayahan. Ang pangalawa, kung may mga problema sa koponan, ay dapat na magagawa ang lahat.

Ang pinakakaraniwang opsyon para sa pagsasama-sama/pagsasama-sama/pagsasama-sama ng mga kakayahan ay developer-analyst. Ang pagsusuri ng analyst at "tatlo sa isa" ay karaniwan din.

Gamit ang aking koponan bilang isang halimbawa, ipapakita ko sa iyo ang mga kalamangan at kahinaan ng aking mga kapwa generalist. May ikatlong bahagi sa kanila sa aking koponan, at mahal na mahal ko sila.

Nakatanggap ang PO ng isang kagyat na gawain upang ipasok ang mga bagong taripa sa isang umiiral na produkto. Ang aking koponan ay may 4 na analyst. Sa oras na iyon, ang isa ay nasa bakasyon, ang isa ay may sakit, at ang iba ay nakikibahagi sa pagpapatupad ng mga madiskarteng gawain. Kung tatanggalin ko sila, hindi maiiwasang maabala nito ang mga deadline ng pagpapatupad. Mayroon lamang isang paraan: ang paggamit ng "lihim na sandata" - isang maraming nalalaman na developer-analyst na pinagkadalubhasaan ang kinakailangang lugar ng paksa. Tawagin natin siyang Anatoly.

Yung tipong personalidad niya "Universal - Aalamin ko ito at gagawin ko". Siyempre, sinubukan niyang ipaliwanag sa mahabang panahon na siya ay "may ganap na atraso sa kanyang mga gawain," ngunit sa pamamagitan ng aking matibay na desisyon ay ipinadala siya upang lutasin ang isang kagyat na problema. At ginawa ito ni Anatoly! Isinagawa niya ang pagtatanghal at natapos ang pagpapatupad sa oras, at nasiyahan ang mga customer.

Sa unang tingin, naging maayos ang lahat. Ngunit pagkatapos ng ilang linggo, muling lumitaw ang mga kinakailangan para sa pagpapabuti para sa produktong ito. Ngayon ang pagbabalangkas ng problemang ito ay isinagawa ng isang "purong" analyst. Sa yugto ng pagsubok sa bagong pag-unlad, sa loob ng mahabang panahon ay hindi namin maintindihan kung bakit kami ay nagkakaroon ng mga pagkakamali sa pag-uugnay ng mga bagong taripa, at pagkatapos lamang, nang malutas ang buong gusot, kami ay nakarating sa ilalim ng katotohanan. Nag-aksaya kami ng maraming oras at nalampasan ang mga deadline.

Ang problema ay ang maraming mga nakatagong sandali at mga pitfalls ay nananatili lamang sa ulo ng aming station wagon at hindi inilipat sa papel. Gaya ng ipinaliwanag ni Anatoly kalaunan, siya ay nagmamadali. Ngunit ang pinaka-malamang na pagpipilian ay nakatagpo siya ng mga problema sa panahon ng pag-unlad at nalampasan lamang ang mga ito nang hindi sinasalamin ito kahit saan.

Nagkaroon ng isa pang sitwasyon. Ngayon ay mayroon na lang kaming isang tester, kaya ang ilang mga gawain ay kailangang masuri ng mga analyst, kabilang ang mga generalist. Samakatuwid, nagbigay ako ng isang gawain sa kondisyon na Fedor - "universal - okay, hayaan mo akong gawin ito, dahil walang iba".
Si Fedor ay isang "tatlo sa isa", ngunit ang isang developer ay inilaan na para sa gawaing ito. Nangangahulugan ito na kinailangan ni Fedya na pagsamahin lamang ang isang analyst at isang tester.

Ang mga kinakailangan ay nakolekta, ang pagtutukoy ay isinumite sa pag-unlad, oras na upang subukan. Alam ni Fedor na ang sistema ay binago "tulad ng likod ng kanyang kamay" at lubusang nagawa ang mga kasalukuyang kinakailangan. Samakatuwid, hindi siya nag-abala sa kanyang sarili sa pagsulat ng mga script ng pagsubok, ngunit nagsagawa ng pagsubok sa "kung paano dapat gumana ang system", pagkatapos ay ipinasa ito sa mga gumagamit.
Natapos ang pagsubok, ang rebisyon ay napunta sa produksyon. Nang maglaon ay lumabas na hindi lamang sinuspinde ng system ang mga pagbabayad sa ilang mga account sa balanse, ngunit hinarangan din ang mga pagbabayad mula sa napakabihirang mga panloob na account na hindi dapat lumahok dito.

Nangyari ito dahil sa ang katunayan na hindi sinuri ni Fedor kung paano "hindi dapat gumana ang sistema", hindi gumawa ng isang plano sa pagsubok o mga checklist. Nagpasya siyang magtipid sa oras at umasa sa sarili niyang instincts.

Paano natin haharapin ang mga problema?

Ang mga sitwasyong tulad nito ay nakakaapekto sa performance ng team, kalidad ng release, at kasiyahan ng customer. Samakatuwid, hindi sila maaaring iwanang walang pansin at pagsusuri sa mga dahilan.

1. Para sa bawat gawain na nagdulot ng mga paghihirap, hinihiling ko sa iyo na punan ang isang pinag-isang form: isang mapa ng error, na nagbibigay-daan sa iyo upang matukoy ang yugto kung saan naganap ang "pag-drawdown":

"Universal" sa development team: benepisyo o pinsala?

2. Pagkatapos matukoy ang mga bottleneck, isang sesyon ng brainstorming ang gaganapin sa bawat empleyado na nakaimpluwensya sa problema: "Ano ang dapat baguhin?" (hindi namin isinasaalang-alang ang mga espesyal na kaso sa pagbabalik-tanaw), bilang isang resulta kung saan ang mga partikular na aksyon ay ipinanganak (tiyak para sa bawat uri ng personalidad) na may mga deadline.

3. Nagpakilala kami ng mga panuntunan para sa pakikipag-ugnayan sa loob ng team. Halimbawa, sumang-ayon kami na kinakailangang itala ang lahat ng impormasyon tungkol sa pag-unlad ng isang gawain sa sistema ng pamamahala ng proyekto. Kapag binago/natukoy ang mga artifact sa panahon ng proseso ng pag-develop, dapat itong ipakita sa base ng kaalaman at sa huling bersyon ng mga teknikal na detalye.

4. Ang kontrol ay nagsimulang isagawa sa bawat yugto (ang espesyal na atensyon ay binabayaran sa mga may problemang yugto sa nakaraan) at awtomatikong batay sa mga resulta ng susunod na gawain.

5. Kung ang resulta sa susunod na gawain ay hindi nagbago, kung gayon hindi ko inilalagay ang generalist na pinag-uusapan sa papel kung saan siya ay hindi maayos na nakayanan. Sinusubukan kong tasahin ang kanyang kakayahan at pagnanais na bumuo ng mga kakayahan sa tungkuling ito. Kung hindi ako makahanap ng tugon, iniiwan ko siya sa papel na mas malapit sa kanya.

Anong nangyari sa huli?

Ang proseso ng pag-unlad ay naging mas transparent. Nabawasan ang BUS factor. Ang mga miyembro ng koponan, na gumagawa ng mga pagkakamali, ay nagiging mas motivated at mapabuti ang kanilang karma. Unti-unti naming pinapabuti ang kalidad ng aming mga release.

"Universal" sa development team: benepisyo o pinsala?

Natuklasan

Ang mga generalist na empleyado ay may mga kalamangan at kahinaan.

Plus:

  • maaari mong isara ang isang lumulubog na gawain anumang oras o malutas ang isang kagyat na bug sa maikling panahon;
  • isang pinagsamang diskarte sa paglutas ng isang problema: tinitingnan ito ng tagapalabas mula sa pananaw ng lahat ng mga tungkulin;
  • halos lahat ay kayang gawin ng mga generalist nang pantay-pantay.

Disadvantages:

  • Ang kadahilanan ng BUS ay tumataas;
  • ang mga pangunahing kakayahan na likas sa tungkulin ay nawawala. Dahil dito, bumababa ang kalidad ng trabaho;
  • tumataas ang posibilidad ng pagbabago sa mga deadline, dahil walang kontrol sa bawat yugto. Mayroon ding mga panganib na lumaki ang isang "bituin": ang empleyado ay tiwala na mas alam niya na siya ay isang pro;
  • ang panganib ng propesyonal na burnout ay tumataas;
  • maraming mahalagang impormasyon tungkol sa proyekto ay maaaring manatili lamang "sa ulo" ng empleyado.

Tulad ng nakikita mo, mayroong higit pang mga pagkukulang. Samakatuwid, gumagamit lang ako ng mga generalist kung walang sapat na mapagkukunan at ang gawain ay medyo apurahan. O may kakayahan ang isang tao na kulang sa iba, ngunit kalidad ang nakataya.

Kung ang panuntunan ng pamamahagi ng mga tungkulin ay sinusunod sa magkasanib na gawain sa isang gawain, kung gayon ang kalidad ng trabaho ay tumataas. Tinitingnan namin ang mga problema mula sa iba't ibang mga anggulo, ang aming pananaw ay hindi malabo, ang mga sariwang kaisipan ay laging lumalabas. Kasabay nito, ang bawat miyembro ng koponan ay may bawat pagkakataon para sa propesyonal na paglago at pagpapalawak ng kanilang mga kakayahan.

Naniniwala ako na ang pinakamahalagang bagay ay ang pakiramdam na kasangkot sa proseso, gawin ang iyong trabaho, unti-unting pagtaas ng lawak ng iyong mga kakayahan. Gayunpaman, ang mga generalist sa isang koponan ay nagdudulot ng mga benepisyo: ang pangunahing bagay ay upang matiyak na epektibo nilang pinagsama ang iba't ibang mga tungkulin.

Nais ko sa lahat ang isang self-organizing team ng "universal masters of their craft"!

Pinagmulan: www.habr.com

Magdagdag ng komento