Ngân hàng đề — PMP Mock Exam Set

Tìm thấy 201 câu.

Câu 141
You are the project manager of Project GHJ, and you’re working with Jack as he manages the budget for your project. In your organization, the project team reports to Jack. Which of the following options can best describe the amount of authority you have in this organizational structure?
  1. A Total
  2. B High
  3. C Moderate
  4. D Low
Xem giải thích

Đáp án

D — Low (thấp).

Vì sao đúng

⚠ Hai dấu hiệu quyết định trong đề: | Dấu hiệu | Suy ra | |---|---| | ⚠ Jack quản lý NGÂN SÁCH dự án | ⚠ → PM không kiểm soát tiền | | ⚠ Đội dự án BÁO CÁO cho Jack, không phải cho bạn | ⚠ → PM không kiểm soát người | | ⚠ Không có tiền, không có người | ⚠ → quyền của quản lý dự án THẤP | | ⚠ Cơ cấu tương ứng | ⚠ functional hoặc weak matrix |

Vì sao các phương án khác sai

  • C (Moderate — trung bình) — ⚠ ứng với balanced matrix: ⚠ ở đó PM chia sẻ quyền với quản lý chức năng và thường kiểm soát một phần ngân sách; ⚠ ở đây PM không nắm gì cả.

  • B (High — cao) — ⚠ ứng với strong matrix: ⚠ PM có quyền đáng kể, đội chủ yếu báo cáo cho PM.

  • A (Total — toàn quyền) — ⚠ ứng với project-oriented: ⚠ PM toàn quyền, đội thuộc hẳn về dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25611 ở lô trước về cơ cấu organic và câu #25587 về vai trò của functional manager. ⚠ Ba câu cùng chủ đề cơ cấu tổ chức và quyền của PM.

⚠ Bảng quyền của PM theo cơ cấu tổ chức: | Cơ cấu | Quyền của PM | Ai quản ngân sách | PM toàn thời gian | |---|---|---|---| | ⚠ Organic / Simple | ⚠ rất ít hoặc không | ⚠ chủ doanh nghiệp | ⚠ hầu như không | | ⚠ Functional | ⚠ rất ít | ⚠ quản lý chức năng | ⚠ hầu như không | | ⚠ Weak matrix | ⚠ THẤP | ⚠ quản lý chức năng | ⚠ bán thời gian | | ⚠ Balanced matrix | ⚠ thấp đến TRUNG BÌNH | ⚠ chia sẻ | ⚠ toàn thời gian | | ⚠ Strong matrix | ⚠ trung bình đến CAO | ⚠ quản lý dự án | ⚠ toàn thời gian | | ⚠ Project-oriented | ⚠ CAO tới TOÀN QUYỀN | ⚠ quản lý dự án | ⚠ toàn thời gian |

Từ khoá nhận diện:

"ai quản ngân sách" → ⚠ câu hỏi quyết định nhất "đội báo cáo cho ai" → ⚠ câu hỏi quyết định thứ hai "PM là điều phối viên / trợ lý dự án" → ⚠ weak matrix hoặc functional "PM toàn thời gian, có nhân viên hành chính riêng" → ⚠ strong matrix hoặc project-oriented

⚠ Làm PM khi quyền THẤP thì sống thế nào Cách
⚠ Dựa vào EXPERT POWER và REFERENT POWER ⚠ không có quyền chức vụ thì dùng quyền chuyên môn và uy tín
⚠ Xây quan hệ tốt với quản lý chức năng ⚠ Jack là đồng minh quan trọng nhất của bạn
⚠ Làm rõ cam kết nguồn lực bằng VĂN BẢN ⚠ thoả thuận với quản lý chức năng
⚠ Dùng nhà tài trợ để gỡ vướng vượt thẩm quyền
⚠ Giao tiếp nhiều hơn bình thường ⚠ thiếu quyền thì phải bù bằng thông tin và ảnh hưởng
⚠ Rủi ro điển hình trong cơ cấu quyền thấp Rủi ro
⚠ Nhân sự bị rút đi làm việc khác đột ngột
⚠ Ưu tiên của dự án thua ưu tiên của phòng ban
⚠ PM chịu trách nhiệm mà không có thẩm quyền ⚠ tình huống khó chịu nhất của nghề
⚠ Cách giảm ⚠ ghi rõ trong điều lệ dự án mức thẩm quyền của PM ngay từ đầu

⚠ Đối chiếu: ⚠ câu #25624 ở lô trước về các dạng quyền lực. ⚠ Chính trong cơ cấu quyền thấp thì expert power và referent power mới là công cụ chính.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Điều lệ dự án có ghi rõ thẩm quyền của bạn không | ⚠ không ghi thì mặc định là thấp | | Ai thật sự quyết định thời gian của thành viên đội | | | Bạn có kênh trực tiếp tới nhà tài trợ không | ⚠ cần thiết khi quyền thấp |

Và câu hỏi duy nhất cần đặt để xác định cơ cấu: ai giữ tiền và ai giữ người? Trả lời được hai câu đó là biết ngay quyền của quản lý dự án ở mức nào.

Câu 142
You are the project manager of SDF project. While working with your team, you decide to direct using positional power. To ensure that the project runs smoothly, you focus on near-term goals, bottom line, systems, and structure. Which of the following statements best describes the way in which you are handling the project?
  1. A Your way of working can be best described as leadership
  2. B You are employing the servant leadership model for the project team.
  3. C Your way of working can be best described as management
  4. D You are employing both leadership and management
Xem giải thích

Đáp án

C — Cách làm việc của bạn được mô tả đúng nhất là QUẢN LÝ (management).

Vì sao đúng

⚠ Bốn dấu hiệu trong đề đều thuộc về QUẢN LÝ: | Dấu hiệu | Nội dung | |---|---| | ⚠ Chỉ đạo bằng QUYỀN CHỨC VỤ | ⚠ positional power — đặc trưng của quản lý | | ⚠ Tập trung vào mục tiêu NGẮN HẠN | ⚠ lãnh đạo nhìn tầm nhìn dài hạn | | ⚠ Tập trung vào KẾT QUẢ TÀI CHÍNH | ⚠ bottom line | | ⚠ Tập trung vào HỆ THỐNG và CẤU TRÚC | ⚠ lãnh đạo tập trung vào CON NGƯỜI | | ⚠ Kết luận | ⚠ cả bốn đều nằm ở cột "quản lý" trong bảng đối chiếu của PMBOK |

