Инженерная культура в IT-компании: как она устроена в проектной модели

Инженерная культура в IT — это принципы, практики и привычки, по которым команда разработки принимает технические решения, проверяет код, разбирает ошибки и передаёт знания. В проектной компании у неё два контура. Первый — ядро компании, которое инженер несёт с собой (код-ревью, тесты, ADR, постмортемы, онбординг). Второй — процессы, стек и регламенты заказчика. Измеряют её не одной цифрой, а метриками поставки DORA и пятью измерениями SPACE. Держится всё на передаче знаний между проектами.

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

Что такое инженерная культура в IT простыми словами

Инженерная культура в IT — это то, как команда разработки на деле обращается с кодом, рисками и ошибками. Ценности на сайте — дело десятое.

Инженерная культура — это набор принципов, подходов и ценностей, которые определяют, как работает и взаимодействует техническая команда (формулировка CTO OBRIO, mind.ua, 04.03.2025).

От корпоративной культуры она отличается предметом. Корпоративная отвечает на вопрос «как мы относимся к людям», инженерная — «как мы относимся к коду, решениям и инцидентам». От набора инструментов — тем, что инструмент покупается за день, а привычка делать маленькие пул-реквесты вырабатывается месяцами. Речь о культуре разработки, вузовское понятие ни при чём.

Для оценки удобна типология Рона Веструма (Westrum, 2004, BMJ Quality & Safety): три типа организаций по тому, как в них течёт информация.

DORA (исследовательская программа Google Cloud) считает культуру с высоким доверием и свободным потоком информации предиктором результатов поставки ПО и результатов организации (dora.dev, Generative organizational culture). Генеративная культура по Вестраму — по сути, рабочее описание психологической безопасности в команде.

Из чего состоит инженерная культура: 7 практик команды разработки

Инженерная культура команды разработки складывается из семи практик: код-ревью, CI/CD и автотесты, ветвление и Definition of Done, ADR, blameless-постмортем, работа с техдолгом и онбординг. Ценности без практик — плакат в переговорке. Практики без ценностей — карго-культ.

Российские цифры есть у Райффайзенбанка (Хабр, 21.10.2025). С 2019 года банк стандартизирует практики в 262 agile-командах и 14 сообществах, считает 82 метрики по 10 практикам на 1 556 GitLab-проектах и сопоставляет их с DORA. В топ-5 попали ветвление, интеграция и сборка, деплой и релиз, код-ревью, автотесты. Вместе практики дают более заметный эффект, особенно на долю неудачных изменений (Change Fail %). Оговорки: данные одной in-house компании, и это корреляция, не причинность.

Код-ревью: зачем оно на самом деле

Код-ревью принято считать фильтром дефектов. Главный его результат другой — передача знаний. В исследовании Microsoft (Bacchelli, Bird, ICSE 2013) разработчики называли главной целью поиск дефектов, но на деле ревью связано с ними слабее, чем ожидалось. Зато даёт передачу знаний, осведомлённость команды и альтернативные решения. Главная трудность — понять изменение. Google (Sadowski и др., ICSE SEIP 2018) изучал ревью на 9 млн изменений, 12 интервью и опросе 44 разработчиков.

Как проводить код-ревью, чтобы оно передавало знания? Правил два. Малый размер изменения (пул-реквест на 3 000 строк получает «LGTM» не потому, что хорош). И SLA на ревью — оговорённый срок первого ответа.

ADR (architecture decision record) — это короткий документ, фиксирующий одно архитектурное решение, его контекст и последствия.

Формат предложил Майкл Найгард 15.11.2011. Пять полей ADR:

1. Заголовок.

2. Контекст.

3. Решение.

4. Статус: предложено, принято, устарело, заменено.

5. Последствия.

Польза видна через год, когда новичок спрашивает, почему здесь очередь, а не прямой вызов. Без журнала архитектурных решений ответ ушёл вместе с автором. 

Blameless-постмортем: разбор инцидента без поиска виноватых

Blameless-постмортем — это разбор инцидента, который ищет причины в системах и процессах и не обвиняет человека или команду.

Определение — из главы «Postmortem Culture» Google SRE Book (John Lunney, Sue Lueder, 2016). Исходная посылка: все действовали из лучших побуждений, чинить надо системы. Триггеры постмортема задают заранее:

• видимый пользователю простой;

• любая потеря данных;

• вмешательство дежурного;

• долгое восстановление;

• сбой мониторинга.

Почему в проектной компании инженерная культура живёт в двух контурах

Инженерная культура в проектной IT-компании состоит из двух контуров: ядра компании, которое не меняется от проекта к проекту, и контура заказчика — его SDLC, регламентов, стека, репозитория и требований ИБ. Разборы темы обычно пишут про in-house компанию, где контуры совпадают. В аутсорсе они не совпадают никогда. Инженерная культура в аутстаффе уязвима вдвойне: специалист месяцами живёт в чужом процессе. Если ядро не сформулировано явно, через год у инженера с собой остаётся одно резюме.

Правило совмещения простое. Суть не меняется: тесты, след решений, разбор ошибок без поиска виноватых. Форма подстраивается (инструменты, шаблоны, релизный процесс). Всё, что меняет процесс заказчика, сначала согласуют с ним.

Инженер в команде заказчика: что сохраняем, а что адаптируем

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

Онбординг разработчика на проект заказчика: первые 2–4 недели

Онбординг на проект заказчика двойной: инженер входит и в домен, и в процессы. Логика чек-листа:

1. До выхода. Заявки на доступы поданы заранее. Ожидание доступов — самая частая потеря первой недели.

2. Дни 1–3. Назначен бадди, разобраны архитектура и границы системы, окружение собирается по инструкции.

3. Неделя 1. Первый небольшой мерж через весь путь: ревью, CI, деплой на стенд.

4. Недели 2–3. Самостоятельная задача, ревью чужого кода, знакомство с процессом инцидентов.

5. Недели 3–4. Разговор с бадди и тимлидом по заранее заданному критерию выхода на продуктивность.

Если у заказчика разбор инцидента сводится к поиску виноватого, разборов делают два. Внутри команды по канону SRE Book: хронология, системные причины, задачи. Для заказчика — причина, влияние, исправление, профилактика. Без оценок людей.

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

Как знания переходят между проектами: гильдии, чаптеры и база решений

Знания в проектной компании переходят между проектами через гильдии и чаптеры, внутренние митапы и общую базу решений. Без них каждый уход инженера обнуляет опыт, и bus factor так и остаётся равным единице.

Гильдия — это сообщество инженеров из разных команд, объединённых общей темой или стеком, а не общим проектом.

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

Исследование гильдий Spotify (Šmite, Moe, Levinta, Floryan; интервью 2018, публикация 2019): гильдии собирают инженеров из разных команд и локаций и снижают зависимость от документации. Типов четыре:

• книжный клуб, где вместе изучают тему;

• open-source-сообщество с общим кодом из разных команд;

• линия поддержки, куда приходят с вопросом;

• комитет по стандартизации, который держит общие стандарты разработки.

Работают гильдии при четырёх условиях: общая цель, спонсорство руководства, регулярные встречи, видимая ценность. Пропадает одно — и в календаре остаётся встреча, на которую приходят трое. Второй слой — база типовых решений. ADR из контура заказчика остаётся у заказчика под NDA, а обезличенный паттерн может жить во внутренней базе. Наша практика: [ДАННЫЕ iFellow: какие сообщества и гильдии есть, по каким стекам, сколько, частота встреч, есть ли база ADR и постмортемов].

Как измерить инженерную культуру: DORA, SPACE и метрики проектной компании

Инженерную культуру нельзя измерить одной цифрой, но можно измерить её следствия: поставку по DORA и продуктивность по SPACE.

DORA-метрики — это четыре показателя эффективности поставки ПО: частота деплоя, время от коммита до продакшена (lead time изменений), доля неудачных изменений и время восстановления сервиса.

SPACE framework — это модель продуктивности разработчиков из пяти измерений: удовлетворённость и благополучие, результат, активность, коммуникация, эффективность и поток (Forsgren, Storey, Zimmermann и др., ACM Queue, 2021).

Главный вывод SPACE: продуктивность к одной метрике не сводится. Коммиты и строки кода в роли KPI культуру ломают. Команда учится оптимизировать их вместо работы. И DORA-метрики подрядчику доступны не всегда: пайплайны и инциденты принадлежат заказчику.

Какие метрики отслеживаем мы: [ДАННЫЕ iFellow: перечень метрик — DORA там, где есть доступ, eNPS, удовлетворённость, ротация, время онбординга; без значений, если раскрывать нельзя].

AI-ассистенты и инженерная культура: что показали DORA 2024 и 2025

AI-ассистенты в разработке усиливают ту инженерную культуру, которая уже есть: в слаженных командах ускоряют работу, во фрагментированных обнажают слабые места. Так формулирует отчёт DORA 2025, называя AI «зеркалом и мультипликатором» (Google, 23.09.2025).

