Abstraction Is a Superpower.

Có một câu hỏi mà tôi đã nghe rất nhiều lần trong quá trình điều hành doanh nghiệp.

"Anh ơi, trường hợp này xử lý sao?"

Một khách hàng muốn hỗ trợ phí vận chuyển.

Một nhân viên cần điều chỉnh giá bán.

Một đơn hàng có điều kiện thanh toán đặc biệt.

Một khách hàng yêu cầu giao hàng ngoài lịch trình.

Một giao dịch không đáp ứng quy định hiện tại nhưng người phụ trách cho rằng vẫn nên được chấp thuận.

Mỗi trường hợp có một câu chuyện riêng.

Mỗi nhân viên có một cách giải thích riêng.

Và mỗi lần, người quản lý lại phải xem xét dữ liệu, đánh giá bối cảnh, cân nhắc rủi ro rồi đưa ra quyết định.

Ban đầu, tôi thấy điều đó khá bình thường.

Kinh doanh vốn phức tạp.

Khách hàng không giống nhau.

Vấn đề không giống nhau.

Và một người lãnh đạo có kinh nghiệm cần phải đưa ra những quyết định mà người khác chưa đủ khả năng thực hiện.

Nghe rất hợp lý.

Cho đến khi tôi nhận ra một điều hơi khó chịu.

Tôi đang liên tục trả lời những câu hỏi khác nhau bằng cùng một logic.

Những tình huống bề ngoài rất khác biệt, nhưng cách tôi đánh giá chúng lại có những điểm chung đáng ngạc nhiên.

Ai đang yêu cầu?

Người đó có quyền quyết định đến đâu?

Những điều kiện nào phải được đáp ứng?

Rủi ro kinh tế là gì?

Nếu vượt khỏi giới hạn, ai có quyền phê duyệt?

Và quyết định đó cần được ghi nhận như thế nào?

Đột nhiên, năm vấn đề không còn hoàn toàn là năm vấn đề độc lập.

Chúng bắt đầu cho thấy một cấu trúc chung.

Đây là khoảnh khắc mà bộ não của một Software Engineer thường trở nên đặc biệt phấn khích.

Bởi vì nếu nhiều vấn đề cùng chia sẻ một cấu trúc, có lẽ chúng ta không cần tiếp tục giải quyết chúng hoàn toàn riêng lẻ.

Có lẽ chúng ta có thể thiết kế một cơ chế chung.

Và nếu làm đúng, cơ chế đó có thể xử lý không chỉ năm tình huống ban đầu, mà cả những tình huống tương tự trong tương lai.

Nghe như phép thuật.

Thực ra, nó có một cái tên khá quen thuộc.

Abstraction.

Và giống như nhiều thứ có vẻ đầy quyền năng trong kỹ thuật, nó cũng là một cách cực kỳ hiệu quả để tạo ra thảm họa nếu được sử dụng bởi một người quá tự tin.

01. Từ câu trả lời đến nguyên lý tạo ra câu trả lời.

Hãy tưởng tượng bạn đang điều hành một doanh nghiệp có mười nhân viên bán hàng.

Mỗi ngày, họ gặp những tình huống khác nhau và cần người quản lý hỗ trợ.

Bạn là người có kinh nghiệm.

Bạn biết lịch sử khách hàng.

Hiểu cấu trúc lợi nhuận.

Nắm được giới hạn vận hành.

Và có khả năng cân nhắc các yếu tố để đưa ra quyết định khá nhanh.

Sau một thời gian, bạn trở thành người giải quyết vấn đề hiệu quả nhất trong tổ chức.

Tuyệt vời.

Nhưng hãy thử đặt một câu hỏi khác.

Nếu bạn có thể đưa ra quyết định trong ba mươi giây, điều gì khiến nhân viên của bạn không thể?

Có thể họ thiếu kinh nghiệm.

Có thể họ thiếu thông tin.

Có thể họ chưa đủ quyền hạn.

Nhưng còn một khả năng khác.

Bạn đang sử dụng một mô hình ra quyết định mà chính bạn chưa từng diễn đạt thành cấu trúc rõ ràng.

Bạn biết khi nào nên chấp thuận hỗ trợ phí giao hàng.

Nhưng bạn chưa định nghĩa đầy đủ những yếu tố nào khiến một yêu cầu đáng được chấp thuận.

Bạn biết khi nào một khách hàng xứng đáng nhận chính sách đặc biệt.

Nhưng phần lớn hiểu biết đó đang tồn tại dưới dạng trực giác được tích lũy từ kinh nghiệm.

Bạn biết những rủi ro nào có thể chấp nhận.

Nhưng người khác chỉ nhìn thấy quyết định cuối cùng, không nhìn thấy toàn bộ logic tạo ra nó.

Kết quả là họ học được những câu trả lời.

Không phải cách tạo ra câu trả lời.

Hôm nay bạn đồng ý hỗ trợ một khách hàng.

Nhân viên ghi nhớ rằng loại khách hàng đó có thể được hỗ trợ.

Ngày mai xuất hiện một khách hàng tương tự, nhưng với cấu trúc lợi nhuận hoàn toàn khác.

Nhân viên áp dụng kinh nghiệm hôm qua.

Và đưa ra quyết định sai.

Không hẳn vì họ thiếu thông minh.

Mà vì họ đã học một kết quả cụ thể thay vì nguyên lý đứng sau kết quả đó.

Đây là khác biệt quan trọng giữa memorization và abstraction.

Một bên ghi nhớ những trường hợp đã xảy ra.

Bên còn lại cố gắng xác định những yếu tố thực sự quyết định kết quả.

Một người có thể biết rất nhiều câu trả lời mà không hiểu nguyên lý.

Và một người hiểu đúng nguyên lý có thể giải quyết được những câu hỏi mà họ chưa từng gặp.

Abstraction không đơn thuần giúp chúng ta giải quyết vấn đề nhanh hơn. Nó giúp chuyển từ việc ghi nhớ câu trả lời sang hiểu cơ chế tạo ra câu trả lời.

Đây là một trong những bước chuyển quan trọng nhất khi xây dựng một hệ thống có khả năng mở rộng.

02. Abstraction không phải là gom những thứ giống nhau.

Có một cách hiểu khá phổ biến về abstraction.

Tìm những thứ có đặc điểm chung.

Gom chúng lại.

Đặt một cái tên.

Tạo ra một mô hình tổng quát.

Xong.

Tiếc là nếu chỉ cần như vậy, việc thiết kế hệ thống đã đơn giản hơn rất nhiều.

Hãy tưởng tượng một doanh nghiệp có ba loại yêu cầu.

Khách hàng xin giảm giá.

Khách hàng xin miễn phí vận chuyển.

Khách hàng xin gia hạn thời gian thanh toán.

Cả ba đều có một điểm chung.

