Привет, я Евгений Бойченко – сооснователь студии, которая разрабатывает мобильные приложения. За 10 лет работы вопрос «Почему так дорого?» я слышу чуть ли не ежедневно. Для многих клиентов мы искали возможности безболезненно снизить цену разработки, и в итоге у меня накопилось некоторое количество кейсов, которые решают проблему высокой стоимости мобильного приложения. В этом треде я призываю комьюнити делиться знаниями о том, как удешевить разработку мобильного софта без потерь. Начну с себя и своих секретиков, а вы присоединяйтесь в комментариях – вместе создадим гайд по экономичной разработке, который будет полезен обществу.

Предисловие: как понять, что мобильное приложение вам нужно

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

• Моя ниша достаточно велика?
• Приложение решит мои бизнес-задачи?
• Будет ли у меня такой поток клиентов, который оправдает вложения?
• В насколько близких отношениях мои клиенты с мобильными технологиями?

Ответ «нет» хотя бы на один из этих вопросов – повод задуматься о необходимости приложения. Мало времени и денег – ещё два предупредительных выстрела. И того, и другого будет уходить много.

Сколько времени уходит на мобильную разработку

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

Сколько денег уходит на мобильную разработку

Готовы потратить семизначную сумму? Начинайте разработку смело. Не готовы? Читайте статью дальше.

MVP приложения

MVP (Minimum Viable Product – «минимально жизнеспособный продукт») – пилотная версия приложения. Она нужна чтобы понять, как продукт или услуга заходит аудитории, при минимальных затратах на создание. Ей не требуются функциональные и дизайнерские украшательства – всё, что там будет, работает строго на бизнес-цель продукта.

Стратегия MVP уместна, когда нужно выпустить приложение вовремя, понять, что люди будут им пользоваться, и проверить все гипотезы, которые вы сформулировали на этапе проектирования. Выбрав её, вы не потратите деньги на неинтересный аудитории продукт. А если интерес будет, то вы сможете развивать приложение дальше.

MVP-версия мобильного приложения для интернет-магазина должна обязательно состоять из главной страницы, каталога с поиском, корзины и функции оплаты. Добавлять анимацию, подключать сторонние сервисы, предлагать несколько способов оплаты и внедрять дополненную или виртуальную реальность рано. Убедитесь, что в приложении покупают, а дальнейший анализ покажет, что ещё нужно пользователю.

Проектирование, аналитика и техническое задание

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

Если вы ещё не выяснили, кто ваши потенциальные пользователи, как проект будет реализован, сколько он стоит и есть ли у вас конкуренты, сделать это можно на этапе бизнес-аналитики.

Суть кратко: системный аналитик собирает ваши требования к проекту и переводит их на язык разработки. Он выясняет:

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

Что при этом происходит:

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

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

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

iOS или Android: что лучше выбрать для разработки мобильного приложения

На разработке приложения можно сэкономить в два и более раза, если делать приложение только под одну платформу – iOS или Android. Но практика показала, что из-за сотен существующих на рынке моделей телефона на ОС Android и нескольких актуальных её версий разработка под эту платформу может стоить больше, чем разработка под iOS.

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

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

Но окончательный выбор платформы зависит от цели приложения и его аудитории. Хотите зарабатывать и делаете ставку на платёжеспособных пользователей? Выбирайте iOS. Создаёте продукт, нацеленный на массы или регионы, жители которых не привыкли или не могут платить за цифровые продукты? Делаете сервисное приложение для курьеров и торговых представителей и не можете позволить себе дорогой парк устройств? Выбирайте Android. Хотите захватить мир? Выбирайте обе платформы.

Как сэкономить на дизайне мобильного приложения

Чтобы не переплатить за дизайн, нужно помнить минимум о двух условиях:

1. Дизайн – это сумма функциональных и графических решений, которые помогают приложению выполнять свою цель, а не впечатляющий внешний вид. Ничто не должно мешать интерфейсу быть практичным и понятным. Иначе говоря, хороший дизайн — это как можно меньше дизайна.
2. До появления вашего приложения пользователи уже работали с десятками других и привыкли к внешнему виду и расположению элементов, последовательности действий и реакции приложения на те или иные действия. Это паттерны, и пользователи ждут, что они будут повторяться всегда и во всех приложениях для конкретной платформы – отталкивайтесь от этого.

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

Допустим, стоит задача разработать для обеих платформ внешне одинаковое приложение. Поэтому нужно сделать какой-то элемент не таким, каким он обычно выглядит в своей ОС. Например, мы пытаемся повторить тулбар iOS в Android-версии. Это значит создание элемента с нуля, что дольше и дороже. В совокупности такие изменения сильно повлияют на стоимость проекта.

С анимациями похожая история: чем они сложнее и круче, тем больше времени и бюджета требуют.

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

Если своих шаблонов у студии нет, то на помощь могут прийти уже упомянутые выше UI-киты. На сайте UI8 изобилие уже готовых китов, иконок, вайрфреймов и всего, что нужно для работы над пользовательским интерфейсом.

Кроссплатформенные приложения: что это и как экономит деньги

Подход к разработке приложения может быть нативным и кроссплатформенным.

Нативные приложения создаются на конкретном языке программирования для конкретной платформы: языки Java и Kotlin — для Android, а Swift не ниже третьей версии — для iOS.

Достоинства:

• мгновенная реакция на действия пользователей;
• прямой доступ к аппаратной части устройства;
• привычный для пользователей платформы интерфейс.

Недостаток: высокая стоимость разработки и поддержки из-за привлечения минимум одного разработчика для каждой платформы.

Кроссплатформенные разработка мобильных приложений осуществляется с помощью веб-технологий (HTML, CSS и JavaScript) инструментами Cordova, Xamarin, React Native и Flutter и работают сразу на iOS и Android. Чтобы написанный код заработал на мобильных устройствах, его нужно либо «перевести» на понятный им язык, либо сделать прослойку, которая работает на устройстве и переводит обращения к функциям устройства с непонятного для них языка на понятный.

Достоинство: низкая стоимость разработки и поддержки из-за привлечения одного веб-разработчика.

Недостатки:

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

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

Как сэкономить на бэкенде

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

1. Хранить данные на стороне клиента, то есть в устройстве. В таком случае для работы приложения не нужен интернет, но так оно лишается интерактивности, а новый контент будет появляться только с новой версией приложения в сторе.
2. Использовать бессерверную архитектуру приложений – Serverless. Это решение не требует ни особых знаний для развёртывания и поддержки, ни ощутимого бюджета — всю поддержку берёт на себя тот облачный сервис, на котором вы построите архитектуру. Много возможностей для этого имеют AWS, Azure и Firebase.
3. Работать с данными через интеграции с бесплатными инструментами. Вместо хитрых кастомных форм можно использовать Google-форму, данные собирать не в административную панель, а в Google-таблицу, а вместо приложения использовать Telegram-бота.
4. Использовать SaaS-сервисы. В приложении есть типовые функции, создание и поддержка которых не только дороги, но и отягощают клиента бумажной волокитой. Поэтому их разработка с нуля – редкость. Один из примеров такой функции — оплата, и стандарт де-факто — использовать платёжный шлюз какого-нибудь банка.

И это касается массы других возможностей приложения. Нужны чаты или push-уведомления? Их дешевле брать готовыми, в виде SaaS (Software-as-a-Service – программное обеспечение как услуга). В среднесрочной перспективе это дешевле и надёжнее, чем писать свою платформу. Вы тем самым избегаете всех грабель, которые собрали разработчики платформы до того, как она заработала.

Фриланс или агентство: выбираем разработчиков

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

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

Минусы:

• Отношения с фрилансером основаны на взаимном доверии, и всегда есть риск наткнуться на недобросовестного исполнителя. Кроме того, без тестирования и code review со стороны профессионалов не факт, что проект будет реализован без багов и другие специалисты смогут его поддерживать, если вы решите сменить исполнителя.
• Срывы дедлайнов и растягивание задач — частая ситуация в работе с фрилансерами. Если он работает над несколькими проектами, в первую очередь он будет решать задачи на горящих. Фрилансер может и вовсе перестать выходить на связь и пропасть.
• Исключительно материальная заинтересованность фрилансера в вашем проекте и полное безразличие к его дальнейшей судьбе могут дать плохой результат. Включённость в проект важна, и от того, каких специалистов вы подберёте и как построите взаимодействие, будет зависеть успешность проекта.

