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

Привет! Я Дмитрий Наранович — руководитель Департамента цифровых сервисов и каналов «Уралсиба» или же CDO, кому как проще. Ровно два года назад наша команда приступила к перезапуску цифровых каналов уже на новых процессах, с новыми принципами и более амбициозными целями.

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

Когда я только возглавил команду, то сразу заметил стагнацию пользовательской базы онлайн-банка и отсутствие развития в части сайта uralsib.ru. Мы банально не успевали за рынком по причине большого time-to-market — это время от начала разработки идеи до вывода готового продукта на рынок. У нас было всего 3-4 полноценных релиза в год, и мы практически не отвечали клиентским запросам. Поэтому, в первую очередь, мы решили сократить time-to-market до трёх недель — фактически это в 5 раз быстрее.

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

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

Всё это мешало, поэтому новая команда начала переделывать процессы и находить альтернативные способы взаимодействия. Однако те, кто работал в банке до прихода нашей команды, тяжело воспринимали изменения: к примеру, очень сложно давался процесс ухода от нарядов к работе в Jira. Адаптацию выдержали не все: остались только продакт, системный аналитик и разработчик, которых пришлось, фактически, переучивать для соответствия новым стандартам и практикам.

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

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

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

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

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

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

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

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

Ещё одна особенность: у нас всё покрыто автотестами. Именно они позволяют, регулярно проверять весь функционал и находить основные проблемы еще до попадания в master. Тесты гоняются круглосуточно — за счёт этого мы сократили время регресса нашего онлайн-банка и сайта с классических 5-7 дней, как у многих, до нескольких часов. За это время мы можем проверить функциональность всего онлайн-банка как минимум на верхнем уровне и во всех точках взаимодействия.

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

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

Сейчас после каждого изменения кода мы можем провести полное тестирование, не останавливаясь в дальнейшей разработке. Что это нам дало? Принцип CI/CD, или процесс бесконечной разработки, помог достичь желаемого результата по time-to-market: мы реально выпускаем релиз с настоящим бизнес-функционалом каждые три недели. К примеру, недавно у нас вышла цифровая карта, новая версия чата в iOS, мы внедрили новые принципы работы с QR-кодом и на 30% повысили его распознавание. Внедрили гибкую дизайн-систему для различных сервисов, но с централизованным управлением, что также сильно влияет на скорость разработки

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

Мы не распылялись при перезапуске онлайн-банка, разработали чёткий план и знали, чего хотим — всё это отразилось на расходах. С перестройкой сайта отдельная история: это первый случай в Уралсибе, когда такое крупное изменение мы сделали вне проектной деятельности, то есть об изменениях никому не говорили. Таким образом, мы доказали, что обычным регулярным процессом можно сделать большие вещи.

Также у нас была очень жёсткая стратегия, в которой мы указали сколько ресурсов надо для разработки, какие это будут ресурсы, требования к «железу». Так, мы не переиспользовали бюджет, а уложились на 99%. Цифры были большие, но контролируемые.

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

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

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

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

#уралсиб