Всем привет! Меня зовут Тирайр, я процессный аналитик в Спортмастер Лаб и менеджер проекта Со-Общест.во, комьюнити людей, стремящихся развиваться в области менеджмента, бизнес- и системного анализа Недавно мы запустили в нашем канале рубрику "Открытый микрофон", где каждый желающий может выступить в прямом эфире с темой, которую он изучил или отработал на практике. Для спикера это отличная возможность прокачать личный бренд и навык презентации. Ещё один бонус - возможность получить обратную связь от экспертов, которых мы подбираем самостоятельно под каждую тему.  Если вам есть о чём рассказать, вы давно увлечены или изучили какую-то тему, просто напишите нам и до встречи в прямом эфире!  Первый выпуск был посвящён стейкхолдерам и взаимодействию с ними. Делимся записью выпуска и комментариями от экспертов. Старший процессный аналитик в Спортмастер Лаб Системный аналитик в СКБ КонтурОпыт работы в IT более 16 лет По моему мнению, очень актуальная тема. Уметь выявлять стейкхолдеров и работать с ними – это обязательное умение для аналитика. Очень понравилась структура доклада и то, как спикер явно проговаривал то, о чем будет говорить дальше.  К теории вопросов нет. Все четко, хоть и капитанство. Информации достаточно, чтобы понять, что за инструменты, и покопать их глубже, если хочется. Очень понравилось, что спикер явно проговорил, что стейкхолдеры это не только пользователи, а все те, на кого влияет продукт. В моей практике частенько приходится объяснять молодым аналитикам, что надо смотреть шире. Хорошо, что отметил, что матрицу стейкхолдеров можно расширять и уменьшать под свои нужды. Иногда сталкиваюсь, что люди принимают инструмент как есть и не пытаются думать, как его удобнее использовать, и мы видим, что микроскопом заколачивают гвозди. Вероятно, во мне говорит опыт продуктовой разработки, но, когда слушал про матрицу RACI, постоянно хотелось спикеру задать вопрос:  «Дружище, зачем так сложно?»  Все дело в том, что я не могу достучаться до конкретного пользователя, да и конкретного заказчика у меня обычно не бывает. У меня есть среднестатистический бухгалтер, юрист, директор. Иногда мои стейкхолдеры – это целые продукты или контролирующие органы. Такова специфика продуктовой разработки. Если мне повезет, может быть конкретный менеджер или аналитик другого продукта, но даже в этом случае мне не нужен такой подробный список. Это лишняя трата времени. Я бы начинал со списка и как наш продукт на них отразится. Может, дальше уже добавлял доп. колонки по необходимости. Матрицы влияния и отношения мне сложно использовать. Вот знаю я, что у ПФР влияние и воздействие высокое, а отношение – никакое. Но что я с этим могу сделать? С другой стороны, если говорить о менеджере соседнего продукта, то тут есть шанс наладить с ним дружбу. Но буду ли я строить ради него матрицу? Вряд ли. В докладе мне не хватило личного опыта спикера. Было бы классно увидеть, как спикер мог бы  это применить в своем прошлом. Лично у меня, когда читаю какую-нибудь книгу, часто появляются вьетнамские флешбеки, где я пытаюсь наложить инструмент на предыдущий опыт и пытаюсь понять, насколько бы он подошел.  Заместитель директора по ИТ в Спортмастер лабОпыт работы ИТ архитектором более 20 лет Про тему доклада Доклад получился скорее про то, как выявлять и инвентаризировать стейкхолдеров и делить их на группы. В этом смысле, как именно взаимодействовать рассказано немного. Оно в целом понятно почему – на таком уровне абстракции их сложно дать.  Про подход работы со стейхолдерами С одной стороны, этот подход имеет существенные плюсы, например, он позволяет уйти от ловушек стандартных ролей типа «Заказчик», «Спонсор» «Product Owner» и т. д., на которые навешиваются функции, которые конкретный человек в конкретном проекте не в состоянии (не может/не хочет) выполнить. С другой стороны, в таком виде подход становится слишком верхнеуровневым и абстрактным. Т.е., он формально правильный, но в деятельности никак не помогает. Этим страдают все стандарты энциклопедии в стиле *BOOK. Вот классическая цитата в таком стиле из рекомендаций по Data Governance. Замените “Data Governance” на что угодно еще, и вы получите очень правильный, но абсолютно бесполезный план (начать, продолжить, закончить). На самом деле, стейкхолдеры нас интересуют всего в 2-х аспектах (Матрица влияния/воздействия скорее про это): стейкхолдеры принимают/влияют на наши решения, которые мы принимаем (а это значит, что они могут остановить/перенаправить проект и т.д.); наши решения влияют на стейкхолдеров (у них может что-то сломаться/починиться  из-за нас). Конечно, каждая ситуация уникальна, но хорошей практикой является все-таки выделять роли и с каждой ролью работать отдельно. При этом, хорошо, если матрица ролей составлена относительно важных процессов для команды проекта. Например, в разрезе полномочий и с какими правами (эксклюзивно решает, имеет право вето или просто как-то влияет): кто инициирует процесс (старта проекта/команды); кто решает вопрос финансирования; кто имеет влияние на backlog; кто принимает готовый результат; кто устанавливает сроки; кто может выделить необходимый ресурс (людей, оборудование); и т.д. И тогда уже для определённых групп людей можно проработать конкретные рекомендации по взаимодействию. Вот тут, например, есть мои старые рекомендации по работе с группой ролей, которые могут ставить задачи и ожидают их исполнения. Еще полезно посмотреть про управления ожиданиями и восприятием.    Еще важно помнить, что Stakeholder – это очень грубое и проектно- или продуктоцентричное упрощение жизни.  Реально стейкхолдеры чаще всего заинтересованы в окружении продукта/проекта, а не в самом продукте.  Про управление требованиями Слово «требование» тоже очень плохой термин. Он употребляется в 2-х разных смыслах: в широком и узком. Они часто путаются.  Про предлагаемые артефакты Список стейкхолдеров мы используем. В частности, каждый FAST старается поддерживать в актуальном состоянии матрицу коммуникаций. Матрица RACI. По моему опыту не работает совсем (write only документ). Матрица влияние-воздействие. Полезна, но подходит скорее для того, чтобы погрузиться в тему, а не для того, чтобы использовать каждый день. Матрица влияние-отношение. Это про политику в большой организации. Очень тонкая и скользкая тема и гораздо более сложная. План коммуникаций. Мне кажется, что это подпорка для начинающих. В целом на уровне здравого смысла делается и так грамотным менеджером. Луковичная модель хорошо иллюстрирует и довольно полно показывает группы стейкхолдеров, но она не отражает значимость стейкхолдеров для проекта/продукта (кажется, что в группе «Поставка решения» находятся самые важные стейкхолдеры – это не так); подходит скорее для того, чтобы погрузиться в тему, а не для того, чтобы использовать каждый день.  Про заказную разработку Работал в заказной разработке 15 лет (Custis), обычно все это решается специальной ролью (account manager), который уже сам это не очень технологизированно ведет в своей записной книжке. Важно это становится в случае, если включается цикл вторичных продаж. Тогда все контакты мыслятся как Lead-ы и ведутся в CRM. Директор по технологиям и поддержке ОМНИ-процессов розничной сети СпортмастерБолее 10 лет опыта во внедрении изменений на стороне бизнеса Хотел бы отметить, что довольно молодой специалист постарался изучить тему довольно глубоко, и классно, что примерил на себя докладчика. Это круто, молодец. Было несколько хороших инструментов для структуры работы с стейкхолдерами, должны помочь новичкам.Несколько буллитов которые хотел отметить:  Сам выступающий отмечал, что такой объем инструментария не используется, хотелось бы услышать, а что он выделяет из инструментов или комбинацию инструментов в своей реальной работе. Почему именно они и чем применимы у нас в компании. Важно понимать, что сами стейкхолдеры меняют не так часто меняют ТЗ , они не понимают образ результата. Главная задача – максимально раскрывать образ результата в каждой встрече, помочь самим заказчикам верно сформулировать и образ результата, и путь к его достижению. Считаю существенной проблемой при взаимодействии такого рода – наличие нескольких важных софт-скилов – нацеленность на результат и эффективные коммуникации. Очень сложно молодым ребятам сразу вступать в контакт с разными сотрудниками внутри иерархической структуры. Даже несмотря на то, что сами инструменты есть. В этой связи возможно подсветить и важность развития таких скилов, и возможные инсайты (пример с животными был интересным). Я бы посоветовал проработать 2 момента: готовиться ко встрече с ключевыми стейкхолдерами – в каком он контексте сейчас, какие цели задачи его интересуют, какие буллиты основные, а какими стоит пренебречь. Как правило, такие сотрудники крайне заняты, получать постоянную ОС не получится – круто сразу на встрече запросить лицо, его замещающее по этому вопросу, и что именно возможно обсудить. Так и материалов, и контекста у сотрудника будет намного больше, в том числе и для понимания конечного образа результата.  Ведущий бизнес-аналитик в EPAM SystemsОпыт работы в IT и бизнес-анализе более 15 лет Главное – Дима сделал работу и попытался понять, где можно применить те или иные артефакты. Я вспомнил себя, когда мне было всё это в новинку и когда я не знал, как это применять. И я вижу, что Дима уже прошёл тот момент, когда он не знает, зачем артефакты нужны, он хорошо понимает, что ему нужен список стейкхолдеров, к остальным артефактам присматривается. Дальше Диме поможет только опыт проектов и применение знаний на практике. Почему – потому что я со многими аналитиками и менеджерами работал, умеющими эффективно строить коммуникацию, и конкретный набор артефактов и методов у каждого свой, тут нет какого-то идеала, надо просто искать то, что поможет именно тебе. Теперь по видео: Нельзя зачитывать презентацию, люди их и сами прочитают – думаю, тут особо пояснений не надо, тут тоже нужен опыт. Стейкхолдеры – не было сразу упомянуто про спонсоров и их важность, вообще не было особых попыток к разбиению по матрицам добавить то, на что мы 100% обращаем внимание в проекте – понимание формальной и неформальной иерархии. Было много сказано про списки стейкхолдеров, про возможные колонки, но не было попытки осмыслить, что колонки должны добавляться и убираться на основании целей, ибо список стейкхолдеров должен выполнять какую-то задачу. Зачем-то на матрице разбиения стейкхолдеров интерес был заменен на влияние, притом сам Дима периодически называл то так, то так (это уже мелочи). Меня удивило сообщение, что не надо информировать рядовых исполнителей о стратегических целях проекта. Дима забыл или не подумал рассказать о том, что аналитик может воздействовать на стейкхолдеров и растить себе союзников, и открытость здесь сильно помогает, по крайней мере, в заказной разработке, когда ты показываешь, что у тебя четкие цели и приоритеты помочь, и ты не играешь в игры. Нужно ли тебе работать в организации, где есть явные враги изменений? Для каждого человека есть персональные триггеры, при срабатывании которых надо заставить себя покинуть проект/компанию. При рассказе про план коммуникаций не было попытки рассказать, зачем он нужен. Пы.Сы. Я не помню, говорил ли я на встрече той нашей про устав проекта, но есть и такой артефакт, который помогает четко прописать участников, их ответственность, цели, задачи, а также прописать управляющий совет, который будет крайней точкой эскалации конфликтов – плюс прописать стандартные пути решения конфликтов. Итого – устав проекта берёт в себя частично три артефакта, про которые говорил Дима, и привносит к этому много полезного. Руководитель команды аналитиков бизнес-процессов в СМ Лаб в домене ОМНИЦК бизнес-анализа в компании, более 10 лет опыта в области бизнес-анализа Презентация составлена довольно структурированно, и подача не вызывает вопросов, но не очень понятно, кто является целевой аудиторией, в зависимости от этого стоит тем или иным образом выстраивать презентацию. При определении кто такие стейкхолдеры, мне кажется не очень удачным пример с ремонтом, ценности от него не очень много, лучше было бы привести пример из профессиональной области – можно взять процессы более общего характера (абстрактные), чтобы они были понятны не только узкому кругу коллег. Про работу с требованиями СХ очень мало инфы. Дима правильно говорит о том, что их может быть много и они могут постоянно давать требования, а эти требования постоянно могут меняться. У любого здравомыслящего человека сразу возникает вопрос: «И что с этим делать?». Я на своей практике сталкивался с ситуацией, когда требования менялись быстрее, чем аналитик успевал их удовлетворять. Есть отличный пример на эту тему – сказка «О рыбаке и рыбке» у А.С. Пушкина. Это, на мой взгляд, проблема. В презентации периодически проскакивает про то, что нужно поддерживать «удовлетворенность» стейкхолдеров, но не сказано, что иногда нужно уметь сказать «НЕТ» - это супер важный навык, потому что: во-первых, у нас есть свои цели, свои сроки и свои ресурсы, в которые нам надо уложиться, постоянное изменение требований этому не способствует; во-вторых, нам неизвестны мотивы стейкхолдера, он может закидывать требованиями, чтобы решить свои задачи, но он не планирует решать твои (и вообще – насколько его задачи идут вразрез с твоими); в общем, отношения должны быть конструктивными и основанными на объективной информации – общих (стратегических) целях, данных и вот этом всем. Пытаться жонглировать противоречивыми требованиями разных сторон, потому что они «так хотят» или у них «исторически сложилось» - мертвая затея. К вопросу о том, где искать стейкхолдеров, есть пара дополнений: если мы работаем в рамках проекта, то можно еще посмотреть архив документации (если она ведется), поискать там схожие проекты и посмотреть, кого выявили там, это может быть источником дополнительных стейкхолдеров. Еще – Дима пренебрегает таким важным источником как опыт, это может быть свой опыт (вообще самое первое, что должно приходить в голову при решении почти любой задачи) и чужой (до него, как правило, проще и быстрее дотянуться, чем до всего остального на слайде). На что еще хочется обратить внимание: как правило, задачи решаются командой, понимание важности идентификации стейкхолдеров и поддержания в актуальном списке перечня СХ всей командой должно быть. То есть такая документация (по проекту) должна быть в общем доступе и возможна для дополнения всеми членами команды. В целом не хватает командного аспекта работы с стейкхолдерами (ты же не один в поле воин), выглядит как будто работа со стейкхолдерами - это задача бизнес-аналитика, а на самом деле это даже в большей степени задача проджект менеджера. А вот личные детали в общедоступном списке (если его принято вести) не очень, может быть, хорошая идея, да и вообще, с такими вещами надо быть очень осторожным, никогда не знаешь, к каким последствиям это может привести. В заключение – довольно мало прикладных инструментов / хинтов / скиллов взаимодействия (конструктивного – это важно) со стейкхолдерами, ну то есть не энциклопедические знания, а свой опыт – это всегда более ценно, чем то, что и так можно найти в интернете.  Процессный аналитик