📋 Продвинутый · Процесс

Подготовка к проекту — от идеи до ТЗ

Плохой старт невозможно компенсировать хорошим кодом. Эта страница — о том что нужно сделать ДО первой строки кода: собрать требования, структурировать ТЗ, определить MVP. Два сценария: клиентский проект и собственный стартап.

клиент → ТЗ стартап → MVP шаблоны для копирования промпты для CC

🏢 Клиентский проект Веб-студия · заказная разработка 🚀 Собственный продукт Стартап · продуктовая разработка

🏢 Сценарий A: Клиентский проект

A1. Этапы работы с клиентом

Первый контакт

Быстро понять масштаб, бюджет, сроки. Определить стоит ли двигаться дальше. Не пиши код — задавай вопросы.

→ первичная оценка (да / нет / maybe) 30–60 мин

Первичный бриф

Анкета из 15 вопросов которую клиент заполняет письменно. Не звонок — именно письменно: клиент думает, ты анализируешь без давления.

→ заполненный бриф.md 1–2 дня (клиент заполняет)

Уточняющий созвон

На основе брифа — 30 минут созвона. Только неясные моменты, не пересказ брифа. Используй CC для подготовки вопросов по брифу.

«Вот бриф клиента: [вставить]. Какие вопросы остались неясными? Составь список уточняющих вопросов.»

→ заметки созвона 30–60 мин

Написание ТЗ

На основе брифа + заметок — структурированное ТЗ. CC помогает написать, ты контролируешь. Не наоборот.

«Напиши ТЗ на разработку [тип проекта] по этому брифу: [вставить]. Структура: цель, аудитория, функционал, технические требования, не входит в scope.»

→ ТЗ v1.0 (PDF или Google Doc) 2–4 часа

Согласование

Клиент читает ТЗ, вносит правки. Максимум 2 итерации. После подписания — это договор, не пожелание.

→ подписанное ТЗ 3–7 дней

A2. Первичный бриф — 15 вопросов

Эти вопросы задаются письменно до любого звонка. Клиент, который не может ответить на них — не готов к разработке.

Что это за продукт? Опиши в 2–3 предложениях.required

Клиент часто не может сформулировать суть. Размытый ответ = неопределённые требования.

Кто целевой пользователь? Возраст, профессия, уровень технической грамотности.required

Меняет UX-решения кардинально. B2B vs B2C — разные интерфейсы.

Какую проблему решает продукт? Как пользователь решает её сейчас (без вашего продукта)?required

Без боли — нет продукта. Если нет ответа — рынка тоже нет.

Есть ли аналоги? Что должно быть лучше чем у них?important

Конкурентный анализ. Помогает не изобретать велосипед.

Какой ожидается объём пользователей? (при запуске / через год / пик)important

Влияет на архитектуру, хостинг, базу данных.

Есть ли дедлайн? Почему именно эта дата?required

Нереальные сроки = провал. «Нам нужно к выставке» — это внешнее ограничение, не каприз.

Какой бюджет? Есть ли резерв на непредвиденное (обычно +20–30%)?required

Без бюджета нельзя оценить scope. Без резерва — первая правка может сорвать проект.

Кто принимает финальное решение? Есть ли другие stakeholders?important

«Согласую с директором» на 5-м этапе = потеря 2 недель и переделка половины.

Какие интеграции нужны? (CRM, платёжная система, соцсети, API)important

Каждая интеграция — отдельная задача с неочевидной сложностью.

Есть ли фирменный стиль / дизайн-гайдлайн? Или нужен дизайн с нуля?important

Дизайн с нуля vs адаптация готового — разница в 2–3x по времени.

На каких устройствах и браузерах должно работать?important

IE11, mobile-first, PWA — каждое требование добавляет время.

Какие требования к безопасности? Есть ли персональные данные / платёжная информация?required

152-ФЗ, PCI DSS — юридические обязательства которые влияют на архитектуру.

Кто будет поддерживать сайт после сдачи? Есть ли технический сотрудник на стороне клиента?important

Влияет на выбор CMS, сложность админки, документацию.

Были ли уже попытки сделать этот продукт? Почему не получилось?

Часто кроется реальная проблема: бюджет кончился, подрядчик подвёл, требования менялись.

Что является критерием успешной сдачи проекта?required

«Всё работает» — не критерий. «10 товаров в каталоге, оплата через ЮКассу, формы отправляют письма» — критерий.

A3. Структура ТЗ

