소프트웨어 팀에서 본질적 동기 부여를 장려하는 방법


15

아마존의 기계식 터크에 관한 Jeff Atwood의 블로그 게시물 은 그것이 금전적 보상을 제공하지 말고 오히려 본질적인 동기 , "작업 자체에 대한 관심이나 즐거움에 의해 주도되는 동기 부여, 그리고 외부의 압력에 의존하기보다는 개인 내부에 존재하는 동기 부여"를 제안해야한다고 제안합니다 .

팀원 (관리자, 리드 또는 개발자)은 소프트웨어 팀에서 본질적 동기를 어떻게 촉진합니까?

편집 : 포괄적 인 답변을 제공하십시오. 객관적인 분석을 통해 개인적인 경험을 공유하십시오.

편집 # 2 : 생산적이고 주제에 대한 토론을 촉진하기 위해 개발자는 금전적 보상이 만족 스럽다고 가정해야합니다.


1
배지, 리더 보드 및 레벨 업 능력. "나는 거의 선임 개발자 인 19,000 점을 얻었습니다. 다음 버그에 대해 논의하겠습니다!"
dietbuddha

re edit2 : 금전적 보상이 만족 스럽다고 가정하면 사실이 아닌 것으로 가정합니다.
매트 엘렌 12

@ 매트 엘렌 나는 당신이 무슨 말을하는지 이해하지 못합니다. 토론에 계속 집중하려고합니다.
Matthew Rodatus

