Как создать топовое банковское приложение: 5 компонентов успеха

Сколько времени нужно, чтобы сделать крутое банковское приложение?
Чтобы это узнать, мы взяли статистику Finextra: на создание полноценного мобильного банка нужно до года. И 5% компаний успевают это сделать за 3 месяца. Нам удалось попасть в эти 5% и сделать топовое банковское приложение.

Обзор мобильного банкинга от компании Finextra.

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

Исходные данные

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

Задача

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

Дополнительные условия

1. Каркас приложения уже есть, поэтому нужно быстро разобраться в существующем коде и переработать архитектуру;
2. Мы начали работу в составе трех команд: одни работали над дизайном, мы — над приложением, третья команда — над серверной частью. Скорость разработки и интеграции приложения зависели от разработчиков сервера;
3. Координация 3 распределенных команд в условиях жестких сроков — верх искусства. Работа идет медленнее, чем могла бы.

Компоненты успешной разработки

Product owner (Владелец продукта)

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

Слаженная команда

• На проект подключилась команда разработчиков, не раз работавших вместе. Такая команда работает быстрее: разработчики легко читают код друг друга, знают сильные и слабые стороны друг друга и в зависимости от этого распределяют задачи. Им не надо тратить время на знакомство и адаптацию;
• Идеально, если одна команда делает клиентскую и серверную части. Мы поначалу делали только клиентскую часть, и нам приходилось ждать сервер. Когда сроки начали поджимать, мы подключились и к бекенду. С этого момента можно было легко уточнять информацию у коллег и быстрее интегрировать готовый функционал;
• Готовность клиента и разработки к расширению команды, если это помогает ускорить разработку.

Ринат и Марина: вместе тимлидят уже третий проект.

iOS и Android вместе

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

ТЗ в Google doc

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

Видео новых функций

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

Например, мы добавили в приложение поиск организаций через сервис dadata. Приложение показывает метки надежности организаций: зеленый - надежный контрагент; желтый - сомнительный; красный - есть риски при работе с контрагентом.

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

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

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