Любой проект по разработке интернет-магазина рано или поздно упирается в один и тот же вопрос: а что именно мы делаем? Одна сторона держит в голове «удобный современный магазин с фильтром и оплатой», другая — «типовой каталог на готовом решении», и до определённого момента обе искренне уверены, что говорят об одном и том же. Разрыв вскрывается на приёмке, когда переделывать уже дорого. Инструмент, который не даёт этому разрыву случиться, называется техническим заданием. Грамотное ТЗ на интернет-магазин — это не пухлый документ ради галочки, а переведённое на язык реализации соглашение: что делаем, как это должно работать, где границы и как мы поймём, что всё готово.
Эта статья — практическое руководство по тому, как написать ТЗ на магазин на 1С-Битрикс так, чтобы оно защищало обе стороны и экономило деньги. Мы разберём, зачем вообще нужно техническое задание, какие бывают уровни детализации, кто его пишет, из каких разделов состоит документ, как формулировать проверяемые требования к магазину вместо расплывчатых пожеланий, как описывать интеграции, контент, дизайн и критерии приёмки, где проходит граница проекта и какие ошибки повторяются чаще всего. В конце — готовая шаблон-структура и чек-лист готовности ТЗ. Материал опирается на нашу практику разработки интернет-магазинов на 1С-Битрикс — без выдуманных цифр, только структура и подход.
Коротко
- ТЗ нужно для четырёх вещей: единое понимание проекта, честная смета, объективная приёмка и защита обеих сторон при спорах.
- Уровень детализации выбирают под риск: типовому магазину хватает краткого ТЗ, сложному и B2B нужно детальное; часто применяют гибрид.
- ТЗ пишут заказчик и подрядчик совместно: бизнес-контекст от заказчика, перевод в требования и оценку — от подрядчика.
- Хорошее требование конкретно и проверяемо. «Сделайте красиво» и «удобный фильтр» — не требования, а источник конфликтов на приёмке.
- Обязательные разделы: цели и KPI, аудитория и сценарии, функциональные и нефункциональные требования, интеграции, контент, дизайн, приёмка, границы проекта, глоссарий.
- Границы проекта (что вне ТЗ) и критерии приёмки — самые недооценённые разделы, но именно они гасят «расползание объёма» и споры «сделано или нет».
Зачем нужно ТЗ на интернет-магазин
Соблазн начать без ТЗ понятен: кажется, что документ отнимает время, а «и так всё ясно». На практике «и так ясно» — самая дорогая иллюзия в проекте. Интернет-магазин — сложный механизм из десятков взаимосвязанных функций, и держать их согласованными в головах двух сторон невозможно. Техническое задание выполняет четыре несводимые друг к другу задачи, и каждая из них по отдельности окупает время на его составление.
Единое понимание проекта
Главная функция ТЗ — синхронизировать картину мира заказчика и подрядчика. Пока требования живут в устных разговорах, у каждого своя версия: заказчик представляет магазин как у конкурента с «умным» поиском и личным кабинетом, подрядчик закладывает типовой функционал готового решения. Записанное и согласованное ТЗ убирает этот зазор: обе стороны видят один и тот же список функций, сценариев и ограничений. Это не про недоверие, а про свойство человеческой памяти — она достраивает и искажает, а документ фиксирует.
Основа для честной сметы
Оценить стоимость и сроки можно только тогда, когда понятно, что делается. Смета собирается из требований: каждая функция, интеграция и нестандартный сценарий имеют свою трудоёмкость. Без ТЗ любая названная цифра — это либо угадывание, либо «средняя температура», от которой потом отталкиваются в спорах. С ТЗ смета становится прозрачной: видно, из чего она складывается, что можно убрать ради экономии, а что убрать нельзя. Тему стоимости мы подробно разбираем в материале о том, сколько стоит интернет-магазин на 1С-Битрикс — и там ключевая мысль ровно та же: честная цена начинается с ТЗ.
Критерий приёмки
ТЗ — это точка отсчёта, по которой определяют, сделана работа или нет. Без него приёмка сводится к спору на ощущениях: заказчику «кажется, что не так», подрядчик отвечает «а в задании этого не было». С ТЗ приёмка становится проверкой по согласованному списку: каждый пункт либо закрыт, либо нет. Именно поэтому в хорошем ТЗ к требованиям привязывают критерии приёмки — чтобы «готово» было фактом, а не мнением. Как это превращается в реальную проверку магазина, мы разбираем в статье про тестирование и QA интернет-магазина на 1С-Битрикс.
Защита обеих сторон
Распространённое заблуждение — что ТЗ защищает только заказчика («чтобы подрядчик не схалтурил»). На деле оно в равной мере защищает и подрядчика: чёткий периметр работ не даёт бесконечно расширять объём под видом «мелких доработок». Хорошее ТЗ выгодно обеим сторонам, потому что снимает почву для конфликта: есть письменная граница того, что входит, как это работает и что считается результатом. Стороны спорят не «по понятиям», а по документу — и почти всегда быстро находят решение.
Уровни детализации: краткое ТЗ и детальное
ТЗ бывает разным по глубине, и «чем подробнее, тем лучше» — не всегда верно. Избыточно детальное ТЗ для простого магазина превращается в бюрократию, которая устаревает быстрее, чем её дочитывают. Недостаточно детальное для сложного проекта оставляет мины замедленного действия. Правильный уровень детализации выбирают под сложность и риск проекта.
Краткое ТЗ
Краткое ТЗ описывает магазин крупными мазками: перечень разделов и страниц, список функций, ключевые интеграции, общие требования к дизайну и производительности. Оно отвечает на вопрос «что делаем» без глубокого погружения в «как именно ведёт себя каждый элемент». Такого ТЗ достаточно для типового магазина на готовом решении, где логика стандартна и предсказуема, а также для первичной оценки порядка стоимости и старта работ. Его плюс — скорость составления и читаемость. Минус — оно оставляет пространство для трактовок в деталях, поэтому спорные и нестандартные узлы в нём лучше отмечать как требующие отдельной проработки.
Детальное ТЗ
Детальное ТЗ расписывает поведение каждого значимого блока: сценарии, граничные случаи, форматы данных, правила расчёта доставки и скидок, поведение фильтра, логику B2B-цен, схему обмена с 1С вплоть до сопоставления свойств. К требованиям привязаны критерии приёмки. Такой документ нужен для сложных, нестандартных и B2B-проектов, где цена недопонимания высока, а логика не выводится «по здравому смыслу». Его плюс — минимум сюрпризов и споров. Минус — трудоёмкость составления и поддержки: детальное ТЗ требует времени и дисциплины, чтобы оставаться актуальным.
| Параметр | Краткое ТЗ | Детальное ТЗ |
|---|---|---|
| Глубина | Перечень функций и требований крупно | Поведение каждого блока и сценарии |
| Когда подходит | Типовой магазин, готовое решение | Сложная логика, B2B, нестандартный обмен |
| Что даёт оценке | Порядок стоимости и сроков | Точную смету по пунктам |
| Риск трактовок | Выше — детали «додумываются» | Ниже — спорные места закрыты |
| Трудоёмкость | Ниже, быстро составить | Выше, нужны время и дисциплина |
| Приёмка | По общим критериям | По критериям к каждому требованию |
На практике часто выигрывает гибрид: краткое ТЗ на весь проект плюс детальная проработка самых рискованных узлов. В магазине на 1С-Битрикс такими узлами почти всегда становятся обмен с 1С, оформление заказа со всеми способами оплаты и доставки, а также B2B-логика (кратность, договорные цены, роли пользователей). Их описывают подробно, а стандартные разделы — крупно. Так документ остаётся читаемым и при этом закрывает места, где ошибка стоит дороже всего.
Кто пишет ТЗ: заказчик и подрядчик совместно
Вопрос «кто пишет ТЗ» звучит так, будто у него один ответ, но лучший результат почти всегда даёт совместная работа. У каждой стороны своя незаменимая часть знаний, и без второй стороны документ получается однобоким.
Что приносит заказчик
Заказчик — носитель бизнес-контекста, которого у подрядчика нет и быть не может: реальные цели проекта, особенности аудитории, структура и источник ассортимента, договорённости с поставщиками, специфика учёта в 1С, процессы обработки заказа, особые сценарии (опт, самовывоз, договорные цены). Без этих вводных любое ТЗ будет писаться «в вакууме». Задача заказчика — честно и полно передать, как устроен его бизнес и чего он хочет от магазина, а не «сформулировать техническое задание» в одиночку.
Что приносит подрядчик
Подрядчик (обычно в лице аналитика) переводит бизнес-вводные на язык реализации: превращает пожелания в проверяемые требования, предлагает решения, отмечает противоречия и риски, оценивает трудоёмкость, подсказывает, что на 1С-Битрикс делается штатно, а что потребует доработки. Он же следит за полнотой: чтобы в ТЗ не забыли про письма и уведомления, обработку остатков, мобильную версию, SEO-структуру — вещи, о которых заказчик часто не думает, потому что они «сами собой разумеются».
Почему в одиночку — плохо
ТЗ, написанное только заказчиком, рискует оказаться технически наивным: невыполнимые в срок хотелки, противоречивые требования, копирование чужих решений без учёта своей специфики. ТЗ, написанное только подрядчиком без глубокого погружения в бизнес, рискует не учесть реальные процессы: красивый типовой магазин, который не ложится на то, как компания на самом деле продаёт. Поэтому оптимальный процесс — итеративный: заказчик даёт вводные, аналитик структурирует их в документ и задаёт уточняющие вопросы, стороны вместе вычитывают каждый раздел и согласуют формулировки. Ответственность за то, чтобы ТЗ отражало реальность, — общая.
Структура ТЗ: из каких разделов состоит документ
У технического задания на интернет-магазин есть устойчивый скелет — набор разделов, которые встречаются практически всегда, независимо от размера проекта. Меняется глубина каждого раздела, но не их состав: если какой-то блок отсутствует, это почти всегда значит, что о нём просто забыли, а не что он не нужен. Ниже — сводная карта разделов ТЗ и того, на какой вопрос отвечает каждый.
| Раздел ТЗ | На какой вопрос отвечает | Что содержит |
|---|---|---|
| Цели и KPI | Зачем магазин бизнесу | Бизнес-цели, измеримые ориентиры, приоритеты |
| Аудитория и сценарии | Кто и как будет пользоваться | Сегменты покупателей, роли, пользовательские сценарии |
| Функциональные требования | Что магазин должен уметь | Каталог, фильтр, карточка, корзина, заказ, ЛК, B2B |
| Нефункциональные требования | Каким должен быть под капотом | Скорость, нагрузка, безопасность, доступность, SEO |
| Интеграции | С чем связывается | 1С, CRM, оплата, доставка, аналитика, касса |
| Контент и наполнение | Чем наполняется и кто это делает | Источник данных, тексты, фото, зоны ответственности |
| Дизайн и прототипы | Как выглядит и ведёт себя интерфейс | Требования к дизайну, прототипы ключевых страниц |
| Платформа и хостинг | На чём работает | Редакция 1С-Битрикс, требования к серверу |
| Этапы и сроки | Как движется проект | Этапы, зависимости, ориентиры по срокам |
| Критерии приёмки | Как понять, что готово | Проверяемые условия, тест-кейсы |
| Границы проекта | Что не входит | Явный список работ вне ТЗ, процедура изменений |
| Глоссарий | На каком языке говорим | Определения ключевых терминов проекта |
Дальше разберём ключевые разделы по порядку — от целей и аудитории до критериев приёмки и границ проекта. Это и есть логика хорошего ТЗ: сначала «зачем и для кого», потом «что и как», затем «на чём и в какие сроки» и, наконец, «как поймём, что готово, и что в проект не входит».
Цели бизнеса и KPI
ТЗ начинается не с функций, а с целей — потому что функции это ответы, а цели это вопросы, на которые они отвечают. Раздел целей объясняет, зачем бизнесу магазин и по каким ориентирам будут судить об успехе. Без него ТЗ превращается в список хотелок без критерия «нужно / не нужно»: непонятно, почему одни функции приоритетны, а другие можно отложить.
Бизнес-цели
Здесь фиксируют, какую задачу бизнеса решает магазин: перевести оптовых клиентов в самообслуживание, вывести розницу в онлайн, выйти в новый регион, разгрузить менеджеров от рутинных заказов, протестировать нишу. От цели напрямую зависят приоритеты: магазин для перевода опта в онлайн будет вкладываться в B2B-функции и обмен с 1С, а магазин для тестирования ниши — в быстрый запуск и аналитику. Формулировка «хотим просто магазин» — это отсутствие цели, и такой проект тяжело и оценивать, и принимать.
KPI и ориентиры
KPI — это измеримые ориентиры, по которым бизнес поймёт, работает магазин или нет. Важная оговорка: в ТЗ фиксируют, какие показатели будут отслеживаться и какие механизмы для этого нужны (аналитика, цели, сегменты воронки), а не выдуманные плановые цифры. Конкретные плановые значения — зона бизнес-планирования заказчика, а не подрядчика. Задача ТЗ — обеспечить, чтобы эти показатели вообще можно было измерить: чтобы стояла аналитика, были настроены цели по ключевым действиям (добавление в корзину, оформление, оплата), а воронка была видна. Магазин, в котором невозможно измерить результат, нельзя ни оценить, ни улучшить.
Приоритизация требований
Из целей вырастает приоритизация: какие требования обязательны к запуску, какие желательны, какие относятся к развитию. Удобно размечать требования по уровням важности — это основа для выделения MVP и для управляемого сокращения объёма, если нужно уложиться в срок или бюджет. Приоритеты, привязанные к целям, отвечают на вопрос «что убрать в первую очередь, если придётся»: убирают то, что дальше всего от цели. Как из приоритетов складывается план первого релиза, мы подробно разбираем в гайде про запуск интернет-магазина на 1С-Битрикс.
Целевая аудитория и сценарии использования
Магазин делают не «для всех», а для конкретных людей с конкретными задачами. Раздел аудитории и сценариев описывает, кто и как будет пользоваться магазином, — и это напрямую определяет функциональные требования. B2B-закупщик, импульсный розничный покупатель и постоянный клиент ведут себя по-разному и нуждаются в разном интерфейсе.
Сегменты аудитории
Здесь выделяют ключевые группы пользователей и их особенности: розница или опт, новые или постоянные, как принимают решение, что для них критично (цена, наличие, скорость доставки, консультация, отсрочка платежа). Для каждого значимого сегмента полезно понимать его путь: как он попадает на сайт, что ищет, что мешает купить. Если магазин обслуживает и розницу, и B2B, это почти всегда означает разные сценарии и, возможно, разные роли пользователей — что нужно заложить в требования, а не обнаружить в процессе.
Пользовательские сценарии
Сценарий (user story) описывает задачу пользователя в формате «как роль, я хочу действие, чтобы получить результат». Например: «как оптовый клиент, я хочу повторить прошлый заказ в один клик, чтобы не собирать одну и ту же корзину каждую неделю». Сценарии переводят абстрактную «аудиторию» в конкретные требования: из примера выше вырастает функция повторного заказа и история заказов в личном кабинете. Хорошее ТЗ собирает ключевые сценарии для каждого сегмента и проверяет по ним полноту функционала: если у сценария нет поддерживающей его функции, значит, требование пропущено.
| Сегмент | Ключевой сценарий | Требование, которое из него следует |
|---|---|---|
| Розничный покупатель | Быстро найти товар и оформить с удобной доставкой | Понятный каталог, фильтр, короткое оформление |
| Постоянный клиент | Повторить заказ, видеть историю и статусы | Личный кабинет, история, повтор заказа |
| Оптовый клиент (B2B) | Заказать с учётом кратности и своих цен | B2B-роли, договорные цены, кратность упаковки |
| Сомневающийся покупатель | Сравнить варианты и уточнить детали | Сравнение, подробная карточка, обратный звонок |
Функциональные требования: каталог, фильтр, поиск
Функциональные требования — сердце ТЗ. Они описывают, что магазин должен уметь и как это работает. Именно здесь чаще всего живут расплывчатые формулировки, поэтому этот блок расписывают особенно тщательно. Начнём с того, с чего начинается путь покупателя, — с каталога, фильтра и поиска.
Структура каталога
В ТЗ описывают, как устроено дерево разделов и подразделов, как товары распределяются по категориям, как устроены свойства (характеристики) и торговые предложения (варианты товара: размер, цвет). Ключевой момент для 1С-Битрикс — структура каталога должна согласовываться с тем, как товары организованы в 1С, потому что от этого зависит обмен. Поэтому раздел каталога пишут с оглядкой на раздел интеграций, а не отдельно. Здесь же фиксируют, какие свойства участвуют в фильтре, какие в сравнении, какие показываются в карточке.
Фильтр
Фильтр — типичное место расплывчатых требований («удобный фильтр»). В ТЗ его описывают конкретно: по каким свойствам фильтруем, как ведёт себя фильтр (мгновенный пересчёт или по кнопке), сохраняется ли выбор в адресе страницы (важно для SEO и для того, чтобы можно было поделиться ссылкой на отфильтрованную выборку), что происходит с недоступными комбинациями, как выглядит на мобильном. От того, как описан фильтр, зависит и удобство, и SEO-потенциал: правильно устроенные страницы фильтрации могут стать посадочными под запросы.
Поиск
Поиск описывают по поведению: что ищется (по названию, артикулу, свойствам), есть ли подсказки при вводе, как обрабатываются опечатки и синонимы, что показывается при отсутствии результатов, как выглядит страница результатов. Для магазина с большим каталогом поиск — один из главных инструментов продаж, и требование «просто поиск» здесь недопустимо: у стандартного и «умного» поиска разная трудоёмкость и разный результат, и это нужно проговорить в ТЗ.
Функциональные требования: карточка, корзина, оформление
Дальше по пути покупателя — карточка товара, корзина и оформление заказа. Это зона, где магазин зарабатывает или теряет деньги, поэтому требования к ней описывают детально.
Карточка товара
В ТЗ фиксируют состав карточки: галерея, название, артикул, цена (и её поведение для разных типов цен и B2B), наличие и остатки, выбор торговых предложений (размер, цвет), характеристики, описание, кнопка «в корзину», сопутствующие и похожие товары, отзывы, доставка и оплата. Отдельно — поведение при отсутствии товара на складе и логика вариантов (что происходит с ценой и наличием при переключении размера). Карточка — самая посещаемая страница магазина, и от полноты её требований зависит конверсия.
Корзина
Корзину описывают по поведению: как добавляется товар, как меняется количество (с учётом кратности для B2B), как показывается итоговая сумма, как применяются скидки и промокоды, что происходит с недоступными товарами, сохраняется ли корзина между визитами. Мелочи здесь стоят продаж: непонятная итоговая сумма или неработающий пересчёт количества выталкивают покупателя.
Оформление заказа
Оформление заказа — критичная точка конверсии и один из самых сложных для описания блоков, потому что в нём сходятся доставка, оплата, данные покупателя и логика заказа. В ТЗ описывают: какие поля запрашиваются, как выбирается доставка и как считается её стоимость, какие способы оплаты доступны, как показывается итоговая сумма со всеми надбавками, можно ли оформить без регистрации, какие письма и уведомления отправляются. Особое внимание — комбинациям: каждый способ доставки должен корректно работать с каждым допустимым способом оплаты, и это отдельно проверяется на приёмке.
Оплата и доставка как требования
Способы оплаты (карты, СБП, оплата при получении, безналичный расчёт для юрлиц) и доставки (курьер, пункты выдачи, почта, транспортные компании, самовывоз) перечисляют в функциональных требованиях, а техническую сторону их подключения — в разделе интеграций. Здесь важно описать бизнес-логику: зоны и правила расчёта доставки, бесплатная доставка от суммы, ограничения способов оплаты для отдельных категорий или ролей. Логику доставки и оплаты нельзя оставлять на «как обычно» — «как обычно» у каждого своё.
Функциональные требования: личный кабинет и B2B
Для многих магазинов, особенно оптовых, личный кабинет и B2B-функции — не опция, а ядро. Их описывают отдельно, потому что здесь больше всего нестандартной логики, которую нельзя «додумать по здравому смыслу».
Личный кабинет
В ТЗ описывают состав личного кабинета: история заказов и их статусы, повторный заказ, сохранённые адреса и реквизиты, избранное, подписки, документы (счета, накладные), управление данными. Для розницы кабинет обычно проще, для B2B — богаче. Ключевой вопрос — какие сценарии он поддерживает: если у постоянного клиента есть сценарий «повторить прошлый заказ», кабинет обязан это уметь, и это фиксируют явно.
B2B-требования
B2B-функционал — самая частая зона недооценки в ТЗ, потому что он выглядит как «обычный магазин, только для юрлиц», а на деле требует отдельной логики. В ТЗ описывают: роли пользователей (например, разные права у сотрудников одной компании), договорные и персональные цены, типы цен из 1С, кратность и единицы упаковки, оптовые скидки и условия, отсрочку платежа и безналичную оплату, быстрый заказ по артикулам или загрузкой списка, документы и закрывающие. Каждый из этих пунктов — отдельное требование с собственной трудоёмкостью. Подробнее B2B-специфику мы разбираем в отдельных материалах блога, но в ТЗ важно одно: B2B-логику нельзя описывать общими словами, её расписывают детально, потому что цена ошибки здесь особенно высока.
Как формулировать требования: «сделайте красиво» против SMART
Можно собрать все нужные разделы и всё равно получить плохое ТЗ — если требования сформулированы расплывчато. Качество ТЗ определяется не длиной, а проверяемостью формулировок. «Сделайте красиво», «удобный фильтр», «быстрый сайт», «современный дизайн» — это не требования, а пожелания: у каждой стороны своё представление о красоте, удобстве, скорости и современности, и на приёмке эти представления не совпадут.
Что делает требование хорошим
Хорошее требование конкретно, однозначно и проверяемо. Его нельзя понять двумя способами, и по нему можно определить, выполнено оно или нет. Принцип часто называют SMART: конкретно (Specific), измеримо (Measurable), достижимо (Achievable), релевантно цели (Relevant), проверяемо (Testable/Time-bound). Простой тест: можно ли по формулировке написать критерий приёмки? Если да — требование рабочее. Если нет («сделайте удобно») — это пожелание, которое нужно переформулировать.
Как переписывать пожелания в требования
Расплывчатое пожелание превращают в требование, задавая вопросы «что именно», «при каких условиях», «что считается результатом». «Быстрый сайт» → «ключевые страницы (главная, каталог, карточка) укладываются в целевые показатели скорости загрузки на типовом соединении». «Удобный фильтр» → «фильтр по свойствам бренд, цена, наличие с мгновенным пересчётом количества и сохранением выбора в URL». «Красивая карточка» → перечень блоков карточки и их поведение. Ниже — сопоставление плохих и хороших формулировок.
| Плохое требование (пожелание) | Хорошее требование (проверяемое) |
|---|---|
| Удобный фильтр в каталоге | Фильтр по свойствам бренд, цена, наличие; мгновенный пересчёт количества; выбор сохраняется в адресе страницы |
| Быстрый сайт | Ключевые страницы соответствуют согласованным целевым показателям скорости загрузки на типовом соединении |
| Красивая карточка товара | Карточка содержит галерею, цену, наличие, выбор вариантов, характеристики, описание, кнопку «в корзину», похожие товары |
| Интеграция с 1С | Обмен переносит товары, цены, остатки на сайт и заказы в учёт по согласованному расписанию, без дублей, с обработкой вариантов |
| Работает на мобильных | Каталог, карточка и оформление заказа корректно отображаются и функциональны на согласованном наборе устройств и браузеров |
| Личный кабинет | Кабинет содержит историю заказов со статусами, повтор заказа, сохранённые адреса и реквизиты, доступ к документам |
| Удобное оформление | Оформление в согласованное число шагов, с расчётом доставки и прозрачной итоговой суммой, возможностью заказа без регистрации |
Нефункциональные требования: нагрузка, скорость, безопасность, SEO
Функциональные требования отвечают на вопрос «что магазин делает», нефункциональные — «каким он должен быть». Это требования к качеству: скорости, устойчивости, безопасности, доступности, поисковой пригодности. Их часто забывают, потому что они «не видны глазом», — а потом магазин тормозит под рекламным трафиком, падает под нагрузкой или не индексируется.
Производительность и нагрузка
Здесь описывают требования к скорости загрузки ключевых страниц и к поведению под нагрузкой. Важно указать ожидаемый профиль нагрузки (обычный трафик и пиковый — распродажи, реклама), потому что от него зависят и архитектурные решения, и требования к хостингу. Формулировки должны быть проверяемыми: не «быстрый сайт», а согласованные целевые показатели для конкретных страниц. Тему скорости и её измерения мы затрагиваем и в других материалах блога — она напрямую влияет и на конверсию, и на позиции.
Безопасность
Магазин принимает персональные данные и платежи, поэтому безопасность — обязательный раздел, а не опция. В ТЗ фиксируют требования: актуальность платформы и модулей, проактивная защита, корректные права доступа и роли, работа по HTTPS, резервное копирование с проверкой восстановления, отсутствие тестовых учёток и открытых служебных разделов на боевом сайте, соответствие требованиям к обработке персональных данных. Безопасность дешевле заложить требованием, чем чинить после инцидента.
Доступность и совместимость
Сюда относят требования к отображению на разных устройствах и в разных браузерах (согласованный список), к мобильной версии как полноценному сценарию покупки, а также базовые требования доступности (читаемость, работа с клавиатуры, альтернативные тексты) — они полезны и людям, и поисковикам. «Работает у меня в одном браузере» — не критерий; целевой набор устройств и браузеров фиксируют в ТЗ.
SEO-требования
SEO закладывают в ТЗ, а не «оптимизируют потом», потому что оно определяет архитектуру: структуру разделов под запросы, человекопонятные адреса (ЧПУ), шаблоны метаданных (title, description) для карточек и разделов, микроразметку товаров, цен, наличия и хлебных крошек, карту сайта, корректную работу с дублями и каноническими адресами, поведение страниц фильтрации. Переделывать структуру и ЧПУ после того, как страницы проиндексированы, дорого и болезненно, поэтому SEO-требования формулируют на этапе ТЗ вместе с SEO-специалистом.
| Группа | Что фиксируют в ТЗ |
|---|---|
| Производительность | Целевые показатели скорости ключевых страниц, профиль нагрузки, поведение в пик |
| Безопасность | HTTPS, права и роли, проактивная защита, бэкапы, обработка перс. данных |
| Совместимость | Список устройств и браузеров, мобильная версия как сценарий покупки |
| Доступность | Читаемость, работа с клавиатуры, альтернативные тексты изображений |
| SEO | Структура под запросы, ЧПУ, метаданные, микроразметка, карта сайта, дубли |
Интеграции в ТЗ: 1С, CRM, оплата, доставка, аналитика
Интеграции превращают витрину в работающий магазин и одновременно являются самой хрупкой частью проекта, потому что зависят от внешних систем. В ТЗ каждую интеграцию описывают отдельно: что, с чем, в какую сторону, по какому расписанию, что считается корректной работой. «Настроить интеграции» одной строкой — прямой путь к сюрпризам.
Обмен с 1С
Для магазина с учётом в 1С обмен — критичная интеграция, влияющая на структуру всего каталога. В ТЗ фиксируют: что синхронизируется и в какую сторону (товары, цены, остатки, разделы — на сайт; заказы — в учёт), формат и механизм обмена, расписание выгрузок, сопоставление свойств и единиц измерения, обработку торговых предложений и остатков по складам, типы цен (в том числе для B2B), поведение при конфликтах и дублях. Чем детальнее описан обмен, тем меньше боли на самой хрупкой части проекта. Обмен проектируют вместе с каталогом, а не «прикручивают потом».
CRM и учётные системы
Если заказы обрабатываются в CRM, в ТЗ описывают, что и как передаётся: заказы, статусы, контакты, история. Указывают направление обмена и логику (например, заказ уходит в CRM для работы менеджеров, а в 1С — для учёта). Набор интеграций определяется реальными процессами, а не принципом «подключим всё, что можно».
Оплата и доставка
Технические требования к приёму оплаты (платёжный шлюз, онлайн-касса и фискализация, поддерживаемые способы) и к расчёту доставки (интеграции служб, расчёт тарифов, пункты выдачи, трекинг) описывают здесь, а бизнес-логику — в функциональных требованиях. Ключевое требование к обеим интеграциям — сквозная проверка: не просто «подключено», а «тестовая оплата проходит и статус приходит», «доставка считается во всех вариантах».
Аналитика
Аналитику тоже фиксируют в ТЗ как интеграцию: какие системы устанавливаются, какие цели и события отслеживаются (добавление в корзину, оформление, оплата, отправка форм), нужна ли электронная коммерция и передача данных о заказах. Без заложенной в ТЗ аналитики после запуска окажется, что воронку не видно, а значит, невозможно понять, где теряются покупатели.
Контент и наполнение
Магазин без контента — пустая витрина, и раздел контента в ТЗ отвечает на два вопроса: чем магазин наполняется и кто это делает. Второй вопрос — про зоны ответственности — критичен, потому что неготовность контента на стороне заказчика чаще тормозит запуск, чем сама разработка.
Источник и объём данных
В ТЗ фиксируют, откуда берутся данные каталога: из 1С обменом, от поставщиков, вводятся вручную. Указывают ориентировочный объём (количество товаров и разделов) и состав данных на товар: название, артикул, цена, остатки, характеристики, описание, фото. Это влияет и на настройку обмена, и на трудоёмкость наполнения, и на требования к производительности.
Контентная часть
Отдельно описывают то, что обмен из 1С не приносит: продающие описания разделов и товаров, тексты на посадочных страницах, справочная информация (доставка, оплата, гарантии, контакты), статьи. Качественный контент помогает и покупателю принять решение, и поиску понять страницу.
Зоны ответственности
Самый важный подраздел — кто за какой контент отвечает и в какие сроки его предоставляет. Часто именно здесь кроется причина срыва: подрядчик сделал каталог, но он «зияет пустотами», потому что заказчик не подготовил описания и фото. В ТЗ явно проговаривают: что готовит заказчик, что подрядчик, что относится к границам проекта (например, написание всех текстов может быть вне ТЗ и выполняться отдельно). Это защищает обе стороны от взаимных претензий «а мы думали, это вы».
Дизайн-требования и прототипы
Раздел дизайна в ТЗ описывает не «нарисуйте красиво», а требования к интерфейсу и способ снять неопределённость через прототипы. Дизайн магазина — инструмент конверсии, а не картинка, поэтому требования к нему тоже должны быть проверяемыми.
Требования к дизайну
Здесь фиксируют: фирменный стиль и его источники (гайдлайн, логотип, цвета), тон и ориентиры (референсы с пояснением, что именно в них нравится), обязательные элементы, требования к адаптивности (мобильная версия — полноценный сценарий, а не уменьшенная копия), приоритетные экраны (главная, каталог, карточка, корзина, оформление). Референсы полезны, но с оговоркой «нравится то-то и то-то», а не «сделайте как здесь» целиком — иначе это снова пожелание, а не требование.
Прототипы
Прототип — схематичный макет ключевых страниц без визуального оформления, показывающий расположение блоков и логику взаимодействия. Прототип в составе ТЗ (или как его продолжение) резко снижает риск недопонимания: спорные решения по структуре и сценариям «обкатывают» на дешёвой в переделке схеме, а не на готовой вёрстке. Согласованный прототип становится входом для дизайна и одновременно наглядной частью требований: по нему видно, что где расположено и как себя ведёт.
- Собрать референсы и стиль. Зафиксировать фирменный стиль и примеры с пояснением, что именно в них ценно.
- Определить приоритетные экраны. Главная, каталог, карточка, корзина, оформление — их прорабатывают в первую очередь.
- Сделать прототипы ключевых страниц. Проверить на них логику до дизайна и вёрстки.
- Согласовать прототипы. Именно на этом этапе дёшево менять структуру и сценарии.
- Зафиксировать требования к адаптиву. Описать поведение ключевых экранов на мобильных.
Редакция 1С-Битрикс и хостинг
Раздел платформы отвечает на вопрос «на чём работает магазин». Для проекта на 1С-Битрикс здесь фиксируют выбор редакции и требования к хостингу — и оба решения должны следовать из требований, а не из привычки или случайного совета.
Редакция 1С-Битрикс
Для интернет-магазина базово нужна редакция с торговым функционалом (каталог, корзина, заказы, скидки, обмен с 1С). Совсем младшие редакции без интернет-магазина не подойдут, а старшая enterprise-редакция нужна крупным высоконагруженным проектам. В ТЗ фиксируют выбранную редакцию и обоснование — под задачи и профиль нагрузки из предыдущих разделов. Отдельно указывают, используется ли готовое решение из Маркетплейса как основа или разработка ведётся индивидуально: это влияет и на структуру ТЗ, и на трудоёмкость.
Хостинг и окружение
Требования к хостингу выводят из нефункциональных требований: ожидаемая нагрузка, объём каталога, требования к скорости и безопасности определяют, какой сервер нужен. В ТЗ фиксируют требования к окружению (совместимость с версией платформы, необходимые модули PHP, СУБД), к резервному копированию и к тому, где размещается боевая и тестовая площадки. Важно, чтобы код и доступы принадлежали заказчику, — это тоже уместно зафиксировать, чтобы магазин оставался вашим активом, а не заложником одного исполнителя.
| Что решается | Из чего выводится |
|---|---|
| Редакция 1С-Битрикс | Набор функций, B2B-логика, профиль нагрузки, потолок роста |
| Готовое решение или разработка | Стандартность процессов, нестандартность требований |
| Требования к хостингу | Нагрузка, объём каталога, скорость, безопасность |
| Окружение и бэкапы | Совместимость с платформой, требования к устойчивости |
| Права на код и доступы | Требование сохранить контроль над активом |
Этапы, сроки, критерии приёмки и тест-кейсы
Этот раздел отвечает на вопросы «как движется проект» и «как мы поймём, что готово». Он превращает ТЗ из статичного описания в рабочий план с точками контроля.
Этапы и сроки
В ТЗ фиксируют этапы проекта, их зависимости и ориентиры по срокам. Важная оговорка: сроки в ТЗ — это ориентиры, выведенные из объёма работ, а не выдуманные цифры «под желание заказчика». Честнее описать, от чего зависит срок (объём каталога, число интеграций, готовность контента, скорость согласований), чем назвать точную дату, которая сорвётся. Разбивка на этапы даёт точки контроля и возможность принимать работу частями.
Критерии приёмки
Критерии приёмки — это заранее согласованный ответ на вопрос «как понять, что требование выполнено». Для каждого значимого требования формулируют проверяемое условие. Без критериев приёмка превращается в спор на ощущениях; с ними — в прохождение по чек-листу, где каждый пункт закрывают явно. Именно критерии приёмки делают «готово» фактом, а не мнением, и защищают обе стороны.
Тест-кейсы
Тест-кейс — это конкретный сценарий проверки: последовательность действий и ожидаемый результат. Из критериев приёмки удобно собирать тест-кейсы: «оформить заказ с доставкой курьером и оплатой картой → заказ создан, оплата прошла, статус пришёл, письмо отправлено, заказ ушёл в 1С». Хорошее ТЗ либо содержит ключевые тест-кейсы, либо даёт основу для их составления. Как из этого строится реальная проверка магазина перед запуском, мы разбираем в статье про тестирование и QA интернет-магазина.
| Требование | Критерий приёмки | Тест-кейс (проверка) |
|---|---|---|
| Приём оплаты картой | Оплата проходит, статус приходит на заказ, формируется чек | Оформить и оплатить тестовый заказ картой |
| Обмен с 1С | Товары, цены, остатки на сайте; заказы в учёте; без дублей | Изменить цену в 1С → проверить на сайте; создать заказ → проверить в учёте |
| Фильтр каталога | Фильтрует по заданным свойствам, пересчёт корректен, выбор в URL | Выбрать бренд и цену → проверить выдачу и адрес страницы |
| Мобильная вёрстка | Каталог, карточка, оформление работают на согласованных устройствах | Пройти покупку на телефоне в целевых браузерах |
Как ТЗ работает дальше: смета и приёмка
ТЗ — не документ «для архива», а рабочий инструмент, который живёт весь проект. Понять его ценность проще всего, проследив, как он используется дальше: из него собирается смета, по нему ведётся разработка, по нему же принимается результат. Это три роли одного документа, и все три ломаются, если ТЗ нет или оно расплывчато.
ТЗ → смета
Смета собирается из требований: каждое функциональное требование, интеграция и нестандартный сценарий имеют трудоёмкость. Чем конкретнее ТЗ, тем точнее оценка и тем меньше «вилка». Расплывчатое ТЗ вынуждает подрядчика либо закладывать большой запас на неопределённость (дороже для заказчика), либо назвать оптимистичную цифру, которая потом вырастет (конфликт). Хорошее ТЗ делает смету прозрачной и управляемой: видно, что стоит дорого и что можно убрать ради экономии.
ТЗ → разработка
Во время разработки ТЗ — источник истины: что делать, как это должно вести себя, где границы. Оно же — основа для управления изменениями: любое новое требование сверяется с ТЗ и либо включается через явную процедуру, либо переносится. Без ТЗ разработка идёт «по последнему разговору», и объём плывёт незаметно.
ТЗ → приёмка
На приёмке ТЗ — точка отсчёта: проверяют, что реализовано то, что описано, по критериям приёмки. Круг замыкается: требования из ТЗ превращаются в критерии приёмки, критерии — в тест-кейсы, тест-кейсы — в проверку. Магазин принимают не «на глаз», а по документу, с которого всё началось.
Границы проекта: что входит и что вне ТЗ
Самый недооценённый раздел ТЗ — не тот, что описывает функции, а тот, что описывает границы: что в проект не входит. Без явных границ возникает «расползание объёма» (scope creep): заказчик добросовестно считает, что «это же очевидно входит», подрядчик — что нет, и на приёмке начинается конфликт из-за вещей, которые никто не проговорил.
Что в scope
Основная часть ТЗ описывает то, что входит в работы: функции, интеграции, дизайн, наполнение в согласованном объёме. Но само по себе перечисление «что входит» не закрывает вопрос — потому что всё, что явно не названо, каждая сторона трактует в свою пользу.
Что out of scope
Поэтому в ТЗ явно перечисляют то, что в текущие работы не входит: например, написание всех продающих текстов, профессиональная фотосъёмка товаров, продвижение и реклама, интеграция с редкой внешней системой, мобильное приложение, миграция контента со старого сайта, обучение персонала. Это не способ «отвертеться», а честное очерчивание периметра. Заказчик заранее видит, что придётся делать отдельно или своими силами, а подрядчик — за что он не отвечает в рамках текущей сметы.
Процедура изменений
Границы работают в паре с процедурой изменений. Требования по ходу проекта уточняются — это нормально. Ненормально, когда изменения «дописываются незаметно». Поэтому в ТЗ (или договоре) фиксируют: новое требование оформляется письменно, оценивается по трудоёмкости и влиянию на срок, и стороны отдельно решают — включить сейчас, перенести на следующий этап или отклонить. Тогда объём остаётся управляемым, а не расползается.
Глоссарий: единый язык проекта
Глоссарий кажется формальностью, но в проекте по 1С-Битриксу он решает реальную проблему: стороны используют одни и те же слова в разных значениях. «Товар», «предложение», «вариант», «свойство», «цена», «остаток» — у заказчика, разработчика и специалиста по 1С за этими словами могут стоять разные сущности. Глоссарий фиксирует единый язык, на котором написано всё ТЗ.
Что полезно определить в глоссарии магазина на 1С-Битрикс:
- Товар и торговое предложение (SKU). Что считается товаром, а что — его вариантом (размер, цвет); как это соотносится с номенклатурой в 1С.
- Свойство и характеристика. Какие свойства участвуют в фильтре, какие в карточке, какие приходят из 1С.
- Тип цены. Розничная, оптовая, персональная, договорная — и откуда каждая берётся.
- Остаток и наличие. По складам или суммарно, как отображается, как обновляется обменом.
- Заказ и его статусы. Какие статусы существуют, что означает каждый, как они синхронизируются с учётом.
- Роль пользователя. Розничный, оптовый, сотрудник компании — и какие права у каждого.
- MVP и границы проекта. Что считается минимальным релизом, что входит и что вне работ.
Глоссарий особенно важен там, где сходятся сайт и 1С: расхождение в понимании «товара» и «предложения» — классическая причина проблем с обменом и каталогом. Пять минут на определение термина экономят часы споров, когда выясняется, что стороны имели в виду разное.
Шаблон-структура ТЗ на магазин
Собрав всё вместе, можно выписать рабочую структуру ТЗ — скелет, по которому удобно собирать документ под конкретный проект. Это не жёсткая форма, а ориентир: глубина каждого раздела подстраивается под сложность и риски, но набор блоков остаётся.
- Общие сведения. О проекте, о компании, назначение документа, участники и их зоны ответственности.
- Цели и KPI. Бизнес-цели магазина, отслеживаемые показатели, приоритизация требований.
- Целевая аудитория и сценарии. Сегменты пользователей, роли, ключевые пользовательские сценарии.
- Функциональные требования. Каталог, фильтр, поиск, карточка, корзина, оформление, оплата и доставка (логика), личный кабинет, B2B.
- Нефункциональные требования. Производительность и нагрузка, безопасность, совместимость и доступность, SEO.
- Интеграции. Обмен с 1С, CRM, оплата, доставка, аналитика, касса и маркировка — по каждой: что, куда, как.
- Контент и наполнение. Источник и объём данных, контентная часть, зоны ответственности и сроки предоставления.
- Дизайн и прототипы. Требования к дизайну и адаптиву, прототипы ключевых страниц.
- Платформа и хостинг. Редакция 1С-Битрикс, готовое решение или разработка, требования к серверу и бэкапам, права на код.
- Этапы и сроки. Разбивка на этапы, зависимости, ориентиры по срокам и от чего они зависят.
- Критерии приёмки и тест-кейсы. Проверяемые условия по требованиям, ключевые сценарии проверки.
- Границы проекта. Что входит, что явно вне работ, процедура изменений.
- Глоссарий. Определения ключевых терминов, особенно на стыке сайта и 1С.
По этой структуре легко проверить полноту готового ТЗ: пройдитесь по пунктам и отметьте, какие раскрыты, а какие «проскочили». Пропущенный раздел — сигнал вернуться и дописать, пока это дёшево. Если хотите увидеть, как ТЗ встраивается в общий ход проекта, посмотрите пошаговый разбор в гайде про запуск интернет-магазина на 1С-Битрикс, а другие материалы по стратегии собраны в рубрике «Бизнес и стратегия».
Частые ошибки в ТЗ
Эти ошибки повторяются из проекта в проект и дорого обходятся обеим сторонам. Зная их заранее, вы избежите большинства проблем ещё на этапе документа.
- Расплывчатые требования. «Сделайте красиво», «удобный фильтр», «быстрый сайт» — пожелания, которые нельзя оценить и принять. Каждое такое место — заложенный конфликт на приёмке.
- Нет критериев приёмки. Требования есть, а как проверить их выполнение — не написано. Приёмка превращается в спор на ощущениях «работает / не работает».
- Нет границ проекта. Не описано, что вне работ, — и объём расползается: заказчик считает «очевидно входит», подрядчик — нет.
- Поверхностное описание обмена с 1С. «Настроить обмен с 1С» одной строкой при том, что обмен определяет структуру всего каталога. Итог — переделка каталога под выгрузку.
- B2B общими словами. «Обычный магазин для юрлиц» вместо детального описания ролей, цен, кратности. У опта не бывает «как у всех».
- Забытые нефункциональные требования. Нет требований к скорости, нагрузке, безопасности, SEO — и они всплывают уже как проблемы после запуска.
- Не проговорены зоны ответственности за контент. Кто и когда даёт описания и фото — не написано, и запуск буксует на пустом каталоге.
- Выдуманные сроки и цифры. Точная дата «под желание» без привязки к объёму работ — обещание, которое сорвётся.
- Копирование чужого ТЗ. «Сделайте как у конкурента» или чужой шаблон без адаптации под свои процессы — источник требований, которые не ложатся на реальный бизнес.
- ТЗ пишет одна сторона. Только заказчик (технически наивно) или только подрядчик (без учёта процессов) — документ получается однобоким.
- Нет процедуры изменений. Требования меняются по ходу, но как их вносить — не описано, и изменения «дописываются незаметно», раздувая объём.
- Нет глоссария. Одни слова в разных значениях, особенно на стыке сайта и 1С, — разночтения, которые всплывают в самый неудобный момент.
Чек-лист готовности ТЗ
Перед тем как считать ТЗ готовым и запускать по нему смету и работы, пройдите по этому чек-листу. Он собирает воедино ключевые проверки со всех разделов.
- Цели и приоритеты зафиксированы. Ясно, зачем магазин, какие показатели отслеживаются, требования размечены по важности.
- Аудитория и сценарии описаны. Выделены сегменты и ключевые пользовательские сценарии, по ним проверена полнота функций.
- Функциональные требования конкретны. Каталог, фильтр, карточка, корзина, оформление, ЛК и B2B описаны проверяемо, без «сделайте удобно».
- Нефункциональные требования на месте. Скорость, нагрузка, безопасность, совместимость, доступность и SEO зафиксированы.
- Интеграции расписаны по отдельности. Обмен с 1С, CRM, оплата, доставка, аналитика — что, куда, как, по какому расписанию.
- Контент и зоны ответственности проговорены. Источник данных, объём, кто и когда даёт тексты и фото.
- Дизайн и прототипы согласованы. Требования к дизайну и адаптиву, прототипы ключевых страниц.
- Платформа и хостинг обоснованы. Редакция, готовое решение или разработка, требования к серверу, права на код.
- Этапы и критерии приёмки заданы. Разбивка на этапы, проверяемые критерии и ключевые тест-кейсы.
- Границы проекта явно очерчены. Описано, что вне работ, и как вносятся изменения.
- Глоссарий составлен. Определены термины, особенно на стыке сайта и 1С.
- ТЗ вычитано обеими сторонами. Заказчик и подрядчик согласовали каждый раздел и подтвердили единое понимание.
Если по большинству пунктов вы получаете уверенное «да, описано и согласовано», ТЗ готово стать основой сметы и работ. Если по критичным пунктам (обмен с 1С, оформление заказа, критерии приёмки, границы проекта) есть «вроде описано» — это не готовность, а риск, который проявится на приёмке.
Вывод
Техническое задание на интернет-магазин — это не бюрократия и не формальность, а перевод пожеланий в проверяемый план, который держит проект вместе. Хорошее ТЗ делает четыре вещи, каждая из которых окупает время на его составление: даёт сторонам единое понимание, служит основой честной сметы, становится точкой отсчёта на приёмке и защищает и заказчика, и подрядчика от споров «по понятиям». Из него собирается смета, по нему идёт разработка, по нему принимают результат — расплывчатое ТЗ ломает все три роли сразу.
Ключ к рабочему ТЗ — не объём, а проверяемость: конкретные требования вместо «сделайте красиво», критерии приёмки вместо «работает / не работает», явные границы проекта вместо «очевидно входит», детально описанный обмен с 1С и B2B вместо общих слов, единый глоссарий вместо разночтений. Уровень детализации подбирают под риск, а пишут ТЗ заказчик и подрядчик совместно: бизнес-контекст от одного, перевод в требования и оценку — от другого. Соберите документ по шаблон-структуре, пройдите чек-лист готовности — и «хочу магазин» превратится в управляемый проект с понятным результатом. А если нужна помощь на этом этапе, мы готовы собрать требования и составить ТЗ вместе с вами, а затем довести проект до запуска.
