Eine „Won’t-have“-Liste hält genau so lange, bis man die App selbst benutzt.
Im ersten Teil habe ich beschrieben, wie aus einer Idee in einer Woche ein MVP wurde: Gewohnheiten auswählen, jeden Tag eine Frage pro Gewohnheit beantworten, Trends und einen Wochenbericht ansehen. So stand es im Anforderungsdokument, und so war es am 19. Juli fertig. Heute, knapp vier Monate später, kann Tageswerk deutlich mehr. Keines der Features, um die es in diesem Teil geht, stand im ursprünglichen Plan. Manche standen sogar ausdrücklich auf der Liste der Dinge, die es nicht geben sollte. Wie kommt so etwas in ein Projekt, das mit einem so klaren Scope gestartet ist? Und ist das dann schon Feature Creep?
Das erste zusätzliche Feature kam drei Tage nach dem ersten Commit, noch bevor das MVP fertig war. Der Katalog hatte fünf Kategorien, und es fehlte eine sechste: Achtsamkeit. Das war schnell gemacht, drei Einträge im Katalog und eine Migration. Interessanter ist, was am selben Tag daneben entstanden ist. Ein Dokument mit dem Titel „Roadmap: Achtsamkeits-Features“, in dem alle weiteren Ideen zu dem Thema gesammelt sind, mit dem deutlichen Hinweis, dass nichts davon zum MVP gehört. Diese Arbeitsweise hat sich durch das ganze Projekt gezogen. Eine Idee wird aufgeschrieben, bekommt eine Nummer und wartet. Das klingt banal, ist aber der Unterschied zwischen einem Backlog und einem Projekt, das in fünf Richtungen gleichzeitig läuft. Mit einem Agenten, der jede Idee in einer Stunde umsetzen kann, ist die Versuchung groß, es einfach zu tun.
Die nächsten Features kamen aus der eigenen Nutzung. Nach ein paar Tagen mit der App fehlte mir etwas. Fünf Zahlen pro Tag sagen, wie der Tag war, aber nicht, was an ihm gut war. So kam am 22. Juli der „Stolz-Moment“ dazu, ein einzelnes Textfeld am Ende der Reflexion. Worauf bist du heute stolz? Dazu ein optionales Journal und zwei Tage später ein Stress-Barometer. Freitext stand im Anforderungsdokument unter „Could-have, nach dem MVP“. Die Regel, dass die Reflexion in zwei Minuten nur mit Antippen funktionieren muss, habe ich dafür nicht aufgegeben. Alle drei Felder sind optional und stehen am Ende, nach den Fragen. Wer es eilig hat, tippt fünfmal und ist fertig. Am selben Tag kam auch das Feature, das am weitesten vom ursprünglichen Plan entfernt war. Ein Sprachmodell schreibt aus den Zahlen einer Woche oder eines Monats ein paar Sätze Zusammenfassung. Das ist nur nach ausdrücklicher Einwilligung aktiv, standardmäßig aus, und übertragen werden weder Name noch E-Mail noch eine Nutzerkennung.
Und die „Won’t-have“-Liste? Dort stand „Tablet-/Desktop-Versionen“. Seit Version 0.8.0 vom 24. August läuft die komplette App auch im Browser, mit demselben Konto und denselben Daten. Der Grund war simpel. Die Website gab es schon, die Logik lag sauber getrennt in gemeinsamen Paketen, und Trends liest man am großen Bildschirm einfach besser. Dort stand auch „KI-generierte Coaching-Empfehlungen“. Dazu gleich mehr. Ich finde es nicht schlimm, dass die Liste nicht gehalten hat. Sie hat ihren Zweck erfüllt, nämlich das MVP klein zu halten. Ein Plan, der nach vier Monaten Nutzung noch unverändert gilt, wäre mir eher verdächtig. Das habe ich im letzten Jahr über agile Arbeit im Beruf geschrieben, und es gilt für das eigene Projekt genauso.
Im September kam der Urlaubsmodus. Das Problem dahinter kennt jeder, der schon einmal eine Serie in irgendeiner App gepflegt hat. Zwei Wochen Urlaub, kein Sport nach Plan, und die Serie von 60 Tagen ist weg. Die naheliegende Lösung wäre, die Serie einfach einzufrieren. Im Projekt steht dazu ein Satz, der mir besser gefällt: Ein Urlaubstag ist kein Tag. Eine beurlaubte Gewohnheit wird an diesen Tagen nicht abgefragt, sie reißt keine Serie, und sie steht in keinem Bericht im Nenner. Die Urlaube werden als Historie gespeichert, denn auch der Jahresbericht im Dezember muss noch wissen, dass im August Urlaub war. Sonst fallen die fehlenden Tage rückwirkend wieder negativ auf. Ein Detail am Rande: Eine beurlaubte Gewohnheit zählt im kostenlosen Tarif weiter gegen die Grenze von drei Gewohnheiten. Sonst wäre Beurlauben der bequemste Weg, die Grenze zu umgehen.
Am meisten gelernt habe ich bei der Stimmung. Die Idee: Man hält fest, wie es einem gerade geht, jederzeit und beliebig oft am Tag, aus einem Katalog von neun Stimmungen. Am 22. September gibt es dazu sechs Commits, und an ihnen kann man ablesen, wie sich ein Feature an einem Tag einmal komplett dreht. Die erste Fassung hatte, was man erwartet: Jede Stimmung bekam einen Wert von −2 bis +2, daraus wurde eine Kurve mit Mittelwert und einem Pfeil gegenüber der Vorwoche. Das sah gut aus. Aber eine Kurve braucht eine Höhe, eine Höhe braucht eine Rangfolge, und eine Rangfolge über Stimmungen ist eine Bewertung. „Müde“ läge unter „freudig“, und ein fallender Verlauf sähe aus wie Scheitern. Will ich eine App, die mir sagt, dass meine Woche schlechter war, weil ich müde war? Am Abend war die Wertung wieder draußen. Statt der Kurve gibt es ein Raster: neun Zeilen, eine Spalte pro Tag, ein Punkt pro Eintrag. Es wird gezählt, nie bewertet. Damit das so bleibt, gibt es einen Test, der fehlschlägt, sobald irgendwo im Code wieder etwas mit dem Namen „valence“, „score“ oder „rank“ auftaucht. Solche Tests habe ich inzwischen mehrere. Sie prüfen keine Funktion, sie halten eine Entscheidung fest. Auch gegenüber einem Agenten, der in drei Monaten in einer neuen Session die naheliegende Idee mit der Kurve noch einmal hat.
Das größte Modul ist das jüngste. In der Oberfläche heißt es „Handschrift“. Dahinter steht eine Methode aus dem Führungskräfte-Coaching, die dort „Leadership Brand“ heißt. Man hält in einem Satz fest, wer man sein will, „Ich bin …“ in höchstens zwanzig Wörtern, und prüft dann täglich mit einem Tipp, ob der Satz noch passt. Dazu kommen ein paar Wörter, an denen man sich messen will, und die man im Tagesrückblick antippt. Das Thema liegt mir nah, die Kategorie „Innovative Führung“ hier im Blog gibt es nicht ohne Grund. Trotzdem habe ich es für die App anders entschieden. Das Modul ist für alle da, nicht nur für Führungskräfte. Das Wort „Führungskraft“ kommt in keiner der acht Sprachen in den Texten vor, und auch das hält ein Test fest. Hier kommt die KI ins Spiel, die laut „Won’t-have“-Liste nie coachen sollte. Ein Workshop führt mit Fragen von fünf Themen über drei zum eigenen Satz, und ein Sprachmodell kann dabei helfen. Der Grundsatz dazu steht im Konzept: Das Modell schlägt vor, der Nutzer entscheidet. Es arbeitet nur am Text, gibt keine Note und keine Ratschläge fürs Leben, und nichts wird gespeichert, bevor man es selbst übernommen hat. Der ganze Ablauf funktioniert auch von Hand, ganz ohne KI.
Bei der Handschrift lief der Weg anders als bei den kleinen Features. Zuerst gab es am 31. Oktober ein Konzeptdokument. Daraus wurden fünf Etappen mit je einem Issue, von denen jede einzeln ausgeliefert werden kann. Die Umsetzung aller fünf Etappen hat dann einen einzigen Tag gedauert, den 1. November, ein Sonntag. Sieben neue Tabellen, App und Web, acht Sprachen. Das Konzept zu schreiben und die Entscheidungen darin zu treffen hat länger gedauert als die Umsetzung. Daran muss ich mich immer noch gewöhnen.
Ist das nun Feature Creep? Ich glaube nicht, solange zwei Dinge gelten. Der Kern bleibt unangetastet, die Reflexion dauert weiterhin zwei Minuten und kommt ohne Tippen aus. Und jedes neue Feature muss sich an denselben Grundsätzen messen lassen: optional, gezählt statt bewertet, nichts verlässt das Gerät ohne Einwilligung. Diese Grundsätze standen nicht alle am ersten Tag fest. Sie sind beim Bauen entstanden, meistens in dem Moment, in dem die erste Fassung fertig war und sich falsch angefühlt hat. Aufgeschrieben sind sie jetzt in der CLAUDE.md und in Tests.
Bis hierhin ging es um das, was die App kann. Dass sie jemand anderes als ich installieren kann, ist eine ganz andere Geschichte. Im nächsten Teil geht es um den Weg in den Play Store und darum, wie die Zusammenarbeit mit Claude im Alltag aussieht.
