Как составить техническое задание на сайт: простая инструкция

За годы работы с сайтами я видел десятки проектов, которые разваливались только потому, что стороны по-разному понимали задачу. Техническое задание — это не бюрократия и не лишний документ «для галочки». Это рабочий инструмент, который фиксирует, что именно нужно сделать, в какие сроки и каким должен быть результат. Без него даже простой лендинг может превратиться в бесконечные правки и споры.

Хорошее ТЗ экономит деньги, время и нервы. Плохое — гарантированно приводит к бесконечным правкам, раздуванию бюджета и финальной фразе «я это не так представлял». Я не раз видел, как отсутствие четкого ТЗ превращало запуск сайта в затяжной марафон. Поэтому ниже — простая и практичная инструкция, которая поможет составить понятное техническое задание на сайт, даже если вы делаете это впервые.

Зачем вообще нужно ТЗ

Техническое задание нужно, чтобы заранее зафиксировать ключевые договоренности:

• цель сайта;
• состав страниц;
• функции и сценарии;
• требования к дизайну;
• что входит в работу, а что нет;
• как будет приниматься результат.

Если ТЗ нет, каждый участник проекта додумывает детали по-своему. Заказчик рисует в голове красивый сайт, исполнитель собирает набор страниц, а на этапе приемки выясняется, что не согласованы форма заявки, мобильная версия и даже тексты кнопок. По опыту, именно такие «мелочи» потом вызывают больше всего споров.

Что дает хорошее ТЗ

• помогает точно оценить стоимость и избежать «неожиданных» доплат;
• сокращает число правок;
• упрощает коммуникацию между заказчиком и исполнителем;
• ускоряет запуск проекта;
• защищает обе стороны от недопонимания и взаимных обвинений.

Как выглядит хорошее ТЗ: коротко

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

1. Что делаем?
2. Для кого?
3. Зачем?
4. Какие страницы и блоки нужны?
5. Какие функции должны работать?
6. Как понять, что задача выполнена?

Из чего состоит техническое задание на сайт

Ниже — структура, которую удобно брать за основу почти для любого проекта: лендинга, корпоративного сайта, интернет-магазина или сайта услуг. Я обычно рекомендую этот каркас своим клиентам, он покрывает все типовые ситуации.

1. Общая информация о проекте

Первый раздел — базовые данные о проекте. Без них документ сложно идентифицировать и согласовывать. Укажите: название проекта, кто заказчик, кто исполнитель, дату подготовки, версию ТЗ и ссылку на исходные материалы, если они уже есть. Это кажется формальностью, но когда проект растягивается на месяцы, версии и даты очень помогают не запутаться.

Пример

• Проект: сайт студии йоги
• Цель: привлечение заявок на пробное занятие
• Формат: одностраничный сайт
• Референсы: 3 примера
• Контактное лицо: Иван Петров

2. Цель сайта

Цель сайта — фундамент всего документа. Без нее нельзя понять, что считать успешным результатом. Я всегда прошу клиентов сформулировать цель одной фразой, и если не получается — проект еще не готов к старту.

Примеры целей

• собрать заявки;
• продавать товары;
• записывать клиентов на услугу;
• информировать о компании;
• принимать бронирования;
• демонстрировать портфолио.

Плохой вариант

«Сделать современный сайт» — такая цель не дает ничего, потому что «современный» каждый понимает по-своему.

Хороший вариант

«Сделать сайт, который будет собирать заявки на расчет стоимости ремонта через форму и мессенджеры» — конкретная и измеримая цель, сразу понятно, что должно работать.

3. Целевая аудитория

Описание целевой аудитории — не маркетинговая абстракция, а рабочий инструмент. От того, кто будет пользоваться сайтом, зависят структура, тексты, визуальный стиль и даже подписи на кнопках. Укажите: кто пользователь; какие у него задачи; что для него важно; какие возражения он может иметь.

Пример

Если сайт нужен для юридических услуг, аудитория может быть такой:

• физические лица, которым нужна консультация;
• предприниматели, которым требуется сопровождение;
• люди, ищущие помощь в конкретной проблеме.

Если прописать эти портреты, исполнителю будет проще принять правильные решения по дизайну и контенту.

4. Структура сайта

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

Для сайта услуг это может быть:

• главная;
• о компании;
• услуги;
• цены;
• кейсы;
• отзывы;
• блог;
• контакты.

Для интернет-магазина:

• главная;
• каталог;
• карточка товара;
• корзина;
• оформление заказа;
• доставка и оплата;
• личный кабинет;
• контакты.

Списки могут меняться, но важно зафиксировать обязательный минимум.