Chúng liên quan đến việc doanh nghiệp chấp nhận thay đổi một điều kiện thương mại.

Một người có thể nhanh chóng tạo ra khái niệm:

Commercial Exception.

Nghe rất hay.

Sau đó xây dựng một quy trình phê duyệt chung cho tất cả.

Nhân viên gửi yêu cầu.

Quản lý chấp thuận hoặc từ chối.

Hệ thống ghi nhận kết quả.

Một abstraction rất đẹp.

Nhưng liệu nó có thực sự tốt?

Giảm giá làm thay đổi doanh thu và biên lợi nhuận của giao dịch.

Hỗ trợ vận chuyển làm thay đổi chi phí phục vụ đơn hàng.

Gia hạn thanh toán làm thay đổi dòng tiền, mức độ phơi nhiễm tín dụng và rủi ro thu hồi công nợ.

Cùng là ngoại lệ thương mại.

Nhưng bản chất kinh tế hoàn toàn khác nhau.

Nếu chúng ta sử dụng cùng một cơ chế đánh giá mà bỏ qua những khác biệt này, abstraction đã xóa mất thông tin quan trọng.

Và một abstraction làm mất những khác biệt quan trọng không phải là sự đơn giản hóa thông minh.

Nó là một sai lầm được đóng gói chuyên nghiệp.

Vậy phải làm sao?

Chúng ta có thể nhận diện một cấu trúc chung ở tầng điều phối quyết định:

Ai yêu cầu?

Loại quyết định là gì?

Dữ liệu nào bắt buộc phải có?

Ai có quyền quyết định?

Quyết định có cần phê duyệt không?

Kết quả được ghi nhận thế nào?

Nhưng logic kinh doanh cụ thể vẫn phải được giữ riêng.

Đánh giá giảm giá dựa trên những điều kiện liên quan đến giá và lợi nhuận.

Đánh giá hỗ trợ vận chuyển dựa trên chi phí giao nhận và chính sách phục vụ.

Đánh giá công nợ dựa trên hạn mức tín dụng, khả năng thanh toán và rủi ro tài chính.

Chúng ta chia sẻ phần thực sự giống nhau.

Và giữ riêng phần thực sự khác nhau.

Good abstraction is not about removing differences. It is about removing irrelevant differences while preserving meaningful ones.

Một abstraction tốt không loại bỏ mọi khác biệt.

Nó chỉ loại bỏ những khác biệt không ảnh hưởng đến bản chất của quyết định.

Nghe có vẻ đơn giản.

Nhưng đây chính là phần khó nhất.

Bởi vì để biết khác biệt nào không quan trọng, trước hết chúng ta phải hiểu rất sâu về vấn đề.

03. The Invariant — Tìm thứ không thay đổi giữa những tình huống thay đổi.

Trong toán học và kỹ thuật, một khái niệm mà tôi đặc biệt thích là Invariant.

Một tính chất hoặc điều kiện được duy trì khi những yếu tố khác thay đổi.

Trong thiết kế phần mềm, invariant có thể là điều kiện mà hệ thống phải luôn bảo đảm.

Trong thiết kế kinh doanh, chúng ta cũng có thể sử dụng cách tư duy tương tự.

Hãy xem một số tình huống.

Nhân viên được phép giảm giá trong một giới hạn nhất định.

Nhân viên được phép hỗ trợ vận chuyển trong những trường hợp được định nghĩa.

Nhân viên được phép điều chỉnh một số điều kiện giao dịch mà không cần người quản lý can thiệp.

Những quyền hạn cụ thể có thể khác nhau.

Nhưng một nguyên lý có thể được giữ nguyên:

Một quyết định chỉ được thực hiện khi người ra quyết định có đủ thẩm quyền và các điều kiện bắt buộc của quyết định đã được đáp ứng.

Đó là một invariant ở tầng quản trị.

Nó không nói mọi quyết định phải có cùng điều kiện.

Nó không nói mọi loại rủi ro phải được đánh giá giống nhau.

Nó chỉ định nghĩa một yêu cầu chung mà mọi quyết định thuộc phạm vi quản lý phải tuân thủ.

Từ nguyên lý đó, chúng ta có thể xây dựng một cấu trúc.

Một loại quyết định có bộ điều kiện riêng.

Một vai trò có phạm vi quyền hạn riêng.

Một tình huống vượt khỏi quyền hạn cần cơ chế xử lý tương ứng.

Một quyết định được thực hiện phải có khả năng truy vết.

Điểm quan trọng nằm ở chỗ những điều kiện này có thể được định nghĩa độc lập với từng nhân viên cụ thể.

Khi nhân sự thay đổi, logic quản trị không cần được phát minh lại từ đầu.

Khi một bộ phận mới xuất hiện, chúng ta có thể xem xét liệu cấu trúc hiện tại có phù hợp hay không.

Khi chính sách thay đổi, chúng ta điều chỉnh những thành phần liên quan thay vì sửa thủ công hàng chục quy trình không đồng nhất.

Đây là nơi abstraction bắt đầu chuyển thành kiến trúc.

Nó tạo ra một bộ khung ổn định để xử lý những biến thể khác nhau.

Nhưng cần phân biệt invariant với một giả định kinh doanh tạm thời.

Ví dụ, một doanh nghiệp có thể quy định đơn hàng dưới một giá trị nhất định phải trả phí vận chuyển.

Ngưỡng giá trị đó có thể thay đổi khi cấu trúc chi phí thay đổi.

Vì vậy, bản thân con số không nhất thiết là invariant.

Điều cần được duy trì có thể là nguyên lý:

Mọi đơn hàng phải được đánh giá theo chính sách chi phí phục vụ đang có hiệu lực, trừ những ngoại lệ được chấp thuận hợp lệ.

Một bên là tham số.

Bên còn lại là nguyên tắc vận hành.

Nhầm lẫn hai thứ sẽ khiến hệ thống trở nên cứng nhắc.

Chúng ta không muốn viết lại kiến trúc mỗi khi doanh nghiệp điều chỉnh chính sách.

Nhưng cũng không muốn biến mọi thứ thành tham số có thể thay đổi tùy tiện.

Abstraction tốt phải biết phân biệt điều gì là nguyên lý, điều gì là chính sách và điều gì chỉ là giá trị cấu hình.

Nếu không làm được, chúng ta chỉ đang chuyển sự hỗn loạn từ hoạt động vận hành sang phần mềm.

Với giao diện quản trị rất đẹp.

04. Complexity không biến mất. Nó được tổ chức lại.

Có một sự thật mà tôi nghĩ những người làm công nghệ nên chấp nhận sớm.

Sự phức tạp của thế giới thực không tự nhiên biến mất chỉ vì chúng ta thiết kế một mô hình đẹp.

Khách hàng vẫn có nhu cầu khác nhau.

Sản phẩm vẫn có những đặc tính khác nhau.

