8 способов сэкономить на разработке мобильного приложения
Основатель студии 65apps Дмитрий Желнин написал для vc.ru колонку о том, как заказчик может сэкономить на разработке мобильного приложения. Автор привел восемь вероятных способов экономии и рассмотрел типичные ошибки компаний, которые стремятся снизить затраты по мобильному направлению.
Мобильная разработка стоит дорого
Причины понятны: относительно молодой рынок, новая экономика, дисбаланс спроса и предложения - качественных разработчиков очень мало, а спрос на приложения колоссальный, в том числе западный.
Людей, способных выполнять проекты, например, на 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% из них ни черта не умеют, сидят без заказов и готовы вам пообещать луну с неба, лишь бы вы им хоть что-то заплатили. На оставшихся идет форменная охота, - недорогие маленькие регионалы с хорошей экспертизой нужны всем: нам (ау, 65apps ищет партнеров), крупным московским вендорам, заказчикам из США и Европы.
Например, мы знаем у нас в Ижевске только одну маленькую студию, которая делает мобильные приложения давно и круто - парни загружены заказами из Штатов с рейтом $50 в час на год вперед. Выводы делайте сами. Если повезет и вы таких найдете и они будет свободны - сможете сэкономить до 40%. Но все равно нужно будет жестко контролировать работу менеджмента, обеспечение качественным тестированием и другие важные аспекты проекта. Важно - как правило, в таких компаниях нет отдела поддержки. От слова «совсем». То же самое и с отделом тестирования и обеспечения качества (QA).
Рисков как таковых тут немного, проблема - найти такую компанию.
Способ № 4: Найти крупного регионального вендора
Экономия: 50%.
Сложности: Мало таких компаний, нет личного «близкого» общения.
«Крупные региональные вендоры» - это компании, похожие на нашу, вырастившие в регионе крупное производство, но не сумевшие самостоятельно - без посредников и интеграторов - войти в большие аккаунты. Нас нет в Москве, а значит, в тендерах МТС или X5 Retail Group нас нет.
Мы научились все это делать на субподряде и мечтаем работать уже с конечным заказчиком. В этом варианте можно неплохо сэкономить и получить качественный продукт. Как правило, до 50% от московских цен.
Здесь уже будет и определенное техническое совершенство: продуманная архитектура, качественный, поддерживаемый код, устойчивость к нагрузкам, нормальное тестирование, поддержка. Чего часто нет у таких студий, так это крутого UX/UI - в регионе найти эти компетенции непросто.
Проблемы такие же, как в предыдущем пункте - таких компаний мало, но они есть. Рейтинг мобильных разработчиков « Тэглайн» вам в помощь!
Способ № 5: Использовать кроссплатформенный движок
Экономия: 35-50%.
Сложности: Грабли в кроссплатформенной разработке раскиданы повсюду.
Делать проект можно нативными средствами, а можно на кроссплатформенном фреймворке. «Натив» позволяет решить практически любую техническую проблему, сделать приложение очень шустрым и красивым. Минус один - длительность и стоимость разработки.
С «кроссплатформой» все совсем по-другому. Она делится как минимум на два типа: первый - это просто web-view с сайтиком внутри, который напоминает мобильное приложение, второй - более продвинутый вариант, когда все элементы интерфейса реализованы нативно, а вот логика как раз на ином, не нативном, языке.
К первой категории относятся PhoneGap, Cordova и множество кроссплатформенных мобильных фреймворков. Из их плюсов таких решений - скорость разработки. Поскольку все приложение полностью реализовано в виде «дешевого и быстрого», то и портирование заключается в том, чтобы просто запустить этот сайт в web-view на другой платформе.
Минусы - «тормоза», присущие этому подходу, также иногда возникают проблемы с возможностью расширения и внедрения нестандартной функциональности, которые очень непросто решить, зачастую совсем не нативный интерфейс. В итоге такой вариант подходит для апробации идеи и позволяет сэкономить до 30-40% от разработки «родного» приложения.
Во второй категории идет ReactNative, NativeScript, Xamarin. Из плюсов - опять же высокая скорость разработки, нативные интерфейсные элементы, быстрая работа приложения, возможность подключения нативных библиотек и компонентов.
Из минусов - среднее комьюнити, необходимо разрабатывать кастомные элементы интерфейса нативно. Так как технология пока молодая, то бывают проблемы с поддержкой - все очень бурно развивается и меняется на ходу. Возможно, позволит сэкономить 35-50% от разработки на нативе. А может породить такой набор грабель, что проект вообще не дойдет до релиза. Кроме того, тут возникает и проблема первого метода - скорее всего при переходе к большому приложению и большой разработке весь наработанный код будет выкинут на помойку.
Способ № 6: Разбить работу на этапы
Экономия: 20-30%.
Сложности: Вам надо понимать все происходящее.
Это, наверное, самый неочевидный наш совет. Во всяком случае, когда мы предлагаем этот вариант нашим заказчикам, обычно все в восторге соглашаются и спрашивают «а что, так можно было?» Итак, мы разбиваем всю работу на три договора:
- ТЗ+дизайн.
- Разработка.
- Развитие и поддержка.
Тут все просто, объясню на примере. Приходит к нам заказчик и своими словами рассказывает, что нужно сделать, показывает свой майнд-мэп, или мокапы, или карту экранов, или что-то еще. Мы говорим, это стоит от 2 до 4 млн руб, но если у вас будет ТЗ - мы сможем назвать точную сумму, за которую мы выполним проект. И она в 99% случаев будет намного меньше 2 млн руб. Почему? Ответ простой - в методике оценки проекта без ТЗ обязательно учитываются риски. И они тем выше, чем больше неопределенность на старте.
Заказав нам разработку ТЗ, заказчик получает возможность получить точную стоимость проекта без заложенных рисков, получает возможность провести по этому ТЗ свой мини-тендер, получает документ, на основании которого будет осуществляться приемка проекта. Это не только удешевляет проект, но и сильно облегчает жизнь всем участникам проекта.
Написание ТЗ у нас стоит от 30 до 100 тысяч руб. В масштабе реализации всего проекта это совсем небольшие затраты. Не было случая, чтобы кто-то пожалел, что заказал ТЗ - оно окупается сразу же. Срок реализации этого этапа - 2-4 недели.
По готовому ТЗ формируется окончательная, адекватная стоимость проекта, планируются спринты, запускается итерационный процесс разработки. Здесь наличие ТЗ на каждом шаге экономит вам деньги.
После релиза и окончания гарантийного срока имеет смысл подписать и третий договор, на поддержку. И здесь, конечно, ваш вендор всегда даст вам более низкую цену, чем любая другая компания. Поддерживать свой код куда проще, чем чужой.
Каковы риски в таком подходе? Вам все равно надо понимать, что написано в ТЗ. То есть необходимы минимальные знания в разработке, технологиях. Да, вам напишут ТЗ, но разбираться с ним надо будет самим, хоть и с помощью авторов. Иначе может получиться совсем не то, что вы хотели.
Способ № 7. Вкладывайтесь в отношения
Экономия: 20-25%.
Сложности: Долго.
Еще одна причина дороговизны мобильной разработки кроется в одной ее особенности - здесь довольно короткие проекты. Очень дорогой пресейл, издержки, связанные со стартом разработки, со сдачей проекта, приемкой и гарантийной поддержкой размазываются не на год-полтора разработки, а на 3-4 месяца.
С этим мало что можно сделать, разве что с честными глазами рассказать подрядчику о том, что «мы с вами надолго, проект будет развиваться, скоро будет версия 2.0, 3.0 и вообще вы заработаете на поддержке». И просить снижать цену - иногда это работает.
Способ № 8: Делайте только то, что нужно
Экономия: 20-50%.
Сложности: Сам продукт.
В разработке есть понятие MVP - Minimum Viable Product, минимально жизнеспособного продукта. Напрямую к экономии оно отношения не имеет, но может сократить затраты на проект в целом. Суть его в том, что начинать надо с минимального набора функций, удовлетворяющих поставленным задачам. Потом функциональность можно развить и нарастить, но в первой версии функций должен быть минимум, но минимум такой, чтобы продукт ваш жил.
Если вы магазин, продающий цветы, то в приложении вашем должен быть список цветов, корзина (возможность купить) и доставка. Не надо делать социальную сеть любителей цветов, оплату Apple Pay, дизайн от «Студии Лебедева» и подбор букетов с помощью искусственного интеллекта. Ваша цель - начать продавать цветы в мобильном приложении, а все остальное перечисленное - приятное, но очень дорогое дополнение, которое, если вы захотите, можно будет реализовать позднее.
Если вы определяете минимум функций для своего приложения, то, скорее всего, они давно решены подрядчиком и стоят вменяемых денег. Вы сэкономите (сколько точно сказать трудно - разброс между тем, что нужно, и тем, что хочет заказчик, иногда разителен) и получите работающий продукт.
Сложностей в данном варианте особых нет. Главное - не забывать предупредить пользователя, что это лишь один из релизов, функционал еще реализован не полностью, наберитесь терпения.
В заключение: как не надо экономить
В завершение рассмотрим и некоторые ошибки, которые совершают компании, стремящиеся сэкономить на разработке своих приложений.
Итак, вот чего делать не нужно:
- Не экономьте на начальном этапе. Продумайте ваш будущий сервис, как он должен работать, на чем вы будете зарабатывать? И миллион других вопросов. Найдите толкового аналитика еще до того, как вы приняли решение что-то делать. Проведите полноценное тестирование самой идеи. Возможно, вам и не нужно никакое мобильное приложение.
- Нельзя экономить на тестировании. Если вы не «Сбербанк», то один-два бага в приложении - и пользователя вы потеряли навсегда.
- Инхаус разработка - это не про экономию. Иногда компании принимают решение делать мобильное приложение своими силами. Это кажется странным, ведь для ведения даже не самого сложного проекта в штате должны быть менеджер проектов, аналитик, дизайнер, собственно разработчик, инженер по тестированию, почти всегда нужен и бэкенд-разработчик для интеграции приложения в инфраструктуру, часто нужны и фронтенд-программисты. Такое расточительное решение имеет смысл, когда мобильное приложение становится предельно значимым каналом работы с клиентом. Например, именно так поступает «Альфа-Банк».
