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

Tìm thấy 720 câu.

Câu 171 People
Killian is the project manager for an agile team that has been doing things for a long time. As early adopters of agile methodologies, they are well seasoned in many ways but fixed in some others. The coders and developers on the team are experienced but have not learned some newer coding languages and disciplines. What should Killian do with his project team?
  1. A Nothing, the team is already ahead of the curve by utilizing agile.
  2. B Fire the team and hire younger coders and developers.
  3. C Teach them scrum.
  4. D Assess the team's skillset collectively and individually.
Xem giải thích

Đáp án

D — ĐÁNH GIÁ bộ kỹ năng của đội, cả ở mức TẬP THỂ lẫn mức CÁ NHÂN.

Vì sao đúng

⚠ Vì sao đánh giá là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Đội đã có kinh nghiệm nhưng CỨNG NHẮC ở một số mặt | ⚠ cần biết cụ thể cứng ở đâu | | ⚠ Thiếu một số NGÔN NGỮ và KỶ LUẬT lập trình mới | ⚠ nhưng cụ thể ai thiếu gì thì chưa rõ | | ⚠ Đánh giá TẬP THỂ cho biết khoảng trống của cả đội | | | ⚠ Đánh giá CÁ NHÂN cho biết ai cần học gì | | | ⚠ Kết luận | ⚠ có bức tranh cụ thể rồi mới thiết kế được kế hoạch phát triển phù hợp |

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

  • B (sa thải cả đội và tuyển lập trình viên trẻ hơn) — ⚠ SAI HẲN về nhiều mặt: ⚠ vứt bỏ kinh nghiệm agile quý giá, ⚠ phân biệt đối xử theo tuổi, ⚠ và ⚠ loại bỏ con người gần như luôn là đáp án sai trong đề PMP.

  • A (không làm gì, đội đã đi trước nhờ dùng agile) — ⚠ tự mãn: ⚠ agile nhấn mạnh CẢI TIẾN LIÊN TỤC, ⚠ và kỹ năng kỹ thuật lỗi thời sẽ tích tụ NỢ KỸ THUẬT.

  • C (dạy họ Scrum) — ⚠ SAI đối tượng: ⚠ đề nói đội là ⚠ người tiên phong áp dụng agile, rất thành thạo — họ đã biết Scrum rồi; ⚠ thứ họ thiếu là KỸ NĂNG KỸ THUẬT.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25858 ở lô 182 (đội có mức hiểu biết agile không đồng đều → đánh giá trước), câu #25867 (nghi ngờ đội không đủ năng lực → rà soát mục tiêu để xác định kỹ năng cần), và câu #25850 (đo hiệu quả đào tạo bằng hiệu suất). ⚠ Bốn câu cùng một chuỗi: đánh giá → thiết kế đào tạo → đo kết quả.

⚠ Vì sao đội agile kỳ cựu vẫn cần đánh giá kỹ năng: | Lý do | Nội dung | |---|---| | ⚠ Thành thạo QUY TRÌNH không đồng nghĩa với thành thạo KỸ THUẬT | | | ⚠ Công nghệ thay đổi nhanh hơn quy trình rất nhiều | | | ⚠ Đội lâu năm dễ hình thành thói quen khó bỏ | ⚠ "fixed in some others" như đề nói | | ⚠ Kỹ năng kỹ thuật lỗi thời sinh NỢ KỸ THUẬT | ⚠ velocity giảm dần theo thời gian | | ⚠ Liên hệ | ⚠ xem câu #25854 ở lô 182 — Scrum lo quản lý, XP lo kỹ thuật; thiếu vế kỹ thuật thì mã mục nát |

Từ khoá nhận diện:

"thiếu kỹ năng cụ thể" → ⚠ đánh giá khoảng trống trước "sa thải và tuyển người mới" → ⚠ luôn là đáp án sai "không làm gì, đã tốt rồi" → ⚠ tự mãn, trái tinh thần cải tiến liên tục "dạy Scrum cho đội đã thành thạo agile" → ⚠ sai đối tượng

⚠ Ma trận kỹ năng — công cụ Killian nên dùng Nội dung
⚠ HÀNG: từng thành viên
⚠ CỘT: các kỹ năng cần thiết
⚠ Ô: mức thành thạo hiện tại ⚠ ví dụ 0 tới 4
⚠ Nhìn theo CỘT: kỹ năng nào cả đội đều yếu ⚠ rủi ro tập thể
⚠ Nhìn theo HÀNG: ai cần phát triển gì
⚠ Ô chỉ có MỘT người biết ⚠ rủi ro phụ thuộc nhân sự chủ chốt
⚠ Cập nhật định kỳ ⚠ để thấy tiến bộ và phát hiện khoảng trống mới
⚠ Sau đánh giá, Killian có thể làm gì Phương án
⚠ Đào tạo có mục tiêu cho từng nhóm kỹ năng
⚠ Ghép cặp người biết với người chưa biết ⚠ lập trình cặp — xem câu #25854 ở lô 182
⚠ Dành thời gian học trong sprint ⚠ slack time hoặc spike
⚠ Mời chuyên gia bên ngoài hướng dẫn ⚠ xem câu #25776 ở lô 180
⚠ Bổ sung một hai người có kỹ năng mới vào đội ⚠ không phải thay cả đội
⚠ Đo kết quả ⚠ theo dõi cải thiện hiệu suất — xem câu #25850 ở lô 182
⚠ Cạm bẫy với đội kỳ cựu Cạm bẫy
⚠ Họ có thể PHẢN ĐỐI việc học cái mới ⚠ "chúng tôi vẫn làm thế này và vẫn ổn"
⚠ Kinh nghiệm lâu năm dễ thành sức ì
⚠ Đánh giá kỹ năng có thể bị hiểu là đánh giá năng lực để sàng lọc
⚠ Cách xử lý ⚠ nói rõ mục đích là PHÁT TRIỂN, không phải sàng lọc — xem câu #25783 ở lô 181

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ma trận kỹ năng không | | | Có kỹ năng nào chỉ một người biết không | ⚠ rủi ro phụ thuộc | | Đội có thời gian để học cái mới không | ⚠ không có thời gian thì đánh giá xong cũng vô ích |

Và điều dễ bị bỏ qua nhất với một đội đã thành công lâu năm: thành thạo cách làm cũ có thể trở thành rào cản với cách làm mới. Đánh giá khách quan là cách nhẹ nhàng nhất để đưa vấn đề ra bàn.

Câu 172 Process
Your team is working on the construction of a warehouse building for a distribution company. You have completed the project's design phase and are tasked by your supervisor to update the project management plan. This plan will include lessons learned from previous phases, an updated risk register, and changes to the original scope management plan. Which of the following artifacts best describes changes to the current project management plan?
  1. A Configuration management
  2. B Artifact management system
  3. C Version control
  4. D Configuration management system
Xem giải thích

Đáp án

C — Version control (kiểm soát phiên bản).

Vì sao đúng

⚠ Vì sao version control là câu trả lời: | Chi tiết trong đề | Suy ra | |---|---| | ⚠ Đề hỏi về thay đổi đối với KẾ HOẠCH QUẢN LÝ DỰ ÁN | ⚠ một TÀI LIỆU của dự án | | ⚠ Cập nhật bài học, sổ rủi ro, kế hoạch quản lý phạm vi | ⚠ đều là tài liệu | | ⚠ Version control theo dõi các PHIÊN BẢN của TÀI LIỆU | | | ⚠ Kết luận | ⚠ thay đổi TÀI LIỆU dự án → kiểm soát phiên bản |