Нанимать фрилансеров стоит при явно ограниченном бюджете, но от вас требуется богатый опыт в управлении проектами и готовность тратить много времени на общение с подрядчиками. Самое главное — просчитывать риски и всегда иметь под рукой план Б.

Региональные студии или столичные: кому доверить проект

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

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

• «Тэглайн» – самый авторитетный рейтинг разработчиков мобильных приложений на российском рынке. Учитывает годовую выручку студии, количество сотрудников, качество сайта студии и её узнаваемость среди коллег по цеху.
• «Рейтинг Рунета» – главные критерии попадания в него – количество выпущенных приложений и их средняя оценка в сторах, поэтому вам не придётся выбирать среди псевдостудий, сделавших два давно мёртвых проекта.
• Clutch – рейтинг из США. Позиции студий зависят от реальных отзывов и оценок от уже работавших с ними клиентов.
• Ruward – агрегатор других рейтингов. Учитывает позиции студий в «Тэглайне», «Рейтинге Рунета», Clutch Russia и ряде второстепенных рейтингов.

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

На что ещё обратить внимание при выборе студии мобильной разработки:

• Студии с маленьким штатом редко способны выдать результат высокого уровня из-за банальной нехватки рук.
• Студия, работающая на рынке от двух лет и более, уже имеет и опыт, и портфолио.
• Портфолио скажет вам о многом: какого масштаба клиенты доверились этой студии, насколько хорошо студия делает свою работу, а главное – создавала ли она ранее продукт, похожий на ваш. Если да, то вам повезло, ведь студия уже понимает ваши проблемы и проблемы рынка, а работа над проектом пойдёт быстрее на всех этапах.

Экономия с помощью конструкторов мобильных приложений

Растущий рынок мобильных приложений в какой-то момент не мог не предложить малому и среднему бизнесу создавать приложения в конструкторах и генераторах.

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

Зачем нужно приложение на конструкторе? Чтобы осмотреться в мобильной среде, увидеть востребованность бизнес-идеи в ней, а если она есть, то это будет зелёным светом к разработке приложения с нуля.

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

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

Признаемся, что автор не знает ни одного конструктора первого типа, на котором собрали бы приложение, пользующееся спросом и решающее реальные проблемы миллионов. Если вы не знакомы со своей аудиторией, слабо понимаете, что такое пользовательский опыт, то вам будет сложно получить достойно выглядящий, удобный и приносящий деньги результат. У таких конструкторов нет поддержки дизайнеров и разработчиков, а значит, вы будете сами себе аналитиком, UX/UI-дизайнером и маркетологом, то есть сами поведёте свой продукт к успеху. Чем это закончится – вопрос риторический.

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

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

Есть множество индустрий, где конструкторы второго типа хорошо решают задачу. Среди них – рестораны и кафе, на создание приложений для которых заточен конструктор WelcomeApp, службы доставки еды, решение для которых поставляет DeliveryApp, массовые мероприятия и корпоративные приложения, с которыми рады помочь такие конструкторы, как Eventicious и EventPlatform, и другие индустрии. Находятся даже платформы для массового выпуска приложений с программой лояльности и студии, которые готовы сделать клоны хоть твиттера и eBay, хоть уберы для любых специалистов.

Политика мобильных сторов в отношении шаблонных и сгенерированных приложений неустойчива. В августе 2017 года компания Apple добавила в инструкцию по публикации приложений в App Store пункт, гласящий, что модераторы не будут пропускать такие приложения. В июле 2019 компания пошла на уступки: такие приложения нельзя подписывать в App Store именем клиента, данные каждого клиента должны храниться на отдельном бинарном файле, а сам конструктор приложения должен предоставлять инструменты для создания приложений с уникальным пользовательским опытом. К таким инструментам и относятся профессиональные конструкторы.

Итог короткий: если и выбирать конструктор для создания мобильных приложений, то только профессиональный. Попробовать – можно, зарабатывать и развивать – с трудом. Сразу после подтверждения спроса думайте о полноценном приложении.

Сэкономить на мобильной разработке с помощью маркетплейсов

