Сергей Барамба – Управление стейкхолдерами. Все дело в нюансах (страница 2)
Что нам говорит 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 используя продукт, но и в нашем примере долгосрочное влияние уже можно представить:
– в оценке профессионализма руководителя проекта со стороны генерального директора;
– в уровне мотивации программиста, он работу сделал, но нет подтверждения что она принесла результат;
– в создании новой задачи по глобальной перестройки механизма визирования и выделения бюджета на следующий период.
Глава 2. Идентификация и анализ стейкхолдеров
Что необходимо руководителю проекта для управления заинтересованными сторонами
Когда речь заходит об управлении заинтересованными лицами в ИТ проекте на бумаге рецепт идеального руководителя (дальше, я буду привычно для среды управления проектами, иногда использовать сокращение «РП») выглядит просто, не сложнее рецепта блинов. Итак, нам потребуется: