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

Tìm thấy 720 câu.

Câu 121 Process
Erik spends a lot of time working with the project team to develop the Work Breakdown Structure (WBS). He prefers to make it as simple as possible for his team to identify their specific contributions to his project. As a result, he assigns different tasks to different roles rather than specific people and clarifies the expected deliverables for each task. The result is that Erik's employees only come to him if they need clarification but are otherwise self-directed. This is an example of which type of project governance?
  1. A Capturing lessons learned
  2. B Defining roles and responsibilities
  3. C Identifying, escalating, and resolving risks
  4. D Stage-gate or phase reviews
Xem giải thích

Đáp án

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

Vì sao đúng

⚠ Những gì Erik làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Giao việc theo VAI TRÒ, không theo tên người cụ thể | ⚠ định nghĩa trách nhiệm ở mức vai trò | | ⚠ Làm rõ BÀN GIAO mong đợi cho mỗi công việc | ⚠ mỗi vai trò biết mình phải tạo ra cái gì | | ⚠ Làm WBS ĐƠN GIẢN để đội dễ nhận ra phần đóng góp của mình | | | ⚠ Kết quả: nhân viên TỰ CHỦ, chỉ hỏi khi cần làm rõ | ⚠ bằng chứng vai trò đã đủ rõ | | ⚠ Kết luận | ⚠ đây là cơ chế quản trị bằng việc xác định rõ ai chịu trách nhiệm về cái gì |

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

  • A (thu thập bài học kinh nghiệm) — ⚠ là ghi lại điều đã học; ⚠ Erik đang thiết lập cách làm việc ngay từ đầu, không phải rút kinh nghiệm.

  • C (nhận diện, leo thang và xử lý rủi ro) — ⚠ là cơ chế xử lý vấn đề và rủi ro; ⚠ không phải phân vai.

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

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là câu THỨ TƯ trong bộ đề dùng cùng bốn phương án về yếu tố quản trị dự án, ⚠ và là câu ⚠ ĐẦU TIÊN có khoá "defining roles and responsibilities" — ⚠ hoàn tất đủ ba trong bốn khoá có thể. ⚠ Bảng tổng hợp: | Câu | Lô | Bối cảnh | Khoá | Chữ cái | |---|---|---|---|---| | ⚠ #25730 | ⚠ 179 | ⚠ chính sách không trả đũa, kênh ẩn danh, leo thang | ⚠ nhận diện – leo thang – xử lý rủi ro | ⚠ C | | ⚠ #25757 | ⚠ 180 | ⚠ giữ vật chứng làm giáo cụ | ⚠ thu thập bài học | ⚠ D | | ⚠ #25761 | ⚠ 180 | ⚠ retrospective sau sự cố, đăng wiki | ⚠ thu thập bài học | ⚠ C | | ⚠ #25843 | ⚠ 182 | ⚠ giao việc theo vai trò, nêu rõ bàn giao | ⚠ xác định vai trò và trách nhiệm | ⚠ B | ⚠ Bốn khoá đều đúng, KHÔNG mâu thuẫn, và chữ cái đã bị xáo ở mọi câu. ⚠ Cách phân biệt: hỏi hành động nhằm mục đích gì — ghi lại tri thức, xử lý vấn đề đang diễn ra, phân vai, hay rà soát định kỳ.

⚠ Bốn yếu tố quản trị dự án: | 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 | | ⚠ Identifying, escalating, resolving risks | ⚠ cơ chế LIÊN TỤC phát hiện và xử lý vấn đề | | ⚠ Defining roles and responsibilities | ⚠ AI làm gì, AI quyết gì — CÂU NÀY |

Từ khoá nhận diện:

"ai làm gì, giao việc theo vai trò" → ⚠ roles and responsibilities "ghi lại, chia sẻ điều đã học" → ⚠ lessons learned "cơ chế báo cáo và xử lý vấn đề" → ⚠ risk governance "rà soát cuối giai đoạn" → ⚠ stage-gate

⚠ Vì sao giao theo VAI TRÒ thay vì theo TÊN NGƯỜI Lý do
⚠ Kế hoạch không phụ thuộc vào một cá nhân cụ thể ⚠ người nghỉ việc thì vai trò vẫn còn
⚠ Dễ điều chỉnh khi nhân sự thay đổi
⚠ Rõ ràng về NĂNG LỰC cần có cho mỗi công việc
⚠ Tránh thiên vị khi phân công
⚠ Nhược điểm ⚠ vẫn phải ánh xạ vai trò sang người thật ở bước huy động nguồn lực
⚠ Vì sao cách của Erik tạo ra sự TỰ CHỦ Cơ chế
⚠ Biết rõ mình chịu trách nhiệm về cái gì
⚠ Biết rõ bàn giao mong đợi trông thế nào
⚠ Không cần hỏi lại vì đã rõ từ đầu
⚠ Chỉ hỏi khi thật sự cần làm rõ ⚠ dấu hiệu phân vai tốt
⚠ Liên hệ ⚠ xem câu #25810 ở lô 181 về ma trận RACI — công cụ chuẩn để làm việc này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi công việc có rõ ai chịu trách nhiệm không | | | Bàn giao mong đợi của mỗi công việc có được mô tả không | | | Đội có phải hỏi bạn nhiều không | ⚠ hỏi nhiều thường là dấu hiệu phân vai chưa rõ |

Và thước đo đơn giản cho chất lượng của việc phân vai: đội hỏi bạn ít đi hay nhiều lên. Erik đo được điều đó — và đó là bằng chứng anh ấy làm đúng.

Câu 122 People
You are a project manager for your organization and have just finished a project on time and on budget. Pleased with your work, management has just assigned you to lead a virtual team that will create an organizational communication server. As part of this project, you will need to develop password-protected chat rooms for each branch worldwide and general chat rooms so every employee can sign on and communicate their ideas in real-time. What technology solution does this scenario best represent?
  1. A The creation of one space to share and save all types of content
  2. B The choice of tools to communicate synchronously
  3. C The choice of tools to communicate asynchronously
  4. D The selection of tools that allow you to create and track tasks
Xem giải thích

Đáp án

B — Việc lựa chọn công cụ để giao tiếp ĐỒNG BỘ (synchronously).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Phòng chat để nhân viên trao đổi ý tưởng | | | ⚠ THỜI GIAN THỰC — real-time | ⚠ từ khoá quyết định | | ⚠ Nhiều người cùng có mặt và trao đổi qua lại | | | ⚠ Kết luận | ⚠ giao tiếp ĐỒNG BỘ — mọi người tham gia CÙNG LÚC |

⚠ Phân biệt đồng bộ và bất đồng bộ: | Loại | Nghĩa | Ví dụ | |---|---|---| | ⚠ SYNCHRONOUS — đồng bộ | ⚠ mọi người tham gia CÙNG LÚC | ⚠ họp, gọi video, gọi điện, CHAT THỜI GIAN THỰC | | ⚠ ASYNCHRONOUS — bất đồng bộ | ⚠ mỗi người tham gia vào thời điểm KHÁC NHAU | ⚠ email, diễn đàn, wiki, video ghi sẵn, tài liệu chung |

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

  • C (công cụ giao tiếp BẤT ĐỒNG BỘ) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ chỉ khác một chữ; ⚠ nhưng ⚠ "real-time" trong đề loại trừ hẳn phương án này.

  • A (một không gian để chia sẻ và lưu mọi loại nội dung) — ⚠ mô tả kho tài liệu, ⚠ đó là giao tiếp KÉO và bất đồng bộ.

  • D (công cụ tạo và theo dõi công việc) — ⚠ mô tả công cụ quản lý công việc, ⚠ không phải công cụ giao tiếp.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25784 ở lô 181 (hội nghị truyền hình cho đội ảo), câu #25681 ở lô 178 (giao tiếp kéo), và câu #25837 ở lô này (trò chuyện trực tiếp hiệu quả nhất). ⚠ Bốn câu cùng nhóm kiến thức quản lý giao tiếp.

