2022-11-23: Agile-управление крупными корпорациями - конференция Enterprise Agile

Короткая ссылка: AgileEnterprise-2022

Ссылки сюда (1) →

О других конференциях

В понедельник 21.11 прошла очередная конференция Enterprise Agile Russia (видео). Конференция была супердинамичная, на доклад с вопросами и перерывом отводилось 30 минут: 20 на доклад, еще 5 на вопросы и 5 на перерыв. Так жестко спикеры не укладывались, но поскольку потом начинался следующий доклад, то в целом получасовые слоты соблюдались. Понятно, что за такое время сложный проект можно изложить только пунктиром, так что спикеры со слушателями уходили в зону обсуждения, с юмором названную организаторами пыточной, где отвечали на вопросы с пристрастием. На конференции было два трека докладов, трек мастер-классов и трек просветительских лекций. Я, как обычно, публиковал заметки в телеграм, но успел только по части докладов. А теперь публикую отчет по горячим следам.

Конференция была посвящена изменениям крупных компаний за счет применения Agile-методов, прежде всего SAFe и OKR. Я хочу заметить, что у меня лично - скептическое отношение к SAFe ввиду его большой сложности, так же как и к более традиционному проектному управлению по PMBOK. Но это скепсис в том смысле, что нет гарантий результата, и есть большие сложности в применении. С другой стороны, опираясь на услышанное, я признаю, что в SAFe видно много полезных практик, решающих задачи управления на большом масштабе. Кроме того, его применение принципиально меняет управленческое мышление в нескольких аспектах. Во-первых, в части признания ценностей Agile, на которые он опирается в части культуры, в том числе потому, что внутри на уровне команд лежит Scrum. А во-вторых - в части перехода от работы с потоком задач которые надо сделать к мышлению потоком ценности, которую надо создать, и этим он позитивно отличается от проектного управления. И, в третьих, он безусловно ломает и размораживает застывшие бюрократизированные структуры.

Что касается инсайтов конференции, то я хочу отметить рассказ РТ Лабс, которая разрабатывает софт электронного правительства, вершиной которого является портал госуслуг, о том, как устроено квартальное планирование. Процедура интересная, но инсайт в другом. По сути заказчики в лице министра и его замов признали, что скорость разработки софта, которая определяет темп изменений государственного управления, определяется разработчиками. Перед ними можно ставить любые задачи и приоритеты, но решение о том, что из этого они успеют за квартал, должны принимать они сами, а заказчику остается лишь с этим смириться. Потому что если не смиряться, то, во-первых, пообещают, но все равно не сделают, а, во-вторых, из-за работы в режиме подвига и стресса будут массово увольняться, и негатив этого вдолгую будет превосходить локальный выигрыш, достигаемый за счет давления на разработчиков. И это - принципиальное изменение в понимании ИТ-разработки заказчиками такого высокого уровня. Оно есть не только там, просто в этом докладе проявилось отчетливо. Хотя в самом докладе этого тезиса не было, это - мое осмысление.

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

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

Disclaimer: Заметки - с голоса, могут быть неточности и неверные интерпретации
Пост на FB в моей ленте Пост в группе Enterprise Agile Пост в группе AgileRussia

Евгения Меньшикова из ВТБ. Журавль в руке: опыт трансформации процессов производства ПО

Вид сверху на трансформацию ВТБ за последние три года с 2019, за которое ИТ увеличилось с 3 до 20 тысяч человек, при этом они сильно ускорились, перейдя от 4 релизов в год с ТТМ 9 месяцев к непрерывной поставки софта и ТТМ около месяца. Для перехода к непрерывной поставки пришлось существенно изменить ИТ-ландшафт: легаси-системы, которые были на входе для этого не пригодны. У трансформации было несколько особенностей:

• Цели - бизнесовые, были поставлены перед банком в 2019 в 1.5 раза розницы, вдвое средний и мелкий бизнес при росте дохода на 15-35% при этом сохранить сегмент крупного бизнеса.
• Команда была уверена, что ключ успеха - в Agile-методах. При этом в банке Agile был дискредитирован предыдущим опытом, били пилоты, которым не удалось взлететь. Поэтому фокус был на бизнес-целях, не на методах.
• Трансформация по площади и на всех уровнях - потому что этап островов уже проходили. При этом идти этапами по полгода, с конкретными целями на каждый этап, и сначала - расшатывание ситуации.
• Принципы, о которых договорились: фокус на создании ценности - поддержке бизнеса; совместная работа; инкрементальность; измеряемость; универсальность; надежность автоматизации и инфобезопасность.
• Смешанная структура программ и проектов с продуктовыми стримами. Синхронные изменения многими участниками, и синхронизация. На некоторые стримы - 3-4 программы, развитие продукта + технологические изменения и т.п. Стримы вокруг продуктов их удерживают.
• На входе была разобщенность ИТ и бизнеса. Поэтому вместо принципа единственного product owner - правило двух ключей: ИТ + бизнеса. Проследили консенсус, и пропорции в целеполагании: 50-70 бизнес, 30-50 технологические.
• Надо менять не только change, но и run, и единая модель управления для обоих, единый такт работы. По факту run всегда на такт позже, но все равно вместе, вовлечение стримов сопровождения с первого планирования.
• Как вовлекаем? Постоянное общение. Townhall - сотрудники говорят с менеджерами, не в варианте "начальники решили - я делаю". Линия поддержки, включая методологию изменений, регулярные обучающие сессии. Гильдии, сначала SM, потом на остальное. Телега и развлекательно-информационный контент. Активности по рассказу.
• Прозрачность. 3d-мониторинг viewpoint: программа, архитектура, стрим, команда. Все дашборды доступны всем.
• Метрику NPS сотрудников - не вводили, пациента на хирургическом столе глупо спрашивать, доволен ли он, и ориентироваться на его мнение проводя операцию. Но все время спрашивали "что не так", и эту обратную связь обрабатывают.

Команда трансформации: начинали в 2019 15 человек, и команда по методологии продолжает оставаться небольшой. А команда внутренней автоматизации, инженерные практики, мониторинг - около 400.

В комментариях в телеграм говорили, что звучит, конечно, интересно, но по опыту знакомых разработчиков ВТБ масштабных изменений на уровне команд не видно. Я тут хочу отметить, что на таком масштабе все зависит от конкретной команды. Легаси-системы никуда не делись, их не заменили целиком, и у тех, кто их поддерживает, наверное, многое осталось по-старому. А в новых командах и развивающихся сегментах бизнеса изменений может быть больше. В любом случае, рост численности ИТ в семь раз с сохранением приемлемой управляемости и результативности является достижением сам по себе.

Виктор Редров и Илья Бушмелев из РТ Лабс. Как SAFe помогает выполнять задачи государственной важности и иногда немного спать

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

А если говорить про детали, то доклад был посвящен устройству процесса планирования на 100+ команд и 2000 сотрудников, при этом между отдельными сервисами в продукте - сильные связи. Это трехдневная сессия, в которой очно участвует 400 человек от компании и Минцифры, и еще 1000 участвует online. Стандартный формат PI SAFe дополнен тактом согласования квартальных планов с министром и заместителями, которое начинается после получения финальных презентаций в 16 часов строго дня и идет вечер второго и третий день. В докладе и презентации этот процесс показан очень детально, с этапами, промежуточными точками и контрольными вопросами по ним. Презентации уже доступны в программе конференции, так что можно смотреть. Что важно, результат планирования - это не просто набор фич у каждой команды, формируются цели и ключевые результаты, в соответствии с подходом OKR и привязка к ним реализуемых фич. Для технической поддержки сделано решение, которое позволяет формировать презентации на основе задач в Jira.

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

Анна Крюкова из Росбанка. Инвестируя в гильдии, инвестируем в развитие всего банка

