„Universal“ im Entwicklungsteam: Vorteil oder Nachteil?

Hallo zusammen! Mein Name ist Liudmila Makarova, ich bin Entwicklungsmanagerin bei UBRiR, und ein Drittel meines Teams besteht aus "Universal-Experten".

Geben Sie es zu: Jeder Tech Lead träumt von interdisziplinärer Zusammenarbeit innerhalb seines Teams. Es ist einfach großartig, wenn eine Person die Arbeit von dreien übernehmen kann, und das auch noch qualitativ hochwertig und ohne Verzögerungen. Und nicht zu vergessen – das spart Ressourcen!
Das klingt sehr verlockend, aber ist es wirklich so? Lassen Sie uns das näher untersuchen.

Wer ist unser Vorreiter der Erwartungen?

Unter dem Begriff "Universal-Experte" versteht man in der Regel Teammitglieder, die mehr als eine Rolle kombinieren, zum Beispiel einen Entwickler-Analysten.

Die Interaktion im Team und das Ergebnis ihrer Arbeit hängen von den beruflichen und persönlichen Qualitäten der Teilnehmer ab.

Bei den Hard Skills ist alles klar, aber die Soft Skills verdienen besondere Aufmerksamkeit. Sie helfen, den richtigen Zugang zu einem Mitarbeiter zu finden und ihn auf die Aufgabe zu lenken, bei der er am effektivsten ist.

Es gibt viele Artikel über die verschiedenen Persönlichkeitstypen in der IT-Branche. Basierend auf meiner Erfahrung würde ich IT-Universal-Experten in vier Kategorien einteilen:

1. „Universal-Experte – allmächtig“

Solche gibt es überall. Sie sind immer sehr aktiv, wollen im Mittelpunkt stehen, fragen ständig ihre Kollegen, ob sie Hilfe brauchen, und können manchmal sogar nerven. Sie interessieren sich nur für bedeutende Aufgaben, an denen sie kreativ arbeiten können, um ihr Ego zu stärken.

Stärken:

• in der Lage, komplexe Probleme zu lösen;
• tauchen tief in die Problematik ein, „graben“ und erreichen Ergebnisse;
• besitzen einen neugierigen Verstand.

Aber:

• emotional instabil;
• wenig steuerbar;
• haben ihre uneingeschränkte Meinung, die sehr schwer zu ändern ist;
• es ist schwierig, sie zu einfachen Aufgaben zu bewegen. Leichte Aufgaben verletzen das Ego der Alleskönner.

2. „Universalist – ich werde mich auseinandersetzen und es machen“

Diese Personen benötigen nur ein Handbuch und etwas Zeit – dann lösen sie das Problem. Meistens haben sie einen umfangreichen Hintergrund als DevOps. Solche Universalisten machen sich keine Mühe mit dem Design und ziehen es vor, die Entwicklungsstrategie ausschließlich auf Basis ihrer eigenen Erfahrungen anzuwenden. Sie können leicht in einen Streit mit dem technischen Leiter über die gewählte Implementierungsmethode geraten.

Stärken:

• eigenständig;
• stressresistent;
• kompetent in vielen Bereichen;
• Sie sind gebildet – es gibt immer etwas, worüber man sprechen kann.

Aber:

• oft brechen sie ihre Verpflichtungen;
• neigen dazu, alles kompliziert zu machen: Sie lösen die Multiplikation durch partielle Integration;
• die Arbeitsqualität ist niedrig, alles gelingt erst beim zweiten oder dritten Versuch;
• verschieben ständig die Fristen, weil sich herausstellt, dass alles nicht so einfach ist.

3. "Universal – gut, lass mich machen, da sonst niemand da ist"

Der Mitarbeiter hat ein gewisses Fachwissen in mehreren Bereichen und entsprechende Erfahrung. Doch es gelingt ihm nicht, in einem dieser Bereiche zum Experten zu werden, da er häufig als Rettungsring eingesetzt wird, um aktuelle Aufgaben zu lösen. Er ist anpassungsfähig, folgsam und glaubt, gefragt zu sein, ist es aber tatsächlich nicht.

Der praktisch ideale Mitarbeiter. Höchstwahrscheinlich hat er ein bestimmtes Fachgebiet, das ihm besser gefällt, aber aufgrund der vagen Kompetenzen findet keine Entwicklung statt. Infolgedessen riskiert die Person, ungenutzt und emotional ausgebrannt zu werden.

Stärken:

• verantwortungsbewusst;
• ergebnisorientiert;
• gelassen;
• vollständig kontrollierbar.

Aber:

• Zeigen durchschnittliche Ergebnisse aufgrund eines niedrigen Kompetenzniveaus;
• können keine komplexen und abstrakten Aufgaben lösen.

4. „Universal – ein Meister seines Fachs“

Eine Person mit einem soliden Hintergrund als Entwickler, die systematisches Denken mitbringt. Sie ist pedantisch und stellt hohe Anforderungen an sich selbst sowie an das Team. Jede Aufgabe, an der sie beteiligt ist, kann sich unendlich ausdehnen, wenn keine Grenzen festgelegt werden.

