11 июля 2008 года компания Apple объявила о запуске магазина приложений App Store – обновления для iTunes Store. У пользователей iPhone и iPod появилась возможность устанавливать через магазин проверенные приложения сторонних разработчиков.

В октябре этого же года компания Google запустила свой сервис Android Market для мобильных устройств под управлением Android.

Спустя несколько месяцев, в апреле 2009 года компания RIM объявила о запуске App World для BlackBerry, а в октябре 2010 в гонку включилась компания Microsoft со своим сервисом Windows Phone Marketplace для устройств под управлением Windows Phone 7.

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

Доступность сторонних приложений сделало мобильное устройство незаменимым инструментом для решения задач – волшебной шкатулкой, с помощью которой можно занять свободное время чтением или играми, почитать последние новости или купить билеты в кино. Определить спелость арбуза по издаваемым при простукивании звукам – запросто! Посветить фонариком в темном подвале – само собой! Узнать, что это там за бар на другой стороне площади – будет исполнено! Навигация, управление голосом, доступ к справочной и личной информации, дополненная реальность, NFC-метки – все это уже реально и может лежать у вас в кармане. Поэтому неудивительно, что все больше и больше людей желают приобрести себе такую шкатулку.

У бизнеса появилась еще одна площадка для привлечения клиентов и, в первую очередь, это касается компаний, деятельность которых связана с распространением медиа-контента и услуг через интернет. Одним из ярких примеров выхода на рынок мобильных приложений в России стало появление в стандартной поставке серии телефонов марки LG под управлением Android приложения-гида “Афиша”, разработанного для издания компанией Энтерра. Мы также помогли выйти на рынок компании Mail.ru со своим Агентом для iOS и, чуть позже, компании Rambler с приложением “Rambler News”.

Для разработчиков игр, поставщиков медиа-контента и интернет-услуг присутствие в магазинах приложений стало обязательным, как в свое время присутствие в интернете. Бурное развитие и постоянное расширение аудитории пользователей мобильных приложений привело к привлечению внимания остальных областей бизнеса к развивающемуся рынку. Компании, ранее использовавшие интернет как сопроводительный информационный ресурс своего реального бизнеса, также стали появляться в магазинах, перенося в приложения часть функций своих сайтов вкупе с интерактивными фишками и развлекательными промо-акциями.

Доставка еды, презентация банка или промышленного предприятия, бронирование номеров в отеле, каталог продукции для магазина или агентства по продаже недвижимости – у многих компаний появилось желание попасть в мобильные устройства пользователей.

Причин у этого желания несколько:

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

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

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

Необходимость нового канала предоставления клиентам информации о себе

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

После определения преимуществ может оказаться, что предлагаемый функционал идентичен функционалу мобильной версии сайта, а желание отправлять пользователю push-уведомления о новых поступлениях товаров окажется дорогостоящим и не приведет к желаемому эффекту. В этом случае имеет смысл в качестве первого шага выпустить мобильную версию сайта. Тем более что, например, браузер Safari в iOS позволяет вынести ярлык в список приложений, дав быстрый доступ к вашему сайту. И было бы неплохо сообщить пользователю об этом на основном сайте. Такой подход позволяет поэкспериментировать с функционалом, проследить за реакцией пользователей и определиться с дальнейшими действиями в рамках разработки непосредственно самого мобильного приложения.

Стремление не отстать от конкурентов

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

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

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

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

Рекомендую проанализировать приложения конкурентов, определить их сильные и слабые стороны, почитать отзывы пользователей в магазине приложений. Иногда только по отзывам можно определить, что приложение не нашло своих пользователей.

Намерение расширить клиентскую базу

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

Желание продемонстрировать свой статус

Тут все просто. Если есть желание и некоторая сумма, которую можно потратить, не задумываясь об экономическом эффекте, то почему бы и нет.

Развитие нового направления бизнеса на основе мобильного приложения

Чаще всего это означает желание создать собственный интернет-бизнес по подобию уже существующих сервисов или воплотить в жизнь оригинальную идею.

