Claude Code Aufgabenabgrenzung: Von vagen Anfragen zu Commits

Warum vage Feature-Anfragen Zeit verschwenden

Eine vage Anfrage klingt harmlos: „Bessere Suche hinzufügen“, „Onboarding flüssiger machen“, „Nutzer brauchen Benachrichtigungen.“ In echten Teams kommt sie oft als Ein-Zeilen-Chatnachricht, ein Screenshot mit Pfeilen oder ein halb erinnerter Kundenanruf. Alle sind sich einig, aber alle haben etwas anderes im Kopf.

Die Kosten zeigen sich später. Wenn der Scope unklar ist, arbeiten Leute mit Vermutungen. Die erste Demo wird zur nächsten Klärungsrunde: „Das meinte ich nicht.“ Arbeit wird neu gemacht, und die Änderung wächst stillschweigend. Design-Anpassungen lösen Code-Änderungen aus, die weitere Tests benötigen. Reviews verlangsamen sich, weil eine schwammige Änderung schwer zu verifizieren ist. Wenn niemand definieren kann, wie „korrekt“ aussieht, streiten Reviewer über Verhalten statt Qualität zu prüfen.

Vage Tasks erkennst du meist früh:

• Kein Schritt-für-Schritt-Beispiel, was ein Nutzer tun können soll
• Keine Edge-Cases (Leerzustände, Berechtigungen, Fehler)
• „Nur für den Fall“-Arbeit, die zu einem riesigen PR aufbläht
• Review-Kommentare, die über Verhalten statt Implementierung streiten
• „Wir klären das unterwegs“ wird zum Plan

Gut abgegrenzte Aufgaben geben dem Team eine Ziellinie: klare Akzeptanzkriterien, ein minimaler UI- und API-Plan und explizite Grenzen dessen, was nicht enthalten ist. Das ist der Unterschied zwischen „Suche verbessern“ und einer kleinen Änderung, die sich leicht bauen und prüfen lässt.

Eine praktische Gewohnheit: Trenne „Definition of done“ von „Nice-to-have“. „Done“ ist eine kurze Liste von Prüfungen, die du ausführen kannst (zum Beispiel: „Die Suche liefert Ergebnisse nach Titel, zeigt ‚Keine Ergebnisse‘ bei Leerzustand und behält die Query in der URL“). „Nice-to-have“ sind Dinge, die warten können (Synonyme, Ranking-Anpassungen, Hervorhebungen, Analytics). Das früh zu kennzeichnen verhindert unbeabsichtigtes Scope-Wachstum.

Mit dem Ergebnis beginnen, nicht mit der Lösung

Vage Anfragen starten oft als vorgeschlagene Fixes: „Button hinzufügen“, „auf neuen Flow wechseln“, „ein anderes Modell verwenden“. Stoppe kurz und übersetze den Vorschlag zuerst in ein Ergebnis.

Ein einfaches Format hilft: „Als [Nutzer] möchte ich [etwas tun], damit ich [ein Ziel erreiche].“ Halte es kurz. Wenn du es nicht in einem Atemzug sagen kannst, ist es noch zu schwammig.

Beschreibe als Nächstes, was sich für den Nutzer ändert, wenn es fertig ist. Konzentriere dich auf sichtbares Verhalten, nicht auf Implementierungsdetails. Zum Beispiel: „Nachdem ich das Formular abgeschickt habe, sehe ich eine Bestätigung und finde den neuen Eintrag in der Liste.“ Das schafft eine klare Ziellinie und macht es schwerer, dass „nur noch eine Kleinigkeit“ hereinschlüpft.

Schreibe auch auf, was gleich bleibt. Non-Goals schützen deinen Scope. Wenn die Anfrage „Onboarding verbessern“ heißt, könnte ein Non-Goal sein: „kein Dashboard-Redesign“ oder „keine Änderungen an der Preis-Tier-Logik“.

Wähle schließlich zuerst einen primären Pfad: die einzelne End-to-End-Schicht, die beweist, dass das Feature funktioniert.

