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

Tìm thấy 718 câu.

Câu 441 People
Ellen is the project manager for the Tufts Project, which has twenty-eight stakeholders in three different time zones. Of the following, which one, according to the communications model, means that communications happen when Ellen communicates with the project team?
  1. A The transfer of knowledge
  2. B The outputting of knowledge
  3. C The presence of knowledge
  4. D The transmission of knowledge
Xem giải thích

Đáp án

A — SỰ CHUYỂN GIAO TRI THỨC (the transfer of knowledge).

Vì sao đúng

⚠ Theo mô hình giao tiếp, giao tiếp chỉ xảy ra khi tri thức được CHUYỂN GIAO: | Yếu tố | Nội dung | |---|---| | ⚠ Người gửi MÃ HOÁ thông điệp | ⚠ biến ý nghĩ thành lời, chữ, hình | | ⚠ Thông điệp được TRUYỀN qua một kênh | ⚠ email, họp, cuộc gọi | | ⚠ Người nhận GIẢI MÃ và HIỂU | ⚠ đây mới là lúc tri thức được chuyển giao | | ⚠ PHẢN HỒI xác nhận điều đó đã xảy ra | ⚠ liên hệ #26753 lô 200 | | ⚠ Kết luận | ⚠ gửi đi không phải là giao tiếp; chỉ khi người nhận HIỂU thì tri thức mới thật sự chuyển giao |

⚠ Bối cảnh của Ellen làm điều này càng đúng: ⚠ hai mươi tám bên liên quan ở ba múi giờ ⚠ — ⚠ thông tin đi qua rất nhiều kênh, và mỗi kênh đều có thể làm mất mát ý nghĩa.

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

  • D (sự TRUYỀN ĐẠT tri thức — transmission) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "truyền đạt" nghe rất gần với "chuyển giao", và truyền tin đúng là một bước trong mô hình giao tiếp: ⚠ nhưng ⚠ TRUYỀN chỉ là việc đưa thông điệp lên kênh — nó có thể diễn ra hoàn hảo mà người nhận vẫn không hiểu gì ⚠ — ⚠ một email gửi thành công là truyền đạt thành công; nó chưa phải giao tiếp thành công; ⚠ ranh giới này chính là điều câu hỏi kiểm tra.

  • B (xuất ra tri thức — outputting) và C (sự hiện diện của tri thức — presence) — ⚠ cả hai đều không phải thuật ngữ trong mô hình giao tiếp; ⚠ chúng ghép từ nghe hợp lý nhưng vô nghĩa về mặt khái niệm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26753 lô 200 (giao tiếp hoàn tất ở phía người nhận), ⚠ #26889 cùng lô (giao tiếp phi ngôn ngữ), ⚠ #26921 cùng lô (agile ưu tiên gặp mặt trực tiếp), ⚠ #26926 cùng lô (giao tiếp kéo và đẩy), ⚠ #26932 cùng lô (bốn kiểu giao tiếp).

⚠ MÔ HÌNH GIAO TIẾP — các thành phần: | Thành phần | Nội dung | |---|---| | ⚠ NGƯỜI GỬI | ⚠ chịu trách nhiệm làm cho thông điệp rõ ràng và đầy đủ | | ⚠ MÃ HOÁ | ⚠ biến ý nghĩ thành ký hiệu: từ ngữ, hình ảnh | | ⚠ THÔNG ĐIỆP và KÊNH | ⚠ nội dung và phương tiện truyền tải | | ⚠ NHIỄU | ⚠ mọi thứ làm méo thông điệp: ngôn ngữ, văn hoá, kỹ thuật, cảm xúc | | ⚠ GIẢI MÃ | ⚠ người nhận diễn giải theo bối cảnh của họ | | ⚠ NGƯỜI NHẬN | ⚠ chịu trách nhiệm bảo đảm mình đã hiểu | | ⚠ PHẢN HỒI | ⚠ xác nhận việc chuyển giao tri thức đã xảy ra | | ⚠ Điều quan trọng nhất | ⚠ NHIỄU tồn tại ở mọi bước — nên giao tiếp không phải một hành động mà là một quá trình cần được kiểm chứng |

⚠ Vì sao Ellen cần chú ý điều này: | Yếu tố | Nội dung | |---|---| | ⚠ 28 bên liên quan | ⚠ số kênh giao tiếp = 28 × 27 ÷ 2 = 378 kênh | | ⚠ Ba múi giờ | ⚠ giao tiếp phần lớn là bất đồng bộ — liên hệ #26799 lô 201 | | ⚠ Không thấy được phản ứng của người nghe | ⚠ phản hồi phải được yêu cầu chủ động | | ⚠ Việc nên làm | ⚠ xây cơ chế xác nhận sự hiểu vào chính kế hoạch giao tiếp — với 378 kênh, việc giả định rằng ai cũng hiểu đúng là một giả định rất đắt |

Từ khoá nhận diện:

"giao tiếp xảy ra khi nào" → ⚠ khi tri thức được CHUYỂN GIAO "truyền đạt" → ⚠ chỉ là đưa thông điệp lên kênh, chưa phải giao tiếp "outputting / presence of knowledge" → ⚠ thuật ngữ bịa nguyên tắc → ⚠ gửi không bằng nhận, nhận không bằng HIỂU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn xác nhận người ta đã hiểu bằng cách nào | ⚠ "rõ chưa" không phải một cách | | Dự án bạn có bao nhiêu kênh giao tiếp | ⚠ n(n−1)/2 | | Có quyết định nào các bên đang hiểu khác nhau không | |

Và ranh giới mà mô hình giao tiếp vạch ra rất rõ ràng: bạn có thể gửi hoàn hảo, truyền hoàn hảo và vẫn chưa giao tiếp được gì — vì thứ duy nhất tính là điều cuối cùng nằm lại trong đầu người nhận.

Câu 442 Process
Your expertise in project management has been recognized, and you are invited to participate as a consultant to guide the project selection council committee. Your recommendation to the council is to engage the project teams within the organization and establish a set of direct questions for the team. Based on the information the team provides in the question and answer sessions, the selection council can determine which projects should be funded. Which project selection technique are you recommending?
  1. A Murder board
  2. B Defined benefit
  3. C Change control board
  4. D Scoring model
Xem giải thích

Đáp án

A — MURDER BOARD (hội đồng chất vấn).

Vì sao đúng

⚠ MURDER BOARD là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Một hội đồng CHẤT VẤN gay gắt người đề xuất dự án | ⚠ bằng một loạt câu hỏi trực diện | | ⚠ Mục đích: tìm ra điểm yếu trước khi cấp vốn | ⚠ thà bị "giết" ở đây còn hơn thất bại sau khi đã đầu tư | | ⚠ Dựa trên PHẢN HỒI TRỰC TIẾP từ đội dự án | ⚠ đúng như đề mô tả | | ⚠ Là phương pháp ĐỊNH TÍNH | ⚠ không dùng công thức toán | | ⚠ Kết luận | ⚠ hỏi trực tiếp và đánh giá qua câu trả lời — đó chính là murder board |

⚠ Tên gọi nghe khắc nghiệt nhưng ý nghĩa rất thực dụng: ⚠ một dự án không chịu nổi các câu hỏi khó trong phòng họp thì càng không chịu nổi thực tế ⚠ — ⚠ liên hệ #26643 lô 198 về phân tích tiền tử thi, cùng tinh thần.

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

  • D (mô hình cho điểm — scoring model) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là một phương pháp lựa chọn dự án chính thống và cũng dùng để so sánh nhiều dự án: ⚠ nhưng ⚠ mô hình cho điểm dựa trên các TIÊU CHÍ có trọng số và cho ra một CON SỐ ⚠ — ⚠ còn đề mô tả một phiên hỏi đáp trực tiếp với đội, tức là phương pháp định tính; ⚠ liên hệ #26902 cùng lô, nơi tổ chức muốn chuyển sang cách tiếp cận TOÁN HỌC hơn — hai câu này nằm ở hai đầu của cùng một trục.

  • C (ban kiểm soát thay đổi) — ⚠ cơ quan phê duyệt THAY ĐỔI trong một dự án đang chạy; ⚠ không liên quan tới việc chọn dự án.

  • B (defined benefit) — ⚠ thuật ngữ của lĩnh vực hưu trí và phúc lợi; ⚠ không phải phương pháp chọn dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26902 cùng lô (CÂU ĐỐI CHIẾU — chuyển sang phương pháp toán học), ⚠ #26840 lô 202 (ROI trong việc chọn dự án), ⚠ #26707 lô 198 (các chỉ số tài chính), ⚠ #26724 lô 199 (trường hợp kinh doanh), ⚠ #26643 lô 198 (tiền tử thi — cùng tinh thần chất vấn sớm).

