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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикация
Agile, Scrum, Kanban–метод
Мифы об Agile. Кросс-функциональными должны быть все члены команды
Миф связан с распространяющимся иногда суждением, что Agile требует, чтобы каждый член команды обладал всеми необходимыми навыками для создания ценности клиенту.
Публикация
Agile, Scrum, Kanban–метод
Отказаться от оценки задач и улучшить отношения с заказчиком
Третий подход к оценке задач, NoEstimates — один из самых интересных. Что если перестать оценивать задачи вообще?
Публикация
Agile, Scrum, Kanban–метод
Agile + Lean: комплексный подход к изменениям в компании
Agile и Scrum сейчас очень популярны. К нам обращается огромное количество компаний с просьбой внедрить Agile-практики и обучить сотни сотрудников. Но всегда ли требуется, а главное, подойдет именно Agile / Scrum?
Публикация
Разработка ПО
Agile как основа технологического бизнеса
Бизнес — это деятельность с целью получения прибыли. Технология — это знание, как делать что-либо. Соответственно, технологический бизнес — это знание того, как правильно действовать, чтобы получить прибыль.

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

Свяжитесь с нами

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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