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

Tìm thấy 720 câu.

Câu 31 People
Fox and his stakeholder, Walter, have a difficult relationship. Although Fox is a dedicated project manager, his unorthodox methods for completing projects significantly differ from Walters' by-the-book approach. This leads to significant mistrust between Fox and Walter so that Walter often requires objective information corroborated by multiple sources before he will act on (or against) Fox's suggestions. Fox recognizes the difficulties inherent in the relationship and knows that he needs Walter's approval for the decisions that will make or break his projects. Which method should the project manager use to build trust and influence with the stakeholder?
  1. A Meetings
  2. B Surveys
  3. C Issue identification
  4. D Progress reporting
Xem giải thích

Đáp án

B — Surveys (khảo sát).

Vì sao đúng

⚠ Điều Walter cần, và vì sao khảo sát đáp ứng được: | Yêu cầu của Walter | Khảo sát cung cấp | |---|---| | ⚠ Thông tin KHÁCH QUAN | ⚠ dữ liệu định lượng, không phải ý kiến của Fox | | ⚠ Được XÁC NHẬN bởi NHIỀU NGUỒN | ⚠ khảo sát thu thập từ nhiều người cùng lúc | | ⚠ Có thể kiểm chứng độc lập | ⚠ Walter tự đọc số liệu, không phải tin lời Fox | | ⚠ Vấn đề gốc | ⚠ Walter KHÔNG TIN CÁ NHÂN Fox — nên mọi giải pháp phải giảm sự phụ thuộc vào lời của Fox |

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

  • A (Meetings — họp) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ họp là kênh giao tiếp tốt nói chung, ⚠ nhưng trong họp thì Fox vẫn là người trình bày — ⚠ vẫn là thông tin chủ quan qua một nguồn duy nhất.

  • D (Progress reporting — báo cáo tiến độ) — ⚠ cũng do Fox soạn, ⚠ nên với người đã mất niềm tin thì nó không đủ khách quan.

  • C (Issue identification — nhận diện vấn đề) — ⚠ là một hoạt động quản lý, ⚠ không phải phương pháp xây dựng niềm tin và ảnh hưởng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25726 ở lô 179 về bên liên quan bực dù dự án đúng tiến độ và câu #25702 về bên liên quan tiêu cực. ⚠ Ba câu cùng chủ đề: khi quan hệ với bên liên quan gặp trục trặc, giải pháp nằm ở CÁCH cung cấp thông tin.

⚠ Vì sao dữ liệu khách quan xây được niềm tin: | Cơ chế | Nội dung | |---|---| | ⚠ Tách QUAN ĐIỂM khỏi CON NGƯỜI | ⚠ Walter không phải chọn tin hay không tin Fox | | ⚠ Cho Walter cơ sở để tự kiểm chứng | ⚠ phù hợp với tính cách "theo sách vở" của ông ấy | | ⚠ Nhiều nguồn → giảm nghi ngờ thiên vị | | | ⚠ Lặp lại nhiều lần → xây dựng thành tích đáng tin | | | ⚠ Bài học | ⚠ với người hoài nghi, hãy để DỮ LIỆU nói thay vì cố thuyết phục bằng lời |

Từ khoá nhận diện:

"cần thông tin khách quan từ nhiều nguồn" → ⚠ khảo sát, dữ liệu định lượng "mất niềm tin cá nhân" → ⚠ giảm phụ thuộc vào lời nói của một người "theo sách vở, cần bằng chứng" → ⚠ cung cấp dữ liệu, không cung cấp ý kiến "ẩn danh, nhiều vòng, chuyên gia" → ⚠ Delphi — nếu vấn đề nhạy cảm

⚠ Fox nên làm gì ngoài khảo sát Việc
⚠ Ghi lại MỌI quyết định và căn cứ bằng văn bản
⚠ Dùng số liệu EVM thay vì nhận định định tính ⚠ CPI, SPI là con số ai cũng kiểm được
⚠ Mời bên thứ ba độc lập đánh giá khi cần
⚠ Giữ đúng cam kết, dù nhỏ ⚠ niềm tin xây bằng chuỗi lời hứa được giữ
⚠ Tìm hiểu vì sao Walter coi phương pháp của mình là bất quy tắc ⚠ có thể có lý do chính đáng
⚠ Đừng ⚠ coi Walter là chướng ngại vật — sự thận trọng của ông ấy có thể bảo vệ dự án
⚠ Các cách xây dựng ảnh hưởng khi không có thẩm quyền Cách
⚠ Expert power — chứng minh bằng chuyên môn
⚠ Dữ liệu khách quan ⚠ cách của câu này
⚠ Tìm điểm chung về MỤC TIÊU ⚠ cả hai đều muốn dự án thành công
⚠ Nhất quán và minh bạch
⚠ Nhờ bên thứ ba mà cả hai cùng tin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông tin bạn đưa có kiểm chứng độc lập được không | | | Bạn đang thuyết phục bằng lời hay bằng dữ liệu | | | Bạn có hiểu vì sao người kia hoài nghi không | ⚠ thường có lý do cụ thể, không phải ác ý |

Và nguyên tắc làm việc với người hoài nghi: đừng cố khiến họ tin BẠN, hãy cho họ thứ mà họ có thể tự kiểm chứng. Với người theo sách vở, dữ liệu luôn thuyết phục hơn sự nhiệt tình.

Câu 32 People
Kelli is the project manager for Project IV, which is nine weeks into implementation, has a CPI of .86 and an SPI of .99. After a recent deliverable failed, a senior stakeholder demanded Kelli remove a team member from the project. What should Kelli do next?
  1. A Investigate the root cause of the failure.
  2. B Speak to the team member's manager.
  3. C Remove that team member from Project V.
  4. D Escalate the issue to the steering committee.
Xem giải thích

Đáp án

A — ĐIỀU TRA nguyên nhân gốc của sự cố.

Vì sao đúng

⚠ Vì sao phải điều tra trước: | Lý do | Nội dung | |---|---| | ⚠ CHƯA BIẾT nguyên nhân thật sự | ⚠ có thể do quy trình, do yêu cầu mơ hồ, do thiếu nguồn lực | | ⚠ CPI = 0,86 — vượt chi ĐÁNG KỂ | ⚠ cho thấy vấn đề có thể mang tính hệ thống | | ⚠ SPI = 0,99 — tiến độ gần như đúng kế hoạch | ⚠ nên vấn đề nằm ở CHI PHÍ và CHẤT LƯỢNG, không ở tốc độ | | ⚠ Đuổi người khi chưa biết nguyên nhân là phản ứng cảm tính | | | ⚠ Nguyên tắc Deming | ⚠ phần lớn vấn đề do HỆ THỐNG, không do cá nhân |

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

  • B (nói chuyện với quản lý của thành viên đó) — ⚠ giả định thành viên đó có lỗi, ⚠ trong khi chưa điều tra.

  • C (loại thành viên đó khỏi Project V) — ⚠ hành động theo yêu cầu của bên liên quan mà chưa xác minh; ⚠ và lưu ý đề nhắc tới ⚠ Project V trong khi đang nói về Project IV — ⚠ càng vô lý.

  • D (leo thang lên ban chỉ đạo) — ⚠ quá sớm: ⚠ chưa có thông tin gì để trình bày; ⚠ leo thang mà không có dữ kiện chỉ chuyển vấn đề chứ không giải quyết.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25725 ở lô 179 — ⚠ Samuel làm chậm, và "loại khỏi đội" là hành động KHÔNG phù hợp. ⚠ Hai câu gần như song sinh: cùng một áp lực đuổi người, cùng một câu trả lời là tìm nguyên nhân gốc trước. ⚠ Và câu #25653 ở lô 179 về sáu bước giải quyết vấn đề.

⚠ Ý nghĩa hai chỉ số trong đề: | Chỉ số | Giá trị | Nghĩa | |---|---|---| | ⚠ CPI = 0,86 | ⚠ < 1 khá nhiều | ⚠ cứ 1 đồng chi chỉ đổi được 0,86 đồng giá trị — vượt chi ~16% | | ⚠ SPI = 0,99 | ⚠ gần bằng 1 | ⚠ tiến độ gần đúng kế hoạch | | ⚠ Suy luận | ⚠ đội đang GIỮ ĐƯỢC TIẾN ĐỘ nhưng phải TRẢ GIÁ bằng chi phí — dấu hiệu điển hình của việc làm lại và sửa lỗi | | ⚠ Giả thuyết đáng điều tra | ⚠ áp lực giữ tiến độ khiến chất lượng giảm, sinh ra làm lại, đẩy chi phí lên |

Từ khoá nhận diện:

"bên liên quan đòi đuổi người" → ⚠ điều tra nguyên nhân gốc TRƯỚC "CPI thấp, SPI gần 1" → ⚠ giữ tiến độ bằng cách chi thêm — dấu hiệu làm lại "bạn nên làm gì tiếp theo" → ⚠ thu thập thông tin trước khi hành động "sa thải, thay người" → ⚠ hầu như luôn là đáp án SAI trong đề PMP

⚠ Kelli nên điều tra những gì Câu hỏi
⚠ Bàn giao hỏng ở khâu nào ⚠ thiết kế, thực hiện, hay kiểm thử?
⚠ Yêu cầu có rõ ràng không
⚠ Đã có bước kiểm soát chất lượng chưa ⚠ nếu bên liên quan phát hiện lỗi thì QC đã không hoạt động
⚠ Người đó có được đào tạo và có đủ nguồn lực không ⚠ trách nhiệm của quản lý
⚠ Có áp lực tiến độ nào khiến phải làm tắt không ⚠ CPI và SPI gợi ý đúng hướng này
⚠ Công cụ ⚠ Ishikawa và 5 Whys
⚠ Cách xử lý với bên liên quan đang bức xúc Cách
⚠ Thừa nhận sự cố và mức độ nghiêm trọng
⚠ Cam kết ĐIỀU TRA và có kết quả trong thời hạn cụ thể
⚠ KHÔNG hứa sa thải ai ⚠ và cũng không bảo vệ mù quáng
⚠ Báo cáo kết quả điều tra kèm hành động khắc phục
⚠ Lưu ý ⚠ quyết định nhân sự thuộc quản lý chức năng, không phải bên liên quan yêu cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã biết nguyên nhân thật chưa | ⚠ nếu chưa thì mọi hành động đều là đoán | | CPI thấp mà SPI cao có phải do làm lại không | | | Có bước kiểm soát chất lượng nào bị bỏ qua không | |

Và nguyên tắc bất di bất dịch của đề thi PMP: thu thập thông tin trước, hành động sau. Đuổi người khi chưa biết nguyên nhân vừa bất công vừa không sửa được vấn đề — vì nó sẽ tái diễn với người tiếp theo.

Câu 33 People
You are the project manager for a local university. Joseph, one of your team members, approaches you before starting the project manager and informs you that he did not finish his assigned task on time due to a last-minute personal circumstance. What course of action should you take next?
  1. A Reprimand Joseph on the spot and focus on the discussion when the task is completed.
  2. B Tell Joseph not to worry about it and reallocate the responsibility to another team member.
  3. C Inform Joseph that he should update the team during the team meeting.
  4. D Excuse Joseph's behavior and ask him to provide an alternate date to complete his task.
Xem giải thích

Đáp án

C — Nói với Joseph rằng anh ấy nên CẬP NHẬT với cả đội trong buổi họp.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Joseph đã CHỦ ĐỘNG báo cáo | ⚠ hành vi cần được khuyến khích, không phải trừng phạt | | ⚠ Cả đội CẦN BIẾT vì việc trễ ảnh hưởng tới người khác | ⚠ có thể có phụ thuộc | | ⚠ Minh bạch giúp đội TỰ ĐIỀU CHỈNH | ⚠ người khác có thể hỗ trợ hoặc sắp lại việc | | ⚠ Tôn trọng Joseph — để anh ấy tự nói, không phải PM nói thay | | | ⚠ Lý do cá nhân đột xuất | ⚠ là chuyện xảy ra được, không phải hành vi thiếu trách nhiệm |

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

  • A (khiển trách Joseph ngay tại chỗ) — ⚠ SAI hoàn toàn: ⚠ phạt người CHỦ ĐỘNG báo tin xấu là cách chắc chắn nhất để ⚠ lần sau không ai báo nữa; ⚠ và khiển trách vì lý do cá nhân bất khả kháng là bất công.

  • B (bảo đừng lo và giao việc cho người khác) — ⚠ bỏ qua vấn đề: ⚠ không tìm hiểu tác động, ⚠ không cho đội biết, ⚠ và tước mất trách nhiệm của Joseph.

  • D (bỏ qua và xin anh ấy một ngày hoàn thành khác) — ⚠ gần đúng nhưng THIẾU bước quan trọng: ⚠ chỉ có PM biết, ⚠ cả đội không biết — trong khi việc trễ có thể chặn công việc của người khác.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25736 ở lô này về truyền đạt trạng thái để bên liên quan không bị bất ngờ và câu #25730 ở lô 179 về chính sách không trả đũa với người báo cáo vấn đề. ⚠ Ba câu cùng một nguyên tắc: minh bạch sớm luôn rẻ hơn che giấu.

⚠ Vì sao KHÔNG được phạt người báo tin xấu: | Hậu quả nếu phạt | Nội dung | |---|---| | ⚠ Lần sau người ta GIẤU cho tới khi không giấu được | | | ⚠ Vấn đề phát hiện muộn luôn ĐẮT hơn | | | ⚠ Cả đội học được rằng nói thật là nguy hiểm | | | ⚠ PM mất nguồn thông tin sớm quan trọng nhất | | | ⚠ Nguyên tắc | ⚠ thưởng cho sự minh bạch, xử lý vấn đề chứ không xử lý người báo |

