Инженерная
культура

Кто мы:
  • Профессионалы с большим опытом и молодые перспективные разработчики
  • Внимательные к деталям во всём: технологиях, подходах, коммуникациях, отношении к работе и коллегам
  • Отличаемся стремлением к достижению поставленных целей и открытостью взаимодействий внутри и между командами
  • Всегда рады новым коллегам, которые разделяют наши ценности и готовы развивать продукты r_keeper!
R_keeper — это надежный продукт с многолетней историей и экспертизой

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

Принципы
работы
Простота в использовании
Лучший код — это код, который не был написан
Не изобретаем велосипед
Просто инструмент
Не пытаемся предсказывать будущее
Ориентируемся на автономию и сервис
Используем как проверенные, так и инновационные решения
Простота в использовании

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

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

Для поиска подходящих технологий мы обращаемся к Tech Radar, опираясь на такие характеристики, как readability, simplicity, maintainability.

Пример

При проектировании новых систем не пытаемся использовать малопопулярные или малопонятные нам СУБД, делая выбор в пользу pg или sql server.

Мы понимаем что от них ждать, как их использовать и обслуживать.

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

Лучший код — это код, который не был написан

Любой код — это усложнение.

Добавление бизнес-логики в сервис или компонента в архитектуру должно быть взвешенным и обоснованным решением. Изменения в системе должны происходить исходя из нужд бизнеса, а не наоборот (когда бизнес меняется в ответ на изменения в IT).

Мы аргументируем, какую ценность несет в себе изменение и как это улучшит продукт.

Пример

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

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

Не изобретаем велосипед

Мы используем готовые сторонние решения, которые удовлетворяют нашим требованиям и помогают решать задачи. Это могут быть платные или open source решения.

Мы аргументируем, какую ценность несет в себе изменение и как это улучшит продукт.

Пример

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

Просто инструмент

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

Пример

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

Не пытаемся предсказывать будущее

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

Пример

При проектировании API для одного конкретного клиента мы стараемся удержаться от крайностей. С одной стороны не спроектировать интерфейс один в один под первого пользователя, без понимания, как в будущем этот API будет развиваться. С другой – не спроектировать максимально гибкий и универсальный API, который в будущем может подойти любому другому клиенту. Обе крайности нам не подходят: либо нам будет неудобно вносить изменения в API, развивая его для новых клиентов, либо 80% гибкости API никогда никому не понадобится. Решая сегодняшнюю задачу, мы готовимся к будущим изменениям и будущему развитию, но не пытаемся их предсказать.

Ориентируемся на автономию и сервис

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

  • DDD (Domain driven design)
  • Профиль нагрузки сервиса (баланс чтения/записи)
Пример

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

  • у сервиса своя команда, он запускается в отдельном процессе
  • независимый deployment
  • инкапсулированный data storage внутри сервиса (подход share nothing).
Используем как проверенные, так и инновационные решения

Мы используем как проверенные и популярные решения, так и пробуем новые и перспективные технологии.

Пример

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

Процессы
взаимодействия
Data-driven подход

Во всех видах коммуникаций мы стараемся ссылаться на данные, аналитику, цифры, оперируя фактами, а не гипотезами или личными догадками. Мы стремимся “покрыть” данными 98% всей внутренней разработки. Одно из важнейших правил — поддержка принятия решений и улучшение продуктов должна строится на основе непротиворечивых и объективных данных.

Ошибки — часть рабочего процесса

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

Brutal honesty

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

Фокус не на проблеме, а на ее решении

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

Мы ориентированы на результат

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

Люди
Мы адаптируемся и многому учимся
Самым важным для нас является то, насколько быстро мы адаптируемся под внешние изменения и новые условия. Если для того, что бы с успехом проходить трудности и достигать поставленных целей нам потребуется получить новые знания, мы постараемся освоить их как можно быстрее. Каждый новый день для наших сотрудников — это возможность повысить уровень своей экспертизы.
Экспериментируем разумно
Наша команда одна из первых на рынке стала делать продукты автоматизации ресторанного бизнеса и достигла высокого уровня экспертизы на рынке кассового ПО в России и за рубежом. Мы не боимся экспериментировать и стремиться проверять гипотезы быстро, дешево и безопасно для компании и наших клиентов. Мы знаем цену ошибкам, поэтому идем только на оправданные риски. В нашем бизнесе есть области, которые не допускают даже мельчайших ошибок.
Ищем мотивацию в прогрессе
Мы отмечаем наши успехи и двигаемся дальше. Наша мотивация — не останавливаться на достигнутом, искать способы для улучшения и становиться лучшей версией самих себя. Мы уверены, всегда есть способ добиться ещё более выдающегося результата.