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

Tìm thấy 720 câu.

Câu 51 Process
Chandler is a scrum master working with multiple other scrum masters to develop national accounting software to process tax documents. Julie is the key sponsor, and one of her requirements for the project is transparency and consistency in gathering scrum artifacts. Given the size of the project and the number of scrum teams involved, what is Chandler most likely to consider in meeting Julie's expectations?
  1. A Purchase a task management tool that comes with artifact features.
  2. B Recommend hiring multiple administrators to help teams organize artifacts.
  3. C Suggest that agile has no focus on documentation, and capturing artifacts is a bad idea.
  4. D Make artifacts a hard requirement from each employee.
Xem giải thích

Đáp án

A — Mua một công cụ quản lý công việc có sẵn tính năng quản lý artifact.

Vì sao đúng

⚠ Bài toán của Chandler: | Yêu cầu | Nội dung | |---|---| | ⚠ NHIỀU đội Scrum cùng làm một sản phẩm | ⚠ quy mô lớn | | ⚠ Nhà tài trợ đòi MINH BẠCH | ⚠ ai cũng thấy được trạng thái | | ⚠ Nhà tài trợ đòi NHẤT QUÁN | ⚠ các đội thu thập artifact theo cùng một cách | | ⚠ Giải pháp | ⚠ một CÔNG CỤ dùng chung tự nhiên tạo ra cả minh bạch lẫn nhất quán |

⚠ Vì sao công cụ giải quyết được cả hai: | Yêu cầu | Công cụ đáp ứng thế nào | |---|---| | ⚠ Minh bạch | ⚠ mọi người xem cùng một nguồn dữ liệu, cập nhật thời gian thực | | ⚠ Nhất quán | ⚠ cùng biểu mẫu, cùng trường dữ liệu, cùng quy trình | | ⚠ Quy mô lớn | ⚠ tổng hợp được dữ liệu từ nhiều đội tự động | | ⚠ Bổ sung | ⚠ giảm công sức thủ công so với việc mỗi đội tự làm bảng tính riêng |

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

  • C (nói agile không quan tâm tài liệu, thu thập artifact là ý tồi) — ⚠ HIỂU SAI agile: ⚠ tuyên ngôn nói ⚠ "phần mềm chạy được HƠN tài liệu đầy đủ" — ⚠ hơn chứ không phải thay thế; ⚠ artifact của Scrum (product backlog, sprint backlog, increment) là ⚠ BẮT BUỘC.

  • B (thuê nhiều nhân viên hành chính giúp các đội sắp xếp artifact) — ⚠ tốn kém và không bền; ⚠ và người ngoài đội cập nhật artifact thì dữ liệu dễ lỗi thời.

  • D (bắt buộc mọi nhân viên phải làm artifact) — ⚠ áp đặt mà không cung cấp phương tiện; ⚠ mệnh lệnh không tạo ra sự nhất quán, công cụ mới tạo ra.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25760 ở lô này về tài liệu khó tìm vì cấu trúc lộn xộn và câu #25772 về phần mềm chạy được là thước đo chính. ⚠ Ba câu cùng làm rõ một điểm: agile KHÔNG bỏ tài liệu, chỉ bỏ tài liệu THỪA.

⚠ Ba artifact của Scrum — đều BẮT BUỘC: | Artifact | Nội dung | Cam kết đi kèm | |---|---|---| | ⚠ Product Backlog | ⚠ danh sách mọi thứ cần làm cho sản phẩm | ⚠ Product Goal | | ⚠ Sprint Backlog | ⚠ phần việc đội nhận cho sprint hiện tại | ⚠ Sprint Goal | | ⚠ Increment | ⚠ phần sản phẩm hoàn thiện sau mỗi sprint | ⚠ Definition of Done | | ⚠ Nguyên tắc | ⚠ cả ba phải MINH BẠCH — đó chính là điều Julie yêu cầu |

Từ khoá nhận diện:

"nhiều đội, cần minh bạch và nhất quán" → ⚠ công cụ dùng chung "agile không cần tài liệu" → ⚠ HIỂU SAI, luôn là đáp án sai "thuê thêm người làm hành chính" → ⚠ thường không bền vững "ra mệnh lệnh bắt buộc" → ⚠ không tạo ra sự nhất quán thật

⚠ Thách thức của agile ở QUY MÔ LỚN Thách thức
⚠ Đồng bộ giữa nhiều đội
⚠ Phụ thuộc chéo giữa các đội
⚠ Tổng hợp trạng thái để báo cáo lên trên ⚠ đúng nhu cầu của Julie
⚠ Giữ nhất quán về Definition of Done
⚠ Các khung mở rộng ⚠ SAFe, LeSS, Scrum of Scrums, Nexus — đều nhấn mạnh minh bạch xuyên đội
⚠ Lưu ý khi chọn công cụ Lưu ý
⚠ Công cụ PHỤC VỤ quy trình, không định nghĩa quy trình
⚠ Đừng mua công cụ rồi bắt đội đổi cách làm cho vừa công cụ
⚠ Đội phải được tham gia chọn ⚠ họ là người dùng hằng ngày
⚠ Cần đào tạo và quy ước sử dụng chung ⚠ công cụ chung mà mỗi đội dùng một kiểu thì vẫn không nhất quán
⚠ Nhớ giá trị đầu tiên của tuyên ngôn ⚠ cá nhân và tương tác HƠN quy trình và công cụ — công cụ là phương tiện, không phải mục đích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các đội có dùng cùng một định nghĩa DONE không | | | Nhà tài trợ có xem được trạng thái mà không cần hỏi ai không | | | Việc cập nhật công cụ có tốn quá nhiều thời gian của đội không | |

Và ranh giới cần giữ: công cụ tạo ra minh bạch, nhưng chỉ khi đội thật sự dùng nó. Một công cụ đắt tiền mà dữ liệu lỗi thời còn tệ hơn một bảng trắng được cập nhật hằng ngày.

Câu 52 Process
You are the project manager for your organization, leading a predictive project to create a new software application. In managing this software development project, you realize that your project is slipping behind schedule. There is a bottleneck in the project, waiting for specific tasks to be completed by three key developers. Funds are running low in the budget, but some scheduled activities are able to be completed in differing orders. What is the best option for getting this project back on schedule?
  1. A Cut scope out of the project.
  2. B Hire more software developers.
  3. C The project cannot get back on schedule without extra funding for hiring.
  4. D Fast-track some of the activities.
Xem giải thích

Đáp án

D — FAST-TRACK một số hoạt động (chạy song song).

Vì sao đúng