Từ khoá nhận diện:

"thành viên chủ động báo trễ việc" → ⚠ khuyến khích, minh bạch với đội "khiển trách ngay tại chỗ" → ⚠ hầu như luôn là đáp án SAI "đừng lo, để người khác làm" → ⚠ bỏ qua vấn đề, cũng SAI "lý do cá nhân bất khả kháng" → ⚠ cần thông cảm, nhưng vẫn phải xử lý tác động

⚠ Chuỗi việc PM nên làm Bước
⚠ 1. GHI NHẬN việc Joseph chủ động báo ⚠ cảm ơn là hợp lý
⚠ 2. Hỏi khi nào hoàn thành được
⚠ 3. Bảo anh ấy cập nhật với ĐỘI trong buổi họp ⚠ bước của câu này
⚠ 4. Đánh giá tác động tới đường găng
⚠ 5. Nếu ảnh hưởng lịch: xem xét san bằng nguồn lực hoặc hỗ trợ thêm
⚠ 6. Nếu ảnh hưởng ngày kết thúc: báo cáo bên liên quan
⚠ Riêng tư ⚠ chi tiết hoàn cảnh cá nhân KHÔNG cần nêu trước đội — chỉ cần nói việc bị chậm và ngày dự kiến mới
⚠ Cân bằng giữa minh bạch và riêng tư Nguyên tắc
⚠ TÁC ĐỘNG công việc: chia sẻ với đội ⚠ "việc X chậm 2 ngày"
⚠ LÝ DO cá nhân: giữ riêng tư ⚠ không bắt Joseph kể chi tiết trước đội
⚠ Câu nói phù hợp trong họp ⚠ "tôi có việc đột xuất nên hạng mục X sẽ trễ tới thứ Năm, ai bị ảnh hưởng thì mình bàn thêm"
⚠ Vì sao để chính Joseph nói thay vì PM nói Lý do
⚠ Giữ TRÁCH NHIỆM ở người thực hiện
⚠ Xây văn hoá tự chịu trách nhiệm
⚠ Tránh cảm giác PM "tố cáo" thành viên
⚠ Đội tin nhau hơn khi thông tin đến trực tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có dám báo tin xấu sớm không | | | Việc trễ này có chặn ai không | | | Bạn có tách được tác động công việc khỏi chuyện riêng tư không | |

Và điều quan trọng nhất trong tình huống này: Joseph đã làm ĐÚNG khi chủ động báo. Phản ứng của PM lúc này sẽ quyết định lần sau cả đội có làm như vậy nữa hay không.

Câu 34 Process
Helen is monitoring her agile project at Phillips Brewery. She regularly keeps a chart on the team’s wall that tracks the project's cost over time. She is using an approach called
  1. A Internal Rate of Return
  2. B Earned Value Ratio
  3. C Agile Project Accounting
  4. D Earned Value Management
Xem giải thích

Đáp án

D — Earned Value Management (quản lý giá trị thu được — EVM).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Bảng theo dõi CHI PHÍ dự án theo THỜI GIAN | ⚠ đường cong chi phí — đặc trưng của EVM | | ⚠ Cập nhật ĐỀU ĐẶN | | | ⚠ Dán trên TƯỜNG cho cả đội thấy | ⚠ information radiator — thực hành phổ biến trong agile | | ⚠ Kết luận | ⚠ EVM dùng được cho cả dự án dự đoán lẫn dự án thích ứng |

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

  • B (Earned Value Ratio) và C (Agile Project Accounting) — ⚠ KHÔNG phải thuật ngữ chuẩn; ⚠ đây là các phương án bịa.

  • A (Internal Rate of Return — IRR) — ⚠ là chỉ số CHỌN DỰ ÁN dựa trên dòng tiền, ⚠ dùng TRƯỚC khi dự án bắt đầu, ⚠ không phải công cụ theo dõi trong lúc thực hiện.

Ghi nhớ

⚠ Đối chiếu: ⚠ các câu EVM ở lô 179 — ⚠ #25685 (CPI), #25708 (ETC), #25718 (CPI sau khuyết tật). ⚠ Câu này hỏi TÊN của phương pháp thay vì hỏi phép tính.

⚠ Ba đường cong cơ bản của EVM: | Đường | Nghĩa | |---|---| | ⚠ PV — Planned Value | ⚠ giá trị công việc ĐÁNG LẼ phải xong tính tới hôm nay | | ⚠ EV — Earned Value | ⚠ giá trị công việc THỰC SỰ đã xong | | ⚠ AC — Actual Cost | ⚠ số tiền THỰC SỰ đã chi | | ⚠ Nhìn ba đường trên một biểu đồ | ⚠ thấy ngay dự án đang vượt chi hay chậm tiến độ |

⚠ Bộ chỉ số EVM: | Chỉ số | Công thức | Nghĩa | |---|---|---| | ⚠ CV | ⚠ EV − AC | ⚠ âm là vượt chi | | ⚠ SV | ⚠ EV − PV | ⚠ âm là chậm | | ⚠ CPI | ⚠ EV / AC | ⚠ dưới 1 là vượt chi | | ⚠ SPI | ⚠ EV / PV | ⚠ dưới 1 là chậm | | ⚠ EAC | ⚠ BAC / CPI | ⚠ dự báo tổng chi phí | | ⚠ ETC | ⚠ EAC − AC | ⚠ còn phải chi bao nhiêu | | ⚠ VAC | ⚠ BAC − EAC | ⚠ âm là sẽ vượt ngân sách | | ⚠ TCPI | ⚠ (BAC − EV) / (BAC − AC) | ⚠ hiệu suất cần đạt để về đúng ngân sách |

Từ khoá nhận diện:

"theo dõi chi phí theo thời gian" → ⚠ EVM "tỷ suất hoàn vốn nội bộ" → ⚠ IRR, dùng để CHỌN dự án "giá trị hiện tại ròng" → ⚠ NPV, cũng để chọn dự án "biểu đồ dán tường cho cả đội xem" → ⚠ information radiator

⚠ EVM trong dự án agile Nội dung
⚠ HOÀN TOÀN dùng được ⚠ EVM không phụ thuộc vào loại vòng đời
⚠ EV tính theo hạng mục backlog ĐÃ DONE
⚠ Kết hợp tốt với velocity và burndown
⚠ Giúp trả lời câu hỏi của bên liên quan về ngân sách
⚠ Lưu ý ⚠ cần định nghĩa DONE rõ ràng, nếu không thì EV không đáng tin
⚠ Information radiator — thực hành của Helen Nội dung
⚠ Thông tin dán ở nơi ai cũng thấy
⚠ Cập nhật thường xuyên, đơn giản, trực quan
⚠ Không cần ai hỏi mới biết tình hình ⚠ minh bạch chủ động
⚠ Ví dụ khác: burndown chart, task board, biểu đồ luồng tích luỹ
⚠ Đối lập với ⚠ "information refrigerator" — dữ liệu nằm trong báo cáo mà không ai đọc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Định nghĩa DONE của bạn có rõ không | ⚠ EV sai thì mọi chỉ số sai theo | | Đội có nhìn thấy số liệu không | ⚠ hay chỉ PM và bên liên quan biết | | Bạn có theo dõi cả xu hướng chứ không chỉ điểm hiện tại không | |

