[email protected]

+7 (920) 053-05-00

Разработка мобильных приложений. Публикация в AppStore и Google.Play

Разработка приложений «под ключ» – от идеи до публикации в Google.Play и AppStore.

В Stex Group мы осуществляем полный цикл разработки мобильных приложений под iPhone и Android. Вне зависимости от сложности и назначения приложения, процесс разработки состоит из одних и тех же этапов.

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

Оформление идеи

Вам нужно написать программу под iPhone, iPad или Android. Вы приходите к нам со своей идеей. Идея может быть в голове или на бумаге. Мы обсуждаем и формализуем идею, предлагаем оптимальные пути реализации и вместе составляем список базовых требований.

Исходя из этих требований определяем предварительный бюджет и примерный срок разработки. Если они вас устраивают – мы заключаем предварительный договор и берем аванс (обычно 30–35% от предварительно определенной стоимости).


   Зачем что-то формализовывать? Я и так могу все понятно объяснить и нарисовать!
Наличие согласованного списка требований позволяет убедиться, что мы говорим на одном языке и одинаково понимаем конечный результат. Зачастую бывает, что заказчик и исполнитель вначале совершенно по–разному понимают одну и ту же идею, что в результате приводит к отрицательному результату. Кроме того, бюджет и сроки рассчитываются, как раз, на основании утвержденного списка требований.

Некоторые фрилансеры (как правило — начинающие) готовы работать без документации. Результат подобных проектов непредсказуем. А мы работаем только с гарантированным положительным результатом.
   А почему вы сразу не можете назвать точный окончательный бюджет и сроки?
В первую очередь — потому, что как правило в начале у заказчика есть только очень общее представление о приложении, которое он хочет получить. А для вычисления стоимости разработки нужно представлять функционал приложения во всей его полноте. Первоначальную оценку можно сделать по списку требований, в дальнейшем оценка уточняется на основании выполненного прототипа и ТЗ. Можно провести параллель между созданием приложения и постройкой дома — чем точнее выполнена проектно-сметная документация, тем точнее можно посчитать стоимость.
   Почему я должен вносить аванс? За что платить, ведь вы еще ничего не сделали!
Разработка мобильного приложений под iOS или Android — сложный технологический процесс, требующий тщательного планирования. Разработка проектной документации (сюда входит создание прототипа и ТЗ) — неотъемлемая и очень важная часть проекта, которая точно так же как и программирование требует существенных трудозатрат. Как правило, это примерно треть стоимости проекта. Именно на эту сумму мы и взимаем авансовый платеж.

Создание прототипа и документации

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

Прототип приложения

Прототип приложения, выполненный в Axure RP

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


   Зачем нужен этот прототип? Можно ведь описать все в ТЗ на бумаге...
Наша цель — в конце проекта иметь не просто полное соответствие ТЗ, но и чтобы заказчик был удовлетворен результатом. Эти две вещи не всегда тождественны. Основная проблема ТЗ, как и любого статического документа — его статичность. Проект может полностью удовлетворять вас на бумаге, но пока вы не понажимали на кнопки и не походили между страницами приложения — никто не даст гарантии, что все нюансы учтены. То, что на бумаге казалось логичным и уместным — в реальности может оказаться совершенно непригодным для использования, или попросту неудобным.

Наличие прототипа – действующего макета – полностью снимает эту проблему. Вы можете начать пользоваться приложением еще до того, как оно будет написано!
   Какой именно функционал будет смоделирован в прототипе?
Все экраны реального приложения, навигация, переходы между экранами, действия на экранах. По сути, прототип — это действующая модель приложения.
   В чем вы делаете прототипы? Какие программы для этого используются?
Как правило, это Axure RP. В некоторых случаях мы создаем прототип при помощи тех же средств, что и само приложение — пишем его на Objective–C или Java.
   Что если я сам сделаю прототип и приду к вам с готовым решением?
Это будет просто отлично. Если прототип, сделанный вами будет в состоянии решить ту же задачу — описать функционал приложения — мы с радостью будем работать с ним.
   Что из себя представляет Техническое Задание (ТЗ)?
Техническое Задание (ТЗ) — это формальный документ, детально описывающий как приложение выглядит и как оно работает. ТЗ описывает работу приложения в целом, и каждый элемент на каждом экране по отдельности. Соответствие приложения Техническому Заданию является основным критерием готовности приложения, поэтому к составлению ТЗ мы подходим со всей возможной тщательностью.
   Я хочу заказать простое приложение. Давайте обойдемся без ТЗ, я так все расскажу.
