init git

.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ì |
+|---|---|---|---|---|