Техническое задание, которое экономит месяц

Вопрос первый: кто принимает решение

Самая дорогая правка — та, которую вносит человек, впервые увидевший макет на сдаче. Если согласование идёт через одного менеджера, а финальное слово за собственником, который в процессе не участвовал, переделка первого экрана в конце проекта почти гарантирована.

• Кто утверждает структуру, кто — дизайн, кто — тексты. Это могут быть разные люди.
• Есть ли у утверждающего право вето на уже согласованное.
• В какой срок приходит ответ. Неделя тишины на каждом этапе — это плюс месяц к проекту.
• Что считается утверждением: письмо, сообщение в чате, подпись.

Вопрос второй: что считается результатом

Формулировка «сделать современный сайт» непроверяема, поэтому спорить о ней можно бесконечно. Результат должен быть описан так, чтобы обе стороны одинаково понимали, наступил он или нет.

• Какое действие пользователя считается целевым: заявка, звонок, запись, оплата.
• Какие страницы обязаны быть на запуске, а какие могут появиться позже.
• На каких устройствах и в каких браузерах проверяем.
• Какие метрики скорости считаем приемлемыми — с конкретными числами.
• Что передаётся на сдаче: доступы, исходники, документация.

Хороший критерий проверки формулировки: её можно проверить, не спрашивая мнения. «Первый экран открывается за 2,5 секунды» проверяется. «Сайт выглядит дорого» — нет.

Вопрос третий: откуда берётся контент

Это место, где проекты стоят чаще всего. Дизайн готов, вёрстка готова, а сайт не запускается, потому что нет текстов о компании и фотографий команды. Ответственность за контент нужно распределить в самом начале и назвать дату.

• Тексты пишет клиент, студия или привлечённый автор — и к какому числу.
• Есть ли фотографии и кто имеет на них права. Сток и чужие фото с сайта конкурента — не вариант.
• Кто отвечает за юридически значимые формулировки: лицензии, гарантии, оферта.
• Что показываем, если контент к сроку не готов: заглушку, сокращённый вариант или сдвигаем запуск.

Вопрос четвёртый: какие интеграции обязательны

Интеграция, которую вспомнили в середине проекта, почти всегда меняет структуру данных, а иногда и логику страниц. Список внешних систем нужен до начала работ, вместе с ответом на вопрос, у кого доступы.

• CRM: куда падают заявки и в каком виде.
• Оплаты: какой провайдер, нужны ли возвраты и чеки.
• Обмен с учётной системой или маркетплейсом: что синхронизируется и как часто.
• Аналитика: какие события считаем целями.
• У кого доступы к домену, хостингу и почте. Это выясняется в начале, а не в день переноса.

Вопрос пятый: что мы не делаем

Граница проекта — такая же часть задания, как и его содержание. Явно записанное «в этот этап не входит» снимает половину будущих споров. Мы, например, всегда фиксируем, что не занимаемся контекстной рекламой и SMM: это не наша компетенция, и обещать её значит подвести клиента.

Как выглядит рабочее ТЗ

Объём не решает: документ на сорок страниц читают по диагонали, и он не работает. Рабочее задание помещается в несколько страниц и содержит только то, на что можно сослаться при разногласии.

• Задача бизнеса и целевое действие — одним абзацем.
• Кто клиент и какие у него возражения.
• Структура: список страниц и блоки на каждой.
• Границы: что входит в этап и что не входит.
• Интеграции и доступы с ответственными.
• Контент: кто, что, к какому числу.
• Критерии приёмки с проверяемыми формулировками.
• Порядок согласования и сроки ответа сторон.

Такое задание пишется два-три дня и экономит месяц. Не потому, что предугадывает всё, а потому, что переносит спорные разговоры в начало проекта, где они стоят дёшево. У нас разбор ниши и проектирование структуры — отдельный этап именно поэтому: к дизайну мы приходим с документом, а не с намерениями.