Vấn đề nhà quản lý cần giải quyết là làm sao lỗi lầm đã gặp không lặp lại nhiều lần, số lỗi hay issue xuất hiện ngày càng ít đi thông qua những kỷ thuật như là Defect Prevention hay với các trường hợp đơn lẻ ta hay dùng RCA (Root Cause Analysis)...
Vậy nên, là người quản lý, ta cần bình tĩnh, xử lý một cách chuyên nghiệp, có cơ sở khoa học, sửa lỗi hệ thống và quan trọng hơn là tránh chỉ trích cá nhân.
Sau đây, mình share mọi người một phương pháp nhằm ngăn ngừa lỗi hay cải tiến nâng cao năng lực cho quy trình sản xuất
Xét trường hợp cụ thể sau (case study):
Sau một số lần chuyển giao sản phẩm (release), khách hàng bắt đầu phàn nàn về chất lượng sản phẩm: tại sao số lỗi (bug hay defect) tìm được trong UAT (User Acceptance Test) nhiều quá!
Trong vai trò là trưởng dự án, bạn làm gì để cải thiện chất lượng?
Bước 1: Xác định vấn đề
Tập hợp tất cả lỗi tìm được bởi khách hàng trong UAT cho những release đã qua. Số bugs trong mỗi release có thể chuẩn hóa thành mật độ lỗi bao gồm tỷ lệ lỗi (major và Minor) / Size của software (FP, SP, SLOC) ta có bảng thống kê sau đây:
Sau đó đưa data lên control chart, xử lý outlier nếu có
Notes:
+ Outlier hay Special Cause of variation thường được xác định bằng các luật như: 1 điểm nằm ngoài control limit (đường màu đỏ) hay 7 điểm dữ liệu liên tục nằm về một phía của central line (đường màu xanh)
+ Khi gặp Outlier: Ta cần tìm nguyên nhân gây ra outlier, và giải pháp để outlier tương tự không xuất hiện
+ Trong Statistical Process Control (SPC): Khi process còn tồn tại outlier thì ta có thể xem process chưa thực sự ổn định (Unstable). Ngược lại process được gọi là ổn định (stable). Nếu Process ổn định và performance đạt mục tiêu kỳ vọng của stakehoilders thì ta gọi process là capable (quy trình tốt)
Bước 2: Tìm ra tất cả nguyên nhân có thể gây ra lỗi
Họp đội dự án, tất cả những người trực tiếp liên quan đến những lỗi đã xẩy ra cùng bàn bạc, sử dụng mô hình xương cá (fishbone diagram) để xác định tất cả các nguyên nhân có thể có mà gây nên những lỗi đó.
Bước 3: Phân tích từng lỗi, tìm nguyên nhân gây ra lỗi đó
Phân tích từng defect (thường ai đã tham gia fix lỗi nào thì phân tích lỗi ấy - trên excel hay dung tracking tool) và tìm ra một hay nhiều nguyên nhân cụ thể nào đã gây ra lỗi đó
Bước 4: Thống kê, vẽ biểu đồ Pareto
Từ kết quả bước 3, ta thống kê xem mỗi nguyên nhân cụ thể đã gây ra bao nhiêu lỗi, và sắp xếp danh sách các nguyên nhân theo tần suất gây lỗi từ lớn đến nhỏ.
Tiếp theo, dùng bảng dữ liệu trên để vẽ Pareto chart (Có thể dung Minitab)
Phân tích vấn đề: (Data Analysis)
Từ đây ta có thể rút ra kết luận quan trọng: 3 nguyên nhân đầu trong Pareto chart nêu trên đã gây ra tới 80% số lỗi khách hàng đã tìm thấy
(cách làm này là rất hữu ích vì ta chỉ cần quan tâm giải quyết 20% nguyên nhân gây ra tới 80% số lỗi - Trong thực thế không thể có đủ thời gian và nguồn lực để giải quyết hết tất cả nguyên nhân gây lỗi)
Bước 5: Đề xuất giải pháp và thực hiện biện pháp ngăn ngừa lỗi
Cùng nhau bàn bạc và đưa ra giải pháp và kế hoạch cụ thể để khắc phục ngay 3 vấn đề đã xác định. Thực hiện bảng kế hoạch (action plan) đã đề ra.
Bước 6: Đánh giá hiệu quả sau cải tiến.
Sau khi hoàn tất bảng kế hoạch (action plan) nêu trên, cho dự án chạy tiếp một thời gian sau đó đo lường và so sánh mật độ lỗi trước và sau cải tiến
Cách 1: Dùng control chart và quan sát bằng mắt thường (Minitab)
Cách 2: Dùng phương pháp thống kê (e.g. T-Test - Minitab).
Nếu P Value <= 0.05 -> Đã có sự thay đổi rõ rệt về thống kê (Significant change) -> Giải pháp hiệu quả -> Chất lượng đã được tang lên đáng kể
Tóm lại:
Defect Prevention là kỹ thuật được áp dụng khá hiệu quả hay được ứng dụng trong dự án nhằm ngăn chặn lỗi (defect prevention), kiểm soát chất lượng cũng như thực hiện cải tiến quy trình hay dây chuyền sản xuất (Process Improvement)
Bên cạnh đó, chúng ta cũng có thể áp dụng kỷ thuật này để giải quyết rât nhiều vấn đề khác, ví dụ: phân tích góp ý từ tất cả nhân viên trong công ty sau một lần làm ESAT (Employee Satisfaction Survey) và đưa ra giải pháp nhằm nâng cao mức độ hài lòng hay mức độ gắn kết của nhân viên…
Hy vọng chia sẻ trên hữu ích với mọi người,
Người viết,
Hoang Sy Quy, PMP, PMI-ACP, Scrum@Scale, Agile Coach, PMP and PMI-ACP Trainer
Chuyên luyện thi PMP, PMI-ACP Interactive Online (Virtual Instructure-Led Training)