Потрібно встановлювати цілі для розробників, хоча цілі не працюють [закрито]

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

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

1. Встановіть вимірювані цілі, які є додатковими до звичайної роботи, наприклад, "Провести навчання з технології X", "Створити документацію для фрагмента коду Y, якого ніхто не розуміє" тощо. Що стосується щорічної оцінки результативності, розробники оцінюють не письмові цілі, а, скоріше, мою думку про незмірну цінність їхньої звичайної роботи, оскільки це власне те, про що компанія дбає.
2. Встановіть цілком конкретні цілі, такі як "дні роботи, виконані, як це зафіксовано системою управління завданнями", "кількість введених помилок", "кількість випущених виробництв". Це призвело до завищених оцінок та неправильної класифікації помилок, щоб досягти кращих "балів". Цікаво, що навіть тим розробникам, які високо оцінили цю систему, це не сподобалось, оскільки внутрішня довіра до команди була пошкоджена, і вони не завжди відчували, що заслуговують на свою високу позицію.
3. Встановіть розмиті цілі, які є варіантами на тему: "Роби свою нормальну роботу добре". Що стосується щорічної оцінки, їх рейтинг справді відображає результати щодо цілей, але самі цілі не піддаються вимірюванню або досяжності, на що не роблять погляду.

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

Пов’язані запитання, які, як я виявив, стосуються не того самого:

• Які хороші цілі продуктивності для інженера-програміста?
• Встановлення цілей ефективності для розробників
• Які підходящі показники ефективності для програмістів?
• Що таке справедлива техніка вимірювання продуктивності для програмістів?
• Мені потрібні певні “Цілі” в кар’єрі на наступний рік

Оновлення (18 листопада 2009 р.): За моє запитання є 10 голосів, а найвищі оцінки мають лише 4 голоси (у тому числі по одному від мене). Я думаю, це нам щось говорить: можливо, Джоел та інші мають рацію, і що поєднана мудрість stackoverflow не може поставити жодних переконливих, вимірюваних цілей для розробників, які не можна було б зробити без негативного впливу на справжню (незмірну) цінність їх робота. Дякую за спробу!

який підхід найкраще підійшов для вас?

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

Примітки:

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

Особисто я намагаюся поставити два типи цілей:

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

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

Я вважаю, що важливо, щоб:

• Цілі розумні
• Цілі узгоджуються з потребами бізнесу
• Ви включаєте "нормальну роботу" до цілей, насправді це найважливіші цілі!
• Співробітник має певну можливість перевершити поставлені вами цілі

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

Все це зводиться до того, що "менеджмент першого рівня", і більшість будь-якого керівництва не знає своїх працівників. Замість того, щоб бути частиною фактичного повсякденного планування та розвитку, такі речі, як SMART, з’являються. Якби менеджери проводили більше часу з хлопцями, які виконують фактичну роботу, нічого з цього не було б потрібно.

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

Вимірювані цілі, які я бачив до цього часу:

• Скласти сертифікаційний іспит
• Дослідіть технологію X та проведіть про це презентацію
• Кількість здійснених змін, що порушують збірку
• Кількість статей у вікі, написаних з питань внутрішнього управління знаннями

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

Доводиться встановлювати цілі для розробників, хоча вони не працюють

Якщо ваші розробники не працюють, можливо, деякі цілі - це саме те, що їм потрібно, щоб дати їм певний стимул? ;-)

"Переконайтеся, що принаймні n% вашого коду перевірено відповідним модульним тестом" Використовуйте інструмент покриття, щоб довести це, і попросіть когось ще перевірити якість тесту.

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

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

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

У нас є ряд показників, які збираються під час роботи програмістів, такі як:

• Кількість SLOC змінено / додано
• Кількість помилок / помилок, усунених на різних етапах процесу (під час експертної перевірки, після експертної перевірки, після випуску)
• Запити на зміни виконані / відхилені
• Формальні документи (описи версій програмного забезпечення, дизайнерські документи тощо)

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

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

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

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

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

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

Цілі, які мені подобаються:

Попросіть N позитивних відгуків про вашу участь у проекті від клієнта проекту.

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

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

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