⚠ CÁC PHƯƠNG PHÁP CHỌN DỰ ÁN — hai nhóm lớn: | Nhóm | Phương pháp | |---|---| | ⚠ ĐỊNH TÍNH (đánh giá lợi ích) | ⚠ MURDER BOARD — ĐÁP ÁN; mô hình cho điểm; so sánh cặp; phương pháp Delphi — liên hệ #26903 cùng lô | | ⚠ ĐỊNH LƯỢNG (toán học) | ⚠ NPV, IRR, ROI, thời gian hoàn vốn, quy hoạch động — liên hệ #26902 cùng lô | | ⚠ Cách phân biệt | ⚠ định tính dựa trên ĐÁNH GIÁ CỦA CON NGƯỜI; định lượng dựa trên CÔNG THỨC — và mô hình cho điểm nằm ở giữa vì nó lượng hoá các đánh giá định tính |

⚠ Murder board hoạt động thế nào: | Bước | Nội dung | |---|---| | ⚠ Đội trình bày đề xuất dự án | | | ⚠ Hội đồng đặt câu hỏi TRỰC DIỆN và KHÓ | ⚠ về giả định, rủi ro, năng lực, lợi ích | | ⚠ Đội trả lời tại chỗ | ⚠ chất lượng câu trả lời là dữ liệu chính | | ⚠ Hội đồng đánh giá dựa trên cả nội dung lẫn mức độ chuẩn bị | | | ⚠ Giá trị thật | ⚠ nó lộ ra ĐỘI đã suy nghĩ kỹ tới đâu — một đội trả lời được các câu hỏi khó thường cũng là đội sẽ xử lý được các vấn đề khó khi dự án chạy |

⚠ Ưu và nhược của phương pháp này: | Ưu | Nhược | |---|---| | ⚠ Phát hiện điểm yếu sớm, khi còn rẻ | ⚠ có thể quá khắc nghiệt với người thiếu kinh nghiệm trình bày | | ⚠ Đánh giá được cả năng lực của đội | ⚠ thiên vị người nói giỏi hơn người làm giỏi | | ⚠ Không cần dữ liệu tài chính đầy đủ | ⚠ kết quả phụ thuộc thành phần hội đồng | | ⚠ Cách dùng tốt nhất | ⚠ kết hợp với một phương pháp định lượng — murder board lọc ra các đề xuất chưa chín, còn các chỉ số tài chính so sánh những đề xuất đã vượt qua vòng đó |

Từ khoá nhận diện:

"hội đồng chất vấn trực tiếp đội đề xuất" → ⚠ MURDER BOARD "tiêu chí có trọng số cho ra điểm số" → ⚠ mô hình cho điểm "phương pháp toán học" → ⚠ định lượng — liên hệ #26902 cùng lô "ban kiểm soát thay đổi" → ⚠ phê duyệt thay đổi trong dự án, không chọn dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn chọn dự án bằng phương pháp nào | | | Ai đặt các câu hỏi khó trước khi một dự án được cấp vốn | | | Có dự án nào được duyệt mà không ai chất vấn giả định của nó không | |

Và điều mà cái tên nghe khắc nghiệt của phương pháp này thật sự bảo vệ: một dự án bị bác trong hai giờ họp rẻ hơn rất nhiều so với một dự án bị dừng sau mười tám tháng — và các câu hỏi khó ở cả hai thời điểm đều giống nhau.

Câu 443 Business Environment
Dennis is the project manager for Project Eggplant, which is intended to update several Paper Corporation data centers. Midway through the implementation, the database software vendor deploys a critical software update. This update may affect the project work that has been completed and will likely affect future work in the project. What is the best next step for Dennis?
  1. A Perform risk analysis.
  2. B Determine the impact take appropriate action.
  3. C Meet with the project team to assess the impact.
  4. D Begin the change management process.
Xem giải thích

Đáp án

D — BẮT ĐẦU QUY TRÌNH QUẢN LÝ THAY ĐỔI.

Vì sao đúng

⚠ Vì sao đây là bước đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Bản cập nhật ẢNH HƯỞNG tới công việc ĐÃ HOÀN THÀNH | ⚠ chạm tới đường cơ sở | | ⚠ Và sẽ ảnh hưởng tới công việc SẮP TỚI | ⚠ tác động hai chiều | | ⚠ Nó xuất hiện giữa lúc đang triển khai | ⚠ không nằm trong kế hoạch ban đầu | | ⚠ Quy trình quản lý thay đổi BAO GỒM cả việc đánh giá tác động | ⚠ đó là bước đầu tiên bên trong quy trình | | ⚠ Kết luận | ⚠ khởi động quy trình là cách bao trùm nhất, và mọi hành động khác đều nằm bên trong nó |

⚠ Vì sao "bắt đầu quy trình" thắng các phương án nêu một hành động lẻ: ⚠ quy trình quản lý thay đổi tự nó chứa việc phân tích tác động, tham vấn đội và đánh giá rủi ro ⚠ — ⚠ chọn một trong các bước con là chọn một phần thay vì chọn cả.

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

  • B (xác định tác động rồi hành động phù hợp) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đánh giá tác động thật sự là việc phải làm, và nó nghe rất hợp lý như bước đầu tiên: ⚠ nhưng ⚠ cụm "hành động phù hợp" quá mơ hồ và ngầm cho phép Dennis TỰ QUYẾT sau khi đánh giá ⚠ — ⚠ một thay đổi chạm tới công việc đã hoàn thành cần được PHÊ DUYỆT, không chỉ được đánh giá; ⚠ đánh giá tác động là một bước BÊN TRONG quy trình quản lý thay đổi, nên phương án D bao trùm phương án B.

  • C (họp với đội để đánh giá tác động) — ⚠ cũng là một bước bên trong quy trình; ⚠ và nó hẹp hơn vì chỉ có góc nhìn của đội.

  • A (phân tích rủi ro) — ⚠ một phần của việc đánh giá tác động; ⚠ hẹp hơn nữa.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26896 cùng lô (đưa yêu cầu tới quy trình kiểm soát thay đổi), ⚠ #26907 cùng lô (đánh giá tác động rồi nộp yêu cầu thay đổi), ⚠ #26910 cùng lô (cập nhật tài liệu sau khi thay đổi được duyệt), ⚠ #26870 lô 202 (thay đổi do sự kiện bên ngoài), ⚠ #26801 lô 201 (ghi nhận yêu cầu thay đổi).

⚠ Bản cập nhật của nhà cung cấp — vì sao nó là một thay đổi thật: | Tác động | Nội dung | |---|---| | ⚠ Công việc đã làm có thể phải kiểm thử lại | ⚠ hoặc phải làm lại | | ⚠ Công việc còn lại phải theo phiên bản mới | ⚠ đổi đặc tả kỹ thuật | | ⚠ Có thể phát sinh chi phí và thời gian | | | ⚠ Có thể phải cập nhật tài liệu và đào tạo | | | ⚠ Nếu KHÔNG cập nhật thì có rủi ro bảo mật hoặc hết hỗ trợ | ⚠ nên "không làm gì" cũng là một quyết định có rủi ro | | ⚠ Điều Dennis cần đưa ra bàn | ⚠ cả hai kịch bản — áp dụng bản cập nhật và KHÔNG áp dụng — đều có chi phí; nhiệm vụ của quy trình thay đổi là để người có thẩm quyền chọn giữa hai cái giá đó |

