Версия 16:19, 21 ноября 2024

В понедельник 18.11 прошла конференция Enterprise Agile Russia-2024, два трека докладов и один трек мастер-классов. Особенность конференции — только доклады от крупных компаний о достаточно масштабном использовании Agile-методов крупными компаниями, из которых были все докладчики, докладов от консультантов не было. И не было докладов о пилотных внедрениях на несколько команд. Как объяснили организаторы, заявок о пилотах было много, но в однодневную конференцию все не уместишь.

Если говорить об общем впечатлении, то примерно в 2012—2014 у меня сложилось четкое впечатление: все, кто всерьез решил использовать Agile-методы на уровне команд — успешно это делают, технология уже зрелая. А на этой конференции такое же впечатление сложилось про использование на уровне крупных компаний. Используют OKR для сихронизации и управления по целям, при чем где-то это на том уровне, что любые проекты вкедут с использованием OKR. Например, был доклад о том, как OKR использовали для проекта закрытия сегмента бизнеса с минимизацией потерь, а в результате сегмент получилось успешно перезапустить.

А из SAFe, который так всеобъемлющ, что напоминает RUP от Agile, выделилось полезное ядро, которое используют для управления на больших масштабах:

1. PI Planning как средство масштабного планирования с взаимоной увязкой по зависимым проектам. Как показывает опыт, число участников хорошо организованной сессии может достигать тысяч человек, и они работают конструктивно, создавая за два дня реалистичный план.
2. Value stream train, которые обеспечивают переход от управления потоками задач, измеряемыми объемом выполненных работ, к управлению потоками создания ценности, который оценивается по ценности для бизнеса и потребителя. При этом обеспечивается трассировка создаваемой ценности до стратегии компании. И это — принципиально другой уровень управления. чем классическое управление потоком работ или проектами, в классических проектах тоже главное — выполнить объем работ, а не достигнуть бизнес-результата.

На этом я заканчиваю об общих впечатлениях, и перехожу к докладам. Часть из них я уже опубликовал на своем канале в ходе конференции, другие — не успел и включаю в отчет. Но надо понимать, что это — меньше половины всех докладов конференций, потому что треков — два, а еще на некоторых слотах я активно общался и доклады пропустил.

Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только)

Это был рассказ о работе с системой метрик, применяемый в hh, иллюстрированный конкретными примерами. Основная идея — метрики лишь показывают точки потенциальных проблем, и не автоматически, а после анализа показателей на предмет нежелательной динамики или соотношение метрик. А дальше нужно породить гипотезы — что может являться причинами, и проверить их через детальный анализ, погружение в реальную работу людей. При этом, если проблемы выявлены из общих метрик, то анализ ведут в каждом из сервисов, причины могут быть различны. Общие подтвержденные гипотезы становятся фокусом на уровне компании, частные — в сервисах, масштаб определяет приоритеты.

В докладе было конкретной дерево метрик из двух групп — ресурсы и поток.

1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход — целевая метрика)

1.2. Распределение ресурсов: стратегия, продукт, тех.налог, прочее. Классификация задач, дальше корректируется продуктом, так как большие задачи могут перекашивать.

2.1. 85 % lead time feature. Полный — от discovery, постановки до АБ тест и пост-продакшн. 85 выбрано ретроспективно из анализа.

2.2. Эффективность потока — блокеры.

2.3. Средняя пропускная способность за неделю

В докладе были примеры. Разбор с тем, что увидели рост времени АБ-тестирования — там были гипотезы. И со сроками discovery в одном из потоков — она была волатильна и коррелировала с отпусками и болезнями, то есть мощности команды явно не хватало на стандартный поток и они добавили человека. При этом нет задачи работать на конкретную метрику, например, увеличение lead time — нормальная вещь, если поставлена задача улучшить фазу discovery. Метрики — лишь сигнал, а дальше надо погружаться, не работать напрямую. Именно люди работают с процессом и знают как поменять.

И в конце — шаги работы с метриками.

1. Начать собирать метрики
2. Анализ и генерацию гипотез
3. Провести анализ сервиса — проверить гипотезы
4. Фокусы для сервисов
5. Общие гипотезы для всех сервисов
6. Задачи для всех и для конкретных сервисов

Анна Аверьянова из Робофинанс. Как 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 — не боятся, так как светофоры лишь привлекают внимание, а не дают выводы. А дальше дискуссия. И бизнес-результаты или счастье команды — не хакнишь, оно или есть, или его нет.