주제 7.0 — 팀 구조, 역할 및 책임

한 문장으로: 디지털 보건 딜리버리의 성패는 팀 사이의 경계를 어떻게 긋고 누가 무엇을 하는지 얼마나 분명히 명명하느냐에 달려 있으므로, 가치의 빠르고 안전한 흐름을 위해 팀을 구조화하고, 다학제로 인력을 배치하며, 책임을 명시하라.

보건·돌봄에서 이것이 중요한 이유#

팀을 조직하는 방식이 곧 서비스가 행동하는 방식이 된다. 시스템의 설계가 그것을 만든 조직의 소통 구조를 반영한다는 **콘웨이의 법칙**은 보건·돌봄에서 호기심거리가 아니라 환자 안전의 위험이다. 파편화된 팀은 파편화된 진료 기록, 취약한 통합, 임상 위험이 숨는 인계를 낳는다.

NHS와 사회적 돌봄에서는 공적 자금을 쓰고 법정 의무도 진다. DCB0129/DCB0160에 따른 임상 안전, UK GDPR과 기밀 유지의 관습법상 의무에 따른 정보 거버넌스, 접근성 의무다. 이러한 의무는 마지막에 덧붙일 수 없다. 이를 이행할 권한과 시간을 가진 지정된 사람들이 팀 안에 대표되어야 한다.

구조를 바르게 하면 다학제 팀이 임상의가 신뢰하고 환자가 쓸 수 있는 작동하는 소프트웨어를 내놓는다. 잘못하면 바쁜 전문가들이 자기 사일로를 최적화하는 동안 서비스 전체는 정체된다. 늦고, 예산을 초과하고, 조용히 방치되는 디지털 프로그램의 전형적 패턴이다.

핵심 개념#

다학제 팀(MDT). 디지털 딜리버리 팀은 끊임없는 외부 의존 없이 서비스를 설계하고, 구축하고, 운영하는 데 필요한 모든 분야를 포함해야 한다. 제품, 딜리버리, 디자인, 리서치, 엔지니어링, 데이터, 임상 및 거버넌스 관점이다. 이는 직원들이 이미 아는 임상 MDT 개념, 곧 혼합된 전문성과 성과에 대한 공유된 책임을 반영한다.

팀 토폴로지. 효과적인 팀 설계를 네 가지 근본 유형과 세 가지 상호작용 방식으로 줄이는 모델(Skelton & Pais)로, 모두 가치의 빠른 흐름을 위한 것이다.

• 스트림 정렬 팀 — 가치 있는 단일 업무 흐름(서비스, 사용자 여정, 제품) 주위로 조직되어 이를 종단 간 소유한다. 기본 팀 유형이며, 대부분의 사람은 여기에 속해야 한다.
• 플랫폼 팀 — 스트림 정렬 팀이 처음부터 다시 만들 필요 없이 더 빨리 가도록 내부 셀프서비스 역량(공유 인프라, 통합 엔진, 로그인 서비스, 공유 진료 기록 API)을 제공한다.
• 지원 팀 — 다른 이들이 역량을 키우도록 코칭하고 물러나는, 기간이 정해진 전문가 팀(예: 임상 안전, 접근성, 테스트 자동화).
• 복잡한 하위 시스템 팀 — 범용 팀에 과부하를 줄 깊은 전문 지식이 필요한 부분(위험 점수 알고리즘, NHS Spine 인터페이스)을 소유한다.

세 가지 상호작용 방식은 어떤 두 팀이 어떻게 관계하는지를 규정한다. 협업(정해진 기간 동안 긴밀히 일하며, 대역폭이 높고, 무언가를 발견하려고 약간의 비효율을 용인), 서비스형 X(한 팀이 다른 팀의 역량을 최소한의 번거로움으로 소비, 규모에서의 저마찰 기본값), 촉진(한 팀이 다른 팀의 학습을 도움)이다. 방식을 명명하면 지연과 비난을 낳는 모호함을 막을 수 있다.

인지 부하. 팀은 머릿속에 담을 수 있는 양에 한계가 있다. 팀 토폴로지는 각 팀이 소유하는 도메인을 안전하게 추론할 수 있는 범위로 제한해야 한다고 주장한다. 도메인이 임상적일 때 결정적인 원칙이다.

