Kiểm soát chất lượng sản phẩm bàn giao và xác định điều kiện nghiệm thu ở cấp quản trị.

Điều kiện nghiệm thu phải có trước lúc sản phẩm hoàn thành

Một yêu cầu như hệ thống dễ sử dụng hoặc có hiệu năng tốt chưa đủ để kiểm tra. Cần mô tả nhiệm vụ người dùng phải hoàn thành, điều kiện dữ liệu, khối lượng và kết quả mong đợi. Điều kiện chấp nhận cần được chủ nghiệp vụ, kỹ thuật và vận hành thống nhất theo phạm vi của họ. Không nên để nhà thầu tự xác định toàn bộ tiêu chí sau khi đã biết sản phẩm làm được gì.

Tiêu chí phải bao phủ cả giao dịch thông thường và trường hợp có tác động lớn. Một luồng hiếm gặp vẫn có thể quan trọng nếu liên quan thanh toán, phân quyền hoặc đối soát. Mức kiểm tra cần tương xứng rủi ro và có cơ sở. Không cần thử mọi tổ hợp vô hạn, nhưng phải biết phạm vi bằng chứng đại diện đến đâu và giới hạn còn lại là gì.

Năng lực quản lý dự án CNTT giúp đưa tiêu chí vào kế hoạch kiểm thử và bàn giao. Khi yêu cầu thay đổi, tiêu chí cần cập nhật có kiểm soát. Nếu vẫn nghiệm thu theo phạm vi cũ, người ký có thể xác nhận điều chưa được triển khai hoặc bỏ sót điều mới đã trở thành thiết yếu.

Phân biệt đáp ứng yêu cầu với đáp ứng nhu cầu sử dụng

Một sản phẩm có thể đúng đặc tả nhưng chưa giúp người dùng hoàn thành công việc. NASA Systems Engineering Handbook phân biệt verification — kiểm tra sản phẩm phù hợp yêu cầu — với validation — xác nhận phù hợp nhu cầu và bối cảnh sử dụng. Doanh nghiệp có thể tham khảo sự phân biệt này khi thiết kế kiểm tra, không cần áp toàn bộ quy trình của một chương trình kỹ thuật hàng không vũ trụ.

Trong dự án IT, kiểm thử chức năng cần được nối với kịch bản nghiệp vụ đầu cuối. Người dùng phải có dữ liệu và quyền phù hợp; các hệ thống liên quan cần cùng hoạt động. Một màn hình trả kết quả đúng chưa chứng minh báo cáo đối soát đúng hoặc giao dịch lỗi được phục hồi. Nếu chỉ kiểm tra từng phần, khoảng giao giữa các phần sẽ khó được xác nhận.

APM trình bày chất lượng gắn với sự phù hợp mục đích và yêu cầu. Từ góc nhìn quản trị, cần xác định bằng chứng cho từng lớp: chức năng, dữ liệu, tích hợp, an toàn và tiếp nhận. Bảng dưới đây là công cụ chuẩn bị hồ sơ nghiệm thu, cần điều chỉnh theo sản phẩm thực tế.

Bảng giúp nhìn chỗ thiếu bằng chứng, không biến nghiệm thu thành thu thập chữ ký từ mọi phòng ban. Người xác nhận cần đủ chuyên môn và quyền trong phạm vi được giao. Khi các lớp đã rõ, cần kiểm tra chất lượng của bằng chứng thay vì chỉ kiểm tra hồ sơ đã có hay chưa.

Bằng chứng phải phản ánh đúng phạm vi sẽ đưa vào sử dụng

Kết quả kiểm thử cần có phiên bản sản phẩm, môi trường, dữ liệu, tình huống và người thực hiện. Nếu sản phẩm được sửa sau kiểm thử, phải đánh giá phần cần kiểm tra lại. Một lỗi đã được nhà thầu báo sửa chưa đồng nghĩa kết quả đã được xác nhận. Hồ sơ cần giữ mối liên hệ giữa lỗi, thay đổi và bằng chứng kiểm thử lại.

Môi trường thử có thể khác vận hành; khác biệt phải được ghi và đánh giá. Tải thấp, dữ liệu nhỏ hoặc kết nối giả lập có thể đủ cho một số câu hỏi nhưng chưa đủ cho mọi kết luận. Người phê duyệt cần biết điều đã kiểm chứng và giả định phải theo dõi sau triển khai. Không nên dùng một tỷ lệ kiểm thử hoàn thành chung để che những luồng trọng yếu chưa được thử.

Năng lực quản lý bảo mật thông tin hỗ trợ phần đánh giá truy cập và dữ liệu. Phạm vi kiểm tra chuyên môn cần được người có trách nhiệm xác nhận. Không được tự suy ra rằng không tìm thấy lỗi đồng nghĩa không còn rủi ro, nhất là khi những phần quan trọng chưa nằm trong phạm vi đánh giá.

Nghiệm thu sản phẩm và cho phép vận hành là hai quyết định cần làm rõ

Doanh nghiệp có thể xác nhận sản phẩm đáp ứng một phạm vi bàn giao, nhưng chưa cho phép triển khai rộng khi điều kiện vận hành còn thiếu. Hai quyết định có thể được tổ chức cùng mốc, song quyền hạn và bằng chứng không nên bị trộn. Người nghiệm thu chức năng chưa chắc được phép chấp nhận gián đoạn hoặc rủi ro dữ liệu của toàn tổ chức.

