"Universeel" in die ontwikkelingspan: voordeel of skade?

"Universeel" in die ontwikkelingspan: voordeel of skade?

Hi almal! My naam is Lyudmila Makarova, ek is 'n ontwikkelingsbestuurder by UBRD en 'n derde van my span is "generaliste".

Erken dit: elke Tech Lead droom van kruisfunksionaliteit binne hul span. Dit is so gaaf as een persoon drie kan vervang, en dit selfs doeltreffend kan doen, sonder om sperdatums uit te stel. En, belangriker, dit spaar hulpbronne!
Dit klink baie aanloklik, maar is dit regtig so? Kom ons probeer dit uitvind.

Wie is hy, ons voorloper van verwagtinge?

Die term "generalis" verwys gewoonlik na spanlede wat meer as een rol kombineer, byvoorbeeld ontwikkelaar-ontleder.

Die interaksie van die span en die resultaat van sy werk hang af van die professionele en persoonlike eienskappe van die deelnemers.

Alles is duidelik oor harde vaardighede, maar sagte vaardighede verdien spesiale aandag. Hulle help om 'n benadering tot 'n werknemer te vind en lei hom na die taak waar hy die nuttigste sal wees.

Daar is baie artikels oor alle soorte persoonlikheidstipes in die IT-industrie. Op grond van my ervaring sal ek IT-generaliste in vier kategorieë verdeel:

1. “Universeel – Almagtig”

Hierdie is oral. Hulle is altyd baie aktief, wil die middelpunt van aandag wees, vra voortdurend hul kollegas of hulle hul hulp nodig het, en soms kan hulle selfs irriterend wees. Hulle is net geïnteresseerd in betekenisvolle take, deelname daaraan sal ruimte gee vir kreatiwiteit en kan hul trots vermaak.

Waarin is hulle sterk:

  • in staat is om komplekse probleme op te los;
  • duik diep in die probleem, "grawe" en bereik resultate;
  • 'n nuuskierige verstand hê.

maar:

  • emosioneel labiel;
  • swak bestuur;
  • het hul eie onwrikbare standpunt, wat baie moeilik is om te verander;
  • Dit is moeilik om iemand te kry om 'n eenvoudige ding te doen. Maklike take knou die ego van die almagtige.

2. "Universeel - ek sal dit uitvind en dit doen"

Sulke mense het net 'n handleiding en 'n bietjie tyd nodig - en hulle sal die probleem oplos. Hulle het gewoonlik 'n sterk agtergrond in DevOps. Sulke generaliste steur hulle nie aan ontwerp nie en verkies om 'n ontwikkelingsmetode te gebruik wat uitsluitlik op hul ervaring gebaseer is. Hulle kan maklik 'n gesprek voer met die tegniese hoof oor die gekose opsie vir die implementering van die taak.

Waarin is hulle sterk:

  • onafhanklik;
  • stresbestand;
  • bekwaam in baie kwessies;
  • geleerd - daar is altyd iets om met hulle oor te praat.

maar:

  • skend dikwels verpligtinge;
  • is geneig om alles te kompliseer: los die vermenigvuldigingstabel op deur met dele te integreer;
  • die kwaliteit van werk is laag, alles werk 2-3 keer;
  • Hulle verskuif voortdurend sperdatums, want in werklikheid blyk alles nie so eenvoudig te wees nie.

3. "Universeel - goed, laat ek dit doen, want daar is niemand anders nie"

Die werknemer is goed onderlê in verskeie gebiede en het relevante ondervinding. Maar hy slaag nie daarin om 'n professionele persoon in enige van hulle te word nie, want hy word dikwels as 'n reddingsboei gebruik, wat gate in huidige take toestop. Buigsaam, doeltreffend, beskou homself in aanvraag, maar is nie.

'n Praktiese ideale werknemer. Heel waarskynlik het hy 'n rigting waarvan hy die beste hou, maar weens die vervaging van bevoegdhede vind ontwikkeling nie plaas nie. Gevolglik loop 'n persoon die risiko om onopgeëis te word en emosioneel uitgebrand te word.

Waarin is hulle sterk:

  • verantwoordelik;
  • resultaat-georiënteerde;
  • kalm;
  • heeltemal beheer.

maar:

  • gemiddelde resultate te toon as gevolg van 'n lae vlak van bevoegdhede;
  • kan nie komplekse en abstrakte probleme oplos nie.

4. "'n Allrounder is 'n meester van sy kuns"

'n Persoon met 'n ernstige agtergrond as 'n ontwikkelaar het stelseldenke. Pedanties, veeleisend van homself en sy span. Enige taak waarby hom betrokke is, kan onbepaald groei as grense nie gedefinieer word nie.

