Риск в контексте анализа — это неопределённое событие или условие, которое при реализации может повлиять на цели проекта, продукта или процесса выявления и документирования требований. Аналитик первым сталкивается с неоднозначностями, противоречивыми ожиданиями и «белыми пятнами» на стыке бизнеса и разработки. Управление рисками на этапе анализа не заменяет общий риск-менеджмент проекта: оно фокусируется на источниках неопределённости в требованиях и позволяет предотвратить дорогостоящие переделки.
1. Суть темы
Риск (risk) — эффект неопределённости на цели (ISO 31000). В работе аналитика это прежде всего угрозы качеству и полноте требований, доступности стейкхолдеров, реализуемости решения и устойчивости процесса elicitation. Рейтинг риска (risk score) — отдельное понятие: обычно произведение оценок вероятности и воздействия; именно рейтинг определяет приоритет в реестре, а не «определение риска».
Эта статья описывает процессный слой качества анализа — цикл идентификации, оценки, реагирования и мониторинга рисков, связанных с требованиями. Общий реестр проекта (бюджет, контракты, ресурсы команды) ведёт PM или риск-менеджер проекта (risk owner на стороне PMO); реестр рисков анализа может существовать отдельно или как раздел в общем реестре. На практике работают оба варианта:
| Модель | Когда уместна |
|---|---|
| Единый реестр | Крупный проект с формальным PMO; риски анализа помечаются категорией «Requirements / BA» |
| Два реестра с синхронизацией | Agile-команда: аналитик ведёт свой список, на ритуале (раз в спринт) эскалирует риски с рейтингом выше порога в проектный реестр |
При модели «два реестра» нужен минимальный контракт синхронизации — иначе BA-реестр остаётся декларацией:
| Элемент контракта | Содержание |
|---|---|
| Обязательные совпадающие поля | ID (или cross-ref), описание, категория, P/I, рейтинг, owner, статус, дата пересмотра |
| Порог эскалации | Рейтинг ≥ порога проекта (например, 12 из 25) или категория «регуляторика / safety» — в проектный реестр в течение одного спринта |
| Кто эскалирует | Owner риска (BA/SA) на refinement или risk review; PM подтверждает приём |
| Если PM не забирает риск | Фиксируется в протоколе; BA эскалирует sponsor / steering с обоснованием «unmitigated high risk»; риск остаётся открытым в BA-реестре с пометкой «Escalated — pending PM acceptance» |
Владение (RACI в упрощённом виде):
| Роль | Ответственность |
|---|---|
| BA/SA (owner риска анализа) | Идентификация, описание, план реагирования через артефакты требований, мониторинг триггеров |
| PM | Интеграция в общий реестр, эскалация на steering, резервы и контрактные меры |
| Команда разработки/QA | Подтверждение технической реализуемости, предложение мер снижения |
| CCB | Решения по изменениям, порождённым материализовавшимся риском (02.05.02 Управление изменениями (Change Control Board)) |
Свод 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) относит управление рисками к задачам аналитика: техника Risk Analysis and Management (BABOK 10.38) и задача Assess Risks в Strategy Analysis (6.3). ISO/IEC/IEEE 29148 задаёт атрибут Risk на уровне отдельного требования — согласованность реестра с этим атрибутом упрощает трассировку от риска к спецификации.
Зачем это аналитику на проекте:
- Раннее обнаружение — дефект в требованиях, найденный после релиза, обходится значительно дороже, чем на этапе анализа.
- Защита бизнес-ценности — проработанные требования снижают вероятность ненужной или некачественной функциональности.
- Прозрачность для стейкхолдеров — реестр делает явными скрытые угрозы и помогает 09.07 Управление ожиданиями заказчика.
- Обоснование ресурсов — критические риски аргументируют время на прототипирование, исследования или формальные инспекции.
2. Ключевые понятия
2.1. Риск, рейтинг, остаточный риск
- Риск — описанная неопределённость: «что может случиться» и «к чему приведёт» для целей проекта.
- Рейтинг = Вероятность × Воздействие (качественная шкала, например 1–5 × 1–5). Порог «высокий приоритет» (например, ≥12 из 25) настраивается политикой проекта, а не является универсальной константой.
- Остаточный риск (residual risk) — уровень неопределённости после применения мер. В реестре фиксируют: исходные P/I, целевые P/I после митигации, принятый residual, кто принял решение и дату.
Governance принятия остаточного риска (типовая матрица — уточняется политикой проекта):
| Residual rating | Кто принимает | Что фиксируется в реестре |
|---|---|---|
| Низкий (например, ≤6) | Owner риска (BA/SA) | Residual P/I, обоснование, план мониторинга |
| Средний (7–11) | BA/SA + согласование PM | То же + ссылка на протокол согласования |
| Высокий (≥12) | Sponsor / steering committee | Явная запись «Accepted by [роль, ФИО, дата]»; без неё риск считается незакрытым |
2.2. Риск, issue и материализация
| Статус | Что это | Куда попадает | Кто фиксирует |
|---|---|---|---|
| Риск | Ещё не случилось, но может | Реестр рисков (Open / Monitoring) | Owner риска (BA/SA) |
| Материализовавшийся риск | Событие наступило | Риск закрывается с причиной «Realized»; создаётся issue | BA/SA + PM |
| Issue | Активная проблема, требующая решения | Issue tracker, change request, backlog impediment | По типу: CR → CCB; дефект требований → rework; блокер спринта → Scrum Master / PO |
Без этого различения цикл мониторинга обрывается: команда продолжает «мониторить» уже свершившееся событие вместо управления последствиями.
2.3. Угрозы и возможности (positive risks)
ISO 31000 и практика PM включают возможности — неопределённости с положительным эффектом. В BABOK «opportunities» чаще оформляют как потребности и гипотезы ценности; в реестре аналитика полезно явно помечать:
- Угроза: «Критерии приёмки для поиска останутся неоднозначными → rework на тестировании».
- Возможность: «Раннее прототипирование выявит переиспользуемый API платёжного модуля → сокращение интеграционных работ».
Стратегии для возможностей: усиление (exploit), разделение (share), принятие с мониторингом — зеркально угрозам (см. §3.3).
2.4. Категории рисков, релевантных аналитику
Таблица ниже — таксономия для реестра, а не второй независимый список проблем. Категория «риски требований» — это view над дефектами качества из 02.04.03 Управление качеством требований: ambiguous, incomplete, untestable становятся строками реестра, когда их последствия значимы для проекта.
| Категория риска | Описание и примеры | Связанные разделы |
|---|---|---|
| Риски требований | Неполнота, неоднозначность, противоречивость, нестабильность, «золотое покрытие» | 02.04.03 Управление качеством требований — метрики качества как индикаторы |
| Риски зависимостей | Блокировки по цепочке требований, внешние команды, неготовый контракт API | 02.05.01 Управление зависимостями между требованиями, 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) |
| Риски процесса анализа | Недостаток компетенций, слабая коммуникация, неэффективные техники выявления | 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии |
| Риски заинтересованных сторон | Конфликт интересов, недоступность ключевых лиц, скрытые потребности | 02.01.03 Анализ заинтересованных сторон (Stakeholder Map) |
| Риски предметной области | Сложность бизнес-правил, регуляторные изменения | 02.01.01 Определение бизнес-проблем и возможностей |
| Технические риски | Legacy, незрелость технологий, проблемы интеграции | 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая), 03.01.04 Интерфейсы и интеграционные взаимодействия |
| Риски безопасности и комплаенса | Несоответствие стандартам (GDPR, PCI DSS), уязвимости в дизайне | 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 08.06 Юридические и регуляторные требования РФ (PCI-DSS), 08.07 Основы кибербезопасности для системного аналитика |
3. Как применяется в работе аналитика
Управление рисками — циклический процесс, встроенный в повседневную работу с требованиями и привязанный к 02.05.05 Жизненный цикл требования и 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC).
Точки пересмотра риска по статусу требования:
| Переход статуса | Типичный триггер пересмотра |
|---|---|
| Draft → Review | Новые риски из рецензирования; уточнение P/I |
| Review → Approved | Residual после мер снижения; связь с baseline |
| Approved → Implemented | Закрытие рисков, закрытых реализацией; новые технические риски из интеграции |
| Любой → Changed (CR) | Новый или пересчитанный риск от изменения scope |
graph TD
A[Идентификация рисков] --> B[Анализ и оценка]
B --> C[Планирование реагирования]
C --> D[Мониторинг и контроль]
D --> E{Новые риски или изменения?}
E -- Да --> A
E -- Нет --> D
D --> F{Риск материализовался?}
F -- Да --> G[Issue / CR / дефект]
G --> D
3.1. Идентификация рисков
Цель — составить список потенциальных угроз и возможностей, связанных с требованиями и процессом их разработки.
Источники:
- Документация: Vision&Scope, BRD, протоколы, обратная связь (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)).
- Чеклисты: 10.04 Чеклист аналитика перед стартом разработки как триггер систематической проверки.
- Допущения и ограничения: явные и неявные предположения (01.07 Когнитивные искажения и критическое мышление помогает выявить неосознанные допущения).
- Зависимости: матрица блокировок между командами и внешними системами (02.05.01 Управление зависимостями между требованиями).
- Модели: BPMN, DFD, ER — вскрывают логические разрывы (03.04.01 BPMN 2.0 - введение и основы, 03.03.01 ER-диаграммы (сущность-связь)).
- Стейкхолдеры: интервью, воркшопы (02.02.01 Интервьюирование и анкетирование).
- Исторические данные: ретроспективы, баги похожих проектов.
Техники (по уровню формализации):
| Уровень | Техники | Когда достаточно |
|---|---|---|
| Базовый | Мозговой штурм (02.02.05 Мозговой штурм и креативные техники), анализ допущений, чеклисты | Большинство продуктовых и корпоративных проектов |
| Обзорный | SWOT, диаграмма Исикавы — см. 01.03 Техники анализа проблем | Нужна структура для workshop с бизнесом |
| Формальный | HAZOP, FMEA — см. 04.04 Техника HAZOP и FMEA для анализа рисков | Только при safety-critical, regulated (медицина, авиация, финансы с жёстким аудитом) или когда политика проекта требует FMEA для компонента |
Пример: допущение «интеграция с платёжным шлюзом по REST, спецификация стабильна» → риск «спецификация изменится до релиза, потребует переработки модуля оплаты».
3.2. Анализ и оценка
Уровень 1 — качественная оценка (обязательный минимум). Каждый риск получает P и I по согласованным шкалам. Этого достаточно для Agile-команд, внутренних продуктов и проектов без формального PMO.
Уровень 2 — количественная оценка (опционально). Применяют, когда нужно сравнить риски в деньгах или person-days, обосновать резерв или выбор между альтернативами. Метод: ожидаемая стоимость (Expected Monetary Value, EMV) = P × Impact в деньгах или спринтах.
Пример EMV: риск «переработка модуля отчётности из-за изменения законодательства» — P=30 % (шкала 3), impact=8 person-weeks (≈400 000 ₽ по ставке команды) → EMV ≈120 000 ₽. Сравнивают с стоимостью меры: юридическая экспертиза за 50 000 ₽ снижает P до 10 % → EMV после меры ≈40 000 ₽.
Когда количественная оценка не обязательна: нет надёжных данных о стоимости, малый проект, риски однородны по порядку величины — достаточно качественного рейтинга и ранжирования.
Шкала вероятности (пример):
| Балл | Ориентир |
|---|---|
| 1 | Очень низкая (<10 %) |
| 2 | Низкая (10–30 %) |
| 3 | Средняя (30–50 %) |
| 4 | Высокая (50–70 %) |
| 5 | Очень высокая (>70 %) |
Шкала воздействия — привязка к артефактам анализа (пример):
| Балл | Воздействие на проект | Пример для аналитика |
|---|---|---|
| 1 | Задержка <0,5 спринта, локальный rework | Уточнение формулировки одной user story |
| 2 | Rework 1–3 story в спринте | Неоднозначность AC одной фичи |
| 3 | Срыв цели спринта или milestone на 1–2 недели | Блокер интеграции с внешней системой |
| 4 | Срыв release milestone, пересмотр scope эпика | Нестабильный API контрагента без fallback |
| 5 | Критический: регуляторный штраф, остановка релиза, safety incident | Несоответствие PCI DSS в платёжном потоке |
Единые якоря impact снижают расхождение оценок между owners.
Когнитивные ловушки при оценке (01.07 Когнитивные искажения и критическое мышление): anchoring на первой цифре в workshop, optimism bias («у нас не случится»), групповое согласие без dissenting opinion. Практика: независимая «слепая» оценка до обсуждения; для high-risk — второй reviewer.
| Риск | Вер. | Возд. | Рейтинг | Приоритет |
|---|---|---|---|---|
| Изменение законодательства → переработка модуля отчётности | 3 | 5 | 15 | Высокий |
| Ключевой эксперт недоступен для согласования макетов | 4 | 3 | 12 | Высокий |
| Неоднозначность критериев приёмки для поиска | 3 | 2 | 6 | Средний |
3.3. Планирование реагирования
Угрозы:
| Стратегия | Суть | Пример для аналитика | Что фиксирует BA в реестре |
|---|---|---|---|
| Избегание | Устранить источник | Исключить нестабильный API до прояснения контракта | «Scope exclusion: API X до v2 spec approved» |
| Передача | Перенести ответственность | BA: «need legal review», «dependency on vendor SLA v1.2»; PM: страхование, контрактные штрафы, outsource | Запись need + owner на стороне PM/legal; BA не описывает страховые продукты |
| Снижение | Уменьшить P или I | Прототип, рецензирование, NFR, spike, ADR | Конкретные артефакты и ссылки |
| Принятие | Осознанно оставить с contingency | Резерв времени; план действий при наступлении | Residual + кто принял (§2.1) |
Возможности:
| Стратегия | Суть | Пример для аналитика |
|---|---|---|
| Усиление (exploit) | Максимально использовать | Ранний spike подтвердил переиспользуемый модуль → включить в MVP первым, зафиксировать в 10.01.13 Шаблон архитектурного решения (ADR) |
| Разделение (share) | Разделить выгоду с партнёром | Совместный PoC с вендором: BA описывает гипотезу и критерии успеха spike |
| Принятие | Не инвестировать активно, мониторить | «Возможность ускорения через low-code — отложена; триггер: задержка >2 спринтов» |
Действия аналитика при снижении технических рисков:
- Spike / PoC — проверка гипотезы до фиксации контракта.
- ADR — 10.01.13 Шаблон архитектурного решения (ADR) для архитектурных развилок с высоким residual.
- Контракт API — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) до начала параллельной разработки.
- Уточнение требований — 02.03.03 Спецификация требований (SRS, Use Case, User Story).
- Прототипирование — 02.02.04 Прототипирование и UI-UX-исследования.
- Рецензирование — 08.03 Тестирование требований (статическое тестирование), 08.04 Рецензирование и инспекции (техники Фейгана).
- Трассировка — 02.03.04 Трассировка требований (концепция), шаблон 10.01.15 Шаблон матрицы трассировки.
- MVP / пилот — ограничение воздействия.
После мер пересчитывают остаточный риск и фиксируют в реестре: «было 5×4=20 → после NFR и AC: 3×3=9; residual принят PM 2026-03-15».
3.4. Мониторинг и контроль
- Регулярный пересмотр — на плановых встречах или раз в спринт (05.02 Scrum и Kanban (аналитик в Agile): риски в Definition of Ready, refinement, impediments).
- Триггеры — индикаторы приближения материализации («эксперт трижды перенёс встречу» → повысить вероятность).
- Актуализация P/I по мере уточнения требований и архитектуры.
- Закрытие — риск неактуален; материализация — закрыть с Realized, завести issue/CR.
- Связь с изменениями — 02.05.02 Управление изменениями (Change Control Board); каждый CR может породить новый риск.
KPI процесса (согласование с 08.01 Метрики и KPI процесса анализа):
| Метрика | Зачем |
|---|---|
| Число открытых high risks (rating ≥ порога) | Нагрузка на команду и эскалации |
| Aging открытых рисков (дней без пересмотра) | «Забытые» риски |
| Доля рисков с пересчитанным residual после мер | Качество митигации, не checkbox |
| Материализации за период vs прогноз | Калибровка шкал P/I |
Интеграция с соседними процессами:
- Elicitation и анализ стейкхолдеров идут параллельно с идентификацией рисков.
- Приоритизация: требование, смягчающее критический риск, получает Must Have — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).
- V&V: глубина проверок зависит от рейтинга — 02.04.01 Верификация и валидация (V&V).
- Scope: 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.
3.5. Инструменты документирования
Реестр рисков (Risk Register) — минимальный набор полей для аналитика:
- ID, категория, описание (угроза / возможность).
- Вероятность, воздействие, рейтинг; остаточный рейтинг после мер.
- Триггеры (индикаторы), стратегия, конкретные действия.
- Owner, статус, дата последнего пересмотра.
- Accepted by (роль, дата) — для residual выше порога owner.
- Связь с требованиями / user story / NFR (ID или ссылка).
- При материализации: ссылка на issue / CR.
Поля можно вести в Google Sheets, Confluence или Jira; для трассировки риск ↔ требование удобен шаблон 10.01.15 Шаблон матрицы трассировки с дополнительной колонкой «Risk ID».
Тепловая карта (Heat Map) — визуализация матрицы P×I для обсуждения с руководством. Достаточна для большинства рисков.
Диаграмма «галстук-бабочка» (Bow-tie) — когда строки реестра недостаточно:
| Критерий | Пример |
|---|---|
| Rating ≥ порога «критический» после митигации | Residual ≥12 |
| Safety, regulated domain, audit trail | PCI, медицинские данные |
| Множественные причины и барьеры | Цепочка: внешний API → кэш → UI → регулятор |
| Нужна коммуникация с steering / compliance | Единая картина «причины — событие — последствия — барьеры» |
В простых командах — Google Sheets или Confluence; в масштабных — Jira с плагинами риск-менеджмента; bow-tie — Lucidchart / Miro.
3.6. Пример: риск нестабильной сети в мобильном приложении
Контекст: приложение доставки; требование — отслеживание геопозиции курьера в реальном времени.
Идентификация: при слабом мобильном интернете координаты поступают с задержкой → негатив пользователей.
Анализ: P=4, I=5 (срыв release milestone, эскалации от бизнеса) → рейтинг 20 (критический).
Реагирование (снижение):
- NFR: при потере связи приложение кэширует координаты и отправляет накопленные данные при восстановлении (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).
- Критерий приёмки (02.04.02 Критерии приёмки (Acceptance Criteria)): «пользователь видит метку времени последнего известного местоположения и индикатор актуальности».
- Требование к тестированию: сценарии деградированной сети и offline-режима (не нагрузочное тестирование) — эмуляция нестабильного соединения, проверка кэширования и синхронизации.
Остаточный риск: P=3, I=3 → рейтинг 9 (средний). Принятие: BA/SA согласовал с PM на sprint review 2026-03-10; в реестре: «Accepted by PM, monitoring on integration stands until release». Без записи «Accepted by» риск остаётся в статусе «Mitigation in progress».
4. Типовые ошибки и ограничения
- Путать риск с рейтингом — в реестре «риск = 15» вместо описания события и отдельного score.
- Не переводить материализовавшийся риск в issue — реестр раздувается, последствия не управляются.
- Вести реестр изолированно от PM — критические риски не получают резервов и эскалации.
- Принимать высокий residual без governance — «принят с мониторингом» без роли и даты не считается решением.
- Только угрозы, без возможностей — упускается раннее прототипирование, переиспользование, ускорение поставки.
- Не пересчитывать residual risk — команда считает меры выполненными, хотя P/I не изменились.
- Применять HAZOP/FMEA вне regulated/safety контекста — формальные методы описаны в 04.04 Техника HAZOP и FMEA для анализа рисков; для обычного продукта достаточно реестра и чеклистов.
- Дублировать inventory качества требований — категория «риски требований» дополняет 02.04.03 Управление качеством требований, а не заменяет его.
- Комплаенс сводить к NFR — юридические и регуляторные риски требуют отдельного процесса (08.06 Юридические и регуляторные требования РФ (PCI-DSS)).
- Игнорировать Agile-ритм и lifecycle — без привязки к DoR/refinement и переходам статуса требования риски всплывают в середине спринта (05.02 Scrum и Kanban (аналитик в Agile), 02.05.05 Жизненный цикл требования).
- Неверный тип теста в мерах — нагрузочное тестирование не заменяет проверку устойчивости к обрыву связи.
- Anchoring и groupthink при оценке P/I — см. 01.07 Когнитивные искажения и критическое мышление.
Связи с другими разделами базы
Ссылки ниже — на разделы, которые задают контекст процесса, но не разобраны подробно в тексте:
- 08.01 Метрики и KPI процесса анализа — KPI реестра рисков и aging.
- 02.05.01 Управление зависимостями между требованиями — типовой источник technical/requirements рисков.
- 02.05.05 Жизненный цикл требования — точки пересмотра риска по статусам.
- 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC) — встраивание цикла рисков в SDLC.
- 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) — снижение integration risk до разработки.
- 10.01.13 Шаблон архитектурного решения (ADR) — фиксация архитектурных мер и spike-результатов.
Источники и дополнительные материалы
Стандарты и руководства
- ISO 31000:2018 «Risk management — Guidelines» — https://www.iso.org/standard/65694.html
- ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle processes — Requirements engineering» — атрибут Risk на уровне требования; https://www.iso.org/standard/72089.html
- IIBA BABOK v3 — техника Risk Analysis and Management (10.38): https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/10-techniques/10-38-risk-analysis-and-management/
- IIBA BABOK v3 — задача Assess Risks (6.3): https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/6-strategy-analysis/6-3-assess-risks/
- PMI PMBOK Guide — процессы управления рисками проекта; адаптируются к анализу требований как контекст, не замена BA-реестра.
Книги
- Karl Wiegers, Joy Beatty. «Software Requirements» (3rd ed.) — главы о рисках требований.
- Suzanne Robertson, James Robertson. «Mastering the Requirements Process» — раздел «Риски и требования».
- Tom DeMarco, Timothy Lister. «Waltzing with Bears» — классика риск-менеджмента в разработке ПО.
Инструменты (практика документирования)
- Jira: плагины Risk Register, Advanced Roadmaps.
- Confluence: шаблон Risk Register.
- Lucidchart / Miro: тепловые карты и bow-tie.