init git

.claude/skills/ba-5-post-release/GUIDE.md

@@ -0,0 +1,159 @@
+# Hướng dẫn sử dụng — `ba-5-post-release` (Giai đoạn 5)
+
+## Giai đoạn này giải quyết gì
+
+Trả lời câu hỏi: **"làm xong rồi, có đạt được điều đã hứa không?"** — và biến câu trả lời
+thành đầu vào cho vòng sau.
+
+Đây là giai đoạn bị bỏ nhiều nhất. Release xong là team chuyển sang việc khác. Hậu quả:
+không ai biết dự án có đáng tiền không, và cùng một sai lầm lặp lại ở dự án sau.
+
+## Ba việc, ba thời điểm khác nhau
+
+🔴 Đừng gọi skill một lần cho cả ba — chúng ở ba mốc thời gian khác nhau:
+
+| Việc | Làm khi nào | Lệnh |
+|---|---|---|
+| `MANUAL` + đào tạo | Trước go-live 1–2 tuần | `--only manual` |
+| `RELNOTE` | Trước hoặc ngay ngày go-live | `--only relnote` |
+| `BENEFIT` | Sau go-live 1–3 tháng | `--only benefit` |
+
+## Cú pháp
+
+```
+/ba-5-post-release <PROJECT> [--only relnote|manual|benefit] [--since <ngày go-live>] [go]
+```
+
+Ví dụ:
+
+```
+/ba-5-post-release Settlement --only manual
+/ba-5-post-release Settlement --only relnote
+/ba-5-post-release Settlement --only benefit --since 2026-09-15
+```
+
+## Chuẩn bị gì trước khi gọi
+
+| Cho việc | Cần có |
+|---|---|
+| `MANUAL` | `PROCESS` TO-BE · `UAT` §B2 và §B3 · `SRS` bảng mã lỗi · ảnh chụp màn hình thật |
+| `RELNOTE` | Danh sách US trong đợt phát hành · `UAT` (hạn chế đã biết) |
+| `BENEFIT` | 🔴 **`BRIEF` §4 với baseline** · số liệu sử dụng thật · `QLOG` · `CR` · phản hồi người dùng |
+
+🔴 **`BENEFIT` không có baseline thì không so sánh được với gì.** Skill kiểm tra điều này
+ngay ở Bước 0 và nói thẳng, thay vì để bạn phát hiện ở cuối.
+
+## Bạn sẽ nhận được gì
+
+```
+ba-output/<PROJECT>/05-post-release/
+├── RELNOTE_<đợt phát hành>_v1.0.md
+├── MANUAL_<module>_v1.0.md          ← kèm phụ lục kế hoạch đào tạo
+└── BENEFIT_<PROJECT>_v1.0.md
+```
+
+Cộng bốn bảng in ra: KPI (baseline × mục tiêu × thực tế) · tự chấm G5 · bài học · đề xuất
+vòng sau.
+
+## Điểm mấu chốt của từng việc
+
+### `RELNOTE` — viết cho người dùng, không cho dev
+
+| Viết thế này | Không viết thế này |
+|---|---|
+| "Bạn xem được chênh lệch POS ngay trong ngày, thay vì chờ cuối tháng" | "Thêm endpoint GET /discrepancies" |
+
+Bốn mục bắt buộc: có gì mới · **có gì thay đổi so với cách làm cũ** · bạn cần làm gì ·
+**chưa có gì**.
+
+Mục cuối hay bị bỏ vì "không hay ho". Nhưng người dùng phát hiện hạn chế mà không được báo
+trước sẽ mất niềm tin vào toàn bộ hệ thống, không chỉ vào tính năng đó.
+
+### `MANUAL` — viết theo công việc, không theo màn hình
+
+Người dùng tra *"làm sao để đối soát ngày hôm qua"*, không tra *"màn hình SCR-01"*.
+
+**Nguồn nội dung tốt nhất là `UAT` §B2 và §B3** — mục "hiểu nhầm cách dùng" và các quan sát
+chỗ người dùng loay hoay. Đó là chỗ người dùng **thật sự** vấp phải, đã được kiểm chứng,
+không phải phỏng đoán của người viết tài liệu.
+
+Phụ lục đào tạo có một điểm cần giữ: **phần thực hành là phần duy nhất tạo ra thay đổi hành
+vi**. Buổi đào tạo chỉ trình bày và demo thì tuần sau người dùng vẫn làm theo cách cũ.
+
+### `BENEFIT` — đo trung thực
+
+Bốn quy tắc, skill sẽ đòi bạn xác nhận từng cái:
+
+1. **Đo cùng cách với lúc lấy baseline** — đổi cách đo thì không so sánh được, và việc đổi
+   cách đo hay xảy ra đúng lúc kết quả không đẹp
+2. **Đo sau khi hệ thống ổn định** — tuần đầu luôn nhiễu
+3. **Ghi rõ yếu tố nhiễu** — cùng lúc có tuyển thêm người không? có phải mùa cao điểm không?
+4. **Không đo được thì ghi là không đo được** — kèm lý do và cách khắc phục lần sau
+
+Phần **bài học** được rút từ dữ liệu có sẵn, không phải ngồi nhớ lại:
+
+| Nguồn | Rút ra |
+|---|---|
+| `QLOG` loại 2 nhiều | Viết mơ hồ (vi phạm W2) |
+| `QLOG` loại 3 nhiều | Đặc tả thiếu phạm vi |
+| `QLOG` loại 4 nhiều | GĐ2 hiểu sai nghiệp vụ |
+| `CR` — số spec gap | Chỗ nào của đặc tả hay bỏ sót |
+| `UAT` "hiểu nhầm cách dùng" | Thiết kế hoặc đào tạo chưa đủ |
+
+## Ví dụ hội thoại
+
+```
+Bạn:    /ba-5-post-release Settlement --only benefit --since 2026-09-15
+
+Claude: [Bước 0]
+        Input:
+        | BRIEF_Settlement_v1.0.md | GOAL-01..03, có baseline cho GOAL-01, GOAL-02 | ✅ |
+        | UAT_2026-09_v1.0.md      | 12 phát hiện, 3 CR                          | ✅ |
+        | QLOG_Settlement.md       | 34 câu hỏi                                   | — |
+
+        ⚠️ GOAL-03 (giảm khiếu nại của cửa hàng) KHÔNG có baseline trong BRIEF §4.
+        Ba lựa chọn:
+        a) Ước lượng ngược từ ticket CS năm ngoái (nếu còn) — ghi rõ độ tin cậy thấp
+        b) Bỏ GOAL-03 khỏi báo cáo, ghi vào §2.2 "không đo được"
+        c) Bạn có số liệu ở nguồn khác?
+
+        Go-live 2026-09-15, hôm nay 2026-08-30 — chưa tới ngày go-live.
+        Bạn muốn tôi chuẩn bị khung BENEFIT trước, hay đây là nhầm ngày?
+```
+
+## Lỗi thường gặp
+
+**"Release xong rồi, giai đoạn này bỏ được không?"**
+Bỏ được, và bạn mất khả năng trả lời "dự án có đáng tiền không". Nếu thật sự không có thời
+gian: tối thiểu làm **đo KPI** và **bài học** — hai phần rẻ nhất và có giá trị lâu nhất.
+
+**"Release note tôi copy từ commit log."**
+Người dùng không quan tâm endpoint nào được thêm. Họ quan tâm việc của họ thay đổi thế nào.
+
+**"Đo KPI ngay tuần đầu cho nóng."**
+Tuần đầu luôn xấu vì người dùng đang học và dữ liệu đang chuyển. Kết luận thất bại lúc đó
+là kết luận sai. Chờ ít nhất 1 tháng.
+
+**"KPI không đạt, viết nhẹ đi cho đỡ căng."**
+`BENEFIT` viết để học. Báo cáo toàn màu xanh thì không ai tin và không ai học được gì. Ghi
+đúng con số, ghi rõ nguyên nhân và yếu tố nhiễu.
+
+**"GĐ1 không ghi baseline, giờ tôi ước lượng một con số hợp lý."**
+Không. Ghi rõ là không đo được và vì sao — đó chính là bài học quan trọng nhất của dự án
+này. Nếu ước lượng ngược từ log cũ thì phải ghi rõ **độ tin cậy thấp**.
+
+**"Bài học: cần giao tiếp tốt hơn."**
+Không dùng được. Bài học phải cụ thể tới mức lần sau đọc là biết làm khác chỗ nào: *"phải
+rà đích danh nhóm kế toán ở Bước 1 GĐ1, vì họ có quyền phủ quyết ở cuối"*.
+
+## Kết thúc
+
+Gate G5 xong thì dự án đóng, hoặc mở vòng mới. Mở vòng mới ⇒ chạy `/ba-1-discovery` với
+`BRIEF` phiên bản mới — **không sửa đè bản cũ**.
+
+## Liên quan
+
+- Tiêu chí gate G5: `../ba-lifecycle/references/workflow.md` §2
+- Đường quay lui GĐ5 → GĐ1: `../ba-lifecycle/references/workflow.md` §5
+- Template: `templates/release-note.md` · `templates/user-manual.md` ·
+  `templates/benefit-review.md`

