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

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

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

В слові

Немає

По-перше: я ніколи не мав своїх проектів залишатися досить стабільними, щоб я міг встановити цілі SMART з будь-яким значенням. Часові шкали між тим, коли міняються мої ролі в проекті, і коли проводяться огляди перф, занадто далеко не синхронізовані.

По-друге: Вимірювання індивідуальної ефективності - це чудовий спосіб створити менталітет "не моя робота" та негативну конкуренцію між людьми та / або різними підгрупами в організації. Дуже легко грати в систему і переконайтесь, що ви доглядаєте за собою і не дуже допомагаєте всій команді. Ми повинні заохочувати людей бути командними гравцями, але тоді наші організації роблять навпаки.

Більшість таких систем є антитетичними для побудови команди. Мері Поппендієк зробила набагато кращу роботу по артикулюванню цього, ніж я коли-небудь можу зробити в LeanEssays: Командна компенсація .

Сью зателефонувала від Джаніс у людські ресурси. "Сью," сказала вона, "Чудова робота, яку зробила ваша команда! І дякую, що ви заповнили всі ці форми введення оцінок. Але насправді, ви не можете дати кожному найкращу оцінку. Ваш середній рейтинг повинен бути "відповідає очікуванням". Ви можете мати лише одного або двох людей, які "набагато перевищили очікування" ... "

... Один з найбільших лідерів думок 20 століття, У. Едвардс Демінг, писав, що незмірний збиток створюється рейтингом людей, системами заслуг та заохочувальною платою. Демінг вважав, що кожен бізнес - це система, а результативність роботи людей є значною мірою результатом того, як система працює. На його думку, система спричиняє 80% проблем у бізнесі, а система несе відповідальність. Він написав, що використовувати заохочення та заохочення змусити людей вирішувати проблеми управління просто не працює. Демінг виступає проти ранжування, оскільки це руйнує гордість за виробництво, а заслуги викликають, оскільки вони вирішують симптоми, а не причини, а не причини.

... давайте глибше розглянемо системи оцінювання та винагороди працівників та дослідимо, що спричиняє їх функціонування ...

Ми використовували цілі SMART у великій корпорації, де я працюю. Вони здебільшого безглузді.

Цілі виходять з вищого рівня управління і є високими та абстрактними. Зв'язок їх із конкретними проектами та розробками - це зазвичай жарт. Більшість проектів, які входять у групу, походять з бізнесу та мають задовольнити конкретну потребу бізнесу. Отже, ви кодуєте проект, запускаєте його у виробництво і виконуєте приголомшливу роботу, як завжди. Як це стосується мети, яку придумав хтось із вищого керівництва?

Ми робимо набагато краще, як група, коли придумуємо власні цілі. Іноді вони включають навчання з певної теми або впровадження нової зміни процесу, що насправді може бути пов'язане з тим, що ми робимо. Вони все ще не дуже пов’язані з щоденною роботою кодування за допомогою щонайменше речей, які допомагають рухати групу вперед у корпоративному середовищі.

EDIT

Як Менемент так правильно вказав, моя відповідь ґрунтується на тому, що цілі SMART не є, ну, SMART. Я додам до своєї відповіді, що якщо ви менеджер програмістів і хочете реалізувати SMART цілі, будьте впевнені, що вони SMART. Використовуйте приклад моїх керуючих як спосіб НЕ реалізувати SMART цілі. Якщо ви не керуєте програмістами, і хтось скаже вам, що ви зараз почнете використовувати цілі SMART, і вони закінчуються так, як наші, тоді розумійте, що у вас є люди з вищого керівництва, які люблять гучні слова та вміють перевіряти вимкнути їх із списку речей, які вони реалізували.

Існує велика кількість досліджень, які показують, що програмісти виконають відмінну роботу за будь-якими критеріями, які їм представлені, ціною інших можливих цілей.

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

Ви не хочете встановлювати рядки коду як цілі. Довірся мені. Встановлення виправлених помилок призводить до написання коду помилок. Прохання виправити помилки в існуючому коді призведе до дуже ліберальних визначень "помилка" (і, можливо, "виправити"). (Крім того, "досяжна" частина залежить від того, наскільки баггі був код.) Просити повноти функції в певний час, ну ....

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

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

В рамках цього я виявив, що постановка цілей саморозвитку працює дуже добре. Наприклад, дві мої цілі минулого року:

1. Читати шаблони дизайну та писати іграшкові проекти, щоб вивчити та продемонструвати кожен шаблон до наступного року. Це закінчилося 2 роки, але покращення кодування було помітним.
2. Вивчити особливості мови .NET 3.5 та щоквартально робити презентацію моїм колегам. Це в кінцевому підсумку було 1 презентацією на LINQ, яку мої колеги оцінили в різній мірі між апатичним та м'яко зацікавленим. Однак я багато навчився, і продемонструвавши свої знання C #, я перейшов до роботи над досить класним новим проектом.

Так, так, я отримав користь і розважився, роблячи це.

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

Так, якщо встановлено правильно.

Якщо їх правильно поставити, цілі можуть покращити як колектив, так і окремих людей. Вони також повинні бути узгоджені з роботою та розроблені для особистості.

Я був у тих місцях, де ціла команда DBA має ті самі чіткі цілі, а також високі рівні мене, такі як "відповідати глобальним та регіональним КПІ, як визначено комітетом КПІ". Якого, звичайно, ніхто не знає ..

Потім я знову був у тих місцях, де менеджер ставив перед собою окремі цілі з продуманим фронтом.

Редагувати:

Я прочитала статтю Мері Поппендієк, і мова не йде про SMART. "Сприйняття неможливості", наприклад, не дає "Досяжного".

Необхідно поставити цілі для особистості, поділитися своїми силами, допомогти усунути слабкі сторони, внести свій внесок у колектив. Вимірювання призначене для особистості.

Не повинно бути порівняння x vs y.

Цілі для x і y повинні бути співмірними з їх рангом або становищем всередині системи: однако не ставить однакових цілей для старших та юніорів. Це несправедливо.

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

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

Як рамки ефективності, SMART є настільки ж ефективним, наскільки тісно співпадають ваші цілі з цілями ваших менеджерів. Іноді ваші цілі SMART доводиться спочатку знижувати, тобто. зробити їх:

• Виконано
• Зрозуміло
• Керований
• Вигідний

Як би дивно це не звучало.

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

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

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

Отже, по-перше, обидві сторони переговорів щодо встановлення цілей повинні працювати над спільним розумінням процесу.

Далі, загальні цілі для організації, підрозділу, групи, команди (або будь-якої ієрархії є актуальною) потрібно пояснити та зрозуміти. У цей момент особа повинна мати можливість (ІМО, цілі повинні бути встановлені на індивідуальному рівні, щоб вони були достойними) мати можливість погодитись на невелику кількість цілей, які повинні інформувати про діяльність цієї людини вперед.

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

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

Це може бути повчально бачити, що люди думають, що може бути корисним / корисним для SMART цілей. Я поставив тут питання ...

Проблема з цілями SMART полягає в тому, що вони повинні вибрати те, що підлягає вимірюванню. Оскільки те, що вимірюється і що важливо для успіху організації, часто не є одне і те ж (і практично ніколи не є програмуванням), цілі SMART завжди провалюються в оцінці ефективності, на мій досвід. І іноді все здається вимірюваним, але не дуже багато зусиль (як і мета SMART, я мав один раз відповісти на всі електронні листи протягом 4 годин. Дійсно, хто хоче спробувати переглянути тисячі електронних листів, які я отримую за рік, визначте, чи це було інформаційним чи потрібна відповідь, а потім подивіться на мої надіслані електронні листи, щоб побачити, чи я відповів на нього, а потім прослухайте записи всіх телефонних дзвінків, щоб побачити, чи я відповів на нього, перевірте мій журнал чату, щоб побачити, чи я відповів на нього тощо. як щодо того електронного листа, який мені надіслали в суботу вночі опівночі ...)

Для всіх людей, які відповіли "НІ", Ваші цілі, ймовірно, НЕ були досить розумні.

Я їх використав і вважаю їх неймовірно корисними. Ви можете спробувати щось, що працює для нас:

1. Встановлюйте щоквартальні цілі.
2. Поставте вимірювані цілі.
3. Поставте для людини лише одну мету
4. Примусьте особу прийняти мету, якщо він каже, що мета занадто амбітна перестроюється до моменту, коли ви погодилися.
5. В кінці кварталу придумайте булеве значення. Досягнута мета = істинна чи помилкова.

Це надзвичайно потужно, це створює відповідальність для розробника. Люди, які хочуть знайти виправдання курки через 6 місяців.

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

SMART - це абревіатура запам'ятовування деяких критеріїв для досягнення кращих цілей. Отже, запровадивши SMART - це означає, що ваше керівництво повинне краще дотримуватися цього принципу. Без управління SMART все-таки було б поставлено цілі, але це було б скоріше важко.

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

Якщо керівництво не зробить це правильно, багато чого не зміниться.