Tôi không ghét những vấn đề.
Thực ra, tôi khá thích chúng. Một vấn đề đủ phức tạp thường chứa đựng điều gì đó thú vị: một quy luật chưa được nhận ra, một giả định sai, hoặc một cấu trúc mà chúng ta chưa nhìn thấy.
Điều tôi không thích là sáng thứ Hai giải quyết một vấn đề, thứ Tư gặp lại nó, và đến thứ Sáu phải ngồi nghe một cuộc họp giải thích vì sao nó tiếp tục xảy ra.
Cùng một vấn đề. Những con người khác nhau. Những lời giải thích khác nhau.
Và một kết luận rất quen thuộc:
"Chúng ta cần rút kinh nghiệm."
Tôi đã nghe câu đó đủ nhiều để bắt đầu nghi ngờ rằng kinh nghiệm là thứ tài sản duy nhất trong doanh nghiệp có thể được rút ra vô hạn mà không bao giờ cạn.
Đáng tiếc, vấn đề cũng vậy.
01. Một sai lầm có thể là ngẫu nhiên. Một trăm sai lầm giống nhau thì không.
Hãy tưởng tượng một doanh nghiệp phân phối hàng hóa.
Một nhân viên bán hàng tạo đơn quá nhỏ, chi phí giao hàng vượt quá mức lợi nhuận mà đơn hàng mang lại.
Quản lý phát hiện, nhắc nhở.
Ngày hôm sau, một nhân viên khác tạo một đơn hàng tương tự.
Lần này, công ty tổ chức họp. Mọi người được yêu cầu chú ý đến giá trị đơn hàng, chi phí vận chuyển và hiệu quả kinh doanh.
Một tuần sau, vấn đề lại xuất hiện.
Giải pháp tiếp theo là gì?
Thông thường, chúng ta sẽ tăng cường đào tạo, bổ sung quy định, yêu cầu kiểm tra kỹ hơn, thậm chí đưa lỗi này vào KPI đánh giá nhân viên.
Nghe rất hợp lý.
Nhưng có một câu hỏi mà ít người đặt ra:
Tại sao hệ thống cho phép một giao dịch không đáp ứng điều kiện kinh doanh được hoàn tất ngay từ đầu?
Nếu một đơn hàng không đạt ngưỡng kinh tế tối thiểu, tại sao phần mềm không tự tính phí giao hàng?
Nếu có ngoại lệ hợp lý, tại sao không thiết kế cơ chế phê duyệt?
Nếu một quyết định ảnh hưởng đến biên lợi nhuận, tại sao hệ thống không cung cấp đủ thông tin cho người ra quyết định?
Chúng ta có thể dành ba tháng để đào tạo nhân viên không mắc lỗi.
Hoặc dành ba ngày để thiết kế lại cách hệ thống xử lý loại giao dịch đó.
Dĩ nhiên, ba ngày chỉ là một ví dụ. Có những thay đổi cần nhiều thời gian hơn rất nhiều.
Nhưng sự khác biệt không nằm ở thời gian triển khai.
Nó nằm ở thứ chúng ta đang cố sửa chữa.
Một bên cố thay đổi hành vi của từng cá nhân. Bên còn lại thay đổi điều kiện khiến hành vi sai có thể xảy ra.
Đó là hai cách tiếp cận hoàn toàn khác nhau.
02. Con người thường sửa sự kiện. Hệ thống phải sửa quy luật.
Khi một vấn đề xuất hiện, phản ứng tự nhiên của chúng ta là giải quyết sự kiện trước mắt.
Khách hàng phàn nàn? Xin lỗi khách.
Giao hàng trễ? Gọi tài xế.
Báo giá sai? Sửa báo giá.
Nhân viên quên thao tác? Nhắc nhân viên.
Không có gì sai với những hành động đó. Chúng cần thiết để hoạt động kinh doanh tiếp tục.
Nhưng giải quyết một sự kiện không đồng nghĩa với giải quyết vấn đề tạo ra sự kiện đó.
Đây là nơi tôi bắt đầu quan tâm đến một khái niệm quen thuộc trong Software Engineering: Abstraction.
Một lập trình viên mới có thể nhìn thấy mười đoạn code lỗi và sửa từng đoạn.
Một kỹ sư có kinh nghiệm hơn sẽ tự hỏi liệu cả mười đoạn code đó có đang biểu hiện cùng một sai lầm thiết kế hay không.
Nếu đúng, họ tìm cách thay đổi cấu trúc chung thay vì tiếp tục vá từng điểm riêng lẻ.
Trong doanh nghiệp cũng vậy.
Mười đơn hàng sai không nhất thiết là mười vấn đề.
Chúng có thể chỉ là mười biểu hiện của một quy tắc kinh doanh chưa được thực thi.
Một trăm cuộc gọi xác nhận không nhất thiết là một trăm công việc bắt buộc.
Chúng có thể là triệu chứng của việc dữ liệu không đủ tin cậy.
Và một nghìn lần nhân viên hỏi quản lý cùng một câu hỏi có thể cho thấy tổ chức chưa thực sự phân quyền ra quyết định.
Điều thú vị là số lượng sự cố có thể tăng lên rất nhanh, trong khi số lượng nguyên nhân cấu trúc thực sự lại nhỏ hơn nhiều.
Tất nhiên, không phải mọi sự cố trông giống nhau đều có chung nguyên nhân. Việc gom nhầm chúng vào một quy luật còn có thể nguy hiểm hơn việc xử lý riêng lẻ.
Vì vậy, abstraction không phải nghệ thuật đặt tên chung cho mọi thứ.
Nó là khả năng xác định chính xác điều gì thực sự giống nhau, điều gì khác nhau, và sự khác biệt nào có ý nghĩa.
Đây là công việc đòi hỏi tư duy, không chỉ kinh nghiệm.
03. Chúng ta đang trả lương cho con người để bù đắp những thiếu sót của hệ thống.
Có một loại chi phí doanh nghiệp rất hiếm khi được nhìn thấy trên báo cáo tài chính.
Tôi gọi nó là chi phí của sự hỗn loạn được bình thường hóa.
Một nhân viên dành mười phút mỗi ngày kiểm tra lại thông tin mà hệ thống đáng lẽ phải xác thực.
Một quản lý dành một giờ giải quyết những ngoại lệ mà chính sách chưa định nghĩa rõ.
Một bộ phận phải liên tục gọi điện cho bộ phận khác để xác nhận những dữ liệu đáng lẽ đã tồn tại trong database.
Mỗi việc đều nhỏ.
Nhỏ đến mức chẳng ai thấy đáng để cải tiến.
Nhưng khi hàng chục người lặp lại chúng hàng trăm ngày, doanh nghiệp đang âm thầm sử dụng nguồn lực quý giá nhất của mình để duy trì những khiếm khuyết đã tồn tại từ lâu.
Điều đáng sợ không phải là chi phí đó lớn bao nhiêu.
Mà là sau một thời gian, tổ chức bắt đầu coi nó như một phần tất yếu của công việc.
"Ở đây trước giờ vẫn vậy."
Câu nói ấy có thể là một trong những hệ thống phòng thủ hiệu quả nhất của sự trì trệ.
Bởi vì một khi vấn đề được chấp nhận như trạng thái bình thường, không ai còn cảm thấy cần phải đặt câu hỏi về nó.
Nhân viên mới được đào tạo để thích nghi.
Nhân viên cũ trở nên thành thạo trong việc xử lý.
Quản lý tự hào vì đội ngũ có kinh nghiệm.
Cả tổ chức ngày càng giỏi trong việc sống chung với những thứ đáng lẽ không cần tồn tại.
Một thành tựu khá kỳ lạ.
Chúng ta nâng cao năng lực con người để thích nghi với hệ thống tồi, thay vì nâng cao chất lượng hệ thống để giải phóng năng lực con người.
Và điều này đưa tôi đến một câu hỏi khác.
Nếu một nhân viên có thể dành toàn bộ thời gian để làm những việc tạo ra giá trị mới, thay vì liên tục xử lý sai sót cũ, doanh nghiệp đó sẽ khác đi bao nhiêu?
Tôi không biết câu trả lời chính xác.
Nhưng tôi nghĩ nó đáng để tìm hiểu hơn nhiều so với việc tiếp tục yêu cầu mọi người cố gắng thêm 10%.
04. Không phải vấn đề nào cũng đáng được giải quyết tận gốc.
Đến đây, có thể bạn nghĩ tôi đang đề xuất tự động hóa tất cả mọi thứ.
Không.
Đó sẽ là một cách rất hiệu quả để biến một hệ thống đang có vài vấn đề nhỏ thành một hệ thống cực kỳ phức tạp với những vấn đề lớn hơn.
Trong thực tế, không phải mọi ngoại lệ đều là tín hiệu của một khiếm khuyết cấu trúc.
Có những sự cố hoàn toàn ngẫu nhiên.
Có những tình huống quá hiếm để đáng đầu tư xây dựng cơ chế riêng.
Có những vấn đề mà chi phí loại bỏ cao hơn rất nhiều so với chi phí chấp nhận.
Và có những sai lầm chỉ đơn giản là sai lầm cá nhân.
Nếu một người cố tình vi phạm quy định đã rõ ràng, với đầy đủ thông tin và công cụ, thì không có lý do gì phải đổ trách nhiệm cho kiến trúc hệ thống.
Tôi không tin vào việc miễn trách nhiệm cho con người bằng cách đổ mọi thứ cho quy trình.
Tôi chỉ phản đối việc lấy trách nhiệm cá nhân làm câu trả lời mặc định cho những vấn đề có tính hệ thống.
Hai điều đó không mâu thuẫn.
Một kiến trúc tốt phải phân biệt được đâu là nhiễu, đâu là tín hiệu.
Và một nhà quản lý giỏi cần biết khi nào nên can thiệp, khi nào nên quan sát, khi nào nên xây dựng một cơ chế mới.
Overengineering cũng là một dạng hỗn loạn. Chỉ khác ở chỗ nó thường được trình bày bằng những sơ đồ rất đẹp.
Tôi từng làm Software Engineer. Tôi hiểu sức hấp dẫn của những sơ đồ đó.
Đặc biệt là khi chính mình vẽ.
05. Từ giải quyết vấn đề đến thiết kế cơ chế học hỏi.
Theo thời gian, tôi nhận ra điều mình thực sự muốn xây dựng không phải một doanh nghiệp không có lỗi.
Điều đó vừa thiếu thực tế, vừa có thể tạo ra một tổ chức sợ thử nghiệm.
Tôi muốn một hệ thống có khả năng học từ những sai lầm.
Một vấn đề mới xuất hiện.
Con người phát hiện, đánh giá và xử lý hậu quả trước mắt.
Nếu vấn đề có khả năng tái diễn, chúng ta phân tích nguyên nhân.
Nếu nguyên nhân có tính cấu trúc, chúng ta thay đổi cấu trúc.
Thay đổi đó có thể là một quy tắc, một cơ chế phê duyệt, một điều chỉnh quy trình, một thay đổi trong phân quyền, hoặc một đoạn phần mềm.
Sau đó, chúng ta quan sát xem vấn đề còn xuất hiện không, và liệu giải pháp có tạo ra tác dụng phụ nào khác.
Nếu có, tiếp tục điều chỉnh.
Đó là một feedback loop.
Không có gì quá thần bí.
Nhưng nó đòi hỏi một sự thay đổi quan trọng trong cách tổ chức đánh giá thành công.
Một quản lý giải quyết được 100 vấn đề có thể là người rất giỏi.
Nhưng một người thiết kế được cơ chế khiến 80 trong số 100 vấn đề đó không còn cần đến sự can thiệp của quản lý có thể đã tạo ra giá trị lớn hơn nhiều.
Dĩ nhiên, phải kiểm chứng kết quả. Một quy trình khiến số lỗi giảm bằng cách ngăn luôn cả những giao dịch hợp lệ thì chẳng phải cải tiến gì đáng tự hào.
Sự khác biệt không nằm ở việc ai làm việc chăm chỉ hơn.
Nó nằm ở việc thành quả của ai tiếp tục tạo ra giá trị ngay cả khi người đó không còn trực tiếp tham gia.
Trong kỹ thuật, chúng ta xây dựng những thành phần có thể tái sử dụng.
Trong tổ chức, tôi muốn xây dựng những quyết định có thể được thực thi nhất quán mà không cần người đã đưa ra chúng phải có mặt mỗi ngày.
Một quyết định đúng được lặp lại nhờ trí nhớ của con người vẫn là một quyết định mong manh.
Một quyết định đúng được chuyển hóa thành năng lực của hệ thống mới thực sự có khả năng mở rộng.
06. Cái bẫy của những người giải quyết vấn đề giỏi.
Có một nghịch lý mà tôi thấy đặc biệt thú vị.
Những người có khả năng giải quyết vấn đề nhanh nhất đôi khi lại trở thành nguyên nhân khiến tổ chức chậm phát triển.
Một founder hiểu hoạt động kinh doanh sâu sắc có thể xử lý ngoại lệ trong vài phút.
Một quản lý giàu kinh nghiệm có thể đưa ra quyết định chính xác mà không cần tham khảo tài liệu.
Một nhân viên xuất sắc có thể tự mình giải quyết những tình huống mà ba người khác phải mất cả ngày.
Trong ngắn hạn, họ là tài sản vô giá.
Nhưng nếu tất cả những quyết định đó chỉ tồn tại trong đầu họ, tổ chức sẽ dần hình thành sự phụ thuộc.
Mọi việc khó đều được chuyển đến người giỏi nhất.
Người giỏi nhất ngày càng bận.
Những người còn lại không có đủ cơ hội để tự ra quyết định.
Và doanh nghiệp phát triển đến đâu, nút thắt cổ chai cũng phát triển theo đến đó.
Tôi đặc biệt cảnh giác với cái bẫy này.
Bởi vì một người có thể rất tự hào khi mình là người duy nhất giải quyết được những vấn đề khó.
Cảm giác ấy khá dễ chịu.
Cho đến khi nhận ra rằng sự tồn tại của mình đã trở thành điều kiện bắt buộc để cả hệ thống vận hành.
Lúc đó, bạn không còn sở hữu một doanh nghiệp có khả năng mở rộng.
Bạn đang sở hữu một công việc cực kỳ phức tạp, với rất nhiều nhân viên hỗ trợ.
Và người nhân viên không được phép nghỉ phép chính là bạn.
Khá ngu ngốc, nếu mục tiêu ban đầu là xây dựng một tổ chức.
07. Tôi không muốn trở thành người giải quyết vấn đề giỏi nhất.
Tôi muốn thiết kế một hệ thống ngày càng ít cần đến khả năng đó của mình.
Điều này không có nghĩa tôi ngừng giải quyết vấn đề.
Ngược lại, tôi muốn tiếp tục đối diện với những vấn đề lớn hơn, mới hơn và khó hơn.
Nhưng tôi không muốn dành năng lực của mình cho những thứ đã được hiểu rõ.
Nếu hôm nay tôi phải can thiệp để giải quyết một tình huống, ngày mai tôi muốn biết liệu tổ chức có thể tự xử lý nó hay không.
Nếu chưa thể, điều gì đang thiếu?
Thông tin?
Quyền hạn?
Năng lực?
Hay một nguyên tắc ra quyết định chưa được định nghĩa?
Đôi khi câu trả lời là phải đào tạo con người.
Đôi khi là phải thay đổi phần mềm.
Đôi khi là phải thiết kế lại cả cách tổ chức công việc.
Và đôi khi, chúng ta đơn giản phải chấp nhận rằng không phải mọi thứ đều có thể được hệ thống hóa một cách hiệu quả.
Điều quan trọng là không ngừng phân biệt những trường hợp đó.
Tôi không theo đuổi sự hoàn hảo.
Tôi theo đuổi khả năng tiến hóa.
Một doanh nghiệp đủ tốt để hoạt động hôm nay, đủ linh hoạt để học từ ngày mai, và đủ trưởng thành để không phải học lại cùng một bài học mãi mãi.
Lời kết: The Same Problem, Again.
Một vấn đề xuất hiện lần đầu có thể là một sự cố.
Lần thứ hai, nó đáng được chú ý.
Lần thứ ba, chúng ta nên bắt đầu tìm kiếm một quy luật.
Nhưng không có con số thần kỳ nào xác định lúc nào một sự cố trở thành vấn đề hệ thống. Đôi khi chỉ một lần là đủ để thấy một khiếm khuyết nghiêm trọng. Đôi khi một trăm lần vẫn chỉ là một trăm sự kiện độc lập.
Khả năng phân biệt chúng mới là điều quan trọng.
Và đó cũng là lý do tôi luôn thích đặt câu hỏi hơn là vội vàng đưa ra câu trả lời.
Bởi vì đằng sau một vấn đề tưởng chừng đơn giản, có thể tồn tại cả một cấu trúc đang chờ được nhận diện.
Tôi tin rằng năng lực đáng giá nhất của một người thiết kế hệ thống không phải khả năng giải quyết thật nhiều vấn đề.
Mà là khả năng nhận ra những vấn đề nào thực chất chỉ là những biểu hiện khác nhau của cùng một nguyên nhân.
Một khi nhìn thấy điều đó, cách tiếp cận sẽ thay đổi hoàn toàn.
Chúng ta ngừng chạy theo từng sự cố.
Chúng ta bắt đầu thiết kế lại những điều kiện tạo ra chúng.
Và nếu ngày mai vấn đề ấy vẫn tiếp tục xuất hiện?
Tôi sẽ không vội kết luận rằng nhân viên thiếu trách nhiệm.
Tôi sẽ hỏi hệ thống đã học được điều gì từ lần trước.
Nếu câu trả lời là không có gì...
Thì chúng ta vừa phát hiện thêm một vấn đề. Và lần này, rất có thể vấn đề nằm ở người thiết kế.
Chết tiệt.
NEXT CHAPTER — PEOPLE ARE NOT THE SYSTEM
Khi mười người cùng mắc một sai lầm, chúng ta đang có mười nhân viên kém năng lực, hay một kiến trúc tồi?
The Architect of Chaos — Ông Chú Hay Chửi