Przepływ PRD → Plan → Todo

Przekształć wymagania produktowe w gotowy do produkcji kod, używając potężnego przepływu planowania i wykonania Claude Code. Ten przewodnik uczy sprawdzonej w boju metodologii używanej przez zespoły inżynieryjne Anthropic do systematycznego i niezawodnego budowania funkcji.

Notatka

Aby uzyskać kompleksowy, głęboki przegląd tej metodologii, w tym zaawansowane wzorce i strategie współpracy w przedsiębiorstwie, zobacz nasz Kompletny przewodnik PRD→Plan→Todo.

Podstawowa metodologia

Dlaczego PRD → Plan → Todo działa

Ten przepływ przekształca chaotyczny rozwój w przewidywalny proces:

1. PRD (dokument wymagań produktowych) - określ, co budować
2. Plan - pozwól Claude przemyśleć, jak to zbudować
3. Todo - wykonaj plan krok po kroku
4. Iteruj - dopracuj na podstawie opinii

Rezultat? Złożone funkcje zbudowane dobrze za pierwszym razem, z jasną możliwością śledzenia od wymagań do kodu.

Rozpoczynanie od wymagań

Tworzenie skutecznych PRD

Jakość twojego wyniku zależy od jasności twojego wkładu. Oto jak strukturyzować wymagania dla Claude:

Podstawowy szablon PRD

# Funkcja: System listy życzeń użytkownika

## Przegląd
Użytkownicy potrzebują zapisywać produkty na później i dzielić się kolekcjami z przyjaciółmi.

## Historie użytkownika
- Jako użytkownik chcę tworzyć wiele list życzeń
- Jako użytkownik chcę dodawać/usuwać produkty z list życzeń
- Jako użytkownik chcę dzielić się listami życzeń przez publiczny link
- Jako odwiedzający chcę przeglądać udostępnione listy życzeń (tylko do odczytu)

## Wymagania techniczne
- Maks. 50 elementów na listę życzeń
- Maks. 10 list życzeń na użytkownika
- Publiczne linki wygasają po 90 dniach
- Śledzenie liczby wyświetleń dla analityki

## Kryteria akceptacji
- [ ] Użytkownicy mogą tworzyć, odczytywać, aktualizować i usuwać listy życzeń
- [ ] Produkty mogą być dodawane/usuwane
- [ ] Linki udostępniania działają bez uwierzytelniania
- [ ] Śledzenie wyświetleń zaimplementowane

Szczegółowy przykład PRD

# PRD: Zaawansowana funkcja wyszukiwania

## Sformułowanie problemu
Użytkownicy mają problem ze znalezieniem konkretnej treści w naszej bibliotece 100k+ dokumentów.
Obecne wyszukiwanie zwraca nieistotne wyniki i brakuje opcji filtrowania.

## Cele
- Poprawić trafność wyszukiwania o 50%
- Skrócić czas znalezienia z 5min do 30s
- Umożliwić zaawansowanym użytkownikom tworzenie złożonych zapytań

## Wymagania funkcjonalne

### Możliwości wyszukiwania
1. Wyszukiwanie pełnotekstowe z rdzeniowaniem
2. Dopasowanie rozmyte dla literówek
3. Operatory logiczne (AND, OR, NOT)
4. Wyszukiwanie fraz z cudzysłowami
5. Obsługa symboli wieloznacznych (*, ?)

### Opcje filtrowania
- Zakres dat (utworzono, zmodyfikowano)
- Typ dokumentu (PDF, DOC, MD)
- Autor/właściciel
- Tagi i kategorie
- Zakresy rozmiarów plików

### Wymagania UI
- Wyszukiwanie podczas pisania z debouncing
- Fragmenty podglądu wyników
- Pasek boczny z filtrami aspektowymi
- Historia wyszukiwania (ostatnie 10)
- Zapisane wyszukiwania dla użytkowników

## Wymagania niefunkcjonalne
- Czas odpowiedzi < 200ms dla 95. percentyla
- Obsługa 1000 równoczesnych wyszukiwań
- Responsywny design mobilny
- Dostępność (WCAG 2.1 AA)
- Działanie offline dla wyników z cache

## Ograniczenia techniczne
- Użyj istniejącego klastra Elasticsearch
- Integracja z obecnym systemem uwierzytelniania
- Zachowanie kompatybilności wstecznej
- Budżet: 2 tygodnie-inżynier

