Основатель студии 65apps Дмитрий Желнин написал колонку о том, как заказчик может сэкономить на разработке мобильного приложения. Автор привёл восемь вероятных способов экономии и рассмотрел типичные ошибки компаний, которые стремятся снизить затраты по мобильному направлению.

Мобильная разработка стоит дорого

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

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

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

Также свой вклад в высокую стоимость услуг, например, iOS-разработки вносит дороговизна девайсов: это и мощные рабочие Mac, и полный парк устройств для тестирования. Достаточно зайти на сайт Apple Store или Яндекс.Маркет, чтобы прикинуть возможный объем затрат.

Это лишь несколько причин, почему растет стоимость можно еще вспомнить все больший парк технологий, усложняющийся UI/UX, все более сложную аналитику и так далее.

Мне нужно приложение. Как сэкономить?

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

  • 25% менеджмент (пресейл, переговоры, работа в тендере, аккаунт-менеджмент, проектный менеджмент и так далее),
  • 45% разработка,
  • 30% тестирование, приемка.
  • Понимание структуры затрат помогает найти способы сэкономить. На самом деле, их не так уж и мало.

    Способ № 1: Нанять фрилансеров

    Экономия: 80%.

    Сложности: Фрилансеры не заинтересованы в вашем продукте. Совсем.

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

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

    В этом варианте нужно понимать: а) что вы хотите получить (фрилансер не будет у вас аналитиком или UI -дизайнером вы должны сами ему объяснять, что делать), б) все риски даже по аппруву у той же Apple ложатся на вас, в) для дальнейшего развития весь код придется выбросить и начать заново.

    Способ № 2: Менеджер проекта в штате + студия на аутстаф

    Экономия: 40%.

    Сложности: Трудно найти проджект-менеджера, вопрос уже его качества.

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

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

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

    Способ № 3: Найти маленькую региональную noname-студию

    Экономия: 40%.

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

    Это лотерея. И шансы выиграть совсем не высоки. 95% из них ни черта не умеют, сидят без заказов и готовы вам пообещать луну с неба, лишь бы вы им хоть что-то заплатили. На оставшихся идет форменная охота, недорогие маленькие регионалы с хорошей экспертизой нужны всем: крупным московским вендорам, заказчикам из США и Европы.

    Например, мы знаем одну маленькую студию, которая делает мобильные приложения давно и круто парни загружены заказами из Штатов с рейтом $50 в час на год вперед. Выводы делайте сами. Если повезет и вы таких найдете и они будет свободны сможете сэкономить до 40%. Но все равно нужно будет жестко контролировать работу менеджмента, обеспечение качественным тестированием и другие важные аспекты проекта. Важно как правило, в таких компаниях нет отдела поддержки. От слова совсем. То же самое и с отделом тестирования и обеспечения качества (QA).

    Рисков как таковых тут немного, проблема найти такую компанию.

    Способ № 4: Найти крупного регионального вендора

    Экономия: 50%.

    Сложности: Мало таких компаний, нет личного близкого общения.

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

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

    Здесь уже будет и определенное техническое совершенство: продуманная архитектура, качественный, поддерживаемый код, устойчивость к нагрузкам, нормальное тестирование, поддержка. Чего часто нет у таких студий, так это крутого UX/UI в регионе найти эти компетенции непросто.

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

    Способ № 5: Использовать кроссплатформенный движок

    Экономия: 3550%.

    Сложности: Грабли в кроссплатформенной разработке раскиданы повсюду.

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

    С кроссплатформой все совсем по-другому. Она делится как минимум на два типа: первый это просто web-view с сайтиком внутри, который напоминает мобильное приложение, второй более продвинутый вариант, когда все элементы интерфейса реализованы нативно, а вот логика как раз на ином, не нативном, языке.

    К первой категории относятся PhoneGap, Cordova и множество кроссплатформенных мобильных фреймворков. Из их плюсов таких решений скорость разработки. Поскольку все приложение полностью реализовано в виде дешевого и быстрого HTML, то и портирование заключается в том, чтобы просто запустить этот сайт в web-view на другой платформе.

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

    Во второй категории идет ReactNative, NativeScript, Xamarin. Из плюсов опять же высокая скорость разработки, нативные интерфейсные элементы, быстрая работа приложения, возможность подключения нативных библиотек и компонентов.

    Из минусов среднее комьюнити, необходимо разрабатывать кастомные элементы интерфейса нативно. Так как технология пока молодая, то бывают проблемы с поддержкой все очень бурно развивается и меняется на ходу. Возможно, позволит сэкономить 3550% от разработки на нативе. А может породить такой набор грабель, что проект вообще не дойдет до релиза. Кроме того, тут возникает и проблема первого метода скорее всего при переходе к большому приложению и большой разработке весь наработанный код будет выкинут на помойку.

    Способ № 6: Разбить работу на этапы

    Экономия: 2030%.

    Сложности: Вам надо понимать все происходящее.

    Это, наверное, самый неочевидный наш совет. Во всяком случае, когда мы предлагаем этот вариант нашим заказчикам, обычно все в восторге соглашаются и спрашивают а что, так можно было? Итак, мы разбиваем всю работу на три договора:

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

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

    Каковы риски в таком подходе? Вам все равно надо понимать, что написано в ТЗ. То есть необходимы минимальные знания в разработке, технологиях. Да, вам напишут ТЗ, но разбираться с ним надо будет самим, хоть и с помощью авторов. Иначе может получиться совсем не то, что вы хотели.

    Способ № 7. Вкладывайтесь в отношения

    Экономия: 2025%.

    Сложности: Долго.

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

    С этим мало что можно сделать, разве что с честными глазами рассказать подрядчику о том, что мы с вами надолго, проект будет развиваться, скоро будет версия 2.0, 3.0 и вообще вы заработаете на поддержке. И просить снижать цену иногда это работает.

    Способ № 8: Делайте только то, что нужно

    Экономия: 2050%.

    Сложности: Сам продукт.

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

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

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

    В заключение: как не надо экономить

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

    Итак, вот чего делать не нужно:

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

    Источник vc.ru

    Вступай в сообщества ITmentor Вконтакте и Facebook

    Помогла статья? Оцените её!
    0 из 5. Общее количество голосов - 0
     

    You have no rights to post comments

    Дмитрий Крикунов

    Публикую статьи, обучающие курсы и новости по программированию: алгоритмам, языкам (С++, Java), параллельному программированию, паттернам и библиотекам (Qt, boost).