Im letzten Teil unserer Serie (Grundlagen einer herausragenden mobilen App: Teil 1 – Das Produkt, Teil 2 – Die Technologie) wollen wir uns ansehen, wie wir sicherstellen können, dass wir alle erwähnten Punkte der ersten beiden Teile auch tatsächlich so umsetzen können. Wie schaffen wir es, ein herausragendes Produkt zu definieren und dieses auch tatsächlich auszuliefern?
Mit einem herausragenden Team!
Sehen wir uns also die Kriterien an, die ein gutes Team ausmachen und die Dinge, die ein gutes Team beherzigt, um eine herausragende App liefern zu können.
Schneller Turnaround
In der Luftfahrt ist der Turnaround, also die Vorbereitung für den nächsten Flug, einer der zentralen Punkte. Ein Flugzeug am Boden bringt keinen Umsatz, daher sind die Fluggesellschaften bemüht, die Zeit am Boden zu kurz wie möglich zu halten.
Quelle: https://commons.wikimedia.org/wiki/File:A380_of_Lufthansa_at_FRA_EDDF_2011-06-26.jpg
Bei der Entwicklung einer App verhält es sich ähnlich: Neue Funktionalitäten, Änderungen und Bugfixes müssen so schnell wie möglich beim Nutzer ankommen, um ihm das bestmögliche Erlebnis zu bieten. Änderungen, die zwar implementiert sind, aber noch auf eine Freigabe warten, sind wie ein Flugzeug am Boden: Sie bringen keinen Gewinn.
Es gilt daher, ein sowohl technisches, als auch organisatorisches Konstrukt zu finden, was es uns ermöglicht, implementierte Änderungen so schnell wie möglich auszuliefern. Auf technischer Ebene helfen hierbei Continuous Integration und Continuous Deployment Setups, die Änderungen im Code reproduzierbar und automatisiert in eine neue App-Version überführen. So kann sich das Entwicklungsteam darauf konzentrieren, an echten Features zu arbeiten und echten Mehrwert für den Nutzer zu erbringen.
Analog hierzu muss auf organisatorischer Ebene sichergestellt sein, dass Änderungen ohne endlose Feedbackschleifen und Verzögerungen an den Nutzer ausgeliefert werden können.
Die Erfahrung hat gezeigt, dass hier schnell ein Lerneffekt bei allen an der Entwicklung Beteiligten einsetzt: Ist es einfach möglich, neue Ideen schnell umzusetzen und zum Nutzer zu bringen, so werden auch kleine Verbesserungen mit Energie vorangetrieben. Ist dies nicht möglich, dann lässt auch die Motivation nach, überhaupt noch nach Verbesserungen zu suchen. Die App beginnt zu stagnieren, die Nutzerbewertungen werden schlechter, und irgendwann verschwindet die App still und leise.
Realistische Testfälle
Das Testing von Apps findet üblicherweise in einer Umgebung statt, die mit der Realität, wie sie die Nutzer erleben, wenig zu tun hat. Gerade die Kommunikation mit Backends, die Daten für die App liefern, sieht für den Tester in einem Firmennetzwerk mit Glasfaseranbindung vollkommen anders aus als für den tatsächlichen Nutzer, der in der realen Welt unterwegs ist.
Auch hier bringt es ein Tweet sehr gut auf den Punkt:
Es sollten daher immer auch und besonders diese Spezialfälle betrachtet werden: Wie verhält sich die App in solch einem Szenario? Was ist das Benutzererlebnis?
Häufig lässt sich hier bereits mit kleinen Mitteln eine große Wirkung erreichen. Wenn keine Daten vom Backend bezogen werden können, fühlen sich viele Nutzer schon deutlich besser, wenn sie wenigstens verstehen, dass gerade keine Aktion durchgeführt werden kann, weil die Netzwerkverbindung (zu) schlecht ist. Ein kleines Icon, das signalisiert, “die App ist offline”, kann hier den Unterschied zwischen einem schlechten und guten Nutzererlebnis machen.
Reale Erfahrungen
Jeder einzelne im Entwicklungsteam sollte die Möglichkeit haben, reale Erfahrungen mit der App zu machen und diese in einem echten Umfeld zu nutzen. Es sind häufig die kleinen Dinge, die abseits von geplanten Usertests und Feldstudien auffallen und ungefiltert zum Entwickler gelangen sollten.
Geschehen kann dies auf verschiedenste Arten und Weisen. Die einfachste ist hierbei die App als Mitglied des Entwicklungsteams tatsächlich selbst für sich zu nutzen und plötzlich eigene Erfahrungen in der Rolle des Nutzers zu machen. Doch es existieren auch subtilere Mittel und Wege.
Ein Entwicklungsleiter der App einer Fluggesellschaft berichtete darüber, dass es in regelmäßigen Abständen üblich und gewünscht war, dass sich die Entwickler einer App einfach nur am Flughafen ans Gate setzten und beobachteten, wie sich die Passagiere vor dem Flug verhielten. Nutzen sie beim Einsteigen die App? Wenn ja, wie schnell funktioniert der Scanprozess? Wie ist der Eindruck, den der Passagier vermittelt? Mit einfachsten Mitteln, nämlich nur der Beobachtung von außen, ohne überhaupt mit dem Passagier zu sprechen, ließe sich so schon eine Menge ableiten.
Diese Vorgehensweise mag nicht für alle Apps und alle Anwendungsfälle gleichermaßen anwendbar und nützlich sein, sie soll aber zeigen, dass es auch andere Wege gibt, als entweder nur darauf zu vertrauen, dass schon alles so funktionieren wird, wie es während der Konzeptionsphase geplant wurde, oder mit enormen Aufwand ein “richtiges” User Testing aufzusetzen.
Das Weitergeben von Wissen
Alle an der Entwicklung Beteiligten, seien es Entwickler, Tester, Business Analysten, User Experience Designer oder andere, lernen im Laufe der Lebenszeit einer App. Sie lernen nicht nur für ihren eigenen Bereich wichtige Details, wie z.B. die korrekte Verwendung von UI Komponenten oder der Kommunikation mit Backends, sondern werden auch immer mehr Experten für die Business-Usecases.
Es wäre nicht das erst Mal, dass ein Entwickler, der bestimmte Funktionalitäten implementiert hat und sich intensiv mit jedem einzelnen Ausnahmefall beschäftigt hat, mehr über das große ganze hinter der Anforderung gelernt hat als Sachbearbeiter, die sich schon seit Jahren mit dem Thema beschäftigen.
Auf dieses erworbene Wissen und die gemachten Erfahrungen kann und sollte aufgebaut werden. Ich selbst habe sehr gute Erfahrungen mit informellen monatlichen Treffen gemacht, bei denen einer oder mehrere am Projekt Beteiligte sich einen bestimmten Aspekt oder Usecase herausgreifen und ihn dem restlichen Team in lockerer Runde vorstellen. So wird das Wissen nicht nur auf mehr und mehr Köpfe verteilt, es entsteht “nebenbei” ein Gefühl der Teamzusammengehörigkeit, in der jeder für den anderen da ist und ihm hilft, die eigene Arbeit einfacher und leichter zu gestalten.
Vermittlung von Wissen in internen Veranstaltungen und öffentlichen Konferenzen
Analyse und Anpassung
Was für die App als Produkt gilt, das gilt auch für das gesamte Entwicklungsteam: Es gibt immer Dinge, die besser gemacht werden können, und immer Dinge, die sich ändern.
Mag es zu Beginn der Entwicklung vielleicht noch keine Notwendigkeit geben, einen “echten” Tester mit ins Team zu holen, so sieht das nach einer Weile vielleicht schon ganz anders aus. Zu einem bestimmten Zeitpunkt mag ein bestimmtes Framework oder eine bestimmte Technologie genau die richtige Lösung gewesen sein, doch gibt es nach einer Weile vielleicht schon wieder ganz neue Tools, die bessere Ergebnisse mit weniger Aufwand ermöglichen.
Inne zu halten und zu überprüfen, ob der aktuelle “Modus Operandi” noch der richtige ist (und anschließend die richtigen Schritte zu tun), hilft nicht nur dabei, in einem sich immer schneller ändernden Umfeld nicht unterzugehen, sondern erlaubt es, besser zu werden und spannende neue Dinge zu erleben.
Denn wie bereits Henry Ford wusste: “Wer immer tut, was er schon kann, bleibt immer das, was er schon ist.”
Ob beim Schreiben von Code, der Analyse von Anforderungen oder der Ideenfindung mit seinem Team – für ihn geht es nicht nur darum, die "richtige" Lösung zu finden, sondern auch dafür zu sorgen, dass alle Beteiligten den Spaß an ihrer Arbeit behalten.
Ursprünglich von der Technik in der Softwareentwicklung fasziniert, widmet Christian heute einen großen Teil seiner Zeit der Interaktion mit Menschen und setzt sich leidenschaftlich für ein besseres Verständnis zwischen Entwicklungsteams und Business-Stakeholdern ein.
Bei schönem Wetter trifft man Christian häufig auf dem Fahrrad oder beim Joggen im Park. Bei schlechtem Wetter findet man ihn eher auf der Couch, wo er vergeblich versucht, seinen Netflix-Konsum unter Kontrolle zu halten.
