의사 소통 능력이 떨어지는 개발자를 관리하는 방법

나는 큰 회사 내에서 수명주기의 중간에있는 응용 프로그램에서 소규모 개발자 팀을 관리합니다. 불행히도 이것은 "다른 기술 작업"으로 30/70의 프로그래밍 작업이 일반적으로 존재한다는 것을 의미합니다. 이 작업에는 다음이 포함됩니다.

• 다양한 작업에서 DBA / Unix / Network / Loadbalancer 팀과 협력
• 다른 지역의 하드웨어 또는 인프라 주문 접수 및 관리
• 아직 CI로 마이그레이션되지 않은 테스트 실행
• 분석
• 지원 / 조사

공정한 작업을 수행하는 대신 개발자가 코딩을 선호한다는 점은 공정합니다. 따라서 팀간에 재미있는 프로그래밍 작업을 균등하게 전달하려고합니다.

대부분의 팀은 자신의 컴파일러 / 게임 엔진 / 고주파 거래 시스템 등을 작성하는 엘리트 프로그래밍 기술을 가지고 있지는 않지만 "일을 할 수있는"커뮤니케이터이기 때문에 다른 팀과 협력하기 때문에 고용되었습니다. 여기에서 복잡한 관료주의를 탐색하십시오. 그들은 훌륭한 개발자이지만, 훌륭한 만능 기술 직원이기도합니다.

그러나 팀 구성원 중 한 명이 평균 이상의 코딩 기술을 사용하지만 평균 이하의 통신 기술을 보유하고있을 것입니다. 전통적으로 이전 개발 관리자는 그에게 프로그래밍 작업을 제공하는 경향이 있었으며 위에 나열된 더 일반적인 작업은 수행하지 않았습니다. 그러나 대기업 IT 부서에서 일반적으로 요구되는 다재다능한 기술 집합을 개발할 적성을 보인 나머지 팀에게는 이것이 공정하다고 생각하지 않습니다.

이 상황에서 어떻게해야합니까? 계속해서 더 많은 프로그래밍 작업을 수행하면 더 빨리 수행 될 것임을 알 수 있습니다 (반대로, 다른 작업은 더 느리게 완료 할 것으로 예상합니다). 그러나 그것은 나의 원칙에 위배되며, 당신이 원하지 않는 일에 나쁘게 행동함으로써 자신을위한 "편안한 틈새"를 개척 할 수 있다는 아이디어를 장려합니다.

나는 원한으로 인해이 문제를 해결하려고하지 않았거나 언급 된 "어깨에 칩"이 있음을 분명히하고 싶습니다. 다재다능한 팀을 유지하는 방법에 대한 조언을 찾고 있습니다. 이 질문에 대한 다양한 답변을 관찰하면이를 달성하는 방법에 대한 많은 다른 의견이있는 것처럼 보입니다.

잘 다듬어 진 개인을 갖기 위해 너무 많은 노력을 기울이고 있고, 잘 다듬어 진 팀을 만들기 위해 충분한 노력을 기울이지 않는 것 같습니다 .

무언가를 잘하는 데는 아무런 문제가 없습니다. 실제로 그가 고용 된 이유 일 것입니다! 프로그래밍에 능숙한 사람부터 시작해 주셔서 감사합니다.

당신은 말했다 :

... 그것은 나의 원칙에 위배되며, 당신이 원하지 않는 일에 나쁜 일을함으로써 자신을위한 "편안한 틈새"를 개척 할 수 있다는 아이디어를 장려합니다.

그가 평범한 프로그래머라면 동의합니다. 그러나 당신은 그렇게 말하지 않았습니다. 당신은 그가 좋은 프로그래머라고 말했습니다. 그는 다른 과제에서 나 빠지지 않았으며, 더 나은 프로그래머가 되려는 노력에만 집중했습니다. 그것에 아무런 문제가 없습니다.

관리자로서 모든 사람이 "잘 정리되어 있는지"확인하는 것은 귀하의 일이 아닙니다. s ***가 완료되도록하는 것이 당신의 임무입니다. 그리고 당신은 그렇게하지 않습니다. 사실, 당신은하는 결정을하고 있어요 중지 끝내는에서 일을.

어떤 문제가 있더라도 극복해야합니다. 팀의 생산성이 떨어집니다.

