App 2.0 – Wie eine neue Generation von Apps entstehen muss

Sven Günther
©Shutterstock/kentoh

Mobile Geräte erfreuen sich großer Beliebtheit und die Marktanteile wachsen stetig. Damit steigt auch der Wunsch vieler Unternehmen, auf solchen Geräten und somit beim Anwender präsent zu sein. Doch auch die Anforderungen steigen stetig weiter. Was bei Unternehmens-Apps heute zu beachten ist, zeigt dieser Artikel.

Das heutige Interesse an mobilen Geräten ist vergleichbar mit dem Interesse am Internet in den 90er Jahren. Während damals viele Unternehmen auf eine Präsenz im World Wide Web setzten, ist nun eine Präsenz auf den Geräten der Anwender gewünscht. Das erste Bedürfnis nach dieser Präsenz haben einfache Apps erfüllt, die mehr oder weniger eine Visitenkarte des Unternehmens darstellten. Mit der Zeit steigen aber die Bedürfnisse der Kunden und Unternehmen erkennen mobile Geräte als einen weiteren Verkaufskanal, wobei auch zu klären ist, was die wichtigsten Bedürfnisse der Kunden sind, die man über mobile Geräte abdecken kann. Einfache Visitenkarten können dabei nicht weiterhelfen. Viele Unternehmen stoßen zunehmend an die Grenzen der Apps, die mit einfachen Mitteln schnell und kostengünstig erstellt wurden. Diese Apps haben meist keine oder nur eine einfache Anbindung an das Backend der Unternehmen. Sie lassen sich schlecht erweitern, weil sie nie vor dem Hintergrund entwickelt wurden, erweiterbar zu sein. Zudem ist das Feedback der Kunden durch öffentliche Plattformen wie die App Stores sehr direkt und entspricht in vielen Fällen auch einer Form, die schon als geschäftsschädigend bezeichnet werden kann.

Die Unternehmens-App: Versuch 1

Manfred, der Marketingchef eines Reiseportals im Internet, hat früh erkannt, dass die Smartphones in den Händen der Nutzer eine gute Möglichkeit sind, Inhalte zu verbreiten. Mit seiner Idee, den Nutzern Reiseziele vorzustellen und diese damit in die Reisebüros und auf die Internetbörse zu locken, rannte er bei seinen Vorgesetzten offene Türen ein. Er hatte lange Zeit gut mit einer Webagentur zusammengearbeitet, die die Internetpräsenz des Unternehmens betreute und war erfreut, als diese ihm auch ein gutes Angebot für eine App machen konnte. Keine neun Monate später hatten sie eine App im App Store. Die Reise-App war ein großer Erfolg und die vielen Downloads machten Hoffnung auf mehr. Die Bewertungen der App im Store waren aber nicht gerade berauschend. Sie bekam von den Nutzern nur zwei von fünf Sternen. Viele beklagten sich über häufige Abstürze und veraltete Inhalte, die nur über eine neue Version der App aktualisiert werden konnten.

Die Anforderungen an die Stabilität und die Erweiterbarkeit von Apps sind genauso hoch wie an andere Software. Die Konzepte, die man gestern noch umsetzen wollte, haben sich heute durch das Feedback der Kunden und die schnelle Änderung des Marktes gewandelt. Durch die Möglichkeit der Nutzung der Apps über mobile Geräte werden Randthemen plötzlich zu Kernthemen und schneller als man denkt wird der Zugang über die mobile App der Hauptgeschäftszweig mit dem meisten Wachstumspotenzial. Viele Nutzer wählen Dienste gezielt danach aus, ob diese über mobile Geräte erreichbar sind. Ist das nicht der Fall, können sich Mitbewerber hier schnell Vorteile verschaffen, die nicht mehr aufholbar sind.

Aus Entwicklersicht