⚠ Ba cách phân loại giao tiếp — đừng lẫn: | Cách phân loại | Các loại | |---|---| | ⚠ Theo PHƯƠNG PHÁP (PMBOK) | ⚠ interactive, push, pull | | ⚠ Theo THỜI GIAN | ⚠ synchronous, asynchronous — CÂU NÀY | | ⚠ Theo TÍNH CHÍNH THỨC | ⚠ formal, informal | | ⚠ Một kênh có thể thuộc nhiều loại | ⚠ ví dụ họp video là interactive + synchronous + có thể formal hoặc informal |

Từ khoá nhận diện:

"thời gian thực, cùng lúc" → ⚠ synchronous "mỗi người xem khi rảnh" → ⚠ asynchronous "kho tài liệu, wiki" → ⚠ asynchronous và pull "tạo và theo dõi công việc" → ⚠ công cụ quản lý việc, không phải giao tiếp

⚠ Ưu và nhược của giao tiếp đồng bộ Điều
⚠ ƯU: phản hồi tức thì, làm rõ nhanh
⚠ ƯU: xây quan hệ và niềm tin tốt hơn
⚠ NHƯỢC: đòi mọi người rảnh CÙNG LÚC ⚠ rất khó với đội đa múi giờ
⚠ NHƯỢC: gây gián đoạn công việc đang tập trung
⚠ NHƯỢC: không tự động lưu lại nếu không ghi chép
⚠ Với đội TOÀN CẦU ⚠ cần kết hợp cả hai: đồng bộ cho việc cần bàn, bất đồng bộ cho việc cần lưu
⚠ Vì sao dự án này cần CẢ HAI Lý do
⚠ Phòng chat riêng cho từng chi nhánh ⚠ đồng bộ trong cùng múi giờ
⚠ Phòng chat chung toàn công ty ⚠ đồng bộ khi trùng giờ, bất đồng bộ khi lệch giờ
⚠ Chat lưu lại lịch sử ⚠ người ở múi giờ khác đọc lại được — thành bất đồng bộ
⚠ Thực tế ⚠ công cụ chat hiện đại phục vụ CẢ HAI kiểu — nhưng đề nhấn "real-time" nên khoá là đồng bộ
⚠ Lưu ý về bảo mật trong đề Lưu ý
⚠ Phòng chat CÓ MẬT KHẨU cho từng chi nhánh ⚠ phân quyền theo nhóm
⚠ Phòng chung mở cho mọi nhân viên
⚠ Đây là yêu cầu ⚠ về phân quyền truy cập — một phần của thiết kế hệ thống giao tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội của bạn có bao nhiêu múi giờ | ⚠ càng nhiều càng phải dựa vào bất đồng bộ | | Thông tin nào cần trao đổi ngay, thông tin nào để lại được | | | Quyết định trong chat có được ghi lại ở nơi tra cứu được không | |

Và nguyên tắc thiết kế giao tiếp cho đội toàn cầu: mặc định là bất đồng bộ, đồng bộ chỉ khi thật sự cần bàn bạc. Ép mọi người cùng online là cách nhanh nhất để ai đó phải họp lúc nửa đêm.

Câu 123 Process
You have been appointed as the manager of a new, large, and complex project to construct a major new manufacturing plant. The project is different from any other project you have worked on before. The project cost is estimated at $20,000,000, and the project will utilize three vendors for different portions of the project work. Halfway through the project, a new risk has is discovered. Of the following choices, which should your team do first?
  1. A Ask a subject matter expert to assess the probability and impact.
  2. B Add the risk to the top of the backlog so it can be addressed ASAP.
  3. C Schedule a risk-based spike to resolve or minimize the situation.
  4. D Stop the project and evaluate the root cause of the risk.
Xem giải thích

Đáp án

A — Nhờ một CHUYÊN GIA đánh giá XÁC SUẤT và TÁC ĐỘNG của rủi ro.

Vì sao đúng

⚠ Vì sao đánh giá trước là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ CHƯA BIẾT rủi ro này lớn hay nhỏ | ⚠ không đánh giá thì không biết ứng phó ở mức nào | | ⚠ Xác suất và tác động quyết định MỨC ƯU TIÊN | | | ⚠ Dự án dùng CÔNG NGHỆ và LOẠI HÌNH mới với bạn | ⚠ đề nói rõ "khác với mọi dự án bạn từng làm" | | ⚠ Chuyên gia có kiến thức mà đội chưa có | ⚠ expert judgment là kỹ thuật chuẩn của PMBOK | | ⚠ Kết luận | ⚠ phân tích rủi ro ĐỊNH TÍNH trước, rồi mới quyết cách ứng phó |

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

  • D (dừng dự án và đánh giá nguyên nhân gốc) — ⚠ phản ứng CỰC ĐOAN: ⚠ dừng một dự án 20 triệu vì một rủi ro chưa được đánh giá là quyết định rất tốn kém.

  • B (đưa rủi ro lên đầu backlog để xử lý ngay) và C (lên lịch một spike để xử lý) — ⚠ cả hai là công cụ AGILE, ⚠ trong khi đây là ⚠ dự án XÂY DỰNG NHÀ MÁY, ba nhà cung cấp, 20 triệu — vòng đời DỰ ĐOÁN; ⚠ và cả hai đều là HÀNH ĐỘNG khi chưa biết mức độ nghiêm trọng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25846 ngay dưới (chiến lược ứng phó), câu #25719 ở lô 179 (EMV), và câu #25748 ở lô 180 (rủi ro đánh giá liên tục). ⚠ Bốn câu tạo thành chuỗi đầy đủ: nhận diện → đánh giá → chọn chiến lược → theo dõi.

⚠ Bảy quy trình quản lý rủi ro — PMBOK 6: | Quy trình | Nhóm | Việc | |---|---|---| | ⚠ Plan Risk Management | ⚠ Lập kế hoạch | ⚠ cách quản lý rủi ro, thang xác suất và tác động | | ⚠ Identify Risks | ⚠ Lập kế hoạch | ⚠ tìm ra rủi ro, ghi vào risk register | | ⚠ Perform QUALITATIVE Risk Analysis | ⚠ Lập kế hoạch | ⚠ đánh giá XÁC SUẤT và TÁC ĐỘNG, xếp ưu tiên — BƯỚC CỦA CÂU NÀY | | ⚠ Perform QUANTITATIVE Risk Analysis | ⚠ Lập kế hoạch | ⚠ định lượng bằng số: EMV, Monte Carlo, cây quyết định | | ⚠ Plan Risk Responses | ⚠ Lập kế hoạch | ⚠ chọn chiến lược ứng phó | | ⚠ Implement Risk Responses | ⚠ Thực hiện | ⚠ thực sự làm những gì đã lập kế hoạch | | ⚠ Monitor Risks | ⚠ Giám sát và kiểm soát | ⚠ theo dõi, phát hiện rủi ro mới |

Từ khoá nhận diện:

