Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 652 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru |
Последний постВ понедельник 18.11 прошла конференция Enterprise Agile Russia-2024, два трека докладов и один трек мастер-классов. Особенность конференции — только доклады от крупных компаний о достаточно масштабном использовании Agile-методов крупными компаниями, из которых были все докладчики, докладов от консультантов не было. И не было докладов о пилотных внедрениях на несколько команд. Как объяснили организаторы, заявок о пилотах было много, но в однодневную конференцию все не уместишь. Если говорить об общем впечатлении, то примерно в 2012—2014 у меня сложилось четкое впечатление: все, кто всерьез решил использовать Agile-методы на уровне команд — успешно это делают, технология уже зрелая. А на этой конференции такое же впечатление сложилось про использование на уровне крупных компаний. Используют OKR для сихронизации и управления по целям, при чем где-то это на том уровне, что любые проекты вкедут с использованием OKR. Например, был доклад о том, как OKR использовали для проекта закрытия сегмента бизнеса с минимизацией потерь, а в результате сегмент получилось успешно перезапустить. А из SAFe, который так всеобъемлющ, что напоминает RUP от Agile, выделилось полезное ядро, которое используют для управления на больших масштабах:
В целом получается, что компания - не механистичный исполнительный механизм, а конструкция со свободными элементами, обладающими собственной волей, но действующими скоординировано. На этом я заканчиваю об общих впечатлениях, и перехожу к докладам. Часть из них я уже опубликовал на своем канале в ходе конференции, другие — не успел и включаю в отчет. Но надо понимать, что это — меньше половины всех докладов конференций, потому что треков — два, а еще на некоторых слотах я активно общался и доклады пропустил. Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только)Это был рассказ о работе с системой метрик, применяемый в hh, иллюстрированный конкретными примерами. Основная идея — метрики лишь показывают точки потенциальных проблем, и не автоматически, а после анализа показателей на предмет нежелательной динамики или соотношение метрик. А дальше нужно породить гипотезы — что может являться причинами, и проверить их через детальный анализ, погружение в реальную работу людей. При этом, если проблемы выявлены из общих метрик, то анализ ведут в каждом из сервисов, причины могут быть различны. Общие подтвержденные гипотезы становятся фокусом на уровне компании, частные — в сервисах, масштаб определяет приоритеты. В докладе было конкретной дерево метрик из двух групп — ресурсы и поток.
В докладе были примеры. Разбор с тем, что увидели рост времени АБ-тестирования — там были гипотезы. И со сроками 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, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам — актуализация целей и задач на следующий год. Получили:
Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems ReplacementБанк меняет основную систему, которая обрабатывает 15 м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику. Как декомпозировать?
В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта — депозиты ФЛ. На стрим — менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся. На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда — продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая. Как управлять таким переносом?
Сергей Паршиков. Оценка производительности команды в корпоративной средеДоклад — summary личного опыта в разных компаниях. Основная идея: волюнтаризм руководителя — зло, потому что рождает обиды. Нужна прозрачная система, о которой договорились. На мой взгляд, основная ценность в другом, автоматические системы есть у многих, и волюнтаризм руководителя — средство исправить их перекосы. А фишка этой системы — dashboard, где показатели можно смотреть оперативно и корректировать свое поведение, а если система дает странные результаты — то можно вести анализ и корректировать систему не дожидаясь, пока она сработает с обидами. Плюс — команда же сама договорилась о такой системе. Сергей говорил в докладе, но без акцентов. Теперь подробнее. Для начала — каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они:
Если условия обеспечили — можно начинать требовать. Заряженные сотрудники — это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки. С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять — объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит. Когда он придумывал систему, то держал две метафоры.
Что входит в квартальную оценку?
Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все. Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится — систему можно менять. Открытые оценки и сравнение — команды начали сравнивать, задавать вопросы — и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно. Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компаниюРассказ о запуске value stream для 20+ команд (100+ человек) внутренней автоматизации. Цель — получить для 80 % инициатив TTM от идеи до результата не более месяца. Проблема TTM связана с тем, что многие идеи требуют для реализации согласованных доработок в нескольких продуктах, а команды не умели корректно работать с зависимостями, и зависшая задача с невысоким приоритетом в одной из команд могла приводить к тому, что продукт в целом не выпускается. При этом у команд — неоднородные бэлоги, задачи могут прилетать от разных источников.
Попытка в результате исследований сразу структурировать на несколько независимых потоков успехом не увенчалась, так что первый value stream запускали сразу на 17 команд. Было сложно, так как команды очень неоднородны, все стартуют с разных позиций. Но от паервого планирвоания получили мгновенную пользу: выяснилось, что одна из немаленьких задач пошла сразу в две команды — дубль убрали. А еще участие в планировании — эффективный способ получения комплексной картины, в том числе для новичков. И в ходе первого квартала часть команд и продуктов увидело пользу, а не бюрократию. На второй квартал добавили еще 5-10 команд, часть из них работали в классическом проектном подходе — проверяли может, они смогут встроиться. Не смогли, и на мой взгляд этого следовало ожидать, таких чудес не бывает. При этом в команды идет набор сотрудников, с рынка приходят сторонники проектного подхода, идет сопротивление, с этим надо работать. И явно проявилась проблема, что поставка конкретных фич для команды более приоритетна, чем достижение целей, то есть комплексное закрытие эпиков, с ней продолжают работать. И культура, что надо не просто выкатить фичу, а увидеть позитивную реакцию пользователей пока отсутствует. И еще обнаружили, что по каким-то инициативам обратная связь от пользователей может приходить долго, через 3-6 месяцев, то есть это не укладывается в картальный такт. Зато по результатам двух планирований получилось структурировать работы и поделить один value train на пять, более сбалансированных, и третий квартал запускали уже по ним. Проблемы на внедрении — достаточно понятные.
Прямое давление на команды вызывает формализм и сопротивление, учатся работать через создание среды, чтобы люди включались в изменения. Видимый эффект — на четверть поднялись по предсказуемости поставки, но тут пока вышли на потолок. УМеньшили заморозку фич, раньше была одна на 2-3. сейчас одна на 5, но они считают, что многовато. Будущие задачи: дух предпринимательства, изменение мышления стейкхолдеров, уход от Заказчик-подрядчик к одной команде, переход к крупными эпикам, возможно, смена бюджетирования от стримов к инициативам. Заново пересматривать стримы и делать воркшопы по идентификации. Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении ЯндексаЕвгений — Head of Portfolio Management в Поиске Яндекса, это 9000 сотрудников и сильно за 100 продуктов. Традиционное годовое бюджетное планирвоание сильно увеличивает TTM, так как надо ждать очередного цикла. Более частое перепланирвоание — дорого. Планирование только по инициативам в моменте требует резерва средств, кроме того потенциально порождает расфокус и незавершенку. В рассказе был спектр вараинтов планирования и описание, к чему пришли.
Пробовали разные комбинации. Пришли: годовое zero-based + непрерывное на новые инициативы. Если есть инициатива — приходят к ним. Классифицируют по размеру. Доупаковывают проект и прогоняем через challendge session — это предварительные защиты через топов смежных value stream, 5-6 человек. На выходе проект уходит — что доработать. Когда готово — уже инвестком. И в зависимости от величины, реализация сразу, если есть ресурсы, а если нет — то либо сразу на совет директоров, либо он ждет годового планирования. Чего добились? Обошлись без доп.найма 600 человек, сократили время получения ресурсов с 6-9 месяцев до 1-2, запустили несоклько бизнесов, больше 20 в непрерывного планирования, больше 100 в рамках годового. Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в ГазпромбанкеАлексей Грабарник — исполнительный вице-президент Газпромбанк. Agile-трансформация ГПБ — это 40+ стримов, 300+ команд, 1400+ поставок в квартал, ttm в среднем — 2 месяца. Управление портфелем — это оркестрация. В этом году они много рассказывали на разных конференциях, подробности можно смотреть там, а в этом докладе был общий взгляд, включая уровень автоматизации разных процессов, который я пунктиром записывал. Вопросы управления, которые раскрывались дальше:
В agile нужно:
Системные изменения позволили:
Вопросы, на которые надо ответить: какие события создать, как построить процессы, какова ваша роль в процессах? Ценностное управление портфелем: определяете, что нужно организации, и управляете этим. Не просто, что какие-то объемы работ сделаны в срок, а постоянно смотрите на ценности, которые приносят сделанные работы. Вопросы по стратегии.
Это точка годового планирования и бюджетирования, каскадирование стратегии в бэклоги. И важно не просто смотреть на бюджеты, а проверять амбициозность целей и достаточность ресурсов. Только единообразные подходы к оценке cost-income позволяет сравнивать окупаемость команд и проектов, и принимать решения. Важно вести дискуссию про достаточность компетенций для реализации, и на синхронизацию инициатив. Вопрос: можно ли в текущей организационной компоновкк достичь поставленных целей? Работа со стратегией — преимущественно ручная тема. Гибкое и бережливое управление ресурсами.
Для скорости эффективно делегирвоание решений руководителей стримов — это не должно требовать много ресурсов. Но руководитель портфеля должен челленджить и подтверждать соответствие стратегии — чтобы выдерживать комплексность. И нужен постоянный мониторинг. Эта часть не должна быть строго документирована, тут вопрос достаточности для руководителей портфелей, и дешевых в создании. Производство
Тут нужна максимальная автоматизация. А для этого нужны общие правила для всех стримов по ведению бэклога, расчета эффектов и так далее. Это дает онлайн мониторинг, который позволяет выявлять и фокусирвоаться на проблемных точках, требующих внимания. И оценка здоровья команд: опросы, мониторинг метрик, коучинг Проблемы конкретных команд могут быть очень разные, по метрикам надо лишь увидеть, какие команды требуют внимания. Это не строится с одного раза. Это итеративный процесс. И в нем — тоже смотрим, что ждет организация и дальше предлагаем решения — аналогично тому, чего ждем от команд. Каждый квартал — много изменений. Слышим обратную связь: где-то продукты жалуются на излишний формализм, разбираемся. Начинали с различными практиками в каждой команде. На входе на примере багажа в аэропорту объяснили критерии эпика. Единый словарь занял год. Первое квартальное планирование была ручная валидация, на второй соотверствие 80 %, на третий — не потребовалось. Бэклог — есть критерии по соотношению разных типов задач. Если он не соответствует — идет дискуссия, могут быть разные ситуации, и если это обосновано — то ОК. Но дальше если оно не исполняется — то они могут поднять красный флаг и обсудить, почему не соблюдаются договренности. Процессы — из jira с единообразным ведением, и apache superset для dashboard. Бизнесовые задачи — тоже в jira, другой workflow, но эффекты считают так же. Хакинга метрик в jira — не боятся, так как светофоры лишь привлекают внимание, а не дают выводы. А дальше дискуссия. И бизнес-результаты или счастье команды — не хакнишь, оно или есть, или его нет. |
Блоги друзей |
