Share ZU:
12 May 2015 @ Marcel Klein

Vertrauen ist gut, Kontrolle ist besser!?

Ist es in ihrem Unternehmen auch völlig normal geworden, dass jede scheinbar noch so unbedeutende Kleinigkeit ausgewertet und analysiert wird? Gibt es auch bei ihnen einen Mitarbeiter, der nichts anderes tut, als seine Kollegen zu überwachen? Diesen Trend  hin zu immer mehr Kontrolle und Statistiken beobachte ich seit einiger Zeit mit wachsender Besorgnis – denn diese metrikgetriebene Entwicklung hat einen erheblichen Einfluss auf den Arbeitsalltag aller Entwicklungsbeteiligten. Lesen Sie hier, warum sich das titelgebende Sprichwort nicht immer bewahrheitet.

Ich vertrete den Standpunkt, dass Metriken bis zu einem gewissen Punkt ihre Daseinsberechtigung haben und auch wertvollen Input zur Projektanalyse liefern. Zum Beispiel ist es wertvoll, zu wissen

  • wie viele Anforderungen noch im Status „In Arbeit“ sind,
  • wie viele Anforderungen bereits mit einem Testfall verlinkt sind oder
  • wie viele Kundenanforderungen bisher noch nicht durch Systemanforderungen abgeholt sind.

Problematisch wird es, wenn Metriken nicht nur das große Ganze, sondern auch noch das kleinste Zahnrad in der Produktentwicklung überwachen. Man muss sich stets bewusst sein, wer von einer Metrik profitiert. Die Erfahrung zeigt, dass vor allem einfache (und damit leicht verständliche) Metriken einen hohen Nutzwert sowohl für das Management, als eben auch für alle anderen Projektbeteiligten haben. Je komplexer die Metrik wird, desto weniger Mehrwert liefert sie im Projektalltag – und wird zum reinen Managementwerkzeug. Nur: Ist die Zeit für die Entwicklung, die Durchführung und die Analyse der Metrik gut investiert? Wäre es nicht vielleicht sinnvoller, diese Energie direkt in die Produktentwicklung fließen zu lassen? Dies ist ein schmaler Grat und diese Problematik sollte stets im Hinterkopf verbleiben.

Der zeitliche Aspekt (und damit der Kostenaspekt) darf also nicht unterschätzt werden. Die Konzeption, Erstellung, Auswertung und Verwaltung komplexerer Metriken kann durchaus in Stunden, und nicht mehr in Minuten, gemessen werden. Zeit, die der eigentlichen Produktentwicklung nicht mehr zur Verfügung steht.

Als eine Ursache, oder zumindest begünstigend, sehe ich die Verwendung datenbank- / tabellenbasierter Anforderungsmanagementwerkzeuge. Es besteht die Gefahr, sich zu ausufernden Metriken hinreißen zu lassen, einfach weil es leicht möglich ist. Der Fantasie bei der Erstellung einer vermeintlich noch unbedingt notwendigen Metrik sind kaum Grenzen gesetzt.

Je komplexer eine Metrik ist, desto eher hat sie ihren Ursprung im Management. Sicherlich gab es bei der Erstellung jeder Metrik einen vermeintlich wichtigen Zweck. In letzter Zeit stelle ich aber immer öfter fest, dass Metriken ausgehebelt werden. Ein Beispiel aus dem Projektalltag:

Das Projektteam ist überfordert, und das schlägt sich auch in den Anforderungsdokumenten nieder. Das Management versorgt alle Projektbeteiligten mit ausufernden  Metriken – alle noch so kleinen Missstände werden aufgedeckt. Der eigentliche Zweck der Metriken wäre nun, Probleme hervorzuheben und transparent zu machen, wo es im Projekt hakt. Doch was geschieht in Wirklichkeit?

Die Metrik hat z.B. gezeigt, dass noch unverhältnismäßig viele Anforderungen im Status „In Arbeit“ sind. Sinnvoll wäre es nun, die Ursache dieses Umstands zu analysieren und abzustellen. Stattdessen werden jedoch die Anforderungen derart angepasst, dass sie von der Metrikauswertung nicht mehr erfasst werden. Anforderungen werden ohne weitere Prüfung auf den Status „Akzeptiert“ gesetzt – um der Metrik zu genügen und keine Managementattention zu generieren.

Der Status der Metrik ist nun also wichtiger geworden als der Status des betrachteten Entwicklungsartefakts. Über das Zurechtbiegen der Metrik wird mehr gesprochen als über die Anforderungen selbst. Spätestens an diesem Punkt sollte jeder Befürworter des Metrikkonzepts umdenken und die Reißleine ziehen, denn so profitiert niemand davon.

Ich denke, ich konnte aufzeigen, dass Metriken einen durchaus wertvollen Beitrag zur Projektbewertung leisten können – solange Metriken einen konkreten Nutzen generieren und deren Ergebnisse auch ohne Sorge akzeptiert werden. Denn nur dann kann es Raum für Verbesserungen geben.

Marcel Klein

Kontaktieren Sie Marcel Klein

Marcel Klein arbeitet bei der HOOD GmbH als Consultant und als Trainer im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Prozessverbesserung sowie die Erstellung von objektorientierten Modellen. Als Trainer hat er sich vor allem auf die gute Formulierung textueller Anforderungen und die nachhaltige Etablierung von Requirements Engineering in einem Unternehmen spezialisiert. Er veröffentlicht regelmäßig zu beiden Themen Artikel und Blogs.