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