Как считать производительность труда IT-персонала
Автор: Самойленко Геннадий — эксперт в области управления эффективностью персонала (HR-ROI)
Организация: HR-рейтинги | hr-ratings.com
Дата публикации: 28 марта 2026
Организация: HR-рейтинги | hr-ratings.com
Дата публикации: 28 марта 2026
Производительность труда IT-персонала — одна из самых сложных тем в управлении персоналом. IT-специалисты создают нематериальный продукт, работают в условиях неопределённости, и их результат часто виден только через месяцы. При этом бизнес требует чётких цифр. В этой статье — ответы на десять вопросов, которые руководители и HR-специалисты задают чаще всего.
1. Почему производительность IT-персонала так сложно измерить?
Главная причина — IT-специалисты создают интеллектуальный продукт, а не физический. Невозможно посчитать строки кода как детали на конвейере: тысяча строк может быть гениальным решением или безнадёжным мусором. Разработчик, который написал три строки, исправившие критическую ошибку, может быть в десятки раз ценнее того, кто три дня добавлял ненужные функции.
Вторая причина — контекстная зависимость. Производительность одного разработчика напрямую зависит от того, насколько хорошо написан чужой код, который он дорабатывает, от качества технического задания, от слаженности команды, от инструментов. Именно поэтому нельзя оценивать IT-специалиста в отрыве от системы, в которой он работает.
Третья причина — невидимая работа. Опытный разработчик много времени тратит на помощь коллегам, проверку кода, написание документации, участие в архитектурных обсуждениях. Всё это не отражается в задачах, но критически влияет на производительность всей команды. Любая система метрик, которая этого не учитывает, даёт искажённую картину.
Вывод простой: нет единой универсальной метрики. Правильный подход — сочетание нескольких показателей с учётом специфики роли, команды и бизнес-контекста.
2. Какие метрики лучше всего подходят для оценки продуктивности разработчиков?
Самый зрелый и признанный подход сегодня — DORA-метрики. Это четыре показателя, которые исследовательская группа Google выявила как ключевые предикторы эффективности IT-команды. Первый — частота деплоев: как часто команда выпускает изменения в продакшн. Второй — время выполнения изменений: сколько времени проходит от написания кода до его появления у пользователей. Третий — частота сбоев при изменениях: какой процент деплоев приводит к инцидентам. Четвёртый — время восстановления после сбоя: как быстро команда устраняет проблемы.
Высокопроизводительные команды по всем четырём показателям выглядят так: деплоят несколько раз в день, изменения проходят путь от кода до продакшна за часы, менее 15% деплоев вызывают проблемы, а восстановление занимает меньше часа. Эти цифры — ориентир, а не норматив.
Помимо DORA, полезны метрики потока: время цикла (от начала работы над задачей до её завершения), незавершённое производство (сколько задач одновременно в работе), пропускная способность (сколько задач завершается за период). Эти показатели помогают выявить системные узкие места, а не виноватых людей.
Важно помнить: метрики должны отражать здоровье системы, а не использоваться для ранжирования сотрудников. Команда, оптимизирующая метрики ради метрик, быстро научится их обманывать.
3. Как измерить производительность IT-специалистов, которые не пишут код?
В IT-командах много ролей помимо разработчиков: аналитики, тестировщики, DevOps-инженеры, технические писатели, продуктовые менеджеры, системные администраторы. Для каждой роли нужны свои подходы.
Для тестировщиков смотрят на покрытие тестами, количество и тяжесть найденных дефектов, долю дефектов, пропущенных в продакшн, скорость прохождения цикла тестирования. Важно: нельзя оценивать тестировщика только по количеству найденных багов — это провоцирует на поиск мелочей в ущерб системному качеству.
Для DevOps-инженеров ключевыми будут доступность систем (аптайм), время развёртывания, количество автоматизированных процессов, среднее время восстановления после инцидентов, снижение ручных операций.
Для аналитиков важна не скорость написания документации, а качество требований — насколько редко разработчики возвращаются с уточняющими вопросами, сколько переделок возникает из-за неясных требований, насколько точны оценки трудозатрат на основе написанных требований.
Общий принцип для всех: метрика должна быть связана с бизнес-результатом, а не просто с активностью. Человек, написавший 50 страниц документации, которую никто не читает, менее продуктивен того, кто написал 5 страниц, которые устранили половину вопросов команды.
4. Что такое DORA-метрики и как их применять на практике?
DORA расшифровывается как DevOps Research and Assessment. Это программа исследований, которую с 2014 года вела независимая группа учёных, а затем её приобрела Google. На протяжении нескольких лет они опрашивали десятки тысяч IT-специалистов по всему миру и пришли к выводу: именно четыре метрики, описанные выше, лучше всего коррелируют с коммерческими результатами компании.
Как внедрять на практике. Первый шаг — определите текущий уровень. Соберите данные по всем четырём метрикам за последние три месяца. Это даст базовую линию. Не нужно сразу целиться в «элитный» уровень — важно понять, где вы находитесь.
Второй шаг — определите, какая из метрик является главным ограничением. Если время выполнения изменений измеряется неделями, начните с него. Это часто означает проблемы с процессом проверки кода или слишком длинные циклы релиза.
Третий шаг — улучшайте системно, а не точечно. Если частота сбоев высока, не наказывайте тех, кто «сломал» систему. Ищите причины в архитектуре, процессе тестирования, качестве требований. Большинство ошибок — системные, а не индивидуальные.
DORA-метрики хорошо работают для продуктовых IT-команд. Для проектных или аутсорсинговых компаний их нужно адаптировать с учётом специфики контракта и жизненного цикла проекта.
5. Можно ли использовать количество задач или тикетов как показатель производительности?
Количество закрытых задач — один из самых популярных и одновременно самых опасных показателей. Популярен, потому что его легко посчитать в любом таск-трекере. Опасен, потому что провоцирует дробление работы на мелкие задачи, закрытие задач «для галочки» без реального результата и избегание сложных, но важных работ в пользу простых.
Классический эффект: разработчик, который правильно декомпозировал большую задачу на 20 мелких, выглядит в 20 раз продуктивнее того, кто честно работает над одной крупной архитектурной задачей несколько недель.
Это не значит, что считать задачи нельзя вообще. Количество закрытых задач — полезный индикатор в сочетании с другими данными. Стоит смотреть на него в динамике внутри одной команды, а не сравнивать людей между собой. Также важно учитывать категории задач: закрытые дефекты, новые функции, технический долг, поддержка — это принципиально разные виды работы.
Более зрелый подход — оценивать не количество задач, а их ценность для бизнеса. Для этого команды используют систему весов: задачи оцениваются в условных единицах сложности (story points), и продуктивность измеряется в единицах завершённой работы, а не в штуках.
6. Как учитывать качество работы, а не только скорость?
Скорость без качества — это иллюзия производительности. Команда, которая быстро выпускает плохой код, создаёт технический долг, который потом втрое дороже исправлять. Поэтому любая система измерения производительности должна включать показатели качества.
Для разработчиков качество измеряется через дефектность: сколько ошибок найдено в коде, написанном конкретным специалистом, на этапе проверки кода и уже в продакшне. Важен не ноль ошибок — ошибки делают все. Важна динамика: становится ли специалист более качественным со временем.
Второй показатель — сложность кода. Существуют инструменты статического анализа (SonarQube, CodeClimate), которые автоматически оценивают цикломатическую сложность, покрытие тестами, наличие «запахов кода». Это объективные данные, которые не зависят от субъективной оценки руководителя.
Третий показатель — обратная связь от коллег. Структурированное peer review позволяет получить оценку качества работы от людей, которые непосредственно сталкиваются с её результатами. Важно, чтобы этот процесс был безопасным и направленным на развитие, а не на наказание.
Четвёртый показатель — возврат задач. Если задача несколько раз возвращается на доработку, это сигнал о проблеме либо с качеством выполнения, либо с качеством постановки задачи. Анализ причин возвратов помогает понять, где именно возникает потеря.
7. Как измерить производительность команды, а не отдельного сотрудника?
Командная производительность — более важный показатель, чем индивидуальная. Исследования показывают: высокопроизводительные команды состоят из людей со средними индивидуальными показателями, но с высокой слаженностью. И наоборот: команда из «звёзд» без взаимодействия может быть менее эффективной.
Основной показатель командной производительности — velocity (скорость): сколько единиц работы команда выполняет за итерацию (обычно двухнедельный спринт). Этот показатель должен быть стабильным или расти. Резкие колебания — сигнал о системных проблемах: нечёткие требования, внешние зависимости, частые переключения контекста.
Важный показатель — предсказуемость. Команда, которая стабильно выполняет 80% из запланированного, лучше управляема, чем команда, которая то перевыполняет план вдвое, то не выполняет вовсе. Предсказуемость важна для бизнеса и для планирования.
Смотрите также на командное время реакции: как быстро команда реагирует на входящие запросы, срочные исправления, вопросы от смежных команд. Это косвенный показатель слаженности и внутренней организации.
Не менее важны качественные показатели: удовлетворённость заказчиков работой команды, уровень психологической безопасности внутри команды, отток участников. Команда с высоким оборотом кадров никогда не будет высокопроизводительной, даже если текущие метрики выглядят хорошо.
8. Как технический долг влияет на производительность и нужно ли его измерять?
Технический долг — это накопленные компромиссы в коде, архитектуре и процессах, которые сделали работу быстрее сейчас, но замедлят её в будущем. Это не всегда плохо: иногда «грязное» решение — правильный бизнес-выбор. Плохо, когда долг накапливается неконтролируемо.
Связь с производительностью прямая: по мере роста технического долга скорость команды падает. Разработчики всё больше времени тратят на то, чтобы понять существующий код, обойти старые ограничения, исправить побочные эффекты. Команды, которые не управляют техническим долгом, через два-три года начинают работать вдвое медленнее при той же численности.
Измерять технический долг можно несколькими способами. Инструменты статического анализа (SonarQube) автоматически оценивают долг в условных часах — сколько времени займёт его исправление. Другой подход — регулярный технический аудит: раз в квартал команда оценивает состояние ключевых компонентов по заданной шкале.
Для руководителей важен не абсолютный размер долга, а его динамика. Если долг растёт быстрее, чем команда успевает его отдавать — это управленческая проблема. Лучшая практика: выделять 15–20% мощности команды на работу с техническим долгом регулярно, а не пытаться потом провести большой рефакторинг.
9. Как избежать манипуляций с метриками со стороны сотрудников?
Любая метрика, на основе которой принимаются решения о вознаграждении или карьере, начинает вести себя иначе, чем планировалось. Это называется законом Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой.
Разработчики — умные люди. Если оценивать их по количеству строк кода, они начнут писать длиннее. Если по количеству закрытых задач — дробить задачи. Если по отсутствию ошибок в продакшне — избегать рискованных, но важных изменений. Манипуляции — это не злой умысел. Это рациональный ответ на неправильно выстроенные стимулы.
Первый способ защиты — использовать несколько метрик одновременно. Сложнее одновременно оптимизировать пять показателей, чем один. Особенно если они находятся в естественном противоречии: скорость и качество, объём и предсказуемость.
Второй способ — отделить метрики для управления от метрик для оценки людей. Командные DORA-метрики не должны напрямую влиять на зарплату конкретного разработчика. Они — инструмент диагностики и улучшения, а не рейтинг.
Третий способ — вовлекать команду в разработку метрик. Когда люди сами участвуют в том, как измеряется их работа, они лучше понимают цель этих измерений и реже пытаются их обойти. Прозрачность — лучший антидот от манипуляций.
10. Как выстроить систему оценки производительности IT-персонала с нуля?
С нуля — значит правильно. Многие компании начинают с метрик и только потом задумываются о том, зачем они нужны. Правильный порядок обратный.
Шаг первый: определите цель измерений. Вы хотите принимать решения о вознаграждении? Выявлять системные проблемы? Планировать нагрузку? Поддерживать рост сотрудников? Разные цели требуют разных инструментов. Смешивать их в одну систему — ошибка.
Шаг второй: начните с качественных данных. Поговорите с командами. Спросите разработчиков, что мешает им работать лучше, где они тратят время впустую, что они считают хорошим результатом своей работы. Эти разговоры дадут больше, чем месяц работы с данными таск-трекера.
Шаг третий: выберите 3–5 метрик, которые отражают бизнес-результат, а не активность. Для продуктовой команды это могут быть DORA-метрики плюс удовлетворённость пользователей продуктом. Для проектной — соблюдение сроков и бюджета плюс качество сдачи. Меньше метрик, но значимых — лучше, чем много метрик ради отчётности.
Шаг четвёртый: внедряйте постепенно. Начните с пилота на одной команде. Соберите обратную связь. Посмотрите, какое поведение провоцируют метрики. Скорректируйте. Только потом масштабируйте.
Шаг пятый: встройте обучение в систему. Метрики должны стать основой для разговора о развитии, а не инструментом контроля. Если сотрудник видит в измерениях угрозу, а не поддержку, система не будет работать так, как задумано.