Изменения

{{Conf-Ref}}В понедельник 18.11 прошла конференция [https://enterprise-agile.ru/ '''Enterprise Agile Russia-2024'''], два трека докладов и один трек мастер-классов. Особенность конференции - конференции — только доклады от крупных компаний о достаточно масштабном использовании Agile-методов крупными компаниями, из которых были все докладчики, докладов от консультантов не было. И не было докладов о пилотных внедрениях на несколько команд. Как объяснили организаторы, заявок о пилотах было много, но в однодневную конференцию все не уместишь.

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

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

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

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

В докладе было конкретной дерево метрик из двух групп - групп — ресурсы и поток. : 1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход - доход — целевая метрика)

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

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

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

# Провести анализ сервиса - сервиса — проверить гипотезы

= Анна Аверьянова из Робофинанс. Как OKR помог перезапустить бизнес! =

У Робофинанс с 2016 был бизнес в Испании - Испании — online выдача кредитов, в 2020 случился ковид, мораторий на платежи кредитов, с одной стороны, а с другой - другой — поддержка ликвидности и онлайн. Они продолжили бизнес, но в 2021 выяснилось, что люди набирают кредиты и не платят. Поэтому по итогам года инвестор, он же владелец и ген.дир принял решения о закрытии бизнеса. Но такой бизнес нельзя закрыть одним днем, надо соблюсти требования регулятора, иначе можно лишиться лицензии и для других сегментов бизнеса. Поэтому был процесс на год, который решили вести по OKR, как и все остальное. Цель понятна - понятна — минимизация потерь. Было сделано 3 сценария от команды: реалистичный, негативный и позитивный. И в конце первого квартала увидели по метрикам, что развитие идет лучше даже оптимистичного сценария, и в принципе динамика позволяет предположить, что за год можно будет сохранить команду и выйти в плюс. Они пошли к владельцу, показали цифры, получили добро на попытку сохранения и поменяли цель. И у них получилось. У команды был стимул - стимул — им нравилось работать вместе и они точно хотели сохраниться. А пост-анализ показывает, что сыграли два внешних фактора: поменялся рынок потребления, то есть тех, кто брал кредиты, при этом часть конкурентов с рынка ушла. А OKR позволил во-время заметить изменение трендов, и пересобрать продукт под новый рынок.

В PwC большое количество ИТ-системы были от головной компании. Поверх них кое-где были собственные решения с российской спецификой. Когда российская часть разводилась с головной, у него осталось лоскутное одеяло этих решений, а чтобы не допустить остановки бизнеса - бизнеса — перешли не Excel. А дальше надо было реанимировать ситуацию, и в компании создали центр продуктовой экспертизы, чтобы сделать это системно. Марина - Марина — его руководитель, в центре собраны архитекторы, devops, юридическое обеспечение и ряд других компетенций, а разработка идет отдельными командами, которую центр поддерживает. И еще просвещает в части продуктового подхода и unit-экономики. И у них получилось не просто разработать продукты, поддерживающие работу компании, но и начать выводить их на рыноК PwC этого вообще не делало. Такая вот success story. О конструкции разработки и функциях центра Марина рассказывала, но очень пунктиром, на слайдах подробности есть.

Одна из существенных черт Agile-методов - методов — прозрачность. И рассказ был о том, как обеспечивают прозрачность работы ИТ для топов банка через запуск value stream. На входе была ситуация, когда руководство неплохо представляет, что происходит в проектах, такая культура в банке есть, но там задействована примерна 1/3 ИТ. А 2/3 были через пулы распределены по подразделениям бизнеса и чем именно они занимаются, руководству не понятно. Более того, как выяснилось в ходе проекта, бизнесу тоже было не понятно, бизнес с ИТ не общался, и обе стороны имели не высокое мнение о другом, как это часто бывает. А еще бизнес с удивлением выяснял суммы, в которые ему обходится ИТ-пул - пул — бухгалтерия это распределяла на общие расходы, а в управленческой отчетности это не светили.

Средство решения - решения — реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - стрим — 10-15 команд. За 2024 запустили 13 value stream, на следующий год - год — еще столько же. Запуск - Запуск — это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - результатам — актуализация целей и задач на следующий год.

Получили:

* У всех - всех — единая мотивация

* value stream - stream — продуктовые, операционные, процессные.

* Метрики - Метрики — cycle time, ttm, радар agile-здоровья и оценка зрелости

Банк меняет основную систему, которая обрабатывает 15м 15 м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику.

Как декомпозировать? * Если есть продукты - продукты — их можно выделять. привлечение, размещение

В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - продукта — депозиты ФЛ. На стрим - стрим — менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.

На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - команда — продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.

