Hallo allerseits! Mein Name ist Lyudmila Makarova, ich bin Entwicklungsleiterin bei der UBRD und ein Drittel meines Teams ist universell.
Erkennen: Jeder Tech Lead träumt von Cross-Funktionalität innerhalb seines Teams. Immerhin ist es so cool, wenn eine Person drei ersetzen kann und dies sogar qualitativ, ohne den Zeitrahmen zu verschieben. Und vor allem spart es Ressourcen!
Es klingt sehr verlockend, aber ist es wirklich so? Versuchen wir es herauszufinden.
Wer ist er, unser Antizipator der Erwartungen?
Unter dem Begriff „Generalist“ werden normalerweise Teammitglieder verstanden, die mehr als eine Rolle kombinieren, z. B. ein Entwicklungsanalyst.
Die Teaminteraktion und das Ergebnis ihrer Arbeit hängen von den beruflichen und persönlichen Qualitäten der Teilnehmer ab.
Durch harte Fähigkeiten ist alles klar, aber weiche Fähigkeiten verdienen besondere Aufmerksamkeit. Sie helfen dabei, einen Ansatz für einen Mitarbeiter zu finden und ihn genau auf die Aufgabe zu lenken, bei der er am nützlichsten ist.
Es gibt viele Artikel über alle Arten von Persönlichkeitstypen von Vertretern der IT-Branche. Aufgrund meiner Erfahrung würde ich IT-Universalien in vier Kategorien einteilen:
1. "Universal - Allmächtig"
Es gibt solche überall. Sie zeigen immer große Aktivität, wollen im Rampenlicht stehen, fragen ihre Kollegen ständig, ob ihre Hilfe benötigt wird, manchmal sogar nervig. Sie interessieren sich nur für wichtige Aufgaben, deren Teilnahme Raum für Kreativität bietet und Stolz amüsieren kann.
Was sind stark:
- in der Lage, komplexe Probleme zu lösen;
- tief in das Problem eingetaucht, "graben" und das Ergebnis erzielen;
- einen forschenden Geist besitzen.
Aber:
- emotional labil;
- schlecht geführt;
- ihren eigenen unerschütterlichen Standpunkt haben, der sehr schwer zu ändern ist;
- Es ist schwer, eine einfache Sache zu erledigen. Leichte Aufgaben verletzen die Allmacht des Stolzes.
2. "Kombi - ich werde es herausfinden und es tun"
Solche Leute haben genug Handbuch und ein wenig Zeit - und sie werden das Problem lösen. Normalerweise haben sie als DevOps einen großen Hintergrund. Solche Generalisten beschäftigen sich nicht mit Design und bevorzugen es, die Entwicklungsmethode nur aufgrund ihrer eigenen Erfahrung anzuwenden. Sie können leicht einen Snack mit Techlide über die gewählte Option zur Umsetzung der Aufgabe haben.
Was sind stark:
- unabhängig;
- stressresistent;
- kompetent in vielen Angelegenheiten;
- Gelehrte - es gibt immer etwas zu besprechen.
Aber:
- oft gegen Verpflichtungen verstoßen;
- neigen dazu, Dinge zu komplizieren: Sie lösen die Multiplikationstabelle durch Integration in Teile;
- Die Qualität der Arbeit ist gering, alles fällt 2-3 mal aus;
- Sie verschieben ständig die Fristen, weil sich in Wirklichkeit alles als nicht so einfach herausstellt.
3. "Universal - okay, lass mich, da es sonst niemanden gibt"
Der Mitarbeiter ist in mehreren Bereichen versiert und verfügt über einschlägige Erfahrung. Aber er schafft es in keinem von ihnen, ein Profi zu werden, weil er oft als Rettungsring eingesetzt wird und Löcher für aktuelle Aufgaben stopft. Formbar, effizient, hält sich für gefragt, ist es aber nicht.
Praktisch idealer Mitarbeiter. Höchstwahrscheinlich hat er eine Richtung, die er mehr mag, aber aufgrund der Unschärfe der Kompetenzen findet keine Entwicklung statt. Infolgedessen läuft eine Person Gefahr, nicht beansprucht und emotional ausgebrannt zu werden.
Was sind stark:
- sind verantwortlich;
- konzentrierte sich auf das Ergebnis;
- ruhig;
- voll kontrolliert.
Aber:
- ein durchschnittliches Ergebnis aufgrund eines geringen Kompetenzniveaus zeigen;
- kann komplexe und abstrakte Probleme nicht lösen.
4. "Universal ist ein Meister seines Fachs"
Eine Person mit einem ernsthaften Entwicklerhintergrund hat systemisches Denken. Pedantisch, fordernd von sich und dem Team. Jede Aufgabe mit seiner Teilnahme kann bis ins Unendliche wachsen, wenn Sie keine Grenzen definieren.
Er ist mit Architektur gut vertraut, wählt die Methode der technischen Implementierung und analysiert sorgfältig den Einfluss der gewählten Lösung auf die aktuelle Architektur. Bescheiden, nicht ehrgeizig.
Was sind stark:
- qualitativ hochwertige Arbeit zeigen;
- in der Lage, jedes Problem zu lösen;
- sehr effizient.
Aber:
- Intoleranz gegenüber den Meinungen anderer;
- Maximalisten. Sie versuchen, alles richtig zu machen, was die Entwicklungszeit verlängert.
Was haben wir in der Praxis?
Mal sehen, wie Rollen und Kompetenzen am häufigsten kombiniert werden. Nehmen wir als Ausgangspunkt das Standard-Entwicklungsteam: PO, Entwicklungsmanager (technischer Experte), Analysten, Programmierer, Tester. Wir werden den Eigentümer des Produkts und den technischen Leiter nicht berücksichtigen. Die erste - wegen mangelnder technischer Kompetenzen. Zweitens sollte er in der Lage sein, alles zu tun, wenn es Probleme im Team gibt.
Die häufigste Option zum Kombinieren / Zusammenführen / Kombinieren von Kompetenzen ist ein analytischer Entwickler. Auch ein Tester-Analyst und ein Drei-in-Eins sind sehr verbreitet.
Am Beispiel meines Teams zeige ich Ihnen die Vor- und Nachteile anderer Universalisten. Es gibt ein Drittel von ihnen in meinem Team, und ich liebe sie sehr.
PO erhielt die dringende Aufgabe, neue Tarife in ein bestehendes Produkt einzuführen. Mein Team hat 4 Analysten. Zu dieser Zeit war einer im Urlaub, der andere wurde krank und der Rest war mit der Umsetzung strategischer Aufgaben beschäftigt. Wenn ich sie herausziehen würde, würde dies unweigerlich die Implementierungsfristen stören. Es gab nur einen Ausweg: die "Geheimwaffe" zu benutzen - die Universalität des Entwickler-Analytikers, der den notwendigen Themenbereich besaß. Nennen wir ihn Anatoly.
Sein Persönlichkeitstyp ist
"Wagen - ich werde es herausfinden
und es tun .
" Natürlich versuchte er lange zu erklären, dass er "einen vollständigen Rückstand seiner Aufgaben" hatte, aber durch meine vorsätzliche Entscheidung wurde er geschickt, um eine dringende Aufgabe zu lösen. Und Anatoly hat es geschafft! Er hat die Implementierung pünktlich inszeniert und abgeschlossen, und die Kunden waren zufrieden.
Auf den ersten Blick hat alles geklappt. Nach einigen Wochen stellten sich jedoch erneut Anforderungen an die Überarbeitung dieses Produkts. Jetzt wurde die Einstellung für diese Aufgabe von einem „reinen“ Analysten übernommen. In der Testphase der neuen Entwicklung konnten wir lange Zeit nicht verstehen, warum wir Fehler beim Binden neuer Tarife hatten, und erst dann, nachdem wir das ganze Gewirr gelöst hatten, gingen wir der Wahrheit auf den Grund. Wir haben viel Zeit verbracht und Termine verpasst.
Das Problem war, dass viele versteckte Momente und Fallstricke nur im Kopf unseres Kombis verblieben und nicht auf Papier übertragen wurden. Wie Anatoly später erklärte, hatte er es eilig. Die wahrscheinlichste Option ist jedoch, dass er bereits während der Entwicklung auf Probleme gestoßen ist und diese einfach umgangen hat, ohne sie irgendwo zu reflektieren.
Es gab eine andere Situation. Jetzt haben wir nur noch einen Tester, daher müssen einige Aufgaben von Analysten getestet werden, einschließlich Generalisten. Deshalb gab ich dem bedingten Fedor eine Aufgabe -
"universell - okay, lassen Sie mich, da es sonst niemanden gibt" .
Fedor - "drei in einem", aber der Entwickler wurde bereits für diese Aufgabe ausgewählt. Feda musste also nur einen Analysten und einen Tester kombinieren.
Anforderungen werden gesammelt, die Spezifikation wird an die Entwicklung übergeben, es ist Zeit zu testen. Fedor kennt das in der Entwicklung befindliche System „wie seine Westentasche“ und hat die aktuellen Anforderungen gründlich ausgearbeitet. Daher 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 wurde abgeschlossen, die Überarbeitung ging zum Abschlussball. Später stellte sich heraus, dass das System nicht nur Zahlungen auf bestimmte Saldokonten aussetzt, sondern auch Zahlungen von sehr seltenen internen Konten blockiert, die daran nicht beteiligt sein sollten.
Dies geschah aufgrund der Tatsache, dass Fedor keine Überprüfung durchgeführt hat, wie "das System nicht funktionieren sollte", keinen Testplan erstellt und Checklisten erstellt hat. Er beschloss, Zeit zu sparen und verließ sich auf seinen eigenen Instinkt.
Wie arbeiten wir mit Problemen?
Solche Situationen wirken sich auf die Effektivität des Teams, die Qualität der Veröffentlichungen und die Kundenzufriedenheit aus. Daher können sie nicht ignoriert und die Gründe analysiert werden.
1. Für jedes Problem, das zu Schwierigkeiten geführt hat, bitte ich Sie, ein einheitliches Formular auszufüllen: eine Fehlerzuordnung, mit der Sie das Stadium identifizieren können, in dem der "Drawdown" stattgefunden hat:
2. Nachdem Sie Engpässe festgestellt haben, führt jeder Mitarbeiter, der das Problem beeinflusst hat, eine Brainstorming-Sitzung mit dem Titel „Was muss geändert werden?“ Durch. (Sonderfälle werden im Retro-Modus nicht berücksichtigt), wodurch bestimmte Aktionen (für jeden Persönlichkeitstyp) mit Zeitplänen geboren werden.
3. Wir haben die Interaktionsregeln im Team eingeführt. Zum Beispiel haben wir vereinbart, notwendigerweise alle Informationen über den Fortschritt der Aufgabe im Projektmanagementsystem aufzuzeichnen. Wenn Sie Artefakte während des Entwicklungsprozesses ändern / identifizieren, müssen Sie dies in der Wissensdatenbank und in der endgültigen Version des TOR anzeigen.
4. Die Kontrolle begann in jeder Phase (besondere Aufmerksamkeit wird problematischen Phasen in der Vergangenheit gewidmet) und basiert automatisch auf den Ergebnissen der nächsten Aufgabe.
5. Wenn sich das Ergebnis der nächsten Aufgabe nicht geändert hat, stelle ich den fraglichen Wagen nicht in die Rolle, mit der er schlecht zurechtkommt. Ich versuche, seine Fähigkeit und seinen Wunsch zu bewerten, Kompetenzen in dieser Rolle zu entwickeln. Wenn ich keine Antwort finde, lasse ich ihn in der Rolle, die ihm näher steht.
Was ist das Ergebnis?
Der Entwicklungsprozess ist transparenter geworden. Der BUS-Faktor nahm ab. Teammitglieder, die an Fehlern arbeiten, werden motivierter und verbessern ihr Karma. Wir verbessern schrittweise die Qualität unserer Veröffentlichungen.
Schlussfolgerungen
Universelle Mitarbeiter haben ihre Vor- und Nachteile.
Vorteile:- Sie können die durchhängende Aufgabe jederzeit schließen oder einen dringenden Fehler in kurzer Zeit beheben.
- ein integrierter Ansatz zur Lösung des Problems: Der Darsteller betrachtet es von der Seite aller Rollen;
- Generalisten können fast alles gleich gut.
Nachteile:- Der BUS-Faktor wächst;
- Die der Rolle innewohnenden Kernkompetenzen werden untergraben. Dadurch wird die Qualität der Arbeit verringert;
- die Wahrscheinlichkeit einer Verschiebung der Begriffe steigt, weil In jeder Phase gibt es keine Kontrolle. Es besteht auch das Risiko, einen „Stern“ zu bekommen: Der Mitarbeiter ist sich sicher, dass er besser weiß, dass er ein Profi ist.
- das Risiko eines professionellen Burnouts steigt;
- Viele wichtige Informationen über das Projekt können nur „im Kopf“ des Mitarbeiters bleiben.
Wie Sie sehen können, gibt es mehr Mängel. Daher verwende ich Universalien nur, wenn nicht genügend Ressourcen vorhanden sind und die Aufgabe dringend genug ist. Oder eine Person hat Kompetenzen, die andere nicht haben, und Qualität steht auf dem Spiel.
Wenn bei der gemeinsamen Arbeit an einer Aufgabe die Regel der Rollenverteilung eingehalten wird, steigt die Qualität der Arbeit. Wir betrachten Probleme aus verschiedenen Blickwinkeln, unsere Augen sind nicht verschwommen, es erscheinen immer neue Gedanken. Darüber hinaus hat jedes Mitglied des Teams alle Möglichkeiten zur beruflichen Weiterentwicklung und zur Erweiterung seiner Kompetenzen.
Ich glaube, das Wichtigste ist, sich in den Prozess involviert zu fühlen, sich an Ihrer Arbeit zu beteiligen und die Breite Ihrer Kompetenzen schrittweise zu erweitern. Trotzdem sind Wagen in einem Team von Vorteil: Die Hauptsache ist, sicherzustellen, dass sie verschiedene Rollen effektiv kombinieren.
Ich wünsche allen ein selbstorganisierendes Team von „Universalmeistern ihres Fachs“!