"vừa phát hiện rủi ro mới" → ⚠ ĐÁNH GIÁ xác suất và tác động trước "nhờ chuyên gia" → ⚠ expert judgment — kỹ thuật chuẩn "dừng dự án" → ⚠ cực đoan, hầu như luôn sai "spike, backlog" → ⚠ công cụ agile — kiểm tra xem dự án có phải agile không

⚠ Phân tích định tính gồm những gì Nội dung
⚠ Đánh giá XÁC SUẤT xảy ra ⚠ theo thang đã định trong kế hoạch quản lý rủi ro
⚠ Đánh giá TÁC ĐỘNG ⚠ lên phạm vi, lịch, chi phí, chất lượng
⚠ Đặt vào MA TRẬN xác suất – tác động
⚠ Xếp ƯU TIÊN các rủi ro
⚠ Đánh giá mức KHẨN CẤP và khả năng phát hiện
⚠ Kết quả ⚠ danh sách rủi ro được xếp hạng — cơ sở để quyết định đầu tư bao nhiêu vào việc ứng phó
⚠ Vì sao dự án này đặc biệt cần chuyên gia Lý do
⚠ "Khác với mọi dự án bạn từng làm" ⚠ kinh nghiệm cũ không áp dụng được
⚠ Quy mô 20 triệu — sai lầm rất đắt
⚠ Ba nhà cung cấp — phức tạp về phối hợp
⚠ Đang ở GIỮA dự án — thay đổi tốn kém hơn
⚠ Phán đoán chuyên gia ⚠ là kỹ thuật được PMBOK liệt kê ở hầu hết mọi quy trình
⚠ Sau khi đánh giá thì làm gì Bước
⚠ Ghi kết quả vào RISK REGISTER
⚠ Nếu rủi ro lớn: phân tích ĐỊNH LƯỢNG thêm ⚠ EMV, Monte Carlo
⚠ Chọn chiến lược ứng phó phù hợp mức độ ⚠ xem câu #25846 ngay dưới
⚠ Xác định chủ sở hữu rủi ro
⚠ Nếu vượt thẩm quyền: ESCALATE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết rủi ro này lớn tới đâu chưa | ⚠ không biết thì chưa nên hành động | | Ai là người đủ chuyên môn để đánh giá | | | Thang xác suất và tác động đã được định trước chưa | ⚠ trong kế hoạch quản lý rủi ro |

Và nguyên tắc chung mà đề PMP kiểm tra ở gần như mọi câu tình huống: đánh giá trước, hành động sau. Phản ứng tương xứng chỉ có được khi biết mức độ nghiêm trọng thật.

Câu 124 Process
Calvin is responsible for identifying and advising on risks for a medium-sized software company. His portfolio includes a line of software programs, all of which have new versions slated for release during buying season for several large clients. Unfortunately, analysts recently discovered that some of the software has a debilitating bug. Calvin anticipates that the damage to his client's reputation will outweigh the cost of pushing the release back until the bug can be resolved, so he advises them to do so. Which risk management option does this represent?
  1. A Transfer
  2. B Escalate
  3. C Mitigate
  4. D Avoid
Xem giải thích

Đáp án

D — Avoid (né tránh rủi ro).

Vì sao đúng

⚠ Vì sao dời lịch phát hành là né tránh: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro: lỗi nghiêm trọng tới tay khách hàng lớn | | | ⚠ Hành động: DỜI phát hành cho tới khi sửa xong lỗi | | | ⚠ Kết quả: lỗi KHÔNG CÒN KHẢ NĂNG tới tay khách | ⚠ xác suất về 0 | | ⚠ Thay đổi KẾ HOẠCH dự án để loại bỏ rủi ro | ⚠ đúng định nghĩa avoid | | ⚠ Cái giá | ⚠ chậm ra mắt, có thể mất doanh thu mùa mua sắm — đây là chi phí của việc né tránh |

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

  • C (Mitigate — giảm nhẹ) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ giảm nhẹ sẽ là ⚠ phát hành đúng hạn nhưng kèm bản vá nhanh, hoặc chỉ phát hành cho một nhóm nhỏ; ⚠ Calvin ⚠ KHÔNG phát hành cho tới khi hết lỗi — đó là loại bỏ hoàn toàn, không phải giảm nhẹ.

  • A (Transfer) — ⚠ không có bên thứ ba nào nhận hậu quả.

  • B (Escalate) — ⚠ Calvin CÓ đưa lên cấp trên để quyết, ⚠ nhưng ⚠ escalate trong PMBOK nghĩa là chuyển rủi ro RA NGOÀI phạm vi dự án vì vượt thẩm quyền; ⚠ ở đây rủi ro vẫn thuộc dự án, Calvin chỉ đang tư vấn trong vai trò của mình.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này HOÀN TẤT bộ bốn câu về chiến lược ứng phó rủi ro trong bộ đề. ⚠ Bảng tổng hợp đầy đủ: | Câu | Lô | Tình huống | Khoá | |---|---|---|---| | ⚠ #25792 | ⚠ 181 | ⚠ 1/100.000 áo lỗi, không kiểm hết, hoàn tiền khi có khiếu nại | ⚠ ACCEPT | | ⚠ #25807 | ⚠ 181 | ⚠ tăng phí bảo hiểm cho đội xe | ⚠ TRANSFER | | ⚠ #25808 | ⚠ 181 | ⚠ giữ máy chủ cũ làm dự phòng | ⚠ MITIGATE | | ⚠ #25846 | ⚠ 182 | ⚠ dời phát hành cho tới khi sửa xong lỗi | ⚠ AVOID | ⚠ Bốn khoá khác nhau, đều ĐÚNG, và cùng nhau phủ đủ bốn chiến lược chính. ⚠ Cách phân biệt tuyệt đối: hỏi xem sau hành động đó, rủi ro CÒN CÓ THỂ XẢY RA không — ⚠ không còn → AVOID; còn nhưng nhẹ hơn → MITIGATE; còn nguyên nhưng người khác trả → TRANSFER; còn nguyên và mình chịu → ACCEPT.

⚠ Năm chiến lược ứng phó mối đe doạ — bảng cuối: | Chiến lược | Sau hành động, rủi ro còn không | Ví dụ trong bộ đề | |---|---|---| | ⚠ Avoid | ⚠ KHÔNG còn khả năng xảy ra | ⚠ #25846 | | ⚠ Transfer | ⚠ còn, nhưng bên thứ ba chịu hậu quả | ⚠ #25807 | | ⚠ Mitigate | ⚠ còn, nhưng nhẹ hơn hoặc ít khả năng hơn | ⚠ #25808 | | ⚠ Accept | ⚠ còn nguyên, ta tự chịu | ⚠ #25792 | | ⚠ Escalate | ⚠ chuyển quyền xử lý ra ngoài phạm vi dự án | |

Từ khoá nhận diện:

"dừng lại, không làm, dời cho tới khi an toàn" → ⚠ AVOID "giảm xác suất hoặc giảm thiệt hại" → ⚠ MITIGATE "bảo hiểm, hợp đồng chuyển rủi ro" → ⚠ TRANSFER "chấp nhận và chuẩn bị ứng phó" → ⚠ ACCEPT

