Ziele für Entwickler festlegen müssen, obwohl Ziele nicht funktionieren [geschlossen]

Es ist allgemein anerkannt, dass das Setzen messbarer Ziele für Softwareentwickler nicht funktioniert , da eine zu starke Konzentration auf die Ziele zu einem Verhalten führen kann, das den organisatorischen Zielen widerspricht (sogenannte " Messdysfunktion ").

In meinem Unternehmen müssen wir jedoch Ziele für alle Mitarbeiter festlegen und werden von der Personalabteilung ermutigt, diese SMART zu machen . In der Vergangenheit haben meine Kollegen der ersten Ebene (Teamleiter) und ich verschiedene Ansätze ausprobiert:

1. Legen Sie messbare Ziele fest, die zusätzlich zum normalen Job gelten, z. B. "Schulung zu Technologie X durchführen", "Dokumentation für Code Y erstellen, den niemand versteht" usw. Wenn es um die jährliche Leistungsbewertung geht, bewerten Sie Entwickler nicht nach den schriftlichen Zielen, sondern nach meiner Meinung über den nicht messbaren Wert ihrer normalen Arbeit, denn genau darum kümmert sich das Unternehmen.
2. Legen Sie ganz bestimmte Ziele fest, z. B. "Vom Task-Management-System aufgezeichnete Arbeitstage", "Anzahl der eingeführten Fehler", "Anzahl der verursachten Produktionsausfälle". Dies führte zu überhöhten Schätzungen und einer falschen Klassifizierung von Fehlern, um bessere "Scores" zu erzielen. Interessanterweise gefiel es selbst den Entwicklern, die auf diesem System sehr gut abschnitten, nicht, da das Vertrauen in das Team beschädigt wurde und sie nicht immer das Gefühl hatten, ihre hohe Position verdient zu haben.
3. Setzen Sie vage Ziele, die Varianten von "Machen Sie Ihren normalen Job gut" sind. Wenn es um die jährliche Bewertung geht, spiegelt ihre Bewertung die Leistung gegenüber den Zielen wider, aber die Ziele selbst sind nicht messbar oder erreichbar, was verpönt ist.

Nichts davon ist ideal. Wenn Sie in einer ähnlichen Situation waren, in der Sie trotz der Beweise für ihre Wirksamkeit aussagekräftige, messbare Ziele für Softwareentwickler schaffen mussten, welcher Ansatz hat für Sie am besten funktioniert?

Verwandte Fragen, die ich gefunden habe und die nicht ganz den gleichen Punkt ansprechen:

• Was sind einige gute Leistungsziele für einen Softwareentwickler?
• Festlegen von Leistungszielen für Entwickler
• Was sind geeignete Leistungsindikatoren für Programmierer?
• Was ist eine faire Produktivitätsmessmethode für Programmierer?
• Ich brauche einige Karriereziele für das nächste Jahr

Update (18. November 2009): Es gibt 10 positive Stimmen für meine Frage, und die Antworten mit der höchsten Bewertung haben nur 4 positive Stimmen (einschließlich jeweils einer von mir). Ich denke, das sagt uns etwas: Vielleicht haben Joel und die anderen Recht und die kombinierte Weisheit des Stackoverflow kann keine überzeugenden, messbaren Ziele für Entwickler hervorbringen, die nicht gespielt werden könnten, ohne den wahren (nicht messbaren) Wert ihrer Entwickler nachteilig zu beeinflussen Arbeit. Danke, dass du es versucht hast!

Welcher Ansatz hat für Sie am besten funktioniert?

Nur ein Ziel: Bestehen Sie eine Code-Inspektion / Peer-Review mit mir als Reviewer, ohne dass ich Fehler finde oder andere Kritik habe. Deshalb habe ich Sie gebeten, etwas zu wiederholen.

Anmerkungen:

• Ich habe die Fähigkeit neuer Mitarbeiter, schnell fertig zu werden, nicht gemessen und sie nicht dazu ermutigt: Ich wollte, dass die Leute lernen, wie man gut fertig wird (denn wenn es nicht gut fertig ist, ist es auch nicht fertig)
• Die Leute haben in einer Codeüberprüfung gelernt, wonach ich gesucht habe: Es ist also eine Lernmöglichkeit und eine Qualitätskontrollmaßnahme und nicht nur ein Managementziel
• Meine Kommentare hätten zwei Kategorien:
  1. Dies ist ein Fehler: Sie müssen ihn beheben, bevor Sie einchecken
  2. Als Vorschlag hätte ich das und das getan
• Nach einer Weile würden meine Überprüfungen des Codes einer Person keine "Muss-Korrektur" -Elemente mehr finden (an diesem Punkt müsste ich ihre Arbeit nicht mehr überprüfen).

