需求提报人调岗、离职或职责调整时，交接的重点是把“谁提的、为什么提、当前确认到哪一步”完整转移给接手人。本文给出一套可执行的交接方法：先界定哪些事项属于待确认，再按五步流程完成权限切换、信息移交与确认闭环，最后用检查清单判断交接能否关闭。文中示例为演示性设定，用于说明清单与字段如何填写。
要点总览（TL;DR）
- 交接对象先界定：尚无明确结论、结论依赖原提报人个人判断、结论未形成书面记录，满足其一即纳入待确认范围。
- 交接按五步推进：冻结原提报人权限并指定新提报人、原提报人填写现状、新提报人复核、需求负责人组织确认、更新状态并关闭交接记录。
- 交接记录把状态和确认人设为必填项，每项待确认事项都要有确认人、确认方式与截止时间，未确认项保持待确认，不因换人默认通过。
- 交接是否完成看检查清单：权限已切换、信息完整、状态一致、记录可追溯、失效项已处理；存在无确认人的待确认项或口头结论未落记录时判定不通过。
- ONES 的统一需求池与权限、流程配置可用于记录需求来源与处理状态，提报人字段变更与变更历史的具体配置建议在实际环境中确认后再固化到流程。
交接前先明确：哪些事项算“待确认”
交接最容易出问题的环节，是把“大家以为已经定了”的事项当成已确认，或者把原提报人的个人判断当成团队结论。因此在动手交接之前，先要有一份判定标准，把需求单上的信息分成三类状态，交接只处理其中的待确认与需复核项。
三条判定标准
一项内容只要满足以下任意一条，就应纳入待确认范围：
- 尚无明确结论：需求背景、范围、优先级等只有讨论过程，没有形成最终意见。
- 结论依赖原提报人的个人判断：例如“当时说大概下个季度要”，依据只存在于原提报人的记忆或口头沟通中，换人后无法复现。
- 结论未形成书面记录：会议上有共识，但需求单、邮件或文档中没有留下确认人和确认时间。
按内容分类整理待确认事项
判定之后，把待确认事项归入以下五类，便于逐类核对、逐类指派确认人：
| 类别 | 典型待确认内容 | 确认后应留下的记录 |
|---|---|---|
| 需求背景与目标 | 业务问题是什么、期望达成什么结果、与原提报人岗位职责的关联 | 背景说明、目标描述、提出依据 |
| 范围边界 | 包含哪些场景、明确不做什么、与其他需求的边界 | 范围清单与排除项 |
| 验收口径 | 怎样算完成、验收标准由谁认定 | 验收条件与验收人 |
| 优先级与期望时间 | 相对其他需求的排序、期望上线时间及其来源 | 优先级结论、时间要求及依据 |
| 干系人与决策人 | 谁提出、谁使用、谁拍板、谁需要被通知 | 干系人名单与决策人 |
区分三种状态
每项内容在交接记录中标注为“已确认”“待确认”或“已失效”。已确认指有明确结论且有书面记录和确认人；待确认指满足上述三条标准之一；已失效指因业务变化、时间过期或需求调整而不再成立的事项，例如原定的期望上线时间已经过去且无人跟进。交接时重点处理待确认项，同时对已确认项做一次快速复核，确认结论仍然有效，避免把过期结论原样带过去。
交接操作步骤：从冻结权限到确认闭环
交接按五个步骤推进，每一步都有明确的输入、动作、输出和完成标志。步骤顺序不宜颠倒：先冻结权限，才能保证交接期间信息不被原提报人继续改动；先由原提报人填写现状，新提报人才能在此基础上复核而不是从零猜测。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 冻结权限并指定新提报人 | 变更通知、需求清单 | 收回原提报人对相关需求的编辑与确认权限，指定新提报人，明确生效时点 | 权限变更记录、新提报人名单 | 新提报人可编辑，原提报人只能查看 |
| 2. 原提报人填写现状 | 待确认事项分类清单 | 逐项写明当前结论、判断依据、遗留问题与相关干系人 | 交接记录初稿 | 清单中每一项都有现状描述，无空白项 |
| 3. 新提报人逐项复核 | 交接记录初稿 | 核对信息完整性，对无法自行判断的事项标注需由谁确认 | 带确认人标注的交接记录 | 每个待确认项都有建议确认人 |
| 4. 需求负责人组织确认 | 带标注的交接记录 | 组织确认人逐项给出结论，记录确认方式与时间 | 确认结论记录 | 待确认项均有结论或明确的确认计划 |
| 5. 更新状态并关闭交接 | 确认结论记录 | 更新需求单上的提报人与确认状态，归档交接记录 | 更新后的需求单、已关闭的交接记录 | 需求单状态与交接记录一致 |
第4步需要特别说明：确认不一定能在一次会议内完成。对于需要业务方拍板的优先级、需要技术评估的验收口径，可以约定确认方式和截止时间，先记录“待确认、确认人为某某、截止某日”，再按计划推进。交接记录在这一步不必等所有结论齐备才继续，但每项待确认事项都必须有责任人和时间点。
在工具层面，这类交接需要需求单能记录提报人、确认状态与变更过程。ONES 提供统一的需求池，业务、产品与研发可以在同一处查看需求来源与处理状态，并通过模板、权限和流程配置管理不同角色的操作范围；需求流转过程可追溯，便于在提报人变更后核对历史信息。具体到提报人字段变更与变更历史的呈现方式，建议在实际环境中确认配置方式后再固化到流程中。
角色分工与交接记录应包含的字段
交接涉及四类角色，各自的责任边界要提前说清，避免出现“原提报人已经调岗、新提报人不敢拍板、需求负责人不知情”的空档。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 原提报人 | 提供需求背景、历史结论与遗留问题；对已做出的判断说明依据，区分事实与个人推测 | 交接记录中的现状描述与依据说明 |
| 新提报人 | 承接后续提报与确认工作；复核信息完整性，标注无法自行判断的事项及建议确认人 | 复核意见与确认人建议 |
| 需求负责人 | 组织确认会议或确认流程；对争议事项做出裁定；对交接结果签字确认 | 确认结论、交接结果确认 |
| 确认人/决策人 | 对待确认事项给出明确结论，说明确认方式 | 逐项确认结论与时间 |
交接记录建议采用固定字段，保证不同人交接时口径一致、事后可追溯：
- 需求编号与需求名称
- 原提报人、新提报人
- 交接时间与生效时点
- 待确认事项（按背景目标、范围、验收口径、优先级与时间、干系人分类）
- 每项的当前状态：已确认、待确认、已失效
- 确认人、确认方式（会议、书面回复、评审等）
- 结论内容与确认时间
- 截止时间
- 备注：口头承诺、待补充材料等
字段设计的关键是让“状态”和“确认人”成为必填项。只要有一项待确认事项没有确认人，这条记录就无法通过后续检查，从而在流程上堵住“先交接、以后再说”的口子。
示例：一次提报人变更的交接过程
以下为演示性场景，用于说明清单与字段如何填写，不代表真实客户案例。
某业务系统的需求由原提报人提出，因岗位调整，由新提报人接手。交接时发现该需求存在两项未确认内容：范围边界和优先级。按清单逐项填写后，交接记录如下：
| 事项 | 状态 | 现状描述 | 确认人 | 确认方式 | 截止时间 |
|---|---|---|---|---|---|
| 需求背景与目标 | 已确认 | 解决对账耗时问题，目标为缩短月度对账时间，有会议纪要 | — | — | — |
| 范围边界 | 待确认 | 原提报人口头提到“先做核心流程”，核心流程具体包含哪些环节未落记录 | 业务负责人 | 书面确认 | 交接后3个工作日 |
| 验收口径 | 已确认 | 以对账结果准确率与操作步骤数为验收条件，已写入需求单 | — | — | — |
| 优先级与期望时间 | 待确认 | 原期望时间为上季度，已过期；当前排序需重新评估 | 需求负责人 | 需求评审会 | 下次评审会 |
| 干系人与决策人 | 待确认 | 原干系人名单含已调岗人员，需更新 | 新提报人 | 名单核对 | 交接后1个工作日 |
这个例子暴露了三类常见遗漏。第一类是口头承诺未落记录，如“先做核心流程”，换人后无法确认原意，只能重新确认。第二类是干系人名单未更新，原名单中的调岗人员仍在列，导致后续通知发错对象。第三类是期望时间已过期但无人处理，如果直接沿用旧时间，排期会出现偏差。处理方式是：三项待确认分别指定确认人与截止时间，状态保持“待确认”，直到结论形成并记录确认时间，才改为“已确认”。
交接完成检查清单
交接是否完成，不看交接会议是否开过，而看以下检查项是否全部通过。建议由需求负责人逐项核对后再关闭交接记录。
| 检查项 | 通过标准 |
|---|---|
| 权限与责任人 | 新提报人已生效并可编辑相关需求；原提报人的编辑与确认权限已收回，仅保留查看 |
| 信息完整性 | 待确认事项均有确认人、确认方式与截止时间；已确认项有书面记录和确认时间 |
| 状态一致性 | 需求单上的提报人、确认状态与交接记录一致；不存在未确认却被标为已通过的项 |
| 记录可追溯 | 交接记录、确认结论与确认时间已归档，后续可查 |
| 失效项处理 | 已失效事项已标注原因，未混入待确认清单重复处理 |
出现以下情况时，交接判定为不通过，需要补齐后再关闭：存在没有确认人的待确认事项；口头结论未形成书面记录；需求单状态与交接记录不一致；原提报人权限未收回，交接期间仍可能产生新的改动。把这些阻断项写进检查清单，可以让交接从“口头交代清楚”变成有据可查的状态转移，提报人变更后需求的确认进度也不会因此中断。
常见问题
原提报人已经离职，无法填写交接记录怎么办？
由需求负责人牵头，从已有书面材料中还原信息：需求单、邮件、会议纪要、工单记录、聊天记录中的确认内容。对只能依赖原提报人记忆的事项，直接标为待确认，并指定最了解该需求的业务方或原提报人的上级作为确认人。交接记录中注明“原提报人已离职、信息来源于书面材料”，避免后续把推测当成既定结论。
交接期间新提报人还没到位，需求由谁负责？
在交接记录中明确过渡责任人，通常由需求负责人或原提报人的上级临时代管，代管范围包括接收新的确认请求和对外答复进度。过渡期同样执行权限冻结，代管人只做信息保管与转达，不对未确认事项拍板。新提报人到位后，按同一份交接记录完成复核，再正式切换责任人。
待确认事项的截止时间到了仍没有结论，怎么处理？
状态继续保持“待确认”，由需求负责人重新指定确认人和新的截止时间，并在交接记录备注中写明延期原因。若该事项已影响排期或交付，应升级到需求评审会裁定，或明确按当前已知信息推进并记录风险。延期不等于默认通过，缺少结论的事项不能改为已确认。
提报人变更后，之前已经确认过的结论需要重新确认吗？
不必全部重来，但要做一次有效性复核。有书面记录和确认人的结论可以沿用，重点检查结论是否仍然成立：期望时间是否已过期、范围是否因业务变化调整、干系人是否已变动。复核发现不再成立的，改为已失效并注明原因，避免把过期结论原样带入后续排期。
多个需求同时更换提报人，如何避免交接遗漏？
按需求逐条建立交接记录，用统一字段保证口径一致，再由需求负责人汇总核对。优先处理有明确时间压力或已进入排期的需求，其余需求可以分批交接，但每条记录都必须有确认人和截止时间。汇总时重点检查是否存在无确认人的待确认项，以及需求单状态与交接记录是否一致。
