Разработка приложения почти никогда не дорожает из-за жадности подрядчика. Она дорожает из-за формулировок вроде «личный кабинет» и «интеграция с 1С», за которыми у заказчика и исполнителя стоят разные объёмы работ. Техническое задание нужно ровно для того, чтобы эти расхождения всплыли до договора, а не на третьем месяце.
Зачем ТЗ, если есть прототип
Прототип показывает экраны, но не отвечает на вопросы, из которых складывается смета: что происходит при отсутствии сети, какие роли есть у пользователей, откуда берутся данные каталога, кто отвечает за серверную часть. Прототип и ТЗ дополняют друг друга: по прототипу считают дизайн, по ТЗ считают логику.
Структура, которая работает
1. Цель продукта и метрика успеха. Одно предложение о том, зачем бизнесу приложение, и одна измеримая метрика: доля повторных заказов, число обращений в поддержку, среднее время оформления. Без этого раздела приложение обрастает функциями, которые никто не заказывал.
2. Роли и сценарии. Перечислите типы пользователей (гость, зарегистрированный клиент, администратор, курьер) и по каждому опишите основные сценарии по шагам. Сценарий это не «пользователь оформляет заказ», а последовательность экранов и действий с указанием, что происходит при ошибке.
3. Платформы и минимальные версии. iOS и Android, минимальные поддерживаемые версии, планшеты. Поддержка старых версий системы добавляет часы на тестирование, поэтому её стоит осознанно ограничить.
4. Экраны и состояния. Для каждого экрана: что на нём есть, что происходит при пустых данных, при загрузке, при ошибке сети. Состояния забывают чаще всего, а они занимают заметную часть времени разработки.
5. Интеграции. Самый дорогой раздел. По каждой системе: название и версия, есть ли готовое API и документация, кто отвечает за доработки на стороне системы, есть ли тестовый контур. Формулировка «интеграция с 1С» без этих деталей не оценивается: у одной компании это выгрузка каталога раз в сутки, у другой онлайн-обмен остатками, ценами и статусами заказов.
6. Уведомления. Какие события вызывают push, кто и откуда их отправляет, нужна ли сегментация. Без этого раздела приложение получает уведомления «для всех», и через месяц их отключает половина пользователей.
7. Данные и приватность. Какие персональные данные собираются, где хранятся, как удаляются по запросу пользователя. Стор откажет в публикации, если политика конфиденциальности не описывает то, что приложение реально делает.
8. Аналитика. Список событий, которые нужно отслеживать, с первого дня. Если события добавляют после релиза, первые месяцы работы продукта остаются без данных.
9. Приёмка. Как проверяется результат: на каких устройствах, по каким сценариям, что считается критичной ошибкой, сколько времени отводится на исправления. Раздел скучный, но именно он предотвращает спор «работает или не работает».
10. Что не входит. Явный список: контент, фотографии товаров, тексты, аккаунты разработчика, серверная инфраструктура, поддержка после релиза. Всё, что не упомянуто, заказчик по умолчанию считает включённым.
Как ТЗ влияет на стоимость
Смета на приложение считается по составу функций в часах, а не по формуле «приложение целиком стоит столько-то». Это значит, что каждая уточнённая строка ТЗ либо убирает часы, либо делает их предсказуемыми. Три примера, которые чаще всего меняют цифру:
- Офлайн-режим. Работа без сети означает локальную базу и синхронизацию, это заметный объём работ. Если офлайн не нужен, его надо явно исключить.
- Роли и права. Два типа пользователей и три типа это разные объёмы: каждая роль приносит свои экраны и проверки.
- Оплата. Приём платежей картой и через СБП, сохранение карт, возвраты и чеки это отдельные интеграции с бухгалтерией и платёжным сервисом.
Вилки по типам приложений, стоимость функций в часах и состав работ мы разобрали отдельно: сколько стоит разработка мобильного приложения. Там же видно, как меняется смета при переходе с кроссплатформенной разработки на нативную.
Признаки формального ТЗ
- В документе нет ни одного числа: ни версий систем, ни ограничений, ни сроков.
- Экраны описаны существительными («профиль», «каталог») без сценариев.
- Интеграции перечислены списком без документации и ответственных.
- Нет раздела «что не входит».
- Нет описания состояний ошибок.
Если в вашем ТЗ есть хотя бы три пункта из этого списка, подрядчик заложит риск в оценку, и вы заплатите за неопределённость.
Что делать, если писать ТЗ некому
Нормальная практика: заказать предпроектное обследование отдельным этапом. Команда собирает требования, описывает сценарии и состав, а вы получаете документ, с которым можно идти к любому подрядчику и сравнивать сметы по одному основанию.
Если хочется сначала прикинуть порядок цифр, заполните онлайн-бриф: у каждого вопроса написано, как он влияет на смету, и по ответам мы возвращаем предварительный расчёт. Общий состав работ, сроки и подход к разработке описаны на странице мобильных приложений.
Услуги по теме статьи
Читайте в бизнес-журнале
- Доступы и права: чек-лист, который спасёт ваш сайт
- Мобильная версия сайта: где теряется половина клиентов
- Интеграции и API: как связать сервисы между собой
Больше разборов о маркетинге, продажах и сайтах публикуем в бизнес-журнале «Дома Маркетинга».