5. Функциональные требования

Функциональные требования — это сердце ТЗ. Здесь мы описываем, что сайт должен уметь делать, а не как он должен выглядеть. Частая ошибка — написать «сделайте удобный сайт» и на этом остановиться. Так не работает. Лучше перечислить конкретные функции.

Примеры функций

• форма заявки;
• обратный звонок;
• онлайн-оплата;
• фильтр товаров;
• поиск по сайту;
• калькулятор стоимости;
• подписка на рассылку;
• карта с адресами;
• мультиязычность.

Каждая функция — это отдельный пункт, по которому потом можно проверить готовность.

6. Требования к дизайну

Дизайн — самый субъективный раздел, поэтому здесь важно зафиксировать как можно больше конкретики. Не обязательно владеть профессиональной терминологией: достаточно внятно объяснить, что вам нравится и что категорически не подходит. Укажите: цветовую гамму; желаемое настроение; примеры сайтов; запреты по стилю; требования к анимации; предпочтения по шрифтам.

Пример формулировки

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

Такая формулировка уже дает исполнителю понятный вектор.

7. Контент

Контент — это тексты, фото, видео, иконки, документы и другие материалы. Без них даже самый лучший дизайн останется пустышкой. Поэтому в ТЗ обязательно фиксируем, кто именно готовит контент. От этого зависят сроки и зоны ответственности.

Вопросы, которые нужно решить

• тексты предоставляет заказчик или исполнитель;
• нужны ли фотографии;
• будет ли съемка;
• нужны ли иллюстрации;
• кто пишет SEO-тексты;
• кто наполняет сайт товарами или статьями.

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

8. Технические требования

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

Что можно указать

• сайт должен корректно работать на мобильных устройствах;
• поддержка современных браузеров;
• быстрая загрузка страниц;
• SSL-сертификат;
• подключение аналитики;
• защита форм от спама;
• базовая SEO-оптимизация;
• резервное копирование.

Это минимум, который я рекомендую прописывать всегда, независимо от сложности проекта.

9. Интеграции

Если сайт должен обмениваться данными с внешними сервисами, это обязательно прописываем отдельным пунктом. Иначе потом выяснится, что CRM не подключена или платежная система не работает.

Примеры интеграций

• CRM;
• онлайн-касса;
• службы доставки;
• платежные системы;
• email-рассылки;
• мессенджеры;
• сервисы аналитики.

Для интернет-магазина это критически важный раздел.

10. Этапы и сроки

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

11. Критерии приемки

Критерии приемки — тот пункт, который чаще всего забывают, а зря. Без него невозможно объективно понять, выполнена ли работа. Заранее описываем, по каким признакам проект считается готовым.

Примеры критериев

• все страницы открываются без ошибок;
• формы отправляют заявки;
• сайт адаптирован под мобильные экраны;
• тексты и изображения размещены в нужных местах;
• нет битых ссылок;
• сайт проходит базовую проверку скорости и отображения.

Это снижает риск споров на этапе сдачи.

Пошаговый алгоритм: как составить ТЗ на сайт

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

Шаг 1. Определите цель

Начните с главного — сформулируйте цель. Но не абстрактное «чтобы был», а конкретную задачу: собирать заявки, продавать товары, записывать на услуги. Если цель одна и понятна, дальше будет проще.

Шаг 2. Опишите аудиторию

Кто будет пользоваться сайтом, что ищет и чего боится? Не нужно писать диссертацию, но портрет типичного посетителя поможет принимать решения по структуре и текстам.

Шаг 3. Соберите референсы

Найдите 3–5 примеров сайтов, которые нравятся по структуре, стилю или функционалу. Не нужно копировать — важно показать ориентир. Референсы — это самый быстрый способ объяснить, что вам нравится, без долгих описаний.

Шаг 4. Составьте структуру

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

Шаг 5. Пропишите функции

Отметьте все важные элементы: формы, фильтры, калькуляторы, оплату, корзину, чат. Чем детальнее, тем меньше сюрпризов на этапе разработки.

Шаг 6. Уточните контент

Кто готовит тексты, фото и видео? Когда материалы будут готовы? Этот шаг сэкономит недели ожидания.

Шаг 7. Зафиксируйте ограничения

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

Шаг 8. Определите критерии приемки

Сразу решите, что именно вы будете проверять перед оплатой и запуском. Это финальный предохранитель от споров.

Таблица: что должно быть в ТЗ и зачем

Типовые ошибки в техническом задании

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

1. Размытые формулировки

Это самая частая ошибка. Слова «красиво», «современно», «удобно» не несут информации, потому что каждый понимает их по-своему.

