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

Tìm thấy 720 câu.

Câu 281 Process
As the project manager for Oleson's Swim Supply, one of Isiah's tasks is to evaluate the risks in his projects. Some risk events have a high impact, and some have a low probability. In Isiah's current project, multiple risks have impact scores that are high-risk but overall score in the low-risk category. How can this be?
  1. A The risks are rated high, medium, or low.
  2. B The risk scores are graded on a bell curve.
  3. C Each risk has a low probability.
  4. D Until a risk occurs, the risk impact is not accounted for in the project.
Xem giải thích

Đáp án

C — Mỗi rủi ro đó đều có XÁC SUẤT THẤP.

Vì sao đúng

⚠ Công thức chấm điểm rủi ro: | Thành phần | Nội dung | |---|---| | ⚠ ĐIỂM RỦI RO = XÁC SUẤT × TÁC ĐỘNG | ⚠ phép NHÂN, không phải phép cộng | | ⚠ Tác động CAO nhưng điểm tổng THẤP | ⚠ chỉ có thể do xác suất thấp | | ⚠ Ví dụ | ⚠ tác động 0,8 × xác suất 0,1 = 0,08 — nằm ở nhóm thấp | | ⚠ Đây là toán học thuần tuý | ⚠ một thừa số nhỏ kéo cả tích xuống, dù thừa số kia lớn | | ⚠ Ví dụ thực tế | ⚠ động đất phá huỷ nhà máy — tác động thảm khốc, xác suất rất nhỏ |

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

  • B (điểm rủi ro được chấm theo đường cong chuẩn) — ⚠ phương án gây nhiễu mạnh nhất vì nghe có vẻ thống kê: ⚠ nhưng ⚠ chấm điểm rủi ro KHÔNG dùng đường cong chuẩn ⚠ — nó là phép nhân đơn giản của hai thang điểm đã định trước.

  • A (rủi ro được xếp loại cao, trung bình, thấp) — ⚠ mô tả KẾT QUẢ phân loại, ⚠ không giải thích VÌ SAO điểm lại thấp.

  • D (chừng nào rủi ro chưa xảy ra thì tác động chưa được tính vào dự án) — ⚠ SAI HẲN về nguyên tắc: ⚠ toàn bộ mục đích của quản lý rủi ro là ⚠ tính tới tác động TRƯỚC KHI nó xảy ra.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25923 ở lô 183 (phân tích định tính không phải kỹ thuật nhận diện), câu #25983 ở lô này (ngưỡng), bộ chiến lược ứng phó ở lô 181–182, và câu #25719 ở lô 179 (EMV −98.000). ⚠ Nhóm quản lý rủi ro.

⚠ Ma trận xác suất – tác động: | | Tác động THẤP | Tác động TRUNG BÌNH | Tác động CAO | |---|---|---|---| | ⚠ Xác suất CAO | ⚠ trung bình | ⚠ cao | ⚠ RẤT CAO | | ⚠ Xác suất TRUNG BÌNH | ⚠ thấp | ⚠ trung bình | ⚠ cao | | ⚠ Xác suất THẤP | ⚠ RẤT THẤP | ⚠ thấp | ⚠ THẤP — trường hợp của Isiah | | ⚠ Điều dễ bị bỏ sót | ⚠ ô "xác suất thấp – tác động cao" xếp hạng thấp nhưng vẫn có thể HUỶ HOẠI dự án nếu xảy ra |

Từ khoá nhận diện:

"tác động cao mà điểm tổng thấp" → ⚠ xác suất thấp "điểm rủi ro" → ⚠ luôn là xác suất NHÂN tác động "đường cong chuẩn" → ⚠ không dùng trong chấm điểm rủi ro định tính "chưa xảy ra thì chưa tính" → ⚠ phủ nhận toàn bộ quản lý rủi ro

⚠ Vì sao rủi ro "xác suất thấp – tác động cao" đáng lo hơn điểm số của nó Lý do
⚠ Điểm số THẤP nên dễ bị bỏ qua trong danh sách
⚠ Nhưng nếu xảy ra thì có thể GIẾT CHẾT dự án
⚠ Cách chấm điểm nhân che mất tính bất đối xứng này
⚠ Nhiều tổ chức đặt luật riêng: tác động thảm khốc thì phải có kế hoạch bất kể xác suất ⚠ thực hành tốt
⚠ Chiến lược phù hợp ⚠ thường là CHUYỂN GIAO (bảo hiểm) hoặc lập KẾ HOẠCH DỰ PHÒNG — liên hệ #25807 lô 181
⚠ Isiah nên làm gì với các rủi ro này Việc
⚠ KHÔNG bỏ qua chỉ vì điểm thấp
⚠ Đánh dấu riêng nhóm "tác động cao" để theo dõi
⚠ Cân nhắc chuyển giao bằng bảo hiểm hoặc hợp đồng
⚠ Lập kế hoạch dự phòng cho tình huống xấu nhất
⚠ Đặt ĐIỂM KÍCH HOẠT để biết khi nào xác suất tăng lên ⚠ liên hệ #25983 — ngưỡng
⚠ Cân nhắc ⚠ có thể dùng phân tích ĐỊNH LƯỢNG (EMV, Monte Carlo) cho nhóm này để thấy rõ hơn
⚠ Hạn chế của chấm điểm định tính Hạn chế
⚠ Thang điểm là quy ước, dễ bị hiểu khác nhau ⚠ "tác động cao" với mỗi người là một mức
⚠ Phép nhân che mất trường hợp bất đối xứng ⚠ chính là vấn đề câu này
⚠ Phụ thuộc phán đoán chủ quan
⚠ Cách bù ⚠ định nghĩa RÕ từng mức bằng con số cụ thể trong kế hoạch quản lý rủi ro — "tác động cao = trên 100.000 đô hoặc trễ trên một tháng"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có rủi ro nào tác động thảm khốc mà điểm thấp không | ⚠ kiểm riêng nhóm đó | | Các mức "cao/trung bình/thấp" của bạn có định nghĩa bằng số không | | | Có kế hoạch dự phòng cho tình huống xấu nhất chưa | |

Và bài học ẩn sau một phép nhân đơn giản: điểm rủi ro giúp bạn XẾP THỨ TỰ để xử lý, nhưng nó không nói cho bạn biết rủi ro nào có thể khiến dự án không bao giờ hoàn thành.

Câu 282 People
Katherine is a scrum master for project UP. Project UP is almost complete, but several critical enhancements were discovered during the last sprint that must be addressed. The project team has convinced Katherine these updates are necessary. Given project UP's velocity, Katherine believes this additional work will require three additional iterations to resolve. This will put project UP behind schedule. What should Katherine do next?
  1. A Do nothing. It is up to the project team to inform stakeholders of delays.
  2. B Meet with relevant stakeholders, explain the situation, and reset expectations.
  3. C Add a spike to the next iteration.
  4. D Update relevant information radiators so stakeholders can view the updates.
Xem giải thích

Đáp án

B — GẶP các bên liên quan có liên quan, GIẢI THÍCH tình hình và ĐẶT LẠI KỲ VỌNG.

Vì sao đúng

