Как бизнес-аналитику работать с несколькими стейкхолдерами

1 декабря 2021

  • Автор: Кирилл Белявский

  • Сложность: норм

  • Время: 7 мин

Успех любого проекта во многом зависит от степени вовлеченности стейкхолдеров в него. Чем она выше, тем лучше качество получаемой от них информации, что значительно упрощает и ускоряет продвижение команды IT-специалистов к нужному для клиента результату. Так как работа со стейкхолдерами — одна из основных задач бизнес-аналитика (BA), ему важно найти подход к каждому из них, правильно определить приоритетность и организовать взаимодействие. Как это сделать, расскажу в статье.

Какими могут быть ключевые стейкхолдеры

Стейкхолдеры — это все люди, которые участвуют в проекте и так или иначе зависимы от него либо влияют на ход работы.

Как работать с несколькими стейкхолдерами _1Внутри команды бизнес-аналитик чаще всего общается с PM, Architect, Designer, Dev Lead + QA Lead. Так как все эти люди — коллеги, проблемы в построении коммуникации с ними возникают не так часто. С внешними стейкхолдерами со стороны клиента — PO (Product Owner), SME (Subject Matter Expert), Tech Lead (Arch, CTO, Tech Product Manager) и Sponsor, — дело обстоит иначе.

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

Для этого часто используют RACI, power-interest grid. Однако перечисленного может не хватить, чтобы построить продуктивные отношения между стейкхолдерами и бизнес-аналитиком. Нужен более глубокий анализ. В этом случае хорошо себя показывает техника Stakeholder Persona.

Выстраиваем отношения: техника Stakeholder Persona 

Как работать с несколькими стейкхолдерами _2В основе Stakeholder Persona лежит техника User Persona, которую часто используют в своей работе дизайнеры. Идея в том, что придумывают персонажа (будущего пользователя), обладающего ключевыми характеристиками для продукта. Затем их описывают, и уже на основании этих данных разрабатывают дизайн, который призван понравиться будущим юзерам/ В технике Stakeholder Persona все тоже самое, только вместо персонажа используем данные реального человека — стейкхолдера.

Суть техники: что делать

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

Ключевые моментыДанные от стейкхолдера
Сфера интересов: ожидания и опасения на счет продукта, отношения к нему.Ожидает, что продукт поможет опередить конкурентов в технологическом плане. Переживает из-за нефункциональных требований и сроков релиза. Данный проект ключевой на текущий год.
Особенности коммуникации: формат, каналы.Предпочитает общение через личные сообщения в Teams. E-mail редко открывает и читает. Может отменить встречу за 5-10 минут до начала.
Авторитеты: кому подчиняется, перед кем отчитывается, к кому прислушивается.Подчиняется CEO компании. Уважает Михаила (Architector), прислушивается к мнению Эрика (SME). Не любит Джона (UX/UI), с которым постоянно спорит на митингах, из-за чего они затягиваются. 
Ожидания от роли бизнес-аналитика: понимание роли BA на проекте и его «территории» ответственности, ключевые документы.Понимает необходимость бизнеса-аналитика на проекте, часто приглашает на митинги. Задает вопросы по эстимейтам, любит пвместе пройтись по бэклогу.
Личные особенности: характер и хобби, семья, питомцы.Любит отчеты, почти всегда серьезен. Сам шутит, но чужие редко воспринимает. Двое сыновей школьников. Любит рыбалку, футбол и быструю езду на своем спортивном авто. Есть большая старая собака, о которой может долго говорить.

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

К примеру, зная сферу интересов и авторитетов, BA легче подготовить к встрече нужные вопросы и правильно сформулировать предложения. Использование информации из блока «Личные особенности» часто помогают наладить отношения на старте проекта при неформальном общении.

Преимущества и недостатки техники

Плюсы:

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

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

Когда использовать

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

Supreme BA

Разрабатываем процессы через Design Thinking

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

  1. Understand. Понять суть проблемы, которую потенциально может решить продукт.
  2. Empathize. Поставить себя на место потенциального пользователя.
  3. Define. Определить проблемы юзеров, четко сформулировать их.
  4. Ideate. Придумать решения.
  5. Prototype. Создать прототип.
  6. Test. Провести тестирование.

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

Суть техники: что делать?

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

