Мария Шевченко — продуктовый менеджер в SoftServe и сертифицированный scrum-мастер. Работает в сфере разработки программных продуктов более четырех лет.
На лекции в UNDERHUB Мария рассказала о том, как коммуницировать со стейкхолдерами, дизайнерами и технической командой.
Записали самое интересное.

Понимание культуры и разделение ценностей компании.
Визия — зачем вы создаете продукт и какой бенефит будет у мира в будущем, когда вы его сделаете.
Дорожная карта (roadmap) — куда вы идете и на какие этапы делите дорогу к главной цели. Например, что и почему заканчиваете в этом в квартале, а что — в следующем.
Утвержденный «change request» процесс — прописанная шаг за шагом процедура доработок продукта.
Система обратной связи с коллегами и руководством относительно вашей работы и продукта.
Метрики — как именно вы определяете успех продукта. Например, удачный запуск приложения на новый рынок — это 200 покупок за первый месяц. Важно: то, что нельзя измерить, нельзя улучшить.
Словарь — главные понятия в работе. Например, MVP для кого-то — работающий код, для кого-то — кликабельный прототип, а для кого-то — первая версия вашего продукта.
Базовые принципы работы с командой

Психологическая безопасность — создавайте комфортную атмосферу в команде. Людям не должно быть страшно или тревожно на рабочем месте.
Доверие — делегируйте, обеспечивайте свободу решений и давайте право на ошибку.
Автономность и ответственность — позволяйте коллегам брать на себя конкретный участок работы, делать его самостоятельно и нести ответственность за результат.
Прозрачность — будьте открыты в отчетности, говорите о причинах увольнения коллег и не скрывайте реальное положение дел в компании.
Как коммуницировать со стейкхолдерами
Стейкхолдеры — это люди, которые влияют на принятие решений. Если их больше пяти, есть смысл целенаправленно заниматься менеджментом стейкхолдеров. Если меньше — не тратьте время.

6 советов, как улучшить эффективность команды.
Три шага в процессе стейкхолдер-менеджмента:
#1. Соберите команду и решите, кто ваши стейкхолдеры: топ-менеджмент, специалисты, которые создают продукт, пользователи. Важно вспомнить всех.
#2. Сформируйте карту стейкхолдеров — распределите их по уровню влияния на решения и интересам. Так вы увидите, кто с кем и каким образом связан. Это позволит эффективнее управлять результатом работы и ожиданиями.
#3. Обозначьте по каждому стейкхолдеру: кто этот человек, на какой он позиции, где и когда с ним коммуницировать, что конкретно для него важно — прогресс продукта, затраты или другие данные.
Зафиксируйте, где ему удобно получать информацию — по почте, в мессенджере, на скайп-звонке.

Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Как взаимодействовать с дизайнерами
Ориентируйтесь на уровень дизайнера: джуниор, мидл, сеньор. Он дает понять уровень абстрактности при постановке задач.
Например, есть проблемы с формой регистрации, из-за которых компания теряет конверсии в покупку. Сеньор понимает задачу на высоком уровне — он знает, как работает бизнес, и целенаправленно решает проблему.
Джуниору можно сказать: давай попробуем изменить положение полей, добавить/убрать валидацию.

Говорите про бизнес-цели — люди любят, когда с ними делятся.
Включайте дизайнеров в процесс на этапе создания дорожной карты. Человек, который понимает идею проекта, работает эффективнее того, кто просто получает задачи.
Давайте больше контекста — предоставляйте исследования пользователей и выгрузки интервью с ними.
Напоминайте, что дизайн нужен не для просмотров на Behance, портфолио или лайков. Сначала решаем проблему, а потом загружаем кейс в портфолио.
Поймите, кто есть кто в команде — какой набор навыков, бэкграунд и спектр интересов у каждого. Это помогает:

- лучше строить коммуникацию
- понять, как влиять на коллегу и чем его можно заинтересовать
Выбирайте правильный канал коммуникации:

- срочная проблема — подходите лично
- вопрос может подождать час — пишите в личные сообщения
- задачу нужно решить на следующий день — пишите e-mail
При постановке задачи говорите, что вам нужно получить в финале, а не то, как к этому прийти. Не рассказывайте, как нужно получить результат, — часто у технической команды есть возможность дать решение намного быстрее, чем вы думаете.
Давайте доказательства. Объясняйте, для чего нужно решить конкретную задачу, что сказал пользователь и что показала аналитика. Готовьте аргументацию заранее.
Защищайте от топ-менеджмента. Часто люди, которые классно пишут код — это люди, которые просто классно пишут код. Они не хотят приоритизировать, принимать решения и заниматься менеджментом. Избавьте их от этого.

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


Хотите получать дайджест статей?

