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

Tìm thấy 720 câu.

Câu 231 Process
Gregory has joined a cross-functional scrum team using a four-week sprint cycle. During the sprint retrospective for the current sprint, the development team raises the need for broader testing and business stakeholders’ involvement. These needs are necessary to perform testing so that the increment acceptance is smooth during the review meeting. Gregory suggests including the product's end-users full-time to work with the development team for the upcoming sprint and test the increment as it is built to confirm its acceptability. As an experienced scrum master, what would you recommend to Gregory and the development team to improve the quality of the tests?
  1. A Use a separate testing sprint to perform all the required tests for the completed increment before starting the next sprint.
  2. B Add a dedicated team of QA testers who can focus only on testing the developed increment.
  3. C Increase the sprint length whenever there is a need to perform additional testing.
  4. D Inform the team that all the necessary testing and quality checks should be part of the Definition of Done.
Xem giải thích

Đáp án

D — Nói với đội rằng MỌI KIỂM THỬ VÀ KIỂM TRA CHẤT LƯỢNG CẦN THIẾT phải nằm trong ĐỊNH NGHĨA HOÀN THÀNH.

Vì sao đúng

⚠ Vì sao đây là khuyến nghị đúng: | Lý do | Nội dung | |---|---| | ⚠ Mỗi sprint phải cho ra một PHẦN TĂNG TRƯỞNG DÙNG ĐƯỢC | ⚠ chưa kiểm thử thì chưa dùng được | | ⚠ Định nghĩa Hoàn thành là nơi ghi mọi điều kiện chất lượng | ⚠ công cụ đúng cho vấn đề này | | ⚠ Kiểm thử nằm TRONG sprint, không tách ra sau | ⚠ nguyên tắc nền tảng của Scrum | | ⚠ Cả đội chịu trách nhiệm chất lượng | ⚠ đội liên chức năng, không có "khâu kiểm thử" riêng | | ⚠ Giải quyết được đúng vấn đề đội nêu | ⚠ nghiệm thu ở sprint review sẽ trơn tru vì mọi thứ đã được kiểm trước đó |

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

  • B (thêm một đội QA chuyên trách chỉ tập trung kiểm thử) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất hợp lý và rất phổ biến trong thực tế: ⚠ nhưng nó ⚠ phá vỡ tính LIÊN CHỨC NĂNG của đội, ⚠ tạo ra một khâu bàn giao mới, ⚠ và ⚠ chuyển trách nhiệm chất lượng ra khỏi đội phát triển ⚠ — đúng thứ Scrum muốn tránh.

  • A (dùng một sprint kiểm thử riêng sau khi làm xong) — ⚠ quay lại mô hình thác nước; ⚠ sprint kiểm thử riêng không tạo ra giá trị mới nào cho người dùng.

  • C (kéo dài sprint mỗi khi cần kiểm thử thêm) — ⚠ phá hộp thời gian ⚠ (xem #25936 cùng lô), ⚠ và không giải quyết nguyên nhân gốc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25936 ở lô này (thành viên ốm → giao những gì làm được, không kéo dài sprint), câu #25929 ở lô 183 (thiếu tiêu chí chấp nhận → hỏi PO), và câu #25940 (giới hạn WIP). ⚠ Cả nhóm về việc giữ kỷ luật của khung Scrum.

⚠ Phân biệt BA khái niệm về "xong": | Khái niệm | Phạm vi | |---|---| | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ RIÊNG từng hạng mục — hạng mục này đúng chưa | | ⚠ ĐỊNH NGHĨA HOÀN THÀNH (DoD) | ⚠ CHUNG cho mọi hạng mục — CÂU NÀY | | ⚠ ĐỊNH NGHĨA SẴN SÀNG (DoR) | ⚠ điều kiện để hạng mục được đưa VÀO sprint | | ⚠ Một hạng mục "xong" khi | ⚠ thoả CẢ tiêu chí chấp nhận riêng LẪN Định nghĩa Hoàn thành chung |

⚠ Một Định nghĩa Hoàn thành đầy đủ thường có: | Mục | Nội dung | |---|---| | ⚠ Mã nguồn đã được rà soát | | | ⚠ Kiểm thử đơn vị đã viết và chạy xanh | | | ⚠ Kiểm thử tích hợp đã chạy | | | ⚠ Kiểm thử chấp nhận của người dùng đã qua | ⚠ đúng thứ đội của Gregory đang thiếu | | ⚠ Tài liệu đã cập nhật | | | ⚠ Đã triển khai lên môi trường thử nghiệm | | | ⚠ Không còn lỗi nghiêm trọng nào mở | | | ⚠ Nguyên tắc | ⚠ DoD do ĐỘI tự đặt, và nên SIẾT DẦN theo thời gian khi năng lực tăng lên |

Từ khoá nhận diện:

"kiểm thử chưa đủ, nghiệm thu trục trặc" → ⚠ bổ sung vào Định nghĩa Hoàn thành "sprint kiểm thử riêng" → ⚠ luôn sai — quay lại thác nước "đội QA tách rời" → ⚠ phá tính liên chức năng "kéo dài sprint" → ⚠ luôn sai

⚠ Đề xuất của Gregory (kéo người dùng cuối vào toàn thời gian) có ổn không Đánh giá
⚠ Ý TƯỞNG ĐÚNG HƯỚNG — đưa phản hồi người dùng vào sớm
⚠ Nhưng TOÀN THỜI GIAN thường không khả thi ⚠ người dùng còn công việc chính của họ
⚠ Và nó KHÔNG thay thế được việc siết Định nghĩa Hoàn thành
⚠ Cách làm thực tế hơn ⚠ mời người dùng tham gia ĐỊNH KỲ, và đưa "đã có người dùng xác nhận" vào DoD hoặc tiêu chí chấp nhận
⚠ Kết luận ⚠ giữ tinh thần đề xuất của Gregory, nhưng đặt nó vào đúng công cụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có Định nghĩa Hoàn thành viết ra không | ⚠ hay chỉ hiểu ngầm mỗi người một kiểu | | Lần cuối DoD được rà lại là khi nào | | | Có việc nào "xong" ở sprint này rồi quay lại ở sprint sau không | ⚠ dấu hiệu DoD quá lỏng |

Và cách nhận ra một Định nghĩa Hoàn thành quá lỏng: cuối mỗi sprint đội báo xong, nhưng không ai dám đem phần đó cho khách hàng dùng thật.

Câu 232 People
Jose wants to use the most effective way to communicate with his agile team. This is most likely to be
  1. A Use of a video conferencing tool for the folks sitting on the other side of their building.
  2. B By ensuring all information discussed is written up in good minutes and distributed to all stakeholders.
  3. C Via a daily report read at the end of each daily standup.
  4. D Face-to-face communication.
Xem giải thích

Đáp án

D — GIAO TIẾP TRỰC TIẾP, mặt đối mặt.

Vì sao đúng

⚠ Vì sao trực tiếp là hiệu quả nhất: | Lý do | Nội dung | |---|---| | ⚠ Truyền được cả GIỌNG ĐIỆU và NGÔN NGỮ CƠ THỂ | ⚠ tầng thông tin lớn nhất, và mất hoàn toàn khi viết | | ⚠ Phản hồi TỨC THÌ — hiểu nhầm được sửa ngay | | | ⚠ Băng thông cao nhất trong mọi kênh | ⚠ truyền được nhiều ý trong ít thời gian | | ⚠ Xây dựng lòng tin và quan hệ | | | ⚠ Tuyên ngôn Agile | ⚠ nguyên tắc số 6: cách truyền đạt thông tin hiệu quả nhất trong và với đội phát triển là TRÒ CHUYỆN TRỰC TIẾP |

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

  • A (dùng công cụ hội nghị truyền hình cho những người ngồi ở PHÍA BÊN KIA CÙNG TOÀ NHÀ) — ⚠ phương án gây nhiễu mạnh nhất vì hội nghị truyền hình đúng là kênh tốt: ⚠ nhưng chi tiết ⚠ "cùng một toà nhà" ⚠ là mấu chốt — ⚠ họ đi bộ sang được thì tại sao lại gọi video? ⚠ Dùng công cụ trung gian khi có thể gặp trực tiếp là tự hạ hiệu quả xuống.

  • B (ghi biên bản đầy đủ rồi gửi cho mọi bên liên quan) — ⚠ giao tiếp ĐẨY, hiệu quả thấp nhất; ⚠ hữu ích để lưu vết, ⚠ nhưng không phải cách truyền đạt hiệu quả nhất.

  • C (báo cáo hằng ngày đọc ở cuối buổi standup) — ⚠ biến daily scrum thành buổi báo cáo ⚠ (xem #25921 lô 183 — sai lầm phổ biến nhất).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25949 ở lô này (tin nhắn là văn bản không chính thức), câu #25950 (xác nhận qua ngôn ngữ cơ thể), câu #25948 (mô hình mã hoá-giải mã), câu #25942 (ràng buộc địa lý), và câu #25885 ở lô 183 (lý do bố trí ngồi chung). ⚠ NĂM câu về giao tiếp trong lô này — nhiều nhất trong mọi chủ đề.

⚠ Thang hiệu quả của các kênh giao tiếp: | Thứ hạng | Kênh | Vì sao | |---|---|---| | ⚠ 1 | ⚠ Trực tiếp có bảng vẽ | ⚠ cao nhất — có cả hình ảnh chung | | ⚠ 2 | ⚠ Trực tiếp | ⚠ ĐÁP ÁN của câu này | | ⚠ 3 | ⚠ Hội nghị truyền hình | ⚠ giữ được nét mặt, mất phần không gian chung | | ⚠ 4 | ⚠ Điện thoại | ⚠ chỉ còn giọng điệu | | ⚠ 5 | ⚠ Tin nhắn tức thời | | | ⚠ 6 | ⚠ Email, tài liệu | ⚠ thấp nhất, nhưng lưu vết tốt nhất | | ⚠ Đánh đổi | ⚠ kênh càng hiệu quả thì càng ÍT để lại dấu vết — nên quyết định quan trọng vẫn phải ghi lại bằng văn bản |

Từ khoá nhận diện:

"cách hiệu quả nhất để giao tiếp" → ⚠ trực tiếp "cùng toà nhà mà gọi video" → ⚠ bẫy — đi bộ sang còn nhanh hơn "biên bản gửi cho tất cả" → ⚠ lưu vết tốt, hiệu quả truyền đạt thấp "đọc báo cáo trong standup" → ⚠ hiểu sai daily scrum

⚠ Vì sao agile nhấn mạnh giao tiếp trực tiếp Lý do
⚠ Giảm tài liệu trung gian không cần thiết
⚠ Rút ngắn vòng phản hồi ⚠ hiểu sai được sửa trong vài giây thay vì vài ngày
⚠ Xây lòng tin — nền tảng của đội tự tổ chức
⚠ Cho phép trao đổi những thứ khó viết ra ⚠ lo lắng, nghi ngờ, linh cảm về rủi ro
⚠ Với đội phân tán ⚠ thay bằng video có bật camera, và cố gắng gặp mặt trực tiếp ít nhất một lần đầu dự án
⚠ Khi nào KHÔNG nên dùng trực tiếp Trường hợp
⚠ Cần lưu vết pháp lý hoặc hợp đồng ⚠ phải bằng văn bản chính thức
⚠ Thông tin phức tạp cần đọc kỹ và tra lại ⚠ tài liệu tốt hơn
⚠ Người nhận ở múi giờ khác ⚠ liên hệ #25942
⚠ Thông tin cần gửi tới rất nhiều người cùng lúc
⚠ Cách kết hợp tốt nhất ⚠ bàn TRỰC TIẾP để hiểu nhau, rồi GHI LẠI để nhớ và để chứng minh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có gửi email cho người ngồi cách mình mười mét không | ⚠ rất nhiều người có | | Đội phân tán của bạn có bật camera không | | | Quyết định bàn miệng có được ghi lại ở đâu không | |

Và nghịch lý mà mọi đội đều gặp: kênh giao tiếp hiệu quả nhất lại là kênh để lại ít bằng chứng nhất — nên câu trả lời đúng không bao giờ là chọn một, mà là dùng đúng kênh cho đúng mục đích.

Câu 233 Process
You work at a manufacturing plant as a project manager and develop the health and safety documentation for a complex project that spans across the organization. Before releasing the health and safety document to the team, you prepare a list of reviews and inclusion within the document. These items include incident names, category, protection required, what to do in an emergency, and emergency evacuation plans. What type of project tool are you using with this approach?
  1. A Risk assessment
  2. B Checklist
  3. C Quality control
  4. D Inspection analysis
Xem giải thích

Đáp án

B — DANH SÁCH KIỂM (checklist).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Bạn lập một DANH SÁCH các mục phải rà soát và phải có trong tài liệu | ⚠ đúng định nghĩa danh sách kiểm | | ⚠ Các mục cụ thể: tên sự cố, phân loại, bảo hộ cần thiết, xử lý khẩn cấp, sơ tán | ⚠ danh mục hạng mục bắt buộc | | ⚠ Dùng TRƯỚC khi phát hành tài liệu | ⚠ bảo đảm không sót mục nào | | ⚠ Danh sách kiểm là gì | ⚠ công cụ có cấu trúc, liệt kê các thành phần bắt buộc để xác nhận đã làm đủ các bước | | ⚠ Vì sao hiệu quả | ⚠ trong việc lặp lại và nhiều chi tiết, trí nhớ luôn thua giấy trắng mực đen |

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

  • A (đánh giá rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì nội dung tài liệu nói về sự cố và tình huống khẩn cấp: ⚠ nhưng đánh giá rủi ro là ⚠ PHÂN TÍCH xác suất và tác động của từng rủi ro, ⚠ không phải danh mục các mục phải có trong một tài liệu; ⚠ bạn đang kiểm tính ĐẦY ĐỦ của tài liệu, không đang đánh giá rủi ro.

  • C (kiểm soát chất lượng) — ⚠ là cả một QUY TRÌNH, ⚠ trong đó danh sách kiểm chỉ là một công cụ; ⚠ câu hỏi hỏi tên CÔNG CỤ.

  • D (phân tích thanh tra) — ⚠ không phải thuật ngữ chuẩn; ⚠ thanh tra là việc xem xét sản phẩm thực tế, không phải lập danh mục.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25923 ở lô 183 (danh sách gợi ý là kỹ thuật nhận diện rủi ro), câu #25914 (thiết kế thực nghiệm), và câu #25947 ở lô này (kiểm toán). ⚠ Nhóm công cụ chất lượng.

⚠ Phân biệt ba thứ dễ lẫn: | Công cụ | Dùng để | |---|---| | ⚠ DANH SÁCH KIỂM (checklist) | ⚠ xác nhận đã làm ĐỦ các bước hoặc có ĐỦ các mục — CÂU NÀY | | ⚠ PHIẾU KIỂM TRA (check sheet) | ⚠ ĐẾM số lần xuất hiện của từng loại lỗi — thu thập dữ liệu | | ⚠ DANH SÁCH GỢI Ý (prompt list) | ⚠ kích thích nghĩ ra RỦI RO theo từng nhóm — PESTLE, TECOP | | ⚠ Mẹo nhớ | ⚠ checklist để TÍCH, check sheet để ĐẾM, prompt list để NGHĨ RA |

Từ khoá nhận diện:

"danh sách các mục phải có" → ⚠ danh sách kiểm "đếm số lần lỗi xảy ra" → ⚠ phiếu kiểm tra "xác suất và tác động" → ⚠ đánh giá rủi ro "xem xét sản phẩm thực tế" → ⚠ thanh tra

⚠ Vì sao danh sách kiểm mạnh trong lĩnh vực an toàn Lý do
⚠ Sai sót do QUÊN là nguyên nhân tai nạn hàng đầu
⚠ Người có kinh nghiệm cũng quên — thậm chí quên nhiều hơn vì chủ quan
⚠ Chuẩn hoá được giữa nhiều người, nhiều ca làm
⚠ Dễ kiểm toán và chứng minh đã tuân thủ ⚠ liên hệ #25947 — kiểm toán tuân thủ
⚠ Bằng chứng thực tế ⚠ hàng không và y tế đều giảm mạnh sự cố nhờ danh sách kiểm, dù nó chỉ là tờ giấy
⚠ Danh sách kiểm tốt trông thế nào Đặc điểm
⚠ NGẮN — vừa một trang, làm được trong vài phút ⚠ dài quá thì người ta tích bừa
⚠ Mỗi mục là một hành động KIỂM CHỨNG ĐƯỢC
⚠ Thứ tự theo trình tự công việc thật
⚠ Được RÀ LẠI sau mỗi sự cố ⚠ mỗi tai nạn thường sinh ra một dòng mới
⚠ Sai lầm ⚠ biến nó thành thủ tục giấy tờ — khi đó người ta tích mà không thật sự kiểm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có danh sách kiểm cho các việc lặp lại không | | | Danh sách đó có ai thực sự dùng không | ⚠ hay chỉ tồn tại để nộp cho kiểm toán | | Lần cuối nó được cập nhật là khi nào | |

Và lý do một công cụ đơn giản như vậy lại có sức mạnh lớn: nó không đòi hỏi bạn giỏi hơn — nó chỉ đòi hỏi bạn đừng quên.

Câu 234 Business Environment
Congratulations! You have finished the project work and are performing quality control. You are about to validate the scope, and management would first like to examine all the changes that have been requested and their statuses. Management wants to see which changes have been approved and which have been declined. Where can you find all of this information?
  1. A The change log.
  2. B The risk register.
  3. C You will have records only of the change requests that have been declined because all approved changes are incorporated into the project scope, and the time and cost baselines are updated.
  4. D You will have records only of the change requests that have been approved because declined change requests are discarded.
Xem giải thích

Đáp án

A — NHẬT KÝ THAY ĐỔI (change log).

Vì sao đúng

⚠ Nhật ký thay đổi chứa gì: | Nội dung | Chi tiết | |---|---| | ⚠ TẤT CẢ yêu cầu thay đổi | ⚠ không phân biệt đã duyệt hay bị từ chối | | ⚠ TRẠNG THÁI hiện tại của từng yêu cầu | ⚠ đang chờ / đã duyệt / bị từ chối / hoãn | | ⚠ Người đề xuất và ngày đề xuất | | | ⚠ Quyết định và LÝ DO của quyết định | | | ⚠ Tác động tới phạm vi, lịch, chi phí | | | ⚠ Đúng thứ lãnh đạo đang hỏi | ⚠ thay đổi nào đã duyệt, thay đổi nào bị từ chối — nằm trọn trong một tài liệu |

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

  • C (chỉ còn hồ sơ của các thay đổi BỊ TỪ CHỐI, vì thay đổi được duyệt đã nhập vào phạm vi và cập nhật đường cơ sở) — ⚠ phương án gây nhiễu mạnh nhất vì phần lý giải NGHE RẤT ĐÚNG: ⚠ thay đổi được duyệt ⚠ ĐÚNG LÀ ⚠ được đưa vào phạm vi và cập nhật đường cơ sở; ⚠ nhưng ⚠ điều đó KHÔNG làm mất bản ghi trong nhật ký thay đổi ⚠ — nhật ký giữ lại cả hai, đó chính là mục đích tồn tại của nó.

  • D (chỉ còn hồ sơ của các thay đổi ĐÃ DUYỆT, vì thay đổi bị từ chối bị bỏ đi) — ⚠ SAI NGHIÊM TRỌNG: ⚠ thay đổi bị từ chối ⚠ KHÔNG BAO GIỜ bị vứt ⚠ — chúng và lý do từ chối là bằng chứng quan trọng.

  • B (sổ đăng ký rủi ro) — ⚠ ghi rủi ro và cách ứng phó, ⚠ không ghi yêu cầu thay đổi.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25933 ở lô này (sửa lỗi là một dạng yêu cầu thay đổi), câu #25939 (hành động khắc phục), và câu #25927 ở lô 183 (hoạt động của giai đoạn đóng). ⚠ Nhóm kiểm soát thay đổi tích hợp.

⚠ Vì sao PHẢI giữ cả thay đổi bị từ chối: | Lý do | Nội dung | |---|---| | ⚠ Tránh đề xuất lại cùng một thay đổi nhiều lần | ⚠ "cái này đã bàn tháng trước, lý do từ chối là..." | | ⚠ Bằng chứng khi có tranh chấp về sau | ⚠ "chúng tôi ĐÃ đề nghị và bên bạn từ chối" | | ⚠ Bài học cho các dự án sau | | | ⚠ Minh bạch với bên liên quan đã đề xuất | ⚠ họ có quyền biết yêu cầu của mình đi tới đâu | | ⚠ Có thể được xem xét LẠI khi bối cảnh thay đổi | | | ⚠ Nguyên tắc chung | ⚠ quản lý dự án không xoá dấu vết quyết định — kể cả quyết định nói KHÔNG |

Từ khoá nhận diện:

"tất cả thay đổi và trạng thái của chúng" → ⚠ nhật ký thay đổi "rủi ro và ứng phó" → ⚠ sổ đăng ký rủi ro "vấn đề đang mở và người phụ trách" → ⚠ nhật ký vấn đề "phương án nào bị vứt đi" → ⚠ luôn nghi ngờ — dự án hiếm khi vứt hồ sơ

⚠ Các sổ và nhật ký hay bị lẫn: | Tài liệu | Ghi gì | |---|---| | ⚠ NHẬT KÝ THAY ĐỔI | ⚠ mọi yêu cầu thay đổi và trạng thái — CÂU NÀY | | ⚠ SỔ ĐĂNG KÝ RỦI RO | ⚠ rủi ro, xác suất, tác động, chiến lược ứng phó, chủ sở hữu | | ⚠ NHẬT KÝ VẤN ĐỀ | ⚠ vấn đề ĐÃ xảy ra, người phụ trách, hạn xử lý | | ⚠ SỔ ĐĂNG KÝ BÊN LIÊN QUAN | ⚠ ai, quyền lực, mức quan tâm, chiến lược tiếp cận | | ⚠ SỔ ĐĂNG KÝ GIẢ ĐỊNH | ⚠ giả định và ràng buộc đã ghi nhận | | ⚠ Mẹo phân biệt rủi ro và vấn đề | ⚠ rủi ro là CÓ THỂ xảy ra, vấn đề là ĐÃ xảy ra |

⚠ Bối cảnh: sắp XÁC NHẬN PHẠM VI Ý nghĩa
⚠ Xác nhận phạm vi = khách hàng NGHIỆM THU chính thức bàn giao
⚠ Khác với KIỂM SOÁT CHẤT LƯỢNG — kiểm tính ĐÚNG bên trong ⚠ chất lượng làm TRƯỚC, xác nhận phạm vi làm SAU
⚠ Rà nhật ký thay đổi trước khi nghiệm thu là việc ĐÚNG ⚠ để chắc bàn giao khớp với phạm vi đã được duyệt sau mọi thay đổi
⚠ Rủi ro nếu bỏ qua ⚠ khách hàng nghiệm thu theo phạm vi GỐC trong khi thực tế đã đổi nhiều lần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký thay đổi của bạn có ghi LÝ DO từ chối không | ⚠ chỉ ghi "từ chối" là gần như vô dụng | | Người đề xuất có được thông báo kết quả không | | | Đường cơ sở hiện tại có phản ánh đủ mọi thay đổi đã duyệt không | |

Và giá trị lớn nhất của một nhật ký thay đổi đầy đủ: sáu tháng sau, khi có người hỏi "vì sao dự án lại thành ra thế này", nó là tài liệu duy nhất trả lời được.

Câu 235 Process
A scrum team is wrapping up the current sprint when Patrick, part of the development team, asks the scrum master when the increment is considered done. What would be the best answer the scrum master can give?
  1. A When the team holds the sprint retrospective, the last event for the sprint
  2. B When the allotted timebox for the sprint expires
  3. C When every sprint backlog item to be delivered meets its Definition of Done, and the product owner accepts it
  4. D When the team holds the sprint review and demonstrates the increment to the stakeholders
Xem giải thích

Đáp án

C — Khi MỌI hạng mục trong sprint backlog cần bàn giao đều thoả ĐỊNH NGHĨA HOÀN THÀNH của nó, VÀ product owner chấp nhận.

Vì sao đúng

⚠ Hai điều kiện phải có ĐỦ CẢ HAI: | Điều kiện | Ý nghĩa | |---|---| | ⚠ Thoả ĐỊNH NGHĨA HOÀN THÀNH | ⚠ điều kiện KỸ THUẬT — đã kiểm thử, đã rà soát, đã tích hợp | | ⚠ Product owner CHẤP NHẬN | ⚠ điều kiện GIÁ TRỊ — đúng thứ khách hàng cần | | ⚠ Thiếu một trong hai thì CHƯA XONG | ⚠ mã chạy được mà sai yêu cầu thì vẫn không xong | | ⚠ Vai trò của DoD | ⚠ là hợp đồng chất lượng chung của đội — liên hệ #25953 cùng lô | | ⚠ Vai trò của PO | ⚠ người duy nhất có quyền nói "cái này chấp nhận được" — liên hệ #25929 lô 183 |

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

  • D (khi đội tổ chức sprint review và trình diễn cho bên liên quan) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ sprint review là nơi ⚠ TRÌNH BÀY ⚠ phần đã xong và thu phản hồi, ⚠ KHÔNG phải nơi làm cho nó thành xong; ⚠ mang thứ chưa xong đi demo là sai cách dùng buổi họp này.

  • B (khi hết hộp thời gian của sprint) — ⚠ thời gian hết KHÔNG làm việc dở thành việc xong; ⚠ phần chưa xong quay lại backlog (xem #25936 cùng lô).

  • A (khi đội tổ chức retrospective — sự kiện cuối cùng của sprint) — ⚠ retrospective bàn về QUY TRÌNH, ⚠ không liên quan tới việc phần tăng trưởng có xong hay không.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25953 ở lô này (kiểm thử phải nằm trong DoD) — ⚠ hai câu bổ sung nhau: một câu nói DoD phải CHỨA GÌ, câu này nói DoD dùng ĐỂ LÀM GÌ. ⚠ Xem thêm câu #25929 ở lô 183 (tiêu chí chấp nhận thuộc PO) và câu #25921 (các sự kiện Scrum).

⚠ "Xong" trong Scrum có mấy tầng: | Tầng | Nội dung | |---|---| | ⚠ Tầng 1 — Tiêu chí chấp nhận của hạng mục | ⚠ hạng mục này làm ĐÚNG chưa | | ⚠ Tầng 2 — Định nghĩa Hoàn thành chung | ⚠ có đạt chuẩn CHẤT LƯỢNG của đội không | | ⚠ Tầng 3 — Product owner chấp nhận | ⚠ có đúng thứ cần không | | ⚠ Cả ba tầng | ⚠ phải qua HẾT thì phần tăng trưởng mới thật sự "xong" | | ⚠ Hệ quả | ⚠ "xong 90%" không tồn tại trong Scrum — chỉ có XONG hoặc CHƯA XONG |

Từ khoá nhận diện:

"khi nào phần tăng trưởng được coi là xong" → ⚠ thoả DoD + PO chấp nhận "hết thời gian sprint" → ⚠ không làm việc dở thành xong "sau khi demo" → ⚠ demo là trình bày thứ ĐÃ xong "sau retrospective" → ⚠ retrospective không liên quan tới sản phẩm

⚠ Vì sao "xong 90%" là khái niệm nguy hiểm Lý do
⚠ 90% cuối cùng thường tốn bằng 90% đầu tiên
⚠ Không ai đo được 90% một cách khách quan
⚠ Che giấu vấn đề cho tới lúc quá muộn
⚠ Giá trị chỉ được ghi nhận khi HOÀN TOÀN xong ⚠ liên hệ #25940 — giới hạn WIP cũng vì lý do này
⚠ Cách chữa ⚠ chia hạng mục nhỏ hơn để mỗi hạng mục xong được trong sprint — liên hệ #25899 lô 183
⚠ Phần tăng trưởng KHÔNG được PO chấp nhận thì sao Xử lý
⚠ KHÔNG tính vào velocity của sprint này
⚠ Quay lại product backlog để PO xếp lại ưu tiên ⚠ không tự động chuyển sang sprint sau
⚠ Tìm hiểu VÌ SAO không được chấp nhận ⚠ thường là tiêu chí chấp nhận chưa rõ từ đầu
⚠ Đưa ra retrospective nếu lặp lại ⚠ một lần là sự cố, ba lần là vấn đề quy trình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai dùng cụm "xong nhưng còn..." không | ⚠ dấu hiệu DoD chưa được tôn trọng | | PO có thực sự xem và chấp nhận từng hạng mục không | ⚠ hay chỉ gật đầu ở sprint review | | Có hạng mục nào quay lại sprint sau nhiều lần không | |

Và định nghĩa gọn nhất: một phần tăng trưởng xong là phần có thể phát hành cho người dùng ngay hôm nay — dù đội có quyết định phát hành hay không.

Câu 236 People
In Avi's organization, members of management are referred to as coaches. Avi, as a project manager, is referred to as a project coach. In the creation of a resource document to handle this situation, what should be covered?
  1. A The notion that coaches are separate from managers.
  2. B The concept that the project team is supposed to work for the coach.
  3. C How a coach is supposed to complete the job.
  4. D How coaches and managers are the same.
Xem giải thích

Đáp án

C — Tài liệu phải nêu HUẤN LUYỆN VIÊN PHẢI HOÀN THÀNH CÔNG VIỆC CỦA MÌNH NHƯ THẾ NÀO.

Vì sao đúng

⚠ Vì sao đây là nội dung cần có: | Lý do | Nội dung | |---|---| | ⚠ Tổ chức dùng TÊN GỌI KHÁC THƯỜNG cho vai trò quản lý | ⚠ "huấn luyện viên" thay cho "quản lý" | | ⚠ Tên lạ thì mọi người sẽ hiểu mỗi người một kiểu | ⚠ nguy cơ nhầm lẫn trách nhiệm | | ⚠ Tài liệu nguồn lực phải mô tả VAI TRÒ và TRÁCH NHIỆM cụ thể | ⚠ người này làm gì, chịu trách nhiệm gì, quyền tới đâu | | ⚠ Mô tả CÁCH LÀM VIỆC là trọng tâm | ⚠ không phải tranh luận về từ ngữ | | ⚠ Nguyên tắc chung | ⚠ tài liệu vai trò trả lời "người này LÀM GÌ", không trả lời "người này TÊN LÀ GÌ" |

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

  • A (khái niệm huấn luyện viên KHÁC với quản lý) — ⚠ phương án gây nhiễu mạnh nhất vì có vẻ làm rõ khái niệm: ⚠ nhưng đó là ⚠ tranh luận về THUẬT NGỮ, ⚠ không giúp ai biết mình phải làm gì; ⚠ tài liệu nguồn lực không phải nơi định nghĩa từ vựng.

  • D (huấn luyện viên và quản lý là như nhau) — ⚠ cùng vấn đề, ⚠ và còn phủ nhận chủ ý của tổ chức khi đổi tên gọi.

  • B (đội dự án phải làm việc CHO huấn luyện viên) — ⚠ SAI về tinh thần: ⚠ nếu tổ chức chọn từ "huấn luyện viên" thì hàm ý là ⚠ PHỤC VỤ và PHÁT TRIỂN đội, ⚠ không phải đội làm việc cho họ ⚠ (liên hệ #25952 — lãnh đạo phục vụ).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25944 ở lô này (dùng lại định nghĩa vai trò và trách nhiệm) — ⚠ hai câu cùng nói về tài liệu vai trò, một câu về việc DÙNG LẠI, câu này về việc VIẾT MỚI khi tổ chức có cách gọi riêng. ⚠ Xem thêm câu #25898 ở lô 183 và câu #25952 (lãnh đạo phục vụ).

⚠ Tài liệu vai trò và trách nhiệm nên có gì: | Mục | Nội dung | |---|---| | ⚠ VAI TRÒ | ⚠ tên gọi và vị trí trong dự án | | ⚠ THẨM QUYỀN | ⚠ quyết được gì, ký được tới mức nào | | ⚠ TRÁCH NHIỆM | ⚠ phải làm những việc gì — CÂU NÀY | | ⚠ NĂNG LỰC | ⚠ kỹ năng và kinh nghiệm cần có | | ⚠ Bốn mục này | ⚠ là bộ chuẩn của tài liệu vai trò trong quản lý nguồn lực | | ⚠ Thiếu mục THẨM QUYỀN | ⚠ lỗi phổ biến nhất — người ta biết phải làm gì nhưng không biết được quyết gì |

Từ khoá nhận diện:

"tổ chức dùng tên gọi riêng cho vai trò" → ⚠ tài liệu phải mô tả CÁCH LÀM VIỆC "định nghĩa từ ngữ, so sánh khái niệm" → ⚠ không phải việc của tài liệu nguồn lực "đội làm việc CHO ai" → ⚠ cách nói của mô hình chỉ huy, không hợp với từ "huấn luyện viên"

⚠ Vì sao tên gọi vai trò lại quan trọng Lý do
⚠ Tên gọi định hình KỲ VỌNG hành vi ⚠ gọi là "huấn luyện viên" thì người ta chờ đợi sự dẫn dắt, không phải mệnh lệnh
⚠ Nhưng tên gọi KHÔNG tự thay đổi hành vi ⚠ đổi tên mà không đổi cách làm thì chỉ là thay nhãn
⚠ Vì thế phải VIẾT RÕ cách làm việc kèm theo ⚠ đúng điều câu hỏi đang nhắm tới
⚠ Ví dụ thực tế ⚠ nhiều tổ chức đổi "quản lý dự án" thành "Scrum Master" mà công việc vẫn y nguyên — nhân viên nhận ra ngay
⚠ Huấn luyện viên khác quản lý truyền thống ở đâu Khác biệt
⚠ HỎI thay vì BẢO
⚠ Phát triển năng lực dài hạn, không chỉ giao kết quả ngắn hạn
⚠ Trao quyền quyết định cho người làm ⚠ liên hệ #25937 — trao quyền cho đội tự giải quyết
⚠ Đo thành công bằng sự trưởng thành của người được huấn luyện
⚠ Vẫn giữ ⚠ trách nhiệm về kết quả — huấn luyện viên không phải người đứng ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi người trong đội có biết ai quyết được gì không | ⚠ thử hỏi ba người về một quyết định cụ thể | | Tài liệu vai trò có ghi THẨM QUYỀN không | | | Tên gọi vai trò ở tổ chức bạn có khớp với hành vi thực tế không | |

Và điều một tổ chức đổi tên gọi vai trò phải hiểu: cái tên tạo ra một lời hứa. Tài liệu mô tả cách làm việc là thứ duy nhất khiến lời hứa đó có thật.

Câu 237 Process
Nico reviews and refines a project scope statement with his team before signing off and confirming its contents with stakeholders. Although the project's original scope was very broad, they discovered that they are expected to provide one hundred printers, toner, and spare parts for the project and maintenance for up to a year. Nico runs a small shop with several other clients, so he quickly calls the project's primary stakeholder to discuss these requirements. This is an example of which part of the project scope statement?
  1. A Deliverables
  2. B Project exclusions
  3. C Product scope description
  4. D Acceptance criteria
Xem giải thích

Đáp án

A — BÀN GIAO (deliverables).

Vì sao đúng

⚠ Những thứ đề liệt kê là gì: | Hạng mục | Loại | |---|---| | ⚠ Một trăm máy in | ⚠ sản phẩm phải giao | | ⚠ Mực in | ⚠ sản phẩm phải giao | | ⚠ Phụ tùng thay thế | ⚠ sản phẩm phải giao | | ⚠ Bảo trì tới một năm | ⚠ DỊCH VỤ phải giao — bàn giao không nhất thiết phải là vật thể | | ⚠ Định nghĩa | ⚠ bàn giao là bất kỳ sản phẩm, kết quả hoặc khả năng nào phải tạo ra để hoàn thành dự án |

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

  • C (mô tả phạm vi sản phẩm) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ mô tả phạm vi sản phẩm là ⚠ phần MÔ TẢ ĐẶC ĐIỂM ⚠ của sản phẩm ⚠ ("máy in laser đen trắng, tốc độ 30 trang/phút"), ⚠ không phải DANH SÁCH những thứ phải giao; ⚠ đề đang liệt kê SỐ LƯỢNG và HẠNG MỤC, không mô tả đặc tính.

  • D (tiêu chí chấp nhận) — ⚠ điều kiện để bàn giao được CHẤP NHẬN ⚠ ("máy in phải hoạt động liên tục 30 ngày không lỗi"); ⚠ đề không nêu điều kiện nào.

  • B (loại trừ khỏi phạm vi) — ⚠ những thứ dự án KHÔNG làm; ⚠ đề đang nói những thứ PHẢI làm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25956 ở lô này (nhật ký thay đổi, và bối cảnh xác nhận phạm vi), câu #25943 (RFQ mua 1.000 bộ thiết bị), và câu #25929 ở lô 183 (tiêu chí chấp nhận thuộc PO). ⚠ Nhóm quản lý phạm vi.

⚠ Các thành phần của TUYÊN BỐ PHẠM VI DỰ ÁN: | Thành phần | Nội dung | |---|---| | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | ⚠ đặc điểm của sản phẩm hoặc dịch vụ | | ⚠ BÀN GIAO | ⚠ danh sách những thứ phải tạo ra — CÂU NÀY | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ điều kiện để được nghiệm thu | | ⚠ LOẠI TRỪ KHỎI PHẠM VI | ⚠ những thứ RÕ RÀNG không thuộc dự án | | ⚠ Mục hay bị bỏ qua nhất | ⚠ LOẠI TRỪ — nhưng đó lại là mục ngăn tranh chấp hiệu quả nhất |

Từ khoá nhận diện:

"danh sách những thứ phải giao, kèm số lượng" → ⚠ bàn giao "đặc điểm, tính năng của sản phẩm" → ⚠ mô tả phạm vi sản phẩm "điều kiện để được chấp nhận" → ⚠ tiêu chí chấp nhận "những thứ KHÔNG làm" → ⚠ loại trừ khỏi phạm vi

⚠ Vì sao Nico gọi ngay cho bên liên quan chính Lý do
⚠ Anh chạy một cửa hàng NHỎ và còn nhiều khách khác ⚠ năng lực có hạn
⚠ "Bảo trì TỚI MỘT NĂM" là cam kết dài hạn ⚠ ràng buộc nguồn lực suốt một năm — liên hệ #25935
⚠ Phạm vi gốc RẤT RỘNG, giờ mới lộ chi tiết ⚠ dấu hiệu phạm vi chưa được làm rõ từ đầu
⚠ Việc anh làm là ĐÚNG ⚠ làm rõ TRƯỚC khi ký, không phải sau khi ký rồi mới kêu
⚠ Bài học ⚠ "phạm vi rất rộng" trong tuyên bố ban đầu gần như luôn là dấu hiệu của rắc rối sắp tới
⚠ Bàn giao có mấy loại Loại
⚠ SẢN PHẨM ⚠ vật thể hữu hình — máy in, mực, phụ tùng
⚠ KẾT QUẢ ⚠ tài liệu, báo cáo, quy trình mới
⚠ KHẢ NĂNG ⚠ dịch vụ, năng lực vận hành — bảo trì một năm
⚠ Bàn giao TRUNG GIAN ⚠ sản phẩm của từng giai đoạn, không giao cho khách
⚠ Điểm hay quên ⚠ DỊCH VỤ cũng là bàn giao — và thường là phần khó ước lượng chi phí nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyên bố phạm vi của bạn có mục LOẠI TRỪ không | | | Có bàn giao nào là DỊCH VỤ kéo dài sau khi dự án đóng không | ⚠ cần kế hoạch riêng cho phần đó | | Bạn có đủ năng lực cho mọi bàn giao đã cam kết không | |

Và cái bẫy lớn nhất trong tình huống của Nico: một dòng chữ "bảo trì tới một năm" có thể nặng hơn cả một trăm máy in cộng lại, và nó luôn được viết bằng cỡ chữ nhỏ hơn.

Câu 238 Process
You are the project manager of a construction project for a new client. The client has asked that you include an outdoor deck as part of the project—something your company does not normally do, but you agree to take on this project component using a contractor to build the seating deck. For this portion of the project, you would like to use a time and materials contract. What must this contract type have?
  1. A A not-to-exceed clause
  2. B The signature of the purchasing agent
  3. C Addendums for each change in the project work
  4. D An end date for the procured work
Xem giải thích

Đáp án

A — ĐIỀU KHOẢN TRẦN (not-to-exceed clause).

Vì sao đúng

⚠ Vì sao hợp đồng T&M cần điều khoản trần: | Lý do | Nội dung | |---|---| | ⚠ T&M trả theo GIỜ CÔNG và VẬT TƯ THỰC TẾ | ⚠ không có giá cố định | | ⚠ Không có trần thì chi phí có thể tăng VÔ HẠN | ⚠ rủi ro dồn hết về bên MUA | | ⚠ Nhà thầu KHÔNG có động lực làm nhanh | ⚠ càng lâu càng được trả nhiều | | ⚠ Điều khoản trần đặt GIỚI HẠN TỐI ĐA | ⚠ vượt trần thì phải thương lượng lại | | ⚠ Thực tế | ⚠ hầu như không tổ chức nào phê duyệt hợp đồng T&M không có trần |

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

  • D (ngày kết thúc cho phần công việc mua sắm) — ⚠ phương án gây nhiễu mạnh nhất vì giới hạn thời gian nghe cũng như một cách kiểm soát: ⚠ nhưng ⚠ ngày kết thúc là điều NÊN CÓ, không phải điều BẮT BUỘC PHẢI CÓ; ⚠ và ⚠ giới hạn thời gian không tự động giới hạn CHI PHÍ ⚠ — nhà thầu vẫn có thể tăng số người làm.

  • C (phụ lục cho mỗi thay đổi trong công việc dự án) — ⚠ chính ưu điểm của T&M là KHÔNG cần sửa hợp đồng cho mỗi thay đổi nhỏ; ⚠ đòi phụ lục cho mọi thay đổi là mất hết tính linh hoạt.

  • B (chữ ký của nhân viên mua hàng) — ⚠ quy định nội bộ của từng tổ chức, ⚠ không phải đặc tính bắt buộc của loại hợp đồng này.

Ghi nhớ

⚠ Đối chiếu: ⚠ đây là câu thứ BA về hợp đồng T&M: ⚠ câu #25733 ở lô 180 (chọn T&M cho công việc chưa rõ phạm vi), ⚠ câu #25765 ở lô 180 (nhận diện T&M từ hoá đơn), ⚠ và câu này (T&M bắt buộc có trần). ⚠ Ba câu bổ sung nhau đầy đủ: KHI NÀO dùng, NHẬN RA thế nào, và PHẢI CÓ gì. ⚠ Xem thêm câu #25951 ở lô này (mua sắm agile) và câu #25882 ở lô 182 (PTA của FPIF).

⚠ BA họ hợp đồng và ai chịu rủi ro: | Họ hợp đồng | Bên chịu rủi ro chi phí | Dùng khi | |---|---|---| | ⚠ GIÁ CỐ ĐỊNH (FP) | ⚠ NGƯỜI BÁN | ⚠ phạm vi rất rõ ràng | | ⚠ HOÀN PHÍ (CR) | ⚠ NGƯỜI MUA | ⚠ phạm vi bất định cao, nghiên cứu | | ⚠ THỜI GIAN VÀ VẬT TƯ (T&M) | ⚠ NGƯỜI MUA — trừ khi có TRẦN | ⚠ việc nhỏ, cần bắt đầu nhanh, phạm vi chưa rõ hết | | ⚠ T&M là loại LAI | ⚠ có đơn giá cố định (như FP) nhưng tổng khối lượng chưa biết (như CR) | | ⚠ Đúng tình huống này | ⚠ công ty không thường làm sàn ngoài trời, phạm vi chưa rõ hết — T&M là lựa chọn hợp lý |

Từ khoá nhận diện:

"T&M bắt buộc phải có gì" → ⚠ điều khoản trần "trả theo giờ và vật tư" → ⚠ T&M "phụ lục cho mọi thay đổi" → ⚠ mất tính linh hoạt, trái mục đích T&M "chữ ký nhân viên mua hàng" → ⚠ quy định nội bộ, không phải đặc tính hợp đồng

⚠ Kiểm soát hợp đồng T&M thế nào Cách
⚠ Đặt TRẦN chi phí ⚠ bắt buộc — CÂU NÀY
⚠ Đặt trần SỐ GIỜ hoặc thời hạn ⚠ nên có thêm
⚠ Yêu cầu báo cáo tiến độ và giờ công định kỳ
⚠ Xác định rõ đơn giá từng loại nhân sự TRƯỚC ⚠ không để nhà thầu tự đưa người đắt tiền vào
⚠ Xác định rõ cách tính vật tư ⚠ giá gốc hay giá gốc cộng phần trăm
⚠ Theo dõi sát ⚠ T&M là loại hợp đồng cần giám sát chặt nhất, vì tiền chạy theo thời gian
⚠ Vì sao vẫn dùng T&M dù rủi ro dồn về bên mua Lý do
⚠ Bắt đầu được NGAY, không phải đợi xác định phạm vi đầy đủ
⚠ Linh hoạt khi công việc thay đổi
⚠ Phù hợp với việc NHỎ và NGẮN ⚠ như phần sàn ngoài trời của tình huống này
⚠ Nguyên tắc an toàn ⚠ T&M cho việc nhỏ thì hợp lý; T&M cho cả dự án lớn là dấu hiệu phạm vi chưa được làm rõ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng T&M của bạn có trần không | | | Bạn có theo dõi chi phí luỹ kế so với trần hằng tuần không | | | Đơn giá từng loại nhân sự có được ghi rõ không | |

Và câu hỏi duy nhất cần đặt trước khi ký một hợp đồng T&M: nếu công việc này tốn gấp ba lần dự kiến, tôi có sẵn sàng trả không? Nếu câu trả lời là không, thì trần phải nằm trong hợp đồng.

Câu 239 People
Ethel is the scrum master for Project W, which is 9 iterations into deployment and has a velocity of 102 story points. During a recent sprint review, Ethel noticed that several stakeholders did not understand recent project developments. What is the most likely cause for this?
  1. A The stakeholders were busy with other projects.
  2. B The stakeholders are not involved in Project W.
  3. C Ethel has not adequately engaged those stakeholders.
  4. D The project team does not give engaging presentations.
Xem giải thích

Đáp án

C — Ethel CHƯA GẮN KẾT những bên liên quan đó một cách đầy đủ.

Vì sao đúng

⚠ Vì sao trách nhiệm thuộc về Scrum Master: | Lý do | Nội dung | |---|---| | ⚠ Gắn kết bên liên quan là TRÁCH NHIỆM CHỦ ĐỘNG của người dẫn dắt | ⚠ không phải chờ họ tự tìm hiểu | | ⚠ Dự án đã ở vòng lặp thứ 9 — đã có 8 lần sprint review trước đó | ⚠ thời gian gắn kết là quá đủ | | ⚠ Bên liên quan KHÔNG NẮM diễn biến là dấu hiệu của khoảng trống giao tiếp | | | ⚠ Ba phương án còn lại đều ĐỔ LỖI cho người khác | ⚠ mẫu hình quen thuộc trong đề PMP: đáp án đúng thường là nhận trách nhiệm | | ⚠ Nguyên tắc | ⚠ người gửi chịu trách nhiệm làm cho thông điệp được hiểu — liên hệ #25948 cùng lô |

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

  • A (bên liên quan bận với dự án khác) — ⚠ phương án gây nhiễu mạnh nhất vì rất có thể là SỰ THẬT: ⚠ nhưng ⚠ đó là điều Ethel PHẢI TÍNH ĐẾN khi lập kế hoạch gắn kết, ⚠ không phải cái cớ; ⚠ bên liên quan bận là chuyện bình thường, việc của người dẫn dắt là tìm cách tiếp cận phù hợp.

  • B (bên liên quan không tham gia dự án W) — ⚠ mâu thuẫn với đề: ⚠ họ đang DỰ sprint review, tức là có tham gia.

  • D (đội không trình bày hấp dẫn) — ⚠ đổ lỗi cho đội; ⚠ và vấn đề là ⚠ KHÔNG NẮM ĐƯỢC DIỄN BIẾN, ⚠ không phải buổi trình bày nhàm chán.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25913 ở lô 183 (bên liên quan không hiểu story point), câu #25905 (đưa phản hồi của bên liên quan vào backlog), câu #25877 ở lô 182 (mời bên liên quan tới demo), và câu #25949 ở lô này (hỏi bên liên quan muốn nhận tin thế nào). ⚠ Nhóm gắn kết bên liên quan.

⚠ Bốn mức gắn kết bên liên quan: | Mức | Nghĩa | |---|---| | ⚠ KHÔNG BIẾT (unaware) | ⚠ chưa biết dự án tồn tại hoặc tác động của nó | | ⚠ CHỐNG ĐỐI (resistant) | ⚠ biết và phản đối | | ⚠ TRUNG LẬP (neutral) | ⚠ biết nhưng không ủng hộ cũng không phản đối | | ⚠ ỦNG HỘ (supportive) | ⚠ biết và ủng hộ | | ⚠ DẪN DẮT (leading) | ⚠ chủ động tham gia bảo đảm dự án thành công | | ⚠ Công cụ | ⚠ ma trận đánh giá mức gắn kết — ghi mức HIỆN TẠI và mức MONG MUỐN cho từng bên | | ⚠ Ở tình huống này | ⚠ những bên đó đang ở mức thấp hơn mức cần thiết, và không ai theo dõi khoảng cách đó |

Từ khoá nhận diện:

"bên liên quan không nắm được tình hình" → ⚠ người dẫn dắt chưa gắn kết đủ "họ bận / họ không quan tâm" → ⚠ cái cớ, không phải nguyên nhân gốc "đội trình bày không hấp dẫn" → ⚠ đổ lỗi cho đội ⚠ Phương án NHẬN TRÁCH NHIỆM → ⚠ thường là đáp án đúng trong đề PMP

⚠ Ethel nên làm gì Việc
⚠ Rà lại sổ đăng ký bên liên quan và mức gắn kết
⚠ HỎI từng bên họ muốn nhận thông tin thế nào và bao lâu một lần ⚠ liên hệ #25949 — hỏi Jessie
⚠ Gửi tóm tắt NGẮN trước mỗi sprint review ⚠ để họ tới với bối cảnh sẵn có
⚠ Dùng bảng thông tin để họ tự xem bất cứ lúc nào ⚠ kênh KÉO
⚠ Trao đổi riêng với bên quan trọng nhưng bận
⚠ Điều KHÔNG nên làm ⚠ kéo dài sprint review để giải thích lại từ đầu — sai chỗ và sai lúc
⚠ Vì sao chi tiết "vòng lặp 9, velocity 102" đáng chú ý Ý nghĩa
⚠ Đội chạy rất tốt về mặt kỹ thuật ⚠ velocity cao và ổn định
⚠ Nhưng phần GẮN KẾT bên ngoài lại bị bỏ quên
⚠ Đây là mẫu hình rất thật ⚠ đội tập trung vào sản phẩm mà quên mất người sẽ dùng và phê duyệt nó
⚠ Hậu quả nếu để lâu ⚠ tới lúc cần phê duyệt hoặc cần ngân sách tiếp thì không ai ủng hộ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ma trận mức gắn kết bên liên quan không | ⚠ hay chỉ có danh sách tên | | Lần cuối rà lại danh sách đó là khi nào | ⚠ bên liên quan thay đổi theo giai đoạn dự án | | Có bên nào quan trọng mà bạn chưa nói chuyện riêng lần nào không | |

Và điều mà một velocity 102 điểm không nói cho bạn biết: đội đang làm rất nhanh, nhưng không ai bảo đảm là những người sẽ ký nghiệm thu vẫn còn đi cùng đường với đội.

Câu 240 Business Environment
Geoff is the project manager for a landscaping company. He recently procured enough pesticide to last his company the rest of the season. While accepting the shipment, Geoff recognizes the pesticide's name as one he recently read about in the newspaper. When he gets back to his desk, he finds the article about the pesticide and reads that it was recently made illegal for residential projects. If his company decides to use the pesticide anyway, it will incur significant regulatory risk. How is project compliance being managed?
  1. A Compliance audit
  2. B Compliance documentation
  3. C Compliance risk
  4. D Compliance council
Xem giải thích

Đáp án

C — RỦI RO TUÂN THỦ (compliance risk).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Thuốc trừ sâu VỪA bị cấm dùng cho công trình khu dân cư | ⚠ quy định pháp lý đã thay đổi | | ⚠ Công ty ĐANG CÂN NHẮC vẫn dùng | ⚠ chưa xảy ra hậu quả — vẫn là RỦI RO | | ⚠ Sẽ gánh rủi ro pháp lý đáng kể | ⚠ đề nói thẳng bằng từ "rủi ro" | | ⚠ Định nghĩa | ⚠ rủi ro tuân thủ là khả năng tổ chức vi phạm luật, quy định hoặc chuẩn mực áp dụng | | ⚠ Đang được quản lý thế nào | ⚠ Geoff đã NHẬN DIỆN được rủi ro — bước đầu tiên của quản lý rủi ro |

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

  • A (kiểm toán tuân thủ) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ kiểm toán tuân thủ là ⚠ cuộc rà soát CÓ CẤU TRÚC, do bên độc lập làm ⚠ (xem #25947 cùng lô); ⚠ ở đây ⚠ Geoff tình cờ đọc báo và tự nhận ra ⚠ — không có cuộc kiểm toán nào cả.

  • B (tài liệu tuân thủ) — ⚠ là hồ sơ chứng minh đã tuân thủ; ⚠ chưa có tài liệu nào được lập trong tình huống này.

  • D (hội đồng tuân thủ) — ⚠ một cơ cấu tổ chức; ⚠ không xuất hiện trong đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25947 ở lô này (kiểm toán), câu #25923 ở lô 183 (kỹ thuật nhận diện rủi ro), câu #25909 (thay đổi luật là yếu tố BÊN NGOÀI), và câu #25955 (danh sách kiểm an toàn). ⚠ Cả nhóm về tuân thủ và rủi ro pháp lý.

⚠ Bốn cách tổ chức quản lý tuân thủ: | Cách | Nội dung | |---|---| | ⚠ RỦI RO TUÂN THỦ | ⚠ nhận diện và đánh giá khả năng vi phạm — CÂU NÀY | | ⚠ KIỂM TOÁN TUÂN THỦ | ⚠ rà soát độc lập xem có đang tuân thủ không | | ⚠ TÀI LIỆU TUÂN THỦ | ⚠ hồ sơ chứng minh đã tuân thủ | | ⚠ HỘI ĐỒNG TUÂN THỦ | ⚠ cơ cấu ra quyết định và giám sát | | ⚠ Bốn thứ này bổ sung nhau | ⚠ nhận diện rủi ro → có cơ chế giám sát → kiểm toán định kỳ → lưu hồ sơ |

Từ khoá nhận diện:

"có thể vi phạm quy định" → ⚠ rủi ro tuân thủ "rà soát độc lập xem có tuân thủ không" → ⚠ kiểm toán tuân thủ "hồ sơ chứng minh" → ⚠ tài liệu tuân thủ "CÓ THỂ xảy ra" → ⚠ rủi ro; "ĐÃ xảy ra" → vấn đề

⚠ Geoff nên làm gì tiếp theo Bước
⚠ 1. XÁC MINH thông tin từ nguồn chính thức ⚠ báo chí có thể sai hoặc chưa đầy đủ — kiểm văn bản pháp quy
⚠ 2. Ghi vào SỔ ĐĂNG KÝ RỦI RO ngay
⚠ 3. Báo cho lãnh đạo và bộ phận pháp chế ⚠ đây là quyết định vượt thẩm quyền của một PM
⚠ 4. Tìm sản phẩm thay thế hợp pháp ⚠ chiến lược NÉ TRÁNH rủi ro
⚠ 5. Xem có trả lại lô hàng cho nhà cung cấp được không
⚠ Điều TUYỆT ĐỐI không làm ⚠ cứ dùng rồi hy vọng không ai phát hiện — đây là vấn đề ĐẠO ĐỨC NGHỀ NGHIỆP, không chỉ là bài toán rủi ro
⚠ Quy tắc đạo đức của PMI về vấn đề này Nội dung
⚠ TRÁCH NHIỆM — tuân thủ luật pháp là nghĩa vụ, không phải lựa chọn
⚠ TRUNG THỰC — phải báo cáo điều mình biết
⚠ CÔNG BẰNG — không được đẩy rủi ro sang cộng đồng dân cư
⚠ Điểm cốt lõi ⚠ quản lý rủi ro KHÔNG bao giờ được dùng để biện minh cho việc cố ý vi phạm pháp luật
⚠ Tính "đáng giá" ⚠ kể cả khi phân tích cho thấy xác suất bị phát hiện thấp, hành vi đó vẫn sai
⚠ Vì sao rủi ro tuân thủ đặc biệt nguy hiểm Lý do
⚠ Hậu quả không chỉ là tiền phạt ⚠ mất giấy phép, truy cứu trách nhiệm cá nhân
⚠ Ảnh hưởng danh tiếng khó phục hồi
⚠ Quy định THAY ĐỔI mà không ai thông báo riêng cho bạn ⚠ đúng tình huống này — Geoff biết được là do tình cờ
⚠ Cách phòng ngừa ⚠ có người hoặc quy trình theo dõi thay đổi quy định trong ngành, không dựa vào may mắn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai trong tổ chức bạn theo dõi thay đổi quy định | ⚠ nếu câu trả lời là "không ai" thì đó là một rủi ro lớn | | Sổ rủi ro của bạn có mục rủi ro pháp lý không | | | Bạn có kênh nào để nêu lo ngại về tuân thủ không | |

Và điều đáng lo nhất trong tình huống này: Geoff biết được chỉ vì tình cờ đọc báo. Nếu hôm đó anh không đọc, lô thuốc đã được dùng và không ai biết cho tới khi có chuyện.