Как написать хороший документ требований продукта (PRD)?

Question

Accepted Answer

**Документ требований продукта (PRD)** объясняет *что* вы строите, *почему* и *как вы узнаете, что это сработало* — чтобы команда инженеров и дизайнеров могла построить нужное без постоянных уточнений. Хороший PRD — это инструмент мышления и артефакт согласования, а не бюрократическая бумажная работа.

## Твёрдый план PRD

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## Начните с причины

Самый важный раздел — это **проблема и цели**. Если команда понимает *почему* и *как выглядит успех*, она часто находит лучшие решения, чем то, которое вы указали. PRD, который является только спецификацией функций, это упускает.

## Негативные цели недооценены

Явное указание того, что находится вне области видимости, предотвращает расширение области видимости и ловушку «пока мы за этим...». Это столь же ценно, как сами требования.

## Типичные ошибки

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## Почему это важно

Большая часть переделок происходит из-за неправильного выравнивания: команда построила то, что было попрошено, а не то, что было необходимо.

Ясный PRD выявляет эти пробелы *до того*, как кто-то напишет код.

Он также заставляет *вас* продумать проблему.

Если вы не можете ясно написать цель и метрику успеха, вы недостаточно хорошо понимаете проблему, чтобы её строить.