Полезны ли цели SMART для программистов? [закрыто]

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

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

Одним словом

нет

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

Второе: измерение индивидуальной работы - отличный способ создать менталитет «не моей работы» и негативную конкуренцию между людьми и / или различными подгруппами в организации. Очень легко настроить систему и убедиться, что вы заботитесь о себе, а не помогаете всей команде. Мы должны поощрять людей быть командными игроками, но тогда наши организации делают прямо противоположное.

Большинство таких систем несовместимы с тимбилдингом. Мэри Поппендик проделала гораздо лучшую работу по формулированию этого, чем я когда-либо мог сделать в LeanEssays: Team Compensation .

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

... Один из величайших идейных лидеров 20-го века, Эдвардс Деминг, писал, что неизмеримый ущерб наносится рейтингом людей, системой заслуг и поощрительной оплатой. Деминг считал, что каждый бизнес - это система, а эффективность отдельных людей во многом является результатом работы системы. По его мнению, система вызывает 80% проблем в бизнесе, и система является ответственностью руководства. Он писал, что использование наставлений и стимулов для привлечения людей к решению управленческих проблем просто не работает. Деминг выступил против ранжирования, потому что он разрушает гордость за мастерство, и заслуга повышается, потому что они обращаются к симптомам, а не к причинам проблем.

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

Мы использовали SMART цели в большой корпорации, где я работаю. Они бессмысленны по большей части.

Цели исходят от высшего руководства и являются высокими и абстрактными. Относить их к конкретным проектам и разработкам, как правило, шутка. Большинство проектов, которые входят в группу, исходят от бизнеса и предназначены для удовлетворения конкретных потребностей бизнеса. Итак, вы кодируете проект, запускаете его в производство и выполняете потрясающую работу, как обычно. Как это соотносится с целью, которую придумал кто-то в высшем руководстве?

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

РЕДАКТИРОВАТЬ

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

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

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

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

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

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

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

1. Читать шаблоны дизайна и писать игрушечные проекты, чтобы выучить и продемонстрировать каждый шаблон к следующему году. Это заняло 2 года, но улучшение моего кодирования было заметно.
2. Изучать особенности языка .NET 3.5 и делать презентации для моих коллег каждый квартал. В итоге это была 1 презентация на LINQ, которую мои коллеги оценили в разной степени между апатичным и слегка заинтересованным. Тем не менее, я многому научился и, продемонстрировав свои знания C #, перешел к работе над довольно крутым новым проектом.

Так что, да, я получил пользу и повеселился, делая это.

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

Да, если установлено правильно.

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

Я был в тех местах, где у всей команды DBA такие же цели, как и у высокопоставленных сотрудников, таких как «соответствие глобальным и региональным KPI, как определено комитетом KPI». Что никто не знает, конечно ..

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

Редактировать:

Я прочитал статью Мэри Поппендик, и она не о SMART. «Восприятие невозможности» терпит неудачу «достижимо», например.

Задачи должны быть поставлены перед человеком, делиться своими сильными сторонами, помогать исправлять слабые стороны, способствовать работе команды. Измерение для человека.

Там не должно быть никакого сравнения х против у.

Цели для x и y должны быть соразмерны с их рангом или положением внутри системы: каждый не устанавливает одинаковые цели для старших и младших. Это нечестно.

Для установки бонусов или выплат из ограниченного банка необходим некоторый эталонный тест: нужно ли вместо этого считать строки кода? Рецензии?

И покажи мне действительные альтернативы, которые не потребуют, чтобы я изменил мой глобальный корпоративный дух. У меня нет критики SMART: у меня есть критика мочи бедных менеджеров ...

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

• выполнимый
• понятный
• управляемый
• выгодный

Как бы странно это ни звучало.

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

Чтобы получить полезные цели, полезно договориться о том, что будет означать аббревиатура SMART: быстрый поиск в Google нашел различные определения :

• S: кажется, что есть консенсус в отношении конкретных (хотя есть некоторые разногласия по поводу того, что это значит)
• М: Значимый и Мотивационный являются альтернативами более распространенному Измеримому
• A: кажется, чаще всего представляет Достижимое, но я также видел Согласованный
• R: в зависимости от того, где вы смотрите, вы можете найти реалистичные, актуальные, ориентированные на результаты
• T, кажется, всегда ссылается на Время, хотя акцент меняется

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

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

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

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

Может быть поучительно посмотреть, что люди считают полезными / стоящими целями SMART. Я поставил вопрос здесь ...

Проблема с умными целями заключается в том, что они должны выбирать, что измеримо. Так как то, что измеримо и что важно для успеха организации, часто не одно и то же (и практически никогда не в программировании), цели SMART в моем опыте всегда проваливаются при оценке производительности. И иногда вещи кажутся измеримыми, но не без особых усилий (Как и цель SMART, у меня был один раз, чтобы ответить на все письма в течение 4 часов. Действительно, кто хочет попробовать просмотреть тысячи писем, которые я получаю в год, определите, соответствует ли это был информационным или нуждался в ответе, а затем просмотрите мои отправленные электронные письма, чтобы узнать, отвечал ли я на него, а затем прослушайте записи всех телефонных звонков, чтобы узнать, ответил ли я на это, проверьте свой журнал IM, чтобы узнать, ответил ли я на него, и т. д. И что насчет того письма, которое пришло мне в субботу ночью в полночь ...)

Для всех людей, которые ответили НЕТ, ваши Цели, вероятно, были недостаточно УМНЫ

Я использовал их, и я считаю их невероятно полезными. Вы можете попробовать что-то, что работает для нас:

1. Ставьте ежеквартальные цели.
2. Ставьте измеримые цели.
3. Установить только одну цель для человека
4. Заставьте человека принять цель, если он скажет, что Цель слишком амбициозна, чтобы приспособиться до того времени, когда вы оба согласитесь.
5. В конце квартала придумайте логическое значение. Достигнутая цель = правда или ложь.

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

PS: Я могу понять, как люди голосуют за ответ, но, пожалуйста, напишите соответствующий комментарий, по крайней мере, я узнаю что-то, чего не знаю :-)

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

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

Если руководство не сделает это правильно, мало что изменится.