Техническое задание на сайт: зачем нужно и как составить

Вы решились на сайт, нашли подрядчика, ударили по рукам — а через два месяца получаете совсем не то, что представляли. Цвета не те, важного раздела нет, зато есть блок, о котором вы не просили. Начинается спор: вы говорите «мы так не договаривались», подрядчик отвечает «а где это написано?». И крыть нечем — нигде. Именно чтобы этого не случилось, существует техническое задание на сайт. Это документ, который переводит ваши ожидания на понятный обеим сторонам язык и превращает устные «ну вы поняли» в конкретные пункты. Разберём без занудства: зачем ТЗ нужно лично вам как заказчику, что в нём должно быть и как его составить, даже если вы не технарь.

Что такое техническое задание простыми словами

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

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

Зачем ТЗ нужно именно вам, а не только подрядчику

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

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

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

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

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

1. Цель сайта и задачи. Зачем он нужен: собирать заявки, показывать портфолио, продавать онлайн. От цели зависит всё остальное.
2. Целевая аудитория. Кто ваш клиент, как он принимает решение, что для него важно. Это влияет на структуру и тексты.
3. Структура сайта. Список страниц и разделов: главная, услуги, цены, о компании, контакты, блог. По сути — карта сайта.
4. Содержание страниц. Какие блоки на каждой странице: экран с заголовком, преимущества, отзывы, форма заявки.
5. Функциональность. Что сайт должен уметь: формы, онлайн-оплата, личный кабинет, калькулятор, интеграция с CRM или мессенджерами.
6. Дизайн и стиль. Ваши цвета, логотип, примеры сайтов, которые нравятся и не нравятся, общее настроение.
7. Технические требования. Адаптивность под телефоны, скорость загрузки, базовая SEO-готовность, на какой платформе делаем.
8. Кто даёт контент. Тексты, фото, логотип — вы предоставляете или подрядчик готовит. Это частый источник конфликтов.
9. Сроки и этапы. Когда что готово: макет, вёрстка, наполнение, запуск.
10. Критерии приёмки. Как вы поймёте, что работа сделана: сайт открывается, формы приходят на почту, всё работает на телефоне.

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

Пример: как расплывчатое ТЗ стоит денег

Возьмём типичную историю. Владелец студии натяжных потолков заказал сайт и сформулировал задачу так: «Нужен современный сайт с ценами и формой заявки, бюджет 60 000 рублей». Подрядчик кивнул и начал делать.

Что пошло не так. Заказчик держал в голове калькулятор стоимости потолка по площади комнаты — а в ТЗ этого не было, была просто «форма заявки». Подрядчик сделал обычную форму. Когда всплыл калькулятор, оказалось, что это отдельная разработка на 25 000 рублей и плюс две недели к сроку. Дальше выяснилось, что фото работ должен был предоставить заказчик, а он думал, что подрядчик найдёт сам — ещё неделя простоя. В итоге проект, который планировали за месяц и 60 тысяч, вышел на полтора месяца и 85 тысяч, причём с осадком у обеих сторон.

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

Мифы про техническое задание

Миф 1: «ТЗ — это на сто страниц и на птичьем языке». Огромные формальные ТЗ нужны крупным IT-проектам с интеграциями и десятками ролей. Для сайта услуг рабочее ТЗ — это 3–7 страниц понятного текста. Объём должен соответствовать задаче, а не пугать.

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

Миф 3: «Есть договор, ТЗ ни к чему». Договор регулирует деньги и ответственность, но что именно делаем — описано в ТЗ. Обычно ТЗ идёт приложением к договору и становится его частью. Одно без другого работает плохо.

Миф 4: «ТЗ всё зафиксирует, и менять ничего нельзя». Наоборот, ТЗ делает изменения управляемыми. Захотели добавить раздел — вносите правку, пересчитываете цену и срок. Плохо не менять, плохо менять втихую и без документа.

Когда подробное ТЗ оправдано, а когда избыточно

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

• Простой сайт-визитка или лендинг. Хватит короткого ТЗ: цель, структура, содержание блоков, кто даёт контент, сроки. Пара страниц.
• Корпоративный сайт с каталогом услуг. Средний уровень детализации: добавляются описание функций, требования к формам и интеграциям, критерии приёмки.
• Интернет-магазин или сайт с личным кабинетом, оплатой, интеграциями. Здесь подробное ТЗ обязательно: каждая функция описывается отдельно, иначе цена и сроки поплывут гарантированно.

Ориентир простой: чем больше в проекте «умных» функций и денег, тем детальнее ТЗ. Если сомневаетесь — лучше описать чуть подробнее. Лишний абзац в документе стоит бесплатно, а недосказанность — реальных денег на переделках.

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

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

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

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

Частые ошибки при составлении ТЗ

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

• Размытые формулировки. «Красиво», «удобно», «продающе» — это не требования, а пожелания. Каждый поймёт по-своему. Заменяйте на конкретику.
• Молчание про контент. Если не договориться, кто даёт тексты и фото, проект встанет ровно на этом.
• Нет критериев приёмки. Без них спор «готово или нет» превращается в бесконечность. Опишите, как проверяете результат.
• Копирование чужого ТЗ целиком. Шаблон полезен как каркас, но ваш бизнес уникален. Слепая копия тянет за собой чужие ошибки.
• ТЗ без согласования с подрядчиком. Документ, который исполнитель не читал и не подтвердил, юридически почти бесполезен.

Короткий вывод и что делать дальше

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

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

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