Личный опыт: как начинающим владельцам продукта выстроить партнёрские отношения со стейкхолдерами

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

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

Для начала кратко расскажу о тех, с кем обычно коммуницируют владельцы продукта:

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

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

Созаказчики ― те, кто могут решить часть своих бизнес-потребностей за счёт заложенной в продукте функциональности. Реализованная для созаказчиков функциональность не должна менять основную логику работы продукта.

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

Смежные команды — это команды, работающие над другими проектами или продуктами. Общение с ними важно по двум причинам:

• Ребята делают для своего продукта какой-то сервис или какую-то опцию, который или которую можно будет у них взять и переиспользовать в своём продукте. Стоит держать со смежными командами связь, чтобы они сразу заложили в свой сервис полезные для вашего продукта функции или оставили интеграционный рукав. Такой подход работает в обе стороны.

• Смежная команда и вы делаете два разных продукта, обслуживающих один бизнес или большую систему. Чтобы синхронизировать внедрение обоих продуктов, следует наладить крепкую коммуникацию и договариваться о планах разработки.

Далее в тексте все ключевые контакты владельца продукта буду называть партнёрами — само название настраивает на правильный ход мыслей в общении с этой группой коллег.

***

Про выстраивание партнёрских отношений со стейкхолдерами и поговорим дальше. Расскажу про три простые тактики, которые я получила опытным путём. Если бы мне о них рассказали на старте работы, это сберегло бы мне много нервов и ускорило бы разработку и запуск продуктов.

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

Что стоит знать о будущих партнёрах до первой встречи

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

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

Постарайтесь узнать как можно больше о том:

• какие системы поддерживают ключевые бизнес-процессы партнёра: например, системы биллинга, накопления и обработки данных, сбора обратной связи, отслеживания и фиксации событий;
• какие проблемы в этих системах существуют;
• есть ли у этих систем план модернизации и бюджет;
• есть ли планы на замену этих систем;
• какие главные боли направления или подразделения — об этом лучше узнать из первых уст у сотрудников партнёра.

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

А общение с сотрудниками будущего партнёра состоится на этапе Discovery — предварительного сбора информации. Так что нужно просто не забыть включить этот вопрос в список. Не стоит делать из этого исследования секрет: это может насторожить собеседников. Наоборот, стоит презентовать идею каждому, с кем владелец продукта захочет доверительно поговорить.

Если кто-то не захочет прямо отвечать на какие-то вопросы, это станет хорошим маркером болевых точек направления.

Как побороть недоверие партнёров

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

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

Вот инструменты, которые позволили мне приходить к такому формату работы быстрее ↓

Делаем бэклог прозрачным для партнёров

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

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

Также прозрачный бэклог сможет уберечь от лишней работы, когда команда продукта сделала то, что оказалось никому не нужным.

Фиксируем все договорённости с партнёрами

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

Никакие устные договоренности не имеют силы в будущем, если их не зафиксировать и не получить от партнёра их подтверждение.

Узнаём у партнёров, какие показатели продукта или процесса разработки для них ключевые

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

В своей работе я использовала:

• аналитические витрины данных;
• отчёты — в идеале генерируемые автоматически;
• дашборды — из готовых это Tableau и Power BI.

Чтобы не закопаться в создании инструмента надолго, стоит проговорить и зафиксировать с партнёром несколько пунктов:

• для чего ему нужен каждый показатель;
• формулу или алгоритм расчёта показателей;
• критические пороговые значения каждого показателя, которые будут сигнализировать о проблемах или об экстремальных успехах.

Когда процесс работы становится прозрачным, партнёрам проще понимать владельца продукта, доверять ему и принимать предлагаемые им следующие шаги.