프로그래머 팀 관리: 그들에게 적절한 동기를 부여하는 방법과 방법은 무엇입니까? XNUMX부

Epigraph :
남편은 더러운 아이들을 바라보며 아내에게 말합니다. 글쎄, 이걸 씻어야할까요, 아니면 새 아이를 낳을까요?

컷 아래에는 우리 팀 리더와 RAS 제품 개발 이사인 Igor Marnat가 프로그래머에게 동기를 부여하는 특징에 대해 논의한 내용이 있습니다.

멋진 소프트웨어 제품을 만드는 성공의 비결은 잘 알려져 있습니다. 멋진 프로그래머로 구성된 팀을 구성하여 팀에 멋진 아이디어를 제공하고 팀 작업을 방해하지 마십시오. 멋진 개발자는 드물고 수요도 많습니다. 일부 채용 담당자는 시장에서 프로그래머를 고용하는 것보다 멋진 프로그래머를 양성하는 것이 더 쉽다는 인상을 받았다고 말하기도 합니다. 채용의 어려움 외에도 각 특정 개발자의 경험, 기존 제품에 대한 지식 및 개발 이력은 종종 대체할 수 없거나 보충하기 어렵고 시간이 많이 걸립니다. 따라서 운이 좋고 이미 멋진 프로그래머 팀이 있다면 그들의 동기를 부여하는 것이 중요합니다. 새로운 개발자를 고용하고 훈련시켜 그들로 팀을 구성하는 것은 아이를 낳고 키우는 것만큼이나 어렵고 시간이 많이 걸리는 일입니다.

프레젠테이션의 명확성과 구조화를 위해 Maslow의 피라미드를 사용하여 프로그래머(프로그래머 팀)에 대한 동기 부여의 주요 요소를 고려해 보겠습니다. 매슬로의 피라미드에 대해 들어본 적이 없다면, 이는 인간의 욕구 계층에 기초한 개인적 동기 부여 이론을 제안한 미국 심리학자 Abraham Harold Maslow의 매우 인기 있고 예시적인 이론입니다(아래 그림 참조).

매슬로우는 개인의 욕구를 생리적 욕구부터 잠재적인 발달과 자아실현의 욕구까지 계층적 순서로 정리했습니다. Maslow 이론의 핵심 가정은 "사람은 낮은 수준의 욕구가 충족될 때까지 더 높은 수준의 욕구를 경험할 수 없다"는 것입니다. 예를 들어, 사람이 XNUMX일 동안 잠을 자지 않거나 먹지 않으면 지식이나 미적 욕구에 의해 움직일 수 없습니다.

세부 사항을 설명하기 전에 분명한 사실에 초점을 맞춰 보겠습니다. 팀은 사람들로 구성되고, 모든 사람들은 다르며, 각자는 자신만의 동기 부여 구조를 가지고 있습니다. 사람마다 다른 관심사에 의해 움직인다는 사실 외에도 사람마다 생활 조건도 다릅니다. 누군가는 경력을 시작하면서 경력을 쌓는 방법에 대해 생각하고 있고, 누군가는 결혼할 예정이며, 누군가는 새로운 주제 영역을 마스터하고 싶어합니다. 한 사람에게 중요한 것은 다른 사람에게는 완전히 중요하지 않으며 내일 모든 것이 다시 바뀔 것입니다. 이 맥락을 올바르게 이해하려면 간단한 해결 방법이 있습니다. 이에 대해 생각하고 작업해야 합니다. 가장 중요한 것은 의사소통이다.
업무 이외의 것에 대해 팀과 이야기하고 비공식적 인 관계를 구축하십시오.

이제 Maslow의 피라미드를 살펴보고 프로그래머 팀 관리에 적용되는 수준을 고려해 보겠습니다.

I: 생리적, 생물학적 요구:

동기부여에 관해 이야기할 때 많은 사람들이 연봉을 먼저 생각하는 경우가 많습니다. 이 경우 급여란 결과에 전혀 의존하지 않는 보상 패키지의 영구적인 부분을 의미합니다. 이는 보너스, 보너스 및 회사 프로모션에는 적용되지 않습니다. 우리의 경우 "생리적 필요"수준에 따른 급여입니다. 보너스, 성과에 따른 보너스, 옵션 및 회사 지분 - 저는 이 모든 것을 다른 수준으로 분류하겠습니다.

내 생각에는 아무리 이상하게 들리더라도 월급은 오히려 의욕을 꺾는 동기요인이 아니라 동기요인이다. 프로그래머와 함께 일할 때의 특징은 그들이 모두 사람이라는 것입니다. 첫째, 매우 똑똑하고(직업의 특징), 둘째, 깊이 있고/또는 폭넓게 교육을 받았습니다. 일반적으로 프로그래머는 자신의 직업 외에도 자신이 제품을 만드는 하나 이상의 주제 영역에 대해 깊은 이해를 갖고 있습니다. 또한 좋은 프로그래머는 프로그래밍 개발의 역사, 알고리즘, 표준 등에 관심이 있고 잘 알고 있습니다. 주제 영역에도 동일하게 적용됩니다. 이 수준의 사람들에게는 일반적으로 급여가 주요 동기 부여 요소가 아닙니다.

동시에 프로그래머에 대한 공정한 급여가 부족하다는 점은 그들의 이해에 따라 의욕을 꺾고 의욕을 크게 떨어뜨립니다. 정당한 급여를 받는 것이 일반적입니다. 급여는 (시장) 표준보다 훨씬 높습니다. 또한 이상하게도 다소 의욕을 잃게 만드는 요인이기도 합니다. 한 동료가 미국의 대형 애니메이션 회사 중 한 곳의 프로그래머 팀에 대해 말한 적이 있습니다. 이 팀은 여러 상황으로 인해 시장보다 XNUMX~XNUMX배 높은 급여를 받았습니다. 그가 말했듯이, 그는 평생 동안 이보다 지루하고 게으르고 의욕이 없는 프로그래머를 본 적이 없습니다. 급여 인상 사실이 단기적으로는 동기를 부여할 수 있지만, 몇 달이 지나면 새 급여가 표준이 되어 동기 부여가 중단됩니다. 일반적으로 경력 초기의 프로그래머에게는 급여 요소가 더 중요합니다. 전문적으로 성장하고 발전함에 따라 그 중요성이 감소하고 다른 요소가 우세하기 시작합니다.

두 번째 중요한 점은 팀 급여 수준이 공정하게 균형을 이루고 있다는 것입니다. 팀에서 한 구성원의 기여도가 눈에 띄게 낮다고 느끼더라도 보상 수준이 같다면 팀 전체의 사기가 저하됩니다. 때때로 관리자들은 급여를 정상 이상으로 인상하여 지치거나 의욕이 상실된 사람을 유지하기 위해 돈으로 불을 지르고 싶은 유혹을 받습니다. 이것은 일반적으로 장기적으로 문제를 일으킬 뿐입니다. 그 사람 자신의 동기는 크게 증가하지 않거나 몇 달 동안 증가하지만 나머지 팀의 동기는 떨어질 것입니다. 그러한 상황에서는 짧은 시간이라도 어떤 비용을 치르더라도 유지해야 하는 독특한 전문가가 아닌 한 다른 접근 방식을 찾아볼 가치가 있습니다.

II. 안전, 편안함, 생활 조건의 일관성에 대한 필요성:

70년 전에는 자동차에 난로가 있다는 것이 자동차를 선택할 때 동기 부여 요인이 될 수 있었지만, 당시에는 그것이 표준 이상이었고 럭셔리함의 상징이었습니다. 이제 에어컨이 없다는 것조차 말도 안되는 일이며, 물론 그 존재는 자동차를 선택할 때 동기 부여 요인이 되지 않습니다. 그래서 10~15년 전에는 편리한 사무실, 좋은 하드웨어, 맛있는 커피, 피트니스, 유연한 근무 시간 등이 있었습니다. 좋은 동기 부여 요소가 될 수 있지만 이제는 이것이 훌륭한 프로그래머의 작업에 대한 표준이 되었습니다. 동시에, 그들의 부재는 다시 의욕을 잃게 될 것입니다.

중요한 사기 저하 요인은 집중력 부족과 시끄러운 작업 환경입니다. 프로그래머의 작업에는 침묵과 집중이 필요합니다. 사무실 공간이 개발자에게 한적한 작업 공간을 제공할 수 있는 기회를 제공하지 못한다면, 최소한 서로 간섭하지 않는 동료들 간의 편안한 협업을 보장해야 합니다. 활기차고 시끄러운 동지들을 서로 하나로 묶어 필요한 사람들에게 집중할 수있는 기회를 제공하는 것이 좋습니다.

프로그래머의 시간 비용은 이제 그가 작업하는 하드웨어 비용보다 훨씬 높습니다. XNUMX~XNUMX개의 모니터, 강력한 컴퓨터, 모든 개발자를 위한 편안한 작업 공간은 모든 회사의 표준이어야 합니다. 이 주제는 Joel Spolsky의 기사 중 하나에서 잘 다루고 있습니다.조엘 테스트: 더 나은 코드를 위한 12단계.”

편안함의 물리적인 요소는 가장 기본적이고 단순합니다. 이제 나머지에 대해 이야기해 보겠습니다.

많은 회사에서 프로그래머의 표준은 유연한 근무 일정과 복장 규정이 없습니다. 이는 팀 작업의 세부 사항이 허용하는 경우(예: 고객, 정치인 또는 은행가와의 회의가 없는 경우) 좋고 정확합니다.

중요한 것은 사람들이 직접 소통하고 문제를 해결할 수 있도록 전체 팀이 현지에서 함께 작업할 수 있는 특정 시간을 갖는 것입니다. 프로그래머는 본질적으로 퇴근 후에도 퇴근하지 않습니다. 일반적으로 업무 문제는 사무실에 있든 상관없이 마음속에 다시 떠오르며, 좋은 결정은 사무실 외부에서 나오는 경우가 많습니다. 선해야 할 필요성을 고려할 때(아래에서 논의할 것입니다), 사소한 통제는 해롭습니다. 이는 의욕을 꺾을 뿐만 아니라 생산성도 저하시킵니다. 실습에서 알 수 있듯이, 통제력이 없으면 동기가 부여된 팀은 필요 이상으로 오래 일할 가능성이 더 높습니다. 통제력이 있다면 개발자는 XNUMX시부터 XNUMX시까지 키보드 앞에 앉아 있을 수 있지만 결과는 더 나쁠 것이라고 생각합니다. 그들이 말했듯이 한 사람이 말을 물가로 이끌 수 있지만, 백 명이 원하지 않으면 물을 마시도록 강요하지 않을 것입니다.

이 수준의 욕구에 대한 설명에는 불안과 두려움으로부터의 자유, 혼란의 부재, 구조와 질서의 필요성도 언급됩니다. 이는 팀 분위기에 큰 영향을 미치는 매우 중요한 포인트이기도 하다.

첫째, 혼돈, 구조 및 질서의 부재 - 팀은 누가 무엇을 담당하는지, 역할이 어떻게 분배되는지, 무엇을 수행해야 하는지, 누구에게, 언제, 제품의 기초가 되는 요구 사항이 무엇인지, 경영진의 기대 사항이 무엇인지 이해해야 합니다. 고객... 이 중 대부분은 공식적으로 설명되어야 하며 모든 것은 정기적으로 논의되어야 합니다. 토론과 주기적인 사용 없이는 설명이 작동하지 않습니다. 정기적으로 논의하고 출시 후 사후 분석 결과를 바탕으로 업데이트하는 것이 좋습니다.

