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

Tìm thấy 720 câu.

Câu 251 People
Stakeholder identification is essential to effective project managers. All the following are key stakeholders on every project except for which one?
  1. A The project management team
  2. B Government agencies
  3. C The project manager
  4. D Influencers
Xem giải thích

Đáp án

B — CƠ QUAN NHÀ NƯỚC (đây KHÔNG phải bên liên quan chính của MỌI dự án).

Vì sao đúng

⚠ Ai là bên liên quan CHÍNH của MỌI dự án: | Bên liên quan | Vì sao luôn có | |---|---| | ⚠ QUẢN LÝ DỰ ÁN | ⚠ không có PM thì không có dự án được quản lý | | ⚠ ĐỘI QUẢN LÝ DỰ ÁN | ⚠ nhóm trực tiếp làm công việc quản lý | | ⚠ NGƯỜI CÓ ẢNH HƯỞNG (influencers) | ⚠ luôn có người tác động được tới dự án dù không trực tiếp tham gia | | ⚠ CƠ QUAN NHÀ NƯỚC | ⚠ CHỈ CÓ khi dự án chịu quản lý của họ — ĐÁP ÁN | | ⚠ Tiêu chí phân biệt | ⚠ "mọi dự án" là từ khoá — chỉ cần MỘT dự án không có là phương án đó bị loại |

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

  • D (người có ảnh hưởng) — ⚠ phương án gây nhiễu mạnh nhất vì nghe mơ hồ nhất: ⚠ nhưng ⚠ mọi dự án đều có người tác động được tới nó ⚠ — người đề xuất, người phản đối, người kiểm soát nguồn lực; ⚠ đây là một nhóm bên liên quan chuẩn trong tài liệu PMI.

  • A (đội quản lý dự án) và C (quản lý dự án) — ⚠ hiển nhiên luôn có trong mọi dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25961 ở lô này (Ethel chưa gắn kết bên liên quan), câu #25949 (Jessie quyền thấp quan tâm thấp), câu #25895 ở lô 183 (phân tích bên liên quan), và câu #25982 cũng ở lô này (hai bên liên quan bất đồng về ưu tiên). ⚠ Bên liên quan là chủ đề xuyên suốt cả hai lô.

⚠ Các nhóm bên liên quan điển hình: | Nhóm | Ghi chú | |---|---| | ⚠ Nhà tài trợ | ⚠ hầu như luôn có | | ⚠ Quản lý dự án và đội | ⚠ luôn có | | ⚠ Khách hàng và người dùng | ⚠ hầu như luôn có | | ⚠ Người có ảnh hưởng | ⚠ luôn có | | ⚠ PMO | ⚠ chỉ khi tổ chức có PMO | | ⚠ Nhà cung cấp và đối tác | ⚠ chỉ khi có mua sắm — liên hệ #25964 | | ⚠ Cơ quan quản lý nhà nước | ⚠ chỉ khi dự án thuộc lĩnh vực bị quản lý — CÂU NÀY | | ⚠ Cộng đồng dân cư, tổ chức xã hội | ⚠ tuỳ dự án | | ⚠ Bài học chung | ⚠ danh sách bên liên quan là RIÊNG của từng dự án, không có mẫu dùng chung cho tất cả |

Từ khoá nhận diện:

"MỌI dự án đều có" → ⚠ PM, đội quản lý, người có ảnh hưởng "tuỳ ngành, tuỳ dự án" → ⚠ cơ quan nhà nước, nhà cung cấp, cộng đồng ⚠ Câu có chữ "EXCEPT" → ⚠ tìm cái KHÔNG PHẢI LÚC NÀO CŨNG ĐÚNG "người có ảnh hưởng" → ⚠ là nhóm chuẩn, đừng loại chỉ vì nghe mơ hồ

⚠ Khi nào cơ quan nhà nước LÀ bên liên quan chính Trường hợp
⚠ Dự án xây dựng cần giấy phép
⚠ Dược phẩm, thiết bị y tế cần phê duyệt
⚠ Tài chính, ngân hàng chịu quản lý chặt
⚠ Môi trường, năng lượng
⚠ Dự án dùng ngân sách công
⚠ Khi đó ⚠ họ có QUYỀN LỰC rất cao dù mức QUAN TÂM có thể thấp — ô "giữ hài lòng" trên ma trận
⚠ Rủi ro nếu bỏ sót ⚠ rủi ro tuân thủ — liên hệ #25962 cùng lô
⚠ Nhận diện bên liên quan sót thì hậu quả gì Hậu quả
⚠ Yêu cầu quan trọng bị bỏ sót
⚠ Phản đối xuất hiện muộn, lúc đã tốn nhiều tiền
⚠ Vi phạm quy định mà không biết
⚠ Cách phòng ⚠ rà lại danh sách bên liên quan Ở MỖI GIAI ĐOẠN, không chỉ ở đầu dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký bên liên quan của bạn cập nhật lần cuối khi nào | | | Dự án của bạn có chịu quy định nào không | ⚠ nếu có thì cơ quan quản lý phải nằm trong danh sách | | Ai là người có ảnh hưởng mà không nằm trong sơ đồ tổ chức | ⚠ thường là người quan trọng nhất và bị bỏ sót nhiều nhất |

Và cách đọc nhanh mọi câu hỏi kiểu này: chỉ cần nghĩ ra MỘT dự án không có bên đó là đủ để loại nó ra.

Câu 252 Business Environment
Peter is starting a large and long-term technology project that will last seven years. The project includes an operating system that is near the end of its life cycle. It also includes a requirement to process cards. The debit and credit card system includes cards with only a magnetic stripe, while some have a security chip. Eventually, the magnetic stripe-only cards will be phased out, but both must be supported for the time being. The operating system in question will be supported for another two to three years, with an unknown new operating system arriving next year. Those are the challenges that Peter is aware of, but there will be other technological changes, updates, and challenges during the next seven years. What mindset should Peter have in managing this project?
  1. A An agile mindset because he should focus on the present with an eye to change.
  2. B An eye on the future because he knows change is coming.
  3. C A fixed mindset because Peter can only work with the technology he has.
  4. D A waterfall mindset. One thing after another, in its order. He should plan for the next seven years.
Xem giải thích

Đáp án

A — TƯ DUY AGILE: tập trung vào HIỆN TẠI với con mắt hướng tới sự THAY ĐỔI.

Vì sao đúng

⚠ Vì sao dự án của Peter cần tư duy agile: | Đặc điểm dự án | Ý nghĩa | |---|---| | ⚠ Kéo dài BẢY NĂM | ⚠ không ai dự đoán nổi công nghệ bảy năm sau | | ⚠ Hệ điều hành sắp hết vòng đời, còn hỗ trợ 2–3 năm | ⚠ chắc chắn phải đổi giữa chừng | | ⚠ Hệ điều hành mới sẽ ra vào NĂM SAU nhưng CHƯA BIẾT là gì | ⚠ bất định đã được nêu đích danh | | ⚠ Phải hỗ trợ CẢ thẻ từ LẪN thẻ chip trong giai đoạn chuyển tiếp | ⚠ yêu cầu sẽ thay đổi khi thẻ từ bị loại bỏ | | ⚠ Còn nhiều thay đổi khác chưa biết | ⚠ Peter đã tự nhận điều này | | ⚠ Kết luận | ⚠ lập kế hoạch chi tiết bảy năm là vô nghĩa; phải làm rõ dần và thích nghi liên tục |

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

  • B (hướng mắt về tương lai vì biết thay đổi sẽ tới) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất khôn ngoan: ⚠ nhưng ⚠ chỉ nhìn tương lai mà không giao được gì ở hiện tại là bẫy phân tích quá mức; ⚠ tư duy agile là ⚠ làm được việc NGAY BÂY GIỜ trong khi vẫn sẵn sàng đổi ⚠ — hai vế, không phải một.

  • D (tư duy thác nước, lập kế hoạch cho cả bảy năm) — ⚠ hoàn toàn sai với mức bất định này.

  • C (tư duy cố định, chỉ làm với công nghệ đang có) — ⚠ phủ nhận thực tế mà chính đề đã mô tả.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25972 ở lô này (nguyên mẫu kiểm chứng ý tưởng → cách tiếp cận thích ứng), câu #25908 ở lô 183 (agile lập kế hoạch nhiều tầng), và câu #25919 (quyết định kiến trúc có ảnh hưởng lâu dài). ⚠ Cả nhóm về việc chọn cách tiếp cận theo mức bất định.

