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`

5.3 KiB Raw Blame History Unescape Escape

Ví dụ minh hoạ — ba-5-post-release