Phần mềm không lỗi vẫn có thể thất bại: đo chất lượng bằng kết quả người dùng

Vì sao “không có bug” chưa chứng minh được chất lượng?

Kiểm thử chứng minh phần mềm chạy đúng đặc tả. Kiểm thử không chứng minh đặc tả đó đúng với công việc thật.

Đây là hai việc khác nhau, và khoảng cách giữa chúng là nơi phần lớn dự án thất bại. Ba tình huống lặp đi lặp lại:

• Đúng thuật toán, sai thao tác. Hệ thống tính chính xác, nhưng một nghiệp vụ vốn mất 3 bước nay mất 8 bước. Nhân viên quay lại dùng Excel.
• Đúng đặc tả, sai dữ liệu thật. Đặc tả viết trên dữ liệu mẫu sạch. Dữ liệu thật có trường trống, mã trùng, ký tự đặc biệt — và luồng xử lý vỡ ngay tuần đầu.
• Đúng tính năng, sai mục đích. Khách yêu cầu nút xuất Excel. Mục đích thật là báo cáo gửi hội sở mỗi sáng thứ Hai. Cái nút được làm đúng, việc làm báo cáo vẫn mất cả buổi.

Trong cả ba trường hợp, biên bản nghiệm thu đều sạch. Và cả ba đều là dự án thất bại.

Phần mềm không ai dùng gây thiệt hại thế nào?

Một hệ thống không được sử dụng gây thiệt hại lớn hơn phần chi phí phát triển đã bỏ ra, vì thiệt hại tiếp tục phát sinh mỗi ngày sau đó.

Với hệ thống quản trị nội bộ, thiệt hại nằm ở thời gian. Đây là phép tính bạn có thể tự chạy trên số liệu của mình:

Đây là phép tính minh hoạ, không phải số liệu khảo sát. Hãy thay bằng con số thật của doanh nghiệp bạn — kết quả thường lớn hơn dự đoán ban đầu.

Với ứng dụng phục vụ khách hàng, thiệt hại nằm ở doanh thu bị rò rỉ ở từng bước chuyển trang, từng giây chờ tải. Khác biệt là ở chỗ: thiệt hại này không xuất hiện trên bất kỳ báo cáo nào, nên không ai chịu trách nhiệm về nó.

Với agency và đơn vị tích hợp hệ thống, thiệt hại nằm ở uy tín. Bạn nhận dự án của khách hàng, giao lại cho bên thứ ba, và bàn giao một sản phẩm chạy được nhưng không tạo ra kết quả. Khách hàng không quay lại, và họ cũng không nói lý do.

Đo chất lượng phần mềm bằng chỉ số nào?

Chất lượng phần mềm nên đo bằng bốn chỉ số dùng đồng thời. Dùng một chỉ số duy nhất sẽ bỏ sót đúng loại thất bại nguy hiểm nhất — phần mềm đúng đặc tả nhưng không ai dùng.

Hai chỉ số đầu thuộc về bên phát triển. Hai chỉ số sau chỉ đo được sau khi hệ thống lên production — và đó chính là lý do phần lớn hợp đồng không có chúng.

Một lưu ý kỹ thuật quan trọng: phần ghi log phục vụ đo lường phải được thiết kế trước khi release, không phải bổ sung sau. Thêm log sau go-live nghĩa là mất dữ liệu nền để so sánh, và mọi cải tiến sau đó đều không chứng minh được hiệu quả.

Vì sao doanh nghiệp Việt Nam thường bỏ qua giai đoạn đo sau release?

Nguyên nhân phổ biến nhất là cấu trúc ngân sách, không phải nhận thức.

• Ngân sách dồn hết vào giai đoạn xây dựng. Khi hệ thống lên production, dòng ngân sách đã cạn. Không còn khoản nào cho việc đo và cải tiến.
• Tiêu chí nghiệm thu là danh sách tính năng. Nghiệm thu theo checklist chức năng khiến cả hai bên tập trung vào ngày bàn giao, không phải kết quả sử dụng.
• Không ai được giao trách nhiệm sau go-live. Đội dự án giải tán, đội vận hành nhận hệ thống nhưng không có quyền thay đổi thiết kế.

