iPhone, iPad, Androids - 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 mobile Fieber hatte längst eine breite Userschicht erreicht. Bei Cortal Consors, einer der führenden Direktbanken in Europa, hatte man dies schnell erkannt und beschloss, dem Kunden auch auf diesem mobilen Kanal zu begegnen - und ihm gleichermaßen Instrumente zur Beobachung sowie Steuerung seines Depots sowie seiner Konten an die Hand zu geben.
Die Zeit drängte, denn obwohl man mit der Kombination aus Marktinformationen, Trading und Banking ein - zu diesem Zeitpunkt einmaliges - Produkt anbot, hatten doch verschiedene Wettbewerber bereits erste mobile Applikationen entwickelt. Entsprechend groß war auch das Interesse in der Unternehmensspitze, die Entwicklung einer eigenen App schnell und effizient voran zu treiben. Nur neun Monate standen dafür zur Verfügung. Doch der enge Zeitrahmen schuf den Freiraum dafür, sich vom bisher starren aber konsequent angewendeten Projekt-Management-Prinzip zu lösen - und dieses mit Elementen einer agilen Vorgehensweise zu mixen.
|
Außen klassisch, innen agil
Im Normalfall wäre das Projekt in die Release-Planung aufgenommen worden, in der sämtliche Softwareentwicklungsprojekte organisiert werden . Das ließ der enge Zeitplan nicht zu, denn um alle in der Release-Planung geforderten Formalitäten zu erfüllen, hätte der Betriebsstart um knapp drei Monate verschoben werden müssen.
Auch von in der bis dato angewandten Form des Wasserfall-Prinzips verabschiedete sich die Projektleitung schnell und passte die Methode den eigenen Anforderungen an. Üblicherweise gliederte Cortal Consors die Projektarbeit in fünf Phasen, die nacheinander abzuarbeiten sind. Für das Mobility-Vorhaben wurden die Projektschritte angepasst. Im folgenden sind die ursprünglichen und veränderten Phasen dargestellt.
1. Vorstudie (Initialisation Phase):
Bedeutet: Das Entwicklungsmodell wird auf Basis von evaluierten Anforderungen, Marktstudien, Problemstrukturierung und Schwachstellenanalyse, Definition sowie auf Basis von Randbedingungen wie Zeit und Budget, etc festgelegt. Außerdem werden Web-Entwicklungsprojekte bei Cortal Consors im Rahmen der sogenannten Release-Planung projektiert.
Wie de facto verfahren wurde: Die Geschäftsführung hat das Projekt ohne tiefer gehende Vorstudien beschlossen. Zwar war bekannt, dass auf Kundenseite eine hohe Affinität zu Apple-Produkten bestand, aber für das iPhone war diese nicht speziell abgefragt worden. Wettbewerberlösungen wurden erst während der Konzeptionsphase analysiert. Das Projekt wurde nicht in die offizielle Release-Planung integriert.
2. Spezifikation und Konzeption (Preparation Phase)
Bedeutet: Die fachlichen Anforderungen an die geplante Applikation werden vor Beginn der Konzeptionsphase schriftlich festgelegt. Dabei muss diese unter anderem folgende Kriterien und Formalien erfüllen: Ausgangssituation, Projektziele, Abhängigkeiten zu anderen Projekten, interne Richtlinien und Compliance, Sicherheitsaspekte sowie Anforderung an die Nutzerschnittstelle und Administration.
Wie de facto verfahren wurde: Erst im Verlauf der dreimonatigen Konzeptionsphase - die parallel zur Entwicklungsphase stattfand - wurde die Spezifikation entwickelt und dann schrittweise angepasst. Sie entsprach letzlich jedoch den offiziellen Formalien einer business-planerischen Spezifikation nur wenig, da sie sich vielmehr am Feedback aller Beteiligten orientierte. Es handelte sich um eine um Wireframes ergänzte Spezifikation. Das Pflichtenheft wurde parallel zur fachlichen Spezifikation erarbeitet, aber erst später fertig gestellt, da es noch an die fachliche angepasst werden musste.
3. Programmierung und Testing (Construction Phase)
Bedeutet: Erst wenn das Pflichtenheft beziehungsweise die Spezifikation steht, kann die Entwicklung starten. 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 - und damit noch vor Erstellung der Spezifikation. Dieser wurde in Workshops, nach Sitzungen des Lenkungsausschusses sowie nach Festlegung des Design-Styleguides im fortlaufenden Turnus den immer wieder neu hinzugekommenen Anforderungen angepasst.
4. User Acceptance Test (Acceptance Phase)
Bedeutet: Die gelieferte Software wird vom Auftraggeber auf Lösungsqualität getestet. Der Anspruch an die Applikation ist, dass nur eine abnahmereife Version dann 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, und Kollegen aus dem Bereich Trading and Technologies die für Bestandskunden. Insgesamt wurden dafür pro Tester vier Mitarbeiterwochen benötigt. Die Web-Agentur lieferte bereits während des Testverlaufs final getestete und damit freigegebene Teile der App aus - noch bevor die gesamte App freigegeben worden war. Die Fachanforderer hatten zuvor bereits Prototypen im Rahmen sogenannter Reviews untersucht und dazu Feedback gegeben, sodass sehr praxisnah und frühzeitig Schwächen in der Entwicklung aufgezeigt - und damit auch behoben - werden konnten.
5. Transition
Bedeutet: In dieser Phase erfolgt der letzte Feinschliff. Außerdem wird die Software allen Usern zur Verfügung gestellt (Go Live).
Wie de facto verfahren wurde: Das Go Live erfolgte in Deutschland im Mai 2010, in Frankreich im September 2010. Dokumentation, User-Schulungen, das Aufsetzen eines Helpdesk, Marketing-Maßnahmen und die Inbetriebsnahme folgten den üblichen Standards.
Wasserfall-Methode mit agilem Projekt-Management kombiniert
Trotz aller Abweichungen vom normalen Prozedere: Agiles Projekt-Management in Reinkultur wurde dennoch nicht betrieben, dafür blieb keine Zeit. Allerdings nutze das Team die Checkliste aus dem Agile Project Management Guide 2.0 des Projekt-Management-Verbands IAPM. Ein Project Owner wurde nicht benannt, weil sich das benötigte fachliche Know-how für die Content-Organisation beziehungsweise für die Konzeption der App kaum einer einzelnen Person übertragen ließ.
Aufbau der App
Grundsätzlich wurden für die iPhone-Applikation Bereiche für zwei unterschiedliche Nutzertypen entwickelt: Ein offener Bereich, in dem der Anwender ohne die Notwendigkeit eines Log ins Marktinformationen abrufen, eine persönliche Watchlist einrichten sowie Wertpapiere suchen und dazugehörige Informationen einsehen kann. Struktur und Inhalte dieses Segments wurden in weiten Teilen dem Internet-Auftritt von Cortal Consors entnommen.
Der zweite Bereich ist nur für eingeloggte Kunden sichtbar. Er bietet eine Übersicht über die eigenen Konten und Depots - inklusive Verzinsungen und aktueller Umsätze - sowie die Möglichkeit, Überweisungen zu tätigen oder Wertpapiere zu kaufen und zu verkaufen.
Workshops als wichtigstes Tool
Bei der Entwicklung der App wurde aber nicht nur wegen des knappen Zeitrahmens auf das lineare Vorgehen des offiziell verwendeten Wasserfall-Ansatzes verzichtet. Ein weiterer Grund war der, dass es inhouse keinerlei Erfahrungen mit der Entwicklung mobiler Applikationen gab, weshalb von Anfang an eine französische Agentur mit Spezialisierung auf Applikationen für das Apple iOS Betriebssystem ins Boot geholt wurde, mit der man jedoch im Vorfeld noch nicht zusammengearbeitet hatte. Und auch die Apple-Entwicklungsplattform X-Code war für die Cortal-Consors-Mitarbeiter Neuland.
Als eines der wichtigsten Tools im Projektverlauf stellten sich die ein- bis zweitägigen Workshops heraus - insgesamt fünf allein in der Konzeptionsphase. In ihnen trieben interne und externe Projekt-Mitarbeiter gemeinsam Konzept und Design der Applikation voran. Noch während des Workshops und auf Basis der bereits pro-aktiv erstellten Prototypen konnte die verpflichtete Agentur zudem die systemseitige Spezifikation ausarbeiten und dadurch ad hoc Einwand bei Wünschen erheben, die das Projekt maßgeblich verzögert hätten.
Das Ergebnis der Workshops und damit auch der Konzeptionsphase präsentierte sich nicht als klassische Spezifikation sondern als Wireframes beziehungsweise als Grobentwurf der Applikation. Er stellt das Mapping von User-Interface-Elementen wie Eingabefelder und Buttons mit den diversen Diensten dar, die Inhalte wie News und Kurse liefern. Dieser Grobentwurf wurde als offizielle "Business Requirement Specification" zu einem wesentlichen Bestandteil des Agenturvertrags. Die systemseitige Spezifikation wurde dagegen erst im Verlauf der Programmierphase fertiggestellt.
Drei Herausforderungen für mobiles Pioniertum
Zusätzlich zum engen Zeitrahmen bis zum Go Live machten drei weitere Faktoren das iPhone App-Projekt zu einer Herausforderung für die Projektverantwortlichen:
1. Gemeinsame App für Deutschland und Frankreich
Weil die Kosten für die App-Entwicklung zu gleichen Teilen zwischen Deutschland und Frankreich geteilt wurden, wurden Vorstellungen und Wünsche beider Länder gleich gewichtet. Das Projektteam setzte sich aus insgesamt vier Mitarbeitern aus Frankreich und Deutschland sowie einem zentralen Projekt-Manager zusammen, die sich auf ein gemeinsames Oberflächendesign einigen mussten.
Während dies beim iPhone-Projekt relativ schnell gelang, drohte die darauffolgende Entwicklung der gemeinsamen iPad-Variante beinahe zu scheitern. Zu unterschiedlich war die Anspruchshaltung: So vertrat das französische Projektanagement die Meinung, dass das Design einen wesentlichen Einfluss auf die Akzeptanz beim französischen Nutzer habe - und entwickelte unaufgefordert eigene Designvorschläge, die es dem zentralen Projekt-Management in Deutschland vorlegte. Schließlich kamen zu den teilweise unterschiedlichen Templates, die aus fachlichen Anforderungen heraus entstanden waren, auch leichte Designunterschiede hinzu.
2. Entwicklungsumgebung deren Verfügbarkeit über das Release-Management koordiniert wurde
Mobile Applikationen von Cortal Consors sind keine isolierten oder autarken Lösungen. Tatsächlich sind sie mit einer ganzen Reihe verschiedener Datenbanken (mit Markt- und Kursdaten) sowie Konto- und Depot-Daten des jeweiligen Kunden verknüpft. Dies zeigte sich gerade in der Programmier- und Testphase als nicht eingeplante, aber große Herausforderung. So mussten beispielsweise Test-Accounts für die Entwickler immer wieder neu angelegt und Testdaten (Konto- und Depotdaten) aufgebaut werden, weil - vom Projektteam unbemerkt - parallel zur Testphase ein sogenannter Datenbankbestands-Neuaufbau stattfand, wodurch die Testdaten immer wieder gelöscht wurden. Programmierarbeiten und Tests wurden also immer wieder unterbrochen - teilweise mehrere Tage lang.
3. Dokumentation bzw. Requirements Engineering
Die Entwicklung der iPhoneApp war für das Projekt-Management ein echtes Innovationsprojekt. Daher hat man sich an den Applikationsrastern vorhandener Web-Applikationen orientiert und diese Schrittweise den Erfordernissen angepasst. Die Fachverantwortlichen hatten jedoch keine Erfahrung mit der Dokumentation und dem zentralen Projekt-Manager fehlt die Zeit, sich darum zu kümmern. Stattdessen wurde mit Wireframes gearbeitet, die in PowerPoint erstellt wurden und zahlreiche Zusatzmerkmale umfassten, wie beispielsweise Kommentare, eindeutige Bezeichnung des Wireframes, Abweichungen für die Länderversionen, Beschreibung des Applikationsverhaltens im Fehlerfall und Verknüpfung mit einem Styleguide.
Lenkungsausschuss: Monatlich statt Meilenstein-gebunden
Auch hier rückte das Projektteam vom Wasserfall-Prinzip ab. Während offiziell jeder Meilenstein vom Lenkungsausschuss abgenommen werden musste, wurde darauf in der Praxis verzichtet. Stattdessen organisierte die Projektleitung in Abstimmung mit der IT-Entwicklung und mit den französischen Kollegen monatlich meilensteinunabhängige Sitzungen mit allen für den jeweiligen Projektstand relevanten Stakeholdern. Wegen des Pioniercharakters des Projekts war das Interesse daran so groß, dass schließlich rund 25 Mitarbeiter dem Lenkungsausschuss angehörten. Während der Sitzungen wurden der aktuelle Projektstand sowie die Budgetentwicklung vorgestellt, aufgetretene Herausforderungen und mögliche Lösungsansätze diskutiert und teilweise auch Budgetfragen direkt entschieden. Dabei wurde wegen des engen Zeitrahmens auf viele Kennzahlen und Formalien verzichtet.
Fazit: Erwartungen weit übertroffen
Die Bedeutung der Projektsponsoren spielte für den Projekterfolg eine entscheidende Rolle. Ohne die vielen Zugeständnisse, die die Geschäftsleitung und obersten Management-Ebenen gegenüber den Projektverantwortlichen im Hinblick auf Einhaltung der offiziellen Richtlinien gemacht haben, wäre eine Umsetzung innerhalb der vorgegebenen neun Monate nicht denkbar gewesen. Als ebenso wichtig erweis sie, dass sich das Projekt-Management offen gegenüber agilen Methoden zeigte.
Die Flexibilität hat sich ausgezahlt. Heute schon entfallen etwa fünf Prozent aller Trading-Aktivitäten bei Cortal Consors auf mobile Applikationen. Folgerichtig kürte das Anlegermagazin Börse Online Cortal Consors zur besten Direktbank des Jahres 2012 in der Kategorie Mobile Banking.
|
Über die IAPM:
Foto: IAPM
Die International Association of Project Managers (IAPM) wurde 1997 gegründet und ist ein weltumspannender Verband mit Zertifizierungsstelle für Projektmanager. Die IAPM bietet unterschiedliche Zertifizierungsmöglichkeiten an, unter anderem auch die zum "Certified Agile Project Manager" speziell für IT-Projektmanager. Grundlage der Zertifizierung für Projektmanager ist der "PM Guide 2.0" (Hrsg. 2010) und für Agile Projektmanager der "Agile PM Guide 2.0" (Hrsg. 2013). Die Guides sind in enger Zusammenarbeit mit international agierenden Projektmanagern entstanden. Schon heute besitzen Mitarbeiter namhafter Unternehmen wie Cortal Consors, Siemens, DB ProjektBau oder Toptica Photonics IAPM-Zertifikate und profitieren somit langfristig vom Know-how und Renommee des Verbandes.www.iapm.net