Warum unsere Ingenieure beim Kunden sitzen und wozu sie nicht da sind

Jedes Plattformunternehmen bietet irgendwann eine Version davon an. Ein Ingenieur arbeitet eine Zeit lang mit einem Kunden zusammen, und etwas wird schneller gebaut, als es sonst der Fall wäre.

Die Frage ist, in welchem Zustand sich der Kunde befindet, wenn dieser Ingenieur geht, und es hängt ganz davon ab, wofür der Ingenieur optimiert hat.

Der Fehlermodus

Der Ingenieur baut das Ding. Es funktioniert, der Kunde ist zufrieden und das Wissen darüber, wie es funktioniert, bleibt beim Ingenieur.

Sechs Monate später muss der Agent geändert werden, intern versteht niemand die Bewertungskriterien und der Kunde öffnet ein Support-Ticket, um sein eigenes System zu ändern. Das ist Abhängigkeit und kann über einen längeren Zeitraum hinweg als erfolgreiches Engagement dargestellt werden.

Kurzfristig ist es auch kommerziell verlockend, weshalb es so oft geschieht, ohne dass irgendjemand darüber entscheidet.

Wozu wir eigentlich da sind

Vermitteln Sie die vier Dinge, die dafür sorgen, dass Agentenoperationen funktionieren, indem Sie sie gemeinsam und nicht für sie erledigen.

Wie man entscheidet, was zuerst automatisiert werden soll, was normalerweise eine engere Entscheidung ist als der Instinkt des Kunden.

Wie schreibt man Bewertungskriterien für die eigene Arbeit, also die Fähigkeit, die am weitesten transferiert wird und mit der niemand ankommt?

Wie man Kosten und Eigentum so instrumentiert, dass der zweite Agent die Fehler des ersten Agenten nicht wiederholt.

Wie man eine Grenze setzt und diese am Ort der Aktion durchsetzt, anstatt sie in einer Eingabeaufforderung zu beschreiben.

Wenn wir diese vier gut machen, ist die Auslieferung des ersten Agenten langsamer und der fünfte gehört ganz ihnen.

Das Maß, das wir verwenden

Keine Agenten geliefert. Ob der Kunde das nächste ohne uns gebaut hat.

Das ist eine bewusst umständliche Maßnahme, denn sie macht ein erfolgreiches Engagement zu einem Ende. Wir glauben, dass es das Richtige ist, und es ist der Test, den wir einem Anbieter unterziehen würden, der mit uns zusammenarbeitet.

Was die Ingenieure lernen

Dies geschieht in beide Richtungen und ist keine Gefälligkeit. Fast alles, was wir an der Plattform verändert haben, ist darauf zurückzuführen, dass wir dabei zusehen mussten, wie ein Team etwas traf, mit dem wir nicht gerechnet hatten.

Die Zuordnung pro Agent wird als Inventarisierungsinstrument und nicht als Kosteninstrument verwendet. Budgets knapp gesteckt und als Signal genutzt. Bewertungskriterien, die rückwärts von einem Fehler geschrieben und nicht im Voraus entworfen wurden. Nichts davon stammte aus einer Roadmap. Sie kamen dadurch, dass man neben jemandem saß.

Wozu wir Nein sagen werden

Etwas bauen, von dem wir glauben, dass es nicht gebaut werden sollte. Ein Agent, der in einen Entscheidungspfad versetzt wird, in dem es teuer ist, falsch zu liegen, und in dem es keinen Überprüfungsschritt gibt, ist keine Frage des Umfangs, sondern ein Designeinwand, und wir würden ihn lieber vorbringen, als ihn vorzubringen.

Wir lehnen es auch ab, ständiger Eigentümer der Agenten eines Kunden zu sein. Ein Agent benötigt einen benannten Eigentümer innerhalb der Organisation, die von ihm abhängig ist.

So arbeiten Sie mit uns zusammen

Der Einsatz ist begrenzt und das Ziel steht zu Beginn fest: Ihr Team führt dies ohne uns durch. Wenn Sie über ein bestimmtes Programm und nicht über ein allgemeines Angebot sprechen möchten, buchen Sie eine Demo und bringen Sie die Einschränkungen mit.

Als nächstes

Die Seiten zum Agent Orchestration System decken die Ebenen ab, auf denen diese Arbeit basiert. In „Karriere“ erfahren Sie, wie diese Rollen von innen aussehen.