Claude Projects: Mehrere Entwicklungsaufgaben gezielt koordinieren

Die Projects-Beta vom 17. September einordnen

Die neue Projekterfahrung wurde zunächst ausgewählten Pro- und Max-Nutzern mit Cloud-Sessions in Claude Code und ohne bestehende Web- oder Desktopprojekte angeboten. Anthropic beschreibt eine schrittweise Erweiterung. Team und Enterprise folgen später. Bestehende Projekte behalten vorerst ihr bisheriges Verhalten. Eine allgemeine Verfügbarkeit für alle Teams lässt sich daraus nicht ableiten.

Prüfen Sie vor einer Einführung, ob das betreffende Konto tatsächlich die neue Koordination besitzt. Verwenden Sie für die Bewertung ein abgegrenztes Testprojekt. Löschen Sie keine produktiven Projekte, um eine Zugangsvoraussetzung nachzubauen. Die Einführung soll einen Arbeitsablauf verbessern und keine bestehenden Daten oder Routinen gefährden.

Ein gemeinsames Ziel braucht getrennte Abnahmekriterien

Als Beispiel soll eine interne Anwendung künftig dieselbe Kundennummer in API, Weboberfläche und Importskript verwenden. Beschreiben Sie zuerst den Endzustand: alte Daten bleiben lesbar, neue Eingaben werden eindeutig validiert und die Dokumentation zeigt die aktuelle Schnittstelle. Das ist präziser als „modernisiere das Projekt“.

Teilen Sie die Abnahme nach Arbeitsbereichen auf. Die API braucht Kompatibilitätstests, die Oberfläche einen nachvollziehbaren Fehlerzustand, das Importskript einen Probelauf ohne Änderungen an echten Daten. Die Koordination darf diese Einzelbelege zusammenführen. Sie sollte eine fehlende Prüfung in einem Teilbereich aber nicht durch erfolgreiche Ergebnisse in den anderen verdecken.

Parallele Aufgaben an echten Grenzen schneiden

Parallele Bearbeitung hilft, wenn Aufgaben unabhängig vorbereitet werden können. Zwei Agenten sollten nicht gleichzeitig dieselbe zentrale Datei mit verschiedenen Annahmen umbauen. Legen Sie deshalb fest, wer den Schnittstellenvertrag beschreibt und welche Aufgaben erst nach dessen Prüfung beginnen. Für jede Arbeitslinie gibt es einen klaren Änderungsbereich.

Im Beispiel entsteht zuerst ein kurzer Vertrag zur Kundennummer mit gültigen und ungültigen Beispielen. Danach können Oberfläche und Import parallel angepasst werden. Jede Aufgabe nennt die verwendete Vertragsversion. Wenn sich diese ändert, müssen betroffene Tests erneut laufen. So bleibt Geschwindigkeit nachvollziehbar, statt später in schwer verständlichen Merge-Konflikten zu verschwinden.

Ein Koordinator ersetzt kein Code-Review

Die neue Projekterfahrung kann Aufgaben delegieren, Ergebnisse zusammenführen und den Fortschritt sichtbar machen. Die fachliche Abnahme bleibt eine gesonderte Aufgabe. Lassen Sie zu jeder Änderung Problem, Lösung, ausgeführte Tests und verbleibende Einschränkungen auflisten. „Tests bestanden“ ist zu ungenau, wenn nicht erkennbar ist, welche Tests auf welchem Stand liefen.

Prüfen Sie besonders Authentifizierung, Zahlungen, Löschungen und Migrationen. Für diese Bereiche sollten die Zuständigkeiten bereits im Team geregelt sein. Der Projektauftrag kann fertige Pull Requests verlangen; der Merge und eine Veröffentlichung folgen den üblichen Repository-Regeln. Ein großer Gesamtauftrag darf diese Regeln nicht stillschweigend aufheben.

Ein Koordinator braucht außerdem eine klare Regel für Konflikte zwischen Arbeitssträngen. Wenn eine Änderung eine Schnittstelle umbenennt und eine andere noch den alten Namen verwendet, müssen beide Ergebnisse zusammen geprüft werden. Lassen Sie den abschließenden Bericht deshalb die betroffenen Schnittstellen, gemeinsam ausgeführten Tests und verbliebene Unsicherheiten nennen. Einzeln erfolgreiche Teilaufgaben beweisen nicht, dass das Gesamtergebnis integrierbar ist. Der fachliche Owner entscheidet über die Abnahme anhand des zusammengeführten Zustands. Dies wird im Review-Protokoll nachvollziehbar festgehalten.

Den Nutzen über einen vollständigen Änderungszyklus messen

Wählen Sie einen kleinen, bereits verstandenen Wartungsauftrag. Erfassen Sie aktive Review-Zeit, Nachfragen, Konflikte, fehlgeschlagene Tests und die Zeit bis zum zusammengeführten Ergebnis. Viele parallele Aufgaben sehen produktiv aus; entscheidend ist, ob das Team tatsächlich weniger Koordinationsarbeit hat und die Änderung nachvollziehen kann.

Beenden Sie den Versuch mit einer Übergabe, die auch ein unbeteiligter Entwickler versteht: Welche Änderungen gehören zusammen, in welcher Reihenfolge werden sie übernommen und wie sieht der Rückweg aus? Falls der Koordinator diese Übersicht nicht zuverlässig liefert, verkleinern Sie das Projekt. Zusätzliche Agenten allein beheben keinen unklaren Schnittstellenvertrag.

Fragen zur neuen Projektkoordination

Ist das dieselbe Funktion wie ein bisheriger Claude-Projektordner? Nein. Die Ankündigung beschreibt eine neue Koordination über Aufgaben hinweg und einen begrenzten Rollout. Bestehende Projektfunktionen werden nicht pauschal ersetzt.

Sollten alle Tickets gleichzeitig gestartet werden? Nur unabhängig bearbeitbare Aufgaben eignen sich für parallele Arbeit. Was kostet das Projekt? Dieser Ratgeber nennt keinen pauschalen Projektpreis. Prüfen Sie Kontoverbrauch und Review-Aufwand am tatsächlichen Auftrag. Die dargestellte Migration ist ein vorgeschlagener Testfall, kein veröffentlichter Kundenbeleg.