diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts index 158ac64..c3ce504 100644 --- a/docs/.vitepress/config.ts +++ b/docs/.vitepress/config.ts @@ -1,34 +1,32 @@ import { defineConfig } from 'vitepress'; export default defineConfig({ - title: 'Фрегат ЛК', + title: 'Техническое задание', description: 'Техническое задание на разработку личного кабинета Фрегат', lang: 'ru-RU', cleanUrls: true, themeConfig: { nav: [ - { text: 'ТЗ', link: '/tz/' }, - { text: 'Этап 1', link: '/tz/stage-1/' }, - { text: 'Текущее состояние', link: '/appendix/current-state' }, + { text: 'Техническое задание', link: '/' }, ], sidebar: [ { text: 'Техническое задание', items: [ - { text: 'Обзор', link: '/tz/' }, - { text: 'Нормативная база', link: '/tz/normative-base' }, - { text: 'Контур продукта', link: '/tz/product-scope' }, - { text: 'Роли и доступ', link: '/tz/roles-access' }, - { text: 'Функциональные требования', link: '/tz/functional-requirements' }, - { text: 'Данные и интеграции', link: '/tz/data-integrations' }, - { text: 'Этап 1 (UX/UI)', link: '/tz/stage-1/' }, - { text: 'Приемка и артефакты', link: '/tz/acceptance' }, + { text: '0. Общие положения', link: '/' }, + { text: '1. Основания и нормативная база', link: '/tz/normative-base' }, + { text: '2. Назначение и границы продукта', link: '/tz/product-scope' }, + { text: '3. Роли и права доступа', link: '/tz/roles-access' }, + { text: '4. Функциональные требования', link: '/tz/functional-requirements' }, + { text: '5. Данные и интеграции', link: '/tz/data-integrations' }, + { text: '6. Экранные формы и текстовые прототипы', link: '/tz/stage-1/' }, + { text: '7. Приемка и состав артефактов', link: '/tz/acceptance' }, ], }, { text: 'Приложения', items: [ - { text: 'Текущее состояние продукта', link: '/appendix/current-state' }, + { text: 'А. Текущее состояние продукта', link: '/appendix/current-state' }, ], }, ], diff --git a/docs/index.md b/docs/index.md index 0697304..34f46b4 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,34 +1,103 @@ ---- -layout: home +# Техническое задание на разработку программного продукта -hero: - name: "Личный кабинет Фрегат" - text: "Подробное техническое задание" - tagline: "Черновой пакет документов по договору №28/04-26ПО от 28 апреля 2026 года" - actions: - - theme: brand - text: Открыть ТЗ - link: /tz/ - - theme: alt - text: Этап 1 - link: /tz/stage-1/ +## 0. Общие положения -features: - - title: По договору и спецификации - details: Структура документа собрана на основании договора, приложения со спецификацией и текущей реализации продукта. - - title: По ГОСТ-логике - details: Каркас построен по логике ГОСТ 19.201-78, но адаптирован под современный B2B веб-продукт. - - title: Из кода, а не из фантазий - details: В документ вынесены реальные роли, разделы, сценарии и сущности, которые уже заложены в продукте. ---- +Наименование программного продукта: `Личный кабинет Фрегат`. -Этот пакет нужен как основа для согласования полного ТЗ и отдельного первого этапа. В текущей версии мы фиксируем: +Заказчик: ООО `Фрегат Групп`. -- рамки продукта -- состав ролей и интерфейсов -- сценарии клиента и менеджера -- требования к данным и интеграциям -- границы этапа 1 по UX/UI -- состав итоговых артефактов и приемки +Основания для разработки: -Рекомендуемый следующий шаг: пройти разделы `/tz/` сверху вниз, внести уточнения по спорным бизнес-правилам и после этого выпускать согласованную редакцию. +- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года +- приложение №1 к договору: спецификация основных требований к программному обеспечению `Личный кабинет Фрегат` +- текущая реализованная кодовая база клиентской и серверной части + +Настоящее техническое задание определяет: + +- назначение программного продукта +- состав и границы системы +- состав ролей и прав доступа +- функциональные и информационные требования +- требования к интеграциям +- требования к интерфейсным формам +- порядок приемки и состав передаваемых материалов + +## Содержание + +1. [Основания и нормативная база](/tz/normative-base) +2. [Назначение и границы продукта](/tz/product-scope) +3. [Роли и права доступа](/tz/roles-access) +4. [Функциональные требования](/tz/functional-requirements) +5. [Данные и интеграции](/tz/data-integrations) +6. [Экранные формы и текстовые прототипы](/tz/stage-1/) +7. [Приемка и состав артефактов](/tz/acceptance) +8. [Приложение. Текущее состояние продукта](/appendix/current-state) + +## Назначение продукта + +Программный продукт предназначен для автоматизации взаимодействия между клиентами ООО `Фрегат Групп` и сотрудниками компании в части: + +- регистрации и подключения клиентов +- выбора готовой продукции +- оформления заявок на заказ +- оформления заявок на расчет индивидуальной продукции +- согласования стоимости и условий доставки +- сопровождения заказов по статусам +- уведомления клиентов по изменениям +- отображения бонусного и реферального контура + +## Ожидаемый результат разработки + +Результатом выполнения работ должен являться развернутый на инфраструктуре заказчика B2B веб-продукт, который: + +- предоставляет отдельный клиентский и менеджерский интерфейс +- работает на desktop и mobile +- обеспечивает управление заказным контуром без отображения цены до ручной обработки менеджером +- обеспечивает хранение и отображение данных по клиентам, товарам, заявкам и заказам +- получает и отображает данные из 1С в согласованном объеме +- обеспечивает уведомления по email и подключенным мессенджерам +- позволяет сопровождать бонусную и реферальную программу + +## Объект автоматизации + +Объектом автоматизации являются процессы взаимодействия с B2B клиентами ООО `Фрегат Групп`, включая: + +- подключение новых клиентов +- работу с каталогом готовой продукции +- оформление и согласование заявок +- сопровождение заказов +- информирование клиентов +- бонусные и реферальные механики + +## Состав системы + +В состав системы входят: + +- клиентский веб-интерфейс +- менеджерский веб-интерфейс +- серверная бизнес-логика +- хранилище данных +- интеграционный слой обмена с 1С +- модуль уведомлений +- модуль бонусной программы +- модуль административных настроек + +## Общие требования к реализации + +Система должна быть реализована как единый программный продукт, в котором: + +- клиент не видит стоимость товара до обработки заявки менеджером +- менеджер управляет ценой, доставкой и согласованием +- данные по заказам и статусам могут обновляться от внешней системы 1С +- доступ к функциям определяется ролью пользователя +- действия пользователей журналируются + +## Принцип детализации настоящего ТЗ + +Настоящий документ описывает не абстрактную концепцию, а конкретный состав продукта. Поэтому дальнейшие разделы фиксируют: + +- реальные модули системы +- реальные действия клиента и менеджера +- реальные данные, подлежащие хранению и отображению +- реальные экранные формы и их состав +- реальные интеграционные требования diff --git a/docs/tz/acceptance.md b/docs/tz/acceptance.md index 1bb0476..423c16e 100644 --- a/docs/tz/acceptance.md +++ b/docs/tz/acceptance.md @@ -1,62 +1,72 @@ -# Приемка и передаваемые артефакты +# 7. Приемка и состав артефактов -## Этапность приемки +## 7.1 Общие положения приемки -Разработка и приемка продукта выполняются последовательно. +Приемка должна подтверждать, что разработанный программный продукт соответствует настоящему техническому заданию, договору и спецификации. -### Этап 1 +При приемке должны проверяться: -Критерий завершения: +- функциональность клиентского контура +- функциональность менеджерского контура +- работа с каталогом +- работа с заявками на заказ +- работа с заявками на расчет +- работа с заказами +- работа уведомлений +- работа бонусного контура +- работа интеграционного обмена в согласованном объеме -- заказчик согласовал 2-3 сверстанные страницы -- подтвержден визуальный подход -- подтверждена логика ключевых сценариев +## 7.2 Критерии приемки -### Этап 2 +Продукт считается соответствующим требованиям, если: -Критерий завершения: +- все обязательные сценарии выполняются +- роли и права разграничены корректно +- статусы и история изменений отображаются корректно +- каталог и остатки отображаются корректно +- клиент не видит цену до публикации условий менеджером +- менеджер может обрабатывать заявки и публиковать условия +- система сохраняет и отображает историю значимых действий -- реализован весь функционал, описанный в ТЗ, без интеграции с 1С -- стороны подтвердили работоспособность сценариев внутри системы +## 7.3 Передаваемые артефакты -### Этап 3 - -Критерий завершения: - -- настроен обмен с 1С -- подтверждена работоспособность интеграционных сценариев -- устранены блокирующие дефекты по интеграции - -## Итоговые артефакты, которые должны быть переданы - -По договору и спецификации в финальном комплекте должны быть: +В состав передаваемых материалов должны входить: - исходный код всех разработанных компонентов -- перечень сторонних модулей и версий -- дистрибутивные комплекты и зависимости -- схема взаимодействия модулей -- схема движения данных +- перечень используемых сторонних модулей и их версий +- сведения об используемых внешних API +- схемы взаимодействия модулей +- схемы движения данных - схемы баз данных и связей -- описание используемых сторонних API - распределение ролей пользователей - сетевые требования, порты и протоколы - обучающие материалы -- исходные графические материалы -- схема графического интерфейса +- исходные графические и интерфейсные материалы -## Что нужно зафиксировать в актах приемки по этапам +## 7.4 Требования к документации -В акте или приложении к акту по каждому этапу желательно отдельно перечислять: +Документация должна позволять: -- что именно показывалось заказчику -- какие сценарии проверялись -- какие замечания были сняты -- какие вопросы перенесены на следующий этап +- развернуть продукт +- сопровождать продукт +- понимать архитектуру модулей +- понимать состав данных +- понимать состав пользовательских ролей +- понимать сценарии интеграционного обмена -## Открытые вопросы перед выпуском финальной редакции ТЗ +## 7.5 Требования к фиксации замечаний -- окончательный перечень страниц первого этапа -- полный состав статусов заявок и заказов -- формат и объем бонусного контура на первом релизе -- обязательные поля клиента и контрагента -- формат данных и событий для интеграции с 1С +При приемке каждая выявленная проблема должна быть классифицирована по влиянию: + +- блокирующий дефект +- критичный дефект +- некритичное замечание +- пожелание к развитию + +Каждое замечание должно иметь: + +- описание +- шаги воспроизведения +- ожидаемый результат +- фактический результат +- статус устранения diff --git a/docs/tz/data-integrations.md b/docs/tz/data-integrations.md index eced12e..df3ac5f 100644 --- a/docs/tz/data-integrations.md +++ b/docs/tz/data-integrations.md @@ -1,105 +1,167 @@ -# Данные и интеграции +# 5. Данные и интеграции -## Основные сущности +## 5.1 Основные сущности данных -В текущем ТЗ должны быть формально закреплены следующие сущности: +Система должна оперировать следующими основными сущностями: - пользователь - роль - контрагент -- клиентская заявка на подключение +- заявка на подключение - товар -- остаток по складу +- складской остаток - корзина - заявка на заказ - заявка на расчет - заказ -- событие статуса заказа +- событие изменения статуса - уведомление - бонусная связь - бонусная транзакция -- заявка на вывод +- заявка на вывод вознаграждения -## Минимальный состав данных по ключевым сущностям +## 5.2 Обязательные данные по сущностям ### Пользователь +Обязательные поля: + - идентификатор - имя - email - телефон - роль -- статус доступа -- связанные мессенджеры -- привязанный контрагент +- статус учетной записи +- связанный контрагент +- подключенные каналы уведомлений + +### Контрагент + +Обязательные поля: + +- идентификатор +- наименование компании +- ИНН +- КПП +- юридический адрес +- контактные лица +- закрепленный менеджер ### Товар -- SKU -- наименование -- тип товара -- параметры товара -- флаги кастомизации -- остатки по складам - -### Заявка на заказ / расчет +Обязательные поля: + +- идентификатор +- SKU +- наименование +- тип продукции +- набор параметров +- остатки по складам +- признаки доступности + +### Заявка на заказ + +Обязательные поля: - идентификатор -- тип заявки - инициатор -- состав позиций или параметры изделия +- дата создания +- состав позиций +- количество +- комментарий клиента - статус -- история изменений -- стоимость после обработки -- параметры доставки - закрепленный менеджер +- стоимость после обработки +- параметры доставки после обработки + +### Заявка на расчет + +Обязательные поля: + +- идентификатор +- инициатор +- дата создания +- параметры изделия +- комментарий клиента +- статус +- закрепленный менеджер +- стоимость после обработки +- параметры доставки после обработки ### Заказ -- идентификатор во внутренней системе +Обязательные поля: + +- внутренний идентификатор - внешний идентификатор 1С - статус -- даты статусов -- состав +- даты изменений +- состав заказа - стоимость - доставка -- связанная заявка +- связанная клиентская заявка -## Интеграции +## 5.3 Требования к данным каталога -### Интеграция с 1С +Для каждой позиции в каталоге система должна хранить и отображать: -На уровне ТЗ фиксируем две группы обменов. +- тип товара +- параметры выбора +- описание параметров +- остатки по складам +- доступные варианты +- признаки кастомизации, если они применимы -#### Входящие события +## 5.4 Интеграция с 1С -- создание нового заказа -- изменение заказа -- обновление статуса -- обновление параметров доставки -- обновление состава и других полей заказа +Интеграция с 1С должна обеспечивать обмен данными о заказах и каталоге. -#### Методы получения данных +### Входящие события -- получение заказов клиента -- получение каталога -- получение характеристик товаров -- получение остатков по складам +Система должна принимать: -## Что нужно зафиксировать отдельно до финальной версии +- событие создания заказа +- событие изменения заказа +- событие изменения статуса +- событие изменения доставки +- событие изменения состава или иных параметров -- контракт webhook-событий -- идентификаторы и правила синхронизации сущностей -- правила дедупликации заказов -- политика ретраев и повторной обработки -- требования к логированию ошибок интеграции +### Методы получения данных -## Требования к журналированию +Система должна получать: -Для спорных операций система должна хранить: +- список заказов клиентов +- каталог товаров +- характеристики товаров +- остатки по складам + +## 5.5 Требования к интеграционному обмену + +Интеграционный слой должен обеспечивать: + +- сопоставление внутренних идентификаторов и идентификаторов 1С +- защиту от дублирования событий +- журналирование входящих событий +- повторную обработку неуспешных событий +- сохранение истории обновлений + +## 5.6 Требования к журналированию + +Для ключевых операций система должна хранить: - кто инициировал действие -- когда оно произошло +- когда произошло действие - какой объект был изменен -- какое было предыдущее значение статуса -- какое стало новое значение статуса +- какое состояние было до изменения +- какое состояние стало после изменения + +## 5.7 Бонусные данные + +Для бонусного контура система должна хранить: + +- текущий баланс +- историю начислений +- историю списаний +- реферальные связи +- заявки на вывод +- статус обработки заявок на вывод diff --git a/docs/tz/functional-requirements.md b/docs/tz/functional-requirements.md index a8a2364..1acab48 100644 --- a/docs/tz/functional-requirements.md +++ b/docs/tz/functional-requirements.md @@ -1,116 +1,130 @@ -# Функциональные требования +# 4. Функциональные требования -## 1. Авторизация и подключение +## 4.1 Авторизация и регистрация -Система должна поддерживать два способа входа клиента в продукт: +Система должна поддерживать два сценария подключения клиента: - регистрация по персональному приглашению -- самостоятельная регистрация с последующим согласованием менеджером +- самостоятельная регистрация через форму -### Обязательные сценарии +### Требования -- создание приглашения менеджером -- отправка приглашения по email -- самостоятельная подача заявки на подключение -- approve/reject заявки менеджером -- завершение регистрации и установка учетных данных -- привязка пользователя к контрагенту -- подключение Telegram и Max как каналов уведомлений +1. Менеджер должен иметь возможность отправить клиенту приглашение на email. +2. Клиент должен иметь возможность завершить регистрацию по полученной ссылке. +3. Клиент должен иметь возможность подать самостоятельную заявку на подключение. +4. После самостоятельной регистрации система должна сформировать заявку на рассмотрение менеджером. +5. Менеджер должен иметь возможность approve/reject заявки. +6. При approve система должна отправить клиенту приглашение для завершения регистрации. +7. После завершения регистрации клиент должен получить доступ к кабинету. +8. Клиент должен иметь возможность подключить Telegram и Max как каналы уведомлений. -## 2. Каталог готовой продукции +## 4.2 Каталог готовой продукции -Система должна предоставлять клиенту витрину готовой продукции. +Система должна отображать клиенту каталог готовой продукции без отображения цены. -### Обязательные сценарии +### Требования -- просмотр списка типов товаров -- переход в карточку конкретного типа товара -- выбор параметров продукции -- просмотр доступных вариантов -- сравнение остатков по складам -- добавление позиции в корзину без отображения цены +1. Система должна отображать список типов продукции. +2. Система должна позволять перейти в карточку конкретного типа товара. +3. Система должна отображать параметры выбора товара. +4. Система должна отображать доступные варианты товара. +5. Система должна отображать остатки по складам по каждой позиции. +6. Система должна позволять добавить позицию в корзину. +7. Система не должна отображать стоимость на этапе выбора товара. +8. Система должна отображать текстовые описания параметров и сценариев применения. -### Обязательные особенности - -- по каждой позиции должны отображаться характеристики товара -- по каждой позиции должны отображаться остатки по складам -- клиент не должен видеть цену на этапе выбора -- каталог должен поддерживать как стандартные параметры, так и информационные описания по применению - -## 3. Корзина и заявка на заказ +## 4.3 Корзина и заявка на заказ Система должна позволять клиенту собрать корзину и отправить заявку менеджеру. -### Обязательные сценарии +### Требования -- просмотр корзины -- изменение количества позиций -- удаление позиции -- отправка заявки на заказ -- фиксация состава заявки без цены -- передача заявки закрепленному менеджеру +1. Клиент должен видеть список выбранных позиций. +2. Клиент должен иметь возможность изменить количество. +3. Клиент должен иметь возможность удалить позицию. +4. Клиент должен иметь возможность отправить заявку на заказ. +5. После отправки заявки система должна зафиксировать состав позиций без стоимости. +6. Система должна назначить заявку закрепленному менеджеру. +7. Система должна сохранить время создания заявки и инициатора. -## 4. Обработка заявки менеджером +## 4.4 Менеджерская обработка заявки -Менеджер должен иметь возможность вручную обработать заявку. +Менеджер должен иметь возможность обработать заявку вручную. -### Обязательные сценарии +### Требования -- открытие заявки менеджером -- заполнение стоимости по позициям или по заявке -- указание параметров доставки -- публикация обновленных условий клиенту -- повторная корректировка до перевода в работу -- перевод заявки в работу -- отмена заявки +1. Менеджер должен видеть состав заявки. +2. Менеджер должен видеть данные клиента и контрагента. +3. Менеджер должен иметь возможность указать стоимость. +4. Менеджер должен иметь возможность указать параметры доставки. +5. Менеджер должен иметь возможность оставить комментарий. +6. Менеджер должен иметь возможность опубликовать условия клиенту. +7. Менеджер должен иметь возможность повторно изменить условия до перевода заявки в работу. +8. Менеджер должен иметь возможность перевести заявку в работу. +9. Менеджер должен иметь возможность отменить заявку. -Система должна фиксировать: +## 4.5 Заявка на расчет -- инициатора изменения -- дату и время действия -- историю изменения статусов +Система должна поддерживать сценарий заявки на расчет индивидуальной продукции. -## 5. Заявка на расчет +### Требования -Если готовая продукция не подходит, система должна переводить клиента в сценарий расчета. +1. Клиент должен иметь возможность перейти в расчетный сценарий, если готовая продукция не подходит. +2. Клиент должен иметь возможность заполнить параметры изделия. +3. Клиент должен иметь возможность отправить заявку на расчет. +4. Менеджер должен иметь возможность обработать заявку на расчет так же, как и заказную заявку. +5. Система должна публиковать стоимость клиенту только после ручной обработки менеджером. -### Обязательные сценарии +### Параметры расчетной заявки -- переход из каталога в заказ с расчетом -- заполнение параметров изделия -- отправка заявки на расчет -- ручная обработка стоимости менеджером -- публикация расчета клиенту -- перевод расчета в работу или отмену - -### Базовые параметры расчета - -Минимально в ТЗ должны быть закреплены: +Минимально система должна поддерживать передачу следующих параметров: - тип продукции - ширина - длина - толщина - цвет -- дополнительные параметры по конкретному типу товара +- микронность или эквивалентный параметр толщины +- специальные параметры в зависимости от типа продукции - комментарий клиента -## 6. Заказы и сопровождение +## 4.6 Статусы заявок + +Для заявок на заказ и заявок на расчет система должна поддерживать статусы, достаточные для управления процессом. + +Минимально должны быть предусмотрены следующие состояния: + +- создана +- отправлена менеджеру +- обработана менеджером +- условия опубликованы +- в работе +- отменена + +Для каждого изменения статуса система должна фиксировать: + +- инициатора +- дату и время +- предыдущее состояние +- новое состояние + +## 4.7 Заказы и сопровождение Система должна отображать клиенту список заказов и карточку каждого заказа. -### Обязательные сценарии +### Требования -- просмотр списка заказов -- фильтрация по периоду -- просмотр карточки заказа -- отображение статуса из 1С -- отображение изменений по заказу -- отправка трекинг-уведомлений +1. Система должна отображать список заказов клиента. +2. Система должна поддерживать фильтрацию истории заказов по периоду. +3. Система должна отображать карточку заказа. +4. Система должна отображать актуальный статус заказа. +5. Система должна отображать историю изменений по заказу. +6. Система должна отображать стоимость и параметры доставки, если они доступны. +7. Система должна отображать дату актуальности данных. -## 7. Уведомления +## 4.8 Уведомления -Система должна поддерживать многоканальные уведомления. +Система должна поддерживать уведомления по нескольким каналам. ### Каналы @@ -118,23 +132,35 @@ - Telegram - Max -### События +### События уведомлений - приглашение к регистрации - approve/reject подключения - публикация условий по заявке - изменение статуса заказа -- изменения по бонусному балансу +- изменения бонусного баланса +- обработка заявки на вывод -## 8. Бонусная программа +## 4.9 Бонусная программа -Бонусный контур должен быть описан в ТЗ как отдельная функциональная область. +Система должна поддерживать бонусный контур как полноценную функциональную область продукта. -Минимально должны быть зафиксированы: +### Требования -- реферальная привязка клиентов -- начисления и списания -- журнал бонусных операций -- магазин вознаграждений -- заявка на вывод -- менеджерская обработка заявок на вывод +1. Менеджер должен иметь возможность создавать реферальные связи. +2. Система должна хранить бонусные начисления и списания. +3. Клиент должен видеть текущий бонусный баланс. +4. Клиент должен видеть историю бонусных операций. +5. Клиент должен иметь возможность использовать бонусы в рамках правил программы. +6. Клиент должен иметь возможность подать заявку на вывод при достижении минимального порога. +7. Менеджер должен иметь возможность обрабатывать заявку на вывод. +8. Система должна уведомлять клиента об изменениях бонусного состояния. + +## 4.10 Административные настройки + +Система должна предоставлять административные разделы для управления: + +- параметрами каталога +- шаблонами уведомлений +- параметрами синхронизации +- бонусным контуром в разрешенной части diff --git a/docs/tz/product-scope.md b/docs/tz/product-scope.md index 4971594..76d98aa 100644 --- a/docs/tz/product-scope.md +++ b/docs/tz/product-scope.md @@ -1,79 +1,108 @@ -# Контур продукта +# 2. Назначение и границы продукта -## Назначение +## 2.1 Назначение системы -`Личный кабинет Фрегат` предназначен для того, чтобы клиент мог самостоятельно работать с заказами и взаимодействием с менеджером в единой системе без постоянной ручной переписки. +`Личный кабинет Фрегат` предназначен для переноса клиентского B2B взаимодействия из разрозненной переписки и ручного обмена файлами в единый веб-интерфейс. -## Основные пользовательские блоки +Система должна обеспечить: -### Для клиента +- единый вход клиента в процессы компании +- цифровой выбор готовой продукции +- цифровую отправку заявок на заказ и расчет +- ручное согласование коммерческих условий менеджером +- прозрачное сопровождение заказа по статусам +- уведомление клиента о значимых изменениях + +## 2.2 Границы продукта + +Продукт охватывает следующие функциональные области: + +- регистрация и подключение клиента +- каталог готовой продукции +- карточка товара и выбор параметров +- корзина и отправка заявки на заказ +- заявка на расчет кастомной продукции +- менеджерская обработка заявок +- карточка заказа и история заказов +- уведомления +- бонусная и реферальная программа +- административные настройки + +Продукт не предназначен для: + +- самостоятельного расчета цены клиентом +- бухгалтерского учета +- публичной B2C торговли +- самостоятельного изменения клиентом бизнес-правил компании + +## 2.3 Пользовательские контуры + +### Клиентский контур + +Клиентский контур должен включать: - вход и завершение регистрации -- профиль компании и контактов -- каталог готовой продукции -- карточка товара с параметрами и остатками -- корзина -- заявка на заказ -- заявка на расчет кастомной продукции -- список заказов -- карточка заказа +- профиль компании +- каталог продукции +- карточку товара +- корзину +- список заявок и заказов +- карточку заказа - уведомления -- бонусная программа +- бонусный кабинет -### Для менеджера +### Менеджерский контур -- обработка заявок на подключение -- обработка клиентских заказов и расчетов -- ручное заполнение стоимости и условий доставки -- публикация обновленных условий клиенту -- просмотр клиентов и контрагентов -- управление реферальными связями -- обработка бонусных операций и заявок на вывод -- настройка каталога, уведомлений и синхронизации +Менеджерский контур должен включать: -## Ключевые бизнес-сценарии +- обработку заявок на подключение +- обработку заказных заявок +- обработку расчетных заявок +- работу с клиентами +- работу с заказами +- бонусные операции +- административные настройки -### Сценарий 1. Подключение клиента +## 2.4 Основные бизнес-сценарии -1. Клиент получает приглашение или самостоятельно подает заявку. -2. Менеджер проверяет данные. -3. При approve клиент завершает регистрацию. -4. Клиент получает доступ в кабинет. +### Сценарий А. Подключение нового клиента -### Сценарий 2. Заказ готовой продукции +1. Клиент получает приглашение от менеджера или самостоятельно подает заявку на подключение. +2. Менеджер проверяет данные клиента. +3. Менеджер принимает решение approve/reject. +4. При approve система отправляет клиенту ссылку для завершения регистрации. +5. Клиент завершает регистрацию и получает доступ в кабинет. -1. Клиент открывает каталог. -2. Выбирает тип товара и параметры. -3. Видит доступные остатки по складам. -4. Добавляет позиции в корзину. -5. Отправляет заявку без цены. -6. Менеджер проставляет цену и условия доставки. -7. Клиент получает обновленные условия. -8. Одна из сторон переводит заявку в работу или отменяет ее. +### Сценарий Б. Заказ готовой продукции -### Сценарий 3. Заявка на расчет +1. Клиент открывает каталог готовой продукции. +2. Клиент выбирает тип товара. +3. Клиент выбирает параметры товара. +4. Клиент видит доступные варианты и остатки по складам. +5. Клиент добавляет позиции в корзину. +6. Клиент отправляет заявку без цены. +7. Менеджер указывает стоимость и условия доставки. +8. Клиент получает обновленные условия и принимает решение. -1. Клиент понимает, что готовая продукция не подходит. -2. Переходит в режим расчета. -3. Заполняет параметры продукции. -4. Отправляет заявку менеджеру. -5. Менеджер указывает цену и условия доставки. -6. Клиент получает расчет и принимает решение. +### Сценарий В. Заявка на расчет -### Сценарий 4. Сопровождение заказа +1. Клиент понимает, что готовый товар не подходит под задачу. +2. Клиент переходит в режим расчета. +3. Клиент заполняет параметры изделия. +4. Клиент отправляет заявку на расчет. +5. Менеджер указывает стоимость и условия доставки. +6. Клиент получает расчет и может продолжить работу по заявке. -1. После создания заказа статусы поступают из 1С. -2. Клиент видит актуальный статус и изменения. -3. Система отправляет уведомления по подключенным каналам. +### Сценарий Г. Сопровождение заказа -## Границы первой проектной фиксации +1. Заказ создается и получает статус. +2. Изменения по заказу поступают в систему. +3. Клиент видит актуальный статус и обновленные данные. +4. Система отправляет уведомления клиенту. -Для первой полноценной редакции ТЗ мы фиксируем все разделы продукта, но детализируем в первую очередь: +### Сценарий Д. Бонусная программа -- авторизацию и подключение клиента -- каталог и заказ готовой продукции -- расчет кастомной продукции -- менеджерскую обработку заявки -- карточку заказа и список заказов - -Бонусная программа должна быть описана в ТЗ, но на раннем этапе может иметь меньшую глубину детализации интерфейсов, чем заказный контур. +1. Менеджер создает или поддерживает реферальную связь. +2. Система отражает бонусные начисления и изменения баланса. +3. Клиент видит бонусный баланс и историю операций. +4. Клиент может использовать бонусы или подать заявку на вывод в рамках правил программы. diff --git a/docs/tz/roles-access.md b/docs/tz/roles-access.md index 8aebb33..d68582a 100644 --- a/docs/tz/roles-access.md +++ b/docs/tz/roles-access.md @@ -1,62 +1,89 @@ -# Роли и доступ +# 3. Роли и права доступа -## Основные роли +## 3.1 Состав ролей -### Клиент +В системе должны быть предусмотрены следующие базовые роли: -Клиент работает в личном кабинете своей организации и имеет доступ только к данным, относящимся к его компании. +- клиент +- менеджер +- суперменеджер -Клиент может: +## 3.2 Роль `Клиент` -- войти по приглашению или после approve заявки -- редактировать профиль и контактные данные в разрешенных пределах +Клиент представляет организацию-контрагента и работает только в рамках данных своей компании. + +Клиент должен иметь возможность: + +- завершить регистрацию по приглашению +- подать заявку на подключение +- просматривать и редактировать собственные профильные данные в разрешенной части - подключать каналы уведомлений -- выбирать готовую продукцию -- создавать заявки на заказ -- создавать заявки на расчет -- просматривать заказы, статусы, историю и уведомления -- просматривать бонусную информацию и подавать заявки на вывод, если это предусмотрено правилами +- работать с каталогом готовой продукции +- добавлять товары в корзину +- отправлять заявку на заказ +- отправлять заявку на расчет +- просматривать список своих заказов +- просматривать карточку заказа +- просматривать уведомления +- просматривать бонусный баланс и историю операций +- подавать заявку на вывод, если это разрешено правилами программы -### Менеджер +## 3.3 Роль `Менеджер` -Менеджер работает с закрепленными клиентами, их заявками, заказами и бонусными операциями. +Менеджер представляет сотрудника компании, закрепленного за клиентами. -Менеджер может: +Менеджер должен иметь возможность: - рассматривать заявки на подключение -- approve/reject регистрацию +- approve/reject регистрацию клиента - привязывать клиента к контрагенту -- принимать клиентские заявки на заказ и расчет -- вручную указывать стоимость и параметры доставки +- получать заявки на заказ +- получать заявки на расчет +- указывать стоимость +- указывать параметры доставки - публиковать условия клиенту -- переводить заявку в работу или отменять ее -- просматривать связанные с клиентами данные -- управлять реферальными связями и бонусными операциями +- переводить заявку в работу +- отменять заявку +- просматривать карточки клиентов +- просматривать карточки заказов +- работать с бонусными связями и заявками на вывод -### Суперменеджер +## 3.4 Роль `Суперменеджер` -Суперменеджер имеет все права менеджера плюс расширенные права на управление данными и настройками. +Суперменеджер является расширенной административной ролью. -Суперменеджер может: +Суперменеджер должен иметь все права менеджера, а также дополнительно: -- работать со всеми клиентами, а не только со своими -- управлять настройками каталога -- управлять шаблонами уведомлений -- управлять параметрами синхронизации -- выполнять административные операции по бонусной системе +- доступ ко всем клиентам и всем заказам +- управление настройками каталога +- управление настройками уведомлений +- управление настройками синхронизации +- расширенный доступ к бонусному контуру -## Ограничения доступа +## 3.5 Матрица доступа + +| Действие | Клиент | Менеджер | Суперменеджер | +| --- | --- | --- | --- | +| Завершение регистрации | Да | Нет | Нет | +| Подача заявки на подключение | Да | Нет | Нет | +| Просмотр каталога | Да | Да | Да | +| Добавление товара в корзину | Да | Нет | Нет | +| Отправка заявки на заказ | Да | Нет | Нет | +| Отправка заявки на расчет | Да | Нет | Нет | +| Указание стоимости и доставки | Нет | Да | Да | +| Публикация условий клиенту | Нет | Да | Да | +| Перевод заявки в работу | Да | Да | Да | +| Отмена заявки | Да | Да | Да | +| Управление настройками каталога | Нет | Нет | Да | +| Управление настройками уведомлений | Нет | Нет | Да | +| Управление синхронизацией | Нет | Нет | Да | + +## 3.6 Ограничения и безопасность доступа Система должна обеспечивать: - раздельные интерфейсы клиента и менеджера -- изоляцию клиентских данных по контрагенту -- контроль административных настроек только для расширенных ролей -- журналирование ключевых действий по заявкам и заказам - -## Открытые вопросы для финальной фиксации - -- может ли один клиент иметь несколько пользователей внутри одной организации -- как разделяются полномочия между менеджером и суперменеджером в части справочников -- кто именно может изменять каталог, уведомления и бонусные настройки -- требуется ли дополнительная роль наблюдателя или оператора +- доступ клиента только к собственному контрагенту и его объектам +- ограничение административных функций по ролям +- журналирование действий пользователя +- возможность аудита изменения статусов и условий заявок diff --git a/docs/tz/stage-1/index.md b/docs/tz/stage-1/index.md index f7940cc..308d05c 100644 --- a/docs/tz/stage-1/index.md +++ b/docs/tz/stage-1/index.md @@ -1,84 +1,204 @@ -# Этап 1: UX/UI +# 6. Экранные формы и текстовые прототипы -## Назначение этапа +## 6.1 Общие требования к экранным формам -Первый этап нужен не для полной разработки продукта, а для согласования визуального подхода, экранной структуры и базовой логики пользовательских сценариев. +Экранные формы должны обеспечивать понятную навигацию, читаемое отображение статусов, явное разделение клиентского и менеджерского контура и однозначную привязку действий к текущему объекту. -Согласно приложению к договору, на этапе должны быть представлены `2-3 сверстанные страницы` с основными элементами интерфейса. +Для всех ключевых форм должны выполняться требования: -## Рекомендуемый состав страниц этапа +- на экране должен быть понятен текущий объект работы +- должен быть виден текущий статус объекта +- действия пользователя должны соответствовать роли и статусу объекта +- клиент не должен видеть стоимость до публикации условий менеджером +- остатки по складам должны отображаться в наглядном виде -### Страница 1. Каталог / карточка товара +## 6.2 Клиентские формы -Цель страницы: +### 6.2.1 Главная страница клиента -- показать, как клиент выбирает готовую продукцию -- показать параметры, доступные варианты и остатки -- показать переход к заказу и к расчету +Назначение: -Что должно быть на странице: +- входная точка в систему +- доступ к основным разделам +- отображение важных текущих событий -- список или карточка типа товара -- иллюстрация товара -- выбор параметров -- описания параметров и сценариев применения -- доступные варианты -- индикация остатков по складам +Состав: + +- шапка с навигацией +- блок быстрых переходов +- блок актуальных заказов +- блок последних уведомлений + +Прототип: + +```text ++-------------------------------------------------------------+ +| Header: каталог | заказы | уведомления | бонусы | профиль | ++-------------------------------------------------------------+ +| Быстрые действия | +| [Каталог] [Мои заказы] [Бонусы] [Профиль] | ++-------------------------------------------------------------+ +| Актуальные заказы | +| № | статус | дата | действие | ++-------------------------------------------------------------+ +| Последние уведомления | ++-------------------------------------------------------------+ +``` + +### 6.2.2 Каталог продукции + +Назначение: + +- показать доступные товарные направления +- дать переход в карточку типа товара + +Состав: + +- поиск +- сетка карточек типов продукции + +### 6.2.3 Карточка типа товара + +Назначение: + +- выбор параметров товара +- просмотр остатков и доступных вариантов +- добавление в корзину + +Состав: + +- заголовок +- изображение +- блок параметров +- блок описания параметров +- SKU выбранной позиции - действие `В корзину` -- действие перехода в расчетный сценарий +- таблица доступных вариантов -### Страница 2. Карточка заявки / заказа клиента +Прототип: -Цель страницы: +```text ++-------------------------------------------------------------+ +| Назад | Тип товара | ++-------------------------------------------------------------+ +| Изображение | Параметры выбора | SKU / В корзину | +| | ширина | | +| | длина | | +| | толщина | | +| | цвет / надпись | | ++-------------------------------------------------------------+ +| Таблица доступных вариантов | +| SKU | ширина | длина | толщина | остатки | действие | ++-------------------------------------------------------------+ +``` -- показать, как клиент видит созданную заявку или заказ -- показать статусы, историю изменений и опубликованные менеджером условия +### 6.2.4 Корзина -Что должно быть на странице: +Назначение: -- номер заявки или заказа -- текущий статус -- состав заказа -- стоимость после обработки менеджером -- параметры доставки -- история статусов -- действия `Отправить в работу` / `Отменить`, если стадия это допускает +- проверка состава заказа +- корректировка количества +- отправка заявки -### Страница 3. Менеджерская обработка заявки +### 6.2.5 Карточка заявки / заказа -Цель страницы: +Назначение: -- показать рабочее место менеджера -- показать, как менеджер вносит стоимость и условия +- отображение состава, статуса, стоимости, доставки и истории -Что должно быть на странице: +Прототип: -- данные клиента -- состав заявки или параметры расчета -- поле стоимости -- блок доставки -- комментарий менеджера +```text ++-------------------------------------------------------------+ +| № заявки / заказа | Статус | ++-------------------------------------------------------------+ +| Состав | ++-------------------------------------------------------------+ +| Стоимость и доставка | ++-------------------------------------------------------------+ +| История изменений | ++-------------------------------------------------------------+ +| [Отправить в работу] [Отменить] | ++-------------------------------------------------------------+ +``` + +### 6.2.6 Список заказов + +Назначение: + +- просмотр текущих и архивных заказов +- фильтрация по периоду + +### 6.2.7 Уведомления + +Назначение: + +- просмотр истории уведомлений по всем объектам + +### 6.2.8 Бонусный кабинет + +Назначение: + +- просмотр бонусного баланса +- просмотр истории операций +- выполнение действий в рамках бонусной программы + +## 6.3 Менеджерские формы + +### 6.3.1 Список клиентов + +Назначение: + +- просмотр клиентов +- переход в карточку клиента + +### 6.3.2 Карточка клиента + +Назначение: + +- просмотр компании, заявок, заказов и бонусных связей + +### 6.3.3 Карточка обработки заявки + +Назначение: + +- ввод стоимости и доставки - публикация условий клиенту -- действия по статусу заявки +- управление статусом -## Что должно быть согласовано по результату этапа +Прототип: -- визуальный стиль кабинета -- логика компоновки клиентских и менеджерских экранов -- базовый набор UI-паттернов -- структура основных карточек и таблиц -- подход к отображению статусов, уведомлений и складских остатков +```text ++-------------------------------------------------------------+ +| Клиент | Контрагент | Менеджер | ++-------------------------------------------------------------+ +| Состав заявки / параметры изделия | ++-------------------------------------------------------------+ +| Стоимость | +| Доставка | +| Комментарий менеджера | ++-------------------------------------------------------------+ +| [Опубликовать условия] [В работу] [Отменить] | ++-------------------------------------------------------------+ +``` -## Что не требуется завершать на этом этапе +### 6.3.4 Список заказов менеджера -- полную реализацию бизнес-логики -- реальные интеграции с 1С -- все вспомогательные разделы -- полную настройку бонусной программы +Назначение: -## Связанные материалы, которые желательно приложить к этапу +- просмотр заказов по клиентам +- контроль текущих статусов -- экранная карта -- список состояний каждой из 3 страниц -- перечень компонентов интерфейса -- список открытых вопросов, блокирующих следующий этап +### 6.3.5 Настройки каталога + +Назначение: + +- управление параметрами типов продукции +- управление описаниями и вариантами + +### 6.3.6 Настройки уведомлений и синхронизации + +Назначение: + +- управление шаблонами сообщений +- управление параметрами обмена