Ba nguyên nhân này đều xử lý được, nhưng phải xử lý ở giai đoạn ký hợp đồng, không phải sau khi phát hiện vấn đề.

VAON kiểm soát chất lượng bằng cách nào?

VAON dùng ba lớp kiểm soát, mỗi lớp bắt một loại lỗi mà lớp trước không thấy được.

Lớp thứ ba là lớp quyết định. Hai lớp đầu kiểm tra phần mềm so với tài liệu; lớp thứ ba kiểm tra phần mềm so với công việc thật. Đây cũng là lớp mà phần lớn mô hình thuê ngoài bỏ qua, vì nó đòi hỏi người hiểu cả nghiệp vụ lẫn kỹ thuật.

Song song với ba lớp này, VAON theo dõi bốn chỉ số ở phần trên và trình bày trong buổi review định kỳ với khách hàng — kể cả khi số liệu không đẹp. Một chỉ số xấu được phát hiện sớm rẻ hơn nhiều lần so với việc phát hiện muộn.

Bảo hành và cải tiến sau release khác nhau ra sao?

Bảo hành và cải tiến là hai phạm vi khác nhau, và việc không tách bạch chúng là nguyên nhân tranh chấp phổ biến nhất sau bàn giao.

VAON đưa một vòng cải tiến sau release vào phạm vi hợp đồng, với số giờ giới hạn được ghi rõ. Cách này giúp hai bên không phải tranh luận về ranh giới ngay lần đầu phát sinh vấn đề.

Năm câu hỏi nên hỏi nhà cung cấp trước khi ký

Năm câu dưới đây dùng được với bất kỳ nhà cung cấp nào, kể cả VAON. Câu trả lời mơ hồ ở bất kỳ câu nào là một dấu hiệu rủi ro.

1. Tỷ lệ lỗi lọt production thực tế của các dự án gần đây là bao nhiêu?
2. Ai là người viết tiêu chí nghiệm thu — bên bạn hay bên chúng tôi?
3. Cải tiến sau release có nằm trong phạm vi hợp đồng không, và giới hạn bao nhiêu giờ?
4. Khi production gặp sự cố, ai xử lý đầu tiên và trong bao nhiêu phút?
5. Test case được sinh ra từ đâu — từ tiêu chí nghiệm thu hay từ code đã viết?

Câu hỏi số 5 đáng chú ý nhất. Test sinh từ code chỉ xác nhận code đang làm đúng cái nó đang làm, và không phát hiện được sai lệch so với yêu cầu.

Khi nào không cần đo sau release?

Việc đo lường không phải lúc nào cũng đáng chi phí. Có ba trường hợp nên bỏ qua:

• Dự án thử nghiệm ngắn hạn (PoC). Mục tiêu là kiểm chứng khả thi kỹ thuật, không phải kết quả vận hành.
• Hệ thống nội bộ dưới 20 người dùng. Chỉ cần theo dõi tỷ lệ hoàn thành nghiệp vụ và thu phản hồi định tính hàng tháng. Thêm chỉ số chỉ tạo việc giấy tờ.
• Khách hàng không thể cấp quyền truy cập log hoặc tiếp cận người dùng cuối. Không có dữ liệu thì mọi chỉ số đều là ước đoán. Trường hợp này nên thoả thuận lại phạm vi trách nhiệm ngay từ đầu.

Nói rõ giới hạn là một phần của việc đảm bảo chất lượng. Một nhà cung cấp cam kết đo được mọi thứ trong mọi hoàn cảnh là một nhà cung cấp chưa từng làm việc đó.

Bước tiếp theo

Nếu bạn đang vận hành một hệ thống đã bàn giao nhưng chưa rõ nó tạo ra kết quả gì, bước hợp lý là đánh giá hiện trạng trước khi quyết định đầu tư tiếp.

VAON cung cấp một buổi đánh giá hiện trạng: rà soát tiêu chí nghiệm thu đang dùng, xác định các chỉ số có thể đo ngay với dữ liệu sẵn có, và chỉ ra những điểm cần bổ sung log trước khi triển khai giai đoạn tiếp theo. Kết quả là một báo cáo ngắn, không kèm ràng buộc hợp đồng.

Liên hệ: sales@ai.vaon.com.vn · Website: https://vaon.com.vn/vi