이 사람에 대해 "뭔가를하겠다"는 결정에 대한 다른 답변에서 약간의 열을 받고 있지만, 나는 당신이 말하는 것을 완전히 얻습니다. 만약 다른 팀원들이 "이보다 더 평범한 작업을하기보다는 코딩을 선호 할 것"이라면, 모든 사람들이 원하는 작업 만함 으로써 빈약 한 의사 소통의 나쁜 성과를 보상하고 있다는 사실에 짜증이 날 것 입니다.

팀의 기술이 문제의 개발자와 비교할 수있는 "좋은 의사 소통 자"중 하나라고 상상해보십시오. 상사가 말을하기 때문에 통화를 처리하고, 키보드에서 마우스를 거의 아는 사람이 아닌 다른 비 IT 직원과 협력하고, 사용자 사인 오프 계획을 작성하는 등의 작업을 수행 할 수 있습니다. 그 동안 심술 쟁이 개발자는 "빈약 한 의사 소통 기술"을 가지고 있기 때문에 "재미있는"작업 만하는 사용자를 무시하고 하루 종일 큐브에 앉아있게됩니다.

지금 당신은 심술 쟁이는 "평균 이상의"기술을 가지고 있다고 말했지만, 그가 최고라고 말하지 않았습니다. 이것은 팀의 1/3, 심술 쟁이 기술 수준 이상인 훌륭한 의사 소통 개발자가 모두 화가 났음을 의미합니다.

최고의 성능을 발휘하는 직원 이 심술-은 개발자에게 짜증을 내기 때문에 생산성을 잃어 버릴 가치가 있습니까? 결정해야합니다.

당신이 그 사람을 해고하지 않는 한, 나는 당신이 다음 접근법 중 하나를 취하는 것이 좋습니다.

1) 더 나은 의사 소통자가되도록 멘토링하십시오. 이것이 가능한지 당신 만이 알 수 있습니다. 그의 손을 조금 더 잡고 있으면 도움이 될 것입니다. 어떤 사람들은 공식적인 비즈니스 상호 작용에 겁에 질려 그것을 요구할 때 화를 내면서 표현합니다.

2) 돈이나 다른 혜택으로 "좋은 의사 소통"을 장려하십시오 . 실제로 훌륭한 의사 소통가를 소중히 여기면 개발자들이 그렇게 성가신 일이 아니라고 보상해야하지만 그 보상은 실제적이고 의미가 있어야합니다. "지구 관리자와의 점심 식사"는 그것을 자르지 않을 것입니다. "스타 플레이어 / 쿠도 / 아타 보이"상도 종이 한 장이 아닙니다. 그것은 여분의 돈, 여분의 휴가, 약간의 융통성있는 시간, 급여 인상을 통제하는 고등학생들에게 진지한 인식이 있어야합니다.

우선, 팀원을 비난하는 것은 경영 능력이 약하다는 것을 나타냅니다 .

만약 그가 의사 소통 능력이 정말 좋지 않다면 , 그의 사회 생활에 대해 유감스럽게 생각하지만 실제로 직장에서 이것은 당신의 문제만큼 큰 문제는 아닙니다 . 그리고 현실을 직시하자. 그는 실제로 당신의 둔한 작업 환경, 또는 자신의 공연에 영향을 미치는 사적인 문제, 또는 비밀리에 당신을 모두 죽일 음모로 지루할 수 있습니다 .

의사 소통에는 최소한 두 가지가 필요하며 결국 사람들의 기술이 열악한 사람이 될 수 있습니다. 나머지 팀원들은 꽤 잘 지내고 있다는 사실을 잊지 마십시오. 모두 의사 소통 부족으로 인해 무의식적으로 보상하고 행복하게 무시할 수 있습니다.

어쨌든, 당신에게서 세 개의 책상에 앉아있는 사람들에 대해 인터넷에 묻지 말고, 챕터로 가서 실제로 문제가 있는지, 그 문제를 해결할 수 있는지 물어보십시오. (또는 최적화되거나 개선 될 수있는 둔한 것)

어쩌면 그는 책상 위치를 싫어하고 (화장실을 향하고 있습니까?) 이로 인해 기분이 나빠질 수 있습니다.

힌트 : 인적 자원이 아닌, 지각있는 인간 인 것처럼 대답을 들어보십시오.

(예 : 특정 관행 의 필요성 과 특정 결정 의 의미 를 자세히 설명 하려고 시도 하십시오. 일부 사람들은 배를 절벽으로 몰아 넣지 않는 선장이 있다는 느낌을 주므로 세부 사항을 파헤칩니다)

사람들이 다릅니다. 관리자는 팀을 최대한 활용하기 위해 사람들을 다르게 대우해야합니다 (그러나 공정하게!).

즉, 소프트 기술이 약한 개발자가 작업하는 것이 좋습니다. 개발자가 소프트 기술을 더 많이 사용하는 비 코딩 작업이 무엇을 좋아하는지 알고 싶습니다. 그들이 그 일에 참여하게하고, 이상적으로는 부드러운 기술을 부작용으로 향상시킬 것입니다.

사람들은 종종 일을 끝내기 위해 무언가 나쁘지 않습니다. 그들은 그것을 즐기지 않거나 적성을 갖기 때문에 나쁘다. 당신은 후자를 도울 수 없으므로 전자에서 일하십시오.

30/70 분할 은 모든 문제가 시작되는 곳일 수 있습니다. 나는 그런 분할에 만족하는 개발자를 본 적이 없다.

개발자가 10, 15 %의 다른 작업 에 익숙해 졌으며 ( 선량 이 적당 할 때 재미 있기 때문에 스스로 만족 했습니다) 30 %가 너무 큽니다. 차라리 다른 팀원들은 "30 % 다른 작업"을 싫어하는 사람보다 자신의 생각을 선호하지 않는다고 생각합니다.

또한 "생산성 수학"을보다 현실적인 수치로 조정하는 것이 중요하다고 생각합니다. "컨텍스트 스위치"에서 피할 수없는 손실로 인해 최대 100 %까지 추가되지 않습니다.

• ^{프로그래밍과 다른 작업 간에 전환 할 때 최대 100 %의 생산성을 합한 30 + 70 은 실제 생활에서는 절대 발생하지 않습니다. 약 20 + 50 또는 20 + 40 일 가능성이 큽니다. 컨텍스트 스위치는 소프트웨어 개발자에게 특히 고통 스럽습니다. 관심이 있으시면이 기사에서 그 이유에 대한 훌륭한 설명을 확인하십시오 . 프로그래머를 깨우지 마십시오!
  생산성을 높이 평가하는 프로그래머는 자연스럽게 그러한 손실에 대해 불만을 나타냅니다.}

작업의 일부로 테스트 를 실행 하는 경우 테스터에게 전달하는 것을 고려 했습니까? 프로그래머가 사실 수 있습니다 그것을 (나는 어떤 경험이 풍부한 프로그래머가 할 수 있어야한다 생각)가 의미하는 것은 아니다 해야한다 . 테스터도이를 수행 할 수 있으며 더 잘 수행 할 수 있으며 "컨텍스트 스위치"에서 생산성 손실이 발생하지 않습니다.

QA 리소스를 어떻게 활용하는지 궁금해하는 또 다른 요점은 지원 / 조사에 대한 언급입니다 . 내가 일했던 전문 테스터는 그런 것들에 "선생님"이있는 경향이있다.

• ^{전 테스터로서, 나는 그것들을 꽤 잘 알고 있습니다. 생산 문제는 테스팅 범위에 대해 배울 수있는 귀중한 데이터 소스 (테스터로서)였습니다 ( "이 문제는 내 테스트에서 올바르게 다루었습니까?"). 결함 우선 순위 지정 ( "테스트에서 다루었 고 릴리스 전에보고되었지만 적절한 우선 순위 / 심각도를 다시 설정 했습니까?").}

좋은 테스터가 지원 문제 조사를 개발자에게 언제 전달해야하는지 쉽게 알 수 있으며, 자주 발생하지는 않습니다. 이로 인해 개발자에게 과부하가 걸리는 이유는 단순히 내 마음에서 벗어날 수 있습니다. 내가 이미 썼 듯이, 그들은 그렇게 할 수 있습니다 (일반적으로 선임 개발자가 QA 가하는 일을하는 방법을 알기를 기대 합니다) .

이것에 대해 할 말이 2 가지 있습니다

1. 코더 나 소프트웨어 개발자 를 모집 했습니까 ?
   소프트웨어 개발자를 고려할 때 언급 한 모든 사항은 소프트웨어 개발의 일부이며 소포입니다. 특정 작업을 위해 모집하지 않은 이상 이러한 사항을 무시할 수 없습니다. 총 소프트웨어 개발의 IMO 50 %는 나머지는 디자인, 분석, 테스트, 문서 등입니다.

2. 아무도 완벽하게 태어나지 않았습니다.
   모든 것에 능숙한 사람을 찾을 수는 없습니다. 당신은 그들이 투쟁하게하고 사물을 배워야합니다.