По данным отчёта DORA 2024 (Google Cloud, 22.10.2024), рост внедрения AI на 25% связан с такими изменениями показателей:

Это оценка связи, а не эффект. 39% респондентов почти или совсем не доверяют коду, который написал AI. Там же два наблюдения: нестабильные приоритеты тормозят работу даже при сильном лидерстве, а здоровая культура снижает выгорание.

По данным DORA 2025 (около 5 000 респондентов, 23.09.2025), AI используют 90% специалистов, рост на 14% за год, медиана — около 2 часов в день. Больше 80% видят рост продуктивности. При этом сильно доверяют AI лишь 24%, а 30% доверяют мало или совсем нет. Связь AI с нестабильностью поставки сохраняется (Splunk, 09.10.2025). Модель DORA AI Capabilities (Google Cloud, 10.12.2025) называет семь способностей:

1. Ясная и донесённая до команд позиция компании по AI.

2. Здоровая экосистема данных.

3. Доступ AI к внутренним данным.

4. Сильные практики контроля версий.

5. Работа малыми партиями.

6. Фокус на пользователе.

7. Качественные внутренние платформы.

Инструментов в списке нет. Сплошь инженерные практики. Без ревью, малых партий и контроля версий AI ускорит одно — накопление нестабильности.

Как проверить инженерную культуру подрядчика или будущего работодателя

Инженерную культуру подрядчика или работодателя проверяют вопросами о конкретных практиках. Общие ответы про «высокие стандарты» — уже сигнал. По данным ЭКОПСИ (Хабр, 20.03.2026; 30 123 IT-специалиста, 691 компания), качество продукта шестой год подряд остаётся первым фактором привлекательности работодателя. Общие ценности поднялись на 2-е место, «сильная профессиональная среда» прибавила в значимости, а зарплата опустилась со 2-го на 4-е. По данным Stack Overflow Developer Survey 2025 (29.07.2025), работой довольны 25% разработчиков; больше всего им нужны автономия и доверие, осмысленные задачи, оплата. Среда ценится не меньше рук, см. о рынке джунов в 2026 году.

За инженерную культуру отвечают три уровня. CTO задаёт рамку и выделяет на практики время. Тимлиды эти практики держат, команда воспроизводит. Выпадет один уровень, и практика превратится в формальность.

Частые вопросы 

Что такое инженерная культура простыми словами?

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

Как построить инженерную культуру в компании с нуля?

Построить инженерную культуру в компании с нуля проще всего с трёх практик. Это код-ревью с оговорённым SLA на первый ответ, CI-проверки, которые при красной сборке блокируют мерж, и blameless-постмортем после инцидентов. По данным Райффайзенбанка (Хабр, 21.10.2025), в совокупности практики связаны с результатом сильнее, поэтому внедряют их пакетом. Остальные практики описаны в разделе о семи практиках.

Кто отвечает за инженерную культуру: CTO, тимлиды или сама команда?

За инженерную культуру отвечают все три уровня одновременно. CTO задаёт рамку и выделяет время на практики, тимлиды держат практики в ежедневной работе, команда воспроизводит их в каждом изменении. Если один уровень выпадает, практика становится формальностью: ревью ставят «для галочки», постмортемы пишут без задач.

Что такое blameless-постмортем и зачем он нужен?

Blameless-постмортем — это разбор инцидента, который ищет причины в системах и процессах и не обвиняет человека или команду (Google SRE Book, глава «Postmortem Culture», 2016). Нужен он затем, чтобы о проблемах сообщали, а не прятали их. Триггеры задают заранее: простой для пользователей, потеря данных, вмешательство дежурного, долгое восстановление, сбой мониторинга.

Какие метрики показывают уровень инженерной культуры?

Уровень инженерной культуры показывают четыре метрики DORA (частота деплоя, lead time изменений, доля неудачных изменений, время восстановления) и пять измерений SPACE (ACM Queue, 2021). Райффайзенбанк связывает с DORA 82 метрики практик на 1 556 GitLab-проектах (Хабр, 21.10.2025). Но это корреляции, и получены они в одной компании.

Можно ли сохранить инженерную культуру, если разработчик работает в команде заказчика?

Сохранить инженерную культуру в команде заказчика можно, если разделить суть и форму. Суть инженер несёт с собой: тесты, ревью, письменную фиксацию решений, разбор ошибок без поиска виноватых. Форму (инструменты, шаблоны, релизный процесс) берёт у заказчика. Держится это на гильдиях и общей базе решений.

Чем инженерная культура в аутсорсе отличается от культуры в продуктовой компании?

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