主题 7.0 — 团队结构、角色与责任

一句话概括： 数字健康交付的成败取决于你如何划定团队之间的边界，以及你如何清晰地指明谁做什么——因此要为价值的快速、安全流动来构建团队结构，让它们拥有多学科的人员配置，并使责任明确化。

为什么这在卫生与照护中至关重要#

你组织团队的方式，会变成你服务表现的方式。康威定律（Conway's Law）——一个系统的设计会反映建造它的组织的沟通结构——在卫生与照护中不是一种奇闻趣事；它是一项患者安全风险。碎片化的团队会产生碎片化的照护记录、脆弱的集成，以及临床风险藏身其中的交接环节。

在 NHS 和社会照护中，你还在花费公共资金，承担法定责任：DCB0129/DCB0160 之下的临床安全、UK GDPR 和保密的普通法义务之下的信息治理，以及无障碍责任。这些责任不能在最后被硬拼接上去。它们必须由拥有权威和时间来履行它们的具名人员，代表在团队内部。

把结构做对，多学科团队就能交付临床医生信任、患者能用的可运行软件。把它做错，你就会得到忙碌的专家们优化自己的孤岛，而整个服务却停滞不前——这是延迟、超预算、悄悄被放弃的数字化项目群背后的经典模式。

核心概念#

多学科团队（Multidisciplinary teams）（MDT）。 一个数字交付团队应该包含设计、建造和运行一项服务所需的每一个学科，而不需要持续的外部依赖——产品、交付、设计、研究、工程、数据，以及临床和治理视角。这反映了员工已经熟悉的临床 MDT 概念：混合的专业知识，对一个成果的共担问责。

Team Topologies。 一个模型（Skelton & Pais），把有效的团队设计归纳为四种基本类型和三种交互模式，全都服务于价值的快速流动：

• 流程对齐团队（Stream-aligned team）——围绕一条单一有价值的工作流（一项服务、一段用户旅程、一个产品）组织，端到端拥有它。这是默认的团队类型；大多数人都应该在这种团队中。
• 平台团队（Platform team）——提供内部自助能力（共享基础设施、一个集成引擎、一个登录服务、一个共享照护记录 API），使流程对齐团队能够更快地前进，而不必重新发明它们。
• 赋能团队（Enabling team）——一个有时限的专家团队（例如临床安全、无障碍性、测试自动化），指导其他人提升一项能力，然后退出。
• 复杂子系统团队（Complicated-subsystem team）——拥有一个需要深厚专业知识的部分（一个风险评分算法、一个 NHS Spine 接口），这会使一个通才团队不堪重负。

三种交互模式支配着任意两个团队之间的关系：协作（Collaboration）（在一段明确的时期内密切合作，高带宽，为了发现问题而容忍一些低效率）、X 即服务（X-as-a-service）（一个团队以最小的麻烦消费另一个团队的能力，是规模化时低摩擦的默认方式），以及促进（Facilitating）（一个团队帮助另一个团队学习）。为模式命名，能防止滋生延迟和相互指责的模糊性。

认知负荷（Cognitive load）。 一个团队脑子里能装下的东西是有限的。Team Topologies 主张，你应该把每个团队所拥有的领域限制在它能够安全推理的范围内——当这个领域是临床性质时，这是一条决定性的原则。

康威定律与反向康威操纵。 由于架构会跟随组织结构——一种把团队和技术视为一个设计整体的社会技术系统（Sociotechnical system）视角——要有意识地塑造团队，以产出你想要的架构。如果你想要一份模块化、可互操作的照护记录，就不要用一个单体团队来构建它。

最佳实践#

1. 围绕每项服务配备一个完整的多学科团队。 至少包括一位产品经理、一位交付经理、一位用户研究员、一位服务/交互设计师、工程师，以及数据/分析能力，加上具名的临床安全和信息治理投入。一个缺少某个学科的团队要么会等待别人，要么会跳过那项工作——而在卫生领域，被跳过的工作通常是安全、无障碍性或治理。

2. 让大多数团队流程对齐，赋予它们端到端的所有权。 围绕一段用户旅程（例如"门诊转诊"）来组织，而不是围绕一个技术层（例如"数据库团队"）。端到端的所有权缩短了反馈循环，阻止了临床风险积累的交接缺口。