둘째, 조용하고 친근한 분위기입니다. 우리 모두는 대부분의 시간을 직장에서 보내며 스트레스, 갈등, 두려움 없이 일을 하고 싶어합니다. 개발팀은 일반적으로 일정과 고객의 압박을 받으며 일합니다. 누구도 동료나 상사로부터 추가적인 스트레스를 받을 필요가 없습니다. 팀의 분위기, 일반적으로 개발자 그룹이 호출되어 "팀"이 될 수 있다는 사실 자체가 관리자의 직접적이고 중요한 책임이며 가장 중요한 중장기 작업 중 하나입니다. 따라서 관리자는 특히 팀 내 갈등을 해결하고 개발 과정이 진행되지 않도록하는 것이 중요합니다. 갈등 관리는 별도로 연구할 가치가 있는 별도의 주제입니다.

팀의 감정 상태와 동료의 행동에 영향을 미치는 두 가지 주요 방법이 있습니다(누군가가 댓글을 추가하면 좋을 것입니다). 첫 번째는 자신의 행동입니다. 개인적인 모범은 관리자와 팀에게 매우 중요합니다. 그들이 말했듯이 신부도 마찬가지고 도착도 마찬가지입니다. 동료가 행동하기를 기대하는 방식으로 행동하십시오. 두 번째는 올바른 행동을 장려하고, 말하자면 잘못된 행동을 장려하지 않는 것입니다. 사람들과 소통하고 피드백을 제공하는 등 다양한 방법이 있습니다. 일반적으로 피드백은 별도의 논의 주제이며 동기 부여 작업에서 크고 중요한 부분입니다.

특이한 것처럼 보일 수도 있지만 실제로는 중요합니다. 개발팀에는 남성보다 여성의 수가 적은 경우가 많습니다. 종종 그룹은 완전히 남성입니다. 그러한 상황에서, 또한 부하가 걸린 상태에서 때로는 외설적인 언어가 팀에서 사용되기 시작합니다. 실습에 따르면 이것이 대기에 부정적인 영향을 미치고 의사 소통이 점차 무례해집니다. 스스로 사용하는 것을 피하고 팀 내에서 사용하는 것을 권장하지 않아야 합니다.

개발팀은 흔히 R&D(연구 및 개발)라고 불리며, 연구가 작업의 상당 부분을 차지합니다. 이것은 일반적으로 프로그래밍하고 계획하기 어려운 부분입니다. 그렇지 않으면 연구가 아닙니다. 팀이 실수를 하고, 주도권을 갖고, 성공으로 끝날 수도 있고 그렇지 않을 수도 있는 다양한 옵션을 시도할 권리가 있다는 것이 중요합니다. 실수는 업무의 정상적인 부분이므로 피할 수 없습니다. 하지만 미래를 위해 연구하고, 분석하고, 배우고 계속해서 나아갈 수 있습니다. 토요타에서 시작된 5 Why 원칙은 문제의 근본 원인을 찾는 좋은 방법입니다. 실수를 처벌하는 것은 두려움과 불확실성의 분위기를 조성하는 좋은 방법입니다. 유일한 예외는 분석 결과에 따르면 업무에 대한 비전문적인 태도로 인해 오류가 발생한 것으로 밝혀진 경우이며, 이 경우 인사 결정을 내려야 할 수 있습니다.

팀 분위기는 대화가 시작되기 전의 기대와 감정 상태에 따라 크게 영향을 받습니다. 어려운 토론, 일종의보고 또는 감정적 대화를 시작하기 전에 대화하려는 사람에 대한 기분과 태도가 중요합니다. 나는 항상 그 사람이 진심으로 최선을 다하려고 노력한 것을 기본으로 믿고 행동합니다. 당신의 입장에서 볼 때 그렇지 않은 것 같다면, 상황을 차분하고 자세하게 파악하고 그가 옳은 일을 한 것이 무엇인지, 왜 그것이 옳다고 생각했는지, 그리고 우리의 기대가 어디에서 갈라지는지 이해해야 합니다. 일반적으로 그 둘은 크게 다르지 않은 것으로 밝혀졌습니다. 단지 맥락에 대한 그의 비전이 더 완전하거나 신선하고, 당신이 몰랐던 것이 있다는 것입니다. 아니면 반대로 그는 아무것도 몰랐습니다. 이는 사람들이 직접 소통하는 횟수가 적고 이메일과 인스턴트 메신저를 사용하는 분산된 팀에서 특히 중요합니다. 이는 다양한 국가의 프로그래머로 구성되고 다양한 시간대에 분산되어 있는 팀에서는 더욱 중요합니다. 여기서 문화적 차이가 큰 역할을 하기 시작합니다.

