Durchs wilde Kurdistan – App Entwicklung in der Praxis

In den vergangenen 4 Monaten hatte ich das Vergnügen, Entwicklung und Launch einer App auf vier verschiedenen mobilen Plattformen zu managen. Die hier geschilderten Erfahrungen sollen einige Anforderungen an die Entwicklungssteuerung deutlich machen, einige wesentliche Unterschiede der App Stores beleuchten und anderen helfen, unnötige Sackgassen zu vermeiden.

Meine Aufgabe bestand in der Steuerung der Entwicklung einer Online-Anwendung auf iPhone, Android, BlackBerry und Windows mobile. Die Entwicklung erfolgte nach Agile Methodik in Scrum-Teams über einen Zeitraum von vier Monaten.

Um es auf den Punkt zu bringen: es war sehr, sehr anstrengend. Und: es war furchtbar spannend und großartig. Wir haben wilde Ideen ausprobiert, dumme Fehler gemacht und viel gelernt.

Hier die wichtigsten Learnings der letzten Monate:

1. Schnelldreher

Der agile Ansatz ist für die Entwicklung mobiler Apps zwingend. Der Grund ist einfach: mobile Anwendungen entwickeln sich heute mit einer unglaublichen Dynamik weiter. In Software-Lebenszyklen zu denken ist ein Fehler – die Dynamik von Apps ist die von Singles in den Top-100. Ich weiß nicht, welche brandneuen Funktionen in 6 Monaten in meiner App bereits zwingend sind. Ein belastbarer Planungshorizont von 3 Monaten ist heute die Realität.

2. Don’t try this

Wenn Sie Ihre App auf verschiedenen Plattformen entwickeln, entkoppeln Sie den zeitlichen Release der verschiedenen Plattformen. Zeitgleicher Launch mag gerade größeren Brands attraktiv erscheinen – Marketing und PR kann so gebündelt werden. Realistisch ist er nicht. Kann klappen, ist aber unnötiger Ehrgeiz: so viel bringt es nicht, dass es die grauen Haar wert ist.

3. Ohr an die Leitung (auch wenn es weh tut)

Über die App Stores erhalten wir direktes Feedback unserer Anwender. iTunes ist hier speziell: bittet Nutzer beim Löschen einer App um eine Bewertung (Rate-on-Delete). Das sorgt für einen hohen Anteil an kritischen Stimmen. Sowas zu lesen tut mir weh. Ich tue es trotzdem: der Nutzer hat Recht – auch wenn er dabei brüllt.

4. Schneller Bugfix is’ nicht

Die Qualitätsprüfungen von Apple, RIM und Microsoft sind zeitlich eine Black Box. Einen Bugfix kann man nicht „mal eben“ nachschieben. Wer diese Lektion erlebt, erlebt physische Schmerzen: Man will brüllen: Leute, es ist Dringend! Aber: Man darf den Assessor von Apple, RIM, Microsoft nicht anbrüllen. Sonst wird er vielleicht sickig. Dumme Situation. Man bleibt höflich, wartet.

Release early, release often klappt heute leider nicht. Zumindest nicht, wie wir es vom Web gewohnt sind. Ausnahme: Android. Da kann man eine gepatchte Version instantan publizieren. Großer Vorteil. Falls/Wenn Android irgendwann eine breite Nutzerschaft hat, wird das wichtig.

5. QM: Ehefrau, nicht Geliebte

Das einzige was hilft, Situationen wie in Punkt 4 zu vermeiden ist QM. Ungeliebte, so was von wichtige QM! QM nörgelt. Ist nie zufrieden. Und ist dennoch der wichtigste Partner der Entwicklung.

Die meisten denken zu wenig über QM nach. Ich unterschätze das regelmäßig.

Fakt ist, für QM muss eben so viel Zeit und Intelligenz aufgewendet werden wie für die Entwicklung. Manchmal braucht QM deutlich mehr Zeit: Ein Fix ist schnell gemacht. Aber wenn der Fix zu schnell gemacht wird, erzeugt er einen noch größeren Bug.

6. Graue Materie

Die App Stores liefern eine Menge Information. Über meine App ebenso wie über Wettbewerber-Apps.

Wo steht meine App im Ranking? Wo stehen die Apps der Wettbewerber? Wie oft wird meine App pro Tag runtergeladen? Wie wird das Update angenommen? Über welche Suchworte werden meine Wettbewerber gefunden? Was begeistert Nutzer an den Apps meiner Wettbewerber?

Wer eine Online App führt – also eine App, die Content live lädt, oder Push Notifications nutzt – hat natürlich 10-mal mehr Daten.

7. Der Unterschied zwischen Männern und Jungs

Die Zahlen verfolgen macht so lange Spaß, wie sie hochgehen. Wenn sie runtergehen, hört der Spaß auf. Aber gerade dann heißt es: hingucken. Das kostet Überwindung. Wer es ernst meint mit seiner App, wer langfristig denkt, bleibt dran. Macht Drilldowns, analysiert, leitet ab, verbessert, released. So lange, bis man den Trend gedreht hat.

Dies sind meine Erfahrungen der letzten Monate. Über jedes dieser Themen könnte ich vermutlich einen Kurzroman schreiben oder drei Stunden frei erzählen. Da dafür wenig Zeit bleibt, werde ich jeden der sieben Punkte im Laufe der kommenden Wochen auf mobile zeitgeist vertiefen.

“App Entwicklung in der Praxis” ist eine neue mobile zeitgeist Serie, in der ich Erfahrungen und Erkenntnisse aus der täglichen Praxis darstellen werde. Falls der/die eine oder andere ähnlich gelagerte, oder ganz abweichende Erfahrungen gemacht hat, freue mich darüber zu hören. Und insbesondere eine angeregte Diskussion.

Über den Autor:

Martin Lawrence ist Produktmanager. Seit 10 Jahren im Thema Internet. Seit fünf Jahren mit Fokus auf Consumer-Anwendungen. Hat sowohl in Startups als auch in Konzernen gearbeitet. Was er am besten macht ist, Technologien voranzutreiben, die Kommunikation zu fördern und die Lebensqualität von Menschen zu verbessern. Er pendelt täglich ausgiebig zwischen Bielefeld und dem Ruhrgebiet. Mailt mit einem BlackBerry, surft mit dem iPhone. Da sich seine Familie und sein Freundeskreis auf ganz Deutschland verteilen, ist er dankbarer Nutzer der mobilen Apps von Twitter, Facebook und Xing.

Geduld ist nicht seine größte Stärke, daher treibt er die Entwicklung mobiler Anwendungen in seinem Team mit Leidenschaft und teilweise anstrengenden Ansprüchen. Er ist daher dankbar für die Nachsicht und Toleranz seiner Kollegen. Privat lebt er in einer Patchwork-Familie mit zwei sehr eigensinnigen Kindern und einer klugen Frau.

Seit März 2005 arbeitet Martin bei telegate MEDIA (vormals klickTel) als Senior Produktmanager. Hier ist er für die Entwicklung der Portale und mobilen Anwendungen verantwortlich.