3. 把平台当作产品来构建，以服务的形式被消费。 把你的集成引擎、身份服务或共享照护记录 API 当作一个内部产品来对待，有自己的团队、路线图和用户。以"即服务"的形式发布它，使流程对齐团队能够自助，而不是提交工单等待。

4. 使用赋能团队来传播稀缺的专业知识，而不是囤积它。 临床安全官、无障碍性专家和安全工程师都是稀缺的。部署他们去指导交付团队达到更高的标准，然后转移到别处，而不是变成每个团队都要排队等候的永久瓶颈。

5. 明确命名每个角色及其决策权。 对重要的决策——临床安全签核、上线、信息治理批准、支出——使用一个责任模型——RACI（负责、问责、被咨询、被告知）或一个更简单的"决策者/顾问"划分。这里的模糊性正是问责蒸发的地方。

6. 给予临床安全官真正的权威和真正的时间。 DCB0129/0160 要求有一位具名的、经过适当培训的临床安全官，能够拦下一次发布。让这个角色在团队中明确化，保护它的时间，确保它能够说"不"——一个只有名号的 CSO，是一场等待被一起事件发现的治理失败。

7. 通过界定领域来管理认知负荷。 如果一个团队拥有太多服务或太复杂的临床领域，就拆分它。留意这个信号：一个不再能够自信地解释自己变更的安全影响的团队，就是超负荷了。

8. 有意识地应用反向康威操纵。 划定团队边界，使其与你想要的架构和互操作性相匹配——为模块化的、基于标准的（例如 HL7 FHIR）系统配置模块化的团队。不要让一张偶然形成的组织架构图替你设计你的照护记录。

与团队讨论的问题#

1. 我们目前的组织架构图已经在哪些地方替我们设计了我们的架构——那是我们真正想要的架构吗？ 康威定律不是可选的：无论我们团队的形状是什么，系统最终都会反映它，因此诚实的第一步，是看看我们已经拥有的照护记录、集成和交接，问是哪个团队边界产生了每一道接缝。在一个卫生与照护环境中，那些接缝正是临床风险藏身之处——一份碎片化的记录、一个脆弱的 Spine 接口、一个没有任何单一团队拥有的安全案例——因此这是一场患者安全对话，而不是一场审美对话。要辩论的张力是，重新划定团队边界以获得我们想要的架构（反向康威操纵）是具有破坏性的，威胁着既有的势力范围，并切割着我们可能无法完全控制的资金和条线管理结构。考虑把你最痛苦的两三个集成，追溯到拥有其两端的团队，问一个流程对齐的边界是否会完全消除这次交接。一个好的答案会指明至少一个你愿意移动的具体边界，诚实说明谁会抵制、为什么，并区分那些值得这种破坏的变革，与那些一个即服务接口会更便宜地解决摩擦的情形。

2. 我们稀缺的专家——临床安全、信息治理、无障碍性——是坐在拥有真正权威的团队内部，还是每个人都要排队等候的外部关卡？ 这个大家族中的每一项服务都承担着不能在最后被硬拼接上去的法定责任（DCB0129/0160 临床安全、UK GDPR 和保密的普通法义务、无障碍法律），然而这些能力是稀缺且昂贵的，这把机构拉向了在中央囤积它们。这个取舍是真实的：把一位临床安全官嵌入每一个团队，你会把稀薄的专业知识稀释开来；把它集中化，你会创造出一种英雄式瓶颈，一个人在每件事上都被咨询，每一次发布都要等待。赋能团队模式——有时限的专家指导团队运行自己的危害工作坊，然后退出——是提议的解决方案，但它只有在领导层保护专家的时间用于教学、而不是亲自动手时才有效。诚实地看看你自己的发布历史：上线延迟等待单一具名个人的情况有多常见，那个人是否有权威和有保障的时间来安全地说"不"？一个有力的答案会正面直视这种稀缺性，为每一项责任在嵌入与赋能之间选择一个有意识的立场，并指明无论你如何分散产能都绝不能被稀释的那个具体权威（叫停一次发布的权力）。

