评估项目健康度，需要三类证据：范围与计划基线、执行过程数据，以及负责人自评和干系人反馈等主观与外部信号。指标要能复算，必须写清分子分母、统计时间窗和取数来源；结论则要结合红黄绿阈值与证据缺口共同解读，单看一个指标无法判断项目是否健康。ONES可用于汇总工作项状态、里程碑和风险记录，为这类评估提供数据基础。
要点总览（TL;DR）
- 评估项目健康度需要四类证据：计划基线（里程碑、交付物、WBS与承诺日期）、执行过程数据（任务状态、缺陷、变更、风险）、投入记录（工时或人力分配）、主观与外部证据（负责人自评、干系人反馈、依赖确认）。
- 每项指标要写清公式、分子分母、统计时间窗和数据截止时点，分母为零记为“不适用”，缺失数据显式标注，口径变更留记录且新旧数据不直接比较。
- 评估按固定节奏推进：确定周期与截止日、采集数据、交叉校验、按口径计算、与阈值比对、结合证据缺口形成红黄绿判断。
- 指标反映状态而非原因，解读时要考虑数据滞后、口径不一致和自评偏差；阈值结合项目类型与阶段设定，不套用统一达标线。
- 健康度评估回答“项目当前处于什么状态”，进度纠偏和跨团队效能指标属于另外的判定对象，数据可复用但结论不宜混在一起。
项目健康度评估要回答什么问题
健康度评估的目标，是把“这个项目现在怎么样”这类笼统印象，拆成一组可以逐项回答、逐项取证的问题。评估开始前先明确判定对象和用途，后续取数才有方向，也才能避免把健康度做成一份堆满数字却无法支撑决策的报告。
健康度评估通常覆盖六个维度，每个维度对应一组具体问题：
- 范围：交付物清单是否稳定？本期承诺的内容有没有未经评审就增加或删减？
- 进度：关键里程碑是否按承诺日期达成？剩余工作与剩余时间是否匹配？
- 质量：缺陷的数量、严重程度和关闭情况如何？验收标准是否满足？
- 风险：已识别风险的状态和应对措施是否落实？是否出现新的高影响风险？
- 资源：人力投入与计划分配是否一致？关键角色是否存在缺口或过载？
- 干系人：依赖方是否确认交付？关键干系人对项目状态的认知是否一致？
评估结论主要用于三件事：提前预警偏离、支持决策（如是否调整范围或补充资源）、为资源调配提供依据。需要区分的是，健康度评估回答“项目当前处于什么状态”，进度纠偏回答“偏离之后怎么补救”，跨团队效能指标回答“多个团队的整体产出效率如何”。三者数据可以复用，但判定对象和结论用途不同，不宜混在同一套指标里下结论。
评估启动时可以先产出一份目标清单，逐条写明：本周期要判断哪个维度、用什么问题表述、结论交给谁使用。这份清单是后续选择数据和设定阈值的依据。
健康度指标需要哪些数据与证据
数据与证据按来源分为四类：计划基线、执行过程、投入记录、主观与外部证据。基线回答“原本承诺什么”，过程数据回答“实际发生了什么”，投入数据回答“用了多少资源”，主观与外部证据补充系统数据看不到的判断和依赖关系。四类证据相互印证，缺一类就可能出现“数据好看但实际失控”或“感觉不妙但拿不出依据”的情况。
| 类别 | 数据项 | 来源系统或文档 | 责任人 |
|---|---|---|---|
| 计划基线 | 里程碑清单及承诺日期 | 项目计划、里程碑记录 | 项目经理 |
| 计划基线 | 交付物清单与验收标准 | 需求文档、范围说明书 | 项目经理、产品负责人 |
| 计划基线 | WBS与任务分解、计划工时 | 项目管理工具中的任务结构 | 项目经理 |
| 执行过程 | 任务状态、完成数量与完成时间 | 工作项管理系统 | 各任务负责人 |
| 执行过程 | 缺陷数量、严重级别、关闭状态 | 缺陷跟踪系统 | 测试负责人 |
| 执行过程 | 变更申请与审批记录 | 变更管理记录 | 项目经理 |
| 执行过程 | 风险登记册及应对措施状态 | 风险台账 | 项目经理、风险责任人 |
| 投入 | 实际工时或人力分配记录 | 工时填报、资源分配表 | 团队成员、资源经理 |
| 主观与外部 | 项目负责人自评与判断依据 | 周报、状态报告 | 项目经理 |
| 主观与外部 | 关键干系人反馈 | 评审纪要、沟通记录 | 项目经理 |
| 主观与外部 | 依赖方交付确认 | 接口确认单、联调记录 | 依赖方接口人 |
采集时要注意两点。第一，每项数据标注截止时点，避免把不同日期的数据拼在一起比较。第二，主观证据要留下判断依据，例如自评“进度正常”时附上已完成里程碑和剩余工作量，否则自评无法与其他证据交叉校验。
指标口径：分子分母、时间窗与缺失值处理
同名指标在不同项目里算法不同，是健康度报告最常见的失真来源。解决办法是为每个指标写一份口径定义，至少包含公式、分子、分母、单位、统计时间窗和数据截止时点。下表给出常用指标的定义示例，具体阈值由项目自行设定。
| 指标 | 公式 | 分母说明 | 时间窗 | 缺失值规则 |
|---|---|---|---|---|
| 任务完成率 | 已完成任务数 ÷ 统计范围内任务总数 × 100% | 统计范围内任务总数，不含已取消任务 | 截至评估日 | 状态为空的任务计入分母，单独标注“状态未更新”数量 |
| 里程碑达成率 | 按期达成里程碑数 ÷ 应达成里程碑数 × 100% | 截至评估日应达成的里程碑数 | 项目启动至评估日 | 无应达成里程碑时分母为零，记为“不适用”，不按0%处理 |
| 缺陷密度 | 缺陷数 ÷ 交付物规模（如功能点数或千行代码） | 交付物规模，需注明计量单位 | 本评估周期内新发现缺陷 | 规模数据缺失时该指标留空，不用缺陷总数替代 |
| 工时偏差率 | （实际工时 − 计划工时）÷ 计划工时 × 100% | 同期计划工时 | 本评估周期 | 工时未填报的任务标注为“投入未知”，不按零工时计算 |
| 高风险未关闭数 | 高影响且未关闭的风险条目数 | 不适用（计数指标） | 截至评估日 | 风险等级未评定的条目单列，不计入高风险数 |
口径变更要有记录。若中途调整了分母范围或统计时间窗，需在报告中注明变更日期和原因，新旧口径的数据不直接比较。分母为零时统一记为“不适用”，避免用0%或100%造成误读。缺失数据要显式标注，不能默认按最差值或最优值填充。
评估步骤：从取数到形成健康度结论
评估流程按固定节奏执行，才能保证不同周期的结论可比。建议按以下步骤推进，并为每步指定责任人。
- 确定评估周期与数据截止日（项目经理）：明确本次评估覆盖的时间段和统一截止时点，通知各数据责任人。
- 采集数据（各数据责任人）：按数据清单从对应系统导出或整理，标注导出时间和数据范围。
- 交叉校验（项目经理与测试、资源负责人）：比对系统数据与自评、干系人反馈是否一致，例如任务完成率与负责人自评的进度判断是否矛盾，里程碑日期与变更记录是否对应。
- 按口径计算指标（项目经理或指定的度量负责人）：逐项套用口径定义，记录分子、分母和计算结果，缺失项按规则标注。
- 与阈值比对（项目经理）：对照本项目设定的红黄绿阈值，形成各维度初判。
- 结合证据缺口形成结论（项目经理与项目负责人）：说明哪些维度证据充分、哪些存在缺口，给出整体健康度判断和需要关注的事项。
交叉校验是容易被跳过的一步，但它的作用很直接：系统里任务显示完成、负责人自评却说有返工，这类矛盾正是需要进一步核实的信号。评估记录中保留校验发现的问题，比只保留最终结论更有参考价值。
示例：一个项目的健康度评估过程
以下为演示情景，数字仅用于说明计算方法。某交付项目评估日为第8周周五，数据截止到当日18时。
基线数据：项目共设6个里程碑，截至评估日应达成3个；本期计划完成任务40项，计划工时320小时；交付物规模按功能点计为120点。
过程数据：已完成任务31项，其中2项状态为空；3个应达成里程碑中2个按期达成，1个延期5天；本期新发现缺陷18个，其中严重缺陷3个；实际填报工时350小时，另有4项任务未填报工时；风险登记册中有2项高影响风险未关闭；变更记录显示本期新增需求2项，均经审批。
指标计算：
- 任务完成率 = 31 ÷ 40 × 100% = 77.5%，另有2项状态未更新需核实；
- 里程碑达成率 = 2 ÷ 3 × 100% ≈ 66.7%；
- 缺陷密度 = 18 ÷ 120 = 0.15个/功能点；
- 工时偏差率 =（350 − 320）÷ 320 × 100% ≈ 9.4%，且4项任务投入未知，实际偏差可能更大；
- 高风险未关闭数 = 2。
证据缺口与判断：任务完成率接近计划，但里程碑有延期、工时超支且部分任务未填报，两项高影响风险未关闭，依赖方对其中一个接口的交付确认尚未回复。综合来看，进度维度可判为黄色，风险维度因高风险未关闭且应对措施状态未更新，判为红色；质量维度缺陷密度处于项目自设阈值内，判为绿色，但严重缺陷3个需跟踪关闭。若只看任务完成率77.5%，容易得出“基本正常”的结论，这正是需要多类证据共同解读的原因。
如何解读结果与规避误判
指标反映的是状态，不解释原因，也不构成结果保证。里程碑达成率低，可能是估算偏乐观、依赖延迟或范围增加，具体原因要靠变更记录、风险台账和干系人反馈去查。把指标当结论、把黄色当“没问题”，是健康度评估中最常见的误判。
解读时注意三类偏差：
- 数据滞后：任务状态更新不及时会让完成率虚高或虚低，评估前应核对最近更新时间和未更新条目数量。
- 口径不一致：不同团队对“完成”的定义不同（开发完成、测试通过、验收通过），跨项目比较前先统一口径。
- 自评偏差：负责人倾向于报喜或报忧，自评需附判断依据，并与系统数据交叉验证。
阈值设定要结合项目类型和阶段。研发早期项目缺陷密度天然偏高，交付末期则对缺陷关闭率更敏感；创新探索类项目对范围变更的容忍度高于合同交付类项目。因此不宜套用统一的达标线，阈值应由项目负责人在启动时提出、经干系人确认后使用，并在阶段切换时复核。
建议建立复核机制：每次评估后由项目经理之外的角色抽查至少两项指标的计算过程，核对分子分母与数据截止时点；对判为绿色但存在证据缺口的维度，要求补充证据后再确认结论。评估记录连同证据缺口一并归档，下一周期评估时对照检查缺口是否补齐。
常见问题
项目刚启动、还没有里程碑到期，健康度怎么评估？
启动阶段可以把评估重点放在基线的完整性和准备度上，而不是达成率。具体做法是：确认里程碑清单、交付物清单和验收标准是否已经形成并经过干系人确认；检查WBS是否覆盖本期承诺范围、计划工时是否已分配到责任人；核对风险登记册是否完成首轮识别。里程碑达成率在无应达成里程碑时按口径记为“不适用”，不按0%或100%处理。此时健康度结论更多依赖基线证据是否齐全，以及关键依赖方是否已确认接口和交付安排。
系统里的任务状态和负责人自评对不上，以哪个为准？
两者都不直接作为结论，先核实再判断。系统状态反映的是工作项记录，可能存在更新不及时；自评反映负责人的判断，可能缺少依据或带有倾向。处理方式是：找出状态为“已完成”但自评提到返工或未收尾的条目，逐项向负责人确认实际进展，并核对最近更新时间。核实后修正系统记录或在评估记录中注明差异。这类矛盾本身就是需要关注的信号，评估记录里保留校验发现的问题，比只保留最终结论更有参考价值。
不同项目的健康度结论可以直接横向比较吗？
直接比较之前要先统一口径。不同团队对“完成”的定义可能不同（开发完成、测试通过、验收通过），缺陷密度的分母计量单位也可能不一致，统计时间窗和数据截止时点不同更会让数字失去可比性。如果要做跨项目比较，先确认各项目使用同一套指标定义和阈值规则，或者只比较口径明确一致的指标。项目类型和阶段差异较大时，阈值本身就不应统一，横向比较更适合看趋势和证据缺口，而不是简单排名。
评估中发现证据缺口，健康度结论还能给出吗？
可以给出，但要同时说明缺口及其影响。做法是：对证据充分的维度按阈值正常判定；对存在缺口的维度，在结论中标注缺口内容（如工时未填报、依赖方未确认、风险应对状态未更新），并说明该缺口可能使判断偏乐观还是偏保守。判为绿色但存在证据缺口的维度，要求补充证据后再确认。评估记录连同缺口一并归档，下一周期对照检查是否补齐。这样结论仍然可用，读者也能知道哪些部分需要谨慎对待。
健康度阈值应该由谁设定，多久复核一次？
阈值由项目负责人在项目启动时提出，经关键干系人确认后使用，而不是套用组织统一的达标线。设定依据包括项目类型（合同交付类对范围变更更敏感，探索类容忍度更高）、所处阶段（研发早期缺陷密度天然偏高，交付末期更关注缺陷关闭率）和历史数据。复核时机建议放在阶段切换、范围发生重大变更或连续两个周期出现同一维度异常时。阈值调整要记录日期和原因，调整前后的评估结论不直接比较。
