“Universeel” in het ontwikkelteam: voordeel of schade?

Dag Allemaal! Mijn naam is Lyudmila Makarova, ik ben ontwikkelingsmanager bij UBRD en een derde van mijn team zijn ‘generalisten’.

Geef toe: elke Tech Lead droomt van cross-functionaliteit binnen zijn team. Het is zo gaaf als één persoon er drie kan vervangen, en dat zelfs efficiënt kan doen, zonder de deadlines te vertragen. En belangrijker nog: het bespaart grondstoffen!
Het klinkt heel verleidelijk, maar is dat ook zo? Laten we proberen het uit te zoeken.

Wie is hij, onze voorloper van verwachtingen?

De term 'generalist' verwijst meestal naar teamleden die meer dan één rol combineren, bijvoorbeeld ontwikkelaar-analist.

De interactie van het team en het resultaat van zijn werk zijn afhankelijk van de professionele en persoonlijke kwaliteiten van de deelnemers.

Over hard skills is alles duidelijk, maar soft skills verdienen bijzondere aandacht. Ze helpen bij het vinden van een aanpak voor een medewerker en leiden hem naar de taak waar hij het meest nuttig zal zijn.

Er zijn veel artikelen over allerlei persoonlijkheidstypes in de IT-industrie. Op basis van mijn ervaring zou ik IT-generalisten in vier categorieën verdelen:

1. “Universeel – Almachtig”

Deze zijn overal. Ze zijn altijd erg actief, willen in het middelpunt van de belangstelling staan, vragen voortdurend aan hun collega's of ze hun hulp nodig hebben en kunnen soms zelfs vervelend zijn. Ze zijn alleen geïnteresseerd in zinvolle taken, waarbij deelname ruimte geeft aan creativiteit en hun trots kan amuseren.

Waar zijn ze sterk in:

• zijn in staat complexe problemen op te lossen;
• diep in het probleem duiken, “graven” en resultaten boeken;
• een onderzoekende geest hebben.

maar:

• emotioneel labiel;
• slecht beheerd;
• hebben hun eigen onwrikbare standpunt, dat heel moeilijk te veranderen is;
• Het is moeilijk om iemand iets simpels te laten doen. Gemakkelijke taken schaden het ego van de almachtige.

2. “Universeel – ik zoek het uit en doe het”

Zulke mensen hebben alleen een handleiding en een beetje tijd nodig - en zij zullen het probleem oplossen. Ze hebben doorgaans een sterke achtergrond in DevOps. Dergelijke generalisten houden zich niet bezig met ontwerp en gebruiken liever een ontwikkelmethode die uitsluitend op hun ervaring is gebaseerd. Ze kunnen gemakkelijk een discussie voeren met de technische leiding over de gekozen optie voor het uitvoeren van de taak.

Waar zijn ze sterk in:

• onafhankelijk;
• stressbestendig;
• bekwaam in veel kwesties;
• erudiet - er valt altijd wel iets met ze te bespreken.

maar:

• schenden vaak verplichtingen;
• hebben de neiging om alles ingewikkelder te maken: los de tafel van vermenigvuldiging op door deze in delen te integreren;
• de kwaliteit van het werk is laag, alles werkt 2-3 keer;
• Ze verschuiven voortdurend deadlines, omdat in werkelijkheid alles niet zo eenvoudig blijkt te zijn.

3. “Universeel – oké, laat mij het doen, want er is niemand anders”

De medewerker is op meerdere vlakken goed thuis en beschikt over relevante ervaring. Maar hij slaagt er in geen van deze taken in om een ​​professional te worden, omdat hij vaak wordt gebruikt als reddingslijn en gaten in de huidige taken dichtt. Plooibaar, efficiënt, beschouwt zichzelf als veelgevraagd, maar is dat niet.

Een praktisch ideale medewerker. Hoogstwaarschijnlijk heeft hij een richting die hij het leukst vindt, maar door de vervaging van competenties vindt er geen ontwikkeling plaats. Als gevolg hiervan loopt iemand het risico niet opgeëist te worden en emotioneel opgebrand te raken.

Waar zijn ze sterk in:

• verantwoordelijk;
• resultaatgericht;
• kalm;
• volledig gecontroleerd.

maar:

• gemiddelde resultaten laten zien vanwege een laag competentieniveau;
• kan geen complexe en abstracte problemen oplossen.

4. “Een alleskunner is een meester in zijn vak”