3. 我们如何知道一个团队承担了超过它能安全承受的认知负荷——我们实际上会怎么做？ 认知负荷是安全交付的隐性调节器：一个团队只能在开始对其自身变更的安全影响的信心开始流失之前，推理这么多的临床领域和这么多的服务，而在卫生领域，那种流失是不可见的，直到一起事件将其暴露出来。困难在于超负荷很少会自我宣告——它看起来像是稍慢的交付、更多的缺陷、更多的"让我和某人确认一下"，处于压力之下的团队倾向于吸收它，而不是标记它，尤其是当拆分一个团队在政治上代价高昂、或编制被冻结时。辩论你的预警信号会是什么（一个不再能够自信地解释其自身发布安全案例的团队是一个强烈的信号），以及你今天是否有任何机制能够在交付明显停滞之前揭示超负荷。也要考虑反压力：拆分团队会创造新的边界和交接，因此这个解决方案可能重新引入问题一的碎片化风险。一个诚实的答案会就具体的、可观察的信号达成一致，而不是含糊的"我们会感觉到"，指明谁有权界定一个团队的领域或拆分它，并承认负荷缓解与边界扩散之间的取舍。

4. 我们哪些共享能力应该作为以服务形式被消费的平台来运行，我们是否真的在这样配备资源——还是只是给一个工单队列重新贴了个标签？ 一个平台团队的承诺是，流程对齐团队能够自助使用一个集成引擎、一个身份服务，或一个共享照护记录 API，而不必提交工单等待，从而使整个系统更快地运转；失败则是把某个东西称为"平台"，而它实际上仍然是一个人手不足的中央职能，每个人仍然要排队等候。这个取舍是真实的：把一项能力构建为一个真正的内部产品，意味着给它自己的团队、路线图、文档和用户，这是一项与交付面向用户的功能相竞争的严肃投资，在一个现金有限的 NHS 环境中，这项投资很容易被无限期推迟。在卫生与照护中，利害关系更加尖锐，因为共享能力常常是安全攸关的——身份匹配索引、FHIR 接口、审计追踪——在这里，一个人手单薄的平台团队会变成其上每一项服务的单点故障。看看几个团队已经依赖的能力，对每一个都问，这种交互是真正低摩擦的 X 即服务，还是一种隐藏了等待时间的伪装协作。一个诚实的答案会指明哪些能力现在真正值得平台投资、哪些可以推迟，明确谁为它们提供资金和人员，并抵制宣布一个没有产品负责人、没有路线图、没有自助路径的"平台"的诱惑。

5. 我们在哪些地方依赖合同供应商或借来的员工，哪些角色我们必须保留在内部，才能保持是一个智能客户、而不是一个被掏空的客户？ 卫生与照护中的许多数字交付都是外包的，一个供应商能够快速带来产能和专业知识——但如果产品所有权、技术保证和临床安全签核都随着合同一起离开大楼，机构就会失去判断自己被卖了什么、规定自己需要什么，或安全地拥有结果的能力。这里的张力存在于速度和能力之间：人员增补和交钥匙式构建能够快速让某个东西上线，但它们可能悄悄侵蚀让你能够让供应商负责的内部实力，并且它们常常交付组件形态的、重交接的结构，而不是拥有一个成果的流程对齐团队。在这个领域，不可谈判的保留角色，集中在无法被委托的问责周围——高级责任人、签署上线的临床安全官、决定优先级的产品负责人，以及足够的技术保证来检查供应商所建造的东西。审视你当前的交付，问如果一个供应商明天离开，你无法重新组建的能力是哪些。一个好的答案会区分真正可以外包的工作，与必须留在内部的智能客户核心，坚持要求合同团队对成果所有权负责、而不是人力外包，并指明必须始终由你自己的问责人员来做的安全和治理决策。

