357 lines
71 KiB
Markdown
357 lines
71 KiB
Markdown
# CTX — Solution Context & Drivers — e-commerce
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Version** | 1.2 |
|
||
| **Date** | 2026-09-12 |
|
||
| **Author** | SA (skill sa-1-context, chế độ `go`, hoạt động `as-is`) |
|
||
| **Status** | 🟡 Draft *(duyệt tạm/từng phần — xem `Approved by`; §2 Driver và §3 Ràng buộc/§5 Giả định đã duyệt tạm ở v1.0/v1.1; **§4 Hiện trạng (AS-IS) vừa bổ sung ở v1.2** theo ghi chú người duyệt — chưa được PO/Tech Lead ký riêng, sẽ ký cùng đợt AG1 toàn phần; Bước 4–5 (`OPT`/`TCO`/`ARISK`) vẫn chưa làm; AG1 toàn phần **chưa** đủ điều kiện, xem "Tự chấm" §① bên dưới, 3/7 tiêu chí ✅)* |
|
||
| **Approved by** | PO (uỷ quyền, chế độ chạy thử): **Điều phối dự án** — duyệt **§2 Driver (`DRV-01`…`DRV-09`)** của bản v1.0 · 2026-09-12; và duyệt **§3 Ràng buộc (`CON-01`…`CON-09`) + §5 Giả định (`ASM-01`…`ASM-06`)** của bản v1.1 · 2026-09-12, cùng cách và cùng ngoại lệ như đã áp dụng cho §2. Ký thay PO theo mô hình ngoại lệ `DEC-01` (SA) / `DEC-01` (BA); **không phải chữ ký PO thật** — `OQ-004` giữ mở cho tới khi PO sàn thật xác nhận lại. `Confidence` của `CTX` giữ 🔴 cho tới khi BA ký G1 thật (không đổi bởi phê duyệt này — phê duyệt không phải bằng chứng nguồn mới, đặc biệt vì phần lớn `CON` neo theo hồ sơ thầu Draft chưa hợp đồng). Duyệt này vẫn là duyệt **từng phần**, không phải AG1 toàn phần. · Tech Lead: — *(chưa ký)* · **§4 Hiện trạng (AS-IS, v1.2) chưa được ai duyệt** — chờ cùng đợt duyệt AG1 toàn phần với Bước 4–5 |
|
||
| **Source** | `ba-output/e-commerce/01-discovery/BRIEF_CartCheckout_v1.0.md` (Draft) · `ba-output/e-commerce/01-discovery/STAKEHOLDER_CartCheckout_v1.0.md` · `ba-output/e-commerce/01-discovery/RISK_CartCheckout_v1.0.md` · `ba-output/e-commerce/02-analysis/PROCESS_CartCheckout_v1.0.md` §0 (khẳng định greenfield, AS-IS rút gọn) · `ba-output/e-commerce/02-analysis/IMPACT_CartCheckout_v1.0.md` · `ba-output/e-commerce/00-index/PROFILE_e-commerce.md` (LIFECYCLE=greenfield) · `e-commerce/docs/SAD.md` v0.2 (§0–§3, §5.3.6, §8, §9.5.2) · `e-commerce/docs/00-project-brief.md` (v3) · `e-commerce/docs/sections/01-tong-quan.md` · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` · `e-commerce/docs/sections/03-kien-truc.md` §3.3–§3.4 (môi trường, tích hợp bên thứ ba) · `e-commerce/docs/sections/09-van-hanh-kiem-thu.md` §9.5.2 (RTO/RPO kế thừa) · `e-commerce/bid/bid-config.md` (Draft — hồ sơ thầu, chưa hợp đồng) · `e-commerce/bid/30-implementation-plan.md` (Draft) · `e-commerce/bid/estimate.computed.json` (Draft, `priceComplete: false`) |
|
||
| **Scope** | Toàn sàn e-commerce (marketplace đa seller) theo `SAD.md` v0.2. Trọng tâm chi tiết nhất: module **Giỏ hàng & Checkout** (FR-05/06/07, US-002/003, RQ-001…004) — nguồn driver có Confidence cao nhất. Các module khác của sàn (Catalog, Seller/KYC, Commission & Payout, Loyalty, Notification…) suy driver từ `SAD.md`/`docs/sections/01,02` — chưa qua BRIEF/RISK cấp module riêng, Confidence thấp hơn. **Phạm vi hoạt động của lượt chạy này (v1.2): Bước 3 — Hiện trạng (AS-IS), §4**, tiếp nối Bước 1 (Driver, v1.0) và Bước 2 (Ràng buộc, v1.1) đã làm trước đó. Phương án (`OPT`)/Chi phí (`TCO`)/Rủi ro kiến trúc (`ARISK`) **vẫn chưa** thực hiện — xem §6 "Ngoài phạm vi". |
|
||
| **Confidence** | 🔴 Giả định chưa xác minh — *(bắt buộc theo ghi chú điều phối: BA chưa ký G1 chính thức cho `BRIEF_CartCheckout` — Draft, `OQ-001`/`OQ-007` (BA) còn mở; đồng thời AG1 (gate của chính GĐ1 SA) chưa từng chạy cho dự án này. Mọi `DRV` suy ra từ nguồn Draft giữ mức 🔴 cho tới khi BA ký G1 thật. §3/§5 (v1.1) dùng nhiều số liệu từ hồ sơ thầu `e-commerce/bid/` — đây là ƯỚC LƯỢNG DỰ THẦU (Draft, `priceComplete: false`, chưa PO ký hợp đồng), KHÔNG phải ràng buộc cứng đã duyệt. §4 (v1.2, mới) có phần **khẳng định greenfield** đủ tin cậy 🟢 (nguồn `PROFILE_e-commerce.md` đã PO chốt 2026-09-08) nhưng phần **tài sản thiết kế `SAD.md`/hồ sơ thầu dùng làm điểm khởi đầu OPT** và **trạng thái đối tác tích hợp** vẫn 🔴 (chưa sandbox/hợp đồng thật với bất kỳ đối tác nào — kế thừa `CON-04`). Header giữ mức thấp nhất toàn tài liệu: 🔴, cho tới khi PO/PM/Tech Lead xác nhận bằng số/tài liệu thật.)* |
|
||
|
||
## Change Log
|
||
|
||
| Version | Date | Người sửa | Thay đổi | ADR/DEC |
|
||
|---|---|---|---|---|
|
||
| 1.0 | 2026-09-12 | SA (qua skill sa-1-context) | Bản đầu — chỉ hoạt động **Driver** (Bước 1/5 của `sa-1-context`), theo yêu cầu phạm vi hẹp của lượt chạy này. Ràng buộc/Hiện trạng/Giả định/`OPT`/`TCO`/`ARISK` để lượt sau. Chạy dưới ngoại lệ gate (BA chưa ký G1, AG1 của chính GĐ1 SA cũng chưa có tiền lệ) theo yêu cầu điều phối viên. | `DEC-01` (SA) |
|
||
| 1.0 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **tạm/từng phần** §2 Driver (`DRV-01`…`DRV-09`) của bản v1.0. Không đổi nội dung chuyên môn. Ký thay PO theo ngoại lệ `DEC-01`; `OQ-004` (tính hợp lệ của ngoại lệ ký thay) **giữ mở**. `Confidence` giữ 🔴 (không nâng lên do phê duyệt này — phê duyệt không phải là bằng chứng mới về nguồn driver). Tech Lead **chưa ký** — theo "Tự chấm AG1" trong tài liệu, gate AG1 toàn phần (đủ 7 tiêu chí, cần cả PO + Tech Lead) **chưa đạt**; đây chỉ là ghi nhận đồng thuận tạm thời trên phần Driver để cho phép các bước sau của `sa-1-context` (Ràng buộc/Hiện trạng/Giả định/`OPT`/`TCO`/`ARISK`) tiếp tục dưới ngoại lệ đã có. Đồng thời, người dùng chốt hướng trả lời `OQ-002` (Bước 2 — ràng buộc Con người): dùng giả định "team MVP chuẩn" ở `Confidence` 🔴, ghi tại `DEC-02` (SA) và đóng `OQ-002` trong sổ `00-index/OQ_e-commerce.md` (giả định thật `ASM-nn` sẽ được lập khi `CON` Bước 2 chạy, tham chiếu `DEC-02`). | `DEC-01`, `DEC-02` (SA) |
|
||
| 1.1 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `constraints`) | Bổ sung §3 Ràng buộc — đủ 6 nhóm (`CON-01` Tiền; `CON-02` Thời gian; `CON-03`/`CON-04` Công nghệ; `CON-05` Con người; `CON-06`/`CON-07` Pháp lý; `CON-08`/`CON-09` Tổ chức/Vận hành) và §5 Giả định (`ASM-01`…`ASM-06`), theo ghi chú người duyệt. Ngân sách/deadline tham khảo `e-commerce/bid/` (hồ sơ thầu ước lượng, **không phải hợp đồng** — nêu rõ độ tin cậy thấp, không coi là ràng buộc cứng khi chưa có PO xác nhận). Pháp lý bổ sung chi tiết PCI-DSS (SAQ A, không lưu thẻ), NĐ13/2023 (residency/retention/quyền xoá dữ liệu, theo `SAD.md` §5.3.6/§8.2.4), hoá đơn điện tử (đã xác nhận hoãn phase 2, không phải khoảng trống). Tiếp tục ngoại lệ gate `DEC-01` (BA chưa qua G1) — người dùng tái khẳng định muốn tiếp tục, ghi nhận thêm tại `DEC-03` (SA); `Confidence` giữ 🔴 toàn bộ tài liệu. Thêm `OQ-005`…`OQ-009` (ngân sách, deadline, đại diện Pháp chế cho residency, đội vận hành sau go-live, có neo theo `SAD.md`/hồ sơ thầu cho Bước 4 hay không) vào §7 và sổ `00-index/OQ_e-commerce.md`. Không sửa §2 Driver đã duyệt từng phần. | `DEC-01`, `DEC-03` (SA) |
|
||
| 1.1 | 2026-09-12 | PO (uỷ quyền, Điều phối dự án) — tác vụ **sign/approve** | Duyệt **từng phần** §3 Ràng buộc (`CON-01`…`CON-09`) và §5 Giả định (`ASM-01`…`ASM-06`) của bản v1.1 — cùng cách ký thay PO theo ngoại lệ `DEC-01` (SA) đã dùng cho §2 Driver ở v1.0, **không phải chữ ký PO thật**. Không đổi nội dung chuyên môn. `OQ-004` (tính hợp lệ của ngoại lệ ký thay) giữ **mở**; Tech Lead **chưa ký**. `Confidence` giữ 🔴 (không nâng — phê duyệt không phải bằng chứng nguồn mới, và phần lớn `CON` vẫn neo theo hồ sơ thầu Draft/`priceComplete:false`, chưa PO xác nhận số thật). Status **giữ** 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện baseline (2/7 tiêu chí ✅, xem "Tự chấm" §①); §4 Hiện trạng và Bước 4–5 (`OPT`/`TCO`/`ARISK`) vẫn để lượt sau. | `DEC-01` (SA) |
|
||
| 1.2 | 2026-09-12 | SA (qua skill sa-1-context, chế độ `go`, hoạt động `as-is`) | Bổ sung §4 Hiện trạng (AS-IS) theo ghi chú người duyệt — bốn phần: (a) khẳng định greenfield + hệ quả (không dữ liệu migrate, không baseline tải/KPI thật); (b) hệ sinh thái bên ngoài phải tích hợp và trạng thái từng đối tác (VNPay, Momo, GHN, GHTK, Email/SMS, hoá đơn điện tử — hoãn phase 2); (c) tài sản thiết kế đã có (`SAD.md` v0.2 approved + hồ sơ thầu) — ghi rõ đây là **thiết kế đề xuất chưa thi công**, dùng làm điểm khởi đầu cho một phương án `OPT` theo trả lời `OQ-009`; (d) kỹ năng/tài sản tổ chức đã biết (AWS bắt buộc `CON-03`, team giả định `DEC-02`). Đóng `OQ-009` (chấp nhận `SAD.md` làm điểm khởi đầu tham khảo cho Bước 4, không phải phương án đã thắng sẵn) — ghi `DEC-04` (SA); `OQ-005`/`OQ-006` **giữ mở**, bổ sung ghi chú "câu trả lời tạm" (dùng số hồ sơ thầu làm mốc tham khảo, chưa PO xác nhận số thật) tại §7 và sổ `00-index/OQ_e-commerce.md`. Không sửa §2 Driver, §3 Ràng buộc, §5 Giả định đã duyệt từng phần trước đó. Tiếp tục ngoại lệ gate `DEC-01`/`DEC-03` (BA chưa qua G1, AG1 chưa từng chạy) — người dùng tái khẳng định muốn tiếp tục; `Confidence` giữ 🔴 cho phần lớn nội dung mới, riêng khẳng định greenfield (a) đạt 🟢 vì có nguồn `PROFILE_e-commerce.md` đã PO chốt. | `DEC-04` (SA) |
|
||
|
||
> Sơ đồ thắng về **quan hệ và luồng** (không có sơ đồ trong phần Driver của lượt chạy này).
|
||
> Bảng/văn bản thắng về **ràng buộc và con số**. Mâu thuẫn ngoài hai loại này là lỗi tài liệu.
|
||
|
||
---
|
||
|
||
## 0. Ghi chú Preflight & ngoại lệ gate — bắt buộc đọc trước
|
||
|
||
Đây là **GĐ1 đầu tiên của bộ SA** cho dự án e-commerce — không có gate SA nào trước nó
|
||
(`sa-lifecycle/workflow.md §4` chỉ yêu cầu điều kiện *ngoài bộ*: BA đã qua **G1** với `BRIEF`,
|
||
`GOAL`, `RQ`). Điều kiện đó **chưa đạt**:
|
||
|
||
- `BRIEF_CartCheckout_v1.0.md` — Status `🟡 Draft`, tự chấm G1 = **chưa đủ điều kiện ký chính
|
||
thức** (3/6 tiêu chí ☐: tên thật stakeholder `OQ-001`, buổi làm việc trực tiếp `OQ-005`,
|
||
baseline KPI thật `OQ-007`).
|
||
- Không có `BRIEF`/`RISK`/`STAKEHOLDER` cấp module cho các phần còn lại của sàn (Catalog,
|
||
Seller/KYC, Commission & Payout, Loyalty, Notification…) — driver các phần này chỉ suy được
|
||
từ `SAD.md` (đã "approved" ở cấp tài liệu BA nội bộ riêng, không đi qua pipeline `ba-*` module
|
||
hoá theo đúng quy trình).
|
||
|
||
**Người dùng (vai điều phối dự án chạy thử) đã được cảnh báo và khẳng định lại muốn tiếp tục**,
|
||
tham chiếu mô hình ngoại lệ đã dùng ở bộ BA (`DEC-02..07`, dự án e-commerce là dự án chạy thử,
|
||
không có Designer, PO ký thay). Quyết định ngoại lệ này được ghi tại `DEC-01` (SA) —
|
||
xem sổ `00-index/DEC_e-commerce.md` (sẽ đồng bộ khi chạy `/sa-lifecycle`).
|
||
|
||
> **DEC-01 (SA)** — Chạy `sa-1-context` (hoạt động Driver) cho dự án e-commerce trong khi BA
|
||
> chưa ký G1 chính thức và bản thân GĐ1 SA chưa có gate trước nó để chờ.
|
||
> **Quyết định:** Tiếp tục, gắn `Confidence 🔴` cho toàn bộ `DRV` cho tới khi BA ký G1 thật.
|
||
> **Người quyết:** Điều phối dự án (đại diện PO, theo ghi chú vận hành dự án chạy thử).
|
||
> **Radar (ước lượng):** chi phí đảo ngược thấp (viết lại phần Driver mất < 1 tuần nếu BA đổi
|
||
> phát biểu bài toán) · bán kính ảnh hưởng toàn bộ GĐ1 SA (một dự án) · không chạm trực tiếp một
|
||
> `QAS` cụ thể (chưa có `QAS` vì đây là GĐ1) · không ràng buộc dài hạn (là ngoại lệ tạm thời,
|
||
> không phải quyết định kiến trúc) · đã có tiền lệ ở bộ BA, ít tranh cãi. Tổng ước ~4 → **ghi
|
||
> `DEC-nn`, không cần `ADR`** theo `decision-radar.md §1–§2`.
|
||
> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng toàn bộ GĐ1 SA cho tới khi BA ký G1 thật (cần
|
||
> tối thiểu: tên thật stakeholder, 1 buổi elicitation trực tiếp, baseline KPI đo được) — ước
|
||
> chậm tiến độ chạy thử ít nhất bằng thời gian BA hoàn tất các mục đó (không có con số cụ thể vì
|
||
> đây là dự án chạy thử không có lịch thật).
|
||
|
||
---
|
||
|
||
## 1. Tóm tắt cho người quyết định
|
||
|
||
Sàn marketplace đa seller (e-commerce) cần kiến trúc chịu được quy mô "lớn" (hàng trăm nghìn
|
||
SKU, hàng trăm nghìn–hàng triệu user, đỉnh hàng nghìn–chục nghìn concurrent user mùa flash sale)
|
||
trong khi vẫn giữ đúng luồng giao dịch lõi (giỏ hàng đa seller → tách đơn → thanh toán) không
|
||
mất tiền, không mất dữ liệu, và tách bạch dòng tiền giữa khách–sàn–seller. Áp lực lớn nhất
|
||
không nằm ở tính năng mà ở: (1) luồng giao dịch lõi là blocker của toàn bộ MVP, (2) đỉnh tải
|
||
flash sale, (3) tuân thủ pháp lý (PCI-DSS, NĐ13/2023) khi xử lý tiền và PII của hai loại chủ
|
||
thể (khách hàng và seller). Tài liệu này **chỉ chốt phần Driver** (`DRV-nn`) của GĐ1; Ràng buộc,
|
||
hiện trạng, phương án, chi phí và rủi ro sẽ chạy ở các lượt kế tiếp — xem `Ngoài phạm vi`.
|
||
|
||
---
|
||
|
||
## 2. Driver — `DRV-nn`
|
||
|
||
*Áp lực kinh doanh ép ra kiến trúc, không phải tính năng. Ưu tiên nguồn: `BRIEF_CartCheckout`
|
||
(GOAL-01/02, RQ-001…004) cho module Giỏ hàng & Checkout; `SAD.md` v0.2 §1–§2 (FR-01…27,
|
||
NFR-01…08) cho các module còn lại của sàn — Confidence thấp hơn vì chưa qua BRIEF module hoá.*
|
||
|
||
| ID | Áp lực (định lượng) | Nguồn | Ai xác nhận · ngày | Thuộc tính chất lượng bị ép | Ưu tiên |
|
||
|---|---|---|---|---|---|
|
||
| `DRV-01` | Chưa có luồng giỏ hàng–checkout–thanh toán đa seller hoạt động ⇒ sàn **không thể ra mắt MVP**: 0 giao dịch ghi nhận được, seller không nhận được đơn, mọi module phụ thuộc (quản lý đơn hàng, hoa hồng, payout, đánh giá) bị **chặn hoàn toàn** — đây là blocker, không phải cải tiến. | `BRIEF_CartCheckout` §3 "Điều gì xảy ra nếu không làm gì cả" · §5.1 RQ-001…004 (Must) | STK-01 (PO sàn) qua `00-project-brief.md` vòng 1 — **chưa có tên thật**, `OQ-001` (BA) còn mở | Tính đúng đắn giao dịch · tính nhất quán dữ liệu qua nhiều seller · thông lượng | Must |
|
||
| `DRV-02` | Giỏ hàng ≥2 seller có nguy cơ tỷ lệ bỏ giỏ ở bước checkout cao hơn giỏ 1 seller (phí ship tính riêng theo từng seller, `RISK-04` mức 🟠). `GOAL-01` đề xuất ngưỡng chấp nhận ≤ (tỷ lệ bỏ giỏ 1 seller) + 10 điểm phần trăm — **baseline thật chưa có** (greenfield, `OQ-007` BA còn mở). | `BRIEF_CartCheckout` §4 GOAL-01 · `RISK_CartCheckout` RISK-04 | STK-01 (PO sàn) — đề xuất đo baseline 4–6 tuần đầu soft-launch, **chưa xác nhận số thật** | Độ trễ hiển thị phí ship theo seller · trải nghiệm nhất quán khi tách đơn | Must (gắn RQ-001/002 Must) |
|
||
| `DRV-03` | Thanh toán phải chấp nhận VNPay/Momo/COD **không lưu thông tin thẻ** để giảm phạm vi tuân thủ PCI-DSS — nếu tự lưu/xử lý thẻ, phạm vi kiểm toán PCI-DSS đầy đủ (thay vì rút gọn qua bên thứ ba) kéo theo chi phí tuân thủ và rủi ro pháp lý cao hơn đáng kể (con số tuân thủ cụ thể chưa có — cần Legal, xem `OQ` mới ở §7). | `BRIEF_CartCheckout` §5.1 RQ-003 · `docs/sections/01-tong-quan.md` §1.5 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-05 | 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 | Bảo mật/tuân thủ (ranh giới phạm vi PCI-DSS) | Must |
|
||
| `DRV-04` | Quy mô mục tiêu "lớn": hàng trăm nghìn SKU trở lên, hàng trăm nghìn–hàng triệu user đăng ký, đỉnh **hàng nghìn–chục nghìn concurrent user** mùa flash sale. Không scale-out ngay từ đầu ⇒ hệ thống có nguy cơ sập đúng lúc doanh thu cao nhất trong năm (flash sale). | `00-project-brief.md` mục 3 (Q&A vòng 1) · `docs/sections/02-phan-tich-yeu-cau.md` NFR-02 | STK-01 (PO sàn) qua vòng 1 brief — **chưa có tên thật, chưa có số đo thật** (dự án chưa vận hành, đây là mục tiêu quy mô đã "chốt" ở mức mô tả định tính "lớn", không phải SLA hợp đồng) | Khả năng mở rộng (scale-out) · thông lượng · độ trễ dưới tải đỉnh | Must |
|
||
| `DRV-05` | Uptime mục tiêu 99.9% cho dịch vụ giao dịch lõi (catalog, checkout, thanh toán) vì doanh thu phụ thuộc trực tiếp; escalation 24/7 cho sự cố nghiêm trọng. 99.9%/tháng ⇒ ngân sách lỗi ≈ 43 phút/tháng — vượt ngân sách này ở đúng dịch vụ giao dịch nghĩa là mất doanh thu trực tiếp trong khung giờ đó. | `docs/sections/02-phan-tich-yeu-cau.md` NFR-03, NFR-08 · `00-project-brief.md` mục 5 giả định #6 | STK-01 (PO sàn) — 🔴 **đây là "giả định mặc định đã chốt trong brief", CHƯA phải SLA hợp đồng thật** (ghi rõ trong `docs/sections/02-phan-tich-yeu-cau.md` cuối §2.2) | Sẵn sàng (availability) · khả năng phục hồi | Must |
|
||
| `DRV-06` | Dòng tiền phải minh bạch giữa 3 bên (khách–sàn–seller): hoa hồng tính theo ngành hàng (cấu hình được), payout hàng tuần qua chuyển khoản có kỳ giữ tiền (hold) 3–7 ngày sau giao hàng thành công. Sai lệch đối soát phát sinh từ tầng giao dịch (checkout/payment) sẽ lan sang toàn bộ hệ thống payout/commission — ở quy mô "lớn" (hàng trăm nghìn giao dịch), một lỗi hệ thống nhỏ nhân lên thành tranh chấp tài chính hàng loạt. | `docs/sections/01-tong-quan.md` §1.1 · `00-project-brief.md` mục 2 & mục 5 (giả định #3) · `docs/sections/02-phan-tich-yeu-cau.md` FR-17/FR-21/FR-22 | STK-01 (PO sàn), STK-04 (Kế toán đối soát — vai trò, chưa tên thật) | Tính nhất quán dữ liệu tài chính · khả năng kiểm toán (audit) · ranh giới sở hữu dữ liệu | Must |
|
||
| `DRV-07` | Chia sẻ PII (địa chỉ giao hàng, số điện thoại người nhận) cho từng seller khi tách đơn theo seller **chưa được rà soát** theo Nghị định 13/2023 vì dự án chưa có đại diện Pháp chế/Bảo mật được chỉ định. Rủi ro tương ứng đã được BA ghi nhận mức **Cao/Trung bình** (`RISK-03`). | `RISK_CartCheckout_v1.0.md` RISK-03 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-04, NFR-05 | *(Chưa có người — `OQ-003` BA còn mở)* | Bảo mật/quyền riêng tư · phân loại dữ liệu nhạy cảm | Must |
|
||
| `DRV-08` | Xác nhận thanh toán qua webhook VNPay/Momo (bên thứ ba) **chưa được xác minh khả thi gần thời gian thực** (`ASM-01`, chưa xác minh). Nếu webhook trễ/lỗi, đơn hàng kẹt "chờ thanh toán" dù tiền đã thu ⇒ khiếu nại CSKH + sai lệch đối soát (`RISK-02`, tác động Cao, khả năng Trung bình). | `RISK_CartCheckout_v1.0.md` RISK-02, ASM-01 · `IMPACT_CartCheckout_v1.0.md` §1.5 | STK-06 (Tech Lead) + STK-01 (PO sàn) — chưa xác nhận khả thi thật (cần đọc tài liệu/gọi sandbox VNPay/Momo) | Tính nhất quán (eventual) · khả năng đối soát bù · quan sát được (observability) | Must |
|
||
| `DRV-09` | Đa ngôn ngữ 5 thứ tiếng (VI mặc định/EN/ZH/KO/JA) để mở rộng tệp khách hàng mục tiêu ra ngoài thị trường Việt Nam thuần tuý — Should, không chặn MVP nếu thiếu, nhưng thiếu thì giới hạn khả năng tiếp cận thị trường theo đúng mô hình kinh doanh đã chốt (marketplace quy mô lớn). | `docs/sections/01-tong-quan.md` §1.1 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-06 | STK-01 (PO sàn) qua vòng 3 brief — chưa tên thật | Khả năng bảo trì (kiến trúc i18n/l10n tách nội dung khỏi code) | Should |
|
||
|
||
**Ghi chú Confidence theo dòng:** `DRV-01, 02, 03, 07, 08` có nguồn trực tiếp từ `BRIEF/RISK/
|
||
IMPACT` cấp module Giỏ hàng & Checkout (dù bản thân các tài liệu đó còn Draft) — Confidence
|
||
🔴 hiện tại chỉ vì BA chưa ký G1, **không phải vì thiếu nguồn**. `DRV-04, 05, 06, 09` chỉ có
|
||
nguồn từ `SAD.md`/`docs/sections` (chưa qua BRIEF/RISK module hoá riêng cho các phần đó của sàn)
|
||
— Confidence 🔴 vì **cả hai lý do**: chưa qua G1 và chưa có phân tích module hoá cấp BA. Ghi rõ
|
||
để người ký AG1 sau này biết mức độ rủi ro khác nhau giữa các dòng.
|
||
|
||
### 2.1 Định hướng khách gợi ý *(tham khảo, KHÔNG phải driver)*
|
||
|
||
| Khách/tài liệu nói | Đây là giải pháp cho vấn đề gì | Đã hỏi ngược chưa | `DRV` thật rút ra được |
|
||
|---|---|---|---|
|
||
| "Kiến trúc cần cache (Redis), CDN, message queue (Kafka/RabbitMQ), scale-out ngang ngay từ đầu" (`00-project-brief.md` mục 2 "NFR tiêu biểu"; lặp lại ở NFR-02) | Giải pháp cho vấn đề chịu tải đỉnh mùa flash sale — nhưng câu này tự nó không định lượng được tải đỉnh | ☐ Chưa hỏi trực tiếp PO/Tech Lead; suy luận qua con số ở NFR-02 ("hàng nghìn–chục nghìn concurrent user") | `DRV-04` — công nghệ cụ thể (Redis/Kafka/RabbitMQ) là đề xuất, **không phải ràng buộc bắt buộc**; việc chọn công nghệ nào thuộc Bước 4 (Phương án) của GĐ1, chưa làm ở lượt này |
|
||
| "Kiến trúc module hoá để các nhóm (catalog, order, seller, payment) phát triển độc lập" (NFR-07) | Giải pháp cho vấn đề đội ngũ chờ nhau khi release (Conway) — nhưng **số đội/số người CHƯA có** | ☐ Chưa hỏi — đây là câu hỏi thuộc nhóm ràng buộc "Con người" (Bước 2, ngoài phạm vi lượt chạy này) | Chưa rút ra được driver cụ thể — ghi `OQ-002` (SA) ở §7 |
|
||
| "Tech stack không bắt buộc, kiến trúc sư tự đề xuất theo best practice cho quy mô lớn; cloud = AWS" (`00-project-brief.md` mục 2 & 5) | Đây là **ràng buộc** (`CON`), không phải driver — AWS đã được xác nhận là bắt buộc (cứng) | N/A — không phải driver | Sẽ thành `CON-nn` (nhóm Công nghệ) khi chạy Bước 2 — ngoài phạm vi lượt này |
|
||
|
||
---
|
||
|
||
## 3. Ràng buộc — `CON-nn`
|
||
|
||
*Thứ KHÔNG thương lượng được — sở thích không phải ràng buộc. Rà đủ sáu nhóm theo
|
||
`sa-1-context/SKILL.md` Bước 2. Ngân sách/deadline dưới đây tham khảo `e-commerce/bid/`
|
||
(`bid-config.md`, `30-implementation-plan.md`, `estimate.computed.json`) — đây là **hồ sơ thầu
|
||
ước lượng của nhà thầu, Status `draft`, `cost.priceComplete=false`, KHÔNG phải hợp đồng đã ký**.
|
||
Dùng làm điểm tham khảo duy nhất hiện có, ghi rõ độ tin cậy 🔴, KHÔNG coi là ràng buộc cứng cho
|
||
tới khi PO xác nhận bằng số thật — theo đúng ghi chú người duyệt.*
|
||
|
||
| ID | Nhóm | Ràng buộc | Nguồn (ai · ngày) | Cứng/Mềm | Hệ quả kiến trúc |
|
||
|---|---|---|---|---|---|
|
||
| `CON-01` | Tiền | Ngân sách hạ tầng/tháng và chi phí một lần **CHƯA được PO duyệt chính thức** (`00-project-brief.md` mục 6: "ngân sách/timeline chưa xác định"; mục 5 giả định: "ngân sách theo business case"). Tham khảo duy nhất hiện có: hồ sơ thầu ước lượng — lao động ≈ 3.420.500.000 VND (chưa VAT) + VAT 10% (342.050.000 VND) = **≈ 3.762.550.000 VND** cho 53,02 người-tháng/7 tháng thực hiện (`estimate.computed.json` → `cost.subtotal/vat/total`); **8 khoản chi phí không lao động** (hạ tầng AWS 3 môi trường, OpenSearch cluster, phí giao dịch VNPay/Momo, phí Email/SMS, phí API GHN/GHTK, domain/SSL/WAF, pentest/ASV hàng năm, đào tạo) đều `amount: null` — **chưa có số**, kể cả trong chính hồ sơ thầu. | `00-project-brief.md` mục 6 · `e-commerce/bid/estimate.computed.json` `cost` (Draft, chưa PO xác nhận) | **Chưa xác định cứng/mềm** — không có ngân sách nào được PO duyệt để đối chiếu | Không thể chấm điểm `TCO` (Bước 5, ngoài phạm vi lượt này) một cách có ý nghĩa cho tới khi có số ngân sách thật — xem `OQ-005` |
|
||
| `CON-02` | Thời gian | Không có deadline hợp đồng/pháp lý bên ngoài được xác nhận (`bid-config.projectDeadline`/`submissionDeadline` rỗng; `estimate.computed.json` → `timeline.deadlineFit.fits = null`). **Hai con số tham khảo KHÔNG khớp nhau:** brief giả định định tính "~9-12 tháng" (mục 5, giả định cuối) vs hồ sơ thầu tính toán "7 tháng thực hiện" (`timeline.durationMonths=7`, teamSize trung bình 9, đỉnh điểm 10 người) + 12 tháng bảo hành sau đó (`bid-config.warrantyMonths=12`). | `00-project-brief.md` mục 5, giả định #7 · `e-commerce/bid/estimate.computed.json` `timeline` · `e-commerce/bid/30-implementation-plan.md` §B7.1, §B7.5 | Mềm (chưa có ràng buộc cứng nào được xác nhận bằng văn bản) | `OPT` Bước 4 (ngoài phạm vi lượt này) phải trình ≥2 kịch bản thời gian (7 tháng "đẩy nhanh" theo bid vs 9-12 tháng "chuẩn" theo brief) thay vì giả định một mốc duy nhất — xem `OQ-006` |
|
||
| `CON-03` | Công nghệ | Cloud **AWS bắt buộc** — đã xác nhận tại vòng 3 Q&A của brief, không phải sở thích của kiến trúc sư | `00-project-brief.md` mục 5 (Q&A vòng 3: "cloud AWS") · `docs/sections/01-tong-quan.md` §1.5 | **Cứng** | Loại mọi phương án dùng cloud khác/on-prem ngay từ Bước 4 (`OPT`) |
|
||
| `CON-04` | Công nghệ | Đối tác thanh toán **VNPay + Momo + COD**, đối tác vận chuyển **GHN + GHTK** đã xác nhận làm mặc định tích hợp (không phải "chờ chọn tuỳ ý") — nhưng dự án **chưa có tài liệu API/tài khoản sandbox thật** với bất kỳ đối tác nào trong bốn đối tác này | `00-project-brief.md` mục 1 vòng 1 & mục 4 vòng 1 | Cứng (danh tính đối tác đã chốt) / Mềm (thời điểm có sandbox/hợp đồng thật — phụ thuộc bên ngoài) | Thiết kế tích hợp (`ICD`, GĐ2) phải giả định theo tài liệu công khai của 4 đối tác này cho tới khi có sandbox thật xác nhận (kế thừa `ASM-01`/`ASM-02` của BA ở `RISK_CartCheckout_v1.0.md` §1, §3) |
|
||
| `CON-05` | Con người | Số đội/số người/kỹ năng team thi công + đội vận hành sau go-live **CHƯA được PM/Tech Lead xác nhận số thật** — hiện dùng giả định tạm "team MVP chuẩn" theo `DEC-02` (SA, 🔴). Tham khảo duy nhất: hồ sơ thầu ước lượng teamSize trung bình **9 vị trí đồng thời**, đỉnh điểm **10 đầu người**, 8 vai trò (PM/BA/SA/UIUX/BE/FE/QA/DEVOPS) — đây là cách tổ chức nhân sự **do nhà thầu đề xuất cho hồ sơ thầu của chính họ**, không phải đội hình mà PO/chủ dự án đã cam kết tuyển/thuê nội bộ; toàn bộ tên/CV nhân sự trong hồ sơ thầu vẫn là `[[CẦN ĐIỀN]]` | `DEC-02` (SA) · `e-commerce/bid/30-implementation-plan.md` §B8.2 (tên/CV `[[CẦN ĐIỀN]]`), §B8.3 (đơn vị FTE, không phải cam kết nhân sự) | Chưa xác định — chỉ là số liệu tham khảo, không có giá trị ràng buộc | Ranh giới service ở `SAD` (GĐ2) không nên chốt cứng theo số liệu này cho tới khi có số team thật — xem `OQ-002` (mở từ v1.0) và `OQ-008` (mới, riêng phần đội vận hành sau go-live) |
|
||
| `CON-06` | Pháp lý | Bắt buộc tuân thủ: **NĐ52/2013 + NĐ85/2021** (thông báo website TMĐT dạng sàn giao dịch với Bộ Công Thương), **NĐ13/2023** (bảo vệ dữ liệu cá nhân — cả PII khách hàng lẫn giấy tờ KYC seller), **PCI-DSS phạm vi thu hẹp** (SAQ A — không lưu thông tin thẻ, giao VNPay/Momo xử lý, cô lập trong một Payment Service duy nhất theo `SAD.md` §3.1) | `docs/sections/01-tong-quan.md` §1.5 · `docs/sections/02-phan-tich-yeu-cau.md` NFR-05 · `SAD.md` §3.1, §8 (§8.4 pentest/ASV cho SAQ A) | **Cứng** (pháp luật, không thương lượng được) | Payment Service phải là biên cô lập duy nhất chạm dữ liệu thẻ (đã phản ánh trong `SAD.md`, GĐ2 SA kế thừa nguyên trạng, không thiết kế lại); mọi luồng chia sẻ địa chỉ/SĐT cho seller khi tách đơn phải qua rà soát Pháp chế trước go-live — **chưa có người rà soát** (kế thừa `RISK-03`/`OQ-003` của BA) |
|
||
| `CON-07` | Pháp lý | Hoá đơn điện tử cho seller **đã xác nhận hoãn sang phase 2** (không thuộc MVP) — đây là **quyết định kinh doanh đã chốt**, không phải khoảng trống thông tin | `00-project-brief.md` mục 2, dòng "Hoá đơn điện tử cho seller — hoãn sang giai đoạn sau, đã xác nhận (vòng 3)" | Cứng (phạm vi đã chốt cho MVP) | Không thiết kế module hoá đơn điện tử ở GĐ2 MVP; ghi vào §6 "Ngoài phạm vi" và để cho `TRM` (GĐ4) khi có phase sau — xem `ASM-06` |
|
||
| `CON-08` | Tổ chức/Vận hành | Đội vận hành (Ops) trực theo ca giờ hành chính + escalation 24/7 cho sự cố nghiêm trọng (do doanh thu phụ thuộc hệ thống) — hiện là **giả định mặc định đã chốt trong brief**, CHƯA xác nhận đội ops là nội bộ PO hay thuê ngoài, quy mô bao nhiêu người | `00-project-brief.md` §5, giả định cuối ("Vận hành: … đội ops trực theo ca…") · `docs/sections/02-phan-tich-yeu-cau.md` NFR-08 | Mềm (giả định, chưa xác nhận thật) | Thiết kế on-call/`INF` ở GĐ2 phải giả định một mô hình vận hành cụ thể cho tới khi có xác nhận thật — xem `OQ-008` |
|
||
| `CON-09` | Tổ chức/Vận hành | Bảo hành 12 tháng sau nghiệm thu tổng thể (`bid-config.warrantyMonths=12`) là điều khoản **đề xuất của nhà thầu trong hồ sơ thầu**, chưa phải điều khoản hợp đồng đã ký; mô hình bàn giao vận hành lâu dài cho PO sau khi hết bảo hành (ai tiếp nhận, có chuyển giao kiến thức không) **chưa được mô tả ở đâu** | `e-commerce/bid/bid-config.md` (`warrantyMonths: 12`) · `e-commerce/bid/30-implementation-plan.md` §B7.2 Giai đoạn 7 | Mềm (đề xuất, chưa ký hợp đồng) | `AGD`/`DREV` ở GĐ3 (ngoài phạm vi lượt này) cần biết ai là đội vận hành lâu dài để viết guideline đúng đối tượng — ghi nhận sớm, không quyết thay PM/PO |
|
||
|
||
**Cứng** = vi phạm thì dự án bị chặn (pháp luật, cloud bắt buộc). **Mềm** = đổi được nhưng tốn
|
||
tiền/thời gian — ở đây phần lớn còn ghi "Mềm/Chưa xác định" vì các nguồn duy nhất hiện có
|
||
(brief giả định, hồ sơ thầu ước lượng) chưa được PO/PM/Tech Lead xác nhận là ràng buộc thật.
|
||
|
||
### 3.1 Nhóm ràng buộc chưa có thông tin (còn cần xác nhận thật)
|
||
|
||
| Nhóm | Ai phải trả lời | Đã hỏi ngày | `OQ` | Chặn gì |
|
||
|---|---|---|---|---|
|
||
| Tiền (số ngân sách thật, không phải ước lượng thầu) | PO / tài chính | 2026-09-12 (qua tài liệu, chưa phải buổi hỏi trực tiếp) | `OQ-005` | `CON-01` (cứng/mềm), `TCO` Bước 5 |
|
||
| Thời gian (deadline thật, nếu có) | PO / PM | 2026-09-12 | `OQ-006` | `CON-02`, kịch bản thời gian ở `OPT` Bước 4 |
|
||
| Con người (đội vận hành sau go-live: nội bộ hay thuê ngoài, quy mô) | PM / SRE | 2026-09-12 | `OQ-008` | `CON-05`, `CON-08`, thiết kế `INF`/on-call GĐ2 |
|
||
| Pháp lý (đại diện Pháp chế/Bảo mật xác nhận yêu cầu residency theo NĐ13/2023) | Legal / Security | 2026-09-12 (kế thừa `OQ-003` của BA, vẫn chưa có người) | `OQ-007` | `CON-06`, `ASM-04`, ranh giới hạ tầng dữ liệu ở `DAT`/`INF` GĐ2 |
|
||
|
||
## 4. Hiện trạng (AS-IS)
|
||
|
||
*Bước 3 của `sa-1-context`, chạy ở lượt này (hoạt động `as-is`). Dự án e-commerce là
|
||
**greenfield** — không có hệ thống/dữ liệu cũ để khảo sát trực tiếp theo bốn mục
|
||
`GUIDE.md` (hệ thống/dữ liệu/tích hợp/vận hành). Theo `SKILL.md` §Bước 3 và
|
||
`artifact-map.md` §7 (loại LIFECYCLE=greenfield ⇒ rút gọn CTX phần as-is), "hiện trạng" ở đây
|
||
gồm bốn phần: (a) khẳng định greenfield + hệ quả, (b) hệ sinh thái bên ngoài bắt buộc tích hợp
|
||
(đây là "as-is" thật duy nhất của một dự án greenfield — các đối tác đã tồn tại và có ràng buộc
|
||
kỹ thuật/pháp lý riêng của họ), (c) tài sản thiết kế nội bộ đã có (`SAD.md`/hồ sơ thầu), (d)
|
||
kỹ năng/tài sản tổ chức đã biết.*
|
||
|
||
### 4.1 Khẳng định greenfield và hệ quả
|
||
|
||
**Khẳng định:** Dự án e-commerce là hệ thống **mới hoàn toàn** — không có hệ thống, cơ sở dữ
|
||
liệu, hay quy trình thủ công nào đang chạy để thay thế/tích hợp cho lõi giao dịch (giỏ hàng →
|
||
checkout → thanh toán → tách đơn theo seller → vận chuyển → hoa hồng/payout). Nguồn:
|
||
`PROFILE_e-commerce.md` (`LIFECYCLE: greenfield`, PO chốt 2026-09-08) · `PROCESS_CartCheckout_v1.0.md`
|
||
§0 ("dự án là marketplace hoàn toàn mới, không có hệ thống hay quy trình thủ công… không có hệ
|
||
thống cũ (ERP/kho/CRM) cần tích hợp hoặc migrate cho luồng giỏ hàng/checkout").
|
||
|
||
| # | Hệ quả của greenfield | Diễn giải cho GĐ1/GĐ2 SA | Nguồn |
|
||
|---|---|---|---|
|
||
| 1 | **Không có dữ liệu để migrate** | `OPT` (Bước 4) không cần kịch bản migration/rollback dữ liệu cũ, khác dự án loại 3 (migration) theo `SKILL.md` Bước 0.2; `DAT` ở GĐ2 thiết kế mô hình dữ liệu từ đầu, không cần ánh xạ từ schema cũ | `PROFILE_e-commerce.md`; `workflow.md §5` (bảng phân loại dự án) |
|
||
| 2 | **Không có baseline tải/KPI đo được thật** | Mọi con số trong `DRV-02` (tỷ lệ bỏ giỏ ≤ baseline 1-seller + 10 điểm %), `DRV-04` (đỉnh "hàng nghìn–chục nghìn concurrent user"), `DRV-05` (uptime 99.9%) là **mục tiêu/giả định đã chốt trong brief**, KHÔNG phải số đo từ hệ thống đang chạy — xác nhận lại điều đã ghi ở các dòng `DRV` tương ứng (§2), không đổi nội dung `DRV` | `BRIEF_CartCheckout` §4 GOAL-01; `docs/sections/02-phan-tich-yeu-cau.md` NFR-02/03; `00-project-brief.md` §5 giả định #6 |
|
||
| 3 | **Không có nợ kỹ thuật/hệ thống legacy** | GĐ2 (`SAD`/`ADR`) không cần rà soát tương thích ngược hay "strangler pattern"; toàn bộ ranh giới service trong `SAD.md` §3.1 có thể thiết kế theo domain lý tưởng, không bị ràng buộc bởi cấu trúc code cũ | `SAD.md` §3.1 |
|
||
| 4 | **Không có người dùng/seller thật đang hoạt động cần continuity** | Không cần chiến lược cutover zero-downtime từ hệ thống cũ sang mới khi go-live; rủi ro go-live là "ra mắt lần đầu" (chưa từng có traffic thật để so sánh), không phải "chuyển đổi không được gián đoạn" | `PROFILE_e-commerce.md`; `PROCESS_CartCheckout_v1.0.md` §0 |
|
||
|
||
🔴 **Hệ quả ngược nếu khẳng định greenfield sai** (VD phát hiện có một hệ thống nội bộ cũ dùng
|
||
tạm cho vận hành thủ công mà brief chưa nhắc tới): phải chạy lại Bước 3 đầy đủ theo bốn mục
|
||
`GUIDE.md` (hệ thống/dữ liệu/tích hợp/vận hành cũ), và `DRV-01` (blocker MVP) có thể phải viết
|
||
lại vì đã có một phần luồng đang chạy thủ công — chưa có dấu hiệu này trong mọi tài liệu đã đọc.
|
||
|
||
### 4.2 Hệ sinh thái bên ngoài phải tích hợp — trạng thái từng đối tác
|
||
|
||
*Đây là "hiện trạng" thật của một dự án greenfield: các đối tác này đã tồn tại độc lập với dự
|
||
án, có ràng buộc kỹ thuật/hợp đồng riêng của họ mà SA phải khảo sát trước khi thiết kế `ICD`
|
||
(GĐ2). Cột "Trạng thái sẵn sàng" đối chiếu với `CON-04` (§3) — dự án **chưa có** tài liệu API
|
||
sandbox/tài khoản thật với bất kỳ đối tác nào dưới đây.*
|
||
|
||
| Đối tác | Vai trò trong luồng nghiệp vụ | Giao thức đề xuất (`SAD.md` §3.4) | Trạng thái sẵn sàng thật (khảo sát) | Nguồn |
|
||
|---|---|---|---|---|
|
||
| **VNPay** | Cổng thanh toán online (redirect + IPN callback xác nhận giao dịch), không lưu thẻ | REST/HTTPS, timeout 10s, retry callback idempotent ≤3 lần | 🔴 Chưa có tài khoản sandbox/hợp đồng — thiết kế timeout/retry ở `SAD.md` §3.4 là **đề xuất chưa xác minh với sandbox thật** (kế thừa `ASM-01`/`ASM-02` của BA, `DRV-08`) | `SAD.md` §3.4; `CON-04`; `RISK_CartCheckout` ASM-01 |
|
||
| **Momo** | Cổng thanh toán online (redirect + IPN), không lưu thẻ | REST/HTTPS, timeout 10s, retry callback idempotent ≤3 lần | 🔴 Chưa có tài khoản sandbox/hợp đồng — tương tự VNPay | `SAD.md` §3.4; `CON-04` |
|
||
| **COD** | Thu tiền mặt khi giao — không phải API bên ngoài, là luồng nghiệp vụ nội bộ xác nhận qua đơn vị vận chuyển | Không áp dụng (không phải tích hợp API) | 🟢 Không phụ thuộc đối tác công nghệ — phụ thuộc quy trình xác nhận thủ công của GHN/GHTK/Ops | `SAD.md` §3.4 |
|
||
| **GHN** | Vận chuyển: tạo vận đơn, tra cứu trạng thái, webhook cập nhật | REST/HTTPS, timeout 8s, retry ≤3 lần, webhook idempotent | 🔴 Chưa có tài liệu API/sandbox thật — `SAD.md` §3.4 đề xuất fallback chéo sang GHTK khi GHN lỗi, **chưa kiểm chứng** khả năng fallback này có hoạt động đúng giữa hai API khác nhau trong thực tế | `SAD.md` §3.4; `CON-04` |
|
||
| **GHTK** | Vận chuyển (tương tự GHN), fallback chéo cho GHN | REST/HTTPS, timeout 8s, retry ≤3 lần | 🔴 Chưa có tài liệu API/sandbox thật — tương tự GHN | `SAD.md` §3.4; `CON-04` |
|
||
| **Email/SMS Provider** | Thông báo đơn hàng/giao hàng, nội dung đa ngôn ngữ | REST/HTTPS hoặc SDK qua queue, timeout 5s, retry ≤5 lần backoff | 🔴🔴 **Nhà cung cấp cụ thể CHƯA CHỐT** (SAD.md §3.4 tự ghi "đề xuất: SES/SNS hoặc SendGrid/Twilio — nhà cung cấp cụ thể chưa chốt, xem giả định") — mức độ chưa sẵn sàng cao hơn VNPay/Momo/GHN/GHTK vì còn chưa chọn đối tác, chưa dừng ở "chưa có sandbox" | `SAD.md` §3.4 |
|
||
| **Ngân hàng (payout)** | Chuyển khoản hoa hồng/payout hàng tuần cho seller | Batch file chuẩn ngân hàng (VD NAPAS) hoặc API — *ngân hàng cụ thể chưa chốt* | 🔴🔴 Chưa chọn ngân hàng đối tác, chưa có định dạng batch xác nhận | `SAD.md` §3.4 |
|
||
| **Google/Facebook OAuth** | Đăng nhập mạng xã hội (Should, không chặn MVP vì email/password vẫn hoạt động độc lập) | OAuth 2.0/OIDC redirect flow, timeout 10s | 🟡 Chuẩn mở, không cần hợp đồng riêng như các đối tác thương mại ở trên, nhưng vẫn chưa có app/client ID thật được đăng ký | `SAD.md` §3.4 |
|
||
| **Hoá đơn điện tử cho seller** | Xuất hoá đơn điện tử tự động khi seller phát sinh doanh thu | *(không thiết kế ở MVP)* | ⏸️ **Hoãn sang phase 2 — đã xác nhận (vòng 3 brief), không phải khoảng trống thông tin.** Không phải rủi ro tích hợp of MVP; ghi nhận cho `TRM` (GĐ4) khi có phase sau | `00-project-brief.md` dòng "Ngoài phạm vi MVP… hoá đơn điện tử tự động cho seller"; `CON-07` |
|
||
|
||
**Đọc bảng:** 🔴 = chưa sandbox/hợp đồng thật nhưng đối tác đã xác định danh tính (kế thừa từ
|
||
Bước 1/2). 🔴🔴 = chưa cả chọn đối tác cụ thể (mức chưa sẵn sàng cao hơn). 🟡 = chuẩn mở, ít rủi
|
||
ro hơn. 🟢 = không phụ thuộc đối tác công nghệ bên ngoài. ⏸️ = ngoài phạm vi MVP theo quyết định
|
||
kinh doanh đã chốt, không phải rủi ro.
|
||
|
||
Hệ quả cho GĐ2: `ICD` không thể chốt contract thật (owner, SLA, mã lỗi cụ thể) cho VNPay/Momo/
|
||
GHN/GHTK/Email-SMS cho tới khi có tài liệu/sandbox thật — GĐ2 sẽ phải thiết kế theo tài liệu
|
||
công khai của đối tác và đánh dấu `Confidence` 🔴 cho các `IF-nnn` tương ứng, kế thừa `ASM-01`
|
||
(BA) và `CON-04` (SA).
|
||
|
||
### 4.3 Tài sản thiết kế nội bộ đã có
|
||
|
||
Dự án **không** ở tình trạng "trắng hoàn toàn" về mặt thiết kế — đã có hai tài sản tham khảo:
|
||
|
||
| Tài sản | Trạng thái ghi trong chính tài liệu | Bản chất thật — SA phải hiểu đúng | Dùng làm gì ở GĐ1 SA |
|
||
|---|---|---|---|
|
||
| `e-commerce/docs/SAD.md` v0.2 (toàn bộ 9 mục `docs/sections/01…09`) | `status: approved` ở mọi mục con và ở bản ráp tổng thể (§0.2/§0.3 của `SAD.md`: "Product Owner/Kiến trúc sư trưởng đã phê duyệt") | Đây là **"approved" ở cấp phê duyệt nội bộ bản vẽ** (PO/Kiến trúc sư trưởng ký trên giấy khi làm hồ sơ), **KHÔNG phải kiến trúc đang chạy production**, không phải nghiệm thu vận hành, và không đi qua gate `AG1`/`AG2` của chính bộ `sa-*` này (được viết trước khi có pipeline `sa-lifecycle`) | Theo trả lời **`OQ-009` (đã đóng, xem `DEC-04`)**: dùng làm **điểm khởi đầu tham khảo** (baseline candidate) cho một trong các phương án ở Bước 4 (`OPT`) — KHÔNG mặc định là phương án thắng sẵn; Bước 4 vẫn phải dựng ≥1 phương án độc lập khác để so sánh thật (tránh bẫy "một phương án đã thắng sẵn", `GUIDE.md` "Bẫy thường gặp") |
|
||
| `e-commerce/bid/` (`bid-config.md`, `30-implementation-plan.md`, `estimate.computed.json`) | `status: draft`, `cost.priceComplete: false` — tự ghi rõ là ước lượng dự thầu, chưa hợp đồng | Ước lượng của **nhà thầu** cho mục đích đấu thầu (nhân công, timeline, đội hình đề xuất) — khác mục đích với `TCO` (ước lượng vận hành 3 năm theo phương án kiến trúc SA chọn) đã ghi ở §6 "Ngoài phạm vi" | Tham khảo duy nhất hiện có cho `CON-01`/`CON-02`/`CON-05` (đã ghi ở §3) — không dùng làm số `TCO` thật ở Bước 5 |
|
||
|
||
🔴 **Ranh giới thẩm quyền quan trọng:** "approved" trong `SAD.md` là do PO/Kiến trúc sư trưởng
|
||
**nội bộ nhà thầu** ký trong quá trình chuẩn bị hồ sơ — không phải PO thật của dự án chạy thử
|
||
này ký qua pipeline `sa-*`. Coi `SAD.md` là "đã chốt, không được đổi" là hiểu sai bản chất và vi
|
||
phạm chính Bước 4 của `SKILL.md` (nguy cơ "một phương án duy nhất" — mục "Bẫy thường gặp").
|
||
|
||
**Quyết định đóng `OQ-009`:** xem `DEC-04` (SA) — chấp nhận dùng `SAD.md`/hồ sơ thầu làm điểm
|
||
khởi đầu tham khảo cho `OPT`, với điều kiện Bước 4 vẫn phải dựng và chấm điểm ≥1 phương án độc
|
||
lập khác theo đúng quy trình bắt buộc của `SKILL.md` Bước 4.
|
||
|
||
### 4.4 Kỹ năng/tài sản tổ chức đã biết
|
||
|
||
| Tài sản/ràng buộc tổ chức | Trạng thái | Hệ quả cho `OPT`/GĐ2 | Nguồn |
|
||
|---|---|---|---|
|
||
| **AWS bắt buộc** | Cứng, đã xác nhận vòng 3 Q&A brief (không phải sở thích SA) | Loại mọi phương án cloud khác/on-prem ngay từ Bước 4; mọi dịch vụ managed đề xuất trong `SAD.md`/`docs/sections/09` (ECS Fargate/EKS, RDS, ElastiCache, MSK, OpenSearch, CloudFront, WAF, Secrets Manager, PagerDuty/OpsGenie tích hợp qua AWS) đều khả thi về mặt nền tảng — chưa khả thi về ngân sách (`OQ-005`) | `CON-03`; `00-project-brief.md` mục 5 |
|
||
| **Team thi công + vận hành** | Chưa có số thật — dùng giả định tạm "team MVP chuẩn" theo `DEC-02` (🔴); tham khảo duy nhất là đội hình đề xuất của nhà thầu (9 vị trí TB, đỉnh 10, 8 vai trò) | Ranh giới ~10 service trong `SAD.md` §3.1 (mỗi service 3–6 kỹ sư theo mô tả §3.1) **chưa được đối chiếu** với số người thật của team dự án chạy thử này — rủi ro Conway nếu team thật nhỏ hơn nhiều | `CON-05`; `DEC-02`; `SAD.md` §3.1; `OQ-002`, `OQ-008` (còn mở) |
|
||
| **Pipeline CI/CD, bảo mật vận hành đề xuất** | `docs/sections/09-van-hanh-kiem-thu.md` đề xuất: OIDC federation (CI ↔ AWS IAM), AWS Secrets Manager cho toàn bộ secret/API key đối tác, CloudWatch Logs + X-Ray/OpenTelemetry, PagerDuty/OpsGenie cho on-call | Tài liệu tự ghi rõ đây là **"đề xuất minh hoạ theo best practice AWS — không phải ràng buộc bắt buộc từ brief"** (brief không chỉ định công cụ cụ thể) — không coi là `CON`, chỉ là năng lực/công cụ tham khảo có sẵn trong thiết kế đề xuất | `docs/sections/09-van-hanh-kiem-thu.md` §9.3, ghi chú cuối |
|
||
| **RTO/RPO đề xuất** | Kế thừa từ `SAD.md` §5.3.2, nhắc lại nguyên trạng ở §9.5.2 — tự ghi rõ "là **giả định** đã chốt (brief không có SLA hợp đồng cụ thể)" | Chưa phải ràng buộc cứng đã xác nhận bởi PO/SRE thật — dùng tham khảo cho `INF`/`ARISK` ở các bước sau, không coi là số đã chốt | `SAD.md` §5.3.2, §9.5.2 |
|
||
| **Đội vận hành (Ops/SRE) sau go-live** | Chưa xác nhận nội bộ hay thuê ngoài, quy mô bao nhiêu người | Chặn thiết kế on-call/`INF` thật ở GĐ2 | `CON-08`; `OQ-008` (còn mở) |
|
||
|
||
Không có bằng chứng về năng lực/kinh nghiệm thật của tổ chức với các công nghệ cụ thể (Kafka/MSK,
|
||
OpenSearch, Kubernetes/EKS) ngoài việc chúng được đề xuất trong `SAD.md` — đây là khoảng trống
|
||
cho `ARISK` (nguồn rủi ro "Con người": *"có ai trong team từng chạy production cái này chưa?"*)
|
||
sẽ được lập ở Bước 5 (ngoài phạm vi lượt chạy này).
|
||
|
||
## 5. Giả định — `ASM-nn`
|
||
|
||
*Giả định cấp `CTX` (kiến trúc), sinh ra khi rà §3 Ràng buộc. Không copy `ASM-01…06` của BA ở
|
||
`RISK_CartCheckout_v1.0.md` §1 — chỉ tham chiếu bằng ID, theo `artifact-map.md §7`. Đánh số
|
||
độc lập, bắt đầu từ `ASM-01` cho sổ của `CTX`.*
|
||
|
||
| ID | Giả định | Cách xác minh | Hệ quả nếu sai | Chủ | Hạn |
|
||
|---|---|---|---|---|---|
|
||
| `ASM-01` | Con số lao động trong hồ sơ thầu (≈3,76 tỷ VND đã VAT, 53,02 người-tháng) nằm "trong khoảng hợp lý" mà PO có thể chấp nhận — dùng làm điểm neo tạm cho `CON-01`, KHÔNG phải ngân sách đã duyệt | PO/tài chính xác nhận bằng văn bản: ngân sách hạ tầng/tháng đã duyệt + chi phí một lần cho phép | Nếu ngân sách thật thấp hơn nhiều: `OPT` Bước 4 phải loại các phương án kiến trúc nặng (Kafka/MSK, RDS Multi-AZ đầy đủ, OpenSearch cluster đa node đề xuất trong `SAD.md`) và chuyển hướng phương án rẻ hơn ngay từ đầu, tránh thiết kế xong mới phát hiện không đủ tiền vận hành | PO | Trước khi chạy Bước 4 (`OPT`) |
|
||
| `ASM-02` | Không có mốc thời gian bên ngoài (hợp đồng/pháp lý/mùa vụ) ép buộc ngày ra mắt — deadline chỉ là "lộ trình MVP tiêu chuẩn" mang tính tham khảo, không phải cam kết cứng | PM/PO xác nhận `projectStartDate`/`projectDeadline` thật (hiện `[[CẦN ĐIỀN]]`/rỗng trong `bid-config.md`) | Nếu có deadline ngắn hơn 7 tháng ép buộc bởi bên ngoài (VD phải kịp mùa sale cụ thể): phải đánh đổi phạm vi MVP hoặc tăng song song hoá đội ngũ (rủi ro tăng chi phí phối hợp, theo chính `30-implementation-plan.md` §B7.5) | PM | Trước khi chạy Bước 4 (`OPT`) |
|
||
| `ASM-03` | Đội vận hành sau go-live sẽ là một đội SRE/Ops (nội bộ hoặc thuê ngoài) trực theo ca hành chính + escalation 24/7 — kế thừa giả định "team MVP chuẩn" của `DEC-02` (🔴), CHƯA có số người/kỹ năng thật | PM/SRE xác nhận số người, kỹ năng, ai trực, mô hình on-call cụ thể | Nếu team vận hành thực tế rất nhỏ hoặc chưa tồn tại: ranh giới ~10 service theo `SAD.md` §3.1 có thể vi phạm Conway (đội quá nhỏ để vận hành nhiều service độc lập), phải gộp bớt ranh giới ở `OPT` Bước 4/GĐ2 | PM/SRE | Trước khi chốt ranh giới service ở GĐ2 |
|
||
| `ASM-04` | Vùng cloud AWS hiện dùng trong `SAD.md` (ap-southeast-1 + region dự phòng cross-region) đáp ứng đủ yêu cầu residency của NĐ13/2023 cho dữ liệu cá nhân khách hàng + seller — NĐ13/2023 không tuyệt đối bắt buộc lưu trữ trong lãnh thổ VN cho mọi loại PII, nhưng giả định này **chưa được đại diện Pháp chế xác nhận** cho đúng mô hình marketplace hai loại chủ thể của dự án này | Đại diện Pháp chế/Bảo mật (chưa được chỉ định — kế thừa `OQ-003` của BA) xác nhận yêu cầu residency cụ thể | Nếu sai (bắt buộc lưu trong lãnh thổ VN cho một số loại dữ liệu): phải chuyển hạ tầng dữ liệu liên quan về region VN hoặc dùng nhà cung cấp trong nước, ảnh hưởng trực tiếp `CON-03`/`CON-06` và `TCO` | Legal/Security (chưa có người — `OQ-007`) | Trước GĐ2 (`DAT`/`INF`), chậm nhất trước go-live |
|
||
| `ASM-05` | Kiến trúc/stack cụ thể mô tả sẵn trong `SAD.md`/hồ sơ thầu (modular "microservices" theo bounded-context ~10 service, Kafka/MSK, RDS PostgreSQL Multi-AZ database-per-service, Redis, OpenSearch, CDN) là **đề xuất của SA/nhà thầu**, có thể dùng làm điểm khởi đầu tham khảo cho Bước 4 (`OPT`) của chính GĐ1 SA này, nhưng KHÔNG coi là đã được khách hàng/PO chốt cứng | Tech Lead + PO xác nhận: chấp nhận `SAD.md` làm baseline cho `OPT`, hay yêu cầu SA dựng phương án độc lập không neo theo tài liệu có sẵn (tránh bẫy "một phương án duy nhất" đã thắng sẵn — xem `GUIDE.md` "Bẫy thường gặp") | Nếu sai (không được neo theo `SAD.md`): Bước 4 phải dựng ≥2 phương án hoàn toàn độc lập, tốn thêm thời gian nhưng giảm rủi ro "chấm điểm để hợp thức hoá lựa chọn đã có" | Tech Lead + PO | Trước khi bắt đầu Bước 4 (`OPT`) |
|
||
| `ASM-06` | Quyết định "hoá đơn điện tử cho seller hoãn phase 2" (đã xác nhận vòng 3 brief) vẫn còn hiệu lực tại thời điểm `CTX` này — không có phản hồi trái ngược mới từ PO | PO xác nhận lại nếu có yêu cầu pháp lý mới bắt buộc hoá đơn điện tử sớm hơn (VD thay đổi quy định về hoá đơn điện tử cho sàn TMĐT) | Nếu sai: phải bổ sung `CON` pháp lý mới và mở rộng phạm vi MVP, ảnh hưởng cả `OPT`/`TCO`/lịch trình đã ước lượng trong hồ sơ thầu | PO | Trước khi chốt `OPT` Bước 4 |
|
||
|
||
Giả định sai mà hệ quả lớn ⇒ nâng thành `ARISK` và xác minh ngay trong GĐ1. `ASM-01`, `ASM-03`,
|
||
`ASM-04` có hệ quả đủ lớn (ảnh hưởng trực tiếp phạm vi/kiến trúc) — ứng viên rõ nhất để nâng
|
||
thành `ARISK-nn` khi Bước 5 (`ARISK`) chạy ở lượt sau.
|
||
|
||
## 6. Ngoài phạm vi
|
||
|
||
*Những thứ người đọc có thể tưởng tài liệu này đã có, nhưng chưa có ở lượt chạy này:*
|
||
|
||
- Khảo sát hiện trạng **kỹ thuật sâu hơn** cho các đối tác tích hợp (gọi thử sandbox thật, đọc
|
||
toàn bộ tài liệu API chi tiết của VNPay/Momo/GHN/GHTK) — §4.2 mới dừng ở mức "biết đối tác nào,
|
||
trạng thái sẵn sàng ở đâu" từ tài liệu sẵn có, chưa phải khảo sát kỹ thuật trực tiếp (gọi API
|
||
thử, đọc rate limit thật) theo đúng nghĩa `GUIDE.md` Bước 3 "Tích hợp — gọi thử nếu được".
|
||
- `OPT` (phương án + chấm điểm), `TCO` (chi phí 3 năm), `ARISK` (rủi ro kiến trúc + POC) —
|
||
chưa chạy Bước 4–5. Không thể chạy các bước này một cách có ý nghĩa cho tới khi các `OQ-005`
|
||
(ngân sách), `OQ-006` (deadline), `OQ-008` (team vận hành) được trả lời bằng số thật — chấm
|
||
điểm phương án chỉ dựa trên ước lượng hồ sơ thầu (`CON-01`, `CON-02`, `CON-05` đều "Chưa xác
|
||
định/Mềm") là chấm bừa.
|
||
- Driver của các module ngoài Giỏ hàng & Checkout (`DRV-04,05,06,09`) mới ở mức suy từ `SAD.md`,
|
||
**chưa** được xác nhận qua một vòng elicitation/BRIEF module hoá riêng như module Giỏ hàng &
|
||
Checkout — không nên coi các dòng này có độ tin cậy ngang với `DRV-01,02,03,07,08`.
|
||
- Hoá đơn/mức giá cụ thể trong `e-commerce/bid/` (rateCard, VAT, các khoản non-labor còn
|
||
`amount: null`) **không phải** là `TCO` của GĐ1 SA — đây là ước lượng dự thầu cho một hợp
|
||
đồng, khác mục đích với `TCO` (ước lượng vận hành 3 năm theo phương án kiến trúc đã chọn).
|
||
SA sẽ tự tính `TCO` riêng ở Bước 5, có thể tham khảo nhưng không sao chép con số thầu.
|
||
- Số liệu cứng/mềm ở `CON-01`, `CON-02`, `CON-05` mới là **đánh giá của SA dựa trên tài liệu
|
||
hiện có**, chưa phải xác nhận từ PO/PM/Tech Lead thật — không nên coi các dòng này đã "chốt".
|
||
|
||
## 7. Open Questions
|
||
|
||
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
|
||
|---|---|---|---|---|---|
|
||
| `OQ-001` | BA chưa ký G1 chính thức cho `BRIEF_CartCheckout` (`OQ-001`/`OQ-007` của BA còn mở: tên thật stakeholder, baseline KPI). Xác nhận: có chấp nhận để `DRV-01,02,03,07,08` giữ Confidence 🔴 và tiếp tục sang Bước 2–5 của GĐ1 SA, hay dừng chờ BA ký G1 thật? | PO sàn (điều phối) + BA | 2026-09-12 | Nâng `Confidence` của toàn bộ `CTX`/`DRV` lên 🟡/🟢; ký AG1 thật (cần PO + Tech Lead, nhưng PO không nên ký trên driver còn 🔴 nếu tránh được) | Nếu PO/BA sau này đổi phát biểu bài toán ở `BRIEF §3` (VD: bỏ yêu cầu guest checkout, hoặc đổi mô hình tách đơn) ⇒ phải viết lại `DRV-01,02` và rà lại mọi `ADR` GĐ2 tham chiếu tới chúng |
|
||
| `OQ-002` | Ràng buộc "Con người" (số đội, số người, kỹ năng, ai vận hành sau go-live) hoàn toàn chưa có thông tin — cần thiết để biến định hướng "kiến trúc module hoá độc lập theo nhóm" (NFR-07, §2.1) thành một `DRV`/`CON` có số liệu, thay vì chỉ là câu mô tả chung chung. | PM / Tech Lead | 2026-09-12 | Bước 2 (`CON` nhóm Con người); ranh giới service khả thi (Conway) ở GĐ2 | Nếu team thực tế rất nhỏ (VD 5 người) mà kiến trúc GĐ2 chia 8+ service theo domain (catalog/order/seller/payment/commission/loyalty/notification/CSKH) ⇒ vi phạm Conway, chậm release hơn cả kiến trúc gộp module |
|
||
| `OQ-003` | Người dùng (điều phối) đã chọn phạm vi **Toàn sàn** cho GĐ1 SA dù được cảnh báo driver ngoài module Giỏ hàng & Checkout (`DRV-04,05,06,09`) chỉ có nguồn `SAD.md`, chưa qua BRIEF/RISK/STAKEHOLDER module hoá riêng như module Giỏ hàng & Checkout. Xác nhận: giữ nguyên phạm vi toàn sàn cho các bước 2–5 tiếp theo, hay thu hẹp về Giỏ hàng & Checkout để có Confidence cao hơn trước? | PO sàn + Tech Lead | 2026-09-12 | Khối lượng và độ tin cậy của `OPT`/`TCO`/`ARISK` ở các bước kế tiếp | Nếu giữ toàn sàn mà không bổ sung BRIEF module hoá cho Catalog/Seller/Commission/Loyalty, `OPT` GĐ1 SA sẽ phải chấm điểm phương án dựa trên driver suy diễn (không phải driver đã xác nhận) — rủi ro chọn sai phương án kiến trúc cho các module đó, phát hiện muộn ở GĐ2/GĐ3 |
|
||
| `OQ-004` | Xác nhận ngoại lệ gate `DEC-01` (SA): chạy GĐ1 SA (Driver) khi BA chưa qua G1 — có đúng là quyết định của người có thẩm quyền điều phối dự án chạy thử, hay cần PO sàn thật xác nhận lại bằng văn bản riêng? | PO sàn (người thật, không phải vai trò) | 2026-09-12 | Tính hợp lệ của toàn bộ `CTX` này khi trình AG1 | Nếu PO thật sau này không công nhận ngoại lệ này, toàn bộ `CTX`/`DRV` phải làm lại sau khi BA ký G1 — chi phí làm lại phần Driver ước < 1 tuần (ít, vì đã có khung sẵn) |
|
||
| `OQ-005` | Ngân sách hạ tầng/tháng và chi phí một lần đã duyệt cho dự án là bao nhiêu? Nguồn tham khảo duy nhất hiện có (`e-commerce/bid/estimate.computed.json`) là ước lượng dự thầu, **chưa hợp đồng**: lao động ≈3,76 tỷ VND đã VAT cho 53,02 người-tháng; 8 khoản chi phí không lao động (hạ tầng AWS, OpenSearch, phí VNPay/Momo, phí GHN/GHTK, Email/SMS, domain/SSL/WAF, pentest, đào tạo) đều chưa có số. **Câu trả lời tạm (2026-09-12, ghi tại §4.3):** chưa nhận được xác nhận số thật từ PO trong vòng chạy này — tạm dùng số hồ sơ thầu làm mốc tham khảo duy nhất, `Confidence` 🔴, `OQ-005` **giữ mở**. | PO / tài chính | 2026-09-12 | `CON-01` (cứng/mềm); `TCO` Bước 5; loại bớt phương án ở `OPT` Bước 4 | Nếu ngân sách thật thấp hơn đáng kể so với ước lượng thầu: phải loại các phương án kiến trúc nặng (Kafka/MSK, RDS Multi-AZ đầy đủ, OpenSearch đa node) ngay từ Bước 4, tránh thiết kế xong ở GĐ2 mới phát hiện không đủ tiền vận hành (tháng thứ 13 trở đi) |
|
||
| `OQ-006` | Deadline dự án chính thức là ngày nào (nếu có)? Hai con số tham khảo hiện KHÔNG khớp: brief nói "~9-12 tháng" (định tính), hồ sơ thầu tính "7 tháng thực hiện" (teamSize trung bình 9, đỉnh điểm 10 người) + 12 tháng bảo hành — cả hai đều CHƯA được PO xác nhận là mốc thật (`bid-config.projectDeadline` rỗng). **Câu trả lời tạm (2026-09-12, ghi tại §4.3):** chưa nhận được xác nhận mốc thật từ PO trong vòng chạy này — tạm giữ song song cả hai con số tham khảo (7 tháng thầu / 9–12 tháng brief), không chọn một, `Confidence` 🔴, `OQ-006` **giữ mở**. | PO / PM | 2026-09-12 | `CON-02`; kịch bản thời gian ở `OPT` Bước 4 | Nếu deadline thật ngắn hơn 7 tháng (do ràng buộc bên ngoài mới xuất hiện): phải cắt phạm vi MVP hoặc tăng song song hoá đội ngũ — theo chính hồ sơ thầu (§B7.5), đòn bẩy này làm tăng chi phí phối hợp và rủi ro tích hợp, không miễn phí |
|
||
| `OQ-007` | Ai là đại diện Pháp chế/Bảo mật xác nhận yêu cầu về nơi lưu trữ dữ liệu (residency) theo NĐ13/2023 cho mô hình marketplace có hai loại chủ thể dữ liệu (khách hàng + seller, gồm cả giấy tờ KYC)? *(kế thừa `OQ-003` của BA — vẫn chưa có người sau khi BA chạy GĐ1)* | PO sàn (chỉ định người) | 2026-09-12 | `CON-06`, `ASM-04`; ranh giới hạ tầng dữ liệu ở `DAT`/`INF` GĐ2 | Nếu về sau phát hiện bắt buộc lưu trữ trong lãnh thổ VN cho một số loại PII: phải chuyển hạ tầng dữ liệu liên quan (hoặc toàn bộ) về region VN/nhà cung cấp trong nước — phát hiện càng muộn (VD sau khi GĐ2 đã chốt `DAT`/`INF` theo `ap-southeast-1`) thì chi phí sửa càng cao, có thể phải viết lại `ADR` hạ tầng |
|
||
| `OQ-008` | Đội vận hành (Ops/SRE) sau go-live là nội bộ PO hay thuê ngoài, quy mô bao nhiêu người, có sẵn sàng trực 24/7 cho sự cố nghiêm trọng theo giả định NFR-08 hay chưa? | PM / SRE | 2026-09-12 | `CON-05`, `CON-08`; thiết kế on-call/`INF` ở GĐ2; ranh giới service (Conway) | Nếu chưa có đội ops sẵn sàng khi go-live: phải tính thêm chi phí thuê ngoài/tuyển dụng vào `TCO` Bước 5, và mục tiêu uptime 99.9% (`DRV-05`) có thể không đạt được trong thực tế dù kiến trúc đúng thiết kế |
|
||
| ~~`OQ-009`~~ | *(Đã đóng ở v1.2, xem "Open Question đã đóng" ngay dưới)* | — | — | — | — |
|
||
|
||
### 7.1 Open Question đã đóng *(mới từ v1.2)*
|
||
|
||
| ID | Câu hỏi | Trả lời | Ngày đóng | Người trả lời | Ghi chú |
|
||
|---|---|---|---|---|---|
|
||
| `OQ-009` | Có chấp nhận dùng kiến trúc/stack đã đề xuất sẵn trong `SAD.md`/hồ sơ thầu (modular microservices ~10 service, Kafka/MSK, RDS Multi-AZ, OpenSearch, Redis) làm điểm khởi đầu cho Bước 4 (`OPT`) của GĐ1 SA, hay yêu cầu SA dựng phương án hoàn toàn độc lập? | **Chấp nhận** dùng `SAD.md`/hồ sơ thầu làm **điểm khởi đầu tham khảo** cho một phương án ở Bước 4 — với điều kiện bắt buộc: Bước 4 vẫn phải dựng và chấm điểm ≥1 phương án độc lập khác theo đúng `SKILL.md` Bước 4, không mặc định `SAD.md` là phương án thắng sẵn. Xem §4.3, `DEC-04` (SA). | 2026-09-12 | Ghi chú người duyệt (đại diện PO/điều phối dự án) | `Confidence` của quyết định này: 🟡 (rõ ràng về điều kiện áp dụng, nhưng người duyệt là ghi chú điều phối, không phải PO/Tech Lead ký trực tiếp qua `sign`) |
|
||
|
||
---
|
||
|
||
## Tự chấm
|
||
|
||
### ① Bảng tự chấm Gate AG1 *(`workflow.md §2`)*
|
||
|
||
| # | Tiêu chí | ☐/✅ | Ghi chú |
|
||
|---|---|---|---|
|
||
| 1 | `CTX` có `DRV-nn`, mỗi driver ghi rõ áp lực kinh doanh | ✅ | 9 `DRV` (`DRV-01…09`), mỗi dòng có áp lực định lượng (nơi có thể), nguồn, thuộc tính chất lượng bị ép. `DRV-04/05` dùng số mô tả định tính "lớn"/"99.9%" đã được chính nguồn (`00-project-brief`) gắn nhãn "giả định mặc định", không phải SA tự bịa |
|
||
| 2 | `CTX` có `CON-nn` (ràng buộc 6 nhóm) | ✅ *(với lưu ý)* | Đủ 6 nhóm (`CON-01` Tiền … `CON-09` Tổ chức/Vận hành, xem §3). Nhưng phần lớn giá trị "Cứng/Mềm" ghi "Chưa xác định" vì nguồn chỉ là ước lượng hồ sơ thầu (Draft, chưa hợp đồng) — chưa phải số PO đã duyệt. Đạt tiêu chí "có mặt và đủ 6 nhóm", chưa đạt mức "đã xác nhận thật" |
|
||
| 3 | `CTX` mô tả hiện trạng as-is: hệ thống, dữ liệu, tích hợp, hợp đồng vendor đang có | ✅ *(với lưu ý)* | §4 mới bổ sung ở v1.2: (a) khẳng định greenfield + hệ quả, (b) bảng trạng thái 9 đối tác tích hợp (VNPay/Momo/GHN/GHTK/Email-SMS/Ngân hàng/OAuth/hoá đơn điện tử), (c) tài sản thiết kế đã có (`SAD.md`/hồ sơ thầu, có ghi rõ ranh giới thẩm quyền), (d) kỹ năng/tài sản tổ chức. "Hệ thống/dữ liệu đang có" = None (greenfield, đã xác nhận nguồn `PROFILE_e-commerce.md`); "hợp đồng vendor đang có" = None (mọi đối tác đều 🔴/🔴🔴 chưa sandbox/hợp đồng thật) — đạt tiêu chí "mô tả hiện trạng", nội dung chính là "hiện trạng = chưa có gì tự vận hành, có đối tác bên ngoài chưa sẵn sàng" |
|
||
| 4 | `OPT` có ≥2 phương án, chấm điểm, nêu phương án bị loại | ☐ | **Chưa tạo file `OPT`** — thuộc Bước 4, ngoài phạm vi lượt chạy này; phụ thuộc `OQ-005`/`OQ-006` trả lời trước (đã có nền: `OQ-009` đóng ở §4.3/§7.1 cho phép dùng `SAD.md` làm điểm khởi đầu tham khảo) |
|
||
| 5 | `TCO` có chi phí 3 năm, ≥2 kịch bản tải | ☐ | **Chưa tạo file `TCO`** — thuộc Bước 5, ngoài phạm vi lượt chạy này |
|
||
| 6 | `ARISK` có rủi ro cao kèm chủ + biện pháp | ☐ | **Chưa tạo file `ARISK`** — thuộc Bước 5, ngoài phạm vi lượt chạy này. §4.2/§4.4 đã nêu sẵn một số ứng viên rủi ro (đối tác chưa sandbox, năng lực team chưa xác nhận với Kafka/MSK/OpenSearch/EKS) để Bước 5 kế thừa |
|
||
| 7 | Rủi ro cao chưa chứng minh được có kế hoạch POC | ☐ | Phụ thuộc `ARISK`, chưa làm |
|
||
|
||
**Kết luận tự chấm AG1:** **Chưa đủ điều kiện ký** — đúng như phạm vi được giao (Driver +
|
||
Ràng buộc + Hiện trạng). 3/7 tiêu chí ✅. Cần chạy tiếp Bước 4–5 (`OPT`, `TCO`, `ARISK`) trước
|
||
khi PO + Tech Lead có thể ký AG1, và cần `OQ-005`/`OQ-006`/`OQ-007`/`OQ-008` được trả
|
||
lời bằng số/người thật trước khi Bước 4–5 có ý nghĩa (`OQ-009` đã đóng). Ngoài ra, ngay cả `DRV` và `CON` đang ở
|
||
`Confidence 🔴` vì lý do preflight (BA chưa ký G1) và vì `CON` dựa trên ước lượng hồ sơ thầu
|
||
chưa xác nhận — nên **không đủ điều kiện baseline `CTX`** dù đã điền đủ nội dung của mục Driver,
|
||
Ràng buộc và Hiện trạng.
|
||
|
||
### ② Checklist D1–D12 *(`design-rules.md`)*
|
||
|
||
| # | Mục | ☐/✅ | Ghi chú |
|
||
|---|---|---|---|
|
||
| D1 | Một ADR một quyết định | N/A | Tài liệu này không có `ADR` |
|
||
| D2 | Không NFR định tính; đủ 4 câu | 🟡 Một phần | Driver không phải `QAS` nên không bắt buộc đủ "4 câu", nhưng đã cố định lượng tối đa có thể (DRV-01,02,03,04,06,07,08 có con số/nguồn cụ thể); `DRV-05,09` còn dùng mô tả định tính do chính nguồn brief chỉ ghi ở mức đó — đã gắn nhãn rõ "giả định mặc định", không che giấu |
|
||
| D3 | Nêu phương án bị loại | N/A | `OPT` (nơi bắt buộc nêu phương án loại) chưa chạy ở lượt này; `CON-05` đã ghi rõ số liệu team hồ sơ thầu KHÔNG được coi là phương án đã chọn |
|
||
| D4 | Sơ đồ khai báo mức + legend | N/A | Không có sơ đồ mới thêm ở §3/§5 |
|
||
| D5 | Interface có chủ/contract | N/A | Chưa tới `ICD` (GĐ2); `CON-04`/§4.2 đã nêu đối tác tích hợp bắt buộc và trạng thái sẵn sàng nhưng chưa có contract thật |
|
||
| D6 | Phụ thuộc ngoài process có timeout/retry | N/A | Chưa tới `FAIL`/`SAD` (GĐ2); §4.2 kế thừa nguyên trạng timeout/retry **đề xuất** từ `SAD.md` §3.4 (VNPay/Momo 10s, GHN/GHTK 8s, Email/SMS 5s) — ghi rõ là đề xuất chưa kiểm chứng với sandbox thật, không phải ràng buộc SA tự đặt mới |
|
||
| D7 | Một chủ sở hữu dữ liệu | N/A | Chưa tới `DAT` (GĐ2) |
|
||
| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | N/A | Chưa tới `AGD`/`FIT` (GĐ3) |
|
||
| D9 | Con số hạ tầng quy ra tiền + nguồn | 🟡 Một phần | `CON-01` có trích dẫn con số (≈3,76 tỷ VND đã VAT) kèm nguồn (`estimate.computed.json`), nhưng đây là số của hồ sơ thầu (nhân công + VAT), KHÔNG phải con số hạ tầng quy đổi kiến trúc — `TCO`/`INF` thật (nơi D9 áp dụng đầy đủ) chưa chạy. §4.3/§4.4 không thêm số hạ tầng mới, chỉ dẫn nguồn cho các bước sau |
|
||
| D10 | Không quyết định thay người có thẩm quyền | ✅ | Mọi chỗ chưa rõ (ngân sách, deadline, đội vận hành, residency pháp lý) đều ghi `OQ-005…008` kèm hệ quả phương án ngược bằng số/định tính rõ ràng, không tự quyết. `OQ-009` đã đóng nhưng bằng **ghi chú điều phối** (không phải PO/Tech Lead ký trực tiếp) — ghi rõ mức độ thẩm quyền thật ở §7.1, không che giấu. Riêng việc gán "Cứng/Mềm" cho từng `CON` và trạng thái 🔴/🔴🔴/🟡/🟢/⏸️ cho từng đối tác ở §4.2 là đánh giá kỹ thuật của SA dựa trên nguồn hiện có, không phải quyết định thay PO |
|
||
| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §6 "Ngoài phạm vi" đầy đủ (đã cập nhật: as-is kỹ thuật sâu hơn — gọi sandbox thật — vẫn ngoài phạm vi); §5 có `ASM-01`…`ASM-06` cấp `CTX`, mỗi cái có cách xác minh, hệ quả, chủ, hạn (không sửa ở lượt này) |
|
||
| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có câu chuẩn ngay sau Change Log |
|
||
|
||
### ③ Danh sách `OQ` mở kèm người phải trả lời, chặn gì
|
||
|
||
Xem bảng đầy đủ ở §7. Tóm tắt tám câu hỏi đang chặn (`OQ-009` đã đóng, xem §7.1): **(1)** `OQ-001`
|
||
chặn nâng `Confidence` của toàn `CTX` — hỏi PO sàn + BA; **(2)** `OQ-002` chặn số liệu team thật
|
||
ở `CON-05` — hỏi PM/Tech Lead; **(3)** `OQ-003` chặn quyết định giữ/thu hẹp phạm vi toàn sàn —
|
||
hỏi PO + Tech Lead; **(4)** `OQ-004` chặn tính hợp lệ của ngoại lệ gate `DEC-01` — hỏi PO sàn
|
||
(người thật); **(5)** `OQ-005` chặn `CON-01`/`TCO` — hỏi PO/tài chính (có câu trả lời tạm, xem
|
||
§7); **(6)** `OQ-006` chặn `CON-02`/kịch bản thời gian ở `OPT` — hỏi PO/PM (có câu trả lời tạm);
|
||
**(7)** `OQ-007` chặn `CON-06`/`ASM-04` (residency pháp lý) — hỏi PO (chỉ định người); **(8)**
|
||
`OQ-008` chặn `CON-05`/`CON-08` (đội vận hành) — hỏi PM/SRE.
|
||
|
||
**Nhắc:** AG1 cần **PO + Tech Lead ký** (điền `Approved by` vào header `OPT`) trước khi chạy
|
||
`/sa-2-architecture`. `OPT` chưa tồn tại — phải chạy tiếp Bước 4–5 của `sa-1-context` trước, và
|
||
nên có `OQ-005/006/007/008` trả lời trước để Bước 4–5 không phải chấm bừa.
|