Biên bản nghiệm thu phần mềm là văn bản hai bên ký xác nhận phần mềm (hoặc một chặng) đã được kiểm và đạt yêu cầu, kèm danh sách lỗi còn tồn và hạn sửa. Nó thường là căn cứ cho một đợt thanh toán và là mốc bắt đầu tính bảo hành, nên cần ghi đủ chín mục: căn cứ, thành phần, phạm vi, môi trường, kết quả kiểm, lỗi còn tồn, tài liệu kèm theo, kết luận, chữ ký. Biên bản thiếu phạm vi hoặc thiếu danh sách lỗi còn tồn là nguồn tranh cãi phổ biến nhất sau khi ký.
Chín mục của biên bản
| Mục | Ghi gì | Vì sao cần |
|---|---|---|
| 1. Căn cứ | Số hợp đồng, phụ lục phạm vi, phiên bản đặc tả | Xác định đang nghiệm thu theo phạm vi nào |
| 2. Thành phần | Người đại diện hai bên, chức vụ | Người ký có thẩm quyền |
| 3. Phạm vi nghiệm thu | Chặng nào, gồm chức năng nào | Phần chưa nghiệm thu không bị coi là đã xong |
| 4. Môi trường | Địa chỉ hệ thống, phiên bản, dữ liệu thử hay dữ liệu thật | Biết phiên bản nào được xác nhận |
| 5. Kết quả kiểm | Số kịch bản, số đạt, số không đạt | Căn cứ đo được cho kết luận |
| 6. Lỗi còn tồn | Danh sách kèm mức và hạn sửa | Bên làm cam kết sửa, bên mua không mất quyền đòi |
| 7. Tài liệu kèm theo | Kết quả UAT, tài liệu hướng dẫn, danh sách bàn giao | Chứng cứ khi cần đối chiếu |
| 8. Kết luận | Đạt, đạt có điều kiện, hoặc chưa đạt | Căn cứ thanh toán và bảo hành |
| 9. Chữ ký | Hai bên, ngày ký | Ngày ký là mốc tính thời hạn |
Mẫu biên bản điền sẵn
Mẫu dưới đây điền bằng dữ liệu giả để thấy mức chi tiết. Hình thức văn bản (quốc hiệu, số hiệu) theo quy định nội bộ của mỗi doanh nghiệp; nội dung là phần quan trọng.
| Mục | Nội dung mẫu |
|---|---|
| Căn cứ | Hợp đồng số 12/2026/HĐPM; Phụ lục 1 Phạm vi; Đặc tả phiên bản 1.3 |
| Thành phần | Bên A: Giám đốc Công ty Mẫu A. Bên B: Người phụ trách dự án Công ty Mẫu B |
| Phạm vi | Chặng 2: tạo đơn, duyệt đơn, xuất kho (CN-05 đến CN-09) |
| Môi trường | Hệ thống thử, phiên bản 0.9.2, dữ liệu 200 đơn mẫu |
| Kết quả | 24 kịch bản: 22 đạt, 2 không đạt (mức nhẹ) |
| Lỗi còn tồn | L-031 nhãn nút sai chính tả, hạn 7 ngày; L-034 cột ngày lệch định dạng, hạn 7 ngày |
| Tài liệu kèm | Bảng kết quả UAT; hướng dẫn sử dụng chặng 2 |
| Kết luận | Đạt có điều kiện: sửa hai lỗi còn tồn trong hạn |
Danh sách lỗi còn tồn
Danh sách lỗi còn tồn là phụ lục của biên bản, và là phần bên mua cần giữ kỹ nhất. Mỗi lỗi cần một mã, mô tả, mức, hạn sửa, và cột xác nhận đã sửa. Khi bên làm báo đã sửa, bên mua kiểm lại đúng kịch bản cũ rồi đánh dấu.
| Mã | Mô tả | Mức | Hạn sửa | Đã sửa, kiểm lại |
|---|---|---|---|---|
| L-031 | Nút "Gửi duyệt" ghi sai chính tả | Nhẹ | 7 ngày | Chưa |
| L-034 | Cột ngày ở danh sách đơn hiện tháng trước ngày | Nhẹ | 7 ngày | Chưa |
Năm lỗi hay gặp khi lập biên bản
- Ghi "nghiệm thu toàn bộ phần mềm" trong khi mới kiểm một chặng.
- Không ghi phiên bản phần mềm, sau này không biết bản nào đã được xác nhận.
- Lỗi còn tồn chỉ nói miệng, không vào biên bản.
- Người ký không có thẩm quyền theo hợp đồng.
- Không ghi ngày ký rõ ràng, không xác định được mốc bắt đầu bảo hành.
Mốc bắt đầu bảo hành quan trọng hơn người mua thường nghĩ. Với ALODEV, bảo hành theo hợp đồng tính từ ngày nghiệm thu đạt (/dieu-khoan mục 6), nên ngày trên biên bản nghiệm thu cuối là ngày bảo hành bắt đầu.
Nghiệm thu từng chặng và nghiệm thu cuối
Dự án chia chặng sẽ có nhiều biên bản. Biên bản chặng xác nhận phần đã làm trong chặng đó, thường trên môi trường thử. Biên bản cuối xác nhận toàn bộ hệ thống chạy trên dữ liệu thật, dẫn chiếu các biên bản chặng, và gộp mọi lỗi còn tồn chưa đóng. Ở ALODEV, mỗi chặng được nghiệm thu riêng và chặng cuối chỉ nghiệm thu khi hệ thống đã chạy trên dữ liệu thật của doanh nghiệp (trang Quy trình).
Một điểm hay bị bỏ qua: lỗi còn tồn của chặng trước phải được kiểm lại trước khi ký biên bản chặng sau. Nếu không, danh sách lỗi còn tồn cứ dài thêm và tới cuối dự án không ai nhớ lỗi nào đã sửa.
Khi hai bên không thống nhất kết luận
Bên làm cho là đạt, bên mua cho là chưa đạt. Cách gỡ nhanh nhất là quay về kịch bản đã chốt: mỗi dòng không đạt được đối chiếu với câu trong đặc tả. Dòng nào đặc tả ghi rõ mà phần mềm làm khác là lỗi; dòng nào đặc tả không ghi là yêu cầu mới, đi theo phiếu thay đổi. Phần còn lại là vùng xám, hai bên thống nhất bằng văn bản và ghi vào biên bản cùng với kết luận.
Biên bản nghiệm thu là tài liệu kế toán và pháp lý, nên lưu cùng hợp đồng, bản ký có chữ ký hai bên và bản điện tử. Tệp kết quả UAT và danh sách lỗi còn tồn đính kèm nên được đánh số phiên bản để không nhầm với các bản nháp trước đó.
Nếu vùng xám nhiều, đó là dấu hiệu đặc tả ban đầu viết chưa đủ rõ. Ghi lại các dòng đó làm bài học cho chặng sau: bổ sung câu kiểm đo được vào đặc tả trước khi làm tiếp, thay vì để tới buổi nghiệm thu mới tranh luận. Mỗi vùng xám được làm rõ sớm là một cuộc tranh cãi được tránh ở biên bản chặng sau.
Câu hỏi thường gặp
Biên bản nghiệm thu phần mềm gồm những nội dung gì?
Căn cứ hợp đồng, thành phần, phạm vi, môi trường, kết quả kiểm, lỗi còn tồn, tài liệu kèm theo, kết luận và chữ ký hai bên.
Nghiệm thu từng chặng có cần biên bản riêng không?
Nên có, nhất là khi mỗi chặng gắn với một đợt thanh toán. Biên bản chặng cuối dẫn chiếu các biên bản trước.
Ký biên bản rồi phát hiện lỗi thì sao?
Lỗi phát sinh từ mã đã bàn giao thường thuộc bảo hành. Vì vậy biên bản cần ghi ngày ký để xác định thời hạn bảo hành.
Biên bản nghiệm thu và biên bản bàn giao khác nhau thế nào?
Nghiệm thu xác nhận phần mềm đạt yêu cầu; bàn giao xác nhận đã nhận mã nguồn, tài liệu, tài khoản. Có thể gộp một văn bản nếu làm cùng ngày.
Bên mua không ký nghiệm thu mãi thì sao?
Hợp đồng nên có thời hạn phản hồi nghiệm thu và cách xử lý khi quá hạn. Điều khoản của ALODEV ghi thời hạn phản hồi thường là 3 đến 5 ngày làm việc.
