Đừng vội sửa con người khi vấn đề nằm ở hệ thống

Có một kiểu vấn đề tôi gặp đi gặp lại trong công việc và cuộc sống.

Một việc bị quên. Một con số nhập sai. Một báo cáo trễ. Một quy trình ai cũng biết là quan trọng nhưng cứ đến lúc làm lại thiếu bước. Một người nhắc mình rằng lần sau sẽ cẩn thận hơn, rồi vài tuần sau lỗi tương tự xuất hiện trở lại.

Phản xạ rất tự nhiên là nhìn vào con người.

Thiếu tập trung. Thiếu trách nhiệm. Chưa đủ kỷ luật. Cần cố gắng hơn.

Có lúc đúng là như vậy.

Nhưng càng làm những công việc có nhiều dữ liệu, nhiều bước và nhiều người phối hợp, tôi càng thấy một khả năng khác: thứ trông giống vấn đề của con người đôi khi thực ra là vấn đề của môi trường và hệ thống.

Nếu một người mắc lỗi một lần, có thể đó là lỗi cá nhân.

Nếu nhiều người cùng mắc một lỗi, hoặc một người cứ lặp lại cùng một lỗi trong cùng một quy trình, tôi nghĩ hệ thống nên được đưa vào diện nghi vấn.

Đây là một thay đổi nhỏ trong cách đặt câu hỏi, nhưng nó làm tôi nhìn việc khác hẳn.

Thay vì chỉ hỏi:

“Ai làm sai?”

Tôi muốn hỏi thêm:

“Điều gì trong cách chúng ta đang làm khiến lỗi này dễ xảy ra đến vậy?”

Chúng ta rất dễ biến một vấn đề vận hành thành một phán xét về con người

Giả sử một báo cáo tuần thường xuyên thiếu một chỉ số.

Cách xử lý nhanh nhất là nhắc người làm báo cáo: “Lần sau nhớ kiểm tra kỹ.”

Nhắc như vậy không sai. Nhưng nếu chỉ dừng ở đó, toàn bộ cơ chế phòng lỗi vẫn nằm trong trí nhớ của một người.

Tuần sau người đó bận hơn một chút, đổi ngữ cảnh nhiều hơn một chút, hoặc dữ liệu đến trễ hơn bình thường, lỗi có thể quay lại.

Một cách tiếp cận khác là hỏi:

• Báo cáo đã có mẫu cố định chưa?
• Các trường bắt buộc có được kiểm tra tự động không?
• Có bước cảnh báo khi dữ liệu trống không?
• Tên cột, nguồn dữ liệu và cách tính đã được chuẩn hóa chưa?
• Người làm có phải nhớ quá nhiều thứ trong đầu không?

Khi hỏi như vậy, vấn đề không còn là “hãy cẩn thận hơn”, mà chuyển thành “hãy làm cho quy trình khó sai hơn”.

Tôi thích cách thứ hai hơn.

Không phải vì nó xóa trách nhiệm cá nhân, mà vì nó biến một bài học thành một thay đổi có thể giữ lại lâu dài.

Một lời nhắc chỉ tồn tại trong trí nhớ.

Một hệ thống tốt có thể tồn tại kể cả khi người vận hành đổi, tâm trạng đổi hoặc khối lượng công việc tăng lên.

Con người không được thiết kế để nhớ mọi thứ

Có một thời gian tôi từng nghĩ người làm việc tốt là người nhớ được nhiều.

Nhớ deadline. Nhớ bước tiếp theo. Nhớ kiểm tra file. Nhớ đặt đúng tên. Nhớ cập nhật trạng thái. Nhớ ai đang chờ mình. Nhớ cả những ngoại lệ chỉ xuất hiện vài tuần một lần.

Nhưng càng về sau tôi càng thấy: dùng trí nhớ để vận hành một hệ thống phức tạp là một thiết kế khá đắt đỏ.

Trí nhớ nên dành cho việc hiểu bối cảnh, tạo liên kết và phán đoán.

Những thứ có thể đưa vào checklist, template, rule, cảnh báo hoặc tự động hóa thì nên cố gắng đưa ra khỏi đầu.

Ví dụ rất đơn giản:

Nếu một file luôn phải được đặt tên theo cùng một cấu trúc, đừng chỉ viết hướng dẫn “nhớ đặt tên đúng”. Nếu có thể, hãy tạo sẵn mẫu tên.

Nếu một biểu mẫu bắt buộc phải có năm trường dữ liệu, đừng đợi người dùng tự nhớ. Hãy làm cho trường thiếu trở thành thứ không thể bỏ qua.

