Follow my new blog

Dienstag, 30. Juli 2013

Was der Softwarekunde will

Wer Software kauft, kauft ein Werkzeug. Das tut er, weil er die Effizienz des Anwenders steigern will.

Alles, was Software tut, kann auch ohne Software getan werden. Wir brauchen Software also nicht für ihre funktionalen Eigenschaften. Stoffe wurden ohne Software gewoben, Logarithmen wurden ohne Software berechnet, Auktionen ohne Software durchgeführt, Rechnungen ohne Software geschrieben usw. usf.

Mit genügend Zeit, Platz, Geld kann man sozusagen Software simulieren.

Das bedeutet: Software wird nicht wegen ihrer Funktionalität geschrieben, es geht also nicht um Effektivität. Software wird vielmehr wegen ihrer nicht-funktionalen Eigenschaften geschrieben. Dafür wird Software gemacht. Ausschließlich.

Nicht-funktionale Anforderungen sind allerdings nicht alle gleich. Es gibt primäre und sekundäre.

Primär sind die nicht-funktionalen Anforderungen, die Software etwas besser tun lassen, als die Alternative. Meist ist die langsamer oder umständlicher oder hat weniger Reichweite. Dann geht es bei Software um Performance, Usability oder Skalierbarkeit.

Sekundär sind die nicht-funktionalen Anforderungen, die Software auch noch erfüllen muss, die aber nichts mehr mit der Alternative zu tun haben. Wenn eine Software schneller als ein Mensch rechnen soll, dann ist Sicherheit ein sekundärer Aspekt. Wenn Software es leichter machen soll, Überblick über Zahlen zu behalten, dann ist Portierbarkeit ein sekundärer Aspekt.

Noch genauer wird Software also wegen ihrer primären nicht-funktionalen Eigenschaften geschrieben. Welche das in Ihrem Projekt/Produkt sind, können Sie ja mal überlegen.

Diese Feststellung hat schon eine Auswirkung auf die Praxis. Aus ihr ergibt sich, dass vordringlich und im Zweifelsfall Aufwand in primäre nicht-funktionale Anforderungen investiert werden sollte.

Nicht-funktionale Eigenschaften gibt es nicht ohne funktionale. Sie sind die Adverbien zu diesen Verben: schnell rechnen, übersichtlich darstellen, verlässlich speichern. Und das sogar im Komparativ, da es ja um eine Steigerung gegenüber der Alternative geht, also: schneller rechnen, übersichtlicher darstellen, verlässlicher speichern.

Nicht-funktionale Eigenschaften und funktionale sind auf Augenhöhe. Kunden suchen Effizienz und Effektivität. Nicht die Pyramide ist daher das erste Bild, das in den Sinn kommen sollte:

image

Es geht vielmehr um einen Kreis für das Ganze, dessen Teile gleichberechtigt sind:

image

Soweit das recht Offensichtliche. Ich glaube aber, dass sich damit nicht das komplette Kundenverhalten erklären lässt. Der Kunde will mehr.

Haltbarkeit ist Wandelbarkeit

Wer in Werkzeuge investiert, der erhofft sich, dass mehr herauskommt, als reingesteckt wurde. Der Nutzen soll größer sein als die Investition. Die Wahrscheinlichkeit dafür steigt mit der Nutzungsdauer.

Dieser Gedanke ist sogar so wichtig, dass er in der Steuergesetzgebung Niederschlag gefunden hat. Abschreibungsdauern richten sich nach üblichen Nutzungsdauern.

Neben den funktionalen und primären nicht-funktionalen Eigenschaften hat der Käufer einer Software also immer auch ihre Haltbarkeit im Hinterkopf. Die Investition soll sich auszahlen.

Eine Batterie soll Wochen oder Monate nutzen, ein Auto Jahre, ein Flugzeug Jahrzehnte, ein Sakralbau Jahrhunderte.

Wer Geld ausgibt, der hat immer eine Wunschvorstellung von der Haltbarkeit des Erwerbs. Er wird sich also mit dem Verkäufer darüber explizit unterhalten bzw. anderweitig etwas über die Haltbarkeit des “Objektes seiner Begierde” in Erfahrung bringen.

Zum obigen Kreis der Anforderungen kommt deshalb ein “Tortenstück” hinzu:

image

Es wäre ja töricht anzunehmen, dass Käufer von Software nicht auf Haltbarkeit achten würden. Für sie ist Software ein Werkzeug wie ein Bohrer oder ein Bagger.

Nun ist es aber so, dass Software zwar ein Werkzeug ist, aber ein immaterielles. Dadurch verschiebt sich die Bedeutung von Haltbarkeit.