Минимальная структура которая покрывает все конфликтные точки.

# Техническое задание: [Название проекта] **Версия:** 1.0 **Дата:** [дата] **Заказчик:** [название] **Исполнитель:** [студия] --- ## 1. Цель проекта [Одна-две фразы: что создаётся и зачем] ## 2. Целевая аудитория [Описание пользователей: кто они, что умеют, как будут использовать] ## 3. Функциональные требования ### 3.1 [Модуль / раздел 1] - [ ] Требование 1 - [ ] Требование 2 ### 3.2 [Модуль / раздел 2] - [ ] Требование 1 ## 4. Нефункциональные требования - **Производительность:** страница загружается < 2 сек на 3G - **Безопасность:** HTTPS, защита от XSS/CSRF, шифрование паролей - **Совместимость:** Chrome, Firefox, Safari последние 2 версии; мобильные iOS/Android - **Доступность:** корректное отображение при отключённом JS ## 5. Технический стек (предлагаемый) - Backend: [Laravel 11 / WordPress / etc.] - Frontend: [Vue 3 / React / Alpine.js / etc.] - База данных: [MySQL / PostgreSQL] - Хостинг: [VDS / cloud / etc.] ## 6. Интеграции - [ ] [Название сервиса] — [что делает] ## 7. НЕ входит в данную версию (Out of Scope) - [Явно перечислить что не делается] - Мобильное приложение - Многоязычность ## 8. Критерии приёмки - [ ] [Конкретный проверяемый критерий] - [ ] Все формы отправляют уведомления на email@client.ru - [ ] Оплата проходит в тестовом режиме ЮКасса ## 9. Сроки и этапы | Этап | Что включает | Срок | |------|-------------|------| | 1. Дизайн | Главная + 3 ключевых экрана | 2 нед | | 2. Backend | API, БД, интеграции | 3 нед | | 3. Frontend | Вёрстка, интеграция с API | 2 нед | | 4. Тестирование | QA, правки | 1 нед | ## 10. Ответственность сторон - Заказчик предоставляет: контент, доступы, обратную связь в течение 3 рабочих дней - Исполнитель: код, деплой, документацию, поддержку [X] мес. после сдачи

A4. Как CC помогает написать ТЗ

Вот бриф клиента: [вставить текст брифа]. Напиши структурированное ТЗ по шаблону. Выдели то что клиент не указал явно и где нужны уточнения.

Клиент хочет [описание]. Составь список рисков и неоднозначностей которые нужно уточнить до начала разработки.

Вот ТЗ версии 1: [вставить]. Проверь нет ли противоречий, неопределённых требований и пунктов которые можно интерпретировать по-разному.

🚀 Сценарий B: Собственный продукт / стартап

B1. Lean Canvas — до строчки кода

Lean Canvas — 20 минут работы которые могут сохранить 3 месяца разработки. Заполни перед тем как открывать IDE.

Проблема

Топ-3 проблемы которые ты решаешь

«Нет инструмента X для аудитории Y», «Существующие решения слишком дорогие»

Решение

Топ-3 фичи которые решают эти проблемы

Минимальный набор — не wishlist, а то что снимает боль

Ключевые метрики

Что измеряешь?

Активные пользователи, конверсия, MRR

Уникальное ценностное предложение

Одна фраза: «Мы помогаем X достичь Y без Z»

Должно быть понятно неспециалисту за 5 секунд

Нечестное преимущество

Что нельзя легко скопировать?

Доступ к аудитории, патент, экспертиза, данные

Каналы

Как достигаешь пользователей?

SEO, cold email, партнёрства, сообщества

Сегменты клиентов

Ранние последователи: конкретно кто?

Не «все», а «PHP-разработчики в небольших студиях»

Структура затрат

Хостинг, инструменты, реклама, твоё время

Считай в деньгах, не в часах

Потоки доходов

Как монетизируешь?

Подписка, one-time, freemium, API-доступ

Заполни с помощью CC: «Я делаю [описание идеи]. Помоги заполнить Lean Canvas — задавай вопросы по одному блоку.»

B2. MVP-скоуп — что входит, что нет

MVP не значит сырой продукт. Это минимум который даёт реальную ценность первым пользователям.