Erich, der Chefentwickler des Reiseportals, bemerkte es als erster: Die Zugriffszahlen auf Kataloginformationen wurden immer mehr, weshalb er nun schon zum wiederholten Male die Serverkapazitäten erhöhen musste. Eine Analyse der Logfiles ergab, dass, seit die App im App Store verfügbar war, viel mehr Anfragen von mobilen Geräten kamen als von klassischen Browsern. Inzwischen hatte seine Abteilung auch die Weiterentwicklung der App übernommen. Es fiel aber allen schwer, mit der bestehenden Codebasis zu arbeiten und notwendige Änderungen, wie Lokalisierung, oder einfache Features, wie die Buchungsanzeige, nachzurüsten. Das Problem waren die ständigen Abstürze der App, die darauf zurückzuführen waren, dass das komplexe Speicher-Handling der App nicht korrekt implementiert worden war. Sie holten sich Hilfe von Experten für mobile Entwicklung und waren so in der Lage, die App wenigstens zu stabilisieren und einfache Änderungen zu implementieren. Die Experten waren für die Entwicklung vor Ort und konnten so von der Erfahrung der Fachexperten profitieren und hatten Anforderungen schnell umgesetzt. Das Feedback der Kunden im App Store war inzwischen deutlich besser und die Downloadzahlen stiegen. Die Experten waren aber auch nicht in der Lage, die App um komplexere Features zu erweitern, weil die Architektur der App gar nicht darauf ausgelegt worden war. Sie empfahlen eine Neuentwicklung der App. Gleichzeitig war es notwendig das Backend zu erweitern, sodass die App darüber auch Buchungen von Reisen durchführen konnte.

Die Anforderungen an Apps in Bezug auf Erweiterbarkeit und Änderbarkeit sind nicht anders als an übliche Softwareprodukte. Viele Anforderungen werden erst erkennbar, wenn die Apps beim Kunden sind und diese das erste Feedback geben. Wenn man heute noch denkt, die Kunden wollen Feature A, erkennt man morgen, dass sie lieber Feature B wollen. Daher müssen Apps einfach und schnell erweiterbar sein. Diese Erweiterungen sollen aber auch zu späteren Zeitpunkten nicht teurer werden, als wenn man sie von Anfang an mit eingeplant hat. Man muss also bei der Entwicklung darauf achten, dass man eine flache Aufwandskurve erreicht (Abb. 1).

Abb. 1: Flache Aufwandskurve vs. steile Aufwandskurve

Um eine flache Aufwandskurve zu erreichen, muss man einige Dinge beachten, die dazu führen, dass die Entwicklung anfangs teurer wird: Eine flache Aufwandskurve erreicht man durch konsequente Anwendung von Refactorings. Refactorings sind Änderungen an der internen Struktur, die das nach außen sichtbare Verhalten nicht verändern. Damit man sicherstellen kann, dass diese Refactorings das Verhalten nicht ändern, sind automatisierte Tests notwendig. Diese zu erstellen, bedeutet vor allem in der Startphase einen Mehraufwand, der sich jedoch schnell auszahlt. Auch während der Entwicklung ist es wichtig, früh und häufig Feedback einzuholen, das dazu dient, zu prüfen, ob die Entwicklung auf dem richtigen Weg ist. Lassen sich alle Funktionalitäten so bedienen wie angedacht oder bekommt man durch die Bedienung noch bessere Ideen, die sich umzusetzen lohnen? Dieses Feedback können Beta-Tester oder Poweruser als Early Adopter gezielt geben.

Zweiter Versuch

Erich hatte nun die Experten für mobile Apps im Haus und beauftragte sie, die App für neu zu entwickeln. Die Entwickler dieser Firma waren immer paarweise am Rechner und entwickelten die Feature so zu zweit. Pairprogramming nannten sie das und versprachen sich davon ein besseres Design der Anwendung durch viele kleine Feedbackzyklen zwischen den Entwicklern. Dadurch, dass auch immer zwei Entwickler an einer Codestelle entwickelt haben, waren sie sehr flexibel, wenn mal ein Entwickler ausfiel. Es bildeten sich keine Wissensinseln. Sie hatten auch eine Technik namens Test-driven Development eingeführt. Damit schrieben sie zuerst die Tests und dann entwickelten sie die Funktionalität. Zusammen mit automatisierten Tests, die die App über die Oberfläche testeten, waren sie in der Lage jederzeit schnell die Funktionsfähigkeit der App zu demonstrieren. Sie arbeiteten in kurzen Zyklen, die sie „Sprints“ nannten. Ein Sprint dauerte immer zwei Wochen. Am Ende des Sprints lieferten sie immer eine Version der App an interne Beta-Tester aus. So konnten schon während der Entwicklung viele Verbesserungen am Konzept vorgenommen werden, die sonst erst bei der Auslieferung der App aufgefallen wären.

