Câu trả lời được chấp nhận
Hai công cụ bổ sung cho nhau: xương cá để mở rộng các nguyên nhân khả dĩ, 5 Why để đào sâu từng nhánh đáng ngờ nhất.
Bước 1 — Mô tả vấn đề cụ thể, có số liệu "3/40 cửa hàng lỗi cấu hình máy in hoá đơn sau bản cập nhật 2.3 và 2.4" tốt hơn nhiều so với "cập nhật hay lỗi".
Bước 2 — Biểu đồ xương cá (Ishikawa) Đặt vấn đề ở "đầu cá", vẽ các nhánh nhóm nguyên nhân. Với dự án phần mềm có thể dùng: Con người, Quy trình, Công cụ, Dữ liệu/Cấu hình, Môi trường, Đo lường. Cả đội brainstorm nguyên nhân vào từng nhánh — chưa đánh giá, chưa loại.
Bước 3 — Chọn nhánh nghi vấn bằng dữ liệu Kiểm tra: các cửa hàng lỗi có điểm gì chung? (cùng model máy in, cùng người cài đặt, cùng phiên bản hệ điều hành...). Dữ liệu chỉ ra nhánh nào thì đào nhánh đó.
Bước 4 — 5 Why trên nhánh đã chọn
- Vì sao máy in lỗi? → File cấu hình bị ghi đè về mặc định.
- Vì sao bị ghi đè? → Bộ cài đặt luôn chép file cấu hình mẫu.
- Vì sao bộ cài chép file mẫu? → Không phân biệt cài mới và cập nhật.
- Vì sao không phân biệt? → Kịch bản cài đặt không có test cho trường hợp cập nhật.
- Vì sao không có test đó? → Danh sách kiểm thử phát hành chỉ có kịch bản cài mới.
→ Nguyên nhân gốc thuộc quy trình, hành động khắc phục: bổ sung kịch bản cập nhật vào kiểm thử phát hành, sửa bộ cài. "5" chỉ là con số gợi ý, dừng khi tới nguyên nhân mà đội có thể hành động để ngăn tái diễn.
Tránh đổ lỗi:
- Hỏi "vì sao quy trình cho phép điều này xảy ra", không hỏi "ai làm sai".
- Nếu chuỗi Why dừng ở "do bạn A bất cẩn" thì hỏi tiếp: vì sao hệ thống phụ thuộc vào việc một người không bao giờ bất cẩn?
- Thống nhất từ đầu: buổi họp nhằm cải tiến, không dùng kết quả để đánh giá cá nhân (tinh thần blameless postmortem).
Bước 5 — Kiểm chứng: sau lần cập nhật tiếp theo, đo lại tỉ lệ lỗi. Nếu không giảm, nguyên nhân gốc chưa đúng.
Nguồn: