Что можно использовать в качестве измеримых (SMART) целей в Agile Shop? [закрыто]

Я программист, работающий в стартапе на промежуточной стадии, который я называю «корпоративной фазой».

Компания, в которой я сейчас работаю, проводит ежегодную инициативу «Измеримые цели», напрямую связанную с премиями сотрудников. Они продолжают рекламировать это как «УМНЫЕ цели» (конкретные, измеримые, достижимые, реалистичные, ограниченные во времени) .

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

В такой среде, что составляет «измеримую цель» хорошего годового программиста?

На самом деле это вопрос к вашему руководителю, так как он слишком широк, чтобы на него можно было ответить.
@Lego, я категорически не согласен. Кешлам дал отличный ответ ниже примерно в 500 словах. Я не вижу причин, по которым это слишком широко, чтобы ответить, или что это основано на мнении. Кажется, это практическая проблема, и приведенные ниже решения действенны и имеют резервную копию. Я надеюсь, что вы пересмотрите свой голос.
Эй, Авраам, и добро пожаловать на рабочее место ! Я внес небольшое изменение в ваш заголовок и добавил цель, объясняющую концепцию критериев SMART. Я думаю, что это отличный вопрос, и надеюсь, что вы получите лучшие ответы, но если вы считаете, что можете улучшить внесенные мной изменения (или если вы не согласны с ними), пожалуйста, не стесняйтесь вносить свои собственные изменения! Заранее спасибо.
УМНЫЕ цели — действительно глупые цели. Они в 100% случаев измеряют то, что измеримо, а не то, что важно. Для разработки программного обеспечения (как и для большинства других специалистов) не существует целей SMART.
@HLGEM - я не согласен. Если вы все сделаете правильно, это способ реально измерить ваш вклад.
Этот вопрос кажется не по теме, потому что он касается конкретной должностной функции и должностных ролей. С этим вопросом лучше обращаться на программистах, где на это уже есть ответы.
Я думаю, вы могли бы изменить вопрос, чтобы задать вопрос о том, как должны быть определены умные цели в целом, но как только вы перенесете это на конкретную работу и конкретные цели, это выходит за рамки этой SE.
На Programmers.SE есть невероятно похожий вопрос: «Как писать «SMART» цели agile-разработчику?» . Я написал ответ там; Я не решаюсь дублировать это здесь, если только это не нужно делать в данном случае? (Я настаиваю на своем ответе :))

Ответы (1)

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

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

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

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

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

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

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

@JoeStrazzere: Для текущих задач да, это «ограничено по времени» - на него можно ответить за определенный период времени. Измерение точно по целям: это рецепт для людей, которые не обещают, что вообще не достигает ни одной из целей наличия системы. Да, это может случиться, но этого не должно быть, если у руководства есть хоть малейшее представление... а если нет, то вы шрод, независимо от того, какую систему они утверждают, что используют или что вы пишете.