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. /Kế hoạch & tiến độ
  2. /40 ngày công không phải 8 ngày với 5 người: chuy…
Kế hoạch & tiến độ· Domain: Lập kế hoạch

40 ngày công không phải 8 ngày với 5 người: chuyển ước lượng công sang thời lượng cho đúng

Ước lượng 40 ngày công, chia cho 5 người, kế hoạch ghi 8 ngày. Thực tế mất 19 ngày. Phân biệt công (effort), thời lượng (duration) và thời gian trôi qua, tính hệ số khả dụng, và hiểu vì sao thêm người không rút ngắn tuyến tính.

HP
Nguyễn Thu Hà, PMP
29/09/2026
6 phút đọc 0 0
40 ngày công không phải 8 ngày với 5 người: chuyển ước lượng công sang thời lượng cho đúng

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một công ty bán lẻ cần xây dựng mô-đun khuyến mại cho ứng dụng bán hàng trước đợt giảm giá cuối năm. Đội ước lượng tổng công là 40 ngày công. Trưởng phòng phân công 5 lập trình viên và PM ghi vào kế hoạch: 8 ngày làm việc.

Mô-đun hoàn thành sau 19 ngày làm việc. Khi xem lại, PM thấy:

  • Mỗi lập trình viên chỉ dành khoảng 60% thời gian cho mô-đun; phần còn lại là sửa lỗi hệ thống đang chạy, họp, hỗ trợ đội khác.
  • Hai ngày đầu, ba người phải chờ thiết kế dữ liệu của người thứ nhất.
  • Phần kiểm thử tích hợp cuối cùng chỉ một người làm được vì cần môi trường duy nhất.
  • Có hai ngày nghỉ lễ nằm trong khoảng thời gian thực hiện.

Không có con số nào trong ước lượng ban đầu sai. Sai nằm ở phép chia.

Ba khái niệm hay bị trộn lẫn

Khái niệmÝ nghĩaĐơn vị
Công (effort)Tổng lượng lao động cần để hoàn thànhNgày công, giờ công
Thời lượng (duration)Số kỳ làm việc từ lúc bắt đầu đến lúc kết thúc hoạt độngNgày làm việc
Thời gian trôi qua (elapsed time)Thời gian lịch, gồm cả cuối tuần, nghỉ lễNgày lịch

PMBOK® Guide ấn bản 6 tách bạch các quy trình: Estimate Activity Resources (9.2) xác định cần loại và lượng nguồn lực nào; Estimate Activity Durations (6.4) ước lượng số kỳ làm việc, có tính tới nguồn lực được giao, mức khả dụng và các yếu tố như quy luật lợi suất giảm dần. Agile Alliance cũng lưu ý ước lượng công thường được diễn đạt dưới dạng thời lượng — và chính bước chuyển đổi này là chỗ hay sai.

Bốn yếu tố biến công thành thời lượng

1. Mức khả dụng (availability)

Không ai dành 100% thời gian cho một hoạt động. Họp, email, hỗ trợ vận hành, đào tạo, nghỉ phép đều lấy đi một phần. Nhiều đội dùng hệ số tập trung (focus factor) — tỷ lệ thời gian thực sự dành cho công việc của dự án. Con số này nên lấy từ dữ liệu của chính đội, không lấy từ "kinh nghiệm chung".

2. Khả năng chia việc (divisibility)

Tình huống liên quan

Kế hoạch & tiến độLập kế hoạch

Ngày go-live "chắc chắn" chỉ đạt được 8% số lần mô phỏng: phân tích rủi ro tiến độ bằng Monte Carlo

Lịch dự án ERP ghi go-live ở ngày làm việc thứ 120, nhưng ba nhánh công việc cùng hội tụ vào một mốc. Mô phỏng Monte Carlo cho thấy ngày đó chỉ đạt được khoảng 8% số lần lặp. Cách đọc đường cong S, hiểu merge bias và chọn mức dự phòng tiến độ có căn cứ.

Ngày đăng: 04/10/2026Lượt xem: 0Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

Đội kiểm thử quá tải 160% trong ba tuần: chọn resource leveling hay resource smoothing?