Iemand met een serieuze achtergrond als ontwikkelaar beschikt over systeemdenken. Pedantisch, veeleisend van zichzelf en zijn team. Elke taak waarbij hij betrokken is, kan voor onbepaalde tijd groeien als er geen grenzen worden gedefinieerd.

Hij kent de architectuur goed, selecteert een wijze van technische implementatie en analyseert zorgvuldig de impact van de gekozen oplossing op de huidige architectuur. Bescheiden, niet ambitieus.

Waar zijn ze sterk in:

• hoge kwaliteit van werk tonen;
• in staat om elk probleem op te lossen;
• zeer efficiënt.

maar:

• intolerant voor de mening van anderen;
• maximalisten. Ze proberen alles goed te doen, en dit verlengt de ontwikkelingstijd.

Wat hebben we in de praktijk?

Laten we eens kijken hoe rollen en competenties het vaakst worden gecombineerd. Laten we een standaard ontwikkelteam als uitgangspunt nemen: PO, ontwikkelingsmanager (tech lead), analisten, programmeurs, testers. We houden geen rekening met de producteigenaar en de technische leiding. De eerste is te wijten aan een gebrek aan technische competenties. De tweede moet, als er problemen zijn in het team, alles kunnen doen.

De meest voorkomende optie voor het combineren/samenvoegen/combineren van competenties is ontwikkelaar-analist. Testanalist en “drie in één” zijn ook heel gebruikelijk.

Met mijn team als voorbeeld zal ik u de voor- en nadelen van mijn collega-generalisten laten zien. Er zit een derde van hen in mijn team en ik hou heel veel van ze.

PO kreeg de dringende taak om nieuwe tarieven in een bestaand product te introduceren. Mijn team heeft 4 analisten. Op dat moment was de een op vakantie, de ander was ziek en de rest was bezig met de uitvoering van strategische taken. Als ik ze eruit zou halen, zou dat onvermijdelijk de implementatiedeadlines verstoren. Er was maar één uitweg: het 'geheime wapen' gebruiken: een veelzijdige ontwikkelaar-analist die het vereiste vakgebied beheerste. Laten we hem Anatoly noemen.

Zijn persoonlijkheidstype is “universeel – ik zoek het uit en doe het”. Natuurlijk probeerde hij lange tijd uit te leggen dat hij 'een volledige achterstand in zijn taken had', maar door mijn wilskrachtige beslissing werd hij gestuurd om een ​​urgent probleem op te lossen. En Anatoly deed het! Hij verzorgde de enscenering en rondde de implementatie op tijd af, en de klanten waren tevreden.

Op het eerste gezicht klopte alles. Maar na een paar weken ontstonden er weer eisen voor verbetering voor dit product. Nu werd de formulering van dit probleem uitgevoerd door een ‘pure’ analist. In de fase van het testen van de nieuwe ontwikkeling konden we lange tijd niet begrijpen waarom we fouten maakten bij het koppelen van nieuwe tarieven, en pas toen, nadat we de hele kluwen hadden ontrafeld, kwamen we tot de bodem van de waarheid. We hebben veel tijd verspild en deadlines gemist.

Het probleem was dat veel verborgen momenten en valkuilen alleen in het hoofd van onze stationwagen bleven en niet op papier werden overgebracht. Zoals Anatoly later uitlegde, had hij te veel haast. Maar de meest waarschijnlijke optie is dat hij al tijdens de ontwikkeling problemen tegenkwam en deze eenvoudigweg omzeilde zonder dit ergens weer te geven.

Er was nog een andere situatie. Nu hebben we maar één tester, dus sommige taken moeten worden getest door analisten, inclusief generalisten. Daarom gaf ik één taak aan de voorwaardelijke Fedor - “universeel – oké, laat mij het doen, want er is niemand anders”.
Fedor is een “drie in één”, maar voor deze taak is al een ontwikkelaar toegewezen. Dit betekent dat Fedya alleen een analist en een tester hoefde te combineren.

De vereisten zijn verzameld, de specificatie is ter ontwikkeling ingediend, het is tijd om te testen. Fedor kent het systeem dat wordt aangepast “als zijn broekzak” en heeft de huidige vereisten grondig uitgewerkt. Daarom hield hij zich niet bezig met het schrijven van testscripts, maar voerde hij tests uit over “hoe het systeem zou moeten werken” en gaf dit vervolgens door aan gebruikers.
De test was voltooid, de revisie ging naar productie. Later bleek dat het systeem niet alleen betalingen naar bepaalde saldorekeningen opschortte, maar ook betalingen blokkeerde van zeer zeldzame interne rekeningen die hier niet aan mee mochten doen.

