Как написать техническое задание для MVP: шаблон и примеры

Как написать тз для mvp — тема, которая определяет успех IT-проекта. «Сделайте нам приложение» — ТЗ, которое стоит 5 000 000 ₽ в переделках. «Вот 10 страниц с user stories, wireframes и acceptance criteria» — ТЗ, которое экономит 30-40% бюджета. Разница — в подходе к описанию того, что вы хотите.

В этом гайде — структура ТЗ для MVP, которую мы используем в Prime IT. С примерами, шаблонами и объяснениями, зачем нужен каждый раздел.

Почему ТЗ важнее, чем кажется

ТЗ — это не бюрократия. Это инструмент, который:

• Превращает идею из головы в документ, который можно обсудить
• Позволяет сравнить оценки разных подрядчиков на одинаковый скоуп
• Служит юридическим основанием при спорах
• Экономит 30-40% бюджета за счёт ясности требований

При разработке MVP хорошее ТЗ — это 50% успеха проекта.

Структура ТЗ для MVP (шаблон)

1. Краткое описание продукта (1 страница)

• Название продукта
• Проблема — какую проблему решает (1-2 предложения)
• Целевая аудитория — кто пользователь (1-2 предложения)
• Ключевая ценность — почему будут использовать
• Тип продукта — веб-приложение, мобильное, SaaS
• Бюджет и сроки — ориентировочные рамки

2. User stories (2-3 страницы)

Описание функций через призму пользователя. Формат:

Как [роль], я хочу [действие], чтобы [результат]

Примеры для маркетплейса:

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

Для MVP: 15-25 user stories. Пометьте приоритет: Must (обязательно), Should (желательно), Could (можно отложить).

3. Wireframes ключевых экранов (3-5 страниц)

Не дизайн, а схема. Что на каком экране, какая навигация. Достаточно 5-7 экранов:

• Главный экран / дашборд
• Регистрация / вход
• Основной рабочий процесс (2-3 экрана)
• Профиль / настройки

Инструменты: Figma (бесплатно), Balsamiq, или даже бумага + фото.

4. Acceptance criteria (2-3 страницы)

Для каждой user story — конкретные критерии готовности.

Пример для «оплата картой»:

• Поддерживаются карты Visa, MasterCard, МИР
• Минимальная сумма оплаты — 100 ₽
• После оплаты — подтверждение на email
• При ошибке — понятное сообщение и возможность повторить
• Интеграция через ЮKassa (не собственный эквайринг)

5. Нефункциональные требования (1 страница)

• Производительность — время загрузки <3 секунд
• Нагрузка — до 100 одновременных пользователей (для MVP достаточно)
• Безопасность — HTTPS, хеширование паролей, OWASP Top 10
• Доступность — мобильная адаптация обязательна
• Хостинг — облако (Yandex Cloud / AWS)

6. Интеграции (0.5-1 страница)

Список внешних систем, с которыми MVP должен работать:

• Платёжная система — ЮKassa
• Email — SMTP или SendGrid
• Аналитика — Яндекс.Метрика
• CRM — нет (в версии 2)

7. Что НЕ входит в MVP (0.5 страницы)

Важнейший раздел! Явно укажите, что отложено:

• Мобильное приложение (только веб, адаптивный)
• Интеграция с 1С
• Многоязычность
• AI-рекомендации

Этот раздел предотвращает scope creep и споры «а мы думали, это входит».

5 ошибок при написании ТЗ

1. Описание решения вместо проблемы — «нужна кнопка X» вместо «пользователь должен иметь возможность Y»
2. Размытые критерии — «удобный интерфейс» вместо конкретных action items
3. 100 страниц — никто не читает. Краткость = ясность
4. Отсутствие приоритетов — всё «обязательно» = ничего не обязательно
5. Нет раздела «что не входит» — гарантированный scope creep

Подробнее о типичных ошибках заказчиков — в нашей статье о выборе команды разработки.

Сколько стоит ТЗ

Кто пишет	Стоимость	Качество
Заказчик сам	0 ₽	Часто размыто, но лучше, чем ничего
Аналитик подрядчика	50 000 — 150 000 ₽	Профессиональный уровень
Отдельный консультант	100 000 — 300 000 ₽	Независимая экспертиза

Инвестиция в ТЗ окупается минимум в 3 раза. Подробнее о бюджетировании — в нашем гайде о стоимости разработки.

Начните с одного листа

Не пытайтесь написать идеальное ТЗ с первой попытки. Начните с одного листа: проблема, аудитория, 10 user stories, 5 wireframes. Этого достаточно для первого разговора с подрядчиком.