⚠ Ba dấu hiệu trong đề chỉ thẳng tới fast-tracking: | Dấu hiệu | Suy ra | |---|---| | ⚠ Dự án đang CHẬM tiến độ | ⚠ cần nén lịch | | ⚠ NGÂN SÁCH gần cạn | ⚠ → LOẠI crashing, vì crashing tốn thêm tiền | | ⚠ "một số hoạt động có thể làm theo THỨ TỰ KHÁC NHAU" | ⚠ → đây là SOFT LOGIC, chạy song song được | | ⚠ Kết luận | ⚠ fast-tracking là lựa chọn duy nhất vừa rút ngắn lịch vừa không tốn thêm tiền |

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

  • B (thuê thêm lập trình viên) — ⚠ chính là CRASHING, ⚠ mà đề nói rõ ⚠ ngân sách gần cạn; ⚠ thêm nữa, ⚠ định luật Brooks: thêm người vào dự án phần mềm đang chậm thường làm nó chậm hơn.

  • C (không thể về đúng tiến độ nếu không có thêm kinh phí) — ⚠ SAI: ⚠ fast-tracking không cần thêm tiền.

  • A (cắt bớt phạm vi) — ⚠ là một phương án CÓ THẬT nhưng phải qua PHÊ DUYỆT của nhà tài trợ và khách hàng; ⚠ đề hỏi ⚠ "lựa chọn TỐT NHẤT", và fast-tracking nằm trong thẩm quyền của đội mà không phải hy sinh giá trị bàn giao.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25665 ở lô 179 về điều kiện để crashing, câu #25642 ở lô 178 về soft logic, và câu #25658 về đường găng. ⚠ Bốn câu tạo thành bộ đầy đủ về nén lịch trình.

⚠ Hai kỹ thuật nén lịch — bảng so sánh: | Tiêu chí | Crashing | Fast tracking | |---|---|---| | ⚠ Cách làm | ⚠ thêm NGUỒN LỰC | ⚠ chạy SONG SONG việc vốn nối tiếp | | ⚠ Chi phí | ⚠ TĂNG | ⚠ thường không tăng | | ⚠ Rủi ro | ⚠ tăng nhẹ | ⚠ TĂNG ĐÁNG KỂ — có thể phải làm lại | | ⚠ Điều kiện | ⚠ việc phải phụ thuộc CÔNG SỨC | ⚠ phụ thuộc phải là SOFT LOGIC | | ⚠ Áp dụng ở đâu | ⚠ ĐƯỜNG GĂNG | ⚠ ĐƯỜNG GĂNG | | ⚠ Chọn cái nào | ⚠ hết tiền → fast-track; sợ rủi ro làm lại → crash |

Từ khoá nhận diện:

"ngân sách cạn, cần rút ngắn lịch" → ⚠ fast tracking "thêm người, thêm ca" → ⚠ crashing, tốn tiền "việc có thể làm theo thứ tự khác" → ⚠ soft logic, fast-track được "cắt phạm vi" → ⚠ phải xin phê duyệt, không phải lựa chọn đầu tiên

⚠ Rủi ro của fast-tracking cần quản lý Rủi ro
⚠ Việc sau bắt đầu khi việc trước chưa xong hẳn ⚠ nếu việc trước thay đổi thì phải LÀM LẠI
⚠ Tăng nhu cầu phối hợp và giao tiếp
⚠ Dễ phát sinh lỗi tích hợp
⚠ Cách giảm rủi ro ⚠ chỉ chồng lấn phần ỔN ĐỊNH; tăng tần suất đồng bộ; chuẩn bị phương án nếu phải làm lại
⚠ Còn nút thắt ba lập trình viên chủ chốt thì sao Xử lý
⚠ Đây là bài toán NGUỒN LỰC, không chỉ là bài toán lịch
⚠ Kiểm tra họ có đang bị phân tán sang việc khác không
⚠ Xem có việc nào chuyển được cho người khác không
⚠ Cân nhắc SAN BẰNG hoặc LÀM MƯỢT nguồn lực ⚠ smoothing không kéo dài dự án, levelling thì có thể
⚠ Fast-tracking giúp gì ⚠ đưa các việc KHÔNG cần ba người đó chạy song song, giảm thời gian chờ
⚠ Sau khi nén lịch phải làm gì Việc
⚠ TÍNH LẠI đường găng ⚠ đường khác có thể trở thành găng
⚠ Cập nhật sổ đăng ký rủi ro ⚠ fast-tracking sinh rủi ro mới
⚠ Thông báo cho đội về thay đổi trình tự
⚠ Nếu vẫn không đủ: báo cáo và đề xuất phương án khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc bạn định chạy song song có phải soft logic thật không | ⚠ hỏi "nếu đảo thứ tự thì hỏng thật hay chỉ bất tiện?" | | Đội có đủ năng lực phối hợp khi chạy song song không | | | Bạn đã đánh giá rủi ro phải làm lại chưa | |

Và nguyên tắc chọn kỹ thuật nén lịch: hết tiền thì fast-track, hết thời gian chịu rủi ro thì crash. Ở đây đề đã nói rõ tiền gần cạn — nên chỉ còn một lựa chọn.

Câu 53 People
Sophia is the scrum master for Project X. A sprint review was just completed, and one particular stakeholder was upset that their item was not included in the previous sprint during the review. After a heated discussion, it was determined that the item would be added to the sprint after the next one. That stakeholder is now approaching Sophia to speak about that item again. What conflict strategy should Sophia use in this situation?
  1. A Avoiding
  2. B Forcing
  3. C Smoothing
  4. D Collaborating
Xem giải thích

Đáp án

A — Avoiding (né tránh).

Vì sao đúng

⚠ Vì sao né tránh phù hợp Ở ĐÂY: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề ĐÃ ĐƯỢC QUYẾT rồi | ⚠ hạng mục sẽ vào sprint sau nữa | | ⚠ Quyết định đã đạt được sau THẢO LUẬN, có sự tham gia của bên liên quan | | | ⚠ Mở lại cuộc tranh luận đã kết thúc KHÔNG tạo ra giá trị mới | | | ⚠ Không có thông tin MỚI nào được nêu ra | | | ⚠ Kết luận | ⚠ né tránh ở đây nghĩa là KHÔNG tái mở một vấn đề đã chốt, chứ không phải trốn tránh trách nhiệm |

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

  • D (Collaborating — hợp tác) — ⚠ thường là chiến lược TỐT NHẤT, ⚠ nhưng ⚠ đã được dùng rồi: ⚠ cuộc thảo luận trong sprint review chính là hợp tác, ⚠ và nó đã cho ra một quyết định.

  • B (Forcing — ép buộc) — ⚠ không cần thiết: ⚠ Sophia không phải áp đặt gì, ⚠ quyết định đã có sẵn.

  • C (Smoothing — xoa dịu) — ⚠ chỉ tạm thời làm dịu mà không giải quyết; ⚠ ở đây vấn đề đã được giải quyết thật rồi.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Trong bảng xếp hạng chuẩn của PMBOK, AVOIDING/WITHDRAWING là chiến lược ĐƯỢC ĐÁNH GIÁ THẤP NHẤT — ⚠ vì nó thường chỉ hoãn vấn đề chứ không giải quyết. ⚠ Câu này là một trong số ít trường hợp né tránh lại ĐÚNG, ⚠ và lý do nằm ở chỗ ⚠ vấn đề ĐÃ được giải quyết bằng hợp tác trước đó. ⚠ Giữ nguyên khoá A, nhưng người học cần nhớ: ⚠ nếu đề KHÔNG nói rõ vấn đề đã được quyết, thì "avoiding" gần như luôn là đáp án SAI. ⚠ PMBOK nêu ba trường hợp né tránh hợp lý: ⚠ vấn đề không quan trọng, người khác giải quyết tốt hơn, hoặc cần thời gian để thu thập thêm thông tin — ⚠ và ở đây có thể thêm trường hợp thứ tư: ⚠ vấn đề đã có quyết định và không có thông tin mới.

