init git

.claude/skills/ba-1-discovery/GUIDE.md

@@ -0,0 +1,146 @@
+# Hướng dẫn sử dụng — `ba-1-discovery` (Giai đoạn 1)
+
+## Giai đoạn này giải quyết gì
+
+Đầu vào là một câu mơ hồ kiểu *"khách muốn làm màn hình quản lý đối soát"*. Đầu ra là một
+bài toán phát biểu được, có chủ, có cách đo thành công, có danh sách yêu cầu mức nghiệp vụ
+đã xếp ưu tiên.
+
+**Không làm ở giai đoạn này:** vẽ màn hình, chọn công nghệ, viết user story chi tiết, ước
+lượng công sức. Thấy mình đang làm mấy thứ đó ⇒ đã trượt sang GĐ2/GĐ3.
+
+## Khi nào gọi
+
+| Tình huống | Có nên gọi |
+|---|---|
+| Nhận module hoàn toàn mới | ✅ Chạy đầy đủ |
+| Enhancement trên module đã có | ✅ Chạy rút gọn — chỉ `RQ` + rủi ro, bỏ `BRIEF` đầy đủ |
+| Sửa lỗi nghiệp vụ nhỏ | ❌ Sang thẳng `ba-3-specification` |
+| Sắp họp với khách, cần bộ câu hỏi | ✅ Gọi và nói rõ "chỉ cần bộ câu hỏi cho buổi họp" |
+| Đã có SRS rồi, chỉ muốn bổ sung KPI | ✅ Gọi rút gọn, nói rõ chỉ cần mục 4 của BRIEF |
+
+## Cú pháp
+
+```
+/ba-1-discovery <PROJECT|US-id> [--mode new|enhancement] [--out <đường-dẫn>] [go]
+```
+
+| Tham số | Ý nghĩa |
+|---|---|
+| `--mode new` | Module mới — chạy đủ 6 bước (mặc định khi không đoán được) |
+| `--mode enhancement` | Chỉ chạy Bước 1 (rà stakeholder bị ảnh hưởng), Bước 4 (`RQ`), Bước 6 (rủi ro) |
+| `go` | Bỏ bước dừng xác nhận input |
+
+Kèm file input bằng cách đính kèm trong hội thoại hoặc ghi đường dẫn:
+
+```
+/ba-1-discovery Settlement — input: d:/Kakao/Docs/yeu-cau-khach.docx, biên bản họp 2026-08-22
+```
+
+## Chuẩn bị gì trước khi gọi
+
+**Tối thiểu** (không có thì skill vẫn chạy nhưng sẽ sinh nhiều `OQ`):
+- Câu mô tả yêu cầu ban đầu, dù mơ hồ
+- Tên người có thể trả lời câu hỏi nghiệp vụ
+
+**Nên có** (chất lượng output tăng rõ rệt):
+- Biên bản/email trao đổi với khách
+- Ảnh chụp màn hình hoặc file Excel người dùng đang dùng thủ công
+- Số liệu hiện trạng: bao nhiêu giao dịch/ngày, bao nhiêu người thao tác
+
+## Quy trình 6 bước — bạn tham gia ở đâu
+
+| Bước | Skill làm | Bạn làm |
+|---|---|---|
+| 1. Stakeholder | Sinh khung, gợi ý nhóm hay bị sót | Điền **tên thật**, xác nhận ai ký được |
+| 2. Chuẩn bị khai thác | Sinh bộ câu hỏi theo vai trò | Duyệt, cắt bớt, gửi trước cho khách |
+| 3. Khai thác | Sinh mẫu biên bản | **Đi họp và ghi** — skill không họp thay bạn |
+| 4. Chưng cất `RQ` | Chuyển phát ngôn → RQ, gắn MoSCoW | Xác nhận MoSCoW với PO |
+| 5. Mục tiêu & phạm vi | Viết `BRIEF`, đòi baseline | Cung cấp/đi hỏi baseline |
+| 6. Rủi ro & giả định | Rà 4 chỗ giả định, 6 loại rủi ro | Chỉ định người chịu trách nhiệm |
+
+🔴 **Bước 3 là bước skill không làm thay được.** Nó chuẩn bị câu hỏi và mẫu biên bản; việc
+ngồi nghe khách nói là của bạn. Đưa biên bản thô vào, skill sẽ chưng cất thành `RQ`.
+
+## Bạn sẽ nhận được gì
+
+Bốn file trong `ba-output/<PROJECT>/01-discovery/`:
+
+```
+BRIEF_<PROJECT>_v1.0.md           ← tài liệu chính, PO ký cái này
+STAKEHOLDER_<PROJECT>_v1.0.md
+ELICITATION_<chủ đề>_<ngày>.md    ← mỗi buổi một file
+RISK_<PROJECT>_v1.0.md
+```
+
+Cộng với ba bảng tự chấm in ra màn hình: Gate G1 · quy tắc viết W1–W13 · danh sách `OQ` mở.
+
+## Ví dụ hội thoại
+
+```
+Bạn:    /ba-1-discovery Settlement
+        Khách bảo cần màn hình đối soát doanh thu POS với hệ thống.
+        Đính kèm: bien-ban-hop-2026-08-22.md
+
+Claude: [Bước 0]
+        Input dùng được:
+        | bien-ban-hop-2026-08-22.md | Biên bản họp khởi động | Cao |
+        | ba-output/Settlement/ | Chưa tồn tại | — |
+
+        Phân loại: module MỚI (chưa thấy artifact nào của Settlement).
+
+        Người cần tiếp cận — tôi suy ra từ biên bản, xác nhận giúp:
+        - Người quyết định: chị Lan (Trưởng phòng Tài chính)?
+        - Người sử dụng: nhân viên đối soát — chưa biết tên
+        - Bị ảnh hưởng: cửa hàng/POS operator — chưa xác nhận
+        - Cung cấp thông tin: ai quản trị hệ thống POS?
+
+        Cách hiểu: bài toán gốc là phát hiện chênh lệch muộn (cuối tháng), không phải
+        "thiếu một màn hình". Tôi sẽ viết BRIEF theo hướng đó.
+
+        Ghi vào ba-output/Settlement/01-discovery/. Xác nhận giúp tôi 4 điểm trên.
+
+Bạn:    Đúng rồi. Người dùng là anh Sơn + 2 bạn. POS do bên NCC X vận hành, đầu mối anh Huy.
+
+Claude: [sinh STAKEHOLDER + bộ câu hỏi cho từng người + khung BRIEF với các OQ]
+```
+
+## Lỗi thường gặp
+
+**"Skill viết BRIEF toàn `OQ`, gần như trống."**
+Đúng như thiết kế. Chưa đi hỏi khách thì chưa có thông tin, và quy tắc số 1 là không bịa.
+Danh sách `OQ` chính là danh sách việc bạn cần đi hỏi. Hỏi xong đưa biên bản vào, chạy lại.
+
+**"Khách đã nói rõ muốn gì rồi, sao còn phải phát biểu bài toán?"**
+Vì thứ khách nói thường là **giải pháp**, không phải vấn đề. "Cần nút export" → hỏi "xuất
+ra để làm gì" → hoá ra để gửi kế toán đối chiếu → hoá ra vấn đề thật là hai hệ thống không
+khớp số. Giải pháp đúng có thể không phải nút export.
+
+**"Không lấy được baseline, khách không có số."**
+Đừng bỏ trống. Ghi `OQ` + đề xuất cách đo: bấm giờ 3 ngày, đếm số ca lỗi tháng trước, hoặc
+lấy log hệ thống cũ. Baseline ước lượng có ghi rõ cách ước lượng vẫn tốt hơn không có gì.
+
+**"Must chiếm 90% danh sách RQ."**
+Việc phân loại chưa xảy ra. Hỏi PO đúng một câu: *"Nếu chỉ kịp một nửa thì cắt cái nào?"*
+— câu này ép ra thứ tự thật.
+
+**"Có hai bên nói ngược nhau, tôi chọn bên nào?"**
+Không chọn. Ghi cả hai vào mục 6 của `STAKEHOLDER`, tạo `OQ`, đưa PO quyết. BA tự chọn là
+vi phạm nguyên tắc 2 và là nguồn gốc của CR ở UAT.
+
+## Ra khỏi giai đoạn này khi nào
+
+Đủ cả ba:
+
+1. Bảng tự chấm G1 toàn ✅
+2. PO đã điền `Approved by` vào header `BRIEF`
+3. Không còn `OQ` nào chặn việc phân rã user story
+
+Rồi chạy `/ba-2-analysis <PROJECT>`.
+
+## Liên quan
+
+- Tiêu chí gate G1: `../ba-lifecycle/references/workflow.md` §2
+- Quy tắc viết: `../ba-lifecycle/references/writing-rules.md`
+- Template: `templates/project-brief.md` · `templates/stakeholder-map.md` ·
+  `templates/elicitation-guide.md` · `templates/risk-register.md`

