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

Ответ 1

какой подход лучше всего подходит вам?

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

Примечания:

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

Ответ 2

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

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

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

Я чувствую, что важно, чтобы:

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

Установление целей для разработчиков, хотя они не работа

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

Цели, которые мне нравятся:

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

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