Wie man dem Management demonstriert, dass mittelmäßige Entwickler das Team verletzen [geschlossen]

Ich bin in der prekären Lage, ein Entwicklerteam in einem kleinen Unternehmen zu "leiten". Ich sage "managen", weil ich, obwohl ich Arbeit zuordne und Feedback zu ihrer Leistung gebe, keine Möglichkeit habe, eine Person tatsächlich zu disziplinieren.

Einige meiner Teammitglieder, mit denen ich nicht umgehen kann, sind nicht in der Lage, selbstständig zu arbeiten, erfordern massives Händchenhalten und verursachen im Allgemeinen Chaos bis hin zum Scheitern des Projekts. Wenn ein Fehler auftritt, muss ich das Projekt retten und es (manchmal hinkend) über die Ziellinie schieben.

Diesen Entwicklern fehlen nicht nur Kenntnisse in Programmierkonzepten, sondern im Allgemeinen auch die Fähigkeit, eine Lösung für ein Problem im Code zu formulieren. Einfache Dinge wie das Schreiben von Schleifen sind für sie schwierig, geschweige denn das Entwerfen und Implementieren einer Lösung für ein Problem.

Wir haben versucht, Paare zu programmieren, Unterricht anzubieten, Bücher zu kaufen, während des Arbeitstages Zeit für das Training bereitzustellen und sogar ganze Tage für die Schulung des Teams zu benötigen.

Der andere leitende Entwickler und ich wissen nicht, was wir tun sollen, aber unsere Produktivität wird dadurch gedrosselt, dass wir uns täglich mit diesen Personen befassen müssen. Das Management zwingt uns, ihnen Arbeit zu geben, und ihre Hauptbeschwerde ist, dass die Dinge nicht schnell genug erledigt werden.

Keines unserer Managementteams arbeitet direkt mit einem anderen Entwickler als mir und dem anderen leitenden Entwickler zusammen. Das Management ist nicht technisch und glaubt, dass jeder Entwickler gleichermaßen erstellt wird und dass wir offensichtlich mehr Mitarbeiter für diese Projekte benötigen, um sie schneller erledigen zu können.

Ich bereite bereits ein Dokument mit Abschnitten aus "The Mythical Man Month" und "Code Complete" vor, das an das Management gesendet werden soll, um hoffentlich anhand von Statistiken zu veranschaulichen, dass das, was uns wirklich behindert, darin besteht, die mittelmäßigen Leute durch den Entwicklungszyklus zu ziehen.

Welche anderen Ressourcen gibt es da draußen? Bücher, Artikel, allgemeine Ratschläge alles wäre hilfreich.

Ist das Problem auf mangelnde Fähigkeiten oder Fertigkeiten, Einstellungsprobleme der Programmierer oder auf eine Unternehmenskultur zurückzuführen, die keine gute Arbeitsmoral fördert?

Wenn es um Fähigkeiten geht, wissen Sie bereits, dass es einige Dinge gibt, die Sie nicht unterrichten können. Wenn das Unternehmen bereit ist (und es scheint, dass dies der Fall ist) und Sie Verbesserungen zeigen können, würde ich die Schulung intensivieren und sehen, welche Entwickler sich dem Anlass stellen. Diejenigen, die Sie nicht tun, müssen loslassen. Ich würde keine zusätzlichen Entwickler einstellen, bis Sie wissen, dass Sie einige Ihrer vorhandenen loslassen werden.

Wenn es sich um Faulheit oder andere Einstellungsprobleme der Programmierer handelt, müssen Sie Ihr Management davon überzeugen, Sie bei Disziplinarmaßnahmen zu unterstützen. Dokumentieren Sie alle Probleme, wie Scott Vercuski beschreibt. Entfernen Sie nach und nach die Programmierer, die sich dem Anlass nicht stellen können. Lassen Sie die verbleibenden Programmierer wissen, dass von ihnen erwartet wird, dass sie gute Programmiertechniken und Best Practices erlernen, und verwenden Sie diese.

Haben Sie Codeüberprüfungen, wenn Sie das noch nicht tun. Es gibt viele Ressourcen, die erklären, wie dies richtig gemacht wird. Sie sollten keine Matches schreien, sondern als Strategiesitzungen betrachtet werden, um die gewünschten Ergebnisse zu erzielen. Besprechen Sie den Code. Wie kann es verbessert werden? Schreiben Sie gegebenenfalls neuen Code in die Überprüfung.

Wenn das Management das Problem ist, sagen Sie ihnen, dass sie das Problem sind, und zeigen Sie ihnen, wie sie es beheben können. Aber Sie müssen eloquent und überzeugend sein. Sie müssen ihr Anwalt sein. Schreiben Sie ein Papier über das Problem. Machen Sie eine Präsentation und zeigen Sie es. Appell an Gewinnmotive.

Schließlich sei der beste Führer für dein Volk, der du sein kannst. Hilf ihnen. Lassen Sie sie frei, damit sie ihre Arbeit erledigen können. Ein Teil Ihrer Arbeit besteht darin, Ihre Mitarbeiter vor der Politik des oberen Managements zu schützen und ein menschenwürdiges Arbeitsumfeld aufrechtzuerhalten, damit sie sich darauf konzentrieren können, die bestmögliche Arbeit zu leisten. Mit anderen Worten, stellen Sie sicher, dass Ihre Mitarbeiter Ihnen vertrauen können.

Komisch, niemand hat dir gesagt, dass dir vielleicht die Managementfähigkeiten fehlen.

Einmal habe ich mit Leuten gearbeitet, die nach anderthalb Jahren Training keine Schleife mehr codieren konnten. Ich habe sie geschult, bis sie ein voll funktionsfähiges Webframework verwenden konnten, und es dauerte nur einen Monat.

Vielleicht solltest du ein Training bekommen.

Vielleicht solltest du einen Bericht über dich lesen .

Ich sage das nicht, um dich anzugreifen. Überhaupt nicht. Ich verstehe das Problem sehr gut, da ich in der Vergangenheit auch keine Teams geführt habe.

Aber weiche dem Ball nicht aus, du bist hauptsächlich dafür verantwortlich, was in deinem Team passiert, egal wie viel Literatur über gute Praktiken du in deinem Leben gelesen hast.

In diesem Fall hören Sie auf, sich zu beschweren, und machen Sie sich an die Arbeit. Nicht als Programmierer, sondern als Manager.

Schließlich kann ich mich irren. Vielleicht hast du alles richtig gemacht. In diesem Fall können und sollten Sie zurücktreten. Der Versuch, zu verhindern, dass ein Flugzeug beim Bewegen der Hände abstürzt, ist nutzlos, egal wie stark Sie sind. Es gibt viele Gelegenheitsteams, die mit Ihren Fähigkeiten Wunder vollbringen, um das Beste aus ihren herauszuholen.

Dokumentation ist Ihre größte Ressource ... ein alter Manager von mir sagte mir: "Wenn Sie sie nicht aufschreiben, ist es nicht passiert." Wenn Ihre Entwickler Ihnen eine schriftliche Schätzung der für die Erledigung einer Aufgabe erforderlichen Zeit geben und diese Fristen ständig (und schwerwiegend) verpassen, sollte dies dokumentiert werden.

Haben Sie eine Art Zeitnehmungssystem? oder protokollieren die Entwickler ihre Zeit? Wenn sie angeben, dass ein Problem X Tage dauert und nach X Tagen nicht erledigt ist, können Sie sich fragen, warum es nicht erledigt wurde.

Um es noch einmal zu wiederholen ... Dokumentation ist der Schlüssel, wenn Sie plötzlich jemanden kündigen und keine ausreichende Dokumentation darüber haben, warum Sie in das Gebiet der Klage gelangen können. Je mehr Dokumentation Sie haben, desto klarer sollte es für das Management sein, dass die Junior-Entwickler nicht ihr Gewicht verlieren und ersetzt werden sollten.

Ich wünsche Ihnen viel Glück, ich fürchte, Sie befinden sich auf einem sehr holprigen Weg ... Ich war dort und es ist ein langwieriger Prozess.

