Wie macht man aus unterdurchschnittlichen Softwareentwicklern bessere?

Nach dem, was Sie sagen, liegt das Problem in der Liebe zum Detail, der Überprüfung und dem Kriechen des Umfangs? Die oben genannten Punkte sind zwar nützlich und bieten Einblicke, sie verleihen Ihrem Team jedoch nicht die Fähigkeiten, die es benötigt, um die von Ihnen gesammelten Entwicklungspunkte zu meistern. Das kommt im Laufe der Zeit mit der richtigen Richtung ( ich gehe davon aus, dass die Ressourcen, mit denen Sie arbeiten, hier relativ jung sind ).

Ich würde auch sagen, dass es zwar großartig ist, Kenntnisse über die verschiedenen von Ihnen erwähnten Methoden zu haben, es für den Entwickler jedoch verwirrend sein könnte, in welchem ​​​​Modus sie arbeiten sollten. Zum Beispiel das Verhalten, das ich von einem Programmierer erwarten würde in einer Scrum-Umgebung würden sich sehr von denen unterscheiden, die in einer strengeren ITIL-basierten Methodik erwartet werden. Achten Sie darauf, nicht zu verwirren oder gemischte Botschaften zu geben.

Kann ich ein paar Dinge vorschlagen, die in der Vergangenheit für mich funktioniert haben? Der Schlüssel zu allen ist, sie regelmäßig und zuverlässig zu machen. Wiederholung betont die Wichtigkeit und sorgt auch dafür, dass das Wissen haften bleibt.

1. Vorhandene Arbeit / Überprüfung des Umfangs: Eine einmal wöchentliche Sitzung, um die Arbeit für die Woche, in der sie zugewiesen wurde, zu überprüfen und, was wichtig ist, diese mit dem vereinbarten Umfang in Beziehung zu setzen. Dies gibt Entwicklern den Blick auf das „große Ganze“, den sie benötigen, zusätzlich zu der Richtung, die ihren Spielraum einschränkt. Es zeigt auch, wie das, was sie tun, mit der Arbeit der Menschen um sie herum interagiert. Protokollieren Sie diese Sitzung, damit die Leute darauf zurückgreifen können. Der Nachteil dabei ist, dass die Leute dazu neigen, nicht zu schreien, wenn die in dieser Sitzung definierte Arbeit vorzeitig abgeschlossen wird;)
2. Peer-Review: Menschen lernen mehr Aufmerksamkeit für Details, wenn sie ermutigt werden, regelmäßige Peer-Reviews der Arbeit durchzuführen. Wir erstellen im Allgemeinen Checklisten für bestimmte Leistungen, um dies für Ressourcen anzukurbeln, die den erforderlichen Standard bereits nicht ganz erreichen (z. B. häufige Fehler, auf die in jeder technischen Spezifikation zu achten ist). Dies sollte Ihnen auch dabei helfen, Ihr Engagement im Laufe der Zeit zu reduzieren, wenn sie sich verbessern.
3. 360-Grad-Feedback: Feedback an jeden sollte sofort erfolgen, um die größte Wirkung zu erzielen, und auf konstruktive Weise übermittelt werden. Das ist leichter gesagt als getan und erfordert einige Anstrengungen von Ihrer Seite, um bereit zu sein, direkt zu sein. Abhängig von der Kultur, in der Sie sich befinden, fühlen sich Ihre Entwickler jedoch möglicherweise weniger wohl dabei, Ihnen Feedback zu geben. Ein Teil dieser Arbeit besteht darin, ihnen zu erlauben, Sie wissen zu lassen, was ihre Probleme sind. Sie werden überrascht sein, wie oft es einen anderen Grund für mangelnde Detailgenauigkeit gibt, und Sie sollten versuchen, diesen herauszukitzeln, um sicherzustellen, dass Ihr Team effektiver ist.

Die erste Frage, die ich an Sie habe, ist, welche Benchmark verwenden Sie, um den „Durchschnitt“ festzulegen. Sie sagen: „Die meisten sind unterdurchschnittlich.“ Ich würde wetten, dass die Leistung Ihrer meisten Ihr Durchschnitt ist. Ich würde weiter wetten, dass Ihre Arbeiterpopulation gut in die Standardleistungskurve passt, was bedeutet, dass Ihr MODUS = Median = Mittelwert ist. Ich gehe hier nicht darauf ein, um Ihnen Statistiken beizubringen, sondern um Sie dazu zu bringen, Ihre Erwartungen und den Stock, an dem Sie Ihre Leistung messen, noch einmal zu überprüfen. Das ist absolut kritisch! Denn wenn Sie an einem falschen Stock messen, werden Sie Ihr Team niemals dazu bringen, sich zu verbessern. in der Tat können Sie nachteilige Folgen haben.