Если хотите получить профессиональную оценку вашего ТЗ или помощь с его написанием — запишитесь на бесплатный Zoom-звонок. Мы разберём вашу идею и покажем, как превратить её в проверенный план MVP.

Как написать ТЗ для MVP: пошаговый алгоритм за 5 дней

Теория — это хорошо, но вам нужен конкретный план. Вот алгоритм, который мы используем в Prime IT для каждого нового проекта. За 5 рабочих дней вы получите готовое ТЗ, по которому можно оценивать стоимость и начинать разработку.

День 1. Интервью с заказчиком и карта целей

Первый шаг — структурированное интервью. Не «расскажите про ваш проект», а конкретные вопросы:

• Кто ваш клиент? Какую задачу он решает сейчас и чем недоволен?
• Какую одну проблему должен решать MVP? (именно одну — фокус)
• Как вы узнаете, что MVP успешен? Какие метрики будете смотреть?
• Какой бюджет и сроки? Есть ли жёсткий дедлайн?
• Есть ли конкуренты? Чем отличаетесь?

Результат дня: документ на 1-2 страницы — описание продукта, целевая аудитория, ключевая ценность, скоуп проекта. Это первый раздел вашего ТЗ для MVP.

День 2. User stories и приоритизация

На основе интервью пишете user stories. Используйте формат: «Как [роль], я хочу [действие], чтобы [результат]». Для MVP должно получиться 15-25 историй.

Каждую историю помечаете приоритетом по MoSCoW:

Приоритет	Значение	Для MVP
Must	Обязательно, без этого MVP не работает	8-12 историй
Should	Важно, но MVP может работать без этого	5-8 историй
Could	Было бы хорошо, но можно отложить	3-5 историй
Won't	Не входит в MVP (раздел «что не входит»)	Фиксируем отдельно

Ключевое правило: в MVP попадают только Must и частично Should. Если Must-историй больше 15 — скоуп проекта слишком широкий, и нужно резать.

День 3. Wireframes и пользовательские сценарии

Берёте Must-истории и рисуете экраны. Не макеты в Figma с пиксельной точностью, а схемы: что на каком экране, куда ведёт кнопка, какой маршрут проходит пользователь.

Для каждого ключевого сценария прописываете путь пользователя от входа до результата. Пример для маркетплейса:

Главная → Каталог → Карточка товара → Корзина → Оплата → Подтверждение

Если сценарий длиннее 6 шагов — ищите, что сократить. Каждый дополнительный шаг — это потеря 20-30% пользователей. Wireframes — один из самых недооценённых инструментов. Они убирают 80% разночтений между тем, что написано в ТЗ, и тем, что подрядчик представляет в голове.

День 4. Acceptance criteria и нефункциональные требования

Для каждой Must-истории пишете acceptance criteria — конкретные условия, при которых функция считается готовой. Без acceptance criteria разработчик решает сам, что считать «готово», а ваше представление может кардинально отличаться.

Пример для истории «пользователь регистрируется через email»:

• Поля: имя, email, пароль (минимум 8 символов)
• После отправки — письмо подтверждения на указанный email
• Без подтверждения — доступ ограничен (можно смотреть, нельзя покупать)
• Повторная регистрация с тем же email — сообщение «email уже зарегистрирован»
• При ошибке сервера — понятное сообщение + повторная попытка

Отдельно фиксируете нефункциональные требования: производительность (время загрузки), нагрузка (одновременных пользователей), безопасность (HTTPS, хеширование, OWASP), адаптивность (мобильная версия), инфраструктура (хостинг, CDN).

День 5. Ревизия и финализация

Собираете всё в один документ. Проверяете:

1. Нет ли противоречий между user stories и wireframes?
2. У каждой Must-истории есть acceptance criteria?
3. Раздел «что НЕ входит» заполнен? (Без него — гарантированный scope creep)
4. Нефункциональные требования реалистичны? (1 000 000 одновременных пользователей для MVP — перебор)
5. Бюджет и сроки указаны хотя бы ориентировочно?

Когда вы знаете, как написать ТЗ для MVP, и следуете этому алгоритму — документ готов за 5 рабочих дней. Не за месяц, не за квартал.

Пример ТЗ для MVP: маркетплейс услуг

Чтобы было нагляднее, вот сокращённый пример реального ТЗ, которое мы готовили для клиента. Продукт — маркетплейс строительных услуг.

Описание продукта

Проблема: Заказчики ремонта тратят 2-3 недели на поиск бригады. Звонят по объявлениям, общаются с 5-10 бригадами, не могут сравнить цены.