⚠ Cơ sở quyết định của Calvin Cơ sở
⚠ So sánh THIỆT HẠI UY TÍN với CHI PHÍ dời lịch
⚠ Kết luận: thiệt hại uy tín LỚN HƠN
⚠ Khách hàng là các công ty LỚN ⚠ mất uy tín với họ ảnh hưởng lâu dài
⚠ Lỗi được mô tả là "debilitating" — rất nghiêm trọng
⚠ Đây là ⚠ phân tích chi phí – lợi ích để chọn chiến lược, không phải quyết định cảm tính
⚠ Vì sao né tránh phù hợp với rủi ro NGHIÊM TRỌNG Lý do
⚠ Giảm nhẹ chỉ làm rủi ro nhỏ đi, không loại bỏ
⚠ Với lỗi nghiêm trọng, ngay cả xác suất nhỏ cũng không chấp nhận được
⚠ Uy tín mất đi rất khó mua lại
⚠ Liên hệ ⚠ xem câu #25688 ở lô 179 — rủi ro có thể làm dự án THẤT BẠI thì phải né tránh, không chỉ giảm nhẹ
⚠ Cái giá của việc né tránh cần được ghi nhận Cái giá
⚠ Chậm ra mắt, mất mùa mua sắm
⚠ Có thể mất doanh thu và cơ hội thị trường
⚠ Đối thủ có thể ra mắt trước
⚠ Đây là ⚠ RỦI RO THỨ CẤP sinh ra từ chính biện pháp ứng phó — phải ghi vào risk register và theo dõi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sau biện pháp này, rủi ro còn khả năng xảy ra không | ⚠ câu hỏi phân biệt chắc chắn nhất | | Biện pháp có sinh rủi ro mới không | ⚠ secondary risk | | Cái giá của biện pháp có được cân nhắc và ghi nhận không | |

Và nguyên tắc chọn chiến lược mà bốn câu trong bộ này cùng dạy: mức độ phản ứng phải tương xứng với mức độ rủi ro — và với rủi ro huỷ hoại uy tín, chỉ có né tránh mới đủ.

Câu 125 Process
Lester finds out that his company is going to have a terrible financial year. Several departments are anticipating layoffs, including a location where Lester's fellow project managers work. All the project managers start a text message thread to discuss how the layoffs could affect their teams and plan to pool resources. After several rounds of text messages, they come to an informal understanding. This is an example of what kind of communication?
  1. A Downward
  2. B Neutral
  3. C Horizontal
  4. D Upward
Xem giải thích

Đáp án

C — Horizontal (giao tiếp theo chiều NGANG).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Những người trao đổi đều là QUẢN LÝ DỰ ÁN | ⚠ cùng cấp bậc trong tổ chức | | ⚠ Họ bàn với NHAU, không báo lên trên hay xuống dưới | | | ⚠ Mục đích: phối hợp và chia sẻ nguồn lực | | | ⚠ Kết luận | ⚠ giao tiếp giữa những người ĐỒNG CẤP = giao tiếp ngang |

⚠ Ba chiều giao tiếp trong tổ chức: | Chiều | Nghĩa | Ví dụ | |---|---|---| | ⚠ UPWARD — lên trên | ⚠ báo cáo cho cấp trên và bên liên quan cấp cao | ⚠ báo cáo trạng thái cho nhà tài trợ | | ⚠ DOWNWARD — xuống dưới | ⚠ truyền đạt tới đội và cấp dưới | ⚠ giao việc, phổ biến kế hoạch | | ⚠ HORIZONTAL — ngang | ⚠ giữa những người ĐỒNG CẤP | ⚠ CÂU NÀY |

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

  • A (Downward) — ⚠ là giao tiếp xuống cấp dưới; ⚠ các quản lý dự án là đồng cấp với nhau.

  • D (Upward) — ⚠ là báo cáo lên cấp trên; ⚠ họ đang không báo cáo cho ai.

  • B (Neutral) — ⚠ KHÔNG phải một chiều giao tiếp trong tổ chức.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25689 ở lô 179 về bốn HƯỚNG ẢNH HƯỞNG của bên liên quan — ⚠ upward, downward, outward, SIDEWARD. ⚠ "Sideward" trong mô hình hướng ảnh hưởng chính là "horizontal" trong phân loại giao tiếp — cùng một ý.

⚠ So sánh hai mô hình: | Mô hình | Các hướng | |---|---| | ⚠ Chiều GIAO TIẾP | ⚠ upward, downward, horizontal | | ⚠ Hướng ẢNH HƯỞNG của bên liên quan (PMBOK) | ⚠ upward, downward, outward, SIDEWARD | | ⚠ Điểm khác | ⚠ mô hình bên liên quan có thêm OUTWARD — nhóm ngoài tổ chức như nhà cung cấp, cơ quan quản lý |

Từ khoá nhận diện:

"giữa các quản lý dự án đồng cấp" → ⚠ horizontal / sideward "báo cáo cho nhà tài trợ" → ⚠ upward "phổ biến cho đội" → ⚠ downward "nhà cung cấp, cơ quan quản lý" → ⚠ outward

⚠ Vì sao giao tiếp NGANG lại quan trọng Lý do
⚠ Các dự án CẠNH TRANH cùng nguồn lực ⚠ đặc biệt trong tổ chức ma trận
⚠ Chia sẻ bài học kinh nghiệm giữa các dự án
⚠ Phối hợp khi có phụ thuộc chéo
⚠ Hỗ trợ nhau về mặt chuyên môn và tinh thần
⚠ Hay bị bỏ quên ⚠ rất nhiều PM chỉ chăm chăm báo cáo lên trên và giao việc xuống dưới
⚠ Về tính CHÍNH THỨC của cuộc trao đổi này Đặc điểm
⚠ Qua tin nhắn — kênh KHÔNG CHÍNH THỨC
⚠ Dẫn tới "hiểu ngầm không chính thức" ⚠ informal understanding
⚠ Nhanh và linh hoạt
⚠ Rủi ro ⚠ thoả thuận không chính thức về chia sẻ nguồn lực có thể KHÔNG được tổ chức công nhận
⚠ Nên làm gì tiếp ⚠ nếu thoả thuận có giá trị thật thì cần chính thức hoá và báo cáo lên cấp có thẩm quyền

⚠ Bốn dạng giao tiếp theo tính chính thức: | Dạng | Ví dụ | |---|---| | ⚠ Formal written | ⚠ hợp đồng, điều lệ, kế hoạch dự án, báo cáo chính thức | | ⚠ Formal verbal | ⚠ thuyết trình, họp chính thức có biên bản | | ⚠ Informal written | ⚠ email, tin nhắn, ghi chú — TÌNH HUỐNG NÀY | | ⚠ Informal verbal | ⚠ trò chuyện, gọi điện nhanh |

⚠ Bối cảnh nhạy cảm của tình huống Lưu ý
⚠ Chủ đề là CẮT GIẢM NHÂN SỰ — rất nhạy cảm
⚠ Trao đổi qua tin nhắn để lại DẤU VẾT ⚠ có thể bị đọc lại trong bối cảnh khác
⚠ Thông tin chưa chính thức, có thể sai
⚠ Lời khuyên ⚠ với chủ đề nhân sự nhạy cảm, nên trao đổi trực tiếp và tránh phán đoán bằng văn bản

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có trao đổi với các quản lý dự án khác không | ⚠ hay chỉ báo cáo lên và giao xuống | | Thoả thuận không chính thức có được chính thức hoá không | | | Kênh bạn dùng có phù hợp với độ nhạy cảm của chủ đề không | |

