第 8 章 软件项目管理

学习目标

• 掌握软件成本估算的常用方法(专家判断、功能点、COCOMO、类比)
• 理解进度计划(CPM/关键路径)与缓冲管理
• 掌握风险识别、量化与应对
• 理解敏捷与传统项目在计划与度量上的差异
• 熟悉团队组织与沟通管理要点
• 掌握项目沟通与期望管理

8.0 项目管理与过程的关系

第 2 章定义"做什么、谁做、产出什么",本章回答"何时完成、花多少钱、风险多大、人怎么用"。两者正交但耦合:过程是骨架,管理是让骨架按时交付的肌肉。OOS 的 PM 不写代码,但对"每个迭代承诺什么、风险清单长什么样、发布窗口何时冻结"负全责。

8.1 项目管理的独特性

软件项目与硬件/工程项目相比:

• 产品不可见
  (直到接近完成),进度难以直观判断;
• 需求易变
  ,范围是最常突破的约束;
• 质量难以"事后检验"
  ,缺陷深藏在逻辑中;
• 知识工作
  ,个体差异大,生产率难以线性叠加(加人不一定快,沟通成本平方增长)。

因此项目管理重心:尽早暴露不确定性(风险驱动)、用反馈代替预测(迭代)、管理范围与期望(而非只压工期)。

软件项目失败的常见根因(经验清单)

8.2 成本与工作量估算

常用方法

各方法要点与陷阱

• 德尔菲
  :独立估算(防锚定)→ 差异 >30% 时讨论 → 再估,2–3 轮收敛;陷阱:权威在场时独立性消失;
• 功能点
  :数"用户可见的逻辑实体"(输入/输出/查询/文件/外部接口),按复杂度加权;陷阱:数得仔细但转换系数(每功能点人天)必须用本团队历史数据,套行业均值误差大;
• COCOMO
  :a、b 为模型常数(基本 COCOMO 约 E=2.4·KLOC^1.05 量级,依模型版本),乘一组调整因子(可靠性、团队经验、工具…);陷阱:输入因子拍脑袋则输出纯噪声;
• 类比
  :找到最相似的 2–3 个历史项目,按规模/复杂度/团队差异修正;陷阱:"相似"的幻觉——技术栈相似 ≠ 业务复杂度相似;
• 计划扑克
  :用斐波那契数列(1/2/3/5/8/13)相对估;高卡先发言者说理由,再同时亮牌,分歧 >2 倍时讨论;陷阱:沦为"投票"而非"信息交换"。

估算纪律

• 范围与估算绑定
  :估算必须附"包含/不包含"清单,否则数字无意义;
• 三点估算
  :乐观 O / 最可能 M / 悲观 P,期望 = (O + 4M + P)/6;
• 留缓冲但要标注
  :区分"估算值"与"承诺值",缓冲是管理决策不是估算误差;
• 校准
  :定期对比估算 vs 实际,积累自己的历史数据(这是最值钱的资产);
• 警惕"好估计的诅咒"
  :用平均生产率估算平均结果会高估风险——用团队中位数而非最优值。

OOS 估算示例:核心下单模块,类比历史项目 12 人月,三点估算 O=10, M=14, P=20 → 期望 14 人月,承诺 18 人月(含 25% 缓冲)。

估算质量自检

1. 估算附范围清单了吗?(无范围 = 无意义)
2. 用的是"团队中位数生产率"还是"英雄生产率"?
3. 缓冲放在哪一层?(建议:承诺层放缓冲,估算层保持诚实)
4. 有没有记录"估算 vs 实际"供下次校准?
5. 高风险项(外部依赖)单独估了吗?(它们常是 P 值的主因)

8.3 进度计划

关键路径法(CPM)

• 活动网络图:任务 + 依赖 + 工期;
• 关键路径
  :最长依赖链,决定项目最短工期;关键路径上任何延迟 = 项目延迟;
• 松弛(float)
  :非关键路径任务的可用延迟量;
• 管理重点:盯关键路径,而非平均盯所有任务。

OOS CPM 示例(发布 1 前的简化网络):

需求(3w) → 架构(2w) → 下单模块(6w) → 支付联调(3w) → 系统测试(3w) → 发布              ↘ 支付SDK预研(2w,与架构并行) ↗(联调前置)

关键路径:需求→架构→下单→支付联调→测试→发布 = 17 周;支付 SDK 预研松弛 1 周。管理动作:每周检查关键路径任务的实际 vs 计划;联调环境申请(T-4 周)设为前置触发项(见 8.4 R1)。

缓冲与不确定性

