Przepływ pracy PRD

Przepływ pracy PRD → Plan → Todo to przełomowa metodologia która transformuje sposób podejścia do rozwoju funkcji. Ten 15-minutowy przewodnik nauczy cię rozbijać złożone wymagania na zarządzalne, wspomagane przez AI kroki implementacji.

Notatka

Dla kompleksowego głębokiego zanurzenia w tę metodologię, włączając zaawansowane wzorce i strategie współpracy zespołowej, zobacz nasz Kompletny przewodnik PRD→Plan→Todo.

Dlaczego PRD → Plan → Todo działa

Wskazówka

Tradycyjne podejście: skok prosto do kodowania, wymyślanie w trakcie

Podejście PRD: Zdefiniuj → Zaprojektuj → Rozłóż → Dostarcz

Moc rozwoju dokumentacja-najpierw

Jasność przed kodem

Pisanie wymagań zmusza do przemyślenia przypadków brzegowych przed implementacją

Zrozumienie AI

Jasne PRD pomagają AI generować lepszy kod dostarczając kompletny kontekst

Równoległa praca

Członkowie zespołu mogą rozpocząć różne części jednocześnie z jasnymi specyfikacjami

Mierzalny postęp

Listy todo dostarczają konkretne śledzenie postępu i zapobiegają rozszerzaniu zakresu

Faza 1: Dokument wymagań produktu (PRD)

Tworzenie skutecznych PRD

1. Zacznij od historii użytkownika

   # System uwierzytelniania użytkownika
   
   ## Historia użytkownika
   Jako użytkownik chcę bezpiecznie zalogować się do aplikacji
   żeby mieć dostęp do mojej personalizowanej treści i funkcji.

2. Zdefiniuj kryteria sukcesu

   ## Kryteria sukcesu
   - Użytkownicy mogą się rejestrować z email/hasłem
   - Wymagana weryfikacja email
   - Login trwa przez 30 dni
   - Resetowanie hasła przez email
   - Integracja OAuth (Google, GitHub)
   - Zarządzanie sesją na różnych urządzeniach

3. Określ wymagania techniczne

   ## Wymagania techniczne
   - Uwierzytelnianie oparte na JWT
   - Hashowanie haseł Bcrypt (12 rund)
   - Ograniczenia częstości na endpointach auth
   - Ochrona CSRF
   - Bezpieczna obsługa cookies
   - Logowanie audytu dla zdarzeń auth

4. Udokumentuj przypadki brzegowe

   ## Przypadki brzegowe
   - Jednoczesne próby logowania
   - Email już zarejestrowany
   - Obsługa błędnych tokenów
   - Blokada konta po nieudanych próbach
   - Awaria serwisu email
   - Uwierzytelnianie cross-origin

Szablon PRD

PRD funkcji

# Funkcja: [Nazwa]

## Przegląd
Krótki opis tego co budujemy i dlaczego.

## Historie użytkownika
- Jako [rola], chcę [funkcję] żeby [korzyść]
- Dodatkowe historie...

## Wymagania funkcjonalne
1. Podstawowa funkcjonalność
2. Interakcje użytkownika
3. Reguły biznesowe

## Wymagania niefunkcjonalne
- Wydajność: czas odpowiedzi < 200ms
- Bezpieczeństwo: zgodność OWASP
- Skalowalność: wsparcie 10k jednoczesnych użytkowników
- Dostępność: WCAG 2.1 AA

## Metryki sukcesu
- Wskaźnik adopcji użytkowników
- Benchmarki wydajności
- Wskaźniki błędów

## Poza zakresem
- Czego NIE budujemy
- Rozważania przyszłe

## Zależności
- Serwisy zewnętrzne
- Systemy wewnętrzne
- Biblioteki zewnętrzne

PRD API

# API: [Nazwa endpointu]

## Projekt endpointu
POST /api/v1/users/register
Content-Type: application/json

Żądanie:
{
  "email": "user@example.com",
  "password": "SecurePass123!",
  "name": "Jan Kowalski"
}

Odpowiedź (201):
{
  "id": "usr_123",
  "email": "user@example.com",
  "name": "Jan Kowalski",
  "emailVerified": false,
  "createdAt": "2024-01-01T00:00:00Z"
}

