От барьеров к результатам: Как наладить эффективное взаимодействие со стейкхолдерами

Термин стейкхолдер

В основе данного термина лежит английское слово – “Stakeholder”, буквально – «владелец доли». Оксфордский словарь даёт нам такое определение – человек, который интересуется или беспокоиться о чем-нибудь, особенно в бизнесе. Термин на русский язык можно перевести, как «заинтересованная сторона». Состоит из слияния двух слов

1) stake – может иметь несколько значений перевода на русский:

– доля (в компании)

– что-то, что ставится на кон ради прибыли или убытка

– находиться под угрозой

– заостренный кусок дерева или другого материала, вбитый в землю в качестве маркера или опоры

2) holder – хранитель, держатель.

История первого использование этого термина уносит нас в эпоху колонизации Америки. Во время экспансии на Запад европейские поселенцы буквально «застолбили» (“stakes”) себе землю, чтобы заявить о своих правах собственности, вытеснив коренных жителей, которые изначально там жили. В документах о таких поселенцах описывали словом «стейкхолдеры».

Существует версия что возникновение современного значения слова «стейкхолдер» связано с азартными играми. Так потом называли человека, принимающего ставки и хранящего у себя до объявления победителя.

Считается, что современная история концепции заинтересованных сторон началась с монографии Р. Э. Фримена «Стратегическое управление: роль заинтересованных сторон», изданной в 1984 г1.

Для проектного управления под словом «стейкхолдер» понимают лицо, группу или организацию, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта2.

А управление стейкхолдерами (Stakeholders management) – Описывает процессы и методы, необходимые для определения заинтересованных сторон проекта и управления взаимодействием между ними и проектной командой.

Как правило, работая со стейкхолдерами руководители проектов концентрируют усилия на трёх группах:

– Кто активно вовлечен в проект и работает в нем (спонсор проекта, проектная команда, спонсор, управляющий комитет, привлеченные сторонние компании и другие исполнители и т.д.)

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

– Кто в проект не вовлечен, но кто, в силу своего положения или профессиональной деятельности, может на него влиять (топ-менеджеры компании, владельцы и инвесторы, акционеры, кредиторы, внешние и внутренние партнеры, регулирующие государственные органы, общественность и т.д.)

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

На основе влияния можно потом выстроить векторы воздействия: Эмоциональный и Рациональный.

Эмоциональный вектор, оценивает как стейкхолдеры относятся к проекту и какой эффект ожидают от проекта на субъективном уровне, и создать положительное представление – это будет ваше «завоевание сердец».

Рациональный вектор позволяет изменить установки насколько стейкхолдеры уверены в том, что выполняемая работа и результаты проекта являются правильными, этот путь называется «завоеванию умов».

В большинстве случаев справедливым считается формула «Дай стейкхолдерам то, что нужно им. А они дадут то, что нужно тебе в замен». Если это делать спонтанно, без плана – скорее всего руководителя ждёт провал, для успеха нужно выстраивать плановый и системный взаимообмен.

Часто я слышу, что заказчик и стейкхолдер – синонимы, и если выстроить работу с заказчиком, то дело сделано. Как мы увидели выше – заинтересованные стороны, те кого проект или продукт так или иначе затрагивает. Сюда же относятся и те, кого проект не затрагивает, но они могут повлиять или подвержены влиянию. Но Заказчики – это те, кто формируют основную задачу для создания продукта или начала проекта. Отсюда можно сделать вывод что заказчики являются частью сущности стейкхолдеры. Но не стоит забывать спонсоров, конечных пользователей ИТ продукта, клиентов.

Стейкхолдеры в «Результат проекта» и в «Процессы проекта».

Если на стейкхолдеров взглянуть с другого ракурса – их можно типизировать на тех, у кого зона интересов связана с результатами проекта – т.е. продуктом – пользователи и заказчики, и тех, кого больше волнуют процессы протекающие в проекте – предоставление отчётности, достижение метрик, соблюдение требований законодательства и внутренней документации в компании, выдерживание рамок бюджета. Это кураторы и руководители подразделений, сотрудники финансовой службы или отдела кадров. Понимая такую типизацию, руководитель проекта сможет на шаге выявления стейкхолдеров задавать правильные вопросы, а это в свою очередь поможет выявить как можно больше стейкхолдеров.

Уровень взаимодействия, частота, канал в коммуникации будут резко зависеть от того, к какой отдельной группе или двум группам сразу будет относится наше заинтересованное лицо. Об это мы поговорим ниже.

Обзор процессов работы со стейкхолдерами по PMBOK версии 6.

