Оценка зрелости инженерных процессов

Проверьте зрелость инженерных процессов вашей команды

Ответив на 50 коротких вопросов

(продолжительность ~ 15-20 минут) вы узнаете:

  1. На каком уровне находится ваша команда – от Chaos до Continuous Improvement
  2. Как вы выглядите по сравнению с другими компаниями
  3. Какие шаги дадут наибольший эффект именно в вашем контексте

Автор: Алексей Обыскалов

Выводы исследования в статье: Инженерная зрелость


Как рассчитывается результат

Ваша роль
Количество человек, включая разработчиков, девопсов, тестировщиков. Не включая бухгалтерию, сапорт, отдел продаж
1
250+
Есть отдельная роль QA‑лид
Есть отдельная роль SRE/DevOps
Есть отдельная роль PM/PO
Есть отдельная роль BA/Аналитики
Есть отдельная роль Security/Инфосек
Готовы вкладываться в улучшение процессов в ближайшие 3 месяца
Нет
Да
Были серьёзные инциденты за последние 30 дней
Релизы выполняются только из тегов
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Используете поэтапные выкладки/канареечные по умолчанию
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Есть формализованный DoD релиза и он реально используется
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Назначается владелец релиза (DRI) на каждый выкат
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Проводятся автоматические post‑deploy smoke/prod‑проверки
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Доля релизов с откатом/инцидентом (CFR) за 90 дней ≤ 10%
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Насколько вас устраивает текущая частота и предсказуемость релизов
Секция 1/10. Релизы. Эта секция показывает предсказуемость поставки. Здесь рождаются «быстрые победы» и самые заметные бизнес‑эффекты.
Совсем не устраивает
Полностью устраивает
Включён PR/MR size‑guard
Секция 2/10. PR‑процесс и ревью. Качество Pull Request/Merge Request (PR/MR) и ревью — главный источник скорости/качества без бюрократии.
Назначены CODEOWNERS по зонам ответственности
Секция 2/10. PR‑процесс и ревью. Качество Pull Request/Merge Request (PR/MR) и ревью — главный источник скорости/качества без бюрократии.
Средний возраст PR/MR ≤ 3 дней
Секция 2/10. PR‑процесс и ревью. Качество Pull Request/Merge Request (PR/MR) и ревью — главный источник скорости/качества без бюрократии.
В PR/MR есть «паспорт»: цель, тест‑ноты, план отката
Секция 2/10. PR‑процесс и ревью. Качество Pull Request/Merge Request (PR/MR) и ревью — главный источник скорости/качества без бюрократии.
Качество ревью (своевременность, по делу, 2+ профильных ревьюера)
Секция 2/10. PR‑процесс и ревью. Качество Pull Request/Merge Request (PR/MR) и ревью — главный источник скорости/качества без бюрократии.
Формальное или отсутствует
Всегда своевременное, глубокое, минимум 2 профильных инженера
Есть CI/CD (хотя бы CI со сборками и тестами)
Секция 3/10. CI/CD. Автосборка/автопроверки — основа дисциплины релизов
Тесты гоняются на каждый PR/MR автоматически
Секция 3/10. CI/CD. Автосборка/автопроверки — основа дисциплины релизов
Блокировки мержа при фэйле CI
Секция 3/10. CI/CD. Автосборка/автопроверки — основа дисциплины релизов
Пайплайны стандартизированы между репозиториями
Секция 3/10. CI/CD. Автосборка/автопроверки — основа дисциплины релизов
Есть защищённые ветки/окружения (protected) для продакшна
Секция 3/10. CI/CD. Автосборка/автопроверки — основа дисциплины релизов
Вас устраивает скорость и стабильность пайплайнов?
Секция 3/10. CI/CD. Автосборка/автопроверки — основа дисциплины релизов
Пайплайны медленные, часто падают, мешают работе
Пайплайны быстрые, стабильные, не создают блокировок
Используете фиче‑флаги/kill‑switch в продакшне?
Секция 4/10. Фиче‑флаги и релиз‑гейты. Нужны для безопасных выкладок и «стоп‑крана» без откатов.
Есть прод‑наблюдаемость (метрики/логи/трейсинг) на критическом пути Имеется ввиду critical user journey (CUJ) и критические интеграции
Секция 5/10. Наблюдаемость и SLO. Видимость и критерии качества защищают релизы от «слепых зон».
Определены SLI/SLO для ключевых потоков (доступность, p95/p99)
Секция 5/10. Наблюдаемость и SLO. Видимость и критерии качества защищают релизы от «слепых зон».
Есть burn‑rate алерты/пороговые правила по SLO
Секция 5/10. Наблюдаемость и SLO. Видимость и критерии качества защищают релизы от «слепых зон».
Post‑deploy проверки учитывают SLO (авто‑rollback/flag‑off)
Секция 5/10. Наблюдаемость и SLO. Видимость и критерии качества защищают релизы от «слепых зон».
Качество алертинга
Секция 5/10. Наблюдаемость и SLO. Видимость и критерии качества защищают релизы от «слепых зон».
Нет доверия
Шум алертов низкий, алерты и пейджеры разделены
Были ли серьёзные инциденты за 90 дней?
Секция 6/10. Инциденты. Структура и роли снижают MTTR и повторяемость.
Есть матрица SEV и назначение ролей IC/Scribe/Comms
Секция 6/10. Инциденты. Структура и роли снижают MTTR и повторяемость.
Средний MTTR ≤ 2 часов
Секция 6/10. Инциденты. Структура и роли снижают MTTR и повторяемость.
Приоритет стабилизации: flag‑off → rollback → fix‑forward ≤ 15 мин соблюдается
Секция 6/10. Инциденты. Структура и роли снижают MTTR и повторяемость.
Постмортемы с action items обязательны для SEV‑1/2
Секция 6/10. Инциденты. Структура и роли снижают MTTR и повторяемость.
Насколько вы довольны управлением инцидентами?
Секция 6/10. Инциденты. Структура и роли снижают MTTR и повторяемость.
Категорически недоволен
Полностью доволен
Есть автотесты (unit/integration/E2E)
Секция 7/10. Тестирование и среды. Автотесты и паритет сред защищают от регрессий.
Есть единый Engineering Handbook/гайд (живой, обновляемый)
Секция 8/10. Документация и инженерная культура. Короткие правила и живые документы уменьшают хаос.
Для значимых решений ведёте ADR/RFC
Секция 8/10. Документация и инженерная культура. Короткие правила и живые документы уменьшают хаос.
Онбординг и офбордонг инженера (чек‑листы + гайды) — есть оба, понятны и актуальны
Секция 8/10. Документация и инженерная культура. Короткие правила и живые документы уменьшают хаос.
Насколько вы довольны документацией на проекте?
Секция 8/10. Документация и инженерная культура. Короткие правила и живые документы уменьшают хаос.
У нас ее нет
Она просто идеальна
Запущены базовые security‑проверки в PR/MR (SAST/SCA)
Секция 9/10. Безопасность поставки. Базовые проверки безопасности встраиваются в обычный поток разработки.
Секреты/доступы управляются централизованно (Vault/Secret Manager), не в коде/файлах
Секция 9/10. Безопасность поставки. Базовые проверки безопасности встраиваются в обычный поток разработки.
Ведёте SBOM/подписываете артефакты (cosign/аналог)
Секция 9/10. Безопасность поставки. Базовые проверки безопасности встраиваются в обычный поток разработки.
Секция 10/10. Запрос и контекст
Направление деятельности компании
Секция 10/10. Запрос и контекст
Я могу внедрять изменения самостоятельно или апрувить их
Секция 10/10. Запрос и контекст
Готовы ли вы доверить внешнему эксперту решение точечных инженерных задач?
Секция 10/10. Запрос и контекст
Нет
Да
Контактная информация
Заполните Ваши контактные данные, чтобы получить результат по итогам опроса
Предпочитаемый способ связи
Политика конфиденциальности и использования данных
Мы сохраняем ответы анкеты и контактные данные — имя, e-mail и компанию — в одной записи.