Единственная возможность работать без ТЗ (это может быть целесообразно, например, в случае когда заранее известно что планы будут меняться постоянно и на ходу) — это почасовая оплата. Вы говорите, что делать - мы ежедневно выставляем вам счет за реально потраченное время.
   Что если после изучения прототипа я разочаруюсь в своей идее и решу не продолжать?
Случается и такое, что уже на стадии прототипа становится понятно, что идея или не принесет денег, или просто перестает нравиться заказчику. В таком случае вы просто не платите денег за основной проект, только авансовый платеж.

Программирование

Самый «скучный» для заказчика этап. Мы программируем приложение согласно ТЗ. На этом этапе никакие правки функционала уже не вносятся, однако промежуточные сборки приложения периодически (как правило – ежедневно) передаются вам для ознакомления.


   Сколько в среднем занимает программирование для мобильного приложения?.
В среднем 4–10 недель. Нужно понимать, что это очень в среднем.
   С помощью каких инструментов осуществляется разработка? Какие языки программирования вы используете?
Приложения под iOS (iPhone, iPad) мы пишем на Objective–С и C++, среда разработки — XCode. Приложения под Android мы разрабатываем на Java, в Eclipse IDE. Мы используем Git в качестве системы контроля версий и хранения кода и Jenkins — для непрерывной интеграции.
   Я слышал, что можно написать одно приложение и под iPhone и под Android сразу, и это будет дешевле и быстрее. Вы так можете?
Совершенно верно, есть кроссплатформенные библиотеки, позволяющие разрабатывать код одновременно для всех платформ. Они были разработаны в первую очередь для веб–программистов, впервые осваивающих мобильные платформы. К сожалению, практика показывает что у подобных систем больше минусов, чем плюсов — обратной стороной универсальности является неспособность поддерживать функционал, доступный родным (native) приложениям, низкая скорость работы, большой размер приложений. Все это в итоге приводит к низкому качеству программ - как под iOS, так и под Android. Поэтому мы подобными вещами не занимаемся.
   Каким образом я смогу поставить себе на iPhone или Android-устройство промежуточную версию? У меня есть коллеги, могут ли они тоже ее установить?
Исполняемый файл для Android достаточно записать во внутреннюю память устройства через USB кабель, или скачать по ссылке прямо из браузера. Вы можете установить его на неограниченное количество устройств.

Для установки тестовых приложений на iPhone мы использует TestFlight — простой и надежный способ установить тестовое приложение на ваш iPhone или iPad. В отличие от Android, тестовое (ad-hoc) приложение для iPhone строится для конкретного устройства, мы предоставляем возможность установки до трех устройств. Это ограничение связано с политикой Apple — у компании–разработчика есть ограничения на количество тестовых устройств.
   Что если пока вы пишете код, мне в голову пришла потрясающая идея, которая обязательно должна войти в приложение?
Мы обязательно добавим этот функционал в приложение — сразу после окончания и сдачи основной части проекта. На ходу, в середине проекта, никакие изменения не вносятся. Процесс разработки — это, по сути, конвейер; вы не можете менять дизайн детали, которую уже обрабатывает токарный станок. Если вы хотите получить другую деталь — нужны новые материалы (деньги, сроки).

Некоторые фрилансеры (как правило — начинающие) готовы вносить любые изменения в середине проекта, лишь бы заполучить заказ. Подобная практика, как правило, ведет к тотальному хаосу и краху проекта. А мы работаем только с гарантированным положительным результатом.
   При расчете стоимости вы указали срок на разработку в человеко-часах. Как я могу быть уверен, что ваши программисты все это время пишут мой код?
Сроки и бюджет проекта рассчитываются на основании количества нормо-часов на каждый блок приложения. В рамках договора мы гарантируем соблюдение общих и поэтапных сроков разработки и рамок утвержденного бюджета, вне зависимости от реального количества человеко-часов, затраченных на разработку. Можно провести аналогию с автосервисом, где стоимость работ зависит от количества утвержденных нормо-часов на конкретную услугу, вне зависимости от реально затраченного на нее времени.

Приемочное тестирование