Dit gebeurde omdat Fedor niet controleerde hoe “het systeem niet zou moeten werken”, geen testplan of checklists opstelde. Hij besloot te besparen op timing en op zijn eigen instinct te vertrouwen.

Hoe gaan wij om met problemen?

Situaties als deze hebben invloed op de teamprestaties, de releasekwaliteit en de klanttevredenheid. Daarom kunnen ze niet zonder aandacht en analyse van de redenen worden gelaten.

1. Voor elke taak die moeilijkheden veroorzaakte, vraag ik u een uniform formulier in te vullen: een foutenkaart, waarmee u het stadium kunt identificeren waarin de “drawdown” plaatsvond:

2. Na het identificeren van knelpunten wordt er met elke medewerker die invloed heeft gehad op het probleem een ​​brainstormsessie gehouden: “Wat te veranderen?” (bij bijzondere gevallen houden we achteraf geen rekening), waardoor specifieke acties ontstaan ​​(specifiek voor elk persoonlijkheidstype) met deadlines.

3. We hebben regels ingevoerd voor de interactie binnen het team. Zo hebben we afgesproken om noodzakelijkerwijs alle informatie over de voortgang van een taak vast te leggen in het projectmanagementsysteem. Wanneer tijdens het ontwikkelingsproces artefacten worden gewijzigd/geïdentificeerd, moet dit worden weerspiegeld in de kennisbank en de definitieve versie van de technische specificaties.

4. De controle werd in elke fase uitgevoerd (speciale aandacht wordt besteed aan problematische fasen in het verleden) en automatisch op basis van de resultaten van de volgende taak.

5. Als het resultaat bij de volgende taak niet is veranderd, dan stel ik de generalist niet in vraag in de rol waarin hij slecht omgaat. Ik probeer zijn vermogen en wens te beoordelen om competenties in deze rol te ontwikkelen. Als ik geen antwoord vind, laat ik hem in de rol die dichter bij hem staat.

Wat gebeurde er op het einde?

Het ontwikkelingsproces is transparanter geworden. De BUS-factor is afgenomen. Teamleden die aan fouten werken, raken gemotiveerder en verbeteren hun karma. We verbeteren geleidelijk de kwaliteit van onze releases.

Bevindingen

Generalistische medewerkers hebben hun voor- en nadelen.

voordelen:

• u kunt op elk moment een vastgelopen taak sluiten of een dringende bug in korte tijd oplossen;
• een geïntegreerde aanpak om een ​​probleem op te lossen: de uitvoerder bekijkt het vanuit het perspectief van alle rollen;
• generalisten kunnen vrijwel alles even goed.

Nadelen:

• BUS-factor neemt toe;
• de kerncompetenties die inherent zijn aan de rol worden uitgehold. Hierdoor neemt de kwaliteit van het werk af;
• de kans op een verschuiving van deadlines neemt toe, omdat er is geen controle in elke fase. Er zijn ook risico’s verbonden aan het uitgroeien tot een “ster”: de werknemer heeft er vertrouwen in dat hij beter weet dat hij een professional is;
• het risico op professionele burn-out neemt toe;
• veel belangrijke informatie over het project kan alleen 'in het hoofd' van de medewerker blijven.

Zoals u kunt zien, zijn er nog meer tekortkomingen. Daarom gebruik ik generalisten alleen als er niet genoeg middelen zijn en de taak behoorlijk urgent is. Of iemand beschikt over competenties die anderen ontberen, maar de kwaliteit staat op het spel.

Als de regel van rolverdeling wordt nageleefd bij gezamenlijk werken aan een taak, neemt de kwaliteit van het werk toe. We bekijken problemen vanuit verschillende invalshoeken, ons zicht is niet wazig, er verschijnen altijd nieuwe gedachten. Tegelijkertijd heeft elk teamlid alle kansen voor professionele groei en uitbreiding van zijn competenties.

Ik geloof dat het allerbelangrijkste is dat je je betrokken voelt bij het proces, je werk doet en geleidelijk de breedte van je competenties vergroot. Generalisten in een team brengen echter voordelen met zich mee: het belangrijkste is om ervoor te zorgen dat ze verschillende rollen effectief combineren.

Ik wens iedereen een zelforganiserend team van “universele meesters in hun vak”!

Bron: www.habr.com