Nimble
Как Ошка помогает дубайскому сервису чаевых выйти на новых клиентов
Год
2024
Клиент
Nimble
Категория
ERP система
Прочее
Прочая информация
Интегрировали дубайский аналог сервиса «Нетмонет» с 4-мя POS-системами. Переписали всю их документацию, починили оплаты, развернули виртуальные терминалы для тестирования — все это за 2 месяца. А теперь переводим сервис на арабский.
И сразу к
результатам
Интегрировали POS-системы Syrve, Odoo, Revel, Micros;
Починили платежный сервис;
Обновили интерфейс, поправили баги в UI/UX;
Улучшили кеширование, чтобы картинки из меню при заказе загружались быстрее;
Доработали систему отчетности, чтобы рестораны могли получать данные по платежам;
Провели полную ревизию архитектуры сервиса — чтобы запланировать будущие доработки.
Клиент
проекта
Nimble — англоязычный проект, работающий на рынке Дубая, аналог российского сервиса «Нетмонет». На момент нашего участия продукт уже был запущен — рестораны с его помощью проводили оплаты, а официанты получали чаевые. 

Однако у него были серьезные недоработки, которые ограничивали его потенциал на рынке: сервис не поддерживал подключения большого числа POS-систем, а оплаты проходили с ошибками. Но обо всем по порядку.
Особенности
рынка
В России ресторанный рынок обслуживают два гиганта — R_Keeper и Iiko. В Дубае же POS-систем — огромное множество, и каждая из них занимает свою долю. Написать интеграцию для каждой из них — задача со звездочкой, поскольку к каждой нужен особый подход. Но если это сделать, то можно охватить большую часть рынка.

Кроме того, в ОАЭ почти нет конкуренции в нише оплаты чаевых и частичных платежей. Банки не предлагают такие сервисы, сосредотачиваясь на стандартных услугах. В отличие от России, где с крупными игроками («Нетмонет», «Яндекс чек» и др.) бороться просто бессмысленно, в Дубае у нового проекта есть шанс занять свою нишу.
Интересно, что чаевые в Эмиратах по-прежнему часто дают наличными, а оплата через QR-код или частичная оплата не сильно распространены. Не потому, что на это нет спроса — просто о таких возможностях здесь мало кто знает.
Что с
сервисом
было не так
Перед тем, как cтартовать, мы провели быструю предпроектную аналитику. Обычно мы подходим к этому более основательно, но в нашей ситуации важно было быстро понять масштаб работы, чтобы сервис скорее заработал. Про наш стандартный подход в аналитике уже как-то писали здесь, почитайте.

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

Сервис поддерживал лишь ограниченное количество POS-систем, причем даже существующая интеграция работала нестабильно. Это мешало подключать рестораны, использующие другие популярные системы (к примеру, Syrve, Odoo, Revel, Micros) — а значит, ограничивало рост клиентской базы и выручки.

Исходя из вышеперечисленного, мы определили главные задачи первых двух месяцев:
Cделать так, интеграция с POS-системами была гибкой и поддерживала как можно больше решений;
Обеспечить стабильную и предсказуемую работу всех типов оплаты, включая полные и частичные (когда оплачиваются только несколько блюд).
Решили не переписывать код с нуля с нуля
Иногда, изучая код, понимаешь, что он слишком сложный и негибкий, и даже небольшие изменения требуют много усилий. Возникает желание переписать всё с нуля, но опыт подсказывает, что это не всегда нужно. Особенно если клиент — стартап c ограниченным бюджетом.
Наша цель — ускорить результат, а не тратить время на создание «идеального» кода, который никто кроме разработчиков и не оценит.
Поэтому вместо глобальных изменений мы выбрали путь постепенного улучшения. Мы разделили задачи так, чтобы 80% времени шло на новые функции, а 20% — на исправление технических проблем. Это позволило сохранить баланс между развитием и стабильностью существующего кода.
(можно в сравнении показать, сколько стоило бы переписывание сервиса с нуля. И сколько стоит доработка, но не переписывание. Можно на рандомном проекте показать, если не хотите нимбловские бюджеты светить)
Передача деплоя. Миграция на инфраструктуру клиента
Один из ключевых этапов проекта — перенос сервиса на инфраструктуру клиента. Раньше система работала на серверах другого подрядчика, и наша задача была переместить её на Google Cloud.  