Vì sao các phương án khác sai

  • A (lãnh đạo) — ⚠ SAI: ⚠ lãnh đạo dùng ⚠ quyền quan hệ và sức thuyết phục, ⚠ hướng tới ⚠ tầm nhìn, con người, tin tưởng, chân trời xa.

  • B (mô hình lãnh đạo phục vụ) — ⚠ SAI hẳn: ⚠ servant leadership đặt ⚠ nhu cầu của đội lên trước, ⚠ người dẫn dắt gỡ vướng cho đội thay vì ra lệnh.

  • D (cả lãnh đạo và quản lý) — ⚠ đề chỉ mô tả các đặc điểm thuộc MỘT phía; ⚠ không có dấu hiệu nào của lãnh đạo trong tình huống.

Ghi nhớ

⚠ Bảng đối chiếu Quản lý và Lãnh đạo — cần thuộc: | Quản lý | Lãnh đạo | |---|---| | ⚠ Dùng quyền CHỨC VỤ | ⚠ dùng quyền QUAN HỆ và ảnh hưởng | | ⚠ DUY TRÌ hiện trạng | ⚠ THÁCH THỨC hiện trạng | | ⚠ Tập trung vào HỆ THỐNG và CẤU TRÚC | ⚠ tập trung vào CON NGƯỜI | | ⚠ KIỂM SOÁT | ⚠ TRUYỀN CẢM HỨNG và tạo TIN TƯỞNG | | ⚠ Mục tiêu NGẮN HẠN | ⚠ tầm nhìn DÀI HẠN | | ⚠ Hỏi THẾ NÀO và KHI NÀO | ⚠ hỏi CÁI GÌ và VÌ SAO | | ⚠ Chú ý KẾT QUẢ TÀI CHÍNH | ⚠ chú ý CHÂN TRỜI phía trước | | ⚠ Chấp nhận hiện trạng | ⚠ đặt câu hỏi về hiện trạng | | ⚠ Làm ĐÚNG CÁCH | ⚠ làm ĐÚNG VIỆC |

Từ khoá nhận diện:

"quyền chức vụ, hệ thống, cấu trúc, ngắn hạn, tài chính" → ⚠ quản lý "tầm nhìn, con người, tin tưởng, dài hạn" → ⚠ lãnh đạo "đặt nhu cầu đội lên trước, gỡ vướng cho đội" → ⚠ servant leadership "làm đúng cách" → ⚠ quản lý; "làm đúng việc" → ⚠ lãnh đạo

⚠ Điểm quan trọng PMBOK nhấn mạnh Nội dung
⚠ Quản lý dự án cần CẢ HAI ⚠ không phải chọn một
⚠ Quản lý KHÔNG phải điều xấu ⚠ dự án cần cả hệ thống lẫn kiểm soát
⚠ Nhưng CHỈ quản lý mà thiếu lãnh đạo ⚠ đội làm đúng quy trình mà không có động lực
⚠ Tình huống nào cần gì ⚠ khủng hoảng cần quản lý chặt; thay đổi lớn cần lãnh đạo mạnh
⚠ Servant leadership — vì sao được nhắc nhiều Nội dung
⚠ Người dẫn dắt PHỤC VỤ đội, không ra lệnh
⚠ Gỡ trở ngại để đội làm việc
⚠ Đặc trưng của cách tiếp cận LINH HOẠT ⚠ vai trò Scrum Master
⚠ Hỏi "đội cần gì" thay vì "đội phải làm gì"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang dùng quyền chức vụ hay quyền ảnh hưởng | | | Đội có hiểu VÌ SAO họ làm việc này không | ⚠ thiếu vế đó là thiếu lãnh đạo | | Bạn dành bao nhiêu thời gian cho con người so với cho báo cáo | |

Và câu tổng kết kinh điển: quản lý là làm đúng cách, lãnh đạo là làm đúng việc. Dự án cần cả hai, nhưng một PM chỉ có nửa đầu sẽ đưa đội đi rất hiệu quả tới sai đích.

Câu 143
You are the ScrumMaster of a large software development project. Your manager has asked that you take a moment and create a chart to show the causal factors and effect of a bottleneck your project is experiencing. You gather the project team to create this chart and do root cause analysis. What type of chart are you creating in this project?
  1. A Pareto
  2. B Five-Whys Charts
  3. C Ishikawa
  4. D Risk burndown
Xem giải thích

Đáp án

C — Ishikawa (biểu đồ xương cá, tức biểu đồ nhân quả).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Dấu hiệu | Suy ra | |---|---| | ⚠ "các yếu tố NGUYÊN NHÂN và HẬU QUẢ" | ⚠ → causal factors and effect — chính là tên của công cụ | | ⚠ "phân tích NGUYÊN NHÂN GỐC" | ⚠ → root cause analysis | | ⚠ Tập hợp cả đội cùng vẽ | ⚠ → đúng cách dùng Ishikawa | | ⚠ Hình dạng | ⚠ hậu quả ở đầu cá, các nhóm nguyên nhân là xương lớn, nguyên nhân cụ thể là xương nhỏ |

Vì sao các phương án khác sai

  • B (Five-Whys Charts) — ⚠ 5 Whys là một kỹ thuật hỏi liên tiếp, ⚠ không phải một loại BIỂU ĐỒ; ⚠ nó bổ trợ cho Ishikawa chứ không thay thế.

  • A (Pareto) — ⚠ XẾP HẠNG các nguyên nhân theo tần suất, ⚠ không thể hiện quan hệ nhân quả.

  • D (Risk burndown) — ⚠ theo dõi mức phơi nhiễm rủi ro giảm dần qua các vòng lặp, ⚠ không liên quan tới phân tích nguyên nhân.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25626 ở lô trước — ⚠ ở đó Ishikawa và cause-and-effect xuất hiện thành HAI phương án riêng dù là cùng một công cụ. ⚠ Ba tên gọi đều chỉ một thứ: Ishikawa, xương cá (fishbone), nhân quả (cause-and-effect). ⚠ Và câu #25653 ở lô này về sáu bước giải quyết vấn đề — ⚠ Ishikawa phục vụ đúng bước 2.

