项目章程模板在立项评审与启动授权中承担两项具体任务：评审前作为输入清单，让评审人逐条对照目标、范围、交付物、里程碑、预算与资源、干系人、风险和成功标准；评审后作为签署载体，把评审结论与授权范围固定在同一份文件上。本文按“填写—评审—签署—归档”的顺序给出操作步骤和配套表格，适用于单个项目是否启动的判断场景。章程版本、评审记录与签署状态可以在ONES中承载，便于形成可追溯的审批痕迹。
要点总览（TL;DR）
- 章程草案提交评审前，目标要可衡量、范围要有明确排除项、预算与资源要有初步口径，并锁定评审版本号、记录填写人与日期。
- 评审会议按“目标—范围—交付物—里程碑—预算与资源—干系人—风险—成功标准”逐条推进，每条意见记录条目、意见、提出人、处置方式、责任人与期限。
- 评审结论分为通过、有条件通过、退回修改三种；有条件通过时，附加条件必须写入授权记录，逐条列明内容、责任人与期限。
- 签署记录至少包含签署人、签署时间、签署版本、签署意见，签署版本须与评审通过的版本一致，授权范围写明预算、资源与范围变更权限。
- 归档时核对章程各版本、评审记录、签署记录、授权范围说明四类材料，重点检查签署版本与评审版本是否一致。
立项评审前，章程模板要填到哪一步
章程草案的填写深度以“评审人能据此提出具体意见”为标准。目标写成可衡量的结果，范围写出明确的排除项，预算与资源给出初步口径，评审才有可讨论的对象；停留在方向性描述的草案，评审容易变成泛泛讨论。
章程模板的核心字段
| 字段 | 填写要求 | 评审时的判断问题 |
|---|---|---|
| 项目目标 | 写成可衡量的结果，说明衡量口径与时间点 | 目标是否可验证，是否与业务诉求对应 |
| 范围边界 | 列出纳入事项，并明确写出排除项 | 排除项是否清晰，是否存在未声明的隐含范围 |
| 交付物 | 逐项列出可验收的产出物 | 交付物是否覆盖目标，验收标准是否可操作 |
| 里程碑 | 给出关键节点与时间，标注依赖关系 | 节点是否现实，关键依赖是否已识别 |
| 预算与资源 | 给出预算口径与所需人力、设备等资源 | 口径是否完整，资源是否已有来源 |
| 关键干系人 | 列出角色、影响方向与参与方式 | 决策人、使用方、受影响方是否齐全 |
| 主要风险 | 列出风险描述、影响与初步应对 | 高风险是否有应对责任人 |
| 成功标准 | 写成项目结束时可以核对的条目 | 标准是否与目标一致，是否可测量 |
提交评审前的完成度与版本锁定
提交前至少达到三项完成度：目标可衡量、范围有明确排除项、资源与预算有初步口径。其余字段允许保留待确认标记，但需注明待确认事项与确认时点，避免评审时把“未填写”误读为“无此内容”。
草案达到完成度后锁定评审版本号，例如“V0.9 评审版”，同时记录填写人与填写日期。评审过程中的修改另存新版本，评审版保持不动，这样后续签署时才能核对“签署的是否为评审通过的版本”。在ONES Wiki中，页面版本会被记录并可随时查看与回滚，章程草案的版本演进可以直接留在同一页面下；页面模板库也可用于统一章程的字段结构，减少每次立项重新搭框架的工作。
按章程条目组织立项评审的操作步骤
评审会议按章程条目逐条审议，而不是先听整体汇报再自由讨论。逐条审议让每条意见都能落到具体字段上，结论也更容易记录和跟踪。
评审角色与职责
- 发起人：介绍项目背景与目标，回答目标与资源来源相关问题，对评审意见表态。
- 项目经理：负责章程草案的填写与版本维护，记录评审意见，会后落实修改。
- 业务负责人：判断目标与业务诉求是否对应，确认范围边界是否符合业务预期。
- 财务或资源审批方：核对预算口径与资源来源，判断投入是否具备条件。
- 技术负责人：评估交付物与里程碑的技术可行性，识别技术风险。
逐条审议顺序与判断问题
建议按“目标—范围—交付物—里程碑—预算与资源—干系人—风险—成功标准”的顺序推进。前一项未形成结论时，后一项的讨论容易失去基准，例如范围未定就讨论里程碑，时间估算会反复推翻。每条的判断问题可直接采用上一节的表格列，主持人逐条点名相关角色发言，避免意见集中在少数人身上。
评审意见的记录字段
| 字段 | 填写内容 |
|---|---|
| 条目 | 对应章程的具体字段，如“范围边界” |
| 意见 | 评审人提出的具体问题或修改建议 |
| 提出人 | 意见提出者姓名与角色 |
| 处置方式 | 采纳、修改、保留三选一，并简述理由 |
| 责任人 | 负责落实该条意见的人 |
| 期限 | 完成修改或补充说明的日期 |
“保留”表示评审方提出意见但决定维持原写法，需要写明理由，否则归档后无法判断该意见是否被处理过。评审记录在ONES Wiki中可以通过页面注释与评论在线补充，评审人直接在对应段落旁反馈，项目经理汇总进记录表，减少会后追忆造成的遗漏。
评审结论的三种形态
- 通过：章程内容满足启动条件，进入授权签署环节。
- 有条件通过：主体内容可接受，但需在指定期限内完成若干修改或补充条件，附加条件须逐条写明并指定责任人。
- 退回修改：关键字段存在实质缺口，修改后重新提交评审，重新锁定评审版本。
结论形态直接决定后续动作：通过和有条件通过进入签署，退回修改回到填写环节。会议结束时应明确结论属于哪一种，并当场确认责任人与期限。
启动授权签署：谁签、签什么、怎么留痕
启动授权签署解决的是“谁有权批准这个项目按当前章程启动”。签署人层级应与授权范围对应：批准预算的层级签署预算授权，调配资源的层级签署资源授权，范围变更权限则明确到具体角色。授权范围超出签署人职权时，应升级到更高层级签署，或在授权记录中注明超出部分的另行审批安排。
签署对象
签署对象包括三部分：章程终稿、评审结论、授权范围说明。章程终稿是评审通过（或按附加条件修改完成）的版本；评审结论说明以何种形态通过；授权范围说明写明批准的预算额度、可调配资源、范围变更的审批权限。三者缺一，签署记录都无法独立说明“批准了什么”。
留痕方式
签署记录至少包含四项：签署人、签署时间、签署版本、签署意见。签署版本应写明章程版本号，与评审通过的版本一致；签署意见可以简短，但要能表达“同意启动”“同意有条件启动”或“暂不授权”的立场。纸质签署可扫描后与电子版一并归档，电子签署则保留签署页面或记录截图，确保签署动作与文件版本能对应。
有条件通过时的附加条件写入
有条件通过的附加条件不能只留在评审记录里，必须写入授权记录，逐条列出条件内容、责任人与完成期限，并说明条件未完成时的处理方式，例如暂停资源投入或重新评审。授权记录中写明附加条件，签署人才算对“带条件的启动”作出了明确授权。
角色分工与各环节交付物
下表把各角色在立项评审与授权签署中的输入、动作与输出放在同一口径下，便于交接时核对。
| 角色 | 输入 | 动作 | 输出 | 交接时点 |
|---|---|---|---|---|
| 发起人 | 业务诉求、资源意向 | 确认项目目标与资源来源，提交立项申请 | 立项申请与目标说明 | 章程填写开始前 |
| 项目经理 | 立项申请、章程模板 | 填写章程草案，锁定评审版本，记录评审意见并落实修改 | 章程草案、评审记录、章程终稿 | 评审前提交草案，评审后提交终稿 |
| 评审参与方 | 章程评审版 | 逐条审议，提出意见并标注处置方式 | 评审意见与评审结论 | 评审会议结束时 |
| 授权人 | 章程终稿、评审结论、授权范围说明 | 核对版本一致性，签署启动授权 | 签署记录 | 评审结论形成后 |
| 项目管理办公室（如有） | 章程各版本、评审记录、签署记录 | 核对归档材料完整性，登记项目启动状态 | 归档清单、启动登记 | 签署完成后 |
交接的关键在于版本：项目经理交给评审方的是锁定后的评审版，交给授权人的是评审通过后的终稿，两者版本号不同但修改轨迹可查。ONES Wiki的页面组可以关联项目，章程文档与项目工作保持对应；不同角色可以配置不同的读写权限，评审参与方在评审阶段获得评论权限、签署完成后收回编辑权限，权限变化本身也是审批痕迹的一部分。
示例：一个立项评审到授权签署的完整走查
以下为演示情景，用于说明模板填写、评审与签署的衔接方式，不对应真实项目。
章程草案关键字段示例
- 项目目标：在第三季度末上线客户自助查询功能，上线后两个月内人工查询工单量下降30%。
- 范围边界：纳入订单状态查询与物流进度查询；排除退款申请与发票下载，这两项由后续项目处理。
- 交付物：查询页面、后台接口、运营配置手册、上线验收报告。
- 里程碑：需求确认（第2周）、开发完成（第8周）、试运行（第10周）、正式上线（第12周）。
- 预算与资源：开发人力3人共10周，测试人力1人共4周，预算口径为内部人力成本加外部接口费用。
- 主要风险：物流接口稳定性不足，应对方式为试运行期增加监控与降级方案。
- 成功标准：功能按期上线，验收报告通过，上线两个月后工单量达到下降目标。
评审意见与处置示例
| 条目 | 意见 | 提出人 | 处置方式 | 责任人 | 期限 |
|---|---|---|---|---|---|
| 里程碑 | 试运行两周偏短，建议延长至三周 | 技术负责人 | 采纳，调整为第11周上线 | 项目经理 | 评审后2个工作日 |
| 预算与资源 | 外部接口费用未给出上限 | 财务审批方 | 修改，补充费用上限与审批方式 | 项目经理 | 评审后3个工作日 |
| 范围边界 | 建议把发票下载纳入本期 | 业务负责人 | 保留，本期范围不变，理由为工期与接口依赖 | 发起人 | 评审当场确认 |
本例评审结论为“有条件通过”：里程碑调整与费用上限补充作为附加条件，在授权记录中逐条列明。
授权签署记录示例
- 签署人：业务线负责人（预算与资源授权范围内）
- 签署时间：评审后第4个工作日
- 签署版本：章程V1.0（评审通过版，含附加条件修改）
- 签署意见：同意启动；附加条件两项须在开发启动前完成，未完成则暂缓资源投入。
- 授权范围：批准预算上限、开发与测试人力调配、范围变更须经发起人与业务负责人共同确认。
归档清单示例
- 章程V0.9评审版、V1.0终稿
- 逐条评审记录表与评审结论
- 启动授权签署记录
- 授权范围说明
- 附加条件完成情况说明
审批痕迹的归档与完成检查
归档的目标是让任何一位未参与评审的人，仅凭归档材料就能回答三个问题：评审的是哪个版本、批准了什么范围、签署人是谁。围绕这三个问题核对，比逐份翻看文件更有效。
归档内容与一致性检查
归档材料包括章程各版本、评审记录、签署记录、授权范围说明四类。核对时重点检查三项一致性：签署版本号与评审通过的版本号一致；授权范围说明中的预算、资源、变更权限与签署意见一致；附加条件在评审记录与授权记录中的表述一致。版本号不一致时，以评审通过的版本为准重新签署，不能以“内容基本相同”为由沿用旧签署。
常见缺口
- 签署版本与评审版本不一致：评审后修改了章程但未重新确认，签署的是修改前版本或修改后未复核的版本。
- 有条件通过未记录附加条件：附加条件只出现在会议纪要中，授权记录未写入，后续无法判断启动是否附带前提。
- 授权范围未写明：签署记录只有签名与日期，没有预算额度与变更权限，执行阶段出现范围调整时缺少判断依据。
完成检查清单
| 检查项 | 通过标准 |
|---|---|
| 章程评审版已锁定 | 有版本号、填写人、填写日期 |
| 评审记录完整 | 每条意见含条目、意见、提出人、处置方式、责任人、期限 |
| 评审结论明确 | 属于通过、有条件通过、退回修改之一，并有结论说明 |
| 签署版本一致 | 签署版本号等于评审通过版本号 |
| 授权范围写明 | 预算、资源、范围变更权限均有明确表述 |
| 附加条件已写入 | 有条件通过时，条件内容、责任人、期限、未完成处理方式齐全 |
| 归档材料齐全 | 章程各版本、评审记录、签署记录、授权范围说明四类齐备 |
在ONES中，章程文档的版本记录、评审阶段的页面评论与角色读写权限，可以把上述材料集中在同一项目页面组下，归档时按版本与权限记录逐项核对。审批流转与电子签署若需要原生能力，应在选型阶段结合组织实际流程确认配置方式。
常见问题
评审会上意见分歧较大、无法当场形成结论时，应该怎么处理？
分歧集中在某个字段时，先确认该字段是否属于启动的必要条件。目标、范围、预算与资源这类关键字段无法达成一致，宜按“退回修改”处理，明确需要补充的信息与重新提交的时间，而不是带着未决问题进入签署。
分歧出现在非关键字段时，可以按“有条件通过”处理，把待定事项写成附加条件，指定责任人与完成期限，并在授权记录中同步写明。无论哪种处理，评审记录中都要保留各方意见与处置方式，避免会后口头约定无法追溯。
签署人职权范围覆盖不了章程中的预算或资源额度，怎么办？
授权范围超出签署人职权时，有两种处理方式：升级到更高层级签署，或由当前签署人就其职权内部分签署，超出部分另行报批并在授权记录中注明。
无论采用哪种方式，授权记录都应写清哪部分由谁批准、哪部分仍在审批中。若超出部分尚未获批，启动授权可以标注为“部分授权”，并说明未获批部分对应的资源投入暂不启动，避免执行阶段出现无授权依据的支出。
有条件通过的项目，附加条件到期未完成，启动授权是否仍然有效？
这取决于授权记录中对附加条件未完成的处理约定。签署时应在授权记录中写明条件未完成时的处理方式，例如暂停资源投入、限制部分范围或重新提交评审。
条件到期时，由责任人提交完成情况说明，授权人据此判断是否维持授权。若条件涉及预算或范围等关键内容，建议重新走一次评审确认，而不是由项目经理单方面决定继续推进。完成情况说明也应归入归档材料，与授权记录一并保存。
章程在签署后需要修改，审批痕迹怎么保持连续？
签署后的修改应另起新版本，原签署版本保持不动。修改内容涉及目标、范围、预算或里程碑等关键字段时，需要重新评审并由原授权人或更高层级重新签署；仅涉及文字表述或非关键补充时，可由项目经理记录变更说明，经授权人确认后附在原签署记录之后。
无论哪种情况，归档中都要能看出“哪一版被签署、哪一版被修改、修改由谁确认”。版本号连续、变更说明与确认记录齐全，审批痕迹才不会在修改环节断掉。
规模较小的项目是否也需要完整的评审与签署流程？
流程深度可以随项目规模和风险调整，但“评审有记录、签署有依据”这两点建议保留。小项目可以简化评审形式，例如由发起人、项目经理和相关职能负责人以书面会签代替会议，评审记录仍按条目记录意见与处置方式。
签署环节同样保留签署人、签署时间、签署版本与授权范围四项要素，只是授权范围可以写得更简短。判断标准是：未参与项目的人能否仅凭归档材料说清批准了什么、由谁批准。满足这一点，简化后的流程就是完整的。