Ich war schon einmal in dieser Situation und kann mich durchaus einfühlen. Was ich getan habe, war, eine kleine, in sich geschlossene Aufgabe zu erledigen, die mich oder einen anderen älteren Entwickler nicht länger als zwei Tage oder so brauchen sollte. Für diese Aufgabe würde ich eine Vielzahl von Dokumentationen erstellen, in denen angegeben wird, wie die Lösung implementiert werden soll, welche Datenbankänderungen vorgenommen werden sollen usw. Dann würde ich mich mit dem Entwickler zusammensetzen, ihm eine allgemeine Anleitung für die Aufgabe geben und sie ihnen zuweisen mit einer Frist von 1 Woche. Am Ende der Woche haben Sie etwas Greifbares, mit dem Sie ihre Arbeit vergleichen können: Haben sie die Spezifikationen erfüllt? Wie fertig sind sie? Wie viele Fehler hat QA gefunden? Haben sie den Build- oder Break-Prozess in irgendeiner Weise unterbrochen?

Sobald dies erledigt ist, haben Sie ein direktes und zielgerichtetes Treffen mit ihnen, in dem erklärt wird, dass sie ihre Pflichten nicht erfüllen. Machen Sie die gleichen Dinge noch ein oder zwei Mal und solange Sie die Kette dokumentieren und kommunizieren, sollten Sie in der Lage sein, sie herauszuschieben. Es mag hart sein, aber es hört sich so an, als ob Sie Leute brauchen, die sich verstärken, und Sie haben einfach nicht die richtigen Leute, um es zu tun.

Stellen Sie außerdem sicher, dass Sie an der Befragung neuer Kandidaten teilnehmen können.

Mein Rat lautet:

Wenn Sie ein Manager sind, müssen Sie die Rechte haben, die mit Ihrer Verantwortung verbunden sind. Diese Rechte umfassen die Disziplin der unter Ihnen stehenden Personen. Wenn sich das obere Management weigert, Ihnen diese Rechte zu gewähren, lehnen Sie es ab, diese Verantwortung zu übernehmen.

Sie müssen Ihren Vorgesetzten gegenüber nicht unbedingt so streng sein, aber das ist die Essenz dessen, was passieren muss.

Mein Rat wäre, einen Bug-Tracker zu implementieren und Aufgaben zuzuweisen. Dies zeigt die Produktivität eines jeden im Team. Wenn wir es zum ersten Mal verwenden, können wir das Team organisieren und die Zeit messen, die wir mit der Arbeit an Aufgaben verbringen. Eines der Dinge, die mir gefallen haben, war die Tatsache, dass jemand, der eine Aufgabe zugewiesen hat, eine E-Mail an den Mitarbeiter und eine Kopie an eine andere Person gesendet hat, um die Aufgabe zu überprüfen.

Übrigens haben wir BugTracker.Net verwendet .

Ich frage mich, wie diese Leute überhaupt in das Unternehmen gekommen sind:

Diesen Entwicklern fehlen nicht nur Kenntnisse in Programmierkonzepten, sondern im Allgemeinen auch die Fähigkeit, eine Lösung für ein Problem im Code zu formulieren.

Einfache Dinge wie das Schreiben von Schleifen sind für sie schwierig ...

Ihr Unternehmen muss zweifellos mehr Zeit und Mühe in die Rekrutierung von Arbeitskräften investieren, wie das alte Sprichwort sagt: Eile macht Verschwendung.

