Как писать ТЗ на разработку сайта. Пример ТЗ сайта

Время чтения - 13 мин.

Дата публикации 04.09.2020 (обновлено 21.05.2026)

Как писать ТЗ на разработку сайта. Пример ТЗ сайта

Представьте: вы заказываете крутой стейк с розмарином, а повар, поняв вас как-то по-своему, приносит котлету по-киевски. Обидно? Еще бы. В разработке сайтов такое происходит на каждом шагу. Заказчик видит один результат, программист — другой. Итог: потерянные деньги, нервы и время.

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

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

Нужно ли создавать ТЗ для сайта: разрушаем мифы

Раянов Руслан, эксперт по платформе Falcon Space По опыту наших проектов могу сказать, что ТЗ уменьшает вероятность манипуляций и прожимов.

Что написано в ТЗ, то обязаны сделать.
Что не описано в ТЗ - делаем потом как Доп. Руслан Раянов, эксперт Falcon Space Многие заказчики относятся к ТЗ спустя рукава. Мол, программисты сами догадаются. Это главная ошибка.

Основная ценность техзадания в том, что оно превращает ваши «хотелки» в конкретные задачи для разработчика.

На практике это выглядит так:

Программист понимает задачу по-своему.
Всплывают детали, требующие доплат и лишнего времени.
Заказчик постоянно меняет требования («О, а давайте еще вот это!»).

Для дизайнера «красивый сайт» — это анимации и модный шрифт. Для программиста — чистый код. Для маркетолога — форма захвата лидов. ТЗ объединяет всех в одну команду.

Экономия на ТЗ оборачивается переделками. Иногда проект бросают и начинают заново с нуля. С новой командой. Но проблема не в команде, а в подходе заказчика. Если выводов не сделали — история повторится.

Что важно знать при создании технического задания: советы эксперта

ТЗ для сайта нужно заказчику и исполнителю

Заказчик получает то, что прописал. Исполнитель знает, что делать. Ни больше, ни меньше.

ТЗ должно быть понятно обеим сторонам. Если заказчик не понимает ТЗ, как он будет принимать работу?

Если детали не описаны — каждый додумает сам. А это прямой путь к скандалам и сорванным срокам.

Не пишите ТЗ сразу на весь проект целиком

Пока вы допишете, половина требований устареет. В процессе появятся новые идеи.

Автор ТЗ, увидев реализацию, понимает, что это не то, и начинает все переписывать. Разработчики в ярости: это ломает базу данных и архитектуру.

Лучший вариант: напишите базовое ТЗ на первую версию. И отдельно — план развития. В плане — направления без деталей. В ТЗ — конкретика на ближайшее время.

Как писать ТЗ для сайта? ТЗ пишет технарь вместе с заказчиком

Если ТЗ пишет только программист — получится точная, но бесполезная система. Формально работает, бизнесу не помогает.

Если ТЗ пишет заказчик — выходит каша. Важные детали упущены, нет структуры, язык не технический.

Идеал: технарь пишет ТЗ на основе обратной связи от заказчика. Заказчик объясняет бизнес-процессы, а IT-специалист переводит их в интерфейсы, структуры данных и связи.

ТЗ — это совместная работа двух сторон. Не перекладывайте ее на кого-то одного.

Перед тем как составить ТЗ, ответьте на главный вопрос: какую бизнес-задачу решает сайт? «Привлечь клиентов» — слишком размыто. Лучше: «Увеличить заявки на 25% за квартал» или «Снизить нагрузку на колл-центр на 15% через чат-бота».

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

Лучше писать ТЗ вместе с будущим исполнителем. Так вы сэкономите на его погружении в проект.

Если вы заказчик, начните с концепции проекта. Изложите суть своими словами. Вот шаблон концепции веб-проекта.

ТЗ на веб-сервис — основание для договора и сметы

ТЗ определяет, что делать. На его основе составляют смету и сроки.

Без ТЗ точный бюджет назвать невозможно. Фразы вроде «сделайте как Авито» — красный флаг.

Лучшая схема: работа по этапам. Каждый этап — свое ТЗ, смета и сроки. Плохое ТЗ или его отсутствие рушит все:

Невозможно оценить смету. Разработчик закладывает запас на неопределенность.
Сроки летят. Появляются новые требования.
Приемка работ превращается в ад. Вечные споры «входит/не входит».

ТЗ — рабочий документ, а не формальность

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

Есть ГОСТы. Но они 30-летней давности и делают документ громоздким. Создание такого ТЗ — отдельный проект.

Главная задача ТЗ — понять, что нужно заказчику, зафиксировать это и начать делать.

Хотите быстрый сайт? Пропишите скорость загрузки. Нужна доступность? Укажите кроссбраузерность (Chrome, Firefox, Safari, Edge). Нужна оплата? Напишите, какую платежную систему интегрировать.

Техзадание для сайта: описание ЧТО + КАК

ТЗ может включать не только «что», но и «как». Детали реализации. Это ускоряет работу.

Раздел о дизайне — вечная боль. В пункт «требования к дизайну» добавляйте макеты. Это снимет 90% споров.

Отдельно — SEO-база. Даже если продвижение не в планах, заложите фундамент: ЧПУ-ссылки, мета-теги, заголовки, XML-карта. Это сэкономит деньги в будущем.

⚠️ Важно: Все, что не вошло в ТЗ, оплачивается отдельно. Это железное правило. Если работа не описана — она не заложена в бюджет. Не надейтесь на «авось».

