人力配置效率审查
沟通成本测算。 统计项目中实际的沟通时间：会议时间、代码审查时间、问题讨论时间、文档同步时间。计算这些时间占总工时的比例。
健康比例：5人以下团队，沟通时间不应超过15%；10人团队，不应超过25%；20人团队，不应超过40%。超过这些比例说明团队规模可能过大，或者沟通机制有问题。
新人净贡献时间。 对每个中途加入的团队成员，记录从入职到开始产生净贡献的时间。净贡献指：他的产出超过了培训他所消耗的其他成员时间。
如果这个时间超过项目剩余时间的50%，说明加人决策是错误的。如果普遍超过3个月，说明项目的知识传递成本过高，需要改进文档和培训流程。
任务并行化程度。 分析项目中有多少工作是真正可以并行的。计算方法：实际并行工时 ÷ 理论最短串行时间。
比值越高，说明项目的可并行性越好，增加人手的效果越明显。如果比值低于0.3，说明项目本质上是串行的，强行加人不会有效果。
架构决策质量评估
概念一致性得分。 让3-5个团队成员独立回答："这个系统的核心设计理念是什么？"如果答案高度一致，说明概念完整性好；如果差异很大，说明缺乏统一的架构愿景。
具体评分：完全一致（10分），大致一致（7分），部分冲突（4分），完全不同（1分）。低于7分的项目通常会在后期遇到严重的集成问题。
架构师决策有效性。 统计项目中重大技术决策的数量和决策者分布。如果重大决策（影响系统整体架构的决策）来自多个不同的人，说明架构控制不够集中。
理想状态：80%的架构决策应该来自同一个人或同一个3人小组。如果决策分散到5个以上的人，架构一致性很难保证。
设计变更频率。 记录核心接口、数据模型、系统架构的变更次数和变更原因。区分两类变更：需求驱动的变更和设计缺陷驱动的变更。
健康项目：需求驱动变更占70%以上，设计缺陷驱动变更不超过30%。如果设计缺陷变更过多，说明前期架构工作不充分。
质量控制体系检查
缺陷发现阶段分布。 统计缺陷是在哪个阶段被发现的：编码阶段、单元测试、集成测试、系统测试、用户测试、生产环境。
理想分布：编码阶段50%，单元测试30%，集成测试15%，系统测试5%，用户测试和生产环境0%。越晚发现的缺陷，修复成本越高。
代码审查覆盖率。 计算有多少代码经过了正式审查，审查质量如何。不是简单的行数比例，而是关键模块的覆盖情况。
核心算法、公共接口、安全相关代码必须100%审查。一般业务逻辑至少80%审查。如果核心代码的审查覆盖率低于95%，风险很高。
测试金字塔结构。 统计不同层次测试的数量：单元测试、集成测试、端到端测试。理想比例应该是倒金字塔：单元测试70%，集成测试20%，端到端测试10%。
如果端到端测试比例过高，说明依赖手动测试太多，自动化程度不够。如果单元测试比例过低，说明代码质量控制前移不够。
进度估算准确性分析
估算偏差模式。 对比初始估算和实际用时，分析偏差的规律。是普遍性的低估，还是特定类型任务的估算问题？
常见模式：新技术任务低估50%以上，集成工作低估200%以上，测试工作低估100%以上。识别自己团队的偏差模式，在后续项目中针对性调整。
关键路径变化轨迹。 项目初期的关键路径和实际关键路径是否一致？如果差异很大，说明前期分析不够充分，或者缺乏风险预案。
缓冲时间利用率。 分析预留的缓冲时间是否被有效利用，还是被帕金森定律消耗掉了。如果缓冲时间利用率过高（90%以上），说明预留不足；如果过低（30%以下），说明预留过度。
团队协作效能度量
决策速度指标。 统计重要决策从提出到确定的平均时间。技术决策应该在1-2天内确定，产品决策应该在1周内确定。决策拖延往往导致更大的延期。
知识共享程度。 测试关键知识的分布：如果某个人离开，有多少工作会受到严重影响？理想状态：任何一个人离开，项目仍能正常进行，只是效率有所下降。
冲突解决机制。 记录项目中技术分歧和意见冲突的数量、解决时间、解决方式。健康的项目应该有分歧（说明大家在思考），但能快速解决分歧。
复盘行动设计
每个指标不是为了打分，而是为了识别具体的改进点：
- 如果沟通成本过高，下次项目考虑拆分团队或改进工具
- 如果概念一致性差，加强架构师的权威性和沟通频率
- 如果缺陷分布不健康，改进代码审查和测试策略
- 如果估算偏差有规律，建立针对性的估算方法
复盘的目标不是证明这次项目成功或失败，而是为下次项目积累可操作的经验。布鲁克斯最大的价值就在于：他不仅告诉我们软件项目为什么困难，更重要的是告诉我们如何从困难中学习。