Quick-Win-Dokumentation: Builder Documentation & User Manual

Zu jedem Quick Win gehören zwei Dokumente mit unterschiedlichen Adressaten.

Adressat: die Person, die den Assistenten warten, weiterentwickeln oder neu bauen will. Neun Pflichtfelder:

1. Steckbrief: Name, Owner, Stand, Plattform
2. Problem & Lösung: was der Assistent löst, welcher Zeitgewinn entsteht
3. Setup-Anleitung: Schritt für Schritt zum Neuaufbau
4. System Prompt: final und datiert
5. Wissensdokumente: Liste, Stand, Verantwortung
6. Test-Inputs & erwartete Outputs: drei Tests
7. Curveball-Erfahrungen: was aus den Robustheitstests gelernt wurde
8. Bekannte Grenzen: was der Assistent nicht kann
9. Versionshistorie: saubere Änderungschronik

Die Curveball-Sektion ist laut Deck ausdrücklich Pflicht: „Sie macht eure Lernreise sichtbar.”

Adressat: Kolleg:innen ohne Workshop-Hintergrund. Maximal zwei Seiten, in alltagstauglicher Sprache:

1. Was kann der Assistent für dich? (ein bis zwei Sätze)
2. Was kann er nicht? (ehrliche Grenzen)
3. So nutzt du ihn, fünf bis sieben Schritte
4. Drei Beispiele: was reinkommt, was rauskommt
5. Häufige Fehler und wie du sie vermeidest
6. Wer hilft dir? Konkrete Personen mit Kontakt

Goldene Regel laut Deck: „Wenn jemand das User Manual liest und nicht sofort weiß, wie’s geht, ist es noch nicht fertig.”

Geprüft wird die Dokumentation nicht vom eigenen Team, sondern kalt von einem Team aus einer anderen Use-Case-Familie, ohne Vorgespräch:

1. Team B liest nur das User Manual und versucht eine Aufgabe blind, wo bleibt es hängen?
2. Team B liest die Builder Documentation. Reicht sie, um den Assistenten neu zu bauen, wenn er gelöscht würde?
3. Team B führt einen echten Test-Input durch, klappt’s?
4. Strukturiertes Feedback in drei Spalten: Was klappte · Was fehlte · Was war verwirrend.
5. Übergabe an Team A.