⚠ Năm chiến lược giải quyết xung đột — xếp hạng: | Chiến lược | Kết quả | Đánh giá | |---|---|---| | ⚠ Collaborate / Problem Solve | ⚠ win-win | ⚠ TỐT NHẤT | | ⚠ Compromise / Reconcile | ⚠ lose-lose, mỗi bên nhượng bộ | ⚠ chấp nhận được | | ⚠ Smooth / Accommodate | ⚠ nhấn mạnh điểm chung | ⚠ giải pháp tạm thời | | ⚠ Force / Direct | ⚠ win-lose | ⚠ dùng khi khẩn cấp | | ⚠ Withdraw / Avoid | ⚠ không giải quyết | ⚠ THẤP NHẤT — nhưng đúng trong trường hợp này |

Từ khoá nhận diện:

"vấn đề đã được quyết, không có thông tin mới" → ⚠ né tránh là hợp lý "cùng phân tích tìm giải pháp tốt nhất" → ⚠ collaborating "chia đôi, mỗi bên nhường" → ⚠ compromising "tôi có quyền nên tôi quyết" → ⚠ forcing

⚠ Sophia nên xử lý cụ thể thế nào Cách
⚠ Nhắc lại quyết định đã thống nhất và LÝ DO ⚠ né tránh KHÔNG có nghĩa là phớt lờ người ta
⚠ Nói rõ hạng mục đã có chỗ trong backlog
⚠ Nếu có THÔNG TIN MỚI thì sẵn sàng xem lại ⚠ đây là điều kiện để mở lại
⚠ Hướng bên liên quan tới product owner ⚠ người sở hữu thứ tự ưu tiên backlog
⚠ Điều KHÔNG nên làm ⚠ tranh luận lại từ đầu mỗi lần bên liên quan hỏi — vừa tốn thời gian vừa mở đường cho việc lật quyết định
⚠ Vì sao mở lại quyết định đã chốt lại có hại Lý do
⚠ Tốn thời gian của cả đội
⚠ Tạo tiền lệ: cứ phàn nàn đủ lâu thì quyết định sẽ đổi
⚠ Làm mất ổn định sprint đang chạy
⚠ Giảm niềm tin vào các quyết định khác
⚠ Ngoại lệ duy nhất ⚠ có THÔNG TIN MỚI làm thay đổi cơ sở của quyết định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vấn đề đã thật sự được quyết chưa | ⚠ có ghi lại không, ai đã đồng ý | | Có thông tin mới nào không | | | Người đang phàn nàn có hiểu lý do quyết định không | ⚠ có khi họ chỉ chưa được giải thích đủ |

Và ranh giới quan trọng: né tránh một vấn đề CHƯA giải quyết là trốn tránh; né tránh việc mở lại vấn đề ĐÃ giải quyết là kỷ luật. Hai điều nghe giống nhau nhưng khác hẳn nhau.

Câu 54 People
Sal is the project manager for an agile project that is ten weeks into deployment. This project is $5,000.00 under budget and one week behind schedule. Over the next few weeks, an outside consultant will be on-site to help the project team learn about new technology. One team member is concerned this will take project time. What is Sal's most likely response to this concern?
  1. A Sal wants to keep everyone busy regardless of the project scope.
  2. B The project has some extra budget to spend.
  3. C The project is only one week behind schedule, so an additional delay is acceptable.
  4. D Team development is important to project success, and the training is needed.
Xem giải thích

Đáp án

D — Phát triển đội là quan trọng đối với thành công của dự án, và việc đào tạo này là CẦN THIẾT.

Vì sao đúng

⚠ Bối cảnh và lý do: | Chi tiết | Suy ra | |---|---| | ⚠ Dự án DƯỚI ngân sách 5.000 | ⚠ có dư địa tài chính | | ⚠ Chậm một tuần | ⚠ không nghiêm trọng | | ⚠ Chuyên gia bên ngoài dạy CÔNG NGHỆ MỚI | ⚠ đội sẽ dùng công nghệ này trong dự án | | ⚠ Đội chưa có kỹ năng đó | | | ⚠ Kết luận | ⚠ đầu tư vào kỹ năng là đầu tư vào chất lượng và năng suất của phần việc còn lại |

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

  • C (chỉ chậm một tuần nên trễ thêm chút cũng chấp nhận được) — ⚠ lý luận SAI: ⚠ chấp nhận trễ thêm không phải lý do để đào tạo; ⚠ và thái độ này coi nhẹ tiến độ.

  • B (dự án còn dư ngân sách để tiêu) — ⚠ lý do TÀI CHÍNH chứ không phải lý do GIÁ TRỊ; ⚠ tiêu tiền vì còn dư là tư duy sai.

  • A (Sal muốn giữ mọi người bận rộn bất kể phạm vi) — ⚠ phản ánh quản lý tồi; ⚠ giữ người bận không phải mục tiêu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25749 ở lô này về dành thời gian cho kèm cặp và câu #25744 về trách nhiệm của quản lý cung cấp nguồn lực. ⚠ Ba câu cùng một thông điệp: đầu tư vào năng lực đội là trách nhiệm của quản lý dự án, không phải khoản chi tuỳ hứng.

⚠ Vì sao đào tạo là đầu tư chứ không phải chi phí: | Lợi ích | Nội dung | |---|---| | ⚠ Giảm LỖI do thiếu hiểu biết về công nghệ | ⚠ chi phí phòng ngừa — rẻ nhất trong bốn nhóm chi phí chất lượng | | ⚠ Tăng NĂNG SUẤT phần việc còn lại | | | ⚠ Giảm phụ thuộc vào chuyên gia bên ngoài về lâu dài | | | ⚠ Tăng ĐỘNG LỰC | ⚠ cơ hội phát triển là yếu tố động viên theo Herzberg | | ⚠ Chi phí | ⚠ thời gian ngắn hạn — đổi lấy hiệu quả dài hạn |

Từ khoá nhận diện:

"đào tạo tốn thời gian dự án" → ⚠ nhưng là đầu tư vào chất lượng và năng suất "còn dư ngân sách nên tiêu" → ⚠ lý do SAI "giữ mọi người bận rộn" → ⚠ quản lý tồi "phát triển đội" → ⚠ quy trình Develop Team, thuộc nhóm Thực hiện

