개발팀을 구성하는 방법

저는 회사 웹 사이트 / 웹 응용 프로그램을 관리하는 11 명의 소프트웨어 개발자 팀의 관리자로서 언제든지 최대 4 개의 동시 프로젝트와 일상적인 지원을 실행합니다. 11 명의 개발자들에게는 기술적 기술, 직책 및 경험이 혼합되어 있지만 팀 구조는 단순하지만 11 명의 개발자 모두 저에게 직접보고합니다.

관리자 한 명을 둔 전체 팀은 확장 성이 떨어지기 시작했습니다. 너무 얇게 퍼지기 시작하여 직접 보고서 수를 줄이고 싶습니다. 내가 이것을 생각할 수있는 모든 방법에는 중대한 단점이 있습니다.

• 후배 개발자에게 상급자에게보고하도록합니다. 이를 통해 최고의 기술자가 개발에 소비하는 시간이 줄어 듭니다.
• 소프트웨어 제품으로 팀을 나눕니다 (예 : 인트라넷 개발자 1-6 명과 외부 사이트 작업 7-11 명). 각 섹션에는 새로운 팀장이 있습니다 (현재 선임 개발자보다 더 많은 관리 / 멘토링 / 코칭 책임이있는 새로운 직무 설명) ). 인공 사일로가 추가되어 원하는 경우 "인트라넷 개발자"가 외부 웹 사이트에서 작동하지 못하게 할 수 있습니다.
• 압력을 줄이기 위해 구조를 평평하게 유지하고 프로젝트 관리자 / 팀 관리자의 형태로 관리 지원을 추가하십시오. 팀이 이처럼 영원히 성장할 수 없기 때문에 이것은 문제를 해결하지 못합니다.

내가 누락 된이 문제를 해결하는 표준 방법이 있습니까?

그렇지 않다면 다른 사람들이 어떻게이 문제를 해결 했습니까?

몇 가지 빠른 생각 :

• 하위 팀은 좋은 아이디어입니다. 구조가없는 11 개의 직접 보고서는 실행 가능한 팀에 비해 너무 큽니다 (직접 코칭을 할 시간이 충분하지 않으며 많은 사람들과 팀 회의를하면 비생산적인 경향이 있습니다).
• 운영과 개발을 분리하는 것을 고려하십시오. 기술이 약간 다르며 하루 종일 운영 문제로 인해 중단되면 프로젝트의 개발 생산성에 심각한 영향을 줄 수 있습니다.
• 처음 두 지점의 결과로 인트라넷, 외부 사이트 및 운영이라는 세 개의 하위 팀이 있어야한다고 생각합니다. 운영 담당자는 모든 일상적인 문제 / 유지 보수 수정 등을 처리하는 반면 두 개발 팀은 비즈니스에 새로운 프로젝트 / 가치를 제공하는 데 중점을 둡니다.
• 정기적으로 팀간에 사람들을 순환 시키십시오. 이것은 때때로 프로젝트에 대해 (예 : 사람들이 다른 하위 팀에서 코드를 검토하도록) 또는 영구적으로 수행 될 수 있습니다. 그러나 비즈니스 요구가있을 때마다 팀 역할이 변경 될 수 있음을 이해해야합니다. 특정 역할을 영원히 "소유"하는 사람은 없습니다.
• 더 많은 관리자 / 관리자를 추가하지 마십시오. 이는 팀의 전반적인 효과 / 생산성을 줄이는 확실한 방법입니다. 각 서브 팀에서 가장 경험이 많은 사람이 팀장 / 코치 역할을하도록하십시오. 그들이 팀 전체를 코칭하고 성공시키는 역할을하는지 확인하고 "작업 관리자"가 아닌 이러한 방식으로 행동 할 수 있도록 준비하십시오.
• 귀하의 역할은 외부 이해 관계자 관리, 그룹 내 자원 / 작업의 우선 순위 지정 및 "주임 코치"역할에 중점을 두어야합니다. 하위 팀에서 이따금 씩 제기되는 문제를 처리해야하지만 일반적으로 문제가 발생하지 않도록 스스로 문제를 해결하도록 권장해야합니다.
• 고도로 기술적 인 전문가라면 건축가 / 디자인 보증 역할을 수행 할 수도 있습니다. 그렇지 않은 경우 팀 내 또는 다른 곳에서 할 수있는 사람을 찾으십시오 .....

또한 항상 애자일 선언문 , 특히 12 가지 원칙을 읽고 읽을 가치가 있습니다.