## Odpowiedzi błędów
- 400: Błędny input
- 409: Email już istnieje
- 429: Przekroczono limit częstości
- 500: Błąd serwera

## Zasady walidacji
- Email: ważny format, unikalny
- Hasło: 8+ znaków, zasady złożoności
- Nazwa: 2-50 znaków

## Ograniczenia częstości
- 5 żądań na minutę na IP
- 20 żądań na godzinę na email

PRD integracji

# Integracja: [Nazwa serwisu]

## Przegląd integracji
Łączenie naszego systemu z [Serwis] w celu [cel].

## Uwierzytelnianie
- Metoda: OAuth 2.0
- Zakresy: read:user, write:data
- Strategia odświeżania tokenów

## Przepływ danych
1. Użytkownik inicjuje akcję
2. System żąda tokenu
3. Wywołaj zewnętrzne API
4. Przetworz odpowiedź
5. Zaktualizuj stan lokalny

## Obsługa błędów
- Logika retry (3 próby)
- Zachowanie fallback
- Raportowanie błędów

## Mapowanie danych
| Ich pole | Nasze pole | Transformacja |
|----------|-----------|---------------|
| user_id | userId | Bezpośrednie |
| created_date | createdAt | ISO 8601 |

## Strategia testowania
- Mockowane odpowiedzi
- Testy integracyjne
- Testy obciążeniowe

Używanie AI do generowania PRD

1. Dostarczaj kontekst:

   "Pomóż mi stworzyć PRD dla systemu powiadomień użytkownika.
   Potrzebujemy powiadomień email, SMS i push z preferencjami użytkownika
   i śledzeniem dostawy."

2. Używaj @Docs do badań:

   @docs "Przejrzyj dokumentację naszego istniejącego systemu wiadomości
   i stwórz PRD które go rozszerza o preferencje powiadomień"

3. Iteruj z AI:

   "Dodaj wymagania ograniczeń częstości i webhooks zwrotne
   dla statusu dostawy do PRD"

Faza 2: Planowanie z AI

Transformuj PRD w plan techniczny

Przełącz na tryb Ask

Używaj trybu Ask do planowania - nie wprowadzi zmian, tylko pomoże ci przemyśleć implementację.

1. Analizuj wymagania:

   "Przejrzyj ten PRD i zidentyfikuj główne komponenty techniczne
   które musimy zbudować @notification-prd.md"

2. Projektowanie architektury:

   "Zaproponuj architekturę dla tego systemu powiadomień.
   Rozważ skalowalność, niezawodność i łatwość utrzymania."

3. Rozbij komponenty:

   "Rozbij to na konkretne serwisy/moduły:
   - Jaki schemat bazy danych potrzebujemy?
   - Jakie endpointy API?
   - Jakie zadania w tle?
   - Jakie komponenty frontend?"

4. Zidentyfikuj zależności:

   "Jakie są zależności i punkty integracji?
   Co powinniśmy zbudować jako pierwsze?"

Przykład outputu planowania

# System powiadomień - plan techniczny

## Przegląd architektury
- API Gateway → Serwis powiadomień
- Kolejka wiadomości (Redis/RabbitMQ)
- Procesy Worker do dostawy
- Webhooks statusu dostawy

## Komponenty

### 1. Schemat bazy danych
- tabela users_preferences
- tabela notifications
- tabela delivery_status
- tabela notification_templates

### 2. Endpointy API
- POST /api/notifications/send
- GET/PUT /api/users/{id}/preferences
- GET /api/notifications/{id}/status
- POST /api/webhooks/delivery

### 3. Serwisy w tle
- EmailWorker
- SMSWorker
- PushWorker
- StatusUpdateWorker

### 4. Komponenty frontend
- NotificationPreferences
- NotificationHistory
- NotificationComposer

## Kolejność implementacji
1. Schemat bazy danych
2. API zarządzania preferencjami
3. Podstawowe wysyłanie email
4. Dodaj SMS i push
5. Śledzenie statusu
6. Komponenty frontend

Najlepsze praktyki planowania

Myśl warstwami

Planuj od warstwy danych w górę: Baza danych → API → Logika biznesowa → UI

Rozważ skalę

Projektuj na 10x obecne obciążenie - łatwiej zaplanować skalę niż dopasować później

Planuj na awarie

Dołącz obsługę błędów, retry i fallbacks do swojego planu

