“Komplexes soll einfach aussehen” - Herausforderungen bei Software-Entwicklung [Interview]

Moderne Software wie blink.it ist für dich als Nutzer vor allem eines: Einfach. Einfach zu bedienen. Einfach zu verstehen. Doch hinter “Software as a service” steckt viel Konzeptarbeit. Product Owner David gibt einen Einblick in die Entwicklung der Lernplattform blink.it - zwischen Kundenwünschen, Priorisierung und Vision.

 Software ist nicht gleich Software. Was sind denn die größten Besonderheiten bei einem “Software as a service”-Konzept wie blink.it im Vergleich zu klassischer Software?

Klassisch wurde Software auf CD oder DVD veröffentlicht. Und die Version, die da drauf war, musste passen. Heutzutage hat sich das auch etwas aufgeweicht, es sind Updates möglich. Aber das was der Kunde auf seinem PC installiert, ist erstmal die Endversion einer Software, die der Kunde einmalig bezahlt.

Hingegen wird Software as a service dauerhaft in kleinen Schritten weiterentwickelt und stetig verbessert. Und im Unterschied zur CD-Software installiert der Kunde eben keine Software, sondern einen Browser, und verwendet die Software auf dem Server des Anbieters. Die Software ist als Internetservice gegen einen Mietbetrag verfügbar.

 Was sind die größten Herausforderungen für dich als Product Owner bei der entwicklung von blink.it als Software-as-a-service?

Die erste Herausforderung ergibt sich schon aus der Besonderheit: Die Software muss auf allen möglichen Browsern laufen. Auch diese Browser werden ja laufend weiterentwickelt, daher muss auch die Software laufend angepasst werden, damit alles funktioniert. Ähnlich ist es auch mit den Diensten, die auf dem Server laufen. Alles wird ständig von vielen Parteien weiterentwickelt. Das erfordert stetige Weiterentwicklung um kompatibel zu bleiben. Das ist aber hauptsächlich eine Herausforderung für das Entwicklerteam. 

Die zweite Herausforderung und eigentlich die erste und größte in meiner Rolle, ist die Produktvision. Was wollen wir mit der Software blink.it eigentlich erreichen? Beispielsweise kann so eine Vision sein “Wir wollen effektives Lernen so einfach machen wie möglich” oder “Das Tool mit dem sich Online- und Präsenzunterricht für alle Beteiligten am einfachsten verbinden lassen.”  –Auch die Vision kann sich sich mit der Zeit und den Kundenwünschen mitentwickeln.

Die dritte Herausforderung in der Rolle als PO ist die ständige Entscheidung und Priorisierung: Wann soll was entwickelt werden? Und welche Auswirkungen hat das an anderen Stellen? Es kommen so viele Ideen und Wünsche rein, intern sowie von den Kunden selbst. Die Entscheidung FÜR eine Entwicklungsoption ist gleichzeitig auch immer die Entscheidung GEGEN viele andere. Die Optionen sind quasi unendlich. Jede Entscheidung betrifft unterschiedliche Personen auf ganz unterschiedliche Weise.

 Wie wählst du denn die Features aus, die tatsächlich in die Software kommen?

Hier treffen sich die Vision und die Priorisierung: Von den vielen Optionen die es gibt – welche trägt jetzt gerade und in Zukunft am besten dazu bei, dass möglichst viele Nutzer diesem Ziel am nächsten kommen? Ergänzend erfolgt eine klassische Nutzen-Aufwand-Abwägung. Wir wollen idealerweise die Schritte gehen, die bei kleinstem Aufwand den größten Nutzen stiften.

Dabei ist die Entscheidung nie “ja” oder “nein”, sondern im Prinzip “jetzt” oder “nicht jetzt”. Nur, weil ein Feature-Wunsch eines Kunden nicht jetzt umgesetzt wird, heißt es nicht, dass er nie umgesetzt wird. Vielleicht einfach nur später. Das kann im Backlog bleiben, also in unserer großen Ideensammlung. 

Gleichzeitig kann es auch heißen, dass eine Idee wartet während immer wieder neue Ideen den Vorzug erhalten - “nicht jetzt” kann also auch für immer sein. Das ist nicht immer leicht zu handhaben und oft noch schwieriger zu vermitteln. Das Ziel ist dabei: Jetzt immer das sinnvollste zu tun. Dann haben wir das Beste aus den Möglichkeiten gemacht.

So läuft die Auswahl der Entwicklungsmöglichkeiten der blink.it-Lernplattform ab. / Eigene Darstellung

Manche Dinge sind auch so essentiell für spätere Entwicklungen, dass wir sie machen müssen, auch wenn sie jetzt gerade nichts Neues bringen. Beispielsweise das neue Design für blink.it, das wir aktuell entwickeln: Das bringt erstmal kaum neue Features für die Kunden. Aber mit dem neuen Design bauen wir die ganze Infrastruktur darunter um, die die Kunden gar nicht sehen. Und diese neue Struktur brauchen wir für die vielen neuen Funktionen in der Zukunft, und um anpassungsfähig zu sein und uns mit unserer Vision zu entwickeln!

 Zu blink.it kommen laufend viele Wünsche von Kunden, und auch die Nachfrage, warum die Umsetzung so lang dauert. Woran liegt das?

