Solution Evaluation

Hệ thống lên production, mọi người ăn mừng, team chuyển sang dự án tiếp theo. Sáu tháng sau, hỏi tháng vừa rồi có bao nhiêu người bấm vào tính năng đó thì cả phòng nhìn nhau. Vùng knowledge area này tồn tại để chặn đúng kịch bản đó, và nó cũng là vùng bị bỏ qua nhiều nhất trong thực tế.

UAT hỏi người dùng có làm được việc thật bằng hệ thống này không. Solution Evaluation hỏi hệ thống có làm doanh nghiệp khá hơn không. Hai câu hỏi khác nhau, và câu thứ hai thường bị bỏ lửng.

Năm task

1. Measure Solution Performance — chọn chỉ số và đo.
2. Analyze Performance Measures — đọc số liệu, tìm nguyên nhân chênh lệch so với kỳ vọng. Phần lớn công sức của cả vùng nằm ở đây, vì số liệu hiếm khi tự nói ra lý do.
3. Assess Solution Limitations — hạn chế nằm bên trong giải pháp.
4. Assess Enterprise Limitations — hạn chế nằm ở tổ chức, quy trình, chính sách hoặc con người xung quanh giải pháp.
5. Recommend Actions to Increase Solution Value — đề xuất cải tiến, mở rộng, hoặc dừng hẳn.

Việc tách task 3 khỏi task 4 là chỗ đáng để ý. Rất nhiều lần phần mềm chạy hoàn hảo mà giá trị vẫn không xuất hiện, vì thứ chặn đường nằm ngoài phần mềm.

So sánh với các bước dễ nhầm

Vùng này còn diễn ra trước khi triển khai. BABOK nói rõ bạn có thể đánh giá cả prototype hoặc một giải pháp đang chạy từ trước mà chưa ai đụng tới.

Ví dụ thực tế

Tờ trình hứa giảm 40% cuộc gọi về tổng đài hỗ trợ đại lý. Đo lại ở ngày thứ 90 sau khi cổng tự phục vụ lên production: giảm được 8%. Hệ thống chạy ổn định, không bug nghiêm trọng, UAT đã pass sạch.

Đào tiếp thì ra hai chuyện. Hạn chế của giải pháp: cổng chỉ hỗ trợ ba nghiệp vụ, trong khi 57% cuộc gọi là để tra cứu hoa hồng, mà tra cứu hoa hồng bị đẩy sang đợt hai. Hạn chế của tổ chức thì buồn cười hơn: đại lý phải đổi mật khẩu mỗi 30 ngày theo chính sách bảo mật, quên mật khẩu thì phải gọi tổng đài, và đúng loại cuộc gọi này lại tăng thêm.

Khuyến nghị cuối cùng gồm ba việc. Việc tốn ít công nhất là nới chính sách mật khẩu kèm cơ chế tự đặt lại qua OTP, không cần viết thêm dòng code nghiệp vụ nào.

Vì sao ở Việt Nam ít ai làm

Vài lý do rất thật: hợp đồng outsourcing kết thúc ở mốc nghiệm thu nên không ai trả tiền cho việc đo sau đó; team bị đẩy sang dự án mới ngay tuần sau; và quan trọng nhất, không ai muốn công bố một con số cho thấy dự án vừa làm không hiệu quả như đã hứa.

Nếu bạn làm ở công ty product thì lý do cuối cùng đó không đứng vững được lâu, vì tiền là tiền của chính công ty.

Bắt đầu ở mức tối thiểu

Không cần cả một chương trình đo lường. Làm ba việc này thôi:

• Trước khi build, viết ra một câu: sau ba tháng chúng ta kỳ vọng chỉ số nào thay đổi từ bao nhiêu lên bao nhiêu.
• Chốt luôn cách lấy số đó: từ log hệ thống, từ báo cáo vận hành, hay từ khảo sát.
• Đặt một lời nhắc trong lịch ở mốc 90 ngày sau go-live để mở số ra xem.

Một dòng kỳ vọng viết ra trước lúc bắt đầu là thứ khiến con số về sau có nghĩa. Viết sau thì bạn chỉ đang giải thích cho một kết quả đã lỡ xảy ra.