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

Tìm thấy 718 câu.

Câu 31 Process
Judith is a product owner who wants to use a collaboration game to plan her product’s features and functionality. She aims to make sure the team thinks through the significant features and dependencies and then maps them into major functional areas. The best choice for her is
  1. A Remember the Future
  2. B Planning Poker
  3. C Simple Prioritization
  4. D Prune the Product Tree
Xem giải thích

Đáp án

D — TỈA CÂY SẢN PHẨM (Prune the Product Tree).

Vì sao đúng

⚠ Vì sao trò này khớp với mục tiêu của Judith: | Yêu cầu trong đề | Cách trò chơi đáp ứng | |---|---| | ⚠ Nghĩ thấu đáo các TÍNH NĂNG quan trọng | ⚠ mỗi tính năng là một chiếc lá dán lên cây | | ⚠ Nhìn ra các PHỤ THUỘC | ⚠ lá mọc trên cành, cành mọc từ thân — cấu trúc cây thể hiện quan hệ | | ⚠ Nhóm vào các MẢNG CHỨC NĂNG lớn | ⚠ mỗi CÀNH LỚN là một mảng chức năng — đúng trọng tâm câu hỏi | | ⚠ Là TRÒ CHƠI CỘNG TÁC | ⚠ do Luke Hohmann đưa ra trong bộ "Innovation Games" | | ⚠ Còn cho thấy sự CÂN ĐỐI của sản phẩm | ⚠ cành nào quá rậm, cành nào trơ trụi — nhìn là thấy ngay | | ⚠ Kết luận | ⚠ trò duy nhất trong bốn phương án tạo ra một CẤU TRÚC PHÂN CẤP của tính năng |

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

  • A (REMEMBER THE FUTURE — nhớ về tương lai) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là một trò chơi cộng tác thật của cùng bộ Innovation Games, cũng dùng để khám phá tính năng: ⚠ nhưng ⚠ nó hỏi "sáu tháng nữa nhìn lại, sản phẩm đã làm được gì khiến bạn hài lòng?" ⚠ — mục đích là khơi ra KỲ VỌNG và định nghĩa thành công, ⚠ không tạo ra cấu trúc phân cấp và không thể hiện phụ thuộc; ⚠ đề đòi cả ba việc, nên chỉ Tỉa cây sản phẩm đáp ứng đủ.

  • B (PLANNING POKER) — ⚠ kỹ thuật ƯỚC LƯỢNG công sức, không phải để khám phá và sắp xếp tính năng.

  • C (xếp ưu tiên đơn giản) — ⚠ là bước SAU: ⚠ phải có tính năng và cấu trúc rồi mới xếp được thứ tự.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26445 cùng lô (kỹ thuật nhóm danh nghĩa), ⚠ #26440 cùng lô (thu ý kiến riêng rồi họp lại), ⚠ #26464 cùng lô (xếp hạng tuyệt đối), ⚠ #26471 cùng lô (rà soát rủi ro trước khi xếp ưu tiên), ⚠ #26463 cùng lô (tầm nhìn sản phẩm).

⚠ Bộ TRÒ CHƠI CỘNG TÁC hay gặp trong đề PMP: | Trò | Dùng để | Cách chơi | |---|---|---| | ⚠ TỈA CÂY SẢN PHẨM | ⚠ khám phá và CẤU TRÚC HOÁ tính năng | ⚠ vẽ cây, dán lá là tính năng lên cành là mảng chức năng | | ⚠ NHỚ VỀ TƯƠNG LAI | ⚠ khơi kỳ vọng, định nghĩa thành công | ⚠ "sáu tháng nữa, điều gì khiến bạn nói dự án đã thành công?" | | ⚠ MUA MỘT TÍNH NĂNG | ⚠ XẾP ƯU TIÊN bằng nguồn lực hữu hạn | ⚠ mỗi người có tiền giả để "mua" tính năng mình muốn | | ⚠ TÀU TỐC HÀNH | ⚠ lấy phản hồi về sản phẩm hiện có | ⚠ viết bưu thiếp cho một người bạn về sản phẩm | | ⚠ HỘP SẢN PHẨM | ⚠ làm rõ điểm bán hàng cốt lõi | ⚠ thiết kế vỏ hộp: đâu là ba dòng chữ trên nắp | | ⚠ Điểm chung | ⚠ tất cả đều chuyển một cuộc thảo luận trừu tượng thành một việc làm bằng tay có hình ảnh — nhờ vậy người ít nói cũng tham gia được, liên hệ #26445 cùng lô | |

⚠ Chơi Tỉa cây sản phẩm như thế nào: | Bước | Nội dung | |---|---| | ⚠ 1. Vẽ một cái cây lớn lên tường | ⚠ thân = sản phẩm lõi hiện có, cành lớn = các mảng chức năng | | ⚠ 2. Mỗi người viết tính năng lên giấy dán hình chiếc lá | | | ⚠ 3. Dán lá lên cành mà nó thuộc về | ⚠ bước này bộc lộ phụ thuộc và chỗ chưa có mảng nào phù hợp | | ⚠ 4. Nhìn hình dáng cây | ⚠ cành rậm = đầu tư nhiều; cành trụi = mảng bị bỏ quên | | ⚠ 5. TỈA — bỏ bớt lá không cần | ⚠ đúng như tên gọi: mục đích là bỏ đi, không chỉ thêm vào | | ⚠ Vì sao ẩn dụ cái cây hiệu quả | ⚠ nó khiến việc BỎ BỚT trở thành hành động lành mạnh và tự nhiên, thay vì một mất mát — tỉa cành là để cây khoẻ hơn |

⚠ Vì sao chủ sản phẩm cần công cụ nhóm chứ không tự làm một mình: | Lý do | Nội dung | |---|---| | ⚠ Phụ thuộc kỹ thuật chỉ đội mới biết | | | ⚠ Tính năng bị bỏ sót thường nằm ở góc nhìn người khác | ⚠ liên hệ #26447 cùng lô — giá trị của đa dạng | | ⚠ Người tham gia tạo ra thì sẽ cam kết với kết quả | ⚠ liên hệ #26460 cùng lô — công bằng trong SCARF | | ⚠ Hình ảnh chung dễ nhớ hơn một danh sách | | | ⚠ Điều trò chơi KHÔNG thay thế | ⚠ quyền quyết định cuối cùng của chủ sản phẩm — trò chơi tạo ra đầu vào và sự đồng thuận, không tạo ra một cuộc bỏ phiếu |

Từ khoá nhận diện:

"nghĩ ra tính năng, phụ thuộc, nhóm vào mảng chức năng" → ⚠ TỈA CÂY SẢN PHẨM "hình dung tương lai, định nghĩa thành công" → ⚠ nhớ về tương lai "ước lượng công sức" → ⚠ planning poker "xếp thứ tự" → ⚠ bước sau, cần đã có danh sách tính năng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách tính năng của bạn có cấu trúc hay chỉ là một danh sách phẳng | | | Có mảng chức năng nào đang trơ trụi không | ⚠ thường là mảng vận hành, bảo mật, hoặc trải nghiệm quản trị | | Buổi lập kế hoạch gần nhất của bạn có ai im lặng suốt không | ⚠ trò chơi cộng tác sinh ra chính vì lý do đó |

Và điều mà cái cây làm được còn bảng tính thì không: nó khiến cả nhóm nhìn thấy sản phẩm của mình MẤT CÂN ĐỐI ở đâu, trước khi khách hàng phải là người chỉ ra điều đó.

Câu 32 Process
Kyle is the project manager for a virtual team at a global online shopping company. He works with a virtual team based in several different countries, none of which have English as a primary language. After working with the team for over a month, Kyle finds it challenging to convey his thoughts through email. Although Kyle has typed out very detailed instructions for what he wants to be done, his teammates are not responding to his queries. Which of the following 5Cs of communication best describes which technique Kyle is not following?
  1. A A coherent, logical flow of ideas
  2. B A controlled flow of words and ideas
  3. C Concise expression and elimination of excessive words
  4. D Correct grammar and spelling
Xem giải thích

Đáp án

C — SÚC TÍCH: diễn đạt gọn, loại bỏ những từ thừa (concise).

Vì sao đúng

⚠ Vì sao đây là chữ C mà Kyle đang thiếu: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Kyle viết "hướng dẫn RẤT CHI TIẾT" | ⚠ chi tiết quá mức là biểu hiện điển hình của thiếu súc tích | | ⚠ Đội KHÔNG PHẢN HỒI | ⚠ không phải họ không muốn — họ không vượt nổi bức tường chữ | | ⚠ Không ai trong đội dùng tiếng Anh làm ngôn ngữ chính | ⚠ email dài với người đọc bằng ngôn ngữ thứ hai là gánh nặng nhân đôi | | ⚠ Đề không nói email lộn xộn hay sai chính tả | ⚠ nên ba chữ C kia không có căn cứ | | ⚠ Kết luận | ⚠ vấn đề là ĐỘ DÀI và lượng từ thừa, đúng định nghĩa của súc tích |

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

  • A (MẠCH LẠC — dòng ý tưởng có logic) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ một email quá dài thường cũng khó theo dõi, nên nghe như thiếu mạch lạc: ⚠ nhưng ⚠ đề nói Kyle viết "rất chi tiết", không nói viết lộn xộn ⚠ — mạch lạc nói về THỨ TỰ và LOGIC của ý, súc tích nói về SỐ LƯỢNG chữ; ⚠ một văn bản có thể rất mạch lạc mà vẫn dài gấp ba lần cần thiết.

  • B (KIỂM SOÁT — dòng từ ngữ và ý tưởng được điều tiết) — ⚠ nói về nhịp độ và lượng thông tin đưa ra mỗi lần, ⚠ gần nhưng vẫn không trúng bằng súc tích.

  • D (ĐÚNG NGỮ PHÁP VÀ CHÍNH TẢ) — ⚠ đề hoàn toàn không nhắc tới lỗi ngữ pháp nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26444 cùng lô (truyền phát thông tin), ⚠ #26316 lô 191 (khác biệt văn hoá), ⚠ #26421/#26366 (công cụ cho đội phân tán), ⚠ #26467 cùng lô (cùng chỗ và phân tán), ⚠ #26450 cùng lô (lắng nghe chủ động).

⚠ NĂM CHỮ C CỦA GIAO TIẾP VIẾT (5Cs) — bảng đầy đủ: | Chữ C | Nghĩa | Vi phạm khi | |---|---|---| | ⚠ CORRECT — ĐÚNG | ⚠ ngữ pháp và chính tả chuẩn | ⚠ sai chính tả làm giảm uy tín người viết | | ⚠ CONCISE — SÚC TÍCH | ⚠ gọn, không từ thừa | ⚠ email dài không ai đọc hết — câu này | | ⚠ CLEAR — RÕ RÀNG | ⚠ đúng mục đích, đúng người nhận | ⚠ người đọc không biết mình cần làm gì | | ⚠ COHERENT — MẠCH LẠC | ⚠ ý nối ý theo trình tự logic | ⚠ nhảy chủ đề, không có mở–thân–kết | | ⚠ CONTROLLED — KIỂM SOÁT | ⚠ dòng thông tin được điều tiết | ⚠ dội quá nhiều thứ cùng lúc | | ⚠ Mẹo nhớ | ⚠ năm chữ C đều mô tả VĂN BẢN VIẾT — chúng là tiêu chuẩn cho email, báo cáo, tài liệu, không phải cho hội thoại | |

⚠ Vì sao súc tích đặc biệt quan trọng với đội đa ngôn ngữ: | Lý do | Nội dung | |---|---| | ⚠ Đọc bằng ngôn ngữ thứ hai tốn nhiều công hơn nhiều | ⚠ mỗi câu thừa là một chi phí thật cho người đọc | | ⚠ Câu dài, mệnh đề lồng nhau rất dễ hiểu sai | | | ⚠ Người đọc ngại hỏi lại vì sợ lộ ra mình chưa hiểu | ⚠ liên hệ #26469 cùng lô — thiếu lòng tin khiến người ta im lặng | | ⚠ Im lặng bị hiểu nhầm là đã hiểu hoặc là thờ ơ | ⚠ đúng điều đang xảy ra với Kyle | | ⚠ Điều Kyle nên làm | ⚠ email ngắn với một yêu cầu rõ ràng ở đầu, gạch đầu dòng, câu ngắn — và bổ sung một cuộc gọi ngắn cho phần phức tạp, vì văn bản không phải kênh phù hợp cho mọi thứ |

⚠ Chữa một email quá dài — danh sách kiểm tra: | Việc | Nội dung | |---|---| | ⚠ Đưa YÊU CẦU lên câu đầu tiên | ⚠ người đọc biết ngay họ cần làm gì | | ⚠ Một email = một chủ đề | ⚠ ba chủ đề trong một email thì hai chủ đề sẽ bị bỏ quên | | ⚠ Dùng gạch đầu dòng thay đoạn văn | | | ⚠ Ghi rõ hạn và người chịu trách nhiệm | | | ⚠ Câu ngắn, từ thông dụng, tránh thành ngữ | ⚠ thành ngữ là thứ khó nhất với người nói ngôn ngữ khác | | ⚠ Phép thử nhanh | ⚠ nếu phải cuộn màn hình mới đọc hết thì nội dung đó không thuộc về email — nó thuộc về một tài liệu có link, hoặc một cuộc gọi |

Từ khoá nhận diện:

"hướng dẫn rất chi tiết mà không ai phản hồi" → ⚠ thiếu SÚC TÍCH "lộn xộn, nhảy chủ đề" → ⚠ thiếu mạch lạc "sai chính tả, sai ngữ pháp" → ⚠ thiếu đúng đắn "dội quá nhiều thông tin một lúc" → ⚠ thiếu kiểm soát

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Email dài nhất bạn gửi tuần này có bao nhiêu chữ | ⚠ và có bao nhiêu người trả lời nó | | Yêu cầu của bạn nằm ở dòng thứ mấy | ⚠ nằm ở cuối thì phần lớn người đọc không thấy | | Đội bạn có ai đang đọc bằng ngôn ngữ thứ hai không | ⚠ nếu có, mọi tiêu chuẩn về độ dài phải chặt hơn |

Và điều mà sự im lặng của đội Kyle đang nói: không phải "chúng tôi không quan tâm", mà là "chúng tôi chưa đọc xong" — và giữa hai câu đó là toàn bộ khác biệt trong cách anh nên sửa.

Câu 33 People
RTC Corporation has hired Ben as a project manager in an agile-predictive hybrid environment. Ben has discovered that multiple processes are delaying product deployments up to six weeks. As a servant leader, he must make decisions that will prevent bottleneck processes. What options could Ben develop that would allow the resolution of these impediments?
  1. A Work with process auditors to find ways to refine, simplify or remove unneeded processes that hinder product deployment.
  2. B Completely do away with the current processes and develop new policies to resolve process time and project completion more effectively.
  3. C Tell stakeholders that there have been no options found, and to deploy a quality product, they must settle for the delay.
  4. D Have team members add more product development to their tasks allowing for more options to present to stakeholders.
Xem giải thích

Đáp án

A — Làm việc với KIỂM TOÁN VIÊN QUY TRÌNH để tìm cách tinh gọn, đơn giản hoá hoặc LOẠI BỎ những quy trình không cần thiết đang cản trở việc triển khai.

Vì sao đúng

⚠ Vì sao đây là hành động của một nhà lãnh đạo phục vụ: | Đặc điểm | Nội dung | |---|---| | ⚠ Nhắm vào ĐÚNG nguyên nhân: quy trình gây tắc nghẽn | ⚠ không đổ lỗi cho người | | ⚠ Làm việc CÙNG người có thẩm quyền về quy trình | ⚠ kiểm toán viên là người hiểu quy trình nào bắt buộc, quy trình nào chỉ là thói quen | | ⚠ Ba lựa chọn theo mức độ tăng dần: tinh chỉnh → đơn giản hoá → loại bỏ | ⚠ thận trọng, có kiểm soát | | ⚠ GỠ VẬT CẢN cho đội chính là việc của lãnh đạo phục vụ | ⚠ liên hệ #26434 cùng lô — nhà tài trợ gỡ vật cản | | ⚠ Môi trường lai agile–dự đoán vẫn cần một số quy trình | ⚠ nên "tinh gọn" đúng hơn "xoá sạch" | | ⚠ Kết luận | ⚠ giải quyết tận gốc mà không phá vỡ khung quản trị |

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

  • B (BỎ HOÀN TOÀN quy trình hiện tại và xây chính sách mới) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng nhắm đúng vào quy trình và nghe rất "agile", rất dứt khoát: ⚠ nhưng ⚠ "bỏ hoàn toàn" là hành động cực đoan và rất rủi ro ⚠ — trong môi trường có yêu cầu tuân thủ, một số quy trình tồn tại vì luật, không vì thói quen; ⚠ và Ben chưa phân tích quy trình nào thừa, quy trình nào cần; ⚠ cải tiến gia tăng có kiểm soát luôn thắng cách mạng mù quáng trong đề PMP.

  • C (nói với bên liên quan rằng không có phương án nào, phải chấp nhận trễ) — ⚠ đầu hàng; ⚠ trái hẳn với vai trò lãnh đạo phục vụ và với chính câu hỏi ("phương án nào Ben CÓ THỂ xây dựng").

  • D (bảo đội gánh thêm việc phát triển để có thêm phương án trình bày) — ⚠ chất thêm việc lên đội đang bị tắc; ⚠ hiểu sai hoàn toàn cả vấn đề lẫn vai trò.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26434 cùng lô (nhà tài trợ gỡ vật cản), ⚠ #26336/#26304 lô 191 (vật cản so với trở ngại), ⚠ #26472 cùng lô (điều chỉnh quy trình theo quy mô), ⚠ #26452 cùng lô (yêu cầu tuân thủ), ⚠ #26457 cùng lô (kiểm toán chất lượng).

⚠ LÃNH ĐẠO PHỤC VỤ làm gì: | Việc | Nội dung | |---|---| | ⚠ GỠ VẬT CẢN cho đội | ⚠ việc trung tâm — đúng tình huống này | | ⚠ Bảo vệ đội khỏi gián đoạn từ bên ngoài | | | ⚠ Tạo môi trường để đội tự tổ chức | ⚠ liên hệ #26460 cùng lô | | ⚠ Hỏi "đội cần gì" thay vì ra lệnh "làm cái này" | | | ⚠ Phát triển năng lực cho từng người | ⚠ liên hệ #26449 cùng lô — đào tạo | | ⚠ Điều lãnh đạo phục vụ KHÔNG làm | ⚠ chất thêm việc để "có thêm lựa chọn" — phương án D là bức tranh phản diện chính xác của vai trò này |