⚠ Sáu nhóm nguyên nhân chuẩn — mô hình 6M: | Nhóm | Nội dung | |---|---| | ⚠ Man / People | ⚠ con người: kỹ năng, đào tạo, số lượng | | ⚠ Machine | ⚠ máy móc, thiết bị, công cụ | | ⚠ Method | ⚠ phương pháp, quy trình | | ⚠ Material | ⚠ nguyên vật liệu, đầu vào | | ⚠ Measurement | ⚠ cách đo lường, dữ liệu | | ⚠ Mother Nature / Environment | ⚠ môi trường, điều kiện xung quanh | | ⚠ Trong dịch vụ và phần mềm | ⚠ hay dùng biến thể: chính sách, quy trình, con người, công nghệ |

Từ khoá nhận diện:

"nguyên nhân và hậu quả, xương cá, nguyên nhân gốc" → ⚠ Ishikawa "xếp hạng nguyên nhân theo tần suất" → ⚠ Pareto "hỏi vì sao năm lần" → ⚠ 5 Whys — kỹ thuật, không phải biểu đồ "rủi ro giảm dần qua vòng lặp" → ⚠ risk burndown

⚠ Cách dùng Ishikawa cho một nút thắt Bước
⚠ Viết HẬU QUẢ ở đầu cá ⚠ "công việc ùn ở khâu kiểm thử"
⚠ Vẽ các xương lớn theo 6M
⚠ Cả đội động não từng nhánh
⚠ Với mỗi nguyên nhân, hỏi thêm "vì sao" ⚠ kết hợp 5 Whys ở đây
⚠ Khoanh vùng vài nguyên nhân khả nghi nhất
⚠ KIỂM CHỨNG bằng dữ liệu trước khi sửa ⚠ bước hay bị bỏ qua nhất
⚠ Bộ đôi công cụ dùng chung Cách phối
⚠ Pareto trước ⚠ chọn vấn đề nào đáng truy
⚠ Ishikawa sau ⚠ truy nguyên nhân của vấn đề đó
⚠ 5 Whys lồng vào Ishikawa ⚠ đào sâu từng nhánh
⚠ Cuối cùng: kiểm chứng bằng dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hậu quả bạn viết ở đầu cá có đủ cụ thể không | ⚠ "chất lượng kém" quá mơ hồ để truy | | Bạn có dừng lại ở nguyên nhân bề mặt không | ⚠ hỏi thêm vài lần "vì sao" | | Nguyên nhân nghi ngờ đã được kiểm chứng chưa | ⚠ sơ đồ chỉ đưa ra giả thuyết, không đưa ra bằng chứng |

Và giới hạn cần biết của công cụ này: Ishikawa sinh ra GIẢ THUYẾT, không sinh ra KẾT LUẬN. Đội vẽ xong một bức xương cá đẹp mà không kiểm chứng bằng dữ liệu thì vẫn đang phỏng đoán, chỉ là phỏng đoán có tổ chức hơn.

Câu 144
Gwen is the project manager of the HJ Project and her schedule is running late. She has identified some activities that she would like to crash, but is concerned about how useful crashing will be. In order to crash the project activities what must be true about the work?
  1. A Effort-driven activities
  2. B Critical path activities
  3. C Non-critical path activities
  4. D Activities longer than eight hours, but less than 80 hours
Xem giải thích

Đáp án

A — Effort-driven activities (công việc phụ thuộc công sức).

Vì sao đúng

⚠ Effort-driven nghĩa là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Thời lượng phụ thuộc vào TỔNG CÔNG SỨC bỏ ra | | | ⚠ Thêm người thì thời lượng GIẢM | ⚠ một người đào 8 giờ, hai người đào 4 giờ | | ⚠ Đây chính là điều kiện để CRASHING có tác dụng | ⚠ crashing = thêm nguồn lực để rút ngắn | | ⚠ Công việc KHÔNG effort-driven | ⚠ thêm người vô ích: bê tông vẫn cần 7 ngày khô, sơn vẫn cần 24 giờ để se, thử nghiệm vẫn cần đủ chu kỳ |

Vì sao các phương án khác sai

  • C (công việc KHÔNG nằm trên đường găng) — ⚠ SAI hẳn: ⚠ nén việc ngoài đường găng ⚠ không rút ngắn dự án chút nào, ⚠ chỉ tốn thêm tiền.

  • D (công việc dài hơn 8 giờ nhưng dưới 80 giờ) — ⚠ đó là quy tắc 8/80 khi PHÂN RÃ WBS, ⚠ không liên quan tới điều kiện nén lịch.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Phương án B ("công việc trên ĐƯỜNG GĂNG") cũng là một điều kiện BẮT BUỘC để crashing có ý nghĩa — ⚠ nén việc ngoài đường găng thì dự án không ngắn đi. ⚠ Đề chọn A vì hỏi ⚠ "điều gì phải đúng về BẢN CHẤT CÔNG VIỆC", ⚠ mà bản chất đó là tính phụ thuộc công sức; ⚠ vị trí trên đường găng là thuộc tính của LỊCH chứ không phải của công việc. ⚠ Giữ nguyên khoá A, nhưng cần nhớ ⚠ crashing đòi HAI điều kiện cùng lúc: nằm trên đường găng VÀ phụ thuộc công sức.

⚠ Đối chiếu: ⚠ câu #25658 ở lô này về đường găng. ⚠ Hai câu bổ sung nhau: câu kia cho biết nén ở ĐÂU, câu này cho biết nén được CÁI GÌ.

⚠ Hai kỹ thuật nén lịch: | Kỹ thuật | Cách làm | Đánh đổi | |---|---|---| | ⚠ Crashing | ⚠ thêm nguồn lực vào đường găng | ⚠ tăng CHI PHÍ | | ⚠ Fast tracking | ⚠ chạy song song các việc vốn nối tiếp | ⚠ tăng RỦI RO và khả năng phải làm lại | | ⚠ Cả hai | ⚠ chỉ tác dụng trên ĐƯỜNG GĂNG | | ⚠ Sau khi nén | ⚠ phải TÍNH LẠI đường găng |

Từ khoá nhận diện:

"thêm người thì nhanh hơn" → ⚠ effort-driven, crash được "phải chờ đủ thời gian bất kể bao nhiêu người" → ⚠ fixed-duration, KHÔNG crash được "thêm nguồn lực, tăng chi phí" → ⚠ crashing "chồng lấn công việc, tăng rủi ro" → ⚠ fast tracking

