프로젝트에서 개발자를 회전시키는 것이 좋은 아이디어입니까?

다른 소규모 팀과 함께 대규모 새 프로젝트를 시작하는 소규모 팀에서 일하고 있습니다. 다른 팀은 현재 수년간 사용해온 레거시 시스템에서 작업하고 있습니다.

관리자는 팀의 개발자가 레거시 시스템에서 작업하는 개발자를 대체하기 위해 몇 개월마다 교체하기로 결정했습니다. 이렇게하면 다른 팀이 새로운 프로젝트를 수행하고 새로운 시스템을 더 잘 이해할 수 있습니다.

2-3 개월마다 프로젝트에서 개발자를 회전시키는 데 따른 이점과 단점을 알고 싶습니다.

나는 이것이 "주요 개발자를 선동하는 것이 좋거나 나쁜 생각입니까?" 와 비슷한 질문이라는 것을 알고 있습니다. 하지만이 질문은 리드 개발자에게 중점을 둡니다. 이 질문은 전체 팀을 프로젝트 안팎으로 회전시키는 것에 관한 것입니다. (새로운 프로젝트의 기술 책임자는 회전하지 않을 수도 있습니다. 아직 모르겠습니다).

모두가 이것이 좋은 것이라고 생각하는 것에 놀랐습니다. Peopleware 의 저자 (IMO는 여전히 읽을 가치가있는 귀중한 몇 가지 소프트웨어 프로젝트 관리 서적 중 하나임)는 크게 동의하지 않습니다. 이 책의 거의 4 부 전체가이 문제에 전념하고 있습니다.

소프트웨어 팀 은 매우 중요한 기능 단위입니다. 팀은 생산성을 높이기 위해 노력해야합니다. 그것은 시간의 (a 걸리는 많은 팀 구성원이 '존경 서로 배우는'서로를 적립하는 습관과 단점 그리고 강점과 약점을위한 시간을).

확실히, 개인적인 경험을 통해, 특정 사람들과 일한 지 1 년이 지난 지금, 나에게 도움이 된 것들을 웃어내는 것을 배웠으며, 팀장으로서의 나의 추정치가 훨씬 나아졌으며, 그렇게하기가 어렵지 않다 모든 사람을 행복하게하기 위해 일을 배부하십시오. 처음에는 그렇지 않았습니다.

"아,하지만 우리는 팀 전체를 무너 뜨리지 않고 단지 몇 사람을 움직일뿐입니다." 그러나 (a) 교체 제품 이 처음부터 얼마나 맹목적으로 비생산적인지 , (b) "나는 정말로 X를 좋아했다" 또는 "이것은 Y가 여전히 주변에서 쉬워졌습니다. " 라는 것은 미묘하고 무의식적으로 새로운 멤버를 불쾌하게하고 기존 팀 내에서 도발을 일으키며 심지어"오래된 "멤버들 사이에 불만을 심었습니다.

사람들은이 작업을 수행하지 않는 목적에 물론 있지만, 거의 모든 시간을 발생합니다. 사람들은 생각없이 그것을합니다. 그리고 그들이 스스로를 강요하지 않으면, 그 문제에 더욱 집중하게되고 강제 침묵에 좌절하게됩니다. 팀과 하위 팀조차도 구조를 망칠 때 시너지 효과를 낳습니다. 피플웨어 (Peopleware)의 저자는 "teamicide"의 형태를 호출합니다.

즉, 팀 멤버를 교체 하는 것은 끔찍한 일이지만 팀 자체를 회전시키는 것은 완벽합니다. 잘 운영되는 소프트웨어 회사는 제품 소유권 개념을 가져야하지만 팀이 실제로 이전 프로젝트를 마치거나 최소한 프로젝트를 가져 오는 한 팀 전체를 다른 프로젝트로 옮기는 것이 팀을 방해하는 것은 아닙니다. 그들이 만족하는 수준.

