Чи може внутрішній представник, голосування та значки заохочувати належну практику програмування?

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

Щось на зразок

• Ви (або інші від вашого імені) можете опублікувати огляд (може бути фрагмент, однократне виконання або серія) для огляду коду

• Інші можуть коментувати це (було б подібне до відповідей у ​​SE)

• Значки можуть бути надані / запропоновані (деякі були б хорошими, а інші були б поганими, як "Коментувати пустелю" або дещо подібне)

• Ви можете проголосувати вгору / вниз за сам код та коментарі та значки (наприклад, якщо хтось запропонував значок, а ви зробили / не погодилися)

Мета такої схеми була б

• Запропонуйте трохи задоволення, щоб заохотити використання оглядів коду

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

• Зменшіть ймовірність перегляду коду, що спричинить "его-війни"

• Надайте кілька показників, щоб допомогти оцінити ефективність окремих людей

Чи може це працювати? Думки?

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

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

Багато експертів проводили дослідження з цього питання. Ось два мої улюблені:

Даніель Пінк зробив чудову презентацію в TED на тему, яку легко спостерігати і розуміти.

Альфі Кон , автор " Наказаних нагородами" , написав на цю тему:

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

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

Решта працівника може спростувати правила гри та кинути. Збільшення товарообігу стане новою проблемою.

Зауважте, що в цій громаді було зроблено багато пропозицій щодо покращення мотивації .

Так, це могло б

Але лише якщо ви розробите це дуже ретельно, інакше це може призвести до відмови. Я зауважую кілька коментарів, але думав, що підсумую свою позицію

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

Значки - це головним чином "весела" річ, я б тримав їх подалі від подальших питань, орієнтованих на майстерність. Тобто значки на кшталт "Сова цього тижня" або група "Відправлено! Знак" буде добре. Якщо у вас є значки на основі вмінь, як-от "Виправлені більшість помилок" або "Повідомлення більшості помилок", подумайте дуже ретельно про те, як це можна сприймати та грати. Значки повинні більше стосуватися висвітлення поведінки, ніж промоції її ІМО. Обов’язково мати як командні, так і окремі значки.

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

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

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

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

Зрештою, я думаю, що вам доведеться спробувати це і побачити, що працює, а що ні, є добра книга під назвою Реальність зламана, що може бути цікаво. Також обов'язково читати книгу Даніеля Пінкс "Драйв".

На мою думку, НІ , оскільки він вимірює не саму хорошу практику, а симптом (якщо інші вважають це гарною практикою).

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

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

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

Просто пам’ятайте, що це будуть не всі єдинороги та веселки. Деяким ініціатива не сподобається, тому загальна продуктивність / якість можуть постраждати. Однак цей ризик може бути того вартий. Залежить від вашої ситуації.

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

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

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

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

Це означає:

• Нехай люди беруть на себе відповідальність за свою роботу
• Заохочуйте людей говорити один з одним про те, що добре працює, а що ні
• Проявляйте справжню вдячність за працю людей

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

Коротка відповідь - так, це могло б спрацювати.

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

Окрім того, що я є професійним програмістом, я також аналітик поведінки любителів.

Одним із підписних висновків сучасної поведінкової науки є те, що на поведінку сильно впливають її наслідки.

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

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

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

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