Zeitplan für den App-Start: Abhängigkeiten, Schätzung und Abnahme

Die Werbung für den mobilen Shop ist bereits freigegeben, und der Starttermin steht im Kalender. Doch Zahlungen funktionieren bisher nur mit Testdaten, das Lager hat die Reservierungsregeln nicht bestätigt, und der frühere Dienstleister hat den Zugang zu den Entwicklerkonten. In dieser Situation bestimmt nicht die Anzahl fertiger Screens den Zeitplan für den App-Start, sondern die längste Kette offener Abhängigkeiten. Um den zugesagten Termin zu prüfen, verlangen Sie einen Plan mit Ergebnissen, Verantwortlichen und Bedingungen für den Übergang zwischen den Phasen.

Hier geht es darum, den Kalender eines mobilen Releases zu beurteilen — nicht darum, eine Technologie zu wählen oder eine allgemeingültige Monatszahl zu finden. Die Serverseite und die Freigaben zur Veröffentlichung können den Termin auch bei fertiger Oberfläche verändern.

1. Definieren Sie zuerst, welches Ereignis als Start gilt

„Die App ist fertig“ kann eine Prototypvorführung, die Übergabe eines Builds an Tester, die Einreichung zur Store-Prüfung oder die Verfügbarkeit für Kunden bedeuten. Das sind unterschiedliche Ereignisse. Halten Sie für den kommerziellen Start Plattform, Länder, Zielgruppe und Ablauf fest: Ein Kunde installiert die App, bestellt und bezahlt, und der Shop erhält die Bestellung im Produktivsystem.

Trennen Sie drei Termine: Bereitschaft zur Einreichung, erwartetes Veröffentlichungsfenster und Beginn der Werbekampagne. Den ersten steuert das Team wesentlich direkter als die Entscheidung einer externen Plattform. Ist das Marketing an einen bestimmten Tag gebunden, brauchen Sie einen vereinbarten Puffer und einen Ersatzvertriebskanal, nicht das Versprechen, die Prüfung im ersten Anlauf zu bestehen.

Halten Sie die Grenzen des ersten Releases schriftlich fest

Erstellen Sie eine kurze Liste der erforderlichen Abläufe und dessen, was bewusst später kommt. Beispielsweise ist die Gastbestellung jetzt nötig, während ein komplexer Austausch von Bonuspunkten in die nächste Version verschoben werden kann. Die Wahl zwischen Weblösung und App ist eine andere Entscheidung; dazu gibt es den Beitrag zur Architektur des mobilen Shop-Kanals. Hier gilt es, den gewählten Umfang in ein überprüfbares Release zu überführen.

2. Machen Sie aus geschätzten Stunden eine Abhängigkeitskarte

Der Aufwand zeigt, wie viel Arbeit zu erledigen ist. Die kalendarische Dauer berücksichtigt außerdem die Verfügbarkeit von Personen, Warteschlangen, ausstehende Antworten und die Ausführungsreihenfolge. Ein zusätzlicher Entwickler verkürzt nicht die Wartezeit auf den Vertrag mit einem Zahlungsanbieter. Zwei parallele Aufgaben sollten Sie auch nicht automatisch hintereinander einplanen.

Verlangen Sie für jedes Ergebnis die Voraussetzungen, die ausführende Person, die abnehmende Person und einen Nachweis der Bereitschaft. Ersetzen Sie „Integration“ durch konkrete Ergebnisse: Die Bestellung wurde übertragen, eine Kennung zurückgegeben, und eine wiederholte Anfrage erzeugt kein Duplikat. Markieren Sie den kritischen Pfad — die Folge abhängiger Arbeiten, deren Verzögerung das Release unmittelbar verschiebt.

Tragen Sie eine unbekannte Abhängigkeit nicht mit null Tagen ein. Bestimmen Sie eine verantwortliche Person und einen Prüftermin: Den API-Zugang belegt eine echte Anfrage, nicht die E-Mail „Die Dokumentation kommt noch“. Ohne Ergebnis bleibt die Schätzung an Bedingungen geknüpft.

3. Prüfen Sie das Backend vor den finalen Screens

Das Backend ist die Serverseite, die Daten speichert und Geschäftsregeln ausführt. Über eine API tauscht die App Anfragen und Antworten mit ihr aus. Für den Zeitplan zählt nicht nur, dass diese Komponenten existieren, sondern dass die benötigten Vorgänge stabil sind: Preise, Bestände, Authentifizierung, Warenreservierung und Zahlungsstatus.

Bestätigen Sie die Release-Bereitschaft des Backends mit einem kurzen End-to-End-Ablauf, bevor das gesamte Design fertig ist. Der Kunde legt einen Artikel in den Warenkorb, der Server prüft den Preis erneut, die Zahlung liefert ein Ergebnis, und die Bestellung erreicht das Warenwirtschaftssystem. Halten Sie fest, welches System maßgeblich ist und wie das Team einen Fehler erkennt.