Контактные данные нужны только для того, чтобы вы могли:
  • получить на e-mail PDF-файл с подробной аналитикой по исследованию (опрос 100+ респондентов о факторах, влияющих на инженерную зрелость).
  • получать информацию о наших открытых мероприятиях и курсах.
Мы не публикуем и не передаём эти данные третьим лицам.

Для аналитики и отчётов используем только обезличенные агрегированные данные без указания имён, компаний и e-mail-адресов.

При желании вы можете запросить удаление своих данных, написав на hardandsoft@hardsoftskills.dev
Ваша ситуация: Chaos of Engineering
Ваши инженерные процессы находятся в хаотичном состоянии.
Релизы выполняются вручную, нет формализованных правил и автоматизации, а инциденты решаются «по факту». Команда держится на инициативе отдельных людей, а не на системе.

Что стоит сделать в первую очередь:
  1. Ввести базовую CI/CD-сборку и автотесты на каждый PR.
  2. Назначать владельца релиза (DRI) и фиксировать DoD.
  3. Начать вести постмортемы и документацию по инцидентам.

После этих шагов появится контроль над релизами и предсказуемость результатов.

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

Ваш балл: из (%) • Уровень:

Ваша ситуация: Reactive Engineering
Вы реагируете на проблемы, но пока не управляете ими.
CI/CD уже внедрён частично, но релизы зависят от людей. Инциденты разбираются, но без системного анализа и улучшений.

Что улучшить:
  1. Формализуйте релизный процесс: релизы из тегов, канареечные выкладки, DoD.
  2. Определите метрики SLI/SLO и фиксируйте MTTR.
  3. Создайте базовый Engineering Handbook – место для регламентов и гайдов.