가짐으로써 팀 대신 stints 개발자 stints을, 당신은 단위로 각 팀의 불쾌한 부작용의없이 개발자 (문서, "교차 수분"등)을 회전하여 얻을 기대하는 모든 같은 혜택을받을. 경영진을 실제로 이해하지 못하는 사람들에게는 생산성이 떨어질 수 있지만 팀을 분할하여 생산성 손실을 줄이면 해당 팀을 다른 프로젝트로 옮김으로써 생산성 손실을 완전히 줄일 수 있습니다.

PS 각주에서 기술 책임자는 회전 하지 않는 유일한 사람 일 수 있습니다 . 이것은 두 팀 을 혼란스럽게 만듭니다. 기술 책임자는 관리자가 아닌 리더이며 팀의 존경을 얻어야하며, 높은 수준의 관리에 의해 단순히 권한이 부여되지 않습니다. 전체 팀을 함께 일한 적이없고 건축, 유용성, 코드 구성, 추정 등과 같은 다른 아이디어를 가질 가능성이 높은 새로운 리더의 지시에 따라야합니다. 이전 리드가없는 상태에서 응집력을 잃기 시작하는 팀원에게 신뢰를 심어주고 비생산적이되는 리드에게. 때때로 회사 는즉, 리드가 종료되거나 승격 된 경우 선택을 통해 수행하는 것은 미치게 들립니다.

나는 여기에 단점이 많이 보이지 않습니다. 회전은 당신을 얻는다 :

• 제도적 지식의 교차 수분-최소한 이론적으로는 기존 프로젝트와 새로운 프로젝트를 모두 알게됩니다.
• 교차 훈련-프로젝트마다 다른 것들이 필요합니다. 멋지고 깨끗한 그린 필드 프로젝트보다 못생긴 레거시 프로젝트에서 작업하는 개발자로 훨씬 더 성장합니다.
• 근본적으로 더 나은 프로젝트-문서를 완성하고 공개적으로 인정하지 않으려는 문서를 완성하고 추한 프로세스를 정리하기 위해 새로운 팀을 구성하는 것과 같은 것은 없습니다.
• 더 나은 코드-대부분의 경우 더 많은 헤드가 더 좋습니다.
• 사기 개선 가능성-다양성은 삶의 향미입니다. 그리고 레거시 프로젝트 버그 수정 / 덕트 테이핑 모드에 영구적으로 붙어 싶어하는 사람. 또한 "새로운"프로젝트가 언젠가는 유산이 될 것이라는 점을 명심하십시오. 영원히 거기에 갇히고 싶습니까?

아마도 유일한 단점은 전환 장소에서 얻는 생산성 저하이지만 첫 번째 라운드에서 나빠질 것입니다. 그 후 양측은 어느 곳에서나 자리에 앉을 것이며 핸드 오프의 추악한 부분을 더 잘 이해하고 해결할 수있을 것입니다.

흥미롭게도 우리의 경험에서 우리는 종종 이러한 의도로 프로젝트를 시작했습니다. 새로운 프로젝트에 대한 제약과 교차 훈련이 너무 비싸다는 신념으로 인해 우리는 종종 이러한 의도에 따라 행동하지 못했습니다.

팀, 회사, 클라이언트 및 소프트웨어와 같은 모든 당사자에게 도움이된다고 생각할 때마다 항상 관리했으면합니다. 2/3 개월은 심각한 부정적인 영향의 위험이 제한적일 정도로 오래 들리며, 대체 프로젝트에 전념 할 수있는 전환 시점을 제외하고는 관련 개발자에게 상황 전환이 진행되지 않습니다.

언급되지 않은 몇 가지 가능한 이점 :

• 더 나은 프로젝트 관리. 두 프로젝트의 프로젝트 관리자가 모두 참여하는 경우 전환 기간이 어느 프로젝트에서나 고통스럽지 않도록 열심히 노력하는 것이 최선의 이익입니다. 이 설정 (설정에 따라 다름)으로 PM과 개발 팀간에보다 긴밀한 협업이 이루어질 수 있습니다.
• 더 나은 (사전) 문서화 프로젝트를 시작하거나 종료하는 것을 알고 있다면 프로젝트의 최선의 이익, 회사의 최선의 이익, 일반적인 모범 사례뿐만 아니라 이제 각 개발자에게 튀는 동안 인생을 편하게 만들기 위해 최선의 이익을 소유합니다. 주위에.
• 사기가 큰 문제입니다. 개발자가 레거시 프로젝트에 푹 빠지지 않았다면 원하는 개발자가 아닐 수도 있습니다! 그들이 가지고 있다면, 그것들을 바꾸고 다른 개발자들에게 맡겨서 회사에 대한 사랑을 느끼게 할 것입니다. 레거시 시스템은 종종 2 단계 프로젝트로 간주되며, 이는 종종 자신의 손해를 입히는 데 도움이됩니다.

회전은 회사에 좋은 일이며 개발자에게도 좋은 일입니다.

많은 이유가 있으며 와이엇은 그의 답변에서 많은 것을 언급했다.

즉, 상황에 따라이를 소개 할 때 새로운 프로젝트를 레거시 프로젝트로 옮기는 개발자는 행복하지 않을 수 있으므로 왜 이런 일이 발생하고 얼마나 오래 지속되는지 명확하게 전달해야합니다. 그리고 계획이 진행됩니다.

팀을 도매로 바꾸지 않고 시작하기 위해 1 ~ 2 명의 개발자를 교체하지 않는 것이 좋을 것입니다.

많은 사람들이 단점을 보지 못하는 것을 보는 것은 매우 이상합니다. Aaronaught와 동의하십시오. 몇 가지 나쁜 생각, 당신은 매우 빠르게 지적 할 수 있습니다-코드에는 소유자가 없으며 모든 사람이 모든 것에 책임이있는 것은 품질에 좋지 않습니다 . 개발자는 리소스가 아니며 (매니저에 의해 그렇게 자주 호출되기도 함) 사람들이며 팀에게는 서로를 아는 것이 매우 중요합니다. 로테이션은 약간 혼란 스럽습니다. 오랜 기간 동안 일부 프로젝트에서 일하면 전문가가 될 것입니다 (도메인뿐만 아니라 해당 프로젝트에서), 대부분의 문제가 어디에서 왔는지, 누가 가장 잘 대답하는지 또는 더 구체적인 도메인 지식 등을 알게 될 것입니다. 새로 온 사람이라면이 모든 생각을 배워야하므로 진행 속도가 느려집니다. 물론 조직의 다른 관행을 아는 것도 좋습니다. 다른 팀이 구성하고 구성하는 방법. 프로젝트가 어떤 방식으로 관련되어있는 경우에 특히 좋습니다. 예를 들어 하나의 프로젝트가 다른 프로젝트에 대한 입력 (직접 필요하지 않음)이므로 큰 그림을 더 잘 이해할 수 있습니다. 물론 전문 지식을 전파하는 것도 좋습니다 (이러한 지식을 얻을 시간이 있다면).

Aaronaught의 최고 답변에 동의하며 몇 가지 추가 사항이 있습니다.

• 사람들은 밀리는 것을 좋아하지 않습니다.
• 계층 적 비즈니스 환경에서 사람들은 나중에 다시 책임을지게 될 책임이 할당 될 수 있습니다. 이것은 단지 일의 일부일 수 있습니다. 그러나 이러한 일이 자주 발생할수록이 사람들은 자신에게 할당 된 모든 것에 대해 책임감을 느끼지 않을 것입니다.
• 전자의 요점은 또한 사람들 스스로 만들지 않은 것들에 대한 유지 보수 작업에도 적용됩니다. 다른 사람들의 엉망을 없애는 것 (또는 더 중립적으로 정리 된 : 미완성 된 일)은 대부분의 개인을 만드는 데 동기를 부여하지 않습니다.
• "프로그래머는 프로그래머이며 프로그래머는 필요에 따라 프로젝트에 삽입 할 수있는 익명 플러그인"이라는 철학은 어떤 프로그래머도 자신에게 할당 된 작업에 대해 감사하거나 더 신경을 쓰지 않습니다.

