Внедрение digital в большой компании должно вести к резкому росту выручки. К такому выводу пришли участники конференции «Гибкое управление проектами в банках», организованной информационным агентством «Новости Банков», которая проходит 24 октября в Зиларт-холле.
«Вот появится окошко - и впишите нас туда»
Что нужно делать, чтобы гибкие подходы – agile - работали в банках? Как это не банально звучит, но нужно менять менталитет людей, которые в банке работают. Например, раньше спонсоры давали деньги на проект и ждали результат. А мы пытаемся им объяснить, что и спонсоры тоже несут ответственность за успех этого проекта, заявил управляющий директор департамента по управлению изменениями Росбанка Евгений Зубков.
«Мы столкнулись с бюрократией, и это осложнило многие шаги. Накопив опыт, мы поняли, что многие проблемы нужно решать быстро, а бюджетирование, например, расписано вперед на полгода», - отметил он.
Зубков признал, что настроить хороший проект на работу с внешним миром в таком большом банке, как Росбанк, сложно, так как у кредитной организации много внутренних систем и команд. Поэтому совместить разработку с 5-6 интеграциями сразу нереально. «У каких-то команд есть букирование на 5-6 месяцев вперед, и они не могут влиться в проект сразу. Мне было сказано – вот через пять месяцев у нас появится окошко – и впишите нас туда. Задача с интеграцией в Росбанке пока рождает наибольшие сложности», - сказал Зубков. При этом он считает, что не все процессы в банке можно сделать в режиме agile.
«Команда разработки всегда работает хуже, чем могла бы»
Руководитель собственной разработки Tinkoff.ru Андрей Шелехин отметил, что для организации работы банка часто не хватает готовых IT-решений, поэтому многое приходится реализовывать с нуля. Например, облачную платформу удаленных рабочих мест, на которой сейчас трудоустроено около 9 тыс. сотрудников или систему для ежедневного планирования оптимальных маршрутов представителей банка по всей России.
В идеальном мире разработка не вносит никаких задержек в процесс создания ценности. В реальности же, по мнению Шелехина, существуют три критерия эффективной разработки - задачи реализуются прогнозируемо и с приемлемой для бизнеса скоростью, разработка успевает реагировать на возникающие изменения, не сбавляя темп, а с ростом функционала скорость выпуска новых фич как минимум не падает. Определить максимальную скорость, с которой могла бы двигаться команда – невозможно, но стоит исходить из того, что команда разработки всегда работает хуже, чем могла бы.
Андрей рассказал, что для поиска узких мест в процессе разработки в автоматическом режиме собираются различные метрики: время от появления идеи до выката на прод, емкость выпускаемых задач, временные затраты на каждом этапе разработки, а также время простоя между ними. Анализируются показатели качества и точности оценки задач.
В основе любых изменений должна лежать выявленная и осмысленная проблема
Первостепенной задачей на пути повышения эффективности разработки Андрей назвал организацию процесса непрерывных улучшений, т.к. в любой момент времени каждому участнику проектной команды что-то мешает работать эффективнее. Для этого в командах раз в две недели проводятся ретроспективы. Они помогают вытягивать на поверхность текущие проблемы, обсуждать их, составлять план конкретных небольших улучшений и контролировать его выполнение. «В основе любых изменений должна лежать выявленная и осмысленная проблема», - считает Андрей.
Необходимо сделать так, чтобы разработчик понимал смысл задач, которые делает. Если заказчик приходит к ИТ-специалисту с готовым решением своей проблемы, не объясняя, зачем это нужно – это работает плохо. Во-первых, пропадает возможность найти более простое и быстрое решение за счет экспертизы разработчика. Затем допускаются ошибки в требованиях, приводящие к багам. Падает качество архитектуры, растет стоимость владения кодом, кроме того исчезает ответственность за результат и желание делать хорошо, отметил представитель Tinkoff.ru.
Андрей рассказал, что команды стремятся к максимально коротким итерациям. Для этого в каждом новом функционале выделяется MVP и ищутся способы снижения стоимости релизов: минимизируются ручные действия администраторов, внедряются DevOps инструменты, происходит уход от монолита к сервисной архитектуре и автоматизируются процессы контроля качества.
Мы визуализируем весь процесс разработки, чтобы синхронизировать работу участников и как можно раньше выявлять и реагировать на проблемы. Формируем небольшие сфокусированные команды – аналитик, несколько разработчиков, тестировщик, там, где нужно – дизайнер. Эти маленькие команды реализуют фичи от идеи до выката на прод, они сфокусированы и не тратят время на лишние коммуникации. Более того, в небольших командах всегда виден вклад каждого участника и легче выявить отстающих.
Существенно повысить эффективность процесса разработки можно за счет автоматизации рутинных действий
Для коммуникаций используем корпоративный мессенджер, определяем допустимое время реагирования в разных каналах и стремимся к тому, чтобы разработчиков реже вырывали из контекста.
Существенно повысить эффективность процесса разработки, по мнению Шелехина Андрея, можно за счет автоматизации рутинных действий. В качестве примера Андрей привел рекомендательную систему, которая отслеживает состояние процесса и подбирает для разработчика задачу, которая в данный момент наиболее полезна. После того, как разработчик заканчивает работу над фичей, в работу вступает бот. Он разворачивает отдельное окружение для ее тестирования и сообщает тестировщику, что можно начинать проверять. После того как тестирование закончено, бот сам пытается влить изменения в основную ветку и привлекает разработчика только если требуется ручное разрешение конфликтов.
«Мы уходим из мира стабильности и комфорта»
Модератор первой сессии, head of AI в МТС Аркадий Сандлер спросил у Шелехина о том, как часто от него уходят разработчики. На что тот ответил, что такое происходит крайне редко, и банк, наоборот, сейчас набирает специалистов.
Начальник отдела исследований и разработок в «Ак Барс цифровые технологии» Ярослав Шуваев рассказал об опыте внедрения agile в своей практике. Он отметил, что в банках работает раздвоенная мораль, так как менеджмент кредитной организации живет в своей метрике, а ИТ-специалисты - в своей.
«Есть ли конкретный пример – сделали, например, вы в банке то-то и то-то, и прибыль увеличилась на столько-то?» – спросили у спикера в телеграмм-боте BankPM2017.
По словам Шуваева, такие случаи были. Например, был полностью написан мобильный банк, что позволило уйти от коробочного решения. «Над ним работало не так много народу, и весь его «фарш» был сделан за год. А стоимость этого мобильного банка была дешевле, чем покупать решение у вендора», - рассказал Шуаев. Аркадий Сандлер спросил, чье это было решение - уйти от вендоров: чье-то директивное, мол, мы теперь независимые, или влияние рынка? На это Шуваев ответил, что проще и дешевле держать свою ИТ-команду внутри банка, чем содержать топ-менеджеров вендора.
Все-таки и банк, и телекомы должны оставаться сервисными организациями
Шуваев также отметил, что банки стремительно превращаются в ИТ-компании, на что Сандлер возразил, что сейчас ИТ-компаниями стремятся стать практически все. Сам Сандлер отметил, что работает в большом телекоме, и тот тоже превращается в ИТ-компанию. Но ни для телекома, ни для банка – это не цель. Все-таки и банк, и телекомы должны оставаться сервисными организациями.
«Много ли вы видели примеров успешных запусков проектов в больших компаниях?», - спросил у аудитории директор по digital «Ростелекома» Вячеслав Благирев. По его словам, сейчас как только большой проект создается, он тут же устаревает. При этом еще и руководство в крупной организации меняется примерно раз в два с половиной года. Мы сейчас уходим из мира стабильности и комфорта и переходим в жизнь в мире Vuca - в ситуации нестабильности и неопределенности, этот термин придумали американские военные.
Ростелеком запустил шесть гибких проектов за восемь месяцев. Например, в Санкт-Петербурге создан сервис онлайн-переезда. Это полностью agile-проект, который позволяет в онлайне перевести все услуги телекома из одной квартиры в другую. Этот проект повышает лояльность клиентов – после его внедрения люди перестали при переезде менять провайдера.
В бою нет времени бояться, надо просто идти и делать. Поэтому agile – это история про «здесь и сейчас». О том, что надо идти и делать
«В бою нет времени бояться, надо просто идти и делать. Поэтому agile – это история про «здесь и сейчас». О том, что надо идти и делать», - отметил agile coach «Ростелекома» Олег Егоркин. При этом его коллега Вячеслав Благирев считает, что при внедрении digital выручка компании должна расти кратно.
Не надо делать большие и классные проекты. Делайте по чуть-чуть, но непрерывно, полагает руководитель центра качества Альфа-Банка Антон Исанин.
Аркадий Сандлер спросил: получается так, что для того, чтобы все гибкие методы заработали, надо устроить несколько публичных казней? На что Исанин ответил, что все проблемы – в голове, и именно голову надо «менять». А если человек сопротивляется изменениям, его надо увольнять.