Tình huống kinh doanh vẫn có ngoại lệ.

Con người vẫn có giới hạn.

Và thị trường vẫn thay đổi theo những cách không ai dự đoán đầy đủ.

Abstraction không xóa bỏ toàn bộ sự phức tạp đó.

Nó giúp chúng ta tổ chức sự phức tạp theo một cách có thể hiểu và quản lý được.

Hãy tưởng tượng một doanh nghiệp có hàng nghìn sản phẩm bao bì.

Ly nhựa.

Nắp ly.

Ống hút.

Tô giấy.

Hộp đựng thực phẩm.

Túi giấy.

Hàng trăm kích thước, chất liệu, quy cách đóng gói và tiêu chuẩn tương thích.

Nếu mỗi mối quan hệ giữa sản phẩm phải được nhân viên ghi nhớ, doanh nghiệp sẽ phụ thuộc rất lớn vào kinh nghiệm cá nhân.

Một nhân viên lâu năm có thể biết loại nắp nào phù hợp với một nhóm ly.

Nhưng nhân viên mới có thể cần nhiều tháng để tích lũy kiến thức tương tự.

Chúng ta có thể cố gắng đào tạo tất cả.

Hoặc tìm cách mô hình hóa những thuộc tính và quan hệ có ý nghĩa.

Nhưng điều đó không đơn giản là gắn nhãn mọi sản phẩm có cùng đường kính miệng.

Hai sản phẩm có cùng một kích thước danh nghĩa chưa chắc tương thích trong mọi trường hợp.

Hình học vành miệng, kiểu khóa nắp, độ cứng vật liệu, dung sai sản xuất và mục đích sử dụng có thể ảnh hưởng đến kết quả thực tế.

Nếu abstraction chỉ giữ lại đường kính mà bỏ qua các yếu tố quyết định khả năng tương thích, chúng ta sẽ tạo ra những gợi ý có vẻ hợp lý nhưng không đáng tin cậy.

Ngược lại, nếu mỗi quan hệ phải được nhập và kiểm tra hoàn toàn thủ công, hệ thống sẽ khó mở rộng.

Vấn đề thiết kế nằm giữa hai thái cực đó.

Những thuộc tính nào có thể được sử dụng để suy luận?

Những quan hệ nào phải được xác nhận bằng dữ liệu thực tế?

Những trường hợp nào cần kiểm tra bổ sung?

Và khi một giả định tương thích bị chứng minh là sai, làm sao để hệ thống học từ kết quả đó?

Một mô hình tốt không cần giả vờ rằng mọi quan hệ đều có thể được suy ra.

Nó phải biết đâu là điều có thể xác định bằng quy tắc, đâu là điều cần bằng chứng thực nghiệm, và đâu là điều chưa đủ thông tin để kết luận.

The purpose of abstraction is not to make reality simple. It is to make complexity manageable.

Đây là sự khác biệt giữa một mô hình đẹp và một mô hình hữu dụng.

Một mô hình đẹp có thể khiến chúng ta cảm thấy thế giới đã trở nên đơn giản.

Một mô hình hữu dụng cho phép chúng ta đưa ra quyết định tốt hơn dù thế giới vẫn phức tạp.

Tôi chọn loại thứ hai.

Dù phải thừa nhận rằng loại thứ nhất thường trông ấn tượng hơn trên slide thuyết trình.

05. Từ một trăm trường hợp đến một Decision Model.

Giả sử một doanh nghiệp liên tục gặp những yêu cầu phê duyệt khác nhau.

Một trăm trường hợp được ghi nhận.

Chúng liên quan đến nhiều nhân viên, nhiều loại khách hàng và nhiều chính sách.

Cách tiếp cận thông thường là phân nhóm các trường hợp theo chủ đề.

Giảm giá.

Phí vận chuyển.

Công nợ.

Giao nhận.

Đổi trả.

Sau đó viết quy trình riêng cho từng nhóm.

Đó có thể là một bước khởi đầu hợp lý.

Nhưng tôi muốn thử đi sâu thêm.

Thay vì chỉ phân loại các trường hợp, hãy phân tích cấu trúc của một quyết định.

Một quyết định kinh doanh thường có những thành phần đáng xem xét:

Context — Bối cảnh.

Những dữ liệu nào cần thiết để hiểu tình huống?

Constraints — Ràng buộc.

Những điều kiện nào không được phép vi phạm, hoặc chỉ có thể vượt qua theo cơ chế đặc biệt?

Authority — Thẩm quyền.

Ai được phép đưa ra quyết định, trong phạm vi nào?

Policy — Chính sách.

Những quy tắc nào áp dụng cho tình huống hiện tại?

Exception Path — Đường xử lý ngoại lệ.

Điều gì xảy ra khi quyết định nằm ngoài phạm vi đã định nghĩa?

Outcome — Kết quả.

Quyết định được thực hiện thế nào và tạo ra tác động gì?

Đây không phải một công thức bất biến áp dụng cho mọi hoạt động.

Nhưng nó có thể là một mô hình hữu ích cho nhiều loại quyết định thương mại và vận hành.

Từ đây, thay vì viết một trăm hướng dẫn độc lập, chúng ta có thể xác định những thành phần chung và những thành phần riêng.

Mỗi loại quyết định có bộ dữ liệu bắt buộc.

Mỗi loại ràng buộc có cách kiểm tra phù hợp.

Mỗi vai trò có phạm vi thẩm quyền.

Mỗi chính sách có điều kiện áp dụng.

Mỗi ngoại lệ có phương thức xử lý.

Và mỗi quyết định quan trọng có thể được ghi nhận để kiểm chứng về sau.

Hãy nhìn lại sự thay đổi.

Ban đầu, chúng ta có một trăm câu hỏi.

Sau đó, chúng ta có một mô hình giúp tổ chức tạo ra câu trả lời cho những câu hỏi thuộc phạm vi của nó.

Đây chính là sức mạnh của abstraction.

Chúng ta không còn cố gắng lưu trữ một trăm quyết định đúng. Chúng ta cố gắng thiết kế một cơ chế có khả năng tạo ra những quyết định đúng.

Nhưng tôi muốn nhấn mạnh chữ cố gắng.

Một mô hình chỉ tốt trong phạm vi những giả định mà nó phản ánh chính xác.

Nếu chính sách sai, dữ liệu sai hoặc các ràng buộc bị hiểu sai, hệ thống vẫn có thể đưa ra kết quả sai với sự nhất quán tuyệt vời.

Và sự nhất quán không làm cho một quyết định sai trở nên đúng.

Nó chỉ khiến sai lầm có khả năng được nhân rộng.

06. Một abstraction tốt phải có ranh giới.

Có một căn bệnh nghề nghiệp khá phổ biến ở những Software Engineer có kinh nghiệm.

