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

Tìm thấy 720 câu.

Câu 381 People
You are the project manager for a new agile project and you're hosting the retrospective. A major defect has appeared during the sprint review and you and the team want to find the causal factors for the defect. Which of the following choices is the best way for an agile team to list the reasons why a specific process failed during an iteration?
  1. A Short subjects
  2. B SMART goals
  3. C Check-in analysis
  4. D Fishbone analysis
Xem giải thích

Đáp án

D — PHÂN TÍCH XƯƠNG CÁ (fishbone analysis).

Vì sao đúng

⚠ Vì sao xương cá phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Đội muốn tìm CÁC YẾU TỐ NGUYÊN NHÂN của một khiếm khuyết | ⚠ đúng mục đích của biểu đồ nhân quả | | ⚠ Xương cá NHÓM nguyên nhân theo các mảng lớn | ⚠ con người, quy trình, công cụ, môi trường, vật liệu, đo lường | | ⚠ Liệt kê được NHIỀU nguyên nhân có thể cùng lúc | ⚠ đúng yêu cầu "liệt kê các lý do" | | ⚠ Là hoạt động NHÓM, hợp với retrospective | | | ⚠ Ba tên gọi | ⚠ xương cá = Ishikawa = biểu đồ nhân quả — liên hệ ghi chú chất lượng ở #26013 lô 185 |

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

  • A (short subjects) — ⚠ phương án gây nhiễu mạnh nhất vì đó là một KỸ THUẬT RETROSPECTIVE có thật: ⚠ nó là khuôn ⚠ "tiếp tục làm / ngừng làm / bắt đầu làm" ⚠ — dùng để THU THẬP Ý KIẾN chung, ⚠ không phải để PHÂN TÍCH NGUYÊN NHÂN GỐC của một khiếm khuyết cụ thể.

  • B (mục tiêu SMART) — ⚠ khuôn đặt mục tiêu: ⚠ cụ thể, đo được, khả thi, liên quan, có thời hạn; ⚠ không phân tích nguyên nhân.

  • C (check-in analysis) — ⚠ không phải thuật ngữ chuẩn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26013 ở lô 185 (cây quyết định — xương cá và Ishikawa bị liệt kê thành hai phương án riêng), câu #25626 lô 177 (đúng lỗi đó lần đầu), và câu #26086 ở lô này (biểu đồ phân tán). ⚠ Đây là lần đầu xương cá là KHOÁ ĐÁP ÁN sau hai lần xuất hiện làm phương án nhiễu.

⚠ Biểu đồ xương cá hoạt động thế nào: | Thành phần | Nội dung | |---|---| | ⚠ ĐẦU CÁ: vấn đề cần phân tích | ⚠ "khiếm khuyết X xuất hiện ở sprint review" | | ⚠ XƯƠNG SỐNG: đường chính | | | ⚠ CÁC XƯƠNG NHÁNH: nhóm nguyên nhân | ⚠ thường dùng 6M: Con người, Phương pháp, Máy móc, Vật liệu, Đo lường, Môi trường | | ⚠ XƯƠNG NHỎ: nguyên nhân cụ thể trong từng nhóm | | | ⚠ Cách dùng trong phần mềm | ⚠ nhóm thường đổi thành: con người, quy trình, công cụ, mã nguồn, yêu cầu, môi trường | | ⚠ Kết hợp với | ⚠ kỹ thuật "5 WHY" — hỏi vì sao năm lần để đào sâu từng nhánh |

Từ khoá nhận diện:

"tìm nguyên nhân gốc, liệt kê lý do" → ⚠ xương cá / Ishikawa / nhân quả "tiếp tục / ngừng / bắt đầu" → ⚠ short subjects, kỹ thuật retrospective "cụ thể, đo được, khả thi..." → ⚠ mục tiêu SMART "80/20, ít nguyên nhân gây nhiều lỗi" → ⚠ Pareto

⚠ Các kỹ thuật retrospective phổ biến — đừng nhầm với công cụ phân tích: | Kỹ thuật | Dùng để | |---|---| | ⚠ SHORT SUBJECTS | ⚠ thu ý kiến: tiếp tục / ngừng / bắt đầu | | ⚠ THUYỀN BUỒM | ⚠ cái gì đẩy đội đi, cái gì kéo lại | | ⚠ TIMELINE | ⚠ nhìn lại sự kiện theo dòng thời gian | | ⚠ XƯƠNG CÁ | ⚠ đào sâu NGUYÊN NHÂN của một vấn đề cụ thể — CÂU NÀY | | ⚠ 5 WHY | ⚠ đào sâu một chuỗi nguyên nhân | | ⚠ Khi nào dùng xương cá | ⚠ khi có MỘT vấn đề cụ thể cần mổ xẻ, không phải khi rà soát chung cả sprint |

⚠ Vì sao phân tích nguyên nhân quan trọng hơn sửa lỗi Lý do
⚠ Sửa lỗi giải quyết TRIỆU CHỨNG ⚠ liên hệ #25933 lô 184 — sửa lỗi
⚠ Sửa nguyên nhân ngăn lỗi TÁI DIỄN ⚠ liên hệ #25939 — hành động khắc phục
⚠ Một khiếm khuyết lọt tới sprint review thường có nhiều nguyên nhân cùng lúc ⚠ đúng lý do dùng xương cá thay vì chỉ hỏi một câu
⚠ Kết quả nên có ⚠ một hoặc hai HÀNH ĐỘNG cụ thể, có người phụ trách — không phải danh sách nguyên nhân để đó
⚠ Có thể dẫn tới ⚠ siết ĐỊNH NGHĨA HOÀN THÀNH — liên hệ #26097 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khiếm khuyết gần nhất của đội bạn có được phân tích nguyên nhân không | ⚠ hay chỉ sửa rồi thôi | | Retrospective của bạn có kết thúc bằng hành động cụ thể không | | | Có loại lỗi nào cứ lặp lại không | ⚠ dấu hiệu chưa chạm tới nguyên nhân gốc |

Và điều một buổi phân tích xương cá làm được mà việc sửa lỗi không làm được: nó biến câu hỏi "ai làm sai" thành câu hỏi "hệ thống của chúng ta đã cho phép điều này xảy ra như thế nào" — và chỉ câu hỏi thứ hai mới sửa được gì đó lâu dài.

Câu 382 Process
As a scrum master, you facilitate a product backlog grooming workshop with the product owner. You have many stakeholders and the entire team to break down the epics and user stories by complexity and effort. Doing so is a crucial process for the sprint planning session. Accuracy and team buy-in are critical, and the workshop is time-boxed to maintain a sharp focus. Which agile estimation method would you recommend to a large team dealing with a complex product?
  1. A Affinity estimating
  2. B Planning poker
  3. C Dot voting
  4. D The bucket system
Xem giải thích

Đáp án

D — HỆ THỐNG NHÓM (the bucket system).

Vì sao đúng