.claude/skills/ba-5-post-release/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: ba-5-post-release
+description: Giai đoạn 5 của quy trình BA — sau khi phát hành. Dùng để viết release note nghiệp vụ cho người dùng, soạn tài liệu hướng dẫn sử dụng và nội dung đào tạo, thu thập và phân loại phản hồi người dùng, đo KPI thực tế so với baseline đã ghi ở giai đoạn 1, rút bài học và đề xuất vòng cải tiến tiếp theo. Kích hoạt khi người dùng nói "viết release note", "tài liệu hướng dẫn sử dụng", "user manual", "đào tạo người dùng", "đo hiệu quả sau release", "KPI có đạt không", "benefit review", "thu thập feedback", "bài học dự án", "retrospective nghiệp vụ". Output vào ba-output/<PROJECT>/05-post-release/, kết thúc bằng Gate G5.
+---
+
+# GĐ5 · POST-RELEASE — Bàn giao & đo hiệu quả
+
+Mục tiêu: **trả lời câu hỏi "làm xong rồi, có đạt được điều đã hứa không?"** và biến câu
+trả lời thành đầu vào cho vòng sau.
+
+Đây là giai đoạn bị bỏ nhiều nhất — release xong là team chuyển sang việc khác. Hậu quả:
+không ai biết dự án có đáng tiền không, và cùng một sai lầm lặp lại ở dự án sau.
+
+Output: `RELNOTE` · `MANUAL` · `BENEFIT` trong `ba-output/<PROJECT>/05-post-release/`
+
+## Bốn nguyên tắc bất di bất dịch
+
+1. **Không bịa số liệu** — không đo được ⇒ ghi rõ *không đo được và vì sao*, không ước lượng
+   một con số đẹp.
+2. **Không quyết định thay PO** — đề xuất vòng sau là đề xuất, PO chốt.
+3. **Mọi phát biểu truy vết được** — mỗi con số KPI phải có nguồn và cách tính.
+4. **Không ghi đè tài liệu đã qua gate.**
+
+🔴 **Nguyên tắc riêng: báo cáo trung thực kể cả khi kết quả xấu.** `BENEFIT` viết để học,
+không phải để khoe. Một báo cáo nói "KPI không đạt vì lý do X" có giá trị hơn nhiều một báo
+cáo toàn màu xanh mà không ai tin.
+
+## 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ờ trả lời**:
+
+1. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Nó quyết định `MANUAL` viết cho ai:
+   `screen` → người dùng cuối · `api-service` → **tài liệu tích hợp cho dev** ·
+   `data-pipeline` → từ điển dữ liệu + hướng dẫn đọc số · `batch-job` → **sổ tay vận hành** ·
+   `ml-model` → hướng dẫn diễn giải kết quả. `RIGOR = light` ⇒ được bỏ `MANUAL` nếu người
+   dùng là chính nhóm làm, nhưng **vẫn phải có `RELNOTE`**.
+2. **Input dùng được** — bảng `File | Vai trò | Version`. Bắt buộc tìm: `BRIEF` (để lấy
+   `GOAL-nn` và **baseline**), `UAT` (kết quả nghiệm thu, danh sách "hiểu nhầm cách dùng"),
+   `QLOG` + `CR` (để rút bài học).
+3. **Đã release chưa, ngày nào** — mốc này quyết định cửa sổ đo KPI.
+4. **Việc cần làm lần này** — `RELNOTE`? `MANUAL`? `BENEFIT`? Ba việc này thường ở ba thời
+   điểm khác nhau (xem bảng dưới).
+5. **Có baseline không** — mở `BRIEF` §4 kiểm tra. **Không có baseline ⇒ nói thẳng ngay từ
+   Bước 0**, đừng để tới cuối mới phát hiện không so sánh được.
+6. **Hỏi xác nhận** năm điểm trên.
+
+Ví dụ minh hoạ nhiều domain: `examples.md`.
+
+**Ba việc, ba thời điểm:**
+
+| Việc | Làm khi nào |
+|---|---|
+| `RELNOTE` | Trước hoặc ngay ngày go-live |
+| `MANUAL` + đào tạo | Trước go-live 1–2 tuần |
+| `BENEFIT` | Sau go-live đủ lâu để KPI ổn định — thường 1–3 tháng |
+
+Bỏ qua khi lệnh có `go`.
+
+## Thực hiện — 5 bước
+
+### Bước 1 — Release note nghiệp vụ
+
+Dùng `templates/release-note.md`.
+
+🔴 **Đây không phải changelog kỹ thuật.** Người đọc là **người tiêu thụ sản phẩm** — với
+`screen` là người dùng cuối, với `api-service` là team tích hợp, với `data-pipeline` là
+người đọc báo cáo, với `batch-job` là người vận hành. Viết bằng ngôn ngữ công việc của họ,
+không phải ngôn ngữ triển khai. Bốn cặp ví dụ ❌/✅: `examples.md`.
+
+Bốn mục bắt buộc:
+
+1. **Có gì mới** — theo công việc của người dùng, không theo màn hình
+2. **Có gì thay đổi so với cách làm cũ** — phần quan trọng nhất, vì đây là chỗ gây bối rối
+3. **Cần làm gì** — người dùng phải hành động gì (đổi thói quen? nhập bổ sung dữ liệu?)
+4. **Chưa có gì** — hạn chế đã biết, cách xử lý tạm, dự kiến khi nào có
+
+Mục 4 hay bị bỏ vì "không hay ho". Nhưng người dùng phát hiện hạn chế mà không được báo
+trước sẽ mất niềm tin vào toàn bộ hệ thống, không chỉ vào tính năng đó.
+
+### Bước 2 — Tài liệu hướng dẫn & đào tạo
+
+Dùng `templates/user-manual.md`.
+
+**Viết theo công việc, không theo màn hình.** Người dùng tìm *"làm sao để đối soát ngày
+hôm qua"*, không tìm *"màn hình SCR-01"*.
+
+Nguồn nội dung có sẵn, dùng lại thay vì viết mới:
+
+| Nguồn | Dùng cho phần nào |
+|---|---|
+| `PROCESS` TO-BE | Cấu trúc chương mục theo luồng công việc |
+| `UAT` §B3 quan sát | Chính xác chỗ người dùng loay hoay ⇒ phần cần hướng dẫn kỹ |
+| `UAT` §B2 "hiểu nhầm cách dùng" | Danh sách câu hỏi thường gặp, viết sẵn câu trả lời |
+| `SRS` bảng mã lỗi | Mục "gặp lỗi này thì làm gì" |
+
+🔴 **Mục "hiểu nhầm cách dùng" từ UAT là vàng.** Đó là danh sách chỗ người dùng thật sự
+vấp phải, đã được kiểm chứng — không phải phỏng đoán của người viết tài liệu.
+
+Với mỗi thao tác: bối cảnh (khi nào dùng) · các bước · ảnh chụp · kết quả mong đợi · lỗi
+thường gặp. Bỏ ảnh chụp thì tài liệu gần như vô dụng với người dùng không rành máy tính.
+
+### Bước 3 — Thu thập phản hồi
+
+Ba nguồn, giá trị khác nhau:
+
+| Nguồn | Ưu | Nhược | Cách lấy |
+|---|---|---|---|
+| **Số liệu sử dụng thật** | Không nói dối | Không giải thích được vì sao | Log, số lượt dùng chức năng |
+| **Phản hồi chủ động** | Chi tiết, có ngữ cảnh | Thiên lệch về người bức xúc | Khảo sát, phỏng vấn |
+| **Ticket hỗ trợ / CS** | Vấn đề thật, có mức độ | Chỉ thấy phần nổi | Hệ thống ticket |
+
+**Đối chiếu ba nguồn** là chỗ ra phát hiện: chức năng ai cũng khen nhưng log cho thấy gần
+như không ai dùng — đó là thông tin quan trọng hơn cả hai nguồn riêng lẻ.
+
+Phân loại phản hồi thành bốn nhóm, mỗi nhóm đi một đường:
+
+| Nhóm | Đi đâu |
+|---|---|
+| Lỗi | Ticket defect |
+| Yêu cầu tính năng mới | Backlog vòng sau |
+| Khó dùng / không tìm thấy | Cải thiện thiết kế **hoặc** bổ sung đào tạo |
+| Hiểu nhầm | Bổ sung tài liệu/đào tạo |
+
+### Bước 4 — Đo KPI so với baseline
+
+Dùng `templates/benefit-review.md`. **Đây là mục đích tồn tại của giai đoạn này.**
+
+Với mỗi `GOAL-nn` trong `BRIEF`:
+
+| GOAL | Baseline (GĐ1) | Mục tiêu | Thực tế | Đạt? | Nguồn số liệu | Cách tính |
+|---|---|---|---|---|---|---|
+
+Ví dụ một `GOAL` đạt chuẩn và một `GOAL` không đo được: `examples.md`.
+
+Bốn quy tắc đo:
+
+1. **Đo cùng cách với lúc lấy baseline.** Đổi cách đo thì con số không so sánh được, và
+   việc đổi cách đo giữa chừng là cách phổ biến để một kết quả xấu trông đẹp lên.
+2. **Đo sau khi hệ thống ổn định.** Tuần đầu sau go-live luôn nhiễu (người dùng đang học,
+   dữ liệu đang chuyển). Chờ ít nhất 1 tháng, tốt nhất 3 tháng.
+3. **Ghi rõ yếu tố nhiễu.** Cùng lúc đó có thay đổi gì khác không (thêm người, đổi quy
+   trình, mùa cao điểm)? Không có yếu tố nhiễu là chuyện hiếm.
+4. **Không đo được thì ghi là không đo được.** Kèm lý do và cách khắc phục cho lần sau.
+
+🔴 **Không có baseline ⇒ ghi nhận đây là bài học của GĐ1, đừng lấp liếm.** Có thể ước lượng
+ngược baseline từ log/số liệu cũ nếu còn, nhưng phải ghi rõ là ước lượng ngược và kém tin cậy.
+
+### Bước 5 — Bài học và đề xuất vòng sau
+
+**Bài học** — rà bốn nguồn dữ liệu có sẵn, không ngồi nhớ lại:
+
+| Nguồn | Rút ra được gì |
+|---|---|
+| `QLOG` thống kê loại câu hỏi | Loại 2 nhiều ⇒ viết mơ hồ · loại 3 nhiều ⇒ đặc tả thiếu phạm vi · loại 4 nhiều ⇒ GĐ2 hiểu sai nghiệp vụ |
+| `CR` — số **spec gap** | Chỗ nào của đặc tả hay bỏ sót |
+| `QLOG` câu hỏi lặp lại | Mục tài liệu nào khó tra cứu |
+| `UAT` "hiểu nhầm cách dùng" | Thiết kế hoặc đào tạo chưa đủ |
+
+Viết bài học theo mẫu: **quan sát được → nguyên nhân → lần sau làm khác thế nào**. Bài học
+kiểu "cần giao tiếp tốt hơn" là không dùng được; nó phải cụ thể tới mức lần sau đọc là biết
+sửa chỗ nào trong quy trình. Bốn bài học đạt chuẩn: `examples.md`.
+
+**Đề xuất vòng sau** — mỗi đề xuất phải có: vấn đề nó giải quyết · bằng chứng từ dữ liệu ở
+Bước 3/4 · ước lượng sơ bộ · lợi ích kỳ vọng. Đề xuất không có bằng chứng là ý kiến cá nhân.
+
+## Trước khi kết thúc
+
+In bốn thứ:
+
+**① Bảng KPI** — `GOAL` × baseline × mục tiêu × thực tế × đạt/không, kèm yếu tố nhiễu.
+
+**② Bảng tự chấm Gate G5** dạng ☐/✅.
+
+**③ Bài học** — bảng `quan sát → nguyên nhân → lần sau làm khác thế nào`.
+
+**④ Đề xuất vòng sau** — đã xếp theo giá trị/chi phí, kèm khuyến nghị của BA.
+
+## Bẫy thường gặp
+
+**Bỏ hẳn giai đoạn này.** Phổ biến nhất. Hậu quả: không ai biết dự án có đáng tiền không,
+và cùng một sai lầm lặp lại ở dự án sau. Nếu thật sự không có thời gian, tối thiểu làm
+Bước 4 (đo KPI) và Bước 5 (bài học) — hai bước này rẻ nhất và có giá trị lâu nhất.
+
+**Release note viết như changelog kỹ thuật.** Người dùng không quan tâm endpoint nào được
+thêm. Họ quan tâm việc của họ thay đổi thế nào.
+
+**Tài liệu hướng dẫn viết theo màn hình.** Người dùng tìm theo công việc, không theo tên
+màn hình. Mục lục theo màn hình là mục lục không ai tra được.
+
+**Đo KPI quá sớm.** Tuần đầu sau go-live luôn xấu vì người dùng đang học. Đo lúc đó rồi kết
+luận thất bại là kết luận sai.
+
+**Đổi cách đo giữa chừng.** Nếu baseline đo bằng cách A thì thực tế cũng phải đo bằng cách
+A. Đổi sang cách B "chính xác hơn" làm mất khả năng so sánh — và thường xảy ra đúng lúc kết
+quả không đẹp.
+
+**Báo cáo toàn màu xanh.** Không ai tin, và không ai học được gì. `BENEFIT` viết để học.
+
+**Bài học viết chung chung.** "Cần giao tiếp tốt hơn" không dùng được. Bài học phải cụ thể
+tới mức lần sau đọc là biết làm khác chỗ nào.

