160 lines
7.4 KiB
Markdown
160 lines
7.4 KiB
Markdown
# 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`
|