init git

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