主题 5.0 — 以产品为主导的工作方式

一句话概括： 以产品为主导的工作方式为持久的、被赋权的团队提供资金，使其在整个生命周期内拥有一项服务，并以可衡量的结果而非一份固定的功能清单来追究其责任。

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

数字卫生与照护机构运行的大多数事物都不是一次性交付——而是一项活的服务。NHS App、一份电子病历、一份共享照护记录、一条电子转诊路径、一个社会照护个案管理系统：这些都不是"已完成"的。随着临床指南的变化、安全事件的出现、需求的转移以及周围体系的演进，它们必须被持续改进。

当你把一项活的服务当作一系列互不相连的项目来管理时，就会出现一种可预见的失败：供应商按规格建造，资金用完，团队解散，服务被搁置腐坏，直到下一轮资本申请。临床医生想方设法绕开缺陷，患者安全风险不断累积，公平性也随之受损，因为最没有能力容忍一个笨拙服务的人，恰恰是需求最大的人。以产品为主导的工作方式，正是为了打破这一循环而存在。它让一个稳定的团队始终贴近用户和结果，使服务随时间变得更安全、更易用、更公平，而不是在资金轮次之间不断退化。

其中的利害关系也涉及财务和法定责任。一个持续验证服务是否真正改善照护的团队，比一个不论是否有人受益、只以"按时按预算交付"衡量成功的项目，更能保护公共资金。本主题与主题 5.1——以项目为主导的工作方式和主题 5.2——以计划为主导的工作方式并列；三者是互补的工具，而非彼此竞争，主题 5.3——企业级投资组合与项目管理（EPPM）则说明了如何将三者统筹在一起。

核心概念#

持久的产品团队。 一个跨职能（cross-functional）、长期存在的团队，在整个生命周期内拥有一项产品或服务。团队持续存在；工作流向团队。这是 Marty Cagan 和硅谷产品集团（Silicon Valley Product Group，SVPG）所描述的产品运营模型的基本单元：一个由产品经理、产品设计师和工程师组成的稳定小组，在卫生领域还需要临床和数据专业知识的支持。

被赋权的团队。 Cagan 明确区分了被交付一份待建事项路线图的"功能团队"，与被交付待解决问题和待实现结果、并被信任去找到最佳方案的"被赋权团队"。赋权不是为所欲为的许可；而是在清晰的战略框架内对结果负责。

结果重于产出。 产出是你交付的东西——一项功能、一次发布、一个界面。结果是由此在世界中产生的变化——更少错过的预约、更快的出院、更少的用药错误、更公平的使用率。以产品为主导的工作方式以结果来衡量团队，因为交付一项无人使用、或无人因此更安全的功能，只是被包装成进展的浪费。

产品经理。 产品管理（product management）的负责人，对产品的价值和可行性负责：这值得建造吗？人们会使用它吗？它是否符合机构的战略、法规和财务状况？在卫生与照护领域，这一角色必须与临床安全和信息治理负责人紧密合作，而不是凌驾于他们之上。

产品运营模型。 SVPG 明确指出，这是一种模型，而不是一套方法论或僵化的框架：这是关于一家公司如何构建和运行技术驱动产品的一组原则——被赋权的团队、结果问责、持续探索和产品战略——而不是一套你安装上去的既定流程。

产品生命周期。 探索（是否存在一个真正值得解决的问题？）、交付（安全良好地构建它）、增长与优化（提升采用率和结果），以及最终的退役（体面地退出或替换）。以产品为主导的团队拥有全部这些阶段，这也是他们能够做出项目团队无法做出的、合理的全生命周期权衡的原因。

最佳实践#

1. 为团队提供资金，而不是为项目提供资金。 正如 Mik Kersten 在《从项目到产品》（Project to Product）中所论述的，将资金从有时限的项目预算转移到与价值流（value stream）挂钩的常设产品预算。为一个持久的团队提供资金，使其在连续的规划周期中追求结果，并根据已证实的成果、而不是多年前商定的里程碑计划，重新授权资金。

2. 给团队问题和结果，而不是功能清单。 将任务表述为"降低门诊爽约率"或"缩短临床医生查找结果所花的时间"，然后让被赋权的团队去发现最佳方案。从上而下交付一份既定功能路线图，会重新制造出 Cagan 所警告的功能团队反模式。

3. 让结果指标明确且具有临床意义。 事先商定一小组结果指标，理想情况下以目标与关键结果（objectives and key results，OKR）的形式呈现（参见主题 7.3）。将每一项效率指标与一项安全指标和一项公平性指标配对，这样团队就绝不会因为以伤害或加剧不平等为代价换取速度而受到奖励。

4. 让团队真正贴近真实用户。 嵌入持续探索：与临床医生、照护人员、行政人员和患者保持定期接触。NHS 服务手册和 GOV.UK 服务手册都将用户研究作为一项常设的实践，而不是一次性的阶段。持久的团队使这一点变得负担得起，因为这些关系得以持续。

5. 构建内含临床安全的多学科团队。 一个数字卫生产品团队除了产品/设计/工程之外，还需要一名临床安全官员（DCB0129/DCB0160）、信息治理和数据专业知识。安全和治理是团队内部拥有的设计输入，而不是最后附加上去的关卡。

6. 对产品进行仪表化测量，并据数据行动。 持久的团队可以投资于遥测，使决策建立在真实使用情况和真实结果之上，而不是主观意见。按队列观察采用情况，以尽早发现数字排斥。

7. 拥有整个生命周期，包括退役。 被赋权的团队不仅规划上线，也规划体面的退役和迁移。决定不继续构建、而是整合到一个战略性平台上，是一项合理且有价值的产品决策。

8. 通过战略而非微观管理来对齐团队。 没有对齐的自主权会产生局部优化和混乱。清晰的产品愿景和战略——在规模化时，加上投资组合和计划层面的框架（主题 5.2 和主题 5.3）——正是能够安全地赋权团队的关键。

与团队讨论的问题#

1. 我们今天运营的哪些服务真正是值得配备持久、有资金保障的产品团队的活服务，哪些是我们只是假装需要一个产品团队的有限工作？ 这是最基础的分类问题，无论朝哪个方向搞错都代价高昂。在一个数字卫生与照护机构中，其资产是混合的——一份共享照护记录或面向患者的应用程序是一项活服务，但一次性的数据中心退出或硬件更新则确实是有限的——诚实的答案需要指明每一个重要系统并逐一论证，而不是到处套用同一种资金模型。张力在于，财务和治理机制通常会把一切都推向有时限的资本申请，因此把某样东西称为"产品"可能显得像是特殊要求，而把一项活服务称为"项目"则悄悄地保证了本主题前面所描述的"建造然后抛弃"式衰败。要考虑全生命周期成本、围绕该服务的临床指南和需求变化的速度，以及当没有人拥有持续改进的责任时，患者安全风险是否会累积。一个好的答案会指明两三项明显应该配备持久团队的服务，坦诚地说明哪些是模棱两可的，并明确把有限工作留给主题 5.1处理，而不是为一刀切的政策辩护。

2. 我们真正愿意把一个团队的资金押在哪两三项结果指标上，我们如何将每一项与一项安全指标和一项公平性指标配对，才能确保我们绝不会因为以伤害为代价换取速度而受到奖励？ "结果重于产出"说起来容易，操作起来却很难，因为一旦某项指标驱动资金，它就开始扭曲行为。一个被要求"降低爽约率"的数字卫生团队，可以通过推动数字信心最强的患者来达成这个数字，同时悄悄扩大对年长或更贫困群体的差距——因此讨论必须揭示每个团队可能过度优化哪一个单一效率指标，以及与之配对的安全和公平性护栏实际衡量的是什么。将具体候选指标带到桌面上（减少用药错误、更快出院、按地区或数字可及性代理指标衡量的使用率），并对其是否具有临床意义、还是仅仅易于仪表化进行压力测试。要考虑谁拥有每项指标、基线是什么、多久审查一次，因为一项无人拥有或没有基线的结果指标只是装饰。一个诚实的答案会承认我们关心的一些结果是缓慢的或难以衡量的，抵制虚荣采用数字的诱惑，并承诺将公平性指标与效率指标一同发布，使这种权衡保持可见。