Beispiel: statt „Snapshots überall hinzufügen“ schreibe: „Als Projektbesitzer kann ich den letzten Snapshot meiner App wiederherstellen, um eine schlechte Änderung rückgängig zu machen.“ Non-Goals: „kein Bulk-Restore, kein UI-Redesign."

Stelle die wenigen Fragen, die Mehrdeutigkeit entfernen

Eine vage Anfrage fehlt selten an Aufwand. Sie fehlt an Entscheidungen.

Beginne mit Einschränkungen, die den Scope still verändern. Deadlines sind wichtig, aber ebenso Zugriffregeln und Compliance-Bedürfnisse. Wenn du auf einer Plattform mit Tiers und Rollen baust, entscheide früh, wer das Feature bekommt und in welchem Plan.

Bitte dann um ein konkretes Beispiel. Ein Screenshot, das Verhalten eines Konkurrenten oder ein früheres Ticket zeigt, was „besser“ wirklich bedeutet. Hat der Anfragende keines, bitte ihn, die letzte Situation zu beschreiben, in der er den Schmerz gespürt hat: Auf welchem Bildschirm war er, was hat er geklickt, was hat er erwartet?

Edge-Cases lassen den Scope explodieren, also nenne die großen früh: leere Daten, Validierungsfehler, langsame oder fehlgeschlagene Netzwerkaufrufe und was „Undo“ wirklich bedeutet.

Entscheide abschließend, wie du den Erfolg verifizierst. Ohne ein testbares Ergebnis wird die Aufgabe zur Meinungsfrage.

Diese fünf Fragen entfernen meist die meiste Mehrdeutigkeit:

• Wer bekommt Zugriff (Tier und Rollen)?
• Was ist die Deadline und was ist die kleinstmögliche akzeptable Version?
• Was ist ein Beispiel des erwarteten Verhaltens?
• Was passiert bei Leerzuständen, Fehlern und langsamen Verbindungen?
• Wie bestätigen wir, dass es funktioniert (konkrete Kriterien oder Metrik)?

Beispiel: „Custom Domains für Kunden hinzufügen“ wird klarer, sobald du entscheidest, zu welchem Tier es gehört, wer es einrichten kann, ob Hosting-Standort für Compliance wichtig ist, welche Fehlermeldung bei ungültigem DNS erscheint und was „done“ heißt (Domain verifiziert, HTTPS aktiv, sichere Rollback-Option).

Verwandle unordentliche Notizen in Akzeptanzkriterien

Unklare Anfragen mischen Ziele, Vermutungen und halb erinnerte Edge-Cases. Die Aufgabe ist, das in Aussagen zu verwandeln, die jeder testen kann, ohne in deinen Kopf zu schauen. Dieselben Kriterien sollten Design, Entwicklung, Review und QA leiten.

Ein einfaches Muster hält es klar. Du kannst Given/When/Then verwenden oder kurze Bullet-Points, die dasselbe aussagen.

Eine schnelle Akzeptanzkriterien‑Vorlage

Schreibe jedes Kriterium als einen einzelnen Test, den jemand ausführen könnte:

• Given ein Startzustand, when der Nutzer X tut, then passiert Y.
• Nenne Validierungsregeln (welche Eingaben erlaubt sind).
• Füge mindestens einen Fehlerfall hinzu (welche Fehlermeldung der Nutzer sieht).
• Definiere das „Done-Signal“ (was QA prüft, was Reviewer erwarten).

Wende es jetzt an. Angenommen, die Notiz lautet: „Snapshots einfacher machen. Ich möchte zurückrollen können, wenn die letzte Änderung Probleme verursacht.“ Formuliere prüfbare Aussagen:

• Given ein Projekt mit 2 Snapshots, when ich Snapshots öffne, then sehe ich beide mit Zeitstempel und kurzer Bezeichnung.
• Given einen Snapshot, when ich Rollback klicke und bestätige, then wird das Projekt auf diesen Snapshot zurückgesetzt und die App baut erfolgreich.
• Given ich bin nicht der Projektbesitzer, when ich versuche zurückzurollen, then sehe ich eine Fehlermeldung und es ändert sich nichts.
• Given ein Rollback läuft, when ich die Seite neu lade, then sehe ich weiterhin Status und Endergebnis.
• Given ein Rollback schlägt fehl, when es stoppt, then sehe ich eine klare Meldung und die aktuelle Version bleibt aktiv.