Auch Fehlerzustände gehören in die Schätzung

Was passiert, wenn ein Artikel nach dem Hinzufügen zum Warenkorb ausverkauft ist, eine Zahlung verspätet bestätigt wird oder die Verbindung nach dem Tippen auf „Bezahlen“ abbricht? Diese Fälle betreffen sowohl den Code als auch den Kundendienst. Verlangen Sie eine Beschreibung der erwarteten Antwort, des erneuten Versuchs und des Schutzes vor doppelten Bestellungen.

Berücksichtigt die Schätzung nur Erfolgszustände, klären Sie sie vor der Terminzusage. Der separate Beitrag zur Spezifikation von Oberflächenzuständen hilft, Anforderungen an Fehler, leere Daten und Ladevorgänge vorzubereiten. Es geht nicht um zusätzliche Verschönerung: Ohne abgestimmte Zustände muss das Team bereits implementierte Vorgänge erneut bearbeiten.

4. Planen Sie die Regeln von Apple und Google als eigenen Zweig

Mit Stand vom 10. November 2026 verlangt Apple eine vollständige Prüfung des ersten Builds, der für externe Tests bei TestFlight App Review eingereicht wird; spätere Builds derselben Version benötigen möglicherweise keine vollständige Prüfung. Betatests ersetzen nicht die Einreichung der endgültigen Version beim App Store. „In TestFlight hochgeladen“ bedeutet daher nicht „Bereit für Werbung an alle“.

Für persönliche Google-Play-Konten, die nach dem 13. November 2023 erstellt wurden, gilt eine eigene Bedingung: ein geschlossener Test mit mindestens 12 Testern, die mindestens 14 Tage ununterbrochen angemeldet bleiben. Danach wird der Produktionszugang beantragt. Das ist weder eine allgemeine Anforderung für jedes Organisationskonto noch eine automatische Veröffentlichungserlaubnis nach Testende. Prüfen Sie die offiziellen Testanforderungen von Google Play für Ihr konkretes Konto.

Bestimmen Sie Verantwortliche für Tester, Rückmeldungen und Antworten an die Plattform. Bereiten Sie parallel Beschreibungen, Screenshots, Angaben zu Daten und den Zugang zur Funktionsprüfung vor. Das sind eigene Aufgaben und nicht der letzte Programmiertag.

Veröffentlichungskontrolle beschleunigt die Prüfung nicht

In App Store Connect können Sie eine manuelle Veröffentlichung nach Freigabe oder eine automatische wählen — auch frühestens zu einem bestimmten Datum. In Google Play lässt sich mit managed publishing die Veröffentlichung genehmigter Änderungen steuern; für die erstmalige Veröffentlichung einer App kann es jedoch nicht verwendet werden. Übertragen Sie den Aktualisierungsablauf eines bestehenden Produkts nicht ungeprüft auf dessen ersten Start.

Google weist darauf hin, dass die Verarbeitung von Änderungen einige Stunden bis sieben Tage, in Ausnahmefällen auch länger dauern kann. Das beschreibt den Plattformprozess und garantiert keinen Termin für Ihr Release. Trennen Sie Prüfung, mögliche Nacharbeit und tatsächliche Store-Verfügbarkeit im Kalender; eine Freigabe bedeutet nicht gleichzeitige Verfügbarkeit für alle Kunden.

5. Ein hypothetisches Beispiel: Warum mehr Personal den Termin nicht rettet

Stellen wir uns einen hypothetischen Shop vor, der seine erste mobile Version mit Katalog, Warenkorb und Zahlung startet. Für dieses Beispiel schätzt das Team die API-Vorbereitung auf 8 Arbeitstage, die mobile Umsetzung auf 10 und die anschließende End-to-End-Abnahme beider Arbeiten auf 4. Das sind frei gewählte Lehrzahlen, keine Marktbenchmarks, keine Fallstudie und keine Schätzung von GL.ua.

Erlaubt ein abgestimmter API-Vertrag, die ersten beiden Arbeiten gleichzeitig zu beginnen und parallel auszuführen, folgt die technische Bereitschaft auf den längeren Zweig und die Abnahme: 10 + 4 = 14 Arbeitstage. Hängt die mobile Arbeit von einer vollständig fertigen API ab, ergibt der sequenzielle Plan 8 + 10 + 4 = 22 Arbeitstage. Derselbe Aufwand führt zu unterschiedlichen Kalendern.

Angenommen, die API verspätet sich um 3 Arbeitstage: Ihr Zweig endet am 11. Tag, und der parallele Plan verschiebt sich auf 11 + 4 = 15 Arbeitstage. Ein zusätzlicher Designer ändert das nicht. Prüfen Sie stattdessen, ob sich die benötigten API-Vorgänge früher stabilisieren lassen, ohne die Abnahme am laufenden System durch Tests mit Platzhaltern zu ersetzen.

Alle diese Ergebnisse bedeuten nur technische Bereitschaft. Kontospezifische Testbedingungen, Store-Prüfungen und mögliche Korrekturen werden zusätzlich geplant. Arbeitstage dürfen nicht einfach Kalendertagen gleichgesetzt werden; berücksichtigen Sie den Teamplan, Wochenenden und die Verfügbarkeit der Personen, die das Ergebnis freigeben, gesondert.

6. Verknüpfen Sie das Budget mit Ergebnissen und Unsicherheit

Eine Terminschätzung für das mobile Release sollte genau zeigen, wofür der Auftraggeber bezahlt: Abhängigkeitsanalyse, API-Prüfung, mobile Umsetzung, Integrationen, Tests, Vorbereitung der Einreichung und Startbegleitung. Berücksichtigen Sie Umgebungen, kostenpflichtige Dienste, Konten, Monitoring und Betreuung nach Veröffentlichung separat. Diese Kosten verschwinden nicht durch weniger Screens.

Vergleichen Sie Angebote mit gleichen Grenzen: Sind Korrekturen nach Abnahme, Store-Unterlagen, erneute Einreichung und Kompatibilitätstests mit dem bestehenden Backend enthalten? Lassen Sie Basisumfang, Annahmen und Reserve für benannte Risiken getrennt ausweisen. Sonst kann ein niedrigerer Betrag nur bedeuten, dass ein Teil der Arbeit außerhalb des Kostenvoranschlags liegt.

Eine unbekannte Integration benötigt eine eigene Prüfung „funktioniert / Änderungen nötig / ungeeignet“ mit vereinbartem Budget und Zeitrahmen. Die Reserve sollte einem konkreten Risiko entsprechen, nicht einem beliebigen Prozentsatz.

7. Nehmen Sie das Release anhand von Nachweisen ab, nicht nach Fertigstellungsgrad

Führen Sie vor der endgültigen Entscheidung eine gemeinsame Abnahme auf vereinbarten Geräten und mit der produktiven Integrationskonfiguration durch. Abnahmekriterien für die App müssen geschäftlich verständlich und an einem bestimmten Build wiederholt prüfbar sein. „Zu 95% fertig“ erklärt nicht, ob bezahlte Bestellungen sicher angenommen werden können.

1. Durchlaufen Sie den Kauf von Installation und Anmeldung bis zur Bestellung im Warenwirtschaftssystem; prüfen Sie Betrag und Status.
2. Stellen Sie eine abgelehnte Zahlung, einen Netzwerkausfall und wiederholtes Tippen nach; stellen Sie sicher, dass kein Duplikat entsteht.
3. Prüfen Sie Preisänderungen, fehlenden Bestand, Abmeldung und die vorgesehene Wiederherstellung des Zugangs.
4. Gleichen Sie Einreichungsunterlagen mit dem Build-Verhalten ab und dokumentieren Sie offene Fehler sowie die Entscheidung zu jedem Blocker.
5. Bestimmen Sie Verantwortliche für Veröffentlichung, Bestellmonitoring und Kundenanfragen; vereinbaren Sie das Vorgehen bei einem kritischen Fehler.

Ein Wiederherstellungsplan besteht nicht nur aus „Wir spielen die alte Version zurück“: Installierte Apps können auf Kundengeräten bleiben. Planen Sie die Kompatibilität serverseitiger Änderungen, das Abschalten einer problematischen Funktion und die Information über einen alternativen Kaufweg ein. Den konkreten Mechanismus muss das Team vor dem Start testen.

8. Welche Schätzung eine Entscheidung tragen kann

Ein fundierter Plan enthält Release-Grenzen, Abhängigkeiten, Verantwortliche, Abnahmenachweise und ein Fenster für externe Prüfungen. Ohne Bestätigung einer kritischen Abhängigkeit ist der Termin eine bedingte Prognose. Ändern sich Umfang oder Eingangsdaten, muss die Schätzung überprüft werden.

Bereiten Sie für das Gespräch mit GL.ua (Glyanec) die Abläufe der ersten Version, ein Schema des Datenaustauschs mit dem Shop und den gewünschten Kampagnentermin vor. Reichen Sie Ihre Aufgabe über die Seite zur Entwicklung von Onlineshops und mobilen Kanälen ein, um mit abgestimmten Abhängigkeiten für eine belastbare Schätzung zu beginnen — statt mit einem Kalender ohne Bedingungen.