7.4 KiB
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:
- Đ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
- Đo sau khi hệ thống ổn định — tuần đầu luôn nhiễu
- 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?
- 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