10.6 项目管理

Overview and motivation

项目管理是在各种约束条件下,把意图转化为已交付成果的学科。你要协调人员、范围、进度、成本、风险和质量,使工作真正完成并交付价值。在软件领域,这门学科常常被人怀疑,被与那些现实会置之不理的重量级计划和甘特图绑在一起。但其背后的真实需求从未消失。总得有人确保正确的工作按正确的顺序进行,依赖关系得到管理,风险及早浮现,利益相关者知道该期待什么。问题不在于要不要管理项目,而在于能以多轻量、多自适应的方式进行管理,同时仍能履行你的义务。

为什么要把这件事明确地提出来讨论?软件项目的失败率高得惊人,而且失败的原因更多是管理层面的,而不是纯技术层面的:范围不清、依赖关系失控、风险未被处理、利益相关者缺席,以及对精确长期估算的幻想。大型项目尤其容易受此影响:团队多、供应商多、跨越多个季度的时间跨度,小小的协调失误就会不断累积放大。好的项目管理在很大程度上,就是诚实地做出承诺、合理地拆解工作、并建立快速反馈机制,使问题在还便宜易改的时候就浮出水面这样一种实践。

企业和政府场景提高了赌注,也改变了约束条件。企业要在战略和预算周期(第 10.1 章)之下管理一系列相互关联的项目组合。政府还要加上采购规则、跨年度的拨款、承包商管理和公共问责。在这些场景中,历史上默认的做法(大型的、范围固定的瀑布式合同)长期以来都有昂贵而显眼的失败记录。本章涵盖了适用于预测型、自适应型和混合型方法的基本原理。第 10.7 章(敏捷)会深入探讨自适应交付,第 10.1 章则涵盖单个项目之上的组合和项目群管理。

Key principles

管理结果,而不是活动。 “完成”意味着交付了价值,而不是关闭了任务。
拆解并排序。 小规模、有序、意识到依赖关系的工作,胜过大爆炸式的计划。
估算是范围,而不是承诺。 诚实地沟通不确定性。
及早并持续地暴露风险。 最便宜的问题,就是最先被发现的问题。
让方法匹配工作本身。 预测型、自适应型或混合型:要契合不确定性和约束条件。
让状态透明可见。 可见的流动胜过让人安心的报告。
利益相关者是团队的一部分。 客户的缺席本身就是一项项目风险。

Recommendations

Choose predictive, adaptive, or hybrid deliberately

不存在普遍正确的交付模型;只有方法与场景之间的契合度:

预测型(计划驱动,“瀑布式”): 范围事先固定,进度和成本随之推导得出。适合需求真正稳定、被充分理解,且存在硬性外部约束(监管认证、物理集成)的工作。它的失败模式是假装软件需求是稳定的,而实际上并非如此。
自适应型(敏捷): 范围可以灵活变化;时间和成本在短迭代周期内固定,每个迭代交付可运行的软件,并吸收学习所得。适合大多数产品和数字服务类工作,这类工作的需求是被逐步发现出来的(第 11.1 章、第 10.7 章)。
混合型: 在预测型治理外壳之内包裹一个自适应型核心,这在企业和政府场景中很常见,也往往是正确的选择（）那里的资金拨付、合规和合同要求里程碑和审计,而交付工作又能从迭代中受益。

诸如 PMBOK(项目管理知识体系,来自项目管理协会)和 PRINCE2(受控环境中的项目管理)这样的框架,把预测型和混合型实践加以规范化。关键在于借鉴它们的纪律(角色、风险、阶段关卡),而不必引入工作本身并不需要的繁文缛节。

Manage scope against the triple constraint

范围、进度和成本会一起变动,并受质量所约束:这就是经典的“铁三角”。你不能三者都固定住,还免费地增加范围。总得有什么要让步,假装并非如此正是死亡行军的开端。把这些权衡明确地摆出来,并决定哪个变量可以灵活变动。自适应方法固定时间和成本,让范围灵活变动。固定价格合同固定范围和成本,而现实中,除非你主动管理,否则质量或进度就会被动地变动。用一个轻量级的变更流程(第 12.3 章)来控制范围蔓延,并优先选择收缩范围到有价值的核心,而不是让所有事情都往后拖延。

Estimate honestly, in ranges, and re-forecast

