Eine Erzählung aus eigener Erfahrung. Entschuldigung für die Länge.
Vor ein paar Jahren hat unsere Entwicklungsgruppe versucht, "richtige" messbare Ziele für Einzelpersonen und Teamleiter festzulegen. Das Experiment dauerte nur ein Jahr, weil harte Messgrößen für individuelle Ziele nicht wirklich gut funktionierten (siehe meine Frage zu diesem Thema für einige Links und weitere Diskussionen).
Man beachte, dass ich Teamleiter war und zusammen mit meinem technischen Chef und den anderen Teamleitern an der Planung beteiligt war, so dass die Ziele nicht von oben herab von der ahnungslosen Geschäftsleitung diktiert wurden - wir wollten damals wirklich, dass sie funktionieren. Es ist auch erwähnenswert, dass die Bonusstruktur ungewollt den Wettbewerb zwischen den Entwicklern förderte. Hier sind meine Beobachtungen zu den Dingen, die wir ausprobiert haben.
Für den Kunden sichtbare Probleme
In unserem Fall zählten wir die Ausfälle bei den Dienstleistungen, die wir für die Kunden erbrachten. Bei einem eingeschweißten Produkt könnte es die Anzahl der von Kunden gemeldeten Fehler sein.
Vorteile: Dies war die einzige wirkliche Maßnahme, die für das obere Management sichtbar war. Sie war auch die objektivste, da sie außerhalb der Entwicklungsgruppe gemessen wurde.
Benachteiligungen: Es gab nicht viele Ausfälle - nur etwa einen pro Entwickler für das ganze Jahr - was bedeutete, dass das Erreichen oder Übertreffen des Ziels eine Frage der "Schuldzuweisung" für die wenigen Ausfälle war, die in jedem Team auftraten. Dies führte zu einem schlechten Gefühl und einem Verlust an Moral.
Umfang der abgeschlossenen Arbeiten
Vorteile: Dies war die einzige positiv messen. Alles andere war "wir merken, wenn etwas Schlimmes passiert", was demoralisierend war. Die Einbeziehung dieser Maßnahme war auch deshalb notwendig, weil ein Entwickler, der das ganze Jahr über nichts getan hat, alle anderen Ziele übertreffen würde, was eindeutig nicht im Interesse des Unternehmens wäre. Die Messung der abgeschlossenen Arbeit kontrollierte den natürlichen Optimismus der Entwickler bei der Einschätzung des Aufgabenumfangs, was nützlich war.
Benachteiligungen: Das Maß für die "abgeschlossene Arbeit" basierte auf Schätzungen, die von den Entwicklern selbst abgegeben wurden (was normalerweise eine gute Sache ist), aber die Einbeziehung in ihre Zielsetzungen ermutigte dazu, das System zu manipulieren und die Schätzungen aufzublähen. Wir hatten kein anderes brauchbares Maß für die abgeschlossene Arbeit: Meiner Meinung nach ist die einzig sinnvolle Art, die Produktivität zu messen, die "Auswirkung auf das Endergebnis des Unternehmens", aber die meisten Entwickler sind so weit vom direkten Verkauf entfernt, dass dies auf individueller Ebene kaum praktikabel ist.
Fehler im neuen Produktionscode gefunden
Wir haben Defekte gemessen eingeführt im Laufe des Jahres in den neuen Produktionscode einfließen, da man der Meinung war, dass Fehler aus den Vorjahren bei den diesjährigen Zielen nicht gegen eine Person angerechnet werden sollten. Fehler, die von internen Qualitätsteams entdeckt wurden, wurden auch dann gezählt, wenn sie keine Auswirkungen auf die Kunden hatten.
Vorteile: Erstaunlich wenige. Die Zeitspanne zwischen der Einführung eines Fehlers und seiner Entdeckung bedeutete, dass es eigentlich keinen unmittelbaren Feedback-Mechanismus zur Verbesserung der Codequalität gab. Makrotrends auf Teamebene waren nützlicher.
Benachteiligungen: Der Schwerpunkt lag auf dem Negativen, da dieses Ziel nur dann aufgerufen wurde, wenn ein Fehler gefunden wurde und wir jemanden brauchten, dem wir die Schuld dafür geben konnten. Die Entwickler zögerten, selbst gefundene Fehler zu erfassen, und eine einfache Zählung bedeutete, dass kleinere Fehler genauso schlimm waren wie schwere Probleme. Da die Anzahl der Fehler pro Person immer noch recht gering war, glich sich die Anzahl der leichten und schweren Fehler nicht aus, wie es bei einer größeren Stichprobe der Fall gewesen wäre. Alte Fehler wurden nicht berücksichtigt, so dass der Ruf der Gruppe hinsichtlich der Codequalität (basierend auf todo gefundene Wanzen) stimmte nicht immer mit der messbaren Anzahl der in diesem Jahr eingeführten Wanzen überein.
Pünktlichkeit der Projektabwicklung
Wir haben die Pünktlichkeit als den Prozentsatz der Arbeit gemessen, die den internen QA-Teams innerhalb der angegebenen Frist übergeben wurde.
Vorteile: Im Gegensatz zum Zählen von Fehlern war dies eine Maßnahme, die unter der unmittelbaren, direkten Kontrolle der Entwickler stand, da sie tatsächlich entschieden, wann die Arbeit abgeschlossen war. Das Vorhandensein des Ziels lenkte den Blick auf die Erledigung der Aufgaben. Dies half dem Team, sich zu realistischen Arbeitsmengen zu verpflichten, und verbesserte die Wahrnehmung der Fähigkeit der Entwicklungsgruppe, Versprechen einzuhalten, durch interne Kunden.
Benachteiligungen: Als einziges Ziel, das direkt unter der Kontrolle der Entwickler stand, wurde es auf Kosten der Codequalität maximiert: Am Tag des Abgabetermins würde der Entwickler, wenn er die Wahl hätte, eine Aufgabe für abgeschlossen zu erklären oder weitere Tests durchzuführen, um das Vertrauen in die Qualität der Aufgabe zu verbessern, sich dafür entscheiden, sie als abgeschlossen zu markieren und zu hoffen, dass die daraus resultierenden Fehler niemals an die Oberfläche kommen.
Reklamationen von internen Kunden
Um zu beurteilen, wie gut die Entwickler während der Entwicklung und des anschließenden Supports ihrer Software mit den internen Kunden kommunizierten, beschlossen wir, die Anzahl der über jede Person eingegangenen Beschwerden zu erfassen. Die Beschwerden sollten von der Führungskraft bestätigt werden, um mögliche Rachegelüste zu vermeiden.
Vorteile: Ich kann mich wirklich an nichts erinnern. Auf einer ausreichend großen Gruppenebene gemessen, ergibt sich ein nützlicherer Wert für die "Kundenzufriedenheit".
Benachteiligungen: Dies ist nicht nur äußerst negativ, sondern auch eine subjektive Maßnahme. Wie bei anderen Zielen lagen die Zahlen für jeden Einzelnen um die Nullmarke herum, was bedeutete, dass eine einzige Bemerkung über jemanden den Unterschied zwischen "unendlich übertroffen" und "nicht erfüllt" bedeuten konnte.
Allgemeine Bemerkungen
Die Bürokratie: Auch wenn unsere Aufgabenmanagement-Tools einen Großteil der Daten für diese Kennzahlen enthielten, war die Zusammenstellung der Daten immer noch mit einem erheblichen manuellen Aufwand verbunden. Die Zeit, die wir mit dem Zusammentragen all dieser Zahlen verbrachten, war nicht angenehm, konzentrierte sich im Allgemeinen auf negative Aspekte unserer Arbeit und wurde möglicherweise nicht einmal durch eine Produktivitätssteigerung wiedergewonnen.
Moral: Bei den Maßnahmen, bei denen Einzelpersonen für Probleme verantwortlich gemacht wurden, fühlten sich nicht nur die "schlechten" Teilnehmer demotiviert, sondern auch die "guten" Teilnehmer, da sie den Verlust der Team-Moral nicht gut fanden und manchmal das Gefühl hatten, dass sie nicht deshalb höher eingestuft wurden, weil sie besser waren, sondern weil sie mehr Glück hatten.
Zusammenfassung
Was haben wir also aus dieser Folge gelernt? In späteren Jahren versuchten wir, einige der Ideen wiederzuverwenden, allerdings auf eine "weichere" Art und Weise, bei der weniger die individuelle Schuld und mehr die Verbesserung des Teams im Vordergrund stand.
- Es ist unmöglich, für einzelne Entwickler Ziele zu definieren, die objektiv messbar sind, einen Mehrwert für das Unternehmen darstellen und nicht manipuliert werden können, also versuchen Sie es erst gar nicht.
- Kundenprobleme und Mängel können auf einer breiteren Teamebene gezählt werden, si Der Ort des Defekts liegt eindeutig in der Verantwortung dieses Teams, d. h., Sie müssen niemals die "Schuldfrage" stellen.
- Wenn Sie Fehler nur auf der Ebene der Verantwortung für ein Codemodul messen, können (und sollten) Sie sowohl alte als auch neue Fehler messen, da es im Interesse dieser Gruppe liegt, alle Fehler zu beseitigen.
- Die Messung der Fehlerzahlen auf Gruppenebene erhöht den Stichprobenumfang pro Gruppe, so dass Anomalien zwischen leichten und schweren Fehlern geglättet werden und ein einfaches Maß für die "Anzahl der Fehler" aussagekräftig ist, z. B. um zu sehen, ob Sie sich von Monat zu Monat verbessern.
- Fügen Sie etwas hinzu, das der oberen Führungsebene wichtig ist, denn sie bei Laune zu halten, ist Ihr Hauptziel als Entwicklungsgruppe. In unserem Fall waren es die für den Kunden sichtbaren Ausfälle. Auch wenn die Maßnahme manchmal willkürlich oder scheinbar unfair ist, wenn die Chefs sie messen, müssen Sie sie auch zur Kenntnis nehmen.
- Die obere Führungsebene braucht keine Kennzahlen zu sehen, die sie nicht in ihren eigenen Zielen hat. Auf diese Weise wird die Versuchung vermieden, einzelne Personen für Fehler verantwortlich zu machen.
- Messung der Pünktlichkeit der Projektabwicklung hat das Verhalten der Entwickler zu ändern und den Schwerpunkt auf die Erledigung von Aufgaben zu legen. Dies verbesserte die Schätzung und ermöglichte es der Gruppe, realistische Versprechungen zu machen. Wenn es einfach wäre, die Informationen über die Aktualität zu sammeln, würde ich in Erwägung ziehen, es auf Teamebene erneut einzusetzen, um Verbesserungen im Laufe der Zeit zu messen.
All dies ist nicht hilfreich, wenn es darum geht, messbare Ziele für einzelne Entwickler festzulegen, aber hoffentlich sind die Ideen für die Verbesserung des Teams nützlicher.