콘웨이의 법칙과 역 콘웨이 기동. 아키텍처가 조직 구조를 따르므로 — 팀과 기술을 하나의 설계로 다루는 사회기술 시스템 관점 — 원하는 아키텍처를 낳도록 팀을 의도적으로 형성하라. 모듈식이고 상호운용 가능한 진료 기록을 원한다면, 하나의 거대한 팀으로 만들지 말라.

모범 사례#

1. 각 서비스 주위에 완전한 다학제 팀을 배치하라. 최소한 제품 관리자, 딜리버리 관리자, 사용자 리서처, 서비스/인터랙션 디자이너, 엔지니어, 데이터/분석 역량에 더해 지정된 임상 안전 및 정보 거버넌스 투입을 포함하라. 한 분야가 빠진 팀은 다른 누군가를 기다리거나 그 일을 건너뛴다. 그리고 보건에서 건너뛴 일은 보통 안전, 접근성, 거버넌스다.

2. 대부분의 팀을 스트림 정렬로 만들고 종단 간 소유권을 주라. 기술 계층(예: "데이터베이스 팀")이 아니라 사용자의 여정(예: "외래 의뢰")을 중심으로 조직하라. 종단 간 소유권은 피드백 고리를 단축하고 임상 위험이 쌓이는 인계의 틈을 없앤다.

3. 플랫폼을 제품으로 구축하고, 서비스로 소비되게 하라. 통합 엔진, 신원 서비스, 공유 진료 기록 API를 자체 팀, 로드맵, 사용자가 있는 내부 제품으로 다루라. 스트림 정렬 팀이 티켓을 올리고 기다리지 않고 스스로 쓰도록 "서비스형"으로 공개하라.

4. 희소한 전문성을 쌓아 두지 말고 퍼뜨리는 데 지원 팀을 쓰라. 임상 안전 책임자, 접근성 전문가, 보안 엔지니어는 드물다. 모든 팀이 줄 서는 영구적 병목이 되기보다, 딜리버리 팀을 더 높은 표준으로 코칭하고 떠나도록 배치하라.

5. 모든 역할과 그 결정권을 명시적으로 명명하라. 임상 안전 승인, 가동, 정보 거버넌스 승인, 지출처럼 중요한 결정에는 RACI(실행 책임, 최종 책임, 자문, 통보)나 더 단순한 "결정자/조언자" 구분 같은 책임 모델을 쓰라. 여기서의 모호함이 책임이 증발하는 곳이다.

6. 임상 안전 책임자에게 실제 권한과 실제 시간을 주라. DCB0129/0160은 릴리스를 멈출 수 있는 지정되고 적절히 교육받은 임상 안전 책임자를 요구한다. 팀 안에서 역할을 명시하고, 시간을 보호하며, 아니라고 말할 수 있게 하라. 이름뿐인 CSO는 사고로 발견되기를 기다리는 거버넌스 실패다.

7. 도메인에 경계를 두어 인지 부하를 관리하라. 팀이 너무 많은 서비스나 너무 복잡한 임상 도메인을 소유하면 나누라. 신호를 살피라. 자기 변경의 안전 영향을 더는 자신 있게 설명하지 못하는 팀은 과부하 상태다.

8. 역 콘웨이 기동을 의도적으로 적용하라. 원하는 아키텍처와 상호운용성에 맞게 팀 경계를 그으라. 모듈식이고 표준 기반(예: HL7 FHIR)의 시스템에는 모듈식 팀이다. 우연한 조직도가 진료 기록을 대신 설계하게 두지 말라.

팀과 논의할 질문#