Ghi nhớ về chất lượng câu hỏi: ⚠ Bộ đề có BA câu rất gần nhau về quản lý cấu hình và kiểm soát phiên bản, với BA khoá KHÁC NHAU. ⚠ Bảng đối chiếu — ⚠ đây là bộ ba quan trọng nhất cần phân biệt trong lô này: | Câu | Lô | Đề hỏi về | Khoá | Lý do | |---|---|---|---|---| | ⚠ #25886 | ⚠ 183 | ⚠ CÔNG CỤ quản lý thay đổi với SẢN PHẨM/DỊCH VỤ | ⚠ configuration management SYSTEM | ⚠ hỏi CÔNG CỤ nên có chữ "system" | | ⚠ #25894 | ⚠ 183 | ⚠ thay đổi với KẾ HOẠCH QUẢN LÝ DỰ ÁN | ⚠ VERSION CONTROL | ⚠ đối tượng là TÀI LIỆU | | ⚠ #25897 | ⚠ 183 | ⚠ ghi lại định hướng KỸ THUẬT và thay đổi ĐẶC TÍNH KỸ THUẬT | ⚠ CONFIGURATION MANAGEMENT | ⚠ đối tượng là ĐẶC TÍNH SẢN PHẨM | ⚠ Ba khoá đều đúng và KHÔNG mâu thuẫn — chúng phân biệt theo ĐỐI TƯỢNG và theo việc đề hỏi CÔNG CỤ hay KHÁI NIỆM.

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

  • D (configuration management system) và A (configuration management) — ⚠ quản lý cấu hình lo ĐẶC TÍNH KỸ THUẬT của SẢN PHẨM, ⚠ không lo phiên bản tài liệu kế hoạch.

  • B (artifact management system) — ⚠ không phải thuật ngữ chuẩn PMBOK.

Ghi nhớ

⚠ Quy tắc phân biệt — thuộc là làm đúng cả ba câu: | Câu hỏi | Trả lời | |---|---| | ⚠ Đối tượng là TÀI LIỆU? | ⚠ → VERSION CONTROL | | ⚠ Đối tượng là SẢN PHẨM và đặc tính kỹ thuật? | ⚠ → CONFIGURATION MANAGEMENT | | ⚠ Đề hỏi "CÔNG CỤ" hay "hệ thống"? | ⚠ → thêm chữ SYSTEM vào đáp án | | ⚠ Đề hỏi về việc PHÊ DUYỆT thay đổi? | ⚠ → CHANGE CONTROL |

⚠ Version control — kiểm soát phiên bản: | Đặc điểm | Nội dung | |---|---| | ⚠ Đánh SỐ PHIÊN BẢN cho mỗi lần cập nhật tài liệu | | | ⚠ Ghi ai sửa, sửa gì, khi nào | | | ⚠ Cho phép QUAY VỀ phiên bản cũ khi cần | | | ⚠ Luôn biết bản nào là bản CHÍNH THỨC hiện tại | | | ⚠ Là MỘT PHẦN của quản lý cấu hình | ⚠ nhưng khi đối tượng là tài liệu thì đây là thuật ngữ chính xác nhất |

Từ khoá nhận diện:

"thay đổi kế hoạch, tài liệu, hồ sơ" → ⚠ version control "thay đổi đặc tính kỹ thuật của sản phẩm" → ⚠ configuration management "công cụ để làm việc đó" → ⚠ thêm chữ system "duyệt hay từ chối thay đổi" → ⚠ change control / CCB

⚠ Vì sao kiểm soát phiên bản quan trọng với kế hoạch dự án Lý do
⚠ Kế hoạch được cập nhật NHIỀU LẦN trong dự án
⚠ Nhiều người cùng tham chiếu tới nó
⚠ Quyết định dựa trên bản CŨ có thể sai ⚠ xem câu #25823 ở lô 181 — bên liên quan cầm bản cũ
⚠ Cần biết ĐƯỜNG CƠ SỞ nào đang có hiệu lực
⚠ Đặc biệt khi ⚠ kết thúc một giai đoạn và cập nhật hàng loạt như tình huống trong đề
⚠ Việc cần làm khi cập nhật kế hoạch cuối giai đoạn Bước
⚠ Tăng SỐ PHIÊN BẢN của kế hoạch
⚠ Ghi rõ NHỮNG GÌ đã thay đổi so với bản trước
⚠ Nếu đổi ĐƯỜNG CƠ SỞ: phải qua kiểm soát thay đổi chính thức ⚠ cập nhật tài liệu thì tự do, đổi đường cơ sở thì không
⚠ THÔNG BÁO cho mọi bên đang dùng bản cũ
⚠ Lưu bản cũ để tra cứu, không xoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu của bạn có số phiên bản và ngày không | | | Mọi người có biết đâu là bản chính thức không | | | Thay đổi đường cơ sở có đi qua kiểm soát thay đổi không | ⚠ khác với cập nhật tài liệu thông thường |

Và cách nhớ cả bộ ba câu này bằng một câu: tài liệu thì phiên bản, sản phẩm thì cấu hình, quyết định thì kiểm soát thay đổi.

Câu 173 Process
Peter is managing a multinational website development project for the Culinary Institute, Inc. The project aims to replace the Institute's current website version, which will significantly update web-based training classes and make the site much more user-friendly for the students and staff. Peter is at a company party where he meets some of the key users of the updated version of the website, as it is available. These key users describe some infuriating aspects of the current version of the website. As Peter listens, he collects the feedback to discuss with the project sponsor later. Which of the following choices best describes what Peter has done in this scenario?
  1. A Stakeholder analysis
  2. B Scope planning
  3. C Integrated change control
  4. D Scope validation
Xem giải thích

Đáp án

A — Stakeholder analysis (phân tích bên liên quan).

Vì sao đúng

⚠ Những gì Peter đang làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Gặp NGƯỜI DÙNG CHÍNH của sản phẩm | ⚠ họ là bên liên quan quan trọng | | ⚠ LẮNG NGHE mối bức xúc của họ với phiên bản hiện tại | ⚠ thu thập kỳ vọng và mối quan tâm | | ⚠ GHI NHẬN phản hồi để bàn với nhà tài trợ sau | ⚠ xử lý qua kênh chính thức | | ⚠ Kết luận | ⚠ thu thập và phân tích thông tin về nhu cầu, kỳ vọng và mối quan tâm của bên liên quan |

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

  • B (Scope planning) — ⚠ là việc lập kế hoạch quản lý phạm vi; ⚠ phản hồi này CÓ THỂ dẫn tới thay đổi phạm vi, ⚠ nhưng hành động hiện tại là THU THẬP thông tin.

  • D (Scope validation) — ⚠ là khách hàng chính thức NGHIỆM THU bàn giao; ⚠ dự án chưa có bàn giao nào để nghiệm thu.

  • C (Integrated change control) — ⚠ là quy trình xử lý yêu cầu thay đổi CHÍNH THỨC; ⚠ Peter mới nghe, chưa có yêu cầu thay đổi nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25699 ở lô 179 (ghi lợi ích và lo ngại của bên liên quan vào sổ đăng ký), câu #25715 (brainwriting để nhận diện bên liên quan), và câu #25890 ở lô này (ưu tiên làm quen ai). ⚠ Bốn câu cùng nhóm kiến thức quản lý bên liên quan.