Và giá trị của giao tiếp ngang mà nhiều PM bỏ qua: đồng nghiệp cùng cấp là người hiểu vấn đề của bạn nhất, và cũng là người cạnh tranh nguồn lực với bạn nhiều nhất. Cả hai lý do đều khiến việc giữ liên lạc với họ trở nên quan trọng.

Câu 126 Process
Henry takes each user story and creates polished documents that explain the details in a diagram. Henry’s agile coach will likely tell him that
  1. A Agile modeling is a great tool that plays a critical role in every user story.
  2. B There should not be a focus on polished models in an agile project.
  3. C Models should never be produced in an agile project.
  4. D Models provide the most benefit at the end of a project.
Xem giải thích

Đáp án

B — KHÔNG nên tập trung vào các mô hình được TRAU CHUỐT trong dự án agile.

Vì sao đúng

⚠ Vì sao trau chuốt mô hình là lãng phí trong agile: | Lý do | Nội dung | |---|---| | ⚠ Mô hình là CÔNG CỤ GIAO TIẾP, không phải sản phẩm | | | ⚠ Yêu cầu THAY ĐỔI liên tục — mô hình đẹp nhanh lỗi thời | | | ⚠ Thời gian trau chuốt là thời gian KHÔNG tạo giá trị | ⚠ một dạng lãng phí theo Lean | | ⚠ Bản vẽ tay trên bảng thường đủ để cả đội hiểu nhau | | | ⚠ Tuyên ngôn agile | ⚠ "phần mềm chạy được HƠN tài liệu đầy đủ toàn diện" |

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

  • C (KHÔNG BAO GIỜ nên tạo mô hình trong dự án agile) — ⚠ SAI vì QUÁ TUYỆT ĐỐI: ⚠ agile ⚠ KHÔNG cấm mô hình; ⚠ mô hình nhanh và vừa đủ rất hữu ích — ⚠ vấn đề chỉ là mức độ trau chuốt.

  • A (mô hình agile đóng vai trò then chốt trong MỌI user story) — ⚠ cũng quá tuyệt đối theo hướng ngược lại: ⚠ nhiều story đơn giản không cần mô hình nào.

  • D (mô hình có giá trị nhất ở CUỐI dự án) — ⚠ NGƯỢC: ⚠ mô hình có giá trị nhất khi ⚠ đang bàn bạc và thiết kế, tức là TRƯỚC khi làm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25768 ở lô 180 (wireframe cố ý vẽ thô để bàn về cấu trúc, không bàn về màu sắc) và câu #25837 ở lô này (trò chuyện trực tiếp hiệu quả nhất). ⚠ Ba câu cùng một nguyên tắc: công cụ phải phục vụ giao tiếp, không phải để trưng bày.

⚠ Nguyên tắc "vừa đủ" trong agile: | Khái niệm | Nội dung | |---|---| | ⚠ Barely Sufficient / Just Enough | ⚠ làm vừa đủ để phục vụ mục đích, không hơn | | ⚠ Áp dụng cho tài liệu, mô hình, quy trình, kế hoạch | | | ⚠ "Vừa đủ" là mức KHÁC NHAU với mỗi đội và mỗi bối cảnh | | | ⚠ Sai lầm hai đầu | ⚠ quá nhiều là lãng phí; quá ít là gây hiểu nhầm |

Từ khoá nhận diện:

"mô hình được trau chuốt, tài liệu đẹp" → ⚠ lãng phí trong agile "không bao giờ tạo mô hình" → ⚠ quá tuyệt đối, SAI "mô hình cho mọi user story" → ⚠ cũng quá tuyệt đối "vừa đủ để trao đổi" → ⚠ nguyên tắc đúng

⚠ Khi nào mô hình VẪN đáng làm trong agile Trường hợp
⚠ Kiến trúc hệ thống phức tạp cần cả đội hiểu chung
⚠ Luồng nghiệp vụ nhiều nhánh khó diễn đạt bằng lời
⚠ Giao diện người dùng — wireframe ⚠ xem câu #25768
⚠ Mô hình dữ liệu cho hệ thống nhiều thực thể
⚠ Tài liệu bắt buộc theo quy định pháp lý
⚠ Nguyên tắc ⚠ mô hình khi nó GIÚP HIỂU NHANH HƠN so với việc nói chuyện
⚠ Henry nên điều chỉnh thế nào Cách
⚠ Vẽ NHANH trên bảng trắng khi đang bàn ⚠ chụp ảnh lại là đủ
⚠ Chỉ trau chuốt mô hình khi nó phải TỒN TẠI LÂU DÀI ⚠ kiến trúc tổng thể, tài liệu bàn giao cho vận hành
⚠ Hỏi: ai sẽ đọc mô hình này và họ cần gì từ nó
⚠ Dành thời gian tiết kiệm được cho việc trao đổi với đội
⚠ Điều Henry làm ĐÚNG ⚠ anh ấy đang cố làm rõ chi tiết — chỉ là chọn sai công cụ và mức đầu tư
⚠ Bảy loại lãng phí Lean — mô hình quá trau chuốt thuộc loại nào Loại
⚠ Extra processes ⚠ thủ tục thừa không ai cần
⚠ Extra features ⚠ trau chuốt vượt mức cần thiết
⚠ Partially done work ⚠ nếu mô hình lỗi thời trước khi được dùng
⚠ Liên hệ ⚠ xem câu #25786 ở lô 181 về bảy loại lãng phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai sẽ đọc mô hình này và họ cần gì | | | Mô hình còn đúng sau bao lâu | ⚠ lỗi thời nhanh thì đừng trau chuốt | | Vẽ tay có đủ để đội hiểu không | ⚠ nếu đủ thì dừng ở đó |

Và câu hỏi để quyết mức đầu tư vào bất kỳ tài liệu nào: nó sẽ được dùng bao nhiêu lần và sống được bao lâu. Tài liệu dùng một lần trong một buổi họp không đáng được trau chuốt như tài liệu bàn giao cho đội vận hành.

Câu 127 Business Environment
Mike has recently taken over as a project manager at a horticultural organization. He is assigned to a project that has been ongoing for over four years. Within two weeks, Mike notices that there has been a high turnover rate for team members during the project. To accommodate these changes, Mike explores agile methodologies. What action should Mike take to shift to a hybrid approach?
  1. A Review a historically similar project to determine the current project's feasibility.
  2. B Remove the number of team members down to nine individuals, plus or minus two.
  3. C Evaluate the benefits of incorporating agile practices.
  4. D Ensure the organization can continue funding the project.
Xem giải thích

Đáp án

C — ĐÁNH GIÁ LỢI ÍCH của việc đưa các thực hành agile vào dự án.

Vì sao đúng

⚠ Vì sao phải đánh giá trước khi chuyển đổi: | Lý do | Nội dung | |---|---| | ⚠ Chuyển sang cách LAI là một THAY ĐỔI LỚN | ⚠ ảnh hưởng cách làm việc của cả đội | | ⚠ Phải biết agile giải quyết được vấn đề gì cho dự án này | | | ⚠ Dự án đã chạy HƠN BỐN NĂM | ⚠ đổi cách làm giữa chừng có rủi ro thật | | ⚠ Không phải mọi dự án đều hợp với agile | | | ⚠ Kết luận | ⚠ đánh giá lợi ích và chi phí trước, quyết định sau — nguyên tắc chung của mọi thay đổi |