Hồ sơ go-live cần xem nguồn lực hỗ trợ, hướng dẫn, giám sát, chuyển dữ liệu và phương án phục hồi. Với mỗi phần, phải biết đã sẵn sàng hay chỉ đang có kế hoạch. Đội tiếp nhận cần thực hành những nhiệm vụ quan trọng, thay vì chỉ tham dự buổi đào tạo. Khả năng tự xử lý một tình huống là bằng chứng rõ hơn số giờ đã được hướng dẫn.

Năng lực quản lý dịch vụ IT giúp nối điều kiện dự án với trách nhiệm vận hành. Nếu một số điều kiện chưa đạt, có thể cân nhắc triển khai giới hạn, xử lý thêm hoặc đổi mốc. Mỗi lựa chọn phải có tác động và người chốt, không mặc định giữ ngày bàn giao là yêu cầu cao nhất.

Tình huống ở mở bài cần được xử lý bằng cách tách những gì buổi trình diễn đã chứng minh khỏi những gì chưa được kiểm tra. Nếu ngoại lệ có thể ảnh hưởng đối soát hoặc phục hồi, cần bằng chứng trước quyết định liên quan. Những điều kiện hợp đồng phải được bộ phận có thẩm quyền xác nhận, không suy diễn chỉ từ áp lực tiến độ của nhà thầu.

Tồn đọng được chấp nhận phải có giới hạn và người tiếp nhận

Một số tồn đọng có thể không ngăn sử dụng, nhưng cần được đánh giá theo tác động và biện pháp kiểm soát. Hồ sơ nên ghi người chịu trách nhiệm sửa, người chịu tác động, thời hạn và cách xác nhận hoàn tất. Không nên ghi chung rằng lỗi nhỏ sẽ xử lý sau. Một lỗi ít nghiêm trọng về kỹ thuật vẫn có thể làm tăng nhiều thao tác nghiệp vụ.

Nếu dùng biện pháp thủ công, phải xác nhận khối lượng có thể xử lý và cách đối soát. Khi số giao dịch tăng hoặc nguồn lực giảm, biện pháp từng phù hợp có thể không còn đủ. Quyết định chấp nhận cần có điều kiện xem lại. Người vận hành phải biết khi nào trình cấp cao hơn nếu tồn đọng chưa được xử lý hoặc tác động vượt mức đã thống nhất.

Không được giảm tiêu chí chỉ để biến kết quả thành đạt mà thiếu quyết định thay đổi. Nếu nhu cầu đã thay đổi, có thể cập nhật điều kiện chấp nhận theo quyền hạn và bằng chứng. Nhưng việc viết lại tiêu chí sau khi sản phẩm không đáp ứng cần được giải thích minh bạch. Năng lực quản trị dự án IT giữ trách nhiệm này xuyên suốt quá trình bàn giao.

Hồ sơ chất lượng phải giúp tổ chức sử dụng và cải tiến

Sau bàn giao, cần giữ phiên bản đã chấp nhận, phạm vi kiểm tra, tồn đọng và bằng chứng liên quan. Những phần còn mở phải được chuyển vào cơ chế quản lý vận hành hoặc công việc tiếp theo với người nhận rõ. Đóng dự án không tự đóng các vấn đề chất lượng. Cũng cần xem phản hồi sử dụng có cho thấy yêu cầu hoặc thử nghiệm ban đầu đã bỏ sót điều quan trọng không.

Rà soát sau triển khai nên tập trung vào lỗi có tác động, thời gian can thiệp và cách người dùng thực hiện công việc. Một hệ thống ít sự cố nhưng phải xử lý ngoài quy trình thường xuyên có thể chưa đạt mục đích. Bài học cần được chuyển thành tiêu chí và kịch bản cho dự án sau, thay vì chỉ ghi trong báo cáo tổng kết mà không có người áp dụng.

Đội vận hành cũng cần biết bằng chứng kiểm tra nằm ở đâu và phản ánh phiên bản nào. Nếu một bản sửa được đưa vào sau nghiệm thu, phải đánh giá phạm vi kiểm tra lại theo phần có thể bị ảnh hưởng. Việc giữ đường liên kết giữa yêu cầu, phiên bản và kết quả giúp xử lý sự cố sau này có cơ sở, đồng thời tránh dùng một biên bản cũ để xác nhận chất lượng của sản phẩm đã thay đổi.

Bước đầu là chọn một sản phẩm sắp nghiệm thu, đối chiếu yêu cầu với bằng chứng và xác định phần chưa đủ điều kiện. Sau đó làm rõ quyền chấp nhận sản phẩm, quyền cho phép vận hành cùng trách nhiệm tồn đọng. Khi các quyết định này có cơ sở, chữ ký nghiệm thu sẽ phản ánh năng lực doanh nghiệp thực sự có thể tiếp nhận, thay vì chỉ kết thúc một mốc trên hợp đồng.

Bài viết liên quan

• Rủi ro dự án nào đáng báo cáo Ban điều hành? Nhìn từ tác động kinh doanh
• Lãnh đạo dự án theo mô hình Agile, Waterfall và Hybrid: Lựa chọn phương pháp theo đặc điểm dự án.
• Tiến độ, ngân sách và chất lượng cùng bị đe dọa: Ra quyết định trong khủng hoảng
• Dự án đã bàn giao nhưng lợi ích chưa đến: Ai tiếp tục chịu trách nhiệm?

Nguồn tham khảo

1. APM — What is quality management and control?
2. NASA — Distinctions between Product Verification and Product Validation
3. UK Government — Government Functional Standard GovS 002: Project Delivery