Methode
Neues Denken | Bewährte Verfahren
KI-Workflower verbindet Verfahren aus Qualitätsmanagement und Softwareentwicklung zu einem Arbeitsablauf, in dem Zielverständnis, Risiko, Umsetzung und Prüfung zusammengehören.
Es geht nicht darum, möglichst viele Prüfungen einzubauen. Entscheidend ist, an der richtigen Stelle die richtige Frage zu stellen.
PoC
Erst beweisen, dass der Weg trägt.
Eine offene technische Annahme wird geprüft, bevor darauf die eigentliche Lösung aufgebaut wird.
QFD
Vom Auftrag bis zum Prüfergebnis.
Die Anforderung bleibt mit Abnahmekriterium, Risiko, Prüfung und tatsächlichem Ergebnis verbunden.
Risikoregister
Risiken sichtbar machen und im Blick behalten.
Erkannte Risiken werden festgehalten, klassifiziert, bewertet und über den weiteren Ablauf verfolgt.
Mini-FMEA
Mögliche Fehler bedenken, bevor sie auftreten.
Vor der Änderung wird gefragt, was schiefgehen kann, wie kritisch das wäre und woran es erkannt wird.
Etappe 1
Bevor etwas geändert wird
Erst verstehen, dann ändern
Der Ablauf beginnt mit der Klärung des Ziels. Aus der Anforderung wird ein möglichst eindeutiges Ergebnisbild: Was soll tatsächlich erreicht werden, und woran lässt sich später erkennen, dass die Aufgabe erfüllt ist? Dieses Ergebnisbild gibt der weiteren Umsetzung und Prüfung die Richtung vor.
Offene Annahmen sichtbar machen
Nicht jede technische Entscheidung lässt sich zu Beginn sicher treffen. KI-Workflower unterscheidet deshalb zwischen dem, was bereits belegt ist, und dem, was zunächst nur angenommen wird. Eine falsche Annahme soll nicht unbemerkt in Planung, Code und Tests weitergetragen werden.
Proof of Concept
Ist eine offene technische Annahme für den weiteren Weg entscheidend, wird sie in einem bewusst begrenzten Versuch geprüft. Ein PoC ist keine kleine Vorabversion des fertigen Programms. Er soll eine konkrete Unsicherheit beseitigen.
Risiko bestimmt die Prüftiefe
Nicht jede Änderung ist gleich riskant. Eine kleine, klar begrenzte Korrektur braucht einen anderen Aufwand als ein Eingriff in Datenhaltung, Sicherheitsmechanismen oder zentrale Programmlogik. Die Risikoeinstufung steuert deshalb Analyse, Absicherung und Prüfung.
Abnahmekriterien vor der Umsetzung
Ein Test wird nicht ausgeführt, um zu zeigen, dass der neue Code funktioniert. Er prüft, ob das vorher festgelegte Abnahmekriterium tatsächlich erfüllt ist.
Etappe 2
Damit der Zusammenhang erhalten bleibt
QFD-basierte Rückverfolgbarkeit verbindet die fachliche Forderung mit ihrem späteren Nachweis:
Risikoregister
Erkannte Risiken werden festgehalten, klassifiziert, bewertet und über den weiteren Ablauf verfolgt.
Mini-FMEA
Bei risikoreicheren Änderungen richtet sich der Blick bewusst auf mögliche Fehler: Was könnte schiefgehen? Welche Folgen hätte das? Woran würden wir es erkennen? Die Mini-FMEA übernimmt den Denkansatz der Fehlermöglichkeits- und Einflussanalyse, ohne daraus eine industrielle Voll-Dokumentation zu machen.
Ausgangszustand sichern
Vor dem ersten Schreibzugriff muss klar sein, worauf im Fehlerfall zurückgefallen werden kann. Ebenso wichtig ist ein bekannter Ausgangszustand, damit später unterschieden werden kann, ob ein Fehler bereits vorhanden war oder durch die aktuelle Änderung entstanden ist.
Etappe 3
Umsetzen und wirklich prüfen
Umsetzung mit bekannten Grenzen
Der Coding-Agent kennt nun Ziel, Annahmen, Risiko, Abnahmekriterien und – abhängig vom Fall – mögliche Fehlerszenarien. Der Auftrag lautet nicht mehr nur „Baue diese Funktion“, sondern sinngemäß: Erreiche dieses Ziel, beachte diese Risiken, erhalte diese bestehenden Eigenschaften und liefere die vereinbarten Nachweise.
Prüfung bedeutet mehr als „Tests bestanden“
Nach der Umsetzung werden die zuvor festgelegten Prüfungen tatsächlich ausgeführt. Ein Fehlschlag führt nicht blind zur nächsten Codeänderung: War die Umsetzung nicht korrekt, die Annahme unzutreffend, das Abnahmekriterium unvollständig oder die Prüfung ungeeignet?
Rückfallprüfung
Wurde ein Fehler erkannt und behoben, soll die daraus gewonnene Erkenntnis nicht verloren gehen. Wo sinnvoll, wird daraus eine dauerhafte Prüfung, die ein Wiederauftreten erkennt.
Nicht-Verlust-Prüfung
Eine Änderung kann ihre neue Aufgabe erfüllen und trotzdem an anderer Stelle Schaden verursachen. Deshalb wird zusätzlich gefragt: Funktioniert nach der Änderung auch das noch, was vorher bereits funktioniert hat?
Gegenprüfung
Ein Coding-Agent darf seine Arbeit prüfen. Wo eine belastbare Bestätigung notwendig ist, reicht seine eigene Aussage jedoch nicht als einzige Grundlage. Abhängig vom Risiko werden getrennte technische oder menschliche Prüfschritte verlangt.
Etappe 4
Vom Prüfergebnis zum Nachweis
Der Nachweis gehört zum Ergebnis
Zu einem abgeschlossenen Arbeitsschritt gehören auch die Ergebnisse der vorgesehenen Prüfungen. Damit bleibt nachvollziehbar, was geändert werden sollte, welche Risiken berücksichtigt wurden, was tatsächlich geprüft wurde und auf welchen Projektstand sich das Ergebnis bezieht.
FEUERFEST steht am Ende
FEUERFEST Local 1.0 ist nicht der Entwicklungsprozess selbst. Es ist der Prüfmechanismus am Ende. Erst wenn die für einen konkreten Projektstand festgelegten Bedingungen vorliegen, kann dieser Stand den Zustand FEUERFEST erreichen.
Regelschleifen
Ein Kreislauf statt einer geraden Linie
Neue Erkenntnisse dürfen frühere Entscheidungen verändern. Ein PoC kann eine Annahme widerlegen. Eine Mini-FMEA kann ein zusätzliches Abnahmekriterium nötig machen. Ein Test kann zeigen, dass das Ziel missverstanden wurde. Eine Nicht-Verlust-Prüfung kann einen bislang unbeachteten Zusammenhang sichtbar machen.
Dann wird nicht einfach weitergemacht. Der Prozess springt bewusst an die Stelle zurück, an der die neue Erkenntnis berücksichtigt werden muss.
Qualität entsteht nicht dadurch, dass ein Ablauf einmal von oben nach unten abgearbeitet wird. Sie entsteht dadurch, dass neue Erkenntnisse den weiteren Weg tatsächlich verändern dürfen.