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