5 Min. Lesezeit
Die Verwandlung des Prototyps in einen funktionalen MVP
Im stark regulierten Financial Services Sektor ist die technische Entwicklung der konzipierten Idee zu einem stabilen, skalierenden Produkt eine besonders herausfordernde Aufgabe.
Wir haben uns auf diese Besonderheiten im Bankenumfeld spezialisiert und verstehen die Umsetzung eines Digitalisierungsprojektes nicht wie die Programmierung des nächsten E-Commerce-Shops.
Im Folgenden erläutern wir, wie wir die regulatorischen Rahmenbedingungen einer Bank mit der Innovationskraft und Umsetzungsorientierung eines FinTechs in Einklang bringen.
Was bisher geschah
- Die priorisierten Lösungsansätze wurden in einer Experience Map visualisiert,
- über die Erstellung von Wireframes zu detaillierten Mockups zusammengeführt und validiert sowie
- letztlich zu einem Prototyp mit einem hohen Detailgrad an Funktionalität und Design entwickelt.
…
Die technische Umsetzung – das Herzstück der Produktentwicklung
Die technische Umsetzung des Design-Prototypen in einen MVP ist Kern unserer Digitalisierungsprojekte – ganz gleich ob gemeinsam mit unseren Kunden oder bei unseren Ventures und eigenen Produktlösungen.
Während der Entwicklung gilt es uns dabei vor allem
- schnellstmöglich Potenziale digitaler Marketing- und Vertriebsstrategien auszuschöpfen und
- relevantes Kundenfeedback vom Start an zu integrieren.
×Exkurs
Minimum Viable Product (MVP)
Unter einem MVP wird ein Produkt bzw. ein Service verstanden, welches nur die notwendigsten Funktionen umfasst, um das identifizierte Kundenproblem zu lösen. Das Ziel ist es, durch den Launch des MVP am Markt, frühzeitig im Entwicklungsprozess qualitatives Feedback zur Lösung einzuholen und Optimierungen vorzunehmen.
Kurzum: Unser Fokus liegt auf der technischen Umsetzung kundenorientierter Produkte in kurzzyklischen Iterationen (meist im 2-Wochen-Rhythmus). Dabei gelten besonders agile Strukturen als geeignet, um die beiden Anforderungen zu erfüllen. Ein dafür sehr bekannter Ansatz ist SCRUM.
Als Framework für die agile Softwareentwicklung setzt SCRUM vor allem bei der Entwicklung unserer eigenen Produkte die passenden Orientierungspunkte:
- Der zeitliche Rahmen sowie das verfügbare Budget sind festgelegt,
- der inhaltliche Umfang variabel.
Losgelöst von organisatorischen Grenzen können wir maximal agil handeln und relevante Learnings für die Optimierung ableiten.
Unsere Erfahrung zeigt jedoch, dass dieses konsequent agile Vorgehen bei der Entwicklung digitaler Produktlösungen im Bankenumfeld aufgrund des dynamischen Scopes nicht vollständig anwendbar ist. Budgetierungszyklen für geplante Projekte starten schließlich häufig weit im Voraus, wodurch eine frühzeitige, valide Bewertung notwendig ist.
Klassische Methoden in Form des herkömmlichen Wasserfallmodells gehören daher noch immer zu den gängigsten Ansätzen der Produktentwicklung:
- Der inhaltliche Umfang ist fix,
- das Budget und der zeitliche Rahmen sind darauf aufbauend geschätzt.
In unseren Digitalisierungsprojekten
leben wir daher einen bewusst gewählten hybriden Ansatz:
- Wir verbinden die agile Umsetzung nach SCRUM mit Facetten der klassischen Produktentwicklung und passen uns an die individuellen organisatorischen und technischen Rahmenbedingungen an.
- Unsere Erkenntnisse aus der eigenen, vollständig agilen Produktentwicklung sowie die Expertise zu neuen technischen Trends lassen wir als relevante Erfolgshebel stetig mit einfließen.
×Exkurs
Agile vs. klassische Produktentwicklung
Bei der agilen Produktentwicklung legt ein kleines, interdisziplinäres Projektteam den Umfang und das Ziel des Projekts in Echtzeit fest. Das Vorgehen erfolgt in kurzen Umsetzungsphasen (Sprints) von in der Regel zwei Wochen. Charakteristisch für jeden Sprint sind die Planungs- und Umsetzungsphase, das Deployment bzw. Release sowie eine anschließende Retrospektive, in der die Zusammenarbeit sowie technische und fachliche Aspekte diskutiert werden. Kosten und Zeit sind bei diesem Ansatz fixe Bestandteile, während der Umfang dynamisch ist.
Die klassische Produktentwicklung (Wasserfall-Modell) spiegelt einen sequenziellen Entwicklungsansatz wider. Auf Basis des festgelegten Umfangs werden im Vorfeld die erforderliche Zeit sowie die Kosten geschätzt. Es folgt die sequenzielle Entwicklung in aufeinanderfolgende Phasen, wobei die einzelnen Phasenergebnisse notwendig sind für den weiteren Fortschritt. Für gewöhnlich werden diese Phasen in die Konzeptions-, Umsetzungs- und Abnahmephase mit einzelnen Meilensteinen unterteilt. An die Abnahme schließt sich das Release, zu dem die Umsetzungen einer oder mehrerer Entwicklungen live gestellt werden.
1 Anforderungen spezifizieren und priorisieren
Auf der Grundlage des Design-Prototyps spezifizieren wir die inhaltlichen und fachlichen Anforderungen an die technische Umsetzung des MVP in User-Stories.
Bei der Umwandlung der Stories in technische Entwicklungstickets bieten wir unseren Kunden maximale Transparenz: Wir setzen ein technisches Ticket-Board auf und binden das gesamte Team bereits an dieser Stelle aktiv in die Spezifizierung und Priorisierung mit ein.
Das Ergebnis ist ein Product-Backlog, welches
- aus priorisierten Aufgabenpaketen besteht,
- die den Nutzen für die Lösung aus Kundensicht abbilden und
- nacheinander entsprechend ihrer Priorität bearbeitet werden können.
Zusätzlich ermöglichen die kleinen inhaltlichen Aufgabenpakete eine indikative Schätzung des budgetären und zeitlichen Entwicklungsaufwands.
2 Entwicklungstickets umsetzen und testen
Ab jetzt starten wir die Entwicklung! Zunächst aggregieren wir die Tickets des
Product-Backlogs in einen initialen Release Plan. Wir verteilen die User Stories entlang einer Zeitachse in Sprints und antizipieren, wann diese bearbeitet werden.
Ist der erste Release Plan erstellt, wechseln wir von der strategischen Planungsebene in die Produktentwicklung. Wir setzen die spezifizierten Entwicklungstickets iterativ in zweiwöchigen Sprints um und testen die Funktionalitäten im Anschluss.
Bei einem gewissen Maß an notwendiger Planungssicherheit, lässt dieses Vorgehen bewusst Raum für technische Optimierungsschleifen.
×Exkurs
Release Plan
Der Release Plan ermöglicht eine Vorschau, in welcher Zeit welche Funktionalität geliefert wird. Die Planung wird dabei in einzelne Sprints heruntergebrochen. Durch einzelne Meilensteine wird vermerkt, wann voraussichtlich genug Funktionalität entwickelt wurde, um ein Release durchzuführen. Voraussetzung ist ein mit Blick auf den Aufwand geschätztes und vorpriorisiertes Product-Backlog, das alle Anforderungen an das zu erstellende Produkt enthält.
Unsere Erfahrung zeigt, dass Besonderheiten komplexer Anwendungslandschaften im Bankenumfeld häufig außer Acht gelassen werden.
Fatal – da es weitere Faktoren gibt, die einen erheblichen Impact auf die Entwicklung haben. Die nachfolgende Liste ist keinesfalls abschließend:
- Komplexität der Applikation durch Anzahl der Schnittstellensysteme sowie externe Abhängigkeiten
- Kritikalität des Produkts bzw. Services
- Kenntnis der fachlichen, funktionalen Anforderungen.
3 MVP validieren und Vorgehen analysieren
An dieser Stelle sind wir mitten in der Umsetzung. Durch 2-wöchige-Releases kleinerer Aufgabenpakete werden neue Produktfunktionen laufend live geschaltet. In fest definierten Zyklen holen wir durch umfängliche Usability-Tests parallel Feedback der Zielgruppe zur Lösung ein.
Wertvolles Kundenfeedback zu einzelnen Produktinkrementen wird als neue User Story in das Product-Backlog aufgenommen und in die Entwicklung einpriorisiert.
Neben den Endkunden-Stimmen ist auch das Feedback des Teams zum Entwicklungsvorgehen relevant. Die Retrospektive im Anschluss an einen Sprint ist Kernelement unseres Prozesses. Wir analysieren die Zusammenarbeit und arbeiten heraus, was verbessert werden kann, um im nächsten Sprint noch produktiver zu werden.
×Exkurs
Usability-Test
Ein Usability-Test ist eine Methode, um die Gebrauchstauglichkeit eines Produkts bzw. Services zu bestimmen. Im Vordergrund steht die Detailoptimierung. Nutzer aus der spezifischen Zielgruppe testen das Produkt bzw. Service dabei auf Schwachstellen und Verbesserungsmöglichkeiten. In den Testsitzungen, die meistens in einem Usability-Labor stattfinden, bearbeiten die Probanden typische Aufgaben, die die Kernfunktionalitäten der Anwendung widerspiegeln.
4 Dokumentation finalisieren und Betrieb sicherstellen
Die Entwicklung nach der OWASP-Foundation, eine mehrfach redundante Qualitätssicherung (automatisiert und manuell) sowie die stetige Aktualisierung der Softwarebibliotheken bilden das Grundfundament einer sicheren Software.
Zusätzlich schließen regelmäßige, manuelle Härtetests (IT-Penetrationstests) als effektive Präventivmaßnahmen tiefere Sicherheitslücken aus. Relevante Findings werden in die Entwicklung gegeben und Auffälligkeiten direkt ausgemerzt.
Auch der eigentliche Betrieb ist nach höchsten und modernsten Sicherheitsstandards bei uns Pflicht und gelebte Praxis, dabei setzen wir ausschließlich auf ISO 27001-zertifizierte Rechenzentren.
Zum Schluss finalisieren wir noch die Dokumentation aller Themen:
- Prozesse der Software
- Relevante Schnittstellen
- Betriebsinformationen
- Sicherheitstest
- …
×Exkurs
IT-Penetrationstests (Pentest)
Mit Hilfe eines Penetrationstests versuchen IT-Experten durch gezielte Angriffe die Empfindlichkeit von Netzwerken oder IT-Systemen gegenüber Angriffen festzustellen, um Gefährdungspotenziale besser einzuschätzen. Sie verwenden ähnliche Methoden und Techniken, wie sie Hacker einsetzen, um unautorisiert in ein System einzudringen. Während des kompletten Penetrationstests erfolgt eine Protokollierung aller durchgeführten Maßnahmen. In einem abschließenden Bericht sind die erkannten Schwachstellen und Lösungsansätze zur Verbesserung des IT-Sicherheitsniveaus aufgeführt.
Und sind Sparringspartner bei Fragestellungen, die mit der Digital-Idee einhergehen:
- Gesetzlich konformen Erhebung, Verarbeitung und Löschung personenbezogener Daten
- bis hin zu Anforderungen an Informationspflichten.
Innerhalb weniger Sprints haben wir so einen MVP entwickelt, der nicht mehr in einer isolierten Testumgebung, sondern live verfügbar ist und die Basis für erste Marketing-Tests bietet.
Sie möchten wissen, wie wir die entwickelte Lösung skalieren? Das erfahren Sie im nächsten Blog-Post.
Output
Technische Entwicklungstickets
Validierter MVP
Priorisiertes Product-Backlog
Vollständige IT-Dokumentation
