Техническое задание на разработку сайта: кто его пишет и что туда точно стоит добавить

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

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

Что такое и зачем нужно ТЗ на разработку сайта?

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

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

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

Зачем составлять ТЗ на разработку сайта?

• Чёткое понимание задач. ТЗ помогает всем участникам проекта ясно понимать, что должно быть сделано. Это снижает вероятность ошибок и недопониманий.
• Экономия времени и денег. Составив ТЗ, вы избегаете ситуаций, когда приходится полностью переделывать ресурс или вносить крупные изменения на поздних этапах. Это защищает от лишних затрат.
• Контроль сроков. Написание ТЗ позволяет разбить проект на этапы и установить конкретные сроки выполнения каждой задачи, что помогает контролировать процесс и избегать задержек.
• Оценка стоимости проекта. Подробное техническое задание позволяет разработчикам точнее оценить стоимость создания сайта, ведь все требования уже известны.

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

• Неудовлетворительный результат. Если чётко не прописать, что должно быть на ресурсе, разработчики могут создать не тот продукт. Например, вы хотели крупный и функциональный интернет-магазин, а получили магазин, сделанный на конструкторе за неделю. Такое часто происходит, когда заказчик не разбирается в том, как происходит создание сайта и чем ресурсы в принципе отличаются друга от друга. В этом случае ориентируется он только на низкую цену. Иногда заказчик и разработчики действительно просто недопонимают друг друга. А иногда нерадивые студии специально обманывают клиентов, пользуясь тем, что они не разбираются в вопросе.
• Постоянные изменения в процессе работы. Этот пункт скорее вредит специалистам, которые занимаются разработкой. Без ТЗ клиент может менять требования на ходу, что сильно тормозит работу. Например, сначала он просит простой калькулятор, где пользователь сможет рассчитать стоимость работ. А потом решает добавить интерактивный блок, чтобы потенциальный клиент мог нарисовать виртуальную комнату и посмотреть, как в зависимости от выкладки будет выглядеть плитка, и уже потом узнать цену проекта.
• Срыв сроков. Когда задачи не определены заранее, разработчики могут столкнуться с неожиданными проблемами, что приведёт к затягиванию сроков создания сайта. Например, если сразу не указать необходимость адаптации ресурса под мобильные устройства, это может всплыть только на финальном этапе, требуя дополнительного времени. Конечно, хороший специалист сразу предупредит заказчика, что адаптация понадобится. Но это в идеальном мире. 
• Перерасход бюджета. Без подробного ТЗ сложно оценить реальную стоимость разработки. Например, если изначально не упомянуть о необходимости сложной фильтрации товаров, это может потребовать значительно больше вложений. В итоге заказчик может быть недоволен лишними затратами, и от работы с подрядчиком останется плохое впечатление.

Кто должен составлять ТЗ на разработку сайта?

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

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

1. Заказчик хорошо знает, что ему нужно: цели сайта, целевую аудиторию, функции и визуальный стиль. Возможно, он даже нашёл пару примеров площадок, которые ему нравятся, и может сказать, что именно стоит у них перенять. Но, скорее всего, ему не хватает технических знаний, чтобы правильно сформулировать детали.
2. Менеджер со стороны подрядчика — специалист, который легко может перевести идеи заказчика на технический язык. Так, чтобы их поняли специалисты, которые будут заниматься непосредственно разработкой. Также такой специалист сможет дополнить техническое задание на разработку сайта важными деталями: например, напомнить о требованиях к безопасности ресурса, скорости его работы или адаптации к разным типам экранов. Неопытный человек может об этом не подумать, а тот, кто разбирается в разработке, обязательно заложит на это бюджет и время. При этом наличие менеджера упрощает коммуникацию сторон. Заказчику не приходится общаться с дизайнерами, техническими специалистами, копирайтерами и другими. Эту работу делают за него.

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

Инструкция по составлению ТЗ на разработку сайта

​​Вот какая информация должна быть в техзадании:

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

Это раздел поможет больше узнать о компании и понять общую концепцию сайта и его предназначение.

• Информация о компании. Попросите заказчика кратко рассказать: чем занимается компания, сколько лет она на рынке, кто её основные конкуренты, какие товары или услуги считаются самыми популярными.
• Целевая аудитория. Уточните, кто целевая аудитория компании. От этого нужно будет отталкиваться при продумывании интерфейса, текстов, цветовой гаммы и других важных моментов. Знание целевой аудитории сразу поможет сделать сайт, который понравится потенциальным клиентам. Ведь часто бывает, что при разработке ресурса о маркетинговой стороне не думают вообще. А вспоминать об этом начинают только когда понимают, что площадка приносит мало продаж.
• Цели. Опишите основные задачи, которые должен решать сайт. Это может быть увеличение продаж, привлечение новой аудитории, улучшение имиджа компании и т. д. Например, кто-то хочет создать самый простой временный сайт, чтобы просто протестировать концепцию. Если это найдёт отклик, компания планирует создать другой более качественный ресурс, а пока не хочет тратить на него деньги. А кто-то сразу нацелен на долгосрочное развитие и готов вкладывать бюджет, чтобы сделать всё максимально продуманно и качественно.
• Тип площадки. Отталкиваясь от предыдущего пункта, укажите, какой именно ресурс нужен, так как это напрямую повлияет на подход к созданию сайта. Это может быть интернет-магазин, сайт с услугами, лендинг, визитка, блог и т. д.

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

В этом разделе подробно описываются ключевые функции ресурса. Здесь пожелания заказчика будут дополняться экспертным мнением специалиста по разработке.