Молодому бизнесу, решившему зайти на территорию мобайла, порой разумнее не делать приложение, а подключиться к маркетплейсу. Например, ресторан или кухня могут не делать своё приложение, а завести аккаунт на Яндекс.Еде, а производитель обуви – в маркетплейсе Bringly или «Беру». Став партнёром, магазин платит площадке комиссию с каждой продажи. Если продажи через маркетплейс есть и имеют тенденцию к росту и возврату клиентов, то можно подумать об инвестициях в собственное мобильное приложение.

Пионерами и лидерами в этой нише остаются Amazon, eBay, Alibaba и Ozon, где большинство из нас что-то покупали хотя бы раз в жизни, а в России, по данным сайта Shopolog, существует несколько десятков маркетплейсов.

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

Мобильное приложение или PWA

А нужно ли вообще делать приложение? Если у вас есть адаптивный сайт и веб-разработчик, то несколько манипуляций – и вы получаете PWA (Progressive Web App). Это не просто сайт: он всё ещё открывается в мобильном браузере, но уже может работать офлайн, посылать push-уведомления, иметь доступ к некоторым аппаратным частям устройства и открываться с рабочего стола через клик на иконку. При этом места на устройстве он занимает меньше.

Понятие PWA появилось в 2015 году на фоне популяризации принципа mobile first. Принцип гласит, что, поскольку мобильный интернет-трафик сравнялся с десктопным (а впоследствии и обогнал его), то дизайнеры и разработчики теперь должны делать сайты в первую очередь для пользователей смартфонов, то есть быстрыми, удобными и полезными. По релевантным запросам такие сайты идут в мобильной поисковой выдаче выше конкурентов.

За эти годы появилось уже достаточно кейсов, подтверждающих, что PWA играют на руку бизнесу: пользователям нравится тот опыт, который они получили от приложения, и они продолжают им пользоваться, нести трафик и покупать товары. От скорости загрузки PWA-версий сайта выиграли Lancome, Tinder, Uber, Pinterest и другие известные продукты.

Установить на своё устройство PWA-приложение пользователь мог только тогда, когда он работал с мобильным сайтом, и их нельзя было найти в магазинах приложений. Но в феврале 2019 с выходом браузера Chrome 72 и появления функции Trusted Web Activity в его Android-версии возможность скачать PWA из стора получили как минимум пользователи ОС Android.

Экономия на поддержке

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

Заключить договор о поддержке – это уже само по себе экономия, но есть несколько способов сократить расходы и на неё:

1. Сократите количество часов. За несколько месяцев работы продукта может выясниться, что вам будет много даже половины купленного на поддержку времени.
2. Откажитесь от поддержки по SLA. В этом случае ваши задачи лишаются разделения по критичности, и насколько бы проблема ни была серьёзной, её никто не будет решать в срочном порядке в нерабочее время. Осторожно предположим: если у вас не DATA-центр, то вряд ли вам нужна незамедлительная реакция отдела поддержки.
3. Сделайте легкоподдерживаемый продукт. Не пренебрегайте документацией, code review, подготовкой автотестов, проработкой архитектуры, рефакторингом – вложенные в них средства оправдают себя позже. Хорошо задокументированный проект позволит разобраться в нём даже тому разработчику, который видит проект впервые.

Модели оплаты

Если вы создаёте приложение совместно со студией, то в зависимости от целей проекта работа и оплата ведутся по одной из двух моделей:

• Fixed price. Модель предполагает, что за утверждённый бюджет в утверждённые сроки студия создаст то, что оговорено в техническом задании.
• Time & Materials. Модель предполагает, что клиент платит постфактум за те человекочасы, которые команда потратила на решение отдельных задач.

Кажется, что FP выгоднее: ведь исполнитель назвал цену на берегу, а по T&M стоимость может оказаться непрогнозируемо больше. Так и есть, когда стоит цель сделать проект к конкретной дате или когда проект небольшой и не предполагает доработок. Но в случае с проектами посложнее исполнитель закладывает в оценку по FP максимум рисков, которые заказчик вынужден оплатить, даже если они не проявились. Так что с работой по T&M стоимость может стать непрогнозируемо меньше. Но всё же существуют оптимальные условия для такой модели:

Предстоит работать над стартапом среднего или большого размера