Và giá trị lớn nhất của việc dán biểu đồ lên tường: cả đội cùng thấy một sự thật. Đó là cách rẻ nhất để mọi người tự điều chỉnh mà không cần ai nhắc.

Câu 35 Process
Dori is the project manager for a minor publishing house specializing in academic texts. A printing run she oversees goes very wrong when the books' bindings are attached upside down. Before the publishing house throws away the books', Dori keeps one as well as the quality control form used to justify the printing. She periodically uses the book and the form as props for presentations about the importance of quality assurance. This is an example of which element of project governance?
  1. A Identifying, escalating, and resolving risks
  2. B Stage-gate or phase reviews
  3. C Defining roles and responsibilities
  4. D Capturing lessons learned
Xem giải thích

Đáp án

D — Capturing lessons learned (thu thập bài học kinh nghiệm).

Vì sao đúng

⚠ Vì sao hành động của Dori là thu thập bài học: | Hành động | Ý nghĩa | |---|---| | ⚠ GIỮ LẠI một cuốn sách bị lỗi | ⚠ bằng chứng vật lý của sự cố | | ⚠ GIỮ LẠI biểu mẫu kiểm soát chất lượng đã dùng | ⚠ bằng chứng về chỗ hổng trong quy trình | | ⚠ Dùng chúng ĐỊNH KỲ trong các buổi trình bày | ⚠ chia sẻ tri thức cho người khác | | ⚠ Mục đích: nhấn mạnh tầm quan trọng của đảm bảo chất lượng | | | ⚠ Kết luận | ⚠ biến một sự cố tốn kém thành tri thức tổ chức dùng lại được |

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

  • A (nhận diện, leo thang và xử lý rủi ro) — ⚠ là cơ chế xử lý vấn đề ĐANG hoặc SẮP xảy ra; ⚠ ở đây sự cố đã kết thúc.

  • B (rà soát cổng giai đoạn) — ⚠ là điểm rà soát ĐỊNH KỲ ở cuối giai đoạn để quyết đi tiếp hay dừng.

  • C (xác định vai trò và trách nhiệm) — ⚠ là việc phân vai, ⚠ không liên quan tới việc lưu giữ tri thức.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25761 CÙNG LÔ. ⚠ Hai câu ⚠ dùng CHÍNH XÁC cùng bốn phương án (bốn yếu tố quản trị dự án) ⚠ và ⚠ có CÙNG khoá đáp án "capturing lessons learned", ⚠ chỉ khác bối cảnh: ⚠ một câu là nhà xuất bản đóng bìa ngược, ⚠ một câu là trang web chính phủ sập vì quá tải. ⚠ Hàm băm MD5 không bắt được vì lời văn hoàn toàn khác. ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ Lưu ý thứ tự chữ cái đã bị xáo: ở câu này đáp án là D, ở #25761 là C. ⚠ Ngoài ra câu #25730 ở lô 179 cũng dùng đúng bốn phương án này nhưng khoá là ⚠ "nhận diện, leo thang và xử lý rủi ro" — ⚠ ba câu tạo thành một bộ, nên học chung để phân biệt.

⚠ Bốn yếu tố quản trị dự án — bảng phân biệt: | Yếu tố | Nhận ra bằng | |---|---| | ⚠ Stage-gate / phase reviews | ⚠ rà soát ĐỊNH KỲ ở cuối giai đoạn, quyết đi tiếp hay dừng | | ⚠ Capturing lessons learned | ⚠ GHI LẠI và CHIA SẺ điều đã học được — hai câu này | | ⚠ Identifying, escalating, resolving risks | ⚠ cơ chế LIÊN TỤC phát hiện và xử lý vấn đề — câu #25730 | | ⚠ Defining roles and responsibilities | ⚠ phân vai, ai quyết gì |

Từ khoá nhận diện:

"ghi lại điều đã học, chia sẻ cho người sau" → ⚠ lessons learned "rà soát cuối giai đoạn" → ⚠ stage-gate "cơ chế báo cáo và xử lý vấn đề đang diễn ra" → ⚠ risk governance "ai làm gì, ai quyết gì" → ⚠ roles and responsibilities

⚠ Lessons learned — vòng đời đầy đủ Bước
⚠ THU THẬP trong suốt dự án, không chỉ ở cuối ⚠ lessons learned register
⚠ PHÂN TÍCH: nguyên nhân gốc là gì
⚠ LƯU TRỮ vào kho tri thức tổ chức ⚠ trở thành OPA
⚠ CHIA SẺ cho các dự án khác ⚠ bước Dori đang làm
⚠ ÁP DỤNG ở dự án sau ⚠ bước quan trọng nhất mà hay bị bỏ nhất
⚠ Ghi mà không ai đọc ⚠ là dạng lãng phí phổ biến nhất của quản lý tri thức
⚠ Vì sao cách của Dori hiệu quả Lý do
⚠ Có VẬT CHỨNG cụ thể, không phải văn bản khô khan
⚠ Kể chuyện dễ nhớ hơn đọc báo cáo ⚠ storytelling — công cụ chuyển giao tri thức ẩn
⚠ Lặp lại ĐỊNH KỲ nên tri thức không bị quên
⚠ Cả biểu mẫu kiểm soát cũng được giữ ⚠ cho thấy quy trình đã thất bại ở đâu, không chỉ cho thấy hậu quả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có kho bài học kinh nghiệm không | | | Có ai ĐỌC nó trước khi bắt đầu dự án mới không | | | Bài học được ghi thành văn bản hay được kể lại | ⚠ cả hai cách đều cần |

Và điều làm nên giá trị của cách làm này: một cuốn sách hỏng dạy được nhiều hơn mười trang báo cáo. Dori đã biến chi phí lỗi thành tài sản đào tạo.

Câu 36 Process
Nikki is the project manager for a team of computer game developers. They have recently released a beta version of a game that has seen moderate success in a niche community of gamers. Nikki engages in a contract with a marketing company that specializes in surveying consumers and creating focus groups. She asks them to create a representative sample from the gaming community at large, survey them, and report the findings to Nikki and her team monthly, corresponding with planned updates to the game. Which quality management practice does this entail?
  1. A Mutually beneficial partnerships
  2. B Continual improvement
  3. C Management responsibility
  4. D Customer satisfaction