관리자로서 당신은 그들 중 최고를 얻어야 만한다는 것에 동의하지만 장기적인 운영에서는 문제에 직면 할 수 있습니다. 그들에게 내가 이것에 좋지 않다는 느낌을 가져라 . 무엇보다도 팀에서 가장 효율적인 결과를 얻을 수 있도록 모든 사람을 동등하게 대우합니다.

직원의 모든 직원이 직책 / 직무 설명이 동일하고 직무 설명에 나열된 모든 내용이 포함 된 경우이 프로그래머는 다른 비 프로그래머 작업을 더 할당하여 이러한 다른 기술을 연마해야합니다. 마찬가지로 다른 직원이 프로그래밍 이외의 작업을 계속해야하는 경우 (사용하거나 잃는 경우) 프로그래밍 기술이 향상되지 않습니다.

그러나 나는 여전히 당신의 주된 우선 순위가 마감일을 충족해야한다고 생각합니다.

편집 : 소규모 팀이 있다면 모든 회원이 여러 모자를 착용 할 수 있도록하는 것이 좋습니다. 충분히 큰 팀이 있다면 다른 영역을 전문으로하는 그룹을 갖는 것이 좋습니다. 게시물에서 전문가 그룹을 보유 할만큼 큰 팀이없는 것처럼 보입니다.

이 게시물의 의사 소통 기술에 대해 정확히 부족한 점이 원래 게시물에서 명확하지 않습니다. 회의에 참석하거나 계획 / 조정 유형의 업무 (예를 들어)에 관심이 없다고해서 의사 소통 기술이 제대로 표시되지는 않습니다. 어쩌면 개발자는 단순히 이러한 유형의 작업이 관리자 작업이라고 생각하고 개발자로서의 생산성을 떨어 뜨릴 수 있습니까? 아니면 조직적인 오버 헤드가 너무 많다고 생각하고 이것이 전체적으로 낭비되는 시간에 대한 항의의 형태일까요? 결국, 사람들이 하루 종일 말을하고 아무것도하지 않는 반대의 문제는 사무실에서도 매우 흔합니다.

대립하지 않는 방식으로이 개발자와 대화 하고 비 프로그래밍 작업을 피하는 이유 를 알아 내려는 것이 중요 합니다. 아마도 하나의 이유가 아니며 다른 유형의 작업이 있기 때문에 다른 이유가있을 수 있습니다. 대화의 목적이 모든 팀 구성원의 팀 생산성 및 작업 만족도를 효과적으로 향상시키는 방법을 배울 수 있도록 대화의 목적을 이해하도록하십시오. 지금은 니가 경련 반응에 대한 그의 우려를 말하거나 주장하려고하지 말아야 할 때이다. 아마도 다른 팀원들과 만나야 할 수도 있습니다. 아마도이 사람이 직업의 채팅 계층에 집중하면서 무거운 개발 작업을 수행하게하는 것이 좋습니다.

이 모임 후에는 대화에 대해 생각하고 열린 마음으로이 직원의 관점을 고려하십시오. 아마도 당신의 초기 감정이 맞았고, 당신이 그를 발전시켜야 할 중요한 기술이 부족할 것입니다. 아니면 당신의 가정에 대해 몇 가지 유효한 도전을했을 수도 있습니다. 다른 팀과 협력하여 일부 프로세스를 공식화하고 중복 통신의 필요성을 줄일 수 있습니다. 다른 팀이 몸무게를 늘리지 않을 수도 있으므로 관리 팀과 친근한 대화를 해야 합니다. 고려하지 않은 많은 가능성이 있습니다.

마지막으로, 가장 중요한 것은 개인과의 후속 대화 또는 적절한 경우 팀 회의를 갖는 것입니다. 영향력을 행사할 수있는 실제 조직 문제를 파악한 경우 직원에게 업무 상황 개선을 위해 취해야 할 조치에 대해 알리십시오. 여전히 개별 직원이 잘못되었다고 생각되면 그와 함께 앉아서 그에게 필요한 변화와 이유를 설명하십시오. 개발자는 논리적 / 실제적인 설명에 잘 반응하는 경향이 있습니다. "동료들에게 모든 재미있는 일을 제공하는 것은 공평하지 않습니다. 우리는 여러분 모두가 순수한 개발자가 되길 원하지만 상황의 현실이 아니기 때문에 우리는 엉터리 일의 부담을 분담해야합니다."

물론,이 사람이 심술 je은 바보 인 경우, 왜 불행한지, 왜 이성에 응답하지 않을 것인지, 동료들로부터 잘 존중받지 못하는 이유를 말하기를 거부합니다.