Chúng ta nhìn thấy hai vấn đề tương tự và bắt đầu nghĩ đến việc xây dựng một framework chung.

Sau đó xuất hiện vấn đề thứ ba.

Framework được mở rộng.

Vấn đề thứ tư cần một cơ chế đặc biệt.

Chúng ta bổ sung configuration.

Vấn đề thứ năm không phù hợp với cấu trúc hiện tại.

Chúng ta thêm plugin.

Vấn đề thứ sáu cần can thiệp vào quá trình xử lý.

Chúng ta bổ sung event hooks.

Và đến vấn đề thứ bảy, chúng ta nhận ra mình vừa xây dựng một nền tảng cực kỳ linh hoạt, có thể cấu hình gần như mọi thứ.

Tuyệt vời.

Chỉ có một vấn đề.

Không ai còn hiểu chính xác nó đang làm gì.

Kể cả người viết.

Đây là hiện tượng tôi rất cảnh giác.

Over-Abstraction.

Khi một abstraction cố gắng bao phủ quá nhiều trường hợp, nó có thể đánh mất ý nghĩa ban đầu.

Một cơ chế phê duyệt chung cho nhiều loại giao dịch có thể hợp lý.

Nhưng điều đó không có nghĩa mọi quy trình trong doanh nghiệp đều nên được chuyển thành cùng một loại workflow.

Một quy trình kiểm soát công nợ có những ràng buộc tài chính rất khác với một quy trình xử lý khiếu nại chất lượng sản phẩm.

Một quyết định thay đổi giá bán không có cùng bản chất với việc xác nhận chất lượng một mẫu in.

Nếu cố gắng ép tất cả vào một cấu trúc duy nhất, chúng ta có thể phải tạo ra ngày càng nhiều ngoại lệ bên trong chính abstraction.

Và đến một thời điểm, phần xử lý ngoại lệ còn phức tạp hơn những quy trình ban đầu.

Có một dấu hiệu mà tôi thường xem là cảnh báo.

Khi phải giải thích một mô hình chung bằng quá nhiều câu bắt đầu với:

"Trừ trường hợp..."

Chúng ta nên tự hỏi liệu abstraction đó có đang vượt khỏi phạm vi hợp lý hay không.

Không phải cứ xuất hiện ngoại lệ là thiết kế sai.

Nhưng nếu ngoại lệ liên tục phủ định những giả định nền tảng, rất có thể chúng ta đã xác định sai ranh giới.

Một abstraction tốt không chỉ biết những gì nó có thể xử lý.

Nó còn phải biết những gì nó không nên xử lý.

Trong kỹ thuật, ranh giới tốt giúp chúng ta kiểm soát sự phụ thuộc.

Trong quản trị, ranh giới tốt giúp xác định trách nhiệm và phạm vi quyết định.

Cả hai đều bảo vệ hệ thống khỏi một sai lầm rất hấp dẫn:

Cố gắng biến một giải pháp hữu ích thành giải pháp cho mọi thứ.

Tôi không phản đối những framework mạnh.

Tôi chỉ nghĩ rằng trước khi xây dựng một framework có thể giải quyết toàn bộ vấn đề của nhân loại, chúng ta nên kiểm tra xem nó đã giải quyết tốt vấn đề đầu tiên hay chưa.

07. Mô hình phải được thiết kế để gặp thực tế.

Một abstraction thường bắt đầu trong đầu người thiết kế.

Sau đó nó xuất hiện trên bảng trắng.

Rồi được chuyển thành một sơ đồ.

Cuối cùng trở thành tài liệu hoặc phần mềm.

Quá trình này khá thú vị.

Nhưng có một điểm nguy hiểm.

Trong suốt những bước đó, mô hình có thể ngày càng trở nên nhất quán với chính nó mà chưa chắc đã nhất quán với thực tế.

Người thiết kế có thể dành hàng tuần để hoàn thiện một cấu trúc rất thanh lịch.

Các thành phần được phân chia rõ ràng.

Luồng dữ liệu hợp lý.

Quyền hạn có định nghĩa.

Ngoại lệ có cơ chế xử lý.

Mọi thứ trông hoàn hảo.

Cho đến khi một nhân viên thực sự sử dụng.

Và câu đầu tiên họ nói là:

"Nhưng khách bên em không làm vậy."

Tôi nghĩ những câu nói như thế rất đáng được lắng nghe.

Không nhất thiết vì nhân viên luôn đúng.

Nhưng vì chúng có thể chỉ ra những giả định mà mô hình chưa phản ánh.

Một sản phẩm có thể có những quy cách thực tế khác với dữ liệu được chuẩn hóa.

Một nhóm khách hàng có thể có hành vi mua hàng khác với những giả định trong chính sách.

Một bước phê duyệt có thể hợp lý trên sơ đồ nhưng gây chậm trễ không chấp nhận được trong giờ cao điểm.

Một ràng buộc có thể bảo vệ lợi nhuận ở cấp giao dịch nhưng khiến doanh nghiệp đánh mất một nhóm khách hàng có giá trị dài hạn.

Đó là lý do tôi không tin vào việc đánh giá abstraction chỉ thông qua vẻ đẹp của thiết kế.

Nó phải được thử nghiệm với những trường hợp thực tế.

Đặc biệt là những trường hợp không phù hợp với giả định của người thiết kế.

Tôi thích bắt đầu bằng một số câu hỏi.

Mô hình này giải thích được những trường hợp nào?

Những trường hợp nào nó chưa giải thích được?

Có tình huống nào khiến hai quyết định giống nhau về dữ liệu đầu vào nhưng thực tế phải có kết quả khác nhau?

Nếu có, chúng ta đang thiếu biến số nào?

Và nếu bổ sung biến số đó, liệu nó có thực sự làm mô hình tốt hơn, hay chỉ đang vá một ngoại lệ hiếm gặp?

Đây là công việc không thể giải quyết bằng sự tự tin.

Nó cần dữ liệu.

Thử nghiệm.

Phản biện.

Và khả năng chấp nhận rằng mô hình đầu tiên của mình có thể chưa đúng.

A good abstraction must survive contact with reality.

Nếu một mô hình chỉ hoạt động khi mọi người làm đúng những điều mà người thiết kế dự đoán, thì mô hình đó có thể vẫn chưa đủ trưởng thành.

Bởi vì thế giới thực có một thói quen rất khó chịu.

Nó không đọc tài liệu thiết kế của chúng ta trước khi hoạt động.

08. Abstraction phải có khả năng tiến hóa.

Một mô hình được thiết kế tốt hôm nay không nhất thiết tiếp tục phù hợp sau ba năm.

Quy mô doanh nghiệp thay đổi.

Cấu trúc khách hàng thay đổi.

Sản phẩm thay đổi.

Công nghệ thay đổi.

