"Universeel" in het ontwikkelingsteam: nut of schade?

Hallo allemaal! Mijn naam is Lyudmila Makarova, ik ben ontwikkeling manager bij UBRiR en een derde van mijn team bestaat uit 'universal workers'.

Erken het: elke Tech Lead droomt van cross-functionele samenwerking binnen zijn team. Het is immers geweldig als één persoon in staat is om drie te vervangen, en dit ook nog eens kwalitatief hoogstaand doet, zonder deadlines te verschuiven. En, niet onbelangrijk, het zorgt voor een besparing van middelen!
Het klinkt erg aanlokkelijk, maar is het ook echt zo? Laten we proberen het uit te zoeken.

Wie is onze verwachtingsovertreffende?

Met de term 'universeel' wordt meestal bedoeld dat teamleden meer dan één rol combineren, zoals ontwikkelaar-analist.

De interactie binnen het team en het resultaat van hun werk hangen af van de professionele en persoonlijke kwaliteiten van de deelnemers.

Wat betreft hard skills is alles duidelijk, maar soft skills verdienen bijzondere aandacht. Ze helpen om een goede benadering te vinden voor de medewerker en hem te richten op die taak waarbij hij het meest waardevol is.

Er zijn veel artikelen over verschillende type persoonlijkheden binnen de IT-industrie. Gebaseerd op mijn ervaring, zou ik IT-universals in vier categorieën indelen:

1. 'Universeel – almachtig'

Ze zijn overal te vinden. Ze tonen altijd veel activiteit, willen in de schijnwerpers staan, vragen constant aan collega's of ze hulp nodig hebben, en kunnen soms zelfs irritant zijn. Ze zijn alleen geïnteresseerd in significante taken, deelname waarbij ruimte voor creativiteit komt en dat hun ego streelt.

In waar ze sterk zijn:

• in staat om complexe taken op te lossen;
• duiken diep in het probleem, ‘graven’ en behalen resultaten;
• hebben een nieuwsgierige geest.

Maar:

• emotioneel labiel;
• moeilijk te sturen;
• hebben een onwrikbaar standpunt dat moeilijk te veranderen is;
• het is moeilijk om ze een simpele taak te laten uitvoeren. Eenvoudige taken raken het ego van de almachtige.

2. 'Universeel – ik begrijp het en doe het'

Deze mensen hebben genoeg aan een handleiding en wat tijd – en ze lossen het probleem op. Gewoonlijk hebben ze een uitgebreide achtergrond als DevOps. Dergelijke universals maken zich niet druk om het ontwerpen en geven de voorkeur aan ontwikkelingsmethoden die uitsluitend zijn gebaseerd op hun ervaring. Ze kunnen met gemak in conflict komen met de tech lead over de gekozen implementatiemethode.

In waar ze sterk zijn:

• zelfstandig;
• stressbestendig;
• competent in veel zaken;
• Geïnformeerd - er is altijd iets om over te praten.

Maar:

• Schenden vaak verplichtingen;
• Geneigen om alles te compliceren: ze lossen de stofverdeling op door deze integraal te splitsen;
• De kwaliteit van het werk is laag, alles lukt pas na 2-3 pogingen;
• Verleggen constant de deadlines, omdat het in werkelijkheid helemaal niet zo eenvoudig blijkt te zijn.

3. "Universeel - goed, laat maar, ik doe het, aangezien er verder niemand is"

De medewerker heeft een behoorlijke kennis van verschillende gebieden en heeft de bijbehorende ervaring. Maar hij slaagt er niet in om professioneel te worden in een van hen, omdat hij vaak als een redder in nood wordt gebruikt om gaten in de lopende taken te dichten. Meegaand, uitvoerend, beschouwt zichzelf als gewild, maar is dat niet.

Praktisch de ideale medewerker. Waarschijnlijk heeft hij een voorkeur voor een bepaald gebied, maar door het vervagen van competenties vindt er geen ontwikkeling plaats. Daardoor loopt de persoon het risico om ongewenst en emotioneel uitgeput te raken.

In waar ze sterk zijn:

• Verantwoordelijk;
• Resultaatgericht;
• Kalm;
• Volledig controleerbaar.

Maar:

• Toningen van gemiddelde prestaties door een laag niveau van competenties;
• Kunnen geen complexe en abstracte taken oplossen.

4. "Universeel - meester van zijn vak"

