项目章程要解决的是启动授权问题：为什么做、做到什么程度、谁负责、凭什么可以开始。本文面向第一次起草章程的项目负责人，给出一份可直接套用的章节骨架、六步编写流程、目标与成功标准的写法、角色分工、完整填写样例和提交前检查清单，范围限定在单个项目的章程编写。
要点总览（TL;DR）
- 章程只承载启动授权所需的信息：背景与依据、目标与成功标准、范围与交付物、关键角色与决策权限、里程碑与约束假设、高层风险、审批签署，详细计划留给项目管理计划。
- 编写按六步推进：收集立项依据、起草目标与成功标准、界定范围边界、确认角色与权限、写里程碑与风险、评审修订并签署归档。
- 目标要写成“指标＋口径＋时间”的可检验表述，范围同时列包含项与排除项，验收口径在章程中定方向、在需求文档中细化。
- 发起人提供依据并签署授权，项目经理负责起草与组织评审，职能负责人确认职责与资源，评审方把关一致性；决策权限落到具体事项并写明升级路径。
- 提交前用检查清单逐项核对，目标无法判断达成、范围无排除项、关键角色未确认、里程碑无判断标准等属于阻断项，需修订后再提交。
项目章程先写哪几块：一份可评审的文档骨架
章程的篇幅通常控制在三到五页，章节按“授权所需信息”组织，不追求覆盖项目全貌。下面这张骨架表可以直接作为文档目录使用，每章回答一个问题，答完即止。
| 章节 | 回答的问题 | 建议篇幅 |
|---|---|---|
| 项目背景与立项依据 | 为什么现在要做这个项目，依据来自哪里 | 半页以内，引用决议、业务需求或问题记录 |
| 项目目标与成功标准 | 项目要达成什么结果，怎样算成功 | 半页，目标三到五条，成功标准逐条可度量 |
| 范围与主要交付物 | 做什么、不做什么，交付哪些成果 | 一页，包含项与排除项分列 |
| 关键角色与决策权限 | 谁发起、谁负责执行、谁做关键决策 | 半页，可用表格 |
| 里程碑与关键约束假设 | 关键时间点是什么，受哪些条件和前提限制 | 半页，里程碑三到六个为宜 |
| 高层级风险 | 哪些风险会影响项目成立，初步应对方向是什么 | 半页以内，列三到五条 |
| 审批与签署 | 谁批准章程生效，版本如何记录 | 签署区加版本记录表 |
详略原则是：能影响授权决策的内容写实，执行层面的内容写方向。例如里程碑写到阶段和关键日期即可，具体任务分解留给项目计划；风险写到类别、影响和应对方向，详细风险登记册在计划阶段建立。
章程与后续文档的分工需要提前说清，避免同一内容在多份文档里各写一版。章程承载启动授权：目标、成功标准、范围边界、关键角色、里程碑、高层风险、签署。项目管理计划承载执行安排：工作分解、进度排布、资源与预算明细、质量与沟通计划。需求文档承载具体功能与验收细则。章程中提到的验收口径是方向性的，细化到条目级由需求文档承接。
从立项意图到章程初稿：六步编写流程
编写章程不是一次成文，而是从零散依据逐步收敛到可签署文本的过程。以下六步按顺序执行，每步都有明确的输入和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集立项依据 | 业务需求、问题记录、上级决议、干系人诉求 | 整理依据来源，标注每条依据的提出方和时间 | 立项依据清单 | 每条依据都能追溯到具体来源 |
| 2. 起草目标与成功标准 | 立项依据清单 | 把业务诉求转成项目目标，为每条目标配可度量标准 | 目标与成功标准草稿 | 每条成功标准都有指标、口径和时间 |
| 3. 界定范围边界 | 目标草稿、需求初步清单 | 列出包含项与排除项，标注主要交付物 | 范围说明 | 排除项至少覆盖一个易混淆的相邻需求 |
| 4. 确认角色与决策权限 | 组织架构、资源意向 | 与发起人、职能负责人逐一确认职责和决策范围 | 角色职责表 | 关键角色本人确认，决策权限无空白 |
| 5. 写里程碑、约束假设与高层风险 | 目标、范围、资源条件 | 设定阶段节点，记录约束与假设，列出高层风险及应对方向 | 里程碑表、风险条目 | 每个里程碑有可判断的完成状态 |
| 6. 评审、修订与签署归档 | 章程初稿 | 组织内部评审，逐条处理意见，提交审批签署并归档 | 签署版章程与版本记录 | 签署完成，评审意见全部关闭或有结论 |
第1步常被跳过，导致目标写得空。收集依据时重点找三类材料：说明“为什么现在做”的业务背景，说明“做到什么程度”的期望描述，以及说明“谁在意结果”的干系人诉求。依据越具体，第2步的转化越顺。
第4步需要面对面确认，不宜只发邮件。角色确认的核心是两件事：这个人承担什么职责，以及在哪些事项上有决定权。资源投入的承诺也在此步落实，避免章程签署后才发现关键岗位无人承接。
第6步的评审通常进行一到两轮。第一轮由评审方检查目标、范围、角色、里程碑之间是否自洽；修订后第二轮聚焦遗留分歧，形成结论。评审意见要逐条记录处理结果，未采纳的意见写明理由。签署完成后即进入归档，版本号从1.0起编。
目标与成功标准怎么写才可验收
目标写空泛，根源是把手段当成了目标。判断标准很简单：一条目标如果无法回答“做到什么程度算完成”，就需要重写。写法上分两层：目标描述期望的业务结果，成功标准给出可检验的度量。
把业务目标转成成功标准，可以按“指标＋口径＋时间”三要素组织。例如业务诉求是“提升客户报修响应速度”，对应的目标写成“缩短客户报修从提交到首次响应的周期”，成功标准写成“上线后三个月内，报修工单首次响应时间中位数从当前水平降至4小时以内，统计口径为工单系统记录的提交时间至首次人工回复时间”。指标、口径、时间齐全，验收时无需再解释。
范围表述要同时写包含项和排除项。只写包含项，边界靠默认理解，后续争议多；排除项的作用是把容易混淆的相邻需求明确挡在范围外。示例：
- 包含项：报修工单的在线提交、自动分派、首次响应计时与超时提醒。
- 排除项：备件库存管理与维修人员排班功能，本期不纳入，由后续项目另行评估。
验收口径与变更的关系要在章程里点明：章程中的成功标准是项目验收的方向依据，具体验收条目在需求文档中细化；范围或成功标准发生实质变化时，需走变更评审并更新章程版本，不能只在执行层面口头调整。这样处理，章程才能持续作为后续计划的对照基准。
角色与职责：谁写、谁审、谁签
章程编写涉及四类角色，职责边界清楚，评审和签署才顺畅。发起人提供立项依据，确认目标与资源承诺，并签署授权；项目经理负责起草全文、组织评审、汇总修订；职能负责人确认本领域职责、资源投入和交付配合方式；评审方（可包括业务、技术、财务等代表）检查内容一致性与可行性，提出评审意见。
| 角色 | 编写阶段职责 | 决策权限 | 签署 |
|---|---|---|---|
| 发起人 | 提供立项依据，确认目标与成功标准 | 批准项目启动、目标调整、范围重大变更 | 签署授权 |
| 项目经理 | 起草章程，组织评审，处理修订 | 章程文本编辑与版本维护 | 起草人签署 |
| 职能负责人 | 确认职责分工、资源投入与配合方式 | 本领域资源调配 | 会签确认 |
| 评审方 | 评审一致性与可行性，提出意见 | 提出评审结论（通过、修订后通过、退回） | 评审记录 |
决策权限的写法要落到具体事项，避免只写“负责项目重大决策”。建议在章程中列明：目标或成功标准的调整由发起人批准；范围排除项之外的新增需求进入变更流程，由发起人与项目经理共同评估；里程碑日期的调整由项目经理提出、发起人确认。升级路径同样写清：项目经理与职能负责人在资源安排上无法达成一致时，提交发起人裁决。
签署与版本记录的责任人是项目经理。每次修订记录版本号、修订日期、修订内容和修订人，签署页保留各角色签署日期。章程定稿后的评审、会签与版本留存，如果团队使用项目协作工具承载，可以把章程文档、评审意见和签署记录放在同一工作项下关联管理，ONES 的文档与工作项协作可用于这类评审留痕和版本追溯；具体审批流配置以团队实际使用的工具能力为准。
完整示例：一份单项目章程的填写样例
以下为演示情景，用于说明各章节如何落笔，实际编写时按项目情况替换内容。
项目背景与立项依据。客户服务部门连续两个季度反馈报修响应慢，客户满意度调查中“响应速度”一项评分下降。依据为客服部提交的改进需求单（编号与日期）及季度经营会决议。
项目目标与成功标准。目标：建立报修工单的在线受理与自动分派机制，缩短首次响应周期。成功标准：上线后三个月内，工单首次响应时间中位数降至4小时以内；工单自动分派覆盖率达到90%以上；统计口径以工单系统记录时间为准。
范围与主要交付物。包含：在线提交入口、自动分派规则、响应计时与超时提醒、工单状态看板。排除：备件库存管理、维修人员排班。主要交付物为工单系统功能模块、分派规则说明、上线培训材料。
关键角色与决策权限。发起人为客服部负责人，批准启动与目标调整；项目经理负责起草与执行协调；IT 负责人确认系统开发资源；运营主管确认分派规则。范围新增需求由发起人与项目经理共同评估后进入变更流程。
里程碑与关键约束假设。里程碑：需求确认完成、分派规则上线试运行、全量上线、上线后三个月效果评估。约束：开发资源在季度内只有两名工程师可用。假设：现有工单系统支持接口扩展。
高层级风险。分派规则与实际业务不匹配，应对方向是试运行期收集反馈并调整；开发资源不足导致延期，应对方向是提前锁定排期并设置范围优先级。
签署区与版本记录。签署区列发起人、项目经理、IT 负责人、运营主管的签署栏与日期。版本记录示例：V1.0，某年某月某日，首次发布，项目经理；V1.1，某年某月某日，调整试运行里程碑日期，项目经理，发起人确认。
提交前的完成检查清单
章程是否可以提交审批，用下面这张清单逐项核对。任一项落入阻断条件，先修订再提交。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 目标与成功标准 | 每条目标配有指标、口径和时间 | 存在无法判断是否达成的目标 |
| 范围 | 包含项与排除项分列，主要交付物明确 | 只有包含项，无任何排除项 |
| 角色与权限 | 关键角色已确认，决策事项与升级路径写清 | 关键角色未确认或决策权限存在空白 |
| 里程碑 | 每个节点有可判断的完成状态和日期 | 里程碑只有名称没有判断标准 |
| 约束假设与风险 | 约束、假设与高层风险各列若干条，风险有应对方向 | 风险条目缺失或只有风险名称 |
| 签署与版本 | 签署角色齐全，版本记录表已建立 | 无签署区或无版本记录 |
常见退回原因集中在三类：目标写成口号、范围没有排除项、角色只写岗位不写决策事项。评审前按清单自查一遍，能显著减少往返。
章程定稿后进入维护状态。触发重新评审的条件包括：项目目标或成功标准调整、范围排除项之外出现重大新增需求、关键角色更换、里程碑整体后移超过约定阈值。每次变更更新版本号并保留修订记录，使章程与后续项目管理计划保持同一基准。
常见问题
章程写多长合适，写细了会不会和项目计划重复？
章程通常控制在三到五页，判断标准是内容是否影响启动授权决策。目标、成功标准、范围边界、关键角色、里程碑、高层风险、签署这些内容写实；工作分解、进度排布、资源与预算明细、质量与沟通安排放到项目管理计划。同一内容只在一份文档里写细，其他文档引用即可，避免多份文档各写一版、后续修订不同步。
发起人很忙，目标与成功标准可以由项目经理直接定吗？
项目经理可以起草，但目标与成功标准需要发起人确认。目标涉及业务结果的取舍和资源承诺，超出项目经理的授权范围。实际操作中，项目经理先依据立项依据写出草稿，标注每条标准的指标、口径和时间，再约发起人用一次短会确认；发起人对某条标准有异议时当场调整，避免评审阶段才发现方向不一致。
项目进行中范围发生变化，章程要跟着改吗？
看变化的性质。排除项之外出现重大新增需求、目标或成功标准调整、关键角色更换、里程碑整体后移超过约定阈值，这些情况应触发章程重新评审并更新版本号。执行层面的细节调整在项目管理计划或需求文档中处理，不必每次改动章程。章程中提前写明变更触发条件，后续判断就有依据。
小项目也需要完整的章程和正式签署吗？
可以简化篇幅，但授权要素不宜省略。小项目可以把章节压缩到一页，背景写两三句，目标与成功标准各一条，范围只列关键包含项和一条排除项，角色写清发起人和负责人，签署用简化的确认记录。省略目标或范围边界，后续出现分歧时缺少对照基准，返工成本往往高于写这一页的时间。
章程签署后放在哪里，怎么保证评审意见和版本不丢？
签署版章程、评审意见处理记录和版本记录应集中存放，并与项目工作项关联，便于执行阶段随时对照。使用项目协作工具时，可以把章程文档、评审记录和签署信息放在同一项目空间下管理，ONES 的文档与工作项协作可用于这类评审留痕和版本追溯，具体审批流配置以团队实际使用的工具能力为准。无论用哪种方式，版本号、修订日期、修订内容和修订人都要记录完整。