В первом случае необходимо понимать, что наличие схожих сервисов на рынке не только не уменьшит стоимость разработки, а наоборот, увеличит ее. Даже если заказывать продукт у подрядчика, уже имеющего опыт разработки в данном направлении. Это связано с тем, что подрядчик обычно передает все права на исходный код клиенту после завершения проекта и не может использовать его повторно. Необходимо будет увеличить или качественно изменить функционал приложения, чтобы сделать его конкурентоспособным, что также отразится на стоимости. И самое главное, нужно быть готовым к тому, что чем больше на рынке подобных приложений, тем больше времени понадобится на наращивание клиентской базы и тем больше денег должно быть заложено в рекламный бюджет.

В случае с оригинальной идеей также есть свои подводные камни.

Во-первых, идея должна быть логически завершенной. Возможно, без привязки к платформе и техническим тонкостям, но обязательно с прозрачной логикой работы.

Во-вторых, ее стоит проверить на оригинальность.

В-третьих, проверка на реализуемость. Далеко не всегда платформа позволяет реализовать то техническое решение, на котором строится идея. Тут лучше прибегнуть к исследованиям специализированной фирмы. Это стоит денег, но если вы настроены серьезно, это может сэкономить средства еще на начальном этапе проекта. Рекламную компанию также следует учесть в бюджете проекта.
В обоих случаях нужно проследить за тем, чтобы после расчета бюджета ожидаемая прибыль от приложения смогла покрыть расходы на его продвижение и развитие.

Желание повысить лояльность клиентов

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

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

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

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

Донести цели проекта до подрядчика

Будет очень хорошо, если вы сможете донести цели разработки до представителей компании-подрядчика перед началом работ. От этого во многом зависит правильность оценки проекта. К тому же есть вероятность, что после озвучивания целей проекта разработчики предложат вам альтернативное решение задачи, основываясь на своем опыте. Для вас это означает сигнал к тому, что вашим проектом интересуются, готовы потратить время на ваши проблемы и рассматривают вас в качестве возможного делового партнера.

Выразить свое видение проекта

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

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

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

Указать сроки и расставить приоритеты

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

• отсутствие опыта подобных разработок у разработчика;
• наличие опыта у разработчика, позволяющее судить о реальных сроках разработки;
• отсутствие достаточных ресурсов у разработчика;
• разница в ожидаемых сроках и предложенной оценкой из-за различного видения задач.

Так как, скорее всего, в конкурсе участвуют несколько подрядчиков, следует попросить их предоставить детализированную оценку трудозатрат и прокомментировать ее. Очевидно, что если из четырех компаний три сообщили о невозможности уложиться в заданный срок, а одна обещает закончить проект на две недели раньше, последняя компания не может оценить объективно сроки из-за отсутствия опыта, либо не учитывает важные нюансы. Сотрудники этой компании, конечно, могут оказаться профессионалами, но на вашем месте я бы поинтересовался у других компаний, в чем именно они видят сложности и потом узнал у компании-оптимиста, как ее разработчики собираются решить данные проблемы в указанные сроки.

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

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

Уделите время техническому заданию. В рамках подготовки контракта составляется так называемое SOW – Scope of Work, это краткий список требований к приложению. Для небольших и средних проектов такого SOW вполне достаточно для начала работ. Для крупных проектов после заключения контракта стартует фаза подготовки технического задания.

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

В некоторых случаях после составления SOW оценка меняется, очень редко – в сторону уменьшения. Возможно, вы сами вышли из границ начальной постановки задачи. Возможно, по ходу уточнения требований стало очевидно, что предполагаемые ранее технологии, менее затратные, не могут быть использованы в силу объективных причин. Возможно, у подрядчика появилось решение, более трудоемкое в реализации, но позволяющее качественно улучшить функционал или значительно облегчить развитие приложения. Решать, продолжить работу или отказаться от дальнейших отношений – это вопрос вашего доверия к подрядчику. Но перед принятием решения я советую обсудить причины изменений. Если повышение оценки было вызвано необходимостью, подрядчик всегда сможет его обосновать.