Плохо:

• Сделать красиво.
• Сделать современно.
• Сделать удобный сайт.

Хорошо:

• Сделать светлый минималистичный сайт с крупными заголовками и формой заявки на первом экране.

2. Отсутствие приоритетов

Не все пожелания одинаково важны. Если не расставить приоритеты, можно потратить ресурсы на второстепенные фичи, а основная задача останется невыполненной. Лучше разделить их на:

• обязательно;
• желательно;
• можно убрать, если не хватает бюджета.

3. Нет списка страниц

Если не прописать структуру, часть разделов может просто не попасть в проект. Классика: заказчик уверен, что страница «О компании» есть, а исполнитель про нее не знает.

4. Неясно, кто дает материалы

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

5. Не прописаны ограничения

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

6. Нет критериев приемки

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

Как сделать ТЗ понятным для исполнителя

Чтобы ТЗ было рабочим, а не просто документом для галочки, нужно писать короткими и однозначными формулировками. Длинные простыни текста с общими фразами никто не читает.

Хорошие правила

• используйте один термин для одного объекта (не называйте форму то «формой», то «анкетой»);
• не смешивайте цели и пожелания;
• не пишите «и так далее»;
• избегайте общих слов без расшифровки;
• прикладывайте примеры.

Хорошая формулировка

«На главной странице должны быть: первый экран, преимущества, услуги, отзывы, форма заявки, контакты». Такая формулировка не оставляет пространства для трактовок.

Плохая формулировка

«На главной странице нужно что-то интересное, удобное и информативное». А вот тут исполнителю придется гадать, что именно вы имели в виду.

Чек-лист перед передачей ТЗ

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

• цель сайта сформулирована конкретно и измеримо;
• целевая аудитория описана хотя бы в общих чертах;
• перечислены все страницы и основные блоки;
• учтены все важные функции;
• дизайн описан словами и примерами;
• понятно, кто и когда готовит контент;
• указаны этапы и сроки;
• есть критерии приемки;
• нет двусмысленных формулировок;
• все важные ограничения зафиксированы.

Мини-шаблон ТЗ на сайт

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

1. Общая информация

• Название проекта
• Заказчик
• Исполнитель
• Дата
• Версия документа

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

2. Цель проекта

• Что должен делать сайт
• Какой результат ожидается

Сформулируйте так, чтобы можно было проверить.

3. Аудитория

• Кто будет пользоваться сайтом
• Какие задачи решает
• Какие вопросы и возражения у посетителей

Краткое описание типичного пользователя.

4. Структура

• Список страниц
• Основные блоки на каждой странице

Для лендинга — последовательность секций.

5. Функционал

• Формы
• Кнопки
• Интеграции
• Дополнительные сервисы

Перечислите все, что должно работать.

6. Дизайн

• Стиль
• Цвета
• Примеры
• Ограничения

Укажите хотя бы два-три референса.

7. Контент

• Кто готовит тексты
• Кто дает фото
• Нужны ли видео и иконки

Распределите ответственность.

8. Технические требования

• Адаптивность
• Скорость
• Браузеры
• SEO
• Аналитика

Обязательный минимум.

9. Сроки

• Этапы
• Даты
• Ответственные

Хотя бы примерные.

10. Приемка

• Что считается готовым результатом

Критерии готовности.

Когда ТЗ можно делать коротким, а когда — подробным

Уровень детализации ТЗ зависит от сложности проекта. Если речь о простом лендинге на конструкторе, можно обойтись коротким документом. Если вы запускаете интернет-магазин с интеграциями и командой разработчиков, потребуется подробное описание. Вот ориентиры.

Короткое ТЗ подходит, если:

• нужен простой лендинг;
• сайт делается на конструкторе;
• функционал минимальный;
• сроки очень сжатые.

Подробное ТЗ нужно, если:

• сайт многостраничный;
• есть сложные формы и интеграции;
• подключается каталог или оплата;
• в проекте участвуют несколько специалистов;
• есть риск споров по объему работ.

FAQ

Нужно ли делать ТЗ для простого сайта?

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

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

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

Сколько страниц должно быть в ТЗ?

Строгого лимита нет. Для лендинга хватит 1–3 страниц описания, для большого сайта документ может быть значительно объемнее. Объем диктуется сложностью, а не желанием написать побольше.

Что важнее всего в ТЗ?

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

Можно ли менять ТЗ в процессе?

Да, но любые изменения лучше фиксировать письменно. Иначе легко потерять часть договоренностей и получить спор по срокам или бюджету. Гибкость нужна, но все изменения должны быть задокументированы.

Вывод

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