Wenn QA diese Prüfungen ausführen kann und Reviewer sie in UI und Logs verifizieren können, bist du bereit, UI- und API‑Arbeit zu planen und in kleine Commits aufzuteilen.

Entwerfe einen minimalen UI-Plan

Ein minimaler UI-Plan ist ein Versprechen: die kleinstmögliche sichtbare Änderung, die beweist, dass das Feature funktioniert.

Beginne damit, zu benennen, welche Bildschirme sich ändern und was eine Person in 10 Sekunden bemerkt. Wenn die Anfrage „einfacher machen“ oder „aufräumen“ lautet, übersetze das in eine konkrete Änderung, die du zeigen kannst.

Schreibe es als kleine Karte, nicht als Redesign. Zum Beispiel: „Bestellungen-Seite: Filterleiste über der Tabelle hinzufügen“ oder „Einstellungen: neuen Schalter unter Benachrichtigungen hinzufügen.“ Wenn du Bildschirm und genaues Element nicht benennen kannst, ist der Scope noch unklar.

Definiere die wichtigsten UI‑Zustände

Die meisten UI-Änderungen brauchen ein paar vorhersehbare Zustände. Nenne nur die, die relevant sind:

• Laden
• Leer
• Fehler (und ob ein Retry möglich ist)
• Erfolg (Toast, Inline-Meldung, aktualisierte Liste)

Bestätige die Texte, die Nutzer sehen

UI‑Texte gehören zum Scope. Erfasse Labels und Meldungen, die freigegeben werden müssen: Button‑Text, Feldbezeichnungen, Hilfetexte und Fehlermeldungen. Wenn die Formulierungen noch offen sind, markiere sie als Platzhalter und notiere, wer sie bestätigt.

Behalte eine kleine „nicht jetzt“-Liste für alles, was nicht nötig ist, um das Feature zu nutzen (responsives Feintuning, erweiterte Sortierung, Animationen, neue Icons).

Entwerfe einen minimalen API- und Datenplan

Eine abgegrenzte Aufgabe braucht einen kleinen, klaren Vertrag zwischen UI, Backend und Daten. Ziel ist nicht, das ganze System zu entwerfen, sondern das kleinstmögliche Set an Requests und Feldern zu definieren, das beweist, dass das Feature funktioniert.

Beginne damit, die Daten aufzulisten, die du brauchst und woher sie kommen: bestehende Felder, die du lesen kannst, neue Felder, die du speichern musst, und Werte, die du berechnen kannst. Wenn du für jedes Feld keine Quelle benennen kannst, hast du noch keinen Plan.

Halte die API‑Oberfläche klein. Für viele Features reicht ein Read und ein Write:

• GET /items/{id} liefert den Zustand zum Rendern des Bildschirms
• POST /items/{id}/update nimmt nur das an, was der Nutzer ändern kann, und liefert den aktualisierten Zustand

Schreibe Eingaben und Ausgaben als einfache Objekte, nicht als Fließtext. Führe erforderliche vs. optionale Felder auf und beschreibe, was bei gängigen Fehlern passiert (nicht gefunden, Validierung fehlgeschlagen).

Führe vor Änderungen am DB kurz eine Auth-Prüfung durch. Entscheide, wer lesen und wer schreiben darf, und formuliere die Regel in einem Satz (z. B.: „Jeder angemeldete Nutzer kann lesen, nur Admins können schreiben“). Das Weglassen führt oft zu Nacharbeit.

Entscheide schließlich, was gespeichert werden muss und was berechnet werden kann. Ein einfacher Grundsatz: Fakten speichern, Views berechnen.

Nutze Claude Code, um eine abgegrenzte Aufgabe zu erzeugen

Claude Code funktioniert am besten, wenn du ein klares Ziel und eine enge Box vorgibst. Füge die unordentliche Anfrage und alle Einschränkungen (Deadline, betroffene Nutzer, Datenregeln) ein. Bitte dann um eine abgegrenzte Ausgabe, die enthält:

