Was macht Softwareentwicklung erfolgreich? Das richtige Ding!

Für wen entwickeln wir Software? Entspricht sie wirklich den Bedürfnissen der Nutzer? Diese Fragen müssen sich Softwareentwickler immer wieder stellen. Denn nicht selten scheitert Software, weil sie schlichtweg an den Bedürfnissen der Benutzer vorbeientwickelt wurde. Weil die Kommunikation nicht funktionierte oder nicht optimal zusammengearbeitet wurde und es deshalb zu Missverständnissen kam. «Software kann noch so gut funktionieren oder einfach erlern- und bedienbar sein – wenn sie nicht die Bedürfnisse des Nutzers abdeckt, war die ganze Produktentwicklung für die Katz», erklärt Urs Enzler, Fachleiter agile und Architektur bei bbv. «Deshalb betone ich es hier nochmals: Frühes Feedback ist extrem wichtig.»

Entwickler müssen sich immer wieder vergewissern, dass sie mit ihrem Produkt in die richtige Richtung gehen. Dies lässt sich mit Prototypen oder Beta-Usern validieren. Auch die Art und Weise, wie mit Stakeholdern und potenziellen Benutzern zusammengearbeitet wird, ist für eine erfolgreiche Produktentwicklung zentral: «Solange man nur über die Software-Anforderungen spricht, ist alles sehr abstrakt», erklärt Enzler. «Je handfester die Fortschritte in der Softwareentwicklung präsentiert werden können, desto besser.» So bietet es sich etwa nur schon an, den Prototyp der Software auf Papier aufzuzeichnen. Ein weiterer Schritt wäre ein Wireframe, also ein erster konzeptioneller Entwurf der Software. Bei der Entwicklung sollte schon möglichst früh der Haupt-Use-Case programmiert und zur Beta-Nutzung bereitgestellt werden. Nur dann, wenn die Software in dieser Form dem Nutzer bereits Arbeit abnimmt, können die Entwickler mit dem Programmieren fortfahren.

«Gold Plating» ist nicht zielführend

Damit das gelingt, müssen viele Entwickler umdenken. «Viele Softwareentwickler sterben gerne in Schönheit und betreiben das sogenannte ‚Gold Plating’: Über den eigentlichen Use-Case hinaus möchten sie oft noch zahlreiche weitere Features einbauen», stellt Enzler fest. «Das sollte erst zu einem späten Zeitpunkt kommen – wenn überhaupt.» Entwickler sollten mit minimalem Aufwand herausfinden können, ob sie auf dem richtigen Weg sind oder nicht.

Das ist leichter gesagt, als getan. Noch immer messen Entwicklungsteams, wie viele Features sie liefern können – «Je mehr, desto besser» lautet die Devise. Sinnstiftender wäre es aber, zu messen, wie viele Probleme des Nutzers man tatsächlich gelöst hat. Das bedeutet: Entwickler müssen erkennen, dass sie keine Wissenshoheit besitzen. «Wir müssen uns eingestehen, dass wir nur mit Hypothesen arbeiten», erklärt Enzler. «Wir stützen uns bloss auf die Annahme, dass die Software auch wirklich das Problem des Users löst – wissen tun wir es erst, wenn der Benutzer dies den Entwicklern bestätigt. Im Idealfall festigt sich die Hypothese, je länger wir am Produkt arbeiten. Ist das nicht der Fall, sollte man sie besser wieder verwerfen.»