Launchplan für eine Mobile App

Was enthalten ist

Eine Mobile App auszuliefern ist etwas anderes, als Software auf einen Server zu bringen. Jemand anderes entscheidet, wann Ihr Build live geht, und der Plan muss das zeigen. Die Vorlage trennt die Arbeit, die Sie steuern, von der Wartezeit, die Sie nicht steuern:

• Stabilisierung des Builds — Feature-Freeze, Auswertung von Abstürzen und ANR-Fehlern, Arbeit an Leistung und Speicher, Barrierefreiheit und Tests auf der Gerätematrix sowie der Release-Candidate-Build. Meilenstein: Release Candidate steht.
• Beta-Test — Upload nach TestFlight und in den internen Play-Track, interne Beta, Gewinnung externer Testerinnen und Tester, die externe Runde und die Auswertung der Rückmeldungen. Meilenstein: Beta-Kriterien erfüllt.
• Store-Eintrag und Assets — Recherche zu Suchbegriffen und Kategorie, Name und Beschreibung, Screenshots und Vorschauvideo, Symbol und Grafiken, die Angaben zum Datenschutz und der Fragebogen zur Altersfreigabe.
• Einreichung und Prüfung — Prüfung der Richtlinienkonformität vor der Einreichung, Einreichung in beiden Stores, die Wartezeit der Prüfung und ein echter Puffer für Ablehnung und erneute Einreichung. Meilenstein: freigegeben und veröffentlichungsbereit.
• Stufenweiser Rollout — Gestaffelte Veröffentlichung an 1, 10 und 50 Prozent, wobei vor jeder Ausweitung die absturzfreie Rate geprüft wird. Meilenstein: volle Verfügbarkeit.
• Day-One-Patch und Beobachtung — Beobachtung von Abstürzen und ANR-Fehlern, das reservierte Patch-Fenster, Antworten auf Store-Bewertungen und die Auswertung der Bindung in Woche eins.

So passen Sie sie an

1. Setzen Sie den Einreichungstermin und rechnen Sie vorwärts, nicht rückwärts — die Prüfdauer können Sie nicht stauchen.
2. Teilen Sie Einreichung und Prüfung je Store auf, wenn iOS und Android unterschiedlich takten; die Prüfdauern unterscheiden sich.
3. Verlängern Sie den Ablehnungspuffer bei einer ersten Einreichung, bei Abo-Apps und bei allem, was Kontolöschung, Gesundheitsdaten oder nutzergenerierte Inhalte berührt.
4. Passen Sie die Rolloutstufen an die Plattform an; der gestaffelte Rollout bei Google Play und die phasenweise Veröffentlichung im App Store laufen nicht identisch.
5. Halten Sie das Patch-Fenster mit namentlich benannten Personen im Plan — ein unbesetztes Patch-Fenster ist nur eine leere Woche.
6. Setzen Sie Release Candidate, Beta-Abschluss, Store-Freigabe und volle Verfügbarkeit als Meilensteine; nach diesen vier Terminen wird gefragt.

Hinweise zur Terminplanung

• Reichen Sie die Store-Metadaten ein, bevor das Binary final ist. Screenshots, Beschreibungen und die Datenschutzangaben lassen sich unabhängig vorbereiten und prüfen und sollten nie der Grund sein, warum der Einreichungstag wartet.
• Kündigen Sie keinen Termin an, der von einer noch nicht erteilten Freigabe abhängt. Hängen Sie das Marketing an den Freigabemeilenstein, damit eine Ablehnung die Kampagne automatisch verschiebt.
• Prüfen Sie die absturzfreie Rate auf jeder Rolloutstufe. Der Sinn eines stufenweisen Rollouts ist der Halt zwischen den Stufen; wenn niemand eingeplant ist, der auf die Zahlen schaut, bringt die Staffelung nichts.
• Reservieren Sie das Patch-Fenster vor dem Launch, nicht danach. Wer den Day-One-Fix bauen soll, ist sonst am Launchtag schon dem nächsten Sprint zugeordnet.
• Gewinnen Sie externe Testende Wochen im Voraus. Eine brauchbare Zahl echter Geräte zusammenzubekommen dauert länger als geplant, und eine dünne Beta findet nichts.
• Setzen Sie den Basisplan mit dem Release Candidate. Alles davor ist Schätzung; danach besteht der Plan überwiegend aus fremden Warteschlangen und gehört als Abweichung verfolgt.

Verwandte Vorlagen

• Gantt-Diagramm-Vorlage für Produkteinführungen
• Gantt-Diagramm-Vorlage für Softwareentwicklung
• Projektplan für die Produktentwicklung
• Alle Gantt-Diagramm-Vorlagen ansehen

Diese Vorlage ist auf Deutsch. Noch nicht übersetzte verwandte Seiten öffnen sich auf Englisch.

Häufige Fragen