2024-11-21: Enterprise Agile: Agile на масштабах большой компании - технологично работает
В понедельник 18.11 прошла конференция Enterprise Agile Russia-2024, два трека докладов и один трек мастер-классов. Особенность конференции — только доклады от крупных компаний о достаточно масштабном использовании Agile-методов крупными компаниями, из которых были все докладчики, докладов от консультантов не было. И не было докладов о пилотных внедрениях на несколько команд. Как объяснили организаторы, заявок о пилотах было много, но в однодневную конференцию все не уместишь.
Если говорить об общем впечатлении, то примерно в 2012—2014 у меня сложилось четкое впечатление: все, кто всерьез решил использовать Agile-методы на уровне команд — успешно это делают, технология уже зрелая. А на этой конференции такое же впечатление сложилось про использование на уровне крупных компаний. Используют OKR для сихронизации и управления по целям, при чем где-то это на том уровне, что любые проекты вкедут с использованием OKR. Например, был доклад о том, как OKR использовали для проекта закрытия сегмента бизнеса с минимизацией потерь, а в результате сегмент получилось успешно перезапустить.
А из SAFe, который так всеобъемлющ, что напоминает RUP от Agile, выделилось полезное ядро, которое используют для управления на больших масштабах:
- PI Planning как средство масштабного планирования с взаимоной увязкой по зависимым проектам. Как показывает опыт, число участников хорошо организованной сессии может достигать тысяч человек, и они работают конструктивно, создавая за два дня реалистичный план.
- Value stream train, которые обеспечивают переход от управления потоками задач, измеряемыми объемом выполненных работ, к управлению потоками создания ценности, который оценивается по ценности для бизнеса и потребителя. При этом обеспечивается трассировка создаваемой ценности до стратегии компании. И это — принципиально другой уровень управления. чем классическое управление потоком работ или проектами, в классических проектах тоже главное — выполнить объем работ, а не достигнуть бизнес-результата.
В целом получается, что компания - не механистичный исполнительный механизм, а конструкция со свободными элементами, обладающими собственной волей, но действующими скоординировано.
На этом я заканчиваю об общих впечатлениях, и перехожу к докладам. Часть из них я уже опубликовал на своем канале в ходе конференции, другие — не успел и включаю в отчет. Но надо понимать, что это — меньше половины всех докладов конференций, потому что треков — два, а еще на некоторых слотах я активно общался и доклады пропустил.
Содержание
[убрать]- 1 Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только)
- 2 Анна Аверьянова из Робофинанс. Как OKR помог перезапустить бизнес!
- 3 Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile
- 4 Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка
- 5 Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems Replacement
- 6 Сергей Паршиков. Оценка производительности команды в корпоративной среде
- 7 Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
- 8 Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
- 9 Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке
Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только)
Это был рассказ о работе с системой метрик, применяемый в hh, иллюстрированный конкретными примерами. Основная идея — метрики лишь показывают точки потенциальных проблем, и не автоматически, а после анализа показателей на предмет нежелательной динамики или соотношение метрик. А дальше нужно породить гипотезы — что может являться причинами, и проверить их через детальный анализ, погружение в реальную работу людей. При этом, если проблемы выявлены из общих метрик, то анализ ведут в каждом из сервисов, причины могут быть различны. Общие подтвержденные гипотезы становятся фокусом на уровне компании, частные — в сервисах, масштаб определяет приоритеты.
В докладе было конкретной дерево метрик из двух групп — ресурсы и поток.
- 1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход — целевая метрика)
- 1.2. Распределение ресурсов: стратегия, продукт, тех.налог, прочее. Классификация задач, дальше корректируется продуктом, так как большие задачи могут перекашивать.
- 2.1. 85 % lead time feature. Полный — от discovery, постановки до АБ тест и пост-продакшн. 85 выбрано ретроспективно из анализа.
- 2.2. Эффективность потока — блокеры.
- 2.3. Средняя пропускная способность за неделю
В докладе были примеры. Разбор с тем, что увидели рост времени АБ-тестирования — там были гипотезы. И со сроками discovery в одном из потоков — она была волатильна и коррелировала с отпусками и болезнями, то есть мощности команды явно не хватало на стандартный поток и они добавили человека. При этом нет задачи работать на конкретную метрику, например, увеличение lead time — нормальная вещь, если поставлена задача улучшить фазу discovery. Метрики — лишь сигнал, а дальше надо погружаться, не работать напрямую. Именно люди работают с процессом и знают как поменять.
И в конце — шаги работы с метриками.
- Начать собирать метрики
- Анализ и генерацию гипотез
- Провести анализ сервиса — проверить гипотезы
- Фокусы для сервисов
- Общие гипотезы для всех сервисов
- Задачи для всех и для конкретных сервисов
Анна Аверьянова из Робофинанс. Как OKR помог перезапустить бизнес!
У Робофинанс с 2016 был бизнес в Испании — online выдача кредитов, в 2020 случился ковид, мораторий на платежи кредитов, с одной стороны, а с другой — поддержка ликвидности и онлайн. Они продолжили бизнес, но в 2021 выяснилось, что люди набирают кредиты и не платят. Поэтому по итогам года инвестор, он же владелец и ген.дир принял решения о закрытии бизнеса. Но такой бизнес нельзя закрыть одним днем, надо соблюсти требования регулятора, иначе можно лишиться лицензии и для других сегментов бизнеса. Поэтому был процесс на год, который решили вести по OKR, как и все остальное. Цель понятна — минимизация потерь. Было сделано 3 сценария от команды: реалистичный, негативный и позитивный. И в конце первого квартала увидели по метрикам, что развитие идет лучше даже оптимистичного сценария, и в принципе динамика позволяет предположить, что за год можно будет сохранить команду и выйти в плюс. Они пошли к владельцу, показали цифры, получили добро на попытку сохранения и поменяли цель. И у них получилось. У команды был стимул — им нравилось работать вместе и они точно хотели сохраниться. А пост-анализ показывает, что сыграли два внешних фактора: поменялся рынок потребления, то есть тех, кто брал кредиты, при этом часть конкурентов с рынка ушла. А OKR позволил во-время заметить изменение трендов, и пересобрать продукт под новый рынок.
Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile
В PwC большое количество ИТ-системы были от головной компании. Поверх них кое-где были собственные решения с российской спецификой. Когда российская часть разводилась с головной, у него осталось лоскутное одеяло этих решений, а чтобы не допустить остановки бизнеса — перешли не Excel. А дальше надо было реанимировать ситуацию, и в компании создали центр продуктовой экспертизы, чтобы сделать это системно. Марина — его руководитель, в центре собраны архитекторы, devops, юридическое обеспечение и ряд других компетенций, а разработка идет отдельными командами, которую центр поддерживает. И еще просвещает в части продуктового подхода и unit-экономики. И у них получилось не просто разработать продукты, поддерживающие работу компании, но и начать выводить их на рыноК PwC этого вообще не делало. Такая вот success story. О конструкции разработки и функциях центра Марина рассказывала, но очень пунктиром, на слайдах подробности есть.
Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка
Одна из существенных черт Agile-методов — прозрачность. И рассказ был о том, как обеспечивают прозрачность работы ИТ для топов банка через запуск value stream. На входе была ситуация, когда руководство неплохо представляет, что происходит в проектах, такая культура в банке есть, но там задействована примерна 1/3 ИТ. А 2/3 были через пулы распределены по подразделениям бизнеса и чем именно они занимаются, руководству не понятно. Более того, как выяснилось в ходе проекта, бизнесу тоже было не понятно, бизнес с ИТ не общался, и обе стороны имели не высокое мнение о другом, как это часто бывает. А еще бизнес с удивлением выяснял суммы, в которые ему обходится ИТ-пул — бухгалтерия это распределяла на общие расходы, а в управленческой отчетности это не светили.
Средство решения — реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим — 10-15 команд. За 2024 запустили 13 value stream, на следующий год — еще столько же. Запуск — это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам — актуализация целей и задач на следующий год.
Получили:
- Структурирование работ, и людей по направлением
- У всех — единая мотивация
- Управление достижением цели
- value stream — продуктовые, операционные, процессные.
- Связь между целями и результатами деятельности. Воронка продаж, экономика
- Метрики — cycle time, ttm, радар agile-здоровья и оценка зрелости
Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems Replacement
Банк меняет основную систему, которая обрабатывает 15 м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику.
Как декомпозировать?
- Если есть продукты — их можно выделять. привлечение, размещение
- По процессам. Вокруг таких систем есть системы-сателлиты, можно брать из них.
- По потребителям данных. Самый молодой и массовый стрим, там сложно.
В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта — депозиты ФЛ. На стрим — менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.
На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда — продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.
Как управлять таким переносом?
- Делать на маленькие шаги
- Исследовать через поставку
- Ставить целью спринта приближение к target-архитектуре
- Находить возможность parallel run
- Работать с потребителем данных
Сергей Паршиков. Оценка производительности команды в корпоративной среде
Доклад — summary личного опыта в разных компаниях. Основная идея: волюнтаризм руководителя — зло, потому что рождает обиды. Нужна прозрачная система, о которой договорились. На мой взгляд, основная ценность в другом, автоматические системы есть у многих, и волюнтаризм руководителя — средство исправить их перекосы. А фишка этой системы — dashboard, где показатели можно смотреть оперативно и корректировать свое поведение, а если система дает странные результаты — то можно вести анализ и корректировать систему не дожидаясь, пока она сработает с обидами. Плюс — команда же сама договорилась о такой системе. Сергей говорил в докладе, но без акцентов.
Теперь подробнее. Для начала — каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они:
- Интересные задачи. Всех заставляют заниматься рутиной. Ему везло — предлагали много свободы.
- Клевый коллектив
- Достойная оплата труда
- Комфортные условия работы
Если условия обеспечили — можно начинать требовать. Заряженные сотрудники — это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки.
С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять — объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.
Когда он придумывал систему, то держал две метафоры.
- Самомотивация — игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям
- Бежать за чемпионами — смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.
Что входит в квартальную оценку?
- Продуктовые и бизнес-метрики — это всем понятно
- Голос клиента — это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
- Эффективность производство — на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
- eNPS: Критика — нейтральное — промоутеры. Формула: Промоутеры — Критика.
- Visibility — публичные выступления. Когда ты подталкиваешь выступать — ты подталкиваешь к выбору интересных задач. А еще — писать в корпоративный час о запуске фич — внутренняя видимость. Это реально поменяло словарь — когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.
Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все.
Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится — систему можно менять. Открытые оценки и сравнение — команды начали сравнивать, задавать вопросы — и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.
Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
Рассказ о запуске value stream для 20+ команд (100+ человек) внутренней автоматизации. Цель — получить для 80 % инициатив TTM от идеи до результата не более месяца. Проблема TTM связана с тем, что многие идеи требуют для реализации согласованных доработок в нескольких продуктах, а команды не умели корректно работать с зависимостями, и зависшая задача с невысоким приоритетом в одной из команд могла приводить к тому, что продукт в целом не выпускается.
При этом у команд — неоднородные бэлоги, задачи могут прилетать от разных источников.
- ЛПР, которые развивают бизнес — бэклог эпиков.
- Пользователи — носители улучшений, командные бэклоги.
- Проактивная модель для реализации ИТ-инициатив.
Попытка в результате исследований сразу структурировать на несколько независимых потоков успехом не увенчалась, так что первый value stream запускали сразу на 17 команд. Было сложно, так как команды очень неоднородны, все стартуют с разных позиций. Но от паервого планирвоания получили мгновенную пользу: выяснилось, что одна из немаленьких задач пошла сразу в две команды — дубль убрали. А еще участие в планировании — эффективный способ получения комплексной картины, в том числе для новичков. И в ходе первого квартала часть команд и продуктов увидело пользу, а не бюрократию.
На второй квартал добавили еще 5-10 команд, часть из них работали в классическом проектном подходе — проверяли может, они смогут встроиться. Не смогли, и на мой взгляд этого следовало ожидать, таких чудес не бывает. При этом в команды идет набор сотрудников, с рынка приходят сторонники проектного подхода, идет сопротивление, с этим надо работать. И явно проявилась проблема, что поставка конкретных фич для команды более приоритетна, чем достижение целей, то есть комплексное закрытие эпиков, с ней продолжают работать. И культура, что надо не просто выкатить фичу, а увидеть позитивную реакцию пользователей пока отсутствует. И еще обнаружили, что по каким-то инициативам обратная связь от пользователей может приходить долго, через 3-6 месяцев, то есть это не укладывается в картальный такт.
Зато по результатам двух планирований получилось структурировать работы и поделить один value train на пять, более сбалансированных, и третий квартал запускали уже по ним.
Проблемы на внедрении — достаточно понятные.
- Люди привыкли вести инициативы в разных местах: бэклоги, записные книжки, Excel, сбор в одном место воспринимался как непонятный формализм. Но собрали.
- Вопрос «зачем делать конкретную фичу» вызывал стресс. Но бэклог таким образом реально сокращался.
- Метрики для измерения business value фичи, хотя бы в натуральных единицах — вызывает непонимание. Но на ретро получилось в некоторых командах показать пользу, как фичи развивают бизнес — и они планируют это развивать.
- Культура непрерывного исследования. До этого только 1-2 команды заглядывали вперед, сейчас почти все смотрят на следующий квартал заранее.
Прямое давление на команды вызывает формализм и сопротивление, учатся работать через создание среды, чтобы люди включались в изменения.
Видимый эффект — на четверть поднялись по предсказуемости поставки, но тут пока вышли на потолок. УМеньшили заморозку фич, раньше была одна на 2-3. сейчас одна на 5, но они считают, что многовато.
Будущие задачи: дух предпринимательства, изменение мышления стейкхолдеров, уход от Заказчик-подрядчик к одной команде, переход к крупными эпикам, возможно, смена бюджетирования от стримов к инициативам. Заново пересматривать стримы и делать воркшопы по идентификации.
Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
Евгений — Head of Portfolio Management в Поиске Яндекса, это 9000 сотрудников и сильно за 100 продуктов. Традиционное годовое бюджетное планирвоание сильно увеличивает TTM, так как надо ждать очередного цикла. Более частое перепланирвоание — дорого. Планирование только по инициативам в моменте требует резерва средств, кроме того потенциально порождает расфокус и незавершенку.
В рассказе был спектр вараинтов планирования и описание, к чему пришли.
- Периодичность.
- Квартальное перепланировние — гибко, это хорошо. Но может превращаться в вечную гонку перепланирования
- Годовое — можно нарисовать 100 excel — просто, и сочетается с бюджетом. Но не гибко.
- Непрерывное — идет постоянно и спокойно в заданном темпе, 1-3 месяца от идеи до реализации — но нужен пул ресурсов
- Подходы
- Zero based — вроде как эффективно, потмоу что полный фокус, но очень трудозатратно
- Только новые — гораздо легче, но есть расфокус и хвост незавершенки
- Бюджеты
- Сначала планируем, потом ищем бюджет на самое нужное — более прозрачно, но трудоемко
- Сначала бюджет, потом заполняем — легче, но сложно готовить
Пробовали разные комбинации. Пришли: годовое zero-based + непрерывное на новые инициативы. Если есть инициатива — приходят к ним. Классифицируют по размеру. Доупаковывают проект и прогоняем через challendge session — это предварительные защиты через топов смежных value stream, 5-6 человек. На выходе проект уходит — что доработать. Когда готово — уже инвестком. И в зависимости от величины, реализация сразу, если есть ресурсы, а если нет — то либо сразу на совет директоров, либо он ждет годового планирования.
Чего добились? Обошлись без доп.найма 600 человек, сократили время получения ресурсов с 6-9 месяцев до 1-2, запустили несоклько бизнесов, больше 20 в непрерывного планирования, больше 100 в рамках годового.
Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке
Алексей Грабарник — исполнительный вице-президент Газпромбанк. Agile-трансформация ГПБ — это 40+ стримов, 300+ команд, 1400+ поставок в квартал, ttm в среднем — 2 месяца. Управление портфелем — это оркестрация.
В этом году они много рассказывали на разных конференциях, подробности можно смотреть там, а в этом докладе был общий взгляд, включая уровень автоматизации разных процессов, который я пунктиром записывал.
Вопросы управления, которые раскрывались дальше:
- стратегия и целеполагание
- бюджеты
- управление произвдством
- контрольные отчеты
В agile нужно:
- помогать принимать решения со стратегией — связка стратегии и бэклога стримов
- создавать структуру управления, чтобы любые изменения быстро
- декомпозировать работу и не потерять управляемость
- делать на метриках и отслеживать результаты online
Системные изменения позволили:
- создать связь между стратегией и бэклогами в рамках годового бюджетирования и целеполагания
- быстро перераспределять бюджеты внутри
- видеть данные онлайн и фокусироваться на точках перераспределения
Вопросы, на которые надо ответить: какие события создать, как построить процессы, какова ваша роль в процессах?
Ценностное управление портфелем: определяете, что нужно организации, и управляете этим. Не просто, что какие-то объемы работ сделаны в срок, а постоянно смотрите на ценности, которые приносят сделанные работы.
Вопросы по стратегии.
- соответствуют ли планы стратегии
- сколько людей выделить
- прозволяет ли оргдизайн достичь целей
Это точка годового планирования и бюджетирования, каскадирование стратегии в бэклоги. И важно не просто смотреть на бюджеты, а проверять амбициозность целей и достаточность ресурсов.
Только единообразные подходы к оценке cost-income позволяет сравнивать окупаемость команд и проектов, и принимать решения. Важно вести дискуссию про достаточность компетенций для реализации, и на синхронизацию инициатив.
Вопрос: можно ли в текущей организационной компоновкк достичь поставленных целей?
Работа со стратегией — преимущественно ручная тема.
Гибкое и бережливое управление ресурсами.
- Как мы можем перераспределять ресурсы?
- Как можно запускать новое и отказываться от неактуального?
- Насколько идем в рамках годовых лимитов и нет ли рисков перерасхода
Для скорости эффективно делегирвоание решений руководителей стримов — это не должно требовать много ресурсов. Но руководитель портфеля должен челленджить и подтверждать соответствие стратегии — чтобы выдерживать комплексность. И нужен постоянный мониторинг.
Эта часть не должна быть строго документирована, тут вопрос достаточности для руководителей портфелей, и дешевых в создании.
Производство
- как содать ритмы, чтобы рзработка была полезна
- как консолидировать бэклоги и отслеживать прогресс
- как сделать взаимодействие с сервисными и контрлирующими подразделениями без доп.нагрузки
Тут нужна максимальная автоматизация. А для этого нужны общие правила для всех стримов по ведению бэклога, расчета эффектов и так далее. Это дает онлайн мониторинг, который позволяет выявлять и фокусирвоаться на проблемных точках, требующих внимания. И оценка здоровья команд: опросы, мониторинг метрик, коучинг Проблемы конкретных команд могут быть очень разные, по метрикам надо лишь увидеть, какие команды требуют внимания.
Это не строится с одного раза. Это итеративный процесс. И в нем — тоже смотрим, что ждет организация и дальше предлагаем решения — аналогично тому, чего ждем от команд. Каждый квартал — много изменений. Слышим обратную связь: где-то продукты жалуются на излишний формализм, разбираемся.
Начинали с различными практиками в каждой команде. На входе на примере багажа в аэропорту объяснили критерии эпика. Единый словарь занял год. Первое квартальное планирование была ручная валидация, на второй соотверствие 80 %, на третий — не потребовалось.
Бэклог — есть критерии по соотношению разных типов задач. Если он не соответствует — идет дискуссия, могут быть разные ситуации, и если это обосновано — то ОК. Но дальше если оно не исполняется — то они могут поднять красный флаг и обсудить, почему не соблюдаются договренности.
Процессы — из jira с единообразным ведением, и apache superset для dashboard. Бизнесовые задачи — тоже в jira, другой workflow, но эффекты считают так же.
Хакинга метрик в jira — не боятся, так как светофоры лишь привлекают внимание, а не дают выводы. А дальше дискуссия. И бизнес-результаты или счастье команды — не хакнишь, оно или есть, или его нет.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.