Bezpieczeństwo najpierw

Planuj uwierzytelnianie, autoryzację i ochronę danych od początku

Faza 3: Implementacja listy Todo

Konwertuj plan na wykonalne todo

Wskazówka

Tutaj dzieje się magia - twoje przemyślane planowanie staje się systematyczną mapą drogową implementacji.

1. Generuj początkową listę todo:

   "Na podstawie naszego planu systemu powiadomień, stwórz szczegółową
   listę todo z konkretnymi zadaniami implementacji. Grupuj według
   komponentów i dołącz szacunki."

2. Dopracuj szczegóły:

   "Dodaj kryteria akceptacji do każdego elementu todo. Dołącz
   wymagania testowe i zadania dokumentacji."

3. Priorytetyzuj zadania:

   "Uporządkuj te todo według zależności i priorytetu.
   Jaka jest ścieżka krytyczna?"

Przykład listy Todo

# System powiadomień - Todo implementacji

## Faza 1: Fundament (Dzień 1-2)
- [ ] Utwórz migrację bazy danych dla tabel powiadomień
  - [ ] tabela users_preferences z flagami email/sms/push
  - [ ] tabela notifications ze śledzeniem statusu
  - [ ] notification_templates ze wsparciem zmiennych
  - [ ] Dodaj indeksy dla wydajności zapytań

- [ ] Skonfiguruj infrastrukturę kolejki wiadomości
  - [ ] Zainstaluj Redis/RabbitMQ
  - [ ] Utwórz konfigurację kolejki
  - [ ] Skonfiguruj kolejki dead letter
  - [ ] Implementuj pooling połączeń

## Faza 2: Podstawowe API (Dzień 3-4)
- [ ] Implementuj zarządzanie preferencjami
  - [ ] endpoint GET /api/users/{id}/preferences
  - [ ] endpoint PUT /api/users/{id}/preferences
  - [ ] Walidacja input z Zod
  - [ ] Testy jednostkowe z 90%+ pokryciem

- [ ] Utwórz API wysyłania powiadomień
  - [ ] endpoint POST /api/notifications/send
  - [ ] Substytucja zmiennych szablonu
  - [ ] Kolejka wiadomości do dostawy
  - [ ] Zwróć ID śledzenia

## Faza 3: Workery dostawy (Dzień 5-6)
- [ ] Implementuj EmailWorker
  - [ ] Integracja SendGrid/AWS SES
  - [ ] Renderowanie szablonów
  - [ ] Logika retry (3 próby)
  - [ ] Obsługa błędów i logowanie

- [ ] Implementuj SMSWorker
  - [ ] Integracja Twilio
  - [ ] Walidacja numerów telefonu
  - [ ] Śledzenie kosztów
  - [ ] Potwierdzenie dostawy

## Faza 4: Śledzenie statusu (Dzień 7)
- [ ] Webhooks statusu dostawy
  - [ ] endpoint POST /api/webhooks/delivery
  - [ ] Weryfikacja podpisu
  - [ ] Przetwarzanie aktualizacji statusu
  - [ ] Emisja zdarzeń dla aktualizacji real-time

Używanie trybu Agent do implementacji

Przełącz na tryb Agent

Teraz gdy masz jasny plan i todo, przełącz na tryb Agent do implementacji.

Systematyczna implementacja

1. Zacznij od pierwszego Todo:

   "Zaimplementujmy pierwsze todo: Utwórz migrację bazy danych
   dla tabel powiadomień. Użyj naszego standardowego wzorca migracji."

2. Zweryfikuj ukończenie:

   "Uruchom migrację i pokaż mi wynikowy schemat"

3. Przejdź do następnego Todo:

   "Świetnie! Teraz zaimplementujmy endpointy API preferencji.
   Zacznij od GET /api/users/{id}/preferences"

4. Testuj w trakcie:

   "Napisz kompleksowe testy dla endpointów preferencji
   włączając przypadki brzegowe"

Strategie zarządzania Todo

Podejście liniowe

Pracuj przez todo sekwencyjnie:

1. Ukończ każde todo w pełni
2. Testuj przed przejściem dalej
3. Dokumentuj w trakcie
4. Przeglądaj przed następną fazą

Najlepsze dla: jasnych zależności, projektów nauki

Podejście równoległe