1. Eine verständliche Neufassung des Scopes und eine kurze Checklist mit Akzeptanzkriterien.
2. Eine kleine Sequenz von Commits (zielt auf 3–7), jeweils mit klarem Ergebnis.
3. Wahrscheinlich betroffene Dateien oder Ordner pro Commit und welche Änderungen darin nötig sind.
4. Einen kurzen Testplan pro Commit (ein Happy Path und ein Edge Case).
5. Explizite Out‑of‑Scope‑Notizen.

Lies die Antwort danach wie ein Reviewer. Wenn du Formulierungen wie „Performance verbessern“ oder „aufgeräumter machen“ siehst, fordere messbare Beschreibungen an.

Mini‑Beispiel (wie „gut“ aussieht)

Anfrage: „Füge eine Möglichkeit hinzu, ein Abo zu pausieren."

Eine abgegrenzte Version könnte sagen: „Der Nutzer kann für 1 bis 3 Monate pausieren; das nächste Abrechnungsdatum aktualisiert sich; Admins sehen den Pausen‑Status.“ Out of scope: „Keine Änderungen an Proration.“

Daraus wird der Commit-Plan praktisch: ein Commit für DB und API‑Form, einer für UI‑Controls, einer für Validierung und Fehlerfälle, einer für E2E‑Tests.

Teile Arbeit in kleine, review‑freundliche Commits

Große Änderungen verstecken Bugs. Kleine Commits machen Reviews schneller, Rollbacks sicherer und helfen dir zu bemerken, wenn du vom Akzeptanzkriterium abweichst.

Eine nützliche Regel: Jeder Commit sollte genau ein neues Verhalten freischalten und eine schnelle Möglichkeit enthalten, es zu beweisen.

Eine übliche Reihenfolge sieht so aus:

• Datenmodell oder Migration (falls nötig) plus Tests
• API‑Verhalten und Validierung
• UI‑Wiring mit Leer‑ und Fehlerzuständen
• Logging oder Analytics nur falls erforderlich, dann kleines Feintuning

Halte jeden Commit fokussiert. Vermeide „bin gerade dabei“-Refactors. Sorge dafür, dass die App Ende-zu-Ende funktioniert, auch wenn die UI einfach ist. Packe Migrationen, Verhalten und UI nicht in einen Commit, außer es gibt einen guten Grund.

Durchgang: „Berichte exportieren“

Ein Stakeholder sagt: „Können wir Export‑Reports hinzufügen?“ Das verbirgt viele Entscheidungen: welcher Bericht, welches Format, wer darf exportieren und wie wird geliefert.

Stelle nur die Fragen, die das Design ändern:

• Welche Berichtstypen sind für v1 relevant?
• Welches Format ist für v1 nötig (CSV, PDF)?
• Wer darf exportieren (Admins, bestimmte Rollen)?
• Direktdownload oder per E‑Mail?
• Limits (max. Datumsbereich, Zeilenlimit, Timeouts)?

Nimm an, die Antworten sind: „Sales Summary, nur CSV, Manager‑Rolle, Direktdownload, max. 90 Tage.“ Dann wird das v1‑Akzeptanzkriterium konkret: Manager können auf Export auf der Sales‑Summary‑Seite klicken; das CSV entspricht den sichtbaren Tabellenspalten; der Export respektiert aktuelle Filter; bei mehr als 90 Tagen zeigt der Server einen klaren Fehler; der Download schließt innerhalb von 30 Sekunden für bis zu 50k Zeilen ab.

Minimaler UI‑Plan: ein Export‑Button bei den Tabellenaktionen, ein Ladezustand während der Generierung und eine Fehlermeldung, die dem Nutzer erklärt, wie er das Problem behebt (z. B. „Wähle 90 Tage oder weniger“).

Minimaler API‑Plan: ein Endpoint, der Filter entgegennimmt und ein generiertes CSV als Dateiantwort zurückgibt, wobei dieselbe Query wie die Tabelle wiederverwendet und die 90‑Tage‑Regel serverseitig durchgesetzt wird.

