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

Tìm thấy 720 câu.

Câu 421 People
Quincy is the scrum master for Project F, which is just beginning its implementation and has a budget of $100,000. At the first team meeting, Quincy wants to ensure the team has a common set of guidelines to operate together best. What best resembles this idea?
  1. A Ground rules
  2. B Project charter
  3. C Project scope statement
  4. D Communications plan
Xem giải thích

Đáp án

A — QUY TẮC CHUNG (ground rules).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ BUỔI HỌP ĐẦU TIÊN của đội | ⚠ đúng thời điểm lập quy tắc chung | | ⚠ Quincy muốn đội có BỘ HƯỚNG DẪN CHUNG | ⚠ định nghĩa gần như nguyên văn của quy tắc chung | | ⚠ Để cùng nhau LÀM VIỆC tốt nhất | ⚠ về CÁCH LÀM VIỆC, không về nội dung dự án | | ⚠ Định nghĩa | ⚠ quy tắc chung là các hành vi mong đợi mà ĐỘI CÙNG NHAU thiết lập và cùng giữ | | ⚠ Ví dụ nội dung | ⚠ họp đúng giờ, không cắt lời, mỗi người có tiếng nói, quyết định gì thì ghi lại, cách xử lý bất đồng |

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

  • B (điều lệ dự án) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là tài liệu ở đầu dự án: ⚠ nhưng điều lệ ⚠ PHÊ CHUẨN DỰ ÁN và bổ nhiệm quản lý dự án ⚠ (liên hệ #26077 lô 186), ⚠ do NHÀ TÀI TRỢ ban hành, không phải do đội cùng lập.

  • D (kế hoạch giao tiếp) — ⚠ quy định AI NHẬN thông tin gì, khi nào, qua kênh nào; ⚠ hẹp hơn nhiều so với cách làm việc chung.

  • C (tuyên bố phạm vi) — ⚠ mô tả CÔNG VIỆC phải làm, ⚠ không mô tả cách đội làm việc với nhau.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25970 ở lô 184 (ai thực thi quy tắc chung → ĐỘI DỰ ÁN) — ⚠ hai câu bổ sung nhau: câu đó hỏi AI GIỮ, câu này hỏi NÓ LÀ GÌ. ⚠ Xem thêm câu #25883 lô 183 (thoả thuận làm việc nhóm), câu #26140 ở lô này (ý kiến bị gạt trong retrospective), và câu #25992 lô 185 (xung đột xây dựng).

⚠ Quy tắc chung — đặc điểm: | Đặc điểm | Nội dung | |---|---| | ⚠ Do ĐỘI CÙNG XÂY DỰNG, không áp từ trên xuống | ⚠ đó là lý do người ta tuân theo | | ⚠ Về HÀNH VI và CÁCH LÀM VIỆC, không về nội dung công việc | | | ⚠ ĐỘI tự thực thi, không phải quản lý đi phạt | ⚠ liên hệ #25970 lô 184 | | ⚠ Nằm trong KẾ HOẠCH QUẢN LÝ NGUỒN LỰC | | | ⚠ Được rà lại khi có người mới hoặc khi vi phạm lặp lại | | | ⚠ Số lượng hợp lý | ⚠ năm tới bảy điều — nhiều hơn thì không ai nhớ |

Từ khoá nhận diện:

"bộ hướng dẫn chung để làm việc cùng nhau" → ⚠ quy tắc chung "phê chuẩn dự án, bổ nhiệm PM" → ⚠ điều lệ dự án "ai nhận thông tin gì" → ⚠ kế hoạch giao tiếp "công việc phải làm" → ⚠ tuyên bố phạm vi

⚠ Quy tắc chung tốt trông thế nào Đặc điểm
⚠ CỤ THỂ và QUAN SÁT ĐƯỢC ⚠ "tôn trọng lẫn nhau" là vô dụng; "không cắt lời khi người khác đang nói" thì dùng được
⚠ Do cả đội đề xuất và đồng ý
⚠ Bao gồm cả cách XỬ LÝ KHI VI PHẠM ⚠ phần hay bị quên nhất
⚠ Treo ở nơi ai cũng thấy
⚠ Ví dụ điển hình ⚠ camera bật trong họp trực tuyến, tắt thông báo khi họp, quyết định phải được ghi lại, ai vắng thì phải đọc biên bản
⚠ Trong agile ⚠ thường gọi là "thoả thuận làm việc" (working agreement) — liên hệ #25883 lô 183
⚠ Vì sao buổi họp đầu tiên là đúng thời điểm Lý do
⚠ Trước khi các thói quen xấu hình thành
⚠ Đội chưa có mâu thuẫn nào nên bàn dễ hơn ⚠ lập quy tắc lúc đang xung đột thì rất khó
⚠ Đặt kỳ vọng chung ngay từ đầu
⚠ Tạo trải nghiệm ra quyết định tập thể đầu tiên ⚠ bài tập tốt cho đội mới
⚠ Với đội đã chạy lâu ⚠ vẫn lập được — thường ở một retrospective, khi có vấn đề lặp lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có quy tắc chung viết ra không | | | Có ai nhớ được ba điều trong đó không | ⚠ thử hỏi bất chợt | | Khi có người vi phạm, ai nhắc | ⚠ nếu chỉ có quản lý nhắc thì đó là nội quy, không phải quy tắc chung |

Và điều làm nên sức mạnh của một bộ quy tắc do chính đội viết ra: khi có người vi phạm, người nhắc không phải viện dẫn quyền lực nào cả — chỉ cần nhắc lại điều mà chính người đó đã đồng ý.

Câu 422 Business Environment
Hank is the scrum master for Project Redpeak, eight iterations into deployment and roughly on budget. During planning sessions, Hank was made aware that several local regulations may change to impact the project positively. During the previous iteration, these regulations went into effect, and Hank has acted according to the risk management plan. What should Hank do next?
  1. A Inform the project sponsor of the positive risk event.
  2. B Mitigate any residual risk.
  3. C Do nothing. Hank has followed the plan to capitalize on these risks.
  4. D Review the stakeholder management plan.
Xem giải thích

Đáp án

A — THÔNG BÁO CHO NHÀ TÀI TRỢ về sự kiện rủi ro TÍCH CỰC.

Vì sao đúng

⚠ Vì sao phải báo dù đây là tin TỐT: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro TÍCH CỰC (cơ hội) ĐÃ XẢY RA | ⚠ quy định mới có lợi cho dự án đã có hiệu lực | | ⚠ Nhà tài trợ cần biết để có thể TẬN DỤNG ở tầm cao hơn | ⚠ có thể mở rộng phạm vi, có thể áp dụng cho dự án khác | | ⚠ Minh bạch áp dụng cho CẢ TIN TỐT lẫn TIN XẤU | | | ⚠ Hank đã làm đúng phần của mình: hành động theo kế hoạch rủi ro | ⚠ giờ tới bước BÁO CÁO | | ⚠ Nguyên tắc | ⚠ quản lý rủi ro không kết thúc khi rủi ro xảy ra — còn phải ghi nhận và truyền đạt |

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

  • C (không làm gì, Hank đã theo kế hoạch để tận dụng rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì Hank ĐÚNG LÀ đã làm theo kế hoạch: ⚠ nhưng ⚠ thực hiện ứng phó chỉ là MỘT BƯỚC ⚠ — còn phải ⚠ báo cáo, cập nhật sổ rủi ro, và đánh giá rủi ro TỒN DƯ; ⚠ "không làm gì" gần như luôn là đáp án sai.

  • B (giảm nhẹ rủi ro tồn dư) — ⚠ là việc CÓ thể cần làm, ⚠ nhưng ⚠ rủi ro tồn dư của một CƠ HỘI đã thành hiện thực thường không đáng kể; ⚠ và bước ưu tiên là báo cáo.

  • D (rà soát kế hoạch quản lý bên liên quan) — ⚠ không liên quan trực tiếp; ⚠ đây là sự kiện rủi ro, không phải thay đổi về bên liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25792/#25807/#25808/#25846 lô 181–182 (bộ chiến lược ứng phó rủi ro TIÊU CỰC), câu #26040 lô 186 (chuyển giao), câu #26087 lô 187 (EMV cho dự phòng), và câu #26147 ở lô này (rủi ro thứ cấp). ⚠ Nhóm rủi ro — và đây là một trong RẤT ÍT câu nói về rủi ro TÍCH CỰC.

⚠ NĂM chiến lược ứng phó rủi ro TÍCH CỰC (cơ hội): | Chiến lược | Nội dung | Đối xứng với rủi ro tiêu cực | |---|---|---| | ⚠ KHAI THÁC (exploit) | ⚠ làm mọi cách để cơ hội CHẮC CHẮN xảy ra | ⚠ đối xứng với NÉ TRÁNH | | ⚠ CHIA SẺ (share) | ⚠ hợp tác với bên có năng lực tận dụng tốt hơn | ⚠ đối xứng với CHUYỂN GIAO | | ⚠ NÂNG CAO (enhance) | ⚠ tăng xác suất hoặc tác động tích cực | ⚠ đối xứng với GIẢM NHẸ | | ⚠ CHẤP NHẬN (accept) | ⚠ không hành động đặc biệt, hưởng nếu nó tới | ⚠ giống tên với rủi ro tiêu cực | | ⚠ LEO THANG (escalate) | ⚠ cơ hội vượt thẩm quyền dự án | ⚠ giống tên với rủi ro tiêu cực | | ⚠ Mẹo nhớ | ⚠ KHAI THÁC – CHIA SẺ – NÂNG CAO là ba tên riêng của cơ hội; CHẤP NHẬN và LEO THANG dùng chung cho cả hai chiều |

Từ khoá nhận diện:

"rủi ro tích cực đã xảy ra" → ⚠ vẫn phải báo cáo và cập nhật sổ rủi ro "không làm gì vì đã theo kế hoạch" → ⚠ thiếu bước báo cáo "khai thác, nâng cao, chia sẻ" → ⚠ chiến lược cho CƠ HỘI "né tránh, giảm nhẹ, chuyển giao" → ⚠ chiến lược cho MỐI ĐE DOẠ

⚠ Hank nên làm đầy đủ những gì Bước
⚠ 1. THÔNG BÁO nhà tài trợ ⚠ CÂU NÀY
⚠ 2. Cập nhật SỔ ĐĂNG KÝ RỦI RO — đóng rủi ro này
⚠ 3. Đánh giá RỦI RO TỒN DƯ và RỦI RO THỨ CẤP ⚠ liên hệ #26147 cùng lô
⚠ 4. Cập nhật dự báo lịch và chi phí nếu cơ hội mang lại lợi ích
⚠ 5. Thông báo các bên liên quan khác
⚠ 6. Ghi vào BÀI HỌC — cách nhận diện và chuẩn bị cho cơ hội này ⚠ liên hệ #26141 cùng lô
⚠ Điểm đáng khen của Hank ⚠ anh đã NHẬN DIỆN cơ hội từ giai đoạn lập kế hoạch và có sẵn kế hoạch ứng phó — phần lớn dự án chỉ ghi rủi ro tiêu cực
⚠ Vì sao rủi ro TÍCH CỰC hay bị bỏ quên Lý do
⚠ Người ta quen nghĩ "rủi ro" là chuyện xấu
⚠ Sổ rủi ro thường chỉ liệt kê mối đe doạ
⚠ Không ai bị phạt vì bỏ lỡ một cơ hội ⚠ trong khi bị phạt nếu để xảy ra sự cố
⚠ Cái giá ⚠ bỏ lỡ những cải thiện đáng kể mà chỉ cần chuẩn bị trước là nắm được
⚠ Cách khắc phục ⚠ khi nhận diện rủi ro, hỏi thẳng: "điều gì có thể xảy ra làm dự án TỐT HƠN dự kiến?"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có rủi ro TÍCH CỰC nào không | ⚠ nếu không có câu nào thì bạn mới quét một nửa | | Khi tin tốt xảy ra, bạn có báo cáo không | ⚠ hay chỉ báo cáo khi có sự cố | | Cơ hội gần nhất có được ghi nhận chính thức không | |

Và điều dễ bị quên nhất về quản lý rủi ro: báo cáo tin tốt cũng quan trọng như báo tin xấu — vì nhà tài trợ chỉ có thể tận dụng cơ hội ở tầm tổ chức nếu ông ta biết là nó đã xảy ra.

Câu 423 People
Brad is a scrum master for Project X, which suffered a setback during the current sprint. Due to this setback, Brad sent updates to key stakeholders a day late. The stakeholders were upset that their report was late, but Brad was able to smooth the situation. What should Brad do at the next retrospective?
  1. A Bring up the late reports, but minimize the impact.
  2. B Share with the team that he sent the reports late and explain why it happened.
  3. C Do nothing.
  4. D Blame the late reports on the setback.
Xem giải thích

Đáp án

B — CHIA SẺ VỚI ĐỘI rằng anh đã gửi báo cáo trễ và GIẢI THÍCH vì sao chuyện đó xảy ra.

Vì sao đúng

⚠ Vì sao nói thẳng là cách đúng: | Lý do | Nội dung | |---|---| | ⚠ Retrospective là nơi rà soát MỌI thứ đã xảy ra | ⚠ kể cả sai sót của Scrum Master | | ⚠ Lãnh đạo TỰ NHẬN LỖI xây dựng AN TOÀN TÂM LÝ | ⚠ liên hệ #25922 lô 183 — lãnh đạo agile thừa nhận sai lầm | | ⚠ Giải thích NGUYÊN NHÂN để cả đội cùng tìm cách phòng ngừa | | | ⚠ Đội có thể giúp — ví dụ có người báo cáo thay khi Brad bận | | | ⚠ Điều quan trọng nhất | ⚠ nếu Scrum Master giấu lỗi của mình thì không ai trong đội dám nói lỗi của họ |

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

  • A (nêu chuyện báo cáo trễ nhưng GIẢM NHẸ tác động) — ⚠ phương án gây nhiễu mạnh nhất vì nó CÓ nêu ra: ⚠ nhưng ⚠ giảm nhẹ là một dạng che giấu ⚠ — bên liên quan ĐÃ bực, tác động là THẬT; ⚠ làm nhẹ đi thì đội học được rằng nên giảm nhẹ lỗi của mình.

  • D (đổ lỗi việc trễ cho sự cố) — ⚠ ĐỔ LỖI cho hoàn cảnh; ⚠ sự cố là NGUYÊN NHÂN cần giải thích, không phải cái cớ để né trách nhiệm.

  • C (không làm gì) — ⚠ bỏ qua một sự việc đã ảnh hưởng tới bên liên quan; ⚠ và retrospective tồn tại chính để bàn những chuyện như vậy.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25922 ở lô 183 (lãnh đạo agile công khai thừa nhận sai lầm — biểu hiện tốt nhất), câu #25992 lô 185 (môi trường an toàn để bất đồng), câu #26140 ở lô này (ý kiến bị gạt trong retrospective), và câu #26004 lô 185 (báo tin xấu sớm và đặt lại kỳ vọng). ⚠ Nhóm an toàn tâm lý và minh bạch.

⚠ Vì sao Scrum Master tự nhận lỗi lại có sức mạnh lớn: | Lý do | Nội dung | |---|---| | ⚠ Đó là BẰNG CHỨNG không thể làm giả rằng nói thật là an toàn | ⚠ mọi lời kêu gọi minh bạch đều vô nghĩa nếu người dẫn dắt không làm trước | | ⚠ Hạ thấp rào cản cho người khác thừa nhận sai sót | | | ⚠ Chuyển trọng tâm từ AI SAI sang HỆ THỐNG THIẾU GÌ | | | ⚠ Sai sót được nêu sớm thì sửa được sớm | | | ⚠ Liên hệ | ⚠ #25922 lô 183 — đây chính xác là hành vi được coi là biểu hiện tốt nhất của lãnh đạo agile |

Từ khoá nhận diện:

"tự nhận lỗi và giải thích nguyên nhân" → ⚠ xây dựng an toàn tâm lý "giảm nhẹ tác động" → ⚠ một dạng che giấu "đổ lỗi cho hoàn cảnh" → ⚠ né trách nhiệm "không làm gì" → ⚠ bỏ qua sự việc đã ảnh hưởng thật

⚠ Brad nên trình bày thế nào Cách
⚠ Nêu SỰ VIỆC: báo cáo gửi trễ một ngày
⚠ Nêu TÁC ĐỘNG THẬT: bên liên quan không hài lòng ⚠ không giảm nhẹ
⚠ Nêu NGUYÊN NHÂN: sự cố khiến anh mất tập trung vào việc báo cáo
⚠ Hỏi đội: làm sao để lần sau không lặp lại ⚠ biến nó thành cải tiến quy trình
⚠ Chốt một HÀNH ĐỘNG cụ thể ⚠ ví dụ có người dự phòng, hoặc mẫu báo cáo soạn sẵn
⚠ Điều KHÔNG nên ⚠ xin lỗi dài dòng — nêu sự việc, nêu bài học, rồi đi tiếp
⚠ Vì sao "sự cố" không phải cái cớ Lý do
⚠ Sự cố là chuyện BÌNH THƯỜNG trong dự án ⚠ kế hoạch giao tiếp phải chịu được sự cố
⚠ Bên liên quan cần thông tin NHẤT vào lúc có sự cố ⚠ nghịch lý: đúng lúc dễ trễ nhất lại là lúc cần nhất
⚠ Nếu một sự cố làm sập cả quy trình báo cáo thì quy trình đó mong manh
⚠ Bài học thật ⚠ cần cơ chế báo cáo không phụ thuộc vào việc một người có rảnh hay không
⚠ Liên hệ ⚠ #26004 lô 185 — khi có vấn đề, báo SỚM và đặt lại kỳ vọng, đừng để bên liên quan tự phát hiện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần cuối bạn nêu sai sót của chính mình trước đội là khi nào | | | Quy trình báo cáo của bạn có phụ thuộc vào một người không | | | Retrospective của đội có bàn về sai sót của người dẫn dắt không | ⚠ nếu chưa bao giờ thì có thể đội chưa thấy đủ an toàn |

Và điều Brad đổi được bằng vài phút khó chịu ở retrospective: quyền được nghe đội nói thật về những sai sót của chính họ trong tất cả các sprint còn lại.

Câu 424 People
Theresa participates in several activities that help her team's knowledge to grow. On her agile project, the most common activity she is likely to perform is
  1. A Evaluating
  2. B Coaching
  3. C Mentoring
  4. D Training
Xem giải thích

Đáp án

B — HUẤN LUYỆN (coaching).

Vì sao đúng

⚠ Vì sao huấn luyện là hoạt động phổ biến nhất trong agile: | Lý do | Nội dung | |---|---| | ⚠ Huấn luyện giúp người ta TỰ TÌM RA câu trả lời | ⚠ hỏi thay vì bảo | | ⚠ Phù hợp với đội TỰ TỔ CHỨC | ⚠ liên hệ #26030 lô 185 — Rose tin tưởng đội tự quyết | | ⚠ Diễn ra LIÊN TỤC trong công việc hằng ngày | ⚠ không cần sắp lịch riêng như đào tạo | | ⚠ Nhắm vào KỸ NĂNG và CÁCH TƯ DUY, không chỉ kiến thức | | | ⚠ Vai trò Scrum Master | ⚠ huấn luyện đội, product owner và cả tổ chức — liên hệ #25913 lô 183 |

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

  • C (kèm cặp — mentoring) — ⚠ phương án gây nhiễu mạnh nhất vì rất gần với huấn luyện: ⚠ nhưng kèm cặp là ⚠ người CÓ KINH NGHIỆM HƠN chia sẻ kiến thức và định hướng nghề nghiệp, ⚠ thường là quan hệ DÀI HẠN một-một; ⚠ huấn luyện tập trung vào NĂNG LỰC HIỆN TẠI và câu hỏi cụ thể, phổ biến hơn nhiều trong công việc hằng ngày của đội agile.

  • D (đào tạo — training) — ⚠ truyền đạt kiến thức có cấu trúc, theo lịch; ⚠ hữu ích nhưng KHÔNG phải hoạt động thường xuyên nhất.

  • A (đánh giá — evaluating) — ⚠ thẩm định năng lực; ⚠ không phải hoạt động phát triển tri thức, và không hợp với tinh thần đội tự tổ chức.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25913 ở lô 183 (Scrum Master huấn luyện bên liên quan về story point), câu #26019 lô 185 (ghép cặp lập trình viên trẻ), câu #25958 lô 184 (tổ chức gọi quản lý là huấn luyện viên), và câu #26011 lô 185 (Stephen học agile bằng cách hợp tác với đồng đội). ⚠ Nhóm phát triển năng lực đội.

⚠ BỐN cách phát triển năng lực — bảng phân biệt: | Cách | Nội dung | Ai làm | Nhịp độ | |---|---|---|---| | ⚠ HUẤN LUYỆN (coaching) | ⚠ HỎI để người ta tự tìm ra câu trả lời | ⚠ Scrum Master, đồng đội | ⚠ LIÊN TỤC, hằng ngày — CÂU NÀY | | ⚠ KÈM CẶP (mentoring) | ⚠ CHIA SẺ kinh nghiệm và định hướng | ⚠ người có kinh nghiệm hơn | ⚠ dài hạn, định kỳ | | ⚠ ĐÀO TẠO (training) | ⚠ truyền đạt kiến thức có cấu trúc | ⚠ giảng viên | ⚠ theo khoá, có lịch | | ⚠ ĐÁNH GIÁ (evaluating) | ⚠ thẩm định năng lực hiện có | ⚠ quản lý hoặc bên thứ ba | ⚠ định kỳ | | ⚠ Mẹo phân biệt | ⚠ huấn luyện HỎI, kèm cặp KỂ, đào tạo DẠY, đánh giá ĐO | | ⚠ Vì sao huấn luyện phổ biến nhất trong agile | ⚠ nó là cách duy nhất phát triển năng lực mà KHÔNG lấy đi quyền tự quyết của đội |

Từ khoá nhận diện:

"giúp đội tự tìm ra câu trả lời, hằng ngày" → ⚠ huấn luyện "người kinh nghiệm hơn định hướng dài hạn" → ⚠ kèm cặp "khoá học có cấu trúc" → ⚠ đào tạo "thẩm định năng lực" → ⚠ đánh giá

⚠ Huấn luyện trong thực tế trông thế nào Ví dụ
⚠ "Bạn nghĩ vì sao chuyện đó xảy ra?" ⚠ thay vì "chuyện đó xảy ra vì..."
⚠ "Có cách nào khác để thử không?"
⚠ "Nếu làm lại, bạn sẽ làm gì khác?"
⚠ Im lặng và chờ họ nghĩ ⚠ kỹ thuật khó nhất và hiệu quả nhất
⚠ Điều KHÔNG phải huấn luyện ⚠ đưa ra câu trả lời rồi gọi đó là huấn luyện
⚠ Vì sao khó ⚠ chậm hơn nhiều so với việc chỉ nói thẳng đáp án — nhưng người kia học được
⚠ Vì sao đội agile cần huấn luyện hơn đào tạo Lý do
⚠ Vấn đề của đội là CỤ THỂ và luôn thay đổi ⚠ khoá học chung không giải quyết được
⚠ Đội tự tổ chức cần tự ra quyết định ⚠ đào tạo cho kiến thức, huấn luyện cho khả năng tự quyết
⚠ Diễn ra trong bối cảnh công việc thật
⚠ Nhưng đào tạo vẫn cần ⚠ cho kiến thức nền: công nghệ mới, khung Scrum, kỹ năng chuyên môn
⚠ Kết hợp tốt nhất ⚠ đào tạo cho nền tảng, huấn luyện để biến nền tảng thành năng lực thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khi ai đó hỏi bạn, bạn TRẢ LỜI hay HỎI LẠI | | | Đội bạn có tự giải quyết được vấn đề mới không | ⚠ thước đo của huấn luyện tốt | | Người trong đội có huấn luyện lẫn nhau không | ⚠ dấu hiệu đội đã trưởng thành |

Và cách nhận ra một người huấn luyện giỏi: sau khi nói chuyện với họ, bạn nghĩ rằng mình đã tự tìm ra câu trả lời — và thật ra thì đúng là bạn đã tự tìm ra.

Câu 425 Process
Jess is the scrum master for Project M, nine iterations into deployment, has a velocity of forty-two story points, and is on budget. Recently Project M experienced a major risk, which was dealt with promptly. This event has triggered another, separate risk to occur. What is the name of this event?
  1. A Residual risk
  2. B Related risk
  3. C Aftershock risk
  4. D Secondary risk
Xem giải thích

Đáp án

D — RỦI RO THỨ CẤP (secondary risk).

Vì sao đúng

⚠ Định nghĩa rủi ro thứ cấp: | Đặc điểm | Nội dung | |---|---| | ⚠ Rủi ro MỚI phát sinh TRỰC TIẾP từ việc THỰC HIỆN một biện pháp ứng phó | ⚠ đúng tình huống của Jess | | ⚠ Nó KHÔNG tồn tại trước khi ta hành động | ⚠ chính hành động của ta tạo ra nó | | ⚠ Phải được NHẬN DIỆN và LẬP KẾ HOẠCH như mọi rủi ro khác | | | ⚠ Ví dụ điển hình | ⚠ thuê ngoài để chuyển giao rủi ro kỹ thuật → sinh ra rủi ro MỚI là phụ thuộc nhà cung cấp (liên hệ #26040 lô 186) | | ⚠ Ví dụ khác | ⚠ đẩy nhanh tiến độ bằng crashing → sinh rủi ro chất lượng giảm |

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

  • A (rủi ro tồn dư — residual risk) — ⚠ phương án gây nhiễu mạnh nhất vì là khái niệm SÓNG ĐÔI: ⚠ nhưng rủi ro tồn dư là ⚠ PHẦN CÒN LẠI của CHÍNH rủi ro ban đầu sau khi đã ứng phó ⚠ — nó ⚠ KHÔNG PHẢI rủi ro MỚI; ⚠ ở đây đề nói rõ một rủi ro KHÁC, RIÊNG BIỆT đã phát sinh.

  • C (rủi ro dư chấn — aftershock risk) và B (rủi ro liên quan — related risk) — ⚠ KHÔNG phải thuật ngữ chuẩn; ⚠ hai phương án bịa nghe hợp lý.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26040 ở lô 186 (chuyển giao rủi ro — thuê nhà thầu xử lý hoá chất), câu #26087 lô 187 (EMV cho dự phòng bất trắc), câu #26144 ở lô này (rủi ro tích cực đã xảy ra), và bộ chiến lược ứng phó ở lô 181–182. ⚠ Nhóm rủi ro nay lên MƯỜI câu.

⚠ BA loại rủi ro liên quan tới việc ỨNG PHÓ — bảng phân biệt: | Loại | Định nghĩa | Ví dụ | |---|---|---| | ⚠ RỦI RO TỒN DƯ (residual) | ⚠ phần CÒN LẠI của rủi ro GỐC sau khi đã ứng phó | ⚠ mua bảo hiểm rồi vẫn còn phần miễn thường phải tự chịu | | ⚠ RỦI RO THỨ CẤP (secondary) | ⚠ rủi ro MỚI do CHÍNH biện pháp ứng phó sinh ra — CÂU NÀY | ⚠ thuê ngoài → phụ thuộc nhà cung cấp | | ⚠ RỦI RO KÍCH HOẠT (trigger) | ⚠ DẤU HIỆU cho biết rủi ro sắp xảy ra | ⚠ liên hệ #25983 lô 185 — ngưỡng | | ⚠ Mẹo nhớ | ⚠ TỒN DƯ là phần THỪA LẠI của rủi ro cũ; THỨ CẤP là rủi ro HOÀN TOÀN MỚI do ta tạo ra | | ⚠ Điểm chung | ⚠ cả hai đều PHẢI được ghi vào sổ rủi ro — nhưng rất hay bị bỏ quên |

Từ khoá nhận diện:

"rủi ro MỚI phát sinh từ việc xử lý rủi ro cũ" → ⚠ thứ cấp "phần còn lại của rủi ro sau khi đã xử lý" → ⚠ tồn dư "dấu hiệu cho biết rủi ro sắp đến" → ⚠ điểm kích hoạt ⚠ Thuật ngữ nghe hợp lý nhưng không có trong tài liệu chuẩn → ⚠ phương án bịa

⚠ Vì sao rủi ro thứ cấp hay bị bỏ quên Lý do
⚠ Người ta coi việc ứng phó là "xong việc" ⚠ không nghĩ rằng chính hành động của mình tạo ra rủi ro mới
⚠ Sổ rủi ro thường không có cột cho rủi ro thứ cấp
⚠ Tâm lý nhẹ nhõm sau khi xử lý xong rủi ro lớn ⚠ đúng tâm trạng của đội Jess lúc này
⚠ Hậu quả ⚠ rủi ro thứ cấp xảy ra mà không ai chuẩn bị — vì nó chưa từng nằm trong kế hoạch nào
⚠ Cách phòng ⚠ mỗi khi lập kế hoạch ứng phó, hỏi ngay: "làm điều này sẽ tạo ra rủi ro mới nào?"
⚠ Jess nên làm gì tiếp Bước
⚠ 1. GHI rủi ro thứ cấp vào sổ đăng ký rủi ro
⚠ 2. Đánh giá xác suất và tác động của nó ⚠ liên hệ #26003 lô 185
⚠ 3. Lập kế hoạch ứng phó cho rủi ro mới này
⚠ 4. Kiểm xem còn RỦI RO TỒN DƯ của rủi ro gốc không
⚠ 5. Báo cáo bên liên quan ⚠ liên hệ #26144 cùng lô
⚠ Cẩn thận ⚠ biện pháp ứng phó cho rủi ro thứ cấp có thể lại sinh ra rủi ro thứ cấp nữa — phải dừng ở mức HỢP LÝ
⚠ Ví dụ chuỗi rủi ro thứ cấp thực tế Ví dụ
⚠ Rủi ro GỐC: đội thiếu kỹ năng về công nghệ mới
⚠ ỨNG PHÓ: thuê chuyên gia bên ngoài
⚠ RỦI RO THỨ CẤP: đội không học được gì, phụ thuộc chuyên gia ⚠ liên hệ #25928 lô 183 — chuyên gia đa năng
⚠ ỨNG PHÓ tiếp: ghép cặp đội với chuyên gia ⚠ liên hệ #26019 lô 185
⚠ RỦI RO THỨ CẤP nữa: tiến độ chậm hơn vì vừa làm vừa dạy
⚠ Kết luận ⚠ mỗi quyết định ứng phó đều mở ra một nhánh rủi ro mới — nhận diện được là đã kiểm soát được một nửa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có ghi rủi ro thứ cấp không | | | Biện pháp ứng phó gần nhất đã tạo ra rủi ro mới nào | ⚠ hỏi thẳng câu này mỗi lần lập kế hoạch ứng phó | | Có rủi ro tồn dư nào chưa được ghi không | |

Và điều dễ bị bỏ qua nhất sau khi xử lý thành công một rủi ro lớn: cảm giác nhẹ nhõm khiến người ta quên rằng chính giải pháp vừa dùng có thể đã mở ra một cánh cửa mới.

Câu 426 Process
You work at an agricultural company that has traditionally relied on old-fashioned methods to fertilize the fields. However, the CEO has requested that you explore new methods to incorporate trending technologies to improve the company's efficiencies and production. Although the CEO is usually opposed to change, she has seen the value these technologies have brought to her competitors. Which of the following methodologies would be best used in this scenario?
  1. A Incremental
  2. B Iterative
  3. C Hybrid
  4. D Predictive/plan-driven
Xem giải thích

Đáp án

C — LAI (hybrid).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Công ty nông nghiệp dùng phương pháp TRUYỀN THỐNG lâu năm | ⚠ có quy trình ổn định cần giữ — phù hợp DỰ ĐOÁN | | ⚠ CEO muốn KHÁM PHÁ công nghệ mới | ⚠ bất định cao — phù hợp THÍCH ỨNG | | ⚠ CEO thường NGẠI THAY ĐỔI | ⚠ cần cách tiếp cận có kiểm soát, không thể agile toàn phần | | ⚠ Nhưng đã thấy giá trị ở đối thủ | ⚠ có động lực thật, không phải thử cho vui | | ⚠ Kết luận | ⚠ giữ phần vận hành ổn định theo DỰ ĐOÁN, thử công nghệ mới theo THÍCH ỨNG — đó là LAI |

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

  • B (lặp) — ⚠ phương án gây nhiễu mạnh nhất vì việc thử công nghệ mới đúng là cần lặp: ⚠ nhưng ⚠ lặp thuần tuý bỏ qua phần VẬN HÀNH TRUYỀN THỐNG vẫn phải chạy ổn định; ⚠ công ty không thể dừng bón phân để đi thử nghiệm — hai phần phải song song với hai cách quản lý khác nhau.

  • A (tăng dần) — ⚠ cùng lý do: ⚠ chỉ nói về cách giao sản phẩm, không giải quyết việc phải giữ hoạt động hiện có.

  • D (dự đoán / theo kế hoạch) — ⚠ không hợp với việc KHÁM PHÁ công nghệ chưa biết trước kết quả.

Ghi nhớ

⚠ Đối chiếu — bộ câu chọn cách tiếp cận nay lên TÁM câu: ⚠ #25972 lô 184 (nguyên mẫu), ⚠ #25974 (dự án bảy năm bất định → tư duy agile), ⚠ #25984 lô 185 (bàn giao tăng dần), ⚠ #25988 (xây nhà mẫu → dự đoán), ⚠ #26029 (giao giá trị nhanh → loại dự đoán), ⚠ #26131 lô 187 (thử nhiều kỹ thuật tiếp thị → lặp), ⚠ #26134 ở lô này (thử va chạm → lặp), ⚠ và câu này. ⚠ Đây là câu đầu tiên có khoá là LAI.

⚠ Khi nào chọn LAI: | Dấu hiệu | Nội dung | |---|---| | ⚠ Dự án có PHẦN RÕ và PHẦN CHƯA RÕ | ⚠ vận hành hiện tại rõ; công nghệ mới chưa rõ | | ⚠ Tổ chức chưa sẵn sàng chuyển đổi hoàn toàn | ⚠ đúng trường hợp CEO ngại thay đổi | | ⚠ Có ràng buộc bắt buộc phải theo quy trình cũ | ⚠ quy định, hợp đồng, an toàn | | ⚠ Cần vừa GIỮ ỔN ĐỊNH vừa ĐỔI MỚI | | | ⚠ Cách triển khai | ⚠ phần vận hành theo kế hoạch; phần thử nghiệm chạy theo vòng lặp ngắn, có ngân sách và thời hạn riêng | | ⚠ Lợi ích cho CEO ngại đổi | ⚠ rủi ro được KHOANH VÙNG — thất bại của thử nghiệm không ảnh hưởng hoạt động chính |

⚠ Bảng chọn cách tiếp cận — tổng hợp cả tám câu: | Điều kiện | Cách tiếp cận | Câu ví dụ | |---|---|---| | ⚠ Yêu cầu rõ, không giao từng phần được | ⚠ DỰ ĐOÁN | ⚠ #25988 | | ⚠ Cần thử để biết, làm lại cùng một thứ | ⚠ LẶP | ⚠ #26131, #26134 | | ⚠ Giao được từng phần dùng được | ⚠ TĂNG DẦN | ⚠ #25984 | | ⚠ Cả hai điều kiện trên | ⚠ AGILE | ⚠ #25974 | | ⚠ Có phần rõ và phần chưa rõ song song | ⚠ LAI | ⚠ #26148 (câu này) | | ⚠ Câu hỏi quyết định | ⚠ dự án có ĐỒNG NHẤT về mức bất định không? Nếu KHÔNG → LAI |

Từ khoá nhận diện:

"vừa giữ vận hành cũ vừa thử cái mới" → ⚠ lai "tổ chức chưa sẵn sàng đổi hoàn toàn" → ⚠ lai "thử đi thử lại cùng một thứ" → ⚠ lặp "giao từng phần dùng được" → ⚠ tăng dần

⚠ Triển khai lai cho công ty này thế nào Cách
⚠ Giữ nguyên quy trình bón phân hiện tại ⚠ không gián đoạn sản xuất
⚠ Chạy THỬ NGHIỆM trên một khu ruộng nhỏ ⚠ theo vòng lặp ngắn, đo kết quả
⚠ Đặt ngân sách và thời hạn RIÊNG cho phần thử nghiệm ⚠ liên hệ #25951 lô 184 — cấp vốn theo từng phần
⚠ Có tiêu chí rõ để quyết mở rộng hay dừng ⚠ liên hệ #26114 lô 187 — cổng giai đoạn
⚠ Báo cáo cho CEO bằng SỐ LIỆU so sánh ⚠ bà ấy đã thấy giá trị ở đối thủ — số liệu của chính công ty còn thuyết phục hơn
⚠ Vì sao cách này hợp với CEO ngại đổi ⚠ bà không phải cam kết thay đổi toàn bộ — chỉ cam kết cho một thử nghiệm có giới hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có phần nào bất định cao hơn hẳn phần khác không | ⚠ nếu có thì nên cân nhắc lai | | Phần thử nghiệm có ngân sách và tiêu chí dừng riêng không | | | Thất bại của thử nghiệm có ảnh hưởng hoạt động chính không | ⚠ nếu có thì chưa khoanh vùng đủ |

Và lý do cách tiếp cận lai thường là lựa chọn thực tế nhất trong tổ chức truyền thống: nó cho phép người ra quyết định thử điều mới mà không phải đặt cược toàn bộ những gì đang hoạt động tốt.

Câu 427 Process
During sprint planning, Stephen reviews the backlog at Queen Industries and places a few user stories in order based on priority. His method of ranking is most likely
  1. A Requirements prioritization
  2. B MoSCoW
  3. C 100-point method
  4. D Relative prioritization
Xem giải thích

Đáp án

D — XẾP ƯU TIÊN TƯƠNG ĐỐI (relative prioritization).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Stephen XẾP các user story THEO THỨ TỰ | ⚠ cái nào trước, cái nào sau | | ⚠ Dựa trên mức ưu tiên | | | ⚠ Không nhắc tới điểm số, không nhắc tới nhóm phân loại | ⚠ chỉ đơn thuần là THỨ TỰ | | ⚠ Định nghĩa | ⚠ xếp ưu tiên tương đối là sắp các hạng mục thành một DANH SÁCH CÓ THỨ TỰ, mỗi hạng mục được so với các hạng mục khác | | ⚠ Vì sao phù hợp với agile | ⚠ backlog vốn là một danh sách CÓ THỨ TỰ — đội luôn lấy hạng mục ở ĐẦU (liên hệ #26014 lô 185) |

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

  • B (MoSCoW) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là kỹ thuật xếp ưu tiên nổi tiếng: ⚠ nhưng MoSCoW ⚠ PHÂN LOẠI vào bốn NHÓM ⚠ (bắt buộc / nên có / có thì tốt / lần này không), ⚠ KHÔNG cho ra thứ tự tuyệt đối trong từng nhóm; ⚠ đề mô tả việc SẮP THEO THỨ TỰ, không phải chia nhóm.

  • C (phương pháp 100 điểm) — ⚠ phát điểm cho mọi người tự phân bổ ⚠ (liên hệ #26043 lô 186); ⚠ đề không nhắc tới việc cho điểm.

  • A (xếp ưu tiên yêu cầu — requirements prioritization) — ⚠ quá chung chung, ⚠ và trong PMI đó là tên một MÔ HÌNH cụ thể có bốn tiêu chí (liên hệ #26153 cùng lô).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26153 ở lô này (Mô hình xếp ưu tiên yêu cầu — lợi ích, hình phạt, chi phí, rủi ro) — ⚠ hai câu ở cùng lô về hai kỹ thuật khác nhau, dễ lẫn. ⚠ Xem thêm câu #26002 lô 185 (xếp hạng tuyệt đối), câu #26043 lô 186 (100 điểm), câu #26085 lô 187 (tiền chơi), và câu #26112 (mô hình Kano).

⚠ Các kỹ thuật xếp ưu tiên backlog — bảng tổng hợp: | Kỹ thuật | Cách làm | Kết quả | |---|---|---| | ⚠ XẾP ƯU TIÊN TƯƠNG ĐỐI | ⚠ so từng cặp, sắp thành danh sách có thứ tự | ⚠ một danh sách 1, 2, 3... — CÂU NÀY | | ⚠ MoSCoW | ⚠ chia vào bốn nhóm | ⚠ bốn nhóm, không có thứ tự trong nhóm | | ⚠ 100 ĐIỂM / TIỀN CHƠI | ⚠ mỗi người phân bổ điểm | ⚠ điểm số, cho biết MỨC ĐỘ ưu tiên | | ⚠ KANO | ⚠ phân loại theo tác động tới sự hài lòng | ⚠ cơ bản / thoả mãn / gây thích thú | | ⚠ WSJF | ⚠ chi phí trì hoãn chia quy mô | ⚠ điểm số để xếp thứ tự | | ⚠ MÔ HÌNH XẾP ƯU TIÊN YÊU CẦU | ⚠ chấm bốn tiêu chí | ⚠ liên hệ #26153 cùng lô | | ⚠ Điểm chung của mọi kỹ thuật tốt | ⚠ buộc phải ĐÁNH ĐỔI, không cho phép nói "cái nào cũng quan trọng" |

Từ khoá nhận diện:

"sắp theo thứ tự, cái nào trước cái nào sau" → ⚠ xếp ưu tiên tương đối "bắt buộc / nên có / có thì tốt" → ⚠ MoSCoW "phát điểm cho mỗi người" → ⚠ 100 điểm "lợi ích, hình phạt, chi phí, rủi ro" → ⚠ mô hình xếp ưu tiên yêu cầu

⚠ Vì sao backlog agile cần thứ tự TUYỆT ĐỐI Lý do
⚠ Đội luôn lấy hạng mục ở ĐẦU danh sách ⚠ liên hệ #26014 lô 185
⚠ Hai hạng mục cùng hạng thì đội không biết lấy cái nào
⚠ Buộc product owner phải quyết định thật ⚠ liên hệ #26002 lô 185 — "mọi việc đều ưu tiên cao" là không có ưu tiên nào
⚠ Đó là lý do ⚠ MoSCoW thường được dùng để SÀNG LỌC, rồi xếp thứ tự tuyệt đối trong nhóm "bắt buộc"
⚠ Xếp ưu tiên dựa trên gì Cơ sở
⚠ GIÁ TRỊ kinh doanh ⚠ liên hệ #25889 lô 183
⚠ RỦI RO — làm phần rủi ro cao trước ⚠ liên hệ #25912 lô 183 và #26024 lô 185
⚠ PHỤ THUỘC kỹ thuật
⚠ Chi phí trì hoãn
⚠ Thực tế ⚠ kết hợp nhiều tiêu chí, và PRODUCT OWNER là người chốt — liên hệ #26041 lô 186

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog của bạn có thứ tự tuyệt đối không | ⚠ hay có mười hạng mục cùng hạng "cao" | | Đội có biết vì sao hạng mục A đứng trên hạng mục B không | | | Ai là người chốt thứ tự | ⚠ phải là product owner |

Và điều làm nên giá trị của một backlog được xếp thứ tự tuyệt đối: đội không bao giờ phải hỏi "làm gì tiếp theo" — câu trả lời đã nằm sẵn ở dòng đầu tiên.

Câu 428 Process
Gabe is a project manager for an electrical organization seeking to switch to a cleaner energy source. The project is currently in its completion phase, and the organization is preparing to halt its use of fossil fuels. However, a wildfire runs rampant throughout the nearby field and causes over $1,000,000 of solar panel damage. Many customers report a power outage in their homes and submit these reports to the organization. Which of the associated terms best describes the scenario above?
  1. A Prevention costs
  2. B Appraisal costs
  3. C Internal failure costs
  4. D External failure costs
Xem giải thích

Đáp án

D — CHI PHÍ LỖI BÊN NGOÀI (external failure costs).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Tấm pin mặt trời hư hại hơn 1 triệu đô | ⚠ thiệt hại đã xảy ra | | ⚠ KHÁCH HÀNG bị MẤT ĐIỆN tại nhà | ⚠ từ khoá quyết định — vấn đề tới TAY KHÁCH HÀNG | | ⚠ Khách hàng gửi báo cáo về công ty | ⚠ khiếu nại sau khi dịch vụ đã được giao | | ⚠ Định nghĩa | ⚠ chi phí lỗi BÊN NGOÀI là chi phí phát sinh khi khiếm khuyết được phát hiện SAU KHI sản phẩm hoặc dịch vụ đã tới khách hàng | | ⚠ Ranh giới phân biệt | ⚠ khách hàng đã nhận hay chưa — đó là toàn bộ sự khác nhau giữa lỗi bên trong và bên ngoài |

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

  • C (chi phí lỗi bên trong) — ⚠ phương án gây nhiễu mạnh nhất vì chỉ khác một chữ: ⚠ nhưng lỗi bên trong là khiếm khuyết được phát hiện ⚠ TRƯỚC KHI giao cho khách hàng ⚠ — làm lại, phế phẩm trong xưởng; ⚠ ở đây khách hàng đã bị ảnh hưởng thật.

  • A (chi phí phòng ngừa) — ⚠ chi TRƯỚC để NGĂN lỗi: ⚠ đào tạo, quy trình, thiết bị tốt (liên hệ #25924 lô 183).

  • B (chi phí thẩm định) — ⚠ chi để PHÁT HIỆN lỗi: ⚠ kiểm thử, thanh tra, đo lường.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25924 ở lô 183 (đào tạo an toàn = chi phí PHÙ HỢP với chất lượng) — ⚠ hai câu là hai nửa của cùng một mô hình: câu đó về nhóm PHÙ HỢP, câu này về nhóm KHÔNG PHÙ HỢP. ⚠ Xem thêm câu #26119 lô 187 (kế hoạch quản lý chất lượng), câu #26124 (kiểm toán chất lượng), và câu #26127 (công cụ kiểm soát chất lượng).

⚠ BỐN NHÓM CHI PHÍ CHẤT LƯỢNG — bảng đầy đủ: | Nhóm | Loại | Nội dung | Ví dụ | |---|---|---|---| | ⚠ PHÒNG NGỪA | ⚠ PHÙ HỢP | ⚠ chi để NGĂN lỗi xảy ra | ⚠ đào tạo, quy trình, thiết bị chuẩn — #25924 lô 183 | | ⚠ THẨM ĐỊNH | ⚠ PHÙ HỢP | ⚠ chi để PHÁT HIỆN lỗi | ⚠ kiểm thử, thanh tra, đo lường | | ⚠ LỖI BÊN TRONG | ⚠ KHÔNG PHÙ HỢP | ⚠ phát hiện TRƯỚC khi giao | ⚠ làm lại, phế phẩm | | ⚠ LỖI BÊN NGOÀI | ⚠ KHÔNG PHÙ HỢP | ⚠ phát hiện SAU khi giao — CÂU NÀY | ⚠ bảo hành, thu hồi, kiện tụng, mất uy tín | | ⚠ Quy luật kinh tế | ⚠ chi phí tăng theo CẤP SỐ NHÂN khi lỗi được phát hiện muộn hơn | | ⚠ Con số kinh điển | ⚠ 1 đồng phòng ngừa ≈ 10 đồng sửa nội bộ ≈ 100 đồng khi tới khách hàng |

Từ khoá nhận diện:

"khách hàng bị ảnh hưởng, khiếu nại, bảo hành" → ⚠ lỗi bên ngoài "làm lại, phế phẩm trong xưởng" → ⚠ lỗi bên trong "đào tạo, quy trình, làm đúng ngay từ đầu" → ⚠ phòng ngừa "kiểm thử, thanh tra" → ⚠ thẩm định ⚠ Mốc phân chia giữa hai loại lỗi → ⚠ khách hàng đã nhận hay chưa

⚠ Vì sao lỗi bên ngoài đắt nhất Lý do
⚠ Chi phí sửa chữa và bồi thường trực tiếp ⚠ hơn 1 triệu đô tấm pin
⚠ Chi phí xử lý khiếu nại và hỗ trợ khách hàng
⚠ MẤT UY TÍN — không đo được nhưng thiệt hại lớn nhất
⚠ Có thể mất khách hàng vĩnh viễn
⚠ Rủi ro pháp lý và quy định ⚠ liên hệ #25962 lô 184
⚠ Đặc biệt với ngành điện ⚠ mất điện ảnh hưởng trực tiếp tới sinh hoạt — mức nhạy cảm rất cao
⚠ Lưu ý: cháy rừng là THIÊN TAI, sao vẫn tính là chi phí lỗi Giải thích
⚠ Câu hỏi hỏi thuật ngữ mô tả HẬU QUẢ, không hỏi nguyên nhân
⚠ Khách hàng đã bị ảnh hưởng sau khi dịch vụ được cung cấp ⚠ đó là điều kiện đủ để gọi là lỗi bên ngoài
⚠ Về quản lý rủi ro, cháy rừng là RỦI RO THUẦN ⚠ liên hệ #26037 lô 186 — chỉ có mặt xấu, và là loại DỄ BẢO HIỂM nhất
⚠ Bài học ⚠ rủi ro thiên tai với hạ tầng ngoài trời phải được CHUYỂN GIAO qua bảo hiểm — liên hệ #26040 lô 186
⚠ Câu hỏi cho Gabe ⚠ dự án đã có kế hoạch dự phòng cho sự kiện thời tiết cực đoan chưa?

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đo chi phí chất lượng theo bốn nhóm không | ⚠ rất ít tổ chức làm | | Chi phí lỗi bên ngoài năm ngoái là bao nhiêu | ⚠ con số này thuyết phục hơn mọi lập luận về đầu tư phòng ngừa | | Đầu tư phòng ngừa có bị cắt đầu tiên khi ngân sách căng không | |

Và lý do bốn nhóm chi phí này đáng đo dù không ai bắt buộc: chúng cho thấy tiền tiết kiệm được ở khâu phòng ngừa luôn quay lại đòi, và luôn đòi ở nhóm đắt nhất.

Câu 429 People
You are a project management consultant to the DWD Project. The team on the project is concerned about stakeholder identification and stakeholder management, and they want to define the roles and responsibilities for stakeholder management. Who identifies project stakeholders and determines their requirements for the project?
  1. A The project sponsor
  2. B The project champion
  3. C The project team
  4. D Influencers
Xem giải thích

Đáp án

C — ĐỘI DỰ ÁN.

Vì sao đúng

⚠ Vì sao đội dự án chịu trách nhiệm việc này: | Lý do | Nội dung | |---|---| | ⚠ Nhận diện bên liên quan là một QUY TRÌNH của dự án | ⚠ do đội dự án thực hiện, dẫn dắt bởi quản lý dự án | | ⚠ Xác định YÊU CẦU của họ cũng là việc của đội | ⚠ thu thập yêu cầu là quy trình quản lý phạm vi | | ⚠ Đội có bối cảnh và tiếp xúc trực tiếp | | | ⚠ Đây là công việc LẶP LẠI suốt dự án, không phải một lần | ⚠ liên hệ #26090 lô 187 — bên liên quan mới thì cập nhật sổ đăng ký | | ⚠ Lưu ý về thuật ngữ | ⚠ "đội dự án" bao gồm cả QUẢN LÝ DỰ ÁN — nên đây là câu trả lời bao trùm nhất |

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

  • A (nhà tài trợ) — ⚠ phương án gây nhiễu mạnh nhất vì nhà tài trợ ĐÚNG LÀ nguồn thông tin quan trọng: ⚠ điều lệ dự án ⚠ có liệt kê bên liên quan ban đầu; ⚠ nhưng ông ta ⚠ CUNG CẤP đầu vào, không THỰC HIỆN việc nhận diện và phân tích liên tục.

  • B (người bảo trợ dự án — project champion) — ⚠ người ủng hộ và quảng bá dự án trong tổ chức; ⚠ hữu ích nhưng không phải người thực hiện quy trình.

  • D (người có ảnh hưởng) — ⚠ họ LÀ một nhóm bên liên quan ⚠ (liên hệ #25973 lô 184), ⚠ không phải người đi nhận diện.

Ghi nhớ

⚠ Đối chiếu — nhóm bên liên quan nay lên MƯỜI BẢY câu: ⚠ #25895 lô 183, ⚠ #25949, #25961, #25973 lô 184, ⚠ #26044, #26046, #26056, #26062, #26073, #26074 lô 186, ⚠ #26090, #26117 lô 187, ⚠ #26139 ở lô này, ⚠ và câu này. ⚠ Chủ đề dày nhất tuyệt đối của bộ đề PMP Set I.

⚠ Ai làm gì trong quản lý bên liên quan: | Vai | Vai trò | |---|---| | ⚠ ĐỘI DỰ ÁN (gồm PM) | ⚠ NHẬN DIỆN, PHÂN TÍCH, gắn kết, thu thập yêu cầu — CÂU NÀY | | ⚠ NHÀ TÀI TRỢ | ⚠ cung cấp danh sách ban đầu trong điều lệ, gỡ vướng ở cấp cao | | ⚠ NGƯỜI BẢO TRỢ (champion) | ⚠ quảng bá và bảo vệ dự án trong tổ chức | | ⚠ PMO | ⚠ cung cấp mẫu, tài sản quy trình, bài học từ dự án trước | | ⚠ BÊN LIÊN QUAN ĐÃ BIẾT | ⚠ giúp chỉ ra bên liên quan CHƯA BIẾT — kỹ thuật "quả cầu tuyết" | | ⚠ Điểm quan trọng | ⚠ nhận diện phải LẶP LẠI ở mỗi giai đoạn — danh sách luôn thay đổi (liên hệ #26090 lô 187) |

Từ khoá nhận diện:

"ai nhận diện và phân tích bên liên quan" → ⚠ đội dự án "ai ban hành điều lệ và cấp danh sách ban đầu" → ⚠ nhà tài trợ "ai quảng bá dự án" → ⚠ người bảo trợ "người có ảnh hưởng" → ⚠ một NHÓM bên liên quan, không phải người đi nhận diện

⚠ Kỹ thuật nhận diện bên liên quan Kỹ thuật
⚠ Rà soát ĐIỀU LỆ và tài liệu dự án
⚠ Phỏng vấn bên liên quan đã biết ⚠ hỏi "còn ai bị ảnh hưởng nữa không?"
⚠ Động não trong đội
⚠ Rà sơ đồ tổ chức và danh sách hợp đồng
⚠ Xem BÀI HỌC từ dự án tương tự ⚠ liên hệ #26035 lô 186
⚠ Quét PESTLE để tìm bên liên quan bên ngoài ⚠ cơ quan quản lý, cộng đồng — liên hệ #26111 lô 187
⚠ Sai lầm phổ biến ⚠ chỉ liệt kê người trong sơ đồ tổ chức, bỏ sót bên ngoài (liên hệ #26133 cùng lô — nhóm người bản địa)
⚠ Vì sao "xác định yêu cầu của họ" cũng thuộc đội Lý do
⚠ Nhận diện được người mà không biết họ cần gì thì vô ích
⚠ Yêu cầu là đầu vào của TUYÊN BỐ PHẠM VI ⚠ liên hệ #26039 lô 186 — phân tích sản phẩm
⚠ Đội là bên duy nhất có thể chuyển yêu cầu thành công việc
⚠ Công cụ ⚠ SỔ ĐĂNG KÝ BÊN LIÊN QUAN ghi cả định danh, đánh giá và YÊU CẦU CHÍNH của từng người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai trong đội bạn phụ trách sổ đăng ký bên liên quan | | | Bạn có hỏi bên liên quan đã biết về những người khác không | ⚠ kỹ thuật rẻ và hiệu quả nhất | | Danh sách được rà lại ở mỗi giai đoạn chưa | |

Và lý do việc này không thể giao cho một mình nhà tài trợ: ông ta biết ai QUAN TRỌNG, còn đội mới biết ai BỊ ẢNH HƯỞNG — và hai danh sách đó không bao giờ trùng nhau hoàn toàn.

Câu 430 People
Mike is a scrum master for Project J, which is on its fifth iteration. During a recent sprint, he noticed Cassie, a junior developer, helping a team member who struggled with a specific deliverable. The deliverable was then submitted on time. What should Mike do next?
  1. A Do nothing. Team members are expected to help each other.
  2. B Call out Cassie's behavior as something for the team to model at the next retrospective.
  3. C Privately speak with the team member Cassie and thank her for helping the other team member with their performance.
  4. D Call out Cassie's behavior as something for the team to model at the next daily standup.
Xem giải thích

Đáp án

B — NÊU HÀNH VI CỦA CASSIE Ở RETROSPECTIVE tiếp theo như một hình mẫu để cả đội noi theo.

Vì sao đúng

⚠ Vì sao nêu công khai ở retrospective là đúng: | Lý do | Nội dung | |---|---| | ⚠ Hành vi TỐT cần được GHI NHẬN CÔNG KHAI | ⚠ khen công khai, góp ý riêng tư | | ⚠ Retrospective là nơi rà soát CÁCH LÀM VIỆC | ⚠ kể cả điều đã làm tốt, không chỉ điều cần sửa | | ⚠ Biến một hành vi cá nhân thành CHUẨN MỰC của đội | ⚠ đó là mục đích thật | | ⚠ Củng cố tinh thần tương trợ và sở hữu tập thể | | | ⚠ Nhắc lại nguyên tắc | ⚠ retrospective KHÔNG chỉ để tìm cái sai — liên hệ #26141 cùng lô, bài học gồm cả cái LÀM TỐT |

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

  • C (nói riêng với Cassie để cảm ơn) — ⚠ phương án gây nhiễu mạnh nhất vì cảm ơn riêng là việc tử tế và nên làm: ⚠ nhưng nó ⚠ CHỈ tác động tới một người ⚠ — ⚠ cả đội không học được gì; ⚠ mục tiêu là lan toả hành vi, không chỉ thưởng cho cá nhân.

  • D (nêu ở buổi standup hằng ngày) — ⚠ SAI BUỔI HỌP: ⚠ daily scrum 15 phút chỉ để đồng bộ và nêu vật cản ⚠ (liên hệ #25921 lô 183).

  • A (không làm gì, thành viên vốn phải giúp nhau) — ⚠ bỏ lỡ cơ hội củng cố hành vi tốt; ⚠ điều gì được ghi nhận thì được lặp lại.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25952 ở lô 184 (Carol bảo đảm thành viên được ghi nhận công sức → lãnh đạo phục vụ), câu #26145 ở lô này (Brad tự nhận lỗi ở retrospective), câu #26140 (ý kiến bị gạt trong retrospective), và câu #25930 lô 183 (thuyết kỳ vọng — phần thưởng phải là thứ người đó coi trọng). ⚠ Nhóm ghi nhận và động lực.

⚠ Nguyên tắc "khen công khai, góp ý riêng tư": | Tình huống | Cách xử lý | Câu ví dụ | |---|---|---| | ⚠ Hành vi TỐT đáng lan toả | ⚠ nêu CÔNG KHAI | ⚠ #26152 (câu này) | | ⚠ Sai sót của một cá nhân | ⚠ nói RIÊNG | ⚠ #26106 lô 187 — nhắc riêng người chưa cập nhật | | ⚠ Sai sót của chính người dẫn dắt | ⚠ nêu CÔNG KHAI | ⚠ #26145 cùng lô — Brad tự nhận | | ⚠ Vấn đề hệ thống nhiều người mắc | ⚠ đưa ra retrospective cho cả đội bàn | | | ⚠ Nguyên tắc nền | ⚠ công khai điều muốn NHÂN RỘNG; riêng tư điều muốn SỬA |

Từ khoá nhận diện:

"hành vi tốt đáng noi theo" → ⚠ nêu công khai ở retrospective "cảm ơn riêng" → ⚠ tử tế nhưng không lan toả "nêu ở daily standup" → ⚠ sai buổi họp "không làm gì vì đó là chuyện đương nhiên" → ⚠ bỏ lỡ cơ hội củng cố

⚠ Vì sao hành vi của Cassie đáng nêu Lý do
⚠ Cô là LẬP TRÌNH VIÊN TRẺ mà chủ động giúp người khác ⚠ không phải việc được giao
⚠ Kết quả cụ thể: bàn giao nộp ĐÚNG HẠN ⚠ có bằng chứng, không phải lời khen chung chung
⚠ Thể hiện tinh thần SỞ HỮU TẬP THỂ ⚠ cả đội cùng chịu trách nhiệm hoàn thành sprint
⚠ Là cách lan toả kỹ năng trong đội ⚠ liên hệ #25928 lô 183 — chuyên gia đa năng
⚠ Điểm quan trọng ⚠ nêu HÀNH VI và KẾT QUẢ, không chỉ khen tên người — để đội hiểu chính xác điều gì đáng noi theo
⚠ Ghi nhận thế nào cho hiệu quả Cách
⚠ CỤ THỂ: nêu rõ làm gì, và kết quả ra sao ⚠ "Cassie giúp bạn X gỡ vướng, nhờ đó hạng mục Y nộp đúng hạn"
⚠ KỊP THỜI: nêu ngay ở retrospective gần nhất
⚠ Đặt câu hỏi cho đội: làm sao để điều này xảy ra thường xuyên hơn ⚠ biến ghi nhận thành cải tiến
⚠ Không biến thành cuộc thi hay xếp hạng ⚠ so sánh cá nhân phá vỡ tinh thần đội
⚠ Cẩn thận với người ngại được chú ý ⚠ có người thấy khó chịu khi được khen trước đám đông — hỏi trước nếu không chắc (liên hệ #25968 lô 184)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retrospective của đội bạn có nói về điều đã LÀM TỐT không | ⚠ hay chỉ liệt kê vấn đề | | Lần cuối bạn ghi nhận công khai một hành vi là khi nào | | | Hành vi được khen có được lặp lại không | ⚠ thước đo duy nhất của việc ghi nhận có tác dụng |

Và lý do một lời ghi nhận đúng chỗ lại đáng giá hơn nhiều so với vẻ ngoài của nó: nó không thưởng cho việc đã xảy ra, mà mua thêm những lần tương tự trong tương lai.