⚠ Nỗi lo của thành viên đội có chính đáng không Đánh giá
⚠ CHÍNH ĐÁNG — thời gian đào tạo là thời gian không làm việc trực tiếp
⚠ Nhất là khi dự án đã chậm một tuần
⚠ Sal nên GIẢI THÍCH chứ không gạt bỏ
⚠ Cách trả lời tốt nhất ⚠ "tôi hiểu lo ngại, nhưng nếu chúng ta dùng công nghệ này mà không hiểu nó thì số giờ sửa lỗi sẽ nhiều hơn số giờ học"
⚠ Cách giảm tác động của đào tạo tới tiến độ Cách
⚠ Lên lịch đào tạo vào giai đoạn ít căng nhất
⚠ Chia nhỏ thành nhiều buổi ngắn
⚠ Đào tạo THEO NHU CẦU công việc sắp tới ⚠ just-in-time learning
⚠ Kết hợp học và làm việc thật
⚠ Cập nhật lịch trình để phản ánh thời gian đào tạo ⚠ đừng để nó thành thời gian "ẩn"
⚠ Vì sao "chậm một tuần" KHÔNG phải lý do biện minh Lý do
⚠ Chậm là chậm — không nên coi nhẹ
⚠ Lý do đào tạo phải là GIÁ TRỊ nó mang lại
⚠ Nếu đào tạo làm chậm thêm thì phải có kế hoạch bù
⚠ Sal nên ⚠ vừa khẳng định giá trị của đào tạo, vừa có kế hoạch xử lý tuần chậm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có thật sự cần công nghệ này cho phần việc còn lại không | | | Thời gian đào tạo đã nằm trong lịch chưa | | | Bạn giải thích LÝ DO hay chỉ ra thông báo | ⚠ giải thích tạo sự đồng thuận |

Và cách nói ngắn gọn nhất với đội: học ba ngày hôm nay rẻ hơn sửa ba tuần lỗi vào tháng sau. Đó là lý do đúng — không phải vì còn dư ngân sách.

Câu 55 People
You are the project manager for a new agile project. Agile is a new approach for your organization, so you are doing a lot of coaching on the agile mindset. During scope definition, Robert, the chief executive officer, and stakeholder, demands that the project obtains customer satisfaction to be successful. What is the danger of this request?
  1. A Customer satisfaction is never achieved through projects but through operations.
  2. B Customer satisfaction is not known until the customer has paid for the project.
  3. C Customer satisfaction is achieved only through measurable quality control metrics.
  4. D Customer satisfaction is not quantifiable.
Xem giải thích

Đáp án

D — Sự hài lòng của khách hàng KHÔNG ĐỊNH LƯỢNG ĐƯỢC (not quantifiable).

Vì sao đúng

⚠ Vấn đề với yêu cầu của Robert: | Vấn đề | Nội dung | |---|---| | ⚠ "Đạt được sự hài lòng của khách hàng" là mục tiêu MƠ HỒ | | | ⚠ Không có NGƯỠNG cụ thể để biết đã đạt hay chưa | | | ⚠ Không đo được thì không nghiệm thu được | | | ⚠ Không đo được thì không biết dự án THÀNH CÔNG hay THẤT BẠI | | | ⚠ Nguyên tắc | ⚠ tiêu chí thành công phải ĐO ĐƯỢC — nguyên tắc SMART, chữ M |

⚠ Cách sửa yêu cầu này thành đo được: | Mơ hồ | Đo được | |---|---| | ⚠ "Khách hàng hài lòng" | ⚠ "điểm NPS đạt tối thiểu 40 sau 3 tháng vận hành" | | ⚠ "Trải nghiệm tốt" | ⚠ "thời gian tải trang dưới 2 giây ở 95% lượt truy cập" | | ⚠ "Dễ dùng" | ⚠ "người dùng mới hoàn thành tác vụ chính trong dưới 3 phút mà không cần hướng dẫn" | | ⚠ "Ít lỗi" | ⚠ "dưới 5 lỗi nghiêm trọng trên 1.000 giờ vận hành" |

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

  • C (sự hài lòng chỉ đạt được qua các thước đo kiểm soát chất lượng đo được) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nó nói ĐÚNG rằng cần thước đo, ⚠ nhưng "chỉ đạt được qua" là quá tuyệt đối — ⚠ hài lòng còn phụ thuộc kỳ vọng, dịch vụ, và quan hệ, ⚠ không chỉ phụ thuộc chỉ số chất lượng.

  • A (sự hài lòng không bao giờ đạt được qua dự án mà qua vận hành) — ⚠ SAI: ⚠ dự án hoàn toàn có thể tạo ra sự hài lòng.

  • B (không biết được cho tới khi khách trả tiền) — ⚠ SAI: ⚠ trả tiền không đồng nghĩa với hài lòng.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này thoạt nhìn có vẻ MÂU THUẪN với câu #25758 CÙNG LÔ, ⚠ nơi ⚠ "customer satisfaction" được nêu là MỘT TRONG NĂM NGUYÊN TẮC quản lý chất lượng — ⚠ tức là một điều tốt cần theo đuổi. ⚠ Hai câu KHÔNG mâu thuẫn — chúng nói về hai chuyện khác nhau: | Câu | Nói về gì | |---|---| | ⚠ #25758 | ⚠ sự hài lòng khách hàng là một NGUYÊN TẮC cần theo đuổi, và Nikki ĐÃ BIẾN NÓ THÀNH ĐO ĐƯỢC bằng khảo sát định kỳ | | ⚠ #25777 | ⚠ "đạt được sự hài lòng" nếu nêu TRẦN TRỤI làm TIÊU CHÍ THÀNH CÔNG thì không đo được, nên nguy hiểm | | ⚠ Bài học chung | ⚠ theo đuổi sự hài lòng là ĐÚNG; nhưng phải chuyển nó thành THƯỚC ĐO CỤ THỂ mới dùng làm tiêu chí nghiệm thu được | ⚠ Giữ nguyên cả hai khoá.

⚠ Nguyên tắc SMART cho mục tiêu dự án: | Chữ | Nghĩa | |---|---| | ⚠ S — Specific | ⚠ cụ thể | | ⚠ M — Measurable | ⚠ ĐO ĐƯỢC — chỗ yêu cầu của Robert thất bại | | ⚠ A — Achievable | ⚠ khả thi | | ⚠ R — Relevant | ⚠ phù hợp mục tiêu kinh doanh | | ⚠ T — Time-bound | ⚠ có mốc thời gian |

Từ khoá nhận diện:

"hài lòng, trải nghiệm tốt, dễ dùng" → ⚠ mơ hồ, phải chuyển thành số "tiêu chí thành công" → ⚠ bắt buộc phải đo được "tiêu chí nghiệm thu" → ⚠ acceptance criteria, cũng phải đo được

⚠ Vì sao tiêu chí mơ hồ NGUY HIỂM Rủi ro
⚠ Không ai biết khi nào dự án XONG
⚠ Khách hàng có thể luôn nói "chưa hài lòng" ⚠ dự án không bao giờ đóng được
⚠ Không nghiệm thu được thì không thanh toán được
⚠ Mở đường cho scope creep vô hạn
⚠ Đây là ⚠ một trong những rủi ro hợp đồng nghiêm trọng nhất
⚠ PM nên phản hồi Robert thế nào Cách
⚠ ĐỒNG Ý với mục tiêu ⚠ sự hài lòng khách hàng là mục tiêu đúng
⚠ Hỏi: "làm sao chúng ta BIẾT là đã đạt?" ⚠ câu hỏi mở đường cho việc định lượng
⚠ Cùng xác định thước đo cụ thể và ngưỡng
⚠ Ghi vào tiêu chí thành công của điều lệ
⚠ Đừng ⚠ bác bỏ thẳng yêu cầu của CEO — hãy giúp ông ấy làm nó rõ ràng hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi tiêu chí thành công có con số kèm theo không | | | Ai là người xác nhận đã đạt | | | Đo bằng cách nào và khi nào | |

