Was Sie vor der Schätzung einer mobilen App vorbereiten sollten

Für eine erste Einschätzung brauchen Sie keinen fertigen Technikplan

Sie können eine Aufwandsschätzung anfragen, während Ihre Idee noch Gestalt annimmt. Sie müssen weder eine Datenbank auswählen noch sämtliche Bildschirme gestalten. Das Entwicklungsteam braucht zunächst ein verständliches Bild davon, wer die App nutzen soll, welche Aufgabe diese Person erledigt und welche Systeme Ihr Unternehmen bereits einsetzt.

Schwierig wird es oft nicht wegen einer fehlenden Funktionsliste, sondern wegen unterschiedlich verstandener Begriffe. Eine „Buchung“ kann eine Anfrage an einen Mitarbeiter, die Reservierung eines freien Termins oder den Kauf des letzten Kursplatzes meinen. Eine Schätzung für den falschen Ablauf kann präzise aussehen und trotzdem wenig nützen. Ein guter Projektüberblick verhindert genau das.

Beschreiben Sie einen Menschen und ein Ergebnis

Beginnen Sie mit einem Satz aus dem tatsächlichen Arbeitsalltag. „Unsere Kursteilnehmer sollen die nächste Lektion öffnen und Aufgaben beim Dozenten einreichen können“ ist greifbarer als „eine innovative Bildungsplattform“. Das Team erkennt, für wen es entwickelt und welches Ergebnis beim Kürzen der ersten Version erhalten bleiben muss.

Erklären Sie danach den heutigen Ablauf. Vielleicht kommen Unterrichtslinks über einen Gruppenchat, Aufgaben per E-Mail und Zugangsfreigaben von einer Verwaltungskraft. Diese Einzelheiten zeigen, wo die App helfen soll. Ohne sie lässt sich eine Oberfläche modernisieren, während das eigentliche Problem bestehen bleibt.

Die erste Version sollte einen nützlichen Ablauf vollständig ermöglichen. Empfehlungen, Community-Funktionen oder umfangreiche Berichte können warten, wenn sie dafür nicht nötig sind. Das ist keine Absage an Ihre langfristige Idee. Es trennt den ersten überprüfbaren Nutzen vom späteren Ausbau.

So wird aus einer vagen Idee eine beschreibbare Aufgabe

Nehmen wir einen fiktiven Anbieter von Sportkursen. Die vage Anfrage lautet: „Wir möchten eine App wie ein großer Fitness-Marktplatz, mit Buchung, Zahlung und Benachrichtigungen.“ Unklar bleibt, ob Sie einen Standort betreiben oder unabhängige Anbieter verbinden, wie Plätze vergeben werden und wer Stornierungen bearbeitet.

Hilfreicher wäre: „Mitglieder unseres ersten Studios wählen einen Kurs, reservieren einen freien Platz und bezahlen, falls ihr Pass die Teilnahme nicht abdeckt. Mitarbeiter ändern den Stundenplan und sehen die Teilnehmenden. Weitere Studios und ein sozialer Bereich gehören nicht zur ersten Version.“

Das ist noch keine technische Spezifikation. Es räumt aber mehrere wesentliche Missverständnisse aus. Ergänzen Sie einen Ausnahmefall: Was passiert, wenn zwei Menschen den letzten Platz wählen oder die Zahlungsbestätigung nach Ablauf der Reservierung eintrifft? Das Team kann nun eine konkrete Frage prüfen, statt eine ganze Plattform zu erraten.

Ein Projektüberblick auf einer Seite

Nutzen Sie die folgenden Felder als Arbeitsgrundlage. Kurze, ehrliche Angaben sind wertvoller als ausgefeilte Werbesätze. Schreiben Sie „noch offen“, wenn eine Entscheidung fehlt, und benennen Sie die zuständige Person.

Nutzer und Problem: [Wer braucht Unterstützung, wie arbeitet die Person heute und was stört dabei?]