Росбанк в какой-то момент решил отдать ИТ в бизнес-блоки, и было понятно, что будут побочные эффекты из-за замыкания экспертов в рамках своей команды. Инструмент решения - гильдии, которые попробовали сделать на самоорганизации, за счет инициативы сотрудников, без выделенных деврелов, которые бы курировали каждую гильдию. Ответ - утвердительный, самоорганизация работает, и даже после кризисов движение возобновляется. Анна - единственный человек во всем банке, которая полностью занимается гильдиями, все остальное - на инициативе и добровольном участии. Сейчас 13 гильдий, более 100 сотрудников активно участвуют, не просто приходят на встречи, а создают какие-то продукты.

Принципы

• Гильдия - про самоорганизацию. Не централизованное создание. И на инициативе - не ставят задачи
• Инвестируешь в гильдию - инвестируешь в себя.
• Гильдия - это по любви. И никто не обязан вступать в гильдию.

Этапы жизни гильдии, начинается с запуска.

• Желание сотрудника запустить гильдию. У кого инициатива - пишет. Вопрос - насколько кросскомандная.
• Появляется лидер гильдии - еще до запуска. HR помогают найти экспертов в командах - получается рабочая группа.
• Проводят общую встречу, гильдия появляется.
• Этап строительства. У каждой гильдии есть чек-лист: цели, правила, площадки коммуникации, идентичность, матрица компетенций...
• Этап полета. Регулярные встречи - раз в 1-2 недели

Есть коммюнити лидеров гильдий - для обмена оптом и помощи. Каждая гильдия берет практики, которые важны в моменте. Плюс общее позиционирование гильдий и встраивание в общие HR-процессы.

У гильдий - свои метрики. Есть общие - по долям участников. И Чувство сообщества - оценка, насколько участники оценивают соответствие идеальной картине.

Было три кейса, что может пойти не так.

• Быстро выполнили цель гильдии - что делать? Расширение спектра тем и увеличение числа участников
• Участников много, а активности мало. DevOps - почти все могут вступить. Но при этом оказалось, что devops-инженеры не чувствуют ценности. Ту гильдию оставили, но devops стали 2.0
• Новостная повестка может повлиять на развитие гильдии. Сотрудники могут оказаться слишком занятыми, либо смениться моральное состояние. И в эти моменты надо сделать паузу, а потом вернуться и продолжить идти. Остаются точки оперативной синхронизации статуса. Паузы были с конца феврале до начала июня, и замедление в октябре (слабее - только моральное состояние, а не занятость).

Что сделано? Описание методологии, на новый уровень вышел обмен знаниями и внутренние обучающие курсы - там прикладные конкретные вещи. Вместо бесконечных Excel создания компетенций появился свой инструмент. Есть общее информирование, задача Анны - сделать, чтобы лиды отпускали людей. Гильдии сами определяют правила вступления, и в некоторые, например, девопс - есть входной барьер по профессии или нужна рекомендация.

Евгения Хосейни. Продуктовая экосистема или как получилось строить самолет, летая на нём

Компания разрабатывает решения для видеонаблюдения. И на входе комплексные решения собирали партнеры, которые предлагали заказчикам комплексное решение. Они приходили с запросами на доработки - шло несколько тактов уточнений без прямого контакта с клиентом, в результате вместо 2 месяцев делали за 9 и даже если получалось нужное - это оказывалось специализированное решение под 1-2 клиентов, которое потом надо было сопровождать. Эту ситуацию принципиально изменили, создав отраслевые команды, ориентированные группы клиентов, которые напрямую взаимодействуют, собирают потребности клиентов, делают отраслевую экосистему и пилотируют на небольшой группе клиентов.

Если подробнее, что поменяли