Và câu hỏi vàng khi gặp mọi yêu cầu mơ hồ: "làm sao chúng ta biết là đã đạt được?". Không trả lời được câu đó thì tiêu chí chưa dùng được.

Câu 56 People
Tim is a scrum master with Project B. He is concerned his development team did not take on enough tasks for a particular sprint. He has asked the development team, and they feel they are progressing at an acceptable pace. How can Tim prove or disprove the development team's report?
  1. A Tim should sit with the project team to directly observe their progress.
  2. B Tim should review each team member's time cards to determine their hours worked.
  3. C Tim should review the team's velocity and compare that to sprint progress.
  4. D The development team is closest to the work, and Tim should take them for their word.
Xem giải thích

Đáp án

C — Tim nên xem VELOCITY của đội và so sánh với tiến độ sprint.

Vì sao đúng

⚠ Velocity là gì và vì sao dùng được ở đây: | Đặc điểm | Nội dung | |---|---| | ⚠ Số điểm story đội hoàn thành TRUNG BÌNH mỗi sprint | | | ⚠ Dựa trên DỮ LIỆU LỊCH SỬ của chính đội đó | | | ⚠ So khối lượng sprint hiện tại với velocity trung bình | ⚠ thấy ngay đội nhận ít hay nhiều hơn bình thường | | ⚠ KHÁCH QUAN — không phụ thuộc cảm nhận | | | ⚠ Kết luận | ⚠ đây là công cụ duy nhất trong bốn phương án cho ra bằng chứng đo được |

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

  • D (đội gần công việc nhất, cứ tin lời họ) — ⚠ bỏ qua trách nhiệm kiểm chứng; ⚠ tin tưởng đội là đúng, ⚠ nhưng tin tưởng KHÔNG loại trừ việc dùng dữ liệu.

  • B (xem bảng chấm công từng người) — ⚠ SAI HẲN với tinh thần agile: ⚠ agile đo ⚠ KẾT QUẢ HOÀN THÀNH, không đo ⚠ SỐ GIỜ NGỒI LÀM; ⚠ và giám sát chấm công phá huỷ niềm tin trong đội.

  • A (ngồi cùng đội quan sát trực tiếp) — ⚠ tốn thời gian, chủ quan, và tạo cảm giác bị giám sát; ⚠ không cho ra dữ liệu so sánh được.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25772 ở lô này về phần mềm chạy được là thước đo tiến độ chính và câu #25721 ở lô 179 về đội tự quyết khối lượng vòng lặp. ⚠ Ba câu bổ sung nhau: đội tự quyết, nhưng quyết định đó vẫn nên dựa trên DỮ LIỆU velocity.

⚠ Velocity — những điều cần biết: | Điều | Nội dung | |---|---| | ⚠ Đơn vị: điểm story hoàn thành mỗi sprint | | | ⚠ Tính trung bình qua vài sprint gần nhất | ⚠ một sprint đơn lẻ không đủ tin cậy | | ⚠ Chỉ tính hạng mục ĐÃ DONE hoàn toàn | ⚠ làm dở không được tính điểm | | ⚠ Dùng để DỰ BÁO khối lượng sprint tiếp theo | | | ⚠ Ổn định dần sau 3–5 sprint | | | ⚠ Cảnh báo | ⚠ KHÔNG dùng velocity để so sánh giữa các ĐỘI khác nhau — mỗi đội có thang điểm riêng |

Từ khoá nhận diện:

"đội có nhận đủ việc không" → ⚠ so với velocity "bảng chấm công, số giờ làm" → ⚠ trái tinh thần agile, luôn là đáp án sai "cứ tin lời đội" → ⚠ bỏ qua trách nhiệm kiểm chứng "quan sát trực tiếp" → ⚠ chủ quan, tốn thời gian

⚠ Cách Tim nên sử dụng dữ liệu Bước
⚠ 1. Tính velocity trung bình vài sprint gần nhất
⚠ 2. So với khối lượng sprint hiện tại
⚠ 3. Nếu thấp hơn đáng kể: MANG DỮ LIỆU RA BÀN với đội ⚠ không phải để trách, mà để hỏi vì sao
⚠ 4. Tìm hiểu nguyên nhân ⚠ có trở ngại? có nợ kỹ thuật? có người nghỉ?
⚠ 5. Đưa vào retrospective
⚠ Thái độ đúng ⚠ Scrum Master mang DỮ LIỆU tới cho đội tự nhìn, không phán xét thay đội
⚠ Các lý do CHÍNH ĐÁNG khiến velocity giảm Lý do
⚠ Có thành viên nghỉ hoặc chuyển việc
⚠ Công việc sprint này phức tạp hơn bình thường
⚠ Đang trả nợ kỹ thuật
⚠ Có trở ngại chưa được gỡ ⚠ đây chính là việc của Scrum Master
⚠ Đội đang học công nghệ mới ⚠ liên hệ câu #25776
⚠ Vì thế ⚠ velocity thấp là DẤU HIỆU cần tìm hiểu, không phải bằng chứng đội lười
⚠ Sai lầm khi dùng velocity Sai lầm
⚠ Dùng làm chỉ tiêu ép đội ⚠ đội sẽ thổi phồng điểm ước lượng
⚠ So sánh giữa các đội ⚠ thang điểm khác nhau, so là vô nghĩa
⚠ Dùng để đánh giá cá nhân ⚠ velocity là chỉ số của ĐỘI
⚠ Dùng đúng ⚠ chỉ để DỰ BÁO và để đội tự nhìn lại mình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Velocity của đội đã ổn định chưa | ⚠ cần vài sprint mới đáng tin | | Bạn dùng nó để dự báo hay để ép | | | Đội có tự nhìn thấy dữ liệu này không | ⚠ minh bạch với đội là điều kiện tiên quyết |

Và cách một Scrum Master nên đặt vấn đề: "số liệu cho thấy sprint này nhẹ hơn trung bình, các bạn thấy có lý do gì không?" — mang dữ liệu ra hỏi, chứ không mang kết luận ra phán.

Câu 57 Process
The project you have been managing for the past few years is maturing and nearing completion. You owe a portion of the success to your qualified vendors to develop the deliverables critical aspects. You are now ready to close the project and work through all the documents to ensure everything is in order and executed. Of the following choices, the closing process group includes all but which one?
  1. A Measuring stakeholders' satisfaction.
  2. B Closing procurements with vendors.
  3. C Verifying that all invoices are accurately charged to the project.
  4. D Reviewing the project exit criteria.
Xem giải thích

Đáp án

B — Đóng hợp đồng với nhà cung cấp (closing procurements with vendors). ⚠ Việc này KHÔNG thuộc nhóm quy trình Kết thúc.

Vì sao đúng

⚠ Thay đổi quan trọng của PMBOK ấn bản 6: | Điều | Nội dung | |---|---| | ⚠ Các ấn bản TRƯỚC có quy trình riêng "Close Procurements" | ⚠ nằm trong nhóm Kết thúc | | ⚠ PMBOK 6 đã BỎ quy trình đó | | | ⚠ Việc đóng hợp đồng được GỘP vào Control Procurements | ⚠ thuộc nhóm GIÁM SÁT VÀ KIỂM SOÁT | | ⚠ Nhóm Kết thúc chỉ còn MỘT quy trình duy nhất | ⚠ Close Project or Phase | | ⚠ Vì thế | ⚠ "đóng hợp đồng" không còn là hoạt động của nhóm Kết thúc |

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

