내부 대표, 투표 및 배지가 좋은 프로그래밍 관행을 장려 할 수 있습니까?

우리는 프로그래머가이 모든 투표 / 배지 / 대표 내용을 좋아하므로 더 나은 코딩을 장려하기 위해 이와 같은 체계를 회사 코드 검토 프로세스에 도입 할 수 있습니다.

같은 것

• 귀하 (또는 귀하를 대신하는 다른 사람)는 코드 검토를 위해 리뷰를 게시 할 수 있습니다 (스 니펫, 단일 커밋 또는 일련의 것일 수 있음).

• 다른 사람들은 그것에 대해 의견을 말할 수 있습니다 (SE의 답변과 비슷할 것입니다)

• 배지를 제공 / 제안 할 수 있습니다 (일부는 좋을 수도 있고, 일부는 "코멘트 사막"과 같이 나쁠 수도 있습니다)

• 코드 자체와 의견 및 배지에 대해 위 / 아래로 투표 할 수 있습니다 (예 : 누군가 배지를 제안하고 동의하지 않은 경우)

이와 같은 계획의 목표는

• 코드 검토 사용을 장려하기 위해 약간의 재미를 소개

• 품질 향상 (이 체계에서 코드 검토 자와 검토자가 모두 배울 수 있음)

• 코드 리뷰가 '자아 전쟁'을 촉발 할 가능성을 줄입니다.

• 개별 성과를 측정하는 데 도움이되는 몇 가지 지표 제공

이게 효과가 있을까요? 생각?

식이 요법 및 기타 보상 / 처벌 기반 시스템 과 같이 돈, 배지 또는 담당자와 같은 외래 보상 은 단기적 으로 작용합니다.

목적 및 자율성 과 같은 본질적인 보상이 대신 사용되어보다 장기적인 결과를 제공 해야합니다 . 단순한 외부 보상 시스템보다 실제로 적용하는 것이 훨씬 어렵지만 비용이 많이 듭니다.

많은 전문가들이이 주제에 대해 연구했습니다. 여기 내가 좋아하는 두 가지가 있습니다.

Daniel Pink는 TED에서보고 이해하기 쉬운 주제에 대해 훌륭한 프레젠테이션을 했습니다.

Rewards by Punished의 저자 인 Alfie Kohn은이 주제에 대해 다음과 같이 썼습니다.

물론 뇌물 및 위협은 일시적인 준수를 유발할 수 있습니다. 체육관에 가거나 어른들에게 책을 줍은 것에 대한 보상을 제공하면 효과가있을 수 있습니다. 그러나 그들은 스스로를 외적인 동기로 생각하기 때문에 보상을 더 이상 사용할 수 없을 때 계속 할 이유가 없습니다. 실제로, 그들은 이전보다 운동이나 독서에 대한 관심이 줄어들 수 있습니다.

보상 (및 처벌)의 또 다른 문제점은 사람들의 행동 방식을 수정한다는 것입니다. 예를 들어 직원에게 보너스를 주면 다른 (회사 전체) 목표에 관계없이 보너스를 얻는 데 집중하게됩니다. 부서와 직원간에 개인주의와 경쟁을 일으킬 것입니다. 원한이 일어나고 모두가 모든 사람을 볼 것입니다. 특히 당신의 목표 중 하나가 "개별 성과 측정을 돕는 것"일 때.

나머지 직원은 게임 규칙을 반증 하고 종료 할 수 있습니다. 증가 된 회전율 은 새로운 문제가 될 것입니다.

이 커뮤니티 에서 동기 부여를 개선하는 방법에 대한 많은 제안이있었습니다 .

그렇습니다

그러나 매우 신중하게 디자인 한 경우에만 역효과가 발생할 수 있습니다. 댓글을 달았지만 내 입장을 요약한다고 생각했습니다.

명성을 얻으려면 주된 목표는 직원들이 시간이 지남에 따라 기술 향상을 추적하는 데 사용할 수있는 측정치를 제공하는 것입니다. 그것을 염두에두고 매우 신중하게 디자인하십시오. 어려운 것은 기술을 측정하는 좋은 방법을 제시합니다. 나는 머리 꼭대기에서 그렇게 할 수 없습니다.

