13 Team Structure

[jongfeel]

제 13장 팀 구조

능력과 의욕이 있고 성실한 사람을 모아도 잘못된 팀 구조는 성공하려는 노력을 높이기 보다는 악화시킨다.
나쁜 팀 구조는 개발 기간 지연, 품질 저하, 사기 하락, 이직률 증가를 일으키고 결국 프로젝트 취소까지 불러 일으킬 수 있다.
일반적으로 전체 프로젝트 팀의 1/3 이 비효율적인 팀 구조로 이루어져 있다 (Jones 1994).

13.1 팀 구성시 고려사항

라손과 라파스토(1989)는 전반적인 목표로 다음 세 가지를 제시한다.

• 문제 해결
• 창의성
• 전술 실행

팀 종류

목표를 정한 뒤 목표 달성이 필요한 특징을 강조하도록 팀 구조를 정한다.
문제 해결 팀은 신뢰를 강조한다.
창의성 팀은 자율성이 중요하다.
전술 실행 팀은 명쾌함이 우선이다.

문제 해결 팀

• 문제 해결 팀은 복잡하고 정의가 불충분한 문제 해결에 초점을 맞춘다.
• 이 팀의 사람들은 믿을 만하고 똑똑하며 현실적이어야 한다.
• 이 팀은 주로 구체적인 문제를 하나 이상 다루며, 팀 구조가 이를 뒷받침해야 한다.

창의성 팀

• 창의성 팀은 가능성과 방안 검토를 특징으로 한다.
• 이 팀의 사람들은 자발적, 독립적, 창의적이며 끈기가 있어야 한다.
• 팀 구조는 팀원 개별 자율성과 팀 전체 자율성을 뒷받침해야 한다.

전술 실행 팀

• 전술 실행 팀은 정의해놓은 계획을 실행한다.
• 이 팀은 집중적인 목표와 분명한 임무 분담이 특징이다. 성공 기준은 흑백으로 팀이 성공했는지 아니면 실패했는지를 판단하기는 대체로 쉽다.
• 이 팀의 사람들은 임무에 대한 긴박감이 필요하고, 심오한 사색보다 행동을 좋아하고 팀에 충성해야 한다.

Table 13-1. Team Objectives and Team Structures

	Problem Resolution	Creativity	Tactical Execution
Dominant feature	Trust	Autonomy	Clarity
Typical software example	Corrective maintenance on live systems	New product development	Product-upgrade development
Process emphasis	Focus on issues	Explore possibilities and alternatives	Highly focused tasks with clear roles, often marked by clear success or failure
Appropriate lifecycle models	Code-and-fix, spiral	Evolutionary prototyping, evolutionary delivery, spiral, design-to-schedule, design-to-tools	Waterfall, modified waterfalls, staged delivery, spiral, design-to-schedule, design-to-tools
Team selection criteria	Intelligent, street smart, people sensitive, high integrity	Cerebral, independent thinkers, self-starters, tenacious	Loyal, committed, action-oriented, sense of urgency, responsive
Appropriate software-team models	Business team, search-and-rescue team, SWAT team	Business team, chief-programmer team, skunkworks team, feature team, theater team	Business team, chief-programmer team, feature team, SWAT team, professional athletic team

Source: Adapted from TeamWork (Larson and LaFasto 1989).

부과적인 팀 설계 특징

공통적으로 있는 특징 네 가지가 있다.

분명한 임무 분담과 책임감

"성공적인 팀은 모두가 책임감이 있다(Larson and LaFasto 1989)."

개별 능력 감독과 평가 피드백 제공

책임감과는 별도로, 팀원 각자 자신이 팀 기대에 부응하는지를 판단할 방법이 필요하다.
개인이 보이는 성과가 적정한지 아니면 개선이 필요한지를 팀원 각자에게 알려 줄 체계가 있어야 한다.

효율적인 의사소통

정보에 쉽게 접근할 수 있어야 한다.
정보 출추가 믿을 수 있어야 한다.
공식적이지 않은 사안에 이의를 제기할 기회가 있어야 한다.
의사소통 시스템은 팀원들이 제기한 문제와 이에 대한 결정 사항을 문서화할 수 있어야 한다.

사실 시반 의사결정