어려운 상황에서 이동 중 운전은 쉽고 매우 쉽지만 후진 운전은 어렵고 퇴적물이 오랫동안 남아 있습니다. 최근 경험에서 나온 간단한 예를 들어보겠습니다. 팀장 중 한 명은 고객과 관련된 문제에 대해 다른 국가의 관련 팀 관리자의 의견이 급히 필요했습니다. 그는 메신저로 동료에게 핑을 보냈고, 15분을 기다렸다가 다시 핑을 했고, 15분 뒤 다른 매니저들도 있는 대규모 채팅으로 가서 다음과 같은 말로 동료를 살짝 공격했다. 나에게 대답해 주실 수 있습니까? 아마도 질문은 그렇게 긴급하지 않습니까?” 결국 우리 기업 메신저가 약간 둔감했고, 동료가 질문을 전혀 보지 못한 것으로 나타났습니다. 나는 사과해야했다. 일반적으로 좋은 것부터 시작하는 것이 좋습니다. 나쁜 실수를 하고 나중에 문제가 생길 수 있는 가능성은 언제나 있습니다. (그렇게 해서는 안 되겠지만) 문제는 없습니다. 일반적으로 업계에서 20년 넘게 일하면서 정말 악의적인 동료를 만난 것은 딱 한 번(!) 입니다. 다행히 우리는 꽤 빨리 헤어졌다. 대부분의 경우 동료가 상황을 최대한 이해하기 위해 최선을 다한다고 가정하는 것이 올바른 것으로 나타났습니다.

관리자로서 귀하의 임무는 컨텍스트의 동기화, 기대치, 요구 사항, 기한 및 팀에서 허용되는 표준에 대한 공통된 이해를 보장하는 것입니다. 사소해 보일 수도 있지만, 팀의 분위기는 바로 이 작은 것에서부터 형성됩니다. 분산된 팀 관점에서 볼 때 중요한 작업 중 하나는 팀 구성원이 정기적으로 대면 커뮤니케이션을 하도록 하는 것입니다. 예를 들어 지원 팀의 엔지니어가 직접 와서 함께 일한 후 기꺼이 직장에 머물면서 최근 그들에게 온 파샤에게 개인적으로 어려운 상황을 도왔다는 말을 프로그래머로부터 여러 번 들었습니다. 이전에 파샤는 메신저의 아이콘일 뿐이었고 아이콘 때문에 아무도 멈추지 않았을 것입니다.

그건 그렇고, 나는 지원 팀에 대해 이야기하기 시작했고 정식 예를 기억했습니다. 한번은 미국 고객 중 한 분이 제품에 문제가 생겼는데, 그 구현 작업을 하던 지원팀 엔지니어 중 한 분이(러시아에서 파견) 퇴근 후 남아 도움을 주셨는데, 문제가 해결되지 않고 계속 나오더군요. 일반적으로 그는 거의 아침까지 거기에 머물며 앉아있었습니다. 이때 고객의 관리자는 문제를 에스컬레이션하고 심각도를 파악한 후 저녁에 퇴근했습니다. 에스컬레이션 프로세스는 이미 다른 시간대에서 추진력을 얻고 있었고 러시아의 지원 관리자는 고객 사무실과의 통신 문제(VPN, 연결 문제, 국가 간 통화 문제 등)로 인해 도움을 주기 시작했습니다. 그 사람이 이미 사무실에 감옥에 갇혀 있다는 사실을 모르고 문제를 해결하고 그를 찾으려고 노력했습니다. 그들은 문제가 이미 실질적으로 해결되었고 제품이 작동하고 있던 아침(미국)에만 그것을 발견했습니다. 그들은 즉시 고객이 그렇게 에스컬레이션을 당했고 아무 것도 작동하지 않으며 당신은 어디에 있는지, 우리는 당신을 찾을 수 없다고 말하기 시작했습니다. 말할 필요도 없이, 그러한 행동의 결과로 그 사람은 크게 의욕을 잃었습니다. 분산된 팀의 업무를 정리하는 것은 별개의 큰 주제이지만 두 가지를 기억하는 것이 중요합니다. 첫째, 커뮤니케이션과 분위기가 매우 중요하며 작업의 성공 여부가 이에 달려 있습니다. 둘째, 이 문제는 단독으로 해결되지 않으며 별도로 심층적으로 다루어야 합니다.

