Шаблон ТЗ на MVP: 14 разделов с примерами формулировок

1. Одно предложение о продукте. Формула: «[Продукт] помогает [кому] решать [какую проблему] с помощью [как]». Пример: «Сервис помогает автосервисам записывать клиентов онлайн и напоминать о визите, сокращая неявки».

2. Проблема и как её решают сейчас. Опишите, чем пользуются люди сегодня: Excel, WhatsApp, блокнот. Это база для сравнения — MVP должен быть удобнее текущего способа, а не идеального конкурента.

3. Портреты пользователей. 2–3 роли с задачами: «Администратор: принимает заявки, следит за расписанием» — по одному абзацу на роль. Роли напрямую превращаются в разделы интерфейса.

4. Метрика успеха MVP. Одна цифра, по которой через 3 месяца вы поймёте, что продукт живой: количество заявок в неделю, доля повторных заказов, время обработки. Ошибка — писать «привлечь инвестиции»: это следствие, а не метрика продукта.

5. Сценарии ключевых ролей. Для каждой роли — путь по шагам: «Клиент открывает страницу → выбирает услугу → выбирает время → вводит телефон → получает СМС». Один сценарий = 5–9 шагов. Всё, что не попало в сценарии, — не MVP.

6. Список функций с приоритетами. Таблица из трёх колонок: функция / зачем / приоритет (must / should / later). Честно: в must попадает только то, без чего сценарии из раздела 5 не работают.

7. Что НЕ входит в MVP. Самый недооценённый раздел. Явно напишите: «личный кабинет с историей — later», «мобильное приложение — later, начинаем с веба». Это защищает бюджет от расползания.

8. Референсы. 2–3 продукта со скриншотами и пометками «нравится это, не нравится то». Не «сделайте как у Авито» целиком, а конкретные элементы.

9. Данные и сущности. Перечислите, чем оперирует система: клиент, заказ, услуга, платёж. Для каждой сущности — 5–10 полей. Не бойтесь ошибиться: аналитик подрядчика уточнит, важно показать состав.

10. Интеграции. Каждая интеграция — отдельная строка бюджета, поэтому перечислите всё: платёжка (какая?), СМС/почта, 1С, CRM, карты, соцсети. Укажите, есть ли у вас доступы и договоры с этими сервисами.

11. Ограничения и требования. Здесь живут вещи, о которых вспоминают в конце и дорого переделывают: персональные данные (152-ФЗ), объём нагрузки («до 100 заказов в день»), устройства («80% клиентов — с телефона»), брендбук, если есть.

12. Сроки и вехи. Если есть дедлайн (выставка, сезон, инвесткомитет) — напишите его и что должно быть готово к дате. Честный дедлайн меняет состав MVP сильнее, чем бюджет.

13. Вилка бюджета. Страх «назову бюджет — под него и посчитают» работает против вас: без вилки подрядчик проектирует вслепую. Пишите диапазон: «до 800 тыс. — идеально, до 1,2 млн — обсуждаемо, если понятно за что».

14. Критерии приёмки. По каждому сценарию из раздела 5 — как проверяете, что готово: «создаю запись с телефона за 60 секунд, СМС приходит». Эти же критерии станут чек-листом финального тестирования.

Ошибка 1: описывать решение вместо задачи. «Нужен экран с фильтром по 12 полям» вместо «менеджер должен находить заказ за 10 секунд». Описывайте результат — решение предложит проектировщик, часто проще и дешевле.

Ошибка 2: MVP на 40 функций. Если в разделе must больше 12–15 пунктов, это не MVP. Правило: вычёркивайте, пока не станет больно, потом верните одну.

Ошибка 3: молчать про админку. Клиентская часть — половина системы. Кто и как будет управлять контентом, заказами, ценами? Админка часто стоит столько же, сколько витрина.