Dann lieferst du es in wenigen kompakten Commits: erst der Endpoint für den festen Happy Path, dann UI‑Wiring, dann Validierung und benutzerseitige Fehlermeldungen, zuletzt Tests und Dokumentation.

Häufige Scoping‑Fehler (und wie du sie vermeidest)

Versteckte Anforderungen schleichen sich ein

Anfragen wie „Teamrollen hinzufügen“ verbergen oft Regeln zu Einladungen, Bearbeitung und was mit bestehenden Nutzern passiert. Wenn du beim Raten erwischt wirst, notiere die Annahme und mache daraus eine Frage oder eine explizite Regel.

UI‑Polish wird mit Kernverhalten vermischt

Teams verlieren Tage, wenn eine Aufgabe sowohl „funktionieren“ als auch „schick aussehen“ beinhaltet. Konzentriere die erste Aufgabe auf Verhalten und Daten. Styling, Animationen und Abstände kommen in einem Folge-Task, sofern sie nicht nötig sind, um das Feature zu nutzen.

Du versuchst, alle Edge‑Cases in v1 zu lösen

Edge‑Cases sind wichtig, aber nicht alle müssen sofort gelöst werden. Behandle die, die Vertrauen brechen (Doppelte Submits, Konflikte), und verschiebe den Rest mit klaren Notizen.

Fehlerzustände und Berechtigungen werden auf „später“ verschoben

Wenn du sie nicht aufschreibst, vergisst du sie. Nimm mindestens einen unhappy path und mindestens eine Berechtigungsregel in die Akzeptanzkriterien auf.

Kriterien, die du nicht verifizieren kannst

Vermeide Begriffe wie „schnell“ oder „intuitiv“, es sei denn, du hängst eine Zahl oder eine konkrete Überprüfung dran. Ersetze sie durch etwas, das du im Review nachweisen kannst.

Kurze Checkliste bevor du zu coden beginnst

Fixiere die Aufgabe so, dass ein Kollege ohne Gedankenlesen reviewen und testen kann:

• Ergebnis und Non-Goals: ein Satz für das Ergebnis plus 1–3 explizite Non-Goals.
• Akzeptanzkriterien: 5–10 prüfbare Checks in klarer Sprache.
• UI‑Zustände: minimale Laden-, Leer-, Fehler- und Erfolgszustände.
• API‑ und Datenhinweise: kleinstmögliche Endpoint‑Form und Datenänderungen sowie wer lesen/schreiben darf.
• Commit‑Plan mit Tests: 3–7 Commits, jeder mit einem schnellen Beweis.

Beispiel: „Saved Searches hinzufügen“ wird zu „Nutzer können einen Filter speichern und später wieder anwenden“, mit Non-Goals wie „kein Teilen“ und „keine Sortieränderungen".

Nächste Schritte: Scope während des Baus stabil halten

Wenn du einen abgegrenzten Task hast, schütze ihn. Vor dem Coden mache ein kurzes Sanity‑Review mit den Fragestellern:

• Lies die Akzeptanzkriterien und bestätige, dass sie das gewünschte Ergebnis abbilden.
• Bestätige Berechtigungen, Leerzustände und Fehlverhalten.
• Bestätige, was außer Scope ist.
• Vereinbare die kleinstmöglichen UI‑ und API‑Änderungen, die die Kriterien erfüllen.
• Entscheide, wie du es demoen willst und was „done“ bedeutet.

Speichere die Kriterien dort, wo gearbeitet wird: im Ticket, in der PR‑Beschreibung und überall, wo dein Team wirklich hinsieht.

Wenn du in Koder.ai (koder.ai) baust, hilft es, zuerst den Plan zu sperren und dann Code daraus zu generieren. Der Planning Mode passt gut zu diesem Workflow, und Snapshots sowie Rollback können Experimente sichern, wenn du einen Ansatz testen und wieder zurücknehmen musst.

Wenn während der Arbeit neue Ideen auftauchen, halte den Scope stabil: schreibe sie in eine Nachfolge‑Liste, pausiere und re‑scope, wenn sie die Akzeptanzkriterien verändern, und halte Commits an ein Kriterium gebunden.