В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего case-study.

Ситуация

Аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного неба - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы: 

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

• Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.

• Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.

Промежуточный итог

• Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.

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

• И результатом всего этого стала демотивация команды – всё по классике.
  

Как решали

Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:

• Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.

• Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.

• Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.

Итак, первый подход

• Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.

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

• Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.

• Проблемы с бэклогом пытались решить через привитие нашей культуры разработки. Но и это не увенчалось успехом.

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

• На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).

• Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.

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

Как мы решили проблему микроменеджмента? А никак. ? Она рассосалась сама, на нас просто обиделся менеджер продукта и сократил общение до необходимого минимума.

Но всё описанное выше было возможно по ряду причин, на которые я ссылался раньше:

? У нашей команды был огромный кредит доверия со стороны спонсора проекта: выше я указал про успешное долгосрочное сотрудничество.

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

? Мы не сказали нет напрямую, мы сказали это через спонсора проекта.

И самый-самый итог руководителя продукта уволили через год. На мой вопрос почему не раньше я получил ответ – контракт, до истечения срока его нельзя было уволить. Первый квартал он адаптировался, полгода показывал, что умеет и ещё квартал подводили итоги.