Как составить ТЗ для разработки: пошаговая инструкция

"Без ТЗ результат ХЗ" -- шутка, которая слишком часто оказывается реальностью. Техническое задание -- это документ, который описывает, что именно должно быть разработано, как это должно работать и каким критериям соответствовать. Хорошее ТЗ защищает обе стороны: заказчик получает гарантию, что продукт будет соответствовать ожиданиям, а разработчик -- чёткое понимание задачи и защиту от бесконечных доработок. На практике же ТЗ либо отсутствует ("мы на словах договоримся"), либо представляет собой 3 абзаца общих фраз, либо, наоборот, 100-страничный документ, который никто не читает. В этой статье расскажем, как составить ТЗ, которое действительно работает -- достаточно подробное для однозначного понимания, но не перегруженное лишней информацией.

Эффективное ТЗ состоит из нескольких обязательных разделов. Общее описание проекта: цели, целевая аудитория, бизнес-контекст. Функциональные требования: что система должна делать (каждая функция как отдельный пункт). Нефункциональные требования: производительность, безопасность, масштабируемость. Пользовательские сценарии: пошаговое описание взаимодействия пользователя с системой. Дизайн и UI: ссылки на макеты, брендбук, требования к адаптивности. Интеграции: список внешних сервисов и описание взаимодействия. Ограничения: технологические, бюджетные, временные. Критерии приёмки: как будет определяться, что работа выполнена. Оптимальный объём ТЗ для проекта стоимостью 200-500 тысяч рублей -- 10-20 страниц. Больше -- избыточно, меньше -- недостаточно.

Функциональные требования -- ядро ТЗ. Каждое требование должно быть конкретным, измеримым и однозначным. Плохо: "Пользователь должен иметь возможность регистрации". Хорошо: "Регистрация через email: пользователь вводит email и пароль (минимум 8 символов, минимум 1 цифра), получает письмо с подтверждением, после перехода по ссылке аккаунт активируется. Регистрация через Telegram: пользователь нажимает кнопку Telegram Login, система получает имя и Telegram ID, создаёт аккаунт автоматически". Группируйте требования по модулям: авторизация, личный кабинет, каталог, корзина, оплата, админ-панель. Для каждого модуля опишите: какие данные вводит пользователь, какие действия может совершить, что видит в ответ, что происходит при ошибке. Используйте нумерацию: FR-1, FR-2 и так далее -- это упрощает ссылки при обсуждении.

Пользовательские сценарии описывают путь пользователя от точки А до точки Б. Они дополняют функциональные требования, показывая, как отдельные функции складываются в целостный опыт. Формат User Story: "Как [роль пользователя], я хочу [действие], чтобы [цель]". Пример: "Как владелец интернет-магазина, я хочу получать уведомление в Telegram о каждом новом заказе, чтобы оперативно реагировать на заказы в нерабочее время". К каждой User Story добавьте критерии приёмки -- конкретные проверки, которые подтверждают, что функция работает корректно. Например: "Уведомление приходит в течение 60 секунд после оформления заказа. Уведомление содержит номер заказа, сумму, имя клиента и список товаров. При недоступности Telegram уведомление дублируется на email". Такой уровень детализации исключает разночтения.

Идеальный вариант -- приложить к ТЗ интерактивные макеты в Figma. Они показывают каждый экран, расположение элементов, переходы между страницами. Стоимость макетов -- от 50 000 рублей, но они окупаются многократно, устраняя разночтения на этапе разработки. Если бюджет на дизайн ограничен, подготовьте хотя бы wireframes -- схематичные наброски экранов, показывающие структуру без визуального оформления. Это можно сделать бесплатно в Figma или даже на бумаге. В ТЗ обязательно укажите: поддерживаемые устройства и разрешения экранов (десктоп от 1280px, планшеты от 768px, мобильные от 375px), требования к скорости загрузки (первый экран за 2 секунды), поддерживаемые браузеры (Chrome, Safari, Firefox последних 2 версий), требования к доступности (размер шрифта, контрастность, навигация с клавиатуры).

Ошибка первая: описание решения вместо проблемы. "Сделайте красную кнопку в правом верхнем углу" -- это описание решения. "Пользователь должен иметь быстрый доступ к корзине с любой страницы" -- это описание проблемы, а дизайнер сам определит лучшее решение. Ошибка вторая: слова-паразиты. "Удобный интерфейс", "быстрая загрузка", "современный дизайн" -- субъективные понятия, которые каждый трактует по-своему. Замените на конкретику: "Загрузка каталога за 1.5 секунды на мобильном интернете 4G". Ошибка третья: забытые крайние случаи. Что если пользователь ввёл неправильный пароль 10 раз? Что если товар закончился между добавлением в корзину и оплатой? Что если у клиента нет фото профиля? Продумайте сценарии ошибок и пограничные ситуации -- именно они становятся источником багов.

Распространённое заблуждение -- ТЗ пишет заказчик. На практике оптимальный вариант -- совместная работа. Заказчик описывает бизнес-требования: что он хочет получить, какие проблемы решить, кто будет пользоваться продуктом. Разработчик (или бизнес-аналитик) переводит это в технические требования: архитектура, интеграции, ограничения платформ. Стоимость составления ТЗ зависит от масштаба проекта. Для небольшого проекта (бот, лендинг) -- можно обойтись бесплатной консультацией и документом на 3-5 страниц. Для среднего проекта (веб-приложение, CRM) -- этап аналитики и составления ТЗ стоит 30-70 тысяч рублей, занимает 1-2 недели. Для крупного проекта -- от 100 тысяч, 2-4 недели работы аналитика совместно с командой заказчика. Эти инвестиции защищают от ситуации, когда бюджет на разработку тратится на бесконечные переделки из-за непонятных требований.