Самая частая ошибка в ТЗ — отсутствие границ MVP и второй очереди функций. Она встретилась в 72% проанализированных документов.
ТЗ
ИССЛЕДОВАНИЕ APPFOX · 2026
Ошибки в техническом задании на разработку приложений и игр
Исследование AppFox на основе анализа технических заданий, клиентских брифов, коммерческих предложений, смет и проектных ретроспектив.
126
технических заданий в выборке
37%
выше риск перерасхода без формализованного ТЗ
10%
быстрее стартуют проекты с готовым ТЗ
Техническое задание не гарантирует идеальный проект, но снижает неопределённость. Чем точнее описаны цель продукта, пользователи, сценарии, роли, платформы, интеграции, backend, дизайн, безопасность и критерии готовности, тем точнее можно оценить стоимость, сроки и риски разработки.
AppFox проанализировала обезличенные данные по брифам и техническим заданиям на разработку мобильных приложений, игр, Telegram Mini Apps, VR/AR-проектов, e-commerce, сервисных приложений и цифровых продуктов для бизнеса, чтобы определить, какие ошибки в ТЗ чаще всего приводят к росту бюджета, задержкам, переделкам и спорным ситуациям.
Это исследование поможет заказчикам подготовиться к разработке, а командам — быстрее оценивать проекты и выявлять риски до старта.
КРАТКО
1
3
5
7
9
2
4
6
8
10
Главные выводы исследования
В 54% документов интеграции были указаны слишком общо: «подключить CRM», «синхронизация с 1С», «подключить оплату» — без API, статусов, ошибок, форматов данных и тестовой среды.
В 46% игровых ТЗ не было полноценного описания core gameplay, уровней, баланса, экономики или условий победы и поражения.
Проекты с подробным ТЗ оценивались на 30% точнее и реже выходили за бюджет, чем проекты с коротким брифом или устным описанием.
Самый рискованный тип формулировки — общая фраза без сценариев: «сделать личный кабинет», «добавить админку», «подключить оплату», «сделать игру как пример».
В 68% брифов не были описаны пользовательские роли: клиент, администратор, менеджер, партнёр, курьер, модератор или другие участники продукта.
В 72% проектов первоначальный MVP не был отделён от функций второй очереди, из-за чего объём первой версии увеличивался уже после старта.
В 49% брифов отсутствовали критерии готовности: заказчик описывал, что нужно сделать, но не фиксировал, как понять, что функция реализована корректно.
Чаще всего ошибки ТЗ влияли на backend, интеграции, UX/UI, QA и сроки согласований.
Хорошее ТЗ не должно быть длинным ради длины. Оно должно снижать неопределённость и фиксировать решения, которые влияют на стоимость, сроки и качество продукта.
Самые частые ошибки в ТЗ и брифах
| Ошибка в ТЗ или брифе | Доля документов | На что влияет | Последствие |
|---|---|---|---|
| Не описаны пользовательские роли | 68% | Backend, UX, QA | Переделка логики доступа |
| Нет границ MVP | 72% | Бюджет, сроки, скоуп | Функции добавляются после старта |
| Функции описаны слишком общо | 62% | Оценка, разработка | Команда уточняет требования в процессе |
| Не описаны интеграции | 54% | Backend, сроки, QA | API оказывается сложнее ожидаемого |
| Нет требований к админ-панели | 52% | Backend, UX, поддержка | Управление контентом добавляется позже |
| Нет сценариев ошибок | 50% | UX/UI, QA | Ошибки и пустые состояния появляются на тестировании |
| Не описаны платежи и возвраты | 48% | Backend, безопасность, QA | Платёжная логика дорабатывается отдельно |
| Не определены платформы | 45% | Архитектура, бюджет | Позже добавляются iOS, Android, Web, Telegram или PC |
| Нет требований к безопасности | 31% | Backend, юридические риски | Защита данных добавляется после оценки |
| Нет критериев готовности | 49% | Согласование, QA | Споры о том, завершена ли функция |
| Не описан контент | 41% | Дизайн, игры, e-commerce | Тексты, изображения, уровни и ассеты задерживают проект |
| Нет GDD для игры | 46% | Геймдизайн, баланс, QA | Механика меняется уже в разработке |
| Не описана аналитика | 43% | Продуктовые метрики | События и отчёты добавляются после релиза |
| Нет приоритетов функций | 57% | MVP, бюджет | В первую версию попадает слишком много задач |
| Нет ответственного за согласования | 39% | Сроки | Решения принимаются медленно |
МЕТОДОЛОГИЯ
Методология
- Период анализа
- январь 2024 — июнь 2026
- Выборка
- 126 технических заданий, 143 клиентских брифа, 96 коммерческих предложений, 104 сметы и 72 проектные ретроспективы
- Важно
- Ошибкой считалась не любая неполнота документа, а такая неопределённость, которая могла повлиять на стоимость, сроки, архитектуру, backend, интеграции, QA или объём доработок после старта.
Вошло в выборку
- MVP мобильных приложений
- приложения для бизнеса
- e-commerce приложения
- сервисные приложения
- приложения с backend и личным кабинетом
- мобильные 2D-игры
- мобильные 3D-игры
- браузерные игры
- Telegram Mini Apps
- промо-игры
- образовательные и детские игры
- VR/AR-проекты
- PC-игры
- проекты с геймификацией
- проекты с AI-функциями
- проекты с внешними интеграциями
- проекты с платежами
- проекты с админ-панелью
Не включалось
- документы без даты
- документы без понятного типа проекта
- внутренние черновики без связи с реальной оценкой
- проекты, по которым невозможно обезличить данные
- разовые задачи без полного цикла разработки
- проекты только на поддержку без разработки новой функциональности
- документы, где ТЗ было подготовлено уже после завершения проекта
МЕТОДОЛОГИЯ
Что считалось техническим заданием
В исследовании техническим заданием считался документ, который описывает не только идею, но и требования к продукту.
В полноценном ТЗ должны быть:
| Раздел | Что должен описывать |
|---|---|
| Цель продукта | Зачем создаётся приложение или игра |
| Целевая аудитория | Кто будет пользоваться продуктом |
| Пользовательские роли | Какие типы пользователей есть в системе |
| Функции | Что должен делать продукт |
| Сценарии | Как пользователь проходит путь от входа до результата |
| Платформы | iOS, Android, Web, Telegram, PC, VR/AR |
| Backend | Данные, роли, статусы, бизнес-логика |
| Интеграции | CRM, 1C, платежи, карты, API, аналитика |
| Дизайн | UX/UI, адаптивность, брендбук, состояния |
| Безопасность | Персональные данные, права, доступы, шифрование |
| Контент | Тексты, изображения, уровни, модели, аудио |
| QA | Что и как нужно тестировать |
| Критерии готовности | Как понять, что функция реализована |
| Ограничения | Сроки, бюджет, технологии, юридические требования |
| Приоритеты | Что входит в MVP, а что переносится дальше |
Короткий бриф не является полноценным ТЗ, но может быть достаточным для предварительной оценки, если он честно фиксирует уровень неопределённости.
МЕТОДОЛОГИЯ
Что считалось ошибкой ТЗ
Ошибкой считалась не любая неполнота документа, а такая неопределённость, которая могла повлиять на:
- стоимость
- сроки
- состав команды
- архитектуру
- UX/UI
- backend
- интеграции
- QA
- безопасность
- публикацию
- поддержку
- объём доработок после старта
Пример. Фраза нужен личный кабинет сама по себе недостаточна. Для оценки нужно понимать, какие данные есть в кабинете, какие роли пользователя существуют, какие действия доступны, какие ограничения и какие состояния нужно реализовать.
МЕТОДОЛОГИЯ
Почему ошибки в ТЗ влияют на бюджет и сроки
ТЗ — это не формальность. Оно определяет границы проекта. Если границы не описаны, команда оценивает проект по предположениям. Чем больше предположений, тем выше риск, что реальный объём работ окажется больше стартовой оценки.
Как неполное ТЗ влияет на проект
| Ошибка | Что происходит в проекте |
|---|---|
| Не описана роль пользователя | Приходится менять backend и интерфейс |
| Не описан сценарий | UX и логика строятся на догадках |
| Не описана интеграция | API оценивается слишком поверхностно |
| Не описан MVP | В первую версию попадает лишний функционал |
| Не описаны ошибки | QA выявляет новые состояния |
| Не описан контент | Разработка ждёт материалы |
| Не описана безопасность | Появляются дополнительные проверки |
| Не описаны критерии готовности | Возникают споры при приёмке |
ОШИБКА 1
Нет границ MVP
Одна из самых частых ошибок — отсутствие чёткой границы между первой версией и будущим развитием продукта.
Плохо
Нужно сделать приложение для доставки еды с каталогом, оплатой, акциями, личным кабинетом, программой лояльности, отзывами, пушами, чатом с поддержкой, аналитикой, курьерским приложением и админкой.
Лучше
MVP включает:
1. Каталог ресторанов.
2. Карточку блюда.
3. Корзину.
4. Оформление заказа.
5. Онлайн-оплату.
6. Личный кабинет клиента.
7. Простую админ-панель для управления заказами.
Во вторую очередь переносятся:
1. Программа лояльности.
2. Отзывы.
3. Чат с поддержкой.
4. Курьерское приложение.
5. Расширенная аналитика.
Как отсутствие MVP влияет на проект
| Проблема | Последствие |
|---|---|
| Нет приоритетов | Все функции кажутся обязательными |
| Нет границы первой версии | Скоуп растёт после старта |
| Нет списка второй очереди | Невозможно управлять ожиданиями |
| Нет критерия успеха MVP | Непонятно, что именно проверяет продукт |
| Нет продуктового фокуса | Бюджет расходуется на второстепенные функции |
ОШИБКА 2
Не описаны пользовательские роли
Если в ТЗ не описаны роли, команда не может точно оценить права доступа, сценарии, backend и тестирование.
Примеры ролей
- гость
- зарегистрированный пользователь
- клиент
- администратор
- менеджер
- модератор
- курьер
- продавец
- партнёр
- преподаватель
- ученик
- игрок
- клан-лидер
- оператор поддержки
Плохо
Пользователь должен видеть свои заказы.
Лучше
В системе есть 3 роли:
1. Клиент: регистрируется, оформляет заказ, оплачивает, видит статус, получает push.
2. Менеджер: видит все заказы, меняет статус, связывается с клиентом, добавляет комментарий.
3. Администратор: управляет пользователями, управляет каталогом, видит отчёты, назначает менеджеров.
Почему роли важны
| Что зависит от ролей | Почему это влияет на оценку |
|---|---|
| Backend | Нужны права доступа и правила |
| UX/UI | У каждой роли свои экраны |
| QA | Нужно тестировать разные сценарии |
| Безопасность | Нельзя показывать чужие данные |
| Админ-панель | Нужны инструменты управления |
| Аналитика | Метрики могут отличаться по ролям |
ОШИБКА 3
Функции описаны слишком общо
Общие формулировки создают иллюзию понятного проекта, но не дают данных для оценки.
Примеры плохих и хороших формулировок
| Плохо | Лучше |
|---|---|
| Сделать личный кабинет | Описать разделы кабинета, поля, действия, роли и ограничения |
| Подключить оплату | Указать провайдера, способы оплаты, возвраты, статусы, ошибки |
| Добавить чат | Указать тип чата: 1:1, групповой, вложения, модерация, уведомления |
| Сделать админку | Описать сущности, права, фильтры, отчёты и действия |
| Сделать как Uber | Описать конкретные сценарии, а не ссылаться на большой продукт |
| Добавить аналитику | Указать события, цели, отчёты и систему аналитики |
| Сделать игру как пример | Описать механику, уровни, управление, победу, поражение и баланс |
Что должно быть у каждой функции
| Поле | Что описывать |
|---|---|
| Название функции | Что это за функция |
| Цель | Зачем она нужна пользователю или бизнесу |
| Пользователь | Какая роль использует функцию |
| Сценарий | Последовательность действий |
| Данные | Какие поля, объекты и статусы нужны |
| Ошибки | Что происходит при неудаче |
| Ограничения | Лимиты, права, условия |
| Интеграции | Какие внешние системы участвуют |
| Критерий готовности | Как проверить, что функция работает |
ОШИБКА 4
Не описаны backend и админ-панель
Заказчик часто видит продукт через интерфейс, но значительная часть работы находится в backend и административной части.
Плохо
Нужна админка.
Лучше
Админ-панель должна позволять:
1. Управлять пользователями: смотреть список, искать по телефону и email, блокировать, менять роль.
2. Управлять заказами: смотреть список, фильтровать по статусу, менять статус, добавлять комментарий.
3. Управлять каталогом: создавать товар, редактировать цену, менять остатки, скрывать товар.
4. Смотреть отчёты: количество заказов, сумма продаж, активные пользователи, выгрузка CSV.
Что нужно описать в backend
| Блок | Что указать |
|---|---|
| Пользователи | Роли, права, профили |
| Данные | Какие объекты хранятся |
| Статусы | Как меняются состояния |
| Бизнес-правила | Что можно и нельзя делать |
| Админ-панель | Какие сущности управляются |
| Логи | Что нужно записывать |
| Уведомления | Когда и кому отправляются |
| Интеграции | Какие системы участвуют |
| Безопасность | Доступы, ограничения, персональные данные |
| Аналитика | Какие события фиксируются |
ОШИБКА 5
Не описаны интеграции
Интеграции часто становятся источником перерасхода, потому что в ТЗ они указаны слишком общо.
Плохо
Интеграция с CRM.
Лучше
Интеграция с CRM включает:
1. Передачу лида из приложения в CRM.
2. Получение статуса заявки из CRM.
3. Обновление статуса в приложении.
4. Обработку ошибок передачи.
5. Логирование запросов.
6. Повторную отправку при сбое.
7. Использование тестового API-контура.
8. Ответственного за API на стороне клиента.
Что нужно указать для каждой интеграции
| Поле | Что описать |
|---|---|
| Название системы | CRM, 1C, банк, карта, аналитика |
| Назначение | Зачем нужна интеграция |
| Направление обмена | В одну сторону или двусторонне |
| Данные | Какие поля передаются |
| Частота | В реальном времени, по расписанию, вручную |
| API | Есть ли документация |
| Тестовый контур | Есть ли sandbox |
| Ошибки | Что делать при сбое |
| Логи | Что записывать |
| Ответственный | Кто отвечает за доступы и API |
ОШИБКА 6
Не описаны платежи
Платежи — это не только кнопка «Оплатить». Нужно учитывать статусы, ошибки, возвраты, чеки, безопасность и сценарии пользователя.
Что нужно описать для платежей
| Блок | Примеры |
|---|---|
| Способы оплаты | Карта, СБП, Apple Pay / Google Pay, внутренний баланс |
| Провайдер | Банк, эквайринг, платёжный шлюз |
| Статусы | Создан, оплачен, отменён, возврат, ошибка |
| Ошибки | Недостаточно средств, отмена, таймаут, сбой |
| Возвраты | Полный, частичный, ручной, автоматический |
| Чеки | Касса, фискализация, email |
| Безопасность | Хранение токенов, персональные данные |
| Уведомления | Push, email, SMS |
| Админ-панель | Просмотр платежей, статусы, возвраты |
| Тестирование | Тестовые карты, sandbox, негативные сценарии |
Плохо
Подключить оплату.
Лучше
Подключить оплату через ЮKassa. Поддержать карту и СБП. После оплаты — статус заказа. При ошибке — понятное сообщение. Администратор видит статус платежа. Нужна возможность полного возврата.
ОШИБКА 7
Не описаны ошибки, пустые состояния и edge cases
Многие ТЗ описывают только идеальный сценарий. Но реальный продукт должен работать и в нестандартных ситуациях.
Примеры состояний, которые часто забывают
| Состояние | Пример |
|---|---|
| Ошибка сети | Пользователь потерял интернет |
| Пустой список | Нет заказов, товаров, сообщений |
| Ошибка оплаты | Платёж отклонён |
| Нет доступа | Пользователь не имеет прав |
| Истёкшая сессия | Нужно войти заново |
| Неверные данные | Ошибка в форме |
| Сервис недоступен | API не отвечает |
| Дубликат действия | Пользователь нажал кнопку дважды |
| Частичный успех | Заказ создан, но уведомление не отправлено |
| Конфликт данных | Статус изменился одновременно в двух системах |
Если ошибки не описаны в ТЗ, они появляются на этапе QA или после релиза. Тогда приходится дорабатывать UX, backend, тексты, тесты и иногда бизнес-логику.
ОШИБКА 8
Не определены платформы и устройства
Платформы влияют на архитектуру, дизайн, разработку, QA и публикацию.
Что нужно указать
| Параметр | Примеры |
|---|---|
| Платформы | iOS, Android, Web, Telegram, PC, VR |
| Версии ОС | Минимальная версия iOS / Android |
| Устройства | Смартфоны, планшеты, desktop, VR-шлемы |
| Ориентация | Портретная, альбомная, обе |
| Браузеры | Chrome, Safari, Firefox, Edge |
| Сторы | App Store, Google Play, RuStore, Steam |
| Доступность | Нужна ли адаптация для людей с ограничениями |
| Производительность | Ограничения по FPS, загрузке, памяти |
| Offline | Нужно ли работать без интернета |
Плохо
Сделать мобильное приложение.
Лучше
Первая версия: Android 10+ и iOS 15+. Планшеты не входят в MVP. Ориентация — портретная. Публикация — Google Play и RuStore. App Store — во второй фазе.
ОШИБКА 9
Не описаны требования к безопасности
Безопасность часто добавляют поздно, когда архитектура уже выбрана. Это повышает стоимость изменений.
Что нужно описать
| Блок | Примеры |
|---|---|
| Персональные данные | Какие данные собираются |
| Авторизация | Телефон, email, соцсети, SSO |
| Права доступа | Кто что может видеть и менять |
| Шифрование | Какие данные защищаются |
| Логи | Что записывается |
| Хранение данных | Где и как хранятся |
| Удаление данных | Как пользователь удаляет аккаунт |
| Админ-доступ | Кто может управлять пользователями |
| Аудит действий | Нужно ли хранить историю изменений |
| Юридические требования | Согласия, политика, обработка данных |
ОШИБКА 10
Не описаны критерии готовности
Критерии готовности помогают команде и заказчику одинаково понимать, когда функция завершена.
Плохо
Сделать регистрацию.
Лучше
Регистрация считается готовой, если:
1. Пользователь вводит номер телефона.
2. Получает SMS-код.
3. Вводит код.
4. При верном коде попадает в личный кабинет.
5. При неверном коде видит ошибку.
6. Повторный запрос кода доступен через 60 секунд.
7. Сценарий протестирован на iOS и Android.
8. Событие регистрации отправляется в аналитику.
Что должно быть в критериях готовности
| Критерий | Пример |
|---|---|
| Основной сценарий | Пользователь может выполнить действие |
| Ошибки | Ошибки обрабатываются корректно |
| Роли | Доступы работают по ролям |
| Данные | Данные сохраняются и отображаются |
| Интеграции | Внешние системы получают нужные данные |
| QA | Сценарий протестирован |
| Аналитика | События отправляются |
| Документация | Функция описана для поддержки |
ИГРОВЫЕ ПРОЕКТЫ
Ошибки в игровых ТЗ и GDD
Для игр обычного ТЗ часто недостаточно. Нужен GDD — game design document, который описывает механику, правила, игровой цикл, уровни, экономику, контент и баланс.
Частые ошибки в игровых документах
| Ошибка | Последствие |
|---|---|
| Не описан core gameplay | Механику приходится искать в процессе |
| Нет условий победы и поражения | Непонятно, как завершается игровой цикл |
| Нет описания уровней | Нельзя оценить объём контента |
| Нет баланса | Требуются дополнительные итерации |
| Нет экономики | Монетизация и прогрессия добавляются позже |
| Нет описания персонажей | Арт и анимация оцениваются неточно |
| Нет туториала | Пользователь не понимает игру |
| Нет требований к устройствам | Возникают проблемы производительности |
| Нет описания multiplayer | Backend и синхронизация недооцениваются |
| Нет live ops-плана | Поддержка после релиза не учитывается |
Что должно быть в GDD
| Раздел | Что описать |
|---|---|
| Жанр | Аркада, пазл, RPG, симулятор, runner |
| Целевая аудитория | Кто будет играть |
| Core gameplay | Основной игровой цикл |
| Управление | Касания, свайпы, клавиатура, геймпад |
| Победа и поражение | Когда игрок выигрывает или проигрывает |
| Уровни | Количество, структура, сложность |
| Персонажи | Роли, способности, анимации |
| Арт-стиль | 2D, 3D, референсы, качество |
| Экономика | Валюта, награды, прогрессия |
| Монетизация | Реклама, покупки, подписка |
| Звук | Музыка, эффекты, озвучка |
| QA | Устройства, сценарии, баланс |
| Публикация | Сторы, возрастные ограничения |
| Live ops | События, сезоны, обновления |
ТИПЫ ПРОЕКТОВ
Как ошибки ТЗ отличаются по типам проектов
| Тип проекта | Самые частые ошибки | На что влияет |
|---|---|---|
| MVP приложения | Нет границ MVP, нет приоритетов | Бюджет, сроки, скоуп |
| Бизнес-приложение | Не описаны роли и статусы | Backend, UX, QA |
| E-commerce | Не описаны каталог, остатки, оплата, возвраты | Интеграции, backend |
| Сервисное приложение | Не описаны заявки, workflow и уведомления | Логика, backend |
| Telegram Mini App | Не описана связка Mini App + бот + backend | Архитектура |
| Промо-игра | Нет механики, рейтинга, защиты от накруток | Геймдизайн, QA |
| 2D-игра | Не описаны уровни, арт и баланс | Контент, сроки |
| 3D-игра | Не описаны модели, анимации, оптимизация | Бюджет, QA |
| Online-игра | Не описаны сервер, matchmaking, античит | Backend, нагрузка |
| VR/AR | Не описаны устройства, 3D и трекинг | Тестирование, оптимизация |
| AI-проект | Не описаны данные, модель, качество ответа | R&D, безопасность |
ОЦЕНКА КАЧЕСТВА
Как оценивать качество ТЗ
AppFox использует шкалу готовности ТЗ к оценке. Её можно применять до передачи документа подрядчику.
Шкала готовности ТЗ
| Уровень | Описание | Что можно сделать |
|---|---|---|
| 0% | Есть только идея | Нужна продуктовая консультация |
| 25% | Есть краткий бриф | Можно дать грубую вилку |
| 50% | Есть список функций | Можно оценить основные блоки |
| 75% | Есть роли, сценарии, платформы, интеграции | Можно готовить детальную смету |
| 90% | Есть UX, backend, критерии готовности, ограничения | Можно планировать разработку |
| 100% | Есть полное ТЗ, макеты, API, контент, критерии приёмки | Можно запускать проект с минимальной неопределённостью |
Таблица самопроверки
| Вопрос | Да / Нет |
|---|---|
| Описана цель продукта? | Да / нет |
| Описана целевая аудитория? | Да / нет |
| Есть список пользовательских ролей? | Да / нет |
| Есть список функций MVP? | Да / нет |
| Есть список функций второй очереди? | Да / нет |
| Описаны основные сценарии? | Да / нет |
| Описаны ошибки и пустые состояния? | Да / нет |
| Описаны платформы и устройства? | Да / нет |
| Описан backend? | Да / нет |
| Описана админ-панель? | Да / нет |
| Описаны интеграции? | Да / нет |
| Есть API-документация? | Да / нет |
| Описаны платежи? | Да / нет |
| Описана безопасность? | Да / нет |
| Описана аналитика? | Да / нет |
| Есть критерии готовности? | Да / нет |
| Назначен ответственный за согласования? | Да / нет |
ШАБЛОНЫ
Минимальный шаблон брифа на разработку приложения
Если полноценного ТЗ пока нет, для первичной оценки можно подготовить бриф.
1. Описание продукта
- Что нужно разработать?
- Для кого продукт?
- Какую бизнес-задачу он решает?
- Какие есть аналоги или референсы?
2. Целевая аудитория
- Кто будет пользоваться продуктом?
- Какие проблемы у этих пользователей?
- Какие устройства они используют?
3. Платформы
- iOS
- Android
- Web
- Telegram Mini App
- PC
- VR/AR
- Другая платформа
4. Пользовательские роли
- Гость
- Пользователь
- Клиент
- Администратор
- Менеджер
- Партнёр
- Другая роль
5. Функции MVP
- Какие функции обязательно нужны в первой версии?
- Что можно перенести во вторую очередь?
- Что точно не входит в MVP?
6. Интеграции
- CRM
- 1C
- Платежи
- Карты
- SMS
- Push
- Аналитика
- Внешние API
7. Дизайн
- Есть ли брендбук?
- Есть ли готовые макеты?
- Нужен ли UX-прототип?
- Есть ли референсы?
8. Backend и админ-панель
- Какие данные нужно хранить?
- Кто управляет контентом?
- Какие отчёты нужны?
- Какие роли есть в админке?
9. Сроки и бюджет
- Есть ли жёсткая дата запуска?
- Есть ли бюджетный диапазон?
- Что важнее: срок, стоимость или полный функционал?
10. Критерии успеха
- Как понять, что MVP успешен?
- Какие метрики нужно отслеживать?
- Что должно произойти после запуска?
ШАБЛОНЫ
Минимальный шаблон GDD для игры
1. Концепция игры
- Жанр
- Целевая аудитория
- Платформы
- Референсы
- Ключевая идея
2. Core gameplay
- Что игрок делает каждую игровую сессию?
- Как начинается игровой цикл?
- Как он завершается?
- Что мотивирует продолжать?
3. Управление
- Свайпы
- Касания
- Кнопки
- Геймпад
- Клавиатура
- VR-контроллеры
4. Условия победы и поражения
- Как игрок выигрывает?
- Как проигрывает?
- Есть ли очки, таймер, здоровье, энергия?
5. Уровни и прогрессия
- Сколько уровней в MVP?
- Как растёт сложность?
- Что открывается по мере прохождения?
6. Арт и анимация
- 2D или 3D
- Персонажи
- Окружение
- UI
- Эффекты
- Анимации
- Референсы качества
7. Экономика и монетизация
- Валюта
- Награды
- Покупки
- Реклама
- Подписки
- Боевой пропуск
8. Backend
- Аккаунты
- Сохранения
- Лидерборды
- Матчмейкинг
- PvP
- Античит
- Аналитика
9. QA и оптимизация
- Устройства
- FPS
- Память
- Сетевые сценарии
- Баланс
- Регресс
10. Публикация и поддержка
- Сторы
- Возрастной рейтинг
- Метаданные
- Иконки
- Скриншоты
- Live ops
- Обновления
ДЛЯ ПОДРЯДЧИКОВ
Как подрядчик должен работать с неполным ТЗ
Неполное ТЗ — не повод сразу отказываться от проекта. Но важно честно зафиксировать уровень неопределённости.
Правильный процесс
Бриф → выявление пробелов → список вопросов → оценка рисков → уточнение требований → предварительная оценка → детальная смета
Что должен сделать подрядчик
| Действие | Зачем |
|---|---|
| Задать уточняющие вопросы | Снизить неопределённость |
| Показать риски | Предупредить рост бюджета |
| Разделить MVP и вторую очередь | Управлять скоупом |
| Описать допущения | Зафиксировать, на чём основана оценка |
| Выделить неизвестные блоки | Не скрывать сложность |
| Предложить этап аналитики | Подготовить проект к разработке |
| Зафиксировать change request | Управлять изменениями после старта |
ПРИМЕРЫ
Примеры: как переписать плохие требования
Пример 1. Личный кабинет
Плохо: Сделать личный кабинет.
Лучше: Кабинет включает профиль (имя, телефон, email), историю заказов, статус текущего заказа, настройки push, кнопку выхода. Пользователь может изменить имя, email, посмотреть заказ, повторить заказ, выйти. Администратор может просмотреть, заблокировать, изменить роль.
Пример 2. Оплата
Плохо: Добавить оплату.
Лучше: Оплата через ЮKassa. Карта и СБП. После оплаты заказ получает статус «Оплачен». При ошибке — понятное сообщение. При отмене — возможен полный возврат. Администратор видит платежи и статусы в панели.
Пример 3. Интеграция с CRM
Плохо: Интеграция с CRM.
Лучше: После отправки формы заявка с полями (имя, телефон, email, источник, комментарий, услуга) передаётся в CRM. CRM возвращает ID и статус. При ошибке — повторная отправка через 5 минут.
Пример 4. Игра
Плохо: Сделать игру как Subway Surfers, только проще.
Лучше: Жанр runner, Android и iOS. Управление свайпами. Цель — пройти дальше и собрать монеты. MVP: 1 персонаж, 3 типа препятствий, 1 окружение, таблица рекордов, базовая экономика. Не в MVP: магазин, задания, PvP, сезоны.
ДАННЫЕ
Как наличие ТЗ влияет на оценку проекта
Проекты с ТЗ и без ТЗ
| Показатель | Проекты с подробным ТЗ | Проекты с кратким брифом | Разница |
|---|---|---|---|
| Точность оценки бюджета | 87% | 61% | +26 п.п. |
| Точность оценки сроков | 82% | 58% | +24 п.п. |
| Доля проектов с перерасходом | 18% | 43% | -25 п.п. |
| Среднее число change request | 2,1 | 5,4 | -3,3 |
| Количество уточняющих вопросов | 12 | 34 | -22 |
| Средний срок пресейла | 9 дней | 5 дней | +4 дня |
Вывод: подробное ТЗ не всегда сокращает время подготовки проекта, но повышает точность оценки и снижает риск переделок после старта.
ЧЕК-ЛИСТ
Чек-лист хорошего ТЗ
Перед передачей ТЗ подрядчику проверьте, есть ли в документе:
- цель продукта
- бизнес-задача
- целевая аудитория
- список платформ
- пользовательские роли
- карта пользовательских сценариев
- список функций MVP
- список функций второй очереди
- описание backend
- описание админ-панели
- описание интеграций
- API-документация или контакт ответственного за API
- требования к платежам
- требования к безопасности
- требования к аналитике
- требования к UX/UI
- брендбук или визуальные референсы
- описание ошибок и пустых состояний
- требования к контенту
- требования к QA
- критерии готовности
- ограничения по срокам
- бюджетный диапазон
- ответственный за согласования
- порядок внесения изменений после старта
ВЫВОДЫ
Выводы исследования
Главные выводы для заказчиков
Хорошее ТЗ снижает неопределённость.
Оно не должно описывать каждую мелочь, но должно фиксировать решения, влияющие на бюджет, сроки и архитектуру.Самые дорогие пробелы — backend, интеграции, роли и MVP.
Именно эти блоки чаще всего оказываются сложнее, чем выглядели в первоначальном брифе.Общие формулировки опасны.
Фразы «личный кабинет», «админка», «оплата», «интеграция» и «игра как пример» требуют расшифровки.Игровым проектам нужен GDD.
Без описания механик, уровней, баланса, арта и экономики игру невозможно точно оценить.Критерии готовности защищают обе стороны.
Они помогают понять, когда функция реализована и что именно будет приниматься.ТЗ должно отделять MVP от будущего развития.
Если всё считается обязательным, проект становится дороже и дольше.Неполное ТЗ не запрещает старт, но требует этапа аналитики.
Если требований мало, сначала нужно уточнить продукт, а не сразу начинать разработку.Главные выводы для бизнеса
Техническое задание — это инструмент управления рисками. Оно помогает заранее определить:
- что именно разрабатывается
- для кого создаётся продукт
- какие функции входят в MVP
- какие функции откладываются
- какие платформы нужны
- какие роли пользователей существуют
- какие интеграции критичны
- какие требования есть к backend
- что нужно тестировать
- как будет приниматься результат
- что считается изменением требований
Чем понятнее ТЗ, тем ниже риск перерасхода, задержек и переделок.
ГЛАВНЫЙ ВЫВОД
Большинство ошибок в ТЗ связано не с техническими деталями, а с неопределённостью продукта: кто пользователь, что он делает, какие есть ограничения, какие сценарии критичны и что считается готовым результатом.ИНФОГРАФИКА
Ключевые данные
Данные основаны на обезличенной выборке AppFox и округлены для публикации
Частота ошибок в ТЗ по категориям
Доля проектов, где встречалась ошибка · данные исследования, %
Нет границ MVP
72%
Не описаны роли
68%
Функции описаны общо
62%
Нет описания backend
58%
Не описаны интеграции
54%
Нет критериев приёмки
49%
050%
Диапазон (мин – макс)Медиана· %
Как ошибки в ТЗ влияют на проект
Распределение последствий ошибок · данные исследования, %
Рост бюджета 32%
Задержка сроков 28%
Переделки 22%
Споры при приёмке 12%
Прочее 6%
Частые вопросы
Зачем нужно техническое задание?
ТЗ нужно, чтобы зафиксировать требования к продукту, снизить неопределённость, точнее оценить стоимость и сроки, уменьшить риск переделок и упростить приёмку результата.
Можно ли начать разработку без ТЗ?
Можно начать с короткого брифа или этапа аналитики, но полноценную разработку без описанных требований начинать рискованно. Если ТЗ нет, команда будет уточнять продукт в процессе, что увеличивает риск изменения бюджета и сроков.
Что важнее: ТЗ или дизайн?
Это разные документы. ТЗ описывает логику, функции, роли, интеграции и ограничения. Дизайн показывает, как продукт будет выглядеть и как пользователь будет проходить сценарии. Для точной оценки нужны оба слоя.
Чем бриф отличается от ТЗ?
Бриф кратко описывает идею, цели, аудиторию, платформы и примерный функционал. ТЗ подробно фиксирует сценарии, роли, требования, интеграции, backend, ограничения и критерии готовности.
Что такое хорошее ТЗ?
Хорошее ТЗ не обязательно очень длинное. Оно должно быть точным, структурированным и полезным для оценки. Главное — описать то, что влияет на бюджет, сроки, архитектуру и качество.
Что чаще всего забывают в ТЗ?
Чаще всего забывают пользовательские роли, границы MVP, интеграции, backend, админ-панель, ошибки, пустые состояния, платёжные сценарии, требования к безопасности, критерии готовности и контент.
Нужно ли ТЗ для игры?
Да. Для игры нужен не только список функций, но и GDD: жанр, core gameplay, управление, уровни, арт, баланс, экономика, монетизация, QA и требования к производительности.
Кто должен писать ТЗ?
ТЗ может писать заказчик, аналитик подрядчика или обе стороны совместно. Хороший вариант — заказчик описывает бизнес-цели и ограничения, а команда разработки помогает превратить это в технически проверяемый документ.
Что делать, если есть только идея?
Начать с discovery / аналитики: описать целевую аудиторию, сценарии, MVP, платформы, роли, интеграции и ограничения. После этого можно переходить к оценке и разработке.
Как понять, что ТЗ готово к оценке?
ТЗ готово к оценке, если по нему можно понять: кто пользователь, что он делает, какие функции входят в MVP, какие платформы нужны, какие есть интеграции, что должен делать backend, как проверять готовность и какие ограничения есть у проекта.
ОБ ИССЛЕДОВАНИИ
Об исследовании
Название
Ошибки в технических заданиях и брифах на разработку приложений и игр: исследование AppFox 2026Автор
AppFox ResearchПериод анализа
январь 2024 — июнь 2026Дата публикации
15 июня 2026Дата обновления
9 июля 2026Выборка
126 технических заданий, 143 клиентских брифа, 96 коммерческих предложений, 104 сметы и 72 проектные ретроспективыТемы
техническое задание, бриф, разработка приложений, разработка игр, MVP, GDD, backend, интеграции, QA, оценка проектаКонтакты для СМИ
info@appfox.ruДИСКЛЕЙМЕР
Дисклеймер
Данные исследования отражают обезличенную статистику технических заданий, брифов, смет и проектных ретроспектив AppFox за указанный период. Влияние ТЗ на конкретный проект может отличаться в зависимости от состава работ, платформ, интеграций, команды, сроков и условий договора.
Материал не является публичной офертой. Для точной оценки проекта требуется анализ требований, пользовательских сценариев, технических ограничений, интеграций и бизнес-целей.
КАК ЦИТИРОВАТЬ ЭТО ИССЛЕДОВАНИЕ
info@appfox.ru
AppFox. Ошибки в технических заданиях: анализ брифов и ТЗ. AppFox Research, 2026. URL: https://appfox.ru/research/tz/
