리드 개발자를 교체하는 것이 좋은 아이디어입니까?

몇 달 전에 창립 된 이후 조직적으로 평평한 팀에서 일하고 있습니다. 내 관리자는 기술이 아니므로 팀 전체가 의사 결정을 담당합니다.

저의 관리자는 자신을 위해 (단일 연락 지점 및 업무를 담당하는 단일 책임 당사자) 우리 (분쟁 해결, 체계적인 기술 지침 등)를 위해 리드 개발자를 보유하면 여러 가지 이점이 있음을 깨닫기 시작했습니다.

팀이 평평했기 때문에 한 가지 우려는 한 명의 개발자를 선택하면 다른 개발자를 낙담시킬 수 있다는 것입니다. 개발자가 아닌 사람은 관리자에게 리드 개발자를 교체하는 것이이 문제를 피할 수있는 방법이라고 제안했습니다. 한 개발자는 한 달 동안, 다른 개발자는 다음 달 등으로 이끌 것입니다.

이것이 좋은 생각입니까? 그 이유는 무엇?

이는 모든 개발자를 의미 합니다. 모든 개발자는 훌륭하지만 반드시 리더십에 똑같이 적합하지는 않습니다.

그렇지 않은 경우 이기적인 이유가 아닌 것처럼 보지 않고이 방법을 사용하지 않는 것이 좋습니다.

회전하지 마십시오.

나는 어떤 사람이 회전하는 포지션에서 아무것도 얻지 못한다고 생각합니다 (리드 자격이없는 사람들은 현재 받고있는 것보다 더 많은 돈을 얻을 수 있습니다).

다음을 수행 할 수있는 뛰어난 수석 개발자가 있으면 개발 프로세스가 궁금합니다.

1. 위임하는 방법을 알고 있습니다.
2. 통제하고 있습니다.
3. 숙련 된 개발자입니다.

그는 나머지 팀원이 조언을 구할 수있는 단일 소스입니다. 또한 고위 경영진과 핵심 개발 팀 사이의 중재자이기도합니다. 나는 변화를 다루는 것을 좋아하는 경영진에 대해 모른다.

당신이 정말로 그 직책에 가장 적합하다면, 모든 사람들이 그것을 알고있을 것입니다. 누구나 알고있을 것입니다 (예 : 고위 경영진, 팀원 등). 당신이 그 위치를 회전시키는 것이 가치가 있다고 믿지 않는다고 말하십시오 (그렇다면 믿는다면). 그런 다음 앉아서 앉아서 임명하게하십시오-이름을 버리거나 자기 진급을 자제하십시오.

수석 개발자가되는 데는 두 가지 부분이 있습니다.

• 기술 리더십 기술 리더십의 경우 프로젝트 수준에서 다른 리드 개발자를 선택하는 것이 좋습니다. 프로젝트가 회전함에 따라 필요에 따라 회전하여 각 개발자를 다른 프로젝트의 기술 리더로 만듭니다. 이러한 종류의 접근 방식은 팀 역학을 처리하고 모든 사람이 올바르게 도전하도록 보장 할 수 있습니다

• 의사 소통 외부 세계와의 의사 소통을위한 단일 접점은 외부 세계에 좋으며 접점에는 좋지 않습니다. 커뮤니케이션 공에 갇힌 사람은 실제 작업을 수행하는 데 걸리는 시간이 줄어들고 모든 사람이 정보를 전달해야합니다. 당신이 최고의 의사 소통 자이고, 모든 대화를하는 대신에 더 많은 재미있는 일을 기꺼이 멈출 수 있다면 더 많은 힘을 얻게됩니다.

관련된 개발자가 참여하고 (이상적으로) 능력이 있다면 반드시 나쁜 생각은 아닙니다.

나는 이것에 대한 참조를 찾는 데 어려움을 겪고 있지만 계속 볼 것입니다. 어떤 민첩한 회사가 이것을 정확하게 기억한다면 그들은 매번 반복하거나 다른 사전 정의 된 시간에 "팀장"이라는 제목을 회전시킵니다. 기간. 이를 통해 개발자 참여를 장려하고 개발자가 해당 역할을 개발하지 못하게 영구적으로 전환하지 않고도 모든 팀 관리 / 외부 커뮤니케이션을 수행 할 수 있습니다.

일부 단점은 잠재적 인 정보 손실 (여러 가지 방법으로 완화 될 수 있음) 및 "나쁜"리더십에 대한 높은 잠재력을 포함합니다. 팀의 비전 / 방향을 유지하기가 어려울 수도 있습니다. 그러나 모든 사람들이이 접근 방식에 참여하고 있고 팀원들이 그러한 시스템 작동에 대해 잘 알고 있고 관심이 있다면, 그것은 가치가 있습니다.

