«Использование какой-либо модели, кроме гибридной, просто невозможно для крупного универсального банка» – Кирилл Меньшов, банк «Открытие»

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

Сейчас многие смотрят на Agile как на некий святой грааль – стоит его внедрить, и все станет хорошо. Рассматриваете ли вы эту модель как единственно правильную? Нельзя выбрать одну модель, которая бы всем подходила, не существует единственной правильной модели организации IT. Особенно, если мы говорим о крупном универсальном банке.

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

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

Отдельно отмечу, что на рынке у каждого свое понимание Agile, и из-за этого возникает много вопросов. Чаще всего под ним понимают итерационную разработку, в которой используется методология Scrum. Многие даже называют Agile все, что угодно, когда нет требований или технического задания, и надо срочно что-то сделать. Мы также достаточно давно применяем и Scrum и итерационную разработку, но наша целевая Agile-модель, в тех командах, где она применима, – это сочетание итерационной разработки и Lean product management.

И, кстати, многие недостатки, которые приписывают Agile – такие как отсутствие сроков, скоупа (набора задач) и бюджета – на самом деле исходят из того, что люди пытаются оторвать одно от другого. Для нас эти две составляющих неделимы. Только они вместе – это Agile.

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

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

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

А зачем вообще нужен Agile? Считается, что он создан для того, чтобы быстрее выводить продукты на рынок. Это так? Именно. Но надо сравнивать яблоки с яблоками. Agile позволяет гораздо быстрее вывести MVP (Minimal viable product – минимально жизнеспособный продукт), достижение же финального результата не настолько однозначно.

То есть модель Agile лучше водопадной? Модель Agile подходит только под определенную организационную среду. Признаком такой среды является готовность работать в концепции Lean product management.

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

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

В чем отличие Lean product management? В Lean product management дедлайн проекта определяется сроком выпуска проекта, а его скоуп является динамичным и определяется командой и менеджером продукта. Мы представляем новый продукт, показываем концепт, описываем продукт в виде некой матрицы, где идет пересечение трех плоскостей. Одна из них – банковский IT-ландшафт, вторая – жизнь клиента в банке, третья – продукт. Нас интересует пересечение клиента и нашего продукта. Мы описываем этапы знакомства клиента с нашим продуктом внутри банка – привлечение, изменение определенных параметров, подключение продукта, выгрузка в учетные системы, в отчетность, закрытие продукта и т.д. А дальше на каждом этапе прописываем фичи.

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

В итоге вероятность уложиться в дедлайн при таком подходе гораздо выше, чем при разработке по ТЗ. Потому что при ТЗ любое изменение внутри проекта требует согласования, и менеджер продукта будет всячески саботировать его принятие, потому что это будет либо увеличивать стоимость проекта, либо менять набор фич. Здесь концепция обратная – менеджер продукта сам выбрал фичи, которые будут входить в скоуп. Он является составной частью команды, и сам ей управляет. Нет этого разрыва: «Я – заказчик, вот мои требования, и делайте, что хотите, но их выполните».

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

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

А что мешает ввести Lean product management повсеместно именно «Открытию»? Во-первых, нехватка менеджеров с нужными навыками. Как уже говорилось, менеджеров продукта так работать не учат, всю жизнь они работали по-другому. Но мы развиваемся постепенно, обучаем их. Во-вторых, все-таки неполная его применимость.

Кстати, сейчас мы в банке «Открытие» как раз ищем таланты для инновационного проекта для малого бизнеса в сфере диджитал и IT. Здесь можно посмотреть подробнее: https://www.openbank.ru/smehr.

То есть нельзя сказать, что Agile во всех случаях лучше? Можно ли сказать, что «Белаз» лучше болида «Формулы 1»? Есть целый ряд задач и ситуаций, когда водопадная модель подходит гораздо больше. Предположим, все работают идеально – никто не меняет никаких требований, все сразу зафиксировано правильно, никто не ошибается в проектной архитектуре и аналитике. В этом случае задача в водопадной модели будет сделана лучше, чем в Agile – быстрее и дешевле, причем существенно – раза в два. Нет лишних итераций, лишнего развертывания и регресса предыдущих операций.

А разве так бывает? Я как раз и хочу сказать, что бывает очень по-разному. Если есть четкая, детерминированная задача; есть понимание, как ее сделать; понятен дедлайн и он достаточно комфортный – тогда Agile не нужен. Например, автоматизация регуляторной отчетности. Зачем утром проводить Scrum-встречу по изменению формата печатных форм? Это бессмысленно. Если вам нужна траншея – нужно брать лопату и копать.

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

Эта статья была разослана 1196 людям, которые подписались на тему «IT в банке»

Чтобы подписаться на «IT в банке», просто введите Ваш электронный адрес.