⚠ Xử lý quy trình gây tắc nghẽn — cách làm có kỷ luật: | Bước | Nội dung | |---|---| | ⚠ 1. ĐO thời gian thực tế ở từng bước | ⚠ sáu tuần trễ nằm ở đâu — không đo thì chỉ đoán | | ⚠ 2. Phân loại: bắt buộc do luật / do chính sách / do thói quen | ⚠ ba loại này xử lý hoàn toàn khác nhau | | ⚠ 3. Với loại BẮT BUỘC: tìm cách làm SONG SONG hoặc sớm hơn | ⚠ không bỏ được thì đổi vị trí trong dòng chảy | | ⚠ 4. Với loại THÓI QUEN: hỏi ai cần kết quả này và để làm gì | ⚠ rất nhiều bước tồn tại vì không ai dám bỏ | | ⚠ 5. Thay đổi từng bước, đo lại sau mỗi lần | | | ⚠ Vì sao phải có kiểm toán viên tham gia | ⚠ họ là người trả lời được câu "bước này bắt buộc hay không" — hỏi sai người thì hoặc bạn bỏ nhầm một bước pháp lý, hoặc bạn giữ mãi một bước vô nghĩa |

⚠ Môi trường LAI agile–dự đoán — vì sao dễ sinh tắc nghẽn: | Nguyên nhân | Nội dung | |---|---| | ⚠ Đội phát triển theo nhịp nhanh, quy trình phê duyệt theo nhịp chậm | ⚠ lệch nhịp là nguồn tắc nghẽn chính | | ⚠ Quy trình cũ được thiết kế cho chu kỳ phát hành hằng năm | ⚠ nay dùng cho chu kỳ hai tuần | | ⚠ Nhiều cấp phê duyệt tuần tự | | | ⚠ Không ai sở hữu toàn bộ dòng chảy đầu-cuối | ⚠ mỗi phòng tối ưu phần của mình | | ⚠ Hướng xử lý bền vững | ⚠ giữ nguyên MỤC ĐÍCH kiểm soát nhưng đổi CÁCH thực hiện — ví dụ thay phê duyệt thủ công cuối kỳ bằng kiểm tra tự động liên tục; đó là "tinh gọn và đơn giản hoá" chứ không phải bỏ |

Từ khoá nhận diện:

"quy trình gây tắc nghẽn" → ⚠ CÙNG KIỂM TOÁN VIÊN TINH GỌN, ĐƠN GIẢN HOÁ, LOẠI BỎ CÁI THỪA "bỏ hoàn toàn quy trình hiện tại" → ⚠ cực đoan, rủi ro tuân thủ, chưa phân tích "chấp nhận trễ, không có phương án" → ⚠ đầu hàng, không bao giờ là đáp án "giao thêm việc cho đội" → ⚠ chất tải lên chỗ đang tắc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đo được thời gian từ "code xong" tới "chạy thật" không | ⚠ không đo thì không biết tắc ở đâu | | Trong chuỗi phê duyệt của bạn, bước nào là do LUẬT | ⚠ hỏi thẳng bộ phận tuân thủ, đừng đoán | | Có bước nào không ai đọc kết quả của nó không | ⚠ đó là ứng viên đầu tiên để bỏ |

Và điều mà sáu tuần trễ thường thực sự chứa: không phải sáu tuần làm việc, mà là sáu tuần chờ đợi — và chờ đợi là thứ duy nhất trong dự án có thể xoá bỏ mà không mất gì cả.

Câu 34 People
Carlos is a project manager for his organization, which is a strong matrix, and he is currently managing a project to construct a hotel for a new client. The hotel project has just reached the fifty percent milestone. Internally, the stakeholders are very pleased with the project and how Carlos has led the project. Management views the vision and milestones reached as being aligned with the results. Externally, the customers are confused by the project and view it as being behind schedule and potentially not what they expected. Stakeholders do not have much to say about the project – other than asking when the work will be done. What can Carlos do to solve this problem?
  1. A Follow the communications management plan to give more info to stakeholders.
  2. B Examine the complaints to see if they are actual stakeholders.
  3. C Nothing, if those close to the project are pleased, then all is well.
  4. D Ask for your sponsor's help.
Xem giải thích

Đáp án

A — Theo KẾ HOẠCH QUẢN LÝ GIAO TIẾP để cung cấp thêm thông tin cho các bên liên quan.

Vì sao đúng

⚠ Vì sao đây là chẩn đoán đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Nội bộ hài lòng, bên ngoài HOANG MANG | ⚠ cùng một dự án, hai bức tranh khác nhau → vấn đề nằm ở THÔNG TIN, không ở công việc | | ⚠ Khách hàng nghĩ dự án TRỄ, dù mốc 50% đã đạt đúng | ⚠ họ không có dữ liệu, chỉ có cảm nhận | | ⚠ Khách hàng nghĩ kết quả "không như mong đợi" | ⚠ kỳ vọng chưa bao giờ được đồng bộ | | ⚠ Bên liên quan chỉ hỏi mỗi "bao giờ xong" | ⚠ dấu hiệu kinh điển của người không nhận đủ thông tin | | ⚠ Đã có SẴN kế hoạch quản lý giao tiếp | ⚠ nên việc cần làm là THEO và MỞ RỘNG nó, không phải phát minh cái mới | | ⚠ Kết luận | ⚠ vấn đề giao tiếp thì chữa bằng giao tiếp có kế hoạch |

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

  • D (xin nhà tài trợ giúp) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nhà tài trợ ĐÚNG LÀ người hỗ trợ giao tiếp với bên liên quan cấp cao, và leo thang đôi khi là đáp án đúng: ⚠ nhưng ⚠ đây là việc HOÀN TOÀN trong tầm tay Carlos ⚠ — anh có kế hoạch giao tiếp, có dữ liệu tiến độ, có kênh tới khách hàng; ⚠ leo thang khi chưa tự làm gì là chuyển việc của mình cho người khác, liên hệ #26442 cùng lô về ranh giới leo thang đúng.

  • B (xem xét xem người phàn nàn có thực sự là bên liên quan không) — ⚠ đề đã gọi họ là KHÁCH HÀNG; ⚠ đặt câu hỏi về tư cách của khách hàng là phản ứng phòng thủ, không phải giải quyết vấn đề.

  • C (không làm gì, người gần dự án đã hài lòng là được) — ⚠ bỏ qua chính nhóm quan trọng nhất; ⚠ khách hàng là người nghiệm thu, sự hài lòng nội bộ không thay thế được.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26468 cùng lô (bên liên quan phải nghe tin đồn — cùng một triệu chứng), ⚠ #26466 cùng lô (mối lo của khách hàng), ⚠ #26453 cùng lô (kế hoạch gắn kết bên liên quan), ⚠ #26477 cùng lô (báo cáo giống nhau cho mọi người là gắn kết KÉM), ⚠ #26444 cùng lô (truyền phát).

⚠ Khi nội bộ và bên ngoài nhìn dự án khác nhau — nguyên nhân thường gặp: | Nguyên nhân | Nội dung | |---|---| | ⚠ Kỳ vọng ban đầu chưa được thống nhất rõ | ⚠ "không như mong đợi" luôn bắt nguồn từ đây | | ⚠ Thông tin chỉ chảy trong nội bộ | ⚠ họp nội bộ đủ đầy, khách hàng nhận được bản tóm tắt sơ sài | | ⚠ Ngôn ngữ báo cáo là ngôn ngữ nội bộ | ⚠ "mốc 50%" không nói lên điều gì với khách sạn chưa nhìn thấy phòng nào hoàn thiện | | ⚠ Tiến độ khó nhìn thấy được từ bên ngoài | ⚠ hạ tầng, móng, hệ thống ngầm — làm xong rất nhiều mà nhìn vào vẫn thấy công trường | | ⚠ Cách chữa hiệu quả nhất | ⚠ cho khách hàng nhìn thấy tiến độ bằng THỨ HỌ HIỂU: ảnh, mô hình, buổi đi thăm công trường, một hạng mục hoàn thiện mẫu — thay vì một con số phần trăm |

⚠ Kế hoạch quản lý giao tiếp trả lời những câu hỏi nào: | Câu hỏi | Nội dung | |---|---| | ⚠ AI cần thông tin gì | ⚠ khác nhau theo từng bên liên quan | | ⚠ BAO LÂU một lần | ⚠ khách hàng đang lo thì nên dày hơn | | ⚠ Bằng KÊNH nào | ⚠ email, họp, cổng thông tin, báo cáo — liên hệ #26444 cùng lô | | ⚠ AI chịu trách nhiệm gửi | | | ⚠ Ở ĐỊNH DẠNG và MỨC CHI TIẾT nào | ⚠ lãnh đạo cần một trang, đội kỹ thuật cần chi tiết | | ⚠ Điều Carlos cần rà lại | ⚠ kế hoạch có mục dành riêng cho KHÁCH HÀNG BÊN NGOÀI không, hay chỉ có mục cho bên liên quan nội bộ — khoảng trống đó chính là lời giải thích cho toàn bộ tình huống |

⚠ Ma trận tổ chức mạnh — chi tiết bối cảnh có ý nghĩa gì: | Khía cạnh | Nội dung | |---|---| | ⚠ Carlos có thẩm quyền TRUNG BÌNH ĐẾN CAO | ⚠ anh chủ động được, không cần xin phép để giao tiếp với khách hàng | | ⚠ Anh làm quản lý dự án TOÀN THỜI GIAN | ⚠ có thời gian cho việc gắn kết bên liên quan | | ⚠ Nên phương án "xin nhà tài trợ giúp" càng yếu | ⚠ ma trận yếu thì lập luận leo thang mạnh hơn; ma trận mạnh thì đây là việc của anh | | ⚠ Bài học chung | ⚠ chi tiết về cấu trúc tổ chức trong đề PMP hiếm khi thừa — nó thường là manh mối cho biết quản lý dự án được phép tự làm tới đâu |

Từ khoá nhận diện:

"nội bộ hài lòng, khách hàng hoang mang" → ⚠ THEO KẾ HOẠCH GIAO TIẾP, ĐƯA THÊM THÔNG TIN "xin nhà tài trợ giúp" → ⚠ leo thang khi chưa tự làm gì "họ có thật là bên liên quan không" → ⚠ phản ứng phòng thủ "mọi thứ vẫn ổn" → ⚠ bỏ qua nhóm sẽ nghiệm thu sản phẩm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khách hàng của bạn nhận báo cáo bao lâu một lần | ⚠ so với tần suất họp nội bộ của bạn | | Báo cáo cho khách hàng có dùng ngôn ngữ của họ không | ⚠ hay dùng ngôn ngữ dự án | | Bạn có biết khách hàng đang NGHĨ GÌ về dự án không | ⚠ nếu chỉ đoán thì hãy hỏi — liên hệ #26443 cùng lô |

Và điều mà mốc 50% của Carlos chứng minh: một dự án có thể đúng tiến độ ở mọi con số và vẫn đang thất bại — vì thứ khách hàng nghiệm thu cuối cùng không phải bảng tiến độ, mà là cảm nhận của họ về việc họ có được nghe hay không.

Câu 35 People
Kenneth has an interdepartmental project that deals with complex issues. The project is in the execution phase. Kenneth sends out weekly status reports to all stakeholders, communicating the project's state regarding its schedule, budget, quality, and risks. Kenneth is using which of the following?
  1. A Good communication management
  2. B Poor stakeholder engagement
  3. C Good stakeholder engagement
  4. D Poor scope management
Xem giải thích

Đáp án

B — GẮN KẾT BÊN LIÊN QUAN KÉM (poor stakeholder engagement).

Vì sao đúng

⚠ Vì sao gửi cùng một báo cáo cho tất cả là gắn kết kém: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ MỘT báo cáo giống nhau gửi cho TẤT CẢ bên liên quan | ⚠ không phân biệt ai cần gì | | ⚠ Dự án LIÊN PHÒNG BAN và PHỨC TẠP | ⚠ các nhóm có mối quan tâm rất khác nhau | | ⚠ Giao tiếp MỘT CHIỀU, chỉ đẩy ra | ⚠ không có kênh nhận lại ý kiến | | ⚠ Gắn kết đòi hỏi TƯƠNG TÁC, không chỉ thông báo | ⚠ đây là ranh giới của câu hỏi | | ⚠ Nội dung cố định: tiến độ, ngân sách, chất lượng, rủi ro | ⚠ hợp lý cho lãnh đạo, gần như vô dụng cho một trưởng bộ phận chỉ quan tâm phần của mình | | ⚠ Kết luận | ⚠ Kenneth đang BÁO CÁO, chứ chưa GẮN KẾT |

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

  • A (quản lý giao tiếp TỐT) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ về hình thức Kenneth làm đúng nhiều thứ: đều đặn hằng tuần, nội dung đầy đủ bốn mảng, gửi cho mọi người: ⚠ nhưng ⚠ kế hoạch quản lý giao tiếp tốt phải ĐIỀU CHỈNH nội dung, mức chi tiết và tần suất theo từng nhóm ⚠ — gửi giống nhau cho tất cả chính là dấu hiệu chưa từng phân tích nhu cầu thông tin; ⚠ đề cố tình dựng một tình huống nhìn thì có kỷ luật, xét kỹ thì máy móc.

  • C (gắn kết bên liên quan TỐT) — ⚠ ngược dấu với đáp án.

  • D (quản lý phạm vi KÉM) — ⚠ đề không nói gì về phạm vi; ⚠ lạc lĩnh vực.

Ghi nhớ

⚠ Đối chiếu — CHÙM CÂU về giao tiếp với bên liên quan trong cùng lô: ⚠ #26476 (nội bộ hài lòng, khách hàng hoang mang), ⚠ #26468 (Julie phải nghe tin đồn), ⚠ #26453 (kế hoạch gắn kết), ⚠ #26443 (hỏi bên liên quan điều gì đang khó), ⚠ #26444 (truyền phát), ⚠ #26436 (ưu tiên theo tác động). ⚠ Sáu câu này cùng vẽ nên một bức tranh: gửi thông tin KHÔNG bằng gắn kết.

⚠ BÁO CÁO và GẮN KẾT — bảng phân biệt: | | Báo cáo (reporting) | Gắn kết (engagement) | |---|---|---| | ⚠ Chiều | ⚠ MỘT chiều — đẩy ra | ⚠ HAI chiều — có nhận lại | | ⚠ Nội dung | ⚠ thường giống nhau cho mọi người | ⚠ điều chỉnh theo từng bên liên quan | | ⚠ Mục tiêu | ⚠ thông báo tình trạng | ⚠ ảnh hưởng tới mức độ ủng hộ và tham gia | | ⚠ Đo bằng | ⚠ đã gửi hay chưa | ⚠ bên liên quan có chuyển từ trung lập sang ủng hộ không | | ⚠ Đủ chưa | ⚠ cần nhưng KHÔNG đủ | ⚠ đây mới là đích | | ⚠ Sai lầm phổ biến nhất | ⚠ coi việc đã gửi báo cáo là bằng chứng đã gắn kết — giống như coi việc đã nói là bằng chứng người kia đã hiểu | |

⚠ Kenneth nên đổi gì: | Việc | Nội dung | |---|---| | ⚠ Phân nhóm bên liên quan theo nhu cầu thông tin | ⚠ lãnh đạo, trưởng phòng, đội thực thi, khách hàng — bốn nhu cầu khác nhau | | ⚠ Điều chỉnh mức chi tiết cho từng nhóm | ⚠ lãnh đạo: một trang có ngoại lệ; trưởng phòng: phần liên quan tới họ | | ⚠ Mở kênh HAI CHIỀU | ⚠ họp ngắn định kỳ, hỏi trực tiếp, không chỉ gửi email | | ⚠ Với bên liên quan quan trọng: gặp riêng | ⚠ liên hệ #26403 lô 193 | | ⚠ Đo hiệu quả: họ có phản hồi không, có ra quyết định kịp không | | | ⚠ Điều KHÔNG cần bỏ | ⚠ báo cáo tuần vẫn nên giữ — nó là NỀN; vấn đề là Kenneth dừng lại ở đó và tưởng đã xong |

⚠ Vì sao dự án LIÊN PHÒNG BAN làm vấn đề này nặng thêm: | Lý do | Nội dung | |---|---| | ⚠ Mỗi phòng có mục tiêu và thước đo riêng | ⚠ cùng một tin tốt với phòng này là tin xấu với phòng kia | | ⚠ Không phòng nào coi dự án là ưu tiên số một | ⚠ phải chủ động kéo họ vào | | ⚠ Thông tin chung chung không giúp ai ra quyết định | ⚠ và người ta ngừng đọc | | ⚠ Xung đột giữa các phòng cần phát hiện SỚM | ⚠ chỉ kênh hai chiều mới phát hiện được | | ⚠ Hệ quả nếu không sửa | ⚠ báo cáo vẫn đều đặn mỗi tuần, không ai đọc, và vấn đề đầu tiên Kenneth biết đến sẽ là vấn đề đã quá muộn để xử lý |

Từ khoá nhận diện:

"cùng một báo cáo gửi cho tất cả bên liên quan" → ⚠ GẮN KẾT KÉM "đều đặn, đầy đủ nội dung" → ⚠ điều kiện cần, không phải điều kiện đủ "gắn kết" → ⚠ luôn hàm ý HAI CHIỀU và ĐIỀU CHỈNH theo người nhận "quản lý phạm vi" → ⚠ lạc lĩnh vực khi đề không nhắc gì tới phạm vi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo của bạn có bao nhiêu phiên bản cho các nhóm khác nhau | ⚠ chỉ một là dấu hiệu của câu này | | Có ai từng phản hồi lại báo cáo của bạn không | ⚠ im lặng kéo dài nghĩa là không ai đọc | | Bạn biết mối quan tâm riêng của từng bên liên quan chính không | |

Và điều đáng nhớ nhất về một báo cáo tuần gửi cho tất cả mọi người: nó được viết cho người gửi chứ không cho người nhận — bằng chứng là nó không đổi dù người nhận là ai.

Câu 36 Process
Monica is the project manager of the Cottage Project. With work and budget spread evenly, this project is scheduled to last 10 months. The project is now in its third month, and the work is on schedule. However, Monica has spent $65,000 of the $130,000 project budget. What is Monica's variance?
  1. A $39,000
  2. B $26,000
  3. C $64,999
  4. D $65,000