3. 我们准备给予被赋权团队多大的真实权限来改变方向，什么样的战略框架能防止这种自主权分裂为局部优化？ 赋权是产品运营模型的核心，也是它最常见的赝品，因为机构会把团队重新贴上"产品团队"的标签，同时仍然从上而下交付一份固定路线图并以交付情况来衡量。真正的问题在于边界在哪里：当探索显示存在一个能更好实现结果的不同方案时，团队能否从董事会支持的功能转向这个方案，还是临床治理、信息治理和现有供应商合同实际上会否决这种做法？张力在于，没有对齐的自主权会在整个 ICS 范围内产生重复和漂移，而以微观管理的方式强制对齐则会重新制造出功能工厂——因此答案在于一个明确的产品愿景和战略，在规模化时加上一个投资组合框架，能够约束而不指挥。要审视最近一次团队想要改变方向的决策，诚实地问系统是否允许它这样做。一个好的答案会定义团队可以独自做出的决策与需要上报的决策，指明提供该框架的战略文件，并坦诚说明机构目前在哪些地方把控制与对齐混为一谈。

4. 我们如何在年度预算周期中为一个持久团队提供资金并为其辩护，当财务部门要求我们为一个没有固定结束日期的"产品"辩护时，我们实际上会怎么做？ 以产品为主导的工作方式成败取决于资金，而 NHS 和公共部门财务的机制是为有时限的资本申请而建立的，而不是为与价值流挂钩的滚动收入资金而建立的——因此这个问题迫使我们面对"为团队提供资金，而不是为项目提供资金"背后令人不安的操作细节。张力在于，一个持久的团队需要多年的稳定性来留住稀缺的临床、产品和工程人才，但它所依赖的资金安排每年都要重新与展示出干净利落的开始和结束的资本计划竞争。带上真实的数字：团队的常设成本是多少，它对应哪一个价值流，以及什么样的已证实结果证据能够证明重新授权是合理的，而不是多年前商定的一份里程碑计划。要考虑资本与收入的会计规则、采购周期和供应商合同在你的机构中是帮助还是对抗这一模式。一个诚实的答案会指明谁签署滚动预算，在预算安排不佳的一年团队会怎样，以及机构是否准备将一项真正的服务转化为一条产品线，而不是悄悄地让它退回到项目申请。

5. 当以产品为主导的工作方式遇上我们的临床安全和信息治理责任时，安全和治理是否真正作为设计输入存在于团队内部，还是仍然是团队竞相赶往并设法绕过的关卡？ 一个持续交付的持久、被赋权团队改变了风险图景，因为每一次迭代都是一次潜在的临床安全和数据保护事件，而不是项目结束时的一次签署——因此 DCB0129/DCB0160 危害工作和 DPIA 必须存在于团队的节奏之中，而不是在发布关卡处临时附加。这种张力是真实的：在每个产品团队中都嵌入一名临床安全官员和一名信息治理负责人成本高昂，而这些技能又很稀缺，因此机构很容易被诱使稀薄地共享这些人力，或将保障视为团队在后期才去争取的一项批准。这种诱惑恰恰重新制造出安全方面的"建造然后抛弃"式失败，因为一个在交付压力下优化某项结果指标的团队，如果没有内部的安全之声，只会在伤害已经波及患者之后才发现问题。要考虑安全案例如何在众多小型发布中保持鲜活，谁拥有危害日志，以及治理同事对探索和优先级排序是否有真正的影响力，还是仅仅在最后拥有否决权。一个好的答案会坦诚说明安全目前在哪些地方仍是一道关卡而非设计输入，并承诺投入能让持续保障变得负担得起的人员配置和节奏。

6. 我们将如何让一个持久团队真正贴近服务不足的用户，使持续改进缩小而不是扩大数字排斥？ 以产品为主导的工作方式承诺将公平性作为一项一等结果，但一个为自己产品做仪表化测量的稳定团队自然会最响亮地听到那些已经在参与的用户的声音——那些数字信心强、有网络连接、会出现在遥测数据中的人——因此贴近用户可能悄悄变成贴近容易接触的用户。张力在于，最有排斥风险的群体（年长患者、贫困地区的人群、数字可及性低或存在语言障碍的人）恰恰是通过持续探索最难、最昂贵触及的人，而他们正是一项公共卫生服务本应服务的对象。将具体实践带到桌面上：哪些群体被刻意招募参与研究，如何按地区和数字可及性代理指标观察采用情况，以及当数字路径让某人掉队时存在什么非数字备用方案。要考虑团队的公平性指标是否真正改变了决策，还是仅仅被报告出来。一个诚实的答案会承认当前研究样本在哪些地方偏向容易触及的人群，指明尚未听到声音的服务不足群体，并描述能够防止改进不断放大既有优势的具体投入——外展、辅助数字服务、电话备用方案。

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

