Оффтоп Редакция vc.ru
12 123

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

#мобильные_приложения #как_надо #советы_бывалых #мобильная_разработка

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Редакция vc.ru", "author_type": "self", "tags": ["\u0441\u043e\u0432\u0435\u0442\u044b_\u0431\u044b\u0432\u0430\u043b\u044b\u0445","\u043c\u043e\u0431\u0438\u043b\u044c\u043d\u044b\u0435_\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","\u043c\u043e\u0431\u0438\u043b\u044c\u043d\u0430\u044f_\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u043a\u0430\u043a_\u043d\u0430\u0434\u043e"], "comments": 0, "likes": 21, "favorites": 0, "is_advertisement": false, "subsite_label": "flood", "id": 3004, "is_wide": true, "is_ugc": true, "date": "Sun, 23 Feb 2014 14:35:29 +0400" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Голосовой помощник выкупил
компанию-создателя
Подписаться на push-уведомления