需求梳理把来自客户、销售、运营和内部团队的零散诉求，整理成可判断、可排序、可交接的需求集合。它覆盖收集、澄清、合并拆分和入库四个环节，到每条需求都有来源、场景、目标、验收口径、负责人和状态时即可交付评审。下面按步骤说明每步的输入、动作、产出和完成标志，并给出字段表、角色分工与自查清单。
要点总览（TL;DR）
- 需求梳理的对象是需求集合本身：统一描述口径、合并重复诉求、拆分过大条目，到每条需求都有来源、场景、目标、验收口径、负责人和状态时即可交付评审。
- 四步流程各有输入、动作和完成标志：统一入口登记原始诉求，逐条澄清场景与验收口径，按同一场景、同一问题、同一目标结果合并重复并拆分可独立验收的结果，最后按统一字段入库。
- 澄清时先确认问题再讨论实现方式，把提出人直接给出的方案还原成背后的业务场景，避免评审时争论做法却没人确认问题是否真实存在。
- 角色分工沿一条交付链展开：登记人维护入口，需求负责人主导澄清与整理，提出人参与确认，评审参与者核对字段完整性与验收口径。
- 缺少验收口径或来源无法追溯的需求不进入评审，留在待补充状态，由需求负责人补齐后再提交。
需求梳理要解决什么问题，梳理到什么程度算完成
需求梳理处理的是需求集合本身：把口径不一的描述统一成同一种结构，把重复的表达归并到一条主需求，把过大的诉求拆成可独立验收的条目。它不负责决定先做哪一条，也不负责把需求排进某个迭代。价值评分、优先级排序和 Sprint Backlog 排期属于后续环节，梳理阶段只需保证进入评审的每条需求信息完整、指向清楚。
梳理完成的判断标准可以落到六个字段上：来源、场景、目标、验收口径、负责人和状态。六项齐全，且需求提出人与承接方对问题描述的理解一致，这条需求就算梳理完成。缺少验收口径或来源无法追溯的条目，即使描述再详细，也不具备进入评审的条件。
梳理深度随需求所处阶段分层，避免两种极端：一种是早期就要求写清全部细节，导致澄清周期无限延长；另一种是直接跳到排期，把模糊诉求当成已确认需求。早期阶段允许粗粒度，重点是把问题、场景和期望结果记下来；进入评审前再细化验收口径、边界条件和关联记录。分层处理让梳理有明确的停止点，而不是一直澄清下去。
第一步：统一收集入口与原始需求登记
收集环节的目标是让所有渠道的诉求都能被找到，并且保留提出时的原始表达。输入是来自客户、销售、运营、内部团队等渠道的原始诉求，形式可能是聊天记录、邮件、会议纪要或口头转述。动作是设定一个统一入口，所有诉求先登记再流转，避免同一诉求在多个地方重复出现却无人认领。
登记时保留原文，不做提前改写。改写会丢失提出人的真实语境，也会让后续澄清失去对照依据。登记表建议包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 提出人 | 记录姓名与所属渠道，便于回访确认 |
| 提出时间 | 登记日期，用于判断诉求的时效性 |
| 原始描述 | 照录提出人的原话，不改写、不概括 |
| 业务场景 | 提出人描述的使用情境，可先粗记 |
| 期望时间 | 提出人希望的解决时间，注明是硬性要求还是期望 |
| 登记人 | 负责录入的人，便于追溯登记过程 |
完成标志是：各渠道的诉求都能在入口找到对应记录，没有只存在于私聊或会议口头结论中的需求。入口规则需要明确一件事：谁有权登记、登记后由谁接手。规则不清时，入口会退化成又一个信息孤岛。
第二步：逐条澄清场景、目标与验收口径
澄清环节要回答四个问题：谁在什么场景下遇到什么问题、期望的结果是什么、如何判断问题已经解决、有哪些边界条件。这四个问题对应场景、目标、验收口径和约束，构成一条需求可被评审的最小信息集。
澄清时先确认问题，再讨论实现方式。提出人往往直接给出方案，例如“加一个导出按钮”，这时需要追问背后的场景：是要把数据交给谁、多久做一次、现有方式哪里不顺手。问题确认清楚后，实现方式可能有多种，方案讨论留到后续环节。把需求与方案混在一起，容易导致评审时争论做法，却没人确认要解决的问题是否真实存在。
澄清问题清单可以直接使用：
- 这个诉求是在什么业务场景下产生的，多久发生一次？
- 目前的做法是什么，哪里最费时间或最容易出错？
- 期望达到的结果是什么，用什么指标或现象判断已经解决？
- 有哪些必须满足的约束，例如时间、数据范围、使用角色？
- 如果只解决一部分，哪部分最关键？
产出是澄清后的需求描述与验收口径草案，记录在澄清记录中，与原始登记关联。完成标志是需求提出人与承接方对问题描述达成一致，双方对“什么算解决”有相同理解。达成一致的方式可以是一次简短确认，也可以是书面回复，关键是留下可查的记录。
第三步：合并重复需求与拆分过大需求
去重和拆分是整理需求集合的核心动作，判断依据要统一，否则同一类诉求在不同人手里会得到不同处理。
重复判断看三点：同一业务场景、同一问题、同一目标结果。三点同时成立，视为重复需求。合并时保留一条主需求，把其他来源记录作为关联记录挂在主需求下，提出人信息全部保留。这样既减少评审时的重复讨论，也不丢失任何一方的诉求背景。仅场景相似但目标不同的需求不合并，例如两个团队都提到报表，一个要按周汇总、一个要按项目拆分，应作为两条需求分别处理。
拆分依据是一条需求是否包含多个可独立验收的结果。如果一条需求里既有权限调整又有页面改版，两者可以分别验收、分别交付，就拆成多条。拆分后每条需求各自拥有场景、目标和验收口径，避免一条大需求在评审时因部分内容争议而整体搁置。拆分说明要记录原需求与子需求的对应关系，便于回溯。
产出是去重合并后的需求清单与拆分说明。完成标志是清单中不存在指向同一问题结果的重复条目，也不存在粒度过大、无法在一次评审中判断清楚的条目。
第四步：按统一字段入库并建立评审与变更规则
入库是把整理结果固化为需求池条目的动作。字段统一，评审才能按同一口径判断；状态规则明确，需求池才不会在流转中失控。需求池必备字段如下：
| 字段 | 说明 |
|---|---|
| 编号 | 唯一标识，入库时自动或按规则生成 |
| 标题 | 一句话概括问题，不含实现方案 |
| 来源 | 关联原始登记记录与提出人 |
| 场景 | 澄清后确认的业务情境 |
| 目标 | 期望达到的结果 |
| 验收口径 | 判断问题已解决的具体标准 |
| 负责人 | 对该需求梳理质量负责的人 |
| 状态 | 待评审、评审中、已确认、已关闭等 |
| 关联记录 | 合并的来源记录、拆分说明、澄清记录 |
字段填写完整后，条目进入待评审状态。评审与变更规则需要提前约定三件事：谁可以修改状态，需求变更如何留痕，什么条件下关闭需求。状态修改权限集中在需求负责人和评审组织者手中，可以避免条目被随意推进；变更时保留修改前后的内容与修改人，评审记录中能看出结论是怎么形成的；关闭需求要有明确理由，例如已由其他需求覆盖、场景不再存在或长期无回应，关闭记录同样保留在条目中。
这一环节的产出是可评审的需求池条目与状态流转规则。在工具承载上，ONES 的需求池条目可以按上述字段配置，状态流转与评审记录随条目保存，合并来源和拆分说明通过关联关系保留在同一条目的上下文里，评审时不必在多个文档之间来回查找。完成标志是待评审条目字段齐全，状态规则已对参与评审的人说明清楚。
角色分工与各环节交付物
需求梳理涉及四类角色，职责边界清楚，交接才有依据。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求提出人 | 提供场景与期望结果，参与澄清确认 | 原始诉求描述、澄清确认意见 |
| 需求负责人或产品经理 | 主导澄清、合并拆分、字段填写与状态维护 | 澄清记录、合并与拆分说明、需求池条目 |
| 评审参与者 | 对需求描述完整性和验收口径给出意见 | 评审意见与结论记录 |
| 登记人 | 维护统一入口，完成原始登记 | 原始需求登记表 |
交付物的交接关系是一条链：原始登记表进入澄清，澄清记录支撑合并与拆分，整理结果形成需求池条目，评审意见回到条目上形成评审记录。每个环节的交付物都挂在同一条需求的上下文中，交接时不需要重新组织信息。需求负责人是这条链的枢纽，负责确认上一环节的产出足以支撑下一环节，而不是把所有工作集中到自己身上。
示例：一条客户诉求如何走完梳理流程
以下为演示情景，用于说明流程形态，不指向具体产品或客户。
起点是一条模糊诉求：某客户在沟通中提到“报表太难用了，希望能改改”。登记人将其录入统一入口，记录提出人、提出时间、原始描述、粗略场景（客户每月向管理层汇报项目进展）和期望时间（下个季度前）。此时不改写原话。
澄清阶段，需求负责人追问后得到：客户每月需要从多个项目汇总进度数据，目前手工整理约需两天，容易漏项；期望结果是汇总时间明显缩短且数据口径一致；验收口径草案为“能按月度生成覆盖全部在管项目的进度汇总，字段口径与现有汇报模板一致”。问题被确认为汇总效率与口径一致性，导出按钮、报表样式等实现方式留待后续讨论。
整理阶段发现另一销售渠道也提过“月度汇报数据整理麻烦”，场景、问题、目标结果一致，判定为重复需求，合并为一条主需求，两条来源记录都保留。澄清中还发现该诉求同时包含“汇总”和“权限分级查看”两个可独立验收的结果，于是拆成两条：一条负责月度汇总生成，一条负责按角色查看范围。两条各自填写场景、目标和验收口径。
入库时填写编号、标题、来源、场景、目标、验收口径、负责人和状态，关联原始登记与澄清记录，状态置为待评审。评审时参与者只需核对字段完整性和验收口径是否可判断，不再重复讨论原始诉求是否真实。
这个示例可迁移的规律是：原文保留让澄清有据可查，问题与方案分离让评审聚焦在要解决什么，合并与拆分让条目粒度适合判断。适用边界在于，诉求本身涉及跨部门流程调整时，澄清范围会超出单条需求，需要另行组织讨论，不宜强行压缩进一次梳理。
完成检查：需求梳理结果的自查清单
本轮梳理是否可交付评审，逐项核对以下内容：
- 字段完整性：每条需求都有来源、场景、目标、验收口径、负责人和状态，缺项已补或已标注待补原因。
- 来源可追溯：每条需求都能关联到原始登记记录，合并后的主需求保留了全部来源与提出人。
- 问题与方案分离：标题和描述陈述的是问题与目标，实现方式没有混入需求正文。
- 重复检查：不存在场景、问题、目标结果三点同时相同的多条需求。
- 拆分检查：不存在包含多个可独立验收结果、却仍作为单条处理的需求。
- 一致性检查：需求提出人与承接方对问题描述和验收口径的理解一致，并有确认记录。
- 状态规则：待评审条目的状态符合约定，修改权限和变更留痕方式已对参与人说明。
阻断项单独列出：缺少验收口径的需求、来源不明或无法回访提出人的需求，不进入评审。这两类条目留在待补充状态，由需求负责人补齐后再提交。自查通过后，需求池进入评审环节，梳理工作到此结束，后续的优先级判断与排期由相应环节接手。
常见问题
需求梳理和需求评审是什么关系，梳理到哪一步就该停下来交给评审？
梳理负责把需求整理成可判断的条目，评审负责对条目给出结论，两者是前后衔接的两个环节。梳理的停止点是字段齐全且提出人与承接方对问题描述达成一致：来源、场景、目标、验收口径、负责人、状态六项到位，条目进入待评审状态，梳理工作即告完成。
实际操作中容易出现两种偏差。一种是梳理阶段就反复讨论做不做、先做哪条，把评审的判断工作提前消耗掉；另一种是字段还缺验收口径就提交评审，评审会上再回头补信息。前者让梳理周期拉长，后者让评审效率下降。把“信息是否完整”留给梳理、“是否值得做、什么时候做”留给评审，两个环节各自有明确的结束条件。
提出人直接给了实现方案，比如要求加一个导出按钮，梳理时应该怎么处理？
先把方案还原成问题：这个导出是要把数据交给谁、多久做一次、现有方式哪里不顺手。确认清楚场景和期望结果后，再判断实现方式。方案本身可以作为参考记录在澄清记录里，但不直接写进需求标题和描述。
这样处理的原因是，同一个问题往往有多种解法，过早锁定方案会让评审聚焦在做法之争上，而忽略了要解决的问题是否真实存在、范围是否清楚。如果澄清后发现提出人的方案确实是最合适的做法，也可以在后续方案讨论中沿用，只是它此时的身份是候选方案，而非需求本身。
两条需求场景相似但目标不同，应该合并还是分开？
分开处理。重复判断需要同一业务场景、同一问题、同一目标结果三点同时成立，仅场景相似不足以合并。例如两个团队都提到报表，一个要按周汇总、一个要按项目拆分，目标结果不同，应作为两条需求分别填写场景、目标和验收口径。
强行合并会让验收口径变得含糊，评审时无法判断做到什么程度算完成。如果两条需求后续确实指向同一交付物，可以在关联记录中互相引用，保留各自的来源与提出人信息，等方案明确后再决定是否归并。
需求入库后发生变更，梳理阶段建立的字段和记录还怎么维护？
变更时保留修改前后的内容、修改人和修改时间，评审记录中能看出结论是怎么形成的。状态修改权限建议集中在需求负责人和评审组织者手中，避免条目被随意推进。
字段结构本身不需要因变更而重建，来源、场景、目标、验收口径这些字段随变更同步更新即可。合并来源和拆分说明通过关联关系挂在条目上，变更后仍可回溯到最初的原始登记与澄清记录。这样处理的价值在于，几个月后回看一条需求时，能还原它从提出到当前状态的完整路径，而不是只看到一个孤立的最终描述。
团队规模较小、没有专职产品经理时，需求梳理的角色分工可以怎么简化？
可以合并角色，但不能省略职责。小团队中登记人、需求负责人常由同一人兼任，评审参与者也可以缩减为两三人，关键是每条需求仍有人对澄清质量和字段完整性负责，提出人仍要参与问题描述的确认。
简化时优先保留两项：一是统一入口，所有诉求先登记再流转，避免需求散落在私聊和会议纪要里；二是验收口径的确认记录，哪怕只是一次书面回复。这两项决定了需求池能否被追溯和判断，其余角色安排可以按团队实际人数调整。角色合并后要在团队内说明谁负责哪一段，避免出现“都以为对方在跟进”的空档。