Xem giải thích

Đáp án

D — Customer satisfaction (sự hài lòng của khách hàng).

Vì sao đúng

⚠ Những gì Nikki làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Thuê công ty chuyên KHẢO SÁT NGƯỜI TIÊU DÙNG | ⚠ thu thập ý kiến khách hàng một cách chuyên nghiệp | | ⚠ Lấy MẪU ĐẠI DIỆN của cộng đồng game nói chung | ⚠ không chỉ nghe nhóm nhỏ hiện tại | | ⚠ Báo cáo HÀNG THÁNG | ⚠ đều đặn, có hệ thống | | ⚠ Trùng khớp với các bản cập nhật game đã lên kế hoạch | ⚠ phản hồi được đưa TRỰC TIẾP vào sản phẩm | | ⚠ Kết luận | ⚠ hiểu, đo lường và quản lý kỳ vọng khách hàng — đúng định nghĩa nguyên tắc customer satisfaction |

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

  • B (Continual improvement — cải tiến liên tục) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ việc cập nhật game định kỳ ⚠ CÓ tính cải tiến liên tục, ⚠ nhưng ⚠ trọng tâm của hành động là THU THẬP Ý KIẾN KHÁCH HÀNG — ⚠ cải tiến liên tục nói về quy trình NỘI BỘ (PDCA), còn ở đây nguồn dữ liệu đến từ BÊN NGOÀI.

  • A (Mutually beneficial partnerships) — ⚠ nói về quan hệ với NHÀ CUNG CẤP; ⚠ công ty khảo sát chỉ là công cụ, không phải trọng tâm.

  • C (Management responsibility) — ⚠ nói về việc lãnh đạo cung cấp đủ nguồn lực cho nhân viên.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25744 ở lô này về management responsibility. ⚠ Hai câu dùng chung bốn phương án về nguyên tắc quản lý chất lượng — nên học chung để phân biệt.

⚠ Năm nguyên tắc quản lý chất lượng hiện đại: | Nguyên tắc | Nhận ra bằng | |---|---| | ⚠ Customer satisfaction | ⚠ hiểu, đo lường và quản lý KỲ VỌNG KHÁCH HÀNG — CÂU NÀY | | ⚠ Prevention over inspection | ⚠ phòng ngừa hơn kiểm tra | | ⚠ Continual improvement | ⚠ PDCA, cải tiến QUY TRÌNH NỘI BỘ | | ⚠ Management responsibility | ⚠ lãnh đạo cấp đủ nguồn lực — câu #25744 | | ⚠ Mutually beneficial partnerships | ⚠ quan hệ lâu dài với nhà cung cấp |

Từ khoá nhận diện:

"khảo sát khách hàng, nhóm tập trung, đo mức hài lòng" → ⚠ customer satisfaction "cải tiến quy trình nội bộ, PDCA" → ⚠ continual improvement "cung cấp nguồn lực cho nhân viên" → ⚠ management responsibility "quan hệ với nhà cung cấp" → ⚠ mutually beneficial partnerships

⚠ Vì sao lấy MẪU ĐẠI DIỆN lại quan trọng Lý do
⚠ Game mới thành công ở một cộng đồng NGÁCH
⚠ Ý kiến nhóm ngách có thể KHÔNG đại diện cho thị trường rộng
⚠ Muốn mở rộng thì phải hiểu người CHƯA chơi
⚠ Tránh thiên kiến người sống sót ⚠ chỉ nghe người đang chơi thì không biết vì sao người khác bỏ đi
⚠ Nikki làm đúng ⚠ yêu cầu mẫu đại diện của "cộng đồng game NÓI CHUNG"
⚠ Vì sao nhịp HÀNG THÁNG khớp bản cập nhật lại quan trọng Lý do
⚠ Phản hồi đến ĐÚNG LÚC có thể hành động
⚠ Dữ liệu cũ vài tháng thì không còn dùng được
⚠ Tạo VÒNG LẶP phản hồi khép kín ⚠ khảo sát → cập nhật → khảo sát lại
⚠ Đây cũng là tinh thần ⚠ của cách tiếp cận lặp và tăng dần
⚠ Ba khái niệm về chất lượng cần phân biệt Khái niệm
⚠ Conformance to requirements ⚠ đáp ứng đúng đặc tả — định nghĩa hẹp
⚠ Fitness for use ⚠ dùng được cho mục đích thực tế của khách
⚠ Customer satisfaction ⚠ khách hàng THẤY HÀI LÒNG — rộng nhất, gồm cả kỳ vọng ngầm
⚠ Bài học ⚠ sản phẩm đúng đặc tả vẫn có thể khiến khách không hài lòng nếu kỳ vọng của họ khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ĐO mức hài lòng khách hàng không | ⚠ hay chỉ đoán từ số lượt khiếu nại | | Mẫu khảo sát có đại diện không | | | Phản hồi có dẫn tới thay đổi sản phẩm không | ⚠ khảo sát mà không hành động là lãng phí |

Và điều làm nên chất lượng thật: đáp ứng đặc tả chỉ là điều kiện cần. Khách hàng hài lòng hay không còn phụ thuộc vào kỳ vọng mà không ai viết ra — và cách duy nhất để biết là đi hỏi.

Câu 37 Business Environment
You are the project manager of the Glass Project for your organization. This project utilizes a hybrid approach, taking some of the predictive planning of traditional projects and merging it with agile iterations. Today, your project sponsor has asked you to send her the Benefits Management Plan. Which of the following will not be included in the document?
  1. A Justification for a project
  2. B Metrics for measuring success
  3. C Intangible benefits that a project should achieve
  4. D A plan for how benefits will be sustained
Xem giải thích

Đáp án

A — Justification for a project (lý do biện minh cho dự án). ⚠ Mục này KHÔNG nằm trong Benefits Management Plan.

Vì sao đúng

⚠ Lý do biện minh thuộc về tài liệu nào: | Tài liệu | Nội dung | |---|---| | ⚠ BUSINESS CASE | ⚠ chứa LÝ DO BIỆN MINH: vì sao dự án đáng làm, phân tích chi phí – lợi ích, các phương án đã cân nhắc | | ⚠ BENEFITS MANAGEMENT PLAN | ⚠ chứa cách ĐO, THEO DÕI và DUY TRÌ lợi ích SAU khi đã quyết làm | | ⚠ Thứ tự | ⚠ business case trả lời "có nên làm không"; benefits management plan trả lời "làm rồi thì đo lợi ích thế nào" |

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

