Техническое задание на сайт: как написать и что включить

Слово «техническое» отпугивает зря. Для сайта малого бизнеса ТЗ — это документ на две-четыре страницы, который отвечает на один вопрос: что мы считаем готовым сайтом. Написать его может владелец бизнеса без единой технической строчки, если помнить главное правило: вы описываете не «как сделать», а «что должно работать».

Зачем ТЗ нужно заказчику, а не только разработчику

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

• Защита от «это не входило в работу». Если в ТЗ написано «форма заявки отправляет данные на почту и в Telegram», спорить не о чем.
• Защита подрядчика от бесконечных «а давайте ещё». Это тоже в ваших интересах: команда, у которой работа не имеет границ, растягивает сроки и закладывает риск в цену.
• Возможность сравнивать предложения. С одним и тем же ТЗ несколько подрядчиков дают сопоставимые сметы, и разница в цене становится объяснимой.
• Проверяемая приёмка. В конце вы не оцениваете «нравится или не нравится», а сверяетесь со списком.
• Страховка от смены исполнителя. Если человек пропал, новый подрядчик подхватывает работу по документу, а не по переписке в мессенджере.

Что должно быть в техническом задании

Минимальный набор разделов выглядит так. В третьей колонке — то, чем обычно заканчивается пропуск раздела: это самые частые конфликты на проектах.

Готовый скелет ТЗ

Скопируйте этот список и заполните своими словами. Пункты, которых у вас нет, вычеркните — это нормально: ТЗ на лендинг заметно короче ТЗ на магазин.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ САЙТА
Заказчик: ______   Дата: ______   Приложение к договору № ______

1. О компании и задаче
   1.1. Чем занимается компания, город и регион работы.
   1.2. Что должен делать сайт: заявки, звонки, запись, продажи.
   1.3. Как поймём, что сайт сработал (например: заявки приходят
        в Telegram и фиксируются в CRM).

2. Аудитория
   2.1. Кто покупает — 2-3 типа клиентов.
   2.2. Что им важно при выборе и чего они опасаются.
   2.3. С чем сравнивают: 3-5 ссылок на конкурентов.

3. Состав сайта
   3.1. Список страниц с назначением каждой.
   3.2. Для главной — перечень блоков сверху вниз.
   3.3. Что переносим со старого сайта, что делаем заново.

4. Функциональность
   4.1. Формы: какие поля, куда уходит заявка, кто её принимает.
   4.2. Каталог, фильтры, личный кабинет, калькулятор — если нужны.
   4.3. Интеграции: CRM, 1С, оплата, мессенджеры, аналитика.
   4.4. Языковые версии — если нужны.

5. Дизайн
   5.1. Фирменный стиль: логотип, цвета, шрифты есть или делаем.
   5.2. 3-5 сайтов-референсов и что именно нравится в каждом.
   5.3. Стоп-лист: чего на сайте быть не должно.
   5.4. Сколько кругов правок макета входит в работу.

6. Контент
   6.1. Кто пишет тексты: заказчик, подрядчик, копирайтер.
   6.2. Кто даёт фото, прайс, документы, реквизиты.
   6.3. Срок передачи материалов.

7. Технические требования
   7.1. Платформа: CMS, конструктор или своя разработка.
   7.2. Кто редактирует контент после сдачи и через что.
   7.3. Требования к скорости и к отображению на телефоне.
   7.4. Домен, хостинг, SSL, почта — на чьей стороне.

8. Аналитика и запуск
   8.1. Счётчики и цели, которые должны быть настроены.
   8.2. Куда приходят заявки и кто отвечает.
   8.3. Проверка перед сдачей: список устройств и браузеров.

9. Сроки и приёмка
   9.1. Этапы работ и что показываем на каждом.
   9.2. Что считается сдачей: сайт открыт на боевом домене,
        формы отправляют заявки, аналитика собирает данные.
   9.3. Срок проверки заказчиком и порядок правок.

10. Права и доступы
   10.1. Кому принадлежат макеты и код после оплаты.
   10.2. Перечень доступов, которые передаются заказчику.
   10.3. Что после сдачи: гарантия на ошибки, поддержка, доработки.

Если на каком-то пункте вы не знаете ответа — так и напишите: «решаем на этапе прототипа». Открытый вопрос, зафиксированный в документе, безопаснее вопроса, о котором обе стороны молча думают по-разному.

Как написать ТЗ, если вы не технарь

Правило одно: вы описываете результат, подрядчик — способ. Не «сделайте на такой-то технологии с такой-то анимацией», а «главная должна открываться на телефоне быстро, а заявка приходить мне в течение минуты». Чем это реализовано — зона ответственности исполнителя, и лезть туда без нужды вредно: вы ограничите его в решениях, за которые сами же и платите.

1. 1Напишите одно предложение о том, что должно происходить после запуска: «человек из поиска оставляет заявку на замер, она приходит мне в Telegram за минуту».
2. 2Соберите 3-5 сайтов, которые вам нравятся, и один-два, которые не нравятся. Рядом с каждым — строчка почему. Это заменяет десять страниц описания дизайна.
3. 3Перечислите услуги или товары так, как их называют клиенты, а не так, как они записаны в договорах и накладных.
4. 4Пройдите по скелету выше сверху вниз и заполните то, что знаете точно. Остальное пометьте как открытые вопросы.
5. 5Отдайте черновик подрядчику и попросите задать вопросы к нему. Хороший подрядчик вернёт список уточнений — из них и получится финальное ТЗ.

Ошибки, из-за которых ТЗ перестаёт работать

Документ есть, а споры всё равно случаются — почти всегда по одним и тем же причинам. Пробегитесь по своему черновику с этим списком.

Кто пишет ТЗ и сколько это стоит

Вариантов три. Заказчик пишет сам — бесплатно, но обычно с пробелами в технической части и в приёмке. Пишет подрядчик по вашим ответам — быстрее и точнее, но документ невольно описывает то, что удобно делать именно ему. Пишет третья сторона — дороже и оправдано на крупных проектах, где ошибка в постановке стоит месяцев.

Разумный компромисс для малого бизнеса: вы заполняете скелет своими словами, подрядчик дополняет техническую часть и возвращает на согласование. Дальше документ идёт приложением к договору — только тогда у него появляется вес. ТЗ, которое никто не подписывал и не приложил, остаётся черновиком: спорить по нему можно, опираться — нет.