Разобраться с дизайном

В зависимости от приложения, под дизайном понимается:

• проработка расположения стандартных элементов на экранах приложения и подготовка необходимого минимума – иконок, стартового экрана, подбор цветовой гаммы;
• добавление собственных элементов управления и отображения информации;
• подготовка полного набора экранов приложения в рамках отдельной дизайн-фазы.

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

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

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

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

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

Подготовить данные

Очень часто в рамках проекта требуется интеграция с базой данных, где хранится и обрабатывается информация, используемая в приложении. В рамках данной задачи разрабатывается спецификация обмена данными и затем по полученному документу проводятся работы на сервере. Разработка спецификации обычно ложится на подрядчика. Работы на сервере могут быть также проведены подрядчиком (тем же или сторонней фирмой), либо специалистами компании-заказчика. Спецификация API – достаточно формальный документ и реализовать по нему требуемый функционал не составит труда, если вы поддерживаете базу данных своими силами. Если нет – вам потребуется предоставить подрядчику доступ к серверу и заплатить за работу.

База данных может быть вновь созданная или уже действующая. Заполнение базы обычно ложится на компанию-заказчика, если в контракте не прописано иначе. При планировании даты старта проекта следует обратить на это внимание, так как приложение не может быть запущено, пока не будут доступны необходимые данные.

Для случая с уже действующей базой следует учитывать, что если в рамках приложения было решено добавить раздел с новостями или расширить описание продукта дополнительными полями, подготовка данных и заполнение этих полей также ляжет на заказчика. И, скорее всего, для заполнения расширенной БД понадобится новый интерфейс, а разработка такого интерфейса – отдельная задача, не входящая в рамки интеграции с приложением.

Определить ответственного за проект

Сама по себе необходимость распределить ответственность очевидна, однако не всегда это распределение сопровождается предоставлением достаточного количества времени на работу с подрядчиком и наделением представителя заказчика соответствующими полномочиями. Если срок является критичным, рекомендую согласовать календарный план работ и максимально разгрузить вашего представителя на время подготовки SoW и ТЗ, старта проекта и финального тестирования. На этих стадиях разработчикам необходима быстрая реакция на возникающие вопросы, иначе есть шанс затянуть старт проекта или не уложиться в сроки. Такой же риск возникает, если представитель заказчика не наделен полномочиями принимать решения по проекту или привлекать своих специалистов для решения запланированных задач – время на согласование может значительно сдвинуть сроки выпуска приложения.

Подготовиться к размещению приложения в магазине

Публикация приложения включает в себя следующие этапы:

• загрузка файла приложения;
• размещение информационных материалов;
• рассмотрение приложения администрацией и принятие его в магазин.

Каждая платформа прилагает детальные инструкции по публикации приложений. Загрузка файла делается по инструкции и обычно подрядчик берет эту задачу на себя.

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

Для ряда платформ после публикации приложение проверяется сотрудниками магазина. У Apple это может занять от одной до четырех недель, для RIM примерно столько же, у Microsoft до недели, Google принимает приложения без задержек.

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

Публикация приложения осуществляется через учетную запись разработчика. Обычно у подрядчика имеется такая запись. Можно разместить приложение от его имени, либо завести собственную учетную запись компании.

В первом случае подрядчик будет являться компанией-разработчиком, но при этом вы будете указаны в качестве владельца приложения. Минус подхода – если подрядчик по каким-то причинам не сможет поддерживать свое членство в портале разработчиков, вам придется публиковать приложение заново от своего имени, с потерей рейтингов и отзывов.
Вариант с собственной учетной записью лишен этого недостатка, но требует определенных денежных затрат и времени на регистрацию. Для Apple и Microsoft цена составляет $99 в год, для Google – разовый платеж $25, для RIM – бесплатно. На регистрацию лучше заложить две – три недели.

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

Надеюсь, эта статья прояснила некоторые вопросы и дала вам верное направление в развитии своего мобильного приложения. Удачи вам и вашим проектам!