Wichtigster Ablauf: [Wo beginnt die Person, was wählt oder übermittelt sie und woran erkennt sie den Erfolg?]

Arbeit im Unternehmen: [Wer bereitet Inhalte vor, bestätigt Vorgänge, klärt Ausnahmen und beantwortet Anfragen?]

Erste Version: [Unverzichtbare Funktionen für diesen Ablauf; ausdrücklich zurückgestellte Funktionen.]

Vorhandene Systeme: [Benötigte Anbindungen, Ansprechpartner, Dokumentation und verfügbare Testzugänge.]

Design und Inhalte: [Idee, Referenzen, Skizzen oder fertige Entwürfe; Zuständige für Texte, Bilder und Sprachfassungen.]

Veröffentlichung: [Länder, Sprachen, iOS oder Android, gewünschter Termin und Grund für die Frist.]

Offene Entscheidungen: [Fragen mit möglicher Auswirkung auf den Plan und Verantwortliche für die Klärung.]

Passwörter und echte Kundendaten gehören nicht in diesen Überblick. Ein fiktiver Beispieldatensatz erklärt den Ablauf meist ebenso gut. Benötigt die Agentur später geschützten Zugriff, lässt sich dieser gesondert und kontrolliert einrichten.

Machen Sie die unsichtbare Betriebsarbeit sichtbar

Die mobile Oberfläche ist nur ein Teil des Dienstes. Fordert ein Kunde eine Erstattung an, muss jemand die Anfrage erhalten, entscheiden und den Datensatz aktualisieren. Veröffentlicht ein Dozent eine Lektion, braucht jemand Rechte zum Hochladen, Ersetzen und Zurückziehen des Inhalts.

Sie müssen vor der Schätzung keine vollständige Verwaltung entwerfen. Beschreiben Sie die Tätigkeiten und die Folgen eines Fehlers. Eine Empfangskraft darf vielleicht Anwesenheiten ändern, aber keine Zahlungsdaten bearbeiten. Unser Leitfaden zur Verwaltungsoberfläche hilft, solche Zuständigkeiten zu trennen.

Sagen Sie außerdem, was zunächst manuell bleiben darf. Für einen kleinen Testbetrieb kann ein täglicher Export ausreichen. Eine dringende Meldung darf dagegen nicht in einem unbeaufsichtigten Postfach liegen bleiben. Manuelle Bearbeitung ist eine bewusste Umfangsentscheidung, kein Weg, die Arbeit unsichtbar zu machen.

Nennen Sie externe Abhängigkeiten

Zwei Apps mit gleich vielen Bildschirmen können unterschiedlich aufwendig sein, weil andere Systeme dahinterstehen. „Unser CRM anbinden“ reicht nicht, wenn niemand weiß, wer es betreut oder ob die benötigten Informationen zugänglich sind.

Fügen Sie keine Produktionsschlüssel ein, nur damit das Dokument vollständig wirkt. Ein öffentlicher Dokumentationslink oder ein Ansprechpartner genügt zunächst. Ist ein Anbieter noch nicht gewählt, kennzeichnen Sie das. Eine Anbieterauswahl ist eine eigene Aufgabe und keine unsichtbare Nebenleistung.

Erklären Sie, warum Ihnen eine Referenz gefällt

Zwei oder drei Referenzen können ausreichen, wenn jede eine konkrete Beobachtung enthält. „Im Stundenplan finde ich schnell einen freien Abend“ hilft weiter. „Bitte genauso bauen“ lässt offen, welche Teile eines über Jahre gewachsenen Produkts gemeint sind.

Zeigen Sie auch störende Beispiele. Vielleicht erklärt eine Zahlungsfehlermeldung nicht, was als Nächstes zu tun ist. Oder ein Lernender findet eine begonnene Lektion nicht wieder. Solche Beobachtungen machen Prioritäten oft schneller verständlich als eine lange Reihe von Adjektiven. Referenzen sollen Entscheidungen erklären, nicht das Kopieren fremder Gestaltung verlangen.