Nếu một quy trình luôn cần kiểm tra dữ liệu trước khi xuất bản, đừng coi bước kiểm tra là một hành động tùy hứng. Hãy biến nó thành một cổng bắt buộc.

Mỗi lần làm được như vậy, chúng ta đang chuyển một phần gánh nặng từ ý chí sang thiết kế.

Và đó thường là một cuộc trao đổi có lợi.

Root Idea: Trước khi yêu cầu con người cố gắng hơn, hãy kiểm tra xem hệ thống có đang khiến hành vi đúng trở nên khó và hành vi sai trở nên quá dễ hay không.

Một hệ thống tốt không cần người dùng lúc nào cũng ở trạng thái tốt nhất

Có một tiêu chuẩn tôi thấy khá hữu ích khi nhìn vào quy trình:

Nếu hệ thống chỉ chạy đúng khi mọi người đều tập trung, tỉnh táo, nhớ đủ và không bị gián đoạn, đó chưa hẳn là một hệ thống tốt.

Con người có ngày khỏe, ngày mệt.

Có lúc làm một việc duy nhất, có lúc phải chuyển qua nhiều việc liên tục.

Có tuần dữ liệu sạch, có tuần nguồn dữ liệu gặp lỗi.

Có lúc người quen việc xử lý, có lúc người mới tiếp quản.

Một quy trình bền vững nên tính đến những biến động đó.

Nó không cần loại bỏ hoàn toàn sai sót — điều đó gần như không thực tế — nhưng nó nên làm ba việc:

1. Giảm xác suất lỗi xảy ra.
2. Phát hiện lỗi càng sớm càng tốt.
3. Giảm hậu quả nếu lỗi vẫn xảy ra.

Tôi thấy ba lớp này hữu ích hơn rất nhiều so với một câu chung chung kiểu “mọi người chú ý hơn nhé”.

Ví dụ, nếu nhập sai một giá trị quan trọng:

• lớp một là giới hạn kiểu dữ liệu hoặc khoảng giá trị hợp lệ;
• lớp hai là cảnh báo bất thường;
• lớp ba là có lịch sử thay đổi để quay lại trạng thái trước.

Khi đó con người vẫn chịu trách nhiệm, nhưng không phải chiến đấu một mình với lỗi.

Trước khi sửa con người, tôi muốn nhìn qua ba lớp

Tôi thường thử tách một vấn đề thành ba lớp đơn giản.

1. Con người

Người thực hiện có đủ kiến thức không?

Họ có hiểu mục tiêu và tiêu chuẩn của đầu ra không?

Họ có đủ thời gian, quyền hạn và thông tin để làm đúng không?

Nếu chưa, vấn đề có thể thật sự nằm ở năng lực, đào tạo hoặc trách nhiệm.

2. Quy trình

Các bước có rõ không?

Điểm bàn giao giữa người này với người khác có mơ hồ không?

Có quá nhiều ngoại lệ phải nhớ không?

Có bước nào tồn tại chỉ vì “trước giờ vẫn làm vậy” nhưng không còn tạo giá trị không?

Nhiều vấn đề được gọi là “thiếu phối hợp” thực ra bắt đầu từ một quy trình không nói rõ ai làm gì, khi nào xong và đầu ra đạt chuẩn là gì.

3. Môi trường và công cụ

Công cụ có giúp hành vi đúng trở nên dễ hơn không?

Hay ngược lại, giao diện, dữ liệu, quyền truy cập và cách tổ chức đang đẩy người dùng về phía sai sót?

Một bảng tính với hàng chục cột giống nhau, không validation, không cảnh báo và không có nguồn sự thật rõ ràng sẽ tạo ra lỗi.

Một hệ thống giao việc không có mức ưu tiên rõ sẽ tạo ra việc quan trọng bị chìm.

Một nơi lưu tài liệu không có quy ước sẽ khiến mỗi người tự tạo một cấu trúc riêng.

Nhìn đủ ba lớp giúp tôi bớt kết luận quá nhanh rằng “người này không ổn”.

Đôi khi đúng là người chưa ổn.

Nhưng đôi khi chúng ta đang đặt một người bình thường vào một hệ thống dễ sai, rồi ngạc nhiên khi họ sai.

Tự động hóa tốt nhất đôi khi không phải làm nhanh hơn, mà là làm ít sai hơn

Khi nói đến tự động hóa, người ta hay nghĩ đến tiết kiệm thời gian.

Tôi cũng vậy.

Một việc mất 30 phút được rút xuống còn 3 phút là một kết quả rất dễ nhìn thấy.

Nhưng càng làm automation, tôi càng thấy một lợi ích khác đáng giá không kém: giảm phụ thuộc vào trí nhớ và sự cẩn thận thủ công.

