Необходимость устанавливать цели для разработчиков, даже если цели не работают [закрыто]

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

Однако в моей компании мы обязаны ставить цели для всех сотрудников, и отдел кадров поощряет их делать их УМНЫМИ . В прошлом я и мои коллеги-менеджеры первого уровня (руководители команд) пробовали несколько подходов:

1. Установите измеримые цели, которые дополняют обычную работу, например «Проведите обучение по технологии X», «Создайте документацию для фрагмента кода Y, который никто не понимает» и т. Д. Когда дело доходит до ежегодной оценки производительности, оценивайте разработчиков не по письменным целям, а, скорее, по моему мнению о неизмеримой ценности их нормальной работы, поскольку это на самом деле то, о чем компания заботится.
2. Установите очень конкретные цели, такие как «количество проделанных дней, записанное системой управления задачами», «количество внесенных ошибок», «количество выпущенных продуктов, вызванных ими». Это привело к завышенным оценкам и неправильной классификации ошибок с целью достижения лучших «баллов». Интересно, что даже разработчикам, получившим высокие оценки в этой системе, она не понравилась, поскольку внутреннее доверие внутри команды было подорвано, и они не всегда чувствовали, что заслуживают своего высокого положения.
3. Ставьте расплывчатые цели, которые являются вариантами «Делай свою обычную работу хорошо». Когда дело доходит до ежегодной оценки, их рейтинг действительно отражает результативность по сравнению с целями, но сами цели не поддаются измерению или достижимости, что вызывает неодобрение.

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

Связанные с этим вопросы, которые я обнаружил, не совсем касаются одного и того же вопроса:

• Каковы хорошие цели производительности для инженера-программиста?
• Установка целей производительности для разработчиков
• Какие показатели производительности подходят для программистов?
• Что такое метод справедливого измерения производительности для программистов?
• Мне нужны карьерные «голы» на следующий год

Обновление (18 ноября 2009 г.): за мой вопрос было подано 10 голосов, а ответы с наивысшими оценками имеют только 4 голоса (включая по одному от меня). Я думаю, это кое-что нам говорит: возможно, что Джоэл и другие правы, и что объединенная мудрость stackoverflow не может привести к каким-либо убедительным, измеримым задачам для разработчиков, которые нельзя было бы решить без отрицательного воздействия на истинную (неизмеримую) ценность их Работа. Спасибо за попытку!

какой подход лучше всего сработал для вас?

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

Ноты:

• Я не оценивал способность новых сотрудников быстро закончить работу и не поощрял их: я хотел, чтобы люди научились хорошо заканчивать (потому что, если работа не закончена хорошо, значит, она еще не закончена)
• Люди узнали то, что я искал, при обзоре кода: так что это возможность обучения и мера контроля качества, а не просто цель управления.
• Мои комментарии будут разделены на две категории:
  1. Это ошибка: вы должны исправить это перед регистрацией
  2. В качестве предложения я бы сделал то-то и то-то
• Через некоторое время мои обзоры кода человека перестанут находить какие-либо элементы, которые "необходимо исправить" (в этот момент мне больше не нужно будет проверять их работу).

Лично я пытаюсь поставить перед собой две цели:

• Бизнес-цели (именно поэтому нам все-таки платят). Например, «завершить проект X до 1 июня 2009 г.»). Эти цели часто разделяются между несколькими членами команды (и они знают об этом). Команда может превзойти цель, запустив проект на раннем этапе или превысив требуемый функционал. Люди могут превзойти цель, создавая больше функциональности, имея меньше ошибок, или обучая и поддерживая других членов команды.

• Цели личностного роста, например, завершение проекта с использованием технологии, которую разработчик хочет добавить к своим навыкам, лучшее понимание предметной области пользователя, получение лидерского опыта и т. Д.

Считаю важным, чтобы:

• Цели SMART
• Цели согласованы с потребностями бизнеса
• Вы действительно включаете «нормальную работу» в задачи, на самом деле это самые важные задачи!
• У сотрудника есть возможность превзойти поставленные вами цели

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

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

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

Измеримые цели, которые я видел до сих пор:

• Сдать сертификационный экзамен
• Изучите технологию X и проведите презентацию о ней
• Количество зафиксированных критических изменений сборки
• Количество вики-статей, написанных по внутреннему управлению знаниями

Как насчет того, чтобы напрямую спросить своих разработчиков, есть ли у них идеи для личного развития, которые затем можно было бы использовать для достижения целей?

Необходимость ставить перед разработчиками цели, даже если они не работают

Если разработчики не работают, возможно , некоторые цели только то , что они должны дать им стимул? ;-)

«Убедитесь, что не менее n% вашего кода протестировано подходящим модульным тестом». Используйте инструмент покрытия, чтобы доказать это, и попросите кого-нибудь другого проверить качество тестирования.

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

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

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

У нас есть ряд показателей, которые собираются по мере работы программистов, например:

• Количество SLOC изменено / добавлено
• Количество ошибок / багов, введенных на разных этапах процесса (во время экспертной оценки, последующей экспертной проверки, после выпуска)
• Запросы на изменение выполнены / отклонены
• Официальные документы (описание версий программного обеспечения, проектная документация и т. Д.)

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

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

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

Одна из проблем может заключаться в том, что ИТ-организации как подразделения / подразделения не имеют измеримых стратегических целей. Если бы они это сделали, было бы легче ставить цели перед людьми.

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

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

Мне нравятся следующие цели:

Получите N положительных отзывов о вашем участии в проекте от клиента проекта.

Это помогает, так как всегда хорошо иметь письменные положительные отзывы от клиентов (внутренних или внешних). Его нетрудно получить, он актуален и является легкой, но не бессмысленной отметкой в ​​списке.

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

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