5 ошибок стартапов, которые решили стать мобильными

Не всякий стартап способен перейти на мобильную платформу из веба (и не всякий стартап изначально существует как мобильное приложение). Как разобраться с проблемами и рисками при «мобилизации» и стоит ли превращать ваш проект в приложение для мобильных ОС? Об этом редакция ЦП
нашла интересную публикацию
, которой и хотим поделиться с нашими читателями.

***

В далеком 2009-м 
Фархан Тавар
 стал вице-президентом в компании по мобильной разработке 
Xtreme Labs
. На тот момент она управляла разработкой мобильных приложений и платформ для крупнейших брендов мира. Проекты были разной сложности и для разных аудиторий, но объединяло их одно: их надо было сделать «на вчера» и сразу добиться большого прорыва в указанном направлении.

Тренд на скоростную «мобилизацию» фактически появился сам собой из потребностей пользователей:
78% пользователей Facebook в США пользуются каждый день соцсетью с мобильника
. Для Twitter этот же показатель 
составляет 75%
, и выручка от мобильной рекламы – под 65%.

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

• HTML5: полная кросс-браузерная совместимость достигается с трудом и для каждой платформы всё равно требует доработки;


• Гибридные приложения: дополнительные слои и переключение между веб-слоем и надстройкой – короче, море возни и сбоев в работе;


• Кросс-платформенные конструкторы: надо писать кучу дополнительного кода, плюс есть кастомный код из конструктора, – в итоге, много «мусора».

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

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

Узнав, какой платформой пользуются ваши клиенты и ЦА, вы сможете определить и круг задач/решений, которые можно решить при помощи мобильного приложения. А тогда уже садиться за разработку конкретно для этой платформы. Лучше детально проработать одну платформу и сделать толковое одно приложение, чем распыляться на всё подряд.

MИФ #2: Ваша back-end инфраструктура уже готова для поддержки мобильных приложений

Реальность: Вам предстоит апгрейд, обновления и даже полная перестройка инфраструктуры.

У большинства компаний-разработчиков есть ложная уверенность, что вся готовая инфраструктура уже есть и для мобильных приложений ничего делать не надо. На самом деле надо подстроить свою базу «железа» под выбранные мобильные API, учесть трафик и нагрузки. Обычно при удачном внедрении рост трафика и нагрузок составляет до 200%. Даже смартфон сегодня потребляет трафика больше, чем иной ноутбук.При настройке и рефакторинге серверов для мобильных API нужно учесть ряд параметров:

• Максимальный размер загружаемых пакетов (до 4 КВ);


• Постраничное отображение и разделение;


• Повторные подключения (если падает сеть);


• Параметр Low latency;


• Число обращений к API для 1 экрана;


• Номер версии API в параметрах.

МИФ #3: Внутри компании можно создать мобильное приложение так же быстро, как и силами подрядчика извне

Реальность: Если будете писать приложение сами, потратите в 4 раза больше времени.

Ошибка стартаперов в том, что они верят в возможность справиться своими силами с приходом на мобильную платформу. Когда подрядчик говорит, что разработка займет месяц или 3 месяца, менеджер в стартапе отмахивается и говорит, что они возьмутся сами за дело. Иногда это даже происходит – но вместо 1 месяца потрачено 4 месяца минимум.

Не думайте, что если у вас в команде есть хорошие специалисты по HTML, CSS и javascript, то вы сами справитесь со всем за счет рабочего времени. Обычно на полноценную разработку надо нишевые навыки и умение тестировать мобильные продукты, писать специально мобильный интерфейс и обеспечить QA.

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

А также в компании, которая занимается разработкой мобильных пиложений по вашему заказу, есть возможность тестировать всё не на эмуляторах, а на конкретных устройствах, экранах и форм-факторах. Это вам не один тестировщик с одним айфоном и тремя эмуляторами на ПК.

Скорость разработки при этом не является приоритетной. Качество намного важнее.

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

Чтобы выбрать подходящего подрядчика, задайте ему немного вопросов:

• Как и когда компания-подрядчик приобрела опыт в качестве разработчика?


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


• Какие методологии разработки используются?


• Какие ошибки / неудачные проекты были у компании?

МИФ #4: Если отдаете разработку мобильного приложения на аутсорс, то вам ничего делать не придется

Реальность: Чтобы получить наилучший результат, клиенты должны плотно сотрудничать с подрядчиком.

Типичная ошибка стартапера: подумать, что кто-то «влезет в вашу шкуру» и примет решения или варианты дизайна ваших приложений такие, которое понравятся вам. Весь проект за вас подрядчик – даже самый талантливый – не сделает.

Надо работать в тесной связке с QA-командами подрядчика и привлекать как своих, так и сторонних менеджеров. Тесная работа позволит избежать ошибок и игры в «угадайку»: что вы хотели и что получили.

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

МИФ #5: Начав работать с одним разработчиком, вы застрянете с ним навечно

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

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

Сопротивление аутсорсингу мобильных приложений в стартапе – вещь типичная: боятся, что не смогут потом отвязаться от аутсорсера, а долгосрочное сотрудничество влетит в копеечку. Но хороший подрядчик не строит свою работу так, будто будет «доить» вас вечно. Нужно очертить сроки сотрудничества и темпы разработки, количество версий и обновлений, которые вы хотите выпустить совместно с подрядчиком. Тогда никто не будет чувствовать себя обязанным кому-либо.

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