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

Почему неполное ТЗ — главный риск для бюджета проекта

Техническое задание на мобильное приложение — это не формальность для подписания договора, а юридически значимая часть проекта. В типовом договоре на разработку есть пункт, по которому объём работ определяется приложением «Техническое задание». Если в этом приложении прописано «реализовать каталог товаров с фильтрацией», но не указано, сколько фильтров, какого типа (чекбоксы, слайдеры, мультиселект), работает ли фильтрация офлайн — подрядчик реализует минимально возможный вариант. А за каждый дополнительный элемент потребует доплату по акту выполненных работ.

По данным отраслевых опросов 2024 года, проекты мобильной разработки с формализованным и детализированным ТЗ укладываются в бюджет в 78 % случаев. Проекты без детализированного ТЗ превышают бюджет в среднем на 40–60 %, а сроки сдвигаются на 2–4 месяца.

Что именно теряется при неполном ТЗ

• Контроль над бюджетом. Без чёткого перечня экранов и сценариев невозможно зафиксировать стоимость. Подрядчик начисляет часы на доработки, которые вы считали «входящими в ТЗ», а он — «дополнительными».

• Юридическая защита. Если дело дойдёт до суда или досудебной претензии, неполное ТЗ работает против заказчика. Суд принимает во внимание буквальное содержание документа, а не ваши ожидания.

• Качество результата. Без acceptance-критериев (критериев приёмки) вы не сможете объективно доказать, что работа выполнена некачественно. Фраза «приложение работает некорректно» не имеет юридической силы, если в ТЗ нет конкретных параметров.

---

Ключевые разделы, которые должны быть в качественном ТЗ

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

1. Спецификация экранов (Screen Specification)

Для каждого экрана должно быть указано:

• уникальное имя экрана;

• макет (wireframe или дизайн-макет в формате Figma, Sketch, XD);

• перечень элементов интерфейса с описанием поведения каждого (что происходит при нажатии, свайпе, долгом нажатии);

• состояния экрана: загрузка, ошибка, пустой контент, офлайн-режим.

Что проверять: сверьте количество экранов в ТЗ с макетами. Если в ТЗ написано «32 экрана», а в Figma-проекте 28 — это расхождение, которое выльется в пересмотр сроков. Типичная стоимость одного экрана с базовой логикой в 2024–2025 годах: 15 000–40 000 ₽ (Junior–Middle команда) или 40 000–120 000 ₽ (Senior, сложные интерактивы).

2. Спецификация бизнес-логики и сценариев (Use Cases / User Stories)

Каждый сценарий должен содержать:

• предусловие (что должно произойти до начала сценария);

• основной поток (happy path) — пошагово;

• альтернативные потоки (что происходит при ошибках, таймаутах, вводе некорректных данных);

• постусловие (состояние системы после завершения сценария).

Что проверять: если сценарий «Оформление заказа» описан одной строкой «Пользователь заполняет форму и нажимает кнопку "Оплатить"» — это не сценарий, а заголовок. Должны быть описаны: валидация полей, обработка ошибок платёжного шлюза, таймаут при нестабильном соединении, повторный запрос при потере связи.

3. Интеграции и API

Для каждого внешнего сервиса должно быть указано:

• название сервиса и версия API;

• эндпоинты, которые будут использоваться;

• формат авторизации (API-ключ, OAuth 2.0, JWT);

• лимиты запросов (rate limits);

• обработка ошибок сервиса (коды 4xx, 5xx);

• требования к кэшированию.

Что проверять: запросите у подрядчика ссылку на документацию каждого API. Если в ТЗ указано «интеграция с платёжной системой», но не названа конкретная (ЮKassa, Stripe, Robokassa, Tinkoff Pay) — это двусмысленность. Разные провайдеры отличаются по комиссиям: ЮKassa берёт 2,8–3,5 % от транзакции, Stripe — 2,9 % + 30 центов. Комиссия напрямую влияет на unit-экономику приложения.

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