팀을 관리하려고 노력하고 있으며 모든 사람들에게 동기를 부여하고 싶을지라도 (공정함을 느끼는 데 도움이 됨) 최고의 프로그래머 프로그래밍을하지 않음으로써 프로젝트를 희생하고 있습니까? 내 말은, 요점은 그렇지 않습니다.

최고의 개발자를 충분히 활용하지 못하거나 잃을 위험이 있습니까? 당신의 임무는 모든 사람에게서 이러한 유형의 의무를 시도하고 완화하는 것입니다.

똑같이 대우받는다고해서 모두를 동일하게 대우한다는 의미는 아닙니다. 다른 사람들이 더 많은 프로그래밍 작업을 할당하기 위해 비 프로그래밍 의무를 풀기를 원한다면 둘 다 잘 될 위험이 있습니까?

편집 : 개인적인 감정 외에는 문제를 식별하지 못했습니다. 어떤 시점에서 의사 소통의 부족은 프로그래머를 방해합니다. 다른 사람들은 원한을 나타내며 그들의 일에 어려움을 겪을 수 있습니다. 지금까지 문제가있는 유일한 사람인 것 같습니다. 공유하고 있지 않은 것이 없다면?

편집 2 결국에는 모든 사람이 특별한 호의를 구할 것입니다. 이 사람은 의사 소통이 적고 코딩이 더 많습니다 (모든 계정에서해야합니다). 다른 사람이 나중에 조금 오기를 원합니다. 다른 사람은 마감 시한을 지키기 위해 회의를 건너 뛸 필요가 있습니다. 그래픽 사용자가 더 큰 모니터를 얻습니다. 점수를 유지하는 것을 너무 강조하면 중요한 것을 잊어 버립니다.

나는 스크립팅을 많이하는 심술 많은 리눅스 관리자이며, 의사 소통 능력이 좋지 않다는 것을 알게되었다. 나는 당신의 남자처럼 많이 들린다. 사실, 이것이 성능 검토에서 얻은 유일한 영역입니다. 다른 한편으로, 나는 지속적으로 팀을 혁신과 문제 해결에서 이끌고 있으며, 우리가 롤아웃하고 팀을 많은 시간과 회사를 구할 수있는 새로운 플랫폼으로 만들고 이끌었습니다. 나 자신으로 허용함으로써 많은 돈.

저의 전 상사는 가족 / 아내와 회사의 고위 경영진에게 직책을 맡기라는 요청을 받았습니다. .... 그는 책임을 공정하게 균형을 맞추기 위해 지칠 줄 모르고 일했고 많은 짐을졌다. 부서 외부의 모든 사람들과 교류 할 때, 그에게 되돌아온 의사 소통 오해가 있었을 때, 그는이를 처벌 적으로 수정했습니다. 그는 "상향 관리"에 열악했기 때문에 우리 팀은 긴급 상황이 될 때까지 자원을 확보 한 마지막 팀이었으며, 그 도구를 사용하는 팀과상의하지 않고 테스트되지 않은 하드웨어에 대해 판매 대행사에게 판매 대금을 초과 지급했습니다. "잘 균형 잡힌"팀을 만들기 위해 작업 목록을 미세 관리하고 작업 균형을 조정하여 팀원이 좋지 않은 영역에서 기술을 향상시킬 수 있도록했습니다. 많은 코드가 깨지거나 구현이 잘못되었습니다. 저자 이외의 사람들에게는 깨진 코드에 대한 지원 작업이 구체적으로 할당되어 있지만 "학습"할 수 있도록 제대로 설계되지 않은 구현, 코드 및 테스트는 팀 구성원들과 실제로는 많은 선의를 만들었습니다.독성 팀 상태로의 빠른 경로 인 "비난 게임"의 발생이 증가했습니다 .

저의 현재 상사는 주니어 관리자 역할에서 들어 와서 자신의 길을 개척 한 조용하고 수집 된 개인입니다. 그는 올바른 결정을 내리고 팀원들에게 자신의 우선 순위를 설정하는 데 크게 의존합니다. 그는 훌륭한 의사 소통 자이며 팀원이 표현한 의사 소통 문제, 아이디어 또는 요구에 대해 조용히 그리고 감독자와 함께 반응합니다. 그는 지칠 줄 모르게 "위쪽으로"일합니다. 그는 주요한 아키텍처 변경을 느리게 수행하고 환경을 변경하기 전에 전체 팀과 철저하게 상담하며 팀원의 전문 지식에 의존하는 것이 편합니다.