회전하는 경우 프로젝트 도중 회전하지 마십시오. 특정 프로젝트의 각 직책에서 누가 가장 적합한 지에 따라 다른 프로젝트에 대해 다른 사람에게 다른 역할을 할당하는 데 본질적으로 잘못된 것은 없습니다. 그러나 조가 일을 수행 할 시간이 되었기 때문에 Joe를 "리드 프로그래머"로 만들지 마십시오. 그는 그것에 익숙하지 않을 수도 있고, 직업을 원하지 않을 수도 있습니다.

시간에 따라 리드 개발자를 회전시키는 것은 나쁜 생각입니다.

모두가 훌륭한 개발자라고해서 모두가 훌륭한 리더라는 의미는 아닙니다. 그리고 좋은 리더라는 것이이 프로그램의 리더에게 적합하다는 것을 의미하지는 않습니다.

개발자에게 할당 된 미션의 중요성이 다르고 각 개발자의 리더십이 다르다고 생각합니다. 1 명당 2 명씩 최우수 후보로 선정되며, 가장 많은 표를 얻은 사람은 리더 개발자 여야합니다.

수석 개발자를 교체하는 것은 나쁜 생각이 될 수 있다는 Jonathan Khoo의 의견에 동의합니다 . 일반적으로 규모가 큰 프로젝트에는 프로젝트를 이끌고있는 단일 기술 책임자가 있으며 다양한 시스템 전반의 문제를 논의하기 위해 여러 가지 구성 요소 리드를보고 할 수도 있습니다.

그러나 Jonathan이 언급하지 않은 한 가지 중요한 점은 기술 책임자도 프로젝트의 다른 사람들이 가질 수없는 높은 수준의 제도적 지식을 개발한다는 것입니다. 기술 리드를 회전 시키면 누군가가 위치로 회전 할 때마다 해당 지식을 개발해야합니다. 또한 리드는 최종 사용자와의 (대규모) 회의 중 일부에 이상적으로 나타나야하기 때문에 프로젝트 외부의 고객과의 관계를 발전시킬 것입니다.

기술 리드를 확보하는 것이 좋지만,이를 시도하고 회전 시키면 하나도없는 것이 더 나을 수 있습니다.

먼저이 사람의 역할이 무엇인지, 누가 누구보다, 얼마나 오래 결정해야하는지 생각해야합니다.

또한 이것이 다른 직원의 업무 방식을 크게 변화 시킬지 여부와 성능 저하 여부를 결정해야합니다. 한 사람이 다른 사람보다 코드의 모든 줄을 "승인"해야 심각한 영향을 줄 수 있습니다.

"우수한"사람없이 다른 팀원에게 다른 특정 역할을 부여 할 수 있습니다. 관리자와 다른 사람 사이의 의사 소통에 가장 능숙한 사람에게는 특정 역할이 부여 될 수 있지만 이것이 "주요 개발자"라는 의미는 아니며 기술적으로나 최고의 사람이 아닐 수도 있습니다. 코드 검토

나는 팀이 표면적으로 평평한 동안 그들 사이에 이미 리더가 있으며, 그들은 이미 그것을 알고 있다고 확신합니다.

조직도는 사람들이 실제로 일하는 방식을 거의 반영하지 않습니다. "평평한 팀"과 같은 특히 이상적인 차트.

조직이 평평한 경우 모든 개발자가 요구 사항 및 솔루션 분석 (RSA) 교육을 통해 공식 프로세스를 따르도록하십시오. 그런 다음 여러 SME (Subject Matter Expert)를 프로젝트에 할당하고 모든 솔루션에 대해 문서화 된 프로세스를 얻을 수 있습니다.

또한 관리자가 비 기술적이라고 언급 했으므로 해당 개인은 여전히 ​​RSA 프로세스를 추진하고 커뮤니케이션을 촉진 할 수 있습니다. 또한 프로젝트별로 특정 SME를 프로젝트의 리드로 지정하여 촉진을 지원하고 개별 기술 세트를 구축 할 수 있습니다.

개발자 팀이 익명으로 투표하지 않는 이유는 무엇입니까? 우선 투표를 사용합니다.

1. 팀 중에서 다른 사람을 선택하여 팀을 이끌 수 있습니다.
2. 상사는이 직책을 맡기 위해 다른 숙련 된 사람을 고용 할 수 있습니다

추신 : 나는 회전이 좋은 생각이라고 생각하지 않으며, 의사 소통에 능숙해야하며 팀 관리에 좋은 경험이 있어야합니다.

귀하의 질문에서 알 수 있듯이 전체 팀은 의사 결정을 담당합니다. 동일한 방식으로 유지할 수 있다고 제안합니다. 그러나 팀 외부의 권한을 전달하고보고하기 위해 팀에서 팀 코디네이터를 선택할 수 있습니다 . 그의 책임은 기술적이지 않은 모든 것을 포함 할 것입니다. 모든 기술적 측면에서, 팀은 현재와 같은 방식으로 앉아서 논의해야합니다. 어떤 결정을 내리든지 Co-Ordinator 를 통해 외부와 소통 할 수 있습니다 . 이 위치는 시간 기반 방식으로 쉽게 회전 할 수 있습니다.