.claude/skills/ba-5-post-release/examples.md

@@ -0,0 +1,94 @@
+# Ví dụ minh hoạ — `ba-5-post-release`
+
+Tách khỏi `SKILL.md` để quy trình không lẫn ví dụ của một ngành cụ thể.
+
+---
+
+## Bước 1 · Release note viết cho người dùng, không cho dev
+
+| ❌ Changelog kỹ thuật | ✅ Release note nghiệp vụ |
+|---|---|
+| "Thêm endpoint `GET /discrepancies`" | "Bạn xem được chênh lệch POS ngay trong ngày, thay vì chờ cuối tháng" |
+| "Áp dụng regex `^[A-Z0-9-]+$` cho field code" | "Từ 01/09, ô Mã cửa hàng chỉ nhận chữ hoa và số" |
+| "Thêm optimistic locking cho bảng `appointment`" | "Nếu hai người cùng đặt một khung giờ, người bấm sau sẽ được báo và chọn giờ khác — trước đây cả hai đều đặt được rồi một người bị gọi lại huỷ" |
+| "Migrate `warehouse_code` sang uppercase" | "Mã kho giờ hiển thị đồng nhất bằng chữ hoa. Báo cáo cũ vẫn giữ nguyên định dạng cũ" |
+
+### Mục "thay đổi có thể làm bạn giật mình" — hay bị bỏ, và đắt
+
+| Hiện tượng người dùng sẽ thấy | Vì sao | Có phải lỗi không |
+|---|---|---|
+| Số liệu tháng 8 khác báo cáo cũ | Cách tính chênh lệch đổi: làm tròn từng dòng thay vì làm tròn tổng | Không — xem mục 3.1 |
+| Danh sách lịch hẹn ít hơn hôm qua | Lịch quá hạn 30 ngày được chuyển sang tab Lưu trữ | Không |
+
+🔴 Đổi cách tính một chỉ số mà không báo trước là cách nhanh nhất để mất niềm tin: người dùng
+thấy số nhảy và kết luận hệ thống sai.
+
+---
+
+## Bước 4 · KPI so với baseline
+
+### Đạt — có đủ ba yếu tố
+
+```
+GOAL-02 | Thời gian phát hiện chênh lệch
+          Baseline:  22 ngày (TB tháng 6–7/2026, nguồn: sổ đối soát của chị Lan)
+          Mục tiêu:  ≤ 1 ngày
+          Thực tế:   1,4 ngày (TB tháng 10–12/2026, cùng cách đo)
+          Đạt?       🟠 Gần đạt
+          Yếu tố nhiễu: tháng 12 là cao điểm, khối lượng gấp 1,8 lần
+                        → làm kết quả XẤU hơn thực chất
+```
+
+### Không đo được — ghi rõ, không lấp liếm
+
+```
+GOAL-03 | Giảm khiếu nại của cửa hàng về số liệu
+          Baseline:  ❌ KHÔNG CÓ — GĐ1 không ghi
+          Thực tế:   không so sánh được
+          Xử lý:     ước lượng ngược từ ticket CS tháng 5–7/2026 được 14 ca/tháng,
+                     nhưng ticket lúc đó chưa phân loại theo nguyên nhân
+                     → 🔴 độ tin cậy THẤP, không dùng để kết luận
+          Bài học:   bắt buộc điền baseline trước khi qua G1
+```
+
+🔴 Không có baseline là **bài học của GĐ1**, không phải lý do để bịa một con số đẹp.
+
+### Đối chiếu ba nguồn — chỗ ra phát hiện
+
+| Phát hiện | Số liệu nói | Người dùng nói | Ticket nói | Kết luận |
+|---|---|---|---|---|
+| Chức năng "xuất báo cáo tuỳ chọn" | 3 lượt dùng/tháng | "Rất tiện, hay dùng" | 0 ticket | 🔴 Ai cũng khen nhưng gần như không ai dùng — hỏi lại vì sao |
+| Màn hình đối soát | 340 lượt/tháng | "Bình thường" | 11 ticket "không tìm thấy nút đóng" | Dùng nhiều nhưng có điểm vướng — ưu tiên sửa |
+
+Dòng đầu là kiểu phát hiện chỉ xuất hiện khi đối chiếu, không nguồn riêng lẻ nào cho thấy.
+
+---
+
+## Bước 5 · Bài học — quan sát → nguyên nhân → hành động
+
+### ❌ Không dùng được
+
+- "Cần giao tiếp tốt hơn với khách hàng"
+- "Nên làm tài liệu kỹ hơn"
+- "Cần test nhiều hơn"
+
+### ✅ Dùng được
+
+| Quan sát được | Nguyên nhân | Lần sau làm khác thế nào | Áp dụng ở |
+|---|---|---|---|
+| 7/12 CR là spec gap về xử lý dữ liệu cũ | GĐ2 chỉ rà tác động code, không rà dữ liệu lịch sử | Bắt buộc điền `IMPACT §1.2` với **số bản ghi thật**, cấm ghi "sẽ xử lý sau" | GĐ2 |
+| Kế toán phủ quyết ở tuần cuối UAT | Không có trong stakeholder map từ đầu | Rà đích danh 3 nhóm hay bị sót ở Bước 1 GĐ1 | GĐ1 |
+| 9/34 câu hỏi của dev thuộc loại 3 (spec không nói) | Đều về đồng thời và chạy lại — không có trong checklist G3 | Thêm hai câu vào checklist G3: "hai người cùng sửa thì sao?" và "chạy lại thì sao?" | GĐ3 |
+| Cùng một câu hỏi về bảng field bị hỏi 4 lần | Bảng field nằm cuối tài liệu 60 trang, khó tra | Đưa bảng field lên đầu PART 2, thêm mục lục theo field | GĐ3 |
+
+Bài học phải cụ thể **tới mức lần sau đọc là biết sửa chỗ nào trong quy trình** — và ba dòng
+cuối đều dẫn tới một thay đổi cụ thể trong chính bộ skill này.
+
+### Rút từ dữ liệu, không ngồi nhớ lại
+
+| Nguồn | Số liệu kỳ này | Rút ra |
+|---|---|---|
+| `QLOG` loại 2 (mơ hồ) | 11/34 | Cao ⇒ vi phạm W2, viết chặt hơn |
+| `QLOG` loại 3 (không nói) | 9/34 | Cao ⇒ đặc tả thiếu phạm vi |
+| `CR` là spec gap | 7/12 | 🔴 Rất cao ⇒ rà lại checklist G3 |
+| `UAT` "hiểu nhầm cách dùng" | 5 ca | Đưa cả 5 vào FAQ của `MANUAL` |