Логика простая: смета составлена на основе ТЗ. Нет пункта в ТЗ — нет денег в смете.

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

Как составить ТЗ для сайта на базе платформы Falcon Space: пример и шаблон

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

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

Разберем разделы.

Общие сведения о системе

Раздел дает понимание: зачем мы это делаем и в чем фишка.

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

Ролей может быть несколько: директор, оператор, кассир. Определите их.

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

Не понимая стимула, вы сделаете никому не нужную систему.

Пользователь определяет успех системы. Нет пользователя — нет системы.

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

Роли и объекты системы

Детализируйте роли и их возможности.

Определите объекты: заказы, товары, клиенты. Для каждого — какие данные хранить: характеристики, логи, статусы.

Это поможет при создании базы данных. Не обязательно все сразу. Дописывайте по ходу.

Действуйте итеративно: описали базу — двигайтесь дальше. Потом вернетесь и дополните.

Бизнес-процессы

Опишите главные процессы. Учитывайте:

Последовательность действий. Если сложно — нарисуйте блок-схему.
Артефакты — доказательства действий: запись в журнале, документ, уведомление.
Не усложняйте. Простой процесс легче внедрить и изменить.
Укажите триггер (что запускает), актора (кто делает) и результат (что на выходе).

Важнее суть, а не форма. Это может быть просто список шагов.

Не увлекайтесь инструментами. Чем проще описание, тем легче его менять и читать.

Если нотацию понимаете только вы — толку ноль. Вред будет: описание есть, но им никто не пользуется.

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

Структура проекта и требования к страницам

Самый важный раздел для исполнителя. Здесь — что конкретно реализовать.

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

Потом — детальное описание каждой страницы. Мы используем Falcon Space, поэтому сразу привязываемся к компонентам платформы. Это ускоряет работу.

Описание страницы может включать:

Что выводим: таблицы, формы, колонки, кнопки, модальные окна. Максимально конкретно.
Действия кнопок. Что меняется? Что видит пользователь при успехе или ошибке?
Ограничения доступа. Кто может видеть страницу? Есть ли особые правила (например, только автор задачи меняет дедлайн)?

Любая неточность — повод для спора. Описывайте все понятно и конкретно.

Интеграции с внешними системами

Определите список внешних систем. Для каждой уточните:

1. Какие данные передавать и в какую сторону. Не «интеграция всего», а конкретные данные. Лучше — точный формат (например, JSON-структура).

2. Формат и протокол: GET-запросы по HTTPS, JSON.

3. Возможности внешней системы по интеграции. От этого стройте свой API.

4. API — фактор неопределенности. Если система неизвестна, заложите на первом этапе прототип API. Иначе разработчик заложит риски в бюджет.

Возможные расширения сайта в будущем

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

Проектирование базы данных

Элемент реализации. Пропишите начальную структуру: таблицы, столбцы, связи, индексы.

Почему это важно на раннем этапе? Можно показать структуру внешнему эксперту и получить фидбек. Ошибки в БД критичны. Лучше исправить их до создания базы или когда данных мало.

Техническому специалисту БД расскажет об объектах и их связях. Полезно текстом описать ключевые моменты: «Товар может принадлежать разным категориям, категории вложены на 3 уровня».

Заключение

Мы разобрали основные моменты составления ТЗ и наш шаблон. Хорошее ТЗ — не гарант успеха, но без него проект почти обречен. Переделки, хотелки заказчика, споры с разработчиками, смена команды — вот что ждет вас без ТЗ.

Сделайте акцент на ТЗ в начале — и избежите множества проблем в будущем.

Скачать шаблон технического задания на разработку сайта (Google Диск)

Часто задаваемые вопросы (FAQ)

Что такое техническое задание (ТЗ) на разработку сайта?

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

Обязательно ли составлять ТЗ?

Формально — нет. Но без ТЗ вы рискуете получить не то, что хотели, переплатить и потерять время. Практически все успешные проекты имеют ТЗ.

Кто должен писать ТЗ?

Совместно: заказчик (описывает бизнес-задачи) и технический специалист (переводит их в требования к системе).

Можно ли использовать готовый шаблон ТЗ?

Да. Мы даем ссылку на наш шаблон. Но его нужно адаптировать под ваш проект: добавить свои разделы, убрать лишнее.

Что делать, если в процессе разработки появились новые требования?

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

Как проверить, что ТЗ написано хорошо?

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

Что делать, если разработчик не выполняет ТЗ?

ТЗ — основа договора. Если разработчик отклоняется, это нарушение. Фиксируйте все несоответствия и требуйте исправления. Если проблема системная — меняйте подрядчика.

Итоговый чек-лист: 10 шагов к идеальному ТЗ

Определите бизнес-цель сайта. Не «привлечь клиентов», а «увеличить заявки на 25%».
Опишите пользователей и их роли. Кто будет работать с системой? Какие у них задачи?
Составьте структуру страниц. Таблица с URL, ролями и описанием.
Детально опишите каждую страницу. Что выводим, какие кнопки, что они делают.
Пропишите бизнес-процессы. Последовательность шагов, триггеры, результаты.
Укажите ограничения и правила. Например, «один сотрудник — одно управление».
Определите интеграции. С какими системами и как обмениваться данными.
Добавьте требования к дизайну и SEO. Макеты, скорость, кроссбраузерность, ЧПУ.
Спроектируйте базу данных. Хотя бы на начальном уровне.
Согласуйте ТЗ с заказчиком и исполнителем. Убедитесь, что все всё поняли.