PMs erlauben, Entwickler zu bewerten/bewerten

Erstens ist jede Bewertung, egal von wem, irgendwann willkürlich. Wenn jemand damit nicht einverstanden ist, sollte er sich einen Ort suchen, an dem es überhaupt keine Bewertungen gibt.

Zweitens sollte für jemanden, der nach Feedback sucht, mehr Feedback immer besser sein als weniger Feedback. Ich meine, selbst wenn ich jemandes Meinung nicht vollständig zustimme, kann es immer noch sehr wertvoll sein, weil es zeigt, wie andere meine Arbeit sehen und was ich tun kann, um ihre Ansichten zu ändern.

Aus dieser Perspektive ist es gut, einen Weg zu finden, Feedback von so ziemlich jedem, der irgendwie mit der Arbeit von Entwicklern zu tun hat, in ihre Bewertung einzubeziehen. Und PM ist definitiv eine Person, deren Arbeit mit Entwicklung "irgendwie zusammenhängt".

Apropos, PM hat eine ziemlich andere Perspektive auf ein Projekt, daher wird ihr Feedback noch wertvoller sein. Wenn wir das Feedback nur innerhalb einer Funktionsgruppe halten, hier: Entwickler und Funktionsmanager der Entwickler, erhalten wir eine ziemlich homogene Sicht auf ein Projekt. Das Einbringen einer anderen Sichtweise, insbesondere von jemandem, der enger mit einem Kunden zusammenarbeitet, würde definitiv dazu beitragen, es besser zu machen.

Hinweis: In meiner Antwort konzentriere ich mich auf Feedback im Allgemeinen und nicht auf eine bestimmte Note, Bewertung, Note oder wie auch immer Sie es nennen.

Denn bei der Beurteilung von Personen ist jedes Bewertungssystem standardmäßig heikel.

Mein Rat wäre, Feedback von PMs einzubeziehen, aber jede direkte Bewertung von Entwicklern zu vermeiden. Wenn funktionale Manager gegenüber ihren Mitarbeitern nicht nur defensiv sind, sollten sie in der Lage sein, den Mitarbeitern dieses Feedback auf wertvolle Weise zu übermitteln. Ein solcher Ansatz erfordert jedoch Vertrauen zwischen so ziemlich allen: PM, einem Manager und einem Teammitglied. PM vertraut darauf, dass ihr Feedback einen Entwickler erreicht. Ein Manager vertraut darauf, dass er ehrliches, direktes und möglicherweise faktenbasiertes Feedback erhält. Ein Entwickler vertraut darauf, dass niemand versucht, sie herunterzufahren usw.

Abhängig von den Standards Ihrer Organisation kann es eine Standardmethode sein, mit der Personen auf einer Skala bewertet werden, und wenn dies der Fall ist, sage ich nicht, dass Sie dies um jeden Preis vermeiden sollten. Denken Sie daran, dass das Feedback von PM nur ein Teil der gesamten Beurteilung der eigenen Arbeit ist.

Wenn Personen (hier: PMs) nie Feedback an andere Teammitglieder abgegeben haben, kann das Bewertungssystem eine gute Möglichkeit sein, die Art und Weise zu standardisieren, wie sie ihr Feedback erstellen.

Vermeiden Sie andererseits bitte alle automatischen Maßnahmen, wie eine Reihe von Fehlern, Codezeilen usw. Dies hat nichts mit Feedback zu tun und treibt die gemessenen Zahlen nur nach unten oder oben (je nach Ziel) ohne direkten Einfluss auf die Qualität , wenn Sie z. B. eine Anzahl von gemeldeten Fehlern messen , können Sie ziemlich sicher sein, dass die Leute aufhören werden , Fehler zu melden; es sagt nicht viel über die Qualität eines Projekts aus und trübt sogar Ihre Sichtbarkeit noch mehr.

Fehler:

Beim Programmieren geht es im Allgemeinen darum, viele vage oder abstrakte Konzepte zu nehmen und sie dann zusammenzufügen, um etwas Großartiges zu schaffen. Entwickler nach der Anzahl der Fehler im Code zu beurteilen, ist vielleicht eine der schlimmsten Möglichkeiten, wie sich ein Unternehmen selbst ins Knie schießen kann.

In einer Welt, in der alles so agil ist, gibt es keine Blaupause, der man folgen könnte. Wir bauen keine Häuser – die reinste mögliche Form eines Wasserfallmodells – wo wir wissen, dass jeder Bolzen 16 Zoll voneinander entfernt sein muss, denn so haben wir die letzten 15 Häuser gebaut. Jedes Softwareprojekt unterscheidet sich in signifikanter Weise grundlegend von anderen Softwareprojekten.

Daher sind Fehler nur eine Tatsache des Lebens. Jede Software wird Fehler haben, weil Entwickler oft Dinge miteinander verbinden, die noch nie zuvor miteinander verbunden wurden. Begründen Sie die Leistung nicht auf Fehlern, es sei denn, Ihr Ziel ist es, Ihr Team zu demoralisieren und niederzuschlagen.