估算正是项目最容易自欺欺人的地方。把估算当作概率范围,而不是单一数字,并对遥远、尚未被充分理解的工作拉宽这个范围(“不确定性锥”)。优先选择相对性和经验性的方法:历史吞吐量和周期时间(第 11.2 章、第 11.3 章)的预测效果,好于英雄式的自下而上猜测。在可能的地方,用测量来取代估算。一个每周完成 8 个条目的团队,完成 40 个条目大约需要 5 周时间,无论故事点是多少(利特尔法则再次出现:决定交付时间的是吞吐量和在制品数量,而不是估算)。要随着现实情况的到来持续重新预测。一份从不改变的计划,并不是被管理着的计划。

Manage dependencies and the critical path

在规模化场景下,主导性的风险很少是某个单一团队的速度问题。而是团队与供应商之间的依赖关系。明确地把它们绘制出来,识别出关键路径(决定最早完成时间的那条工作序列),并优先攻克最长、风险最高的依赖关系。在可能的地方减少耦合(消除一个依赖,比追踪一个依赖更有价值),并使用清晰的接口和契约,使各团队能够并行推进(第 1.2 章、第 2.3 章)。对于跨团队的项目群,定期的依赖和风险同步会议,胜过一份没有人会读的状态报告。

Run a living risk register

风险管理是杠杆效应最高的项目管理活动,也是最常被省略的活动。维护一份简单的、持续更新的风险登记册:每一项风险都记录其可能性、影响、负责人,以及缓解或应急方案(第 12.3 章)。定期评审它,退役已经过去的风险,并随着新风险出现而添加进去。要把风险(可能发生)、问题(已经在发生)和决策(第 1.6 章)区分开来。目标不是一份文档,而是一种向前看的习惯,让你能够预见问题,而不是在截止日期才发现它们。

Engage stakeholders and communicate transparently

大多数”意外的”项目失败,其实早就被某个没有被倾听的人看在眼里。识别利益相关者,理解他们的关切,并让他们真正地参与进来。客户的缺席本身就是头号风险之一。通过透明的流动(可见的看板、燃起图、演示过的可运行软件)来沟通状态,而不是那种奖励乐观情绪的红黄绿报告。要诚实、及早地升级问题。一个运作良好的项目,会让坏消息传播得很快。

Trade-offs: pros and cons

Approach	Pros	Cons
预测型 / 瀑布式	范围和成本可预测;对合同和审计友好	不适合不确定的需求;反馈滞后;大爆炸式风险
自适应型 / 敏捷	反馈快;能吸收变化;及早产生价值	事先固定范围/成本更困难;需要客户深度参与
混合型	在治理框架内迭代;适合企业/政府场景	节奏之间存在张力;可能同时继承两种开销
详尽的事前估算	让规划者和出资方感到安心	精确地错误;制作成本高;很快就会失去时效性
经验性预测(流动指标)	有据可依、能自我修正	需要历史数据和纪律;看起来不那么”确定”
繁重的风险/流程仪式	全面细致;适合高风险项目群	拖慢小团队;可能沦为打勾了事

核心张力在于可预测性与适应性之间。出资方、合同和审计要求牢固的承诺。而不确定的软件工作则需要学习和调整的空间。像敏捷(第 10.7 章)那样化解这一张力:对结果和截止日期做出坚定的承诺,同时让范围灵活变动,并用混合型治理来满足监督要求,同时又不冻结交付进度。

Questions to discuss with your team

你们要如何把自适应交付团队包裹在预测型治理外壳之中,而不同时继承两者各自的开销? 混合型在企业和政府场景中很常见,也往往是正确的选择（）那里的资金周期、合规和合同要求里程碑和审计,而交付工作又能从迭代中受益。这里的风险是真实存在的:一个设计糟糕的混合模式,会同时继承瀑布式繁重的文档工作和敏捷式的各种仪式,团队会切身感受到两种节奏相互冲突所带来的摩擦。带上证据:把你们的资金关卡、合规检查点和合同里程碑实际落在哪里绘制出来,检查每一个是否都要求一份交付工作本身原本不会产生的文档。答案应当让迭代去满足监督要求,而不是与之对抗,做法是把演示过的可运行增量和一份持续更新的风险登记册,直接输入治理节奏之中,而不是停下来另行组装报告。借鉴像 PRINCE2 这样的框架的纪律,而不引入工作本身并不需要的繁文缛节。
你们的项目状态是透明的流动,还是奖励乐观情绪的红黄绿报告? 大多数意外的失败,其实早就被某个没有被倾听的人看在眼里,而”西瓜式”状态汇报(外面是绿的,里面是红的)正是诚实的坏消息一直被埋没、直到截止日期才浮出水面的原因。用可见的看板、燃起图和演示过的可运行软件,来取代那种让人安心的报告,并让”及早升级问题”成为一件安全的事,而不是一种职业风险。带上证据:回顾你们最近一个出问题的项目,问一问第一个预警信号出现的时间,和管理层听到它的时间之间相差多久。客户的缺席本身就是头号风险之一,因此要检查是否有一位真正参与其中的利益相关者,还是你们正满怀信心地朝着错误的方向前进。一个运作良好的项目会让坏消息传播得很快,而修复这一点,靠的是文化上的努力,不亚于工具上的努力。
如果进度和成本不再能够移动,你知道自己会收缩到哪个最小的有价值核心吗? 范围、进度和成本会一起变动,并受质量所约束,而当出资方把三者都固定住时,质量就会成为那个无声的泄压阀,死亡行军也由此开始。自适应方法固定时间和成本,让范围灵活变动,而这只有在你已经决定好哪一部分能交付真正的价值、哪些功能是可以协商的情况下才行得通。带上证据:对于你们当前的这次发布,你能说出必须出货的核心内容,以及会最先被砍掉的清单吗,还是每一项功能都被悄悄当成了必需项?答案应当让你能够收缩到一个有价值的核心,而不是让所有事情都往后拖延,而且这件事应当在压力到来之前就已敲定,而不是在截止日期临时想办法。用一个轻量级的变更流程来控制其余部分,以免范围蔓延吞掉你原本指望的那部分余量。
此刻,哪一个跨团队依赖关系正处于你们的关键路径上?谁负责消除它或降低它的风险? 在规模化场景下,主导性的威胁很少是某个团队的速度;而是团队与供应商之间的依赖关系序列,正是它决定了最早可能的完成时间。如果没有人能说出当前处于关键路径上的依赖关系,那你们管理的就只是局部进度,而真正决定你们交付日期的那件事却在无人关注中悄悄漂移。带上证据:一份依赖关系图,展示哪些交接环节供给哪些后续环节、最长的链条在哪里运行、哪些环节仍未建成或被合同条款卡住,再加上每个高风险环节的具名负责人。目标是优先攻克最长、风险最高的依赖关系,并在可能的地方消除耦合,因为消除一个依赖比追踪一个依赖更有价值。在企业和政府项目群中,最棘手的环节往往跨越供应商或机构的边界,因此要在双方各自指定负责的负责人,并确认合同允许他们采取行动,否则这个依赖关系就会一直悬而未决,直到它变成一次公开的延误。
随着现实情况的到来,你们是如何重新预测的?一次延误要多快才能被资助这项工作的人看到? 一份从不改变的计划,不是被管理着的,而是被捍卫着的,而一个被捍卫到超出证据支持范围的单一日期,正是项目在无声无息中拖延、直到截止日期才暴露的方式。尽可能用测量来取代估算,依据历史吞吐量和周期时间进行预测,而不是英雄式的自下而上猜测,并对遥远、尚未被充分理解的工作拉宽范围。带上证据:你们实际的每周完成速率、当前的待办事项规模,以及由此得出的预计完成时间,并与管理层目前相信的日期做对比。答案应当给出资方一个诚实的、不断收窄的预测,让他们每个周期都能看到,而不是一个一直维持到崩溃为止的固定日期。在政府及其他受拨款约束的场景中,一份能及早暴露延误的预测,能让你在规则允许的范围内重新界定范围或重新确定基线,而一次被隐藏的延误则会变成一次监督失败和一条头条新闻。
在仍能履行你们真实义务的前提下,最轻量的流程是什么?哪些繁文缛节已经脱离了降低风险这个目的? 管理不足和管理过度都有真实的代价:一边是混乱、返工和被遗漏的依赖关系,另一边是拖慢交付、却并未降低风险的打勾了事。这里的张力在于,审计、合规和合同条款确实施加了真实的要求,但团队往往会在某个仪式早已不再发挥作用之后,依然把它保留很久。带上证据:对每一份反复出现的报告、每一道关卡、每一次会议,说出它所对应的具体义务或风险,并标记出任何一个无法追溯到二者之一的仪式。答案应当让你能够退役那些只是提供心理安慰的仪式,同时保留那些能满足真正的审计人员或出资方要求的工件。在企业和政府场景中,把每一项仪式对应到它所服务的具名拨款、采购或监管规则上,这样你就能有依据地向监督方论证削减其余部分是合理的,而不是靠猜测合规到底要求什么。

Sector lens

