Рассказ из личного опыта. Извинения за длину.
Несколько лет назад наша группа разработчиков попыталась установить «правильные» измеримые цели для отдельных лиц и руководителей команд. Эксперимент длился всего один год, потому что жесткие метрики не очень хорошо работали для отдельных целей (см. мой вопрос по теме для некоторых ссылок и дальнейшего обсуждения).
Обратите внимание, что я был руководителем группы и участвовал в планировании всего этого вместе с моим техническим боссом и другими руководителями группы, поэтому цели не были чем-то продиктованы высшими руководителями - в то время, когда мы действительно хотели их на работу. Стоит также отметить, что структура бонусов непреднамеренно поощряет конкуренцию между разработчиками. Вот мои наблюдения о том, что мы попробовали.
Видимые клиенту проблемы
В нашем случае мы учитывали перебои в обслуживании, предоставляемом клиентам. В термоусадочной упаковке это может быть количество ошибок, о которых сообщили клиенты.
Преимущества: Это была единственная реальная мера, которая была видна высшему руководству. Это было также самым объективным, измеряемым вне группы развития.
Недостатки: Было не так много простоев - всего по одному на разработчика в течение всего года - что означало, что неудача или превышение цели были вопросом "возложения вины" за немногих перебои, которые произошли в каждой команде. Это привело к плохому самочувствию и потере морального духа.
Объем выполненных работ
Преимущества: Это был единственный положительный показатель. Все остальное было «мы замечаем, когда случается что-то плохое», что деморализует. Его включение также было необходимо, потому что без него разработчик, который ничего не делал весь год, превысил бы все другие цели, что явно не отвечало бы интересам компании. Измерение объема выполненных работ проверило естественный оптимизм разработчиков при оценке размера задачи, что было полезно.
Недостатки: Мера "выполненной работы" была основана на оценках, предоставленных самими разработчиками (как правило, хорошая вещь), но включение ее в свои цели побудило игровые системы раздувать оценки. У нас не было никакого другого жизнеспособного показателя выполненной работы: я думаю, что единственный возможный ценный способ измерения производительности - это «влияние на прибыль компании», но большинство разработчиков настолько далеки от прямых продаж, что редко бывает практичным на индивидуальном уровне.
Дефекты, обнаруженные в новом производственном коде
Мы измерили дефекты ввел в новый производственный код в течение года, так как считалось, что ошибки предыдущих лет не должны учитываться ни для какого человека в целях этого года. Дефекты, обнаруженные внутренними командами по качеству, были включены в подсчет, даже если они не влияли на клиентов.
Преимущества: Удивительно мало. Промежуток времени между появлением дефекта и его обнаружением означал, что действительно не было механизма немедленной обратной связи для улучшения качества кода. Макро тренды на командном уровне были более полезными.
Недостатки: Особое внимание было уделено негативу, поскольку эта цель использовалась только тогда, когда был обнаружен дефект, и нам нужен был кто-то, кто в этом виноват. Разработчики неохотно регистрировали обнаруженные ими дефекты, и простой подсчет означал, что незначительные ошибки были такими же серьезными, как и серьезные проблемы. Так как количество дефектов на человека было все еще довольно низким, количество мелких и серьезных дефектов не выровнялось, как это могло бы быть с более крупной выборкой. Старые дефекты не были включены, поэтому репутация группы по качеству кода (на основе всех найденных ошибок) не всегда соответствовала количественному показателю количества введенных в этом году.
Своевременность сдачи проекта
Мы измерили своевременность как процент работы, выполненной внутренним командам по обеспечению качества к установленному сроку.
Преимущества: В отличие от подсчета дефектов, эта мера находилась под непосредственным непосредственным контролем разработчиков, так как они эффективно определяли, когда работа будет завершена. Наличие цели сосредоточило ум на выполнении заданий. Это помогло команде выполнить реалистичный объем работы и улучшило восприятие внутренними клиентами способности группы выполнять обещания.
Недостатки: Как единственная цель, находящаяся непосредственно под контролем разработчиков, она была максимизирована за счет качества кода: в день крайнего срока, учитывая выбор между заявлением о завершении задачи или выполнением продолжая тестирование, чтобы повысить уверенность в его качестве, разработчик предпочел бы отметить его завершение и надеяться, что возникшие ошибки никогда не появятся.
Жалобы от внутренних клиентов
Чтобы оценить, насколько хорошо разработчики общались с внутренними заказчиками во время разработки и последующей поддержки их программного обеспечения, мы решили, что количество жалоб, полученных по каждому человеку, будет записано. Жалобы будут подтверждены менеджером, чтобы избежать возможной мстительности.
Преимущества: Реально ничего не могу вспомнить. При измерении на достаточно большом уровне группы оценка «удовлетворенности клиентов» становится более полезной.
Недостатки: Не только крайне отрицательный, но и субъективный показатель. Как и в случае с другими целями, цифры для каждого человека были около нулевой отметки, что означало, что один комментарий о ком-то мог означать разницу между «бесконечно превышенным» и «не встречающимся».
Общие комментарии
Бюрократия: В то время как наши инструменты управления задачами хранили большую часть данных для этих метрик, все еще было приложено немало ручных усилий для их сопоставления. Время, затрачиваемое на получение всех чисел, было не из приятных, как правило, фокусировалось на негативных аспектах нашей работы и, возможно, даже не было исправлено повышением производительности.
Мораль: Что касается мер, в которых людей обвиняли в проблемах, то не только те, кто имел «плохие» баллы, чувствовали себя демотивированными, но и те, кто имел «хорошие» баллы, поскольку им не нравились потеря боевого духа в команде и иногда ощущение, что их оценивают выше не потому, что они были лучше, а потому, что им повезло.
Резюме
Так что же мы узнали из этого эпизода? В последующие годы мы пытались повторно использовать некоторые идеи, но более «мягким» способом, где меньше внимания уделялось индивидуальной вине, а больше - улучшению команды.
- Невозможно определить цели для отдельных разработчиков, которые являются объективно измеримыми, повышают ценность компании и не поддаются разработке, поэтому не пытайтесь попробовать.
- Проблемы и дефекты клиента можно просчитать на более широком командном уровне, , если локализация дефекта однозначно является обязанностью этой команды, то есть вам никогда не придется играть " Виноват игра ".
- Как только вы измеряете дефекты только на уровне ответственности за программный модуль, вы можете (и должны) измерять старые ошибки, а также новые, поскольку в интересах этой группы устранить все дефекты.
- Измерение количества дефектов на уровне группы увеличивает размер выборки для каждой группы, поэтому аномалии между незначительными и серьезными дефектами сглаживаются, и простая мера «количество ошибок» может что-то значить, например, чтобы увидеть, улучшаете ли вы месяц -он-месяц.
- Включите что-то, о чем заботится высшее руководство, потому что поддерживать их - ваша основная цель как группы разработчиков. В нашем случае это были видимые для клиента сбои, поэтому, даже если мера иногда является произвольной или, казалось бы, несправедливой, если это то, что измеряют боссы, то вам также необходимо обратить на это внимание.
- Высшему руководству не нужно видеть показатели, которых у них нет, в своих собственных целях. Таким образом, он избегает искушения обвинять людей в ошибках.
- Измерение своевременности выполнения проекта сделал изменил поведение разработчика и сфокусировался на выполнении задач. Это улучшило оценку и позволило группе давать реалистичные обещания. Если бы было легко собирать информацию о своевременности, я бы подумал об ее повторном использовании на уровне команды, чтобы измерить улучшение со временем.
Все это не помогает, когда вам необходимо установить измеримые цели для отдельных разработчиков, но, надеюсь, идеи будут более полезными для улучшения команды.