1. 현재의 조직도가 이미 우리 아키텍처를 대신 설계하고 있는 곳은 어디이며 — 그것이 우리가 실제로 원하는 아키텍처인가? 콘웨이의 법칙은 선택이 아니다. 팀의 모양이 어떠하든 시스템은 그것을 닮게 되므로, 정직한 첫 수는 이미 가진 진료 기록, 통합, 인계를 보고 어느 팀 경계가 각 이음새를 낳았는지 묻는 것이다. 보건·돌봄 환경에서 그 이음새는 임상 위험이 숨는 곳이다. 파편화된 기록, 취약한 Spine 인터페이스, 어느 단일 팀도 소유하지 않는 안전 케이스다. 따라서 이것은 미적 논의가 아니라 환자 안전의 대화다. 토론할 긴장은 원하는 아키텍처를 얻으려고 팀 경계를 다시 긋는 것(역 콘웨이 기동)이 혼란스럽고, 기존의 영역을 위협하며, 우리가 완전히 통제하지 못할 수 있는 재원 및 라인 관리 구조를 가로지른다는 점이다. 가장 고통스러운 통합 두세 개를 각 끝을 소유한 팀으로 거슬러 매핑하고, 스트림 정렬 경계가 인계를 아예 없앴을지 물어보라. 좋은 답은 옮길 구체적 경계를 최소한 하나 명명하고, 누가 왜 저항할지 솔직하며, 혼란을 감수할 가치가 있는 변화와 서비스형 인터페이스가 더 싸게 마찰을 해결할 변화를 구별한다.

2. 임상 안전, 정보 거버넌스, 접근성 같은 희소한 전문가는 실제 권한을 지니고 팀 안에 있는가, 아니면 모두가 줄 서는 외부 관문인가? 이 가족의 모든 서비스는 마지막에 덧붙일 수 없는 법정 의무(DCB0129/0160 임상 안전, UK GDPR과 기밀 유지의 관습법상 의무, 접근성 법)를 지지만, 이 역량은 희귀하고 비싸서 조직을 중앙에 쌓아 두는 쪽으로 끌어당긴다. 상충 관계는 진짜다. 모든 팀에 임상 안전 책임자를 두면 얇은 전문성이 희석될 때까지 퍼지고, 중앙화하면 한 사람이 모든 것에 자문되고 모든 릴리스가 기다리는 영웅적 병목이 생긴다. 팀이 자체 위험 요소 워크숍을 운영하도록 코칭하고 물러나는 기간이 정해진 전문가라는 지원 팀 패턴이 제안된 해결책이지만, 리더십이 전문가들의 시간을 직접 하는 것이 아니라 가르치는 데 보호할 때만 작동한다. 자신의 릴리스 이력을 정직하게 보라. 가동이 지정된 한 사람을 기다리느라 몇 번 미뤄졌고, 그 사람에게 안전하게 아니라고 말할 권한과 보호된 시간이 있었는가? 강한 답은 희소성을 정면으로 마주하고, 각 의무에 대해 내재화 대 지원에 대한 의도적 입장을 고르며, 역량을 어떻게 퍼뜨리든 결코 희석되어서는 안 되는 구체적 권한(릴리스를 멈출 힘)을 명명한다.

3. 팀이 안전하게 질 수 있는 것보다 더 많은 인지 부하를 졌는지 어떻게 알 수 있으며 — 그것에 대해 실제로 무엇을 하겠는가? 인지 부하는 안전한 딜리버리의 조용한 통제자다. 팀은 자기 변경의 안전 영향에 대한 확신이 침식되기 시작하기 전까지 추론할 수 있는 임상 도메인과 서비스의 양에 한계가 있으며, 보건에서 그 침식은 사고가 드러내기 전까지 보이지 않는다. 어려움은 과부하가 좀처럼 스스로를 알리지 않는다는 점이다. 약간 느린 딜리버리, 더 많은 결함, 더 많은 "누구에게 확인해 볼게"로 보이고, 압박받는 팀은 특히 팀을 나누는 것이 정치적으로 비싸거나 인원이 동결되었을 때 표시하기보다 흡수하는 경향이 있다. 조기 경보 신호가 무엇일지(자기 릴리스의 안전 케이스를 더는 자신 있게 설명하지 못하는 팀은 강한 신호다), 딜리버리가 눈에 띄게 정체되기 전에 과부하를 드러낼 기제가 오늘 있는지 토론하라. 반대 압력도 고려하라. 팀을 나누면 새 경계와 인계가 생기므로, 치료가 질문 1의 파편화 위험을 다시 들여올 수 있다. 정직한 답은 막연한 "느낌으로 알 것"이 아니라 구체적이고 관찰 가능한 신호에 합의하고, 팀의 도메인에 경계를 두거나 나눌 권한이 누구에게 있는지 명명하며, 부하 경감과 경계 증식 사이의 상충 관계를 인정한다.

