„Universal“ im Entwicklungsteam: Nutzen oder Schaden?

Hallo zusammen! Mein Name ist Lyudmila Makarova, ich bin Entwicklungsmanagerin bei UBRiR und ein Drittel meines Teams sind "Alleskönner".

Geben Sie es zu: Jeder Tech Lead träumt von der cross-funktionalen Zusammenarbeit innerhalb seines Teams. Es ist großartig, wenn eine Person drei ersetzen kann und das auch noch qualitativ hochwertig, ohne die Fristen zu verschieben. Und nicht zu vergessen, es spart Ressourcen!
Das klingt sehr verlockend, aber ist es wirklich so? Lassen Sie uns das klären.

Wer ist unser Vorreiter der Erwartungen?

Unter dem Begriff "Alleskönner" versteht man normalerweise Teammitglieder, die mehr als eine Rolle kombinieren, zum Beispiel Entwickler-Analytiker.

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

Bei den Hard Skills ist alles klar, aber die Soft Skills verdienen besondere Beachtung. Sie helfen, den Zugang zum Mitarbeiter zu finden und ihn genau auf die Aufgabe zu lenken, bei der er maximal nützlich sein kann.

Es gibt viele Artikel über verschiedene Persönlichkeitstypen in der IT-Branche. Basierend auf meinen Erfahrungen würde ich IT-Alleskönner in vier Kategorien einteilen:

1. "Alleskönner – Allmächtig"

Solche gibt es überall. Sie zeigen immer viel Aktivität, wollen im Mittelpunkt stehen, fragen ständig bei Kollegen nach, ob sie helfen können, und können manchmal sogar nerven. Ihr Interesse gilt nur bedeutenden Aufgaben, die Raum für Kreativität bieten und ihr Ego erfreuen.

Dabei sind sie stark in:

• der Lage, komplexe Aufgaben zu lösen;
• tauchen tief in Probleme ein, "graben" und erzielen Ergebnisse;
• verfügen über einen neugierigen Verstand.

Aber:

• sind emotional labil;
• kaum steuerbar;
• haben ihre unbeirrbare Meinung, die sehr schwer zu ändern ist;
• schwierig zu motivieren, einfache Aufgaben zu erledigen. Einfache Aufgaben kratzen am Ego der Allmächtigen.

2. "Alleskönner – Ich werde es herausfinden und machen"

Solchen Leuten genügt ein Handbuch und ein wenig Zeit – und sie lösen das Problem. Normalerweise haben sie einen umfangreichen Hintergrund als DevOps. Diese Alleskönner scheuen sich nicht, zu planen, und ziehen es vor, die Entwicklungsmethode ausschließlich auf der Grundlage ihrer eigenen Erfahrung zu nutzen. Sie können problemlos mit dem Tech Lead über die gewählte Umsetzung der Aufgabe streiten.

Dabei sind sie stark in:

• unabhängig;
• stressresistent;
• kompetent in vielen Fragen;
• Wissensreich – mit ihnen gibt es immer etwas zu besprechen.

Aber:

• häufig Verpflichtungen verletzen;
• neigen dazu, alles zu komplizieren: lösen das Einmaleins durch partielle Integration;
• die Qualität der Arbeit ist niedrig, alles wird erst beim zweiten oder dritten Versuch erreicht;
• verschieben ständig die Fristen, weil sich herausstellt, dass es in Wirklichkeit nicht so einfach ist.

3. „Universal – na gut, lassen Sie es mich machen, da es sonst niemand gibt“

Der Mitarbeiter hat in mehreren Bereichen ein gutes Verständnis und entsprechende Erfahrung. Er kann jedoch in keinem von ihnen ein Profi werden, da er oft als Rettungsring eingesetzt wird, um aktuelle Aufgaben zu erledigen. Flexibel, fügsam, fühlt sich gefragt, ist es aber tatsächlich nicht.

Praktisch der ideale Mitarbeiter. Höchstwahrscheinlich hat er einen Bereich, der ihm mehr zusagt, aber durch die Unschärfe der Kompetenzen findet keine Entwicklung statt. Infolgedessen riskiert die Person, ungenutzt und emotional ausgebrannt zu werden.

Dabei sind sie stark in:

• verantwortlich;
• ergebnisorientiert;
• ruhig;
• vollständig kontrollierbar.

Aber:

• zeigen durchschnittliche Ergebnisse wegen niedrigem Kompetenzniveau;
• können komplexe und abstrakte Aufgaben nicht lösen.

4. „Universal – Meister seines Fachs“

Eine Person mit einem soliden Hintergrund als Entwickler, hat systemisches Denken. Ist pedantisch, stellt hohe Anforderungen an sich selbst und das Team. Jede Aufgabe mit seiner Beteiligung kann sich endlos ausdehnen, wenn die Grenzen nicht definiert werden.