Xem giải thích

Đáp án

B — 26.000 đô-la.

Vì sao đúng

⚠ Tính từng bước: | Bước | Phép tính | Kết quả | |---|---|---| | ⚠ Ngân sách hoàn thành (BAC) | ⚠ đề cho | ⚠ 130.000 đô | | ⚠ Thời lượng dự án | ⚠ đề cho | ⚠ 10 tháng, công việc và ngân sách rải ĐỀU | | ⚠ Đang ở tháng thứ 3 | ⚠ đã trôi qua 3/10 = 30% | | | ⚠ Giá trị hoạch định (PV) | ⚠ 130.000 × 0,30 | ⚠ 39.000 đô | | ⚠ Giá trị thu được (EV) | ⚠ công việc ĐÚNG TIẾN ĐỘ → EV = PV | ⚠ 39.000 đô | | ⚠ Chi phí thực tế (AC) | ⚠ đề cho — đã chi 65.000 | ⚠ 65.000 đô | | ⚠ Chênh lệch chi phí (CV) | ⚠ EV − AC = 39.000 − 65.000 | ⚠ −26.000 đô | | ⚠ Kết luận | ⚠ chênh lệch là 26.000 đô, dấu âm nghĩa là VƯỢT CHI | |

⚠ Chốt chặn quan trọng: ⚠ "công việc đúng tiến độ" là câu cho biết EV = PV ⚠ — không có câu đó thì bài toán thiếu dữ kiện; ⚠ nhờ nó, chênh lệch tiến độ SV = EV − PV = 0, nên chênh lệch duy nhất còn lại là chênh lệch CHI PHÍ.

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

  • A (39.000 đô) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đó là một con số THẬT trong bài — chính là PV và EV: ⚠ nhưng ⚠ nó là GIÁ TRỊ CÔNG VIỆC, không phải CHÊNH LỆCH ⚠ — bẫy này bắt đúng người tính ra 39.000 rồi dừng lại ở đó thay vì trừ tiếp.
  • D (65.000 đô) — ⚠ là chi phí thực tế AC, cũng là một số có sẵn trong đề, cũng không phải chênh lệch.
  • C (64.999 đô) — ⚠ con số vô nghĩa, chỉ khác AC đúng 1 đô; ⚠ nhiễu kiểu đánh vào người chọn vội.

Ghi nhớ

⚠ Đối chiếu — BỘ GIÁ TRỊ THU ĐƯỢC: ⚠ #26231 lô 189 (bài đầy đủ nhất, có cả EAC), ⚠ #26459 cùng lô (đọc ý nghĩa CPI 0,98), ⚠ #26462 cùng lô (CPI 0,96 và SPI 0,85), ⚠ #26308 lô 191 (từ SPI suy ra thời gian còn lại), ⚠ #26341 lô 192 (CPI 1,2).

⚠ Bổ sung: các chỉ số khác của dự án Cottage: | Chỉ số | Phép tính | Kết quả | |---|---|---| | ⚠ SV — chênh lệch tiến độ | ⚠ EV − PV = 39.000 − 39.000 | ⚠ 0 — đúng tiến độ | | ⚠ CV — chênh lệch chi phí | ⚠ 39.000 − 65.000 | ⚠ −26.000 — vượt chi | | ⚠ SPI | ⚠ 39.000 ÷ 39.000 | ⚠ 1,00 — đúng tiến độ | | ⚠ CPI | ⚠ 39.000 ÷ 65.000 | ⚠ ≈ 0,60 — rất xấu | | ⚠ EAC (giả định hiệu suất giữ nguyên) | ⚠ BAC ÷ CPI = 130.000 ÷ 0,60 | ⚠ ≈ 216.667 đô | | ⚠ Ý nghĩa thực tế | ⚠ CPI 0,60 nghĩa là mỗi đô chi ra chỉ mua được 60 xu giá trị — nếu không đổi gì, dự án sẽ tốn gần GẤP RƯỠI ngân sách; đây là tình huống nghiêm trọng hơn nhiều so với con số 26.000 nghe có vẻ nhỏ |

⚠ Ba công thức chênh lệch — nhớ theo một quy tắc duy nhất: | Chỉ số | Công thức | Quy tắc | |---|---|---| | ⚠ CV — chênh lệch chi phí | ⚠ EV − AC | ⚠ EV luôn đứng TRƯỚC | | ⚠ SV — chênh lệch tiến độ | ⚠ EV − PV | ⚠ EV luôn đứng TRƯỚC | | ⚠ CPI | ⚠ EV ÷ AC | ⚠ EV luôn ở TỬ SỐ | | ⚠ SPI | ⚠ EV ÷ PV | ⚠ EV luôn ở TỬ SỐ | | ⚠ Quy tắc chung | ⚠ EV LUÔN đứng đầu trong cả bốn công thức — nhớ đúng một điều này là không bao giờ đảo ngược dấu | | | ⚠ Đọc dấu | ⚠ ÂM là xấu ở cả CV và SV; nhỏ hơn 1 là xấu ở cả CPI và SPI | |

⚠ Bẫy hay gặp trong bài toán giá trị thu được: | Bẫy | Cách tránh | |---|---| | ⚠ Nhầm AC với EV | ⚠ tiền ĐÃ CHI không phải giá trị ĐÃ LÀM — đây là bẫy trung tâm của bài này | | ⚠ Quên nhân BAC với phần trăm thời gian đã trôi | ⚠ chỉ đúng khi đề nói "rải đều" — bài này có nói | | ⚠ Chọn một con số có sẵn trong đề | ⚠ 39.000 và 65.000 đều có sẵn; chênh lệch phải TÍNH ra | | ⚠ Quên rằng "đúng tiến độ" cho biết EV = PV | ⚠ câu chìa khoá của bài, đọc lướt là mất | | ⚠ Thói quen tốt | ⚠ luôn viết ra ba con số PV, EV, AC trước khi tính bất cứ chỉ số nào — mọi công thức đều chỉ là phép cộng trừ chia của ba số đó |

Từ khoá nhận diện:

"đúng tiến độ" → ⚠ EV = PV "rải đều trong N tháng, đang ở tháng thứ M" → ⚠ PV = BAC × M/N "đã chi bao nhiêu" → ⚠ AC "chênh lệch" → ⚠ luôn là EV trừ đi thứ khác, không bao giờ ngược lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có đo được EV không | ⚠ rất nhiều dự án chỉ theo dõi AC và tưởng đó là đủ | | Bạn có nhầm "đã chi 50% ngân sách" với "đã xong 50%" không | ⚠ bài này chính là ví dụ vì sao không được nhầm | | CPI của bạn hiện là bao nhiêu | ⚠ dưới 0,9 là lúc phải hành động, không phải lúc theo dõi thêm |

Và điều mà con số 26.000 đô của Monica che giấu: dự án đúng tiến độ trên mọi báo cáo, nhưng đã tiêu hết một nửa ngân sách để làm xong ba phần mười công việc — và không ai nhìn ra điều đó nếu chỉ nhìn vào lịch.

Câu 37 Business Environment
JB is responsible for writing contracts and providing payroll for various employers who want to hire his temps. He works off a template, adjusting certain sections as needed. When he has a working contract, he sends it to a lawyer retained by his company. The lawyer reviews it with an eye to tax and regulatory compliance. If it looks okay, the lawyer files the contract away. How is project compliance being managed?
  1. A Compliance audit
  2. B Compliance documentation
  3. C Compliance council
  4. D Compliance risk
Xem giải thích

Đáp án

A — KIỂM TOÁN TUÂN THỦ (compliance audit).

Vì sao đúng

⚠ Vì sao việc luật sư làm là một cuộc kiểm toán tuân thủ: | Đặc điểm của kiểm toán | Có trong tình huống | |---|---| | ⚠ Do bên ĐỘC LẬP với người tạo ra tài liệu thực hiện | ⚠ luật sư, không phải JB | | ⚠ Rà soát theo một BỘ TIÊU CHÍ xác định | ⚠ quy định về thuế và pháp lý | | ⚠ Diễn ra ĐỀU ĐẶN, có hệ thống | ⚠ mọi hợp đồng đều đi qua bước này | | ⚠ Có KẾT LUẬN: đạt hay không đạt | ⚠ "nếu ổn thì luật sư lưu lại" | | ⚠ Có lưu hồ sơ để chứng minh về sau | ⚠ việc lưu trữ là bằng chứng tuân thủ | | ⚠ Kết luận | ⚠ đây là cơ chế KIỂM TRA, và kiểm tra có hệ thống bởi bên độc lập chính là kiểm toán |

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

  • B (TÀI LIỆU HOÁ TUÂN THỦ — compliance documentation) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trong tình huống có cả mẫu hợp đồng lẫn việc lưu trữ hồ sơ, đều là hoạt động tài liệu hoá thật: ⚠ nhưng ⚠ đề hỏi tuân thủ đang được QUẢN LÝ NHƯ THẾ NÀO ⚠ — tài liệu hoá chỉ là lưu giữ, còn thứ thực sự bảo đảm tuân thủ ở đây là hành động RÀ SOÁT của luật sư; ⚠ bỏ bước rà soát đi thì tài liệu vẫn còn nguyên mà tuân thủ thì không còn.

  • C (HỘI ĐỒNG TUÂN THỦ — compliance council) — ⚠ là một NHÓM người có thẩm quyền về chính sách tuân thủ; ⚠ ở đây chỉ có một luật sư rà soát, không phải hội đồng.

  • D (RỦI RO TUÂN THỦ) — ⚠ là một LOẠI RỦI RO, không phải một cách quản lý; ⚠ lạc phạm trù.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26452 cùng lô (hướng dẫn phân tích tuân thủ), ⚠ #26471 cùng lô (rủi ro tuân thủ trước khi xếp ưu tiên), ⚠ #26451 cùng lô (quản trị mua sắm), ⚠ #26457 cùng lô (kiểm toán chất lượng — cùng logic, khác đối tượng), ⚠ #26426 lô 193 (tuân thủ không thương lượng).

⚠ Bốn cơ chế quản lý tuân thủ — phân biệt: | Cơ chế | Là gì | Ví dụ | |---|---|---| | ⚠ KIỂM TOÁN tuân thủ | ⚠ rà soát có hệ thống bởi bên độc lập | ⚠ luật sư soát hợp đồng — câu này | | ⚠ TÀI LIỆU HOÁ tuân thủ | ⚠ ghi và lưu bằng chứng | ⚠ mẫu hợp đồng, hồ sơ đã lưu | | ⚠ HỘI ĐỒNG tuân thủ | ⚠ nhóm ra chính sách và phán quyết | ⚠ ban tuân thủ của tập đoàn | | ⚠ ĐÀO TẠO tuân thủ | ⚠ trang bị kiến thức cho người thực hiện | ⚠ khoá học bắt buộc hằng năm | | ⚠ Quan hệ giữa bốn cái | ⚠ đào tạo để làm ĐÚNG, tài liệu để CHỨNG MINH, kiểm toán để KIỂM CHỨNG, hội đồng để QUYẾT khi có tranh cãi — thiếu kiểm toán thì ba cái kia không có gì bảo đảm | |

⚠ Vì sao mẫu hợp đồng CHƯA đủ để bảo đảm tuân thủ: | Lý do | Nội dung | |---|---| | ⚠ JB "điều chỉnh vài phần khi cần" | ⚠ mỗi lần điều chỉnh là một lần có thể lệch chuẩn | | ⚠ Mẫu được soạn cho tình huống chung | ⚠ trường hợp cụ thể có thể rơi ra ngoài | | ⚠ Quy định thuế và pháp lý THAY ĐỔI | ⚠ mẫu cũ có thể đã lỗi thời — liên hệ #26480 cùng lô | | ⚠ JB không phải luật sư | ⚠ anh không đủ chuyên môn để tự phán quyết | | ⚠ Vì thế | ⚠ mẫu giúp giảm sai sót nhưng không thay thế được một cặp mắt độc lập — đó là toàn bộ lý do bước rà soát của luật sư tồn tại |

⚠ Ba tuyến phòng vệ — khung tư duy chuẩn về tuân thủ: | Tuyến | Ai | Việc | |---|---|---| | ⚠ Tuyến 1 | ⚠ người trực tiếp làm việc — JB | ⚠ làm đúng ngay từ đầu, dùng mẫu chuẩn | | ⚠ Tuyến 2 | ⚠ bộ phận tuân thủ / luật sư công ty | ⚠ rà soát, tư vấn, đặt chuẩn — luật sư trong câu này | | ⚠ Tuyến 3 | ⚠ kiểm toán nội bộ hoặc bên ngoài | ⚠ kiểm tra xem hai tuyến kia có hoạt động không | | ⚠ Nhận xét về tình huống | ⚠ JB và luật sư đang phủ tuyến 1 và tuyến 2 — một quy trình lành mạnh cho quy mô này | |

Từ khoá nhận diện:

"bên độc lập rà soát theo tiêu chí rồi kết luận" → ⚠ KIỂM TOÁN TUÂN THỦ "lưu hồ sơ, dùng mẫu" → ⚠ tài liệu hoá — cần nhưng không phải cơ chế bảo đảm "một nhóm ra chính sách" → ⚠ hội đồng tuân thủ "rủi ro tuân thủ" → ⚠ một loại rủi ro, không phải một cách quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu pháp lý của bạn có ai ĐỘC LẬP rà soát không | ⚠ hay chỉ có người soạn tự kiểm | | Mẫu của bạn được cập nhật lần cuối khi nào | | | Bạn có lưu bằng chứng đã rà soát không | ⚠ khi có tranh chấp, "chúng tôi có kiểm" mà không có hồ sơ thì bằng không kiểm |

Và điều làm nên khác biệt giữa một quy trình tuân thủ thật và một quy trình trên giấy: không phải là có mẫu chuẩn hay có hồ sơ đầy đủ, mà là có ai đó không phải người viết ra nó chịu đọc lại nó.

Câu 38 Business Environment
Amanda is the project manager for Project K, which is eight weeks into an international deployment across nine countries. During a weekly status meeting, one of the stakeholders noted that a new government was transitioning into power in one of Project K's countries. What should Amanda do with this information?
  1. A Reach out to local contacts to determine the impact on Project K.
  2. B Log the information into the project management system.
  3. C Monitor the transition to see if it will impact Project K.
  4. D Ask her legal team to investigate the new government's policies.
Xem giải thích

Đáp án

C — THEO DÕI quá trình chuyển giao quyền lực để xem nó có tác động tới Dự án K hay không.

Vì sao đúng

