10.1 组合与项目群管理

概述与动机

组合与项目群管理（programme management）是这样一门学科：决定一个大型工程组织应该构建什么，随着时间为这些工作提供资金，在众多团队之间对其排序，并将其引导至战略成果，而不是孤立的产出。单个团队靠非正式的对齐和一份共享的待办事项列表就能应付。而一个运营着数十甚至数百个团队的企业或政府机构则做不到。所有这些工作都在争夺同样稀缺的预算、同样稀缺的专业技能、同样共享的平台，以及同样有限的领导层注意力。没有一个刻意设计的组合层，你最终会得到局部最优化：每个团队都很忙碌，每份路线图看起来都合理，而整体所交付的战略价值却远低于应有水平。

对于大型团队而言，风险会不断累积。重复的工作、错位的优先级和未被管理的跨团队依赖，会悄悄地对每一项计划征税。一个某团队本可以在一个冲刺内交付的功能，却要等上三个季度，因为它依赖的平台团队从未听说过它。在政府场景中，这个问题更为尖锐。年度拨款、多年期资本资金、采购法规和公共问责制意味着，一个构架不良的项目群可能会让一个机构在错误的方向上锁定多年的承诺支出。因此，做好组合管理并不是官僚式的额外开销，而是大型组织将战略转化为已交付软件的方式。

本章把组合与项目群管理当作一项工程领导力关切，而不仅仅是项目管理办公室（PMO）的职能。其目标是把战略与目标同路线图连接起来，在真实约束下诚实地排定优先级，把依赖关系和供应商当作一等风险来对待，并驾驭预算与采购周期，尤其是主导公共部门工作的多年期资金节奏。

关键原则

重结果，轻产出。 为世界中的改变（采用率、成本、可靠性、使命成果）提供资金并加以衡量，而不是已交付功能的数量。
战略必须清晰可辨。 每个团队都应能把自己的工作追溯到少数几个已发布的目标上。
排定优先级即是做减法。 一个对一切都说”是”的组合没有战略；价值恰恰体现在你有意不做的事情上。
依赖关系才是真正的进度表。 对于大型组织而言，协调成本，而不是编码工作量，通常才是硬约束。
为持久的团队提供资金，而不是为临时项目提供资金。 稳定、与产品对齐的团队，胜过按项目重新组建的人员池。
让资金节奏与学习节奏相匹配。 分批承诺资金，使你能够随着证据到来而停止、转向或加码投入。
供应商是组合的延伸，而非组合之外的存在。 承包商和系统集成商的工作，必须以与内部工作同等的可见度进行治理。

建议

让工程与战略和 OKR 对齐

发布一小组组织级目标（理想情况下三到五个），并轻度地向下传导。让团队自行设定服务于这些共享目标的关键结果，而不是把已分配的任务直接派给他们。让传导链保持浅层：最多两到三级，否则战略与日常工作之间的联系就会变成一种虚构。按固定节奏评审目标（通常进展按季度评审，目标本身按年度评审），并公开地淘汰或重写那些已不再重要的目标。抵制把 OKR（目标与关键结果）变成绩效考核武器的冲动。一旦关键结果与个人奖金挂钩，团队就会故意压低目标，你就会失去这个信号。

带着意图和诚实的时间视野来制定路线图

在多个高度上维护路线图。组合路线图展示跨季度的主题和成果；团队路线图展示近期的可交付成果。围绕问题和成果来构建它们，且信心水平随时间推移而递减。“现在／接下来／以后”这样的时间视野，比带有具体日期、暗示虚假精确性的甘特图更能有效传达不确定性。按固定节奏重新审视路线图，并把它们当作对某个方向的承诺，而不是对遥远未来具体日期的合同。

使用明确的框架和有据可查的权衡来排定优先级

选择一种轻量、一致的优先级排定方法，并统一地加以应用，这样你就能在整个组合范围内进行比较。常见的选项包括加权评分法（价值、成本、风险、战略契合度）、延迟成本（一项有价值的交付每等待一个单位时间所放弃的价值）及其加权最短作业优先（WSJF）变体，以及 RICE（覆盖面、影响、信心、工作量）。没有任何公式能替你做决定。一个框架真正的价值在于，它迫使假设浮出水面，让领导者能够就此展开争论。始终记录下你正在做出的权衡（你推迟了什么、为什么），这样当事实发生变化时，你就能重新审视这个决定。

管理众多团队之间的依赖关系

