Техническое задание — документ, который решает, получите ли вы через два месяца именно тот сайт, за который заплатили, или будете спорить с подрядчиком, доплачивать и сдвигать дедлайны. По нашему опыту в Euromedia (600+ проектов за 12 лет работы) около половины конфликтов между заказчиком и разработчиком начинаются с одного: «в ТЗ этого не было». Не потому, что кто-то жульничает, — просто никто не записал, что именно нужно сделать.
Хорошая новость: составить толковое ТЗ может даже человек без технического бэкграунда. Плохая: шаблон «скачать за минуту» без понимания структуры создаёт иллюзию готовности, а не само задание. Ниже — рабочий каркас ТЗ, примеры формулировок, которые реально что-то значат, и 8 типичных ошибок заказчиков, каждая из которых раздувает бюджет и сроки.
Что должно быть в ТЗ: структура по разделам
Техническое задание на сайт — это не сочинение и не презентация. Это перечень требований, по которому разработчик может оценить объём работ, назвать срок и цену, а вы — принять результат. Минимально рабочий ТЗ состоит из девяти разделов.
1. Цели и задачи сайта
Без цели сайт превращается в «красиво и современно» — а это не цель. Укажите 1–3 конкретные задачи: продавать, собирать заявки, информировать, поддерживать имидж. Хорошо, если цель измерима: «получать не менее 30 заявок в месяц», а не «увеличить продажи». Измеримая цель влияет на структуру: сайт под заявки и сайт-каталог проектируются по-разному.
2. Целевая аудитория
Кто придёт на сайт и что он должен там сделать. «Владельцы малого бизнеса» — слишком широко. «Руководители производственных компаний из Беларуси, которые ищут подрядчика и сравнивают 3–4 предложения» — уже рабочий портрет. Аудитория определяет язык текстов, глубину информации и даже дизайн: сайт для конечных покупателей и сайт для b2b-партнёров — разные продукты.
3. Структура страниц
Перечислите все страницы и разделы: главная, о компании, услуги (каждая услуга — отдельная страница или одна общая?), каталог/портфолио, блог, контакты. Для каждой страницы — одним предложением, что на ней должно быть. Это самый частый источник недопонимания: заказчик думает, что «страница услуг» — это одна страница, а подрядчик заложил в смету десять.
4. Дизайн
Опишите ожидания честно, но без попытки спроектировать самому. Достаточно: общий стиль (строгий, минималистичный, яркий), примеры сайтов, которые нравятся и которые не нравятся — с пояснением, что именно. Укажите фирменные цвета, логотип, есть ли брендбук. Отдельно — адаптивность: сайт обязан корректно работать на мобильных, но стоит зафиксировать, какие устройства приоритетны (в Беларуси больше половины трафика — мобильный).
5. Функционал
Самый важный раздел для оценки стоимости. Перечислите всё, что сайт должен делать: формы обратной связи, калькулятор, личный кабинет, онлайн-оплата, фильтры каталога, интеграция с CRM, мультиязычность, карта, чат. По каждому пункту — как это должно работать, хотя бы в двух предложениях. «Интеграция с CRM» без деталей — это от «передавать заявки на почту» до «двусторонняя синхронизация сделок» — разница в цене в разы.
6. Контент
Кто готовит тексты, фото и видео — вы или подрядчик? Сколько страниц нужно наполнить? Это раздел, который чаще всего «забывают», а потом сайт стоит готовый, но пустой, потому что тексты никто не написал. Если тексты пишет подрядчик — укажите объём и тематику; если вы — зафиксируйте срок предоставления материалов, иначе запуск будет ждать контента месяцами.
7. Сроки
Разбейте проект на этапы с датами: дизайн-макет, вёрстка, наполнение, тестирование, запуск. Отдельно пропишите, сколько дней вы закладываете на свои согласования — правки с вашей стороны тоже занимают время, и честный подрядчик это учтёт.
8. Бюджет
Укажите вилку, в которую хотите уложиться, или попросите разбить смету по этапам. Честный бюджет в ТЗ экономит время обеим сторонам: подрядчик сразу скажет, что реально сделать за эти деньги, а что — нет. Подробнее о том, из чего складывается цена, мы писали в статье о стоимости разработки сайта в Беларуси в 2026 году.
9. Поддержка и гарантии
Что происходит после запуска: гарантийный срок на исправление багов, кто обновляет движок и плагины, сколько стоит час доработок после сдачи. Сайт — не разовая покупка, а инструмент, который живёт и требует ухода.
Сводная таблица — что писать в каждом разделе:
| Раздел ТЗ | Что обязательно указать | Частая ошибка |
|---|---|---|
| Цели | 1–3 измеримые задачи сайта | «Сделать красиво и современно» |
| Аудитория | Портрет посетителя и его действие на сайте | «Все, кому интересно» |
| Структура | Список всех страниц, содержание каждой | Подразумевать страницы «по умолчанию» |
| Дизайн | Стиль, примеры «нравится / не нравится», брендбук | Пытаться самому нарисовать макет в ТЗ |
| Функционал | Каждый модуль + как он должен работать | «Интеграция с CRM» без деталей |
| Контент | Кто готовит материалы, объём, сроки | Не указывать вообще |
| Сроки | Этапы с датами, время на ваши согласования | Один дедлайн «через месяц» на всё |
| Бюджет | Вилка или смета по этапам | Скрывать бюджет «чтобы не накрутили» |
| Поддержка | Гарантия, обновления, стоимость доработок | Думать, что после запуска всё закончилось |
Примеры хороших и плохих формулировок
Разница между плохим и хорошим ТЗ — в конкретике. Сравните: левая колонка — то, что разработчики читают каждую неделю, правая — то, с чем можно работать.
| Плохо (так писать не надо) | Хорошо (так понятно обеим сторонам) |
|---|---|
| Сайт должен быть современным и красивым | Дизайн в спокойных тонах, пример — [ссылка на сайт]; не нравятся кислотные цвета и анимация при наведении |
| Сделать удобную форму заявки | Форма: имя, телефон, поле «что интересует» (выпадающий список из 5 услуг), чекбокс согласия на обработку данных; заявка уходит на euromedia.by@yandex.by и в CRM |
| Нужен каталог товаров | Каталог на 200 позиций, фильтры по цене, производителю и наличию; карточка товара — фото, характеристики, кнопка «заказать» |
| Сайт должен быстро грузиться | Время загрузки главной страницы — до 3 секунд на мобильном интернете (проверяем через PageSpeed Insights) |
| Интеграция с соцсетями | Кнопки «поделиться» в статьях блога + виджет Instagram на главной |
| Сделать SEO-оптимизацию | Человеко-понятные URL, заполненные title/description на всех страницах, sitemap.xml, микроразметка Organization |
| Нужна мобильная версия | Адаптивная вёрстка под смартфоны от 360 px; на мобильных телефон в шапке — кликабельная кнопка звонка |
| Сайт на двух языках | Русская и английская версии; переключатель в шапке; переводы предоставляем мы в течение 10 дней после запроса |
Правило простое: если по пункту ТЗ разработчик вынужден задавать уточняющий вопрос — пункт написан плохо. Хорошее ТЗ отвечает на вопросы до того, как их задали.
8 ошибок заказчиков, которые удваивают бюджет и сроки
Эти ошибки мы видим из проекта в проект. Каждая по отдельности кажется мелочью, но в сумме они превращают разработку в 3 месяца в полгода, а бюджет — в цифру, которую никто не планировал.
Ошибка 1. «Сделайте как у конкурентов, только лучше»
Фраза, за которой нет содержания. Какой конкурент? Что именно «лучше» — дизайн, скорость, структура? Подрядчик угадывает, вы разочаровываетесь, макет переделывается трижды. Вместо этого: дайте 2–3 ссылки и по каждой напишите, что конкретно берём (структуру каталога, подачу цен, тон текстов), а что не подходит.
Ошибка 2. ТЗ из трёх строк
«Нужен сайт-визитка, красиво, недорого, сроки — месяц». Такое ТЗ не защищает никого: подрядчик закладывает минимум, вы ждёте максимум, а при приёмке выясняется, что «мы думали, там будет калькулятор». Объём ТЗ пропорционален сложности проекта: для лендинга хватит 3–4 страниц, для интернет-магазина — 15–20. Но три строки — это не ТЗ, это заявка на консультацию.
Ошибка 3. Меняющиеся требования в процессе
Самая дорогая ошибка. На этапе дизайна вы просите «добавить раздел», на этапе вёрстки — «переделать структуру», после запуска — «а давайте ещё личный кабинет». Каждое изменение после утверждения этапа — это переделка уже сделанной работы. Выход: фиксируйте результат каждого этапа подписью (или письмом «утверждаю») и складывайте новые идеи в список «вторая очередь» — их реализуют после запуска, а не вместо него.
Ошибка 4. Контент «потом как-нибудь»
Сайт готов, а текстов нет, фото нет, логотип в низком разрешении. Проект встаёт на 2–3 месяца не по вине разработчика. Контент — это 30–40% работы над сайтом, и готовить его нужно параллельно с разработкой, а не после. В ТЗ зафиксируйте: кто готовит материалы и к какой дате. Нет материалов в срок — сдвигается запуск, и это честно прописано заранее.
Ошибка 5. Один человек решает всё «на глаз»
Дизайн согласует директор, тексты правит бухгалтер, структуру меняет «знакомый, который разбирается». Результат — противоречивые правки и бесконечные итерации. Назначьте одного ответственного за проект с вашей стороны, который собирает мнения внутри компании и передаёт подрядчику единую позицию. Один голос — один цикл правок.
Ошибка 6. Экономия на прототипе
«Давайте сразу дизайн, прототип — лишняя трата». Прототип (схема страниц без красоты) стоит недорого, а показывает структуру и логику до того, как дизайнер потратил на неё неделю. Переделать схему — час, переделать готовый дизайн — дни. Пропуск прототипа — классический способ заплатить дважды: за переделку того, что можно было поправить на бумаге.
Ошибка 7. Не зафиксированы критерии приёмки
Как вы поймёте, что сайт готов? Если в ТЗ нет ответа, приёмка превращается в «что-то не то, но не знаю что». Пропишите проверяемые критерии: сайт открывается в Chrome, Safari и Яндекс Браузере; формы отправляют заявки на указанную почту; скорость загрузки — до 3 секунд; все страницы из структуры на месте. Приёмка по чек-листу занимает час вместо недели переписок.
Ошибка 8. «Поддержка не нужна, разберёмся сами»
Через полгода после запуска: движок не обновлялся, плагин конфликтует, сайт лежит в выходные. Разбираться самим — значит чинить в авральном режиме и дороже. Минимальный пакет поддержки (обновления, бэкапы, мелкие правки) стоит несопоставимо дешевле восстановления упавшего сайта. Вопрос поддержки решайте до подписания договора, а не после первого сбоя.
Как Euromedia работает по ТЗ
За 12 лет и 600+ проектов мы выработали процесс, в котором ТЗ — не формальность, а рабочий инструмент. Выглядит он так:
1. Бриф. Короткая анкета на 20–30 вопросов: о бизнесе, аудитории, конкурентах, ожиданиях. Заполняется за 30–40 минут и уже на этом этапе убирает половину недопонимания. Если у вас нет готового ТЗ — бриф станет его основой, мы поможем.
2. Прототип. Схема ключевых страниц: где что расположено и как посетитель движется к заявке. Вы видите логику сайта до дизайна и можете поправить её за час, а не за неделю.
3. Договор с фиксацией ТЗ. Техническое задание становится приложением к договору. Это защищает обе стороны: вы получаете гарантию, что всё из ТЗ будет сделано, мы — гарантию, что объём работ не вырастет «по ходу дела» без доплаты. Изменения после подписания — только через допсоглашение с оценкой сроков и стоимости. Никаких сюрпризов.
4. Разработка по этапам. Дизайн → вёрстка → программирование → наполнение. Каждый этап вы принимаете отдельно: смотрите, проверяете по ТЗ, утверждаете. Пока этап не принят, дальше не идём — так ошибки ловятся рано, когда их дёшево исправлять.
5. Тестирование. Проверяем сайт по чек-листу: формы, адаптивность, скорость, корректность в разных браузерах, битые ссылки. Вы получаете сайт, который уже проверен, а не «вроде работает».
6. Запуск и поддержка. Перенос на ваш хостинг (или наш), обучение управлению сайтом, гарантийный период на исправление ошибок. Дальше — пакет поддержки по желанию: обновления, бэкапы, развитие сайта.
Чек-лист: готово ли ваше ТЗ к передаче подрядчику:
- Цели сайта сформулированы измеримо (не «красиво»)
- Описана целевая аудитория и её действие на сайте
- Перечислены все страницы с кратким содержанием каждой
- Приложены примеры дизайна «нравится / не нравится»
- Каждый модуль функционала описан: что делает и как
- Указано, кто готовит контент и к какому сроку
- Сроки разбиты на этапы, заложено время на ваши согласования
- Обозначен бюджет или запрошена смета по этапам
- Прописаны критерии приёмки (что проверяем при сдаче)
- Решён вопрос поддержки после запуска
- Назначен один ответственный за проект с вашей стороны
Если отметили все пункты — подрядчик сможет назвать точные сроки и цену после первой же встречи. Если нет — вы теперь знаете, что дописать.
Итог
Хорошее ТЗ — это не бюрократия, а страховка: от срыва сроков, раздутого бюджета и сайта, который «не то, что заказывали». Девять разделов, конкретные формулировки вместо общих слов, зафиксированные критерии приёмки — и разработка превращается из лотереи в управляемый процесс.
Нет готового ТЗ — не проблема: приходите с идеей, дальше разберёмся вместе. Euromedia — digital-агентство из Дзержинска: 600+ проектов за 12 лет, разработка сайтов, SEO и реклама. Офис — ул. Фурманова, 33, работаем Пн–Пт с 9:00 до 17:30. Напишите нам на странице контактов, позвоните +375 (29) 256-33-94 или на euromedia.by@yandex.by — обсудим задачу, поможем составить ТЗ и назовём точные сроки и стоимость.
Частые вопросы
Нужно ли ТЗ, если заказываю простой сайт-визитку?
Да, но короткое. Даже для лендинга зафиксируйте: структуру блоков, тексты (кто пишет), 2–3 примера дизайна, критерии приёмки. Это 2–3 страницы вместо 20, но они так же защищают от «мы думали иначе».
Кто должен писать ТЗ — заказчик или подрядчик?
В идеале — вместе. Вы описываете бизнес-задачу, аудиторию и ожидания; подрядчик переводит это в технические требования и предупреждает о подводных камнях. В Euromedia бриф и прототип закрывают эту работу: вы отвечаете на вопросы о бизнесе, мы оформляем ТЗ как приложение к договору.
Сколько стоит разработка ТЗ?
Если ТЗ вырастает из брифа и прототипа в рамках проекта — обычно входит в стоимость разработки. Отдельная услуга «написать ТЗ под ключ» встречается, но чаще это часть предпроектной аналитики. Уточняйте у подрядчика до подписания договора.
Можно ли менять ТЗ после подписания договора?
Можно, но через допсоглашение: фиксируется, что меняется, насколько сдвигаются сроки и как меняется цена. Так честно для обеих сторон. Хаотичные правки «по ходу» без фиксации — главная причина срыва сроков, см. ошибку №3 выше.
Что делать, если подрядчик работает без ТЗ вообще?
Насторожиться. Работа без зафиксированного объёма — это устные договорённости, которые при споре ничего не стоят. Минимум — переписка с перечнем работ и скриншотами макетов; но полноценное ТЗ как приложение к договору надёжнее.
ТЗ — это то же самое, что бриф?
Нет. Бриф — это вопросы подрядчика вам (что за бизнес, кто клиенты, что нравится). ТЗ — это ответы, оформленные как требования к результату: что именно будет сделано и как проверяется. Бриф — вход, ТЗ — выход.
Как понять, что ТЗ достаточно подробное?
Простой тест: дайте ТЗ двум независимым разработчикам. Если оба назвали близкие сроки и цену без десятка уточняющих вопросов — ТЗ хорошее. Если каждый спрашивает своё — дописывайте разделы.