.claude/skills/ba-1-discovery/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: ba-1-discovery
+description: Giai đoạn 1 của quy trình BA — khai thác và làm rõ yêu cầu. Dùng khi nhận một ý tưởng/module mới còn mơ hồ và cần xác định stakeholder, phát biểu bài toán, mục tiêu kinh doanh kèm KPI, phạm vi in/out, yêu cầu mức nghiệp vụ (RQ), rủi ro và giả định. Kích hoạt khi người dùng nói "khách hàng muốn làm X", "phân tích yêu cầu mới", "chuẩn bị họp với khách", "cần bộ câu hỏi phỏng vấn", "viết project brief", "xác định stakeholder", "làm rõ scope". Output ghi vào ba-output/<PROJECT>/01-discovery/ và phải qua Gate G1 trước khi sang ba-2-analysis.
+---
+
+# GĐ1 · DISCOVERY — Khai thác & làm rõ yêu cầu
+
+Mục tiêu duy nhất: **chuyển một mong muốn mơ hồ thành một bài toán phát biểu được, có
+người chịu trách nhiệm, có cách đo thành công.** Chưa bàn giải pháp, chưa vẽ màn hình.
+
+Output: `BRIEF` · `STAKEHOLDER` · `ELICITATION` · `RISK` trong `ba-output/<PROJECT>/01-discovery/`
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa yêu cầu** — thiếu thông tin ⇒ `OQ-nnn`, không điền giá trị "hợp lý".
+2. **Không quyết định thay PO** — trình phương án kèm khuyến nghị, PO chốt.
+3. **Mọi phát biểu phải truy vết được** về một stakeholder cụ thể. Không nguồn ⇒ `ASM-nn`.
+4. **Không ghi đè tài liệu đã qua gate** — sửa qua `CR-nnn` kèm Change Log.
+
+Nạp thêm: `../ba-lifecycle/references/domain-profiles.md` (ba trục quyết định khối lượng
+công việc) · `../ba-lifecycle/references/writing-rules.md` (13 quy tắc W1–W13) ·
+`../ba-lifecycle/references/artifact-map.md` §2 (header bắt buộc) ·
+`../ba-lifecycle/references/diagram-rules.md` (ranh giới hệ thống, ma trận stakeholder, 5-Why).
+
+Ví dụ minh hoạ ở nhiều domain: `examples.md`.
+
+## Bước 0 — Chốt input rồi dừng lại
+
+**Chưa được ghi file.** Làm sáu việc rồi **dừng chờ người dùng trả lời**:
+
+1. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Chưa có ⇒ **đây là skill tạo nó**: đề
+   xuất `PRODUCT · LIFECYCLE · RIGOR` kèm lý do, và hỏi xác nhận. Ba trục này quyết định
+   khối lượng của chính lần chạy này.
+2. **Input dùng được** — bảng `File/Nguồn | Vai trò | Độ tin cậy`. Gồm: file người dùng đưa
+   trong hội thoại (ưu tiên cao nhất), file trong lệnh, và những gì tự tìm thấy trong
+   `ba-output/`, `.docs/`, `docs/`.
+3. **Khối lượng theo profile** — nêu rõ sẽ chạy đủ hay rút gọn:
+   `LIFECYCLE = enhancement` ⇒ chỉ `RQ` + rủi ro · `RIGOR = light` ⇒ bỏ biên bản chính thức,
+   `STAKEHOLDER` chỉ 2 nhóm, chỉ cần 1 `GOAL` có baseline (xem `workflow.md` §2 — G1).
+4. **Ai là người trả lời được** — liệt kê tên/vai trò cần tiếp cận. Chưa biết ⇒ nói rõ.
+5. **Cách hiểu bài toán** — 2–3 câu, kèm tên file định ghi ra.
+6. **Hỏi người dùng** xác nhận năm điểm trên.
+
+Bỏ qua bước dừng khi lệnh có `go` / `chạy luôn` — khi đó ghi phần tự đánh giá input vào
+mục Open Questions của `BRIEF`.
+
+## Thực hiện — 6 bước
+
+### Bước 1 — Stakeholder trước, yêu cầu sau
+
+Làm việc này **đầu tiên**. Yêu cầu không có chủ là yêu cầu không ai bảo vệ khi cắt scope.
+
+Điền `templates/stakeholder-map.md`. Bốn nhóm, thiếu nhóm nào cũng là lỗ hổng:
+
+| Nhóm | Câu hỏi nhận diện | Rủi ro nếu bỏ sót |
+|---|---|---|
+| **Quyết định** | Ai ký duyệt? Ai cắt được scope? | Làm xong bị bác |
+| **Sử dụng** | Ai ngồi trước màn hình mỗi ngày? | Đúng spec nhưng không ai dùng |
+| **Bị ảnh hưởng** | Quy trình của ai thay đổi? Ai mất/được việc? | Kháng cự lúc go-live |
+| **Cung cấp thông tin** | Ai biết nghiệp vụ hiện tại? Ai giữ dữ liệu? | Hiểu sai AS-IS |
+
+Mỗi stakeholder: `STK-nn` · tên thật · vai trò · **mức quan tâm × mức ảnh hưởng** · kênh
+liên lạc · người thay thế khi vắng.
+
+🔴 Ba nhóm hay bị bỏ sót nhất, phải hỏi đích danh: **vận hành/CS** (người nhận cuộc gọi
+khiếu nại), **kế toán/đối soát** (người chịu hậu quả nếu số liệu sai), **bộ phận pháp
+chế/bảo mật** (người có quyền phủ quyết muộn nhất và đau nhất).
+
+### Bước 2 — Chuẩn bị khai thác
+
+Sinh bộ câu hỏi từ `templates/elicitation-guide.md`, **cắt theo đúng người sắp gặp** —
+đừng đưa một danh sách 60 câu chung chung.
+
+Chọn kỹ thuật theo tình huống:
+
+| Tình huống | Kỹ thuật | Vì sao |
+|---|---|---|
+| Chưa biết gì về nghiệp vụ | Phỏng vấn 1-1 + quan sát tại chỗ | Người ta kể quy trình *nên thế*, làm mới lộ quy trình *thật* |
+| Nhiều bên mâu thuẫn | Workshop có facilitator | Bắt mâu thuẫn lộ ra sớm, rẻ hơn lộ ở UAT |
+| Đã có hệ thống cũ | Phân tích tài liệu + soi dữ liệu thật | Dữ liệu không biết nói dối |
+| Đông người dùng cuối | Khảo sát + phỏng vấn sâu vài người | Định lượng rồi mới định tính |
+| Yêu cầu mơ hồ về UX | Prototype thấp + phản ứng | Người ta phê bình giỏi hơn mô tả |
+
+**Trước buổi làm việc luôn gửi trước agenda + câu hỏi.** Người được hỏi cần thời gian tra
+số liệu; hỏi bất ngờ thì nhận về phỏng đoán.
+
+### Bước 3 — Khai thác và ghi biên bản
+
+Ghi vào `ELICITATION_<phạm vi>_<ngày>.md`. Mỗi buổi một file, không gộp.
+
+Quy tắc ghi biên bản:
+
+- Ghi **nguyên văn** câu trả lời quan trọng, không diễn giải lại. Diễn giải làm mất sắc thái
+  ("thường thì" ≠ "luôn luôn").
+- Tách rõ ba loại phát ngôn: **sự thật** (đo được) · **ý kiến** (mong muốn) · **giả định**
+  (tưởng là thật). Trộn ba thứ này là lỗi kinh điển.
+- Câu trả lời mâu thuẫn với buổi khác ⇒ ghi cả hai, đánh dấu `⚠️ mâu thuẫn với STK-03 ngày …`,
+  **không tự chọn bên nào**.
+- Kết thúc mỗi buổi: đọc lại tóm tắt cho người được hỏi xác nhận ngay tại chỗ.
+
+Năm câu phải hỏi trong mọi buổi, hỏi nguyên văn:
+
+1. "Hôm nay anh/chị làm việc này thế nào? Cho tôi xem một ca thật được không?"
+2. "Chỗ nào mất thời gian nhất / hay sai nhất?"
+3. "Trường hợp ngoại lệ nào hay gặp? Lúc đó xử lý sao?"
+4. "Nếu hệ thống mới làm được đúng một thứ thôi, anh/chị chọn thứ gì?"
+5. "Làm thế nào để biết dự án này thành công?" *(đây là nguồn của KPI)*
+
+### Bước 4 — Chưng cất thành `RQ-nnn`
+
+Chuyển phát ngôn thành yêu cầu mức nghiệp vụ. **Không phải chức năng, không phải màn hình.**
+
+```
+RQ-nnn | <ai> phải <đạt được gì>, thay vì <cách làm hiện tại>.
+         Nguồn: STK-nn, biên bản <ngày> · MoSCoW: … · Liên quan: GOAL-nn
+         Giải pháp khách gợi ý: <nếu có>
+```
+
+Mỗi `RQ`: phát biểu · nguồn (`STK-nn` + ngày) · MoSCoW · liên kết `GOAL-nn`.
+
+Ví dụ ở ba domain khác nhau (bán lẻ, y tế, logistics): `examples.md`.
+
+**Quy tắc MoSCoW**: Must là *"không có thì bản phát hành này vô nghĩa"*, không phải *"rất
+quan trọng"*. Nếu >60% số RQ là Must thì việc phân loại chưa xảy ra — quay lại hỏi PO
+"nếu chỉ kịp một nửa, cắt cái nào".
+
+🔴 **Bẫy giải pháp giả dạng yêu cầu.** Thứ khách nói ra thường là **giải pháp họ nghĩ ra**,
+không phải vấn đề của họ. Hỏi ngược cho tới khi ra vấn đề gốc: *"Cái đó để làm gì? Sau khi
+có nó thì anh/chị làm gì tiếp?"* — câu trả lời mới là `RQ`.
+
+Ghi giải pháp khách đề xuất vào cột riêng "Giải pháp khách gợi ý": có giá trị tham khảo,
+nhưng không phải yêu cầu. Rất thường xuyên, giải pháp đúng khác thứ khách yêu cầu và rẻ hơn
+— ba ca thật ở ba domain: `examples.md`.
+
+### Bước 5 — Mục tiêu, KPI và phạm vi
+
+Điền `templates/project-brief.md`.
+
+**`GOAL-nn` phải có baseline.** Không có số hiện tại thì GĐ5 không đo được gì:
+
+```
+GOAL-nn | <mục tiêu>
+          Baseline: <số hiện tại> (<kỳ đo>, nguồn: <ai/đâu>)
+          Mục tiêu: <số đích> · Đo bằng: <định nghĩa phép đo>
+          Ai đo: <người> · Tần suất: <…>
+```
+
+Chưa có baseline ⇒ ghi `OQ` và **đề xuất cách đo baseline** kèm chi phí ước tính, đừng bỏ
+trống. Baseline ước lượng có ghi rõ cách ước lượng vẫn tốt hơn không có gì — ví dụ cả hai
+trường hợp: `examples.md`.
+
+**Phạm vi phải viết cả hai vế.** Vế "ngoài phạm vi" quan trọng hơn, vì nó chặn tranh cãi
+sau này. Mỗi mục out-of-scope ghi kèm lý do và "sẽ xử lý ở đâu/khi nào".
+
+### Bước 6 — Rủi ro và giả định
+
+Điền `templates/risk-register.md`.
+
+**Giả định `ASM-nn`** — mọi thứ bạn tin là đúng nhưng chưa ai xác nhận. Bắt buộc rà bốn chỗ
+này, đây là nơi giả định hay ẩn nấp:
+
+- Dữ liệu: "hệ thống cũ có sẵn trường này" — đã mở DB ra xem chưa?
+- Tích hợp: "API bên kia trả về realtime" — đã đọc tài liệu của họ chưa?
+- Con người: "vận hành sẽ nhập liệu hằng ngày" — đã hỏi vận hành chưa?
+- Pháp lý: "được phép lưu thông tin này" — đã hỏi pháp chế chưa?
+
+Mỗi `ASM` phải có **cách xác minh** và **hệ quả nếu sai**. Giả định sai mà hệ quả lớn ⇒
+nâng thành `RISK` và xác minh ngay trong GĐ1, đừng để sang GĐ3.
+
+## Trước khi kết thúc
+
+In ba thứ:
+
+**① Bảng tự chấm Gate G1** (checklist ở `../ba-lifecycle/references/workflow.md` §2) dạng
+☐/✅. Mục chưa đạt phải nói rõ thiếu gì — **không đánh ✅ cho có**.
+
+**② Checklist W1–W13** (`../ba-lifecycle/references/writing-rules.md`) dạng ☐/✅.
+
+**③ Danh sách `OQ` mở** kèm người phải trả lời và deadline đề xuất.
+
+Chấm G1 theo đúng `RIGOR` đã khai — áp bảng "Bớt ở light" / "Thêm ở strict" ở
+`../ba-lifecycle/references/workflow.md` §2, và **nói rõ đang chấm ở mức nào**.
+
+Rồi nhắc người dùng: G1 cần **PO ký** (điền `Approved by` vào header); mức `strict` cần thêm
+**Bảo mật/Pháp chế**. Ký xong mới chạy `/ba-2-analysis`.
+
+## Bẫy thường gặp
+
+**Nhảy sang giải pháp quá sớm.** Dấu hiệu: trong `BRIEF` đã xuất hiện tên màn hình, tên
+nút, tên bảng dữ liệu. GĐ1 chỉ nói *vấn đề* và *kết quả mong muốn*. Thấy mình đang vẽ màn
+hình ⇒ dừng, quay lại hỏi "vấn đề gốc là gì".
+
+**Chỉ hỏi người ký duyệt.** Người ký duyệt mô tả quy trình *nên thế*. Người ngồi làm mỗi
+ngày mới biết quy trình *thật* — và họ là người sẽ dùng hệ thống.
+
+**Nhận yêu cầu qua nhiều lớp trung gian.** "Sếp bảo là khách muốn…" — mỗi lớp truyền tin
+làm mất một phần ngữ cảnh. Ghi rõ trong nguồn là thông tin gián tiếp, và tìm cách xác minh
+với người gốc.
+
+**Ghi biên bản sau buổi họp một tuần.** Trí nhớ thay thế sự thật bằng phiên bản hợp lý hơn.
+Ghi trong ngày, gửi xác nhận trong 24 giờ.
+
+**Coi "không có ý kiến gì" là đồng ý.** Im lặng ở GĐ1 thường thành phủ quyết ở UAT. Với
+stakeholder ảnh hưởng cao mà im lặng, phải chủ động hỏi từng điểm một.