在依赖关系咬人之前，让它们变得可见。维护一份依赖关系图或登记册，为每一项重要计划注明它需要从其他团队获得什么、以及截止到何时。使用一个定期的跨团队规划活动（在规模化框架中，季度性的大房间规划会议很常见）来公开地暴露和协商依赖关系。更好的做法是，通过设计把依赖关系消除掉：投资于自助式平台、有良好文档记录的 API 和清晰的内部契约，使团队能够不必相互等待就能推进。为每一个跨领域的依赖关系指定唯一的负责人。无人负责的依赖关系，正是项目群悄悄延误的地方。

治理供应商、承包商和系统集成商

把外部交付伙伴当作组合的一部分来对待。要求对他们的待办事项列表、速度、质量和风险，拥有与内部工作同等的可见度。围绕结果和分阶段交付的可运行软件来组织合同，而不是围绕文档量或坐席人数。保留足够的内部技术能力，用以明确规定工作内容、判断质量，并在供应商失败时能够接手。永远不要把”精明买家”这一职能外包出去。通过掌握自己的数据、要求开放接口，并从第一天起就坚持要求退出和过渡条款，来防范锁定。

驾驭采购、预算和多年期资金

理解你所处的资金节奏，并设计与之相匹配的项目群。尤其是在政府场景中，拨款可能是按年度进行的，而系统的构建却需要数年时间，这就产生了在年底前花完预算、以及过度扩大初始承诺范围的压力。用三种方式来应对这一点：把项目群构造成一系列各自独立创造价值的增量（模块化合同），在规则允许的地方争取增量式和敏捷式资金的授权，并建立真实的成本估算，把构建、运行和维持分开核算。尽早让采购、财务和法务部门参与进来（他们塑造可能性的程度，远超大多数工程师的想象），并把技术计划翻译成这些职能部门所需要的预算类别和财政年度边界。

权衡：优点与缺点

方式	优点	缺点
集中式组合控制	战略对齐强；重复工作少；更容易做资金权衡	决策变慢；可能压制团队自主性和局部创新
去中心化团队自主	团队快速、积极性高；尊重局部专长	重复工作；战略一致性弱；跨团队风险隐藏
按项目提供资金	每项计划的范围和问责都很清晰	团队频繁流动；短期主义；长期所有权薄弱
按产品／团队提供资金	持久的所有权；持续的质量	更难重新分配；存在为僵尸项目提供资金的风险
按公式排定优先级	透明、可比较、有据可依	虚假的精确性；输入值可被操纵；可能挤压判断力
多年期固定项目群	资金稳定；长周期投资	锁定早期假设；纠正方向代价高昂

核心张力存在于一致性与速度之间。中央控制过多，组织行动缓慢，还会挫伤最优秀人才的积极性。中央控制过少，组织就会碎裂成上百个局部最优。成熟的组织只把少数必须保持一致的事情集中管理（战略、共享平台、跨领域标准，以及资金权衡），并把执行决策尽可能下放给团队。资金稳定性与适应性之间的张力以同样的方式化解：不是二选一，而是针对持久的团队分批承诺资金，使人员的稳定性与方向的灵活性得以共存。

与团队讨论的问题

