Привет, мы компания r_keeper. Вы точно бывали в ресторанах, которые используют нашу систему автоматизации — от KFC и Burger King до Ginza Project и Novikov Group. А всего мы внедрили ее в 65 000 заведений в 53 странах мира. Здесь мы будем писать о своем опыте продуктовой разработки и интересных кейсах. А пока хотим познакомиться и поделиться тем, как устроена работа инженеров в r_keeper. Рассказывают Тимур Нурутдинов и руководители отделов Сергей Устимов и Алан Ортабаев.
Про нас: 30 лет — полет нормальный
Мы занимаемся автоматизацией уже 30 лет — начинали, когда во всей Москве было несколько крупных ресторанов. Сейчас их тысячи, и для каждого у нас есть решение: мобильные кассы, которые работают прямо на планшетах официантов, — для небольших заведений, сложные кастомизированные системы — для крупных сетей вроде «Шоколадницы» или Subway.
Рестораны цифровизируются непрерывно, и r_keeper эволюционирует вместе с ними. Еще лет 15 назад мы не использовали средства командной разработки, запросто обходились без системы контроля версий, CI/CD и автосборки. Файлами обменивались по сети или прямо по почте, а рабочие версии продуктов уходили клиентам с машин разработчиков. Многое делали самостоятельно — например, кроссплатформенные фреймворки работы с графикой, сетью, многозадачностью.
Теперь все иначе: изменились приоритеты, требования к безопасности, усложнился продукт, появилось много сетевых заведений на 300 и даже больше точек, рестораны стали более требовательны к скорости изменений. Мы перешли на итеративную разработку, чтобы более точно планировать релизы, оценивать промежуточный результат и при необходимости корректировать процесс, быстрее поставлять клиентам новые решения.
Про архитектуру: касса плюс десятки модулей
Центр архитектуры r_keeper — касса, вокруг которой выстроена целая экосистема продуктов — они подключаются как модули.
Это собственные продукты r_keeper: системы бронирования и лояльности, приложения для мобильных официантов и доставки. Плюс мы поддерживаем несколько открытых API, которые позволяют партнерам проводить интеграции своих решений с кассой и нашим облаком.
Также касса «дружит» с разными девайсами от сторонних производителей — от фискальных регистраторов, сканеров штрихкодов и 3D-сканеров для распознавания блюд до промоэкранов и киосков самообслуживания.
Про приоритеты: облака и большие данные
Сейчас у нас несколько приоритетов разработки — то, что нужно рестораторам больше всего.
Клаудификация
Мы даем возможность ресторанам подключить кассу через облако и не тратить время и силы на развертывание собственного сервера. Так клиенты экономят на железе, а мы можем быстро предоставлять им актуальную версию ПО и легко адаптировать систему под конфигурацию заведений. Часть наших продуктов работает только из облака: система лояльности, система управления персоналом, решение для доставки и отдельный функционал системы бронирования. Все они пишутся на .NET, для базы данных используются PostgreSQL и Redis, для асинхронных операций и обмена данными — RabbitMQ и Kafka, для сбора метрик и логов — Grafana, Prometheus и ELK.
Чтобы рестораторам было удобно управлять подключенными модулями, мы сделали облачную «менеджерскую» — r_keeper Office, он работает в режиме одного окна и открывается из браузера.
Развитие доставки
Пандемия вывела доставку в топ, а тренд на dark kitchen полностью меняет рынок. Раньше бизнес-процессы были выстроены под то, что гость приходит в ресторан, ужинает и оплачивает счет, теперь же нужно готовить и доставлять блюда к порогу. Мы даем ресторанам полноценный многофункциональный инструмент для запуска собственной доставки.
Маркетплейсы
Пока работаем над полуавтоматизированным вариантом подключения к маркетплейсам, дальше перейдем к полностью автоматическому: у клиентов в личном кабинете просто появится кнопка «Подключить Delivery Club» или «Подключить Яндекс.Еду». Решение будет работать в облаке и полностью избавит сотрудников ресторана от необходимости понимать технические аспекты — больше никакой ручной настройки.
Репортинг и аналитика данных
Сейчас все больше ресторанов хотят понимать своих гостей, а мы даем им инструмент для аналитики данных и прогнозирования неких паттернов поведения прямо из облака.
Про стек технологий: r_keeper на радаре
30 лет на рынке — это не только огромный опыт и экспертиза, но и большой техдолг. Кассе r_keeper как продукту 29 лет, текущую версию мы начали писать больше 10 лет назад на Delphi / C Builder, а сейчас постепенно мигрируем на .NET и Kotlin. На ее архитектуру наложило заметный отпечаток то, что раньше кассовая система работала не только под Windows, но и под DOS, в котором использовались свои многозадачность, сетевой стек и собственная графика. У других продуктов тоже большой жизненный цикл: часть из них была выпущена в 2000-х годах и поддерживается до сих пор, в некоторых продолжаются доработки. Отдельные компоненты для разных клиентов мы пишем на новых языках.
В какой-то момент мы поняли, что надо структурировать наш стек, и составили технологический радар компании.
Посмотреть r_keeper TechRadar
Все технологии разделены на четыре сектора: Platform & Infrastructure, Data Management, Tools, Languages & Frameworks. Внутри сектора технологии разделены на слои: активно используем, в заморозке (техдолг / не используем в новых проектах), готовимся применять в production, исследуем.
Для нас выбор стека — это всегда баланс стоимости разработки новых и поддержки текущих решений, возможности быстрого найма специалистов и нашей оценки перспективности решения. Поэтому, например, мы используем .NET (c#), который давно популярен в России и получил «второе дыхание» с выходом .NET core, и Typescript — суперпопулярную и перспективную технологию для frontend-разработки.
Про разработчиков: 120 старичков и новичков
Над продуктами r_keeper сейчас работает около 120 разработчиков: в основном в двух центрах разработки в Москве и Воронеже, некоторые удаленно. Вместе с новым специалистами работают и те, кто в r_keeper уже 15—20 лет: из первых пяти нанятых разработчиков четверо все еще в команде.
В нашей истории много кейсов, когда ребята вместе с компанией и ее продуктами вырастали до team lead или до руководителей отделов. И в команду мы берем тех, кто готов учиться, ставить перед собой цели и выкладываться для их достижения. Стандартного обучения нет, но по запросу доступно многое — от тренингов и конференций до образовательных программ нашей головной компании Mail.ru Group.
Чаще всего люди приходят в r_keeper, потому что хотят поработать с современным технологическим стеком. Например, в одном из продуктов мы активно используем Flutter и Kotlin Multiplatform. В другом, где в качестве API для frontend личного кабинета применяется GraphQL, мы внедряем технологию GraphQL-federation, чтобы команды могли оставаться автономными и поставлять части API по своему продукту независимо от других разработчиков. А чтобы решить проблему монолита на стороне frontend, мы внедрили технологию WebPack Module Federation и фреймворк Vue.js — тут r_keeper в числе первопроходцев.
У нас нет строгих корпоративных правил, зато есть определенная свобода как в выборе решений, так и в направлении развития. Много интересных задач и понятные правила инженерной культуры. Но главное — ребятам нравится, что они могут оценить свой продукт «вживую»: достаточно просто сходить в ресторан или заказать доставку.
Кажется, самое главное о «внутренней кухне» r_keeper мы рассказали — пишите в комментариях, если остались какие-то вопросы. Обязательно ответим, а совсем скоро вернемся с новыми статьями в блоге. Планируем делиться опытом разработки, интересными кейсами, экспертизой наших инженеров. Уже в ближайшее время расскажем, как выбирали связку KMM + Flutter для одного из наших мобильных проектов (и что из этого вышло после рабочего внедрения).
Комментарии (3)
OlegStrekalovsky
11.08.2021 13:08Теперь DoDo узнали где ещё можно хантить .Net разработчиков, которые ещё и с их областью деятельности знакомы :)
morfius86
Работал 8 лет интегратором продуктов компании UCS. С приходом RKeeper7 стало лучше, но он концепции "модуль модулем погоняет" стало уже тошнить. Особенно доставляло "удовольствие" все эти модули настраивать. В целом все гибко, но от всего этого хотелось повешаться.
snap01
Но тут стоит отметить, что:
1. В одном заведении используют не больше 10% реализованного функционала.
2. На одном рабочем месте используют не больше 30% от используемого на предприятии.
Может быть было бы неплохо иметь удобные средства быстрой установки и базовой настройки модулей. Но ставят систему обычно профессионалы, а не любители. У меня не было особых проблем с настройкой связи отдельных модулей после нескольких установок. А вот если раз в год что-то редкое настраивать, не зная какие настройки в этом модуле вообще существуют, то дело может затягиваться, да.