• 关键链法(CCT)
  :移除任务级冗余缓冲,集中为项目级缓冲(50% 集中),缓冲燃尽图监控;
• 帕金森定律对策:承诺基于估算 + 缓冲,而非"希望压缩";
• 里程碑应可验证(产出物 + 验收标准),不是"完成 50%"这类模糊表述。

里程碑写法对比:

• 模糊:“需求完成 60%”(无法验证,必然争议);
• 可验证:“SRS v1.0 通过评审(问题清单闭环),评审记录签字”(工件 + 判据)。

迭代项目中的进度

• 用速度(velocity):团队每迭代实际完成的故事点,预测未来容量;
• 发布预测 = 剩余工作量 / 平均速度(给区间,不给单点);
• 范围管理:迭代内范围冻结,迭代间可调。

速度的使用纪律:

1. 用已完成故事的点(未完成不计);
2. 取最近 3–5 个迭代均值,不取最佳值;
3. 速度突然上升/下降先查原因(范围定义变了?人变了?),再更新预测;
4. 速度是容量工具,不是 KPI——用速度考核会催生"往故事里塞点"。

8.4 风险管理

流程

识别 → 定性评估(概率×影响) → 量化(关键风险) → 应对规划 → 监控

识别技巧:

• 头脑风暴 + “事前验尸”(假设项目已失败,倒推死因);
• 检查清单:人员 / 需求 / 外部依赖 / 技术新颖度 / 数据 / 合规 / 进度压力;
• 新风险主要出现在需求变更与外部承诺之后 → 变更后强制风险刷新。

风险登记册(示例:OOS)

登记册字段纪律:每条风险必须有负责人与触发指标(可观察的"风险正在发生"信号)。没有触发指标的风险 = 无法监控 = 纸上谈兵。

应对策略

• 规避
  :改变计划使风险不发生;
• 缓解
  :降低概率或影响(最常用);
• 转移
  :外包、保险、SLA 约束;
• 接受
  :主动(留应急储备)或被动(发生了再说,仅限低等级)。

风险升降级机制:月度检视,按触发指标与最新信息重评概率/影响;等级上升 → 升级应对(如 R1 触发 → 启动备用渠道预研);连续两月无变化且概率下降 → 可归档。

经验:风险最大的往往不是技术,而是人(关键依赖)、需求(蔓延)、外部接口(联调)。技术风险用原型/预研消除(螺旋思想)。

8.5 团队与组织

规模与结构

• 核心开发团队 ≤9 人(两个披萨),超过则拆小队,各队有独立目标;
• 康威定律
  :系统结构终将镜像组织沟通结构——想要微服务边界清晰,先对齐团队边界;
• 汇报链短,减少信息失真。

知识管理(对抗 R3 类风险)

沟通管理

• 沟通渠道数 = n(n-1)/2,10 人团队 45 条——用机制代替闲聊:每日站会、看板、周报模板;
• 书面化关键决策(ADR、会议纪要),避免"会上说好的";
• 外部干系人:固定节奏演示(OOS 双周演示),管理期望比汇报进度更重要。

期望管理三件套:

1. 展示节奏
   :双周演示让业务方"看见"进展,替代百分比汇报;
2. 坏消息快
   :风险触发 24 小时内上报,附应对方案(只报选项不报"救我");
3. 范围透明
   :待办列表公开,优先级变化可见——"没做"与"不做"对业务方同样重要。

8.6 度量(项目健康)

度量用于决策与预警,不是考核工具——用度量考核会催生"为指标而工作"(古德哈特定律)。

状态报告模板(周报,半页):

本期完成: (3 条,绑定工件)下期承诺: (3 条)风险变化: (新增/升级/关闭,各 1 行)需要决策: (最多 2 项,附选项与建议)健康灯: 进度__ 质量__ 风险__ (红黄绿 + 一句理由)

8.7 传统 vs 敏捷的项目管理对照

OOS 实践:双周迭代 + 季度发布路线图(方向)+ 双周演示 + 风险登记册月度检视。

挣值管理(EVM)速览(预测型项目用)

• PV(计划值)/ EV(挣值)/ AC(实际成本);
• SV = EV − PV(进度偏差),CV = EV − AC(成本偏差);
• EAC(完工估算)修正预测;
• 陷阱:EV 的"完成百分比"若靠感觉填报,指标全是噪声——EVM 有效的前提是可验证的完成判据(与 DoD 同源)。

8.8 项目管理的反模式

8.9 本章 FAQ

