Discovery durchführen

Die Discovery vermittelt dem Product Engineer genügend Verständnis, um ein nützliches Produkt zu definieren und Coding-Agenten nicht das falsche Problem lösen zu lassen. Sie sollte angestrebtes Ergebnis, beteiligte Menschen und Prozesse, wesentliche Beschränkungen und wichtige offene Entscheidungen ermitteln. Ziel ist ein klarer Ausgangspunkt, kein vollständiges Dokument, bevor jemand funktionierende Software erkunden kann.

Verantwortliche Rolle: Product Engineer.
Teilnehmer: Fachliche Stakeholder, vorgesehene Benutzer, Domänenexperten; bei Bedarf Architekt und UX-Designer.
Eingaben: Erstanfrage, vorhandene Prozessunterlagen, bestehender Produktkontext, bekannte Unternehmensbeschränkungen.
Ergebnisse: Problem- und Ergebnisbeschreibung, identifizierte Benutzer und Stakeholder, anfänglicher Umfang, wesentliche Abläufe, offene Fragen und vorläufige Ziele.

Der Product Engineer kann einen dialogbasierten KI-Assistenten einsetzen, um ein Geschäftsproblem zu durchdenken und gleichzeitig Informationen von Stakeholdern zu sammeln. Statt mit einem langen Fragebogen zu beginnen oder eine erste Funktionsanfrage für vollständig zu halten, kann er den aktuellen Arbeitsablauf erklären und den Assistenten bitten, Annahmen zu identifizieren, Alternativen zu erkunden und zu prüfen, ob die vorgeschlagene Lösung das tatsächliche Problem adressiert.

Der Assistent kann verstreute Notizen zu vorläufigen Abläufen ordnen, übersehene Akteure sichtbar machen, realistische Ausnahmen vorschlagen und fehlende Entscheidungen erkennen. Seine Beiträge sind Vorschläge zur Untersuchung, keine verbindlichen Anforderungen. Der Product Engineer prüft Tatsachenbehauptungen und bringt Fragen zu Geschäftsrichtlinien zum autorisierten Verantwortlichen zurück.

Das Gespräch kann gesprochen oder geschrieben sein und sich über mehrere Sitzungen erstrecken. Wesentliche Ergebnisse gehören in Produktziele, Entscheidungen und Funktionsspezifikationen, statt vom Gesprächsgedächtnis eines Agenten abzuhängen.

1. Anfrage und tatsächliches Problem verstehen. Klären Sie den Anlass, die Betroffenen, heutige Probleme und warum die vorgeschlagene Funktion helfen soll.
2. Den Arbeitsablauf im Gespräch erkunden. Nutzen Sie Stakeholder-Gespräche und, wo hilfreich, einen dialogbasierten KI-Assistenten, um Normalablauf, Entscheidungen, Übergaben und relevante Ausnahmen zu erfassen. Lassen Sie fehlende Annahmen hinterfragen und plausible Ansätze vergleichen.
3. Gewünschte Ergebnisse definieren. Beschreiben Sie Veränderungen für die arbeitenden Menschen und beobachtbaren Erfolg ohne unbelegte Kennzahlen.
4. Akteure, Daten und Einschränkungen identifizieren. Bestimmen Sie Berechtigungen, externe Abhängigkeiten, sensible Informationen, bestehende Unternehmensstandards und wichtige nichtfunktionale Grenzen.
5. Vereinbarte Regeln von offenen Fragen trennen. Nutzen Sie KI, um Mehrdeutigkeiten zu erkennen; folgenreiche Richtlinienentscheidungen treffen jedoch die tatsächlichen Verantwortlichen. Dokumentieren Sie Annahmen ausdrücklich.
6. Zusammenfassen und validieren. Überführen Sie das Gespräch in eine knappe Problembeschreibung, Anfangsumfang, Ergebnisse, Abläufe, Ausschlüsse und Entscheidungsprotokoll. Bestätigen Sie wesentliche Punkte mit relevanten Stakeholdern.
7. Validierte Absicht in Funktionsspezifikationen überführen. Halten Sie geklärtes Produktwissen in dauerhaften Artefakten fest; behandeln Sie das Gesprächsprotokoll selbst nicht als Spezifikation.

Ein Stakeholder fordert ein Genehmigungsdashboard. Der Product Engineer bittet einen dialogbasierten KI-Assistenten, den zugrunde liegenden Prozess zu durchdenken. Dieser vermutet, dass das eigentliche Problem nicht fehlende Diagramme, sondern nicht nachverfolgte Genehmigungsentscheidungen sein könnte. Er fragt auch, wer genehmigen darf, ob Genehmigende eigene Anträge genehmigen dürfen, ob Ablehnungsgründe erforderlich sind und wie Antragstellende das Ergebnis erfahren.

Der Product Engineer klärt diese Fragen mit Stakeholdern. Das vereinbarte Ergebnis kann ein kleiner Antrags- und Entscheidungsablauf ohne Analysedashboard sein. Der Implementierungsagent darf Genehmigungsberechtigungen oder Ablehnungsrichtlinien nicht eigenständig festlegen.

• Welche Arbeit wird heute erledigt und warum muss sie sich ändern?
• Wer startet den Prozess? Wer darf genehmigen, ablehnen oder korrigieren?
• Was ist für die ausführende Person ein erfolgreiches Ergebnis?
• Was geschieht, wenn erforderliche Informationen fehlen oder ungültig sind?
• Welche externen Systeme oder bestehenden Datensätze müssen einbezogen werden?
• Was ist ausdrücklich von der ersten Veröffentlichung ausgeschlossen?
• Welche Entscheidungen müssen Richtlinienverantwortliche statt des Entwicklungsteams treffen?
• Was sollte ein Stakeholder während des UAT demonstrieren können?

Discovery reicht aus, um mit der Spezifikationsarbeit zu beginnen, wenn das Geschäftsproblem und die gewünschten Ergebnisse klar sind, die wichtigsten Akteure, Arbeitsabläufe und der anfängliche Umfang verstanden wurden und wesentliche offene Entscheidungen mit ihren zuständigen Verantwortlichen dokumentiert sind. Dialogbasierte KI kann helfen, Annahmen zu erkennen und Optionen zu klären, ersetzt jedoch weder die Zustimmung der Stakeholder noch dauerhafte Projektdokumentation. Discovery kann fortgesetzt werden, wenn funktionierende Software neue Erkenntnisse liefert.

Eine angefragte Oberfläche als Geschäftsziel behandeln; widersprüchliche Stakeholder-Regeln ungeklärt übernehmen; große Mengen beiläufiger Details spezifizieren, die Feedback an funktionierender Software wirksamer klären würde; und einen technisch plausiblen Standardwert für eine autorisierte Richtlinienentscheidung halten.