Мы изучили код, настроили деплой и успешно перенесли проект на новую инфраструктуру клиента — так, что он продолжил стабильно работать и после миграции.
POS-системы. Интеграция
Мы уже говорили о том, что каждая POS-система была уникальной. У каждой были свои протоколы и алгоритмы работы, к каждой нужен был свой подход. Без тщательного изучения каждой из них написать адаптеры было бы просто невозможно.
Адаптер — это мост между ядром и POS-системой, что-то вроде «переходника», который позволяет одной системе взаимодействовать с другими.
Отдельно стоит отметить, что документация вендоров не билась с реальностью. Поэтому нам пришлось самостоятельно анализировать фактический формат общения с POS-системой. И разрабатывать инструкции, по которым можно было бы работать.
Итак, код изучен, интеграции написаны. Что дальше? 
Тесты. Чтобы проверить, работают ли интеграции, мы ездили в ресторан, создавали фейковый стол и размещали заказ. Тестирование проходило в реальных условиях с реальными системами и деньгами. Правда делали мы это поздно ночью, когда заведение уже было закрыто — чтобы его обычная работа не нарушалась.

Чуть позже мы развернули POS в виртуальной среде: арендовали сервер в Google Cloud, установили на него Windows и настроили систему. Клиент купил лицензию, и мы начали тестирование. Виртуальный терминал запускался, и мы могли входить по паролю, работать с меню, проверять оплаты и другие функции.
Хотя виртуальные тесты были полезными, они не всегда заменяли реальную работу с терминалом. Порой виртуальная версия системы отличалась от фактической. Например, мы могли установить версию 1.1, а в реальности ресторан пользовался версией 1.0. Это нужно было учитывать и правильно обрабатывать.
Зато теперь мы знаем, что можем виртуально тестировать вообще все — вне зависимости от того, как далеко от нас находится клиент.
Переписали платежную систему с Node.js на Java
проекта
Платежная система оказалась одной из самых больших проблем в проекте. Она была написана на Node.js, в то время как весь проект велся на Java. Разные языки — не проблема. Проблема — огромное количество костылей и непонятных решений в коде платежки. И невозможность достучаться до  разработчика за уточнениями. 

Мы решили, что проще будет переписать платежную систему на Java. Это позволило бы нам привести все к единому технологическому стеку, а значит, упростить поддержку и дальнейшую разработку. Кроме того, этот шаг существенно снизил объем кода и улучшил стабильность системы.
Доработали кеширование, отчетность и UI/UX
Мы оптимизировали кеширование, чтобы изображения из меню загружались быстрее при заказе. Раньше они хранились в POS-системе и загружались заново при каждом клике — поэтому вместо блюд клиент мог видеть черные квадраты. 

Кроме того, мы усовершенствовали систему отчетности, чтобы рестораны могли получать точные данные о платежах и чаевых через Paymob. Мы перенесли POS-систему на Windows и добавили функцию «not now» для чаевых, чтобы клиенты могли отказаться от них.
Мы также улучшили UI/UX — чтобы все было по красоте. И начали локализацию интерфейса на арабский язык. Это сложный процесс, так как при адаптации элементы сдвигаются в правую сторону, а скроллы работают по-другому. Мы продолжаем работать над этим и обязательно расскажем, как справились с задачей.
Резюме: что сделали и что у нас в планах
Мы начали с того, что подключили всего два ресторана, а сейчас уже интегрировали семь сетей. А еще провели ревизию архитектуры и настроили систему на стабильную работу — чтобы платежи, как минимум, не отваливались.
Теперь поделимся планами на зиму 2024-2025: 
Планируем завершить миграцию платежного шлюза в декабре, а также добавить возможность частичной оплаты в двух POS-системах.
В ближайшее время доработаем админку, чтобы рестораны могли легко заходить в систему, видеть статистику и управлять данными. Можно будет решать проблемы, например, с зависшими транзакциями и некорректным отображением позиций в меню.
Планируем дать возможность ресторанам настраивать комиссии самостоятельно — чтобы систему можно было кастомизировать под экономику каждой конкретной сети.
Хотим создать демоверсию, чтобы заведения могли протестировать систему перед интеграцией — потенциально этот шаг может увеличить продажи продукта.
К февралю разработаем систему уведомлений для официантов, чтобы они отслеживали чаевые, статистику по заказам и другие данные.
Про локализацию на арабском мы уже сказали.
Команда
проекта
Бюджеты
Мы не из тех, кто на вопрос о цене говорит: «Отвечу в Директ». Поэтому вот вам табличка со стоимостью часа наших разработчиков. А на проект в общей сложности у нас ушло 1300 часов за 3 месяца работы.
DevOPS инженер
DevOps
3 500 ₽
Backend Lead (Python)
Back
3 600 ₽
Системный Аналитик
SA
3 100 ₽
Backend разработчик
Back
3 200 ₽
Бизнес Аналитик
BA
3 100 ₽
QA
QA
2 500 ₽
Арт Директор
ArtDir
3 100 ₽
Менеджер проектов
PM
2 500 ₽
Дизайнер
Des
2 900 ₽
Архитектор ИБ
IB
5 800 ₽
Frontend Lead (Next.js)
FrontLead
3 400 ₽
Flutter разработчик
Flutter
3 100 ₽
Frontend разработчик
Front
3 200 ₽