Используемая технология должна быть максимально прозрачна для разработчика. Мы поощряем поиск наиболее простых и понятных путей решения задачи. Там, где это возможно, используем принятый в компании технологический стек, вместо того чтобы создавать изолированную область системы с высоким порогом входа и низким уровнем внесения изменений. Для поиска используемых технологий мы обращаемся к Tech Radar. Основными характеристики здесь становятся readability, simplicity, maintainability.

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

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

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

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

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

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

Мы предпочитаем небольшие сервисы, по возможности с минимальным количеством кода. Проектируемый сервис должен быть максимально автономен, а значит и иметь целостную, единую зону ответственности. Под автономностью сервиса мы подразумеваем его запуск в отдельном процессе, независимый deployment, инкапсулированный data storage внутри сервиса (подход share nothing).

Мы стремимся к асинхронному взаимодействию и event driven сервисам там, где это возможно. Services producers отправляют события в стрим данных. Другие services consumers подписываются на определенные события. Взаимодействие между сервисами становится неблокирующим. Мы используем такие подходы, как Inner Source, Release Train, Feature toggle и многие другие для поддержания неблокирующих процессов.

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

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

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

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

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

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

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

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

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

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