Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Nguồn lực
  3. /IBM OS/360 và Luật Brooks: vì sao thêm người vào…
Số 60Quản lý Nguồn lực

IBM OS/360 và Luật Brooks: vì sao thêm người vào dự án phần mềm đang trễ lại làm nó trễ hơn

Từ kinh nghiệm quản lý hệ điều hành OS/360 của IBM, Fred Brooks đúc kết trong The Mythical Man-Month (1975) rằng thêm nhân lực vào dự án phần mềm đã trễ chỉ làm nó trễ thêm. Phân tích thời gian làm quen, chi phí giao tiếp n(n−1)/2 và cách PM lập kế hoạch nguồn lực, nén tiến độ đúng chuẩn PMP.

HP
Nguyễn Thu Hà, PMP
22/09/2026
5 phút đọc 0 lượt xem
IBM OS/360 và Luật Brooks: vì sao thêm người vào dự án phần mềm đang trễ lại làm nó trễ hơn
Bình luận0

Bối cảnh thực tế

Thập niên 1960, IBM phát triển OS/360 — hệ điều hành cho dòng máy tính lớn System/360, một trong những dự án phần mềm lớn và phức tạp nhất thời bấy giờ. Fred Brooks là người quản lý dự án. Khi tiến độ trượt, phản xạ quen thuộc là bổ sung lập trình viên với hy vọng “nhiều tay thì nhanh việc”.

Kết quả lại ngược với kỳ vọng. Người mới cần thời gian tìm hiểu hệ thống, kéo theo các kỹ sư giàu kinh nghiệm phải dừng việc để hướng dẫn; số cuộc trao đổi, họp phối hợp tăng vọt; còn nhiều công việc vốn tuần tự nên không thể chia nhỏ cho thêm người cùng làm.

Năm 1975, Brooks đúc kết bài học trong cuốn The Mythical Man-Month (Huyền thoại tháng-người), với câu trở thành định luật mang tên ông:

Luật Brooks: thêm nhân lực vào một dự án phần mềm đang trễ sẽ làm nó trễ hơn nữa.

  • Thời gian làm quen (ramp-up) của người mới làm giảm năng suất của cả đội trong ngắn hạn.
  • Số kênh giao tiếp tăng theo công thức n(n−1)/2: đội 10 người có 45 kênh, đội 20 người có 190 kênh.
  • Nhiều công việc không chia nhỏ được — “chín người phụ nữ không thể sinh một đứa trẻ trong một tháng”.

Luật cũng có ngoại lệ: thêm người sớm hoặc thêm chuyên gia cho việc độc lập vẫn có thể giúp ích.

