В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего case-study.
Ситуация
Аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного неба - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог
Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
И результатом всего этого стала демотивация команды – всё по классике.
Как решали
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход
Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Проблемы с бэклогом пытались решить через привитие нашей культуры разработки. Но и это не увенчалось успехом.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
Итогом стало то, что спонсор проекта вместе с руководителем продукта просмотрели совместно все стори и утверждали их, и так происходило до тех пор, пока состояние бэклога не стабилизировалось. Рецидива не было по одной простой причине – метрика, о которой я говорил выше, показывалась каждую неделю.
Как мы решили проблему микроменеджмента? А никак. 😆 Она рассосалась сама, на нас просто обиделся менеджер продукта и сократил общение до необходимого минимума.
Но всё описанное выше было возможно по ряду причин, на которые я ссылался раньше:
🤘 У нашей команды был огромный кредит доверия со стороны спонсора проекта: выше я указал про успешное долгосрочное сотрудничество.
🤘 Спонсор проекта действительно был заинтересован в развитии продукта, успех продукта позволил ему построить головокружительную карьеру.
🤘 Мы не сказали нет напрямую, мы сказали это через спонсора проекта.
И самый-самый итог руководителя продукта уволили через год. На мой вопрос почему не раньше я получил ответ – контракт, до истечения срока его нельзя было уволить. Первый квартал он адаптировался, полгода показывал, что умеет и ещё квартал подводили итоги.
