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

История длиной в три года о 10 000 товаров, которые превратились в неконтролируемый поток, и пошаговый чек-лист, который защитит ваш следующий проект.

Часть 1. Кейс: как 10 000 товаров превратились в неконтролируемый поток и сожгли бюджет

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

В 2020 году меня пригласили в ту же компанию. Почему вернулась? Решать проблемы мне интереснее, чем работать в стабильном болоте. Плюс приятная ЗП, удалёнка, товар, с которым было интересно работать, и, конечно, новый «пожар». К этому времени наняли нового подрядчика, который реализовывал новый сайт.

Итог, который мне хотели сдать, был плачевен:

Для пользователя: те же 10 000 товаров были вывалены одним списком на главной, без фильтров, без рубрикаторов. Чистый поток плитки. Целевая аудитория (дизайнеры интерьера) физически не могла искать товары по ключевым для них параметрам: бренду, коллекции, цвету, материалу.

Для администратора: уникальная кастомная история на Laravel, где в админке было нельзя поставить новый баннер или поменять режим работы. Товары предполагалось менять в 1С, где карточка могла сохраняться 10 минут.

Корень проблемы: формальное ТЗ от подрядчика, который обещал “красиво и трендово”, умещалось на одном листе и свелось к общим пожеланиям.

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

Главные ошибки, которые привели к провалу:

Подмена ТЗ коммерческим предложением. Задача для менеджера проекта была абстрактной («сделайте красиво»), что позволило подрядчику сделать «как проще», а не «как нужно».
Отсутствие бизнес-требований. Никто не прописал, как будет выглядеть главная страница, по какой логике клиент должен искать товар и что для него критично (фильтры по бренду, цвету).
Игнорирование эксплуатации. Не было продумано, как админ будет управлять таким объёмом контента. Редактирование через 1С, тратя по 10 минут на карточку, тупиковый путь.

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

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

Часть 2. 5 шагов, чтобы составить ТЗ, которое защитит ваш бюджет (практический чек-лист)

Шаг 1. Фундамент: ответьте на три ключевых вопроса

Перед поиском подрядчика честно и письменно зафиксируйте:

Что вы продаёте? Без абстракций («ощущение уникальности»). Только конкретика: «строительные материалы», «SaaS-решение», «услуги клининга».
Какова цель сайта? Одна главная бизнес-задача: «продавать 30 курсов в месяц», «собирать заявки на замер», «дать удобство дизайнерам, которые приводят клиентов».
Критичный функционал (must have). Без чего сайт не работает: «фильтры по 5+ параметрам», «интеграция с 1С», «онлайн-калькулятор доставки».

Результат этапа: Чёткое понимание «зачем» и «что» до обсуждения «как».

Шаг 2. Визуализация: говорите на языке примеров

Создайте документ с референсами (скриншоты, ссылки). Комментируйте каждый элемент:

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

Результат: Наглядный «коллаж» вместо абстрактных «хочу красиво».

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

Не тратьте время на форматирование. Скопируйте свои наработки из шагов 1 и 2 в ChatGPT или DeepSeek с запросом:

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

Не останавливайтесь на первом ответе. Уточняйте: «Дополни и улучши, вот мои правки», пока не получите ясный документ. Это экономит дни работы.

Шаг 4. Технический выбор: подберите платформу стратегически

От этого выбора зависят будущие расходы.

Для типовых задач (интернет-магазин, каталог, лендинг) выбирайте проверенные CMS («1С-Битрикс» для большой номенклатуры, Tilda для простых решений). Плюсы: долгосрочная поддержка, много специалистов.
Кастомная разработка на фреймворках (Laravel) подходит для уникальных, нетиповых продуктов. Ну или если ваша цель показать всем, что можете себе позволить. Минус: каждая доработка будет дорогой и привяжет вас к конкретному исполнителю.

Шаг 5. Защита: оцените реакцию подрядчика и зафиксируйте всё

Отправьте ТЗ и анализируйте ответ. Это лучший тест на профессионализм.

Хороший знак, если вам:

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

Красный флаг, когда:

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

Ваш юридический козырь

Готовое и согласованное ТЗ ОБЯЗАТЕЛЬНО фиксируйте его как Неотъемлемое Приложение №1 к договору, где чёрным по белому прописаны объём работ, сроки, стоимость и условия. Это переводит ваши пожелания в юридические обязательства и вашу главную защиту.

Этот метод — ваша страховка от фундаментальных провалов

Конечно, мой метод не гарантия идеального сайта, всё-таки реализация зависит от подрядчика. Но это страховка от фундаментальных провалов и неконтролируемых расходов. Он позволяет говорить с подрядчиком на понятном языке и переводит процесс из творческого "хочу" в управляемый проект.

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

Обсудить проект →

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

P.S. Работайте с теми, кто ценит ваши требования, а не игнорирует их.