Рынок, на котором стартап хочет занять место, может быстро измениться, а вместе с ним поменяются и требования к продукту. Но при работе по FP клиент уже описал в техническом задании функциональность, которую исполнитель сделает при любых обстоятельствах — даже если функциональность больше не нужна. Мало того, что он её описал, так он за неё ещё и заплатил. И если результат оказался не пригоден для рынка, придётся платить за доработку или замораживать проект. Модель Time & Materials даёт возможность быстро пересматривать и кардинально менять приоритеты.

У клиента есть время на регулярную коммуникацию с командой

Fixed Price освобождает клиента от необходимости отслеживать течение проекта: студия получает деньги и называет сроки, а клиент в это время занимается своими делами и ждёт результата. При работе по Time & Materials клиент — это соучастник, напрямую влияющий на проект. Кстати, это самое соучастие и экономит бюджет, потому что требования к продукту не составляются в функциональное задание, а уточняются напрямую, и можно быстро обсудить возможные решения, их плюсы и минусы, а потом выбрать самый короткий путь реализации. На Fixed Price же студия должна заложить время на отработку рисков в оценку и нести за них ответственность сама. Под рисками мы имеем в виду неверно истолкованные части ФЗ, что вызывает неожиданный, мягко говоря, результат, недовольство клиента и переделки.

Нет чётких дедлайнов

Амбициозный проект трудно создавать в рамках строгих сроков и функциональности. Строгость — черта модели Fixed Price. Но если риски вылезают наружу, то разработчик приходит к клиенту и говорит, что задача оказалась сложнее, чем предполагалось, и придётся упрощать разработку, чтобы уложиться в сроки. Модель Time & Materials позволяет избежать связанной с этим неловкости: оплата по факту выполнения задачи даёт возможность обсуждать её столько, сколько нужно, и работать без нервов.

Блок для тех, у кого мало времени: как сделать приложение и не попасть в долговую яму – кратко

1. Начинайте с MVP-версии. Она поможет вам оценить востребованность приложения у целевой аудитории – минимум киллер-фич, только лаконичный дизайн и полезная функциональность.
2. Не жалейте времени и денег на бизнес-аналитику. Этот этап поможет вам выбрать правильную стратегию для развития приложения, отметёт нежизнеспособные идеи и сэкономит ваши деньги в долгосрочной перспективе (особенно на этапе поддержки).
3. Сделайте как можно меньше дизайна. В помощь – гайдлайны от Google и Apple и UI-киты.
4. Если в приложение закладывается простая функциональность – сделайте его кроссплатформенным. Разработку сложных приложений можно начинать с одной платформы – iOS или Android. Когда показатели конверсии оправдают себя, то смело принимайтесь за вторую.
5. Храните данные на стороне клиента, не прибегая к бэкенду или используйте бессерверную архитектуру.
6. Работайте с данными через интеграции с бесплатными инструментами (например, от Google) вместо таблиц и хитрых кастомных форм.
7. Вместо разработки типовых функций с нуля используйте SaaS-сервисы и библиотеки.
8. Выбирайте разработчика, который будет заинтересован в жизнеспособности вашего проекта. Не ориентируйтесь на столичные студии разработки, а найти хорошего исполнителя помогут рейтинги.
9. Если бюджет совсем маленький, используйте конструктор приложений – приложение, разработанное на конструкторе, поможет вам прощупать почву в мобильной среде и понять, нужно ли начинать полноценную разработку.
10. Не начинайте с eCommerce-приложения – станьте партнером маркетплейса, если хотите сначала протестировать спрос на ваши товары.
11. Если у вас уже есть сайт и свободный веб-разработчик, создайте PWA вместо приложения. PWA-сайт построен на технологиях, которые позволяют ему работать как мобильное приложение: быть нативным, присылать пуши, быстро отвечать на запросы пользователя.
12. Сократите расходы на поддержку приложения: не покупайте много часов заранее, откажитесь от поддержки по SLA, создайте понятную документацию, в которой разработчики смогут быстро и легко ориентироваться.
13. Выбирайте работу по схеме Time & Materials, чтобы минимизировать расходы на риски.

Поделитесь своим опытом снижения цены мобильной разработки

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