Существенная часть аgile-трансформации – изменение культуры. Гибкой следует делать всю организацию целиком. Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка», рекомендует руководителям, которые хотят построить гибкую организацию, запастись терпением и быть аgile, а не внедрять его. Таков был главный посыл его выступления на форуме ITMF 2017, организованном издательством «Открытые системы».
– Зачем вы хотите стать agile?
Чтобы быстро запускать новые идеи и делать так, чтобы клиентам это очень нравилось.
– С чего у вас все началось?
Все началось с дирекции ИТ, которой предъявляли две классические претензии: долго и дорого. Если все делать быстро, нужно минимум шесть месяцев, чтобы установить минорную задачу в продуктив. И то, если вложиться всей душой. Сегодня это малоинтересно бизнесу.
Agile, DevOps и Scrum – это зачастую дорого. Но на уровне правления мы решили, что нам важнее скорость запуска продуктов и уровень удовлетворенности клиентов.
– Почему дорого, если вы экономите время. Ведь время стоит денег?
Но размер команды-то меняется... Например, за развитие фронт-офисных систем отвечает команда из 50 человек, у нее 30 заказчиков. В этих системах обслуживаются кредиты, депозиты и другие банковские продукты. Если мы строим продуктовую команду, нам нужны разработчики, хотя бы по два на каждый продукт. То же самое с тестировщиками и поддержкой, которые нужны в каждой команде. То есть штат растет, и надо понимать для чего это.
– Рост штата не компенсируется повышением скорости?
Затраты растут, но мы ожидаем, что и прибыль вырастет – благодаря тому, что мы делаем быстрее и больше, фокусируемся на удовлетворении потребностей клиентов. Когда целями являются time-to-market, клиентский опыт (customer experience) и повышение индекса потребительской лояльности (net promoter score, NPS), то аргумент «дорого» отходит на второй план.
Вот, к примеру, такая ситуация. Бизнес-заказчик спрашивает, когда для него сделают нужную ему доработку, а ему отвечают: вот очередь твоих коллег, приходи через месяц или докажи, что твоя задача – самая приоритетная. Вариант нанять еще 10 человек и сделать работу за месяц не проходит, потому что нет возможности наращивать расходы на ИТ. Количество запросов от заказчиков очень высоко, и если не увеличить число разработчиков, то нужные продукты будут получены только к 2028 году.
Сейчас ситуация меняется: человек из бизнеса сам приходит в правление банка и говорит, что из заработанной в прошлом году суммы хочет инвестировать часть в расширение ИТ-команды, потому что видит набор идей, которые можно реализовать, что позволит заработать больше. Таким образом, ушел тезис, что ИТ – это дорого.
Теперь второй тезис: ИТ – это долго. У нас порядка 30 заказчиков на одну систему, а в банке их – условно 300. Портфельное управление задачами – это сложные и долгие процессы. Cейчас мы уходим в парадигму, когда у нас есть «собственник» продукта. Ответственный за конкретный бизнес-продукт по сути сам себе заказчик, поэтому три месяца из семи на совершение формальных действий по согласованиям автоматически исчезают. Теперь «собственники» решают, какая следующая опция появится в депозитах, а какая – в картах, у них получаются компактные команды, так как они отвечают за заработок в конце года.
– Сколько у вас команд сейчас и сколько предполагается в будущем?
Раньше у нас была одна команда из 50 человек и псевдогибкость – релизы мы выдавали не чаще раза в месяц. Теперь ее разбили на 10 команд поменьше, убрали очередь заказчиков. Сервисных команд сейчас 25, а продуктовых будет не менее 50.
– Внедрить гибкий подход вы пытались неоднократно. Когда наступил переломный момент?
До 2013 года предпринимались попытки внедрить аgile «снизу вверх», а в 2014-2015 годах – привнести его извне. В 2016 году председатель правления банка вышел на совет директоров и сказал, что хочет построить agile-организацию. C тех пор все изменилось, agile-команда стала не айтишной, а полнофункциональной, в нее вошли управляющие директора, которые отвечают за кредитные и некредитные продукты в ретейле. Они почувствовали все преимущества гибкости и теперь сами ее хотят. Поменялось и то, как мы внедряем agile. Мы внедряем его не по плану, а по Scrum.
Раньше это было «играми айтишников» и предполагалось, что agile – это про то, как мы пишем код. А в действительности это про то, как мы развиваем продукты, как работаем в условиях неопределенности и как в целом принимаем решения. И мы поняли, что можем масштабировать этот подход на корпоративный уровень. Это означает изменение культуры всей организации, изменение того, как мы планируем бюджет, оцениваем людей, делегируем полномочия. Это история не про ИТ, а про банк в целом, и менять надо весь банк.
В связи с этим возникает множество вопросов. Как работают проекты? Какие нужны метрики? Как меняется роль топ-менеджеров?
– На каких проектах происходило внедрение agile?
Мы от управления проектами переходим к управлению продуктами. Трансформация – дело длинное. К примеру, мы развиваем новый ипотечный конвейер. Раньше кредитный конвейер внедрялся так: к 30 заказчикам приставлялся бизнес-аналитик, который писал большущую спецификацию, на нее рисовалась сложная архитектура, мы писали код, тестировали, отдавали через полтора года заказчику. А теперь команда, которая пишет конвейер, и человек, отвечающий в банке за все кредитные продукты, собираются вместе и смотрят на идею нового конвейера с точки зрения того, зачем он нужен и что нам мешает реализовать его прямо сейчас.
Теперь мы не пытаемся угадать, каким рынок будет через два года, и к тому времени выдать бизнес-заказчику продукт, который на 80% не соответствует его ожиданиям. Теперь заказчик в процессе разработки сам перечисляет свои ожидания и говорит, что конкретно ему надо прямо завтра.
Когда CPO (Chief Product Owner) это попробовал, то стал самым главным поборником всей этой истории, потому что понимает, чем заняты его сотрудники каждый день, почему это столько стоит, и отдачу начинает получать через месяц. Мы быстро тестируем идеи и начинаем зарабатывать сразу. А если это не нужно, то понимаем это не через три года, а через месяц и перестаем тратить деньги.
– В перспективе вы откажетесь от проектного управления или будете комбинировать его с agile? Какие ограничения agile вы видите?
В банке остаются и проектное управление, удельный вес которого снижается, и продуктовое, которого раньше не было. От проектов мы не откажемся никогда. Как заработать много денег на рынке, никто не знает точно. Существует набор гипотез, их нужно быстро проверять, для этого есть Scrum. К примеру, замена автоматизированной банковской системы – это сложно, но эксперты знают, как это сделать, проверки гипотез не требуется и проектный подход здесь будет всегда. В создании продуктов будут Scrum и его производные.
Проектное управление никуда не денется, потому что во многих ситуациях нужна кросс-продуктовая координация. Но роль проектного менеджера меняется, так как он становится членом продуктовой команды со своим набором задач, лежащих вне поля разработки конкретного продукта.
– Банк по сути жесткая структура, как он может быть agile? Как можно сочетать жесткость и гибкость?
Сочетать можно и нужно. Да, мы зарегулированы, однако регуляторные требования и групповые стандарты, которые нельзя нарушать для процессов планирования, бюджетирования, практически не имеют отношения к разработке продуктов, если мы не нарушаем базовых правил, типа обработки персональных данных. Поэтому Scrum тут вполне применим. Однако Scrum, родившийся в стартапах, где возможно все, в нашем случае, образно говоря, помещается в «контейнер» из стандартов, и градус свободы для Product Owner’a (ответственного за продукт) снижается.
Ограничения есть, но банк должен выстроить работу таким образом, чтобы они не мешали развитию продуктов.
– Помимо поддержки руководителя компании, какие еще условия должны выполняться, чтобы agile был эффективен?
Без поддержки руководства трансформация просто невозможна. И вся корпоративная бюрократия должна ее поддерживать. Корпоративные ценности должны соответствовать agile, а если не соответствуют, то их надо менять.
Очень важно иметь собственную экспертизу в agile. Рынок консультантов и людей, предлагающих услуги трансформации, в настоящее время довольно большой, и без понимания предметной области выбрать тех, кто подходит тебе, невозможно. С другой стороны, на рынке нет базовых специалистов, необходимых в командах, например Scrum-мастеров, их никто не отпускает. Их надо растить самим.
Cистема корпоративного обучения также подвергается изменениям, особенно если она была построена на таких вещах как ITSM или PMBOK.
Кроме того, надо менять всю систему карьерного продвижения людей в организации. Гибкая организация ведет себя по-разному в зависимости от ситуации, исходя из этого строится вся система мотивации, карьерного продвижения и бонусов. Сейчас все, как всегда, упирается в людей. Нужно нанимать людей с правильным складом ума и с правильными ценностями, смотреть, может ли человек работать в команде и нацелен ли он на общий результат.
– Что вы посоветуете ИТ-руководителям, которые хотят внедрить agile?
Первым делом – запастись терпением. Каждую неделю мы рассказываем про аgile на разных уровнях – и этого все равно недостаточно. Мы занимались DevOps полтора года, много и активно вкладываясь, но казалось, что ничего не происходило. Однако спустя полгода вдруг что-то начинает появляться как бы само. Мозг у людей быстро не поменяется, надо несколько лет рассказывать одно и то же.
С точки зрения agile в ИТ мы лидеры среди европейских подразделений банка, но с точки зрения бизнеса мы только в начале пути, хотя по сравнению с другими организациями у нас большой прогресс. Мы поняли, что такое продукт, каковы полномочия «собственника» продукта, и к концу 2017 года запустим множество продуктовых команд по Scrum. А дальше будем долго «докручивать» всю бюрократическую обвязку и долго-долго менять мышление.