⚠ Vì sao chọn phương án BAO TRÙM lại là kỹ năng làm bài quan trọng: | Nguyên tắc | Nội dung | |---|---| | ⚠ Khi nhiều phương án đều đúng nhưng ở các mức khác nhau | ⚠ chọn phương án chứa các phương án kia | | ⚠ "Bắt đầu quy trình X" thường bao trùm các bước con của X | | | ⚠ Phương án nêu một hành động lẻ thường là bước con | | | ⚠ Cảnh báo ngược lại | ⚠ mẹo này chỉ áp dụng khi các phương án CÙNG NẰM trong một quy trình — nếu chúng thuộc các lĩnh vực khác nhau thì phải chọn theo nội dung, không theo độ bao trùm |

Từ khoá nhận diện:

"sự kiện bên ngoài ảnh hưởng công việc đã làm và sắp làm" → ⚠ BẮT ĐẦU QUY TRÌNH QUẢN LÝ THAY ĐỔI "đánh giá tác động rồi hành động phù hợp" → ⚠ một bước bên trong quy trình, và cụm "hành động phù hợp" quá mơ hồ "họp đội để đánh giá" → ⚠ hẹp hơn, chỉ một góc nhìn mẹo làm bài → ⚠ khi các phương án là các bước của cùng một quy trình, chọn phương án BAO TRÙM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản cập nhật của nhà cung cấp trong dự án bạn được xử lý thế nào | | | Ai quyết định có áp dụng hay không | | | Bạn có ghi rủi ro "phiên bản phụ thuộc thay đổi" vào sổ không | |

Và điều mà một bản cập nhật do bên thứ ba tung ra nhắc dự án của Dennis: có những thay đổi không ai trong dự án yêu cầu và cũng không ai từ chối được — và cách duy nhất xử lý chúng có kỷ luật là đưa chúng vào đúng cái quy trình vốn được lập ra cho những điều bất ngờ.

Câu 444 Process
You are the project manager for your organization. Your current project is to create a nature trail in a local park. This trail will not be paved but will have gravel as its base. The trail is a four-mile loop around a lake and has some rugged hiking portions. You are at a point in the project where you are ready to order the gravel materials, so you send a request for a quote to several vendors. How should the vendors respond?
  1. A Provide you with a proposal on how they will deliver the materials to the job site.
  2. B Provide you with a price for the gravel.
  3. C Provide you with a price for the gravel and how it will be delivered.
  4. D Invite you to a bidders conference to discuss the statement of work.
Xem giải thích

Đáp án

B — CUNG CẤP CHO BẠN MỘT MỨC GIÁ CHO SỎI.

Vì sao đúng

⚠ YÊU CẦU BÁO GIÁ (RFQ) hỏi cái gì: | Đặc điểm | Nội dung | |---|---| | ⚠ RFQ = Request for Quotation | ⚠ hỏi GIÁ, và chỉ hỏi giá | | ⚠ Dùng khi hàng hoá đã được ĐẶC TẢ RÕ RÀNG | ⚠ sỏi làm nền đường mòn — một mặt hàng chuẩn | | ⚠ Tiêu chí lựa chọn chủ yếu là GIÁ | | | ⚠ Nhà cung cấp không cần đề xuất giải pháp | ⚠ vì bài toán đã rõ | | ⚠ Kết luận | ⚠ hỏi gì thì nhận nấy — RFQ nhận về một con số |