Доклад - Доклад — summary личного опыта в разных компаниях. Основная идея: волюнтаризм руководителя - руководителя — зло, потому что рождает обиды. Нужна прозрачная система, о которой договорились. На мой взгляд, основная ценность в другом, автоматические системы есть у многих, и волюнтаризм руководителя - руководителя — средство исправить их перекосы. А фишка этой системы - системы — dashboard, где показатели можно смотреть оперативно и корректировать свое поведение, а если система дает странные результаты - результаты — то можно вести анализ и корректировать систему не дожидаясь, пока она сработает с обидами. Плюс - Плюс — команда же сама договорилась о такой системе. Сергей говорил в докладе, но без акцентов.

Теперь подробнее. Для начала - начала — каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они: * Интересные задачи. Всех заставляют заниматься рутиной. Ему везло - везло — предлагали много свободы.

Если условия обеспечили - обеспечили — можно начинать требовать. Заряженные сотрудники - сотрудники — это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно  Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки.

С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять - понять — объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.

Когда он придумывал систему, то держал две метафоры. * Самомотивация - Самомотивация — игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям* Бежать за чемпионами - чемпионами — смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.

Что входит в квартальную оценку? * Продуктовые и бизнес-метрики - метрики — это всем понятно* Голос клиента - клиента — это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.* Эффективность производство - производство — на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.* eNPS: Критика - нейтральное - Критика — нейтральное — промоутеры. Формула: Промоутеры - Промоутеры — Критика. * Visibility - Visibility — публичные выступления. Когда ты подталкиваешь выступать - выступать — ты подталкиваешь к выбору интересных задач. А еще - еще — писать в корпоративный час о запуске фич - фич — внутренняя видимость. Это реально поменяло словарь - словарь — когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.

Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится - нравится — систему можно менять. Открытые оценки и сравнение - сравнение — команды начали сравнивать, задавать вопросы - вопросы — и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.

Рассказ о запуске value stream для 20+ команд (100+ человек) внутренней автоматизации. Цель - Цель — получить для 8080 % инициатив TTM от идеи до результата не более месяца. Проблема TTM связана с тем, что многие идеи требуют для реализации согласованных доработок в нескольких продуктах, а команды не умели корректно работать с зависимостями, и зависшая задача с невысоким приоритетом в одной из команд могла приводить к тому, что продукт в целом не выпускается.

При этом у команд - команд — неоднородные бэлоги, задачи могут прилетать от разных источников. * ЛПР, которые развивают бизнес - бизнес — бэклог эпиков.* Пользователи - Пользователи — носители улучшений, командные бэклоги.

Попытка в результате исследований сразу структурировать на несколько независимых потоков успехом не увенчалась, так что первый value stream запускали сразу на 17 команд. Было сложно, так как команды очень неоднородны, все стартуют с разных позиций. Но от паервого планирвоания получили мгновенную пользу: выяснилось, что одна из немаленьких задач пошла сразу в две команды - команды — дубль убрали. А еще участие в планировании - планировании — эффективный способ получения комплексной картины, в том числе для новичков. И в ходе первого квартала часть команд и продуктов увидело пользу, а не бюрократию.

На второй квартал добавили еще 5-10 команд, часть из них работали в классическом проектном подходе - подходе — проверяли может, они смогут встроиться. Не смогли, и на мой взгляд этого следовало ожидать, таких чудес не бывает. При этом в команды идет набор сотрудников, с рынка приходят сторонники проектного подхода, идет сопротивление, с этим надо работать. И явно проявилась проблема, что поставка конкретных фич для команды более приоритетна, чем достижение целей, то есть комплексное закрытие эпиков, с ней продолжают работать. И культура, что надо не просто выкатить фичу, а увидеть позитивную реакцию пользователей пока отсутствует. И еще обнаружили, что по каким-то инициативам обратная связь от пользователей может приходить долго, через 3-6 месяцев, то есть это не укладывается в картальный такт.

Зато по результатам двух планирований получилось структурировать работы и поделить один value train на пять, более сбалансированных, и третий квартал запускали уже по ним.

Проблемы на внедрении - внедрении — достаточно понятные. * Люди привыкли вести инициативы в разных местах: бэклоги, записные книжки, Excel, сбор в одном место воспринимался как непонятный формализм. Но собрали. * Вопрос "зачем «зачем делать конкретную фичу" фичу» вызывал стресс. Но бэклог таким образом реально сокращался.* Метрики для измерения business value фичи, хотя бы в натуральных единицах - единицах — вызывает непонимание. Но на ретро получилось в некоторых командах показать пользу, как фичи развивают бизнес - бизнес — и они планируют это развивать.