Hier ist der Deal, die Leistungskurve und die Wahrscheinlichkeitsverteilung besagen, dass Sie höchstwahrscheinlich ein durchschnittliches Team mit durchschnittlichen Einzelleistungen haben. Ab und zu hat man Glück, aber auch Pech und einen Blindgänger. Aber Sie sollten bei der Planung von einer durchschnittlichen Leistung Ihrer menschlichen Leistungsträger ausgehen. Eine Planung, die etwas anderes annimmt, wird wahrscheinlich zu einem zu optimistischen, unerreichbaren Plan führen und ist nicht viel mehr als Wunschdenken.

Und da Sie sie nicht auswählen können, müssen Sie das Leistungsniveau akzeptieren, das Sie erhalten, und interne Qualitätskontrollen aufbauen, um Fehler zu kontrollieren und die Leistung im Laufe der Zeit schrittweise zu verbessern. Eine Menge Geld in den Versuch zu stecken, in dieser Dynamik etwas zu ändern, ist eine Verschwendung. Jeder Blip, den Sie vielleicht sehen, kann nichts anderes als stochastisch sein, mit einem Rückkehr-Blip zurück zum Mittelwert (Regression zum Mittelwert).

Die drei wichtigsten Treiber für Leistung sind Zweck, Autonomie und Beherrschung. Stellen Sie sicher, dass Sie verstehen, was diese sind, und beginnen Sie mit dem Aufbau einer Kultur, die sie ermöglicht. Wenn Sie einen besonderen Grund für eine geringere Leistung haben, kann dies hilfreich sein. (Ihr Team dazu zu bringen, ein Buch zu lesen, ist übrigens kein Wegbereiter für einen dieser drei Punkte.)

Ich denke, das Wichtigste ist, die Frage zu beantworten, warum man Entwickler besser machen muss. Ist es, weil Sie wollen, dass die Entwicklung besser und effizienter realisiert wird, oder wollen Sie bessere Entwickler haben, die nebenbei besser entwickeln? Wenn nur einer, dann gibt es zwei Möglichkeiten, dies zu erreichen: a. Verbesserung der Leistung des Teams – was meiner Meinung nach eine einfachere Aufgabe ist – viele Methoden – nehmen wir SCRUM als Beispiel, könnte in diesem Fall helfen b. Die Leistung von Einzelpersonen verbessern - was Sie anscheinend tun möchten und was meiner Meinung nach viel schwieriger ist

Nehmen wir an, Sie wollen b erreichen.

Meiner Meinung nach sollten Sie damit beginnen, zu versichern, dass die Entwickler selbst das Bedürfnis haben, ihre eigene Arbeitsweise zu verbessern, wenn sie das sehen, dann ist Ihre Arbeit viel einfacher, wenn nicht, müssen Sie sie ändern. Es ist sehr schwer, einen Weg vorzuschlagen, sie zu motivieren, wahrscheinlich wird jedes Teammitglied durch einen anderen Faktor motiviert. Sicherlich bin ich nicht davon überzeugt, dass sie motiviert sind, weil sie mehr als fair bezahlt werden, in vielen Situationen ist Geld nicht alles, oft ist es Verantwortung, Selbstverwirklichung, die Dinge im Griff haben, konkrete und klare Zukunftsvisionen und so weiter ..

Wenn Menschen motiviert sind, sich zu verbessern, haben Sie mehr als die Hälfte der Arbeit erledigt. Dann sollten viele Techniken, die in anderen Antworten erwähnt werden, ganz gut funktionieren. Aus meiner Sicht sind die beiden wichtigsten: a) Häufiges Feedback – das kommt von Peer-Reviews, Anwendungsdemos, retrospektiven Treffen oder anderen Treffen/Diskussionen, bei denen es darum geht, was in Zukunft passiert und wie wir es verbessern können. b) Delegation von Verantwortung – anfangs könnten Sie der Hauptfeedbackgeber sein, aber es sollte sich ziemlich schnell ändern und das Team selbst sollte sich um Selbstverbesserung organisieren. c) Slack - Lernen ist ein schmerzhafter Prozess, und während dieser Zeit müssen viele Fehler gemacht werden. Sie müssen geduldig sein und Sie sollten nicht gleichzeitig hohe Leistung und Lernen verlangen, Leerlaufzeit ist notwendig.