⚠ Vì sao crashing hay thất bại trong thực tế Lý do
⚠ Người mới cần thời gian LÀM QUEN ⚠ có khi còn làm chậm lại lúc đầu
⚠ Số kênh giao tiếp tăng theo bình phương
⚠ Nhiều công việc KHÔNG chia nhỏ được ⚠ chín phụ nữ không sinh con trong một tháng
⚠ Chi phí tăng nhanh hơn thời gian giảm
⚠ Luật Brooks ⚠ "thêm người vào dự án phần mềm đang chậm sẽ làm nó chậm hơn"
⚠ Gwen nên kiểm tra gì trước khi nén Kiểm tra
⚠ Việc đó có nằm trên đường găng không
⚠ Việc đó có phụ thuộc công sức không
⚠ Có sẵn người đủ kỹ năng không
⚠ Chi phí tăng thêm có được duyệt không
⚠ Có phương án rẻ hơn không ⚠ fast tracking, giảm phạm vi, đàm phán dời hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc bạn định nén thuộc loại nào | ⚠ công sức hay cố định thời lượng | | Nén xong đường găng có đổi không | | | Chi phí mỗi ngày rút ngắn là bao nhiêu | ⚠ so sánh giữa các phương án để chọn rẻ nhất |

Và câu ví von cần thuộc: chín người phụ nữ không sinh được một đứa trẻ trong một tháng. Công việc nào cũng nén được bằng tiền là ngộ nhận nguy hiểm nhất khi lịch bị ép.

Câu 145
Your project team is inspecting all of the work that has been completed in the project so far. The team is testing, measuring, and sampling the completed deliverables before the customer will inspect the work next week. They are also applying corrective actions to any mistakes to ensure the deliverables are defect-free before the customer examines the work and allows the project to move forward. What is happening in this scenario?
  1. A Quality control and scope control
  2. B Refactoring and scope validation
  3. C Scope control and quality assurance
  4. D Quality control and scope validation
Xem giải thích

Đáp án

D — Quality control và Scope validation (kiểm soát chất lượng rồi xác nhận phạm vi).

Vì sao đúng

⚠ Bóc tách hai giai đoạn trong đề: | Giai đoạn | Ai làm | Là quy trình gì | |---|---|---| | ⚠ ĐỘI kiểm thử, đo lường, lấy mẫu, sửa lỗi | ⚠ đội dự án | ⚠ Control Quality — kiểm soát chất lượng | | ⚠ KHÁCH HÀNG kiểm tra và cho phép dự án đi tiếp | ⚠ khách hàng | ⚠ Validate Scope — xác nhận phạm vi | | ⚠ Thứ tự | ⚠ QC TRƯỚC, Validate Scope SAU — đúng như đề mô tả |

Vì sao các phương án khác sai

  • A (Quality control và Scope control) — ⚠ vế sau sai: ⚠ Control Scope là theo dõi và ngăn phạm vi phình ra, ⚠ không phải việc khách hàng nghiệm thu.

  • C (Scope control và Quality assurance) — ⚠ sai cả hai vế.

  • B (Refactoring và Scope validation) — ⚠ vế đầu sai: ⚠ refactoring là cải thiện cấu trúc mã mà không đổi hành vi, ⚠ không phải kiểm thử và đo lường.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25591 ở lô trước hỏi thẳng thứ tự Control Quality trước Validate Scope, và câu #25636 ở lô này phân biệt QA với QC. ⚠ Ba câu cùng một chuỗi khái niệm.

⚠ Chuỗi từ công việc tới nghiệm thu: | Bước | Quy trình | Đầu ra | |---|---|---| | ⚠ 1 | ⚠ Direct and Manage Project Work | ⚠ deliverables — bàn giao thô | | ⚠ 2 | ⚠ Control Quality | ⚠ VERIFIED deliverables — bàn giao đã xác minh | | ⚠ 3 | ⚠ Validate Scope | ⚠ ACCEPTED deliverables — bàn giao được chấp nhận | | ⚠ 4 | ⚠ Close Project or Phase | ⚠ bàn giao sản phẩm cuối cùng | | ⚠ Bẫy thi | ⚠ đảo thứ tự bước 2 và bước 3 — đưa hàng chưa kiểm cho khách xem |

⚠ Bảng phân biệt bốn quy trình dễ lẫn: | Quy trình | Ai làm | Kiểm cái gì | Mục đích | |---|---|---|---| | ⚠ Manage Quality (QA) | ⚠ bộ phận chất lượng | ⚠ QUY TRÌNH | ⚠ cải tiến cách làm | | ⚠ Control Quality (QC) | ⚠ đội dự án | ⚠ SẢN PHẨM | ⚠ đúng yêu cầu kỹ thuật chưa | | ⚠ Validate Scope | ⚠ KHÁCH HÀNG | ⚠ SẢN PHẨM | ⚠ chấp nhận chính thức | | ⚠ Control Scope | ⚠ quản lý dự án | ⚠ PHẠM VI | ⚠ ngăn scope creep |

Từ khoá nhận diện:

"đội kiểm thử, đo, lấy mẫu" → ⚠ Control Quality "khách hàng ký nhận, cho đi tiếp" → ⚠ Validate Scope "kiểm toán quy trình làm việc" → ⚠ Manage Quality "phạm vi phình ra" → ⚠ Control Scope

⚠ Vì sao thứ tự QC trước Validate Scope quan trọng Lý do
⚠ Đưa hàng lỗi cho khách xem là mất uy tín
⚠ Sửa lỗi sau khi khách thấy đắt hơn nhiều
⚠ Khách hàng không phải người tìm lỗi kỹ thuật của bạn
⚠ Đội trong đề đã làm đúng ⚠ áp dụng hành động khắc phục TRƯỚC khi khách kiểm tra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bàn giao đã qua QC chưa trước khi mời khách nghiệm thu | | | Tiêu chí nghiệm thu đã thống nhất từ đầu chưa | ⚠ thiếu là tranh cãi lúc bàn giao | | Ai là người có thẩm quyền ký chấp nhận | |