一个整合照护系统（ICS）运营一款面向患者的预约管理应用程序，供多家信托机构使用。历史上，每一项改进都是一个独立的项目：一家供应商被聘请来"添加短信提醒"，完成交付，然后离开。六个月后，提醒功能出现故障，没有人负责修复，需要一次资本申请才能重新开启合同。

该 ICS 转向以产品为主导的模式。它组建了一个持久的产品团队——一名产品经理、一名设计师、四名工程师、一名临床安全官员和一名信息治理负责人——按滚动方式获得资金，并被赋予一项结果而不是一份功能清单：降低爽约（DNA）率，并改善整个人群获取服务的公平性。

该团队与患者和门诊排班人员开展持续探索。他们了解到提醒确实有帮助，但在一个贫困地区导致爽约的更大原因是患者无法轻松改约，因此他们干脆错过了预约时段。由于该团队拥有的是结果而不是规格说明，他们将投入从一项炫目的通知功能转向了一个简单的自助改约流程，并按地区和数字可及性代理指标对采用情况进行了仪表化测量。

经过三个规划周期，爽约率下降了——至关重要的是，该团队监测了公平性指标，发现年长患者的采用率滞后，于是推动了一条电话备用路径，以免数字路径扩大不平等。由于结果是可证实的，资金得以持续。没有任何一项功能曾被"签署然后抛弃"；服务只是持续改进。当后来一个国家级平台提供了相同的功能时，同一个团队执行了迁移并退役了自己的组件——这是一个项目团队永远不会有能力做出的全生命周期决策。

行业视角#

初创企业#

在一家小型数字卫生公司中，以产品为主导的工作方式是默认的——往往是唯一的——模式：一个被赋权的团队，有时是整个公司，端到端地拥有产品。资金是硬性约束，因为投资者的现金流跑道或拨款资金意味着团队必须足够快地展示出结果吸引力（采用率、留存率、早期临床信号）以证明下一轮融资的合理性，因此持续探索和仪表化测量是生存工具，而不是奢侈品。风险偏好较高，问责对象是创始人和投资者，而不是董事会或公众，因此团队可以在几天内转向。陷阱在于把临床安全和信息治理（DCB0129、DPIA）当作可以推迟的企业级开销——在卫生领域，即便在种子阶段，这项规范也是不容商量的，NHS 买家会在让你接触患者数据之前要求 DTAC 证据。

小型企业#

对于一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院或居家照护机构、一家单点诊所，或一家已过初创阶段的小型健康科技供应商——以产品为主导的工作方式很少意味着组建一个专职的跨职能团队，因为没有多余的产品经理、设计师或工程师可以雇佣。在这里，"持久团队"往往是诊所经理或注册管理者加上一个受信任的供应商，因此重要的规范是让配置和维护系统的人对结果负责——更少错过的预约、更安全的药物核对、对最虚弱居民更好的可及性——而不是对一次性安装负责。资金是紧张且持续的，而不是有现金流跑道限制的，因此明智的做法是投入他人持续维护的产品（一家运营良好的供应商的路线图、一份共享照护记录、一个 ICS 平台），而不是委托无人会维护的定制建造。临床安全和信息治理依然全面适用——与大型信托机构相同的 DCB0160 部署职责和 DPIA 义务——但没有任何内部能力，这使得选择拥有自身安全案例的供应商成为一项真正的产品决策。公平性角度贴近日常：小型服务提供者往往恰恰服务于最容易受数字排斥影响的年长或更贫困患者，因此保留一个非数字备用方案不是可有可无的。

大型机构#

在一家大型 NHS 信托机构、整合照护系统（ICS）或健康科技公司中，持久团队模型与年度资本预算和项目形态的财务机制相冲突。核心工作是把常设服务——EPR 优化团队、共享照护记录团队——从时断时续的项目转变为与价值流挂钩、按滚动方式获得资金的产品团队，这既是一项财务和治理变革，也是一项组织架构变革。问责分层于临床治理、信息治理、董事会保障和供应商合同之中，因此赋权必须与明确的产品战略和投资组合对齐（参见主题 5.3——企业级投资组合与项目管理）配对，以阻止数十个自主团队各自进行局部优化。规模是贴近用户的敌人，因此有意识地投资于嵌入式研究，是让一个大型机构的团队保持诚实的关键。

政府#

