Выпуск новой версии приложения – это значит, что прошлая безнадежно устарела? И на что обратить внимание, если задумались о смене приложения? Мы в Clevertec год за годом разрабатываем и модернизируем мобильные банки. Я – Алексей, был вовлечён в этот процесс сначала со стороны банка, а теперь со стороны компании-разработчика. Дополнить видение проблем бизнеса технологическими аспектами мне помог Кирилл @KirylEr – опытный android-разработчик. Итак, вот что обычно стоит за решением полностью изменить привычный облик приложения.

Приложение устарело. Что это значит?

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

Дело в трендах дизайна, которые меняются примерно раз в год. Но несовременное – не значит плохо работающее. Если вопрос только в том, чтобы “перекрасить кнопки”, то разговор о разработке нового приложения можно не начинать. Здесь поможет внешний рестайлинг.

В мобильных банках со стороны бизнеса и разработки всё выглядит иначе.

Мобильное приложение само по себе не несёт ценности. Ценность – это продукт или услуга, которую пользователи получают с его помощью.

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

Как бизнес принимает решение о смене приложения

Это финансовый вопрос, так почему бы не подбить экономику? В этом случае расчёты не имеют большого смысла, потому что разработать новое мобильное приложение в 95% случаев будет дороже, чем изменить старое. Но выйти на рынок с одним новым продуктом внутри мобильного банка и представить абсолютно новую стратегию: digital-банк, суперапп – это совершенно разные по масштабу вещи. Рассчитать стоимость команды разработки можно. Измерить стоимость технологического лидерства на рынке – нереально.

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

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

На старте проработки таких решений всегда рассматривают 3 варианта:

1. внедрение в текущем мобильном приложении;

2. смена мобильного приложения;

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

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

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

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

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

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

Что ещё может быть не так с кодом?

Накопился техдолг

Если менеджмент ошибся с расчетом сроков и все время подгонял разработку, то уже через полгода всё приложение может стать сплошным техдолгом. Пример очень плохого сценария: “Мы за неделю сделали то, что нужно было за месяц. Надо бы переделать нормально”.

Кардинально изменилась технология

И такое случается. Например, Google вводит Kotlin как основной язык программирования для Android. Да, можно переписать код с Java на Kotlin. Но из-за новых возможностей, которые даёт Kotlin, лучше переписать полностью и продолжить работу на новом стеке.

Сменилась команда разработчиков 

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

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

Как построить команду, которая исправит старое или сделает новое хорошо

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

В разработке банковских приложений участвуют от 3 до 10, а иногда и больше команд. Это инхаус-специалисты и представители разных вендоров. Задача – скоординировать их работу так, чтобы не было разрывов в производстве.

Бэкенд

Ситуация: Изменения скорее всего затронут core-систему банка, учетные системы, карточный процессинг, CRM, BPM и другое. Обычно в банке уже есть своя команда, которая эти системы сопровождает и работает над их развитием.

Что делать?

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

Мидл и фронт

Ситуация: Интеграционный слой и работу над “внешним видом” приложения чаще отдают в разработку вендорам. Чем больше команд участвует, тем сложнее управлять проектом и поддерживать эффективность. 

Что делать?

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

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

В идеальном варианте интеграции и фронтенд берет на себя одна команда. Если это невозможно, то особое внимание – на следующий пункт.

Управление ожиданиями бизнеса и ИТ-команды

Ситуация: Бизнес всегда в первую очередь спрашивает о сроках. Для разработки это бывает больно. Команды могут рассинхронизироваться: например, мидл работает быстро, но ему не вовремя поставляют доработки со стороны бэкенд-систем. В итоге – разрыв в производстве и срывы дедлайнов.

Что делать?

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

С одной стороны он дает спокойствие и понимание бизнесу: что, в какие сроки и за какой бюджет будет реализовано. 

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

На мой взгляд, этот человек – product owner. В компаниях его роль видят по-разному. Идеально, если она объединяет бизнес-видение и верхнеуровневое понимание ИТ-составляющей.

Когда есть взаимопонимание со стороны бизнеса и ИТ, то проект с большой долей вероятности будет успешен.

Саммари: что делать, если появились мысли о новом приложении:

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

2. Обратить внимание на текущее состояние кода. Проблемы с ним могут утвердить в необходимости нового приложения.

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

Эта статья основана на нашем опыте, и наверняка она не исчерпывающая. Если хотите задать вопросы или поделиться мнением – жду вас в комментариях.

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