[소프트웨어 아키텍처] 효율적인 프로젝트 팀 만들기

팀 규모는 아키텍트가 개발팀에 행사하는 제어량에 영향을 미치는 팩터 중 하나 입니다. 팀이 클수록 제어가 많이 필요하고 팀이 작을수록 제어가 덜 필요 합니다. 가장 효율적인 개발팀 규모는 아래 3가지 팩터로 결정 됩니다.

• 프로세스 손실
• 다원적 무지
• 책임 확산

프로세스 손실

기본적으로 프로젝트에 인력을 더 많이 투입 할 수록 프로젝트 수행하는 기간이 길어진다는 것 입니다. 유능한 소프트웨어는 개발팀을 잘 관리하여 프로세스 손실을 찾습니다. 프로세스 손실은 어떤 프로젝트나 과업을 수행하기에 올바른 팀 규모를 결정하는 유용한 팩터 입니다. 코드를 리포지터리에 커밋할때 병합 충돌이 자주 발생하면 이는 프로세스 손실의 징후 입니다. 즉, 팀원들이 동일한 코드 작업을 하고 있다는 방증 입니다. 프로세스 손실을 방지하려면 팀 내부적으로 병렬 작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있겠끔 환경을 제공 합니다. 팀원이 새로 합류 했는데도 병렬 작업 흐름을 생성할 부분이 없다면 이 신규 팀원이 왜 프로젝트에 합류 했는지 알아보고 현재 상황에서 인력을 추가 투입 하면 부정적인 영향이 있을 거라는 점을 프로젝트 관리자에게 설명해야 합니다.

다원적 무지

팀 규모가 너무 크면 다원적 무지 현상도 발생 합니다. 모든 사람들이 자신이 뭔가 너무 뻔한 것을 놓치고 있는 게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상 입니다. 예를 들어 잘못된 표준이 왔는데 그걸 그냥 동의하는 모습이라고 볼 수 있습니다.

유능한 아키텍트는 어떤 성격의 협업 회의나 토론을 하더라도 상대방의 표정과 몸짓을 끊임없이 관찰하며 다원적 무지가 일어날 것 같으면 조정자를 자처 합니다. 중간중간 끼어 들어 그 동안 논의된 해결책에 대해 사람들에게 의견을 물어보고 그들이 발언할 때 그들 편에서 지지해줘야 합니다.

책임 확산

팀 규모가 커질수록 의사 소통이 잘 안되는 건 모두가 공감하는 팩트 입니다. 팀원 중 누가 무슨 일을 담당하고 있는지 혼란스럽다면 팀이 너무 커졌다는 신호 입니다.

유능한 아키텍트는 개발팀이 아키텍처를 잘 구현하도록 친절하게 안내하는 것은 물론 팀이 건강하고 행복하게 공동 목표를 달성하도록 서로 협력하는 분위기를 조성 합니다.

이 3가지 징후를 발견하고 결과적으로 개발팀 스스로 바로잡을 수 있게 도와주면 팀을 매끄럽게 꾸려갈 수 있습니다.