6. 我们如何知道我们的团队结构真正在产出价值的快速、安全流动——什么会触发我们重新划定它？ 团队设计是一种手段，而不是目的：流程对齐团队、平台和具名交互模式的意义在于更快、更安全的价值交付，然而机构很少去衡量这个结构是否正在实现这一点，因此重组往往依据政治和直觉、而不是证据发生。困难在于选择反映流动和安全性、而不被操纵的信号——原始的速度或故事点吞吐量会诱发错误的行为，而流动指标（从想法到上线的前置时间、部署频率、每次变更的交接次数）和安全指标（危害被关闭的速度、团队是否拥有自己的安全案例）能更多地告诉你，边界是在帮助还是在伤害。这里与稳定性存在真实的张力：不断的重组会摧毁使交付安全的团队长期性和共享认知空间，因此你需要在重新划定边界之前设定一个高门槛和清晰的触发条件。讨论什么证据会告诉你一个边界是错的——持续的跨团队等待、一个没有任何单一团队拥有的安全案例、一个没有人自助使用的平台——以及谁被授权据此采取行动。一个诚实的答案会承诺关注一小组你真正会观察的流动和安全信号，设定一个保护团队稳定性的有意识门槛，并为任何未来的重塑指明触发条件和决策者。

实践中：一个卫生与照护案例#

一个整合照护系统（ICS）正在急症、社区、心理健康、初级照护和社会照护领域推行一份共享照护记录。

本能的做法是创建一个大型的"共享照护记录团队"。相反，该 ICS 应用了 Team Topologies。一个平台团队拥有共享记录的核心：身份匹配索引、FHIR API 和集成引擎，以自助能力的形式发布。若干流程对齐团队各自拥有其上的一段真实用户旅程——"在急诊室查看患者记录"、"社工安全保障视图"、"全科医生药物核对"——并以服务的形式消费这个平台。一个复杂子系统团队拥有概率性患者匹配算法，在这里，一次误匹配是一起真正的安全事件。一个由临床安全和无障碍性专家组成的赋能团队在各个流程对齐团队之间轮转，指导他们运行自己的 DCB0160 危害工作坊，而不是替他们完成。

每个团队都有一位具名的产品经理、交付经理和临床安全官，一份 RACI 明确说明上线问责于高级责任人，但不能在没有 CSO 和 IG 签核的情况下推进。当急诊室团队需要一个新的数据字段时，交互模式是明确的：通过一份有文档记录的 API 请求，来自平台团队的 X 即服务，而不是一次为期六周的协作。交付更快，至关重要的是，每段旅程的安全案例由交付它的团队所拥有。

行业视角#

初创企业#

一家十人规模的数字健康初创企业无法配备四种不同的团队类型——它通常就是一个单一的流程对齐团队，其中一个人身兼数职（一位同时做用户研究的工程师、一位实际上是临床安全官的临床医生创始人）。优先事项是让整个团队保持在同一个共享认知空间内，使决策快速；当每个人都在同一个房间里时，一份正式的 RACI 是过度设计。真正的风险是创始人瓶颈：临床安全和信息治理压在一个忙碌的人身上，DCB0129/0160 责任很容易被推迟。随着公司赢得第一份 NHS 合同，第一批专家招聘应该是那些能为这个关卡降低风险的人——一位具名的 CSO 和一位信息治理负责人——然后再扩大工程编制。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院，或一家单点诊所——有真实的患者和持续的运营，但很少有专职的数字或 IT 团队，因此没有需要设计的"团队拓扑结构"；诊所经理或一位临床负责人实际上就是全部的交付能力，还要兼顾他们的日常工作。现实的做法不是构建平台和赋能团队，而是在你已经拥有的人员上明确指定责任——谁是你所部署系统的临床安全官，谁拥有信息治理，谁签核一次变更——即使这些只是少数员工身上的兼职角色。因为同样的法定责任（DCB0129/0160、UK GDPR、无障碍性）像适用于一家大型信托机构一样适用，实际的做法是依靠你的供应商和你的 ICS 的共享平台和赋能支持，而不是重新发明它们，同时保留刚好足够的智能客户能力来让供应商负责。单一最大的风险是那个单人瓶颈：如果唯一理解临床系统的人离开，安全性和连续性都会随之而去，因此在这里，写下 RACI 并交叉培训第二个人，比任何正式的团队模型都更重要。

大型机构#

