Wäre es nicht super, wenn du die größte Falle im App-Projekt vermeiden könntest? Darum geht es hier: eine Lektion aus meiner Erfahrung als Entwickler. Es gibt viele Artikel zu „typischen Fehlern bei Software-Projekten”, aber ich halte diesen Post bewusst schlank. Hast du diesen einen Punkt im Griff, wirst du viele Folgeprobleme gar nicht erst sehen.
Plane noch kein Releasedatum
Bevor du denkst „ja wann dann?”: Weißt du, wie aufwändig deine App zu entwickeln ist? Kannst du also entscheiden, wann sie fertig sein kann?
Nein. Klingt einleuchtend, oder?
Trotzdem ist es für Entwickler nicht ungewöhnlich, Anfragen zu bekommen, bei denen kaum etwas klar ist. Außer dem Releasedatum.
Ja moment.
Das ist wie zum Architekten zu gehen um sich ein Haus bauen zu lassen: noch kein Grundstück, aber das Einzugsdatum steht fest, der Mietvertrag der alten Wohnung ist schon gekündigt.
Manchmal gibt es äußere Einflüsse, die ein bestimmtes Datum rechtfertigen. Meiner Erfahrung nach ist dieses Datum aber meist selbst gesetzt. „Das Marketing ist schon angelaufen” heißt es gerne. Und mit ausreichend Puffer geplant habe ich selten ein Releasedatum gesehen.
Ein Releasedatum ist immer ein Kompromiss zwischen Zeit und Funktionsumfang. Ist eines fest, liegt der gesamte Spielraum im anderen. Wenn du also Gründe für ein bestimmtes Datum hast, musst du darauf vorbereitet sein, dass möglicherweise nicht alles im geplanten Zeitraum machbar ist.
Verändere nicht einfach den Planungsumfang
Ein Plan ist kein Plan, wenn er andauernd verändert wird. Feature creep, also das Einschleichen neuer Features gerne getarnt als „kannst du nicht mal kurz…”, ist ein eigenes Thema, das ich anderswo behandelt habe.
Hier geht es um etwas Spezifischeres: Ein zu straffer Zeitplan führt fast zwangsläufig dazu, dass die folgenden zwei Fehler gemacht werden.
Überspringe weder Qualitätssicherung noch Nutzertests
Qualitätssicherung ist nicht, wenn du die App einmal kurz durchklickst. Qualitätssicherung ist der Versuch, die App als Benutzer absichtlich kaputtzumachen: Fehlerfälle testen, unterschiedliche Geräte und Bildschirmgrößen ausprobieren, Unsinn in Eingabefelder eingeben, unlogische Reihenfolgen durchspielen, schlechte oder fehlende Internetverbindung simulieren. In größeren Projekten stellt man eigens Leute dafür an.
Genauso mit Nutzertests. Vor allem, wenn die App Daten von einem Server bezieht: Woher weißt du, dass der Server standhält, wenn beim Launch plötzlich Hunderte Nutzer gleichzeitig rein wollen? Ohne Belastungstest riskierst du, dass Kunden auf ein unzuverlässiges System losgelassen werden und sofort wieder abspringen.
Genau wie ein Autor einen Lektor braucht, weil er seine eigenen Sätze so oft gelesen hat, dass Tippfehler und Unklarheiten unsichtbar werden, braucht ein Entwickler jemanden der testet. Bugs, die du und der Entwickler nicht mehr sehen, werden sonst der Kunde finden.
Ist der Zeitplan jetzt besonders eng, ist es verlockend, hier ein Auge zuzudrücken und zu hoffen, dass es schon gut geht.
Ja. Du kannst Zeit sparen. Aber dann solltest du dir bewusst sein, dass du mit dem Feuer spielst.