새로운 관리자에 따르면 다운 타임이 거의 0으로 감소했습니다 (또한 지원 업무에 소요되는 시간의 비율이 약 40 %에서 약 10 %로 감소했습니다). 팀의 만족도는 지붕을 넘어갔습니다. '3 년에서 5 년마다 새로운 하드웨어로 은행을 개척'에서 5 년 동안 매년 약 백만 백만 달러를 절약해야하는 지속적인 인수 계획으로 이동했습니다. 이 계획은 이전 관리자에게는 결코 일어나지 않았지만 새로운 관리자에 의해 고위 경영진에게 적극적으로 밀려 났으며 팀의 기술 세트에서 많은 시너지 효과를 찾는 데 의존 한 풀뿌리 프로그램이었습니다. 우리는 CIO로부터 비공식적으로 우리가 현재 "함께 똥을 가지고있는"유일한 팀이고 그가 우리는 가능한 한 적은 업무 환경을 방해하고 가능한 한 문제 영역에 대해 많은 자원을 섞습니다. 이것은 사실이었으며 다른 팀의 작업 부하를 방해했지만 지원 비용을 더욱 낮추고 있지만 팀의 지원 비용도 낮추었습니다.

개발자들이 자신의 기술을 향상시킬 수있는 곳은 학교 나 시간에 있습니다. 그들이 물건을 생산하는 장소는 회사의 시간입니다. 물건을 생산하는 가장 좋은 방법은 가장 잘 아는 것을 생산하는 것입니다. 한 개발자가 편하지 않은 영역에서 작업 할 때는 전문화되고 팀으로 일하는 두 번째 개발자를 끌어들이거나 전문 개발자가 코드를 작성하고 문서 및 다이어그램을 작성해야합니다. 코드를 작성한 사람들에게 지원 작업을 전달하십시오. 그렇기 때문에, "버스 팩터"라고하는 것이 증가합니다. 전문가가 버스에 맞아야 부서가 속도 충돌을 일으킬 가능성이 있습니다. (또는 해고 또는 직업 전환, 또는 ...) 진실은 "버스 이벤트"에서 그 두려움으로 인한 생산성 손실이 실제 손실보다 몇 배나 높다는 것입니다. 발생합니다. "버스 행사"에서 일반적으로 발생하는 일은 전문가의 작업 상속자가 자신의 이미지로이를 재구성하여 가장 효과적으로 지원할 수있게함으로써 일반적으로 많은 문제를 해결하고 지원에 소요되는 시간을 더욱 단축 시키며 인생은 계속된다는 것입니다. 의 위에.

최선을 다할 수있는 사람들에게 일을 할당하십시오. 학생들이 자신의 작업을 지원하고 문서화하도록하십시오. 창의력을 키우고 방해 나 소액 관리없이 집중할 수 있습니다. 불행히도 회사가 수영하는 것처럼 들리는 관리 학교 BS는 그 밖의 모든 것입니다. 그렇다고 팀이 수영을해야한다는 의미는 아닙니다.

회사의 관점에서 보면 훌륭한 관리자는 회사의 가치를 높이는 동시에 그 가치에 따라 업무를 수행합니다. IT 직원의 관점에서, 우수한 관리자는 팀이 가능한 한 신속하고 깨끗하게 할 수있는 일을하도록하고 주말 경영진이 주말 MBA 수업에서 배운 가치를 밑줄로 내리는 것을 막는 대변인에 대한 배설물 역할을합니다. 당신은 회사 사람이고, 그것은 당신의 팀에게 최선이 아닐 수도 있습니다. "좋은"의사 소통 기술을 가진 사람들은 말하기에는 너무 예의입니다.

• 직원이 자신의 직업 설명에 의사 소통 기술이 얼마나 중요한지 알고 있어야합니다. 그와 함께 개선을 위해 노력하십시오.
• 그러한 작업에서 다른 팀원들만큼 훌륭하다고 주장하지 마십시오.
• 당신이 믿는 원칙에 따라 과제를 배정하십시오. 업무에 효율적인 업무 배정과 공정성 / 재미 사이의 균형을 찾으십시오.

이것들은 요약 아이디어 일뿐입니다. 누군가 가이 요점을 훔치고 다른 대답 중 하나로 접을 수 있기를 바랍니다. ;-)

