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

 

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

 

 

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

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

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

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

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

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

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

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

25% менеджмент (пресейл, переговоры, работа в тендере, аккаунт-менеджмент, проектный менеджмент и так далее);

45% разработка;

30% тестирование, приемка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Экономия: 20—30%.

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

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

ТЗ+дизайн.

Разработка.

Развитие и поддержка.

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

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

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

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

Экономия: 20—25%.

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Источник vc.ru

 

 

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