⚠ Cả ba phương án còn lại ĐỀU là nội dung của Benefits Management Plan:

  • B (thước đo để đánh giá thành công) — ⚠ CÓ: ⚠ metrics là phần cốt lõi.

  • C (lợi ích VÔ HÌNH dự án cần đạt) — ⚠ CÓ: ⚠ kế hoạch ghi cả lợi ích hữu hình lẫn vô hình.

  • D (kế hoạch DUY TRÌ lợi ích) — ⚠ CÓ: ⚠ đây là điểm phân biệt quan trọng nhất — ⚠ lợi ích phải được duy trì SAU khi dự án kết thúc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25638 ở lô 178 — ⚠ nhà tài trợ chịu trách nhiệm về business case, ⚠ và câu #25738 ở lô này về ⚠ rà soát điều lệ khi lo sản phẩm không mang lại lợi ích đã hứa. ⚠ Ba câu cùng chủ đề: dự án tồn tại vì LỢI ÍCH, không vì bản thân sản phẩm.

⚠ Nội dung của Benefits Management Plan: | Mục | Nội dung | |---|---| | ⚠ Lợi ích MỤC TIÊU | ⚠ hữu hình và vô hình | | ⚠ Sự phù hợp CHIẾN LƯỢC | ⚠ lợi ích này phục vụ mục tiêu nào của tổ chức | | ⚠ KHUNG THỜI GIAN | ⚠ lợi ích xuất hiện khi nào: ngắn hạn, dài hạn, liên tục | | ⚠ CHỦ SỞ HỮU lợi ích | ⚠ ai chịu trách nhiệm theo dõi và duy trì | | ⚠ THƯỚC ĐO | ⚠ đo bằng gì, trực tiếp hay gián tiếp | | ⚠ GIẢ ĐỊNH | | | ⚠ RỦI RO đối với việc thu được lợi ích | | | ⚠ Ai sở hữu tài liệu | ⚠ NHÀ TÀI TRỢ, giống như business case |

Từ khoá nhận diện:

"vì sao dự án đáng làm" → ⚠ business case "đo và duy trì lợi ích thế nào" → ⚠ benefits management plan "cho phép dự án tồn tại" → ⚠ project charter "làm dự án thế nào" → ⚠ project management plan

⚠ Vì sao tách hai tài liệu này Lý do
⚠ Business case viết TRƯỚC khi quyết định ⚠ để quyết có làm hay không
⚠ Benefits plan dùng TRONG và SAU dự án ⚠ để kiểm chứng lợi ích có thật sự xảy ra không
⚠ Nhiều lợi ích chỉ hiện ra SAU khi dự án đóng ⚠ ví dụ tiết kiệm chi phí vận hành hằng năm
⚠ Điểm hay bị bỏ qua nhất ⚠ không ai quay lại đo xem lợi ích hứa hẹn có thành hiện thực không
⚠ Bối cảnh dự án LAI có ý nghĩa gì Ý nghĩa
⚠ Kết hợp lập kế hoạch dự đoán với vòng lặp linh hoạt
⚠ Benefits management plan vẫn CẦN, không phụ thuộc loại vòng đời
⚠ Trong dự án lai, lợi ích có thể đo theo từng đợt phát hành
⚠ Lợi thế ⚠ đo lợi ích sớm hơn thay vì đợi tới cuối dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có benefits management plan không | | | Ai chịu trách nhiệm theo dõi lợi ích sau khi dự án đóng | | | Lợi ích có thước đo cụ thể không | ⚠ "cải thiện trải nghiệm" không phải thước đo |

Và ranh giới cần thuộc: business case biện minh, benefits plan đo lường. Rất nhiều tổ chức có vế đầu mà không có vế sau — nên không bao giờ biết dự án có mang lại thứ đã hứa hay không.

Câu 38 Process
Spyke is the project manager for the Beach Project, which is nine weeks into implementation, six weeks into a twelve-week timeline, and one week behind schedule. Recently several team members complained to Spyke that it is incredibly challenging to find project documentation. They know there is a project drive on the network, but the information is not sorted logically or named with a structure that is easy to access. What should Spyke do?
  1. A Save all project documents to the cloud.
  2. B Assess how documentation is stored and adjust accordingly.
  3. C Print all documentation in a central project binder.
  4. D Assign one team member to manage project documentation.
Xem giải thích

Đáp án

B — ĐÁNH GIÁ cách tài liệu đang được lưu trữ rồi ĐIỀU CHỈNH cho phù hợp.

Vì sao đúng

⚠ Vì sao đây là hành động đúng: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề là CẤU TRÚC và CÁCH ĐẶT TÊN, không phải nơi lưu | ⚠ đề nói rõ: có ổ mạng nhưng thông tin không sắp xếp logic | | ⚠ Phải HIỂU tình trạng hiện tại trước khi thay đổi | | | ⚠ Điều chỉnh dựa trên nhu cầu thật của đội | ⚠ họ là người phải tìm tài liệu hằng ngày | | ⚠ Đây là vấn đề QUẢN LÝ THÔNG TIN, thuộc trách nhiệm PM | | | ⚠ Bối cảnh | ⚠ dự án đã chậm một tuần — mất thời gian tìm tài liệu càng làm tình hình xấu thêm |

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

  • A (lưu toàn bộ tài liệu lên đám mây) — ⚠ ĐỔI NƠI LƯU nhưng KHÔNG sửa vấn đề gốc: ⚠ tài liệu lộn xộn trên ổ mạng chuyển lên đám mây vẫn lộn xộn.

  • C (in toàn bộ tài liệu vào một tập hồ sơ trung tâm) — ⚠ đi lùi: ⚠ tài liệu giấy khó tìm kiếm hơn, ⚠ khó cập nhật, ⚠ và không dùng được với đội phân tán.

  • D (giao một thành viên quản lý tài liệu) — ⚠ tạo NÚT THẮT CỔ CHAI: ⚠ mọi người phải hỏi một người; ⚠ và vẫn không giải quyết vấn đề cấu trúc.

Ghi nhớ

⚠ Quản lý thông tin dự án — nguyên tắc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Cấu trúc thư mục phản ánh CÁCH NGƯỜI TA TÌM | ⚠ không phải cách người lưu nghĩ | | ⚠ Quy ước ĐẶT TÊN nhất quán | ⚠ ngày, loại tài liệu, phiên bản | | ⚠ QUẢN LÝ PHIÊN BẢN rõ ràng | ⚠ tránh tình trạng "bản cuối cùng thật sự v3" | | ⚠ Phân quyền truy cập phù hợp | | | ⚠ Có nơi ai cũng biết để tra | ⚠ information radiator | | ⚠ Thuộc quy trình | ⚠ Manage Project Knowledge — quản lý thông tin là một nửa của quy trình này |

Từ khoá nhận diện:

"khó tìm tài liệu" → ⚠ vấn đề CẤU TRÚC, đánh giá rồi sửa "chuyển sang nơi lưu khác" → ⚠ không sửa vấn đề gốc "giao một người quản lý" → ⚠ tạo nút thắt "in ra giấy" → ⚠ đi lùi về công nghệ

