бизнес процесс мобильного приложения
Этапы разработки мобильного приложения: пьеса в 7 действиях
Время чтения: 7 минут
Отправим вам статью на:
Знаете ли вы, что около 6 140 мобильных приложений выходят в Google Play ежедневно? А к 2020 году число релизов в App Store достигнет 5 миллионов? Статистика говорит об одном: пора разрабатывать своё мобильное приложение. Если вы всерьёз задумались над разработкой приложения, наш обзор вам поможет.
Неважно, что вы планируете создать — инструмент для бизнеса или стартап с широкой аудиторией. Мы развеем ваши страхи и опишем этапы разработки мобильного приложения.
Итак, пьеса “Процесс разработки мобильного приложения” в 7 действиях.
Действующие лица
Клиент — заказчик мобильного приложения, идейный вдохновитель проекта
Azoft — разработчики приложения
Project manager — менеджер проекта
Бизнес-аналитик — исследователь и хранитель знаний о требованиях к продукту
UI/UX дизайнер — создатель интуитивного и привлекательного интерфейса приложения
Разработчик — инженер, который пишет код приложения
QA инженер — специалист по тестированию приложения
Пролог
Сначала клиент приходит с идеей мобильного приложения. Мы просим клиента предоставить нам техническое задание (ТЗ), а если его нет — высылаем бриф на разработку мобильного приложения. Бриф помогает расставить приоритеты, обозначить цели и задачи приложения.
Все приложения разные, и мы используем разные методологии разработки: каскадную модель — Waterfall, и гибкую — Agile. Что бы вы не выбрали, процесс создания мобильного приложения включает оценку, аналитику, дизайн, разработку, тестирование, багфиксинг, релиз и поддержку после релиза. Ключевое различие состоит в подходах. В каскадной модели продукт разрабатывается сразу полностью. В гибкой — приложение разрабатывается итерациями, каждая из которых объединяет в себе все перечисленные стадии разработки.
На выходе:
Действие первое — Планирование и оценка
Первый вопрос, который интересует клиента: “Сколько это будет стоить?”. Следующий за ним: “Когда будет готово мобильное приложение?”. Чтобы ответить на оба вопроса, Azoft проводит оценку и составляет план работ. На этом этапе к проекту обычно присоединяется менеджер проекта. Он может выступать со стороны заказчика или со стороны команды разработчиков. Задачи менеджера проекта: координировать работу команды и общаться с заказчиком.
Но что же означает загадочное слово “оценка”? На этом этапе мы изучаем техническую документацию. Рассчитываем, сколько времени потребуется на разработку и тестирование. Выявляем не описанные сценарии и узкие места в ТЗ.
Экспресс-оценка занимает от нескольких часов до одного дня и даёт примерное представление о трудозатратах. Детальная оценка может длиться от нескольких дней до недели, но она позволяет точно определить, как, когда и какое приложение вы получите в результате. Если бизнес-аналитик подключается к проекту на этапе оценки, клиенту и разработчикам легче получить единое представление о приложении и всё точно рассчитать.
Но какой бы детальной ни была оценка, случается, что заказчики добавляют новые фичи прямо по ходу проекта. Когда мы делали приложение Pro Photo Shoot, соцсеть для фотографов и моделей, его автор, стартапер Уильям Апшоу на этапе разработки понял, каких функций не хватает. Список задач увеличился, мы сделали повторную оценку и сдвинули дату релиза. В итоге бюджет подрос, но мы разработали соцсеть для профи из фотоиндустрии в полном соответствии с требованиями клиента.
На выходе:
Действие второе — Aналитика
Аналитика не всегда входит в процесс разработки мобильного приложения. Бывает, что клиенты самостоятельно выполняют бизнес-анализ приложения, либо приходят с готовым списком требований. Но те приложения, которые прошли этот этап у компании-разработчика, выигрывают, — именно аналитика помогает бизнесу и разработчикам достичь единого видения, и уже на основе этого сделать переоценку требуемых работ и получить детальный бюджет проекта.
Бизнес-аналитики в Azoft выявляют требования к мобильному приложению, предлагают варианты реализации, строят схемы взаимодействия пользователя с приложением, создают основу UI — wireframes.
Большую работу провели наши аналитики на проекте для крупной сети супермаркетов. Заказчик искал способ, как через приложение мотивировать покупателей на дополнительные покупки. Мы проанализировали возможные пути решения и предложили наиболее эффективный вариант — интегрировать в мобильное приложение систему рекомендаций. Программа на базе AI советует пользователям товары на основе их предпочтений и истории покупок.
На выходе:
Действие третье — Дизайн приложения
Иногда клиенты приходят с готовым дизайном. Если дизайна у заказчика нет, мы создаём UI/UX с нуля. Когда аналитик передаёт дизайнеру основу графического интерфейса, вайерфреймы, мы приступаем к визуальному дизайну. Отрисовываем карту экранов, графические элементы, детализированный прототип с учётом различных сценариев использования.
На этом этапе UI/UX дизайнер создаёт статичные прототипы и, по запросу клиента, интерактивные прототипы приложения. Так мы показываем, как будет выглядеть приложение и какого поведения от него ожидать с учётом запланированных фич. Всё зависит от конкретных задач и пожеланий клиента.
Во время отрисовки дизайна приложение обретает свой будущий облик. Здесь очень важно получить обратную связь от бизнес-аналитика и клиента, чтобы дизайн мобильного приложения в полной мере отвечал требованиям.
На выходе:
Действие четвёртое — Разработка
Когда есть развёрнутое ТЗ и оценка, готов дизайн и утверждён прототип мобильного приложения, начинается хардкор. Команда разработчиков пишет код, чтобы реализовать запланированное поведение приложения и соединить логику приложения с серверной частью, если она предусмотрена. А также мы воплощаем готовый дизайн в коде — прописываем все стили и элементы UI, с которыми взаимодействует пользователь приложения.
В нативной разработке мы применяем языки Java и Kotlin для Android, Objective-C и Swift для iOS, и самые современные фреймворки и библиотеки. В кроссплатформенных решениях работаем с React Native и NativeScript.
Как только часть функционала разработана, мы её тестируем и продолжаем трудиться над остальными функциями.
Важно во время разработки, когда сверстали дизайн, подключить дизайнера. Дизайнер проверит, насколько хорошо разработчики реализовали скрины приложения: все ли стили соответствуют выбранным, тот ли выбран цвет, каково соотношение сторон, как скруглили углы и т.д.
На выходе:
Действие пятое — Тестирование и багфиксинг
QA инженеры Azoft подключаются к проекту на старте и тестируют так часто, как только возможно. Это гарантирует высокий уровень качества и помогает клиенту не раздуть бюджет.
На этапе оценки мы тестируем ТЗ. Параллельно с разработкой пишем тестовую документацию, например, тест-кейсы. Когда часть функционала готова, начинается тестирование. Все баги вносим в систему баг-репортинга, после исправления проверяем, что баги пофиксили и это не повлияло на остальной функционал. Перед релизом приложения делаем приёмочное тестирование: проходим основные бизнес-кейсы приложения, чтобы убедиться — поведение приложения соответствует тестовой документации и требованиям клиента.
Когда мы разрабатывали StoryApp — приложение для чтения коротких рассказов, заказчик не сразу определился, какие функции будут в приложении. Мы описали тестовую спецификацию с подробными характеристиками экранов и фич на основании озвученных требований клиента. Когда же во время разработки появились новые функции, например, покупки в приложении, мы были к этому готовы — расширили тестовую спецификацию непосредственно в разгаре проекта.
На выходе:
Действие шестое — Релиз
Когда серия тестов и доработок приложения завершена, а разработчики, аналитики, тестировщики и дизайнеры дружно одобряют результат, приходит время добавить приложение в магазин приложений — Apple App Store, Google Play или любой другой сервис по желанию клиента.
Чтобы приложение прошло ревью сторов, клиент может обратиться к разработчикам за помощью в релизе, а может подготовить и выложить приложение в магазин самостоятельно.
На выходе:
Действие седьмое — Техподдержка и развитие
После публикации мобильного приложения его история не заканчивается. Если клиент обнаруживает баги после релиза, мы их фиксим. Если же первые месяцы жизни приложения показывают, где и что нужно допилить или переделать, есть два варианта: заключить договор на сопровождение или запустить новую фазу разработки с учётом новых переменных.
На выходе:
Эпилог
Разработка мобильного приложения это непросто. Нет такой схемы “Раз-два, и готово”. Многие этапы могут пересекаться друг с другом или идти параллельно. Инстаграму потребовалось больше трёх лет, чтобы стать удобным и любимым миллионами приложением. И они до сих пор продолжают вносить улучшения и добавлять новые фичи. Перед тем как фантазировать, куда вы вложите деньги от продажи своего приложения IT-гиганту вроде Google, приготовьтесь — будет много работы. Смотрите действие первое.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.
Разработка мобильных приложений: с чего начать
В нашей работе мы проходим все стадии жизненного цикла создания мобильного приложения, и я бы хотел поделиться нашим опытом в этой сфере. Под катом — рассказ об основах мобильной разработки: от выбора платформы до создания, размещения в магазине и последующего мониторинга.
Тенденции
Чем пользуются владельцы мобильных телефонов?
Статистика
За 2012 год в РФ продано порядка 12,6 миллионов смартфонов: Россия считается одной из быстроразвивающихся в этом плане стран.
Если взглянуть на такой же график по всему миру, то увидим, что и тут Android в авангарде с ¾ рынка.
За второй квартал 2012 года по всему миру было продано 104 миллиона телефонов Android — как население довольно крупной страны. Но нас как мобильных разработчиков интересует не только наличие смартфона, но и то, как с ним работают. Существенная доля обладателей устройств на Android пользуется ими как обычными телефонами: SMS, звонки — и все. Они не активируют устройство в Google Play, не скачивают приложения.
Не все люди обзавелись телефонами в 2012 году, поэтому реальное распределение сил среди мобильных операционных систем демонстрирует наша внутренняя статистика. В эту статистику входят Россия и страны СНГ: Украина, Белоруссия, Казахстан, Узбекистан.
Установка приложений
При выборе платформы, под которую будет разрабатываться приложение, важно знать статистику по уже существующим приложениям. Графики исследовательской компании App Annie от сентября 2012 года показывают, как растут два конкурирующих магазина Apple и Google.
По количеству скачиваний на первом месте Google Play: больше устройств, больше скачиваний, больше трафика и рост при этом +66% по сравнению с январем 2012 года. Рост iOS оказался в два раза меньше, порядка 30%. Но главный график – какую выручку приносят пользователи. И здесь ситуация в корне иная. Проще зарабатывать на iOS, но деньги есть и в Google Play, если уметь их забирать.
Типы мобильных приложений
На практике можно разделить приложения для мобильных устройств на три типа.
Мобильные сайты, веб-приложения
Это самый распространенный тип приложений для мобильных устройств. Современные смартфоны в состоянии отобразить обычный сайт. Им доступно все то, что мы привыкли видеть в десктопных приложениях — поддержка HTML5 делает свое дело. Помните, что веб-приложения отлично подходят для стартапа: именно они позволяют получить большой результат за маленькие деньги и за небольшой срок. Еще один плюс мобильного сайта по сравнению с другими мобильными приложениями – это кроссплатформенность. Однако есть и минус, притом весомый: с ними достаточно сложно заработать.
При таком подходе вы получаете доступ ко всем плюсам API операционной системы: приложение обрастает push-уведомлениями и другими приятными плюшками, кроме того, теперь ваш продукт можно размещать в сторах. При этом основной контент все еще представляет собой платформонезависимую страничку с версткой, размещенную на сервере. Это позволяет вносить косметические изменения в продукт без выпуска новой версии: достаточно залить изменения на сервер. Гибридные приложения – отличное решение для тех, кто начинает бизнес или хочет проверить свою идею, показать ее инвестору, друзьям.
Этот вид приложений самый ресурсоемкий, но вместе с этим он позволяет по максимуму использовать возможности, предлагаемые каждой конкретной операционной системой. Как следствие, нативные приложения выигрывают как по функционалу, так и по скорости работы у других типов мобильных приложений. Именно к такому подходу сейчас приходят те компании, которые делали комбинированные приложения. Например, Facebook начинала с комбинированного приложения: нативные контролы (переключатели, вкладки и так далее) и веб-страница в качестве контента. Несмотря на то, что это неплохое решение, проблемы с производительностью приводят к тому, что разработчики отходят от комбинации с вебом.
Статистика
Приведу статистику скачиваний на примере наших мессенджеров.
Во-первых, у нас есть приложение ICQ, которое постоянно развивается: среди последних изменений стоит отметить аудиозвонки. Второй мессенджер Mail.Ru Group – Агент. В Агенте реализован примерно тот же функционал, и, хотя у него была немного другая история развития, мы выпускаем версии практически под все платформы и его можно найти в любом сторе.
Основная разница между двумя этими приложениями – это их аудитория. ICQ – это международный продукт. Программа скачивается не только в России, им активно пользуются жители Европы, Латинской Америки. Агент же изначально делался в России и для русскоязычных пользователей.
Тем интереснее сравнить статистику скачиваний из магазинов.
Большая часть 62% иностранной аудитории идет в Google Play. Примерно 1/5 идет в AppStore, 14% — в Ovi Store. И уже оставшиеся 5% делят магазины для платформ Windows Phone (4%) и Samsung Bada (1%). С Агентом ситуация в корне другая: доли Google Play и Ovi примерно одинаковые. Ну а 10% AppStore наглядно демонстрируют любовь к «яблочной» продукции в нашей стране.
Процесс создания мобильного приложения
Итак, перейдем к самому вкусному: процессу разработки мобильного приложения.
Прежде всего, необходимо определить, что и для кого мы пишем. Ответы на эти вопросы оформляются в User Story. На картинке вы можете посмотреть на реальный тикет в нашем трекере. Он описывает, как существующий пользователь ICQ может войти в приложение, и какие проблемы он может встретить. На этом этапе важно проработать все возможные сценарии, чтобы не было неприятных сюрпризов на более поздних этапах разработки.
Важно понимать, что за каждым пунктом в вашем to-do листе скрывается огромный айсберг функционала. Старайтесь фрагментировать и конкретизировать задачи. Крупные хотелки лучше всего разделить на несколько этапов (релизов в стор). Однако это тема отдельной дискусии, вернемся к этапам создания приложения.
Проектирование и дизайн
После составления User Story начинается проектирование и разработка дизайна.
На этом этапе мы используем прототипы, которые мы вешаем на доску и стрелочками показываем, как будет происходит навигация.
При разработке дизайна обязательно используются гайдлайны.
Гайдлайн в общем понимании – это документ, который выпускает компания, и по которому дизайнеры и разработчики понимают принцип построения взаимодействия приложения с пользователем. Условно говоря, для iOS кнопки надо делать круглыми, а для Windows Phone – квадратными. Однако мы используем и внутренние гайдлайны для разработчиков. Таким образом результат работы дизайнера чаще всего состоит из макетов, гайдлайнов и нарезки графики.
Макеты лучше всего подавать «перелинкованными», например с помощью ProtoTypr, чтобы была понятна логика переходов. Гайдлайны содержат в себе информацию об отступах, размерах, визуальных эффектах, механике анимации и пр. Этот этап можно пропустить, если в вашем проекте один дизайнер и один разработчик, сидящие рядом друг с другом. Третья часть результата — нарезка графики — должна содержать минимум необходимых графических ресурсов (заботимся о весе приложения), иметь версии для разных разрешений экранов. Чаще всего мы рисуем для ретины и xhdpi-экранов. Далее идет подготовка для неретины и mdpi автоматизированными средствами (если допустимо их использование). Чаще всего руками приходится готовить hdpi-ресурсы.
Передача в разработку. Обсуждение и необходимые правки описания
После получения макетов, гайдлайна и нарезки, начинается работа разработчика. Мы передаем в разработку все то, что придумали, и ожидаем ранний результат. Это не значит, что работа над архитектурой и пользовательским интерфейсом закончена. Иногда у разработчиков появляются интересные идеи, которые вносят коррективы в изначальный план. Когда разработка завершена, наступает стадия тестирования.
Существует немалое количество способов протестировать приложение.
В мобильной разработке тестировщик – это человек, вокруг которого одни телефоны. У нас есть огромный шкаф, в котором лежат как старые телефоны, так и самые свежие новинки. Внутри мы стараемся тестировать по тест-кейсам. Если внедряется новая фича, по ее описанию составляется тест-план.
Существуют сервисы, помогающие в тестировании. Мы используем HockeyApp – приложение, позволяющее раздавать наш продукт бета-тестерам. Мы пишем в социальных сетях: «Ребята, у нас новое крутое приложение. Кто хочет попробовать?» Желающие получают билд, пользуются приложением, а сервис собирает статистику, составляет креш-репорт и отправляет все это нам.
Также есть сервисы, позволяющие протестировать приложение на разных операционных системах — например, все Android-прошивки версии 2.1 или 2.3. Вы отдаете приложение, сервис скриншотит весь путь, который вы задали, присылает картинки вам на почту, и вы проверяете, все ли в порядке.
Итак, вы разработали, протестировали приложение, залили его в стор. Для отслеживания статистики скачиваний можно использовать сервис Distimo. Он показывает статистику по пользователям, которые приходят в стор, чтобы скачать приложения, и агрегирует комментарии.
Важно понимать, что люди более склонны оставлять негативные комментарии. Если у человека все хорошо, он чаще всего просто пользуется приложением, не комментируя. При стабильной работе наших приложений мы получаем 40-50 комментариев ежедневно. В день ошибки количество записей может доходить до 400 на одной платформе. Поэтому имейте в виду, что комментарии – это не полная оценка вашей работы, скорее еще один баг-трекер.
Изменить ситуацию может довольно распространенных «хак» — окно Rate Us. С предложением оставить положительный комментарий в сторе, а в случае проблем написать разработчику. Эффект достаточно сильный, главное — правильно продумать алгоритм показывания диалога юзеру.
Помимо комментариев Distimo показывает количество скачиваний, заработанные деньги, а также откуда скачивают ваши приложения.
Еще один интересный мониторинговый сервис – Flurry. Он помогает собирать клиентскую статистику. Flurry предоставляет отчет о том, что делает пользователь в вашем приложении: сколько раз он нажал на кнопку, сколько раз возвращался в приложение и более общие параметры — аудитория, география, пол, возраст и пр.
В некоторых мобильных продуктах мы также используем подсчет клиентской статистики с помощью Google Analytics. Разницы при сравнении с Flurry нет практически никакой. Минусы в скорости работы и обработки логов есть в обоих случаях, однако, если вы привыкли работать с гугловским интерфейсом, можете использовать этот инструмент.
Несмотря на большое количество сторонних сервисов, у нас есть собственная статистика. Какими бы хорошими не были внешние источники, их нужно проверять. Мы способны сами оценивать статистику, но для этого необходимо строить инфраструктуру для генерации отчетов, еженедельной отправки отчетов по email и других вещей, упрощающих жизнь. Поэтому нам проще использовать такие сервисы, как Flurry и Distimo, а к внутренним логам обращаться при возникновении вопросов. Наша практика показывает, что такой подход оправдан: периодически наши данные и данные сервисов несколько разнятся. Если вы склонны проверять статистику, используйте разные источники.
Специфика
Заключение
Я постарался рассказать вам о базовых особенностях и подводных камнях мобильной разработки, которые встречались нам на нашем пути. Надеюсь, пост оказалась вам полезным. Если у вас остались вопросы по теме, или вы знаете что-то, что может быть полезно нам, давайте обсудим это в комментариях.
Как разработать мобильное приложение для своего бизнеса и не разориться
Когда бизнес заказывает мобильное приложение, есть риск переплатить или слишком сэкономить. Если переплатить, приложение может не окупиться и ударит по бюджету компании. Если слишком сэкономить, есть риск на выходе получить бесполезный и нефункциональный кусок кода.
Мы в компании Neti занимаемся разработкой мобильных приложений и хотим рассказать, как соблюсти баланс между экономией и функциональностью: потратить минимум денег и получить все, что нужно.
На стоимость разработки мобильных приложений влияют 5 критериев:
Дизайн. Чем больше у приложения экранов, пунктов меню и разделов, тем дороже дизайн.
Функционал. Здесь все также: чем больше функций, тем дороже. Калькулятор, платежи, работа с файлами, чат, подключение карт — каждая функция увеличивает стоимость приложения.
Работа на разных платформах. Если приложение нужно только для одной платформы, его стоимость будет ниже. Если нужно, чтобы оно работало и на iOS, и на Android, есть два пути:
Разработка серверной части. Если она есть или нужно подключиться к готовой системе, например, 1С, это проще и дешевле. Если нужно разрабатывать серверные механизмы, это сделает разработку дороже.
Например, нужно приложение для сотрудников розничной сети, которое показывает информацию о товарах по ценнику. Это приложение должно подключаться к серверам, где хранятся данные о товарах и с помощью машинного обучения распознаются фото ценников. Если серверная часть готова, разработать приложение будет проще и дешевле. Если ее нет, придется писать такой функционал и разработка выйдет дороже.
Тестирование. Его стоимость зависит от количества экранов и от функционала приложения.
Чтобы лучше объяснить разницу между недорогим и дорогим приложением, возьмем два примера из нашей практики.
Нам нужно было за короткий срок работать легкое и удобное мобильное приложение. Все нужные для него функции были простыми и недорогими: каталог, интеграция с картами и интернет-магазином Ленты. Для всего этого есть стандартные решения, так что разработать такое просто. Кроме того, мы сделали приложение кроссплатформенным, что помогло сэкономить еще больше.
Заказчику нужно было мобильное приложение для контроля строительства и подрядчиков. Приложение получилось дорогим из-за того, что нужны были сложные нестандартные функции: загрузка поэтажных планов из ПДФ, редактирование этих планов, обработка замечаний, синхронизация, формирование отчетов, графики и поддержка офлайн-режима. Все это нельзя было реализовать в кроссплатформенном приложении, так что мы писали два разных кода для iOS и Android. Это и сделало приложение дорогим.
Подробнее об этом мы рассказывали в кейсе у нас на сайте.
Ниже мы говорим об экономии не в ущерб качеству. Даже если вы сэкономите, вы все равно получите качественное, рабочее и функциональное приложение, удобное для пользователей. Просто приложение не будет идеальным — но зачастую идеал и не нужен.
Не добавлять лишние функции. В приложения часто добавляют функции, которые кажутся крутыми, но на самом деле не нужны. Чтобы минимизировать бюджет, на старте должен быть только критичный функционал, который решает основную задачу приложения. Универсальных советов здесь нет — все зависит от ситуации.
Например, в приложении по доставке еды из супермаркетов обязательно нужна карта, корзина, платежные инструменты, интеграция с интернет-магазином супермаркетов. А вот без отзывов или отображения иконки курьера на карте на старте точно можно обойтись.
Другой пример с приложением застройщика. На старте мы планировали добавить разные слои объектов: с пешеходными дорожками, экстерьером, деревьями или коммуникациями. Эти слои можно было бы включать и отключать. Но по факту оказалось, что этот функционал не нужен: всегда необходимо видеть полную картину, и отключать слои нет смысла. Если бы мы не анализировали поведение пользователей, понять это бы не получилось.
Еще заказчики часто просят добавить в приложение офлайн-режим: чтобы все работало без связи с сервером. На практике такое нужно очень редко, например, если это приложение для инженеров, которые работают в подвале. В остальных случаях ничего страшного не произойдет, если приложение не будет работать офлайн: мобильный интернет есть везде.
Заменять сложные решения простыми. Некоторые функции в приложении не обязательно разрабатывать — можно использовать простые и готовые решения.
Например, многие клиенты хотят, чтобы в приложении был чат. Кажется, что это просто, но на самом деле разрабатывать реально удобный чат достаточно долго, сложно и дорого. Гораздо лучше оставить ссылку на Whatsapp или Telegram и переводить человека туда. Над популярными мессенджерами уже не первый год работают сотни программистов, они поддерживают чат-ботов и легко интегрируются с CRM — и все это почти бесплатно.
Другой пример: оплата прямо в приложении. Ее можно серьезно упростить: сделать оплату через веб-сайт, чтобы окно подтверждения открывалось внутри приложения. Это быстро, удобно для пользователя и гораздо дешевле интеграции с платежными системами.
Выбрать не столичное, а региональное агентство. Работа крупных московских агентств стоит дорого: дизайнерам и разработчикам там платят больше. Чтобы сэкономить, лучше обратиться в хорошее региональное агентство — так вы получите приложение за меньшие деньги, но не потеряете в качестве и функционале.
Даже если вы московская компания, приложение можно заказать в регионе: удаленно подписать договор, общаться и передавать все результаты без личных встреч.
Neti — как раз такая компания. Мы нанимаем программистов и дизайнеров из регионов, платим им больше, чем в среднем получают IT-шники в их городах — и все равно получается дешевле, чем в Москве. В итоге стоимость приложения тоже получается ниже.
Собрать больше материалов для дизайнера. У вашей компании наверняка есть брендбуки, логотипы и другие графические материалы. Многое из них можно использовать в разработке дизайна приложения, чтобы не пришлось все продумывать и рисовать с нуля. Если вы соберете такие материалы заранее и предоставите студии, разработка приложения будет стоить дешевле.
В разработке есть критичные вещи, на которых экономить нельзя категорически. Из очевидного: базовые функции, без которых приложение не будет работать. Нельзя сделать приложение по доставке еды и не добавить туда корзину.
Но есть четыре вещи, на которых вроде бы сэкономить можно, но мы этого делать не рекомендуем:
Предварительное исследование рынка и потребностей пользователей. Важно обязательно понять, кто целевая аудитория приложения, какой функционал критически важен, как работают приложения конкурентов и какие процессы нужно автоматизировать с помощью приложения. Это стоит денег: может потребоваться провести анкетирование или опрос или заплатить маркетинговому консультанту. Но без этого есть риск создать приложение, в котором будет десяток лишних функций и ни одной нужной.
Важно, чтобы со студией общался не только начальник или менеджер, но и маркетолог, который погружен в задачи проекта и хорошо понимает его целевую аудиторию.
Дизайн. Даже идеальный функционал не сработает, если приложение будет некрасивым и неудобным. Дизайн — лицо приложения, его основа. В дизайне нельзя игнорировать принципы разработки интерфейсов — приложение будет выглядеть дешево и не понравится пользователям.
Тестирование. Чтобы сэкономить, есть соблазн пропустить этот этап: вроде бы все работает, все хорошо, приложение можно выпускать. Но так делать категорически нельзя: в процессе работы могут вскрыться какие-то критические ошибки и дыры в безопасности, которые принесут компании крупные убытки. Да и пользоваться приложением, которое постоянно ломается, никто не будет. Поэтому мы никогда не убираем тестирование из сметы и не рекомендуем на нем экономить.
Напишите в комментариях, знаете ли вы еще какие-то моменты, на которых можно сэкономить, а на которых не стоит. Может, мы что-то упустили? Было бы здорово посмотреть на опыт других разработчиков или услышать отклик от потенциальных заказчиков.