研发资源需求澄清清单用于在需求进入容量评估前，把“需要什么人、投入多少、何时交付、依据是什么”逐项问清。清单围绕可用人力供需展开，至少覆盖需求来源与优先级、交付约束、技能与角色要求、投入估算与证据四类信息，每项都要能判断是否已澄清，并指定负责人和确认时点。未确认的关键项应标为阻断项，避免带着模糊假设进入资源承诺。
要点总览（TL;DR）
- 清单在需求进入容量评估或立项评审前使用，只处理可用人力供需，组合承接取舍与具体排期不在范围内。
- 核心检查项分三段：需求来源与优先级、交付约束与范围、技能与投入估算，每项配通过标准、证据、负责人和检查时点。
- 每项结论分“已澄清、部分澄清、未澄清”三档，已澄清需附可留存证据，部分澄清需列补问计划。
- 范围边界、关键技能、交付时间、优先级依据四类设为阻断项，未澄清前不进入容量评估。
- 证据按需求编号与需求记录同处存放，清单关闭后交接给容量评估或排期负责人。
谁在什么时点使用这份澄清清单
这份清单服务于一个明确动作：在需求进入容量评估或立项评审之前，把资源相关前提确认到可核对的程度。它不承担排期和分配决策，只负责把输入信息整理清楚，让后续评估有据可依。
| 角色 | 在清单中的职责 | 介入时点 |
|---|---|---|
| 需求提出方 | 说明需求来源、目标、优先级依据和期望时间，提供业务侧证据 | 清单启动时填写，澄清过程中补充 |
| 研发负责人 | 确认范围边界、技能要求、估算口径和承接可行性 | 需求信息初步齐全后逐项确认 |
| 资源或项目管理人员 | 组织澄清、汇总记录、复核证据完整性、标记阻断项 | 全程，重点在清单关闭前复核 |
触发时点建议统一为：需求进入容量评估队列或立项评审议程之前。清单产出是一份可逐项确认的需求澄清记录，包含检查项、结论、证据和负责人。需要说明边界：组合层面的项目承接取舍、具体人员排期与资源分配执行不在本清单范围内，这些动作发生在澄清完成之后，由相应流程处理。
第一阶段：需求来源与优先级检查项
这一阶段回答“需求从哪来、为什么现在做、相对谁优先”。来源不清或优先级无依据的需求，即使技能和工期写得再细，也无法判断是否值得投入人力。
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 需求提出方与业务归属 | 明确到具体部门或业务负责人，能直接联系确认 | 需求单、邮件或评审记录 | 需求提出方 | 清单启动时 |
| 需求对应的目标或问题描述 | 说明要达成的业务目标或要解决的具体问题，可观察或可衡量 | 目标说明、问题记录 | 需求提出方 | 清单启动时 |
| 需求类型 | 标注为新增、变更、缺陷修复、合规或技术债中的一类 | 需求单字段 | 需求提出方 | 清单启动时 |
| 优先级依据与排序结论 | 给出排序理由（如业务影响、合规期限、依赖关系），并说明相对哪些需求排序 | 优先级评审记录 | 需求提出方与研发负责人 | 进入评估前 |
| 替代方案或可延后选项 | 说明是否已有替代做法，或最晚可延后到什么时点 | 方案说明、会议纪要 | 需求提出方 | 进入评估前 |
优先级一项最容易写成“高”或“紧急”而缺少依据。可操作的写法是记录排序时比较的对象和理由，例如“相对某合规需求排后，因监管期限在下一季度”。这样在容量不足时，取舍有据可查。
第二阶段：交付约束与范围检查项
交付约束决定资源估算的前提。时间、范围、质量门槛和外部依赖任何一项模糊，估算结果都会失真。
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 期望交付时间与关键里程碑 | 给出目标日期及至少一个中间里程碑，说明日期来源（合同、活动、合规期限等） | 项目计划、合同或业务通知 | 需求提出方 | 进入评估前 |
| 范围边界 | 列出包含项，并明确写出排除项 | 范围说明文档 | 需求提出方与研发负责人 | 进入评估前 |
| 质量门槛与验收方式 | 说明验收标准、测试要求和谁参与验收 | 验收标准文档 | 研发负责人 | 进入评估前 |
| 外部依赖 | 列明第三方接口、采购、环境准备或合规审批，并标注各自就绪时间 | 依赖清单、对接记录 | 需求提出方与研发负责人 | 进入评估前 |
| 变更处理方式 | 约定变更触发条件和处理路径，例如范围扩大多少需重新澄清 | 变更约定记录 | 资源或项目管理人员 | 清单关闭前 |
范围边界建议用“包含／排除”两列对照书写，排除项写得越具体，后续争议越少。外部依赖要标注就绪时间而非仅列名称，因为依赖晚到会直接改变人力投入曲线。
第三阶段：技能、角色与投入估算检查项
这一阶段把需求翻译成可核对的角色与技能要求，并给出估算口径。估算没有口径和依据，就无法与团队实际可用人力比对。
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 所需角色与技能清单 | 按角色列出技能要求，区分必备与可培养 | 技能清单 | 研发负责人 | 进入评估前 |
| 关键技能稀缺程度与可替代性 | 标注哪些技能在团队内稀缺，是否有人可替代或需外部支持 | 团队技能盘点记录 | 研发负责人 | 进入评估前 |
| 投入估算口径 | 统一使用人天、人月或故事点中的一种，并说明换算关系 | 估算表 | 研发负责人 | 进入评估前 |
| 估算依据与历史参考 | 引用类似需求的实际投入数据或分解到任务级估算 | 历史项目数据、估算记录 | 研发负责人 | 进入评估前 |
| 峰值投入时段与持续时长 | 说明人力需求最集中的时间段及持续多久 | 投入曲线或阶段计划 | 研发负责人 | 进入评估前 |
| 承接团队可行性确认 | 承接团队负责人确认技能匹配和时间窗口可行 | 确认记录 | 研发负责人 | 清单关闭前 |
估算口径要在清单里固定下来，同一批需求用同一种单位，便于横向比较。峰值投入时段尤其值得单独记录：两个需求总量相同，但峰值重叠时对可用人力的压力完全不同。
通过标准：每项如何判定已澄清
统一判定口径是清单可复核的前提。建议把每项结论分为三档，并规定各档对应的动作。
| 结论 | 判定条件 | 后续动作 |
|---|---|---|
| 已澄清 | 通过标准全部满足，且附有指定形式的证据 | 记录结论，进入下一阶段或容量评估 |
| 部分澄清 | 信息方向明确但缺少证据，或存在待确认的细节 | 列出补问事项、责任人和补充期限，到期复核 |
| 未澄清 | 关键信息缺失，或各方说法不一致且未达成一致 | 标记为阻断项，暂停进入容量评估 |
证据形式限定为可留存的材料：需求文档、评审记录、估算表或书面确认消息。口头共识可以作为过程信息，判定“已澄清”仍需落到上述形式之一。每项设置复核人和复核时点，复核人建议由未直接填写该项的人担任，以减少自证。
证据留存与负责人分工
清单要可追溯，就要明确每类检查项由谁提供证据、由谁复核、存放在哪里。
| 检查项类别 | 证据提供方 | 复核方 | 证据形式 |
|---|---|---|---|
| 需求来源、目标、优先级 | 需求提出方 | 资源或项目管理人员 | 需求单、优先级评审记录 |
| 范围、质量门槛、技能要求 | 研发负责人 | 资源或项目管理人员 | 范围说明、验收标准、技能清单 |
| 投入估算与依据 | 研发负责人 | 资源或项目管理人员 | 估算表、历史数据引用 |
| 外部依赖与就绪时间 | 需求提出方与研发负责人 | 资源或项目管理人员 | 依赖清单、对接记录 |
证据存放位置建议与需求记录放在同一处，按需求编号关联，并保留版本信息，便于后续评估引用澄清时的原始结论。清单归档后，在容量评估、排期讨论和变更评审中作为输入引用，避免重复澄清同一问题。
在工具层面，澄清结果需要与需求记录、评审状态和后续资源视图衔接。ONES 支持通过工作数量和工时规模了解成员排期，并可按筛选与分组查看成员在不同项目的投入比重；资源和工时管理解决方案提供资源规划视图，便于按业务优先级安排团队资源，也可查看项目和团队的资源利用率及负荷度。把澄清清单中的角色、估算和时点记录到工作项与文档中，可以让后续容量评估直接引用同一份数据，减少信息在表格与系统之间反复搬运。
阻断项与清单完成条件
并非所有未澄清项都同等严重。以下四类建议设为阻断项，未澄清前不进入容量评估：
- 范围边界：包含项与排除项未确认，估算范围无法界定。
- 关键技能：稀缺技能无可用人员且无可替代方案，投入无法落地。
- 交付时间：目标日期或关键里程碑缺失，无法判断人力峰值是否可行。
- 优先级依据：排序理由缺失，容量不足时无法做取舍。
阻断项未澄清时，处理动作是退回补充而非搁置：由清单负责人指定补问对象和期限，到期重新复核。清单完成条件为全部阻断项判定为已澄清且附有证据，非阻断项允许以“部分澄清”状态随清单流转，但需注明补充计划。
例外放行需要明确条件与审批人，例如业务期限不可调整时，由需求提出方与研发负责人共同书面确认风险，并经资源或项目管理人员记录后方可进入评估。清单关闭后，交接对象为容量评估或排期环节的负责人，交接内容包括澄清记录、阻断项结论和待补充事项清单。
常见问题
需求提出方只能给出大致时间，清单还能继续推进吗？
可以推进，但交付时间一项应判定为“部分澄清”或“未澄清”，视缺失程度而定。如果目标日期完全缺失，按阻断项处理，退回补充；如果日期存在但来源未说明（例如未注明是合同期限还是内部期望），可先记录日期并标注待确认来源，同时列出补问对象和期限。清单允许非阻断项以“部分澄清”状态随流程流转，但阻断项必须澄清后才能进入容量评估。
技能要求写到什么颗粒度才算澄清？
以能判断“团队内是否有人可承接、是否需要外部支持”为准。建议按角色列出必备技能和可培养技能，并标注稀缺程度与可替代性。如果只写“需要后端开发”，无法判断技能匹配；如果写到具体框架和熟练程度，又可能超出澄清阶段所需。一个可操作的检验方法是：承接团队负责人能否据此回答“现有成员中谁可以投入、缺口在哪里”。
多个需求同时澄清时，优先级排序如何避免各说各话？
在清单中固定记录排序比较的对象和理由，例如“相对某合规需求排后，因监管期限在下一季度”。排序结论需要需求提出方与研发负责人共同确认，并附优先级评审记录作为证据。如果两个需求都声称紧急且缺少比较依据，应判定优先级一项未澄清，按阻断项处理。统一记录比较基准，能让容量不足时的取舍有据可查。
清单关闭后需求发生变更，需要重新走一遍澄清吗？
取决于变更是否触及阻断项。清单中应事先约定变更触发条件，例如范围扩大超过一定比例、交付时间前移、关键技能要求变化时，需要重新澄清对应检查项。仅涉及非阻断项的小幅调整，可在原清单上更新记录并注明变更依据。无论哪种情况，变更后的结论和证据都应保留版本信息，便于后续评估引用。
澄清结果记录在表格里，后续容量评估如何直接使用？
关键是让澄清记录与需求记录关联，避免评估时重新收集。在工具层面，可以把角色、估算口径、峰值时段和阻断项结论记录到工作项字段与关联文档中，评审状态同步更新。ONES 支持通过工作数量和工时规模了解成员排期，并可按筛选与分组查看成员在不同项目的投入比重；资源和工时管理解决方案提供资源规划视图，便于按业务优先级安排团队资源。这样容量评估可以直接引用同一份数据，减少表格与系统之间的反复搬运。
