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

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

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

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

«Дружище, зачем так сложно?»

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

Матрицы влияния и отношения мне сложно использовать. Вот знаю я, что у ПФР влияние и воздействие высокое, а отношение – никакое. Но что я с этим могу сделать? С другой стороны, если говорить о менеджере соседнего продукта, то тут есть шанс наладить с ним дружбу. Но буду ли я строить ради него матрицу? Вряд ли.

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

Про тему доклада

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

Про подход работы со стейхолдерами

С одной стороны, этот подход имеет существенные плюсы, например, он позволяет уйти от ловушек стандартных ролей типа «Заказчик», «Спонсор» «Product Owner» и т. д., на которые навешиваются функции, которые конкретный человек в конкретном проекте не в состоянии (не может/не хочет) выполнить.

С другой стороны, в таком виде подход становится слишком верхнеуровневым и абстрактным. Т.е., он формально правильный, но в деятельности никак не помогает. Этим страдают все стандарты энциклопедии в стиле *BOOK.

Вот классическая цитата в таком стиле из рекомендаций по Data Governance. Замените “Data Governance” на что угодно еще, и вы получите очень правильный, но абсолютно бесполезный план (начать, продолжить, закончить).

На самом деле, стейкхолдеры нас интересуют всего в 2-х аспектах (Матрица влияния/воздействия скорее про это):

• стейкхолдеры принимают/влияют на наши решения, которые мы принимаем (а это значит, что они могут остановить/перенаправить проект и т.д.);

• наши решения влияют на стейкхолдеров (у них может что-то сломаться/починиться
  из-за нас).

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

• кто инициирует процесс (старта проекта/команды);

• кто решает вопрос финансирования;

• кто имеет влияние на backlog;

• кто принимает готовый результат;

• кто устанавливает сроки;

• кто может выделить необходимый ресурс (людей, оборудование);

• и т.д.

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

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

Еще важно помнить, что Stakeholder – это очень грубое и проектно- или продуктоцентричное упрощение жизни.

Реально стейкхолдеры чаще всего заинтересованы в окружении продукта/проекта, а не в самом продукте.

Про управление требованиями

Слово «требование» тоже очень плохой термин. Он употребляется в 2-х разных смыслах: в широком и узком. Они часто путаются.

Про предлагаемые артефакты

• Список стейкхолдеров мы используем. В частности, каждый FAST старается поддерживать в актуальном состоянии матрицу коммуникаций.

• Матрица RACI. По моему опыту не работает совсем (write only документ).

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

• Матрица влияние-отношение. Это про политику в большой организации. Очень тонкая и скользкая тема и гораздо более сложная.

• План коммуникаций. Мне кажется, что это подпорка для начинающих. В целом на уровне здравого смысла делается и так грамотным менеджером.

• Луковичная модель хорошо иллюстрирует и довольно полно показывает группы стейкхолдеров, но она не отражает значимость стейкхолдеров для проекта/продукта (кажется, что в группе «Поставка решения» находятся самые важные стейкхолдеры – это не так); подходит скорее для того, чтобы погрузиться в тему, а не для того, чтобы использовать каждый день.

Про заказную разработку

Работал в заказной разработке 15 лет (Custis), обычно все это решается специальной ролью (account manager), который уже сам это не очень технологизированно ведет в своей записной книжке. Важно это становится в случае, если включается цикл вторичных продаж. Тогда все контакты мыслятся как Lead-ы и ведутся в CRM.

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

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

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

Я бы посоветовал проработать 2 момента:

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

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

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

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

Теперь по видео:

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

2. Стейкхолдеры – не было сразу упомянуто про спонсоров и их важность, вообще не было особых попыток к разбиению по матрицам добавить то, на что мы 100% обращаем внимание в проекте – понимание формальной и неформальной иерархии.

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

4. Зачем-то на матрице разбиения стейкхолдеров интерес был заменен на влияние, притом сам Дима периодически называл то так, то так (это уже мелочи).

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

6. Нужно ли тебе работать в организации, где есть явные враги изменений? Для каждого человека есть персональные триггеры, при срабатывании которых надо заставить себя покинуть проект/компанию.

7. При рассказе про план коммуникаций не было попытки рассказать, зачем он нужен.

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

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

Про работу с требованиями СХ очень мало инфы. Дима правильно говорит о том, что их может быть много и они могут постоянно давать требования, а эти требования постоянно могут меняться. У любого здравомыслящего человека сразу возникает вопрос: «И что с этим делать?». Я на своей практике сталкивался с ситуацией, когда требования менялись быстрее, чем аналитик успевал их удовлетворять. Есть отличный пример на эту тему – сказка «О рыбаке и рыбке» у А.С. Пушкина. Это, на мой взгляд, проблема. В презентации периодически проскакивает про то, что нужно поддерживать «удовлетворенность» стейкхолдеров, но не сказано, что иногда нужно уметь сказать «НЕТ» - это супер важный навык, потому что: во-первых, у нас есть свои цели, свои сроки и свои ресурсы, в которые нам надо уложиться, постоянное изменение требований этому не способствует; во-вторых, нам неизвестны мотивы стейкхолдера, он может закидывать требованиями, чтобы решить свои задачи, но он не планирует решать твои (и вообще – насколько его задачи идут вразрез с твоими); в общем, отношения должны быть конструктивными и основанными на объективной информации – общих (стратегических) целях, данных и вот этом всем. Пытаться жонглировать противоречивыми требованиями разных сторон, потому что они «так хотят» или у них «исторически сложилось» - мертвая затея.

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

На что еще хочется обратить внимание: как правило, задачи решаются командой, понимание важности идентификации стейкхолдеров и поддержания в актуальном списке перечня СХ всей командой должно быть. То есть такая документация (по проекту) должна быть в общем доступе и возможна для дополнения всеми членами команды.

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

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

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