ТЗ на доработку сайта: как описать задачу, чтобы разработчик понял с первого раза

Плохое ТЗ обычно звучит так: “сделайте красиво”, “форма работает неправильно”, “нужно как у конкурентов”, “поправить сайт”. Разработчик начинает задавать вопросы, заказчик раздражается, сроки растут. Не потому что задача сложная, а потому что она описана слишком туманно.

Хорошее ТЗ не обязано быть длинным. Оно должно дать разработчику контекст, ожидаемый результат и критерии проверки.

Начать с цели

Не только “добавить кнопку”, а зачем она нужна.

Цель: увеличить количество заявок со страницы услуги.
Нужно добавить кнопку "Получить консультацию" после блока с ценами.

Когда понятна цель, разработчик может заметить риск. Например, кнопка есть, но форма ниже не работает на мобильном.

Описать текущее поведение

Перед ожидаемым результатом нужно указать, что происходит сейчас.

Сейчас при отправке формы пользователь видит сообщение "Ошибка".
Заявка в CRM не создаётся.
Письмо менеджеру не приходит.

Если есть ссылка на страницу, скриншот и пример данных — это сильно ускоряет диагностику.

Описать ожидаемое поведение

Ожидаемый результат должен быть проверяемым.

После отправки формы:
1. На сайте появляется сообщение "Спасибо, заявка отправлена".
2. В CRM создаётся лид.
3. Менеджеру приходит уведомление.
4. В лог записывается ID лида.

Такое описание сразу превращается в чек-лист приёмки.

Указать ограничения

Ограничения важны не меньше самой задачи. Например:

• не менять дизайн соседних блоков;
• не трогать текущую CRM-интеграцию;
• сохранить старые URL;
• не менять структуру базы без согласования;
• правка должна работать на PHP 8.2;
• нельзя останавливать сайт днём.

Без ограничений разработчик может выбрать технически нормальное решение, которое не подходит бизнесу.

Примеры и антипримеры

Если нужно сделать блок “как у конкурента”, лучше дать ссылку и объяснить, что именно нравится: расположение, логика, текст, поведение на мобильном.

Нравится: компактная форма в два поля и кнопка рядом.
Не нужно копировать: цвета, анимацию, всплывающее окно.

Это лучше, чем просто “сделать как здесь”.

Доступы и данные

Если задача требует CRM, почты, хостинга или админки, нужно заранее понять, какие доступы нужны. Не обязательно сразу пересылать пароли в переписке. Но нужно зафиксировать, что без доступа задача не проверяется полностью.

Критерии приёмки

Критерии приёмки — это список, по которому понятно, задача готова или нет.

Готово, если:
- кнопка отображается на desktop и mobile;
- форма открывается по клику;
- обязательные поля проверяются;
- тестовая заявка создаётся в CRM;
- письмо приходит на sales@example.ru;
- в консоли браузера нет JS-ошибок.

Что не входит в задачу

Иногда полезно явно написать, что не входит. Например: “В рамках этой задачи не меняем тексты на странице и не настраиваем рекламные цели”. Это защищает срок и бюджет.

Чек-лист ТЗ

1. Цель задачи.
2. Ссылка на страницу или раздел.
3. Текущее поведение.
4. Ожидаемое поведение.
5. Скриншоты или примеры.
6. Ограничения.
7. Нужные доступы.
8. Критерии приёмки.
9. Что не входит в задачу.

ТЗ нужно не для бюрократии. Оно снижает число догадок. Чем меньше разработчик угадывает, тем точнее оценка, спокойнее релиз и меньше переделок.