7324
правки
Изменения
Новая страница: «В понедельник 18.11 прошла конференция [https://enterprise-agile.ru/ '''Enterprise Agile Russia-2024'''], два трека докл…»
В понедельник 18.11 прошла конференция [https://enterprise-agile.ru/ '''Enterprise Agile Russia-2024'''], два трека докладов и один трек мастер-классов. Особенность конференции - только доклады от крупных компаний о достаточно масштабном использовании Agile-методов крупными компаниями, из которых были все докладчики, докладов от консультантов не было. И не было докладов о пилотных внедрениях на несколько команд. Как объяснили организаторы, заявок о пилотах было много, но в однодневную конференцию все не уместишь.
Если говорить об общем впечатлении, то примерно в 2012-2014 у меня сложилось четкое впечатление: все, кто всерьез решил использовать Agile-методы на уровне команд - успешно это делают, технология уже зрелая. А на этой конференции такое же впечатление сложилось про использование на уровне крупных компаний. Используют '''OKR для сихронизации и управления по целям''', при чем где-то это на том уровне, что любые проекты вкедут с использованием OKR. Например, был доклад о том, как OKR использовали для проекта закрытия сегмента бизнеса с минимизацией потерь, а в результате сегмент получилось успешно перезапустить.
А '''из SAFe''', который так всеобъемлющ, что напоминает RUP от Agile, '''выделилось полезное ядро''', которое используют для управления на больших масштабах:
# '''PI Planning''' как средство масштабного планирования с взаимоной увязкой по зависимым проектам. Как показывает опыт, число участников хорошо организованной сессии может достигать тысяч человек, и они работают конструктивно, создавая за два дня реалистичный план.
# '''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. Метрики - лишь сигнал, а дальше надо погружаться, не работать напрямую. Именно люди работают с процессом и знают как поменять.
И в конце - шаги работы с метриками.
# Начать собирать метрики
# Анализ и генерацию гипотез
# Провести анализ сервиса - проверить гипотезы
# Фокусы для сервисов
# Общие гипотезы для всех сервисов
# Задачи для всех и для конкретных сервисов
= Анна Аверьянова из Робофинанс. Как 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 - не боятся, так как светофоры лишь привлекают внимание, а не дают выводы. А дальше дискуссия. И бизнес-результаты или счастье команды - не хакнишь, оно или есть, или его нет.
{{wl-publish: 2024-11-21 16:19:17 +0300 | MaksTsepkov }}
Если говорить об общем впечатлении, то примерно в 2012-2014 у меня сложилось четкое впечатление: все, кто всерьез решил использовать Agile-методы на уровне команд - успешно это делают, технология уже зрелая. А на этой конференции такое же впечатление сложилось про использование на уровне крупных компаний. Используют '''OKR для сихронизации и управления по целям''', при чем где-то это на том уровне, что любые проекты вкедут с использованием OKR. Например, был доклад о том, как OKR использовали для проекта закрытия сегмента бизнеса с минимизацией потерь, а в результате сегмент получилось успешно перезапустить.
А '''из SAFe''', который так всеобъемлющ, что напоминает RUP от Agile, '''выделилось полезное ядро''', которое используют для управления на больших масштабах:
# '''PI Planning''' как средство масштабного планирования с взаимоной увязкой по зависимым проектам. Как показывает опыт, число участников хорошо организованной сессии может достигать тысяч человек, и они работают конструктивно, создавая за два дня реалистичный план.
# '''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. Метрики - лишь сигнал, а дальше надо погружаться, не работать напрямую. Именно люди работают с процессом и знают как поменять.
И в конце - шаги работы с метриками.
# Начать собирать метрики
# Анализ и генерацию гипотез
# Провести анализ сервиса - проверить гипотезы
# Фокусы для сервисов
# Общие гипотезы для всех сервисов
# Задачи для всех и для конкретных сервисов
= Анна Аверьянова из Робофинанс. Как 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 - не боятся, так как светофоры лишь привлекают внимание, а не дают выводы. А дальше дискуссия. И бизнес-результаты или счастье команды - не хакнишь, оно или есть, или его нет.
{{wl-publish: 2024-11-21 16:19:17 +0300 | MaksTsepkov }}