⚠ Spyke nên đánh giá những gì Câu hỏi
⚠ Đội tìm tài liệu theo cách nào ⚠ theo giai đoạn? theo loại? theo ngày?
⚠ Tài liệu nào được tra nhiều nhất
⚠ Có quy ước đặt tên nào chưa
⚠ Có bao nhiêu phiên bản trùng lặp
⚠ Ai có quyền tạo thư mục mới ⚠ thiếu quy tắc là nguyên nhân của sự hỗn loạn
⚠ Cấu trúc thư mục dự án gợi ý Cấu trúc
⚠ 01 — Khởi tạo ⚠ điều lệ, business case, sổ bên liên quan
⚠ 02 — Lập kế hoạch ⚠ kế hoạch quản lý dự án và các kế hoạch con
⚠ 03 — Thực hiện ⚠ biên bản họp, bàn giao
⚠ 04 — Giám sát và kiểm soát ⚠ báo cáo, sổ rủi ro, sổ vấn đề, sổ thay đổi
⚠ 05 — Kết thúc ⚠ báo cáo cuối, bài học kinh nghiệm
⚠ Nguyên tắc quan trọng hơn cấu trúc cụ thể ⚠ cả đội phải HIỂU và ĐỒNG Ý với nó
⚠ Vì sao đây không phải chuyện nhỏ Lý do
⚠ Thời gian tìm tài liệu là thời gian MẤT TRẮNG
⚠ Dùng nhầm phiên bản cũ gây LỖI thật
⚠ Dự án đã chậm một tuần — không còn dư thời gian để lãng phí
⚠ Là dấu hiệu quản lý thông tin yếu nói chung
⚠ Chi phí sửa ⚠ vài giờ sắp xếp lại, hoàn vốn trong vài ngày

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới vào đội mất bao lâu để tìm được tài liệu cần | ⚠ phép thử tốt nhất | | Có quy ước đặt tên và phiên bản không | | | Đội có được hỏi ý kiến về cấu trúc không | ⚠ áp cấu trúc mà đội không dùng thì cũng vô ích |

Và nguyên tắc gọn nhất: sửa cấu trúc trước, đổi công cụ sau. Chuyển một mớ lộn xộn sang nền tảng mới chỉ tạo ra một mớ lộn xộn mới ở nơi khác.

Câu 39 Process
Joaquin recently oversaw the launch of a new website for a government service, and it quickly stopped working due to too many users accessing the website at once. After a week of emergency sessions, the website stabilizes and is usable. Joaquin calls a retrospective meeting to ask his team what they could have done differently and what they have learned from their experience. The results are recorded and posted in a public wiki. This is an example of which element of project governance?
  1. A Stage-gate or phase reviews
  2. B Defining roles and responsibilities
  3. C Capturing lessons learned
  4. D Identifying, escalating, and resolving risks
Xem giải thích

Đáp án

C — Capturing lessons learned (thu thập bài học kinh nghiệm).

Vì sao đúng

⚠ Những gì Joaquin làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Gọi họp RETROSPECTIVE sau khi sự cố đã ổn định | ⚠ nhìn lại có hệ thống | | ⚠ Hỏi đội "chúng ta lẽ ra có thể làm khác đi thế nào" | ⚠ rút ra bài học | | ⚠ Hỏi "chúng ta đã học được gì" | | | ⚠ GHI LẠI kết quả | | | ⚠ Đăng lên WIKI CÔNG KHAI | ⚠ chia sẻ cho toàn tổ chức — biến tri thức cá nhân thành tài sản tổ chức | | ⚠ Kết luận | ⚠ đủ cả bốn bước: nhìn lại, rút ra, ghi lại, chia sẻ |

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

  • D (nhận diện, leo thang và xử lý rủi ro) — ⚠ là cơ chế xử lý vấn đề ĐANG diễn ra; ⚠ ở đây sự cố đã được xử lý xong, ⚠ Joaquin đang làm bước SAU.

  • A (rà soát cổng giai đoạn) — ⚠ là rà soát ĐỊNH KỲ theo lịch, ⚠ không phải phản ứng với một sự cố cụ thể.

  • B (xác định vai trò và trách nhiệm) — ⚠ là việc phân vai, ⚠ không liên quan.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25757 CÙNG LÔ ⚠ (Dori giữ cuốn sách đóng bìa ngược làm giáo cụ). ⚠ Hai câu ⚠ dùng CHÍNH XÁC cùng bốn phương án và có CÙNG khoá đáp án, ⚠ chỉ khác bối cảnh. ⚠ MD5 không bắt được vì lời văn hoàn toàn khác nhau. ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ Lưu ý chữ cái đã bị xáo: ở #25757 đáp án là D, ở câu này là C. ⚠ Cùng bộ này còn có câu #25730 ở lô 179 với khoá khác — ⚠ "nhận diện, leo thang và xử lý rủi ro". ⚠ Ba câu tạo thành một bộ so sánh rất tốt.

⚠ Phân biệt ba câu cùng bộ phương án: | Câu | Bối cảnh | Khoá | |---|---|---| | ⚠ #25730 (lô 179) | ⚠ chính sách không trả đũa, kênh ẩn danh, leo thang khi có cơ sở | ⚠ nhận diện – leo thang – xử lý rủi ro | | ⚠ #25757 (lô này) | ⚠ giữ vật chứng làm giáo cụ cho các buổi trình bày | ⚠ thu thập bài học | | ⚠ #25761 (câu này) | ⚠ retrospective sau sự cố, đăng wiki công khai | ⚠ thu thập bài học | | ⚠ Cách phân biệt | ⚠ vấn đề ĐANG diễn ra → quản trị rủi ro; vấn đề ĐÃ xong và đang rút kinh nghiệm → bài học |

⚠ Retrospective — nhìn lại: | Đặc điểm | Nội dung | |---|---| | ⚠ Bàn về CÁCH LÀM VIỆC, không bàn về sản phẩm | | | ⚠ Ba câu hỏi kinh điển | ⚠ cái gì đã tốt, cái gì chưa tốt, lần sau làm gì khác đi | | ⚠ Không đổ lỗi — tập trung vào hệ thống | ⚠ blameless postmortem | | ⚠ Kết quả phải dẫn tới HÀNH ĐỘNG cụ thể | | | ⚠ Joaquin làm thêm một bước quan trọng | ⚠ ĐĂNG CÔNG KHAI để cả tổ chức học được, không giữ trong nội bộ đội |

Từ khoá nhận diện:

"nhìn lại, rút kinh nghiệm, ghi lại, chia sẻ" → ⚠ lessons learned "cơ chế báo cáo và xử lý vấn đề đang diễn ra" → ⚠ quản trị rủi ro "rà soát cuối giai đoạn để quyết đi tiếp" → ⚠ stage-gate "wiki công khai, không đổ lỗi" → ⚠ văn hoá học hỏi lành mạnh

