# 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`