⚠ Phân tích bên liên quan gồm những gì: | Nội dung | Chi tiết | |---|---| | ⚠ NHẬN DIỆN ai là bên liên quan | | | ⚠ Thu thập LỢI ÍCH, KỲ VỌNG và MỐI QUAN TÂM của họ | ⚠ đúng việc Peter đang làm | | ⚠ Đánh giá mức QUYỀN LỰC và ẢNH HƯỞNG | | | ⚠ Xác định mức THAM GIA hiện tại và mong muốn | | | ⚠ Phân loại bằng các mô hình | ⚠ power/interest grid, salience model, hướng ảnh hưởng | | ⚠ Kết quả | ⚠ stakeholder register — đầu vào cho kế hoạch tham gia |

Từ khoá nhận diện:

"lắng nghe nhu cầu và bức xúc của bên liên quan" → ⚠ stakeholder analysis "khách hàng nghiệm thu bàn giao" → ⚠ validate scope "nộp và duyệt yêu cầu thay đổi" → ⚠ integrated change control "lập kế hoạch cách quản lý phạm vi" → ⚠ scope planning

⚠ Vì sao thông tin thu được ở buổi tiệc lại quý Lý do
⚠ Người ta nói THẬT hơn khi không ở môi trường chính thức
⚠ Đây là NGƯỜI DÙNG THẬT, không phải người đại diện
⚠ Bức xúc với phiên bản CŨ chỉ ra đúng thứ cần cải thiện
⚠ Thông tin này khó thu được qua khảo sát chính thức
⚠ Peter làm đúng ⚠ LẮNG NGHE và GHI NHẬN, không hứa hẹn gì tại chỗ
⚠ Peter nên làm gì tiếp theo Bước
⚠ 1. GHI lại phản hồi khi còn nhớ rõ
⚠ 2. Cập nhật SỔ ĐĂNG KÝ BÊN LIÊN QUAN ⚠ thêm nhóm người dùng này và mối quan tâm của họ
⚠ 3. Bàn với nhà tài trợ như đã định
⚠ 4. Nếu phản hồi dẫn tới thay đổi phạm vi: mở YÊU CẦU THAY ĐỔI ⚠ lúc này mới tới integrated change control
⚠ 5. Cân nhắc thu thập phản hồi có hệ thống hơn ⚠ khảo sát, phỏng vấn, nhóm tập trung
⚠ Đừng ⚠ âm thầm đưa các yêu cầu này vào dự án — đó là scope creep
⚠ Lưu ý về ranh giới nghề nghiệp Lưu ý
⚠ Nghe thông tin ngoài giờ làm việc là bình thường
⚠ Nhưng KHÔNG hứa hẹn hay cam kết gì tại chỗ
⚠ Đưa mọi thứ về kênh CHÍNH THỨC để xử lý
⚠ Peter làm đúng ⚠ "thu thập để bàn với nhà tài trợ sau" — đúng ranh giới
⚠ Bối cảnh ĐA QUỐC GIA có ý nghĩa gì Ý nghĩa
⚠ Người dùng ở nhiều nơi có nhu cầu khác nhau
⚠ Nhóm gặp ở buổi tiệc có thể không đại diện cho tất cả
⚠ Cần thu thập có hệ thống hơn để có bức tranh đầy đủ ⚠ xem câu #25758 ở lô 180 về mẫu đại diện
⚠ Nhưng ⚠ đây vẫn là điểm khởi đầu quý giá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết người dùng THẬT nghĩ gì không | ⚠ hay chỉ nghe qua người đại diện | | Phản hồi có được ghi lại và xử lý không | | | Bạn có hứa gì mà chưa qua quy trình không | |

Và giá trị của những cuộc trò chuyện không chính thức: người dùng nói thật nhất khi họ không biết mình đang được phỏng vấn. Việc của PM là ghi lại và đưa nó về kênh chính thức.

Câu 174 Process
Jo is the project manager for Project HAL, deploying a new help center software to support ticketing agents. While reviewing the project plan, Jo notices that the project team does not directly interact with any ticketing agents. Ticketing agents take the incoming calls from the end-users. Why would Jo think this is a problem?
  1. A The ticketing agents are the product owners.
  2. B This makes knowledge transfer more challenging.
  3. C The project team should use the same equipment as the ticketing agents.
  4. D The steering committee asked Jo to co-locate his team and the ticketing agents.
Xem giải thích

Đáp án

B — Việc này làm cho CHUYỂN GIAO TRI THỨC trở nên khó khăn hơn.

Vì sao đúng

⚠ Vấn đề khi đội không tiếp xúc với người dùng thật: | Vấn đề | Nội dung | |---|---| | ⚠ Nhân viên tổng đài là NGƯỜI DÙNG CHÍNH của phần mềm | | | ⚠ Họ nắm TRI THỨC ẨN về công việc hằng ngày | ⚠ quy trình thật, tình huống ngoại lệ, thao tác nhanh | | ⚠ Tri thức ẩn chỉ chuyển giao qua TƯƠNG TÁC người với người | | | ⚠ Không tiếp xúc → đội phải ĐOÁN nhu cầu của họ | | | ⚠ Hậu quả | ⚠ phần mềm có thể đúng đặc tả nhưng không dùng được trong thực tế |

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

  • A (nhân viên tổng đài là product owner) — ⚠ SAI về vai trò: ⚠ họ là NGƯỜI DÙNG, không phải product owner; ⚠ product owner là một vai trò riêng.

  • C (đội nên dùng cùng thiết bị với nhân viên tổng đài) — ⚠ có thể hữu ích nhưng ⚠ quá HẸP; ⚠ vấn đề không nằm ở thiết bị mà ở TRI THỨC.

  • D (ban chỉ đạo yêu cầu cho hai bên ngồi cùng chỗ) — ⚠ không có căn cứ trong đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25630 ở lô 177 (tri thức ẩn chuyển giao qua tương tác), câu #25625 (reverse shadowing), và câu #25895 ngay trên (Peter lắng nghe người dùng thật). ⚠ Bốn câu cùng một bài học: tri thức về công việc thật nằm ở người làm công việc đó.

⚠ Tri thức ẩn của nhân viên tổng đài gồm những gì: | Loại | Ví dụ | |---|---| | ⚠ Quy trình THẬT khác quy trình trên giấy | ⚠ các bước tắt, cách xử lý ngoại lệ | | ⚠ Những tình huống hay gặp nhất | | | ⚠ Thao tác nào lặp lại nhiều lần trong ngày | ⚠ thứ cần tối ưu nhất | | ⚠ Điểm gây bực bội trong công cụ hiện tại | | | ⚠ Áp lực thời gian khi khách đang chờ máy | ⚠ yếu tố quyết định thiết kế giao diện | | ⚠ Không tài liệu nào ghi được | ⚠ phải quan sát và trò chuyện mới biết |

Từ khoá nhận diện:

"đội không tiếp xúc với người dùng" → ⚠ khó chuyển giao tri thức "tri thức trong đầu người làm việc" → ⚠ tacit knowledge "người dùng chính" → ⚠ khác với product owner "đi theo quan sát người làm việc" → ⚠ shadowing — cách thu tri thức ẩn

