研发项目Charter要在立项评审时回答三个问题：为什么做、做到什么程度、做哪些与不做哪些。对应到文档结构，就是立项依据、目标、范围三块内容。三块内容需要相互校验：每条目标都能在范围内找到承载它的交付物，每条范围项都能回溯到一条立项依据。本文按“写什么—按什么顺序写—谁写谁评审—示例—评审前检查”的顺序展开，适用于单个研发项目的立项文档编写。
要点总览（TL;DR）
- Charter要回答三个问题：为什么做（立项依据）、做到什么程度（目标）、做哪些与不做哪些（范围），三块内容需相互校验。
- 立项依据写到可核验的颗粒度：业务问题、需求来源、不做的后果、投入与决策依据，四项缺一都会让评审停留在方向性讨论。
- 目标区分业务目标与交付目标，每条给出度量口径、基线与目标值；基线缺失时先补测基线，不用估计值代替。
- 范围用包含/不包含两栏并列书写，不包含项具体到功能、系统或团队，并单列关键假设与依赖。
- 撰写顺序为立项依据→目标→范围→交叉校验，提交评审前按检查清单逐项核对，全部通过再进入评审会。
Charter里目标、范围、立项依据各写什么
三块内容承担不同的判断任务：立项依据回答“值不值得做”，目标回答“做成什么样算成功”，范围回答“这次做到哪里为止”。写作时先给结论性判断，再用可核验的字段支撑，避免只写方向性描述。
立项依据：写到可核验的颗粒度
立项依据的必备要素包括四项：业务问题（当前存在什么具体问题、影响哪些业务环节）、需求来源（客户反馈、市场变化、内部运营数据、合规要求等，注明来源与时间）、不做的后果（机会成本、风险敞口、竞争影响）、决策与投入依据（为什么现在做、需要投入的资源量级与决策记录）。四项要素中，业务问题和需求来源是事实基础，不做的后果和投入依据是判断依据，缺一项都会让评审停留在“听起来有道理”的层面。
目标：业务目标与交付目标分开写
业务目标描述项目上线后希望改变的业务结果，交付目标描述项目团队在项目周期内必须完成的产出。两类目标都要给出度量口径、基线与目标值。例如业务目标写“订单处理时长从当前的X小时降至Y小时”，交付目标写“完成订单处理链路的改造并在两个业务单元上线”。基线缺失时先补基线测量，再写目标值，否则目标无法在结项时验证。
范围：包含、不包含、边界与依赖
范围用“包含/不包含”两栏并列书写，包含项列出交付物、受影响系统与团队边界，不包含项明确本次不做的功能、不覆盖的系统和不参与的团队。单列关键假设与依赖，例如依赖某系统的接口开放时间、假设某业务规则在项目期内不变。不包含项写得越具体，后续范围蔓延的争议越少。
三块内容的校验关系
写完三块内容后做一次对应检查：每条目标在范围内是否有承载它的交付物；每条范围项能否回溯到一条立项依据；立项依据中的业务问题是否都有目标去回应。无法对应的项，要么补齐缺失的一环，要么删除。
| 字段 | 填写要求 | 合格示例 |
|---|---|---|
| 业务问题 | 描述具体问题、影响环节与影响程度 | 订单人工审核环节平均耗时X小时，高峰期积压明显 |
| 需求来源 | 注明来源类型、提供方与时间 | 某季度客户反馈汇总、运营月度数据报告 |
| 不做的后果 | 说明机会成本或风险 | 积压问题延续，影响续约与新增订单转化 |
| 投入与决策依据 | 资源量级、决策人与决策记录 | 投入若干人月，由业务与财务负责人评审确认 |
| 业务目标 | 度量口径、基线、目标值 | 订单处理时长从X小时降至Y小时 |
| 交付目标 | 可验收的产出与上线范围 | 完成审核链路改造并在两个业务单元上线 |
| 范围包含项 | 交付物、受影响系统、团队边界 | 审核规则配置、审核工作台改造、两个业务单元 |
| 范围不包含项 | 明确排除的功能、系统、团队 | 不覆盖海外业务单元，不改动结算系统 |
| 假设与依赖 | 逐条列出并注明责任方 | 依赖某系统接口在项目中期开放 |
按顺序写Charter的操作步骤
撰写顺序建议为立项依据、目标、范围、交叉校验。每一步以可检查的完成标志收尾，前一步未达标不进入下一步，可以减少后期反复修改。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：形成立项依据初稿 | 客户反馈、运营数据、市场与合规材料、历史决策记录 | 归纳业务问题，标注需求来源与时间，写明不做的后果与投入量级 | 立项依据初稿 | 每个业务问题都有来源支撑，不做的后果有具体描述 |
| 第二步：拆解目标并确定基线 | 立项依据初稿、现有业务指标数据 | 把业务问题转化为业务目标，补充交付目标，逐条写明度量口径、基线与目标值 | 目标清单 | 每条目标都有基线数值和可验证的度量方式 |
| 第三步：划定范围边界 | 目标清单、系统现状、团队分工 | 列出包含项与不包含项，标注受影响系统与团队边界，单列假设与依赖 | 范围清单 | 不包含项具体到功能或系统，依赖项有责任方 |
| 第四步：交叉校验并补齐 | 立项依据、目标清单、范围清单 | 逐条检查目标与范围的对应关系，补齐缺口或删除无依据项 | 校验后的Charter全文 | 每条目标有承载交付物，每条范围项可回溯到立项依据 |
第二步确定基线时，如果现有数据不足以支撑度量，应把“补测基线”本身写进项目的前置任务，而不是用估计值代替。第三步划定范围时，把“本次不做的功能”与“后续版本再做的功能”分开记录，前者进入不包含项，后者可作为后续规划的输入，避免在本次立项中反复争论。
谁写、谁评审、谁拍板：角色与交付物
Charter的撰写与评审涉及四类角色，各自提供不同性质的输入，职责不重叠。项目经理承担组织与一致性维护，业务与财务决策者承担立项结论。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品/需求负责人 | 提供业务问题、需求来源与优先级判断 | 需求来源清单、业务问题描述 |
| 项目经理 | 组织撰写，维护目标与范围的一致性，管理版本 | Charter全文、交叉校验记录、版本记录 |
| 技术负责人 | 评估技术可行性、系统影响与外部依赖 | 可行性评估意见、依赖清单 |
| 业务与财务决策者 | 确认投入量级与立项结论 | 立项决策记录、投入确认意见 |
评审记录与版本留痕归项目经理维护：每次评审的参与人、提出的修改意见、修改后的版本号都应可追溯。立项结论由业务与财务决策者确认后写入决策记录，作为Charter的附件或独立条目保存。目标与范围在评审中被修改时，同步更新交叉校验结果，避免文档内部出现前后不一致。
当Charter需要在多人之间流转评审时，可以把文档、目标条目与评审记录放在同一协作空间中承载。以ONES为例，项目文档可用于存放Charter正文与版本，工作项可承载目标与范围条目并关联评审意见，评审结论与修改记录随文档留痕，便于在立项评审会上逐条核对。具体配置方式按团队现有流程设置。
一份研发项目Charter的填写示例
以下为演示情景，用于说明三块内容的落地写法，不对应任何具体企业事实与数据。
背景设定
某研发团队负责一套内部订单处理系统的迭代。运营数据显示人工审核环节耗时较长，高峰期积压明显，客户反馈中与订单响应速度相关的意见集中出现。团队拟立项改造审核链路。
立项依据段落示例
“订单人工审核环节平均耗时X小时，高峰期积压订单数量明显上升，影响订单响应速度与客户续约意愿（来源：运营月度数据报告、某季度客户反馈汇总）。若本次不启动改造，积压问题将延续至下一业务周期，新增订单转化受到持续影响。建议投入若干人月，在下一业务周期内完成审核链路改造，由业务负责人与财务负责人评审确认投入。”这段写法把问题、来源、不做的后果与投入依据放在同一段内，评审时可以逐项追问。
目标段落示例
业务目标：“订单处理时长从基线X小时降至Y小时，以运营月度统计口径度量。”交付目标：“完成审核规则配置与审核工作台改造，并在两个业务单元上线，上线后连续一个月按新流程运行。”两条目标都带度量口径与验收方式，结项时可对照验证。
范围包含与不包含示例
| 包含项 | 不包含项 |
|---|---|
| 审核规则配置能力 | 海外业务单元的审核流程 |
| 审核工作台改造 | 结算系统的任何改动 |
| 两个业务单元的上线支持 | 移动端审核入口 |
| 与审核相关的运营数据埋点 | 历史订单数据迁移 |
示例中目标与范围的对应关系是：业务目标“处理时长下降”由包含项中的审核规则配置与工作台改造承载；交付目标“两个业务单元上线”对应包含项中的上线支持；不包含项中的海外业务单元与移动端入口，说明本次目标不覆盖这些场景。关键依赖写明“依赖某系统接口在项目中期开放，责任方为该系统维护团队”。
立项评审前的完成检查
提交评审前逐项核对下表，全部通过再进入评审会。任何一项未通过，回到对应章节补齐，不在评审会上临时解释。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 立项依据是否回答了为什么现在做 | 业务问题有来源支撑，不做的后果与投入依据均已写明 | 产品/需求负责人 |
| 目标是否可度量且有基线 | 每条目标有度量口径、基线与目标值，业务目标与交付目标分开 | 项目经理 |
| 范围是否写明不包含项 | 不包含项具体到功能、系统或团队，不只写“其他” | 项目经理 |
| 目标与范围是否逐条对应 | 每条目标有承载交付物，每条范围项可回溯到立项依据 | 项目经理 |
| 关键假设、依赖与风险是否列出 | 逐条列出并注明责任方与影响 | 技术负责人 |
| 评审角色是否已确认并留痕 | 评审参与人、修改意见、版本号可追溯，立项结论有决策记录 | 项目经理 |
检查通过后，Charter即可提交立项评审。评审中若目标或范围发生调整，同步更新交叉校验结果与版本记录，保持文档内部一致，再进入下一轮确认。
常见问题
立项依据里“不做的后果”写不出来，说明什么？
写不出不做的后果，通常说明立项依据还停留在“这件事有价值”的层面，没有回答“为什么现在做”。可以换一个角度追问：如果这个项目推迟一个业务周期，哪些业务指标会继续恶化、哪些风险会继续暴露、哪些机会会流失。如果追问后仍然找不到具体后果，这个项目可能更适合放进后续规划池，而不是进入本次立项评审。
另一种情况是后果确实存在但缺少数据支撑，此时应把相关数据补测列为立项前置任务，在Charter中注明数据缺口与补齐时间，避免用笼统描述代替。
目标已经有基线，但项目周期内业务指标受外部因素影响大，目标值怎么定？
外部因素影响大时，建议把目标拆成两层：一层是项目团队可控的交付目标，例如完成某链路改造并在指定业务单元上线；另一层是业务目标，写明度量口径与目标值，同时注明影响该指标的外部因素与观察方式。这样结项时可以先验证交付目标是否达成，再结合外部因素解释业务目标的实际表现。
如果外部影响足以让业务目标失去验证意义，也可以在Charter中把业务目标写成方向性观察指标，并说明原因，由评审确认后再定稿。
范围不包含项写多少合适？写多了会不会显得项目价值小？
不包含项的作用是划定本次交付的边界，与项目价值大小无关。判断写多少的标准是：评审会上可能被追问“这个做不做”的内容，都应有明确归属。常见需要写进不包含项的有：本次不覆盖的业务单元或地区、不改动的关联系统、不做的终端入口、不迁移的历史数据。
与本次无关、评审也不会追问的内容不必罗列。把“后续版本再做的功能”与“本次不做的功能”分开记录，前者作为后续规划输入，后者进入不包含项，可以减少评审中的反复争论。
Charter评审通过后，目标和范围还能改吗？
可以改，但要留下变更记录。评审通过后的目标或范围调整，建议同步更新三件事：修改后的Charter版本号、交叉校验结果、变更原因与确认人。目标与范围是相互对应的，改动其中一项后如果不重新校验，文档内部容易出现前后不一致，结项时也难以对照验证。
调整幅度较大时，例如业务目标或上线范围发生实质变化，建议重新提交一次评审确认，而不是仅在文档中修改。
小团队没有独立的业务与财务决策者，立项结论由谁确认？
角色可以合并，但确认动作要保留。小团队中业务负责人往往同时承担投入确认的职责，此时在Charter中写明“立项结论由某角色确认”并留下确认记录即可，不必为每个角色单独设岗。关键是立项结论有明确的确认人和确认时间，而不是由撰写者自行判定。
如果团队缺少财务侧判断，可以在立项依据中把投入量级与预期收益写得具体一些，由业务负责人基于这些信息确认，降低后续因投入分歧导致的返工。
