Сад Монолитных Обломков: Как Psb Перешёл На Scrum

Мы не внедряли Scrum ради Scrum — мы хотели предоставить клиентам онлайн-доступ к продуктам и услугам банка и использовать обычный проектный подход, а не кросс-функциональные команды.

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

Я, Константин Ахметов, руководитель отдела развития технологий розничного кредитования Промсвязьбанка, расскажу, почему мы решили использовать Scrum-фреймворк для цифровизации продуктов банка.

О необходимости

Некоторые считают, что изменения в разработке начинаются с прочтения Scrum Guide. Для нас все началось из-за KPI. У Промсвязьбанка есть интернет-банкинг с онлайн-заявками на получение кредита.

Несмотря на то, что оформление кредита онлайн проще и удобнее, чем посещение офиса банка, процент таких кредитов был невысок.

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

Точнее, мы знали, что онлайн-версия приложения представляет собой однозначную копию офисной версии, заполненную сотрудником на месте, и не учитывает современные тенденции и опыт современных пользователей.

Да, теоретически можно было бы быстро сделать хороший продукт за один подход — это идеальный вариант для бизнеса.

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

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

Бизнес не хотел слепо распределять ресурсы («вот твоя задача, сделай»).

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

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

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

В результате, скорее всего, классический проектный подход для данной задачи не подходит. И на это есть две причины:

Потребность в онлайн-услугах будет всегда, и она развивается вместе с банковскими продуктами и услугами.
А это уже противоречит классическому проекту, у которого обязательно есть конечная дата – дедлайн.
У нас не было срока.
Особенно важно развитие продаж и обслуживания клиентов.
У банка может быть много продуктов (какими бы консервативными они ни были), но если у клиентов нет к ним доступа, они их не купят. А удобные сервисы – это способ привлечь новых клиентов, которым можно продавать продукцию.
Мы понимали, что просто создавая интерфейс для сложного банковского бэкенда (то есть раскрывая нашу CRM), мы не получим хорошего результата, потому что форма заявки в нашей CRM такова, что для ее заполнения нужен специально обученный оператор.
.
Нам нужно было переучить нашего клиента: через MVP, через эксперименты, через общение с ним на местах, гугл-формы, анкеты, исследования поведения пользователей на сайте.
Это не похоже на классический проект, где определены требования.
изначально.

Сад монолитных обломков: как PSB перешёл на Scrum

По модели Кеневин (Cynefin), наша задача лежит в области комплексной предметной области – там, где классический менеджмент проектов не работает. Почему заявка на получение кредита является сложной областью? Сервисы, которые используются при создании/обработке анкеты: авторизация, уведомления, подготовка данных для системы принятия решений (запрос данных в БКИ, ФССП и т.д.), история обращений клиентов, система принятия решений, каталог продукции, отчетность о рисках, пластиковые карты, страхование и т.д. Вы могли бы написать книгу только об авторизации.

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

Возникает ряд вопросов: технических (заводить ли учетную запись для каждого заполняющего заявку, как отправить заявку, какую нагрузку мы получим вообще на базу данных и на службу уведомлений (номер телефона подтверждается по СМС) ), как защититься от DDoS-атак, предоставляя API для неавторизованных пользователей), и юридические (можно ли обратиться в кредитное бюро с полным именем/паспортом неавторизованного клиента и как вообще обрабатывать персональные данные).

Мы еще не знаем, куда нас приведет Scrum. В настоящее время наш продукт представляет собой веб-приложение и мобильное приложение.

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

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

О команде

Скрам невозможен без правильной команды: независимой структуры внутри организации, которая была бы автономной и сама собирала требования, сама их анализировала и затем поддерживала решение в производстве.

Как было до смены парадигмы: метод разработки — классический «водопад», когда бизнес-аналитик создал запрос на разработку, разработчик и системный аналитик оценили запрос, системный аналитик написал техническое задание, разработчик реализовал техническое задание.

спецификации, если запрос имел достаточный приоритет. Здесь понятие команды было весьма условным.

Были случаи, когда между этапами формирования требований, написания ТЗ и разработки могло пройти много времени и в результате коммуникация между участниками доработки была практически нулевой (над этим работал аналитик, написавший ТЗ).

другая задача на долгое время, и разработчик, получивший ТЗ через два месяца после ее написания, задает аналитику вопросы о том, что он написал в прошлой жизни).

Раньше понятие команды было размытым — существовал просто пул ресурсов, выполняющих прилетевшие сверху задачи.

Не было вообще команд по созданию собственных продуктов, за которые они бы отвечали.

За результат отвечали конкретные исполнители.

Теперь у нас есть команда, работающая в направлении, указанном владельцем продукта, при этом периодически получаем обратные звонки от команды разработчиков.

Все это происходит под контролем Scrum Master — я считаю, что мы очень строго следуем Scrum Guide. Наша Scrum-команда: Владелец продукта, Scrum-мастер и команда разработчиков, которая состоит из 1-2 бэкенд-разработчиков, 1-3 фронтенд-разработчиков, 1-2 аналитиков, 1-2 тестировщиков и дизайнера.

Как правило, общее количество составляет менее девяти человек.

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

Да, если прийти к разработчику, проработавшему в уютной проектной среде 15 лет, и сказать: «Добби, ты свободен, делай продукт так, как считаешь нужным», то разработчик не всегда будет доволен.

Будет сопротивление и мечты вернуться к уютной проектной деятельности, а ваша попытка интегрировать Scrum закончится саботажем.

Поэтому мы начали нашу трансформацию с команд и их подготовки.

Основываясь на классическом Scrum и его ценностях, мы рассказали командам, что с ними будет и для чего все это нужно.

Такая подготовка необходима, чтобы не вызвать сопротивления еще до первого MVP. Были и трудности.

Сокращений не было, но были разработчики, продуктивность которых снизилась после перевода в Scrum-команду, и их пришлось возвращать обратно в «водопад».

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

Второй ингредиент успешной трансформации команды — опытные Scrum-мастера.

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

Но мастер следит за тем, чтобы взаимодействие в команде соответствовало ценностям Scrum, что, на мой взгляд, самое сложное в его работе.

Как можно заметить недостаточную открытость члена команды или заметить, что разработчика что-то беспокоит, но он стесняется об этом сказать? В первые месяцы внедрения Scrum многие разработчики не воспринимали Scrum Masters всерьез.

Раньше я наблюдал, как Scrum Master подходил к разработчику из моего отдела, сидящему за компьютером в наушниках, просил его снять их и вызывал на Daily Scrum Meeting, затем выслушивал оправдания разработчика, объяснял важность ежедневного событие и что команда должна встретиться всего 15 минут. Он не отходил от разработчика, пока тот не встал и не пошел на встречу.

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

Когда есть обратная связь, об этом можно говорить и обсуждать, но когда команда приходит к ежедневному/планированию и просто молчит, то, на мой взгляд, это самое сложное для Скрам-мастера.

Я смотрел ежедневку, когда все участники молчали.

Особенно в начале пандемии, когда все начали работать удаленно: люди собирались в Zoom, у всех отключали микрофон/видео, и получается, что смысла во встрече не было, как и прогресса.

Такие случаи возникали редко и, по моим наблюдениям, только в новых командах, не обученных Scrum. Если на такой встрече присутствует Скрам-мастер (или член команды, который понимает, зачем нужен ежедневник), он быстро оживит встречу, напомнив ему, о чем нужно поговорить.

О контурах развития

Знаменитый треугольник «быстро – дешево – качественно», выберите два из трех:

Сад монолитных обломков: как PSB перешёл на Scrum

Он хорошо отражает архитектуру решений, встраивающих DEV в инфраструктуру компании.

Если компания не хочет слишком много тратить на ИТ, то она делает упор на «дешево и быстро» — и в ландшафте будут доминировать монолиты на простой инфраструктуре (например, три общих контура: разработка, тестирование, производство).

Сосуществовать в таком монолитном ландшафте разработки продуктов и Scrum — непростая задача.

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

Поэтому сейчас мы больше внимания уделяем «быстро и качественно».

Это стало дополнительным толчком к переосмыслению дизайна ИТ-ландшафта, освоению микросервисной архитектуры и развитию DevOps. У команд появилась независимость в принятии решений, свой личный DevOps, свой CI/CD, пирамиды тестирования и возможность выпускать продукт каждый день, что было недостижимо в условиях сложно связанных банковских монолитов.

Со стороны может показаться, что вносить подобные изменения в ключевые компоненты БИС, ту же CRM, или доступ к СУБД, или процессинг — рискованно.

Но спешу вас успокоить: команды оказались кросс-функциональными, поэтому изменения легко могут коснуться всех компонентов системы (не только фронтенда).

Естественно, все изменения проходят рассмотрение, утверждение и автоматическую проверку службой информационной безопасности банка.

В каждой команде есть свой DevOps-инженер, в каждой команде свои инструменты и правила поставки продукта, в отличие от классической модели, где есть DevOps-отдел и есть единые правила и единый подход к разработке.

Scrum для нас — это автономные мини-офисы внутри крупной компании, разделенные по потребностям клиента.

Да, в этом есть некоторая избыточность — Скрам требовал увеличения штата на 30%, но скажу слова капитана: раз он позволяет быстро и без потери качества выводить на рынок новые фичи и решать проблемы клиентов, то это стоит того.

О клиенте

Кстати, о клиенте.

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

Скрам-команда разделила анкету на две части и выложила ее в Интернет. Теперь клиент может со своего телефона заполнить несколько основных параметров о себе и желаемом кредите, а все остальное добавляется только после предварительного одобрения.

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

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

Сад монолитных обломков: как PSB перешёл на Scrum

В результате клиенты получают красивый лендинг и простой способ взять кредит, а банк – новых клиентов, увеличение объемов выданных кредитов, улучшение своих внутренних процессов и понимание, что делать дальше.