.claude/skills/ba-1-discovery/examples.md

@@ -0,0 +1,108 @@
+# Ví dụ minh hoạ — `ba-1-discovery`
+
+Tách khỏi `SKILL.md` để quy trình không lẫn ví dụ của một ngành cụ thể. Cùng một quy tắc,
+minh hoạ ở ba domain khác nhau.
+
+---
+
+## Bước 4 · Chưng cất phát ngôn thành `RQ`
+
+`RQ` là **yêu cầu mức nghiệp vụ** — không phải chức năng, không phải màn hình.
+
+### Bán lẻ — đối soát doanh thu
+
+```
+RQ-007 | Người phụ trách đối soát phải phát hiện được chênh lệch giữa số liệu POS và số
+         liệu hệ thống trong ngày phát sinh, thay vì cuối tháng.
+         Nguồn: STK-04, biên bản 2026-08-22 · MoSCoW: Must · Liên quan: GOAL-02
+         Giải pháp khách gợi ý: "thêm màn hình đối soát"
+```
+
+### Y tế — đặt lịch khám
+
+```
+RQ-003 | Bệnh nhân phải biết ngay tại thời điểm đặt là khung giờ đó còn trống hay không,
+         thay vì đặt xong rồi bị gọi lại báo huỷ.
+         Nguồn: STK-02 (điều dưỡng tiếp nhận), quan sát 2026-08-19 · MoSCoW: Must
+         Giải pháp khách gợi ý: "cho xem lịch bác sĩ"
+```
+
+### Logistics — kiểm kê kho
+
+```
+RQ-011 | Quản lý kho phải biết chênh lệch giữa tồn hệ thống và tồn thực tế của một mã hàng
+         mà không phải dừng hoạt động kho để kiểm toàn bộ.
+         Nguồn: STK-01, workshop 2026-08-20 · MoSCoW: Should · Liên quan: GOAL-01
+```
+
+**Điểm chung của cả ba:** nêu *ai* cần *đạt được gì*, kèm *ràng buộc thực tế*. Không nêu
+màn hình, không nêu nút.
+
+---
+
+## Bẫy giải pháp giả dạng yêu cầu
+
+Câu khách nói thường là **giải pháp**. Hỏi ngược tới vấn đề gốc:
+
+| Domain | Khách nói | Hỏi ngược | Vấn đề gốc → `RQ` |
+|---|---|---|---|
+| Bán lẻ | "Cần thêm nút Export Excel" | "Xuất ra để làm gì? Sau khi có file thì làm gì tiếp?" | Gửi kế toán đối chiếu thủ công vì hai hệ thống không khớp số |
+| Y tế | "Cho tôi xem lịch của tất cả bác sĩ" | "Xem để quyết định gì?" | Cần biết còn slot trống nào gần nhất, không cần xem cả lịch |
+| Logistics | "Thêm cột ngày nhập vào bảng" | "Có cột đó rồi anh/chị làm gì?" | Cần lọc ra hàng tồn quá 90 ngày → cần bộ lọc, không cần cột |
+
+Cả ba trường hợp, giải pháp đúng **khác** với thứ khách yêu cầu — và rẻ hơn.
+
+Ghi giải pháp khách gợi ý vào cột riêng: có giá trị tham khảo, nhưng không phải yêu cầu.
+
+---
+
+## Bước 5 · `GOAL` phải có baseline
+
+### Đủ tiêu chuẩn
+
+```
+GOAL-02 | Rút ngắn thời gian phát hiện chênh lệch đối soát
+          Baseline: 22 ngày (trung bình tháng 6–7/2026, nguồn: chị Lan cung cấp)
+          Mục tiêu: ≤ 1 ngày
+          Đo bằng: chênh lệch giữa ngày phát sinh và ngày ghi nhận
+          Ai đo: BA + kế toán, hàng tháng
+```
+
+### Chưa có baseline — vẫn phải xử lý, không bỏ trống
+
+```
+GOAL-01 | Giảm tỷ lệ bệnh nhân bị huỷ lịch sau khi đã đặt
+          Baseline: ❓ chưa có số — OQ-006
+          Đề xuất cách đo baseline: đếm số cuộc gọi báo huỷ trong sổ tiếp nhận
+          tháng 7–8/2026 (ước tính 2 giờ công), hoặc lấy log tổng đài nếu còn
+          Mục tiêu: giảm 80% so với baseline đo được
+```
+
+🔴 Baseline ước lượng **có ghi rõ cách ước lượng** vẫn tốt hơn không có gì. Bỏ trống ⇒ GĐ5
+không so sánh được với gì, và "dự án có thành công không" thành tranh cãi cảm tính.
+
+---
+
+## Bước 1 · Ba nhóm stakeholder hay bị bỏ sót
+
+| Nhóm | Bán lẻ | Y tế | Logistics |
+|---|---|---|---|
+| **Vận hành / CS** | Tổng đài nhận khiếu nại của cửa hàng | Điều dưỡng tiếp nhận, tổng đài đặt lịch | Điều phối viên nhận cuộc gọi tài xế |
+| **Kế toán / đối soát** | Kế toán công nợ đối chiếu cuối tháng | Kế toán viện phí, bảo hiểm y tế | Kế toán kho, kiểm kê định kỳ |
+| **Pháp chế / bảo mật** | Dữ liệu giao dịch, thông tin thẻ | 🔴 Hồ sơ bệnh án — quy định rất chặt | Dữ liệu vị trí tài xế |
+
+Ba nhóm này thường nằm ở ô **"Giữ hài lòng"** (ảnh hưởng cao, ít quan tâm) — im lặng suốt
+dự án rồi phủ quyết ở phút chót.
+
+---
+
+## Bước 6 · Giả định — bốn chỗ hay ẩn nấp
+
+| Chỗ | Bán lẻ | Y tế |
+|---|---|---|
+| **Dữ liệu** | "Hệ thống POS có lưu mã cửa hàng" — đã mở DB xem chưa? | "Hồ sơ cũ có số điện thoại bệnh nhân" — bao nhiêu % không rỗng? |
+| **Tích hợp** | "API POS trả realtime" — đã đọc tài liệu bên NCC chưa? | "Hệ thống BHYT tra cứu được 24/7" — đã hỏi giờ bảo trì chưa? |
+| **Con người** | "Nhân viên sẽ đối soát mỗi ngày" — đã hỏi chính họ chưa? | "Điều dưỡng nhập kết quả ngay sau khám" — đã quan sát chưa? |
+| **Pháp lý** | "Được lưu thông tin thẻ 5 năm" | 🔴 "Được cho bệnh nhân xem kết quả qua app" — đã hỏi pháp chế chưa? |
+
+Giả định có **hệ quả nếu sai ở mức Cao** ⇒ nâng thành `RISK` và xác minh **ngay trong GĐ1**.

