Типичные ошибки в техническом задании и как их исправить
Практика3 минРедакция Innovialabs
Коротко
Большинство проблем ТЗ сводится к одному — требование нельзя проверить. Исправление простое: конкретные формулировки, описанные крайние случаи и критерии приёмки для каждой функции.
Главная ошибка: требования, которые нельзя проверить
Хорошее техническое задание отвечает на вопрос «как мы поймём, что это сделано?». Если на этот вопрос нет ответа, исполнитель и заказчик будут понимать результат по-разному. Почти все ошибки ниже — частные случаи этой проблемы. Для каждой приводим пример «было» и «стало».
1. Расплывчатые формулировки
Слова «удобный», «быстрый», «современный», «интуитивный» не описывают поведение системы.
- Было: «Сайт должен быстро загружаться».
- Стало: «Главная страница загружается на мобильном интернете так, чтобы основной контент был виден без долгого ожидания; целевые значения Core Web Vitals — в зелёной зоне по данным PageSpeed Insights».
Правило: каждое прилагательное замените измеримым условием или конкретным действием пользователя.
2. Нет крайних случаев
ТЗ описывает только «счастливый путь», когда всё идёт по плану.
- Было: «Пользователь оплачивает заказ картой».
- Стало: «Пользователь оплачивает заказ картой. Если платёж отклонён — показываем причину и предлагаем повторить. Если пользователь закрыл страницу во время оплаты — заказ остаётся в статусе „Ожидает оплаты“ и отменяется через заданное время. Если платёжная система не ответила — заказ не подтверждается до получения статуса».
Задайте к каждой функции вопросы: что если данных нет, их слишком много, они неверные, сеть пропала, действие повторили дважды?
3. Нет критериев приёмки
Без них сдача проекта превращается в спор.
- Было: «Реализовать регистрацию».
- Стало:
- пользователь вводит телефон и получает код подтверждения;
- неверный код — сообщение об ошибке, можно запросить новый код через указанный интервал;
- повторная регистрация на тот же номер невозможна, предлагается вход;
- после успешной регистрации пользователь попадает в личный кабинет.
Удобный формат: «Дано — Когда — Тогда». Каждый пункт можно проверить вручную или тестом.
4. Решение вместо задачи
Заказчик пишет «сделать на технологии X» или «добавить кнопку в правом углу», не объясняя зачем.
- Было: «Добавить выгрузку в Excel».
- Стало: «Бухгалтеру раз в месяц нужен список оплаченных заказов за период для сверки. Формат — таблица, которую можно открыть в Excel».
Когда понятна цель, исполнитель может предложить более простое решение.
5. Нет ролей и прав доступа
«Пользователь может редактировать заказ» — какой пользователь? Опишите роли (клиент, менеджер, администратор) и таблицу: кто что видит и что может менять.
| Действие | Клиент | Менеджер | Админ |
|---|---|---|---|
| Видеть свои заказы | да | — | да |
| Менять статус заказа | нет | да | да |
| Удалять заказ | нет | нет | да |
6. Забыты нефункциональные требования
Кроме функций, важны: ожидаемая нагрузка, поддерживаемые браузеры и устройства, языки интерфейса, резервное копирование, требования к хранению персональных данных, кто будет поддерживать систему после запуска.
7. Всё одинаково важно
Если все 80 пунктов обязательные, сроки и бюджет не сойдутся. Разделите требования на «обязательно для запуска», «желательно» и «потом». Это делает обсуждение сроков честным.
Быстрый чек-лист перед отправкой ТЗ
- у каждой функции есть цель и критерии приёмки;
- описаны ошибки и крайние случаи;
- перечислены роли и права;
- указаны нефункциональные требования;
- расставлены приоритеты;
- нет слов без измеримого смысла.