Lịch trình trông hợp lý cho tới khi xếp người vào: đội kiểm thử phải gánh 160% công suất trong ba tuần. Phân biệt resource leveling và resource smoothing, khi nào chấp nhận lùi mốc và khi nào chỉ dùng float.

Ngày đăng: 01/10/2026Lượt xem: 4Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

Ước lượng ba điểm và PERT: khi đội chỉ đưa ra một con số lạc quan

Đội cam kết "28 ngày là xong" nhưng đó chỉ là kịch bản thuận lợi. Cách dùng ước lượng ba điểm, công thức PERT và độ lệch chuẩn để đưa ra mốc tiến độ có mức tin cậy.

Ngày đăng: 28/09/2026Lượt xem: 5Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

Mỗi công việc đều có "đệm an toàn" mà dự án vẫn trễ: quản lý tiến độ bằng chuỗi găng và buffer

Kỹ sư nào cũng cộng thêm thời gian an toàn vào ước lượng, vậy mà dự án R&D vẫn trễ. Phương pháp chuỗi găng (critical chain) gom phần an toàn thành buffer chung, theo dõi bằng fever chart. Cách tính buffer, đọc trạng thái và những thay đổi hành vi cần có.

Ngày đăng: 28/09/2026Lượt xem: 0Bình luận: 0

Một số việc chia được cho nhiều người gần như tuyến tính (nhập liệu, kiểm thử thủ công các kịch bản độc lập). Nhiều việc khác có phần tuần tự: thiết kế phải xong trước khi lập trình song song; tích hợp chỉ một người làm được trên môi trường duy nhất. Phần tuần tự không rút ngắn được bằng cách thêm người.

3. Chi phí phối hợp

Fred Brooks, trong The Mythical Man-Month (1975), chỉ ra rằng số kênh giao tiếp tăng nhanh theo quy mô nhóm. Với n người, số kênh là n(n−1)/2: 3 người có 3 kênh, 5 người có 10 kênh, 10 người có 45 kênh. Mỗi người thêm vào đều kéo theo thời gian họp, đồng bộ, giải quyết xung đột mã.

4. Thời gian làm quen (ramp-up)

Người mới cần thời gian hiểu hệ thống, và người cũ phải bỏ thời gian hướng dẫn. Luật Brooks tóm gọn: thêm người vào một dự án phần mềm đang trễ sẽ làm nó trễ hơn. Chính Brooks gọi đó là sự đơn giản hoá quá mức; luật này đúng nhất với việc khó chia, đã trễ, và người mới chưa quen hệ thống.

Tính lại cho tình huống

Với cùng 40 ngày công, PM tính lại theo các yếu tố trên (số liệu minh hoạ):

  1. Tách phần tuần tự: thiết kế dữ liệu 3 ngày công (1 người) và kiểm thử tích hợp 4 ngày công (1 người) — tổng 7 ngày công tuần tự.
  2. Phần song song: 33 ngày công còn lại chia cho 5 người.
  3. Áp hệ số tập trung 0,6:
    • Phần tuần tự: 7 / 0,6 ≈ 11,7 ngày làm việc.
    • Phần song song: 33 / (5 × 0,6) = 11 ngày làm việc.
  4. Cộng phối hợp: thêm khoảng 10% cho đồng bộ giữa 5 người → khoảng 12 ngày cho phần song song.
  5. Thời lượng ≈ 11,7 + 12 ≈ 24 ngày làm việc (chưa kể nghỉ lễ). Đổi sang lịch: cộng 2 ngày lễ.

Con số này còn dài hơn thực tế 19 ngày — vì trong thực tế đội đã tự xoay xở (một phần thiết kế được làm song song). Nhưng nó gần sự thật hơn nhiều so với 8 ngày, và quan trọng hơn: nó chỉ ra đòn bẩy thật để rút ngắn:

  • Giải phóng người khỏi việc vận hành (tăng hệ số tập trung) có tác dụng mạnh hơn thêm người.
  • Rút ngắn phần tuần tự (chuẩn bị môi trường tích hợp thứ hai, thiết kế dữ liệu sớm) tác động trực tiếp lên thời lượng.

Đo hệ số tập trung của chính đội