.claude/skills/ba-5-post-release/templates/benefit-review.md

@@ -0,0 +1,182 @@
+# BENEFIT — Benefit Realization Review — <PROJECT>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <BA> (skill ba-5-post-release) |
+| **Status** | 🟡 Draft |
+| **Approved by** | PO: — · BA Lead: — |
+| **Ngày go-live** | |
+| **Cửa sổ đo** | từ … đến … *(sau go-live … tháng)* |
+| **Source** | BRIEF_… v1.0 §4 · UAT_… · QLOG_… · CR_… |
+
+> 🔴 **Tài liệu này viết để học, không phải để khoe.** Một báo cáo nói *"KPI không đạt vì lý
+> do X"* có giá trị hơn nhiều một báo cáo toàn màu xanh mà không ai tin.
+
+---
+
+## 1. Kết luận
+
+| | |
+|---|---|
+| **Số GOAL đạt** | … / … |
+| **Kết luận tổng thể** | ✅ Đạt kỳ vọng / 🟠 Đạt một phần / 🔴 Không đạt / ⏳ Chưa đo được |
+| **Phát hiện quan trọng nhất** | |
+| **Đề xuất chính** | |
+
+*Viết mục này sau cùng.*
+
+---
+
+## 2. KPI so với baseline
+
+| GOAL | Chỉ số | Baseline (GĐ1) | Mục tiêu | **Thực tế** | Đạt? | Nguồn số liệu | Cách tính |
+|---|---|---|---|---|---|---|---|
+| GOAL-01 | | | | | ✅/🟠/🔴/⏳ | | |
+| GOAL-02 | | | | | | | |
+
+**Bốn quy tắc đo — xác nhận từng cái:**
+
+| # | Quy tắc | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | Đo **cùng cách** với lúc lấy baseline | | Đổi cách đo ⇒ không so sánh được |
+| 2 | Đo sau khi hệ thống **ổn định** (≥1 tháng, tốt nhất 3 tháng) | | Tuần đầu luôn nhiễu |
+| 3 | Đã ghi rõ **yếu tố nhiễu** | | Xem §2.1 |
+| 4 | Không đo được thì **ghi là không đo được** | | Không ước lượng một con số đẹp |
+
+🔴 Quy tắc 1 hay bị vi phạm đúng lúc kết quả không đẹp: người ta đổi sang cách đo "chính xác
+hơn". Nếu buộc phải đổi cách đo, trình **cả hai con số** và giải thích.
+
+### 2.1 Yếu tố nhiễu
+
+*Cùng thời gian đó có thay đổi gì khác không? Không có yếu tố nhiễu là chuyện hiếm.*
+
+| # | Yếu tố | Ảnh hưởng tới GOAL nào | Theo hướng nào | Ước tính mức độ |
+|---|---|---|---|---|
+| 1 | *(vd: tuyển thêm 2 nhân viên đối soát)* | GOAL-01 | Làm kết quả **đẹp hơn** thực chất | |
+| 2 | *(vd: tháng cao điểm, khối lượng gấp đôi)* | GOAL-02 | Làm kết quả **xấu hơn** thực chất | |
+
+### 2.2 GOAL không đo được
+
+| GOAL | Vì sao không đo được | Khắc phục cho lần sau |
+|---|---|---|
+| | *(vd: GĐ1 không ghi baseline)* | Bắt buộc điền baseline trước khi qua G1 |
+
+🔴 **Không có baseline là bài học của GĐ1, không phải lý do để bỏ qua.** Có thể ước lượng
+ngược từ log/số liệu cũ nếu còn — nhưng phải ghi rõ là **ước lượng ngược, độ tin cậy thấp**.
+
+---
+
+## 3. Mức độ sử dụng thật
+
+*Số liệu không nói dối. Đây là phần đối trọng với phản hồi chủ quan ở §4.*
+
+| Chức năng | US | Số lượt dùng/tháng | Số người dùng khác nhau | Kỳ vọng | Nhận xét |
+|---|---|---|---|---|---|
+| | US-011 | | | | |
+
+**Chức năng gần như không ai dùng:**
+
+| Chức năng | Lượt dùng | Vì sao (giả thuyết) | Đã xác minh bằng cách nào |
+|---|---|---|---|
+
+🔴 Chức năng **ai cũng khen nhưng log cho thấy không ai dùng** là phát hiện quan trọng hơn
+cả hai nguồn riêng lẻ. Đối chiếu §3 với §4 để tìm những chỗ như vậy.
+
+---
+
+## 4. Phản hồi người dùng
+
+### 4.1 Nguồn thu thập
+
+| Nguồn | Số lượng | Thời gian thu thập | Độ tin cậy |
+|---|---|---|---|
+| Khảo sát | | | Thiên lệch về người bức xúc |
+| Phỏng vấn sâu | | | |
+| Ticket hỗ trợ / CS | | | Chỉ thấy phần nổi |
+| Số liệu sử dụng | | | Không nói dối, không giải thích được vì sao |
+
+### 4.2 Phân loại
+
+| Nhóm | Số lượng | Ví dụ tiêu biểu | Đi đâu |
+|---|---|---|---|
+| Lỗi | | | Ticket defect |
+| Yêu cầu tính năng mới | | | Backlog vòng sau |
+| Khó dùng / không tìm thấy | | | Cải thiện thiết kế **hoặc** đào tạo |
+| Hiểu nhầm | | | Bổ sung tài liệu/đào tạo |
+
+### 4.3 Đối chiếu ba nguồn
+
+| Phát hiện | Số liệu nói gì | Người dùng nói gì | Ticket nói gì | Kết luận |
+|---|---|---|---|---|
+| | | | | |
+
+---
+
+## 5. Bài học
+
+> Mẫu bắt buộc: **quan sát được → nguyên nhân → lần sau làm khác thế nào**.
+> Bài học kiểu *"cần giao tiếp tốt hơn"* là không dùng được.
+
+### 5.1 Rút từ dữ liệu có sẵn — không ngồi nhớ lại
+
+| Nguồn | Số liệu | Rút ra được gì |
+|---|---|---|
+| `QLOG` loại 2 (spec mơ hồ) | … câu | Cao ⇒ vi phạm quy tắc W2, cần viết chặt hơn ở mục nào |
+| `QLOG` loại 3 (spec không nói) | … câu | Cao ⇒ đặc tả thiếu phạm vi, rà lại checklist G3 |
+| `QLOG` loại 4 (spec sai) | … câu | Cao ⇒ GĐ2 hiểu sai nghiệp vụ |
+| `QLOG` câu hỏi lặp lại | … | Mục tài liệu nào khó tra cứu |
+| `CR` — số **spec gap** | … / … CR | Chỗ nào của đặc tả hay bỏ sót |
+| `UAT` "hiểu nhầm cách dùng" | … | Thiết kế hoặc đào tạo chưa đủ |
+| `RISK` đã xảy ra thật | … / … | Rủi ro nào dự đoán đúng, rủi ro nào không lường được |
+
+### 5.2 Bảng bài học
+
+| # | Quan sát được | Nguyên nhân | Lần sau làm khác thế nào | Áp dụng ở giai đoạn |
+|---|---|---|---|---|
+| 1 | 7/12 CR là spec gap về xử lý dữ liệu cũ | GĐ2 chỉ rà tác động code, không rà dữ liệu lịch sử | Bắt buộc điền §1.2 của `IMPACT` với số bản ghi thật, không để "sẽ xử lý sau" | GĐ2 |
+| 2 | Kế toán phủ quyết ở tuần cuối UAT | Không có trong stakeholder map từ đầu | Rà đích danh 3 nhóm hay bị sót ở Bước 1 GĐ1 | GĐ1 |
+
+### 5.3 Cái gì đã làm tốt — giữ lại
+
+| # | Việc | Vì sao hiệu quả |
+|---|---|---|
+
+*Bài học không chỉ là danh sách sai lầm. Cái làm tốt mà không ghi lại thì lần sau cũng không lặp lại được.*
+
+---
+
+## 6. Đề xuất vòng sau
+
+> Mỗi đề xuất phải có **bằng chứng từ §3/§4**. Đề xuất không có bằng chứng là ý kiến cá nhân.
+
+| # | Đề xuất | Vấn đề nó giải quyết | Bằng chứng | Ước lượng | Lợi ích kỳ vọng | Ưu tiên BA đề xuất |
+|---|---|---|---|---|---|---|
+| 1 | | | §4.2: 14 phản hồi cùng nội dung | | | Cao |
+
+**Khuyến nghị của BA:** …
+
+*(Khuyến nghị, không phải quyết định — PO chốt.)*
+
+---
+
+## 7. Tự chấm Gate G5
+
+| # | Tiêu chí | ☐/✅ | Ghi chú |
+|---|---|---|---|
+| 1 | `RELNOTE` đã phát hành cho người dùng | | |
+| 2 | `MANUAL` / tài liệu đào tạo đã bàn giao | | |
+| 3 | KPI thực tế đã so sánh với baseline và mục tiêu | | |
+| 4 | Feedback đã thu thập và phân loại | | |
+| 5 | Bài học đã viết theo mẫu quan sát→nguyên nhân→hành động | | |
+| 6 | Đề xuất vòng sau đã lập và đưa vào backlog | | |
+
+## 8. Kết thúc hay mở vòng mới
+
+| | |
+|---|---|
+| **Quyết định** | Đóng dự án / Mở vòng cải tiến / Chờ đo lại sau … tháng |
+| **Người quyết** | |
+| **Ngày** | |
+| **Nếu mở vòng mới** | Chạy `/ba-1-discovery <PROJECT>` — `BRIEF` phiên bản mới, **không sửa đè bản cũ** |