Ist gut vertraut mit der Architektur und wählt die Methode der technischen Umsetzung sorgfältig aus, indem sie die Auswirkungen der gewählten Lösung auf die aktuelle Architektur analysiert. Bescheiden, nicht ehrgeizig.

Stärken:

• zeigen eine hohe Arbeitsqualität;
• sind in der Lage, jede Aufgabe zu lösen;
• sind sehr arbeitsam.

Aber:

• intolerant gegenüber der Meinung anderer;
• Maximalisten. Sie versuchen, alles richtig zu machen, was die Entwicklungszeiten verlängert.

Was haben wir in der Praxis?

Schauen wir uns an, wie Rollen und Kompetenzen am häufigsten kombiniert werden. Ausgangspunkt ist ein Standard-Entwicklungsteam: PO, Entwicklungsmanager (Tech Lead), Analysten, Programmierer, Tester. Den Produktbesitzer und den Tech Lead zählen wir nicht dazu. Den ersten wegen fehlender technischer Kompetenzen. Der zweite sollte, wenn es im Team Probleme gibt, in der Lage sein, alles zu tun.

Die gängigste Form der Kombination von Fähigkeiten ist der Entwickler-Analytiker. Häufig kommen auch Analytiker-Testentwickler und „Drei-in-einem“-Rollen vor.

Anhand meines eigenen Teams möchte ich die Vor- und Nachteile von universellen Kollegen aufzeigen. Ein Drittel meines Teams besteht aus ihnen, und ich schätze sie sehr.

Von der PO erhielt ich einen dringenden Auftrag zur Einführung neuer Tarife in unser bestehendes Produkt. In meinem Team arbeiten vier Analysten. Zu diesem Zeitpunkt war einer im Urlaub, ein anderer krank und die übrigen kümmerten sich um strategische Aufgaben. Hätte ich sie herausgerissen, hätte dies unweigerlich die Umsetzung verzögert. Es blieb nur eine Lösung: das „Geheimwaffe“ – ein universeller Entwickler-Analytiker, der die erforderliche Fachkenntnis hatte. Nennen wir ihn Anatoli.

Sein Persönlichkeitstyp ist „Universalist – ich kriege das hin und mache es“. Natürlich versuchte er lange zu erklären, dass er einen „vollständigen Backlog seiner Aufgaben“ habe, aber auf meinen entschlossenen Befehl hin wurde er mit der dringenden Aufgabe betraut. Und Anatoli hat die Herausforderung gemeistert! Er hat die Anforderungen definiert und die Umsetzung fristgerecht durchgeführt, und die Auftraggeber waren zufrieden.

Auf den ersten Blick schien alles gelungen. Doch nach ein paar Wochen gab es erneut Anforderungen zur Überarbeitung dieses Produkts. Nun übernahm ein „reiner“ Analyst die Aufgabenstellung. In der Testphase der neuen Entwicklung konnten wir lange nicht verstehen, warum wir Fehler bei der Zuordnung neuer Tarife hatten. Erst nachdem wir das ganze Problem aufgedröselt hatten, kamen wir der Wahrheit näher. Wir haben viel Zeit verloren und die Fristen versäumt.

Das Problem lag darin, dass viele versteckte Details und Stolpersteine nur im Kopf unseres Alleskönners blieben und nicht schriftlich festgehalten wurden. Wie Anatoli später erklärte, hatte er es eilig. Wahrscheinlich stellte er bereits während der Entwicklung fest, dass er auf Probleme stieß, dokumentierte diese jedoch nirgendwo.

Es gab auch eine andere Situation. Derzeit haben wir nur einen Tester, weshalb einige Aufgaben von den Analysten getestet werden müssen, darunter auch die Alleskönner. Daher habe ich eine Aufgabe dem hypothetischen Fedor zugewiesen – „Alleskönner – in Ordnung, dann mache ich es, da sonst niemand da ist.".
Fedor – ein „Drei-in-einem“, aber für diese Aufgabe wurde bereits ein Entwickler zugewiesen. Das bedeutet, dass Fedor nur die Rollen Analyst und Tester kombinieren musste.

Die Anforderungen wurden gesammelt, die Spezifikation an die Entwicklung übergeben, es ist Zeit für die Tests. Fedor kennt das weiterzuentwickelnde System „wie seine eigenen fünf Finger“ und hat die aktuellen Anforderungen gründlich durchgearbeitet. Daher hat er sich nicht die Mühe gemacht, Testfälle zu schreiben, sondern führte Tests durch, um zu überprüfen, „wie das System funktionieren sollte“, und übergab es dann den Benutzern.
Der Test wurde abgeschlossen, die Weiterentwicklung wurde in die Produktion übergeben. Später stellte sich heraus, dass das System nicht nur die Durchführung von Zahlungen auf bestimmten Balancekonten aussetzt, sondern auch Zahlungen von sehr seltenen internen Konten blockiert, die nicht daran teilnehmen sollten.

