ТЗ на разработку B2B-портала: с чего начать, чтобы не уйти в долгострой.
06.10.2026
Каталог, корзина, заказы и интеграция с 1С — ещё не техническое задание. Пока компания не решила, откуда берётся цена, кто резервирует товар и как обрабатывается частичная отгрузка, подрядчик оценивает не проект, а собственные предположения. Разбираем, какие решения зафиксировать до разработки и как превратить их в проверяемые требования.
1. Почему проект становится долгостроем до первой строки кода
Компания приносит подрядчику привычный список: личный кабинет, каталог, персональные цены, остатки, корзина, заказы, документы, интеграция с 1С. По нему можно обсудить состав разделов, но нельзя достоверно оценить логику работы.
Во время разработки обнаруживается, что один сотрудник закупает от имени нескольких юридических лиц, цена зависит от договора, остатки распределены между складами, а заказ включает складские и заказные позиции. Часть товара уже отгружена, часть ещё производится. В ERP у строк разные состояния, а в макете предусмотрен один статус на весь заказ. Вдобавок нужного метода обмена нет.
Приходится менять модель данных, экраны и интеграцию одновременно. Дело не в том, что разработчики забыли кнопку: в момент оценки ещё не были приняты решения, определяющие объём работ. ТЗ должно выявить такие зависимости до того, как они превратятся в переделки.
Во время разработки обнаруживается, что один сотрудник закупает от имени нескольких юридических лиц, цена зависит от договора, остатки распределены между складами, а заказ включает складские и заказные позиции. Часть товара уже отгружена, часть ещё производится. В ERP у строк разные состояния, а в макете предусмотрен один статус на весь заказ. Вдобавок нужного метода обмена нет.
Приходится менять модель данных, экраны и интеграцию одновременно. Дело не в том, что разработчики забыли кнопку: в момент оценки ещё не были приняты решения, определяющие объём работ. ТЗ должно выявить такие зависимости до того, как они превратятся в переделки.
2. ТЗ начинается не с экранов
Удобный прототип не отвечает на вопрос, можно ли отгрузить часть заказа при просроченной задолженности. Сначала бизнес описывает результат и правила, затем команда проектирует поведение системы. Рабочая последовательность выглядит так:
Цепочка подготовки требований: от бизнес-цели до критериев приёмки.
Для каждого перехода нужен ответственный. Коммерческий директор определяет правила продаж, финансовая команда — лимиты и условия оплаты, логистика — резерв и отгрузку, IT — источники данных и технические ограничения. Аналит
Цепочка подготовки требований: от бизнес-цели до критериев приёмки.
Для каждого перехода нужен ответственный. Коммерческий директор определяет правила продаж, финансовая команда — лимиты и условия оплаты, логистика — резерв и отгрузку, IT — источники данных и технические ограничения. Аналит
3. Что подготовить до полноценного ТЗ
Прежде чем составлять ТЗ, необходимо описать текущий процесс (AS IS), целевой процесс (TO BE), бизнес-цели, границы первой версии, пользователей, юридические лица и торговые точки. К этому комплекту добавляют карту систем, источники данных, предварительную схему обменов, ограничения и реестр открытых вопросов с ответственными. Полнота каждого материала зависит от стадии проекта: для предварительной оценки допустимы зафиксированные допущения, а блокирующие зависимости необходимо проверить до утверждения сроков и бюджета.
В журнале предпроекта фиксируют вопрос, возможные решения, ответственного, срок ответа и влияние на оценку. Вопросы, которые затрагивают основной сценарий заказа, стоимость или интеграции, нельзя оставлять со статусом «обсудим позже». После утверждения ТЗ изменения ведут отдельно — по согласованной процедуре.
Минимум для предварительной оценки: границы MVP, схема основного заказа, перечень ролей и организаций, источники цен и остатков, известные интеграции и список открытых вопросов. До фиксации окончательных сроков и бюджета отдельно подтверждают зависимости, способные изменить архитектуру или основной сценарий.
Минимум для предварительной оценки: границы MVP, схема основного заказа, перечень ролей и организаций, источники цен и остатков, известные интеграции и список открытых вопросов. До фиксации окончательных сроков и бюджета отдельно подтверждают зависимости, способные изменить архитектуру или основной сценарий.
4. Зафиксировать границы проекта раньше списка функций
Границы проекта фиксируют по двум признакам. Первый — состав релиза: входит в MVP, переносится в следующую очередь, временно остаётся ручным или не входит в проект. Второй — место реализации: ERP/1С, CRM, B2B-портал либо другая система. Одна функция может одновременно входить в MVP и выполняться в ERP. Отдельный список исключений помогает избежать споров о первоначальном объёме работ и дополнительной оплате.
Типичная цепочка расширения: сначала нужны каталог и заказ, затем договоры, согласования, логистика, отчёты, рекламации, бонусная программа и приложение. Все задачи могут быть полезны, но не обязаны входить в первый релиз. Для каждой новой идеи владелец продукта решает: заменить ею другую задачу, перенести в backlog или согласовать изменение сроков и бюджета.
Уточнение раскрывает уже согласованное поведение; изменение бизнес-правила меняет его смысл; новая функция добавляет сценарий; ошибка означает несоответствие утверждённому требованию. Эти категории нельзя смешивать при приёмке и управлении изменениями. О выборе состава первой версии подробнее — в статье «MVP B2B-портала за 5 месяцев».
Типичная цепочка расширения: сначала нужны каталог и заказ, затем договоры, согласования, логистика, отчёты, рекламации, бонусная программа и приложение. Все задачи могут быть полезны, но не обязаны входить в первый релиз. Для каждой новой идеи владелец продукта решает: заменить ею другую задачу, перенести в backlog или согласовать изменение сроков и бюджета.
Уточнение раскрывает уже согласованное поведение; изменение бизнес-правила меняет его смысл; новая функция добавляет сценарий; ошибка означает несоответствие утверждённому требованию. Эти категории нельзя смешивать при приёмке и управлении изменениями. О выборе состава первой версии подробнее — в статье «MVP B2B-портала за 5 месяцев».
5. Пользователи, организации и права
Пары «пользователь / администратор» недостаточно. У организации могут быть несколько юрлиц, договоров, филиалов, торговых точек и складов. Закупщик оформляет заказ, бухгалтер получает документы, руководитель согласует закупку, администратор организации приглашает сотрудников, менеджер поставщика сопровождает сделку.
Нужно определить не только действие, но и его контекст: от чьего имени сотрудник работает, какой договор выбран, видит ли задолженность и может ли открыть заказ другой торговой точки. Права проверяются на сервере, а не только скрытием кнопки
Нужно определить не только действие, но и его контекст: от чьего имени сотрудник работает, какой договор выбран, видит ли задолженность и может ли открыть заказ другой торговой точки. Права проверяются на сервере, а не только скрытием кнопки
Практический вопрос, который нельзя оставить за рамками: кто создаёт первую учётную запись — ERP по данным контрагента или сотрудник поставщика? Если для входа по SMS нужен телефон, нужно определить сценарий для контрагента, у которого телефон не заполнен.
6. Один сквозной сценарий вместо разрозненных экранов
Проведите заказ по всей цепочке:
авторизация → выбор юрлица → каталог → цена и остаток → корзина → заказ → передача в ERP → резерв → статус → отгрузка → документы.
На каждом шаге укажите бизнес-правило, систему-источник и ожидаемое состояние при ошибке.
Например, подтверждение на экране ещё не означает резерв на складе. Укажите, какое событие создаёт резерв и какое подтверждение ERP позволяет показать статус «Принят». Если заказ содержит складскую и производимую позиции, правила могут различаться. Прежде чем утверждать макеты, проверьте сквозной сценарий на реальных примерах данных: если на каком-либо этапе неизвестны источник информации или правило обработки, оценка этой функции остаётся предварительной.
авторизация → выбор юрлица → каталог → цена и остаток → корзина → заказ → передача в ERP → резерв → статус → отгрузка → документы.
На каждом шаге укажите бизнес-правило, систему-источник и ожидаемое состояние при ошибке.
Например, подтверждение на экране ещё не означает резерв на складе. Укажите, какое событие создаёт резерв и какое подтверждение ERP позволяет показать статус «Принят». Если заказ содержит складскую и производимую позиции, правила могут различаться. Прежде чем утверждать макеты, проверьте сквозной сценарий на реальных примерах данных: если на каком-либо этапе неизвестны источник информации или правило обработки, оценка этой функции остаётся предварительной.
7. Как формулировать функциональные требования
Фраза «показывать персональную цену» не определяет ни источника, ни получателя, ни сценария ошибки. Рабочее требование должно отвечать на вопросы: кто запрашивает данные, для какого юридического лица и договора, по какому правилу определяется цена, когда она обновляется, что происходит при исключении и как проверить результат. Приведённый ниже вариант с ценой из ERP по договору — пример; в конкретном проекте правило может зависеть также от прайс-листа, контрагента или нескольких условий.
Пример перехода от пожелания к проверяемому требованию о персональной цене.
В истории заказов отдельно согласуют, входят ли заказы, оформленные менеджером вне портала, можно ли повторить заказ и когда разрешена отмена. Для остатков определяют, показывать точное число или диапазон, учитывать ли резерв и что делать при изменении количества во время оформления. Например: одна команда может показать общий остаток по всем складам, а другая — только доступный выбранному дилеру. Формально обе выполнят требование «показывать остатки», но результат будет разным.
Пример функционального требования: доступный остаток
Условие: пользователь вошёл в портал и выбрал разрешённое юридическое лицо и торговую точку. Действие: открывает карточку товара. Правило: портал показывает доступный к заказу остаток по разрешённым складам из согласованного источника с учётом резерва по утверждённой методике. В ТЗ фиксируют допустимый срок актуальности данных и период их обновления. Исключение: если данные устарели, портал показывает согласованное сообщение; разрешено ли в таком случае оформление заказа, определяют отдельным бизнес-правилом. Приёмка: сверить показанный остаток с контрольными данными ERP, проверить нулевой остаток, резерв, смену торговой точки и истечение допустимого срока актуальности. Это образец формата: источники, сроки и правила резерва согласуют для конкретного проекта.
Условие: пользователь вошёл в портал и выбрал разрешённое юридическое лицо и торговую точку. Действие: открывает карточку товара. Правило: портал показывает доступный к заказу остаток по разрешённым складам из согласованного источника с учётом резерва по утверждённой методике. В ТЗ фиксируют допустимый срок актуальности данных и период их обновления. Исключение: если данные устарели, портал показывает согласованное сообщение; разрешено ли в таком случае оформление заказа, определяют отдельным бизнес-правилом. Приёмка: сверить показанный остаток с контрольными данными ERP, проверить нулевой остаток, резерв, смену торговой точки и истечение допустимого срока актуальности. Это образец формата: источники, сроки и правила резерва согласуют для конкретного проекта.
8. Альтернативные сценарии — часть функции, а не доработка
Для каждого критичного действия определяют, что произойдёт при ошибке. ERP недоступна; заказ отправлен повторно; цена отсутствует; остаток изменился; пользователь потерял доступ к юрлицу; документ ещё не сформирован; обмен вернул неполный ответ; заказ не прошёл проверку кредитного лимита. Для каждого случая фиксируют действие системы, сообщение пользователю, сохранность данных, правила повторной передачи, уведомление ответственного и запись ошибки.
Условный пример: пользователь нажал «Оформить», но ответ ERP не пришёл. Портал сохраняет заказ с собственным идентификатором и статусом «Ожидает подтверждения» и повторяет передачу по согласованному правилу. При повторном нажатии или повторной отправке тот же заказ не должен создаваться в ERP второй раз: для этого заранее согласовывают сопоставление идентификаторов и обработку повторных запросов. Это пример проектного решения, а не универсальный режим; его необходимо подтвердить с IT и бизнесом.
Условный пример: пользователь нажал «Оформить», но ответ ERP не пришёл. Портал сохраняет заказ с собственным идентификатором и статусом «Ожидает подтверждения» и повторяет передачу по согласованному правилу. При повторном нажатии или повторной отправке тот же заказ не должен создаваться в ERP второй раз: для этого заранее согласовывают сопоставление идентификаторов и обработку повторных запросов. Это пример проектного решения, а не универсальный режим; его необходимо подтвердить с IT и бизнесом.
Пример из практики: построчные статусы при частичной отгрузке
На одном из проектов B2B-портала один заказ мог включать складские и заказные позиции с разными сроками готовности: часть товара находилась в резерве, другая ожидала поступления или производства, а отдельные позиции уже были отгружены.
При описании сценария выяснилось, что общий статус «Частично отгружен» не показывает дилеру, какие именно товары отправлены и каких ещё нужно ждать.
Для этого сценария согласовали построчные статусы и отображение количества по каждой позиции. В требования также включили правила разделения строк между резервом, ожиданием, производством и отгрузкой.
В проектной модели предусмотрели отображение состояния отдельных позиций, а не только заказа целиком. Даже если ERP поддерживает частичные отгрузки, состав передаваемых статусов и количества необходимо отдельно согласовать для личного кабинета.
9. Данные и интеграции: что скрывается за строкой «связать с 1С»
Карта обменов — таблица, где зафиксировано, какие данные, из какой системы, куда и при каком событии передаются. Для каждой сущности нужны идентификаторы, обязательные поля, формат, направление, частота, правила преобразования, поведение при ошибке, повторная отправка, журнал и ответственный. Список сущностей обычно включает товары, характеристики, коллекции, цены, скидки, остатки, склады, контрагентов, договоры, юрлица, торговые точки, пользователей, заказы и их строки, статусы, счета, оплаты, документы, отгрузки и рекламации. Направления в таблице ниже приведены как пример; инициатор и конкретный механизм каждого обмена определяются архитектурой проекта.
Особенно внимательно проверяют идентификаторы строк. Если ERP возвращает позиции в другом порядке, сопоставлять их по номеру в списке нельзя: резерв и отгрузка могут привязаться не к тому товару. Нужен устойчивый идентификатор и согласованное правило связи исходной строки с её состояниями или дочерними строками при разделении на резерв, ожидание производства и отгрузку. Конкретная схема зависит от модели данных ERP.
Пример из практики: доставка заказа несколькими рейсами
На одном из проектов B2B-портала заказ мог отгружаться несколькими партиями, а доставка учитывалась в количестве оплаченных рейсов. После частичной отгрузки необходимо было определить, сколько рейсов уже выполнено и сколько товара ещё требуется перевезти.
Количество оставшихся оплаченных рейсов само по себе не показывает, хватит ли их для отгрузки. Нужно сопоставить оставшийся товар с грузоподъёмностью выбранного транспорта: даже одной ещё не выполненной доставки может быть недостаточно.
Поэтому в требованиях связали количество оплаченных и выполненных рейсов, остаток товара и грузоподъёмность. Для окончательного расчёта необходимо отдельно согласовать источники сведений об отгрузках, место расчёта и правило действий при нехватке грузоподъёмности.
При подготовке ТЗ такой сценарий нужно описывать не только для первоначального оформления заказа, но и для повторного расчёта после каждой частичной отгрузки. Результат реализации и проверки в этом примере не заявлен.
10. API-first: сначала проверить возможность обмена
API-first в контексте проекта означает: сначала определить необходимые пользователю данные и операции, описать требования к обмену, а затем проверить, может ли существующая инфраструктура их предоставить. Это не требование переделать всю ERP. Например, если порталу нужен доступный остаток по торговой точке, а действующий метод возвращает только общий остаток, такую разницу необходимо обнаружить до утверждения логики интерфейса.
Вариант первый: необходимый метод уже есть. IT передаёт описание, доступ к тестовому контуру и примеры ответов; разработчик проверяет полноту данных. Второй: нужные данные хранятся в ERP, но существующий механизм обмена не позволяет получить их в необходимом составе. Тогда доработку ERP включают в план проекта с владельцем, сроком и совместным тестом. Третий: исходная система не хранит нужное правило. Бизнес выбирает место реализации, согласует временный ручной сценарий либо исключает функцию из MVP. Отказ от полной автоматизации в первой версии иногда позволяет не блокировать запуск.
В приложении к ТЗ для каждого метода фиксируют назначение, параметры запроса и ответа, обязательные поля, авторизацию, коды ошибок, время ожидания, повторные запросы, защиту от дублей, журналирование, тестовый контур и ответственную команду. Таймаут — сколько портал ждёт ответ; защита от дублей — почему повтор не создаёт второй заказ. Конкретные значения согласуют по реальной инфраструктуре.
Выбор платформы и объёма адаптации связан с этими ограничениями; отдельный разбор — «Готовое решение или кастомная разработка B2B-портала».
Вариант первый: необходимый метод уже есть. IT передаёт описание, доступ к тестовому контуру и примеры ответов; разработчик проверяет полноту данных. Второй: нужные данные хранятся в ERP, но существующий механизм обмена не позволяет получить их в необходимом составе. Тогда доработку ERP включают в план проекта с владельцем, сроком и совместным тестом. Третий: исходная система не хранит нужное правило. Бизнес выбирает место реализации, согласует временный ручной сценарий либо исключает функцию из MVP. Отказ от полной автоматизации в первой версии иногда позволяет не блокировать запуск.
В приложении к ТЗ для каждого метода фиксируют назначение, параметры запроса и ответа, обязательные поля, авторизацию, коды ошибок, время ожидания, повторные запросы, защиту от дублей, журналирование, тестовый контур и ответственную команду. Таймаут — сколько портал ждёт ответ; защита от дублей — почему повтор не создаёт второй заказ. Конкретные значения согласуют по реальной инфраструктуре.
Выбор платформы и объёма адаптации связан с этими ограничениями; отдельный разбор — «Готовое решение или кастомная разработка B2B-портала».
11. Нефункциональные требования без произвольных цифр
В ТЗ описывают ожидаемое число пользователей и одновременных операций, размер каталога, рост истории заказов, требования к скорости ключевых действий, поддерживаемые браузеры и устройства. Требования к нагрузке определяют по текущему использованию и планам бизнеса, затем согласуют условия проверки. Не стоит переносить значения из универсального шаблона без проверки применимости.
Отдельно согласуют разграничение доступа, защиту персональных и коммерческих данных, журнал действий, резервное копирование и восстановление, мониторинг обменов, хранение ошибок, тестовую и боевую среды, инфраструктуру и порядок развёртывания. Для каждого измеримого требования указывают способ проверки и условия: объём данных, тип операции, тестовый контур и допустимый результат.
Отдельно согласуют разграничение доступа, защиту персональных и коммерческих данных, журнал действий, резервное копирование и восстановление, мониторинг обменов, хранение ошибок, тестовую и боевую среды, инфраструктуру и порядок развёртывания. Для каждого измеримого требования указывают способ проверки и условия: объём данных, тип операции, тестовый контур и допустимый результат.
12. Приёмка: проверять результат, а не впечатление
«Удобно», «быстро» и «интеграция работает корректно» не являются критериями приёмки. Используйте формат «исходное условие → действие → ожидаемый результат». Для цены нужен контрольный договор, для остатков — известный резерв, для прав — пользователь без доступа.
Каждое критичное требование связывают с критерием приёмки и тест-кейсом. Результат проверки фиксируют, чтобы заказчик и разработчик могли подтвердить выполнение требования. Если тестовые данные не подготовлены, даже точное требование нельзя проверить.
13. Кто за что отвечает
Обязанности зависят от договора, но до оценки необходимо определить, кто утверждает бизнес-правила, предоставляет данные и отвечает за доработки внешних систем. Разработчик не может самостоятельно утвердить кредитную политику, а клиентский IT-отдел должен заранее знать о необходимости нового API.
Зафиксируйте конкретных ответственных, дату готовности тестового контура, порядок предоставления доступов и того, кто принимает спорные решения. Например, за тестовый контур ERP назначают сотрудника, который может организовать доступ и подтвердить срок его готовности. Общая формулировка «ответственный — команда клиента» не закрывает такую зависимость.
14. Как менять ТЗ без бесконечной переоценки
ТЗ не обязано оставаться неизменным. Но у него должна быть версия, журнал изменений, реестр открытых вопросов и один владелец продукта. Новую задачу заносят в backlog, оценивают влияние на архитектуру, интеграции, тестирование, сроки и стоимость. Если изменение затрагивает утверждённую базу, оформляют запрос на изменение (Change Request) и согласуют до начала работы.
Исправление дефекта не подменяют платной новой функцией; новую бизнес-логику не проводят под видом «маленького уточнения». Например, уточнить название существующего статуса — не то же самое, что добавить согласование заказа руководителем. Во втором случае меняется сценарий, набор прав и объём тестирования: влияние на сроки и стоимость нужно оценить до реализации
Исправление дефекта не подменяют платной новой функцией; новую бизнес-логику не проводят под видом «маленького уточнения». Например, уточнить название существующего статуса — не то же самое, что добавить согласование заказа руководителем. Во втором случае меняется сценарий, набор прав и объём тестирования: влияние на сроки и стоимость нужно оценить до реализации
15. ТЗ — связанный набор материалов, а не гигантский файл
Основной документ хранит цели, границы и требования. Отдельные приложения удобнее для схем процессов, матрицы ролей, карты разделов, сценариев, таблицы статусов, карты обменов, API-контрактов, UX-прототипов, критериев приёмки, тест-кейсов и backlog. Каждое приложение имеет версию и ссылку из основного документа.
Основной документ и приложения должны иметь версии и понятные связи: руководитель согласует объём, аналитик уточняет правила, разработчик реализует их, тестировщик проверяет результат. Порядок предпроектных этапов и комплект результатов подробнее разобраны в материале «Методология внедрения B2B-портала».
Основной документ и приложения должны иметь версии и понятные связи: руководитель согласует объём, аналитик уточняет правила, разработчик реализует их, тестировщик проверяет результат. Порядок предпроектных этапов и комплект результатов подробнее разобраны в материале «Методология внедрения B2B-портала».
16. Красные флаги перед стартом
Для более широкой проверки организации перед запуском используйте материал «Чек-лист внедрения B2B-портала». Здесь проверяется именно качество требований.
Пять опор, которые должны быть согласованы до старта разработки.
18. Итог
До начала разработки согласуйте границы MVP, права пользователей, бизнес-правила, источники данных, ответственность за интеграции и критерии приёмки. Если эти вопросы остаются открытыми, оценка проекта должна явно учитывать связанные риски и зависимости. ТЗ не обязано описывать каждую кнопку до пикселя, но должно позволять реализовать и проверить согласованные сценарии.
Разработка B2B порталов