Haltbarkeit in der materiellen Welt hat etwas mit Unveränderlichkeit, Erhalt, Konstanz zu tun. Ein Messer, Fenster, Auto ist umso haltbarer, je weniger es sich über die Zeit und mit Gebrauch verändert. Weniger Verschleiß bedeutet längere Haltbarkeit und damit höhere Investitionssicherheit.

Jedenfalls war und ist das gewöhnlich so. Denn es gibt auch materielle Werkzeuge, bei denen die Haltbarkeit weniger mit Verschleiß zu tun hat. Mir fällt da z.B. ein Handy ein. Dessen materielle Haltbarkeit ist weit höher als seine immaterielle. Allemal, wenn wir von geplanter Obszoleszenz absehen. Ich könnte immer noch mit meinem ersten Handy aus dem Jahr 1998 telefonieren.

Aber ich will das nicht. Es hat nämlich nicht Schritt gehalten mit der Entwicklung. Ich habe heute andere Ansprüche an ein Handy.

Unveränderlichkeit ist von Wert, wenn sich die Einsatzwelt eines Werkzeugs über die Zeit seiner materiellen Haltbarkeit nur geringfügig ändert. Deshalb tun wir bei Messern, Bohrern, Autos etwas gegen Verschleiß.

Dadurch verschiebt sich ebenfalls die Bedeutung von Haltbarkeit von Software. Denn die Einsatzwelt von Software ist in den meisten Fällen starken Veränderungen unterworfen. Das ist der Fall, weil Software in vielen Fällen weniger Werkzeug in einem Prozess, sondern vielmehr selbst die Definition eines Prozesses ist. Je größer ein Softwaresystem, desto eher ist das der Fall.

Die Haltbarkeitsdauer, d.h. die Zeit, in der ihr Nutzen höher als die Kosten ist, ist bei Software deshalb eine Funktion ihrer Anpassungsfähigkeit. Haltbar ist Software, die sich über lange Zeit leicht Veränderungen in der Einsatzwelt nachführen lässt.

Bei Software gibt es also keine Wartung wie bei materiellen Werkzeugen. Es geht eben nicht um den Erhalt von Eigenschaften. Von Softwarewartung zu sprechen und Wartungsverträge anzubieten, ist aus meiner Sicht grob kontraproduktiv. Denn dadurch wird ein völlig falsches Bild von Software transportiert. Es werden auch die falschen Signale an die Softwareproduktion gesandt.

Kunden erwarten Haltbarkeit. Denn ohne Haltbarkeit keine Investitionssicherheit. Doch diese Haltbarkeit hat eben nichts mit Erhalt heutiger Eigenschaften zu tun, sondern mit der Fähigkeit zum Wandel von Eigenschaften. Das müssen wir Kunden deutlich machen. Wir müssen ihnen explizit Wandelbarkeit [1] verkaufen. Ohne Wandelbarkeit keine Haltbarkeit. Wir müssen Wandelbarkeit auf Augenhöhe mit Funktionalität und primären nicht-funktionalen Eigenschaften sehen:

image

Wandelbarkeit ist nicht nice to have, sondern zentral. Wandelbarkeit ist keine Eigenschaft, die sich später hineinrefaktorisieren lässt. Wandelbarkeit ist auch wichtiger als sekundäre nicht-funktionale Eigenschaften.

Wenn Software ein nutzbringendes Werkzeug sein und lange bleiben soll, dann muss sie auf das Dreibein Effizienz, Wandelbarkeit und Effektivität gestellt werden. Das ist genau das, was der Kunde will - ob er das so klar ausspricht oder nicht.

Endnoten

[1] Mit Wandelbarkeit meine ich natürlich nicht, Software zwanghaft mit Plug-Ins auszurüsten. Was ich unter Wandelbarkeit verstehe, geht tiefer. Sie ist auf allen Abstraktionsebenen ins Softwaresystem gewoben. Sie hat mit grundlegenden Prinzipien zu tun.

Kommentare:

Hannes Preishuber hat gesagt…

Mit diesem Post hast Du dich soweit vom Kunden entfernt, wie die Raumsonde Voyager 1 von der Erde. Ich bin da so polemisch, weil es genug Leute gibt, die mir Tag für Tag erzählen was ich will. "Das ist genau das, was der Kunde will - ob er das so klar ausspricht oder nicht."