Een persoon met een ernstige achtergrond als ontwikkelaar, heeft een systematische denkwijze. Perfectionistisch, veeleisend tegenover zichzelf en het team. Elke taak waaraan hij deelneemt kan eindeloos uitgroeien als de grenzen niet worden aangegeven.

Goed bekend met de architectuur, kiest de methode van technische uitvoering, zorgvuldig analyserend welke impact de gekozen oplossing heeft op de huidige architectuur. Bescheiden, niet ambitieus.

In waar ze sterk zijn:

• Tonen hoge kwaliteit van werk;
• Kunnen elke taak oplossen;
• Zeer productief.

Maar:

• Intolerant voor de meningen van anderen;
• Maximalisten. Proberen alles goed te doen, wat de ontwikkelingstijd verlengt.

Wat hebben we in de praktijk?

Laten we kijken hoe rollen en competenties vaak worden samengevoegd. We nemen een standaard ontwikkelteam als uitgangspunt: PO, development manager (tech lead), analisten, programmeurs, testers. We beschouwen de producteigenaar en tech lead niet. De eerste vanwege een gebrek aan technische competenties. De tweede moet in het geval van problemen in het team in staat zijn om alles te doen.

De meest voorkomende variant van het combineren/samenvoegen van vaardigheden is de ontwikkelaar-analist. Ook de analist-testers en de 'drie in één' zijn heel gebruikelijk.

Aan de hand van mijn team laat ik de voor- en nadelen van collega-universals zien. In mijn team is een derde daarvan, en ik hou echt van hen.

Van de PO kwam een dringende taak om nieuwe tarieven in het bestaande product in te voeren. In mijn team zijn er 4 analisten. Op dat moment was er eentje met verlof, een ander was ziek, en de anderen waren bezig met strategische taken. Als ik ze eruit had gehaald, zou dat onvermijdelijk de deadlines hebben verstoord. Er was nog maar één oplossing: het 'geheime wapen' gebruiken – een universel ontwikkelaar-analist die op de hoogte was van het vereiste onderwerp. Laten we hem Anatoli noemen.

Zijn persoonlijkheidstype is ‘universel – ik zal het begrijpen en doen’. Natuurlijk probeerde hij lange tijd uit te leggen dat hij 'een volle backlog met taken' had, maar op mijn wilskrachtige beslissing werd hij naar de dringende taak gestuurd. En Anatoli heeft het gedaan! Hij heeft de opdracht uitgevoerd en de implementatie op tijd afgerond, en de klanten waren tevreden.

Op het eerste gezicht was alles gelukt. Maar na enkele weken kwamen er opnieuw eisen voor aanpassingen aan dit product. Nu behandelde een 'schone' analist de taak. In de testfase van de nieuwe ontwikkeling konden we lange tijd niet begrijpen waarom we fouten tegenkwamen bij het koppelen van de nieuwe tarieven, en pas later, na het ontrafelen van de hele situatie, kwamen we tot de waarheid. We hebben een hoop tijd verloren en de deadlines verstoord.

Het probleem was dat veel verborgen dingen en onderhuidse problemen alleen in het hoofd van onze universel waren gebleven en niet op papier waren gezet. Zoals Anatoli later uitlegde, was hij te gehaast. Maar waarschijnlijker is het dat hij tijdens de ontwikkeling tegen problemen aanliep en ze gewoon omzeilde, zonder er ergens iets van vast te leggen.

Er was ook een andere situatie. Nu hebben we maar één tester, dus moeten sommige taken door analisten worden getest, waaronder – universals. Daarom gaf ik een taak aan de voorwaardelijke Fedor – ‘universel – goed, laten we zeggen dat ik het wel doe, aangezien er niemand anders is’.
Fedor is 'drie in één', maar voor deze taak was er al een ontwikkelaar toegewezen. Dus Fedor moest alleen de rol van analist en tester combineren.

De vereisten zijn verzameld, de specificatie is aan de ontwikkeling overgedragen, het is tijd om te testen. Fyodor kent het systeem dat in ontwikkeling is «als zijn vijf vingers» en heeft de huidige vereisten grondig uitgewerkt. Daarom vond hij het niet nodig om testscenario's te schrijven, en heeft hij getest op hoe het systeem «zou moeten werken», en daarna heeft hij het aan de gebruikers overgedragen.
De test is afgerond, en de ontwikkeling is naar productie gegaan. Later bleek dat het systeem niet alleen betalingen op bepaalde balansrekeningen opschort, maar ook betalingen blokkeert van zeer zeldzame interne rekeningen, die hier niet bij betrokken hadden moeten zijn.

