Product & Project ManagerPM không trả lời ngay "có" hay "không" mà đưa yêu cầu qua quy trình change control: đánh giá tác động lên phạm vi, tiến độ, chi phí, rủi ro, rồi để người có thẩm quyền quyết định dựa trên con số.
Quy trình:
- Ghi nhận vào change request log: ai yêu cầu, nội dung, lý do nghiệp vụ, mức độ gấp.
- Phân loại: đây là thay đổi thật, hay chỉ là làm rõ một yêu cầu đã có trong hợp đồng? Lỗi so với spec đã chốt thì không phải change request. Phần phân tích nội dung yêu cầu thường do BA làm.
- Đánh giá tác động cùng tech lead: bao nhiêu man-day, ảnh hưởng milestone nào, có đụng vào phần đã test xong không.
- Đưa phương án cho khách: làm và tính thêm chi phí; làm và đổi lấy một hạng mục có độ lớn tương đương; hoặc chuyển sang giai đoạn sau.
- Chốt bằng văn bản (CR có chữ ký hoặc email xác nhận), cập nhật baseline phạm vi và kế hoạch, báo lại team.
Với hợp đồng fixed-price, mỗi thay đổi làm miễn phí là lợi nhuận dự án bị cắt. Trước khi báo giá, mở lại điều khoản thay đổi trong hợp đồng hoặc SOW: thường đã quy định đơn giá man-day cho phần phát sinh và ai phía khách có quyền ký CR. Thay đổi nhỏ có thể nhận miễn phí để giữ quan hệ, nhưng vẫn phải ghi lại: cộng dồn 20 thay đổi "nhỏ" có thể bằng cả một sprint.
Lưu ý: đừng để dev nhận yêu cầu trực tiếp từ khách qua chat rồi làm luôn. Đây là con đường phổ biến nhất khiến phạm vi phình ra mà PM không biết; thống nhất với khách rằng mọi yêu cầu mới đều đi qua PM hoặc BA.