• Сквозные процессы. Экосистема - она из нескольких продуктов, продуктовый хаб. Внутри делание по сегментам.
• Отраслевая команда: Менеджер сегмента + Продукт, который тащит сгенеренные продукты + Исследователь трендов.
• Выделение сегмента рынка - целевые клиенты, их потребности, что удовлетворяем, а что нет. Дальше продавцы по целевым клиентам.
• Отраслевой бизнес-аналитик - отдельная позиция, дало неожиданный результат. Интегрирован в отраслевую команду, и выясняет у целевых клиентов реальные потребности. И собирает задачку внутри команд разработки, она расползается по стримам.
• Целеполагание. Цели на год в деньгах по каналам. Идеи, гипотезы продуктовые, околопродуктовые, непродуктовые. И дальше на квартал получаются задачи по формированию гипотез под идеи, цели в продуктовых и непродуктовых метриках и так далее.

Ошибки

• Избыточная сложность и длительность согласования на этапе разработки, даже для небольших фич - сделали простой процесс
• У них была переоценка собственной продуктовой экспертизы, клиенты используют продукты для других целей и не так как задумывалось - и это надо исследовать
• 100% план на недоукомплектованную команду - не работает, его не выполняют, и надо учитывать реальную комплектацию при планировании
• Не провели аудит инструментов анализа данных - не видели как бежим сразу
• Не зафиксировали метрики рентабельности целевой системы
• Не зафиксировали метрики здоровья

Напутствие:

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

Дарья Ерещенко из ГНИВЦ. Культура съедает трансформацию на обед в Гос-ИТ

Компания делает nalog.ru и другой софт для ФНС. Agile-трансформация мыслится генеральным как способ двигаться быстро, и у команды трансформации - большие полномочия. Начинали летом 2021 с 3 человек в команде трансформации и 10 поддерживаемых команд, сейчас 13 человек в команде трансформации, у которых 77 поддерживаемых команд. При этом меняется не только организация, но и инженерные практики, год назад серьезно взялись за процессы тестирования, а сейчас ставят devops. Кроме того идет активная работа с изменением культуры компании, на это идет примерно треть усилий с отдельным бэклогом, в котором 40 фич, реализуемых итерационно по спринтам. Опыт показывает, что выделенная команда трансформации - нужна. И нужно привлечение внешних экспертов - взгляд со стороны помогает двигаться вперед.

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

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

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

Взаимодействие с заказчиком - ФНС. Быль опасения, что им трансформация не будет нужна. Но они не подтвердились. Всем хочется видеть прозрачную картину работ, прозрачный бэклог. Ценность, что сотрудничество в заказчиком важнее исполнения контракта - реализуемо. Любой госконтракт - структурирован, там эпики, которые можно идти фичами и историями, их можно приносить, и заказчик видит. Что интересно, демонстрация подходов вирусно распространяется по самой ФНС, в частности, правовое управление, которые не про ИТ, тоже захотело применять, пришли в Jira.

Кстати, я хочу подтвердить из своего опыта: госзаказчики приветствуют организацию работы по Agile, если ты учитываешь их особенности преокта. Прозрачность хода проекта и гикость - актуальны. Мы использовали Agile-методы еще с начала 2010-х, а в 2016 я рассказывал об этом опыте на AgileDays.

Светлана Овсянникова из Ингосстраха. Повышение эффективности работы команд как ответ на вызов времени

В рассказе, по сути, были собраны кейсы изменений, которые происходили последние два года. На входе - несколько связанных проблем: большая текучка сотрудников, низкая результативность и производительность, распил неповоротливого монолита, переход на современные технологии. Для начала устранили гигиеническую проблему - подняли зарплату до конкурентной по рынку. Для изменения монолита сделали ставку на тех.платформу, на которой будут делать все новое. Это помогло отчасти, тех.платформа - не серебряная пуля, но помогает, позволяет создавать LowCode решения - если снабдить примерами и понизить порог входа. Она позволила сделать шаблонизацию сервисов - упрощение процесса разработки, быстрый способ вывода сервиса, ускорение в 8 раз.

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

