Đừng hỏi tại sao sự cố xảy ra, hãy hỏi chúng ta đang thay đổi điều gì

Có một câu hỏi mà hầu hết các đội kỹ thuật đều hỏi sau mỗi sự cố: "Tại sao điều này lại xảy ra?" Nhưng theo tác giả Michael Heap, chính câu hỏi đó lại là lý do khiến sự cố lặp lại. Bài viết dưới đây kể lại một cuộc trò chuyện với SVP kỹ thuật của anh, và rút ra một bài học đáng suy ngẫm cho mọi tổ chức công nghệ.

"Tôi không muốn nghe chi tiết"

Vài tháng trước, tác giả bị kéo vào một cuộc gọi với người đồng cấp bên kỹ thuật và sếp của người đó — tình cờ lại là SVP kỹ thuật của công ty. Một chuyện đã xảy ra mà lẽ ra không nên xảy ra. Không đến mức thảm khốc, nhưng đủ nghiêm trọng để anh phải ngồi vào cuộc gọi với một SVP.

Anh bắt đầu giải thích sự việc thì bị ngắt lời: "Michael, tôi không muốn nghe chi tiết."

Vị SVP nói tiếp:

Tôi biết nếu chúng ta đi vào chi tiết, mọi lý do sẽ đều hoàn toàn hợp lý. Cậu sẽ giải thích chuyện gì đã xảy ra, tôi sẽ hiểu vì sao mọi người đưa ra quyết định như vậy, và tôi sẽ đồng cảm với cậu.

Rồi chuyện đó sẽ lại xảy ra lần nữa.

Nên tôi không muốn nghe chi tiết. Tôi muốn biết chúng ta đang thay đổi điều gì.

Ban đầu, tác giả nghĩ câu "tôi không muốn nghe chi tiết" nghe có vẻ xem nhẹ vấn đề. Làm sao một người có thể ra quyết định sáng suốt mà không hiểu rõ ngọn ngành?

Rồi anh nhận ra: đó không phải là sự xem nhẹ. Vị lãnh đạo ấy mặc định rằng đội ngũ của mình có năng lực, và thực chất đang nói: "Tôi tin các bạn rồi. Giờ hãy nói xem tiếp theo chúng ta làm gì."

Đặt đúng câu hỏi

Sau khi có sự cố, hầu hết tổ chức hỏi: "Tại sao chuyện này lại xảy ra?" Chúng ta đều quen với việc trả lời câu hỏi đó.

Chúng ta viết lại dòng thời gian. Chúng ta tái dựng các quyết định. Chúng ta giải thích các phụ thuộc. Cuối cùng, chúng ta đưa ra một tài liệu chứa đựng tổ hợp sự kiện cụ thể đã dẫn đến sự cố.

Mọi người gật đầu, nói "nghe hợp lý đấy", rồi ai về việc nấy.

Hiểu một vấn đề không giống với việc sửa nó. Một lời giải thích hay có thể còn khiến mọi thứ tệ hơn. Một khi tất cả đều đồng ý rằng hành vi đó là hợp lý, động lực thay đổi bất cứ điều gì cũng biến mất.

Khi một sự cố được xem là chuỗi sự kiện đáng tiếc nhưng dễ hiểu, nơi không ai có lỗi, thì sẽ chẳng có gì thay đổi. Sáu tháng sau, chuyện y hệt lại xảy ra, và mọi người ngơ ngác không hiểu sao mình lại rơi vào tình huống này lần nữa.

Để thúc đẩy thay đổi trong tổ chức, đừng hỏi "tại sao chuyện này xảy ra?"

Thay vào đó, hãy hỏi:

Chúng ta đang thay đổi điều gì để loại lỗi này ít có khả năng lặp lại hơn trong tương lai?

Con người thường hành động hợp lý

Vị SVP không quan tâm đến việc hiểu sự việc đã xảy ra thế nào hay ai liên quan. Ông không cần được thuyết phục rằng tất cả những người liên quan đều hành xử hợp lý. Đó là kỳ vọng mặc định.

Câu hỏi của ông trở thành:

