팀을 통해 능력을 어떻게 배분해야합니까?

이것을 읽은 후, 나는 능력이 다양한 개발자 그룹 (일명 거의 모든 팀) 내에서 민첩한 팀을 구성하는 방법에 대해 많은 의견 차이가 있음을 알았습니다. 모든 최고의 개발자가 자신의 팀을 구성하고 가장 우선 순위가 높은 작업을 수행해야합니까? 이를 통해 가장 중요한 작업이 완료됩니다. 동시에, 우선 순위가 낮은 업무 일지라도 기술 부채를 쌓는 "완벽하지 않은"팀이 남아 있습니다. 반면에 균등하게 분산 된 팀은 후발 개발자에게 조금 더 나은 이점을 제공 할 수 있지만 가장 많은 타자들에게 동기를 부여 할 수 있습니다. 또한 많은 훌륭한 디자인 패턴과 끔찍한 안티 패턴을 혼합하면 안티 패턴이 될 수도 있습니다.

A-Teams에는 알려진 위험이 있지만, 역학이 옳다면 제 생각에 가장 강한 프로젝트를 가장 중요한 프로젝트에 참여시킬 것입니다. 우선 순위가 낮은 프로젝트의 경우 가능한 한 멀리 떨어져있는 것을 막으려면 훌륭한 팀 리더가 필요합니다. 기술 부채는 무엇이든 일어날 것입니다. 모든 기술 부채가 같은 것은 아닙니다. 기술 부채의 비용 / 부채는 처음에 프로젝트의 비즈니스 가치에 비례하므로 우선 순위가 낮은 프로젝트는 사마귀가 많을 수 있지만 프로젝트 비용은 우선 순위가 높은 프로젝트의 중요한 문제보다 훨씬 적을 수 있습니다 있다.

교수님 중 한 명이 팀 구조에 대한 일화를 말해 주었을 때를 기억합니다 (지금 그가 이야기 한 논문을 보았지만 찾을 수없는 것 같습니다).

기본적으로 이야기는 다음과 같습니다.

프로그래머 그룹은 능력에 따라 그룹으로 나뉘어졌다. 최악의 x 프로그래머는 함께 그룹화되고, 다음 x는 함께 그룹화되고, 가장 좋은 것은 그룹화되었다.

그들은 모두 같은 작업을 배정 받았으며,이를 완수하기 위해 정해진 일정을 정했습니다.

기간이 끝날 무렵 주최측은 작업에 대한 솔루션을 살펴 보았고 놀랍게도 최고의 성과를내는 팀이 평균 인원으로 구성된 팀에서 나온 것을 발견했습니다. 대조적으로, A * 프로그래머로 구성된 팀은 최고의 솔루션이 무엇인지에 대해 논쟁하면서 모든 시간을 소비했기 때문에 최악의 솔루션 중 하나를 만들었 습니다 .

일을 끝내려는 팀이 필요하다면 평균적인 사람들과 리드 할 수있는 지배적 인 사람을 얻으십시오. 연구의 결론 (정확히 기억한다면), 그렇지 않으면 더 많은 지배적 인 사람들이 얻는 것보다 싸우는 데 더 많은 시간을 할애합니다 일이 끝났습니다!

경험이없는 개발자의 대다수는 강력하고 우아한 디자인을 스스로 만들지 못할 수도 있지만 디자인을 볼 때이를 인식하고 이해할 수 있습니다. 그들이 할 수 없다면, 그들은 일반적으로 적성 또는 처음부터 고용 준비가 부족합니다.

또한 매우 복잡한 소프트웨어 설계를 이해할 수는 있지만 경험이 부족한 개발자가있을 때 더 간단한 것이 더 좋은시기를 알 수있는 재량이 없습니다.

내 경험상, 당신은 준비되지 않은 멤버, 불필요하게 복잡한 멤버 또는 둘 다를 포함하는 혼합 팀에 영구적 인 문제가 있습니다. 그렇지 않으면 팀에 문제가있는 경우 일반적으로 의사 소통을 개선하거나 적절한 역할을 할당하여 문제를 해결할 수 있습니다.

최고의 인력을 단일 팀으로 그룹화하면 훌륭한 단기 솔루션처럼 보일 수 있지만 장기적으로 실패하고 추가 비용이 발생합니다. 예를 들어, 회사는 사람들이 훈련 비용을 지불하는 대신 숙련 된 동료로부터 배우는 것을 선호합니다. 최고의 인재를 분리하면 저 숙련 된 인재에게 지식을 이전 할 수 없습니다. 단기적으로는 최고의 팀이 잘 수행 할 수 있지만 지식 이전이 부족하여 숙련 된 직원의 수가 증가하지 않습니다. 처음에는 성과가 낮은 팀을 보유하고 사람들이 숙련 될수록 모든 팀의 성과를 높이는 것이 훨씬 좋습니다.

또한 숙련 된 사람들이 떠나기로 결정하면 어떻게됩니까? 누가 그들의 프로젝트를합니까?

또 다른 요점은 팀이 다른 기술을 가진 사람들로 구성되어야한다는 것입니다. 가장 고위 개발자가 수행하기에는 너무 비싸고 쉬운 작업 (그리고 지루한 작업)이 항상 있습니다.

가르 칠 수없는 사람들은 ...

고려해야 할 더 많은 요소가 있다고 생각합니다.

당신은 팀 리더로 가르 칠 수있는 것들을 배포함으로써 가장 가치를 얻게 될 것입니다. 그들은 팀의 다른 구성원을 가르 칠 수 있으며 업무의 질을 높이는 데 도움을 줄 수 있습니다.

모든 선임 프로그래머가 좋은 리드를하는 것은 아닙니다. 정보를 전달하는 능력은 그 자체로 기술입니다. 이 기술은 프로그래밍 경험을 통해 개발 된 것이 아닙니다. 그것은 가르침과 설명을 통해 발전합니다.

'A'팀을 지정하는 데는 두 가지 중요한 문제가 있습니다. 첫 번째는 호환성입니다. 잘 어울리는 팀이 "능력"보다 훨씬 중요합니다. 이제 이것은 두 명의 "높은"기술 프로그래머, 두 명의 "낮은"기술 프로그래머 또는 혼합 일 수 있습니다. 그들이 함께 일할 수 있다는 사실은 그들이 더 생산적이라는 것을 의미합니다.

두 번째 문제는 성장에 관한 것입니다. 두 명의 "낮은"기술 프로그래머는 나쁜 습관 외에 서로에게서 많은 것을 배우지 못할 것입니다. 마찬가지로 두 명의 "높은"숙련 된 프로그래머는 서로 많은 것을 배우지 않을 것입니다. 그러나 "낮음"과 "높음"기술 수준을 혼합하면 "낮음"기술의 능력을 향상시키는 데 도움이되고, "높음"기술의 능력을 향상시킬 수 있습니다. 나는 당신이 다른 누군가에게 그것을 가르 칠 수있을 때까지 "숙련 된"기술로 간주되지 않습니다.

코인의 반대편에서 서로 "지속"할 수있는 팀을 유지하는 것이 합리적이라고 생각합니다. A-Team 타입 프로그래머는 B-Team 타입이 비트를 끝내기를 기다리지 않습니다. B- 팀 유형은 A- 팀 스타일 워크 플로에 의해 결정될 수 있습니다.