⚠ Mike cần đánh giá những gì: | Câu hỏi | Nội dung | |---|---| | ⚠ Vấn đề THẬT của dự án là gì | ⚠ tỷ lệ thay người cao — nhưng VÌ SAO? | | ⚠ Agile có giải quyết được vấn đề đó không | | | ⚠ Phần nào của dự án phù hợp với agile, phần nào không | | | ⚠ Đội và tổ chức đã sẵn sàng chưa | | | ⚠ Chi phí chuyển đổi so với lợi ích | |

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

  • B (giảm số thành viên xuống chín người cộng trừ hai) — ⚠ áp dụng máy móc một con số: ⚠ quy mô đội Scrum là ⚠ HƯỚNG DẪN, không phải luật; ⚠ và cắt người mà chưa biết lý do là hành động cực đoan.

  • A (rà soát dự án tương tự trong quá khứ) — ⚠ hữu ích nhưng không phải bước đầu tiên; ⚠ và không giải quyết câu hỏi "agile có phù hợp không".

  • D (đảm bảo tổ chức còn tài trợ được dự án) — ⚠ là vấn đề TÀI CHÍNH, ⚠ không liên quan tới việc chuyển sang cách tiếp cận lai.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25747 ở lô 180 (đội bất mãn vì bị ép dùng Scrum) và câu #25805 ở lô 181 (bên liên quan chưa hiểu agile). ⚠ Ba câu cùng chủ đề chuyển đổi sang agile — và cùng một bài học: không áp đặt, phải hiểu và thuyết phục.

⚠ Vòng đời LAI — hybrid: | Đặc điểm | Nội dung | |---|---| | ⚠ Kết hợp yếu tố dự đoán và thích ứng | | | ⚠ Phần ỔN ĐỊNH làm theo cách dự đoán | ⚠ hạ tầng, tuân thủ pháp lý, mua sắm | | ⚠ Phần BIẾN ĐỘNG làm theo vòng lặp | ⚠ phát triển tính năng, thiết kế trải nghiệm | | ⚠ Rất phổ biến trong thực tế | ⚠ ít tổ chức chạy agile thuần hoặc dự đoán thuần | | ⚠ Liên hệ | ⚠ xem câu #25805 ở lô 181 — Wendy đề xuất đúng mô hình này |

Từ khoá nhận diện:

"chuyển sang cách tiếp cận mới" → ⚠ đánh giá lợi ích và chi phí trước "cắt đội xuống 9±2 người" → ⚠ áp dụng máy móc con số, thường sai "tỷ lệ thay người cao" → ⚠ TRIỆU CHỨNG, phải tìm nguyên nhân gốc "cách tiếp cận lai" → ⚠ kết hợp dự đoán và thích ứng theo từng phần

⚠ Vấn đề thật có thể nằm ở đâu Nguyên nhân
⚠ Dự án kéo dài 4 năm — kiệt sức và chán
⚠ Không thấy kết quả rõ ràng ⚠ agile CÓ THỂ giúp: giao được phần dùng được sớm
⚠ Quản lý trước có vấn đề
⚠ Cơ hội nghề nghiệp tốt hơn ở nơi khác ⚠ agile KHÔNG giúp gì cho vấn đề này
⚠ Bài học ⚠ agile không phải thuốc chữa bách bệnh — phải biết bệnh trước
⚠ Nếu quyết định chuyển đổi thì làm gì Bước
⚠ Bắt đầu NHỎ — thử một phần của dự án
⚠ ĐÀO TẠO đội trước khi áp dụng ⚠ xem câu #25747 ở lô 180
⚠ Giải thích LÝ DO cho đội, để họ tham gia quyết định
⚠ Giữ những gì đang chạy tốt
⚠ Đo kết quả sau vài vòng lặp rồi điều chỉnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã biết nguyên nhân gốc của vấn đề chưa | | | Agile có giải quyết đúng vấn đề đó không | | | Đội có được hỏi ý kiến không | |

Và cạm bẫy phổ biến nhất khi một PM mới nhận dự án có vấn đề: áp dụng ngay phương pháp mà mình quen. Chẩn đoán trước, kê đơn sau.

Câu 128 People
Oscar is the scrum master for Project X, which is in its fifth iteration. Recently several members of his team were sent to a specialized training camp to improve their skills. How can Oscar best determine if their training was successful?
  1. A By checking their exam scores
  2. B By asking their managers
  3. C By tracking how their performance improves
  4. D By asking them how training went
Xem giải thích

Đáp án

C — Bằng cách THEO DÕI mức độ CẢI THIỆN HIỆU SUẤT của họ.

Vì sao đúng

⚠ Vì sao đo bằng hiệu suất là cách tốt nhất: | Lý do | Nội dung | |---|---| | ⚠ Mục đích của đào tạo là NÂNG NĂNG LỰC LÀM VIỆC | ⚠ không phải để có chứng chỉ | | ⚠ Hiệu suất là bằng chứng KHÁCH QUAN, đo được | | | ⚠ Cho biết kiến thức có được ÁP DỤNG vào công việc thật không | | | ⚠ Trong agile có sẵn dữ liệu để đo | ⚠ velocity, throughput, số lỗi, thời gian chu kỳ | | ⚠ Kết luận | ⚠ đào tạo thành công khi công việc tốt lên, không phải khi học viên hài lòng |

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

  • A (xem điểm thi của họ) — ⚠ chỉ đo được KIẾN THỨC, ⚠ không đo được khả năng ÁP DỤNG; ⚠ người thi điểm cao vẫn có thể không dùng được vào việc thật.

  • D (hỏi họ buổi đào tạo thế nào) — ⚠ chỉ đo PHẢN ỨNG và cảm nhận; ⚠ khoá học vui không đồng nghĩa với khoá học hiệu quả.

  • B (hỏi quản lý của họ) — ⚠ ý kiến chủ quan của bên thứ ba; ⚠ và trong Scrum, đội tự tổ chức nên quản lý chức năng không quan sát công việc hằng ngày.

Ghi nhớ

⚠ Mô hình Kirkpatrick — bốn mức đánh giá đào tạo: | Mức | Đo gì | Phương án tương ứng | |---|---|---| | ⚠ 1 — REACTION | ⚠ học viên thấy khoá học thế nào | ⚠ phương án D | | ⚠ 2 — LEARNING | ⚠ họ tiếp thu được kiến thức gì | ⚠ phương án A — điểm thi | | ⚠ 3 — BEHAVIOR | ⚠ họ có THAY ĐỔI cách làm việc không | ⚠ PHƯƠNG ÁN C | | ⚠ 4 — RESULTS | ⚠ kết quả kinh doanh có tốt lên không | ⚠ mức cao nhất | | ⚠ Mức càng cao | ⚠ càng khó đo nhưng càng có ý nghĩa |

Từ khoá nhận diện:

"cải thiện hiệu suất công việc" → ⚠ mức 3–4, cách đo tốt nhất "điểm thi" → ⚠ mức 2, chỉ đo kiến thức "hỏi cảm nhận" → ⚠ mức 1, yếu nhất "kết quả kinh doanh" → ⚠ mức 4, khó đo nhất

