Каковы разумные KPI для команды разработчиков веб-приложений?

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

Есть ли у вас какие-либо предложения по разумным и полезным KPI для команды, состоящей в основном из разработчиков Rails?

Я думаю о таких вещах, как показатели качества кода, которые вы видите в репозиториях Github. В то же время у меня есть некоторые оговорки.

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

В моем предварительном исследовании я также наткнулся на эту цитируемую строку по теме:

Если когда-либо существовал определенный способ убить боевой дух в стартапе, то это ввод KPI и называние их KPI.

Мы все еще относительно небольшая и молодая компания с тем, что нам нравится думать о стартапе.

Я готов дать отпор этой инициативе. Но я подумал, что должен тщательно выслушать эту идею. Ссылки, предложения, аргументы против всей идеи приветствуются. Спасибо!

@klenwell: В стартапе, в котором я работаю, мы используем мягкие, неиндивидуальные показатели. Сколько ошибок было создано и сколько было устранено? Какие компоненты программного обеспечения были самыми глючными? Насколько продуктивной себя чувствует команда? Как мы относимся к людям, общению и рабочему процессу? Насколько точны были наши прогнозы сложности? Каково наше покрытие кода? — Они измеряют не индивидуальную производительность (поскольку работа в нашем контексте очень совместная), а качество нашей командной работы. Их нельзя использовать для того, чтобы предписать четкое (и глубоко ошибочное) решение «вверх-вниз», но они указывают на то, что команда может улучшить.
Снижение «производительности» в умственном труде до одного или нескольких чисел обречено на плохую метрику, на полный провал или даже на игру сообразительных манипуляторов. Вместо этого используйте письменные оценки. В течение года пишите о каждом проекте так, как если бы это был обзор фильма, запрашивайте мнение ваших пользователей/клиентов, называйте участников и их достижения, обсуждайте влияние работы на организацию в целом и то, как она закладывает основу. для дальнейшей работы. Это "объективно"? НЕТ, но в этом гораздо больше смысла и пользы, чем в тупом наборе показателей KPI (или целей SMART BS).

Ответы (2)

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

Я сам прошел через 2 из них. Это всегда заканчивается тем, что все ваши топ-менеджеры уходят в течение 2 лет и в конечном итоге оставляют вас с кучей людей, которые будут мириться с KPI, потому что им трудно найти другую работу. Кроме того, даже посредственные разработчики достаточно умны, чтобы обмануть любую систему, с которой вы пытаетесь ими управлять. По моему опыту, это часто происходит после приобретения новой материнской компании или новой исполнительной команды.

Есть поговорка: «Управлять разработчиками — все равно, что пасти кошек». Мой лучший совет по этому поводу — предоставить им право собственности и ответственность за домен, а также рекомендации по приоритизации запросов. Все ваши топы могут управлять собой (и, вероятно, предпочитают), в то время как вашим средним и начальным уровням может потребоваться больше рекомендаций, но KPI не являются ответом. Это работа колл-центра. Разработчики — креативщики. Они также хороши в математике, что является очень редкой парой черт. Худшее, что вы можете сделать, это управлять ими как рабочими часами.

Если вам абсолютно необходимо что-то измерять, выберите что-то, что действительно должно заботить компанию, например количество новых ошибок или соотношение ошибок к новым функциям.

В течение последнего года, в отсутствие KPI, наша команда успешно работала над оттачиванием наших методов разработки, ускорением доставки и улучшением качества наших приложений, а также созданием настоящего корпоративного духа.

Вы нашли то, что работает для вашей команды. Продолжайте делать это, пока это не произойдет.

Откуда он знает, что эти вещи работают/улучшаются, если он ничего не измеряет? (И если это так, то я бы сказал, что это должны быть ключевые показатели эффективности, которые требует руководство).
Мышление для большинства разработчиков было бы таким:If we are delivering results in a timely manner, why would we need to measure it?
@JuhaUntinen Зачем вообще кому-то хотеть стать лучше?
@diev, он может что-то измерять, только не лезь в фарс с KPI. Каждый разработчик может видеть это правильно. Как я уже сказал, измеряйте то, что он уже может измерить, например, количество ошибок, количество функций, отставание от выпуска, сокращение объемов и т. д. Вам нужен бесперебойно работающий магазин, и вы делаете это, устраняя как можно больше трений. Упрощайте рабочие процессы, а не усложняйте их. Держите клиентов подальше от разработчиков, если это вообще возможно, и т. д. KPI добавляют трения, потому что разработчики заняты выяснением того, как обыграть систему. Разработчики совершенствуются, зная больше вещей, а не механически минимизируя шаги.
@diev, также самое эффективное, что вы можете сделать с кодовой базой с течением времени, — это сделать ее интуитивно понятной, модульной и удобной в сопровождении. Если у вас большая сумасшедшая, чрезмерно сложная кодовая база, вы будете платить за нее десятилетиями. Ошибки будет сложнее найти, новые функции будет сложнее реализовать и они будут более подвержены ошибкам, что приведет к хакерскому коду, и это порочный круг. Как вы измеряете, насколько ремонтопригодна ваша кодовая база? Вы, конечно, не сделаете это, «требуя» KPI.
Чтобы внести свой вклад в развернувшуюся здесь дискуссию, мы используем скрам (разумеется, я надеюсь, что это справедливо) для отслеживания пары ключевых показателей: размера партии (очков за историю) и скорости (очков за спринт). Мы стремимся к тому, чтобы размер партии был небольшим (а-ля Reinertsen ), а скорость увеличивалась (хотя это число приблизилось к пределу). Я не хочу получать эти близкие к KPI, опасаясь, что это поощрит подтасовку или игру чисел, как предлагают Томбо и другие. Я бы воздержался от подсчета ошибок по той же причине. Но открыты для идей для других KPI.
«управлять разработчиками — это как пасти кошек». Но люди, похоже, упускают из виду, что самый простой способ пасти кошек — передвигать их миски с едой. Это так же применимо к людям, как и к кошкам.

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

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

Однако, если эта информация будет использоваться на индивидуальном уровне при оценке эффективности для определения продвижения по службе, компенсации или потенциального увольнения; тогда это становится намного сложнее продать команде.

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

Хотя я являюсь ярым сторонником использования метрик и KPI для команд разработчиков, есть много предостережений, которые часто упускают из виду. В результате KPI, независимо от того, какой показатель они измеряют, обычно воспринимаются как «золотые», хотя на самом деле они являются производными и искусственными измерениями, на которые напрямую влияют внешние силы, которые часто не измеряются или не понимаются.

Проще говоря, в производственной среде, если я знаю, что данная машина может производить 1000 изделий в час, это конкретное, дискретное измерение. Есть 1000 повторяющихся задач, которые точно такие же, как предыдущая задача. Каждый дубликат другого.

Суть в том, что разработка программного обеспечения никогда не была точным дублированием и тиражированием предыдущих задач. Каждая задача, требование, разработчик, ресурс QA; почти каждый аспект варьируется от задачи к задаче. Относиться к метрикам как к «высеченным в камне» — все равно, что сравнивать яблоки с апельсинами.

Были представлены цели компании. Они имеют смысл, и я за ними. Но да, вопрос о том, как эта информация будет использоваться, не разъяснялся и вызывает озабоченность. Я постараюсь уточнить этот вопрос у высшего руководства. Ваши очки хорошо приняты. Спасибо!
Каковы разумные KPI для команды разработчиков веб-приложений?
СпросиСетьПолитика конфиденциальности1y, 0v