Роман Тишкин

Роман Тишкин

Креативный директор, основатель

Как составить техническое задание на разработку сайта — гайд от мэдсевен

madseven_cinematic_digital_illustration_of_glowing_neon_green_0a149d70-3c64-4e4f-a0b0-768ca647809f_1.png 07.11.2025

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

Зачем техническое задание вообще нужно (и кому)

Заказчику:

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

Команде исполнителя

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

Юристам и менеджерам

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

Ключевая мысль: техническое задание не должно быть «про всё на свете». Оно должно быть про конкретный сайт, конкретные бизнес-задачи и измеримые критерии качества — чтобы результат можно было проверить, а не обсуждать на ощущениях.

Принципы хорошего технического задания

Конкретность

Формулировки должны быть однозначными. Не «красиво и современно», а: минимализм, контрастная типографика, без параллакса, светлый фон, акцентный цвет #00FF75, адаптив под 320–1920 px.

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

Полнота по критичным темам

Не обязательно описывать каждую кнопку до пикселя, но ключевые блоки должны быть раскрыты:

  • функционал страниц и сценарии пользователя
  • интеграции (CRM, платёжные системы, аналитика)
  • роли и уровни доступа в админке
  • SEO-блок (мета-теги, ЧПУ, sitemap, robots.txt)
  • требования к безопасности и защите данных
  • требования к структуре и загрузке контента

Измеримость

Важно не «чтобы работало хорошо», а чтобы было понятно, как это проверить.

Например:

  • формы отправляют заявку на почту и в CRM
  • мобильная версия корректно работает на популярных устройствах

Структура

ТЗ — это рабочий документ, а не поток текста.

В нём должны быть:

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

Структура облегчает согласование, экономит время на доработках и делает документ управляемым.

Актуальность

Все технологические решения должны быть зафиксированы с уточнениями:

  • CMS и её версия
  • используемые библиотеки и фреймворки
  • сторонние сервисы
  • ограничения выбранных решений

Это защищает проект от ситуации «мы думали, что система умеет вот это». ТЗ должно отражать реальные возможности технологий на момент запуска проекта.

Структура технического задания на разработку сайта

(каркас мэдсевен — как мы реально работаем)

Вводные и цели проекта

Здесь отвечаем на главный вопрос: зачем вообще нужен сайт?

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

Целевая аудитория и сценарии

  • Кто наши клиенты: сегменты, их боли, сомнения, мотивация.
  • 2–3 ключевых сценария: человек пришёл → понял, что вы предлагаете → сравнил → оставил заявку или купил. Мы прописываем это заранее, чтобы сайт помогал принимать решение, а не просто «был».

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

Проще говоря — карта сайта.

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

Без этого сайт начинает расти хаотично и превращается в лабиринт.

Что сайт должен уметь

Здесь описываем функционал простым языком:

  • формы заявок
  • поиск и фильтры
  • личный кабинет
  • корзина и оплата
  • интеграции с CRM, 1С, доставкой, чатом

И отдельно — кто и что может делать в админке: администратор, редактор, менеджер.

Контент

Кто делает тексты, фото и видео? В каком объёме?

  • Какая тональность — строгая, экспертная, лёгкая.
  • Как оформляются тексты: заголовки, списки, длина блоков.

Это важно, чтобы сайт выглядел целостно, а не как сборник случайных материалов.

Дизайн

Не «сделайте красиво», а конкретно:

  • референсы
  • бренд-гайд
  • сетка и единый стиль блоков
  • состояния кнопок (наведение, ошибка, пустой результат)

И важный момент — доступность: читаемый контраст, возможность пользоваться сайтом с клавиатуры, корректные alt-тексты для изображений.

Технологии и где всё будет жить

  • На какой системе работает сайт.
  • Какие сервисы подключаются.
  • Где размещается хостинг.
  • Есть ли тестовая версия перед запуском.
  • Как делаются резервные копии.

Это защищает от сюрпризов и «а мы думали, оно работает иначе».

Скорость и качество

Мы заранее фиксируем:

  • допустимый размер страниц
  • оптимизацию изображений
  • чтобы сайт открывался за 2–3 секунды даже в нестабильной сети

Потому что если сайт грузится долго — клиент просто закрывает вкладку.

SEO

Чтобы сайт находили в поиске:

  • понятные адреса страниц
  • корректные заголовки и описания
  • карта сайта
  • редиректы, если что-то меняется

SEO лучше заложить сразу, чем переделывать потом.

Безопасность

  • защищённое соединение (HTTPS)
  • защита форм от спама
  • корректная работа с персональными данными
  • ограниченный доступ к админке

Сайт — это часть бизнеса, а значит, к нему применяются те же требования к безопасности.

Тестирование и приёмка

Перед запуском мы фиксируем:

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

Чтобы запуск был спокойным, а не стрессовым.

Этапы проекта

Прописываем порядок работ:

прототипы → дизайн → верстка → разработка → интеграции → тестирование → наполнение → запуск

И на каждом этапе — что именно согласовывается.

Бюджет и лицензии

  • разбивка стоимости по этапам
  • платные сервисы и плагины
  • кто оплачивает лицензии
  • кому принадлежат права на сайт

Чек-лист приёмки (сохраните себе)

  • Все целевые сценарии проходят от начала до конца.

  • Для большинства пользователей сайт открывается быстро и работает ровно.

  • Формы шлют данные в CRM и на почту, дубликаты отсекаются.

  • Метрики и события настроены, цели фиксируются.

  • SEO-основа: карта сайта, robots, редиректы, микроразметка.

  • Контент уникален, alt-тексты заполнены, доступность проверена.

  • Бэкапы и логи работают, роли доступа ограничены.

  • Передан пакет: исходники дизайна, исходники кода, инструкции, доступы.

FAQ коротко

Можно ли начать без технического задания?

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

Кто пишет техническое задание?

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

Сколько страниц в техническом задании?

Ровно столько, сколько нужно для ясности. Для лендинга это может быть 10–15 страниц, для сложного корпоративного сайта — 40–80 и больше. Важно не количество страниц, а отсутствие двусмысленностей: чтобы разработчики понимали, что делать, а заказчик — что получит в результате.

Что с правками?

Мы фиксируем согласованную версию ТЗ. Если в процессе появляются изменения — это нормально, бизнес живой. Но все новые задачи проходят через change-log и дополнительное согласование сроков и бюджета. Это защищает и проект, и обе стороны от «расползания» объёма работ.

Итог

Грамотное техническое задание — половина успеха «разработки сайта». Оно экономит деньги, сокращает сроки и избавляет от бесконечных «а давайте ещё вот это». Делайте техническое задание конкретным, измеримым и живым — таким, которым команда реально пользуется каждый день.

Если хотите, мэдсевен поможет разработать техническое задание под ваши цели, а затем реализовать сайт по нему — без сюрпризов и «ожидание/реальность». Напишите нам — обсудим задачу и соберём проект в понятный план.