Как измерять работу программистов CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить? В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика. Очевидные метрики, которые придумает HR: - Присутствие на рабочем месте - Количество выполненных задач - Количество часов, затраченных на выполнение этих задач - Уложился ли в план

Неочевидные метрики, которые добавит CTO: - "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса. - "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32). - Количество багов в коде, написанном разработчиком. - Скорость — любые баллы делим на время. - % отклонения от собственной или командной оценки.

Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу. Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись. Что с этим делать? - Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку. - Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