Wenn Sie sich in dieser von Ihnen beschriebenen Situation befinden, beenden Sie Ihren Bericht (wie andere angedeutet haben), machen Sie ihn kurz und unterstreichen Sie, wie viel Geld dies das Unternehmen kostet, reichen Sie ihn ein und warten Sie auf das Beste (wie Sie sagten, Sie haben "keine" Rückgriff auf die tatsächliche Disziplinierung eines Individuums. ").

Ich habe dies vor einiger Zeit gelesen, um Programmierer zu ermutigen, die Besten sein zu wollen.

Nerd Herding

Sie haben erwähnt, dass Sie für Ihr Team "Feedback zur Leistung geben".

So:

1. Setzen Sie sich mit Ihrem Team.
2. Geben Sie ihnen Ausdrucke dieser Seite und teilen Sie ihnen mit, dass Sie sie über sie gepostet haben.
3. Lass sie es lesen.
4. Bitten Sie sie, Ihnen bei der Lösung des Problems zu helfen.
5. Hören Sie zu und schreiben Sie es auf.
6. Bringen Sie das zu Ihrem Management-Team.

Peopleware ist ein weiteres Buch, das in Ihre Liste aufgenommen werden sollte.

Als ich es las, fand ich es jedoch nicht praktisch, weil niemand im Unternehmen seine Empfehlungen ausprobieren wollte.

Klingt so, als wären Sie auf dem richtigen Weg.

Wenn Sie ihnen harte Zahlen zeigen, werden sie die Dinge klarer sehen - erstellen Sie eine Codierung für eine Zuweisung und geben Sie sie an mehrere verschiedene Programmierer weiter, um an jeder Arbeit für sich zu arbeiten. Machen Sie es selbst testbar.

Behalten Sie Details darüber bei, wie lange jeder einzelne dauert und wie viele Fehler der Code verursacht.

Zeigen Sie die Zahlen dem oberen Management, sie sollten jetzt überzeugt sein.

Das Buch

Code Complete: Ein praktisches Handbuch zur Softwarekonstruktion von Steve McConnell

ist eine gute Quelle, die helfen kann, Best Practices zu erlernen.

Es könnte ein wenig helfen, wenn jeder Entwickler dies in Diskussionen lesen und lernen muss, aber das Wichtigste ist, die Ergebnisse zu quantifizieren. Nehmen Sie die Gehälter von sich selbst und dem Rest des Teams und berechnen Sie dann, wie viel zusätzliche Zeit Sie aufwenden müssen, um andere Fehler zu beheben, und die zusätzlichen Kosten für die Entwickler, die die Dinge zunächst durcheinander bringen.

Zeigen Sie dann, wie ein Team besserer Entwickler den ROI verbessern kann.

Halten Sie den Bericht kurz. Mach es nicht wortreich. Sagen wir, wie viel Geld sie dafür verlieren.

Wir haben jetzt ein Tool, das die Komplexität unserer Codemodule misst. Es läuft auf unseren PL / SQL-Modulen, aber ich glaube, dass es in anderen Umgebungen Tools gibt.

Es gibt verschiedene Abschnitte, aber es war ein ziemlicher Augenöffner für das Management, als einige unserer Schlüsselmodule als "nicht testbar" markiert wurden.

Wir haben ein Tool zur Analyse von Imakten kombiniert, mit dessen Hilfe doppelte Funktionen hervorgehoben werden können, und haben dies alles als Bewertung der „technischen Verschuldung“ zusammengefasst.

Da wir dies Modul für Modul präsentieren konnten, wäre es einfach gewesen, die Täter zu identifizieren (wir haben es getan, aber nicht gemeldet). So wie es war, war die Organisation mehr auf Verbesserungen ausgerichtet als auf das Zeigen mit dem Finger.

(Abgesehen davon wird jetzt der gesamte Code zur Überprüfung eingereicht, und eine begleitende Code-Analyse muss bereitgestellt werden. Hier wird es definitiv besser.)

Dies ist nur möglich, wenn Sie eine gute Traktion mit dem Management haben. Wenn Sie versuchen, es zu erzwingen, könnten Sie meiner Erfahrung nach in Schwierigkeiten geraten.

Nur eine Idee.

Ich gehe davon aus, dass Sie die Versionskontrollsysteme wie SVN verwenden. Machen Sie also die Politik, Commits zu überprüfen und schlechte abzulehnen. Zeigen Sie dann einfach den anderen Managern Statistiken über abgelehnte Commits, um zu beweisen, dass mittelmäßige Entwickler für das Unternehmen sehr teuer sind.

Hier ist eine weitere Idee für Sie: Reparieren Sie nicht, was sie brechen. Senden Sie es zur Überarbeitung in einer E-Mail zurück, indem Sie ihnen mitteilen, was falsch ist und wie (nur allgemein) das CC-Management behoben werden kann. Stellen Sie sicher, dass Sie für das Management genau wissen, wie sich dies auf Ihre endgültige Frist auswirkt. Dadurch wird die Dokumentation von Leistungsproblemen für Sie erstellt, und einige von ihnen sind möglicherweise nicht mehr so ​​schlecht, wenn sie ihre eigenen Probleme beheben müssen.