Wie aus einer Frage ein Produkt wird

Unsere Methode heisst Value Engineering. Wir nutzen sie in einem einfachen Sinn: die gewünschte Leistung verstehen, den nötigen Aufwand anschauen und einen besseren Weg ausprobieren. Es geht nicht darum, Qualität gegen einen tieferen Preis zu tauschen. Es geht darum zu sehen, welche Teile wirklich zum Ergebnis beitragen.

Bei einem AI-Werkzeug könnte die eigentliche Funktion so lauten: einer Person helfen, eine Änderung am Code sicher zu beurteilen. «Möglichst viele Dateien lesen» ist dann kein Ziel. Eine klare Erklärung, die passenden Belege und die relevanten Tests kommen der Sache näher. Diese Unterscheidung schützt uns davor, Aktivität mit Nutzen zu verwechseln.

LeanCTX ist eine konkrete Antwort auf solche Fragen. Seine Leseansichten behandeln Orientierung und genaue Prüfung unterschiedlich. Ein Strukturüberblick passt für den Einstieg. Der vollständige Inhalt passt für die genaue Untersuchung. Es geht also nicht darum, jeden Zugriff möglichst klein zu machen. Es geht darum, für jeden Schritt das richtige Material bereitzuhalten. [1]

Thinkery entscheidet über diese Fragen selbst. Wir bestimmen, was wir entwickeln, veröffentlichen und langfristig pflegen. Value Engineering ist dabei unsere interne Arbeitsweise. Sie lenkt Entwicklungszeit dorthin, wo sie für die Aufgabe am meisten bringt. Rückmeldungen aus der Nutzung führen zur nächsten Frage: Was gehört in die nächste Version?

Vor einem Versuch halten wir drei Dinge fest. Welche Verbesserung erwarten wir? Woran würden wir sie erkennen? Was muss unbedingt erhalten bleiben? So wird aus «Das sollte effizienter sein» eine prüfbare Frage. Zum Beispiel: Verkürzt eine gezielte Dateiansicht den Einstieg, ohne dass eine wichtige Ausnahme untergeht? Der zweite Teil zählt genauso wie der erste.

Der erste Versuch muss nicht das ganze Produkt abbilden. Ein einzelner Ablauf genügt, wenn er die entscheidende Unsicherheit zeigt. Wir bauen so wenig wie möglich, um etwas zu lernen. Und genug, damit die Beobachtung mehr ist als eine hübsche Vorführung. Schwierige Eingaben, Unterbrechungen und Änderungen am Auftrag gehören dazu.

Ein möglicher Aufbau: eine Codeänderung mit einer absichtlich eingebauten Ausnahme. Der vollständige Lesezugriff dient als Vergleich, die gezielte Ansicht als Alternative. Beide müssen die Ausnahme zeigen. Erst danach lohnt der Blick auf Laufzeit und Textmenge. Das ist ein Beispiel für einen Versuchsaufbau, kein berichtetes Messergebnis. Es zeigt, warum wir die Anforderungen vorher festlegen. Sonst erklärt man den günstigen Ausgang nachträglich zum Ziel.

Nach einer Änderung schauen wir wieder auf die ursprüngliche Aufgabe. Hat sie geholfen? Ist an anderer Stelle Arbeit dazugekommen? Bleibt die Bedienung verständlich? Ein Versuch kann zeigen, dass eine Idee trägt. Er kann auch zeigen, dass wir die Frage anders stellen müssen. Beides ist nützlich, wenn wir Bedingungen und Beobachtung sauber notieren.

Einzelne Messwerte brauchen einen Zusammenhang. LeanCTX führt zum Beispiel ein lokales Verzeichnis von Einsparungsereignissen, dessen Integrität sich prüfen lässt. So wird eine technische Veränderung besser nachvollziehbar. Für den Entscheid schauen wir zusätzlich, ob die Aufgabe gut erledigt wurde. Ein sauber geführter Nachweis beantwortet nur die Frage, die er tatsächlich erfasst. [2]

Wir trennen deshalb drei Ebenen. «Dieser Durchlauf brauchte weniger Eingabetext» ist eine Beobachtung. «Die Auswahl könnte für diese Aufgabe reichen» ist eine Deutung. «Wir prüfen den Ansatz an weiteren Aufgaben» ist ein Entscheid. Vermischt man die Ebenen, wirkt ein früher Versuch endgültiger, als er ist.

Nach einem Versuch muss nicht immer eine neue Funktion entstehen. Manchmal ist eine verständlichere Voreinstellung besser. Manchmal bleibt der bestehende Weg der richtige. Und manchmal halten wir eine Erkenntnis fest und bauen vorerst nicht weiter. Ein Produkt soll durch die Arbeit klarer werden, nicht automatisch grösser.

Eine Produktfirma lebt mit ihren Entscheidungen weiter. Jede zusätzliche Funktion will gepflegt werden. Jede Voreinstellung prägt die Nutzung. Deshalb ist der begründete Entscheid, etwas klein zu halten, so wertvoll wie eine Erweiterung. Wir wollen Produkte bauen, deren Umfang sich aus ihrer Aufgabe erklärt. Die nächste Version soll auf dem beruhen, was wir gelernt haben.