⚠ Vì sao hệ thống nhóm phù hợp với tình huống: | Yêu cầu trong đề | Hệ thống nhóm đáp ứng thế nào | |---|---| | ⚠ ĐỘI LỚN, nhiều bên liên quan | ⚠ chia nhóm nhỏ ước lượng song song — quy mô không thành vấn đề | | ⚠ SẢN PHẨM PHỨC TẠP, nhiều epic và user story | ⚠ xử lý được số lượng hạng mục rất lớn | | ⚠ Có HỘP THỜI GIAN, cần giữ tập trung | ⚠ nhanh hơn nhiều so với thảo luận từng hạng mục | | ⚠ Cần ĐỘ CHÍNH XÁC và SỰ ĐỒNG THUẬN | ⚠ vẫn giữ được vì cả nhóm cùng hiệu chỉnh ở cuối | | ⚠ Cách làm | ⚠ đặt sẵn các "thùng" theo thang (1, 2, 3, 5, 8, 13...), rồi PHÂN LOẠI hạng mục vào thùng thay vì ước lượng từng cái |

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

  • B (planning poker) — ⚠ phương án gây nhiễu mạnh nhất vì đó là kỹ thuật ước lượng agile nổi tiếng nhất: ⚠ nhưng planning poker ⚠ ước lượng TỪNG hạng mục MỘT, có thảo luận khi lệch nhau ⚠ — ⚠ quá chậm cho đội LỚN với sản phẩm PHỨC TẠP trong một hộp thời gian; ⚠ nó hợp với đội nhỏ và số hạng mục vừa phải.

  • A (ước lượng theo nhóm tương đồng — affinity estimating) — ⚠ rất gần với hệ thống nhóm và cũng nhanh: ⚠ nhưng nó thiên về ⚠ XẾP HẠNG TƯƠNG ĐỐI theo cảm nhận, ⚠ còn hệ thống nhóm ⚠ có sẵn THANG SỐ và quy trình hiệu chỉnh rõ ràng hơn ⚠ — hợp hơn khi cần độ chính xác cho lập kế hoạch sprint.

  • C (bỏ phiếu chấm điểm — dot voting) — ⚠ kỹ thuật XẾP ƯU TIÊN, ⚠ không phải ước lượng kích cỡ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26095 ở lô này (affinity estimating là phương án nhiễu), câu #25993 lô 185 (không áp velocity từ đội khác), câu #26043 lô 186 (phương pháp 100 điểm), và câu #25990 lô 185 (bốn kỹ thuật ước lượng của quản lý dự án truyền thống). ⚠ Nhóm ước lượng.

⚠ Các kỹ thuật ước lượng AGILE — bảng đối chiếu: | Kỹ thuật | Cách làm | Hợp với | |---|---|---| | ⚠ PLANNING POKER | ⚠ từng hạng mục, mọi người giơ bài cùng lúc, thảo luận khi lệch | ⚠ đội NHỎ, số hạng mục vừa phải | | ⚠ AFFINITY ESTIMATING | ⚠ xếp hạng mục cạnh nhau theo độ lớn tương đối | ⚠ nhiều hạng mục, cần nhanh | | ⚠ HỆ THỐNG NHÓM (bucket) | ⚠ có sẵn thùng theo thang số, phân loại hạng mục vào thùng | ⚠ đội LỚN, RẤT nhiều hạng mục — CÂU NÀY | | ⚠ T-SHIRT SIZING | ⚠ S, M, L, XL — thô nhất | ⚠ ước lượng sơ bộ ở mức epic | | ⚠ ƯỚC LƯỢNG TƯƠNG ĐỐI theo hạng mục chuẩn | ⚠ so với một hạng mục đã biết | ⚠ mọi quy mô | | ⚠ Điểm chung của mọi kỹ thuật agile | ⚠ ước lượng TƯƠNG ĐỐI, do ĐỘI thực hiện, và KHÔNG quy ra giờ |

Từ khoá nhận diện:

"đội lớn, nhiều hạng mục, có hộp thời gian" → ⚠ hệ thống nhóm "đội nhỏ, thảo luận kỹ từng hạng mục" → ⚠ planning poker "xếp cạnh nhau theo độ lớn" → ⚠ affinity estimating "bỏ phiếu chấm điểm" → ⚠ xếp ưu tiên, không phải ước lượng

⚠ Hệ thống nhóm hoạt động thế nào: | Bước | Nội dung | |---|---| | ⚠ 1. Đặt sẵn các "thùng" theo thang | ⚠ 1, 2, 3, 5, 8, 13, 20, 40, 100 | | ⚠ 2. Ước lượng một hạng mục ĐẦU TIÊN cùng nhau làm chuẩn | | | ⚠ 3. Chia nhóm nhỏ, mỗi nhóm phân loại một phần hạng mục vào thùng | ⚠ chạy SONG SONG — đây là chỗ tiết kiệm thời gian | | ⚠ 4. Cả nhóm cùng RÀ SOÁT lại kết quả | ⚠ giữ được sự đồng thuận | | ⚠ 5. Hiệu chỉnh những hạng mục còn tranh cãi | | | ⚠ Vì sao nhanh | ⚠ không thảo luận từng hạng mục — chỉ thảo luận những chỗ có bất đồng thật |

⚠ Vì sao planning poker không hợp ở đây Lý do
⚠ Mỗi hạng mục cần một vòng giơ bài và thảo luận ⚠ với hàng trăm hạng mục thì mất nhiều ngày
⚠ Đội càng lớn thì mỗi vòng càng lâu ⚠ liên hệ #26070 lô 186 — kênh giao tiếp tăng theo bình phương
⚠ Người ta mất tập trung sau một hai giờ ⚠ và đề nói rõ có hộp thời gian
⚠ Khi nào planning poker vẫn tốt nhất ⚠ đội 5–9 người, ước lượng vài chục hạng mục cho sprint tới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi ước lượng của đội bạn kéo dài bao lâu | ⚠ quá hai giờ là chất lượng ước lượng bắt đầu giảm | | Số hạng mục cần ước lượng là bao nhiêu | ⚠ quyết định kỹ thuật nào phù hợp | | Ước lượng của bạn có do chính đội làm không | ⚠ liên hệ #25993 lô 185 |

Và nguyên tắc chọn kỹ thuật ước lượng, dù bộ đề có bao nhiêu tên gọi đi nữa: độ chính xác cần có phải tương xứng với quyết định sẽ dựa vào nó — ước lượng backlog dài hạn không cần chính xác bằng ước lượng cho sprint tuần sau.

Câu 383 Process
Harry and Ron work on a project together. Harry is assigned as the project manager, and Ron is designated as a project coordinator that can help support his efforts. One day, after the project status update meeting, a stakeholder contacts Ron to talk about an additional scope they would like added to the project. Ron informs the stakeholder to submit the details in writing. What would be Ron's next best choice in how to respond to the stakeholder?
  1. A Make sure the stakeholder understands the impact of the change.
  2. B Find the root cause of why the scope was not identified during project planning.
  3. C Ask the stakeholder if any more changes are expected.
  4. D Perform integrated change control.
Xem giải thích

Đáp án

D — THỰC HIỆN KIỂM SOÁT THAY ĐỔI TÍCH HỢP.

Vì sao đúng

⚠ Trình tự Ron đang đi: | Bước | Nội dung | |---|---| | ⚠ 1. Bên liên quan đề xuất thêm phạm vi | ⚠ đã xảy ra | | ⚠ 2. Ron yêu cầu nộp CHI TIẾT BẰNG VĂN BẢN | ⚠ đã làm — bước đúng, liên hệ #26048 lô 186 | | ⚠ 3. Đưa qua KIỂM SOÁT THAY ĐỔI TÍCH HỢP | ⚠ BƯỚC TIẾP THEO — CÂU NÀY | | ⚠ 4. Phân tích tác động lên mọi lĩnh vực | ⚠ nằm TRONG quy trình này — liên hệ #26052 lô 186 | | ⚠ 5. CCB hoặc nhà tài trợ quyết | | | ⚠ Vì sao là bước tiếp theo | ⚠ có văn bản rồi thì đưa vào quy trình chính thức — mọi việc khác đều là một phần của quy trình đó |

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

  • A (bảo đảm bên liên quan hiểu tác động của thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì đó là việc rất nên làm: ⚠ nhưng ⚠ chưa PHÂN TÍCH thì chưa BIẾT tác động là gì để mà giải thích; ⚠ nó là bước SAU khi quy trình cho ra kết quả.

  • C (hỏi bên liên quan còn thay đổi nào nữa không) — ⚠ có ích để lập kế hoạch, ⚠ nhưng không phải bước tiếp theo của yêu cầu ĐANG có.

  • B (tìm nguyên nhân gốc vì sao phạm vi này không được nhận diện khi lập kế hoạch) — ⚠ là BÀI HỌC KINH NGHIỆM đáng ghi, ⚠ nhưng ⚠ không giải quyết yêu cầu trước mắt; ⚠ và nhiều thay đổi phát sinh hoàn toàn chính đáng, không phải do lập kế hoạch kém.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26068 ở lô 186 (Joachim và Kelly — cùng cặp nhân vật quản lý dự án và điều phối viên), câu #25978 lô 184 (xin dời mốc → thu thập dữ liệu tác động), câu #26048 lô 186 (luật mới → lập yêu cầu thay đổi bằng văn bản), và câu #26101 ở lô này (thêm kiểm thử → kiểm soát thay đổi tích hợp). ⚠ Nhóm kiểm soát thay đổi — nay là câu thứ MƯỜI HAI.

⚠ Bảy bước của kiểm soát thay đổi tích hợp: | Bước | Nội dung | |---|---| | ⚠ 1. TIẾP NHẬN yêu cầu bằng văn bản | ⚠ Ron đã làm | | ⚠ 2. GHI vào nhật ký thay đổi | ⚠ liên hệ #25956 lô 184 | | ⚠ 3. PHÂN TÍCH TÁC ĐỘNG lên bảy lĩnh vực | ⚠ liên hệ #26052 lô 186 | | ⚠ 4. Trình người có THẨM QUYỀN | ⚠ CCB hoặc nhà tài trợ | | ⚠ 5. QUYẾT ĐỊNH: duyệt / từ chối / hoãn | | | ⚠ 6. Cập nhật kế hoạch và ĐƯỜNG CƠ SỞ nếu duyệt | | | ⚠ 7. THÔNG BÁO cho người đề xuất và các bên | ⚠ phương án A thuộc bước này | | ⚠ Cả bảy bước | ⚠ gộp lại chính là "thực hiện kiểm soát thay đổi tích hợp" — đó là lý do đáp án D bao trùm |

Từ khoá nhận diện:

"đã có yêu cầu bằng văn bản, bước tiếp theo là gì" → ⚠ đưa vào kiểm soát thay đổi tích hợp "giải thích tác động cho bên liên quan" → ⚠ sau khi đã phân tích "tìm nguyên nhân vì sao bỏ sót" → ⚠ bài học kinh nghiệm, không phải bước xử lý "hỏi còn thay đổi nào nữa không" → ⚠ hữu ích nhưng không phải bước tiếp theo

⚠ Ron làm ĐÚNG những gì Điểm tốt
⚠ Không từ chối, không hứa suông
⚠ Yêu cầu nộp BẰNG VĂN BẢN ngay ⚠ tạo dấu vết và khởi động quy trình
⚠ Không tự quyết dù là điều phối viên ⚠ đúng thẩm quyền của vai trò
⚠ Vai trò điều phối viên dự án ⚠ có chút quyền ra quyết định, nhưng KHÔNG duyệt thay đổi phạm vi — liên hệ #26088 cùng lô
⚠ Ron nên báo ai ⚠ HARRY — quản lý dự án; anh là người đưa yêu cầu vào quy trình chính thức
⚠ Vì sao phải bằng VĂN BẢN Lý do
⚠ Tạo dấu vết ai đề xuất, khi nào, nội dung gì
⚠ Buộc người đề xuất phải NGHĨ KỸ ⚠ nhiều yêu cầu tự biến mất ở bước này
⚠ Tránh hiểu nhầm về phạm vi yêu cầu
⚠ Là căn cứ khi có tranh chấp về sau
⚠ Điều cần cân bằng ⚠ form phải DỄ ĐIỀN — quá phiền thì người ta sẽ đi đường vòng (liên hệ #26066 lô 186 — trường hợp Scotty)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu thay đổi ở dự án bạn mất bao lâu để xử lý | | | Có ai trong đội tự nhận thay đổi mà không qua quy trình không | | | Người đề xuất có được thông báo kết quả không | ⚠ bước bảy — hay bị bỏ nhất |

Và điều Ron thể hiện qua một câu trả lời ngắn với bên liên quan: anh không nói có, không nói không, mà nói "hãy viết ra" — câu trả lời duy nhất vừa tôn trọng người đề xuất vừa bảo vệ được dự án.

Câu 384 People
Rachel is the scrum master for Project Q, which is in its ninth iteration and has a velocity of 96 story points. During a recent sprint, Rachel noticed several team members had not updated their task statuses on time. What should Rachel do?
  1. A Escalate the issue to the product owner.
  2. B Privately remind those who did not update their tasks to do so.
  3. C Do nothing. The team is responsible for updating their tasks and will hold each other accountable.
  4. D Remind the entire team to update their tasks.
Xem giải thích

Đáp án

B — NHẮC RIÊNG những người CHƯA cập nhật để họ cập nhật.

Vì sao đúng

⚠ Vì sao nhắc riêng đúng người là cách đúng: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề chỉ ở VÀI THÀNH VIÊN, không phải cả đội | ⚠ nhắc cả đội là phạt người làm đúng | | ⚠ RIÊNG TƯ giữ được thể diện | ⚠ nhắc công khai dễ thành bêu riếu | | ⚠ Có cơ hội hỏi VÌ SAO họ chưa cập nhật | ⚠ có thể có lý do thật: công cụ khó dùng, không rõ quy ước, quá bận | | ⚠ Tương xứng với mức nghiêm trọng của vấn đề | ⚠ đây là việc nhỏ, không cần biện pháp lớn | | ⚠ Nguyên tắc chung | ⚠ khen công khai, góp ý riêng tư |

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

  • D (nhắc CẢ ĐỘI cập nhật công việc) — ⚠ phương án gây nhiễu mạnh nhất vì nghe công bằng và không chỉ trích ai: ⚠ nhưng nó ⚠ PHẠT NHỮNG NGƯỜI ĐÃ LÀM ĐÚNG ⚠ bằng cách bắt họ nghe nhắc nhở không dành cho mình, ⚠ và ⚠ người vi phạm dễ nghĩ "chắc không phải nói mình"; ⚠ nhắc chung là cách né việc nói chuyện thẳng.

  • C (không làm gì, đội tự chịu trách nhiệm với nhau) — ⚠ lý tưởng nhưng bỏ mặc; ⚠ Rachel đã BIẾT có vấn đề, ⚠ và tự chịu trách nhiệm lẫn nhau là thứ cần được NUÔI DƯỠNG, không tự có.

  • A (leo thang lên product owner) — ⚠ leo thang quá mức cho một việc rất nhỏ, ⚠ và PO không quản lý cách đội làm việc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25939 ở lô 184 (thành viên liên tục lệch chuẩn chất lượng → hành động khắc phục, không kỷ luật ngay), câu #26019 lô 185 (lập trình viên trẻ chật vật → ghép cặp), câu #25968 lô 184 (người ngại nói trong retrospective), và câu #26025 lô 185 (bên liên quan nói quá nhiều). ⚠ Cả nhóm cùng một nguyên tắc: xử lý ĐÚNG NGƯỜI, ĐÚNG MỨC, và RIÊNG TƯ trước.

⚠ NGUYÊN TẮC TƯƠNG XỨNG trong xử lý vấn đề con người: | Mức vấn đề | Cách xử lý | |---|---| | ⚠ Sơ suất lần đầu, việc nhỏ | ⚠ nhắc riêng, nhẹ nhàng — CÂU NÀY | | ⚠ Lặp lại nhiều lần | ⚠ trao đổi riêng sâu hơn, tìm nguyên nhân | | ⚠ Vấn đề hệ thống, nhiều người cùng mắc | ⚠ đưa ra retrospective để cả đội bàn | | ⚠ Ảnh hưởng nghiêm trọng tới dự án | ⚠ hành động khắc phục chính thức — liên hệ #25939 lô 184 | | ⚠ Vi phạm đạo đức hoặc quy định | ⚠ leo thang lên nhân sự hoặc lãnh đạo | | ⚠ Sai lầm hai đầu | ⚠ phản ứng quá nhẹ thì vấn đề lặp lại; quá nặng thì mất lòng tin và người ta giấu vấn đề |

Từ khoá nhận diện:

"vài người chưa làm" → ⚠ nhắc riêng chính những người đó "nhắc cả đội" → ⚠ phạt người làm đúng, né việc nói thẳng "không làm gì, đội tự lo" → ⚠ bỏ mặc khi mình đã biết "leo thang" → ⚠ quá mức cho một việc nhỏ

⚠ Rachel nên hỏi gì khi nhắc riêng Câu hỏi
⚠ "Có gì khiến việc cập nhật khó không?" ⚠ mở đường cho họ nói lý do thật
⚠ Công cụ có khó dùng không ⚠ rất thường là nguyên nhân
⚠ Có rõ quy ước cập nhật khi nào không ⚠ có thể chưa ai nói rõ
⚠ Có đang quá tải không
⚠ Điều KHÔNG nên hỏi ⚠ "vì sao anh không làm?" — câu hỏi này chỉ nhận về lời bào chữa
⚠ Vì sao cập nhật trạng thái lại quan trọng Lý do
⚠ Bảng công việc là NGUỒN SỰ THẬT DUY NHẤT của đội
⚠ Không cập nhật thì burndown và burnup sai ⚠ liên hệ #26094 cùng lô
⚠ Người khác không biết việc nào đã có người nhận ⚠ dẫn tới làm trùng hoặc bỏ sót
⚠ Daily standup mất hiệu quả
⚠ Nhưng cũng nên hỏi ngược lại ⚠ nếu nhiều người quên, có thể quy trình cập nhật đang quá phiền — và đó là vấn đề để đưa ra retrospective

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng công việc của đội bạn có phản ánh đúng thực tế không | | | Cập nhật trạng thái mất bao nhiêu thời gian mỗi ngày | ⚠ quá một phút là quá nhiều | | Bạn có xu hướng nhắc chung thay vì nói riêng không | |

Và lý do "nhắc cả đội" là lựa chọn hấp dẫn mà sai: nó cho phép người quản lý cảm thấy mình đã xử lý vấn đề, mà không phải có cuộc trò chuyện khó khăn với người thật sự cần nghe.

Câu 385 Process
Anthony is working on a 3D printing project to develop innovative new building models for clients to view in real-time. However, Anthony has had issues scheduling times to create models based on the 3D printer's resource overallocation for other projects. The other projects require the printers to be used to create visual landscapes for those same buildings. Which of the following actions can Anthony take to utilize the 3D printers better?
  1. A Request the purchase of another 3D printer.
  2. B Identify the critical path for all consolidated projects.
  3. C Work with other project managers to manage the 3D printers for the visual landscape jobs.
  4. D Develop a business proposal to show upper-level management why Anthony's project is more valuable for the company.
Xem giải thích

Đáp án

C — LÀM VIỆC VỚI CÁC QUẢN LÝ DỰ ÁN KHÁC để cùng điều phối việc dùng máy in 3D.

Vì sao đúng

⚠ Vì sao phối hợp là cách đúng: | Lý do | Nội dung | |---|---| | ⚠ Đây là vấn đề NGUỒN LỰC DÙNG CHUNG giữa nhiều dự án | ⚠ liên hệ #25935 lô 184 — hai PM tranh nhau một người | | ⚠ Các dự án kia làm việc LIÊN QUAN — cảnh quan cho CÙNG những toà nhà đó | ⚠ chi tiết quan trọng: họ có mục tiêu chung, không phải đối thủ | | ⚠ Phối hợp lịch có thể giải quyết mà KHÔNG tốn thêm tiền | | | ⚠ Thử ở MỨC THẤP NHẤT trước khi leo thang | ⚠ liên hệ #26008 lô 185 | | ⚠ Kết quả có thể đạt được | ⚠ xếp lịch in xen kẽ, gộp các lần in cùng toà nhà, chia ca sử dụng |

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

  • A (đề nghị mua thêm một máy in 3D) — ⚠ phương án gây nhiễu mạnh nhất vì nó giải quyết triệt để vấn đề: ⚠ nhưng ⚠ tốn tiền và chưa thử cách miễn phí nào; ⚠ và cần phân tích make-or-buy đầy đủ trước (liên hệ #26100 cùng lô).

  • D (làm đề xuất kinh doanh chứng minh dự án của Anthony giá trị hơn) — ⚠ biến đồng nghiệp thành đối thủ; ⚠ thắng cuộc này thì thua quan hệ cho mọi lần sau.

  • B (xác định đường găng cho tất cả các dự án hợp nhất) — ⚠ hữu ích để phân tích, ⚠ nhưng ⚠ Anthony KHÔNG có thẩm quyền làm việc đó cho dự án của người khác; ⚠ đó là việc của PMO hoặc quản lý chương trình.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25935 ở lô 184 (hai PM cùng cần Juan toàn thời gian → ràng buộc nguồn lực), câu #26015 lô 185 (đội khác xin mượn người → hai Scrum Master thương lượng), câu #26008 (bên liên quan không nhả nguồn lực), và câu #26050 lô 186 (thương lượng là bước đầu tiên). ⚠ Nhóm tranh chấp nguồn lực — bốn câu, cùng một nguyên tắc: THƯƠNG LƯỢNG TRƯỚC.

⚠ Thang xử lý tranh chấp nguồn lực: | Mức | Cách làm | |---|---| | ⚠ 1. Phối hợp trực tiếp giữa các PM | ⚠ CÂU NÀY — rẻ nhất, nhanh nhất, giữ quan hệ | | ⚠ 2. San bằng hoặc làm phẳng nguồn lực trong lịch của mình | ⚠ liên hệ #25935 lô 184 | | ⚠ 3. Đưa lên PMO hoặc quản lý chương trình | ⚠ họ có tầm nhìn toàn danh mục | | ⚠ 4. Leo thang lên nhà tài trợ | ⚠ liên hệ #25906 lô 183 | | ⚠ 5. Đề xuất mua thêm nguồn lực | ⚠ tốn tiền, nên là lựa chọn sau cùng | | ⚠ Sai lầm phổ biến | ⚠ nhảy thẳng lên mức 4 hoặc 5 mà chưa thử mức 1 |

Từ khoá nhận diện:

"nguồn lực dùng chung giữa các dự án" → ⚠ phối hợp giữa các PM trước "mua thêm" → ⚠ tốn tiền, lựa chọn sau cùng "chứng minh dự án tôi quan trọng hơn" → ⚠ biến đồng nghiệp thành đối thủ "phân tích đường găng của dự án người khác" → ⚠ vượt thẩm quyền của một PM

⚠ Vì sao chi tiết "cùng những toà nhà đó" lại quan trọng Ý nghĩa
⚠ Các dự án phục vụ CÙNG một khách hàng cuối
⚠ Có thể GỘP các lần in lại ⚠ in mô hình toà nhà và cảnh quan cùng lúc
⚠ Tổ chức có lợi khi cả hai dự án cùng thành công ⚠ không phải trò chơi tổng bằng không
⚠ Cơ hội bị bỏ lỡ nếu cạnh tranh ⚠ hai dự án lẽ ra nên là CHƯƠNG TRÌNH được quản lý phối hợp — liên hệ #25995 lô 185
⚠ Gợi ý cho tổ chức ⚠ nếu tình huống này lặp lại, đó là dấu hiệu cần quản lý ở tầng DANH MỤC hoặc CHƯƠNG TRÌNH
⚠ Anthony nên chuẩn bị gì cho cuộc trao đổi Chuẩn bị
⚠ Lịch cần dùng máy in CỤ THỂ của mình ⚠ ngày nào, mấy giờ, bao lâu
⚠ Mức linh hoạt của mình ⚠ có việc nào dời được không
⚠ Hiểu nhu cầu của bên kia trước khi đề xuất ⚠ liên hệ #26009 lô 185 — thương lượng dựa trên lợi ích
⚠ Vài phương án để cùng chọn
⚠ Kết thúc bằng ⚠ một LỊCH DÙNG CHUNG được ghi lại, không phải một thoả thuận miệng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn dùng chung nguồn lực nào với dự án khác | | | Có lịch dùng chung được ghi lại không | | | Bạn có biết nhu cầu của các dự án kia không | ⚠ hay chỉ biết nhu cầu của mình |

Và điều Anthony có thể nhận ra khi ngồi xuống với đồng nghiệp: hai dự án đang tranh nhau một cái máy hoá ra đang làm cho cùng một khách hàng — và cách nhìn đó thường mở ra những giải pháp mà cuộc cạnh tranh không bao giờ tìm thấy.

Câu 386 People
Judy's project coach has met with everyone on their team one-on-one about their upcoming project. Judy has just learned that her mother has a few medical issues that will take her away from her team occasionally. Judy explained her concerns to her coach and explained that it is important for her to have a good life balance. Her coach should
  1. A Encourage her to share whatever information she is comfortable with, so the team can support her when she is occasionally out.
  2. B Tell Judy to keep this to herself, as it is inappropriate to mention in the workplace.
  3. C None of the above.
  4. D Ask that she work additional hours to cover any unplanned time that she is out.
Xem giải thích

Đáp án

A — KHUYẾN KHÍCH Judy chia sẻ những thông tin cô thấy THOẢI MÁI, để đội có thể HỖ TRỢ khi cô thỉnh thoảng vắng mặt.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ TÔN TRỌNG quyền riêng tư — chỉ chia sẻ mức cô thấy thoải mái | ⚠ cô quyết định, không phải huấn luyện viên | | ⚠ Cho phép đội LẬP KẾ HOẠCH quanh việc cô vắng mặt | ⚠ thực tế và có ích cho công việc | | ⚠ Xây dựng AN TOÀN TÂM LÝ | ⚠ liên hệ #25992 lô 185 | | ⚠ Ghi nhận mối quan tâm của cô về CÂN BẰNG CUỘC SỐNG | ⚠ nhịp độ bền vững là nguyên tắc agile | | ⚠ Cân bằng đúng | ⚠ giữa quyền riêng tư của cá nhân và nhu cầu lập kế hoạch của đội |

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

  • B (bảo Judy giữ chuyện này cho riêng mình vì không nên nhắc ở nơi làm việc) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như đang bảo vệ ranh giới nghề nghiệp: ⚠ nhưng nó ⚠ PHÁ HUỶ AN TOÀN TÂM LÝ ⚠ — Judy đã chủ động chia sẻ và tin tưởng, ⚠ và đội cần biết ở mức nào đó để hỗ trợ và lập kế hoạch.

  • D (yêu cầu cô làm thêm giờ để bù thời gian vắng ngoài kế hoạch) — ⚠ trái nguyên tắc NHỊP ĐỘ BỀN VỮNG, ⚠ và ⚠ thiếu nhân văn với người đang chăm sóc gia đình.

  • C (không phương án nào) — ⚠ sai vì A đúng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25992 ở lô 185 (môi trường an toàn để bất đồng), câu #25998 (mục tiêu cá nhân vẫn quan trọng), câu #25952 lô 184 (Carol thể hiện lãnh đạo phục vụ), và câu #26106 ở lô này (nhắc riêng thay vì nhắc cả đội). ⚠ Nhóm lãnh đạo con người.

⚠ Cân bằng giữa RIÊNG TƯ và NHU CẦU của đội: | Nguyên tắc | Nội dung | |---|---| | ⚠ CHI TIẾT Y TẾ là quyền riêng tư TUYỆT ĐỐI | ⚠ không ai được ép chia sẻ, và ở nhiều nơi còn là quy định pháp luật | | ⚠ THỜI GIAN VẮNG MẶT là thông tin đội cần | ⚠ để lập kế hoạch sprint | | ⚠ Người đó tự quyết chia sẻ tới đâu | ⚠ "tôi sẽ vắng một số buổi sáng" là đủ, không cần lý do | | ⚠ Huấn luyện viên tạo điều kiện, không ép buộc | | | ⚠ Câu nói đúng | ⚠ "em chia sẻ tới đâu thấy thoải mái thì tới đó — đội chỉ cần biết lịch để sắp xếp" |

Từ khoá nhận diện:

"chia sẻ ở mức thấy thoải mái" → ⚠ tôn trọng quyền riêng tư và vẫn giúp đội lập kế hoạch "giữ cho riêng mình, không nên nhắc" → ⚠ phá huỷ an toàn tâm lý "làm bù thêm giờ" → ⚠ trái nhịp độ bền vững "cân bằng cuộc sống" → ⚠ giá trị được agile công nhận, không phải yêu sách

⚠ Đội có thể hỗ trợ Judy thế nào Cách
⚠ Không giao cho cô việc là NÚT THẮT DUY NHẤT ⚠ liên hệ #25928 lô 183 — chuyên gia đa năng
⚠ Ghép cặp để có người thứ hai nắm việc ⚠ liên hệ #26019 lô 185
⚠ Tính sức chứa sprint có trừ thời gian vắng dự kiến
⚠ Linh hoạt về giờ giấc nếu công việc cho phép
⚠ Ghi lại quyết định để cô không bị lỡ khi vắng ⚠ liên hệ #26061 lô 186 — người vắng bỏ lỡ giao tiếp thẩm thấu
⚠ Điều KHÔNG nên ⚠ âm thầm giảm việc quan trọng của cô — đó là loại trừ, không phải hỗ trợ
⚠ NHỊP ĐỘ BỀN VỮNG — nguyên tắc agile số 8 Nội dung
⚠ Các bên phải duy trì được nhịp làm việc VÔ THỜI HẠN
⚠ Làm thêm giờ liên tục làm giảm năng suất và tăng lỗi
⚠ Đội kiệt sức là rủi ro dự án, không chỉ là vấn đề nhân sự
⚠ Vì sao phương án D đặc biệt sai ⚠ nó biến một tình huống cần cảm thông thành một khoản nợ phải trả bằng sức khoẻ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai là điểm phụ thuộc duy nhất cho một việc không | | | Sức chứa sprint có trừ nghỉ phép và vắng mặt dự kiến không | ⚠ rất nhiều đội quên bước này | | Người trong đội có dám nói về vấn đề cá nhân không | ⚠ thước đo an toàn tâm lý |

Và điều huấn luyện viên của Judy thật sự làm khi trả lời đúng cách: anh cho cô biết rằng việc nói ra không khiến cô trở thành gánh nặng — và đó là điều duy nhất cô cần nghe ở thời điểm này.

Câu 387 People
Wayne's company has asked him about the resources for his upcoming agile project. They suggest that he use several team members, including some members in his building, others in another building in a nearby state, and a team that includes offshore team members and locals. What is Wayne's ideal resource team if the skills are roughly equivalent in all locations?
  1. A Wayne would choose the offshore team members because they would have more flexibility in their schedule to work virtually.
  2. B Wayne would choose a team in his building and move them to the same space.
  3. C Wayne would choose the team in his building and those located nearby since they have the same schedule but would be required to set up video conferencing.
  4. D Wayne would choose a team in his building and do daily standups together in the same room.
Xem giải thích

Đáp án

B — Chọn đội TRONG CÙNG TOÀ NHÀ và ĐƯA HỌ VỀ CÙNG MỘT KHÔNG GIAN.

Vì sao đúng

⚠ Vì sao đây là lựa chọn tối ưu: | Lý do | Nội dung | |---|---| | ⚠ Đề nói rõ KỸ NĂNG NGANG NHAU ở mọi nơi | ⚠ nên yếu tố quyết định duy nhất còn lại là VỊ TRÍ | | ⚠ Ngồi chung là bố trí TỐI ƯU cho đội agile | ⚠ liên hệ #25885 lô 183 | | ⚠ Có GIAO TIẾP THẨM THẤU | ⚠ liên hệ #26061 lô 186 — Bruno học được nhờ nghe lỏm | | ⚠ Vòng phản hồi ngắn nhất, không lệch múi giờ | ⚠ liên hệ #26064 lô 186 | | ⚠ Không cần đầu tư bù đắp cho khoảng cách | | | ⚠ Điểm mấu chốt của phương án B | ⚠ không chỉ chọn người cùng toà nhà mà còn ĐƯA HỌ VỀ CÙNG MỘT KHÔNG GIAN — cùng toà nhà mà khác tầng vẫn chưa phải ngồi chung |

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

  • D (chọn đội trong toà nhà và họp đứng hằng ngày cùng một phòng) — ⚠ phương án gây nhiễu mạnh nhất vì rất gần với đáp án: ⚠ nhưng nó ⚠ chỉ gộp họ 15 PHÚT MỖI NGÀY ⚠ — ⚠ phần lớn lợi ích của việc ngồi chung đến từ 7 giờ 45 phút CÒN LẠI, ⚠ khi người ta nghe được nhau, hỏi nhau ngay, và vẽ chung lên bảng.

  • C (đội trong toà nhà và những người ở gần, dùng hội nghị truyền hình) — ⚠ vẫn là đội phân tán, ⚠ chấp nhận mất mát khi không cần thiết.

  • A (chọn đội ở nước ngoài vì họ linh hoạt hơn khi làm việc từ xa) — ⚠ giả định không có căn cứ, ⚠ và chọn phương án kém tối ưu nhất khi có lựa chọn tốt hơn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26082 ở lô 186 (đội phân tán VẪN thành công được nhờ vòng lặp ngắn) — ⚠ hai câu bổ sung nhau, KHÔNG mâu thuẫn: ⚠ #26082 nói khi BUỘC PHẢI làm việc phân tán thì vẫn thành công được; câu này nói khi CÓ LỰA CHỌN thì ngồi chung là tối ưu. ⚠ Xem thêm câu #25885 lô 183, câu #26059 lô 186 (đội ngồi chung loại bỏ lãng phí), và câu #26061 (giao tiếp thẩm thấu).

⚠ Thang bố trí đội — từ tốt nhất tới kém nhất: | Mức | Bố trí | |---|---| | ⚠ 1 | ⚠ NGỒI CHUNG một không gian — CÂU NÀY | | ⚠ 2 | ⚠ cùng toà nhà, khác phòng | | ⚠ 3 | ⚠ cùng thành phố, cùng múi giờ | | ⚠ 4 | ⚠ khác múi giờ nhưng còn giờ làm việc chồng lấn | | ⚠ 5 | ⚠ không có giờ làm việc chồng lấn | | ⚠ Nguyên tắc | ⚠ mỗi bậc xuống là mất thêm một phần giao tiếp — và phải BÙ ĐẮP bằng công cụ và kỷ luật | | ⚠ Nhưng nhớ | ⚠ bậc thấp KHÔNG có nghĩa là thất bại — chỉ là tốn công hơn (liên hệ #26082 lô 186) |

Từ khoá nhận diện:

"kỹ năng ngang nhau, có lựa chọn" → ⚠ chọn ngồi chung "chỉ họp standup cùng phòng" → ⚠ chưa phải ngồi chung "đội phân tán buộc phải chấp nhận" → ⚠ vẫn thành công được, nhưng cần đầu tư bù "cùng toà nhà" → ⚠ chưa đủ — phải cùng KHÔNG GIAN LÀM VIỆC

⚠ Vì sao 15 phút standup chung không thay được cả ngày ngồi chung Lý do
⚠ Câu hỏi nảy ra lúc 10 giờ sáng không đợi được tới hôm sau
⚠ Không nghe được cuộc trao đổi của người khác ⚠ mất thẩm thấu — liên hệ #26061 lô 186
⚠ Không dùng chung được bảng vẽ, không quay sang hỏi ngay được
⚠ Không xây được quan hệ qua những tương tác nhỏ hằng ngày
⚠ Con số đáng nhớ ⚠ standup chiếm khoảng 3% thời gian làm việc — 97% còn lại mới là nơi lợi ích của ngồi chung xuất hiện
⚠ Nếu tổ chức KHÔNG cho ngồi chung thì sao Cách
⚠ Trình bày lợi ích bằng số liệu, không bằng lý thuyết
⚠ Xin thử nghiệm trong một sprint
⚠ Nếu vẫn không được, đầu tư mạnh vào công cụ bù đắp ⚠ liên hệ #26082 lô 186 — danh sách cách bù
⚠ Điều KHÔNG nên ⚠ chấp nhận đội phân tán mà không làm gì để bù, rồi ngạc nhiên khi giao tiếp trục trặc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ngồi cùng một chỗ không | ⚠ hay chỉ cùng toà nhà | | Nếu phân tán, bạn đã bù đắp những gì | | | Khi có lựa chọn, tổ chức bạn ưu tiên gì | ⚠ thường là tiết kiệm chi phí văn phòng, mà không tính chi phí giao tiếp |

Và điều Wayne cần trình bày với công ty: khi kỹ năng ngang nhau ở mọi nơi, chọn đội ngồi chung không phải là sở thích cá nhân — đó là lựa chọn duy nhất không phải trả thêm chi phí phối hợp trong suốt dự án.

Câu 388 Process
You have tasked Kathy with creating a requirements management plan for your project. After a week, Kathy submits a draft of the requirements management plan for your review. While reading through the draft, you notice one of the components listed does not belong in the plan. Which of the following components does not belong in the plan?
  1. A The metrics that will be used and the rationale for their use
  2. B Traceability structure that reflects the requirement attributes captured on the traceability matrix.
  3. C A process that specifies how formal acceptance of the completed project deliverables will be obtained.
  4. D How requirements activities will be planned, tracked, and reported.
Xem giải thích

Đáp án

C — QUY TRÌNH XÁC ĐỊNH CÁCH ĐẠT ĐƯỢC NGHIỆM THU CHÍNH THỨC cho các bàn giao đã hoàn thành (thành phần này KHÔNG thuộc kế hoạch quản lý yêu cầu).

Vì sao đúng

⚠ Vì sao thành phần này thuộc chỗ khác: | Lý do | Nội dung | |---|---| | ⚠ Nghiệm thu chính thức bàn giao thuộc quy trình XÁC NHẬN PHẠM VI | | | ⚠ Nó được mô tả trong KẾ HOẠCH QUẢN LÝ PHẠM VI | ⚠ không phải kế hoạch quản lý yêu cầu | | ⚠ Kế hoạch quản lý YÊU CẦU nói về VÒNG ĐỜI CỦA YÊU CẦU | ⚠ thu thập, phân tích, ghi nhận, truy xuất, thay đổi | | ⚠ Ba thành phần còn lại đều đúng là của kế hoạch yêu cầu | | | ⚠ Ranh giới | ⚠ yêu cầu là ĐẦU VÀO; nghiệm thu bàn giao là ĐẦU RA ở cuối chuỗi |

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

  • B (cấu trúc truy xuất phản ánh các thuộc tính yêu cầu trên ma trận truy xuất) — ⚠ phương án gây nhiễu mạnh nhất vì câu chữ dài và kỹ thuật: ⚠ nhưng ⚠ MA TRẬN TRUY XUẤT YÊU CẦU là công cụ trung tâm của kế hoạch này ⚠ (liên hệ #25981 lô 184) — ⚠ hoàn toàn thuộc về nó.

  • A (các chỉ số sẽ dùng và lý do dùng chúng) — ⚠ thuộc kế hoạch yêu cầu: ⚠ đo lường yêu cầu thế nào.

  • D (cách các hoạt động về yêu cầu sẽ được lập kế hoạch, theo dõi và báo cáo) — ⚠ định nghĩa gần như nguyên văn của kế hoạch quản lý yêu cầu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25981 ở lô 184 (kế hoạch nào mô tả cách phân tích, ghi nhận và quản lý yêu cầu → kế hoạch quản lý yêu cầu) — ⚠ hai câu về cùng một tài liệu: câu đó hỏi NÓ LÀ GÌ, câu này hỏi NÓ KHÔNG CHỨA GÌ. ⚠ Xem thêm câu #26072 lô 186 (sổ đăng ký rủi ro không thuộc kế hoạch quản lý rủi ro) — ⚠ cùng một dạng câu hỏi, cùng một mẹo làm bài.

⚠ KẾ HOẠCH QUẢN LÝ YÊU CẦU chứa gì: | Thành phần | Nội dung | |---|---| | ⚠ Cách THU THẬP yêu cầu | ⚠ phỏng vấn, hội thảo, khảo sát, nguyên mẫu | | ⚠ Cách PHÂN TÍCH và ưu tiên yêu cầu | | | ⚠ Cách GHI NHẬN và lưu trữ | | | ⚠ Cách THEO DÕI, BÁO CÁO hoạt động về yêu cầu | ⚠ phương án D | | ⚠ Cấu trúc MA TRẬN TRUY XUẤT | ⚠ phương án B | | ⚠ CHỈ SỐ đo lường và lý do dùng | ⚠ phương án A | | ⚠ Quy trình QUẢN LÝ THAY ĐỔI yêu cầu | | | ⚠ Cấu trúc phân rã sản phẩm | | | ⚠ KHÔNG chứa | ⚠ quy trình nghiệm thu bàn giao — thuộc kế hoạch quản lý PHẠM VI |

⚠ Mẹo làm bài chung cho dạng câu "thành phần nào KHÔNG thuộc kế hoạch X": | Bước | Nội dung | |---|---| | ⚠ 1. Xác định kế hoạch X nói về CÁI GÌ | ⚠ yêu cầu, rủi ro, phạm vi, giao tiếp | | ⚠ 2. Loại phương án nào nói về LĨNH VỰC KHÁC | | | ⚠ 3. Cẩn thận với phương án chứa DANH SÁCH DỮ LIỆU cụ thể | ⚠ sổ đăng ký, nhật ký — chúng là tài liệu RIÊNG, không nằm trong kế hoạch (liên hệ #26072 lô 186) | | ⚠ Quy tắc bao trùm | ⚠ "KẾ HOẠCH quản lý X" mô tả CÁCH LÀM; dữ liệu cụ thể luôn nằm ở tài liệu khác |

Từ khoá nhận diện:

"thu thập, phân tích, truy xuất, thay đổi YÊU CẦU" → ⚠ kế hoạch quản lý yêu cầu "nghiệm thu bàn giao, xác nhận phạm vi" → ⚠ kế hoạch quản lý phạm vi "ma trận truy xuất" → ⚠ thuộc kế hoạch yêu cầu ⚠ Câu có chữ "KHÔNG" → ⚠ tìm thành phần thuộc LĨNH VỰC KHÁC

⚠ Phân biệt hai kế hoạch anh em Phân biệt
⚠ KẾ HOẠCH QUẢN LÝ YÊU CẦU ⚠ yêu cầu được thu thập, phân tích, truy xuất và thay đổi ra sao
⚠ KẾ HOẠCH QUẢN LÝ PHẠM VI ⚠ phạm vi được xác định, chia nhỏ (WBS), XÁC NHẬN và kiểm soát ra sao
⚠ Chỗ dễ nhầm ⚠ cả hai đều liên quan tới "khách hàng muốn gì" — nhưng một cái quản YÊU CẦU, một cái quản CÔNG VIỆC và NGHIỆM THU
⚠ Liên hệ ⚠ #25981 lô 184 đã có bảng phân biệt bốn kế hoạch phụ hay lẫn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có kế hoạch quản lý yêu cầu riêng không | ⚠ hay gộp vào kế hoạch phạm vi | | Ma trận truy xuất của bạn có nối yêu cầu với mục tiêu kinh doanh không | | | Quy trình nghiệm thu bàn giao được ghi ở đâu | |

Và cách kiểm tra nhanh mọi câu hỏi dạng này: hỏi xem thành phần đó nói về VÒNG ĐỜI CỦA YÊU CẦU hay nói về việc GIAO SẢN PHẨM — hai chuyện đó nằm ở hai tài liệu khác nhau.

Câu 389 Business Environment
Brittany is an IT project manager at a company. Brittany has witnessed the roll-out of innovative new software that can potentially increase network speeds at her company. However, she realizes this will be a significant undertaking as many of her co-workers are opposed to trying out new services. Which PESTLE factor best describes the situation above?
  1. A Environmental
  2. B Political
  3. C Technical
  4. D Legal
Xem giải thích

Đáp án

C — KỸ THUẬT (Technical).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ PHẦN MỀM MỚI có khả năng tăng tốc độ mạng | ⚠ đây là một CÔNG NGHỆ MỚI | | ⚠ Bối cảnh là dự án CÔNG NGHỆ THÔNG TIN | | | ⚠ Yếu tố thúc đẩy dự án chính là khả năng kỹ thuật mới | | | ⚠ Định nghĩa yếu tố KỸ THUẬT trong PESTLE | ⚠ công nghệ mới, tự động hoá, đổi mới, nghiên cứu phát triển, tốc độ thay đổi công nghệ | | ⚠ Còn việc đồng nghiệp phản đối | ⚠ đó là VẤN ĐỀ QUẢN TRỊ THAY ĐỔI, không phải một yếu tố PESTLE |

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

  • B (chính trị) — ⚠ phương án gây nhiễu mạnh nhất vì đề nhấn mạnh sự PHẢN ĐỐI của đồng nghiệp, nghe như "chính trị nội bộ": ⚠ nhưng yếu tố CHÍNH TRỊ trong PESTLE nói về ⚠ chính sách nhà nước, ổn định chính trị, thuế, quy định thương mại ⚠ — ⚠ KHÔNG phải chính trị công sở; ⚠ đây là bẫy ngôn ngữ điển hình.

  • D (pháp lý) — ⚠ luật, quy định, tuân thủ, sở hữu trí tuệ; ⚠ đề không nhắc tới.

  • A (môi trường) — ⚠ khí hậu, tác động sinh thái, phát triển bền vững; ⚠ không liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25909 ở lô 183 (yếu tố khiến dự án hết cần thiết — phân biệt bên trong và bên ngoài), câu #25923 (danh sách gợi ý là kỹ thuật nhận diện rủi ro, và PESTLE là một danh sách gợi ý), và câu #26034 lô 186 (thay đổi công nghệ cần quản trị thay đổi văn hoá). ⚠ Nhóm phân tích môi trường bên ngoài.

⚠ PESTLE — sáu yếu tố môi trường BÊN NGOÀI: | Chữ | Yếu tố | Ví dụ | |---|---|---| | ⚠ P — Political | ⚠ CHÍNH TRỊ | ⚠ chính sách nhà nước, ổn định chính trị, thuế, thương mại quốc tế | | ⚠ E — Economic | ⚠ KINH TẾ | ⚠ lạm phát, lãi suất, tăng trưởng, tỷ giá | | ⚠ S — Social | ⚠ XÃ HỘI | ⚠ nhân khẩu, văn hoá, lối sống, thói quen tiêu dùng | | ⚠ T — Technological | ⚠ KỸ THUẬT | ⚠ công nghệ mới, tự động hoá, đổi mới — CÂU NÀY | | ⚠ L — Legal | ⚠ PHÁP LÝ | ⚠ luật lao động, an toàn, sở hữu trí tuệ, tuân thủ | | ⚠ E — Environmental | ⚠ MÔI TRƯỜNG | ⚠ khí hậu, chất thải, phát triển bền vững | | ⚠ Dùng để làm gì | ⚠ NHẬN DIỆN RỦI RO có hệ thống — là một "danh sách gợi ý" (liên hệ #25923 lô 183) | | ⚠ Đặc điểm quan trọng | ⚠ PESTLE chỉ quét yếu tố BÊN NGOÀI tổ chức — liên hệ #25909 lô 183 |

Từ khoá nhận diện:

"công nghệ mới, tự động hoá, đổi mới" → ⚠ KỸ THUẬT "chính sách nhà nước, thuế" → ⚠ CHÍNH TRỊ, không phải chính trị công sở "luật, quy định, tuân thủ" → ⚠ PHÁP LÝ "đồng nghiệp phản đối" → ⚠ quản trị thay đổi, KHÔNG phải yếu tố PESTLE

⚠ Vấn đề THẬT của Brittany là gì Vấn đề
⚠ Yếu tố PESTLE là KỸ THUẬT — công nghệ mới tạo cơ hội ⚠ câu trả lời của câu hỏi
⚠ Nhưng THÁCH THỨC THẬT là sự KHÁNG CỰ của con người
⚠ Đó là bài toán QUẢN TRỊ THAY ĐỔI TỔ CHỨC ⚠ liên hệ #26034 lô 186 — bàn giao xong vẫn cần thay đổi văn hoá
⚠ Việc cô cần làm ⚠ nhận diện bên liên quan phản đối, tìm hiểu lý do, truyền thông về LỢI ÍCH — liên hệ #26074 lô 186
⚠ Sai lầm phổ biến ⚠ cho rằng công nghệ tốt thì tự khắc được chấp nhận
⚠ Các mô hình quét môi trường khác Mô hình
⚠ PESTLE ⚠ sáu yếu tố bên ngoài — CÂU NÀY
⚠ SWOT ⚠ điểm mạnh, yếu (bên trong) + cơ hội, thách thức (bên ngoài)
⚠ TECOP ⚠ kỹ thuật, môi trường, thương mại, vận hành, chính trị
⚠ VUCA ⚠ biến động, bất định, phức tạp, mơ hồ
⚠ Điểm chung ⚠ đều là DANH SÁCH GỢI Ý để không bỏ sót loại rủi ro nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn đã quét đủ sáu yếu tố PESTLE chưa | | | Yếu tố nào ảnh hưởng nhiều nhất tới dự án bạn | | | Bạn có nhầm "chính trị công sở" với yếu tố chính trị PESTLE không | ⚠ bẫy ngôn ngữ hay gặp nhất của mô hình này |

Và điều tình huống của Brittany minh hoạ rất rõ: yếu tố kỹ thuật tạo ra CƠ HỘI, nhưng yếu tố quyết định dự án thành hay bại lại là con người — và không có chữ cái nào trong PESTLE dành cho điều đó.

Câu 390 Process
Shirley is a product owner at Galaxy, Inc. Who has created a list of features using Kano Analysis. Most of the items on her list provide value to the customer but are not especially innovative or unexpected features. She can best classify those items as
  1. A Indifferent
  2. B Kanovators
  3. C Satisfiers
  4. D Delighters
Xem giải thích

Đáp án

C — NHÓM THOẢ MÃN (satisfiers).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Tính năng MANG LẠI GIÁ TRỊ cho khách hàng | ⚠ có tác động tích cực | | ⚠ Nhưng KHÔNG đặc biệt sáng tạo hay bất ngờ | ⚠ không tạo cảm giác thích thú | | ⚠ Đó chính là nhóm THOẢ MÃN — còn gọi là "hiệu năng" | | | ⚠ Đặc điểm nhóm này | ⚠ CÀNG NHIỀU CÀNG TỐT — mức hài lòng tăng TỶ LỆ THUẬN với mức đáp ứng | | ⚠ Ví dụ | ⚠ tốc độ tải trang, dung lượng lưu trữ, thời lượng pin — nhanh hơn, nhiều hơn thì khách hàng hài lòng hơn |

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

  • D (nhóm gây thích thú — delighters) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là nhóm mang lại giá trị: ⚠ nhưng delighters là những tính năng ⚠ BẤT NGỜ, khách hàng KHÔNG NGHĨ TỚI mà lại rất thích ⚠ — ⚠ đề nói rõ các tính năng này KHÔNG đặc biệt sáng tạo hay bất ngờ.

  • A (nhóm thờ ơ — indifferent) — ⚠ khách hàng KHÔNG quan tâm, có hay không cũng vậy; ⚠ đề nói rõ chúng CÓ mang lại giá trị.

  • B ("Kanovators") — ⚠ KHÔNG phải thuật ngữ; ⚠ phương án bịa dựa trên tên Kano.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25912 ở lô 183 (PO xếp backlog theo rủi ro), câu #26002 lô 185 (xếp hạng tuyệt đối), câu #26043 lô 186 (phương pháp 100 điểm), và câu #26085 ở lô này (tiền chơi chỉ dùng cho chức năng nghiệp vụ). ⚠ Nhóm xếp ưu tiên backlog — và Kano là mô hình PHÂN LOẠI, bổ sung cho các kỹ thuật bỏ phiếu.

⚠ MÔ HÌNH KANO — năm nhóm tính năng: | Nhóm | Đặc điểm | Nếu CÓ | Nếu KHÔNG | |---|---|---|---| | ⚠ CƠ BẢN (basic / must-be) | ⚠ khách hàng coi là hiển nhiên | ⚠ không ai khen | ⚠ rất bất mãn | | ⚠ THOẢ MÃN (satisfier / performance) | ⚠ càng nhiều càng tốt — CÂU NÀY | ⚠ hài lòng tăng dần | ⚠ hài lòng giảm dần | | ⚠ GÂY THÍCH THÚ (delighter / excitement) | ⚠ bất ngờ, không được kỳ vọng | ⚠ rất thích thú | ⚠ không ai để ý | | ⚠ THỜ Ơ (indifferent) | ⚠ khách hàng không quan tâm | ⚠ không ảnh hưởng | ⚠ không ảnh hưởng | | ⚠ NGƯỢC (reverse) | ⚠ có lại làm giảm hài lòng | ⚠ khó chịu | ⚠ hài lòng | | ⚠ Điểm quan trọng nhất | ⚠ các nhóm DI CHUYỂN theo thời gian — delighter hôm nay thành basic ngày mai |

⚠ Ví dụ về sự di chuyển theo thời gian: | Tính năng | Trước đây | Bây giờ | |---|---|---| | ⚠ Camera trên điện thoại | ⚠ DELIGHTER | ⚠ BASIC | | ⚠ Wifi trong khách sạn | ⚠ DELIGHTER | ⚠ BASIC | | ⚠ Tốc độ tải trang | ⚠ SATISFIER | ⚠ vẫn là SATISFIER | | ⚠ Hệ quả cho product owner | ⚠ phải RÀ LẠI phân loại Kano định kỳ — cái từng làm khách hàng thích thú giờ chỉ là điều kiện tối thiểu |

Từ khoá nhận diện:

"có giá trị nhưng không bất ngờ, càng nhiều càng tốt" → ⚠ thoả mãn "bất ngờ, khách hàng không nghĩ tới" → ⚠ gây thích thú "hiển nhiên phải có, thiếu thì bất mãn" → ⚠ cơ bản "có hay không cũng vậy" → ⚠ thờ ơ ⚠ Thuật ngữ nghe lạ tai như "Kanovators" → ⚠ thường là phương án bịa

⚠ Dùng Kano để xếp ưu tiên backlog thế nào Cách
⚠ Làm ĐỦ nhóm CƠ BẢN trước ⚠ thiếu là khách hàng bất mãn ngay, dù làm tốt mọi thứ khác
⚠ Đầu tư vào nhóm THOẢ MÃN theo mức cạnh tranh ⚠ đây là nơi so kè với đối thủ
⚠ Chọn MỘT VÀI delighter làm điểm khác biệt ⚠ không cần nhiều — vài cái đủ tạo ấn tượng
⚠ LOẠI BỎ nhóm thờ ơ khỏi backlog ⚠ tiết kiệm được nhiều công sức nhất
⚠ Cách thu thập dữ liệu ⚠ khảo sát Kano hỏi mỗi tính năng hai lần: "nếu CÓ bạn thấy sao" và "nếu KHÔNG CÓ bạn thấy sao"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog của bạn có tính năng nào thuộc nhóm THỜ Ơ không | ⚠ đó là ứng viên để cắt | | Các tính năng CƠ BẢN đã đủ chưa | ⚠ thiếu một cái là hỏng cả sản phẩm | | Phân loại Kano của bạn cập nhật lần cuối khi nào | |

Và bài học quan trọng nhất từ mô hình Kano: đầu tư thêm vào một tính năng CƠ BẢN đã đủ tốt gần như không mang lại gì — trong khi cùng công sức đó bỏ vào nhóm thoả mãn hoặc một delighter thì khách hàng nhận ra ngay.