누군가를 재 할당 할 수있는 완벽한 시간은 그들이하는 일에 지루해지기 시작할 때입니다. 더 이상 얻을 것이 없으며 모든 것이 통제되고 있으며 작업이 완료되었습니다. 이러한 경우에 그들은 일반적으로 앞으로 나와 다른 기회를 요구할 것입니다.

물론 현실은 완고하고 종종 선택의 여지가 없으며 어떤 이유로 든 다른 곳에서 누군가가 필요할 수 있습니다. 이것은 반드시 나쁘지는 않지만 사람을 중요하게 느끼게 할 수 있으며 큰 문제를 해결해야한다면 그에 대한 신용이있을 것입니다.

지식을 전파하기 위해 사람들을 뒤섞 으면 이직률이 높아질 것입니다. 그렇게하면 지식이 확산 될 것이지만, 의도가 아닌 회사 외부로 확산 될 것입니다.

TL; DR 한 팀으로 만든 다음 두 프로젝트를 지원하는 한 팀입니다.

@Aaronaught를 반향하기 위해 새로운 팀, 프로세스 등에 적응하는 데 시간이 걸릴 수 있으므로 믹싱 팀은 문제가 될 수 있다고 생각합니다. 너무 많은 사람들을 빠르게 돌리면 팀의 정체성을 잃게됩니다. 이것은 더 많은 질문, 혼란 및 그 정체성을 보충하는 데 소비되는 시간으로 이어집니다.

반면에 두 팀을 하나의 팀으로 합류시키고 1 팀이 2 개의 프로젝트를 지원하려는 공동 노력이 있다면 팀이 너무 크지 않은 한 훌륭하게 작동한다고 생각합니다. 여러 프로젝트를 지원하는 수많은 팀의 일원이었습니다. 두 프로젝트가 기술에 가까울수록 전환이 더 쉬워집니다. 내 경험상 언어, 클라이언트 / 서버 (GUI 특히), 산업 (의료, 웹, 게임) 또는 기타 유사한 라인을 교차 할 때 한 프로젝트에서 다른 프로젝트로 전환하는 데 더 많은 비용이 듭니다. 비결은 다른 사람들이 혜택을 얻을 수있을만큼 자주 프로젝트를 진행하도록하지만 전환 비용이 혜택을 초과하는 경우는 아닙니다.

그러면 더 많은 사람들이 프로젝트에 참여하게하는 이점은 비용과 마찬가지로 잘 알려져 있습니다.

프로그래머의 회전은 회사의 관점과 개발자의 관점에서 좋은 것입니다.

회사 관점에서

1. 경영진은 멀티 태스킹을 처리 할 수 ​​있는지 여부와 변경 사항에 적응할 수 있는지 여부를 특정 개발자의 강점과 약점을 알게됩니다.
2. 어떤 개발자가 어떤 이유로 회사를 떠날 경우, 회사는 이미 백업을 준비했습니다.
3. 많은 사람들이 프로젝트를 진행함에 따라 점점 더 많은 개발자들이 같은 것을 테스트함으로써 프로젝트의 성능을 향상시킬 것입니다. (테스트 리소스 낭비 최소화)
4. 모든 팀원은 팀에서 일하며 프로젝트 성과를 향상시키고 향후 경영진은 어려운 모듈이나 작업을 구현하는 동안 어떤 종류의 팀을 구성해야하는지 알게 될 것입니다.

개발자의 관점에서

1. 그의 자신감이 높아질수록 개발자를 더 긍정적으로 만들 것입니다.
2. 개발자는 다른 팀 동료 코드에서 더 나은 아이디어를 얻고 향후 개발에 이러한 기술을 사용할 수 있습니다.
3. 더 나은 아이디어와 다른 팀원의 제안으로 개발자의 생산성이 향상됩니다.

한 가지 중요한 점만 명심해야합니다.

프로그래머의 회전은 자주 발생해서는 안됩니다. 60 %-70 %의 개발이 완료된 후에 만 ​​변화가 도움이 될 것입니다.