⚠ Cả ba phương án còn lại ĐỀU thuộc hoạt động kết thúc dự án:

  • A (đo mức hài lòng của bên liên quan) — ⚠ thuộc Close Project or Phase, ⚠ là một phần của việc đánh giá thành công dự án.

  • C (kiểm tra mọi hoá đơn đã được ghi nhận đúng vào dự án) — ⚠ thuộc việc kết toán tài chính khi đóng dự án.

  • D (rà soát tiêu chí kết thúc dự án) — ⚠ exit criteria là một phần bắt buộc của Close Project or Phase.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25652 ở lô 178 về Control Procurements và câu #25763 ở lô này về hợp đồng là đầu vào của Close Project or Phase. ⚠ Ba câu cùng chủ đề — và cần đọc kỹ để không mâu thuẫn.

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này và câu #25763 cùng lô thoạt nhìn có vẻ mâu thuẫn. ⚠ Câu #25763 nói ⚠ hợp đồng là ĐẦU VÀO của Close Project or Phase; ⚠ câu này nói ⚠ đóng hợp đồng KHÔNG thuộc nhóm Kết thúc. ⚠ Cả hai đều ĐÚNG và không mâu thuẫn: | Việc | Thuộc quy trình nào | |---|---| | ⚠ ĐÓNG từng hợp đồng | ⚠ Control Procurements — nhóm Giám sát và kiểm soát | | ⚠ XÁC NHẬN mọi hợp đồng đã đóng, dùng hồ sơ làm đầu vào | ⚠ Close Project or Phase — nhóm Kết thúc | | ⚠ Cách nhớ | ⚠ Control Procurements ĐÓNG hợp đồng; Close Project KIỂM TRA xem đã đóng hết chưa |

⚠ Nhóm quy trình Kết thúc — chỉ có MỘT quy trình: | Quy trình | Nhóm kiến thức | |---|---| | ⚠ Close Project or Phase | ⚠ Project Integration Management | | ⚠ Đây là điểm hay ra thi | ⚠ PMBOK 6 có 49 quy trình, nhóm Kết thúc chỉ chiếm 1 |

⚠ Số quy trình theo nhóm — PMBOK 6: | Nhóm | Số quy trình | |---|---| | ⚠ Khởi tạo | ⚠ 2 | | ⚠ Lập kế hoạch | ⚠ 24 | | ⚠ Thực hiện | ⚠ 10 | | ⚠ Giám sát và kiểm soát | ⚠ 12 | | ⚠ Kết thúc | ⚠ 1 | | ⚠ Tổng | ⚠ 49 |

Từ khoá nhận diện:

"đóng hợp đồng" → ⚠ Control Procurements, KHÔNG phải nhóm Kết thúc "báo cáo cuối, bài học kinh nghiệm, lưu trữ tài liệu" → ⚠ Close Project or Phase "tiêu chí kết thúc" → ⚠ exit criteria, thuộc nhóm Kết thúc "Close Procurements" → ⚠ quy trình ĐÃ BỊ BỎ từ PMBOK 6

⚠ Close Project or Phase làm những gì Việc
⚠ Xác nhận công việc đã hoàn thành theo tiêu chí
⚠ Chuyển giao sản phẩm cuối cùng
⚠ Thu thập và lưu trữ BÀI HỌC KINH NGHIỆM
⚠ Lưu trữ tài liệu dự án thành OPA
⚠ Giải phóng nguồn lực
⚠ Đo mức hài lòng của bên liên quan ⚠ phương án A
⚠ Kết toán tài chính ⚠ phương án C
⚠ Xác nhận mọi hợp đồng đã đóng ⚠ XÁC NHẬN chứ không THỰC HIỆN việc đóng
⚠ Viết báo cáo cuối cùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi hợp đồng đã đóng qua Control Procurements chưa | | | Bài học kinh nghiệm đã được lưu chưa | | | Tiêu chí kết thúc có được rà soát chính thức không | |

Và điểm dễ mất điểm nhất ở dạng câu này: nhiều tài liệu cũ vẫn dạy "Close Procurements" là quy trình riêng. Với PMBOK 6 trở đi, nhóm Kết thúc chỉ còn đúng một quy trình.

Câu 58 Process
Edward’s company, Mammoth Studios, requires that he copy all his project’s agile tasks into a Gantt chart along with relevant dates. Besides it being time-consuming to duplicate the work, the biggest issue that Edward has with tracking progress through a Gantt chart is
  1. A The Gantt chart does not include any information on project costs.
  2. B The Gantt chart does not include the information on the percentage of the project completed.
  3. C The Gantt chart does not include any information on the tasks completed on the project.
  4. D The Gantt chart does not include a view of the project over time.
Xem giải thích

Đáp án

A — Biểu đồ Gantt KHÔNG chứa thông tin nào về CHI PHÍ dự án.

Vì sao đúng

⚠ Biểu đồ Gantt thể hiện gì và KHÔNG thể hiện gì: | Có | Không có | |---|---| | ⚠ Danh sách công việc | ⚠ CHI PHÍ — không có cột nào cho tiền | | ⚠ Thời gian bắt đầu và kết thúc từng việc | ⚠ ngân sách từng việc | | ⚠ Thời lượng | ⚠ chi phí thực tế đã tiêu | | ⚠ Phụ thuộc giữa các việc | ⚠ dự báo chi phí khi hoàn thành | | ⚠ Phần trăm hoàn thành | ⚠ hiệu suất chi phí | | ⚠ Mốc quan trọng | | | ⚠ Kết luận | ⚠ Gantt là công cụ về THỜI GIAN, hoàn toàn không nói gì về TIỀN |

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

⚠ Cả ba phương án còn lại đều nêu những thứ mà Gantt THỰC SỰ CÓ:

  • B (không có thông tin phần trăm hoàn thành) — ⚠ SAI: ⚠ Gantt hiện đại luôn hiển thị phần trăm hoàn thành bằng thanh tô đậm.

  • C (không có thông tin về công việc đã hoàn thành) — ⚠ SAI: ⚠ đó chính là chức năng cơ bản của Gantt.

  • D (không có góc nhìn dự án theo thời gian) — ⚠ SAI HOÀN TOÀN: ⚠ trục thời gian chính là trục ngang của biểu đồ Gantt.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25756 ở lô này về EVM và câu #25772 về thước đo tiến độ của agile. ⚠ Ba câu bổ sung nhau: Gantt cho THỜI GIAN, EVM cho CHI PHÍ và giá trị, burndown cho KHỐI LƯỢNG CÒN LẠI.

⚠ So sánh các công cụ theo dõi: | Công cụ | Cho biết | |---|---| | ⚠ Gantt chart | ⚠ THỜI GIAN: việc nào khi nào, phụ thuộc gì | | ⚠ Network diagram | ⚠ PHỤ THUỘC và ĐƯỜNG GĂNG | | ⚠ S-curve / EVM | ⚠ CHI PHÍ và GIÁ TRỊ theo thời gian | | ⚠ Burndown / burnup | ⚠ KHỐI LƯỢNG công việc còn lại hoặc đã làm | | ⚠ Cumulative flow diagram | ⚠ NÚT THẮT trong luồng công việc | | ⚠ Không công cụ nào nói hết | ⚠ phải dùng kết hợp |

