Ich implementiere derzeit Scrum und einen Wechsel zu Ruby on Rails in meiner Organisation. Wir haben ein Team von sechs Entwicklern, von denen nur zwei Erfahrung mit Ruby on Rails haben. Zwei der anderen Entwickler verstehen Rails relativ schnell, aber die dritte zögert und beschwert sich ständig über Rails und ihre Abneigung gegen das Framework.
Ich habe moralisches Coaching sowie mehrere Ressourcen bereitgestellt, damit sie die Rails-Kurve so schnell wie möglich passieren können, aber ich kann diese Person einfach nicht an Bord holen, indem ich mich unseren Sprint-Zielen und Arbeitsinstrumenten (z. B. Rails) verpflichte. Sobald sie von etwas frustriert wird, gerät sie in eine mentale Blockade, die den Rest des Teams verärgert (mich eingeschlossen, obwohl ich die Ereignisse in einer ruhigen Art und Weise handhabe). Ich denke, es ist eher ein Wutanfall oder ein Anfall als ein tatsächliches technisches Problem in Bezug auf das Erlernen des Frameworks.
Irgendwelche Ideen oder Rückmeldungen, die mir helfen könnten, ein besserer Manager zu sein und diese Person hoffentlich an Bord zu holen?
Der beste Weg, den ich gefunden habe, um einem ganzen Team oder einem einzelnen Teammitglied zu helfen, mit einem neuen Projekt/einer neuen Technologie/Fähigkeit/einem notwendigen Übel an Bord zu kommen, ist „Subversion“. (man beachte die ironischen Zitate)
Eine Person, die stark gegen eine bestimmte Technologie ist (in diesem Fall), fühlt sich eindeutig isoliert oder ignoriert oder dass ihr Status in der Gruppe untergraben wird. Ihre Aufgabe als PM wird also immer darin bestehen, die Persönlichkeiten Ihres Teams zu managen, und dies ist keine Ausnahme.
Die Menschen wollen das Gefühl haben, dass ihre Position sicher ist, ihre Beiträge und Meinungen geschätzt werden, ihre Stimme gehört wird. Sie müssen also analysieren, warum diese Person sich so fühlt, wie sie ist.
Sobald Sie also die zugrunde liegende Ursache herausgefunden haben (und die obigen Beschreibungen sind nur einige davon und wahrscheinlich VIEL zu vereinfacht), müssen Sie als PM ihre Position in der Gruppe erneut bestätigen, indem Sie ihr Arbeit geben, die sie beruhigt. So...
All diese Lösungen sind natürlich simpel, geben Ihnen aber hoffentlich eine Vorstellung davon, wie Sie Ihr gesamtes Team und den einen abweichenden Entwickler dazu bringen können, sich in das neue Rails-Framework einzukaufen. Machen Sie es ihnen zu eigen. Gehen Sie auf ihre Einwände ein, indem Sie nach ihrer Lösung innerhalb des Frameworks fragen (dh Rails wegzuwerfen ist nicht die Antwort). Wenn Sie den Entwickler dazu bringen können, sich auf die Details der Überwindung seiner eigenen Einwände zu konzentrieren, erhalten Sie die Zustimmung, die Sie benötigen, und ein friedlicheres Team.
Da ich nur Ihre Seite der Dinge gehört habe, bin ich nicht bereit anzunehmen, dass das Problem die Person ist, von der Sie sprechen. Ich stimme zwar zu, dass es ein Problem gibt, aber das Problem betrifft Menschen, Prozesse und das Änderungsmanagement. Sie müssen dies bestätigen, bevor das Problem zur Zufriedenheit aller gelöst werden kann.
Höchstwahrscheinlich müssen Sie einige Änderungen an der Zusammensetzung Ihres Teams vornehmen. Das ist keine Anklage gegen das Teammitglied; Es ist einfach so, dass ein effektives Change Management manchmal personelle Veränderungen erfordert.
Wenn Sie diese Frage auf einer anderen Q&A-Website wie Workplace SE stellen , erhalten Sie möglicherweise eine andere Antwort. Aus Sicht des Projektmanagements und insbesondere aus agiler Sicht haben Sie organisatorische Veränderungen jedoch nicht richtig umgesetzt.
Beim Programmieren ändern Sie eine einfache Sache nach der anderen, damit Sie sie debuggen können. Sie haben mindestens zwei komplexe Dinge gleichzeitig geändert und haben Schwierigkeiten, sie zu debuggen.
Scrum (oder jedes Projektmanagement-Framework) erfordert Schulung und Zeit, um effektiv implementiert zu werden. Darüber hinaus erfordern agile Frameworks die Zustimmung des gesamten Teams, nicht nur des Projektmanagers.
Wenn Sie Teammitglieder haben, die nicht an agilen Praktiken oder Scrum-Zeremonien interessiert sind, und Sie wirklich alle lehrbaren Momente und Coaching-Möglichkeiten ausgeschöpft haben, dann müssen Sie die Verantwortung dafür übernehmen, dass Sie ein Framework vorgeschrieben haben, ohne zuvor Buy-in geschaffen zu haben. Danach müssen Sie ein Team bilden, das sich aus selbstorganisierenden Personen zusammensetzt, die einem agilen Framework folgen möchten .
An der Jobfront haben Sie eine Reihe von Änderungen an der Stellenbeschreibung des Teams vorgenommen, darunter:
Wenn Sie all das geändert haben, haben Sie wahrscheinlich auch das Produkt geändert, das Sie bauen. Das ist eine Menge Veränderung in der Stellenbeschreibung einer Person, und nicht jeder in der IT möchte funktionsübergreifend sein oder neue Sprachen und Frameworks lernen, die nicht zu seinen kognitiven Mustern passen.
Manche Menschen genießen die Möglichkeit, neue Technologien zu nutzen oder an einem neuen Projekt zu arbeiten, während andere Stabilität bevorzugen und in einer klar definierten Komfortzone bleiben. Wenn Sie gerade die Stellenbeschreibung von jemandem von .NET- oder Java-Programmierer in einem Wasserfall-Shop zu Ruby on Rails-Entwickler in einer Scrum- und/oder DevOps-Organisation geändert haben, wird es sicherlich Leute geben, die den Wechsel nicht schaffen können oder wollen.
Wenn das Team diese Änderung des Technologie-Stacks nicht vorangetrieben hat, muss das Management bereit sein, die Verantwortung für die Änderung der Stellenbeschreibung zu übernehmen. Darüber hinaus sollten sowohl die Geschäftsleitung als auch der Projektmanager damit rechnen, ein Team um einen neuen Technologie-Stack herum umschulen und reformieren zu müssen.
Nicht alle Änderungen liegen in der Verantwortung des Mitarbeiters. Es ist großartig, dass Sie fünf von sechs Ihrer derzeitigen Teammitglieder mit den neuen Projekt- und Technologie-Frameworks an Bord haben. Jetzt ist es Ihre Aufgabe, festzustellen, ob es eine Rolle für jemanden gibt, der nicht zu Ihrem neuen IT-Modell passt.
Vielleicht kann diese Person eine andere Rolle innerhalb des Unternehmens oder des Teams übernehmen. Vielleicht gibt es andere Projekte oder andere Teams, an denen diese Person arbeiten kann, die für sie von größerem Interesse sein könnten. Wenn nicht, sagen Sie im Wesentlichen: „Übernehmen Sie das neue Paradigma oder finden Sie einen neuen Job.“
Als Unternehmen ist das vielleicht keine unvernünftige Perspektive. Unter dem Gesichtspunkt der Teambildung erzielen Sie jedoch im Allgemeinen bessere Ergebnisse, wenn Sie anerkennen, dass nicht jede Person für jedes Team oder jede Organisationskultur geeignet ist. Denken Sie daran, wenn Sie sich entscheiden, Änderungen an Ihrer Teamzusammensetzung vorzunehmen, denn nichts zerstört den Teamzusammenhalt so schnell wie die Schuldzuweisung an die Mitarbeiter für die Ergebnisse strategischer Entscheidungen des Unternehmens.
Betrachten Sie dies als eine Änderung der Jobanforderungen und nicht als ein zwischenmenschliches Problem. Dies ist nicht nur ein konstruktiverer Ansatz als der Versuch, Schuldzuweisungen vorzunehmen, sondern führt auch eher zu einer objektiven Lösung.
Tatsache ist, dass Rails ein veraltetes, langsames und fehlerhaftes Framework ist.
Ich gehe davon aus, dass Sie gezwungen waren, einige Legacy-Projektarbeiten zu übernehmen, die deren Verwendung vorschreiben, aber Sie müssen erkennen, dass die Arbeit an diesem Projekt für die Karrieren Ihrer Entwickler nicht von Vorteil sein wird.
Wenn Sie sie nicht durch höhere Löhne, Heimarbeit, weniger Stunden oder ähnliches kompensieren, werden die Guten woanders arbeiten gehen.
Die Lösung ist einfach. Fragen Sie den Entwickler: „Wenn Sie ein Freiberufler wären, wie viel Aufpreis würden Sie für ein Rails-Projekt gegenüber einem ‚Lieblingssprachen‘-Projekt verlangen?“ Dann zahlen Sie ihnen den zusätzlichen Prozentsatz
nvoigt