2.2: Планирование продукта

Ключевое: Прежде чем строить продукт, нужно описать его — что он делает, для кого, какие экраны увидит пользователь. Это описание продукта (на английском — PRD, Product Requirements Document) станет «чертежом», по которому Claude построит приложение. Чем точнее чертёж — тем лучше результат.

Обзор

Представь, что ты строишь дом. Можно просто сказать строителю: «Построй мне дом» — и получить что-то. А можно дать ему план: сколько комнат, какая планировка, где окна, какая крыша. Результат будет совершенно другим.

С продуктом — то же самое. В прошлом уроке мы создали фундамент (проект и контекст). Теперь нужно описать, что именно мы строим. Не техническим языком, а человеческим: какие экраны увидит пользователь, что он сможет сделать, какие проблемы это решает.

Это описание продукта — один из самых важных документов в жизни стартапа. Он помогает:

• Тебе — чётко сформулировать, что ты строишь (и что НЕ строишь)
• Claude — точно понять задачу и построить именно то, что нужно
• Команде — если у тебя есть со-основатель или советник, у всех одинаковое понимание
• Инвесторам — показать, что ты понимаешь свой продукт до деталей

Многие основатели пропускают этот шаг — «зачем планировать, давайте строить!». И потом переделывают три раза, потому что «это не то, что я имел в виду». 30 минут планирования сэкономят часы разработки.

В этом уроке ты возьмёшь результаты из модуля 1 (что нужно клиентам, чем ты отличаешься от конкурентов) и вместе с Claude превратишь это в чёткий план. Claude будет задавать вопросы, предлагать варианты и помогать расставить приоритеты.

Чему научишься

• Как описать продукт так, чтобы Claude точно понял — есть определённая структура, которая работает лучше всего. Не «сделай мне приложение», а конкретное описание: экраны, действия, данные. Ты научишься формулировать описание по этой структуре.

