Sie befinden sich mitten in einem Kundenprojekt, als der Verantwortliche auf Kundenseite sagt: „Wir benötigen diesen Workflow für unsere drei Regionen – jeweils mit unterschiedlichen Genehmigungsregeln –, und die Einhaltung muss durch die Plattform erzwungen werden.“ Wahrscheinlich könnten Sie im Rahmen der Bereitstellung eine schnelle, spezifische Lösung („Hack“) implementieren, doch Sie wissen auch: Dies ist eine Anforderung, die mit hoher Wahrscheinlichkeit auch der nächste Kunde stellen wird.
In dieser Lektion geht es darum, den Moment zu erkennen, in dem eine Kundenanfrage von einer einmaligen Lieferaufgabe zu einer Kernaufgabe der Produktentwicklung wird – und zu klären, welche Aufgaben dabei weiterhin in Ihren Verantwortungsbereich als Forward Deployed Engineer (FDE) fallen. Ein FDE ist ein Ingenieur, der Lösungen direkt in der Kundenumgebung bereitstellt und gleichzeitig Kundenanforderungen in konkrete Produkt- und Entwicklungsarbeit übersetzt.
Bevor Sie entscheiden, was genau entwickelt werden soll, müssen Sie zunächst den Kern der Anfrage verstehen. Geht es darum, „dass es für dieses Konto bis Freitag funktioniert“, oder handelt es sich um „eine fehlende, wiederverwendbare Funktionalität, für die dieser Kunde das erste deutliche Signal liefert“?
Untersuchen Sie den Unterschied zwischen einer kundenspezifischen Einzellösung und einer wiederverwendbaren Funktionalität.
Eine Anfrage wird dann zur Produktstrategie, wenn es nicht mehr nur um die Konfiguration für diesen einen Kunden geht, sondern um eine fehlende Produktfunktion. Man merkt das daran, dass der Kunde nicht nach einem bloßen Ergebnis fragt, sondern nach einer Regel, für die die Plattform selbst verantwortlich sein muss.
Stellen Sie sich folgende Situation vor: Der Kunde möchte, dass regionsspezifische Genehmigungsverfahren direkt in der Plattform durchgesetzt werden – nicht in einer Tabelle, nicht als manueller Schritt und nicht als kundenspezifisches Skript, das nur Ihr Team versteht. Das ist ein Hinweis darauf, dass hier etwas verlangt wird, das Produktdesign, langfristigen Support und eine klare Definition des Funktionsverhaltens erfordert.
Eine einfache Methode zur Unterscheidung ist die Frage: Was passiert, wenn ich nicht mehr da bin? Wenn die Lösung die Pflege eines eigenen Code-Zweigs (Custom Branch), eines privaten Patches oder eines Sonderverhaltens erfordert, das ohne Ihre Notizen niemand erklären kann, bewegt sich die Sache in den Bereich der Produktentwicklung. Sie benötigt dann eine offizielle Schnittstelle und ein stabiles Support-Konzept.
Was unterstützt werden muss, muss auch designt werden Sobald ein Kunde erwartet, dass eine Funktion auch Upgrades und neue Nutzer überdauert, sollten Sie sie wie ein Produkt behandeln – und nicht wie einen einmaligen Trick bei der Bereitstellung.
Selbst wenn eine Anforderung eigentlich in den Bereich der Kernproduktentwicklung gehört, tragen Sie weiterhin die Verantwortung für den Fortschritt des Kundenprojekts. Ihre Aufgabe ist es, den Kunden handlungsfähig zu machen, ohne das Produkt im laufenden Betrieb eigenmächtig umzuschreiben.
Diese Verantwortung umfasst zwei Aspekte.
Erstens: Sie treiben die Bereitstellung voran. Sie wandeln die Anfrage in eine klare Anforderung um, prüfen die Machbarkeit im aktuellen System und schlagen eine Übergangslösung vor, bei der die Einschränkungen offen kommuniziert werden.
Zweitens: Sie wahren die Produktintegrität. Produktintegrität bedeutet, dass das Produkt als Einheit konsistent bleibt und nicht zu einer Ansammlung kundenspezifischer Verhaltensweisen verkommt, die sich mit der Zeit gegenseitig stören. In der Praxis heißt das: Vermeiden Sie Code-Abspaltungen (Forks) und versteckte Konfigurationsschalter, die nur von einem einzigen Kunden genutzt werden. Vermeiden Sie zudem Zusagen, die das Entwicklungsteam später in eine Sackgasse führen könnten.
Im Beispiel mit den Genehmigungsverfahren könnten Sie einen vorübergehenden Prozess implementieren, der die Audit-Anforderungen erfüllt, während Sie gleichzeitig Argumente für die Einführung einer Kernfunktion sammeln. Sie lehnen die Anfrage nicht ab, sondern ordnen sie zeitlich sinnvoll ein.
Das Tückische daran ist, dass sich diese Fehler im Moment oft wie „kundenorientiertes Handeln“ anfühlen. Die Kosten dafür fallen erst später an – meist dann, wenn Sie bereits bei einem anderen Kunden tätig sind.
Hier sind einige Beispiele dafür, wie solche Fehler zu Folgekosten führen.