Và những ngoại lệ từng hiếm gặp có thể trở thành một phần quan trọng của hoạt động kinh doanh.

Nếu abstraction được xây dựng quá cứng, mỗi thay đổi sẽ đòi hỏi can thiệp vào cấu trúc cốt lõi.

Theo thời gian, hệ thống ngày càng khó sửa.

Một thay đổi nhỏ có thể ảnh hưởng đến hàng chục thành phần.

Một chính sách mới đòi hỏi chỉnh sửa nhiều nơi.

Và mỗi lần triển khai đều mang theo nguy cơ phá vỡ những chức năng trước đó.

Đây là lý do tôi quan tâm đến việc tách những yếu tố ổn định khỏi những yếu tố có khả năng thay đổi.

Một nguyên lý quản trị có thể tương đối ổn định.

Nhưng ngưỡng giá trị giao dịch có thể thay đổi thường xuyên.

Cấu trúc quyền hạn có thể được định nghĩa rõ.

Nhưng người đảm nhiệm một vai trò có thể thay đổi.

Một loại quyết định có thể có quy trình xử lý ổn định.

Nhưng những điều kiện kinh doanh áp dụng cho nó có thể được điều chỉnh.

Nếu mọi thứ bị trộn lẫn vào cùng một khối logic, thay đổi sẽ trở nên đắt đỏ.

Ngược lại, nếu mọi thứ đều được cấu hình tùy ý, hệ thống có thể mất tính nhất quán.

Vấn đề thiết kế là xác định phần nào cần ổn định, phần nào cần linh hoạt, và ai có quyền thay đổi từng phần.

Flexibility without boundaries is chaos. Stability without adaptability is rigidity.

Một abstraction có giá trị lâu dài phải tìm được sự cân bằng giữa hai thứ đó.

Nhưng sự cân bằng không có nghĩa tất cả thành phần đều phải linh hoạt như nhau.

Có những ràng buộc cần được bảo vệ nghiêm ngặt.

Có những chính sách nên dễ điều chỉnh.

Có những quyết định chỉ nên thay đổi sau khi có bằng chứng đủ mạnh.

Và có những giả định cần được liên tục thử nghiệm.

Một kiến trúc tốt phải phản ánh những khác biệt ấy.

Bởi vì thay đổi không phải điều duy nhất chúng ta cần quản lý.

Chúng ta còn phải quản lý quyền được thay đổi.

09. Khi abstraction trở thành năng lực của tổ chức.

Đến đây, chúng ta có thể quay lại câu hỏi ban đầu.

Tại sao một nhân viên phải liên tục hỏi quản lý về những tình huống đã xuất hiện nhiều lần?

Có thể họ thiếu năng lực.

Nhưng cũng có thể tổ chức chưa chuyển hóa được những hiểu biết đã tích lũy thành một cơ chế có thể sử dụng chung.

Một người quản lý có thể rất giỏi đưa ra quyết định.

Nhưng nếu mọi quyết định đều yêu cầu họ trực tiếp tham gia, năng lực đó vẫn chủ yếu thuộc về cá nhân.

Một Software Engineer có thể hiểu toàn bộ logic nghiệp vụ.

Nhưng nếu chỉ mình họ có thể sửa và vận hành hệ thống, doanh nghiệp vẫn đang phụ thuộc vào một cá nhân khác.

Một nhân viên kỳ cựu có thể biết chính xác sản phẩm nào phù hợp với từng loại khách hàng.

Nhưng nếu kiến thức đó chỉ tồn tại trong trí nhớ, tổ chức chưa thực sự sở hữu một hệ thống tri thức có khả năng mở rộng.

Abstraction tạo ra cơ hội để thay đổi điều này.

Nó cho phép chuyển một phần tri thức ngầm thành cấu trúc rõ ràng.

Từ kinh nghiệm cá nhân thành nguyên tắc.

Từ nguyên tắc thành mô hình.

Từ mô hình thành quy trình, dữ liệu hoặc phần mềm.

Và từ những thành phần đó thành năng lực vận hành mà nhiều người có thể sử dụng.

Tất nhiên, không phải mọi tri thức đều có thể được mô hình hóa đầy đủ.

Có những quyết định đòi hỏi kinh nghiệm, cảm nhận bối cảnh và khả năng phán đoán trong điều kiện thiếu thông tin.

Tôi không muốn thay thế những năng lực ấy bằng những quy tắc giả vờ rằng thế giới đơn giản hơn thực tế.

Nhưng tôi muốn giảm số lượng quyết định đã có thể được cấu trúc hóa mà vẫn tiếp tục phụ thuộc vào trí nhớ hoặc sự hiện diện của một vài người.

Một tổ chức trưởng thành không nhất thiết phải có nhiều người xuất sắc hơn.

Nó cần có khả năng sử dụng tốt hơn những hiểu biết mà người xuất sắc đã tạo ra.

The real leverage of abstraction is the ability to turn individual understanding into shared capability.

Đây là nơi abstraction trở thành một lợi thế cạnh tranh.

Không phải vì doanh nghiệp sở hữu nhiều thuật toán hơn.

Mà vì doanh nghiệp có thể chuyển hóa kinh nghiệm thành năng lực vận hành nhanh hơn.

Và khi một vấn đề mới xuất hiện, tổ chức không nhất thiết phải học lại mọi thứ từ đầu.

10. Đừng đánh giá abstraction bằng số dòng code đã tiết kiệm.

Trong Software Engineering, chúng ta đôi khi cảm thấy rất hài lòng khi loại bỏ được những đoạn code lặp lại.

Mười function được gom thành một.

Năm quy trình được chuyển thành một framework.

Một cấu trúc dữ liệu chung thay thế nhiều cấu trúc riêng biệt.

Codebase trở nên ngắn gọn hơn.

Nhưng ít code hơn không tự động đồng nghĩa với thiết kế tốt hơn.

Một abstraction có thể giảm sự lặp lại nhưng làm tăng độ phức tạp trong việc hiểu, sửa đổi và kiểm chứng.

Nó có thể khiến một thay đổi vốn chỉ ảnh hưởng đến một trường hợp giờ đây ảnh hưởng đến toàn bộ hệ thống.

Và một lỗi trong logic chung có thể tạo ra hậu quả trên quy mô lớn hơn nhiều so với một lỗi cục bộ.

Trong doanh nghiệp cũng tương tự.

Một quy trình chung không nhất thiết hiệu quả hơn nhiều quy trình chuyên biệt.

Một chính sách thống nhất không nhất thiết tốt hơn những chính sách được thiết kế cho các nhóm khách hàng có đặc điểm khác nhau.

Một cơ chế ra quyết định tập trung không nhất thiết tốt hơn việc phân quyền rõ ràng theo từng lĩnh vực.

Điều tôi quan tâm không phải chúng ta đã giảm được bao nhiêu quy trình.

