Metodologia PRD→Plan→Todo

Metodologia PRD→Plan→Todo to systematyczne podejście do rozwoju wspomaganego przez AI, które przekształca wysokopoziomowe wymagania w działający kod przez trzy różne fazy. Ten przepływ pracy stał się złotym standardem dla zespołów używających Claude Code i Cursor.

Trzy filary

1. PRD (dokument wymagań produktu): co trzeba zbudować
2. Plan: jak to zbudować (podejście techniczne)
3. Todo: konkretne zadania implementacyjne

Dlaczego ta metodologia działa

Tradycyjny rozwój często przeskakuje bezpośrednio z wymagań do kodu, prowadząc do:

• Niepasujących implementacji
• Zapomnianych przypadków brzegowych
• Długu technicznego z powodu słabego planowania
• Trudnych przeglądów kodu

Podejście PRD→Plan→Todo zapewnia:

• ✅ Jasne dopasowanie między potrzebami biznesowymi a implementacją techniczną
• ✅ Kompleksowe pokrycie wszystkich wymagań
• ✅ Systematyczne podejście, którym AI może konsekwentnie kierować się
• ✅ Wbudowaną dokumentację dla przyszłego utrzymania

Faza 1: PRD (dokument wymagań produktu)

PRD definiuje co należy zbudować z perspektywy biznesowej.

Tworzenie skutecznych PRD

Struktura

# Funkcja: system uwierzytelnienia użytkownika

## Przegląd
Krótki opis funkcji i jej wartości biznesowej

## Historie użytkowników
Jako [typ użytkownika], chcę [akcja], aby [korzyść]

## Wymagania funkcjonalne
1. Użytkownicy mogą się rejestrować email/hasło
2. Wymagana weryfikacja emaila
3. Funkcjonalność resetowania hasła
4. Opcja "zapamiętaj mnie"

## Wymagania niefunkcjonalne
- Czas odpowiedzi < 200ms
- Obsługa 10k równoczesnych użytkowników
- Zgodność z GDPR
- Dostępność WCAG 2.1 AA

## Kryteria akceptacji
- [ ] Użytkownik może się pomyślnie zarejestrować
- [ ] Nieprawidłowe emaile są odrzucane
- [ ] Hasła spełniają wymagania bezpieczeństwa
- [ ] Sesja utrzymuje się z "zapamiętaj mnie"

## Poza zakresem
- Logowanie społecznościowe (Faza 2)
- Uwierzytelnienie dwuskładnikowe (Faza 2)

Prompt AI

"Wygeneruj PRD dla [opis funkcji], który zawiera:
- Przegląd i wartość biznesową
- Historie użytkowników dla wszystkich typów użytkowników
- Wymagania funkcjonalne (numerowana lista)
- Wymagania niefunkcjonalne (wydajność, bezpieczeństwo, zgodność)
- Kryteria akceptacji (testowalne warunki)
- Wyraźnie określ, co jest poza zakresem
- Uwzględnij wymagania UI/UX
- Zanotuj punkty integracji z istniejącymi systemami"

Najlepsze praktyki

• Bądź konkretny: “Użytkownik widzi komunikat błędu” → “Użytkownik widzi komunikat ‘Email już istnieje’ na czerwono pod polem email”
• Dołączaj przykłady: Pokaż przykładowe dane wejściowe/wyjściowe
• Zdefiniuj przypadki brzegowe: Co się dzieje, gdy coś pójdzie nie tak?
• Ustaw mierzalne kryteria: Użyj liczb dla wymagań wydajności
• Rozważ wszystkich użytkowników: Uwzględnij adminów, zwykłych użytkowników, gości
• Kontrola wersji: Śledź zmiany PRD w czasie

Przykład rzeczywistego PRD

Funkcja kasy e-commerce

# PRD: funkcja szybkiej kasy

## Przegląd
Zaimplementuj kasę jednym kliknięciem dla powracających klientów, aby zmniejszyć porzucanie koszyka o 25%

## Historie użytkowników
1. Jako powracający klient, chcę dokończyć zakup jednym kliknięciem
2. Jako nowy klient, chcę mieć opcję zapisania moich danych na przyszłość
3. Jako admin, chcę śledzić użycie szybkiej kasy

## Wymagania funkcjonalne
1. Przechowuj zaszyfrowane metody płatności (zgodnie z PCI)
2. Wypełnij adres wysyłki z ostatniego zamówienia
3. Pokaż podsumowanie zamówienia przed potwierdzeniem
4. Wyślij paragon email natychmiast
5. Aktualizuj zapasy w czasie rzeczywistym

