DOC-REQ-001 User Stories и MoSCoW¶

Версия	Статус	Дата создания	Дата обновления
v0.2-test	Draft	2026-04-27	2026-04-27

О документе: фиксирует пользовательские истории, приоритеты MoSCoW и границы MVP.

Для кого: для команды разработки, аналитика, преподавателя и проверяющего.

1. MoSCoW¶

Must Have¶

Функция	Обоснование
Создание лида	Базовая операция CRM
Изменение статуса	Основной процесс движения по воронке
Просмотр списка лидов	Базовый обзор данных
Канбан-доска	Визуализация лидов по стадиям
История лида	Проверка прохождения стадий
Импорт CSV/XLSX	Требуется для загрузки тестовых данных
Экспорт Excel/CSV	Требуется для отчётности и проверки
Одобрение возврата стадии РОПом	Ключевое бизнес-правило
Выбор роли	Учебная замена авторизации

Should Have¶

Функция	Обоснование
Фильтр по источнику	Помогает анализировать каналы
Фильтр по менеджеру	Нужен РОП и аналитику
Фильтр по периоду	Нужен для отчётности
Просмотр воронки продаж	Поддерживает KPI
Расчёт средней длительности стадии	Поддерживает аналитику

Could Have¶

Функция	Обоснование
Теги для лидов	Полезно, но не критично
Дополнительные визуализации KPI	Можно добавить после MVP
Комментарии к сменам стадий	Есть в модели, но не всегда обязательны

Won’t Have¶

Функция	Причина исключения
Телефония	Выходит за рамки учебного MVP
Email-рассылки	Выходит за рамки кейса
Регистрация и авторизация	Заменены выбором роли
Персональные данные	Не используются в учебном проекте
Сумма сделки	Не входит в текущую модель БД
Интеграция с внешней CRM	Не требуется для MVP

2. User Stories¶

US-001. Создание лида менеджером¶

Как менеджер, я хочу создать нового лида, чтобы начать работу с потенциальным клиентом.

Acceptance:

менеджер открывает форму создания;
заполняет название, источник и заметку;
система создаёт лид в стадии new;
лид отображается в таблице и канбане менеджера.

US-002. Просмотр своих лидов менеджером¶

Как менеджер, я хочу видеть только свои лиды, чтобы работать со своей зоной ответственности.

Acceptance:

менеджер выбирает роль manager_1 или manager_2;
система показывает только лиды, где owner равен выбранному менеджеру;
чужие лиды не отображаются.

US-003. Перевод лида по стадиям¶

Как менеджер, я хочу переводить лид по стадиям, чтобы фиксировать прогресс работы.

Acceptance:

допустим переход только на следующую стадию;
new можно перевести только в qualified;
qualified можно перевести только в proposal;
proposal можно перевести в won или lost;
при переходе создаётся запись в истории стадий.

US-004. Запрос возврата стадии¶

Как менеджер, я хочу запросить возврат лида на предыдущую стадию, если стадия была выбрана ошибочно.

Acceptance:

менеджер нажимает «Возврат»;
система создаёт заявку на возврат;
стадия не меняется до одобрения РОП;
РОП видит заявку в очереди возвратов.

US-005. Одобрение возврата РОПом¶

Как руководитель отдела продаж, я хочу одобрять или отклонять возвраты стадий, чтобы контролировать корректность процесса.

Acceptance:

РОП открывает очередь возвратов;
видит лид, текущую стадию, целевую стадию и комментарий;
может одобрить возврат;
может отклонить возврат;
при отклонении заявка удаляется / закрывается без изменения стадии.

Принятое допущение: отдельной таблицы заявок на возврат в БД нет. В документации это описано как функциональный сценарий, но в финальной версии нужно сверить, где фактически хранится заявка.

US-006. Просмотр истории лида¶

Как пользователь с правом просмотра, я хочу видеть историю стадий лида, чтобы понимать, как он двигался по воронке.

Acceptance:

пользователь открывает историю;
видит стадии, время входа, время выхода и статус подтверждения;
комментарий отображается, если он был заполнен.

US-007. Просмотр всей воронки аналитиком¶

Как аналитик, я хочу видеть всю воронку, чтобы оценивать качество процесса продаж.

Acceptance:

аналитик видит лиды всех менеджеров;
не может менять данные;
видит распределение по стадиям;
может экспортировать данные.

US-008. Контроль всех лидов РОПом¶

Как РОП, я хочу видеть все лиды и управлять ими, чтобы контролировать работу отдела продаж.

Acceptance:

РОП видит всех лидов;
может фильтровать по менеджеру, источнику и периоду;
может менять стадии;
может экспортировать отчёт;
может одобрять возвраты.

US-009. Импорт лидов¶

Как пользователь с правом импорта, я хочу загрузить лиды из CSV/XLSX, чтобы быстро наполнить систему тестовыми данными.

Acceptance:

файл выбирается в интерфейсе;
валидные записи загружаются;
дубли по lead_uid пропускаются;
невалидные записи не ломают загрузку;
после импорта лиды отображаются в таблице.

US-010. Экспорт данных¶

Как аналитик или РОП, я хочу экспортировать лиды в Excel/CSV, чтобы проверить данные или использовать их в отчёте.

Acceptance:

пользователь нажимает экспорт;
система формирует файл;
файл содержит lead_uid, title, notes, owner, stage, entered_at, source_code;
данные соответствуют выбранным фильтрам.

US-011. Отчёт по KPI¶

Как аналитик или РОП, я хочу видеть конверсию и среднюю длительность стадий, чтобы находить узкие места процесса продаж.

Acceptance:

система считает долю won от общего количества лидов;
система считает среднюю длительность по стадиям;
данные можно фильтровать по источнику, менеджеру и периоду.