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

Tìm thấy 720 câu.

Câu 201 Process
You are the Highway Automation Project project manager and are facilitating the risk identification process with your project team and other key stakeholders. You have encouraged the participants to identify as many project risks as possible. All of the following are acceptable risk identification techniques, except which one?
  1. A SWOT analysis
  2. B Root-cause analysis
  3. C Prompt lists
  4. D Qualitative analysis
Xem giải thích

Đáp án

D — PHÂN TÍCH ĐỊNH TÍNH (qualitative analysis) — đây KHÔNG phải kỹ thuật nhận diện rủi ro.

Vì sao đúng

⚠ Vì sao phân tích định tính không thuộc bước nhận diện: | Lý do | Nội dung | |---|---| | ⚠ Nó là một QUY TRÌNH RIÊNG đứng SAU nhận diện | ⚠ Thực hiện phân tích định tính rủi ro | | ⚠ Nó XẾP HẠNG các rủi ro ĐÃ ĐƯỢC nhận diện | ⚠ theo xác suất và mức tác động | | ⚠ Không có rủi ro trong sổ đăng ký thì không phân tích được gì | ⚠ phải có đầu vào trước | | ⚠ Ba phương án còn lại | ⚠ đều SINH RA rủi ro mới cho danh sách |

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

  • B (phân tích nguyên nhân gốc) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như công cụ phân tích chứ không phải công cụ tìm kiếm: ⚠ nhưng nó ⚠ đi từ VẤN ĐỀ ngược về NGUYÊN NHÂN, ⚠ và mỗi nguyên nhân tìm được lại là một nguồn rủi ro mới ⚠ — đúng là kỹ thuật nhận diện.

  • A (phân tích SWOT) — ⚠ Điểm mạnh, Điểm yếu, Cơ hội, Thách thức; ⚠ điểm yếu và thách thức sinh ra rủi ro tiêu cực, cơ hội sinh ra rủi ro tích cực.

  • C (danh sách gợi ý — prompt list) — ⚠ danh mục các nhóm rủi ro định sẵn ⚠ (PESTLE, TECOP, VUCA) ⚠ để kích thích người tham gia nghĩ ra rủi ro; ⚠ đúng là kỹ thuật nhận diện.

Ghi nhớ