一家大型 NHS 信托机构或健康科技公司面临相反的问题：团队太多，沿着遗留组件和部门界限划分，到处都是交接。这正是一个有意识的团队设计模型发挥价值的地方——把组件团队重塑为流程对齐团队，为共享照护记录和集成能力建立平台团队，并使用赋能团队来传播稀缺的临床安全和无障碍性专业知识。RACI 和明确的决策权变得至关重要，因为利益相关者的绝对数量使非正式协调变得不可能。反向康威操纵在这里是一个实时的杠杆：一张有数十年历史的组织架构图已经在塑造架构，因此领导者必须有意识地重新划定团队边界，而不是让结构替他们设计照护记录。

政府#

一个国家机构（NHS England、DHSC）或地方当局设定了其他人据以配置人员的标准——Government Digital and Data 能力框架、服务标准、DCB0129/0160——并对议会和公众就资金如何购买团队产能负责。这里的结构由采购和资金规则塑造：许多交付是外包给供应商的，因此需要保留在内部的关键角色是智能客户角色（产品所有权、技术保证、临床安全签核），它们防止能力被掏空。问责是正式的、可审计的——一位具名的高级责任人、已发布的支出控制、透明度义务——因此责任模型是一项公共记录事务，而不是可选的卫生习惯。典型的风险是结构僵化成永久的项目群委员会和扼杀流动的关卡；反制措施是让供应商对流程对齐的、拥有成果的团队负责，而不是人力外包公司。

常见失败模式#

• 组件团队陷阱。 按技术层拆分的团队（"前端团队"、"数据库团队"）在每个功能上都产生交接，不拥有任何成果。围绕价值流重组。
• 对 Spotify 的生搬硬套。 复制"小队、部落、分会、公会"这些标签，却没有底层的自主性、对齐和平台投资。Spotify 模型是某一家公司在某一个时刻的快照——甚至 Spotify 自己也已经向前发展了。借用原则，而不是组织架构图。
• 英雄式瓶颈。 一位 CSO、一位架构师，或一位信息治理负责人在每件事上都是被咨询方，因此每个团队都要等待。把他们转变为一种能提升每个人能力的赋能能力。
• 作为事后补充的治理。 临床安全和信息治理被表示为外部关卡，而不是嵌入的团队成员，因此他们的担忧到达时已经太晚，无法廉价地据以行动。
• 无边界的团队。 一个不断吸收服务、直到没有人理解全貌的团队。认知超负荷表现为交付放缓、安全信心侵蚀。
• 永久的协作。 两个团队无限期地"协作"，通常意味着缺失了一个边界。为协作设定时限，转向一个干净的即服务接口。

成熟度模型#

检查清单#

• 每项服务都有一个端到端拥有它的流程对齐团队。
• 每个团队都包含、或有具名的渠道能够获取产品、交付、研究、设计、工程、数据、临床安全和信息治理。
• 每个团队都有一位具名、经过培训的临床安全官，拥有保障的时间和叫停一次发布的权威。
• 共享能力（集成、身份、照护记录 API）作为以服务形式被消费的内部平台运行。
• 稀缺的专家通过有时限的赋能团队工作，而不是变成永久瓶颈。
• 存在一份用于临床签核、上线、信息治理批准和支出的 RACI（或等效物），并被真正使用。
• 每一个跨团队依赖关系都有一个具名的交互模式（协作/X 即服务/促进）。
• 团队领域被限定在一个可管理的认知负荷范围内；超负荷的团队被拆分。
• 团队边界被有意识地选择，以产出你想要的架构和互操作性。

关键资料来源#

• Team Topologies —— Matthew Skelton & Manuel Pais（四种团队类型、三种交互模式、认知负荷）：teamtopologies.com
• NHS Digital Service Standard 和 NHS Service Manual —— 多学科团队角色和工作方式
• GOV.UK Service Manual（GDS）——"建立一个服务团队"和敏捷交付指导
• Government Digital and Data（原 DDaT）职业能力框架——角色定义：ddat-capability-framework.service.gov.uk
• 临床风险管理标准 DCB0129（制造）和 DCB0160（部署），NHS Digital——临床安全官角色
• 康威定律——Melvin Conway，《委员会如何发明？（How Do Committees Invent?）》（1968）
• Spotify 工程文化（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——变革管理。