Мы не внедряли Sсrum ради Scrum’а — мы хотели дать клиентам онлайн-доступ к продуктам и сервисам банка и использовать обычный проектный подход, а не кросс-функциональные команды. Но у этой задачи была особенность, которая вынудила нас прийти к гибкой методологии.
Я, Константин Ахметов, начальник отдела разработки розничных кредитных технологий ПСБ, и я расскажу, почему мы решили использовать фреймворк Scrum для цифровизации продуктов банка.
Про потребность
Кто-то считает, что изменения в разработке начинаются с чтения Scrum Guide. У нас всё началось из-за KPI. У ПСБ есть интернет-банкинг с онлайн-заявками на кредит. Несмотря на то, что онлайн-оформление кредита проще и удобнее, чем поход в офис банка, процент выдачи таких кредитов был низкий. Мы понимали, что где-то в логике получения банковского продукта были проблемы, но наши попытки, как разработчиков, повлиять на ситуацию и доработать продукт при классическом «водопаде» разработки положение дел не меняли. Точнее, мы знали, что онлайн-версия заявки повторяла один в один офисный вариант, заполняемый сотрудником на месте, и не учитывала современные тенденции и опыт современных пользователей.
Да, в теории можно было бы за один подход и быстро сделать хороший продукт - это идеальный вариант для бизнеса. Проблема в том, что так разрабатывать сложные продукты не получается: мы постоянно сталкиваемся с обновляющимися требованиями пользователей, а разработка «запряжена» в эволюционирующие прямо по пути технологии.
Мы решили создать команду, которая должна была сфокусироваться на “цифре” и работать на этом направлении в долгую, решая задачи повышения конверсии кредитных заявок и корректируя свою работу по ходу дела. Бизнес не хотел слепо выделять ресурсы («вот вам задача — делайте»). Нужно было, чтобы разработка была прозрачной: бизнес, в нашем случае банк, хочет видеть, за что разработчики получают зарплату, поэтому нужен регулярный фидбэк.
Также хотелось, чтобы риск разработать что-то ненужное был минимальным: за две недели (размер спринта) трудно создать что-то объёмное и при этом ненужное, что сразу же полетит в корзину. И методология должна быть общеизвестной, чтобы все причастные быстро влились в процесс.
В итоге, скорее всего, классический проектный подход для этой задачи не годится. И тому есть две причины:
Потребность в онлайн-услугах и сервисах будет всегда, и она эволюционирует вместе с банковскими продуктами и сервисами. А это уже противоречит классическому проекту, у которого обязательно есть финальная дата — дедлайн. У нас дедлайна не было. Особенно важна эволюция сервисов продаж и клиентских сервисов. У банка может быть много продуктов (неважно, насколько они консервативны), но если у клиентов к ним нет доступа, их не будут приобретать. А удобные сервисы — это способ привлечь новых клиентов, которым можно продать продукты.
Мы понимали, что, просто создав интерфейс сложного банковского бэкенда (то есть выставив наружу нашу CRM), мы не получим хорошего результата, ведь форма заявок в нашей CRM такова, что для её заполнения нужен специально обученный операционист. Нам нужно было заново изучить нашего клиента: через MVP, через эксперименты, через коммуникацию с ним на местах, гугл-формы, опросники, исследования поведения пользователя на сайте... Это не похоже на классический проект, где требования определены изначально.
Согласно модели Кеневин (Cynefin), наша задача лежит в области комплексного домена — там, где не работает классический менеджмент проектов
Почему кредитная анкета — это комплексный домен? Сервисы, которые используются при создании/обработке анкеты: авторизация, уведомления, подготовка данных для системы принятия решений (запрос данных в БКИ, ФССП, и др.), история по заявкам клиента, система принятия решений, продуктовый каталог, рисковая отчётность, пластиковые карты, страховки и др.
Об одной только авторизации можно книгу написать. Например, есть реализованные кейсы, когда клиент приходит из неавторизованной зоны, — то есть в банк с паспортом он ещё не ходил, и всё, что мы о нём достоверно знаем, это только его номер телефона. Возникает ряд вопросов: как технических (создавать ли аккаунт для всех заполняющих заявку, как отправить заявку, какую нагрузку мы получим в целом на базу данных и на сервис уведомлений (телефон подтверждается СМС), как защититься от DDoS-атак, предоставляя API для неавторизованных пользователей), так и юридических (можем ли мы обратиться в бюро кредитных историй с ФИО/паспортом неавторизованного клиента и как в целом обрабатывать персональные данные).
Куда нас приведёт Scrum, мы ещё не знаем. Сейчас наш продукт — это веб и мобильное приложение. А завтра, быть может, начнём, как другие банки, выпускать лампочки — всё ради желаний нашего клиента, который и является индикатором эффективности работы и правильности выбора методологии.
Кажется, что звучит бредово, но в этом и есть смысл гибких методологий: результат как бы не определён, и мы через изучение потребностей клиента делаем ему то, за что он будет платить.
Про команду
Scrum невозможен без правильной команды: самостоятельной структуры внутри организации, которая была бы автономна и сама собирала требования, сама их анализировала и потом поддерживала решение в продакшене.
Как у нас было до смены парадигмы: метод разработки — классический «водопад», когда бизнес-аналитик создавал заявку на разработку, разработчик и системный аналитик оценивали заявку, системный аналитик писал ТЗ, разработчик реализовывал ТЗ, если заявка была достаточно приоритетна. Здесь понятие команды было весьма условно. Были кейсы, когда между этапами формирования требований, написания ТЗ и разработки могло пройти очень много времени и, как следствие, коммуникация между участниками доработки была практически нулевая (аналитик, написавший ТЗ, уже давно работает над другой задачей, а разработчик, к которому пришло ТЗ через два месяца после его написания, задает аналитику вопросы о чем-то из того, что он писал в прошлой жизни). Раньше понятие команды было размыто — был просто пул ресурсов, который выполнял задачи, прилетевшие сверху. Вообще не существовало команд по созданию их собственных продуктов, за которые они отвечают. За результат отвечали конкретные исполнители.
Теперь же у нас команда, работающая в направлении, которое ей указывает product owner, получая при этом периодический колбэк от команды разработки. Всё это под присмотром Scrum-мастера, — я считаю, что мы весьма строго следуем Scrum-гайду. Наша Scrum-команда: Product Owner, Scrum-мастер и команда разработки, которая состоит из 1–2 бэкенд-разработчиков, 1–3 фронтенд-разработчиков, 1–2 аналитиков, 1–2 тестировщиков и дизайнера. Как правило, суммарно меньше девяти человек. Все участники из разных отделов — например, может быть, что в команде два бэкенд-разработчика из отдела разработки кредитных технологий, один аналитик из отдела кредитной аналитики, один фронт из отдела веб-разработки и т. д. Команды были созданы из людей которые уже работали в банке, плюс нам пришлось привлекать новых.
Да, если прийти к разработчику, который 15 лет работал в уютненькой проектной деятельности, и сказать: «Добби, ты свободен, делай продукт, как считаешь нужным», — то разработчик не всегда обрадуется. Будет сопротивляться и мечтать о возвращении в уютную проектную деятельность, и ваша попытка интегрировать Scrum закончится саботажем.
Поэтому нашу трансформацию мы начали с команд и их обучения. Основываясь на классическом Scrum’е и его ценностях, мы рассказали командам, что с ними будет происходить и для чего это всё. Такая подготовка нужна, чтобы не вызвать сопротивление ещё до первого MVP. Трудности тоже были. Обошлось без увольнений, но были разработчики, производительность которых снижалась после перевода их в Scrum-команду, и их приходилось возвращать обратно в «водопад». Были случаи, когда разработчики саботировали ивенты (не хотели ходить на дейли или PBR), но такие проблемы решались чаще всего тренингами по Scrum’у, так как после них приходит осознание смысла работы в Scrum’е. Например, на тренинге объяснят, что, если тебя слишком часто дёргают без необходимости, то нужно рассказать об этом на ретро, чтобы команда приняла меры и ты мог спокойно работать без лишних коммуникаций.
Второй ингредиент успешной трансформации команды — опытные Scrum-мастера. Многие недооценивают эту роль и назначают на неё бывших DEV, аналитиков и иногда QA. В результате на мероприятиях Scrum’а акцент смещается в сторону технической части решения, а про потребность клиента и ценности Scrum’а забывают. А ведь мастер следит за тем, чтобы взаимодействия в команде шли согласно Scrum-ценностям, что, как мне кажется, самое сложное в его работе. Вот как увидеть недостаточную открытость члена команды или заметить, что разработчика что-то беспокоит, но он стесняется об этом сказать? В первые месяцы внедрения Scrum’а многие разработчики не воспринимали Scrum-мастеров всерьёз. Бывало, я наблюдал, как Scrum-мастер подходил к сидящему за своим компьютером в наушниках разработчику моего отдела, просил их снять и звал его на Daily Scrum Meeting, затем выслушивал отговорки разработчика, объяснял важность ежедневного мероприятия и то, что команда должна собраться всего на 15 минут. Он не отходил от разработчика, пока тот не вставал и не шёл на встречу.
Для всего этого нужно известное самообладание, но, по моему мнению, Scrum-мастеров как раз больше выводит из себя тихий саботаж, чем откровенный колбэк. Когда есть обратная связь, можно об этом поговорить и обсудить, а когда команда приходит на дейли/планирование и просто молчит, то, на мой взгляд, это самое тяжёлое для Scrum-мастера.
Я наблюдал дейли, когда все участники молчали. Особенно во время начала пандемии, когда все начали работать удалённо: собрались люди в Zoom’е, у всех отключены микрофон/видео, и получается, что смысла во встрече нет, как и прогресса. Такие случаи возникали редко и, по моим наблюдениям, только в новых не обученых Scrum’у командах. Если на такой встрече присутствует Scrum-мастер (или член команды, который понимает зачем нужны дейли), то он быстро оживит встречу напомнив о чем нужно поговорить.
Про контуры разработки
Знаменитый треугольник «быстро — дёшево — качественно», выбери два из трёх»:
Он хорошо отражает архитектуру решений, которые строят DEV в инфраструктуре компании. Если компания не хочет слишком много тратить на IT, то делает акцент в сторону «дёшево и быстро» — и в ландшафте будут преобладать монолиты на простой инфраструктуре (например, три общих контура: разработка, тест, прод).
Сосуществование в таком монолитном ландшафте продуктовой разработки и Scrum’а - это сложная задача. Когда несколько команд работают над монолитом одновременно, изменения одной часто будут влиять на другую, приводя к увеличению числа багов и срыву целей спринта, и, в итоге, к срыву поставки инкремента. Поэтому теперь мы больше делаем акцент на «быстро и качественно».
Это было дополнительным импульсом к переосмыслению дизайна IT-ландшафта, освоению микросервисной архитектуры и развитию DevOps.
Команды получили независимость в принятии решений, своего личного DevOps’а, свой CI/CD, пирамиды тестов и возможность релизить продукт хоть каждый день, что в условиях сложно связанных банковских монолитов было недостижимо. Со стороны может показаться, что проводить такие изменения над ключевыми компонентами БИС, той же CRM или доступа к СУБД, или процессинга рискованно. Но спешу вас успокоить: команды получились кросс-функциональными, поэтому изменения могут спокойно касаться всех компонентов системы (не только фронтенда). Естественно, все изменения проходят review, согласования и автоматические проверки службы информационной безопасности банка.
Каждая команда имеет своего DevOps-инженера, у каждой команды есть свои инструменты и правила поставки на прод, в отличие от классической модели, где есть отдел DevOps’а и есть единые правила и единый подход к разработке. Scrum для нас — это автономные мини-офисы внутри большой компании, разделенные по потребностям клиента.
Да, в этом есть некоторая избыточность — Scrum потребовал роста штата на 30%, но скажу капитанские слова: раз это позволяет быстро и без потери качества выводить новые фичи на рынок и решать проблемы клиента, то оно того стоит.
Про клиента
Кстати, о клиенте. Банк переходит на цифру не ради цифровизации, а чтобы соответствовать ожиданиям клиента и предоставлять ему те услуги, которые он хочет. Например, заявку на ипотеку раньше можно было заполнять только в офисе, и при этом менеджер должен был вводить полсотни полей анкеты, даже если большая их часть могла не пригодиться в случае отказа на первом этапе предварительных проверок.
Scrum-команда разделила анкету на две части и вывела ее в онлайн. Теперь клиент может с телефона заполнить несколько основных параметров о себе и желаемом кредите, а всё остальное добавляется только после предварительного одобрения. Менеджеру теперь не нужно вбивать тонны ненужной информации, потому что процент отказа по заявкам вырос, так как ужесточились требования к заёмщикам. А раз менеджер делает меньше ненужной работы, то растёт продуктивность в целом.
В итоге клиенты получают красивый лендинг и легкий способ взять кредит, а банк — новых клиентов, повышение объема выданных кредитов, улучшение своих внутренних процессов и понимание, что делать дальше.
В этой статье я рассказал, как мы внедряем гибкую методологию в свои бизнес-процессы. А какие трансформации процесса разработки были у вас? Буду рад обсудить наш и ваш опыт в комментариях.