⚠ Đối chiếu: ⚠ bộ chiến lược ứng phó rủi ro đã hoàn tất ở lô 181–182 (#25792 chấp nhận, #25807 chuyển giao, #25808 giảm nhẹ, #25846 né tránh), câu #25892 ở lô này (rủi ro hệ thống → leo thang), và câu #25912 (xếp backlog theo rủi ro). ⚠ Câu này bổ sung mảnh còn thiếu: bước NHẬN DIỆN, đứng trước tất cả.

⚠ Bảy quy trình quản lý rủi ro: | Quy trình | Việc | |---|---| | ⚠ 1. Lập kế hoạch quản lý rủi ro | ⚠ quyết định sẽ quản rủi ro thế nào | | ⚠ 2. NHẬN DIỆN rủi ro | ⚠ liệt kê càng nhiều càng tốt — CÂU NÀY | | ⚠ 3. Phân tích ĐỊNH TÍNH | ⚠ xếp hạng theo xác suất × tác động | | ⚠ 4. Phân tích ĐỊNH LƯỢNG | ⚠ quy ra số — EMV, Monte Carlo, cây quyết định | | ⚠ 5. Lập kế hoạch ỨNG PHÓ | ⚠ né tránh / chuyển giao / giảm nhẹ / chấp nhận / leo thang | | ⚠ 6. THỰC HIỆN ứng phó | | | ⚠ 7. GIÁM SÁT rủi ro | ⚠ nhận diện lại liên tục suốt dự án | | ⚠ Điểm mấu chốt | ⚠ nhận diện KHÔNG làm một lần rồi thôi — nó lặp lại suốt vòng đời |

⚠ Các kỹ thuật NHẬN DIỆN rủi ro: | Kỹ thuật | Nội dung | |---|---| | ⚠ Động não (brainstorming) | ⚠ phổ biến nhất — đúng việc PM đang làm | | ⚠ Kỹ thuật Delphi | ⚠ hỏi chuyên gia ẩn danh nhiều vòng, tránh ảnh hưởng lẫn nhau | | ⚠ Phỏng vấn | | | ⚠ Phân tích SWOT | | | ⚠ Phân tích nguyên nhân gốc | | | ⚠ Danh sách gợi ý (prompt list) | ⚠ PESTLE, TECOP, VUCA | | ⚠ Phân tích giả định và ràng buộc | ⚠ mỗi giả định là một rủi ro tiềm tàng — xem câu #25724 | | ⚠ Rà soát tài liệu, danh sách kiểm | |

Từ khoá nhận diện:

"tìm ra rủi ro mới" → ⚠ kỹ thuật nhận diện "xếp hạng, ưu tiên, xác suất × tác động" → ⚠ phân tích định tính "quy ra tiền, mô phỏng" → ⚠ phân tích định lượng ⚠ Câu có chữ "EXCEPT" → ⚠ tìm cái KHÁC NHÓM, không tìm cái sai

⚠ Vì sao "càng nhiều càng tốt" ở bước nhận diện Lý do
⚠ Rủi ro không được nhận diện thì không thể quản
⚠ Sàng lọc là việc của bước SAU, không phải bước này ⚠ phê phán sớm sẽ làm người ta ngừng nói
⚠ Mời đủ bên liên quan để có nhiều góc nhìn ⚠ đúng việc PM đang làm
⚠ Sai lầm phổ biến ⚠ vừa nêu vừa đánh giá — buổi họp sẽ chỉ ra được vài rủi ro hiển nhiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký rủi ro của bạn cập nhật lần cuối khi nào | | | Có mời bên liên quan ngoài đội tham gia nhận diện không | | | Rủi ro TÍCH CỰC (cơ hội) có được ghi không | ⚠ thường bị bỏ quên hoàn toàn |

Và điều làm nên khác biệt giữa hai bước: nhận diện là mở rộng danh sách, phân tích là thu hẹp nó lại. Làm ngược thứ tự thì cả hai đều hỏng.

Câu 202 Business Environment
You are the project manager of the generator upgrade and replacement project, which is expected to last 36 months. The project work is extremely dangerous, so the project team will undergo intense safety training to ensure the workers' safety and make certain the project is not delayed due to faulty work. The cost of the safety training is known as which one of the following?
  1. A The cost of regulations
  2. B The cost of conformance to quality
  3. C The cost of doing business
  4. D The cost of nonconformance to quality
Xem giải thích

Đáp án

B — CHI PHÍ PHÙ HỢP VỚI CHẤT LƯỢNG (cost of conformance to quality).

Vì sao đúng

⚠ Vì sao đào tạo an toàn thuộc chi phí phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Đó là khoản chi CHỦ ĐỘNG để NGĂN sự cố xảy ra | ⚠ chi phí phòng ngừa | | ⚠ Chi TRƯỚC khi có lỗi, không phải chi sau khi có lỗi | ⚠ tiêu chí phân biệt cốt lõi | | ⚠ Đề nói rõ mục đích: đảm bảo an toàn và tránh làm hỏng gây trễ | | | ⚠ Nhóm chi phí phù hợp gồm | ⚠ chi phí PHÒNG NGỪA + chi phí THẨM ĐỊNH | | ⚠ Đào tạo thuộc nhóm nào | ⚠ PHÒNG NGỪA |

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

  • D (chi phí không phù hợp với chất lượng) — ⚠ phương án gây nhiễu mạnh nhất vì chỉ khác một chữ: ⚠ chi phí KHÔNG phù hợp là khoản phải trả ⚠ SAU KHI lỗi đã xảy ra ⚠ — làm lại, phế phẩm, bảo hành, kiện tụng, mất uy tín, ⚠ và chi phí tai nạn lao động nếu công nhân bị thương.

  • A (chi phí của quy định) — ⚠ không phải thuật ngữ chuẩn trong chi phí chất lượng.

  • C (chi phí kinh doanh) — ⚠ quá chung chung; ⚠ mọi khoản chi đều là chi phí kinh doanh, nói vậy không phân loại được gì.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25636 ở lô 178 (phòng ngừa và kiểm tra), câu #25914 ở lô này (thiết kế thực nghiệm), và câu #25900 (chất lượng ít bị ảnh hưởng nhất). ⚠ Cả nhóm về quản lý chất lượng.

⚠ BỐN NHÓM chi phí chất lượng: | Nhóm | Loại | Ví dụ | |---|---|---| | ⚠ PHÒNG NGỪA | ⚠ PHÙ HỢP | ⚠ đào tạo, tài liệu quy trình, thiết bị đúng chuẩn, thời gian làm đúng ngay từ đầu — CÂU NÀY | | ⚠ THẨM ĐỊNH | ⚠ PHÙ HỢP | ⚠ kiểm thử, thanh tra, đo lường, kiểm định | | ⚠ LỖI BÊN TRONG | ⚠ KHÔNG PHÙ HỢP | ⚠ làm lại, phế phẩm — phát hiện TRƯỚC khi giao | | ⚠ LỖI BÊN NGOÀI | ⚠ KHÔNG PHÙ HỢP | ⚠ bảo hành, thu hồi, kiện tụng, mất uy tín — phát hiện SAU khi giao | | ⚠ Quy tắc kinh tế | ⚠ chi 1 đồng phòng ngừa rẻ hơn nhiều lần so với chi để sửa lỗi bên ngoài |

Từ khoá nhận diện:

"đào tạo, quy trình, làm đúng ngay từ đầu" → ⚠ phòng ngừa → PHÙ HỢP "kiểm thử, thanh tra, đo" → ⚠ thẩm định → PHÙ HỢP "làm lại, phế phẩm" → ⚠ lỗi bên trong → KHÔNG PHÙ HỢP "bảo hành, thu hồi, kiện" → ⚠ lỗi bên ngoài → KHÔNG PHÙ HỢP ⚠ Mốc phân chia → ⚠ tiền chi TRƯỚC khi lỗi xảy ra hay SAU

⚠ Vì sao dự án 36 tháng và nguy hiểm càng nên đầu tư phòng ngừa Lý do
⚠ Tai nạn lao động là chi phí không phù hợp ĐẮT NHẤT ⚠ và có phần không quy ra tiền được
⚠ Dự án dài thì đội có thời gian thu hồi khoản đầu tư đào tạo
⚠ Công việc nguy hiểm có tần suất sự cố cao hơn
⚠ Trễ do làm hỏng sẽ kéo theo cả chuỗi hoạt động phía sau ⚠ đề nêu đích danh lý do này
⚠ Ngoài chi phí ⚠ an toàn lao động còn là nghĩa vụ pháp lý và đạo đức, không chỉ là bài toán tiền
⚠ Phân biệt ba khái niệm hay lẫn Khái niệm
⚠ Chi phí CHẤT LƯỢNG (COQ) ⚠ toàn bộ chi phí liên quan tới chất lượng trong vòng đời sản phẩm
⚠ Chi phí PHÙ HỢP ⚠ phần chi để NGĂN lỗi
⚠ Chi phí KHÔNG PHÙ HỢP ⚠ phần trả GIÁ cho lỗi
⚠ Lưu ý về vòng đời ⚠ COQ tính cả chi phí sau khi bàn giao — bảo hành có thể kéo dài nhiều năm sau khi dự án đóng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngân sách của bạn có dòng nào cho phòng ngừa không | ⚠ hay chỉ có dự phòng để sửa sai | | Chi phí làm lại năm ngoái là bao nhiêu | ⚠ rất ít tổ chức đo được | | Đào tạo có bị cắt đầu tiên khi ngân sách căng không | ⚠ dấu hiệu tổ chức chưa hiểu COQ |

Và nghịch lý của chi phí phòng ngừa: khi nó phát huy tác dụng, không có gì xảy ra cả — nên nó luôn là khoản dễ bị cắt nhất trong mọi cuộc rà soát ngân sách.

Câu 203 People
Megan is working hard to be a better listener on her agile team. She hears the words spoken by her team and is highly attentive to them, personalizing them as she hears them. What is the best next step for Megan to improve her listening?
  1. A Megan should focus less on herself and empathize with the speakers on her team.
  2. B Megan should start to coach the rest of the team on what she is hearing.
  3. C Megan does not have any changes to make.
  4. D Megan should start repeating back everything said to ensure she has heard it correctly.
Xem giải thích

Đáp án

A — Megan nên BỚT TẬP TRUNG VÀO CHÍNH MÌNH và ĐỒNG CẢM với người nói trong đội.

Vì sao đúng

⚠ Megan đang ở đâu trong thang lắng nghe: | Bậc | Nội dung | |---|---| | ⚠ Nghe được lời nói của đội | ⚠ Megan đã làm | | ⚠ Rất chú tâm | ⚠ Megan đã làm | | ⚠ NHƯNG "cá nhân hoá" khi nghe | ⚠ quy chiếu lời người khác về trải nghiệm của CHÍNH MÌNH | | ⚠ Vấn đề | ⚠ cô đang nghe qua bộ lọc của bản thân, chưa nghe được điều người kia thực sự muốn nói | | ⚠ Bước tiếp theo | ⚠ chuyển từ NGHE CHÚ TÂM sang NGHE ĐỒNG CẢM — bậc cao nhất |

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

  • D (bắt đầu nhắc lại mọi điều được nói để chắc là nghe đúng) — ⚠ phương án gây nhiễu mạnh nhất vì nhắc lại là một kỹ thuật lắng nghe thật: ⚠ nhưng ⚠ nhắc lại MỌI THỨ là máy móc và làm gián đoạn; ⚠ nó chỉ xác nhận CÂU CHỮ, ⚠ không chạm tới cảm xúc và ý định ⚠ — đúng chỗ Megan đang thiếu.

  • B (bắt đầu huấn luyện đội về những gì cô nghe được) — ⚠ quay lại đặt mình vào trung tâm; ⚠ chính là vấn đề cần sửa.

  • C (Megan không cần thay đổi gì) — ⚠ đề nêu rõ một khiếm khuyết ⚠ (cá nhân hoá), ⚠ nên vẫn còn chỗ để cải thiện.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25891 ở lô này (để Lena tự nói với bên liên quan), câu #25901 (phong cách lãnh đạo hỗ trợ), và câu #25922 (lãnh đạo thừa nhận sai lầm). ⚠ Cả nhóm về kỹ năng con người của người dẫn dắt agile.

⚠ Các bậc lắng nghe: | Bậc | Nội dung | |---|---| | ⚠ PHỚT LỜ | ⚠ không nghe gì cả | | ⚠ GIẢ VỜ NGHE | ⚠ gật đầu nhưng đầu óc ở nơi khác | | ⚠ NGHE CHỌN LỌC | ⚠ chỉ nghe phần mình quan tâm | | ⚠ NGHE CHÚ TÂM | ⚠ tập trung vào câu chữ — Megan đang ở đây | | ⚠ NGHE ĐỒNG CẢM | ⚠ hiểu cả cảm xúc và ý định phía sau — ĐÍCH ĐẾN | | ⚠ Nghe ĐỒNG CẢM khác nghe CHÚ TÂM ở đâu | ⚠ chú tâm là nghe để TRẢ LỜI, đồng cảm là nghe để HIỂU |

Từ khoá nhận diện:

"cá nhân hoá điều nghe được" → ⚠ rào cản của nghe đồng cảm "nhắc lại mọi thứ" → ⚠ kỹ thuật máy móc, không phải bước tiếp theo "không cần thay đổi" → ⚠ luôn sai khi đề đã nêu khiếm khuyết "lắng nghe chủ động" → ⚠ nghe + xác nhận hiểu + phản hồi phi lời

⚠ Rào cản của lắng nghe Rào cản
⚠ Nghĩ trước câu trả lời trong lúc người ta còn nói ⚠ phổ biến nhất
⚠ Quy chiếu về trải nghiệm của mình ⚠ đúng vấn đề của Megan
⚠ Phán xét sớm
⚠ Cắt lời để "giúp"
⚠ Chỉ nghe nội dung, bỏ qua giọng điệu và ngôn ngữ cơ thể
⚠ Kiểm tra nhanh ⚠ sau cuộc nói chuyện, bạn nhớ điều họ nói hay nhớ điều mình định nói?
⚠ Vì sao lắng nghe quan trọng với người dẫn dắt agile Lý do
⚠ Vật cản thật thường được nói ra rất khẽ
⚠ Tin xấu chỉ đến với người biết nghe ⚠ liên hệ câu #25922 — an toàn tâm lý
⚠ Xung đột được giải quyết bằng hiểu, không bằng thắng ⚠ liên hệ câu #25916
⚠ Lãnh đạo phục vụ bắt đầu bằng việc biết đội cần gì
⚠ Thực hành cụ thể ⚠ im lặng thêm ba giây sau khi người kia dứt lời — kỹ thuật đơn giản mà hiệu quả nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong cuộc họp gần nhất bạn nói bao nhiêu phần trăm thời gian | | | Bạn có hay bắt đầu câu bằng "hồi tôi làm dự án X..." không | ⚠ dấu hiệu cá nhân hoá | | Có ai trong đội ít nói hẳn đi không | ⚠ có thể họ đã thấy nói cũng không ai nghe |

Và điều Megan đã làm đúng mà nhiều người bỏ qua: cô nhận ra mình chưa nghe tốt. Phần lớn những người nghe kém đều tin rằng mình nghe rất giỏi.

Câu 204 People
Isaac is the scrum master for Project H, five iterations into deployment, and recently completed a spike. After a contentious meeting with stakeholders, everyone committed to a course of action that Isaac does not personally agree with for the project. What should he do next?
  1. A Voice his disagreement, but commit to the course of action.
  2. B Complain to his project management office.
  3. C Plan for the course of action Isaac supports.
  4. D Attempt to influence the stakeholders to take other action.
Xem giải thích

Đáp án

A — NÊU rõ sự không đồng tình của mình, NHƯNG CAM KẾT thực hiện phương án đã chốt.

Vì sao đúng

⚠ Nguyên tắc "bất đồng và cam kết": | Thành phần | Nội dung | |---|---| | ⚠ NÊU quan điểm khác biệt một cách trung thực | ⚠ minh bạch — im lặng là che giấu thông tin | | ⚠ Nêu TRƯỚC hoặc TẠI thời điểm quyết định | ⚠ không phải sau khi mọi thứ hỏng | | ⚠ Khi tập thể đã chốt thì CAM KẾT thực hiện đầy đủ | ⚠ không phá ngầm, không làm nửa vời | | ⚠ Ghi lại quan điểm trái chiều | ⚠ để sau này rà soát lại có dữ liệu | | ⚠ Vì sao vừa nêu vừa cam kết | ⚠ quyết định tập thể chỉ hiệu lực khi mọi người thực thi thật — bất đồng ngầm giết dự án chậm rãi |

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

  • D (cố gắng tác động để bên liên quan chọn phương án khác) — ⚠ phương án gây nhiễu mạnh nhất vì thuyết phục là kỹ năng chính đáng: ⚠ nhưng ⚠ thời điểm để thuyết phục là TRƯỚC khi chốt; ⚠ đề nói rõ ⚠ "mọi người ĐÃ CAM KẾT" ⚠ — quay lại lật kèo sau đó là phá vỡ quyết định tập thể.

  • C (cứ lập kế hoạch theo phương án Isaac ủng hộ) — ⚠ phá hoại ngầm, ⚠ vi phạm đạo đức nghề nghiệp.

  • B (phàn nàn với văn phòng quản lý dự án) — ⚠ leo thang không chính đáng; ⚠ đây không phải vấn đề vượt thẩm quyền, ⚠ chỉ là Isaac không thích quyết định.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25916 ở lô này (Eva nhường-thua) — ⚠ hai câu bổ sung nhau rất đẹp: ⚠ Eva nhường vì mệt mà KHÔNG nêu quan điểm, ⚠ Isaac thì NÊU quan điểm rồi mới cam kết. ⚠ Cùng kết cục "làm theo phương án của người khác", nhưng một bên lành mạnh, một bên độc hại. ⚠ Xem thêm câu #25919 (quyết định cùng đội) và câu #25922 (minh bạch).

⚠ Khi nào nêu bất đồng, khi nào cam kết: | Giai đoạn | Việc nên làm | |---|---| | ⚠ TRƯỚC quyết định | ⚠ nêu hết lo ngại, đưa dữ liệu, thuyết phục | | ⚠ TẠI thời điểm quyết định | ⚠ nói rõ mình không đồng tình và VÌ SAO | | ⚠ SAU quyết định | ⚠ CAM KẾT thực hiện đầy đủ | | ⚠ KHI có dữ liệu mới | ⚠ được phép nêu lại — nhưng phải là DỮ LIỆU MỚI, không phải cảm giác cũ | | ⚠ Điều tuyệt đối không làm | ⚠ cam kết ngoài miệng rồi làm nửa vời — vừa hỏng việc vừa mất uy tín |

Từ khoá nhận diện:

"đã cam kết rồi nhưng tôi không đồng ý" → ⚠ nêu quan điểm + cam kết thực hiện "cứ làm theo ý mình" → ⚠ phá hoại ngầm, luôn sai "phàn nàn lên trên" → ⚠ leo thang không chính đáng "quay lại thuyết phục sau khi đã chốt" → ⚠ sai thời điểm

⚠ Vì sao "bất đồng và cam kết" hiệu quả Lý do
⚠ Quyết định được đưa ra NHANH, không bị treo mãi
⚠ Quan điểm trái chiều vẫn được ghi nhận, không bị đè
⚠ Thực thi thống nhất nên có kết quả để đánh giá ⚠ thực thi nửa vời thì không biết phương án sai hay cách làm sai
⚠ Nếu sau này sai, có ghi chép để học
⚠ Nguồn gốc ⚠ nguyên tắc lãnh đạo được nhiều tổ chức lớn dùng, rất hợp với văn hoá agile
⚠ Isaac nên trình bày thế nào Cách
⚠ Nêu CỤ THỂ điều mình lo, không nói chung chung ⚠ "tôi lo kiến trúc này khó mở rộng khi tải tăng gấp ba"
⚠ Ghi vào biên bản hoặc nhật ký rủi ro ⚠ lo ngại chưa được giải quyết chính là một RỦI RO đã nhận diện
⚠ Đề xuất tiêu chí để biết khi nào cần xem lại ⚠ cách chuyên nghiệp nhất
⚠ Rồi thực hiện hết mình
⚠ Lưu ý về vai trò ⚠ Isaac là Scrum Master — càng phải làm gương cho cam kết tập thể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyết định gần nhất bạn không đồng tình — bạn đã nói ra chưa | | | Đội bạn có ai gật đầu trong họp rồi làm khác không | | | Lo ngại trái chiều có được ghi vào sổ rủi ro không | |

Và điều phân biệt một chuyên gia với một người khó chịu: cả hai đều không đồng tình, nhưng chỉ một người vẫn khiến quyết định tập thể có cơ hội thành công.

Câu 205 Process
A project is reaching its end and management has asked you to move forward with closing the project. All the technical work is complete. During the closure phase, all the following activities occur except
  1. A Formal acceptance
  2. B Creation of lessons learned.
  3. C Performance reporting
  4. D Performing cost-benefit analysis.
Xem giải thích

Đáp án

D — THỰC HIỆN PHÂN TÍCH CHI PHÍ-LỢI ÍCH (đây KHÔNG phải hoạt động của giai đoạn đóng dự án).

Vì sao đúng

⚠ Phân tích chi phí-lợi ích thuộc giai đoạn nào: | Giai đoạn | Vai trò của phân tích chi phí-lợi ích | |---|---| | ⚠ TRƯỚC dự án / KHỞI TẠO | ⚠ quyết định CÓ NÊN làm dự án này không — dựng business case | | ⚠ Trong LẬP KẾ HOẠCH | ⚠ so sánh các phương án, quyết định đầu tư chất lượng, make-or-buy | | ⚠ Trong KIỂM SOÁT THAY ĐỔI | ⚠ cân nhắc một yêu cầu thay đổi có đáng làm không | | ⚠ Trong ĐÓNG dự án | ⚠ KHÔNG — quyết định đầu tư đã xong, tiền đã tiêu hết | | ⚠ Lý do gốc | ⚠ phân tích chi phí-lợi ích phục vụ việc RA QUYẾT ĐỊNH; đóng dự án không còn quyết định đầu tư nào để ra |

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

  • C (báo cáo hiệu suất) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như việc của giai đoạn giám sát: ⚠ nhưng ⚠ báo cáo hiệu suất CUỐI CÙNG là một phần của việc đóng ⚠ — tổng kết kết quả so với đường cơ sở và trình cho bên liên quan ⚠ (đúng việc Shawn làm ở câu #25918).

  • A (nghiệm thu chính thức) — ⚠ hoạt động trung tâm của giai đoạn đóng: ⚠ khách hàng ký chấp nhận bàn giao.

  • B (tạo bài học kinh nghiệm) — ⚠ đầu ra kinh điển của giai đoạn đóng ⚠ (xem câu #25911 và #25909).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25911 ở lô này (báo cáo bài học cho họp tổng kết), câu #25909 (Milly đóng dự án), và câu #25918 (rà soát mục tiêu đã hoàn thành). ⚠ BỐN câu về giai đoạn đóng trong cùng một lô — chủ đề được hỏi rất dày ở bộ đề này.

⚠ Hoạt động của giai đoạn ĐÓNG: | Hoạt động | Nội dung | |---|---| | ⚠ Nghiệm thu chính thức bàn giao | ⚠ có chữ ký, không phải gật đầu miệng | | ⚠ Đóng hợp đồng và thanh toán hết | | | ⚠ Báo cáo hiệu suất cuối cùng | | | ⚠ Ghi và lưu bài học kinh nghiệm | | | ⚠ Lưu trữ tài liệu dự án | | | ⚠ Giải phóng nguồn lực | | | ⚠ Cập nhật tài sản quy trình của tổ chức | | | ⚠ Chuyển giao cho bộ phận vận hành | | | ⚠ Áp dụng cho | ⚠ cả dự án THÀNH CÔNG lẫn dự án bị HUỶ — xem câu #25909 |

Từ khoá nhận diện:

"phân tích chi phí-lợi ích, NPV, IRR, thời gian hoàn vốn" → ⚠ KHỞI TẠO / lựa chọn dự án "nghiệm thu, lưu trữ, giải phóng nguồn lực" → ⚠ ĐÓNG "bài học kinh nghiệm" → ⚠ thu LIÊN TỤC, tổng hợp khi ĐÓNG ⚠ Câu có chữ "EXCEPT" → ⚠ tìm cái thuộc giai đoạn KHÁC

⚠ Đừng nhầm hai thứ này Phân biệt
⚠ Phân tích chi phí-lợi ích ⚠ TRƯỚC — quyết định có làm không
⚠ Rà soát hiện thực hoá lợi ích ⚠ SAU — kiểm xem lợi ích hứa hẹn có thành thật không
⚠ Điểm quan trọng ⚠ việc thứ hai thường diễn ra SAU KHI dự án đã đóng, hàng tháng hoặc hàng năm sau — và thường do tổ chức làm chứ không phải PM
⚠ Vì sao dễ nhầm ⚠ cả hai đều nói về lợi ích và tiền, nhưng ở hai đầu ngược nhau của vòng đời
⚠ Vì sao đóng dự án hay bị làm qua loa Lý do
⚠ Ai cũng đã chuyển sang dự án mới
⚠ Ngân sách đã hết
⚠ Không có sản phẩm mới nào ra đời từ việc này
⚠ Áp lực từ tổ chức là "xong rồi thì chuyển tiếp"
⚠ Cái giá phải trả ⚠ hợp đồng treo, tranh chấp pháp lý, bài học mất, nguồn lực bị giữ trên giấy tờ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án gần nhất của bạn có được đóng CHÍNH THỨC không | | | Có hợp đồng nào chưa đóng hẳn không | | | Bài học có nằm ở nơi người khác tìm được không | ⚠ để trong ổ đĩa cá nhân thì coi như không có |

Và điều dễ quên nhất về giai đoạn đóng: nó không tạo ra giá trị cho dự án này, nó tạo ra giá trị cho dự án tiếp theo.

Câu 206 People
Jared’s agile team at Morgan Consulting consists of generalizing specialists. What is the best definition of a generalizing specialist?
  1. A A generalizing specialist is someone who knows just one skill.
  2. B A generalizing specialist is a person who knows how to perform their job duties well.
  3. C A generalizing specialist is someone who knows the responsibilities of each role.
  4. D A generalizing specialist is a person who is skilled in more than one discipline.
Xem giải thích

Đáp án

D — Chuyên gia đa năng là người CÓ KỸ NĂNG Ở NHIỀU HƠN MỘT LĨNH VỰC.

Vì sao đúng

⚠ Định nghĩa chuyên gia đa năng (generalizing specialist): | Thành phần | Nội dung | |---|---| | ⚠ SPECIALIST — có ít nhất một lĩnh vực CHUYÊN SÂU | ⚠ giỏi thật sự ở một thứ | | ⚠ GENERALIZING — biết làm được nhiều lĩnh vực khác ở mức đủ dùng | ⚠ không cần giỏi bằng | | ⚠ Thường được vẽ thành "hình chữ T" | ⚠ nét dọc là chiều sâu, nét ngang là chiều rộng | | ⚠ Sẵn sàng học thêm và nhận việc ngoài chuyên môn chính | | | ⚠ Vì sao agile cần | ⚠ đội nhỏ, tự tổ chức, phải tự làm hết mọi việc để hoàn thành hạng mục |

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

  • C (người biết trách nhiệm của TỪNG VAI TRÒ) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ⚠ BIẾT trách nhiệm của người khác khác hẳn LÀM ĐƯỢC việc của họ; ⚠ chuyên gia đa năng phải thực sự có kỹ năng, không chỉ hiểu vai trò.

  • A (người chỉ biết một kỹ năng) — ⚠ đó là chuyên gia hẹp, ⚠ ngược hẳn định nghĩa.

  • B (người làm tốt phần việc của mình) — ⚠ mô tả một nhân viên giỏi bình thường, ⚠ không nói gì về chiều rộng kỹ năng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25893 ở lô này (đánh giá bộ kỹ năng của đội), câu #25896 (chuyển giao tri thức khó hơn dự tính), và câu #25898 (xác định vai trò và trách nhiệm). ⚠ Cả nhóm về năng lực và cơ cấu đội.

⚠ Các mô hình hình dạng kỹ năng: | Hình | Nghĩa | |---|---| | ⚠ Chữ I | ⚠ chỉ sâu một lĩnh vực, không rộng — chuyên gia hẹp | | ⚠ Chữ T | ⚠ sâu một lĩnh vực, rộng nhiều lĩnh vực — CÂU NÀY | | ⚠ Chữ π (pi) | ⚠ sâu HAI lĩnh vực, rộng nhiều lĩnh vực | | ⚠ Chữ E | ⚠ kinh nghiệm, chuyên môn, khám phá, thực thi — mô hình mở rộng | | ⚠ Xu hướng | ⚠ đội agile hướng tới nhiều người chữ T để giảm phụ thuộc vào một cá nhân |

Từ khoá nhận diện:

"kỹ năng ở nhiều hơn một lĩnh vực" → ⚠ chuyên gia đa năng "biết trách nhiệm của các vai trò" → ⚠ hiểu biết, không phải kỹ năng "chỉ một kỹ năng" → ⚠ chuyên gia hẹp "hình chữ T" → ⚠ cách nói khác của cùng khái niệm

⚠ Vì sao đội agile cần chuyên gia đa năng Lý do
⚠ Giảm NÚT THẮT CỔ CHAI ⚠ không phải chờ đúng một người mới làm được một loại việc
⚠ Giảm rủi ro "chiếc xe buýt" ⚠ một người nghỉ thì đội vẫn chạy
⚠ Cả đội cùng chịu trách nhiệm hoàn thành hạng mục ⚠ không có chuyện "phần của tôi xong rồi"
⚠ Việc dồn ở một khâu thì người khác nhảy vào giúp ⚠ swarming — giảm thời gian chờ
⚠ Hiểu công việc của nhau nên phối hợp tốt hơn
⚠ Đánh đổi ⚠ rộng ra thì có thể mất một phần chiều sâu — phải cân bằng, không phải ai cũng làm mọi thứ
⚠ Xây đội chuyên gia đa năng thế nào Cách
⚠ LẬP TRÌNH CẶP hoặc lập trình nhóm ⚠ cách lan toả kỹ năng nhanh nhất
⚠ Luân phiên công việc
⚠ Ghép người mới với người có kinh nghiệm khác lĩnh vực
⚠ Dành thời gian học trong sprint, không đợi "lúc rảnh" ⚠ không bao giờ có lúc rảnh
⚠ Tránh gán nhãn cứng "đây là người backend"
⚠ Cần thời gian ⚠ đây là khoản đầu tư nhiều tháng, không phải một khoá đào tạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có loại việc nào chỉ MỘT người trong đội làm được không | ⚠ đó là nút thắt và là rủi ro | | Đội có lập trình cặp hoặc luân phiên việc không | | | Ai đã học thêm kỹ năng mới trong ba tháng qua | |

Và cách hiểu đúng về chữ T: phần dọc mới là thứ khiến bạn có giá trị, phần ngang là thứ khiến cả đội chạy nhanh hơn. Bỏ phần dọc để đổi lấy phần ngang là hiểu sai hoàn toàn.

Câu 207 People
Christopher is a part of the delivery team that is working on the first iteration of their project. One of his assigned user stories is missing acceptance criteria. Christopher should most likely
  1. A Stop work on the item, as the team made a mistake in estimating a user story with no defined acceptance criteria.
  2. B Reestimate the item before he continues his work.
  3. C

    Ask the Scrum master to add the acceptance criteria so he can continue work.
  4. D Ask the product owner to add the acceptance criteria so he can continue work.
Xem giải thích

Đáp án

D — Hỏi PRODUCT OWNER bổ sung tiêu chí chấp nhận để anh tiếp tục làm.

Vì sao đúng

⚠ Vì sao là product owner: | Lý do | Nội dung | |---|---| | ⚠ PO SỞ HỮU nội dung backlog | ⚠ kể cả tiêu chí chấp nhận | | ⚠ Tiêu chí chấp nhận định nghĩa "thế nào là làm xong ĐÚNG" | ⚠ đó là quyết định về GIÁ TRỊ, thuộc về PO | | ⚠ Christopher phát hiện thiếu thì báo NGAY, không tự đoán | | | ⚠ Anh KHÔNG dừng việc, chỉ bổ sung thông tin còn thiếu | ⚠ giữ dòng chảy công việc | | ⚠ Bối cảnh | ⚠ đây là ITERATION ĐẦU TIÊN — đội còn đang học cách chuẩn bị hạng mục, chuyện này bình thường |

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

  • C (nhờ Scrum Master thêm tiêu chí chấp nhận) — ⚠ phương án gây nhiễu mạnh nhất vì Scrum Master là người hay được hỏi trước: ⚠ nhưng ⚠ Scrum Master KHÔNG sở hữu nội dung backlog; ⚠ SM có thể ĐIỀU PHỐI cuộc trao đổi, ⚠ nhưng người viết tiêu chí phải là PO.

  • A (dừng việc vì đội đã sai khi ước lượng hạng mục không có tiêu chí chấp nhận) — ⚠ phản ứng thái quá; ⚠ đúng là hạng mục chưa đủ "sẵn sàng", nhưng cách xử lý là ⚠ bổ sung nhanh, ⚠ không phải dừng và đổ lỗi.

  • B (ước lượng lại trước khi làm tiếp) — ⚠ có thể cần SAU KHI có tiêu chí, ⚠ nhưng không phải việc ĐẦU TIÊN; ⚠ chưa biết tiêu chí thì ước lượng lại dựa vào đâu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25915 ở lô này (PO chưa xếp backlog / chưa nêu mục tiêu), câu #25899 (chia nhỏ user story), và câu #25912 (PO xếp backlog theo rủi ro). ⚠ Cả nhóm về trách nhiệm của product owner với backlog.

⚠ Ai chịu trách nhiệm gì trong Scrum: | Vai | Sở hữu | |---|---| | ⚠ PRODUCT OWNER | ⚠ NỘI DUNG backlog: hạng mục, thứ tự, tiêu chí chấp nhận, quyết định giá trị | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ CÁCH LÀM: thiết kế, ước lượng, Định nghĩa Hoàn thành, chất lượng kỹ thuật | | ⚠ SCRUM MASTER | ⚠ QUY TRÌNH: điều phối, gỡ vật cản, huấn luyện | | ⚠ Nguyên tắc | ⚠ PO nói CÁI GÌ và VÌ SAO, đội nói THẾ NÀO và BAO NHIÊU |

Từ khoá nhận diện:

"thiếu tiêu chí chấp nhận" → ⚠ hỏi product owner "Scrum Master viết yêu cầu" → ⚠ sai vai "dừng việc và đổ lỗi" → ⚠ gần như luôn sai "ước lượng lại" → ⚠ chỉ sau khi đã có đủ thông tin

⚠ Phân biệt hai khái niệm hay lẫn Khái niệm
⚠ TIÊU CHÍ CHẤP NHẬN ⚠ RIÊNG cho từng hạng mục — điều kiện để hạng mục ĐÓ được coi là đúng
⚠ ĐỊNH NGHĨA HOÀN THÀNH (DoD) ⚠ CHUNG cho mọi hạng mục — đã kiểm thử, đã review, đã tích hợp, đã viết tài liệu
⚠ ĐỊNH NGHĨA SẴN SÀNG (DoR) ⚠ điều kiện để hạng mục được ĐƯA VÀO sprint — trong đó thường CÓ "phải có tiêu chí chấp nhận"
⚠ Ở tình huống này ⚠ hạng mục đã lọt vào sprint mà chưa thoả DoR — dấu hiệu cần chấn chỉnh backlog refinement
⚠ Tiêu chí chấp nhận tốt trông thế nào Đặc điểm
⚠ KIỂM CHỨNG ĐƯỢC — đúng hoặc sai, không mơ hồ ⚠ "nhanh" là tệ, "phản hồi dưới 2 giây" là tốt
⚠ Viết từ góc nhìn NGƯỜI DÙNG
⚠ Đủ ngắn để đội đọc và hiểu ngay
⚠ Bao gồm cả trường hợp biên và trường hợp lỗi
⚠ Dạng hay dùng ⚠ Given / When / Then — Cho trước / Khi / Thì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có Định nghĩa Sẵn Sàng không | | | Có bao nhiêu hạng mục trong sprint hiện tại thiếu tiêu chí chấp nhận | | | Khi thiếu thông tin, đội hỏi ai đầu tiên | ⚠ nếu luôn là Scrum Master thì PO đang vắng mặt quá nhiều |

Và điều đáng chú ý ở phản ứng của Christopher: anh không tự đoán ý product owner. Tự đoán là cách nhanh nhất để làm xong một thứ không ai cần.

Câu 208 People
You need a method to keep workers motivated and inspired on your project. This project has many conditions that the project team sees as unfavorable, but they do like you as a project manager. Which of the following theories states that as long as workers are rewarded, they will remain productive?
  1. A Vroom's Expectancy Theory
  2. B McGregor's Theory of X and Y
  3. C Ouchi's Theory Z
  4. D Herzberg's Theory of Motivation
Xem giải thích

Đáp án

A — THUYẾT KỲ VỌNG CỦA VROOM (Vroom's Expectancy Theory).

Vì sao đúng

⚠ Nội dung thuyết kỳ vọng: | Thành phần | Nghĩa | |---|---| | ⚠ KỲ VỌNG (Expectancy) | ⚠ "nếu tôi nỗ lực thì tôi có làm được không?" | | ⚠ PHƯƠNG TIỆN (Instrumentality) | ⚠ "nếu tôi làm được thì tôi có được thưởng không?" | | ⚠ HOÁ TRỊ (Valence) | ⚠ "phần thưởng đó có đáng để tôi muốn không?" | | ⚠ Động lực = Kỳ vọng × Phương tiện × Hoá trị | ⚠ PHÉP NHÂN — một thành phần bằng 0 thì động lực bằng 0 | | ⚠ Khớp với đề ở chỗ | ⚠ "chừng nào còn được thưởng thì người ta còn giữ năng suất" chính là phát biểu rút gọn của thuyết này |

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

  • D (Thuyết động lực của Herzberg) — ⚠ phương án gây nhiễu mạnh nhất vì đề có chi tiết "nhiều điều kiện đội thấy không thuận lợi nhưng họ quý bạn": ⚠ đó là mô tả ⚠ YẾU TỐ DUY TRÌ ⚠ của Herzberg; ⚠ nhưng Herzberg nói ⚠ yếu tố duy trì chỉ ngăn BẤT MÃN chứ KHÔNG tạo động lực ⚠ — ngược hẳn với phát biểu "có thưởng thì còn năng suất". ⚠ Chi tiết về điều kiện làm việc là mồi nhử cố ý.

  • B (Thuyết X và Y của McGregor) — ⚠ về giả định của NHÀ QUẢN LÝ về nhân viên: ⚠ X coi người ta lười cần giám sát, Y coi người ta tự giác; ⚠ không nói về phần thưởng.

  • C (Thuyết Z của Ouchi) — ⚠ về quản trị kiểu Nhật: ⚠ việc làm trọn đời, ra quyết định đồng thuận, gắn bó lâu dài.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25917 ở lô này (quy luật lợi ích giảm dần — Thuyết Z và Herzberg là phương án nhiễu), câu #25901 (phong cách lãnh đạo hỗ trợ), và các câu về Maslow/McClelland ở lô 177–181. ⚠ Bộ thuyết động lực bị hỏi đi hỏi lại rất nhiều, và LUÔN trộn lẫn nhau trong bộ phương án.

⚠ BẢNG ĐỐI CHIẾU các thuyết động lực: | Thuyết | Ý chính | Từ khoá nhận diện | |---|---|---| | ⚠ VROOM — Kỳ vọng | ⚠ nỗ lực → kết quả → phần thưởng đáng giá | ⚠ "được thưởng thì còn cố" — CÂU NÀY | | ⚠ MASLOW — Tháp nhu cầu | ⚠ năm bậc, thoả bậc dưới mới lên bậc trên | ⚠ "tự thể hiện", "nhu cầu cơ bản" | | ⚠ HERZBERG — Hai yếu tố | ⚠ duy trì ngăn bất mãn, tạo động lực mới thúc đẩy | ⚠ "lương và điều kiện làm việc không tạo động lực" | | ⚠ McCLELLAND — Nhu cầu đạt được | ⚠ thành tựu / quyền lực / liên kết | ⚠ "người này thích được ghi nhận thành tích" | | ⚠ McGREGOR — X và Y | ⚠ giả định của quản lý về nhân viên | ⚠ "cần giám sát chặt" hoặc "tự giác" | | ⚠ OUCHI — Thuyết Z | ⚠ gắn bó lâu dài, đồng thuận | ⚠ "việc làm trọn đời, quản trị kiểu Nhật" | | ⚠ Mẹo | ⚠ có chữ PHẦN THƯỞNG và ĐIỀU KIỆN "chừng nào còn" thì nghĩ ngay tới VROOM |

⚠ Ba thành phần của Vroom trong thực tế dự án: | Thành phần | Đội mất động lực khi | |---|---| | ⚠ KỲ VỌNG = 0 | ⚠ "làm gì thì làm, dự án này cũng không kịp hạn" | | ⚠ PHƯƠNG TIỆN = 0 | ⚠ "cố mấy thì cuối năm cũng xét thưởng như nhau" | | ⚠ HOÁ TRỊ = 0 | ⚠ "thưởng thêm một buổi họp biểu dương thì tôi không cần" | | ⚠ Hệ quả thực tiễn | ⚠ muốn chữa động lực thì phải tìm ĐÚNG thành phần đang bằng 0 — chữa nhầm thì tốn tiền mà vô ích |

⚠ Áp dụng vào tình huống của đề Việc nên làm
⚠ Điều kiện bất lợi mà đội vẫn quý PM ⚠ quan hệ tốt là vốn, nhưng không thay được phần thưởng
⚠ Làm rõ mục tiêu ĐẠT ĐƯỢC ĐƯỢC ⚠ nâng KỲ VỌNG
⚠ Nói rõ đạt rồi thì được gì ⚠ nâng PHƯƠNG TIỆN
⚠ Hỏi xem họ THỰC SỰ muốn phần thưởng gì ⚠ nâng HOÁ TRỊ — đừng đoán
⚠ Nhắc lại ⚠ cải thiện điều kiện bất lợi vẫn cần làm — nhưng theo Herzberg, nó chỉ gỡ bất mãn chứ không tự tạo động lực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có tin mục tiêu là đạt được không | | | Họ có tin nỗ lực sẽ được ghi nhận không | | | Bạn có biết từng người coi trọng phần thưởng gì không | ⚠ có người muốn tiền, có người muốn được học, có người muốn nghỉ bù |

Và điểm mạnh nhất của thuyết Vroom so với các thuyết khác: nó là phép nhân, không phải phép cộng. Một khâu bằng không thì mọi nỗ lực ở hai khâu còn lại đều vô nghĩa.

Câu 209 People
Bob is the scrum master for Project L, which is in its fifth iteration and has a velocity of 49 story points. Recently a new developer joined the team and has approached Bob with several questions about the project. What is the best response Bob could provide?
  1. A Answer their questions and refer them to project documentation.
  2. B Refer them to project documentation.
  3. C Defer their questions until the next daily standup.
  4. D Assign another team member to help them out.
Xem giải thích

Đáp án

A — TRẢ LỜI các câu hỏi của họ VÀ chỉ họ tới tài liệu dự án.

Vì sao đúng

⚠ Vì sao đây là phản hồi tốt nhất: | Lý do | Nội dung | |---|---| | ⚠ Trả lời NGAY — không để người mới bị treo | ⚠ họ đang cần thông tin để bắt đầu đóng góp | | ⚠ Chỉ thêm tài liệu để họ TỰ TÌM về sau | ⚠ dạy cách tự tra cứu, không chỉ cho cá con | | ⚠ Kết hợp CẢ HAI mới là đầy đủ | ⚠ ba phương án còn lại đều chỉ có một nửa hoặc không có gì | | ⚠ Scrum Master phục vụ đội, kể cả thành viên mới | | | ⚠ Kết quả | ⚠ người mới hoà nhập nhanh và sớm tự chủ được |

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

  • B (chỉ chỉ họ tới tài liệu dự án) — ⚠ phương án gây nhiễu mạnh nhất vì chỉ khác đáp án đúng ở việc BỎ vế trả lời: ⚠ tài liệu ⚠ không bao giờ trả lời được hết mọi câu hỏi, ⚠ nhất là những thứ thuộc bối cảnh và lý do; ⚠ và đẩy người mới đi đọc tài liệu là thông điệp lạnh nhạt ngay ngày đầu.

  • C (để tới buổi standup hôm sau mới trả lời) — ⚠ trì hoãn vô cớ, ⚠ và daily scrum ⚠ KHÔNG phải chỗ giải đáp thắc mắc ⚠ (xem câu #25921 — 15 phút, chỉ nêu vật cản).

  • D (giao một thành viên khác giúp họ) — ⚠ đẩy việc; ⚠ có thể hữu ích như bước BỔ SUNG (ghép người đỡ đầu), ⚠ nhưng không thay được việc Scrum Master tự trả lời.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25913 ở lô này (bên liên quan không hiểu story point — nhắc ngắn rồi gửi tài liệu) — ⚠ HAI câu cùng một khuôn xử lý: đáp ứng NGAY + để lại tài nguyên để tự học sau. ⚠ Xem thêm câu #25919 (huấn luyện Scrum Master khác) và câu #25928 (chuyên gia đa năng).

⚠ Vì sao chi tiết "velocity 49, iteration thứ 5" lại đáng chú ý: | Ý nghĩa | Nội dung | |---|---| | ⚠ Đội đã ỔN ĐỊNH sau 5 vòng lặp | ⚠ velocity đã đáng tin | | ⚠ Thêm người mới sẽ LÀM GIẢM velocity một thời gian | ⚠ người cũ phải bỏ thời gian hướng dẫn | | ⚠ Đó là điều BÌNH THƯỜNG và phải giải thích trước với bên liên quan | ⚠ liên hệ câu #25903 — điều tra biến động velocity | | ⚠ Sai lầm | ⚠ kỳ vọng velocity tăng ngay khi thêm người — xem quy luật lợi ích giảm dần ở câu #25917 |

Từ khoá nhận diện:

"thành viên mới đặt câu hỏi" → ⚠ trả lời + chỉ tài liệu "chỉ chỉ tài liệu" → ⚠ thiếu một nửa "để tới standup" → ⚠ standup không phải nơi hỏi đáp "giao người khác" → ⚠ bổ sung được, nhưng không thay thế được

⚠ Đón thành viên mới vào đội agile Việc
⚠ Giới thiệu MỤC TIÊU sản phẩm, không chỉ công việc kỹ thuật ⚠ hiểu VÌ SAO trước khi hiểu LÀM GÌ
⚠ Ghép LẬP TRÌNH CẶP ngay tuần đầu ⚠ cách hoà nhập nhanh nhất
⚠ Chỉ rõ nơi để tài liệu và cách tra
⚠ Giao một hạng mục nhỏ có ý nghĩa sớm ⚠ cảm giác đóng góp được là động lực lớn nhất tuần đầu
⚠ Nói rõ Định nghĩa Hoàn thành và các quy ước của đội
⚠ Điều cần tránh ⚠ đưa một chồng tài liệu rồi biến mất trong hai tuần
⚠ Vì sao tài liệu không đủ Lý do
⚠ Tài liệu ghi CÁI GÌ, hiếm khi ghi VÌ SAO
⚠ Tài liệu luôn lạc hậu hơn thực tế
⚠ Người mới không biết mình chưa biết gì để mà tra ⚠ lý do quan trọng nhất
⚠ Agile ưu tiên TRAO ĐỔI TRỰC TIẾP hơn tài liệu đầy đủ ⚠ giá trị trong Tuyên ngôn Agile
⚠ Cân bằng đúng ⚠ trả lời trực tiếp cho phần bối cảnh, tài liệu cho phần tra cứu lặp lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới gần nhất mất bao lâu mới đóng góp được | | | Đội có quy trình đón người mới không | ⚠ hay mỗi lần lại làm một kiểu | | Bên liên quan có được báo trước về việc velocity giảm tạm thời không | |

Và câu hỏi hay nhất để hỏi một thành viên mới sau hai tuần: "có điều gì bạn đã phải tự đoán vì không tìm được câu trả lời không?" — đó là danh sách việc cần sửa cho lần đón người tiếp theo.

Câu 210 Process
Your project is just beginning, and you have invited all the key stakeholders, the project team, and members of management to participate in an initial meeting. What is this type of meeting called?
  1. A A risk identification meeting
  2. B A requirements gathering meeting
  3. C A kick-off meeting
  4. D A team development meeting
Xem giải thích

Đáp án

C — HỌP KHỞI ĐỘNG (kick-off meeting).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Ý nghĩa | |---|---| | ⚠ "Dự án vừa mới bắt đầu" | ⚠ đúng thời điểm của họp khởi động | | ⚠ Mời TẤT CẢ bên liên quan chính | ⚠ phạm vi rộng — đặc trưng của kick-off | | ⚠ Mời cả ĐỘI DỰ ÁN và LÃNH ĐẠO | ⚠ ba nhóm cùng ngồi lại | | ⚠ Gọi là "buổi họp ĐẦU TIÊN" | | | ⚠ Mục đích | ⚠ công bố dự án, giới thiệu mọi người, thống nhất mục tiêu và cách làm việc |

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

  • B (họp thu thập yêu cầu) — ⚠ phương án gây nhiễu mạnh nhất vì cũng diễn ra sớm và cũng mời bên liên quan: ⚠ nhưng nó có ⚠ mục đích HẸP và CỤ THỂ ⚠ — lấy yêu cầu; ⚠ nó ⚠ không mời lãnh đạo và toàn bộ bên liên quan chính, ⚠ và thường diễn ra SAU kick-off.

  • A (họp nhận diện rủi ro) — ⚠ cũng có mục đích hẹp ⚠ (xem câu #25923); ⚠ diễn ra trong giai đoạn lập kế hoạch.

  • D (họp phát triển đội) — ⚠ hoạt động xây dựng đội, ⚠ không phải buổi họp mở màn dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25883 ở lô này (thoả thuận làm việc nhóm — teaming agreement), câu #25895 (phân tích bên liên quan), và câu #25898 (xác định vai trò và trách nhiệm). ⚠ Cả nhóm về các việc phải làm ở đầu dự án — và nhiều việc trong đó được khởi động ngay tại buổi kick-off.

⚠ Nội dung một buổi họp khởi động tốt: | Nội dung | Chi tiết | |---|---| | ⚠ Giới thiệu mọi người và vai trò của từng người | | | ⚠ Trình bày MỤC TIÊU và lý do tồn tại của dự án | ⚠ từ điều lệ dự án | | ⚠ Phạm vi ở mức cao và các bàn giao chính | | | ⚠ Mốc thời gian và ngân sách tổng thể | | | ⚠ Cách làm việc: nhịp họp, kênh liên lạc, cách báo cáo | | | ⚠ Rủi ro và giả định đã biết | | | ⚠ Kỳ vọng đối với từng nhóm bên liên quan | | | ⚠ Điều quan trọng nhất | ⚠ để mọi người rời phòng với CÙNG MỘT hiểu biết về dự án |

Từ khoá nhận diện:

"buổi họp đầu tiên, mời đủ mọi bên" → ⚠ họp khởi động "lấy yêu cầu" → ⚠ họp thu thập yêu cầu, mục đích hẹp "liệt kê rủi ro" → ⚠ họp nhận diện rủi ro "gắn kết đội" → ⚠ hoạt động phát triển đội

⚠ Thời điểm họp khởi động Trường hợp
⚠ Dự án DỰ ĐOÁN ⚠ sau khi lập kế hoạch xong, trước khi bắt đầu thực hiện
⚠ Dự án nhỏ hoặc đội đã quen ⚠ ngay sau khi ban hành điều lệ
⚠ Dự án AGILE ⚠ có thể có kick-off cho từng bản phát hành, không chỉ một lần đầu
⚠ Dự án nhiều GIAI ĐOẠN ⚠ mỗi giai đoạn có thể có buổi khởi động riêng
⚠ Lưu ý ⚠ kick-off KHÔNG phải là nơi lập kế hoạch — kế hoạch nên đã có trước để trình bày
⚠ Vì sao kick-off đáng đầu tư Lý do
⚠ Là lần duy nhất mọi bên liên quan cùng có mặt
⚠ Đặt kỳ vọng ngay từ đầu, tránh hiểu lầm về sau
⚠ Tạo cam kết công khai từ lãnh đạo ⚠ rất giá trị khi sau này cần gỡ vướng — xem câu #25906
⚠ Cho đội thấy công việc của mình nằm trong bức tranh nào
⚠ Sai lầm phổ biến ⚠ biến kick-off thành buổi trình chiếu một chiều dài hai tiếng — nên dành ít nhất một phần ba thời gian cho hỏi đáp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án gần nhất của bạn có kick-off không | | | Nhà tài trợ có PHÁT BIỂU trong buổi đó không | ⚠ sự có mặt của họ là tín hiệu mạnh với cả tổ chức | | Sau buổi họp, mọi người có hiểu giống nhau về mục tiêu không | ⚠ thử hỏi ba người và so ba câu trả lời |

Và giá trị lớn nhất của buổi khởi động thường không nằm trong nội dung trình bày: nó nằm ở chỗ mọi người biết mặt nhau trước khi có vấn đề xảy ra.