Большой Голландский Банк | Наш путь к масштабируемой гибкости

Авторы:

Cезарио Рамос, г-н А, г-жа Б и г-н В

В этой статье мы расскажем о том, как мы улучшили модель на базе Spotify в трайбе Голландского Банка.

Над нашим продуктом кредитования бизнеса работают более 20 команд.

Мы разрабатываем наш продукт в трех локациях со смешанными командами. Участники каждой из команд владеют навыками бизнеса, ИТ и операционными навыками. При такой схеме работы мы поставляем нашим клиентам ценный продукт каждые две недели. Мы достигли этого, помимо прочего, благодаря внедрению принципов LeSS для оптимизации нашего способа работы в стиле Spotify.

Итак, что мы изменили?

В этой статье мы расскажем нашу историю с четырех различных точек зрения.

С точки зрения:

Около полутора лет назад я (рассказывает руководитель) начал руководить трайбом ― группой из 500 человек, в которой представители бизнеса и ИТ работали совместно в скводах, создавая продукт кредитования бизнеса и взаимодействуя с командами, отвечающими за лояльность клиентов. До этого я занимался созданием розничного банка с нуля и развитием решений для ипотечного кредитования. Во время моей предыдущей деятельности я интенсивно работал над превращением работы по Аджайлу в модель, подходящую для эффективной организации.

В первые несколько недель я решил понаблюдать за группой.

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

Казалось, все шло хорошо, пока мы не подошли к первому большому релизу продукта.

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

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

Я предложил новичкам (тем, кто проработал в нашем трайбе менее 6 месяцев) поделиться со мной своим видением, и они также отметили отсутствие взаимопонимания между представителями бизнеса и ИТ. Кроме того, они выразили сомнение в том, что функции, над которыми работали скводы (команды), действительно были самыми важными для клиента и клана, а не только для самих этих скводов.

В то же время, при создании целевой платформы для Бельгии и Нидерландов, я столкнулся с проблемами, связанными с отсутствием требований к ее возможностям, необходимым каждой из этих стран, а также образом мышления в стиле «они и мы». Как же свести все это воедино…

Я не знал, что делать, поэтому начал искать помощи. К счастью, примерно в это время на нашу обучающую сессию зашел ИТ-директор, и я рассказал ему о нашей ситуации. Он сказал, что знает кое-кого, кто мог бы мне помочь и даже когда-то проводил Go See (сессии выявления проблем) для моих команд ― он представил меня Сезарио.

Я (рассказывает консультант) познакомился с представителями Голландского Банка, когда выступал с докладом на встрече. Моя лекция была о программистах в условиях крупномасштабной разработки. После лекции ко мне подошел один джентльмен и рассказал о проблемах, которые он наблюдал в своей группе. Позже он представился как ИТ-директор из Голландского Банка в Нидерландах.

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

Я не был в этом особенно заинтересован, так что сказал, что отправлю ему свое предложение позже на этой неделе. Он ответил: «Хм-м… Я думал, что Аджайл подразумевает, что сотрудничество с клиентами важнее условий контракта?»… Его ответ заинтриговал меня, и я решил съездить в Голландский Банк и посмотреть, что же там происходит.

Итак, пару недель спустя я поехал туда, чтобы провести там сессию Go See в течение пары дней.

Я часто начинаю совместную работу с сессии Go See. Я провожу такие сессии, чтобы выразить свое уважение команде и ее руководству, а также понять, как выглядит работа команд.

Один из моментов, на которые я обращаю внимание ― повторяющиеся события. Паттерны событий, которые происходят снова и снова через некоторые время. Почему? Потому что такие паттерны ― результат организационной структуры, процессов и политик, с которыми работают люди. И систематически возникающие проблемы, скорее всего, можно решить лишь с помощью улучшения организационного дизайна. Вопреки распространенному убеждению, полностью исправить системные проблемы невозможно путем одной лишь работы с людьми.

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

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

На основе всей этой информации я сформировал у себя понимание того, как происходит работа, и использовал это для составления рекомендаций.

Далее я расскажу о своих наблюдениях, имеющих отношение к теме этой статьи.

Продуктовая группа называется трайб. Ее директор ― представитель бизнеса и эксперт в области рынка кредитования бизнеса. Его называют лидером трайба. Команды называют скводами. В сквод входят носители бизнес-знаний (CJE), навыков ИТ и разработки, а также DevOps. В каждом скводе есть Владелец Продукта, который управляет Бэклогом сквода. За развитие навыков и компетенций людей отвечает чаптер лид. Они есть как в ИТ, так и в бизнесе.

Аджайл-коуч поддерживает работу клана в соответствии со стандартом Аджайла Голландского Банка. Владелец Продукта, чаптер лид и Аджайл-коуч объединены в тройку, называемую POCLAC. Участники POCLAC регулярно встречаются, чтобы обсудить проблемы и решения возможных проблем скводов.