Geschwindigkeit der Codierung:

Einige Entwickler können sehr schnell codieren, aber dann 6 bis 12 Monate später; Plötzlich kommt der Fortschritt aufgrund all der Abkürzungen und Fehlentscheidungen im Code zum Erliegen. Programmierer sind keine Schreibkräfte. Sie messen den Erfolg nicht daran, wie schnell sie Code in ihren Editor speien können.

Andere Entwickler sind methodisch, geduldig und detailorientiert. Sie nehmen sich die Zeit, darüber nachzudenken, welcher Ansatz den Erfolg des Produkts sicherstellt. Ihre Entscheidungen stellen sicher, dass das Produkt auch noch in Jahren unterstützt werden kann. Sie stellen sicher, dass bei einer Änderung eines Teils des Systems kein Dominoeffekt entsteht, der durch die gesamte Codebasis nachhallt und alles andere ausschaltet. Ihr Code ist gut kommentiert, lesbar, konstruiert und einfach zu warten.

Ich verstehe, warum wir als Projektmanager dies messen wollen, aber wir müssen verstehen, dass dies ein sehr heikles, möglicherweise unermessliches Gleichgewicht ist, und es erfordert gutes Urteilsvermögen und die Entscheidungsfindung der technischen Mitarbeiter des Projekts.

Entwickler werden im Allgemeinen nach Gehalt bezahlt, weil ihre Arbeit die Fähigkeit beinhaltet, Entscheidungen zu treffen und Urteile zu fällen, und nicht kleine runde Dinger auf einer Mindestlohn-Produktionslinie zu produzieren.

Einhaltung der Anforderungen:

Softwareentwicklung ist ein kreativer Prozess. Es ist auch ein Engineering-Prozess. Der Engineering-Prozess kommt ins Spiel, wenn der Entwickler sicherstellen muss, dass er oder sie versteht, was gebaut werden soll. Mithilfe von Logik, guter Dokumentation, manchmal formalen Methoden und Planung sollte ein Entwickler in der Lage sein, sich ein klares Bild davon zu machen, was er bauen muss.

Der kreative Teil kommt mit der eigentlichen Lösung der Probleme ins Spiel, die sich letztendlich im Entwicklungsprozess ergeben. Dies kommt manchmal auch in anderen Bereichen vor, beispielsweise im Bauwesen. Vielleicht gibt es einen Grund, warum die letzten beiden Stollen nicht 16 Zoll voneinander entfernt sein können, also muss etwas Kreativität aufgewendet werden, um eine sichere und nachhaltige Lösung zu finden. Bei Software stoßen Entwickler manchmal auf Wände, und er/sie muss einen Weg um diese Wand herum finden, indem er oder sie die Dinge, die er oder sie über verschiedene Programmierkonzepte weiß, nimmt und sie dann alle zusammenführt, um eine großartige Lösung zu finden.

Nun, der Kreativitätsteil der Softwareentwicklung bedeutet nicht, dass der Entwickler alles bauen sollte, was er oder sie bauen möchte; Stattdessen muss sich der Entwickler weiterhin an die Anforderungen halten. Der kreative Teil liegt im Ansatz zur Lösung des Problems, nicht im eigentlichen Problem selbst.

Trotzdem haben Ingenieure manchmal kreative Ideen, die das Produkt verbessern können. Ob diese Elemente jedoch implementiert werden oder nicht, hängt ausschließlich davon ab, für wen das Produkt bestimmt ist. In einem Startup hat der Ingenieur wahrscheinlich viel Freiheit, um innovativ zu sein und etwas zu schaffen, das die Menschen mit Leidenschaft erfüllt. Auf der anderen Seite besteht das Ziel in einem großen Unternehmen, das kundenspezifische Software für einen Kunden entwickelt, darin, das zu liefern, was der Kunde will, und das lässt möglicherweise wenig Raum für unaufgeforderte Änderungen.

Zusammenfassung

Zusammenfassend sind die ersten beiden Punkte Punkte, deren Messung einfach keinen Sinn macht. Bugs sind eine Tatsache des Lebens. Betrachten Sie sie einfach als unvollendete Funktionen oder als Teil des Verbesserungsprozesses. Die Geschwindigkeit der Codierung ist möglicherweise keine Funktion des Projekterfolgs, da die Codierung ein Konstruktionsprozess und kein Herstellungsprozess ist. Schließlich kann sich die Einhaltung der Anforderungen von Projekt zu Projekt ändern und ist in einigen Projekten möglicherweise nicht messbar oder wichtig.

Konzentrieren Sie sich stattdessen auf die Bewertung der Personen. Ist er leicht zu verstehen? Hilft sie, andere Teammitglieder zu motivieren? Hilft sie bei der Zusammenarbeit mit dem Team und generiert sie Ideen zur Problemlösung? Vertrauen Sie dieser Person, dass sie das liefert, was sie verspricht. Wenn Bugs gefunden werden, übernimmt er die Verantwortung und gräbt sich leidenschaftlich ein und behebt das unvollendete Feature (Bug).