Рассказ о методологиях работы со стейкхолдерами был бы неполным, если не затронуть насколько детально расписаны процессы, в пусть уже считающейся устаревшей после выхода в свет версии 7, но всё-таки все ещё актуальной PMBOK 6.

В книге описывается 4 процесса:

Как и все другие процессы в PMBOK – все описано очень теоретически, и не даёт ответов как именно с практической точки зрения все вышеуказанное реализовать руководителю проекта. Главная польза для руководителя проекта от изучения описания процессов в книге – понимание последовательности выполнения процессов один за другим и то, что «Мониторинг вовлечения стейкхолдеров» осуществлять в течении всего проекта.

После старта проекта первая активность, когда команда проекта взаимодействует со стейкхолдерами – это сбор требований. В этом процессе происходит документирование потребностей заинтересованных сторон для достижения заявленных целей проекта.

Что нам говорит Scrum про работу со стейкхолдерами

В Scrum Guide от ноября 2020 года слово Стейкхолдер встречает 13 раз, при этом само определение термина не приводится. Поэтому, мне кажется, уместным будет пользоваться общепринятым определением, которое приводилось выше. Так же Scrum Guide оперирует ещё термином ключевые стейкхолдеры (key stakeholders), и тоже без расшифровки определения. Логично нам предположить, что это какие более важные стейкхолдеры, чем обычные, без приставки «ключевые».

Основная роль управления стейкхолдерами возлагается на Владельца продукта (Product Owner), который должен перекладывать выявленные потребности от всех стейкхолдеров внутрь артефакта под названием Беклог Продукта (Product Backlog). Он должен хорошо знать в лицо стейкхолдеров, каждый день с ними взаимодействовать, как требует 4й принцип Agile – «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе»3.

При этом в рамках уже согласованных задач, взятых в работу командой Скрам Мастер (Scrum Master) выполняет ряд важных задач при взаимодействии со стейкхолдерами:

– Фасилитирует взаимодействие и организовывает сотрудничество между заинтересованными сторонами.

– Осуществляет устранение барьеров между стейкхолдерами и Scrum-командами.

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

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

В целом ответственность за управление стейкхолдерами сразу распределена между всеми ролями в Scrum:

– Владелец продукта по новым задачам и метрикам

– Команда в процессе реализации уже существующих задач поддерживая уровень удовлетворённости. При этом стейкхолдеры с дополнительными вводными в задачи или совсем новыми требованиями отправляет к Владельцу продукта

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

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

Макс Кларксон (1922 – 1998) – выдающийся исследователь в области управления заинтересованными сторонами описал основные принципы по управлению заинтересованными сторонами:

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

Принцип 2 – Коммуникации: РП должны прислушиваться к заинтересованным сторонам и открыто общаться с ними об их проблемах, а также о рисках, которые они принимают на себя в связи с их участием.

Принцип 3 – Поведение: РП должны внедрять процессы и модели поведения, которые учитывают проблемы и возможности каждой заинтересованной группы.

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

Принцип 5 – Кооперация: РП должны сотрудничать с другими участниками, как с государственными, так и частными, чтобы гарантировать, что риски и вред, возникающие в результате деятельности, сведены к минимуму и, там, где их невозможно избежать, должным образом компенсированы.

Принцип 6 – Защита прав: РП должны полностью избегать действий, которые могут поставить под угрозу неотъемлемые права человека или привести к рискам, которые, если их ясно понять, будут явно неприемлемы для соответствующих заинтересованных сторон.

Принцип 7 Конфликты: РП должны признавать потенциальные конфликты между собой и заинтересованными сторонами или просто между стейкхолдерами. Конфликты должны разрешаться посредством открытого общения, соответствующих систем отчетности и стимулирования и, при необходимости, проверки третьей стороной.

Отсюда следует, что Руководитель проекта как минимум должен не оставлять без внимания стейкхолдеров, вести системную и внимательную работу с ними.

Output, Outcome, Impact – почему они недовольны результатом

Выстраивая работу с заинтересованными сторонами, руководитель проекта может столкнуться ситуацией, когда его команда прекрасно выполнит свою работу, сделает красивый продукт, в срок и не превысив бюджет. Вы ожидаете восторг и благодарность за успешно проделанную работу, но увы такого на демонстрации результата не происходит.

Что бы разобраться этом эффекте и найти способы преодоления такого препятствия сначала давайте изучим 3 термина и разберём пример:

Output (англ.: выход) описывает результат который достигается определенной активностью. Может относиться к продукту, услуге или другому легко ощутимому достижению.