Mà là những thay đổi đó có thực sự cải thiện năng lực vận hành hay không.

Nhân viên có thể tự xử lý nhiều tình huống hơn mà vẫn bảo đảm chất lượng quyết định không?

Số lần phải hỏi quản lý có giảm mà không làm gia tăng sai sót không?

Một chính sách mới có thể được triển khai nhanh hơn mà không tạo ra thêm rủi ro không?

Khi một nhân viên nghỉ việc, hệ thống có tiếp tục vận hành ổn định không?

Và khi một vấn đề mới xuất hiện, tổ chức có thể nhận diện và xử lý nó mà không phải tái thiết kế toàn bộ cấu trúc không?

Đó là những kết quả đáng quan tâm.

The best abstraction is not necessarily the most generic one. It is the one that creates the greatest useful leverage at an acceptable cost.

Một thiết kế đơn giản, xử lý tốt một nhóm vấn đề quan trọng có thể giá trị hơn rất nhiều so với một framework hoành tráng cố gắng giải quyết mọi tình huống có thể tưởng tượng.

Điều này đôi khi khá khó chấp nhận với những người thích xây dựng hệ thống.

Bởi vì một framework tổng quát thường đem lại cảm giác thành tựu trí tuệ rất lớn.

Còn một quy tắc kinh doanh đơn giản, được đặt đúng chỗ, có thể chẳng có gì đáng khoe.

Nhưng tôi không điều hành doanh nghiệp để giành giải kiến trúc phần mềm đẹp nhất.

Tôi muốn hệ thống hoạt động.

Một mục tiêu có phần kém lãng mạn.

Nhưng khá hữu ích khi đến ngày trả lương.

11. Một abstraction sai có thể nguy hiểm hơn một trăm quyết định sai.

Có một lý do khiến tôi luôn muốn kiểm chứng kỹ những abstraction quan trọng.

Một quyết định sai của nhân viên thường có phạm vi ảnh hưởng tương đối giới hạn.

Một báo giá sai.

Một đơn hàng sai.

Một khách hàng bị xử lý không phù hợp.

Tất nhiên, có những sai lầm cá nhân rất nghiêm trọng.

Nhưng trong nhiều tình huống thông thường, phạm vi ảnh hưởng vẫn có thể được xác định.

Ngược lại, một abstraction sai có thể được thực thi trên hàng nghìn giao dịch.

Một quy tắc tính phí vận chuyển bỏ qua yếu tố chi phí quan trọng có thể khiến nhiều đơn hàng được xử lý dưới mức hiệu quả kinh tế cần thiết.

Một mô hình đánh giá khách hàng không phân biệt đúng những loại rủi ro có thể tạo ra hàng loạt quyết định tín dụng không phù hợp.

Một hệ thống đề xuất sản phẩm dựa trên những giả định tương thích sai có thể khiến lỗi được lặp lại trên toàn bộ danh mục.

Và điều nguy hiểm là những sai lầm đó có thể rất nhất quán.

Không ai cần cố tình làm sai.

Nhân viên đang tuân thủ quy trình.

Phần mềm đang hoạt động đúng logic.

Báo cáo không xuất hiện lỗi kỹ thuật.

Nhưng kết quả kinh doanh vẫn sai.

Bởi vì vấn đề không nằm ở việc triển khai.

Nó nằm ở mô hình.

Tôi thích phân biệt ba loại sai lầm.

Execution Error — Thực hiện sai một logic đúng.

Model Error — Thực hiện đúng một logic sai.

Objective Error — Tối ưu đúng một mục tiêu không phù hợp.

Loại đầu tiên thường dễ nhận diện hơn.

Chúng ta có một quy định và một hành động vi phạm quy định.

Loại thứ hai nguy hiểm hơn vì mọi người có thể thực hiện đúng những gì hệ thống yêu cầu.

Loại thứ ba còn khó phát hiện hơn nữa.

Bởi vì mô hình có thể hoàn toàn chính xác trong việc tối ưu mục tiêu đã được thiết kế, nhưng mục tiêu đó lại không phản ánh lợi ích thực sự của doanh nghiệp.

Ví dụ, một thuật toán tối ưu chi phí giao hàng có thể làm việc rất tốt.

Chi phí trên mỗi điểm giao giảm.

Tỷ lệ sử dụng phương tiện tăng.

Tuyến giao được sắp xếp hiệu quả.

Nhưng nếu thuật toán không tính đến những cam kết thời gian quan trọng, kết quả có thể khiến trải nghiệm khách hàng xấu đi.

Thuật toán không sai trong việc tối ưu chi phí.

Sai lầm nằm ở việc chúng ta đã định nghĩa bài toán chưa đầy đủ.

A perfectly optimized wrong objective is still a wrong outcome.

Đây là lý do người thiết kế hệ thống phải hiểu kinh doanh đủ sâu để không chỉ hỏi:

"Mô hình này có hoạt động đúng không?"

Mà còn phải hỏi:

"Chúng ta có đang mô hình hóa đúng vấn đề cần giải quyết hay không?"

Một câu hỏi khó hơn nhiều.

Và không có unit test nào có thể tự động trả lời đầy đủ.

12. Abstraction không phải tài năng tạo ra những mô hình ngày càng phức tạp.

Tôi nghĩ có một sự hiểu lầm về những người có khả năng tư duy trừu tượng tốt.

Chúng ta thường tưởng tượng họ là những người có thể tạo ra các mô hình cực kỳ phức tạp.

Hàng trăm biến số.

Hàng chục mối quan hệ.

Những sơ đồ mà người bình thường nhìn vào chỉ thấy một đống hình chữ nhật và mũi tên.

Tôi không cho rằng độ phức tạp của mô hình là thước đo năng lực abstraction.

Thực ra, đôi khi điều ngược lại mới đúng.

Một người chưa hiểu rõ vấn đề có thể cần rất nhiều quy tắc để mô tả nó.

Một người hiểu sâu hơn có thể nhận ra những quy tắc đó chỉ là biểu hiện của một vài nguyên lý chung.

Nhưng tôi cũng không muốn thần thánh hóa sự đơn giản.

Có những hệ thống thực sự phức tạp.

Và cố gắng ép chúng vào một mô hình quá đơn giản có thể khiến những khác biệt quan trọng bị bỏ qua.

Vì vậy, mục tiêu không phải là tạo ra mô hình có ít thành phần nhất.

Mà là tạo ra mô hình đơn giản nhất vẫn giữ được những thông tin cần thiết để đưa ra quyết định đúng.

Điều này đòi hỏi khả năng phân biệt.

Điều gì là bản chất?

Điều gì là ngẫu nhiên?

Điều gì chỉ là cách vấn đề biểu hiện trong một bối cảnh cụ thể?

Và điều gì sẽ tiếp tục đúng khi bối cảnh thay đổi?

