Harvard Business Review từ chối bài của Melvin Conway vì thiếu bằng chứng. Luận điểm ấy thành định luật Conway.

17/10/2026 · VietTechies · Biên tập

Năm 1967, Melvin Conway gửi cho tạp chí Harvard Business Review (HBR) một bài báo lập luận rằng hệ thống do một tổ chức thiết kế rốt cuộc sẽ sao chép lại cách những người trong tổ chức ấy giao tiếp với nhau — ý tưởng mà nay được gọi là định luật Conway (Conway’s law). Tạp chí từ chối đăng. Sau này, Conway viết trên trang web cá nhân: “HBR từ chối bài này với lý do tôi chưa chứng minh được luận điểm của mình.”

Vậy là ông gửi bài sang Datamation — “tạp chí công nghệ thông tin hàng đầu thời bấy giờ”, như ông mô tả. Bài báo được đăng vào tháng 4 năm 1968 với nhan đề “How Do Committees Invent?” (tạm dịch: Các ủy ban phát minh như thế nào?). Bảy năm sau, Fred Brooks trích dẫn bài báo này trong cuốn sách The Mythical Man-Month và gọi luận điểm của bài là “định luật Conway”. Theo lời Conway: “Cái tên ấy được dùng luôn từ đó.”

Bốn thập niên sau khi bài báo bị từ chối, các nhà nghiên cứu đem ý tưởng này ra kiểm chứng trên phần mềm thật. Một trong các nghiên cứu ấy đến từ Trường Kinh doanh Harvard (Harvard Business School).

Tám người, hai trình biên dịch

Bài báo bảo vệ luận điểm bằng một ví dụ nhỏ, liên quan đến hai ngôn ngữ lập trình thời ấy: COBOL, dành cho các chương trình kinh doanh, và ALGOL, dành cho các chương trình toán học và khoa học. Conway viết: “Ở một tổ chức nhận nghiên cứu theo hợp đồng, có tám người phải làm ra một trình biên dịch (compiler) COBOL và một trình biên dịch ALGOL. Sau vài ước tính ban đầu về độ khó và thời gian, năm người được phân công làm phần COBOL và ba người làm phần ALGOL. Kết quả là trình biên dịch COBOL chạy qua năm giai đoạn, còn trình biên dịch ALGOL chạy qua ba giai đoạn.”

Mỗi giai đoạn (phase) là một khâu trong công việc của trình biên dịch, làm xong thì chuyển kết quả sang giai đoạn kế tiếp. Năm người, năm giai đoạn. Ba người, ba giai đoạn. Ý khái quát của Conway là: “bản thân việc tổ chức một nhóm thiết kế có nghĩa là một số quyết định thiết kế đã được đưa ra rồi.” Các ví dụ của ông không dừng lại ở trình biên dịch: “Hai quân chủng được Tổng tư lệnh chỉ thị phát triển một hệ thống vũ khí chung, đáp ứng nhu cầu riêng của mỗi bên. Sau bao công sức, họ làm ra một bản sao sơ đồ tổ chức của mình.”

Để mô tả mối liên hệ giữa nhóm và hệ thống, Conway mượn một thuật ngữ toán học. Trong mô hình của ông, một hệ thống là tập hợp các hệ thống con, còn gọi là các nút, nối với nhau bằng những nhánh; các hệ thống con giao tiếp với nhau qua những nhánh ấy. Ở đâu có hai nút nối với nhau, ở đó các nhóm thiết kế làm ra hai nút ấy “hẳn đã phải thương lượng và thống nhất” về cách kết nối. Ông viết: “Kiểu quan hệ bảo toàn cấu trúc như thế giữa hai tập hợp sự vật được gọi là phép đồng cấu (homomorphism).”

Bản in năm 1968 phát biểu luận điểm này như sau: “các tổ chức thiết kế hệ thống (theo nghĩa rộng dùng ở đây) bị ràng buộc phải tạo ra những thiết kế là bản sao cấu trúc giao tiếp của các tổ chức ấy.”

Conway khuyên các nhà quản lý làm gì

Tiêu chí mà bài báo đưa ra cho các nhà quản lý là: “công việc thiết kế nên được tổ chức theo nhu cầu giao tiếp.” Conway lập luận rằng vì “thiết kế nảy ra đầu tiên hầu như không bao giờ là thiết kế tốt nhất có thể”, ý tưởng chủ đạo về hệ thống có thể cần thay đổi, nên “tính linh hoạt của tổ chức là yếu tố quan trọng để thiết kế hiệu quả”. Khi tóm lược ý này trong The Mythical Man-Month, Brooks viết rằng “ban đầu, sơ đồ tổ chức sẽ phản ánh thiết kế hệ thống đầu tiên, vốn gần như chắc chắn không phải là thiết kế đúng”.

Conway cũng dè chừng những nhóm thiết kế đông người. Ông lưu ý rằng số kênh giao tiếp có thể có trong một tổ chức là “xấp xỉ một nửa bình phương số người”, nên nhóm đông gấp đôi thì số kênh tăng lên khoảng gấp bốn. Ông kêu gọi một triết lý quản lý “không dựa trên giả định rằng thêm nhân lực thì năng suất cứ thế tăng thêm”. Đề xuất của ông: “Phải tìm ra cách khen thưởng những nhà quản lý thiết kế biết giữ cho tổ chức của mình gọn nhẹ và linh hoạt.”

Các nhà nghiên cứu sau này kiểm chứng định luật Conway ra sao

