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

Рассказываю о новом подходе к разработке MVP для стартапов — как не тратить кучу денег на создании и внедрении дизайна, а быстро собрать интерфейс на Bootstrap. Подход полезен тем, кому нужен простой понятный интерфейс и запуск проекта с космической скоростью.

Денис Гордиенко, генеральный директор Brigt Mobile

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

Мы затронем тему о том, как:

  • сэкономить на разработке мобильных приложений;

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

Как обычно происходит

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

  • Этап прототипирования.
  • Этап дизайна – (сюда входит отрисовка всех макетов, согласование с клиентом, внедрение правок).
  • Этап верстки / фронтенда
  • Этап сборки – один из основных этапов (включает в себя серверную часть, программирование приложений на базе HTML-вёрстки, создание архитектуры БД и разработка админки).
  • Этап тестирования и исправления багов.

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

Раньше весь этот процесс у нас стоил 35 тыс за один экран, т.е. если у вас приложение на 10 экранов, вышло бы 350 тыс. Это, конечно, не огромная сумма, но для многих клиентов на MVP-версию ценник неподъемный. Отсюда родилась идея о том, что нужно изменить технологии так, чтобы это было выгодно и клиентам, и нам. Мы пришли к тому, что необходимо выбросить все ненужное для быстрого запуска стартапа.

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

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

К чему я пришел

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

То есть на страте есть некая структура, например, на 10 экранов, в которой прописано, что конкретно в каком экране должно быть (регистрация, авторизация, редактирование и т.д.). Получается такое микро-ТЗ. На этапе согласования с клиентом, ещё до получения денег,, мы погружаемся в идею и прописываем какие поля должны быть на каждом из экранов. По идее это не более 1-2 часов для адекватного сейлза.

Первый этап - разворачиваем сервер и БД

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

Второй этап - запуск каркасных приложений

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

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

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

Третий этап - натив и интеграции

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

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

То же самое и с интеграциями - подключение к 1С, Битрикс24, amo.crm, соцсетям делается на этом этапе.

Четвертый этап - багфикс и причесон

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

Таким способом этап верстки и дизайна мы сокращаем до минимума засчет Bootstrap. Мы выкидываем из производственного процесса все ненужное, что не принципиально для стартапа, тем самым экономим клиенту время и деньги более, чем в 2 раза.

Развитие стартапа

После появления идеи, я рекомендую своим клиентам придерживаться следующих этапов развития:

  • Запуск MVP-версии
  • Сбор обратной связи, тестирование идеи на живых пользователях
  • Принятие решение по дальнейшим изменениям

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

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

Пишите мне в личку или по контактам на сайте свои идеи для стартапа, а я помогу оценить их по вот такой схеме. Жду ваши мнения в комментариях.

Вы тоже можете рассказать о своём проекте, как автор этого материала. Соберите побольше информации — и публикуйте материал в подсайте «Трибуна».
0
50 комментариев
Написать комментарий...
Анатолий Паращук

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

Так вот, где этот сайт для вебвью располагается у вас обычно: на локалхосте или на внешнем ресурсе? Какие трудности и ограничения есть у приложений на вебвью?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Анатолий, Вы всё верно понимаете. Это мобильный сайт, который отображается в приложении-обёртке. Кроме того, в нативной части могут быть дополнительные функции, кроме простого отображения. Например, GPS, push, работа с камерой и т.д. В этом случае, данные из натива передаются на сервер с webbiew через JS-методы

Сервер, как и в стандартной модели размещается у хостинг-провайдера, обычно мы рекомендуем VPS с серверным пространством BitrixVM, т.к. для администрирования сервера используем админку от 1С-Битрикс.

Ответить
Развернуть ветку
Alexandr Pashkevich

Сам до недавнего времени писал на Cordova-based решениях. Я так понимаю,что вы их и используете(поправьте если не прав). ИМХО уже сейчас лучше использовать flutter. Для любого уважающего себя веб-разработчика порох входа во flutter минимальный.

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

Во flutter'e очень удобный "канал" для работы с нативным кодом(по сравнению с вариантом кордовы). Нативные компоненты, компиляция в arm64 код(весь, а не только компоненты, как делает React Native).

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Александр, не совсем верно. Мы пишем чистый webview на Bitrix.Framework (пространство разработки от Битрикса). К нему написали собственные обёртки (пробовали Bitrix.Mobile, но оно ужасно неповоротливое). Кордову, ионик и подобные компилируемые фреймворки забрили из-за двух факторов:
1. При обновлении приложения его нужно переопубликовывать
2. Более высокий порог входа для программистов.
Второй пункт не про то, что мы говнокодеров привлекаем, а обусловлен тем, что программистов воспитываем почти с нуля и нам критично насколько быстро он сможет выполнять боевые задачи

