279 lines
26 KiB
Markdown
279 lines
26 KiB
Markdown
# BRIEF — 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 (xem `00-index/PROFILE_e-commerce.md`) |
|
||
| **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` (FR-05, FR-06, FR-07, NFR-01, NFR-03, NFR-05) · `e-commerce/docs/sections/07-giao-dien.md` (SCR-04…SCR-07, chỉ dùng làm bối cảnh) · `STAKEHOLDER_CartCheckout_v1.0.md` · `ELICITATION_CartCheckout_2026-09-08.md` · `RISK_CartCheckout_v1.0.md` |
|
||
| **Scope** | Module Giỏ hàng & Checkout — FR-05 (Giỏ hàng đa seller), FR-06 (Checkout & tách đơn theo seller), FR-07 (Thanh toán VNPay/Momo/COD) — dự án e-commerce (marketplace). **Không** bao gồm toàn sàn. |
|
||
|
||
## 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. Tóm tắt cho người quyết định
|
||
|
||
Sàn marketplace đa seller sắp xây (dự án e-commerce) cần một luồng giỏ hàng–checkout–thanh
|
||
toán xử lý đúng đặc thù đa người bán: một khách mua từ nhiều seller trong một lần thanh toán,
|
||
hệ thống tự tách thành các đơn con theo seller, thanh toán qua VNPay/Momo/COD. Đây là luồng
|
||
giao dịch lõi — không có nó, sàn không ghi nhận được doanh thu và seller không nhận được đơn.
|
||
Tài liệu này chốt phạm vi, mục tiêu đo được và bốn yêu cầu mức nghiệp vụ (`RQ-001`…`RQ-004`)
|
||
cho module này; còn nhiều `OQ` cần PO/Tech Lead trả lời trước khi ký G1 chính thức (tên thật
|
||
stakeholder, KPI baseline, chính sách giới hạn COD).
|
||
|
||
---
|
||
|
||
## 2. Bối cảnh
|
||
|
||
Dự án e-commerce là **greenfield** — chưa có hệ thống nào đang chạy để thay thế (xem
|
||
`00-index/PROFILE_e-commerce.md`). Vì vậy không có "cách làm thủ công hiện tại" của chính sàn
|
||
này để mô tả; bối cảnh dưới đây là **quyết định mô hình kinh doanh đã chốt**, không phải số đo
|
||
vận hành thật.
|
||
|
||
| Thông tin hiện trạng | Giá trị | Nguồn |
|
||
|---|---|---|
|
||
| Số giao dịch/ngày (dự kiến khi vận hành) | Chưa vận hành — quy mô mục tiêu "lớn": hàng trăm nghìn SKU, hàng trăm nghìn–hàng triệu user đăng ký, cao điểm hàng nghìn–chục nghìn concurrent user mùa flash sale | `00-project-brief.md` mục 3 |
|
||
| Số người thao tác checkout đồng thời | N/A — chưa vận hành | — |
|
||
| Thời gian xử lý trung bình | N/A — chưa vận hành; mục tiêu latency đề xuất ở NFR-01 (< 2s catalog/search, < 3s checkout) là **giả định mặc định đã chốt trong brief**, chưa phải SLA hợp đồng thật | `sections/02-phan-tich-yeu-cau.md` NFR-01, ghi chú cuối §2.2 |
|
||
| Tỷ lệ sai sót hiện tại | N/A — chưa vận hành, không có hệ thống cũ | — |
|
||
|
||
## 3. Phát biểu bài toán
|
||
|
||
> **Vấn đề:** Sàn marketplace đa seller đã cam kết mô hình "khách mua từ nhiều seller trong một
|
||
> trải nghiệm thống nhất" (mục tiêu dự án, `sections/01-tong-quan.md` §1.1) nhưng **chưa có**
|
||
> luồng giỏ hàng–checkout–thanh toán nào xử lý được việc: (1) gộp sản phẩm nhiều seller vào một
|
||
> giỏ, (2) tách thành đơn con đúng theo từng seller khi khách xác nhận mua, (3) thu tiền qua
|
||
> nhiều kênh thanh toán phổ biến tại Việt Nam (VNPay, Momo, COD) mà không lưu thông tin thẻ.
|
||
> Thiếu luồng này, sàn không thể ra mắt MVP, seller không có cách nào nhận đơn hàng, và không
|
||
> có dữ liệu giao dịch để tính hoa hồng/payout ở các module khác.
|
||
|
||
❌ Không viết giải pháp ở đây — mục này giữ đúng quy tắc, không nêu tên màn hình/nút cụ thể.
|
||
|
||
**Bằng chứng của vấn đề:**
|
||
|
||
| # | Bằng chứng | Nguồn | Loại |
|
||
|---|---|---|---|
|
||
| 1 | Mô hình kinh doanh đã xác nhận là marketplace đa seller (không phải single-vendor) — kéo theo yêu cầu bắt buộc về giỏ hàng/checkout đa seller | `00-project-brief.md` vòng 1, câu hỏi 1 | Sự thật (quyết định đã chốt) |
|
||
| 2 | FR-05 (Giỏ hàng đa người bán), FR-06 (Checkout & tách đơn theo seller), FR-07 (Thanh toán) đều được xếp **Must** trong bảng yêu cầu đã duyệt | `sections/02-phan-tich-yeu-cau.md` §2.1 | Sự thật |
|
||
| 3 | Guest (khách vãng lai) được xác nhận cho phép checkout không cần tài khoản | `sections/01-tong-quan.md` §1.2 | Sự thật |
|
||
|
||
**Điều gì xảy ra nếu không làm gì cả?** Sàn không ra mắt được MVP marketplace — toàn bộ các
|
||
module phụ thuộc (quản lý đơn hàng, hoa hồng, payout, đánh giá sau mua) đều cần dữ liệu đơn
|
||
hàng sinh ra từ checkout. Đây là điều kiện tiên quyết (blocker), không phải một cải tiến.
|
||
|
||
## 4. Mục tiêu kinh doanh & KPI
|
||
|
||
🔴 **Cả hai GOAL dưới đây chưa có baseline số thật** vì dự án greenfield (chưa vận hành). Theo
|
||
quy tắc, không bỏ trống — ghi `OQ` kèm đề xuất cách đo baseline.
|
||
|
||
| ID | Mục tiêu | Baseline hiện tại | Mục tiêu | Cách đo | Ai đo | Tần suất |
|
||
|---|---|---|---|---|---|---|
|
||
| GOAL-01 | Giảm tỷ lệ bỏ giỏ hàng ở bước checkout đối với giỏ hàng có ≥2 seller (rủi ro cao hơn giỏ 1 seller do phí ship gộp — xem `RISK-04`) | ❓ Chưa có — dự án chưa vận hành (`OQ-007`). Đề xuất cách đo: theo dõi tỷ lệ hoàn tất checkout trong 4–6 tuần đầu soft-launch, tách riêng theo số seller trong giỏ | PO xác nhận sau khi có số đo soft-launch, đề xuất ban đầu ≤ tỷ lệ bỏ giỏ của giỏ 1 seller + 10 điểm phần trăm | (số phiên checkout hoàn tất) / (số phiên bắt đầu checkout), theo nhóm số seller trong giỏ | BA + PO, hàng tuần trong 6 tuần đầu | Hàng tuần (giai đoạn đầu) |
|
||
| GOAL-02 | Tỷ lệ thanh toán thành công trên tổng số phiên checkout đã chọn phương thức thanh toán | ❓ Chưa có — chưa vận hành (`OQ-007`). Đề xuất đo baseline bằng dữ liệu 4 tuần đầu sau go-live, tách riêng theo kênh VNPay/Momo/COD | PO xác nhận; đề xuất tham khảo ngành ≥ 90% cho ví điện tử, COD không tính "thất bại" theo nghĩa kỹ thuật mà theo tỷ lệ hoàn/từ chối nhận hàng (liên quan `RISK-01`) | (số giao dịch thanh toán thành công) / (số giao dịch đã khởi tạo), theo kênh | BA + Kế toán đối soát (STK-04), hàng tuần | Hàng tuần (giai đoạn đầu), sau đó hàng tháng |
|
||
|
||
## 5. Phạm vi
|
||
|
||
### 5.1 Trong phạm vi
|
||
|
||
| # | Hạng mục | Vì sao cần | RQ liên quan |
|
||
|---|---|---|---|
|
||
| 1 | Giỏ hàng chứa sản phẩm từ nhiều seller khác nhau, nhóm hiển thị theo seller | Điều kiện tiên quyết của mô hình marketplace đa seller | RQ-001 |
|
||
| 2 | Checkout: thu thập địa chỉ giao hàng, tự động tách giỏ hàng thành các đơn con theo từng seller | Mỗi seller cần xử lý đơn độc lập, không lẫn với seller khác | RQ-002 |
|
||
| 3 | Thanh toán qua VNPay, Momo hoặc COD, không lưu thông tin thẻ trên hệ thống sàn | Đối tác thanh toán đã xác nhận; giảm phạm vi PCI-DSS (NFR-05) | RQ-003 |
|
||
| 4 | Guest checkout — mua hàng không cần tạo tài khoản trước | Đã xác nhận trong `sections/01-tong-quan.md` §1.2 | RQ-004 |
|
||
|
||
### 5.2 Ngoài phạm vi *(quan trọng hơn mục 5.1)*
|
||
|
||
| # | Hạng mục | Lý do loại | Xử lý ở đâu / khi nào |
|
||
|---|---|---|---|
|
||
| 1 | Áp mã khuyến mãi/coupon (FR-13) | Được giao ở một module khác (Khuyến mãi), dù xuất hiện trên cùng màn hình checkout theo bối cảnh UI ở `sections/07-giao-dien.md` SCR-05 | Module Khuyến mãi & Loyalty — cần PO xác nhận điểm nối, xem `OQ-004` |
|
||
| 2 | Dùng điểm thưởng loyalty khi checkout (FR-14) | Tương tự trên | Module Loyalty — `OQ-004` |
|
||
| 3 | Theo dõi/xử lý đơn hàng sau khi đã tạo (huỷ, đổi trả, khiếu nại — FR-08, FR-09, FR-25) | Là vòng đời đơn hàng sau checkout, không phải hành vi tạo đơn | GĐ1/GĐ2 của module Quản lý đơn hàng, chạy riêng |
|
||
| 4 | Xử lý tồn kho, đóng gói, cập nhật vận chuyển sau khi đơn được tạo (FR-26) | Thuộc vận hành kho, không phải luồng giỏ hàng/checkout | Module Vận hành đơn hàng, chạy riêng |
|
||
| 5 | KYC, cấu hình hoa hồng, payout cho seller (FR-17, FR-21, FR-22) | Không liên quan trực tiếp tới hành vi giỏ hàng/checkout của khách mua | Module Quản trị Seller & Tài chính, chạy riêng |
|
||
| 6 | Danh mục & tìm kiếm sản phẩm (FR-04) | Là bước trước giỏ hàng, đã có màn hình riêng (SCR-01…SCR-03) | Module Catalog & Tìm kiếm, chạy riêng |
|
||
| 7 | Nội dung/mẫu thông báo email/SMS xác nhận đơn hàng (FR-12) | Module này chỉ **kích hoạt** sự kiện gửi thông báo, không thiết kế nội dung/kênh gửi | Module Thông báo, chạy riêng — GĐ3 chỉ ghi rõ sự kiện trigger |
|
||
|
||
### 5.3 Ranh giới hệ thống
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
GUEST(["👤 Guest"])
|
||
CUS(["👤 Customer"])
|
||
|
||
subgraph PHAMVI["Trong phạm vi — Module Giỏ hàng & Checkout"]
|
||
CART["Giỏ hàng đa seller (FR-05)"]
|
||
CHK["Checkout & tách đơn theo seller (FR-06)"]
|
||
PAY["Thanh toán VNPay/Momo/COD (FR-07)"]
|
||
end
|
||
|
||
CATALOG[["Catalog & Tìm kiếm (FR-04) — ngoài phạm vi"]]
|
||
PROMO[["Khuyến mãi & Loyalty (FR-13/14) — ngoài phạm vi"]]
|
||
ORDER[["Quản lý đơn hàng sau checkout (FR-08/09) — ngoài phạm vi"]]
|
||
SELLERBIZ[["KYC / Hoa hồng / Payout seller (FR-17/21/22) — ngoài phạm vi"]]
|
||
NOTI[["Thông báo email/SMS (FR-12) — ngoài phạm vi"]]
|
||
VNPAY[["VNPay"]]
|
||
MOMO[["Momo"]]
|
||
GHN[["GHN"]]
|
||
GHTK[["GHTK"]]
|
||
|
||
GUEST --> CART
|
||
CUS --> CART
|
||
CATALOG --> CART
|
||
CART --> CHK
|
||
PROMO -.-> CHK
|
||
CHK --> GHN
|
||
CHK --> GHTK
|
||
CHK --> PAY
|
||
PAY <--> VNPAY
|
||
PAY <--> MOMO
|
||
CHK --> ORDER
|
||
CHK --> SELLERBIZ
|
||
CHK --> NOTI
|
||
```
|
||
|
||
*Khung đôi `[[ ]]` = ngoài phạm vi module này (có thể trong phạm vi dự án e-commerce nói
|
||
chung, chạy ở module khác). Mũi tên hai chiều = trao đổi dữ liệu hai chiều với hệ thống ngoài.*
|
||
|
||
| Hệ thống | Trong/Ngoài phạm vi | Dữ liệu trao đổi | Chiều | Đầu mối |
|
||
|---|---|---|---|---|
|
||
| VNPay | Ngoài — tích hợp | Yêu cầu thanh toán, xác nhận kết quả (webhook — `ASM-01` chưa xác minh) | Hai chiều | Chưa xác định |
|
||
| Momo | Ngoài — tích hợp | Tương tự VNPay | Hai chiều | Chưa xác định |
|
||
| GHN | Ngoài — tích hợp | Địa chỉ giao hàng → phí ship/thời gian giao ước tính (`ASM-02` chưa xác minh) | Hai chiều | Chưa xác định |
|
||
| GHTK | Ngoài — tích hợp | Tương tự GHN | Hai chiều | Chưa xác định |
|
||
| Catalog & Tìm kiếm | Ngoài phạm vi module, trong phạm vi dự án | Sản phẩm, giá, tồn kho → giỏ hàng | Một chiều vào giỏ hàng | STK-06 (Tech Lead) |
|
||
| Khuyến mãi & Loyalty | Ngoài phạm vi module — điểm nối cần xác nhận (`OQ-004`) | Mã coupon/điểm thưởng → giảm giá áp vào checkout | Một chiều vào checkout | STK-01 (PO sàn) |
|
||
| Quản lý đơn hàng sau checkout | Ngoài phạm vi module, trong phạm vi dự án | Đơn con đã tạo → module quản lý đơn hàng | Một chiều ra khỏi module | STK-05 (Trưởng vận hành) |
|
||
| KYC/Hoa hồng/Payout seller | Ngoài phạm vi module | Dữ liệu giao dịch đã thanh toán → tính hoa hồng/payout | Một chiều ra khỏi module | STK-04 (Kế toán đối soát) |
|
||
| Thông báo email/SMS | Ngoài phạm vi module | Sự kiện "đơn đã tạo/thanh toán thành công" → trigger gửi | Một chiều ra khỏi module | Chưa xác định |
|
||
|
||
## 6. Yêu cầu mức nghiệp vụ
|
||
|
||
| ID | Phát biểu yêu cầu | Nguồn (STK + ngày) | MoSCoW | GOAL | Giải pháp khách gợi ý |
|
||
|---|---|---|---|---|---|
|
||
| RQ-001 | Customer/Guest phải mua được sản phẩm từ nhiều seller khác nhau trong một giỏ hàng và hoàn tất bằng một lần checkout, thay vì phải đặt hàng riêng lẻ với từng seller trên các trang/luồng khác nhau. | STK-01 (PO sàn), qua `00-project-brief.md` vòng 1 (2026, vòng 1 không ghi ngày cụ thể) | Must | GOAL-01 | "Giỏ hàng đa seller" |
|
||
| RQ-002 | Hệ thống phải tự động tách một giỏ hàng đa seller thành các đơn con riêng theo từng seller ngay khi Customer/Guest xác nhận đặt hàng, để mỗi seller xử lý đơn của mình độc lập mà không thấy dữ liệu của seller khác. | STK-01 (PO sàn), STK-03 (Seller đại diện — chưa phỏng vấn trực tiếp), qua `00-project-brief.md` mục 2 & `sections/02-phan-tich-yeu-cau.md` FR-06 | Must | GOAL-01 | "tách đơn theo seller" |
|
||
| RQ-003 | Customer/Guest phải thanh toán được bằng VNPay, Momo hoặc COD mà hệ thống sàn không lưu trữ thông tin thẻ thanh toán, để giảm phạm vi tuân thủ PCI-DSS. | STK-01 (PO sàn), STK-06 (Tech Lead — chưa xác nhận khả thi), qua `00-project-brief.md` vòng 1 & `sections/02-phan-tich-yeu-cau.md` NFR-05 | Must | GOAL-02 | "Thanh toán (VNPay/Momo + COD)" |
|
||
| RQ-004 | Guest (khách vãng lai) phải checkout hoàn tất được mà không cần tạo tài khoản trước, để không mất khách hàng tiềm năng ở bước bắt buộc đăng ký. | STK-01 (PO sàn), qua `sections/01-tong-quan.md` §1.2 | Must | GOAL-01 | "guest checkout" |
|
||
|
||
🔴 **Kiểm tra phân bổ MoSCoW:** cả 4/4 RQ đều Must = 100% > ngưỡng 60%. Theo quy tắc, đây là
|
||
dấu hiệu "chưa phân loại thật" và cần hỏi PO câu "nếu chỉ kịp một nửa module này thì cắt cái
|
||
nào". Trong trường hợp này, mức Must khớp với xếp hạng đã có sẵn ở `FR-05/06/07` trong tài
|
||
liệu phân tích yêu cầu đã duyệt (`sections/02-phan-tich-yeu-cau.md`), với lý do hợp lý là cả 4
|
||
RQ đều thuộc luồng giao dịch lõi không thể MVP thiếu. Tuy vậy, **BA chưa tự ý coi đây là đã
|
||
chốt** — ghi `OQ-008` để PO xác nhận lại đúng theo quy trình BA-1, không suy diễn thay PO.
|
||
|
||
| MoSCoW | Nghĩa chính xác |
|
||
|---|---|
|
||
| **Must** | Không có thì bản phát hành này vô nghĩa |
|
||
| **Should** | Quan trọng, nhưng thiếu vẫn dùng được, có cách làm thủ công tạm |
|
||
| **Could** | Có thì tốt, cắt đầu tiên khi thiếu thời gian |
|
||
| **Won't (this time)** | Đã bàn và thống nhất **không** làm lần này |
|
||
|
||
## 7. Ràng buộc
|
||
|
||
| Loại | Nội dung | Nguồn | Ảnh hưởng |
|
||
|---|---|---|---|
|
||
| Thời gian | Ngân sách/thời gian dự án chưa xác định chính thức; giả định lộ trình MVP tiêu chuẩn ~9–12 tháng cho toàn sàn | `00-project-brief.md` mục 5, giả định #7 | Có thể cần cắt phạm vi module nếu timeline thực tế ngắn hơn |
|
||
| Ngân sách / nguồn lực | Chưa xác định | `00-project-brief.md` mục 6 | — |
|
||
| Công nghệ | Triển khai trên AWS; không ràng buộc tech stack cụ thể cho module này | `sections/01-tong-quan.md` §1.5 | Kiến trúc chi tiết thuộc GĐ2/Tech Lead |
|
||
| Pháp lý / tuân thủ | NĐ52/85 (thông báo website TMĐT), NĐ13/2023 (bảo vệ dữ liệu cá nhân — địa chỉ/SĐT trong đơn hàng), PCI-DSS phạm vi giảm (không lưu thẻ) | `sections/01-tong-quan.md` §1.5, NFR-05 | Cần đại diện Pháp chế xác nhận (chưa có — `OQ-003`); ảnh hưởng RQ-003, RISK-03 |
|
||
| Tổ chức / quy trình | Không có hệ thống cũ, không có seller/khách hàng thật để tham chiếu quy trình — mọi giả định phải xác minh trước GĐ2/GĐ3 | `00-project-brief.md` mục 3, mục 6 | Số lượng `ASM` cao hơn bình thường cho một dự án brownfield |
|
||
|
||
## 8. Giả định và rủi ro
|
||
|
||
*Chi tiết đầy đủ ở `RISK_CartCheckout_v1.0.md`. Tóm tắt các mục ảnh hưởng trực tiếp tới phạm
|
||
vi module này:*
|
||
|
||
| ID | Nội dung | Nếu sai thì sao |
|
||
|---|---|---|
|
||
| ASM-01 | VNPay/Momo hỗ trợ webhook xác nhận thanh toán gần thời gian thực | Phải đổi cơ chế xác nhận đơn hàng ở GĐ3, ảnh hưởng NFR-01 |
|
||
| ASM-02 | GHN/GHTK cung cấp API tính phí ship/kiểm tra vùng phục vụ tại checkout | Không hiển thị được phí/thời gian giao theo seller lúc checkout |
|
||
| ASM-05 | COD không giới hạn giá trị đơn ở MVP | Thiếu một business rule quan trọng, có thể lộ ở UAT dưới dạng rủi ro tài chính |
|
||
| RISK-01 | Bùng đơn COD một phần khi giỏ đa seller bị tách nhiều đơn con | Tổn thất phí vận chuyển hoàn hàng cho seller, tranh chấp seller–sàn |
|
||
| RISK-02 | Webhook thanh toán trễ/lỗi khiến đơn kẹt "Chờ thanh toán" dù đã thu tiền | Khiếu nại CSKH, sai lệch đối soát |
|
||
| RISK-03 | Chưa có đại diện Pháp chế/Bảo mật rà soát việc chia sẻ PII cho seller | Rủi ro vi phạm NĐ13/2023 khi go-live |
|
||
|
||
## 9. Tiêu chí thành công của giai đoạn
|
||
|
||
- [ ] PO sàn xác nhận đúng phát biểu bài toán ở mục 3 (không phải giải pháp)
|
||
- [ ] PO sàn chốt lại KPI/baseline ở mục 4 (dù chỉ là cam kết đo baseline trong X tuần đầu, không cần số thật ngay)
|
||
- [ ] PO sàn xác nhận điểm nối với module Khuyến mãi/Loyalty (`OQ-004`) và ranh giới ngoài phạm vi ở mục 5.2
|
||
- [ ] Tech Lead xác nhận sơ bộ tính khả thi của ASM-01, ASM-02 (không cần xác minh đầy đủ ở G1, nhưng phải biết là rủi ro)
|
||
- [ ] RISK-01 (bùng COD) có người chịu trách nhiệm thật và hướng xử lý (chọn 1 trong 2 phương án BA đề xuất, hoặc phương án khác)
|
||
- [ ] Có người đại diện Pháp chế/Bảo mật được chỉ định (`OQ-003`), dù việc rà soát chi tiết có thể làm ở GĐ2
|
||
|
||
## 10. Open Questions
|
||
|
||
*Tổng hợp từ mọi artifact của lần chạy này. Sổ toàn dự án: `00-index/OQ_e-commerce.md`.*
|
||
|
||
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Phương án BA đề xuất |
|
||
|---|---|---|---|---|---|
|
||
| OQ-001 | Tên thật + đầu mối liên lạc của STK-01…STK-06 là gì? | Điều phối dự án / PO | 2026-09-08 | Ký G1 thật | Dùng vai trò tạm để chạy tiếp; phải có tên thật trước khi coi G1 là ký hợp lệ |
|
||
| OQ-002 | Mức Quan tâm × Ảnh hưởng ở `STAKEHOLDER` mục 2 là đánh giá của BA — từng STK có đồng ý không? | STK-01…STK-06 | 2026-09-08 | Chiến lược tiếp cận | Giữ nguyên đánh giá ban đầu, điều chỉnh khi có phản hồi |
|
||
| OQ-003 | Ai là đại diện Pháp chế/Bảo mật cho dự án? Cần xác nhận phạm vi lưu/chia sẻ PII khi tách đơn theo seller. | PO sàn | 2026-09-08 | RISK-03, RQ-003 | Đề nghị PO chỉ định trước khi kết thúc GĐ2 |
|
||
| OQ-004 | Áp coupon (FR-13) và dùng điểm thưởng (FR-14) trong màn hình checkout có thuộc phạm vi module này không, hay là điểm tích hợp với module khác? | PO sàn | 2026-09-08 | Phạm vi mục 5.1/5.2, thiết kế màn hình checkout ở GĐ3 | Đề xuất: coi là điểm tích hợp (module Khuyến mãi/Loyalty sở hữu logic, module này chỉ hiển thị kết quả) — PO quyết |
|
||
| OQ-005 | Cần tổ chức phỏng vấn thật với Khách hàng đại diện (STK-02) và Seller đại diện (STK-03) — ai làm đầu mối sắp xếp? | Điều phối dự án / PO sàn | 2026-09-08 | Chất lượng RQ, phát hiện ngoại lệ thực tế | Đề nghị lên lịch trong tuần đầu GĐ2 |
|
||
| OQ-006 | Chính sách giới hạn giá trị đơn COD (nếu có) là gì? | PO sàn, Kế toán đối soát | 2026-09-08 | ASM-05, RISK-01, `BR` ở GĐ2 | BA đề xuất 2 phương án ở RISK-01, PO chọn |
|
||
| OQ-007 | Baseline thật cho GOAL-01 (tỷ lệ bỏ giỏ hàng) và GOAL-02 (tỷ lệ thanh toán thành công) là bao nhiêu? | PO sàn | 2026-09-08 | Đo lường hiệu quả ở GĐ5 | Đo trong 4–6 tuần đầu soft-launch theo cách đề xuất ở mục 4 |
|
||
| OQ-008 | Xác nhận lại: cả 4 RQ của module này đều Must — nếu chỉ kịp một nửa thời gian, PO sẽ cắt cái nào? | PO sàn | 2026-09-08 | Ưu tiên hoá ở GĐ2 (`BACKLOG`) | Đề xuất giữ nguyên cả 4 vì đều thuộc luồng giao dịch lõi, nhưng đây là đề xuất — PO quyết |
|
||
|
||
## 11. Ngoài phạm vi tài liệu này
|
||
|
||
- Thiết kế màn hình chi tiết (field, validation, message lỗi) → GĐ3, `SRS`
|
||
- Quy trình AS-IS/TO-BE chi tiết từng bước, business rule đầy đủ (VD công thức tính phí ship gộp) → GĐ2, `PROCESS`/`BR`
|
||
- Ước lượng công sức, lịch trình → PM
|
||
- Thiết kế API/kiến trúc tích hợp VNPay/Momo/GHN/GHTK → GĐ2/GĐ3, Tech Lead
|
||
- Nội dung/mẫu email/SMS thông báo đơn hàng → module Thông báo (FR-12), ngoài phạm vi module này
|
||
|
||
---
|
||
|
||
## Tự chấm
|
||
|
||
**Gate G1** *(chấm ở mức RIGOR = standard — áp đúng checklist §2 của `workflow.md`, không bớt/thêm)*
|
||
|
||
| # | Tiêu chí | ☐/✅ | Ghi chú |
|
||
|---|---|---|---|
|
||
| 1 | BRIEF có bối cảnh, phát biểu bài toán, phạm vi in/out, GOAL kèm KPI | ✅ | Có đủ; GOAL chưa có baseline số thật (greenfield) nhưng đã ghi `OQ-007` + đề xuất cách đo, đúng quy tắc "không bỏ trống" |
|
||
| 2 | STAKEHOLDER đủ 4 nhóm, có tên thật | ☐ | Đủ 4 nhóm (Quyết định/Sử dụng/Bị ảnh hưởng/Cung cấp thông tin) nhưng **chưa có tên thật** cho bất kỳ ai — chỉ có vai trò, chờ `OQ-001`. Thiếu hẳn đại diện Pháp chế/Bảo mật (`OQ-003`) |
|
||
| 3 | ELICITATION có ≥1 buổi với nhóm quyết định và nhóm sử dụng | ☐ | Có bản tổng hợp có nguồn (từ brief 3 vòng), nhưng **không phải buổi làm việc trực tiếp** với STK-02 (Sử dụng) riêng cho module này — xem `ELICITATION` mục 0 và `OQ-005` |
|
||
| 4 | RQ có MoSCoW, truy về được stakeholder cụ thể | ✅ (có lưu ý) | 4/4 RQ có MoSCoW + nguồn, nhưng nguồn là brief cấp dự án (qua STK-01) chứ chưa phải phỏng vấn riêng module; 100% Must đã ghi nhận và tạo `OQ-008` theo đúng quy tắc thay vì tự quyết |
|
||
| 5 | RISK/ASM đã ghi, rủi ro mức cao có người chịu trách nhiệm | ☐ | Đã ghi đủ 6 ASM + 4 RISK (3 mức 🔴); nhưng người chịu trách nhiệm mới là **vai trò**, chưa có tên thật (`OQ-001`), và RISK-03 chưa có người chịu trách nhiệm nào (chưa có đại diện Pháp chế) |
|
||
| 6 | KPI có baseline | ☐ | Cả 2 GOAL đều baseline = ❓ (đúng vì greenfield), đã đề xuất cách đo — chưa phải "có" baseline thật |
|
||
|
||
**Kết luận tự chấm:** G1 **chưa đủ điều kiện ký chính thức** theo đúng nghĩa checklist —
|
||
3/6 tiêu chí còn ☐ do thiếu tên thật stakeholder, thiếu buổi làm việc trực tiếp, và KPI chưa
|
||
có baseline số. Đây là kết quả **đúng như thiết kế của GĐ1 chạy chế độ `go` không phỏng vấn
|
||
thật**: sản phẩm là một bộ khung đầy đủ cấu trúc + danh sách việc cụ thể cần làm trước khi PO
|
||
ký thật. Không tự đánh ✅ cho có.
|
||
|
||
**Quy tắc viết W1–W13**
|
||
|
||
| W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | W11 | W12 | W13 |
|
||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||
| ✅ | ✅ | ✅ | N/A (GĐ1 chưa có luồng lỗi màn hình) | N/A (GĐ1 chưa có text hiển thị) | N/A (GĐ1 chưa có trạng thái thực thể) | N/A (GĐ1 chưa có field/nút) | ✅ | ✅ | ✅ | ✅ | N/A (GĐ1 không có hình wireframe) | ✅ | ✅ |
|
||
|
||
Ghi chú W2: đã quét cụm từ mơ hồ (`nhanh|mượt|thân thiện|v\.v|phù hợp|tương ứng|nên |có thể `)
|
||
trên toàn bộ 4 file GĐ1 — **~15 dòng khớp**, không phải 0. Đã soát lại từng dòng:
|
||
- Phần lớn nằm trong **mô tả rủi ro** (`RISK_CartCheckout_v1.0.md` RISK-01…04), dùng đúng công
|
||
thức bắt buộc của template rủi ro *"có thể xảy ra <sự kiện>, dẫn tới <hậu quả đo được>"* —
|
||
đây là cú pháp chuẩn của `risk-register.md`, không phải một phát biểu yêu cầu/NFR mơ hồ.
|
||
- Một số nằm trong **giả định `ASM`** đang chờ xác minh (VD "đồng bộ đủ nhanh" ở `ASM-06`) —
|
||
đây là hạn chế thật, chưa xác minh xong nên chưa thể quy về con số cụ thể; đã gắn `ASM-06`
|
||
và lịch xác minh trước GĐ3, không để trôi thành spec chính thức còn mơ hồ.
|
||
- Một số nằm trong **trích dẫn/diễn giải nguồn** (F1 ở `ELICITATION`, ghi chú phạm vi ở
|
||
`BRIEF` §5.3, §9) — mô tả khả năng/phạm vi bằng ngôn ngữ tự nhiên, không phải NFR/AC cần đo
|
||
được ở GĐ1.
|
||
Không có dòng nào trong 4 file dùng các từ này để **né việc quyết định** trong một phát biểu
|
||
`RQ`/`GOAL` chính thức (mọi `RQ`/`GOAL` đều dùng "phải" và có phép đo). Đã quét
|
||
`TBD|TODO|\?\?\?` — 0 kết quả là placeholder chưa xử lý thật (chỉ có 1 dòng tự nhắc tới chuỗi
|
||
`TBD|TODO` trong chính câu giải thích quy tắc này); mọi chỗ chưa rõ đều dùng `OQ-nnn`.
|