Trong một bản thảo nghiên cứu (working paper) của Trường Kinh doanh Harvard, về sau được đăng trên tạp chí Research Policy năm 2012, Alan MacCormack, John Rusnak và Carliss Baldwin so sánh từng cặp sản phẩm phần mềm có chức năng tương tự nhau. Trong mỗi cặp, một sản phẩm đến từ một tổ chức liên kết lỏng (loosely coupled), chẳng hạn một cộng đồng mã nguồn mở gồm những người đóng góp phân tán ở nhiều nơi, còn sản phẩm kia đến từ một tổ chức liên kết chặt, chẳng hạn một nhóm phát triển phần mềm thương mại. Nếu Conway đúng, code do các tổ chức liên kết lỏng làm ra sẽ có tính mô-đun cao hơn. Để kiểm tra, các tác giả đo “chi phí lan truyền” (propagation cost) của mã nguồn từng sản phẩm: tính trung bình, một thay đổi ở một tệp có thể ảnh hưởng tới bao nhiêu phần trăm hệ thống, trực tiếp hoặc thông qua các tệp khác.

Các tác giả tóm tắt: “Ở tất cả các cặp chúng tôi khảo sát, sản phẩm do tổ chức liên kết lỏng phát triển đều có tính mô-đun cao hơn đáng kể so với sản phẩm của tổ chức liên kết chặt.” Với cặp phần mềm tài chính, trung bình một thay đổi ở một tệp có thể lan tới 7,74% hệ thống ở phần mềm mã nguồn mở GnuCash, so với 47,14% ở một sản phẩm thương mại mà các tác giả gọi là MyBooks.

Nachiappan Nagappan và Brendan Murphy ở Microsoft Research, cùng Victor Basili ở Đại học Maryland, đặt ra một câu hỏi liên quan, lấy Windows Vista làm đối tượng: cấu trúc của một tổ chức có dự báo được chất lượng phần mềm mà tổ chức ấy làm ra hay không? Với 3.404 tệp nhị phân (binary) — những tệp đã qua biên dịch hợp thành hệ thống — nhóm tác giả tính tám chỉ số về tổ chức đứng sau phần code, chẳng hạn bao nhiêu kỹ sư từng chỉnh sửa mỗi tệp và bao nhiêu người trong số đó đã rời công ty. Một mô hình dựa trên các chỉ số này đã dự đoán những tệp nào sẽ tỏ ra dễ phát sinh lỗi sau khi phát hành: trong số các tệp bị mô hình đánh dấu, 86,2% đúng là dễ phát sinh lỗi (chỉ số precision), và mô hình phát hiện được 84,0% số tệp dễ phát sinh lỗi (chỉ số recall). Một mô hình dựa trên lượng mã nguồn bị thay đổi (code churn) đạt lần lượt 78,6% và 79,9%.

Cả hai nghiên cứu đều có giới hạn. Nghiên cứu của Harvard so sánh năm cặp sản phẩm, còn nghiên cứu về Vista xét một hệ điều hành của một công ty. Không nghiên cứu nào có thể cho thấy quan hệ nhân quả.

Các bản kể phổ biến khác với tư liệu ở điểm nào

FOLDOC, một từ điển tin học trực tuyến lâu năm, ghi rằng định luật thường được phát biểu là: “Nếu có bốn nhóm cùng làm một trình biên dịch, bạn sẽ có một trình biên dịch 4 lượt.” Ví dụ Conway thật sự đưa ra có tám người, chia thành nhóm năm người và nhóm ba người, và tính theo giai đoạn (phase) chứ không phải theo lượt (pass).

Brooks cũng không phải người đầu tiên dùng cái tên này. Theo một bài tiểu sử về Larry Constantine do IEEE Computer Society — hội chuyên ngành máy tính của Viện Kỹ sư Điện và Điện tử (IEEE) — công bố, định luật này “được George Mealy đặt tên” tại Hội thảo quốc gia về lập trình mô-đun (National Symposium on Modular Programming) vào tháng 7 năm 1968, ba tháng sau khi bài báo được đăng.

Vì sao cách chia việc ban đầu lại quan trọng

Ví dụ về hai trình biên dịch là phần mà các nhóm ngày nay có thể vận dụng. Chuyện ai làm phần nào thường được quyết định từ sớm, vào lúc hiểu biết về thiết kế còn ít nhất, và đó là một quyết định thiết kế, dù có ai gọi nó như vậy hay không. Theo cách Conway lý giải, ranh giới giữa các nhóm có xu hướng trở thành giao diện (interface) trong hệ thống, vì đó là nơi con người phải thương lượng với nhau.

Đó cũng là lý do Conway kêu gọi tổ chức linh hoạt, chứ không đòi một kế hoạch ban đầu hoàn hảo. Theo lập luận của ông, thiết kế đầu tiên hầu như không bao giờ là phương án tốt nhất, và một tổ chức đã đóng khung quanh thiết kế đầu tiên sẽ tiếp tục làm ra đúng thiết kế ấy. Ai trao đổi với ai từ ngày đầu chính là bản nháp đầu tiên của kiến trúc hệ thống.

Harvard Business Review muốn có bằng chứng. Bốn thập niên sau, một phần bằng chứng đến từ Trường Kinh doanh Harvard. Bài báo từng bị từ chối kia vốn đã cho thấy khuôn mẫu ấy ở quy mô thu nhỏ: năm người, năm giai đoạn; ba người, ba giai đoạn.

Bài liên quan

Đọc bằng ngôn ngữ khác: English