Выпуск новой версии приложения – это значит, что прошлая безнадежно устарела? И на что обратить внимание, если задумались о смене приложения? Мы в Clevertec год за годом разрабатываем и модернизируем мобильные банки. Я – Алексей, был вовлечён в этот процесс сначала со стороны банка, а теперь со стороны компании-разработчика. Дополнить видение проблем бизнеса технологическими аспектами мне помог Кирилл @KirylEr – опытный android-разработчик. Итак, вот что обычно стоит за решением полностью изменить привычный облик приложения.
Приложение устарело. Что это значит?
Для пользователя приложение становится устаревшим из-за визуальных впечатлений. Несовременный дизайн и неудобный интерфейс – это повод сказать, что всё плохо.
Дело в трендах дизайна, которые меняются примерно раз в год. Но несовременное – не значит плохо работающее. Если вопрос только в том, чтобы “перекрасить кнопки”, то разговор о разработке нового приложения можно не начинать. Здесь поможет внешний рестайлинг.
В мобильных банках со стороны бизнеса и разработки всё выглядит иначе.
Мобильное приложение само по себе не несёт ценности. Ценность – это продукт или услуга, которую пользователи получают с его помощью.
Если мы говорим о смене интерфейса, то скорее всего причина в том, что устарели и стали неудобными процессы, заложенные в приложении. В этом случае перемена “внешности” – это новая концепция пользовательского опыта. А значит, приложение нужно построить заново.
Как бизнес принимает решение о смене приложения
Это финансовый вопрос, так почему бы не подбить экономику? В этом случае расчёты не имеют большого смысла, потому что разработать новое мобильное приложение в 95% случаев будет дороже, чем изменить старое. Но выйти на рынок с одним новым продуктом внутри мобильного банка и представить абсолютно новую стратегию: digital-банк, суперапп – это совершенно разные по масштабу вещи. Рассчитать стоимость команды разработки можно. Измерить стоимость технологического лидерства на рынке – нереально.
Основания, на которых компании принимают решения о смене мобильного приложения, можно разделить на две категории: бизнес-цели и технологические причины.
Бизнес-цели обычно связаны с внедрением новой продуктовой линейки, новых процессов, не существующих на рынке, или даже новой бизнес-стратегии.
На старте проработки таких решений всегда рассматривают 3 варианта:
внедрение в текущем мобильном приложении;
смена мобильного приложения;
смена мобильного приложения и бэкенд-платформы, обеспечивающей его работу.
Можно долго описывать плюсы и минусы каждого из подходов, говорить, что всё зависит от объёмов необходимых изменений. Но самые успешные бизнес-проекты, в которых мне доводилось участвовать, реализовались по третьему варианту: с полной заменой мобильного приложения и где-то с полной, а где-то с частичной заменой бэкенд-систем.
Технологические причины – это быстродействие, отказоустойчивость, ограничения возможности работы онлайн и 24/7.
Если в приложении мало изменений, оно долго может жить без глобальных переписываний кода. Время от времени придется поднимать версии библиотек, чтобы попадать в сторы без проблем.
Когда бизнес стремительно меняется, он постоянно реализует новые маркетинговые стратегии, меняет дизайн. В любом случае наступит момент, когда обновление приложения повлечёт настолько большие трудозатраты разработчиков, что поддерживать старую версию уже не целесообразно.
По опыту одного из наших проектов – банковского приложения, для которого мы сделали уже третью абсолютно новую версию, каждая предыдущая жила около 3 лет. Потом из-за изменения концепции и новых технологий становилось проще переписать код, чем исправить.
Что ещё может быть не так с кодом?
Накопился техдолг
Если менеджмент ошибся с расчетом сроков и все время подгонял разработку, то уже через полгода всё приложение может стать сплошным техдолгом. Пример очень плохого сценария: “Мы за неделю сделали то, что нужно было за месяц. Надо бы переделать нормально”.
Кардинально изменилась технология
И такое случается. Например, Google вводит Kotlin как основной язык программирования для Android. Да, можно переписать код с Java на Kotlin. Но из-за новых возможностей, которые даёт Kotlin, лучше переписать полностью и продолжить работу на новом стеке.
Сменилась команда разработчиков
Даже стабильные команды с годами обновляются. Молодые ребята хотят работать с новыми технологиями. Справедливые аргументы – быстродействие, новые фишки, которые нельзя сделать старыми инструментами.
Другой пример – на проект завели новую команду, а старая оставила всё в беспорядке и плохой документацией. Разбираться в чужом коде, пытаться понять, почему это сделано именно так, будет гораздо сложнее и дольше, чем написать заново.
Как построить команду, которая исправит старое или сделает новое хорошо
Итак, глобальной перестройке приложения быть. Главное здесь – это понимание, что большие перемены не делаются в одиночку.
В разработке банковских приложений участвуют от 3 до 10, а иногда и больше команд. Это инхаус-специалисты и представители разных вендоров. Задача – скоординировать их работу так, чтобы не было разрывов в производстве.
Бэкенд
Ситуация: Изменения скорее всего затронут core-систему банка, учетные системы, карточный процессинг, CRM, BPM и другое. Обычно в банке уже есть своя команда, которая эти системы сопровождает и работает над их развитием.
Что делать?
Заранее позаботиться, чтобы эти специалисты были доступны для совместной работы над новым приложением не от случая к случаю, а в нужное время и в нужном объёме.
Мидл и фронт
Ситуация: Интеграционный слой и работу над “внешним видом” приложения чаще отдают в разработку вендорам. Чем больше команд участвует, тем сложнее управлять проектом и поддерживать эффективность.
Что делать?
Кроме системного анализа, проектирования архитектуры и разработки приложения всегда есть этапы бизнес-аналитики, дизайна и проектирования пользовательского опыта. Здесь появляется риск разрыва между ожиданиями и реальностью: впечатляющая концепция UX часто выливается в годы разработки. Так быть не должно.
Если один вендор имеет обширную экспертизу и может взять на себя ответственность за реализацию под ключ: разработать концепцию, отрисовать ее в прототипе мобильного приложения, спроектировать технически и в результате реализовать, то заказчику проще управлять результатом.
В идеальном варианте интеграции и фронтенд берет на себя одна команда. Если это невозможно, то особое внимание – на следующий пункт.
Управление ожиданиями бизнеса и ИТ-команды
Ситуация: Бизнес всегда в первую очередь спрашивает о сроках. Для разработки это бывает больно. Команды могут рассинхронизироваться: например, мидл работает быстро, но ему не вовремя поставляют доработки со стороны бэкенд-систем. В итоге – разрыв в производстве и срывы дедлайнов.
Что делать?
Со старта должен быть человек, который отвечает в целом за проект и его реализацию: от проектирования до внедрения. Он может составить мастер-план разработки по всем этапам, системам и уровням, организовать работу команд таким образом, чтобы учесть все зависимости.
С одной стороны он дает спокойствие и понимание бизнесу: что, в какие сроки и за какой бюджет будет реализовано.
С другой стороны он понимает все о технических командах: кто, что и в какие сроки должен сделать, чтобы проект взлетел, и дать им конкретное понимание об этом.
На мой взгляд, этот человек – product owner. В компаниях его роль видят по-разному. Идеально, если она объединяет бизнес-видение и верхнеуровневое понимание ИТ-составляющей.
Когда есть взаимопонимание со стороны бизнеса и ИТ, то проект с большой долей вероятности будет успешен.
Саммари: что делать, если появились мысли о новом приложении:
Определиться с целью. Новое приложение не нужно, если старое хорошо работает и вы не планируете реализовать абсолютно новую бизнес-стратегию. Чтобы освежить впечатления пользователей, хватит редизайна. Но достичь новых бизнес-результатов без глобальных перемен не получится.
Обратить внимание на текущее состояние кода. Проблемы с ним могут утвердить в необходимости нового приложения.
Планируя большие перемены, заранее позаботиться об эффективном взаимодействии команд разработки, наладить качественную коммуникацию и процессы взаимодействия между бизнесом и ИТ-командой.
Эта статья основана на нашем опыте, и наверняка она не исчерпывающая. Если хотите задать вопросы или поделиться мнением – жду вас в комментариях.
Кстати, в следующей статье хотим рассказать, как компании решают главную боль нового приложения: переводят клиентов из старого приложения в новую версию. Интересно будет прочесть?