## Metryki sukcesu
- Wskaźnik sukcesu wyszukiwania > 80%
- Średnio kliknięte wyniki w top 3
- Ocena satysfakcji użytkowników > 4.5/5

Format PRD dla API

# Ulepszenie API: Operacje zbiorcze

## Wymagane endpointy

### POST /api/v2/products/bulk
- Akceptuje tablicę obiektów produktów (maks. 100)
- Walidacja wszystkich przed przetwarzaniem jakichkolwiek
- Zwraca szczegółową tablicę błędów
- Obsługa trybu częściowego sukcesu

### PUT /api/v2/products/bulk
- Aktualizacja wielu produktów według ID
- Obsługa aktualizacji na poziomie pól
- Zachowanie ścieżki audytu
- Limit częstotliwości: 10 żądań/minutę

### DELETE /api/v2/products/bulk
- Miękkie usuwanie domyślnie
- Wymaga dodatkowego nagłówka potwierdzenia
- Zwraca liczbę usuniętych
- Logowanie wszystkich usunięć

## Formaty żądania/odpowiedzi

// Żądanie
{
  "products": [...],
  "options": {
    "validate_only": false,
    "partial_success": true
  }
}

// Odpowiedź
{
  "success": 85,
  "failed": 15,
  "errors": [
    {
      "index": 2,
      "code": "INVALID_SKU",
      "message": "SKU już istnieje"
    }
  ]
}

## Obsługa błędów
- Błędy walidacji: 400
- Błędy uwierzytelniania: 401/403
- Limit częstotliwości: 429
- Błędy serwera: 500

Przekazywanie PRD do Claude

Gdy masz już PRD, oto jak skutecznie go przekazać Claude:

1. Zacznij od kontekstu

   > Musimy zaimplementować nową funkcję. Oto PRD:
   [wklej treść PRD]
   Na podstawie naszego stosu technologicznego (Next.js 15, Postgres, uwierzytelnianie Clerk),
   przeanalizuj to i zidentyfikuj wszelkie pytania lub obawy.

2. Pozwól Claude zadać pytania wyjaśniające

   Claude: Mam kilka pytań dotyczących funkcji listy życzeń:
   1. Czy nazwy list życzeń powinny być unikalne dla użytkownika?
   2. Czy produkty mogą być w wielu listach życzeń?
   3. Co się dzieje gdy produkt zostanie usunięty?
   4. Czy powinniśmy śledzić, kto dodał każdy element?

3. Dopracuj wymagania razem

   > Dobre pytania! Pozwól mi wyjaśnić:
   1. Nie, użytkownicy mogą mieć duplikatowe nazwy
   2. Tak, produkty mogą być w wielu listach
   3. Zachowaj jako "niedostępny" z metadanymi
   4. Tak, śledź added_by i added_at

4. Potwierdź zrozumienie

   > Podsumuj swoje zrozumienie wymagań
   i wszelkie decyzje techniczne, które podjęliśmy.

Wskazówka

Zapisz dopracowane PRD w CLAUDE.md do przyszłego użytku:

# Kontekst funkcji: System listy życzeń (listopad 2024)
# Decyzje: Zachowaj usunięte produkty, pozwól na duplikaty
# Tech: Postgres JSONB dla metadanych, Redis dla liczby wyświetleń

Planowanie z głębokim rozumowaniem

Aktywowanie trybów myślenia Claude

Claude Code oferuje wiele poziomów myślenia dla różnych potrzeb złożoności:

Spektrum trybu myślenia

Wyzwalacz	Tokeny	Przypadek użycia
(domyślny)	~500	Proste zadania, jasna ścieżka
think	~5,000	Standardowe planowanie funkcji
think hard	~10,000	Złożone architektury
think harder	~20,000	Integracja wielu systemów
ultrathink	~128,000	Większe refaktoryzacje, migracje

Wybieraj na podstawie złożoności, nie ważności. Krytyczna poprawka błędu może potrzebować trybu domyślnego, podczas gdy nowy mikroserwis potrzebuje ultrathink.

Przepływ planowania

Standardowe planowanie

Dla typowych funkcji (tryb think):

> Na podstawie PRD listy życzeń, pomyśl o podejściu do implementacji.
Rozważ schemat bazy danych, design API i komponenty UI.

Odpowiedź Claude może zawierać:

Przemyślę to systematycznie...

## Schemat bazy danych
- tabela wishlists: id, user_id, name, created_at, is_public
- wishlist_items: id, wishlist_id, product_id, added_by, added_at
- wishlist_views: do śledzenia analityki

