Files

Leonard-ThindPad-P50 c81f249920 init git

2026-09-08 10:26:21 +07:00

5.8 KiB

Raw Blame History

CR — Change Request — `CR-nnn`


ID	CR-001
Ngày nhận	YYYY-MM-DD
Người đề xuất
Kênh
Ưu tiên đề xuất	Khẩn / Cao / Trung bình / Thấp
Trạng thái	🟡 Đang đánh giá / 🟠 Chờ PO quyết / ✅ Chấp nhận / ⏸ Hoãn / ❌ Từ chối
Author	(skill ba-4-delivery-support)
Liên quan	US-011 · SRS_US011 v1.2 · AC-05

0. Phân loại — làm trước mọi thứ khác

🔴 Đây là phân loại tốn kém nhất khi làm sai. Áp dụng phép thử máy móc, không theo cảm tính.

flowchart TD
    Q1{"Sản phẩm có làm đúng<br/>tài liệu đã ký (SRS Baselined)?"}
    Q2{"Tài liệu có nói về<br/>tình huống này không?"}
    D(["DEFECT<br/>Dev sửa, không tính thêm chi phí<br/>→ Đóng phiếu này"])
    CR(["CHANGE REQUEST<br/>PO quyết<br/>→ Tiếp tục §1"])
    GAP(["SPEC GAP<br/>Thiếu sót đặc tả, trách nhiệm BA<br/>→ Tiếp tục, xem §0.1"])

    Q1 -->|KHÔNG| D
    Q1 -->|CÓ| Q2
    Q2 -->|"CÓ, khách muốn khác đi"| CR
    Q2 -->|"KHÔNG nói gì"| GAP


Kết luận	Defect / Change Request / Spec gap
Căn cứ	(trích đích danh mục tài liệu — không viết "theo tôi nghĩ")

0.1 Nếu là Spec gap

Tài liệu im lặng về tình huống này ⇒ thiếu sót của đặc tả, trách nhiệm thuộc BA.


Vì sao đặc tả bỏ sót
Lẽ ra phải nằm ở mục nào
Đưa vào bài học GĐ5	☐

Xử lý tiếp như một CR (đánh giá tác động, PO quyết), nhưng nói rõ nguyên nhân gốc — đừng đẩy sang khách như CR bình thường, cũng đừng nhận là bug của dev.

1. Yêu cầu — nguyên văn

"…"

Chép nguyên văn. Diễn giải lại theo ý mình là cách làm mất thông tin ngay từ bước đầu.

2. Làm rõ — vấn đề gốc là gì

🔴 Bước cứu được nhiều tiền nhất. Khách nói "thêm cột X vào bảng" → hỏi "để làm gì?" → hoá ra để tìm nhanh hơn → hoá ra chỉ cần thêm bộ lọc, rẻ hơn nhiều.

Câu hỏi	Trả lời
Việc này giải quyết vấn đề gì?
Hiện tại không có nó thì xử lý thế nào?
Bao lâu gặp một lần? Ai gặp?
Nếu để sau bản phát hành này thì sao?
Có cách nào khác đạt cùng kết quả không?

Vấn đề gốc:

(phát biểu lại bằng ngôn ngữ vấn đề, không phải ngôn ngữ giải pháp)

3. Đánh giá tác động

Rà đủ 6 trục như IMPACT ở GĐ2.

Trục	Tác động	Mức
Màn hình/chức năng		🔴/🟠/🟢
Dữ liệu
Business rule
Phân quyền
Tích hợp
Báo cáo/đối soát

Tài liệu phải sửa:

Tài liệu	Mục	Version hiện tại → mới
SRS_US011	§2.3.3, §4.1	v1.2 → v1.3
AC_US011	AC-05, AC-09
RTM

Ảnh hưởng tới việc đã làm:


Code đã viết phải sửa
Test case phải viết lại
Đã UAT rồi thì phải test lại phần nào

Ước lượng (làm cùng dev, không ước lượng một mình):

Hạng mục	Công sức	Ai ước lượng
Phân tích + sửa tài liệu		BA
Phát triển		Dev
Kiểm thử		QA
Tổng

Ảnh hưởng tiến độ: …

4. Phương án

🔴 Luôn trình ≥2 phương án. Một phương án không phải là lựa chọn, đó là thông báo.

#	Phương án	Công sức	Rủi ro	Đáp ứng vấn đề gốc
A	Làm đúng như đề xuất			Hoàn toàn
B	Giải pháp thay thế rẻ hơn			Một phần — thiếu …
C	Hoãn sang phase sau	0	Người dùng phải làm tay tới …	Không

Khuyến nghị của BA: Phương án … vì …

(Khuyến nghị, không phải quyết định — nguyên tắc 2.)

5. Quyết định của PO


Người quyết
Ngày
Quyết định	✅ Chấp nhận PA… / ⏸ Hoãn tới… / ❌ Từ chối
Lý do
Ghi vào	`DEC-nn` trong `00-index/`
Ảnh hưởng tiến độ được chấp nhận
Chi phí được chấp nhận

6. Thực thi

Thứ tự bắt buộc: sửa tài liệu trước, code sau. Ngược lại thì tài liệu không bao giờ đuổi kịp.

#	Việc	Ai	Trạng thái
1	Sửa SRS + tăng version + Change Log	BA	☐
2	Cập nhật RTM	BA	☐
3	Báo cho team (dev, QA, ai đã đọc bản cũ)	BA	☐
4	Sửa code	Dev	☐
5	Cập nhật test case	QA	☐
6	Test lại phạm vi hồi quy	QA	☐

7. Đóng phiếu


Ngày đóng
Đã verify	☐
Người xác nhận

Sổ tổng hợp CR

ID	Ngày	Người đề xuất	Tóm tắt	Loại	Công sức	Trạng thái	Quyết định	Ngày quyết
CR-001				CR	3d	✅	PA-B

Thống kê:

Chỉ số	Giá trị	Ý nghĩa nếu cao
Tổng CR
Trong đó Spec gap		🔴 Đặc tả GĐ3 chưa kỹ — rà lại checklist G3
Trong đó bị phân loại nhầm ban đầu		Cần thống nhất lại phép thử §0 với team
Tổng công sức phát sinh		So với ước lượng ban đầu
CR chờ quyết > 5 ngày		🔴 Đang chặn team

5.8 KiB Raw Blame History

CR — Change Request — CR-nnn