Как измерить и оценить производительность разработчиков

[NeverIn]

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

[ganqqwerty]

Есть подозрение, что как только разрабы узнают о существовании такого инструмента, некоторое их количество сбежит сразу, а многие из тех, кто останутся, начнут оптимизировать метрики вместо того, чтобы делать работу. Некоторые даже установят сами себе такой же, ну или будут мерить эти метрики другим способом. Ну вот скажем, отчет «engineers that do not commit code», вы же понимаете, как надо работать в организациях, в которых попадание в этот отчет заканчивается дружественной беседой с менеджером? Правильно, заканчивается это созданием бота, который будет делать git commit --amend.
А потом читаешь посты ребят, которым при работе в условном Crossover старший коллега говорит: «Васек, ты работаешь хорошо и чисто, и все успеваешь, но мало кликаешь. Ты не мог бы кликать побольше, а то у меня тут метрика проседает по моему подразделению».
Позвольте процитировать тут чудесного автора Дорофеева:

Черный закон метрик

Черный закон метрик (Для любой системы KPIсуществует такая стратегия В, что показатель KPIпри следовании этой стратегии находятся в зеленой зоне, но при этом сам проект через жопу идет в неизвестность).

[ganqqwerty]

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

[yaroslav2]

В статье я увидел только одну полезную и худо-бедно измеримую метрику: были ли достигнуты бизнес цели / решены поставленные задачи?

Ну, ещё посещаемость – но это, на мой взгляд, для особо запущенных случаев.

Число коммитов – это сродни числу строк кода. Ни о чем не говорит (в лучшем случае, о посещаемости).

Оказание помощи – такая цель может легко увести в сторону.

На скриншотах упоминаются Teamwork, Efficiency, Technical Debt, но совершенно непонятно, как их измерить.

Как измерить и оценить производительность разработчиков

Для меня вопрос остался неотвеченным.

[JustDont]

Ну, ещё посещаемость – но это, на мой взгляд, для особо запущенных случаев.

Если среди разработчиков нужно бороться за посещаемость (то есть ничего не делается, и рассмотрение в деталях показывает, что люди уже просто забили) — то тут уже всё настолько плохо, что попытки обращать внимание именно на посещаемость — это сродни лечения отсутствия головы прикладыванием подорожника.
Если же дело делается, но посещаемость не идеальная, то это либо следствие других проблем (и нужно их выявлять и бороться с ними), либо же вообще естественное состояние дел. Скажем, больше 6 часов в день практически никто не кодит, да и эти 6 часов — близки к идеалу. Если у людей нет организационных вопросов минимум на два часа каждый день — они будут уходить раньше.

Так что это практически всегда бессмысленный показатель. Выявить не занимающегося работой разработчика можно куда проще — по отсутствию какой-либо полезной активности в таск-трекере в единицу прогресса (спринт и тому подобное). Борьба именно за посещаемость приводит исключительно к имитации бурной деятельности и снижению морали.

[ganqqwerty]

У меня ощущение, что Technical Debt можно померить методами социологического анкетирования. Подходишь к гребцам и спрашиваешь «по шкале от одного до десяти, насколько сильно тебя достал говнокод в нашем проекте?» Или там: «давай попробуем вспомнить, когда последний раз ты реализовывал фичу так, чтобы было не стыдно?» Или вот более прицельно: «какой из микросервисов в нашем проекте может наилучшим образом обеспечить костылями соседнюю травматологию?» Всячески варьируешь эти вопросы, задаешь их в разной обстановке и в разном состоянии гребцов, не забываешь варьировать шкалы (пятибалльная, трехбалльная и десятибалльная), и в итоге некоторую качественную оценку имеешь.

[katatamar]

мне кажется, проблема основная — она всегда одинаковая. Заказчик вчегда хочет быстро и дешево, забывая, что, на самом деле, это вечный «проклятый треугольник»: быстро, дешево, хорошо (выбери только два)

[yaroslav2]

Зачем вообще оценивать производительность разработчиков? Обычно это нужно менеджеру.

У него два главных вопроса:

1. Как понять, насколько эффективно работают мои подчиненные? Не дурачат ли они меня?
2. Как продемонстрировать начальству, что я – эффективный менеджер?

Вот бы найти чудо-метрику "эффективности", она бы на оба вопроса ответ дала.

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

Я бы переформулировал её так: тем, что можно измерить, намного легче управлять.

Вот и получается, что увлечённые погоней за "эффективностью" менеджеры управляют лишь тем, что удается измерить.

Всё как в анекдоте: "Почему вы ищете часы возле фонарного столба? Вы их здесь потеряли? — Нет, потерял я их в канаве, но там темно, и ничего не видно".

