研发项目立项前，需要把业务目标和约束条件确认到可以评审的程度。本文按业务目标、范围与交付、资源与投入、风险与合规四类给出确认清单，并说明每项由谁确认、用什么文档承载，最后提供一份立项确认单模板和完成检查表，帮助你判断是否可以进入立项评审。
要点总览（TL;DR）
- 立项前要确认四类内容：业务目标（问题、用户或场景、指标与目标值、时间窗口、负责人）、范围与交付约束（交付物、排除项、里程碑、验收口径）、资源与投入约束（人力、预算、外部依赖、关键前提）、风险与合规约束（技术可行性、数据与安全、上线运维责任）。
- 业务目标以“可评审”为标准：指标要有基线值、目标值和统计口径，目标负责人要能对业务结果负责并书面确认。
- 范围约束要同时写清做什么和不做什么，验收人应与目标负责人区分；资源盘点以找出缺口为目标，缺口标注补齐责任人和时间。
- 四类信息由业务、产品、技术、财务、合规角色分别确认，汇总到一份立项确认单，在立项评审会前完成签署。
- 提交评审前逐项核对，区分阻断项与跟踪项：预算未批准、合规未通过、关键角色无着落属于阻断项。
立项前先确认哪几项业务目标
业务目标的确认标准是“可评审”：一个没有指标、没有目标值、没有时间窗口的目标，在立项评审会上无法被判断是否值得投入。把模糊想法转成可评审的目标，需要确认以下六项内容，缺一项就视为未完成。
| 确认项 | 要回答的问题 | 判断标准 |
|---|---|---|
| 业务问题 | 项目要解决什么具体问题？问题目前造成了什么损失或低效？ | 能用一两句话描述问题，并指出受影响的业务环节 |
| 目标用户或场景 | 谁使用、在什么场景下使用？ | 明确到角色或业务场景，而非“所有用户” |
| 成功指标 | 用什么指标衡量目标达成？ | 指标可采集、可对比，避免“体验更好”这类无法验证的表述 |
| 目标值与衡量口径 | 目标值是多少？从什么基线出发？统计周期和统计范围是什么？ | 写明基线值、目标值、统计口径，三者齐全 |
| 时间窗口与阶段目标 | 目标在多长时间内达成？中间有哪些阶段目标？ | 给出整体时间窗口，并把阶段目标与里程碑对应 |
| 目标负责人 | 谁对目标达成负责？谁确认目标？ | 指定一名业务负责人，确认方式为书面确认或评审会记录 |
确认时常见的偏差是把“上线某个功能”当成业务目标。功能上线是交付结果，业务目标应描述上线后业务指标的变化，例如某类订单处理时长从多少降到多少。指标口径要提前写清，否则立项后各方对同一指标的理解不一致，验收时容易产生争议。目标负责人需要是能对业务结果负责的角色，产品负责人可以协助定义指标，业务负责人对目标值确认并签字。
必须提前锁定的范围与交付约束
范围约束要同时写清“做什么”和“不做什么”。只写交付物清单，立项后各方对边界的理解会不断扩张；明确排除项，才能在有人提出新增需求时快速判断是否属于本期范围。
确认范围与交付约束时，按以下四项逐一落表：
- 必须交付的成果：列出本期必须产出的交付物，每项写明形态（如可运行的系统、接口文档、上线报告）和完成标志。
- 明确不做的部分：把评审中讨论过但决定不纳入本期的需求写成排除项，注明后续处理方式（延后、另立项目或不做）。
- 关键里程碑与依赖关系：标出每个里程碑的完成时间和前置依赖，区分项目内部依赖与外部依赖，外部依赖要写明对方交付时间和责任人。
- 验收标准与验收人：每个交付物对应可核验的验收条件，并指定验收人。验收人应与目标负责人区分，避免自验自收。
范围变更的提出与确认方式也要在立项前约定：谁可以提出变更、变更由谁评估影响、达到什么条件需要重新评审。把这些规则写进确认单，立项后的范围调整就有据可依，而不是每次临时协商。
资源、预算与外部依赖怎么核清
资源约束的核对目标是找出缺口，而不是证明资源充足。按人力、预算、外部依赖、关键前提四类逐项盘点，每一项都标注“已确认”或“有缺口”，有缺口的写明补齐责任人和补齐时间。
| 类别 | 确认内容 | 输出 |
|---|---|---|
| 人力投入 | 各角色投入人数与投入比例，关键角色是否到位 | 角色清单与缺口说明 |
| 预算项 | 人力成本、采购、外部服务等预算项及金额，审批口径与审批人 | 预算明细与审批状态 |
| 外部依赖 | 供应商、合作方、平台方的交付内容、时间承诺与违约处理 | 依赖清单与对方责任人 |
| 关键前提 | 设备、测试环境、数据获取、账号权限等启动前提是否具备 | 前提条件清单与就绪状态 |
人力盘点要关注关键角色的缺口，例如架构设计或安全评审角色只有兼职投入，这类缺口在立项阶段就要暴露。预算确认要区分“已批准”和“待批准”，待批准项作为立项条件写入确认单。外部依赖要拿到对方的时间承诺，口头承诺不足以支撑里程碑排期。数据前提尤其容易被忽略：训练数据、历史业务数据或测试数据的获取权限和合规审批，往往决定项目能否按计划启动。
风险与合规约束的确认要点
风险确认的目的是形成可跟踪的风险项，而不是在立项材料里罗列担忧。每项风险要写明描述、等级、应对方向和责任人，等级可按发生概率与影响程度组合判断。
- 技术可行性：关键技术方案是否经过验证？是否存在尚未验证的核心假设？对未验证部分，写明验证方式和验证时间点，作为立项后的前置任务。
- 法规、数据与安全合规：项目涉及的数据类型是否允许采集和使用？是否需要安全评审或合规审批？审批周期是否影响里程碑？
- 上线与运维责任：上线由谁执行、上线后的运维由哪个团队承接、故障响应时限如何约定。研发团队交付后无人承接运维，是立项阶段就应明确的责任边界。
- 风险等级与责任人：每项风险指定一名责任人，负责跟踪应对措施的落实，并在立项评审时说明应对方向。
合规类约束要给出结论性判断：需要审批的，写明审批事项和预计周期；确认无需审批的，也记录判断依据和判断人。这样在评审时，合规问题有明确结论，不会留到开发中途才发现阻塞。
角色分工与立项确认单的交付物
四类信息由不同角色确认，最终汇总到一份立项确认单。分工不清会导致同一项信息被重复确认或无人确认，建议按下表明确责任。
| 角色 | 负责确认的内容 | 在确认单上的签署项 |
|---|---|---|
| 业务负责人 | 业务问题、目标用户、成功指标与目标值、时间窗口 | 目标与指标确认 |
| 产品负责人 | 范围边界、交付物清单、排除项、验收标准 | 范围与验收确认 |
| 技术负责人 | 技术可行性、关键技术风险、环境与数据前提 | 技术方案与风险确认 |
| 财务角色 | 预算项、金额与审批口径 | 预算确认 |
| 合规或安全角色 | 数据使用、安全评审、合规审批结论 | 合规结论确认 |
立项确认单建议包含以下字段：项目名称与一句话描述、业务问题、目标用户或场景、成功指标（含基线值、目标值、口径）、时间窗口与阶段目标、交付物清单、排除项、里程碑与依赖、验收标准与验收人、人力投入与缺口、预算明细与审批状态、外部依赖、关键前提、风险清单（含等级与责任人）、范围变更规则、各角色签署栏。每个字段标注填写责任人，避免汇总时互相等待。
确认单的评审与签署节点安排在立项评审会之前：各角色先完成本领域确认并签署，汇总人检查字段完整性，再提交评审。信息不全时的处理方式是标注缺口、写明补齐责任人和补齐时间，由评审会决定缺口是否构成阻断。承载这份确认单时，可以用文档协作工具集中管理：ONES Wiki 支持页面组关联项目，需求与文档互相对应，文档可嵌入任务进度和报表，评审时能直接看到目标指标与任务进展的对应关系；其版本记录支持随时查看与回滚，多角色读写权限可按分工配置，适合把立项确认单、指标口径和风险清单放在同一处维护，并与项目任务保持关联。
一个研发项目的立项确认示例
以下为演示情景，用于说明确认单的填写过程，不代表真实项目数据。
项目背景：某业务系统需要支持新的对账流程，现有流程依赖人工核对，处理周期长。项目组在立项前完成如下确认。
| 确认项 | 填写内容 |
|---|---|
| 业务问题 | 对账依赖人工逐笔核对，月末集中处理压力大，差错需事后追溯 |
| 目标用户与场景 | 财务对账岗，每日对账与月末结账两个场景 |
| 成功指标 | 单日对账处理时长；对账差错率。基线值由财务提供近三个月均值，目标值与统计口径在确认单中写明 |
| 时间窗口 | 整体窗口与阶段目标对应两个里程碑：流程上线、月末结账首次全量使用 |
| 交付物与排除项 | 交付：对账流程、操作手册、上线报告。排除：历史数据批量迁移、移动端审批 |
| 验收标准与验收人 | 财务对账岗按操作手册完成一次完整对账；验收人为财务负责人 |
| 资源与依赖 | 后端与测试角色各一名，已确认；历史数据接口依赖数据平台团队，对方承诺时间写入依赖清单；测试环境待申请，列为待补齐项 |
| 风险项 | 历史数据质量不确定，等级中，责任人为技术负责人，应对方向为先做数据抽样验证；数据使用范围需合规确认，责任人合规角色 |
汇总后的立项结论是：业务目标与范围已确认，预算已批准，测试环境和数据抽样验证为待补齐项，不构成阻断，允许进入立项评审，补齐项在评审会上作为跟踪事项记录。这个示例说明，确认单的价值在于把“大致清楚”变成“逐项有结论、有责任人、有补齐条件”。
立项前的完成检查
提交立项评审前，用下表逐项核对。检查项全部通过，且无未处理的阻断项，才具备进入评审的条件。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 业务目标完整性 | 业务问题、目标用户、指标、目标值与口径、时间窗口、负责人六项齐全 | 退回业务负责人补充，指标口径需书面确认 |
| 范围与交付约束 | 交付物、排除项、里程碑、验收标准与验收人全部落表 | 补充排除项和验收人，缺失验收人的交付物不得提交评审 |
| 资源与投入 | 人力、预算、外部依赖、关键前提四类均有结论，缺口有责任人和补齐时间 | 预算未批准或关键角色未到位，列为阻断项 |
| 风险与合规 | 风险项有等级、应对方向和责任人；合规事项有结论性判断 | 合规结论缺失列为阻断项，技术风险未验证列为跟踪项 |
| 签署完整性 | 各角色签署栏已填写，汇总人完成完整性检查 | 缺签字段退回对应角色确认 |
阻断项指不解决就不能进入评审的事项，典型如预算未批准、合规审批未通过、关键角色无着落；跟踪项指可以在评审会上记录、立项后限期补齐的事项，如测试环境申请、数据抽样验证。区分这两类，能避免把所有缺口都当成阻断而拖延立项，也避免把真正的阻断项带入执行阶段。检查通过后，立项确认单连同风险清单提交评审，评审结论与补齐事项一并归档，作为后续阶段核对的依据。
常见问题
立项确认单和项目计划有什么区别，能不能合并成一份文档？
两者回答的问题不同。立项确认单回答“这个项目为什么值得做、边界在哪里、前提是否具备”，是进入评审前的判断依据；项目计划回答“立项后怎么执行”，包含任务分解、排期和资源分配。可以放在同一文档空间里维护，但建议立项确认单在评审前定稿并签署，项目计划在立项通过后展开，避免执行细节反复修改导致目标与约束的结论被稀释。
业务负责人和产品负责人对目标值有分歧时，立项前怎么处理？
分歧通常来自指标口径或基线数据不一致。处理方式是先把口径写清楚：统计范围、统计周期、数据来源、基线取值方式，由双方共同确认口径后再讨论目标值。如果口径一致仍有分歧，由业务负责人对目标值做最终确认，因为目标值对应的是业务结果责任；产品负责人保留对指标可采集性和实现可行性的意见，记录在确认单备注中。分歧未解决时，不建议带着模糊目标进入评审。
外部依赖方只给口头承诺，能不能先立项再补书面确认？
要看这项依赖是否影响关键里程碑。如果依赖方交付时间直接决定里程碑排期，口头承诺不足以支撑计划，应列为待补齐项，并在评审时说明补齐时间；若该依赖处于关键路径且无法取得书面时间承诺，建议作为阻断项处理。非关键路径上的依赖可以先记录为跟踪项，立项后限期补齐。无论哪种情况，依赖清单里都要写明对方责任人和约定时间。
合规审批周期较长，立项评审要不要等审批完成？
不必一律等待，但要区分审批事项的性质。涉及数据采集和使用范围的审批，如果结论可能改变项目范围或技术方案，应在评审前取得结论性判断或明确的审批时间表；仅涉及上线前的手续性审批，可以作为跟踪项写入确认单，约定完成节点。评审材料中要写明审批事项、预计周期和责任人，避免开发中途才发现阻塞。
立项确认单用什么工具承载比较合适？
关键是让多角色能协同填写、版本可追溯，并与项目任务保持关联。ONES Wiki 的页面组可关联项目，需求与文档互相对应，文档支持嵌入任务进度和报表，评审时能直接对照目标指标与任务进展；版本记录支持查看与回滚，读写权限可按角色配置，适合把立项确认单、指标口径和风险清单放在同一处维护。
