de
Projektleitung, Werkzeuge
KI-Projektleiter: Warum der Aufbau von KI-Agenten nur ein weiteres IT-Projekt ist
Einige Monate, nachdem generative KI praktisch genug wurde, um damit zu arbeiten, begann auf unserer Seite von FlexiProject etwas Interessantes zu passieren – im Geschäftsteam, nicht im Ingenieursteam. Ohne Code zu schreiben, hatten wir plötzlich Agenten, die im Stillen Teile unserer täglichen Arbeit erledigten: die Erstellung von Kundenangeboten, das Ausfüllen von Vertragsdaten, das Abrufen von Search Console Berichten, das Aktualisieren unseres Produkt-Backlogs nach Kundengesprächen und die Verwaltung der Website. Der Aufbau der Agenten war der einfache Teil. Was wir nicht erwartet hatten, war, dass das KI-Projektmanagement, das jeden Agenten wie ein echtes Softwareprojekt behandelt, mit einem Plan, einem gemeinsamen Zweig, Tests und einem Auslieferungsschritt, genauso wichtig sein würde wie alles, was unsere Ingenieure jemals ausgeliefert hatten. Dies ist die Geschichte dessen, was wir gelernt haben, in der Reihenfolge, in der wir es gelernt haben.
In diesem Artikel erfahren Sie mehr:
|
Wie ein Unternehmensteam begann, KI-Agenten zu entwickeln
KI-Agenten bauen, obwohl wir keine IT sind
Die interessante Wendung der letzten zwei Jahre ist, dass Sie kein Entwicklungsteam mehr brauchen, um eine funktionierende KI zu entwickeln. Ein Geschäftsmann, der beschreiben kann, was passieren soll, und ein paar Beispieleingaben kopiert, kann einen Agenten bauen, der echte Arbeit leistet. Wir hatten nicht vor, Erbauer zu werden. Wir stießen immer wieder auf Aufgaben, bei denen die Antwort offensichtlich war: „Das könnte ein Agent erledigen“, also begannen wir mit dem Bau. Das erste Projekt dauerte einen Nachmittag. Die zweite dauerte einen Nachmittag. Dann begannen die Probleme – nicht mit dem Gebäude, sondern mit allem drum herum.
Die Agenten, die wir gebaut haben
Die Liste wuchs schneller als wir erwartet hatten. Wir haben einen Agenten, der Kundendaten automatisch in unsere Standardverträge einträgt. Einen Agenten, der auf der Grundlage einer Zusammenfassung des Verkaufsgesprächs einen ersten Entwurf eines Angebots erstellt. Einen Integrator, der die Excel-Projektliste eines Kunden direkt in seine FlexiProject Umgebung importiert. Ein Assistent, der uns bei der Verwaltung von Teilen unserer Website hilft. Ein Agent, der die Google Search Console-Daten für unsere Domain abruft und sie in eine lesbare wöchentliche Zusammenfassung verwandelt. Ein Agent, der nach Besprechungen mit Kunden unser Produkt-Backlog mit dem aktualisiert, was nach Ansicht bestimmter Unternehmen noch fehlt, damit Funktionsideen nicht zwischen einem Anruf und der nächsten Planungssitzung verloren gehen. Und Dutzende kleinerer Helfer für einzelne Aufgaben, die jemand für sich selbst entwickelt, ständig verbessert und schließlich mit dem Team teilt.
Wenn derselbe Agent parallel erweitert wurde
Die Reibung ging nicht von den Agenten aus, die wir einmal aufgebaut und dann vergessen hatten. Sie kam von den Agenten, die tatsächlich wichtig waren. Zwei Leute nahmen einen nützlichen Agenten, jeder hatte eine eigene Idee, wie man ihn verbessern könnte, und begannen, ihn unabhängig voneinander zu erweitern. Eine Woche später hatten wir zwei Versionen: unterschiedliche Prompts, unterschiedliche Tools, unterschiedliche Randfälle – und keine saubere Möglichkeit, sie zusammenzuführen. Es war das gleiche Problem, das die Entwickler schon vor Jahrzehnten mit Git gelöst haben: Sie können nicht zwei Leute haben, die an einem gemeinsamen Ausgangspunkt arbeiten und ihn in verschiedene Richtungen verbessern, ohne ein Verzweigungsmodell zu haben. Wir waren einfach nicht der Meinung, dass wir eines brauchten. Agenten waren „einfach“. Der Begriff „KI-Projektmanagement“ war in unserem Wortschatz noch nicht enthalten.
Warum die Entwicklung von KI-Agenten im Grunde IT-Projektmanagement ist
Agenten bauen ist trivial einfach
Die erste Lektion ist die unangenehmste: Einen Agenten aufzubauen ist wirklich einfach. Jeder, der dies liest, kann ein Modell öffnen und innerhalb einer Stunde etwas zum Laufen bringen. Die Demo wird zauberhaft aussehen. Die ersten drei Benutzer werden es lieben. Und das ist genau der Moment, in dem das Projekt schwierig wird, denn eine Demo zu liefern, bedeutet nicht, ein Tool zu liefern, auf das sich das Unternehmen verlassen kann. Die Kluft zwischen „funktioniert mit den Eingaben, die ich ausprobiert habe“ und „funktioniert mit den Eingaben, die das ganze Unternehmen verwendet“ ist enorm, und das Modell selbst trägt nicht dazu bei, diese Kluft zu überbrücken. Die Überbrückung dieser Kluft ist die Aufgabe des KI-Projektmanagements.
Ein Business-Team, das KI-Agenten entwickelt, muss IT-Projektmanagement lernen
Wenn ein Team, das nicht aus der IT-Branche stammt, mit der Entwicklung von Software beginnt, und ein Agent ist eine Software, erbt es alle Probleme, mit denen Ingenieurteams fünfzig Jahre lang gelernt haben umzugehen. Die Anforderungen müssen aufgeschrieben werden. Die Architektur muss entworfen werden. Code, Eingabeaufforderungen oder Tooldefinitionen müssen irgendwo gemeinsam genutzt werden. Es müssen Tests existieren. Änderungen müssen überprüft werden, bevor sie in Betrieb genommen werden. Wenn Sie eine dieser Aufgaben auslassen, verschwindet sie nicht, sondern verschiebt die Kosten nur zeitlich nach vorne. Die gute Nachricht ist, dass es das Playbook bereits gibt. Die Disziplinen, die IT-Projekte zum Erfolg führen, gelten unverändert, wenn ein Unternehmensteam Agenten entwickelt. Die einzige neue Zutat ist die Evaluierung – die KI-spezifische Version des Testens.
Testen Sie FlexiProject!
Der Lebenszyklus eines KI-Agentenprojekts
1. Erste Analyse – welches Problem lösen wir eigentlich?
Jeder Agent, der es wert ist, entwickelt zu werden, beginnt mit einer Analysephase, die nichts mit KI zu tun hat. Wer wird ihn benutzen? Was tun sie heute, Schritt für Schritt? Welcher dieser Schritte tut tatsächlich weh? Wie sieht „gut gemacht“ aus – messbar? Bevor wir den Agenten für die Angebotserstellung entwickelten, schrieben wir die genaue manuelle Abfolge auf, die das Verkaufsteam befolgte, markierten, welche Schritte sich wiederholten und welche Ermessen erforderten, und entschieden erst dann, was der Agent tun sollte und was nicht. Die Analyse dauerte länger als die Erstellung. Dieses Verhältnis ist normal.
2. Planung – Umfang, Integrationen, gemeinsame Niederlassung
Bei der Planung legen Sie drei Dinge fest: Inputs und Outputs, die Integrationen, die der Agent berühren wird, und vor allem, wo die Arbeit stattfindet. Wenn zwei Personen einen Beitrag leisten wollen, brauchen sie eine gemeinsame Definition von „main“. Das kann ein einzelnes Dokument mit den kanonischen Prompts und Tooldefinitionen sein, ein Repo, ein Skill-Ordner – das Format ist weniger wichtig als die Vereinbarung. Legen Sie es gleich am ersten Tag fest. Entscheiden Sie, was der Agent nicht tun wird, schreiben Sie es auf und halten Sie sich daran. Scope creep ist der häufigste Grund, warum Agenten nicht mehr gewartet werden können.
3. Entwicklung – der trügerisch einfache Teil
Der Aufbau selbst ist schnell. Das ist der Haken an der Sache. Sie schreiben Ihre Prompts, schließen Ihre Tools an, führen ein paar Beispiele aus und fühlen sich zu 80% fertig. Sie sind eher bei 30%. Die verbleibenden 70% sind alles, was Sie noch nicht getestet haben: die seltsamen Eingaben, die langen Eingaben, die Eingaben in einer anderen Sprache, die Fälle, in denen ein Tool ein leeres Ergebnis liefert, die Fälle, in denen der Benutzer mitten im Gespräch seine Meinung ändert. Nichts davon ist aus dem Inneren des Builds heraus sichtbar.
4. Testen – und dann wieder Testen
Hier unterscheiden sich Agenten am stärksten von klassischer Software, und hier sparen die meisten Teams an der falschen Stelle. Ein Agent besteht heute einen Test und kann morgen denselben Test nicht bestehen, weil Sie eine einzige Zeile in der Eingabeaufforderung geändert haben oder weil das zugrunde liegende Modell aktualisiert wurde. Die Disziplin, die Sie brauchen, ist die Regressionsbewertung: ein gespeicherter Satz von Eingaben mit dem erwarteten Verhalten, der automatisch oder zumindest systematisch nach jeder Änderung ausgeführt wird. Ohne dies erfahren Sie nur von Regressionen, wenn ein Benutzer darüber stolpert.
5. Lieferung und Übergabe
Ein Agent, der nie offiziell ausgeliefert wird, ist ein Agent, der vom ersten Tag an veraltet ist. Die Auslieferung bedeutet, dass Sie die Dokumentation für den Benutzer schreiben, definieren, wie der Erfolg in der Produktion aussieht, und eine Möglichkeit einrichten, um zu überwachen, ob der Agent drei Monate später noch nützlich ist. Das haben wir auf die langsame Art gelernt – siehe den nächsten Abschnitt.
MVP, Agile und Scrum in KI-Projekten
MVP first – beginnen Sie mit dem kleinsten nützlichen Agenten
Jeder Agent, den wir erfolgreich entwickelt haben, begann als kleinste nützliche Version seiner selbst. Eine Aufgabe. Eine Eingabe. Eine Ausgabe. Wir haben der Versuchung widerstanden, den zweiten Anwendungsfall hinzuzufügen, bis wir gesehen haben, dass der erste den Kontakt mit echten Benutzern überlebt hat. Die Agenten, die sich schwer taten, waren das Gegenteil: vom ersten Tag an ehrgeizig, mit drei Funktionen, von denen keine durchgehend funktionierte. Big-Bang-Agenten scheitern aus genau denselben Gründen, aus denen Big-Bang-Softwareprojekte scheitern; der Formfaktor ändert nichts an der Rechnung. Wenn Sie nur eine Regel aus diesem Artikel mitnehmen, dann diese: Ein MVP für einen KI-Agenten ist so klein, dass eine Person ihn in drei Sätzen beschreiben und am Ende eines Tages an einem echten Beispiel durchspielen kann. Alles danach ist Iteration.
Warum Agile für KI-Agenten natürlich passt
Agenten sind ungewöhnlich gut für die agile Arbeit geeignet, weil sie ungewöhnlich unberechenbar sind. Sie können einen Agenten nicht im Voraus vollständig spezifizieren, so wie Sie ein Zahlungsformular oder einen Bericht spezifizieren. Sie erstellen eine kleine Version, beobachten, wie sie in der realen Welt funktioniert, sehen, wo sie versagt, und verbessern die nächste Sache. Der Versuch, den perfekten Agenten auf dem Papier zu entwerfen, bevor Sie ihn bauen, ist der schnellste Weg, den falschen Agenten zu bauen. Iteration ist keine Vorliebe des Projektmanagements für KI, sondern eine strukturelle Anforderung – der gleiche Plan-Do-Check-Act-Rhythmus, den Deming schon vor Jahrzehnten für jeden Prozess beschrieben hat, der ständig verbessert werden muss, nur eben angewandt auf Agenten, deren Verhalten Sie nicht vollständig vorhersagen können.
Agentenarbeit in Scrum-Sprints ausführen
Wir behandeln jeden wichtigen Agenten wie einen kleinen Arbeitsstrom im Stil von Scrum. Es gibt ein Backlog von Fähigkeiten, die der Agent haben könnte. Jeder Sprint wählt eine kleine Anzahl von ihnen aus. Die Sprint-Demo ist der Agent selbst, der mit echten Eingaben des Teams, das ihn verwenden wird, läuft. Wenn die Demo nicht überzeugend ist, wird die Arbeit fortgesetzt. Die Kadenz zwingt zu einer echten Konversation zwischen dem Entwickler und den Benutzern, anstatt einer monatelangen stillen Entwicklung.
Fehler, die wir gemacht haben
Bauen vor Analysieren
Weil der Aufbau so schnell geht, scheint es effizient zu sein, direkt dazu überzugehen. Ist es aber nicht. Agenten, die wir ohne eine klare Analyse gebaut haben, funktionierten zwar technisch, lösten aber das falsche Problem. Das Team, das sie einsetzte, war eine Zeit lang höflich darüber und ging dann still und leise dazu über, die Arbeit manuell zu erledigen. Ein Nachmittag mit einer Analyse hätte eine Woche Bauzeit gespart.
Dem Modell vertrauen, dass es das herausfindet
Dies war der konsequenteste Fehler, den wir gemacht haben und der am schwersten zu verlernen war. Wir gingen davon aus, dass das Modell eine gute Lösung finden würde, wenn wir ihm die Aufgabe in einfacher Sprache geben. Das war oft nicht der Fall – nicht, weil das Modell schwach war, sondern weil wir die Designarbeit nicht selbst geleistet hatten. Das Modell hat keinen Einblick in den Kontext Ihres Unternehmens, Ihre vorhandenen Daten, Ihre ungeschriebenen Konventionen, das System rund um die Aufgabe. Je mehr Sie ihm davon geben, eine echte Analyse, eine echte Architektur, die Struktur, der Sie folgen wollen, desto besser das Ergebnis. Das Modell ist hervorragend in der Ausführung. Es ist nicht Ihr Architekt.
Ein großer Wurf, anstatt mit einem MVP zu beginnen
Jedes Mal, wenn wir versuchten, gleich am ersten Tag einen voll funktionsfähigen Agenten auf den Markt zu bringen, dauerte das Ergebnis länger, war schwieriger zu debuggen und wurde häufiger aufgegeben als die kleinen Versionen, die wir absichtlich entwickelt hatten. Big-Bang fühlte sich schneller an. War es aber nicht.
Zwei Personen entwickeln parallel denselben Wirkstoff
Dies war der Git-Moment. Zwei Leute, derselbe Agent, unterschiedliche Ideen, unterschiedliche Zweige in ihren Köpfen, kein gemeinsames „main“. Eine Woche später waren es zwei Versionen, die sich nicht miteinander vereinbaren ließen. Wir behandeln jetzt jeden sinnvollen Agenten so, wie Entwickler ihren Code behandeln: eine kanonische Version, ein explizites Verzweigungsmodell, wenn mehr als eine Person daran arbeitet, und ein expliziter Merge-Schritt. Oder, wenn die Ideen wirklich voneinander abweichen, eine bewusste Entscheidung, sich in zwei separate Agenten aufzuteilen, anstatt so zu tun, als ob sie immer noch einer wären.
Keine anfängliche Dokumentation – die Benutzer wussten nicht, was der Agent tat
Die ersten internen Nutzer unserer Fähigkeiten stellten immer wieder dieselben Fragen: Was macht dieses Ding eigentlich, was muss ich eingeben, wie sieht die Ausgabe aus, wann sollte ich es im Vergleich zur vorherigen Version verwenden. Wir dachten, der Agent sei selbsterklärend. War er aber nicht. Wir schreiben jetzt für jeden Agenten bei der Übergabe eine kurze Beschreibung für den Benutzer – was er tut, was man ihm geben muss, was man erwarten kann und was er nicht tut. Das kostet zehn Minuten und verhindert wochenlange Verwirrung bei der Benutzung.
Testen Sie FlexiProject!
Häufig gestellte Fragen zum KI-Projektmanagement
Unterscheidet sich das KI-Projektmanagement vom normalen IT-Projektmanagement?
Die Disziplinen sind die gleichen – Analyse, Planung, Erstellung, Test, Auslieferung, Iteration. Die Unterschiede liegen in den Erstellungs- und Testphasen: Die Ergebnisse sind nicht deterministisch, das Verhalten kann sich ändern, wenn sich das Modell oder die Eingabeaufforderungen ändern, und „Testen“ wird zu „Bewertung anhand einer gespeicherten Gruppe von Fällen“. Alles um diese Phasen herum sieht aus wie ein normales IT-Projekt.
Brauche ich ein Projektmanagement-Tool, um die Entwicklung von KI-Agenten zu verwalten?
Sie brauchen einen Ort, an dem jeder Agent als Projekt lebt: mit einem Plan, einer aktuellen Version, einem Eigentümer und einem Lieferstatus. Ob dieser Ort ein Projektmanagement-System, ein Wiki oder eine Ordnerstruktur ist, ist weniger wichtig als die Tatsache, dass Sie eines haben. Für Teams, die viele Agenten parallel betreiben, macht sich ein echtes PM-System schnell bezahlt.
Wie groß sollte ein MVP-Agent sein?
Klein genug, dass eine Person es in drei Sätzen beschreiben und am Ende eines Tages an einem echten Beispiel durchspielen kann. Wenn Sie das nicht können, ist der Umfang zu groß und das MVP ist etwas enger gefasst.
Wie können Sie verhindern, dass zwei Personen parallel denselben Agenten entwickeln?
Sie halten nicht zwei Personen davon ab, einen Beitrag zu leisten – Sie machen deutlich, wo die kanonische Version lebt, wem die Zusammenführung gehört und wann abweichende Ideen zu einer bewussten Abspaltung in zwei separate Agenten werden sollten. Die Lektion aus der Softwareentwicklung gilt eins zu eins: ein gemeinsamer Zweig mit einem vereinbarten Zusammenführungsprozess.
Wann wird ein Agent zum Erben?
In dem Moment, in dem niemand mehr dafür verantwortlich ist, zu beurteilen, ob er noch hilft. Ein Agent, der von niemandem überprüft wird, verschlechtert sich still und leise, die Welt um ihn herum verändert sich, die Eingaben entwickeln sich weiter, das zugrunde liegende Modell wird ersetzt, und eines Tages ist er falsch und niemand bemerkt es. Vererbung ist kein Alter, es ist ein Zustand der Vernachlässigung.
Fazit
Der aufregende Teil der Entwicklung von KI-Agenten, das Modell, die Eingabeaufforderungen, der Moment, in dem eine Demo zum ersten Mal funktioniert, ist der kleinste Teil der Arbeit. Die weniger aufregenden Teile sind es, die aus einer Demo ein Tool machen, auf das sich das ganze Unternehmen verlassen kann: eine klare Analyse, ein echter Plan, ein gemeinsamer Zweig, Regressionstests, Dokumentation und ein Iterationsrhythmus, der den Agenten noch lange nach der Auslieferung der ersten Version nützlich macht. Nichts davon ist exotisch. Es ist genau die Disziplin, die IT-Projekten seit Jahrzehnten zum Erfolg verhilft, und zwar ohne Verwässerung auf eine etwas neuere Art von Software angewendet. Die Teams, die diese Disziplin frühzeitig anwenden, haben am Ende Agenten, denen sie vertrauen. Die Teams, die das nicht tun, müssen denselben Agenten zweimal neu entwickeln. KI-Projektmanagement bedeutet in der Praxis, jeden Agenten wie ein echtes Projekt zu behandeln, mit einem Plan, den Sie aufstellen, überarbeiten und verbessern können. Wir tun dies in FlexiProject, wo jeder Agent seine eigene Projektakte mit einem klar formulierten Aktionsplan erhält. Egal, für welches System Sie sich entscheiden, behandeln Sie jeden Agenten als Projekt, nicht als Experiment.
AUTOR
Dominik Wrzosek
General Manager at FlexiProject
![Was ist ein Gantt-Diagramm, und wie erstellt man es? [BEISPIEL]](https://flexi-project.com/wp-content/uploads/2024/04/What-is-Gantt-chart-e1714048900401.png)