• Как выбрать, какие функции делать первыми — у любого продукта всегда больше идей, чем времени. Ты научишься методу MoSCoW (Must have, Should have, Could have, Won't have), который помогает определить, что обязательно для первой версии, а что может подождать.

• Как описать путь пользователя — что человек видит, когда открывает приложение? Куда нажимает? Что происходит дальше? Эти сценарии (user stories) — ключ к хорошему продукту.

• Как создать техническую спецификацию — не пугайся, Claude напишет её сам. Но ты поймёшь, зачем она нужна и как она связана с описанием продукта.

Структура описания продукта

Вот как выглядит хорошее описание продукта. Именно такой файл prd.md ты создашь в этом уроке:

# Описание продукта: [Название]

## 1. Проблема
Что за проблему мы решаем? Для кого?

## 2. Решение
Как наш продукт решает эту проблему? В чём главная идея?

## 3. Целевой пользователь
Кто будет пользоваться? Какой у него контекст?
(берём из модуля 1 — исследование клиентов)

## 4. Основные функции
Список всего, что продукт должен уметь.
С приоритетами: Must / Should / Could / Won't

## 5. Пользовательские сценарии
Что пользователь делает шаг за шагом:
- Открывает приложение → видит...
- Нажимает кнопку → происходит...
- Получает результат → делает...

## 6. Экраны и навигация
Какие страницы/экраны есть:
- Главная
- Дашборд
- Настройки
- ...

## 7. Что НЕ входит в первую версию
Список того, что мы осознанно откладываем.

## 8. Метрики успеха
Как мы поймём, что продукт работает?

Не нужно заполнять это заранее — Claude поможет пройти по каждому разделу в диалоге. Он будет задавать вопросы, а ты — отвечать. В итоге получится заполненный документ.

Приоритизация функций: метод MoSCoW

Самая частая ошибка — пытаться сделать всё сразу. Первая версия продукта (MVP) должна быть маленькой и фокусированной.

Правило для первой версии: 3-5 функций в Must have. Не больше. Всё остальное — на потом.

Почему меньше — это лучше

• Быстрее построишь — 3 функции Claude сделает за час, 15 функций — за неделю
• Легче проверить — пользователь протестирует 3 функции, а 15 — просто не дойдёт
• Проще исправить — если что-то не так, легче переделать малое
• Раньше получишь обратную связь — а это самое ценное для стартапа

Пользовательские сценарии

Пользовательский сценарий (user story) — это описание одного действия с точки зрения пользователя. Формат простой:

«Как [кто], я хочу [что сделать], чтобы [зачем]»

Примеры:

• «Как менеджер, я хочу видеть все обращения клиентов в одном списке, чтобы ничего не потерять»
• «Как владелец бизнеса, я хочу получать отчёт за неделю, чтобы понимать нагрузку на поддержку»
• «Как новый пользователь, я хочу пройти онбординг за 2 минуты, чтобы быстро начать работать»

Почему это важно для vibe coding? Потому что Claude отлично понимает такие описания. Когда ты говоришь «сделай экран со списком обращений, как описано в сценарии 1» — Claude знает, что именно нужно показать, какие данные вывести, какие действия предусмотреть.

Как написать хороший сценарий

Чем конкретнее — тем лучше результат. Это правило номер один в vibe coding.

Пошаговый процесс урока

Шаг 1: Вспоминаем результаты исследований

Claude откроет файлы из модуля 1 (market-brief.md, результаты анализа клиентов и конкурентов) и напомнит ключевые выводы. Это база для описания продукта.

Шаг 2: Определяем проблему и решение

Claude задаст вопросы: «Какую главную проблему решает продукт?», «Чем твоё решение отличается?». Вместе вы сформулируете ясное описание.

Шаг 3: Составляем список функций

Мозговой штурм: какие функции нужны? Claude поможет придумать то, о чём ты не подумал, и убрать лишнее.

Шаг 4: Расставляем приоритеты

Используя метод MoSCoW, разделяете все функции на категории. Claude может предложить свой вариант приоритизации, но финальное решение — за тобой.

Шаг 5: Описываем сценарии

Для каждой Must have функции прописываете пользовательский сценарий: кто, что делает, что видит, что происходит.

Шаг 6: Создаём файлы

Claude создаст два файла:

• prd.md — описание продукта со всеми разделами
• tech-spec.md — техническая спецификация (Claude заполнит сам на основе описания)

Советы для лучшего результата

1. Не торопись — 30 минут на планирование сэкономят часы на разработке. Если урок занял 40 минут — это нормально и даже хорошо.

2. Думай как пользователь — не «какие функции добавить», а «что пользователь хочет сделать». Это разные вопросы с разными ответами.

3. Будь конкретным — «красивый дизайн» не говорит ничего. «Минималистичный интерфейс, белый фон, зелёные акценты, шрифт Inter» — говорит всё.

4. Фиксируй, что НЕ делаешь — раздел «Won't have» так же важен, как «Must have». Он защищает от бесконечного расползания функций.

5. Спорь с Claude — если Claude предлагает добавить функцию, а ты считаешь, что для MVP она лишняя — скажи это. Ты лучше знаешь своего пользователя.

6. Проверяй связность — описание продукта должно быть непротиворечивым. Если в одном месте написано «простое приложение», а в другом — 20 экранов, что-то не так.

Частые вопросы

Зачем писать описание, если можно просто сказать Claude, что строить? Можно, но результат будет хуже. Описание продукта — это способ подумать заранее, а не на ходу. Claude строит ровно то, что описано. Чем точнее описание — тем меньше переделок.

А если я не знаю, какие функции нужны? Claude поможет! Расскажи ему о проблеме и целевом пользователе — он предложит варианты. Ты выберешь лучшие. Это диалог, а не экзамен.

Что такое tech-spec.md и нужно ли мне в нём разбираться? Техническая спецификация — это «инструкция для Claude», где описано, какие технологии использовать, как организовать код, какие библиотеки подключить. Тебе не нужно разбираться в деталях — Claude напишет её сам на основе описания продукта. Но она нужна ему, чтобы принимать правильные технические решения.

Можно ли изменить описание потом? Конечно. Описание продукта — живой документ. После первых тестов с пользователями ты наверняка захочешь что-то изменить. Это нормальная часть процесса.

Сколько пользовательских сценариев нужно? Для первой версии — 3-5 основных сценариев, по одному на каждую Must have функцию. Этого достаточно, чтобы Claude понял структуру продукта.

А если мой продукт сильно отличается от учебного примера? Структура описания продукта универсальна. Неважно, строишь ты SaaS-продукт, маркетплейс или инструмент для внутренней команды — разделы те же: проблема, решение, функции, сценарии, приоритеты.

Что создашь

• prd.md — описание продукта: проблема, решение, функции с приоритетами, пользовательские сценарии, экраны и навигация. Главный документ, определяющий, что мы строим.
• tech-spec.md — техническая спецификация: какие технологии, какая архитектура, какие зависимости. Claude заполнит сам — тебе не нужно в этом разбираться, но Claude нужен этот файл для работы.

Запуск

/start-2-2

Следующий урок: Разработка →