项目计划评审的目标，是把计划从项目经理一个人的排期，变成团队共同承诺的基线。本文按评审前准备、评审会操作、角色分工、检查清单、示例和完成确认六个环节展开，适用于项目整体计划、阶段计划或里程碑计划的评审。评审通过的标准是范围、里程碑、关键依赖、资源缺口和主要风险都有明确结论，计划文档写得完整只是基础条件。
要点总览（TL;DR）
- 评审前先确定评审对象与层级，判断范围初稿、里程碑、关键依赖和资源需求是否具备准入条件，材料至少提前两个工作日发出。
- 评审分两段：会前按范围、进度、资源、风险分角色预审并区分阻断项与一般意见，会上只处理阻断项和承诺，一般意见会后书面回复。
- 评审结论分通过、有条件通过、退回修改三种，判定依据是范围、里程碑、关键依赖、资源缺口和主要风险是否都有明确结论。
- 修改项必须带责任人和期限，有条件通过需明确复评时间，基线更新后通知相关方，评审记录归档供下次对照。
- 评审是否做到位看闭环：结论明确、修改项无待定、基线已更新、未决事项有复评安排、记录可追溯，出现无人提阻断项等信号需回头检查准入和角色分工。
评审前要准备什么：对象、准入条件与材料
评审启动前先回答三个问题：评什么、够不够格评、谁来评。这三项没有确定，评审会很容易变成信息同步会，讨论无法收敛到结论。
确定评审对象与层级
先明确本次评审的计划层级。项目整体计划评审关注范围边界、总里程碑和跨团队依赖；阶段计划评审关注本阶段的交付物、资源投入和上下阶段衔接；里程碑计划评审关注关键时间点前后的任务完整性和决策点。层级不同，参会角色和检查重点也不同，一次评审只评一个层级，避免议题混杂。
准入条件判断
计划进入评审前应满足以下条件，缺项较多时先退回补充，不占用评审会时间：
- 范围初稿已完成，交付物清单和边界说明可读；
- 里程碑已排定，至少覆盖启动、关键交付和验收节点；
- 关键依赖已识别，包括外部团队、供应商和前置任务；
- 资源需求已按角色列出，投入比例或人天有初步估算。
准入判断由评审发起人完成，判断结果记录为“可评审”或“退回补充”，退回时写明缺项和补充期限。
提交材料与时限
材料清单建议包含：计划文档（含工作分解与里程碑）、依赖清单、资源需求表、风险与假设清单、上一版基线（如有）。材料至少在评审会前两个工作日发出，给预审角色留出核对时间。材料版本号与提交时间一并记录，会上讨论以该版本为准。
发起人与参会名单
评审发起人通常由项目经理担任，负责组织材料、确定议程和记录结论。参会角色按评审层级确定：范围与验收口径需要业务或需求方在场，技术可行性需要技术负责人确认，资源投入需要资源负责人确认，评审规则和结论记录由质量人员或指定主持人把关。名单在发出材料时同步确认，缺席的关键角色需提前指定代理人。
评审怎么开：从预审到结论会的操作步骤
评审分两段进行：会前分角色预审，会上集中确认。预审解决“各自看到的问题”，集中会解决“问题如何定论”。下表给出各步骤的输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 分角色预审 | 计划文档、依赖清单、资源表、风险清单 | 范围、进度、资源、风险四类角色按各自检查项核对，标记疑问和阻断项 | 预审意见清单，按阻断项和一般意见分类 | 各类角色意见在会前汇总到发起人 |
| 集中评审会 | 预审意见清单、计划文档 | 按议程逐项确认假设、依赖和资源缺口，对阻断项当场给出处理方向 | 会议结论草案、修改项清单 | 阻断项均有结论或明确复评安排 |
| 修改项登记 | 会议结论草案 | 为每项修改指定责任人、期限和复评方式 | 修改项台账 | 每项修改都有责任人和期限 |
| 结论确认 | 修改项台账、复评结果 | 按判定依据给出通过、有条件通过或退回修改 | 评审结论记录 | 结论经参会关键角色确认 |
分角色预审各自核对什么
范围预审核对交付物清单是否覆盖验收要求、边界外事项是否写明；进度预审核对里程碑之间任务是否完整、关键路径是否识别、缓冲是否集中在关键路径末端；资源预审核对各角色投入是否与任务量匹配、是否存在同一人员跨项目冲突；风险预审核对外部依赖是否有承诺方、假设是否登记、应对措施是否落到具体动作。预审意见按“阻断项”和“一般意见”分开提交，阻断项指不解决就无法承诺计划的问题。
集中评审会的议程与时间分配
一场两小时的评审会可按以下节奏安排：十分钟说明评审目标和结论规则；三十分钟逐项过阻断项，每项给出处理方向；三十分钟讨论依赖与资源缺口，明确承诺方；二十分钟确认修改项和责任人；十分钟总结结论。一般意见不逐条展开，会后书面回复处理结果。
确认假设、依赖与资源缺口的提问方式
提问要指向可验证的事实。对假设问“这个假设如果不成立，哪个里程碑会受影响”；对依赖问“对方在什么时间点交付什么，由谁确认”；对资源缺口问“缺口由谁补、什么时间确认、补不上时计划如何调整”。每个问题当场记录结论或记为未决事项，未决事项指定复评时间。
三种评审结论及判定依据
- 通过：范围、里程碑、关键依赖、资源缺口和主要风险均有明确结论，无未处理的阻断项，计划可发布为基线。
- 有条件通过：主体计划可承诺，但存在少量修改项或未决事项，明确责任人和期限后先行发布基线，到期复评。
- 退回修改：存在未解决的阻断项，如关键依赖无承诺方、资源缺口影响关键路径、范围边界不清，计划返回修改后重新提交评审。
谁参加、各自交付什么：角色与职责分工
评审变成项目经理单人汇报，通常是因为角色职责没有提前界定。下表按角色列出评审中的主要动作和交付物，参会时按此对号入座。
| 角色 | 评审中的职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织评审、准备材料、维护计划基线、跟踪修改项闭环 | 评审材料包、修改项台账、更新后的计划基线 |
| 技术或方案负责人 | 确认工作分解是否覆盖技术工作、技术方案是否可行、工作量估算是否合理 | 技术可行性意见、估算修正建议 |
| 资源负责人 | 确认各角色人力投入、识别跨项目冲突、对缺口给出补充或调整方案 | 资源承诺或缺口说明 |
| 质量或评审主持人 | 把关评审规则执行、控制议程节奏、记录结论和未决事项 | 评审结论记录、未决事项清单 |
| 业务或需求方 | 确认范围边界、交付物形态和验收口径 | 范围与验收口径确认意见 |
角色可以由同一人兼任，但职责不能省略。小团队中技术负责人可兼资源确认，业务方确认范围这一环仍需有明确的人签字或书面回复，否则范围争议会留到执行阶段。
评审检查清单：逐项判断计划是否可承诺
检查清单用于会上逐项核对，每类给出通过标准和阻断项。阻断项未解决时，评审结论不能为“通过”。
| 类别 | 检查项 | 通过标准 | 阻断项示例 |
|---|---|---|---|
| 范围 | 交付物清单、边界说明、验收口径 | 每项交付物有验收标准，边界外事项已写明 | 核心交付物无验收口径 |
| 进度 | 里程碑、关键路径、缓冲 | 里程碑覆盖关键决策点，关键路径已识别，缓冲位置合理 | 关键路径未识别或缓冲为零 |
| 资源 | 角色、投入比例、缺口 | 各角色投入与任务量匹配，缺口有补充方案 | 关键角色无投入承诺 |
| 依赖 | 外部依赖、内部前置任务 | 每项依赖有承诺方和交付时间 | 关键依赖无承诺方 |
| 风险 | 假设、风险登记、应对措施 | 主要风险有应对动作和触发条件 | 影响里程碑的风险无应对措施 |
清单的使用方式是逐项标记“通过、待补充、阻断”，待补充项进入修改项台账，阻断项当场讨论处理方向。清单本身随评审记录归档，作为下次评审的对照依据。
一个评审示例：从提交到基线确认
以下为演示情景，用于说明各步骤如何衔接，不对应真实项目。
某中等规模系统建设项目提交整体计划评审。材料包括工作分解、六个里程碑、依赖清单和资源需求表。预审阶段，技术负责人指出测试环境准备任务未纳入分解，进度预审发现联调里程碑前没有缓冲，资源预审发现两名后端工程师在同期另一个项目中已有七成投入，风险预审发现第三方接口交付只有口头时间、无承诺方。前三项列为阻断项，第四项列为一般意见。
评审会上，测试环境任务当场补入分解并调整联调里程碑；缓冲调整为集中在联调前的关键路径末端；资源负责人确认其中一名工程师的冲突可通过调整另一项目排期解决，另一名维持原投入但需每周核对饱和度；第三方接口依赖由业务方在一周内取得书面交付时间。会议结论为“有条件通过”：计划先行发布基线，第三方接口承诺和资源调整作为修改项，责任人和期限当场登记，两周后复评。
复评时两项修改项均完成，基线版本更新并通知相关方，评审闭环。这个示例可迁移的规律是：预审把问题分类，会上只处理阻断项和承诺，修改项带期限闭环。适用边界在于，跨组织依赖多、承诺方不在场的项目，需要把依赖确认单独安排一次会议，不能指望一场评审解决所有外部承诺。
评审结论、修改项和计划基线需要有承载的地方，否则闭环依赖个人记忆。ONES 的项目计划支持设置计划和里程碑基线，并通过版本对比追溯变更细节；评审形成的修改项可以作为工作项登记责任人和期限，基线更新后在系统中留痕，便于复评时对照。这套承载方式适用于已经用工具管理计划的团队，评审规则本身仍需团队自行约定。
评审完成后怎么确认做到位
评审是否产生可执行结果，用以下检查项确认：
- 评审结论已记录，结论类型明确为通过、有条件通过或退回修改；
- 每项修改项都有责任人和期限，无“待定”项；
- 计划基线已更新，版本号变化并通知相关方；
- 未决事项写明复评时间和复评责任人；
- 评审记录、预审意见和结论可追溯，下次评审能调取对照。
形式化评审有几个可识别的信号：会上无人提出阻断项，预审意见只有“同意”；修改项没有责任人或期限，会后无人跟踪；结论写“原则通过”但没有基线版本；未决事项没有复评安排。出现这些信号时，评审的实际作用有限，需要回到准入条件和角色分工上检查哪一环被省略了。
评审完成后，计划进入执行阶段，进度偏差的处理属于项目进度管理的范围，本文不展开。评审建立的基线、依赖清单和风险登记，正好是后续偏差分析和变更控制的输入。
常见问题
计划材料还不完整，可以先开评审会边讨论边补吗？
不建议。准入条件的作用是把补充工作挡在评审会之前，范围初稿、里程碑、关键依赖和资源需求缺项较多时，会上讨论会散成信息同步，难以收敛到结论。更稳妥的做法是由评审发起人做准入判断，记录为“退回补充”，写明缺项和补充期限，补齐后再排评审。若只有个别非阻断项缺失，可以进入评审，但要在修改项台账中登记，不影响结论判定。
关键角色当天来不了，评审还能照常进行吗？
取决于缺席角色承担的确认事项。范围与验收口径需要业务或需求方确认，资源投入需要资源负责人承诺，这两类角色缺席时，相关结论无法当场定论，评审容易变成“有条件通过”甚至退回。可行做法是提前指定有决策权的代理人，或在议程中把该角色负责的议题单独安排复评。技术负责人的意见可以由方案团队内部先形成书面结论带入会场，但承诺类事项仍需有明确的人确认。
“有条件通过”和“退回修改”的界线怎么把握？
看阻断项是否影响计划可承诺。主体计划可以先行发布基线、剩余问题有明确责任人和期限的，判为有条件通过；存在关键依赖无承诺方、资源缺口影响关键路径、核心交付物无验收口径这类阻断项的，判为退回修改。界线不清时按更严格的一档处理，因为带着未解决阻断项发布基线，后续变更成本更高。有条件通过的修改项到期必须复评，复评不通过再转为退回修改。
评审记录和修改项放在哪里，才能支撑复评和追溯？
评审记录、预审意见、结论和修改项台账应放在团队共同可访问的位置，并与计划版本对应。修改项登记责任人和期限后，需要有跟踪机制，到期前能提醒、复评时能对照。ONES 的项目计划支持设置计划和里程碑基线，并通过版本对比追溯变更细节；评审形成的修改项可以作为工作项登记责任人和期限，基线更新后在系统中留痕，便于复评时对照。具体用哪种工作项类型和模板，需要团队按自身流程约定。
跨团队或外部供应商的依赖，能在一场评审里全部确认吗？
通常不能。外部依赖的承诺方往往不在评审会场，会上只能确认“由谁去取得承诺、什么时间反馈”，无法当场完成承诺本身。建议把外部依赖确认单独安排一次对接会议，或在评审中将其登记为带期限的修改项，到期复评。评审会上重点确认依赖的识别是否完整、每项依赖是否有对接人和反馈时间，避免把“已识别”误当成“已承诺”。
