29/07/2014
Креативный директор компании-разработчика мобильных приложений Redmadrobot Макс Десятых написал для ЦП колонку о том, какие шаги могут повысить шансы на создание успешного мобильного продукта.
Студия веб разработки и дизайна Madlight
Определение цели
Любой проект начинается с обозначения целей бизнеса и задач потребителя продукта. Очень важно правильно определить их и зафиксировать, чтобы регулярно сверяться уже по ходу проекта, иначе можно фатально отклониться от курса и на финише обнаружить себя решившим что угодно, кроме того, что нужно.
Если приложение само по себе продукт (калькулятор, например), то при его разработке нужно задаться двумя вопросами: зачем оно потребителю, и как потребитель будет им пользоваться? Получив ответы, берем «Построение бизнес-моделей» Александра Остервальдера и упаковываем идею в бизнес.
Если приложение — канал коммуникации для предоставления услуги (банковской или оператора связи), то возникает вторая сторона — помимо потребительских «зачем» и «как» должны быть вопросы по сервисной части — в каких типах коммуникаций приложение нужно и какие задачи оно решит для компании? Например, мобильный банк (система самообслуживания) должен повышать среднемесячные остатки на счетах клиентов, увеличивать комиссионный доход банка и обеспечивать допродажи продуктов.
Анализ требований
Работу непосредственно над реализацией мобильного приложения мы начинаем с детальной аналитики — от замысла продукта до подробного документирования функциональных и нефункциональных требований. На этом, первоначальном этапе, крайне важно получить согласованное и непротиворечивое описание того, что будет создано позднее, на последующих этапах. В этот же момент начинается работа по подготовке тест-кейсов, которые будут использоваться в ходе разработки для контроля соответствия требованиям, стандартам качества кода и работоспособности функциональности.
Не стоит опираться только на желания клиента, собственная экспертная аналитика даже важнее — кто, если не разработчик должен знать, как именно перенести те или иные услуги в мобильный канал.
К сожалению, часто наши мечты об идеальном сервисном приложении разбиваются о реальность. После сверки с требованиями к бизнес-процессам, изучения бэкэнда (насколько разработчик может в него интегрироваться и вынести сервисы на мобильные платформы) становится понятно, что проект предстоит сильно упростить. Например, если стать клиентом банка через приложение технически невозможно (только лично в отделении). Или если заказ запчастей в автосалоне и запись на ТО доступны только через колл-центр.
Найм лучшего дизайнера и опытного разработчика
Результаты этапа анализа (концепция продукта, спецификация требований) являются входящей информацией к следующему этапу — проектированию. Мы выполняем проектирование двух составляющих приложения: графический интерфейс и структура программного кода приложения. На этом этапе создаются каркас графического интерфейса (wireframes), карта экранов (screenflow), прототип низкой детализации, а также пользовательские сценарии (use cases) и дизайн кода приложения (software architecture).
Поскольку приложения, как правило, работают с сервером, результатом этапа проектирования также являются требования к серверной стороне по части взаимодействия с мобильным приложением (спецификация API). Стоит отметить, что уровень дизайнера — это ключ. Высокая квалификация этого специалиста на выходе дает аккуратные и красивые приложения, которые всем нравятся, а потому работают. Но важен и правильный разработчик. Любой может научиться программировать достаточно быстро, если знает английский язык и в своё время наткнулся на Stackoverflow, но правильный разработчик должен обладать фундаментальной подготовкой и наработать свои 10 000 часов опыта. Хорошая новость в том, что всё достаточно хорошо видно по коду, который он написал, но есть и плохая новость — нужно самому обладать достаточной технической компетенцией, чтобы дать оценку.
В соответствии с ГОСТом на разработку интерфейсов и принципом человеко-ориентированного дизайна стоит привлекать пользователей к проектированию на самых ранних стадиях.
Речь не идет о том, чтобы спрашивать у них, как сделать то или это, — ни в коем случае, — но желательно как можно раньше показать потенциальному пользователю хотя бы какой-то прототип. И внимательно послушать.
Критика дизайна со стороны юзабилити-специалиста
Далее скелет графического интерфейса обрастает визуальным дизайном, финализируются экраны и отрисовываются различные состояния для всех сценариев пользования. На этом этапе уже можно изготовить прототип высокой детализации, очень близкий по опыту пользования к итоговому продукту. Этот прототип мы подвергаем юзабилити-тестированию, чтобы удостовериться, что принятые дизайн-решения эргономичны и позволяют пользователю эффективно решать свои задачи. Полученные результаты используются для корректировки интерфейса, если это необходимо.
Юзабилити-исследование — супер-шаг быстрого выявления и устранения проблем, в частности, «задизайнивания». Это когда вместо упрощения реализации сценариев в погоне за эстетикой процесс решения задач усложняется. Результат — потеря эффективности. Это значит, что при тестировании меньшее количество пользователей поймет, как выполнить те или иные задачи. И среднее время решения задач, и количество успешных попыток выполнения сценариев будут не лучшими. С такой проблемой мы столкнулись в проекте «Мой Билайн» — функциональная кнопка, расположенная в соответствии с гайдами справа в углу, клево выглядела, но пользователи ее не замечали. Пришлось перемещать ее в центр экрана.
Дизайнер должен контролировать разработку
Когда архитектура приложения спроектирована и дизайн пользовательского интерфейса готов, мы приступаем к этапу разработки, на котором воплощаем требуемое поведение приложения в коде. Здесь не обойтись без авторского надзора дизайнера интерфейса. Он смотрит за тем, что получается, и выполняет две важные функции: контролирует, чтобы всё было в точности так, как задумано и нарисовано, и быстро вносит корректировки в дизайн, когда это требуется.
На этом этапе необходимо иметь работающий сервер (тестовый, продуктивный либо эмулятор), на котором происходит отладка клиент-серверного взаимодействия.
Опыт показывает, что сервер никогда не бывает готов к этому моменту и никогда не работает на 100% так, как должен.
Поэтому мы применяем специальные API-тестеры, которые в автоматическом режиме проверяют корректность работы сервера и соответствие спецификации API.
Анализ безопасности
Разработкой приложения должны заниматься специалисты, знакомые с понятием SA (security assurance). Только что мы проводили аудит приложения для крупной транспортной компании, которая продает свои услуги населению, в том числе через мобильный канал. Даже поверхностной проверки хватило, чтобы через дыру в безопасности получить доступ к данным с кредитных карт пользователей. Данные не были зашифрованы — скорее всего, компания этим вопросом просто не озадачилась.
Тестирование
По мере того, как создается мобильное приложение, мы «облепляем» код модульными тестами (unit test) и постоянно и автоматически подвергаем уже разработанный функционал тестированию. Это позволяет всегда быть уверенными в качестве разработанного кода.
По завершении этапа разработки мы проверяем работу приложения на соответствие всему набору тест-кейсов, которые базируются на требованиях, то есть мы проверяем работу приложения на соответствие исходным требованиям. После успешного прохождения через службу профессиональных QA-инженеров (quality assurance) приложение признается готовым к публикации. В этот момент мы сообщаем PR-службе дату поставки готовой сборки приложения — самое время сосредоточиться на подготовке текстовых и графических материалов: описаний, ключевых слов, скриншотов, видеопрезентаций.
Техподдержка и развитие
После публикации мобильного приложения работу продолжает вести служба техподдержки, которая как помогает пользователям решить их проблемы, так и определяет наличие конкретных дефектов (багов) приложения, которые подлежат исправлению. Наконец, важно понимать, что великолепные приложения появляются не в один момент, а в результате длительной работы по анализу пользовательского поведения с планомерным улучшением свойств и метрик. Приложения нуждаются в сопровождении на протяжении всего их жизненного цикла вплоть до утилизации.
Но это уже другая история.
http://madlight.org/
