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

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

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

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

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

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

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

1️⃣ СОЗДАВАТЬ MVP

В разработке и стартапа есть понятие MVP — Minimum Viable Product, минимально жизнеспособного продукта.

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

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

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

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

2️⃣ ИСПОЛЬЗОВАТЬ КРОССПЛАТФОРМЕННОЕ РЕШЕНИЕ

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

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

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

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

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

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

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

3️⃣ РАЗБИТЬ ПРОЕКТ НА ЭТАПЫ

Это, наверное, самый неочевидный совет из всех.

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

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

Тут все просто, прозе показать на примере:
Приходит к нам клиент и своими словами рассказывает, что нужно сделать, показывает свой наработки или примеры проектов, или карту экранов, или что-то еще. Мы говорим, это стоит от 2 до 4 млн руб, но если у вас будет ТЗ — мы сможем назвать точную сумму, за которую мы выполним проект. И она в 99% случаев будет намного меньше 2 млн руб. Почему? Ответ простой — в методике оценки проекта без ТЗ обязательно учитываются риски. И они тем выше, чем больше неопределенность на старте.

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

Написание ТЗ у нас стоит от 50 до 100 тысяч руб. В масштабе реализации всего проекта это совсем небольшие затраты. Не было случая, чтобы кто-то пожалел, что заказал ТЗ — оно окупается сразу же. Срок реализации этого этапа — 2–4 недели.

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

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

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

4️⃣ НАЙТИ РЕГИОНАЛЬНУЮ КОМАНДУ РАЗРАБОТКИ

Это конечно та еще лотерея.
И шансы выиграть совсем не высоки. 80% из них ни чего не умеют, сидят без заказов и готовы вам пообещать луну с неба, лишь бы вы им хоть что-то заплатили.

А потом начинаются истории: пропали куда-то, задерживают сроки на 2 месяца, кормят нас завтраками и тд... Историй от наши клиентов таких уйма🤨

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

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

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

5️⃣ ИНТЕГРАЦИЯ С ВНЕШНИМИ СИСТЕМАМИ (ERP, CRM)

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

Приведем пример:
Необходимой, например, будет интеграция с API Chat-GPT, в вашем проекте, где основная задача стоит - консультация пользователя виртуальным психологом с помощью переписки.

Эта интеграция обязательна т.к. это основа вашей бизнес идеи и это несет основную прибыль проекту….

А вот например, возьмем тот же проект, но вы решили в него интегрировать на старте 1С бухгалтерию т.к. бухгалтер сказала, что без нее никак совсем.
Вот тут стоп!! Она вам объективно пока совсем не нужна в проекте. Есть огромная вероятность, что он совсем не "полетит" и через 2 месяца вы его вообще закроете -> а смысл на интеграцию 1С было тратить сотни тысяч???

6️⃣ ПОДДЕРЖКА НЕСКОЛЬКИХ ЯЗЫКОВ

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

А теперь, бонусом к материалам этой статьи, расскажем, на чем экономить точно не стоит никогда в жизни ⤵️

❌ «Не разрабатывать дизайн»

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

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

❌ «Тестировщик не нужен, я сам все проверю»

Смелое заявление. Если вы не профессиональный тестировщик, с опытом 5+ лет, то проверка займет уйму вашего времени, а ошибки в проекте все равно останутся. Не бывает программ без ошибок — бывают только хорошо протестированные программы.

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

❌ «Возьмем пока фрилансеров, а дальше видно будет»

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

❌ «Соберу команду самостоятельно»

Дополним предыдущий пункт: не нанимайте фрилансеров ни в единственном, ни во множественном числе. Тем более, не пытайтесь самостоятельно собрать команду из разрозненных фрилансеров, даже если каждый из них выполняет свою функцию на «отлично».

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

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

❌ «Не проводить аналитику и не писать ТЗ»

Работа на любом проекте начинается с аналитики и составления технического задания.

В целях экономии, есть соблазн заказать ТЗ у недорогих исполнителей или что еще хуже, написать самим. Здесь кроется опасность: недочеты в ТЗ выйдут боком в итоговом IT-продукте.

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

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

Про ТЗ это вообще отдельная история)... Многие компании даже проповедуют тот подход, что ТЗ вообще пустая трата времени и денег... Якобы они все нарисуют на экранчиках для вас, а вот то, что нарисуют, то и будем считать объемом работ)
Ну ок, пусть так.... А что вы будуте делать, если они вас по своему поняли и на экранах они не смогли нарисовать, например то, как они будут размещать приложение на сервере.. Вам нужно было одно, а они решили за вас другое..
Кто будет оплачивать переделку?? И как вы им докажите что вы правы?? Ведь уже вашу переписку не найти))) Обычная стандартная ситуация на любом проекте...

Конечно - ответ очевиден, что в ТЗ записали, так и будет сделано.
А если его нет)? ☹️

❌ «Маркетинг выстроим после запуска

Это одна из главных фатальных ошибок, вместе с предыдущим пунктом про бизнес-аналитику. И самое страшное, что так думают 8 из 10 наших клиентов...

По сути, аналитика и маркетинг связаны воедино красной нитью..

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

А смысл тогда запускать вообще проект за несколько миллионов, если после этапа бизнес-аналитики вы понимаете и принимаете решение этого не делать... И разом сэкономите 2-3млн зря потраченных рублей и 5-6 месяцев своего драгоценного времени)) Ну как вам? 🤓

А про маркетинг: это вообще странный подход к делу.... Многие говорят: "Я не буду закладывать бюджеты на маркетинг, оно как-то само потом будет продаваться, без моего участия"! 😆

Согласитесь, это супер странная позиция основателя компании..
Ну ок, а может то, что вы своим подходом предлагаете, не будет нужно аудитории, от слова совсем? Это на подумать....