App 2.0

Die Art und Weise, wie man gute Apps entwickelt, unterscheidet sich nicht von der Art und Weise wie man im Allgemeinen gute Software entwickelt. Als Weiterentwicklung der ersten Apps, die als Visitenkarten ihren Dienst geleistet haben, aber nicht sonderlich erweiterbar waren, sind Apps nach App 2.0 von der Struktur her anders aufgebaut. Das App-2.0-Manifest (Kasten: „Das App-2.0-Manifest“) liefert hier für Entwickler einfache Regeln, wie gute Apps gebaut werden sollten. Nicht nur Entwickler profitieren von diesen Regeln, auch eine Auswahl über vergleichbare Kriterien und die technische Abnahme von Apps, die durch Drittanbieter entwickelt wurden, wird damit möglich.

Manfred konnte den Tag, an dem die Version 2.0 der App des Reiseportals veröffentlich wurde, kaum erwarten. Dann war sie aber endlich durch den Review-Prozess gelaufen und die Kunden konnten die App herunterladen. Die App erreichte schon nach wenigen Monaten die Marke von einer Million Downloads. Das Portal erzielte über die App mehr als ein Drittel seines Umsatzes – Umsatz, der durch die App erst generiert wurde. Weitere Features wie Buchungsvorschau, Rabatte für Stammkunden und kurzfristige Sonderaktionen wurden durch die neue App erst möglich und relativ zügig eingebaut. Inzwischen haben die Experten das Unternehmen verlassen, nicht aber ohne die internen Entwickler zu schulen, die App selbst weiterzuentwickeln.

Das App-2.0-Manifest
Wir wollen für unsere Kunden Werte schaffen, indem wir Apps in hoher Qualität entwickeln, die flexibel und schnell an die Bedürfnisse des Marktes angepasst werden können. Folgende Punkte beachten wir dabei:

1. Wir testen unsere Software konsequent automatisiert
2. Wir erstellen für unsere Kunden häufige Releases und erhalten so schnelles und frühes Feedback
3. Wir schämen uns nicht für unseren Quellcode und legen ihn unseren Kunden offen
4. Wir nehmen jedes Feedback ernst und verbessern damit die App

Fazit

Die Entwicklung von Apps nach dem App-2.0-Manifest kann zu Beginn teurer werden. Diese Investition in hohe Softwarequalität zahlt sich aber spätestens dann aus, wenn die Nutzer mit der App zufrieden sind und dies durch gute Bewertungen im App Store quittieren. Erweiterungen der App mit neuen Features, die zu Beginn der Entwicklung noch gar nicht absehbar waren, sind nun einfach und kostengünstig möglich. Damit lassen sich mit mobilen Apps bestehende Geschäftszweige ausbauen und neue Geschäftszweige erobern.

Aufmacherbild: „Mobile Technology Next Generation Media as a Art“ von Shutterstock / Urheberrecht: kentoh

Geschrieben von
Sven Günther
Sven Günther
Sven Günther ist Jahrgang 1971. Seine berufliche Laufbahn begann mit der Entwicklung und Reparatur elektronischer Baugruppen. Er studierte an der Fachhochschule Brandenburg Informatik mit den Schwerpunkten Softwareentwicklung und Mikroprozessortechnik. Seit 1997 entwickelt Sven Software in Java und C-Sprachen sowohl im Enterprise-Umfeld als auch für mobile Geräte. Agile Entwicklungsmethoden hat er 2007 für sich entdeckt und ist seitdem begeistert von ihnen. Sein besonderes Interesse gilt der Architektur und dem Design von Softwaresystemen sowie der testgetriebenen Softwareentwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.