⚠ Chọn cách tiếp cận theo mức BẤT ĐỊNH: | Mức bất định về YÊU CẦU | Mức bất định về CÔNG NGHỆ | Cách tiếp cận | |---|---|---| | ⚠ Thấp | ⚠ Thấp | ⚠ DỰ ĐOÁN | | ⚠ Cao | ⚠ Thấp | ⚠ LẶP — làm rõ yêu cầu dần | | ⚠ Thấp | ⚠ Cao | ⚠ TĂNG DẦN — giao từng phần để thử công nghệ | | ⚠ Cao | ⚠ Cao | ⚠ AGILE hoàn toàn — dự án của Peter | | ⚠ Mô hình này | ⚠ thường gọi là mô hình Stacey, dùng để chọn cách tiếp cận |

Từ khoá nhận diện:

"dài nhiều năm, công nghệ đang thay đổi" → ⚠ tư duy agile "chỉ nhìn tương lai" → ⚠ thiếu vế hành động ở hiện tại "lập kế hoạch chi tiết cho bảy năm" → ⚠ luôn sai với mức bất định cao "chỉ làm với cái đang có" → ⚠ tư duy cố định, phủ nhận thực tế

⚠ Peter nên làm gì cụ thể Việc
⚠ Lập kế hoạch CHI TIẾT cho 3–6 tháng tới, THÔ cho phần còn lại ⚠ lập kế hoạch nhiều tầng
⚠ Thiết kế kiến trúc TRỪU TƯỢNG HOÁ phần phụ thuộc hệ điều hành ⚠ để đổi hệ điều hành mà không viết lại tất cả
⚠ Tách phần xử lý thẻ từ và thẻ chip thành hai mô-đun ⚠ để gỡ bỏ thẻ từ về sau không ảnh hưởng phần còn lại
⚠ Giao giá trị từng phần, không đợi tới năm thứ bảy
⚠ Rà soát lại cách tiếp cận định kỳ
⚠ Ghi các bất định đã biết vào SỔ RỦI RO ngay ⚠ Peter đã nhận diện được ba cái — đó là tài sản
⚠ Nguyên tắc kiến trúc ⚠ hoãn các quyết định khó đảo ngược tới thời điểm muộn nhất có trách nhiệm — liên hệ #25919
⚠ "Tập trung hiện tại với con mắt hướng tới thay đổi" nghĩa là gì Nghĩa
⚠ GIAO được thứ có giá trị NGAY BÂY GIỜ ⚠ không đợi mọi thứ chắc chắn mới bắt đầu
⚠ Nhưng THIẾT KẾ sao cho đổi được ⚠ không khoá cứng vào một công nghệ
⚠ Và RÀ SOÁT liên tục khi thông tin mới xuất hiện
⚠ Sai lầm hai đầu ⚠ một là lập kế hoạch cứng cho bảy năm, hai là không quyết gì cả vì "mọi thứ sẽ thay đổi"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có phần nào khoá cứng vào một công nghệ cụ thể không | | | Kế hoạch của bạn chi tiết tới bao xa | ⚠ chi tiết quá xa là lãng phí, chi tiết quá gần là hỗn loạn | | Bạn rà soát lại giả định công nghệ bao lâu một lần | |

Và điều Peter đã làm đúng ngay từ đầu, trước cả khi chọn phương pháp: anh liệt kê ra được những thứ mình chưa biết. Đó là điểm khởi đầu của mọi cách tiếp cận thích ứng.

Câu 253 Process
Jason is managing an eight-month project and has held biweekly meetings with the project stakeholders. The project is 90 percent complete, is on schedule and under budget so far. With just one month remaining before the project completion, Jason asks the team to add two additional features that one of the stakeholders requested. The additions will utilize the remaining project budget to further boost customer satisfaction without risking schedule delays. Unfortunately, Jason must take an extended leave of absence due to a health emergency. In Jason's absence, Jenna has been asked to work as the project manager for the project, which will likely be complete before Jason returns. After learning about the recent feature additions, what is the best thing for Jenna to do?
  1. A Ask the team to add the changes to the change log afterward.
  2. B Acknowledge it as a value-added change.
  3. C Consider it as gold plating.
  4. D Since this reflects poor planning, add a note to the lessons-learned register.
Xem giải thích

Đáp án

C — Coi đó là MẠ VÀNG (gold plating).

Vì sao đúng

⚠ Vì sao đây là mạ vàng: | Dấu hiệu | Nội dung | |---|---| | ⚠ Thêm hai TÍNH NĂNG không nằm trong phạm vi đã duyệt | | | ⚠ Không qua quy trình KIỂM SOÁT THAY ĐỔI | ⚠ Jason tự quyết | | ⚠ Lý do là "tiêu nốt ngân sách còn dư" và "tăng sự hài lòng" | ⚠ động cơ điển hình của mạ vàng | | ⚠ Dự án đang ĐÚNG TIẾN ĐỘ và DƯỚI NGÂN SÁCH | ⚠ đang thành công — không cần thêm gì cả | | ⚠ Định nghĩa | ⚠ mạ vàng là thêm tính năng hoặc chất lượng VƯỢT yêu cầu mà khách hàng không đòi và không duyệt |

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

  • B (ghi nhận đó là thay đổi gia tăng giá trị) — ⚠ phương án gây nhiễu mạnh nhất vì Jason đúng là có ý tốt: ⚠ nhưng ⚠ thay đổi gia tăng giá trị vẫn PHẢI qua kiểm soát thay đổi; ⚠ ý định tốt không biến việc bỏ qua quy trình thành hợp lệ, ⚠ và bên liên quan yêu cầu KHÔNG đồng nghĩa với việc yêu cầu đó đã được duyệt.

  • A (nhờ đội bổ sung thay đổi vào nhật ký thay đổi SAU khi làm) — ⚠ hợp thức hoá ngược; ⚠ nhật ký thay đổi ghi các yêu cầu ĐÃ QUA quy trình, không phải nơi che đậy việc đã rồi.

  • D (ghi vào sổ bài học kinh nghiệm vì đây là lập kế hoạch kém) — ⚠ KHÔNG phải lập kế hoạch kém: ⚠ dự án đúng tiến độ và dưới ngân sách là dấu hiệu lập kế hoạch TỐT; ⚠ vấn đề nằm ở quyết định của Jason ở cuối dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25956 ở lô này (nhật ký thay đổi), câu #25933 (sửa lỗi), câu #25959 (bàn giao trong tuyên bố phạm vi), và câu #25981 cũng ở lô này (kế hoạch quản lý yêu cầu). ⚠ Nhóm quản lý phạm vi và thay đổi.