在国家层面——NHS England、DHSC、UKHSA——以产品为主导的工作方式为长期存在的平台（NHS App、NHS login、国家互操作性 API）提供资金，将其作为产品而不是项目，并依据 GDS 和 NHS 服务标准及其服务评估来问责。资金通过支出审查安排和商业案例流动，因此困难之处在于当围绕它们的机制是为有时限的项目建立时，如何在财政年度和政治周期中维持稳定的团队。问责对象是部长、议会以及通过国家审计署面向公众，而公平性责任是法定的，因此结果指标必须与已发布的人群层面公平性指标配对。回报在于覆盖面：一次单一的产品改进可以同时触及数千万用户，这既提高了做对的收益，也提高了做错的代价。

常见失败模式#

• 有名无实的产品主导（"功能工厂"）。 机构把项目团队重新贴上"产品团队"的标签，但仍然交付一份固定路线图，并以交付情况来衡量他们。修复方法：改变任务和指标，而不只是职位名称。
• 没有安全或公平性护栏的结果。 优化单一效率指标可能掩盖伤害或扩大排斥。修复方法：每项结果指标都与一项安全指标和一项公平性指标配对。
• 没有战略的"赋权"。 被留下自行发明方向的团队会漂移和重复。修复方法：强有力的产品愿景和战略，以及投资组合层面的对齐（主题 5.3）。
• 将产品主导应用于真正有限的工作。 一次性的数据中心迁移或硬件部署不需要一个永久性团队。修复方法：在范围确实固定的地方使用项目主导的工作方式（主题 5.1）。
• 回归到年度项目申请的资金模式。 一个预算时断时续的持久团队无法规划或留住人才。修复方法：为价值流提供滚动的、以结果审查为基础的资金。
• 作为工单撰写者的产品经理。 把这一角色简化为待办事项管理是一种浪费。修复方法：让产品经理对价值、可行性和结果负责。

成熟度模型#

检查清单#

• 这是否真正是一项持续进行的服务（而非有限工作），适合配备持久团队？
• 是否有一个稳定的跨职能团队在整个生命周期内拥有该产品？
• 该团队是否被赋予问题和结果的任务，而不是一份固定的功能清单？
• 结果指标是否已商定——每一项都与一项安全指标和一项公平性指标配对？
• 临床安全（DCB0129/DCB0160）和信息治理是否存在于团队内部？
• 该团队是否按滚动方式获得资金，并根据已证实的结果重新获得授权？
• 持续的用户研究和探索是否是一项常设实践？
• 该产品是否经过仪表化测量，采用情况是否按队列被观察以发现排斥现象？
• 是否有清晰的产品战略将自主权与机构目标对齐？
• 体面的退役／迁移是否作为一个明确的生命周期阶段被规划？

关键资料来源#

• 硅谷产品集团（Silicon Valley Product Group，SVPG）、Marty Cagan — 产品运营模型简介（The Product Operating Model: An Introduction） 和 被赋权的产品团队（Empowered Product Teams）（svpg.com）；著作《启示录》（Inspired）、《赋能》（Empowered）和《转型》（Transformed）。
• Mik Kersten — 从项目到产品：如何借助流动框架在数字颠覆时代生存与繁荣（Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework）（IT Revolution，2018 年）。
• NHS England — NHS 服务手册和 NHS 数字服务标准。
• GOV.UK — 政府数字服务（Government Digital Service，GDS）服务手册与服务标准。
• NHS Digital 临床安全标准 DCB0129（健康 IT 系统的制造）和 DCB0160（部署）。
• John Doerr — 这就是 OKR（Measure What Matters），关于基于结果的目标设定。

参考文献#

1. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
2. Product lifecycle — Wikipedia — https://en.wikipedia.org/wiki/Product_lifecycle
3. Cross-functional team — Wikipedia — https://en.wikipedia.org/wiki/Cross-functional_team
4. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
5. Objectives and key results (OKR) — Wikipedia — https://en.wikipedia.org/wiki/OKR
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. NHS App — Wikipedia — https://en.wikipedia.org/wiki/NHS_App
8. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
9. The Product Operating Model / Inspired, Empowered, Transformed — Marty Cagan, Silicon Valley Product Group — https://www.svpg.com/
10. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/
11. NHS service manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/
12. GOV.UK Service Manual and Service Standard — Government Digital Service — https://www.gov.uk/service-manual
13. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
14. Measure What Matters — John Doerr — https://www.whatmatters.com/