## Struktura API
- Endpointy REST pod /api/wishlists
- GraphQL może być lepszy dla zagnieżdżonych danych
- Potrzeba ograniczenia częstotliwości dla publicznych endpointów

## Fazy implementacji
1. Migracje bazy danych i modele
2. CRUD API z testami
3. Komponenty frontend
4. Mechanizm udostępniania
5. Integracja analityki

## Rozważania
- Indeks na user_id dla wydajności
- Redis dla liczby wyświetleń (unikaj zapisów do DB)
- UUID dla linków udostępniania (nie sekwencyjne ID)
- Miękkie usuwanie dla odzyskiwania danych

Złożone planowanie

Dla decyzji architektonicznych (tryb ultrathink):

> Migrujemy z REST do GraphQL w 50+ endpointach obsługujących
> 1M+ dziennych użytkowników. Ultrathink o strategii migracji,
> włączając wdrożenie bez przestojów, stopniowe wprowadzanie i plany wycofania.

To wyzwala rozszerzone rozumowanie, gdzie Claude będzie:

• Analizować istniejące wzorce API
• Projektować architekturę równoległego uruchamiania
• Tworzyć szczegółowe fazy migracji
• Planować monitorowanie i wyzwalacze wycofania
• Rozważać przypadki brzegowe i tryby awarii
• Proponować strategie testowania

Iteracyjne planowanie

Buduj plany przez rozmowę:

> Zaplanujmy refaktoryzację uwierzytelniania. Zacznij od analizy
> naszej obecnej implementacji JWT.

[Claude analizuje]

> Dobra analiza. Teraz pomyśl o migracji do Clerk przy
> zachowaniu kompatybilności wstecznej.

[Claude rozszerza plan]

> A co z migracją sesji dla zalogowanych użytkowników?

[Claude dalej dopracowuje]

To podejście pomaga ci kierować myśleniem Claude we właściwym kierunku.

Ocena planów

Przed przejściem do implementacji, zwaliduj plan Claude:

1. Sprawdź kompletność

   • Czy adresuje wszystkie wymagania PRD?
   • Czy przypadki brzegowe są rozważone?
   • Czy obsługa błędów jest określona?

2. Oceń wykonalność

   • Czy szacunki czasu są realistyczne?
   • Czy mamy wymagane zależności?
   • Jakieś blokujące ograniczenia techniczne?

3. Przejrzyj dopasowanie architektury

   • Zgodne z istniejącymi wzorcami?
   • Zachowuje granice systemu?
   • Zgodne z konwencjami zespołu?

4. Rozważ alternatywy

   > Jakie alternatywne podejścia rozważałeś?
   > Dlaczego wybrałeś to?

Konwersja planów na listy zadań

Podejście listy zadań

Claude Code doskonale radzi sobie z dzieleniem planów na wykonalne zadania. To systematyczne podejście zapewnia, że nic nie wpadnie między krzesło a stół:

## Zadania implementacji funkcji listy życzeń

### Faza 1: Konfiguracja bazy danych ✅
- [x] Stwórz migrację dla tabeli wishlists
- [x] Stwórz migrację dla tabeli wishlist_items
- [x] Dodaj indeksy dla wydajności
- [x] Stwórz modele Prisma
- [x] Zasiej dane testowe

### Faza 2: Backend API (w trakcie)
- [x] POST /api/wishlists - Stwórz listę życzeń
- [x] GET /api/wishlists - Wylistuj listy życzeń użytkownika
- [ ] GET /api/wishlists/:id - Pobierz pojedynczą listę życzeń
- [ ] PUT /api/wishlists/:id - Zaktualizuj listę życzeń
- [ ] DELETE /api/wishlists/:id - Usuń listę życzeń
- [ ] POST /api/wishlists/:id/items - Dodaj element
- [ ] DELETE /api/wishlists/:id/items/:itemId - Usuń element
- [ ] GET /api/wishlists/shared/:shareId - Widok publiczny

### Faza 3: Komponenty frontend
- [ ] Komponent WishlistCard
- [ ] Layout WishlistGrid
- [ ] Przycisk AddToWishlist
- [ ] Modal ShareWishlist
- [ ] Strona WishlistManager

### Faza 4: Testowanie i dopracowanie
- [ ] Testy integracji API
- [ ] Testy jednostkowe komponentów
- [ ] Scenariusze testów E2E
- [ ] Optymalizacja wydajności
- [ ] Aktualizacja dokumentacji

Praca z listami zadań

Pozwól Claude prowadzić

