Как вы работаете с разногласиями между стейкхолдерами?

Как я работаю с разногласиями между стейкхолдерами

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

Принцип 1: Слушание без защиты

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

Что я делаю:

1. Организую встречу с конфликтующими сторонами

   • Отдельно с каждой (1-on-1)
   • Потом вместе, если есть смысл

2. Задаю открытые вопросы:

   • "Объясни мне твой point of view"
   • "Какие данные тебя убедили?"
   • "Какие риски ты видишь?"
   • "Что может изменить твоё мнение?"

3. Слушаю активно:

   • Пишу заметки
   • Не перебиваю
   • Показываю, что слышу

Пример: CEO: "Нужно добавить эту фичу, клиент просит" CTO: "Это невозможно сейчас, у нас нет capacity, система не масштабируется"

Вместо "давайте договоримся":

• Я спрашиваю CEO: какой именно клиент? сколько платит? какой был SLA?
• Я спрашиваю CTO: что нужно для масштабирования? сколько времени? какой budget?

Принцип 2: Данные — источник истины

Разногласия часто происходят из-за разных предположений. Мой job — собрать данные.

Типичное разногласие:

Дизайнер: "Нам нужен большой красный кнопок, он привлечет внимание" Аналитик: "Данные показывают, что люди не кликают на красные кнопки, они мешают"

Мой процесс:

1. Запросить конкретные данные

   • Какие точно данные? (A/B тест? analytics?)
   • В каком контексте? (на какой странице? какой сегмент?)
   • Когда это было? (месяц назад? 2 года назад?)

2. Пробить дыры в предположениях

   • "А может, красный кнопок работает для другого сегмента?"
   • "Может, размер кнопка важнее, чем цвет?"
   • "Может, это было правдой, но рынок изменился?"

3. Если данных нет → запустить исследование

   • A/B тест на неделю
   • User interview (5-10 пользователей)
   • Analytics check

Результат:

• Решение основано на фактах, не на мнении
• Все согласны, потому что видят данные

Принцип 3: Ищу win-win, не компромисс

Компромисс = никто доволен (A уступил, B уступил) Win-win = оба выиграли

Пример разногласия:

PM: "Нужно добавить экспорт в CSV, клиенты просят" Engineer: "Это даст нам +20% load на БД, система упадет"

Компромисс: "Добавим экспорт, но только для top 10% пользователей"

• PM: недоволен (клиенты все еще просят)
• Engineer: недоволен (всё равно будет нагрузка)

Win-win:

• Я спрашиваю Engineer: "Что нам нужно, чтобы это работало?"
• Engineer: "Queue system для асинхронного экспорта, занимает 2 недели"
• Я спрашиваю PM: "Это важнее чем [другая фича]?"
• PM: "Да, для retention это важнее"
• Решение: делаем queue system (2 недели), потом добавляем экспорт
• Результат: Engineer решает техдолг, PM решает problem пользователя, все счастливы

Процесс разрешения разногласия (RICE + Align)

Шаг 1: Слушание (30 мин)

• Встреча 1-on-1 с каждым
• Документирую их позицию
• Вопросы: почему? какие данные? что может изменить мнение?

Шаг 2: Анализ (24-48 часов)

• Собираю данные (metrics, research, feedback)
• Спрашиваю других людей (есть ли у них похожие проблемы?)
• Анализирую options (может быть 3-й вариант?)

Шаг 3: Встреча с обеими сторонами (30 мин)

• Объясняю, что я услышал
• Представляю данные
• Предлагаю options:
  • Option A (позиция 1)
  • Option B (позиция 2)
  • Option C (my win-win)
  • Option D (hybrid)

Шаг 4: Решение

• Если все согласны → отлично
• Если нет → принимаю решение, как PM
• Документирую (почему мы выбрали эту позицию)

Шаг 5: Движение вперед

• Чёткая next action
• Кто за что отвечает
• Checkpoints для review

Когда я решаю разногласие как PM

В некоторых случаях я принимаю решение, даже если не все согласны:

Случай 1: Time-sensitive decision

• Это нужно решить сейчас
• Все поняли данные
• Риск инaction > риск решения → Я решаю

Случай 2: Стратегическое направление

• Это определяет будущее продукта
• Нужна одна позиция, не множество → Я решаю

Случай 3: Я PM, я ответственен

• Я получу feedback от рынка
• Я отвечу за результаты → Я решаю

Но я объясняю:

• Почему я выбрал этот вариант
• Какие риски я вижу
• Как мы будем измерять успех
• Что изменит мнение в будущем

Типичные разногласия, которые я встречаю

1. Лозунг vs Функциональность

• Design: "Нам нужно 20 шагов для идеального UX"
• Business: "Конкуренты делают в 3 шага, нам нужно быстрее"
• Моё решение: оба правы. Нужен progressive disclosure (сложное скрыто, базовое на виду)

2. Масштабируемость vs Speed

• Engineer: "Нам нужна архитектура, которая выдержит 10M пользователей"
• Startup: "У нас 10k пользователей, нам нужен launch через 2 недели"
• Моё решение: делаем v1 быстро (2 недели), v2 масштабируемо (месяц)

3. Один feature vs Many features

• Product: "Давайте один фичу, но идеально"
• Marketing: "Давайте много фич, показывать во всех презентациях"
• Моё решение: один core feature (perfect), + 3 supporting features (good)

Как я предотвращаю разногласия

Профилактика лучше, чем лечение:

1. Регулярная синхронизация — встречи 1-2 раза в неделю с key stakeholders
2. Прозрачная roadmap — все видят приоритеты и объяснение
3. Shared metrics — все смотрят на одни KPI
4. Decision log — все понимают, почему выбрали это
5. Ранние интервью — включаю stakeholders в research

Итог

Разногласия — это нормально. Они показывают, что люди думают и заботятся о продукте. Мой job как PM:

• Слушать все стороны без bias
• Собрать данные
• Найти win-win
• Если нет — принять решение и двигаться вперед
• Измерить результаты

Лучший PM не тот, кто избегает конфликта, а тот, кто разрешает его быстро и справедливо.