Что учесть при разработке мобильного приложения

Самое страшное, что может случиться с мобильным приложением — если им не будут пользоваться. К такому сценарию может привести целый ряд ошибок на каждом этапе работы. О том, что требует особого внимания при создании мобильного приложения, рассказал Юрий Мейталов, руководитель ИТ-отдела британской финтех-платформы Bilderlings.

Бывает, руководство хочет «как у конкурентов», забывая, что вашим клиентам нужно что-то другое. Или задача ставится исходя из личных вкусов менеджера: в итоге ему нравится, а клиенту неудобно. Поэтому первым шагом должен быть user research, изучение конкретных потребностей клиентов. И только на основании этого исследования уже можно писать техзадание.

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

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

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

Вот есть китайский WeChat — это одно приложение для всего сразу. Оно настолько перегружено, что попробуй найди нужную опцию. Другая крайность — под каждую задачу делать отдельное приложение от одного поставщика услуг. Например, если я хочу использовать банк «Икс» и как юрлицо, и как частное, то мне нужно скачивать несколько приложений. По-хорошему, надо искать баланс между двумя крайностями.

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

Мобильное приложение должно позволять делать основные вещи. Попытка внедрить туда всё усложняет навигацию. А в мобильном приложении невозможно сделать навигацию так же, как в вебе. Поэтому надо точно знать, что именно нужно клиенту, и делать только это. И это уже задача UX.

Технологии для разработки приложения могут быть кроссплатформенными или нативными. Первый вариант — это когда одна основа сразу для Android и iOS, второй — отдельное приложение для Android, отдельное для iOS. Нативный вариант сильно дороже: и стоимость самой разработки практически удваивается, и дороже будет поддерживать. А если выбирать кроссплатформенные технологии, тот тут вопрос, на чём конкретно их делать — это зависит уже от деталей, задач, самого сервиса. Мы для себя выбрали кроссплатформенный вариант и сравнительно новую технологию, которая появилась только в прошлом году. Поскольку технология новая, то это тоже своего рода риск: мы ещё не знаем, в какой момент мы во что-то упрёмся.

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

Делать самим или отдать на аутсорс — это вопрос ресурсов: надо просто тщательно всё рассчитать. Другое дело — выбрать самого подрядчика.

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

Идеальный вариант, когда есть связь «команда» — «команда». Например, у меня был проект, когда мы созванивались только с проектным менеджером, все вопросы обсуждали только с ним, долго и нудно. А обратной связи от самой команды не было. Получался такой испорченный телефон. Хорошо, когда команды между собой общаются без участия менеджеров.

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

Мы работаем с финансовыми данными и о безопасности думаем уже на стадии разработки. Первым делом мы проводим аудит приложения, чтобы всё было не только на совести разработчиков, но и проверено профессиональными тестировщиками, которые занимаются безопасностью. В приложение должны быть внедрены определённые технологические решения, которые защищают его от вредоносных кодов и утечки данных. Это must have, но именно вы как заказчик должны проверить, насколько ваш продукт надёжен.

Есть гайды — например, OWASP MASVS. Это, по сути, топ уязвимых мест, которые надо учитывать при разработке. Эти уязвимости легко закрываются, но если разработчик об этом не думает, то он может и не закрыть слабые места. Поэтому, во-первых, важно оговаривать всё на старте, во-вторых (доверяй, но проверяй), нужно стороннее тестирование на проникновение (penetration test).

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

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

Мы в итоге сделали два в одном: и демо-доступ, и видео о том, как работает приложение.

Во-первых, надо следить за отзывами, которые оставляют клиенты в App Store и Google Play. Если ничего не отвечать и не менять, то рейтинг приложения будет падать: клиент несчастный, комментарий плохой, впечатление испорчено. Во-вторых, хорошо бы продумать альтернативный канал связи — то есть телефон или кнопка support должны быть в самом приложении, желательно на виду. Если у клиента проблема и он не знает, куда жаловаться, он напишет в отзывах к приложению.

Допустим, у вас сто тысяч клиентов, а скачиваний всего десять. Надо искать проблему. Или скачиваний много, но после этого клиент заходит и сразу же уходит, приложением не пользуется. В чем причина? Надо собирать аналитику поведения пользователей. Сервисов, которые собирают такие данные, много. Проблема в том, чтобы их грамотно проанализировать и сделать правильные выводы. И это тоже момент, который стоит учесть на старте — как минимум, выделить такую задачу и назначить ответственного.

Прочитать материал полностью можно на сайте Rusbase.