Ich will von meiner Software sowenig wie von meinen Auto das es wandelbar ist. Es soll kein Autobot draus werden, wenn ich an der roten Ampel stehe.
Es soll tun, wofür ich es verwenden möchte und zwar jetzt und zügig (das tut Software leider häufig nicht) ich möchte keine Metamorphose per Update in neue und bessere Software. Und wenn man den 100 Millionen Apple Kunden folgt, wollen sie das auch nicht. Die kaufen sich DING und denken weder an wie lange man DING verwenden möchte noch an potentiellen Multiuse von DING. Eigentlich sollte unisono Einigkeit herrschen, das Abhängigkeiten ein erhöhtes Risiko bedeuten. Also weg damit und nicht noch weitere virtuell ins Projekt reindiskutieren.

Ralf Westphal - One Man Think Tank hat gesagt…

Danke, Hannes, für diese Steilvorlage. Du sprichst wie der typische Kunde. Ich hab ja gesagt: Der will Wandelbarkeit, ob er es weiß oder nicht. Du verhältst dich wie ein Kunde, der das nicht weiß.

Erstens ist natürlich zu unterscheiden zwischen Projekten und Produkten. Du spricht von Produkten. Ich habe eher auf Projekte angespielt.

Aber auch bei Produkten, die nicht für einen Kunden, sondern womöglich Tausende entstehen, gibt es "den Kunden" als "Durchschnitt" der tatsächlichen bzw. gewünschten Kunden.

Und dieser "Überkunde", die Legion, die will, dass sich das Produkte wandelt. Das mag dem einen oder anderen konkreten Kunden nicht schmecken - aber die Legion findet das gut und wächst nur dadurch.

Ohne Wandel gibt es keine Bug Fixes. Ohne Wandel gibt es auch keine neue Funktionalität. Und die findest du in jeder App in einem App Store früher oder später. Schau dir einfach an, wieviele Apps um Aktualisierung auf deinem iPhone/Android Phone betteln nach 1 Woche oder 1 Monat. Das tun sie, obwohl du selbst wahrscheinlich keinen Bug Report geschrieben hast.

In einer Hinsicht sind die Smartphone Apps aber besonders. Da sie im Vergleich zu Desktop-Software oft sehr klein, fokussiert sind, ist es tatsächlich so, dass der Wandel dort nicht unbedingt innerhalb einer App stattfinden muss, sondern über Apps hinweg. Das ist dann ein Stück wie bei Autos oder Fernsehern.

Als App-Nutzer hole ich mir heute die Foto-App X und in einem halben Jahr die Foto-App Y und dann Z usw. Meine Nutzungswünsche wandeln sich - aber mich interessiert nicht so sehr, ob die bisherige App sie erfüllt. Weil die Kosten so gering sind und weil das Angebot so groß ist, bin ich gewillt, eine Evolution über Modelle und Hersteller mitzumachen. Außerdem sind Apps individueller im Einsatz als Desktop-Anwendung in Unternehmen.

Ich bin ganz klar für den Weg der Apps. Also: Große Anwendungen zerschlagen in kleinere, die sich weniger verändern müssen. Stattdessen kann man sie leichter ersetzen. Rewrite over refactor.

Auf einer höheren Abstraktionsebene ist das aber weiterhin Wandelbarkeit eines Softwaresystems. Nur ist dessen Struktur anders.

Abhängigkeiten? Klar, die sind immer schlecht. Aber ich weiß nicht, wo du das Gegenteil aus meinem Artikel gelesen hast. Ich will keine "reindiskutieren" - und das weißt du, wenn du nur ungefähr verfolgst, was ich schreibe.

stmon hat gesagt…

Es wird etwas nach Vorgabe erstellt, was passt (oder auch nicht)... aber klassisch nach Wilhelm Busch
"Ein jeder Wunsch, wenn er erfüllt, // Kriegt augenblicklich Junge."

Das Problem des Kunden ist, dass ihm selten bewusst ist, dass ein Projekt im Rahmen der Software-Entwicklung auch ein wissen-erzeugender Prozess ist.

Für mich gibt's im Kopf die Umsetzungen z.B. "Kommt selten vor -> Standard-Fall", "Kommt nie vor -> bei nächster Gelegenheit", "Immer -> einmal" usw.

Und m.E. ist es genau dies, was immer im Hinterkopf sein sollte; was passiert, wenn sich der Kunde umentscheidet?

Was passiert, wenn dies nicht berücksichtigt wird, wurde ja bei der Keynote auf der DWX schön eruiert (ich fand den Vergleich drastisch aber nicht schlecht :)

Kurz, warum sollte ich mir einen Stein (oder Monolith :) ans Bein binden, wenn's nicht sein muss?!

PS: Mir hatte der Begriff "Evolvierbarkeit" etwas besser gefallen.