Ниже изображена схема такой организационной структуры.

Трайб состоял из 24 скводов. Некоторые скводы были территориально распределены. И большинство скводов было тем, что в терминологии LeSS мы называем компонентными командами.

Я также заметил, что в них было 24 командных «Владельца Продукта». Они были постоянно заняты уточнением требований, управлением бэклога, координацией работы команд и управлением командами.

Изменения, которые проводили командные «Владельцы Продукта», были локальными. Я нашел множество примеров, которые это подтверждают. Вот один из них: Скводу 3 требовались изменения в API, а Сквод 6 планировал выполнить эти изменения. Позже в Скводе 6 решили не выполнять этих изменений, и Сквод 3 не смог завершить свою работу. Этим отрядам было очень трудно согласовать свою работу с целями трайба и продукта в целом.

Хотя у каждого сквода была четкая цель, зачастую эта цель не была значимой для конечных пользователей. Из этого факта явно следовало, что большинство отрядов были не в состоянии доставить ценность конечным пользователям самостоятельно. По отдельности эти отряды могли только выполнять часть всей фичи. Большинство скводов зависели друг от друга, и степень этой зависимости составляла от 30 % до 80 %. Зависимости замедляют разработку фич, удлиняют очереди задач различных скводов, увеличивают петлю обратной связи на рынке, а также снижают гибкость на уровне трайба и предсказуемость на уровне продукта. Это большая проблема, которая при добавлении новых компонентных команд может вырасти экспоненциально.

Я подумал, что этот способ работы ― идеальный пример реализации принципа Copy-Paste масштабирования [1]. Это распространенная ментальная модель для масштабирования Аджайл-подходов, которая не дает хороших результатов.

Такая организация работы часто приводит к повторяющимся проблемам, связанным с ненадежными прогнозами, низким фокусом на цели всего трайба и неспособностью реагировать на поступающие идеи.

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

На этом графике изображены результаты изучения зависимостей в трайбе, состоящем из скводов. Цвет каждого круга обозначает, на сколько процентов загружен тот или иной отряд разработкой фич для конечных пользователей в определенной области. Если круг полностью окрашен в синий цвет, это означает, что соответствующий сквод загружен на 100 % в «синей» области.

Выяснилось, что отряды с синими кругами (1, 2, 3, 4, 5, 7, 8, 18 и 21) должны вместе работать над одним продуктом, потому что эти отряды нужны практически для каждой фичи.

Чаптер лидеры вели себя как монофункциональные менеджеры. Например, для каждой конкретной технологии (Pega или Java) был свой ИТ-лид чаптера. Монофункциональные менеджеры предлагают своим сотрудникам карьерный рост лишь в области одного конкретного навыка. Они не могут предложить им расти в области нескольких навыков, хотя именно это требуется для создания адаптивной команды.

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

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

Семнадцать скводов работали в фиче-бранчах. Это означало, что они неделями, а иногда даже месяцами, работали изолированно, без интеграции своего кода с кодом других скводов. Я выяснил, что особой причины наличия такого большого количества веток не было, кроме той «здесь так принято работать».

Ветвление приводит к замедлению координирования, к задержкам, проблемам интеграции, снижению возможности рефакторинга и долгим и болезненным фазам стабилизации, которые полны сюрпризов. В отсутствии непрерывной интеграции координация затруднена.

Неудивительно, что в таких условиях релизы постоянно проходили болезненно и прогнозы были непредсказуемыми.[2]

Последнее наблюдение, которым я хотел бы поделиться, связано с разработкой через выдаваемые решения. Раз в квартал проводились сессии квартального уточнения бэклога (QBR), где отрядам выдавались задачи Epic, состоящие из нескольких историй, которые необходимо было выполнить. Производительность измерялась по мере выполнения задач Epic и входящих в них историй. Целью отрядов было выдать все истории в начале следующего квартала, как и планировалось. Чем более вы предсказуемы, тем лучше результат.

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

То есть целью было доставить определенный набор задач или решений Epic. Вместо достижения определенного значимого результата. Командам выдавалась работа для выполнения, а не проблемы для решения.

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

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

Нам предстояло получить ответы на следующие вопросы:

Выводы, к которым мы пришли в результате сессий Go See, позволили нам выработать дальнейшее направление работы.

Надежность наверняка была бы выше, если бы мы понимали, где находится наш трайб в любой момент времени относительно наших квартальных целей.

Мы решили, что прозрачность нашей работы возрастет, если каждые две недели мы будем знать, что было и что не было сделано на уровне всего продукта.

Поэтому мы решили:

Основываясь на результатах сессий Go See, мы пришли к выводу, что фокус и соответствие цели на уровне трайба, вероятно, можно повысить, если сократить автономию скводов, попросив их достигать какой-либо общей цели в каждом Спринте.

Поэтому мы решили:

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

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

Поэтому мы решили:

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

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

Проблема в том, что обычно мы предпочитаем не делать того, что, по нашим ожиданиям, работать не должно.