.claude/skills/ba-1-discovery/templates/elicitation-guide.md

@@ -0,0 +1,200 @@
+# ELICITATION — Bộ câu hỏi & mẫu biên bản
+
+Hai phần: **§A ngân hàng câu hỏi** (chọn ra, cắt theo người sắp gặp) và **§B mẫu biên bản**
+(điền sau mỗi buổi).
+
+---
+
+# §A · Ngân hàng câu hỏi
+
+> Đừng bê nguyên 60 câu vào buổi họp. Chọn 8–12 câu đúng vai trò người ngồi đối diện,
+> gửi trước cho họ chuẩn bị số liệu.
+
+## A1. Năm câu hỏi bắt buộc trong mọi buổi
+
+1. "Hôm nay anh/chị làm việc này thế nào? Cho tôi xem một ca thật được không?"
+2. "Chỗ nào mất thời gian nhất / hay sai nhất?"
+3. "Trường hợp ngoại lệ nào hay gặp? Lúc đó xử lý sao?"
+4. "Nếu hệ thống mới chỉ làm được đúng một thứ thôi, anh/chị chọn thứ gì?"
+5. "Làm thế nào để biết dự án này thành công?" *(nguồn của KPI)*
+
+## A2. Hỏi người quyết định (PO, quản lý)
+
+- Vấn đề nào khiến anh/chị quyết định đầu tư vào việc này lúc này, mà không phải năm ngoái?
+- Nếu dự án này không làm, chuyện gì xảy ra trong 6 tháng tới?
+- Ba tháng sau go-live, anh/chị nhìn vào con số nào để nói "đáng tiền"?
+- Hiện tại con số đó đang là bao nhiêu? *(baseline — hỏi thẳng, đừng ngại)*
+- Có ràng buộc nào về thời hạn không thể lùi? Vì sao?
+- Nếu chỉ kịp một nửa, anh/chị cắt phần nào?
+- Ai ngoài anh/chị có quyền phủ quyết việc này?
+- Đã từng có ai làm việc tương tự trong công ty chưa? Kết quả thế nào?
+
+## A3. Hỏi người sử dụng hằng ngày
+
+- Một ngày làm việc điển hình của anh/chị với việc này diễn ra thế nào?
+- Anh/chị đang dùng công cụ gì? *(chú ý các file Excel cá nhân — chúng là spec ẩn)*
+- Bước nào anh/chị phải làm đi làm lại, hoặc phải copy từ chỗ này sang chỗ kia?
+- Khi nào anh/chị phải hỏi người khác mới làm tiếp được?
+- Có mẹo/quy ước riêng nào mà chỉ người trong nghề biết không?
+- Lần gần nhất có sự cố, chuyện gì đã xảy ra? Xử lý thế nào?
+- Một tháng có bao nhiêu ca ngoại lệ? Ai xử lý?
+- Nếu làm sai, ai phát hiện ra và phát hiện lúc nào?
+- Có việc gì anh/chị vẫn phải làm tay dù hệ thống hiện tại có chức năng đó không? Vì sao?
+
+🔴 Câu cuối là câu vàng — nó lộ ra chỗ hệ thống cũ **có tính năng nhưng không dùng được**,
+tức là chỗ dễ lặp lại sai lầm nhất.
+
+## A4. Hỏi về dữ liệu
+
+- Dữ liệu này từ đâu ra? Ai nhập? Nhập lúc nào?
+- Trường nào bắt buộc, trường nào hay bỏ trống?
+- Có bao nhiêu bản ghi hiện tại? Tăng bao nhiêu mỗi tháng?
+- Dữ liệu cũ có cần chuyển sang không? Từ mốc nào trở đi?
+- Dữ liệu này có sai không? Sai kiểu gì? Ai sửa?
+- Cùng một thực thể có thể có mấy bản ghi trùng? Nhận biết trùng bằng gì?
+- Có thông tin cá nhân/nhạy cảm không? Ai được xem? Lưu bao lâu?
+- Ai đang cầm bản dữ liệu "thật" nhất? *(thường là một file Excel trên máy ai đó)*
+
+## A5. Hỏi về quy tắc nghiệp vụ
+
+- Điều kiện nào thì được làm việc này? Điều kiện nào thì không?
+- Ai được phê duyệt? Có mức nào cần hai người duyệt không?
+- Có giới hạn nào về số lượng/giá trị/thời gian không?
+- Quy tắc này có ngoại lệ không? Ai được cho phép ngoại lệ?
+- Quy tắc này có từ bao giờ, do đâu mà có? *(quy định pháp luật hay thói quen nội bộ — hai
+  thứ này có độ cứng rất khác nhau)*
+- Quy tắc này có thể thay đổi trong 1 năm tới không?
+- Nếu vi phạm quy tắc thì hệ thống nên chặn, cảnh báo, hay chỉ ghi log?
+
+## A6. Hỏi về tích hợp
+
+- Việc này liên quan tới hệ thống nào khác?
+- Dữ liệu chạy theo chiều nào? Đồng bộ hay theo lô?
+- Bên kia có tài liệu API không? Ai là đầu mối?
+- Nếu bên kia lỗi/chậm thì nghiệp vụ này xử lý sao?
+- Có phải đối chiếu số liệu hai bên không? Ai làm, tần suất nào?
+
+## A7. Hỏi về phi chức năng
+
+- Bao nhiêu người dùng đồng thời? Giờ cao điểm là khi nào?
+- Chậm bao lâu thì anh/chị thấy không chấp nhận được?
+- Hệ thống được phép dừng bao lâu để bảo trì? Vào lúc nào?
+- Có yêu cầu lưu vết ai làm gì lúc nào không? Lưu bao lâu?
+- Dùng trên máy tính hay điện thoại? Trình duyệt nào? Có dùng ngoài văn phòng không?
+- Cần hỗ trợ mấy ngôn ngữ?
+
+## A8. Câu hỏi đào sâu khi câu trả lời mơ hồ
+
+| Họ nói | Hỏi lại |
+|---|---|
+| "Thường thì…" | "Thường là bao nhiêu phần trăm? Còn lại thì sao?" |
+| "Cái đó tự động" | "Tự động chạy lúc nào? Ai bấm? Nếu lỗi thì ai biết?" |
+| "Ai cũng làm được" | "Cụ thể những vai trò nào? Có ai KHÔNG được làm không?" |
+| "Nhanh thôi" | "Bao nhiêu giây thì anh/chị bắt đầu thấy khó chịu?" |
+| "Giống hệ thống cũ" | "Cho tôi xem hệ thống cũ. Có chỗ nào anh/chị muốn khác đi không?" |
+| "Không quan trọng lắm" | "Nếu bỏ hẳn phần này thì có ảnh hưởng gì không?" |
+| "Để tôi hỏi lại" | "Tôi ghi là OQ nhé, anh/chị trả lời được trước ngày nào?" |
+
+## A9. Kỹ thuật 5-Why cho pain point
+
+Dùng khi khách nêu một khó khăn — đào tới nguyên nhân gốc, đừng dừng ở lớp một.
+
+```mermaid
+flowchart TD
+    P0["Điểm đau khách nêu:<br/>'Mất 2 tiếng mỗi ngày để đối chiếu'"]
+    P1["Vì sao? → Phải mở 3 hệ thống rồi copy sang Excel"]
+    P2["Vì sao? → Không hệ thống nào có đủ cả 3 loại số liệu"]
+    P3["Vì sao? → POS và kho là hai hệ thống của hai nhà cung cấp"]
+    P4["Vì sao? → Mua ở hai thời điểm khác nhau, không ai làm cầu nối"]
+    P5(["🎯 GỐC: Chưa ai đo được thiệt hại nên chưa ai ưu tiên"])
+
+    P0 --> P1 --> P2 --> P3 --> P4 --> P5
+```
+
+**Bảng đi kèm** *(quy tắc W13)* — mỗi lớp có thể sinh ra một `RQ` khác nhau:
+
+| Lớp | Nếu dừng ở đây thì `RQ` sẽ là | Chi phí giải pháp | Có giải quyết gốc không |
+|---|---|---|---|
+| 1 | "Cần công cụ copy nhanh hơn" | Thấp | ❌ |
+| 3 | "Cần một nơi xem đủ 3 loại số liệu" | Trung bình | Một phần |
+| 5 | "Cần đo được thiệt hại để ưu tiên đúng" | Thấp | ✅ |
+
+Gốc quyết định `RQ` viết thế nào. Dừng ở lớp một thì ra một yêu cầu "làm thêm nút export".
+
+---
+
+# §B · Mẫu biên bản
+
+> Mỗi buổi một file: `ELICITATION_<phạm vi>_<YYYY-MM-DD>.md`. Không gộp nhiều buổi.
+
+```markdown
+# ELICITATION — <Chủ đề> — <YYYY-MM-DD>
+
+| | |
+|---|---|
+| **Buổi** | <số>/<tổng dự kiến> |
+| **Ngày giờ** | YYYY-MM-DD HH:MM–HH:MM |
+| **Hình thức** | Phỏng vấn 1-1 / Workshop / Quan sát tại chỗ / Khảo sát |
+| **Người tham gia** | STK-nn <tên, vai trò> |
+| **Người ghi** | |
+| **Đã gửi xác nhận** | ☐ / ✅ ngày… |
+
+## 1. Mục tiêu buổi làm việc
+
+- Cần làm rõ: …
+
+## 2. Nội dung
+
+### 2.1 Sự thật thu được *(đo được, kiểm chứng được)*
+
+| # | Nội dung | Nguồn xác minh |
+|---|---|---|
+| F1 | | |
+
+### 2.2 Ý kiến / mong muốn *(chưa phải yêu cầu đã chốt)*
+
+| # | Nội dung | Người nêu | Mức thiết tha |
+|---|---|---|---|
+| O1 | | STK-nn | Cao/TB/Thấp |
+
+### 2.3 Giả định phát hiện *(người nói tin là đúng nhưng chưa ai xác nhận)*
+
+| # | Giả định | Cách xác minh | → ASM |
+|---|---|---|---|
+| A1 | | | ASM-nn |
+
+### 2.4 Trích nguyên văn *(những câu quan trọng, KHÔNG diễn giải lại)*
+
+> "…"  — STK-nn
+
+## 3. Mâu thuẫn với thông tin trước đó
+
+| # | Buổi này nói | Buổi/nguồn trước nói | Trạng thái |
+|---|---|---|---|
+| 1 | | ⚠️ mâu thuẫn với STK-03 ngày… | Chưa giải quyết — OQ-0nn |
+
+*Ghi cả hai, **không tự chọn bên nào**.*
+
+## 4. Yêu cầu chưng cất được
+
+| → RQ | Phát biểu | MoSCoW đề xuất | Giải pháp khách gợi ý |
+|---|---|---|---|
+| RQ-0nn | | | |
+
+## 5. Open Questions phát sinh
+
+| ID | Câu hỏi | Hỏi ai | Hạn đề xuất |
+|---|---|---|---|
+| OQ-0nn | | | |
+
+## 6. Việc cần làm tiếp
+
+| # | Việc | Ai | Hạn |
+|---|---|---|---|
+
+## 7. Tóm tắt đã đọc lại cho người tham gia xác nhận tại chỗ
+
+- [ ] Đã đọc lại tóm tắt cuối buổi
+- [ ] Đã gửi biên bản trong vòng 24h
+- [ ] Đã nhận phản hồi xác nhận
+```

