KPI программиста и разработчика – что должно учитываться при оценке эффективности IT-специалистов

Как оценивать работу программиста и разработчика, работающие и неработающие метрики. Почему системы uptime недостаточно? Обо всех сложностях оценки эффективности IT-специалистов в нашей статье.

время на прочтение: 2 мин.

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

С KPI возникает много проблем как на стадии внедрения, так и на стадии использования. Неправильно подобранные критерии оценки разработчика и программиста не только искажают видение реальности, но и снижают мотивацию сотрудников. К тому же, недобросовестные руководители и менеджеры выстраивают всю систему оценки эффективности под себя, оставляя лазейки для занижения показателей на основании предпочтений.

Основные метрики оценки для IT-специалистов

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

  • простота и понятность;
  • достижимость;
  • измеряемость;
  • направленность на ускорение результата.

Показатели эффективности программистов и разработчиков сложно подобрать из-за творческой составляющей их труда. Наиболее распространенной метрикой для оценки является время работоспособности IT-продукта – uptime. Оно измеряется в процентах за промежуток времени, показывая класс надежности программы/кода. Аптайм относится к высокоуровневым показателям наравне с сокращением расходов и увеличением прибыли от реализации. Использовать эти критерии удобно для приложений, платформ и айти-решений, направленных на принесение прибыли клиентам.

Для прочих сфер удобно применять технические критерии. Условно их удобно делить на поощрительные и санкционные. К поощрительным относятся:

  • количество выполненных задач за рабочий день/час;
  • количество исправленных ошибок.

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

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

Сложности при внедрении KPI, неработающие метрики

Оценка сотрудников ИТ-сферы затрудняется разнообразием выполняемых задач и сложностью их классификации. Большинство компаний прибегают к однобокой оценке работы через аптайм, оставляя без внимания остальные области. Всего существует 4 группы KPI программистов, которые потенциально можно применить практически к любой сфере разработки:

  • финансовые: отслеживание затрат на поддержку продукта, сотрудника, пользователя;
  • клиентские: время ответа на запросы, количество пользователей системы/ПО, количество выявленных клиентом проблем;
  • технические: время между сбоями, время ремонта, доступность/понятность системы, безопасность данных;
  • направленные на развитие: количество повторяющихся дефектов, отработка внештатных ситуаций.

Каждый внедренный показатель должен соответствовать конкретной цели и согласовываться с общей стратегией.

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

Эффективны ли KPI для программистов

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

У программистов не так. Их код или работает, или нет. Проактивность в большей степени заключается в поиске дополнительных решений, наставничестве или разработке идей для будущих проектов. Но стоит ли направлять внимание персонала на работу, не входящую напрямую в их функционал? Однозначного мнения о необходимости внедрения системы оценки для программистов нет. Менеджеры знают, как оценить труд разработчика с технической стороны, но как привести к измеримому показателю творческую часть процесса не ясно до сих пор.

Другие статьи