Привет, меня зовут Алексей Кафтанов, я — руководитель компании FullStack (входит в ГК «Автомакон»). Мы занимаемся разработкой мобильных и web-приложений.
В начале года у нас появился интересный кейс. За две недели мы сделали базовое курьерское приложение с обновлением функционала без необходимости выгрузки билда в стор.
Проект получился классическим MVP, модель реализации подойдет для небольших b2c и почти любых b2b-проектов. Если в сжатые сроки вам требуется рабочее приложение, советую обратить внимание на этот подход. Текст будет интересен проджект-менеджерам и, скорее всего, в нем не будет ничего ранее неизвестного для программистов.
Эксперименты с онлайн-доставкой ВкусВилл начал проводить еще в прошлом году. Для этого была выбрана и утверждена логичная бизнес-стратегия: разработка двух разных приложений, для клиента и сборщика/курьера.
Это было удобно, клиентов было немного, загрузка приложения была небольшой: около 100 заказов в день, в процессе развития — до 1000.
Затем началась пандемия, ритейл стал повсеместно перестраиваться в сторону доставки. Клиентский поток увеличился в разы, времени на изменения и согласования было минимум — все поняли, что существующая реализация — плохая и ее нужно срочно менять.
От службы доставки в период изоляции зависела работа всей сети, поэтому главным вопросом, стоявшим перед командой, был: «Что делать с курьерами?» Тогда решили сделать telegram-бот. Потому что в боты мы умеем.
Увеличение количества заказов подтвердило успешность выбранной бизнес-модели. Но далее мы стали упираться в ограничения бота как платформы. В частности, перед разработкой стояло несколько задач:
Нас накрыло флешбеками о проблемах с ревью. Плюс к этому при стандартном подходе к разработке нам пришлось бы пройти все этапы проектирования, дизайна, анализа UX-редактором, верстки и сборки. По нашей оценке это заняло бы от одного до трех месяцев и отняло ресурсы у основного приложения.
Интересный факт: в FullStack фронтом «ВкусВилла» занимаются четыре героя: 2 для iOS и 2 для Android. Если вы хотите составить им компанию, напишите мне — kafa@automacon.ru.
В тот момент нам повезло: мы нашли ребят, рассказавших нам про no-code платформу Bubble.io. По их словам приложение по нашим запросам могло быть сделано там за неделю. Более того, они показали, как именно оно могло бы функционировать и даже прошли проверку на возможность работать с нашим довольно хитрым бекендом.
Если честно, Bubble показался мне довольно-таки сырой технологией, с точки зрения пользовательского интерфейса это несколько странная и не отзывчивая система.
Но во время знакомства с ней появилась идея: использовать принцип работы платформы для быстрого создания собственного приложения. Потому что, если с этой задачей может справиться Bubble, то почему не может, например, SPA?
Мы решили написать пользовательский интерфейс на ReactJS с использованием фреймворка Capacitor. Проект собирается в оптимизированный и сжатый набор файлов, который выгружается на удаленный сервер. Capacitor имеет доступ к нативным функциям, приложение запускается через WebView, где указан URL с собранным на ReactJS проектом. Соответственно этой логике проект должен был открываться как обычный сайт с возможностью вызова нативных функций. Удивительно, Apple без проблем пропускает подобные технологии в свой магазин приложений.
Написали, которое передали ребятам с компетенцией Bubble и одному своему программисту React. Выглядело оно довольно-таки примитивно: берем дизайн-гайд, продумываем простой UI и собираем фронт, который будет выполнять всю функциональность бота.
У каждой команды (если считать нашего программиста за команду) было 2 недели на реализацию задачи: на основе гайдлайна самостоятельно создать максимально простое и удобное приложение. Консультироваться разработчики должны были напрямую с лидером проекта со стороны бизнеса.
Подчеркну, мы сознательно отказались от проектирования, дизайна и привлечения аналитика.
В данном случае свою роль сыграло то, что мы работаем с ВкусВилл. В их культуре активно используется методика задвоения поставщиков. Мне стало интересно посмотреть, как над проектом будет работать сторонняя команда Bubble. Возможно, нам удалось бы перенять у них какие-то фишки, приемы менеджмента и особенности коммуникации.
При этом безоговорочной веры в успех приложения на основе конструктора у меня не было, поэтому тратить 2 недели на создание одного решения не хотелось.
В первую очередь, идея параллелить команды оказалась очень логичной: интерфейсное решение no-code как-то сразу не задалось.
Поскольку задача делать по гайдлайнам стояла сразу, реализация меня как-то немного демотивировала. С точки зрения отклика у Bubble есть очевидная проблема: нажимается все топорно, часто по два раза. В процессе обнаружились еще одни танцы с бубнами: больше 2 дней у команды ушло заменить «нативные» для Bubble Google-карты на Яндекс. Еще 1 день — сделать функционал открытия маршрутизации через 2Gis. При этом решение получилось костыльное: если 2Gis не установлен на устройство, оно все равно предлагалось. По трудозатратам у no-code команды вышло чуть больше 80 часов (первоначально именно такой лимит был установлен) при этом приложение получилось сырым. На этом сотрудничество с ними и закончили.
Решение на ReactJS получилось гораздо более оптимальным: во-первых, полный функционал получилось сделать за 67 часов, во вторых с точки зрения гайдлайнов и логики все получилось вполне рабочим:
Публикация на iOS прошла удачно: не было вопросов на ревью, уже на следующий день приложение было в сторе. Android в Play Market мы выкладывать не стали, просто разместили .apk в облачном хранилище.
После запуска стали ощутимы все плюсы подобной сборки. Приложение не было готово к полноценным тестам, а апдейты и доработки удобнее делать без необходимости публикации.
Сейчас приложение работает уже несколько месяцев, мы добавили довольно много функционала, сделали хороший каздев с курьерами. Все довольны.
Удивительно, но разработка на bubble.io получилась дольше, а итоговый продукт — более сырым. Существенную роль здесь сыграло ограничение конструктора.
В самом начале, при постановке ТЗ, я обратил внимание команд на важность использования гайдлайна с уже готовыми визуальными элементами: шрифтами, иконками, общим стилем и т.д. Несмотря на это у ребят из Bubble получился предельно примитивный интерфейс. Вряд ли решающую роль могло сыграть банальное «не успели», скорее, дело в том, что платформа плохо кастомизируется. Если кто-то может объяснить причину, напишите в комментариях.
Многих может удивить, что мы не знали о такой методологии и ее уже повсеместно используют. Тем не менее, для меня это стало открытием и я думаю что это очень хорошее решение для корпоративных приложений с небольшим количеством Пользователей. Приложение получается в разы удобнее и принципиально отличается от адаптивной версии сайтов, сроки реализации меньше, чем при работе с ReactNative или Flutter, визуально разница не заметна.
Подытожу: проект показался хорошим вызовом для команды, а — лично для меня — управление им было отличным способом передохнуть от рутины долгого, внимательного и очень вдумчивого проектирования «больших» задач.
В начале года у нас появился интересный кейс. За две недели мы сделали базовое курьерское приложение с обновлением функционала без необходимости выгрузки билда в стор.
Проект получился классическим MVP, модель реализации подойдет для небольших b2c и почти любых b2b-проектов. Если в сжатые сроки вам требуется рабочее приложение, советую обратить внимание на этот подход. Текст будет интересен проджект-менеджерам и, скорее всего, в нем не будет ничего ранее неизвестного для программистов.
Немного истории
Эксперименты с онлайн-доставкой ВкусВилл начал проводить еще в прошлом году. Для этого была выбрана и утверждена логичная бизнес-стратегия: разработка двух разных приложений, для клиента и сборщика/курьера.
Это было удобно, клиентов было немного, загрузка приложения была небольшой: около 100 заказов в день, в процессе развития — до 1000.
Затем началась пандемия, ритейл стал повсеместно перестраиваться в сторону доставки. Клиентский поток увеличился в разы, времени на изменения и согласования было минимум — все поняли, что существующая реализация — плохая и ее нужно срочно менять.
Проблемы нашей реализации
- Приложения были только Android. Но пандемия перетрясла все сферы, и в службы доставки стали приходить курьеры с iOS.
- Приложение очень долго обновлялось, например, однажды мы попали под семидневное ревью от Google. Оптимизировать продукт в таких условиях было невозможно.
От службы доставки в период изоляции зависела работа всей сети, поэтому главным вопросом, стоявшим перед командой, был: «Что делать с курьерами?» Тогда решили сделать telegram-бот. Потому что в боты мы умеем.
Увеличение количества заказов подтвердило успешность выбранной бизнес-модели. Но далее мы стали упираться в ограничения бота как платформы. В частности, перед разработкой стояло несколько задач:
- Видеть маршрут и все заказы на удобной карте
- Быть привязанным сразу к нескольким торговым точкам
- Получать актуальную информацию о статусе заказов
- Использовать быстрый, нативно понятный интерфейс. За время работы бот оброс большим количеством дополнительной функциональности, что значительно увеличило количество кнопок для простого, по меркам приложения, пользовательского пути.
- Синхронизировать с приложением свою актуальную локацию. С этим пунктом у telegram наблюдаются определенные сложности и ограничения: передача локации возможна только на 8 часов.
- “Отделить” пуш-уведомления внутри приложения от общих пушей в телеграмме, так курьерам удобнее реагировать именно на заказы.
Нас накрыло флешбеками о проблемах с ревью. Плюс к этому при стандартном подходе к разработке нам пришлось бы пройти все этапы проектирования, дизайна, анализа UX-редактором, верстки и сборки. По нашей оценке это заняло бы от одного до трех месяцев и отняло ресурсы у основного приложения.
Интересный факт: в FullStack фронтом «ВкусВилла» занимаются четыре героя: 2 для iOS и 2 для Android. Если вы хотите составить им компанию, напишите мне — kafa@automacon.ru.
Начало разработки
В тот момент нам повезло: мы нашли ребят, рассказавших нам про no-code платформу Bubble.io. По их словам приложение по нашим запросам могло быть сделано там за неделю. Более того, они показали, как именно оно могло бы функционировать и даже прошли проверку на возможность работать с нашим довольно хитрым бекендом.
Если честно, Bubble показался мне довольно-таки сырой технологией, с точки зрения пользовательского интерфейса это несколько странная и не отзывчивая система.
Но во время знакомства с ней появилась идея: использовать принцип работы платформы для быстрого создания собственного приложения. Потому что, если с этой задачей может справиться Bubble, то почему не может, например, SPA?
Мы решили написать пользовательский интерфейс на ReactJS с использованием фреймворка Capacitor. Проект собирается в оптимизированный и сжатый набор файлов, который выгружается на удаленный сервер. Capacitor имеет доступ к нативным функциям, приложение запускается через WebView, где указан URL с собранным на ReactJS проектом. Соответственно этой логике проект должен был открываться как обычный сайт с возможностью вызова нативных функций. Удивительно, Apple без проблем пропускает подобные технологии в свой магазин приложений.
Написали, которое передали ребятам с компетенцией Bubble и одному своему программисту React. Выглядело оно довольно-таки примитивно: берем дизайн-гайд, продумываем простой UI и собираем фронт, который будет выполнять всю функциональность бота.
У каждой команды (если считать нашего программиста за команду) было 2 недели на реализацию задачи: на основе гайдлайна самостоятельно создать максимально простое и удобное приложение. Консультироваться разработчики должны были напрямую с лидером проекта со стороны бизнеса.
Подчеркну, мы сознательно отказались от проектирования, дизайна и привлечения аналитика.
Почему команд было две?
В данном случае свою роль сыграло то, что мы работаем с ВкусВилл. В их культуре активно используется методика задвоения поставщиков. Мне стало интересно посмотреть, как над проектом будет работать сторонняя команда Bubble. Возможно, нам удалось бы перенять у них какие-то фишки, приемы менеджмента и особенности коммуникации.
При этом безоговорочной веры в успех приложения на основе конструктора у меня не было, поэтому тратить 2 недели на создание одного решения не хотелось.
Что получилось
В первую очередь, идея параллелить команды оказалась очень логичной: интерфейсное решение no-code как-то сразу не задалось.
Поскольку задача делать по гайдлайнам стояла сразу, реализация меня как-то немного демотивировала. С точки зрения отклика у Bubble есть очевидная проблема: нажимается все топорно, часто по два раза. В процессе обнаружились еще одни танцы с бубнами: больше 2 дней у команды ушло заменить «нативные» для Bubble Google-карты на Яндекс. Еще 1 день — сделать функционал открытия маршрутизации через 2Gis. При этом решение получилось костыльное: если 2Gis не установлен на устройство, оно все равно предлагалось. По трудозатратам у no-code команды вышло чуть больше 80 часов (первоначально именно такой лимит был установлен) при этом приложение получилось сырым. На этом сотрудничество с ними и закончили.
Решение на ReactJS получилось гораздо более оптимальным: во-первых, полный функционал получилось сделать за 67 часов, во вторых с точки зрения гайдлайнов и логики все получилось вполне рабочим:
Публикация на iOS прошла удачно: не было вопросов на ревью, уже на следующий день приложение было в сторе. Android в Play Market мы выкладывать не стали, просто разместили .apk в облачном хранилище.
После запуска стали ощутимы все плюсы подобной сборки. Приложение не было готово к полноценным тестам, а апдейты и доработки удобнее делать без необходимости публикации.
Сейчас приложение работает уже несколько месяцев, мы добавили довольно много функционала, сделали хороший каздев с курьерами. Все довольны.
Немного выводов
Удивительно, но разработка на bubble.io получилась дольше, а итоговый продукт — более сырым. Существенную роль здесь сыграло ограничение конструктора.
В самом начале, при постановке ТЗ, я обратил внимание команд на важность использования гайдлайна с уже готовыми визуальными элементами: шрифтами, иконками, общим стилем и т.д. Несмотря на это у ребят из Bubble получился предельно примитивный интерфейс. Вряд ли решающую роль могло сыграть банальное «не успели», скорее, дело в том, что платформа плохо кастомизируется. Если кто-то может объяснить причину, напишите в комментариях.
Многих может удивить, что мы не знали о такой методологии и ее уже повсеместно используют. Тем не менее, для меня это стало открытием и я думаю что это очень хорошее решение для корпоративных приложений с небольшим количеством Пользователей. Приложение получается в разы удобнее и принципиально отличается от адаптивной версии сайтов, сроки реализации меньше, чем при работе с ReactNative или Flutter, визуально разница не заметна.
Подытожу: проект показался хорошим вызовом для команды, а — лично для меня — управление им было отличным способом передохнуть от рутины долгого, внимательного и очень вдумчивого проектирования «больших» задач.