.claude/skills/ba-1-discovery/templates/project-brief.md

@@ -0,0 +1,184 @@
+# BRIEF — <Tên module/dự án>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <BA> (skill ba-1-discovery) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Source** | <liệt kê file/biên bản đã dùng, mỗi cái một dòng> |
+| **Scope** | <module / US id> |
+
+## Change Log
+
+| Version | Date | Người sửa | Thay đổi | CR |
+|---|---|---|---|---|
+| 1.0 | YYYY-MM-DD | | Bản đầu | — |
+
+---
+
+## 1. Tóm tắt cho người quyết định
+
+> *Ba câu. Đọc xong biết: vấn đề gì, làm gì, được gì. Viết mục này SAU CÙNG.*
+
+---
+
+## 2. Bối cảnh
+
+*Hiện tại việc này đang diễn ra thế nào? Ai làm, tần suất bao nhiêu, mất bao lâu, bằng
+công cụ gì. Chỉ nêu sự thật quan sát được, kèm nguồn.*
+
+| Thông tin hiện trạng | Giá trị | Nguồn |
+|---|---|---|
+| Số giao dịch/ngày | | |
+| Số người thao tác | | |
+| Thời gian xử lý trung bình | | |
+| Tỷ lệ sai sót hiện tại | | |
+
+## 3. Phát biểu bài toán
+
+> **Vấn đề:** *<Ai> gặp <khó khăn gì> khi <làm việc gì>, dẫn tới <hậu quả đo được>.*
+
+❌ Không viết giải pháp ở đây ("cần thêm màn hình…", "cần nút export…").
+✅ Viết vấn đề đo được ("mất trung bình 2 giờ/ngày đối chiếu thủ công, sai sót 3–5 ca/tháng").
+
+**Bằng chứng của vấn đề:**
+
+| # | Bằng chứng | Nguồn | Loại |
+|---|---|---|---|
+| 1 | | STK-nn, biên bản ngày… | Sự thật / Ý kiến |
+
+**Điều gì xảy ra nếu không làm gì cả?** *(câu này quyết định dự án có đáng làm không)*
+
+## 4. Mục tiêu kinh doanh & KPI
+
+| 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 | | | | | | |
+| GOAL-02 | | | | | | |
+
+🔴 **Baseline trống ⇒ ghi `OQ` kèm đề xuất cách đo.** Không có baseline thì GĐ5 không có gì
+để so sánh, và "dự án có thành công không" sẽ thành tranh cãi cảm tính.
+
+## 5. Phạm vi
+
+### 5.1 Trong phạm vi
+
+| # | Hạng mục | Vì sao cần | RQ liên quan |
+|---|---|---|---|
+| 1 | | | RQ-001 |
+
+### 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 | | | |
+
+### 5.3 Ranh giới hệ thống
+
+*Hệ thống nào nằm trong, hệ thống nào chỉ tích hợp, dữ liệu đi qua đâu.*
+
+```mermaid
+flowchart LR
+    NGUOIDUNG(["👤 Vai trò sử dụng"])
+
+    subgraph PHAMVI["Trong phạm vi dự án"]
+        HT["Hệ thống đang xây"]
+    end
+
+    HTA[["Hệ thống A — chỉ tích hợp"]]
+    HTB[["Hệ thống B — ngoài phạm vi"]]
+
+    NGUOIDUNG --> HT
+    HT <--> HTA
+    HT --> HTB
+```
+
+*Khung đôi `[[ ]]` = ngoài phạm vi dự án. Mũi tên hai chiều = có trao đổi dữ liệu hai chiều.*
+
+| Hệ thống | Trong/Ngoài phạm vi | Dữ liệu trao đổi | Chiều | Đầu mối |
+|---|---|---|---|---|
+| | | | | |
+
+*Bảng này là phần bắt buộc đi kèm sơ đồ (quy tắc W13) — sơ đồ không nói được dữ liệu gì đi
+qua và ai chịu trách nhiệm.*
+
+## 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 | | STK-01, 2026-08-22 | Must | GOAL-01 | |
+| RQ-002 | | | Should | | |
+
+**Kiểm tra phân bổ MoSCoW:** Must ≤ 60% tổng số. Vượt ⇒ chưa phân loại thật, quay lại hỏi
+PO *"nếu chỉ kịp một nửa thì cắt cái nào"*.
+
+| 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 — ghi để khỏi bàn lại |
+
+## 7. Ràng buộc
+
+| Loại | Nội dung | Nguồn | Ảnh hưởng |
+|---|---|---|---|
+| Thời gian | | | |
+| Ngân sách / nguồn lực | | | |
+| Công nghệ | | | |
+| Pháp lý / tuân thủ | | | |
+| Tổ chức / quy trình | | | |
+
+## 8. Giả định và rủi ro
+
+*Chi tiết ở `RISK_<...>.md`. Ở đây chỉ nêu những cái ảnh hưởng tới phạm vi.*
+
+| ID | Nội dung | Nếu sai thì sao |
+|---|---|---|
+| ASM-01 | | |
+| RISK-01 | | |
+
+## 9. Tiêu chí thành công của giai đoạn
+
+*Khi nào coi là "làm xong và làm đúng"? Khác với KPI ở mục 4 — mục này nói về sản phẩm,
+mục 4 nói về hiệu quả kinh doanh.*
+
+- [ ]
+- [ ]
+
+## 10. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Phương án BA đề xuất |
+|---|---|---|---|---|---|
+| OQ-001 | | | | | *(đề xuất, chưa phải quyết định)* |
+
+## 11. Ngoài phạm vi tài liệu này
+
+*Những gì người đọc có thể tưởng là có trong tài liệu này nhưng không có, và tìm ở đâu.*
+
+- Thiết kế màn hình → GĐ3, `SRS`
+- Quy trình chi tiết từng bước → GĐ2, `PROCESS`
+- Ước lượng công sức → PM
+
+---
+
+## Tự chấm
+
+**Gate G1**
+
+| # | 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 | | |
+| 2 | STAKEHOLDER đủ 4 nhóm, có tên thật | | |
+| 3 | ELICITATION có ≥1 buổi với nhóm quyết định và nhóm sử dụng | | |
+| 4 | RQ có MoSCoW, truy về được stakeholder cụ thể | | |
+| 5 | RISK/ASM đã ghi, rủi ro cao có người chịu trách nhiệm | | |
+| 6 | KPI có baseline | | |
+
+**Quy tắc viết W1–W13** — xem `../ba-lifecycle/references/writing-rules.md`
+
+| W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | W11 | W12 | W13 |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| | | | | | | | | | | | | |

