Từ yêu cầu của khách hàng Mỹ đến UAT

Vấn đề

Khách hàng là một công ty SaaS tại Mỹ, đội phát triển ở Việt Nam. Yêu cầu thường đến dưới dạng một email ngắn hoặc một hai câu trong cuộc họp. Chuyển thẳng cho Dev thì mỗi yêu cầu kéo theo nhiều vòng hỏi lại.

Khi yêu cầu đi thẳng tới DevMỗi vòng hỏi lại mất trọn một ngày

1. 1Email ba dòngtừ PM phía khách
2. 2Dev đọc và đoán
3. 3Hỏi lại khách
   lệch 11–12 giờ
4. 4Khách trả lờisáng hôm sau

Khách trả lời → Dev đọc và đoán · lặp lại cho đến khi đủ rõ

Bối cảnh và vai trò

• Đầu mối tiếp nhận yêu cầu, phân tích, thiết kế và bàn giao cho Dev. Mọi cuộc họp, email, ticket và tài liệu đều bằng tiếng Anh. Khách chọn tôi làm đầu mối liên lạc duy nhất của team.
• Kiêm một phần Scrum Master: backlog, sprint planning, blocker, tiến độ.
• Tham gia kiểm thử và UAT.
• Ràng buộc: lệch múi giờ, phía khách không có BA, không đổi hành vi thanh toán khi chưa được duyệt.

Quy mô thật của dự án

Nền tảng SaaS cho ngành xây dựng nhà ở tại Mỹ, 15 repo: web quản trị, ứng dụng cho thợ, cổng nhà cung cấp, dịch vụ tài chính và báo cáo. Số liệu đếm từ kho tài liệu và Jira của dự án, 06/2026 đến 09/2026.

JiraTicket tôi tạo trên toàn board

• Tôi tạo
• Cả team còn lại

• 1.333 issue47%, nhiều nhất team

  624709

Phần dưới dùng một yêu cầu mô phỏng để minh hoạ đúng quy trình tôi áp dụng cho từng yêu cầu trong dự án.

Bước 1: Tiếp nhận yêu cầu gốc

CPClient PMGửi 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?”

Ba câu, nhưng chứa ít nhất ba tính năng, hai hệ thống bị ảnh hưởng (thanh toán và phân quyền truy cập) và một nhu cầu báo cáo cho Sales.

Bước 2: Bộ câu hỏi làm rõ

Mỗi câu hỏi đi kèm một giả định mặc định, khách chỉ cần xác nhận hoặc sửa.

Câu hỏi làm rõChín câu, một vòng trả lời

7/9

• Nhắc trước bao nhiêu ngày, mấy lần?Khách sửa: thêm mốc 3 ngày, thành 7, 3 và 1 ngàyQ1
• Email, trong ứng dụng, hay cả hai?Giả định: cả haiQ2
• Chỉ chủ tài khoản hay cả quản trị phụ?Giả định: chủ tài khoản và quản trị thanh toánQ3
• Quá hạn thì khoá ngay hay có ân hạn?Giả định: ân hạn 7 ngày, chỉ cảnh báoQ4
• Khoá toàn bộ hay chỉ tính năng trả phí?Khách sửa: chỉ đọc, và khoá thêm quyền gọi APIQ5
• Tài khoản đang quá hạn lúc phát hành?Giả định: tính ân hạn từ ngày phát hànhQ6
• Quản trị nội bộ có được gia hạn tay?Giả định: có, phải ghi logQ7
• "Hết hạn" tính theo múi giờ nào?Giả định: múi giờ của tài khoảnQ8
• Sales xem ở đâu, cột gì, bao lâu một lần?Giả định: danh sách trong CRM, cập nhật hằng ngàyQ9

Bước 3: Đánh giá ảnh hưởng và business rules

Trước khi thiết kế, tôi đọc codebase và database dev để biết thành phần nào bị ảnh hưởng.

Đánh giá ảnh hưởngNăm thành phần sẵn có bị chạm tới

Business rules được khách duyệt bằng văn bản trước khi vẽ luồng. Ba quy tắc đầu nằm trên cùng một trục thời gian:

BR-01 đến BR-03Một gói, từ lúc sắp hết hạn đến lúc chỉ đọc

Ân hạn 7 ngày · cảnh báo mỗi lần đăng nhập

T−7nhắc lần 1T−3nhắc lần 2T−1nhắc lần 3T0hết hạnT+7chỉ đọc, API trả 402

T−8T+9

1. T−7nhắc lần 1
2. T−3nhắc lần 2
3. T−1nhắc lần 3
4. T0hết hạn
5. T+7chỉ đọc, API trả 402
6. Ân hạn 7 ngày · cảnh báo mỗi lần đăng nhập

Business rulesKhách duyệt bằng văn bản

7/7

• Nhắc gia hạn 7, 3 và 1 ngày trước hạnBR-01
• Ân hạn 7 ngày, cảnh báo mỗi lần đăng nhậpBR-02
• Hết ân hạn: chỉ đọc, API bị từ chối với mã 402BR-03
• Thanh toán thành công thì hoạt động lại trong 5 phútBR-04
• Quản trị gia hạn tay tối đa 30 ngày, bắt buộc lý do, có logBR-05
• Tài khoản đã quá hạn trước phát hành: ân hạn từ ngày phát hànhBR-06
• "Sắp rời bỏ": sắp hết hạn hoặc đang ân hạn, 30 ngày không thanh toánBR-07

Bước 4: Vòng đời trạng thái, user story và ticket

Trạng thái của một gói

1. 1Active
2. 2Expiringcòn 7 ngày
3. 3Graceân hạn 7 ngày
4. 4Suspendedchỉ đọc

Suspended → Active · thanh toán thành công ở bất kỳ trạng thái nào, mở lại trong 5 phút (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

JiraMột Epic, bốn Story, chia theo sức chứa sprint

	Sprint này	Sprint sau
US-01 · Nhắc gia hạn qua email và trong ứng dụng	Làm
US-02 · Ân hạn và chế độ chỉ đọc	Làm
US-03 · Quản trị gia hạn tay, có log		Làm
US-04 · Danh sách "sắp rời bỏ" đồng bộ CRM		Làm

Bước 5: Kiểm thử và UAT

Test case viết từ acceptance criteria. Agent chạy trước các case tự động hoá được; tôi tự xác minh case lỗi và các case liên quan tới webhook.

Test caseTrích bảng kiểm thử

	Cách chạy	Kết quả
TC-01 · Còn 7 ngày: nhận email và thông báo đúng nội dung	Agent	Đạt
TC-02 · Múi giờ khác: nhắc đúng ngày địa phương	Agent	Lỗi: tác vụ chạy theo giờ UTC
TC-04 · Bị khoá: ghi trả 402, đọc trả 200	Agent, API	Đạt
TC-05 · Thanh toán khi bị khoá: mở lại trong 5 phút	Thủ công	Đạt
TC-06 · Webhook thanh toán đến hai lần	Thủ công	Lỗi: gia hạn gấp đôi

UAT

1. 1Checklist UATbám BR-01 đến BR-07
2. 2Khách chạy trên stagingngay trong buổi họp
3. 3Ký nhận qua ticket

Kết quả

Từ email đến nghiệm thu

1. 11 emailba dòng
2. 29 câu hỏimột vòng trả lời
3. 37 business rulekhách duyệt
4. 41 Epic, 4 Storycó acceptance criteria
5. 5Test case và UATký nhận

• Cách làm rõ bằng “câu hỏi kèm giả định mặc định” được dùng lại cho các yêu cầu sau.
• Đội phát triển nhận ticket đã đủ điều kiện, không phải chờ hỏi lại qua múi giờ.

Điều tôi học được

• Với khách lệch múi giờ, chất lượng câu hỏi quyết định tốc độ sprint nhiều hơn tốc độ viết code.
• Đọc database dev trước khi thiết kế giúp phản biện yêu cầu bằng số liệu.
• Acceptance criteria không bao giờ liệt kê hết. BA cần tự bổ sung các test dựa trên hiểu biết về hệ thống.