По результативности и производительности начали с измерения. Смотрели SonarQube, им понравилось. Только в феврале вендор ушел. Используют Decision Intelligence - оценка ценностного вклада разработчика и производительности. BlueOptima, в презентации был график в координатах производительность и качество, и размеры усилий в кружках. Через эту оценку смотрят выигрыша и потери - производительность стала измерима. И определяется ценность сотрудников и команд, эффекты изменения организации. Что важно - измерение производительности сотрудников и команд не привязано напрямую к заплатам и мотивации, это лишь индикация проблем и повод для разбора ситуации. Считают, что прямая привязка приведет к тому, что будут сильно стремиться подделать. И по содержанию за низкой эффективностью может стоять лень, а могут быть сложности в процессах, например, время ожидания пакетов или внешние согласования.

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

Еще интересно - в 2021 году они активно использовали консультантов, которые помогали делать трансформацию. В феврале их консультанты ушли. По мнению Светланы, пока хватает наработанных материалов, задела, но позднее уход консультантов может сказаться.

Иван Болотин из ВСК. Анархия или творчество? Насколько можно отклоняться от SAFe

Полтора года назад ВСК принял стратегию расширения на рынке с целевыми показателями по доле сбора страховой премии, доле в марже и другими бизнес-показателями. Помимо бизнес-направления было HR (кого ищем) и технологическое. А организационным инструментом реализации была выбрана трансформация на основе SAFe. Трансформация успешно удалась, сейчас 11 поездов на 500+ человек:

• Фронт - мобильное приложение, личные кабинеты, интернет-магазин
• Foundation - поставщики услуг, 16 приложений по разным видам страхования (из 60)
• А еще - учетные, аналитические и ИТ-сервисы.

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

По SAFe есть учебник, и он - сложный. Как обычно это бывает, велик соблазн сделать без учебника, в надежде, что получится лучше. Опыт говорит о том, что так не работает, читать учебник, разбираться и ему следовать - нужно. В докладе были конкретные кейсы с оценкой ущерба.

Пример-1, негатив 30 млн. Ошибка - опоздали с внедрением Large Solution SAFe и Portfolio SAFe - когда идет провязка стратегических целей до задач. Фронты запланировали работы на один период, они сделали с опережением, интеграции не произошло, оценка - по стоимости поддержания систем.

Способ устранения - изменение конфигурации. Epic Owner. Portfolio Backlog и Portfolio Kanban. Pre PI планинг для синхронизации и Solution demo сквозное, а не поездами. Совет: изучите конфигурации SAFe. Их много, есть схемы, тренеры тренеры рассказывают, для чего конкретная конфигурация нужна. Посмотрите и конфигурируйте сознательно.

Пример-2, 25 млн негатива. Ошибка - неравномерное развитие управленческих и инженерных практик. SAFe - не только PI, поезда и т.п., там инженерные практики - devops и т.п. Там есть Flow metrics, радары чтобы выявлять проблемные места. А они - не посмотрели. Проблемное место - тестирование. Но они его не увидели, потому что не сразу подняли метрики. Сейчас метрики есть, и проблема видна достоверно: задачи в статусе "Готово к тестированию" живут 16% времени, а это - простой, который и дал оценку негатива. Сейчас это устраняют через разные методы: автотесты, TDD и так далее.

Рекомендация - с самого начала измеряйте, это не стоит ничего, надо настроить Jira и все. И расшивайте те узкие горлышки, которые увидите.

Пример-3, негатив 40 млн. Недостаточное внимание соответствия кандидатов тому, как они соответствуют Team Fit; ценностям и принципам Agile. А еще они не требовали сдачи экзаменов по SAFe, поэтому люди формально проходили обучение. Это привело к 4 нежелательным увольнениям, а есть оценка, что стоимость одного увольнения это 2 годовых ФОТ.

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

И в заключении. Виктор Ченг: "Если что-то имеет здравый смысл, это не значит, что это - общепринятая практика". Он сказал тривиальное: читайте учебники, используйте метрики, беседуйте для проверки совместимости с командой. Это вроде все знают - но не используют.

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