Đây không phải công việc chỉ cần học một vài design patterns.

Nó đòi hỏi kiến thức nền tảng, kinh nghiệm thực tế, khả năng phân tích và sự kiên nhẫn với những trường hợp chưa phù hợp với mô hình.

Đôi khi phải quan sát rất lâu trước khi một cấu trúc trở nên rõ ràng.

Đôi khi phải thử nhiều giả thuyết.

Đôi khi một ngoại lệ nhỏ khiến toàn bộ cách hiểu trước đó phải thay đổi.

Và đôi khi chúng ta phải chấp nhận rằng mình chưa đủ thông tin để xây dựng một abstraction đáng tin cậy.

Tôi không xem việc trì hoãn một abstraction là thất bại.

Có những vấn đề nên được xử lý riêng lẻ trong một thời gian để chúng ta hiểu rõ hơn về bản chất của chúng.

Một abstraction được xây dựng quá sớm có thể trở thành một khoản technical debt rất đắt.

Đặc biệt khi cả hệ thống bắt đầu phụ thuộc vào nó.

Premature abstraction can be more expensive than temporary duplication.

Một chút lặp lại đôi khi dễ chịu hơn rất nhiều so với một cấu trúc chung được xây dựng dựa trên những giả định chưa đúng.

Đây là điều mà người trẻ thích viết framework có thể không muốn nghe.

Tôi hiểu.

Ngày xưa tôi cũng thích xây những thứ thật tổng quát.

Bây giờ tôi vẫn thích.

Chỉ là đã bắt đầu biết sợ hậu quả hơn một chút.

13. Từ khả năng nhìn thấy cấu trúc đến khả năng thiết kế tương lai.

Trong Part I, chúng ta đã bàn về khả năng nhìn thấy những mối liên hệ ẩn sau các sự kiện.

Nhưng nhận diện cấu trúc và thiết kế cấu trúc là hai năng lực khác nhau.

Một người có thể phân tích rất chính xác tại sao một tổ chức liên tục gặp vấn đề.

Họ có thể nhận diện những điểm phụ thuộc, những cơ chế khuyến khích sai lệch và những quy trình tạo ra ngoại lệ.

Nhưng điều đó chưa bảo đảm họ có thể thiết kế một hệ thống tốt hơn.

Bởi vì phân tích quá khứ và thiết kế tương lai có những yêu cầu khác nhau.

Khi phân tích, chúng ta có thể quan sát những kết quả đã xảy ra.

Khi thiết kế, chúng ta phải dự đoán những hành vi có thể xuất hiện từ một cấu trúc chưa tồn tại.

Chúng ta phải tự hỏi:

Nếu thay đổi quyền hạn, con người sẽ phản ứng ra sao?

Nếu tự động hóa một bước kiểm soát, liệu có xuất hiện cách lách quy trình mới?

Nếu thay đổi cơ chế thưởng, nhân viên sẽ tối ưu hành vi theo hướng nào?

Nếu loại bỏ một bước phê duyệt, rủi ro có được chuyển sang nơi khác không?

Nếu đưa ra một quy tắc chung, những trường hợp nào có thể bị xử lý không phù hợp?

Đây là lý do tôi cho rằng thiết kế hệ thống là một công việc vừa mang tính kỹ thuật, vừa mang tính thực nghiệm.

Chúng ta không chỉ định nghĩa cấu trúc.

Chúng ta đưa ra giả thuyết về hành vi của cấu trúc đó trong tương lai.

Sau đó triển khai, quan sát và điều chỉnh.

Một abstraction tốt phải có khả năng được kiểm chứng.

Một kiến trúc tốt phải có khả năng được thay đổi.

Và một người thiết kế tốt phải chấp nhận rằng những quyết định của mình có thể tạo ra tác dụng phụ mà ban đầu họ chưa dự đoán được.

Tôi thích nghĩ rằng công việc của mình không phải tạo ra một hệ thống hoàn hảo.

Mà là xây dựng một hệ thống ngày càng có khả năng hiểu và cải thiện chính nó.

Trong đó, mỗi vấn đề mới không mặc nhiên dẫn đến thêm một quy định.

Mỗi ngoại lệ không mặc nhiên dẫn đến thêm một bước phê duyệt.

Và mỗi thất bại không mặc nhiên dẫn đến việc tìm một người để chịu trách nhiệm.

Thay vào đó, chúng ta xem xét liệu vấn đề có cho thấy một giới hạn của mô hình hiện tại hay không.

Nếu có, chúng ta cải thiện mô hình.

Nếu chưa đủ bằng chứng, chúng ta tiếp tục quan sát.

Và nếu chỉ là một biến động không đáng kể, chúng ta không cần biến nó thành một cuộc cách mạng về kiến trúc.

Khả năng không làm gì khi không cần thiết cũng là một phần của thiết kế tốt.

Mặc dù nó không tạo ra nhiều thứ để đưa vào báo cáo thành tích.

14. Người thiết kế giỏi nhất không nên là người phải trả lời nhiều câu hỏi nhất.

Tôi muốn quay lại với hình ảnh ban đầu.

Một nhân viên đến hỏi:

"Anh ơi, trường hợp này xử lý sao?"

Người quản lý xem xét.

Đưa ra câu trả lời.

Công việc tiếp tục.

Nếu tình huống đó thực sự mới, tôi không có vấn đề gì với việc phải tham gia.

Ngược lại, tôi thích những câu hỏi mới.

Chúng có thể chỉ ra một cơ hội, một rủi ro hoặc một cấu trúc mà tổ chức chưa nhận diện.

Nhưng nếu câu hỏi đó đã được đặt ra hàng trăm lần, tôi muốn biết tại sao nó vẫn cần được đưa đến mình.

Có phải nhân viên chưa có đủ thông tin?

Có phải quyền hạn chưa rõ?

Có phải chính sách chưa được định nghĩa?

Hay có một abstraction quan trọng mà chúng ta chưa xây dựng?

Tôi muốn dùng khả năng của mình để giải quyết những điều chưa có lời giải.

Không phải trở thành một thư viện sống chuyên trả lời những câu hỏi đã được giải quyết.

Tôi muốn người mới có thể nhanh chóng hiểu cách ra quyết định trong phạm vi công việc.

Người có kinh nghiệm có thể tự chủ hơn.

Người xuất sắc có thể tập trung vào những tình huống thực sự đòi hỏi năng lực đặc biệt.

Và tổ chức có thể tiếp tục hoạt động khi một vài người quan trọng không có mặt.

Điều này không có nghĩa mọi quyết định phải được tự động hóa.

Nó có nghĩa những quyết định đã hiểu rõ nên được chuyển hóa thành năng lực chung ở mức độ hợp lý.

Tôi không cần mọi nhân viên trở thành một Software Architect.

Nhưng tôi muốn những gì được thiết kế trong hệ thống giúp họ đưa ra quyết định tốt hơn.