⚠ Phân biệt BA khái niệm về phạm vi phình ra: | Khái niệm | Nguồn gốc | Có qua quy trình không | |---|---|---| | ⚠ MẠ VÀNG (gold plating) | ⚠ ĐỘI hoặc PM tự thêm | ⚠ KHÔNG — CÂU NÀY | | ⚠ TRƯỢT PHẠM VI (scope creep) | ⚠ KHÁCH HÀNG hoặc bên liên quan xin thêm dần | ⚠ KHÔNG | | ⚠ THAY ĐỔI HỢP LỆ | ⚠ bất kỳ ai đề xuất | ⚠ CÓ — qua kiểm soát thay đổi tích hợp | | ⚠ Mẹo phân biệt | ⚠ mạ vàng đến từ BÊN TRONG, trượt phạm vi đến từ BÊN NGOÀI, thay đổi hợp lệ có CHỮ KÝ | | ⚠ Ở tình huống này | ⚠ bên liên quan có xin, nhưng CHÍNH JASON quyết định làm mà không qua quy trình — nên là MẠ VÀNG |

Từ khoá nhận diện:

"thêm tính năng bằng ngân sách dư" → ⚠ mạ vàng "khách hàng xin thêm dần dần" → ⚠ trượt phạm vi "đã qua CCB, có phê duyệt" → ⚠ thay đổi hợp lệ "ghi vào nhật ký SAU khi làm" → ⚠ hợp thức hoá ngược, luôn sai

⚠ Vì sao mạ vàng có hại dù có ý tốt Tác hại
⚠ Thêm tính năng là thêm RỦI RO và thêm LỖI ⚠ ở tháng cuối cùng, khi ít thời gian sửa nhất
⚠ Tiêu hết dự phòng vốn để phòng bất trắc ⚠ ngân sách dư không phải tiền thừa
⚠ Tạo kỳ vọng sai cho các dự án sau
⚠ Khách hàng có thể KHÔNG MUỐN tính năng đó ⚠ họ còn phải bảo trì nó suốt vòng đời
⚠ Vi phạm nguyên tắc quản trị phạm vi
⚠ Nghịch lý ⚠ ngân sách dư là THÀNH TÍCH — tiêu nốt nó để làm việc ngoài phạm vi là biến thành tích thành rủi ro
⚠ Jenna nên làm gì cụ thể Bước
⚠ 1. Nhận diện đúng bản chất: đây là mạ vàng ⚠ bước câu hỏi đang hỏi
⚠ 2. Đánh giá tình trạng hiện tại: đã làm tới đâu
⚠ 3. Nếu chưa làm: DỪNG và đưa qua kiểm soát thay đổi
⚠ 4. Nếu đã làm: báo nhà tài trợ và ghi nhận chính thức ⚠ không giấu
⚠ 5. Ghi vào bài học kinh nghiệm ⚠ nhưng bài học là về KIỂM SOÁT THAY ĐỔI, không phải về lập kế hoạch kém
⚠ Điều khó ⚠ Jenna phải xử lý một quyết định của người tiền nhiệm đang nghỉ bệnh — cần khéo léo, nhưng không được im lặng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có bao giờ thêm "cho đẹp" mà không ai yêu cầu không | | | Ngân sách dư ở tổ chức bạn được xử lý thế nào | ⚠ nếu bị coi là "phải tiêu hết" thì mạ vàng sẽ luôn xảy ra | | Có thay đổi nào đang được làm mà chưa có phê duyệt không | |

Và câu hỏi Jason đáng lẽ phải tự hỏi: "khách hàng có bảo tôi làm cái này không?" Nếu câu trả lời là không, thì mọi lý do khác đều không quan trọng.

Câu 254 Process

Rob's project will begin very soon. He reviews some of the documents in preparation, including a first draft of the project charter assembled from several brainstorming sessions. As he reviews the documents, he takes notes and paraphrases key concepts to be able to answer any last-minute questions from the project sponsor or stakeholders. Rob also creates a draft schedule including touchpoints for future project phases and a proposed process for incorporating feedback received to date. More importantly, these touchpoints will give Rob and his team a chance to evaluate the project against the project charter and the original scope documents so that they can make any required changes. Which process group is being integrated into the adaptive planning environment?

  1. A Planning process group
  2. B Initiating process group
  3. C Monitoring and controlling process group
  4. D Executing process group
Xem giải thích

Đáp án

B — Nhóm quy trình KHỞI TẠO (initiating process group).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Rob rà soát BẢN THẢO ĐIỀU LỆ DỰ ÁN | ⚠ điều lệ là đầu ra của nhóm KHỞI TẠO | | ⚠ Các điểm chạm để đối chiếu dự án với ĐIỀU LỆ và phạm vi GỐC | ⚠ quay lại tài liệu khởi tạo ở các giai đoạn sau | | ⚠ Chuẩn bị trả lời câu hỏi của nhà tài trợ và bên liên quan | ⚠ hoạt động đặc trưng đầu dự án | | ⚠ Dự án SẮP bắt đầu | | | ⚠ Câu hỏi thật sự hỏi gì | ⚠ nhóm quy trình nào đang được TÍCH HỢP VÀO môi trường lập kế hoạch thích ứng — tức là được LẶP LẠI ở các vòng sau | | ⚠ Trả lời | ⚠ KHỞI TẠO — trong môi trường thích ứng, việc đối chiếu lại với điều lệ diễn ra NHIỀU LẦN, không chỉ một lần ở đầu |

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

  • A (nhóm lập kế hoạch) — ⚠ phương án gây nhiễu mạnh nhất vì Rob đang lập lịch nháp: ⚠ nhưng ⚠ trọng tâm của đoạn văn là ĐIỀU LỆ và PHẠM VI GỐC, ⚠ và điểm mấu chốt là ⚠ các điểm chạm để ĐÁNH GIÁ LẠI dự án so với điều lệ ⚠ — đó là việc kéo nhóm KHỞI TẠO vào các vòng sau.

  • C (nhóm giám sát và kiểm soát) — ⚠ các điểm chạm nghe giống giám sát; ⚠ nhưng thứ được đối chiếu là ⚠ tài liệu KHỞI TẠO, ⚠ không phải đường cơ sở hiệu suất.

  • D (nhóm thực hiện) — ⚠ chưa có công việc nào được thực hiện; ⚠ dự án còn chưa bắt đầu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25971 ở lô này (thời điểm họp khởi động), câu #25932 ở lô 183 (tên gọi buổi họp đầu dự án), và câu #25974 ở lô này (tư duy agile cho dự án bất định dài hạn). ⚠ Cả nhóm về giai đoạn đầu dự án.

⚠ NĂM nhóm quy trình và đầu ra chính: | Nhóm | Đầu ra tiêu biểu | |---|---| | ⚠ KHỞI TẠO | ⚠ điều lệ dự án, sổ đăng ký bên liên quan — CÂU NÀY | | ⚠ LẬP KẾ HOẠCH | ⚠ kế hoạch quản lý dự án và các đường cơ sở | | ⚠ THỰC HIỆN | ⚠ bàn giao, dữ liệu hiệu suất công việc | | ⚠ GIÁM SÁT VÀ KIỂM SOÁT | ⚠ yêu cầu thay đổi, báo cáo hiệu suất | | ⚠ KẾT THÚC | ⚠ bàn giao cuối, bài học kinh nghiệm | | ⚠ Lưu ý quan trọng | ⚠ nhóm quy trình KHÔNG phải giai đoạn — chúng LẶP LẠI ở mỗi giai đoạn và mỗi vòng lặp |

Từ khoá nhận diện:

"điều lệ dự án, phạm vi gốc, bên liên quan ban đầu" → ⚠ khởi tạo "đường cơ sở, kế hoạch quản lý" → ⚠ lập kế hoạch "so với đường cơ sở, yêu cầu thay đổi" → ⚠ giám sát và kiểm soát "quay lại đối chiếu với điều lệ ở các vòng sau" → ⚠ khởi tạo được tích hợp vào môi trường thích ứng

⚠ Vì sao môi trường thích ứng lại LẶP LẠI khởi tạo Lý do
⚠ Điều lệ và mục tiêu kinh doanh có thể ĐỔI theo thời gian ⚠ liên hệ #25905 lô 183 — bên liên quan phát hiện bàn giao không còn cần thiết
⚠ Bên liên quan mới xuất hiện, bên cũ rời đi
⚠ Mỗi bản phát hành có thể được coi như một dự án nhỏ
⚠ Cần kiểm lại business case còn đứng vững không ⚠ liên hệ #25909 — khi nào dự án hết cần thiết
⚠ Đối lập với dự đoán ⚠ dự án dự đoán khởi tạo MỘT LẦN rồi thôi; dự án thích ứng quay lại câu hỏi "vì sao chúng ta làm việc này" nhiều lần
⚠ Rob đang làm những việc tốt gì Việc
⚠ Diễn giải lại khái niệm bằng lời của mình ⚠ cách kiểm tra mình đã thật sự hiểu
⚠ Chuẩn bị trước cho câu hỏi bất chợt
⚠ Thiết kế sẵn cơ chế tiếp nhận phản hồi
⚠ Đặt điểm chạm để đối chiếu định kỳ ⚠ điểm hay nhất — nhiều dự án không bao giờ mở lại điều lệ sau ngày đầu tiên
⚠ Bài học ⚠ điều lệ không phải tờ giấy để ký rồi cất đi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần cuối bạn đọc lại điều lệ dự án của mình là khi nào | | | Mục tiêu ghi trong điều lệ còn đúng không | | | Có điểm chạm nào để đối chiếu định kỳ không | |

Và điều làm nên khác biệt của môi trường thích ứng: câu hỏi "chúng ta đang làm đúng thứ cần làm chứ?" được đặt ra nhiều lần, chứ không chỉ một lần vào ngày đầu tiên khi chưa ai biết gì.

Câu 255 Process
Ernie is the project manager for a user experience team and user interface employees responsible for creating website templates. After Ernie and his business analysts gather requirements, these employees create mock-ups for the project's stakeholders. The stakeholders review each mock-up, approve or reject them as they do, and give feedback for the next iteration. One mock-up is rejected because the color scheme is not accessible by colorblind people. This is an example of which part of the project scope statement?
  1. A Acceptance criteria
  2. B Project exclusions
  3. C Deliverables
  4. D Product scope description
Xem giải thích

Đáp án

A — TIÊU CHÍ CHẤP NHẬN (acceptance criteria).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Bên liên quan XEM XÉT từng bản mẫu | ⚠ quá trình đánh giá theo tiêu chí | | ⚠ CHẤP NHẬN hoặc TỪ CHỐI | ⚠ từ khoá quyết định — có chấp nhận được hay không | | ⚠ Bị từ chối vì bảng màu KHÔNG THÂN THIỆN với người mù màu | ⚠ một ĐIỀU KIỆN cụ thể mà bản mẫu phải thoả | | ⚠ Định nghĩa | ⚠ tiêu chí chấp nhận là tập hợp điều kiện phải được đáp ứng TRƯỚC KHI bàn giao được nghiệm thu | | ⚠ Ở đây | ⚠ khả năng tiếp cận cho người khiếm khuyết thị giác chính là một tiêu chí chấp nhận |

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

  • C (bàn giao) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ⚠ bản mẫu ĐÚNG LÀ một bàn giao, ⚠ nhưng câu hỏi hỏi ⚠ VIỆC TỪ CHỐI VÌ MỘT ĐIỀU KIỆN ⚠ minh hoạ cho mục nào — ⚠ và đó là tiêu chí chấp nhận, không phải bản thân bàn giao.

  • D (mô tả phạm vi sản phẩm) — ⚠ mô tả ĐẶC ĐIỂM của sản phẩm; ⚠ ở đây đang nói về ĐIỀU KIỆN NGHIỆM THU.

  • B (loại trừ khỏi phạm vi) — ⚠ những thứ dự án KHÔNG làm; ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Đối chiếu — cặp câu trong CÙNG MỘT LÔ: ⚠ câu #25959 ⚠ (100 máy in, mực, phụ tùng, bảo trì một năm → BÀN GIAO) ⚠ và câu này ⚠ (điều kiện để bản mẫu được chấp nhận → TIÊU CHÍ CHẤP NHẬN). ⚠ Hai câu hỏi về HAI MỤC KHÁC NHAU của cùng một tài liệu — tuyên bố phạm vi dự án. Hai khoá đáp án nhất quán, bổ sung nhau. ⚠ Xem thêm câu #25929 ở lô 183 (tiêu chí chấp nhận thuộc product owner) và câu #25957 (DoD và PO chấp nhận).

⚠ Bốn mục của TUYÊN BỐ PHẠM VI DỰ ÁN — bảng đối chiếu đầy đủ: | Mục | Trả lời câu hỏi | Ví dụ trong hai câu này | |---|---|---| | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | ⚠ sản phẩm TRÔNG NHƯ THẾ NÀO | ⚠ "máy in laser đen trắng 30 trang/phút" | | ⚠ BÀN GIAO | ⚠ phải TẠO RA những gì | ⚠ #25959 — 100 máy in, mực, phụ tùng, bảo trì | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ thế nào thì được NGHIỆM THU | ⚠ #25977 — bảng màu phải thân thiện với người mù màu | | ⚠ LOẠI TRỪ KHỎI PHẠM VI | ⚠ rõ ràng KHÔNG làm gì | ⚠ "không bao gồm đào tạo người dùng" | | ⚠ Mẹo phân biệt hai mục hay lẫn | ⚠ BÀN GIAO là DANH TỪ (cái gì), TIÊU CHÍ CHẤP NHẬN là ĐIỀU KIỆN (thế nào thì đạt) |

Từ khoá nhận diện:

"chấp nhận / từ chối vì một điều kiện" → ⚠ tiêu chí chấp nhận "danh sách những thứ phải giao" → ⚠ bàn giao "đặc điểm kỹ thuật của sản phẩm" → ⚠ mô tả phạm vi sản phẩm "không thuộc dự án này" → ⚠ loại trừ