⚠ Vì sao phải chủ động báo ngay: | Lý do | Nội dung | |---|---| | ⚠ Trễ ba vòng lặp là thay đổi LỚN, ảnh hưởng trực tiếp tới bên liên quan | | | ⚠ Họ cần biết SỚM để điều chỉnh kế hoạch của họ | | | ⚠ MINH BẠCH là trụ cột của Scrum | ⚠ liên hệ #25922 lô 183 | | ⚠ Bên liên quan biết tin xấu từ nguồn khác sẽ mất lòng tin hoàn toàn | | | ⚠ Có thể họ sẽ đưa ra lựa chọn khác | ⚠ giao trước phần đã xong, cắt bớt phạm vi, chấp nhận trễ | | ⚠ Vai của Katherine | ⚠ Scrum Master bảo đảm thông tin minh bạch, không phải người che chắn |

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

  • D (cập nhật các bảng thông tin để bên liên quan tự xem) — ⚠ phương án gây nhiễu mạnh nhất vì bảng thông tin đúng là công cụ minh bạch của agile: ⚠ nhưng ⚠ tin xấu lớn KHÔNG được truyền bằng kênh KÉO; ⚠ để họ tự phát hiện qua bảng số liệu là ⚠ kỹ thuật đúng dùng sai chỗ ⚠ — tin quan trọng cần kênh TƯƠNG TÁC (liên hệ #25979 lô 184).

  • C (thêm một spike vào vòng lặp tới) — ⚠ spike để giảm bất định KỸ THUẬT; ⚠ ở đây bất định đã hết — đội đã biết cần ba vòng lặp nữa; ⚠ vấn đề là KỲ VỌNG, không phải kỹ thuật.

  • A (không làm gì, để đội tự báo cho bên liên quan) — ⚠ né trách nhiệm; ⚠ và không có gì bảo đảm việc đó xảy ra.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25961 ở lô 184 (Ethel chưa gắn kết bên liên quan), câu #25936 (thành viên ốm → giao những gì làm được), câu #25987 ở lô này (thêm tính năng mới vào backlog), và câu #26001 (hai nhóm tranh nhau nhận bàn giao). ⚠ Nhóm gắn kết bên liên quan và xử lý tin xấu.

⚠ Nguyên tắc truyền tin xấu: | Nguyên tắc | Nội dung | |---|---| | ⚠ SỚM — ngay khi biết chắc | ⚠ thời gian không làm tin xấu tốt lên | | ⚠ TRỰC TIẾP — không qua email hay bảng thông tin | ⚠ liên hệ #25954 lô 184 | | ⚠ Kèm PHƯƠNG ÁN, không chỉ nêu vấn đề | ⚠ "trễ ba vòng lặp; hoặc giao phần A trước, hoặc cắt phần B" | | ⚠ Nêu rõ NGUYÊN NHÂN và TÁC ĐỘNG bằng số liệu | | | ⚠ Đặt lại kỳ vọng bằng CAM KẾT MỚI cụ thể | | | ⚠ Điều tệ nhất | ⚠ im lặng và hy vọng gỡ kịp — khi không kịp thì mất cả tiến độ lẫn lòng tin |

Từ khoá nhận diện:

"dự án sẽ trễ" → ⚠ gặp bên liên quan, đặt lại kỳ vọng "cập nhật bảng thông tin để họ tự xem" → ⚠ kênh kéo, không hợp với tin xấu lớn "để đội tự báo" → ⚠ né trách nhiệm "thêm spike" → ⚠ giải quyết bất định kỹ thuật, không giải quyết vấn đề kỳ vọng

⚠ Katherine nên chuẩn bị gì trước cuộc gặp Chuẩn bị
⚠ Con số cụ thể: ba vòng lặp, tương đương bao nhiêu tuần
⚠ Lý do các cải tiến đó là BẮT BUỘC, không phải mong muốn ⚠ đội đã thuyết phục được cô, giờ cô phải thuyết phục bên liên quan
⚠ Ít nhất HAI phương án để họ chọn ⚠ giao trước phần đã xong, hoặc cắt phạm vi khác, hoặc chấp nhận trễ
⚠ Rủi ro nếu KHÔNG làm các cải tiến đó ⚠ đây mới là lập luận thuyết phục nhất
⚠ Cùng đi với ai ⚠ nên có PRODUCT OWNER — quyết định đánh đổi phạm vi và thời gian là của PO
⚠ "Đặt lại kỳ vọng" nghĩa là gì Nghĩa
⚠ Thay cam kết cũ bằng cam kết MỚI, cụ thể và thực tế
⚠ Không phải xin lỗi rồi để đó
⚠ Ghi nhận chính thức, không chỉ nói miệng
⚠ Bao gồm cả việc nói rõ điều gì SẼ KHÔNG thay đổi ⚠ để họ còn chỗ bám
⚠ Kiểm tra thành công ⚠ sau cuộc gặp, bên liên quan có kế hoạch mới của riêng họ chưa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tin xấu gần nhất đến với bên liên quan sớm hay muộn | | | Bạn có mang phương án đi cùng tin xấu không | | | Đội có dám báo tin xấu cho bạn không | ⚠ nếu không, bạn cũng sẽ luôn là người biết muộn |

Và điều làm nên khác biệt giữa một cuộc gặp báo trễ tốt và tồi: cuộc gặp tồi kết thúc bằng việc bên liên quan phải đi tìm cách xử lý; cuộc gặp tốt kết thúc bằng việc họ đã chọn xong một trong những phương án bạn mang tới.

Câu 283 Process
Johann is reviewing a recently accepted project scope statement before discussing it with his team. In addition to the mechanical parts his team is expected to provide, Johann notices that his team is expected to write status reports and documentation. Johann is surprised since his team consists mostly of tradespeople who seldom write reports. He checks with his sponsor to see if the reports and documentation are required. The sponsor confirms that they are. This is an example of which part of the project scope statement?
  1. A Deliverables
  2. B Acceptance criteria
  3. C Project exclusions
  4. D Product scope description
Xem giải thích

Đáp án

A — BÀN GIAO (deliverables).

Vì sao đúng

⚠ Vì sao báo cáo và tài liệu là bàn giao: | Lý do | Nội dung | |---|---| | ⚠ Bàn giao KHÔNG chỉ là sản phẩm vật lý | ⚠ định nghĩa gồm sản phẩm, KẾT QUẢ, hoặc khả năng | | ⚠ Tài liệu và báo cáo là KẾT QUẢ phải tạo ra | | | ⚠ Chúng nằm trong tuyên bố phạm vi ĐÃ ĐƯỢC CHẤP NHẬN | ⚠ tức là đã được cam kết | | ⚠ Nhà tài trợ XÁC NHẬN chúng là bắt buộc | ⚠ Johann đã kiểm tra đúng cách | | ⚠ Kết luận | ⚠ đội của Johann phải làm chúng, dù đội toàn thợ nghề ít khi viết báo cáo |

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

  • D (mô tả phạm vi sản phẩm) — ⚠ phương án gây nhiễu mạnh nhất vì cũng nằm trong cùng tài liệu: ⚠ nhưng mô tả phạm vi sản phẩm nêu ⚠ ĐẶC ĐIỂM của sản phẩm ⚠ (liên hệ #25997 cùng lô); ⚠ ở đây đề đang liệt kê ⚠ NHỮNG THỨ PHẢI TẠO RA.

  • B (tiêu chí chấp nhận) — ⚠ điều kiện để được nghiệm thu; ⚠ đề không nêu điều kiện nào.

  • C (loại trừ khỏi phạm vi) — ⚠ những thứ KHÔNG làm; ⚠ ngược hẳn.

Ghi nhớ

⚠ Đối chiếu — BÀN GIAO đã được hỏi HAI lần, khoá nhất quán: | Câu | Tình huống | Loại bàn giao | |---|---|---| | ⚠ #25959 (lô 184) | ⚠ 100 máy in, mực, phụ tùng, bảo trì một năm | ⚠ SẢN PHẨM + DỊCH VỤ | | ⚠ #26005 (lô này) | ⚠ linh kiện cơ khí + báo cáo trạng thái + tài liệu | ⚠ SẢN PHẨM + KẾT QUẢ | | ⚠ Điểm chung | ⚠ cả hai đều nhấn mạnh rằng bàn giao KHÔNG chỉ là vật thể | ⚠ Cùng với #25977 (tiêu chí chấp nhận), #25989 (loại trừ) và #25997 (mô tả phạm vi sản phẩm), bộ đề đã hỏi ĐỦ BỐN MỤC của tuyên bố phạm vi, và mục BÀN GIAO được hỏi hai lần.

⚠ Ba loại bàn giao: | Loại | Ví dụ | |---|---| | ⚠ SẢN PHẨM | ⚠ linh kiện cơ khí, máy in, toà nhà | | ⚠ KẾT QUẢ | ⚠ báo cáo, tài liệu, quy trình mới, kết quả nghiên cứu — CÂU NÀY | | ⚠ KHẢ NĂNG | ⚠ dịch vụ bảo trì, năng lực vận hành mới | | ⚠ Bàn giao TRUNG GIAN | ⚠ sản phẩm của từng giai đoạn, không giao cho khách nhưng vẫn phải tạo ra | | ⚠ Điểm hay quên nhất | ⚠ tài liệu và báo cáo là bàn giao THẬT, cần được ước lượng và cấp nguồn lực như mọi công việc khác |

Từ khoá nhận diện:

"những thứ đội phải tạo ra" → ⚠ bàn giao "đặc điểm, chức năng của sản phẩm" → ⚠ mô tả phạm vi sản phẩm "điều kiện được nghiệm thu" → ⚠ tiêu chí chấp nhận "tài liệu, báo cáo" → ⚠ vẫn là bàn giao, đừng coi là việc phụ

⚠ Vấn đề thật mà Johann đang đối mặt Vấn đề
⚠ Đội toàn thợ nghề, ít khi viết báo cáo ⚠ thiếu KỸ NĂNG cho một bàn giao đã cam kết
⚠ Công việc này có thể chưa được ƯỚC LƯỢNG vào lịch ⚠ rủi ro về thời gian
⚠ Chất lượng tài liệu có thể không đạt kỳ vọng
⚠ Việc Johann đã làm ĐÚNG ⚠ kiểm tra lại với nhà tài trợ thay vì tự cho là không cần
⚠ Việc nên làm tiếp ⚠ ước lượng công sức viết tài liệu, cân nhắc mẫu sẵn hoặc người hỗ trợ chuyên trách, và làm rõ TIÊU CHÍ CHẤP NHẬN của tài liệu
⚠ Vì sao yêu cầu tài liệu hay bị bỏ sót khi ước lượng Lý do
⚠ Nó không phải "sản phẩm chính" nên tâm lý coi nhẹ
⚠ Không ai đo được "thế nào là tài liệu đủ tốt" ⚠ thiếu tiêu chí chấp nhận
⚠ Thường dồn về cuối dự án, đúng lúc hết thời gian
⚠ Cách phòng ⚠ đưa tài liệu vào ĐỊNH NGHĨA HOÀN THÀNH của từng phần, không để dồn — liên hệ #25953 lô 184

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch của bạn có thời gian cho việc viết tài liệu không | | | Đội có kỹ năng cho mọi bàn giao đã cam kết không | ⚠ liên hệ #25893 lô 183 — đánh giá bộ kỹ năng | | Tài liệu có tiêu chí chấp nhận rõ ràng không | |

Và điều Johann phát hiện ra khi đọc kỹ tuyên bố phạm vi: cam kết nặng nhất của dự án đôi khi nằm ở một dòng mà không ai đọc kỹ, vì nó không nói về thứ mà đội tự hào làm ra.

Câu 284 People
Lucas is the project manager for the Orange Project. He is explaining to his project team the importance of completing lessons learned documentation. Why should Lucas's project team complete lessons learned documentation?
  1. A To ensure the closure of the project
  2. B To help project teams in the future complete their projects with more efficiency.
  3. C So future stakeholders can see what the project's team has accomplished
  4. D So management can see what the project's team has accomplished
Xem giải thích

Đáp án

B — Để GIÚP CÁC ĐỘI DỰ ÁN TRONG TƯƠNG LAI hoàn thành dự án của họ HIỆU QUẢ HƠN.

Vì sao đúng

⚠ Mục đích thật của bài học kinh nghiệm: | Mục đích | Nội dung | |---|---| | ⚠ TRUYỀN TRI THỨC sang các dự án sau | ⚠ giá trị chính | | ⚠ Tránh lặp lại sai lầm đã mắc | | | ⚠ Nhân rộng cách làm đã chứng minh là tốt | | | ⚠ Bồi đắp TÀI SẢN QUY TRÌNH của tổ chức | | | ⚠ Nói cách khác | ⚠ bài học không tạo ra giá trị cho dự án NÀY — nó tạo ra giá trị cho dự án TIẾP THEO |

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

  • A (để bảo đảm dự án được đóng) — ⚠ phương án gây nhiễu mạnh nhất vì bài học ĐÚNG LÀ một đầu ra bắt buộc của giai đoạn đóng: ⚠ nhưng đó là ⚠ MÔ TẢ THỦ TỤC, không phải LÝ DO; ⚠ trả lời kiểu này thì đội sẽ viết cho có ⚠ — đúng nguyên nhân khiến phần lớn tài liệu bài học trở nên vô dụng.

  • D (để lãnh đạo thấy đội đã đạt được gì) và C (để bên liên quan tương lai thấy đội đã đạt được gì) — ⚠ biến bài học thành BÁO CÁO THÀNH TÍCH; ⚠ khi mục đích là khoe thì ⚠ không ai còn dám ghi lại điều đã làm sai ⚠ — mà đó mới là phần giá trị nhất.

Ghi nhớ

⚠ Đối chiếu — bài học kinh nghiệm đã được hỏi SÁU lần qua ba lô: ⚠ #25757/#25761 lô 180 (yếu tố quản trị dự án), ⚠ #25896 lô 183 (chuyển giao tri thức khó hơn dự tính), ⚠ #25911 (báo cáo bài học cho họp tổng kết), ⚠ #25964 lô 184 (không có bài học nhà cung cấp), ⚠ #25999 lô này (chủ đề của buổi họp kết thúc), ⚠ và câu này. ⚠ Đây là chủ đề được hỏi dày nhất của cả ba lô, và câu này là câu duy nhất hỏi thẳng VÌ SAO.

⚠ Vòng đời của một bài học kinh nghiệm: | Bước | Nội dung | |---|---| | ⚠ 1. THU THẬP — liên tục trong dự án | ⚠ không đợi tới cuối | | ⚠ 2. GHI LẠI — cụ thể, có bối cảnh và khuyến nghị | | | ⚠ 3. LƯU vào kho của tổ chức | ⚠ không phải ổ đĩa cá nhân | | ⚠ 4. TÌM LẠI ĐƯỢC — phân loại, gắn thẻ, tìm kiếm được | ⚠ bước bị bỏ quên nhiều nhất | | ⚠ 5. ĐƯỢC ĐỌC ở đầu dự án mới | | | ⚠ 6. BIẾN THÀNH thay đổi trong quy trình chuẩn | ⚠ đích đến cuối cùng | | ⚠ Thực tế phũ phàng | ⚠ hầu hết tổ chức dừng ở bước 2 hoặc 3, và tự hỏi vì sao bài học không có tác dụng |

Từ khoá nhận diện:

"giúp dự án tương lai" → ⚠ mục đích thật của bài học "để đóng dự án" → ⚠ mô tả thủ tục, không phải lý do "để lãnh đạo thấy thành tích" → ⚠ biến bài học thành báo cáo khoe ⚠ Câu hỏi VÌ SAO → ⚠ tìm câu nói về GIÁ TRỊ TẠO RA, không tìm câu nói về quy định

⚠ Vì sao mục đích "khoe thành tích" lại nguy hiểm Lý do
⚠ Không ai ghi lại thất bại nếu tài liệu để lãnh đạo đọc
⚠ Mà THẤT BẠI mới là phần dạy được nhiều nhất
⚠ Tài liệu trở thành bản quảng cáo, mất giá trị tham khảo
⚠ Điều kiện để bài học trung thực ⚠ AN TOÀN TÂM LÝ — liên hệ #25992 và #25922
⚠ Câu hỏi kiểm tra ⚠ bài học gần nhất của tổ chức bạn có ghi điều gì đã làm SAI không?
⚠ Lucas nên nói gì với đội để thuyết phục Cách
⚠ Kể một ví dụ bài học của dự án TRƯỚC đã giúp đội này ⚠ thuyết phục nhất, nếu có
⚠ Nhấn mạnh đội sau có thể là CHÍNH HỌ ⚠ họ đang giúp bản thân trong tương lai
⚠ Cam kết rằng tài liệu không dùng để đánh giá cá nhân
⚠ Làm việc này NGẮN và ĐỀU, không dồn một buổi dài cuối dự án
⚠ Tránh ⚠ nói "quy trình bắt phải làm" — đó chính là phương án A

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bài học của tổ chức bạn có ai đọc không | ⚠ kiểm số lượt truy cập nếu có | | Có bài học nào đã trở thành thay đổi quy trình chưa | | | Bài học gần nhất có ghi cả cái sai không | |

Và câu hỏi thẳng thắn nhất mà Lucas có thể đặt cho đội: "nếu sáu tháng nữa có một đội khác gặp đúng vấn đề chúng ta vừa vượt qua, ta muốn họ mất ba tuần để tự tìm ra, hay mất ba phút để đọc?"

Câu 285 Process
Joey is recovering from a project which recently ended. During this project, the stakeholders continuously added deliverables to the scope in addition to updating existing deliverables. The result was Joey's team being overworked and his other projects suffering from a lack of resources, all of which increasingly became devoted to the out-of-scope project. Before starting a new project, Joey decides to write up the overall characteristics of the product his team will provide as soon as he has a project charter and requirements documentation. This is an example of which part of the project scope statement?
  1. A Product scope description
  2. B Acceptance criteria
  3. C Project exclusions
  4. D Deliverables
Xem giải thích

Đáp án

A — MÔ TẢ PHẠM VI SẢN PHẨM (product scope description).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Joey viết ĐẶC TÍNH TỔNG THỂ của sản phẩm đội sẽ tạo ra | ⚠ đúng định nghĩa mô tả phạm vi sản phẩm | | ⚠ Làm ngay khi có ĐIỀU LỆ và TÀI LIỆU YÊU CẦU | ⚠ đúng hai đầu vào chuẩn của quy trình Xác định phạm vi | | ⚠ Mục đích: chặn việc bên liên quan cứ thêm bàn giao mãi | ⚠ bài học từ dự án trước | | ⚠ Định nghĩa | ⚠ mô tả phạm vi sản phẩm nêu ĐẶC ĐIỂM của sản phẩm, dịch vụ hoặc kết quả mà dự án tạo ra | | ⚠ Vì sao nó chặn được trượt phạm vi | ⚠ có mô tả rõ thì mọi yêu cầu mới đều lộ ra là NẰM TRONG hay NẰM NGOÀI |

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

  • D (bàn giao) — ⚠ phương án gây nhiễu mạnh nhất vì cả đoạn đầu nói về việc bên liên quan thêm bàn giao: ⚠ nhưng ⚠ thứ Joey ĐANG VIẾT là ĐẶC TÍNH TỔNG THỂ của sản phẩm, ⚠ không phải danh sách những thứ phải giao.

  • C (loại trừ khỏi phạm vi) — ⚠ nêu những gì KHÔNG làm; ⚠ Joey đang mô tả sản phẩm SẼ có gì.

  • B (tiêu chí chấp nhận) — ⚠ điều kiện nghiệm thu; ⚠ chưa nhắc tới.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG trong CÙNG MỘT LÔ: ⚠ câu #25997 ⚠ (tài liệu mô tả ứng dụng web ba phần với chức năng từng phần) ⚠ và câu này ⚠ (Joey viết đặc tính tổng thể của sản phẩm). ⚠ Hai câu hỏi CÙNG một mục, khoá HOÀN TOÀN NHẤT QUÁN — cùng là mô tả phạm vi sản phẩm. ⚠ Khác biệt: #25997 nhìn tài liệu ĐÃ CÓ, câu này nhìn hành động VIẾT RA nó, và nêu thêm ĐỘNG CƠ — chặn trượt phạm vi.

⚠ Bộ bốn mục của tuyên bố phạm vi — đã đủ và có mục lặp: | Mục | Các câu đã hỏi | |---|---| | ⚠ BÀN GIAO | ⚠ #25959 (lô 184), #26005 (lô này) | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ #25977 (lô 184) | | ⚠ LOẠI TRỪ KHỎI PHẠM VI | ⚠ #25989 (lô này) | | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | ⚠ #25997, #26007 (lô này) | | ⚠ Tổng | ⚠ SÁU câu về cùng một tài liệu qua hai lô — không câu nào mâu thuẫn với câu nào |

Từ khoá nhận diện:

"đặc tính tổng thể của sản phẩm" → ⚠ mô tả phạm vi sản phẩm "danh sách phải tạo ra" → ⚠ bàn giao "điều kiện nghiệm thu" → ⚠ tiêu chí chấp nhận "rõ ràng không làm" → ⚠ loại trừ

⚠ Bài học Joey rút ra từ dự án trước Bài học
⚠ Bên liên quan liên tục thêm bàn giao ⚠ TRƯỢT PHẠM VI — liên hệ #25975 lô 184
⚠ Đội quá tải
⚠ Các dự án KHÁC của Joey thiếu nguồn lực ⚠ liên hệ #25935 lô 184 — ràng buộc nguồn lực
⚠ Nguyên nhân gốc ⚠ không có mô tả phạm vi rõ ràng ngay từ đầu, nên không có căn cứ để nói "cái này nằm ngoài"
⚠ Cách chữa của Joey ⚠ viết mô tả phạm vi sản phẩm NGAY khi có điều lệ — phòng bệnh chứ không chữa bệnh
⚠ Bộ ba tài liệu chặn trượt phạm vi Tài liệu
⚠ MÔ TẢ PHẠM VI SẢN PHẨM ⚠ sản phẩm là cái gì — CÂU NÀY
⚠ LOẠI TRỪ KHỎI PHẠM VI ⚠ rõ ràng không bao gồm gì — liên hệ #25989
⚠ QUY TRÌNH KIỂM SOÁT THAY ĐỔI ⚠ cơ chế xử lý mọi yêu cầu mới — liên hệ #25991
⚠ Thiếu một trong ba ⚠ trượt phạm vi gần như chắc chắn xảy ra
⚠ Nhưng nhớ ⚠ có tài liệu mà không THỰC THI thì cũng như không — phải có người dám nói "cái này cần yêu cầu thay đổi"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có mô tả phạm vi sản phẩm viết ra không | | | Khi có yêu cầu mới, bạn có căn cứ để nói nó nằm ngoài không | | | Bên liên quan đã xác nhận mô tả đó chưa | ⚠ chưa xác nhận thì nó chỉ là ghi chú của riêng bạn |

Và điều Joey làm đúng nhất không phải là viết tài liệu: anh nhận ra rằng vấn đề của dự án trước không nằm ở việc bên liên quan đòi hỏi quá nhiều, mà ở việc không có gì để đối chiếu khi họ đòi hỏi.

Câu 286 People
Kelsie is the scrum master for Project Q, which is in its fifth week of implementation and has a velocity of 48 story points. Recently a developer approached Kelsie with a challenge related to a stakeholder not releasing project resources to complete a task. What should Kelsie do next?
  1. A Complain to the project management office.
  2. B Meet directly with the stakeholder about the issue.
  3. C Have the developer speak with the stakeholder.
  4. D Escalate the issue to her steering committee.
Xem giải thích

Đáp án

B — GẶP TRỰC TIẾP bên liên quan đó về vấn đề này.

Vì sao đúng

⚠ Vì sao Scrum Master phải trực tiếp xử lý: | Lý do | Nội dung | |---|---| | ⚠ GỠ VẬT CẢN là trách nhiệm cốt lõi của Scrum Master | ⚠ đây đúng là một vật cản | | ⚠ Lập trình viên đã báo cáo đúng cách — giờ tới lượt Kelsie | | | ⚠ Vấn đề nằm NGOÀI đội, nên đội không tự gỡ được | ⚠ khác với bất đồng nội bộ — liên hệ #25937 lô 184 | | ⚠ Gặp TRỰC TIẾP là kênh hiệu quả nhất | ⚠ liên hệ #25954 lô 184 | | ⚠ Trình tự đúng | ⚠ thử giải quyết ở mức thấp nhất trước, leo thang chỉ khi thất bại |

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

  • C (để lập trình viên tự nói chuyện với bên liên quan) — ⚠ phương án gây nhiễu mạnh nhất vì trao quyền cho đội là nguyên tắc đúng: ⚠ nhưng ⚠ lập trình viên KHÔNG có vị thế để đòi một bên liên quan nhả nguồn lực; ⚠ và anh ta ⚠ đã tìm tới Kelsie chính vì tự mình không giải quyết được ⚠ — đẩy ngược lại là né trách nhiệm.

  • D (leo thang lên uỷ ban chỉ đạo) và A (phàn nàn với văn phòng quản lý dự án) — ⚠ leo thang QUÁ SỚM; ⚠ Kelsie chưa hề nói chuyện với người đó; ⚠ leo thang trước khi thử là cách nhanh nhất làm hỏng quan hệ với bên liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26001 ở lô này (hai nhóm bên liên quan cãi nhau → gặp cả hai), câu #25982 ở lô 184 (hai bên liên quan bất đồng ưu tiên), câu #25906 ở lô 183 (nhà tài trợ gỡ vướng vượt thẩm quyền PM), và câu #25919 (huấn luyện Scrum Master khác). ⚠ Nhóm gỡ vật cản và leo thang.

⚠ THANG LEO THANG — thử từ dưới lên: | Mức | Khi nào | |---|---| | ⚠ 1. Người trong cuộc tự giải quyết | ⚠ nếu họ có vị thế để làm | | ⚠ 2. Scrum Master / PM gặp trực tiếp | ⚠ CÂU NÀY | | ⚠ 3. Product owner hoặc quản lý chức năng can thiệp | | | ⚠ 4. Nhà tài trợ | ⚠ liên hệ #25906 | | ⚠ 5. Uỷ ban chỉ đạo / PMO | | | ⚠ Nguyên tắc | ⚠ mỗi lần leo thang phải nói được "tôi đã thử gì và vì sao chưa đủ" | | ⚠ Sai lầm hai đầu | ⚠ leo thang quá sớm làm mất quan hệ; leo thang quá muộn làm mất thời gian của dự án |

Từ khoá nhận diện:

"bên liên quan không nhả nguồn lực" → ⚠ Scrum Master gặp trực tiếp trước "leo thang ngay" → ⚠ quá sớm khi chưa thử "để thành viên tự đi nói" → ⚠ né trách nhiệm khi họ không có vị thế "gỡ vật cản" → ⚠ trách nhiệm số một của Scrum Master

⚠ Kelsie nên chuẩn bị gì cho cuộc gặp Chuẩn bị
⚠ Hiểu VÌ SAO bên liên quan giữ nguồn lực ⚠ có thể họ cũng đang có sức ép — liên hệ #25935 lô 184
⚠ Số liệu về TÁC ĐỘNG lên dự án ⚠ "thiếu người này thì công việc X trễ hai tuần"
⚠ Đề xuất phương án, không chỉ nêu yêu cầu ⚠ "chúng tôi chỉ cần 30% thời gian của bạn ấy trong ba tuần"
⚠ Thái độ HỢP TÁC, không đối đầu
⚠ Kết thúc bằng ⚠ một cam kết cụ thể có thời hạn, không phải "để tôi xem"
⚠ Nếu cuộc gặp thất bại thì sao Bước tiếp
⚠ GHI vào NHẬT KÝ VẤN ĐỀ với ngày, người, kết quả ⚠ có dấu vết để leo thang
⚠ Báo product owner — vì tác động tới giá trị giao được
⚠ Rồi mới leo thang lên nhà tài trợ hoặc PMO
⚠ Điều cần nói khi leo thang ⚠ nêu TÁC ĐỘNG và ĐỀ XUẤT, không kể lể ai sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vật cản gần nhất của đội bạn mất bao lâu để gỡ | | | Đội có báo vật cản sớm không | ⚠ nếu muộn, có thể vì lần trước báo mà không ai gỡ | | Bạn có nhật ký vấn đề ghi lại các lần đã thử không | |

Và thước đo giá trị thật của một Scrum Master: không phải số buổi họp anh ta điều phối, mà là quãng thời gian trung bình từ lúc một vật cản được nêu tới lúc nó biến mất.

Câu 287 People
As a project manager, Farah will need to know how to negotiate. In which environment do negotiations work best?
  1. A Sincerity, honesty, and extreme caution
  2. B Caution and yielding
  3. C Mutual respect and admiration
  4. D Mutual respect and cooperation
Xem giải thích

Đáp án

D — TÔN TRỌNG LẪN NHAU và HỢP TÁC.

Vì sao đúng

⚠ Vì sao hai yếu tố này là nền của thương lượng tốt: | Yếu tố | Nội dung | |---|---| | ⚠ TÔN TRỌNG LẪN NHAU | ⚠ cho phép nói thẳng nhu cầu mà không sợ bị lợi dụng | | ⚠ HỢP TÁC | ⚠ hai bên cùng tìm giải pháp, không tranh phần | | ⚠ Kết quả hướng tới THẮNG-THẮNG | ⚠ liên hệ #25916 lô 183 — bảng đối chiếu chiến lược xung đột | | ⚠ Quan hệ được giữ cho các lần thương lượng sau | ⚠ rất quan trọng trong dự án — người ta còn gặp lại nhau nhiều lần | | ⚠ Cốt lõi | ⚠ thương lượng dựa trên LỢI ÍCH, không dựa trên VỊ THẾ |

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

  • C (tôn trọng lẫn nhau và NGƯỠNG MỘ) — ⚠ phương án gây nhiễu mạnh nhất vì chỉ khác đáp án đúng ở một từ: ⚠ nhưng ⚠ NGƯỠNG MỘ không phải điều kiện cần ⚠ — bạn hoàn toàn thương lượng tốt được với người bạn không ngưỡng mộ; ⚠ và ngưỡng mộ quá mức còn làm suy yếu vị thế của chính bạn.

  • A (chân thành, trung thực và HẾT SỨC THẬN TRỌNG) — ⚠ hai yếu tố đầu tốt, ⚠ nhưng ⚠ "hết sức thận trọng" hàm ý NGHI NGỜ ⚠ — làm chậm và cản trở việc chia sẻ thông tin cần thiết.

  • B (thận trọng và NHƯỜNG NHỊN) — ⚠ nhường nhịn là chiến lược NHƯỢNG BỘ, ⚠ dẫn tới kết quả nhường-thua (liên hệ #25916); ⚠ đó không phải thương lượng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25982 ở lô 184 (hai bên liên quan bất đồng → thương lượng), câu #26001 ở lô này (hai nhóm tranh nhau nhận bàn giao), câu #26002 (xếp hạng tuyệt đối cùng bên liên quan), và câu #25992 (xung đột xây dựng). ⚠ Thương lượng là kỹ năng chạy xuyên suốt nhóm câu hỏi về bên liên quan.

⚠ Nguyên tắc thương lượng dựa trên lợi ích: | Nguyên tắc | Nội dung | |---|---| | ⚠ TÁCH CON NGƯỜI khỏi VẤN ĐỀ | ⚠ cứng rắn với vấn đề, mềm mỏng với con người | | ⚠ Tập trung vào LỢI ÍCH, không vào VỊ THẾ | ⚠ hỏi "vì sao anh cần điều đó" thay vì tranh cãi về điều được nêu ra | | ⚠ Tạo ra NHIỀU PHƯƠNG ÁN trước khi quyết | | | ⚠ Dựa trên TIÊU CHÍ KHÁCH QUAN | ⚠ giá thị trường, chuẩn ngành, dữ liệu — liên hệ #26002 | | ⚠ Chuẩn bị trước | ⚠ biết PHƯƠNG ÁN TỐT NHẤT NẾU KHÔNG THOẢ THUẬN của mình là gì |

⚠ Phân biệt VỊ THẾ và LỢI ÍCH — ví dụ kinh điển: | | Nội dung | |---|---| | ⚠ VỊ THẾ | ⚠ "tôi cần cả quả cam" ⚠ — hai bên tranh nhau, chỉ chia đôi được | | ⚠ LỢI ÍCH | ⚠ một người cần NƯỚC, người kia cần VỎ để làm bánh | | ⚠ Kết quả | ⚠ hỏi VÌ SAO thì cả hai đều được trọn vẹn — đó là thắng-thắng thật | | ⚠ Áp dụng vào dự án | ⚠ "tôi cần xong trước tháng 6" có thể thật ra là "tôi cần báo cáo được cho hội đồng tháng 6" — hai nhu cầu rất khác nhau |

Từ khoá nhận diện:

"tôn trọng lẫn nhau và hợp tác" → ⚠ môi trường thương lượng tốt nhất "nhường nhịn" → ⚠ nhượng bộ, không phải thương lượng "hết sức thận trọng" → ⚠ hàm ý nghi ngờ, cản trở trao đổi "ngưỡng mộ" → ⚠ không phải điều kiện cần

⚠ Quản lý dự án thương lượng những gì Nội dung
⚠ NGUỒN LỰC với quản lý chức năng ⚠ liên hệ #25935 lô 184 và #26008 cùng lô
⚠ PHẠM VI và ưu tiên với bên liên quan
⚠ ĐIỀU KHOẢN với nhà cung cấp ⚠ liên hệ #25960 lô 184 — T&M và điều khoản trần
⚠ Lịch trình và mốc với khách hàng
⚠ Vai trò và trách nhiệm trong đội
⚠ Tần suất ⚠ PM thương lượng gần như mỗi ngày, phần lớn là những cuộc thương lượng không ai gọi tên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cuộc thương lượng gần nhất bạn có hỏi "vì sao" không | | | Bạn có biết phương án thay thế của mình là gì trước khi vào bàn không | | | Sau khi thoả thuận, quan hệ tốt lên hay xấu đi | ⚠ thước đo thật của một cuộc thương lượng tốt |

Và điều phân biệt thương lượng với mặc cả: mặc cả chia một chiếc bánh cố định, còn thương lượng bắt đầu bằng câu hỏi liệu chiếc bánh có thể lớn hơn không.

Câu 288 People
Nicholas uses the multi-voting method on his team at Soap Street to have stakeholders prioritize the backlog. He has noticed that there have been several disagreements in the last few sessions. What is the best way for him to reduce disagreements in the next session?
  1. A Tell the stakeholders that no negative discussions can occur in the session.
  2. B Ask selected stakeholders not to attend the next session.
  3. C Have stakeholders vote silently on their top priorities.
  4. D Allow each stakeholder no more than a one-minute comment period per item.
Xem giải thích

Đáp án

C — Cho bên liên quan BỎ PHIẾU IM LẶNG cho các ưu tiên hàng đầu của họ.

Vì sao đúng

⚠ Vì sao bỏ phiếu im lặng giảm tranh cãi: | Lý do | Nội dung | |---|---| | ⚠ Mỗi người quyết ĐỘC LẬP, không bị ảnh hưởng bởi người nói to | | | ⚠ Loại bỏ hiệu ứng ĐÁM ĐÔNG và thiên lệch neo | ⚠ người bỏ phiếu đầu tiên định hình cả nhóm | | ⚠ Người ít nói vẫn có tiếng nói ngang bằng | ⚠ liên hệ #25968 lô 184 — người ngại nói trong retrospective | | ⚠ Kết quả là DỮ LIỆU tổng hợp, không phải cuộc tranh cãi | | | ⚠ Sau khi có kết quả | ⚠ mới thảo luận, và lúc đó thảo luận về CHÊNH LỆCH cụ thể chứ không về mọi thứ |

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

  • D (cho mỗi bên liên quan bình luận tối đa một phút mỗi hạng mục) — ⚠ phương án gây nhiễu mạnh nhất vì giới hạn thời gian đúng là một kỹ thuật điều phối: ⚠ nhưng nó ⚠ chỉ RÚT NGẮN tranh cãi chứ không GIẢM tranh cãi; ⚠ và với danh sách dài thì một phút mỗi hạng mục mỗi người là buổi họp không bao giờ kết thúc.

  • A (tuyên bố không được có thảo luận tiêu cực nào) — ⚠ ĐÈ NÉN bất đồng thay vì xử lý; ⚠ đi ngược nguyên tắc xung đột xây dựng (liên hệ #25992 cùng lô).

  • B (đề nghị một số bên liên quan không dự buổi sau) — ⚠ loại người khỏi bàn; ⚠ vấn đề sẽ quay lại nặng hơn, và đó là cách nhanh nhất mất lòng tin.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26002 ở lô này (xếp hạng tuyệt đối khi mọi việc đều "ưu tiên cao"), câu #25982 ở lô 184 (hai bên liên quan bất đồng ưu tiên), câu #26001 (tranh nhau nhận bàn giao), và câu #25992 (xung đột xây dựng). ⚠ Bốn câu tạo thành một bộ công cụ khá đầy đủ để xử lý bất đồng về ưu tiên.

⚠ Các kỹ thuật ra quyết định nhóm: | Kỹ thuật | Cách làm | |---|---| | ⚠ NHẤT TRÍ (unanimity) | ⚠ mọi người đều đồng ý — chậm nhưng cam kết cao nhất | | ⚠ ĐA SỐ (majority) | ⚠ trên 50% | | ⚠ ĐA SỐ TƯƠNG ĐỐI (plurality) | ⚠ nhóm đông nhất thắng, dù chưa quá bán | | ⚠ ĐỘC ĐOÁN (autocratic) | ⚠ một người quyết | | ⚠ PHÂN TÍCH ĐA TIÊU CHÍ | ⚠ cho điểm theo bảng tiêu chí | | ⚠ BỎ PHIẾU NHIỀU LƯỢT (multi-voting) | ⚠ mỗi người có nhiều phiếu, thu hẹp dần danh sách — kỹ thuật Nicholas đang dùng | | ⚠ Cải tiến cho mọi kỹ thuật | ⚠ cho bỏ phiếu IM LẶNG trước, thảo luận sau |

Từ khoá nhận diện:

"giảm tranh cãi khi bỏ phiếu" → ⚠ bỏ phiếu im lặng, độc lập "cấm thảo luận tiêu cực" → ⚠ đè nén bất đồng, luôn sai "mời một số người ra khỏi buổi họp" → ⚠ loại người khỏi bàn, luôn sai "giới hạn thời gian nói" → ⚠ rút ngắn chứ không giảm tranh cãi

⚠ Quy trình đề xuất cho buổi sau của Nicholas Bước
⚠ 1. Trình bày danh sách hạng mục, làm rõ nghĩa từng mục ⚠ tranh cãi nhiều khi chỉ vì hiểu khác nhau về cùng một mục
⚠ 2. Mỗi người cho điểm hoặc bỏ phiếu IM LẶNG ⚠ giấy dán, biểu quyết điện tử, hoặc phát 100 điểm
⚠ 3. Công bố kết quả tổng hợp
⚠ 4. Chỉ THẢO LUẬN những mục có CHÊNH LỆCH LỚN ⚠ tiết kiệm phần lớn thời gian
⚠ 5. Bỏ phiếu lại nếu cần
⚠ Kết quả ⚠ tranh luận tập trung vào đúng chỗ có bất đồng thật, thay vì trải đều khắp danh sách
⚠ Vì sao bất đồng lại tăng qua các buổi gần đây Nguyên nhân có thể
⚠ Danh sách hạng mục ngày càng dài
⚠ Không có TIÊU CHÍ chung để so sánh ⚠ liên hệ #26002
⚠ Có người mới tham gia mà chưa nắm bối cảnh
⚠ Sức chứa của đội không được nói rõ ⚠ không biết chỉ làm được 5 việc thì ai cũng đòi thêm
⚠ Nicholas nên kiểm ⚠ bỏ phiếu im lặng giải quyết TRIỆU CHỨNG; vẫn nên tìm xem nguyên nhân gốc là gì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong buổi họp gần nhất, ai nói nhiều nhất | ⚠ nếu luôn là cùng một người thì kết quả đang bị lệch | | Mọi người có hiểu giống nhau về từng hạng mục không | | | Có tiêu chí chung để so sánh không | |

Và điều đơn giản mà kỹ thuật này khai thác: khi người ta viết ra lựa chọn trước khi nghe người khác nói, bạn có được ý kiến thật của cả nhóm. Khi họ nói ra lần lượt, bạn thường chỉ có ý kiến của người nói đầu tiên, lặp lại theo nhiều cách khác nhau.

Câu 289 Process
Stephen is a new team member for your software upgrade project, and he has much experience working in predictive environments but is not familiar with many agile project management concepts. You decide to pull him aside to discuss some options for Stephen to understand the agile mindset better. Which of the following methods would not be the most appropriate method for Stephen to learn agile methodologies?
  1. A Continue to use his predictive methods to support the project.
  2. B Research the topic to learn what they do not know.
  3. C Examine the projects or organization’s knowledge repository.
  4. D Collaborate with other team members to fill in the knowledge gap.
Xem giải thích

Đáp án

A — TIẾP TỤC dùng các phương pháp dự đoán quen thuộc để hỗ trợ dự án (đây là cách KHÔNG phù hợp nhất).

Vì sao đúng

⚠ Vì sao phương án này không giúp Stephen học agile: | Lý do | Nội dung | |---|---| | ⚠ Nó KHÔNG dạy anh điều gì mới cả | ⚠ câu hỏi là về cách HỌC agile | | ⚠ Giữ nguyên tư duy cũ là đúng thứ cần thay đổi | ⚠ đề nói rõ mục tiêu là hiểu TƯ DUY agile | | ⚠ Có thể gây xung đột với cách làm việc của đội | | | ⚠ Ba phương án còn lại đều là con đường học THẬT | ⚠ tự nghiên cứu, đọc kho tri thức, học từ đồng đội | | ⚠ Lưu ý công bằng | ⚠ kinh nghiệm dự đoán của Stephen là TÀI SẢN — nhưng dùng nó thay cho việc học thì không phải cách học |

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

  • C (xem kho tri thức của dự án hoặc tổ chức) — ⚠ phương án gây nhiễu mạnh nhất vì nghe khô khan và thụ động: ⚠ nhưng đó ⚠ chính là bài học kinh nghiệm và tài sản quy trình ⚠ (liên hệ #26006 cùng lô) ⚠ — cách học rẻ và nhanh nhất, và là đúng thứ mà kho bài học tồn tại để phục vụ.

  • B (tự nghiên cứu để lấp chỗ mình chưa biết) — ⚠ cách học chủ động, hoàn toàn hợp lý.

  • D (hợp tác với các thành viên khác để lấp khoảng trống kiến thức) — ⚠ cách học hiệu quả nhất trong agile; ⚠ liên hệ #25928 lô 183 — chuyên gia đa năng lan toả kỹ năng qua làm việc cùng nhau.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25908 ở lô 183 (tổ chức mới chuyển sang agile hiểu sai velocity), câu #25913 (bên liên quan không hiểu story point), câu #25931 ở lô 184 (thành viên mới đặt câu hỏi → trả lời và chỉ tài liệu), và câu #25994 ở lô này (đội chưa quen agile, phạm vi chưa rõ). ⚠ Nhóm chuyển đổi sang agile.

⚠ Người có nền dự đoán học agile thế nào cho tốt: | Cách | Nội dung | |---|---| | ⚠ Hiểu VÌ SAO agile khác, không chỉ học thuật ngữ | ⚠ thuật ngữ học một tuần, tư duy mất vài tháng | | ⚠ Tham gia đủ các sự kiện và quan sát | | | ⚠ Ghép cặp làm việc với người có kinh nghiệm agile | | | ⚠ Đọc bài học của các dự án agile trong tổ chức | | | ⚠ Chấp nhận cảm giác khó chịu ban đầu | ⚠ không có kế hoạch chi tiết cho cả năm là cảm giác rất lạ với người quen dự đoán | | ⚠ Điều KHÔNG nên làm | ⚠ âm thầm áp khuôn cũ lên cách làm mới — vừa không học được vừa gây nhiễu cho đội |

Từ khoá nhận diện:

"tiếp tục dùng cách cũ" → ⚠ không phải cách học cái mới "tự nghiên cứu, đọc kho tri thức, học từ đồng đội" → ⚠ đều là cách học hợp lệ ⚠ Câu hỏi có chữ "KHÔNG phù hợp NHẤT" → ⚠ tìm phương án duy nhất không dẫn tới việc học

⚠ Kinh nghiệm dự đoán của Stephen có giá trị gì trong agile Giá trị
⚠ Hiểu về rủi ro, phụ thuộc, ước lượng ⚠ agile vẫn cần những thứ này
⚠ Kỹ năng làm việc với bên liên quan và hợp đồng
⚠ Kỷ luật về chất lượng và tài liệu
⚠ Rất hữu ích nếu dự án theo cách tiếp cận LAI ⚠ liên hệ #25972 lô 184
⚠ Vấn đề duy nhất ⚠ là khi anh dùng nó để THAY THẾ việc học, chứ không phải để BỔ SUNG
⚠ Những hiểu lầm phổ biến của người mới chuyển sang agile Hiểu lầm
⚠ "Agile là không có kế hoạch" ⚠ sai — agile lập kế hoạch NHIỀU HƠN, chỉ là theo tầng và liên tục
⚠ "Agile là không có tài liệu" ⚠ sai — chỉ là ưu tiên phần mềm chạy được hơn tài liệu đầy đủ
⚠ "Agile là muốn gì cũng được" ⚠ sai — vẫn có đánh đổi, liên hệ #25987 cùng lô
⚠ "Scrum Master là quản lý dự án đổi tên" ⚠ sai — liên hệ #25958 lô 184
⚠ Cách sửa nhanh nhất ⚠ cho họ trải qua vài sprint thật thay vì đọc thêm tài liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai đang âm thầm làm theo cách cũ không | | | Người mới có được ghép cặp với ai không | | | Kho tri thức của tổ chức có gì về agile không | |

Và điều đáng nói về tình huống này: bạn đã kéo Stephen ra nói chuyện riêng thay vì để anh tự loay hoay. Đó chính là cách học thứ tư — và là cách hiệu quả nhất trong bốn cách.

Câu 290 Process
Eve is the project manager for Project Wooly, which is in its ninth week of implementation, is $5,000 over a $100,000 budget, and is one week behind schedule. Recently Eve noticed a team member working on a task that was not part of Project Wooly's scope but will provide value. What should Eve do?
  1. A Stop the work and direct the team member to another task.
  2. B Escalate the issue to the team member's manager.
  3. C Stop the work but submit a change request.
  4. D Do nothing. The task will benefit the project.
Xem giải thích

Đáp án

C — DỪNG công việc đó lại, NHƯNG NỘP MỘT YÊU CẦU THAY ĐỔI.

Vì sao đúng

⚠ Hai vế, cả hai đều cần: | Vế | Lý do | |---|---| | ⚠ DỪNG — vì công việc nằm NGOÀI phạm vi đã duyệt | ⚠ làm việc ngoài phạm vi mà không qua quy trình là MẠ VÀNG | | ⚠ NỘP YÊU CẦU THAY ĐỔI — vì nó CÓ giá trị | ⚠ không vứt bỏ giá trị, đưa nó qua đúng cửa | | ⚠ Dự án đang VƯỢT CHI 5% và TRỄ một tuần | ⚠ càng phải kiểm soát chặt, không thêm việc tuỳ tiện | | ⚠ Để CCB hoặc nhà tài trợ quyết | ⚠ PM không tự duyệt cũng không tự từ chối | | ⚠ Cân bằng | ⚠ vừa bảo vệ đường cơ sở, vừa không giết chết sáng kiến của thành viên |

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

  • D (không làm gì, việc đó có lợi cho dự án) — ⚠ phương án gây nhiễu mạnh nhất vì "có giá trị" nghe như lý do đủ: ⚠ nhưng đây chính là ⚠ ĐỊNH NGHĨA CỦA MẠ VÀNG ⚠ (liên hệ #25975 lô 184) ⚠ — thêm giá trị mà khách hàng không yêu cầu và không ai duyệt; ⚠ và nó tiêu nguồn lực của một dự án đang vượt chi và trễ hạn.

  • A (dừng việc và chuyển thành viên sang việc khác) — ⚠ đúng nửa đầu, sai nửa sau: ⚠ ⚠ VỨT BỎ giá trị ⚠ mà không cho ai cơ hội xem xét.

  • B (leo thang lên quản lý của thành viên đó) — ⚠ biến việc chuyên môn thành chuyện kỷ luật; ⚠ thành viên có ý tốt, không vi phạm đạo đức; ⚠ liên hệ #25939 lô 184 — tìm nguyên nhân trước khi trừng phạt.

Ghi nhớ

⚠ Đối chiếu — cặp câu về MẠ VÀNG: ⚠ câu #25975 ở lô 184 ⚠ (Jason tự thêm hai tính năng bằng ngân sách dư → nhận diện đó là MẠ VÀNG) ⚠ và câu này ⚠ (thành viên làm việc ngoài phạm vi → DỪNG và nộp yêu cầu thay đổi). ⚠ Hai câu nhất quán và bổ sung nhau: câu kia hỏi GỌI TÊN hiện tượng, câu này hỏi LÀM GÌ với nó. ⚠ Xem thêm câu #25991 ở lô này (vì sao cần kiểm soát thay đổi) và câu #25978 lô 184 (phân tích tác động trước).

⚠ Xử lý công việc ngoài phạm vi — cây quyết định: | Tình huống | Xử lý | |---|---| | ⚠ Ngoài phạm vi, KHÔNG có giá trị | ⚠ dừng, chuyển sang việc khác | | ⚠ Ngoài phạm vi, CÓ giá trị | ⚠ dừng + nộp yêu cầu thay đổi — CÂU NÀY | | ⚠ Trong phạm vi nhưng làm sai | ⚠ SỬA LỖI — liên hệ #25933 lô 184 | | ⚠ Trong phạm vi, làm quá mức cần thiết | ⚠ cũng là mạ vàng — dừng lại ở mức yêu cầu | | ⚠ Nguyên tắc chung | ⚠ KHÔNG BAO GIỜ để công việc ngoài phạm vi tiếp tục mà không có phê duyệt, dù nó tốt tới đâu |

Từ khoá nhận diện:

"ngoài phạm vi nhưng có giá trị" → ⚠ dừng + yêu cầu thay đổi "không làm gì vì nó có lợi" → ⚠ mạ vàng, luôn sai "dừng và bỏ luôn" → ⚠ vứt bỏ giá trị một cách không cần thiết "báo quản lý của người đó" → ⚠ biến việc chuyên môn thành kỷ luật

⚠ Vì sao mạ vàng đặc biệt nguy hiểm với dự án đang TRỄ và VƯỢT CHI Lý do
⚠ Tiêu nguồn lực đáng lẽ dùng để bắt kịp tiến độ
⚠ Thêm phần chưa được kiểm thử vào sản phẩm
⚠ Làm sai lệch số liệu EVM ⚠ công sức bỏ ra không nằm trong đường cơ sở
⚠ Khó giải trình với nhà tài trợ ⚠ "trễ và vượt chi, mà lại làm thêm việc không ai yêu cầu"
⚠ Con số của đề ⚠ vượt 5.000 trên 100.000 và trễ một tuần — chưa nghiêm trọng, nhưng đủ để không được phép lãng phí
⚠ Eve nên nói với thành viên đó thế nào Cách
⚠ GHI NHẬN sáng kiến trước ⚠ người này đang cố làm sản phẩm tốt hơn
⚠ Giải thích vì sao phải qua quy trình ⚠ liên hệ #25991 — vì tác động phải được xem xét
⚠ Cùng người đó viết yêu cầu thay đổi ⚠ biến sáng kiến thành đề xuất chính thức
⚠ Thông báo kết quả cho họ dù duyệt hay không ⚠ liên hệ #25956 lô 184 — nhật ký thay đổi
⚠ Điều KHÔNG nên làm ⚠ mắng "sao lại tự ý làm" — lần sau người ta sẽ giấu thay vì làm công khai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai đang làm việc không có trong kế hoạch không | | | Có cơ chế nào để họ đề xuất ý tưởng chính thức không | ⚠ không có thì họ sẽ tự làm | | Yêu cầu thay đổi ở tổ chức bạn mất bao lâu để xử lý | ⚠ quá lâu cũng là một lý do khiến người ta tự ý làm |

Và bài học ẩn phía sau: một thành viên tự ý làm việc ngoài phạm vi thường không phải là người thiếu kỷ luật — đó có thể là dấu hiệu rằng kênh chính thức để đề xuất ý tưởng của bạn quá chậm hoặc không tồn tại.