Например, вам на встрече пожаловался генеральный директор что, работая в вашей ИТ системе согласования заявок на оплату, очень медленно происходит массовое выставление виз. Вы провели замеры и действительно на пакет в 20 заявок требуется около 60 секунд. Вы потратили 20 часов работы одного разработчика и оптимизировали код таким образом что вышеуказанный пакет согласовывается всего за 20 секунд. Ваш Output – 3х кратное увеличение производительности и даже не потребовалось времени больше недели. Классный результат «за дёшево» и надо «пиариться» перед стейкхолдером. Для красоты цифр можно в рассказе использовать значение «300%». В рамках этой задачи в нашем чек-листе все метрики «зелёные»:

– производительность увеличилась – да;

– без дополнительных ресурсов и затрат – да;

– серверные мощности остались прежние – да;

– срок между постановкой задачи и результатом (Time-To-Market) приемлемый – да.

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

Outcome (англ.: исход) – термин определяет эффект, достигнутый с участием вышеприведённого «output». В других словах, описывает реально добавленную ценность продуктом.

В продолжение нашего примера, в ответ на ваши достижения в трёхкратное увеличение вы получаете хлёсткое: “я проверил, ничего не изменилось, все так же медленно».

Что мы получаем в итоге:

– Вместо «молодец, хорошо справился» разработчик получит или новую задачу на ещё большее улучшение или, что хуже, информацию о том, что его работа была в пустую. Тут лучше ничего не сказать, чтобы не демотивировать.

– Сами получаем статус «Пети» кричащего «волки-волки» перед самым важным стейкхолдером.

– Потребность показать, что работы были проведены не зря – провести личную демонстрацию в формета «до внесения изменения» с секундомером и «после», включая-выключая настройку, то есть ещё раз отнять его время и не факт, что придёт осознание.

– Дополнительные затраты времени для себя и программиста.

Если проанализировать ситуацию, можно было бы в такую ситуацию не попасть, если сначала спросить какое значение производительности является приемлемым и ожидаемым. А ещё провести замеры поведения пользователя в системе. Тогда можно было бы увидеть, что, выставив «визы» на документах и нажав кнопку, основное окно сворачивается, потому что там идёт длительный процесс. Пока идёт обработка продолжается работа в других документах, чтобы не терять время. Несколько минут спустя, он возвращается к основному окну вашей программы выбирает пачку в новые 15-20 документов и операция повторяется. Поэтому прирост производительности от 60 до 20 секунд на самом деле не заметен. Да и как выяснилось чёткое значение первичного показателя в 60 секунд даже было не известно генеральному. Решить задачу можно было бы, если бы в интерфейсе визы выставлялись бы «мгновенно» (а именно такие в целом ожидания были озвучены позднее на детальном интервью), а потом уже дописывались в систему, в отложенном формате. Но это было бы возможно только через создание нового процесса, а не в оптимизации текущего в 3 раза.

Слово impact (анг.: воздействие) описывает результат в длительной перспективе и может оказаться не в прямой зависимости от outcome или output.

В целом, конечно, impact как правило, больше связан с какими-то серьёзным метриками, которые можно достигнуть через длительное время от событий output и outcome используя продукт, но и в нашем примере долгосрочное влияние уже можно представить:

– в оценке профессионализма руководителя проекта со стороны генерального директора;

– в уровне мотивации программиста, он работу сделал, но нет подтверждения что она принесла результат;

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

Что необходимо руководителю проекта для управления заинтересованными сторонами

Когда речь заходит об управлении заинтересованными лицами в ИТ проекте на бумаге рецепт идеального руководителя (дальше, я буду привычно для среды управления проектами, иногда использовать сокращение «РП») выглядит просто, не сложнее рецепта блинов. Итак, нам потребуется:

Вот и наш идеально прокаченный Руководитель Проекта, который сможет склонить на свою сторону почти любого стейкхолдера.

Понятное дело, в нашем рецепте, почти половина зависит от удачи. А она нет-нет, да и отвернётся даже от самого везучего, поэтому это не наш метод. На самом деле, успех заключается в методичном и последовательном выполнении 4х шагов по работе со стейкхолдерами:

Шаг 1. Выявить

Шаг 2. Классифицировать

Шаг 3. Выработать план на основе классификации

Шаг 4. Постоянная оценка и корректировка планов, инструментов и подходов

И это все на протяжении всего проекта, до самого последнего дня, и иногда даже после. Руководитель должен готовиться погружаться постоянно в этот процесс и держать в голове много дополнительный информации, считывать эмоции, настроения. И самое главное – вкладывать в это свою энергию.

