Как устроена инженерная культура Neo Group

В Neo Group шесть продуктов и несколько команд разработки. Они пишут на разных языках и решают разные задачи, но подчиняются одному набору договорённостей. Эти договорённости не записаны в толстом регламенте — их всего несколько, и они скорее про то, как принимать решения, чем про то, как форматировать код.

Решение принимает тот, кто будет его поддерживать

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

Дизайн-ревью до кода, а не после

Крупные изменения обсуждаются документом на одну-две страницы: что меняем, почему, какие альтернативы рассматривали и чем платим. Час обсуждения на этом этапе стоит дешевле, чем переписывание готового сервиса. Документ остаётся в репозитории — через полгода он объясняет новому человеку, почему всё сделано именно так.

Разбор инцидентов без поиска виноватого

После каждого сбоя в продакшене команда собирается и разбирает случившееся. Вопрос «кто это сделал» на разборе не звучит: если ошибка одного человека может уронить продакшен, проблема не в человеке, а в том, что её ничто не остановило. Итог разбора — не выговор, а изменения в коде, тестах или процессе.

Дежурство — общее

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

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