Худшая ошибка начинающего продакт менеджера заключается в непонимании важности коммуникации с ключевыми лицами проекта, программы или продукта. Стейкхолдеры — это аудитории, заинтересованные в конечном результате или подверженные его влиянию, и правильно построенное общение с ними критически важно для проекта. С первого дня запуска появится масса желающих внести изменения в проект, причем как из вашей организации, так и со стороны. Каждый будет считать свои «хотелки» самыми важными и настойчиво требовать их реализации. Практика показывает, что требования стейколдеров довольно быстро перерастают в лавину, которая похоронила уже не один проект. Как правильно реагировать на «хотелки» и говорить «да» только действительно стоящим предложениям?
Чтобы ответить на этот вопрос, сначала нужно тщательно разобраться в определении, кто такие стейкхолдеры.
Здравствуйте, я — стейкхолдер
Проведём простой эксперимент, чтобы продемонстрировать трудности на тернистом пути самообучения продуктовому менеджменту. Набираем в Google запрос: «кто такой стейкхолдер», и смотрим ближайшее русскоязычное определение. Формулировку любезно предоставит Википедия:
Стейкхо́лдер (англ. stákeholder) (заинтересованная сторона, причастная сторона) — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям.
Ну что же, неплохо для начала. Более прилежный исследователь через некоторое время найдёт русскоязычный вариант Руководства к Своду знаний по управлению проектами (The Project Management Institute’s A Guide to the Project Management Body of Knowledge, PMBOK® Guide), которая описывает заинтересованное лицо следующим образом:
Заинтересованная сторона — лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта.
Свой вклад в библиотеку определений внесла и Ассоциация Великобритании по управлению проектами:
Стейкхолдерами являются все, кто заинтересован в проекте, имеет влияние на проект или находится под воздействием проекта. Управление стейкхолдерами — это систематическое выявление, анализ и планирование мероприятий по коммуникации, ведению переговоров и влиянию на стейкхолдеров.
Не сомневаемся, что из набора определений все хорошо поняли, что самый существенный момент в природе стейкхолдера — это возможность влиять на проект.
Пиэм приходит в офис, открывает почту, а там тоже пиэм
После инициирования проекта множество людей пытается оказать на него влияние — члены команды, руководство организации, представители клиентов, поставщиков, лояльные потребители и доброжелатели из профессионального сообщества.
Если унифицировать входящие просьбы, то мы поймём — все респонденты запрашивают внесение изменений в проект. Справиться с ситуацией помогут два правила:
1) Не все респонденты являются стейкхолдерами.
2) Всем говорить да, соглашаться со всеми — неправильная работа со стейкхолдерами.
Чтобы определить, кто является стейкхолдером и стоит ли уделять ему внимание, применяются разные методы, из которых следует выбрать подходящий именно для вашего случая. Это может быть распределение аудитории по степени ответственности, по степени возможной поддержки — и, конечно, по степени влияния. Для последнего используются продвинутые техники, например, матрица стейкхолдеров, которая идентифицирует заинтересованных лиц по четырём признакам:
1) Должны быть довольны;
2) Должны быть управляемы;
3) Действия аудитории должны быть зафиксированы;
4) Должны быть информированы.
Совершенно не факт, что вам понадобится применять матрицу. Скорее всего, подойдёт что-то попроще. Чтобы не терять массу времени на изучение теории, лучше обратиться к опытному эксперту.
С большой долей вероятности эксперт сразу произнесёт слово «интервью».
Радость человеческого общения
Персональная коммуникация — ключ к успешному управлению стейкхолдерами. Необходимо регулярно общаться в течение всего проекта, чтобы не тонуть в потоке поверхностных пожеланий, а получать реальные инсайты по проекту. Это первая и основная цель интервью.
А первое правило интервью — не говорить слово «интервью». Серьёзно! Иначе собеседник «закроется» и будет чувствовать неловкость. Мы на этом закончим, чтобы не уходить в культурные пласты журналистики и социологии. Как вы уже догадываетесь, правильная техника интервью — это опять-таки отдельная дисциплина.
Стейкхолдеры могут требовать вещей, которые по сути неправильны, не нужны либо устарели. Зачастую это происходит не специально. Обстоятельства меняются постоянно, и если изменения не документируются, то стейкхолдеры принимают решения, основываясь на старой информации. Поэтому вторая цель интервью — оперативно проверить актуальность данных, которыми располагают заинтересованные лица. Это может стать хорошим поводом для встречи.
Если вы расположены в том же офисе, то прекрасным способом будет чаепитие или совместный поход на обед. Если работаете удаленно — Skype вам в помощь. Узнайте, какие интересы у респондента, какие сформировались предположения и ожидания от проекта. Наконец, нужно точно знать, что может выбить его из колеи, просто с человеческой точки зрения.
Помедленнее, я записываю
Теперь мы переходим от классического проектного менеджмента в поле гибкого программирования. Scrum и Agile приобрели взрывную популярность по очевидным причинам: экономия средств и поразительная эффективность. Блестящие результаты обусловлены тем, что данные технологии являются пограничными дисциплинами, как и управление ожиданиями. Они выигрывают благодаря минимизации издержек, когда обычный разговор переводится в грамотную техническую документацию по проекту.
Поэтому каждое общение со стейкхолдером должно быть:
1) Задокументировано. Нет записи — нет драгоценного разговора. А разговор и правда может оказаться драгоценным, если пересчитать стоимость времени участников в чистые деньги.
2) Интерпретировано в соответствии с Agile методикой.
Agile требует, чтобы инсайты заинтересованных лиц были переведены в пользовательские истории. Обрисуем «крупными мазками», как это делается.
Пользовательская история — это короткое описание элемента функционала, строго с точки зрения пользователя и по принципу добавления пользовательской ценности проекту. Правила:
1) Избегать технических терминов.
2) Соблюдать приоритеты по принципу добавления ценности. То есть в первую очередь съедаем самую прибыльную часть слона. А не самую вкусную с точки зрения знатоков.
3) Типовой формат пользовательской истории: «Как <тип пользователя>, я <хочу/нуждаюсь/могу/ и т.д.> для того, чтобы <цель>».
С пользовательскими историями проблема та же, что и со всем проектным и продуктовым менеджментом. Детальные рекомендации по нужному вопросу разрослись до объёма многотомной библиотеки, и самостоятельно извлечь рациональное зерно из такого количества контента — задача крайне неблагодарная.
Можем лишь пожелать мужества отважным энтузиастам, которые пускаются в самостоятельное плавание по неизведанным океанам знаний в области продуктового менеджмента. Но, безусловно, оно того стоит.
Комментарии