Лого vc.ru

Макс Десятых, Redmadrobot: 8 этапов разработки успешного мобильного приложения

Макс Десятых, Redmadrobot: 8 этапов разработки успешного мобильного приложения

Креативный директор компании-разработчика мобильных приложений Redmadrobot Макс Десятых написал для ЦП колонку о том, какие шаги могут повысить шансы на создание успешного мобильного продукта.

Поделиться

Определение цели

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

Если приложение само по себе продукт (калькулятор, например), то при его разработке нужно задаться двумя вопросами: зачем оно потребителю, и как потребитель будет им пользоваться? Получив ответы, берем «Построение бизнес-моделей» Александра Остервальдера и упаковываем идею в бизнес.

Если приложение — канал коммуникации для предоставления услуги (банковской или оператора связи), то возникает вторая сторона — помимо потребительских «зачем» и «как» должны быть вопросы по сервисной части — в каких типах коммуникаций приложение нужно и какие задачи оно решит для компании? Например, мобильный банк (система самообслуживания) должен повышать среднемесячные остатки на счетах клиентов, увеличивать комиссионный доход банка и обеспечивать допродажи продуктов.

Анализ требований

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

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

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

Найм лучшего дизайнера и опытного разработчика

Результаты этапа анализа (концепция продукта, спецификация требований) являются входящей информацией к следующему этапу — проектированию. Мы выполняем проектирование двух составляющих приложения: графический интерфейс и структура программного кода приложения. На этом этапе создаются каркас графического интерфейса (wireframes), карта экранов (screenflow), прототип низкой детализации, а также пользовательские сценарии (use cases) и дизайн кода приложения (software architecture). 

Макс Десятых

Поскольку приложения, как правило, работают с сервером, результатом этапа проектирования также являются требования к серверной стороне по части взаимодействия с мобильным приложением (спецификация API). Стоит отметить, что уровень дизайнера — это ключ. Высокая квалификация этого специалиста на выходе дает аккуратные и красивые приложения, которые всем нравятся, а потому работают. Но важен и правильный разработчик. Любой может научиться программировать достаточно быстро, если знает английский язык и в своё время наткнулся на Stackoverflow, но правильный разработчик должен обладать фундаментальной подготовкой и наработать свои 10 000 часов опыта. Хорошая новость в том, что всё достаточно хорошо видно по коду, который он написал, но есть и плохая новость — нужно самому обладать достаточной технической компетенцией, чтобы дать оценку.

В соответствии с ГОСТом на разработку интерфейсов и принципом человеко-ориентированного дизайна стоит привлекать пользователей к проектированию на самых ранних стадиях.

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

Критика дизайна со стороны юзабилити-специалиста

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

Юзабилити-исследование — супер-шаг быстрого выявления и устранения проблем, в частности, «задизайнивания». Это когда вместо упрощения реализации сценариев в погоне за эстетикой процесс решения задач усложняется. Результат — потеря эффективности. Это значит, что при тестировании меньшее количество пользователей поймет, как выполнить те или иные задачи. И среднее время решения задач, и количество успешных попыток выполнения сценариев будут не лучшими. С такой проблемой мы столкнулись в проекте «Мой Билайн» — функциональная кнопка, расположенная в соответствии с гайдами справа в углу, клево выглядела, но пользователи ее не замечали. Пришлось перемещать ее в центр экрана. 

Дизайнер должен контролировать разработку

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

На этом этапе необходимо иметь работающий сервер (тестовый, продуктивный либо эмулятор), на котором происходит отладка клиент-серверного взаимодействия.

Опыт показывает, что сервер никогда не бывает готов к этому моменту и никогда не работает на 100% так, как должен.

Поэтому мы применяем специальные API-тестеры, которые в автоматическом режиме проверяют корректность работы сервера и соответствие спецификации API.

Анализ безопасности

Разработкой приложения должны заниматься специалисты, знакомые с понятием SA (security assurance). Только что мы проводили аудит приложения для крупной транспортной компании, которая продает свои услуги населению, в том числе через мобильный канал. Даже поверхностной проверки хватило, чтобы через дыру в безопасности получить доступ к данным с кредитных карт пользователей. Данные не были зашифрованы — скорее всего, компания этим вопросом просто не озадачилась.

Тестирование

По мере того, как создается мобильное приложение, мы «облепляем» код модульными тестами (unit test) и постоянно и автоматически подвергаем уже разработанный функционал тестированию. Это позволяет всегда быть уверенными в качестве разработанного кода.

По завершении этапа разработки мы проверяем работу приложения на соответствие всему набору тест-кейсов, которые базируются на требованиях, то есть мы проверяем работу приложения на соответствие исходным требованиям. После успешного прохождения через службу профессиональных QA-инженеров (quality assurance) приложение признается готовым к публикации. В этот момент мы сообщаем PR-службе дату поставки готовой сборки приложения — самое время сосредоточиться на подготовке текстовых и графических материалов: описаний, ключевых слов, скриншотов, видеопрезентаций.

Техподдержка и развитие

После публикации мобильного приложения работу продолжает вести служба техподдержки, которая как помогает пользователям решить их проблемы, так и определяет наличие конкретных дефектов (багов) приложения, которые подлежат исправлению. Наконец, важно понимать, что великолепные приложения появляются не в один момент, а в результате длительной работы по анализу пользовательского поведения с планомерным улучшением свойств и метрик. Приложения нуждаются в сопровождении на протяжении всего их жизненного цикла вплоть до утилизации. 

Но это уже другая история.

Статьи по теме
Макс Волошин, Redmadrobot: 14 ошибок при разработке мобильных приложений03 июня 2014, 18:26
WWDC глазами очевидца: новые тренды развития технологий10 июня 2014, 20:50
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Максим, спасибо за статью.
А можете дать полезных ссылок на статьи и доп. сервисы по описанным вами пунктам

Виталий, я бы начал со статей в Википедии — представление на базовом уровне даёт хорошее.

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
slugge

накоенц-то. через 3 года дошло что ненадо делать то что не умеешь

Blackberry официально отказалась от производства смартфонов
0
Иван Фурть
F-Game

Краткий пересказ жизни: "Родился, умер". Не все нужно кратко пересказывать...

А по сути: забавный рассказ про разработку игры от людей, которые делают не ф2п для мобилок.

Как сделать игру смешной: лекция разработчика юмористического проекта Stanley Parable
0
Alexey Bolshov

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

ABBYY запустила онлайн-платформу для оценки качества школьного образования
0
Алеша Егоров

А что продаете? Любопытно

«Подделки принесли нам 1,5 миллиона рублей за два месяца»
0
Vitaliy Yatsenko

Худший материал, который я читал в течение месяца.

«Половина украинцев — это программисты, копирайтеры и маркетологи»
0
Показать еще