Hệ số tập trung không nên là con số "nghe nói". Một cách đo đơn giản trong 2–4 tuần:

  • Mỗi người ghi nhanh cuối ngày số giờ dành cho công việc dự án, tách riêng họp, hỗ trợ vận hành, việc khác.
  • Tính tỷ lệ giờ dự án trên tổng giờ làm việc theo từng người và trung bình đội.
  • Đối chiếu với kết quả bàn giao: nếu tỷ lệ cao mà sản lượng thấp, có thể vấn đề nằm ở chuyển đổi ngữ cảnh (context switching) — người làm nhiều việc xen kẽ trong ngày mất thêm thời gian khởi động lại mỗi lần đổi việc.

Đội agile có thể dùng trực tiếp dữ liệu lịch sử của mình (velocity hoặc số hạng mục hoàn thành mỗi sprint) thay cho hệ số tập trung, vì dữ liệu đó đã phản ánh sẵn mức khả dụng thật.

Một lưu ý về cách dùng: hệ số tập trung là công cụ lập kế hoạch, không phải chỉ tiêu đánh giá. Khi bị dùng để đánh giá cá nhân, người ta sẽ ghi số đẹp và dữ liệu mất giá trị.

Nén tiến độ: khi nào thêm người có ích

PMBOK gọi việc thêm nguồn lực để rút ngắn tiến độ là crashing, và làm song song các hoạt động vốn tuần tự là fast tracking. Thêm người có ích khi:

  • Thêm sớm, không phải khi đã trễ.
  • Công việc chia được thành phần độc lập (ví dụ thêm người kiểm thử cho các kịch bản độc lập).
  • Người được thêm đã quen hệ thống, hoặc được giao phần việc tách biệt ít cần phối hợp.
  • Hoạt động được rút ngắn nằm trên đường găng — rút ngắn hoạt động không găng chỉ tốn tiền.

Sai lầm thường gặp

  • Chia thẳng công cho số người và gọi đó là thời lượng.
  • Giả định 100% khả dụng cho người đang kiêm nhiệm vận hành.
  • Bỏ qua lịch nguồn lực (resource calendar): nghỉ phép, lễ, ca làm việc.
  • Hứa "thêm người là kịp" khi dự án đã trễ mà không phân tích phần tuần tự và chi phí làm quen.

Góc ôn thi PMP

  • Phân biệt rõ effort (công) và duration (thời lượng); đề có thể cho tình huống "nhân đôi số người có giảm một nửa thời lượng không?" → không nhất thiết, do quy luật lợi suất giảm dần và chi phí phối hợp.
  • Số kênh giao tiếp = n(n−1)/2 — công thức hay gặp trong quản lý truyền thông.
  • Crashing tăng chi phí, fast tracking tăng rủi ro làm lại; cả hai chỉ có ý nghĩa với hoạt động trên đường găng.

Nguồn tham khảo

  • Brooks's law – Wikipedia
  • Estimation – Agile Alliance Glossary
#effort#duration#focus-factor#Luật Brooks#uoc-luong-thoi-luong

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

Câu 1/1
Một hoạt động trên đường găng được ước lượng 60 ngày công và đang giao cho 3 người. Sponsor đề nghị tăng lên 6 người để rút thời lượng còn một nửa. Hoạt động gồm một phần thiết kế chỉ một người làm được và phần lập trình chia được. Câu trả lời nào của PM phù hợp nhất?

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

Đội 5 người có hệ số tập trung chỉ khoảng 0,5 vì phải kiêm hỗ trợ vận hành. Dự án đang có nguy cơ trễ 3 tuần. Nếu là PM, bạn đề xuất gì với ban giám đốc?

Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

Đánh giá bài viết

Bình luận

Mục lục

Tình huống minh hoạBa khái niệm hay bị trộn lẫnBốn yếu tố biến công thành thời lượngTính lại cho tình huốngĐo hệ số tập trung của chính độiNén tiến độ: khi nào thêm người có íchSai lầm thường gặpGóc ôn thi PMPNguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoBộ đề thi thử PMP (mẫu)
Quảng cáoTemplate quản lý dự án (mẫu)