Và ranh giới cần thuộc: QC là ĐỘI TỰ kiểm, Validate Scope là KHÁCH kiểm. Cùng nhìn vào một sản phẩm nhưng khác người, khác mục đích và bắt buộc khác thứ tự.

Câu 146
Beth is the project manager of the GHV Project for her organization. Her project is to install new software at 450 sites around the world over the next year. Management has asked Beth to create a cost estimate for the project, but Beth says it will be difficult to provide an accurate cost estimate because of the travel costs fluctuating in the project. What type of costs are the travel costs in this project?
  1. A Indirect costs
  2. B Variable costs
  3. C Direct costs
  4. D Fluctuating costs
Xem giải thích

Đáp án

B — Variable costs (chi phí biến đổi).

Vì sao đúng

⚠ Vì sao chi phí đi lại là chi phí biến đổi: | Lý do | Nội dung | |---|---| | ⚠ Thay đổi theo KHỐI LƯỢNG công việc | ⚠ càng nhiều điểm lắp đặt càng nhiều chuyến đi | | ⚠ 450 điểm trên toàn thế giới | ⚠ mỗi điểm phát sinh chi phí đi lại riêng | | ⚠ Giá vé và khách sạn BIẾN ĐỘNG | ⚠ đúng chữ "fluctuating" trong đề | | ⚠ Kết luận | ⚠ không cố định, phụ thuộc khối lượng — đúng định nghĩa chi phí biến đổi |

Vì sao các phương án khác sai

  • C (Direct costs — chi phí trực tiếp) — ⚠ cũng ĐÚNG một phần: ⚠ chi phí đi lại quy được trực tiếp cho dự án. ⚠ Nhưng "trực tiếp/gián tiếp" trả lời câu hỏi "quy cho ai", còn đề hỏi vì sao khó ước lượng — tức là hỏi tính BIẾN ĐỘNG. ⚠ Trục phân loại phù hợp với câu hỏi là cố định/biến đổi.

  • A (Indirect costs — chi phí gián tiếp) — ⚠ SAI: ⚠ chi phí gián tiếp là khoản chia sẻ cho nhiều dự án (⚠ tiền điện văn phòng, lương bộ phận hành chính); ⚠ vé máy bay của dự án này chỉ thuộc dự án này.

  • D (Fluctuating costs) — ⚠ không phải thuật ngữ PMBOK.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25634 ở lô này về chi phí chìm. ⚠ Cả hai thuộc bộ khái niệm phân loại chi phí — bảng đầy đủ dưới đây.

⚠ Bốn cặp phân loại chi phí — HAI TRỤC ĐỘC LẬP: | Trục | Cặp | Phân biệt theo | |---|---|---| | ⚠ Trục 1 | ⚠ Fixed / Variable | ⚠ có thay đổi theo khối lượng không | | ⚠ Trục 2 | ⚠ Direct / Indirect | ⚠ quy được cho một dự án hay chia sẻ nhiều dự án | | ⚠ Lưu ý quan trọng | ⚠ một khoản chi có thể VỪA trực tiếp VỪA biến đổi — hai trục không loại trừ nhau |

⚠ Ví dụ cho từng ô: | Loại | Ví dụ | |---|---| | ⚠ Cố định + trực tiếp | ⚠ thuê một thiết bị chuyên dụng cho riêng dự án, trả trọn gói | | ⚠ Biến đổi + trực tiếp | ⚠ chi phí đi lại theo số điểm lắp đặt — CÂU NÀY | | ⚠ Cố định + gián tiếp | ⚠ tiền thuê văn phòng chia cho các dự án | | ⚠ Biến đổi + gián tiếp | ⚠ tiền điện theo mức sử dụng, chia cho các dự án |

Từ khoá nhận diện:

"thay đổi theo số lượng, theo khối lượng" → ⚠ variable "không đổi dù làm ít hay nhiều" → ⚠ fixed "quy thẳng cho dự án này" → ⚠ direct "chia sẻ với nhiều dự án" → ⚠ indirect "đã chi, không thu hồi" → ⚠ sunk "giá trị lựa chọn bị bỏ qua" → ⚠ opportunity

⚠ Beth nên xử lý bài toán này thế nào Cách
⚠ Ước lượng theo ĐƠN GIÁ đi lại trung bình mỗi điểm ⚠ kỹ thuật parametric
⚠ Chia nhóm theo khu vực địa lý ⚠ chi phí bay nội địa khác bay quốc tế rất nhiều
⚠ Dùng ước lượng BA ĐIỂM cho phần biến động ⚠ lạc quan, khả dĩ, bi quan
⚠ Lập DỰ PHÒNG cho biến động giá vé ⚠ contingency reserve, có căn cứ
⚠ Gộp các điểm gần nhau vào một chuyến ⚠ giảm cả chi phí lẫn biến động
⚠ Đừng ⚠ đệm ngầm 10% vào mỗi hoạt động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí nào trong dự án biến đổi theo khối lượng | ⚠ đó là chỗ rủi ro ngân sách lớn nhất | | Bạn có đơn giá đáng tin cho phần biến đổi không | | | Dự phòng đã lập công khai chưa | |

Và điều Beth nói với lãnh đạo là hợp lý: chi phí biến đổi lớn khiến ước lượng chính xác trở nên khó. Cách trả lời chuyên nghiệp không phải là từ chối đưa số, mà là đưa số kèm dải sai số và một khoản dự phòng có căn cứ.

Câu 147
Hans is the project manager for his organization and management has asked him to help choose a project. Project A is worth $450,000 and will take 18 months to complete. Project B is worth $560,000 but will take two years to complete. A third project is worth $301,000 and will take 25 months to complete. If Hans recommends Project A what is the opportunity cost in this scenario?
  1. A $560,000
  2. B $301,000
  3. C $450,000
  4. D $861,000
Xem giải thích

Đáp án

D — 861.000.

Vì sao đúng theo khoá đề

⚠ Cách tính của đề: | Dự án | Giá trị | Được chọn? | |---|---|---| | ⚠ Dự án A | ⚠ 450.000, 18 tháng | ⚠ ĐƯỢC CHỌN | | ⚠ Dự án B | ⚠ 560.000, 24 tháng | ⚠ bị bỏ | | ⚠ Dự án thứ ba | ⚠ 301.000, 25 tháng | ⚠ bị bỏ | | ⚠ Tổng giá trị bị bỏ | ⚠ 560.000 + 301.000 = 861.000 | |

