4 ноября
Это AMACON: в Минске проведут профильную конференцию для маркетологов
1 | 1 |
Agile-трансформация — это внедрение гибкой методологии управления не только в работу команды, но и на всех уровнях управления компанией. Как проходит трансформация, какие инструменты лучше использовать, на какие результаты рассчитывать? Стоит ли вообще выбирать Agile с учетом специфики вашей работы? Об этом рассказывает эксперт по внедрению Agile Максим Якубович, опираясь на кейс бельгийского банка, опубликованные исследования и собственный опыт.
— Agile-трансформация целых компаний стала логичным продолжением опыта внедрения Agile в отдельных командах. И сегодня, по оценкам многих экспертов, именно она является одной из мейнстримовых тем в блоке управления изменениями компаний.
Для тех, кто все еще не в теме: Agile, если кратко, — это итеративный, кросс-функциональный, ориентированный на команду подход для реализации проектов и создания новых продуктов, который можно применять в любой отрасли, но с учетом контекста, команды и проекта.
Первоначально Agile появился в области разработки программного обеспечения и был предназначен для того, чтобы поставить на первое место скорость, автономность и совместную работу с целью раскрыть полный потенциал команды. К основным выгодам Agile обычно относят:
Более подробную информацию вы найдете по ссылке. Но надо отметить, что Agile — далеко не панацея, и применение этой философии для всех проектов без учета специфики может не дать ожидаемого эффекта.
Например, для того чтобы понять, какую методологию управления проектами лучше выбрать, специалисты обычно рекомендуют опросить заинтересованные стороны: сотрудников компании, руководителей, заказчиков продукта и т.п. Специальные вопросы, которые можно найти в Agile Practice Guide, помогут выбрать оптимальный подход к управлению под определенный контекст, каждому из которых отведен отдельный сектор на графике:
Анализ ответов на этом графике в соответствии с их локализацией поможет выбрать наиболее подходящий метод управления. Скажу о каждом из них пару слов:
Но давайте вернемся к тем компаниям, где на пути Agile-трансформации стоит уже не только команда. Дело в том, что между терминами «Agile» и «Agile-трансформация» действительно есть некоторая разница. Словосочетание «Agile-трансформация» обычно используется для описания перехода компании в состояние, когда эта методология применяется во всей компании, а не только на уровне отдельных команд или департаментов. То есть имеется в виду масштабирование Agile-подхода к управлению процессами на всех уровнях компании.
Читайте также: Почему у одних получается, а у других — нет. Эксперт про опыт внедрения Agile
Например, в одном из бельгийских банков целями такой трансформации было сохранение актуальности компании на рынке сейчас и в будущем, повышение прозрачности и понятности процессов, ускорение работы и пр. Я считаю этот кейс хорошим примером того, как можно переосмыслить и изменить бизнес-процессы и сами подходы к ним.
При том, что в Беларуси многие компании (преимущественно в сфере ИТ) внедряют Agile-подход в управление отдельными проектами, интерес к полной Agile-трансформации проявляют пока только банки. Кейсов по ее успешному завершению в Беларуси пока нет, поэтому я привожу пример трансформации бельгийского банка. Итак.
1. Первый шаг — это выбор методологии для масштабирования Agile. В случае, если в вашем проекте работает до десяти человек и вы хотите работать по Agile, я бы рекомендовал использовать фреймворк Scrum — подробнее о нем можно узнать по ссылке. Но для проектов с количеством участников 50+ он не подходит.
Например, в банке, который мы взяли в качестве примера, был выбран SAFe (Scaled Agile Framework) — это гибкий фреймворк, позволяющий использовать Agile-методологии в больших командах размером более 50 человек. По сути, SAFe напоминает слоеный пирог из различных методик Agile, где на нижнем уровне находится практически традиционный Scrum, с типичными 2/3-недельными спринтами, командами по 3−9 человек включая владельца продукта (Product Owner), а также все типичные ритуалы, начиная от ежедневной планерки — и заканчивая разбором полетов на ретроспективном совещании.
Но особенность этого фреймворка в том, что команда уже перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом.
Спринты объединяются в Program Increments (это регулярные мероприятия по планированию), состоящие обычно из 5 спринтов. То есть если в классическом Scrum мы построили что-то не то — то коррекция курса проводится уже в следующем спринте. Но в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment, ожидая очередного мероприятия.
На следующем уровне находится Agile Release Train (так называемые поезда). Для управления всеми пятью спринтовыми отрезками появляются новые функции, например, системный архитектор. А последний спринт объявляется организационным, и во время него проводятся общие собрания, анализ технического долга, строятся планы по проработке архитектуры процесса и синхронизируется работа всех команд.
Над уровнем Agile Release Train находится координация между отделами, директорами, и клиентом — проводится анализ экономической целесообразности изменений, создаются планы работ на 12−36 месяцев. Для компаний с годовым оборотом менее миллиарда долларов — это, как правило, последний этаж.
В пользу SAFe в случае с банком сыграло то, что фреймворк хорошо задокументирован и способен поддерживать иерархические организации. Однако в банке не стали внедрять канонический SAFe в полной мере, видимо, потому, что у него есть свои недостатки, например:
С учетом этого банк использовал SAFe в качестве основы для построения собственной адаптированной Agile-модели (подробности банк, к сожалению, не раскрывает).
Альтернативой для SAFe в крупных компаниях могут быть около десятка подходов к масштабированию Agile на большие команды, но вторым по популярности после SAFe является LeSS, подробнее о нем можно узнать в Отчете об исследовании Agile в России за 2019.
2. Второй шаг — компания должна решить: стоит делать это своими силами или привлечь профессионалов на аутсорсе? Чтобы ответить на этот вопрос — нужно понять, что именно следует сделать на этом этапе:
Банк выбрал второй вариант и привлек консультантов извне. Вероятно, к такому решению руководство банка пришло потому, что очевидно — внутри банка нет специалистов, имеющих опыт выполнения аналогичных проектов, и банк не рискнул бы делать это своими силами. Об этом также говорят, например, Agile-трансформации Сбербанка, который консультировали две компании: McKinsey и ScrumTrek. При этом McKinsey обеспечивал политику в большой корпорации и референс-визиты по всему миру, а ScrumTrek — масштабирование Agile на основе, кстати, того же SAFe.
3. Третий шаг — выбор программного продукта. Для автоматизированного управления проектами в мире используется около 500 программных продуктов. Подробнее о них можно прочесть в этой статье.
Но для управления портфелями проектов — софта у них не так уж и много. Управление портфелями проектов как дисциплина зародилось в 90-е годы, и за это время разработчики программных продуктов не успели разработать много продуктов, которые покрывали бы нужный компаниям функционал по управлению портфелями. А в банках как раз одновременно идет огромное количество проектов, и надо принимать решения о перераспределении ресурсов, запуске новых проектов и остановке ставших неактульными проектов каждый месяц.
Каждый год аналитики из Gartner Inc., одной из ведущих аналитических компаний мира, публикуют свой анализ пространства управления проектами и портфелями (PPM) вместе с оценкой основных доступных решений. Результаты последнего рейтинга представлены на графике «Магический квадрант». Gartner называет «Магическим квадрантом» отчет с анализом какого-либо сегмента рынка, в который включает изображение с распределением поставщиков по указанным четвертям. Ежегодно компания выпускает несколько десятков магических квадрантов для каждого выбранного ею класса программного обеспечения.
На этом изображении мы видим названия решений для автоматизации управления портфелями проектов, которые Gartner разделил на 4 квадранта и для этого использовал две линейные прогрессивные экспертные шкалы — «полнота видения» (от англ. completeness of vision) и «способность реализации» (от англ. ability to execute).
Каждый поставщик таких решений, попавший в рамки рассмотрения, оценивается по этим двум критериям и оказывается в одном из четырех квадрантов плоскости, которые называются:
При этом поставщики иногда отмечают даже сам факт попадания в какой-либо магический квадрант отдельным пресс-релизом и признанием рыночных достижений, даже если компания упомянута лишь в квадранте «нишевых игроков».
Однако это не единственный рейтинг компании Gartner для поставщиков софта по управлению проектами. У них также есть «Магический квадрант» на тему «Инструменты планирования Agile предприятия», где представлены продукты, которые поддерживают использование Agile. Он выглядит вот так:
Интересно, что здесь в квадранте Visionaries представлен продукт белорусской компании Targetprocess, который и был выбран бельгийским банком для автоматизации процессов во время Agile-трансформации.
На мой взгляд, выбор в пользу Targetprocess в данном случае обоснован, потому что софт позволяет автоматизировать как работу в отдельном проекте, использующем Scrum или Kanban, так и управление портфелем проектов компании, что является серьезным преимуществом. Например, софт поддерживает использование Jira (система отслеживания задач) для управления портфелями проектов. Есть возможность автоматизировать ведение журнала продукта, работу с приоритетами элементов журнала, планирование спринтов и т.д., что важно для Scrum. И в то же время поддерживаются kanban-доска с WIP-лимитами, специальные отчеты, важные для использования kanban.
При этом Targetprocess имеет интеграцию с другими продуктами для управления проектами (например, Trello) и может использоваться только для уровня управления портфелями, например, как это сделано в компании Wargaming. К недостаткам Targetprocess можно отнести стоимость этого продукта, его вряд ли может себе позволить малый и даже средний бизнес.
В качестве альтернативы я бы предложил решение белорусских разработчиков Easy Projects, которым наша компания «КейТуБи» пользуется уже 4 года.
На текущий момент в бельгийском банке все представители бизнеса и ИТ-специалисты, работающие над реализацией ИТ-проектов (в общей сложности речь идет о 1300 пользователях в Targetprocess), прошли этап начального обучения и активно используют программу. Это позволяет говорить о том, что процесс трансформации компания прошла успешно.
Типичными целями для Agile-трансформации считаются результаты, которых удалось добиться и банку:
В заключение, опираясь на собственный опыт и некоторые опубликованные исследования, я могу дать общие рекомендации для тех компаний, которые хотят улучшить, ускорить и автоматизировать процессы и работу над продуктом:
1. Выберите подходящую именно вашей компании модель управления.
2. Поставьте внятную цель (лучше использовать для этого методологии постановки целей SMART или OKR).
3. Определитесь, кто будет внедрять изменения в компании.
4. Выберите оптимальный программный продукт для автоматизации управления портфелями и проектами (желательно, чтобы это был один продукт).
4 ноября
Это AMACON: в Минске проведут профильную конференцию для маркетологов
4 ноября
Завершился первый ночной хакатон в Беларуси “Startup Boom Hackathon&Accelerator”! Как это было?
1 ноября
Бесплатный аудит кадровых и бухгалтерских процессов – спецпредложение от ООО «СМАР ЛИГАЛ»
1 ноября
Запускаем акцию — «Заяви о себе с Про бизнес»!
1 ноября
МТБанк открыл phygital-офис в центре Минска. Что это за отделение и почему там нет касс?
1 ноября
Открыта регистрация на Форум по управлению интернетом Belarus IGF-2024
31 октября
Форум для белорусского бизнеса "Лига экспорта" пройдет в Минске 10 декабря
30 октября
BFS 17-й сезон: живая музыка, дух путешествий и инновационные гаджеты