Phương pháp 5 Whys: Hỏi Tại sao như một đứa trẻ
Khi server sập, đừng chỉ khởi động lại rồi nghĩ đã xong việc. Hãy hỏi Tại sao 5 lần để tìm ra nguyên nhân gốc rễ Root Cause thay vì chỉ chữa triệu chứng.
Chữa cháy vs Chống cháy
Là PM, chúng ta thường xuyên đóng vai Lính cứu hỏa và đưa ra quyết định để cứu hoả.
Bug xuất hiện -> Fix bug.
Khách hàng kêu -> Xoa dịu.
Doanh số giảm -> Chạy khuyến mãi.
Chúng ta rất giỏi Chữa cháy, nhưng rất tệ trong việc tìm ra nguồn lửa ban đầu. Kết quả là tuần sau đám cháy lại bùng lên chỗ cũ hoặc chỗ khác nhưng do vẫn đề cũ.
Sakichi Toyoda (nhà sáng lập Toyota) đã tặng cho thế giới một công cụ đơn giản đến ngớ ngẩn nhưng cực kỳ hiệu quả: 5 Whys.
Ví dụ: Tại sao trễ Deadline?
Vấn đề: Tính năng A bị chậm tiến độ 1 tuần.
Tại sao? Vì Dev ước lượng sai thời gian. Kết luận vội: Mắng Dev “Lần sau estimate cho chuẩn vào!” -> Sai lầm. Hãy hỏi tiếp.
Tại sao ước lượng sai? Vì khi bắt tay vào làm mới phát hiện thư viện bên thứ 3 bị lỗi.
Tại sao không phát hiện lỗi này sớm hơn? Vì lúc estimate chỉ nhìn qua loa, không làm nghiên cứu kỹ thuật trước.
Tại sao không làm Tech Spike? Vì PM là bạn đấy! ép deadline gấp quá, không cho Dev thời gian nghiên cứu.
Tại sao ép deadline? Vì team Sales đã lỡ hứa với khách hàng ngày ra mắt mà không hỏi team Product.
Nguyên nhân Root Cause: Quy trình hứa hẹn của Sales và Product không đồng bộ. Giải pháp: Thiết lập quy tắc “Sales không được bán những gì chưa có trong Roadmap”.
Nếu bạn dừng ở câu 1, bạn đổ lỗi cho Dev. Nếu bạn đi đến câu 5, bạn sửa được cả hệ thống.
Lưu ý khi dùng 5 Whys
Không đổ lỗi con người: Mục tiêu là tìm lỗi ở Quy trình Process, không phải tìm người để mắng.
Dựa trên thực tế: Đừng đoán. Câu trả lời phải dựa trên sự thật đã xảy ra.
Không cứng nhắc: Có thể là 3 Whys, có thể là 7 Whys. Hỏi đến khi nào tìm ra cái gốc rễ thì thôi.
Hãy tập thói quen trở thành “đứa trẻ tò mò” trong mọi cuộc họp Post-Mortem.
T.D