评估项目是否成功，需要把交付结果、业务结果、过程健康度和相关方认可分开度量，再按事先约定的权重和判定规则合成结论。核心做法是：立项时确定维度、指标、口径、时间窗和判定阈值；结项时先核对交付类指标，再在业务效果观察期内核对业务类指标；当交付成功而业务成功未达成时，按“交付验收通过、业务效果待观察或未达标”分别记录，不用交付指标替代业务结论。
要点总览（TL;DR）
- 评估项目是否成功，先把问题拆成交付、业务、过程健康度和相关方认可四类，分别度量、分别记录，再按事先约定的权重和判定规则合成结论。
- 每个指标在立项时配一张口径卡，写明分子分母、统计时间窗、数据来源、取数责任人和缺失值处理规则，评估时按卡取数，不临时改公式。
- 综合判定分四步：单项指标按阈值判达标、维度内加权合成、四维度合成总分并保留各维度结论、取数与复核分离后发布。
- 交付成功与业务成功判定时点不同，观察期未结束写“交付验收通过、业务效果待观察”；业务未达标时区分项目执行原因与外部假设失效，分别记录并设定复查日期。
- 指标反映结果状态，不直接证明因果，不同项目类型和规模不宜直接横比，阈值调整需说明理由并留痕。
评估目标：先明确要回答哪几个成功问题
“项目是否成功”是一个复合问题，直接投票式打分容易把不同性质的结论混在一起。评估开始前，先把问题拆成四类：交付是否完成、业务目标是否达成、执行过程是否健康、相关方是否认可。四类问题回答的是不同的事，结论也可能互相冲突，因此需要分别度量、分别记录。
评估时点同样要事先写清楚。交付类问题在结项验收时即可回答；业务类问题通常需要一段观察期，等目标指标稳定后再回答；过程健康度贯穿项目全程，在复盘时汇总；相关方认可在验收和复盘两个节点都可能采集。把“结项时结论”和“观察期结束后结论”分开记录，可以避免在业务效果尚未显现时就下最终判断。
评估结论的用途会影响口径的严格程度。用于验收付款的评估，指标口径和证据要求应最严格，判定规则需在合同中或立项文件中固化；用于内部复盘的评估，可以纳入更多过程指标和定性反馈；用于资源再分配的评估，则要保证不同项目之间的口径可比。用途不同，指标取舍和证据形式可以不同，但同一用途下的口径必须统一。
据此可以形成一份评估目标清单，至少包含四项内容：评估对象（哪个项目、哪个阶段）、评估时点（结项、观察期结束、复盘）、四类成功问题各自对应的具体问法、以及每类结论的用途。清单在立项阶段确认，后续调整需留痕。
指标与范围：四个维度各用什么指标
四个维度各自选择少量能说明问题的指标，避免指标堆砌。每个指标注明单位、适用项目类型和是否必选，必选指标构成评估的底线，可选指标按项目特点增补。
| 维度 | 指标示例 | 单位 | 适用项目类型 | 是否必选 |
|---|---|---|---|---|
| 交付 | 范围完成率 | 百分比 | 有明确交付清单的项目 | 必选 |
| 交付 | 里程碑达成率 | 百分比 | 分阶段交付的项目 | 必选 |
| 交付 | 验收缺陷密度 | 个/千行或个/功能点 | 软件与产品类项目 | 按类型选 |
| 业务 | 目标业务指标达成率 | 百分比 | 有量化业务目标的项目 | 必选 |
| 业务 | 采用率 | 百分比 | 上线类、推广类项目 | 按类型选 |
| 业务 | 收益回收周期 | 月 | 有可核算投入产出的项目 | 按类型选 |
| 过程 | 进度偏差 | 天或百分比 | 全部项目 | 必选 |
| 过程 | 成本偏差 | 金额或百分比 | 有预算的项目 | 必选 |
| 过程 | 变更次数、返工率 | 次、百分比 | 需求变动较多的项目 | 按类型选 |
| 相关方 | 关键干系人验收意见 | 通过/有条件通过/不通过 | 全部项目 | 必选 |
| 相关方 | 满意度或使用反馈 | 评分或反馈条目 | 有明确使用方的项目 | 按类型选 |
范围之外也要写明。与本次评估无关的指标，例如与项目目标无对应关系的部门级考核指标、无法取得可靠数据的指标、以及需要长期跟踪才能得出结论的指标，应在评估方案中列明不纳入及原因。这样既控制评估成本，也防止事后临时加指标改变结论。
数据口径与证据：每个指标怎么取数、谁来确认
指标名称相同、口径不同，结论就会不同。每个指标需要一张口径卡，写明分子、分母、统计时间窗、单位、数据来源、取数责任人和缺失值处理规则。口径卡在立项时确认，评估时按卡取数，不临时改公式。
| 指标 | 公式（分子/分母） | 时间窗 | 数据来源 | 责任人 | 缺失值处理 |
|---|---|---|---|---|---|
| 范围完成率 | 已验收通过的需求数 / 基线范围内需求总数 | 立项至结项 | 需求清单与验收记录 | 项目经理 | 需求被正式移出范围的，从分母剔除并留变更记录 |
| 里程碑达成率 | 按期达成的里程碑数 / 计划里程碑总数 | 立项至结项 | 里程碑计划与完成记录 | 项目经理 | 里程碑被正式调整的，按调整后计划计算并注明 |
| 目标业务指标达成率 | 观察期实际值 / 立项时目标值 | 上线后约定观察期 | 业务系统数据 | 业务负责人 | 观察期数据不足的，标注“待观察”，不填零 |
| 进度偏差 | 实际完成日期 − 计划完成日期 | 结项时 | 项目计划与状态记录 | 项目经理 | 计划变更已批准的，以最新批准计划为基准 |
| 关键干系人验收意见 | 定性结论 | 验收时 | 验收记录或评审纪要 | 验收组织方 | 意见缺失的，记为“未取得意见”，不默认通过 |
定性指标同样需要证据形式和通过标准。关键干系人验收意见以签字验收记录或评审纪要为准，通过标准可设为“无重大遗留问题且关键干系人书面确认”；满意度以回收的有效反馈为准，需注明样本量和回收率。没有证据的定性结论不进入合成计算。
三类特殊情况要提前定规则：分母为零时该指标记为“不适用”，不参与加权；数据缺失时区分“未采集”和“采集后不可得”，前者补采，后者在结论中标注并说明对判定的影响；口径需要变更时，新旧口径分别计算并同时呈现，不用新口径覆盖已发布的旧结论。
取数依赖日常记录。工作项状态、里程碑完成情况、验收记录如果散落在邮件和聊天记录里，口径卡就难以执行。使用 ONES 这类项目协作平台时，需求、任务、里程碑和验收记录沉淀在同一套工作项与文档中，评估时按状态和字段导出即可对应口径卡，减少事后补录和口径争议。
计算与评估步骤：从单项指标到综合判定
评估按固定顺序执行，先单项、再维度、最后综合，每一步都可复算。
第一步，单项达标判定。每个指标在立项时设定阈值，阈值来源写明依据，例如历史基线、合同约定、业务方承诺或行业参考值。判定结果分为达标、未达标、不适用三档。阈值不设通用默认值，没有依据的阈值需标注为“暂定”，并在复盘中复核。
第二步，维度内合成。同一维度内的指标按权重加权，权重在立项时确定，合计为100%。存在底线要求的维度可设一票否决项，例如关键干系人验收不通过时，交付维度直接判为未达成，不再看加权分。否决项应尽量少，且事先写明。
第三步，综合分级。四个维度的得分按约定权重合成总分，同时保留各维度结论。综合结论分为四级：成功（各维度均达标）、基本成功（交付与相关方达标，业务待观察或过程有偏差）、部分达成（交付达标但业务未达标，或过程严重偏差）、未达成（交付或验收未通过）。分级规则表与权重表一并固化在评估方案中。
第四步，复核。取数人和复核人分离，复核人核对公式、分母、时间窗和证据是否与口径卡一致，确认无误后结论才对外发布。复核记录随评估报告归档。
例子：一个项目的多维评估演算
以下为演示情景，数据仅用于说明计算过程。某内部系统改造项目，立项时基线范围需求40项，计划里程碑5个，预算80万元，目标业务指标为上线后三个月内月活跃使用人数达到500人。
| 指标 | 实际取值 | 计算 | 阈值 | 判定 |
|---|---|---|---|---|
| 范围完成率 | 38项验收通过，2项经批准移出范围 | 38 / 38 | ≥95% | 达标 |
| 里程碑达成率 | 5个中4个按期 | 4 / 5 | ≥80% | 达标 |
| 进度偏差 | 实际比计划晚12天 | 12天 | ≤10天 | 未达标 |
| 成本偏差 | 实际支出84万元 | +4万元 | ≤5% | 达标 |
| 目标业务指标达成率 | 观察期第2个月活跃320人，第3个月数据未出 | 320 / 500 | ≥100% | 待观察 |
| 关键干系人验收意见 | 书面确认通过，附2项优化建议 | 定性 | 无重大遗留问题 | 达标 |
按维度合成：交付维度两项均达标，判为达成；过程维度进度偏差未达标、成本偏差达标，加权后判为部分达成；相关方维度达标；业务维度因观察期未结束，记为“待观察”，不参与总分加权，但在结论中单列。
综合结论记录为“基本成功”：交付验收通过，过程存在进度偏差，业务效果待观察。三个月观察期结束后补录数据，若活跃人数达到500人，结论更新为“成功”；若未达到，则按下一节的规则处理。示例中第3个月数据缺失属于“未采集”，按口径卡补采，不按零值计算。
交付成功与业务成功不一致时如何判定
交付成功与业务成功的判定时点天然不同：交付在结项时判定，业务效果需要观察期。两者不一致是常见情形，处理原则是分别记录、不互相替代。
观察期未结束时，结论写“交付验收通过，业务效果待观察”，并注明观察期截止日期和责任人。这一结论不视为最终成功，也不因交付通过而提前宣布业务达成。
观察期结束、业务未达标时，需要区分原因。属于项目执行原因的，例如功能未按预期使用、推广不到位、交付质量导致采用率低，结论记为“交付成功、业务未达标”，由项目团队承担改进责任；属于外部假设失效的，例如立项时假设的市场条件、政策环境或用户需求发生变化，结论中应写明假设变化的事实和证据，责任归属按立项文件约定处理。两类原因可能同时存在，分别列出，不合并成一句“效果不佳”。
结论记录采用固定模板：交付结论、业务结论、判定时点、原因分类、后续跟踪事项和责任人。后续跟踪事项需设定复查日期，到期复核后更新结论，避免“待观察”长期悬置。
解读与限制：指标能说明什么、不能说明什么
指标反映的是结果状态，不能直接证明因果。业务指标达成可能来自项目交付，也可能来自市场变化、其他团队动作或统计口径调整。把达成率直接归因于项目，需要额外的对照证据，例如上线前后对比、使用行为数据或用户访谈。
不同项目类型和规模下的指标不宜直接横向比较。一个两周的小型工具项目和一个跨年度平台项目的进度偏差、缺陷密度含义不同，直接排名会误导资源决策。横向比较的前提是口径卡一致、项目类型相近，否则只做纵向对比和趋势观察。
阈值设定带有主观性。同一指标在不同业务阶段可以设不同阈值，调整阈值需说明理由并留痕，不能因为结果不理想而事后放宽。评估结论的使用也应设限：单指标不构成对个人或团队的完整绩效结论；综合分级用于项目层面的判断，用于考核时需结合职责分工另行设计。
结论发布前经过复核，发布后保留原始数据和计算过程，便于后续复查和口径追溯。评估方法本身也应定期回顾，根据实际使用情况修正指标和权重。
常见问题
业务效果观察期应该设多长，观察期内结论怎么写？
观察期长度取决于业务指标稳定所需的时间，常见做法是在立项时与业务方约定，例如上线后三个月，并在评估方案中写明截止日期。观察期内不把业务维度计入总分加权，结论写“交付验收通过，业务效果待观察”，同时注明观察期截止日期和跟踪责任人。观察期结束后补录数据，再更新结论，避免“待观察”长期悬置。
某个指标分母为零或数据缺失时，综合结论还能算吗？
可以算，但要按事先定的规则处理。分母为零时该指标记为“不适用”，不参与加权，其余指标按原权重归一化后合成。数据缺失要区分“未采集”和“采集后不可得”：前者补采后再评估，后者在结论中标注缺失项及其对判定的影响，不用零值代替。若缺失指标属于一票否决项，则暂缓发布综合结论，待证据补齐。
交付验收通过但业务指标未达标，责任应该算在项目团队吗？
需要先区分原因再定责任。属于项目执行原因的，例如功能未按预期使用、推广不到位、交付质量导致采用率低，由项目团队承担改进责任；属于外部假设失效的，例如立项时假设的市场条件、政策环境或用户需求发生变化，结论中写明假设变化的事实和证据，责任归属按立项文件约定处理。两类原因可能同时存在，分别列出，不合并成一句“效果不佳”。
不同项目之间的成功度可以直接排名比较吗？
直接排名容易误导。横向比较的前提是口径卡一致、项目类型和规模相近，否则进度偏差、缺陷密度等指标在不同项目中的含义不同。更稳妥的做法是同一项目做纵向对比和趋势观察；确需横向比较时，先统一公式、时间窗和阈值来源，并在结论中注明可比性限制。
评估结论能否直接用于个人绩效考核？
综合分级用于项目层面的判断，单指标不构成对个人或团队的完整绩效结论。用于考核时需结合职责分工另行设计，明确哪些指标由谁负责、哪些属于外部条件影响。评估结论发布前经过复核，发布后保留原始数据和计算过程，便于复查和口径追溯。