4. 우리의 공유 역량 중 어느 것을 서비스로 소비되는 플랫폼으로 운영해야 하며, 실제로 그렇게 자원을 대고 있는가 — 아니면 티켓 대기열의 이름만 바꾸고 있는가? 플랫폼 팀의 약속은 스트림 정렬 팀이 티켓을 올리고 기다리지 않고 통합 엔진, 신원 서비스, 공유 진료 기록 API를 스스로 쓰게 되어 시스템 전체가 더 빨라진다는 것이다. 실패는 모두가 여전히 줄 서는 인력 부족의 중앙 기능인데 "플랫폼"이라 부르는 것이다. 상충 관계는 진짜다. 역량을 진정한 내부 제품으로 구축한다는 것은 자체 팀, 로드맵, 문서, 사용자를 준다는 뜻이고, 이는 사용자 대면 기능을 내놓는 것과 경쟁하는 진지한 투자이며 현금이 제한된 NHS 환경에서 무기한 미루기 쉽다. 보건·돌봄에서는 공유 역량이 흔히 안전이 중요한 것들이어서 위험이 더 날카롭다. 개인 매칭 인덱스, FHIR 인터페이스, 감사 추적이며, 얇은 플랫폼 팀은 그 위의 모든 서비스에 대한 단일 장애점이 된다. 이미 여러 팀이 의존하는 역량을 보고 각각에 대해 그 상호작용이 진정한 저마찰 서비스형 X인지 숨은 대기가 있는 위장된 협업인지 물어보라. 정직한 답은 어떤 역량이 지금 플랫폼 투자를 정당화하고 어떤 것이 나중인지 명명하고, 누가 재원을 대고 인력을 배치하는지 분명히 하며, 제품 책임자도, 로드맵도, 셀프서비스 경로도 없는 플랫폼을 선언하려는 유혹에 저항한다.

5. 계약 공급업체나 빌려 온 직원에 의존하는 곳은 어디이며, 속이 빈 고객이 아니라 지능형 고객으로 남으려면 어떤 역할을 사내에 두어야 하는가? 보건·돌봄의 많은 디지털 딜리버리는 외주되며, 공급업체는 역량과 전문성을 빠르게 가져올 수 있다. 그러나 제품 소유권, 기술 보증, 임상 안전 승인이 모두 계약과 함께 건물을 떠나면, 조직은 자신이 팔리는 것을 판단하고, 필요한 것을 명세하고, 결과를 안전하게 소유할 능력을 잃는다. 긴장은 속도와 역량 사이에 있다. 인력 보강과 턴키 구축은 무언가를 빨리 라이브로 만들지만, 공급업체에 책임을 물을 수 있게 하는 사내 근육을 조용히 침식할 수 있고, 성과를 소유하는 스트림 정렬 팀이 아니라 구성 요소 모양에 인계가 많은 구조를 전달하는 경우가 많다. 이 분야에서 양보할 수 없는 유지 역할은 위임할 수 없는 책임 주위에 모인다. 고위 책임 소유자, 가동을 승인하는 임상 안전 책임자, 우선순위를 정하는 제품 책임자, 공급업체가 만든 것을 점검할 충분한 기술 보증이다. 현재의 딜리버리를 살피고 공급업체가 내일 떠나면 어떤 역량을 재구성할 수 없을지 물어보라. 좋은 답은 진정으로 계약해도 좋은 업무와 사내에 남아야 하는 지능형 고객의 핵심을 구별하고, 계약 팀이 인력 파견이 아니라 성과 소유를 지도록 요구하며, 항상 우리 자신의 책임 있는 사람들에게 있어야 하는 안전 및 거버넌스 결정을 명명한다.