Решение: Платформа, где заказчик оставляет заявку, а подрядчики откликаются с ценами и сроками. Как «Авито Услуги», но с фокусом на строительство и рейтингом по реальным объектам.

Целевая аудитория: Владельцы квартир в Москве, планирующие ремонт (30-50 лет, доход выше среднего).

Ключевые user stories (Must)

1. Как заказчик, хочу оставить заявку с описанием и фото объекта, чтобы получить предложения от подрядчиков
2. Как подрядчик, хочу видеть новые заявки в моём городе, чтобы откликнуться с ценой
3. Как заказчик, хочу сравнить отклики по цене, рейтингу и срокам, чтобы выбрать лучшего
4. Как заказчик, хочу оставить отзыв после завершения работ, чтобы помочь другим
5. Как подрядчик, хочу загрузить портфолио с фото объектов, чтобы привлекать заказчиков

Что НЕ входит в MVP

• Онлайн-оплата через платформу (только договорённость напрямую)
• Мобильное приложение (только адаптивный веб)
• Интеграция с 1С, CRM, ERP
• AI-подбор подрядчика
• Многоязычность

Обратите внимание: скоуп проекта жёстко ограничен. Нет попытки «сделать всё». MVP решает одну задачу — соединить заказчика с подрядчиком. Остальное — в следующих версиях.

Инструменты для написания ТЗ

Не усложняйте. Для большинства проектов достаточно стандартных инструментов.

Задача	Инструмент	Стоимость	Подходит для
Текст ТЗ	Google Docs / Notion	Бесплатно	Все проекты
Wireframes	Figma	Бесплатно (для 3 проектов)	Веб и мобильные
Wireframes (быстрые)	Balsamiq / Whimsical	$12-15/мес	Прототипы за час
User stories	Miro / FigJam	Бесплатно	Командная работа
Диаграммы	Draw.io / Excalidraw	Бесплатно	Архитектурные схемы
Управление требованиями	Jira / Linear	Бесплатно (до 10 чел.)	Крупные проекты

Если у вас нет опыта в Figma — рисуйте wireframes на бумаге и фотографируйте. Серьёзно. Фото wireframe на салфетке лучше, чем отсутствие wireframe. Главное — чтобы подрядчик понимал, что вы имеете в виду.

Шаблон структуры документа

Когда вы разобрались, как написать ТЗ для MVP, используйте следующий чек-лист для самопроверки. Каждый раздел — обязательный:

1. Описание продукта — проблема, аудитория, ценность (1 стр.)
2. User stories — с приоритетами Must/Should/Could (2-3 стр.)
3. Wireframes — 5-7 ключевых экранов (3-5 стр.)
4. Acceptance criteria — для каждой Must-истории (2-3 стр.)
5. Нефункциональные требования — производительность, безопасность, нагрузка (1 стр.)
6. Интеграции — платежи, email, аналитика (0.5-1 стр.)
7. Что НЕ входит — явно исключённый скоуп проекта (0.5 стр.)
8. Бюджет и сроки — ориентировочные рамки (0.5 стр.)

Итого: 10-15 страниц. Этого достаточно для оценки стоимости и старта разработки. Более объёмное техническое задание для MVP не нужно — вы потратите месяц на документ, который устареет ещё до начала работ.

Как подготовить ТЗ к передаче подрядчику

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

Проведите kick-off встречу

Не отправляйте ТЗ по email со словами «вот, посмотрите». Назначьте звонок на 1-1.5 часа и пройдитесь по документу вместе. Это обязательный шаг: даже хорошо написанное техническое задание для MVP оставляет место для интерпретаций.

На встрече фиксируйте вопросы. Если подрядчик не задаёт вопросов — это красный флаг. Значит, он либо не читал ТЗ, либо планирует «разобраться по ходу».

Зафиксируйте процесс изменений

ТЗ будет меняться — это нормально. Ненормально — менять его устно, в чатах, «между делом». Установите формальный процесс:

• Любое изменение оформляется как Change Request — отдельный документ с описанием, обоснованием и влиянием на сроки/бюджет
• Change Request утверждается обеими сторонами до начала работ
• Все утверждённые изменения вносятся в ТЗ с пометкой версии (v1.1, v1.2)

Без этого процесса вы получите scope creep — неконтролируемое расширение скоупа проекта, когда «ещё одна маленькая фича» превращается в +50% к бюджету.

Добавьте глоссарий

Если в проекте есть специфическая терминология (а она есть всегда), добавьте глоссарий в конец ТЗ. «Лот», «оффер», «лид», «воронка» — эти слова означают разное для маркетолога, разработчика и заказчика. Два абзаца с определениями экономят часы споров.