在 A 公司工作了三年多，主要对接某公立医院的 LIS 支持工作，项目以 Sprint 迭代方式长期交付，需求与缺陷管理使用 JIRA，日常沟通依赖客户内部 Chat、邮件、Demo 会议与每日站会。我担任研发组长，对外协调客户，对内负责排期与交付。
项目告一段落后，我把这几年在需求侧沉淀的做法做了整理。本文不涉及团队管理规范、技术编码规范等内容，只聚焦四件事：怎么和客户把需求说清楚、定下来；Sprint 里需求变了怎么处理；怎样让历史需求查得回；哪些情况要设边界、说「不行」。
一、与客户沟通需求的注意事项
不同客户性格不同，需要采用不同的沟通方式。以下是几种常见场景及处理方式。
1. 同一事项多次沟通仍无进展
和客户沟通一般在 Chat 或 Zoom 中进行。
最高优先级（P0）任务：在 Chat 或 Zoom 中尽快追踪、推动解决；若仍无法推进，及时向上汇报给 SM，由 SM 升级至客户方较高职位的对接人。
次优先级任务（P1～P3）：客户有时会遗忘，可用 Excel 追踪进展，建议包含以下字段：
| 字段 | 说明 |
|---|---|
| 事项描述 | 需求 / Bug / 待确认问题 |
| 提出日期 | 首次提出时间 |
| 优先级 | P1～P3 或客户定义等级 |
| 对接人 | 客户方负责人 |
| 客户承诺时间 | 对方答复的处理 / 确认时间 |
| 实际进展 | 每次跟进记录 |
| 下次跟进日 | P1 隔周，P2 隔 Sprint，P3 隔月或按客户约定时间追询 |
| 状态 | 待确认 / 进行中 / 已关闭 / 已升级 |
按优先级隔周、隔 Sprint 或隔月跟进。若对接人多次无法推进，该表可作为向上汇报或**延后处理（defer）**的依据。
2. 多人沟通，无人对最终需求拍板
有时客户方多人同时在线，各有意见，却无人能最终确认需求。处理方式：
- 识别客户方职位较高或业务范围更匹配的对接人
- 明确说明：需求未确认则无法排期与开发
- 询问预计确认时间，并要求确认后写入 JIRA
参考措辞：
您看，这个需求目前无法确定，我们这边也无法继续推进。能否请您帮忙确认最终方案？确认后我们再按你方的要求执行。请问大概什么时候可以定稿？定稿后能否将确认结果记录在 JIRA 中？
这样可将仍在犹豫的需求锁定到责任人，避免多人意见不一、需求无法推进。
组长动作：对内先统一口径，指定一名成员整理讨论要点；对外只由组长回复，避免团队成员各自向客户承诺。
3. 识别伪需求
识别伪需求的前提，是对底层业务有一定了解。客户虽熟悉业务，但在互联网或 UI 方面经验可能不如团队。需要基于业务，帮客户梳理绕路、操作繁琐的流程。
原则：
- 早期以倾听为主，建立信任
- 熟悉业务后，在合适时机提出简化建议
- 对某模块足够熟、客户足够信任后，可逐步主导方案讨论
- 不直接否定客户，用「目前流程是 A，如果改成 B 可以少 N 步」的方式沟通
常见伪需求信号：
- 客户要求的功能，现有系统或报表已可满足
- 需求描述的是「怎么做界面」，而非「要解决什么业务问题」
- 多人讨论后方向反复，说明业务目标本身未清晰
- 按客户要求实现后，操作步骤仍然繁琐
4. 锁定沟通结果
需求沟通过程和确认项有时在 Chat 和会议中完成。处理方式：
- 将会议中沟通确认的结果，及时在 Chat 中发送给客户，与客户二次确认
- 引导客户在 JIRA 中创建 Story，逐步培养习惯
- 将 Chat 中的确认结论同步到对应 Story 的 Comment
- Comment 中写清：确认人、确认时间、确认内容、是否有附件 / 截图
- 口头确认的事项，24 小时内补录 JIRA，避免「说过但无记录」
- Demo 会议中客户提出的改动需求，记录到 JIRA，与客户二次确认，再根据实际情况决定当期修改或放入下个 Sprint 处理
原则：Chat、会议用于讨论，JIRA 用于定稿与追溯。
二、需求变更处理方案
需求在 Sprint 内仍可能发生变化。常见有两类。
1. 高优先级需求需插入当前 Sprint
处理流程：
收到插入需求
↓
评估：故事点、参与人、是否影响在研任务
↓
组长 + 研发 + 测试联合评估能否在本 Sprint 完成
↓
能完成 → 与客户沟通工时置换（延后低优先级 Story）
不能完成 → 说明原因，建议放入下一 Sprint 或拆分为第一期 / 第二期
↓
客户确认后，再调整 Sprint 待办列表
评估要点：
- 了解需求范围与验收标准
- 研发估点，明确参与人员
- 判断当前 Sprint 剩余容量是否足够
- 与客户沟通：当前 Sprint 未开始的低优先级任务，是否可以延后
- 置换结果写入 JIRA Sprint 备注，Demo 时向客户说明范围变化
组长原则：不在客户未确认前，私下答应「这个 Sprint 能做」；每个 Sprint 预留约 10%～15% 的工时缓冲应对小改动，但不替代正式变更流程。
2. 研发中期发现理解与客户不一致
此类情况在团队中较少，但若发生，必须及时叫停，不能带着偏差做到 Demo。
处理步骤：
- 内部对齐：与研发、测试开会，列出理解不一致的具体点
- 判断性质
- 研发理解更深 → 可能是需求升级，需与客户确认是否接受
- 研发理解有误 → 评估改动范围
- 需求本身模糊 → 回到「需求确认」流程
- 拉客户对齐：用 Story、原型或流程图对照，逐条确认
- 评估影响：能否在当前 Sprint 完成；若不能，是否拆期
- 复盘：是否规划阶段说明不足、Story 描述不清、缺少测试用例评审
改动量判断：
| 情况 | 处理方式 |
|---|---|
| 改动小，不影响验收 | 当前 Sprint 内完成 |
| 改动中，影响 1～2 人天 | 与客户沟通是否接受部分交付 |
| 改动大，影响架构或排期 | 暂停开发，重新估点，调整 Sprint 或拆分 Story |
预防措施（Sprint 规划阶段）：
- 复杂功能必须向客户陈述打算如何实现
- 涉及 SQL、报表、权限、多库查询的 Story，规划时拉客户、组长、测试一起过
- 对容易歧义的需求，当天安排需求对齐小会，不要拖到开发中期
三、需求对齐与追溯
要减少变更和理解偏差，前提是历史需求查得回、对得上。项目周期越长，研发和客户人员变动越多，后来者越难了解以前的需求。我们建立了如下文档体系。
1. 引导客户在 JIRA Story 中记录需求
日常沟通中的确认项、需求细节，客户未必会及时写入 Story。应尽量引导客户：
- 将需求写入 Story 描述；未写入 Story 的，由组长更新并与客户确认
- 将日常确认内容写入 Story 的 Comment
- 每条 Comment 标注：日期、确认人、结论
组长动作：每次 Demo 前检查本 Sprint Story 是否已更新；未更新的，由对应人员补充；组长复核后与客户确认。
2. Issue、Bug 关联到 Story
功能增强时可能遇到 Bug 再现，或隔一两年需要查某个 Issue / Bug 为何如此处理。要求：
- Bug / Issue 必须关联对应 Story 或 Epic
- 关闭 Bug 时在 Comment 中说明根因和修复方式
- 若为「设计如此」，需引用客户确认记录
3. 测试用例承载业务需求（思维导图）
每个 Sprint 若再单独写长篇需求文档，既难保证交付质量，又占用时间。但项目持续迭代、人员也会变动，仍需要随时查阅历史需求。经与团队沟通，测试用例不应只是测试指引，还应承载业务逻辑，由全团队共同维护。
实际场景中，客户常会问：「以前这个功能查的是哪条 SQL？」若只能去代码里翻，效率很低。沟通过程中，客户和团队也都会遇到「历史业务记不清」的情况。因此测试用例采用思维导图，约定如下：
内容要求：
- 可执行性：非 Tester 也应能按用例执行，步骤需足够详细
- 业务与 JIRA：写清业务需求及对应 JIRA ID
- SQL 与数据：写明各功能涉及的 SQL、查询/更新的表与字段
- 多库场景：若存在多库，需标明查询或更新的是哪个 DB
- 维护责任：Story 变更时，测试用例同步更新；研发 Review 用例中的 SQL 与逻辑是否正确
组织方式：
- 不要按每个 Sprint 的交付形式拆分导图
- 按整体项目或业务模块组织
- 同一需求多次迭代时，在模块下增加版本节点，而非新建孤立分支
评审机制：
- 每个 Story 开发前，客户 + 研发 + 测试共同评审测试用例
- 评审后的改动及时更新到用例中，并同步给各方
- 研发参照 Story 和测试用例开发
- 每个 Sprint 结束时，组长复核用例是否符合规范、是否有遗漏
组长原则：测试用例是团队资产，不是测试个人文档；人员变动时，用例完整性优先于个人写法习惯。
4. 资料归纳整理与需求回溯（Sprint 交付记录）
（1）Demo 交付记录
每次 Demo 前向客户讲解本次交付内容，并留存记录：
| 记录项 | 说明 |
|---|---|
| Sprint 编号 | 如 Sprint 42 |
| 时间范围 | 起止日期 |
| 交付 Story 列表 | JIRA ID + 标题 |
| Demo 日期 | 实际演示时间 |
| 客户反馈 | 待修改项 / 已接受项 |
| 遗留问题 | 带入下一 Sprint 的事项 |
形式：Markdown页面均可，关键是按时间可检索。
作用：
- 向客户做总体说明
- 日后按时间查找「某年某月做了什么」
- 帮助后来者了解项目演进路径
（2）其他补充资料
需求呈现不限于 JIRA 和思维导图，有时还需：
- Excel：批量数据规则、字段映射、对账表
- 录屏视频：客户需求讲解、复杂操作流程、Demo 回放、知识交接会议
- 流程图 / 原型：界面变更、审批流
- 测试 SQL 脚本合集：按模块归档
归档原则：按项目模块存放，避免文件散落在个人电脑或 Chat 记录中。
项目周期长、人员会变动，依靠以上文档体系，后来者可以更快了解既有业务，而不只依赖「谁还记得」。
四、风险识别与边界管理
文档体系能缓解问题，但无法消除风险。以下是我们长期关注的几类风险，以及什么情况下需要设边界。
1. 风险登记表
| 风险 | 信号 | 影响 | 缓解措施 | 负责人 |
|---|---|---|---|---|
| 需求悬空 | 同一事项 3 次沟通无结论 | 排期浪费、Sprint 空转 | Excel 追踪 + 升级对接人 | 组长 |
| 人员单点 | 某模块仅一人能改 | 离职 / 请假导致停滞 | 结对 + 文档 + 交叉复核 | 模块负责人 |
| Sprint 被打穿 | 中途插入多个高优需求 | 承诺无法兑现 | 工时置换 + 预留缓冲 + 提前预警 | 组长 |
| 理解偏差 | 开发中期才发现 | 返工、延期 | 规划时讲清实现 + 用例评审 | 组长 + 研发 + 测试 |
| 客户换人 | 新对接人推翻旧结论 | 重复沟通、范围蔓延 | 以 JIRA 记录为依据 | 组长 |
| 项目重启 | 文档过时、人员全换 | 上手慢、重复踩坑 | 知识交接 + 交付记录 + 思维导图 | 组长 |
更新频率：每个 Sprint 规划时过一遍，关闭已消除的风险，补充新风险。
升级路径（简要）：
- 需求长期悬空 → 组长汇总 Excel，上报 SM，由 SM 对接客户方较高职位
- Sprint 范围失控 → 周报说明影响，同步内部 PM 或部门负责人
- 生产 P0 故障 → 即时通报客户与内部管理层，事后补充根因分析
2. 预期管理与说「不行」
可以延后或拒绝的情况：
- 需求未确认就要求开发
- 超出当前 Sprint 容量，且无法做工时置换
- 与已确认需求冲突，客户内部尚未拍板
- 涉及合规、安全、架构大改但未评估
参考说法：
理解这项需求的重要性。按当前 Sprint 容量，若插入此需求，XX 和 YY 将无法在本 Sprint 完成。建议：一，置换低优先级 Story；二，拆成两期，本期做核心部分，下期完成其余。请您确认倾向哪种方式，我们好调整排期。
结语
长期 B 端项目里，需求管理的核心可以概括为三句话：
- Chat、会议用来讨论，JIRA 用来定稿
- 测试用例不只服务测试，也承载业务与历史
- Demo 记录留痕，让后来的查得到、对得上
这些做法来自一个 Sprint 迭代的医疗 B 端项目，未必能原样照搬，但在「客户难拍板、需求常变更、人员会变动」的场景下，希望对你有参考价值。