6. 우리 팀 구조가 빠르고 안전한 가치 흐름을 실제로 만들어 내는지 어떻게 알 수 있으며 — 무엇이 우리가 구조를 다시 그리게 만들 것인가? 팀 설계는 목적이 아니라 수단이다. 스트림 정렬 팀, 플랫폼, 명명된 상호작용 방식의 요점은 가치를 더 빠르고 안전하게 전달하는 것이지만, 조직은 구조가 그것을 전달하는지 계측하는 일이 드물어서 조직 개편이 증거가 아니라 정치와 직관으로 일어난다. 어려움은 조작되지 않으면서 흐름과 안전을 반영하는 신호를 고르는 것이다. 원시 속도나 스토리 포인트 처리량은 잘못된 행동을 부르고, 흐름 지표(아이디어에서 라이브까지의 리드 타임, 배포 빈도, 변경당 인계 횟수)와 안전 지표(위험 요소가 얼마나 빨리 종결되는지, 팀이 자체 안전 케이스를 소유하는지)가 경계가 돕는지 해치는지 더 많이 알려 준다. 안정성과 진정한 긴장이 있다. 끊임없는 개편은 딜리버리를 안전하게 만드는 팀의 지속성과 공유된 인지 공간을 파괴하므로, 경계를 다시 긋기 전에 높은 기준과 분명한 계기가 필요하다. 어떤 증거가 경계가 잘못되었음을 알려 줄지 — 지속적인 팀 간 대기, 어느 단일 팀도 소유하지 않는 안전 케이스, 아무도 스스로 쓰지 않는 플랫폼 — 그리고 누가 그에 따라 조치할 권한이 있는지 논의하라. 정직한 답은 실제로 지켜볼 소수의 흐름 및 안전 신호를 약속하고, 팀 안정성을 보호하는 의도적 임계를 정하며, 미래의 재구성에 대한 계기 조건과 결정권자를 명명한다.

실제 사례: 보건·돌봄 예시#

한 통합 돌봄 시스템(ICS)이 급성기, 지역사회, 정신건강, 일차 진료, 사회적 돌봄 전반에 공유 진료 기록을 배포하고 있다.

본능은 하나의 큰 "공유 진료 기록 팀"을 만드는 것이다. 대신 ICS는 팀 토폴로지를 적용한다. 플랫폼 팀이 공유 기록의 핵심, 곧 개인 매칭 인덱스, FHIR API, 통합 엔진을 소유하며 셀프서비스 역량으로 공개한다. 여러 스트림 정렬 팀이 그 위에서 각각 실제 사용자 여정 — "응급실에서 환자 기록 보기", "사회복지사 안전보호 시야", "일반의 투약 조정" — 을 소유하고 플랫폼을 서비스로 소비한다. 복잡한 하위 시스템 팀은 거짓 일치가 진정한 안전 사건인 확률적 환자 매칭 알고리즘을 소유한다. 임상 안전 및 접근성 전문가로 이뤄진 지원 팀은 스트림 정렬 팀을 돌아가며 코칭하여, 대신 해 주는 대신 팀이 자체 DCB0160 위험 요소 워크숍을 운영하게 한다.

각 팀에는 지정된 제품 관리자, 딜리버리 관리자, 임상 안전 책임자가 있고, RACI는 가동이 고위 책임 소유자에게 최종 책임이 있지만 CSO와 정보 거버넌스 승인 없이는 진행할 수 없음을 분명히 한다. 응급실 팀이 새 데이터 필드가 필요할 때 상호작용 방식은 명시적이다. 6주의 협업이 아니라 문서화된 API 요청을 통해 플랫폼 팀으로부터 서비스형 X를 받는다. 딜리버리는 더 빨라지고, 결정적으로 각 여정의 안전 케이스는 그것을 내놓는 팀이 소유한다.

부문별 관점#

스타트업#

