Change Request(CR)
Đề nghị chính thức thay đổi phạm vi, chức năng hoặc tài liệu đã chốt, kèm phân tích tác động về thời gian, chi phí và rủi ro trước khi có người đủ thẩm quyền phê duyệt.
Định nghĩa
Không dự án nào giữ nguyên phạm vi từ đầu đến cuối. Vấn đề không nằm ở việc có thay đổi hay không, mà ở chỗ thay đổi đi qua cửa chính hay lẻn vào cửa sau. CR là cái cửa chính đó: một đề nghị được ghi lại, được đánh giá tác động, được ai đó có thẩm quyền duyệt hoặc từ chối.
Điều kiện tiên quyết để có CR là phải có cái gì đó đã chốt. Không có baseline thì mọi thứ đều là "đang bàn", và khi đó không ai chứng minh được cái gì phát sinh, cái gì đã cam kết.
Baseline trước, CR sau. Không có mốc thì không đo được độ lệch.
Quy trình xử lý một CR
- Ghi nhận: ai đề nghị, đề nghị gì, vì sao cần, mong muốn khi nào có.
- Làm rõ: BA hỏi lại cho tới khi mô tả đủ để ước lượng. Bước này hay bị bỏ, và bỏ là ước lượng sai.
- Phân tích tác động: ảnh hưởng tới yêu cầu nào, module nào, test case nào, dữ liệu nào; thêm bao nhiêu ngày công; kéo mốc nào; rủi ro gì nếu làm và nếu không làm.
- Trình duyệt: hội đồng thay đổi (CCB) hoặc người được uỷ quyền quyết. Ba lựa chọn: duyệt, từ chối, hoặc hoãn sang giai đoạn sau.
- Cập nhật: tài liệu, backlog, kế hoạch, RTM, hợp đồng phụ lục nếu có.
- Thông báo: dev, QC, đội vận hành, và cả những stakeholder không ngồi trong buổi duyệt.
Bước 3 là phần BA tạo ra giá trị lớn nhất. Một CR được trình bày kèm câu "làm cái này sẽ đẩy go-live thêm 9 ngày và phải test lại toàn bộ luồng thanh toán" cho ra quyết định khác hẳn so với chỉ nói "khách muốn thêm cái này".
So sánh CR và Bug
Đây là cuộc cãi nhau kinh điển giữa BA, QC và khách. Câu hỏi phân định chỉ có một: hệ thống có đang làm sai so với yêu cầu đã chốt không?
| Bug (lỗi) | Change Request (thay đổi) | |
|---|---|---|
| Bản chất | Hệ thống chạy khác đặc tả đã duyệt | Đặc tả đã duyệt nay muốn khác đi |
| Ai chịu chi phí | Nhà phát triển, nằm trong hợp đồng | Thường tính thêm, tuỳ hợp đồng |
| Căn cứ phân định | Tài liệu yêu cầu, AC, biên bản chốt | So sánh yêu cầu mới với baseline |
| Ví dụ | Spec ghi làm tròn lên, hệ thống làm tròn xuống | Spec ghi làm tròn lên, khách muốn đổi thành làm tròn xuống |
| Vào đâu | Bug tracker, sửa trong sprint | Danh sách CR, chờ duyệt |
Vùng xám thật sự nằm ở chỗ thứ ba: đặc tả không nói gì. Khách bảo "hiển nhiên phải như thế", dev bảo "spec không có". Trên nguyên tắc thì không có yêu cầu nghĩa là không có lỗi, nên đó là CR. Trên thực tế, nếu thiếu sót đó là do BA viết ẩu, cãi thắng cũng chẳng vẻ vang gì. Nhiều đội xử lý bằng cách gọi là "spec gap": nhận sửa nếu nhỏ, mở CR nếu lớn, và ghi lại để lần sau viết kỹ hơn.
Ví dụ thực tế
Dự án cổng thanh toán học phí cho một hệ thống trung tâm ngoại ngữ, 22 chi nhánh, đã chốt SRS và đang ở sprint 6 trong 8.
Khách đề nghị: cho phụ huynh trả góp học phí 3 kỳ thay vì đóng một lần.
Phân tích tác động BA đưa ra: thêm 1 bảng lịch trả, sửa 4 màn hình, sửa luồng đối soát với ngân hàng, sửa 2 báo cáo doanh thu, ảnh hưởng 17 test case, ước tính 14 ngày công dev và 5 ngày QC, đẩy go-live từ 15/9 sang 30/9 — rơi vào đúng mùa tuyển sinh.
Kết quả: hội đồng duyệt làm, nhưng tách thành phase 2 sau go-live, và phase 1 chỉ thêm một trường ghi chú để nhân viên xử lý tay trong 6 tuần đầu. Cái quyết định đó được đưa ra trong phòng họp, có bảng tác động trên màn hình. Không phải trong một cuộc gọi lúc 9 giờ tối.
Mẹo khi đi làm
Đừng bao giờ nói "cái này phải mở CR" bằng giọng khoá cửa. Nói bằng số: "làm được, mất khoảng 12 ngày công, ảnh hưởng mốc UAT, anh chị cân nhắc đổi ưu tiên với tính năng X". Chuyển từ chuyện thủ tục sang chuyện đánh đổi, và đưa người có thẩm quyền vào vị trí phải chọn.
Giữ một sổ CR mở cho cả khách xem, kể cả những CR bị từ chối. Đến lúc có người hỏi "sao hệ thống không có chức năng này", bạn mở sổ ra và thấy nó bị chính họ hoãn từ tháng Tư.
Với các thay đổi nhỏ dưới nửa ngày công, nhiều đội thoả thuận trước một hạn mức: dưới ngưỡng đó thì xử lý trong sprint, không mở CR. Không có ngưỡng này thì quy trình sẽ chết vì thủ tục.
