команда для разработки мобильного приложения
Роли в команде разработки ПО
Андрей Подкин
Часто Иногда при обсуждении недостатков приложений пользователи говорят, что разработчики поленились сделать хорошо. Но кто такие разработчики приложений? Давайте попробуем разобраться, какие роли есть в команде разработки.
А точно все они есть?
В принципе, для того, чтобы сделать простейшее приложение, достаточно одного-единственного программиста. Но при возрастании сложности и увеличении сроков разработки кому-то волей-неволей придется исполнять те или иные роли, даже если они явно не выделены (в виде должностей или как-то еще).
Проект
Важный момент разработки программного обеспечения (ПО) заключается в том, что эта самая разработка ведется в рамках проектов. Т.е. очерчиваются сроки, желаемый результат и бюджет проекта (сюда же обычно включаются и людские ресурсы, ведь людей нанимают за деньги и от количества денег зависит, сколько разработчиков и какой квалификации можно нанять). А теперь давайте попробуем рассмотреть, кто же участвует в проектах разработки ПО.
Команда программистов
Собственно, те люди, которые придумывают и реализовывают приложение. Они:
Без написанного и скомпилированного кода приложения не будет. Именно поэтому совсем исключить программистов нельзя. Даже если какие-то приложения создаются в простом визуальном конструкторе, то это тоже своего рода программирование.
Именно программисты зачастую принимают решение, как конкретно будет реализована та или иная функциональность в приложении. И если функциональность реализована плохо, то значительная часть вины может лежать на программистах. А может и нет, поскольку финальное слово в принятии решений принадлежит не им.
Тестировщики
Это те люди, которые проверяют, корректно ли приложение работает. Причем корректно — не значит удобно для пользователя. Тестировщик может написать замечание к удобству использования, но его первоочередная задача — убедиться в том, что приложение работает согласно требованиям и спецификациям.
Тестировать приложения можно как вручную, так и при помощи автотестов (например, программно нажимать кнопки и проверять, какие экраны открываются).
При отсутствии в команде разработки явно выделенных тестировщиков их функции обычно передаются программистам. При этом считается, что программист не может корректно протестировать то, что он разрабатывал сам, и потому проводится перекрестное тестирование (Вася тестирует то, что делал Петя, а Петя — то, что делал Вася). Другой способ экономии на тестировщиках может заключаться в том, что опытный специалист привлекается только для написания плана тестирования, а реальное тестирование (на большом «зоопарке» устройств) производят начинающие тестировщики, которые «стоят» намного дешевле.
Если в приложении есть явная и незамысловатая ошибка (кнопки в калькуляторе иногда не нажимаются), то часть вины в ней лежит на тестировщиках (они что-то не проверили).
Дизайнер
Это человек, который определяет, как будет выглядеть и как будет вести себя приложение. Взаимное расположение элементов, схема перемещения по экранам, анимации — все это должен продумать дизайнер. Если приложение большое и сложное, то дизайнер может быть и не один. Или, например, один из дизайнеров может только рисовать интерфейс, а другой — глобально продумывать всю концепцию взаимодействия с пользователем.
Дизайнер есть не во всех компаниях, занимающихся разработкой ПО, поэтому если приложение не сулит коммерческого успеха, то появляется соблазн сэкономить на привлечении профессионального дизайнера (и тем более целой команды), передав его обязанности программистам. И может получиться не так уж и плохо, если программисты достаточно опытные и понятия «usability» и «user experience» для них — не пустой звук.
Иногда дизайнер совместно с программистами несет ответственность за часть ошибок в приложении: бывает, что реализовать придуманный дизайн довольно сложно, а при возрастании сложности увеличивается и вероятность совершения ошибок. И, конечно, все отзывы «неудобный интерфейс» — это камни в огород дизайнера.
Заказчик или владелец продукта
Это человек, который определяет весь ход создания и развития продукта. Он принимает решение, что должно быть сделано, оценивает, соответствует ли реализация концепции продукта или нет. Например, программисты говорят ему: «Для реализации этой штуки нам потребуется два месяца. Или можем использовать кучу сторонних библиотек и сделать все за неделю, но тогда объем приложения увеличится на 30 Мб». Владелец продукта может сказать: «Еще 30 Мб? Это совершенно неприемлемо» или «У нас релиз через месяц, делаем как можно быстрее и запускаемся». И он же несет ответственность за направление развития продукта. Если вы читаете отзывы: «Зачем испортили такое хорошее приложение? Теперь оно вообще стало ни о чем», знайте, именно владелец продукта определил такую судьбу проекта.
Разница в названиях роли проистекает из типа компании. В продуктовой компании (которая разрабатывает свой внутренний продукт) назначается владелец продукта. При заказной разработке выделяется представитель заказчика, который будет взаимодействовать с разработчиками.
Может ли проект разработки обойтись без этого человека? Проект — может, а продукт (приложение) — нет. Кто-то все равно должен понимать, для чего это приложение разрабатывается и как оно должно существовать и развиваться в дальнейшем.
Руководитель проекта
Человек, который руководит всем этим безобразием всей этой командой. Отслеживает сроки выполнения задач. Оперативно реагирует, если начинаются проблемы с качеством. Мотивирует команду работать более эффективно («выбивает» премии, заказывает пиццу, и прочая, и прочая). Вместе с владельцем продукта принимает решения, когда возможны альтернативные варианты при выборе развития продукта в ходе разработки. Если проект очень большой и сложный (что все-таки для мобильных приложений редкость), то он может разбиваться на несколько подпроектов, и у них могут быть свои руководители, а в помощь руководителю проекта выделяется администратор проекта, который занимается большей частью «бумажной» работы: ведет протоколы совещаний (фиксирует принятые решения), рисует график прогресса проекта (например, «сгорание задач»).
По статистике, только малая часть проектов по разработке ПО завершается в срок с установленным уровнем качества и в рамках первоначального бюджета. Если что-то пошло не так, именно руководитель проекта в конечном счете принимает ответственность за то, чем придется жертвовать: выпустить продукт позднее, исправлять ошибки при помощи обновлений или выбить побольше денег (например, чтобы отдать часть разработки другой команде за отдельные деньги).
В небольших проектах с опытной командой программистов и тестировщиков можно обойтись и без явно выделенного руководителя проекта. Тогда обычно его роль исполняет ведущий программист — тимлид (калька с английского teamlead — лидер команды).
Заинтересованный топ-менеджер
В литературе по управлению проектами его обычно называют спонсором проекта. Для компании, разрабатывающей ПО на заказ, он не важен. И без него всем очевидно, что проект дает: это те деньги, за счет которых и живет компания. Но в компании, которая разрабатывает ПО внутри себя (это может быть и продуктовая компания, и компания, разрабатывающая приложения для своих внутренних потребностей), все может быть сложнее. Конкретное приложение может быть не столь важно для компании, размер и структура компании могут вносить свои коррективы (кто-то может решать свои личные задачи, например, по карьерному росту, за счет конкретного проекта). Поэтому становится очень важным, чтобы был топ-менеджер, который «болеет» за продукт и продвигает его. В этом случае при возникновении проблем команда разработки всегда может обратиться к нему, рассказать о проблемах и получить необходимые ресурсы. Типичный пример: премии за успешную работу. Если команда действительно старалась и выпустила приложение в срок с заданным качеством, руководитель проекта может обратиться к спонсору проекта для того, чтобы он инициировал выделение дополнительных средств на премию.
Заключение
Теперь вы знаете, кто есть кто в команде разработки приложений. И если вам придет в голову мысль разработать приложение под Android или iOS, вы будете знать не только о том, что для этого надо, но и о том, каких людей нужно найти.
6 ключевых ролей в команде разработки программного обеспечения
Имидж профессионалов IT сферы в массовой культуре кардинально изменился за последние годы. Абсурдные стереотипы ушли в прошлое, а программисты стали настоящей элитой 2010-х.
Однако, когда мы говорим о профессионалах в IT сфере, мы должны говорить не только о программистах. IT проекты требуют участия различных специалистов, и не только с техническим образованием.
В Smartum Pro мы работаем с проектами из различных индустрий, таких как здравоохранение, логистика, электронное обучение и др., для которых необходимы различные подходы, но при этом основные аспекты нашего процесса разработки веб и мобильных приложений остаются неизменными.
Наша команда включает в себя профессионалов с различными ролями, которые работают для получения лучшего решения, удовлетворяющего целям и требованиям клиента.
В данной статье мы поговорим о 6 ключевых профессиональных ролях, необходимых для проекта разработки качественного мобильного или веб приложения.
Бизнес-аналитик вовлечен в проект с первой стадии, сразу после заключения сделки, а иногда даже до нее. Главная обязанность бизнес-аналитика заключается в коммуникации как с клиентом, так и с командой разработчиков.
Заказчики обычно думают в первую очередь о своих целях. Программисты же думают о функциях и коде, фокусируясь на том, как сделать то, что хочет клиент, и решить его задачи.
Но между целями клиента и функциями приложения лежит целая пропасть. Следовательно, бизнес-аналитик (сокращенно БA) должен точно определить, что хочет заказчик и что ему нужно.
БA собирает требования клиента к желаемому продукту, анализирует то, как он должен выглядеть и какие функции нужно включить в разработку, а также зачем и как это должно быть сделано.
Бизнес-аналитик также проводит исследование конкурентов вместе со специалистами в области маркетинга для обеспечения устойчивости продукта на рынке и его конкурентоспособности с уже существующими продуктами.
Бизнес-аналитик также определяет целевую аудиторию продукта, создает пользовательских персонажей, вайрфреймы и пишет техническое задание, если оно не было полностью предоставлено клиентом.
Таким образом, роль бизнес-аналитика заключается в планировании оптимального процесса разработки, интерпретации требований заказчика, подготовке документации и осуществления эффективной коммуникации между клиентом и командой.
Когда требования клиента определены и правильно интерпретированы, в процесс разработки подключается менеджер проекта (сокращенно PM). Его основная задача заключается в управлении проектом, как следует из названия профессии.
Чтобы точнее объяснить роль PM, давайте рассмотрим его основные задачи. Как и бизнес-аналитик, менеджер проекта также может быть включен в коммуникацию с клиентом, однако главной задачей PM является работа непосредственно с командой разработчиков программного обеспечения.
Менеджер проекта распределяет задачи между ними, планирует ход работы, мотивирует команду, контролирует процесс и координирует общие действия. Также он несет ответственность за тайм-менеджмент, управление рисками и действия в случае непредвиденных ситуаций.
PM следит за тем, чтобы процесс разработки шел по плану. В гибких методологиях это также подразумевает то, что изменения, которые необходимо внести в проект, внедряются корректно, так что клиент может быстро и легко утвердить их, а команда не делает лишней работы.
Это тот человек, от которого идет большая часть креативности в проекте. Главная ответственность UI/UX дизайнера заключается в создании приятного интерфейса и отличного пользовательского опыта.
Дизайнер использует вайрфреймы, созданные клиентом или бизнес-аналитиком, чтобы “нарисовать” мокапы и создать дизайн интерфейса мобильного приложения (UI) согласно действующим гайдлайнам и трендам. Он также планирует пользовательский опыт, который сделает продукт удобным для использования.
В Smartum Pro наши дизайнеры применяют InVision для создания динамических прототипов, которые отражают поведение и внешний вид будущего продукта, позволяя протестировать прототип на реальном устройстве до начала процесса разработки.
Клиенту удобно видеть модель приложения, а программистам прототип просто необходим, чтобы написать код. Это как дизайн-проект комнаты для профессионалов, которые будут её декорировать — необходимо видеть, что должно получиться в результате работы. Наши дизайнеры в Smartum Pro также предоставляют графические элементы для магазинов приложений, мокапы и логотипы.
Это ядро команды, люди со специфической областью экспертизы. Программисты — это словно переводчики, которые переводят язык человека и язык графики в язык цифровых технологий, которые понятны компьютерам и устройствам, что позволяет выполнять то, что хочет клиент.
Существуют различные уровни в команде разработчиков программного обеспечения, включающие junior, middle и senior уровни, которые зависят от опыта работы и уровня экспертизы.
Программисты также имеют различные области экспертизы, они пишут на различных языках и работают с различными платформами. Поэтому и существует такое “разнообразие” разработчиков, вовлеченных в один проект. Например, стандартный проект разработки мобильного приложения требует участия как минимум Android, iOS и backend-разработчиков.
QA (Quality Assurance) специалисты необходимы для каждого процесса разработки и обеспечения высокого качества продукта. Они тестируют его, проходят через все приложение и определяют баги и ошибки с последующим предоставлением отчета команде разработки, которая проводит их исправление.
Необходимо выявить ошибки до того, как продукт попадет к пользователям, чтобы сохранить лицо продукта и обеспечить позитивный пользовательский опыт. Другие обязанности QA-специалистов включают общее тестирование продукта и его соответствие заявленным требованиям.
Специалист по маркетингу
Профессионалы в сфере маркетинга работают с продуктом на стадии до и пост-разработки и являются необходимыми для развития каждого продукта, только если это не система, используемая исключительно внутри компании. Команда разработала отличный продукт, но какой в этом смысл, если никто об этом не узнает?
Таким образом, эти специалисты проводят исследование рынка на первой стадии проекта, определяют целевую аудиторию и изучают ее нужды и предпочтения, а также подготавливают и запускают маркетинговые кампании после выпуска продукта, ищут каналы распространения, занимаются маркетингом в социальных сетях, пишут тексты и статьи, описания продукта (контент-маркетинг) и др., чтобы обеспечить продвижение продукта и его успех.
Специалисты по маркетингу также отвечают за анализ статистики приложени, его дальнейшее развитие и улучшение (подразумевая анализ реакции пользователей, определение функций и того, что нужно сделать в следующей версии)и пр.
Суммируя все вышесказанное, стоит отметить то, что команда разработки программного обеспечения — это не только программисты.
В Smartum Pro работает слаженная команда профессионалов с экспертизой в различных сферах, отвечающих за все стадии разработки мобильных и веб приложений и обеспечивающих создание качественного продукта.
Разработка мобильного приложения: от идеи до результата
Процесс создания нативного приложения, описанный компанией BHW Group и адаптированный AppCraft под современный софт и реалии.
Каждый день тысячи мобильных приложений появляются в Google Play и Apple App Store. Соцсети, мессенджеры, игры и многие другие – все они делаются профессионалами по одному алгоритму разработки. И сегодня мы разложим его на понятные шаги, чтобы показать вам внутреннюю кухню мобильной разработки. Она включает в себя шесть этапов: оформление идеи, разработка стратегии, работа над дизайном, непосредственно разработка, выход на рынок и мониторинг ситуации.
Материал будет полезен начинающим студиям разработки, тем, кто задумал свой стартап, а также тем, кто спонтанно решил внедрить в свой бизнес приложение, но ещё смутно представляет, какие издержки оно может принести.
Как бы тривиально это не звучало, но хорошее приложение начинается с хорошей идеи. Если у вас её нет, подумайте над существующими в мире проблемами и возможными способами их решения. Перебирайте варианты, пока не обнаружите подходящий пробел на рынке, а потом ищите лучший путь, которым его можно заполнить. Это половина успеха.
Ключом к ответу может стать понимание того, почему эта проблема вообще существует, а для её решения до сих пор нет ни одного приложения. Погрузитесь в тему, соберите данные и обсудите их с командой. И, если у вас достаточно ресурсов на разработку, беритесь за дело.
Следующий шаг после рождения идеи – составить план работы над проектом. Его проще всего начать с анализа конкурентов. Найдите на рынке похожие мобильные приложения и проанализируйте следующие факторы:
История компании – будьте готовы столкнуться с теми же трудностями, что и ваши ближайшие конкуренты. Заодно попробуйте понять, как они завоевали признание аудитории.
Благодаря анализу конкурентов вы убиваете сразу двух зайцев. Во-первых, учитесь на чужих ошибках, причём бесплатно, без траты лишнего времени и ощущения собственной неполноценности. Во-вторых, вы начинаете понимать, на что вам придётся пойти, чтобы выжить на рынке мобильной разработки. Что именно пользователь хочет увидеть в своём смартфоне? Есть ли для вашего приложения свободная ниша? Ответы на эти вопросы помогут вам найти баланс между вашими возможностями и потребностями рынка. Ну а если ваша идея настолько уникальна, что подобных приложений ещё нет в природе, посмотрите, как разработчики-первопроходцы из других сфер презентовали себя аудитории.
Если вы не занимаетесь разработкой мобильных приложений исключительно ради удовольствия, то наверняка заинтересованы в том, чтобы получить с продукта хорошую прибыль. Покупки в приложении, оплата подписки или премиум-версии, размещение рекламы, продажа данных – все эти способы монетизации можно использовать, даже если вы распространяете приложение не бесплатно. Чтобы выбрать оптимальный вариант, посмотрите, на чём зарабатывают ваши конкуренты, и определитесь, в какой момент начнёте монетизацию. Если спохватитесь слишком поздно, рискуете попасть в трудные времена.
Эта ступень мобильной разработки связана с пониманием главного вызова, стоящего перед любым разработчиком. Вам придётся продвигать своё приложение, чтобы о нём узнали и начали пользоваться. Сотни качественных мобильных приложений пылятся на виртуальных полках потому, что у их разработчиков не было маркетинговой стратегии и бюджета на её реализацию. А без неё могут обойтись только B2B-приложения, сделанные для внутреннего использования сотрудниками компании-заказчика.
Этап стратегического планирования завершается составлением дорожной карты вашего мобильного приложения, которая зафиксирует его идеальный путь от минимального жизнеспособного продукта (MVP) до попадания в топы магазинов. Составьте список контрольных точек и расставьте их в зависимости от собственных приоритетов. Учитывайте функционал приложения, возможные пожелания аудитории и следующие из них обновления. Но над ними вы будете думать, когда получите фидбек от первых пользователей MVP. Пока же можно сосредоточиться на других вещах.
Внутренняя архитектура зависит от функционала мобильного приложения и выбранного способа обработки и хранения данных. Обычно мы составляем два списка – характеристик, которыми должно обладать приложение, и ключевых визуальных элементов. Они становятся фундаментом для всех будущих архитектурных работ.
Инструменты: доска и маркеры. Много маркеров.
Затем мы рисуем на доске или бумаге экраны и располагаем на них необходимые элементы и данные. Несмотря на то, что один и тот же элемент может присутствовать на нескольких экранах, у него должен быть «дом». Именно на этом этапе в проект можно внести любые изменения.
Они определяют способы взаимодействия пользователя с приложением. Учитывайте все варианты его поведения, чтобы понять, сколько касаний ему потребуется для завершения того или иного действия, причём количество этих касаний должно быть пропорционально сложности действия. Если обнаруживается, что интерфейс не понятен пользователю интуитивно, приходится возвращаться к предыдущему шагу и менять вайрфреймы. При этом после любого изменения все пользовательские сценарии проверяются заново на случай, если мы, упростив одно действие, усложнили другое.
Инструменты: маркеры, плюс Invision, Adobe XD и Figma.
Самый простой способ проверить, насколько хорош ваш UX-дизайн – протестировать его на будущих пользователях. Отправьте им ссылку, после перехода по которой они смогут «потыкать» по отрисованным вайрфреймам. О функциональности речь не идёт, только о проверке навигации. Прислушивайтесь к комментариям, возвращайтесь на один-два-три шага назад, исправляйте проблему и тестируйте. Снова и снова.
Инструменты те же, что и для пользовательских сценарий: Invision, Adobe XD и Figma.
Стайлгайды – это стройматериалы для отделки «интерьера» мобильного приложения и повышения его юзабилити. Без продуманного стайлгайда элементы дизайна будут менять цвета и плавать по экрану, сбивая пользователя с толку.
Руководство по стилю мобильного приложения должно быть максимально подробным и опираться на характеристики аудитории. Ей нужно работать в приложении по ночам? Делаем тёмную тему. Это внутреннее приложение для сотрудников крупной компании? Убираем всё лишнее. Как это сделать? Опытный UI-дизайнер предложит сотню вариантов цветовой палитры, шрифтов и виджетов (кнопок, форм, значков и т.д.).
Рендеринг – это процесс отрисовки вайрфреймов в цифре в соответствии со стайлгайдом. Дизайнер должен придерживаться рекомендаций, но не следовать им слепо. Только так визуальная составляющая мобильного приложения будет выглядеть целостно.
Не стоит жалеть времени на то, чтобы отправить отрисованные в диджитале экраны тем же пользователям, которым отправляли вайрфреймы. Это своего рода переломный момент, после которого любые изменения становятся крайне затратными. По сути, вы заливаете фундамент будущего дома, так неужели не надо свериться с планом и десять раз проверить все измерения?
Настало время подключать разработчиков, которые качественно реализуют продуманный до мелочей и многократно протестированный дизайн. Что может пойти не так? Например, вы заказали дизайн у одной компании, а разработку – у другой. Или у них внутренний раскол. Поэтому рекомендуем работать с профессиональной командой, которая занимается мобильной разработкой от идеи до результата.
В некоторой степени успех совместной работы дизайнеров и разработчиков зависит от выбора инструментов. Например, приложение Zeplin показывает последним все свойства загруженного в него дизайна, хотя не обладает всеми возможностями Sketch или Photoshop. В любом случае, убедитесь в том, что команда пользуется точными значениями измерений и не ленится копировать HEX-коды цветов.
В мобильной разработке существует великое множество технологий. Одни почти не требуют затрат, но не отличаются высокой производительностью, другие потребуют больших вложений во имя блестящего результата. Худшее, что вы можете сделать на данном этапе – использовать устаревшие или ненадёжные инструменты, которые приведут к тому, что вам придётся переписывать код, доплачивая остальным членам команды за переработку. Чтобы избежать этого, рекомендуем принять ряд важных решений до начала работы над проектом. Каких именно, расскажем ниже.
Существует три основных подхода frontend-разработке:
Сервер влияет на производительность мобильного приложения и масштабируемость продукта, то есть способность системы увеличивать ту же производительность за счёт увеличения доступных ресурсов. Технологии здесь те же, что и в разработке веб-приложений. Отправная точка – определиться с:
Языком программирования – написать мобильное приложение можно на Java, SWIFT, а сервер на Javascript, C#, Go-lang, PHP, Python и ещё десятке языков. И у каждого из них есть фреймворки на любой вкус.
Чтобы спланировать спринт, составьте список задач с конкретными критериями оценки результата. Это поможет разработчикам оценить временные затраты на выполнение каждой из них и равномерно распределить обязанности внутри команды.
На этапе разработки команда воплощает в жизнь идеи дизайнеров и свои собственные. Результат проверяет QA-команда (отдел контроля качества) или менеджер проекта. Последний также распределяет задачи между разработчиками, добиваясь равномерной загрузки команды на протяжении всего спринта.
Разработчики должны чётко представлять концепцию приложения и его отличительные черты. Ничто так не мотивирует, как амбициозные цели, но в погоне за ними нельзя забывать о реальности. Возможно, вам придётся смириться с тем, что часть функций так и останется нереализованной.
Тестировать приложение не должны его же разработчики.
Тип тестирования выбирают исходя из проверяемой характеристики приложения:
Функционал – должен соответствовать заявленному. Хорошо, если у подрядчика есть QA-команда, а у неё – план тестирования со списком всех функций приложения и его желаемым поведением. Но если таковой нет – необходимо позаботиться об этом и нанять специально обученных специалистов. Юзабилити – интерфейс мобильного приложения должен быть интуитивно понятным и дружелюбным. О проблемах с этими качествами вам лучше всего расскажут те, кто видят продукт впервые.
Но и это ещё не всё:
Регрессионное тестирование – используется для проверки уже протестированного кода на ошибки, исправленные ранее, или возникшие в результате этих исправлений. Здесь на помощь вновь приходит QA-команда с чек-листами изменений, внесённых в код на каждом из спринтов.
В конце каждого спринта обсуждайте его результаты с заинтересованными сторонами. Сделайте выводы из трудностей, с которыми вы столкнулись, и постарайтесь больше их не допускать. Отмечайте успешные решения и используйте их в дальнейшем. Двух одинаковых проектов быть не может, поэтому разработчики постоянно прокачивают свои навыки, в том числе – навыки планирования работы над проектом. Который, кстати, переходит в следующую стадию.
К этому моменту приложение (или хотя бы MVP) должно быть полностью готово к выходу на рынок. Но если вы хотите потратить маркетинговый бюджет с умом, то размещать приложение в публичный доступ Google Play и Apple App Store пока рано. Нужно ещё раз протестировать его — на этот раз на небольших группах целевой аудитории. Сделать это можно двумя способами.
Первое правило фокус-группы — участники должны увидеть приложение впервые. Вам необходимо выяснить, кто они, откуда узнали о вашем продукте и пользуются ли чем-то похожим. Когда перейдёте непосредственно к тестированию, не давайте подсказок, а наблюдайте за тем, какие сложности возникают у людей в процессе использования приложения. Затем попросите каждого участника высказаться и обсудите все спорные моменты.
Вместе с фокус-группой (или вместо неё) можно устроить пробный запуск приложения для ограниченной аудитории опытных пользователей и охотников за новинками. Обязательно скажите им, что цените их интерес, попросите фидбек и пообещайте принять во внимание конструктивную критику. Кстати, бета-тестирование также позволяет проверить, как ваше приложение работает с разными устройствами и операционными системами.
Помните: лучше получить как можно больше подробных отчётов об ошибках и исправить их, чем не получить ни одного и узнать о проблеме от недовольных комментаторов из магазинов.
Перед тем, как представить своё мобильное приложение миру, позаботьтесь о двух вещах: надёжном API-сервере и соблюдении правил Google Play Store и Apple App Store.
Большинству мобильных приложений нужен backend-сервер, который обменивается данными с ними. Если сервер перегружен или не отвечает, приложение не будет работать. Хорошая новость: благодаря облачным технологиям конфигурацию сервера можно менять в зависимости от размера пользовательской базы.
Публикация приложения в Google Play Store и Apple App Store – трудоёмкий процесс. Вам придётся убедиться в том, что приложение отвечает требованиям магазина, заполнить несколько форм для каждого из них, подготовить скриншоты и маркетинговые материалы, составить текст описания… а Apple ещё и тщательно в течение нескольких дней будет проверять само приложение и даже может не только потребовать изменений, но и отказать в публикации из-за “бессмысленности” приложения. Нет, мы не исключаем вероятность того, что магазин примет ваше приложение без лишних вопросов, и через несколько дней оно будет доступно для скачивания. Просто предупреждаем о возможных трудностях, которые возникнут с вероятностью в 99%.
Разработка мобильного приложения не заканчивается с его публикацией в сторах. Даже за умеренно популярными приложениями стоит целая история обновлений. Исправленные ошибки, улучшение производительности, новые возможности – поводов масса. Выбрать нужный именно вам поможет мониторинг следующих аспектов.
Для отслеживания падений приложения есть немало библиотек. Они хранят информацию о том, что делал пользователь во время падения, на каком устройстве оно произошло и многое другое – в общем, всё, что поможет разработчикам решить проблему. Кроме того, функцию отправки сообщения о падении можно встроить в само приложение. Вам останется только рассортировать их.
Современные системы аналитики мобильных приложений собирают информацию об аудитории вашего приложения (распределение пользователей по полу, возрасту, местонахождению, языку и т.д.) и особенностях взаимодействия с ним (времени входа в приложение, времени, проведённом в приложении, количестве просмотренных экранов и пр.). Некоторые даже составляют тепловые карты, которые показывают, на какие кнопки пользователи нажимают чаще остальных. Используйте эти данные как ориентиры на будущее: вкладывайтесь в доработку тех областей, в которых концентрация действий аудитории наиболее высока.
Этот показатель нельзя измерить двумя предыдущими способами, но следить за ним необходимо. Как часто происходило то или иное действие и как долго оно длилось – вот вопросы, которые помогут оптимизировать работу приложения. Если простейшее действие занимает больше времени, чем ожидалось, это тревожный сигнал.
Оценки и отзывы в магазинах крайне важны, особенно для новых приложений. Всегда отвечайте комментаторам: благодарите за хорошие слова и постарайтесь помочь тем, кто столкнулся с трудностями при использовании вашего приложения. Комментаторы обычно не ожидают, что им ответят реальные разработчики. Чуть больше клиентоориентированности – и две звезды превращаются в пять, а ваша репутация взлетает до небес.
Цель мониторинга – понять, что делать дальше. Используйте статистику и отзывы, чтобы выявить слабые места, а потом возвращайтесь на n шагов назад и укрепляйте их. Повышайте конверсию пользователей в покупателей, расширяйте клиентскую базу, зарабатывайте, в конце концов. Ведь мобильная разработка – это очень динамичная среда, и, чтобы быть на плаву, надо постоянно работать над продуктом и над собой.
Процесс разработки мобильного приложения кажется сложным только на первый взгляд. Да, вам придётся принимать множество важных решений и постоянно возвращаться к предыдущим этапам. Не поддавайтесь соблазну пропустить один или несколько – в конце вас ждёт заслуженная награда в виде денег и благодарных пользователей. Говорим об этом как разработчики с почти 7-летним опытом 🙂
Статья-источник на странице блога компании BHW Group.