Любая инициатива живёт среди людей и групп, чьи интересы могут продвинуть или заблокировать изменения. Анализ заинтересованных сторон (Stakeholder Analysis) отвечает на три вопроса: кто влияет на решение, чего они хотят и как с ними работать. Карта стейкхолдеров (Stakeholder Map) — один из артефактов этого анализа, обычно на основе сетки «власть — интерес». Без реестра и плана вовлечения даже точные цели и требования рискуют быть отвергнуты при внедрении.
1. Суть темы
В BABOK v3 работа со стейкхолдерами разнесена по двум областям знаний (см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)):
- Strategy Analysis — идентификация и анализ заинтересованных сторон в контексте изменения: кто затронут, каковы интересы и влияние. Это логичный шаг трека 02.01.01 Определение бизнес-проблем и возможностей → 02.01.02 Цели, KPI и критерии успеха (SMART, GQM) → текущая статья.
- Business Analysis Planning and Monitoring — задача Plan Stakeholder Engagement: как поддерживать рабочие отношения на протяжении инициативы, пересматривать план и фиксировать уровни вовлечения.
ISO/IEC/IEEE 29148 называет stakeholder requirements — потребности и ограничения сторон, которые должны быть отражены в решении; реестр и карта помогают не потерять их при переходе к 02.03.01 Классификация требований (БТ, ФТ, НФТ).
Это этап до и вокруг выявления требований: вы фиксируете, с кем и как работать, а методы интервью и воркшопов — в 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии.
Процесс итеративен: Identify → Analyze → Plan Engagement. На выходе — реестр стейкхолдеров (Stakeholder Register), карта и план коммуникаций. Реестр живёт на протяжении инициативы; карта — снимок для приоритизации на конкретной фазе (discovery, проектирование, cutover), который пересматривают на вехах или в начале спринта (см. 05.02 Scrum и Kanban (аналитик в Agile)). Влияние стейкхолдеров на границы решения — отдельная тема: 02.01.04 Определение границ решения (Scope Modelling).
flowchart LR
A[Identify] --> B[Analyze]
B --> C[Plan Engagement]
C --> D[Реестр + карта + план коммуникаций]
D --> E[Выявление требований]
E -.->|новые лица, смена влияния| A
2. Ключевые понятия
Определение и категории
Определение (BABOK v3): заинтересованная сторона — человек, группа или организация, имеющая отношение к изменению, потребность, ожидания или влияние на проект и его результат.
Базовые категории:
- Внутренние / внешние: сотрудники / клиенты, партнёры, регуляторы.
- Прямые / косвенные: взаимодействуют с решением / затронуты опосредованно.
- По роли в инициативе: спонсор, владелец продукта, пользователи, эксперты предметной области, команда, регуляторы.
| Категория | Примеры | Вопросы для идентификации |
|---|---|---|
| Спонсоры | Исполнительный спонсор, владелец бюджета | Кто финансирует? Кто может отменить? |
| Пользователи | Конечные и опытные пользователи, администраторы | Кто ежедневно использует решение? |
| Операторы | IT-операции, поддержка | Кто сопровождает систему после запуска? |
| Регуляторы | Комплаенс, юристы, аудит | Кто следит за соблюдением правил? |
| Затронутые стороны | Смежные отделы | Кого коснутся изменения? |
| Эксперты предметной области | SME, технические лидеры | У кого критическая информация? |
| Лица, принимающие решения | Комитет, архитекторы | Кто утверждает решения? |
| Влиятельные лица | Лидеры мнений, профсоюзы | Кто формирует восприятие? |
Косвенные стейкхолдеры вроде конкурентов попадают в реестр, если их реакция на рынок или регуляторику влияет на сроки, scope или допустимость решения — не как «участники проекта», а как фактор риска для инициативы.
Стейкхолдер vs роль в системе
Стейкхолдер — субъект с интересом к изменению (человек, группа, организация). Роль в системе — функция в модели решения: актор на диаграмме прецедентов, роль в IAM, участник BPMN-процесса. Один человек может быть и стейкхолдером, и носителем роли, но это разные срезы: «директор по продажам» как стейкхолдер (бюджет, одобрение) и как роль «Утверждающий скидку» в use case.
Внешний актор на контекстной диаграмме (клиентский API, платёжный шлюз) — граница системы, а не запись в реестре стейкхолдеров изменения: владелец интеграции или комплаенс-офицер, отвечающий за договор с провайдером, — стейкхолдер; сам шлюз — нет. См. 03.01.02 Моделирование контекста системы (Context Diagram) и 03.02.01 Диаграмма прецедентов (Use Case Diagram).
Путаница приводит к пропуску скрытых ЛПР и к «лишним» акторам в модели. Ролевая модель IAM — 10.01.11 Шаблон ролевой модели.
Спонсор vs Product Owner
| Роль | Фокус | Типичные полномочия |
|---|---|---|
| Исполнительный спонсор (Executive Sponsor) | Обоснование инвестиций, защита инициативы | Бюджет, отмена проекта, эскалация |
| Product Owner (Scrum) | Ценность продукта в рамках продукта | Приоритет backlog, приёмка инкремента |
В Agile PO ≠ executive sponsor: PO не заменяет спонсора с бюджетом и полномочиями отменить программу. В реестре фиксируйте обе роли отдельно, если они у разных людей.
Характеристики для анализа
Для каждого стейкхолдера в реестре:
- Интерес (Interest): насколько важен исход для этой инициативы.
- Влияние (Power/Influence): способность повлиять на решения, ресурсы, блокировки.
- Отношение (Attitude): поддерживает, нейтрален, сопротивляется, не осведомлён.
- Ожидания и ограничения: что ждёт, что не устраивает сейчас.
- Представитель группы (representative of): какой сегмент или роль охватывает; с кем валидировать требования (validates with).
- Связь с требованиями: как решения стейкхолдера влияют на scope и приоритеты → 02.03.04 Трассировка требований (концепция).
Шкала High / Medium / Low субъективна. Якоря на проекте:
- Высокая власть: может остановить инициативу или выделить/отозвать бюджет (спонсор, CEO, регулятор с мандатом).
- Средняя: влияет на часть scope или ресурсов команды (руководитель подразделения, PO).
- Низкая: редко блокирует, но может давать экспертизу или создавать шум (отдельный пользователь без мандата).
Интерес оценивайте в контексте инициативы, а не должности в целом: CPO может иметь низкий интерес к внутреннему ETL-проекту. Оценки фиксируйте в беседах и проверяйте у нескольких источников — см. 02.02.01 Интервьюирование и анкетирование, 09.01 Техники активного слушания и опросов. Не полагайтесь на догадки команды — субъективность оценок типична; см. 01.07 Когнитивные искажения и критическое мышление.
Модели классификации: когда какую
| Модель | Оси | Когда использовать |
|---|---|---|
| Power / Interest (карта стейкхолдеров) | Власть × интерес | Старт инициативы, быстрый выбор стратегии вовлечения |
| Influence / Attitude | Влияние × отношение | Много сопротивления; нужно видеть, кого «переводить» в поддержку |
| Salience (BABOK) | Power, legitimacy, urgency | Сложное окружение: много групп с пересекающимися претензиями |
| Уровень вовлечения (engagement) | Unaware → Leading | Детализация плана после квадранта карты |
Стратегии по Power/Interest (BABOK / Mendelow):
| Квадрант | Власть | Интерес | Стратегия |
|---|---|---|---|
| Manage Closely | Высокая | Высокий | Постоянное вовлечение, совместные решения |
| Keep Satisfied | Высокая | Низкий | Ключевые решения и одобрения без перегруза деталями |
| Keep Informed | Низкая | Высокий | Регулярные обновления, сбор обратной связи |
| Monitor | Низкая | Низкий | Минимальные усилия, периодический пересмотр |
Уровни вовлечения (BABOK): unaware → resistant → neutral → supportive → leading. Уровень фиксируют в реестре и планируют переход (например, resistant → neutral через воркшоп с разбором рисков).
Salience (Mitchell et al., в BABOK — definitive stakeholder): стейххолдер «выступает» на передний план, когда сочетание власти, легитимности и срочности делает его критичным для инициативы. Упрощённое правило «силён по двум из трёх» годится только для грубой приоритизации на воркшопе — не как механический счёт. Используйте модель, когда на карте Power/Interest слишком много точек в «Manage Closely» и нужна более тонкая градация.
3. Как применяется в работе аналитика
3.1 Идентификация (Identify)
Прямой вход из трека 02.01: лица, уже фигурировавшие при формулировке проблемы (02.01.01 Определение бизнес-проблем и возможностей) и целей (02.01.02 Цели, KPI и критерии успеха (SMART, GQM)), — спонсор, владелец метрики, пострадавшие подразделения. Их не нужно «открывать заново»: перенесите в реестр и дополните.
Дополнительные источники: устав, бизнес-кейс, Vision & Scope — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD); оргструктура; интервью «кого ещё подключить?»; мозговой штурм — 02.02.05 Мозговой штурм и креативные техники; роли в AS-IS процессах и системах — 02.02.03 Наблюдение и анализ документов.
Реестр обычно содержит: ID, имя/роль, категорию, организацию, контакты, оценки interest/power/attitude, уровень engagement, стратегию, частоту коммуникаций, representative of / validates with, примечания (бюджетные полномочия; «реальный ЛПР» vs формальный).
Готового шаблона реестра в разделе артефактов 10.01 нет: оформляйте таблицей в Confluence, Excel или инструменте управления требованиями — см. 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence).
3.2 Анализ и план вовлечения
- Заполните оценки в реестре (с обоснованием в примечаниях).
- Постройте карту Power/Interest для приоритизации на текущей фазе.
- Назначьте стратегию и целевой уровень engagement каждой группе.
- Свяжите группу с методом elicitation и типом touchpoint (см. таблицу ниже).
План коммуникаций vs engagement: коммуникация — что и когда сообщаем (статус, решение, приглашение на воркшоп); engagement — цель смены отношения (например, resistant → neutral). Оба поля живут в реестре.
| Стратегия (Power/Interest) | Тип touchpoint | Цель engagement |
|---|---|---|
| Manage Closely | Совместные решения, стратегические интервью | leading / supportive |
| Keep Satisfied | Краткий статус перед ключевым решением, одобрение | neutral → supportive |
| Keep Informed | Регулярный digest, демо, UAT | unaware → neutral |
| Monitor | Периодический ping, подключение по триггеру | поддержать осведомлённость |
При конфликтующих целях стейкхолдеров не выбирайте «победителя» молча: эскалируйте trade-off спонсору, используйте приоритизацию — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) — и переговоры — 09.03 Управление конфликтами и переговоры.
3.3 Карта стейкхолдеров (Stakeholder Map)
Координаты зависят от фазы. Одна и та же группа смещается по осям: IT Operations на discovery часто в Monitor (низкий интерес, низкая власть к scope); перед cutover интерес растёт (NFR, runbooks, on-call) — группа переходит в Keep Informed или Manage Closely. Фиксируйте в реестре фазу снимка и дату пересмотра.
Оси диаграммы ниже — фаза discovery: X = Interest (слева низкий → справа высокий), Y = Power (снизу низкая → сверху высокая). Координаты [x, y] = [interest, power]. Смысл квадрантов продублирован таблицей — не все среды одинаково рендерят quadrantChart в Mermaid.
quadrantChart
title Stakeholder Map (Power vs Interest) — фаза discovery
x-axis Low Interest --> High Interest
y-axis Low Power --> High Power
quadrant-1 "Manage Closely"
quadrant-2 "Keep Satisfied"
quadrant-3 "Monitor"
quadrant-4 "Keep Informed"
"Sponsor": [0.85, 0.95]
"Product Owner": [0.8, 0.75]
"End Users": [0.9, 0.25]
"IT Operations": [0.15, 0.2]
"Department Head": [0.25, 0.9]
| Точка | Interest | Power | Квадрант | Стратегия |
|---|---|---|---|---|
| Sponsor | Высокий | Высокая | Manage Closely | Регулярные решения, защита scope |
| Product Owner | Высокий | Средняя–высокая | Manage Closely / Keep Satisfied | Согласование backlog и приоритетов |
| End Users | Высокий | Низкая | Keep Informed | Интервью, прототипы, UAT |
| Department Head | Низкий | Высокая | Keep Satisfied | Одобрения, без операционных деталей |
| IT Operations | Низкий | Низкая | Monitor (discovery) | Подключать до cutover и NFR |
В PMBOK подписи квадрантов могут отличаться; проверяйте, какая ось где нарисована, прежде чем читать чужую карту.
3.4 Карта Influence / Attitude
Когда важнее отношение к изменению, чем интерес к деталям scope, используйте вторую ось. X = Attitude (слева сопротивление → справа поддержка), Y = Influence (снизу низкое → сверху высокое).
| Квадрант | Влияние | Отношение | Стратегия |
|---|---|---|---|
| Win Over | Высокое | Сопротивление / нейтралитет | 1:1, разбор страхов, демонстрация выгод, поиск союзников |
| Leverage Allies | Высокое | Поддержка | Делегировать продвижение изменений, использовать как champion |
| Show Consideration | Низкое | Поддержка | Благодарность, вовлечение в пилоты и обратную связь |
| Monitor | Низкое | Сопротивление | Не перегружать; следить, не слилось ли с влиятельным блоком |
Пример: руководитель смежного департамента с высоким влиянием и resistant attitude попадает в Win Over — отдельный план до общего воркшопа по требованиям.
3.5 Другие артефакты
RACI для утверждения требований — не полная матрица процессов организации, а фиксация «кто A/R на ключевой активности». На малом продукте, где PO совмещён со спонсором, достаточно реестра и устных договорённостей — отдельная RACI избыточна. На enterprise-инициативе с несколькими accountable за scope, sign-off и бюджет RACI по ключевым активностям обязательна.
Пример для активности «Согласование scope требований»:
| Активность | Спонсор | BA | PO | Команда разработки |
|---|---|---|---|---|
| Согласование scope требований | A | R | C | I |
A — accountable (принимает итог), R — responsible (готовит), C — consulted, I — informed.
Персоны (Personas) — обобщённый образ группы пользователей для эмпатии и UX; дополняют реестр, но не несут power/interest и не заменяют запись о конкретном стейкхолдере (например, Department Head в квадранте Keep Satisfied). Методы: 02.02.04 Прототипирование и UI-UX-исследования.
4. Типовые ошибки и ограничения
- Невидимые стейкхолдеры: поддержка, ИБ, юристы, аудит — блокировка на финале. Действие: проход по регламентам согласования и 10.04 Чеклист аналитика перед стартом разработки.
- «Реальный ЛПР» vs формальный: на enterprise-проектах решения принимает не тот, кто указан в уставе. Действие: уточнять «кто фактически подпишет» и «кто может заблокировать».
- Громкий голос = вся группа: один активный пользователь ≠ все пользователи. Действие: поле representative of и валидация у нескольких представителей сегмента.
- Игнор сопротивления: часто это страх потери роли, а не «враги проекта». Действие: карта Influence/Attitude и 09.07 Управление ожиданиями заказчика.
- Статичная карта: координаты без привязки к фазе; новые игроки после реорганизации. Действие: пересмотр на вехах; реестр — living document в 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence).
- Конфликт целей и scope creep через стейкхолдеров: см. §3.2 — эскалация trade-off, 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.
- Путаница PO и спонсора: ожидание от PO полномочий по бюджету. Действие: раздельные записи в реестре и RACI.
Связи с другими разделами базы
- Когнитивные ловушки при субъективных оценках H/M/L: 01.07 Когнитивные искажения и критическое мышление
- Актор на контекстной диаграмме vs стейкхолдер изменения: 03.01.02 Моделирование контекста системы (Context Diagram)
- Living register и хранение артефакта: 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)
- Проверка готовности к разработке (пункт про стейкхолдеров и RACI): 10.04 Чеклист аналитика перед стартом разработки
- Риски от пропущенных или враждебных сторон: 08.05 Управление рисками на этапе анализа
Источники и дополнительные материалы
Книги и стандарты
- IIBA (2015). BABOK® Guide v3. Главы 2.2 «Stakeholders», 3.2 «Plan Stakeholder Engagement», техники Stakeholder List, Map, Personas; модель Salience и уровни engagement. https://www.iiba.org/standards-and-resources/babok/
- ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering — раздел stakeholder requirements. https://www.iso.org/standard/72089.html
- PMI (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 7th ed., домен Stakeholders и сетка power/interest. https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
- Mitchell, R. K., Agle, B. R., Wood, D. J. «Toward a Theory of Stakeholder Identification and Salience» — классическая модель salience (power, legitimacy, urgency).
- Thompson, R. Stakeholder Analysis: Winning Support for Your Projects — практическое руководство по идентификации и плану вовлечения.
Статьи и онлайн-ресурсы
- MindTools. «Stakeholder Analysis» — Power/Interest Grid. https://www.mindtools.com/aol0rms/stakeholder-analysis/
- Open Practice Library. Stakeholder Map — https://openpracticelibrary.com/practice/stakeholder-map/
- Open Practice Library. Stakeholder RACI Map — https://openpracticelibrary.com/practice/stakeholder-raci-map/
- Bridging the Gap (Laura Brandenburg). Материалы по stakeholder analysis для BA — https://www.youtube.com/@BridgingTheGap
- Шаблоны: Stakeholder Map и RACI в Miro, Mural, Confluence (community templates).