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

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

***


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

The_Five_Mistakes_Startups_Make_When_Building_for_Mobile

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

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





МИФ #1: Нативное приложение для каждой платформы отдельно – пустая трата времени и денег


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

Кажется, что делать кросс-платформенное мобильное приложение выгодно. Один раз пишете код, и потом на каждый отдельный сайт выкладываете. Вроде просто и логично. Так же думали в свое время в FacebookLinkedIn и Southwest Airlines. Однако в свое время Марк Цукерберг признал, что слепая вера в возможности кросс-платформенного HTML5 стала одной из самых больших ошибок Фейсбука.

Те, кто осознал аналогичность своей ошибки, переписали приложения на нативные. А вот авиалинии Southwest по-прежнему пользуются универсальным приложением – и оно одно из худших в App Store.

Кросс-платформенность при мобильной разработке выбирают, как правило, те стартапы, у которых туго с деньгами и нет отдельной стратегии внедрения и продвижения для каждой мобильной ОС. Вместо того, чтобы нанять толковых спецов по нативной разработке, они начинают возлагать надежды на гибридные конструкторы HTML5 и всякие наборы для создания приложения «одного на все времена». Юзабилити, верстка и функциональность будут в итоге жалкими, но есть и другие недостатки:



  • 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. Также стоит работать с дизайнерами, привлечь специалистов разного уровня. Тестирование, отладка, внесение правок – при переходе в мобильную версию для вашего стартапа все они станут комплексными процессами, которые надо масштабировать по мере роста стартапа и привлекать для этого специалистов с обеих сторон. Со временем вы сможете осуществлять все эти процессы и самостоятельно.
null