Đây là ca kinh điển của phạm vi phình to (scope creep) — thay đổi đến muộn, nghe thì "nhỏ" nhưng chạm vào phần rủi ro nhất là tích hợp thanh toán. Góc nhìn của Ban biên tập:
1. Không trả lời "có" hay "không" ngay tại cuộc gọi. Tinh thần PMBOK 7 là tập trung vào giá trị chứ không phải bám cứng phạm vi; nhưng mọi thay đổi vẫn phải đi qua quy trình kiểm soát thay đổi. Việc đầu tiên là ghi nhận yêu cầu, rồi phân tích tác động lên tiến độ, chi phí, chất lượng và rủi ro.
2. Làm rõ giá trị thật. Hỏi lại: mất bao nhiêu khách nếu thiếu đặt cọc trong 3–4 tuần đầu? Có đo được không? Nhiều khi "đối thủ vừa ra" là cảm giác, chưa phải dữ liệu.
3. Đưa ra phương án có đánh đổi rõ ràng cho người có thẩm quyền quyết định (sponsor/ban kiểm soát thay đổi):
- Phương án A – giữ ngày, giữ phạm vi: rủi ro thấp nhất, khách hàng có thể không vui.
- Phương án B – thêm vào bản này, lùi go-live: đầy đủ tính năng nhưng phá vỡ cam kết đã truyền thông.
- Phương án C – tách phát hành: go-live đúng ngày với phần lõi; phát triển tính năng thanh toán sau một công tắc tính năng (feature toggle), bật khi đã kiểm thử xong. Kỹ thuật này tách "triển khai mã" khỏi "phát hành tính năng", giúp không phải dồn mọi thứ vào một ngày.
- Phương án D – nhồi vào và tăng ca: thường là lựa chọn tệ nhất — vừa đội rủi ro chất lượng ở phần thanh toán, vừa đốt sức đội ngay trước ngày lên sóng.
4. Khuyến nghị: thường phương án C cân bằng nhất. Nó phản ánh nguyên tắc thích ứng và phục hồi (adaptability & resilience) và lĩnh vực hiệu suất Delivery — giao giá trị theo từng phần. Điều kiện: khách hàng đồng ý bằng văn bản, thay đổi được cập nhật vào baseline phạm vi và kế hoạch phát hành.
5. Rút kinh nghiệm cho lần sau: ngay từ đầu, thống nhất một "ngày đóng băng phạm vi" (scope freeze) cho mỗi bản phát hành và quy tắc xử lý yêu cầu đến sau ngày đó. Khi luật chơi rõ từ trước, cuộc gọi kiểu này bớt căng thẳng hơn nhiều.
Nguồn: