팀 토폴로지

 

"다량의 정보를 요구하는 지식 기반의 문제 해결 업무에 있어서는 개개인의 단순 집합체 형태보다 응집력 강한 팀 형태로 업무를 수행하는 편이 훨씬 효과적이라는 사실"

개개인의 조합보다는 팀으로서 어떻게 하면 제대로 활동하고 성과를 낼 수 있을지에 대한 프레임을 제공하면서 그 근간에는 인지부하를 두고 있다.

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년 심리학자인 존 스웰러가 ‘업무를 기억하는 데 들이는 정신적 노력의 총량’ 이라는 표현을 한 이후 사용되기 시작했다. 스웰러는 인지 부하를 다음 세 가지로 분류한다.

1. 내적 인지 부하(intrinsic cognitive load) : 문제 영역의 기본 테스크 관련 인지 부하 ( e.g. ‘자바 클래스 구조란 무엇인가?’, ‘새로운 방법은 어떻게 창출하는가?’)
2. 외적 인지 부하(extraneous cognitive load) : 수행 중인 업무의 환경 관련 인지 부하 (e.g. ‘구성요소를 어떻게 재배치해야 하는가?’, ‘서비스 설정은 어떻게 해야 하는가?’)
3. 관련 인지 부하(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)에 너무 집착하면 현대 소프트웨어에 내재한 사람과 팀의 역학 관계를 무시하게 된다. 이는 특히 구성원들의 인지 부하가 과도할 때, 그들의 참여 부족과 직결된다. 

데이터 쓰기의 기술

 

"데이터를 잘 다룰 수 없다면 손으로 적어서라도 비교할 수 있는 판을 만들어보자."

데이터를 한번도 안써본 사람이라면, 어떻게 연습하는 것이 좋을까?

이에 대한 필자의 생각은 7가지 단계를 연습함으로 가능하다고 이야기 한다.

각 단계에 대해 설명하고 다수의 예시를 통해 이런 과정을 이해시키고 있다.

데이터를 분석하는 과정을 실 예시들을 통해 간단히 살펴보기에 좋다. 

데이터 전문 조직에서 제언을 할 때, 지나치게 일반적인 내용을 제시하면 실행할 만한 인사이트가 없고, 지나치게 구체적인 방향성을 제시하면 현장 전문가들의 의견을 배제하는 것처럼 보인다. 그 중간쯤, 현장에서 활용할 수 있으면서도 구체적인 제언을 해야 한다.

데이터 비전문가에게는 시계열 단위로 이리저리 쪼개어 매출을 분석하기를 권한다. 최대한 작은 단위, 즉 ‘연월일시분초’까지 있으면 가장 좋은데, 분 단위 이하는 관리하기가 어려울 수 있으니 시간 단위까지라도 매출을 집계해 확보하는 것이 좋다. 그 시간에 어떤 제품이 팔려서 그 매출이 확보되었는지도 시간별로 정리해보는 것이 필요하다. 데이터를 잘 다룰 수 없다면 손으로 적어서라도 비교할 수 있는 판을 만들어보자.

소비자의 마음은 날씨에 따라 달라진다. -> 한겨울 퇴근시간, 편의점에서는 왜 칼로리 높은 식품이 잘 팔릴까?

소비자의 마음은 가끔 거짓말을 한다. -> 소풍용 돗자리를 30대 남성들이 사간 이유는?

데이터 디자인

1.질문하기 : 궁금한 것이 있어야 데이터 분석이 시작된다.

2.문장 쪼개기 : 비전문가에게 가장 유용한 사고방식 훈련

3.데이터 찾기 : 어디서 어떻게 데이터를 확보할 것인가

4.데이터 분석하기 : 관점을 세우고 작은 것부터 시작한다.

데이터 스토리텔링

5.데이터 퍼즐 맞추기 : 낱낱의 분석을 모아 인사이트를 만든다

6.변화를 만들 제언하기 : 스토리로 방향을 제시한다

7.데이터에 옷 입히기 : 청자에 맞추어 스토리를 공유한다.

데이터 디자인 1단계 질문하기

왜 시험 기간에 샷 추가를 많이 할까? 시험 기간이 되었으니 잠을 깨우기 위해서일까? 그냥 카페인이 엄청나게 많이 든 에너지 음료를 팔면 어떨까?

데이터 디자인 2단계 문장 쪼개기

왜 시험 기간에 : 시험 기간이라서 그런 걸까? 혹시 시험이 아니라, 이달에만 그런 건 아닐까? 샷 추가 커피 판매가 학기별로 중간고사, 기말고사 기간과 맞물리는가?

샷추가를 : 샷 추가란, 기존에 추가하지 않던 사람이 샷을 추가하는 것을 말하는 걸까? 아니면 진한 커피를 마시는 사람들이.. 

데이터 문해력

 

"데이터 작업 전에 애당초 무슨 말을 하고 싶은지를 생각해보고 이에 필요한 데이터를 활용해 작업을 진행하는 접근 방식"

책 처음부터 끝까지 한가지 내용을 이야기하고 있다.