다른 접근 방식은 동일한 회사의 경험 수준> 동일한 프로젝트 경험> 경험 수준에 따라 리드 개발자를 두는 것입니다. 그리고 필요하다면, 위치를 단계적으로 회전시킬 수 있습니다. 이상적으로 각 개발 단계에는 자체 요구 사항과 결과물이 있으며, 이는 미니 프로젝트로 계획하고 작업 할 수 있습니다. 각 단계마다 다른 리드를 사용하면 회전의 거의 모든 부정적인 영향을 최소화 할 수 있습니다.

회전하는 리드 개발자가 아닌 x 프로젝트를 완수하기 위해 가장 많은 지식과 지식을 가진 사람이 회전하는 프로젝트 리더를 갖습니다.

리드 개발자는 일반적으로 프로모션이며 적립해야합니다.

그러나 리더십 기술을 훈련시키고 개발하기 위해 다른 프로젝트를 담당하는 사람을 교체 한 다음 그들이 얼마나 잘했는지에 대한 명확한 측정 값을 갖습니다.

충분히 큰 배에 선장이있는 것과 같은 방식으로 팀장이 있어야합니다.

관리자가 해당 역할을 수행 할 수 없거나 수행 할 수없는 경우 개발자 중 한 명을 지정하여 작성해야합니다.

먼저 개발팀 내에서 모든 기술적 결정을 내릴 수있는 힘이 얼마나 운이 좋은지 총체적으로 알아야한다고 생각합니다. 기술 관리에 영향을 미치는 마이크로 매니지먼트 계층의 부담으로 인해 얼마나 많은 팀이 어려움을 겪고 종종 일관성이없는 선택, 호환성 악몽 및 개발자 좌절을 초래 하는가 ...

개발자가 언급 한 개발자 리드의 이점에서 실제로 기술 능력 측면에서 자연스럽게 뛰어난 사람이 있다면 그 중 일부 (조직화 된 기술 지침 ...)가 이미 발생하고 있어야합니다. 이 경우 공식 개발자를 공식 개발자로 만드는 것이 현재 얻는 것보다 더 나은 결과를 얻는 방법을 알 수 없습니다. 그러한 팀원이 당신의 팀에 존재하지 않는다면, 공식적으로 어떤 사람 에게 기술적 권한을 부여하는 것이 토론과 집단적 결정보다 더 나은 결과를 가져 오는지 알 수 없습니다 .

나는 덴마크가 말한 코디네이터 인 조직 리더를 설립하는 데 훨씬 더 큰 가치가 있다고 생각합니다. 관리자가 아니라 상사가 아니라 집단적 의사 결정 프로세스를 조직하고 팀의 대변인, 외부와의 인터페이스 역할을하는 사람. 그렇게하면, 급여 차이, 질투 등 앞서 언급 한 문제를 피하는 것이 좋습니다.

언젠가는 리더가되는 것이 다른 것보다 더 무거운 책임입니다. 누군가 선택에 책임을 져야했는데, 다른 사람이 선택을 원하지 않을 때 사회가 작동하는 방식입니다.

팀이 리더를 교체하기를 원한다는 사실은 모든 사람이 자신이하는 일에 대해 책임을 질 수 있다고 느끼고 다른 사람을 선호하고 싶지 않다는 것을 의미 할 수 있습니다. 좋은 감정인 것 같습니다. 모두 팀이 성공하기를 원합니다.

그러한 경우, 어려운 결정이 내려 질 때 그 결정에 투표하고 다른 사람과 대화하기 위해 담당자가 필요할 때 최고의 의사 소통 기술을 가진 사람을 선택하십시오.

우선, 역할을 분리해야한다고 생각합니다. 팀과 회사의 다른 사람 사이의 접점 역할을하는 사람이 반드시 최종 기술 결정을 내리는 사람 일 필요는 없습니다.

연락 담당자 역할을 수행해도 권한이 부여되지 않으므로 정해진 일정에 따라 책임을 져야 할 필요는 없습니다. 나는 팀이 자리에 앉게하고 모든 사람들은 그들이 일을 얼마나 마땅히 할 것인지 (일부는 사람들이 좋아할 수도 있고, 다른 사람들은 그 일을하는 것에 강력하게 반대 할 수도 있음) 말한 다음 누군가에게 역할을 맡기도록 투표한다고 말합니다. 그들이 아플 때마다 다른 사람에게 넘길 수 있다는 것을 이해하십시오.

기술 리드 측도. 모든 사람이 동일한 기술과 거의 동일한 수준의 경험을 가지고 있다면 모두가 리드가되도록 노력하십시오. 중요한 것은 프로젝트 중간에 절대 변경하지 않는 것입니다. 새 프로젝트가 시작될 때까지 기다린 다음 해당 영역에서 가장 경험이 많은 사람 또는 무작위로 리드를 선택하십시오.