Najskuteczniejsze dla standardowych funkcji:

> Zaimplementuj funkcję listy życzeń na podstawie naszego planu.
> Pracuj przez zadania systematycznie, testując każdą fazę
> przed przejściem do następnej.

[Claude zaczyna od Fazy 1, tworzy migracje, uruchamia je,
potwierdza sukces, następnie przechodzi do Fazy 2...]

Claude będzie:

• Wykonywać zadania w kolejności
• Uruchamiać testy po każdym kroku
• Prosić o potwierdzenie na granicach faz
• Aktualizować listę zadań w miarę postępów

Interaktywne wykonanie

Lepsze dla złożonych lub wrażliwych zmian:

> Zaimplementujmy Fazę 1 funkcji listy życzeń.
> Pokaż mi migracje przed ich uruchomieniem.

[Claude pokazuje pliki migracji]

> Dobrze, uruchom migracje i stwórz modele.

[Claude wykonuje]

> Teraz zacznijmy od API. Rozpocznij od endpointu tworzenia.

[Claude implementuje POST /api/wishlists]

> Dodaj walidację dla pola name - maks. 50 znaków.

[Claude aktualizuje z walidacją]

Zadania równoległe

Użyj narzędzia zadań Claude dla niezależnych elementów:

> Te endpointy API są niezależne. Użyj podagentów do
> zaimplementowania ich równolegle:
> - GET /api/wishlists
> - POST /api/wishlists
> - DELETE /api/wishlists/:id

Claude uruchomi wielu agentów do jednoczesnej pracy.

Śledzenie postępów

Claude może prowadzić dziennik postępów podczas pracy:

# Postęp implementacji listy życzeń

## Ukończone dzisiaj
- ✅ Schemat bazy danych stworzony i zmigrowany
- ✅ Modele Prisma wygenerowane
- ✅ Podstawowe CRUD API (6/8 endpointów)
- ✅ Middleware walidacji wejścia
- ✅ Ograniczenie częstotliwości dodane

## Obecnie pracuję nad
- 🔄 Logika generowania linków udostępniania
- 🔄 Autoryzacja widoku publicznego

## Blokady
- ❌ Redis nie skonfigurowany dla liczby wyświetleń
  - Rozwiązanie: Użyj DB na razie, migruj później

## Następne kroki
- Dokończ pozostałe endpointy API
- Rozpocznij komponenty frontend
- Dodaj kompleksowe testy

## Notatki
- Zdecydowano użyć UUID dla linków udostępniania
- Dodano miękkie usuwanie dla odzyskiwania
- Limit częstotliwości: 100 żądań/minutę dla publicznych endpointów

Wskazówka

Poproś Claude o aktualizację progress.md po każdej sesji pracy. To pomaga z przekazywaniem i zapewnia jasną ścieżkę audytu decyzji i zmian.

Iterowanie implementacji

Obsługa opinii

Gdy przeglądasz pracę Claude, przekazuj opinię skutecznie:

1. Bądź konkretny w kwestii problemów

   ❌ "API nie działa dobrze"
   ✅ "API zwraca 500 gdy nazwa listy życzeń jest pusta.
       Dodaj walidację by zwracać 400 z jasną wiadomością błędu."

2. Podawaj przykłady

   > Link udostępniania powinien wyglądać jak: myapp.com/wishlist/share/abc123
   > Nie: myapp.com/api/wishlists/123/public

3. Odwołuj się do najlepszych praktyk

   > Postępuj zgodnie z naszym formatem błędów API z CLAUDE.md:
   > { error: { code: "VALIDATION_ERROR", message: "..." } }

4. Iteruj szybko

   > Napraw problem z walidacją, następnie kontynuuj z następnym endpointem.
   > Nie refaktoryzuj jeszcze wszystkiego.

Powszechne wzorce iteracji

Poprawki oparte na testach

> Tworzenie listy życzeń nie działa. Napisz najpierw test, który nie przejdzie
> i odtworzy problem.

[Claude pisze test]

> Teraz napraw implementację by test przeszedł.

[Claude naprawia kod]

> Dodaj testy przypadków brzegowych dla pustych nazw i znaków specjalnych.

Stopniowe ulepszanie

> Podstawowa funkcja działa. Teraz dodaj:
> 1. Optymistyczne aktualizacje UI
> 2. Stany ładowania
> 3. Granice błędów
> 4. Logika ponowienia

> Implementuj po jednym by mogliśmy testować każde.

Optymalizacja wydajności