Vì sao các phương án khác sai theo khoá đề

  • A (560.000) — ⚠ là giá trị của dự án B, ⚠ tức chỉ một trong hai dự án bị bỏ.

  • B (301.000) — ⚠ là giá trị của dự án thứ ba.

  • C (450.000) — ⚠ là giá trị dự án ĐƯỢC CHỌN, ⚠ không phải chi phí cơ hội.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Định nghĩa KINH ĐIỂN của chi phí cơ hội là "giá trị của lựa chọn TỐT NHẤT bị bỏ qua", ⚠ tức là ⚠ 560.000 — phương án A. ⚠ Khoá đề lại ⚠ CỘNG giá trị của CẢ HAI dự án bị bỏ ⚠ để ra 861.000. ⚠ Đây là cách hiểu ít phổ biến hơn và không khớp với định nghĩa kinh tế học chuẩn — ⚠ theo cách hiểu chuẩn, ta chỉ có thể chọn MỘT dự án nên chỉ mất MỘT cơ hội tốt nhất, không mất cả hai cộng dồn. ⚠ Giữ nguyên khoá đáp án D theo nguồn đề, nhưng khi thi ⚠ hãy đọc kỹ phương án: nếu chỉ có hai dự án thì hai cách hiểu cho cùng kết quả; nếu có từ ba dự án trở lên, hãy xem giá trị dự án tốt nhất bị bỏ có nằm trong danh sách phương án không — nếu có, đó nhiều khả năng là đáp án mong đợi.

⚠ Định nghĩa chuẩn để nắm chắc: | Điều | Nội dung | |---|---| | ⚠ Chi phí cơ hội = giá trị của lựa chọn TỐT NHẤT bị bỏ qua | | | ⚠ Không phải tổng của mọi lựa chọn bị bỏ | ⚠ theo kinh tế học chuẩn | | ⚠ Ví dụ hai dự án: chọn A 450.000, bỏ B 560.000 | ⚠ chi phí cơ hội = 560.000 | | ⚠ Ý nghĩa | ⚠ cái ta đánh mất khi chọn cái này thay vì cái kia |

Từ khoá nhận diện:

"chi phí cơ hội" → ⚠ giá trị của cái bị bỏ qua, KHÔNG phải cái được chọn "tiền đã chi, không thu hồi" → ⚠ sunk cost "chọn A hay chọn B" → ⚠ bài toán lựa chọn dự án

⚠ Câu hỏi đặt ra về quyết định của Hans Câu hỏi
⚠ Vì sao chọn A khi B có giá trị cao hơn ⚠ A xong sau 18 tháng, B mất 24 tháng
⚠ Giá trị theo THÁNG là bao nhiêu ⚠ A: 450.000/18 = 25.000/tháng; B: 560.000/24 ≈ 23.333/tháng; C: 301.000/25 = 12.040/tháng
⚠ Tính theo tốc độ tạo giá trị thì A tốt nhất ⚠ đây có thể là lý do Hans khuyến nghị A
⚠ Bài học ⚠ chọn dự án không chỉ nhìn con số tuyệt đối
⚠ Các phương pháp chọn dự án hay ra thi Phương pháp
⚠ NPV — giá trị hiện tại ròng ⚠ chọn NPV CAO nhất; NPV âm thì không nên làm
⚠ IRR — tỷ suất hoàn vốn nội bộ ⚠ chọn IRR cao nhất
⚠ Payback period — thời gian hoàn vốn ⚠ chọn NGẮN nhất; không tính giá trị tiền theo thời gian
⚠ BCR — tỷ số lợi ích trên chi phí ⚠ lớn hơn 1 là có lợi, chọn cái CAO nhất
⚠ Lưu ý ⚠ chi phí chìm KHÔNG bao giờ đưa vào các phép tính này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề hỏi giá trị bị bỏ hay giá trị được chọn | ⚠ đọc kỹ, đây là bẫy thường gặp | | Có bao nhiêu lựa chọn bị bỏ | ⚠ quyết định cách tính theo nguồn đề | | Giá trị các phương án có nằm trong danh sách không | ⚠ giúp đoán ý đồ của người soạn đề |

Và điều quan trọng nhất rút ra: chi phí cơ hội luôn là giá trị của thứ BẠN KHÔNG CHỌN. Dù cộng một hay cộng cả hai, đáp án không bao giờ là giá trị của dự án được chọn.

Câu 148
You are the project manager of the JKL Project for your organization and you’re meeting with the project team. It’s come to your attention that the project team has padded every activity duration in the project schedule by 10-12 hours. You explain to the team that this padding isn’t acceptable and they need to identify accurate duration estimates to predict the duration of the project. What law describes the danger of padding activity duration estimates?
  1. A Parkinson’s Law
  2. B Law of Diminishing Returns
  3. C Moore’s Law
  4. D Little’s Law
Xem giải thích

Đáp án

A — Parkinson's Law (Định luật Parkinson).

Vì sao đúng

⚠ Định luật Parkinson:

⚠ "Công việc nở ra để lấp đầy thời gian được cấp cho nó."

Hệ quả với việc đệm lịch Nội dung
⚠ Cho một việc 10 giờ thì nó tốn 10 giờ
⚠ Cho cùng việc đó 20 giờ thì nó tốn 20 giờ
⚠ Phần đệm KHÔNG BAO GIỜ được tiết kiệm lại ⚠ nó bị tiêu hết
⚠ Vì thế đệm 10–12 giờ mỗi việc là mất trắng
⚠ Kết luận ⚠ đệm không làm dự án an toàn hơn, chỉ làm nó DÀI hơn