Softwareentwicklung ist naturgemäß ein subjektiver Prozess, und Sie können keine objektiven Bewertungskriterien verwenden, um Positionen wie diese zu bewerten, ohne sich selbst, Ihr Team und Ihre Organisation zu untergraben.

Ich glaube nicht, dass es für die Beantwortung dieser Frage relevant ist, ein Entwickler zu sein. Wir leben in einer Welt, in der wir an unserer Leistung gemessen werden, unabhängig von der Aktivität oder Arbeit, die wir ausführen. Gemessen zu werden und mit unseren Kollegen verglichen zu werden, steht im Einklang mit dem Setzen und Erreichen von Zielen, einem gesunden Wettbewerb und dem Aussortieren derer, die nicht dazugehören. Wie man sich dabei fühlt, ist unerheblich.

Der Messstab, den Sie verwenden, sollte eine zerlegte Version des Stabs sein, der zur Messung der Leistung der Organisation verwendet wird.

Eine Metrik wird immer unbeabsichtigte Nebenwirkungen haben. In vielen Fällen sind diese Nebenwirkungen für die Organisation ohne Bedeutung. In anderen Fällen führt die von Ihnen gewählte Metrik zu einer Verhaltensänderung, die Sie nicht wollten. Also gehen Sie es klug an. Messen Sie nicht etwas, nur um zu sagen, dass Sie messen. Messen Sie es, weil Sie ein Ziel haben, das Sie erreichen müssen, und weil Sie ein Auge auf unerwünschte Verhaltensweisen haben, die es auch hervorrufen kann.

Projektmanager sollten sich auf die Verwaltung von Zeit und Ressourcen konzentrieren, um die Deadline einzuhalten. Ich denke, unabhängig von der Disziplin sollte ein PM in der Lage sein, zu bewerten, wie Teammitglieder an der Projektinitiierung beteiligt sind (haben sie teilgenommen), wie gut sie planen (hat sich ihr Mangel an Planung oder ihre mangelnde Planungsfähigkeit negativ auf den Zeitplan ausgewirkt). sie ausführen (entsprachen ihre Schätzungen ihrem tatsächlichen Output oder ihrer Burndown-Rate?) und wie gut sie überwachen und kontrollieren (korrekte Arbeit in ihrem Einflussbereich) und das Projekt ordnungsgemäß abgeschlossen haben (Lessons Learned verpflichten, endgültige vertragliche Leistungen einreichen, etc.).

Die Prämisse und Besonderheiten Ihrer Frage im Bereich der Softwareentwicklung (Anzahl der Fehler usw.) sind jedoch meiner Meinung nach falsch gedacht. PMs sollten sich auf die Disziplinbereiche konzentrieren, die sie kennen. Während ich denke, dass als Team Metriken definiert werden könnten, die den PM-Wissensbereichen entsprechen (z. B. klassische PMI-Wissensbereiche, die dem zugeordnet sind, was das Programmierteam für eine passende Metrik für diesen Bereich hält), würde ich es vermeiden, einen Programmierer oder ein Programmierteam zu beeinflussen und zu verwalten es sei denn, Sie waren Teammitglied und Teil des von der/den Messung(en) betroffenen Teams.

Sie sagen, Sie möchten "eine Art Bewertung anwenden", basierend auf:

1. Anzahl der Fehler
2. Geschwindigkeit des Codes
3. Einhaltung der Anforderungen

Nur der letzte davon hat einen subjektiven Anteil an der Messung, und selbst dann kann dies je nach Strenge und Granularität Ihrer Anforderungsverfolgung zur Debatte stehen.

Meine Frage ist also, warum dies etwas zum PM-Preis macht? warum nicht einfach automatisieren? Schlagen Sie die Anzahl der Fehler, die Leistungsmetriken der nächtlichen Tests usw. für den Code jedes Entwicklers nach und führen Sie einen laufenden Durchschnitt oder so.

Wenn Sie es zu einer automatisierten Metrik machen, riskieren Sie natürlich, dass die Entwickler das System spielen. Wenn Sie es zu einem rein subjektiven Maß der Meinung des Projektmanagers zum Entwicklercode machen, dann ist es ein ziemlich wertloses Maß, es sei denn, Ihre PMs sind alle auch Entwickler.

Ich bin ein Entwickler und würde es nicht gutheißen, wenn eine technisch nicht versierte Person meinen Code auf einer beliebigen Skala bewertet. Es fällt mir schwer, eine bessere Lösung anzubieten, ohne zu wissen, was Sie erreichen möchten oder ob es ein zugrunde liegendes Problem gibt, das Sie anzugehen versuchen.

Projektmanager sollten unbedingt einen Beitrag zu den Leistungsbeurteilungen der Mitarbeiter in ihren Teams leisten.