Александр Володин, Газпромнефть. SAFe в нефтянке - легко! Или...

SAFe применяется для организации проектов изменений. В компании идут 65 программ с участием 6500 человек, 1200 ИТ-решений, 600 команд, 65 программ, 40 городов, 200 площадок. Их надо перевести на Agile-рельсы. 40 уже переведены.

Эксперимент начали 1.5 года назад, когда пришли пандемийные ограничения. Бизнес согласился попробовать, взяли 3 программы, обучали. Параллельно другие программы смотрели - и тоже пробовали. Потом случилось демо - и все встали в ряд на трансформацию.

Они вовлекают бизнес и получают вопрос: есть ли инструкция по самоорганизации команд? На таких масштабах вопрос актуальный, и они дают на него ответ. Сделали стандарты - процессный и технический, как раскатываем. Профили компетенций, ролевые модели проектов. Образовательные курсы PO и SM, недавно - для руководителей программ.

Есть базовая модель продуктовой зрелости. Бинарная: используют практику или нет. В следующем году будет 2.0 - поменяли компоновку и набор метрик. В модели компоновка между продуктовыми и командными метриками.

Топ-менеджеры начали задавать понятные и классные вопросы: вы классно работаете, а что меняется в полях. Изменения - отслеживают, у них 3-месячный цикл (со смещением к кварталам). Выросли метрики. Предсказуемость - 56 -> 77, зрелость 72 -> 91, частота релизов в 4 раза, ФОТ НЕ изменился.

Бизнес осознал, что для эффективного взаимодействия надо приходить очно, и со всех 200 площадок начали привозить людей.

Инструменты - Jira и Confluence, сделали надстройку, планирование online, доска как идет релиз, метрики предсказуемости и все прочее. 10к пользователей Jira, 7000 обучено. 600 обучено SAFe.

Про планирование. Раньше, когда защищались какие-то программы - было 8 тактов по 4 часа. Последний раз демо и решения по планам 1.5+2.5=4 часа. Но раньше расходы не считали, поэтому строго метрики посчитать нельзя. Через год посмотрим. И подготовка уменьшилась.

Что достигнуто по большому? Стратегически стали нефтяной продуктовой компанией.

Елена Седова из банка Открытие. Лидерство, как основа трансформации организации

Надо честно заметить, что про лидерство в докладе было мало. Но вот трансформация банка была описана достаточно подробно, и это - интересно. Дальше будет пунктирные заметки, которые полезно смотреть вместе с презентацией, как, впрочем, и для других докладов. В начале 2021 года были организационные изменения: выделены бизнес-линии и самостоятельные бизнес-юниты - трайбы, и центры компетенций в поддержку. ИТ не вошло в общую структуру трайбов. Синхронизация между трайбами - топы банков + лидеры трайбов. У команды три фокуса: бизнес, ИТ и клиенты, и есть структуры, которые обеспечивают балансировку.

Delivery и discovery. Была гипотеза, что главное - технологическая зрелость, а там 600 легаси-систем. Но в какой-то момент этого стало недостаточно, фокус на компетенциях и на людях. Центры компетенции по Agile, UI/UX, аналитические центры. И внешний консалтинг - как источник рыночного опыта, понимание чужих путей и ошибок.

Какие ожидания и результаты - динамика взаимодействия с топами.

• Q1 Первый вопрос "как работает" задали через 2 месяца. Топам интересно видеть.
• Q2 Следующий вопрос через 3 месяца - где деньги. И тут - прозрачность, приоритизация, скоринговая модель
• Q3 Дальше вопрос - а где доход? План эффекта по каждой цели и персональная ответственность.
• Q4 План-факт каждого эффекта по каждой цели.

В 2022 на входе был план. Но Открытие было в числе первых, кто попал под раздачу в марте. И оказалось, что процессы позволяют адаптироваться. Планирование - на квартал. Внутри квартала изменения не слишком большие. Поэтому шли квартальными шагами. При этом было решение топов - не пересматривать бизнес-план, потому что неопределенность слишком велика. И, что интересно - план в целом реализован.