성능이 전부입니다. 프로그래밍 작업을 그에게주세요. 나머지 부서와이 문제에 대해상의하십시오. 선택적으로 누군가가 공동 작업을 수행하도록하거나 다른 사람을 공동 작업 만 수행하도록합니다. 재미있는 프로그래밍을 생각하지 마십시오. 모든 것이 POV의 "재미"입니다.

그렇지 않으면 관리하기가 매우 어렵고 효과가 떨어질 수있는 상황을 만들 수 있습니다.

훌륭한 질문은 모든 팀장, 감독자, 기술자 관리자가 고려해야 할 종류입니다. 나는 당신의 접근 방식을 좋아합니다. 모든 사람들은 '재미있는'작업을해야합니다. 촬영이 더 픽업 다른 작업을 할 수있는 크로스 훈련 혼란을 일으키는에서 PETERBILT 원리를 방지하는 팀이 가진 'indesipensible 팀 구성원도 팀을 떠나거나 테이크 말하다 휴가'.

이제 많은 게시물에서 지적했듯이 작업은 공평하지 않으며 그렇게해서는 안됩니다. 관리자는 얼마나 가치있는 작업이 수행되는지 측정됩니다.

• 관리자는 기술을 기반으로 작업을 개인과 일치시킵니다.
• 훌륭한 관리자는 팀의 기술, 성장, 관심 및 건물 생산성을 기준으로 작업을 일치시킵니다.
• 훌륭한 관리자는 약간의 도움과지도로 팀이이 작업을 수행하도록합니다. 즉, 관리자가 하루 종일 지출하지 않습니다.

좋은 프로그래머에게 이야기하고 배우고 싶은 것이 있는지 물어보십시오. 그가 할 수있는 다른 일들 ... 다른 팀원들에게 프로그래밍을 도와 줄 수 있습니까? 예, 의사 소통에 문제가 있다는 것을 알고 있습니다.

이것을 포장하는 또 다른 방법은 작업 목록을 가지고 각 직원이 무언가를 선택할 수 있도록하는 것입니다. 좋은 프로그래머가 먼저 선택하도록하십시오. 미리 경고하고 작업 목록을 더 잘 보여 주면.

거의 항상 변화로 저항하는 저항력을 얻는다면 그에게 가치있는 판매 포인트를 찾으십시오. 마지막으로 팀을 위해 그렇게 할 수 있습니다.

또한 실수를 시작하고 생산성을 낮추는 것은 사람들이 배우고있는 신호입니다. 이 프로젝트는 어려움을 겪을 수 있지만 다음 프로젝트가 더 나을 것입니다.

마지막으로, 일이 잘 이루어 지도록하는 것이 당신의 일이지만, 직원의 수가 늘어나고 프로세스에 더 잘 참여할 수 있다면 말입니다. 어떤 사람들은 일을 끝내는 가장 좋은 방법은해야 할 일을 알고 결과를 소유하는 팀이라고 말합니다.

편집 : 아, 계속 노력하십시오. 위의 조언은 수년간의 실수를 저지른 것에서 비롯되었지만 항상 팀의 성장을 돕고 싶었고 생산성이 왕이라는 것을 알고 있었으므로 마지막 시도가 실패했을 때 새로운 것을 계속 시도했습니다.

가장 좋은 답변은 이미 받아 들여졌지만 "작업 배정"만이 관리자와 함께 할 수있는 유일한 것은 아니라는 사실에 아무도 놀랐습니다. "평균 이상의 커뮤니케이션 기술"을 갖고있는 "평균 이상의 프로그래머"를 갖는 것은 유사한 프로그래밍 기술과 약한 의사 소통 기술을 가진 사람보다 (다른 모든 것이 평등 한) 고임금 / 고급 개발자 여야합니다. 이것은 팀으로부터인지 된 "선호"를 상쇄하는 데 도움이 될 수 있습니다. (일부 조직에서는 수행중인 작업 유형으로 인해 "요구 사항 분석"에서 평균 이상의 기술과 다른 영역에서 평균 이하의 기술을 갖는 것이 회사에 훨씬 더 가치가있을 수 있습니다. 관리자는이를 처리하는 방법을 결정해야합니다. .)

주의해야 할 또 다른 사항 : 문제가있는 사람에게 프로그래밍 작업 외에 아무것도 제공하지 않으면 격리가 장기적으로 이루어질 것입니다. 다른 작업을 계속 제공해야합니다 (그러나 잘 수행 할 수있는 작업, 부정적인 피드백을 위해 설정하지 마십시오 !!). 다른 부서 / 팀에게 공개되고 공개됩니다.