## Wymagania wydajności
- Dokończenie kasy < 3 sekundy
- Obsługa 1000 równoczesnych kas
- 99.9% dostępności w godzinach biznesowych

Faza 2: plan techniczny

Plan przekłada wymagania biznesowe na architekturę techniczną i podejście.

Tworzenie kompleksowych planów

1. Analizuj PRD

   "Na podstawie tego PRD, stwórz plan techniczny, który zawiera:
   - Przegląd architektury wysokopoziomowej
   - Wybory technologiczne z uzasadnieniem
   - Projekt modelu danych
   - Potrzebne endpointy API
   - Rozważania bezpieczeństwa
   - Punkty integracji
   - Strategia wdrożenia"

2. Zdefiniuj komponenty

   "Podziel architekturę na:
   - Potrzebne komponenty/strony frontend
   - Usługi/moduły backend
   - Zmiany schematu bazy danych
   - Integracje zewnętrznych usług
   - Wymagania infrastrukturalne"

3. Zidentyfikuj ryzyka

   "Jakie są ryzyka techniczne i jak je łagodzimy?
   Rozważ: wąskie gardła wydajności, luki bezpieczeństwa,
   problemy skalowalności, zależności zewnętrzne"

Szablon planu

Plan backend

# Plan techniczny: uwierzytelnienie użytkownika

## Przegląd architektury
- Uwierzytelnienie bezstanowe oparte na JWT
- PostgreSQL dla danych użytkownika
- Redis do zarządzania sesjami
- Usługa email do powiadomień

## Projekt API
POST /api/auth/register
POST /api/auth/login
POST /api/auth/logout
POST /api/auth/refresh
POST /api/auth/reset-password

## Schemat bazy danych
users:
- id (uuid, klucz główny)
- email (unikalny, indeksowany)
- password_hash
- email_verified (boolean)
- created_at, updated_at

sessions:
- token (klucz główny)
- user_id (klucz obcy)
- expires_at
- ip_address

## Środki bezpieczeństwa
- Bcrypt do hashowania haseł (12 rund)
- Ograniczanie częstotliwości na endpointach auth
- Prawidłowo skonfigurowany CORS
- Walidacja wejść na wszystkich polach

Plan frontend

# Plan techniczny frontend

## Architektura komponentów
- AuthProvider (kontekst dla stanu auth)
- Komponent LoginForm
- Komponent RegisterForm
- PasswordResetFlow
- AuthGuard HOC dla chronionego routingu

## Zarządzanie stanem
- Hook useAuth do operacji auth
- Local storage do trwałości tokenów
- Session storage do tymczasowych danych

## Przepływ UI/UX
1. Formularze auth oparte na modalu
2. Walidacja w czasie rzeczywistym
3. Stany ładowania podczas wywołań API
4. Powiadomienia sukcesu/błędu
5. Przekierowanie po logowaniu

## Wydajność
- Lazy load komponentów auth
- Prefetch sprawdzenia auth przy ładowaniu aplikacji
- Optymistyczne aktualizacje UI

Faza 3: lista todo (zadania implementacyjne)

Lista todo dzieli plan na konkretne, wykonalne zadania, które można zaimplementować.

Generowanie skutecznych todo

Strategia podziału zadań

"Przekształć ten plan techniczny w szczegółową listę todo:
- Każde zadanie powinno być ukończone w 1-4 godziny
- Uwzględnij zależności zadań
- Grupuj według komponentu/obszaru funkcji
- Dodaj kryteria akceptacji dla każdego zadania
- Priorytetyzuj zadania (P0/P1/P2)
- Uwzględnij zadania testowe
- Nie zapomnij o dokumentacji"

Przykład listy todo

Format strukturalny

# Todo implementacji: uwierzytelnienie użytkownika

## Konfiguracja bazy danych (P0)
- [ ] Stwórz migracje bazy danych dla tabeli users
- [ ] Stwórz migracje bazy danych dla tabeli sessions
- [ ] Dodaj indeksy dla wyszukiwania email i token
- [ ] Zasiej bazę danych testowymi użytkownikami

## API backend (P0)
- [ ] Zaimplementuj narzędzie hashowania haseł
- [ ] Stwórz endpoint POST /api/auth/register
  - Walidacja wejść
  - Sprawdzenie unikalności email
  - Wyślij email weryfikacyjny
- [ ] Stwórz endpoint POST /api/auth/login
  - Waliduj dane uwierzytelnienia
  - Wygeneruj token JWT
  - Stwórz rekord sesji