Наблюдаемость. План - Процессы - Результаты и План-факт. И 24*7 есть прозрачное наблюдение всего этого, доступное для всех. D презентации - слайды с конкретными показателями.

Культура. Когда зашли в эту историю все говорили "вы должны стать agile". Тут интересный слайд. Есть элементы традиционной культуры - прибыль, иерархия, контроль, планирование, закрытость. Есть agile - противовесы: смысл и предназначение, горизонтальное взаимодействие, самостоятельность, эксперименты, прозрачность. Реально надо сделать симбиоз.

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

Сложные вопросы

• Кроме денег надо честно ответить - кому это надо и чью задачу решаем. Задачу бизнеса, а не про "модно" или "быть как все" - не пойдет
• Люди - сопротивляются. Это требует усилий не только команд, но и лидеров. На пилотах результата будет быстро, а серьезная - долго, и поддержка длинная. Люди выгорают
• Умение брать персональную ответственность взамен коллективной, которая присуща традиционной системе, когда каждый шаг надо согласовывать.

Панельная дискуссия: Agile в крупных организациях и госкомпаниях - как работать с сопротивлением

Дискуссию организовавал Павел Алферов, а участвовали Александр Ожаровский из РАНХиГС, Василий Слышкин из ГосТех, Михаил Трегубенко из СИБУР и Олег Богатырев из ГНИВЦ.

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

В начале была проблематизация. Коллеги из Scrum Trek проводят исследования, вроде все растет, но далеко не всегда успешно. По России исследований успеха нет, но есть зарубежные исследования (scruminc): 50% Agile-трансформаций провалились, из них 67% критично сказались для компании. Был вопрос: а как вы думаете? В России так же, лучше или хуже. Мнение зала, что в России такого количества провалов нет. И мнение одного из экспертов: это потому, что у нас хорошо строят потемкинские деревни и имитируют. На что была реплика из зала: так потемкинская деревня - это ж прототип, видите какие у нас правильные культурные традиции.

А еще по России есть исследования про цифровую трансформацию: 5% успешны, 20% провалились, а остальные 75% размылись, то есть достигли чего-то, но не того, что планировали. Кажется, с Agile - тоже самое.

Было голосование за причины провала:

1. несогласованные практики и процессы
2. орг.культура, противоречащая ценностям
3. общее организационное сопротивление изменениям
4. отсутствие навыков и опыта работы с методами agile
5. недостаточное участие руководства

Лидеры по голосованию - 2, 5, 3.

Пока оно шло, были комментарии экспертов и реплики с мест по поводу провалов.

• Если первое лицо говорит "штука нужна, но без него нормально живем" - то этой штуки не будет.
• Кейс в компании. Основной тормоз трансформации - успешная работа команды. Когда провал - там просто разбираться, а вот когда успешно, то есть желание оставить как есть. Правда, тут надо разбираться, ведь трансформация - не цель, а средство, может, успешные команды надо оставить? Но будет нарушаться взаимодействие, так как окружение меняется, а они будут говорить "это не мы виноваты". Тут неоднозначно.
• Реплика. Успех часто постфактум вовсе не такой, каким казался сразу после внедрения.
• Реплика. Не хватает причины "не ясна цель трансформации, или она неверная".
• Почему Agile плохо работает в Германии? Потому что ордунг и фюрер - в культуре.

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

• С культурой - сложнее всего. Она в опыте людей, его сложно менять.
• Была стена плача в Сбере. Только недолго продлилось.
• Ограничивающие убеждения - у топов, у команд. Где-то из советской школы, где-то из первого опыта низких позиций, где загоняли в рамки - эти рамки живут. С этим надо работать, надо осмысливать. Но системно делают маловато. Работа с онтологиями.
• Ценности.
  • Сплоченная команда, принцип одной лодки - команда и заказчик из бизнеса получают одинаковую оценку.
  • Можно достичь результата без проекта - и это хорошо, способ остановиться.
  • Уважение и партнерство, мы вместе
  • Каждый день становимся лучше, не надо делать большой взрыв.