Прямое давление на команды вызывает формализм и сопротивление, учатся работать через создание среды, чтобы люди включались в изменения.

Видимый эффект - эффект — на четверть поднялись по предсказуемости поставки, но тут пока вышли на потолок. УМеньшили заморозку фич, раньше была одна на 2-3. сейчас одна на 5, но они считают, что многовато.

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

Евгений - Евгений — Head of Portfolio Management в Поиске Яндекса, это 9000 сотрудников и сильно за 100 продуктов. Традиционное годовое бюджетное планирвоание сильно увеличивает TTM, так как надо ждать очередного цикла. Более частое перепланирвоание - перепланирвоание — дорого. Планирование только по инициативам в моменте требует резерва средств, кроме того потенциально порождает расфокус и незавершенку.

В рассказе был спектр вараинтов планирования и описание, к чему пришли. * Периодичность. ** Квартальное перепланировние - перепланировние — гибко, это хорошо. Но может превращаться в вечную гонку перепланирования** Годовое - Годовое — можно нарисовать 100 excel - excel — просто, и сочетается с бюджетом. Но не гибко. ** Непрерывное - Непрерывное — идет постоянно и спокойно в заданном темпе, 1-3 месяца от идеи до реализации - реализации — но нужен пул ресурсов

** Zero based - based — вроде как эффективно, потмоу что полный фокус, но очень трудозатратно ** Только новые - новые — гораздо легче, но есть расфокус и хвост незавершенки* Бюджеты ** Сначала планируем, потом ищем бюджет на самое нужное - нужное — более прозрачно, но трудоемко** Сначала бюджет, потом заполняем - заполняем — легче, но сложно готовить

Пробовали разные комбинации. Пришли: годовое zero-based + непрерывное на новые инициативы. Если есть инициатива - инициатива — приходят к ним. Классифицируют по размеру. Доупаковывают проект и прогоняем через challendge session - session — это предварительные защиты через топов смежных value stream, 5-6 человек. На выходе проект уходит - уходит — что доработать. Когда готово - готово — уже инвестком. И в зависимости от величины, реализация сразу, если есть ресурсы, а если нет - нет — то либо сразу на совет директоров, либо он ждет годового планирования.

Чего добились? Обошлись без доп.найма 600 человек, сократили время получения ресурсов с 6-9 месяцев до 1-2, запустили несоклько бизнесов, больше 20 в непрерывного планирования, больше 100 в рамках годового.

Алексей Грабарник - Грабарник — исполнительный вице-президент Газпромбанк. Agile-трансформация ГПБ - ГПБ — это 40+ стримов, 300+ команд, 1400+ поставок в квартал, ttm в среднем - среднем — 2 месяца. Управление портфелем - портфелем — это оркестрация.

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

В agile нужно: * помогать принимать решения со стратегией - стратегией — связка стратегии и бэклога стримов

Системные изменения позволили:

Вопросы по стратегии.

Только единообразные подходы к оценке cost-income позволяет сравнивать окупаемость команд и проектов, и принимать решения. Важно вести дискуссию про достаточность компетенций для реализации, и на синхронизацию инициатив.

Вопрос: можно ли в текущей организационной компоновкк достичь поставленных целей?

Работа со стратегией - стратегией — преимущественно ручная тема.

Гибкое и бережливое управление ресурсами.

Для скорости эффективно делегирвоание решений руководителей стримов - стримов — это не должно требовать много ресурсов. Но руководитель портфеля должен челленджить и подтверждать соответствие стратегии - стратегии — чтобы выдерживать комплексность. И нужен постоянный мониторинг.

Эта часть не должна быть строго документирована, тут вопрос достаточности для руководителей портфелей, и дешевых в создании.

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

Это не строится с одного раза. Это итеративный процесс. И в нем - нем — тоже смотрим, что ждет организация и дальше предлагаем решения - решения — аналогично тому, чего ждем от команд. Каждый квартал - квартал — много изменений. Слышим обратную связь: где-то продукты жалуются на излишний формализм, разбираемся.

Начинали с различными практиками в каждой команде. На входе на примере багажа в аэропорту объяснили критерии эпика. Единый словарь занял год. Первое квартальное планирование была ручная валидация, на второй соотверствие 8080 %, на третий - третий — не потребовалось.

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

Процессы - Процессы — из jira с единообразным ведением, и apache superset для dashboard. Бизнесовые задачи - задачи — тоже в jira, другой workflow, но эффекты считают так же.

Хакинга метрик в jira - jira — не боятся, так как светофоры лишь привлекают внимание, а не дают выводы. А дальше дискуссия. И бизнес-результаты или счастье команды - команды — не хакнишь, оно или есть, или его нет.