Comments 13
git commit --amend
. А потом читаешь посты ребят, которым при работе в условном Crossover старший коллега говорит: «Васек, ты работаешь хорошо и чисто, и все успеваешь, но мало кликаешь. Ты не мог бы кликать побольше, а то у меня тут метрика проседает по моему подразделению».
Позвольте процитировать тут чудесного автора Дорофеева:
![image](https://habrastorage.org/getpro/habr/comment_images/d67/3c2/340/d673c23400ae4de96c5572ee62e6b007.jpg)
Черный закон метрик (Для любой системы KPIсуществует такая стратегия В, что показатель KPIпри следовании этой стратегии находятся в зеленой зоне, но при этом сам проект через жопу идет в неизвестность).
В статье я увидел только одну полезную и худо-бедно измеримую метрику: были ли достигнуты бизнес цели / решены поставленные задачи?
Ну, ещё посещаемость – но это, на мой взгляд, для особо запущенных случаев.
Число коммитов – это сродни числу строк кода. Ни о чем не говорит (в лучшем случае, о посещаемости).
Оказание помощи – такая цель может легко увести в сторону.
На скриншотах упоминаются Teamwork, Efficiency, Technical Debt, но совершенно непонятно, как их измерить.
Как измерить и оценить производительность разработчиков
Для меня вопрос остался неотвеченным.
Ну, ещё посещаемость – но это, на мой взгляд, для особо запущенных случаев.
Если среди разработчиков нужно бороться за посещаемость (то есть ничего не делается, и рассмотрение в деталях показывает, что люди уже просто забили) — то тут уже всё настолько плохо, что попытки обращать внимание именно на посещаемость — это сродни лечения отсутствия головы прикладыванием подорожника.
Если же дело делается, но посещаемость не идеальная, то это либо следствие других проблем (и нужно их выявлять и бороться с ними), либо же вообще естественное состояние дел. Скажем, больше 6 часов в день практически никто не кодит, да и эти 6 часов — близки к идеалу. Если у людей нет организационных вопросов минимум на два часа каждый день — они будут уходить раньше.
Так что это практически всегда бессмысленный показатель. Выявить не занимающегося работой разработчика можно куда проще — по отсутствию какой-либо полезной активности в таск-трекере в единицу прогресса (спринт и тому подобное). Борьба именно за посещаемость приводит исключительно к имитации бурной деятельности и снижению морали.
Зачем вообще оценивать производительность разработчиков? Обычно это нужно менеджеру.
У него два главных вопроса:
- Как понять, насколько эффективно работают мои подчиненные? Не дурачат ли они меня?
- Как продемонстрировать начальству, что я – эффективный менеджер?
Вот бы найти чудо-метрику "эффективности", она бы на оба вопроса ответ дала.
Стремлению найти метрику также способствует менеджерская истина: управлять можно только тем, что можно измерить.
Я бы переформулировал её так: тем, что можно измерить, намного легче управлять.
Вот и получается, что увлечённые погоней за "эффективностью" менеджеры управляют лишь тем, что удается измерить.
Всё как в анекдоте: "Почему вы ищете часы возле фонарного столба? Вы их здесь потеряли? — Нет, потерял я их в канаве, но там темно, и ничего не видно".
Для начала, я бы посоветовал разобраться, что значит быть эффективным (см. статью) в каждом конкретном случае. А уж потом искать метрики.
Поставил минус за пропаганду вредных для команды практик.
Подобные системы всегда ломаются на простом контрольном вопросе: как они будут реагировать на парное программирование? Подсел я к коллеге, мы продуктивно поработали часок и сделали нужный кусок функциональности. А ещё каждый из нас получил кусок нового опыта — например, один узнал хитрости работы в IDE, а другой — новую команду shell (каждый учится у соседа). А ещё мы бонусом укрепили условный "командный дух", пока работали плечом к плечу, и в следующий раз охотнее придём друг другу на помощь. Что из этого попадёт в систему? Условный час работы коллеги и 0 часов моей работы? Прэлестно! Ах да, тут же есть такие метрики, как "коллаборация" и "инициативность"! Надо лишь, чтобы менеджер на забыл нажать соответствующую галочку. Прекрасный мотиватор для продуктивной деятельности (на самом деле нет)!
Ок, а если мы решили попробовать моб-программирование? Мини-хакатон? Групповой анализ проблемы у доски? Утреннюю code cata для разогрева (на минуточку, с полным удалением кода, без загрузки в какой-либо репозиторий)? Наброски дизайна системы в блокноте? Справочник я открыл и целый час (вот ужас-то!) читал его — как это скажется на моей Метрике Эффективности (TM)? А если, прости г-ди, посмел пообщаться с коллегой не на рабочем месте, а на кофе-пойнте и там подкинуть идеи для решения задачи? Написал мотивирующий пост во внутренний блог? Перенёс "своими ногами" фидбек по компоненту X из одного отдела в другой? Что из этого попадёт в метрики, а что нет?
Есть огромное количество практик в разработке ПО, которые улучшают индивидуальную и командную эффективность, но при этом принципиально не сводятся к паттерну "сидит Вася за своим компутером и регулярно пушит код на сервер". Как бы ни хотелось собрать их все в одну удобную для учёта систему, это невозможно принципиально. Есть какие-то общие рекомендации, но "серебряной пули" не существует. Каждый раз, в каждой команде, с каждой новой проблемой надо включать мозг, надо задавать вопросы, надо стараться выкинуть свои предрассудки/искажения, которые мешают увидеть корневые проблемы. Это сложная, неприятная, утомительная ситуация, в которую надо окунаться снова и снова. И даже успех решения одной-двух-N проблем не даёт полной гарантии того, что в N+1-м случае всё пройдёт гладко. Это сложные системы. Это реальная жизнь!
Что в этой статье написано про жизнь? Пара предложений в извиняющемся тоне — "да, программисты тоже люди, вообще-то, вы уж как-нибудь поаккуратнее с ними". Конечно, я понимаю: все устают без конца напрягать мозг (Канеман не просто так получил Нобелевку!), и иллюзия существования простых, универсальных решений рано или поздно соблазняет почти каждого. Поставь нашу систему. Полюбуйся на красивые дашборды. Спрячься за ними от необходимости идти и рыть носом землю на месте. Не думай о бремени общения с этими грубыми интровертами. Нажми на кнопочку сортировки. Сформируй запрос. Помедитируй над графиком. Ты здесь хозяин. Ты их оцениваешь, а они тебя нет. Экран монитора защитит тебя. Нажми на кнопку — составится отчёт. Ты великолепен!
Кто клюёт на эту приманку, тот начинает разрушать жизнь себе и окружающим. Чем дальше, тем больше. Реальная командная работа заменяется дрочерством на абстрактные циферки. Кооперация вытесняется конкуренцией. Исследование местности отбрасывается во имя следования карте. Гадание по теням на стене начинает называться "принятием взвешенных решений".
За это и минус — здесь происходит продажа вредоносных иллюзий вместо решения реальных проблем. Была бы возможность — поставил бы два.
Да, рынок своё дело делал, делает и будет делать. Но люди (а не просто абстрактные "гребцы") в процессе могут пострадать довольно сильно. На это хотелось бы обратить внимание.
Как измерить и оценить производительность разработчиков