Das geschah, weil Fedor nicht überprüft hat, „wie das System nicht funktionieren sollte“, er keinen Testplan oder Checklisten erstellt hat. Er wollte Zeit sparen und vertraute auf sein eigenes Gespür.

Wie gehen wir mit Problemen um?

Solche Situationen beeinträchtigen die Effizienz des Teams, die Qualität der veröffentlichten Releases und die Zufriedenheit der Kunden. Daher dürfen sie nicht unbeachtet bleiben und müssen analysiert werden.

1. Für jede Aufgabe, die Schwierigkeiten bereitet hat, bitte ich darum, ein einheitliches Formular auszufüllen: ein Fehlerprotokoll, das es ermöglicht, den Schritt zu identifizieren, an dem es zu einem 'Abfall' kam:

2. Nach der Identifizierung der Engpässe findet mit jedem Mitarbeiter, der das Problem beeinflusst hat, ein Brainstorming statt: 'Was ändern?'. (Einzelfälle betrachten wir nicht in der Retrospektive.) Daraus resultieren konkrete Maßnahmen, die je nach Persönlichkeit der Beteiligten unterschiedliche Fristen haben.

3. Wir haben Regeln für die Zusammenarbeit im Team eingeführt. Zum Beispiel haben wir vereinbart, alle Informationen über den Fortschritt der Aufgaben im Projektmanagementsystem festzuhalten. Bei Änderungen oder der Entdeckung von Artefakten während des Entwicklungsprozesses muss dies in der Wissensdatenbank und der endgültigen Version des Lastenhefts dokumentiert werden.

4. Die Kontrolle wird in jeder Phase durchgeführt (besonderes Augenmerk gilt problematischen Phasen in der Vergangenheit) und automatisch anhand der Ergebnisse der nächsten Aufgabe.

5. Wenn das Ergebnis für die nächste Aufgabe gleich bleibt, werde ich den betreffenden Universalisten nicht in die Rolle setzen, in der er schlecht abschneidet. Ich versuche, seine Fähigkeit und sein Interesse an der Entwicklung von Kompetenzen in dieser Rolle zu bewerten. Wenn ich keine Resonanz finde, lasse ich ihn in der Rolle, die ihm näher ist.

Was ist letztendlich herausgekommen?

Der Entwicklungsprozess wurde transparenter. Der BUS-Faktor hat sich reduziert. Die Teammitglieder, die an Fehlern arbeiten, werden motivierter und verbessern ihr Karma. Wir erhöhen schrittweise die Qualität unserer Releases.

Fazit

Mitarbeiter mit universellen Fähigkeiten haben ihre Vor- und Nachteile.

Vorteile:

• Man kann jederzeit eine hängende Aufgabe schließen oder ein dringendes Problem kurzfristig lösen;
• Ganzheitlicher Ansatz bei der Lösung von Aufgaben: Der Ausführende betrachtet diese aus der Perspektive aller Rollen;
• Universalisten können praktisch alles gleich gut erledigen.

Nachteile:

• Der BUS-Faktor wächst;
• Die grundlegenden Kompetenzen, die zur Rolle gehören, verwässern sich. Dadurch sinkt die Arbeitsqualität;
• Es besteht eine höhere Wahrscheinlichkeit von Fristverschiebungen, da die Kontrolle über jeden Schritt fehlt. Zudem bestehen Risiken, dass sich ein „Star“ herausbildet: Der Mitarbeiter ist überzeugt, dass er es besser weiß, dass er ein Profi ist.
• Das Risiko von beruflichem Burnout steigt.
• Wichtige Informationen über das Projekt könnten nur im Kopf des Mitarbeiters bleiben.

Wie Sie sehen, gibt es mehr Nachteile. Deshalb setze ich Universalisten nur ein, wenn die Ressourcen fehlen und die Aufgabe dringend ist, oder wenn eine Person über Kompetenzen verfügt, die anderen fehlen, und die Qualität auf dem Spiel steht.

Wenn in der gemeinsamen Arbeit an einer Aufgabe die Regel der Rollenteilung beachtet wird, steigt die Qualität der Arbeit. Wir betrachten Probleme aus verschiedenen Perspektiven, der Blick wird nicht eintönig, und es entstehen immer neue Gedanken. Gleichzeitig hat jedes Teammitglied die Möglichkeit, sich professionell weiterzuentwickeln und seine Kompetenzen zu erweitern.

Ich denke, das Wichtigste ist, sich dem Prozess zugehörig zu fühlen, die eigene Arbeit zu machen und schrittweise die Breite der eigenen Kompetenzen zu erweitern. Dennoch bringen Universalisten im Team einen Nutzen: Das Ziel ist, dass sie verschiedene Rollen effektiv kombinieren.

Ich wünsche allen selbstorganisierenden Teams von "Universalisten – Meistern ihres Fachs"!

Quelle: habr.com