Q1:估算永远不准,还要估吗? 要。估算的价值不在"准",在于:暴露风险(P 值很大 = 风险很大)、对齐范围(范围不清才估不准)、积累校准数据。持续不准说明方法或范围有问题,恰好是管理信号。

Q2:项目经理该懂技术吗? 要懂到"能判断技术风险的真实性和量级"(知道"联调 3 周"是合理还是乐观),不必写代码。不懂技术的 PM 在风险评审中会被"技术乐观"系统性误导。

Q3:迭代内能不能加需求? 默认不能(范围冻结);例外:等价替换(用新故事换出等量旧故事,PO 拍板)或缺陷修复。频繁"不能"说明容量承诺有问题(8.3 速度纪律)。

Q4:项目已经延期 30%,怎么办? 按序:① 重算关键路径,找到真实瓶颈;② 范围协商(砍 What,不是压 How);③ 资源/顺序重排(高风险前置);④ 坏消息上报 + 新承诺(基于重算,不基于面子)。"加班赶工"通常只适用于关键路径上的并行化空间,且短期为限。

Q5:PO 不接受"砍范围换时间"的取舍,怎么办? 回到业务目标层:把"目标 vs 选项"摆出来——“你要 X,选 A/B/C,各自代价如下”,让 PO 做取舍决策而不是"是/否"决策(PO 的授权范围是优先级,不是物理定律)。若 PO 仍坚持"全都要、时间不动",书面记录"管理层接受延期风险",风险入登记册并指定 Owner——责任明确化,比争论有效。

附录 A:估算偏差八大常见原因(诊断表)

用法:每个项目/迭代结束后,对照本表做"估算 vs 实际"复盘,记录主因;积累三次以上,你的团队会形成自己的"偏差画像"(例如"我们总在外部依赖上超 30%"),下次估算直接校正。

附录 B:沟通机制节奏表(11 人团队示例)

纪律:每会必有"产出时限"(纪要/决策/行动项 24 小时内发出);没有产出的会,砍掉。会议数量是成本,不是投入——沟通机制的目标是减少会议。

附录 C:估算走查完整示例(OOS v1.3"部分退款")

1. 拆解
   :拆为 5 个故事(需求分析 0.5 人日/状态机改造 2/接口+编码 3/测试 2/文档+发布 1);
2. 独立估算
   :3 名开发分别估 8 / 9.5 / 12 人日;
3. 分歧讨论
   :12 人日方提出"ERP 退款接口需联调"(其他两人漏掉的外部依赖)→ 确认联调 +2 人日必入;
4. 三点法
   :O=9,M=12,P=16(含联调 2 人日与 10% 波动)→ 期望 12;
5. 承诺
   :13.5 人日(期望 +12.5% 缓冲,缓冲标注在承诺层,估算层保持诚实);
6. 实际
   :12.5 人日(联调顺利,UI 返工 0.5 人日);
7. 校准
   :偏差 -8%;记录"联调风险出现但受控";更新估算表"外部依赖"权重。

要点:估算的价值在第 3 步暴露——一个隐藏的外部依赖在变成进度风险之前浮出水面。估算不是预言术,是风险扫描仪。

8.10 小结

• 软件项目管理核心:尽早暴露不确定性、反馈代替预测、管理范围与期望;
• 估算:方法多样,纪律统一(范围绑定、三点、留缓冲、校准、自检五问);
• 进度:盯关键路径,缓冲集中管理,里程碑可验证;速度是容量工具非 KPI;
• 风险:识别-评估-应对-监控,每条有 Owner + 触发指标;人/需求/外部接口是重灾区;
• 团队 ≤9、康威定律、机制化沟通、知识管理对抗单点依赖;
• 度量用于决策不用于考核;状态报告半页模板;
• EVM 依赖可验证完成判据;反模式表(8.8)用于自查。

思考题

1. 为什么"往延迟的项目里加人"常常更慢?用沟通成本公式解释。
2. 用 CPM 给"需求→设计→下单模块→支付联调→系统测试→发布"画活动网络,指出关键路径。
3. OOS 风险 R1(联调延迟)触发后,备用渠道预案应提前准备到什么程度才算"缓解到位"?
4. 为什么"用缺陷数考核开发团队"会产生反效果?给出两个具体行为扭曲例子。
5. 用 8.2 自检五问审查你最近一次估算,列出缺陷并给出修正。
6. 为你的项目做一次"事前验尸":假设发布失败,写出 5 个最可能的死因,并为前 2 个设计触发指标。
7. 速度连续三个迭代下降,列出 4 个可能的真实原因与各自的排查方法。
8. 设计你团队的周报状态报告,按 8.6 模板填充一期真实内容。