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

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

Техзадание — самая скучная часть проекта, которая спасает все остальное

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

Что это дает вам как заказчику:

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

ТЗ для создания сайта и договор не взаимозаменяемые документы. Договор отвечает за юридическую сторону вопроса, ТЗ — за техническую. Вместе они закрывают проект с двух сторон.

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

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

Один пишет, второй направляет. Так рождается хорошее ТЗ

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

Что от вас нужно:

• Рассказать о компании, товарах или услугах и о том, для кого вы все это делаете.
• Объяснить, зачем вам вообще сайт.
• Поделиться идеями и пожеланиями.
• Показать примеры сайтов, которые вам нравятся.
• Отвечать на вопросы исполнителя.

Можете предложить и свой вариант ТЗ для создания сайта, иногда это заметно ускоряет дело.

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

Идеальный вариант — писать техзадание вместе. Вы делитесь видением, исполнитель — опытом. И тогда все сходится.

Почему плохое техническое задание — это дорого

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

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

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

Анатомия рабочего технического задания

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

Что за проект и зачем он бизнесу

Первый блок отвечает на два вопроса сразу: что мы делаем и что изменится после запуска. Цель должна быть измеримой, иначе ее нельзя проверить. Сюда же — общее описание проекта: тип сайта, его масштаб, для кого он создается.

Для кого все это

Целевая аудитория — не абстрактные «все». Это конкретные люди с возрастом, интересами, задачами и болями. Чем точнее портрет, тем легче дизайнеру и копирайтеру говорить с этими людьми на одном языке.

Кто чем пользуется

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

Как все происходит

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

Что на экране

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

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

Откуда и куда текут данные

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

Кто делает контент

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

Как это выглядит

Дизайн — это не «красиво и современно», а вполне конкретные вещи. Цвета, шрифты, логотип, общий стиль и расположение элементов на странице должны быть прописаны, а не оставлены на усмотрение дизайнера. Если есть брендбук — отлично, если нет — подберите хотя бы референсы, чтобы исполнитель понимал, к чему вы стремитесь. И отдельно стоит упомянуть версию для слабовидящих, если она вам нужна, потому что это отдельный слой работы.

Скорость, адаптив, безопасность

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

Персональные данные — отдельной строкой

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

Как понять, что все готово

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

Что не нужно делать на данном этапе

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

SEO-настройки

Еще один блок, который часто откладывают на потом — SEO-настройки. А зря, потому что если вы планируете продвигать сайт, то без них не обойтись буквально с первой минуты. Нужны человеко-понятные адреса, описания у изображений, карта сайта, файл robots.txt, микроразметка и грамотные редиректы. Все это лучше заложить сразу, а не переделывать потом, когда сайт уже проиндексирован поисковиками.

Сколько это займет

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

Что после запуска

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

Не все сайты делаются по одному лекалу

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

Лендинг

Задача такого сайта — продать одну услугу или товар, либо собрать заявки. В ТЗ важно прописать сценарий: как человек идет к цели. Например, зашел, посмотрел видео, оставил заявку. Дальше — блоки. Перечислите их сверху вниз: первый экран, боль, решение, кейсы, отзывы, форма. Отдельно опишите формы: какие поля обязательны, куда падают заявки — на почту, в CRM или в Telegram. Не забудьте про аналитику: установка целей на клики и отправку форм обязательна. Если нужен квиз, распишите логику ветвления — выбрал «А», покажи вопрос «Б».

Корпоративный портал

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

Онлайн-магазин

Здесь техзадание будет больше за счет дополнительных пунктов, к нему добавится:

• Каталог. Глубина вложенности категорий, фильтры по цвету, размеру, цене, сортировка.
• Карточка товара. Вариации, остатки на складе, фотогалерея, видео, отзывы, похожие товары.
• Корзина и оформление заказа. Гостевой заказ или обязательная регистрация, способы доставки и оплаты.
• Личный кабинет с историей заказов, статусами и бонусами.

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

Промо-сайт

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

90% трафика придет с телефонов, так что внимательно продумайте требования к мобильной верстке.

Блог или медиа

Цель — публикация контента, монетизация, удержание аудитории. В задании опишите редактор: насколько удобно вставлять фото, видео, цитаты, галереи. Продумайте таксономию — теги, рубрики, авторы. Решите, как будут работать комментарии: встроенные или через сторонний сервис, а также нужна ли модерация. Добавьте умный поиск по статьям. Не забудьте про RSS и форму подписки на новые материалы. И отдельное требование — скорость: оптимизация изображений и кэширование должны быть в приоритете.

Не спешите подписывать: чек-лист по техзаданию

Перед тем как согласовать ТЗ, устройте себе небольшую проверку, чтобы потом не было мучительно больно из-за споров и переделок.

Общие сведения:

• Цель сайта сформулирована так, что через полгода можно однозначно сказать: достигли ее или нет.
• Описана целевая аудитория: кто они, возраст, какие задачи решают, с каких устройств заходят.
• Есть 2-3 примера конкурентов или референсов дизайна.
• Указаны сроки и бюджет — вилка или фикс.
• Понятно, кто принимает решения со стороны заказчика.
• Отдельным пунктом — что в работу не входит. Это спасает от споров в конце.