Шаг 1. Выявить

На первом шаге – Затрагивая процедуру выявления стейкхолдеров помимо создания поимённого списка, будет необходимо: определить их основные проблемы, просчитать столкновения различных интересов, вычислить различные ограничения и оценить возможности взаимодействия с каждым стейкхолдером.

Прежде чем приступать к идентификации стейкхолдеров ИТ проекта важно визуализировать «Жизненный цикл» самого проекта для участников мозгового штурма. Это сильно поможет команде генерировать мысли и наносить на карту.

Для процесса идентификации попробуйте в команде проекта задать нижеследующие вопросы и записать ответы.

Вопросы для идентификации стейкхолдеров в области «Результат проекта»:

Для кого мы создаём данный продукт? Кто его будет использовать? Кому предстоит его администрировать и эксплуатировать?

Как вы думаете кто может пригодиться вне команды на каждом из этапов проекта.

Что необходимо знать, чтобы выпустить продукт?

Кто-то уже в компании имеет соответствующий опыт?

Кем будут приниматься решения по продукту?

Чье мнение окажется важным и требуется посоветоваться прежде, чем принимать решение.

Кто вне команды будет выполнять действия согласно принятых решений?

Чья активная поддержка имеет существенно значения для успеха проекта?

Для кого проект будет выгоден, а для кого несёт угрозу?

Кого в обществе мы можем потревожить нашей активностью?

Вопросы для идентификации стейкхолдеров в области «Процессы проекта»:

С кем придётся согласовывать методологию работы над проектом?

В чьих руках будут находится финансы, и кто будет согласовывать движение денежных средств в рамках проекта?

В чьих руках будут находится кадровые вопросы команды проекта?

Кто владелец регламентов и положений, в рамках которых будет осуществляться деятельность внутри проекта?

Какие ключевые законодательные акты могут повлиять на достижение целей проекта? С кем надо контактировать и консультироваться что бы не наступили риски?

Кому необходимо будет сдавать отчёты?

На чьи метрики может повлиять проект?

Кто будет принимать итоговый продукт когда проекта закончится?

В рамках проектов очень часто приходится оперировать аббревиатурой «ЛПР»4– Лицо принимающее решение. Это такой человек, который наделен полномочиями в той или иной сфере и несёт прямую ответственность за реализацию и последствия принятого решения. Это не обязательно должен быть руководитель подразделения, им может оказаться лидером или экспертов в определённой области. При этом он должен обязан выдать в команду проекта решение. Ключевое слово «обязан», и от выданной информации порой может зависеть каким будет ИТ продукт. Для ЛПР важна высокая оперативность и к его помощи команда прибегает в случаях недостатка информации для принятия решения или нехватки времени. Таким образом такие ЛПР становятся стейкхолдерами и должны быть идентифицированы.

Реальные и виртуальные стейкхолдера

Большая часть ИТ проектов это про проверку гипотез и конкретных пользователей у продукта ещё может не быть. Если вы создаёте продукт для большого количества пользователей вашего ИТ продукта, руководитель проекта может вводить «виртуального стейкхолдера» – представителя потенциальных пользователей и наделять его определёнными свойствами и желаниями.

В отличие от реального стейкхолдера, у которого есть Фамилия и имя, название организации, чётко понятно, где он сидит и как к нему обратиться, виртуальные живут только в наших головах и документах. Но уже начинают влиять на наш проект или быть подвержены влиянию проекта.

Хорошо, когда его принесут маркетологи или другие стейкхолдеры. Если нет, то такого стейкхолдера команда сочиняет на мозговом штурме по методу «портрет клиента», описывая его пол, возраст, привычки, которые сформируют желания и требования к к итоговому продукту. И на ранней стадии проекта этого виртуального стейкхолдера будет достаточно.

Введение «виртуальных» заинтересованных сторон позволяет детальнее определить степень влияния и способы реагирования на поведение. Если РП работает с «общественностью», тяжело предусмотреть планы и действия для всех возрастных и социальных категорий в этой сущности. А если ввести виртуального стейкхолдера «пожилая женщина, на пенсии, которая выгуливает в парке свою собачку дважды в день и читает книгу на скамейке у входа», то сразу понятны и риски, и маршруты, по которым она может пожаловаться на вас, если вы решили провести ремонтные работы и на неделю убрать скамейки пока монтируете столбы и вешаете камеры для видеонаблюдения. И сразу понятно, как выработать способы противодействия или снижения уровня дискомфорта для такого стейкхолдера.