Một cảnh báo đúng lúc có thể có giá trị hơn một dashboard đẹp.

Một rule chặn dữ liệu sai có thể có giá trị hơn việc rút ngắn vài phút thao tác.

Một log thay đổi có thể không tạo cảm giác “xịn”, nhưng nó giúp cả đội biết chuyện gì đã xảy ra khi có sự cố.

Một bước kiểm tra tự động trước khi xuất dữ liệu có thể chẳng giúp quy trình chạy nhanh hơn bao nhiêu, nhưng nó giúp mọi người ngủ ngon hơn.

Vì vậy, khi nghĩ về automation, tôi không chỉ muốn hỏi:

“Việc này có thể làm tự động được không?”

Tôi muốn hỏi thêm:

“Chỗ nào đang buộc con người phải nhớ, phải kiểm tra thủ công hoặc phải lặp lại một quyết định có quy tắc?”

Đó thường là những điểm rất đáng để hệ thống can thiệp.

Nhưng “do hệ thống” không được trở thành cái cớ để né trách nhiệm

Tư duy hệ thống cũng có một cái bẫy.

Nếu cái gì cũng giải thích bằng quy trình, môi trường và công cụ, chúng ta có thể vô tình làm mờ trách nhiệm cá nhân.

Có những việc hệ thống đã rất rõ nhưng vẫn bị bỏ qua.

Có những lỗi đến từ sự cẩu thả thật.

Có những năng lực bắt buộc phải học chứ không thể thiết kế giao diện để bù mãi.

Có những quyết định cần một người đứng tên và chịu trách nhiệm.

Vì vậy, với tôi, mục tiêu không phải là chuyển từ “đổ lỗi cho con người” sang “đổ lỗi cho hệ thống”.

Mục tiêu là tìm đúng tầng để sửa.

Nếu thiếu kỹ năng, đào tạo.

Nếu thiếu tiêu chuẩn, làm rõ tiêu chuẩn.

Nếu quy trình rườm rà, rút gọn.

Nếu công cụ dễ gây lỗi, thiết kế lại.

Nếu lỗi có thể tự phát hiện, tự động hóa việc phát hiện.

Nếu cuối cùng vẫn là vấn đề trách nhiệm, xử lý ở tầng trách nhiệm.

Điểm quan trọng là đừng nhảy thẳng đến kết luận về con người trước khi kiểm tra các tầng còn lại.

Năm câu hỏi tôi muốn giữ lại

Khi một vấn đề lặp lại, tôi muốn tự hỏi năm câu này trước:

1. Lỗi này là cá biệt hay đã xuất hiện nhiều lần?
2. Hệ thống hiện tại đang dựa vào trí nhớ của con người ở điểm nào?
3. Có thể làm cho hành vi đúng trở thành lựa chọn dễ nhất không?
4. Nếu lỗi xảy ra, hệ thống có phát hiện sớm và truy ngược được không?
5. Sau sự cố này, chúng ta chỉ nhắc nhau hay thật sự thay đổi một thứ gì đó trong cách vận hành?

Tôi đặc biệt thích câu cuối.

Bởi vì nếu một lỗi xảy ra, cả nhóm cùng họp, cùng rút kinh nghiệm, rồi hệ thống vẫn y nguyên, thì khả năng cao chúng ta chỉ vừa tạo thêm một ký ức — chưa tạo ra một cải tiến.

Cố gắng là tốt. Thiết kế để không phải cố quá nhiều còn tốt hơn

Tôi vẫn tin vào kỷ luật, trách nhiệm và nỗ lực cá nhân.

Nhưng tôi không còn muốn dùng chúng như câu trả lời đầu tiên cho mọi vấn đề.

Một người phải liên tục “cố nhớ” có thể đang làm việc trong một hệ thống cần được chuẩn hóa.

Một đội phải liên tục “nhắc nhau” có thể đang thiếu một cơ chế.

Một lỗi cứ quay trở lại có thể đang nói rằng bài học chưa được chuyển thành thiết kế.

Và một quy trình khiến người giỏi cũng thường xuyên sai thì rất có thể cần được sửa trước khi chúng ta đi sửa người.

Có lẽ đây cũng là một cách để làm mọi thứ gọn hơn:

Đừng cố biến con người thành những cỗ máy hoàn hảo. Hãy để hệ thống gánh những phần máy móc, để con người còn chỗ cho suy nghĩ, phán đoán và sáng tạo.

Từ rối đến gọn đôi khi không bắt đầu bằng việc làm nhiều hơn.

Nó bắt đầu bằng một câu hỏi khác:

“Nếu không trách người trước, mình sẽ sửa hệ thống này như thế nào?”