101 lines
11 KiB
Markdown
101 lines
11 KiB
Markdown
# RISK — Sổ rủi ro & giả định — Module Giỏ hàng & Checkout (e-commerce)
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Version** | 1.0 |
|
||
| **Date** | 2026-09-08 |
|
||
| **Author** | BA (qua skill ba-1-discovery) |
|
||
| **Status** | 🟡 Draft |
|
||
| **Approved by** | — |
|
||
| **Profile** | screen · greenfield · standard |
|
||
| **Source** | `e-commerce/docs/00-project-brief.md` · `e-commerce/docs/sections/01-tong-quan.md` · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` · `e-commerce/docs/sections/07-giao-dien.md` (bối cảnh UI SCR-04…07) · `ELICITATION_CartCheckout_2026-09-08.md` |
|
||
| **Scope** | Module Giỏ hàng & Checkout (FR-05, FR-06, FR-07) — dự án e-commerce |
|
||
|
||
## Change Log
|
||
|
||
| Version | Date | Người sửa | Thay đổi | CR |
|
||
|---|---|---|---|---|
|
||
| 1.0 | 2026-09-08 | BA (qua skill ba-1-discovery) | Bản đầu | — |
|
||
|
||
---
|
||
|
||
## 1. Giả định (`ASM-nn`)
|
||
|
||
| ID | Giả định | Ai/cái gì làm nó đúng | Cách xác minh | Hạn xác minh | Hệ quả nếu sai | Trạng thái |
|
||
|---|---|---|---|---|---|---|
|
||
| ASM-01 | VNPay/Momo hỗ trợ webhook xác nhận thanh toán gần thời gian thực (không phải chỉ polling chậm) | Cổng thanh toán bên thứ ba | Đọc tài liệu tích hợp VNPay/Momo, gọi thử sandbox | Trước GĐ2 kết thúc (trước khi chốt `PROCESS`/`BR` thanh toán) | SCR-07 (xác nhận đơn) phải đổi từ "chờ webhook" sang polling định kỳ, tăng độ trễ cảm nhận, ảnh hưởng NFR-01 | ☐ Chưa xác minh |
|
||
| ASM-02 | GHN/GHTK cung cấp API tính phí vận chuyển & kiểm tra vùng phục vụ theo địa chỉ tại thời điểm checkout | Đơn vị vận chuyển bên thứ ba | Đọc tài liệu API GHN/GHTK; xác nhận với Trưởng vận hành (STK-05) | Trước GĐ2 kết thúc | Không hiển thị được phí/thời gian giao theo từng seller lúc checkout → phải chuyển sang ước tính tĩnh hoặc tính sau, ảnh hưởng trải nghiệm và RQ liên quan tách đơn | ☐ Chưa xác minh |
|
||
| ASM-03 | Giỏ hàng có N seller sẽ luôn tách thành đúng N đơn con — không có trường hợp gộp 2 seller vào 1 đơn con | FR-06 đã mô tả rõ cơ chế này ở mức khái niệm | Xác nhận lại với PO sàn (STK-01) khi làm `BR` ở GĐ2 — chưa có ngoại lệ nào được nêu | Trước khi chốt `BR` ở GĐ2 | Nếu có ngoại lệ (VD gộp đơn cùng kho vận), toàn bộ luồng tách đơn và tính phí ship phải thiết kế lại | ☐ Chưa xác minh |
|
||
| ASM-04 | Seller (STK-03) sẽ nhận được thông báo về đơn con mới ngay sau khi checkout thành công, dù việc gửi thông báo thuộc FR-12/FR-19 (ngoài phạm vi module này) | Phụ thuộc module Quản lý đơn hàng (seller) và Thông báo — chưa xác nhận SLA bàn giao dữ liệu giữa hai module | Xác nhận điểm nối dữ liệu (event/queue) với Tech Lead (STK-06) ở GĐ2 | Trước khi chốt `IMPACT` ở GĐ2 | Seller không biết có đơn mới kịp thời → chậm xử lý, ảnh hưởng SLA giao hàng | ☐ Chưa xác minh |
|
||
| ASM-05 | COD không có giới hạn giá trị đơn hàng tối đa ở MVP (không có business rule chặn) | Suy ra từ việc brief không đề cập giới hạn COD | Hỏi PO sàn (STK-01) và Kế toán đối soát (STK-04) — xem `OQ-006` | Trước khi chốt `BR` thanh toán ở GĐ2 | Nếu sai (cần giới hạn) → thiếu một business rule quan trọng, phát hiện muộn có thể lộ ở UAT hoặc sau go-live dưới dạng rủi ro tài chính thật (RISK-01) | ☐ Chưa xác minh |
|
||
| ASM-06 | Giá/tồn kho hiển thị trong giỏ hàng đủ đồng bộ với catalog để phát hiện thay đổi giữa lúc thêm giỏ và lúc checkout (không có cache trễ đáng kể) | Kiến trúc dữ liệu catalog (chưa thiết kế — thuộc GĐ2/GĐ3) | Xác nhận với Tech Lead (STK-06) khi có kiến trúc sơ bộ | Trước GĐ3 (SRS) | Nếu cache trễ, khách có thể thanh toán với giá/tồn kho sai → tranh chấp, phải bổ sung cơ chế khoá giá/tồn kho tạm thời (reservation) | ☐ Chưa xác minh |
|
||
|
||
**Bốn chỗ giả định hay ẩn nấp — đã rà theo checklist chuẩn:**
|
||
|
||
| Chỗ | Giả định điển hình trong module này | Trạng thái rà soát |
|
||
|---|---|---|
|
||
| **Dữ liệu** | ASM-06 (đồng bộ giá/tồn kho) | Đã ghi, chưa xác minh |
|
||
| **Tích hợp** | ASM-01 (webhook VNPay/Momo), ASM-02 (API GHN/GHTK) | Đã ghi, chưa xác minh |
|
||
| **Con người** | ASM-04 (seller được thông báo kịp thời) | Đã ghi, chưa xác minh |
|
||
| **Pháp lý** | Không có ASM riêng cho PII ở đây — xem `RISK-03` (chưa có đại diện Pháp chế để hỏi, `OQ-003` ở `STAKEHOLDER_CartCheckout_v1.0.md`) | Chưa có người trả lời được |
|
||
|
||
🔴 ASM-05 có hệ quả nếu sai ở mức **Cao** (rủi ro tài chính thật) → đã nâng thành `RISK-01`
|
||
bên dưới và cần xác minh **ngay trong GĐ1/đầu GĐ2**, không để tới UAT.
|
||
|
||
## 2. Rủi ro (`RISK-nn`)
|
||
|
||
| ID | Mô tả rủi ro | Loại | Khả năng | Tác động | Mức | Người chịu trách nhiệm | Phương án ứng phó | Dấu hiệu sớm | Trạng thái |
|
||
|---|---|---|---|---|---|---|---|---|---|
|
||
| RISK-01 | Vì một giỏ hàng đa seller được tách thành nhiều đơn con COD độc lập (FR-06) và MVP theo giả định (`ASM-05`) chưa có giới hạn giá trị/số lượng đơn COD, có thể xảy ra tình trạng khách nhận một phần đơn (VD chỉ nhận đơn của seller A, từ chối đơn seller B), dẫn tới seller B chịu phí vận chuyển hoàn hàng và phát sinh tranh chấp seller–sàn hàng loạt khi quy mô giao dịch lớn (brief xác nhận quy mô "lớn", hàng trăm nghìn user). | Nghiệp vụ / Tài chính | Cao | Cao | 🔴 | STK-01 (PO sàn) — *chưa có tên thật, `OQ-001`* | BA đề xuất 2 phương án cho PO chọn: (a) giới hạn giá trị tối đa cho đơn COD đa seller; (b) yêu cầu xác thực OTP/đặt cọc cho đơn giá trị cao. **Đây là đề xuất, PO phải chọn (W8)** | Tỷ lệ đơn con bị từ chối một phần tăng bất thường theo dữ liệu vận hành sau go-live | Mở |
|
||
| RISK-02 | Vì VNPay/Momo là bên thứ ba và cơ chế xác nhận qua webhook chưa được xác minh (`ASM-01`), có thể xảy ra tình trạng khách đã bị trừ tiền nhưng hệ thống không nhận được xác nhận trong thời gian chờ ở màn hình xác nhận đơn hàng (SCR-07, bối cảnh UI), dẫn tới đơn hàng kẹt ở trạng thái "Chờ thanh toán" dù tiền đã được cổng thanh toán ghi nhận, gây khiếu nại CSKH và tranh chấp đối soát với STK-04. | Tích hợp | Trung bình | Cao | 🔴 | STK-06 (Tech Lead) + STK-01 (PO sàn) | BA đề xuất: có cơ chế đối soát bù (reconciliation job) định kỳ đối chiếu trạng thái giao dịch với cổng thanh toán, không chỉ dựa vào webhook một lần. **Cần Tech Lead xác nhận khả thi** | Số lượng đơn "Chờ thanh toán" quá 15 phút tăng bất thường | Mở |
|
||
| RISK-03 | Vì dự án chưa có đại diện Pháp chế/Bảo mật được chỉ định (xem `STAKEHOLDER_CartCheckout_v1.0.md` mục 3), có thể xảy ra việc module Giỏ hàng & Checkout thu thập/chia sẻ dữ liệu địa chỉ giao hàng và số điện thoại người nhận cho từng seller (khi tách đơn) mà chưa được rà soát theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân, dẫn tới rủi ro vi phạm quy định khi go-live. | Tuân thủ | Trung bình | Cao | 🔴 | *(Chưa có người — `OQ-003`)* | BA đề xuất: PO chỉ định người phụ trách pháp chế/bảo mật trước khi kết thúc GĐ2; BA chuẩn bị danh sách trường dữ liệu PII được chia sẻ cho seller để người đó rà soát | Chưa có ai được hỏi về việc này tính tới thời điểm chốt G1 | Mở |
|
||
| RISK-04 | Vì checkout phải tính phí vận chuyển riêng cho từng đơn con theo seller (FR-06, tích hợp GHN/GHTK — `ASM-02`), tổng phí vận chuyển của một giỏ hàng nhiều seller có thể cao hơn đáng kể so với mua từ một seller duy nhất, dẫn tới khách bỏ giỏ hàng ở bước checkout (ảnh hưởng trực tiếp tới GOAL-01/GOAL-02 ở `BRIEF`). | Nghiệp vụ | Trung bình | Trung bình | 🟠 | STK-01 (PO sàn) | BA đề xuất PO cân nhắc chính sách trợ giá/miễn phí ship theo ngưỡng đơn hàng — **đề xuất, PO quyết, chưa phải chốt** | Tỷ lệ bỏ giỏ hàng ở bước checkout cao hơn ở bước giỏ hàng, đặc biệt với giỏ có ≥2 seller | Mở |
|
||
|
||
**Ma trận mức:**
|
||
|
||
| Tác động ↓ · Khả năng → | Thấp | Trung bình | Cao |
|
||
|---|---|---|---|
|
||
| **Cao** | 🟠 | 🔴 RISK-02, RISK-03 | 🔴 RISK-01 |
|
||
| **Trung bình** | 🟢 | 🟠 RISK-04 | 🔴 |
|
||
| **Thấp** | 🟢 | 🟢 | 🟠 |
|
||
|
||
🔴 RISK-01, RISK-02, RISK-03 phải có phương án ứng phó và người chịu trách nhiệm **thật** (không
|
||
phải placeholder vai trò) trước khi qua G2 — báo PM.
|
||
|
||
**Loại rủi ro — đã rà đủ 6 loại:**
|
||
|
||
| Loại | Rà cho module này |
|
||
|---|---|
|
||
| Nghiệp vụ | RISK-01, RISK-04 |
|
||
| Dữ liệu | Chưa phát hiện rủi ro riêng — theo dõi qua `ASM-06` |
|
||
| Tích hợp | RISK-02 |
|
||
| Con người | Chưa phát hiện rủi ro riêng cho module này — theo dõi qua `ASM-04` |
|
||
| Tuân thủ | RISK-03 |
|
||
| Tổ chức | Chưa phát hiện — vì chưa có buổi làm việc thật để lộ mâu thuẫn (xem `STAKEHOLDER` mục 6) |
|
||
|
||
## 3. Phụ thuộc bên ngoài
|
||
|
||
| # | Phụ thuộc vào | Bên nào | Cần trước ngày | Nếu trễ thì sao | Đầu mối | Trạng thái |
|
||
|---|---|---|---|---|---|---|
|
||
| 1 | Tài liệu API + tài khoản sandbox VNPay | VNPay | Trước khi bắt đầu GĐ3 (SRS thanh toán) | Không xác minh được ASM-01, chặn thiết kế luồng xác nhận thanh toán | Chưa xác định | Mở |
|
||
| 2 | Tài liệu API + tài khoản sandbox Momo | Momo | Trước khi bắt đầu GĐ3 | Tương tự trên | Chưa xác định | Mở |
|
||
| 3 | Tài liệu API + tài khoản tích hợp GHN | GHN | Trước khi bắt đầu GĐ3 (SRS checkout, tính phí ship) | Không xác minh được ASM-02, phải dùng ước tính tĩnh tạm thời | Chưa xác định | Mở |
|
||
| 4 | Tài liệu API + tài khoản tích hợp GHTK | GHTK | Trước khi bắt đầu GĐ3 | Tương tự trên | Chưa xác định | Mở |
|
||
|
||
## 4. Rủi ro đã đóng
|
||
|
||
*Chưa có — dự án mới bắt đầu GĐ1.*
|
||
|
||
| ID | Rủi ro | Ngày đóng | Kết cục | Bài học |
|
||
|---|---|---|---|---|
|
||
|
||
## 5. Lịch rà soát
|
||
|
||
| Mốc | Việc |
|
||
|---|---|
|
||
| Trước khi ký G1 | Rà lại RISK-01, RISK-02, RISK-03 với người chịu trách nhiệm thật (không phải vai trò placeholder) |
|
||
| GĐ2 bắt đầu | ASM-03, ASM-04, ASM-05 phải chuyển sang "đã xác minh" trước khi chốt `BR` |
|
||
| GĐ3 bắt đầu | ASM-01, ASM-02, ASM-06 phải chuyển sang "đã xác minh" hoặc thành `RISK` chính thức |
|
||
| GĐ4 UAT | Rà lại RISK-01 (COD) và RISK-02 (webhook) — đây là lúc chúng dễ hiện hình nhất |
|
||
| GĐ5 | Chuyển bài học vào `BENEFIT` |
|