Как составить ТЗ для сайта: разбор кейса, где ошибки увеличили бюджет в 2 раза

Из практики digital-агентства: подробный анализ провала проекта с 10 000 товаров и пошаговая инструкция для создания технического задания, которое защищает сроки и бюджет.

В digital-проектах цена ошибки, допущенной на этапе планирования, всегда в разы выше стоимости самой разработки. В этой статье я разберу реальный кейс из моей практики, который длился три года и наглядно показывает, к чему приводит «экономия» на грамотном техническом задании. А главное — дам практический алгоритм, который мы используем в fenkodigital для постановки задач подрядчикам и защиты интересов клиентов.

Часть 1. Анализ провала: как 10 000 товаров стали неликвидным складом

В 2018 году я присоединилась к компании, которая только что запустила новый корпоративный сайт на «1С-Битрикс». За красивым фасадом скрывалась нерабочая система: админка «падала» при одновременной работе двух менеджеров, база данных регулярно теряла часть из 10 000 товарных позиций. Компания месяцами тратила средства на аварийное восстановление данных, что в сумме превышало стоимость создания нового, стабильного сайта.

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

Повторение ошибки: новый подрядчик, старые проблемы

В 2020 году, когда компания вновь обратилась ко мне за помощью, ситуация была парадоксальной. Новый подрядчик, приглашённый для «решения всех проблем», создал сайт, который оказался не менее dysfunctional.

Что получил бизнес в итоге:

Для покупателей (дизайнеров интерьера): 10 000 товаров, вываленных одним бесконечным списком на главной. Ни фильтров по бренду и цвету, ни рубрикатора — найти нужное было физически невозможно.
Для администраторов: «Уникальная» кастомная CMS на Laravel, в которой нельзя было изменить баннер или режим работы. Единственный способ редактировать товары — через интеграцию с 1С, где сохранение одной карточки занимало до 10 минут.

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

Финансовый итог и корневые причины

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

Главные ошибки на старте:

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

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

Часть 2. Методика fenkodigital: 5 шагов к ТЗ, которое работает

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

Шаг 1. Определение бизнес-ядра

Прежде чем искать подрядчика, ответьте письменно на три вопроса:

Суть продукта/услуги: «Продаём строительные материалы премиум-класса», а не «создаём уют». Без абстракций.
Ключевая цель сайта: Одна метрика или действие: «увеличить количество qualified lead-ов от дизайнеров на 40%», «снизить нагрузку на менеджеров за счёт онлайн-калькулятора».
Критичный функционал (Must Have): Без чего сайт не выполнит цель? «Сложные фильтры по 5+ атрибутам», «интеграция с CRM для автоматического создания сделок».

Результат: Вы формулируете для себя (и будущего подрядчика) не «хочу красиво», а «мне нужен инструмент для решения конкретной бизнес-задачи».

Шаг 2. Визуализация через референсы

Создайте «доску настроения» (Mood Board) в Figma, Miro или даже обычном Google Doc. Собирайте:

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

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

Шаг 3. Структурирование с помощью ИИ

Не тратьте часы на придумывание структуры документа. Объедините текстовые ответы из шага 1 и визуальные материалы из шага 2. Загрузите это в ChatGPT или DeepSeek с промптом:

«Сформируй структурированное техническое задание для разработки сайта на основе этих материалов. Включи разделы: 1. Цели и метрики. 2. Требования к функционалу (приоритизировать). 3. Описание ключевых страниц и user flow. 4. Требования к административной панели. 5. Референсы и требования к дизайну.»

Итеративно дорабатывайте сгенерированный черновик, пока не получите внятный документ-основу.

Шаг 4. Стратегический выбор технологического стека

Это решение определяет бюджет на долгие годы.

Типовые задачи (лендинг, каталог, интернет-магазин): Выбор за проверенными CMS (1С-Битрикс, WordPress, Tilda). Преимущество: широкий пул специалистов, относительная дешевизна доработок, долгосрочная поддержка.
Кастомная разработка (Laravel, React, «своя CMS»): Оправдана только для продуктов с уникальной, нетиповой логикой. Риск: Вы на годы привязываетесь к конкретной команде, а любая правка оценивается как новая разработка.

Простой вопрос, который мы задаём клиентам: «Вы хотите владеть сайтом как продуктом или как услугой?» Ответ на него часто проясняет выбор.

Шаг 5. Валидация ТЗ через диалог с подрядчиком

Отправьте подготовленное ТЗ 2-3 потенциальным исполнителям. Их реакция — лучший тест на качество документа и профессионализм самой команды.

Зелёные флаги (хороший знак):

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

Красные флаги (сигнал к осторожности):

Молниеносное согласие со всеми, даже самыми сложными требованиями без вопросов.
Активная продажа «уникального фреймворка» или кастомного решения там, где достаточно коробочной CMS.
Игнорирование вопросов удобства администрирования и масштабируемости.

Юридическое закрепление — не формальность

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

Вопросы и ответы по составлению ТЗ

Короткие ответы на частые вопросы наших клиентов.

Нужно ли нанимать отдельного специалиста для написания ТЗ?

Не всегда. Если ваш проект стандартен (лендинг, визитка, типовой магазин), вы можете подготовить основу самостоятельно по нашему чек-листу. Однако для сложных систем с уникальной логикой (маркетплейсы, SaaS) консультация бизнес- или digital-аналитика сэкономит бюджет на этапе разработки, так как он предвосхитит логические и технические тупики.

Какой бюджет закладывать на этап подготовки ТЗ?

Это может занимать от 5% до 15% от общего бюджета на проект, в зависимости от сложности. Рассматривайте эти затраты не как потеру, а как инвестицию в управление рисками. Хорошее ТЗ предотвращает спорные ситуации и бесконечные дорогостоящие доработки «на лету».

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

«Гибкость» — не синоним «беспорядочности». Scrum и Agile подразумевают чёткое описание элементов бэклога (фактически, небольших ТЗ для каждой итерации). Отказ от фиксации требований — красный флаг. Это часто означает, что исполнитель не хочет нести ответственность за конечный результат. Настаивайте на детализации или ищите другого подрядчика.

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

Можно как отправную точку, но опасно как конечный документ. Шаблоны часто содержат общие, ни к чему не обязывающие формулировки. Ваша задача — максимально конкретизировать каждый пункт под свою бизнес-логику. Готовый шаблон нужно наполнять своей уникальной «начинкой».

Кто должен отвечать за утверждение ТЗ со стороны заказчика?

Идеально — лицо, которое будет нести ответственность за результат работы сайта (product owner, директор по digital) и ключевой будущий пользователь (например, руководитель отдела продаж для CRM). Это гарантирует, что ТЗ будет соответствовать и бизнес-целям, и реальным рабочим процессам.

Ключевые выводы для вашего проекта

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

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

Обсудить подготовку ТЗ для вашего проекта →

Ссылка откроется на fenkodigital.ru

P.S. Управляйте проектами, а не расходами на них.