Привет, хабровчане. В преддверии старта курса «Agile Project Manager», в создании которого принимал участие, делюсь основанной на собственном опыте статьёй.
Возможности и перспективы agile-трансформации обсуждаются сейчас очень широко, привлекая аудиторию от IT-аналитиков до менеджеров CxO-уровня. Известно несколько западных (пока) школ по достижению так называемого Enterprise Agility – это действительно интересно и даже модно. И как любой hype согласно методике Gartner, по ощущениям, данное направление неуклонно движется к «пику завышенных ожиданий», за которым видимо ждёт «пропасть разочарований» и только потом устойчивое «плато продуктивности».
Вот как это выглядит в общем случае:
Попробуем обобщить предварительные итоги такой трансформации по опыту двух совершенно разных компаний, крупнейших представителей своей отрасли, одними из первых на российском рынке ступивших на стезю полномасштабной agile-трансформации. Непосредственно лидируя отдельные направления в качестве бизнес-архитектора, отвечая за структурирование изменений и разработку целевой модели организации, я пришёл к весьма прагматичным и не совсем ожидаемым выводам, которым кратко поделюсь в данной статье.
Итак, представим, умудренные опытом руководители некой большой компании озабочены повышенными ожиданиями акционеров, ростом конкуренции, перераспределением выручки в пользу цифровых каналов и связанными с этим вызовами. Как всегда, ищутся способы увеличить производительность труда, усилить присутствие бренда на рынке и просто не потерять ставших более разборчивыми клиентов в условиях турбулентности. Прочитаны бизнес-бестселлеры, проведено много часов консультаций, принимается решение последовать актуальному тренду и начать (или ускорить) трансформацию модели управления. Кто-то говорит пора звать «большую четверку», которая всё объяснит, кто-то предлагает внедрять Scrum of Scrum или делать большую общую Kanban-доску…
— ясное понимание цели, ради которой нам необходимо измениться: какую бизнес-модель компания видит для себя в перспективе и почему для её реализации не обойтись без перестройки организационной структуры для достижения принципиально иного уровня гибкости и осознанности в принятии решений. Это стратегический этап, как обычно в числе прочего характеризующийся оценкой своего положения и конкурентов, выбором ориентиров для сравнения и формированием сценариев будущего с оценкой глобальных преимуществ и потенциальных рисков.
что agile-трансформация крупной компании, вопреки стереотипам, хоть и следует духу agile-манифеста, имеет мало отношения к тому, что общепринято называть agile-методологией. Гибкость зрелой организации начинается не с выделения продуктов и тем более не с определенных церемоний, а в первую очередь – со стратегии управления внутренними инвестициями, а также c совершенно конкретных мер по развитию корпоративной культуры.
Первое проявляется через способность делегировать принятие решений об инвестициях в развитие, перестраивая управление портфелем проектов в пользу децентрализации бюджетов. Одновременно развивается умение каскадировать стратегические цели, устанавливать KPI или OKR, сочетать подходы сверху-вниз и снизу-вверх. Интересны вызовы, например, для команды CFO, – потребность в демократизации финансово-экономического обоснования и последующей оценки эффективности бизнес-инициатив. Суть каскадирования примерно показана на рисунке:
Второе определяется повышением зрелости менеджмента компании — это критично, поскольку, если верить исследованиям, проведенным авторами книги «Лидер и племя», культура команды не сможет держаться выше культурного уровня её лидера (личные наблюдения с этим вполне согласуются). И в целом, необходимо создание условий для вовлеченности сотрудников и мотивации большинства ценить командные достижения выше личных – здесь важно не только обучение, но и ревизия системы компенсаций.
После этого логически следует проработка архитектуры компании, начиная с ключевых потоков создания ценности, приводящая к целевой организационной структуре с соответствующим перераспределением полномочий и бюджетов в сочетании с реформированием коллегиального управления на стратегическом уровне.
Наконец, всё вышесказанное надо запустить в жизнь, невзирая на политику и консерватизм, создавая сотрудникам безопасные условия для перехода.
мы приходим к выстраиванию собственно «кросс-командного» agile: фокусируемся сначала на запуске, потом на взаимодействии конкретных продуктовых команд, следуя рекомендациям LeSS или SAFe (отмечу, что новая версия 5.0 покрывает также большую часть перечисленного выше), либо создавая их производные, как делали мы. Команды можно запускать параллельно, и зачастую они сами принимают решение о своей готовности к применению Scrum, например. Они не всегда оказываются правы, но это точно не основная проблема. Главное не терять из виду фундаментальные основы, без которых трансформация рискует превратиться в игрушку для привлечения талантов.
Конечно, вы на верном пути, если внедряете культуру постоянных улучшений, проводите тренинги для команд, и безусловно стараетесь держать клиента в фокусе внимания. При этом, трансформация не может проводиться «кавалерийским наскоком» и требует внятного экономического обоснования и должной систематизации. Иначе руководство компании попадает в ловушку «видимости agile», когда энергичные заряженные позитивом митинги вселяют веру в успех и помогают переосмыслить мировоззрение (что уже хорошо), но не способствуют структурному подкрепленному надежными данными подходу к реформированию организации и результативному управлению ею в новых условиях. Умение системно и комплексно проводить agile-трансформацию компании с недавнего времени начали называть Structural Agility – это даёт возможность преодолеть инерцию и построить действительно гибкую клиенто-ориентированную, привлекательную для партнеров и инвесторов цифровую организацию, реализующую творческий потенциал своих сотрудников.
Возможности и перспективы agile-трансформации обсуждаются сейчас очень широко, привлекая аудиторию от IT-аналитиков до менеджеров CxO-уровня. Известно несколько западных (пока) школ по достижению так называемого Enterprise Agility – это действительно интересно и даже модно. И как любой hype согласно методике Gartner, по ощущениям, данное направление неуклонно движется к «пику завышенных ожиданий», за которым видимо ждёт «пропасть разочарований» и только потом устойчивое «плато продуктивности».
Вот как это выглядит в общем случае:
Попробуем обобщить предварительные итоги такой трансформации по опыту двух совершенно разных компаний, крупнейших представителей своей отрасли, одними из первых на российском рынке ступивших на стезю полномасштабной agile-трансформации. Непосредственно лидируя отдельные направления в качестве бизнес-архитектора, отвечая за структурирование изменений и разработку целевой модели организации, я пришёл к весьма прагматичным и не совсем ожидаемым выводам, которым кратко поделюсь в данной статье.
Итак, представим, умудренные опытом руководители некой большой компании озабочены повышенными ожиданиями акционеров, ростом конкуренции, перераспределением выручки в пользу цифровых каналов и связанными с этим вызовами. Как всегда, ищутся способы увеличить производительность труда, усилить присутствие бренда на рынке и просто не потерять ставших более разборчивыми клиентов в условиях турбулентности. Прочитаны бизнес-бестселлеры, проведено много часов консультаций, принимается решение последовать актуальному тренду и начать (или ускорить) трансформацию модели управления. Кто-то говорит пора звать «большую четверку», которая всё объяснит, кто-то предлагает внедрять Scrum of Scrum или делать большую общую Kanban-доску…
Первое, с чего стоит начать
— ясное понимание цели, ради которой нам необходимо измениться: какую бизнес-модель компания видит для себя в перспективе и почему для её реализации не обойтись без перестройки организационной структуры для достижения принципиально иного уровня гибкости и осознанности в принятии решений. Это стратегический этап, как обычно в числе прочего характеризующийся оценкой своего положения и конкурентов, выбором ориентиров для сравнения и формированием сценариев будущего с оценкой глобальных преимуществ и потенциальных рисков.
Далее оказывается,
что agile-трансформация крупной компании, вопреки стереотипам, хоть и следует духу agile-манифеста, имеет мало отношения к тому, что общепринято называть agile-методологией. Гибкость зрелой организации начинается не с выделения продуктов и тем более не с определенных церемоний, а в первую очередь – со стратегии управления внутренними инвестициями, а также c совершенно конкретных мер по развитию корпоративной культуры.
Первое проявляется через способность делегировать принятие решений об инвестициях в развитие, перестраивая управление портфелем проектов в пользу децентрализации бюджетов. Одновременно развивается умение каскадировать стратегические цели, устанавливать KPI или OKR, сочетать подходы сверху-вниз и снизу-вверх. Интересны вызовы, например, для команды CFO, – потребность в демократизации финансово-экономического обоснования и последующей оценки эффективности бизнес-инициатив. Суть каскадирования примерно показана на рисунке:
Второе определяется повышением зрелости менеджмента компании — это критично, поскольку, если верить исследованиям, проведенным авторами книги «Лидер и племя», культура команды не сможет держаться выше культурного уровня её лидера (личные наблюдения с этим вполне согласуются). И в целом, необходимо создание условий для вовлеченности сотрудников и мотивации большинства ценить командные достижения выше личных – здесь важно не только обучение, но и ревизия системы компенсаций.
После этого логически следует проработка архитектуры компании, начиная с ключевых потоков создания ценности, приводящая к целевой организационной структуре с соответствующим перераспределением полномочий и бюджетов в сочетании с реформированием коллегиального управления на стратегическом уровне.
Наконец, всё вышесказанное надо запустить в жизнь, невзирая на политику и консерватизм, создавая сотрудникам безопасные условия для перехода.
И лишь на следующем этапе
мы приходим к выстраиванию собственно «кросс-командного» agile: фокусируемся сначала на запуске, потом на взаимодействии конкретных продуктовых команд, следуя рекомендациям LeSS или SAFe (отмечу, что новая версия 5.0 покрывает также большую часть перечисленного выше), либо создавая их производные, как делали мы. Команды можно запускать параллельно, и зачастую они сами принимают решение о своей готовности к применению Scrum, например. Они не всегда оказываются правы, но это точно не основная проблема. Главное не терять из виду фундаментальные основы, без которых трансформация рискует превратиться в игрушку для привлечения талантов.
Конечно, вы на верном пути, если внедряете культуру постоянных улучшений, проводите тренинги для команд, и безусловно стараетесь держать клиента в фокусе внимания. При этом, трансформация не может проводиться «кавалерийским наскоком» и требует внятного экономического обоснования и должной систематизации. Иначе руководство компании попадает в ловушку «видимости agile», когда энергичные заряженные позитивом митинги вселяют веру в успех и помогают переосмыслить мировоззрение (что уже хорошо), но не способствуют структурному подкрепленному надежными данными подходу к реформированию организации и результативному управлению ею в новых условиях. Умение системно и комплексно проводить agile-трансформацию компании с недавнего времени начали называть Structural Agility – это даёт возможность преодолеть инерцию и построить действительно гибкую клиенто-ориентированную, привлекательную для партнеров и инвесторов цифровую организацию, реализующую творческий потенциал своих сотрудников.
wmgeek
Участвовал в трансформации международной компании, продолжаю нести ценности Agile в проектной команде системного интегратора и что то в вашем видении есть, но на уровне проекта я искал и не мог найти источника гибкости финансов… Цель, срок, ресурсы (бюджет) определены в уставе. Можно изгибаться, но границы заданы. Fix time and resource, flex scope слышалось решением. Но смотреть нужно выше, не на проект, а на весь портфель. И вот тогда, приоритезируя проекты по портфелю, тем самым flex scope, как задачи в backlog, мы достигаем гибкости без ломки финансов. С одной стороны четкий, прозрачный, привычный бюджет. С другой — гибкость в реализации тех или иных проектов. Остается признать, что бюджет проекта живой и непрерывно балансируется за счет портфеля. Резервы выносятся на уровень портфеля, сроки реализации задач сжимаются и проявляются преимущества гибкого подхода. Но работали ли вы с проектами без фиксированного бюджета? Я чаще вижу KPI плюс минус 10% от первоначального плана :-( Это барьер на уровне PMO, а вовсе не CFO. Дефект в том, что руководитель портфеля слепо переносит свой KPI на каждый проект в отдельности.
podymov Автор
Спасибо за развернутый комментарий! Действительно, в классическом проекте нет бюджетной гибкости, поскольку это из компонентов коммитмента. Соответственно, бюджетные решения принимаются на уровне программы или портфеля. В статье, при делегировании инвестиционных решений, прежде всего подразумевается не прямое наращивание суммы бюджета, а дробление портфелей и относительная свобода выбора содержания бэклогов команд.
Проект превращается в один или несколько эпиков, которые по факту имеют свою стоимость (и желательно бизнес-кейс).
Решения о выделении существенных дополнительных сумм согласовываются более централизовано, тем не менее мы уходим от необходимости единого PMO.