Как написать ТЗ на MVP: 7 разделов и пример
ТЗ на MVP — это не 40 страниц спецификаций, а короткий документ из 7 разделов: гипотеза, пользователь, один ключевой сценарий, что НЕ входит, интеграции, критерии успеха и ограничения. Такое ТЗ помещается на несколько страниц, сокращает переписку с подрядчиком и позволяет ему назвать фиксированную цену. Разделы и заполненный пример ТЗ — ниже.
Зачем ТЗ, если «мы же гибкие»
ТЗ на MVP решает две задачи. Первая — ваша: письменная формулировка гипотезы мгновенно вскрывает, что вы на самом деле проверяете (часто это открытие). Вторая — экономическая: при чётком ТЗ мы работаем по фиксированной стоимости, без ТЗ — почасовка и оценка «от и до» (см. формат работы).
Цена ошибки несопоставима с ценой ТЗ. По оценке Qtim на vc.ru (март 2026), 2–3 недели аналитики и прототипов стоят 300–500 тыс. ₽, а переделка продукта после трёх месяцев разработки «не в ту сторону» — 3–5 млн ₽. Для MVP суммы меньше, пропорция та же.
Цена ошибки несопоставима с ценой ТЗ. По оценке Qtim на vc.ru (март 2026), 2–3 недели аналитики и прототипов стоят 300–500 тыс. ₽, а переделка продукта после трёх месяцев разработки «не в ту сторону» — 3–5 млн ₽. Для MVP суммы меньше, пропорция та же.
7 разделов ТЗ на MVP
- Гипотеза — одно предложение: «Мы считаем, что (кто) будет платить за (что), потому что (почему)».
- Пользователь — кто он, где вы его возьмёте на проверку, сколько их нужно.
- Ключевой сценарий — путь пользователя от входа до ценности, по шагам. Один. Второй сценарий — вторая итерация.
- Что НЕ входит — самый важный раздел: личные кабинеты «на будущее», админки со всеми настройками, мобильное приложение «заодно». Всё, без чего гипотеза проверяется, — сюда.
- Интеграции — оплата, доставка, учёт: только те, без которых сценарий не работает.
- Критерии успеха — какие цифры через сколько недель означают «строим дальше»: заявки, оплаты, возвраты.
- Ограничения — бюджет, дедлайн, пожелания к стеку (если есть) и два пункта, которые в 2026 году нельзя пропускать:
- где хранятся данные — если продукт собирает регистрации, заявки или оплаты граждан РФ, с 1 июля 2025 года первичный сбор персональных данных допускается только в базы на территории России (23-ФЗ). Это влияет на выбор стека, поэтому фиксируется до сметы;
- какие события нужно считать — если критерий успеха «30 оплат за месяц», в ТЗ должно быть, где и как фиксируется оплата: Яндекс Метрика, события в базе, выгрузка. Иначе через месяц проверять будет нечем.
Пример: как выглядит заполненное ТЗ
Условный пример — сервис записи ветеринара на дом. Так выглядят разделы в сокращении:
Самая длинная строка здесь — «Что НЕ входит». Так и должно быть. Бюджет в примере сходится с нашими вилками: MVP на no-code — от 500 тыс. ₽, а онлайн-оплата и SMS — ещё две интеграции.
Типовые ошибки
- ТЗ описывает продукт мечты, а не проверку. Признак: в документе больше трёх сценариев.
- Нет раздела «что не входит». Тогда его напишет разработка — своими руками в вашу смету.
- Критерий успеха — «понравится пользователям». Не измеримо → не проверяемо → MVP не выполнил работу.
- Технические решения вместо задач — «нужен микросервис на Go». Опишите задачу; стек — совместное решение (как выбрать).
ТЗ и AI-генерация
Если прототип вы собираете сами в Lovable, Bolt или v0, ТЗ всё равно нужно — оно и есть основа промпта. Генератор строит то, что описано, и охотно добавляет лишнее: раздел «Что НЕ входит» защищает прототип от лишних функций так же, как смету. Критерии успеха и требования к данным генератор за вас не сформулирует.
Черновик ТЗ можно собрать и с помощью нашего AI-генератора ТЗ: он раскладывает описание идеи по тем же 7 разделам. Раздел «Что НЕ входит» после него всё равно стоит перечитать и дописать руками.
Черновик ТЗ можно собрать и с помощью нашего AI-генератора ТЗ: он раскладывает описание идеи по тем же 7 разделам. Раздел «Что НЕ входит» после него всё равно стоит перечитать и дописать руками.
Пример из практики
Druffle — платформа бесконтактного сервиса для отелей. Вместе с основателями мы спроектировали один замкнутый сценарий: гость создаёт заявку → администратор назначает сотрудника → сотрудник получает уведомление в мессенджере и меняет статус → гость видит результат. На этом цикле pre-MVP собрали за 6 недель к жёсткому дедлайну 31 августа.
Для полноценного MVP команда Druffle передала нам ТЗ, и продукт наращивали итерациями на той же базе, без переписывания. Подробнее — в кейсе Druffle.
Для полноценного MVP команда Druffle передала нам ТЗ, и продукт наращивали итерациями на той же базе, без переписывания. Подробнее — в кейсе Druffle.
Как собрать своё ТЗ
Возьмите таблицу из примера выше и замените каждую строку своей: семь строк, по одной на раздел. Начните с гипотезы и «Что НЕ входит» — остальное проще дописать, когда эти два раздела готовы. С таким ТЗ приходите в форму расчёта: по нему мы даём смету без уточняющих кругов.
Частые вопросы
Не рано: раздел «гипотеза» и есть проверка, что идея сформулирована. Остальные разделы заполняются в диалоге — на первой встрече мы это делаем вместе.
Объёмом и центром тяжести: обычное ТЗ описывает систему целиком, ТЗ на MVP — одну проверку. Главный раздел здесь — «что не входит».
Да, но осознанно: изменение фиксируется и пересчитывается. Гибкость — не в размытом ТЗ, а в коротких итерациях: проверили — скорректировали следующую.
Это самый частый затык, и он полезен: если непонятно, какая цифра докажет спрос, гипотеза ещё не готова. Помогаем сформулировать на первой встрече.