주관적인 판단은 팀 사기를 꺾는다.
팀원은 자신에게 영향을 미치는 결정에 깔려 있는 근거를 이해해야 한다.

쾌속 개발에 가장 적합한 팀 종류는 무엇인가

알아야 할 핵심은 바로 모든 프로젝트에서 최고 개발 속력을 내는 궁극적인 팀 구조는 없다.

문서 작성기를 개발한다고 하면
초반에는 뛰어난 제품 특성을 파악하는 일이 업무가 되며 창의성을 뒷받침하는 팀 구조를 만들어야 한다.
이후 다음 버전의 문서 작성기를 개발한다면 이전 버전에서 어떤 기능을 포함해야 할지를 이미 파악했으므로
경쟁우위를 유지하도록 이 기능들을 가능한 빨리 구현하는 것이다.
이럴 때는 전술 실행을 뒷받침하는 팀 구조를 선정해야 한다.

최고 '쾌속 개발 팀 구조'는 존재하지 않는다.
가장 효과적인 구조는 상황에 따라 다르기 때문이다. 그림 13-1.

Figure 13-1.No single team structure is best for all projects.13.1 Team-Structure Considerations

13.2 팀 모델

여기서 소개하는 모델 사이에는 직교 집합(orthogonal set)은 아니므로 중복과 모순이 존재한다.
여러 모델을 조합해 새로운 모델을 만들 수도 있다.
가능한 팀 구조 전부 제시하는 건 아니며 팀을 구성하는 다양한 방법이 존재함을 보여주는 것이다.

비즈니스 팀

기술 수석이 이끄는 동료 개발자 그룹이다.
팀원 전부는 같은 직위이며 데이터베이스, 그래픽, 사용자 인터페이스 등 다양한 프로그래밍 언어를 쓰는 전문 분야를 맡는다.
기술 수석은 동료 중 1인자이며 관리 보다는 전문적 기술 지식에 근거해 기술 수석 업무를 맡게 된다.

수석이 어려운 기술 사안을 최종적으로 결정하는 책임을 맡는 경우가 가장 일반적인 구성이다.
어떤 경우에 수석은 단순히 팀원 중 한 명으로서, 관리층과 의사소통이라는 추가 임무를 맡는다.

이 팀 구조에서는 팀원 각자가 자신의 전문 분야를 맡을 수 있다.
팀원 간 업무 할동은 팀 자체에서 결정이 가능하다.
이 팀 구조는 소규모 그룹에 효과가 있다.
시간이 지나면서 상호 관계를 정립해가는 장기적인 그룹에도 적합하다.

문제 해결, 창의성, 전술 실행 등 모든 종류의 구조를 사용할 수 있지만 이게 약점으로 작용하기도 한다.
많은 경우에 다른 팀 구조가 훨씬 낫다.

수석 개발자 팀

수석 개발자팀(Chief-Programmer Team) 개념은 1960년대 후반에서 1970년대 초반에 IBM이 창안했다 (Baker 1972, Baker and Mills 1973).
그 후, 프레드 브룩스가 저술한 Mythical Man-Month로 인해 유명해졌다(Brooks 1975, 1995).
프레드 브룩스는 수석 개발자 팀을 수술 팀(Surgical Team)이라고 불렀다.

이 개념은 슈퍼스타 개발자를 집도의(surgeon) 또는 수석 개발자(chief programmer)로 임명한다.
이 사람이 명세화 과정 전체를 읶르고 설계 전부를 완성하고, 코드 대부분을 작성하며 프로젝트 사안 대다수를 최종적으로 결정 내린다.
나머지 팀원은 자기가 맡은 특정 분야에 전념한다.
즉, 팀원 각자는 집도의 주위에 포진하여 지원하는 임무를 맡는다.

수석 개발자 팀은 한 분야에 관한 전문 개발자가 다방면에 지식이 있는 개발자보다 뛰어난 경향을 이용하는 팀 구조다(Jones 1991).
예비 개발자, 행정 책임자, 도구 관리자, 언어 전문가 등이 있고 현재는 소프트웨어 도구로 대체된 문서 전문가, 테스트 전문가, 프로그램 관리자도 있다.

20여년 전 수석 개발자 팀은 전대미문의 생산성을 보여주었다(Baker and Mills 1973).
이후 많은 회사가 수석 개발자 팀을 시도했지만 그 놀라운 성과를 재현하는 데 실패했다.
능력 있는 개발자는 대개 기술 선도 프로젝트에 참여하고 싶어하는데 비해,
기술 선도 프로젝트는 일반 회사가 흔히 수행하는 프로젝트와는 거리가 멀다.

프로젝트를 빨리 끝내기 위해서 수석 개발자 팀 구조를 사용하기 보다는
열심히 일할 용의가 있고 하루에 16시간씩 일하겠다는 슈퍼스타가 있으면 수석 개발자 팀이 적합하다.

수석 개발자 팀은 창의적인 프로젝트에 적합하다.
뛰어난 한 사람이 책임을 지므로 시스템 전체 일관성을 유지할 수 있다.
이 팀은 전술 실행 프로젝트에 적합하다.

스컹크웍스 팀

스컹크웍스 팀(Skunkworks Team)은 공학계에 전해오는 전설과 같은 팀 구조다.
스컹크웍스 프로젝트는 재능있고 창의적인 개발자 그룹에게 관료적인 제한이 없는 시설을 제공하고 창의적으로 개발하도록 도와준다.

이 팀 구조에서는 개발자가 강한 주인 의식과 놀라운 참여 의식이 생긴다는 장점이 있다.
그러나 팀 진행상황을 파악할 방법이 없다는 단점도 있다.

스컹크웍스 팀은 창의성이 핵심인 실험적인 프로젝트에 가장 적합하다.

기능 팀

기능 팀(Feature Team) 방식에서는 개발, 품질보증, 문서, 프로그램 관리, 영업 인력이 전통적인 계층 구조로 짜여 있다.
이 조직을 기반으로 각 그룹에서 한 명 이상을 차출하여 특정 제품 기능을 책임지게 한다(McCarthy 1995a).

기능 팀은 권한, 책임감, 공정이라는 장점이 있다.
따라서 문제 해결 프로젝트에 적합하다.
여러 분야에 걸친 팀 구성원은 아이디어를 자극하므로 창의성 프로젝트도 적합하다.

수색 구조 팀

수색 구조 팀(Search-and-Rescue Team) 모델에서 소프트웨어 팀은 조난당한 산악 등 반원을 수색하는 응급 의료 기술진처럼 행동한다.
특정 하드웨어와 소프트웨어 도구에 대한 전문 지식과 특정 비즈니스 환경에 대한 전문 지식이 모두 필요하다.
제품 손실이라는 응급 상황에서 제품 추적 소프트웨어에 대한 정통한 지식, 즉각적으로 문제에 대처하는 능력, 단시간에 시스템을 안정화시킬 수 있는 전문 지식이 있어야 한다.

수색 구조 팀 모델은 문제 해결 팀에 가장 적합하다.
창의성보다는 현실을 중시하며 전술 실행을 뒷받침하기에는 기간이 짧다.

특별 기동대 팀

특별 기동대 팀(SWAT Team) 모델은 군대나 경찰 특별 기동대 팀을 본보기로 한다.
소프트웨어어세는 '고급 도구'에 능숙한 팀을 말한다.
제임스 마틴이 RAD 방법론에서 제안한 개념이다. (Martin 1991)

특별 기동대 팀은 다음과 같은 분야에서 전문성을 발휘한다.

• 특정 DBMS 제품 - 엑세스, 오라클 등
• 특정 프로그래밍 환경 - 델파이, 파워빌더, 비주얼 베이직 등
• 특정 개발법 - JAD 세션, UI 프로토타이핑
• 특정 프로젝트 단계 - 프로젝트 예측, 계획 수립, 성능 최적화, 복구 등

특별 기동 임무는 상시 수행하지는 않지만 팀원들은 함께 일하는 데 익숙하고 맡은 임무가 분명하다.

특별 기동대 팀은 전술 실행 프로젝트에 특히 적합하다.
팀 임무는 익숙한 도구나 개발법을 사용해 해결책을 구현하는 일이다.
이 팀은 문제 해결 프로젝트에도 적합하다.
팀원들은 서로 신뢰하며, 프로젝트 단계 각각을 신속히 해결해야 할 문제로 간주하여 처리한다.

프로 운동선수 팀

프로 운동선수 팀(Professional Athletic Team) 모델은 기성품 소프트웨어 생산에서 흔히 찾아볼 수 있다.
일부 팀은 프로 야구 팀과 비슷하다. 개발자인 선수는 감독 보다 중요하다. 선수가 감독보다 프로젝트 성공에 더 큰 영향을 미치기 때문이다.

감독인 관리자의 임무는 장애물을 제거하고 개발자들이 효율적으로 일할 수 있는 환경을 만드는 것이다.
운동선수 각자는 고도로 전문적인 임무를 맡는다. 소프트웨어 팀도 마찬가지다.

프로 야구 감독이 전직 유명 선수이듯이 소프트웨어 분야도 마찬가지다.

이 모델은 개별 팀원이 맡는 전문적인 임무를 강조하는 전략 실행 프로젝트에 가장 적합하다.

극단 팀

극단 팀(Theater Team)은 분명한 방향성과 프로젝트 임무 협상이 특징이다.
감독은 제품 비전을 유지하며 개인에게 임무를 맡긴다.
배우는 예술적 본능에 따라 자신이 맡은 부분을 완성해간다.
개별 배우의 아이디어가 감독의 비전과 충돌할 경우, 프로젝트를 위해 감독의 비전을 우선한다.

개발자는 먼저 테스트를 받고 임무를 받는다.
개발자가 임무를 받기 전에는 상당한 협상을 하게 된다.

• "그래픽 기술 수석을 맡을 수 있다면 프로젝트에 참여하겠습니다."
• "데이터베이스에 싫증이 나서 이번엔 UI를 구현하고 싶습니다."
• "이번에는 수석을 맡아야 합니다. 다른 임무는 싫습니다."

이 모델에서 수셕역을 맡겠다고 서명했다면 이후 다른 역할을 할 수 없다.

소프트웨어 관리자는 감독 역이다. 자금 확보, 일정 조절, 인력 확보를 책임지고 프로젝트의 기술적 측면은 맡지 않는다.

극단 모델은 창의성이 필요한 프로젝트에서 강력한 비전을 중심으로 통합 방법을 제공하는 장점이 있다.
프레드 브룩스는 개념적인 일관성은 시스템 설계에서 가장 중요하며, 시스템이 개념적인 일관성을 유지하려면 한 사람이 그 개념을 통제해야 한다(Brooks 1975).

극단 모델은 개성이 강한 사람들이 많은 소프트웨어 팀에 특히 적합하다.
프로젝트에서 정말로 중요한 임무를 특정 개발자만이 맡을 수 있다면, 감독은 프로젝트 성공을 위해 프리마돈나의 행동을 이해하기로 결정할 수 있다.

대규모 팀

대규모 팀은 의사소통과 조정 문제에 주목해야 한다.
프로젝트의 팀원 수가 증가하면 의사소통 경로 수와 조정할 업무량 역시 늘어난다. 사람 수가 아닌 사람 수의 제곱에 비례해 늘어나며 그림 13-2는 이런 증가 방식을 보여준다.

Figure 13-2.Communication paths on projects of various sizes.

의사소통 경로 수가 많아질수록, 의사소통에 드는 시간이 늘어난다.
그리고 그 과정에서 실수를 저지를 확률도 커진다.

대규모 프로젝트는 공식적이고 원활한 의사소통을 가능하게 만드는 조직 기법이 필요하다.
의사소통의 효율성은 팀 구조에 따라 크게 달라진다.

원활한 의사 소통을 하려면 계층 구조가 필요하다.

• 소그룹을 비즈니스 팀으로 조직한다. 대표는 팀 내에서 정한다.
• 소그룹을 수석 개발자 팀으로 조직한다. 대표는 예비 개발자가 맡는다.
• 소그룹을 기능 팀으로 조직한다. 대표는 프로그램 관리부가 맡는다.

팀을 어떻게 조직하던지 간에 개념적인 일관성을 최종적으로 책임질 사람은 단 한 명이어야 한다.
각 팀이 내놓는 부분적인 해결책을 모아 전체적으로 우수한지 확인하는 임무를 맡는 사람이 반드시 한 명은 있어야 한다.

