Vom Prototyp zum Betrieb: was vor dem ersten echten Einsatz klar sein sollte

Der erste Nutzer verändert die Aufgabe

Ein Prototyp beantwortet eine Frage: Ist diese Idee technisch möglich, verständlich oder für jemanden interessant? Sobald eine Organisation damit regelmäßig arbeitet, kommen andere Erwartungen dazu. Daten sollen erhalten bleiben. Fehler brauchen einen Ansprechpartner. Änderungen dürfen einen wichtigen Ablauf nicht unerwartet unterbrechen.

Das ist kein Plädoyer, jeden Prototyp mit einer großen Betriebsorganisation zu belasten. Die Vorbereitung sollte zum tatsächlichen Einsatz passen. Eine öffentliche Informationsseite, eine interne Notizhilfe und eine Anwendung zur Schulverpflegung brauchen unterschiedliche Maßstäbe. Aber diese Maßstäbe müssen ausgesprochen werden.

Die folgenden Fragen sind mein Vorschlag für ein Gespräch vor dem ersten echten Einsatz. Sie ersetzen keine Prüfung der konkreten Anwendung.

1. Welcher Ablauf muss funktionieren?

„Die Anwendung ist erreichbar“ ist ein schwaches Ziel, wenn die entscheidende Funktion nicht verwendbar ist. Bei einer Bestelllösung wäre beispielsweise relevant, ob eine berechtigte Person ihre Bestellung im vorgesehenen Zeitraum erfolgreich abschließen kann. Bei einem Informationsangebot zählt auch, ob die richtigen Angaben verständlich auffindbar sind.

Aus dem Ablauf lassen sich Erwartungen ableiten: Wie aktuell müssen Daten sein? Welche Unterbrechung lässt sich überbrücken? Was wäre ein spürbarer Fehler für die Nutzer? Das SRE Workbook von Google zeigt an einem Beispieldokument für Serviceziele, wie Ziele und ihre Messung ausdrücklich beschrieben werden können. Das Prinzip lässt sich auch auf kleine Anwendungen übertragen; die konkreten Zielwerte müssen zur Aufgabe passen.

2. Wer übernimmt welche Verantwortung?

Die technische Betreuung ist nur ein Teil. Jemand muss auch fachliche Fragen beantworten, Zugänge vergeben und über Änderungen entscheiden. Bei kleinen Vorhaben kann dieselbe Person mehrere Rollen übernehmen. Trotzdem sollten sie benannt sein.

Ein kurzer Betriebskontakt ist oft hilfreicher als eine umfangreiche Dokumentation ohne Zuständigkeit: Wer ist erreichbar? Wo werden Probleme gemeldet? Welche Informationen braucht die Person, um den Fehler einzuordnen? Und wer vertritt sie bei Abwesenheit?

3. Wie wird ein Fehler bemerkt?

Ein Server kann laufen, während ein fachlicher Prozess fehlschlägt. Deshalb sollte die Beobachtung zum wichtigen Ablauf passen. Technische Fehlermeldungen, Rückmeldungen von Nutzern und eine Prüfung zentraler Funktionen ergänzen einander.

Dabei geht es nicht darum, möglichst viele Benachrichtigungen zu erzeugen. Ein Hinweis sollte zu einer konkreten Reaktion führen können. Wenn niemand weiß, was auf eine Meldung folgen soll, fehlt noch ein Teil des Betriebsentwurfs.

4. Was passiert mit den Daten?

Eine Sicherung ist zunächst eine gespeicherte Kopie. Ob sie im Ernstfall hilft, zeigt sich beim Wiederherstellen. Welche Daten sind enthalten? Welche Änderungen könnten zwischen zwei Sicherungen verloren gehen? Welche Zugänge und Werkzeuge werden für die Wiederherstellung gebraucht?

Diese Fragen gehören zum Entwurf, ebenso wie die sichere Übergabe oder Löschung am Ende der Zusammenarbeit. Ein lesbarer Export ist für eine Organisation möglicherweise wichtiger als eine weitere Komfortfunktion.

5. Wie werden Änderungen eingespielt?

Eine neue Version verändert ein laufendes System. Deshalb muss nachvollziehbar bleiben, welcher Stand eingesetzt wird und welche Prüfung er durchlaufen hat. Besonders Datenänderungen brauchen Aufmerksamkeit: Eine alte Programmversion wieder einzuspielen macht eine bereits durchgeführte Datenänderung nicht automatisch rückgängig.

Für einen kleinen Dienst kann ein einfacher, dokumentierter Ablauf genügen. Entscheidend ist, dass ein misslungener Wechsel nicht erst unter Zeitdruck zum ersten Mal durchdacht wird. Googles Beschreibung von Production Readiness Reviews ordnet solche Fragen in eine breitere Übernahme von Betriebsverantwortung ein.

6. Was ist ausdrücklich noch nicht abgedeckt?

Ein begrenzter Start kann sinnvoll sein. Dann sollte er auch begrenzt beschrieben werden: welche Nutzergruppe, welche Funktionen und welche Betreuung vorgesehen sind. Eine offene Einschränkung lässt sich gemeinsam behandeln. Eine stillschweigende Erwartung wird häufig erst im Problemfall sichtbar.

Schulmittag ist in meinem Projektverzeichnis ein Beispiel für die Verbindung von Produkt und laufendem Betrieb. Schulnavi zeigt eine andere Seite: die Verantwortung für Herkunft und Verständlichkeit von Daten. Die gemeinsame Frage bleibt, was Menschen von einem System tatsächlich erwarten dürfen.