Khi hạn chót đã cận kề mà công việc vẫn còn tồn đọng nhiều, ai cũng có suy nghĩ tương tự: liệu thêm người có giúp hoàn thành công việc nhanh hơn không? Bởi rõ ràng có những việc càng nhiều người làm càng mau xong, chẳng hạn như chuyển đồ khi dọn nhà hay cày ruộng.
Thế nhưng trong phát triển phần mềm, điều ngược lại lại thường xuyên xảy ra. Thêm người vào một dự án vốn đã chậm tiến độ sẽ khiến tiến độ càng chậm hơn. Quy luật đúc kết từ kinh nghiệm này được gọi là “định luật Brooks (Brooks's Law)”, theo tên người đầu tiên hệ thống hóa nó.
Tài liệu này lần lượt trình bày bối cảnh ra đời của định luật Brooks và ngộ nhận ẩn sau đơn vị người-tháng, lý do thêm người vẫn không nhanh hơn và cách tính số kênh giao tiếp gia tăng, cùng những cách tránh tác động của định luật và các giới hạn của nó.
Nguyên lý và ứng dụng của định luật Brooks
Sự ra đời của định luật và ngộ nhận về người-tháng
Frederick P. Brooks Jr. là nhà khoa học máy tính đã lãnh đạo việc phát triển máy tính lớn System/360 và hệ điều hành OS/360 của nó tại IBM ở Mỹ vào thập niên 1960. OS/360 là một trong những dự án phần mềm lớn nhất thời bấy giờ, và dù có rất nhiều lập trình viên tham gia, tiến độ vẫn liên tục bị chậm.
Dựa trên trải nghiệm ấy, Brooks xuất bản cuốn “Huyền thoại người-tháng (The Mythical Man-Month)” vào năm 1975. Trong cuốn sách, ông viết: “Bổ sung nhân lực cho một dự án phần mềm đang chậm tiến độ sẽ khiến nó càng chậm hơn (Adding manpower to a late software project makes it later)”, và câu nói này về sau được gọi là định luật Brooks.
Người-tháng (Man-Month) là đơn vị chỉ khối lượng công việc mà một người thực hiện trong một tháng. Với một công việc có khối lượng 10 người-tháng, cách tính này cho rằng một người có thể hoàn thành trong mười tháng, hoặc mười người có thể hoàn thành trong một tháng. Brooks chỉ ra rằng phép tính ấy chỉ đúng khi công việc có thể được chia đều mà không cần trao đổi với nhau, và bản thân suy nghĩ có thể hoán đổi số người với số tháng đã là một ngộ nhận.
Dù nửa thế kỷ đã trôi qua, cuốn sách này vẫn được xem là một tác phẩm kinh điển của ngành kỹ nghệ phần mềm. Ấn bản kỷ niệm 20 năm ra mắt vào năm 1995 còn có bài viết “Không có viên đạn bạc (No Silver Bullet)”, với nội dung rằng không tồn tại phương pháp thần kỳ nào có thể ngay lập tức nâng cao năng suất một cách vượt bậc. Brooks được trao giải Turing (Turing Award) vào năm 1999 nhờ những đóng góp cho kiến trúc máy tính và kỹ nghệ phần mềm.
Vì sao thêm người vẫn không nhanh hơn
Khi đưa người mới vào một dự án chậm tiến độ, thoạt nhìn có vẻ như lực lượng làm việc đã tăng lên. Nhưng trên thực tế, tiến độ dễ bị chậm thêm vì những lý do sau.
(1) Cần thời gian để làm quen
Người mới phải tìm hiểu cấu trúc dự án, những quyết định đã được đưa ra và cách thức làm việc thì mới có thể đảm đương phần việc của mình. Trong thời gian đó, các thành viên hiện tại phải tạm dừng công việc để hướng dẫn người mới, nên trong vài tuần đầu, tốc độ chung trái lại còn giảm xuống.
(2) Có những việc không thể chia nhỏ
Một số công việc phải trải qua các bước theo trình tự cố định dù có thêm bao nhiêu người đi nữa. Brooks giải thích điều này bằng câu nói: “Sinh một đứa trẻ cần chín tháng. Dù bố trí bao nhiêu phụ nữ thì cũng vậy.”
(3) Công việc phối hợp tăng lên
Càng chia nhỏ công việc, càng có thêm nhiều việc phải làm để ghép các phần lại với nhau, kiểm tra xem chúng có khớp nhau không và thống nhất cách hiểu. Càng nhiều người, thời gian dành cho việc điều phối này càng tăng nhanh.
Khi ba yếu tố này cùng xuất hiện, kế hoạch tiến độ ban đầu đã đổ vỡ trước khi người mới bắt đầu đảm đương được phần việc của mình. Vì thế, nỗ lực bù đắp công việc chậm trễ bằng số lượng người thường dẫn đến sự chậm trễ lớn hơn.
Cách tính số kênh giao tiếp gia tăng
Số lượng kênh giao tiếp là minh họa rõ nhất cho định luật Brooks. Nếu mọi thành viên trong nhóm đều phải trao đổi với nhau, khi số người là n, số kênh giao tiếp sẽ là n(n-1)/2. Dù số người chỉ tăng từng người một, số kênh lại tăng nhanh hơn nhiều.
- Nhóm có 3 người (Team of 3): Có 3 kênh giao tiếp.
- Nhóm có 5 người (Team of 5): Số kênh giao tiếp tăng lên 10.
- Nhóm có 10 người (Team of 10): Số kênh giao tiếp là 45.
- Nhóm có 20 người (Team of 20): Số kênh giao tiếp lên tới 190.
Như vậy, khi số người tăng gấp đôi, số kênh tăng gần gấp bốn. Các cuộc họp, tin nhắn và công việc kiểm tra cũng tăng tương ứng, còn thời gian thực sự dành cho việc xây dựng phần mềm lại giảm đi. Đến một thời điểm, nhóm sẽ chạm tới ngưỡng mà càng thêm người, năng suất chung càng giảm.
Cách tránh tác động của định luật và những giới hạn
Định luật Brooks gần với lời khuyên hãy cân nhắc kỹ thời điểm và cách thức bổ sung nhân lực hơn là yêu cầu không được tăng người. Trong thực tế phát triển phần mềm, người ta cố gắng tránh cái bẫy này bằng những phương pháp sau.
- Nhóm nhỏ (Small Team): Duy trì số thành viên trong mỗi nhóm ở mức ít để giảm số kênh giao tiếp. Nguyên tắc “nhóm hai chiếc pizza” của Amazon là một ví dụ nổi tiếng.
- Mô-đun hóa (Modularity): Chia công việc thành các phần độc lập với nhau và quy định rõ các quy ước giữa những phần đó để giảm lượng thông tin các nhóm cần trao đổi.
- Bổ sung nhân lực sớm (Early Staffing): Nếu cần thêm người, hãy đưa họ vào từ đầu dự án để có thời gian làm quen, thay vì đợi đến khi tiến độ đã chậm.
- Điều chỉnh phạm vi (Scope Cut): Nếu đã chậm tiến độ, việc cắt giảm tính năng hoặc lên lại lịch trình thường tốt hơn là thêm người.
Tuy nhiên, định luật này cũng có giới hạn. Chính Brooks về sau cũng thừa nhận rằng định luật là một nhận định đã đơn giản hóa quá mức. Với những việc dễ chia nhỏ như kiểm thử hay viết tài liệu, hoặc khi người tham gia đã hiểu rõ dự án, việc thêm người thực sự có thể giúp công việc nhanh hơn. Ngày nay, nhờ sự phát triển của công cụ cộng tác và tự động hóa, công sức dành cho giao tiếp đã giảm so với trước, nên mức độ tác động của định luật tùy thuộc vào đặc điểm của nhóm và công việc.
Sau cùng, định luật Brooks nhắc chúng ta rằng tốc độ làm việc không chỉ được quyết định bởi số lượng người. Trước khi thêm người, hãy xem xét công việc được phân chia ra sao và mọi người kết nối với nhau như thế nào; đó chính là bước đầu tiên để phát triển phần mềm đúng tiến độ.