⚠ Oscar có thể đo bằng chỉ số nào Chỉ số
⚠ VELOCITY của đội qua các vòng lặp ⚠ so trước và sau đào tạo
⚠ Số LỖI tìm thấy sau khi giao ⚠ escaped defects giảm không
⚠ CYCLE TIME — thời gian hoàn thành một hạng mục
⚠ Số lần phải nhờ người khác giúp về kỹ năng đó
⚠ Chất lượng mã qua rà soát
⚠ Lưu ý ⚠ cần vài vòng lặp mới thấy xu hướng — đừng kết luận sau một sprint
⚠ Cạm bẫy khi đo hiệu quả đào tạo Cạm bẫy
⚠ Nhiều yếu tố khác cùng ảnh hưởng tới hiệu suất ⚠ khó tách riêng tác động của đào tạo
⚠ Hiệu suất có thể GIẢM ngay sau đào tạo ⚠ người ta đang tập cách làm mới
⚠ Kỹ năng mềm rất khó đo bằng số
⚠ Cách giảm ⚠ kết hợp nhiều nguồn: số liệu, quan sát, phản hồi đồng nghiệp
⚠ Vai trò của Oscar ở đây Vai trò
⚠ Scrum Master theo dõi sự PHÁT TRIỂN của đội
⚠ Không đánh giá hiệu suất CÁ NHÂN để xếp loại ⚠ đó là việc của quản lý chức năng
⚠ Mục đích là biết đầu tư đào tạo có đáng không ⚠ để quyết định có tiếp tục đầu tư nữa hay không
⚠ Liên hệ ⚠ xem câu #25776 ở lô 180 — đào tạo là đầu tư, và mọi khoản đầu tư đều cần đo hiệu quả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có số liệu TRƯỚC đào tạo để so sánh không | ⚠ không có mốc gốc thì không đo được cải thiện | | Bạn đo ở mức nào trong bốn mức Kirkpatrick | | | Đã cho đủ thời gian để kỹ năng mới phát huy chưa | |

Và câu hỏi phân biệt đào tạo hiệu quả với đào tạo hình thức: công việc có tốt lên không. Học viên hài lòng và thi điểm cao là dấu hiệu tốt, nhưng chưa phải bằng chứng.

Câu 129 People
Tracy Lynn is on a project team with the Blue Arrow Corporation and she is leading a project to develop an online catalog for customers. Nan has been working overtime to ensure a specific feature will be completed on time. The feature will recommend related items for customers when they add items to their online shopping cart. This requirement is taking a considerable amount of time and may delay the project's go-live date. Nan and Tracy Lynn are in a status update meeting with the key stakeholders to discuss the requirements and the timeline. The stakeholders sound upset that the project may not make its deadline. The project manager explains that Nan is putting in extra work, that the schedule will be met on time or very close to its deadline, and that the problem is not as big as it seems. What strategy is the project manager using?
  1. A Collaborating
  2. B Smoothing
  3. C Forcing
  4. D Withdrawing
Xem giải thích

Đáp án

B — Smoothing (xoa dịu).

Vì sao đúng

⚠ Dấu hiệu smoothing trong lời của quản lý dự án: | Câu nói | Ý nghĩa | |---|---| | ⚠ "Nan đang làm thêm giờ" | ⚠ nhấn mạnh nỗ lực để trấn an | | ⚠ "Lịch sẽ được đảm bảo hoặc rất sát hạn" | ⚠ giảm nhẹ mức nghiêm trọng | | ⚠ "Vấn đề không lớn như vẻ ngoài" | ⚠ câu QUYẾT ĐỊNH — làm dịu mối lo | | ⚠ Kết luận | ⚠ nhấn mạnh điểm tích cực, giảm nhẹ khác biệt — đúng định nghĩa smoothing |

⚠ Smoothing là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Nhấn mạnh ĐIỂM CHUNG, giảm nhẹ KHÁC BIỆT | | | ⚠ Làm dịu căng thẳng TẠM THỜI | | | ⚠ KHÔNG giải quyết vấn đề gốc | | | ⚠ Có thể mua thêm thời gian để tìm giải pháp thật | | | ⚠ Còn gọi là | ⚠ accommodate — nhân nhượng |

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

  • A (Collaborating) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ hợp tác là ⚠ CÙNG PHÂN TÍCH để tìm giải pháp tốt cho tất cả; ⚠ ở đây quản lý dự án ⚠ chỉ TRẤN AN, không mời bên liên quan cùng tìm phương án.

  • C (Forcing) — ⚠ là áp đặt quyết định của mình; ⚠ quản lý dự án không ép ai làm gì.

  • D (Withdrawing) — ⚠ là né tránh, không nói tới vấn đề; ⚠ ở đây vấn đề ĐƯỢC nói tới, chỉ là được giảm nhẹ.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này HOÀN TẤT bộ NĂM câu về chiến lược giải quyết xung đột trong bộ đề — đủ cả năm chiến lược. ⚠ Bảng tổng hợp: | Câu | Lô | Tình huống | Khoá | |---|---|---|---| | ⚠ #25672 | ⚠ 178 | ⚠ Kelly dùng thâm niên để áp quyết định | ⚠ FORCING | | ⚠ #25775 | ⚠ 180 | ⚠ bên liên quan mở lại vấn đề đã chốt | ⚠ AVOIDING | | ⚠ #25785 | ⚠ 181 | ⚠ mời nhà phân tích đi cà phê để hiểu và cùng giải quyết | ⚠ COLLABORATING | | ⚠ #25814 | ⚠ 181 | ⚠ người dẫn trước tìm giải pháp làm vừa lòng mọi người | ⚠ COMPROMISING | | ⚠ #25851 | ⚠ 182 | ⚠ trấn an bên liên quan, giảm nhẹ mức nghiêm trọng | ⚠ SMOOTHING | ⚠ Năm khoá khác nhau, đều ĐÚNG, phủ đủ năm chiến lược. ⚠ Đây là bộ câu hoàn chỉnh nhất về chủ đề xung đột trong toàn bộ ngân hàng đề — nên học chung một lượt.

⚠ Năm chiến lược — bảng cuối cùng: | Chiến lược | Nhận ra bằng | Kết quả | |---|---|---| | ⚠ Collaborate / Problem Solve | ⚠ cùng phân tích, tìm giải pháp tốt hơn cho tất cả | ⚠ WIN-WIN, tốt nhất | | ⚠ Compromise | ⚠ mỗi bên nhượng bộ một phần | ⚠ LOSE-LOSE | | ⚠ Smooth / Accommodate | ⚠ nhấn mạnh điểm chung, giảm nhẹ khác biệt | ⚠ TẠM THỜI — CÂU NÀY | | ⚠ Force / Direct | ⚠ áp đặt quan điểm của mình | ⚠ WIN-LOSE | | ⚠ Withdraw / Avoid | ⚠ né tránh, hoãn lại | ⚠ không giải quyết, thấp nhất |

Từ khoá nhận diện:

"vấn đề không lớn như vẻ ngoài, mọi thứ sẽ ổn" → ⚠ SMOOTHING "cùng phân tích tìm giải pháp" → ⚠ COLLABORATING "tôi có quyền nên tôi quyết" → ⚠ FORCING "để bàn sau" → ⚠ WITHDRAWING "chia đôi, mỗi bên nhường" → ⚠ COMPROMISING