Vì sao các phương án khác sai

  • B (Law of Diminishing Returns — quy luật lợi ích cận biên giảm dần) — ⚠ nói rằng thêm một đơn vị đầu vào mang lại lợi ích ngày càng ít; ⚠ liên quan tới việc thêm người, không liên quan tới đệm lịch.

  • C (Moore's Law — định luật Moore) — ⚠ số bóng bán dẫn trên vi mạch tăng gấp đôi khoảng mỗi hai năm; ⚠ thuộc lĩnh vực phần cứng máy tính.

  • D (Little's Law — định luật Little) — ⚠ thời gian trong hệ thống = số việc đang xử lý / tốc độ hoàn thành; ⚠ dùng trong Kanban để giảm việc dở dang, ⚠ không nói về đệm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25645 ở lô này — ⚠ Tom cộng 10% vì "nhà cung cấp luôn trễ". ⚠ Câu đó bàn về bản chất giả định của việc đệm; câu này giải thích vì sao đệm có hại.

⚠ Ba hiệu ứng khiến phần đệm luôn biến mất: | Hiệu ứng | Nội dung | |---|---| | ⚠ Định luật Parkinson | ⚠ công việc nở ra lấp đầy thời gian được cấp | | ⚠ Hội chứng sinh viên | ⚠ student syndrome — người ta chỉ bắt đầu làm khi sắp tới hạn | | ⚠ Không báo cáo xong sớm | ⚠ xong sớm cũng giữ lại, sợ lần sau bị cắt thời gian | | ⚠ Kết quả | ⚠ đệm bị tiêu hết mà dự án vẫn trễ khi có sự cố thật |

Từ khoá nhận diện:

"công việc nở ra lấp đầy thời gian" → ⚠ Parkinson "thêm nguồn lực nhưng lợi ích giảm dần" → ⚠ diminishing returns "giảm việc dở dang để rút ngắn thời gian chờ" → ⚠ Little's Law "số bóng bán dẫn gấp đôi" → ⚠ Moore

⚠ Cách làm ĐÚNG thay cho đệm ngầm Cách
⚠ Ước lượng TRUNG THỰC cho từng hoạt động ⚠ không đệm
⚠ Gộp phần dự phòng vào MỘT khoản CHUNG ⚠ contingency reserve, công khai
⚠ Dựa trên phân tích rủi ro thật
⚠ Theo dõi mức tiêu dự phòng ⚠ thấy được dự án đang tiêu nhanh hay chậm
⚠ Đây là ý tưởng nền của ⚠ critical chain method — gộp đệm cá nhân thành project buffer
⚠ Critical Chain Method — vì sao liên quan Nội dung
⚠ Bỏ hết phần đệm trong từng hoạt động
⚠ Gộp lại thành BUFFER đặt ở cuối chuỗi
⚠ Có feeding buffer cho các nhánh phụ
⚠ Tính cả ràng buộc NGUỒN LỰC, không chỉ ràng buộc logic
⚠ Kết quả ⚠ tổng đệm cần dùng NHỎ hơn tổng các phần đệm rời rạc
⚠ Vì sao đội hay đệm lịch Lý do
⚠ Sợ bị trách khi trễ
⚠ Từng bị cắt ước lượng nên đệm trước cho chắc
⚠ Không có cơ chế dự phòng chính thức
⚠ PM nên làm gì ⚠ tạo môi trường an toàn để ước lượng trung thực, và lập dự phòng công khai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng của đội có phần đệm ngầm không | ⚠ hỏi thẳng, không phạt | | Dự án có khoản dự phòng công khai chưa | | | Việc xong sớm có được báo cáo không | ⚠ nếu không thì môi trường đang khuyến khích giấu |

Và câu tổng kết đáng nhớ: đệm cá nhân bảo vệ cá nhân, dự phòng chung bảo vệ dự án. Định luật Parkinson giải thích chính xác vì sao vế đầu luôn thất bại.

Câu 149
You are the project manager of the NKQ Project and you’re working with your project team to define some reasons why several defects have slipped past your testing into production. There are lots of potential reasons why the defects have passed through. What term is given to these defects?
  1. A Passed defects
  2. B Poor inspections
  3. C Found defects
  4. D Escaped defects
Xem giải thích

Đáp án

D — Escaped defects (lỗi lọt lưới).

Vì sao đúng

⚠ Escaped defect là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Lỗi ĐÃ TỒN TẠI trong sản phẩm | | | ⚠ KHÔNG bị phát hiện trong quá trình kiểm thử | | | ⚠ LỌT ra tới môi trường VẬN HÀNH | | | ⚠ Người dùng thật gặp phải nó | | | ⚠ Là | ⚠ thước đo trực tiếp cho hiệu quả của khâu kiểm thử |

Vì sao các phương án khác sai

  • B (Poor inspections — kiểm tra kém) — ⚠ là NGUYÊN NHÂN có thể có, ⚠ không phải TÊN GỌI của các lỗi đó.

  • A (Passed defects) và C (Found defects) — ⚠ không phải thuật ngữ chuẩn; ⚠ "found defects" nếu có nghĩa thì lại là lỗi ĐÃ tìm thấy — ngược hẳn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25628 ở lô này — ⚠ bỏ kiểm thử để kịp hạn khiến lỗi lọt ra vận hành, ⚠ và câu #25595 ở lô trước về external defects. ⚠ Ba câu cùng chủ đề: lỗi lọt lưới là biểu hiện, chi phí lỗi bên ngoài là hậu quả.

⚠ Vì sao chỉ số này quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Đo trực tiếp CHẤT LƯỢNG của quy trình kiểm thử | | | ⚠ Chi phí sửa lỗi lọt lưới CAO nhất trong bốn loại | ⚠ external failure cost | | ⚠ Ảnh hưởng trực tiếp tới người dùng và uy tín | | | ⚠ Công thức hay dùng | ⚠ defect escape rate = lỗi lọt / (lỗi lọt + lỗi bắt được), tính theo kỳ phát hành |

Từ khoá nhận diện:

"lỗi lọt qua kiểm thử vào vận hành" → ⚠ escaped defect "chi phí do lỗi tới tay khách" → ⚠ external failure cost "lỗi bắt được trước khi giao" → ⚠ internal failure cost "ngăn lỗi phát sinh" → ⚠ prevention cost

⚠ Nguyên nhân thường gặp của lỗi lọt lưới Nguyên nhân
⚠ Độ phủ kiểm thử thấp ⚠ có nhánh mã chưa bao giờ được chạy
⚠ Môi trường kiểm thử khác môi trường thật ⚠ dữ liệu, cấu hình, quy mô
⚠ Bỏ bớt kiểm thử để kịp hạn ⚠ nguyên nhân của câu #25628
⚠ Yêu cầu mơ hồ nên không biết phải kiểm gì
⚠ Kiểm thử hồi quy không đủ ⚠ sửa chỗ này hỏng chỗ kia
⚠ Thiếu kiểm thử trường hợp biên
⚠ Cách giảm lỗi lọt lưới Cách
⚠ Phân tích nguyên nhân gốc cho MỖI lỗi lọt ⚠ dùng Ishikawa và 5 Whys
⚠ Bổ sung ca kiểm thử cho mỗi lỗi tìm được ở vận hành ⚠ để nó không tái diễn
⚠ Dịch việc kiểm thử về phía SỚM ⚠ shift left — kiểm ngay khi viết mã
⚠ Làm môi trường kiểm thử giống môi trường thật
⚠ Đo và theo dõi tỷ lệ lọt theo thời gian ⚠ tăng là dấu hiệu quy trình xuống cấp

⚠ Đối chiếu: ⚠ câu #25664 ở lô này về Ishikawa — ⚠ đó chính là công cụ để phân tích "rất nhiều lý do tiềm tàng" mà đề nhắc tới.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ĐO tỷ lệ lỗi lọt lưới không | ⚠ không đo thì không biết kiểm thử có hiệu quả không | | Mỗi lỗi lọt có được truy nguyên nhân gốc không | | | Có ca kiểm thử mới cho từng lỗi đã lọt chưa | |

Và cách nhìn đúng về loại lỗi này: mỗi lỗi lọt lưới là một bài học miễn phí về chỗ hổng của quy trình kiểm thử. Sửa lỗi mà không sửa chỗ hổng thì lỗi tiếp theo cũng sẽ lọt qua đúng cửa đó.

Câu 150
Consider a project to create a new house for a customer. The customer describes the home as a three-bedroom house. They go on to define the square footage, how the home will be used, the look and feel of the home, the type of flooring, the appliances, and more and more detail as you work with the customer to capture all of the requirements. What is this process called?
  1. A Choice generation
  2. B Decomposition
  3. C Progressive elaboration
  4. D Painful
Xem giải thích

Đáp án

C — Progressive elaboration (chi tiết hoá tuần tự).

Vì sao đúng

⚠ Diễn tiến trong đề: | Bước | Mức chi tiết | |---|---| | ⚠ "một ngôi nhà ba phòng ngủ" | ⚠ mức RẤT THÔ | | ⚠ Thêm diện tích sàn | ⚠ chi tiết hơn | | ⚠ Thêm cách sử dụng, phong cách | ⚠ chi tiết hơn nữa | | ⚠ Thêm loại sàn, thiết bị gia dụng | ⚠ rất chi tiết | | ⚠ Đây chính là | ⚠ progressive elaboration — làm rõ dần theo thời gian khi có thêm thông tin |

Vì sao các phương án khác sai

  • B (Decomposition — phân rã) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ phân rã là ⚠ CHIA NHỎ công việc đã biết thành các phần (⚠ tạo WBS); ⚠ ở đây không chia nhỏ mà là ⚠ LÀM RÕ DẦN thứ ban đầu còn mơ hồ — hai việc khác nhau.

  • A (Choice generation) — ⚠ không phải thuật ngữ PMBOK.

  • D (Painful) — ⚠ là phương án đùa, không phải thuật ngữ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25627 ở lô trước về planning package — ⚠ đó chính là cơ chế trong WBS cho phép chi tiết hoá tuần tự.

⚠ Progressive elaboration: | Đặc điểm | Nội dung | |---|---| | ⚠ Là ĐẶC TRƯNG của mọi dự án | ⚠ không phải một kỹ thuật riêng lẻ | | ⚠ Bắt đầu ở mức khái quát, chi tiết dần | | | ⚠ Diễn ra LIÊN TỤC suốt vòng đời dự án | | | ⚠ Cho phép làm việc với thông tin chưa đầy đủ | | | ⚠ Đừng nhầm với | ⚠ scope creep — chi tiết hoá là LÀM RÕ thứ đã thoả thuận, scope creep là THÊM thứ chưa ai duyệt |

⚠ Ba khái niệm dễ lẫn: | Khái niệm | Nghĩa | |---|---| | ⚠ Progressive elaboration | ⚠ làm RÕ DẦN thứ còn mơ hồ khi có thêm thông tin | | ⚠ Rolling wave planning | ⚠ một DẠNG cụ thể: lập kế hoạch chi tiết cho phần gần, để thô phần xa | | ⚠ Decomposition | ⚠ CHIA NHỎ công việc đã biết thành các phần cấu thành |

Từ khoá nhận diện:

"chi tiết dần theo thời gian, ban đầu còn mơ hồ" → ⚠ progressive elaboration "lập kế hoạch chi tiết phần sắp tới, phần xa để thô" → ⚠ rolling wave planning "chia gói công việc thành hoạt động" → ⚠ decomposition "thêm yêu cầu mới không ai duyệt" → ⚠ scope creep

⚠ Ranh giới giữa chi tiết hoá và scope creep Phân biệt
⚠ "Sàn gỗ sồi" thay cho "sàn gỗ" ⚠ CHI TIẾT HOÁ — làm rõ thứ đã có
⚠ "Thêm một phòng ngủ thứ tư" ⚠ SCOPE CREEP — thêm thứ chưa có
⚠ Câu hỏi kiểm tra ⚠ "điều này đã nằm trong thoả thuận ban đầu chưa, chỉ là chưa nói rõ?"
⚠ Nếu câu trả lời là không ⚠ phải đưa qua kiểm soát thay đổi
⚠ Vì sao khái niệm này quan trọng với PM Lý do
⚠ Không dự án nào biết hết mọi thứ từ đầu
⚠ Ép chi tiết quá sớm là lãng phí và tạo cảm giác chắc chắn giả
⚠ Nhưng để mơ hồ quá lâu thì không ước lượng được
⚠ Cân bằng ⚠ chi tiết vừa đủ để ra quyết định tiếp theo, không hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu của bạn đã đủ rõ để ước lượng chưa | | | Việc làm rõ có bị dùng làm cửa để thêm phạm vi không | ⚠ ranh giới rất mỏng, phải tỉnh táo | | Đường cơ sở phạm vi có được cập nhật khi chi tiết hoá không | |

Và điều cần nhắc khách hàng: làm rõ chi tiết thì được, thêm phòng ngủ thì phải mở yêu cầu thay đổi. Cùng một cuộc trò chuyện có thể chứa cả hai — việc của PM là nhận ra chúng khác nhau.