Открытый микрофон #1. Как взаимодействовать со стейкхолдерами
Про тему доклада
Доклад получился скорее про то, как выявлять и инвентаризировать стейкхолдеров и делить их на группы. В этом смысле, как именно взаимодействовать рассказано немного. Оно в целом понятно почему — на таком уровне абстракции их сложно дать.
Про подход работы со стейхолдерами
С одной стороны, этот подход имеет существенные плюсы, например, он позволяет уйти от ловушек стандартных ролей типа «Заказчик», «Спонсор» «Product Owner» и т. д., на которые навешиваются функции, которые конкретный человек в конкретном проекте не в состоянии (не может/не хочет) выполнить.
С другой стороны, в таком виде подход становится слишком верхнеуровневым и абстрактным. Т.е., он формально правильный, но в деятельности никак не помогает. Этим страдают все стандарты энциклопедии в стиле *BOOK.
Пример верхнеуровневой и абстрактной диаграммы
Вот классическая цитата в таком стиле из рекомендаций по Data Governance. Замените «Data Governance» на что угодно еще, и вы получите очень правильный, но абсолютно бесполезный план (начать, продолжить, закончить).
На самом деле, стейкхолдеры нас интересуют всего в 2-х аспектах (Матрица влияния/воздействия скорее про это):
стейкхолдеры принимают/влияют на наши решения, которые мы принимаем (а это значит, что они могут остановить/перенаправить проект и т.д.);
наши решения влияют на стейкхолдеров (у них может что-то сломаться/починиться
из-за нас).
Конечно, каждая ситуация уникальна, но хорошей практикой является все-таки выделять роли и с каждой ролью работать отдельно. При этом, хорошо, если матрица ролей составлена относительно важных процессов для команды проекта. Например, в разрезе полномочий и с какими правами (эксклюзивно решает, имеет право вето или просто как-то влияет):
кто инициирует процесс (старта проекта/команды);
кто решает вопрос финансирования;
кто имеет влияние на backlog;
кто принимает готовый результат;
кто устанавливает сроки;
кто может выделить необходимый ресурс (людей, оборудование);
и т.д.
И тогда уже для определённых групп людей можно проработать конкретные рекомендации по взаимодействию.
Вот тут, например, есть мои старые рекомендации по работе с группой ролей, которые могут ставить задачи и ожидают их исполнения. Еще полезно посмотреть про управления ожиданиями и восприятием.
Еще важно помнить, что Stakeholder — это очень грубое и проектно- или продуктоцентричное упрощение жизни.
Реально стейкхолдеры чаще всего заинтересованы в окружении продукта/проекта, а не в самом продукте.
Про управление требованиями
Слово «требование» тоже очень плохой термин. Он употребляется в 2-х разных смыслах: в широком и узком. Они часто путаются.
Про предлагаемые артефакты
Список стейкхолдеров мы используем. В частности, каждый FAST старается поддерживать в актуальном состоянии матрицу коммуникаций.
Матрица RACI. По моему опыту не работает совсем (write only документ).
Матрица влияние-воздействие. Полезна, но подходит скорее для того, чтобы погрузиться в тему, а не для того, чтобы использовать каждый день.
Матрица влияние-отношение. Это про политику в большой организации. Очень тонкая и скользкая тема и гораздо более сложная.
План коммуникаций.Мне кажется, что это подпорка для начинающих. В целом на уровне здравого смысла делается и так грамотным менеджером.
Луковичная модель хорошо иллюстрирует и довольно полно показывает группы стейкхолдеров, но она не отражает значимость стейкхолдеров для проекта/продукта (кажется, что в группе «Поставка решения» находятся самые важные стейкхолдеры — это не так); подходит скорее для того, чтобы погрузиться в тему, а не для того, чтобы использовать каждый день.
Диаграмма луковичной модели
Про заказную разработку
Работал в заказной разработке 15 лет (Custis), обычно все это решается специальной ролью (account manager), который уже сам это не очень технологизированно ведет в своей записной книжке. Важно это становится в случае, если включается цикл вторичных продаж. Тогда все контакты мыслятся как Lead-ы и ведутся в CRM.
