Все статьи
Relentless Improvements или долгий путь стратегических и тактических изменений
Дата: 03.04.2021
История Технологического Центра Дойче Банка про 3 года трансформации в сторону выстраивания команд вокруг цепочек создания ценности.
Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.
Артемий Анцупов (модератор конференции): Всем привет, кто присоединился к нам после перерыва на треке №2. Следующий блок у нас начнет Александр Троицкий, человек, который своими руками участвует во внедрении SAFe-фреймворка в таком техническом гиганте, как Deutsche Bank. Александр поведает нам о том, как же реализуются процессы тактического, стратегического изменения в Deutsche Bank. Александр, тебе слово.
Александр Троицкий: Большое спасибо! Всем привет после перерыва. И сегодня давайте поговорим об интересной теме, которая является безжалостными непрерывными улучшениями. Как это происходит у нас, с какими сложностями мы сталкиваемся, к чему мы пришли на данный момент.
Пару слов обо мне. Я более 8 лет работаю в IT на разных ролях, на разных уровнях. Это дало мне довольно богатый опыт того, как это происходит, как люди в это вовлекаются, начиная непосредственно от инженеров, которые на местах уже сидят, реализуют какую-то потребность, ценность для конечного пользователя, заканчивая более высокими уровнями, связанных с тем, как это все организуется, как людьми управляется, какие процессы для этого нужны. Как уже было сказано, я работаю в технологическом центре Deutsche Bank. Мы трансформируемся по SAFe.
Для того чтобы немного погрузиться в тему, надо сначала понять, о какой части организации мы говорим, что это такое, что она из себя представляет. Давайте начнем эту картинку раскручивать. Начнем с того, что я работаю в большой команде, в команде рисков, которая занимается подсчетом рисков в банке. Мы начали процесс SAFe-трансформации довольно давно, в 2018 году. За это время мы обучили довольно много людей, мы синхронизовали огромное количество команд, организовали команды в поезда. На данный момент сейчас у нас в команде рисков порядка 20 поездов и примерно 150 команд, которые в эти поезда входят.
Я не буду детально останавливаться на всем нашем домене рисков. Я поговорю о той части команды, в которой работаю непосредственно я, которая называется Market Risk Technology Team, которая занимается подсчетом именно рыночных рисков. Эта часть организации чуть-чуть поменьше. Давайте обозначим ее scope (прим. ред. — границы ответственности) и поговорим про некоторые особенности, которые дальше нам будут важны. Здесь речь уже пойдет порядка о 30 командах. То есть наш контур где-то 500 человек. Важный момент. Мы распределены между 4 локациями, начиная от США, заканчивая Индией. Это довольно большой временной диапазон. Представлены тремя основными системами или платформами.
Когда мы стартуем любую SAFe-трансформацию, то на состоит из нескольких этапов. Понятно, что для навала надо определиться, где располагается потребность клиента, как мы ее создаем. Для этого в SAFe-подходе существует такое понятие как Value Stream (прим. ред. — цепочка создания ценности). Value Stream включает в себя некоторую последовательность шагов, начиная от концептуального, заканчивая непосредственной доставкой ценности до клиента, которая нам нужна, которая существует в организации для того, чтобы эту ценность создать и донести. Она включает в себя не только сами шаги. Она включает в себя также людей, которые работают в рамках этих шагов. А также системы, которые реализуют доставку информации.
В SAFe-подходе существует последовательность, состоящая из четырех шагов, как нам организовать людей в некоторые команды, которые в эти Value Stream, так или иначе входят. С первыми тремя шагами, я не буду на них очень подробно останавливаться, все достаточно просто. Там речь идет о том, что надо определить саму цепочку поставки, определить системы, которые включают в эту цепочку, и определить людей, которые эти системы поддерживают и развивают.
Дальше наступает интересный шаг. Надо организовать людей уже непосредственно в некоторые структуры, которые в SAFe называются поездами (прим. ред. — Agile Release Train, ART). Даже в SAFe довольно четко сказано, что этот вопрос, скорее, больше про искусство, нежели про какой-то алгоритм. Давайте остановимся на нем подробнее. Когда мы начнем организовывать людей в команды, нам на самом деле нужно сперва определиться с довольно важной историей.
Что для нас будет самым ценным. Мы можем стараться организовывать людей так, чтобы они у нас были выровнены по цепочке поставки ценности, добиваясь таким образом быстрого протекания наших задач, в конечном счете ценности для клиента через систему. Мы можем выстраивать ее вокруг существующих приложений, платформ, систем. Таким образом, может быть, скорость протекания у нас будет медленнее, потому что будут некоторые сложности на этапе их взаимодействия между собой. Но зато мы будем гораздо лучше сохранять качество в нашей системе, потому что команды, работающие в одной платформе, работают сообща, а не разбросаны между разными поездами, возможно, решающие разные бизнесовые задачи.
Существуют и другие точки оптимизации. Но на них более подробно я останавливаться не буду. Тут важный момент. Когда мы столкнулись с решением этой задачи, именно распределения людей в поезда, мы оценили, что у нас есть еще несколько проблем помимо того, что надо просто определиться с точкой оптимизации на начальном этапе. Нужно еще обратить внимание на то, что в нашем случае, как я говорил, у нас несколько платформ. У нас есть некоторое взаимодействие между ними. На этапах между этим взаимодействием происходит довольно много интересных сложностей, как это часто бывает, именно интеграция – ключевая проблема в взаимодействии систем.
Сами платформы довольно разные технически. То есть люди, которые работают в одной платформе, могут уже не иметь такого skill set (прим. ред. — набора навыков), чтобы работать с другими платформами. У них разные инженерные процессы. Да и просто количество людей – я напоминаю, это 500 человек непосредственно в нашем контуре – уже не помещается в один поезд по рекомендациям SAFe. Там рекомендация порядка 125 человек.
Тем не менее, проанализировали все, что у нас было на этапе старта. Дальше надо понять, чего же мы хотим достигнуть, какая у нас ключевая цель, зачем мы вообще начинаем процесс трансформации, перекройки команд, перераспределения их из тех структур, где они изначально когда-то находились. Мы определили свою цель следующим образом. Мы изначально хотели стремиться к тому, чтобы выстроить поезда, выровненные вокруг цепочки поставки ценностей, и тут некоторое дополнение, которое непосредственно про наш кейс более интересно. Нам хотелось этого добиться в каждой локации. Поскольку у нас их 4, коммуникация между локациями даже просто по времени того как солнце встает и заходит, само по себе проблема. Если мы можем сделать это в каждой из имеющихся локаций, мы добьемся существенно больших результатов.
Что же нам это даст? Глобальная гипотеза, что это позволит нам уменьшить Time To Market, то есть уменьшить время доставки ценности и уменьшить затраты на коммуникацию, которая сейчас существует между разными командами. Понимая такую глобальную цель, анализируя те сложности, которые у нас есть, мы решили, что начинать мы все-таки будем с платформенных команд. Именно так мы и делали когда-то давно.
Почему мы делали именно так? Потому что экспертиза у нас разная, то есть не везде у нас есть возможности в каждой локации иметь экспертизу, на тот момент ее не было, получить быструю экспертизу по смежным платформам. Нет выровненных инженерных практик, общего на тот момент стека CI/CD (прим. ред. — Continuous Integration/Contimuous Deployment, Непрерывная Интеграция/Непрерывное Развертывание) и общего стека тестирования. При этом всем никто не отменял каждодневные бизнес-задачи, которые надо было решать. Поэтому трансформацией трансформацией, а бизнес делать надо. Поэтому мы выбрали платформы для начала. Я уже начал говорить о тех моментах, которые остановили наш выбор на платформенных командах изначально, но давайте я еще остановлюсь на некоторых важных моментах. Отличия методологии. То есть разные инженерные практики. Это первая проблема. У нас не было единого инструмента сквозного тестирования всех систем. Какие-то практики существовали, но единого быстрого удобного инструмента тестирования нет. Экспертиза распределена между локациями. В каждой локации экспертизы по всем трем платформам у нас не было. Понимая, что в эту историю мы входим с той глобальной целью, а именно выровняться полностью по цепочке поставки ценности в каждой локации, это займет время. Мы сразу это понимали. Нам нужно сохранять тренд на протяжении длительного периода нашего трансформационного процесса.
Что же мы начали делать для того, чтобы перестроиться. Первая и относительно простая история связана с архитектурой. Почему она относительно простая? Потому что когда у вас речь идет о технологиях, есть какие-то базовые, удобные, известные подходы, которые гарантируют качество результата внутри.
Мы начали выстраивать единый поток. Я остановлюсь на нескольких важных вещах. Это единый CI/СD с использованием одних и тех же технологий и через все платформы использование единого стека, потому что он по историческим причинам был довольно разный. И использование такого подхода как определение жестких контрактов взаимодействия между системами, потому что как мы говорили ранее, именно на интеграции много проблем и существует. Естественно, мы стали выделять довольно внушительное время в наших каденциях для того, чтобы заниматься архитектурными изменениями, этим архитектурным выравниванием, потому что это не происходит за день, и даже не за два.
Когда мы начали анализировать, что нам надо сделать в тестировании, как нам надо изменить наш подход, то опять же остановлюсь на нескольких ключевых моментах. Первое, что мы начали разрабатывать, это единый инструмент тестирования, интегрированный со всеми платформами, который позволяет быстро валидировать, что ценность действительно создается от начала и до конца. Мы можем это валидировать и проверять разные этапы.
Вторым важным изменением стало создание единой системной команды, потому что до этого системные команды для каждой из платформ были отдельные. Соответственно, создание единой системной команды позволило сделать нам некоторый общий релизный цикл, и вообще, подойти к релизу нашего продукта как к некоторой концептуально единой точке.
Мы немного поговорили о технических изменениях, которые мы делали. Теперь остановимся на том, как мы боролись с проблемой экспертизы. Сначала обозначу три основных направления, в рамках которых мы работали. Мы делали следующее. Первое, что можно делать, если у вас нет какой-то экспертизы, вы можете перебрасывать команды из одного поезда в другой. Можно создавать новые команды для того, чтобы наращивать экспертизу, а также можно обучать уже имеющиеся.
Давайте остановимся на каждом из этих пунктов подробнее. Плюсы и минусы. Историческим самым первым подходом, который мы начали пробовать, было перераспределение команд между поездами. Он достаточно простой тем, что вы получаете быстрый результат. Ваши поезда умеют работать со всеми имеющимися платформами. Но есть и минусы. Команды остаются запертыми в рамках своих экспертиз. Несмотря на то, что это дает определенную гибкость в плане формирования бизнесового бэклога для поездов на следующую каденцию, тем не менее на самом деле выстраивание такой полной экспертизы в рамках локации не очень решает. Поэтому достаточно быстро мы начали применять другой подход в совокупности с первым, а именно создание новых команд. Тут этот подход как раз очень хорошо позволяет решить проблему экспертизы внутри локации. И это здорово.
И также на самом деле есть и второй большой плюс. Если вы создаете новую команду, призванную пройти обучение, научиться чему-то в конкретной платформе, в некоторой конкретной области, то эта команда становится сфокусированной на решении проблем именно в этой конкретной области. И это хорошо, потому что ее не отвлекают на какие-то другие задачи, нет тенденции присваивать ей или стремиться к тому, чтобы эта команда скорее взяла задачи из той области, где они исторически были экспертами, так как команда новая.
Но минус опять же вытекает из плюсов. Раз в данной локации экспертов нет, значит, они находятся где-то далеко. Их нужно как-то вытаскивать, с ними нужно работать. При отсутствии должного вклада к этому подходу, который выравнивается через цели на каденции и так далее, с этим становится сложно. На самом деле, когда мы такие команды изначально стартовали, они довольно долго буксовали, поэтому этот подход не такой простой, он требует действительно серьезного вовлечения и внимания всего поезда и всех людей, которые в него входят.
И кто сказал, что старого пса нельзя обучить новым трюкам. Через какое-то время, когда у нас уже появилась экспертиза в локациях, в новых командах или путем переброски, мы начали делать иначе. Мы начали брать уже имеющиеся команды, которые являются признанными экспертами в определенной платформе и давать им задачи, которые связаны больше или требуют взаимодействия с другой платформой. Даже не взаимодействия, а именно реализации функционала в них. Это начало давать хорошие плоды.
Плюс заключается в том, что такая команда действительно становится кросс-функциональной не только с точки зрения того, что она может создавать, тестировать и так далее. Она может еще действительно работать в рамках разных систем, из которых состоит наш продукт. Данный подход невозможен, на мой взгляд, и не будет достаточно эффективен без наличия доступных экспертов. И в принципе, надо понимать, что он требует больше времени. Поэтому в целом все эти подходы имеют свои плюсы и минусы. Поэтому мы их, как я уже заметил, комбинируем. Мы говорим, что это здорово, у нас есть разные подходы. Мы ими занимаемся. Но все это занимает время. Время становится для нас довольно ключевым фактором. Так у нас и было. Поэтому на протяжении этого времени происходит много изменений. Все эти изменения влияют на конечный результат. Поэтому нам нужно сохранять направление движения.
Я поговорю о двух основных проблемах, с которыми мы столкнулись, с которыми можете столкнуться вы или, возможно, тоже с ними сталкиваетесь. От момента формирования команды до ее активной работы, команда проходит через многие стадии. С этим связано много интересных аспектов, о которых я скажу далее. И второй момент. Иногда людей между командами приходится перераспределять по тем или иным причинам. Об этом тоже поговорим.
Давайте начнем с того, что команды проходят разные стадии. Когда мы формировали первые поезда, мы создали команды немного иначе, чем они существовали до того, как у нас SAFe-трансформация началась.
Некоторые гипотезы относительно того как люди хорошо сработаются, кому с кем удобно работать, и где какая будет эффективная команда, не все из этих гипотез хорошо сработали. Это приводит к тому, и в нашем случае так и получилось, что некоторые команды стадию шторминга не пережили, и людей пришлось перераспределять, перекидывать между имеющимися командами или формировать новые, уже полностью перебалансируя какую-то часто поезда, например, что требует вовлечения гораздо большего количества людей.
Вторая проблема связана с тем, что на самом деле люди имеют свойство приходить и уходить, то есть по решение задач выделяются, появляются новые кадры, новые люди. Их нужно включать в команды. Но кадры также и теряются. В нашем случае мы в какой-то момент одновременно, так получилось, потеряли сразу нескольких PO (прим. ред. — Product Owner, Владелец Продукта). Запасного фонда для того чтобы быстро пополнить запас имеющихся PO, у нас просто не было. Решить этот вопрос наймом невозможно за один-два дня. Это тоже привело к некоторому перераспределению команд. И тут я хочу остановиться на некотором контринтуитивном выводе, который на мой взгляд, работает в Enterprise-среде.
Когда мы говорим про маленькие команды, то они у нас более гибкие. Если у нас работает всего около пяти человек или даже меньше, они эффективно строят взаимодействие между собой, и с точки зрения конечного результата мы имеем много плюсов. Так делали и мы вначале. Но столкнувшись с ситуацией потери некоторых кадров, мы поняли, что на самом деле большой зверь гораздо более надежен, с точки зрения долгосрочной перспективы. Если вы по какой-то причине теряете несколько кадров, по разным причинам, даже просто банальные отпуска никто не отменял. Или болезни. К сожалению, сейчас это довольно актуальная тема. Так вот, если в команде чуть больше людей, то на самом деле гораздо проще пережить такую ситуацию. Поэтому мы сейчас создаем команды немного крупнее, чем создавали вначале.
Наверное, было бы не совсем здорово, если бы я, рассказывая обо всем том, что мы делаем, не подтвердил это хоть какими-либо цифрами, которые показывают, что мы действительно движемся в правильном направлении. На слайде представлен график нашего PI Predictability Measure (прим. ред. — метрика предсказуемости программы) за примерно последний год. Тут не уточнены точно кварталы, за которые он представлен, но это на самом деле не так важно. Здесь можно видеть, что предсказуемость результата довольно хорошо сохраняется. Она находится в правильном, с точки зрения SAFe подхода, диапазоне, от 80 до 100%. При этом за это время у нас, 2020 год по сравнению с 2019, вдвое увеличилось количество релизов. Они стали у нас синхронными. Количество фич, которые мы выпускаем в каждом из релизов, утроилось при этом, что говорит о том, что мы создаем ценность с некоторым хорошим постоянством. А если еще вспомнить, что наши команды стали более выровненными и те фичи, которые команды выпускают, имеют больший бизнес-смысл, и еще синхронизированное, то ситуация еще становится еще лучше.
Чем хочется закончить? Мы с вами поговорили о том, с чего мы начинали, куда мы движемся, какими подходами мы двигались, как мы меняли нашу структуру, как перестраивались на протяжении всего этого времени. Напоминаю, что на одном из самых первых слайдов была цифра, что мы стартовали в 2018 году. Сейчас идет уже 2020, то есть время идет.
Что хочется сказать? На самом деле смотря на текущую ситуацию, я могу сказать, что глобальные цели мы еще не достигли. Хоть мы и максимально к ней приблизились. Кажется, что осталось не так много. Но тем не менее, важная история заключается в том, что трансформация – это не какая-то финальная точка, к которой вы двигаетесь и потом достигаете, потом ходите на конференции и рассказываете, что мы трансформировались, теперь у нас все замечательно, классно. И больше ничего делать не надо. Это все-таки путь и путь этот довольно длинный.
Важно, что на этом пути нас ждет очень много препятствий. Нам нужно научиться их преодолевать и сохранять вектор развития. Это самое главное, о чем я хотел сказать. Не нужно бояться трансформационных изменений, даже в крупных Enterprise они возможны. Но надо понимать, что они будут происходить достаточно медленно. Нам нужно сохранять направление движения во время всего этого процесса. На этом у меня все.
Вопрос-ответ
Артемий Анцупов: Спасибо тебе большое за выступление. Это действительно был очень большой, объемный, классный доклад.
Касательно вопросов. Мне интересно. Скажи, пожалуйста, когда вы начинали работу, в чем был первый толчок к тому, чтобы начать такую проработку с экспертизой команд. Вы же с чего-то, наверное, начали, или возникла серьезная проблема, или это было чисто на лидерстве сделано? С чего именно вы стартовали. Такой замечательный длинный объемный timeline. В чем был основной мотиватор таких изменений?
Александр Троицкий: Если мы говорим про основную историю, зачем мы все это делали, то перед нами на достаточно высоком уровне была поставлена глобальная цель. Давайте к ней вернемся. А именно выровняться вокруг цепочки поставки ценностей. Наш достаточно высокий менеджмент понимал, что это то, чего мы хотим добиться. И только так мы сможем действительно проработать и улучшить Time To Market внутри нашей организации. Именно это глобальная цель, которая декларировалась нашим руководством на каждый из наших каденций, приводила к тому, что мы делали какие-то изменения, которые были призваны эту глобальную задачу решить.
Артемий Анцупов: Вы сейчас продолжаете это движение в сторону этой огромной цели. Какой у вас ближайший challenge? Над чем вы работаете прямо сейчас. Какой у вас ближайший shift?
Александр Троицкий: Хороший вопрос. На самом деле мы довольно долго и сложно работали с этим самым наращиванием экспертизы в локациях. Это довольно сложная история. Я ее достаточно аккуратно коснулся в своем докладе. Можно посвятить ей гораздо больше времени. Наверное, такая сильная тенденция последнего времени, что мы смогли наконец-то добиться хороших результатов. У нас в локациях появились эксперты хорошего уровня, которые умеют работать с новыми платформами. Сейчас наш ближайший challenge – это чтобы те эксперты, которые у нас появились, смогли поделиться своими знаниями с большим количеством. Именно обучать команды, которые уже умеют с чем-то работать, чему-то новому.
Артемий Анцупов: Как вы планируете это делать? В SAFe есть замечательные инструменты, всякие Community of Practices, Spotify, гильдии, еще что-то. Может быть, поделишься практиками, которые только собираетесь применять?
Александр Троицкий: Да, на самом деле все это мы, конечно, применяем. Community of Practices у нас довольно много. Они активно стартуют. Некоторые из них заканчиваются, как это часто бывает с Community of Practices. Но я бы выделил очень важный этап, без которого, как мне кажется, добиться серьезных результатов не получится. Мы это в какой-то момент поняли, стали на этом делать акцент. Командам, которые должны обучиться чему-то новому, нужно обязательно иметь в своих следующих целях на следующую итерацию задачи, которые связаны с обучением, технологическим стеком, конкретными бизнес-ценностями в рамках новых для них платформ и систем.
Без такого прикладного инструментария, когда тебе действительно нужно что-то сделать, добиться результатов только на каких-то гильдиях, обучающих историях, к сожалению, не получается. Человек что-то слушает, но…
Артемий Анцупов: Зачем мне это? Это понадобится потом. Это действительно не работает. Спасибо тебе огромное за мудрость, за информацию. Это действительно очень классно, такой уровень задач вы себе ставите, что я думаю, для многих это то, что только придется пройти. Очень классно, что уже есть такой ваш опыт. Спасибо тебе огромное.
Видео и слайды
