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

82

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.

löschen
quelle
20
An den Schließern: Komm schon! Halt dich fest!
Peter
6
Das Hinzufügen dieser Frage zu meinen Favoriten reicht nicht aus. Ich muss es als Hintergrundbild festlegen.
Manos Dilaverakis
5
Verdammt, ich sollte abstimmen, um zu schließen, aber ich mag die Frage :(
IAdapter
3
Eine sehr wichtige Sache, die Sie tun müssen , ist, das Management davon zu überzeugen, dass Sie und / oder Ihr leitender Entwickler mitbestimmen, wer eingestellt (und entlassen oder diszipliniert) wird. Wenn Sie für die Führung verantwortlich sein sollen, sollten Sie zumindest ein Mitspracherecht haben, ob sie überhaupt Teil Ihres Teams sind oder nicht.
Michael Todd
5
Gewählt zu nah, subjektiv und argumentativ. Sollte ein Community-Wiki sein, wenn die Leute nur entlüften wollen.
Joe

Antworten:

26

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.

Robert Harvey
quelle
Interessiert hier Robert. Haben Sie Links oder Ressourcen zu "So führen Sie keine Codeüberprüfung durch". Ich frage, weil ich glaube, dass ich in einer war, die neulich furchtbar schief gelaufen ist ... Ich hätte gerne eine externe Dokumentation, wenn ich (noch einmal) zum Management über diesen Senior Engineer gehe. (Ich ging sogar so weit, das Szenario von einem anderen Senior abzuprallen, unter dem ich einmal gearbeitet hatte, und er stimmte zu, dass die Antwort, die ich erhielt, "ein wenig anders schien".)
Jason D
@ Jason: Nicht sicher, was bei Ihrer Codeüberprüfung passiert ist, aber dieser Artikel könnte einen Einblick geben: it.toolbox.com/blogs/puramu/…
Robert Harvey
Nicht ganz das, was ich mir erhofft hatte, aber es hat auf andere grundlegende Mängel bei der Durchführung des Überprüfungsprozesses hingewiesen. (zB ohne die "erwachsene" / nicht unverfallbare Partei als diejenige, die die Überprüfung leitet ...) Ich werde diesen Link unter anderem verwenden, um Verbesserungen unseres Codeüberprüfungsprozesses mit dem Management zu besprechen und meine jüngsten persönlichen Erfahrungen als ein Beispiel, warum der unparteiische Vermittler da sein sollte ...
Jason D
32

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.

e-satis
quelle
6
Ich verstehe nicht, warum die Leute dich herabgestimmt haben. Sie sprechen den gültigen Punkt an, dass Leads / Manager, die sich aus normalen Ingenieuren entwickeln, fast nie selbst eine Schulung zum Umgang mit Menschen erhalten. Der alte Irrtum "Sie sind ein großartiger Ingenieur, Sie werden daher ein großartiger Manager sein".
Erich Mirabal
1
Nun, weil es politisch nicht korrekt ist, jemandem, der um Hilfe bittet, zu sagen, dass er vielleicht die Ursache seiner Situation ist. Ich muss sagen, das möchte ich selbst nicht sagen, aber es ist normalerweise ein nützlicher Elektroschock.
E-Satis
4
Vielen Dank, dass Sie darauf hingewiesen haben - und ich bekomme auch keine negativen Stimmen. Ich hatte noch nie eine Managementausbildung. Ich wurde ohne vorherige Erfahrung in diese (prekäre) Position gebracht. Ich gebe voll und ganz zu, dass ich teilweise schuld sein könnte. Ich habe (mehr als einmal) darum gebeten, einen tatsächlichen Entwicklungsmanager einzustellen, der über Erfahrung in der Leitung eines Entwicklerteams verfügt. Anfrage scheint auf taube Ohren gestoßen zu sein.
1
Ich habe auf manager-tools.com einige wirklich gute Management-Tipps gefunden. Sie haben Podcasts, die in nützliche Themen unterteilt sind. Vielleicht finden Sie dort etwas, das Ihnen hilft.
Paul Hildebrandt
@ Paul - danke dafür, ich werde es auf jeden Fall ausprobieren!
15

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.

user26901
quelle
Wir verwenden ein Zeiterfassungssystem und ein Fehlerverfolgungstool, aber ich habe keinen Zugriff darauf, die Zeit anderer Personen anzuzeigen. Ich werde auf jeden Fall anfangen, meine Erfahrungen sorgfältiger zu dokumentieren.
Wenn Sie genügend Unterlagen über ihre Schätzungen sammeln, können Sie diese Schätzungen Ihrem Manager geben und ihn bitten, einen Arbeitszeittabellenvergleich durchzuführen. Dies zeigt hoffentlich, dass der Entwickler X Tage geschätzt und X + Y Tage auf konsistenter Basis verbracht hat, wodurch Sie mehr Munition erhalten für Ihre Entscheidung.
2
Wenn Schätzungen das Problem sind, stellen Sie fest, dass gute Schätzungen Zeit brauchen. Um abzuschätzen, wie lange ein Codierungsproblem dauern wird, müssen Sie herausfinden, welche Codezeilen Sie ändern müssen, welche Klassen und Methoden Sie schreiben müssen usw. und natürlich müssen Sie berücksichtigen rechtzeitig zum Testen. Die gute Nachricht ist, dass Sie diese Dinge sowieso herausfinden müssen, damit Sie sich nicht wirklich mehr Zeit für die Schätzung nehmen.
Ryan Lundy
6

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.

Jacob G.
quelle
5

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.

Paul Nathan
quelle
2

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 .

Nelson Miranda
quelle
Wir haben einen Bug-Tracker und ein Zeiterfassungssystem, aber sie sind nicht integriert. Wir überlassen es auch dem einzelnen Entwickler, die für eine Aufgabe aufgewendete Zeit einzugeben. Möglicherweise muss ich prüfen, ob wir die Gesamtzeit zwischen der Fertigstellung der Zuweisung im Bug-Tracker und der geschätzten Zeit nachverfolgen können.
Ich würde dann denken, dass es ein ethisches Problem der Mitarbeiter ist, auf das Sie sich konzentrieren müssten.
Nelson Miranda
Klingt nach einem schönen Ort, um 8 Stunden am Tag zu verbringen ... NICHT! Seit wann sind wir Programmierer Fabrikarbeiter geworden! Wie hoch ist die Fluktuation in Ihrem Unternehmen und wie viel Geld verschwenden Sie, weil Sie der menschlichen Natur nicht gerecht werden können? Hat jemand, der dort arbeitet, einen hohen Blutdruck? Das einzige, was Sie verwalten können, ist ein Sweatshop. Niemand, der sein Salz wert ist, würde in dieser Umgebung arbeiten wollen. Ups, es ist Zeit für meine Kaffeepause. ;-)
Sam
2

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. ").

Peter Perháč
quelle
3
Entwicklungsmitarbeiter wurden nicht in den Einstellungsprozess einbezogen, so kamen sie ins
2

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

Nerd Herding

Andy Joiner
quelle
Erstaunlicher Artikel. Gute Verknüpfung +1
Smalltown2k
Gut gemacht, um die Chance zu erkennen, nicht das Hindernis.
Sam
1

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.
user271471
quelle
1

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.

aaaa bbbb
quelle
Das letzte Mal, als ich in dieser Situation war - ich habe aufgehört und bin woanders hingegangen. Es ist jetzt viel besser, mit einem anderen Entwicklerteam zusammenzuarbeiten, das tatsächlich die nötigen Voraussetzungen hat, um echte Entwicklung zu betreiben.
James
0

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.

Oded
quelle
0

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.

Todd Moses
quelle
OP gibt bereits an, dass er Code Complete verwendet. Irgendwelche anderen guten Bücher?
aaaa bbbb
0

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

Dean J.
quelle
0

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.)

James Wiseman
quelle
0

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.

fastcodejava
quelle
0

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.

Sergey
quelle
0

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.

HLGEM
quelle