Быть гибким, но не потерять банк: как работает Agile в кредитных организациях

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

Cерьезно, Agile и банки несовместимы

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

Судите сами:

• Первый принцип: «Люди и взаимодействие важнее процессов и инструментов». Да что вы такое говорите? Разве есть что-то важнее процессов и регламентов? Люди приходят и уходят, а процессы остаются! Кому не нравится – брысь из банка.
• Второй принцип: «Работающий продукт важнее исчерпывающей документации». Так, кто это сказал? Сжечь ведьму! Недостаточно документированный банковский продукт – страшная ересь. Документация должна быть настолько объемной, чтобы забаррикадировать дверь, когда после некрасивого сбоя придут ревизоры с Неглинки.
• Третий принцип: «Сотрудничество с заказчиком важнее согласования условий контракта». Тут почти правильно, только речь должна идти не о сотрудничестве, а о слепом подчинении разработчиков бизнесу. Кормильцам заведомо виднее, каким должен быть продукт.
• Четвертый принцип: «Готовность к изменениям важнее следования первоначальному плану». И снова дикая ересь. Какие такие изменения? Планы были утверждены на Заседании Правления! Что это вы в них вносить задумали? Возомнили себя умнее Членов Правления? Вон из банка! Новых найдем!

Собственно, с новыми-то проблема и возникла. «Альфа-Лаборатория» во многом потому и появилась, что в банке окончательно сложилась текучка кадров. Следуя уже тогда модному тезису о том, что банк – это IT-компания, разработчики уходили в Google, Яндекс, информационную безопасность, собственные стартапы…

А между тем число банковских сервисов росло...

Росли требования к системам ИБ. Постоянно менялись требования регулятора, которые также необходимо было учитывать в работе. И если году в 2005-м можно было сказать в августе: «ОК, мы учтем это в плане на следующий год, утвердим на совете директоров и весной сделаем», то в 2015-м такое не прокатывало.

Делать надо было сразу. Не ожидая согласования документации. А вот кому делать – понятно было средне. Спрос на программистов и тимлидов в банковской среде вырос колоссально, а вакансии заполнялись весьма неторопливо. Собственно, именно программист сегодня – самый востребованный банковский сотрудник.

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

Но есть один нюанс

Спросите любого специалиста по внедрению Agile в организациях, и он вам скажет – «Все принципы должны соблюдаться одновременно. Если хоть что-то не соблюдается – это уже не Agile, а черт знает что».

Только тогда появляется нужная гибкость в членах. Но, например, у банка «Открытие» команды разработчиков традиционно находятся в Москве и Саратове. У Модульбанка – в Москве и Уфе. Соединять их во имя соблюдения Манифеста – значит потерять время, деньги и людей (трудно поверить, но далеко не все разработчики так уж рвутся в Москву).

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

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

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

Получается забавно

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

Я попросил показать канбан. Меня подвели к обычной офисной доске метр на метр, где просто было расписано – кто чем занимается в данный момент. Рядом висел небольшой колокольчик. Что же. И канбаны бывают очень разными…

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

Послушать людей, знающих толк в банковской гибкости, и примерить их идеи на себя, можно на III ежегодной клубной конференции «Гибкое управление проектами в банках», организованной ИА Банкир.Ру. Она состоится 24 октября.

Материалы по теме:

Отдайтесь Agile-трансформации: как создать успешную Scrum-команду

Зомби не пройдут. Как выбрать Scrum-мастера для вашей команды

Три распространенных ошибки тех, кто захотел перейти на Scrum

«Псевдо-аджайл» только поначалу выглядит круто – разрушаем популярные мифы

Скрам для маркетологов. Холакратия для счастья. Что подходит вам?