.claude/skills/ba-5-post-release/templates/release-note.md

@@ -0,0 +1,109 @@
+# RELNOTE — <Tên hệ thống> — Bản phát hành <ngày / số hiệu>
+
+| | |
+|---|---|
+| **Ngày phát hành** | YYYY-MM-DD |
+| **Phiên bản** | |
+| **Người viết** | <BA> |
+| **Đối tượng đọc** | Người dùng cuối *(không phải dev)* |
+| **US bao gồm** | US-011, US-012, US-013 |
+
+> 🔴 **Đây không phải changelog kỹ thuật.**
+>
+> | Viết thế này | Không viết thế này |
+> |---|---|
+> | "Bạn xem được chênh lệch POS ngay trong ngày, thay vì chờ cuối tháng" | "Thêm endpoint GET /discrepancies" |
+> | "Từ 01/09, ô Mã cửa hàng chỉ nhận chữ hoa và số" | "Áp dụng regex `^[A-Z0-9-]+$` cho field code" |
+
+---
+
+## 1. Tóm tắt
+
+*Hai câu. Bản phát hành này thay đổi gì trong công việc hằng ngày của bạn.*
+
+---
+
+## 2. Có gì mới
+
+*Sắp theo công việc của người dùng, không theo màn hình.*
+
+### 2.1 <Tên công việc theo cách người dùng gọi>
+
+| | |
+|---|---|
+| **Dành cho** | *(vai trò nào)* |
+| **Trước đây** | |
+| **Từ nay** | |
+| **Vào ở đâu** | |
+
+*(ảnh chụp màn hình)*
+
+---
+
+## 3. Có gì thay đổi so với cách làm cũ
+
+> 🔴 **Mục quan trọng nhất.** Đây là chỗ gây bối rối và gây cuộc gọi tới bộ phận hỗ trợ.
+
+| # | Thay đổi | Trước | Sau | Bạn cần lưu ý gì | Từ ngày |
+|---|---|---|---|---|---|
+| 1 | | | | | |
+
+**Thay đổi có thể làm bạn giật mình:**
+
+| Hiện tượng bạn sẽ thấy | Vì sao | Có phải lỗi không |
+|---|---|---|
+| *(vd: số liệu tháng 8 khác báo cáo cũ)* | Cách tính chênh lệch đã đổi theo quy tắc mới | Không — xem mục 3.1 |
+
+*Đổi cách tính một chỉ số mà không báo trước là cách nhanh nhất để mất niềm tin: người dùng
+thấy số nhảy và nghĩ hệ thống sai.*
+
+---
+
+## 4. Bạn cần làm gì
+
+| # | Việc | Ai cần làm | Hạn | Vì sao |
+|---|---|---|---|---|
+| 1 | | | | |
+
+*Không có việc gì cần làm thì ghi rõ "Không cần làm gì" — đừng để trống.*
+
+---
+
+## 5. Chưa có gì *(hạn chế đã biết)*
+
+> Mục này hay bị bỏ vì "không hay ho". Nhưng người dùng phát hiện hạn chế mà **không được
+> báo trước** sẽ mất niềm tin vào toàn bộ hệ thống, không chỉ vào tính năng đó.
+
+| # | Chưa làm được | Cách xử lý tạm | Dự kiến có khi nào |
+|---|---|---|---|
+| 1 | | | |
+
+---
+
+## 6. Gặp vấn đề thì làm gì
+
+| Tình huống | Làm gì | Liên hệ ai |
+|---|---|---|
+| Thấy số liệu không đúng | | |
+| Không vào được / lỗi hiển thị | | |
+| Không tìm thấy chức năng | Xem tài liệu hướng dẫn mục… | |
+| Muốn đề xuất cải tiến | | |
+
+---
+
+## 7. Tài liệu kèm theo
+
+| Tài liệu | Dành cho ai | Ở đâu |
+|---|---|---|
+| Hướng dẫn sử dụng | Người dùng | |
+| Video/buổi đào tạo | | |
+| Câu hỏi thường gặp | | |
+
+---
+
+## 8. Lịch hỗ trợ sau phát hành
+
+| Thời gian | Hình thức hỗ trợ | Ai trực |
+|---|---|---|
+| Tuần đầu | | |
+| Tuần 2–4 | | |