Во время внедрения новых способов работы мы сделали много того, что по моим ожиданиям, не должны было сработать.

То есть мы не придерживались общепринятых идей по поводу того, как должно происходить подобное внедрение. Мы разрушили множество «правил»:

Мы (рассказывает Владелец Продукта) ставим перед собой следующие цели по улучшению процесса:

Первым шагом проекта кредитования бизнеса в Голландском Банке стала работа с семью скводами и одним Владельцем Продукта. Скводы работают в соответствии со стандартным процессом LeSS. Стоит отметить лишь один момент.

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

Все скводы переезжают из одной страны в другую во время Обзора Спринта. А поскольку продолжительность Спринта составляет две недели, получается, что раз в месяц все люди из Нидерландов приезжают в Бельгию и наоборот. Поскольку мы все делаем вместе, мы используем целый день, чтобы закрыть один Спринт и начать следующий.

Типичная повестка дня на Обзоре Спринта включает в себя: Видение Продукта, Цели Спринта, несколько параллельных демонстраций, корректировку работы на основе обратной связи и обзор планов на следующие Спринты.

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

Ниже я приведу несколько проблем, которыми мы хотели бы поделиться:

В течение первых нескольких Спринтов некоторые участники считали, что наши мульти-командные Уточнения Бэклога — всего лишь напрасная трата времени. Они утверждали, что и так хорошо знают, что нужно делать. Так почему они должны обсуждать все это заново с людьми, которые, возможно, даже не работали в таких условиях? Это неэффективно и кажется им нерациональным.

Я бы ответил им так: «Я понимаю, что вы все знаете об этом конкретном элементе Бэклога Продукта, но что вы знаете о других участниках своей команды?

Как вы можете знать все, если остальные этого не знают, тогда как наша цель — чтобы любой сквод мог взять в работу любой элемент Бэклога Продукта? Если вы эксперт в теме “А”, а все остальные участники команды — эксперты в теме “Б”, то что случится, если в нашем Бэклоге Продукта останется только тема “А”? Это не то, чего мы хотим».

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

Я бы сказал: «Мы даем оценку влияния на бизнес, но не можем оценить, какую функциональность (истории) мы доставим и когда. Конкретная функциональность изменяется по мере того, как мы получаем фидбек о нашей готовой функциональности и ее влиянию на бизнес».

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

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

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

Образ мышления, привязанный к локальной эффективности, выявился во время Планирования Спринта. На Планировании Спринта скводы могли выбирать, над какими элементами Бэклога Продукта они хотят работать. Естественно, скводы выбирали те элементы, с которыми они были хорошо знакомы. Скводы не выбирали элементы согласно приоритетам. На рисунке ниже изображен Бэклог Продукта после того, как скводы выбрали для себя его элементы.

Иллюстрация показывает, что скводы выбирали элементы из верхней и нижней частей Бэклога. Они чаще выбирали элементы с меньшей ценностью из нижней части, чем элементы с большей ценностью из средней части.

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

Несколько раз мне приходилось стоять, держа в руках карточки элементов из средней части и предлагать их скводам. При этом я повторял, что это поможет им расширить свое понимание продукта в целом. Наша цель заключается в том, чтобы каждый сквод мог взять любой элемент из Бэклога Продукта. Это было нелегко, и прошло много времени, пока скводы свыклись с этой новой идеей. Сначала один сквод решился взять такой элемент, а вскоре за ним последовали остальные. Особенно после того, как скводы, которые избегали выбора элементов, в которых они не были экспертами, оказались перед лицом тех, кто на это решился.

В ранних Спринтах я очень хотел достичь успеха и делал для этого все возможное. Это был период долгих дней и коротких ночей. Я отвечал на вопросы, разговаривал с многими пользователями и стейкхолдерами, писал истории и задачи Epic, организовывал встречи и так далее. Я был просто невыносим. Это не могло продолжаться долго. Как я мог быть Владельцем Продукта для семи скводов?

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

Ситуация изменилась после того, как мы попросили участников команд самостоятельно создавать карты историй для решения наших главных проблем. Решение проблем стало их заботой, и это действительно помогло нам сделать уточнение Бэклога проще и эффективнее.

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

Введение Общей Ретроспективы существенно изменило эту динамику. В конце каждого Спринта представители скводов и руководители собирались вместе, чтобы обсудить имеющиеся проблемы. Скводам была предоставлена полная свобода улучшать то, что они хотят. Это привело к многочисленным действиям по улучшению работы, например, сессиям группового программирования, сессиям обмена знаниями, введению всевозможных стандартов, изменению способа проведения Уточнения Бэклога, изменению состава скводов и даже изменению способа проведения ими Общей Ретроспективы.

Мы проработали в такой конфигурации уже шесть месяцев и можем поделиться с вами некоторыми интересными результатами.

Основные наши выводы, которые мы считаем значительными, таковы:

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