그들이 보는 경우에 마지막으로 ... 다른 팀 구성원으로 확인 어떤 주기적으로 팀 과제에서 불평등. 이것은 당신에게 큰 관심사가 될 수 있지만, 다른 모든 사람들의 목록에서 # 15입니다.

자신의 평가에 의해이 한 명의 프로그래머가 팀에서 최고이기 때문에, 그 사람에게 원하는 직업을 제공하는 것이 "공정한"방법으로 (최고의 성과를 거둔 결과). 결국,이 회사에서 일하기를 원했지만 전혀 고용되지 않은 사람들이 있었을 것입니다. 그러나 아무도이 코딩을하지 않는다고 "공평하지 않다"고 말하지는 않을 것입니다.

더 많은 코딩을 원하는 팀의 다른 숙련 된 팀원에게 공정한 접근 방식을 사용하는 것이 좋을 것이라고 생각합니다. x와 y 기술을 습득했다는 것을 보여줄 수 있다면 다음에 나오는 일입니다. "

응답 한 다른 사람들과 마찬가지로 저는 여러분의 입장을 이해하며 비슷한 야망을 가질 것입니다.

이를 수행하는 데 가장 적합한 사람들에게 작업을 제공하는 것이 합리적이라고 말할 수 있지만, 역동적이고 유연한 팀을 제공하기 위해 사람들의 기술을 넓히는 것도 의미가 있습니다.

이 사람이 자신의 역할에서 비 코딩 요소를 수행해야하지만 의사 소통 기술이 실제로 필요한 것보다 열악한 경우 개선해야합니다. 어떤 종류의 개발 검토 / 평가 시스템이 있다고 가정하면이 시점에서 문제가 제기됩니다.

핵심 문제는 당신이 그에게 필요한 것을 명확하게 설명하고, 그가 준수 할 능력이 있는지 평가하고,이를 가능하게하는 훈련 계획을 세우는 것입니다. 교육이 반드시 공식적인 것은 아니지만 필요한 기술을 습득하도록 도와 주어야합니다.

그가 단순히 귀찮게 할 수 없다면 궁극적으로 징계 문제가 될 것입니다. 그가 당신에게 시도하고지지 해 왔음에도 불구하고 능력이 없다면, 징계 조치가있을 수 있습니다 (내가 거칠고 반 생산적이라고 주장 할 것입니다). 특정 작업을 위해 잘라냅니다.

그 남자와 이야기하는 것은 당신의 첫 번째 전화 포트 중 하나가 될 것입니다 . 그는 자신감이나 통찰력이 부족하다는 것을 알 수 있습니다. 당신은 또한 그가 매우 반응 적이며 자신을 향상시킬 수있는 기회에 감사 할 것임을 알 수 있습니다.

모든 그런 작업을하려면 주니어를 고용해야하며, 도움을 요청하는 모든 것을 도와 주어야한다는 사실을 모든 사람에게 알려야합니다.

그들은 능력으로 인해 "평균 이상"코더를 귀찮게하고 다른 팀은 새로운 부족을 얻습니다. 후배는 처음부터 배우고 결국 회사는 끝이 둥글다.

모든 사람이 동일한 의사 소통 기술을 갖기를 기대하는 것은 절름발이 남자에게 다른 팀만큼 빨리 달리도록 가르치는 것을 기대하는 것만 큼 합리적입니다.

사람들은 다르고 기술과 약점이 다릅니다. 의사 소통 기술에서 다른 사람을 따라 잡을 수 없기 때문에 훌륭한 프로그래머를 해고하는 것은 다른 사람만큼 빨리 걸을 수 없기 때문에 불구가 된 사람을 해고하는 것과 같습니다. 윤리적 관점에서 불공평 할 수 있으며 귀하의 경제적 이익에 위배 될 수 있습니다.

과거에 그렇게하지 않았다면 처음에는 아스퍼거 증후군 에 대해 읽어보십시오 . 불쌍한 사회적 기술은 해당 증후군의 주요 지표입니다.

둘째, 원하는 사람을 고용하고 해고 할 수 있지만 직원의 강점과 약점에 대처하지 못하면 가장 좋은 프로그래머가 떠날 것이므로 많은 프로그래머가 생길 수 있습니다. .

아담 (Adam )이라는 영화가있다.이 영화 에는 예상치 못한 무언가를 썼기 때문이다. 그의 아이디어는 고용주에게 많은 돈을 가져다 줄 수 있었지만, 그의 "원칙"에 집중했기 때문에 그 기회를 이용할 수 없었습니다.