⚠ Khi nào smoothing HỢP LÝ Trường hợp
⚠ Cần GIỮ QUAN HỆ trong lúc căng thẳng
⚠ Vấn đề nhỏ hơn nhiều so với quan hệ
⚠ Cần MUA THÊM THỜI GIAN để chuẩn bị giải pháp thật
⚠ Đang trong cuộc họp không phải chỗ để bàn sâu ⚠ có thể áp dụng cho tình huống này
⚠ KHÔNG hợp lý khi ⚠ dùng nó để tránh nói ra sự thật về nguy cơ trễ hạn
⚠ Rủi ro trong cách xử lý của quản lý dự án Rủi ro
⚠ Nếu dự án TRỄ THẬT thì bên liên quan sẽ mất niềm tin nặng hơn
⚠ "Sẽ đúng hạn hoặc rất sát" là cách nói MƠ HỒ
⚠ Nan làm thêm giờ không phải giải pháp bền vững ⚠ xem câu #25612 ở lô 177 — làm quá sức dẫn tới làm lại
⚠ Cách làm tốt hơn ⚠ nêu số liệu cụ thể, các phương án, và rủi ro thật — tức là chuyển sang COLLABORATING
⚠ Cách xử lý tốt hơn cho tình huống này Cách
⚠ Trình bày SỐ LIỆU thật về tiến độ
⚠ Nêu rõ khả năng trễ và mức trễ dự kiến
⚠ Đưa ra các phương án: giảm phạm vi, dời hạn, thêm nguồn lực
⚠ Mời bên liên quan cùng chọn ⚠ đây mới là hợp tác
⚠ Nguyên tắc ⚠ tin xấu nói sớm — xem câu #25736 ở lô 180

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang trấn an hay đang giải quyết | | | Bên liên quan có nhận được thông tin đủ để quyết định không | | | Nếu dự đoán lạc quan không thành thì sao | |

Và ranh giới mỏng của smoothing: trấn an để giữ bình tĩnh là hợp lý; trấn an để tránh nói ra rủi ro thật là nguy hiểm. Ở đây có dấu hiệu của vế thứ hai.

Câu 130 Process
In agile development, teams tend to have more effective sprints as the project matures with each increment handed off and accepted by the user groups. What is the main reason behind the agile team's continuous improvement?
  1. A Use of feedback loops
  2. B Efficient use of resources
  3. C Ability to change the scope
  4. D Servant leadership
Xem giải thích

Đáp án

A — Việc sử dụng các VÒNG PHẢN HỒI (feedback loops).

Vì sao đúng

⚠ Vì sao vòng phản hồi là cơ chế cải tiến liên tục: | Cơ chế | Nội dung | |---|---| | ⚠ Mỗi vòng lặp tạo ra PHẢN HỒI về sản phẩm và về cách làm việc | | | ⚠ Đội DÙNG phản hồi đó để điều chỉnh ngay vòng lặp sau | | | ⚠ Chu kỳ NGẮN nên học được nhanh | | | ⚠ Lặp đi lặp lại nên cải tiến TÍCH LUỸ | | | ⚠ Đề nói rõ | ⚠ "mỗi increment được giao và được người dùng chấp nhận" — đó chính là một vòng phản hồi hoàn chỉnh |

⚠ Các vòng phản hồi trong agile: | Vòng | Chu kỳ | Phản hồi về | |---|---|---| | ⚠ Lập trình cặp và rà soát mã | ⚠ liên tục | ⚠ chất lượng mã | | ⚠ Tích hợp và kiểm thử tự động | ⚠ vài phút tới vài giờ | ⚠ lỗi kỹ thuật | | ⚠ Daily standup | ⚠ hằng ngày | ⚠ tiến độ và trở ngại | | ⚠ Sprint review | ⚠ mỗi vòng lặp | ⚠ SẢN PHẨM — người dùng nghĩ gì | | ⚠ RETROSPECTIVE | ⚠ mỗi vòng lặp | ⚠ QUY TRÌNH — cách làm việc của đội | | ⚠ Vòng càng NGẮN | ⚠ càng sửa sai sớm và rẻ |

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

  • D (Servant leadership) — ⚠ là PHONG CÁCH LÃNH ĐẠO hỗ trợ cải tiến, ⚠ nhưng không phải CƠ CHẾ tạo ra cải tiến.

  • C (khả năng thay đổi phạm vi) — ⚠ là ĐẶC ĐIỂM của agile, ⚠ không phải nguyên nhân khiến đội làm việc tốt hơn qua từng sprint.

  • B (sử dụng nguồn lực hiệu quả) — ⚠ là KẾT QUẢ có thể có, ⚠ không phải nguyên nhân.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25806 ở lô 181 (PDCA — trở ngại lộ ra ở bước CHECK) và câu #25842 ở lô này (rủi ro giảm nhanh nhờ học sớm). ⚠ Ba câu cùng một cơ chế nền: học từ thực tế rồi điều chỉnh.

⚠ Vòng phản hồi và PDCA: | PDCA | Trong một sprint | |---|---| | ⚠ PLAN | ⚠ sprint planning | | ⚠ DO | ⚠ làm việc trong sprint | | ⚠ CHECK | ⚠ sprint review và retrospective | | ⚠ ACT | ⚠ điều chỉnh backlog và cách làm việc | | ⚠ Mỗi sprint | ⚠ là một vòng PDCA hoàn chỉnh — đó là lý do đội tốt lên qua từng sprint |

Từ khoá nhận diện:

"đội tốt lên qua từng vòng lặp" → ⚠ vòng phản hồi "nhìn lại và điều chỉnh" → ⚠ inspect and adapt — nguyên tắc nền của Scrum "lãnh đạo phục vụ" → ⚠ phong cách hỗ trợ, không phải cơ chế "thay đổi phạm vi được" → ⚠ đặc điểm, không phải nguyên nhân cải tiến

⚠ Điều kiện để vòng phản hồi hoạt động Điều kiện
⚠ Phản hồi phải ĐẾN ĐƯỢC người có thể hành động
⚠ Phải có HÀNH ĐỘNG cụ thể sau mỗi vòng ⚠ retrospective không dẫn tới thay đổi thì vòng lặp đứt
⚠ Chu kỳ phải đủ NGẮN để còn kịp điều chỉnh
⚠ Môi trường AN TOÀN để nói thật
⚠ Liên hệ ⚠ xem câu #25797 ở lô 181 — người ta lơ đãng trong retrospective vì đã nói mà không có gì thay đổi
⚠ Nguyên tắc "Inspect and Adapt" của Scrum Nội dung
⚠ Ba trụ cột của Scrum: MINH BẠCH, THANH TRA, THÍCH ỨNG
⚠ Minh bạch: ai cũng thấy được tình hình thật
⚠ Thanh tra: kiểm tra thường xuyên hiện vật và tiến độ
⚠ Thích ứng: điều chỉnh ngay khi phát hiện lệch
⚠ Ba trụ cột này ⚠ chính là cách diễn đạt khác của vòng phản hồi
⚠ Vì sao đội mới thường chậm rồi nhanh dần Cơ chế
⚠ Vòng 1–2: học cách làm việc với nhau ⚠ giai đoạn Forming và Storming
⚠ Vòng 3–5: hình thành chuẩn mực, velocity ổn định ⚠ Norming
⚠ Từ vòng 5 trở đi: tối ưu dần ⚠ Performing
⚠ Cộng thêm ⚠ mỗi retrospective gỡ được một trở ngại — hiệu quả tích luỹ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retrospective của đội có dẫn tới hành động cụ thể không | | | Vòng phản hồi ngắn nhất của bạn dài bao lâu | ⚠ càng ngắn càng học nhanh | | Phản hồi từ người dùng có tới được đội không | |

Và cơ chế đơn giản giải thích toàn bộ sức mạnh của agile: làm, xem kết quả, sửa, làm lại. Cải tiến liên tục không đến từ nỗ lực nhiều hơn mà đến từ việc lặp lại chu trình đó đủ nhanh.