Dit gebeurde omdat Fyodor geen controle heeft uitgevoerd over hoe «het systeem niet zou moeten werken», geen testplan of checklist heeft opgesteld. Hij besloot tijd te besparen en vertrouwde op zijn eigen intuïtie.

Hoe gaan we om met problemen?

Dergelijke situaties beïnvloeden de effectiviteit van het team, de kwaliteit van de opgeleverde releases en de tevredenheid van de klanten. Daarom kunnen ze niet zonder aandacht en analyse van de oorzaken blijven.

1. Voor elke taak die problemen heeft veroorzaakt, vraag ik om een gestandaardiseerd formulier in te vullen: de foutkaart, die helpt om de fase te identificeren waarop er een «daling» heeft plaatsgevonden:

2. Na het identificeren van knelpunten, wordt er met elke medewerker die invloed heeft gehad op het probleem een brainstorm gehouden «Wat moet er veranderd worden?» (met uitzondering van specifieke gevallen die we niet bespreken tijdens de retrospective), waarvan concreet actiepunten voortkomen (voor elk persoonlijkheidstype zijn er eigen acties) met deadlines.

3. We hebben regels voor samenwerking binnen het team ingevoerd. Bijvoorbeeld, we hebben afgesproken om alle informatie over de voortgang van taken in het projectmanagementsysteem vast te leggen. Bij wijzigingen/bepalingen van artefacten tijdens de ontwikkeling, moet dit worden weergegeven in de kennisbank en de uiteindelijke versie van de specificaties.

4. Controle vindt plaats in elke fase (met bijzondere aandacht voor problematische fases uit het verleden) en automatisch op basis van de resultaten van de volgende taak.

5. Als het resultaat voor de volgende taak niet is veranderd, geef ik de betreffende allrounder geen rol waarvoor hij slecht presteert. Ik probeer zijn capaciteit en bereidheid om competenties in deze rol te ontwikkelen te evalueren. Als ik geen respons vind, laat ik hem in de rol die hem het dichtst ligt.

Wat is er uiteindelijk uit gekomen?

Het ontwikkelproces is transparanter geworden. De BUS-factor is afgenomen. Teamleden worden gemotiveerder terwijl ze aan fouten werken, wat hun karma verbetert. We verhogen geleidelijk de kwaliteit van onze releases.

Conclusies

Universele medewerkers hebben hun voor- en nadelen.

Voordelen:

• je kunt op elk moment een vertraagde taak sluiten of een dringende bug in korte tijd oplossen;
• een geïntegreerde aanpak bij het oplossen van een probleem: de uitvoerder bekijkt het vanuit het perspectief van alle rollen;
• universele medewerkers kunnen praktisch alles even goed doen.

Nadelen:

• de BUS-factor neemt toe;
• de belangrijkste competenties die bij de rol horen, vervagen. Dit verlaagt de kwaliteit van het werk;
• de kans op vertragingen neemt toe, omdat er geen controle is in elke fase. Ook ontstaan de risico's van het creëren van een 'ster': de medewerker is ervan overtuigd dat hij het beter weet, dat hij de professional is;
• er is een verhoogd risico op burn-out;
• veel belangrijke informatie over het project kan alleen 'in het hoofd' van de medewerker blijven.

Zoals je ziet, zijn er meer nadelen. Daarom gebruik ik universele medewerkers alleen als er onvoldoende middelen zijn en de taak dringend genoeg is. Of als de persoon over competenties beschikt die anderen niet hebben, en de kwaliteit op het spel staat.

Als er bij het samenwerken aan een taak voldaan wordt aan de rolverdeling, stijgt de kwaliteit van het werk. We bekijken problemen vanuit verschillende perspectieven, de blik wordt niet vertroebeld, er komen altijd nieuwe ideeën naar voren. Daarbij heeft elke teamleden alle mogelijkheden voor professionele groei en uitbreiding van hun competenties.

Ik beschouw het als het belangrijkste om je betrokken te voelen bij het proces, je werk te doen en geleidelijk je competenties te verbreden. Desondanks brengen universele medewerkers voordelen in het team: het belangrijkste is om ervoor te zorgen dat ze verschillende rollen effectief combineren.

Ik wens alle zelforganiserende teams van 'universele vakmensen' veel succes!

Bron: habr.com