Từ khoá nhận diện:

"Gantt thiếu gì" → ⚠ CHI PHÍ "chi phí theo thời gian" → ⚠ S-curve, EVM "đường găng" → ⚠ network diagram "còn bao nhiêu việc" → ⚠ burndown

⚠ Vấn đề THẬT của Edward Vấn đề
⚠ Phải SAO CHÉP THỦ CÔNG task agile sang Gantt ⚠ lãng phí, dễ sai, dữ liệu hai nơi lệch nhau
⚠ Gantt không phù hợp với công việc thay đổi liên tục ⚠ backlog sắp lại ưu tiên mỗi sprint thì Gantt lỗi thời ngay
⚠ Và Gantt không cho biết gì về chi phí ⚠ câu trả lời của đề
⚠ Điều Edward nên đề xuất ⚠ dùng công cụ tự sinh báo cáo từ backlog, hoặc thống nhất với tổ chức về cách báo cáo phù hợp với agile
⚠ Vì sao tổ chức vẫn đòi Gantt cho dự án agile Lý do
⚠ Lãnh đạo quen nhìn Gantt
⚠ Cần so sánh với các dự án dự đoán khác trong danh mục
⚠ Yêu cầu báo cáo của tổ chức chưa cập nhật
⚠ Cách xử lý ⚠ tự động hoá việc sinh báo cáo thay vì làm tay, và giáo dục lãnh đạo về các chỉ số agile
⚠ Khi nào Gantt VẪN hữu ích Trường hợp
⚠ Dự án có nhiều PHỤ THUỘC bên ngoài cần thấy rõ
⚠ Cần trình bày mốc cho bên liên quan không quen agile
⚠ Dự án LAI, phần dự đoán vẫn cần lịch chi tiết
⚠ Đừng ⚠ coi Gantt là công cụ đo tiến độ duy nhất — nó chỉ nói về thời gian

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn theo dõi chi phí bằng công cụ nào | ⚠ nếu chỉ có Gantt thì bạn đang mù về tiền | | Có phải nhập liệu hai lần không | ⚠ dấu hiệu quy trình cần tự động hoá | | Bên liên quan cần thông tin gì thật sự | ⚠ có khi họ chỉ cần mốc, không cần cả biểu đồ |

Và giới hạn cần nhớ về công cụ quen thuộc nhất của nghề: Gantt trả lời "khi nào", EVM trả lời "bao nhiêu tiền", và không cái nào thay được cái kia.

Câu 59 Process
Harry plans to build out his software in several sprints over the course of a year. The software's core functionality will make it immediately useful for the three departments that will use it. Once it is deployed, each subsequent sprint will be used to develop a new module to accompany the core functionality. For instance, an accounting module will allow the accounting department to pull in its data and use it to populate a series of dashboards. Once all of the modules are incorporated, Harry's project will go into maintenance mode. Which project methodology is appropriate?
  1. A Incremental
  2. B Agile
  3. C Iterative
  4. D Predictive
Xem giải thích

Đáp án

A — Incremental (tăng dần).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Chức năng LÕI dùng được NGAY cho ba phòng ban | ⚠ → giao được giá trị sử dụng ngay từ đợt đầu | | ⚠ Mỗi sprint tiếp theo thêm MỘT MODULE MỚI | ⚠ → bổ sung CHỨC NĂNG chứ không tinh chỉnh cái cũ | | ⚠ Ví dụ: module kế toán cho phòng kế toán | ⚠ → mỗi module phục vụ một nhóm người dùng | | ⚠ Khi đủ module thì chuyển sang bảo trì | | | ⚠ Kết luận | ⚠ giao hàng THÀNH NHIỀU ĐỢT, mỗi đợt THÊM chức năng dùng được — đúng định nghĩa incremental |

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

  • C (Iterative — lặp) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ vòng đời lặp là ⚠ làm đi làm lại để TINH CHỈNH cùng một thứ cho tốt hơn, ⚠ giao hàng MỘT LẦN ở cuối; ⚠ Harry lại ⚠ THÊM module mới mỗi đợt và giao ngay — đó là tăng dần.

  • B (Agile) — ⚠ agile là sự KẾT HỢP của lặp và tăng dần, ⚠ nhưng đề mô tả rất rõ đặc trưng ⚠ TĂNG DẦN thuần tuý: ⚠ mỗi đợt thêm một module độc lập, không nói tới việc tinh chỉnh dựa trên phản hồi.

  • D (Predictive — dự đoán) — ⚠ giao hàng MỘT LẦN ở cuối dự án, ⚠ trái hẳn mô tả.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25686 ở lô 179 về vòng đời dự đoán. ⚠ Hai câu là cặp đối chiếu về bốn loại vòng đời.

⚠ Bốn loại vòng đời — bảng phân biệt: | Vòng đời | Phạm vi | Số lần GIAO | Mục tiêu chính | |---|---|---|---| | ⚠ Predictive | ⚠ chốt SỚM | ⚠ MỘT lần ở cuối | ⚠ quản lý CHI PHÍ | | ⚠ Iterative | ⚠ chốt sớm, tinh chỉnh dần | ⚠ MỘT lần ở cuối | ⚠ giải pháp ĐÚNG hơn | | ⚠ Incremental | ⚠ chốt sớm | ⚠ NHIỀU lần, mỗi lần thêm chức năng | ⚠ TỐC ĐỘ giao giá trị — CÂU NÀY | | ⚠ Adaptive / Agile | ⚠ MỞ, chi tiết hoá dần | ⚠ thường xuyên | ⚠ PHẢN HỒI và thích ứng |

⚠ Ví dụ minh hoạ để không bao giờ nhầm: | Vòng đời | Ví dụ vẽ bức tranh chân dung | |---|---| | ⚠ Iterative | ⚠ phác toàn bộ khuôn mặt mờ, rồi tô đậm dần cả bức qua từng lượt — chỉ giao khi xong hẳn | | ⚠ Incremental | ⚠ vẽ xong hoàn chỉnh đôi mắt, rồi tới mũi, rồi tới miệng — mỗi phần xong là dùng được ngay | | ⚠ Agile | ⚠ kết hợp cả hai, có phản hồi khách hàng sau mỗi lượt | | ⚠ Predictive | ⚠ vẽ theo đúng bản thiết kế đã duyệt, chỉ cho xem khi hoàn tất |

Từ khoá nhận diện:

"mỗi đợt thêm chức năng dùng được" → ⚠ incremental "làm đi làm lại cho tốt hơn, giao một lần" → ⚠ iterative "phạm vi mở, phản hồi liên tục" → ⚠ agile / adaptive "chốt phạm vi, giao một lần ở cuối" → ⚠ predictive

