Laut einer Auswertung der Standish Group werden 64 Prozent aller Software-Features selten oder nie genutzt. Das ist keine Anekdote – es ist ein strukturelles Muster. Die meisten Lösungen wurden nicht gebaut, um Wert zu schaffen, sondern um keine Anforderung zu vergessen. Das Ergebnis: aufgeblähte Systeme, die viel können und wenig bewegen.
Wie wir die zwei, drei Stellschrauben finden, die wirklich zählen, warum „schlank" am Ende schneller und günstiger ist, und was eine fokussierte Lösung konkret bewegt – darum geht es hier.
Der Feature-Reflex – und warum er teuer wird
Wenn ein Prozess hakt, ist der erste Impuls, möglichst viel abzudecken: jede Ausnahme, jeder Sonderfall, jedes „das brauchen wir vielleicht auch noch". Das Ergebnis ist ein System, das alles kann und nichts richtig. Und Komplexität ist nicht gratis: Jede zusätzliche Funktion ist eine weitere Stelle, die Fehler machen kann, die geschult werden will und die Nutzer im Alltag eher ausbremst als unterstützt. Was selten benutzt wird, wird auch selten verstanden.
Die Zahlen zu diesem Reflex sind ernüchternd. In einer viel zitierten Auswertung der Standish Group werden rund 64 Prozent der Funktionen einer typischen Unternehmensanwendung „selten" oder „nie" genutzt – nur etwa 20 Prozent kommen häufig oder immer zum Einsatz. Der größte Teil dessen, was gebaut wird, zahlt also nie auf den Nutzen ein.
Kostenlos ist dieser Ballast trotzdem nicht. Jede Funktion, die du baust, musst du auch pflegen, testen und mitschleppen – im Bau einmal, in der Wartung dauerhaft. Schlank zu bauen heißt deshalb nicht, zu sparen. Es heißt, sich auf das Wirksame zu konzentrieren und den Rest bewusst wegzulassen.