Анализ стейкхолдеров проекта 💎 — OnAgile Consulting

Анализ стейкхолдеров проекта

Несмотря на то, что в базовом варианте работа agile-команды не предполагает такую процедуру как Управление проектом (как и саму роль менеджера проекта), часто бывает полезно применять хорошие практики, наработанные в рамках стандартных процедур управления проектами. Одна из них — анализ стейкхолдеров проекта.

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

Что сделать: собраться командой вместе с владельцем продукта на двухчасовую (обычно этого времени достаточно) встречу и посмотреть на то, каких заинтересованных лиц мы можем идентифицировать, и как следует управлять их ожиданиями и вовлекать в процесс.

Типовые шаги встречи

 1. Нарисовать шаблон матрицы стейкхолдеров (как на примере)

 2. Заполнить шаблон методом «тихой фасилитации» - попросить каждого, независимо от других, в течение 7-10 минут выписать заинтересованные лица, которые он видит в контуре проекта. Это может быть как ГД компании, так и простые пользователи будущего продукта.

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

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

 5. Сформировать план коммуникаций — определить по каждому заинтересованному лицу на какие встречи и как часто мы его должны приглашать (или использовать другие каналы коммуникации, например, письма со статусом или слайды с демо очередной версии продукта).

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

Сама по себе культура agile-подхода не подразумевает создания большого количества артефактов и управления ими, поэтому основная задача упражнения по анализу заинтересованных лиц — это расширить видение командой задач продукта, над которым она работает, и не забыть поддерживать нужный уровень коммуникаций с окружающим миром.

Поэтому дальнейшее поддержание актуальности этого артефакта не является обязательным и полностью зависит от решения команды.

Еще публикации по Agile в Agile, Scrum, Kanban–метод

Публикация
Agile, Scrum, Kanban–метод
Agile + Lean: комплексный подход к изменениям в компании
Agile и Scrum сейчас очень популярны. К нам обращается огромное количество компаний с просьбой внедрить Agile-практики и обучить сотни сотрудников. Но всегда ли требуется, а главное, подойдет именно Agile / Scrum?
Публикация
Agile, Scrum, Kanban–метод
Мифы об Agile. Самоорганизация недостижима
Миф связан с некорректной интерпретацией термина «самоорганизация» — отсутствие менеджмента, бесконтрольные действия людей. Однако в самоорганизацию вложен совсем иной смысл.
Публикация
Agile, Scrum, Kanban–метод
Выбор пилотной команды для внедрения Agile
«С какой команды лучше начать пилотное внедрение Agile?» — часто спрашивают нас клиенты, особенно в крупных компаниях.
Публикация
Agile, Scrum, Kanban–метод
Покер планирования - совместная оценка задач командой
Planning poker — техника командной оценки задач в относительных единицах. Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning».

Мы помогаем организациям с 2004 года

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!