Структура и функционал

• Есть карта сайта — все страницы и разделы, включая те, о которых обычно вспоминают в последний момент: 404, раздел с частыми вопросами, страница с условиями возврата, результаты поиска.
• Описаны ключевые сценарии пользователя: что делает, куда кликает.
• У каждой кнопки и формы есть понятное поведение: что нажимаем, что происходит дальше.
• Перечислены все формы: какие поля обязательные или нет, куда уходят данные.
• Указаны внешние связи: CRM, 1С, платежные системы, службы доставки, карты и геосервисы, аналитика, сервисы рассылки и чат.
• Прописана админка — что редактируется без программиста.
• Указаны роли пользователей и права доступа, если есть личный кабинет.

Дизайн и контент

• Есть референсы или брендбук: цвета, шрифты, логотип.
• Цвета и шрифты зафиксированы конкретными значениями, а не словами «фирменный» и «современный».
• Указан стиль и настроение: строгий, яркий, минимализм.
• Понятно, кто пишет тексты, кто делает фото и видео, и в какие сроки.
• Прописаны требования к адаптивности: как сайт выглядит на телефоне, планшете и десктопе.

Технические требования

• Выбрана CMS или платформа — либо указано «на усмотрение исполнителя».
• Указано, кто покупает и оплачивает хостинг и домен.
• Есть цифры по скорости загрузки, а не пожелание «чтобы быстро».
• Указаны браузеры и устройства для поддержки.
• Описаны требования к безопасности: SSL, защита форм, бэкапы.
• Прописано, что должен уметь поисковик: адреса, мета-теги, карта сайта.
• Этапы разбиты с датами и результатом каждого. Не «дизайн», а «дизайн главной и каталога к такому-то числу».

Приемка и передача

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

Как выглядит готовое техзадание

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

1. Общие сведения о проекте

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

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

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

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

3. Роли пользователей и права доступа

На сайте предусмотрены четыре категории пользователей:

• Гость — просмотр меню, формирование корзины, оформление заказа без регистрации.
• Клиент — зарегистрированный пользователь с доступом к истории заказов, сохраненным адресам и функции повторного заказа.
• Оператор — сотрудник, обрабатывающий заказы в административной панели и изменяющий их статусы.
• Администратор — управление меню, ценами, акциями, зонами доставки и учетными записями операторов.

Разграничение прав фиксируется на этапе проектирования: гость не имеет доступа к чужим заказам, оператор не редактирует меню, администратор обладает полным доступом.

4. Пользовательские сценарии

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

5. Структура сайта и функционал

• Главная страница — знакомство с кухней, акции, переход к меню и заказу, блок популярных блюд.
• Меню — две основные категории: японская кухня и пицца. Внутри — подкатегории: роллы, суши, сеты, напитки; пицца классическая, авторская, комбо. В карточке блюда — фото, состав, вес, цена, кнопка добавления в корзину.
• Корзина — список выбранных блюд, изменение количества, удаление позиций, расчет стоимости доставки.
• Оформление заказа — единый экран с полями: имя, телефон, адрес, комментарий, способ оплаты.
• Личный кабинет — история заказов, сохраненные адреса, повторный заказ.
• Административная панель — управление меню, ценами, акциями, зонами доставки, заказами и статусами без участия программиста.

6. Интеграции и обмен данными

Заказы передаются в CRM. Оплата — через эквайринг с поддержкой карт и СБП. Уведомления клиенту — SMS или мессенджер. Аналитика — Яндекс.Метрика и Google Analytics. При недоступности внешнего сервиса заказ сохраняется в системе и отображается оператору для ручной обработки.

7. Контент и материалы

Фото блюд и описания предоставляет заказчик. Тексты для главной и разделов готовит исполнитель на основе брифа. Меню и цены передаются заказчиком в Excel за неделю до начала наполнения.

8. Дизайн и визуальные требования

Цветовая гамма — теплые оттенки: темно-красный, графитовый, кремовый. Шрифты — современные, читаемые. Логотип предоставляется заказчиком. Стиль — чистый, с акцентом на фотографии блюд, без избыточной анимации. Версия для слабовидящих не требуется.

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

Корректное отображение на персональных компьютерах, планшетах и смартфонах. Поддержка браузеров Chrome, Safari, Firefox, Edge. Время загрузки страницы — не более 1,5 секунд. Защита данных пользователей, оплата через защищенное соединение.

10. Персональные данные

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

11. Критерии приемки

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

12. Границы этапа

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

13. SEO-требования

Человеко-понятные адреса, ALT-описания изображений, карта сайта, файл robots.txt, микроразметка для блюд и ресторана, настройка редиректов.

14. Сроки и этапы работ

Прототипирование — 1 неделя. Дизайн — 2 недели. Верстка и программирование — 3 недели. Наполнение и тестирование — 1 неделя. Запуск — 2 дня. Каждый этап завершается результатом, подлежащим проверке.

15. Гарантии и поддержка

Гарантийная поддержка — 2 месяца с момента запуска. Включает исправление ошибок и консультации по работе с административной панелью. Права на исходный код и дизайн переходят заказчику после полной оплаты.