• Есть проблема с топами - их учить или менять? Ответ - всех не поменяешь, так что надо работать по-разному.

По результатам, которые появились на экране, было интересное замечание: там очевидные вещи: начинать обучение топов, поставить цели, убрать агентов сопротивления. И возникает вопрос: если причины в этом, то почему так не делают, ведь вещи очевидные? Я тут замечу, что так пытаются делать, только не получается, то есть реальные причины в чем-то другом.

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

Фарит Хуснояров из VK. Когда все сроки вышли, а результат нужен завтра

Доклад посмотрел в записи, включил в отчет позднее

История про перестройку в этом году команды, которая делает vk messenger. Проблема в том, что он сильно отстал от других платформ. За прошлый год ни одна из фич не была доведена до релиза. При том, что команда из квалифицированных профи с хорошей мотивацией, люди любят vk и искренне хотят нанести пользу пользователям. Но не получается. И проблема - в организации работы. Кейс, на мой взгляд - характерный для многих инженерных команд, чем и интересен.

На входе команда 40 человек была организована по платформам: web, андроид, iOS, бэк - это часто бывает. Каждая - со своей организацией процесса внутри, ведь "профи лучше знают как организоваться". Коммуникации - слабые. А чтобы поставить фичу, надо чтобы она появилась на всех платформах. Так фичи и не доходили до пользователей.

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

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

Организационно это было сделано через процедуру квартального планирования, PI planing из SAFe. Фарит раньше работал в РТ Лабс, которая делает госуслуги, там это начали активно применять, чтобы разгрести завал работы, спровоцированный ковидом. Главное что дает процедура - прозрачность планирования, это важно и для руководства и для заказчика, она дает представление что будет сделано и в какие сроки. На конференции был доклад РТ Лабс, где это рассказывали, отзыв у меня в конспекте есть. В целом команда против планирования не возражала, вопросы были в технической осуществимости.

А дальше нужна фокусировка на том, чтобы фичи были сделаны целиком, на всех платформах. Решение тут известное - фичи-тимы или мультиплатформенные команды. Фарит эти две конструкции различает, хотя я не очень понял разницу. У них на первую итерацию было сделано две мультиплатформенных команды, в каждую взяли по 2 разработчика из каждой платформы. При этом платформенные команды - остались, они дорабатывают механизмы ядра, если это нужно для фич, через них проходят новые сотрудники при онбординге. Отмечу, что в целом конструкция сложная, но известная и понятная. О ней, например, рассказывал Евгений Россинский из ivi на Teamlead-2018.

В первую итерацию каждая команда взяла по 1 фиче. Эксперимент признан удачным, сейчас вторая итерация, команд уже 4, они взяли 9 фич. Естественно, был вопрос про организацию работы такой команды - потому что люди пришли из разных команд, в каждой из которой была своя организация. Решили иcпользовать Scrum. Основное возражение - что это долго и требует обучения, но тут подключился ScrumTrek, все сделали быстро.

Еще одна проблема - мощность команды разработки. Когда роадмап сделали, то стало понятно, что нынешней мощностью телеграм нагонят к 2030 году, не раньше. Значит надо что-то делать и быстро. Но культура требовала отбора настоящих профессионалов, были тяжелые собеседования, и больше одного сотрудника в месяц - не приходило. Но и изменить культуру быстро не получалось, люди не были готовы работать с теми, кого не считают "настоящим профи". И тут был workaround - через аутсорсинг. Компании-аутсорсеры предложили лидов, которые прошли собеседование. И те уже под себя набирали команды, а взаимодействие все шло через квалифицированных людей. Таким образом получилось в короткое время добавить 5 команд, 20 человек. Которым отдали все мелочи и исправление багов. Взаимодействие тоже возложено на команды платформ.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 18:33, 23 ноября 2022 • нет комментариев