IMPACT — Phân tích tác động — Giỏ hàng & Checkout (e-commerce)
|
|
| Version |
1.0 |
| Date |
2026-09-08 |
| Author |
BA (qua skill ba-2-analysis) |
| Status |
🟡 Draft |
| Approved by |
— (cần Tech Lead xác nhận — chưa có Tech Lead thật tham gia lần chạy này) |
| Profile |
screen · greenfield · standard |
| Source |
01-discovery/BRIEF_CartCheckout_v1.0.md §5.3 (ranh giới hệ thống) · 01-discovery/RISK_CartCheckout_v1.0.md §3 (phụ thuộc bên ngoài) · PROCESS_CartCheckout_v1.0.md · e-commerce/docs/sections/06-luong-xu-ly.md §6.1.1 (tham chiếu tích hợp, không chép thiết kế) |
| Scope |
Module Giỏ hàng & Checkout — RQ-001…RQ-004 |
Change Log
| Version |
Date |
Người sửa |
Thay đổi |
CR |
| 1.0 |
2026-09-08 |
BA (qua skill ba-2-analysis) |
Bản đầu — rút gọn theo LIFECYCLE = greenfield, trọng tâm trục tích hợp |
— |
⚠️ Ngoại lệ gate G1 — xem cảnh báo đầy đủ ở đầu PROCESS_CartCheckout_v1.0.md và DEC-02
ở 00-index/DECISION_e-commerce.md.
Vì sao tài liệu này rút gọn: theo 00-index/PROFILE_e-commerce.md mục "Hệ quả đã áp
dụng" (LIFECYCLE = greenfield): "GĐ2 IMPACT rút gọn: chỉ trục tích hợp (không có
module/dữ liệu cũ bị ảnh hưởng)". Tài liệu dưới đây vẫn rà đủ sáu trục theo template
(không bỏ giai đoạn im lặng) — năm trục còn lại ghi rõ "đã rà, không phát hiện" kèm lý do
greenfield; trục 1.5 (Tích hợp) là trọng tâm thật sự của tài liệu này.
0. Kết luận
|
|
| Mức tác động tổng thể |
🟠 Trung bình — không có gì để đụng ở màn hình/dữ liệu/BR/RBAC cũ (greenfield), nhưng tích hợp với 4 bên thứ ba (VNPay, Momo, GHN, GHTK) + 3 module nội bộ song song (Catalog, Commission & Payout, Promotion & Loyalty, Notification) đều chưa được xác minh khả thi |
| Số hạng mục 🔴 |
2 (VNPay, Momo — xem §1.5) |
| Cần migrate dữ liệu |
Không — LIFECYCLE = greenfield, không có dữ liệu cũ (xác nhận F7, ELICITATION_CartCheckout_2026-09-08.md) |
| Cần phối hợp bên thứ ba |
Có — VNPay, Momo, GHN, GHTK (xem §1.5) |
| Rủi ro lớn nhất |
RISK-02 (webhook thanh toán trễ/lỗi khiến đơn kẹt "chờ thanh toán") và RISK-01 (COD bùng đơn một phần) — cả hai đã ghi ở GĐ1, ảnh hưởng trực tiếp tới khả năng chốt BR-CART-03/BR-CART-06 ở GĐ2 này |
1. Sáu trục rà soát
1.1 Màn hình / chức năng hiện có
| Màn hình/chức năng |
Đường dẫn |
Tác động |
Mức |
Phương án |
Ai xác nhận |
| (không có) |
— |
— |
— |
— |
— |
Đã rà: đã kiểm tra ba-output/e-commerce/ (chỉ có artifact GĐ1 của chính module này) và
e-commerce/docs/sections/07-giao-dien.md (mô tả UI dạng văn bản SCR-01…, chưa phải màn hình
đã build). Kết luận: không có màn hình nào đang chạy để module này tác động — đây là module
đầu tiên chạy GĐ2 của dự án e-commerce (greenfield, chưa có bản build sản phẩm nào trước đó).
1.2 Dữ liệu
| Bảng/thực thể |
Thay đổi |
Số bản ghi hiện có |
Dữ liệu cũ xử lý thế nào |
Mức |
Ai xác nhận |
| (không có) |
— |
0 |
N/A |
— |
— |
Đã rà: đối chiếu e-commerce/docs/sections/05-thiet-ke-du-lieu.md §5.3.5 "Migration dữ
liệu cũ: Không áp dụng — dự án greenfield… không có hệ thống cũ cần tích hợp/migrate". Kết
luận: không có dữ liệu cũ. Toàn bộ thực thể mới (Cart, CartItem, Order, OrderSeller,
OrderItem, Payment — xem BR_CartCheckout_v1.0.md §4) được tạo mới hoàn toàn; không thuộc
ba lựa chọn "giữ nguyên/migrate/song song" vì không có dữ liệu cũ để chọn.
1.3 Business rule
| BR hiện hành |
Bị ảnh hưởng thế nào |
Mâu thuẫn với rule mới? |
Xử lý |
Mức |
| (không có) |
— |
— |
— |
— |
Đã rà: không có BR nào đã chốt (✅ Baselined) trước module này trong toàn dự án
e-commerce — đây là bộ BR đầu tiên (BR_CartCheckout_v1.0.md). Mâu thuẫn nội bộ giữa các
rule mới của chính module này đã được rà ở BR_CartCheckout_v1.0.md §6, không lặp lại ở đây.
1.4 Phân quyền
| Vai trò |
Thay đổi quyền |
Ai bị mất quyền |
Đã thông báo |
Mức |
| (không có) |
— |
— |
— |
— |
Đã rà: không có RBAC nào đã chốt trước module này. RBAC_CartCheckout_v1.0.md tạo mới
2 vai trò (Guest, Customer) — chưa ảnh hưởng vai trò nào đã tồn tại vì đây là module đầu tiên.
1.5 Tích hợp / hệ thống ngoài — TRỌNG TÂM
| Hệ thống |
Điểm chạm |
Thay đổi |
Đầu mối bên kia |
Cần bên kia làm gì |
Hạn |
Mức |
| VNPay |
Payment Service khởi tạo giao dịch (US-008) + nhận webhook xác nhận (BR-CART-06) |
Tích hợp mới hoàn toàn |
Chưa xác định (RISK §3 phụ thuộc #1) |
Cung cấp tài liệu API + tài khoản sandbox; xác nhận cơ chế/độ trễ webhook (ASM-01/OQ-010) |
Trước khi bắt đầu GĐ3 (SRS thanh toán) |
🔴 |
| Momo |
Tương tự VNPay |
Tích hợp mới hoàn toàn |
Chưa xác định (RISK §3 phụ thuộc #2) |
Tương tự VNPay |
Trước GĐ3 |
🔴 |
| GHN |
Ước tính phí ship/kiểm tra vùng phục vụ theo địa chỉ lúc checkout (US-005) |
Tích hợp mới |
Chưa xác định (RISK §3 phụ thuộc #3) |
Cung cấp API tính phí + vùng phục vụ (ASM-02/OQ GĐ1) |
Trước GĐ3 (SRS checkout) |
🟠 |
| GHTK |
Tương tự GHN |
Tích hợp mới |
Chưa xác định (RISK §3 phụ thuộc #4) |
Tương tự GHN |
Trước GĐ3 |
🟠 |
| Catalog & Inventory (module nội bộ, cùng dự án, ngoài phạm vi RQ-001…004) |
Cart đọc giá/tồn kho khi thêm giỏ (US-001) và giữ tồn kho khi checkout (US-004, BR-CART-02) |
Tích hợp nội bộ mới (một chiều vào Cart) |
STK-06 (Tech Lead) |
Xác nhận kiến trúc đồng bộ giá/tồn kho, độ trễ cache (ASM-06/OQ-009) |
Trước GĐ3 |
🟠 |
| Commission & Payout (module nội bộ, ngoài phạm vi) |
Nhận sự kiện thanh toán thành công để tạo bản ghi hoa hồng |
Tích hợp nội bộ mới (một chiều ra khỏi module này) |
STK-06 (Tech Lead) |
Xác nhận cấu trúc sự kiện cần thiết |
Trước GĐ3 |
🟢 |
| Notification (module nội bộ, ngoài phạm vi, FR-12) |
Nhận sự kiện "đơn đã tạo"/"thanh toán thành công" để trigger gửi email/SMS |
Tích hợp nội bộ mới (một chiều ra khỏi module này) |
STK-06 (Tech Lead) |
Xác nhận điều kiện trigger |
Trước GĐ3 |
🟢 |
| Khuyến mãi & Loyalty (module nội bộ, ngoài phạm vi, FR-13/14) |
Checkout gọi API "áp dụng mã/điểm" và hiển thị kết quả giảm giá đã tính (điểm tích hợp đã xác nhận qua OQ-004, xem DEC-03) |
Tích hợp nội bộ mới (hai chiều: gọi áp dụng + nhận kết quả) |
STK-01 (PO sàn) đã xác nhận điểm nối; đầu mối kỹ thuật (API contract) chưa xác định |
Cung cấp API "áp dụng mã/điểm" trả về giá trị giảm |
Trước GĐ3 (màn hình checkout, US-004/US-005) |
🟠 |
Nếu bên kia lỗi hoặc chậm thì nghiệp vụ này xử lý thế nào? (bắt buộc trả lời)
- VNPay/Momo lỗi/chậm (timeout, không gửi webhook): theo
PROCESS_CartCheckout_v1.0.md
bước B9 — đơn giữ pending_payment; cơ chế đối soát bù (reconciliation job) được đề xuất ở
RISK-02 (GĐ1) nhưng thiết kế chi tiết thuộc phạm vi module Thanh toán ở GĐ3, không phải
một US của module Giỏ hàng & Checkout. Đây là phụ thuộc bắt buộc phải xử lý trước go-live,
ghi nhận rõ để không rơi vào khoảng trống giữa hai module.
- GHN/GHTK lỗi/chậm lúc ước tính phí ship (US-005): nếu
ASM-02 sai (API không khả dụng
thời gian thực lúc checkout), phương án dự phòng là chuyển sang ước tính tĩnh — chưa được
PO/Tech Lead xác nhận là phương án chính thức, vẫn ở dạng giả định từ GĐ1.
- Catalog & Inventory chậm/không phản hồi: có thể chặn hoàn toàn bước thêm giỏ (US-001)
hoặc checkout (US-004) vì đây là phụ thuộc cứng (không có giá/tồn kho thì không tạo được
CartItem/OrderItem hợp lệ) — cần Tech Lead xác nhận SLA nội bộ giữa hai service, ngoài
khả năng BA tự quyết.
- Khuyến mãi & Loyalty lỗi/chậm: theo
OQ-004/DEC-03, module này chỉ hiển thị kết quả đã
tính — nếu API áp dụng lỗi, hành vi hiển thị cho khách (bỏ qua coupon/điểm, hay chặn checkout
hoàn toàn) chưa chốt, cần OQ mới ở GĐ3.
Đã rà: đối chiếu BRIEF_CartCheckout_v1.0.md §5.3 (ranh giới hệ thống) và
RISK_CartCheckout_v1.0.md §3 (phụ thuộc bên ngoài) — không phát hiện hệ thống tích hợp nào
khác ngoài bảng trên trong phạm vi RQ-001…004.
1.6 Báo cáo / đối soát
Rút gọn theo LIFECYCLE = greenfield (theo quyết định ở PROFILE) — không có báo cáo hiện
hành nào bị đổi cách tính vì đây là module đầu tiên, chưa từng có báo cáo trước đó.
| Báo cáo |
Số liệu nào đổi |
Đổi từ khi nào |
Ai dùng báo cáo này |
Đã báo chưa |
Mức |
| (không có báo cáo hiện hành để đổi) |
— |
— |
— |
— |
— |
Ghi nhận (không phải "tác động" theo nghĩa template, nhưng quan trọng để không bỏ sót):
dữ liệu Order/OrderSeller/Payment do module này sinh ra là đầu vào bắt buộc cho báo
cáo đối soát doanh thu tương lai (STK-04 Kế toán đối soát, RACI ở STAKEHOLDER GĐ1) — nhưng
vì chưa có báo cáo nào tồn tại để so sánh, mục này không có gì để điền theo đúng cấu trúc bảng
trên. Đây là lý do RISK-02 (webhook trễ) quan trọng: dữ liệu sai lệch ngay từ module này sẽ
lan sang mọi báo cáo đối soát sau này — ghi chú lại để module Kế toán/Đối soát (nếu chạy GĐ1/2
riêng sau này) biết điểm phụ thuộc ngược.
2. Tác động lên người dùng và vận hành
| Vai trò |
Thay đổi trong công việc |
Cần đào tạo |
Cần thông báo trước |
Mức kháng cự dự kiến |
| Customer/Guest |
Trải nghiệm hoàn toàn mới (không có công việc "cũ" bị thay đổi — greenfield) |
Hướng dẫn UX tại chỗ (onboarding/tooltip) — thuộc WF/UICONV GĐ3 |
Không áp dụng (chưa có người dùng cũ) |
Thấp — nhưng chưa đo được thật (chưa vận hành), xem GOAL-01 |
CSKH (ngoài phạm vi stakeholder module này, nhưng liên đới qua RISK-02) |
Có thể cần quy trình mới để xử lý đơn "kẹt chờ thanh toán" — chưa có quy trình chính thức nào được thiết kế trong phạm vi module này |
Chưa xác định — phụ thuộc thiết kế cơ chế đối soát bù ở GĐ3 module Thanh toán |
Cần thông báo trước go-live nếu quy trình này được xác nhận |
Chưa đánh giá được — chưa có CSKH thật tham gia (đúng hệ quả G1 chưa ký) |
3. Tác động lên phi chức năng
| Khía cạnh |
Tác động |
Ngưỡng hiện tại |
Ngưỡng sau thay đổi |
Cần đo lại |
| Hiệu năng |
Checkout (B1→B5, PROCESS) phải hoàn tất trong ngưỡng đề xuất |
N/A — chưa vận hành |
< 3 giây (đề xuất NFR-01, chưa phải SLA hợp đồng — xem BRIEF §2) |
☑ (bắt buộc đo ở soft-launch, theo GOAL-01/GOAL-02) |
| Dung lượng lưu trữ |
Chưa đo — greenfield, không có dữ liệu lịch sử để ước lượng tăng trưởng thật |
N/A |
N/A |
☑ (sau khi có số liệu vận hành thật, không phải việc của GĐ2) |
| Bảo mật / tuân thủ |
Chia sẻ PII (địa chỉ, SĐT) cho seller khi tách đơn (RISK-03) chưa được Pháp chế/Bảo mật rà soát |
N/A |
N/A — chờ người phụ trách (OQ-003, GĐ1) |
☑ (bắt buộc trước go-live, không phải "nên làm") |
4. Thứ tự triển khai bắt buộc
| # |
Việc |
Phải xong trước |
Vì sao |
Ai làm |
| 1 |
Xác minh ASM-01 (webhook VNPay/Momo khả thi gần thời gian thực) |
Thiết kế chi tiết SRS US-008 ở GĐ3 |
Nếu sai, toàn bộ luồng xác nhận thanh toán (BR-CART-06) phải đổi cơ chế sang polling |
Tech Lead |
| 2 |
Xác minh ASM-02 (API GHN/GHTK tính phí ship real-time) |
Thiết kế chi tiết SRS US-005 ở GĐ3 |
Nếu sai, phải đổi sang phương án ước tính tĩnh — thay đổi UX hiển thị phí ship |
Tech Lead + STK-05 (Trưởng vận hành) |
| 3 |
PO trả lời OQ-006 (giới hạn COD) |
Chốt BR-CART-03 trước khi viết AC của US-007 ở GĐ3 |
Không có con số thì không viết được điều kiện chặn/cảnh báo cụ thể |
PO, Kế toán đối soát |
| 4 |
Xác nhận API contract "áp dụng mã/điểm" với module Khuyến mãi & Loyalty |
Thiết kế màn hình checkout (US-004/US-005) ở GĐ3 |
Module này chỉ hiển thị kết quả đã tính — không tự thiết kế được UI nếu chưa biết dữ liệu trả về là gì |
Tech Lead, PO |
5. Phạm vi hồi quy đề xuất cho QA
| Khu vực cần test lại |
Vì sao |
Ưu tiên |
| (không có) |
Module đầu tiên chạy GĐ2 của dự án e-commerce — chưa có tính năng nào đã release để hồi quy (greenfield, RIGOR = standard không miễn hoàn toàn nghĩa vụ ghi mục này, nhưng nội dung thật sự là "không có" vì chưa có bản release nào trước đó) |
N/A |
6. Open Questions
| ID |
Câu hỏi |
Hỏi ai |
Từ ngày |
Chặn gì |
| OQ-009 |
ASM-06 — giá/tồn kho thay đổi giữa lúc thêm giỏ và checkout |
PO + Tech Lead |
2026-09-08 |
§1.5 dòng Catalog & Inventory |
| OQ-010 |
Xác nhận khả thi ASM-01 (webhook VNPay/Momo) |
Tech Lead |
2026-09-08 |
§1.5 dòng VNPay/Momo, §4 mục 1 |
| (GĐ1) ASM-02 |
Xác nhận API GHN/GHTK tính phí ship real-time |
Tech Lead, STK-05 |
2026-09-08 |
§1.5 dòng GHN/GHTK, §4 mục 2 |
| (mới) OQ-017 |
Nếu API "áp dụng mã/điểm" của module Khuyến mãi & Loyalty lỗi/chậm lúc checkout, hệ thống bỏ qua và cho tiếp tục hay chặn checkout hoàn toàn? |
PO, Tech Lead |
2026-09-08 |
§1.5 dòng Khuyến mãi & Loyalty |
7. Xác nhận
| Vai trò |
Người |
Xác nhận nội dung |
Ngày |
| Tech Lead |
(chưa có — chưa xác định tên thật, xem OQ-001 GĐ1) |
☐ Khả thi, đã rà đủ |
— |
| QA |
(chưa có) |
☐ Phạm vi hồi quy hợp lý (N/A cho module đầu tiên) |
— |
| PO |
(chưa có — chưa xác định tên thật, xem OQ-001 GĐ1) |
☐ Chấp nhận tác động lên người dùng |
— |
