Как стать автором
Обновить

Нет, мы так не работаем

Уровень сложностиСредний
Время на прочтение3 мин
Количество просмотров30K

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

Ситуация

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

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

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

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

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

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

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

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

Как решали

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
Хабы:
Всего голосов 47: ↑36 и ↓11+34
Комментарии38

Публикации

Истории

Работа

Ближайшие события

Конференция HR API 2024
Дата14 – 15 июня
Время10:00 – 18:00
Место
Санкт-ПетербургОнлайн
Конференция «IT IS CONF 2024»
Дата20 июня
Время09:00 – 19:00
Место
Екатеринбург
Summer Merge
Дата28 – 30 июня
Время11:00
Место
Ульяновская область