Change request (yêu cầu thay đổi) là đề nghị làm khác hoặc làm thêm so với phạm vi đã chốt trong hợp đồng. Thay đổi là chuyện bình thường khi khách bắt đầu dùng bản thử và thấy điều mình chưa nghĩ tới. Cách xử lý công bằng có năm bước: ghi lại bằng văn bản, phân loại lỗi hay thay đổi, ước lượng thời gian và chi phí, bên mua duyệt, rồi mới làm và ghi vào phụ lục. Không duyệt thì không làm và không phát sinh tiền.
Lỗi hay thay đổi: câu hỏi đầu tiên
Mọi tranh cãi về tiền phát sinh đều bắt đầu từ câu này. Phép thử đơn giản: mở đặc tả đã duyệt, tìm chức năng liên quan.
| Tình huống | Loại | Ai trả |
|---|---|---|
| Phần mềm làm khác điều đặc tả ghi rõ | Lỗi | Bên làm sửa trong phạm vi |
| Đặc tả ghi mơ hồ, hai cách hiểu đều hợp lý | Làm rõ đặc tả | Hai bên thống nhất; thường chia theo mức ảnh hưởng |
| Đặc tả không có chức năng đó | Thay đổi, thêm mới | Bên mua, sau khi duyệt ước lượng |
| Đặc tả có nhưng bên mua muốn làm khác | Thay đổi | Bên mua, sau khi duyệt ước lượng |
| Luật hoặc dịch vụ bên thứ ba đổi giữa chừng | Thay đổi do bên ngoài | Thường là bên mua; nên có điều khoản riêng |
Dòng thứ hai là vùng xám thật sự và là lý do tiêu chí nghiệm thu phải viết đo được ngay từ đặc tả. Đặc tả càng rõ, vùng xám càng hẹp.
Năm bước xử lý
- Ghi lại: mỗi yêu cầu một dòng trong danh sách chung, ai đề xuất, ngày nào, mô tả gì.
- Phân loại: lỗi, làm rõ đặc tả hay thay đổi.
- Ước lượng: bên làm báo thời gian, chi phí và ảnh hưởng tới lịch các phần khác.
- Duyệt: người có thẩm quyền phía bên mua duyệt bằng văn bản; không duyệt thì dừng.
- Làm và ghi phụ lục: thay đổi đã duyệt được gộp vào phụ lục hợp đồng, cập nhật đặc tả và lịch.
ALODEV công bố đúng cách này. Trang Quy trình ghi: mỗi yêu cầu mới được ghi lại, ước lượng thời gian và chi phí, doanh nghiệp duyệt rồi mới làm. Điều khoản dịch vụ ghi tính năng mới ngoài phạm vi ban đầu làm bằng phụ lục hợp đồng riêng.
Mẫu phiếu yêu cầu thay đổi
| Trường | Ví dụ |
|---|---|
| Mã | YCTĐ-004 |
| Người đề xuất, ngày | Trưởng phòng kinh doanh, 14/10 |
| Mô tả | Thêm lọc danh sách khách theo tỉnh và xuất tệp theo bộ lọc |
| Lý do | Chia vùng phụ trách cho nhân viên bán hàng từ quý sau |
| Phân loại | Thay đổi, thêm mới (đặc tả mục CN-03 không có lọc theo tỉnh) |
| Ước lượng | 2 ngày công; không ảnh hưởng mốc nghiệm thu chặng 2 |
| Chi phí | Theo đơn giá phụ lục (số trong phiếu thật) |
| Duyệt | Giám đốc, ký ngày 16/10 |
| Ghi vào | Phụ lục bổ sung số 1 |
Ba cách để thay đổi không làm vỡ dự án
Gom thay đổi theo đợt
Duyệt từng thay đổi nhỏ lẻ mỗi ngày làm đội làm liên tục đổi hướng. Gom thay đổi, duyệt ở buổi rà soát cuối đợt, và xếp vào đợt sau.
Cân nhắc đổi chứ không chỉ thêm
Khi một tính năng mới quan trọng hơn một tính năng cũ chưa làm, đổi chỗ hai tính năng có thể không phát sinh tiền. Hỏi bên làm phương án đổi trước khi duyệt thêm.
Hỏi ảnh hưởng tới lịch
Một thay đổi nhỏ về công có thể đẩy lùi mốc nghiệm thu vì phải kiểm lại cả luồng. Chậm vì bên mua đổi phạm vi thì lịch được thống nhất lại, khác với chậm do bên làm. Trang Mô hình hợp tác của ALODEV cũng phân biệt hai trường hợp này.
Ước lượng một thay đổi gồm những gì
Khi nhận ước lượng cho một yêu cầu thay đổi, nhìn vào ba phần. Thứ nhất là công làm phần mới. Thứ hai là công sửa những phần cũ bị ảnh hưởng: thêm một trường dữ liệu có thể kéo theo sửa biểu mẫu, báo cáo, tệp xuất và quyền truy cập. Thứ ba là công kiểm lại: mọi luồng chạm vào phần đã sửa phải được kiểm lại, kể cả những luồng đã nghiệm thu.
Ước lượng chỉ có phần thứ nhất thường thấp một cách đáng ngờ, và phần còn lại sẽ quay lại dưới dạng chậm lịch. Ước lượng tách đủ ba phần giúp bên mua quyết định có nên thay đổi bây giờ hay để sang đợt sau, khi một số phần bị ảnh hưởng chưa được làm.
Thay đổi do luật hoặc bên thứ ba
Có những thay đổi không ai trong hai bên muốn: quy định về hoá đơn điện tử đổi, cổng thanh toán đổi cách kết nối, mức lương tối thiểu vùng tăng. Hợp đồng nên có một điều riêng cho nhóm này: ai theo dõi, bao lâu phải cập nhật, và tính tiền thế nào. Nếu phần mềm có bảo trì định kỳ, thay đổi do luật thường nằm trong gói bảo trì; nếu không, đi theo quy trình yêu cầu thay đổi như mọi thay đổi khác.
Giữ danh sách thay đổi gọn
Sau vài tháng, danh sách yêu cầu thay đổi có thể dài hàng chục dòng. Mỗi dòng nên có trạng thái rõ: mới, đang ước lượng, chờ duyệt, đã duyệt, không duyệt, đã làm. Dòng không duyệt vẫn giữ lại, ghi lý do, vì cùng một ý tưởng thường quay lại sau vài tháng và ai cũng quên lần trước đã quyết thế nào. Cuối mỗi chặng, tổng hợp các thay đổi đã duyệt vào một phụ lục, thay vì ký mỗi thay đổi một phụ lục riêng.
Một quy tắc đơn giản giúp danh sách không phình: mỗi yêu cầu mới phải có người đề xuất nói được nó giải quyết việc gì và ai dùng. Yêu cầu không trả lời được hai câu đó thường là ý thích, nên để sang sau khi phần mềm đã chạy thật một thời gian và người dùng tự thấy cần hay không.
Câu hỏi thường gặp
Change request là gì?
Là yêu cầu thay đổi phạm vi đã chốt: làm thêm, làm khác hoặc bỏ bớt. Mỗi yêu cầu cần ghi lại, ước lượng và duyệt trước khi làm.
Sửa lỗi có bị tính là change request không?
Không, nếu phần mềm làm khác đặc tả đã duyệt. Lỗi thuộc trách nhiệm bên làm trong phạm vi và bảo hành.
Hợp đồng trọn gói có đổi yêu cầu được không?
Được, qua quy trình yêu cầu thay đổi và phụ lục bổ sung. Phần không đổi vẫn giữ giá trọn gói.
Bên làm tự làm thêm rồi tính tiền thì sao?
Nếu hợp đồng quy định phải duyệt trước, phần làm thêm không duyệt không phải trả. Đó là lý do bước duyệt phải bằng văn bản.
Có nên chừa ngân sách dự phòng cho thay đổi?
Nên, vì thay đổi gần như luôn có khi người dùng thật bắt đầu dùng. Khoản dự phòng giúp duyệt thay đổi quan trọng mà không phải xin lại ngân sách.