Hy is goed vertroud met die argitektuur, kies 'n metode van tegniese implementering, en analiseer noukeurig die impak van die gekose oplossing op die huidige argitektuur. Beskeie, nie ambisieus nie.

Waarin is hulle sterk:

  • toon hoë gehalte van werk;
  • in staat om enige probleem op te los;
  • baie doeltreffend.

maar:

  • onverdraagsaam teenoor ander se opinies;
  • maksimaliste. Hulle probeer alles reg doen, en dit verhoog ontwikkelingstyd.

Wat het ons in die praktyk?

Kom ons kyk hoe rolle en bevoegdhede meestal gekombineer word. Kom ons neem 'n standaardontwikkelingspan as vertrekpunt: PO, ontwikkelingsbestuurder (tegnologieleier), ontleders, programmeerders, toetsers. Ons sal nie die produkeienaar en tegniese leiding oorweeg nie. Die eerste is as gevolg van 'n gebrek aan tegniese vaardighede. Die tweede een, as daar probleme in die span is, behoort alles te kan doen.

Die mees algemene opsie vir die kombinasie/samesmelting/kombinasie van bevoegdhede is ontwikkelaar-ontleder. Toetsontleder en "drie in een" is ook baie algemeen.

Deur my span as voorbeeld te gebruik, sal ek jou die voor- en nadele van my mede-generaals wys. Daar is 'n derde van hulle in my span, en ek is baie lief vir hulle.

PO het 'n dringende taak ontvang om nuwe tariewe in 'n bestaande produk in te stel. My span het 4 ontleders. Op daardie stadium was een met vakansie, die ander was siek, en die res was besig met die implementering van strategiese take. As ek hulle uittrek, sou dit onvermydelik die implementeringspertye ontwrig. Daar was net een uitweg: om die "geheime wapen" te gebruik - 'n veelsydige ontwikkelaar-ontleder wat die vereiste vakgebied bemeester het. Kom ons noem hom Anatoly.

Sy persoonlikheidstipe is "universeel - ek sal dit uitvind en dit doen". Hy het natuurlik lank probeer verduidelik dat hy “vol agterstand van sy take het”, maar deur my sterk wilsbesluit is hy gestuur om ’n dringende probleem op te los. En Anatoly het dit gedoen! Hy het die opvoering uitgevoer en die implementering betyds voltooi, en die klante was tevrede.

Met die eerste oogopslag het alles uitgewerk. Maar na 'n paar weke het vereistes vir verbetering weer vir hierdie produk ontstaan. Nou is die formulering van hierdie probleem deur 'n "suiwer" ontleder uitgevoer. Op die stadium van toetsing van die nuwe ontwikkeling kon ons vir 'n lang tyd nie verstaan ​​hoekom ons foute het om nuwe tariewe te koppel nie, en eers toe, nadat ons die hele warboel ontrafel het, het ons tot die bodem van die waarheid gekom. Ons het baie tyd gemors en sperdatums gemis.

Die probleem was dat baie versteekte oomblikke en slaggate net in die kop van ons stasiewa gebly het en nie na papier oorgedra is nie. Soos Anatoly later verduidelik het, was hy te haastig. Maar die mees waarskynlike opsie is dat hy reeds tydens ontwikkeling op probleme afgekom het en dit eenvoudig omseil het sonder om dit nêrens te weerspieël.

Daar was 'n ander situasie. Nou het ons net een toetser, so sommige take moet deur ontleders getoets word, insluitend algemene. Daarom het ek een taak aan die voorwaardelike Fedor gegee - "universeel - goed, laat ek dit doen, want daar is niemand anders nie".
Fedor is 'n "drie in een", maar 'n ontwikkelaar is reeds vir hierdie taak toegewys. Dit beteken dat Fedya slegs 'n ontleder en 'n toetser moes kombineer.

Vereistes is ingesamel, die spesifikasie is aan ontwikkeling voorgelê, dit is tyd om te toets. Fedor weet dat die stelsel verander word "soos die rug van sy hand" en het die huidige vereistes deeglik uitgewerk. Daarom het hy hom nie daaraan gesteur om toetsskrifte te skryf nie, maar toetse uitgevoer oor “hoe die stelsel moet werk”, en dit dan aan gebruikers deurgegee.
Die toets is voltooi, die hersiening het na produksie gegaan. Dit het later geblyk dat die stelsel nie net betalings aan sekere balansrekeninge opgeskort het nie, maar ook betalings van baie skaars interne rekeninge geblokkeer het wat nie veronderstel was om hieraan deel te neem nie.

