0
0
Доступность технологий создает иллюзию, что их разработка — это легкий и быстрый процесс. Однако любое неверное решение в этом деле может дорого обойтись. О том, что требует особого внимания при создании мобильного приложения, рассказал Юрий Мейталов, руководитель ИТ-отдела британской финтех-платформы Bilderlings.
Чтобы пользовались: что учесть при разработке мобильного приложения
Юрий Мейталов
В проекте Dig(IT)al рассказываем о технологиях, которые помогут вам заработать. Переходите на цифровую сторону бизнеса.
Под руководством Юрия было выпущено несколько банковских приложений, и он уверен: самое страшное, что может случиться с мобильным приложением — если им не будут пользоваться. К такому сценарию может привести целый ряд ошибок на каждом этапе работы.
Постановка задачи
Бывает, руководство хочет «как у конкурентов», забывая, что вашим клиентам нужно что-то другое. Или задача ставится исходя из личных вкусов менеджера: в итоге ему нравится, а клиенту неудобно. Поэтому первым шагом должен быть user research, изучение конкретных потребностей клиентов. И только на основании этого исследования уже можно писать техзадание.
Звучит банально и очевидно, но всё равно каждый раз через это проходишь. Когда постоянно следишь за конкурентами, невольно забываешь, что у вас с ними не симметричная аудитория. Например, у нас было искушение многое сделать «как у других», но наша аудитория — это в первую очередь бизнес, поэтому «фишки масс-маркета» для нас неактуальны.
Если ТЗ написано без анализа, не опираясь на конкретные клиентские нужды, то потом сложно будет найти корень проблемы. Приложением не будут пользоваться, а вам придётся гадать, на какой стороне беда: техническая, айтишная, дизайнерская.
User research — это командная задача, а не только отдела маркетинга. Например, для создания банковского приложения надо изучить бизнес-профиль клиентов, поток транзакций и их типы, инструменты, которыми люди пользуются. Важно не только знать, какие действия совершает клиент, но и понимать, зачем он это делает: с какой целью человек хочет посмотреть баланс, получить выписку, сделать перечисление между своими счетами и так далее. Для этого надо анализировать данные, которые есть в компании, или проводить интервью с клиентами.
В идеале над этим должны работать люди из разных отделов, чтобы видеть сервис целиком и двигаться одновременно в разных направлениях.
Излишняя кастомизация
Мы сделали функциональность одинаковой для всех клиентов, независимо от их профиля. Многие банки кастомизируют приложения. Мы решили, что для нас это будет уже overengineering, или чрезмерное усложнение. К тому же есть риск ошибиться: кому-то станет недоступна какая-то функция, потому что неверно определили нужды клиента.
Вот есть китайский WeChat — это одно приложение для всего сразу. Оно настолько перегружено, что попробуй найди нужную опцию. Другая крайность — под каждую задачу делать отдельное приложение от одного поставщика услуг. Например, если я хочу использовать банк «Икс» и как юрлицо, и как частное, то мне нужно скачивать несколько приложений. По-хорошему, надо искать баланс между двумя крайностями.
Проблемы с функционалом
Выбор, как кастомизировать приложение — это первый этап, где есть риск уйти в избыточность или, наоборот, недостаточность. Следующий — это выбор функционала. Две частые проблемы — у одних урезанное по функционалу приложение, у других, наоборот, слишком много всего. Перегруженность — тоже плохо.
Мобильное приложение должно позволять делать основные вещи. Попытка внедрить туда всё усложняет навигацию. А в мобильном приложении невозможно сделать навигацию так же, как в вебе. Поэтому надо точно знать, что именно нужно клиенту, и делать только это. И это уже задача UX. Даже нам, хотя мы делали всё минималистично, потом пришла обратная связь: что тут сложно, здесь сложно, а тут много функциональности, которая не факт, что нужна, — перемудрили.
Бывают случаи, когда клиент просит о какой-то фиче: «мне нужно, чтобы было так». Делать что-то для двух клиентов из тысячи неправильно. Надо сперва разобраться, насколько это необходимо другим и можно ли эту функциональность как-то ещё развернуть, чтобы ею пользовались. Как правило, приходится выбирать то, что удобнее большинству.
Самое главное для мобильного приложения — чтобы все основные функции были на виду. А если у вас что-то более глубокое, то это можно спрятать так, чтобы человек мог в случае необходимости найти.
Технологии: нативная VS кроссплатформенная
Технологии для разработки приложения могут быть кроссплатформенными или нативными. Первый вариант — это когда одна основа сразу для Android и iOS, второй — отдельное приложение для Android, отдельное для iOS. Нативный вариант сильно дороже: и стоимость самой разработки практически удваивается, и дороже будет поддерживать. А если выбирать кроссплатформенные технологии, тот тут вопрос, на чём конкретно их делать — это зависит уже от деталей, задач, самого сервиса. Мы для себя выбрали кроссплатформенный вариант и сравнительно новую технологию, которая появилась только в прошлом году. Поскольку технология новая, то это тоже своего рода риск: мы ещё не знаем, в какой момент мы во что-то упрёмся.
Выбирая ту или иную технологию, надо думать наперёд и прикидывать, как вы будете развиваться — сможет ли выбранная технология покрыть все нужды, можно ли будет на этой платформе внедрить всё, что захочется.
Идеальный вариант — это хорошо расширяемые технологии, не заточенные под конкретные опции, у которых уже есть какая-то история и которые, предположительно, будут поддерживаться в обозримом будущем.
То, что сегодня кажется простым, завтра может настолько устареть, что некому будет поддерживать эту технологию. Вот появилось что-то новое, и смартфон это поддерживает. А потом выходит новый айфон, и там что-то настолько инновационное, что этим смогут воспользоваться только нативные приложения, а кроссплатформенным придется пару месяцев адаптироваться. И это тоже надо учитывать. Многие новые фреймворки и кроссплатформенные разработки быстро умирают. Поэтому надо следить за тем, как та или иная технология развивается.
Выбор подрядчика или собственная разработка
Делать самим или отдать на аутсорс — это вопрос ресурсов: надо просто тщательно всё рассчитать. Другое дело — выбрать самого подрядчика.
Здесь ты никогда до конца не знаешь, как в итоге пойдёт. Бывает, что и компания классная, и проекты у неё отличные, а вот именно на ваш проект поставят не очень профессиональных разработчиков, и всё затянется. Важна совокупность факторов: профессионализм и опыт компании, профессионализм и опыт конкретных сотрудников и большая работа с твоей стороны, в частности — контроль разработки.
Коммуникация между командами
Идеальный вариант, когда есть связь «команда» — «команда». Например, у меня был проект, когда мы созванивались только с проектным менеджером, все вопросы обсуждали только с ним, долго и нудно. А обратной связи от самой команды не было. Получался такой испорченный телефон. Хорошо, когда команды между собой общаются без участия менеджеров.
Еще один момент для контроля — это анализ затрат и проверка того, совпадают ли оценки с обеих сторон. Кроме того, важно и со своей стороны адекватно оценивать собственную техническую готовность: насколько вы готовы предоставить свою часть (тот же API или какую-то новую функциональность), необходимую для внедрения разработки.
Безопасность
Мы работаем с финансовыми данными и о безопасности думаем уже на стадии разработки. Первым делом мы проводим аудит приложения, чтобы всё было не только на совести разработчиков, но и проверено профессиональными тестировщиками, которые занимаются безопасностью. В приложение должны быть внедрены определённые технологические решения, которые защищают его от вредоносных кодов и утечки данных. Это must have, но именно вы как заказчик должны проверить, насколько ваш продукт надёжен.
Есть гайды — например, OWASP MASVS. Это, по сути, топ уязвимых мест, которые надо учитывать при разработке. Эти уязвимости легко закрываются, но если разработчик об этом не думает, то он может и не закрыть слабые места. Поэтому, во-первых, важно оговаривать всё на старте, во-вторых (доверяй, но проверяй), нужно стороннее тестирование на проникновение (penetration test).
Прохождение ревью
Когда приложение готово, его надо залить в магазин и отправить на ревью, т.е. на проверку. В Android это происходит автоматически, а в iOS вручную: конкретный человек-ревьюер скачивает приложение и проверяет, как оно работает и соответствует ли требованиям iOS. Если видит какие-то нарушения или что-то вызывает сомнения, он отклоняет приложение и отправляет его на доработку. Каждый цикл занимает минимум день. Поэтому, чтобы избежать такого сценария, надо тщательно всё подготовить заранее.
Нужно, чтобы и картинки, и описание соответствовали требованиям. В случае с банковскими приложениями возникает сложность с демо-доступом. Представьте: ревьюер доходит до экрана с логином — и всё. Вы же не будете его заставлять открывать счёт. Он пишет «невозможно проверить функциональность» и отклоняет вашу заявку. И надо либо дать демо-доступ, либо писать ответы, что доступ невозможен, так как у нас есть финансовые и клиентские данные, но вот вам ссылка на видео, где можно посмотреть, как это работает. И все это занимает время, если не продумать заранее.
Мы в итоге сделали два в одном: и демо-доступ, и видео о том, как работает приложение.
Обратная связь
Во-первых, надо следить за отзывами, которые оставляют клиенты в App Store и Google Play. Если ничего не отвечать и не менять, то рейтинг приложения будет падать: клиент несчастный, комментарий плохой, впечатление испорчено. Во-вторых, хорошо бы продумать альтернативный канал связи — то есть телефон или кнопка support должны быть в самом приложении, желательно на виду. Если у клиента проблема и он не знает, куда жаловаться, он напишет в отзывах к приложению.
Мониторинг активности
Допустим, у вас сто тысяч клиентов, а скачиваний всего десять. Надо искать проблему. Или скачиваний много, но после этого клиент заходит и сразу же уходит, приложением не пользуется. В чем причина? Надо собирать аналитику поведения пользователей. Сервисов, которые собирают такие данные, много. Проблема в том, чтобы их грамотно проанализировать и сделать правильные выводы. И это тоже момент, который стоит учесть на старте — как минимум, выделить такую задачу и назначить ответственного.
Чек-лист
Что учесть при создании приложения, чтобы им реально пользовались клиенты:
- сперва анализ, потом ТЗ;
- работа над ТЗ с участием всех отделов;
- кастомизация без фанатизма;
- баланс между основными и дополнительными функциями;
- тщательный выбор подходящей технологии;
- выбор надежного подрядчика;
- возможность прямой коммуникации между командами заказчика и разработчика;
- контроль безопасности (тесты);
- подготовка к прохождению ревью;
- сбор обратной связи;
- мониторинг активности пользователей.
Фото на обложке: HayDmitriy/Depositphotos
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Источник: https://rb.ru/
Average Rating