Как измерять работу программистов.
CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить?
В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика.
Очевидные метрики, которые придумает HR:
– Присутствие на рабочем месте.
– Количество выполненных задач.
– Количество часов, затраченных на выполнение этих задач.
– Уложился ли в план.
Неочевидные метрики, которые добавит CTO:
– “Бизнес ценность” — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса.
– “Стори пойнты” — баллы трудоёмкости. Разработчики собираются на “Покер Планирования” и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32).
– Количество багов в коде, написанном разработчиком.
– Скорость — любые баллы делим на время.
– % отклонения от собственной или командной оценки.
Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу.
Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно.
Наблюдатель меняет природу света. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись.
Что с этим делать?
– Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку.
– Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них.