Haben Sie zu viel Geld?

Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?

Um das Thema „Verschwendung“ soll es heute in diesem Blog gehen. Ich skizziere verschiedene Arten von Verschwendung und zeige Wege, diese zu vermeiden.

Gerade im klassischen RE-Umfeld findet man die Tendenz, extrem detaillierte und umfangreiche Spezifikationen zu erstellen – dabei kann die Spezifikation an sich bereits als Verschwendung gesehen werden, denn für den Kunden stellt sie keine nutzbare Funktionalität dar. Oder hat zu ihnen schon einmal am Ende ihres Projekts ein Kunde gesagt „Gut, das Produkt ist nicht fertig geworden, aber dafür haben wir eine tolle Spezifikation!“? Somit sollte man sich vor allem auf die Anteile der Spezifikation konzentrieren, die aktuell wichtig sind und folglich einen direkten Nutzen darstellen. Es gilt also der Leitsatz: „Spezifiziere so wenig wie möglich, und so viel wie nötig!“.

Ein eng damit verknüpftes Problem stellen sog. Extra-Features dar. So mancher Spezifikateur findet kein Halten mehr, sollte er einmal in Fahrt kommen. Die Folge ist die absolute Überspezifikation: eine Spezifikation aller nur erdenklichen Details, die ein realer oder eventuell sogar nur potentieller Kunde benötigen KÖNNTE! Schlimm genug, dass diese Extra-Features gehörigen Aufwand bei der Spezifikation erzeugt haben – wenn dies niemandem auffällt, werden diese Funktionalitäten auch entwickelt und getestet. Die Verschwendung ist perfekt. Dem kann durch das frühe Einholen von Feedback und enge Zusammenarbeit mit dem Kunden entgegengewirkt werden.

Eine weitere Art der Verschwendung sind klassische Flaschenhälse. Es entstehen Verzögerungen, weil großangelegte Reviews zum einen viel Zeit rauben, zum anderen aber auch schwer planbar sind. Es besteht die Gefahr, alles in einem Abwasch erledigen zu wollen. Entwickler, Architekten, Tester, Analysten, die Qualitätssicherung – all diese Rollen und weitere werden zu einem umfangreichen Review eingeladen, welches womöglich erst in ferner Zukunft stattfinden kann, weil es nicht ohne weiteres möglich ist, die Terminpläne aller Beteiligten in Einklang zu bringen. Derartige „Monster“-Termine sind unnötig, und sollten durch kleine, agile Meetings mit weniger, aber dafür relevanten Beteiligten abgelöst werden, welche dafür kontinuierlich stattfinden. Nichts ist teurer, als eine ganze Entwicklungsabteilung zur Untätigkeit zu verdammen, weil diese ohne wichtiges Feedback nicht weiterarbeiten kann.

Auch an Schnittstellen entsteht unnötiger Aufwand und somit Verschwendung. Beim Erstellen einer Spezifikation wird oftmals nicht ausreichend an den Empfänger gedacht. Bei der Übergabe kommt es dann zu Missverständnissen. Anforderungen werden entweder falsch interpretiert oder werden überhaupt nicht verstanden. Ein Beispiel ist hier die Beziehung zwischen Systemanalyst und Tester: wenn der Systemanalyst nicht direkt bei der Erstellung jeder einzelnen Anforderung den unausweichlichen Test ebendieser Anforderung im Hinterkopf hat, sind Probleme vorprogrammiert. Ein anderes Beispiel ist das Verhältnis zwischen Systemanalyst und Entwickler: nur, wenn die Anforderungen eine hohe Qualität aufweisen und keinen Interpretationsspielraum zulassen, kann gewährleistet werden, dass diese vom Entwickler auch korrekt umgesetzt werden.

Eine sehr teure Art der Verschwendung sind Fehler im fertigen Produkt. Auch, wenn genauestens gemäß Spezifikation entwickelt wurde, hilft alle Sorgfalt nicht, wenn die Ursache des Produktfehlers in einer fehlerhaften Spezifikation zu finden ist. Stellen Sie sich vor, Sie entwickeln Einzelanfertigungen mit hohem Hardwareanteil, und stellen erst nach Auslieferung und Einrichtung ihres Produkts fest, dass ein grundlegendes Feature fehlerhaft implementiert wurde. Derart kostspielige Peinlichkeiten verhindern Sie durch frühes Feedback und enge Zusammenarbeit mit ihrem Kunden im Voraus.

Das folgende Problem dürfte ihnen sicherlich bekannt vorkommen. Sie starten ihren Tag mit der Abarbeitung ihrer Emails. Leider haben Sie nur 30 Minuten Zeit, danach steht ein Regelmeeting für Projekt X im Kalender. Dieses müssen Sie frühzeitig verlassen, denn ihre Expertise wird auch in Projekt Y sehr geschätzt. Sie hetzen also zum nächsten Termin. Puh, Mittagspause. Danach könnten Sie sich wieder ihren Emails widmen. Sofern ihr Chef nicht bei ihnen am Platz steht und sie dazu „überredet“, doch bitte den Nachmittag damit zu verbringen, im gerade sehr dringenden Projekt Z auszuhelfen. Leider ist diese Art der Arbeitsorganisation ein weit verbreitetes Problem. Durch ständigen Wechsel der Aufgaben entstehen hohe Reibungsverluste. Mehrmals am Tag ist es erforderlich, sich in neue Themen einzuarbeiten. Dem können Sie nur mit einer klaren Projektorganisation entgegenwirken. Im Idealfall schließen Sie ein Thema vollständig ab, bevor Sie sich dem nächsten widmen.

Abschließend möchte ich noch auf das Problem des Wieder-Erlernens eingehen. Leider ist es in vielen Projekten an der Tagesordnung, dass zwischen Spezifikation,  Implementierung, Integration und Test eine große Zeitspanne liegt. Während die Details einer bestimmten Funktionalität für den Spezifikateur längst in Vergessenheit geraten sind, sind diese für den Tester womöglich hochaktuell und werfen Fragen auf. Damit der Spezifikateur dem Tester also weiterhelfen kann, muss er sich in das Thema erneut einarbeiten. Bei dieser Art der Verschwendung haben wir auch einen direkten Bezug zu vorhergenannten, dem ständigen Wechsel der Aufgaben. Des Weiteren entsteht für den Tester eine Verzögerung, weil er ohne das Feedback des Spezifikateurs womöglich nicht weiterarbeiten kann.

Wir sehen, dass es vielfältige Arten der Verschwendung gibt, und ich bin mir sicher, dass ihnen ein Großteil dieser im Arbeitsalltag bereits begegnet ist – oder sie aktuell nach wie vor plagt. Was mich wieder an den Anfang dieses Blogs zurückführt:

Haben Sie denn eigentlich zu viel Geld?

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.