.claude/skills/ba-1-discovery/templates/risk-register.md

@@ -0,0 +1,97 @@
+# RISK — Sổ rủi ro & giả định — <Tên module/dự án>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <BA> (skill ba-1-discovery) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Source** | |
+| **Scope** | |
+
+---
+
+## 1. Giả định (`ASM-nn`)
+
+Mọi thứ đang tin là đúng nhưng **chưa ai xác nhận**. Giả định không ghi ra là giả định sẽ
+nổ ở GĐ3 hoặc UAT.
+
+| ID | Giả định | Ai/cái gì làm nó đúng | Cách xác minh | Hạn xác minh | Hệ quả nếu sai | Trạng thái |
+|---|---|---|---|---|---|---|
+| ASM-01 | | | | | | ☐ Chưa xác minh |
+
+**Bốn chỗ giả định hay ẩn nấp — rà đích danh, đừng chờ nó tự lộ:**
+
+| Chỗ | Giả định điển hình | Cách xác minh rẻ nhất |
+|---|---|---|
+| **Dữ liệu** | "Hệ thống cũ có sẵn trường này" | Mở DB/màn hình cũ ra xem, chụp màn hình |
+| **Tích hợp** | "API bên kia trả về realtime" | Xin tài liệu API + gọi thử một lần |
+| **Con người** | "Vận hành sẽ nhập liệu hằng ngày" | Hỏi thẳng chính người đó, không hỏi sếp họ |
+| **Pháp lý** | "Được phép lưu thông tin này" | Gửi câu hỏi bằng văn bản cho pháp chế |
+
+🔴 Giả định có **hệ quả nếu sai ở mức Cao** ⇒ nâng thành `RISK` và **xác minh ngay trong
+GĐ1**. Để sang GĐ3 mới phát hiện thì phải viết lại spec.
+
+## 2. Rủi ro (`RISK-nn`)
+
+| ID | Mô tả rủi ro | Loại | Khả năng | Tác động | Mức | Người chịu trách nhiệm | Phương án ứng phó | Dấu hiệu sớm | Trạng thái |
+|---|---|---|---|---|---|---|---|---|---|
+| RISK-01 | | | Cao/TB/Thấp | Cao/TB/Thấp | 🔴/🟠/🟢 | | | | Mở |
+
+**Viết rủi ro đúng cách** — công thức ba vế, thiếu vế nào cũng thành khẩu hiệu:
+
+```
+Vì <nguyên nhân có thật>, có thể xảy ra <sự kiện>, dẫn tới <hậu quả đo được>.
+```
+
+❌ "Rủi ro về tiến độ."
+✅ "Vì hệ thống POS do bên thứ ba vận hành và chưa cam kết lịch mở API, có thể tới cuối
+   tháng 10 vẫn chưa tích hợp được, dẫn tới trượt go-live tháng 11 hoặc phải nhập tay
+   ~3.000 giao dịch/ngày."
+
+**Ma trận mức** — 3×3, mermaid không có loại sơ đồ này nên dùng bảng (`diagram-rules.md`):
+
+| Tác động ↓ · Khả năng → | Thấp | Trung bình | Cao |
+|---|---|---|---|
+| **Cao** | 🟠 | 🔴 | 🔴 |
+| **Trung bình** | 🟢 | 🟠 | 🔴 |
+| **Thấp** | 🟢 | 🟢 | 🟠 |
+
+🔴 = phải có phương án ứng phó và người chịu trách nhiệm **ngay trong GĐ1**, báo PM.
+🟠 = theo dõi, rà lại ở mỗi gate.
+🟢 = ghi nhận.
+
+**Loại rủi ro — rà đủ 6 loại, đừng chỉ nghĩ tới tiến độ:**
+
+| Loại | Câu hỏi rà |
+|---|---|
+| Nghiệp vụ | Hiểu sai quy trình? Bỏ sót ngoại lệ quan trọng? |
+| Dữ liệu | Dữ liệu cũ bẩn? Không migrate được? Không đối chiếu được? |
+| Tích hợp | Bên thứ ba không sẵn sàng? Đổi contract giữa chừng? |
+| Con người | Người dùng không chịu đổi thói quen? Người biết nghiệp vụ nghỉ việc? |
+| Tuân thủ | Vi phạm quy định về dữ liệu cá nhân? Thiếu lưu vết? |
+| Tổ chức | Hai bên stakeholder mâu thuẫn chưa giải quyết? Không ai ký được? |
+
+## 3. Phụ thuộc bên ngoài
+
+*Những thứ dự án cần nhưng không tự quyết được.*
+
+| # | Phụ thuộc vào | Bên nào | Cần trước ngày | Nếu trễ thì sao | Đầu mối | Trạng thái |
+|---|---|---|---|---|---|---|
+
+## 4. Rủi ro đã đóng
+
+*Giữ lại, không xoá — để lần sau biết cái gì từng xảy ra và xử lý thế nào.*
+
+| ID | Rủi ro | Ngày đóng | Kết cục | Bài học |
+|---|---|---|---|---|
+
+## 5. Lịch rà soát
+
+| Mốc | Việc |
+|---|---|
+| Mỗi gate | Rà toàn bộ 🔴 và 🟠, cập nhật trạng thái |
+| GĐ3 bắt đầu | Mọi `ASM` phải chuyển sang **đã xác minh** hoặc thành `RISK` |
+| GĐ4 UAT | Rà rủi ro con người và dữ liệu — đây là lúc chúng hiện hình |
+| GĐ5 | Chuyển bài học vào `BENEFIT` |