> Strona listy życzeń ładuje się wolno z 50 elementami.
> Zprofiluj to i zidentyfikuj wąskie gardła.

[Claude analizuje]

> Zaimplementuj top 3 optymalizacje i zmierz wpływ.

[Claude optymalizuje i raportuje metryki]

Przykład z rzeczywistego świata

Kompletny przepływ funkcji

Oto jak starszy programista używa przepływu PRD → Plan → Todo:

> Muszę zaimplementować system powiadomień. Oto PRD:
> [wkleja 200-liniowy PRD o powiadomieniach email/push/w aplikacji]

Claude: Przeanalizuję ten PRD. Zauważam, że wymienia trzy kanały powiadomień
ale nie określa priorytetu. Czy wszystkie trzy powinny być zaimplementowane
razem czy możemy je wprowadzać fazami?

> Zróbmy to fazami: najpierw email, potem w aplikacji, push na końcu.

> Na tej podstawie, pomyśl mocno o podejściu do implementacji.
> Rozważ skalowalność dla 100k dziennych powiadomień.

Claude: [Rozszerzone myślenie o architekturze, systemach kolejek,
śledzeniu dostarczania, zarządzaniu szablonami, preferencjach użytkowników...]

Oto mój plan implementacji:
1. Kolejka wiadomości z Redis/BullMQ dla niezawodności
2. System szablonów używający Handlebars
3. Abstrakcja dostawcy dla łatwego przełączania
4. Śledzenie statusu dostarczania w Postgres
5. Preferencje użytkowników z rezygnacją na poziomie kanału

> Doskonały plan. Stwórz szczegółową listę zadań dla fazy 1 (tylko email).

Claude: [Generuje listę 25 zadań zorganizowaną według komponentu]

> Zacznijmy. Przepracuj najpierw zadania infrastruktury.

[Claude implementuje konfigurację Redis, konfigurację kolejki, proces worker...]

> Kolejka przetwarza za wolno. Potrzebujemy przepustowości 10k/godzinę.

Claude: Dodam równoczesnych workerów. Obecnie jednowątkowe...
[Aktualizuje by używać 5 równoczesnych workerów, dodaje wsadowanie]

> Znacznie lepiej. Kontynuuj z szablonami email.

[Sesja trwa 2 godziny, funkcja jest wdrażana tego samego dnia]

Najlepsze praktyki

Czynniki sukcesu PRD → Plan → Todo

RÓB:

• Zacznij od jasnych, szczegółowych wymagań
• Pozwól Claude myśleć przed implementacją
• Dziel pracę na weryfikowalne części
• Testuj każdą fazę przed kontynuacją
• Prowadź dzienniki postępów dla złożonych funkcji
• Iteruj na podstawie konkretnych opinii

NIE RÓB:

• Skacz od razu do kodowania
• Dawaj niejasne wymagania
• Próbuj budować wszystko naraz
• Pomijaj fazę planowania
• Ignoruj pytania wyjaśniające Claude
• Refaktoryzuj podczas implementacji

Wskazówki od zaawansowanych użytkowników

1. “Myśl o Claude jak o młodszym architekcie” - Może tworzyć solidne plany, ale potrzebuje twojej ekspertyzy do walidacji decyzji architektonicznych.

2. “Wymagania to prompty” - Im jaśniejszy twój PRD, tym lepszy wynik Claude. Zainwestuj czas z góry.

3. “Plany to żywe dokumenty” - Aktualizuj je w miarę uczenia się. Claude może rewidować plany na podstawie odkryć implementacyjnych.

4. “Listy zadań zapobiegają dryfowi” - Utrzymują Claude skupionego i zapobiegają nadmiernej inżynierii lub zbaczaniu z kursu.

5. “Granice faz mają znaczenie” - Ukończ i przetestuj każdą fazę. To zapewnia naturalne punkty kontrolne do przeglądu.

Następne kroki

Teraz gdy rozumiesz przepływ PRD → Plan → Todo:

Głębokie rozumowanie Opanuj tryby myślenia dla złożonych problemów

Konfiguracja MCP Zintegruj zewnętrzne narzędzia ze swoim przepływem

Przepływ testowania Buduj jakość od początku

Pamiętaj: Świetne oprogramowanie nie powstaje przypadkowo. Przepływ PRD → Plan → Todo zapewnia, że każda funkcja jest przemyślanie zaprojektowana, starannie zaimplementowana i dokładnie przetestowana. Opanuj tę metodologię i zobacz jak wzrasta twoja produktywność!