⚠ Jo nên làm gì Việc
⚠ Sắp xếp cho đội QUAN SÁT nhân viên tổng đài làm việc ⚠ shadowing — xem câu #25625 ở lô 177
⚠ Mời đại diện tổng đài tham gia buổi rà soát yêu cầu
⚠ Mời họ dự SPRINT REVIEW để cho phản hồi
⚠ Cho đội thử nghe vài cuộc gọi thật ⚠ hiểu áp lực thời gian
⚠ Xây PERSONA dựa trên người dùng thật ⚠ xem câu #25768 ở lô 180
⚠ Kiểm thử khả dụng với chính họ
⚠ Chi phí thấp ⚠ vài buổi quan sát, nhưng tránh được việc làm ra phần mềm không ai dùng
⚠ Rủi ro nếu không sửa Rủi ro
⚠ Phần mềm đúng đặc tả nhưng KHÔNG dùng được thực tế
⚠ Người dùng phản đối khi triển khai ⚠ xem câu #25890 ở lô này
⚠ Phải làm lại nhiều sau khi phát hành
⚠ Lợi ích dự kiến không đạt được ⚠ xem câu #25835 ở lô 182
⚠ Đây là ⚠ rủi ro rất phổ biến và rất đắt trong dự án phần mềm nội bộ
⚠ Nguyên tắc agile liên quan Nguyên tắc
⚠ "Người làm nghiệp vụ và người phát triển phải làm việc CÙNG NHAU hằng ngày" ⚠ nguyên tắc thứ tư của Tuyên ngôn Agile
⚠ On-site customer — thực hành của XP ⚠ khách hàng ngồi cùng đội
⚠ Tình huống của Jo ⚠ vi phạm trực tiếp nguyên tắc này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn đã gặp người dùng THẬT chưa | | | Đội có hiểu công việc hằng ngày của họ không | | | Yêu cầu đến từ người dùng hay từ người đại diện | ⚠ hai nguồn có thể rất khác nhau |

Và cách phát hiện sớm nhất một dự án phần mềm nội bộ sắp gặp rắc rối: hỏi đội xem họ đã ngồi cạnh người dùng thật bao nhiêu giờ. Con số đó thường nói lên nhiều điều hơn mọi báo cáo tiến độ.

Câu 175 Process
Abbas is the project manager for the Jefferson Project, designing and implementing a new application that connects to a database server. Management has asked him to create a method to document the project's technical direction and any changes or enhancements of the project deliverable's technical attributes. Of the following, which one will satisfy the management's request?
  1. A Configuration management
  2. B Scope control
  3. C Integrated change control
  4. D Change management plan
Xem giải thích

Đáp án

A — Configuration management (quản lý cấu hình).

Vì sao đúng

⚠ Vì sao quản lý cấu hình là câu trả lời: | Chi tiết trong đề | Suy ra | |---|---| | ⚠ Ghi lại ĐỊNH HƯỚNG KỸ THUẬT của dự án | ⚠ thuộc đặc tính sản phẩm | | ⚠ Ghi mọi THAY ĐỔI và NÂNG CẤP | | | ⚠ Đối tượng: ĐẶC TÍNH KỸ THUẬT của bàn giao | ⚠ từ khoá quyết định | | ⚠ Kết luận | ⚠ quản lý cấu hình lo chính xác việc này — theo dõi và kiểm soát đặc tính kỹ thuật của sản phẩm |

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

  • C (Integrated change control) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ đây là quy trình ⚠ PHÊ DUYỆT hay từ chối thay đổi, ⚠ không phải cơ chế GHI LẠI và theo dõi đặc tính kỹ thuật.

  • D (Change management plan) — ⚠ là kế hoạch mô tả CÁCH quản lý thay đổi, ⚠ không phải cơ chế ghi lại đặc tính kỹ thuật.

  • B (Scope control) — ⚠ lo việc ngăn phạm vi phình ra, ⚠ không lo đặc tính kỹ thuật.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là câu THỨ BA trong bộ ba câu rất gần nhau CÙNG LÔ về quản lý cấu hình và kiểm soát phiên bản. ⚠ Bảng đối chiếu đầy đủ: | Câu | Đề hỏi về | Khoá | Lý do phân biệt | |---|---|---|---| | ⚠ #25886 | ⚠ CÔNG CỤ quản lý thay đổi với SẢN PHẨM/DỊCH VỤ | ⚠ configuration management SYSTEM | ⚠ hỏi CÔNG CỤ → có chữ "system" | | ⚠ #25894 | ⚠ thay đổi với KẾ HOẠCH QUẢN LÝ DỰ ÁN | ⚠ VERSION CONTROL | ⚠ đối tượng là TÀI LIỆU | | ⚠ #25897 | ⚠ ghi định hướng và thay đổi ĐẶC TÍNH KỸ THUẬT | ⚠ CONFIGURATION MANAGEMENT | ⚠ đối tượng là ĐẶC TÍNH SẢN PHẨM, hỏi KHÁI NIỆM | ⚠ Ba khoá đều ĐÚNG và KHÔNG mâu thuẫn. ⚠ Bộ ba này là bài kiểm tra rất kỹ về việc phân biệt ĐỐI TƯỢNG (tài liệu hay sản phẩm) và CẤP ĐỘ (khái niệm hay công cụ).

⚠ Quy tắc phân biệt — thuộc là làm đúng cả ba: | Câu hỏi kiểm tra | Trả lời | |---|---| | ⚠ Đối tượng là TÀI LIỆU? | ⚠ → VERSION CONTROL | | ⚠ Đối tượng là SẢN PHẨM và đặc tính kỹ thuật? | ⚠ → CONFIGURATION MANAGEMENT | | ⚠ Đề dùng chữ "CÔNG CỤ" hay "hệ thống"? | ⚠ → thêm SYSTEM vào đáp án | | ⚠ Đề nói về việc PHÊ DUYỆT? | ⚠ → CHANGE CONTROL |

⚠ Bốn hoạt động của quản lý cấu hình: | Hoạt động | Nội dung | |---|---| | ⚠ Configuration IDENTIFICATION | ⚠ xác định cái gì được đưa vào kiểm soát cấu hình | | ⚠ Configuration STATUS ACCOUNTING | ⚠ GHI NHẬN và BÁO CÁO trạng thái từng phiên bản — đúng yêu cầu của đề | | ⚠ Configuration VERIFICATION AND AUDIT | ⚠ kiểm tra sản phẩm khớp với đặc tả đã duyệt | | ⚠ Configuration CONTROL | ⚠ kiểm soát việc thay đổi các mục trong cấu hình |

Từ khoá nhận diện:

"định hướng kỹ thuật, đặc tính kỹ thuật của bàn giao" → ⚠ configuration management "phiên bản tài liệu, kế hoạch" → ⚠ version control "duyệt hay từ chối yêu cầu thay đổi" → ⚠ integrated change control "kế hoạch mô tả cách quản lý thay đổi" → ⚠ change management plan

⚠ Quan hệ giữa quản lý cấu hình và kiểm soát thay đổi Quan hệ
⚠ CHANGE CONTROL quyết định CÓ ĐỔI hay không
⚠ CONFIGURATION MANAGEMENT đảm bảo sau khi đổi thì AI CŨNG DÙNG ĐÚNG BẢN
⚠ Cả hai nằm trong Perform Integrated Change Control
⚠ Bổ sung cho nhau ⚠ thiếu vế đầu thì thay đổi tuỳ tiện; thiếu vế sau thì mỗi người dùng một bản
⚠ Vì sao dự án của Abbas cần điều này Lý do
⚠ Ứng dụng KẾT NỐI với máy chủ cơ sở dữ liệu ⚠ giao diện kỹ thuật phải khớp chính xác giữa hai bên
⚠ Thay đổi một bên có thể phá vỡ bên kia
⚠ Cần biết phiên bản nào tương thích với phiên bản nào
⚠ Không có quản lý cấu hình ⚠ rất dễ có tình trạng "chạy được trên máy tôi" mà không chạy ở nơi khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết đặc tính kỹ thuật nào đang là bản chính thức không | | | Thay đổi kỹ thuật có được ghi lại và thông báo không | | | Sản phẩm thực tế có khớp với đặc tả đã duyệt không | ⚠ đó là việc của configuration audit |

