Подход Agile: как это работает в Промсвязьбанке

Скорость внедрения качественных продуктов – главное конкурентное преимущество банка. Понимая это, в Промсвязьбанке перешли к применению agile-подходов, перевели мобильные приложения на собственную разработку и выпустили абсолютно новые, усовершенствованные приложения для iOS и Android.

Почему Agile?

Говоря о причинах перехода на Agile, руководитель блока «Цифровой бизнес» Промсвязьбанка Алгирдас Шакманас говорит, что этот подход позволяет банку пересмотреть культуру взаимодействия между людьми, которые участвуют в проекте. Agile – это в первую очередь особый образ мышления и уже потом семейство подходов и конкретных технических практик разработки продуктов.

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

В Agile организационная структура упрощается. «Подход пришел в бизнес из мира разработки программного обеспечения. Манифест Agile создали люди, уставшие от поиска “серебряной пули” (лучшего метода разработки), которая позволит наилучшим образом разрабатывать программные продукты, способные удовлетворить реальные потребности пользователя. Эту пулю индустрия ищет, наверное, с момента появления первого программного продукта. Но в итоге выяснилось, что одной для всех серебряной пули нет», – говорит Алексей Чубенко, директор по развитию цифровых каналов Промсвязьбанка.

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

Организационный метод Scrum предполагает, что для соответствия принципу Agile – создания короткими итерациями ценности для клиента – необходимо вести работу двухнедельными или месячными циклами (спринтами). Чтобы соответствовать потребностям пользователя и фокусироваться на создаваемом продукте, нужно, чтобы команда разработки была полностью занята в проекте, чтобы ей никто не ставил никаких других задач. В команде выделяется специальная роль мастера – человека, который разгребает препятствия, мешающие команде достигать цели и постоянно совершенствовать процесс разработки.

СПРАВКА. Scrum – спортивный термин, пришедший из регби, можно перевести как «схватка, толкотня вокруг мяча». Такой термин использовали создатели метода разработки программного обеспечения Кен Швабер (Ken Schwaber) и Джеф Сазерленд (Jeff Sutherland), возможно, потому, что он более точно описывает основные принципы работы небольшой кросс-функциональной команды над наиболее приоритетной ценностью продукта короткими циклами, результатами которых является готовая к использованию целостная часть продукта.

«Бытует мнение, что в подходе Agile за счет скорости и отсутствия централизованного руководства командой теряется качество, что работа ведется по принципу “тяп-ляп – и в продакшен”. На самом деле последнее характерно скорее для техники code-and-fix, применяемой стартапами, которым важно как можно скорее проверить продуктовую гипотезу на конечных пользователях, а уже потом, поняв, что продукт имеет ценность, повышать его качество. Если команда делает плохой код – это в любом случае не Agile, потому что не соответствует его принципам», – замечает Алексей Чубенко.

Хорошая новость заключается в том, что в Agile применяются лучшие технические и процессные практики разработки. В экстрим-программировании (XP), например, есть практика парного программирования, когда один программист пишет код, а второй сидит рядом за монитором, тут же читает этот код и обсуждает со своим напарником, как его можно оптимизировать. Это, казалось бы, в два раза дороже, но на самом деле оптимально и дешевле за счет уменьшения количества ошибок в коде, оба человека более погружены в проект, повышается взаимозаменяемость, люди меньше устают и работают эффективнее.

Самоорганизующаяся команда стремится соответствовать принципам Agile и постоянно ищет способы улучшить процесс разработки, повысить качество продукта и скорость внедрения. И если она не начнет применять, к примеру, лучшие практики DevOps, если не будут использоваться частые, быстрые сборки приложений, если не будет автоматического развертывания приложения и автоматического тестирования, не будут использоваться лучшие практики программирования и т.д., то за 2–3 спринта команда наберет большой технический долг (ошибки в системе, временные технические решения), который приведет к тому, что не будет соблюдаться принцип непрерывных ценностных улучшений продукта, потому что в следующих спринтах придется изменять архитектуру и проводить, к примеру, рефакторинг кода и исправление ошибок и «костылей», вместо того чтобы делать новую функцию для пользователей. Или, допустим, продукт будет полностью готов для пользователя, но его внедрение растянется на длительные этапы проверок и согласования с эксплуатирующим подразделением.

СПРАВКА. DevOps (от англ. development – разработка и operations – сопровождение, обслуживание) – набор подходов и практик разработки ПО, с фокусом на активное взаимодействие технических специалистов, участвующих в процессах аналитики, разработки, тестирования, внедрения и сопровождения продукта (программистов, тестировщиков и админов/внедренцев, сопровождающий промышленную эксплуатацию персонал).

Для выстраивания продуктовой «трубы» (или пайплайна, от англ. pipe – труба) от начала кодирования до внедрения конкретной ценности для клиента в продакшен применяется DevOps, чтобы эта труба была без узких горлышек, без задвижек и петель, а формировала прямой поток. Для этого в команду привлекаются все компетенции и роли, которые на пути следования этого потока ценностей могут на него повлиять. Если практики DevOps не внедрены, сотрудники, которые будут обслуживать эту систему, могут перед запуском решения вдруг обнаружить, что оно создано так, что эксплуатировать его нельзя и все нужно дорабатывать. Должна производиться автоматическая сборка приложения и автоматическое тестирование, по результатам чего принимается решение о дальнейшем релизе кода вплоть до продакшен-систем.

«Google и Facebook в итоге могут внедрять сотни изменений системы в день именно потому, что у них этот пайплайн выстроен таким образом, что нигде нет препятствий – если все этапы пути автоматически пройдены, код оказывается в промышленной среде через сутки после того, как продуктовая идея была разработана и оттестирована», – говорит Алексей Чубенко.

Как это происходит в Промсвязьбанке

«Почему мы к этому пришли? – объясняет Алгирдас Шакманас. – Потому что в классической модели каскадной разработки каждая команда отвечает за свой этап, процесс превращается в череду бесконечных согласований и время вывода на рынок никак нельзя сократить. Треугольник скорость – ресурсы – качество постоянно плывет. Заказчик начинает щупать решение, только когда начинается процесс тестирования, и часто выясняется, что это совсем не то, что он ожидал».

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

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

Алексей Чубенко (у флипчарта) и одна из первых agile-команд ПСБ. Фото: Арсений Несходимов для Republic

«Мы стремимся к тому, чтобы выпускать релизы в магазины приложений каждые две недели, но для этого нам нужно будет, например, увеличить процент покрытия автоматическими тестами функциональности нашего приложения. Как правило, мы готовы какую-то фичу сделать за две недели, но не всегда мы готовы ее успешно протестировать, это требует дополнительного времени. Но по крайней мере месячный цикл мы сейчас точно соблюдаем», – говорит Чубенко.

Итоговая задача – провести трансформацию цифрового бизнеса банка в модель гибкой разработки продуктов. Конечно, это затронет и IT-подразделение, поэтому вместе с руководителем IT-направления Промсвязьбанка Андреем Овсянниковым и командой ООО ИЦБТ (главным разработчиком банковского ПО Промсвязьбанка) принимаются решения, какие изменения в этих инструментах, технологиях, подходах к разработке необходимо сделать в организации, чтобы достичь принципов гибкости.

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

Вместо этого в банке пошли по гибкому пути даже в трансформации. «Мы не говорим, что Промсвязьбанк через год должен стать гибким, – мы говорим, что у нас есть возможность и желание создать все условия для того, чтобы весь банк увидел на практике, что Agile действительно приносит результат – сокращает время вывода продукта на рынок и повышает качество пользовательского опыта. Для этого мы запускаем пилотные команды», – рассказывает Шакманас.

Для пилотов в ПСБ выбрали требующие наиболее быстрых изменений продукты, которые будут разрабатываться двумя пилотными agile-командами. Это продукты в цифровом бизнесе, в среднем и малом бизнесе. В цифровом блоке выделены транзакционные функции приложения и интернет-банка, которыми клиент пользуется каждый день, – платежи и переводы. Здесь в банке видят явные точки роста – необходимость увеличить количество поставщиков, упростить процедуры оплаты, сделать функции гибкого поиска, применить новые подходы в юзабилити, вывести новые функции. Платить станет удобнее, проще и выгоднее.

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

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

Соответственно банк будет менять процессы, регламенты, смотреть, где возможны усовершенствования, где необходимо применить новые технологии или техники. «Таким образом, на этапе пилота, который мы планируем провести за три месяца, нам удастся изменить существующие в банке процессы и создать почву для запуска следующих команд по этому пути. И постепенно, такими точечными изменениями, мы сможем изменить существующие процедуры работы в банке», – уверен Шакманас.

«Мы не утверждаем, что все в банке будут работать по Agile. Мы понимаем, что у такого процесса работы есть свои преимущества, которые лучшим образом проявляются на фазе роста продукта. Но, может быть, не стоит их необдуманно применять для всех стадий продуктового цикла в банке – заставлять работать по Agile подразделения, отвечающие за соответствие наших процессов требованиям регулятора или сопровождение АБС», – добавляет Чубенко.

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

Это принесло свои результаты – приложение для iOS было разработано за короткий срок, буквально за три месяца. Оно было выпущено в App Store в мае этого года. «Надо сказать, что мы были готовы к тому, что первая версия соберет большое количество отзывов, – может быть, даже негативных. Команда могла за короткий период вносить изменения, и как раз благодаря этому мы достаточно быстро смогли погасить негатив, возникший из-за того, что мы совершили такой неплавный переход. В частности, мы существенно повысили безопасность, но при этом для входа в приложение нужно было заново ввести логин и пароль. Как оказалось, многие клиенты их банально забыли. Мы быстро улучшили форму ввода пароля и уже через неделю выкатили изменение, которое позволило снять эту проблему», – рассказывает Алексей Чубенко.

Версия для Android была выпущена совсем недавно. Сравнив новые версии мобильных приложений для Android и iOS со старыми приложениями, можно заметить, что банк перешел на нативные технологии разработки. Ранее использовалась технология, формирующая одинаковое приложение для обеих мобильных систем, что было удобно с точки зрения разработки, но не всегда позволяло удовлетворить пожелание пользователей к интерфейсу. Теперь клиенты могут естественным образом использовать паттерны, заложенные в операционной системе мобильного телефона.

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

«Как раз исходя из необходимости внедрения таких изменений и принималось решение о переносе компетенции по разработке в банк. Мы понимали, что разработка мобильного приложения – это основная банковская деятельность, это то, что нам позволит стать лидерами на рынке мобильных приложений», – говорит Шакманас.

Сейчас в бета-версии мобильного приложения банк тестирует чат-бота. Планы по его развитию включают в себя возможность не только вести диалог с пользователем, но и выполнять его команды, отданные человеческим языком, – например: «Заплати за мой телефон 500 рублей». «У нас нет цели создания нового мессенджера, у нас есть цель улучшения взаимодействия с клиентом в разных каналах. То есть чат-бот – это платформа, и каналы к нему могут быть разными – начиная от SMS и заканчивая наиболее известными мессенджерами – Telegram, WhatsApp и т.д.», – поясняет Чубенко.

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

Фото: Арсений Несходимов для Republic