Mit den Aufgaben der nächsten Person beginnen

Fragen Sie vor der Dokumentation, was nach Projektende ohne das ursprüngliche Entwicklungsteam möglich sein soll. Eine interne Fachperson muss vielleicht Quellen aktualisieren und Fehler einordnen. Eine technische Person muss eine Version bereitstellen oder einen Dienst wiederherstellen können.

Daraus entstehen unterschiedliche Unterlagen. Eine Architekturskizze erklärt Zusammenhänge. Eine Betriebsanleitung beschreibt Handlungen. Ein Testprotokoll dokumentiert, was in einer bestimmten Fassung geprüft wurde. Eine einzelne umfangreiche Datei erfüllt diese Zwecke nicht automatisch.

Legen Sie deshalb ein kleines Inhaltsverzeichnis mit Zielgruppe und Verantwortlichem je Dokument an. Umfang und Detailgrad richten sich nach der Aufgabe, nicht nach einer möglichst hohen Seitenzahl.

Die Lösung auf einer Seite erklären

Die erste Übersicht sollte Zweck, unterstützte Nutzergruppe, Datenquellen, Hauptkomponenten und externe Dienste zeigen. Ergänzen Sie, welche Informationen zwischen den Komponenten fliessen und wo Entscheidungen oder Freigaben stattfinden.

Ein neues Teammitglied sollte damit erklären können, wie aus einer Eingabe ein Ergebnis wird. Dazu gehören auch die Grenzen: Welche Aufgabe löst das System bewusst nicht? Wo wird eine Fachperson eingeschaltet? Welche Quelle ist für eine bestimmte Angabe massgeblich?

Die NCSC-Leitlinien zur sicheren Entwicklung nennen die Dokumentation von Daten, Modellen und Prompts ausdrücklich. Für Ihre Übergabe wird daraus eine konkrete Bestandsübersicht der tatsächlich eingesetzten Bausteine.

Konfiguration und Versionen nachvollziehbar halten

Erfassen Sie die Version der Anwendung, wichtige Bibliotheken oder Dienste, Modellbezeichnungen und relevante Konfigurationen. Beschreiben Sie, wo die gültigen Fassungen liegen und wie Änderungen nachvollzogen werden.

Geheime Zugangsdaten gehören nicht ungeschützt in ein Handbuch. Dokumentieren Sie stattdessen, in welchem vorgesehenen System sie verwaltet werden und welche Rolle Zugriff erhält. Eine Anleitung kann verständlich sein, ohne Geheimnisse zu vervielfältigen.

Halten Sie auch fest, welche Teile absichtlich variabel bleiben. Wenn ein externer Dienst sich unabhängig verändert, braucht die Dokumentation eine zuständige Person und einen Prüfweg für solche Änderungen.

Datenflüsse und fachliche Regeln festhalten

Eine Liste der Quellen reicht nicht, wenn wichtige Bedeutung nur im Kopf des Entwicklungsteams liegt. Beschreiben Sie beispielsweise, wie Produktkennungen zugeordnet, ungültige Versionen ausgeschlossen und fehlende Werte behandelt werden.

Für jede relevante Datenquelle sollten Herkunft, Verantwortlicher, Aktualisierung und erlaubter Einsatz erkennbar sein. Verweisen Sie auf die vorhandene Datenpflege, statt denselben Bestand an mehreren Orten widersprüchlich zu beschreiben.

Unser Beitrag zu Dokumentmetadaten für KI vertieft, welche Angaben auf Dokumentebene helfen. Die Projektdokumentation erklärt zusätzlich, wie die Anwendung mit diesen Angaben arbeitet.

Tests mit ihrem Geltungsbereich übergeben

Übergeben Sie den vereinbarten Testkatalog, erwartete Ergebnisse und den Stand der letzten Ausführung. Markieren Sie bekannte Fehler und nicht untersuchte Fälle. Ein grünes Gesamtergebnis ohne Testumfang lässt sich später kaum einordnen.

Notieren Sie, bei welchen Änderungen Tests erneut ausgeführt werden sollten. Eine neue Datenquelle, eine andere Rechtezuordnung oder ein Modellwechsel kann andere Prüfungen erfordern als eine reine Textkorrektur in der Oberfläche.

Die NIST-Empfehlungen zu Entwicklungsnachweisen betonen Unterlagen, die für die empfangende Zielgruppe nutzbar sind. Ein exportiertes technisches Protokoll ist deshalb nur dann hilfreich, wenn die zuständige Person seine Aussage und Grenzen versteht.

Eine fiktive Übergabeprobe durchführen

In einem fiktiven Projekt erhält eine neue technische Person die Aufgabe, eine freigegebene Dokumentversion in der Testumgebung zu ersetzen. Sie verwendet nur die Übergabeunterlagen und meldet jede Stelle, an der sie zusätzliche Erklärung benötigt.

Anschliessend prüft eine Fachperson eine bekannte Frage und einen Fall mit fehlender Grundlage. Beide halten fest, ob Quelle, Version und erwartetes Verhalten nachvollziehbar sind. Die Agentur ergänzt unklare Schritte unmittelbar in den Unterlagen.

Diese Probe zeigt mehr als eine Präsentation des fertigen Handbuchs. Sie macht sichtbar, ob die dokumentierte Handlung von einer anderen Person tatsächlich ausgeführt werden kann.

Störungen und Rückfall beschreiben

Für wichtige Fehlerfälle braucht es eine kurze Anleitung: Was wird beobachtet, wer wird informiert und welche Nutzung wird gegebenenfalls gestoppt? Beschreiben Sie den verfügbaren manuellen Ersatzablauf und die Bedingungen einer erneuten Freigabe.

Eine Wiederherstellungsanleitung sollte auf einer geeigneten Umgebung geprüft werden. Notieren Sie auch, welche Daten oder Arbeitsschritte bei einer Wiederherstellung besonders beachtet werden müssen. Eine pauschale Aussage «Backup vorhanden» beantwortet diese Frage nicht.

Pflege zur Übergabe hinzufügen

Legen Sie fest, wer Dokumente nach Änderungen aktualisiert und wie die gültige Fassung erkennbar bleibt. Veraltete Betriebsunterlagen können im entscheidenden Moment zu Fehlhandlungen führen. Die Aktualisierung gehört deshalb in den normalen Änderungsablauf.

Prüfen Sie die Zugänglichkeit der Unterlagen aus Sicht der empfangenden Person. Ein Verweis auf ein internes Agenturlaufwerk ist keine dauerhafte Übergabe. Benötigte Dateien und Verknüpfungen müssen am vereinbarten Ort mit passenden Zugriffsrechten verfügbar sein.

Mit einclick als KI-Umsetzungspartner können Sie die Übergabe von Anfang an als konkretes Lieferobjekt planen: verständliche Unterlagen, bekannte Grenzen und eine praktisch durchgeführte Übernahme.