"Với giả định rằng những người hợp lý đã tạo ra kết quả này, thì cần thay đổi điều gì?"

Hãy xem vài ví dụ:

• "Chúng tôi bỏ sót vì Alice đang đi nghỉ và Bob tưởng đội Widgets phụ trách việc đó." — Được thôi. Vậy làm sao để quyền sở hữu trở nên rõ ràng, dứt khoát khi có người vắng mặt?
• "Yêu cầu thay đổi ba ngày trước khi ra mắt." — Tất nhiên rồi! Vậy điều gì sẽ xảy ra khi yêu cầu thay đổi trong khoảng thời gian cận kề ngày ra mắt?
• "Cảnh báo có kêu, nhưng kỹ sư trực đã xử lý hai mươi cảnh báo ít giá trị từ tối hôm đó." — Hợp lý. Vậy làm sao cải thiện tỷ lệ tín hiệu trên nhiễu của hệ thống cảnh báo?

Hãy tập trung vào việc thay đổi hệ thống. Con người thường không phải là thứ cần thay đổi.

Lời giải thích hay không phải là bản sửa lỗi

Nếu bản postmortem của bạn đầy những câu như "chúng ta nên cho bộ phận hỗ trợ tham gia sớm hơn" và "chúng ta cần giao tiếp tốt hơn", hay câu tác giả đặc biệt ghét: "lần sau chúng ta sẽ cẩn thận hơn" — thì bạn đang có một tập hợp những hy vọng được khoác áo tiến bộ.

Nếu hành động khắc phục của bạn phụ thuộc vào việc mọi người còn nhớ một cuộc trò chuyện từ sáu tháng trước, thì bạn không có hành động khắc phục nào cả. Bạn chỉ có truyền thuyết của tổ chức. Nếu tất cả những người liên quan đến sự cố đều rời công ty vào ngày mai, liệu giải pháp có còn hiệu quả? Nếu câu trả lời là không, thì con người có thể đã học được điều gì đó, nhưng hệ thống vẫn được định sẵn là sẽ thất bại.

Để một bản postmortem tạo ra thay đổi lâu dài, hãy hỏi:

Nếu tình huống y hệt xảy ra vào ngày mai, điều gì sẽ khiến kết quả khác đi?

Một quy trình buộc phải đưa ra quyết định tại điểm này đã là một cải tiến. Một hệ thống ngăn chặn được cả loại lỗi này còn mạnh mẽ hơn.

Quy trình vì quy trình

Bạn cũng có thể đi quá xa với ý "hệ thống ngăn chặn được loại lỗi này".

Không phải thất bại nào cũng đáng để tạo ra một quy trình mới. Đó là cách bạn xây dựng những môi trường chẳng ai muốn làm việc trong đó. Đôi khi chi phí ngăn chặn sự lặp lại còn cao hơn chi phí thỉnh thoảng chấp nhận thất bại, và điều đó không sao cả.

Nhưng bạn cần chấp nhận thất bại một cách có ý thức. "Chúng ta chủ động chấp nhận rủi ro này" rất khác với "chúng ta đã nói sẽ cố gắng hơn và ai cũng thấy dễ chịu hơn".

Niềm tin

Tác giả vẫn nghĩ nhiều về điều vị SVP đã nói. Điều nghe như sự thiếu kiên nhẫn thực ra là một tuyên bố về niềm tin. Ông không cần ai chứng minh rằng những người liên quan đều có năng lực và thiện chí. Ông sẵn sàng bắt đầu từ giả định đó. Nếu quá trình điều tra cho thấy điều ngược lại, ta có thể xử lý riêng.

Điều ông không muốn là để sự đồng cảm trở thành cơ chế giúp tổ chức thoát khỏi trách nhiệm phải thay đổi.

Con người thường đưa ra quyết định tốt nhất có thể dựa trên thông tin, động lực và ràng buộc quanh họ. Đó là lý do vì sao "sửa con người" thường là câu trả lời sai.

Đôi khi điều hữu ích nhất mà một người lãnh đạo có thể nói là:

Tôi tin các bạn. Tôi không cần chi tiết. Hãy nói cho tôi biết chúng ta đang thay đổi điều gì.