배지는 주로 "재미있는"것입니다. 나는 주로 기술 지향적 인 문제에서 멀리 떨어져 있습니다. 즉 "이 주 밤 올빼미"또는 "Shipped! 배지"그룹과 같은 배지는 정상입니다. "Fixed most bugs"또는 "Reported most bugs"와 같은 기술 기반 배지가 있다면이를 인식하고 게임하는 방법에 대해 매우 신중하게 생각하십시오. 배지는 IMO를 홍보하는 것보다 행동을 강조하는 것에 관한 것이어야합니다. 팀 배지와 개인 배지를 모두 가지고 있어야합니다.

나는 부정적인 배지에 대해 강력히 권장합니다.이 일들은 재미 있어야하며 사람들이 실수하는 것을 두려워하는 것은 위험합니다. 이러한 경우에 도움이되는 유용한 이메일을 생성하십시오.

배지를 결정하고 투표하지 못하게하는 것이 좋습니다. 사람들은 배지에 대한 제안을 보낼 수 있지만 사람들에게 미치는 영향은 매우 심할 수 있으므로, 투표 내용이 무엇인지 알고 있고 다수결이 아닌 사람을 신중하게 결정하여 배지 사용 방법을 결정해야합니다.

코드 검토는 흥미로운 아이디어이며 기술 가치를 창출 할 수있는 방법 중 하나 인 것 같습니다. 코드를 강조 표시하고 토론하면 도움이 될 수 있습니다. 그러나 모든 사람들이 자신이 개발 한 모든 것을 잠재적으로 판단하고 있다는 것을 안다면 역효과를 낳을 수 있습니다. 특히 무언가를 빨리 쓰고 리팩토링하는 반복 개발의 경우에는 그 행동을 원하지 않습니다.

아마도 코드를 직접 제출 한 사람이나 특정 나이의 코드 만 제출할 수있는 사람에 의해 상쇄 될 수 있습니다. 그럼에도 불구하고 어떤 효과가 있을지 알기가 까다로울 수 있습니다.

나는 당신이 그것을 시도하고 작동하는 것과 그렇지 않은 것을보아야한다고 생각합니다. 실제 라는 좋은 책 이 깨져서 흥미로울 수 있습니다. 또한 Daniel Pinks 책 "Drive"는 반드시 읽어야합니다.

내 의견으로는 NO 는 좋은 연습 자체가 아니라 증상 (다른 사람들 이 좋은 연습 이라고 생각 하는 경우 )을 측정하기 때문입니다.

밥 아저씨의 책을 역설하려면 (제목을 잊어 버렸습니다) : 좋은 코드는 거의 힘들어 보이지만 마치 마치 언어를 쓰려고 한 것처럼 문제를 사소하게 보이게합니다.

내 경험에 따르면, 그러한 코드는 주목을받지 못하고 오랜 시간이 지나면이 코드는 결코 문제를 일으키지 않았으며 아마도 코드가 도입되기 전에 문제가 불확실성의 큰 혼란 이었다는 것을 기억할 것입니다 모호함. 리뷰에서 칭찬을받는 코드는 일반적으로 리뷰어가 기분 좋지 않을 때 좋은 날에 보는 코드이며, 가장 적은 변화가 있습니다.

아이디어는 팀에게 새로운 역 동성을 가져다 줄 것입니다. 팀이 틀에 박힌 느낌이들 때, 이것은 일을 흔들어주는 좋은 방법입니다.

그것이 모든 유니콘과 무지개가 아니라는 것을 기억하십시오. 일부는 이니셔티브를 좋아하지 않아 전반적인 생산성 / 품질이 저하 될 수 있습니다. 그러나이 위험은 그만한 가치가 있습니다. 상황에 따라 다릅니다.

저는 사람들이 "기계적", 반복적이고 지루한 일을하도록 동기를 부여하기 위해 외적 동기 (제안하는 것이 외적 동기의 한 형태입니다)를 사용하는 것이 좋습니다.

• 회의 시간에 표시
• 시간표를 제 시간에 제출하기
• 설명서 업데이트
• 팀과 정보 공유