그 구조는 주로 depend on project specifications

팀의 선임 개발자 당 3 명의 주니어가있는 것이 이상적입니다. 결과적으로 교직원 당 2-3 명의 선임 개발자가 있습니다.

따라서 프로젝트 진행 상태에 대해서는 기술 책임자 만 PM에보고합니다. 설명 된 구조는 여전히 기술적이지 않은 문제 (휴가, 시간 초과, 충돌 등)에 대해 누구나 PM에 액세스 할 수 있다고 가정합니다.

상대적으로 성공적인 소프트웨어 개발 팀 중 하나는 프로젝트별로 다음과 같이 진행되었습니다.

모든 사람이 직접보고 한 소프트웨어 개발 관리자 / 수석 개발자 / 멘토.

• 일정을 유지하고 요구 사항 및 수락 협상을 촉진하고 커뮤니케이션을 수행 한 프로젝트 관리자 모두 점선으로이 사람에게보고했습니다. 문서 담당자 (종종 PM이기도하지만 전문 지식이 허용 된 경우에만 해당)
• 프로젝트 요구에 따라 1-3 명의 개발자 또는 상급 개발자가 혼합되어 있습니다.
• 가능한 경우 주니어 개발자.
• QA 풀에서 할당 된 사람입니다.
• 인프라 스트럭처 직원

완벽하게 작동했으며 그 조직을 좋아했습니다. 반면에 저는 소프트웨어 개발 관리자였으며 팀의 조직 구조는 발전하고있었습니다.

기능 직원 구성 패턴을 따르는 것을 고려하십시오 . 이것은 소프트웨어 제품별로 팀을 분할하는 두 번째 옵션에 대해 이야기합니다.

컨텍스트에서 기사를 인용하려면 다음을 수행하십시오.

기능적 조직의 가장 큰 장점은 사회적 구조를 비즈니스 가치 제공에 연결한다는 것입니다. 내 관점에서 소프트웨어 프로젝트는 그들이 지원하는 활동의 효율성을 향상시키는만큼 성공하여 비즈니스 가치를 창출합니다. 동일한 방식으로 팀을 구성함으로써 비즈니스 사용자 만족을위한 팀을 구성 할 수 있습니다.

실제 관리 / HR 구조는 그 이상과 관련이 없습니다.

내가 누락 된이 문제를 해결하는 표준 방법이 있습니까?

실제로는 아닙니다. 그것은 당신의 팀, 당신, 당신이해야 할 일, 그리고 회사가 당신에게 어떤 자원을 제공 할 것인지에 달려 있습니다.

개인적으로 가장 좋은 종류의 스위치는 기술 관리를 관리 관리에서 분리하는 것입니다. 사람들이 둘 다 능숙하고 드물게 상호 작용하는 경향이 거의 없습니다.

한 사람이 기술적 측면을 처리합니다. 해야 할 일, 누가 할 일, 일을 어떻게 정리해야하는지. 다른 하나는 관리 측면을 처리합니다. 그런 다음 검토, 예산 회의, 제품 계획 등을 통해 한 쪽에서 다른쪽으로 통찰력을 전달하고 통일 된 전선을 제공합니다.

이것이 어떻게 분해되는지는 몇 가지 다른 방법으로 갈 수 있습니다. 가장 일반적인 것은 엔지니어링 관리자가 관리적인 측면이고 achitect는 기술적 인 측면이되는 것입니다. 그들은 동료이며 감독 / VP에보고합니다.

내가 본 또 다른 작업은 엔지니어링 관리자가 관리 담당자가되게하고 팀장이 기술 담당자 역할을하는 것입니다. 이는 더 까다 롭고,보고가 계층 적 일지라도 올바른 사람들이 (대부분) 동료로 행동해야합니다.

특정 시나리오의 경우 2-3 개의 팀을 구성하고 기술적 인 측면에서 기술적 인 측면을 수행하고 관리에 집중할 것을 권장합니다. 그렇습니다. 실제로 코드를 작성하는 리드에서 시간을 단축하지만 더 좋은 개발자를보다 효율적이고 생산적으로 만들어서 그 시간을 회복해야합니다 (좋은 일을하는 경우). 그것은 실제 승진으로 그들에게 더 많은 동기 부여와 성취감을 제공합니다. 그리고 가장 실질적으로 새로운 직책을 여는 것보다 경영진에게 판매하는 것이 더 쉽습니다.