Давай немного поговорим про инженерную культуру. Я наткнулся на классную статью коллег из Райфайзен Банка про то, как они выстраивают практики разработки и эксплуатации в огромной распределённой команде и как системно измеряют техническую зрелость. Ребята работают в контексте сотен команд и тысяч айтишников, и у них инженерная культура — это не абстракция, а вполне конкретный набор практик, метрик и стандартов, которые помогают договориться “как мы делаем работу” и не изобретать велосипеды в каждом углу. Интересный ход — метрика Pain Index: по сути, это агрегированная «боль клиента», которая складывается из всех технических решений, ошибок, недотестированных релизов и провалов в эксплуатации. Она становится ориентиром: любые изменения в процессах и инфраструктуре смотрят через призму того, как это влияет на Pain Index. Параллельно с этим команда последовательно внедряет базовые практики: CI/CD, автотесты, code review, trunk based development, логирование, мониторинг, DR-тесты. Причём фокус не только на “галочках”, а на том, чтобы всё это реально жило в ежедневной работе команд. Круто, как они эволюционировали от жёстких IT-стандартов к «лучшим практикам», которые перестали быть формальной обязаловкой и стали чем-то вроде гигиены. В какой-то момент стало понятно, что заставлять команды “чистить зубы” по регламенту — тупиковая история. Вместо этого Райф сместил акцент на инженерную культуру и техническое совершенство, а практики обернул внутрь платформы разработчика и внутренних сервисов, максимально автоматизировав оценку: доля ручных проверок упала, а adoption практик при этом вырос. Следующий шаг — формализация «Culture of Engineering» через цели и метрики: Time-to-Market, Reliability & Resilience, работа с легаси, SLA/инцидент-менеджмент. Они пересобрали привычные DORA-метрики под свои реалии, сделали прозрачные дашборды и дали командам инструмент самодиагностики: видно, как часто вы деплоитесь, сколько живут задачи, насколько устойчиво ведут себя системы и как всё это влияет на Pain Index. В итоге получается хорошая иллюстрация того, что инженерная культура — это не мотивационный плакат, а долгий путь: стандарты → практики → платформа → метрики и, в конечном счёте, общая ответственность за качество и скорость изменений. Ссылку оставлю здесь, рекомендую почитать первоисточник: https://habr.com/ru/companies/oleg-bunin/articles/585640/