требования к функционалу мобильного приложения
Каким должен быть функционал мобильного приложения
Функционал мобильного приложения – мощный инструмент для ведения бизнеса, который не стоит недооценивать. Он выполняет сразу несколько важных функций: повышает интерес пользователей к предоставляемым товарам и услугам компании, а также привлекает новых клиентов и партнеров.
Это удобно для современного пользователя, поскольку доступ к приложению возможен в любое время в режиме 24/7 в любой точке мира.
Однако следует соблюдать баланс между предлагаемым функционалом мобильного приложения и требованиями клиентов. Идеальное приложение включает в себя все необходимые опции для выполнения своего непосредственного назначения, но, в то же время, он не должен быть перегружен.
Прежде, чем заказать создание приложения для смартфонов, необходимо проанализировать предложения конкурентов и решить, как новое приложение будет выгодно отличаться от них.
Главный вопрос в разработке функционала приложения: как получить эффективный продукт?
Необходимый функциональный минимум приложения включает такие опции:
Почему эти методы работают?
При использовании основных компонентов и дополнительных опций (связанных со спецификой работы фирмы) достигается максимальное приближение к требованиям пользователя. Таким образом значительно повышается интерес к фирме и растет целевая аудитория.
Конечной целью, на которую ориентировано приложение, является рост прибыли за счет популяризации бизнеса заказчика, а также монетизации. Пусть стоимость создания бизнес-приложения не пугает опытных предпринимателей, поскольку в итоге они получают значительный финансовый доход от своего вклада.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
В РФ появился предварительный стандарт для мобильных приложений с 87 требованиями к их функционалу
Чиновники Росстандарта утвердили предварительный стандарт для мобильных приложений в России. Он содержит 87 требований к функционалу софта, о чем сообщает «Коммерсант». Одно из основных требований — возможность бесплатного ознакомления с возможностями платного софта. Пока что сам стандарт и его требования носят сугубо рекомендательный характер, но разработчики документа считают, что при создании новых приложений стоит ориентироваться именно на него.
Требования разделяются на несколько категорий, включая качество мобильных приложений, юзабилити, безопасность, производительность. Заместитель руководителя Роскачества Илья Лоевский заявил: «Раньше в России не было госстандартов в области мобильных приложений, и разработчики ориентировались на гайдлайны корпораций, в частности Google и Аpple».
Авторы документа считают, что любое приложение должно запрашивать минимум разрешений при установке. Кроме того, разработчикам необходимо объяснять, зачем нужно каждое из разрешений — пользователи, особенно неопытные, далеко не всегда это понимают. Любое приложение должно иметь недвусмысленно трактуемую политику конфиденциальности.
Так, пользователи должны получить всю необходимую информацию о том, какие данные приложение будет собирать и каким образом личные данные пользователя будут обрабатываться и храниться. Должна быть доступна информация о том, кто сможет получить доступ к пользовательским данным и в каком случае. Согласно новому стандарту, любой пользователь имеет право отказаться от сбора данных и использование любым приложением. Самое главное, все персональные данные пользователей должны храниться в России, что определяется так называемым «законом Яровой».
Еще одно важное требование стандарта — уведомление пользователей любого приложения о том, будет ли использоваться личная информация для рекламы в том либо ином виде. У платных приложений должна быть lite-версия с возможностью апробации основных функций программы. Если пользователю приложение подходит, он может его купить. Но это произойдет лишь после того, как тот, кто загрузил приложение, полностью с ним ознакомится. Интересным требованием стандарта является необходимость отсутствия критических уязвимостей. При этом обновляться приложения должны не реже одного раза в год, в них не должно быть никакой навязчивой рекламы. Разработки же обязаны оперативно реагировать на вопросы пользователей.
Чиновники считают, что новый стандарт призван стать «ориентиром для организаций при разработке мобильных продуктов». Его планируется ввести в действие с 1 октября этого года, о чем сообщили представители Роскачества. Илья Лоевский заявил, что данным стандартам при необходимости могут пользоваться все заинтересованные лица, в том числе организации стран евразийского экономического Союза. Лоевский уверен, что через три года стандарт получит статус «ГОСТ Р» и станет бессрочным.
Далеко не все разработчики довольны новой инициативой чиновников. В частности, свое мнение выразил старший разработчик Node.js Юрий Бушев. Он заявил, что проверку на соответствие требованиям описываемого стандарта прошли бы около 60%.
И действительно, большая часть приложений «изо всех сил» пытается получить как можно больше персональных данных пользователей, чтобы потом разработчики или их партнеры могли использовать собранную информацию для монетизации в той либо иной форме. Но как бы там ни было, многие разработчики считают, что попытка государства защитить пользователей приложений не будет иметь существенного эффекта.
Это объясняется тем, что статус «предварительного стандарта» совершенно не обязывает организации к исполнению его требований. Более того, новый стандарт практически не содержит четких технических требований. Возможно, над стандартом работали люди, которые не слишком хорошо знакомы с реалиями IT-сферы. Как бы там ни было, существует далеко ненулевая возможность того, что стандарт станет необходимым условием для разработчиков приложений для государства.
Крупные компании вероятнее всего не заинтересуются этим ГОСТом, а вот молодым разработчикам он может быть полезен и предостережет от простых ошибок, которые новички чаще всего допускают. Кроме того, стандарт не решит проблему в случае конфликта между разработчиком и пользователем, поскольку второй не имеет права требовать у производителя соответствовать данному своду требований.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ МОБИЛЬНОГО ПРИЛОЖЕНИЯ
by Андрей Вакурин · Published 15.08.2017 · Updated 25.02.2021
2.1 Предмет разработки
2.2 Назначение документа
3.1 Требования к дизайну сайта
3.2 Порядок утверждения дизайн-концепции
4.1 Классы пользователей
4.2 Требования к представлению сайта
4.3 Требования к системе управления сайтом
4.4 Требования к разделению доступа
5.1 Требования к информационному обеспечению
5.2 Требования к программному обеспечению
5.3 Требования к техническому обеспечению
5.4 Требования к лингвистическому обеспечению
5.5 Требования к эргономике и технической эстетике
6.1 Требования к наполнению информацией
6.2 Требования к персоналу
6.3 Порядок предоставления дистрибутива
6.4 Порядок переноса сайта на технические средства заказчика
| Термин | Описание |
| Сайт | Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц оформление и способы представления информации 2.1 Предмет разработки
Предметом разработки является Назначение мобильного приложения: – Вывод рекламной информации о мобильном приложении; – Осуществление администрирование мобильного приложения; – Вывод аналитической информации (с возможностью отправить на принтер и на почтовый адрес); Цель создания мобильного приложения: – Агрегирование сервисов курортной зоны России в одной месте; – Возможность бронирования путешествий «в один клик»; – Обмен сообщениями и отзывами между пользователями; Целевая аудитория сайта: – Семейные пары (средний возраст которых родителей 30-35 лет) с маленькими детьми, которые планируют провести отдых на курортных зонах России (Сочи, Крым и тд); – Молодежь (от 18 до 30 лет), которая планирует отправиться на зимние курортные зоны (Красная поляна, Кавказ и тд.); – Активные люди, которые любят путешествовать по России и сами планируют свой отпуск; 2.2 Назначение документа В настоящем документе приводится полный набор требований к реализации мобильного приложения и сайта. Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями: 3.1 Требования к дизайну сайта При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ). Оформление должно быть разработано в достаточно консервативном ключе. На страницах недолжно быть большого объема текста. В дизайне сайта не должны присутствовать: – много сливающегося текста; – тёмные и агрессивные цветовые сочетания и графические решения.
Рис. Пример формы авторизации 3.2 Порядок утверждения дизайн-концепции Под дизайн-концепцией понимается вариант оформления главной страницы и графическая оболочка внутренних страниц, демонстрирующие общее визуальное (композиционное, цветовое, шрифтовое, навигационное) решение основных страниц сайта. Дизайн-концепция представляется в виде файла (нескольких файлов) в растровом формате или в распечатке по согласованию сторон. Если представленная Исполнителем дизайн-концепция удовлетворяет Заказчика, он должен утвердить ее в течение пяти рабочих дней с момента представления. При этом он может направить Исполнителю список частных доработок, не затрагивающих общую структуру страниц и их стилевое решение. Указанные доработки производятся параллельно с разработкой программных модулей сайта. Внесение изменений в дизайн-концепцию после ее приемки допускается только по дополнительному соглашению сторон. Если представленная концепция не удовлетворяет требованиям Заказчика, последний предоставляет мотивированный отказ от принятия концепции с указанием деталей, которые послужили препятствием для принятия концепции и более четкой формулировкой требований. В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции (дорабатывает, вносит изменения). Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней. Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений. 4.1 Классы пользователей 3) Администратор – пользователь, авторизованный в интерфейсе сайта 4.2 Требования к представлению мобильного приложения Требования к представлению главной страницы мобильного приложения. Главная страница мобильного приложения должна содержать графическую часть, навигационное меню сайта (у пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.), а также контентную область для того, чтобы посетитель мобильного приложения с первой страницы мог получить вводную информацию об актуальных развлечениях, транспорте, питании и путевки, а также ознакомиться с последними новостями. В нижней части экрана должно располагаться горизонтальное меню и включать разделы: Транспорт, Питание, Развлечение, Проживание. Контентная часть главной странице мобильного приложения должна включать: Требования к отображению раздела «проживание». При переходе пользователя на раздел «проживание» пользователю в верхней части экрана Требования к внутренним страницам раздела проживание. Требования к отображению раздела «развлечения». При переходе пользователя на раздел «развлечения» пользователю Требования к внутренним страницам раздела «развлечения». Требования к разрабатываемому разделу «транспорт» Требования к разрабатываемому разделу «питание» Требования к внутренним страницам раздела «питание». Требования к внутренним страницам раздела «личный кабинет». Требования к странице «оплата». Оплата путевки, тура, экскурсии, снаряжения и тд. Оплата авиа, жд билетов. Требования к структуре сайта Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах. Пользователи могут авторизоваться в мобильном приложении, в форме авторизации должны присутствовать: Данные для доступа (авторизации): Ниже формы располагаются ссылка: Форма «Забыли пароль» содержит поля: При неудачной попытке авторизации – появляется приглашение для повторной попытки авторизоваться с формой авторизации. Списки рассылок и уведомления Авторизованные пользователи могут управлять своими списками рассылок, а также просматривать полученные уведомления. 4.4 Требования к разделению доступа После прохождения аутентификации сайт или мобильное приложение должно проверять полномочия пользователя на доступ к запрошенному разделу. Если доступ запрещен, пользователю должно быть выведено сообщение о невозможности доступа в закрытый раздел. Комментарии к статьям и разделам могут оставлять только зарегистрированные пользователи. 5.1 Требования к информационному обеспечению Требования к хранению данных Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД размещаются ссылки на них. Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД. Требования к языкам программирования Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0). Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML. Для реализации динамических страниц должен использоваться язык PHP. Для разработки мобильного приложения должен быть использован ReactJS Требования к организации гиперссылок Все ссылки в мобильном приложении должны быть относительными (за исключением внешних). Требования к иллюстрациям Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg. Требования к объему одной страницы Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb. 5.2 Требования к программному обеспечению Желательно, чтобы PHP не был запущен в SafeMode. 5.3 Требования к техническому обеспечению Точные технически характеристики сервера будут уточнены после завершения системы и обширного тестирования всех модулей 5.4 Требования к лингвистическому обеспечению Сайт должен выполняться на русском языке. 5.5 Требования к эргономике и технической эстетике Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций. 6.1 Требования к наполнению информацией Общие требования к информационному наполнению Наполнение страниц мобильного приложения должно происходить в автоматическом режиме. 6.3 Требования к персоналу Для эксплуатации веб-интерфейса сайта от администратора не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и стандартным веб-браузером (например, MS IE 6.0 или выше). Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word. Прочие пользователи: уверенный пользователь сети Интернет. 6.4 Порядок предоставления дистрибутива По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в – архив с исходными кодами всех программных модулей и разделов сайта; – дамп проектной базы данных с актуальной информацией. Дистрибутив предоставляется на CD-диске в виде файлового архива. 6.5 Порядок переноса сайта на технические средства заказчика После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и доступ к базе данных сайта. 6.6 Дополнительные требования Требования к производительности Работа любого скрипта не должна превышать 60 секунд. При условии нагрузки на сервер не более 500.000 обращений к страницам портала в сутки. Требования к безопасности Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php- код скриптов. Требуется разграничение доступа. Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен. На уровне СУБД должно быть реализовано разграничение доступа к данным в БД. Требования к надежности Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить Чтобы пользовались: что учесть при разработке мобильного приложения
директор IT-отдела британской финтех-платформы Bilderlings Доступность технологий создает иллюзию, что их разработка — это легкий и быстрый процесс. Однако любое неверное решение в этом деле может дорого обойтись. О том, что требует особого внимания при создании мобильного приложения, рассказал Юрий Мейталов, руководитель ИТ-отдела британской финтех-платформы 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 должны быть в самом приложении, желательно на виду. Если у клиента проблема и он не знает, куда жаловаться, он напишет в отзывах к приложению. Мониторинг активностиДопустим, у вас сто тысяч клиентов, а скачиваний всего десять. Надо искать проблему. Или скачиваний много, но после этого клиент заходит и сразу же уходит, приложением не пользуется. В чем причина? Надо собирать аналитику поведения пользователей. Сервисов, которые собирают такие данные, много. Проблема в том, чтобы их грамотно проанализировать и сделать правильные выводы. И это тоже момент, который стоит учесть на старте — как минимум, выделить такую задачу и назначить ответственного. Чек-листЧто учесть при создании приложения, чтобы им реально пользовались клиенты:
|
