Короткий ответ
Техническое задание на B2B-портал должно описывать не только страницы и функции. В нём нужно зафиксировать роли пользователей, бизнес-сценарии, данные, интеграции, права доступа, админку, ошибки, этапы MVP, критерии приёмки и ограничения развития.
Если ТЗ описывает только интерфейс, подрядчик будет додумывать бизнес-логику во время разработки. Это почти всегда увеличивает сроки, стоимость и количество спорных решений.
Чем B2B-портал отличается от обычного сайта
B2B-портал обычно связан с реальными операционными процессами: заказами, заявками, документами, статусами, оплатами, отгрузками, согласованиями, партнёрами, менеджерами, складами, CRM, 1С или внутренними сервисами.
Поэтому ТЗ должно отвечать на вопросы:
- кто пользуется порталом;
- какие задачи выполняет каждая роль;
- какие данные откуда приходят;
- какие действия пользователь может совершать;
- какие статусы и документы участвуют в процессе;
- какие интеграции критичны;
- что происходит при ошибке;
- как система будет развиваться после первого релиза.
Без этих ответов портал легко превращается в набор экранов, который сложно поддерживать и развивать.
Если такая ситуация уже случилась в работающем проекте, полезно отдельно разобрать, почему портал стало невозможно развивать и какие слои мешают новым доработкам.
1. Цель и границы проекта
В начале ТЗ нужно зафиксировать, зачем создаётся портал и где его границы.
Важно описать:
- бизнес-цель проекта;
- какие процессы портал должен заменить или усилить;
- какие подразделения, клиенты, партнёры или сотрудники участвуют;
- что входит в первый релиз;
- что сознательно не входит в MVP;
- какие ограничения есть по срокам, бюджету, данным и интеграциям.
Это помогает не смешивать в одном документе обязательный функционал, идеи на будущее и пожелания “когда-нибудь”.
2. Роли пользователей и права доступа
Для B2B-портала модель ролей часто важнее дизайна. Ошибка в правах доступа может привести к утечке данных, неправильным действиям или хаосу в поддержке.
В ТЗ нужно описать:
- все типы пользователей;
- какие разделы видит каждая роль;
- какие действия разрешены;
- какие данные доступны только для чтения;
- кто может создавать, менять, согласовывать или отменять объекты;
- какие действия требуют подтверждения;
- какие исключения есть для отдельных подразделений или клиентов.
Если в будущем планируются AI-функции, роли нужно описывать особенно аккуратно: AI не должен видеть больше данных, чем разрешено пользователю.
3. Бизнес-сценарии вместо списка экранов
Слабое ТЗ часто выглядит как перечень страниц: главная, личный кабинет, заявки, документы, отчёты, профиль. Для сложного портала этого мало.
Нужно описывать сценарии:
- пользователь создаёт заявку;
- менеджер проверяет и меняет статус;
- клиент получает уведомление;
- система отправляет данные в CRM или 1С;
- документ становится доступен для скачивания;
- при ошибке обмена задача уходит ответственному сотруднику;
- администратор видит журнал действий.
У каждого сценария должны быть начало, результат, участники, данные, ошибки и исключения. Подробнее об архитектуре таких систем есть в статье что входит в архитектуру личного кабинета.
4. Данные и источники истины
B2B-портал редко хранит все данные сам. Обычно он получает информацию из CRM, 1С, ERP, складской системы, биллинга, документооборота, базы клиентов или внешних API.
В ТЗ нужно определить:
- какие данные отображаются в портале;
- где находится источник истины по каждому типу данных;
- какие данные пользователь может редактировать;
- какие данные только отображаются;
- как часто информация обновляется;
- что происходит при расхождении данных;
- кто отвечает за исправление ошибок.
Если источники истины не описать, портал начнёт показывать противоречивые статусы, дубли и устаревшие документы. Это одна из причин, почему интеграции ломают портал.
5. Интеграции
Интеграции нельзя оставлять на уровень “подключить CRM” или “синхронизировать с 1С”. Для разработки этого недостаточно.
По каждой интеграции нужно описать:
- назначение обмена;
- какие данные передаются;
- в каком направлении идёт обмен;
- как часто он выполняется;
- что запускает обмен;
- какие ограничения есть у внешней системы;
- как логируются ошибки;
- кто видит сбой и что делает дальше;
- нужен ли ручной повтор обмена.
Если интеграции критичны для бизнеса, их лучше проектировать до выбора подрядчика. Это снижает риск, что разные команды дадут несопоставимые оценки.
6. Админка и операционная работа
Админка не должна быть остаточным разделом “для управления всем”. В B2B-портале она часто определяет, сможет ли бизнес обслуживать систему без постоянных доработок.
В ТЗ нужно описать:
- какие справочники редактируются через админку;
- кто управляет пользователями и ролями;
- какие статусы можно менять вручную;
- какие документы загружаются или заменяются;
- какие уведомления настраиваются;
- какие действия должны попадать в журнал;
- какие операции нельзя выполнять без подтверждения.
Хорошая админка снижает нагрузку на разработку и поддержку. Слабая админка превращает каждое изменение в задачу для подрядчика.
7. Ошибки, исключения и нестандартные ситуации
ТЗ часто описывает идеальный путь, но реальные порталы живут в исключениях: интеграция недоступна, документ не загружен, заявка зависла, пользователь ошибся, данные не совпали, сотрудник ушёл в отпуск.
Нужно заранее описать:
- что видит пользователь при ошибке;
- кто получает уведомление;
- можно ли повторить действие;
- как откатить ошибочную операцию;
- где хранится журнал событий;
- какие ошибки критичны;
- какие действия выполняются вручную.
Если исключения не описать, команда будет принимать решения во время разработки, а бизнес узнает о них только на приёмке.
8. MVP и этапы развития
Для B2B-портала особенно важно разделить первый релиз и будущие этапы. Без этого ТЗ быстро превращается в большой список желаний.
Разделите функциональность на:
- MVP: без чего портал не решает основную задачу;
- следующий этап: что усиливает продукт после запуска;
- опционально: идеи, которые можно отложить;
- технические условия: что нужно сделать, чтобы будущие этапы были возможны.
Такой подход помогает не перегрузить первый релиз и одновременно не закрыть себе развитие архитектурными решениями.
9. Критерии приёмки
ТЗ должно помогать принимать результат, а не только начинать разработку.
Для ключевых сценариев стоит зафиксировать:
- что считается готовым результатом;
- какие роли участвуют в проверке;
- какие данные должны совпадать;
- какие интеграции проверяются;
- какие ошибки недопустимы;
- какие документы и инструкции передаются;
- кто принимает результат со стороны бизнеса.
Если критериев приёмки нет, спор о готовности проекта становится субъективным: подрядчик считает, что задача сделана, а бизнес видит недоработанный процесс.
10. Документация и передача
Даже если проект делает один подрядчик, ТЗ должно предусматривать передачу знаний. Это не недоверие к команде, а нормальная защита бизнеса.
Минимально стоит зафиксировать:
- карту модулей;
- карту ролей и сценариев;
- описание интеграций;
- инструкцию по окружениям и релизам;
- список доступов и владельцев сервисов;
- известные ограничения и технический долг;
- правила обновления документации.
Если документация откладывается “на потом”, проект становится зависимым от отдельных людей. При смене команды это превращается в отдельную проблему.
Подробный состав документации для уже работающего проекта разобран отдельно: что должно быть в технической документации web-проекта.
Что не нужно включать в ТЗ
ТЗ не должно быть перегружено второстепенными деталями, которые лучше уточнять в проектировании или дизайне.
Обычно не стоит фиксировать слишком жёстко:
- точные названия всех кнопок до проектирования сценариев;
- декоративные детали интерфейса;
- будущие функции без бизнес-приоритета;
- технические решения без обсуждения архитектуры;
- требования “как у конкурента” без описания процесса;
- AI-функции без данных, ролей и метрик качества.
ТЗ должно оставаться рабочим документом, а не формальной энциклопедией проекта.
Когда ТЗ лучше заменить проектированием
Если портал сложный, одно текстовое ТЗ может быть недостаточным. Тогда полезнее сначала провести проектирование web-портала: разобрать цели, роли, процессы, данные, интеграции, MVP и архитектурный контур.
Проектирование особенно важно, если:
- есть несколько ролей и подразделений;
- портал связан с CRM, 1С или ERP;
- есть личный кабинет, админка и внутренние процессы;
- нужно выбирать подрядчика по сопоставимым требованиям;
- в будущем планируются AI-сценарии;
- бизнес хочет понять бюджет и риски до разработки.
Если проект уже начался, но требования расползлись, стоит начать с аудита web-проекта и карты текущего состояния.
Практический вывод
ТЗ на B2B-портал должно описывать систему: роли, сценарии, данные, интеграции, админку, ошибки, MVP, приёмку и передачу. Чем лучше это сделано до разработки, тем меньше риск дорогих переделок и конфликтов на приёмке.
Если сейчас есть только общая идея портала, не стоит сразу отдавать её в разработку. Сначала нужно превратить идею в карту процессов и решений. Это дешевле, чем исправлять архитектуру после первых релизов.