Persönlich versuche ich zwei Arten von Zielen zu setzen:

• Geschäftsorientierte Ziele (deshalb werden wir doch bezahlt). Zum Beispiel "Projekt X bis 1. Juni 2009 abschließen"). Diese Ziele werden häufig von mehreren Teammitgliedern geteilt (und sie sind sich dessen bewusst). Das Team kann das Ziel übertreffen, indem es das Projekt frühzeitig einbringt oder die erforderliche Funktionalität überschreitet. Einzelpersonen können das Ziel übertreffen, indem sie mehr Funktionen produzieren, weniger Fehler gegen sie haben oder andere Mitglieder des Teams coachen und unterstützen.

• Persönliche Wachstumsziele, z. B. Abschluss eines Projekts mit einer Technologie, die der Entwickler zu seinen Fähigkeiten hinzufügen möchte, um die Domäne des Benutzers besser zu verstehen, Führungserfahrung zu sammeln usw.

Ich halte es für wichtig, dass:

• Ziele sind SMART
• Die Ziele sind auf die Bedürfnisse des Unternehmens ausgerichtet
• Sie nehmen "normale Arbeit" in Ziele auf, tatsächlich sind dies die wichtigsten Ziele!
• Der Mitarbeiter hat die Möglichkeit, die von Ihnen festgelegten Ziele zu übertreffen

Schließlich würde ich mich von Software-Metriken als Zielen fernhalten - sie sind zu einfach zu spielen und geben Ihnen wahrscheinlich nicht das, was Sie brauchen. Ich würde nur eine Metrik verwenden, bei der ich jemanden in oder aus einem bestimmten Verhalten heraus coachen möchte.

Dies alles läuft auf die Tatsache hinaus, dass "First Level Management" und fast jedes Management seine Mitarbeiter nicht kennt. Anstatt Teil der täglichen Planung und Entwicklung zu sein, tauchen Dinge wie SMART auf. Wenn Manager mehr Zeit mit den Leuten verbringen würden, die die eigentliche Arbeit erledigen, wäre nichts davon erforderlich.

Persönlich arbeite ich lieber in einer agilen Umgebung, in der es offensichtlich ist , wer von den Entwicklern in Bezug auf Produktivität und Qualitätsbewusstsein arbeitet. Ein wirklich agiler Ansatz erfordert, dass nicht nur Entwickler, sondern auch Designer, Tester, Kunden und Produktmanager in den Prozess einbezogen werden. Dies führt natürlich zu besseren Einsichten aus Sicht der Manager.

Messbare Ziele, die ich bisher gesehen habe:

• Bestehen Sie eine Zertifikatsprüfung
• Erforschen Sie Technologie X und halten Sie eine Präsentation darüber
• Anzahl der festgeschriebenen Build-Breaking-Änderungen
• Anzahl der Wiki-Artikel zum internen Wissensmanagement

Wie wäre es, wenn Sie Ihre Entwickler direkt fragen, ob sie Ideen für die persönliche Entwicklung haben, die dann für Ziele verwendet werden könnten?

Entwickler Ziele setzen müssen, obwohl sie nicht funktionieren

Wenn Ihre Entwickler nicht arbeiten, sind einige Ziele vielleicht genau das, was sie brauchen, um ihnen einen Anreiz zu geben? ;-);

"Stellen Sie sicher, dass mindestens n% Ihres Codes durch einen geeigneten Komponententest getestet werden." Verwenden Sie ein Coverage-Tool, um dies zu beweisen, und lassen Sie die Testqualität von einer anderen Person überprüfen.

Ich denke, dass es in der Praxis eine gute Idee ist, ganz bestimmte Ziele im Voraus zu haben, dh SMART (vielleicht arbeiten wir tatsächlich am selben Ort), aber für die meisten Teams ist dies nicht sehr praktisch.

Das Problem ist wirklich, dass sich unsere inkrementellen Ziele ändern. Das Geschäft ändert sich und als Entwickler müssen wir richtig und in einem angemessenen Zeitrahmen reagieren.

Überlegen Sie, ob Sie Ziele festlegen möchten, die mit dem Zweck Ihres Teams oder Ihrer Gruppe in der Organisation zusammenhängen. Ihr Team würde nicht finanziert, wenn es keinen Zweck erfüllen würde - einen Makrozweck. Haben Sie kollektive Ziele, die in Ihrem gesamten Team existieren und auf das Unternehmen abgestimmt sind. Geben Sie den Menschen Verantwortung und machen Sie sie zur Rechenschaft. Feiern Sie ihre Erfolge und Misserfolge (wenn wir manchmal nicht scheitern, versuchen wir es wahrscheinlich nicht und das wollen Sie von den Menschen). HTH