Mir ist klar, dass Sie keine Einstellungs-/Entlassungsvollmacht haben, aber manchmal müssen die wirklich Schlechten entlassen werden.

Schauen Sie sich die ähnliche Frage an: Umgang mit ungelernten / unmotivierten Teammitgliedern

Es gibt kein Patentrezept für die Softwareentwicklung.

Haben Sie sich auf das Team konzentriert, um ein leistungsstarkes Team aufzubauen?

Einige der Teambuilding-Übungen, die ich erfolgreich eingesetzt habe, sind:

1. Lyssa Adkins (Coaching Agile Teams) hat eine großartige Teambuilding-Übung – einen Hochleistungsbaum.

   o Verwendet die Scrum-Werte: Engagement, Mut, Fokus, Offenheit (Transparenz) & Respekt für Teambuilding.

   o Team identifiziert Merkmale eines Hochleistungsteams.

2. Ermöglichen Sie retrospektive Meetings zur kontinuierlichen Verbesserung.

   o Was läuft gut?

   o Was muss verbessert werden?

   o Lassen Sie das Team sich verpflichten, 2-3 Verbesserungen umzusetzen.

3. Verwenden Sie ein „WaterCooler“-Meeting, um das Team in lockerer Sitzung aufzubauen.

   o Zwangloses Treffen zum Spielen.

4. Verwenden Sie Persona für Teammitglieder.

   o Hilft den Leuten, die Teammitglieder kennenzulernen.

Für verteilte Teams nutze ich die Online-Tools Conteneo & Trello für Meetings.

Beispiel eines Hochleistungsbaums:

Das Wichtigste zuerst, entscheiden Sie sich für eine Methodik - viele der von Ihnen erwähnten sind gegensätzlich und würden nicht gut zusammenpassen. TDD, Agile, SCRUM - wählen Sie eine aus (TDD kann hier helfen, aber es kann eine Änderung der Denkweise sein) :D

Als nächstes scheint QA Ihr eigentliches Problem zu sein. Dies bedeutet, dass Sie einige grundlegende Prozessänderungen einführen müssen. Schauen Sie sich altmodische Code-Komplettlösungen an - implementieren Sie einen regelbasierten "Cop", um Code zu standardisieren (viele "Cop" gibt es heutzutage - und VS hat ihn eingebaut). Wenn Sie VS verwenden, implementieren Sie auch einen Testprozess im Build (Testfälle können in der Codierungsphase erstellt und im laufenden Betrieb getestet werden – einige Erweiterungen prüfen sogar, während der Code verschlüsselt wird!). Stellen Sie sicher, dass Testfälle von einer anderen Person als dem Programmierer geschrieben werden, vorzugsweise von einem Sys-An/Prog und mit etwas Erfahrung (ein guter Entwicklerleiter wird dabei helfen - wenn Sie keinen Entwicklerleiter haben, denken Sie darüber nach, einen zu erstellen, selbst wenn es ist eine Position ohne Gehaltserhöhung innerhalb der Reihen), erhalten Sie, wenn möglich, mehr Benutzerbeteiligung, um die Dinge auf einem ausgeglichenen Kurs zu halten. Geben Sie dem Dev Lead die Verantwortung, sicherzustellen, dass die Sicherheitsanforderungen erfüllt sind und Testskripts erstellt wurden – lassen Sie ihn direkt mit dem System-/Bus-Analysten zusammenarbeiten und den/die Programmierer betreuen. Lassen Sie Benutzer Entwürfe/Testskripte signieren und „bezahlen“ Sie für jeden Scope Creep. Lassen Sie die QA innerhalb des Teams durchführen und von Ihnen abmelden, damit der QA-Analyst, der Tester und der Programmierer alle wissen, dass sie (ziemlich) überwacht werden - es macht auch Fehlerbehebungen billiger, da sie früher im Entwicklungszyklus abgefangen werden.

Programmierer werden durch Erfahrung und durch das Erlernen bewährter Verfahren (durch Mentoring und Osmose) besser – wenn das Team niemanden dieses Kalibers hat, müssen Sie vielleicht auf die Einstellung einer leitenden Position als Entwickler drängen (oder vielleicht eine aus einem anderen Projekt ausleihen). ), um genau das zu tun - der PM kann pushen, aber es braucht einen anderen Programmierer, um zu zeigen, wie es gemacht werden sollte.