• Структура сайта. Опишите, какие страницы и разделы должны быть на сайте, что должно быть в главном меню, какие подразделы будут у основных страниц и т. д. Можно кратко описать, содержание каждого типа страницы. Например:
  • Главная страница: информация о компании, ключевые услуги, преимущества, отзывы клиентов, форма захвата (заявка на консультацию).
  • Услуги: список услуг с кратким описанием и кнопкой для перехода к детальной информации по каждой услуге.
  • О компании: история компании, миссия, команда (с фотографиями сотрудников).
  • Контакты: контактная информация (адрес, телефон, e-mail), карта проезда к офису, форма обратной связи.
  • Отзывы: блок с отзывами клиентов с возможностью добавлять новые отзывы через форму.
  • Блог: список статей, с краткими описаниями и кнопками "Читать далее".

  Полноценная расписанная структура может выглядеть так:

  

  Или её можно представить в виде древовидной схемы, где от главной страницы отходят другие основные разделы.

• Функциональность сайта. Опишите функции, которые должны быть у площадки. Например, регистрация пользователей, личный кабинет, добавление товаров в корзину, оформление заказа, оплата через онлайн-платежи, автоматическая отправка уведомлений на электронную почту и т. д.
• Интеграции с внешними сервисами. Если планируется интеграция с другими системами, укажите это. Например, может понадобиться интеграция с CRM, онлайн-кассой, ERP-системой для управления складом и т. д.
• Интерактивные элементы. Опишите, какие интерактивные элементы страниц нужны: формы захвата, всплывающие окна, анимации, чат-боты, онлайн-калькулятор и т. д. Также стоит указать, на каких именно страницах они будут находиться.
• Фильтры. Этот момент чаще актуален для разработки интернет-магазинов. Укажите, по каким критериям должна быть возможность фильтровать товары. Например, по категории, цене, брендам, цветам, размерам, материалам, рейтингу товара и т. д. Для каждого пункта стоит указать конкретные требования. Например, сделать фильтр по цене в виде ползунка. А в фильтр по бренду добавить такой-то список наименований.

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

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

• Платформа и язык программирования. Укажите, какие технологии должны быть использованы для создания сайта. Например, ресурс может быть сделан на CMS, то есть собираться из готовых шаблонов, которые адаптируются под конкретный проект. Или быть полностью написан с нуля. От этого в том числе будет зависеть стоимость разработки, потому что создание с нуля всегда сложнее, дольше и дороже. В зависимости от варианта можно указывать конкретные CMS или определённые языки программирования.
• Адаптивность. Уточните, что ресурс должен корректно отображаться на устройствах с экранами разного размера. Сейчас это требование обязательно для создания любых сайтов, ведь большинство трафика идёт с мобильных устройств. Лучше всего описать, как должны выглядеть ключевые элементы на разных устройствах. Также важно учесть кроссбраузерную вёрстку, чтобы ресурс нормально выглядел в том числе в разных браузерах.
• Безопасность. Перечислите меры безопасности, которые нужно внедрить: защита данных пользователей, SSL-сертификат, регулярное резервное копирование и т. д. Компаниям из определённых сфер, например, банковской, особенно важно защищать данные своих клиентов. Поэтому для них требования к безопасности могут быть ещё более повышенными.
• SEO-требования. Если заказчик планирует продвигаться в выдаче, есть смысл сразу заняться поисковой оптимизацией. Например, прописать уникальные мета-теги, сделать человекопонятные ссылки, минимизировать время загрузки страниц.

4. Дизайн и UX (пользовательский интерфейс)

Этот раздел определяет внешний вид ресурса и его удобство для пользователей. Здесь точно нужно избегать субъективных формулировок. Понятия “красиво” и “стильно” у каждого свои.

• Примеры дизайна. Возможно, у заказчика есть примеры дизайна, которые ему нравятся. Можно приложить их к ТЗ на сайт, чтобы дизайнеры понимали от чего отталкиваться.
• Цветовая гамма. Опишите, какие цвета должны присутствовать на сайте. Это может быть конкретная палитра или просто предпочтения. Часто выбирают просто фирменные цвета бренда.
• Шрифты. Укажите шрифты, которые хотите использовать. Можно назвать как конкретный шрифт (у некоторых компаний даже есть свои фирменные), так и просто общий стиль (например, строгий или игривый).
• Расположение элементов. Опишите, где должны находиться ключевые элементы, такие как логотип, кнопки, меню. Например: “логотип компании в левом верхнем углу, основное меню — горизонтальное под логотипом".
• Удобство использования (UX). Опишите, что важно для удобства пользователей. Например так: “Процесс регистрации и оформления заказа должен быть максимально упрощён. Минимум полей для заполнения, поддержка автозаполнения для доставки".

5. Контент

Определите, какой контент будет на площадке и кто будет за него отвечать.

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

6. Этапы и сроки выполнения

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

• Разделение на этапы. Пропишите важные этапы работы. Основные это: создание прототипов страниц, разработка дизайн-макета, вёрстка, программирование, тестирование и запуск. Укажите, сколько времени будет занимать каждый этап, чтобы понимать общие сроки проекта.
• Контрольные точки. Определите промежуточные результаты, которые должны быть достигнуты на каждом этапе. После каждого такого этапа можно приносить проект на согласование с заказчиком, чтобы он внёс необходимые правки. Так внедрить их будет гораздо проще, чем после полного завершения проекта.

Частые ошибки при формировании ТЗ на разработку сайта

Обычно встречаются:

Нечёткие или общие формулировки

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

Отсутствие чёткой структуры

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

Игнорирование требований к адаптивности

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

Отсутствие информации о контенте

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

Не учтены интеграции с другими системами

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

Отсутствие планов по тестированию

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

Игнорирование планов по дальнейшему развитию

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

Резюмируем

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