Most of the executives I talk to are still very much focused on digital largely as a way to do “more of the same,” just more efficiently, quickly, cost effectively. But I don’t see a lot of evidence of fundamentally stepping back and rethinking, at a basic level, “What business are we really in?”
Als Anbieter von individuell entwickelter Software ist uns die Situation sehr vertraut: interessierte Unternehmen fragen uns an – mit einem detaillierten Pflichtenheft in der Hand, was genau die zu entwickelnde Software leisten soll. Gerade bei öffentlichen Ausschreibungen sind schon einige technische und UI-Details exakt beschrieben, sodass die angefragte Software-Entwicklung vor allem darin besteht, die beschriebenen Anforderungen visuell in einem Prototypen darzustellen und diesen dann in die funktionale Software zu übersetzen. Soweit, so gut.
Wenn das Unternehmen vorher einen intensiven Prozess zur Designentwicklung durchgeführt hat, kann man mit einem derartigen Lastenheft gut arbeiten. Die Erfahrung zeigt aber, dass die meisten Lastenhefte aus Pflichtenheften abgeleitet sind, die wiederum eine priorisierte Sammlung der Anforderungen an die neue Software sind und meist das Leistungsspektrum der bisher eingesetzten Systeme lediglich optimiert.
Die Funktionalitäten werden – oft genug – von nicht Technikerinnen und Technikern formuliert, ebenso wenig von UX-Fachkräften. Typischerweise sind es die Referentinnen und Referenten, die Bereichsverantwortlichen und deren Mitarbeitende, die später die Software nutzen sollen.
In den allermeisten Ausschreibungen und Anfragen begegnen uns mehr oder weniger umfangreiche Lastenhefte. Ziel der ausschreibenden Stelle ist, möglichst klar und unmissverständlich zu definieren, was die Software können soll. Auch ist es in der Regel einfach, jede Anforderung ziemlich exakt zu kalkulieren und ein monetäres Angebot zu schreiben.
Daraus ergeben sich Vor- und Nachteile:
Die ausschreibende Organisation bzw. das ausschreibende Unternehmen hat bereits viel Vorarbeit geleistet und die anbietenden Unternehmen können schnell in die Kalkulation und in die Angebotserstellung gehen. das spart Zeit und Geld.
Alles hängt daran, dass die Person, die das Lastenheft zusammengestellt hat, einen guten Überblick über die Schmerzpunkte und Zielsetzungen hat. Außerdem ist die technische Kompetenz der Person entscheidend. Kennt die Person die technologischen Möglichkeiten? Ist sie in der Lage, eingeübte Prozesse im Arbeitsbereich kritisch zu hinterfragen, um sie entsprechend optimiert im Lastenheft abzubilden oder sogar komplette Prozesse zu ersetzen? Ist sie außerdem in der Lage, intern die Innovationen zu argumentieren?
Der Erfolg der Software hängt an einzelnen Personen, deren Kompetenz und Abstraktionsvermögen.
In der agilen Software-Entwicklung arbeitet idealerweise ein multi-disziplinäres Team an dem Vorhaben. Und zwar von Anfang an. Von Beginn an sitzen die Expertinnen und Experten an einem Tisch, um ein gemeinsames Verständnis von Bedürfnissen, Motivationen und Voraussetzungen aller Stakeholder zu erarbeiten.
Stichwort: Stakeholder. Explizit sind neben den unternehmens-/organisationsinternen Nutzerinnen und Nutzern auch Partnerunternehmen sowie Konsumentinnen und Konsumenten als relevante Stakeholder zumindest mittelbar am Tisch. Oft übernehmen Kontaktpersonen beim Auftraggeber diese Rolle (z.B. Support, Sales etc.).
Gemeinsam eröffnet sich dann schnell ein breiteres, holistischeres Bild von der Herausforderung. Auch mit in der Diskussion sind die Expertinnen und Experten für UX- und UI-Design, Daten-Management, Software-Architektur und schließlich Software-Entwicklung. Die enge Zusammenarbeit reduziert Missverständnisse und ermöglicht die schnelle Klärung von Detailfragen. Alle Teilnehmenden bringen ihre Expertise ein. Am Ende steht ein Konzept, ein klares Bild, welche Software gebaut werden soll und wie sie aussieht und sich anfühlt.
Anstatt daraus ein vollständiges Lastenheft abzuleiten, kann die Entwicklungsarbeit sofort starten. Die auftraggebende Organisation bzw. das auftraggebende Unternehmen kann in kurzen Iterationen den Entwicklungsstand validieren und testen.
In der agilen Software-Entwicklung stehen Methoden zur Verfügung, auf Erkenntnisse und geänderte Rahmenbedingungen schnell zu reagieren. Wird es erforderlich oder gewünscht, kann das Konzept angepasst werden. Im Ergebnis passt die fertige Software so besser zu den Nutzerinnen und Nutzern sowie zu den strategischen Zielsetzungen des Unternehmens bzw. der Organisation.
In der Regel erfüllt die fertige Software die Erwartungen besser, da es eine engere Einbindung der Stakeholder gibt. Innovationen sind wahrscheinlicher, weil die Expertinnen und Experten für die Umsetzung sich naturgemäß auf einem aktuelleren Wissensstand halten und diese Expertise schon im Konzept einbringen.
Geänderte Rahmenbedingungen können besser berücksichtigt werden.
Da die Entwicklung schneller starten kann, steht die fertige Software schneller zur Verfügung.
Da während des Entwicklungsprozesses sich das Konzept laufend anpasst, um Anforderungen zusätzlich oder besser zu erfüllen oder um geänderten Rahmenbedingungen Rechnung zu tragen, kann ein Gesamtvolumen schlechter kalkuliert werden. Vielmehr ist die Kalkulation ein Kostenrahmen. Je nach Budget kann das Konzept angepasst werden.
Eine große initiale Kalkulation verschafft vermeintlich Sicherheit und Planbarkeit. Im Lastenheft steht genau, was erwartet wird und in der Kalkulation, was das kostet und wann es fertig ist.
Wäre die Welt so, dass sie an einem bestimmten Zeitpunkt stehenbleibt, wäre das ideal. In Zeiten dynamischer Märkte, sich schnell verändernder Möglichkeiten und Risiken, ist deswegen eine nach der Wasserfall-Methode aufgesetztes Projekt schwierig. Nicht selten ändern sich so viele Rahmenbedingungen während der Software-Entwicklung, dass die ursprünglich beauftragte Software, gar nicht oder nur noch mit Anpassungen sinnvoll und mehrwertstiftend ist.
Das bedeutet: während in der agilen Vorgehensweise diese Unsicherheit akzeptiert wird und die Prozesse darauf eingerichtet sind, ignorieren traditionelle Herangehensweisen diesen Fakt.
Nach unserer Erfahrung ist es deswegen sinnvoller, an den Anfang den Fokus auf die gemeinsame Konzepterstellung zu legen und diesen Prozess zu nutzen, um Vertrauen zu einem Software-Entwickler bzw. einem Software-Unternehmen aufzubauen. Eine vertrauensvolle und funktionierende Kommunikation und enger Austausch ermöglicht, die Software eher wie ein gemeinsames Kind zu betrachten, dass sich entwickelt, Einflüsse aufnimmt, sich verrennt und am Ende seinen Weg findet. – Und genau wie Kinder, die selbstbewusst sich entwickeln können, wird auch die Software am Ende richtig gut sein in ihrem Gebiet.
Farben sind einer der wichtigsten Eindrücke für uns Menschen. Vor Urzeiten halfen sie uns zu überleben. Rote Beeren, zum Beispiel, sollte man meiden, da diese Giftig sein könnten. Genauso wie Fliegenpilze. Grüne Pflanzen hingegen, haben uns das …
Zum ersten Mal fand die WTM virtuell statt. Corona hat auch hier einen deutlichen Schritt zu mehr Digitalisierung bewirkt. Hat es funktioniert? Wir finden, ja.
Eine Persona zu definieren, ist erstmal nicht schwierig. Es kostet aber etwas Zeit und Aufwand. Der Nutzen von Personas für die Konzeption und die spätere Entwicklung einer Applikation machen den Aufwand auf jeden Fall wett.
Wie Kühnen in seiner Definition formuliert, beschreibt eine Persona einen Menschen mit allen Facetten, Vorlieben und Abneigungen. Sie beschreibt Gewohnheiten, Erfahrungen und teilweise nicht in direktem Zusammenhang zur konkreten Aufgabenstellung stehende Überzeugungen.
