The Mythical Man-Month: vì sao thêm kỹ sư vào dự án trễ của khách lại làm nó trễ hơn

Câu được trích nhiều nhất của cuốn sách chỉ dài một dòng: thêm người vào một dự án phần mềm đang trễ sẽ làm nó trễ hơn. Fred Brooks rút ra điều này từ thời quản lý IBM System/360 và OS/360.

Năm mươi năm sau, câu đó vẫn đúng ở chỗ FDE hay phải có mặt: phòng họp của khách, khi deadline đã trượt và có người đề nghị “cử thêm hai người sang”.

Làm FDE thì sớm muộn bạn cũng gặp cảnh này. Deployment chậm ba tuần, khách sốt ruột, account team muốn tỏ thiện chí bằng cách tăng nhân sự. The Mythical Man-Month giải thích vì sao phản xạ đó thường làm hỏng việc, và cho bạn con số để phản biện.

Bản nên đọc là Anniversary Edition (Addison-Wesley, 1995). Theo Pearson, bản này giữ nguyên các bài luận từ lần in đầu năm 1975, thêm các bài mới đánh giá lại nghề quản lý dự án phần mềm và in kèm “No Silver Bullet” (1986).

Định luật Brooks: có hai cái giá, không phải một

Brooks chỉ ra hai lý do. Lý do đầu dễ thấy: người mới cần thời gian để bắt nhịp, và trong thời gian đó họ lấy giờ của chính những người đã quen dự án. Lý do thứ hai khó thấy hơn: mỗi người thêm vào lại mở thêm đường giao tiếp.

Sách đưa ra công thức n(n − 1)/2 để đếm số kênh giao tiếp trong một nhóm. Tính thử cho một engagement cỡ vừa: bốn kỹ sư có 4 × 3 / 2 = 6 kênh. Thêm hai người thành sáu thì có 6 × 5 / 2 = 15 kênh. Số người tăng 50%, số kênh tăng gấp 2,5 lần. Với 50 lập trình viên, con số là 1.225.

Hãy đặt phép tính đó vào một tình huống giả định. Bạn đang triển khai một pipeline dữ liệu cho khách, đã trễ ba tuần, và hai kỹ sư mới được cử sang.

Tuần đầu, bạn ngồi giải thích schema của khách, quy trình xin quyền truy cập và vì sao không được đụng vào bảng kia. Tuần thứ hai họ bắt đầu code, nhưng mỗi quyết định giờ phải đi qua 15 kênh thay vì 6.

Sang tuần thứ ba, dự án vẫn chưa nhanh thêm được ngày nào.

Vì thế, việc đầu tiên nên làm ở chỗ khách là quay lại cuộc họp với phép tính trên và một đề xuất khác: cắt những gì không cần cho mốc gần nhất, rồi giữ đội hiện tại tập trung.

Đội phẫu thuật: dồn sức quanh người giỏi nhất

Ý thứ hai đáng giữ là mô hình “surgical team”, tức đội phẫu thuật. Một lập trình viên chính có tay nghề cao tự viết những phần then chốt, những người còn lại làm hỗ trợ. Brooks đặt mô hình này cạnh một nhận xét thẳng thắn: lập trình viên “giỏi” làm việc năng suất gấp năm đến mười lần người tầm trung.

Nhiều engagement FDE vốn đã chạy theo kiểu này mà không ai gọi tên: một người nắm toàn bộ bối cảnh của khách và kiến trúc tích hợp. Bài học rút ra từ Brooks là phải bảo vệ người đó.

Con số năm đến mười lần là nhận xét chung về khoảng cách giữa các lập trình viên, không phải phép đo cho riêng ai; nhưng nếu nửa ngày của người dẫn dắt bị tiêu vào việc giải thích lại cho người mới, bạn đang lãng phí đúng người mà cả engagement dựa vào.

Hiệu ứng hệ thống thứ hai: phiên bản 2 nguy hiểm nhất

Ý thứ ba hợp với giai đoạn sau go-live. Brooks cảnh báo rằng hệ thống thứ hai của một kiến trúc sư hay bị nhồi đầy những tính năng đã gác lại ở hệ thống đầu. Ông gọi đó là hệ thống nguy hiểm nhất mà họ từng thiết kế.

Với FDE, cái bẫy này thường mở ra ngay sau lần triển khai đầu tiên thành công. Khách vui, bạn tự tin, và danh sách “để bản sau” bỗng thành scope của bản sau. Hãy đọc lại danh sách đó và hỏi từng mục: nó giải quyết vấn đề của khách, hay chỉ là món nợ cảm xúc từ lần trước?

Cắt scope cũng có thể sai cách

Hiểu định luật Brooks rồi, nhiều người lại vấp ở bước tiếp theo. Lỗi hay gặp nhất là tự cắt scope trong đội mà không chốt lại mốc mới với khách. Đội thấy mình đã làm đúng, còn khách vẫn chờ đủ tính năng vào ngày cũ, và đến hôm bàn giao thì niềm tin mất sạch.

Lỗi thứ hai là dùng định luật như cái cớ để từ chối mọi sự giúp đỡ. Brooks nói về người mới phải bắt nhịp và kênh giao tiếp mới, nên điều cần hỏi là người được cử sang có làm tăng hai thứ đó hay không.

Cách an toàn là viết rõ ra: bỏ mục nào, mốc mới là ngày nào, và để khách xác nhận trước khi đội đổi kế hoạch.

Ai nên đọc, và đọc theo thứ tự nào?

Sách hợp với kỹ sư từ hai năm kinh nghiệm trở lên, nhất là người bắt đầu dẫn dắt engagement hoặc phải nói chuyện tiến độ với khách. InformIT nhận xét hiếm có cuốn sách quản lý dự án phần mềm nào có ảnh hưởng lâu bền như cuốn này. Dù vậy, đừng đọc như sách giáo khoa, vì nhiều ví dụ đến từ thời mainframe.

Thứ tự nên đọc: bài về định luật và công thức giao tiếp trước, rồi đội phẫu thuật, rồi hiệu ứng hệ thống thứ hai. Sau cùng mới đến “No Silver Bullet” và các bài viết thêm năm 1995 để thấy Brooks tự nhìn lại mình.

Khi chuẩn bị phỏng vấn FDE, đừng chỉ trích định luật Brooks. Hãy kể một lần bạn đã từ chối thêm người và cắt scope thay vào đó: dự án trễ bao lâu, bạn bỏ những gì, và kịp mốc nào. Ghi đủ ba chi tiết ấy lên CV, trong đó số tuần trễ và mốc kịp được nên là con số cụ thể.

Một công thức từ năm 1975 sẽ không giúp dự án của khách chạy nhanh hơn. Nhưng nó cho bạn đủ lý lẽ để không làm dự án chậm thêm.