Ein FDE-Engagement umfasst den gesamten Ablauf vom Erstkontakt bis zur stabilen Unterstützung im Produktivbetrieb – es beschränkt sich nicht nur auf die eigentliche Entwicklung. Die Herausforderung besteht darin, dass jede Phase ein anderes „Hauptrisiko“ birgt und einen spezifischen Nachweis erfordert, der dem Kunden vorgelegt werden muss, bevor der nächste Schritt erfolgen kann.
Stellen Sie sich folgende Situation vor: Sie sind als Forward Deployed Engineer (FDE) bei einem mittelgroßen Versicherer, NorthBridge Mutual, tätig und arbeiten an der Einführung eines internen Assistenten. Dieser soll Schadenregulierer dabei unterstützen, relevante Vertragsbedingungen und frühere Schadensfälle zu finden. Das Plattformteam erwartet eine funktionierende Lösung innerhalb von zwei Wochen, die Sicherheitsabteilung verlangt formelle Prüfungen, und der geschäftliche Auftraggeber möchte bis Quartalsende Zahlen zur Nutzungsrate sehen. Ihre Aufgabe ist es, die Phasen Discovery (Analyse/Konzeption), Delivery (Umsetzung) und Support zu durchlaufen, ohne dabei das eigentliche Ziel – den Erfolg des Projekts – aus den Augen zu verlieren.
Um diesen Fokus zu wahren, sollten Sie den Lebenszyklus als eine Abfolge expliziter Entscheidungen betrachten. Jede Entscheidung führt zu einem konkreten Ergebnis, auf das Sie verweisen können. So lässt sich argumentieren: „Wir befinden uns an diesem Punkt, haben uns auf dieses Vorgehen geeinigt, und deshalb setzen wir jene andere Maßnahme noch nicht um.“ Genau hier sind meist die wichtigsten Abwägungen und Entscheidungen eines FDE gefragt.
Der Lebenszyklus lässt sich am besten steuern, wenn die Phasen klar benannt und jeweils mit einem konkreten Arbeitsergebnis (Artefakt) verknüpft werden. Dieses Ergebnis dient dazu, Abstimmung zu erzielen, Abhängigkeiten aufzulösen und den Projektumfang zu verteidigen, wenn der Zeit- oder Erfolgsdruck steigt.
Werfen wir einen Blick auf die Phasen des Engagements und die dabei entstehenden Ergebnisse.
Bei NorthBridge Mutual endet die Discovery-Phase, sobald Sie schriftlich festhalten können, wer die Nutzer sind, wie ihre aktuellen Arbeitsabläufe aussehen und was „besser“ in messbaren Zahlen bedeutet. Discovery ist die Zeit, in der Sie die Arbeitsabläufe und Rahmenbedingungen der Nutzer so gut kennenlernen, dass Sie eine Lösung vorschlagen können, die auch tatsächlich genutzt wird.
In der Scoping-Phase überführen Sie diese Anforderungen in eine erste, klar abgegrenzte Release-Version. Der Scope (Leistungsumfang) umfasst genau die Funktionen und Integrationen, deren Bereitstellung vereinbart wurde, sowie eine explizite Liste dessen, was nicht enthalten ist. Hier legen Sie auch fest, welche Voraussetzungen für die Auslieferung erfüllt sein müssen – etwa Sicherheitsfreigaben, Datenzugriffe und die Zuständigkeit der jeweiligen Teams für Abhängigkeiten.
In der Design-Phase machen Sie Abwägungen und Kompromisse sichtbar, noch bevor Code geschrieben wird. Das Solution Design beschreibt die Funktionsweise des Systems von Ende zu Ende – einschließlich Datenfluss, User Experience und operativer Verantwortlichkeit – und zwar so detailliert, dass Sicherheits- und Plattformteams es prüfen können.
In der Implementierungsphase trifft der Plan auf die Realität. Ihr wichtigstes Ergebnis ist ein funktionsfähiger „Thin Slice“ (ein minimaler, aber durchgängiger Ausschnitt), der den kritischen Pfad validiert – etwa das Abrufen der richtigen Dokumente und deren Anzeige in der Benutzeroberfläche für Sachbearbeiter, auch wenn das Design noch nicht ausgereift ist.
In der Phase vor dem Start (Pre-Launch) wechseln Sie von der Denkweise des Entwicklers zu der des Betreibers. Sie legen fest, wie das Monitoring erfolgt, wie sich Fehler äußern, wer im Störungsfall benachrichtigt wird und wie ein Rollback durchgeführt wird.
Bei der Übergabe (Handoff) reduzieren Sie Single Points of Failure (kritische Schwachstellen). Der Handoff umfasst die Weitergabe von Wissen und operativer Verantwortung, damit das Kundenteam das System betreiben kann, ohne dass Sie bei jeder Änderung einbezogen werden müssen.
Im Produktionssupport entscheidet sich, ob man an Glaubwürdigkeit gewinnt oder verliert. Produktionssupport bedeutet, die Funktionsfähigkeit des Systems im realen Betrieb zu gewährleisten, auf Störungen zu reagieren und kleinere Korrekturen vorzunehmen, ohne dabei den ursprünglichen Leistungsumfang und die Release-Ziele zu gefährden.
Ein disziplinierter Umgang mit dem Lebenszyklus ist entscheidend, denn jede übersprungene Phase führt später zu einem Notfall – und dieser landet meist beim FDE (Full-Stack Development Engineer). Das Muster ist vorhersehbar: Wer zu Beginn übereilt handelt, zahlt später mit Nacharbeit und Vertrauensverlust.
Hier erfahren Sie mehr über die häufigsten Fehlerquellen in den einzelnen Phasen.