⚠ Vì sao đăng CÔNG KHAI lại quan trọng Lý do
⚠ Bài học nằm trong một đội thì chỉ đội đó học được
⚠ Sự cố quá tải trang web có thể tái diễn ở dự án khác
⚠ Minh bạch xây dựng văn hoá không đổ lỗi
⚠ Người tìm kiếm sau này tự tra được
⚠ Điều kiện ⚠ nội dung phải nói về HỆ THỐNG, không nêu tên người để trách

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sau mỗi sự cố lớn bạn có làm retrospective không | | | Kết quả có được lưu ở nơi người khác tìm được không | | | Có hành động cụ thể nào được thực hiện sau đó không | ⚠ ghi mà không làm là ghi cho vui |

Và điều Joaquin làm đúng nhất: biến một sự cố công khai thành tri thức công khai. Sự cố trang web đã xảy ra rồi — thứ duy nhất còn cứu vãn được là những gì tổ chức học được từ nó.

Câu 40 People
William is the project manager of the NA Project. This project will replace all the laptops in the organization with a newer model laptop. Some of the stakeholders are concerned about the replaced hardware, the personalization of their existing hardware, and the software. William needs to capture all these concerns at the start of the project. What should he do next?
  1. A William should document stakeholders' needs in the stakeholder engagement plan.
  2. B William should use the MoSCoW prioritization method for the stakeholder's needs and concerns.
  3. C Nothing. The project charter should list the needs and acceptance criteria that stakeholders want for the project.
  4. D William should document the needs and concerns in the project scope management plan.
Xem giải thích

Đáp án

B — William nên dùng phương pháp XẾP ƯU TIÊN MoSCoW cho các nhu cầu và mối quan tâm của bên liên quan.

Vì sao đúng

⚠ Vì sao MoSCoW phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Có NHIỀU mối quan tâm khác nhau | ⚠ phần cứng cũ, cá nhân hoá, phần mềm | | ⚠ Không thể đáp ứng TẤT CẢ như nhau | | | ⚠ Cần phân loại theo MỨC ĐỘ THIẾT YẾU | | | ⚠ Ở ĐẦU dự án — đúng thời điểm để xếp ưu tiên | | | ⚠ MoSCoW cho ra | ⚠ danh sách rõ ràng cái gì bắt buộc, cái gì nên có, cái gì để sau |

⚠ MoSCoW là gì: | Chữ | Nghĩa | Ý nghĩa | |---|---|---| | ⚠ M — Must have | ⚠ BẮT BUỘC phải có | ⚠ thiếu là dự án thất bại | | ⚠ S — Should have | ⚠ NÊN có | ⚠ quan trọng nhưng không sống còn | | ⚠ C — Could have | ⚠ CÓ THÌ TỐT | ⚠ làm nếu còn thời gian và nguồn lực | | ⚠ W — Won't have (this time) | ⚠ LẦN NÀY KHÔNG làm | ⚠ đã cân nhắc và quyết định loại — ghi lại để không bị hỏi lại | | ⚠ Chữ "o" | ⚠ chỉ để cho dễ đọc, không mang nghĩa |

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

  • A (ghi nhu cầu vào kế hoạch tham gia bên liên quan) — ⚠ ghi lại là ĐÚNG nhưng CHƯA ĐỦ: ⚠ ghi mà không xếp ưu tiên thì đội không biết làm gì trước; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • D (ghi vào kế hoạch quản lý phạm vi) — ⚠ SAI tài liệu: ⚠ kế hoạch quản lý phạm vi nói về ⚠ CÁCH quản lý phạm vi, ⚠ không chứa danh sách nhu cầu cụ thể.

  • C (không cần làm gì, điều lệ đã liệt kê rồi) — ⚠ SAI: ⚠ điều lệ chỉ có yêu cầu ở MỨC CAO, ⚠ không đủ chi tiết cho các mối quan tâm cụ thể này.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25704 ở lô 179 về kế hoạch tham gia bên liên quan và câu #25699 về sổ đăng ký bên liên quan. ⚠ Ba câu vẽ đủ chuỗi: ghi nhận (register) → xếp ưu tiên (MoSCoW) → lập chiến lược tham gia (engagement plan).

⚠ Các phương pháp xếp ưu tiên yêu cầu: | Phương pháp | Cách làm | |---|---| | ⚠ MoSCoW | ⚠ bốn nhóm: bắt buộc, nên, có thì tốt, lần này không — CÂU NÀY | | ⚠ Kano model | ⚠ cơ bản, hiệu năng, hấp dẫn — theo mức hài lòng của khách | | ⚠ Weighted ranking / scoring | ⚠ chấm điểm nhiều tiêu chí có trọng số | | ⚠ 100-point method | ⚠ mỗi người có 100 điểm để phân bổ | | ⚠ Paired comparison | ⚠ so từng cặp một | | ⚠ Multivoting | ⚠ bỏ phiếu nhiều vòng |

Từ khoá nhận diện:

"bắt buộc, nên có, có thì tốt, lần này không" → ⚠ MoSCoW "tính năng cơ bản, hiệu năng, hấp dẫn" → ⚠ Kano "mỗi người 100 điểm" → ⚠ 100-point method "nhiều nhu cầu, phải chọn cái nào trước" → ⚠ cần một phương pháp xếp ưu tiên

⚠ Áp MoSCoW vào tình huống của William Ví dụ
⚠ MUST: dữ liệu công việc được chuyển sang máy mới nguyên vẹn
⚠ MUST: phần mềm bắt buộc cho công việc được cài đặt
⚠ SHOULD: xử lý an toàn phần cứng cũ, xoá dữ liệu đúng quy định
⚠ COULD: khôi phục các thiết lập cá nhân hoá
⚠ WON'T: cài lại phần mềm cá nhân không phục vụ công việc
⚠ Lợi ích ⚠ bên liên quan thấy rõ mối quan tâm của họ được xử lý ở mức nào, và VÌ SAO
⚠ Vì sao nhóm "WON'T" lại quan trọng nhất Lý do
⚠ Nói rõ cái gì KHÔNG làm, tránh hiểu lầm
⚠ Chống scope creep ⚠ đã có văn bản thì khó bị "nhớ nhầm"
⚠ Cho thấy đã CÂN NHẮC chứ không phải bỏ quên
⚠ Chữ "this time" để ngỏ khả năng làm ở dự án sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhóm MUST có quá nhiều không | ⚠ nếu mọi thứ đều bắt buộc thì không có ưu tiên nào cả | | Bên liên quan có được tham gia xếp ưu tiên không | | | Nhóm WON'T đã được ghi rõ và thông báo chưa | |

Và giá trị lớn nhất của MoSCoW: nó buộc mọi người thừa nhận rằng không phải thứ gì cũng bắt buộc. Cuộc trò chuyện khó nhất trong dự án là cuộc trò chuyện về những gì sẽ KHÔNG được làm.