Привет, Хабр! Мы уже писали о том, как в ноябре прошлого года затеяли работу над самым крупным обновлением мобильного банка «Открытие» за все время его существования. В этой статье мы расскажем про процессы — про то, как развиваем продукт совместно с Открытие Digital.

От Waterfall к Agile

Два года назад мы вышли в AppStore и Google Play
Тогда в “Открытии” жили по системе waterfall и еще не дробили большие фичи, чтобы вводить их по частям, и первое крупное обновление случилось спустя несколько месяцев после запуска, когда появилась возможность открывать вклады прямо в приложении. Но постепенно длина итераций начала сокращаться, и переход к Agile дал возможность улучшать продукт практически непрерывно.

Один продукт и две команды

Сегодня за большинство диджитал-продуктов банка отвечает специальное подразделение Открытие Digital, а в Redmadrobot — выделенная команда из 10 человек, которая совместно с “Открытием” занимается мобильным приложением банка с момента создания самой первой его версии.


Офис Открытие Digital

Команды “Открытия” и Redmadrobot сидят в разных офисах, но это не мешает супер-плотному взаимодействию по продукту.


Офис Redmadrobot

Антон Подеречин, iOS-разработчик Redmadrobot
“Первые полгода мы регулярно десантировались в офис Открытия Digital, бывало, я работал там по 3-4 дня в неделю. Это было необходимо для плотной синхронизации, плюс безопасность не позволяла получать доступ к некоторым тестовым средам извне. Сейчас обе команды постоянно друг к другу ездят на встречи, но не более”

Некоторое время назад мы перешли на специальный спринт-пульс (расписание работы на каждые 2 недели, в соответствии с которым команда выпускает обновления продукта), который удобен обеим командам — теперь все, кто “поставляет” какие-либо фичи для мобильного приложения, работают в рамках этого спринт-пульса. На старте каждого спринта мы синхронизируемся, проговаривая цели, задачи и то, как именно они будут реализовываться в течение спринта. Синкапы по ходу работ проходят между командами каждую неделю. Спринт может включать как реализацию одной или нескольких новых фич, так и задачи на R&D — будь то смена пинкода карты или анализ доступных на рынке технологий сканирования и распознавания документов. Сейчас обновления приложения в сторе появляются раз в две-три недели.

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

В Redmadrobot развитие продукта — зона ответственности арт-директора, тимлида, аналитика и менеджера проекта, последний проектирует работу команды — планирует загрузку разработчиков, дизайнеров, тестировщиков и отвечает за финансовые показатели.
В команде существует принцип ротации, направленный на то, чтобы все ее участники профессионально развивались — разработчики регулярно переключаются на новые интересные задачи (примерно раз в полгода), дизайнеры вырастают в арт-директоров и включаются в управление продуктом.

Артур Сахаров, технический директор, Redmadrobot (@mc_murphy)
“У нас внутри компании есть правила — регулярные ассессменты, ротация и пр. И мы эту практику не меняем в том числе в продуктовых командах. Да, при ротации происходит частичная потеря эффективности — любому новому человеку нужно время, чтобы освоиться в проекте, но и мы, и “Открытие” понимаем, что таким образом отрабатываются риски — застой грозит потерей ценных специалистов, которые всегда хотят развиваться. Именно под такого типа людей мы в Redmadrobot выстраиваем свою инфраструктуру, которая позволяет насыщать производство разными проектами, технологиями и вокруг них поддерживать движение”

Demo days

Раз в месяц в “Открытии” проходит демо — это четырехчасовое мероприятие, на котором все команды, занимающиеся развитием диджитал-продуктов банка (не только мобильных), в неформальной обстановке рассказывают о своей работе за месяц в формате коротких презентаций. Это и трансляция опыта на все диджитал-команды, и демонстрация продуктов топ-менеджменту. Мы участвуем в демо двумя командами — product owner со стороны “Открытия” рассказывает о показателях работы приложения, а Redmadrobot — о новых фичах.

Данила Березин, администратор проекта, Redmadrobot
“Надо понимать, что на демо нельзя просто сказать, что в течение месяца мы проводили рефакторинг и исправляли баги. Никто “извне” этого не поймет. Таким образом, необходимость презентации на демо всегда была некоторым критерием при определении скоупа спринта и обязательного наличия в нем значимых для пользователя фич”


Команды Открытие Digital и Redmadrobot после демо-дня

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

Roadmap и ревью

Каждый год совместно с Открытие Digital мы перекладываем список бизнес-задач на продуктовую составляющую (то есть смотрим, как “смэпить” требования банка и наше приложение) и затем утверждаем документ — так формируется roadmap мобильного продукта и бизнеса. Раз в квартал команда Redmadrobot делает ревью по всем фичам приложения для того, чтобы приоритизировать и определить, что именно войдет в последующие релизы.


Офис Открытие Digital

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

Масштабное обновление: программа максимум и приоритизация

В середине 2016 года мы решили сделать большой редизайн нашего приложения. За время, прошедшее с запуска первой версии продукта, выросли требования бизнеса и ожидания клиентов, изменились возможности платформы и средства разработки.


Конечно, это “программа максимум”, которую мы и не планировали уместить в первый релиз. Тут наступает момент, когда надо приоритизировать. Перед нами стояла необходимость сохранить всю функциональность приложения, (привет, Капитан Очевидность! — но все помнят эпичный провал с запуском нового “Кинопоиска”), дополнив ее самым приоритетным из списка выше.

Lean-подход и работа в режиме стартапа

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

Григорий Матвиевич ( fountainhead ), руководитель iOS-разработки, Redmadrobot
“Мы сразу запускаем весь функционал, где каждая конкретная функция будет работоспособной, но без изысков. Мы ни в коем случае не можем запустить приложение банка без переводов или без отображения счетов и других вещей, которые де-факто стали стандартом в мобильном банкинге. При этом никто не отменял строгие банковские требования по безопасности, сжатые сроки и ограниченные ресурсы”

В некотором смысле команда, работающая над приложением “Открытия” — это стартап внутри Redmadrobot, где работа над продуктом идет очень быстрым темпом и сопровождается постоянными мозговыми штурмами. Итоговый список функционала в рамках масштабного обновления мы формировали на основе аналитики, а также экспертизы всей команды. Каждый участник core team проанализировал и составил собственный топ сильных и слабых мест приложения. В общем топе фичей оказались:

• Платежи
• Шаблоны
• Перевод по номеру телефона
• Перевод с карты на карту
• Чат
• Лояльность и тарифы по продуктам

Все фичи-кандидаты в релиз прогоняются через три бизнес-фокуса банка:

• Наращивание активной клиентской базы
• Повышение частоты транзакций
• Переход в digital

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

Анастасия Графская, менеджер проектов, “Открытие Digital”
“Важно отдавать себе отчет в том, что идеального состояния продукта не бывает никогда — идеальный сегодня продукт завтра будет другим, и его улучшение достигается за счет постоянных обновлений. Думая о том, как должен развиваться мобильный банк, мы всегда исходим из пользовательских потребностей, которые оно должно закрывать. Решать реальные проблемы клиентов — наш приоритет, и хорошие бизнес-показатели мобильного продукта это всегда производные положительного пользовательского опыта”

Проектирование от потребностей и вовлечение пользователя

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

Артур Сахаров, технический директор, Redmadrobot (@mc_murphy)
“Сделать интродакшн, где все возможности приложения расписаны максимально подробно или вывалить на главный экран абсолютно все функции — не наш метод. То есть мы не решаем задачу привлечь внимание пользователя ко всем функциям приложения сразу. Наша задача иная — вычислять потребность пользователя и контекст, в котором он будет пытаться эту потребность закрыть — и затем помещать функцию именно в этот контекст”

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

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

Итог

За счет объединения технологической и продуктово-банковской экспертизы мы с Открытие Digital достигли синергетического эффекта. Банку не приходится думать об организации и развитии эффективного процесса разработки продукта inhouse. Мы же в Redmadrobot получаем инсайты и экспертизу в финтехе от крупнейшего частного банка России. Мы работаем ради одной общей цели — сделать самый удобный сервис мобильного банкинга на российском рынке. Свести к минимуму количество действий, которые пользователю необходимо делать вручную, переложив эти задачи на ИТ-системы посредством мобильного приложения.

Елисей Захаров, менеджер по маркетингу и развитию мобильных приложений, Открытие Digital
“Клиент банка — центр экосистемы. Каждый из нас находится в финансовом взаимодействии с родными и близкими, государством, работодателем, поставщиками услуг, и чем шире спектр транзакционных активностей пользователя, который покрывает мобильный продукт, тем он круче. Построить такой сервис за один месяц и даже год нельзя, но мы движемся к цели, шаг за шагом. На очереди более плотная интеграция с внешними системами и дальнейшая проработка всего платежного функционала приложения “Открытия”. Ну а совсем скоро — совершенно обновленный Android — stay tuned!”