Và câu tóm gọn cả bộ ba: tài liệu thì phiên bản, sản phẩm thì cấu hình, quyết định thì kiểm soát thay đổi.

Câu 176 Process
Jakub is creating a responsibility assignment matrix for his team. This project artifact denotes who is responsible for completing a specific task, who is accountable for reviewing it when it is completed, who can be consulted about a task, and who should be kept informed about a given task's progress. The matrix is kept in a publicly accessible repository where anyone can read it, but only Jakub can edit it. This is an example of which element of project governance?
  1. A Defining roles and responsibilities
  2. B Identifying, escalating, and resolving risks
  3. C Stage-gate or phase reviews
  4. D Capturing lessons learned
Xem giải thích

Đáp án

A — Defining roles and responsibilities (xác định vai trò và trách nhiệm).

Vì sao đúng

⚠ Những gì Jakub làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Lập MA TRẬN GÁN TRÁCH NHIỆM — RACI | | | ⚠ Ghi rõ ai LÀM, ai CHỊU TRÁCH NHIỆM, ai được THAM VẤN, ai được THÔNG BÁO | ⚠ đúng bốn chữ của RACI | | ⚠ Lưu ở kho CÔNG KHAI ai cũng đọc được | ⚠ minh bạch | | ⚠ Chỉ Jakub được sửa | ⚠ kiểm soát phiên bản — một nguồn duy nhất | | ⚠ Kết luận | ⚠ đây là cơ chế quản trị bằng việc phân vai rõ ràng và minh bạch |

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

  • D (thu thập bài học kinh nghiệm) — ⚠ là ghi lại điều đã học; ⚠ RACI là công cụ phân vai TRƯỚC khi làm.

  • B (nhận diện, leo thang và xử lý rủi ro) — ⚠ là cơ chế xử lý vấn đề và rủi ro.

  • C (rà soát cổng giai đoạn) — ⚠ là điểm rà soát định kỳ cuối giai đoạn.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là câu THỨ NĂM trong bộ đề dùng cùng bốn phương án về yếu tố quản trị dự án — và là câu THỨ HAI có khoá "defining roles and responsibilities". ⚠ Bảng tổng hợp đầy đủ: | Câu | Lô | Bối cảnh | Khoá | Chữ cái | |---|---|---|---|---| | ⚠ #25730 | ⚠ 179 | ⚠ chính sách không trả đũa, kênh ẩn danh | ⚠ nhận diện – leo thang – xử lý rủi ro | ⚠ C | | ⚠ #25757 | ⚠ 180 | ⚠ giữ vật chứng làm giáo cụ | ⚠ thu thập bài học | ⚠ D | | ⚠ #25761 | ⚠ 180 | ⚠ retrospective sau sự cố, đăng wiki | ⚠ thu thập bài học | ⚠ C | | ⚠ #25843 | ⚠ 182 | ⚠ giao việc theo vai trò, nêu rõ bàn giao | ⚠ vai trò và trách nhiệm | ⚠ B | | ⚠ #25898 | ⚠ 183 | ⚠ ma trận RACI công khai | ⚠ vai trò và trách nhiệm | ⚠ A | ⚠ Năm khoá đều đúng, không mâu thuẫn, và chữ cái xáo ở mọi câu. ⚠ Đây là bộ câu được lặp lại nhiều nhất trong toàn bộ đề — chỉ còn "stage-gate reviews" là chưa từng làm khoá.

⚠ Bốn yếu tố quản trị dự án — bảng cuối: | Yếu tố | Nhận ra bằng | |---|---| | ⚠ Defining roles and responsibilities | ⚠ RACI, phân vai, ai làm gì — CÂU NÀY | | ⚠ Capturing lessons learned | ⚠ ghi lại và chia sẻ điều đã học | | ⚠ Identifying, escalating, resolving risks | ⚠ cơ chế liên tục phát hiện và xử lý vấn đề | | ⚠ Stage-gate / phase reviews | ⚠ rà soát định kỳ cuối giai đoạn |

⚠ RACI — nhắc lại: | Chữ | Nghĩa | Quy tắc | |---|---|---| | ⚠ R — Responsible | ⚠ người LÀM | ⚠ có thể nhiều người | | ⚠ A — Accountable | ⚠ người CHỊU TRÁCH NHIỆM cuối cùng, duyệt kết quả | ⚠ CHỈ MỘT người | | ⚠ C — Consulted | ⚠ được THAM VẤN — hai chiều | | | ⚠ I — Informed | ⚠ được THÔNG BÁO — một chiều | | | ⚠ Liên hệ | ⚠ xem câu #25810 ở lô 181 về chữ C |

Từ khoá nhận diện:

"RACI, ma trận trách nhiệm, ai làm gì" → ⚠ defining roles and responsibilities "ghi lại điều đã học" → ⚠ lessons learned "cơ chế báo cáo và xử lý vấn đề" → ⚠ risk governance "rà soát cuối giai đoạn" → ⚠ stage-gate

⚠ Chi tiết đáng chú ý về cách Jakub quản lý ma trận Chi tiết
⚠ Lưu ở kho CÔNG KHAI ⚠ minh bạch — ai cũng biết vai trò của mình và của người khác
⚠ CHỈ Jakub được sửa ⚠ kiểm soát phiên bản, tránh mỗi người sửa một kiểu
⚠ Đây là cách làm ⚠ cân bằng tốt giữa MINH BẠCH và KIỂM SOÁT — xem câu #25824 ở lô 181
⚠ Lưu ý ⚠ nhưng cần cơ chế để người khác ĐỀ XUẤT sửa khi phát hiện sai
⚠ Lợi ích của việc công khai ma trận RACI Lợi ích
⚠ Ai cũng biết mình chịu trách nhiệm gì
⚠ Biết phải hỏi ai khi cần
⚠ Phát hiện sớm việc không ai nhận hoặc nhiều người cùng nhận
⚠ Giảm tranh cãi "tôi tưởng anh làm"
⚠ Liên hệ ⚠ xem câu #25843 ở lô 182 — phân vai rõ tạo ra sự tự chủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi công việc có đúng một chữ A không | | | Ma trận có được công khai cho cả đội không | | | Có cơ chế để người khác đề xuất sửa không | |

Và giá trị của một ma trận RACI công khai: nó biến câu hỏi "ai làm việc này" từ một cuộc tranh luận thành một lần tra bảng.

Câu 177 Process
As the project manager of the KEY Project, Valarie is using an agile approach to the project. The development team and the product owner are discussing the size of the user stories for the upcoming sprint. The top requirement has been sized at 35 user stories, and the team's velocity is 22. What is the best course of action for this requirement?
  1. A Resize the story
  2. B Add more team members
  3. C Slice the story
  4. D Increase the velocity
Xem giải thích

Đáp án

C — CHIA NHỎ (slice) hạng mục đó.

Vì sao đúng

