Bàn giao phần mềm: checklist để nghiệm thu, không chỉ nhận sản phẩm

UDT Insights

Từ kho tri thức UDT: tài liệu nguồn tạo năm 2023, cập nhật tháng 8/2026. Bài biên tập mới.

Demo chưa phải toàn bộ việc bàn giao

Đơn vị phát triển trình diễn tính năng. Giao diện trông đúng, nhưng đội tiếp nhận vẫn chưa trả lời được những câu hỏi cơ bản. Đã kiểm tra phiên bản nào? Còn thiếu gì? Ai xử lý khi phát sinh vấn đề sau phát hành?

Hãy xem bàn giao là một chuỗi quyết định có bằng chứng. Dùng checklist này để thống nhất trách nhiệm với đối tác phát triển. Điều chỉnh theo sản phẩm và cách phối hợp của hai bên.

Tách ba quyết định khác nhau

Hoàn thành mã nguồn nghĩa là phần triển khai sẵn sàng cho bước kiểm tra tiếp theo. Nghiệm thu xác nhận hành vi được bàn giao đạt tiêu chí đã thống nhất. Bàn giao vận hành xác nhận đội tiếp nhận biết cách sử dụng, hỗ trợ và bảo trì phiên bản đã nghiệm thu.

Ba quyết định có thể diễn ra vào những thời điểm khác nhau. Demo không thay thế nghiệm thu. Nghiệm thu cũng không tự động cho phép đưa phần mềm lên môi trường chính thức.

Scrum Guide mô tả Definition of Done là chuẩn chất lượng của Increment.[1] Cần phân biệt chuẩn chất lượng chung với tiêu chí nghiệm thu riêng của từng tính năng. Cả hai đều không thay thế việc thống nhất ai có quyền nghiệm thu.

Chuẩn bị bộ hồ sơ nghiệm thu gọn, đủ dùng

Đặt hồ sơ gần bản ghi phát hành. Dẫn tới bằng chứng thay vì sao chép toàn bộ báo cáo vào nhiều nơi.

• Phạm vi và tiêu chí: nêu hành vi được bàn giao, phần không bao gồm và điều kiện nghiệm thu có thể quan sát.
• Phiên bản và bằng chứng: xác định bản build, môi trường kiểm tra, kết quả kiểm thử và lỗi chưa xử lý.
• Rà soát và quyết định: xác định vai trò nghiệm thu, ghi quyết định và giải thích từng tiêu chí chưa đạt.
• Giới hạn và hướng dẫn: cung cấp ghi chú phát hành, giới hạn đã biết và hướng dẫn cho người dùng.
• Sẵn sàng vận hành: thống nhất kiểm tra triển khai, phương án khôi phục và rà soát thay đổi dữ liệu khi cần.
• Trách nhiệm: xác định người tiếp nhận, kênh hỗ trợ, việc còn mở và lần rà soát tiếp theo.

Ví dụ giả định: biểu mẫu đặt phòng

Đây là ví dụ giả định, không phải dự án khách hàng UDT. Một nhóm bàn giao biểu mẫu đặt phòng họp cho văn phòng.

Trước khi kiểm tra, hai bên thống nhất người dùng đặt được phòng còn trống và nhận thông báo rõ khi trùng lịch. Hồ sơ nghiệm thu xác định đúng bản build, kèm bằng chứng cho cả hai tình huống.

Người rà soát phát hiện màn hình trắng khi đặt trùng lịch. Nhóm ghi nhận tiêu chí chưa đạt và giao người sửa. Việc demo thành công tình huống phòng trống không xóa được phát hiện này.

Sau khi sửa, người rà soát kiểm tra bản build mới rồi ghi quyết định. Người tiếp nhận kiểm tra thêm hướng dẫn sử dụng và kênh hỗ trợ. Phát hành lên môi trường chính thức vẫn cần quyết định cho phép riêng.

Luồng bàn giao bốn bước

Dùng trình tự này để thấy rõ quyết định tiếp theo.

• Thống nhất: xác định phạm vi, tiêu chí nghiệm thu và vai trò tiếp nhận.
• Kiểm tra: rà soát đúng phiên bản cùng bằng chứng tương ứng.
• Quyết định: ghi nghiệm thu hoặc yêu cầu sửa, kèm người chịu trách nhiệm.
• Chuyển giao: xác nhận hướng dẫn, trách nhiệm phát hành và việc cần theo dõi.

Đừng dùng chữ ký để che phần chưa rõ

Biên bản nghiệm thu cần nói rõ người kiểm tra đã kiểm tra gì. Nếu còn giới hạn, hãy ghi tác động và cách xử lý đã thống nhất. Không biến vấn đề còn mở thành kết luận đạt vô điều kiện.

Cập nhật hồ sơ khi có thay đổi. Hành vi mới cần tiêu chí và bằng chứng mới, không dùng lại phê duyệt cũ. Hãy bắt đầu với một đợt phát hành. Kiểm tra xem người khác có hiểu quyết định mà không cần giải thích riêng hay không.