⚠ Ba loại hồ sơ mời thầu và câu trả lời tương ứng: ⚠ RFQ hỏi GIÁ; RFP hỏi GIẢI PHÁP; IFB hỏi GIÁ THẦU cho một phạm vi đã định ⚠ — ⚠ chọn sai loại thì nhận về sai thứ mình cần.

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

  • C (báo giá sỏi VÀ cách giao hàng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trong thực tế, một báo giá vật liệu thường có kèm điều kiện giao hàng, nên phương án này nghe thực tế hơn cả đáp án: ⚠ nhưng ⚠ câu hỏi kiểm tra ĐỊNH NGHĨA của RFQ, và RFQ chỉ yêu cầu giá ⚠ — ⚠ nếu bạn cần cả phương án giao hàng thì phải đưa yêu cầu đó vào đặc tả hoặc dùng RFP; ⚠ bài học thực tế đi kèm: bạn chỉ nhận được thứ bạn hỏi, nên đặc tả thiếu sẽ cho ra các báo giá không so sánh được với nhau.

  • A (đề xuất về cách họ sẽ giao vật liệu tới công trường) — ⚠ đó là câu trả lời cho một RFP; ⚠ RFP hỏi về giải pháp và cách thực hiện.

  • D (mời bạn dự hội nghị nhà thầu để bàn về tuyên bố công việc) — ⚠ hội nghị nhà thầu do BÊN MUA tổ chức, không phải bên bán; ⚠ và nó diễn ra trước khi nhận hồ sơ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26916 cùng lô (khi nào không cần đấu thầu cạnh tranh), ⚠ #26930 cùng lô (hợp đồng cộng phí khuyến khích), ⚠ #26814 lô 201 (thư ý định), ⚠ #26850 lô 202 (nguồn đơn nhất và nguồn duy nhất), ⚠ #26684 lô 199 (tuyên bố công việc).

⚠ BA LOẠI HỒ SƠ MỜI THẦU: | Loại | Hỏi gì | Dùng khi | |---|---|---| | ⚠ RFQ — yêu cầu báo giá | ⚠ GIÁ — ĐÁP ÁN | ⚠ hàng hoá chuẩn, đặc tả đã rõ | | ⚠ RFP — yêu cầu đề xuất | ⚠ GIẢI PHÁP và cách thực hiện | ⚠ bài toán phức tạp, chưa rõ cách làm | | ⚠ IFB — thư mời thầu | ⚠ GIÁ THẦU cho một phạm vi đã định đầy đủ | ⚠ xây dựng, mua sắm công | | ⚠ Cách nhớ | ⚠ RFQ hỏi "bao nhiêu tiền"; RFP hỏi "anh sẽ làm thế nào"; IFB hỏi "anh nhận làm toàn bộ việc này với giá nào" |

⚠ Vì sao dự án đường mòn phù hợp với RFQ: | Yếu tố | Nội dung | |---|---| | ⚠ Sỏi là hàng hoá tiêu chuẩn | ⚠ các nhà cung cấp bán thứ gần như giống nhau | | ⚠ Yêu cầu kỹ thuật đơn giản và đã rõ | | | ⚠ Không cần nhà cung cấp sáng tạo giải pháp | | | ⚠ Giá là tiêu chí phân biệt chính | | | ⚠ Điều cần cẩn thận | ⚠ đặc tả phải nêu rõ LOẠI SỎI, KHỐI LƯỢNG, thời điểm và địa điểm giao — nếu không, các báo giá nhận về sẽ không so sánh được với nhau, và toàn bộ mục đích của việc dùng RFQ bị mất |

⚠ HỘI NGHỊ NHÀ THẦU — làm rõ khái niệm ở phương án D: | Đặc điểm | Nội dung | |---|---| | ⚠ Do BÊN MUA tổ chức | ⚠ không phải bên bán mời | | ⚠ Diễn ra TRƯỚC khi nộp hồ sơ | | | ⚠ Mục đích: mọi nhà cung cấp hiểu yêu cầu như nhau | | | ⚠ Câu hỏi và câu trả lời được chia sẻ cho TẤT CẢ | ⚠ bảo đảm công bằng | | ⚠ Vì sao nó quan trọng | ⚠ nó ngăn tình trạng một nhà cung cấp có thông tin tốt hơn những người khác — và đó là điều kiện để cuộc đấu thầu có ý nghĩa |

Từ khoá nhận diện:

"yêu cầu báo giá (RFQ)" → ⚠ nhà cung cấp trả lời bằng GIÁ "yêu cầu đề xuất (RFP)" → ⚠ trả lời bằng GIẢI PHÁP "hội nghị nhà thầu" → ⚠ do BÊN MUA tổ chức, trước khi nộp hồ sơ nguyên tắc → ⚠ bạn nhận được đúng thứ bạn hỏi, nên đặc tả quyết định chất lượng hồ sơ nhận về

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang dùng loại hồ sơ nào cho lần mua sắm tới | | | Đặc tả của bạn đủ rõ để các báo giá so sánh được không | | | Bạn có tổ chức hội nghị nhà thầu khi cần không | |

Và điều mà việc chọn đúng loại hồ sơ quyết định: bạn nhận về năm con số so sánh được với nhau, hay năm bản đề xuất mà mỗi bản nói về một thứ khác nhau và không cái nào đặt cạnh cái nào được.

Câu 445 People
Your organization has accepted a contract to construct a bridge in your city. As part of this incentive-based contract, the organization, you, and your project team will receive a sizeable bonus for every day you complete the project ahead of schedule. As the project manager, you have shared the incentive goal with your project team and they have agreed to work six days a week, rather than the usual five. Three months into the project the project is clearly four weeks ahead of schedule if the team had worked the usual five days a week. However, you notice that several of your team members are visibly stressed with the workload and long hours the project is requiring. You are concerned the project team may begin to falter as they are overworked and tired. What should you do next in the scenario to mitigate the risk of the team's energy and buy-in on the project?
  1. A Recommend that the team takes a few days off from the project work.
  2. B Use your emotional intelligence to understand why the team is tired.
  3. C Ask the team if they would like more people to work on the bridge project.
  4. D Remind the team why they are working all the overtime.
Xem giải thích

Đáp án

A — ĐỀ NGHỊ ĐỘI NGHỈ VÀI NGÀY KHỎI CÔNG VIỆC DỰ ÁN.

Vì sao đúng

⚠ Vì sao cho đội nghỉ là việc đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Đội làm SÁU ngày một tuần suốt BA THÁNG | ⚠ nhịp độ không bền vững kéo dài | | ⚠ Nhiều thành viên đã CĂNG THẲNG THẤY RÕ | ⚠ dấu hiệu kiệt sức đã lộ ra bên ngoài | | ⚠ Dự án ĐANG SỚM HƠN KẾ HOẠCH bốn tuần | ⚠ có dư địa thật để nghỉ | | ⚠ Nghỉ là hành động CỤ THỂ giải quyết nguyên nhân | ⚠ không phải chỉ thấu hiểu hay giải thích | | ⚠ Kết luận | ⚠ có dư địa, có dấu hiệu kiệt sức — dùng dư địa đó cho con người là quyết định đúng |

⚠ Nguyên tắc NHỊP ĐỘ BỀN VỮNG của agile áp dụng cho mọi dự án: ⚠ một đội kiệt sức sẽ mắc nhiều lỗi hơn, và phần thời gian tiết kiệm được sẽ mất lại vào việc sửa ⚠ — ⚠ liên hệ #26674 lô 198.

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

  • B (dùng trí tuệ cảm xúc để hiểu vì sao đội mệt) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trí tuệ cảm xúc là năng lực quan trọng và việc thấu hiểu đội luôn được đề PMP đánh giá cao: ⚠ nhưng ⚠ nguyên nhân đã QUÁ RÕ RÀNG — họ làm sáu ngày một tuần trong ba tháng ⚠ — ⚠ không cần thêm sự thấu hiểu nào để biết vì sao họ mệt; điều cần là HÀNH ĐỘNG; ⚠ thấu hiểu mà không hành động, trong tình huống nguyên nhân đã rõ, chỉ là sự trì hoãn có vẻ tử tế.

  • C (hỏi đội có muốn thêm người vào dự án không) — ⚠ thêm người giữa chừng làm chậm hơn; ⚠ liên hệ #26831 lô 201 về định luật Brooks.

  • D (nhắc đội lý do vì sao họ làm thêm giờ) — ⚠ dùng tiền thưởng để đẩy đội đi tiếp; ⚠ đây là phản ứng tệ nhất khi đã thấy dấu hiệu kiệt sức.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ở cuối ("…several of your team members are visibly stressed with the workload and long hours") ⚠ — ⚠ câu hỏi đầy đủ hỏi bạn nên làm gì; ⚠ khoá được giữ nguyên vì phần đề còn lại đã đủ dữ kiện.

⚠ Đối chiếu: ⚠ #26674 lô 198 (nhịp độ bền vững), ⚠ #26859 lô 202 (nhận ra dấu hiệu sa sút ở thành viên), ⚠ #26831 lô 201 (thêm người không làm nhanh hơn), ⚠ #26846 lô 202 (giám sát mức gắn kết), ⚠ #26927 cùng lô (thấu cảm với thành viên gặp khó khăn).

⚠ Vì sao hợp đồng khuyến khích tạo ra chính cái bẫy này: | Cơ chế | Nội dung | |---|---| | ⚠ Thưởng theo NGÀY hoàn thành sớm | ⚠ tạo áp lực làm thêm liên tục | | ⚠ Phần thưởng thuộc về cả đội | ⚠ nên áp lực đến từ chính đồng đội, khó từ chối hơn | | ⚠ Không có cơ chế tự dừng | ⚠ càng sớm càng nhiều tiền, nên không có điểm đủ | | ⚠ Rủi ro chất lượng bị bỏ qua | ⚠ cầu là công trình an toàn — lỗi ở đây rất đắt | | ⚠ Trách nhiệm của người quản lý dự án | ⚠ hợp đồng khuyến khích không được phép biến thành lý do bỏ qua an toàn và sức khoẻ của đội — và người duy nhất có thể nói dừng lại chính là bạn, vì đội đang bị chính khoản thưởng của họ thúc đi |

⚠ Nghỉ vài ngày không làm mất bốn tuần lợi thế: | Tính toán | Nội dung | |---|---| | ⚠ Dự án đang sớm hơn BỐN TUẦN | | | ⚠ Nghỉ vài ngày tiêu chưa tới một tuần trong đó | | | ⚠ Đội nghỉ ngơi sẽ làm việc năng suất hơn sau đó | ⚠ có thể bù lại phần lớn | | ⚠ Giảm rủi ro lỗi và tai nạn | ⚠ với công trình xây dựng, đây là lập luận mạnh nhất | | ⚠ Cách trình bày với đội và với tổ chức | ⚠ nói bằng con số: chúng ta còn dư ba tuần rưỡi sau khi nghỉ, và mỗi sai sót do mệt mỏi có thể tốn nhiều hơn thế — đó là lập luận mà cả đội lẫn ban lãnh đạo đều nghe được |

Từ khoá nhận diện:

"đội kiệt sức, dự án đang sớm hơn kế hoạch" → ⚠ CHO ĐỘI NGHỈ "dùng trí tuệ cảm xúc để hiểu" → ⚠ nguyên nhân đã rõ, cần hành động chứ không cần thêm hiểu biết "thêm người vào" → ⚠ làm chậm hơn giữa chừng dự án "nhắc lại lý do làm thêm giờ" → ⚠ đẩy đội đi tiếp khi họ đã kiệt sức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn đã làm thêm giờ liên tục bao lâu | | | Có ai đang có dấu hiệu kiệt sức không | ⚠ hỏi thẳng, đừng đợi họ nói | | Dư địa tiến độ hiện tại của bạn dùng vào việc gì | |

Và điều mà một khoản thưởng theo ngày dễ khiến người ta quên: bốn tuần sớm hơn kế hoạch là một con số rất đẹp trong báo cáo, nhưng nó được mua bằng ba tháng làm sáu ngày một tuần — và cái giá đó đang được ghi ở một nơi mà không bảng theo dõi tiến độ nào hiển thị.

Câu 446 Process
In agile projects, risks and threats can be considered as
  1. A Less formal, as agile projects do not require risk registers
  2. B Irrelevant to the agile methodology
  3. C The opposite of value
  4. D A minor part of any project
Xem giải thích

Đáp án

C — ĐỐI LẬP CỦA GIÁ TRỊ (the opposite of value).

Vì sao đúng

⚠ Vì sao agile nhìn rủi ro như phản giá trị: | Lập luận | Nội dung | |---|---| | ⚠ Agile tổ chức mọi thứ quanh việc GIAO GIÁ TRỊ | ⚠ tồn đọng được xếp theo giá trị | | ⚠ Rủi ro làm GIẢM hoặc ĐE DOẠ giá trị sẽ giao được | ⚠ nên nó là phản giá trị | | ⚠ Cách khung hoá này cho phép xếp rủi ro CÙNG THANG với tính năng | ⚠ cả hai cùng nằm trong tồn đọng | | ⚠ Hạng mục giảm rủi ro cạnh tranh chỗ với hạng mục tạo giá trị | ⚠ và được xếp ưu tiên theo cùng một tiêu chí | | ⚠ Kết luận | ⚠ coi rủi ro là phản giá trị giúp quản lý nó bằng chính cơ chế đã có: tồn đọng có xếp ưu tiên |

⚠ Hệ quả thực tế: ⚠ một hạng mục giảm rủi ro lớn có thể được xếp trên một tính năng hấp dẫn ⚠ — ⚠ liên hệ #26749 lô 200 về việc làm hạng mục rủi ro cao sớm nhất có thể.

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

  • A (ít trang trọng hơn, vì dự án agile không cần sổ đăng ký rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ agile thật sự nhẹ về tài liệu, nên "không cần sổ đăng ký" nghe rất khớp với tinh thần đó: ⚠ nhưng ⚠ agile KHÔNG bỏ việc quản lý rủi ro — nó chỉ tích hợp rủi ro vào tồn đọng và vào các buổi họp thường kỳ thay vì tách thành một tài liệu riêng ⚠ — ⚠ nhiều đội agile vẫn giữ sổ đăng ký rủi ro hoặc một danh sách rủi ro trên bảng trực quan; ⚠ liên hệ #26876 lô 202: agile giảm tài liệu xuống mức vừa đủ chứ không về không.

  • B (không liên quan tới agile) — ⚠ sai hoàn toàn; ⚠ agile ra đời chính để đối phó với bất định.

  • D (một phần nhỏ của mọi dự án) — ⚠ hạ thấp vai trò của quản lý rủi ro; ⚠ trái với thực tế của mọi phương pháp.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26749 lô 200 (làm hạng mục rủi ro cao sớm nhất có thể), ⚠ #26892 cùng lô (ai tham gia nhận diện rủi ro trong agile), ⚠ #26899 cùng lô (chấp nhận rủi ro), ⚠ #26924 cùng lô (quá nhiều việc dở dang là một rủi ro), ⚠ #26909 cùng lô (đón nhận thay đổi).

⚠ QUẢN LÝ RỦI RO TRONG AGILE — làm khác chứ không bỏ: | Cách làm truyền thống | Cách làm agile | |---|---| | ⚠ Sổ đăng ký rủi ro riêng, rà soát định kỳ | ⚠ rủi ro nằm ngay trong TỒN ĐỌNG như một hạng mục | | ⚠ Phân tích định lượng chi tiết | ⚠ xếp ưu tiên tương đối cùng các hạng mục khác | | ⚠ Cuộc họp rủi ro riêng | ⚠ bàn trong họp đứng, lập kế hoạch vòng lặp và hồi cứu | | ⚠ Chủ rủi ro được chỉ định | ⚠ cả đội cùng chịu trách nhiệm | | ⚠ Điểm chung | ⚠ cả hai đều nhằm NHÌN THẤY rủi ro sớm và làm gì đó với nó — chỉ khác ở chỗ đặt thông tin đó vào đâu |

⚠ Vì sao vòng lặp ngắn tự nó đã là một cơ chế giảm rủi ro: | Cơ chế | Nội dung | |---|---| | ⚠ Giao sớm và thường xuyên | ⚠ rủi ro "làm sai thứ khách cần" được kiểm chứng liên tục | | ⚠ Tích hợp liên tục | ⚠ rủi ro kỹ thuật lộ ra trong vài giờ — liên hệ #26793 lô 201 | | ⚠ Làm phần khó trước | ⚠ liên hệ #26749 lô 200 | | ⚠ Hồi cứu mỗi vòng lặp | ⚠ rủi ro quy trình được xử lý đều đặn | | ⚠ Nhận xét | ⚠ agile không có một quy trình quản lý rủi ro tách biệt vì phần lớn cấu trúc của nó ĐÃ LÀ một cơ chế giảm rủi ro — nhưng điều đó không có nghĩa là đội được phép ngừng nghĩ về rủi ro một cách có ý thức |

⚠ Cách đưa rủi ro vào tồn đọng: | Việc | Nội dung | |---|---| | ⚠ Viết hạng mục giảm rủi ro như một câu chuyện | ⚠ "để giảm rủi ro X, chúng ta cần làm Y" | | ⚠ Ước lượng nó như mọi hạng mục khác | | | ⚠ Xếp ưu tiên theo mức rủi ro nó gỡ bỏ | ⚠ rủi ro càng lớn thì càng lên trên | | ⚠ Dùng spike cho các rủi ro cần nghiên cứu | ⚠ liên hệ #26749 lô 200 | | ⚠ Lợi ích lớn nhất | ⚠ rủi ro thôi là một danh sách mà không ai đọc và trở thành công việc thật có người làm — đó chính là giá trị của việc khung hoá nó như phản giá trị |

Từ khoá nhận diện:

"rủi ro trong agile" → ⚠ ĐỐI LẬP CỦA GIÁ TRỊ "agile không cần sổ đăng ký rủi ro" → ⚠ agile làm KHÁC chứ không bỏ "rủi ro không liên quan tới agile" → ⚠ sai hoàn toàn hệ quả thực tế → ⚠ hạng mục giảm rủi ro cạnh tranh chỗ với tính năng trong cùng một tồn đọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro trong dự án agile của bạn được ghi ở đâu | | | Có hạng mục nào trong tồn đọng tồn tại để giảm rủi ro không | | | Đội bạn nói về rủi ro trong cuộc họp nào | |

Và điều mà cách khung hoá "rủi ro là phản giá trị" làm được: nó đưa rủi ro vào đúng cuộc trò chuyện mà đội đã có hằng ngày — thay vì để nó nằm trong một tài liệu riêng mà mọi người chỉ mở ra khi đã quá muộn.

Câu 447 People
Daily, Diego's project team utilizes phone calls and e-mails to send and receive information. For project team members who are located in the same geographical area, Diego, as project manager, would like to have more face-to-face, interactive meetings. Jessica, a team member, asks why, and Diego tells her it is because of the nonverbal language advantages. Of the following, what percentage of a message is sent through nonverbal communication, such as hand gestures, body language, and facial expressions?
  1. A 20 to 30 percent
  2. B More than 50%
  3. C 30 to 40 percent
  4. D 10 to 20 percent
Xem giải thích

Đáp án

B — HƠN 50%.

Vì sao đúng

⚠ Quy tắc kinh nghiệm được PMI dẫn lại: | Thành phần | Tỉ lệ ước tính | |---|---| | ⚠ NGÔN NGỮ CƠ THỂ, cử chỉ, nét mặt | ⚠ hơn 50% — ĐÁP ÁN | | ⚠ Giọng điệu, ngữ điệu, tốc độ nói | ⚠ khoảng 35–40% | | ⚠ TỪ NGỮ thực tế được nói ra | ⚠ chỉ khoảng 7–10% | | ⚠ Hệ quả trực tiếp | ⚠ email và tin nhắn mất đi hơn 90% các tín hiệu — đó là lý do Diego muốn gặp mặt |

⚠ Đây là cơ sở của nguyên tắc agile ưu tiên trao đổi trực tiếp ⚠ — ⚠ liên hệ #26921 cùng lô.

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

  • C (30 đến 40 phần trăm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ con số này TRÙNG với tỉ lệ thường được gán cho GIỌNG ĐIỆU trong cùng mô hình, nên nó xuất hiện thật trong tài liệu và dễ bị nhớ nhầm vị trí: ⚠ nhưng ⚠ câu hỏi hỏi về ngôn ngữ cơ thể, cử chỉ và nét mặt — tức là phần PHI NGÔN NGỮ THUẦN TUÝ, và phần đó chiếm hơn một nửa ⚠ — ⚠ cách nhớ an toàn: từ ngữ chiếm phần NHỎ NHẤT, ngôn ngữ cơ thể chiếm phần LỚN NHẤT.

  • A (20 đến 30 phần trăm) và D (10 đến 20 phần trăm) — ⚠ cả hai đều quá thấp; ⚠ chúng gần với tỉ lệ của từ ngữ hơn là của ngôn ngữ cơ thể.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ các con số này bắt nguồn từ nghiên cứu của Mehrabian, vốn được thực hiện trong bối cảnh RẤT HẸP — khi lời nói và cảm xúc MÂU THUẪN nhau ⚠ — ⚠ áp dụng chúng cho mọi loại giao tiếp là một sự khái quát hoá quá mức mà chính tác giả đã nhiều lần phản đối; ⚠ KHOÁ ĐƯỢC GIỮ NGUYÊN vì đây là con số mà tài liệu quản lý dự án vẫn dùng, và kỳ thi hỏi theo tài liệu đó; ⚠ điều nên nhớ cho thực tế: kết luận ĐÚNG là "kênh giàu truyền tải nhiều hơn kênh nghèo", còn con số chính xác thì không nên coi là một hằng số khoa học.

⚠ Đối chiếu: ⚠ #26921 cùng lô (agile ưu tiên gặp mặt trực tiếp), ⚠ #26932 cùng lô (bốn kiểu giao tiếp), ⚠ #26692 lô 199 (chọn kênh giàu cho việc phức tạp), ⚠ #26827 lô 201 (khi kênh viết lại phù hợp hơn), ⚠ #26883 cùng lô (mô hình giao tiếp).

⚠ THANG ĐỘ GIÀU của kênh giao tiếp — nhắc lại: | Kênh | Giữ được gì | |---|---| | ⚠ Gặp mặt trực tiếp | ⚠ từ ngữ + giọng điệu + ngôn ngữ cơ thể — đầy đủ nhất | | ⚠ Họp video | ⚠ gần như đầy đủ, mất một phần cử chỉ toàn thân | | ⚠ Điện thoại | ⚠ từ ngữ + giọng điệu, mất hoàn toàn phần hình | | ⚠ Chat | ⚠ chỉ từ ngữ, có tốc độ phản hồi nhanh | | ⚠ Email | ⚠ chỉ từ ngữ, bất đồng bộ | | ⚠ Kết luận thực dụng | ⚠ mỗi bước xuống thang là mất một lớp thông tin — và với các cuộc trao đổi có yếu tố cảm xúc hoặc dễ hiểu lầm, những lớp bị mất đó chính là lớp quan trọng nhất |

⚠ Diego nên tổ chức thế nào: | Việc | Nội dung | |---|---| | ⚠ Gặp mặt cho các cuộc trao đổi PHỨC TẠP hoặc NHẠY CẢM | ⚠ thiết kế, xung đột, phản hồi | | ⚠ Giữ email và điện thoại cho thông tin thường lệ | ⚠ liên hệ #26827 lô 201 | | ⚠ Với người ở xa thì dùng họp video có bật hình | | | ⚠ Ghi lại quyết định bằng văn bản sau khi gặp | ⚠ kênh giàu để hiểu nhau, kênh nghèo để lưu vết | | ⚠ Điều đáng nói với Jessica | ⚠ không phải "email là xấu" mà là "email không phù hợp cho loại trao đổi này" — cùng một công cụ có thể là lựa chọn tốt nhất hoặc tệ nhất tuỳ nội dung |

Từ khoá nhận diện:

"ngôn ngữ cơ thể, cử chỉ, nét mặt" → ⚠ HƠN 50% thông điệp "giọng điệu" → ⚠ khoảng 35–40% "từ ngữ" → ⚠ chỉ khoảng 7–10% — phần nhỏ nhất cảnh báo → ⚠ con số này là quy tắc kinh nghiệm trong bối cảnh hẹp, đừng coi là hằng số khoa học

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các cuộc trao đổi khó trong dự án bạn diễn ra qua kênh nào | | | Có hiểu lầm nào gần đây bắt nguồn từ một email không | | | Bạn có bật hình trong các cuộc họp quan trọng không | |

Và điều mà các con số này nói lên, dù bản thân chúng chỉ là ước lượng thô: phần lớn thứ bạn truyền đi không nằm trong câu chữ — nên mỗi lần chọn email cho một việc tế nhị là một lần bạn tự nguyện bỏ đi phần lớn công cụ của mình.

Câu 448 Process

Jamie, a team member for Project Lion, reviewed project documentation and found the following table misfiled (see below). She asks her project team, but no one knows what it is for, so she asks the project manager. What is the most likely use for this table?


  1. A Expense account limits.
  2. B It is a useless artifact and may be discarded.
  3. C Bonus amounts at project completion.
  4. D Cost escalation thresholds.
Xem giải thích

Đáp án

D — NGƯỠNG LEO THANG CHI PHÍ (cost escalation thresholds).

Vì sao đúng

⚠ Suy ra từ bốn phương án và bối cảnh: | Manh mối | Ý nghĩa | |---|---| | ⚠ Đây là một BẢNG trong hồ sơ dự án | ⚠ một hiện vật chính thức, không phải ghi chú cá nhân | | ⚠ Không ai trong đội biết nó dùng để làm gì | ⚠ gợi ý đây là công cụ của cấp quản lý dự án chứ không của người thực hiện | | ⚠ Ngưỡng leo thang là một bảng CÓ THẬT trong quản lý dự án | ⚠ quy định mức chi vượt bao nhiêu thì phải báo lên ai | | ⚠ Ba phương án còn lại đều bất thường hoặc vô lý | ⚠ loại trừ được bằng logic | | ⚠ Kết luận | ⚠ một bảng ngưỡng bằng tiền trong hồ sơ dự án gần như chắc chắn là ngưỡng leo thang |

⚠ NGƯỠNG LEO THANG trả lời câu hỏi: ⚠ "vượt bao nhiêu thì tôi tự quyết, vượt bao nhiêu thì phải xin ai" ⚠ — ⚠ liên hệ #26836 lô 202 về ngưỡng trong kế hoạch quản lý thay đổi.

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

  • A (hạn mức tài khoản chi tiêu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hạn mức chi tiêu cũng là một bảng các con số tiền và cũng tồn tại thật trong nhiều tổ chức: ⚠ nhưng ⚠ hạn mức chi tiêu cá nhân là tài liệu của bộ phận TÀI CHÍNH hoặc NHÂN SỰ, không nằm trong hồ sơ dự án ⚠ — ⚠ và nó áp cho từng người theo chức vụ, không gắn với dự án cụ thể nào; ⚠ bối cảnh "tài liệu dự án bị xếp nhầm chỗ" gợi ý một hiện vật của chính dự án.

  • C (mức thưởng khi hoàn thành dự án) — ⚠ thông tin nhân sự nhạy cảm, thường không nằm trong hồ sơ dự án lưu hành chung; ⚠ và đề không nhắc gì tới cơ chế thưởng.

  • B (một hiện vật vô dụng, có thể vứt đi) — ⚠ kết luận vội vàng và nguy hiểm; ⚠ trong đề PMP, phương án "vứt đi" hoặc "không làm gì" gần như luôn sai.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này PHỤ THUỘC VÀO MỘT BẢNG mà bộ nguồn không nhập được ("see below") ⚠ — ⚠ khoá được giữ nguyên vì bốn phương án đủ để suy luận: chỉ có một phương án mô tả một hiện vật chuẩn của quản lý dự án; ⚠ kỹ năng dùng khi gặp câu phụ thuộc hình: ánh xạ từng phương án về một loại tài liệu cụ thể, rồi chọn cái phù hợp nhất với bối cảnh mà đề mô tả bằng lời.

⚠ Đối chiếu: ⚠ #26836 lô 202 (ngưỡng trong kế hoạch quản lý thay đổi), ⚠ #26893 cùng lô (leo thang theo hướng dẫn của dự án), ⚠ #26904 cùng lô (đường leo thang đã thiết lập), ⚠ #26845 lô 202 (đường leo thang và kế hoạch dự phòng), ⚠ #26907 cùng lô (thẩm quyền phê duyệt theo mức).

⚠ NGƯỠNG LEO THANG dùng để làm gì: | Chức năng | Nội dung | |---|---| | ⚠ Xác định mức tự quyết của người quản lý dự án | ⚠ dưới ngưỡng thì tự xử lý | | ⚠ Xác định khi nào phải báo nhà tài trợ hoặc ban chỉ đạo | | | ⚠ Loại bỏ tranh cãi lúc đang căng thẳng | ⚠ quy tắc được đặt ra khi chưa có ca cụ thể nào | | ⚠ Bảo đảm nhất quán giữa các dự án | | | ⚠ Vì sao nó quý | ⚠ nó biến câu hỏi "việc này có đáng báo cáo lên không" từ một phán đoán cá nhân thành một phép so sánh — và nhờ đó không ai phải tự chịu trách nhiệm về việc đã im lặng |

⚠ Vì sao không ai trong đội biết bảng này: | Lý do | Nội dung | |---|---| | ⚠ Nó là công cụ của người QUẢN LÝ, không của người thực hiện | | | ⚠ Nó hiếm khi được dùng tới trong ngày thường | ⚠ chỉ dùng khi có sai lệch | | ⚠ Nó có thể do PMO ban hành và ít được phổ biến | | | ⚠ Điều đáng làm sau khi Jamie hỏi | ⚠ giải thích cho cả đội hiểu ngưỡng đó nghĩa là gì — một đội biết khi nào cần báo lên sẽ báo sớm hơn nhiều, liên hệ #26893 cùng lô |

⚠ Nhóm câu hỏi về LEO THANG trong lô này: | Câu | Nội dung | |---|---| | ⚠ #26890 (câu này) | ⚠ bảng ngưỡng leo thang chi phí | | ⚠ #26893 | ⚠ leo thang theo hướng dẫn của dự án khi phát hiện chi phí làm lại | | ⚠ #26904 | ⚠ tham chiếu đường leo thang đã thiết lập cho quy trình mất kiểm soát | | ⚠ Nhận xét | ⚠ ba câu trong một lô cùng kiểm tra một ý: KHÔNG tự quyết cũng KHÔNG leo thang bừa, mà tra đúng ngưỡng đã được thoả thuận trước |

Từ khoá nhận diện:

"bảng ngưỡng bằng tiền trong hồ sơ dự án" → ⚠ NGƯỠNG LEO THANG CHI PHÍ "hạn mức chi tiêu cá nhân" → ⚠ tài liệu của tài chính hoặc nhân sự, không của dự án "vứt đi vì không ai biết" → ⚠ gần như luôn sai trong đề PMP câu phụ thuộc hình → ⚠ ánh xạ từng phương án về một loại tài liệu rồi so với bối cảnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết ngưỡng tự quyết của mình là bao nhiêu không | | | Đội bạn có biết khi nào cần báo lên không | | | Có tài liệu nào trong hồ sơ dự án mà không ai hiểu để làm gì không | ⚠ nó đáng được giải thích chứ không đáng bị vứt |

Và điều mà một bảng ngưỡng nằm im trong hồ sơ suốt cả dự án thể hiện: hoặc mọi thứ đang rất suôn sẻ, hoặc có người đang tự quyết những việc lẽ ra phải báo lên — và chỉ có một cách để biết là cái nào.

Câu 449 Process
You are the scrum master for a technical project in your organization that will replace a current software with a newer version your team is developing. You have been working closely with your scrum team's product owner to understand the various business requirements. The product owner has prioritized these requirements according to the user's urgency and the business value gained through its fulfillment. Upon meeting with the entire scrum team, the developers have also spent time prioritizing their sprint requirements. The product owner wants to track items the team will complete in the current sprint. Which document would be most useful to the product owner?
  1. A Release planning document
  2. B Product backlog
  3. C Sprint backlog
  4. D Project management plan 
Xem giải thích

Đáp án

C — TỒN ĐỌNG SPRINT (sprint backlog).

Vì sao đúng

⚠ Vì sao đây là tài liệu đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Chủ sản phẩm muốn theo dõi các hạng mục ĐỘI SẼ HOÀN THÀNH TRONG SPRINT HIỆN TẠI | ⚠ đúng định nghĩa tồn đọng sprint | | ⚠ Đội phát triển đã xếp thứ tự công việc của sprint | ⚠ tồn đọng sprint do ĐỘI sở hữu | | ⚠ Đây là phạm vi CAM KẾT của một vòng lặp | ⚠ khác với toàn bộ danh sách công việc | | ⚠ Kết luận | ⚠ muốn biết vòng lặp này làm gì thì nhìn tồn đọng sprint |

⚠ Phân biệt cốt lõi: ⚠ TỒN ĐỌNG SẢN PHẨM là mọi thứ CÓ THỂ làm; TỒN ĐỌNG SPRINT là những gì SẼ làm trong vòng lặp này ⚠ — ⚠ liên hệ #26825 lô 201.

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

  • B (tồn đọng sản phẩm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đề dành phần lớn câu chữ để nói về việc chủ sản phẩm xếp ưu tiên các yêu cầu, và đó chính là công việc trên tồn đọng sản phẩm: ⚠ nhưng ⚠ tồn đọng sản phẩm chứa TOÀN BỘ công việc còn lại của cả sản phẩm, không cho biết vòng lặp này làm gì ⚠ — ⚠ câu hỏi nói rõ "các hạng mục đội sẽ hoàn thành trong SPRINT HIỆN TẠI"; ⚠ phần mô tả về chủ sản phẩm ở đầu đề là bối cảnh, không phải câu trả lời.

  • A (tài liệu lập kế hoạch phát hành) — ⚠ ở tầng cao hơn, cho biết bản phát hành gồm những gì; ⚠ không chi tiết tới mức một vòng lặp.

  • D (kế hoạch quản lý dự án) — ⚠ tài liệu của vòng đời dự đoán; ⚠ nói về cách quản lý chứ không liệt kê công việc của sprint.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ở cuối ("Which document would be most useful to…") ⚠ — ⚠ ý đầy đủ là tài liệu nào hữu ích nhất để theo dõi điều đó; ⚠ khoá giữ nguyên vì phần đề còn lại nêu rõ nhu cầu.

⚠ Đối chiếu: ⚠ #26825 lô 201 (phân biệt hai tồn đọng), ⚠ #26909 cùng lô (kế hoạch thay đổi khi học được thêm), ⚠ #26919 cùng lô (ước lượng điểm câu chuyện), ⚠ #26924 cùng lô (quá nhiều hạng mục dở dang trong sprint), ⚠ #26908 cùng lô (bảng thông tin trực quan).

⚠ CÁC TẦNG KẾ HOẠCH trong agile — từ xa tới gần: | Tầng | Nội dung | Ai sở hữu | |---|---|---| | ⚠ Tầm nhìn sản phẩm | ⚠ mục tiêu dài hạn | ⚠ chủ sản phẩm | | ⚠ Lộ trình sản phẩm | ⚠ các chủ đề lớn theo quý | ⚠ chủ sản phẩm | | ⚠ Kế hoạch phát hành | ⚠ bản phát hành tới gồm gì — phương án A | ⚠ chủ sản phẩm và đội | | ⚠ TỒN ĐỌNG SẢN PHẨM | ⚠ mọi thứ có thể làm, có xếp thứ tự | ⚠ chủ sản phẩm | | ⚠ TỒN ĐỌNG SPRINT | ⚠ những gì làm trong vòng lặp này — ĐÁP ÁN | ⚠ ĐỘI PHÁT TRIỂN | | ⚠ Điểm dễ nhầm | ⚠ chủ sản phẩm sở hữu tồn đọng SẢN PHẨM, còn ĐỘI sở hữu tồn đọng SPRINT — kể cả khi chủ sản phẩm là người muốn theo dõi nó |

⚠ Tồn đọng sprint gồm những gì: | Thành phần | Nội dung | |---|---| | ⚠ MỤC TIÊU SPRINT | ⚠ vì sao vòng lặp này tồn tại | | ⚠ Các hạng mục tồn đọng sản phẩm được chọn | | | ⚠ Kế hoạch thực hiện chúng | ⚠ các nhiệm vụ do đội tự chia | | ⚠ Trạng thái hiện tại của từng hạng mục | ⚠ liên hệ #26924 cùng lô | | ⚠ Tính chất quan trọng | ⚠ nó là kế hoạch CỦA ĐỘI, do đội cập nhật hằng ngày — chủ sản phẩm được xem và được góp ý, nhưng không được tự thay đổi nội dung của nó giữa vòng lặp |

Từ khoá nhận diện:

"hạng mục sẽ hoàn thành trong SPRINT hiện tại" → ⚠ TỒN ĐỌNG SPRINT "mọi thứ có thể làm cho sản phẩm" → ⚠ tồn đọng sản phẩm "bản phát hành tới gồm gì" → ⚠ kế hoạch phát hành quyền sở hữu → ⚠ sản phẩm thuộc CHỦ SẢN PHẨM, sprint thuộc ĐỘI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chủ sản phẩm của bạn xem tồn đọng sprint ở đâu | | | Có ai ngoài đội thay đổi nội dung sprint giữa chừng không | | | Mục tiêu sprint hiện tại của đội bạn là gì | ⚠ hỏi ba người, nếu ba câu trả lời khác nhau thì đó là vấn đề |

Và điều mà việc phân biệt hai tồn đọng bảo vệ: quyền của đội được cam kết một lượng công việc rồi được yên ổn hoàn thành nó — nếu ai cũng sửa được tồn đọng sprint thì cam kết đó không còn nghĩa gì.

Câu 450 Process
Jeffrey has talked with all the appropriate people to identify the risks in his agile project at Joshua Jellybeans. The people he is engaged with include
  1. A The development team and managerial stakeholders, including the product owner.
  2. B The development team.
  3. C The development team and product owner.
  4. D All stakeholders, including the development team, product owner, sponsor, and a few customers.
Xem giải thích

Đáp án

D — TẤT CẢ CÁC BÊN LIÊN QUAN, GỒM ĐỘI PHÁT TRIỂN, CHỦ SẢN PHẨM, NHÀ TÀI TRỢ VÀ MỘT SỐ KHÁCH HÀNG.

Vì sao đúng

⚠ Vì sao phải mở rộng ra mọi bên liên quan: | Lý do | Nội dung | |---|---| | ⚠ Mỗi nhóm nhìn thấy loại rủi ro KHÁC NHAU | ⚠ không nhóm nào thấy được toàn bộ | | ⚠ Đội phát triển thấy rủi ro KỸ THUẬT | | | ⚠ Chủ sản phẩm thấy rủi ro về GIÁ TRỊ và ưu tiên | | | ⚠ Nhà tài trợ thấy rủi ro TỔ CHỨC và ngân sách | | | ⚠ Khách hàng thấy rủi ro về NHU CẦU THẬT và bối cảnh sử dụng | | | ⚠ Kết luận | ⚠ nhận diện rủi ro là hoạt động cần góc nhìn rộng nhất có thể |

⚠ Nguyên tắc chung của quản lý rủi ro: ⚠ rủi ro nguy hiểm nhất là rủi ro không ai nhìn thấy ⚠ — ⚠ và cách duy nhất giảm điểm mù là mời thêm những đôi mắt khác nhau vào cuộc.

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

  • A (đội phát triển và các bên liên quan quản lý, gồm cả chủ sản phẩm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó đã khá rộng — có cả đội, cả chủ sản phẩm và cả cấp quản lý, nên trông như một danh sách đầy đủ: ⚠ nhưng ⚠ nó thiếu KHÁCH HÀNG ⚠ — ⚠ và khách hàng chính là nhóm nhìn thấy loại rủi ro mà không ai bên trong tổ chức thấy được: sản phẩm có dùng được trong bối cảnh thật hay không; ⚠ liên hệ #26857 lô 202 về vực đánh giá — phần lớn rủi ro lớn nhất của một dự án phần mềm nằm đúng ở khoảng cách đó.

  • C (đội phát triển và chủ sản phẩm) — ⚠ thiếu nhà tài trợ và khách hàng; ⚠ bỏ mất góc nhìn tổ chức và góc nhìn người dùng.

  • B (chỉ đội phát triển) — ⚠ hẹp nhất; ⚠ chỉ thấy được rủi ro kỹ thuật.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26888 cùng lô (rủi ro là phản giá trị trong agile), ⚠ #26899 cùng lô (chiến lược chấp nhận rủi ro), ⚠ #26857 lô 202 (vực đánh giá), ⚠ #26837 lô 202 (điểm chạm với bên liên quan để phát hiện rủi ro), ⚠ #26903 cùng lô (kỹ thuật Delphi để thu ý kiến nhiều bên).

⚠ Mỗi nhóm nhìn thấy loại rủi ro nào: | Nhóm | Rủi ro họ nhìn thấy rõ nhất | |---|---| | ⚠ ĐỘI PHÁT TRIỂN | ⚠ kỹ thuật, phụ thuộc, nợ kỹ thuật, năng lực | | ⚠ CHỦ SẢN PHẨM | ⚠ giá trị, ưu tiên, thị trường, đối thủ | | ⚠ NHÀ TÀI TRỢ | ⚠ ngân sách, chính trị nội bộ, thay đổi chiến lược | | ⚠ KHÁCH HÀNG và NGƯỜI DÙNG | ⚠ bối cảnh sử dụng thật, quy trình nghiệp vụ, khả năng tiếp nhận | | ⚠ Bộ phận vận hành và bảo mật | ⚠ vận hành, tuân thủ — nhóm hay bị quên nhất | | ⚠ Kết luận | ⚠ một buổi nhận diện rủi ro chỉ có đội kỹ thuật sẽ cho ra một danh sách rất kỹ về rủi ro kỹ thuật và gần như trống ở mọi loại còn lại |

⚠ Kỹ thuật nhận diện rủi ro trong agile: | Kỹ thuật | Nội dung | |---|---| | ⚠ Động não trong buổi lập kế hoạch phát hành | ⚠ với sự tham gia rộng | | ⚠ Phân tích tiền tử thi | ⚠ liên hệ #26643 lô 198 | | ⚠ Delphi cho các bên có khoảng cách quyền lực | ⚠ liên hệ #26903 cùng lô | | ⚠ Rà soát rủi ro trong hồi cứu | | | ⚠ Đưa rủi ro thành hạng mục tồn đọng | ⚠ liên hệ #26888 cùng lô | | ⚠ Nhịp thực hiện | ⚠ nhận diện rủi ro trong agile là hoạt động LIÊN TỤC chứ không phải một buổi họp đầu dự án — mỗi vòng lặp đều sinh ra thông tin mới, và thông tin mới luôn kèm theo rủi ro mới |

⚠ Vì sao mời khách hàng lại quan trọng và cũng khó: | Khía cạnh | Nội dung | |---|---| | ⚠ Họ biết bối cảnh sử dụng thật | ⚠ thứ không ai bên trong tổ chức biết đủ | | ⚠ Họ phát hiện các giả định sai từ sớm | | | ⚠ Nhưng họ không quen ngôn ngữ kỹ thuật | ⚠ cần người điều phối dịch qua lại | | ⚠ Và mời quá nhiều khách sẽ làm buổi họp mất kiểm soát | ⚠ đề nói rõ "một vài khách hàng", không phải tất cả | | ⚠ Cân bằng đúng | ⚠ mời một vài người đại diện cho các nhóm người dùng khác nhau — đủ để có góc nhìn thật mà không biến buổi làm việc thành một hội nghị |

Từ khoá nhận diện:

"nhận diện rủi ro trong agile" → ⚠ MỌI bên liên quan, gồm cả KHÁCH HÀNG "chỉ đội phát triển" → ⚠ chỉ thấy rủi ro kỹ thuật "đội và chủ sản phẩm" → ⚠ thiếu góc nhìn tổ chức và người dùng nguyên tắc → ⚠ rủi ro nguy hiểm nhất là rủi ro không ai nhìn thấy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi nhận diện rủi ro gần nhất của bạn có những ai | | | Danh sách rủi ro của bạn có bao nhiêu phần trăm là rủi ro kỹ thuật | ⚠ quá cao nghĩa là góc nhìn còn hẹp | | Khách hàng đã bao giờ được hỏi về rủi ro chưa | |

Và điều mà một buổi nhận diện rủi ro có đủ mặt các bên thường cho thấy: rủi ro mà mỗi nhóm coi là hiển nhiên lại chính là rủi ro mà các nhóm khác chưa từng nghĩ tới — và những rủi ro đó chỉ xuất hiện khi tất cả cùng ngồi trong một phòng.