13.3 관리자와 기술 수석

관리책임자를 수석 또는 기술 수거이라고 부른다.
보통 관리 보다는 기술 능력에 근거해서 이 임무를 맡긴다.

관리자와 기술 수석은 항상 밀접하게 일하지는 않는다.
그러나 두 사람이 해당 사안에 대해 효율적인 의사소통을 한다면 책임 중복, 동기, 고객 관계, 품질 저하, 프로젝트 목적 탈피 등 많은 문제를 개선할 수 있다.

기술 수석 임무를 효과적으로 수행하는 데 있어 가장 큰 장애물은 기술 수석과 관리자 사이에 정확한 책임 분담의 어려움이다.
흔히 책임이 뒤섞이는 경우가 많다.

가장 이상적인 상황은 기술 수석이 기술 업무를 책임지고 한 팀을 맡는다.
관리자는 비기술적인 방향을 책임지고 프로젝트 둘 이상을 맡는다.
운동선수 팀이나 극단 팀과 같은 일부 모델은 관리자와 기술 수석을 분리하기가 비교적 쉽다.

프로젝트 초반에 기술 수석과 관리자가 책임 분담을 의논하는 편이 바람직하다.
문제가 생기면 자기 책임이라고 생각하는 책임 충돌과 상대편 책임이라고 생각하는 책임 공백을 없앨 수 있다.

존 보디는 프로젝트 관리자와 기술 수석의 관계를 그림으로 표현했다.
[그림 13-3]에 몇 가지를 보여주고 있다(Boddie 1987).

Figure 13-3.Project manager’s and technical lead’s responsibilities. Since specificroles can vary from project to project, a discussion that uses this illustration as afocal point can help to clarify the division of responsibilities on a particularproject. Source: Adapted from Crunch Mode (Boddie 1987).

읽을 거리

다음은 팀 구조에 대한 일반적인 정보를 담은 자료 세 편이다.

• Larson, Carl E., and Frank M. J. LaFasto. Teamwork: What Must Go Right;What Can Go Wrong. Newbury Park, Calif.: Sage, 1989.
  • 3장에 프로젝트 목표와 효과적인 팀 구조를 설명한다.
• Communications of the ACM, October 1993.
  • 프로젝트 조직과 관리라는 주제로 팀 구조에 관한 논문 여러 편이 실려 있다
• Constantine, Larry L. Constantine on Peopleware. Englewood Cliffs, N.J.:Yourdon Press, 1995.
  • 3장에 팀 구조를 설명한다. 라파스토 이론을 기반으로 팀 종류 네 가지를 정의한다.

다음은 특정 팀 구조를 다루는 자료다.

• Brooks, Frederick P., Jr. The Mythical Man-Month, Anniversary Edition. Read-ing, Mass.: Addison-Wesley, 1995.
  • 3장에 수석 개발자 팀을 설명한다.
• Thomsett, Rob. “When the Rubber Hits the Road: A Guide to Implementing Self-Managing Teams, ”American Programmer, December 1994, 37– 45.
  • 자기-관리 팀을 설명하고 이런 팀이 초기에 문제를 극복하는 실용적인 조언을 제시한다.
• McCarthy, Jim. Dynamics of Software Development. Redmond, Wash.:Microsoft Press, 1995.
  • 규칙 7 중에 '기능 팀을 사용하라' 는 내용으로 마이크로소프트의 기능 팀을 상세하게 설명한다.
• Heckel, Paul. The Elements of Friendly Software Design. New York: WarnerBooks, 1984.
  • 11장에 애니매이션 제작과 소프트웨어 개발 사이의 관계를 얘기한다. 설명하는 방식은 다르지만 극단 모델과 같은 개념이다.
• Martin, James. Rapid Application Development. New York: MacMillan Pub-lishing Company, 1991.
  • 여러 스컹크웍스 프로젝트를 얘기한다.
• Peters, Tomas J., and Robert H. Waterman, Jr. In Search of Excellence. NewYork: Warner Books, 1982.
  • 13장 "The Choir and the Team"에서 소프트웨어 개발 그룹을 이해하는 방법으로 합창단을 제안한다. 합창단의 성공은 개인의 능력만큼이나 협동에 달려 있기 때문이다.