Hallo zusammen! Mein Name ist Lyudmila Makarova, ich bin Entwicklungsmanagerin bei UBRD und ein Drittel meines Teams sind „Generalisten“.
Geben Sie es zu: Jeder Tech Lead träumt von funktionsübergreifender Zusammenarbeit in seinem Team. Es ist so cool, wenn eine Person in der Lage ist, drei zu ersetzen, und das sogar effizient, ohne die Fristen zu verzögern. Und das Wichtigste: Es spart Ressourcen!
Es klingt sehr verlockend, aber ist es wirklich so? Versuchen wir es herauszufinden.
Wer ist er, unser Vorbote der Erwartungen?
Der Begriff „Generalist“ bezieht sich normalerweise auf Teammitglieder, die mehr als eine Rolle vereinen, beispielsweise Entwickler-Analyst.
Das Zusammenspiel des Teams und das Ergebnis seiner Arbeit hängen von den fachlichen und persönlichen Qualitäten der Teilnehmer ab.
Über Hard Skills ist alles klar, aber Soft Skills verdienen besondere Aufmerksamkeit. Sie helfen dabei, einen Mitarbeiter zu erreichen und ihn an die Aufgabe weiterzuleiten, bei der er am nützlichsten ist.
Es gibt viele Artikel über alle Arten von Persönlichkeitstypen in der IT-Branche. Aufgrund meiner Erfahrung würde ich IT-Generalisten in vier Kategorien einteilen:
1. „Universell – Allmächtig“
Diese gibt es überall. Sie sind immer sehr aktiv, wollen im Mittelpunkt stehen, fragen ständig ihre Kollegen, ob sie Hilfe brauchen, und manchmal können sie sogar nervig sein. Sie interessieren sich nur für sinnvolle Aufgaben, deren Teilnahme Raum für Kreativität gibt und ihren Stolz befriedigen kann.
Worin sind sie stark:
- sind in der Lage, komplexe Probleme zu lösen;
- tief in das Problem eintauchen, „graben“ und Ergebnisse erzielen;
- einen neugierigen Geist haben.
Aber:
- emotional labil;
- schlecht verwaltet;
- haben ihren eigenen unerschütterlichen Standpunkt, der sehr schwer zu ändern ist;
- Es ist schwer, jemanden dazu zu bringen, eine einfache Sache zu tun. Leichte Aufgaben verletzen das Ego des Allmächtigen.
2. „Universell – ich werde es herausfinden und es tun“
Solche Leute brauchen nur ein Handbuch und ein wenig Zeit – und sie werden das Problem lösen. Sie verfügen in der Regel über fundierte Kenntnisse im Bereich DevOps. Solche Generalisten kümmern sich nicht um Design und bevorzugen eine Entwicklungsmethode, die ausschließlich auf ihrer Erfahrung basiert. Sie können problemlos mit dem technischen Leiter über die gewählte Option zur Umsetzung der Aufgabe diskutieren.
Worin sind sie stark:
- unabhängig;
- Stressresistent;
- kompetent in vielen Belangen;
- gelehrt - mit ihnen gibt es immer etwas zu besprechen.
Aber:
- verstoßen oft gegen Pflichten;
- neigen dazu, alles zu komplizieren: Lösen Sie das Einmaleins durch partielle Integration;
- die Arbeitsqualität ist gering, alles funktioniert 2-3 Mal;
- Sie verschieben ständig Fristen, denn in Wirklichkeit ist alles nicht so einfach.
3. „Universal – okay, lass es mich machen, da sonst niemand da ist“
Der Mitarbeiter ist in mehreren Bereichen versiert und verfügt über entsprechende Erfahrung. Doch in keinem von ihnen gelingt es ihm, ein Profi zu werden, da er oft als Lebensader eingesetzt wird und Lücken in aktuellen Aufgaben stopft. Biegsam, effizient, hält sich für gefragt, ist es aber nicht.
Ein praktischer idealer Mitarbeiter. Höchstwahrscheinlich hat er eine Richtung, die ihm am besten gefällt, aber aufgrund der Verwischung der Kompetenzen kommt es nicht zu einer Entwicklung. Infolgedessen besteht die Gefahr, dass eine Person nicht beansprucht wird und emotional ausgebrannt ist.
Worin sind sie stark:
- verantwortlich;
- ergebnisorientiert;
- ruhig;
- völlig kontrolliert.
Aber:
- aufgrund eines geringen Kompetenzniveaus durchschnittliche Ergebnisse zeigen;
- kann komplexe und abstrakte Probleme nicht lösen.
4. „Ein Allrounder ist ein Meister seines Fachs“
Eine Person mit einem ernsthaften Hintergrund als Entwickler verfügt über Systemdenken. Pedantistisch, anspruchsvoll gegenüber sich selbst und seinem Team. Jede Aufgabe, an der er beteiligt ist, kann ins Unendliche wachsen, wenn keine Grenzen definiert sind.
Er ist mit der Architektur gut vertraut, wählt eine Methode der technischen Umsetzung und analysiert sorgfältig die Auswirkungen der gewählten Lösung auf die aktuelle Architektur. Bescheiden, nicht ehrgeizig.
Worin sind sie stark:
- hohe Arbeitsqualität zeigen;
- in der Lage, jedes Problem zu lösen;
- sehr effizient.
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?
Sehen wir uns an, wie Rollen und Kompetenzen am häufigsten kombiniert werden. Nehmen wir als Ausgangspunkt ein Standard-Entwicklungsteam: PO, Entwicklungsmanager (Tech Lead), Analysten, Programmierer, Tester. Wir werden den Produktbesitzer und den technischen Leiter nicht berücksichtigen. Der erste Grund liegt in einem Mangel an technischen Kompetenzen. Der zweite sollte, wenn es Probleme im Team gibt, alles können.
Die häufigste Option zum Kombinieren/Zusammenführen/Kombinieren von Kompetenzen ist Entwickler-Analyst. Auch Testanalytiker und „Three in One“ sind weit verbreitet.
Am Beispiel meines Teams zeige ich Ihnen die Vor- und Nachteile meiner Generalistenkollegen. In meinem Team gibt es ein Drittel von ihnen, und ich liebe sie sehr.
PO erhielt die dringende Aufgabe, neue Zölle in ein bestehendes Produkt einzuführen. Mein Team besteht aus 4 Analysten. Zu dieser Zeit war der eine im Urlaub, der andere war krank und der Rest war mit der Umsetzung strategischer Aufgaben beschäftigt. Würde ich sie zurückziehen, würde das unweigerlich zu einer Unterbrechung der Umsetzungsfristen führen. Es gab nur einen Ausweg: die „Geheimwaffe“ einzusetzen – einen vielseitigen Entwickler-Analysten, der das erforderliche Themengebiet beherrscht. Nennen wir ihn Anatoly.
Sein Persönlichkeitstyp ist „universell – ich werde es herausfinden und es tun“. Natürlich versuchte er lange zu erklären, dass er „einen vollen Rückstand an Aufgaben hat“, aber durch meine willensstarke Entscheidung wurde er geschickt, um ein dringendes Problem zu lösen. Und Anatoly hat es geschafft! Er hat das Staging durchgeführt und die Umsetzung termingerecht abgeschlossen, die Kunden waren zufrieden.
Auf den ersten Blick hat alles geklappt. Doch schon nach einigen Wochen ergaben sich für dieses Produkt erneut Verbesserungsbedarfe. Nun wurde die Formulierung dieses Problems von einem „reinen“ Analytiker vorgenommen. In der Testphase der Neuentwicklung konnten wir lange Zeit nicht verstehen, warum wir Fehler bei der Verknüpfung neuer Tarife hatten, und erst dann, nachdem wir das ganze Gewirr enträtselt hatten, kamen wir der Wahrheit auf den Grund. Wir haben viel Zeit verschwendet und Fristen verpasst.
Das Problem war, dass viele versteckte Momente und Fallstricke nur im Kopf unseres Kombis blieben und nicht aufs Papier übertragen wurden. Wie Anatoly später erklärte, hatte er es zu eilig. Am wahrscheinlichsten ist jedoch, dass er bereits während der Entwicklung auf Probleme gestoßen ist und diese einfach umgangen hat, ohne dies irgendwo zu reflektieren.
Es gab eine andere Situation. Jetzt haben wir nur noch einen Tester, daher müssen einige Aufgaben von Analysten, darunter auch Generalisten, getestet werden. Deshalb habe ich dem bedingten Fedor eine Aufgabe gegeben - „universell – okay, lass es mich machen, da sonst niemand da ist“.
Fedor ist ein „Drei in Eins“, für diese Aufgabe wurde jedoch bereits ein Entwickler zugewiesen. Das bedeutet, dass Fedya nur einen Analysten und einen Tester vereinen musste.
Die Anforderungen sind gesammelt, die Spezifikation wurde der Entwicklung vorgelegt, es ist Zeit zum Testen. Fedor kennt das zu modifizierende System „wie seine Westentasche“ und hat die aktuellen Anforderungen gründlich ausgearbeitet. Deshalb machte er sich nicht die Mühe, Testskripte zu schreiben, sondern testete, „wie das System funktionieren sollte“ und gab es dann an die Benutzer weiter.
Der Test war abgeschlossen, die Revision ging in Produktion. Später stellte sich heraus, dass das System nicht nur Zahlungen auf bestimmte Guthabenkonten sperrte, sondern auch Zahlungen von sehr seltenen internen Konten blockierte, die daran nicht teilnehmen sollten.
Dies geschah aufgrund der Tatsache, dass Fedor nicht überprüfte, wie „das System nicht funktionieren sollte“, keinen Testplan oder Checklisten erstellte. Er beschloss, das Timing zu sparen und sich auf seine eigenen Instinkte zu verlassen.
Wie gehen wir mit Problemen um?
Situationen wie diese wirken sich auf die Teamleistung, die Release-Qualität und die Kundenzufriedenheit aus. Daher können sie nicht ohne Aufmerksamkeit und Analyse der Gründe gelassen werden.
1. Für jede Aufgabe, die Schwierigkeiten verursacht hat, bitte ich Sie, ein einheitliches Formular auszufüllen: eine Fehlerkarte, die es Ihnen ermöglicht, die Phase zu identifizieren, in der der „Drawdown“ aufgetreten ist:
2. Nach der Identifizierung von Engpässen wird mit jedem Mitarbeiter, der das Problem beeinflusst hat, ein Brainstorming durchgeführt: „Was soll geändert werden?“ (Wir berücksichtigen keine Sonderfälle im Nachhinein), wodurch spezifische Handlungen (spezifisch für jeden Persönlichkeitstyp) mit Fristen entstehen.
3. Wir haben Regeln für die Interaktion im Team eingeführt. Beispielsweise haben wir vereinbart, alle Informationen über den Fortschritt einer Aufgabe unbedingt im Projektmanagementsystem zu erfassen. Wenn Artefakte während des Entwicklungsprozesses geändert/identifiziert werden, muss sich dies in der Wissensdatenbank und der endgültigen Version der technischen Spezifikationen widerspiegeln.
4. Die Kontrolle begann in jeder Phase (besonderes Augenmerk wird auf problematische Phasen in der Vergangenheit gelegt) und automatisch auf der Grundlage der Ergebnisse der nächsten Aufgabe.
5. Wenn sich das Ergebnis bei der nächsten Aufgabe nicht verändert hat, dann ordne ich den betreffenden Generalisten nicht der Rolle zu, in der er schlecht zurechtkommt. Ich versuche, seine Fähigkeit und seinen Wunsch einzuschätzen, in dieser Rolle Kompetenzen zu entwickeln. Wenn ich keine Antwort finde, belasse ich ihn in der Rolle, die ihm näher ist.
Was ist am Ende passiert?
Der Entwicklungsprozess ist transparenter geworden. Der BUS-Faktor hat abgenommen. Teammitglieder, die an Fehlern arbeiten, werden motivierter und verbessern ihr Karma. Wir verbessern schrittweise die Qualität unserer Veröffentlichungen.
Befund
Generalistische Mitarbeiter haben ihre Vor- und Nachteile.
Vorteile:
- Sie können eine stagnierende Aufgabe jederzeit schließen oder einen dringenden Fehler in kurzer Zeit beheben;
- ein integrierter Ansatz zur Lösung eines Problems: Der Darsteller betrachtet es aus der Perspektive aller Rollen;
- Generalisten können fast alles gleich gut.
Nachteile:
- BUS-Faktor erhöht sich;
- Die der Rolle innewohnenden Kernkompetenzen werden untergraben. Dadurch sinkt die Qualität der Arbeit;
- die Wahrscheinlichkeit einer Fristverschiebung steigt, weil Es gibt keine Kontrolle in jeder Phase. Es besteht auch das Risiko, ein „Star“ zu werden: Der Mitarbeiter ist zuversichtlich, dass er besser weiß, dass er ein Profi ist;
- das Risiko eines beruflichen Burnouts steigt;
- Viele wichtige Informationen über das Projekt können nur „im Kopf“ des Mitarbeiters bleiben.
Wie Sie sehen, gibt es noch weitere Mängel. Deshalb verwende ich Generalisten nur dann, wenn die Ressourcen nicht ausreichen und die Aufgabe recht dringend ist. Oder eine Person verfügt über Kompetenzen, die anderen fehlen, aber die Qualität steht auf dem Spiel.
Wird bei der gemeinsamen Bearbeitung einer Aufgabe die Regel der Rollenverteilung beachtet, steigt die Arbeitsqualität. Wir betrachten Probleme aus verschiedenen Blickwinkeln, unser Blick ist nicht verschwommen, es tauchen immer neue Gedanken auf. Gleichzeitig hat jedes Teammitglied alle Möglichkeiten zur beruflichen Weiterentwicklung und Erweiterung seiner Kompetenzen.
Ich glaube, das Wichtigste ist, sich in den Prozess eingebunden zu fühlen, seine Arbeit zu erledigen und die Breite seiner Kompetenzen schrittweise zu erweitern. Allerdings bringen Generalisten im Team Vorteile mit sich: Es geht vor allem darum, unterschiedliche Rollen effektiv zu vereinen.
Ich wünsche allen ein sich selbst organisierendes Team von „universellen Meistern ihres Fachs“!
Source: habr.com