Phân tích theo chuẩn PMP

  • “Tháng-người” không hoán đổi được: lỗi ở khâu ước lượng nguồn lực

    Quy trình Ước lượng nguồn lực hoạt động (Estimate Activity Resources) giả định ngầm rằng công sức và thời gian có thể đổi chéo cho nhau. Điều này chỉ đúng với công việc chia được và ít phụ thuộc. Với phần mềm, thời lượng (duration) bị chi phối bởi phụ thuộc logic và chi phí phối hợp, nên nhân đôi số người không chia đôi thời gian. PM cần ước lượng có tính tới đường cong học tập và chi phí giao tiếp, thay vì nhân chia tháng-người một cách cơ học.

  • Crashing có điều kiện: chỉ hiệu quả với hoạt động trên đường găng và “chia được”

    Nén tiến độ bằng tăng nguồn lực (crashing) là kỹ thuật hợp lệ trong Phát triển lịch trình (Develop Schedule), nhưng PMBOK nhấn mạnh nó chỉ có tác dụng với hoạt động trên đường găng (critical path) và có thể làm tăng chi phí, rủi ro. Thêm người vào phần việc tuần tự, phụ thuộc kiến thức ngầm của đội gốc thì vừa tốn chi phí vừa kéo dài thời gian — đúng tình huống OS/360.

  • Chi phí giao tiếp tăng theo cấp số của quy mô đội

    Công thức số kênh giao tiếp n(n−1)/2 là kiến thức quen thuộc của đề PMP. Khi đội lớn lên, thời gian dành cho phối hợp, đồng bộ và giải quyết hiểu lầm tăng nhanh hơn nhiều so với năng lực sản xuất bổ sung. Kế hoạch quản lý nguồn lực (Resource Management Plan) và kế hoạch quản lý giao tiếp phải thiết kế cấu trúc đội (nhóm nhỏ, giao diện rõ) để kiềm chế số kênh này.

  • Phát triển đội nhóm bị đặt lại: người mới kéo đội về giai đoạn đầu Tuckman

    Theo mô hình Tuckman, mỗi lần thành phần đội thay đổi đáng kể, đội có thể quay lại giai đoạn Forming/Storming. Việc bơm người hàng loạt vào cuối dự án làm đứt nhịp làm việc của một đội đang ở giai đoạn Performing — chi phí ẩn mà các quyết định “thêm người cho nhanh” thường bỏ qua.

  • Hướng xử lý theo khuyến nghị PMI

    1. 1

      Bước 1: Phân tích trước khi hành động: xác định nguyên nhân trễ thật sự

      Trước khi xin thêm người, PM phân tích đường găng, nút thắt và chất lượng ước lượng ban đầu. Nhiều dự án “trễ” thực chất là do ước lượng lạc quan; điều chỉnh lại đường cơ sở qua kiểm soát thay đổi tích hợp có thể là phương án đúng hơn bổ sung nhân lực.

    2. 2

      Bước 2: Đánh giá phương án bổ sung nguồn lực theo tiêu chí rõ ràng

      Chỉ đề xuất thêm người khi phần việc đáp ứng các điều kiện sau:

      • Việc chia được, ít phụ thuộc

        Phần việc có giao diện rõ, có thể giao trọn cho người mới mà không cần đội gốc kèm liên tục.

      • Người mới đã có chuyên môn

        Ưu tiên chuyên gia đúng mảng (kiểm thử, hạ tầng, tài liệu) để rút ngắn thời gian làm quen.

      • Còn đủ thời gian hoàn vốn

        Nếu thời gian còn lại ngắn hơn thời gian làm quen cộng hướng dẫn, việc thêm người gần như chắc chắn làm chậm thêm.

    3. 3

      Bước 3: Cân nhắc các đòn bẩy khác của nén tiến độ và phạm vi

      So sánh với làm song song (fast tracking) các phần việc độc lập, chuyển bớt tính năng sang bản phát hành sau (giảm phạm vi có kiểm soát), hoặc gỡ bỏ trở ngại cho đội hiện tại. Mọi thay đổi đường cơ sở phải đi qua quy trình kiểm soát thay đổi.

    4. 4

      Bước 4: Nếu thêm người: lập kế hoạch onboarding như một hoạt động có ngân sách

      Đưa thời gian hướng dẫn, tài liệu bàn giao và người kèm cặp vào lịch; giao người mới phần việc biên trước, đưa vào luồng chính sau. Cập nhật ma trận RACI để tránh chồng chéo trách nhiệm.

    5. 5

      Bước 5: Giữ đội nhỏ, cấu trúc theo mô-đun

      Tổ chức thành các nhóm nhỏ có trách nhiệm rõ với từng mô-đun, giảm số kênh giao tiếp phải duy trì. Đây cũng là tinh thần của mô hình “đội phẫu thuật” mà Brooks đề xuất trong cùng cuốn sách.

    PM Takeaway (Bài học rút ra)

    Nhân lực không phải là thứ đổ thêm vào là ra tiến độ: với công việc tri thức, mỗi người mới mang theo chi phí làm quen và chi phí giao tiếp. PM giỏi phân tích nguyên nhân trễ và tính chi phí ẩn trước khi xin thêm người.

    Nguồn tham khảo

    • Brooks’s law — Wikipedia
    • The Mythical Man-Month — Wikipedia
    #Quản lý nguồn lực#Luật Brooks#Nén tiến độ#Kênh giao tiếp#Phát triển phần mềm

    Nguồn: Brooks’s law — Wikipedia ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Dự án phần mềm 10 người đang trễ 4 tuần, còn 6 tuần đến hạn. Nhà tài trợ đề nghị bổ sung ngay 8 lập trình viên từ dự án khác, chưa ai biết mã nguồn. Phần việc còn lại chủ yếu là tích hợp các mô-đun phụ thuộc chặt vào nhau. PM nên làm gì TRƯỚC TIÊN?

    Bạn chọn phương án nào?

    Nếu là PM của một dự án phần mềm đang trễ 3 tuần trên đường găng, ban lãnh đạo sẵn sàng cấp thêm 5 người. Bạn chọn phương án nào?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Nguồn lực

    Heartbleed và OpenSSL (2014): hạ tầng bảo mật của cả Internet dựa vào một nhóm tình nguyện viên, chỉ một người làm toàn thời gian

    Lỗi Heartbleed trong thư viện OpenSSL khiến khoảng 17% máy chủ web có chứng thực tin cậy bị coi là dễ tổn thương khi công bố. Phía sau là một dự án do vài tình nguyện viên duy trì, chỉ một người làm toàn thời gian và quyên góp hằng năm chỉ khoảng 2.000 USD. Phân tích dưới góc nhìn quản lý nguồn lực: phụ thuộc trọng yếu vào một "nguồn lực" không ai phân bổ ngân sách.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Quản lý Nguồn lực

    Mozilla 2020: cắt giảm khoảng 250 nhân sự, đội Servo bị ảnh hưởng và bài toán giữ tri thức khi tái cơ cấu đội kỹ thuật

    Ngày 11/08/2020 Mozilla công bố cắt giảm khoảng 250 nhân sự với lý do doanh thu giảm do đại dịch; đội phát triển công cụ trình duyệt Servo nằm trong số bị ảnh hưởng. Dự án chuyển sang Linux Foundation Europe và được kích hoạt lại năm 2023 nhờ nguồn tài trợ ngoài. Phân tích về giải tán đội, chuyển giao tri thức và kế hoạch cho dự án nghiên cứu dài hạn.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận10/10/2026
    Quản lý Nguồn lực

    Backdoor xz Utils (2024): người bảo trì một mình kiệt sức và chiến dịch gây áp lực nhiều năm để chiếm quyền bảo trì

    Năm 2022, người bảo trì gốc của xz Utils nói công khai mình bị giới hạn bởi vấn đề sức khoẻ tinh thần và dự án chỉ là sở thích không lương, trong khi một số tài khoản liên tục thúc ép bàn giao quyền. Đến tháng 3/2024, backdoor CVE-2024-3094 (CVSS 10) bị phát hiện tình cờ. Phân tích về kiệt sức, bus factor và quản trị quyền truy cập trong dự án.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận27/09/2026

    Nội dung

    Bối cảnh thực tếPhân tích theo chuẩn PMPHướng xử lý theo khuyến nghị PMIPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)