Вы получили от заказчика техническое задание на 2 страницы с общими фразами, а команда уже через неделю задает вопросы: «Что именно делать?», «А это обязательно?», «Как это должно работать?».
Знакомо?
Проблема в том, что плохое ТЗ — источник 80% конфликтов и переделок в проекте. В этой статье разберем:
- почему расплывчатые требования — это бомба замедленного действия;
- какие ошибки чаще всего встречаются;
- как составить ТЗ, которое защитит вас и команду;
- как вовлечь заказчика в доработку документа.
Почему плохое ТЗ — проблема
Когда требования сформулированы нечетко, возникают:
- бесконечные правки («Я имел в виду не это!»);
- срывы сроков из‑за переделок;
- рост бюджета на доработку;
- конфликты между командой и заказчиком;
- риск сдать продукт, который не решает задачу.
Пример из практики:
Заказчик написал: «Нужно сделать удобный личный кабинет». Команда реализовала
- профиль пользователя;
- историю заказов;
- настройки уведомлений.
Но оказалось, заказчику нужен был только раздел для загрузки документов. Итог — 2 недели работы впустую.
Типичные ошибки в ТЗ (и как их избежать)
1. Общие фразы вместо конкретики
Плохо: Система должна быть быстрой.
Хорошо: Время отклика системы при загрузке главной страницы — не более 1 секунды при нагрузке до 100 пользователей одновременно.
2. Отсутствие критериев приемки
Плохо: Добавить функцию поиска.
Хорошо: Поиск должен находить записи по: названию, дате, категории. Результаты сортируются по релевантности. При отсутствии совпадений выводится сообщение: Ничего не найдено.
3. Неопределенные термины
Плохо: Интуитивно понятный интерфейс.
Хорошо: Кнопка Сохранить расположена в правом верхнем углу. При нажатии появляется всплывающее сообщение: Данные сохранены (зеленым цветом).
4. Смешение требований и решений
Плохо: Использовать React для фронтенда.
Хорошо: Интерфейс должен поддерживать работу в браузерах Chrome, Firefox, Safari последних версий.
5. Отсутствие приоритетов
Плохо: длинный список требований без ранжирования.
Хорошо: раздел Критично для запуска (must have) и Желательно (nice to have).
6. Игнорирование ограничений
Плохо: нет информации о совместимости с другими системами.
Хорошо: Система должна интегрироваться с CRM Битрикс24 через API. Формат передачи данных — JSON.
Чек‑лист обязательных разделов ТЗ
1. Цель проекта
- Что решает система?
- Какие бизнес‑задачи закрывает?
2. Функциональные требования
- Список функций с детализацией (что делает, как работает, какие данные обрабатывает).
- Примеры сценариев использования (user stories).
3. Нефункциональные требования
- Производительность (скорость, нагрузка).
- Безопасность (шифрование, аутентификация).
- Совместимость (браузеры, ОС, устройства).
4. Критерии приемки
- Как проверить, что функция работает?
- Какие тесты проводятся?
5. Ограничения
- Технические (аппаратные требования, интеграция).
- Временные (сроки, релизы).
- Бюджетные.
6. Роли и ответственность
- Кто утверждает изменения?
- Кто тестирует?
- Кто принимает результат?
7. Термины и сокращения
- Глоссарий для единообразия понимания.
8. Приложения
- Эскизы интерфейса.
- Схемы данных.
- Примеры входных/выходных данных.
Как вовлечь заказчика в доработку ТЗ
Шаг 1. Начните с вопросов, а не с документа
- Проведите интервью: «Что для вас критично?», «Какие проблемы должна решить система?», «Как вы сейчас это делаете?».
- Зафиксируйте ответы в виде user stories: «Как менеджер, я хочу быстро найти клиента по номеру телефона, чтобы не тратить время на поиск в Excel».
Шаг 2. Покажите прототип
- Используйте макеты (даже на бумаге) — так заказчик увидит, как будут выглядеть функции.
- Спросите: «Это то, что вы имели в виду?».
Шаг 3. Разбейте ТЗ на части
- Предложите согласовать сначала «ядро» (критичные функции), затем детали.
- Это снизит сопротивление и ускорит процесс.
Шаг 4. Используйте «язык пользы»
- Вместо: «Добавим поле «Комментарий», скажите: «Поле «Комментарий» позволит фиксировать важные детали сделки, чтобы избежать ошибок при отгрузке».
Шаг 5. Фиксируйте договоренности
- После каждой встречи отправляйте письмо с кратким резюме: «Мы договорились, что…».
- Попросите подтвердить: «Все верно?».
Шаг 6. Проведите «тест‑драйв» ТЗ
- Дайте заказчику заполнить небольшой сценарий по вашему шаблону (например, описать процесс оформления заказа).
- Так он поймет, как структурировать требования.
Как улучшить формулировку
сравните примеры:
Исходное требование (плохо):
«Сделать форму обратной связи».
Улучшенный вариант (хорошо):
- Цель: собрать контакты клиентов для обработки заявок.
- Расположение: в футере сайта и на странице «Контакты».
- Поля: имя (обязательное), email (обязательное, проверка формата), телефон (необязательное), сообщение (не менее 10 символов).
- Валидация: при пустом поле — подсветка красным; при неверном email — сообщение: «Введите корректный email».
- Действие после отправки: показ сообщения: «Спасибо! Мы ответим в течение 24 часов»; отправка письма администратору на support@company.ru.
- Ограничения: форма должна работать при отключенном JavaScript (альтернативный вариант).
Ключевые выводы
- ТЗ — это не формальность, а инструмент защиты проекта. Четкие требования снижают риски переделок и конфликтов.
- Избегайте абстракций. Каждая функция должна иметь критерии проверки.
- Вовлекайте заказчика поэтапно. Начните с вопросов и прототипов, а не с толстого документа.
- Используйте шаблоны и чек‑листы. Это сэкономит время и исключит пропуски важных разделов.
- Фиксируйте договоренности письменно. Даже небольшие уточнения должны быть согласованы.
Если ТЗ можно трактовать двояко — его уже нужно переписывать.
Не ждите, пока заказчик сам сформулирует требования. Возьмите процесс в свои руки — и проект пойдет по плану.