DOC-GOV-002 Реестр рисков и матрица рисков¶

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

О документе: реестр фиксирует основные риски CRM_14, их причины, влияние, вероятность и меры снижения.

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

1. Подход к оценке рисков¶

Команда использует простую матрицу 3 × 3.

Вероятность:

низкая;
средняя;
высокая.

Влияние:

низкое;
среднее;
высокое.

Уровень риска:

низкий;
средний;
высокий.

2. Реестр рисков¶

RISK-001. Несогласованность PostgreSQL-схемы и 1С-контура¶

Причина: в проекте одновременно описывается логическая схема mini_crm_simple и учебная реализация в 1С.

Вероятность: средняя.
Влияние: высокое.
Уровень до мер: высокий.

Меры:

явно описать, что PostgreSQL-схема является логической моделью;
отдельно указать роль 1С как учебного контура;
не добавлять в документацию таблицы, которых нет в исходной схеме;
сверять API и БД по одному набору сущностей.

Владелец риска: Рахимов Шамиль, Кучин Иван.

RISK-002. Нечёткая ролевая модель¶

Причина: в учебном проекте нет полноценной авторизации, а роль выбирается вручную на стартовом экране.

Вероятность: средняя.
Влияние: среднее.
Уровень до мер: средний.

Меры:

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

Владелец риска: Кармаев Андрей, Полухина Елизавета.

RISK-003. Ошибки в бизнес-правилах движения лида¶

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

Вероятность: средняя.
Влияние: высокое.
Уровень до мер: высокий.

Меры:

зафиксировать цепочку new → qualified → proposal → won/lost;
запретить пропуск стадий;
описать отдельный сценарий возврата через РОП;
добавить acceptance-критерии на переходы.

Владелец риска: Кармаев Андрей, Рахимов Шамиль.
Триггер: лид можно перевести напрямую из new в proposal или в won.

RISK-004. Недостаточность тестовых данных¶

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

Вероятность: средняя.
Влияние: среднее.
Уровень до мер: средний.

Меры:

подготовить 100 тестовых лидов;
распределить лиды по всем стадиям;
добавить разные источники;
добавить двух менеджеров;
включить завершённые и незавершённые стадии.

Владелец риска: Рахимов Шамиль.
Триггер: отчёт по воронке не показывает все стадии.

RISK-005. Импорт создаёт дубли¶

Причина: при повторной загрузке CSV/XLSX один и тот же лид может добавиться повторно.

Вероятность: средняя.
Влияние: высокое.
Уровень до мер: высокий.

Меры:

использовать lead_uid как ключ идемпотентности;
при дубле пропускать запись;
добавить тест на повторный импорт;
описать поведение импорта в acceptance.

Владелец риска: Рахимов Шамиль, Кучин Иван.
Триггер: повторный импорт увеличивает количество лидов за счёт дублей.

RISK-006. Scope проекта расширится¶

Причина: CRM легко расширить телефонией, email, авторизацией, финансовыми полями и сложной аналитикой.

Вероятность: высокая.
Влияние: среднее.
Уровень до мер: высокий.

Меры:

держать MoSCoW как основной контроль scope;
не включать телефонию, email и регистрацию;
теги и дополнительные визуализации оставить в Could Have;
не добавлять новые таблицы без решения команды.

Владелец риска: Кармаев Андрей.
Триггер: появляются задачи, которых нет в MVP.

RISK-007. Интерфейс и backend расходятся¶

Причина: frontend может ожидать поля или endpoints, которых нет в backend.

Вероятность: средняя.
Влияние: среднее.
Уровень до мер: средний.

Меры:

описать API-контракты;
согласовать поля lead_uid, title, source_code, current_stage, owner, notes;
использовать единые enum-значения;
проверять сценарии через демо.

Владелец риска: Маркина Майя, Полухина Елизавета, Рахимов Шамиль.
Триггер: экран не может отобразить лид из-за несовпадения структуры ответа.

RISK-008. Неполная документация к финальной сдаче¶

Причина: команда сосредоточится на демо и не успеет описать ТЗ, БД, тесты и сценарии.

Вероятность: средняя.
Влияние: высокое.
Уровень до мер: высокий.

Меры:

собрать единый Markdown-документ;
выделить спорные места подчёркнутым курсивом;
заранее подготовить acceptance-критерии;
связать документацию с презентацией.

Владелец риска: Кармаев Андрей.
Триггер: на защите есть демо, но нет полного описания требований и проверки.

3. Главные риски¶

Главными рисками команда считает:

несогласованность БД и 1С-контура;
ошибки в бизнес-правилах движения лида;
дубли при импорте;
расширение scope;
неполную документацию.