⚠ Vấn đề và giải pháp: | Chi tiết | Suy ra | |---|---| | ⚠ Hạng mục được ước lượng 35 điểm | | | ⚠ VELOCITY của đội chỉ 22 điểm mỗi sprint | | | ⚠ Hạng mục LỚN HƠN năng lực một sprint | ⚠ không thể hoàn thành trong một vòng lặp | | ⚠ Giải pháp | ⚠ CHIA NHỎ thành nhiều hạng mục, mỗi hạng mục vẫn phải mang GIÁ TRỊ độc lập |

⚠ Vì sao phải chia nhỏ: | Lý do | Nội dung | |---|---| | ⚠ Hạng mục không xong trong sprint thì KHÔNG tính điểm | ⚠ velocity ảo, tiến độ không đo được | | ⚠ Hạng mục lớn ước lượng KÉM CHÍNH XÁC hơn nhiều | | | ⚠ Chia nhỏ cho phép giao GIÁ TRỊ sớm hơn | | | ⚠ Dễ phát hiện vấn đề sớm | | | ⚠ Nguyên tắc | ⚠ hạng mục nên đủ nhỏ để hoàn thành gọn trong một sprint |

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

  • A (ước lượng lại hạng mục) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ước lượng lại ⚠ không làm công việc nhỏ đi; ⚠ đổi con số mà không đổi khối lượng là tự lừa mình.

  • D (tăng velocity) — ⚠ VÔ NGHĨA: ⚠ velocity là số ĐO ĐƯỢC từ lịch sử, ⚠ không phải con số đặt ra; ⚠ xem câu #25880 ở lô 182.

  • B (thêm người vào đội) — ⚠ không giải quyết vấn đề hạng mục quá lớn; ⚠ và thêm người làm velocity giảm trong ngắn hạn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25880 ở lô 182 (velocity dao động vì ước lượng kém) và câu #25778 ở lô 180 (dùng velocity để kiểm chứng khối lượng sprint). ⚠ Ba câu cùng chủ đề velocity và ước lượng.

⚠ Các cách CHIA NHỎ một hạng mục lớn: | Cách | Ví dụ | |---|---| | ⚠ Theo BƯỚC trong quy trình nghiệp vụ | ⚠ đăng ký → xác nhận → kích hoạt | | ⚠ Theo LOẠI DỮ LIỆU | ⚠ xử lý một loại trước, các loại khác sau | | ⚠ Theo QUY TẮC NGHIỆP VỤ | ⚠ trường hợp đơn giản trước, ngoại lệ sau | | ⚠ Theo GIAO DIỆN | ⚠ giao diện cơ bản trước, tối ưu trải nghiệm sau | | ⚠ Theo THAO TÁC | ⚠ tạo, đọc, sửa, xoá — tách từng thao tác | | ⚠ Tách phần NGHIÊN CỨU thành spike riêng | | | ⚠ Nguyên tắc quan trọng nhất | ⚠ mỗi mảnh vẫn phải mang GIÁ TRỊ và có thể kiểm thử độc lập — không chia theo TẦNG kỹ thuật |

Từ khoá nhận diện:

"hạng mục lớn hơn velocity" → ⚠ chia nhỏ "ước lượng lại" → ⚠ không làm công việc nhỏ đi "tăng velocity" → ⚠ vô nghĩa, velocity là số đo "thêm người" → ⚠ không giải quyết vấn đề kích thước hạng mục

⚠ Sai lầm khi chia nhỏ Sai lầm
⚠ Chia theo TẦNG KỸ THUẬT ⚠ "làm cơ sở dữ liệu" rồi "làm giao diện" — không mảnh nào dùng được
⚠ Chia thành các công việc kỹ thuật rời rạc ⚠ mất tính giá trị độc lập
⚠ Chia quá vụn ⚠ tốn công quản lý hơn giá trị thu được
⚠ Cách đúng ⚠ mỗi mảnh là một lát cắt DỌC qua mọi tầng, mang giá trị dùng được
⚠ Thuật ngữ ⚠ vertical slicing — lát cắt dọc
⚠ Kích thước hạng mục hợp lý Hướng dẫn
⚠ Không quá 1/4 tới 1/3 velocity của sprint ⚠ với velocity 22 thì hạng mục nên dưới 8 điểm
⚠ Đủ nhỏ để hoàn thành gọn trong sprint
⚠ Đủ lớn để mang giá trị có nghĩa
⚠ Đây là ⚠ hướng dẫn kinh nghiệm, không phải luật cứng
⚠ Ai chịu trách nhiệm chia nhỏ Ai
⚠ ĐỘI và PRODUCT OWNER cùng làm ⚠ trong buổi backlog refinement
⚠ Product owner đảm bảo mỗi mảnh vẫn mang giá trị
⚠ Đội đảm bảo mỗi mảnh khả thi về kỹ thuật
⚠ Scrum Master ⚠ điều phối, không tự chia thay

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạng mục lớn nhất trong sprint chiếm bao nhiêu phần velocity | | | Mỗi mảnh sau khi chia có mang giá trị độc lập không | | | Đội có buổi refinement định kỳ không | ⚠ đó là nơi chia nhỏ diễn ra |

Và nguyên tắc đơn giản nhất về kích thước hạng mục: nếu không chắc làm xong trong một sprint thì chia nhỏ. Đổi con số ước lượng không làm công việc nhẹ đi.

Câu 178 Business Environment
Bruce is managing a project to construct a bridge spanning a large river. Two months into this project, the local government issues a new regulation that requires that bridge width be double in width from what Bruce was initially planning. Thankfully, the team has just been creating the blueprints and engineering of the bridge and has not yet started construction. Which of the following project aspects will be least affected by this new regulation?
  1. A Scope
  2. B Quality
  3. C Cost
  4. D Schedule
Xem giải thích

Đáp án

B — Quality (chất lượng). ⚠ Đây là khía cạnh ÍT bị ảnh hưởng nhất.

Vì sao đúng

⚠ Tác động của việc nhân đôi bề rộng cầu: | Khía cạnh | Tác động | |---|---| | ⚠ PHẠM VI | ⚠ ẢNH HƯỞNG LỚN — cầu rộng gấp đôi là công trình khác hẳn | | ⚠ CHI PHÍ | ⚠ ẢNH HƯỞNG LỚN — nhiều vật liệu, nhiều nhân công, nền móng lớn hơn | | ⚠ LỊCH TRÌNH | ⚠ ẢNH HƯỞNG LỚN — thiết kế lại, thi công nhiều hơn | | ⚠ CHẤT LƯỢNG | ⚠ ÍT ảnh hưởng — TIÊU CHUẨN kỹ thuật vẫn như cũ | | ⚠ Lý do | ⚠ cầu rộng gấp đôi vẫn phải đạt CÙNG tiêu chuẩn an toàn, cùng chuẩn vật liệu, cùng dung sai kỹ thuật |

⚠ Vì sao chất lượng ít bị ảnh hưởng: | Lý do | Nội dung | |---|---| | ⚠ Chất lượng là mức ĐÁP ỨNG YÊU CẦU | ⚠ yêu cầu kỹ thuật về độ bền, an toàn không đổi | | ⚠ Cầu rộng hơn là thay đổi về CẤP ĐỘ và QUY MÔ, không phải về chất lượng | ⚠ liên hệ cặp quality/grade — xem #25816, #25828 ở lô 181 | | ⚠ Chuẩn xây dựng và dung sai vẫn áp dụng như cũ | | | ⚠ Ngoại lệ nhỏ | ⚠ có thể cần kiểm tra thêm về mặt kỹ thuật, nhưng CHUẨN thì không đổi |

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

  • A (Scope), C (Cost), D (Schedule) — ⚠ cả ba ĐỀU bị ảnh hưởng nặng; ⚠ đề hỏi cái ÍT bị ảnh hưởng nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25886 ở lô này (thay đổi quy định xây dựng đòi cập nhật mẫu) — ⚠ cùng dạng tình huống: quy định mới buộc dự án thay đổi.

