Пример техзадания на разработку сайта

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

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

Зачем нужен подробный документ и кому он нужен

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

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

Принципы составления ТЗ

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

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

Структура идеального техзадания

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

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

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

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

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

2. Цели и задачи проекта

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

Пример формулировки: "Задача — увеличить количество лидов с сайта на 30% за 6 месяцев. KPI — количество заполненных форм, заявок через онлайн-чат и время на странице с формой." Такие формулировки позволяют планировать интеграции с аналитикой и выбирать нужные инструменты.

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

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

Например: "Пользователь А — менеджер по закупкам, 30-45 лет, ищет техническую документацию и условия сотрудничества. Пользователь Б — частный покупатель, 25-40 лет, важны отзывы и оплата картой." Такие профили определяют структуру и содержание страниц.

4. Анализ конкурентов и референсы

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

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

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

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

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

Функции для пользователя

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

Не забывайте о мобильной версии — многие функции должны работать одинаково удобно на экране смартфона.

Функции для администратора

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

Если нужна интеграция с CRM или 1С, опишите сценарий передачи данных: какие поля, в каком формате, когда происходит синхронизация.

6. Нефункциональные требования

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

Пример формулировки: "Время загрузки главной страницы не более 2,5 секунд при условии соединения 4G и средней мощности сервера. Поддержка последних двух версий Chrome, Firefox, Safari и Edge." Так разработчик понимает ожидания по оптимизации.

7. Контент, структура и карта сайта

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

Заполните такую таблицу для всех страниц. Это поможет на этапе оценки объема работ и при составлении прототипов.

8. Дизайн и брендбук

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

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

9. Технические требования и стек технологий

Укажите, готовы ли вы использовать определенный CMS или фреймворк. Многие клиенты предпочитают WordPress, потому что он простой для изменения контента, но у крупных проектов могут быть свои требования к технологиям — например, React, Laravel, Django и др.

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

10. Интеграции и внешние сервисы

Если проект предполагает интеграцию с CRM, платежными системами, службами доставки, аналитикой или сторонними API — перечислите их и опишите сценарии обмена данными. Укажите форматы передачи, требования к безопасности и частоту синхронизации.

Например: "Интеграция с Яндекс.Кассой — при успешной оплате обновлять статус заказа в CRM, отправлять уведомление менеджеру по email." Такие сценарии помогают оценить сложность интеграции.

11. Хостинг, домен и поддержка

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

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

12. Безопасность и защита данных

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

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

13. SEO и аналитика

Если сайт должен быть видимым в поиске, включите базовые SEO-требования: корректные title и meta, человекопонятные URL, карта сайта, микроразметка и настройка редиректов. Опишите желаемые показатели и инструменты аналитики — Google Analytics, Яндекс.Метрика, GTM.

Также уточните, кто отвечает за SEO-контент: подрядчик создает шаблоны, а заказчик заполняет тексты, или подрядчик делает полное сопровождение. Это влияет на сроки и стоимость.

14. Тестирование и приемка работ

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

Рядом с каждым пунктом функционала укажите чек-листы для приемки: что проверяет заказчик и какие баги считаются критичными. Пример: "Форма обратной связи — при отправке показывается сообщение об успехе, на почту приходит письмо с данными, данные сохраняются в базе." Такие критерии ускоряют приемочный этап.

15. График работ и бюджет

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

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

16. Дополнительные приложения

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

Также полезно приложить шаблон контент-плана или пример заполнения карточки товара — так вы зададите стандарт качества контента и оформления.

Примеры формулировок и шаблонные блоки

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

Пример описания функционала формы обратной связи

Форма обратной связи должна содержать поля: Имя (обязательно), Email (обязательно, проверка формата), Телефон (необязательно), Сообщение (обязательно, минимум 10 символов). После отправки пользователь видит сообщение об успешной отправке, данные сохраняются в базе, на указанный email отправляется уведомление менеджеру.

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

Пример описания карточки товара

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

SEO: у каждой карточки уникальный title и meta-description, автоматические хлебные крошки и семантическая разметка Product schema.

Чек-листы для составления и проверки ТЗ

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

• Определены цели и измеримые KPI?
• Есть список страниц и приоритеты?
• Прописан желаемый стек технологий или CMS?
• Указаны критерии приемки для ключевых функций?
• Приложены логотипы и брендовые материалы?
• Описаны правила работы с контентом и SEO-требования?
• Указаны ответственные лица и контактные данные?
• Определен бюджет и сроки по этапам?

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

Шаблонное ТЗ для небольшого бизнеса (короткий вариант)

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

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

• Название проекта
• Контакты заказчика
• Цель сайта (KPI)
• Список страниц с приоритетом
• Список ключевых функций
• Референсы по дизайну
• Желаемый бюджет и сроки

Этот набор подходит, когда надо быстро получить коммерческое предложение. Но помните: чем полнее ТЗ, тем точнее оценка и меньше правок на финише.

Как оценивать полученные от подрядчика ответы

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

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

Типичные ошибки в техзаданиях и как их избежать

Ошибка 1: слишком общие формулировки. Решение — конкретизируйте поведение системы и добавляйте примеры. Ошибка 2: отсутствие критериев приемки. Решение — опишите чек-листы и приемочные сценарии. Ошибка 3: неучет мобильной версии. Решение — прописывайте требования адаптивности.

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

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

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

Используйте таск-трекер для управления задачами и фиксации правок. Это оставляет след и уменьшает риск "я просил" — "я не видел". При каждом изменении в ТЗ фиксируйте обновленную версию и дату.

Заключение и шаблон для скачивания

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

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

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

Пример техзадания на разработку сайта