После внедрения этих практик команда перестанет работать «с пожаром в руках» и получит контроль над релизами, инцидентами и качеством поставки.

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

Ваш балл: из (%) • Уровень:

Ваша ситуация: Structured Engineering
У вас уже есть структура и повторяемые процессы.
CI/CD работает, код-ревью выстроено, инциденты анализируются, но практики разрознены между командами. Документация и стандарты не всегда актуальны.

Что поможет перейти на новый уровень:
  1. Стандартизируйте пайплайны и окружения между репозиториями.
  2. Введите CODEOWNERS и регулярные ревью архитектуры.
  3. Пересмотрите документацию: ADR, онбординг, чек-листы.

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

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

Ваш балл: из (%) • Уровень:

Ваша ситуация: Measurable Engineering
Процессы управляемы и измеримы.
Команда оперирует метриками, релизы стабильны, наблюдаемость внедрена, но ещё есть ручные зоны и зависимости.

Как закрепить результат:
  1. Добавьте auto-rollback и burn-rate алерты.
  2. Расширьте автоматические post-deploy проверки.
  3. Проводите регулярные “tech reviews” по инцидентам и архитектуре.

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

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

Ваш балл: из (%) • Уровень:

Ваша ситуация: Continuous Improvements Engineering


Вы достигли высокого уровня инженерной зрелости.
Вы достигли высокого уровня инженерной зрелости –процессы прозрачны, метрики понятны, культура постмортемов и улучшений встроена в ДНК команды.

Чтобы сохранять лидерство:
  1. Развивайте внутренние гильдии и менторство.
  2. Делитесь best practices внутри компании и вовне.
  3. Переходите к стратегическим улучшениям – performance culture и AI-инструменты в инженерии.

Следующий шаг:
Если хотите системно развивать инженерное лидерство и культуру улучшений, мы можем провести стратегический разбор результатов – обсудим, как масштабировать зрелость, performance-культуру и внедрение AI-инструментов.

Ваш балл: из (%) • Уровень:

Ваша ситуация: Chaos of Engineering
Ваши инженерные процессы находятся в хаотичном состоянии.
Релизы выполняются вручную, нет формализованных правил и автоматизации, а инциденты решаются «по факту». Команда держится на инициативе отдельных людей, а не на системе.

Что стоит сделать в первую очередь:
  1. Ввести базовую CI/CD-сборку и автотесты на каждый PR.
  2. Назначать владельца релиза (DRI) и фиксировать DoD.
  3. Начать вести постмортемы и документацию по инцидентам.

После этих шагов появится контроль над релизами и предсказуемость результатов.

Ваш балл: из (%) • Уровень:

Ваша ситуация: Reactive Engineering
Вы реагируете на проблемы, но пока не управляете ими.
CI/CD уже внедрён частично, но релизы зависят от людей. Инциденты разбираются, но без системного анализа и улучшений.

Что улучшить:
  1. Формализуйте релизный процесс: релизы из тегов, канареечные выкладки, DoD.
  2. Определите метрики SLI/SLO и фиксируйте MTTR.
  3. Создайте базовый Engineering Handbook – место для регламентов и гайдов.

После внедрения этих практик команда перестанет работать «с пожаром в руках» и получит контроль над релизами, инцидентами и качеством поставки.

Ваш балл: из (%) • Уровень:

Ваша ситуация: Structured Engineering
У вас уже есть структура и повторяемые процессы.
CI/CD работает, код-ревью выстроено, инциденты анализируются, но практики разрознены между командами. Документация и стандарты не всегда актуальны.

Что поможет перейти на новый уровень:
  1. Стандартизируйте пайплайны и окружения между репозиториями.
  2. Введите CODEOWNERS и регулярные ревью архитектуры.
  3. Пересмотрите документацию: ADR, онбординг, чек-листы.

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

Ваш балл: из (%) • Уровень:

Ваша ситуация: Measurable Engineering
Процессы управляемы и измеримы.
Команда оперирует метриками, релизы стабильны, наблюдаемость внедрена, но ещё есть ручные зоны и зависимости.

Как закрепить результат:
  1. Добавьте auto-rollback и burn-rate алерты.
  2. Расширьте автоматические post-deploy проверки.
  3. Проводите регулярные “tech reviews” по инцидентам и архитектуре.

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

Ваш балл: из (%) • Уровень:

Ваша ситуация: Continuous Improvements Engineering


Вы достигли высокого уровня инженерной зрелости.
Вы достигли высокого уровня инженерной зрелости –процессы прозрачны, метрики понятны, культура постмортемов и улучшений встроена в ДНК команды.

Чтобы сохранять лидерство:
  1. Развивайте внутренние гильдии и менторство.
  2. Делитесь best practices внутри компании и вовне.
  3. Переходите к стратегическим улучшениям – performance culture и AI-инструменты в инженерии.

Ваш балл: из (%) • Уровень: