研发项目Charter写完后，评审要回答的是：这份文本能否支撑立项评审做出判断。做法是把目标、范围、成功标准、启动授权四类要素拆成可判定的检查条目，为每条指定证据来源和判定口径，按“逐项取证—判定—汇总—记录待办”执行，最后给出通过、有条件通过或不通过，并标注证据不足项与复核时点。
要点总览（TL;DR）
- Charter质量评审的对象是单份文本及其附件，结论作为立项评审前的输入，不替代立项决策，也不做多项目准入排序。
- 把目标、范围、成功标准、启动授权四类要素拆成可判定条目，每条指定证据来源与判定口径，定性条目要求有表述、有责任人、有可核对对象。
- 判定分符合、部分符合、不符合、证据不足四档，证据不足标注待补而非直接判不合格；任一阻断项不符合即不通过。
- 结论分通过、有条件通过、不通过三档，条件项对应待办、责任人与复核时点，复核通过后再提交立项评审。
- 评审结论只反映文本质量，不保证执行结果，定性判定建议多人交叉核对，范围或授权变更后应重新评审关键条目。
评审要回答什么问题：Charter质量的判定目标
Charter质量评审的对象是单份Charter文本及其附件，任务边界是判断这份文本是否完整、可执行、可授权。评审不评价项目本身的价值高低，也不在多个项目之间做准入排序——那是立项决策和多项目组合管理的任务。评审结论的用途是作为立项评审前的输入材料，帮助决策者在开会前就知道哪些地方还缺证据、哪些条件需要补充。
具体来说，评审要回答四类问题：
- 目标是否清晰可衡量：业务目标与项目目标之间是否有明确的对应关系，目标能否用指标或可核验的结果描述。
- 范围是否界定：纳入了什么、排除了什么，关键交付物和边界条件是否写明。
- 成功标准是否可验证：验收口径、时间窗、责任方是否明确到可以核对。
- 启动授权是否明确：发起人、决策人、资源与预算授权、里程碑授权是否落到具体角色。
把这四类问题作为评审目标，可以避免评审会滑向对项目前景的争论。评审人只需回答“文本里有没有、写得够不够判定”，项目价值判断留给立项决策环节。
评审范围与检查项：四类要素拆成可判定条目
四类要素需要拆成可以逐项打勾或判定的条目，否则评审容易停留在“感觉写得还行”的层面。下表给出每类要素的检查条目、判定要点和常见缺失表现，组织可按项目类型增删条目，但建议在评审前固定下来。
| 要素类别 | 检查条目 | 判定要点 | 常见缺失表现 |
|---|---|---|---|
| 目标 | 业务目标与项目目标的对应关系 | 每个项目目标能追溯到一条业务目标，或说明其支撑关系 | 只写业务愿景，项目目标缺失或与业务目标脱节 |
| 目标 | 目标的可衡量性 | 目标有指标名称、口径或可核验的结果描述 | 使用“提升”“优化”等无法核对的表述 |
| 范围 | 纳入与排除内容 | 明确写出做什么、不做什么 | 只有纳入项，没有排除项，边界靠默认理解 |
| 范围 | 关键交付物 | 交付物可识别，能对应到后续验收 | 交付物写成“系统一套”等笼统表述 |
| 范围 | 边界条件 | 依赖的系统、团队、外部条件有交代 | 依赖关系未写，执行阶段才发现卡点 |
| 成功标准 | 验收口径 | 写明按什么标准判定成功，谁来判断 | 只有目标没有验收方式 |
| 成功标准 | 时间窗 | 标准适用的时间段或截止时点明确 | 时间表述模糊，如“上线后尽快” |
| 成功标准 | 责任方 | 每项标准有确认或验收的责任角色 | 标准无人认领，验收时互相推诿 |
| 启动授权 | 发起人与决策人 | 角色到人，职责区分清楚 | 只写部门名称，无具体角色 |
| 启动授权 | 资源与预算授权 | 授权范围、额度或审批路径有说明 | 资源描述停留在“给予支持” |
| 启动授权 | 里程碑授权 | 关键节点的审批或放行机制明确 | 里程碑只有时间，没有放行条件 |
拆条目时要注意颗粒度：条目太粗，判定会退化为印象打分；条目太细，评审成本超过收益。一个实用的做法是先按上表跑一轮，把反复出现争议的条目再细分，把从未触发问题的条目合并。
证据与数据口径：每项判定需要什么材料
每个检查条目都要指定证据来源，评审人依据材料判定，避免凭印象打分。可用的证据类型包括：Charter正文、附件、需求或商业论证材料、会议记录、干系人确认记录。证据可以来自文本本身，也可以来自文本引用的支撑材料，但需要在评审记录中写明出处。
定性条目的通过标准建议写成三要素：有明确表述、有责任人、有可核对对象。例如“范围排除项”条目，通过的标准是Charter中列出了排除内容，且排除项有对应的确认人，评审人能指出具体段落。三项缺一，判为部分符合。
定量条目的口径要写全五项：指标名称、分子分母、时间窗、单位、数据来源。以“缺陷密度”为例，需写明统计的是哪个阶段的缺陷数除以什么规模的代码或功能点、统计区间、单位（如个/千行）、数据取自哪个系统。口径不全的指标，即使数值看起来合理，也应判为证据不足而非符合。
缺失值与不可判定项的处理方式需要事先约定：
- 条目在Charter中完全没有提及，判为不符合；
- 条目有提及但表述无法核对，判为部分符合，并写明缺什么；
- 条目依赖的材料尚未提供，判为证据不足，标注待补，不推断为不通过；
- 条目本身不适用于该项目类型（如纯研究类项目的预算授权粒度），标注不适用并说明理由。
证据不足与不符合要分开记录。前者是材料问题，后者是文本问题，混在一起会让后续整改失去方向。
评审执行步骤：从逐项取证到汇总结论
评审按五个步骤执行，角色分工在第一步确定，判定规则在评审开始前公开，避免事后调整口径。
步骤一：确定评审人与角色。至少区分三类角色：发起人（提供业务背景与授权信息）、项目负责人（解释Charter内容、补充证据）、评审人（独立判定）。评审人宜包含一名不直接参与该项目的人员，用于交叉核对定性判断。
步骤二：逐项取证并填写判定结果。判定分四档：符合、部分符合、不符合、证据不足。每条记录写明证据出处和判定理由，理由要具体到段落或附件，不写“基本可以”这类结论。
步骤三：按要素汇总，识别阻断项与条件项。阻断项是缺失后无法进入立项评审的条目，例如目标完全不可衡量、启动授权缺失；条件项是可以限期补齐的条目，例如某项成功标准的时间窗待确认。哪些条目属于阻断项，应在评审前按组织约定列明。
步骤四：形成结论。结论分三档：
- 通过：无阻断项不符合，条件项在可接受范围内；
- 有条件通过：无阻断项不符合，但存在需限期补齐的条件项；
- 不通过：任一阻断项不符合，或条件项数量与影响超出约定范围。
判定规则示例：任一阻断项不符合即不通过；条件项需在约定时限内补齐并复核。阈值和时限由组织按项目规模设定，评审前写入规则说明。
步骤五：记录待办、责任人与复核时点。每条条件项对应一个待办，写明补齐内容、责任人和复核日期。评审记录、待办与复核时点可以在ONES这类研发管理平台中承载，把评审结论与立项评审流程衔接起来，具体配置以组织现有工具为准。
示例：一份研发Charter的评审记录
以下为演示情景，指标口径与阈值按组织实际设定，不代表通用标准。
背景：某研发项目Charter提出“将订单处理接口的平均响应时间从800毫秒降至400毫秒以内，覆盖高峰期日均120万次调用”，范围写明“改造订单查询与写入两条链路，不含支付链路”，成功标准写“上线后连续4周，P95响应时间不超过400毫秒，由运维团队按监控数据确认”，启动授权写“发起人为业务线负责人，预算授权50万元以内由项目负责人审批，超出部分报技术委员会”。
目标条目判定：指标名称（平均响应时间与P95）、时间窗（上线后连续4周）、单位（毫秒）、数据来源（监控系统）齐全，判为符合。需注意“平均响应时间”与成功标准中的“P95”口径不一致，记录为条件项，要求统一为同一统计口径。
范围条目判定：纳入项与排除项均有表述，关键交付物为两条链路的改造，判为符合；边界条件中未写明与支付链路的接口依赖如何处理，判为部分符合，列为条件项。
成功标准条目判定：验收口径、时间窗、责任方三项齐全，判为符合；但“高峰期”未定义具体时段，判为部分符合，要求补充高峰时段的定义。
启动授权条目判定：发起人与决策人明确，预算授权有额度与审批路径，判为符合；里程碑授权只写了时间节点，未写放行条件，判为部分符合，列为条件项。
汇总结论：无阻断项不符合，存在四项条件项（口径统一、依赖处理、高峰定义、里程碑放行条件），结论为有条件通过。四项条件项分别指定责任人与复核日期，复核通过后提交立项评审。
这个例子说明，评审记录的价值在于把“写得还行”转化为具体条目和具体缺口，让项目负责人在立项评审前知道改哪里。
结果解读与限制：结论能说明什么、不能说明什么
评审结论反映的是Charter文本的质量，即四类要素是否完整、可判定、可授权。它不保证项目执行结果，文本写得完整而执行失败的情况并不少见；反过来，文本存在条件项也不意味着项目不可行。把评审结论当作项目成功概率的预测，会误用这套方法。
定性判定受评审人经验影响。同一份Charter，不同评审人对“可衡量”的宽严把握可能不同。建议对争议条目采用多人交叉核对，或在评审前用样例校准判定尺度。定量条目的判定相对稳定，但前提是口径写全，口径不全时结论的可靠性会下降。
证据不足项应标注待补，不直接判为不合格。这类条目的处理方式是约定补充时限，到期后复核，而不是在本次评审中给出否定结论。评审结论也需要随项目进展更新：范围调整、目标修订、授权变更后，原结论不再适用，应重新走一遍关键条目。
最后，评审结论与立项决策、多项目准入是不同环节的输入。立项决策还要考虑战略匹配、资源竞争和风险偏好；多项目准入比较则涉及项目之间的排序。Charter质量评审只回答“这份文本是否具备进入决策的条件”，把这一层边界守住，评审才能稳定复用。
常见问题
Charter评审结论为“有条件通过”时，能否直接进入立项评审？
可以进入，但需要把条件项作为立项评审的已知输入一并提交。通常做法是：条件项对应待办、责任人和复核日期，在立项评审材料中列出尚未补齐的内容及其影响。若条件项涉及阻断性内容（例如启动授权额度未定），建议补齐后再提交，避免立项会上反复退回。是否允许带条件项进入立项评审，由组织在评审规则中事先约定。
评审人认为某条目“写得不够清楚”，但项目负责人坚持可以执行，如何判定？
回到判定口径：该条目是否有明确表述、有责任人、有可核对对象。三项齐全判符合；缺一项判部分符合，并写明缺的是哪一项，例如“排除项已列出，但无确认人”。把分歧落到具体缺失项上，比争论“清不清楚”更容易收敛。仍无法达成一致时，可由不直接参与该项目的一名评审人交叉核对，并在记录中保留双方意见。
项目类型不同，检查条目和阻断项是否要统一？
建议保留四类要素的框架统一，条目和阻断项按项目类型配置。纯研究类项目的预算授权粒度、预研类项目的成功标准时间窗，与交付类项目差异较大，强行统一会让评审退化为形式打勾。可行做法是维护一份基础条目表，再按项目类型增删条目，并在评审前公开本次适用的阻断项清单。
Charter在评审后发生范围或目标调整，原评审结论还有效吗？
原结论不再直接适用。范围、目标、成功标准或启动授权发生实质变更后，应针对变更涉及的条目重新取证判定，其余条目可沿用原记录并注明未变。若变更触及阻断项，需要重新形成结论。把评审记录与Charter版本对应起来，可以避免用旧结论支撑新文本。
评审记录、待办和复核时点用什么方式承载比较合适？
关键是让记录与Charter版本、立项评审流程可追溯。可以用文档加任务清单的方式承载，也可以在ONES这类研发管理平台中把评审记录、条件项待办和复核日期关联到项目上，便于到期提醒和复核留痕。具体用哪种方式，取决于组织现有的工具配置和立项流程习惯。