- [ ] Dodaj middleware ograniczania częstotliwości
- [ ] Napisz testy integracji API

## Komponenty frontend (P1)
- [ ] Stwórz AuthContext i Provider
- [ ] Zaimplementuj hook useAuth
- [ ] Zbuduj komponent LoginForm
  - Walidacja formularza
  - Obsługa błędów
  - Stany ładowania
- [ ] Zbuduj komponent RegisterForm
- [ ] Dodaj AuthGuard HOC
- [ ] Napisz testy komponentów

## Integracja (P1)
- [ ] Połącz frontend z API backend
- [ ] Zaimplementuj logikę odświeżania tokenów
- [ ] Dodaj interceptory błędów
- [ ] Przetestuj pełny przepływ auth

## Dokumentacja (P2)
- [ ] Udokumentuj endpointy API
- [ ] Stwórz diagram przepływu auth
- [ ] Napisz przewodnik wdrożenia

Format przyjazny AI

## Todo: zaimplementuj rejestrację użytkownika

**Zadanie**: Stwórz endpoint rejestracji użytkownika
**Kryteria akceptacji**:
- Waliduje format email
- Sprawdza unikalność email
- Hashuje hasło z bcrypt
- Wysyła email weryfikacyjny
- Zwraca odpowiednie błędy

**Zależności**: migracje bazy danych ukończone
**Priorytet**: P0
**Szacowany czas**: 2 godziny

**Notatki implementacyjne**:
- Użyj Joi do walidacji
- Zwróć 409 dla duplikatu email
- Loguj próby rejestracji

Wykonywanie z pomocą AI

Używanie Claude Code

1. Zacznij od PRD

   # W katalogu projektu
   claude
   
   "Oto mój PRD dla systemu uwierzytelnienia użytkownika: [wklej PRD]
   Wygeneruj plan techniczny do implementacji tego."

2. Przejrzyj i udoskonalaj plan

   "Plan wygląda dobrze, ale użyjmy Passport.js zamiast
   niestandardowej implementacji JWT. Zaktualizuj plan odpowiednio."

3. Wygeneruj todo

   "Na podstawie tego planu, stwórz szczegółową listę todo pogrupowaną według:
   - Konfiguracja bazy danych
   - Implementacja backend
   - Komponenty frontend
   - Testowanie
   - Dokumentacja"

4. Implementuj systematycznie

   "Zacznijmy od konfiguracji bazy danych.
   Zaimplementuj pierwsze todo: Stwórz migrację tabeli user"

Używanie Cursor

Tryb Agent

// Użyj trybu Agent Cursor dla złożonych zadań wieloplikowych

"Mam ten PRD dla uwierzytelnienia użytkownika [wklej PRD].
Stwórz plan techniczny, następnie zaimplementuj schemat
bazy danych i podstawowe endpointy API. Przestrzegaj naszych
standardów kodowania w .cursorrules."

// Agent będzie:
// 1. Analizować PRD
// 2. Tworzyć plan
// 3. Generować migracje
// 4. Implementować endpointy
// 5. Dodawać podstawowe testy

Tryb Composer

// Użyj Composer do skoncentrowanych zadań

"Na podstawie tego elementu todo:
'Stwórz endpoint POST /api/auth/register z walidacją'

Zaimplementuj endpoint zgodnie z tymi wymaganiami:
- Walidacja email i hasła
- Sprawdź istniejącego użytkownika
- Hashuj hasło z bcrypt
- Wyślij email weryfikacyjny
- Zwróć obiekt użytkownika bez hasła"

Zaawansowane wzorce

Iteracyjne udoskonalanie

Pętla sprzężenia zwrotnego

graph LR A[PRD] --> B[Plan] B --> C[Todo] C --> D[Implementacja] D --> E[Testowanie] E --> F[Feedback] F --> A

Po implementacji, zaktualizuj swoje dokumenty:

• PRD: Dodaj odkryte wymagania
• Plan: Udokumentuj decyzje architektoniczne
• Todo: Oznacz ukończone, dodaj nowe zadania

Współpraca zespołowa

Współdzielone dokumenty

• Przechowuj PRD w /docs/requirements/
• Trzymaj plany w /docs/architecture/
• Śledź todo w /docs/tasks/ lub narzędziu zarządzania projektami

Dzielenie kontekstu AI

• Odwołuj się do dokumentów z @docs/requirements/auth-prd.md
• Uwzględniaj decyzje zespołowe w promptach
• Używaj konsekwentnej terminologii w zespole

