Большинство конфликтов «заказчик ↔ разработчик» рождаются из одной фразы: «я думал, это входило». ТЗ — это документ, который убирает «я думал». Он фиксирует, что именно делается, в каком объёме и как мы поймём, что готово.
Хорошая новость: чтобы написать рабочее ТЗ, не нужно быть техническим специалистом. Нужно ясно описать, что приложение делает и для кого.
01 · Зачем ТЗ, даже если «и так понятно»
«И так понятно» — самая дорогая иллюзия в проекте. У вас в голове одно приложение, у разработчика — другое, и совпадают они процентов на 70. Оставшиеся 30% — это и есть переделки, споры и сорванные сроки. ТЗ синхронизирует картинки в головах до того, как написана первая строчка кода.
ТЗ защищает обе стороны. Заказчика — от «это не входило, доплатите». Разработчика — от бесконечного «а давайте ещё вот это, по-быстрому».
02 · Что должно быть в ТЗ
Рабочее ТЗ на мобильное приложение обычно состоит из таких блоков:
- Цель и аудитория. Зачем приложение и для кого. Одно предложение, но точное.
- Роли пользователей. Кто работает с приложением — клиент, исполнитель, оператор, админ.
- Функции по ролям. Что каждая роль может делать. Это ядро ТЗ.
- Экраны и сценарии. Основные пути пользователя: от входа до целевого действия.
- Интеграции. Оплата, 1С, CRM, карты, уведомления — что и с чем связываем.
- Нефункциональные требования. Платформы (iOS/Android), языки, требования к безопасности и данным.
- Что НЕ входит. Отдельный важный раздел — он экономит нервы обеим сторонам.
03 · Роли и сценарии — сердце ТЗ
Если из ТЗ убрать всё лишнее, останется главное: кто и что делает. Описывайте функции через роли и сценарии, а не списком «фич». Не «нужны уведомления», а «когда водитель выходит на линию, оператор видит его на карте в реальном времени». Такая формулировка проверяема: по ней видно, готово или нет.
04 · Частые ошибки в ТЗ
- «Сделайте как у Х, только лучше». Это не ТЗ. У «Х» сотни экранов и лет разработки — нужно описать именно ваши функции.
- Размытые формулировки. «Удобный интерфейс», «быстрая работа» — не проверяемы. Нужны конкретные действия и результаты.
- Нет раздела «что не входит». Без него любая хотелка кажется «и так подразумевалась».
- Всё и сразу. ТЗ на 200 функций для первой версии — путь к бюджету, который вы не потянете. Разделите на этапы.
05 · Чем ТЗ отличается от брифа
Их часто путают. Бриф — это короткая анкета на старте: идея, аудитория, бюджет, сроки, примеры. С него удобно начать разговор. ТЗ — это уже детальное описание функций, на основе которого считается смета и пишется код. Бриф заполняете вы за 15 минут; ТЗ обычно рождается совместно с подрядчиком на этапе разбора.
06 · Шаблон и с чего начать
Не нужно изобретать структуру с нуля. В разделе «Шаблоны» у нас лежит готовый шаблон ТЗ для мобильного приложения и бриф — скачайте, заполните по разделам выше, и у вас уже будет каркас, по которому можно считать проект.
А если хотите, чтобы ТЗ помогли собрать — это и есть наш бесплатный «Разбор идеи»: вы рассказываете задачу, мы превращаем её в структурированное ТЗ со сметой. Опишите идею — и начнём.