나는 당신의 가정이 잘못되었으므로 그 가정에 근거한 답변 (편집 # 2)이 유용 할 수 없다고 말하고 있습니다.
매트 엘렌 12

1
그렇습니다.하지만 모든 경우에 그 가정이 어떻게 잘못 될 수 있습니까? 당신은 자격없이 내 가정이 잘못되었다는 전 세계적인 진술을하고 있습니다.
Matthew Rodatus

답변:


20

그것을 죽이지 않음으로써 . 나는 5 일 이상 일하는 모든 사람들이 책을 채우기에 충분한 동기 부여 살인자를 만났다. 모두가 기회가 있으면 더 잘할 것이라고 맹세합니다. 그러나 어쨌든,이 살인자들은 지속되고, 그것들을 구현하는 사람들은 보통 계속 생각하고, 더 낫습니다.

제 생각에 가장 좋은 방법은 선을 행하지 않고 나쁜 일을 피하는 것입니다.

수정, 요청시 수정 :

긴 버전

제 생각에는 본질적 동기는 작업 / 회사와의 식별과 밀접한 관련이 있습니다.

식별에서 오는 식별하기 위해 자신의 작업 시도와 자신을 식별하는 사람이 사이에 가능한 한 작은 차이 '그가 원하는 일을'작업을하고 '와 같은 가질 수 있도록,'STH 같은 글의를 만들기 위해 '같이.

따라서 일을하고 회사에 이익을 줘서 회사 / 팀에게 혜택을주는 것 사이의 결정을 강요하는 모든 것은 잠재적 동기 유발 요인이므로 피해야합니다.

내가 만난 킬러 중 일부는 다음과 같습니다.

끊어진 의사 소통 : 그것은 무엇을 어떻게 대신에 누가 어떻게 말을하는지가 중요합니다. 옳은 일을하기위한 동기 (ad res)는 메신저를 죽이고 카산드라를 비 웃으며 공개적으로 속죄를 집행함으로써 처벌됩니다.

징후 : 많은 참조, 숨은 참조 및 전자 메일, 모임에서 말한 것과 식당에서 말한 것 사이에 차이가 있습니다.

결과에 대한 형식 : 작업이 수행되는 방식이 아니라 주로 작업이 수행되는 방식이 중요합니다. 가치있는 것을 생산하는 동기는 생산 된 것을 감상하지 않고 생산을 처벌함으로써 사라집니다. 프로토콜을 따르면 아무것도 생성하지 않는 것이 훨씬 쉽습니다.

징후 : '페이스 북 차단기', 고정 근무 시간, 책상 규정. (제프 애트우드가 '가구 경찰'에 대해 sth를 썼다고 생각합니다)

지루함 / 죽은 끝 : 이 직업에서, 누군가가 머무를 때, 무언가를 놓치거나, 배우거나, 다른 전문 분야 (예 : 코딩에서 디자인까지)를 얻거나 가족에게 제공 할 수있는 급여를받는 기회 . 더 오래 머무를수록 더 적은 기회가 있습니다.

선택은 회사를 개선하고 자신을 개선하는 것입니다.

징후 : 모든 사람을 'X 사람'이라고하며 X는 그가 영원히 한 일입니다.


1
AAA +++는 다시 찬성합니다. 나는 이것을 "팀에게 과제를주고, 팀에게 필요한 도구를 제공 한 다음, 길을 벗어난다"는 변형으로 표현합니다. 관리자가 방해가 될뿐만 아니라 다른 문제를 해결하는 데 시간을 할애 할 수 있다면 승자가됩니다.
Tom Anderson

여기에 +1 최고의 답변- 본질적으로 본질적 동기 부여를 외부에서 육성 할 수는 없지만 확실히 파괴 할 수 있기 때문입니다!
Steven A. Lowe

좋은 답변을 얻으려면 +1하십시오. 말이 되네요 본질적 동기를 죽이는 일반적인 요인에 대해 더 자세히 설명해 주시겠습니까 (아마도 목록을 제공 할 수 있습니까)?
Matthew Rodatus

@ Matthew Rodatus : 나는 그런 목록을 제공하기 위해 게시물을 수정했습니다.
keppla

좋은 정교함! 가구 경찰에 관해서는이 기사를 의미합니까? 제프는 링크, 그러나 그는 그것을 기록하지 않았다 girtby.net/archives/2005/10/26/the-virtual-furniture-police
마태 복음 Rodatus

10

소프트웨어 개발 수명주기의 일부로

  • 올바른 사람에게 올바른 작업을 할당하십시오 (가능한 경우).
    • 이것은 그들이 처음에 과제원한다는 것을 의미합니다
    • 그렇지 않은 경우이 작업을 수행하지 않아야 할 수도 있습니다.
  • 까다로운 작업 할당
    • 프로그래머는 창조적 인 사람이며 정신적으로 도전적인 과제를 수행하고 이미 수행 한 작업을 과도하게 다시 수행하는 것보다 선호합니다.
    • 물론 요구 사항의 일부로 현재 수행중인 작업 만 할당 할 수 있지만 이러한 각 요구 사항이 어떻게 과제를 나타내는 지 파악하고 적절한 개발자를 선택하십시오. 요구 사항이 항상 동일하고 지루한 경우 여기에서 수행해야 할 작업도 있습니다. 여기에는 고유 한 동기가 없지만 본질적인 실패 및 중복 지점이 있습니다.
  • 사용하여 지속적인 통합 / 검사 게임
    • 그들은 재미 있고 동기 부여
    • 그들은 사람들이 완벽을 위해 노력하도록 격려합니다
    • 그들은 본질적으로 내재적이지 않지만, 자신을 완성하고 배우고 공유하기를 원하지만 가끔씩 밀어야하는 개발의 내부 질에 호소합니다.
  • SCM에 월 보드 (또는 라디에이터 ) 사용 , 지속적인 통합 및 지속적인 검사 도구는 재미 있고 동기 부여가됩니다 (그러면 인프라의 일부로 필요합니다)
    • CI 게임과 같은 이유로 개발자에게 호소합니다.
    • 경쟁 측면이 없어도 프로젝트에 참여하는 개발자에게 자부심과 자격을 부여합니다.
    • 그들이 큰 팀의 일원이라면 더 큰 디자인의 진화를 볼 수 있습니다.
    • 또한 (및 개발자가 아닌 개별적으로)에게 다음을 수행 하는 데 도움이 됩니다.
      • 경쟁 (프로젝트 간, 코드 품질면 에서-LOC와 경쟁하지 마십시오 ... )
      • 공동 작업 (가족에 속한 소프트웨어를 구축하려는 경우)
  • 회고전 사용
    • 협업 방식으로 문제를 식별하는 데 도움이됩니다.
    • 그들은 개발자에게 프로젝트에 대한 소속감 을 부여합니다 (그리고 그 실수)
    • 그들은 보상이나 비난을 할당 하지 않습니다 (그러나 책임감을 부여하십시오 )
  • 코드 검토 는 프로세스에서 없어서는 안될 부분이어야합니다 (또는 수용하는 대신 코드를 두려워하게됩니다).
    • 개발자는 자연스럽게 칭찬을 구하고 노력하는 법을 배웁니다.
    • 그들은 비판에 더 개방적 일 것이다
  • 창의적 이고 건설적인 비판 을 허용하고 장려
  • 개인 개발을 허용하고 장려하십시오
    • 애완 동물 프로젝트의 형태로
    • 프로토 타입 형태 (애완 동물 프로젝트 일 수 있음)
    • 사무실에서 숨길 필요가없는 개발자는 더 행복합니다
  • 지식 공유 허용 및 장려
  • 개발자가 코드연마 하도록 허용 (및 권장)
    • 다음 작업으로 넘어가는 것은 흥미로울 수 있지만 만족스러운 수준의 품질로 마무리하지 않고 한동안 작업 한 작업 을 포기 하도록 강요하는 것은 여러 가지 이유로 나쁩니다. 위에서 언급 한 감정 (선물, 장인 정신 등)을 잃어 버리면 질이 떨어집니다.
    • 개발자가 작업을 마치는 동안 재미를 느끼고 대체 구현을 실험 해보십시오 (벤치 마크가 나타나면 잠재적으로 유리합니다).
  • 팀 / 개인간에 성가신 작업 을 교체
    • 여러 사람이 필요한 기술을 갖출 수 있도록
    • 동료들이 "아하!"를 가리 키지 않고 언젠가는 배가 고프지 않은 일을 다루는 사람들에게 그들의 짐을 나누고 조금 더 동정심을 느끼게하고 그들을 돕기를 원합니다.

카우보이 코딩이나 잠수함의 영향을 피하기 위해 할 수있는 모든 일을하십시오. 개발자가 자신 이하는 일을 자랑스러워 하고, 자신이하는 일을 즐기고 , 다른 사람에게 보여주고 다른 사람들 이 그들의 노력에 참여 하게하기를 바랍니다.

프로그래머에게 피해를 줄 수있는 문서 작업의 경우에도 다음을 시도하여 문서를보다 재미있게 만들고이를 완성 된 제품을 생산하는 느낌과 연결하십시오. 문서는 공식 제공 물뿐만 아니라 제품 자체의 필수 부분으로 나타나야합니다.

  • 그들이 원하는 도구, 템플릿 및 프로세스를 사용하도록 허용
    • 프로젝트가 시작되기 전에 설정하고 일관성을 유지하십시오.
    • 프로세스가 가능한 가볍고 즐겁도록 회고의 일부로 프로젝트간에 검토하십시오.
    • 마케팅 부서가 귀하에게 강요하는 추악한 (그리고 무엇보다도 비현실적인) 템플릿을 사용하는 것은
  • 과도하다고 생각되는 문서에 대해 토론 할 수 있도록합니다.
    • 그들이 옳고 부하를 줄이는 데 도움이 될 수 있습니다

그들이 되십시오 교사 , 전도자 또는 아무것도가 다른 사람에게 노하우 나 지식을 데려의 위치에 박았을 모두 당신의 SDLC와 기업 문화의 한 부분으로. 가르 칠 기회가있는 사람이라면 누구나 학생들이 감사의 표시를 보이지 않을 때에도 자신이 얻는 느낌을 알 수 있습니다. 그래도 일반적인 경우를 고려해 보자. 그리고 직접적인 보상은 얻지 못한다. 또한 동시에 힘을 실어주고 겸손하게 만듭니다 (항상 자신을 잘못 증명하거나 무언가에 대항 할 사람을 찾을 수 있습니다).


다음 섹션에서는 본질적으로 동기 부여가 아닌 요점을 간략하게 설명합니다.

그들이 질문에 직접적으로 관련되지 않을 수도 있지만, 나는 그들이 내재적으로이 본질적인 동기를 육성하는 데 간접적으로 도움 이 되는 좋은 포인터라고 생각하기 때문에 그것들을 목록으로 남겨 두는 것을 선호합니다 .

기업 문화의 일부로

  • 개발자가 공유 할 정기적 인 대화 / 세션 을 설정하십시오 .
    • ... 프로젝트를 진행하면서 얻은 지식
    • ... 무언가에 대해 활기차고 열정적으로 만드는 것에 대한 지식
  • 개발자를 신뢰
  • 기술자에게 기술적 결정을 내림
    • 그것들을 결정 과정의 일부로 만드십시오
    • 들으십시오 (또는 그들이 닫히더라도 놀라지 마십시오)
  • 그들의 삶을 더 쉽고 좌절없이 만드십시오 :
    • 좋은 개발 도구
    • 좋은 하드웨어
    • 좋은 환경
    • 공짜 음식
    • 바보 같은 장난감 거짓말
    • 아이디어를 논의 할 장소 및 조용히 반영 할 장소

새로운 스타터

  • 새로운 스타터의 업적 개요 (StackOverflow 스타일 단계 및 "잠금 해제"에 필요한 상을 생각하십시오)
  • 기술 수준 내에서 과제를 할당하지만 충분한 도전 과제가 있습니다.

1
내가 본질적 동기를 부여한 정의는 그것이 " 과업 자체 에 대한 관심 이나 즐거움 에 의해 주도되는 동기"라는 것을 기억하십시오 . 당신이 언급 한 많은 것들이 과제 자체를 뛰어 넘습니다. 이러한 것들이 프로그래밍 작업에 대한 관심이나 즐거움을 키우는 데 어떻게 도움이 될 수 있습니까? 프로그래밍의 사회적 활동에는 그리 많지 않습니다.
Matthew Rodatus

@Matthew Rodatus : 죄송합니다. 제 생각에는 그 생각을 건너 뛰었습니다. 이 경우 모든 기업 문화 측면이 본질적인 것은 아니라고 생각합니다. 그러나 첫 번째 섹션에서 언급 된 대부분의 요점은 개발자가 이미 보유하고 있어야하는 가치에 호소합니다. 반응으로이를 트리거하는 것입니다. 예, 그것은 외부 행동을 암시하지만, 당신은 당신이이 본질적 동기를 키우고 싶다고 언급했습니다. 나는 오늘 밤 늦게 당신의 의견을 염두에두고 확장하려고 노력할 것이지만, 그것은 점심 시간에 대한 빠른 대답이었습니다.
haylem

"새로운 스타터에 대한 개요 성과 (...)"-그들은 외적인 동기가 아닌가?
Martin Thompson

@haylem 노력해 주셔서 감사합니다. 첫 번째 섹션의 대부분의 요점은 본질적인 동기를 부여 할 수 있다는 데 동의합니다. 잘 했어.
Matthew Rodatus

@ 마틴 : 예. 마찬가지로, 그들은 외부 보상입니다. 그러나 그들은 당신에게 육체적 보상을주지 않으며, 심지어 비교할 수는 있지만 포인트를주지 않습니다. 그러나 그것은 내부의 자질에 호소합니다. 선한 일에 대한 자부심, 장인의 지위를 파악하고 특정 기술 수준을 보여 주려는 욕구 등 ... 많은 간접 동기가 내재적 가치에 호소하는 것 같습니다.
haylem

5

대부분의 비즈니스 소유자가 여기에 요점이 없다고 생각합니다.

물론 돈을 살 수있는 최고의 도구를 제공하고, 사무실에 개발자를 배치하고, 베네수엘라에 무료 식사 / 맥주 / 여행을 제공합니다.

이것들은 모두 훌륭한 특권 이지만, 하루가 끝나면 소유자의 이익을 높이는 것 (그리고 개발자가 직장에서 "즐거워하는"것)이라는 한 가지 목적을 제공합니다. 그리고 그것은 완벽하게 괜찮습니다.

그러나 외근으로 일하는 우리 모두에게있어, 그래, 나는 그런 특권을 기쁘게 생각하지만, 내 보너스 / 보상 / 13 번째 급여 / 무엇을 대신 할 수는 없습니다. 나를 위해. 그것이 효과가없는 것처럼 보이면 회사를 관리하는 사람들이 합리적인 속도로 충분한 현금을 버리고 있지 않을 수 있습니다.


6
돈은 (보통) 필요 하지만 동기 부여 에는 충분 하지 않다고 말하고 싶습니다 .
벤 호킹

1
@Ben-그렇기 때문에 금전적 보상으로 특권을 원한다고 말한 것입니다.
Jas

내 질문은 구체적으로 돈과 같은 외적인 동기 부여를 촉진하는 방법을 다루고 있습니다.
Matthew Rodatus

1
@Matthew Rodatus-@haylem이 그 점을 잘 다루었다고 생각하지만 @Jas가 작성한 요점을 간과하는 것이 위험하다고 생각합니다. 나는 일부 관리자 들이 본질적 동기 에만 초점을 맞추고 있다고 들었습니다 . 그것은 전혀 집중하지 않는 것보다 큰 실수입니다.
Ben Hocking 13:23에

2
동기 부여를 죽이지 않는 것에 대한 나의 대답과 일치 : 돈으로 동기를 부여받지 못할 수도 있지만, 평소의 금액으로 보상받을만큼 귀하의 작업이 충분히 인정되지 않는다는 것을 깨닫면 동기 부여를 죽일 수 있습니다.
keppla

5

불행히도, 연구에 따르면 ( 이 새로운 과학자 기사 , 전문을 구독해야 함) 돈은 창조적 인 노력에 큰 동기가되지 않음을 보여줍니다 . 실제로 사람들이 덜 열심히 일할 수 있습니다.

따라서 사람들에게 동기를 부여하는 가장 좋은 방법은 그들이하는 일이 생존에 중요하지 않다고 믿도록 돕는 것입니다. 이를 통해 더 큰 위험을 감수하고 더욱 창의적으로 행동 할 수 있습니다.

어떻게해야합니까?

본질적으로 문제는 성과 관련 급여와 같은 것들 때문에 발생합니다. 사람들은 자신이하는 일이 옳다는 것을 알아야하지만, 유료 패킷의 크기를 이에 의존 할 필요는 없습니다.

돈을 가진 사람들에게 동기를 부여하려면 회의에서주의를 기울이는 것과 같은 사소한 일에 돈을 쓰십시오.

창의력은 실험이 허용되고 어떤 목표 나 다른 목표를 충족하지 않아 처벌되지 않는 환경에있게함으로써 촉진됩니다.

원하는 것은 시도되고 테스트 된 방법의 구현과 실험의 균형을 맞추는 것입니다. 그래서 당신은 문제를 뒤집습니다. 예를 들어, 수정 된 모든 N 고객 문제 또는 구현 된 모든 불쾌한보고 기능에 대해 새로운 기술을 사용하거나 오래된 문제를 해결하는 새로운 방법을 모색해야합니다.

보너스를위한 돈이 있다면, 대신에 회의에 참석하거나 (팀이 가고 싶어하는) 회의에 참여하거나 실험 / 흥미로운 추가 비즈니스 프로젝트 (귀하의 팀이 참여하기를 원함)에 투자하십시오. 장비.


3

개발자가 올바른 일을하도록 신뢰함으로써

대부분의 개발자는 그러한 기능을 제공 할 경우 양질의 제품을 개발하려고합니다. 개발자가 더 빠른 장비, 더 나은 모니터 또는 조용한 작업 조건을 요구하는 경우 제공하도록 노력하십시오.


3

동기 부여는 수행해야 할 작업에 대한 태도에 달려 있습니다. 우리가 한 일에서 빛을 발하거나 뛰어 넘는 태도를 가지고 있다면 실제로 더 나빠질 수 있습니다. 학교에서 시험을 치르거나 스포츠 클럽의 일원이되어 게임을 능가하거나 이기고 싶었던 시절을 생각해보십시오. 성능 마인드 종종 우리를 방해 압력에 결과는 정말 잘 수행하거나 창의적인 솔루션 (참조 찾기 위해 동기 부여에 댄 핑크 ). 따라서 자신의 성과에 따라 보상을 사용하면 실제로 업무 수행에 대한 본질적 동기가 줄어들 수 있습니다.

성과 사고 방식과는 반대로 학습 사고 방식 에 기반한 업무 지향적 인 방향이 있습니다 . 여기서 결과는 그 자체로는 중요하지 않지만 작업을 수행하고 작업의 컨텍스트를 이해하는 프로세스입니다. 스포츠 비유에서, 이것은 조금 개선하려고 할 때입니다. 궁극적으로 승리에 대한 기대는 없으며, 최고를 제공하고 실패로부터 배우십시오. 궁극적 인 실패에 대한 이해를 높이면 개인의 부와 지식이 생겨 장기적으로 우리의 본질적 동기를 증가시킬 수 있습니다. 이 유형의 사고 방식은 Steve Ritter (CMU)와 Carol Dweck (Stanford)가 논의합니다.


당신은 돈의 부정적인 예를 들었지만 성장과 발전에 대한 긍정적 인 예는 무엇입니까?
Matthew Rodatus

아마 이것은 힌트입니다 : youtube.com/watch?v=ZHbxB2Q48Zo
poseid

답변에 정보를 요약하고 링크를 게시하는 대신 결론을 도출 할 수 있습니까?
Matthew Rodatus

이것이 더 명확합니까? 어떻게 생각해?
poseid

나는 그것을 좋아한다. 좋은 대답입니다. +1
Matthew Rodatus

2

악마의 옹호자 역할을하겠습니다.

사람들은 매우 이기적인 생물입니다. 그들은 주로 자신에 관심이 있습니다. 그것을 바꾸는 것은 매우 어렵다. 따라서이 약점을 탐색하여 이점을 활용해야합니다.

사람들이 "과업 자체에 대한 관심이나 즐거움"을 가질 때, 그들은 호기심을 만족 시키거나 어떤 도구를 배우기 위해 개인적인 관심을 추구하고 있음을 의미합니다. 왜 도구를 배우는가? 개인 프로그래밍 (자체 지향)에서 사용하거나 마케팅 이점 (욕심 많은 이익)으로 전환하십시오. 이타주의 흔적은 거의 없습니다.

"내재적 동기 부여"를 위해서는 팀원들이 갖고 싶은 달콤한 현상금에 목표를 두어야합니다. 회사에 가치있는 것 (일부 기술 또는 비 기술적 분야의 지식 및 전문 지식)과 개인에게 가치있는 것 (유명한 인증, 직책, 급여 충돌)을 결합하십시오. 이 방향으로 생각하십시오.

솔직히 말해서 이타적인 사람들도 있습니다. 그들 없이는 세상은 이미 무너 졌을 것입니다. 그러나 그들은 반드시 당신의 계급에 참여하는 데 관심이 없지만, 사회에 기여할 수있는 다른 방법 (오픈 ​​소스, 개인 프로젝트, 포럼 지원 등)을 항상 찾을 수 있습니다. 그래서 당신은 기본으로 돌아가서 탐욕스러운 프로그래머에게 윤활유를 공급하는 방법으로 돌아갑니다.


당신은 여기에 외적인 동기를 부여하고 있는데, 그것은 실제로 반응하지 않습니다.
David Thornley

3
-1. 사람들은 실제로 이기적이지 않습니다. 수천 년의 진화가 그것을 처리했으며, 쉽게 입증되었습니다. 그러나 사람들은 이기적으로 행동 할 수 있습니다 . 그리고 그들이 그렇게 할 때 상당히 예측 가능합니다. 이기주의는 사회적 배제와 밀접한 관련이 있습니다. BTW, _under_paying 사람들은 감사의 부족을 보여 배제 감을 느끼고 이기심을 유발합니다. 이것이 지불이 사회적 위생 요소 인 이유입니다. 동기 부여는 아니지만 동기 부여를 막습니다.
MSalters

2

Atwood 씨의 말 에 따르면 해결해야 할 문제에 관심이있는 사람들을 고용 해야합니다 . 그들의 동기는 기존의 관심사, 즉 그 사람에게 내재 된 관심에서 비롯됩니다. 나는 당신이 본질적 동기를 키울 수 있다고 생각하지 않습니다. 단지 당신이 그것에 호소 할 수 있다고 생각합니다.

보상은 여전히 ​​중요하지만, 동일한 보상이 주어지면 관심있는 문제가있는 곳에서 일하고 싶습니다.이 관심이 있기 때문에 자연스럽게, 의도하지 않게 더 열심히 일할 것입니다.


좋은 답변을 얻으려면 +1하십시오. 팀이 전체적으로 효과적 이도록 본질적 동기를 공유 할 수 있다고 생각하십니까? 내 답변보기 : programmers.stackexchange.com/questions/78477/…
Matthew Rodatus

@Matthew Rodatus : 흥미로운 문제를 발견 한 사람들의 열정은 본질적인 관심이 아니라 공유 될 수 있다고 생각합니다. 그러나 열정은 팀의 모든 사람들에게 동기를 부여하기에 충분할 수 있습니다.
dietbuddha

+1 절대적으로 맞습니다. 이 업계에서 10 년이 지난 후에도 내 업무에 100 % 만족하지 못하는 동시에 (순수한 프로그래밍을 좋아하는 동시에) 이것이 핵심임을 깨달았습니다. 임의의 지루한 비즈니스 시스템을 사용하면 비참하고, 강렬하고 비생산적이며 결국 태워 질 것입니다. 코딩이 내가 좋아하는 문제 영역과 내가 믿는 원인을위한 장소에 놓으면 록 스타가 될 것입니다.
Bobby Tables

1

물론 팀원들이 다르게 동기를 부여하는 것은 당연한 일입니다. 어떤 사람들은 외적 동기 부여 (예 : 돈)를 위해 일하고 어떤 사람들은 내재적 동기 부여 (예 : 품질 소프트웨어)를 위해 일합니다.

그러나이 팀원들은 서로 협력하고 서로의 강점을 공유 할 수 있어야합니다.

그들이 양질의 작업을한다면 개발자는 수용 가능하다. 그러나 그들이 진정으로 자신의 일을 즐기지 않으면 리더로 고용하기가 어려울 것입니다. 중요한 리더십 특성은 열의입니다. 왜냐하면 그것은 다른 사람들이 당면한 일을 즐기도록 추진하기 때문입니다.

또 다른 중요한 역학은 건강하고 규칙적인 사회적 상호 작용입니다. Joel Spolsky는 최근 팀 점심의 이점대해 블로그를 작성했습니다. : "함께 먹는 것은 그것이 인간과 그것이 무엇 ... 인도적 직장을 가지고 의미된다는 것이 무엇을 의미하는지의 중요한 부분이다" 틀에 박힌 개발자가 내성적하더라도, 외로움 사기가 꺾이는 및됩니다 프로그래밍을 즐기기가 어렵습니다.

요약하면, 열정적 인 리더십격려적인 동지 관계를 통해 일부 사람들이 갖고 있고 다른 사람들이 갖지 못한 본질적인 동기는 팀에 의해 전달되고 공유 될 수 있습니다.


이 대답은 내 자신의 가설로 구성됩니다. 커뮤니티의 다른 회원들이 어떻게 생각하는지 궁금합니다.
Matthew Rodatus

0

내 생각에, 본질적 동기는 매슬로우의 필요 계층에서 개인의 마지막 요구에 매핑된다. 그것은 그 자체로는 필요하지 않지만 자기 실현에서 나온 것이다. 이 계층 구조가 모든 상황에 적용되는 것은 아니지만,이 계층 구조의 기초를 무시하면 내재적 동기가 부족한 경우가 많습니다.

대부분의 조직은 개인이 마지막 요구를 충족 시키려고 노력하지만 대부분은 계층의 맨 아래에있는 요구에 초점을 맞추지 않습니다.


0

이 기사와 그 뒤에있는 이론에 대한 나의 취지는 사업 소유자가 노동 비용을 평가 절하하려는 시도이며 사람들이 "행복하기 위해이 돈이 모두 필요하지 않기 때문에 문제가되지 않는다" 우리가 당신에게 인상을주지 않거나 우리가 시장보다 낮은 가격으로 당신을 고용한다면 당신은 당신이 직업을 가지고 있다는 것을 기뻐해야 할 것입니다. 토요일 오전 6 시부 터 자정까지는 "약혼 한"근로자 꿀벌이하는 일이 더 좋기 때문에 좋은 일을하게 될 것입니다. 프로젝트를 위해 자신을 죽이고 나면 "

이 연구는 청구서를 지불하거나 테이블에 음식을 넣는 방법에 대해 걱정할 필요가 없다는 점에서 "편안한"금액으로 누군가에게 얼마를 지불하든 문제가되지 않는다고 밝혔다. 그래서 얼마입니까? 40k / 년 USD? 30k?

본질적 동기 부여를 육성하는 방법에 관해서는 @keppala에 동의합니다. 본질적 동기는 내면에서 나옵니다. 당신이 할 수있는 최선은 그것을 가지고있는 직원들로부터 그것을 스너프하지 않는 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.