Работа со стейкхолдерами
Стейкхолдер программного продукта — это любое лицо или организация, которое имеет интерес или влияние на разработку, запуск или использование программного продукта.
Что это за этап
Управление ожиданиями стейкхолдеров является критически важной задачей для успешного развития продукта. Оно играет ключевую роль в обеспечении того, чтобы продукт обладал востребованными функциями и характеристиками, что напрямую влияет на его рыночный успех и конкурентоспособность.
Эффективное управление ожиданиями помогает снизить риски изменения продукта на поздних стадиях разработки. Это позволяет экономить ресурсы и время, гарантируя своевременное завершение проекта. Качественная работа со стейкхолдерами определяет перспективы продукта: если стейкхолдер является инвестором, он будет продолжать инвестировать, доверяя команде; если это клиент, он будет дольше пользоваться продуктом, оставаясь довольным его возможностями.
Постоянное общение и обсуждение ожиданий формируют четкое представление о приоритетах и потребностях всех вовлеченных сторон. Это ведет к более эффективному принятию решений, делает продукт более конкурентоспособным и положительно влияет на его долгосрочный успех.
Ключевым объектом управления в этапе работы со стейкхолдерами является взаимодействие со стейкхолдером и его ожидания.
Как следствие, важнейшим артефактом является список стейкхолдеров и формат взаимодействия с ними. Как итог список стейкхолдеров должен быть:
- определен,
- согласован с Менеджером проекта, Руководителем разработки направления и Руководителем направления.
- зафиксирован в общем доступе для команды
- определен степень влияния каждого из них.
Стейкхолдеры должны знать друг о друге. При необходимости ожидания от стейкхолдеров синхронизируются по инициативе любого из них или команды производства.
Сбор информации со стейкхолдеров — это набор процессов и правил, с помощью которых разные заинтересованные лица могут приносить запрос в команду разработки. Процесс работы с каждым стейкхолдером может иметь свой отдельный «интерфейс», разную периодичность, разный цикл обработки этого потока задач.
Взаимодействие со стейкхолдерами не сводиться только к сбору «пожеланий» к изменению продукта, это комплексная двухсторонняя коммуникация направленная на достижение общих и отдельных целей.
Различные виды коммуникаций:
- Функциональные запросы: Обсуждение и внедрение необходимых изменений или добавление новой функциональности для удовлетворения бизнес-требований.
- Инциденты, проблемы: Быстрое реагирование и управление возникающими проблемами, в частности по работе продукта у клиента, а также разработка плана по их эффективному решению и предотвращению в будущем.
- Инсайты с рынка: Внедрение обратной связи от рынка и учет рыночных трендов для корректировки стратегических и тактических действий.
- Процессные предложения: Анализ и оптимизация существующих процессов, а также предложение и внедрение новых подходов для повышения эффективности.
- Стратегические и другие инициативы: Определение и проработка как долгосрочных, так и краткосрочных целей и инициатив, согласование их приоритетов и ресурсов.
- Запрос на аналитику, данные, графики и отчеты: Сбор, анализ и представление данных для поддержки принятия обоснованных решений.
- Административные и орг вопросы: Решение вопросов, связанных с организацией работы команды, управлением ресурсами и координацией действий внутри проекта.
Организация процесса
- Определение стейкхолдеров.
- Составить исчерпывающий список стейкхолдеров. Для проверки смотри список вероятных стейкхолдеров продукта: Типология и примеры стейкхолдеров.
- Зафиксировать ожидания и интересы стейкхолдеров. Проанализировать процессы в которых стейкхолдеру взаимодействует с продуктом.
- Приоритизация стейхколдеров, на основе их влияния, заинтересованности, наличии ресурсов, эффекта синергии от взаимодействия.
- Установление «контракта» и канала работы с каждым конкретным типом стейкхолдеров:
- Диалог с представителем стейкхолдера о типах запросов, которые могут поступать от них.
- Обсуждение формата запросов: канал занесения, объем минимальной необходимой информации.
- Договоренности про сроки реакции и формат поступления этой обратной связи.
- Определение ответственных с обоих сторон за взаимодействие. В том числе в кого обращаться, если что-то сломалось или другой форс-мажор.
- Фиксация результатов договоренностей в доступном обеим сторонам месте.
- Создание необходимых для взаимодействия инструментов, например формы для сбора обращений, доски для отслеживания статусов, точки коммуникаций.
- Фиксация «Карты стейкхолдеров"*, включая список, приоритет, контракты в доступном для команды месте.
*Подразумевается не конкретный фреймворк, а любой удобный команде метод. - Организовать процесс пересмотра списка стейкхолдеров, приоритетов и каналов коммуникации.
Что на входе
Заданный формат, в котором:
- Обязательно:
- Описание запроса.
- Источник запроса и координаты для связи с ним.
Если это пользователь, клиент или потенциальный клиент — его реквизиты для связи и уточнения запроса. Если это член команды, менеджер по продажам, партнер — их контакты. - Критичность, риски, в том числе сроки (при наличии).
- Мотивация.
- Желательно:
- Предположение о влиянии на цель продукта или компании.
- Объект влияния: пользователь, команда, процесс и т.д..
- Ожидаемый образ результата.
- Наличие артефактов и сами артефакты.
Сам канал занесения информации. Может быть разным в зависимости от типа стейкхолдера.
Сроки реакции на запрос. Могут отличаться в зависимости от типа стейкхолдера.
Возможность оставить запрос есть в любой момент времени.
Содержание этапа
- Штатная работа по сбору запросов.
- Уточнение запросов. В том числе: артефакты, мотивация и влияние на цель / результат.
- Обратная связь стейкхолдеру о решении по его запросу в рамках «контракта».
- Информация о состоянии запроса доступна в любой момент времени (если не договорились о другом).
- Замер удовлетворенности процессом работы с запросами (стейкхолдер может быть недоволен тем, что его задачи не берутся, но если он понимает, почему так — это ок).
В зависимости от этапа жизненного цикла программного продукта критерии принесения задач меняются (количество запрашиваемых данных, скорость реакции и т.д.). На ранних стадиях ЖЦ продукта допускается более свободные формулировки, но в тоже время быстрее скорость взаимодействия. Это обосновывается тем, что продукт скорее всего снимает первые «сливки», плотнее взаимодействует с клиентами как следствие более толерантен к риску. В то время как зрелые продукты на зрелых рынках требуют более взвешенных решений.
Результат этапа
- Карта стейкхолдеров.
- Выстроенный процесс работы с каждым стейкхолдером.
- Правила занесения запросов описаны и доступны каждому члену команды.
- В результате процесса обеспечивается полнота запроса с уточнениями, необходимыми для принятия решения на этапе Сортировка. То есть запрос содержит в себе как минимум:
-
- Обязательно:
- Описание запроса.
- Источник запроса и координаты для связи с ним.
Если это пользователь, клиент или потенциальный клиент — его реквизиты для связи и уточнения запроса. Если это член команды, менеджер по продажам, партнер — их контакты. - Критичность, риски, в том числе сроки (при наличии).
- Мотивация.
- Предположение о влиянии на цель продукта или компании.
- Объект влияния: пользователь, команда, процесс и т.д..
- Артефакты, при их наличии.
- Желательно:
- Ожидаемый образ результата.
- Обязательно:
Индикаторы качества
Как понять, что этап выстроен хорошо или плохо.
Не выстроена работа со стейкхолдером
- Ни разу не проводился диалог по работе с конкретным стейкхолдером.
- Стейкхолдер не понимает, как занести задачу в команду разработки. Для него процесс прохождения его запроса не прозрачен.
Рекомендация: Составить карту стейкхолдеров и контракты взаимодействия.
Низкая вовлечённость стейкхолдеров
Стейкхолдеры не приходят с предложениями по развитию продукта и не дают фидбек об изменениях в продукте.
- Может быть следствием других проблем, в частности системное невыполнение договорённостей.
- Незнание стейкхолдеров о своей возможности влиять на развитие продукта.
- Ключевые стейкхолдеры не участвуют в планировании исследований и разработки.
Непонимание бизнес-целей и неверно сформированные ожидания
- Все запросы стейкхолдера отклоняются.
Рекомендация: Нужно корректировать понимание целей и стратегии развития продукта. При этом непонимание может быть как со стороны стейкхолдера, так и со стороны команды.
Так же возможно, что неверно классифицирован/приоритезирован стейкхолдер и стоит пересмотреть взаимодействие с ним.
Системное невыполнение договорённостей
- Стейкхолдер перестал приносить запросы в команду. Например, за последние три месяца не занес ни одного, хотя до этого регулярно заносил.
- Среди стейкхолдеров развивается апатия и «выученная беспомощность», потому что «какой смысл туда ходить и говорить».
Рекомендация: Важно определить, что именно вызывает невыполнение — проблемы с коммуникацией, конфликтующие приоритеты или что-то еще. И уже целенаправленно вносить изменения.
Формат коммуникации не удовлетворяет одну из сторон
- Запросы систематически приносятся не в заданном формате.
- Формат запросов и контракт в целом очень вольно интерпретируются и исполняются любой из сторон.
- На уточнение запросу уходит много времени у ответственного (начинают страдать другие обязанности).
- Стейкхолдер приносит запросы напрямую в аналитика, разработчика, продуктового дизайнера (и это не соответствует «контракту»).
- Менеджер разработки с удивлением обнаруживает, что команда разработки занята задачами, которые прошли мимо него.
- Стейкхолдер говорит: «я нашёл другие более рабочие методы решения задач».
- Стейкхолдер заносит много срочных задач (и для этого нет внешних объективных обстоятельств).
Рекомендация: Пересмотреть контракт взаимодействия. Скорректировать ожидания.
Плохо работают инструменты ОС по запросам
- Не знает статус его запроса и это создает проблемы в его работе.
- Не получает обратной связи по своим запросам и не понимает что с ними проиходит дальше.
- Жалобы, что «разработка не слышит», «не понятно чем они занимаются», «они что-то делают, а мы уж тут выкручиваемся как можем»
Рекомендация: Уточнить, какие именно инструменты являются проблематичными и какова природа проблем — техническая неисправность, стейкхолдер некорректно использует инструменты, либо некачественное выполнение контракта со стороны ответственного в продукте.
Процесс не контролируется и не развивается
- Нет актуальных данных об удовлетворённости стейкхолдерами результатами взаимодействия.
- Частая эскалация проблем.
- Удовлетворенность по процессы работы с запросами:
- низкая (менее 3,8 по 5-балльной шкале, если замер производится с применением шкалы),
- негативная динамика от замера к замеру,
Рекомендация: Найти ответственного за работу со стейкхолдерами и выстроить повторяющийся процесс итеративных улучшений.
Непрозрачность процесса для стейкхолдера
Стейкхолдер не понимает:
- почему какие-то запросы идут дальше в работу, а какие-то нет.
- как приоритизируются задачи и запросы.
Рекомендация: Работать над прозрачностью сквозных процессов и всего ValueStream.
Человеческий фактор
- Ответственный со стороны разработки/стейкхолдера демотивирован, раздражен, негативит при работе с конкретным стейкхолдером.
Рекомендация: Вмешательство руководителя, фасилитатора. Изучение проблемы, как следствие в качестве решение может быть: изменение формата взаимодействия, изменение ответственных, личное развитие сотрудника софт-скиллам.
Инструменты для работы
- Инструменты анкетирования для сбора запросов и замера удовлетворённости взаимодействия.
Стафф, google form или typeform. - Таск-треккеры для отслеживания статусов запросов.
Доски и issues в YouTrack или Jira, доски в маттермост, где стейкхолдер может самостоятельно посмотреть статус запроса.- Уведомления об изменении статуса на почту.
- Whiteboards: Miro, Holst, Контур.Доски
- Тестовые редакторы для фиксации контракта.
Confluence, Контур.Диск, Google-доки - Инструменты коммуникации
- Чат в тг, маттермост, электронная почта.
- Регулярные и инцидентные встречи
- Контур.Толк, Офлайн-встречи
- Карта стейкхолдеров