Ich versuche, KPI für Mitarbeiter meines Unternehmens zu implementieren. Einer der aufgeführten KPIs ist die Qualität des Codes, gemessen an Fehlern, die von Entwicklern erstellt wurden.
Jetzt ist mein Problem: Ich habe vor, einem Entwickler 40 Punkte (mein Bewertungssystem) zu geben, wenn er/sie fehlerfreien Code erstellt.
Es kann Fehler geben, die schwerer, mittlerer und niedriger Natur sind. Wie bewerte ich meine Entwickler und vergebe Punkte basierend auf der Anzahl der Fehler, die sie erstellen?
Bitte seien Sie vorsichtig, wenn Sie diese Art von Messungen als KPIs verwenden.
Wenn Sie dies tun, prognostiziere ich Folgendes:
Dieser Artikel von Esther Derby schlägt Alternativen zur Verwendung von KPIs in Gehaltsüberprüfungen vor. Es gibt immer mehr Beweise dafür, dass die Verwendung von Leistung als Maß für die Bezahlung destruktiv ist. Meine Erfahrung ist sicherlich, dass es eher Heldentum und eine Schuldzuweisungskultur als Teamarbeit fördert, insbesondere wenn die KPIs unerwünschte Elemente messen.
Ich denke, dir fehlen auch ein paar KPIs ...
Negative Punkte jedes Mal, wenn ein Product Owner eine Anforderung ändert. Sie hätten wissen müssen, was sie wollten, bevor die Entwicklung begann.
Negative Punkte jedes Mal, wenn ein Tester doppelte Punkte eingibt. Vielleicht bekommen sie jedes Mal positive Punkte, wenn sie einen Fehler finden?
Negative Punkte für die Personalabteilung jedes Mal, wenn ein „guter“ Entwickler geht, um woanders zu arbeiten. Und positive Punkte jedes Mal, wenn sie einen Entwickler überreden können, für Sie zu arbeiten, weil das eine schwierige Sache wird ;-)
Das ist auf so vielen Ebenen eine schlechte Idee.
Lassen Sie uns die Möglichkeiten auflisten:
Die Verhaltensweisen, die Sie fördern möchten, sind:
Damit:
Wenn Sie diesen Weg fortsetzen, werden 3 Dinge für Sie erledigt:
Senken Sie die Moral Ihrer Entwicklungsteams
Steigern Sie die Mitarbeiterfluktuation, wenn sie in sinnvolleren Entwicklungsumgebungen nach Arbeit suchen
Reduzieren Sie die Liefergeschwindigkeit für Ihre Kunden.
Sie müssen nun auswählen, wie Sie fortfahren möchten.
Leistungsbewertungen auf der Grundlage von Fehlern sind meiner Meinung nach eine ziemlich schlechte Idee.
Selbst in den besten Szenarien, in denen angenommen wird, dass Tester perfekte Arbeit leisten, ist es sehr schwierig, eine Art Bugtracker zu implementieren, der keine Nebenwirkungen erzeugt.
Sie könnten in Betracht ziehen, eine Art Metrik für Nacharbeitsstunden zu verwenden. Das funktioniert tendenziell besser, weil:
Verlagern Sie den Schwerpunkt von Fehlern auf leistungsfähigere Software, es macht einfach mehr Sinn.
Ich plane, einem Entwickler 40 Punkte (mein Bewertungssystem) zu geben, wenn er fehlerfreien Code erstellt.
Wie wäre es, wenn Sie die Programmierer fragen, wie viel (Geld) sie ausgeben würden, wenn ihnen jemand zeigen könnte, wie man fehlerfreien Code erstellt? Professionelles Programmieren ist keine leichte Aufgabe und es gibt viel bessere Möglichkeiten, gute Programmierer zu beurteilen.
Hier sind einige Gründe, warum man mit fehlerhaftem Code endet:
1. Das Management beschließt, einige neue Funktionen einzuführen, die einigen anderen zuvor implementierten Funktionen widersprechen würden. Ich meine, wer will keine neuen Features?
2. Das Management möchte diese in der nächsten Version haben, aber keine Zeit, den vorhandenen Code umzugestalten und zu bereinigen. Ich meine, wenn der Kunde nichts Neues sieht, was wird das Management präsentieren? Wir haben keine neuen Funktionen in dieser Version, aber jetzt funktioniert alles so, wie es soll? Ja, versuchen Sie, das vor einem Publikum zu sagen
Was Sie wirklich brauchen, heißt Code-Review, es wird von professionellen Programmierern durchgeführt, die den Code paarweise durchgehen und die Probleme beheben, aber damit dies funktioniert, brauchen Sie mindestens einen guten Programmierer. Heutzutage gilt jeder, der tippen kann, als Programmierer.
PS: Die obigen Kommentare stammen aus der Sicht eines Programmierers und eines Managers.
Das Festlegen eines Ziels wie der Anzahl der Fehler ist etwas, das leicht auszutricksen ist, und es ist leicht, jemanden zu finden, dem die anderen die Schuld geben können. Das zerstört Ihren Teamzusammenhalt. Bitte messen Sie die Menschen nicht an den Fehlern, die sie eingeführt haben. Wenn Sie dies tun, werden sie nichts festschreiben, bis sie zu 100 % sicher sind, dass es fehlerfrei ist, und Sie werden nie eine Veröffentlichung haben. Während ich diese Antwort schrieb, kamen mir 7 verschiedene Möglichkeiten, diesen KPI auszutricksen, also werde ich wie ein ziemlich guter Entwickler aussehen, während ich nichts Gutes für die Organisation tue.
Ich habe einen anderen Vorschlag. Suchen Sie nach wiederkehrenden Problemen . Wenn Sie Mitarbeiter bewerten, konzentrieren Sie sich auf ihren Fortschritt und belohnen Sie diejenigen, die sich ständig verbessern, und lassen Sie diejenigen gehen, die sich nicht verbessern.
Nehmen wir an, wir arbeiten zusammen und ich mache viele Programmierfehler. Wir sind uns einig, dass ich mehr über die Sprache lerne, die wir verwenden. Du wirst meinen Fortschritt überprüfen und wenn sich mein Programmierstil verbessert, belohnst du mich. Wenn nicht, dann haben wir etwas zu besprechen.
Die Einwände aller Mitwirkenden sind zielführend und diese stimmen bei allen KPIs. Sie legen eine Metrik für gesteigertes erwünschtes Verhalten fest, dieses erwünschte Verhalten wird „bezahlt“ durch das Entfernen anderer Verhaltensweisen, von denen einige ebenfalls erwünscht sind. Aus diesem Grund ist die Erstellung Ihrer KPIs sehr herausfordernd und Sie müssen dies mit Sorgfalt tun.
Hier ist ein ausgewogener Ansatz erforderlich, bei dem Sie, wenn Sie die Reduzierung von Qualitätsmängeln messen, auch die anderen Verhaltensweisen messen und belohnen müssen, die wahrscheinlich ebenfalls betroffen sein werden. Wenn ich zum Beispiel an Qualität gemessen werde, werde ich langsamer und meine Arbeit doppelt überprüfen. Dem muss man also rechtzeitig mit einer Messung entgegenwirken. Ich würde auch weniger Risiken eingehen, was man in vielen Umgebungen nicht möchte. Dem muss man also entgegenwirken. Sie müssen auch auf Ursache und Wirkung achten, die Beziehung zwischen der unabhängigen Variablen (was Sie manipulieren) und der abhängigen Variablen (dem Ergebnis). Was intuitiv, logisch und sogar "gesunder Menschenverstand" erscheint, ist zu oft nicht wahr. Man sollte meinen, dass eine Gehaltserhöhung positive Auswirkungen auf die Arbeitsmoral und den Arbeitseinsatz hat. Tatsächlich wird die Moral nicht berührt,
Es kann sein, dass die Bewertung von Fehlern nicht die Lösung zur Qualitätssteigerung ist, sondern eher die Verhaltensweisen bewertet werden, die zu Qualität führen, dh Frühindikatoren. Wir wissen, dass erhöhte Fähigkeiten höhere Leistung bedeuten sollten, also gibt es vielleicht ein oder zwei KPIs, die den Erwerb und die Beherrschung von Fähigkeiten motivieren.
Um ehrlich zu sein, glaube ich, dass Sie das nicht tun sollten. Meiner Meinung nach gibt es keinen fairen Weg, dies zu messen. Kein Programmierer, egal wie erfahren er ist, wird fehlerfreien Code erstellen. Manchmal werden Fehler von anderen Fehlern verdeckt. Manchmal entstehen Fehler aus der Interaktion zweier separater Codeteile, die für sich genommen frei von Fehlern sind. Vielleicht bleiben wirklich schwerwiegende Fehler monate- oder jahrelang unentdeckt.
Ich glaube, das ist genauso falsch wie der Versuch, die Leistung anhand der Anzahl der pro Tag produzierten Codezeilen zu messen.
Qualität ist ein Prozess und kein einfaches Maß für „Fehler“-Raten. Sie verbessern die Qualität, indem Sie einen besseren Prozess von Anfang bis Ende schaffen, der sich über alle Ebenen der Organisation erstreckt. Die Benachteiligung einer Rolle in der Wertschöpfungskette wird Ihnen nicht dabei helfen, Ihr Ziel zu erreichen.
Ich habe einmal in einer solchen Umgebung gearbeitet und weißt du was? Ich verließ diesen Ort mit Wut und in sehr schlechten Bedingungen. Und das ist es, woran Sie leiden werden, wenn Sie tatsächlich versuchen, die Fähigkeiten Ihrer Entwickler anhand ihrer Fehler zu messen.
Du machst alles falsch. So haben wir es damals behoben:
Erstellen Sie eine komplexe, aber kurze gedruckte Liste der wichtigsten Punkte.
Wenn jemand diese Liste NICHT überprüft, bevor er DANN freigibt, können Sie ihm oder ihr die Schuld geben.
So sollte es laufen. Denn wenn Sie anfangen, Fehler zu messen, werden Sie sehr schlechtes „Karma“ von Ihrem Mitarbeiter bekommen, alle werden Sie hassen und mit Ihnen umgehen, als ob Sie ein Diktator wären. Und auch Sie werden denen Anerkennung zollen, die absolut nichts Gutes tun!
Jeder macht Fehler und es gibt immer DIESE Kleinigkeit, an die wir uns vor der Veröffentlichung nicht erinnern, und deshalb gibt es Hotfixes !
Dies ist ein Paradebeispiel für „Messungsstörung“.
Jeder Versuch, einen Mitarbeiter auf der Grundlage einer harten Metrik zu belohnen oder zu bestrafen, wird fehlschlagen. Der Mitarbeiter ist schlau genug, die Metrik zu spielen, und normalerweise mit dem gegenteiligen Effekt, der beabsichtigt war.
Joel Spolsky hat es in diesen Blogbeiträgen sehr gut behandelt:
Joels Artikel enthalten viele Beispiele, einschließlich des Themas dieser Frage:
Angenommen, Sie entscheiden sich, dem Entwickler mit den wenigsten Fehlern einen Bonus zu zahlen. Jedes Mal, wenn ein Tester versucht, einen Fehler zu melden, wird dies zu einem großen Streit, und normalerweise überzeugt der Entwickler den Tester, dass es sich nicht wirklich um einen Fehler handelt. Oder der Tester stimmt zu, den Fehler „formlos“ dem Entwickler zu melden, bevor er ihn in das Fehlerverfolgungssystem einträgt. Und jetzt benutzt niemand das Bug-Tracking-System. Die Anzahl der Fehler geht weit zurück, aber die Anzahl der Fehler bleibt gleich.
Entwickler sind auf diese Weise clever. Was auch immer Sie zu messen versuchen, sie werden einen Weg finden, es zu maximieren, und Sie werden nie ganz das bekommen, was Sie wollen.
Wenn Sie die Vergütung von jemandem an ein beliebiges numerisches Bewertungssystem binden, drängen Sie diese Person, sich an das Bewertungssystem zu halten, anstatt daran zu arbeiten, tatsächlich Geschäftsergebnisse zu erzielen. „Ich bekomme die volle Punktzahl, wenn ich keine Fehler schreibe? Cool! Ich werde keinen Code schreiben!“
Die logische Folge dieser Regel ist, dass Sie sich kein Bewertungsschema ausdenken können, das nicht auf unnütze Weise „gespielt“ werden kann.
Für ein System, das ausreichend komplex ist, um wirklich wertvolle Arbeit zu leisten, werden Sie niemals fehlerfreien Code haben. Sie haben weniger fehlerhaften und mehr fehlerhaften Code. Aber da wird irgendwo ein Bug drin sein.
Ich denke, Sie werden nur Ihre Kollegen verärgern und sich einige Feinde machen.
Bugs sollten vom Tester abgeholt werden. Wenn dieser Tester das Gefühl hat, dass ein bestimmter Mitarbeiter ständig Dinge kaputt macht, dann ist es sinnvoll, mit diesem Mitarbeiter zu sprechen und zu sehen, wie seine Leistung verbessert werden kann. Anstatt alle wegen ihres Jobs paranoid und unsicher zu machen.
Wie bei allen anderen bisher bin ich ziemlich dagegen. Ein paar Gründe fallen mir ein:
Außendruck
Die meisten Unternehmen erlauben den Unternehmen, die Softwareentwicklung unter Druck zu setzen/zu kontrollieren. Was ich meine, ist, dass nur sehr wenige Orte einen Entwickler fragen, wie lange es dauern wird, etwas zu tun, und ihm dann so lange Zeit lassen. Sie geben einen Zeitplan vor, der dem Product Owner nicht gefällt, und Sie werden wahrscheinlich von ihm unter Druck gesetzt, dies früher zu erledigen.
Während es immer noch der Entwickler ist, der Fehler schreibt, sind viele Kräfte im Spiel. Er möchte nicht dafür bestraft werden, dass er geschäftliche Anforderungen nicht erfüllt. Aber wenn sie ihn weiterhin unter Druck setzen, an einem Tag ein Feature zu schreiben, das eine Woche dauern sollte, können Sie darauf wetten, dass es Fehler geben wird.
Mehrere Ebenen
Bei mehreren Ebenen oder Ebenen von Software könnte ein Fehler in der oberen Ebene gefunden werden, aber tatsächlich durch etwas tieferes verursacht werden. Außerdem könnten „Bugs“ eingeführt werden, weil die Schichten missverstanden, was die anderen taten.
Abnahme der Produktivität
Die tatsächliche Produktivität wird sinken, da Sie jetzt nicht nur das Projekt einer Qualitätssicherung unterziehen müssen, sondern sich auch Zeit nehmen müssen, um die wahre Ursache und den Schuldigen herauszufinden. Während dies einfach erscheinen mag, würde ich wetten, dass es zu etwas Größerem explodieren wird. Wenn meine Leistung darauf basiert, dass ich keine Fehler bekomme und Sie versuchen, mir einen Fehler zuzuweisen, können Sie darauf wetten, dass ich argumentieren werde, dass dies nicht der Fall ist. Dies wird keine einfache E-Mail sein, in der steht: „Das war Johns Schuld, nicht meine.“ Denn jetzt wird John antworten. Am Ende sitzen Sie mindestens einmal pro Woche in stundenlangen Besprechungen und versuchen, alle Fehler zu sortieren.
Entwickler müssen professionell sein
Ansätze wie dieser mindern tendenziell die Professionalität von Entwicklern. Denken Sie an CEOs, sie werden oft anhand des Gesamtwachstums des Unternehmens bewertet, richtig? Wenn sie einen 100.000-Dollar-Kunden im Jahr verlieren, ist das vielleicht schlecht, aber es wird oft heruntergespielt, wenn sie das Unternehmen in diesem Jahr immer noch um 500.000 Dollar wachsen lassen.
Pläne, die versuchen, Entwickler an Metriken wie diese (Anzahl der veröffentlichten Fehler oder Anzahl der geschriebenen Codezeilen, veröffentlichte Funktionen, geschriebene Tests usw.) zu binden, nehmen Entwickler aus dem Bereich eines professionellen Angestellten und platzieren sie in der Kategorie der Stundenarbeiter.
Stellen Sie sich vor, Sie haben einen Stundenarbeiter, der Briefe verschickt. Sein Ziel könnte eine Genauigkeit von 100 % sein, und Sie beschließen, ihm für jeden Buchstaben, den er vermasselt, 1 Punkt anzuhängen.
Das ist im Wesentlichen das, was Sie Entwicklern antun. Sie nehmen eine Gruppe von Menschen, die typischerweise:
Und Sie machen sie zu Fabrikarbeitern. Sie werden anfangen, „auf die Uhr zu schlagen“. Sie werden anfangen, nach dem schnellsten und einfachsten Weg zu suchen, um JETZT etwas zu tun, ohne darüber nachzudenken, wie es sich in Zukunft entwickeln wird. Warum schließlich eine ganze Summenroutine bauen, wenn ich die Werte für 1*1 bis 12*12 einfach fest codieren kann. So weiß ich, dass es keine Fehler gibt.
Vorbehalt
In Anbetracht dessen sage ich jedoch NICHT , dass Entwickler nicht zur Rechenschaft gezogen werden sollten. Ich denke absolut, dass sie das tun sollten, und ehrlich gesagt, jeder Entwickler, der es wert ist, in der Nähe zu bleiben, wird keine Fehler veröffentlichen wollen. Wenn Sie Entwickler haben, denen es nichts ausmacht, Fehler zu veröffentlichen, sollten Sie sie sofort feuern (im Ernst, tun Sie es vor dem Mittagessen.)
TL;DR
Ich kann mir kein anderes berufliches Umfeld oder Beruf vorstellen, in dem Menschen versuchen, diese Art von Metriken aufeinander anzuwenden.
Wenn ein Manager nicht sagen kann, wer seine Top-Performer und wer seine Low-Performer sind, dann sollte diese Person keine Softwareentwickler verwalten, weil sie keine Ahnung hat.
Bevor Sie eine Metrik anwenden, müssen Sie viel Zeit damit verbringen, die richtige zu finden, oder Sie riskieren, Ihre Top-Performer zu verdrängen, da sie nicht wie kleine Kinder oder Fließbandarbeiter behandelt werden wollen (und am Ende Sie entscheidet sich möglicherweise dafür, keine Metriken zu haben.)
Ich habe das gesehen. Ein typischer neuer PM, der aus dem Geschäft kam (in diesem Fall ein multinationaler Einzelhandelskonzern), hatte gedacht, dass jede Abteilung gleich ist – wenn es ein Problem gibt, dann schlagen Sie den falschen Macher und halten Sie alle auf Trab. Funktioniert nie mit IT. Die meisten Projekte, die überhaupt einen PM erfordern, bedeuten mehrere Programmierer und Sys-An, Bus-An, Benutzerunterstützung, Architekten usw. usw. Alle mit ihren Rudern im Wasser. Scope Creep, Aufgabenverschiebung, Verzögerungen, Meilensteineinschränkungen, Upstream-/Downstream-Systemänderungen, Personalbesetzung/Krankheit/Urlaub/Neuzuweisung/Vertragsänderungen, externe Systemprobleme, Hardwareprobleme, Domänen-/Umgebungsprobleme, Einrichtungsprobleme, Legacy-Code/-Systeme, schlecht Code, der als Basis in das Projekt einfließt (dh ursprünglicher Code, der ergänzt werden muss), ist die Liste fast endlos - so viele Dinge führen dazu, dass sich die Dinge an der Kohlefront ändern. Gute Entwicklerteams werden dies kompensieren, die zusätzlichen Stunden aufwenden, die Extrameile gehen – und ihre Eventualitäten aus dem Fenster werfen. Das bedeutet Fehler. Dies ist an sich kein Problem, es ist Teil des Prozesses - es ist nicht wie ein Stuhlhersteller, der einen Miststuhl herstellt, der in den Mülleimer wandert, Fehler können behoben werden. Wenn Sie KPIs ausführen möchten, tun Sie dies anhand der Anzahl der als Team behobenen Fehler, nicht der erhobenen. Andernfalls werden Fehler versteckt oder „zusammengeführt“ – Schuld wird in alle Richtungen (auch nach oben!) geschossen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen. gehen Sie die Extrameile - und werfen Sie ihre Eventualitäten aus dem Fenster. Das bedeutet Fehler. Dies ist an sich kein Problem, es ist Teil des Prozesses - es ist nicht wie ein Stuhlhersteller, der einen Miststuhl herstellt, der in den Mülleimer wandert, Fehler können behoben werden. Wenn Sie KPIs ausführen möchten, tun Sie dies anhand der Anzahl der als Team behobenen Fehler, nicht der erhobenen. Andernfalls werden Fehler versteckt oder "zusammengeführt" - Schuld wird in alle Richtungen (auch nach oben!) geschossen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen. gehen Sie die Extrameile - und werfen Sie ihre Eventualitäten aus dem Fenster. Das bedeutet Fehler. Dies ist an sich kein Problem, es ist Teil des Prozesses - es ist nicht wie ein Stuhlhersteller, der einen Miststuhl herstellt, der in den Mülleimer wandert, Fehler können behoben werden. Wenn Sie KPIs ausführen möchten, tun Sie dies anhand der Anzahl der als Team behobenen Fehler, nicht der erhobenen. Andernfalls werden Fehler versteckt oder „zusammengeführt“ – Schuld wird in alle Richtungen (auch nach oben!) geschossen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen. es ist Teil des Prozesses - es ist nicht wie ein Stuhlhersteller, der einen Miststuhl herstellt, der in den Mülleimer wandert, Fehler können behoben werden. Wenn Sie KPIs ausführen möchten, tun Sie dies anhand der Anzahl der als Team behobenen Fehler, nicht der erhobenen. Andernfalls werden Fehler versteckt oder "zusammengeführt" - Schuld wird in alle Richtungen (auch nach oben!) geschossen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen. es ist Teil des Prozesses - es ist nicht wie ein Stuhlhersteller, der einen Miststuhl herstellt, der in den Mülleimer wandert, Fehler können behoben werden. Wenn Sie KPIs ausführen möchten, tun Sie dies anhand der Anzahl der als Team behobenen Fehler, nicht der erhobenen. Andernfalls werden Fehler versteckt oder "zusammengeführt" - Schuld wird in alle Richtungen (auch nach oben!) geschossen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen. Es wird auch für ein restriktives Umfeld sorgen. Wenn Sie als Entwicklungsleiter mitten im Projekt zu mir kommen und auf eine Änderung drängen, würde ich Ihnen sagen, dass Sie bis zur nächsten Phase warten sollen – es würde überhaupt kein Scope Creep geben, es sei denn, Sie sind bereit, alle Fehler abzuschreiben und den KPI zu übernehmen stattdessen schlagen.
Dieser Ansatz wird auf Sie zurückschlagen – denken Sie noch einmal darüber nach!
Ein guter Entwickler ist die Art von Person, die den Testern und dem QA-Team fröhlich sagt: „Bitte – ich möchte , dass Sie Fehler in meinem Code finden“. Er ermutigt Tester aktiv, seinen Code zu knacken, damit er ihn verbessern kann. Seine Motivation ist es, all diese Fehler zu finden, bevor es für die Produktion freigegeben wird.
Wenn Sie den Entwickler dazu motivieren, die Anzahl der gemeldeten Fehler zu minimieren, glauben Sie, dass er so begeistert sein wird?
Ich denke, das Einzige, was noch schlimmer sein könnte, ist, Entwickler basierend auf der Anzahl der Fehler zu bezahlen, die sie beheben. Ich kann fast garantieren, dass es viel länger dauern wird, bis ein Code das Licht der Welt erblickt, wenn Sie auf der Grundlage der umgekehrten Anzahl der erstellten Fehler bezahlen.
Sie werden besser dran sein, eine Kultur und Prozesse zu schaffen, die weniger Fehler fördern. Brechen Sie den Build ab, Sie bekommen ein bisschen gutmütige, öffentliche Schande – und können es reparieren. Verwenden Sie TDD, um das Design und die Codeentwicklung voranzutreiben, damit Sie wissen, dass Sie Tests haben, die die Funktionen abdecken, an denen Sie arbeiten. Verwenden Sie Code-Reviews/Pair-Programming, um mehr als einen Blick auf den Code zu lenken. Dinge wie diese fördern gute Praktiken, belasten die Leute aber nicht und verursachen keine Lähmung wie „Du bekommst Geld für jeden Fehler, den du hast“.
Belohnen Sie das Team für gute Arbeit, dafür, Dinge zu erreichen – Projekte schnell mit zufriedenen Kunden auf den Weg zu bringen. Belohnen Sie Einzelpersonen dafür, dass sie ihre Fähigkeiten verbessern und zum Team beitragen.
Dies ist die einzige Frage, die zählt: Ist es gut genug?
In jeder Branche ist Perfektion teuer . Suchen Sie nach einfach zu wartendem Code. Es ist in Ordnung, wenn es Fehler gibt, solange der Stil des Programmierers es einfach macht, sie zu beheben.
Nur um die Liste dessen, was passieren wird, zu ergänzen:
Es kommt oft vor, dass auf den zweiten Blick, vielleicht bei der nächsten Funktionserweiterung, derselbe Programmierer seinen eigenen Fehler findet. Ich nehme an, Sie können sich davor schützen, indem Sie ihnen keine Punkte berechnen.
Meiner Meinung nach wollen Sie Programmierer nicht davon abhalten, Fehler aufzudecken. Und ich denke, das ist alles, was Sie mit dieser Art von Ansatz erreichen werden.
Dies kommt von einem Programmierer mit 12 Jahren Erfahrung, der aber nur in 1 Firma gearbeitet hat. Kompetente Manager sollten kein Problem damit haben, gute und schlechte Performer zu identifizieren, und dieses System scheint ein Versuch zu sein, das Management zu automatisieren.
Stärken Sie Ihre Entwickler, anstatt sie mit willkürlichen Maßstäben zu messen. Schauen Sie sich Agile an . Fehler sind kein Maßstab für gute Arbeit, Fehler passieren. Zufriedene Kunden sind ein Maß für gute Arbeit, aber Zufriedenheit lässt sich nicht wirklich messen.
Die Grundidee von Agile ist, dass die Entwickler ihre Ziele haben, die Arbeit untereinander aufgeteilt haben und in kleinen Schritten auf funktionsfähige Funktionen hinarbeiten. Sie sind direkt verantwortlich für das, was sie tun. Und das Beste daran ist, dass Sie die Punkte nicht im Auge behalten müssen!
Es gibt viele Bücher und Websites über Agile, und Ihre Entwickler werden es mögen, wenn Sie diesen Ansatz übernehmen, wenn er gut implementiert ist.
Warten Sie, das Originalplakat sagte nicht, in welche Richtung das gehen würde. Vielleicht mehr Bugs ist besser. Je mehr Bugs ein Entwickler produziert, desto produktiver ist er natürlich! Wenn sie die durchschnittliche Fehlerproduktionsrate haben, dann haben sie umso mehr Code geschrieben, je mehr Fehler sie haben.
Natürlich ist es auch keine gute Idee, mehr Fehler anzureizen, da es ziemlich einfach wäre, Fehler absichtlich einzubauen.
Ich kenne einen lustigen. Wie wäre es, wenn Sie einige Ihrer Entwickler dazu anregen, hinterhältige Fehler zu erstellen, die es durch so viele Ebenen der Codeüberprüfung, -inspektion und -tests wie möglich schaffen können? Dann können Sie Fehler in diesem Prozess aufdecken ...
Seien Sie für den Anfang, wie andere vorgeschlagen haben, vorsichtig, wenn Sie erwägen, die Vergütung an die „Leistung“ zu binden. Bevor Sie diesen Weg einschlagen, sehen Sie sich Dan Pinks TED-Vortrag über die überraschende Wissenschaft der Motivation an: http://www.ted.com/talks/dan_pink_on_motivation.html
Nicht, dass Metriken nutzlos wären. Diese Art von Metriken sind jedoch für Teams nützlicher als für Einzelpersonen. Das Team ist hier das gesamte Team, das an der Bereitstellung eines Produkts beteiligt ist: Dazu gehören Entwickler undTester (und Produktmanager, Projektmanager...). Entwicklung und Test sollten nicht gegensätzlich sein. Messen Sie viele Dinge und verwenden Sie sie, um eine ungefähre Vorstellung vom Fortschritt Ihres Teams zu bekommen. Machen Sie sich nichts vor, dass alle oder sogar einige Ihrer Metriken wirklich objektiv sein werden. Fehler sind jeweils subjektiv, daher ist eine Reihe von Fehlern noch subjektiver. Ihre Messwerte sind genauer, wenn es Anreize gibt, sie wahrheitsgemäß zu melden. Solche Anreize können immateriell sein und sind idealerweise mit einer Unternehmenskultur der Offenheit, Zusammenarbeit, des Lernens und der Verbesserung verflochten. Die meisten Metriken stellen auch Kompromisse mit Kosten oder letztendlich Gewinn dar. Die Reduzierung von Kundenvorfällen auf null ist wahrscheinlich kostenintensiv, ebenso wie eine 100-prozentige Testautomatisierungsabdeckung. Normalerweise ist die Meinung von Experten wertvoller als eine Metrik. Meine Güte, fragen Sie Ihr Team, wie sie' tun -- wenn die Unternehmenskultur gut ist, werden sie ihre Leistung wahrheitsgemäß melden. Wenn Sie einen agilen Prozess haben, tun Sie dies hoffentlich bereits in Ihren Retrospektive-Meetings. Wenn Sie Metriken in Kombination mit Expertenmeinungen und in einem Kontext offener Kommunikation und Zusammenarbeit verwenden, glaube ich, dass sie wertvoll sein können.
Zu den Metriken eines Produkt-/Dienstleistungsentwicklungsteams können gehören:
Das ist ungefähr der schlechteste Weg, um irgendeine Art von Kameradschaft aufzubauen. Was wäre, wenn jemand Sie beispielsweise anhand der Anzahl schlecht geschriebener Anforderungen oder verpasster Meilensteine beurteilen könnte?
Es ist unmöglich, die Leistung nur anhand der Fehlerraten der Entwicklerarbeit zu messen.
Wieso den? Fehlerfreie Apps bedeuten nicht, dass der Entwickler einfach zu wartenden Code erstellt hat, und es garantiert nicht, dass es in seiner Arbeit kein fest codiertes Skript gibt.
Aus meiner Sicht und was ich getan habe, messe ich die Leistung von Entwicklern, indem ich den Status verwende, wann er/sie seine Arbeiten an Tester übermittelt hat, wie viele Codes an Entwickler zurückgegeben werden und wie lange sie ihre Arbeiten nach den zugehörigen Aufgaben einreichen ihnen zugeordnet.
Anreiz? Sie bekommen ihn, wenn sie das von mir vorgegebene Ziel übertreffen oder erreichen konnten. Ich habe 8 Jahre als Softwareentwickler gearbeitet, und jede Aufgabe, die ich meinen Entwicklern gegeben habe, wurde zuerst an den Schwierigkeiten und der Komplexität der Geschäftsprozesse gemessen.
Zu spät zur Party, aber das würde ich an deiner Stelle tun:
Basieren Sie eine Metrik auf dem gewünschten Ergebnis . Ich würde häufigere Veröffentlichungen bevorzugen. Je kürzer das Zeitintervall zwischen den Releases ist, desto höher ist der KPI. Die Nebeneffekte sind kleinere Releases (d. h. weniger Fehler), Continuous Delivery, automatisierte Tests und eine Umgebung, in der Fehler innerhalb von Minuten behoben werden können.
Machen Sie es zu einer Teammetrik. Wenn Sie Personen belohnen, bitten Sie jedes Teammitglied, 10 Punkte auf seine Kollegen zu verteilen, je nachdem, wer der Leistung des Teams am meisten zuschreibt. Verteilen Sie die Belohnungen entsprechend.
Fragen Sie das Team, was es für einen guten KPI halten würde, wenn Sie bedenken, dass Ihnen die Leistung des Ganzen (der Wert, den Sie Ihren Kunden liefern) wichtig ist, nicht die interne persönliche Leistung. Fragen Sie sie, wie sie eine Gesamtoptimierung anstelle einer Teiloptimierung belohnen können.
woliveirajr
Tommy B.
Lorenzo Dematte
Christoffer Hammarström
Allov
zzzzov
böse Süßigkeitentüte
Isaac Fife
Ian Halter
Peter K.
Roy Tinker
GBa
Okt
Jeff
Matthäus Lock
Fragen
Wolf5370
Bastien Vandamme
woliveirajr
zzzzov
mcmcc
Levi Hackwith
Fragen
Promotion