데이터라 함은 그 목적에 따라 어떤 데이터를 볼 것인지 어떤 방식으로 볼지를 결정해야 하고 결과가 아닌 결론과 향후 액션이 도출될수 있어야 한다. 그렇기 때문에, 데이터를 먼저 모으는 것이 먼저가 아닌 해결하고 싶은 가설이 먼저 이뤄져야 한다.

데이터 분석이란 말을 하기 전에 무슨 문제를 풀고 싶은건지에 대한 질문에 대한 답을 먼저하자. 

“이 그래프를 통해 무엇을 말할 수 있을까요?”가 아니라,

“이 그래프를 작성한 사람은 (그래프 작성 전에) 무엇을 말하고 싶었을까요?” 입니다. 

전자는 ‘데이터와 그래프 중심의 사고’를 전제로 한 질문으로, 누군가가 만든 데이터와 그래프를 읽어내는 것만 추구하는 것

후자는 ‘목적 사고력’이라 할 수 있습니다. 데이터 작업 전에 애당초 무슨 말을 하고 싶은지를 생각해보고 이에 필요한 데이터를 활용해 작업을 진행하는 접근 방식입니다. 필자가 목표로 하는 데이터 문해력이란 바로 후자에 해당합니다.

데이터가 여러분에게 직접적인 답을 주는 경우는 없습니다. 설령 아무리 고난도의 통계와 분석 방법을 구사하더라도 말입니다. 

대신, ‘당신이 무엇을 알고 싶은지, 이를 알게 되면 무엇을 하고 싶은지, 이를 위해서는 어떤 데이터(지표)가 필요한지’ 이를 구체적으로 생각하는 것이 무엇보다도 중요합니다.

‘문제’란 수주 수가 급감했다. 이며, 그 ‘원인’은 ‘고객 상담 및 대응 부실’일 것입니다. 그러면, 원인에 대한 ‘해결방안’은 ‘효과적이고 효율적인 영업 활동’이라는 구조가 성립됩니다. 어떤 것이 옳고 그른 것인가 따지지 말고, 일단 머릿속으로 이러한 삼자 관계를 정리하고 이해할 필요가 있습니다. 그리고 무엇을 ‘문제’로 삼고, 어떤 데이터를 활용할지 결정해가는 것이 중요합니다.

목적 및 문제 (무슨 말을 하고 싶은가, 말해야 하는가) - 둘 이상의 해석이 나오지 않도록, 구체적으로 표현하고 정의하였는가?

—> 데이터 및 지표

가치 있는 정보란 무엇인가? 

구체적인 행동을 특정할 수 있다. (누가 언제 무엇을 했는지), 구체적인 판단을 내릴 재료가 된다.

위 그래프가 ‘편차가 크다(=표준편차가 크다)’, 아래 그래프가 ‘편차가 작다(=표준편차가 작다)’고 할 수 있습니다. 표준편차의 크기는 데이터의 최솟값에서 최댓값의 차이가 아니라 데이터 대다수가 존재하는 범위의 폭을 의미한다는 점을 이해해주시기 바랍니다. 최솟값과 최댓값 같은 극단적인 값에 전체 편차는 영향받지 않으며 대다수의 데이터가 분포된 범위를 나타낸다는 장점이 있습니다.

‘간극 본능(The Gap Instinct)’에 의한 함정을 소개하고 있습니다. 

즉, 인간은 누구나 ‘좋다/나쁘다’, ‘높다/낮다’, ‘크다/작다’ 등 2가지 이상으로 ‘편 가르기’를 하고 그 차이를 구분하려 합니다. 그리고 그 차이를 클로즈업하면 알기 쉬운 결론으로 이어지기 때문에 이 방법을 자주 사용하게 됩니다. 하지만, 이는 어디까지나 작업자나 분석자 자신이 그어놓은 선으로 그룹을 구분했기에 나온 차이이며, 그 그룹의 특징을 단적으로 나타낸 평균 등의 지표가 꼭 그룹 전체를 대표한다고는 볼 수 없습니다. 그 지표에서 나타나지 않은 다른 부분들 또한 무시할 수 없는 것입니다.

“당신이 현재 직면하고 있는 문제나 그 배경에 대해 전혀 모르는 제 3자가 바로 앞에 있다고 상상하세요. 그 사람에게 당신이 다루는 문제를 데이터로 설명하려면 무슨 데이터를 어떻게 보여주면 좋을까요?” 상대방이 그 데이터를 보고 나서, “그렇군요! 확실히 문제가 있네요.!” 라고 말한다면 성공한 것입니다.

원인 후보를 이끌어 내는 방법과 지표를 특정하는 방식

1. 원인 후보를 열거한다. 2. 지표를 결정한다. 3. 관련성을 확인한다.

마법 같은 정답은 없지만, 필자가 생각하는 최선의 접근 방식은 ‘논리적 사고(로지컬 씽킹)’입니다. 여기서 말하는 ‘논리적 사고’란 문제를 구조화하고 정리하면서 생각하는 것을 가리킵니다.