Категория	✅ В MVP	⏳ Не в MVP (v2+)
Аутентификация	Email + пароль, сброс пароля	OAuth, 2FA, SSO
Платежи	Одна платёжная система (ЮКасса / Stripe)	Несколько методов, рассрочка
Уведомления	Email	Push, SMS, in-app
Аналитика	Базовый дашборд	Продвинутая отчётность, экспорт
Интерфейс	Один дизайн	Тёмная тема, кастомизация
API	Внутренний	Публичный API, SDK
Локализация	Один язык	Мультиязычность
Мобильный	Адаптивный веб	Нативное приложение

Вот список фич которые я хочу: [список]. Помоги разделить на MVP (то что нужно для первых пользователей) и v2 (то что можно добавить потом). Критерий: MVP должен быть готов за [X недель].

B3. User Story Mapping с Claude

User Story Map помогает увидеть продукт глазами пользователя и приоритизировать разработку. По горизонтали — пользовательские активности (что делает). По вертикали — конкретные истории (как именно).

КАК [роль пользователя] Я ХОЧУ [действие] ЧТОБЫ [цель / ценность] КРИТЕРИИ ПРИЁМКИ: - [ ] [проверяемое условие 1] - [ ] [проверяемое условие 2] ПРИОРИТЕТ: [Must Have / Should Have / Could Have] ОЦЕНКА: [X часов / дней]

Вот мой продукт: [описание]. Составь User Story Map — основные активности пользователя и 3–5 историй под каждой.

Вот user stories: [список]. Расставь приоритеты по методу MoSCoW для MVP за 8 недель.

B4. Выбор технического стека

Стек выбирается один раз — менять его дорого. Задай CC правильные вопросы.

Я делаю [тип продукта]. Аудитория [описание]. Планируемая нагрузка [X users]. Предложи 2–3 варианта стека с плюсами и минусами каждого.

Сравни Laravel vs Django для [описание задачи]. Учти: один разработчик, знаком с PHP, нужна быстрая разработка.

Какие риски у выбора [стек] для [тип проекта]? Что может стать проблемой через год?

Нужна ли мне микросервисная архитектура для [описание]? Или монолит будет достаточен?

B5. CLAUDE.md для нового проекта

Создай CLAUDE.md в начале проекта — не через 3 месяца когда всё уже сломано.

# Проект: [Название] ## Контекст [2–3 предложения: что делает, для кого, зачем] ## Стек [Технологии с версиями: Laravel 11, PHP 8.3, Vue 3.4, PostgreSQL 16, Redis 7] ## Архитектура (соблюдать обязательно) - [Главные архитектурные правила] - Логика ТОЛЬКО в Services/ - [Специфика проекта] ## Команды - Тесты: `[команда]` - Линтер: `[команда]` - Dev-сервер: `[команда]` - Деплой: `[команда или "вручную"]` ## Инфраструктура - Локально: [порты, контейнеры] - Staging: [URL если есть] - Production: [URL] ## Запреты - НЕ трогай [файлы/папки которые нельзя менять] - НЕ коммить без явного запроса - НЕ меняй .env — только читай ## После изменений Всегда запускай тесты и показывай вывод.

🔗 Передача контекста в Claude

Claude не читает мысли. Контекст — твоя ответственность.

В начале каждой сессии
Прочитай CLAUDE.md. Если проекту > 1 месяца — проверь что он актуален. Устаревший CLAUDE.md хуже чем отсутствующий.

При сложных задачах
Дай контекст явно: «Мы делаем X для Y. Сейчас работаем над Z. Вот текущая структура: [вставить].» Не жди что Claude сам поймёт что важно.

Для нового проекта
Первый промпт всегда: «Вот контекст проекта: [бриф или Lean Canvas]. Задай вопросы которые помогут тебе лучше понять что мы делаем.»

✅ Переход к разработке

Готов начинать?
Бриф готов, ТЗ согласовано / Lean Canvas заполнен, MVP определён — значит можно начинать разработку.

📐 Стандарты разработки →

Цикл без регресса, скиллы, CLAUDE.md, чеклисты

📚 Связанные материалы

📐 Большая проектная документация

Когда ТЗ перерастает один файл: PRD, spec, PLAN, ADR, examples/ — система доков для агента

📐 Стандарты разработки

Цикл без регресса, скиллы, чеклист перед коммитом

🗂️ Workflow разработки

Brainstorm → Spec → Plan → Execute → Merge

🧭 Выбор модели

Какую модель использовать для ТЗ, планирования, кода

📋 Команды CC

Команды CC для управления контекстом проекта

🪙 Оптимизация токенов

Как работать с большим контекстом проекта