По мотивам Форума «Трансформания», который прошел в мае, мы подготовили для вас выжимку интересных мыслей и кейсов об опыте Agile-трансформации и сокращении time2market в банках. Наперекор расхожему мнению, что Agile не работает в организациях со строгой иерархией, спикеры доказали, что работает и рассказали свою историю трансформации.

О своем опыте трансформации банка от принципа управления «топ даун» к созданию команд рассказал Владимир Химаныч, управляющий директор по работе с персоналом «Райффайзенбанк».

Что стало мотивом? Зачем мы пошли по этому пути? Перед нами стояли задачи: нам надо было сократить время выхода на рынок продуктов, повысить вовлеченность сотрудников в развитие бизнеса и их эффективность.

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

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

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

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

Agile для нас оказался удобным. При agile-трансформации первым и главным вопросом стал - что собой представляет продукт? Когда можно создавать agile-команду? Для себя мы выделили 6 характеристик продукта:

1.  У продукта есть внешний клиент, который готов за этот продукт платить?
2.  Возможно, что в этом продукте существует выделенный P&L (отчет о прибылях и убытках)?
3.  Присутствует высокая зависимость от ИТ-компонентов?
4.  Нуждается в быстрой разработке?
5.  А также нуждается в feature adoption map?
6.  Продукт достаточно большой?

Мы создали 14 команд, которые достаточно легко ответили на эти вопросы. В командах были выделены роли: technical lead, scrum master, product owner. Впоследствии, product owner раздробился на service owner, platform owner, channel owner, product owner. Также в команде, конечно, присутствовали ИТ-таланты: разработчики, тестировщики, аналитики, инженеры, которые участвуют в разработке продукта.

У каждой команды был свой коллегиальный орган управления, те, кого мы назвали PTS (product owner. technical lead, scrum master). Эта модель команды показала свою эффективность. PTS не выделяет кого-то более главного, принцип полного равенства, ни одна из этих ролей не является руководителем. Все ключевые вопросы решаются коллегиально. И здесь действовал принцип, о котором команда договаривалась сама: либо принцип консенсуса, либо делегирование принятия решения. По факту от второго команды отказались, т.к. он не работал.

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

Параллельно мы перестраивали и работу правления с тем, чтобы не мешать развитию, не создавать антитез, вот Agile, а вот и все остальное.

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

Вся эта история также предполагала большую перестройку связанную с автоматизацией. И нам пришлось разработать много новых инструментов, чтобы команды работали эффективно: продуктовая школа, академия скрам-мастеров, ИТ-академия, которая отвечает на вопрос, какой мой путь в банке. Люди должны развиваться и ИТ-компании предоставляют такой путь развития, мы пошли по тому же пути. Демо-дни, это супер важно, если раньше на демо-дни приходили 200, сейчас 500-1000 человек, всем интересно, что происходит с продуктом, а product owner, может подсмотреть «фичи» и разработчиков. Теперь у нас внутри открытый рынок и они могут переманить к себе в команду разработчиков.

Наши белорусские банки также встали на тропу agile-трансформации. Вот, что о своем опыте рассказали банк БелВЭБ и БПС-Сбербанк:

Максим Смоляков, директор департамента инновационного развития ОАО «Банк БелВЭБ»: «При разработке новых продуктов мы столкнулись с ситуацией, что каждая новая доработка занимала большое количество времени. Нужно было снова и снова пересогласовывать изменения с различными подразделениями. В итоге, когда мы выходили к релизу продукта, он был уже неактуален. Потом мы пошли в Agile. В классическом виде Agile в банке не существует. Были выбраны наиболее подходящие практики. Взяли управление бэклогом, выделили отдельные команды по системам, вырастили у себя бизнес-аналитиков. Благодаря такой трансформации у нас изменилось, мировоззрение, что можно выйти на пределы банковского бизнеса, что можно идти туда, где клиенту удобно. Клиенту не нужен банк, ему надо удовлетворить потребности в том месте, где ему удобно. Так и появилась концепция, что банк должен стать высокотехнологичным партнером для клиентов или для партнеров банка.

Дмитрий Самцевич, директор департамента банковских технологий и процессов ОАО «БПС-Сбербанк»: «К моменту, когда мы принимали решение об Agile-трансформации средний time2market проекта составлял 1,5 года. В случае с проектами по совершенствованию инфраструктуры проект мог выдержать этот срок, но в случае с бизнес-проектами — это очень большой срок в условиях, когда надо уметь все менять на лету. Второе - непрозрачность процесса производства и стоимости разработки. С помощью Agile нам удалось решить эти два вопроса. Из нашего опыта мы извлекли уроки.

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

Что такое time2market или почему этот показатель важен для бизнеса рассказал Максим Белоусов, член Правления Российского Союза ИТ-директоров.

Будучи Заместителем Председателя Правления ПАО «БАНК УРАЛСИБ» Максиму с командой удалось в разы улучшить показатели time2market (в 4 раза), доступности, непрерывности, SLA при сохранении минимального роста количества сотрудников и бюджета. Максим разработал собственную систему постоянных улучшений. В своем выступлении он рассказал с помощью каких организационных изменений внутри ИТ-подразделения можно прийти к сокращению time2market.

«Мы должны быть не супер-быстрыми, у бизнеса должен быть зрелый ИТ, который по требованию в нужные бизнесу сроки выводит в продакшен те или иные изменения.

В первую очередь, давайте разберемся из чего состоит time2market? Мы у себя выделили 3 понятия: time2market, time2open, time2test.

Мы работали над каждым элементом в отдельности, совершенствуя его. Как результат добились его сокращения в 4 раза.

За счет чего удалось этого достигнуть? 99% цифровой трансформации - это управление изменениями. Этот процесс должен быть формализован. Необходимо управлять жизненным циклом управления изменениями. В нашем случае жизненный цикл выглядел таким образом:

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

Был внедрен общий KPI - сокращение t2m для всех, бизнес-руководителей в том числе. При этом у нас было постоянное изменение нормативных показателей, шаг за шагом. Мы ставили достижимые цели. Позже показатель постоянно сдвигался. Сразу далеко не прыгнешь: сначала на 1,2 метра, потом 1,3.

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

ВРЕЗКА:

Перечень других организационных мер, о которых рассказал Максим Белоусов:

• разработали чек-лист, что такое качественное бизнес-требование (все жалуются, что бизнес плохо пишет требования, эти требования проверялись самим бизнесом по чек-листу на выходе);
• выделена роль аккаунт-менеджера, который представляет интересы по взаимодействию с тем или иным подразделением;
• создание функциональных групп, эти группы были аккумулированы на определенных бизнес-процессах;
• на уровне разработчиков выделили роль инженера-аналитика - он переводил запросы на язык разработчика, при этом разработчик сфокусировался на разработке;
• проработали скорость с подрядчиками.
• настроили мотивацию команды, если обещали за 30, а сделали за 20, получали свои бонусы.
• был внедрен единый календарный ресурсный план - все видели, когда задача должна поступить на тест и т.п.
• упрощенная система приоритезации задач, их должно быть не больше трех.
• автоматизация тестирования, так мы сократили тестирование вместо 30 дней сейчас в среднем 10 дней. Тяжело релизами управлять, когда много информационных систем. С помощью автоматизации смогли спланировать релизный план и сделать это чаще, и изменения могли быстрее попадать в продакшен.

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