Wielu deweloperów/instancji AI:

1. Przypisz niezależne todo
2. Pracuj jednocześnie
3. Integruj na kamieniach milowych
4. Rozwiązuj konflikty wcześnie

Najlepsze dla: napięte terminy, doświadczonych zespołów

Podejście iteracyjne

Buduj warstwami:

1. Podstawowa implementacja najpierw
2. Dodawaj funkcje stopniowo
3. Refaktoryzuj według potrzeb
4. Poleruj na końcu

Najlepsze dla: niepewnych wymagań, MVP

Śledzenie postępu

Wizualne śledzenie postępu

# Dashboard postępu

## Ogólnie: 45% ukończone ████████░░░░░░░░

### Faza 1: Fundament ✅ 100%
- [x] Migracje bazy danych
- [x] Konfiguracja kolejki wiadomości

### Faza 2: Podstawowe API 🏗️ 60%
- [x] Zarządzanie preferencjami
- [ ] API wysyłania powiadomień
- [ ] System szablonów

### Faza 3: Workery ⏳ 0%
- [ ] EmailWorker
- [ ] SMSWorker
- [ ] PushWorker

### Faza 4: Śledzenie 📋 0%
- [ ] Webhooks statusu
- [ ] Aktualizacje real-time

Używanie checkpointów

Wskazówka

Twórz checkpointy po każdej głównej fazie - to pozwala na bezpieczne eksperymentowanie i łatwy rollback.

1. Utwórz checkpoint:

   "Utwórz checkpoint: Faza 1 Fundament ukończona"

2. Kontynuuj rozwój: Pracuj nad następną fazą

3. Rollback jeśli potrzeba:

   "Rollback do checkpoint: Faza 1 Fundament ukończona"

Częste wzorce i antywzorce

Wzorce sukcesu ✅

Jasny zakres

Każde todo powinno być ukończalne w 1-4 godziny

Testowalne wyniki

Każde todo ma jasne kryteria akceptacji

Świadomość zależności

Uporządkuj todo według zależności, nie preferencji

Regularna integracja

Integruj pracę często aby uniknąć konfliktów

Antywzorce których należy unikać ❌

Niejasne Todo

“Implementuj uwierzytelnianie” - za szerokie!

Pomiń planowanie

Skok do todo bez PRD/Planu

Ignoruj zależności

Rozpoczynanie UI przed gotowością API

Brak śledzenia postępu

Tracenie informacji co jest ukończone

Przykład z rzeczywistego świata

Od PRD do wdrożenia

Projekt: System koszyka e-commerce
Czas: 3 dni
Zespół: 1 deweloper + Cursor AI

Dzień 1:
- Rano: Napisz PRD (2 godziny)
- Popołudnie: Planowanie z AI (1 godzina)
- Popołudnie: Generuj todo (30 min)
- Wieczór: Implementuj schemat bazy danych

Dzień 2:
- Rano: Endpointy API koszyka
- Popołudnie: Logika dodawania do koszyka
- Wieczór: Pakiet testów

Dzień 3:
- Rano: Komponenty frontend
- Popołudnie: Testy integracyjne
- Wieczór: Dokumentacja i wdrożenie

Wynik: Funkcja ukończona z 95% pokryciem testami

Zaawansowane techniki PRD

Używanie szablonów

Twórz szablony PRD do ponownego użycia:

.cursor/templates/
├── feature-prd.md
├── api-prd.md
├── integration-prd.md
└── bugfix-prd.md

Udoskonalanie wspomagane przez AI

"Przejrzyj ten PRD i zidentyfikuj wszelkie brakujące wymagania,
przypadki brzegowe lub potencjalne problemy bezpieczeństwa"

Współpracujące PRD

"Na podstawie naszej dyskusji w @past-chat, stwórz
kompleksowy PRD włączający cały feedback"

Następne kroki

Kontynuuj do konfiguracji MCP

Teraz skonfigurujmy serwery MCP aby zwiększyć moc twojego przepływu pracy rozwoju zewnętrznymi integracjami.

Konfiguracja MCP →

Czas: 10 minut

Wskazówka

Transformacja ukończona: Masz teraz systematyczne podejście do rozwoju funkcji które skaluje się od prostych błędów po złożone systemy. Ta metodologia oszczędzi godziny przepracowywania i zamieszania.