哪几件事必须在整个组织范围内保持一致？哪些决策应当下放给团队？ 组合管理中的核心张力是一致性与速度之间的取舍，而把这条界线划错，两边都代价高昂。集中过多，决策就会爬行，最优秀的人才也会失去自主权；集中过少，你就会碎裂成上百个局部最优，滋生重复系统和隐藏的跨团队风险。成熟的组织只在中心保留一份简短清单：战略、共享平台、跨领域标准，以及资金权衡。把证据带到会议上：数一数有多少团队在各自独立解决同一个问题，又有多少最近的决策因为等待中央批准而停滞。如果任何一个数字偏高，说明你把这条界线画错了地方，因此应该转移具体的决策权，而不是抽象地争论集中化本身。
在不失去项目制资金所赋予的那种问责性的前提下，你将如何为结果而不是为产出提供资金？ 为持久、与产品对齐的团队提供资金，胜过为临时项目提供资金，因为稳定的团队能持续保证质量，不仅仅负责构建，也拥有运行的责任。但问题在于：项目制资金给了领导者一个清晰的范围和明确的问责链条，而持续性的团队资金则可能在其前提早已失效很久之后，仍在悄悄为僵尸项目买单。解决办法是针对持久团队分批承诺资金，按季度节奏评审每个主题，并在主题之间重新分配产能，而不是解散团队。带上真正重要的证据：对于每一个获得资金的团队，上个季度哪项结果（采用率、成本、可靠性、使命成果）发生了变化，如果资金突然变得紧张，你会停止资助哪一项。如果你说不出那个结果是什么，那你资助的仍然是产出，而不是结果。
要想在采购供应商和系统集成商工作时保持”精明买家”的身份，你必须保留多少内部工程能力？ 当你把交付工作交给承包商或系统集成商时，问责仍然留在你这里，因此你需要足够的内部深度来明确规定工作内容、判断质量，并在供应商失败时能够接手。一旦失去这种能力，你得到的就是”人力外包”式合同：你买到的是工时而不是结果，也再也无法分辨自己是被服务，还是被俘获。要权衡的是，留住那些不亲自编写大部分代码的资深工程师所需的成本，相对于供应商锁定和使命被挟持所带来的远为巨大的成本。带上具体的信号：你的团队今天能否读懂供应商的待办事项列表、复现一次构建，并掌握数据和接口？从第一天起就坚持要求退出和过渡条款，因为争取谈判筹码的时机，是在签约之前，而不是在关系恶化之后。
在这个周期里，你有意不资助哪些计划？每个团队都能把这个”不”追溯回战略吗？ 排定优先级即是做减法，一个悄悄对一切都说”是”的组合没有战略；它只是把稀缺的产能摊得太薄，导致什么都做不好。对大型组织而言，这种损害是弥散的，因为没有任何一次单独的批准看起来是鲁莽的，但累加起来却让那几项真正能推动目标的押注失血。相互对立的力量是真实存在的：每一项被拒绝的计划都有一位相信它至关重要的发起人，而一个框架（加权评分、延迟成本、RICE）不会替你做决定，它只会迫使假设浮出水面，让领导者能够就此争论。带上排定优先级后的清单、为每一项推迟计划所记录的明确权衡，以及正在进行中的计划数量与你实际有能力完成的数量之间的对比。在企业和政府场景中，还要加上每一次拒绝所带来的政治代价，以及谁有权让这个”不”真正生效，因为一个任何发起人都可以通过升级来推翻的优先级决定，不是决定，只是一个建议。
你今天的跨团队依赖关系分布在哪里？你正在通过设计消除掉哪些依赖关系，而不仅仅是在跟踪它们？ 对大型组织而言，协调成本，而不是编码工作量，通常才是硬约束，因此一个某团队本可以在一个冲刺内交付的功能，可能会因为一个从未听说过它的平台团队而等上三个季度。在登记册中跟踪依赖关系让它们变得可见，但可见不等于解决；杠杆更大的做法，是通过自助式平台、有文档记录的 API 和清晰的内部契约，从根本上消除它们，让团队不再相互等待。这里的权衡在于，平台投资需要占用现在真实存在的产能，用以对抗日后才会悄悄累积的依赖延误，而资助那个看得见的功能，总是比资助那个看不见的平台更有诱惑力。带上你排名前列计划的依赖关系图、上个季度因为等待另一个团队而延误的交付数量，以及每一个跨领域依赖是否都有唯一的负责人。在数十个团队和外部集成商相互交织的企业和政府项目群中，指定一个能够尽早暴露这些问题的跨团队规划节奏，因为一个在集成阶段才被发现的依赖关系，本身就已经是一次进度失败。
你构建资金和合同的方式，是否与你实际学习的节奏相匹配？ 以大额多年期方式一次性承诺资金，会锁定你最早、信息最不充分的假设，然而许多资金制度（）尤其是年度政府拨款（）却在推动你过度扩大初始承诺范围、并在年底前花完预算。相互制约的考量在于，资金稳定性能让持久的团队为长周期进行投资，因此答案不是把合同切得极小，而是把资金分阶段、与已证明的成果挂钩，投入到一系列各自独立创造价值的增量中。带上你当前承诺的形态：在第一个可运行软件交付之前已经承诺了多少资金、成本估算是否把构建、运行和维持分开核算，以及在不浪费拨款的前提下，你最晚能到多迟才停止或重新调整方向。对企业和政府读者而言，采购和法务团队塑造可能性的程度，远超大多数工程师的预期，因此应尽早让他们参与，并在你假定自己需要一份单体合同之前，明确问一问现行规则已经允许哪些模块化合同和增量资金授权。

行业视角

初创企业。 只有几名工程师、跑道又短，创始人就是组合层本身，因此把它简化成一块白板：两三个已发布的结果，工作都钉在这些结果上，其余一切见到就砍掉。用几周内就能叫停的短期押注方式提供资金，而不是提前承诺一个季度，并跳过那些协调成本会超过所省下成本的框架、登记册和规划活动。你唯一真正的组合风险，是那几个你无法回避的外部依赖，因此为每一个指定一名负责人。

小型企业。 由于没有专职的 PMO 或项目群经理，组合管理是现有人员之间反复进行的一场对话，而不是一个需要招聘的岗位。对核心业务之外的一切，多依赖购买而非自建，并根据离开一个供应商的难易程度来评判它，因为当你缺乏迁移所需的人手时，锁定的伤害最大。维护一份诚实的清单，列明你正在资助什么、又有意不资助什么，并按固定、轻量的节奏重新审视它，使稀缺的预算流向那几项真正养活业务的结果。

企业。 在数十甚至数百个团队之间，任务是在不陷入僵局的前提下实现一致性：只把战略、共享平台、跨领域标准和资金权衡集中管理，把执行下放给团队。持续为持久、与产品对齐的团队提供资金，开展季度组合评审来在主题之间重新分配产能，并通过共享登记册和跨团队规划来管理依赖关系。在这种规模下，治理和审计是不容妥协的，因此要让供应商的工作和内部工作同样可见，并为每一次优先级决定记录下背后的权衡。

政府。 采购法规、年度拨款和公共问责制塑造着每一步行动。优先选择模块化合同，而不是单体式的多年期授标，分阶段提供资金并与已证明的成果挂钩，并在估算中把构建、运行和维持分开，使维持工作永远不会成为一个意外。保留一支内部”精明买家”团队，掌握自己的数据和接口，并在每一份合同中写入退出和过渡条款，因为透明度义务意味着一个失败的项目群会成为一次公开、被审计的事件，而不是一次悄悄的注销。

示例

初创企业。 一家十二人的种子期初创企业运营着两个小分队，创始人充当整个组合层。每周一，他们把工作只钉在两个已发布的结果上（）激活率和毛利率（）并公开砍掉任何两者都不服务的事情，因此一个看似亮眼的集成需求会被搁置，转而优先修复入职流程的流失问题。他们用短期押注而不是提前一个季度承诺来提供资金，并为那个他们无法回避的唯一外部依赖（）支付服务提供商（）指定了一名负责人，使它永远不会悄悄拖慢某次发布。

企业。 一家全球性银行在零售、支付和风控领域运营着一百多个交付团队。它召开季度组合评审，由一个小型高管团队把资金分配给十几个战略主题，每个主题由一对负责人共同带领：一位业务负责人，一位工程负责人。团队获得的是持续性资金，而不是按项目提供的资金。季度评审在各主题之间重新分配产能，而不是解散团队。一份共享依赖登记册和一场季度规划活动，及早暴露跨团队需求。结果是：意外延误更少，并且在市场条件变化时，能够在一个季度之内重新调整投资方向。

政府。 一家正在对一套已使用数十年的报税系统进行现代化改造的国家税务机关，放弃了单一的单体式多年期合同，转而采用模块化合同：一系列规模较小、各自独立创造价值的增量，每一个都交付公民可以使用的可运行软件。它请求分阶段提供资金，与已证明的成果挂钩，从而降低了大型项目群失败的风险。该机构保留了一支内部技术团队作为”精明买家”，掌握全部数据和接口，并在每一份供应商合同中写入明确的退出条款，使任何单一集成商都无法挟持这项使命。

商业论证：动机、投资回报率与总拥有成本

组合管理的回报来自三个来源：避免的浪费、更快的价值交付，以及更少的大型项目群失败。避免的浪费，是指你从未构建的重复系统，以及你从未资助的低价值计划（）因为组合视角让这种冗余变得可见。更快的价值来自于消除依赖关系，使团队不再相互等待。然而最大的回报，是风险的降低。大型软件项目群失败或严重超支的比率很高，而一次被避免的多年期失败，其价值就可能远远超过整个组合职能的全部成本。

采纳的成本是真实存在的：组合与项目群角色、规划节奏、工具，以及这一切所消耗的协调时间。不采纳的成本则更大，但更加弥散，因此很容易被忽视：未经协调的支出、投入在错位工作上的沉没成本，以及依赖延误在每一项计划中不断累积的拖累。在向领导层论证时，应把组合管理构建为这样一种机制：它把他们的战略转化为交付成果，并保护他们免受足以断送职业生涯的大型项目群失败之害。展示构建、运行和多年期维持的全部总拥有成本，而不只是初始构建成本，因为只为构建提供资金的领导者，总会对运行成本感到意外。

反模式与陷阱

