Nguyễn Thu Hà, PMP
Tình huống này là hệ quả của việc không thống nhất "xong" nghĩa là gì ngay từ đầu.
1. Tách lỗi và yêu cầu mới. Lập danh sách tất cả mục khách hàng nêu, phân loại cùng khách hàng:
- Lỗi: chức năng có trong phạm vi hợp đồng nhưng không hoạt động đúng → bên bạn sửa.
- Cải tiến/yêu cầu mới: không có trong phạm vi (ví dụ tích hợp phần mềm chấm công mới mua) → xử lý qua yêu cầu thay đổi, có thể là phụ lục hoặc giai đoạn 2.
- Vùng xám: đặc tả mơ hồ, hai bên hiểu khác → đàm phán, có thể nhượng bộ một phần để giữ quan hệ. Dữ kiện quan trọng: khách hàng đã dùng hệ thống tính lương 3 kỳ — đó là bằng chứng mạnh rằng hệ thống đáp ứng chức năng cốt lõi.
2. Đi đến nghiệm thu:
- Đề xuất nghiệm thu có điều kiện: ký nghiệm thu với danh sách lỗi tồn đọng kèm cam kết thời hạn sửa; các yêu cầu mới được báo giá riêng.
- Nhấn vào lợi ích chung: nghiệm thu giúp chuyển sang giai đoạn bảo hành/hỗ trợ có cam kết rõ ràng — điều có lợi cho khách hàng.
- Nếu cần, nâng cấp lên cấp sponsor hai bên — mang theo danh sách đã phân loại, không mang cảm xúc.
- Tham khảo điều khoản hợp đồng về nghiệm thu (có điều khoản "mặc nhiên nghiệm thu khi đưa vào sử dụng" không?) — nhưng dùng như căn cứ thương lượng, không phải vũ khí đầu tiên.
3. Lần sau:
- Tiêu chí chấp nhận cho từng chức năng/user story, được khách hàng duyệt trước khi làm. Agile Alliance nhấn mạnh user story cần đi kèm tiêu chí chấp nhận rõ ràng cho đội phát triển.
- Định nghĩa hoàn thành (Definition of Done) thống nhất giữa hai bên — Agile Alliance mô tả DoD giúp tránh tình trạng "xong" của đội và "xong" của khách hàng mang nghĩa khác nhau.
- Nghiệm thu từng phần theo mốc, thay vì dồn một lần cuối dự án.
- Quy trình kiểm soát thay đổi ghi trong hợp đồng: yêu cầu mới → đánh giá tác động → phê duyệt → điều chỉnh giá/tiến độ.
Theo PMBOK 7, đây là lĩnh vực hiệu suất Delivery (xác nhận phạm vi, tiêu chí chấp nhận) và Stakeholders: kỳ vọng không được làm rõ sớm sẽ quay lại thành tranh chấp ở cuối.
Nguồn: