"다량의 정보를 요구하는 지식 기반의 문제 해결 업무에 있어서는 개개인의 단순 집합체 형태보다 응집력 강한 팀 형태로 업무를 수행하는 편이 훨씬 효과적이라는 사실"
개개인의 조합보다는 팀으로서 어떻게 하면 제대로 활동하고 성과를 낼 수 있을지에 대한 프레임을 제공하면서 그 근간에는 인지부하를 두고 있다.
4가지 팀의 유형과(스트림 정렬팀, 난해한 하위시스템 팀, 플랫폼 팀, 활성화 팀)
각 팀간의 협력 관계를 설명하는 3가지 유형(협력, 엑스 애즈 어 서비스, 촉진)으로 제시하는 프레임을 통해
팀의 역할과 그 관계들을 정의한다.
어떻게 하면 최대한 협력해야 하는 구성원들과 최대한 분리되서 각팀끼리 일해야 하는 구조를 만드는 것과
구성된 토폴로지에서 발생되는 문제들을 어떻게 지속적으로 개선하는 것이
책에서 이야기하는 토폴로지의 핵심일 것이다.
책을 읽으면서 팀이 아닌 하나의 팀 안에서도 동일한 방식으로 협력관계를 만들어 낼 수 있을지에 대한 고민이 생겼고, 한번 쯤은 시도해봐야 할 것 같다.
팀 토폴로지의 목적은 역동적 협업이 필요한 장소와 시점을 식별하고, 그런 상황에 조직이 적응하는 데 적합한 접근 방식과 정신적 도구를 제공하는 것이다. 또한, 실행에 집중해야 하는 순간이나 커뮤니케이션 부하를 줄여야 하는 순간이 언제인지도 알 수 있게 돕는다.
수십 년 전부터 조직 행동 전문가들은 현대의 복잡계(complex system)에 효과적 팀 성과가 필요하다는 것을 인지했다. 특히, 드리스켈(Driskell)과 살라스(Salas)는 다량의 정보를 요구하는 지식 기반의 문제 해결 업무에 있어서는 개개인의 단순 집합체 형태보다 응집력 강한 팀 형태로 업무를 수행하는 편이 훨씬 효과적이라는 사실을 발견했다.
던바의 수에 따른 팀 규모 조정 : 조직 내 팀 구성은 던바의 수를 따른다. 약 5명(소프트웨어 팀은 8명)으로 시작해 15명, 50명, 150명, 500명 등으로 규모를 늘린다.
터크만 팀 성과 모델 (Team Performance Model)
터크만 성과 모델은 팀이 성과를 내는 형태를 4단계로 설명한다.
1. 형성기(Forming) : 처음으로 모임
2.격동기(Stoming) : 초기 구성원 사이의 개성 및 업무수행 방식 차이를 살펴봄
3.규범기(Norming) : 협업의 표준 방식을 발전시킴
4.성과기(Performing) : 높은 수준의 효과를 달성하는 상태에 이름
인지 부하라는 용어는 1988년 심리학자인 존 스웰러가 ‘업무를 기억하는 데 들이는 정신적 노력의 총량’ 이라는 표현을 한 이후 사용되기 시작했다. 스웰러는 인지 부하를 다음 세 가지로 분류한다.
- 내적 인지 부하(intrinsic cognitive load) : 문제 영역의 기본 테스크 관련 인지 부하 ( e.g. ‘자바 클래스 구조란 무엇인가?’, ‘새로운 방법은 어떻게 창출하는가?’)
- 외적 인지 부하(extraneous cognitive load) : 수행 중인 업무의 환경 관련 인지 부하 (e.g. ‘구성요소를 어떻게 재배치해야 하는가?’, ‘서비스 설정은 어떻게 해야 하는가?’)
- 관련 인지 부하(germane cognitive load) : 학습이나 높은 성과 달성 과정에서 주의해야 할 업무 관련 인지 부하 (e.g ‘이 서비스가 ABC 서비스와 어떻게 상호작용해야 하는가?’)
개발과 운영 간 마찰이 증가하면서 2009년 데브옵스 운동이 있어났다. 개발에서 애자일이 점점 주류가 되면서 운영팀에 가해지는 압박이 급격하게 커진 것이 주된 원인이었다.
애자일을 도입한 많은 조직은 소프트웨어 전달 속도와 운영팀의 역량 차이를 말끔히 해결하지 못하고 리소스를 제공하거나 소프트웨어 업데이트를 배포하려고 했다.
팀 간 불일치는 점점 분명해졌고 이는 결과적으로 업무 흐름에 좋지 않은 형태와 집중력 저하로 이어졌다.
다이앤 스트로드와 시드 허프는 2012년 그들의 논문 ‘A Taxonomy of Dependencies in Agile Software Development’에서 의존성을 지식 의존성과 업무 의존성, 자원 의존성이라는 세 가지 유형으로 분류했다.
이 분류법을 활용하면 팀 간 의존성과 업무 흐름의 잠재적 제약을 정확히 파악하는 데 도움을 받을 수 있다.
어떤 도구를 활용하든 영역별 의존성의 수를 추적하고, 특정 상황에 의미 있는 정도의 임곗값과 경계를 설정하는 것이 매우 중요하다.
확인되지 않은 의존성이 증가하도록 두면 안 된다. 만일 이런 현상이 나타나면, 팀 설계 및 의존성의 조정을 고려해야 한다.
스트림 정렬팀은 조직에서 가장 주요한 팀 유형이며 다른 팀 토폴로지를 따르는 팀들은 스트림 정렬팀의 부하를 줄이기 위해 존재한다.
활성화 팀은 스트림 정렬팀이 현재 가지고 있지 않은 역량을 획득할 수 있도록 연구나 실험을 하고, 성공적인 프랙티스를 제공하려 노력한다.
플랫폼 팀은 낮은 단계의 세부 지식(프로비저닝, 모니터링 혹은 배포 등)을 담당하고, 쉽게 사용할 수 있는 서비스를 제공함으로써 스트림 정렬팀의 인지 부하를 줄이기 위해 존재한다.
난해한 하위 시스템 팀의 목표는 복잡한 하위시스템을 포함하거나 사용하는 시스템에서 작업하는 스트림 정렬팀의 인지 부하를 줄이는 것이다.
난해한 하위시스템 팀은 일반적으로 발견하거나 습득하기 어려운 특별한 능력과 전문성을 활용해 하위시스템의 복잡성을 처리한다.
효과적 플랫폼 팀에게 어떤 행동과 결과를 기대할 수 있는가?
플랫폼 팀은 빠른 프로토타이핑 기법을 사용하며, 스트림 정렬팀 구성원들에게 무엇이 동작하고 무엇이 동작하지 않는지에 대해 신속한 피드백을 제공한다.
플랫폼 팀은 자신들이 제공하는 서비스의 사용성과 신뢰성에 집중하며, 해당 서비스가 목적에 부합하고 사용 가능한지 정기적으로 평가한다.
플랫폼 팀은 솔선수범한다. (가능하다면) 자신들이 내부적으로 제공하는 서비스를 사용해 보고, 스트림 정렬팀 및 활성화 팀과 협업하면서 가급적 하위 수준의 플랫폼(다른 플랫폼 팀이 소유한)을 소비한다.
플랫폼 팀은 신기술과 마찬가지로 내부에서 제공되는 신규 서비스 또한 그 도입이 즉각적이지 않으며, 적응 곡선에 따라 발전한다는 것을 이해한다.
좋은 사용자 경험과 개발자 경험을 세심하게 고려한 플랫폼은 강력한 사용성을 제공하며, API와 그 기능이 동작하는 방식에 일관성을 제공할 것이다. 사용법 안내와 기타 문서는 (구체적이지는 않지만) 포괄적이고,
최신 상태로 유지되며, 플랫폼의 세세한 부분까지 일일이 문서화 하는 것이 아니라 특정 태스크를 수행하도록 하는 데 집중돼야 한다.
플랫폼은 개발팀을 방해하지 않도록 시도해야 한다. 즉, 개발팀으로 하여금 팀이 어떻게 해야 하는지에 관한 사전 지식이 없더라도 필요한 것을 있도록 해야 한다.
개발자 경험을 테스트하는 좋은 방법은 신규 개발자가 플랫폼을 얼마나 쉽게 사용하는지 확인해 보는 것이다.
모든 팀은 느슨하게 결합되야 하고 스트림 변화의 흐름에 정렬되야 하며, 그들이 책임지는 제품과 서비스 및 사용자 경험에서 유용한 증분을 전달 할 수 있어야 한다.
스트림 정렬팀이 이를 달성하려면 활성화 팀(교차팀이 마주치는 장애물과 어려움을 식별하고, 새로운 접근 방식 도입을 쉽게 함), 난해한 하위시스템 팀(필요한 경우, 시스템의 특정 부분에 전문성을 반영함),
플랫폼 팀(스트림 정렬팀이 원활하게 소프트웨어 제품과 서비스를 구현하고 지원할 수 있는 기반을 제공함)에게 도움을 받아야 한다.
하위시스템 경계를 (거의 독립적인) 비즈니스 세그먼트에 맞추는 방법을 찾는 것은 훌륭한 접근법이며, 도메인 주도 설계 방식을 활용해 큰 도움을 얻을 수 있다.
그러나 이 밖에도 변화 케이던스나 리스크, 규제 준수와 같은 다양한 파단면이 있다는 것을 감지하고 주의해야 하며, 때로는 다양한 파단면들을 조합해 사용해야 한다.
3가지 핵심 팀 상호 작용 모드
소프트웨어 시스템에 팀 토폴로지 모델을 적용하는 방법과 시기를 이해하려면, 우선 팀 최우선 역동과 콘웨이의 법칙에 따라 팀이 상호 작용하고, 이때 따라야만 하는 3가지 핵심 방법을 정의하고 이해해야 한다.
- 협력 Collaboration : 다른 팀과 밀접하게 함께 일한다.
- 엑스 애즈 어 서비스 XaaS, X-as-a-Service : 최소한으로 협력하며 무언가를 소비하거나 제공한다.
- 촉진 Facilitating : 다른 팀을 돕거나 다른 팀의 도움을 받아 장애를 없앤다.
초기의 밀접한 협력은 작은 대상의 제한된 협력 형태로 발전한다. 그 과정에서의 발견은 기술과 제품에 대한 이해를 향상시키고, 제품이나 서비스 경계가 더욱 명확하게 구축되면
엑스 애즈 어 서비스 모드로 한층 더 발전한다.
소프트웨어는 점점 사용자를 위한 제품이 아니라 사용자와의 지속적 대화 개념으로 변하고 있다. 이 지속적 대화가 효과적이고 성공적으로 이뤄지려면, 소프트웨어를 지속적으로 보살펴야 한다.
소프트웨어를 설계하고 구현하는 팀은 첫 단계부터 이를 효과적으로 구현할 수 있도록 전체 운영 과정에 참여해야 한다. 이 같은 지속적 보살핌을 설계하고 운영해서 제공하는 팀은
해당 소프트웨어가 가진 상업적 지속성에 대한 책임도 일부 담당해야 한다. 그렇지 않으면 (중요한) 결정들이 재무와 동떨어진 곳에서 일어날 것이다.
참여도가 낮은 팀, 기술과 시장 변화에서 수없이 반복되는 당혹스러움, 콘웨이의 법칙 위반, 팀 규모에 비해 너무나 거대한 소프트웨어, 혼란하기 그지없는 조직 설꼐 옵션과 전달 프레임워크, 이리저리 끌려다니는 팀, 거의 매년 반복되는 고통스러운 조직 개편, 형편없는 변화의 흐름이 그러했다.
많은 조직이 소프트웨어 전달을 둘러싼 다양한 문제를 경험하는 이유는 조직 대부분이 소프트웨어 개발 본질과 동떨어진 모델을 활용하기 때문이다. 피처 전달(feature delivery)에 너무 집착하면 현대 소프트웨어에 내재한 사람과 팀의 역학 관계를 무시하게 된다. 이는 특히 구성원들의 인지 부하가 과도할 때, 그들의 참여 부족과 직결된다.
개개인의 조합보다는 팀으로서 어떻게 하면 제대로 활동하고 성과를 낼 수 있을지에 대한 프레임을 제공하면서 그 근간에는 인지부하를 두고 있다.
4가지 팀의 유형과(스트림 정렬팀, 난해한 하위시스템 팀, 플랫폼 팀, 활성화 팀)
각 팀간의 협력 관계를 설명하는 3가지 유형(협력, 엑스 애즈 어 서비스, 촉진)으로 제시하는 프레임을 통해
팀의 역할과 그 관계들을 정의한다.
어떻게 하면 최대한 협력해야 하는 구성원들과 최대한 분리되서 각팀끼리 일해야 하는 구조를 만드는 것과
구성된 토폴로지에서 발생되는 문제들을 어떻게 지속적으로 개선하는 것이
책에서 이야기하는 토폴로지의 핵심일 것이다.
책을 읽으면서 팀이 아닌 하나의 팀 안에서도 동일한 방식으로 협력관계를 만들어 낼 수 있을지에 대한 고민이 생겼고, 한번 쯤은 시도해봐야 할 것 같다.
팀 토폴로지의 목적은 역동적 협업이 필요한 장소와 시점을 식별하고, 그런 상황에 조직이 적응하는 데 적합한 접근 방식과 정신적 도구를 제공하는 것이다. 또한, 실행에 집중해야 하는 순간이나 커뮤니케이션 부하를 줄여야 하는 순간이 언제인지도 알 수 있게 돕는다.수십 년 전부터 조직 행동 전문가들은 현대의 복잡계(complex system)에 효과적 팀 성과가 필요하다는 것을 인지했다. 특히, 드리스켈(Driskell)과 살라스(Salas)는 다량의 정보를 요구하는 지식 기반의 문제 해결 업무에 있어서는 개개인의 단순 집합체 형태보다 응집력 강한 팀 형태로 업무를 수행하는 편이 훨씬 효과적이라는 사실을 발견했다.던바의 수에 따른 팀 규모 조정 : 조직 내 팀 구성은 던바의 수를 따른다. 약 5명(소프트웨어 팀은 8명)으로 시작해 15명, 50명, 150명, 500명 등으로 규모를 늘린다.터크만 팀 성과 모델 (Team Performance Model)터크만 성과 모델은 팀이 성과를 내는 형태를 4단계로 설명한다.1. 형성기(Forming) : 처음으로 모임2.격동기(Stoming) : 초기 구성원 사이의 개성 및 업무수행 방식 차이를 살펴봄3.규범기(Norming) : 협업의 표준 방식을 발전시킴4.성과기(Performing) : 높은 수준의 효과를 달성하는 상태에 이름인지 부하라는 용어는 1988년 심리학자인 존 스웰러가 ‘업무를 기억하는 데 들이는 정신적 노력의 총량’ 이라는 표현을 한 이후 사용되기 시작했다. 스웰러는 인지 부하를 다음 세 가지로 분류한다.
- 내적 인지 부하(intrinsic cognitive load) : 문제 영역의 기본 테스크 관련 인지 부하 ( e.g. ‘자바 클래스 구조란 무엇인가?’, ‘새로운 방법은 어떻게 창출하는가?’)
- 외적 인지 부하(extraneous cognitive load) : 수행 중인 업무의 환경 관련 인지 부하 (e.g. ‘구성요소를 어떻게 재배치해야 하는가?’, ‘서비스 설정은 어떻게 해야 하는가?’)
- 관련 인지 부하(germane cognitive load) : 학습이나 높은 성과 달성 과정에서 주의해야 할 업무 관련 인지 부하 (e.g ‘이 서비스가 ABC 서비스와 어떻게 상호작용해야 하는가?’)
개발과 운영 간 마찰이 증가하면서 2009년 데브옵스 운동이 있어났다. 개발에서 애자일이 점점 주류가 되면서 운영팀에 가해지는 압박이 급격하게 커진 것이 주된 원인이었다.애자일을 도입한 많은 조직은 소프트웨어 전달 속도와 운영팀의 역량 차이를 말끔히 해결하지 못하고 리소스를 제공하거나 소프트웨어 업데이트를 배포하려고 했다.팀 간 불일치는 점점 분명해졌고 이는 결과적으로 업무 흐름에 좋지 않은 형태와 집중력 저하로 이어졌다.다이앤 스트로드와 시드 허프는 2012년 그들의 논문 ‘A Taxonomy of Dependencies in Agile Software Development’에서 의존성을 지식 의존성과 업무 의존성, 자원 의존성이라는 세 가지 유형으로 분류했다.이 분류법을 활용하면 팀 간 의존성과 업무 흐름의 잠재적 제약을 정확히 파악하는 데 도움을 받을 수 있다.어떤 도구를 활용하든 영역별 의존성의 수를 추적하고, 특정 상황에 의미 있는 정도의 임곗값과 경계를 설정하는 것이 매우 중요하다.확인되지 않은 의존성이 증가하도록 두면 안 된다. 만일 이런 현상이 나타나면, 팀 설계 및 의존성의 조정을 고려해야 한다.스트림 정렬팀은 조직에서 가장 주요한 팀 유형이며 다른 팀 토폴로지를 따르는 팀들은 스트림 정렬팀의 부하를 줄이기 위해 존재한다.활성화 팀은 스트림 정렬팀이 현재 가지고 있지 않은 역량을 획득할 수 있도록 연구나 실험을 하고, 성공적인 프랙티스를 제공하려 노력한다.플랫폼 팀은 낮은 단계의 세부 지식(프로비저닝, 모니터링 혹은 배포 등)을 담당하고, 쉽게 사용할 수 있는 서비스를 제공함으로써 스트림 정렬팀의 인지 부하를 줄이기 위해 존재한다.난해한 하위 시스템 팀의 목표는 복잡한 하위시스템을 포함하거나 사용하는 시스템에서 작업하는 스트림 정렬팀의 인지 부하를 줄이는 것이다.난해한 하위시스템 팀은 일반적으로 발견하거나 습득하기 어려운 특별한 능력과 전문성을 활용해 하위시스템의 복잡성을 처리한다.효과적 플랫폼 팀에게 어떤 행동과 결과를 기대할 수 있는가?플랫폼 팀은 빠른 프로토타이핑 기법을 사용하며, 스트림 정렬팀 구성원들에게 무엇이 동작하고 무엇이 동작하지 않는지에 대해 신속한 피드백을 제공한다.플랫폼 팀은 자신들이 제공하는 서비스의 사용성과 신뢰성에 집중하며, 해당 서비스가 목적에 부합하고 사용 가능한지 정기적으로 평가한다.플랫폼 팀은 솔선수범한다. (가능하다면) 자신들이 내부적으로 제공하는 서비스를 사용해 보고, 스트림 정렬팀 및 활성화 팀과 협업하면서 가급적 하위 수준의 플랫폼(다른 플랫폼 팀이 소유한)을 소비한다.플랫폼 팀은 신기술과 마찬가지로 내부에서 제공되는 신규 서비스 또한 그 도입이 즉각적이지 않으며, 적응 곡선에 따라 발전한다는 것을 이해한다.좋은 사용자 경험과 개발자 경험을 세심하게 고려한 플랫폼은 강력한 사용성을 제공하며, API와 그 기능이 동작하는 방식에 일관성을 제공할 것이다. 사용법 안내와 기타 문서는 (구체적이지는 않지만) 포괄적이고,최신 상태로 유지되며, 플랫폼의 세세한 부분까지 일일이 문서화 하는 것이 아니라 특정 태스크를 수행하도록 하는 데 집중돼야 한다.플랫폼은 개발팀을 방해하지 않도록 시도해야 한다. 즉, 개발팀으로 하여금 팀이 어떻게 해야 하는지에 관한 사전 지식이 없더라도 필요한 것을 있도록 해야 한다.개발자 경험을 테스트하는 좋은 방법은 신규 개발자가 플랫폼을 얼마나 쉽게 사용하는지 확인해 보는 것이다.모든 팀은 느슨하게 결합되야 하고 스트림 변화의 흐름에 정렬되야 하며, 그들이 책임지는 제품과 서비스 및 사용자 경험에서 유용한 증분을 전달 할 수 있어야 한다.스트림 정렬팀이 이를 달성하려면 활성화 팀(교차팀이 마주치는 장애물과 어려움을 식별하고, 새로운 접근 방식 도입을 쉽게 함), 난해한 하위시스템 팀(필요한 경우, 시스템의 특정 부분에 전문성을 반영함),플랫폼 팀(스트림 정렬팀이 원활하게 소프트웨어 제품과 서비스를 구현하고 지원할 수 있는 기반을 제공함)에게 도움을 받아야 한다.하위시스템 경계를 (거의 독립적인) 비즈니스 세그먼트에 맞추는 방법을 찾는 것은 훌륭한 접근법이며, 도메인 주도 설계 방식을 활용해 큰 도움을 얻을 수 있다.그러나 이 밖에도 변화 케이던스나 리스크, 규제 준수와 같은 다양한 파단면이 있다는 것을 감지하고 주의해야 하며, 때로는 다양한 파단면들을 조합해 사용해야 한다.3가지 핵심 팀 상호 작용 모드소프트웨어 시스템에 팀 토폴로지 모델을 적용하는 방법과 시기를 이해하려면, 우선 팀 최우선 역동과 콘웨이의 법칙에 따라 팀이 상호 작용하고, 이때 따라야만 하는 3가지 핵심 방법을 정의하고 이해해야 한다.
- 협력 Collaboration : 다른 팀과 밀접하게 함께 일한다.
- 엑스 애즈 어 서비스 XaaS, X-as-a-Service : 최소한으로 협력하며 무언가를 소비하거나 제공한다.
- 촉진 Facilitating : 다른 팀을 돕거나 다른 팀의 도움을 받아 장애를 없앤다.
초기의 밀접한 협력은 작은 대상의 제한된 협력 형태로 발전한다. 그 과정에서의 발견은 기술과 제품에 대한 이해를 향상시키고, 제품이나 서비스 경계가 더욱 명확하게 구축되면엑스 애즈 어 서비스 모드로 한층 더 발전한다.소프트웨어는 점점 사용자를 위한 제품이 아니라 사용자와의 지속적 대화 개념으로 변하고 있다. 이 지속적 대화가 효과적이고 성공적으로 이뤄지려면, 소프트웨어를 지속적으로 보살펴야 한다.소프트웨어를 설계하고 구현하는 팀은 첫 단계부터 이를 효과적으로 구현할 수 있도록 전체 운영 과정에 참여해야 한다. 이 같은 지속적 보살핌을 설계하고 운영해서 제공하는 팀은해당 소프트웨어가 가진 상업적 지속성에 대한 책임도 일부 담당해야 한다. 그렇지 않으면 (중요한) 결정들이 재무와 동떨어진 곳에서 일어날 것이다.참여도가 낮은 팀, 기술과 시장 변화에서 수없이 반복되는 당혹스러움, 콘웨이의 법칙 위반, 팀 규모에 비해 너무나 거대한 소프트웨어, 혼란하기 그지없는 조직 설꼐 옵션과 전달 프레임워크, 이리저리 끌려다니는 팀, 거의 매년 반복되는 고통스러운 조직 개편, 형편없는 변화의 흐름이 그러했다.많은 조직이 소프트웨어 전달을 둘러싼 다양한 문제를 경험하는 이유는 조직 대부분이 소프트웨어 개발 본질과 동떨어진 모델을 활용하기 때문이다. 피처 전달(feature delivery)에 너무 집착하면 현대 소프트웨어에 내재한 사람과 팀의 역학 관계를 무시하게 된다. 이는 특히 구성원들의 인지 부하가 과도할 때, 그들의 참여 부족과 직결된다.
.jpeg)
