Wäre es nicht super, wenn du die größte Falle in deinem App-Projekt vermeiden könntest? Dafür habe ich dir diesen Artikel verfasst, mit der wichtigsten Lektion meiner Erfahrung als Entwickler. Es gibt viele Beiträge im Internet zu dem Thema „typische Fehler bei Software-Projekten“ (definitiv eine Google-Suche für dich wert), ich habe jedoch diesen Post absichtlich schlank gefasst, um den Kern der Sache zu treffen. Hast du diesen Punkt im Griff, dann werden dir einige Folgeprobleme nämlich auch nicht über den Weg laufen.
Es fängt nicht im Projekt an, sondern vorher. Sogar vor der Planung mit dem Entwickler. Es ist der erste Moment in dem du dafür sorgen kannst, dass die Wahrscheinlichkeit der folgenden Schwierigkeiten minimiert wird.
Plane erstmal keinen Releasezeitpunkt
Bevor du dir denkst „ja wann dann?“, erst die Gegenfrage: Weißt du wie aufwändig deine App zu entwickeln ist und wie viel Zeit da reinfließen muss? Also kannst du vorweg entscheiden wann die App fertig sein kann? Nein. Klingt doch einleuchtend, was? Interessanterweise ist es für Entwickler nicht ungewöhnlich Projektanfragen zu bekommen in denen nichts wirklich klar ist… außer das Releasedatum.
Ja moment.
Das ist wie zum Architekten zu gehen, um sich ein Haus bauen zu lassen. Man hat noch kein Grundstück gekauft, aber das Einzugsdatum ist schon fix, der Mietvertrag der alten Wohnung gekündigt, Nachmieter organisiert und neue Möbel sind bestellt.
Manchmal gibt es äußere Einflüsse, die ein gewisses Datum rechtfertigen, ja. Meiner Erfahrung nach ist dieses Datum meist selbst gesetzt. „Das Marketing ist schon angelaufen“ heißt es gerne. In der Regel ist dieses Datum auch eher zeitnah und mir müsste erst noch ein Projekt über den Weg laufen, wo ein Releasedatum mit genügend Puffer geplant ist.
Ein Releasedatum ist immer, wirklich immer, ein Kompromiss zwischen „wie viel Zeit nehmen wir uns?“ und „welche Features werden wir entwickeln?“. Es beinhaltet immer beides und wenn eines fertig bestimmt ist, dann befindet sich der gesamte Handlungsspielraum im anderen. Gibt es also Gründe für ein gewisses Datum, dann solltest du darauf vorbereitet sein bei der Planung zu realisieren, dass möglicherweise nicht alles im geplanten Zeitraum machbar ist. Das heißt, wir sind bei der Frage angelangt wie wichtig die einzelnen Teile der App sind und ob eine Teilmenge der Funktionen für den Release genügen.
Das selbe kann natürlich auch während des Projektes passieren.
Verändere nicht einfach den Planungsumfang
Ein Plan ist kein Plan, wenn er andauernd verändert wird. In einem vorherigen Artikel bin ich bereits auf „Feature creeping“ eingegangen und was es verursacht. Feature creeping ist, wenn sich neue Features als Funktionalität in den aktuellen Planungsumfang einschleichen. Meistens passiert das getarnt als tolle neue Idee oder als „kannst du nicht mal kurz/schnell…“. Ein Softwareprojekt lebt. Es werden Fehler gefunden oder der Entwickler findet raus, dass eine Sache doch schwerer zu erledigen ist als gedacht. Der Plan muss flexibel genug sein, um darauf eingehen zu können. Das ist normal und ein guter Entwickler wird dafür sorgen, dass das in der Planung berücksichtigt wird. Ich rede jedoch davon, dass es oft passiert, dass der Umfang verändert und das gesetzte Datum als undiskutabel fix behandelt wird.
Und jetzt zur Frage warum ich die Zeitplanung zuerst genannt habe: weil ein zu straffer Zeitplan dafür sorgt, dass die nächsten beiden Fehler gemacht werden:
- Qualitätssicherung überspringen
- Benutzertests überspringen
Überspringe weder die Qualitätssicherung als auch Nutzertests
Zuerst sollte ich an dieser Stelle darauf eingehen, was ich damit meine. Qualitätssicherung ist nicht, wenn du dir die App zum Testen installierst und ein paar Mal durchtappst. Qualitätssicherung ist der Versuch als Benutzer die App absichtlich kaputtzumachen. Das heißt: Fehlerfälle testen, unterschiedliche Geräte mit unterschiedlichen Bildschirmgrößen testen, Quatsch in Eingabefelder eingeben, unlogische Benutzungsreihenfolgen ausprobieren, App bei schlechtem oder nicht vorhandener Internetverbindung testen… In größeren Projekten stellt man sogar explizit Leute dafür an den ganzen Tag nichts anderes zu tun.
Genau so mit Nutzertests. Vor allem, wenn die App auch Daten von einem Server beziehen muss: Woher weißt du, dass alles glattgehen wird? Woher weißt du, dass der Server nicht in die Knie geht, wenn zum erfolgreichen Launch gleich ein paar Hundert Leute probieren die App zu benutzen? Ohne Belastungstest springen dir vielleicht Kunden ab, weil sie auf ein unzuverlässiges System gelassen werden, weil die Tests wegen Zeitnot übersprungen wurden.
Ja, dein Projekt mag nicht riesig sein, aber getestet werden muss es trotzdem. Auch Entwickler machen Fehler und diese sollten gefunden werden, bevor der Kunde darauf stößt. Oder vielleicht sind es keine Fehler, sondern die App ist an entscheidenden Stellen zu langsam oder zu kompliziert. Genau so wie ein Autor einen Lektor braucht, so braucht ein Entwickler einen Tester. Genau so wie der Autor seine eigenen Sätze so oft gelesen hat, dass die Tippfehler oder Unklarheiten nicht auffallen, so kann es sein, dass dir und Entwickler Sachen durch die Lappen gehen.
Ist jetzt im Projekt der Zeitplan besonders eng, dann ist es leicht hier ein Auge zu zu drücken und zu tun als ob alles schon gut gehen wird. Ja, du kannst Zeit sparen und in dem Fall solltest du dir bewusst sein, dass du mit dem Feuer spielst.
Dieser Artikel als Podcast-Folge
Meine Artikel kannst du auch einfach als Podcast hören. Direkt diese Folge im Web-Player oder in jeder Podcast-App:
Apple Podcasts: https://podcasts.apple.com/de/podcast/applify/id1489203144
Overcast: https://overcast.fm/itunes1489203144/applify-app-entwicklung-mit-jan-brinker
Spotify: https://open.spotify.com/show/6tVmQfMCZ7VgHU9iZD2VIU
Google Podcasts: https://podcasts.google.com/?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xMDkwMTQ4Yy9wb2RjYXN0L3Jzcw%3D%3D