Startup. 以几乎没有仪式感、但有真正纪律的方式来管理。把发布拆解成小的、有序的切片,承诺一个发布日期,同时让范围灵活地收缩到一个有价值的核心,并给创始人一个范围而不是一个单一日期,每周根据你们实际关闭了多少个切片来重新预测。在一份共享文档中写一份十行的风险登记册,列出唯一一个可能拖垮发布日期的依赖关系,并配上负责人和退路方案,这比任何工具都更有价值,因为你最稀缺的资源是注意力,而一次发现得太晚的延误可能会终结整个公司。

Small business. 你没有项目经理,也没有多少余力,因此要依靠你们已经在用的工具,而不是搭建一个治理办公室。在一块可见的看板上追踪工作,维护一份简短的、持续更新的风险清单,并优先购买现成的排期或工单产品,而不是从零开始构建流程。事先决定好这次发布必须出货哪一个单一功能才值得做,因为一旦进度收紧,你不会有多余的人手在当下临时协商范围。

Enterprise. 这里的难题是在众多团队、供应商和资金周期之间进行协调。把自适应团队包裹在一个预测型治理外壳之中,把演示过的增量和一份持续更新的风险登记册直接输入里程碑节奏之中,而不是另行组装报告,并维护一份跨团队依赖关系图,使关键路径是被主动管理的,而不是被动发现的。在整个项目组合中统一采用基于范围、并经经验性重新预测的估算方式,使管理层能够依据诚实的、不断收窄的预测来比较各个项目,而不是依据乐观的固定日期。

Government. 采购规则、跨年度拨款和公共问责塑造着每一个决策。优先选择在一个满足拨款和监督要求的治理框架下、以自适应方式交付的模块化、基于结果的增量,而不是一份带有遥远上线日期的固定价格、固定范围的瀑布式合同。一份持续更新的风险登记册和透明、经演示的增量,能让审计人员和立法者获得真实的可见性,而在固定资金内把范围灵活地收缩到一个有价值的核心,能让你及早交付有用的能力,而不是把一切都押在某一个日期上。

Examples

Startup. 一家七人规模的初创公司正争分夺秒地发布其第一款付费产品,他们以几乎没有仪式感、但有真正纪律的方式来管理这个项目。他们把发布拆解成小的、有序的切片,承诺一个发布日期,同时让范围灵活地收缩到一个有价值的核心,而不是承诺每一项功能都会实现,并给创始人一个范围而不是一个单一日期,每周根据团队实际关闭了多少个切片来重新预测。一份共享文档中的十行风险登记册,列出了唯一一个可能拖垮发布日期的依赖关系（）一项尚未完成的支付集成（）并配上了负责人和退路方案,这样最大的威胁是被持续关注着的,而不是在截止日期才被发现。

Enterprise. 一家正在替换其贷款发放平台的银行,运行着一个混合型项目:一个带有季度资金里程碑和合规关卡的预测型外壳,包裹着每两周交付一次可运行增量的自适应团队。一份跨团队依赖关系图揭示出,一项共享身份服务正处于关键路径上。因此项目群把它排在最前面并降低其风险,避免了后期的连锁延误。估算以范围的形式表达,并每月依据实际吞吐量重新预测,因此管理层看到的是一个诚实的、不断收窄的预测,而不是一个悄悄拖延的固定日期。

Government. 某机构放弃了一份单一的固定价格、固定范围的瀑布式合同(这正是多起公共失败案例背后的模式),转而采用模块化采购:在一个满足拨款和监督要求的治理框架下,以自适应方式交付更小的、基于结果的增量。一份持续更新的风险登记册和透明、经演示的增量,让审计人员和立法者获得了真实的可见性。由于范围能在固定资金内灵活地收缩到一个有价值的核心,该项目能够及早交付有用的能力,而不是把一切都押在某一个遥远的上线日期上(第 10.1 章、第 10.3 章)。

Business case: motivations, ROI, and TCO

良好项目管理的回报,主要体现为避免的失败。大型软件项目迟交、超支或被取消的可能性,要远高于按原始的固定计划完成的可能性,而其损失是巨大的:沉没成本,加上放弃掉的价值,在政府场景中,还要加上公共和政治层面的损害。本章所述的这些学科(诚实的估算、依赖关系管理、及早的风险工作、深度参与的利益相关者,以及自适应的范围)正是能把一个项目从失败曲线上拉回来的那些做法。哪怕只是适度降低重大超支或取消的概率,其价值也远超把项目管理好所需的成本。

在总拥有成本方面,轻量级的自适应管理降低了整个工作生命周期内的成本。快速反馈能及早发现代价高昂的错误。增量交付能更早开始产生价值回报,从而改善投资回报的时机。透明的流动减少了繁重治理所带来的汇报开销。管理不足(混乱、返工、被遗漏的依赖关系)和管理过度(拖慢交付的仪式)都有真实的代价。目标是找到能满足你真实义务的最轻量流程。向管理层论证这一点时,可以把最近一个出问题的项目的全部成本,与一份风险登记册、一份依赖关系图,以及诚实的、基于范围的预测这些近乎零成本的做法做对比。