Программирование заканчивается, и приложение передается вам для тестирования и проверки соответствия ТЗ. Приложение устанавливается на ваши тестовые устройства, и работает в точности так же, как если бы было скачано из Google.Play или AppStore. Все несоответствия и найденные проблемы исправляются на этом этапе.


   Каким образом я должен тестировать приложение?
Приложение тестируется на соблюдение всех требований, указанных в ТЗ. Если приложение каким-то образом не соответствует любому из пунктов ТЗ - оно в кратчайшие сроки дорабатывается за наш счет до полного соответствия. Если какой-либо функционал не описан в ТЗ (но подразумевается заказчиком) — он реализуется после приемки и оплаты основных работ за отдельную стоимость. Еще раз подчеркнем важность детального составления ТЗ: если какой-либо (пусть даже очевидный с точки зрения заказчика) функционал не описан в ТЗ - с большой долей вероятности его не будет и в приложении.
   Во время тестирования я нашел ошибку или несоответствие ТЗ. Что дальше?
После того, как отчет об ошибке или несоответствии будет передан нам — они будут устранены (приведены в соответствие с ТЗ) в кратчайшие возможные сроки.
   Сколько у меня есть времени на тестирование?
Как правило, срок отведенный на ПСИ (приемо–сдаточные испытания) составляет 10% от общего времени разработки. Некоторые проекты могут потребовать больше времени, в таком случае это отдельно оговаривается в договоре.
   Меня все устраивает, но я хочу добавить новый функционал до передачи в AppStore!
Нет проблем. Как только работы по основному договору приняты и оплачены — мы с радостью оценим и добавим дополнительный функционал до передачи продукта в AppStore / Google.Play. Важно однако понимать, что задержка приемки / сдачи основных работ из-за отсутствия функционала не оговоренного в ТЗ недопустима. Подобная ситуация отдельно оговаривается в договоре, и может служить законным поводом для разрыва договора.

Публикация

После приемки заказчиком приложения и подписания акта приемки - приложение передается в AppStore и / или Google.Play для публикации. Каждое приложение перед публикацией проверяется командами Google и Apple. Приемка в Google.Play, как правило, не занимает больше суток. Процесс приемки в AppStore занимает гораздо больше времени – не менее недели.


   Зачем вообще нужны эти AppStore? Почему нельзя разместить приложение на моем сайте?
Политика Apple прямо запрещает любые пути распространения приложений кроме как через AppStore (исключения составляют тестовые ad-hoc сборки и corporate distribution).

В случае с Android-приложением возможно распространять его прямо с сайта, однако аудитория Google.Play позволит добиться гораздо большего количества скачиваний. Кроме того, некоторые Android-устройства позволяют устанавливать приложения только из Google.Play.
   От чего зависит, примут ли мое приложение в AppStore и Google.Play?
Политика проверки приложений Android достаточно либеральная, приложения проходят лишь поверхностную проверку. Если приложение не содержит порнографии и других материалов, оскорбляющих общественную мораль — с большой долей вероятности оно будет принято в Google.Play.

В случае с AppStore приложения проходят очень жесткую проверку на соответствие Apple Review Guidelines. Этот документ из несколько страниц мелкого текста детально описывает требования, которым должно удовлетворять приложение — как с точки зрения внешнего вида и содержания, так и с точки зрения внутренней архитектуры и кода.

За последние несколько лет мы разместили в AppStore более 100 приложений наших клиентов. подобный опыт позволяет учесть все нюансы и в большинстве случаев избежать отказа в размещении. При этом около 10% приложений все равно проходят проверку в AppStore только со второго или третьего раза — эти риски следует обязательно учитывать при планировании маркетинговой стратегии приложения.
   Сколько занимает проверка приложения?
Проверка приложения под Android обычно занимает меньше суток. Ревью приложения в AppStore занимает 1-2 недели.
   А что, если приложение не пройдет проверку, такое бывает?
Да, около 10% приложений не проходят проверку Apple с первого раза. Это может быть по причине явного несоответствия Apple Review Guidelines (которые достаточно часто обновляются), либо по чисто субъективным причинам, например в случае различной трактовки этих правил разработчиками и сотрудниками AppStore Review Team. Так, в нашей практике были случаи, когда приложение отказывались принимать в AppStore потому, что оно (цитата) недостаточно возбуждает фантазию пользователя. В любом случае, если мы взялись за проект — мы гарантируем приемку приложения в AppStore.

Поддержка и развитие

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