Идентификация и классификация стейкхолдеров

Урок 1 из 4

Урок 02.01: Идентификация и классификация стейкхолдеров

Цель урока

Научится системно выявлять всех стейкхолдеров проекта, классифицировать их (внутренние / внешние / скрытые) и применять на практике две ключевые матрицы управления — матрицу Менделоу (Власть / Интерес) и матрицу RACI — для планирования коммуникаций и распределения ответственности.

Ключевые понятия

  • Стейкхолдер (Stakeholder) — любое лицо, группа или организация, которая может влиять на проект, быть затронутой проектом или ощущать на себе его влияние (PMBOK Guide)
  • Внутренние стейкхолдеры — участники внутри команды и организации-исполнителя
  • Внешние стейкхолдеры — лица и организации за пределами команды проекта, но влияющие на него
  • Скрытые стейкхолдеры — стейкхолдеры, которых не видно на старте, но они могут существенно повлиять на проект
  • Матрица Менделоу (Mendelow's Matrix / Power-Interest Grid) — инструмент классификации стейкхолдеров по двум осям: уровень власти и уровень интереса к проекту
  • RACI-матрица — инструмент распределения ролей и ответственности: Responsible (Исполняет), Accountable (Отвечает), Consulted (Консультирует), Informed (Информируется)
  • Power-Interest Grid — см. Матрица Менделоу

1. Зачем аналитику заниматься стейкхолдерами?

Жёсткая правда: Провал проекта редко бывает из-за плохого кода. Чаще всего — из-за того, что забыли согласовать требования с нужным человеком.

Статистика (по данным PMI и Standish Group):

  • 37% проектов проваливаются из-за недостаточного вовлечения стейкхолдеров (CHAOS Report)
  • Проекты с активным управлением стейкхолдерами успешны в 2,5 раза чаще

Задача аналитика — на старте ответить на 3 вопроса:

  1. Кто все люди, которые влияют на проект? (полный список)
  2. Как они влияют? (власть, интерес, роль)
  3. Как мы будем с ними работать? (стратегия коммуникации)

2. Полная классификация стейкхолдеров

2.1. По положению относительно проекта

Тип Определение Примеры
Внутренние Члены команды проекта и сотрудники компании-исполнителя Project Manager, разработчики, QA, архитектор, аналитик, DevOps
Внешние Находятся за пределами команды, но влияют на проект Заказчик, пользователи, подрядчики, регуляторы, партнёры, конкуренты

2.2. По отношению к проекту (более детальная классификация)

Категория Подкатегория Примеры
Инициаторы Те, кто «запускает» проект CEO, владелец бизнеса, государственный орган
Инвесторы / Спонсоры Выделяют бюджет и ресурсы Финансовый директор, грантодатель, совет директоров
Заказчики Формулируют требования и принимают результат Product Owner, бизнес-заказчик, клиент
Пользователи Непосредственно работают с результатом Операторы, менеджеры, кассиры, водители
Разработчики Строят решение Backend, frontend, архитектор, DevOps
Тестировщики Проверяют качество QA-инженеры, тест-аналитики
Эксплуатация / Support Обеспечивают работу системы Helpdesk, сисадмины, SRE
Регуляторы / Контроль Устанавливают правила и проверяют соблюдение Государственные органы, служба безопасности, юристы, compliance, DPO
Косвенно затронутые Меняют свою работу из-за проекта Бухгалтерия, HR, смежные отделы
Подрядчики / Вендоры Поставляют внешние компоненты или услуги Интегратор 1С, облачный провайдер, платёжный шлюз
Конкуренты Могут реагировать на проект Другие компании на рынке
Общество / СМИ Могут влиять на репутацию Пресса, профильные сообщества, профсоюзы

2.3. По степени формальности (отдельно для аналитика)

Тип Описание Как выявить
Явные Записаны в уставе проекта, в контракте, в оргструктуре «Очевидные» — прочитать Project Charter
Неявные Не указаны формально, но очевидны из контекста «Догадаться» — кто будет пользоваться? Кто будет платить?
Скрытые Нигде не указаны, часто о них забывают, но они обладают серьёзной властью Использовать техники поиска (см. раздел 3 ниже)

3. Методы поиска стейкхолдеров (7 техник)

Техника 1: Анализ устава проекта (Project Charter)

Что делать: Прочитать устав / контракт / инициационную документацию и выписать:

  • Спонсора (кто подписал бюджет)
  • Заказчика (кто принимает работу)
  • Ключевых участников со стороны заказчика

Результат: 3–5 очевидных стейкхолдеров — фундамент списка.

Техника 2: Снежный ком (Snowball Sampling)

Метод: После интервью с каждым стейкхолдером задавать 3 вопроса:

  1. «Кто ещё, по вашему мнению, должен быть вовлечён в проект?»
  2. «Кто может быть заинтересован в результате проекта?»
  3. «Кто может ему сопротивляться или заблокировать?»

Каждый новый стейкхолдер называет ещё 2–3. За 2–3 итерации список растёт с 5 до 30 человек.

Пример: Начинали с CEO → он назвал начальника IT-отдела → IT-директор назвал руководителя службы безопасности → безопасность назвала юриста → юрист — Data Protection Officer.

Когда применять: На старте проекта, в первой фазе интервью.

Техника 3: Анализ организационной структуры (Org Chart)

Что делать: Запросить оргструктуру компании-заказчика и отметить, какие отделы и роли могут быть затронуты проектом.

На что смотреть:

  • Отделы, которые будут поставлять данные в вашу систему
  • Отделы, которые будут получать данные из вашей системы
  • Отделы, чьи процессы изменятся (даже косвенно)

Пример для проекта «CRM-система»:

Генеральный директор (спонсор)
├── Коммерческий отдел (пользователи)
├── Бухгалтерия (получает отчёты из CRM)
├── Юридический отдел (договоры)
├── IT-отдел (эксплуатация)
├── Отдел маркетинга (email-рассылки)
└── Служба безопасности (доступ к данным клиентов)

Каждая из этих веток — потенциальный стейкхолдер.

Техника 4: Чек-лист «подразделения компании»

Пройдите по списку и отметьте, кто уже есть в вашем списке, а кого забыли:

  • Руководство — CEO, CFO, CIO
  • Заказчик — PO, Business Owner
  • Пользователи — операторы, менеджеры, администраторы
  • Разработка — архитектор, SA, backend, frontend
  • QA — тест-лид, тест-инженеры
  • DevOps / Инфраструктура — сисадмины, SRE
  • Бухгалтерия / Финансы — для проектов с денежными операциями
  • Юридический отдел — договоры, 152-ФЗ, GDPR
  • Служба безопасности (InfoSec) — политики, шифрование, аудит
  • Compliance / AML — для финтех-проектов
  • Data Protection Officer (DPO) — персональные данные
  • HR / Администрация — если система влияет на кадровые процессы
  • Техническая поддержка (Helpdesk) — будет работать с пользователями
  • Маркетинг / PR — внешние коммуникации, бренд
  • Подрядчики / Вендоры — внешние интеграции
  • Аудит (внутренний / внешний) — проверки

Техника 5: Анализ процесса «от начала до конца» (End-to-End)

Возьмите ключевой бизнес-процесс и для каждой стадии спросите: «Кто участвует?»:

Пример для проекта «Интернет-магазин»:

Пользователь заходит на сайт
         ↓
Кто создал контент?  → Маркетолог (стейкхолдер)
         ↓
Пользователь выбирает товар
         ↓
Кто обновляет остатки? → Кладовщик (скрытый стейкхолдер)
         ↓
Пользователь оплачивает
         ↓
Кто проводит платёж? → Бухгалтер (скрытый стейкхолдер)
Кто проверяет фрод? → Служба безопасности (скрытый)
         ↓
Курьер доставляет
         ↓
Кто управляет курьерами? → Логист (скрытый)
         ↓
Возврат / претензия
         ↓
Кто обрабатывает возвраты? → Отдел возвратов (скрытый)

Техника 6: Анализ последствий / «День после запуска»

Представьте, что система уже работает. Кто:

  • будет нажимать кнопки? → пользователь
  • будет её чинить, если упадёт? → DevOps / админ
  • будет отвечать на вопросы пользователей? → Helpdesk
  • будет жаловаться, если она неудобна? → операторы
  • будет платить штраф, если она нарушит закон? → юрист, DPO
  • лишится работы / полномочий из-за автоматизации? → недовольные стейкхолдеры

Важно: Последняя группа — самая опасная. Если проект автоматизирует чью-то работу, этот человек может (осознанно или нет) саботировать проект. Его нужно выявить и управлять его ожиданиями.

Техника 7: Краудсорсинг в команде

Что делать: Собрать команду проекта (PM, архитектор, лиды) и за 30 минут провести мозговой штурм «Кто наши стейкхолдеры?». Каждый участник видит проект со своей стороны.

Метод: Каждый пишет на стикерах по 3–5 стейкхолдеров, затем группируют.

Результат: Часто выявляются стейкхолдеры, которых аналитик в одиночку не увидел. Например, DevOps знает, что нужно согласовать deployment с администратором сети — а аналитик мог забыть.

4. Матрица Менделоу (Power-Interest Grid)

4.1. Что это?

Матрица Менделоу (или Power-Interest Grid) — инструмент, разработанный Aubrey Mendelow для классификации стейкхолдеров по двум параметрам:

Ось Что измеряет Вопрос
Власть (Power) Способность стейкхолдера влиять на проект, навязывать свою волю, блокировать решения «Может ли этот человек остановить проект?»
Интерес (Interest) Степень заинтересованности стейкхолдера в результате проекта «Обеспокоен ли он результатом? Будет ли он активно участвовать?»

4.2. Четыре квадранта и стратегии

                    ВЫСОКАЯ ВЛАСТЬ
                    ┌─────────────────────┬─────────────────────┐
                    │  Квадрант 2         │  Квадрант 1          │
                    │  УДОВЛЕТВОРЯТЬ      │  УПРАВЛЯТЬ ВПЛОТНУЮ   │
    НИЗКИЙ          │  (Keep Satisfied)   │  (Manage Closely)     │    ВЫСОКИЙ
    ИНТЕРЕС         │                     │                       │    ИНТЕРЕС
                    ├─────────────────────┼─────────────────────┤
                    │  Квадрант 3         │  Квадрант 4          │
                    │  МОНИТОРИТЬ         │  ДЕРЖАТЬ В КУРСЕ     │
                    │  (Monitor)          │  (Keep Informed)     │
                    │                     │                       │
                    └─────────────────────┴─────────────────────┘
                    НИЗКАЯ ВЛАСТЬ

Квадрант 1: Управлять вплотную (Manage Closely)

Высокая власть + Высокий интерес

Это самые важные стейкхолдеры. Они могут как сделать проект успешным, так и провалить его.

Примеры:

  • Product Owner / Заказчик
  • Спонсор проекта (если он активно вовлечён)
  • Руководитель ИТ-департамента

Стратегия:

  • Максимальная вовлечённость
  • Еженедельные статус-встречи
  • Привлекать к ключевым решениям
  • Демо после каждого спринта
  • Согласовывать все изменения требований

Риск: Если потерять этого стейкхолдера (он перестал уделять время) — проект теряет направление.

Квадрант 2: Удовлетворять (Keep Satisfied)

Высокая власть + Низкий интерес

Эти стейкхолдеры могут одним решением заблокировать проект, но им всё равно до тех пор, пока проект их не задевает.

Примеры:

  • Генеральный директор (если проект не стратегический)
  • Финансовый директор (пока проект в бюджете)
  • Руководитель юридической службы
  • Начальник службы безопасности

Стратегия:

  • Не беспокоить по мелочам
  • Информировать о ключевых вехах (milestones)
  • Быть готовым быстро ответить на запрос
  • Обязательно вовлекать, если проект пересекает их зону ответственности

Риск: Стейкхолдер может «проснуться» в критический момент и наложить вето, если его интересы не учтены.

Пример провала: Проект внедрения CRM сделали без участия юриста. За день до запуска юрист сказал: «Хранение персональных данных клиентов не соответствует 152-ФЗ». Запуск отложен на 3 месяца.

Квадрант 3: Мониторить (Monitor)

Низкая власть + Низкий интерес

Затрачивать минимум усилий. Эти стейкхолдеры не влияют на проект существенно.

Примеры:

  • Сотрудники смежных отделов (которых проект почти не касается)
  • Аутсорсинговые компании-подрядчики с фиксированным контрактом
  • Стажёры в команде

Стратегия:

  • Разовые отчёты
  • Периодический мониторинг (не изменился ли их интерес)
  • Максимум — email-рассылка раз в месяц

Важно: Следить, чтобы стейкхолдер не переместился в другой квадрант. Если его интерес вырос — перевести в Q4 или Q1.

Квадрант 4: Держать в курсе (Keep Informed)

Низкая власть + Высокий интерес

Эти стейкхолдеры заинтересованы в проекте, но не могут на него сильно влиять. Поддержание их в курсе — залог их лояльности.

Примеры:

  • Пользователи системы (операторы, менеджеры)
  • Техническая поддержка (Helpdesk)
  • Внутренние тренеры, которые будут обучать
  • Профильные специалисты (эксперты предметной области)

Стратегия:

  • Демо новых возможностей
  • Регулярные рассылки (что сделано, что планируется)
  • Сбор обратной связи (опросы, интервью)
  • Привлекать к UAT-тестированию

Риск: Если не информировать — пользователи будут сопротивляться внедрению («нас не спросили, нам навязали»).

4.3. Пример построения матрицы для проекта «Мобильное приложение доставки еды»

Стейкхолдер Власть (1-5) Интерес (1-5) Квадрант Стратегия
Владелец сети ресторанов (спонсор) 5 4 Q1: Управлять вплотную Личные встречи раз в 2 недели, демо после каждого спринта
Product Owner (от заказчика) 4 5 Q1: Управлять вплотную Ежедневный контакт, участие в grooming, приоритизация бэклога
Руководитель IT-департамента 5 2 Q2: Удовлетворять Ежемесячный статусный отчёт, вовлекать при вопросах архитектуры
Юрист 4 1 Q2: Удовлетворять Единоразово согласовать требования, привлекать только по 152-ФЗ
Бухгалтер 2 3 Q3: Мониторить Разовый опрос требований к отчётам
Курьеры 1 4 Q4: Держать в курсе Обучение перед запуском, сбор feedback через 2 недели после запуска
Операторы колл-центра 1 5 Q4: Держать в курсе Демо функций, FAQ, участие в UAT

4.4. Частая ошибка при работе с матрицей

Ошибка: Стейкхолдеры не статичны! В ходе проекта их интерес и власть могут меняться.

Пример динамики:

  • Стейкхолдер был в Q3 (Мониторить) — курьер.
  • Ситуация: Проект внедряет автоматическое распределение заказов, которое лишает курьеров выбора («чьи заказы брать»).
  • Результат: Интерес курьеров резко вырос → они перемещаются в Q4 (Держать в курсе), а если устроят акцию протеста — их коллективная власть может вырасти до Q1.

Действие аналитика: Пересматривать матрицу Менделоу на каждом этапе проекта (хотя бы раз в месяц или при существенном изменении).

5. RACI-матрица (Responsibility Assignment Matrix)

5.1. Что такое RACI?

RACI — это таблица, которая показывает роль каждого стейкхолдера в каждой задаче или артефакте проекта.

Расшифровка:

Буква Англ. Русский Что означает
R Responsible Исполняет Тот, кто физически выполняет работу
A Accountable Отвечает Тот, кто отвечает за результат (единственный!)
C Consulted Консультирует Тот, с кем согласуют до принятия решения (two-way communication)
I Informed Информируется Тот, кого ставят в известность после решения (one-way communication)

5.2. Золотые правила RACI

  1. На каждую задачу — ровно одна (1) роль A (Accountable). Если ответственность размыта, результат никто не делает.
  2. R и A не должны быть одним лицом (спорно, но рекомендуется — это даёт двойной контроль). Исключения — мелкие задачи.
  3. R может быть несколько — команда разработчиков.
  4. C — не более 2–3 человек на задачу. Иначе — бесконечные согласования.
  5. I может быть много — рассылка по списку.

5.3. Пример RACI-матрицы для IT-проекта

Проект: Разработка модуля «Корзина» для интернет-магазина.

Задача / Артефакт PO (заказчик) Аналитик (СА) Архитектор Team Lead Разработчик QA DevOps
Сбор требований к корзине C R C I I — —
Написание User Stories I R — C — — —
Согласование User Stories A R — — — — —
Разработка архитектуры модуля — C R A — — C
Написание кода — — — A R — —
Написание тест-кейсов — C — — — R —
Проведение code review — — I A R — —
Развёртывание на staging — — — — — — R
Приёмочное тестирование (UAT) A C — I — R —

Разбор по строкам:

  • Сбор требований: Аналитик — исполнитель (R). PO и архитектор — консультанты (C). Team Lead — информируется (I).
  • Согласование User Stories: PO — ответственный (A — решение за ним). Аналитик — исполнитель (R — подготовил документ).
  • Разработка архитектуры: Архитектор — R, Team Lead — A (контролирует, что архитектура выполнима в коде).
  • Code review: Team Lead — A (отвечает за качество кода). Разработчик — R (проводит ревью). Архитектор — I (знает о результатах).
  • UAT: PO — A (принимает решение: соответствует / не соответствует). QA — R (готовит и проводит). Аналитик — C (поясняет требования).

5.4. Пример RACI для артефакта «SRS-документ»

Действие с SRS Заказчик Аналитик Архитектор PM Юрист
Написание черновика — R — — —
Ревью функциональной части I A C — —
Ревью архитектурной реализуемости — I R — —
Ревью legal / compliance — I — — R
Утверждение (подпись) A I I I I
Актуализация при изменениях — R — — —

Ключевой вывод: A в утверждении SRS — только заказчик. Аналитик — R (автор), но он НЕ может утвердить SRS самостоятельно. Это принципиально.

5.5. Расшифровка позиций: как читать RACI?

Проверим распределение на примере «Разработка кода»:

Team Lead Разработчик
Написание кода A R
  • Разработчик — пишет код (R). Ручки пачкает он.
  • Team Lead — отвечает за то, что код написан верно, вовремя и соответствует стандартам (A). Если код не готов — спрашивают с Team Lead, а не с Ивана-разработчика.

Аналогия из жизни:

  • R — повар, который готовит блюдо.
  • A — шеф-повар, который отвечает, что блюдо соответствует рецепту и подано вовремя. Если клиент отравился — спрашивают с шефа, а не с повара.
  • C — дегустатор, которому дают попробовать до подачи.
  • I — официант, который знает, что блюдо готово, и может отнести его клиенту.

5.6. RACI vs RASCI (дополнительно)

Иногда используют расширение RASCI или RACI-VS:

Буква Значение
S Support — поддерживает (второй исполнитель, backup)
V Verifies — проверяет результат (например, QA)
S Sign-off — подписывает (тот, чья подпись нужна)

Но для большинства проектов классического RACI достаточно.

5.7. Типичные ошибки в RACI

Ошибка Пример Как исправить
Два A на одну задачу И PM, и заказчик — A в приоритизации Определить одного: либо PO — за ценность, либо PM — за сроки
Все — C 7 человек указаны как Consulted по каждому вопросу Оставить 1–2 ключевых консультанта, остальных — I
Пустые строки По задаче нет ни R, ни A Кто-то должен делать. Если никто — задача не будет выполнена
R = A = один человек Аналитик и R, и A для SRS Разделить: Аналитик — R, Заказчик — A (или PM)
Матрицу составили и забыли RACI есть, но никто в неё не смотрит Использовать при открытии каждой задачи: «Кто у нас R? Кто A?»

6. Интеграция: как связать матрицу Менделоу и RACI

На практике эти два инструмента используются последовательно:

Шаг 1: Найти всех стейкхолдеров  →  Техники поиска (раздел 3)
                ↓
Шаг 2: Оценить власть и интерес  →  Матрица Менделоу (раздел 4)
                ↓
Шаг 3: Определить стратегию      →  Стратегия по квадранту
                ↓
Шаг 4: Распределить роли         →  RACI-матрица (раздел 5)
                ↓
Шаг 5: Планировать коммуникации  →  План: кому, как часто, что сообщать

Пример связки для стейкхолдера «Юрист»:

Инструмент Результат
Метод поиска Чек-лист «подразделения» → добавили юриста
Матрица Менделоу Власть = 4 (может заблокировать), Интерес = 1 (пока не трогаем) → Q2: Удовлетворять
Стратегия Привлекать только по вопросам compliance, не беспокоить по мелочам
RACI для SRS Юрист — C (Consulted) для раздела Legal / 152-ФЗ
RACI для User Stories Юрист — I (Informed) о фичах, связанных с персональными данными
План коммуникаций Отправить SRS на согласование → получить подпись → только потом утверждение

7. Практические примеры: полный цикл для двух стейкхолдеров

Пример 1: Product Owner (внутренний, явный)

Параметр Значение
Тип Внутренний, явный (указан в уставе)
Власть 5 (принимает решение о приоритетах, бюджете)
Интерес 5 (заинтересован в результате)
Квадрант Менделоу Q1: Управлять вплотную
Стратегия Ежедневное общение, участие в grooming, демо, совместное планирование
RACI: Сбор требований C (консультант)
RACI: Утверждение SRS A (ответственный)
RACI: Приоритизация бэклога A (он решает)

Пример 2: Администратор базы данных (DBA) — скрытый

Параметр Значение
Тип Внутренний, скрытый (о нём часто забывают)
Как нашли Техника «анализ процесса» + чек-лист (DevOps подсказал)
Власть 3 (может заблокировать deployment, если схема БД unsafe)
Интерес 2 (его работа — не дать упасть БД, а не делать новую фичу)
Квадрант Менделоу Q3: Мониторить (но с потенциалом перехода в Q2)
Стратегия Вовлекать на этапе проектирования модели данных. Информировать о миграциях БД.
RACI: Модель данных C (консультант — проверит индексы, производительность)
RACI: Написание DDL-скриптов R (он пишет production-скрипты)
RACI: Развёртывание C (должен дать добро на миграцию)

8. Как составить план коммуникаций на основе анализа стейкхолдеров

Итоговый документ — таблица коммуникаций:

Стейкхолдер Квадрант Формат коммуникации Периодичность Ответственный
Product Owner Q1 Личная встреча + демо Еженедельно Аналитик
Архитектор Q1 Созвон по архитектурным вопросам По необходимости Аналитик / Архитектор
Генеральный директор Q2 Email-отчёт (1 страница) Ежемесячно PM
Юрист Q2 Email с запросом на согласование По необходимости Аналитик
Команда разработки Q4 Daily stand-up + общий чат Ежедневно Аналитик (участвует)
Пользователи Q4 Демо / новости в корпоративном портале Раз в спринт PO / Аналитик
Подрядчик (1С) Q3 Статус-митинг по интеграции Раз в месяц PM

Вопросы для самопроверки

  1. Чем внутренние стейкхолдеры отличаются от внешних? Приведите по 2 примера на каждый тип.
  2. Опишите 3 техники поиска стейкхолдеров. Какая из них, на ваш взгляд, самая эффективная на старте проекта? Почему?
  3. Нарисуйте (на бумаге или в mind) матрицу Менделоу. Разместите в ней: CEO (высокая власть, низкий интерес) и оператора колл-центра (низкая власть, высокий интерес). Какая стратегия для каждого?
  4. Что означает каждая буква в RACI? Какое золотое правило про количество ответственных (A)?
  5. В RACI-матрице для задачи «Согласование API-контракта с внешним сервисом» кто будет A, а кто R, если:
    • аналитик подготовил контракт
    • архитектор проверил техническую реализуемость
    • заказчик утвердил функциональность
    • внешняя команда подрядчика реализует свою сторону?

Практическое задание

Кейс: Вы — аналитик в проекте «Мобильное приложение для предзаказа обедов в офисной столовой». Руководство компании хочет, чтобы сотрудники могли заказать обед через приложение, оплатить онлайн и забрать в столовой без очереди.

Задание 1. Примените 3 техники поиска стейкхолдеров. Составьте полный список (минимум 12 стейкхолдеров). Разделите на внутренних / внешних / скрытых.

Задание 2. Для каждого стейкхолдера оцените власть (1–5) и интерес (1–5). Разместите в квадрантах матрицы Менделоу. Для каждого квадранта определите стратегию.

Задание 3. Составьте RACI-матрицу для следующих задач:

  1. Сбор требований к модулю оплаты
  2. Проектирование схемы БД
  3. Разработка API для интеграции с платёжным шлюзом
  4. Тестирование сценария «Оплата заказа»
  5. Приёмочное тестирование (UAT) с заказчиком

Роли: PO (заказчик от бизнеса), Аналитик, Архитектор, Team Lead, Backend-разработчик, QA, DevOps, Бухгалтер (для чеков и отчётности).

Формат сдачи: Один файл (md / doc) с таблицами.

Дополнительные материалы

  • Стандарт: PMBOK Guide (6th ed.), глава 13 — Stakeholder Management
  • Книга: A Guide to the Business Analysis Body of Knowledge (BABOK 3.0), глава 4 — Elicitation and Collaboration
  • Статья: Mendelow, A. L. (1991). «Stakeholder Mapping» (Proceedings of the 2nd International Conference on Information Systems) — оригинал
  • Инструмент: Miro — шаблон для Power-Interest Grid (есть готовые template)
  • Шаблон: RACI matrix template (Google Sheets / Excel) — скачать по запросу «RACI template»
  • Видео: «Stakeholder Analysis in 5 Steps» на YouTube (любой актуальный гайд по PM)

📚 Материалы модуля

🖼️ Схема и инфографика

🎬 Видео-лекция

🎬 Аналитик как следователь

📄 Дополнительные материалы (PDF)

📄Requirements Investigation Playbook
Скачать
Спросить ИИ