Impact Analysis
Việc rà xem một thay đổi sẽ đụng tới những đâu trước khi ai đó gật đầu: chức năng liên quan, dữ liệu cũ, tích hợp, báo cáo, phạm vi test lại, tài liệu và cả người đang vận hành.
Định nghĩa
Khách nhắn một câu: "Chỉ đổi cách tính phí ship thôi mà, đơn giản." Câu đó, hoặc một biến thể của nó, bạn sẽ nghe suốt đời làm nghề. Việc của bạn là trong vài giờ trả lời được nó đụng tới đâu, tốn bao nhiêu, và rủi ro nằm ở chỗ nào. Đó là impact analysis.
Đa số thay đổi trông nhỏ ở phần nhìn thấy và to ở phần không nhìn thấy. Bạn được trả lương cho phần không nhìn thấy.
Chín chỗ phải soi
Chạy theo danh sách này, đừng chạy theo trí nhớ:
- Chức năng liên quan — dùng ma trận truy vết hoặc tìm theo mã yêu cầu. Chỗ nào đang gọi tới logic sắp đổi.
- Dữ liệu đang có — bản ghi cũ tính theo công thức cũ có phải tính lại không, có cần chạy backfill không, dữ liệu đang treo giữa chừng xử lý ra sao.
- Tích hợp — API cho đối tác, file trao đổi định kỳ, webhook. Đổi cấu trúc thì phải báo trước bao lâu theo thoả thuận.
- Báo cáo và số liệu — thứ hay bị quên nhất. Có báo cáo nào đang đọc thẳng bảng dữ liệu cũ không.
- Phân quyền và luồng phê duyệt — thêm một bước duyệt thì phải thêm vai trò, thêm thông báo, và ai đó phải cấu hình cho 60 chi nhánh.
- Phạm vi kiểm thử lại — bao nhiêu test case phải sửa, bao nhiêu ca hồi quy phải chạy, có cần dữ liệu test mới không.
- Tài liệu — FRD, tài liệu hướng dẫn người dùng, kịch bản UAT, tài liệu API.
- Người và vận hành — cần đào tạo lại không, tổng đài có phải học kịch bản trả lời mới không, có thông báo gì cho khách hàng không.
- Lịch và phụ thuộc — thay đổi này chặn việc gì đang chạy song song, có đụng mốc đóng băng trước go-live không.
Mục 4 và mục 8 gây đau nhiều nhất trong thực tế, vì cả hai đều nằm ngoài tầm nhìn của đội phát triển.
Mẫu bảng
Một bảng năm cột là đủ dùng cho hầu hết CR:
| Hạng mục | Tác động | Công ước tính | Rủi ro | Ghi chú |
|---|---|---|---|---|
| Màn hình tính phí | Sửa logic, thêm cấu hình theo vùng | 2 ngày | Thấp | |
| Dữ liệu đơn đang treo | 1.400 đơn chưa giao, cần quyết áp giá nào | 1 ngày | Cao | Cần nghiệp vụ quyết |
| API đối tác giao vận | Thêm trường vùng phí | 1,5 ngày | Trung bình | Báo trước 5 ngày làm việc |
| Báo cáo doanh thu ngày | Công thức đang hard-code | 2 ngày | Cao | Kế toán đang dùng hằng ngày |
| Hồi quy | 34 test case, 9 ca phải viết mới | 3 ngày | Trung bình |
Cuối bảng ghi ba dòng: tổng công, ngày sớm nhất có thể lên, và phương án nếu không làm. Người duyệt cần đúng ba thông tin đó để quyết.
Ví dụ thực tế
Sàn thương mại nội địa, khoảng 18.000 đơn mỗi ngày, đổi cách tính phí giao hàng từ một mức phẳng toàn quốc sang phí theo vùng và theo trọng lượng. Khách nghĩ đây là việc hai ngày.
Kết quả rà soát trong một buổi chiều:
- Logic tính phí xuất hiện ở ba nơi: màn hình giỏ hàng, dịch vụ tạo đơn, và job tính lại phí khi khách đổi địa chỉ.
- 1.400 đơn đang ở trạng thái chờ lấy hàng. Áp giá mới cho đơn đã đặt là chuyện nghiệp vụ, không phải chuyện kỹ thuật, và cần người có thẩm quyền quyết.
- Mã khuyến mãi miễn phí ship đang trừ theo con số cố định. Với phí theo vùng, có ba tổ hợp làm giá trị đơn về âm.
- Báo cáo doanh thu ngày gửi kế toán lúc 7 giờ sáng đang cộng phí ship theo công thức viết cứng trong câu truy vấn.
- App tài xế hiển thị phí thu hộ, phải cập nhật cùng lúc, và app phải qua kiểm duyệt cửa hàng ứng dụng mất 2–3 ngày.
Tổng công từ 2 ngày thành 11 ngày, trong đó chỗ đắt nhất là ba tổ hợp khuyến mãi. Khách vẫn đồng ý làm, nhưng lịch được dời ngay từ đầu và có một quyết định nghiệp vụ được chốt bằng văn bản về 1.400 đơn treo. Chi phí của buổi chiều rà soát đó gần như bằng không so với việc phát hiện ở tuần thứ hai.
Lỗi hay gặp
Chỉ nhìn phần code. Chỉ hỏi một dev. Ước lượng khi đang đứng trong phòng họp và khách đang nhìn — luôn xin lại một buổi để rà, chưa ai chết vì chờ thêm bốn tiếng. Và lỗi nặng nhất: làm impact analysis rồi cất vào máy mình. Nó phải nằm đính kèm ngay trong CR, vì sáu tháng sau khi có người hỏi "sao chỗ này lại làm thế", cái bảng đó là câu trả lời.