열 명 규모의 디지털 보건 스타트업은 네 가지 팀 유형을 따로 배치할 수 없다. 보통 한 사람이 여러 역할을 하는(사용자 리서치도 하는 엔지니어, 사실상 임상 안전 책임자인 임상의 창업자) 단일 스트림 정렬 팀 그 자체다. 우선순위는 결정이 빠르도록 팀 전체를 하나의 공유된 인지 공간에 두는 것이다. 모두가 같은 방에 있을 때 공식 RACI는 과하다. 실제 위험은 창업자 병목이다. 임상 안전과 정보 거버넌스가 한 명의 바쁜 사람에게 얹히고, DCB0129/0160 의무는 미루기 쉽다. 회사가 첫 NHS 계약을 따내면, 엔지니어링 인원을 늘리기 전에 첫 전문가 채용은 그 관문의 위험을 낮추는 이들, 곧 지정된 CSO와 정보 거버넌스 리드여야 한다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉 — 에게는 실제 환자와 지속적인 운영이 있지만 전담 디지털이나 IT 팀은 드물어서 설계할 "팀 토폴로지"가 없다. 진료소 관리자나 임상 리드가 본업과 함께 사실상 딜리버리 역량 전체다. 현실적인 수는 플랫폼 및 지원 팀을 구축하는 것이 아니라 이미 있는 사람들에게 책임을 명시적으로 명명하는 것이다. 도입하는 시스템의 임상 안전 책임자는 누구인지, 누가 정보 거버넌스를 소유하는지, 누가 변경을 승인하는지 — 소수 직원의 시간제 겸직일지라도. 대형 트러스트와 같은 법정 의무(DCB0129/0160, UK GDPR, 접근성)가 적용되므로, 실용적 패턴은 공급업체와 ICS의 공유 플랫폼 및 지원에 기대어 처음부터 다시 만들지 않으면서, 공급업체에 책임을 물을 만큼의 지능형 고객 역량만 유지하는 것이다. 가장 큰 단일 위험은 한 사람 병목이다. 임상 시스템을 이해하는 유일한 사람이 떠나면 안전과 연속성이 함께 나가므로, 여기서는 어떤 공식 팀 모델보다 RACI를 적어 두고 두 번째 사람을 교차 교육하는 것이 중요하다.

대기업#

대형 NHS 트러스트나 보건 기술 기업은 반대의 문제를 안고 있다. 레거시 구성 요소와 부서 경계로 그어진 너무 많은 팀과 곳곳의 인계다. 여기서 의도적인 팀 설계 모델이 값을 한다. 구성 요소 팀을 스트림 정렬 팀으로 재편하고, 공유 진료 기록과 통합 역량을 위한 플랫폼 팀을 세우며, 지원 팀으로 희소한 임상 안전 및 접근성 전문성을 퍼뜨린다. 이해관계자의 수가 많아 비공식 조율이 불가능하므로 RACI와 명시적 결정권이 필수가 된다. 역 콘웨이 기동은 여기서 살아 있는 지렛대다. 수십 년 된 조직도가 이미 아키텍처를 형성하고 있으므로, 리더는 구조가 진료 기록을 대신 설계하게 두지 말고 팀 경계를 의도적으로 다시 그어야 한다.

정부#

국가 기관(NHS England, DHSC)이나 지방정부는 다른 이들이 인력을 맞추는 표준 — Government Digital and Data 역량 프레임워크, Service Standard, DCB0129/0160 — 을 정하며, 돈이 팀 역량을 어떻게 사는지에 대해 의회와 대중에게 책임을 진다. 여기서 구조는 조달 및 재원 규칙에 의해 형성된다. 딜리버리의 상당수가 공급업체에 계약되므로, 사내에 유지할 결정적 역할은 역량이 속 빈 강정이 되는 것을 막는 지능형 고객 역할(제품 소유권, 기술 보증, 임상 안전 승인)이다. 책임은 공식적이고 감사 가능하다. 지정된 고위 책임 소유자, 공표된 지출 통제, 투명성 의무가 있으므로 책임 모델은 선택적 위생이 아니라 공적 기록의 문제다. 특징적 위험은 구조가 흐름을 조이는 영구적 프로그램 이사회와 관문으로 굳어지는 것이며, 대응은 공급업체에 인력 파견이 아니라 스트림 정렬적이고 성과를 소유하는 팀을 요구하는 것이다.

흔한 실패 양상#

• 구성 요소 팀의 함정. 기술 계층("프런트엔드 팀", "데이터베이스 팀")으로 나눈 팀은 모든 기능마다 인계를 만들고 어떤 성과도 소유하지 않는다. 가치의 흐름 주위로 재편하라.
• 카고 컬트 Spotify. 기반이 되는 자율성, 정렬, 플랫폼 투자 없이 "스쿼드, 트라이브, 챕터, 길드"를 라벨로만 복사한다. Spotify 모델은 한 회사의 한 시점의 스냅샷이었고, Spotify조차 앞으로 나아갔다. 조직도가 아니라 원칙을 빌리라.
• 영웅적 병목. 한 명의 CSO, 아키텍트, 정보 거버넌스 리드가 모든 것에 자문되어 모든 팀이 기다린다. 이들을 모두의 역량을 끌어올리는 지원 역량으로 바꾸라.
• 사후 고려로서의 거버넌스. 임상 안전과 정보 거버넌스가 팀에 내장된 구성원이 아니라 외부 관문으로 대표되어, 그들의 우려가 싸게 조치하기엔 너무 늦게 도착한다.
• 경계 없는 팀. 아무도 전체를 이해하지 못할 때까지 서비스를 계속 흡수하는 팀. 인지 과부하는 딜리버리가 느려지고 안전 확신이 침식되는 것으로 나타난다.
• 영구적 협업. 두 팀이 무기한 "협업"하는 것은 보통 누락된 경계다. 협업에 기간을 두고 깔끔한 서비스형 인터페이스로 옮기라.

성숙도 모델#

체크리스트#

• 모든 서비스에 그것을 종단 간 소유하는 스트림 정렬 팀이 있다.
• 각 팀이 제품, 딜리버리, 리서치, 디자인, 엔지니어링, 데이터, 임상 안전, 정보 거버넌스를 포함하거나 지정된 접근 경로가 있다.
• 팀마다 릴리스를 멈출 보호된 시간과 권한이 있는 지정되고 교육받은 임상 안전 책임자가 있다.
• 공유 역량(통합, 신원, 진료 기록 API)이 서비스로 소비되는 내부 플랫폼으로 운영된다.
• 희소한 전문가는 영구적 병목이 아니라 기간이 정해진 지원 팀을 통해 일한다.
• 임상 승인, 가동, 정보 거버넌스 승인, 지출에 대한 RACI(또는 그에 상응하는 것)가 있고 실제로 사용된다.
• 각 팀 간 의존성에 지정된 상호작용 방식(협업 / 서비스형 X / 촉진)이 있다.
• 팀의 도메인이 관리 가능한 인지 부하로 경계 지어져 있고, 과부하된 팀은 나뉜다.
• 원하는 아키텍처와 상호운용성을 낳도록 팀 경계를 의도적으로 선택한다.

주요 출처#

• Team Topologies — Matthew Skelton & Manuel Pais (네 가지 팀 유형, 세 가지 상호작용 방식, 인지 부하): teamtopologies.com
• NHS Digital Service Standard and NHS Service Manual — 다학제 팀 역할과 업무 방식
• GOV.UK Service Manual (GDS) — "Set up a service team" 및 애자일 딜리버리 지침
• Government Digital and Data (formerly DDaT) Profession Capability Framework — 역할 정의: ddat-capability-framework.service.gov.uk
• Clinical Risk Management standards DCB0129 (제조) and DCB0160 (배치), NHS Digital — 임상 안전 책임자 역할
• Conway's Law — Melvin Conway, "How Do Committees Invent?" (1968)
• Spotify engineering culture (Henrik Kniberg) — 스쿼드/트라이브/챕터/길드, 한 시점의 모델로 비판적으로 읽을 것

참고문헌#

1. Conway's law — Wikipedia — https://en.wikipedia.org/wiki/Conway%27s_law
2. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
3. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
4. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
5. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
6. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais — https://teamtopologies.com
8. NHS Service Manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk
9. Service Manual — Government Digital Service (GDS), GOV.UK — https://www.gov.uk/service-manual
10. Government Digital and Data Profession Capability Framework — GOV.UK — https://ddat-capability-framework.service.gov.uk
11. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
12. "How Do Committees Invent?" (1968) — Melvin E. Conway — http://www.melconway.com/Home/Committees_Paper.html

주제 7.2 — 인력 계획, 주제 7.3 — 인력 전략, 주제 7.5 — 인재 및 조직 개발, 주제 8.1 — 변화 관리도 참조.