Warum Change Requests sich so gern als Bugs tarnen…

Alle Software-Projekmanager kennen es: Schon wieder ein Bug der eigentlich ein Feature ist. Warum das so ist? Change Requests sind aufgrund des damit verbundenen Overheads aufwendig, insbesondere liegt der Ball erst einmal beim Anfragenden, meist einem Produktmanager. Sobald dagegen ein Fehler gemeldet wird, liegt die Verantwortung sofort bei der Entwicklung – die Aufwände für den Anforderer sinken. Ähnliche Effekte beobachtet man mit Beginn der Messung der Zahl der CRs oder Bugs um daraus Steuerungsmaßnahmen abzuleiten. Automatisch werden die beteiligten Personen ihre eigenen Interessen im Hinblick auf die kommunizierten Metriken berücksichtigen um möglichst gut auszusehen. D.h. statistische Metriken verlieren an Wert, sobald sie zur Steuerung verwendet werden.

Wie komme ich nun darauf und lässt sich dieser Punkt wirklich in dieser Form verallgemeinern?

Ted Hardy hat im Blog Better Projects auf die Verbindung zwischen Projekten und Goodheart’s Gesetz hingewiesen und ebenfalls ein Beispiel beschrieben. In der englischen Wikipedia findet man die ursprüngliche Definition des Gesetzes:

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes

[Wikipedia-Kontrollfreak-Bashing]
Die deutsche Wikipedia liefert leider keine Übersetzung, vielleicht wurde ja auch dieser Beitrag von den derzeitigen Kontrollfreaks dort mal wieder wegen Nicht-Relevanz gelöscht. Wer den Abstieg der deutschen Wikipedia verfolgen will kann sich z.B. die Löschdiskussion um Fefe’s Blog dort ansehen und weinen.
[/Wikipedia-Kontrollfreak-Bashing]

Zurück zum Thema. Im Sinne von Goodheart wird es in meinem aktuellen PM-Einführungsprojekt spannend geeignete Metriken für die Bewertung der Projekte und des Projektmanagements festzulegen. Denn auch dort besteht das Risiko, dass sich die Realität metrikoptimierend anpasst und der eigentliche Zweck der Metriken hinfällig wird.

6 Antworten zu Warum Change Requests sich so gern als Bugs tarnen…

  1. […] kein Allheilmittel sind. Auf der anderen Seite wird sich der Wasserbrauch sicher nicht gemäß Goodheart’s Gesetz verändern wenn man Zielvorgaben für den Wasserverbrauch vorgibt. D.h. das Spiel wird den […]

  2. […] ich, welche Faktoren eingerechnet werden. Aber wie bei vielen anderen Metriken auch, würde hier Goodheart’s Gesetz greifen und die Metriken in kürzester Zeit ad absurdum geführt […]

  3. Die Tendenz das Verhalten auf die Optimierung der Metrik hin zu verändern hat mir auch schon üfters verdruss bereitet. Um ganz ehrlich zu sein einen allgemeingültigen Lösungsansatz habe ich da noch nicht gefunden.

    Konkret bei den Bugs halte ich es wie Detlef Kreuz schreibt. Wenn ein „Bug“ gemeldet wird ist immer die erste Frage nach dem „Sollverhalten“.

  4. […] This post was mentioned on Twitter by Andreas Heilwagen. Andreas Heilwagen said: Warum Change Requests sich so gern als Bugs tarnen…: http://wp.me/ph8DD-1ra #pmot #pmde […]

  5. Detlef Kreuz sagt:

    Die Verantwortung von Bugs liegt insbesondere dann bei der Entwicklung, wenn die Anforderungen vorher nicht klar definiert wurden. In meiner Umgebung hat es sehr geholfen, dass bei einer Bug-Meldung die Anforderungen benannt werden mussten, die (angeblich) fehlerhaft umgesetzt wurden. Bis auf offensichtliche Bugs, natürlich. Ist nicht klar, welche Anforderung ein „Bug“ verletzt hat, wird er zu einem CR. Punkt.

    Gab natürlich eine (Lern-) Phase, in der alle wie wild herumjammerten…

    Bei agilen Projekten habe ich bisher nicht beobachten können, dass sich die Beteiligten wie beschrieben verhalten. Liegt vermutlich an den kurzen Feedbackschleifen😉

    • Das beschreibt genau das Problem, dem man immer wieder aufsitzt. Da der Kunde bei agilen Projekten eng integriert ist kann er viel früher nachsteuern, Projekte nehmen auch nicht die politischen Dimensionen an wie bei Festpreisprojekten ,-)

%d Bloggern gefällt das: