轻量级研发项目Charter的裁剪重点落在目标与范围两处：目标保留可验证的成果与成功标准，压缩背景叙述和长期愿景；范围保留本期交付边界、明确不做的内容和关键依赖，压缩逐条需求清单与详细工作分解。授权部分保留决策人、变更审批和升级路径三项即可。裁剪深度由项目规模、不确定性和跨团队依赖程度决定，不必套用同一份模板。
要点总览（TL;DR）
- 轻量Charter的最小信息集是目标、范围边界、授权与决策、关键依赖与风险四类，其余内容后移到计划、需求文档和迭代安排。
- 目标章节保留一句可验证成果、两到三条成功标准、一句业务关联，压缩背景铺陈、长期愿景和指标全集。
- 范围章节用“包含—不包含—依赖”三段式划边界，逐条需求清单和完整WBS交给下游文档。
- 授权保留项目负责人与决策人、变更审批触发条件、升级路径三项，多级会签和完整职责矩阵按组织制度另行承载。
- 编写深度按项目规模、不确定性和跨团队依赖程度判断：小型控制在一页内，中型写实边界与决策规则，大型分阶段表述并回补审批节点。
轻量级Charter先回答哪几个问题
一份轻量Charter的作用，是让参与方在投入资源前对“做成什么、做到哪里、谁拍板”形成一致理解。它承担立项判断的职责，详细执行规划交给后续的计划、需求文档和迭代安排。判断内容该留还是该移，可以用一个问题检验：这条信息如果缺失，是否会导致立项结论改变或启动后立刻产生争议。会改变结论的留下，只影响执行细节的移到下游文档。
轻量Charter的最小信息集包括四类内容：
- 目标：本期要达成的可验证成果，以及判断达成的成功标准。
- 范围边界：本期交付什么、明确不做什么、依赖哪些外部方。
- 授权与决策：项目负责人、最终决策人、变更审批规则和问题升级路径。
- 关键依赖与风险：影响成败的外部条件，以及每项条件的责任人。
可以后移到其他文档的内容包括：逐条需求描述、完整工作分解结构（WBS）、详细排期与资源明细、技术方案设计、测试用例清单。这些内容在立项阶段往往尚未稳定，提前写全容易造成返工，也会让Charter变成一份无人维护的长文档。
编写深度按三个维度判断。项目规模小、目标清晰、由单一团队交付时，Charter可以控制在一页以内；不确定性高（例如技术路线待验证、需求方向待探索）时，目标和成功标准要写得更具体，范围反而可以留出探索空间；跨团队依赖多时，范围边界和接口方必须写清楚，授权部分也要明确升级路径。三个维度中任何一个突出，对应章节就加深，其余章节保持精简。
目标部分可以裁剪到什么程度
目标章节保留三项内容即可支撑立项：一句可验证的成果描述、两到三条成功标准或验收口径、一句与业务目标的关联。成果描述回答“项目结束时什么会变得不同”，成功标准回答“凭什么判断做到了”，业务目标关联回答“为什么现在做这件事”。
可以裁剪的内容包括：行业背景与市场形势铺陈、三到五年的长期愿景、多层级的OKR目标树、覆盖所有维度的量化指标全集。这些内容在立项材料中常见，但对单项目的启动决策贡献有限，写多了反而稀释重点。长期愿景可以留在产品规划文档中，指标全集可以在项目执行中逐步补充。
一个可操作的写法是“一句话成果加两到三条成功标准”。例如：
- 成果：为现有订单系统增加批量导入能力，使运营人员可以一次导入千条级订单。
- 成功标准一：单次导入一千条订单在五分钟内完成，失败记录可导出并定位到具体行。
- 成功标准二：上线后一个月内，运营团队日常订单录入中有八成通过批量导入完成。
成功标准要能被验证，避免“提升用户体验”“显著提高效率”这类无法核对的表述。如果立项阶段确实无法给出量化口径，可以写清验证方式和验证时间点，例如“上线两周后由运营负责人组织验收，以抽样比对结果为准”。
范围部分如何划边界而不写全量需求
范围章节的核心是用边界和排除项替代需求清单。保留三类内容：本期交付物边界（交付哪些能力、覆盖哪些用户或场景）、明确不做的内容、外部依赖与接口方。逐条需求描述、详细功能清单和完整WBS移到需求文档与项目计划中。
边界表达建议采用“包含—不包含—依赖”三段式：
- 包含：本期交付的能力清单，按能力而非按需求条目描述，每条注明覆盖的场景。
- 不包含：本期明确排除的能力、场景或用户群，写清排除原因和后续安排。
- 依赖：需要其他团队或系统提供的前置条件，注明接口方和期望时间。
常见遗漏点有三个。一是只写包含不写排除，导致启动后各方对边界理解不一致；二是依赖项只写系统名称，没写对接人和交付时间，风险无人跟踪；三是把“暂不支持”写成排除项却没有后续安排，后续需求重新进入时缺少判断依据。排除项最好附一句“计划在下一期评估”或“由某团队另行承接”，让边界有去向。
范围边界写到能回答“这个需求本期做不做”即可，不必穷举所有可能的需求。立项后出现的新需求，通过变更审批规则处理，这正是授权部分要解决的问题。
授权与决策内容保留哪几项
轻量Charter的授权部分保留三项：项目负责人与最终决策人、变更审批规则、问题升级路径。三项各回答一个问题——谁对结果负责、范围或目标变更由谁批准、跨团队冲突或资源问题找谁裁决。
可以裁剪的内容包括多级会签流程、完整的角色职责矩阵（RACI）、逐项审批权限表。这些内容适合放在组织级项目管理制度中，单份Charter重复一遍既增加维护成本，也容易与实际执行脱节。
| 项目情形 | 授权配置建议 |
|---|---|
| 单一团队、影响范围有限 | 项目负责人即决策人，变更由负责人在周会记录并同步干系人 |
| 跨两个以上团队协作 | 指定一名最终决策人，范围变更需决策人确认，升级路径指向双方共同上级 |
| 涉及合规、资金或对外承诺 | 在最小三项基础上回补审批节点，按组织制度明确哪些变更必须走正式审批 |
变更审批规则要写清触发条件，例如“交付范围增减、成功标准调整、里程碑推迟超过一周”需要审批，日常任务调整不必上报。升级路径写到具体角色而非部门名称，避免出现问题时找不到人。
不同规模项目的Charter编写深度对照
下表按项目规模给出目标、范围、授权三处的编写深度建议。规模划分可按团队人数、交付周期和影响范围综合判断，具体口径由组织自行确定，下表作为参照。
| 项目规模 | 目标 | 范围 | 授权 | 裁剪取舍与理由 |
|---|---|---|---|---|
| 小型（单团队、周期数周） | 一句话成果加一到两条成功标准 | 包含与不包含各列三到五条，依赖简写 | 负责人兼决策人，变更口头确认后记录 | 参与方少、沟通成本低，Charter控制在一页内，重点防止范围悄悄扩大 |
| 中型（两三个团队、周期一到两个季度） | 成果描述加两到三条可量化成功标准，附业务目标关联一句 | 三段式边界写全，依赖注明接口方与时间 | 明确最终决策人，变更审批规则写触发条件，升级路径到角色 | 跨团队协作增多，边界和决策规则是争议高发点，需要写实 |
| 大型（多团队、周期半年以上或影响对外） | 成果与成功标准分阶段表述，保留阶段性验收口径 | 边界按阶段划分，排除项附后续安排，依赖形成清单并指定跟踪人 | 在最小三项基础上回补审批节点，明确变更分级 | 周期长、变量多，需要阶段性对齐机制，但详细需求与WBS仍放在下游文档 |
跨团队依赖多、合规要求高的项目，需要在上述基础上回补内容：依赖清单的跟踪机制、合规相关的验收证据要求、对外承诺的审批记录。回补的原则是只补与立项决策和风险控制直接相关的内容，执行细节仍交给计划文档。
Charter确定后，目标和范围边界需要在实际执行中保持可查。以ONES为例，可以把Charter中的目标与范围条目登记为工作项，把文档状态与变更审批规则对应起来，使范围调整留下记录、决策人确认有据可查。具体承载方式按团队现有工具配置确定。
一份轻量Charter示例
以下示例为演示情景：某中型研发项目，由两个团队协作，计划周期十周，为内部客服系统增加工单自动分类能力。示例展示裁剪后的实际样貌。
目标
- 成果：客服系统上线工单自动分类，新工单进入时自动归入预设的八类问题。
- 成功标准一：分类准确率达到八成五以上，以两周人工抽检结果为准。
- 成功标准二：客服人员手动改分类的比例低于两成。
- 业务关联：支撑本季度客服响应时长的改善目标。
范围
- 包含：八类问题的自动分类、人工改分类入口、分类结果统计报表。
- 不包含：多语言工单分类（下一期评估）、分类模型的自助训练界面（由算法团队另行承接）。
- 依赖：客服系统提供工单创建事件接口，接口方为客服平台团队，需在第四周前就绪；历史工单数据由数据团队在第三周前完成脱敏交付。
授权
- 项目负责人：客服研发团队负责人；最终决策人：客服中心负责人。
- 变更审批：分类类别增减、成功标准调整需决策人确认；里程碑推迟超过一周需上报。
- 升级路径：接口交付延期先由双方团队负责人协商，未解决升级至客服中心负责人。
示例中刻意省略的内容包括：完整的需求列表、模型选型的技术方案、十周的详细排期、测试用例。省略理由是这些内容在立项阶段尚未稳定，且不影响启动决策，分别由需求文档、技术设计文档和项目计划承载。
裁剪后的完成检查
Charter写完后，用以下清单逐项核对，全部通过即可支撑立项；未通过项登记为后续补充事项，注明补充时间和责任人。
- 目标是否包含可验证的成果描述，成功标准能否在项目结束时核对。
- 范围是否同时写了包含项和排除项，排除项是否注明后续安排。
- 外部依赖是否写清接口方、交付内容和期望时间，是否有人跟踪。
- 项目负责人与最终决策人是否明确到具体角色。
- 变更审批规则是否写清触发条件，升级路径是否指向具体角色。
- 关键风险是否列出，每项风险是否有责任人。
- 被裁剪的内容是否登记为后续补充事项，注明由哪份文档承接、何时补充。
- 涉及合规或对外承诺的项目，是否已按组织制度回补相应审批与证据要求。
检查通过后，Charter即可作为立项依据进入执行。执行过程中目标和范围发生变化时，按变更审批规则处理，并同步更新Charter中的对应条目，保持文档与实际一致。
常见问题
项目立项阶段需求还没定清楚，范围章节怎么写才不至于反复改？
范围章节写到能回答“这个需求本期做不做”即可，不必等需求全部明确。具体做法是按能力而非按需求条目描述包含项，每条注明覆盖场景；排除项写清原因和后续安排；依赖项写清接口方和期望时间。立项后出现的新需求走变更审批规则，不需要回头重写整份Charter。
如果需求方向本身还在探索，可以在包含项中写明探索性交付物及其验证方式，把范围边界定在验证目标上，而不是定在具体功能上。
单一团队的小项目，是否可以不写Charter直接开工？
是否编写由团队自行判断。小项目参与方少、沟通成本低，口头对齐也能推进；但范围悄悄扩大、成功标准事后各说各话，是小项目最常见的两类争议。若决定编写，控制在一页以内即可：一句话成果、一到两条成功标准、包含与不包含各列三到五条、负责人兼决策人。若决定不写，建议至少留下目标与范围边界的简短记录，便于后续追溯。
裁剪后的Charter和后续的项目计划如何衔接，避免两份文档脱节？
衔接的关键是分工明确：Charter只承载立项判断所需的信息，项目计划承载排期、资源、WBS和详细需求。可以在Charter末尾登记被裁剪内容的去向，注明由哪份文档承接、何时补充。执行中目标和范围发生变化时，按变更审批规则处理，并同步更新Charter对应条目，使Charter始终反映当前边界，而不是停留在立项当天。
跨团队依赖多或涉及合规要求的项目，需要回补哪些内容？
回补原则是只补与立项决策和风险控制直接相关的内容。跨团队依赖多的项目，需要回补依赖清单的跟踪机制，明确每项依赖的接口方、交付时间和跟踪人；涉及合规、资金或对外承诺的项目，需要按组织制度回补审批节点和验收证据要求，并明确哪些变更必须走正式审批。详细需求、技术方案和完整排期仍放在下游文档，不因回补而把Charter写成全量立项材料。
Charter写完由谁确认，确认后还需要定期维护吗？
确认人通常是Charter中写明的最终决策人，项目负责人负责组织编写和提交。确认后不需要定期全文重写，但目标和范围边界发生变化时应同步更新对应条目，并保留变更记录。完成检查清单可以在每次更新后快速核对一遍，重点看成功标准是否仍可验证、排除项是否仍有效、依赖是否仍有人跟踪。
