6874
правки
Изменения
Новая страница: «{{Conf-Ref}} right В понедельник 21.11 прошла очередная конференция [https://2…»
{{Conf-Ref}}
[[Файл:AgileEnterprise2022-ph.jpg|300px|right]]
В понедельник 21.11 прошла очередная конференция [https://2022.agileconf.ru/ '''Enterprise Agile Russia''']. Конференция была супердинамичная, '''на доклад с вопросами и перерывом отводилось 30 минут''': 20 на доклад, еще 5 на вопросы и 5 на перерыв. Так жестко спикеры не укладывались, но поскольку потом начинался следующий доклад, то в целом получасовые слоты соблюдались. Понятно, что за такое время сложный проект можно изложить только пунктиром, так что спикеры со слушателями уходили в зону обсуждения, с юмором названную организаторами пыточной, где отвечали на вопросы с пристрастием. На конференции было два трека докладов, трек мастер-классов и трек просветительских лекций. Я, как обычно, публиковал заметки в телеграм, но успел только по части докладов. А теперь публикую отчет по горячим следам.
Конференция была посвящена изменениям крупных компаний за счет применения Agile-методов, прежде всего SAFe и OKR. Я хочу заметить, что у меня лично - скептическое отношение к SAFe ввиду его большой сложности, так же как и к более традиционному проектному управлению по PMBOK. Но это скепсис в том смысле, что нет гарантий результата, и есть большие сложности в применении. С другой стороны, опираясь на услышанное, я признаю, что в SAFe видно много полезных практик, решающих задачи управления на большом масштабе. Кроме того, его применение принципиально меняет управленческое мышление в нескольких аспектах. Во-первых, в части признания ценностей Agile, на которые он опирается в части культуры, в том числе потому, что внутри на уровне команд лежит Scrum. А во-вторых - в части перехода от работы с потоком задач которые надо сделать к мышлению потоком ценности, которую надо создать, и этим он позитивно отличается от проектного управления. И, в третьих, он безусловно ломает и размораживает застывшие бюрократизированные структуры.
Что касается инсайтов конференции, то я хочу отметить рассказ РТ Лабс, которая разрабатывает софт электронного правительства, вершиной которого является портал госуслуг, о том, как устроено квартальное планирование. Процедура интересная, но инсайт в другом. По сути заказчики в лице министра и его замов признали, что скорость разработки софта, которая определяет темп изменений государственного управления, определяется разработчиками. Перед ними можно ставить любые задачи и приоритеты, но решение о том, что из этого они успеют за квартал, должны принимать они сами, а заказчику остается лишь с этим смириться. Потому что если не смиряться, то, во-первых, пообещают, но все равно не сделают, а, во-вторых, из-за работы в режиме подвига и стресса будут массово увольняться, и негатив этого вдолгую будет превосходить локальный выигрыш, достигаемый за счет давления на разработчиков. И это - принципиальное изменение в понимании ИТ-разработки заказчиками такого высокого уровня. Оно есть не только там, просто в этом докладе проявилось отчетливо. Хотя в самом докладе этого тезиса не было, это - мое осмысление.
Еще надо отметить, что этом в большинстве докладов речь шла не про ИТ-разработку, а про деятельность корпорации в целом. Конечно, часть компаний, таких как банки или стразовые, в значительной мере продают цифровые продукты, однако деятельность по-прежнему включает в себя работу офисов и взаимодействие с клиентами. И Agile-методы позволяют координировать, организовать и развивать сложную производственную деятельность, а также программы и проекты ее изменения, им отдают предпочтение перед другими.
А теперь - краткие резюме той части докладов, на которой я был. И я рекомендую '''смотреть презентации''', они уже [https://2022.agileconf.ru/program/ опубликованы]. Спикеры не следовали принципу, что на презентации должна быть картинка для привлечения внимания и короткие тезисы, и это - хорошо. В презентациях много схем и содержательных тезисов, и они дают хороший скелет доклада, который имеет смысл посмотреть даже без записи.
{{red|Disclaimer: Заметки - с голоса, могут быть неточности и неверные интерпретации}}
=Евгения Меньшикова из ВТБ. Журавль в руке: опыт трансформации процессов производства ПО=
Вид сверху на трансформацию ВТБ за последние три года с 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 я [[Agile - то что на самом деле нужно госзаказчикам (Максим Цепков на AgileDays-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 - тоже самое.
Было голосование за причины провала:
# несогласованные практики и процессы
# орг.культура, противоречащая ценностям
# общее организационное сопротивление изменениям
# отсутствие навыков и опыта работы с методами agile
# недостаточное участие руководства
Лидеры по голосованию - 2, 5, 3.
Пока оно шло, были комментарии экспертов и реплики с мест по поводу провалов.
* Если первое лицо говорит "штука нужна, но без него нормально живем" - то этой штуки не будет.
* Кейс в компании. Основной тормоз трансформации - успешная работа команды. Когда провал - там просто разбираться, а вот когда успешно, то есть желание оставить как есть. Правда, тут надо разбираться, ведь трансформация - не цель, а средство, может, успешные команды надо оставить? Но будет нарушаться взаимодействие, так как окружение меняется, а они будут говорить "это не мы виноваты". Тут неоднозначно.
* Реплика. Успех часто постфактум вовсе не такой, каким казался сразу после внедрения.
* Реплика. Не хватает причины "не ясна цель трансформации, или она неверная".
* Почему Agile плохо работает в Германии? Потому что ордунг и фюрер - в культуре.
А дальше по каждой из проблем участники писали лайфхаки, как справится и голосовали за других, а эксперты - комментировали.
* С культурой - сложнее всего. Она в опыте людей, его сложно менять.
* Была стена плача в Сбере. Только недолго продлилось.
* Ограничивающие убеждения - у топов, у команд. Где-то из советской школы, где-то из первого опыта низких позиций, где загоняли в рамки - эти рамки живут. С этим надо работать, надо осмысливать. Но системно делают маловато. Работа с онтологиями.
* Ценности.
** Сплоченная команда, принцип одной лодки - команда и заказчик из бизнеса получают одинаковую оценку.
** Можно достичь результата без проекта - и это хорошо, способ остановиться.
** Уважение и партнерство, мы вместе
** Каждый день становимся лучше, не надо делать большой взрыв.
* Есть проблема с топами - их учить или менять? Ответ - всех не поменяешь, так что надо работать по-разному.
По результатам, которые появились на экране, было интересное замечание: там очевидные вещи: начинать обучение топов, поставить цели, убрать агентов сопротивления. И возникает вопрос: если причины в этом, то почему так не делают, ведь вещи очевидные? Я тут замечу, что так пытаются делать, только не получается, то есть реальные причины в чем-то другом.
Я тут замечу, что поверхностное рассмотрение - проблема самого формата дискуссии: он вскрывает то, что достаточно очевидно, а не в глубине. Но, с другой стороны, это для экспертов очевидные вещи, для участников может быть интересно. А еще этот формат показывает экспертам, что происходит в общественном сознании, а не на уровне глубокого погружения и это полезно.
{{wl-publish: 2022-11-23 18:33:33 +0300 | MaksTsepkov }}
[[Файл:AgileEnterprise2022-ph.jpg|300px|right]]
В понедельник 21.11 прошла очередная конференция [https://2022.agileconf.ru/ '''Enterprise Agile Russia''']. Конференция была супердинамичная, '''на доклад с вопросами и перерывом отводилось 30 минут''': 20 на доклад, еще 5 на вопросы и 5 на перерыв. Так жестко спикеры не укладывались, но поскольку потом начинался следующий доклад, то в целом получасовые слоты соблюдались. Понятно, что за такое время сложный проект можно изложить только пунктиром, так что спикеры со слушателями уходили в зону обсуждения, с юмором названную организаторами пыточной, где отвечали на вопросы с пристрастием. На конференции было два трека докладов, трек мастер-классов и трек просветительских лекций. Я, как обычно, публиковал заметки в телеграм, но успел только по части докладов. А теперь публикую отчет по горячим следам.
Конференция была посвящена изменениям крупных компаний за счет применения Agile-методов, прежде всего SAFe и OKR. Я хочу заметить, что у меня лично - скептическое отношение к SAFe ввиду его большой сложности, так же как и к более традиционному проектному управлению по PMBOK. Но это скепсис в том смысле, что нет гарантий результата, и есть большие сложности в применении. С другой стороны, опираясь на услышанное, я признаю, что в SAFe видно много полезных практик, решающих задачи управления на большом масштабе. Кроме того, его применение принципиально меняет управленческое мышление в нескольких аспектах. Во-первых, в части признания ценностей Agile, на которые он опирается в части культуры, в том числе потому, что внутри на уровне команд лежит Scrum. А во-вторых - в части перехода от работы с потоком задач которые надо сделать к мышлению потоком ценности, которую надо создать, и этим он позитивно отличается от проектного управления. И, в третьих, он безусловно ломает и размораживает застывшие бюрократизированные структуры.
Что касается инсайтов конференции, то я хочу отметить рассказ РТ Лабс, которая разрабатывает софт электронного правительства, вершиной которого является портал госуслуг, о том, как устроено квартальное планирование. Процедура интересная, но инсайт в другом. По сути заказчики в лице министра и его замов признали, что скорость разработки софта, которая определяет темп изменений государственного управления, определяется разработчиками. Перед ними можно ставить любые задачи и приоритеты, но решение о том, что из этого они успеют за квартал, должны принимать они сами, а заказчику остается лишь с этим смириться. Потому что если не смиряться, то, во-первых, пообещают, но все равно не сделают, а, во-вторых, из-за работы в режиме подвига и стресса будут массово увольняться, и негатив этого вдолгую будет превосходить локальный выигрыш, достигаемый за счет давления на разработчиков. И это - принципиальное изменение в понимании ИТ-разработки заказчиками такого высокого уровня. Оно есть не только там, просто в этом докладе проявилось отчетливо. Хотя в самом докладе этого тезиса не было, это - мое осмысление.
Еще надо отметить, что этом в большинстве докладов речь шла не про ИТ-разработку, а про деятельность корпорации в целом. Конечно, часть компаний, таких как банки или стразовые, в значительной мере продают цифровые продукты, однако деятельность по-прежнему включает в себя работу офисов и взаимодействие с клиентами. И Agile-методы позволяют координировать, организовать и развивать сложную производственную деятельность, а также программы и проекты ее изменения, им отдают предпочтение перед другими.
А теперь - краткие резюме той части докладов, на которой я был. И я рекомендую '''смотреть презентации''', они уже [https://2022.agileconf.ru/program/ опубликованы]. Спикеры не следовали принципу, что на презентации должна быть картинка для привлечения внимания и короткие тезисы, и это - хорошо. В презентациях много схем и содержательных тезисов, и они дают хороший скелет доклада, который имеет смысл посмотреть даже без записи.
{{red|Disclaimer: Заметки - с голоса, могут быть неточности и неверные интерпретации}}
=Евгения Меньшикова из ВТБ. Журавль в руке: опыт трансформации процессов производства ПО=
Вид сверху на трансформацию ВТБ за последние три года с 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 я [[Agile - то что на самом деле нужно госзаказчикам (Максим Цепков на AgileDays-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 - тоже самое.
Было голосование за причины провала:
# несогласованные практики и процессы
# орг.культура, противоречащая ценностям
# общее организационное сопротивление изменениям
# отсутствие навыков и опыта работы с методами agile
# недостаточное участие руководства
Лидеры по голосованию - 2, 5, 3.
Пока оно шло, были комментарии экспертов и реплики с мест по поводу провалов.
* Если первое лицо говорит "штука нужна, но без него нормально живем" - то этой штуки не будет.
* Кейс в компании. Основной тормоз трансформации - успешная работа команды. Когда провал - там просто разбираться, а вот когда успешно, то есть желание оставить как есть. Правда, тут надо разбираться, ведь трансформация - не цель, а средство, может, успешные команды надо оставить? Но будет нарушаться взаимодействие, так как окружение меняется, а они будут говорить "это не мы виноваты". Тут неоднозначно.
* Реплика. Успех часто постфактум вовсе не такой, каким казался сразу после внедрения.
* Реплика. Не хватает причины "не ясна цель трансформации, или она неверная".
* Почему Agile плохо работает в Германии? Потому что ордунг и фюрер - в культуре.
А дальше по каждой из проблем участники писали лайфхаки, как справится и голосовали за других, а эксперты - комментировали.
* С культурой - сложнее всего. Она в опыте людей, его сложно менять.
* Была стена плача в Сбере. Только недолго продлилось.
* Ограничивающие убеждения - у топов, у команд. Где-то из советской школы, где-то из первого опыта низких позиций, где загоняли в рамки - эти рамки живут. С этим надо работать, надо осмысливать. Но системно делают маловато. Работа с онтологиями.
* Ценности.
** Сплоченная команда, принцип одной лодки - команда и заказчик из бизнеса получают одинаковую оценку.
** Можно достичь результата без проекта - и это хорошо, способ остановиться.
** Уважение и партнерство, мы вместе
** Каждый день становимся лучше, не надо делать большой взрыв.
* Есть проблема с топами - их учить или менять? Ответ - всех не поменяешь, так что надо работать по-разному.
По результатам, которые появились на экране, было интересное замечание: там очевидные вещи: начинать обучение топов, поставить цели, убрать агентов сопротивления. И возникает вопрос: если причины в этом, то почему так не делают, ведь вещи очевидные? Я тут замечу, что так пытаются делать, только не получается, то есть реальные причины в чем-то другом.
Я тут замечу, что поверхностное рассмотрение - проблема самого формата дискуссии: он вскрывает то, что достаточно очевидно, а не в глубине. Но, с другой стороны, это для экспертов очевидные вещи, для участников может быть интересно. А еще этот формат показывает экспертам, что происходит в общественном сознании, а не на уровне глубокого погружения и это полезно.
{{wl-publish: 2022-11-23 18:33:33 +0300 | MaksTsepkov }}