Для начала, я бы посоветовал разобраться, что значит быть эффективным (см. статью) в каждом конкретном случае. А уж потом искать метрики.

[zloddey]

Поставил минус за пропаганду вредных для команды практик.

Подобные системы всегда ломаются на простом контрольном вопросе: как они будут реагировать на парное программирование? Подсел я к коллеге, мы продуктивно поработали часок и сделали нужный кусок функциональности. А ещё каждый из нас получил кусок нового опыта — например, один узнал хитрости работы в IDE, а другой — новую команду shell (каждый учится у соседа). А ещё мы бонусом укрепили условный "командный дух", пока работали плечом к плечу, и в следующий раз охотнее придём друг другу на помощь. Что из этого попадёт в систему? Условный час работы коллеги и 0 часов моей работы? Прэлестно! Ах да, тут же есть такие метрики, как "коллаборация" и "инициативность"! Надо лишь, чтобы менеджер на забыл нажать соответствующую галочку. Прекрасный мотиватор для продуктивной деятельности (на самом деле нет)!

Ок, а если мы решили попробовать моб-программирование? Мини-хакатон? Групповой анализ проблемы у доски? Утреннюю code cata для разогрева (на минуточку, с полным удалением кода, без загрузки в какой-либо репозиторий)? Наброски дизайна системы в блокноте? Справочник я открыл и целый час (вот ужас-то!) читал его — как это скажется на моей Метрике Эффективности (TM)? А если, прости г-ди, посмел пообщаться с коллегой не на рабочем месте, а на кофе-пойнте и там подкинуть идеи для решения задачи? Написал мотивирующий пост во внутренний блог? Перенёс "своими ногами" фидбек по компоненту X из одного отдела в другой? Что из этого попадёт в метрики, а что нет?

Есть огромное количество практик в разработке ПО, которые улучшают индивидуальную и командную эффективность, но при этом принципиально не сводятся к паттерну "сидит Вася за своим компутером и регулярно пушит код на сервер". Как бы ни хотелось собрать их все в одну удобную для учёта систему, это невозможно принципиально. Есть какие-то общие рекомендации, но "серебряной пули" не существует. Каждый раз, в каждой команде, с каждой новой проблемой надо включать мозг, надо задавать вопросы, надо стараться выкинуть свои предрассудки/искажения, которые мешают увидеть корневые проблемы. Это сложная, неприятная, утомительная ситуация, в которую надо окунаться снова и снова. И даже успех решения одной-двух-N проблем не даёт полной гарантии того, что в N+1-м случае всё пройдёт гладко. Это сложные системы. Это реальная жизнь!

Что в этой статье написано про жизнь? Пара предложений в извиняющемся тоне — "да, программисты тоже люди, вообще-то, вы уж как-нибудь поаккуратнее с ними". Конечно, я понимаю: все устают без конца напрягать мозг (Канеман не просто так получил Нобелевку!), и иллюзия существования простых, универсальных решений рано или поздно соблазняет почти каждого. Поставь нашу систему. Полюбуйся на красивые дашборды. Спрячься за ними от необходимости идти и рыть носом землю на месте. Не думай о бремени общения с этими грубыми интровертами. Нажми на кнопочку сортировки. Сформируй запрос. Помедитируй над графиком. Ты здесь хозяин. Ты их оцениваешь, а они тебя нет. Экран монитора защитит тебя. Нажми на кнопку — составится отчёт. Ты великолепен!

Кто клюёт на эту приманку, тот начинает разрушать жизнь себе и окружающим. Чем дальше, тем больше. Реальная командная работа заменяется дрочерством на абстрактные циферки. Кооперация вытесняется конкуренцией. Исследование местности отбрасывается во имя следования карте. Гадание по теням на стене начинает называться "принятием взвешенных решений".

За это и минус — здесь происходит продажа вредоносных иллюзий вместо решения реальных проблем. Была бы возможность — поставил бы два.

[ganqqwerty]

Мне кажется, что пока что рынок успешно уничтожал таких Сов-эффективных-менеджеров. Гребцы разбегались как только им надоедало писать обходящие метрики ботов и все успешно накрывалось. Буду надеяться, что и дальше так будет.

[zloddey]

Да, рынок своё дело делал, делает и будет делать. Но люди (а не просто абстрактные "гребцы") в процессе могут пострадать довольно сильно. На это хотелось бы обратить внимание.

[ganqqwerty]

Я сам гребец, мне можно гребцовые шутки))

[zloddey]

Ну, я тоже "гребец", но не забываю про кавычки в этом слове. А вот про то, что все мы в первую очередь люди, в 99% случаев забывать не стоит. Это важнее, чем все условности, роли и маски, которые мы тащим на себе каждый день.