Von unseren Kunden kommen großartige Vorschläge und Wünsche, die ich wirklich sehr wertvoll finde! Am liebsten würde ich viele davon direkt umsetzen. Würden wir sie JETZT umsetzen, wären sie allerdings in der alten Infrastruktur und im alten Design. Das blockiert dann wieder die Entwicklung in die Zukunft.

Also stellen wir gerade leider viele dieser Wünsche erstmal zurück - wie gesagt, sie gehen nicht verloren. Und bauen erstmal die neue Basis. DANN können wir die Wünsche direkt mit der neuen Technologie umsetzen. Das spart auch einfach sehr viel zusätzliche Arbeit, alles zu entwickeln, um es dann für’s neue Design noch mal komplett anzupassen.

"Wir suchen immer nach dem “Sweetspot” zwischen Aufwand, Nutzen und Vision."

Und auch dann wird wieder nach Nutzen und Aufwand priorisiert. Wie erwähnt, sind das Entscheidungen in einem komplexen Umfeld. Und das Ziel ist immer, die ideale Balance zu finden, den “Sweetspot” zwischen Aufwand, Nutzen für die Kunden und Produktvision.

 Du sagst, SaaS wird in vielen kleinen Schritten entwickelt. Wie läuft denn ein solcher “kleiner Schritt” bei blink.it ab und was macht ihn so komplex?

Zunächst einmal ermitteln wir für jede Idee das spezifische Ziel, das unsere Nutzer damit erreichen können. Dafür braucht es auch viel Einfühlungsvermögen. Gemeinsam mit den Designern und Entwicklern, muss ich genau verstehen und formulieren, was der Nutzer erreichen möchte. Dafür ist es wichtig sich in unsere Kunden und ihren Alltag mit der Software hineinzuversetzen. Manches davon können wir aus uns heraus klären und oft erfahren wir das durch Rückfragen.

Mit dieser Zielsetzung im Gepäck, versuchen wir einzuschätzen, welchen Nutzen es bringt und welche Ressourcen wir dafür benötigen. Dazu versuchen wir gemeinsam die Komplexität einzuschätzen. Dabei vergleichen wir unterschiedliche Entwicklungsoptionen. Priorisiert wird schließlich auf der Basis von Nutzen und erforderlichen Ressourcen. Wir haben dann eine Reihenfolge, in der wir die Ideen abarbeiten wollen.  

"SaaS-Entwicklung ist die Verbindung von Empathie für die Kunden und technischem Know-How."

Schließlich besprechen wir, wie viele davon wir in den nächsten zwei Wochen angehen können. Ein Entwicklungsintervall, ein “Sprint”, umfasst bei uns zwei Wochen. 

Mit dieser Zielformulierung gehen wir in die technische Umsetzung. Daran arbeiten dann Entwickler und Designer zusammen. Was fertig ist, wird noch ausgiebig getestet: Funktioniert alles in der Praxis? Wenn das sichergestellt ist, kann die Idee als fertiges Feature für die Kunden veröffentlicht werden.

Jede neue Idee durchläuft einige Prozessschritte, bevor sie veröffentlicht wird. / Eigene Darstellung.

In manchen Fällen, wie beim neuen Design, werden die Änderungen aber auch nicht direkt veröffentlicht. Sondern es werden die Ergebnisse aus vielen “Sprints” gebündelt, und dann an Tag X  in einem Rutsch den Kunden zur Verfügung stellt. Das sieht dann für die Kunden so aus, als hätten wir lange gar nichts gemacht. Es ist natürlich anders: 

Wir arbeiten IMMER an der Plattform. Diese Bündelung passiert dann, wenn erst viele kleine Dinge zusammen ein rundes Ergebnis für die Kunden bringen. Eine Tabelle nur an einer Stelle der Plattform zu veröffentlichen könnte beispielsweise Nutzer irritieren. Die Tabellen an mehreren Stellen gleichzeitig zu ändern kann da sinnvoll sein.

"Für die Kunden sieht alles kinderleicht und smooth aus. Doch die Realität der Softwareentwicklung ist komplex!"

Software ist mehr als nur ‘Code schreiben und veröffentlichen. Neben dem Software-Code für unterschiedliche Komponenten, wird auch die erforderliche Infrastruktur betrieben. Zum Beispiel die Mechanismen, die abhängig von der aktuellen Nutzerlast automatisch die Server starten und beenden, damit auch viele Zugriffe auf einmal möglich sind. Davon sehen die Nutzer idealerweise nichts! Nutzer sollen den Flow haben in ihrer eigenen Arbeit ohne sich mit der Komplexität zu beschäftigen. Egal was im Hintergrund passiert - es soll ein einfaches Erlebnis sein.

Das ist das Paradoxon an der Sache: Machen wir es richtig, sieht es für die Kunden kinderleicht und sehr flott aus. Verständlicherweise entsteht dann der Eindruck, es wäre nichts dabei. Dabei sind die Hintergründe oft komplexer als auf der Oberfläche sichtbar wird.