Какой уровень выгорания ИТ⁠-⁠инженеров и как управлять их результативностью в 2025 году

Всем привет! Меня зовут Эдуард и я Ex. Tech Unit Lead из компании Skyeng.

Управляя командами разработки я познакомился с гайдом, который дополняет классическую методологию Scrum и увеличивает эффективность работы в IT⁠-⁠командах. Хотел бы поделиться этими знаниями со всеми заинтересованными.

В данном обзоре я как Ex. Tech Unit Lead из компании Skyeng расскажу об уровне выгорания IT⁠-⁠инженеров и опыте в управлении их результативностью в условиях нарастающей скорости необходимых изменений в разработке технологических продуктов в 2025 году.

Это методологическая обзорная заметка на гайд по управлению IT⁠-⁠командой, где я представлю несколько проверенных инструментов, которые дополняют Scrum и Kanban технологии и при внедрении показали интересные результаты.

Заметка получилась объемом около 1000 символов и состоит из двух частей: в первой я дам небольшой общий обзор на проблемы и метрики в управлении IT⁠-⁠командами, которые которые хотел бы рассмотреть. А во второй — краткое описание гайда по управлению IT⁠-⁠командой и описание примененных методик, которые показали положительные результаты.

По данным cnews в 2025 году наблюдается снижение текучести кадров среди IT⁠-⁠инженеров у большинства компаний, при этом разброс в этом показателе удивительно высокий 6 — 15%, более чем в два раза. Это соответствует моим наблюдениям и среди IT⁠-⁠команд внутри одной и той же компании на примере EdTech..

Такой же разброс можно наблюдать и в двух остальных ключевых метриках — скорость релиза новых “фич” и показателю утилизации времени IT⁠-⁠инженеров. На моей практике работы в метрико-ориентированных компаниях руководители традиционно замеряют и следят за динамикой этих трех главных метрик кроме традиционного eNPS (Employee Net Promoter Score) во всех IT⁠-⁠командах, ведь один спринт разработки может доходить в стоимости до 1,5 миллионов рублей и более.

Почему у IT⁠-⁠команд, работающих в одной корпоративной культуре, по одним и тем же технологиям Scrum или Kanban, с одними и теми же уровнями опыта сотрудников их эффективность может отличаться более чем на 100%?

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

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

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

Присмотревшись к процессам работы можно увидеть, что у данной команды три бэклога задач вместо одного, как указывает традиционная методология Scrum — не только Product Backlog, но еще и Tech backlog и Bug backlog. У каждого из них есть отдельный ответственный, например Tech backlog находится под управлением Тим. лида, а Bug backlog под управлением старшего QA⁠-⁠инженера. Еще для каждого из данных бэклогов есть регулярные встречи по оценке и приоритезации задач и каждый из них имеет “квоту” в сторипоинтах каждого спринта.

Таким образом IT⁠-⁠архитектура поддерживается в долгосрочной перспективе должным образом, система не “падает”, а баги никогда не накапливаются.

Звучит просто, верно? Но именно с помощью таких восьми описанных и внедренных “надстроек” к Scrum и Kanban методологиям мой коллега IT Project Manager Lead Денис Шишкин смог системно показать улучшение ключевых метрик и общей эффективности более чем на 25 процентных пунктов в восьми IT⁠-⁠командах разных компаний. Собирая и тестируя лучшие практики надстроек IT⁠-⁠команд в банковском секторе, а затем в EdTech — Скайенг (где мы с ним и познакомились), была описана методология работы, которая успешно дополняет классические Agile модели с учетом текущих реалий постоянного повышения требований в скорости разработки и внедрения автоматизаций с помощью ИИ.

Данная методология (или гайд) называется Agile-Oriented Flow Framework (AOFF) и далее во второй части обзора я хочу выделить на мой взгляд самые ключевые ее инструменты, которые решают ряд реальных проблем, с которыми мы сталкиваемся.

По замерам мы определяли, что теряется до 30% дорогостоящего времени разработчиков на малоэффективные встречи и общение в переписках с колллегами из других команд вместо обдумывания решений для текущих задач и написанию кода.

Ниже несколько протестированных надстроек из гайда, которые дали результат после первых двух спринтов:

1) Разделение ролей в команде.

Scrum традиционно предусматривает только 3 роли (Product Owner, Scrum Master, Dev Team), в описанной методологии не смотря на кол⁠-⁠во сотрудников в команде важно распределить и четко обозначить границы ответственности для каждой из семи ролей. Таким образом, разработчики и инженеры по тестированию во время текущего спринта не участвуют в продуктовых и других дискуссиях, текстовых и онлайн если задача не дошла до обсуждения методов реализации, а на всех первичных обсуждениях принимают участие специально определенные роли сотрудников, от которых нет ожиданий и планов по выдаче нужного капасити. Делюсь с вами этими ролями:

• IT Project Manager — Взаимодействие со стейкхолдерами и внутренними клиентами, приоритизация бизнес-задач.
• Tech Lead — Разработка архитектурной стратегии и технического дизайна сложных проектов. Наставничество и обучение для developers.
• Lead QA — Приоритизация баг⁠-⁠бэклога, межкомандная коммуникация, менторинг и поддержка QA⁠-⁠специалистов.
• Manual QA — Проверка выполненных задач и критериев качества, работа с тикетами поддержки, создание баг⁠-⁠репортов и их эскалация.
• Automation QA — Разработка и поддержка автоматизированных тестов.
• Developer — Оценка задач, реализация технических решений, первичное тестирование, релиз и мониторинг пост⁠-⁠релиза.
• On⁠-⁠Duty Developer — Мониторинг систем и алертов, срочные “хотфиксы”, логирование технических багов.

2) Технология работы с “влетными” то есть незапланированными в спринте задачами.

Гайд подразумевает, что выделенная роль IT Project Manager оценивает совместно с заказчиком незапланированные задачи — насколько риски (продуктовые, репутационные и другие) от невыполнения такой срочной задачи выше выполнения запланированных целей текущего спринта (да, гайд подразумевает, что в каждый спринт прописываются цели). При принятии положительного решения в обязательном порядке закладывается время на оценку, составление технического решения и тестирование данной задачи, а не только на ее выполнение.

Протестированные надстройки из гайда:

1) Методика квартального планирования и межкомандной синхронизации с декомпозицией и оценкой проектов для IT⁠-⁠команд. На выходе этого процесса мы получили сверстанный план спринтов на 1 или 3 месяца в зависимости от подразделений, в который закладывается ресурс на задачи по поддержке и развитию архитектуры, а так же на решение багов, которые традиционно закрываются быстрыми “костыльными” решениями по ходу работы над проектами.

2) Дополненные критерии оценки задач разработчиков. Методология предусматривает, чтобы оценка в сторипоинтах проставлялась с учетом трех ключевых критериев: сложность разработки, риск багов и потенциальный объем необходимого написанного кода. Еще метод оценки предусматривает конкретно ограниченные стори поинты для оценки задач. Это позволяет уравнять оценки одной и той же задачи от разных уровней IT⁠-⁠инженеров и получить высоко предсказуемое планирование IT⁠-⁠команды с точностью до 90% выполнения задач спринтов в течение года. Я напишу данные ограниченные числа и предоставлю уважаемому читателю узнать эту широко известную последовательность: 1, 2, 3, 5, 8, 13.

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