Beschreiben Sie eigene Materialien ebenso genau. Eine Figma-Datei kann fertige Ansichten enthalten, aber keine leeren Zustände oder Stornierungen. Eine bestehende App kann wertvolle Daten besitzen und zugleich kaum dokumentiert sein. „Design fertig“ oder „Server vorhanden“ sind deshalb nur der Anfang einer Erklärung.

Unterscheiden Sie Frist und Wunschdatum

Nennen Sie den Grund für den Termin. Ein Kursbeginn, eine vertragliche Partnerzusage und eine persönliche Präferenz haben unterschiedliches Gewicht. Ergänzen Sie die Aufgaben Ihres Unternehmens: Konten vorbereiten, Inhalte liefern, Regeln prüfen, Zahlungsfreigaben erhalten und Entwürfe abnehmen.

Diese Abhängigkeiten müssen in der Schätzung sichtbar sein. Sonst wird stillschweigend angenommen, dass alles rechtzeitig vorliegt. Bei einer festen Frist sollte die Agentur Kürzungen vorschlagen, die den Hauptablauf erhalten. Einige dekorative Ansichten zu streichen löst keine fehlende Schnittstelle.

Methoden der Kalkulation behandeln wir im Leitfaden zu Entwicklungskosten. Hier geht es um bessere Ausgangsinformationen, nicht um einen pauschalen Betrag für jede Idee. Richten Sie Ihren Projektüberblick deshalb nicht nach einer zufälligen Zahl aus einem fremden Beispiel aus.

Verlangen Sie Annahmen und einen nächsten Schritt

Eine hilfreiche Antwort erklärt das Verständnis der Aufgabe, enthaltene Leistungen, Ausschlüsse und offene Prüfungen. Sie unterscheidet eine erste Orientierung von einer Lieferzusage auf Basis geprüfter Anforderungen. Diese Trennung schützt beide Seiten vor falschen Erwartungen.

Fragen Sie nach der unsichersten Annahme. Beispielsweise: „Wir gehen davon aus, dass Ihr Terminverwaltungssystem Doppelbuchungen verhindert.“ Dann kann der nächste Schritt eine begrenzte technische Prüfung sein. Das ist aussagekräftiger als eine scheinbar sichere Gesamtaussage ohne Begründung.

Zum Vergleich der Antworten eignet sich unser Leitfaden zur Agenturauswahl. Verteilen Sie wichtige Klarstellungen an alle Beteiligten und verwenden Sie dieselbe aktualisierte Fassung. Andernfalls bewerten Sie nicht nur die Teams, sondern auch Unterschiede in deren Informationsstand.

Prüfen Sie, ob der Überblick versandbereit ist

Lesen Sie das Dokument aus Sicht einer Person, die Sie nicht kennt. Erkennt sie den ersten Nutzer, dessen Ergebnis, die Arbeit Ihres Unternehmens und die wichtigste offene Frage? Dann reicht es wahrscheinlich für ein sinnvolles Gespräch. Eine zusätzliche Seite mit Funktionsnamen macht die Aufgabe nicht automatisch klarer.

Bei Appfyl können Sie die Angaben über den kurzen Projektfragebogen zur Prüfung einreichen. Das ist eine Anfrage, keine sofortige Berechnung oder Terminzusage. Derselbe Projektüberblick eignet sich auch für Gespräche mit anderen Teams.

Sobald das Verhalten genauer vereinbart werden soll, nutzen Sie die Vorlage für eine technische Spezifikation. Der Überblick beschreibt Problem und Grenzen. Die Spezifikation beschreibt Verhalten und Abnahme. So wird aus der Vorbereitung keine unnötige Dokumentationsarbeit.

Häufige Fragen