이 요구 수준과 관련된 또 다른 중요한 점은 급여입니다. 급여 규모가 아니라 급여를 변경하는 특정 절차가 있습니다. 회사는 다양한 직위에 대한 요구 사항을 결정하는 접근 방식을 가지고 있어야 합니다. 각 개발자는 자신의 작업에 대한 기대치를 회사와 논의하고 자신의 노력이 급여에 언제 어떻게 영향을 미칠 수 있는지 이해할 수 있어야 합니다. 관리자와의 정기 회의, 반기별 또는 연간 성과 검토가 이러한 목적을 위해 사용됩니다. 이것은 다시 말하지만, 존재가 명시적으로 동기를 부여하지는 않지만 부재는 매우 의욕을 떨어뜨리는 순간 중 하나입니다.

질서의 필요성과 규칙의 존재에서 이러한 규칙을 준수하고 공식 및 비공식적으로 팀에서 허용되는 규범을 따라야 할 필요성이 따릅니다. 일반적으로 말하자면, 나는 그것을 “좋은 사람이 되어야 할 필요성”이라고 부르고 싶습니다. 이러한 필요성이 존재한다는 것은 미세 관리가 필요하지 않고 오히려 해롭다는 것을 확인시켜 줍니다. 업무에 필요한 모든 것을 사람에게 제공하고, 상황과 우선 순위에 대한 지식을 제공하고, 자신의 수준에서 행동과 의사 결정의 자유를 제공하는 것으로 충분합니다. 그러한 상황에서 그는 신뢰와 스스로 결정을 내릴 수 있는 기회를 느끼고 그에 대한 책임을지며 자신의 잠재력을 드러낼 수 있을 것입니다.

질서의 필요성과 혼돈의 부재에 기인해야 하는 또 다른 중요한 점은 작업에 집중하는 능력, 빈번한 컨텍스트 전환의 부재입니다. 프로그래머가 되려면 시간과 집중이 필요합니다. 프로그래머는 긴급하게 한 작업을 포기하고 다른 작업으로 전환하는 것을 정말로 좋아하지 않습니다. 프로그래머의 작업에 필요한 부분은 일반적으로 실제 코드 개발뿐만 아니라 버그 수정 및 고객 요청 처리 지원입니다. 프로그래머가 다른 작업으로 전환하기 전에 한 작업에 대한 작업을 조용하고 완전하게 완료할 수 있도록 이러한 작업을 미리 계획하는 것이 좋습니다. 가장 좋은 방법은 스스로 작업을 계획하고, 우선 순위와 향후 작업을 미리 식별하고, 한 가지 유형의 작업에 작업하는 데 길고 연장된 시간을 할당할 수 있는 기회를 제공하는 것입니다. 이 주제는 "라는 책에 잘 설명되어 있습니다.Google - 사이트 안정성 엔지니어링”에는 대규모, 고부하, 내결함성 시스템의 운영 및 개발을 보장하는 팀의 작업 계획 방법과 소프트웨어 개발과 지원을 결합하는 직업을 가진 엔지니어에 대한 접근 방식이 잘 설명되어 있습니다.

계속 될 ...

출처 : habr.com