研发项目Charter是立项阶段把“为什么做、做到什么程度、谁来决定”写清楚的一份启动文件。本文提供一张可直接复制填写的空白表格，覆盖背景与问题、目标与成功标准、范围边界、交付物与里程碑、角色与决策权、资源与预算、风险与假设、验收与退出条件八类字段，并配套字段说明、必填选填对照和一份完整填写示例。适用范围为单个研发项目的立项判断，不涉及多项目之间的优先级排序。
要点总览（TL;DR）
- 研发项目Charter模板以一张空白表格为核心，覆盖背景与问题、目标与成功标准、范围边界、交付物与里程碑、角色与决策权、资源与预算、风险与假设、验收与退出条件八类字段。
- 目标字段写成含指标、基线与目标值的可验证结果，范围字段同时写纳入与排除，里程碑写交付物与判定点，角色写决策事项，风险写触发条件与应对。
- 立项评审必须齐备的字段包括背景与问题、目标与成功标准、范围边界、关键交付物、项目负责人与决策人、验收条件；详细预算拆分、完整风险登记、外部依赖清单可按项目规模裁剪。
- 完整填写示例展示目标、成功标准与验收方式指向同一组指标，排除范围与依赖清单分别对应风险与退出条件，可照此结构替换为自身项目内容。
- 模板按项目类型增删字段，评审后回填实际结果，更新版本与变更记录，定期清理失效字段，保持长期可用。
研发项目Charter空白模板（可直接复制）
下表为空白模板，复制到文档或表格工具后逐行填写。填写区保持空白，填写提示列说明该行应写成的形态；不确定的内容先标注“待确认”并写明确认人和时间，避免用模糊表述占位。
| 区块 | 字段名 | 填写区 | 填写提示 |
|---|---|---|---|
| 项目基本信息 | 项目名称 | 使用团队内部可检索的正式名称，避免代号与简称混用 | |
| 项目基本信息 | Charter版本与日期 | 写版本号与定稿日期，后续变更在此累加 | |
| 项目基本信息 | 发起人与发起部门 | 写提出该项目并对立项负责的人 | |
| 背景与问题 | 业务背景 | 说明当前业务场景与触发立项的事件 | |
| 背景与问题 | 待解决问题 | 写具体问题及其影响对象、影响程度 | |
| 背景与问题 | 不做的后果 | 说明维持现状的代价，作为立项必要性的依据 | |
| 目标与成功标准 | 项目目标 | 写成可验证的结果，包含指标、基线值与目标值 | |
| 目标与成功标准 | 成功标准 | 列出验收时用来判断目标达成的具体证据 | |
| 目标与成功标准 | 非目标 | 写明本项目不追求的结果，防止目标被扩大解释 | |
| 范围边界 | 纳入范围 | 列出本项目负责交付的对象、模块或流程 | |
| 范围边界 | 排除范围 | 列出明确不做的事项及归属方 | |
| 交付物与里程碑 | 关键交付物 | 逐项列出可交付成果及其形态 | |
| 交付物与里程碑 | 里程碑计划 | 每个里程碑写交付物、判定点与目标时间 | |
| 角色与决策权 | 项目负责人 | 写对交付结果负责的人及其职责边界 | |
| 角色与决策权 | 决策人与决策事项 | 写谁对范围变更、资源追加、终止等项目事项拍板 | |
| 角色与决策权 | 核心成员与分工 | 按职能列出参与方及其承担的工作 | |
| 资源与预算 | 人力投入 | 写角色、人数与投入周期 | |
| 资源与预算 | 预算与外部采购 | 写预算额度、用途与审批口径 | |
| 资源与预算 | 依赖的系统与团队 | 列出需要配合的内部系统、外部供应商或协作团队 | |
| 风险与假设 | 主要风险 | 每条写触发条件、影响与应对动作 | |
| 风险与假设 | 关键假设 | 写立项成立所依赖的前提，以及假设不成立时的处理 | |
| 验收与退出条件 | 验收方式 | 写验收由谁、依据什么材料、按什么标准判定 | |
| 验收与退出条件 | 退出与终止条件 | 写出现哪些情况时暂停、缩减或终止项目 |
表格结构按“先说明为什么做，再说明做成什么样，最后说明怎么判定”的顺序排列。填写时从上到下推进，遇到上游字段写不实的情况，先回到上一区块补齐，再继续往下写。
每个字段填什么：Charter字段说明
字段说明解决的是“这一行应该写成什么形态”。同一份Charter在评审中被质疑，多数源于字段写成了动作描述或岗位名称，缺少可核对的判断依据。以下按区块说明写法与常见错误。
背景、目标与成功标准
- 业务背景与待解决问题：写清问题发生在哪个业务环节、影响哪些用户或流程、目前造成的具体损失。常见错误是把背景写成产品愿景，读不出要解决的具体问题。
- 项目目标：写成可验证结果，包含指标名称、当前基线、目标值和统计口径。例如“将订单接口平均响应时间从800毫秒降至300毫秒以内”，而非“优化接口性能”。常见错误是目标只有方向没有数值，验收时无法判断是否达成。
- 成功标准：列出验收时能拿出的证据，如测试报告、监控数据、用户验收记录。成功标准与目标一一对应，目标有几条，标准就应有几条。
- 非目标：写明本项目明确不追求的结果，用于回应评审中“顺便把这个也做了”的诉求。
范围、交付物与里程碑
- 纳入范围与排除范围：两项必须同时填写。只写纳入范围，边界会在执行中被不断外扩；排除范围要写清归属方，例如“移动端适配由客户端团队负责，不在本项目范围”。
- 关键交付物：逐项列出成果形态，如服务接口、数据迁移脚本、上线文档。交付物是里程碑判定的对象，写不清交付物，里程碑就无法判定。
- 里程碑计划：每个里程碑写三件事——到点交付什么、用什么判定完成、目标时间。常见错误是把里程碑写成“完成开发”“进入测试”这类阶段名称，缺少可判定的交付物。
角色、资源、风险与验收
- 角色与决策权：除岗位名称外，必须写清决策事项。例如“范围变更由项目负责人提出、技术总监审批”，而不是只写“技术总监”。常见错误是角色表列了一串人名，却没人对变更和终止负责。
- 资源与预算：人力写角色、人数与投入周期；预算写额度、用途与审批口径；外部依赖写清对接方与期望配合时间。
- 风险与假设：每条风险写触发条件、影响和应对动作，例如“若第三方接口在联调前未提供测试环境，则联调顺延，应对为提前两周发起环境申请”。假设写立项成立所依赖的前提，并注明假设不成立时的处理方式。
- 验收与退出条件：验收写判定人、依据材料和标准；退出条件写触发暂停、缩减或终止的具体情形，与风险字段中的触发条件保持对应。
必填与选填：按项目阶段取舍字段
立项评审需要一份能支撑决策的最小完整集，其余字段可按项目规模和阶段裁剪。裁剪的原则是：影响“做不做、做到哪、谁负责、怎么算完成”的字段必须齐备，影响“怎么排布资源”的细节可以后补。
| 字段 | 属性 | 说明 |
|---|---|---|
| 背景与问题 | 必填 | 立项必要性的直接依据 |
| 目标与成功标准 | 必填 | 决定验收口径，缺失则无法判定完成 |
| 范围边界（纳入与排除） | 必填 | 控制执行期范围蔓延 |
| 关键交付物 | 必填 | 里程碑与验收的共同对象 |
| 项目负责人与决策人 | 必填 | 明确结果责任与变更审批权 |
| 验收条件 | 必填 | 与成功标准对应，评审时一并确认 |
| 详细预算拆分 | 选填 | 小项目可只写总额与用途，按财务要求补充明细 |
| 完整风险登记 | 选填 | 立项阶段写前三条主要风险即可，执行期再扩充 |
| 外部依赖清单 | 选填 | 依赖较少时可并入资源区块简述 |
小项目可进一步压缩：里程碑合并为两到三个关键判定点，角色表只保留负责人、决策人和核心执行角色，风险保留影响交付的前两条。预研类项目的目标允许写成“验证某技术路线在给定条件下的可行性”，但成功标准仍需给出可判定的结论形式，例如验证报告需回答的具体问题清单。涉及跨部门资源或外部采购的项目，预算拆分与依赖清单应转为必填，因为这两项直接影响审批链条。
完整填写示例：一个研发项目Charter
以下为演示情景，用于展示字段之间的对应关系，不代表任何真实项目。示例项目为“订单服务性能改造”，可按相同结构替换为自身项目内容。
| 区块 | 字段名 | 填写内容 |
|---|---|---|
| 项目基本信息 | 项目名称 | 订单服务性能改造（2025年第二季度） |
| 项目基本信息 | Charter版本与日期 | V1.0，立项评审前定稿 |
| 项目基本信息 | 发起人与发起部门 | 交易平台部负责人 |
| 背景与问题 | 业务背景 | 大促期间订单创建请求量达到日常五倍，现有服务出现排队 |
| 背景与问题 | 待解决问题 | 订单创建接口平均响应时间800毫秒，高峰期超时率约3%，影响下单转化 |
| 背景与问题 | 不做的后果 | 下一次大促超时率预计继续上升，客服工单与退款纠纷同步增加 |
| 目标与成功标准 | 项目目标 | 订单创建接口平均响应时间降至300毫秒以内，高峰期超时率降至0.5%以下 |
| 目标与成功标准 | 成功标准 | 压测报告显示五倍日常流量下指标达标；上线后连续两周监控数据达标 |
| 目标与成功标准 | 非目标 | 不重构订单数据模型，不调整下单业务流程 |
| 范围边界 | 纳入范围 | 订单创建链路、库存校验调用、订单写入数据库的异步化改造 |
| 范围边界 | 排除范围 | 支付链路改造由支付团队负责；移动端展示优化不在本项目范围 |
| 交付物与里程碑 | 关键交付物 | 改造后的订单服务、压测报告、上线方案与回滚预案 |
| 交付物与里程碑 | 里程碑计划 | M1：完成链路梳理与方案评审，判定点为方案评审通过；M2：完成改造并通过压测，判定点为压测报告达标；M3：灰度上线并稳定运行两周，判定点为监控数据达标 |
| 角色与决策权 | 项目负责人 | 订单服务组技术负责人，对交付结果与进度负责 |
| 角色与决策权 | 决策人与决策事项 | 范围变更由项目负责人提出、交易平台部负责人审批；终止决策由技术委员会做出 |
| 角色与决策权 | 核心成员与分工 | 后端两人负责服务改造，测试一人负责压测，运维一人负责灰度与监控 |
| 资源与预算 | 人力投入 | 后端两人、测试一人、运维一人，投入周期为一个季度 |
| 资源与预算 | 预算与外部采购 | 压测环境扩容费用按实际用量申请，无外部采购 |
| 资源与预算 | 依赖的系统与团队 | 依赖库存服务提供批量校验接口，需在M2前完成联调 |
| 风险与假设 | 主要风险 | 风险一：库存服务接口改造延期，触发条件为联调前两周未提供测试环境，应对为提前发起环境申请并准备降级方案；风险二：压测环境与生产环境差异导致数据失真，应对为压测前校准环境配置 |
| 风险与假设 | 关键假设 | 假设大促流量峰值不超过日常五倍；若超出，则按预案限流并重新评估目标值 |
| 验收与退出条件 | 验收方式 | 由交易平台部负责人依据压测报告与两周监控数据验收 |
| 验收与退出条件 | 退出与终止条件 | 若库存服务改造无法在M2前完成，则缩减范围为订单写入异步化单项；若压测两轮均未达标且方案评审确认无可行路径，则终止项目 |
示例中目标值与成功标准、验收方式三处指向同一组指标；排除范围中的支付链路与依赖清单中的库存服务分别对应风险与退出条件，形成前后一致的约束链。填写自己的项目时，可逐行对照检查：每个目标是否都有对应的成功标准和验收方式，每条主要风险是否都有触发条件与应对动作。
Charter定稿后，目标、里程碑与验收条件需要在项目空间中持续被引用。使用ONES时，可在ONES Wiki中通过页面模板库一键创建制式化文档，把Charter作为项目文档沉淀，并借助页面版本记录保留每次修订与回滚；文档可关联项目任务，页面组关联项目后，需求与文档互相对应，文档中还能嵌入任务进度与报表，便于评审后对照实际进展回填结果。
模板的调整与维护方法
模板的价值在于长期可用。首次填写完成后，团队应按项目类型做小幅改造，并把评审与执行中的实际结果回填到模板中，形成可对照的记录。
- 按项目类型增删字段：功能迭代类项目强化范围边界与交付物；预研类项目强化关键假设与验证结论形式；平台改造类项目强化依赖清单与退出条件。增删以“是否影响立项判断”为准，不影响判断的字段移入选填区。
- 评审后回填实际结果：立项评审通过后，在Charter末尾追加评审结论与调整项；项目结束后回填目标实际值、里程碑实际达成情况与风险实际发生情况，形成计划与结果的对照，供下一个项目参考。
- 版本与变更记录：每次修改Charter都更新版本号与日期，并在变更记录中写明修改字段、修改原因与确认人。范围、目标、验收条件的变更单独标注，便于追溯。
- 定期清理失效字段：每季度或每完成若干项目后检查一次模板，删除长期空置的字段，合并重复字段，把反复出现的填写错误补充进填写提示列。
维护动作本身也需要留痕。把模板作为团队共享文档管理，保留历史版本，新成员从最新版本复制填写；模板变更时同步通知常用该模板的项目负责人，避免新旧版本混用导致评审口径不一致。
常见问题
Charter写完后，目标或范围在执行中发生变化怎么办？
范围、目标、验收条件的变更应在Charter中单独标注，更新版本号与日期，并写明修改字段、修改原因与确认人。变更前先确认决策人：模板中“决策人与决策事项”一行应已写明谁对范围变更、资源追加、终止拍板，按该约定提交审批，避免执行中口头调整后无人追溯。
若变更涉及验收口径，成功标准与验收方式需同步修改，保持三处指向同一组指标。
预研类项目目标难以量化，Charter怎么填？
预研类项目的目标可以写成“验证某技术路线在给定条件下的可行性”，但成功标准仍需给出可判定的结论形式，例如验证报告需要回答的具体问题清单、需要对比的方案数量与判定依据。关键假设一栏要写清立项成立所依赖的前提，以及假设不成立时的处理方式，避免项目在无法得出结论时无限延期。
小团队没有专职项目经理，Charter的角色字段怎么填？
角色字段的核心是写清决策事项，岗位名称可以合并。小团队可由同一人兼任项目负责人与决策人，但需在Charter中写明其承担的两类职责：对交付结果负责，以及对范围变更、资源追加、终止做出决定。核心成员按实际参与职能列出，人数少时可一人对应多项分工，仍需写清各自承担的工作。
Charter定稿后放在哪里，才能被后续评审和验收持续引用？
Charter需要作为项目文档沉淀，而不是停留在个人电脑里。使用ONES时，可在ONES Wiki中通过页面模板库一键创建制式化文档，把Charter作为项目文档管理，并借助页面版本记录保留每次修订与回滚；文档可关联项目任务，页面组关联项目后需求与文档互相对应，文档中还能嵌入任务进度与报表，便于评审后对照实际进展回填结果。
模板用了一段时间后字段越来越多，如何判断哪些该删？
以“是否影响立项判断”为准：影响做不做、做到哪、谁负责、怎么算完成的字段保留在必填区，其余移入选填区或删除。每季度或每完成若干项目后检查一次模板，删除长期空置的字段，合并重复字段，把反复出现的填写错误补充进填写提示列。模板变更时同步通知常用该模板的项目负责人，避免新旧版本混用导致评审口径不一致。