Tôi không cần mọi quản lý có cùng khả năng abstraction.

Nhưng tôi muốn những hiểu biết quan trọng có thể được diễn đạt, kiểm chứng và sử dụng bởi nhiều người.

Và tôi không cần xây dựng một doanh nghiệp không bao giờ gặp vấn đề mới.

Thực ra, điều đó nghe khá nhàm chán.

Tôi muốn những vấn đề mới tiếp tục xuất hiện.

Bởi vì chúng là dấu hiệu cho thấy tổ chức đang tiếp xúc với những giới hạn mới của thị trường, năng lực và mô hình kinh doanh.

Điều tôi không muốn là phải liên tục giải quyết những vấn đề cũ chỉ vì chúng ta chưa từng biến hiểu biết của mình thành một cơ chế có thể tái sử dụng.

The goal is not to eliminate thinking. It is to stop wasting thinking on problems that have already been understood.

Đó là cách tôi nhìn nhận giá trị sâu xa của abstraction.

Không phải làm cho con người suy nghĩ ít đi.

Mà là giải phóng năng lực tư duy để họ có thể giải quyết những vấn đề có giá trị cao hơn.

Lời kết: Abstraction Is a Superpower.

Tôi không cho rằng abstraction là một năng lực thần bí.

Nó không khiến người sở hữu trở nên đúng trong mọi tình huống.

Không thay thế kiến thức chuyên môn.

Không miễn trừ trách nhiệm kiểm chứng.

Và chắc chắn không bảo đảm rằng mọi cấu trúc được tạo ra đều có giá trị.

Nhưng khi được sử dụng đúng, nó là một dạng đòn bẩy trí tuệ rất mạnh.

Một người có thể giải quyết một vấn đề.

Một quy trình có thể giúp nhiều người giải quyết cùng loại vấn đề.

Một abstraction tốt có thể trở thành nền tảng để giải quyết cả một nhóm vấn đề có chung cấu trúc.

Và một kiến trúc được xây dựng từ những abstraction phù hợp có thể tạo ra năng lực vận hành vượt xa khả năng xử lý trực tiếp của từng cá nhân.

Đó là điều khiến tôi hứng thú.

Không phải vì tôi muốn viết nhiều phần mềm hơn.

Mà vì tôi muốn một phần năng lực tư duy của con người có thể được chuyển hóa thành những cơ chế tiếp tục tạo ra giá trị khi người đó không còn trực tiếp tham gia.

Tôi muốn những kiến thức đã được khám phá không phải liên tục được khám phá lại.

Những sai lầm đã được hiểu không phải liên tục được giải thích lại.

Những quyết định đã có nguyên lý rõ ràng không phải liên tục được đưa đến cùng một người.

Và những con người có khả năng tạo ra ý tưởng mới không phải dành phần lớn thời gian để duy trì những thứ đã cũ.

Nhưng tôi cũng hiểu rằng một abstraction càng được sử dụng rộng, trách nhiệm của người thiết kế càng lớn.

Một nguyên lý đúng có thể giúp hàng nghìn người ra quyết định tốt hơn.

Một nguyên lý sai cũng có thể khiến hàng nghìn người ra quyết định sai theo cùng một cách.

Vì vậy, khả năng abstraction phải đi cùng một phẩm chất mà tôi cho rằng không thể thiếu trong kỹ thuật.

Intellectual Humility.

Sự khiêm tốn trước những điều mình chưa hiểu.

Không phải sự khiêm tốn mang tính hình thức.

Không phải lúc nào cũng phải nói rằng mình có thể sai để tỏ ra cầu thị.

Mà là khả năng thực sự thay đổi mô hình khi dữ liệu cho thấy nó không còn đúng.

Một người thiết kế có thể rất tự tin vào lập luận của mình.

Nhưng mô hình phải có khả năng bị kiểm chứng.

Giả định phải có khả năng bị phản biện.

Và kiến trúc phải có khả năng tiến hóa.

Tôi nghĩ đó mới là cách sử dụng abstraction một cách có trách nhiệm.

Abstraction is a superpower. But every superpower amplifies both competence and stupidity.

Nó khuếch đại năng lực.

Và cũng khuếch đại sự ngu ngốc.

Một người đưa ra quyết định sai có thể gây ra một vấn đề.

Một người xây dựng abstraction sai có thể tạo ra một cỗ máy sản xuất vấn đề với hiệu suất công nghiệp.

Đây là một trách nhiệm không nhỏ.

Đặc biệt khi người đó vừa là Software Engineer, vừa là người điều hành doanh nghiệp.

Bởi vì lúc ấy, anh ta có đủ khả năng kỹ thuật để triển khai ý tưởng.

Và đủ quyền lực để bắt cả tổ chức sử dụng nó.

Một sự kết hợp rất đáng sợ.

Nhất là khi anh ta còn cực kỳ tin tưởng vào khả năng thiết kế của mình.

Vì vậy, trước khi tự hào rằng mình vừa tìm thấy một abstraction có thể giải quyết một trăm vấn đề, tôi nghĩ chúng ta nên đặt thêm một câu hỏi.

Nếu abstraction này sai, nó có thể khiến bao nhiêu người cùng sai theo?

Nếu chưa trả lời được, có lẽ chúng ta chưa nên vội triển khai nó cho toàn bộ tổ chức.

Còn nếu đã kiểm chứng đủ tốt, hiểu rõ những giới hạn và thiết kế được cơ chế để nó tiếp tục học hỏi?

Khi đó, chúng ta có thể bắt đầu làm một điều thú vị.

Trao cho con người nhiều quyền tự chủ hơn.

Không phải bằng cách loại bỏ mọi giới hạn.

Mà bằng cách thiết kế những giới hạn đủ thông minh để họ có thể tự tin ra quyết định trong phạm vi của mình.

Và đó chính là chủ đề tiếp theo.

Bởi vì một khi đã có khả năng chuyển hóa những nguyên lý thành cơ chế, câu hỏi quan trọng không còn chỉ là chúng ta có thể kiểm soát được những gì.

Mà là:

Làm thế nào để kiểm soát những điều thực sự cần kiểm soát, trong khi vẫn giải phóng tối đa năng lực của con người?

Một bài toán vừa mang tính kiến trúc, vừa mang tính quản trị.

Và nếu làm sai, chúng ta sẽ xây dựng được một hệ thống cực kỳ an toàn.

An toàn đến mức không ai được phép làm cái quái gì cả.

Congratulations. You have successfully engineered a prison.

NEXT CHAPTER — GUARDRAILS, NOT HANDCUFFS

Tự do trong khuôn khổ: làm thế nào để thiết kế một tổ chức có thể trao quyền cho con người mà không đánh mất khả năng kiểm soát?

The Architect of Chaos — Ông Chú Hay Chửi