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