So starten wir ein Projekt.
Kein Kick-off-Marathon. Am ersten Tag sind wir in Ihrer Infrastruktur, nicht in einem Workshop-Raum.
Viele Projekte verlieren die ersten Wochen mit Workshops, Stakeholder-Mappings und PowerPoint-Architekturen. Wir nicht.
Am ersten Tag haben wir Zugang zur Infrastruktur. Am zweiten Tag steht die erste Pipeline. In der ersten Woche gibt es lauffähigen Code.
Infrastruktur-Zugang und erste Orientierung.
Wir brauchen keine Einführungspräsentation. Wir brauchen AWS-Credentials, Zugang zum Repository und einen Ansprechpartner, der Fragen beantworten kann.
Am ersten Tag verschaffen wir uns einen Überblick: Welche Services laufen? Wie ist die Architektur aufgebaut? Wo sind die Schmerzpunkte?
Wir dokumentieren, was wir finden. Keine PowerPoint, sondern Architecture Decision Records im Repository.
Erste Pipeline, erste Ergebnisse.
Bevor wir Architektur diskutieren, bauen wir eine CI/CD-Pipeline. Nicht weil das das Wichtigste ist, sondern weil es alles andere beschleunigt.
Jede Änderung, die wir danach machen, ist sofort testbar und deploybar. Kein manuelles Deployment, kein Warten auf Ops-Teams.
Parallel analysieren wir die bestehende Infrastruktur und identifizieren Quick Wins: Was können wir sofort verbessern, ohne Risiko?
Am Ende von Tag 3 gibt es den ersten Merge Request mit echtem Code.
Lauffähiger Code statt Konzeptpapiere.
Nach einer Woche existiert ein lauffähiges System. Nicht vollständig, aber funktional. Etwas, das man zeigen kann. Etwas, das man testen kann.
Wir arbeiten in kurzen Zyklen: Bauen, zeigen, Feedback einarbeiten. Jeden Tag. Nicht alle zwei Wochen in einem Sprint Review.
Der Kunde sieht jeden Tag Fortschritt. Nicht in Status-Reports, sondern in funktionierender Software.
Das schafft Vertrauen. Und Vertrauen ist die Grundlage für alles, was danach kommt.
Architekturentscheidungen in Code, nicht in Slides.
In Woche 2 stehen die fundamentalen Architekturentscheidungen. Nicht auf Papier, sondern im Code. Infrastructure as Code, getestete Deployments, dokumentierte Entscheidungen.
Wenn etwas nicht funktioniert, merken wir es jetzt, nicht nach 3 Monaten Konzeptphase.
Vom Prototyp zum System.
Ab Woche 3 wird aus dem Prototyp ein System. Wir härten die Architektur, implementieren Security, bauen Monitoring auf.
Am Ende von Woche 4 existiert ein System, das echte Nutzer verwenden können. Kein MVP auf dem Whiteboard, sondern Software in Produktion.
Kontinuierliche Verbesserung.
Nach dem initialen Setup arbeiten wir in einem kontinuierlichen Modus: Neue Features, Performance-Optimierung, Skalierung.
Der Unterschied zu anderen: Wir haben kein Change-Request-Verfahren. Wir haben ein Backlog und liefern jeden Tag.
Wir verschwenden keine Zeit mit Planung. Wir nutzen sie zum Entwickeln.
Dieses Vorgehen funktioniert, weil wir es in jedem Projekt so machen. Bei Siemens, bei VW, bei Siemens Energy. Die Technologien ändern sich, der Ansatz bleibt.
Am Ende des Kickoffs hat der Kunde kein Konzeptpapier. Sondern ein laufendes System und das Vertrauen, dass wir liefern.