• Производительность: время отклика основных экранов (например, загрузка каталога ≤ 2 секунды при соединении 4G).

• Масштабируемость: на какое количество одновременных пользователей рассчитана архитектура (например, 5 000, 50 000, 500 000).

• Безопасность: требования к шифрованию данных (TLS 1.2+), хранению токенов (Keychain/Keystore), обработке персональных данных в соответствии с 152-ФЗ.

• Поддерживаемые платформы и версии ОС: минимальные версии iOS и Android (например, iOS 15+, Android 10+).

• Офлайн-режим: какие данные кэшируются, как синхронизируются при восстановлении связи.

Что проверять: если в ТЗ написано «приложение должно быть быстрым» — это не требование. Требование — «экран каталога загружается за ≤ 1,5 секунды при соединении 4G и ≤ 3 секунды при 3G». Без измеримых метрик невозможно провести приёмку.

5. Дизайн и брендинг

• ссылка на гайдлайн (brand book);

• цветовые коды, типографика;

• иконки и сплеш-экран;

• тёмная/светлая тема (если предполагается);

• адаптивность под разные размеры экранов (от iPhone SE до iPad, от 5-дюймовых Android до планшетов).

6. Критерии приёмки (Acceptance Criteria)

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

• «Авторизация через SMS-код проходит за ≤ 10 секунд от момента отправки запроса до отображения главного экрана».

• «При потере соединения в процессе загрузки формы показывается баннер "Нет подключения к интернету" с кнопкой "Повторить"».

• «Push-уведомление о новом сообщении доставляется на устройство в течение 30 секунд при активном подключении».

---

Таблица проверки: критические параметры документа

Используйте эту таблицу как чек-лист: пройдитесь по каждому пункту и отметьте «✓» или «✗». Если в «Признак проблемы» стоит ситуация, которую вы обнаружили в вашем ТЗ — возвращайте документ подрядчику на доработку.

---

Скрытые ловушки: формулировки, которые ведут к допзатратам

«По аналогии с…»

Формулировка «Каталог товаров — по аналогии с Wildberries» выглядит конкретной, но юридически ничего не значит. Wildberries — это система из тысяч экранов, десятков микросервисов и сложнейшей бизнес-логики. Подрядчик реализует «аналогию» в своём понимании: одну карточку товара без вариантов, фильтрацию только по цене, без рекомендаций. А вы ожидаете фильтр по 15 параметрам, историю просмотров и AR-примерку.

Как исправить: опишите конкретно, какой именно функционал переносите. Например: «Экран каталога товаров содержит: сетку карточек (2 или 4 в ряд, переключение кнопкой), фильтрацию по цене (ползунок), категории (мультиселект до 5 значений), сортировку (по цене ↑↓, по рейтингу, по новизне)».

«Функционал будет дорабатываться по мере развития проекта»

Эта фраза в ТЗ означает, что подрядчик не знает (или не хочет прописывать) полный объём работ, а хочет получать оплату за итерации. Юридически она открывает дорогу бесконечным допсоглашениям.

Как исправить: если вы действительно планируете итеративную разработку, зафиксируйте: количество итераций (спринтов), содержание каждого спринта, стоимость каждого спринта, сроки. Каждый спринт — отдельное приложение к договору с конкретным перечнем работ.

«Базовая реализация», «Стандартный функционал»

«Базовая авторизация» — это что? Логин/пароль? SMS-код? OAuth через Google? Biometrics? У каждого подрядчика своё понимание «базового». Цена отличается в 3–5 раз.

Как исправить: замените каждое слово «базовый» и «стандартный» на конкретное описание. Если не знаете, какой вариант нужен — опишите бизнес-требование («нужно, чтобы пользователь мог войти за ≤ 15 секунд, не помня пароль»), а подрядчик предложит техническое решение. Но это решение тоже фиксируется в ТЗ.

«Тестирование включено в стоимость»

Без конкретизации это значит только ручное тестирование на одном устройстве разработчиком. Нагрузочное тестирование, тестирование на 15+ моделях устройств, автоматизированные тесты, security audit — всё это, как правило, оплачивается отдельно.

Как исправить: пропишите в ТЗ перечень устройств (минимум 5 моделей iOS и 10 моделей Android, включая бюджетные с 3 ГБ ОЗУ), виды тестирования и формат отчёта (список багов в Jira с приложенными скриншотами/видео).

Сроки без привязки к этапам

«Срок разработки — 4 месяца» — это не срок, а пожелание. Если нет разбивки на этапы с промежуточными дедлайнами, подрядчик может 3 месяца работать в «тихом режиме», а на последней неделе предъявить нерабочий прототип.

Как исправить: разбейте на этапы. Пример: «Этап 1 (4 недели): архитектура + каркас UI. Этап 2 (6 недель): основная бизнес-логика. Этап 3 (4 недели): интеграции. Этап 4 (2 недели): тестирование и исправление багов. Этап 5 (2 недели): публикация в сторах и стабилизация». Итого: 18 недель (≈ 4,5 месяца) с чёткими вехами.

---

Когда ТЗ считается готовым к подписанию

ТЗ готово к подписанию, когда одновременно выполнены все следующие условия:

1. Каждый экран имеет макет и описание поведения всех элементов. Проверьте: возьмите любой экран из ТЗ и попробуйте описать, что произойдёт при нажатии на каждый интерактивный элемент. Если не можете — экран не описан.

2. Каждый сценарий содержит основной поток и минимум 2 альтернативных. Сценарий «Оплата заказа» должен описывать: успешную оплату, ошибку платёжного шлюза, таймаут при обработке.

3. Все интеграции указаны с конкретными сервисами и версиями API. Если в ТЗ написано «SMS-рассылка» — какой провайдер? SMS.ru? SMS Aero? Twilio? Каждый отличается по цене (от 0,5 до 3,5 ₽ за SMS в зависимости от объёма) и по API.

4. Нефункциональные требования выражены в измеримых величинах. Цифры, а не прилагательные.

5. Критерии приёмки сформулированы так, что независимый тестировщик может по ним провести проверку. Если критерий невозможно проверить — он не работает.

6. ТЗ подписано обеими сторонами и является приложением к договору. Неподписанное ТЗ — это просто текстовый файл. Юридической силы не имеет.

Признаки того, что ТЗ ещё не готово

• В тексте есть фразы «TBD», «TODO», «будет уточнено».

• Более 30 % экранов не имеют макетов.

• Нет раздела «Критерии приёмки».

• Не указаны поддерживаемые версии ОС.

• Интеграции описаны без конкретных сервисов.

• Смета не разбита на этапы.

• Нет описания процесса передачи исходного кода.

---

Что может пойти не так, если подписать ТЗ с пропусками

Сценарий 1. «Дополнительные работы». Вы подписали ТЗ, где экран «Профиль пользователя» описан одной строкой. Подрядчик реализует: имя, аватар, кнопка выхода. Вы ожидали: история заказов, управление подписками, настройки уведомлений, привязка карт. Каждый элемент — допсоглашение. Итого: профиль стоит не 80 000 ₽, а 350 000 ₽.

Сценарий 2. «Срыв публикации в стор». В ТЗ не указано, кто проходит ревью Apple (Review Guidelines). Apple может отклонить приложение по 15+ пунктам (от навигации до обработки данных). Если в договоре нет обязательства подрядчика довести приложение до публикации — вы получите работающий код, который невозможно разместить в App Store.

Сценарий 3. «Подрядчик исчез с кодом». В договоре и ТЗ нет пункта о передаче исходного кода. Подрядчик передаёт вам сборку (.apk /.ipa), но не исходники. Для внесения изменений вам придётся либо снова обращаться к тому же подрядчику, либо писать всё с нуля. Стоимость повторной разработки — 100 % от первоначальной.

Сценарий 4. «Производительность не та». Приложение работает на флагманах, но на устройствах с 3 ГБ ОЗУ (а это до 35 % аудитории в России, по данным DeviceAtlas за 2024 год) экран каталога грузится 6 секунд. В ТЗ не было указано минимальное время отклика — формально подрядчик работу выполнил.

---

Кто должен готовить ТЗ — заказчик или подрядчик?

В идеале — совместно. Заказчик формулирует бизнес-требования (что должно уметь приложение и зачем), подрядчик переводит их в техническую спецификацию (как именно это будет реализовано). Если подрядчик готовит ТЗ самостоятельно, обязательно привлеките независимого технического специалиста для аудита. Стоимость экспертизы ТЗ у стороннего эксперта: 30 000–80 000 ₽ в зависимости от объёма документа. Это дешевле, чем один неучтённый интеграционный модуль.

Сколько страниц должно быть в хорошем ТЗ?

Для простого приложения (5–10 экранов, без сложных интеграций) — от 25 до 40 страниц. Для среднего (15–30 экранов, 2–3 интеграции) — 50–80 страниц. Для сложного (30+ экранов, платёжная система, геолокация, push, офлайн-режим) — 100–150+ страниц. Если вам дали 8-страничное ТЗ на приложение с каталогом, корзиной, оплатой и личным кабинетом — документ неполный.

Можно ли обойтись без ТЗ и работать по agile-методологии?

Можно, но с оговорками. Agile предполагает итеративную разработку, при которой требования уточняются по ходу. Однако базовое ТЗ (так называемое Product Requirements Document, PRD) нужно даже в agile: в нём зафиксированы бизнес-цели, приоритеты и ограничения. Без PRD спринты превращаются в хаотичную доработку по желанию заказчика, а бюджет растёт бесконтрольно. Минимальный компромисс: PRD на 10–15 страниц + детализация по спринтам.

Как проверить, не скопировал ли подрядчик ТЗ с другого проекта?

Признаки шаблонного ТЗ: общие формулировки без упоминания вашей бизнес-логики, названия сервисов-конкурентов (например, упоминание «Сбербанк» в вашем ТЗ, если вы работаете с Альфа-Банком), неактуальные версии API, отсутствие специфичных для вашего проекта экранов. Задайте подрядчику вопрос: «Почему в разделе авторизации указан вход через VK ID, если по нашим требованиям нужен вход через Яндекс ID?» — и смотрите на реакцию.

Нужно ли включать в ТЗ требования к админ-панели?

Да, обязательно, если приложение предполагает управляемый контент (каталог, новости, пользователи). Админ-панель — это отдельный продукт со своими экранами, правами доступа и сценариями. Если в ТЗ нет раздела про админку — вы получите приложение без возможности управлять им, и за каждый элемент управления потребуется отдельная доработка.

Что делать, если подрядчик отказывается вносить изменения в ТЗ?

Отказ вносить конкретику в ТЗ — это красный флаг. Честный подрядчик заинтересован в детальном ТЗ, потому что оно защищает и его: чёткий объём работ = чёткая цена = меньше споров. Если подрядчик настаивает на формулировках «базовый», «стандартный» и не хочет детализировать — вероятно, он планирует зарабатывать на допработах. Рассмотрите другого подрядчика.

Какой бюджет закладывать на непредвиденные расходы даже при хорошем ТЗ?

Практика показывает, что даже при идеальном ТЗ возникают допработы: обновление API внешнего сервиса, изменение требований стора, обнаружение ограничений на этапе реализации. Закладывайте резерв 15–20 % от стоимости проекта. При бюджете 3 000 000 ₽ — это 450 000–600 000 ₽ резерва.