На стадии Understand + Empathize каждый ключевой стейкхолдер высказывает свои ожидания (Hopes) и опасения от процесса (Fears), размещая на онлайн доске соответствующие стикеры. В колонку Hopes пишут, чего процесс взаимодействия поможет достичь, а в Fears — какие проблемы могут возникнуть, чего хотелось бы избежать.

Как работать с несколькими стейкхолдерами _3

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

Как работать с несколькими стейкхолдерами_4_1После этапа Understand + Empathize переходят к Define — определяют основные проблемы, которые беспокоят стейкхолдеров. Обычно это делают путем голосования. На онлайн-досках на той же MIRO каждый участник может поставить точку определенного цвета напротив нужного стикера, что удобно и наглядно. 

По опыту, наиболее часто называют проблемы, связанные с requirements process, road map и meetings.

Как работать с несколькими стейкхолдерами _4

После стадии Define переходят к этапу Ideate — поиску идей, как можно встроить в процесс взаимодействия те решения проблем, которые определили на предыдущих этапах. Задачу усложняет то, что итог должен удовлетворить всех участников. Для удобства работы над поиском оптимальной схемы процесса можно договориться, что в течение определенного времени каждый предлагает свое видение и оставляет все это в общем доступе. Потом вся команда на встрече обсуждает полученную от всех информацию. Итогом должен стать готовый вариант рабочего процесса, после чего переходят к следующей стадии.

Как работать с несколькими стейкхолдерами _5

На этапе Prototype + Test бизнес-аналитик описывает все договоренности и создает ряд процессных артефактов. Далее получает формальное согласие всех стейкхолдеров на то, что взаимодействие на проекте будет происходить в предложенном виде, затем запускает процесс. Если же какие-то проблемы повторяются либо появляются новые после N-го времени следования утвержденной схемы работы, BA инициирует повторный воркшоп.

Преимущества и недостатки подхода

Плюсы:

  • Повышает вовлеченность стейкхолдеров. Они лучше понимают: чем занимается бизнес-аналитик на проекте, как формируются требования, как происходит коммуникация.
  • Подсвечивает ожидания ключевых участников проекта. Наглядно видно, что и кто ожидает от совместной работы. Также эту информацию можно легко перенести с доски в «карточку» Stakeholder Persona.
  • Можно использовать на любом этапе проекта. Его можно инициировать как на старте, так и в середине или даже на последних этапах работы.

Минусы:

  • Необходимо обучение стейкхолдеров. Пояснить им, что такое Design Thinking, как он работает, зачем нужен.
  • Процесс времязатратный. Нужно организовать всех участников, затем проанализировать данные, выработать дальнейший процесс и все это привести к формальному виду, который будет понятен всем.
  • Результат может удовлетворить большинство, но не всех стейкхолдеров. Это актуально для всех процессов, которые растянуты во времени.

Когда использовать

Применять Design Thinking можно на проектах любой сложности, когда стоит задача выработать процесс взаимодействия с большим количеством стейкхолдеров с нуля либо же изменить текущий формат уже в процессе. Эффективен как в случае с Co-located командами (находятся в одном месте), так и распределенными (территориально и по временным зонам).

Вместо вывода

Умение правильно выстроить отношения и процесс взаимодействия со стейкхолдерами — один из основных софт-скилов для бизнес-аналитика. Помочь в этом могут разные инструменты и техники, но Stakeholder Persona и Design Thinking однозначно входят в ТОП наиболее эффективных. Применяя их правильно на практике, вы всегда сможете настроить комфортную, и что важнее, результативную работу с любым количеством стейкхолдеров вне зависимости от уровня проекта.

P.S. Если хотите узнать еще больше эффективных методов работы бизнес-аналитика с командой и клиентом, приглашаем на курс Supreme BA, где вас ждут: рабочие кейсы от экспертов, теория, практика и еще раз практика. Чтобы понять, подходит ли вам программа, запишитесь на бесплатную консультацию — мы с удовольствием поделимся демо-уроком и тестом на проверку ваших знаний и навыков. 

Кирилл Белявский

Кирилл Белявский

Lead Business Analyst в SoftServe. Более 8 лет опыта в бизнес анализе. Спикер курсов I am BA и Supreme BA. Регулярный лектор на курсах, митапах и конференциях, ведет подкаст о жизни и бизнес-анализе.