HiPPO 式优先级排定。 决策由”薪水最高的人的意见”驱动，而不是由证据或一致同意的框架驱动。
把路线图当作日期承诺。 把遥远未来的日期当作承诺发布，然后按日历而不是按结果来管理进度。
一切都是第一优先级。 一个没有明确说”不”的组合，把稀缺的产能摊得太薄，导致什么都完不成。
对依赖关系视而不见。 在集成阶段才发现跨团队依赖关系，而不是在规划阶段就发现。
人力外包式合同。 购买承包商的工时而不是结果，并失去内部判断质量的能力。
不花就浪费式支出。 年底预算冲刺，为避免退回拨款而资助低价值工作。
把 OKR 当作管控塔。 把目标变成已分配的任务和考核指标，摧毁了它们本应提供的诚实信号。
僵尸项目群。 多年期的努力，仅凭惯性就在其前提早已失效很久之后，依然在持续获得资金。

成熟度模型

第一级，启动： 优先级是临时设定的，随着谁的声音最大而改变。没有组合视角，因此依赖关系是作为集成阶段的危机才浮现的，重复系统也无人察觉。供应商是按合同量而不是按结果来管理的，资金则跟随年底的年度冲刺而定。

第二级，发展： 存在一份组合清单，并定期评审，但实践因团队而异。目标已被发布，但与日常工作的联系薄弱；一些团队维护依赖登记册、按结果管理若干供应商，另一些团队则两者都没做。预算可预测，但仍是按项目进行的，因此问责比战略一致性更清晰。

第三级，标准化： 战略通过一个浅层的 OKR 结构清晰地向下传导给团队，一套优先级排定框架被形成文档并应用于整个组合。跨团队规划活动在依赖关系造成损害之前就将其暴露出来，团队获得的是持续性资金而不是按项目提供的资金，模块化合同和增量资金在全组织范围内是常态，而不是局部实验。

第四级，管理： 组合被对照基准进行衡量，而不只是被记录在案。领导者跟踪每个已获资助主题的结果变化、排名靠前计划的延迟成本、依赖延误率、供应商相对于约定结果的交付表现，以及与已证明成果挂钩的承诺支出占比。优先级权衡和终止标准基于这些证据被严格执行，成本和进度的预测与实际之间的偏差驱动每一项资金决策，而不是靠游说。

第五级，编排： 组合、项目群和风险规划是整合在一起的，组合随着证据的到来而持续被重新平衡。依赖关系大多已通过平台和清晰的内部契约被设计消除，供应商工作和内部工作共享同一套价值与风险视角，资金节奏与学习节奏相匹配，使组织能够在不引发混乱的情况下，例行性地停止、重新调整方向或重新界定工作范围。

讨论议题

一个 OKR 传导链要浅到什么程度才会失去对工作的指导作用？又要深到什么程度才会变成一种虚构？
一个优先级排定公式在什么时候能改善决策？又在什么时候只是在为某人预先设定好的答案洗白？
平台团队应该由中央预算提供资金，还是应该向使用它们的团队收取费用？这会如何改变它们的激励机制？
在政府场景中，在现行拨款法规框架内，你能把增量式和模块化资金推进到多远，才需要立法修改？
如何在不被报告开销淹没的前提下，让供应商的工作与内部工作同样可见？
当一个持久团队的产品失去战略相关性时，正确的应对是什么：重新部署人员，还是解散重建？

关键要点

组合管理通过决定资助什么、以何种顺序资助、在众多团队之间如何分配，把战略转化为已交付的软件。
通过做减法来排定优先级，并记录下这些权衡；一个对一切都说”是”的组合没有战略。
对大型组织而言，跨团队依赖关系，而不是编码工作量，通常才是硬约束；要让它们变得可见，并通过设计消除它们。
为持久、与产品对齐的团队提供资金，并分批承诺资金，使人员的稳定性与方向的灵活性得以共存。
把供应商当作组合的一部分来治理，把”精明买家”职能留在内部，并通过掌握数据所有权和退出条款来防范锁定。
在政府场景中，把项目群构造成一系列各自独立创造价值的增量，以适应多年期资金周期，降低大型项目群失败的风险。

参考文献与延伸阅读

Donald G. Reinertsen, The Principles of Product Development Flow
Marty Cagan, Inspired and Empowered
John Doerr, Measure What Matters
Christina Wodtke, Radical Focus: Achieving Your Most Important Goals with OKRs
Mik Kersten, Project to Product
Jez Humble, Joanne Molesky, and Barry O’Reilly, Lean Enterprise
Project Management Institute, The Standard for Portfolio Management
Axelos, Managing Successful Programmes (MSP)
U.S. Digital Service, Digital Services Playbook
UK Government Digital Service, Service Manual and Technology Code of Practice
U.S. Government Accountability Office, Agile Assessment Guide