Почему продакт-менеджеру стоит полюбить конфликты: кейс команды «Яндекс.Трекер»

Мы пообщались с Любой Карповой, руководителем сервисов для командной работы «Яндекс.Трекер», «Яндекс.Вики» и «Яндекс.Формы», и преподавателем курса «Продуктовый лидер», чтобы разобраться с видами конфликтов в продуктовых командах и методами их решения.

Продакт-менеджер должен уметь говорить «нет», даже когда команда предлагает «гениальные идеи». Иногда нет смысла их реализовывать по двум причинам:

Задача продакта «продать» команде «фичу», которая улучшит продукт как минимум по одному из двух пунктов. Но команда не всегда согласна с его решением. В итоге менеджер обижается, что идею не оценили. Это приводит к конфликту.

Конфликт в команде — проблема продакта. Значит ли, что конфликт — это плохо? Нет. Потому что конструктивный конфликт помогает найти лучшее решение.

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

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

Каждое подразделение ставит цели на полугодие и ближайший месяц. Команда разработки совместно с заказчиком оценивают риски — публично проговаривают «что может пойти не так».

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

Каждый квартал проводим большие ретроспективы — анализ проделанной работы. В ретроспективах участвуют: команда разработки, смежные команды и заказчик.

Регулярные ретроспективы позволяют решить существующие конфликты и предотвратить новые.

Команды разработки и команды менеджеров дополнительно проводят ретроспективы внутри локальных скрамов раз в две недели.

На перфоманс ревью, ретроспективах и внутри скрам-команды работают с целями и метриками их достижения.

У каждого есть свой TODO. По итогам периода участники отчитываются о результатах и определяют, что пошло хорошо, а что не очень. Если ответственный с чем-то не справился, объясняет почему.

С помощью оценки спринта, полугодия или квартала выявляем:

Каждую часть разбираем по пунктам.

Внутри нашего проекта можно выделить три типа конфликтов.

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

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

Дать подробное объяснение и ответ на вопрос: «почему мы так решили». Создать общий контекст. Можно удалённо, через рабочий чат, если это не сработает — пригласить на ретроспективу. Такой подход снимет непонимание и страх того, что могут всё «сломать».

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

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

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

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

Если конфликт становится системой — повторяется из раза в раз, тогда есть смысл вмешаться.

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

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

Не всегда можно понять идею, которая описана на словах. Если речь идёт о продукте, лучше написать фрагмент кода и показать, о чём речь. Или как минимум, визуализировать ситуацию.

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

Формулируем проблему: клиенты говорят, что продукт плохой.

Идём и опрашиваем ключевых стейкхолдеров. С помощью «Метода пяти почему» выясняем причину.

Каждый стейкхолдер даёт свое отражение реальности, своё дерево причин.

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

Чтобы решить конфликт, с каждым нужно поговорить отдельно. Собрать причины, построить деревья причин: «почему продукт плохой и темпы роста низкие». Оформить деревья в лес. Взять «лес» и пройти по всем стейкхолдерам ещё раз, показать каждому его оформленное видение и видение коллег.

И только после двух кругов организовать совместную сессию.

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

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

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

Решать эту проблему продакт-менеджеру. Компромисс — зло для бизнеса. Он снижает градус конфликта, но не приводит к эффективному решению.

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

Конфликтуйте с пользой.

Потому в крупных компаниях работают системы синхронизации целей и процессов, чтобы максимально приблизить представление о точке «Б» к одному у всех сотрудников.

Каждый воспринимает информацию по-своему. Если попросить десять человек описать, что они представляют, когда слышат «собачка», можно получить десять разных вариантов: от рыжего шпица до застежки на куртке.

Задача продакт-менеджера — создавать общий контекст для всех участников команды: откуда мы движемся, куда и как туда доберемся.

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

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

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