Agile-трансформации в первую очередь касаются перехода на продуктовое управление, когда мы заменяем классическое проектное управление фокусом на продукты и клиентов. А чтобы команда могла эффективно развивать продукты, она должна научиться жить и работать по-новому.
Дмитрий Курдюмов, основатель агентства Smart Units, рассказал, как правильно подходить к Agile-трансформации, из каких этапов она состоит и какие ошибки чаще всего совершают компании на пути внедрения гибких методик.
В процессе Agile-трансформации команды начинают жить и мыслить не категориями проектов с фиксированными ресурсами, объемом работ и бюджетом, в рамках которых они должны быть выполнены, а продуктовыми метриками и целями — стремясь к тому, чтобы продукт приносил определенную ценность компании. Под ценностью я подразумеваю некий бизнес-результат. В конечном итоге компания должна либо зарабатывать больше, либо сократить какие-то ненужные издержки.
На уровне команд такой фокус декомпозируется на продуктовые метрики и появляется роль владельца продукта, который отвечает за бизнес-результат. Чтобы эффективно достигать этих целей, влиять на метрики, развивать продукт и делать его максимально ориентированным на клиента, как раз и нужны гибкие подходы.
Именно поэтому переход компании к продуктовой структуре влечет за собой необходимость для команд жить по-новому и использовать гибкие подходы для сокращения риска неудач. Ведь когда команда планирует работу на спринт (неделю или две), по сути, она берет на себя риски — а вдруг запланированные задачи окажутся не нужны. Однако есть и хорошие новости — в конце спринта команда получит обратную связь от рынка и определит, в правильную ли сторону она движется. То есть появляется возможность выстраивать процесс быстрого тестирования гипотез и развивать продукт на основе мгновенной обратной связи рынка. Именно ради такой выгоды компании и начинают Agile-трансформацию.
Проблема 1. Сопротивление менеджеров
Компаниям, которые пошли по пути Agile-трансформации, приходится полностью менять модель управления и сокращать уровни иерархии, чтобы команды становились отдельными бизнес-единицами и отвечали за результаты своего продукта. При такой структуре, как правило, пропадает необходимость в линейных менеджерах и руководителях команд классического стиля — которые ставят задачи и контролируют ход их выполнения. Причина проста: за приоритизацию и ответ на вопрос «что делать?» теперь отвечает владелец продукта, а «как делать?» определяет сама команда — она же теперь и принимает решения.
И это вызывает сопротивление менеджмента среднего звена. Потому что части менеджеров приходится либо устраниться из компании, либо принять новые правила игры и управления — фактически, перейти от привычной модели «я руководитель и ставлю задачи» к модели «я помогаю команде проще и быстрее поставлять ценность». То есть менеджеры теряют традиционную власть и контроль над командами.
Кроме того, middle-менеджмент перестает понимать свою роль — ведь никто толком не объясняет новые правила, не помогает перестроиться. Это происходит из-за недостатка лидеров изменений снизу. Как чаще всего происходит трансформация: наверху, на уровне CEO, принимают решение идти в Agile, но никто не пытается серьезно донести это решение до всех ступеней вертикали. И если снизу никто не будет сознательно выявлять лидеров, драйвить трансформацию, обучать и развивать людей, помогать в построении процессов и команд, то middle-менеджмент так и останется наедине со своими невеселыми мыслями.
Обычно такую работу выполняют Scrum-мастера и Agile-коучи, которые появляются на старте трансформации: они могут поддерживать команды снизу и устраняют нехватку лидеров. Однако они не должны подменять собой агентов изменений и становиться менеджерами — их задача выращивать таких людей внутри компании и помогать им осознать свою новую роль.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Проблема 2. Взгляд на Agile-трансформацию как на проект
Нередко Agile-трансформацию рассматривают как проект: компания решила трансформироваться, наняла консультантов за большие деньги, которые провели тренинги и ушли. При этом структура и стиль работы компании почти не поменялись — просто новые термины и названия ролей заменили прежние. Результат — скепсис по отношению к Agile со стороны команды.
Концепция «Agile-трансформация как проект» не работает — потому что трансформация больше похожа на продукт с длинным жизненным циклом и может продолжаться бесконечно — меняясь в соответствии с потребностями и запросами рынка. Сегодня актуально одно, завтра — другое, и ко всем новым обстоятельствам постоянно приходится адаптироваться. Поэтому процесс изменений нельзя рассматривать как проект.
Однако можно выделить этапы, которые должна пройти каждая компания во время трансформации:
- Сначала необходимо обеспечить условия, в которых будут работать Agile-команды, и поменять организационную структуру. Это поможет сформировать новое поведение.
- Потом начинаем выстраивать новые процессы и учить команду, как работать по-новому: быстрее и регулярнее выпускать продукт на рынок, жить максимально прозрачно и показывать, что находится в бэклоге, какими были результаты спринта, проводить обзоры спринта или демо.
- Подкрутить фокус на продукт: ответить на вопросы, для кого и зачем мы все это делаем, чтобы «на вход» командам подавалась правильная ценность.
- После этого идет этап изменения культуры организации. Важно понимать, что без соответствующей структуры и условий она не поменяется: люди должны привыкнуть фокусироваться на продукте, думать о клиенте, следовать принципу «ошибайся быстро, ошибайся безопасно» — то есть знать, что их не будут ругать за ошибки, а если вдруг у кого-то появится проблема, то ее можно свободно обсудить и попросить помощи. И построение культуры — очень долгий процесс. Для этого нужны скрам-мастера, лидеры изменений и люди в командах, которые хотят работать по-новому и понимают ценность новых процессов.
Причем все эти этапы можно проходить двумя способами: с помощью революции и с помощью эволюции. Революция — когда мы резко все меняем и принимаем, что с завтрашнего дня живем по-новому. Эволюция — процесс постепенных изменений. Большой компании опасно и сложно идти по пути революции — слишком много всего надо поменять в процессе трансформации и существует риск, что в таком процессе просядут бизнес-результаты. поэтому приходится искать баланс: эволюционным путем идти можно — это менее рискованный, но гораздо более долгий процесс. Революционный путь быстрее, но он несет много рисков. Поэтому чаще всего трансформация начинается с пилотного внедрения Agile на одном продукте и одной команде. После этого мы смотрим на результаты и масштабируем их на всю компанию.
Проблема 3. Отсутствие вовлеченности топ-менеджмента
Часто CEO говорит: все, мы должны стать Agile — вот такая теперь у вас задача, идите делайте. Однако так не работает. Трансформация — это не так, что руководители должны написать план перехода, сверстать красивые презентации, а потом отчитаться, что все отлично и теперь мы Agile. Трансформация — это всегда совместная работа верха и низа компании. Менеджмент должен активно вовлекаться в работу, чтобы устранять препятствия на пути команд и поддержать изменения. Иначе у людей внизу не хватит полномочий, прав и рычагов, чтобы построить Agile-процессы и правильную культуру.
Задача топ-менеджмента — помочь командам и дать им все необходимое, чтобы Agile-трансформация удалась. Однако топ-менеджеры часто бывают к этому не готовы и не вовлекаются в процесс. В итоге появляются Agile-ритуалы, которые ничего в себе не несут, а сотрудники компании начинают думать, что Agile — это какая-то бесполезная игрушка топ-менеджмента.
Agile-трансформация может восприниматься только лишь как набор практик и действий, которые должна выполнять команда. Однако на самом деле Agile — это фокус на продукт и клиента. А для этого должен появиться процесс регулярной инспекции и адаптации: измерение того, что есть сейчас, и изменение этого «сейчас» под требования рынка — то есть постоянная попытка понять, в какую сторону необходимо двигаться. Этот процесс сопровождается большим количеством ошибок — и это нормально, надо дать командам возможность ошибаться, иначе эффекта от внедрения Agile не будет. Менеджмент должен быть готов постоянно поддерживать и развивать такую культуру.
Проблема 4. Отсутствие системного подхода к изменениям
У Agile-трансформации, как и у любого продукта, должна быть дорожная карта, вектор, цели: чего мы хотим достичь и что мы для этого делаем — а также бэклог изменений, регулярная синхронизация и группа трансформации, которая обсуждает и анализирует, куда движется компания.
Отсутствие такой системности ведет к тому, что трансформация скатывается к фоновой активности, а менеджмент занимает позицию «да, это важно, но пусть люди сами разбираются, как это сделать». В итоге не получается выстроить нормальный системный процесс, который бы на самом деле создавал ценность для компании.
Проблема 5. Не все принимают Agile
В процессе трансформации придется отказаться от некоторых участников команд, потому что не все готовы перейти к новому формату работы. И это нормально. Особенно много таких людей бывает среди менеджеров, которые не готовы меняться и потому сопротивляются изменениям, саботируют процесс трансформации. Некоторые из них самоустраняются, а вот сотрудники на высоких должностях могут не уходить самостоятельно — и от них придется отказываться.
У этой проблемы есть еще одно следствие. Когда компания уже прошла определенный путь и поменяла культуру, ее ценности становятся близки к Agile-ценностям. И с этого момента важно нанимать людей не только по хард-скилам, но и по тем самым ценностям. Успешные гибкие компании смотрят не только на непосредственный опыт человека, но и на его ценности. Даже самый крутой профессионал может быть бесполезен в Agile-компании, потому что просто не может работать в команде.
Проблема 6. Проектный подход никуда не уходит
Нередко случается, что в компании создаются продуктовые команды, однако сроки и задачи им все равно спускаются сверху. Получается странная ситуация: мы вроде бы Agile-команда, но при этом выполняем проект с фиксированными сроками и ресурсами. Необходимо дать командам ответственность за результат и возможность самостоятельно принимать решения. Иначе зачем тогда Agile?
