Как РМ-у работать с изменениями в проекте: 2 кейса из практики

8 июня 2022

  • Автор: Иван Пашко

  • Сложность: нормально

  • Время: 3 мин

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

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

Кейс 1: Kanban вместо Scrum как преодолеть предупреждение руководства

Все команды на проекте работали по методологии Scrum. Это нравилось руководству, ведь вся компания была синхронизирована, работала одинаково, и было ощущение, что оперировать таким процессом проще. По мнению руководства, благодаря Scrum легче контролировать работу и оценивать сотрудников.

Техническая команда, с которой я работал, не была эффективной в таком формате. Целью команды был технический рефакторинг и разбиение монолитной архитектуры на микросервисную. Но делалось это «по живому» — пока существующий продукт активно развивался.

Проблем в Scrum-подходе, неудовлетворявших команду, было две:

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

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

Несмотря на неэффективность Scrum-методологии в этой конкретной ситуации, менеджмент в компании боялся смены процесса. Особенно слова «Kanban», ведь это вроде бы что-то о хаосе, отсутствие контроля и ожидаемого планирования. На самом деле совсем нет, но сейчас не об этом.

Как ввести изменения и помочь команде с переходом?

Начали все с целей и business benefits. Прежде всего, нужно было предупредить стейкхолдеров, принимающих решения, ведь команда outsource, а принятие решений на стороне клиента. Далее — объяснить недостатки текущего перехода: фрустрация команды, неработающий подход, постоянно меняющийся скоуп, чувство хаоса — и преимущества нового. После этого стоило побороть страхи перед новым подходом: как мониторить, как контролировать, как планировать (спойлер: lead time+cycle time решают эти вопросы очень просто).

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

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

Через месяц команде дали зелёный свет продолжать в этом русле, но страх у клиента все равно остался, ведь все остальные команды продолжали работать по Scrum, а тут Kanban. С этого времени начался этап удержания (sustain the change) изменения, заключавшийся в основном в обсуждении на уровне руководства, постоянной коммуникации и мониторинге происходящего.

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

PM Hard Skills_ Release

Кейс 2: Неприятное изменение, которое в итоге превратилось в адаптацию

Клиент решил улучшить разработку и T-shape-нуть команды, чтобы лучше тестировали код, писали тесты и отвечали за все сами. Решением проблемы оказалось довольно неприятное изменение — сокращение роли QA/AQA.

Большинство команд не было готово к таким нововведениям, поэтому был предложен и воплощен план адаптации и постепенной смены.

  1. Обсудить проблему и понять, зачем нужны изменения: start with Why?
  2. Выяснить, как команда относится к такой смене, и готова ли к этому.
  3. Понять, что мешает реализации изменений (barriers) и что может способствовать (enablers).

Причиной изменения было желание улучшить команды, сделать их более независимыми (такими были только команды разработки) и дать больше ответственности.

Основной проблемой, которая волновала команду (resistance to change), было отсутствие качественных требований, что привело к доработке.

Наибольшая ценность QA заключалась в понимании и последующем тестировании требований.

После того, как цель была понятна, а отправная точка обозначена, команды с QA-инженерами начали готовить план перехода. Процесс подготовки был долгим, поэтому сразу к результату: мы попытались перенести эту функцию в начало процесса, нагрузив PO дополнительной работой и разгрузив его новой ролью — BA. По сути, изменение свелось к переходу роли тестирования на начало процесса, где и возникало больше бизнесовых ошибок, и как следствие — rework.

За год команда успешно адаптировалась к новому процессу, где разработчики отвечали за код, его качество и доставку, а аналитики из РО — за понятность и точность требований.

Вместо выводов

Менеджмент перемен — это действительно сложно. Нужно знать модели и фреймворки, какая документация и метрики важны, как общаться с командой и вводить изменения так, чтобы это не сломало процессы. Хорошая новость — этому можно научиться, вопрос только в том, на своих ошибках или опыте экспертов 😉

Иван Пашко

Engineering Manager в Preply. Более 10 лет в ІТ. Основные направления — лидерство, менеджмент и культура команд.