Ответить
Развернуть ветку
Alexandr Pashkevich

Почему при обновлении надо переопубликовывать?
Один раз генерируете .jks или .keystore файлик (я про андроид) и подписываете с помощью jarsigner каждый новый билд одним и тем же файлом. Или я не так понял?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Не совсем корректно выразился. Под переопубликовыванием я как раз и имел ввиду выкладку обновлений. Т.е. пользователям нужно будет явно скачивать свежую версию. Очевидно, какая-то их часть обновление не поставит и будет сидеть на старой версии.

В случае webview такого нет. Вы изменяете html на сервере и при очередном обращении к этому экрану пользователь видит свежую версию экрана

Ответить
Развернуть ветку
Nuke

Почему решили использовать отвратительный Битрикс?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Мы его используем в качестве админки и фреймворка. А в чём, на Ваш взгляд его отвратительность?

Ответить
Развернуть ветку
Nuke

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Я думаю, что здесь поможет наследование. Например, наш техдир принципиально запрещает лезть в ядро и разбирать архитектуру Битрикса, чтобы, как раз, не было желания накостылить там, где это не нужно. Всё общение с ядром только через понимание входных и выходных данных. Если есть излишек - забиваешь, если чего-то не хватает, то наследуешь и дописываешь то, чего не хватает. Со своей стороны могу сказать, что 90% претензий к Битриксу основано либо на желании что-то закостылить по быстренькому, либо на непонимании принципов ООП. Это не камень лично в Ваш огород, просто в защиту Битрикса.

Ответить
Развернуть ветку
Саша Верёвкин-Орлов

"После появления идеи, я рекомендую своим клиентам придерживаться следующих этапов развития:
Запуск MVP-версии
Сбор обратной связи, тестирование идеи на живых пользователях
Принятие решение по дальнейшим изменениям"

Сразу запуск MVP-версии после появления идеи? А как же аналитика, опросы и др. перед запуском MVP-версии? Уже на этих этапах можно понять, что идея так себе и не стоит вкладываться даже в MVP.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Саша Верёвкин-Орлов

Я общее направление действий и имею в виду, клиент и слов таких может не знать Customer Development, Roadmap, Customer journey Map и др. А аналитика и опросы перед запуском MVP для большинства проектов обязательный этап.

Я вот только эту статью оцениваю, а не весь ваш блог. Я, например, клиент. У меня появилась идея. Читаю статью и понимаю, что первый этап развития "Запуск MVP-версии". Ок, запускаем MVP, тратим деньги, получаем продукт, который никому не нужен.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Саша Верёвкин-Орлов

Это понятно. Бывают проекты, которые можно на этапе аналитики понять, что скорее всего не прокатит и продукт никому не нужен. Вливать в такой в такой проект деньги и поддерживать какое-то время смысла нет.
Кто-то рассказывал историю из серий Саус Парка. Там гномы воровали у жителей грязные трусы. У гномов был план на этом зарабатывать. План состоял из трёх пунктов:
1. Воруем грязные трусы
2. Второй пункт плана они забыли.
3. Получаем прибыль.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Иногда не нужную никому идею можно модифицировать и сделать нужную. В принципе, кастдев примерно об этом

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Василий Пупкин

можно ли на webview написать приложение для курьера которое стабильно в фоновом режиме будет передавать на сервер его GPS-трекинг, при этом чтобы оно работало на iphone,android и windows mobile?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Да, если сделать нативную функцию фонового GPS-трекинга, который передаёт данные на сервер. Мы как раз недавно такую фишку сделали в нашем готовом решении для запуска маркетплейсов услуг - http://servicepi.ru

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

Ответить
Развернуть ветку
Василий Пупкин

если оценить приложение в экранах = 3шт (авторизация + просмотр списка заказов + просмотр заказа с возможностью смены статуса) = 16*3 = 48 тыс руб ? вы готовы сделать его за эту сумму?

Ответить
Развернуть ветку
К М

Раха, ты?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Если это только экраны (без дополнительных нативных функций и интеграций с внешними сервисами и базами), то да. Получается, что заказы будет создавать админ из своей панели. Напишите мне в ВК https://vk.com/truewuch или на мыло [email protected] обсудим детали.

Ответить
Развернуть ветку
К М

Круто! А можете код показать? Реализовано на swift?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Серверная часть и экраны на Bitrix.Framework, а натив на Java/Objective-C

Код натива в ближайшее время зальём на гитхаб в формате опенсорса и напишу отдельную статью с интервью нашего техдира. Как говорится coming soon :)