Gut mit der Architektur vertraut, wählt die Methode der technischen Umsetzung und analysiert sorgfältig den Einfluss der gewählten Lösung auf die aktuelle Architektur. Bescheiden, wenig ehrgeizig.

Dabei sind sie stark in:

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

Aber:

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

Was haben wir in der Praxis?

Schauen wir uns an, wie häufig Rollen und Kompetenzen kombiniert werden. Nehmen wir als Ausgangspunkt ein standardmäßiges Entwicklungsteam: PO, Entwicklungsleiter (Techlead), Analysten, Programmierer, Tester. Den Produkteigentümer und den Techlead lassen wir außen vor. Den ersteren wegen des Fehlens technischer Kompetenzen, den zweiten muss man, falls im Team Probleme auftreten, gerade in der Lage sein, alles zu machen.

Die häufigste Variante der Zusammenlegung/Vereinigung/Kombination von Kompetenzen ist der Entwickler-Analytiker. Auch der Analytiker-Tester und „drei in einem“ kommen sehr häufig vor.

Anhand meines Teams werde ich die Vor- und Nachteile von Universalkollegen aufzeigen. Ein Drittel meines Teams besteht aus ihnen, und ich schätze sie sehr.

Von der PO kam eine dringende Aufgabe zur Einführung neuer Tarife in das bestehende Produkt. In meinem Team sind 4 Analysten. Zu diesem Zeitpunkt war einer im Urlaub, ein anderer krank, und die restlichen arbeiteten an der Umsetzung strategischer Aufgaben. Wenn ich sie herausgezogen hätte, hätte das unweigerlich die Umsetzungstermine gefährdet. Es blieb nur der einen Ausweg: das „geheime Waffen“ – den Universalkenner-Analytiker-Entwickler zu nutzen, der die erforderlichen Fachkenntnisse hatte. Nennen wir ihn Anatoli.

Sein Persönlichkeitstyp ist „Universalkenner – ich werde es herausfinden und umsetzen“. Natürlich hat er lange versucht zu erklären, dass er „einen vollständigen Backlog seiner Aufgaben“ hat, aber aufgrund meiner entschlossenen Entscheidung wurde er zur Lösung der dringenden Aufgabe geschickt. Und Anatoli hat es geschafft! Er hat die Anforderung formuliert und die Umsetzung rechtzeitig erledigt, und die Auftraggeber waren zufrieden.

Auf den ersten Blick war alles gelungen. Aber nach einigen Wochen gab es erneut Anforderungen zur Nachbearbeitung dieses Produkts. Für diese Aufgabe war nun ein „reiner“ Analyst zuständig. In der Testphase der neuen Entwicklung konnten wir lange nicht verstehen, warum Fehler bei der Zuordnung der neuen Tarife auftraten, und erst später, als wir das ganze Knäuel entwirrten, gelangten wir zur Wahrheit. Wir haben eine Menge Zeit verloren und die Fristen überschritten.

Das Problem lag darin, dass viele versteckte Aspekte und Fallstricke nur im Kopf unseres Universalkenner geblieben waren und nicht auf Papier festgehalten wurden. Wie Anatoli später erklärte, hatte er sich zu sehr beeilt. Aber am wahrscheinlichsten ist, dass er bereits bei der Entwicklung auf Probleme stieß und diese einfach umging, ohne sie irgendwo festzuhalten.

Es gab auch eine andere Situation. Jetzt haben wir nur einen Tester, daher müssen einige Aufgaben von den Analysten, einschließlich – Universalkennern, getestet werden. Deshalb habe ich eine Aufgabe einem hypothetischen Fjodor gegeben – „Universalkenner – in Ordnung, ich mache es, da sonst niemand da ist“.
Fjodor ist „drei in einem“, aber für diese Aufgabe war bereits ein Entwickler zugewiesen. Das bedeutet, dass Fjodor nur Analyst und Tester in einer Person vereinen musste.

Die Anforderungen wurden gesammelt, die Spezifikation an die Entwicklung übergeben, es ist Zeit zu testen. Fjodor kennt das überarbeitete System «wie seine fünf Finger» und hat die aktuellen Anforderungen akribisch bearbeitet. Daher hat er sich nicht die Mühe gemacht, Test-Szenarien zu schreiben, sondern hat getestet, «wie das System funktionieren sollte», und danach – an die Benutzer übergeben.
Der Test wurde abgeschlossen, die Überarbeitung ging an die Produktion. Später stellte sich heraus, dass das System nicht nur die Durchführung von Zahlungen auf bestimmten Kontoguthaben pausiert, sondern auch die Durchführung von Zahlungen von sehr seltenen internen Konten blockiert, die dabei nicht beteiligt sein sollten.

Das geschah, weil Fjodor nicht überprüft hat, wie «das System nicht funktionieren sollte», keinen Testplan und keine Checklisten erstellt hat. Er entschloss sich, Zeit zu sparen und vertraute auf sein eigenes Gespür.

Wie gehen wir mit Problemen um?

Ähnliche Situationen wirken sich auf die Effizienz der Teamarbeit, die Qualität der veröffentlichten Releases und die Zufriedenheit der Auftraggeber aus. Daher dürfen sie nicht unbeachtet bleiben und sollten analysiert werden.

1. Für jede Aufgabe, die Schwierigkeiten bereitet hat, bitte ich um das Ausfüllen eines einheitlichen Formulars: eines Fehlerberichts, der es ermöglicht, die Phase zu identifizieren, in der es zu einem «Rückgang» kam:

2. Nachdem die Engpässe identifiziert sind, findet mit jedem Mitarbeiter, der das Problem beeinflusst hat, ein Brainstorming statt: «Was müssen wir ändern?» (Einzelfälle betrachten wir nicht retrospektiv), aus dem konkrete Maßnahmen hervorgehen (für jeden Typ Persönlichkeit eigene) mit Terminen.

3. Wir haben Regeln für die Interaktion innerhalb des Teams eingeführt. Zum Beispiel haben wir vereinbart, alle Informationen über den Fortschritt der Aufgaben im Projektmanagementsystem festzuhalten. Bei Änderungen oder der Entdeckung von Artefakten im Entwicklungsprozess muss dies in der Wissensdatenbank und in der endgültigen Version der Spezifikation angezeigt werden.

4. Die Kontrolle fand in jeder Phase statt (besonderes Augenmerk wird auf problematische Phasen in der Vergangenheit gelegt) und automatisch auf Grundlage der Ergebnisse der nächsten Aufgabe.

5. Wenn sich das Ergebnis der nächsten Aufgabe nicht geändert hat, setze ich das betrachtete Universalgenie nicht in die Rolle, aus der er schlecht abschneidet. Ich versuche, seine Fähigkeit und seinen Wunsch zur Weiterentwicklung der Kompetenzen in dieser Rolle zu beurteilen. Wenn ich keine Resonanz finde, lasse ich ihn in der Rolle, die ihm näher ist.

Was ist letztendlich herausgekommen?

Der Entwicklungsprozess ist transparenter geworden. Der BUS-Faktor hat sich verringert. Teammitglieder, die an Fehlern arbeiten, sind motivierter und verbessern ihr Karma. Wir erhöhen allmählich die Qualität unserer Releases.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

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

Vorteile:

• Es ist möglich, eine hängende Aufgabe jederzeit zu schließen oder einen dringenden Bug in kurzer Zeit zu beheben;
• ein ganzheitlicher Ansatz bei der Lösung von Aufgaben: der Ausführende betrachtet sie aus der Perspektive aller Rollen;
• Universalisten können nahezu alles gleichermaßen gut erledigen.

Nachteile:

• Der BUS-Faktor wächst;
• die grundlegenden Kompetenzen, die spezifisch für eine Rolle sind, verschwimmen. Dadurch sinkt die Arbeitsqualität;
• Die Wahrscheinlichkeit von Terminverschiebungen steigt, da es keine Kontrolle über jeden Schritt gibt. Es bestehen auch Risiken für die Entstehung einer "Sternsituation": Der Mitarbeiter ist überzeugt, dass er besser weiß, dass er ein Profi ist;
• Das Risiko des beruflichen Burnouts steigt;
• Eine Menge wichtiger Informationen über das Projekt kann nur im "Kopf" des Mitarbeiters bleiben.

Wie Sie sehen, überwiegen die Nachteile. Daher setze ich Universalisten nur ein, wenn die Ressourcen knapp sind und die Aufgabe dringend ist. Oder wenn die Person Fähigkeiten hat, die bei anderen fehlen und bei denen es um Qualität geht.

Wenn bei der gemeinsamen Arbeit an einer Aufgabe die Regel der Rollenzuweisung eingehalten wird, steigt die Arbeitsqualität. Wir betrachten die Probleme aus verschiedenen Blickwinkeln, der Blick wird nicht einseitig, es kommen immer neue Gedanken hinzu. Gleichzeitig hat jedes Teammitglied alle Möglichkeiten für professionelles Wachstum und Erweiterung seiner Kompetenzen.

Ich glaube, dass das Wichtigste ist, seine Zugehörigkeit zum Prozess zu spüren, seine Arbeit zu tun und allmählich die Breite seiner Kompetenzen zu erhöhen. Dennoch bringen Universalisten im Team Vorteile: Es ist entscheidend, dass sie unterschiedliche Rollen effektiv kombinieren.

Ich wünsche allen selbstorganisierenden Teams von "Universalisten, die Meister ihres Fachs sind"!

Quelle: habr.com