⚠ Vì sao theo dõi là hành động đúng ở thời điểm này: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Chính phủ mới ĐANG chuyển giao — CHƯA nắm quyền | ⚠ chưa có chính sách nào được ban hành | | ⚠ Chưa có tác động NÀO được xác nhận | ⚠ đây là RỦI RO, không phải VẤN ĐỀ | | ⚠ Rủi ro chưa xảy ra thì được GIÁM SÁT, không được ứng phó | ⚠ quy trình Giám sát rủi ro | | ⚠ Ghi vào sổ đăng ký rủi ro và đặt TÁC NHÂN KÍCH HOẠT | ⚠ khi chính sách thật xuất hiện thì mới hành động | | ⚠ Chỉ ảnh hưởng MỘT trong CHÍN nước | ⚠ phản ứng phải tương xứng với mức phơi nhiễm | | ⚠ Kết luận | ⚠ theo dõi là ứng xử đúng mức với một bất định chưa thành hình |

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

  • A (liên hệ đầu mối địa phương để xác định tác động lên dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó CHỦ ĐỘNG, dùng người am hiểu tại chỗ, và nghe rất có trách nhiệm: ⚠ nhưng ⚠ CHƯA CÓ GÌ để đánh giá ⚠ — chính phủ mới còn chưa nhậm chức, chưa công bố chính sách nào; ⚠ hỏi lúc này chỉ nhận được phỏng đoán, và hành động dựa trên phỏng đoán chính trị là phản ứng thái quá; ⚠ A là bước ĐÚNG nhưng SAI THỜI ĐIỂM — nó là việc phải làm khi tác nhân kích hoạt xuất hiện.

  • B (ghi thông tin vào hệ thống quản lý dự án) — ⚠ chỉ là hành vi lưu trữ; ⚠ ghi mà không theo dõi thì thông tin nằm chết trong hệ thống.

  • D (nhờ bộ phận pháp lý điều tra chính sách của chính phủ mới) — ⚠ cùng lỗi với A, còn nặng hơn: ⚠ chính phủ mới chưa có chính sách nào để mà điều tra.

Ghi nhớ

⚠ Đối chiếu — CẶP CÂU quan trọng: ⚠ #26394 và #26396 lô 193 — ⚠ luật ĐÃ ban hành = VẤN ĐỀ (phải hành động ngay); thuế quan mới chỉ được NHẮC TỚI = RỦI RO (theo dõi). ⚠ #26480 thuộc đúng vế thứ hai: chính phủ còn chưa nhậm chức thì mức độ bất định còn cao hơn nữa. ⚠ Liên hệ thêm #26462 cùng lô (rủi ro tồn dư), #26322 lô 191 (nhận diện rủi ro suốt vòng đời).

⚠ Thang phản ứng theo mức độ chắc chắn — bảng tra: | Tình trạng | Phân loại | Hành động đúng | |---|---|---| | ⚠ Có tin đồn về khả năng thay đổi | ⚠ rủi ro mờ | ⚠ ghi nhận, THEO DÕI — tình huống này | | ⚠ Thay đổi đã được công bố, chưa có hiệu lực | ⚠ rủi ro rõ | ⚠ phân tích tác động, chuẩn bị ứng phó | | ⚠ Đã có hiệu lực nhưng chưa chạm tới dự án | ⚠ rủi ro sắp thành vấn đề | ⚠ kích hoạt kế hoạch ứng phó | | ⚠ Đã ảnh hưởng tới dự án | ⚠ VẤN ĐỀ | ⚠ xử lý ngay, ghi sổ vấn đề, có thể cần yêu cầu thay đổi | | ⚠ Nguyên tắc | ⚠ mức phản ứng phải TƯƠNG XỨNG với mức chắc chắn — phản ứng non thì mất cảnh giác, phản ứng quá thì đốt nguồn lực vào thứ có thể không bao giờ xảy ra | |

⚠ Amanda nên ghi gì vào sổ đăng ký rủi ro: | Mục | Nội dung | |---|---| | ⚠ Mô tả rủi ro | ⚠ "chính phủ mới ở nước X có thể đổi quy định ảnh hưởng tới triển khai" | | ⚠ Loại | ⚠ rủi ro BÊN NGOÀI, thuộc nhóm chính trị/pháp lý | | ⚠ Chủ sở hữu | ⚠ người phụ trách thị trường đó | | ⚠ TÁC NHÂN KÍCH HOẠT | ⚠ chính phủ mới nhậm chức và công bố chính sách liên quan — đây là mục quan trọng nhất | | ⚠ Ứng phó dự kiến | ⚠ khi kích hoạt: liên hệ đầu mối địa phương (phương án A) và bộ phận pháp lý (phương án D) | | ⚠ Nhận xét | ⚠ hai phương án nhiễu của câu này chính là NỘI DUNG của kế hoạch ứng phó — chúng không sai về bản chất, chúng chỉ chưa tới lúc |

⚠ Rủi ro CHÍNH TRỊ trong dự án đa quốc gia: | Khía cạnh | Nội dung | |---|---| | ⚠ Nằm ngoài tầm kiểm soát hoàn toàn | ⚠ không thể giảm nhẹ nguyên nhân, chỉ giảm nhẹ tác động | | ⚠ Chiến lược thường dùng | ⚠ chấp nhận có theo dõi, kèm dự phòng; đôi khi bảo hiểm rủi ro chính trị | | ⚠ Cần đầu mối tại chỗ cho từng nước | ⚠ họ nhận ra tín hiệu sớm hơn nhiều so với trụ sở chính | | ⚠ Ảnh hưởng một nước không có nghĩa dừng cả dự án | ⚠ thiết kế sao cho tách được từng thị trường — liên hệ #26472 cùng lô | | ⚠ Sai lầm hay gặp | ⚠ hoặc phớt lờ hoàn toàn vì "không làm gì được", hoặc hoảng loạn với mỗi bản tin — cả hai đều là hậu quả của việc không có tác nhân kích hoạt được định nghĩa trước |

Từ khoá nhận diện:

"chính phủ đang chuyển giao, chưa có chính sách" → ⚠ THEO DÕI "luật đã ban hành và đã ảnh hưởng" → ⚠ vấn đề, xử lý ngay — #26394 lô 193 "liên hệ đầu mối / nhờ pháp lý điều tra" → ⚠ đúng việc, sai thời điểm; là nội dung của kế hoạch ứng phó "ghi vào hệ thống" → ⚠ cần, nhưng chỉ ghi thì không đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro trong sổ của bạn có tác nhân kích hoạt cụ thể không | ⚠ không có thì không ai biết khi nào phải hành động | | Bạn có đầu mối ở mỗi thị trường mình triển khai không | | | Lần gần nhất bạn rà soát rủi ro bên ngoài là khi nào | ⚠ rủi ro chính trị đổi nhanh hơn nhịp họp hằng tháng |

Và ranh giới mà câu này thực sự dạy: theo dõi không phải là không làm gì — nó là quyết định có ý thức về việc chờ tới đúng thời điểm, với một điều kiện đã ghi sẵn cho biết thời điểm đó là khi nào.

Câu 39 Process
Adaline is a scrum master for Project VN, which just began. While meeting with the product owner, Adaline realizes there are numerous e-mails and instant messages which contain possible user stories for Project VN. What should the product owner and Adaline do next?
  1. A Brainstorm stories for Project N and use an affinity diagram.
  2. B Review every e-mail and instant message and put them into the backlog as needed.
  3. C Forward the e-mails and instant messages to the project team.
  4. D Hold a meeting with all relevant stakeholders to gather their ideas.
Xem giải thích

Đáp án

B — Rà soát TỪNG email và tin nhắn rồi đưa vào backlog những gì cần thiết.

Vì sao đúng

⚠ Vì sao đây là bước tiếp theo đúng: | Lý do | Nội dung | |---|---| | ⚠ Thông tin ĐÃ CÓ SẴN, chỉ đang nằm rải rác | ⚠ việc cần làm là THU GOM, không phải tạo mới | | ⚠ Backlog là NGUỒN SỰ THẬT DUY NHẤT của công việc | ⚠ mọi yêu cầu phải hội tụ về đó | | ⚠ "Khi cần" nghĩa là có SÀNG LỌC, không đổ hết vào | ⚠ chi tiết quan trọng phân biệt đáp án này với việc chép máy móc | | ⚠ Dự án VỪA BẮT ĐẦU | ⚠ đúng thời điểm để gom hết đầu vào hiện có | | ⚠ Chủ sản phẩm là người sở hữu backlog | ⚠ và Adaline là scrum master hỗ trợ tiến trình | | ⚠ Kết luận | ⚠ dùng thứ đang có trước khi đi tìm thêm thứ mới |

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

  • D (họp với tất cả bên liên quan để thu thập ý tưởng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đây là việc rất đúng đắn và sẽ phải làm ở một thời điểm nào đó: ⚠ nhưng ⚠ họp mà chưa xem thứ mình đã có là lãng phí thời gian của tất cả mọi người ⚠ — bên liên quan sẽ nhắc lại chính những gì họ đã viết trong email; ⚠ trình tự đúng là gom cái đã có → tổng hợp → rồi mới họp để bổ sung và làm rõ.

  • A (động não thêm rồi dùng sơ đồ tương đồng) — ⚠ cũng là tạo mới trong khi chưa dùng cái sẵn có; ⚠ và đề còn ghi nhầm tên dự án ("Project N" thay vì "Project VN").

  • C (chuyển tiếp email và tin nhắn cho cả đội) — ⚠ đẩy việc sàng lọc sang người khác; ⚠ đội sẽ nhận một đống thư không có cấu trúc, và đó không phải backlog.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án A viết "Project N" trong khi đề gọi dự án là "Project VN" ⚠ — ⚠ lỗi đánh máy, không ảnh hưởng tới việc chấm vì phương án vẫn sai vì lý do nội dung; ⚠ cùng loại với #26437 cùng lô (tên dự án không nhất quán giữa đề và phương án) và #26465 cùng lô (câu đề bị cụt) — ⚠ bộ đề Set II có mật độ lỗi soạn thảo cao hơn Set I.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26473 cùng lô (tỉa cây sản phẩm — công cụ tạo tính năng MỚI), ⚠ #26471 cùng lô (xếp ưu tiên backlog sau khi xét rủi ro), ⚠ #26464 cùng lô (xếp hạng tuyệt đối), ⚠ #26463 cùng lô (hiện vật agile).

⚠ Trình tự xây dựng backlog ban đầu: | Bước | Việc | |---|---| | ⚠ 1. GOM mọi đầu vào đã có | ⚠ email, tin nhắn, ghi chú họp, tài liệu cũ — bước của câu này | | ⚠ 2. SÀNG LỌC: cái nào là yêu cầu thật, cái nào chỉ là bàn tán | ⚠ "khi cần" trong đáp án chính là bước này | | ⚠ 3. Viết lại thành câu chuyện người dùng có cấu trúc | ⚠ "Là một… tôi muốn… để…" | | ⚠ 4. HỌP với bên liên quan để bổ sung phần còn thiếu | ⚠ phương án D — đúng nhưng thuộc bước này | | ⚠ 5. Xếp ưu tiên | ⚠ liên hệ #26471 và #26464 cùng lô | | ⚠ 6. Rà soát backlog định kỳ | ⚠ backlog không bao giờ "xong" | | ⚠ Nguyên tắc xuyên suốt | ⚠ dùng hết thứ mình đã có trước khi đòi hỏi thêm thời gian của người khác — đó là biểu hiện của sự tôn trọng, không chỉ của hiệu suất |

⚠ Vì sao yêu cầu rải rác trong email và tin nhắn là một VẤN ĐỀ CẦN CHỮA: | Vấn đề | Nội dung | |---|---| | ⚠ Không ai nhìn thấy toàn cảnh | ⚠ mỗi người chỉ biết phần mình đã gửi | | ⚠ Yêu cầu trùng nhau hoặc mâu thuẫn không lộ ra | | | ⚠ Không có thứ tự ưu tiên | ⚠ ai gửi sau cùng thì được nhớ lâu nhất | | ⚠ Dễ mất khi người ta đổi việc | ⚠ liên hệ #26455 cùng lô — tri thức nằm trong hộp thư là tri thức sắp mất | | ⚠ Không có ai chịu trách nhiệm | | | ⚠ Việc Adaline nên làm sau khi gom xong | ⚠ thiết lập QUY ƯỚC: từ nay yêu cầu mới đi qua backlog, không qua tin nhắn riêng — nếu không thì sáu tuần nữa lại có một đống email mới |

⚠ Vai trò của scrum master và chủ sản phẩm trong việc này: | | Chủ sản phẩm | Scrum master | |---|---|---| | ⚠ Sở hữu backlog | ⚠ CÓ — quyết nội dung và thứ tự | ⚠ không | | ⚠ Vai trò trong việc gom yêu cầu | ⚠ quyết cái nào vào backlog | ⚠ tổ chức tiến trình, gỡ vướng mắc | | ⚠ Làm việc với bên liên quan | ⚠ là đầu mối chính | ⚠ hỗ trợ, bảo vệ đội khỏi gián đoạn | | ⚠ Trong đề này | ⚠ cả hai cùng làm — đúng, vì đây là việc thiết lập nền tảng | | | ⚠ Ranh giới cần nhớ | ⚠ scrum master GIÚP backlog trở nên rõ ràng và dễ làm việc; scrum master KHÔNG quyết cái gì được làm trước — liên hệ #26475 cùng lô về lãnh đạo phục vụ | |

Từ khoá nhận diện:

"yêu cầu nằm rải rác trong email và tin nhắn" → ⚠ RÀ SOÁT TỪNG CÁI, ĐƯA VÀO BACKLOG KHI CẦN "họp với tất cả bên liên quan" → ⚠ đúng nhưng là bước sau "động não tạo ý tưởng mới" → ⚠ tạo mới khi chưa dùng cái sẵn có "chuyển tiếp cho đội" → ⚠ đẩy việc sàng lọc, không tạo ra backlog

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu của dự án bạn đang nằm ở bao nhiêu nơi | ⚠ nhiều hơn một là đã có vấn đề | | Có quy ước nào về nơi tiếp nhận yêu cầu mới không | | | Backlog của bạn có phản ánh mọi thứ bên liên quan đã nói không | ⚠ hay chỉ những thứ được nói to nhất |

Và lý do bước gom email tẻ nhạt này lại quan trọng: một yêu cầu không nằm trong backlog thì không tồn tại với đội — nhưng nó vẫn tồn tại rất rõ trong đầu người đã gửi nó, và họ sẽ nhớ ra vào đúng ngày nghiệm thu.

Câu 40 People
Tommy is a project manager on Project SRVUP in a strong matrix environment. This project is an application development project for insurance programs within the organization and has many compliance requirements. Recently, one of the project stakeholders approached him about a challenge with a team member, Roger. The stakeholder said that Roger was overwhelmed and could not accomplish a specific feature. The stakeholder wants Tommy to escalate the issue with Roger's manager. What should Tommy do next?
  1. A Review Roger's recent work to identify poor performance.
  2. B Talk to Roger's manager.
  3. C Reduce Roger's workload.
  4. D Thank the stakeholder for their concern and speak with Roger.
Xem giải thích

Đáp án

D — CẢM ƠN bên liên quan đã quan tâm và NÓI CHUYỆN TRỰC TIẾP VỚI ROGER.

Vì sao đúng

⚠ Vì sao nói chuyện với Roger là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Thông tin đến từ NGƯỜI THỨ BA, chưa được kiểm chứng | ⚠ Tommy mới chỉ nghe một phía | | ⚠ Roger là người DUY NHẤT biết mình thực sự đang gặp gì | ⚠ có thể quá tải, có thể vướng phụ thuộc, có thể thiếu thông tin | | ⚠ Tommy là quản lý dự án của Roger trong dự án | ⚠ nói chuyện với thành viên đội là việc bình thường của anh | | ⚠ Cảm ơn bên liên quan giữ được kênh thông tin mở | ⚠ họ sẽ tiếp tục báo những việc như thế lần sau | | ⚠ Tôn trọng phẩm giá của Roger | ⚠ anh được biết và được nói trước khi ai đó nói về anh | | ⚠ Kết luận | ⚠ kiểm chứng trước, hành động sau — và kiểm chứng ở nguồn gần nhất |

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

  • B (nói chuyện với quản lý trực tiếp của Roger) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trong ma trận mạnh, quản lý chức năng ĐÚNG LÀ người phụ trách nhân sự, và đó chính là điều bên liên quan đề nghị: ⚠ nhưng ⚠ leo thang trước khi nói với chính đương sự là bỏ qua một bậc ⚠ — nó biến một cuộc trò chuyện thành một hồ sơ nhân sự; ⚠ nếu Roger chỉ đang vướng một phụ thuộc kỹ thuật thì Tommy vừa làm hỏng quan hệ vì một việc lẽ ra giải quyết trong mười phút; ⚠ quản lý chức năng là bước SAU, nếu cần.

  • A (rà soát công việc gần đây của Roger để tìm bằng chứng hiệu suất kém) — ⚠ đi tìm bằng chứng buộc tội trước khi hỏi người trong cuộc; ⚠ và nó giả định sẵn rằng lời tố cáo là đúng.

  • C (giảm khối lượng việc của Roger) — ⚠ hành động khi chưa biết nguyên nhân; ⚠ nếu vấn đề không phải khối lượng thì việc này vô ích, và còn có thể khiến Roger thấy bị hạ thấp.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26469 cùng lô (thành viên gặp khó nhưng nói mọi thứ ổn — cùng chủ đề, nhìn từ góc khác), ⚠ #26234/#26235 lô 190 (quản lý dự án dự đoán đi tìm nguyên nhân gốc, scrum master hỏi đội), ⚠ #26442 cùng lô (khi nào leo thang), ⚠ #26476 cùng lô (leo thang khi chưa tự làm gì), ⚠ #26450 cùng lô (lắng nghe chủ động).

⚠ Nguyên tắc chung: NÓI CHUYỆN VỚI NGƯỜI TRONG CUỘC TRƯỚC: | Bậc | Việc | Khi nào | |---|---|---| | ⚠ 1 | ⚠ Nói chuyện trực tiếp với người liên quan | ⚠ LUÔN LUÔN bắt đầu ở đây — đáp án của câu này | | ⚠ 2 | ⚠ Cùng người đó tìm cách xử lý | ⚠ nếu vấn đề nằm trong tầm dự án | | ⚠ 3 | ⚠ Đưa quản lý chức năng vào cuộc | ⚠ nếu là vấn đề năng lực hoặc khối lượng kéo dài | | ⚠ 4 | ⚠ Leo thang lên nhà tài trợ | ⚠ nếu vượt thẩm quyền của cả hai | | ⚠ Vì sao thứ tự này gần như bất biến trong đề PMP | ⚠ mỗi bậc bỏ qua là một quan hệ bị tổn hại và một cơ hội giải quyết đơn giản bị mất — đề PMP gần như KHÔNG BAO GIỜ chọn phương án nhảy bậc khi bậc dưới còn khả thi | |

⚠ Tommy nên nói chuyện với Roger như thế nào: | Việc | Nội dung | |---|---| | ⚠ Gặp RIÊNG, không nhắc tới việc ai đã phản ánh | ⚠ nếu không, Roger sẽ phòng thủ với đồng nghiệp thay vì nói về công việc | | ⚠ Hỏi về CÔNG VIỆC, không hỏi về con người | ⚠ "tính năng này có chỗ nào đang vướng không" — liên hệ #26469 cùng lô | | ⚠ LẮNG NGHE CHỦ ĐỘNG | ⚠ liên hệ #26450 cùng lô | | ⚠ Hỏi Roger cần gì để tiến được | ⚠ anh thường biết câu trả lời | | ⚠ Cùng thống nhất bước tiếp theo | ⚠ có thể là giảm tải, có thể là gỡ phụ thuộc, có thể chỉ là làm rõ yêu cầu | | ⚠ Điều tuyệt đối tránh | ⚠ mở đầu bằng "có người nói anh không làm nổi việc này" — câu đó đóng cửa cuộc trò chuyện trước khi nó bắt đầu |

⚠ Vì sao bối cảnh MA TRẬN MẠNH lại càng ủng hộ đáp án D: | Khía cạnh | Nội dung | |---|---| | ⚠ Trong ma trận mạnh, quản lý dự án có thẩm quyền cao | ⚠ Tommy hoàn toàn có quyền làm việc trực tiếp với thành viên đội | | ⚠ Anh KHÔNG cần đi qua quản lý chức năng để trao đổi công việc | | | ⚠ Quản lý chức năng vẫn giữ vai trò về nhân sự dài hạn | ⚠ nên bậc 3 vẫn tồn tại, chỉ là chưa tới lúc | | ⚠ Dự án có nhiều yêu cầu TUÂN THỦ | ⚠ áp lực cao, càng cần biết chính xác vướng mắc thật là gì — liên hệ #26479 cùng lô | | ⚠ Nhận xét | ⚠ chi tiết "ma trận mạnh" trong đề thường xuất hiện chính để loại bỏ phương án "đi hỏi quản lý chức năng" — nó nói rằng quản lý dự án có đủ thẩm quyền tự xử lý |

Từ khoá nhận diện:

"bên liên quan phản ánh về một thành viên" → ⚠ CẢM ƠN, RỒI NÓI CHUYỆN VỚI CHÍNH NGƯỜI ĐÓ "báo lên quản lý của họ" → ⚠ nhảy bậc, biến trò chuyện thành hồ sơ "rà soát tìm bằng chứng hiệu suất kém" → ⚠ giả định sẵn lời tố cáo là đúng "giảm tải ngay" → ⚠ hành động trước khi biết nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khi nghe phản ánh về ai đó, phản xạ đầu tiên của bạn là gì | ⚠ hỏi người đó, hay tìm bằng chứng | | Đội bạn có biết rằng vấn đề sẽ được hỏi thẳng chứ không báo cáo lên trên không | ⚠ điều đó quyết định họ có dám nói ra khó khăn hay không | | Bạn có cảm ơn người mang tin tới không | ⚠ kể cả khi tin đó hoá ra không chính xác |

Và điều mà cách Tommy xử lý mười phút tới sẽ dạy cho cả đội: rằng ở dự án này, khi ai đó gặp khó, câu hỏi đầu tiên sẽ đến từ người muốn giúp — chứ không đến từ phòng nhân sự.