Dit het gebeur as gevolg van die feit dat Fedor nie gekyk het hoe "die stelsel nie moet werk nie", nie 'n toetsplan of kontrolelyste opgestel het nie. Hy het besluit om op tydsberekening te bespaar en op sy eie instinkte staat te maak.

Hoe hanteer ons probleme?

Situasies soos hierdie beïnvloed spanprestasie, vrystellingskwaliteit en klanttevredenheid. Daarom kan hulle nie sonder aandag en ontleding van die redes gelaat word nie.

1. Vir elke taak wat probleme veroorsaak het, vra ek u om 'n verenigde vorm in te vul: 'n foutkaart waarmee u die stadium kan identifiseer waarop die "onttrekking" plaasgevind het:

"Universeel" in die ontwikkelingspan: voordeel of skade?

2. Nadat knelpunte geïdentifiseer is, word 'n dinkskrum gehou met elke werknemer wat die probleem beïnvloed het: "Wat om te verander?" (ons oorweeg nie spesiale gevalle in retrospek nie), as gevolg waarvan spesifieke aksies gebore word (spesifiek vir elke persoonlikheidstipe) met spertye.

3. Ons het reëls vir interaksie binne die span ingestel. Ons het byvoorbeeld ingestem om noodwendig alle inligting oor die vordering van 'n taak in die projekbestuurstelsel aan te teken. Wanneer artefakte tydens die ontwikkelingsproses verander/geïdentifiseer word, moet dit in die kennisbasis en die finale weergawe van die tegniese spesifikasies weerspieël word.

4. Beheer het in elke stadium begin word (spesiale aandag word gegee aan problematiese stadiums in die verlede) en outomaties gebaseer op die resultate van die volgende taak.

5. As die uitslag op die volgende taak nie verander het nie, dan plaas ek nie die betrokke generaal in die rol waarin hy swak klaarkom nie. Ek probeer sy vermoë en begeerte om vaardighede in hierdie rol te ontwikkel, assesseer. As ek nie 'n antwoord kry nie, laat ek hom in die rol wat nader aan hom is.

Wat het op die ou end gebeur?

Die ontwikkelingsproses het meer deursigtig geword. Die BUS-faktor het afgeneem. Spanlede wat aan foute werk, word meer gemotiveerd en verbeter hul karma. Ons verbeter die kwaliteit van ons vrystellings geleidelik.

"Universeel" in die ontwikkelingspan: voordeel of skade?

Bevindinge

Algemene werknemers het hul voor- en nadele.

voordele:

  • jy kan enige tyd 'n afsakkende taak toemaak of 'n dringende fout in 'n kort tyd oplos;
  • 'n geïntegreerde benadering tot die oplossing van 'n probleem: die uitvoerder kyk daarna vanuit die perspektief van alle rolle;
  • generaliste kan amper alles ewe goed doen.

Nadele:

  • BUS-faktor verhoog;
  • die kernbevoegdhede inherent aan die rol word geërodeer. As gevolg hiervan neem die kwaliteit van werk af;
  • die waarskynlikheid van 'n verskuiwing in spertye verhoog, omdat daar is geen beheer in elke stadium nie. Daar is ook risiko's om 'n "ster" te laat groei: die werknemer is vol vertroue dat hy beter weet dat hy 'n pro is;
  • die risiko van professionele uitbranding neem toe;
  • baie belangrike inligting oor die projek kan net “in die kop” van die werknemer bly.

Soos u kan sien, is daar meer tekortkominge. Daarom gebruik ek veralgemeners slegs as daar nie genoeg hulpbronne is nie en die taak redelik dringend is. Of 'n persoon het bevoegdhede wat ander kort, maar kwaliteit is op die spel.

As die reël van rolverdeling nagekom word in gesamentlike werk aan 'n taak, dan neem die kwaliteit van werk toe. Ons kyk na probleme vanuit verskillende hoeke, ons siening is nie vaag nie, vars gedagtes verskyn altyd. Terselfdertyd het elke spanlid elke geleentheid vir professionele groei en uitbreiding van hul bevoegdhede.

Ek glo dat die belangrikste ding is om betrokke te voel by die proses, om jou werk te doen, en geleidelik die breedte van jou bevoegdhede te vergroot. Generaliste in 'n span bring egter voordele: die belangrikste ding is om te verseker dat hulle verskillende rolle effektief kombineer.

Ek wens almal 'n selforganiserende span van "universele meesters van hul kuns" toe!

Bron: will.com

Voeg 'n opmerking