Problem: Übergaben werden zu spät geplant
Webprojekte gelten häufig mit dem Livegang als abgeschlossen. Wochen später fehlen Angaben zu Hosting, CMS-Rollen oder Deployment. Bei twindor setzt die Übergabe deshalb vor dem Launch an: Zugänge, Entscheidungen und Betriebsabläufe werden so festgehalten, dass eine fremde Person das Projekt übernehmen kann. Der Unterschied zeigt sich nicht im Design, sondern in der Zeit, die nach dem Launch für Klärungen verloren geht.
Ursache: Wissen liegt in Chats, Mails und Tickets
Der Engpass entsteht selten durch fehlende Fachkenntnis, sondern durch Streuung. Build-Befehle stehen in Chatverläufen, CMS-Rollen in E-Mails, Hosting-Zugänge in Tickets. Jede Information existiert, aber nicht an der Stelle, an der sie im Ernstfall gebraucht wird. Besonders bei Wechseln zwischen Agentur, Kunde und IT-Dienstleister wird daraus Reibung, weil niemand den vollständigen Zusammenhang kennt.
Lösung: Vier Schritte zur prüfbaren Übergabe
- Zugänge und Rollen bündeln: Hosting, CMS, Domain, Analytics und Backups werden pro Projekt in einer verantworteten Liste geführt. Zu jedem Eintrag gehören Ansprechpartner, Rechte und Änderungsdatum.
- Entscheidungen protokollieren: Für Theme, Plugins, Serverkonfiguration und Datenmodell wird kurz festgehalten, welche Alternative geprüft wurde und warum die Wahl gefallen ist. Das verhindert spätere Diskussionen ohne Grundlage.
- Deployment reproduzierbar machen: Lokale Entwicklung, Staging und Produktion erhalten einen dokumentierten Ablauf mit Build-Kommandos, Umgebungsvariablen und Rollback-Schritten. Ein zweiter Entwickler muss den Ablauf ohne Zuruf wiederholen können.
- Übergabe praktisch testen: Eine nicht am Projekt beteiligte Person richtet die Seite einmal nach Dokumentation ein. Jede Lücke wird notiert und geschlossen, bevor das Projekt als abgeschlossen gilt.
Beispiel: Formularänderung nach sechs Monaten
Sechs Monate nach dem Launch soll ein Kontaktformular ein neues Pflichtfeld erhalten. Ohne Übergabedokumentation beginnt die Suche nach Formular-Plugin, SMTP-Zugang und Deployment-Umgebung. Mit der twindor-Methode stehen Plugin-Entscheidung, Mailkonfiguration und Rollback-Schritt in einer Ablage. Die Änderung bleibt eine kleine Aufgabe statt eines mehrstündigen Suchlaufs.
Dokumentation als Teil der Definition of Done
Die Übergabe wird belastbar, wenn sie nicht als Abschlussgeschenk behandelt wird, sondern als Prüfpunkt im Projektablauf. Ein Ticket gilt erst als erledigt, wenn Zugänge, Entscheidung und Betriebsweg dokumentiert sind. Diese Regel kostet während der Entwicklung wenige Minuten pro Aufgabe und spart nach dem Launch ganze Abstimmungsschleifen.
Ergebnis: Planbare Wartung statt Wissenslücken
Die dokumentierte Übergabe verändert den Alltag nach dem Launch. Textänderungen, neue Formulare oder Template-Anpassungen brauchen weniger Erklärungen, weil Rollen, Befehle und Entscheidungen auffindbar sind. Für Kunden wird Wartung planbar; für Entwickler sinken Kontextwechsel. twindor zeigt damit, dass saubere Webentwicklung nicht mit dem Livegang endet, sondern mit einer nachvollziehbaren Übergabe arbeitet.