Ответить
Развернуть ветку
К М

Ждем ждем

Ответить
Развернуть ветку
К М

Кстати, что скажете про сравнение Swift и ObjC?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Если делать webview или подобное простое, с точки зрения нативной части, приложение, то по барабану

Ответить
Развернуть ветку
К М

Нет, я имею в виду в целом языки если сравнивать, что думаете?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
К М

Да не )), просто интересовался

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Василий Пупкин

было 35 тыс за экран, а теперь в 2 раза = 17,5 тыс?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

16 тыс экран. Спасибо, что обратили внимание, почему-то пропустил точную цифру в статье

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Антон Черных

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Michael Skimpy

1. Стали в 2 раза меньше платить сотрудникам
или
2. Стали в 2 раза меньше работать

Профит)

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Michael Skimpy

То, что я написал - называется юмор) Я даже статью не читал. Увидел очередное банально-рекламное название - и решил написать.

А раньше Вы как верстали без бутстрапа?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Банально-рекламное название как раз и нужно чтобы привлечь максимум просмотров :)

Верстали на голом HTML+SCSS

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Stas Gladkovsky

MVP = тяп ляп и в продакшн
Есть и другие нелитературные определения. Увы но Индия это теперь мы.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

У Вас есть более подходящие решения для проверки той или иной гипотезы без траты кучи денег на разработку? Тогда поделитесь ими с нами.

Ответить
Развернуть ветку
Vyacheslav Zolotov

Почему у вас стоимость работы зависит от количества экранов? Что если будет сложная логика работы приложения? Например, логика работы страницы приложения стоит в 3 раза больше верстки? Выходит что вы написали про MVP каких-то типовых проектов?

Как себя поведет webview если нужно загрузить и проскролить список из 10 000+ элементов? Что будет с плавностью и отзывчивостью?

Почему вы считаете что html верстка быстрее нативной и/или других кроссплатформенных технологий? Может быть html верстальщики просто дешевле или в команде не было нативщиков?

В одном из комментариев вы написали: "Кордову, ионик и подобные компилируемые фреймворки забрили из-за двух факторов: 1. При обновлении приложения его нужно переопубликовывать".

Работает ли такой подход на iOS? Если да, то что вы будете делать, когда apple прикроет такую возможность?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вячеслав, попробую ответить на всю массу Ваших вопросов:

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

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

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

4. По поводу скорости html-вёрстки. Возможно, в статье не совсем корректно выразился. Речь не о скорости загрузки, а о скорости разработки. То есть сделав 1 webview-экран мы его по факту реализовали и в iOS, и в Android и в веб-версии. По скорости загрузки передавать сгенерированный экран, либо данные, например, в JSON, при текущих реалиях 3-4G разницы нет. Можете скачать из сторов нашу демку для запуска маркетплейсов "Сервис поиска исполнителей", посмотрите как всё грузится.

5. Да, подход работает и в iOS. Для сторов, формально, это передача контента (свайп-меню, верхняя плашка, GPS и т.д. у нас нативные). То есть, если выражаться Вашими словами, то Apple должен прикрыть передачу данных между приложением и сервером в принципе, а этого никогда не будет. В год мы публикуем 40-50 приложений в сторы, при модерации подобных вопросов с саппортом не возникает, хотя, саппорт Apple на порядок суровее, чем Гугловский.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

В 3 пункт не вставилось название - можно воспользоваться Crosswalk

Ответить
Развернуть ветку
Lai Psov

Стартапам не нужен дизайн... Странное, на мой взгляд, утверждение.
Ни слова про UX-тестирование, только утверждение у клиента. Очень странно.
Я примерно представляю, что именно получается в итоге - если это какие-то очень прикладные приложения под конкретного человека, то здорово 😃

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Стартапу как раз вредит UX-тестирование и прочие заморочки на этапе MVP. MVP - это как раз о том, что делаешь ключевую бизнес-функцию как получилось, главное супер быстро, а затем итеративно её улучшаешь в формате agile и lean startup. Не вопрос, когда-то продукт придёт и к UX-тестированию. Но это не первичная и даже не вторичная задача на старте. В принципе, моя позиция совпадает вот с этой притчей - https://bash.im/quote/420672

Ответить
Развернуть ветку
Lai Psov

Ясно, спасибо! :) А я вот сторонник теории, что первое впечатление два раза не создашь ;)

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Lai Psov

Ясно, спасибо ;)
Единственное - MVP применяется во многих случаях, и абсолютно не обязательно на малой аудитории.
🤓

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
47 комментариев
Раскрывать всегда