Anti-patterns and pitfalls

一切都固定的计划: 范围、进度和成本全部锁死,质量沦为无声的泄压阀。
把估算当作承诺: 把单一数字的日期当作承诺来对待,然后一路捍卫到超出证据支持的范围。
忽视依赖关系: 管理着每个团队的速度,而跨团队的关键路径却在悄悄延误。
风险登记册表演: 一份创建一次之后再也没人回顾过的文档。
西瓜式状态汇报: 外面是绿的,里面是红的;乐观情绪被奖励,而诚实却没有。
客户缺席: 没有真正参与的利益相关者,于是满怀信心地做出了错误的东西。
大爆炸式交付: 一切都在最后才集成和发布,把风险推向最大化(与第 11.2 章对比)。
为流程而流程: 消耗精力、却并不降低风险的仪式和报告。

Maturity model

Level 1 (Initiate): 项目依靠个人英雄主义和侥幸运作;范围、风险和依赖关系即便有人管理,也是随意的;估算是被捍卫到超出证据支持范围的单一数字;意外总是在截止日期才出现。
Level 2 (Develop): 部分项目上存在基本的规划、状态汇报和风险清单,另一些项目上则没有;交付方法是凭习惯选择的,而不是依据契合度;估算和依赖关系追踪因团队而异,因此整个组织的实践并不一致。
Level 3 (Standardize): 一套有文档记录的方法在整个组织范围内被强制执行:交付方法依据工作本身来选择,范围依照铁三角来管理,每个项目都被期望维护一份持续更新的风险登记册和依赖关系图,估算以范围的形式表达,并随着利益相关者的深度参与而重新预测。
Level 4 (Manage): 交付被对照基线加以度量和管控。吞吐量、周期时间、预测准确度、依赖关系和风险的结案率,以及进度和成本偏差,都按项目追踪,并汇总到整个组合层面;预测是经验性的、不断收窄的;延误会及早浮现,并依据证据、而不是乐观情绪来触发重新界定范围或重新确定基线。
Level 5 (Orchestrate): 项目管理与组合管理、资金规划和风险规划相整合,并持续改进。混合型治理满足了监督要求,同时又不拖慢交付,跨团队和跨供应商的依赖关系被主动管理,回顾会议把经过衡量的改变反馈回实践之中,组织会随着约束条件和优先级的变化而调整方法、重新平衡工作。

Ideas for discussion

你们当前的每一项计划,实际上需要哪种交付方法(预测型、自适应型、混合型)?它与你们正在使用的方法相匹配吗?
你上一次承诺一个日期时,给出的是一个范围还是一个单一数字?这如何影响了期望?
此刻,跨团队之间处于关键路径上的依赖关系是什么?谁负责降低它的风险?
你们的风险登记册是一个持续更新的习惯,还是一份一次性的文档?
当范围、进度和成本全部固定时,质量正在悄悄承受哪些压力?
如果你用测量到的吞吐量取代估算,你们的预测会有怎样的变化?

Key takeaways

项目管理是在范围，进度，成本，质量的约束条件下,把意图转化为已交付成果。
让方法匹配工作: 预测型、自适应型或混合型,并在企业/政府场景中优先选择混合型治理。
把估算当作范围来对待,依据经验性的流动指标重新预测,不要让单一数字的日期变成谎言。
依赖关系和风险是规模化场景下主导性的失败模式:要持续地绘制并管理两者。
保持利益相关者的深度参与和状态的透明;让坏消息传播得快。
投资回报体现为避免的失败;能满足你义务的最轻量流程才是赢家。参见第 10.7 章(敏捷)、第 10.1 章(组合与项目群管理)、第 11.2 章(交付)和第 11.3 章(排队论)。

References and further reading

Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide).
AXELOS, Managing Successful Projects with PRINCE2.
Frederick Brooks, The Mythical Man-Month (why adding people to a late project makes it later).
Tom DeMarco and Timothy Lister, Peopleware and Waltzing with Bears (risk management).
Steve McConnell, Software Estimation: Demystifying the Black Art.
Daniel Vacanti, Actionable Agile Metrics for Predictability (empirical forecasting).
Standish Group, CHAOS Report (software project outcomes, read critically).
U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard (modern public-sector delivery).
Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (megaproject delivery).