从美国客户的需求到 UAT

问题

客户是一家美国的 SaaS 公司，开发团队在越南。需求通常以一封简短的邮件或会议中的一两句话的形式出现。如果直接转给开发，每个需求都会引发多轮追问。

需求直接交给开发时每一轮追问都要耗掉整整一天

1. 1三行邮件来自客户方 PM
2. 2开发阅读并猜测
3. 3向客户追问
   时差 11–12 小时
4. 4客户答复第二天早上

客户答复 → 开发阅读并猜测 · 反复进行，直到足够清楚

背景与角色

• 我是对接人，负责受理需求、分析、设计并交付给开发。所有会议、邮件、工单和文档均使用英语。客户指定我为团队唯一的对接人。
• 兼任部分 Scrum Master 职责：backlog、Sprint 计划、阻塞项、进度。
• 参与测试和 UAT。
• 约束：存在时差，客户方没有 BA，未经批准不得改变支付行为。

项目的真实规模

面向美国住宅建筑行业的 SaaS 平台，15 个代码仓库：管理后台、工人应用、供应商门户、财务与报表服务。数据统计自项目文档库和 Jira，时间为 2026 年 6 月至 9 月。

Jira我在全板创建的工单

• 我创建
• 团队其他成员

• 1,333 个 issue占 47%，团队最多

  624709

本页其余部分用一个模拟需求，展示我在项目中处理每个需求的具体流程。

第 1 步：受理原始需求

CPClient PM收件人 BA

Plan expiry

“We need customers to get reminded before their plan expires, and lose access if they don’t pay. Sales also wants to know who is about to churn. Can we have this next sprint?”

短短三句话，却至少包含三个功能、两个受影响的系统（支付和访问权限），以及销售部门的报表需求。

第 2 步：澄清问题清单

每个问题都附带一个默认假设，客户只需确认或修改。

澄清问题九个问题，一轮答复

7/9

• 提前多少天提醒，提醒几次？客户修改：增加 3 天节点，变为 7 天、3 天和 1 天Q1
• 邮件、应用内，还是两者都要？假设：两者都要Q2
• 只发给账户所有者，还是也发给其他管理员？假设：账户所有者和账单管理员Q3
• 逾期后立即锁定，还是设宽限期？假设：宽限期 7 天，仅作警告Q4
• 全部锁定，还是只锁定付费功能？客户修改：只读，并额外锁定 API 调用权限Q5
• 发布时已逾期的账户怎么办？假设：宽限期从发布日起算Q6
• 内部管理员能否手动延期？假设：可以，但必须记录日志Q7
• “到期”按哪个时区计算？假设：账户所在时区Q8
• 销售在哪里查看、需要哪些列、多久更新一次？假设：CRM 中的列表，每日更新Q9

第 3 步：影响评估与业务规则

设计之前，我先阅读代码库和开发数据库，弄清哪些组件会受影响。

影响评估五个现有组件受到影响

业务规则在绘制流程前由客户书面确认。前三条规则位于同一条时间轴上：

BR-01 至 BR-03一个套餐，从即将到期到只读

宽限期 7 天 · 每次登录时显示警告

T−7第 1 次提醒T−3第 2 次提醒T−1第 3 次提醒T0到期T+7只读，API 返回 402

T−8T+9

1. T−7第 1 次提醒
2. T−3第 2 次提醒
3. T−1第 3 次提醒
4. T0到期
5. T+7只读，API 返回 402
6. 宽限期 7 天 · 每次登录时显示警告

业务规则由客户书面确认

7/7

• 到期前 7 天、3 天和 1 天提醒续费BR-01
• 宽限期 7 天，每次登录时显示警告BR-02
• 宽限期结束：只读，API 请求被拒绝，返回 402BR-03
• 支付成功后账户在 5 分钟内恢复正常BR-04
• 管理员可手动延期，最长 30 天，必须填写原因并记录日志BR-05
• 发布前已逾期的账户：宽限期从发布日起算BR-06
• “有流失风险”：即将到期或处于宽限期，且 30 天内没有付款BR-07

第 4 步：状态生命周期、用户故事与工单

套餐的状态

1. 1Active
2. 2Expiring还剩 7 天
3. 3Grace宽限期 7 天
4. 4Suspended只读

Suspended → Active · 任何状态下支付成功，账户都在 5 分钟内重新开通（BR-04）

US-02Ready

Grace period and read-only mode

As a billing admin of an expired account, I want a 7-day grace period with clear warnings so that I can renew without losing my data or being locked out unexpectedly.

• Given the subscription expired less than 7 days ago, when the user signs in, then a warning banner shows the expiry date and the days left, and every feature still works.
• Given the subscription expired 7 or more days ago, when the user calls any write endpoint, then the response is 402 with renewal instructions, and read endpoints still return 200.
• Given a suspended account, when a successful payment webhook arrives, then the account is active again within 5 minutes.
• Given an account that expired before the release date, when the release goes live, then the grace period starts on the release date.

Epic

Subscription expiry

Rules

BR-02, BR-03, BR-04, BR-06

Sprint

Current

Jira一个 Epic，四个 Story，按 Sprint 容量拆分

	本 Sprint	下个 Sprint
US-01 · 通过邮件和应用内提醒续费	排入
US-02 · 宽限期与只读模式	排入
US-03 · 管理员手动延期并记录日志		排入
US-04 · “有流失风险”列表同步到 CRM		排入

第 5 步：测试与 UAT

测试用例根据验收标准编写。可自动化的用例先由智能体执行；失败用例以及与 webhook 相关的用例由我亲自验证。

测试用例测试表节选

	执行方式	结果
TC-01 · 还剩 7 天：收到内容正确的邮件和通知	智能体	通过
TC-02 · 其他时区：在当地的正确日期收到提醒	智能体	失败：任务按 UTC 时间运行
TC-04 · 被锁定：写操作返回 402，读操作返回 200	智能体、API	通过
TC-05 · 锁定状态下支付：5 分钟内恢复	手工	通过
TC-06 · 支付 webhook 重复到达两次	手工	失败：续期被重复计算

UAT

1. 1UAT 清单对应 BR-01 至 BR-07
2. 2客户在 staging 上执行就在会议中
3. 3通过工单签字确认

结果

从邮件到验收

1. 11 封邮件三行字
2. 29 个问题一轮答复
3. 37 条业务规则客户确认
4. 41 个 Epic，4 个 Story带验收标准
5. 5测试用例与 UAT签字确认

• “问题附带默认假设”的澄清方式在后续需求中被沿用。
• 开发团队拿到的工单已满足条件，不必隔着时区等待答复。

我学到的

• 面对有时差的客户，问题的质量比写代码的速度更能决定 Sprint 的速度。
• 设计前先读开发数据库，才能用数据对需求提出不同意见。
• 验收标准永远列不全。BA 需要凭借对系统的理解自行补充测试。