.claude/skills/ba-5-post-release/templates/user-manual.md

@@ -0,0 +1,175 @@
+# MANUAL — Hướng dẫn sử dụng — <Tên hệ thống/module>
+
+| | |
+|---|---|
+| **Version** | 1.0 |
+| **Date** | YYYY-MM-DD |
+| **Author** | <BA> |
+| **Đối tượng** | *(vai trò nào đọc tài liệu này)* |
+| **Áp dụng cho phiên bản** | |
+
+> 🔴 **Viết theo công việc, không theo màn hình.** Người dùng tìm *"làm sao để đối soát ngày
+> hôm qua"*, không tìm *"màn hình SCR-01"*. Mục lục theo màn hình là mục lục không ai tra được.
+
+---
+
+## Mục lục theo công việc
+
+| # | Tôi muốn… | Xem mục |
+|---|---|---|
+| 1 | Đối soát dữ liệu của một ngày | §2.1 |
+| 2 | Tìm lại một chênh lệch đã xử lý | §2.2 |
+| 3 | Xuất báo cáo gửi kế toán | §2.3 |
+| 4 | Gặp lỗi khi lưu | §4 |
+
+---
+
+## 1. Trước khi bắt đầu
+
+| | |
+|---|---|
+| **Đường dẫn** | |
+| **Đăng nhập bằng** | |
+| **Quyền bạn cần có** | |
+| **Trình duyệt khuyến nghị** | |
+| **Không vào được thì liên hệ** | |
+
+**Bạn thuộc vai trò nào — và điều đó ảnh hưởng gì:**
+
+| Vai trò | Bạn làm được gì | Bạn không thấy chức năng nào |
+|---|---|---|
+| | | |
+
+*Người dùng không thấy một nút và tưởng hệ thống lỗi là tình huống hỗ trợ phổ biến nhất.
+Bảng này xử lý nó trước khi nó xảy ra.*
+
+---
+
+## 2. Các công việc
+
+### 2.1 <Tên công việc theo cách người dùng gọi>
+
+| | |
+|---|---|
+| **Khi nào làm việc này** | |
+| **Bạn cần chuẩn bị** | |
+| **Mất khoảng** | |
+
+**Các bước:**
+
+1. **<Thao tác>**
+
+   *(ảnh chụp màn hình có khoanh vùng chỗ cần bấm)*
+
+   > 💡 *Mẹo: …*
+
+2. **<Thao tác>**
+
+   > ⚠️ *Lưu ý: …*
+
+**Kết quả bạn sẽ thấy:**
+
+*(ảnh chụp)*
+
+**Nếu không đúng như vậy:** xem §4.
+
+---
+
+**Lỗi thường gặp ở công việc này:**
+
+| Bạn thấy | Nghĩa là | Làm gì |
+|---|---|---|
+| | | |
+
+*Nguồn của bảng này: mục "hiểu nhầm cách dùng" trong `UAT` §B2 và các quan sát ở §B3 — đó là
+chỗ người dùng **thật sự** vấp phải, đã được kiểm chứng, không phải phỏng đoán.*
+
+---
+
+## 3. Giải thích thuật ngữ
+
+| Thuật ngữ trên màn hình | Nghĩa là gì | Ví dụ |
+|---|---|---|
+| | | |
+
+*Lấy từ `GLOSSARY` trong `00-index/`. Thuật ngữ hệ thống dùng mà người dùng không quen là
+nguồn hiểu nhầm thường xuyên.*
+
+---
+
+## 4. Gặp lỗi thì làm gì
+
+*Lấy từ bảng mã lỗi trong `SRS` §4.1, viết lại bằng ngôn ngữ người dùng.*
+
+| Thông báo bạn thấy | Nghĩa là | Bạn nên làm gì | Vẫn không được thì |
+|---|---|---|---|
+| "Mã cửa hàng này đã được sử dụng." | Mã bạn nhập trùng với cửa hàng khác | Kiểm tra lại danh sách, chọn mã khác | Liên hệ … |
+
+---
+
+## 5. Câu hỏi thường gặp
+
+*Nguồn: `QLOG` (câu hỏi lặp lại) + `UAT` §B2 (hiểu nhầm cách dùng) + phản hồi sau go-live.*
+
+**Hỏi:** …
+**Đáp:** …
+
+---
+
+## 6. Những gì hệ thống chưa làm được
+
+| Chưa làm được | Hiện phải làm thế nào | Dự kiến có khi nào |
+|---|---|---|
+
+*Ghi ra để người dùng không mất thời gian đi tìm chức năng không tồn tại.*
+
+---
+
+## 7. Liên hệ hỗ trợ
+
+| Vấn đề | Liên hệ | Kênh | Thời gian phản hồi |
+|---|---|---|---|
+
+---
+
+# Phụ lục — Nội dung đào tạo
+
+## P1. Kế hoạch buổi đào tạo
+
+| | |
+|---|---|
+| **Đối tượng** | |
+| **Số người** | |
+| **Thời lượng** | |
+| **Hình thức** | Trực tiếp / Trực tuyến / Tự học |
+| **Ngày** | |
+
+| Thời gian | Nội dung | Hình thức |
+|---|---|---|
+| 0–10' | Vì sao có thay đổi này *(lấy từ `BRIEF` §3)* | Trình bày |
+| 10–30' | Đi qua luồng công việc chính | Demo |
+| 30–60' | **Người học tự thao tác trên dữ liệu mẫu** | Thực hành |
+| 60–75' | Hỏi đáp | |
+
+🔴 **Phần thực hành là phần duy nhất tạo ra thay đổi hành vi.** Buổi đào tạo chỉ có trình
+bày và demo thì tuần sau người dùng vẫn làm theo cách cũ.
+
+## P2. Bài thực hành
+
+| # | Tình huống | Người học phải làm gì | Coi là đạt khi |
+|---|---|---|---|
+| 1 | | | |
+
+*Lấy tình huống từ kịch bản `UAT` §A5 — chúng đã được kiểm chứng là phản ánh công việc thật.*
+
+## P3. Theo dõi sau đào tạo
+
+| # | Việc | Khi nào | Ai |
+|---|---|---|---|
+| 1 | Gửi tài liệu + link video | Ngay sau buổi | BA |
+| 2 | Trực hỗ trợ tại chỗ | Tuần đầu | |
+| 3 | Kiểm tra số lượt sử dụng thật | Sau 2 tuần | BA |
+| 4 | Thu thập phản hồi | Sau 1 tháng | BA |
+
+*Việc số 3 là việc hay bị bỏ và là việc trung thực nhất: nếu sau hai tuần không ai dùng, thì
+buổi đào tạo đã không có tác dụng — và đó là dữ liệu cho `BENEFIT`.*