业务流程图交付前的质量评审，需要判断这张图能否作为需求沟通和后续设计的可靠依据。评估可从六个维度展开：范围与边界完整性、节点与角色完整性、逻辑一致性、数据与规则可执行性、可读性与标注规范、可追溯性与变更受控。每个维度都要有可核验的证据项和明确的通过标准，评审时按“证据是否齐备—问题是否阻断—结果是否可复算”三步判定，避免用单一维度代替整体质量结论。
要点总览（TL;DR）
- 业务流程图交付前评审可从六个维度展开：范围与边界完整性、节点与角色完整性、逻辑一致性、数据与规则可执行性、可读性与标注规范、可追溯性与变更受控。
- 每个维度都要有可核验的证据项和统一口径，百分比指标只反映该项检查的覆盖情况，整体结论由阻断项判定和缺陷清单共同形成。
- 评审按“证据是否齐备—问题是否阻断—结果是否可复算”三步执行，无出口节点、缺少起点终点、关键判断无条件说明等属于阻断项，修复后需重新评审。
- 维度指标不能单独代表整体质量，流程图评审通过只说明表达完整、逻辑自洽，业务效果需另行通过运行数据验证。
- 评审记录、整改项与复核结果应与流程图版本一并归档，便于后续变更时追溯。
交付前评审要回答的质量问题
流程图在需求文档中承担的是“业务如何流转”的表达任务。交付前评审要回答的核心问题是：读者能否仅凭这张图和配套说明，准确理解流程的起点、终点、参与角色、判断分支和异常处理，并据此开展后续设计、开发和验收。评审结论应当能够指向具体位置和具体缺陷，而不是笼统地给出“画得清楚”或“还需要完善”。
评审对象包括五类内容：流程范围，即流程从哪个事件触发、在哪个结果结束；节点，即每个活动、判断、等待和子流程；角色，即每个节点由谁执行、向谁交接；规则，即分支条件、时限要求和例外处理；数据，即节点输入输出的表单、单据或关键字段。评审时逐项核对这五类内容是否在图中和配套说明中有一致表达。
以下内容不纳入本评审：系统架构设计是否合理、界面如何绘制、需求内容本身是否符合业务实际。需求内容的业务正确性属于需求分析与澄清环节，流程图质量评审只判断“表达是否完整、一致、可执行”，两者结论应分开记录，避免把业务分歧误记为绘图缺陷。
六个评估维度与指标口径
六个维度分别回答不同问题，指标口径需要统一到可计算的程度。下表给出维度、指标定义、计算口径和统计单位。统计时间窗建议与评审批次一致，例如按“本次交付版本”统计，不以历史累计数据替代当前版本状态。
| 维度 | 指标定义 | 计算口径 | 单位与时间窗 |
|---|---|---|---|
| 范围与边界完整性 | 流程起点、终点、触发条件和结束状态是否明确 | 已明确项数 ÷ 应明确项数（起点、终点、触发条件、结束状态共4项） | 百分比，按本次交付版本统计 |
| 节点与角色完整性 | 每个节点是否标注执行角色，交接是否有明确对象 | 已标注执行角色的节点数 ÷ 流程节点总数；角色表中已定义角色数 ÷ 图中出现的角色数 | 百分比，按单张流程图统计 |
| 逻辑一致性 | 分支是否有条件、路径是否可达、是否存在无出口节点 | 通过核验的分支数 ÷ 分支总数；无出口节点数、孤立节点数单独计数 | 百分比与个数，按单张流程图统计 |
| 数据与规则可执行性 | 判断条件、输入输出数据、异常路径是否可据以执行 | 已写明判断条件和数据对象的节点数 ÷ 需要条件的节点数 | 百分比，按单张流程图统计 |
| 可读性与标注规范 | 命名、图例、编号、连线方向是否符合团队约定 | 符合命名与图例规范的节点数 ÷ 节点总数；缺图例、重名、连线交叉等按缺陷计数 | 百分比与缺陷数，按单张流程图统计 |
| 可追溯性与变更受控 | 流程图版本、关联需求条目、变更记录是否可查 | 已关联需求编号的节点或流程数 ÷ 应关联总数；有版本号和变更说明的流程图数 ÷ 交付流程图总数 | 百分比，按交付批次统计 |
口径使用时有两条约束。第一，分子分母必须来自同一版本、同一范围的流程图，跨版本合并计算会掩盖当前缺陷。第二，百分比指标只反映该项检查的覆盖情况，不能直接换算为整体质量分；整体结论由阻断项判定和缺陷清单共同形成。
证据项与数据来源
每个维度都需要对应证据支撑。证据不足时，该项按“未通过核验”记录，并在评审意见中注明缺失材料，不以口头说明替代书面证据。
| 维度 | 证据项 | 定性通过标准 |
|---|---|---|
| 范围与边界完整性 | 流程图文件、流程说明、上下游接口说明 | 起点和终点各只有一个明确入口与出口；触发条件和结束状态有文字说明；与上下游流程的接口有标注 |
| 节点与角色完整性 | 节点清单、角色表、组织或岗位说明 | 每个节点有执行角色；角色表覆盖图中全部角色；跨部门交接有接收方 |
| 逻辑一致性 | 流程图文件、分支条件说明 | 每个判断节点有至少两个带条件的出口；所有路径可到达终点；无孤立节点和无出口节点 |
| 数据与规则可执行性 | 表单或字段清单、规则说明、异常处理说明 | 判断条件可判定真假；节点输入输出有数据对象；异常路径有处理方式或明确标注待定 |
| 可读性与标注规范 | 团队绘图规范、图例、命名约定 | 节点命名使用动宾结构且无重名；图例完整；编号连续；连线方向与阅读顺序一致 |
| 可追溯性与变更受控 | 版本记录、需求条目关联表、评审记录 | 流程图有版本号和修订说明；关键节点可关联到需求条目；变更经过评审并留有记录 |
证据缺失的处理方式分两种：属于交付必备材料的，记为阻断项，例如缺少角色表导致无法核验节点执行者；属于补充说明性质的，记为一般缺陷并列入整改清单，例如图例不完整但节点命名可辨认。两种处理都应在评审记录中写明缺失内容和补齐责任人。
评审计算与判定步骤
评审按以下步骤执行，保证不同评审人对同一张图能得出相近结论。
- 确定范围与抽样方式。单张流程图或节点数较少的流程做全量核验；同一批次交付多张流程图时，可按流程数量抽取，但阻断项检查应覆盖全部交付流程图，覆盖率指标按全量计算。
- 逐维度核验并记录证据。按六个维度逐项填写核验结果，每个不通过项记录节点编号、问题描述和证据出处，便于整改时定位。
- 计算维度指标。按第二节口径计算百分比和缺陷计数，分母为零时标注“不适用”，不计为满分，也不计入平均分。
- 判定阻断项。出现以下任一情况即整体不通过：流程无明确起点或终点；存在无出口节点或不可达路径；关键判断节点缺少条件说明；交付版本无版本号或变更记录。阻断项修复后需重新评审。
- 判定一般缺陷。非阻断缺陷按数量和严重程度形成整改清单，设定整改期限和复核人。通过线由团队在评审前约定，例如一般缺陷全部登记且有整改计划即可放行，不在评审过程中临时调整。
- 形成结论并留痕。结论写明通过、有条件通过或不通过，附维度指标、缺陷清单和整改责任人。评审记录与流程图版本一并归档，后续变更时对照复核。
数据不可比的情况需要单独说明：不同复杂度流程的节点数差异较大，节点完整性百分比不宜直接横向排名；跨团队比较时应先统一绘图规范和统计口径，否则只做本团队纵向对比。
一个流程图的评审示例
以下为演示情景，数据仅用于说明计算方法，不代表真实项目。某采购申请流程共20个节点，图中出现5个角色，交付版本为V1.2。
- 范围与边界：起点、终点、触发条件、结束状态4项中明确3项，结束状态未写明，指标为75%。
- 节点与角色：20个节点中18个标注执行角色，指标为90%；图中5个角色在角色表中定义4个，指标为80%。
- 逻辑一致性：共8个分支，7个带条件说明，指标为87.5%；发现1个节点无出口，属于阻断项。
- 数据与规则：需要判断条件的节点6个，写明条件的5个，指标为83.3%；异常路径有1处标注“待定”。
- 可读性：20个节点中17个符合命名规范，指标为85%；存在2处重名节点。
- 可追溯性：流程图有版本号V1.2和修订说明；20个节点中12个关联需求编号，指标为60%。
判定过程：该图存在无出口节点，触发阻断项，整体结论为不通过。整改项包括补齐结束状态说明、为无出口节点补充后续路径、定义缺失角色、补充异常路径处理方式、修正重名节点、为剩余8个节点补充需求关联。整改完成后重新核验阻断项，并复核一般缺陷是否关闭。该示例说明，即使多数维度百分比在80%以上，单个阻断项仍足以使整体结论为不通过。
评审结论形成后，缺陷清单需要在需求文档和任务系统中流转到责任人，整改完成后由评审人对照原版本复核。ONES 的文档与工作项管理可用于承载评审记录、整改任务和复核状态，使流程图版本与整改结论保持对应；具体使用方式按团队现有流程配置。
结果解读与常见误用
维度指标反映的是流程图在特定检查项上的覆盖情况，不能单独代表整体质量。一张图可读性得分很高，仍可能因缺少异常路径而在开发阶段暴露问题；可追溯性得分低，也不必然说明流程逻辑有误。解读时应把指标、阻断项和缺陷清单放在一起看，结论指向具体问题和整改动作。
流程图质量与业务效果是两件事。流程图评审通过，只说明表达完整、逻辑自洽、可供后续环节使用，不能推出流程上线后效率提升或风险下降。业务效果需要通过运行数据和专项评估验证，两者结论不应混用。
常见误用有三种：把平均分当作放行依据，忽略阻断项；用历史版本的指标评价当前交付，掩盖新引入的缺陷；把评审结论直接作为需求内容正确的证明。评审后的管理动作应明确：通过则归档并进入下一环节；有条件通过则限期整改并复核；不通过则退回修改，阻断项关闭前不进入交付。评审记录、整改项和复核结果应与流程图版本一并保存，便于后续变更时追溯。
常见问题
流程图的节点数很多，评审时是否必须全量核验？
单张流程图或节点数较少的流程建议全量核验。同一批次交付多张流程图时，一般缺陷可以按流程数量抽样检查，但阻断项检查应覆盖全部交付流程图，覆盖率指标按全量计算。抽样时要在评审记录中写明抽样方法和覆盖范围，避免用抽样结果推断未检查部分的质量。
团队对“一般缺陷放行线”意见不一致，评审前应如何约定？
通过线应在评审开始前由团队共同约定，例如一般缺陷全部登记且有明确整改计划即可放行，或设定缺陷数量上限。约定后写入评审规则，评审过程中不临时调整。若评审中发现规则本身不合理，应记录为规则修订项，在下一批次评审前统一修改，避免同一批次内标准前后不一。
流程图与需求文档中的描述不一致时，算流程图缺陷还是需求问题？
需要先区分不一致的性质。如果流程图遗漏了需求文档中已明确的角色、分支或数据对象，属于流程图表达不完整，记为流程图缺陷；如果两边描述本身存在业务理解分歧，则属于需求内容问题，应转入需求分析与澄清环节处理。两类问题分开记录，避免把业务分歧误记为绘图缺陷。
分母为零的指标如何处理，是否影响整体结论？
分母为零时标注“不适用”，不计为满分，也不计入平均分。例如某流程图没有判断节点，则“判断条件写明比例”不适用。整体结论仍由阻断项判定和缺陷清单形成，不适用项在评审记录中单独列出，说明原因，便于后续复核时理解口径。
评审通过后流程图发生变更，是否需要重新评审？
需要根据变更范围决定。涉及流程起点终点、判断分支、角色交接或异常路径的变更，应重新核验阻断项并复核相关维度；仅涉及命名、图例或文字说明的修改，可由评审人对照原记录做局部复核。变更后的版本号、修订说明和复核结论应与原评审记录一并保存，保持版本与结论对应。
