Опытные РМ-ы знают: изменения не обходят стороной ни один проект, ведь они происходят не время от времени, а постоянно. Потому и подходить к работе с ними нужно систематически, чтобы не случилось так, что изменения затянули настолько, что уже и управлять ими невозможно.
В статье поделюсь, от чего «бежали» мы с командой и как адаптировались к переходу от уже привычных процессов в проекте к чему-то новому. Каждый из кейсов показывает, почему менеджеру важно научиться работать с изменениями в проекте и не бояться их. Наличие у PM-а навыков работы с изменениями не только экономит бюджет и время компании, но и делает процессы более комфортными, в частности для команды.
Кейс 1: Kanban вместо Scrum — как преодолеть предупреждение руководства
Все команды на проекте работали по методологии Scrum. Это нравилось руководству, ведь вся компания была синхронизирована, работала одинаково, и было ощущение, что оперировать таким процессом проще. По мнению руководства, благодаря Scrum легче контролировать работу и оценивать сотрудников.
Техническая команда, с которой я работал, не была эффективной в таком формате. Целью команды был технический рефакторинг и разбиение монолитной архитектуры на микросервисную. Но делалось это «по живому» — пока существующий продукт активно развивался.
Проблем в Scrum-подходе, неудовлетворявших команду, было две:
- Невозможность спрогнозировать сложность задач, ведь каждый день появлялись новые нюансы или функциональность.
- Постоянное изменение приоритетов задач — вытекающая из первой проблема.
Команда научилась декомпозировать работу на маленькие куски более или менее одинакового размера, но постоянное изменение приоритетов, последовательности и скоупа мешало эффективному планированию.
Несмотря на неэффективность Scrum-методологии в этой конкретной ситуации, менеджмент в компании боялся смены процесса. Особенно слова «Kanban», ведь это вроде бы что-то о хаосе, отсутствие контроля и ожидаемого планирования. На самом деле совсем нет, но сейчас не об этом.
Как ввести изменения и помочь команде с переходом?
Начали все с целей и business benefits. Прежде всего, нужно было предупредить стейкхолдеров, принимающих решения, ведь команда outsource, а принятие решений на стороне клиента. Далее — объяснить недостатки текущего перехода: фрустрация команды, неработающий подход, постоянно меняющийся скоуп, чувство хаоса — и преимущества нового. После этого стоило побороть страхи перед новым подходом: как мониторить, как контролировать, как планировать (спойлер: lead time+cycle time решают эти вопросы очень просто).
Мы предложили клиенту попробовать новый режим в течение месяца и сравнить результаты. Клиент согласился на эксперимент.
Этап execution смены был прост, ведь команда была более чем готова к вводу изменений. Примерно месяц все адаптировались к новому процессу: мы провели несколько итераций и улучшили определенные подходы и другие моменты. Постоянно коммуницировали со стейкхолдерами по поводу процесса и прогресса.
Через месяц команде дали зелёный свет продолжать в этом русле, но страх у клиента все равно остался, ведь все остальные команды продолжали работать по Scrum, а тут Kanban. С этого времени начался этап удержания (sustain the change) изменения, заключавшийся в основном в обсуждении на уровне руководства, постоянной коммуникации и мониторинге происходящего. 🐇 Твои +5% дополнительной скидки на любой курс для проджект-менеджеров! Просто добавь в форму регистрации на курс промокод «Пасхалка 5%» 🐇
Команда работала в новом подходе больше года. За это время она стала образцом для нескольких других команд, которые хотели внедрить то же самое. К сожалению, у них не получилось «продать» руководству эту идею, даже имея эффективный пример под боком, но это уже другая история. Главное, что здесь в конкретной команде нам удалось внедрить более эффективный подход.
Кейс 2: Неприятное изменение, которое в итоге превратилось в адаптацию
Клиент решил улучшить разработку и T-shape-нуть команды, чтобы лучше тестировали код, писали тесты и отвечали за все сами. Решением проблемы оказалось довольно неприятное изменение — сокращение роли QA/AQA.
Большинство команд не было готово к таким нововведениям, поэтому был предложен и воплощен план адаптации и постепенной смены.
- Обсудить проблему и понять, зачем нужны изменения: start with Why?
- Выяснить, как команда относится к такой смене, и готова ли к этому.
- Понять, что мешает реализации изменений (barriers) и что может способствовать (enablers).
Причиной изменения было желание улучшить команды, сделать их более независимыми (такими были только команды разработки) и дать больше ответственности.
Основной проблемой, которая волновала команду (resistance to change), было отсутствие качественных требований, что привело к доработке.
Наибольшая ценность QA заключалась в понимании и последующем тестировании требований.
После того, как цель была понятна, а отправная точка обозначена, команды с QA-инженерами начали готовить план перехода. Процесс подготовки был долгим, поэтому сразу к результату: мы попытались перенести эту функцию в начало процесса, нагрузив PO дополнительной работой и разгрузив его новой ролью — BA. По сути, изменение свелось к переходу роли тестирования на начало процесса, где и возникало больше бизнесовых ошибок, и как следствие — rework.
За год команда успешно адаптировалась к новому процессу, где разработчики отвечали за код, его качество и доставку, а аналитики из РО — за понятность и точность требований.
Вместо выводов
Менеджмент перемен — это действительно сложно. Нужно знать модели и фреймворки, какая документация и метрики важны, как общаться с командой и вводить изменения так, чтобы это не сломало процессы. Хорошая новость — этому можно научиться, вопрос только в том, на своих ошибках или опыте экспертов 😉