Wir haben eine Reihe von Metriken, die gesammelt werden, wenn Programmierer arbeiten, wie zum Beispiel:

• Anzahl der geänderten / hinzugefügten SLOC
• Anzahl der Fehler / Bugs, die in verschiedenen Phasen des Prozesses (während der Begutachtung, nach der Begutachtung, nach der Veröffentlichung) injiziert wurden
• Änderungswünsche erfüllt / abgelehnt
• Formale Dokumente (Softwareversionsbeschreibungen, Designdokumente usw.)

All dies sind Sachverhalte, die ich in Präsentationen für das Management und die Qualitätssicherung von Software nützlich finde. Aber ich habe sie nie für schrecklich nützlich befunden, um die Leistung der Menschen tatsächlich zu bewerten - das ist der Punkt, auf den mehrere der von Ihnen aufgelisteten Links hinweisen. Ich habe festgestellt, dass Joels Punkte hier gültig sind - Metriken fördern niemals eine gute Teamatmosphäre.

Leider leben wir alle in einer Welt, in der andere Kennzahlen benötigen (Management, Qualitätssicherung, externe Auftragnehmer usw.). Ich habe festgestellt, dass ein Balanceakt erforderlich ist - Bereitstellung dieser Metriken, aber auch Nachweis von immateriellen Werten -. Immaterielle Werte sind das, was jeder Programmierer erreicht hat und die nicht unbedingt nachverfolgt werden müssen. Zum Beispiel hatte ich einen Programmierer, der viel Zeit damit verbrachte, Legacy-Code zu untersuchen, den sonst niemand berühren wollte. Obwohl seine Kennzahlen für diesen Zeitraum niedrig waren, war dieser Aufwand von unschätzbarem Wert.

Die einzige Möglichkeit, solche Dinge einzubeziehen, bestand darin, auf die Schaffung einer zusätzlichen immateriellen Kategorie zu drängen und diese mit den anderen Metriken gleich zu gewichten. Normalerweise reicht dies aus, um die Balance für einen bestimmten Programmierer zu schwingen.

Eines der Probleme scheint zu sein, dass IT-Organisationen als Abteilung / Abteilung keine messbaren strategischen Ziele haben. Wenn sie dies tun würden, wäre es einfacher, die Ziele für die Individuen festzulegen.

Wenn es beispielsweise eine Abteilungsinitiative gab, um die Anzahl der aufgeworfenen Problemtickets zu verringern, können Sie individuelle Ziele festlegen, die auf der Anzahl der Tickets für die von ihnen betreute Software basieren.

Da die Softwareentwicklung weitgehend kollabarativ ist, wäre es sinnvoller, Ziele auf Teamebene festzulegen und dann Einzelpersonen nach ihrem Beitrag zum Team zu bewerten.

Ein Ziel, das mir gefällt, ist:

Fordern Sie vom Projektkunden N positive Bewertungen Ihrer Beteiligung an einem Projekt an.

Dies ist hilfreich, da es immer gut ist, schriftliche positive Rückmeldungen von Kunden (intern oder extern) zu erhalten. Es ist nicht schwer zu bekommen, es ist relevant und es ist ein einfaches, aber nicht bedeutungsloses Häkchen auf der Liste.

Ich denke, es ist ein entscheidender Punkt, zu bestimmen, wie die persönliche Entwicklung an den durchgeführten Projekten ausgerichtet werden kann. Wenn Entwickler sich selbst analysieren, um Schwachstellen zu finden, und Feedback zu anderen geben, kann dies eine Möglichkeit sein, Verbesserungen zu finden und diese dann zu messen. Zum Beispiel kann ich feststellen, dass ich selten abgeschlossene Artikel dokumentiere, und so kann ich für meine Ziele für das Jahr angeben, dass ich dies verbessern möchte und dass die Menge an Dokumentation, die ich produziere, ein Maß dafür sein kann. Es kann funktionieren oder es kann nach hinten losgehen, je nachdem, wie ich es wirklich befolge. Einerseits kann es berechtigte Bedenken geben, wie ich meine Arbeit verbessere und das tue, was als der richtige Weg angesehen werden kann, während eine passive aggressive oder kindische Sichtweise darin besteht, einen Berg von Dokumentation zu produzieren, wenn dies nicht der Fall ist.

Die Definition eines effektiven Entwicklers ist ein weiteres Element. Ist es die Person, die Fehler am besten behebt? Funktioniert neue am schnellsten? Werden neue Arbeiten mit Tests und Dokumentationen abgeschlossen, obwohl dies nicht schnell erledigt wird? Was nennen Sie effektiv, da die Standardantwort "es kommt darauf an" hier geklärt werden sollte.