Brauchen wir das Feature wirklich?

Eine Geschichte über zwei Features in zwei verschiedenen Softwareprogrammen

Was ist das Schöne bei der Entwicklung von Software?

Sie können definieren, was Sie haben wollen. Sie definieren die Features, die Sie benötigen oder die Sie gerne haben möchten. Sie priorisieren Anforderungen und legen so fest, was Ihnen wichtiger ist und was Sie ggf. von Ihrem Entwicklungspartner als Erstes erhalten wollen. Sie schauen sich Zwischenstände an und geben frühzeitig Feedback, sodass Sie genau das erhalten, was Ihren Mitarbeitenden den meisten Nutzen bietet. Natürlich kostet das alles etwas Geld, aber in der Summe bekommen Sie ein Ergebnis, das dieses Geld wert ist.

Und was ist das Unschöne bei der Entwicklung von Software?

Sie müssen definieren, was Sie haben wollen. Und zwar so, dass Ihr Entwicklungspartner wirklich versteht, was Sie benötigen. Also bspw. korrekte, vollständige, eindeutige, widerspruchsfreie Anforderungen. Sie müssen Rückmeldungen geben, damit Ihre Mitarbeitenden Features erhalten, die leicht zu finden und zu bedienen sind. Und das müssen Sie auch tun, wenn Sie eigentlich gar keine Zeit dafür haben, weil irgendwo anders der Schuh drückt. Und natürlich kostet das Ganze auch noch Geld…

Viele Unternehmen nutzen Dienstleister oder Agenturen für die Entwicklung von Software. Für sie es es schlicht eine gute Gelegenheit, etwas zu erhalten, dass es sonst so nirgends gibt: eine passgenaue Lösung, die einen oder mehre Dienste bietet, und so das Arbeiten der Anwender deutlich erleichtert. Zu einem Preis, zu dem sie es selbst nicht herstellen können oder wollen. Idealerweise von einem Partner, der sich in die Situation des Unternehmens hineinversetzen kann und versteht, was es braucht.

Dies ist die Geschichte von zwei Features in zwei verschiedenen Softwareprogrammen.

Herr Meier hat das Unternehmen verlassen

Vor einiger Zeit erzählte mir ein Freund eine Geschichte. Er hatte mit seiner Firma an einer Ausschreibung teilgenommen. Hunderte von Anforderungen füllten unzählige Seiten. Bei jeder Anforderung wollte der Auftraggeber wissen, ob das Produkt des Lieferanten die Anforderung erfüllt und wie es funktioniert. Wir wollen X, wie unterstützt Ihre Lösung das? Wir brauchen Y, wie können Sie Y erfassen? Dann kam die Frage nach Z. Leider funktionierte Z nicht mit dem Tool. Bestenfalls mit ein paar Klimmzügen, um die Ecke gedacht und eineinhalb Augen zugedrückt.

Was sollte mein Freund tun? Was hätten Sie an seiner Stelle genacht? Hätten Sie bei der Antwort geschummelt? Oder hätten Sie klipp und klar die Wahrheit geschrieben und riskiert, an dieser Stelle aus der Ausschreibung zu fliegen? Und was hätten Sie an Stelle des Auftraggebers erwartet?

Gemeinsam mit seinen Kollegen entschied sich mein Freund für eine wohlwollende Beschreibung des Features, mit dem Z gelöst werden könnte. Es kam wie es kommen musste: die zweite Runde war erreicht. Die Präsentation stand an. Natürlich würde man auch über Z sprechen. Wie sollte man reagieren? Mit einem Augenzwinkern zugeben, dass man nicht ganz die Wahrheit gesagt hat? Erklären, dass man Z anders verstanden hatte, als es sich jetzt hier und heute darstellt? Oder erklären, dass man Z im Moment vielleicht nicht so unterstützen könne, wie er es brauche, dass dies aber in Zukunft sehr schnell möglich sein werde?

A, B und C wurden mit dem Auftraggeber besprochen. X und Y auch. Nun stand Z an. Und mein Freund sagte: “Z ist ein interessantes Feature, über das wir lange diskutiert haben. Wir sind unterschiedlicher Meinung darüber, was Sie damit genau wollen. Wer braucht denn dieses Feature von Ihnen?”

Die Beteiligten des ausschreibenden Unternehmens schauten sich gegenseitig an. Man schaute nach links, man schaute nach rechts. Wer braucht dieses Feature? Ich nicht! Du? Dann sagte einer der Beteiligten: “Ich glaube, das war eine Anforderung von Herrn Meier. Herr Meier hat vor drei Wochen das Unternehmen verlassen. Ich glaube, wir brauchen das Feature nicht mehr”.

YAGNI

Machen wir einen kleinen Sprung in die Welt der Softwareentwicklung. Dort finden Sie viele Prinzipien und Praktiken, die eine Entwicklung deutlich erleichtern. Ein solches Set an Prinzipien und Praktiken definiert die sogenannte Clean Code Entwicklung.

• Clean Code bezeichnet Code, der leicht zu verstehen, zu ändern, zu erweitern und zu warten ist.
• Prinzipien sind Grundsätze zur Strukturierung von Software. Sie ergänzen einander. Wird Software entgegen der Prinzipien entwickelt, zeigen sich die Auswirkungen spätestens mittelfristig, bspw. durch steigende Aufwände bei Anpassungen.
• Praktiken sind Handlungsanweisungen, also Methoden und Techniken, die kontinuierlich zum Einsatz kommen.

YAGNI ist ein Prinzip. Als Akronym steht es für “You Ain’t Gonna Need It”, also “Du wirst es nicht benötigen”. Es adressiert Softwareentwickler, die gerne vorausdenken und zusätzliche Funktionen programmieren, in der Annahme, diese zu einem späteren Zeitpunkt zu benötigen.

Es gibt eine Reihe von Gründen, warum Entwickler Features implementieren, die heute noch nicht benötigt werden:

• Entwickler stehen immer in dem Spannungsfeld, entweder genau das zu implementieren, was spezifiziert ist, oder über den Tellerrand hinauszuschauen und bereits den Grundstein für etwas zu legen, was in Zukunft kommen wird. (Ähnlich wie bei einem Auto: Ein Auto wird sehr wahrscheinlich nie 5 Reifen gleichzeitig zum Fahren benötigen. Trotzdem kann es sinnvoll sein, im Kofferraum einen Platz für einen Ersatzreifen vorzusehen. [1])
• Entwickler wollen den Auftraggeber mit Funktionalität überraschen. [2]
• Entwickler haben Spaß daran, eine Architektur zu entwerfen, die auf mögliche zukünftige Anforderungen vorbereitet ist.

Ein weiterer Grund für die Abweichung von YAGNI liegt im Requirements Engineering bzw. im Anforderungsmanagement. Je besser das Anforderungsmanagement funktioniert, desto weniger Aufwand entsteht durch Mehrdeutigkeit, Unvollständigkeit oder Interpretation.

Die Probleme mit nicht genutzten Features

Zurück zu Herrn Meier und der Ausschreibung. Dass Herr Meier das Unternehmen bald verlassen würde, konnte zum Zeitpunkt der Ausschreibung wahrscheinlich niemand beim Auftraggeber voraussehen. Dennoch müssen sich Unternehmen immer wieder die Frage stellen, wer braucht was und warum. Natürlich ist Software geduldig und natürlich kann man auch als Dienstleister X, Y und Z programmieren. Und nach dem YAGNI-Prinzip genau X, Y und Z. [3] Softwareentwicklung kostet aber Geld und logischerweise macht es Sinn, den Anwendern dafür den größtmöglichen Nutzen zu bieten. Wenn also nur eine Person ein Feature benötigt, kann sich ein Auftraggeber durchaus intern einigen, ob er nicht lieber ein anderes Feature in Auftrag gibt, von dem mehrere Nutzer profitieren.

Ich hatte Ihnen zu Beginn eine Geschichte über zwei Features in zwei verschiedenen Softwareprogrammen versprochen. Von Feature Z habe ich schon erzählt. Auch wenn unklar ist, was Z eigentlich macht, so ist doch relativ klar, dass (fast) niemand im Unternehmen des Auftraggebers Z nutzen wird. Eigentlich schade. Individuell spezifiziert, individuell bestellt, individuell programmiert. Geld zum Fenster rausgeworfen.

Kommen wir zum zweiten Feature meiner Ankündigung. Feature A wohnt in einem Standardprogramm, z.B. MS Excel. Es ist eines von 10.000 anderen Features. Sie nutzen es genauso wenig wie 99 Prozent der anderen Anwender des Programms. Stört Sie das? Wahrscheinlich nicht, denn wie die meisten Anwender nutzen Sie nur wenige Funktionen des Standardprogramms. Standard heißt ja nicht, dass jeder alle Funktionen nutzt, sondern dass bestimmte Funktionen standardmäßig im Programmumfang enthalten sind. Sie mussten nichts dafür tun, Sie mussten es nicht explizit bestellen und Sie mussten es nicht explizit bezahlen. Implizit aber schon. Und zwar möglicherweise nicht nur einmalig beim Kauf der Software, sondern fortlaufend durch den Wartungs- und Pflegevertrag, den Sie abgeschlossen haben. Eigentlich schade, aber im allgemeinen Kontext einer Standardsoftware in der Praxis auch irgendwie zu vernachlässigen. [4]

Wir haben jetzt also zwei Features: Z und A. Beide werden nicht verwendet. Beide werden direkt oder indirekt, explizit oder implizit bezahlt. Bei Feature A können Sie praktisch nichts machen – es ist Teil einer Standardsoftware [5] – bei Z aber sehr wohl. Hier haben Sie die Möglichkeit, YAGNI selbst anzuwenden. Hier haben Sie die Gelegenheit, mithilfe eines definierten Prozesses im Anforderungsmanagement die Anforderungen und Features zu bestimmen, die Ihnen wirklich den bestmöglichen Nutzen bringen. Und wissen Sie, was das Schöne daran ist?