.claude/skills/ba-1-discovery/templates/stakeholder-map.md

@@ -0,0 +1,104 @@
+# STAKEHOLDER — <Tên module/dự án>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <BA> (skill ba-1-discovery) |
+| **Status** | 🟡 Draft |
+| **Approved by** | — |
+| **Source** | |
+| **Scope** | |
+
+---
+
+## 1. Danh sách stakeholder
+
+| ID | Tên | Vai trò / Bộ phận | Nhóm | Quan tâm | Ảnh hưởng | Chiến lược | Kênh | Người thay thế |
+|---|---|---|---|---|---|---|---|---|
+| STK-01 | | | Quyết định | Cao | Cao | Quản lý sát | | |
+| STK-02 | | | Sử dụng | Cao | Thấp | Giữ thông tin | | |
+| STK-03 | | | Bị ảnh hưởng | | | | | |
+| STK-04 | | | Cung cấp thông tin | | | | | |
+
+**Nhóm** — bốn nhóm, thiếu nhóm nào cũng là lỗ hổng:
+
+| Nhóm | Nhận diện bằng câu hỏi | Rủi ro nếu bỏ sót |
+|---|---|---|
+| Quyết định | Ai ký duyệt? Ai cắt được scope? Ai giữ ngân sách? | Làm xong bị bác |
+| Sử dụng | Ai ngồi trước màn hình mỗi ngày? | Đúng spec nhưng không ai dùng |
+| Bị ảnh hưởng | Quy trình của ai thay đổi? Ai mất/được việc? | Kháng cự lúc go-live |
+| Cung cấp thông tin | Ai biết nghiệp vụ hiện tại? Ai giữ dữ liệu/hệ thống cũ? | Hiểu sai AS-IS |
+
+## 2. Ma trận Quan tâm × Ảnh hưởng
+
+```mermaid
+quadrantChart
+    title Stakeholder — Quan tâm × Ảnh hưởng
+    x-axis "Quan tâm thấp" --> "Quan tâm cao"
+    y-axis "Ảnh hưởng thấp" --> "Ảnh hưởng cao"
+    quadrant-1 "QUẢN LÝ SÁT"
+    quadrant-2 "GIỮ HÀI LÒNG"
+    quadrant-3 "THEO DÕI"
+    quadrant-4 "GIỮ THÔNG TIN"
+    "STK-01": [0.85, 0.90]
+    "STK-02": [0.80, 0.25]
+    "STK-03": [0.30, 0.35]
+    "STK-04": [0.20, 0.85]
+```
+
+*Toạ độ 0–1. Đặt mỗi `STK-nn` theo mức đã chấm ở bảng §1.*
+
+| Ô | Chiến lược | STK trong ô |
+|---|---|---|
+| **Quản lý sát** *(quan tâm cao, ảnh hưởng cao)* | Đồng hành, duyệt từng gate | STK-01 |
+| **Giữ hài lòng** *(quan tâm thấp, ảnh hưởng cao)* | Hỏi từng điểm một, không chấp nhận im lặng | STK-04 |
+| **Giữ thông tin** *(quan tâm cao, ảnh hưởng thấp)* | Hỏi ý kiến, demo sớm | STK-02 |
+| **Theo dõi** *(cả hai thấp)* | Thông báo khi cần | STK-03 |
+
+⚠️ `quadrantChart` cần mermaid ≥ 10. Renderer cũ không hiểu ⇒ **bảng trên là phương án dự
+phòng**, luôn giữ nó.
+
+🔴 **Ô "Giữ hài lòng" là ô nguy hiểm nhất** — ảnh hưởng cao nhưng ít quan tâm, nên thường
+im lặng suốt dự án rồi phủ quyết ở phút chót. Pháp chế, bảo mật, kế toán hay nằm ở đây.
+Với ô này: hỏi từng điểm một, không chấp nhận "không có ý kiến gì".
+
+## 3. Ba nhóm hay bị bỏ sót — rà đích danh
+
+| Nhóm | Vì sao dễ quên | Câu phải hỏi |
+|---|---|---|
+| **Vận hành / CS** | Không dự họp dự án | "Khi khách hàng khiếu nại việc này, ai nhận cuộc gọi? Họ cần tra cứu gì?" |
+| **Kế toán / đối soát** | Chỉ xuất hiện cuối kỳ | "Số liệu này cuối tháng ai đối chiếu? Đối chiếu với cái gì?" |
+| **Pháp chế / bảo mật** | Chỉ được hỏi khi sắp go-live | "Dữ liệu này có phải thông tin cá nhân không? Lưu bao lâu? Ai được xem?" |
+
+## 4. RACI theo hạng mục quyết định
+
+| Hạng mục | R (làm) | A (chịu trách nhiệm cuối) | C (hỏi ý kiến) | I (thông báo) |
+|---|---|---|---|---|
+| Chốt phạm vi | BA | PO | Tech Lead, PM | Team |
+| Chốt quy trình nghiệp vụ | BA | PO | STK-02, STK-04 | QA, Dev |
+| Chốt phương án kỹ thuật | Tech Lead | Tech Lead | BA | PO |
+| Chốt tiêu chí nghiệm thu | BA | PO | QA | Dev |
+| Duyệt UAT | QA | PO | BA | Team |
+
+**Mỗi hàng chỉ có đúng một chữ A.** Hai chữ A nghĩa là chưa ai chịu trách nhiệm.
+
+## 5. Kế hoạch tiếp cận
+
+| STK | Cần lấy thông tin gì | Kỹ thuật | Dự kiến | Trạng thái |
+|---|---|---|---|---|
+| STK-01 | Mục tiêu, ràng buộc, tiêu chí thành công | Phỏng vấn 1-1 | | ☐ |
+| STK-02 | Quy trình thật, pain point, ngoại lệ | Quan sát tại chỗ | | ☐ |
+
+## 6. Mâu thuẫn giữa các bên
+
+*Ghi lại, **không tự giải quyết**. Đây là đầu vào cho PO quyết.*
+
+| # | Bên A muốn | Bên B muốn | Vì sao mâu thuẫn | Trạng thái |
+|---|---|---|---|---|
+| 1 | STK-01: … | STK-03: … | | Chờ PO — OQ-0nn |
+
+## 7. Open Questions
+
+| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
+|---|---|---|---|---|