⚠ Vì sao tiêu chí chấp nhận phải viết RA TỪ ĐẦU Lý do
⚠ Đội biết đích để nhắm tới
⚠ Tránh tranh cãi lúc nghiệm thu ⚠ "tôi tưởng thế này mới đạt"
⚠ Cho phép kiểm chứng khách quan
⚠ Giảm số vòng làm lại ⚠ đúng vấn đề đội của Ernie đang gặp
⚠ Ở tình huống này ⚠ nếu "phải đạt chuẩn tiếp cận WCAG" được viết ra từ đầu thì bản mẫu đã không bị từ chối
⚠ Khả năng tiếp cận là tiêu chí chấp nhận như thế nào Nội dung
⚠ Độ tương phản màu tối thiểu ⚠ kiểm chứng được bằng công cụ đo
⚠ Không dùng MÀU SẮC làm dấu hiệu DUY NHẤT ⚠ đúng lỗi trong tình huống này
⚠ Có văn bản thay thế cho hình ảnh
⚠ Điều hướng được bằng bàn phím
⚠ Lưu ý ⚠ ở nhiều nơi đây là YÊU CẦU PHÁP LÝ, không phải lựa chọn — khi đó nó vừa là tiêu chí chấp nhận vừa là vấn đề tuân thủ (liên hệ #25962)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bàn giao của bạn có tiêu chí chấp nhận viết ra không | | | Tiêu chí đó có KIỂM CHỨNG ĐƯỢC không | ⚠ "đẹp" và "dễ dùng" là tiêu chí vô dụng | | Bên liên quan có xác nhận tiêu chí TRƯỚC khi đội bắt đầu không | |

Và nguyên nhân sâu xa của việc bản mẫu bị từ chối: không ai nói với đội thiết kế rằng khả năng tiếp cận là điều kiện bắt buộc. Đó là lỗi của tiêu chí chấp nhận, không phải lỗi của người thiết kế.

Câu 256 Process
Jeremy is the project manager for Project Alps, which is in its third week of implementation, is $5,000.00 over a $100,000.00 budget, and is on schedule. A stakeholder has asked Jeremy to move a significant project milestone two weeks back in the project. What should Jeremy do next?
  1. A Agree and move the milestone.
  2. B Hire a consultant to advise the stakeholder.
  3. C Gather data about the milestone and the impact of moving it.
  4. D Reject the request since it is not in the project plan.
Xem giải thích

Đáp án

C — THU THẬP DỮ LIỆU về mốc đó và TÁC ĐỘNG của việc dời nó.

Vì sao đúng

⚠ Vì sao phải thu thập dữ liệu trước: | Lý do | Nội dung | |---|---| | ⚠ Chưa biết TÁC ĐỘNG thì không thể quyết | ⚠ mốc quan trọng thường kéo theo nhiều phụ thuộc | | ⚠ Dời mốc có thể ảnh hưởng ĐƯỜNG GĂNG | ⚠ liên hệ #25938 cùng lô | | ⚠ Dự án ĐANG vượt chi 5.000 trên 100.000 | ⚠ 5% vượt chi — mọi thay đổi đều phải cân nhắc kỹ hơn | | ⚠ Phân tích tác động là ĐẦU VÀO của kiểm soát thay đổi | | | ⚠ Trình tự chuẩn | ⚠ hiểu yêu cầu → phân tích tác động → lập yêu cầu thay đổi → CCB quyết → thực hiện hoặc thông báo từ chối |

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

  • D (từ chối vì việc đó không nằm trong kế hoạch dự án) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như đang bảo vệ đường cơ sở: ⚠ nhưng ⚠ từ chối NGAY mà chưa phân tích cũng sai như đồng ý ngay; ⚠ mọi yêu cầu đều đáng được xem xét qua quy trình, ⚠ và "không nằm trong kế hoạch" chính là định nghĩa của một yêu cầu thay đổi, không phải lý do bác bỏ.

  • A (đồng ý và dời mốc) — ⚠ bỏ qua kiểm soát thay đổi, ⚠ và tự quyết vượt thẩm quyền.

  • B (thuê tư vấn để khuyên bên liên quan) — ⚠ phản ứng thái quá và tốn kém; ⚠ đây là công việc thường ngày của quản lý dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25975 ở lô này (mạ vàng — thay đổi không qua quy trình), câu #25956 (nhật ký thay đổi), câu #25965 (cập nhật kế hoạch giao tiếp), và câu #25982 cũng ở lô này (hai bên liên quan bất đồng về ưu tiên). ⚠ Nhóm kiểm soát thay đổi và xử lý yêu cầu của bên liên quan.

⚠ Quy trình xử lý một yêu cầu thay đổi: | Bước | Nội dung | |---|---| | ⚠ 1. LẮNG NGHE và hiểu vì sao họ muốn thay đổi | ⚠ lý do thật thường khác lý do nói ra | | ⚠ 2. THU THẬP DỮ LIỆU và phân tích tác động | ⚠ CÂU NÀY — tác động tới phạm vi, lịch, chi phí, chất lượng, rủi ro, nguồn lực | | ⚠ 3. Lập YÊU CẦU THAY ĐỔI chính thức | | | ⚠ 4. Đưa qua CCB hoặc nhà tài trợ | | | ⚠ 5. Cập nhật NHẬT KÝ THAY ĐỔI dù duyệt hay không | ⚠ liên hệ #25956 | | ⚠ 6. THÔNG BÁO kết quả cho người đề xuất | ⚠ bước hay bị quên nhất | | ⚠ 7. Nếu duyệt: cập nhật đường cơ sở và kế hoạch | | | ⚠ Nguyên tắc | ⚠ PM KHÔNG tự duyệt và cũng KHÔNG tự từ chối — PM PHÂN TÍCH rồi đưa lên đúng cấp |

Từ khoá nhận diện:

"bên liên quan xin thay đổi" → ⚠ phân tích tác động trước "đồng ý ngay" → ⚠ bỏ qua quy trình "từ chối ngay" → ⚠ cũng bỏ qua quy trình "thuê tư vấn" → ⚠ phản ứng thái quá, gần như luôn sai trong đề PMP

⚠ Dời một mốc quan trọng ảnh hưởng những gì Ảnh hưởng
⚠ Các hoạt động PHỤ THUỘC phía sau
⚠ Đường găng có thể thay đổi ⚠ hoặc xuất hiện đường găng mới
⚠ Nguồn lực đã được đặt trước cho khoảng thời gian đó ⚠ liên hệ #25935 — ràng buộc nguồn lực
⚠ Cam kết với nhà cung cấp và khách hàng
⚠ Chi phí — dự án đã vượt 5% rồi
⚠ Các mốc thanh toán nếu hợp đồng gắn với mốc
⚠ Câu hỏi phải trả lời được ⚠ dời hai tuần ở đây làm dự án trễ bao lâu và tốn thêm bao nhiêu
⚠ Vì sao phải hỏi VÌ SAO họ muốn dời Lý do
⚠ Có thể có một ràng buộc bên ngoài mà bạn chưa biết
⚠ Có thể có giải pháp khác đáp ứng nhu cầu thật của họ ⚠ mà không cần dời mốc
⚠ Có thể đây là dấu hiệu của rủi ro chưa được nhận diện
⚠ Kỹ năng cần ⚠ phân biệt VỊ THẾ (dời mốc) với LỢI ÍCH (điều họ thật sự cần) — nền tảng của thương lượng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có công cụ để mô phỏng tác động của việc dời một mốc không | | | Yêu cầu thay đổi gần nhất mất bao lâu để được quyết | | | Người đề xuất có được thông báo kết quả không | |

Và điều phân biệt một quản lý dự án chuyên nghiệp: không nói "được" và cũng không nói "không được" — nói "để tôi xem việc đó ảnh hưởng gì rồi trả lời anh bằng số liệu".

Câu 257 People
Joyce is using a model that will help her gauge the effectiveness of different methods of communication on her project at Sandor Software. She has learned that the most effective methods are
  1. A Low in information density and interactivity
  2. B High in information density and interactivity
  3. C High in information density and illustration
  4. D Low in time and high in inclusion
Xem giải thích

Đáp án

B — MẬT ĐỘ THÔNG TIN CAO và TÍNH TƯƠNG TÁC CAO.

Vì sao đúng

⚠ Hai trục quyết định hiệu quả của một kênh giao tiếp: | Trục | Nghĩa | |---|---| | ⚠ MẬT ĐỘ THÔNG TIN | ⚠ truyền được bao nhiêu ý nghĩa trong một đơn vị thời gian — lời nói, giọng điệu, nét mặt, cử chỉ | | ⚠ TÍNH TƯƠNG TÁC | ⚠ hai bên trao đổi qua lại được ngay hay không | | ⚠ Cao ở CẢ HAI trục | ⚠ hiệu quả nhất — chính là gặp mặt trực tiếp | | ⚠ Ví dụ cao nhất | ⚠ hai người đứng trước bảng vẽ, vừa nói vừa vẽ vừa hỏi lại | | ⚠ Ví dụ thấp nhất | ⚠ một tài liệu gửi đi và không ai trả lời |

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

  • C (mật độ thông tin cao và HÌNH MINH HOẠ) — ⚠ phương án gây nhiễu mạnh nhất vì hình minh hoạ thật sự giúp truyền đạt: ⚠ nhưng hình ảnh làm ⚠ tăng MẬT ĐỘ, ⚠ không tự tạo ra TƯƠNG TÁC; ⚠ một tài liệu đầy sơ đồ đẹp mà không ai hỏi lại được vẫn là giao tiếp một chiều.

  • A (thấp ở cả hai) — ⚠ ngược hẳn; ⚠ đó là mô tả của kênh kém hiệu quả nhất.

  • D (ít thời gian và tính bao hàm cao) — ⚠ hai yếu tố này KHÔNG phải hai trục của mô hình; ⚠ ghép hai khái niệm không cùng hệ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25954 ở lô này (giao tiếp trực tiếp hiệu quả nhất) — ⚠ hai câu là hai mặt của cùng một vấn đề: câu kia hỏi KÊNH NÀO, câu này hỏi VÌ SAO. ⚠ Xem thêm câu #25948 (mô hình mã hoá-giải mã), câu #25949 (bốn ô văn bản/lời nói × chính thức/không), câu #25950 (ngôn ngữ cơ thể), câu #25942 (ràng buộc địa lý), và câu #25965 (cập nhật kế hoạch giao tiếp). ⚠ BẢY câu về giao tiếp trong lô này — kỷ lục của cả hai lô.

⚠ Xếp hạng kênh theo hai trục: | Kênh | Mật độ | Tương tác | Hiệu quả | |---|---|---|---| | ⚠ Trực tiếp có bảng vẽ | ⚠ rất cao | ⚠ rất cao | ⚠ cao nhất | | ⚠ Trực tiếp | ⚠ cao | ⚠ cao | ⚠ rất cao | | ⚠ Hội nghị truyền hình | ⚠ khá | ⚠ cao | ⚠ khá | | ⚠ Điện thoại | ⚠ trung bình | ⚠ cao | ⚠ trung bình | | ⚠ Tin nhắn tức thời | ⚠ thấp | ⚠ khá | ⚠ thấp | | ⚠ Email | ⚠ thấp | ⚠ thấp | ⚠ thấp | | ⚠ Tài liệu, video ghi sẵn | ⚠ trung bình | ⚠ không có | ⚠ thấp nhất | | ⚠ Nhận xét | ⚠ TƯƠNG TÁC là trục quan trọng hơn — video ghi sẵn có mật độ cao nhưng vẫn kém vì không hỏi lại được |

Từ khoá nhận diện:

"hiệu quả nhất" → ⚠ cao ở CẢ mật độ LẪN tương tác "hình minh hoạ" → ⚠ tăng mật độ, không tạo tương tác "tài liệu đầy đủ, gửi một chiều" → ⚠ kênh kém hiệu quả nhất "vừa nói vừa vẽ vừa hỏi" → ⚠ kênh tốt nhất

⚠ Áp dụng thực tế vào từng loại nội dung Nội dung
⚠ Thảo luận thiết kế, giải quyết vấn đề ⚠ cần TƯƠNG TÁC cao — gặp trực tiếp hoặc gọi video
⚠ Truyền đạt tin nhạy cảm ⚠ luôn trực tiếp, không bao giờ qua email
⚠ Thông tin tham chiếu cần tra lại ⚠ tài liệu — mật độ vừa đủ, không cần tương tác
⚠ Thông báo đại chúng ⚠ email hoặc bảng thông tin
⚠ Sai lầm phổ biến nhất ⚠ dùng email cho việc cần tranh luận — mười lượt qua lại trong ba ngày, đáng lẽ mười phút nói chuyện là xong
⚠ Với đội phân tán thì làm sao Cách
⚠ Bật CAMERA để lấy lại mật độ đã mất
⚠ Dùng bảng vẽ trực tuyến chung ⚠ kéo kênh lên gần với "trực tiếp có bảng vẽ"
⚠ Gặp mặt trực tiếp ít nhất một lần đầu dự án ⚠ vốn quan hệ này dùng được cả năm sau đó
⚠ Dành thời gian cho trò chuyện phi công việc ⚠ thứ tự nhiên có ở văn phòng nhưng biến mất khi làm từ xa
⚠ Nhắc lại ⚠ ràng buộc múi giờ có thể khiến tương tác thời gian thực bất khả thi — liên hệ #25942

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuỗi email dài nhất tuần qua của bạn có bao nhiêu lượt | ⚠ quá ba lượt là dấu hiệu chọn sai kênh | | Đội bạn có bật camera khi họp không | | | Tin xấu gần nhất được truyền đạt qua kênh nào | |

Và quy tắc thực dụng rút ra từ mô hình này: nếu bạn đang chuẩn bị gõ lần trả lời thứ ba trong cùng một chuỗi email, hãy nhấc máy lên gọi.

Câu 258 People
You are the project manager for Industrial Lights Project. Your project team can have access to the job site only between 8:00 p.m. and 7:00 a.m. Which project document would document this information for your project?
  1. A Project charter
  2. B Project calendar
  3. C Project schedule
  4. D Resource management plan
Xem giải thích

Đáp án

B — LỊCH DỰ ÁN (project calendar).

Vì sao đúng

⚠ Lịch dự án ghi gì: | Nội dung | Chi tiết | |---|---| | ⚠ NHỮNG NGÀY và GIỜ mà công việc dự án có thể diễn ra | ⚠ chính là thông tin của câu này | | ⚠ Ca làm việc, ngày nghỉ, ngày lễ | | | ⚠ Khoảng thời gian được tiếp cận địa điểm hoặc tài nguyên | ⚠ 20h tối tới 7h sáng | | ⚠ Là ĐẦU VÀO để xây dựng lịch trình | ⚠ không phải bản thân lịch trình | | ⚠ Vì sao quan trọng | ⚠ phần mềm lập lịch dùng lịch dự án để tính thời lượng thực tế của mỗi hoạt động |

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

  • C (lịch trình dự án) — ⚠ phương án gây nhiễu mạnh nhất vì tên gọi gần như giống hệt: ⚠ nhưng ⚠ lịch TRÌNH ghi hoạt động nào diễn ra KHI NÀO, ⚠ còn ⚠ lịch DỰ ÁN ghi KHI NÀO thì ĐƯỢC PHÉP làm việc; ⚠ lịch dự án là ĐẦU VÀO, lịch trình là ĐẦU RA.

  • D (kế hoạch quản lý nguồn lực) — ⚠ mô tả cách xác định, phân bổ và quản lý nguồn lực; ⚠ có thể nhắc tới ràng buộc, nhưng nơi ghi CỤ THỂ khung giờ làm việc là lịch dự án.

  • A (điều lệ dự án) — ⚠ tài liệu cấp cao ở giai đoạn khởi tạo; ⚠ không đi vào chi tiết vận hành như khung giờ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25938 ở lô này (đường găng có độ trễ bằng không), câu #25934 (quan hệ FS), câu #25935 (ràng buộc nguồn lực), và câu #25902 ở lô 183 (độ trễ toàn phần). ⚠ Nhóm quản lý lịch trình.

⚠ Phân biệt hai loại lịch: | Loại | Ghi gì | |---|---| | ⚠ LỊCH DỰ ÁN | ⚠ thời gian CÔNG VIỆC DỰ ÁN có thể diễn ra — CÂU NÀY | | ⚠ LỊCH NGUỒN LỰC | ⚠ thời gian TỪNG NGUỒN LỰC cụ thể sẵn sàng — Juan rảnh những ngày nào | | ⚠ Ví dụ khác nhau | ⚠ công trường mở 20h–7h là LỊCH DỰ ÁN; một kỹ sư chỉ làm ca đêm ba ngày mỗi tuần là LỊCH NGUỒN LỰC | | ⚠ Cả hai đều là | ⚠ ĐẦU VÀO của quy trình Xây dựng lịch trình |

Từ khoá nhận diện:

"chỉ được làm việc trong khung giờ nào" → ⚠ lịch dự án "nguồn lực cụ thể rảnh khi nào" → ⚠ lịch nguồn lực "hoạt động nào diễn ra ngày nào" → ⚠ lịch trình dự án "cách quản lý nguồn lực nói chung" → ⚠ kế hoạch quản lý nguồn lực

⚠ Ràng buộc chỉ làm ban đêm ảnh hưởng gì Ảnh hưởng
⚠ Cửa sổ làm việc chỉ 11 tiếng mỗi ngày ⚠ và phải trừ thời gian chuẩn bị, dọn dẹp
⚠ Chi phí NHÂN CÔNG CA ĐÊM cao hơn ⚠ phải tính vào ước lượng chi phí
⚠ Năng suất ban đêm thường thấp hơn ⚠ và tỷ lệ sai sót cao hơn
⚠ Khó huy động nhà cung cấp và hỗ trợ ngoài giờ
⚠ Vấn đề an toàn lao động khi làm đêm ⚠ liên hệ #25924 lô 183 — đầu tư phòng ngừa
⚠ Sai lầm nghiêm trọng ⚠ ước lượng thời lượng theo ngày làm việc 8 tiếng bình thường rồi mới phát hiện chỉ được vào công trường ban đêm
⚠ Các đầu vào để xây dựng lịch trình Đầu vào
⚠ Danh sách hoạt động và thuộc tính
⚠ Sơ đồ mạng lịch trình ⚠ quan hệ FS/SS/FF/SF — liên hệ #25934
⚠ Ước lượng thời lượng
⚠ Yêu cầu nguồn lực và LỊCH NGUỒN LỰC
⚠ LỊCH DỰ ÁN ⚠ CÂU NÀY
⚠ Ràng buộc và giả định
⚠ Thiếu lịch dự án ⚠ lịch trình sinh ra sẽ đẹp trên phần mềm và không chạy được ngoài đời

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch dự án của bạn có phản ánh đúng khung giờ thực tế không | | | Có tính ngày lễ và ngày nghỉ của mọi địa điểm không | ⚠ quan trọng với dự án đa quốc gia — liên hệ #25942 | | Ước lượng thời lượng của bạn dựa trên bao nhiêu giờ mỗi ngày | |

Và bài học từ một ràng buộc tưởng như nhỏ: một dòng "chỉ được vào công trường từ 20h tới 7h" có thể làm thay đổi toàn bộ lịch trình, ngân sách và kế hoạch nhân sự của dự án — nếu nó được ghi nhận. Và nếu không, nó sẽ làm thay đổi tất cả những thứ đó vào tuần thứ hai của dự án.

Câu 259 Business Environment
The project manager reports that the project is progressing according to scope. Management asks to change a few requirements with the scope. Which plan details how requirements will be analyzed, documented, and managed in the project?
  1. A The scope management plan
  2. B The change control system
  3. C The communication management plan
  4. D The requirements management plan
Xem giải thích

Đáp án

D — KẾ HOẠCH QUẢN LÝ YÊU CẦU (requirements management plan).

Vì sao đúng

⚠ Kế hoạch quản lý yêu cầu mô tả gì: | Nội dung | Chi tiết | |---|---| | ⚠ Cách THU THẬP yêu cầu | ⚠ phỏng vấn, hội thảo, khảo sát, nguyên mẫu | | ⚠ Cách PHÂN TÍCH yêu cầu | ⚠ đúng từ khoá trong đề | | ⚠ Cách GHI NHẬN yêu cầu | ⚠ đúng từ khoá trong đề | | ⚠ Cách QUẢN LÝ thay đổi về yêu cầu | ⚠ đúng từ khoá trong đề | | ⚠ Cấu trúc MA TRẬN TRUY XUẤT yêu cầu | ⚠ liên kết yêu cầu với bàn giao và với mục tiêu kinh doanh | | ⚠ Ba động từ trong đề | ⚠ "phân tích, ghi nhận, quản lý" là mô tả gần như nguyên văn của tài liệu này |

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

  • A (kế hoạch quản lý phạm vi) — ⚠ phương án gây nhiễu mạnh nhất vì hai kế hoạch này là anh em ruột: ⚠ nhưng kế hoạch quản lý phạm vi nói về ⚠ cách XÂY DỰNG, XÁC NHẬN và KIỂM SOÁT PHẠM VI nói chung ⚠ (lập WBS, nghiệm thu, kiểm soát phạm vi), ⚠ còn cách xử lý YÊU CẦU cụ thể thì nằm ở kế hoạch riêng.

  • B (hệ thống kiểm soát thay đổi) — ⚠ cơ chế xét duyệt thay đổi; ⚠ không mô tả cách phân tích và ghi nhận yêu cầu.

  • C (kế hoạch quản lý giao tiếp) — ⚠ về ai nhận thông tin gì, ⚠ không liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25977 ở lô này (tiêu chí chấp nhận), câu #25959 (bàn giao), câu #25975 (mạ vàng), và câu #25966 (kế hoạch quản lý cấu hình). ⚠ Nhóm phạm vi và yêu cầu.

⚠ Các kế hoạch phụ hay bị lẫn: | Kế hoạch | Trả lời câu hỏi | |---|---| | ⚠ QUẢN LÝ YÊU CẦU | ⚠ yêu cầu được thu thập, phân tích, ghi nhận, truy xuất và thay đổi ra sao — CÂU NÀY | | ⚠ QUẢN LÝ PHẠM VI | ⚠ phạm vi được xác định, chia nhỏ (WBS), xác nhận và kiểm soát ra sao | | ⚠ QUẢN LÝ CẤU HÌNH | ⚠ đặc tính kỹ thuật và phiên bản tài liệu được kiểm soát ra sao — liên hệ #25966 | | ⚠ QUẢN LÝ THAY ĐỔI | ⚠ yêu cầu thay đổi được đề xuất, xét duyệt và triển khai ra sao | | ⚠ Bốn kế hoạch này | ⚠ đều là phần của KẾ HOẠCH QUẢN LÝ DỰ ÁN, và rất hay bị hỏi lẫn nhau |

Từ khoá nhận diện:

"phân tích, ghi nhận, quản lý YÊU CẦU" → ⚠ kế hoạch quản lý yêu cầu "WBS, xác nhận phạm vi, kiểm soát phạm vi" → ⚠ kế hoạch quản lý phạm vi "phiên bản tài liệu, đặc tính kỹ thuật" → ⚠ kế hoạch quản lý cấu hình "duyệt hay từ chối thay đổi" → ⚠ kiểm soát thay đổi tích hợp

⚠ MA TRẬN TRUY XUẤT YÊU CẦU — công cụ trung tâm Nội dung
⚠ Nối mỗi YÊU CẦU với NGUỒN GỐC của nó ⚠ ai đề xuất, vì sao
⚠ Nối yêu cầu với MỤC TIÊU KINH DOANH ⚠ để loại yêu cầu không phục vụ mục tiêu nào
⚠ Nối yêu cầu với BÀN GIAO và TRƯỜNG HỢP KIỂM THỬ
⚠ Ghi TRẠNG THÁI của từng yêu cầu
⚠ Giá trị lớn nhất ⚠ khi lãnh đạo đòi đổi vài yêu cầu — đúng tình huống của đề — ma trận cho biết NGAY việc đó chạm tới những gì
⚠ Vì sao "đổi vài yêu cầu" không bao giờ nhỏ như nghe thấy Lý do
⚠ Một yêu cầu thường liên quan tới nhiều bàn giao
⚠ Có thể kéo theo thay đổi thiết kế và kiểm thử
⚠ Có thể mâu thuẫn với yêu cầu khác đã duyệt
⚠ Phải qua kiểm soát thay đổi ⚠ liên hệ #25978 — phân tích tác động trước
⚠ Điều PM phải làm ⚠ KHÔNG nói "được thôi" — nói "để tôi tra ma trận truy xuất rồi báo lại tác động"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có ma trận truy xuất yêu cầu không | | | Mỗi yêu cầu có nối được với một mục tiêu kinh doanh không | ⚠ yêu cầu không nối được với mục tiêu nào là ứng viên để loại | | Ai được quyền phê duyệt thay đổi yêu cầu | |

Và lý do tồn tại của một kế hoạch riêng cho yêu cầu: phạm vi nói cho bạn biết phải làm gì, còn yêu cầu nói cho bạn biết vì sao. Khi có người xin đổi, chỉ vế thứ hai mới trả lời được câu hỏi đổi thì mất gì.

Câu 260 People
Phylis is a project manager on project GVX. During a recent prioritization meeting, two of her stakeholders got into an argument over which tasks should be prioritized. By the end of the meeting, neither stakeholder was satisfied, and the task list is still not finalized. What should Phylis do next?
  1. A Do nothing. The stakeholders will determine a list eventually.
  2. B Since the stakeholders could not agree, Phylis should determine the order herself.
  3. C Review what she knows about each stakeholder and meet with them together to negotiate a list.
  4. D Ask the project management office to prioritize the tasks for the stakeholders.
Xem giải thích

Đáp án

C — Xem lại những gì mình biết về TỪNG bên liên quan, rồi GẶP CẢ HAI CÙNG LÚC để thương lượng ra danh sách.

Vì sao đúng

⚠ Hai vế của đáp án, cả hai đều cần: | Vế | Nội dung | |---|---| | ⚠ CHUẨN BỊ — xem lại thông tin về từng bên | ⚠ quyền lực, mức quan tâm, lợi ích, ràng buộc của họ | | ⚠ HỌP CHUNG để thương lượng | ⚠ không đi lại giữa hai bên, không quyết thay | | ⚠ Phylis ĐIỀU PHỐI chứ không PHÁN XỬ | | | ⚠ Danh sách ưu tiên phải do hai bên cùng chấp nhận | ⚠ nếu Phylis tự quyết thì cả hai đều không cam kết | | ⚠ Vì sao chuẩn bị trước | ⚠ hiểu LỢI ÍCH thật của mỗi bên mới tìm được điểm chung — không chuẩn bị thì buổi họp lặp lại đúng cuộc cãi cũ |

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

  • B (vì hai bên không thoả thuận được nên Phylis tự quyết thứ tự) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như PM đang nhận trách nhiệm: ⚠ nhưng ⚠ quyết thay hai bên liên quan sẽ khiến CẢ HAI cùng không hài lòng, ⚠ và ⚠ thứ tự ưu tiên phải phản ánh giá trị kinh doanh do bên liên quan xác định, ⚠ không phải ý riêng của PM.

  • D (nhờ PMO xếp ưu tiên hộ) — ⚠ leo thang không cần thiết; ⚠ Phylis chưa thử điều phối lần nào.

  • A (không làm gì, rồi họ cũng sẽ thống nhất) — ⚠ bỏ mặc; ⚠ đề nói rõ danh sách VẪN CHƯA hoàn tất và cả hai đều không hài lòng.

Ghi nhớ

⚠ Đối chiếu — câu thứ TƯ về xung đột trong lô này. Bảng tổng hợp cả bốn: | Câu | Ai xung đột | Đặc điểm | Khoá | |---|---|---|---| | ⚠ #25937 (Terry) | ⚠ trong đội | ⚠ giai đoạn sớm, có yếu tố cảm xúc | ⚠ TRAO QUYỀN cho đội tự giải quyết | | ⚠ #25945 (Oscar) | ⚠ hai lập trình viên | ⚠ bất đồng kỹ thuật, có dữ kiện phân xử | ⚠ chỉ tới TÀI LIỆU | | ⚠ #25963 (Benji) | ⚠ lập trình viên và product manager | ⚠ vi phạm quy trình vừa thống nhất | ⚠ CAN THIỆP, tìm nguồn gốc | | ⚠ #25982 (Phylis) | ⚠ hai BÊN LIÊN QUAN | ⚠ bế tắc, cả hai không hài lòng, công việc bị chặn | ⚠ CHUẨN BỊ rồi HỌP CHUNG thương lượng | ⚠ Bốn khoá KHÔNG mâu thuẫn — chúng minh hoạ NGUYÊN TẮC TƯƠNG XỨNG: mức can thiệp tăng dần theo mức nghiêm trọng và theo việc xung đột nằm TRONG hay NGOÀI đội. ⚠ Điểm chung xuyên suốt: người dẫn dắt LUÔN làm gì đó, và KHÔNG BAO GIỜ tự quyết thay khi những người trong cuộc còn có thể tự thoả thuận.

⚠ Vì sao xung đột giữa BÊN LIÊN QUAN khó hơn xung đột trong đội: | Lý do | Nội dung | |---|---| | ⚠ PM không có thẩm quyền với họ | ⚠ chỉ có thể thuyết phục, không thể chỉ đạo | | ⚠ Họ có lợi ích ở ngoài dự án | ⚠ ngân sách phòng ban, chỉ tiêu riêng | | ⚠ Xung đột có thể phản ánh mâu thuẫn ở cấp tổ chức | | | ⚠ Không có quy tắc chung của đội để viện dẫn | ⚠ liên hệ #25970 | | ⚠ Công cụ chính | ⚠ THƯƠNG LƯỢNG và DỮ LIỆU — không phải quyền lực |

Từ khoá nhận diện:

"hai bên liên quan bất đồng về ưu tiên" → ⚠ chuẩn bị rồi họp chung thương lượng "PM tự quyết" → ⚠ cả hai bên đều không cam kết "nhờ PMO" → ⚠ leo thang trước khi tự thử "không làm gì" → ⚠ gần như luôn sai

⚠ Chuẩn bị cho buổi họp thương lượng thế nào Việc
⚠ Xem sổ đăng ký bên liên quan: quyền lực, quan tâm, lợi ích
⚠ Tìm hiểu VÌ SAO mỗi bên muốn ưu tiên như vậy ⚠ phân biệt VỊ THẾ với LỢI ÍCH
⚠ Chuẩn bị DỮ LIỆU khách quan ⚠ giá trị kinh doanh, chi phí, rủi ro của từng hạng mục
⚠ Chuẩn bị TIÊU CHÍ xếp ưu tiên chung ⚠ MoSCoW, giá trị/nỗ lực, WSJF — liên hệ #25912 lô 183
⚠ Đặt quy tắc cho buổi họp
⚠ Mấu chốt ⚠ chuyển cuộc tranh luận từ "ý tôi hay ý anh" sang "tiêu chí nào và dữ liệu nói gì"
⚠ Nếu họp chung vẫn không xong thì sao Bước tiếp
⚠ Đưa tiêu chí xếp hạng ra và cho điểm công khai
⚠ Tìm phương án thứ ba mà cả hai chấp nhận được ⚠ thắng-thắng — liên hệ #25916 lô 183
⚠ Nếu vẫn bế tắc thì mới LEO THANG lên nhà tài trợ ⚠ liên hệ #25906 — nhà tài trợ gỡ vướng vượt thẩm quyền PM
⚠ Thứ tự ⚠ leo thang là bước SAU khi đã thử điều phối, không phải bước đầu tiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có TIÊU CHÍ xếp ưu tiên được thống nhất trước không | ⚠ không có tiêu chí thì mọi cuộc bàn ưu tiên đều thành tranh cãi | | Bạn có biết lợi ích thật của từng bên liên quan không | | | Ai là người quyết cuối cùng khi hai bên không thoả thuận được | ⚠ nên biết trước, đừng đợi tới lúc bế tắc |

Và điều khiến buổi họp thứ hai khác buổi họp thứ nhất: lần đầu hai bên nói về thứ họ muốn, lần sau Phylis sẽ khiến họ nói về lý do họ muốn — và đó là chỗ duy nhất tìm ra được điểm chung.