⚠ Vì sao incremental phù hợp với dự án của Harry Lý do
⚠ Người dùng có giá trị NGAY sau đợt đầu ⚠ không phải chờ một năm
⚠ Rủi ro giảm: nếu dừng giữa chừng vẫn có phần dùng được
⚠ Mỗi module phục vụ một phòng ban khác nhau ⚠ chia tự nhiên theo module
⚠ Phản hồi từ module trước cải thiện module sau
⚠ Điều kiện ⚠ phần lõi phải được thiết kế đủ tốt để các module sau cắm vào được
⚠ Rủi ro của cách tiếp cận tăng dần Rủi ro
⚠ Kiến trúc lõi sai thì mọi module sau đều khổ
⚠ Chi phí tích hợp lặp lại mỗi đợt
⚠ Người dùng phải học lại giao diện sau mỗi đợt
⚠ Cách giảm ⚠ đầu tư kỹ vào thiết kế lõi, giữ giao diện nhất quán, tự động hoá kiểm thử hồi quy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phần lõi có thật sự dùng được độc lập không | ⚠ điều kiện tiên quyết của incremental | | Kiến trúc có cho phép cắm thêm module không | | | Mỗi đợt giao có tạo giá trị thật cho người dùng không | |

Và điểm phân biệt then chốt giữa hai từ dễ nhầm nhất: iterative làm CÙNG MỘT THỨ tốt dần lên, incremental làm THÊM THỨ MỚI mỗi lần.

Câu 60 Business Environment
Chris is the risk manager for a significant airline construction company. According to the project schedule, the construction of a new aircraft is in progress and is approximately 50% complete. While performing a regular audit of the work progress, Chris notices that some workers are not wearing the proper personal protective equipment per the posted Health & Safety requirements. In this scenario, what should Chris do?
  1. A Tell the workers to stop work.
  2. B Notify the worksite supervisor immediately.
  3. C Document the incident in the risk register.
  4. D Ignore the situation as it is not Chris's responsibility.
Xem giải thích

Đáp án

B — Thông báo NGAY LẬP TỨC cho giám sát công trường.

Vì sao đúng

⚠ Nguyên tắc về an toàn: | Nguyên tắc | Nội dung | |---|---| | ⚠ AN TOÀN LÀ TRÊN HẾT — không thoả hiệp | | | ⚠ Người có THẨM QUYỀN và TRÁCH NHIỆM tại công trường là GIÁM SÁT | | | ⚠ Chris là quản lý RỦI RO, không phải giám sát thi công | ⚠ anh ấy không có thẩm quyền chỉ đạo trực tiếp công nhân | | ⚠ Thông báo NGAY vì rủi ro đang diễn ra | ⚠ không chờ tới cuộc họp sau | | ⚠ Kết luận | ⚠ báo cho đúng người có thẩm quyền, ngay lập tức |

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

  • A (bảo công nhân dừng việc) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ hành động đúng hướng nhưng ⚠ VƯỢT THẨM QUYỀN; ⚠ Chris không phải người quản lý trực tiếp họ, ⚠ và ra lệnh vượt tuyến có thể gây rối loạn; ⚠ trừ khi có NGUY HIỂM TỨC THÌ đe doạ tính mạng — khi đó ai cũng có quyền và nghĩa vụ can thiệp.

  • C (ghi vào sổ đăng ký rủi ro) — ⚠ CẦN LÀM nhưng KHÔNG PHẢI việc ĐẦU TIÊN: ⚠ ghi sổ trong khi công nhân vẫn đang gặp nguy hiểm là đặt sai thứ tự ưu tiên; ⚠ ghi sổ là bước SAU.

  • D (bỏ qua vì không phải trách nhiệm của Chris) — ⚠ SAI HOÀN TOÀN về mặt đạo đức nghề nghiệp: ⚠ Quy tắc Đạo đức và Ứng xử Nghề nghiệp của PMI yêu cầu ⚠ báo cáo hành vi vi phạm và bảo vệ an toàn.

Ghi nhớ

⚠ Bốn giá trị trong Quy tắc Đạo đức của PMI: | Giá trị | Nội dung | |---|---| | ⚠ RESPONSIBILITY — Trách nhiệm | ⚠ sở hữu quyết định của mình, BÁO CÁO hành vi trái quy định — áp dụng ở đây | | ⚠ RESPECT — Tôn trọng | ⚠ tôn trọng con người, nguồn lực và môi trường | | ⚠ FAIRNESS — Công bằng | ⚠ quyết định khách quan, không thiên vị, tránh xung đột lợi ích | | ⚠ HONESTY — Trung thực | ⚠ hiểu sự thật và hành động trung thực | | ⚠ Trong tình huống này | ⚠ giá trị TRÁCH NHIỆM buộc Chris phải hành động, không được làm ngơ |

Từ khoá nhận diện:

"vi phạm an toàn" → ⚠ báo NGAY cho người có thẩm quyền "không phải việc của tôi" → ⚠ LUÔN là đáp án SAI trong đề PMP "ghi vào sổ rồi tính sau" → ⚠ sai thứ tự ưu tiên khi có nguy hiểm "nguy hiểm tức thì đe doạ tính mạng" → ⚠ khi đó dừng việc ngay là đúng

⚠ Trình tự hành động đầy đủ của Chris Bước
⚠ 1. Thông báo NGAY cho giám sát công trường ⚠ bước của câu này
⚠ 2. Nếu có nguy hiểm TỨC THÌ: can thiệp ngay bất kể thẩm quyền
⚠ 3. Ghi nhận sự việc vào SỔ VẤN ĐỀ và SỔ RỦI RO ⚠ phương án C là bước này
⚠ 4. Xác nhận đã được khắc phục
⚠ 5. Phân tích NGUYÊN NHÂN GỐC ⚠ vì sao công nhân không mang bảo hộ? thiếu thiết bị? thiếu đào tạo? văn hoá?
⚠ 6. Báo cáo trong buổi rà soát rủi ro định kỳ
⚠ 7. Ghi vào bài học kinh nghiệm
⚠ Vì sao đây là vấn đề RỦI RO nghiêm trọng Lý do
⚠ Tác động: thương tật hoặc tử vong ⚠ mức tác động cao nhất có thể
⚠ Rủi ro PHÁP LÝ cho tổ chức
⚠ Có thể bị đình chỉ thi công
⚠ Uy tín doanh nghiệp
⚠ Đây là loại rủi ro ⚠ KHÔNG được "chấp nhận" — phải né tránh hoặc giảm nhẹ tới mức thấp nhất
⚠ Vì sao ghi sổ rủi ro thôi là KHÔNG ĐỦ Lý do
⚠ Sổ rủi ro là công cụ THEO DÕI, không phải công cụ HÀNH ĐỘNG
⚠ Nguy hiểm đang diễn ra ngay lúc này
⚠ Sổ rủi ro dành cho rủi ro CHƯA xảy ra ⚠ đây đã là VẤN ĐỀ đang xảy ra — thuộc issue log
⚠ Nhưng vẫn phải ghi ⚠ để theo dõi và phân tích xu hướng — chỉ là ghi SAU khi đã báo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai là người có thẩm quyền xử lý tại chỗ | | | Có nguy hiểm tức thì không | ⚠ quyết định bạn có được can thiệp trực tiếp không | | Sau khi báo có ai xác nhận đã khắc phục không | |

Và nguyên tắc bất di bất dịch trong mọi đề thi liên quan tới an toàn: không bao giờ làm ngơ, và luôn báo cho đúng người ngay lập tức. "Không phải việc của tôi" chưa bao giờ là đáp án đúng.