⚠ Sáu ràng buộc cạnh tranh của PMBOK: | Ràng buộc | Tác động trong tình huống này | |---|---| | ⚠ SCOPE — phạm vi | ⚠ đổi lớn | | ⚠ SCHEDULE — lịch trình | ⚠ đổi lớn | | ⚠ COST — chi phí | ⚠ đổi lớn | | ⚠ QUALITY — chất lượng | ⚠ ÍT đổi — CÂU NÀY | | ⚠ RESOURCES — nguồn lực | ⚠ cũng đổi lớn: cần thêm người và thiết bị | | ⚠ RISK — rủi ro | ⚠ cũng đổi: công trình lớn hơn, rủi ro cao hơn | | ⚠ Nguyên tắc | ⚠ đổi một ràng buộc thường kéo theo các ràng buộc khác |

Từ khoá nhận diện:

"nhân đôi quy mô công trình" → ⚠ phạm vi, chi phí, lịch đều đổi lớn "tiêu chuẩn kỹ thuật vẫn như cũ" → ⚠ chất lượng ít bị ảnh hưởng "quy mô và tính năng" → ⚠ GRADE "đáp ứng đúng yêu cầu" → ⚠ QUALITY

⚠ Điểm may mắn của Bruce Điểm
⚠ Đội mới đang làm BẢN VẼ và THIẾT KẾ
⚠ CHƯA bắt đầu thi công ⚠ chi phí thay đổi ở giai đoạn này THẤP HƠN NHIỀU
⚠ Liên hệ ⚠ quy tắc nhân 10 — lỗi bắt ở thiết kế rẻ hơn nhiều so với bắt ở thi công
⚠ Nếu đã đổ móng ⚠ chi phí thay đổi có thể lên tới mức phải huỷ dự án
⚠ Bruce nên làm gì Bước
⚠ 1. Xác nhận quy định mới là CHÍNH THỨC và bắt buộc áp dụng
⚠ 2. ĐÁNH GIÁ TÁC ĐỘNG đầy đủ lên sáu ràng buộc
⚠ 3. Nộp YÊU CẦU THAY ĐỔI qua kiểm soát thay đổi tích hợp
⚠ 4. Trình nhà tài trợ quyết: tăng ngân sách, dời hạn, hay huỷ dự án
⚠ 5. Nếu duyệt: cập nhật ĐƯỜNG CƠ SỞ phạm vi, lịch, chi phí
⚠ 6. Cập nhật sổ rủi ro
⚠ Đây là ⚠ thay đổi do YẾU TỐ MÔI TRƯỜNG DOANH NGHIỆP bên ngoài — không ai kiểm soát được
⚠ Vì sao thay đổi quy định pháp lý là rủi ro khó ứng phó Lý do
⚠ Nằm ngoài tầm kiểm soát của dự án và tổ chức ⚠ rủi ro HỆ THỐNG — xem câu #25892 ở lô này
⚠ Không thể né tránh, chỉ có thể tuân thủ
⚠ Thường xuất hiện đột ngột
⚠ Cách giảm ⚠ theo dõi môi trường pháp lý, dùng khung PESTLE khi nhận diện rủi ro — xem #25692 ở lô 179

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thay đổi này ảnh hưởng những ràng buộc nào | ⚠ rà đủ sáu, không chỉ ba | | Bạn đang ở giai đoạn nào khi phát hiện | ⚠ càng sớm càng rẻ | | Đã đưa qua kiểm soát thay đổi chưa | |

Và điều phân biệt "quy mô" với "chất lượng" trong tình huống này: cầu rộng gấp đôi vẫn phải an toàn đúng như cầu cũ. Quy mô đổi, chuẩn chất lượng không đổi.

Câu 179 People
Fallon is the project manager for her client's website creation project. Some of the employees at Withrow Logistics, Fallon's client, are happy about the change and are helping with Fallon's plan for the new website design. Fallon has identified the methods of stakeholder management in the stakeholder management plan. In which categorization has she also identified the positive stakeholders?
  1. A Supportive
  2. B Happy
  3. C Leading
  4. D Informed
Xem giải thích

Đáp án

A — Supportive (ủng hộ).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Nhân viên VUI VẺ về sự thay đổi | ⚠ thái độ tích cực | | ⚠ Họ ĐANG GIÚP với kế hoạch thiết kế trang web mới | ⚠ có hành động hỗ trợ thật | | ⚠ Nhưng KHÔNG chủ động dẫn dắt dự án | ⚠ phân biệt với mức LEADING | | ⚠ Kết luận | ⚠ biết dự án, ủng hộ, và có hỗ trợ — đúng mức SUPPORTIVE |

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

  • C (Leading — dẫn dắt) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ mức leading là ⚠ CHỦ ĐỘNG tham gia để đảm bảo dự án thành công — họ tự đứng ra tổ chức, vận động, gỡ vướng; ⚠ ở đây nhân viên chỉ ⚠ HỖ TRỢ khi được đề nghị.

  • D (Informed) — ⚠ KHÔNG phải một trong năm mức tham gia của PMBOK; ⚠ "Informed" là chữ I trong RACI — hai khái niệm khác nhau.

  • B (Happy) — ⚠ không phải thuật ngữ phân loại nào cả.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25702 ở lô 179 (bên liên quan TIÊU CỰC / resistant) và câu #25890 ở lô này (ưu tiên tiếp cận người phản đối). ⚠ Ba câu cùng dùng thang năm mức tham gia — câu này là đầu tích cực của thang đó.

⚠ Năm mức tham gia của bên liên quan: | Mức | Nghĩa | |---|---| | ⚠ UNAWARE | ⚠ chưa biết dự án tồn tại hoặc chưa biết tác động của nó | | ⚠ RESISTANT | ⚠ biết và CHỐNG lại thay đổi | | ⚠ NEUTRAL | ⚠ biết nhưng không ủng hộ cũng không phản đối | | ⚠ SUPPORTIVE | ⚠ biết và ỦNG HỘ, có hỗ trợ khi được đề nghị — CÂU NÀY | | ⚠ LEADING | ⚠ CHỦ ĐỘNG tham gia để đảm bảo dự án thành công | | ⚠ Công cụ | ⚠ stakeholder engagement assessment matrix — ghi mức HIỆN TẠI (C) và mức MONG MUỐN (D) |

Từ khoá nhận diện:

"vui vẻ, hỗ trợ khi được đề nghị" → ⚠ SUPPORTIVE "chủ động đứng ra vận động, tổ chức" → ⚠ LEADING "chống lại thay đổi" → ⚠ RESISTANT "chưa biết dự án" → ⚠ UNAWARE "Informed" → ⚠ là chữ I trong RACI, KHÔNG phải mức tham gia