창의성을 필요로하거나 품질을 객관적으로 측정 할 수없는 모든 유형의 작업에 대한 동기 부여에는 사용하지 않습니다. 예를 들어, 위젯을 작성하는 사람이 있고 부품의 우수 여부를 기계적으로 검증 할 수 있고 승인 된 프로세스를 따르지 않는 한 부품을 만들 수없는 프로세스가있는 경우 동기를 부여하는 것이 생산적입니다 공정을 통해 품질을 희생시키면서 더 많은 단위를 만들기 위해 지름길을 취할 수 없기 때문에 생산성에 대한 엄청난 보상을받는 작업자.

그러한 보호 장치가 없다면 외적 동기에 대한 시도는 반드시 역효과를 낳을 것입니다. 프로그래밍은이 범주에 속합니다. 소프트웨어 품질을 안정적으로 측정 할 수는 없습니다. 위젯을 만들 때 공장을 떠나 다음 위젯에서 수행하는 작업에는 영향을 미치지 않지만 소프트웨어를 만들 때 계속해서 작업을 계속해야하기 때문입니다. 당신이하는 일은 이제 장기적인 영향을 미칩니다. 매우 중요하지만 측정 할 수없는 장기 효과입니다. 본질적 동기는 이런 종류의 일에 훨씬 더 유용한 동기입니다.

그것의 의미는:

• 사람들이 자신의 업무에 책임을지게하십시오
• 사람들이 잘 작동하는 것과 그렇지 않은 것에 대해 서로 이야기하도록 격려하십시오
• 사람들의 일에 진심으로 감사를 표한다

이 작품을 만드는 것의 일부는 서로를 모르거나 매일 서로 협력해야하는 많은 수의 참가자입니다. 소규모 그룹에서는 시스템이 게임을보기 좋게하거나 판촉 경쟁을 악화시키는 방법이 될 것이라고 생각합니다. 이것이 공식적인 동료 평가가 종종 열악한 시스템 인 이유입니다. 소규모 그룹에서는 최고의 담당자를 가진 사람들이 최고의 프로그래머가 아니라 정치적으로 가장 성실한 사람들이 될 것입니다.

짧은 대답은 그렇습니다.

약간 더 긴 대답은 그렇습니다. 작동 할 수 있지만 역효과를 낼 수도 있습니다.

전문 프로그래머 인 동시에 아마추어 행동 분석가이기도합니다.

현대 행동 과학의 주요 발견 중 하나는 행동이 그 결과에 크게 영향을 받는다는 것입니다.

결과를 통제하면 행동에 어느 정도 영향을 줄 수 있습니다. 정도는 행동을 바꾸려는 각 개인에게 특정 결과가 얼마나 중요한지, 그리고 결과를 피하고 그들이 일하고자하는 다른 사람들을 찾는 것이 얼마나 쉬운 지에 달려 있습니다.

전문 프로그래머로서 코드 작성의 한 가지 결과는 내가 돈을받는 것입니다. 지불을 중단하고 오래 전에 나타나지 않습니다. 급여는 저에게 정말 중요한 결과이며 (가족을 키우고 있습니다) 현재 회사에서 지불하는 대신 일할 의향이있는 다른 결과는 없습니다.

당신이 나의 상사라면, 당신은 나에게 어떤 결과 (인센티브, 강화제)를 제공할지 결정할 것입니다. 그러나 당신은 내가 그들을 어떻게 인식하는지 결정할 수 없습니다. 예를 들어, "달의 코더"로 선택된 경우 상사는 특별한 주차 공간을 제공하기로 결정할 수 있습니다. 샌프란시스코 나 뉴욕에 살면서 차를 운전한다면 기꺼이 그 일을 할 수도 있습니다. 그러나 내가 지금 사는 곳에서 주차는 문제가되지 않으며 어쨌든 출근 할 수 있습니다.

내 경험상 직장에서 SO와 같은 프로그램을 구현할 때 가장 큰 위험은 사람들에게 가치가있는 대가를 지불하는 대신 동료 투표를 제공하는 것으로 인식 될 수 있다는 것입니다.