Có câu chuyện kể rằng tại một công ty, ba nhóm cùng làm một chương trình, rồi chương trình hoàn thiện lại chia thành đúng ba khối. Chẳng ai quyết định phải làm như vậy, nhưng cách phân chia các nhóm đã trở thành hình hài của phần mềm.
Nhận xét rằng cấu trúc giao tiếp của tổ chức thiết kế hệ thống được phản ánh nguyên vẹn trong cấu trúc của chính hệ thống ấy được gọi là “định luật Conway (Conway's Law)”. Trong giới lập trình viên, định luật này cũng thường được nhắc đến qua câu nói: “Nhìn sơ đồ tổ chức là thấy cấu trúc phần mềm”.
Trong tài liệu này, chúng ta sẽ lần lượt tìm hiểu định luật Conway bắt nguồn từ đâu, vì sao hiện tượng này xảy ra, nó biểu hiện như thế nào trong thực tế và cả cách vận dụng ngược định luật này.
Tìm hiểu định luật Conway
Định luật Conway bắt nguồn từ đâu?
Tên gọi của định luật này bắt nguồn từ nhà khoa học máy tính người Mỹ Melvin Conway. Năm 1967, ông viết bài “Các ủy ban phát minh như thế nào? (How Do Committees Invent?)”; sau khi không được một tạp chí quản trị đăng tải, bài viết đã được đăng trên tạp chí máy tính Datamation vào năm 1968.
Trong bài viết, Conway lập luận rằng “một tổ chức thiết kế hệ thống tất yếu sẽ tạo ra thiết kế mô phỏng nguyên vẹn cấu trúc giao tiếp của tổ chức đó”. Ở đây, hệ thống không chỉ giới hạn ở phần mềm mà còn chỉ rộng ra mọi thứ con người cùng nhau thiết kế.
Người phổ biến rộng rãi ý tưởng này dưới tên gọi “định luật Conway” là Frederick Brooks. Năm 1975, ông giới thiệu nhận xét này trong cuốn “Huyền thoại tháng-người (The Mythical Man-Month)”, được xem là một tác phẩm kinh điển về phát triển phần mềm; từ đó, định luật Conway dần trở thành kiến thức phổ biến trong thực tiễn phát triển phần mềm.
Vì sao hình thái tổ chức lại phản ánh trong thiết kế?
Vì một người không thể tự mình xây dựng một hệ thống lớn, nhiều người và nhiều nhóm phải chia nhau đảm nhận công việc. Khi phân chia công việc, họ phải xác định những điểm các phần khớp nối với nhau, tức là các phần kết nối; muốn xác định những phần kết nối này, những người phụ trách phải trao đổi với nhau.
Tuy nhiên, việc trao đổi giữa người với người không diễn ra như nhau ở mọi nơi. Trong cùng một nhóm, mọi người có thể hỏi và sửa bất cứ lúc nào, nhưng với nhóm khác hoặc phòng ban khác, họ phải sắp xếp cuộc họp và trao đổi tài liệu. Vì thế, những nơi dễ trao đổi sẽ được gắn kết chặt chẽ thành một khối, còn những nơi khó trao đổi sẽ bị chia cắt bởi các ranh giới cứng nhắc.
Cuối cùng, ranh giới của hệ thống thường được vạch theo những vị trí thuận tiện cho việc giao tiếp hơn là những vị trí phù hợp nhất về mặt kỹ thuật. Định luật Conway gần với một kết quả tự nhiên do cách làm việc cùng nhau tạo ra hơn là một vấn đề nảy sinh vì người thiết kế thiếu quyết tâm.
Theo thời gian, những ranh giới này càng trở nên vững chắc. Mỗi phần sau khi được phân chia đều có một nhóm phụ trách, và vì nhóm nào cũng muốn giữ phần của mình nên muốn thay đổi cấu trúc thì phải thay đổi cả tổ chức. Vì vậy mới có nhận định rằng hệ thống càng lâu đời thì càng lưu giữ dấu vết những lần tái cơ cấu mà công ty đã trải qua, giống như các hóa thạch.
Những biểu hiện của định luật Conway
Một ví dụ thường gặp là website công ty. Người truy cập nghĩ rằng mình đang xem website của một công ty, nhưng khi chuyển qua các mục trong trình đơn, họ thường thấy mỗi phòng ban có thiết kế và giọng văn khác nhau. Đó là vì website được xây dựng theo cách phân chia phòng ban trong công ty thay vì theo nhu cầu của khách hàng.
Hiện tượng tương tự cũng xảy ra ở những dự án lớn có nhiều công ty cùng tham gia. Khi mỗi đơn vị tự xây dựng phần mình phụ trách, từng phần có thể hoạt động tốt, nhưng tại những chỗ kết nối với nhau thường xuất hiện vấn đề như định dạng dữ liệu không tương thích hoặc cùng một chức năng bị xây dựng hai lần. Càng nhiều ranh giới thì thời gian và chi phí để lấp đầy những khoảng trống ấy cũng càng tăng.
Định luật này cũng đã được xác nhận qua nghiên cứu. Năm 2012, các nhà nghiên cứu tại Trường Kinh doanh Harvard ở Mỹ đã so sánh các phần mềm có cùng chức năng và công bố kết quả cho thấy sản phẩm do các lập trình viên mã nguồn mở phân tán ở nhiều nơi tạo ra có cấu trúc được chia nhỏ hơn so với sản phẩm do các nhóm trong công ty làm việc tập trung, gắn bó chặt chẽ tạo ra. Các nhà nghiên cứu xem đây là bằng chứng cho “giả thuyết tấm gương”, theo đó tổ chức và sản phẩm mang dáng dấp của nhau.
Vận dụng ngược định luật Conway
Nếu không thể tránh định luật Conway, ta cũng có thể tổ chức đội ngũ trước sao cho phù hợp với thiết kế mong muốn. Cách làm này được gọi là “chiến lược Conway đảo ngược (Inverse Conway Maneuver)” và đã được thảo luận rộng rãi trong ngành phần mềm từ thập niên 2010.
Chẳng hạn, nếu muốn chia dịch vụ thành các đơn vị nhỏ độc lập, ta có thể lập các nhóm nhỏ riêng biệt, mỗi nhóm chịu trách nhiệm về một đơn vị từ đầu đến cuối. Câu chuyện Amazon nhấn mạnh quy mô nhóm đủ nhỏ để chỉ cần hai chiếc pizza là đủ cho một bữa ăn cũng gắn liền với ý tưởng này.
Tuy nhiên, thay đổi tổ chức không có nghĩa là mọi vấn đề sẽ tự động được giải quyết. Nếu chia nhóm quá nhỏ, nhu cầu phối hợp giữa các nhóm có thể còn tăng lên, vì vậy cần liên tục xem xét đồng thời cả cấu trúc hệ thống lẫn cơ cấu nhân sự.
Định luật Conway nhắc nhở chúng ta rằng đằng sau những việc có vẻ là vấn đề kỹ thuật còn ẩn chứa vấn đề con người. Muốn xây dựng một hệ thống tốt, ta cần xem xét không chỉ mã nguồn mà trước hết còn cả cách những người viết mã giao tiếp với nhau.
Trước hết nhìn lại cách chúng ta cùng làm việc chính là bước đầu tiên để xây dựng một hệ thống tốt hơn.