⚠ Phân biệt hai thang dễ lẫn Thang
⚠ Mức THAM GIA (engagement level) ⚠ unaware, resistant, neutral, supportive, leading
⚠ Vai trò trong RACI ⚠ responsible, accountable, consulted, informed
⚠ Khác nhau hoàn toàn ⚠ một cái đo THÁI ĐỘ, một cái đo VAI TRÒ trong công việc
⚠ Bẫy thi ⚠ phương án "Informed" xuất hiện ở đây chính là để đánh lừa
⚠ Việc cần làm với bên liên quan ủng hộ Việc
⚠ GIỮ họ ở mức ủng hộ ⚠ đừng coi là chuyện đương nhiên
⚠ Tiếp tục thông tin đều đặn
⚠ GHI NHẬN đóng góp của họ
⚠ Cân nhắc nâng lên mức LEADING nếu họ có ảnh hưởng ⚠ người ủng hộ có ảnh hưởng là đồng minh quý
⚠ Cảnh báo ⚠ bên liên quan ủng hộ vẫn có thể chuyển sang trung lập nếu bị bỏ quên
⚠ Vì sao thang này quan trọng Lý do
⚠ Cho biết đầu tư thời gian vào ai ⚠ nơi khoảng cách C→D lớn nhất
⚠ Cho biết chiến lược tiếp cận phù hợp
⚠ Theo dõi được sự thay đổi thái độ theo thời gian
⚠ Liên hệ ⚠ xem câu #25890 ở lô này — ưu tiên nơi có khoảng cách lớn nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ma trận mức tham gia cho mọi bên liên quan không | | | Người ủng hộ có được duy trì không | ⚠ hay bị bỏ quên vì "họ ổn rồi" | | Có ai từ ủng hộ chuyển sang trung lập không | ⚠ dấu hiệu giao tiếp đang yếu đi |

Và cạm bẫy phổ biến với bên liên quan ủng hộ: coi sự ủng hộ là chuyện đương nhiên và ngừng chăm sóc họ. Sự ủng hộ cần được duy trì, không tự tồn tại mãi.

Câu 180 People
Carrie is the project manager for her organization, and she is leading a project scheduled to last nine months. Carrie reviews her project's network diagram, and she comes across a task that can be delayed three days without impacting the delivery milestone date. This task is said to have
  1. A Project float
  2. B Total float
  3. C Lead
  4. D Free float
Xem giải thích

Đáp án

B — Total float (dự trữ toàn phần).

Vì sao đúng

⚠ Định nghĩa chính xác: | Khái niệm | Nghĩa | |---|---| | ⚠ TOTAL FLOAT | ⚠ thời gian một hoạt động có thể trễ mà KHÔNG ảnh hưởng NGÀY KẾT THÚC DỰ ÁN hoặc MỐC ràng buộc | | ⚠ FREE FLOAT | ⚠ thời gian trễ mà KHÔNG ảnh hưởng NGÀY BẮT ĐẦU SỚM NHẤT của hoạt động KẾ TIẾP | | ⚠ Đề nói gì | ⚠ "trễ 3 ngày mà không ảnh hưởng NGÀY MỐC BÀN GIAO" — đó là TOTAL FLOAT |

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

  • D (Free float) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ free float đo ảnh hưởng tới ⚠ hoạt động KẾ TIẾP, ⚠ không phải tới ⚠ MỐC BÀN GIAO; ⚠ chỉ khác một cụm từ nhưng là hai khái niệm khác nhau.

  • C (Lead) — ⚠ là khoảng thời gian cho phép hoạt động sau BẮT ĐẦU SỚM hơn logic gốc; ⚠ không phải dự trữ thời gian.

  • A (Project float) — ⚠ không phải thuật ngữ chuẩn PMBOK; ⚠ đôi khi được dùng để chỉ dự trữ giữa ngày hoàn thành dự kiến và ngày ràng buộc, nhưng không phải tên gọi chính thức.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25603 ở lô 177 (free float) và câu #25658 ở lô 178 (đường găng là đường dài nhất về thời lượng). ⚠ Ba câu tạo thành bộ đầy đủ về các khái niệm float — và đây là cặp dễ nhầm nhất trong quản lý lịch trình.

⚠ Bảng phân biệt hai loại float: | Mục | TOTAL FLOAT | FREE FLOAT | |---|---|---| | ⚠ Ảnh hưởng tới | ⚠ ngày kết thúc DỰ ÁN hoặc MỐC ràng buộc | ⚠ ngày bắt đầu sớm nhất của hoạt động KẾ TIẾP | | ⚠ Công thức | ⚠ LS − ES hoặc LF − EF | ⚠ ES của hoạt động sau − EF của hoạt động này − 1 | | ⚠ Độ lớn | ⚠ LỚN HƠN hoặc BẰNG free float | ⚠ luôn nhỏ hơn hoặc bằng total float | | ⚠ Trên đường găng | ⚠ bằng 0 | ⚠ bằng 0 | | ⚠ Mẹo nhớ | ⚠ TOTAL nhìn tới CUỐI dự án; FREE nhìn tới việc NGAY SAU |

Từ khoá nhận diện:

"không ảnh hưởng ngày kết thúc dự án hoặc mốc" → ⚠ TOTAL float "không ảnh hưởng việc kế tiếp" → ⚠ FREE float "float bằng 0" → ⚠ đường găng "cho phép bắt đầu sớm hơn" → ⚠ LEAD "buộc phải chờ thêm" → ⚠ LAG

⚠ Cách tính float từ sơ đồ mạng: | Đại lượng | Nghĩa | |---|---| | ⚠ ES — Early Start | ⚠ ngày bắt đầu sớm nhất | | ⚠ EF — Early Finish | ⚠ ngày kết thúc sớm nhất | | ⚠ LS — Late Start | ⚠ ngày bắt đầu muộn nhất mà không trễ dự án | | ⚠ LF — Late Finish | ⚠ ngày kết thúc muộn nhất mà không trễ dự án | | ⚠ Total float = LS − ES = LF − EF | | | ⚠ Tính bằng | ⚠ forward pass cho ES và EF, backward pass cho LS và LF |

⚠ Vì sao float lại quan trọng Lý do
⚠ Cho biết hoạt động nào có thể trễ mà không sao ⚠ linh hoạt trong phân bổ nguồn lực
⚠ Float bằng 0 = đường găng = phải theo dõi sát nhất
⚠ Float ÂM nghĩa là dự án ĐÃ TRỄ so với ràng buộc ⚠ cần hành động ngay
⚠ Là cơ sở cho RESOURCE SMOOTHING ⚠ chỉ dùng phần float sẵn có nên không kéo dài dự án
⚠ Liên hệ ⚠ xem câu #25839 ở lô 182 về smoothing và levelling
⚠ Cảnh báo khi sử dụng float Cảnh báo
⚠ Float là của ĐƯỜNG, không phải của riêng một hoạt động ⚠ dùng hết float ở hoạt động này thì hoạt động sau trên cùng đường mất float
⚠ Float thay đổi khi lịch thực tế thay đổi ⚠ phải tính lại thường xuyên
⚠ Đường near-critical có float rất nhỏ ⚠ dễ trở thành đường găng
⚠ Vì thế ⚠ đừng coi float là "thời gian được phép lãng phí"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tính lại float sau mỗi lần cập nhật lịch không | | | Có hoạt động nào float âm không | ⚠ dấu hiệu dự án đã trễ so với ràng buộc | | Đội có hiểu float là của cả đường, không phải của riêng việc mình không | |

Và cách nhớ chắc chắn cặp khái niệm dễ nhầm nhất: TOTAL nhìn tới ĐÍCH, FREE nhìn tới NGƯỜI KẾ TIẾP. Đề nói tới "mốc bàn giao" nên đó là total float.