{ "author_name": "Konstantin Panphilov", "author_type": "self", "tags": ["\u043a\u043e\u043b\u043e\u043d\u043a\u0430"], "comments": 53, "likes": 18, "favorites": 54, "is_advertisement": false, "section_name": "default", "id": "20268", "is_wide": "1" }
Konstantin Panphilov
9 771

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

Колонка основателя 65apps Дмитрия Желнина

Поделиться

В избранное

В избранном

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

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

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

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

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

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

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

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

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

  1. 25% менеджмент (пресейл, переговоры, работа в тендере, аккаунт-менеджмент, проектный менеджмент и так далее);
  2. 45% разработка;
  3. 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 и множество кроссплатформенных мобильных фреймворков. Из их плюсов таких решений — скорость разработки. Поскольку все приложение полностью реализовано в виде «дешевого и быстрого» HTML, то и портирование заключается в том, чтобы просто запустить этот сайт в web-view на другой платформе.

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

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

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

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

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

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

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

  1. ТЗ+дизайн.
  2. Разработка.
  3. Развитие и поддержка.

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

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

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

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

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

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

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

#Колонка

{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Нейронная сеть научилась читать стихи
голосом Пастернака и смотреть в окно на осень
Подписаться на push-уведомления
[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "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", "tablet" ], "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", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "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-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } } ]