Я программист, работающий в стартапе на промежуточной стадии, который я называю «корпоративной фазой».
Компания, в которой я сейчас работаю, проводит ежегодную инициативу «Измеримые цели», напрямую связанную с премиями сотрудников. Они продолжают рекламировать это как «УМНЫЕ цели» (конкретные, измеримые, достижимые, реалистичные, ограниченные во времени) .
К сожалению, будучи магазином Agile, долгосрочные цели трудно объяснить, поскольку особенности того, что будет разработано, когда не известны более чем за месяц, если что.
В такой среде, что составляет «измеримую цель» хорошего годового программиста?
Это широко используемый набор критериев для постановки целей. Хитрость заключается в том, чтобы быть конкретным, но не слишком конкретным ... и, когда это возможно, вывести цели из целей вашего менеджера для отдела. Я тоже не силен в этом, несмотря на несколько десятков лет работы с такой системой.
Если вы полностью придерживаетесь Agile, вы можете записать их как цели скорости выполнения, а не как конечные точки. «Поддерживать среднюю частоту N функциональных баллов за спринт» будет конкретным, измеримым, ограниченным по времени, и, надеюсь, вы сможете выбрать достижимое и реалистичное N. Удержание невыполненной работы под контролем (и, желательно, уменьшение ее размера или, по крайней мере, поддержание несколько предсказуемой скорости удаления из нее элементов) может быть еще одним аспектом, который можно измерить количественно.
Помните, что, поскольку ваша компания только начинает этот процесс, всем придется немного повозиться с постановкой целей. Набросайте что-нибудь, попросите вашего менеджера проверить это, переделайте и повторяйте до тех пор, пока оно не станет достаточно хорошим ... затем сдайте его, прикрепите копию к стене как напоминание о том, с какими приоритетами вы согласились, и перестаньте беспокоиться о том, насколько хорошо или плохо написано что было. Ваш, вероятно, будет не хуже, чем у кого-либо еще.
И помните, что, в конце концов, вы не оцениваетесь по этому документу. Ваша работа будет оцениваться; этот план предназначен только для того, чтобы убедиться, что вы и ваше руководство согласны с тем, в чем заключается ваша работа. Им бы понравилось, если бы вы могли точно предсказать свою производительность, поскольку это помогло бы вашему руководству спланировать, сколько они могут взять на себя в свою очередь... и они, конечно, хотели бы, чтобы вы немного поработали... но если вы переоценивать или недооценивать свои прогнозируемые результаты, это действительно менее важно, чем то, чем эти результаты окажутся.
Я не знаю, какую разновидность Agile вы используете, но один из пунктов книги Scrum — не воспринимать план спринта слишком буквально. В конце концов, вы захотите иметь реалистичное представление о том, каким будет ваш ритм и ритм команды, но это приходит только со временем и практикой... и если вы переоцените или недооцените, это просто шанс понять, почему и требуется ли корректировка либо для ожиданий, либо для повышения производительности.
Как я уже сказал, я уже довольно давно имею дело с такой системой. Мой опыт показывает, что его ценность во многом зависит от того, насколько ваш менеджер готов работать с вами, чтобы сделать его полезным инструментом. Это может стать бессмысленным ритуалом, отнимающим время, или стать инструментом для обсуждения того, что именно вам нужно сделать, чтобы получить этот бонус. Это может быть средством защиты от выставления оценок за то, что, как вам не сказали, входит в ваши обязанности, но только в том случае, если руководство работает с вами, чтобы поддерживать это как «живой документ», который редактируется при изменении обязанностей.
Другими словами: если ваше руководство ожидает, что это будет серебряная пуля, им нужно напомнить, что серебряной пули не существует. Если они хотят использовать это как инструмент, чтобы помочь вам понять, за что вас судят, это может быть полезно.
пользователь9158
джмак
джмак
комар
HLGEM
IDRinkandIKnowThings
IDRinkandIKnowThings
IDRinkandIKnowThings
джкмелони