Integracja z istniejącymi przepływami pracy

Agile/Scrum

• PRD: Tworzone podczas planowania sprintu
• Plan: Spotkanie technicznego udoskonalenia
• Todo: Staje się elementami backlogu sprintu
• Każde todo może być mapowane na story point

Kanban

• PRD: Wchodzi do backlogu po zatwierdzeniu
• Plan: Tworzony przy przenoszeniu do “Analiza”
• Todo: Pojedyncze karty na tablicy
• Przepływ: Backlog → Analiza → Dev → Przegląd → Gotowe

Waterfall

• PRD: Część fazy wymagań
• Plan: Wynik fazy projektowania
• Todo: Lista kontrolna fazy rozwoju
• Każda faza formalnie przeglądana

Typowe pułapki i rozwiązania

Uwaga

Pułapka: Pominięcie fazy planowania i przejście bezpośrednio z PRD do todo.

Rozwiązanie: Nawet dla małych funkcji, stwórz przynajmniej krótki plan techniczny. Pomaga to AI zrozumieć kontekst architektoniczny i zapobiega niespójnym implementacjom.

Lista kontrolna zapobiegania pułapkom

• PRD zbyt niejasne: Uwzględnij konkretne przykłady i przypadki brzegowe
• Plan bez ryzyk: Zawsze uwzględnij sekcję “Ryzyka i łagodzenie”
• Todo zbyt duże: Podziel każde zadanie powyżej 4 godzin
• Brak kryteriów akceptacji: Każde todo potrzebuje jasnej definicji ukończenia
• Ignorowanie zależności: Oznacz zależności zadań wyraźnie
• Brakujące testy: Uwzględnij zadania testowe dla każdego komponentu

Mierzenie sukcesu

Śledź te metryki, aby ulepszyć swój proces:

1. Wskaźnik ukończenia: % todo ukończonych jak pierwotnie napisane
2. Wskaźnik przeróbek: Jak często zaimplementowane funkcje wymagają zmian
3. Dokładność czasu: Rzeczywisty vs szacowany czas dla todo
4. Pokrycie wymagań: % wymagań PRD pomyślnie zaimplementowanych
5. Jakość dokumentacji: Kompletność dokumentacji po implementacji

Rzeczywiste studia przypadków

Migracja platformy e-commerce

Wyzwanie: Migracja monolitu PHP do mikrousług

Podejście:

1. Stworzono PRD dla każdej granicy usługi
2. Opracowano plan migracji ze strategiami rollback
3. Wygenerowano szczegółowe todo z flagami funkcji

Rezultat:

• 6-miesięczny projekt ukończony w 4 miesiące
• 90% mniej bugów niż poprzednie próby migracji
• Pełna dokumentacja wygenerowana wraz z kodem

Kluczowy czynnik sukcesu: Metodologia PRD→Plan→Todo zapewniła, że nic nie zostało zapomniane podczas złożonej migracji.

Narzędzia i szablony

Generator szablonów PRD

"Wygeneruj szablon PRD dla funkcji [typ], który zawiera:
- Wszystkie standardowe sekcje
- Wymagania specyficzne dla branży
- Rozważania zgodności
- Benchmarki wydajności
- Punkty dotykowe integracji"

Analizator planów

"Przejrzyj ten plan techniczny i zidentyfikuj:
- Brakujące komponenty architektoniczne
- Potencjalne problemy skalowalności
- Luki bezpieczeństwa
- Możliwości optymalizacji kosztów
- Ryzyka długu technicznego"

Priorytetyzator todo

"Weź tę listę todo i:
- Zidentyfikuj ścieżkę krytyczną
- Zasugeruj równoległe strumienie pracy
- Oszacuj czas ukończenia
- Podkreśl blokady
- Polecj kolejność zadań"

Następne kroki

Pobierz szablony

Pobierz nasze szablony PRD, Plan i Todo z przykładami dla typowych funkcji

Obejrzyj tutorial

Zobacz metodologię w akcji z rzeczywistą implementacją funkcji

Dołącz do społeczności

Podziel się swoimi doświadczeniami i ucz się od innych zespołów używających tego podejścia

Wskazówka

Wskazówka pro: Stwórz folder /docs w swoim projekcie z podkatalogami dla /requirements (PRD), /architecture (Plany) i /tasks (Todo). To ułatwia asystentom AI odwoływanie się do poprzednich decyzji i utrzymywanie spójności między funkcjami.