Ja, nein, vielleicht

Erinnern Sie sich noch an die allererste Frage am Anfang meines Beitrags? Was ist das Schöne bei der Entwicklung von Software?

Softwareentwicklung ist in der Regel keine einmalige Sache. Ja, Sie haben einen Bedarf und definieren und priorisieren Anforderungen. Sie machen sich auf die Suche und wählen einen Entwicklungspartner aus. Sie arbeiten miteinander und manchmal gibt es im Zuge der Zusammenarbeit auch Meinungsverschiedenheiten. [6] Das Schöne ist aber: Sie nutzen eine Software, die für Ihre Situation entwickelt wurde. Die Ihren Mitarbeitenden Vorteile bringt. Die etwas kann, dass vorher nicht oder nur schwer möglich war. Und im Laufe der Zeit werden alle Beteiligten klüger.

Und warum ist das schön? Alles altert. Software auch. Irgendwann stehen Sie möglicherweise vor der Situation, eine Software zu sanieren oder sie sogar komplett zu modernisieren. Softwaremodernisierung bedeutet, eine Software an neue Anforderungen und Technologien anzupassen, um ihre Leistung, Sicherheit und Benutzerfreundlichkeit zu verbessern, Kosten und Komplexität zu reduzieren und ihre Lebensdauer, Skalierbarkeit und Flexibilität zu erhöhen. Und Softwaremodernisierung bedeutet, sich noch einmal die Frage zu stellen, ob man ein Feature Z wirklich benötigt. Hat es den Nutzen erfüllt, den Sie sich ursprünglich davon erhofft haben? Wurde es wie gedacht genutzt oder hat sich der Kontext verschoben und Z ist inzwischen unnötig. Sie haben also die Gelegenheit, sich im Zuge einer Softwaremodernisierung bei jedem Feature neu zu fragen: Brauchen wir das Feature wirklich? Ja, nein, vielleicht?

Wenn “ja”, modernisieren Sie das Feature Z. Sie haben es früher gebraucht, Sie brauchen es jetzt, prima. Bei “nein” lassen Sie es schlicht weg. Situationen ändern sich, nutzen Sie jetzt die Gelegenheit und lassen Sie Unnötiges einfach weg. Und bei “vielleicht” gehen Sie wieder in die interne Abstimmung, holen Meinungen ein und wägen ab, welches Feature stattdessen sinnvoll sein könnte.  Ist das nicht schön?

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk.

[1] Dieses nicht-technische Beispiel zeigt auch das Dilemma einer vorausschauenden Implementierung: Natürlich ist es sinnvoll, im Falle einer Panne eine Möglichkeit zu haben, einen platten Autoreifen zu ersetzen. Aber muss es ein Ersatzreifen sein oder reicht vielleicht auch ein Gasgemisch, das den Reifen für weitere 50 Kilometer fahrtüchtig macht, so dass die nächste Tankstelle oder Werkstatt angesteuert werden kann? Ergo: Eigenmächtige Entscheidungen von Softwareentwicklern sind immer mit Vorsicht zu genießen. Im Zweifelsfall sollte man die Anforderungen möglichst genau spezifizieren und auf Vollständigkeit achten.

[2] Dies wird auch als Gold Plating bezeichnet.

[3] Als Dienstleister für Softwareentwicklung versuchen wir bei t2informatik übrigens, die Motive hinter einem Feature zu verstehen. Wenn wir das Motiv verstehen, sind wir im Idealfall in der Lage, verschiedene Lösungswege zu diskutieren, die dann – aufeinander abgestimmt – zum bestmöglichen Ergebnis für den Nutzer führen.

[4] Der nicht genutzte Funktionsumfang einer Standardlösung wird in der Regel ignoriert; ist die Summe der nicht genutzten Funktionen jedoch sehr groß, könnten sich Unternehmen überlegen, auf kleinere Lösungen zu setzen, von denen sie – idealerweise für etwas weniger Geld – mehr Funktionen nutzen.

[5] Wäre doch mal lustig zu erfahren, wie Microsoft reagiert, wenn man sagt, dass man in MS Excel die Funktion zum Zusammenfügen von Inhalten verschiedener Zellen, bei der man nur die Werte und nicht die zugrunde liegenden Formeln übernehmen will, nicht als Feature benötigt, und man wissen möchte, wie hoch ein möglicher Preisnachlass wäre.

[6] Softwareentwicklung ist eine schöne Sache, aber nicht ganz einfach, und damit meine ich nicht einmal das Programmieren an sich, sondern die Verständigung untereinander. Meinungsverschiedenheiten in Projekten sind daher bis zu einem gewissen Grad relativ normal. Wichtig ist, dass man sich trotzdem zusammenrauft, um die bestmögliche Lösung zu finden. Vielleicht sprechen Sie mit uns über Ihre Situation und wie wir Ihre Wünsche und Vorstellungen umsetzen können.

Michael Schenkel hat weitere Beiträge im t2informatik Blog veröffentlicht, u. a.:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.