Хорошее техническое задание не пытается предсказать каждую мелочь. Оно выделяет решения, которые влияют на цену, срок и приёмку: структуру, функции, данные, интеграции и критерии готовности. Остальные детали можно уточнять в макетах и рабочих комментариях по согласованному процессу.
Начните с задачи и пользователей
До перечня страниц опишите, кому нужен сайт и какое действие посетитель должен выполнить: выбрать услугу, запросить расчёт, оформить заказ или найти контакт. Для сотрудников укажите рабочие сценарии — например, изменение цены, обработку заявки или выгрузку каталога. Это помогает отличить обязательные функции от пожеланий.
Общую рамку договора удобно проверить по чек-листу договора на разработку сайта, а в техническом задании сосредоточиться на самом результате.
Опишите карту страниц и типы контента
Перечислите не только названия разделов, но и типы страниц: услуга, проект, статья, категория, карточка товара, контакты. Для каждого типа укажите обязательные поля и связи. Если десять страниц строятся по одному шаблону, это одна задача; если у каждой свой сценарий и набор блоков — объём другой.
- Какие страницы создаются к запуску и кто их заполняет.
- Какие разделы заказчик сможет добавлять самостоятельно.
- Какие URL важно сохранить при замене действующего сайта.
- Нужны ли поиск, фильтры, сортировка и пагинация.
Разберите функции на вход, обработку и результат
Для формы опишите поля, проверки, согласие на обработку данных, получателя и сообщение об успешной отправке. Для интеграции с CRM — какие данные передаются, в какой момент, как фиксируется ошибка. Для оплаты — доступные способы, статусы и поведение при неуспешной операции.
Такой формат снижает двусмысленность: функция становится набором проверяемых действий, а не названием сервиса. При разработке интернет-магазина это особенно важно для каталога, оплаты, доставки и работы менеджера.
Разделите материалы сторон
Заказчик обычно лучше знает факты о бизнесе, исполнитель — требования к формату материалов. В приложении можно указать, кто готовит тексты, фотографии, юридическую информацию, товарные данные и переводы. Для каждого набора полезны формат, объём и дата передачи.
Если исполнитель редактирует или создаёт контент, уточните количество страниц и итераций. Если используются материалы из фотобанков, согласуйте лицензию и источник. Это защищает график от ситуации, когда дизайн готов, а запуск задерживается из-за отсутствующих данных.
Добавьте критерии приёмки
Критерий должен позволять повторить проверку. «Корректно работает на телефоне» можно раскрыть перечнем основных разрешений и сценариев; «настроено SEO» — списком метатегов, Sitemap, robots.txt, микроразметки и проверки индексируемости.
Не стоит превращать ТЗ в сотни несущественных требований. Сначала фиксируют то, что влияет на бизнес-сценарий, безопасность данных, стоимость и совместимость. Визуальные детали удобнее утверждать макетом, указав в ТЗ статус макета как части проекта.
Предусмотрите управляемые изменения
Во время разработки появляются уточнения. Поэтому нужен порядок: запрос, оценка влияния на цену и срок, письменное согласование, выполнение. Полезно отличать уточнение уже согласованного требования от новой функции.
Перед подписанием проведите короткую встречу по ТЗ: представитель бизнеса проходит ключевые сценарии, а исполнитель показывает, где они описаны. Если участники одинаково представляют результат, документ выполнил основную задачу.
