Самый неприятный момент наступает не в день запуска. Он наступает позже — когда вы упираетесь в реальность: нужно загрузить (15,000) товаров, настроить оплату, связать остатки со складом, ускорить сайт, нормально индексироваться в Google и Яндексе, а подрядчик спокойно говорит: «А это не было в ТЗ».
Техническое задание — не бюрократия и не “бумажка для галочки”. Это документ, который превращает ваши ожидания в измеримые требования и защищает проект от расползания сроков, бюджета и ответственности.
Почему устные договоренности = +(200%) к бюджету
Устные обещания почти всегда заканчиваются одинаково: каждый участник проекта запоминает разговор по‑своему, а прав в итоге тот, кто фиксировал требования письменно.
Вот что обычно раздувает бюджет в e-commerce, если стартовали “на доверии”:
- Функционал вспоминают по ходу работ: фильтры, избранное, сравнение, мультивалюта, промокоды, статусы заказа, роли менеджеров
- Интеграции “добавляются потом”: оплата, доставка, CRM, склад, (1С), МойСклад, касса, эквайринг
- Контент не готов: фото, характеристики, категории, тексты, атрибуты, SEO‑шаблоны
- Нагрузка не посчитана: сайт начинает тормозить на (5,000+) товаров и (100+) посетителях одновременно
- Приемка размыта: “красиво” есть, но заказы не проходят, письма не уходят, мобильная версия сыпется
И да, на практике это легко превращается в “проект на (X)”, который в процессе становится “(X \times 2)” просто потому, что стороны по‑разному понимали задачу.
Что такое ТЗ на интернет-магазин (по‑человечески)
ТЗ — это чек‑лист ожиданий, переведенный на язык функций, цифр и проверяемых условий. Не обязательно писать его канцеляритом или на (40) страниц. Главное — чтобы документ отвечал на вопрос: “Что именно мы делаем, как это работает, кто за что отвечает, и как мы поймем, что всё готово”.
Если коротко, хорошее ТЗ делает две вещи: снижает риски и экономит деньги. Потому что любые изменения дешевле на бумаге, чем в коде на продакшене.
6 обязательных блоков ТЗ, без которых магазин нормально не поедет
Ниже — структура, которую мы используем в «Спартан», когда проектируем e-commerce на WordPress/WooCommerce (или на другой платформе, если по задаче она подходит лучше).
1) Цель проекта (не про дизайн, а про результат)
Плохая цель: “Сделать современный красивый интернет-магазин”.
Рабочая цель звучит измеримо: магазин должен принимать оплату картой, считать доставку, выгружать фиды в рекламу, синхронизировать остатки со складом, выдерживать пиковую нагрузку и конвертировать трафик в заявки/заказы.
Пример формулировки, которую реально можно проверить: магазин обрабатывает (100) заказов в день, обновляет остатки каждые (15) минут, открывается на мобильном за до (2.5) секунды на типовых страницах каталога.
2) Структура и сценарии (не “страницы”, а путь пользователя)
В e-commerce важно не количество страниц, а сценарии:
- Как пользователь ищет товар (каталог, фильтры, поиск, подсказки)
- Как выбирает (карточка, галерея, характеристики, вариации)
- Как покупает (корзина, чекаут, методы оплаты/доставки)
- Как возвращается (личный кабинет, повтор заказа, статусы)
В ТЗ фиксируют: какие разделы нужны, какая логика у фильтра, какие поля на оформлении заказа, какие статусы заказа используются, какие уведомления уходят клиенту и менеджеру.
Если это не прописать, вы почти гарантированно получите “ну мы сделали как обычно”, а “как обычно” редко совпадает с вашей моделью продаж.
3) Контент и товары: кто готовит, в каком формате, в какие сроки
Товарный контент — это половина успеха магазина, и именно здесь чаще всего проект стопорится.
В ТЗ нужно определить:
- Источник данных: Excel/CSV, (1С), МойСклад, API поставщика, парсинг
- Структуру каталога: категории, атрибуты, вариации (цвет/размер), бренды
- Правила заполнения: обязательные поля, единый формат характеристик, изображения
- Ответственных: кто подготавливает, кто импортирует, кто проверяет качество
Реальность такая: “мы потом зальем товары” часто означает “сайт запустится без ассортимента, а продажи начнутся когда-нибудь”.
4) Интеграции: перечислить сейчас, а не вспоминать потом
Интеграции почти всегда дороже “вдогонку”, потому что затрагивают архитектуру, безопасность и тестирование.
Типовой список для Беларуси:
- Оплата: Assist, bePaid, CloudPayments (если работает по вашему юрлицу), Stripe (в зависимости от страны компании), платежи картой, Apple Pay/Google Pay (если доступно)
- Доставка: Европочта, Белпочта, СДЭК (если актуально), собственная доставка по зонам, расчет по API или по таблице тарифов
- Склад/учет: (1С), МойСклад, Excel-выгрузки по расписанию, двусторонняя синхронизация остатков и цен
- Маркетинг: Meta Pixel, GA4, Яндекс.Метрика, события e-commerce, выгрузки в Merchant Center/каталоги
- SEO‑база: ЧПУ/URL‑шаблоны, шаблоны meta для категорий/товаров, sitemap, robots, canonical, микроразметка
Нормальная формулировка в ТЗ звучит так: “Синхронизируем такие-то поля, с такой-то частотой, в такую-то сторону, с логированием ошибок”.
5) Технические требования: скорость, мобильная версия, безопасность, надежность
Это то, что владельцы бизнеса часто не прописывают, а потом удивляются, почему сайт “не летает” и “что-то ломается после обновлений”.
В ТЗ стоит зафиксировать:
- Производительность: целевые показатели (например, LCP/INP как ориентиры), лимиты по времени загрузки ключевых страниц
- Мобильная версия: не “адаптив есть”, а какие брейкпоинты проверяем и какие элементы обязательны на мобильном
- Безопасность: SSL, защита админки, роли пользователей, антиспам, политика обновлений, ограничение попыток входа
- Бэкапы: частота, где хранятся, кто отвечает за восстановление, регламент
- Окружения: будет ли staging (тестовый сайт) и кто имеет доступ
Для магазина это критично: один сбой в оплате или утечка доступа — и вы теряете доверие, деньги и время.
6) Критерии приемки: как именно вы поймете, что проект готов
Самый важный блок, который экономит нервы обеим сторонам.
Вместо “когда мне понравится” в приемке нужны проверки:
- (10) тестовых заказов: разные устройства, разные способы оплаты/доставки, письмо/смс, смена статусов
- Проверка импорта: товары, вариации, цены, остатки, изображения
- Проверка SEO‑базы: индексируемость, отсутствие дублей, корректные canonical, генерация sitemap
- Проверка ролей: менеджер видит заказы, клиент видит историю, админ управляет каталогом
- Проверка скорости на согласованном хостинге, а не “у разработчика локально”
Если приемка не прописана, проект можно “сдать” в любой момент фразой “ну оно же работает”.
Этап проектирования, который снимает недопонимание между бизнесом и разработчиком
В «Спартан» мы всегда отделяем “хочу” от “как сделаем”. И лучший инструмент для этого — этап проектирования: интервью, прототип, карта сценариев, согласование интеграций и контента до разработки.
Что дает проектирование:
- Вы видите будущий магазин до дизайна и кода
- Мы находим противоречия (например, “быстрый чекаут в один шаг” и “обязательные поля для бухгалтерии”)
- Появляется понятная смета: что входит, что опционально, что зависит от данных клиента
- Снижается риск “переделывать готовое”
Это тот самый этап, который предприниматели чаще всего пытаются пропустить — и именно он потом спасает бюджет.
«Красивый сайт» и «инструмент продаж» — действительно разные ТЗ
Красота — важна, но e-commerce продает не “визуалом”, а удобством и логикой.
ТЗ на “красивый сайт” обычно состоит из референсов и слов “минимализм, премиально, современно”.
ТЗ на “продающий магазин” включает:
- Логику категорий и фильтров под реальный ассортимент
- Поиск с подсказками и нормальной обработкой опечаток (если нужно)
- Карточку товара, которая отвечает на возражения (доставка, наличие, возврат, гарантия)
- Сценарии повторных покупок и апсейла (комплекты, сопутствующие товары)
- Аналитику: события, воронка, источники продаж
Именно поэтому мы в «Спартан» начинаем не с “нарисуем красиво”, а с вопроса: как вы зарабатываете и что должно происходить на сайте, чтобы деньги приходили стабильно.
Инсайт от «Спартан»: сильное ТЗ делается в 4 этапа, а не в один
Мы видели десятки проектов, где “ТЗ” было одним сообщением в мессенджере. Для магазина это почти гарантированный путь к переделкам.
Рабочий процесс выглядит так:
- Ваше видение: ассортимент, география, модель доставки/оплаты, приоритеты, конкуренты
- Предпроектный аудит: мы задаем неудобные вопросы, считаем риски, фиксируем ограничения, предлагаем архитектуру
- Детализация реализации: описываем модули, интеграции, роли, поля, статусы, сценарии, делаем прототипы ключевых экранов
- Финализация приемки: составляем чек‑лист тестирования, критерии “готово”, регламент запуска и поддержки
Если пропустить второй этап, чаще всего получается сайт “как у всех”, который не совпадает с вашим бизнес‑процессом. А потом начинаются платные “доработки”, потому что “вы не уточнили”.
Актуальные ориентиры по стоимости в (2026): сколько стоит нормальное ТЗ и разработка магазина
Цены зависят от масштаба и интеграций, но мы можем дать понятные вилки, чтобы вы планировали бюджет без иллюзий.
Ориентиры по работам в Беларуси на (2026) год:
- Предпроектный этап и ТЗ для e-commerce: примерно (900)–(3,500) (BYN) (интервью, прототип ключевых сценариев, описание интеграций, приемка)
- Интернет-магазин на WordPress/WooCommerce “под ключ” (каталог, корзина, чекаут, базовая SEO‑настройка, аналитика, адаптив): примерно (4,500)–(12,000) (BYN)
- Магазин с интеграциями (1С)/МойСклад, расширенными фильтрами, мультискладом, сложной доставкой, миграцией и импортами: примерно (12,000)–(30,000) (BYN)
- Поддержка и развитие (обновления, мониторинг, бэкапы, мелкие доработки): примерно (250)–(1,200) (BYN) в месяц, в зависимости от SLA и объема работ
Важно: если вы планируете импорт (10,000+) товаров, сложные вариации и регулярную синхронизацию, мы почти всегда рекомендуем закладывать бюджет на производительность (кэширование, оптимизацию запросов, правильный хостинг/VPS, CDN при необходимости). Это дешевле, чем “лечить тормоза” после запуска.
Мини‑пример: один абзац, который спасает проект
Вместо: “Сделать фильтр по цене”.
Пишите так: фильтр в категории работает по цене и наличию, отображает диапазон в (BYN), учитывает скидочную цену, применяет условия без перезагрузки страницы, сохраняет выбранные параметры в URL, корректно работает на мобильных устройствах, время ответа фильтра до (300)–(600) мс на каталоге до (20,000) товаров при настроенном кэше.
Это не “занудство”. Это ясность, за которую вы платите один раз, а не бесконечно.
Что мы предлагаем в «Спартан»
Если вы запускаете интернет-магазин впервые или уже обожглись на “устных договоренностях”, мы можем подключиться в удобном формате:
- Разобрать вашу задачу и собрать требования в понятное ТЗ
- Спроектировать структуру, сценарии и прототипы ключевых страниц
- Рассчитать смету и сроки без “сюрпризов”
- Реализовать магазин на WordPress/WooCommerce с упором на скорость, SEO‑базу и стабильность
- Настроить интеграции (оплата, доставка, склад/учет, аналитика) и чек‑лист приемки
Если хотите, чтобы ваш сайт был не “просто красивым”, а реально продавал, напишите нам на spartan.by: проведем короткую консультацию, зададим правильные вопросы и предложим план работ с прозрачной стоимостью и понятными этапами.
