Schon im Jahr 2009 war klar: Die neue Generation mobiler Endgeräte konnte nicht länger als Spielzeug einer kleinen Gruppe von Early Adoptern und Technikfreaks abgetan werden, das Mobil-Fieber hatte eine breite User-Schicht erreicht. Die Direktbank Cortal Consors erkannte das und beschloss, den Kunden auch auf diesem Kanal zu begegnen - ihnen also mobile Instrumente zum Beobachten und Steuern ihrer Konten und Depots an die Hand zu geben.
Foto: Cortal Consors
Die Zeit drängte: Verschiedene Konkurrenten hatten bereits damit begonnen, ebenfalls erste mobile Applikationen zu entwickeln. Entsprechend groß war das Inter-esse an der Unternehmensspitze, die Entwicklung einer eigenen App schnell und effizient voranzutreiben. Nur neun Monate standen dafür zur Verfügung. Der enge Zeitrahmen machte es notwendig, sich vom bisher starren, aber konsequent angewendeten Projekt-Management-Prinzip zu lösen - und es mit Elementen einer agilen Vorgehensweise zu mixen.
Außen klassisch, innen agil
Im Normalfall wäre das Projekt erst einmal in die Release-Planung aufgenommen worden, in der sämtliche Softwareentwicklungsprojekte organisiert werden. Doch das ließ der enge Zeitplan nicht zu, denn um alle dort geforderten Formalitäten zu erfüllen, hätte der Betriebsstart um knapp drei Monate verschoben werden müssen.
Auch von der bis dato angewandten Form des Wasserfall-Modells verabschiedete sich die Projektleitung schnell. Üblicherweise gliederte Cortal Consors die Projektarbeit in fünf Phasen, die nacheinander abzuarbeiten sind. Für das Mobility-Vorhaben wurden die Projektschritte angepasst.
1. Vorstudie (Initialization Phase)
Bedeutet: Das Entwicklungsmodell wird auf Basis von evaluierten Anforderungen, Marktstudien, Problemstrukturierung und Schwachstellenanalyse sowie von Randbedingungen wie Zeit und Budget festgelegt.
Wie de facto verfahren wurde: Die Geschäftsführung hat das Projekt ohne tiefer gehende Vorstudien beschlossen. Lösungen der Konkurrenten wurden erst während der Konzeptionsphase analysiert.
2. Spezifikation und Konzeption (Preparation Phase)
Bedeutet: Die fachlichen Anforderungen an die geplante Applikation werden vor Beginn der Konzeptionsphase schriftlich festgelegt. Dabei sind folgende Kriterien zu beachten: Ausgangssituation, Projektziele, Abhängigkeiten zu anderen Projekten, interne Richtlinien und Compliance, Sicherheitsaspekte sowie Anforderung an Nutzerschnittstelle und Administration.
Wie de facto verfahren wurde: Erst im Verlauf der dreimonatigen Konzeptionsphase parallel zur Entwicklung wurde die Spezifikation entwickelt und dann schrittweise angepasst. Den offiziellen Formalien einer Business-planerischen Spezifikation entsprach sie nur wenig, vielmehr orientierte sie sich am Feedback aller Beteiligten und arbeitete mit Wireframes. Das Pflichtenheft wurde parallel zur fachlichen Spezifikation erarbeitet, aber wegen der Anpassungen erst später fertiggestellt.
3. Programmierung und Testing (Construction Phase)
Bedeutet: Erst wenn das Pflichtenheft beziehungsweise die Spezifikation steht, kann die Entwicklung beginnen. Jede Abweichung oder Änderung erfordert einen schriftlichen Change Request - und wird damit als Ärgernis angesehen.
Wie de facto verfahren wurde: Der mit der Programmierung beauftragte Dienstleister brachte bereits zum ersten Konzeptions-Workshop einen Prototypen mit. Dieser wurde in Workshops, nach Sitzungen des Lenkungsausschusses und auf Grundlage des Design-Styleguide fortlaufend den jeweiligen Anforderungen angepasst.
4. User Acceptance Test (Acceptance Phase)
Bedeutet: Die gelieferte Software wird vom Auftraggeber auf ihre Lösungsqualität getestet. Der Anspruch an die Applikation ist der, dass nur eine abnahmereife Version nach fest definierten Testkriterien und -serien geprüft werden soll.
Wie de facto verfahren wurde: Zwei Monate lang analysierten Tester aus dem Bereich E-Business die Variante für Neukunden. Kollegen aus dem Bereich Trading and Technologies übernahmen die Tests für Bestandskunden. Insgesamt benötigte jeder Tester vier Mitarbeiterwochen. Die Web-Agentur lieferte bereits während des Testverlaufs freigegebene Teile der App aus. Die Fachanforderer hatten zuvor Prototypen im Rahmen der Reviews untersucht und dazu Feedback gegeben. So ließen sich praxisnah und frühzeitig Schwächen in der Entwicklung aufzeigen und beheben.
5. Transition
Bedeutet: In dieser Phase bekommt ein System den letzten Schliff. Außerdem wird die Software allen Usern zur Verfügung gestellt (Go Live).
Wie de facto verfahren wurde: Das Go Live erfolgte hierzulande im Mai 2010, in Frankreich im September 2010. Dokumentation, User-Schulungen, Aufsetzen des Helpdesks, Marketing-Maßnahmen und Inbetriebsnahme folgten den üblichen Standards.
Zu wenig Zeit für Reinkultur
Trotz aller Abweichungen vom normalen Prozedere handelte es sich nicht um agiles Projekt-Management in Reinkultur. Auch dafür reichte die Zeit nicht. Allerdings nutzte das Team die Checkliste aus dem Agile Project Management Guide 2.0 der International Association of Project Managers (IAPM).
Ein Project Owner wurde ebenfalls nicht benannt. Das benötigte fachliche Know-how für die Content-Organisation beziehungsweise die Konzeption der App ließ sich kaum einer einzelnen Person übertragen.
Da es im Haus keinerlei Erfahrungen mit der Entwicklung mobiler Applikationen gab. wurde eine französische Agentur mit iOS-Know-how ins Boot geholt. Als eines der wichtigsten Projekt-Tools stellten sich die ein- bis zweitägigen Workshops heraus - fünf allein in der Konzeptionsphase. Noch während des Workshops und auf Basis der proaktiv erstellten Prototypen konnte die Agentur die systemseitige Spezifikation ausarbeiten. Das versetzte sie in die Lage, ad hoc Einwand bei Wünschen zu erheben, die das Projekt maßgeblich verzögert hätten.
Das Ergebnis der Workshops präsentierte sich nicht als klassische Spezifikation, sondern als Wireframes beziehungsweise Grobentwurf der Applikation. Er stellte das Mapping von User-Interface-Elementen dar, die Inhalte wie News und Kurse liefern sollten. Als offizielle "Business Requirement Specification" wurde der Entwurf zu einem wesentlichen Bestandteil des Agenturvertrags.
Drei Herausforderungen
Zusätzlich zum engen Zeitrahmen machten drei weitere Faktoren das App-Projekt zu einer Herausforderung:
1. Gemeinsame App für Deutschland und Frankreich
Weil die Kosten für die App-Entwicklung zu gleichen Teilen zwischen Deutschland und Frankreich aufgeteilt wurden, waren auch Vorstellungen und Wünsche beider Länder gleich gewichtet. Das Projektteam musste sich auf ein gemeinsames Oberflächendesign einigen. Während das beim iPhone-Projekt relativ schnell gelang, drohte die Entwicklung der iPad-Variante zu scheitern.
Zu unterschiedlich war die Anspruchshaltung: So vertrat das französische Projekt-Management die Ansicht, dass das Design wesentlichen Einfluss auf die Akzeptanz der Nutzer habe - und entwickelte eigene Designvorschläge. So kamen zu den teilweise unterschiedlichen Templates, die aus fachlichen Anforderungen entstanden waren, auch leichte Designunterschiede.
2. Paralleler Neuaufbau des Datenbankbestands
Mobile Applikationen von Cortal Consors sind mit einer ganzen Reihe verschiedener Datenbanken (Markt- und Kursdaten) sowie Konto- und Depotdaten des jeweiligen Kunden verknüpft. Das erwies sich gerade in der Programmier- und Testphase als nicht eingeplante Herausforderung. So mussten Test-Accounts für die Entwickler immer wieder neu angelegt und Testdaten (Konto- und Depotdaten) mehrmals aufgebaut werden. Der Grund: Parallel zu den Tests fand - vom Projektteam unbemerkt - ein Neuaufbau des Datenbankbestands statt. Die Tests wurden also immer wieder, teilweise mehrere Tage lang, unterbrochen.
3. Dokumentation/Requirements Engineering
Die Entwicklung der iPhoneApp war für das Projekt-Management ein echtes Innovationsprojekt. Es orientierte sich deshalb an den Applikationsrastern vorhandener Web-Applikationen und passte diese schrittweise an seine eigenen Erfordernisse an.
Die Fachverantwortlichen hatten jedoch keine Erfahrung mit der Dokumentation und das Projekt-Management keine Zeit, sich darum zu kümmern. So wurde mit Wireframes gearbeitet, die in Powerpoint erstellt waren und Zusatzmerkmale wie Kommentare, Abweichungen der Länderversionen, Beschreibung des Verhaltens im Fehlerfall und Verknüpfung mit einem Styleguide aufwiesen.
Die Flexibilität hat sich ausgezahlt. Heute entfallen rund fünf Prozent aller Trading-Aktivitäten bei Cortal Consors auf mobile Applikationen. Und 2012 kürte das Anlegermagazin "Börse Online" das Finanzhaus zur besten Direktbank im Bereich Mobile Banking.