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

Tìm thấy 720 câu.

Câu 61 People
Kyle is a project manager for IT Humanities Organization and was assigned to a new project to build racing drones for a client. During the individual assessments for Kyle's team members, it was determined that John excelled at aerodynamics but scored low in communication abilities. Jill scored high in aerodynamics and communication. The other four team members did not score very high on aerodynamics. Based on this assessment, Kyle should do which of the following?
  1. A Add Jill and John to the team as normal and monitor John's progress closely since he scored low on communication.
  2. B Build a team silo and put John and Jill on the same team placing Jill in charge of John.
  3. C Try to find a replacement for John regardless of his ability in aerodynamics.
  4. D Build a team silo and put John and Jill on the same team working on the same tasks.
Xem giải thích

Đáp án

A — Nhận cả Jill và John vào đội như bình thường, và THEO SÁT tiến độ của John vì anh ấy điểm giao tiếp thấp.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ John GIỎI khí động học — đúng kỹ năng dự án cần | ⚠ và bốn người còn lại đều không mạnh về mảng này | | ⚠ Điểm giao tiếp thấp là điều CẢI THIỆN ĐƯỢC | ⚠ không phải lý do loại người | | ⚠ Đánh giá cá nhân dùng để HIỂU và HỖ TRỢ, không phải để sàng lọc | | | ⚠ Theo sát là biện pháp phòng ngừa hợp lý | ⚠ phát hiện sớm nếu giao tiếp gây trở ngại | | ⚠ Kết luận | ⚠ giữ năng lực chuyên môn, quản lý điểm yếu bằng theo dõi và hỗ trợ |

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

  • C (tìm người thay John bất kể năng lực khí động học) — ⚠ SAI HẲN: ⚠ vứt bỏ đúng thứ dự án cần nhất; ⚠ và ⚠ loại người vì một điểm yếu là phản ứng cực đoan.

  • B (lập ốc đảo, đặt Jill làm sếp John) và D (lập ốc đảo, hai người làm cùng việc) — ⚠ "team silo" là cách tổ chức CÔ LẬP một nhóm khỏi phần còn lại, ⚠ đi ngược tinh thần đội đa kỹ năng; ⚠ và ⚠ cô lập người có điểm giao tiếp yếu càng làm vấn đề tệ hơn; ⚠ riêng phương án D còn ⚠ lãng phí: hai chuyên gia làm trùng một việc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25725 ở lô 179 (Samuel làm chậm — loại khỏi đội là hành động SAI), câu #25754 ở lô 179 (bên liên quan đòi đuổi người — điều tra nguyên nhân gốc trước), và câu #25771 ở lô 180 về đánh giá tính cách. ⚠ Bốn câu cùng một thông điệp: đề thi PMP gần như KHÔNG BAO GIỜ chọn phương án loại bỏ con người.

⚠ Mục đích đúng của đánh giá cá nhân và đội: | Mục đích | Nội dung | |---|---| | ⚠ Hiểu ĐIỂM MẠNH để phân công phù hợp | | | ⚠ Hiểu ĐIỂM YẾU để hỗ trợ và đào tạo | | | ⚠ Hiểu phong cách làm việc để phối hợp tốt hơn | | | ⚠ Xác định nhu cầu phát triển của đội | | | ⚠ KHÔNG dùng để | ⚠ sàng lọc, dán nhãn, hay loại người khỏi dự án |

Từ khoá nhận diện:

"điểm yếu ở một kỹ năng" → ⚠ hỗ trợ và theo dõi, không loại người "loại khỏi đội, tìm người thay" → ⚠ gần như luôn là đáp án SAI "team silo" → ⚠ cô lập nhóm, đi ngược đội đa kỹ năng "đánh giá cá nhân" → ⚠ công cụ của Develop Team, để phát triển chứ không để sàng lọc

⚠ Kyle nên hỗ trợ John thế nào Cách
⚠ Ghép cặp John với Jill ⚠ Jill giỏi cả hai mảng, có thể làm cầu nối
⚠ Giảm số kênh giao tiếp John phải xử lý ⚠ cho anh ấy một đầu mối thay vì nhiều người
⚠ Dùng kênh viết thay vì kênh nói nếu phù hợp hơn với anh ấy
⚠ Đào tạo kỹ năng giao tiếp nếu cần
⚠ Theo dõi để can thiệp sớm khi có trục trặc ⚠ chính là phần thứ hai của đáp án
⚠ Đừng ⚠ biến điểm yếu thành nhãn dán công khai
⚠ Vì sao "team silo" là ý tồi Lý do
⚠ Cô lập tri thức trong một nhóm nhỏ
⚠ Tăng rủi ro phụ thuộc nhân sự chủ chốt
⚠ Đi ngược nguyên tắc đội ĐA KỸ NĂNG của agile
⚠ Giảm cơ hội chuyển giao tri thức cho bốn người còn lại ⚠ họ đang yếu khí động học, rất cần học

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả đánh giá có được dùng để phát triển không | ⚠ hay để phân loại người | | Điểm yếu có được hỗ trợ cụ thể không | | | Tri thức chuyên môn có được lan toả trong đội không | |

Và nguyên tắc quản lý con người mà đề PMP luôn kiểm tra: quản lý điểm yếu, đừng loại bỏ con người. Một chuyên gia khí động học giỏi mà ngại nói chuyện vẫn quý hơn một người giao tiếp tốt mà không biết làm việc.

Câu 62 People
Communication is a large part of project management and project managers must be communicators. When considering virtual teams, you will need additional skills to be an effective communicator. What is the best communication tool to engage a virtual team?
  1. A A team blog that all team members can contribute to that contains team information.
  2. B Hosting web conferencing software meetings.
  3. C Emailing important notices.
  4. D Instant messaging team members daily.
Xem giải thích

Đáp án

B — Tổ chức các cuộc họp qua PHẦN MỀM HỘI NGHỊ TRUYỀN HÌNH (web conferencing).

Vì sao đúng

⚠ Vì sao hội nghị truyền hình là công cụ tốt nhất cho đội ảo: | Ưu điểm | Nội dung | |---|---| | ⚠ Là giao tiếp TƯƠNG TÁC — hai chiều, thời gian thực | ⚠ phương pháp hiệu quả nhất trong ba phương pháp của PMBOK | | ⚠ Có HÌNH ẢNH — giữ được phần giao tiếp phi ngôn ngữ | ⚠ nét mặt, cử chỉ, thái độ | | ⚠ Cho phép hỏi đáp và làm rõ NGAY LẬP TỨC | | | ⚠ Xây dựng QUAN HỆ và niềm tin | ⚠ điều mà đội ảo thiếu nhất | | ⚠ Chia sẻ màn hình, cùng làm việc trên tài liệu | | | ⚠ Kết luận | ⚠ gần nhất với việc gặp mặt trực tiếp mà đội ảo có thể có |

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

⚠ Cả ba phương án còn lại đều là giao tiếp MỘT CHIỀU hoặc kém tương tác:

  • C (gửi email các thông báo quan trọng) — ⚠ là giao tiếp ĐẨY một chiều; ⚠ không biết người ta có đọc và hiểu không.

  • A (blog chung của đội) — ⚠ là giao tiếp KÉO; ⚠ hữu ích để lưu trữ thông tin nhưng ⚠ không tạo tương tác.

  • D (nhắn tin tức thời hằng ngày) — ⚠ có tính tương tác nhưng CHỈ hợp với trao đổi NGẮN; ⚠ không phù hợp cho nội dung phức tạp; ⚠ và dễ gây gián đoạn liên tục.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25681 ở lô 178 về giao tiếp kéo (pull) và câu #25740 ở lô 180 về yếu tố ảnh hưởng giao tiếp trong dự án đa quốc gia. ⚠ Ba câu cùng nhóm kiến thức quản lý giao tiếp.

⚠ Ba phương pháp giao tiếp — xếp theo hiệu quả: | Phương pháp | Ví dụ | Hiệu quả | |---|---|---| | ⚠ INTERACTIVE — tương tác | ⚠ họp, gọi video, gọi điện, trò chuyện trực tiếp | ⚠ CAO NHẤT — CÂU NÀY | | ⚠ PUSH — đẩy | ⚠ email, báo cáo, bản tin, thư | ⚠ trung bình — đảm bảo GỬI ĐI, không đảm bảo HIỂU | | ⚠ PULL — kéo | ⚠ blog, wiki, kho tài liệu, bảng điều khiển | ⚠ thấp nhất về tương tác — nhưng tốt cho khối lượng lớn | | ⚠ Thực tế | ⚠ dùng CẢ BA, tuỳ loại thông tin |

Từ khoá nhận diện:

"đội ảo cần công cụ tốt nhất" → ⚠ hội nghị truyền hình, giao tiếp tương tác "email, bản tin" → ⚠ push, một chiều "blog, wiki, kho tài liệu" → ⚠ pull "trao đổi ngắn, nhanh" → ⚠ nhắn tin — bổ trợ, không thay thế

⚠ Thách thức riêng của đội ảo Thách thức
⚠ Mất giao tiếp PHI NGÔN NGỮ ⚠ video khắc phục được phần lớn
⚠ Khó xây dựng NIỀM TIN ⚠ thấy mặt nhau giúp rất nhiều
⚠ Lệch múi giờ
⚠ Khác biệt văn hoá và ngôn ngữ
⚠ Cảm giác bị cô lập
⚠ Cách giảm ⚠ bật camera, luân phiên giờ họp, có thời gian trò chuyện phi công việc, ghi lại quyết định bằng văn bản
⚠ Nguyên tắc dùng hội nghị truyền hình cho hiệu quả Nguyên tắc
⚠ BẬT CAMERA — nếu không thì chỉ còn là cuộc gọi thoại
⚠ Có chương trình họp gửi trước
⚠ Ghi lại QUYẾT ĐỊNH bằng văn bản sau họp ⚠ kết hợp interactive với push
⚠ Giữ họp NGẮN — mệt mỏi khi họp video là có thật
⚠ Đảm bảo ai cũng được phát biểu ⚠ người ở xa dễ bị lấn át

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội ảo của bạn có gặp mặt qua video định kỳ không | | | Quyết định trong họp có được ghi lại không | | | Có ai luôn phải họp ngoài giờ làm việc của họ không | |

Và điều quan trọng nhất với đội ảo: thấy được mặt nhau là bước đầu để tin nhau. Email và wiki truyền được thông tin, nhưng không truyền được sự tin cậy.

Câu 63 People
You are the project manager on a project where a business analyst is not comfortable with your work ethic. He feels that you should be doing more to help him gather the project requirements since there are over 900 project requirements. Instead of coming to you to discuss his feelings about your work ethic, he goes to your supervisor to complain. What do you do to resolve the conflict between you and the business analyst to assure your supervisor that the conflict between you and the business analyst will not impact the project?
  1. A Inform your supervisor that the business analyst is not equipped to do their job, and you would like to request that another business analyst replace him on the project.
  2. B Schedule a meeting with the business analyst and your supervisor to discuss the conflict.
  3. C Ask to be assigned to another project as you feel the business analyst should have come to you first to discuss why they thought you were not doing your job to assist them with gathering the requirements.
  4. D Invite the business analyst to coffee to discuss why they feel you are not carrying your weight on the project. Determine if there is anything you could do to assist them with gathering the requirements.
Xem giải thích

Đáp án

D — Mời nhà phân tích nghiệp vụ đi uống cà phê để hỏi vì sao họ cảm thấy bạn không gánh đủ phần việc, và xem có gì bạn có thể hỗ trợ.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Giải quyết XUNG ĐỘT ở mức THẤP NHẤT — trực tiếp giữa hai người | ⚠ nguyên tắc của PMBOK | | ⚠ Là chiến lược HỢP TÁC — tìm hiểu rồi cùng giải quyết | ⚠ collaborating, chiến lược tốt nhất | | ⚠ Không khí thân mật giúp cuộc trò chuyện dễ hơn | ⚠ cà phê thay vì phòng họp có cấp trên ngồi | | ⚠ Thể hiện thiện chí, không phòng thủ | | | ⚠ 900 yêu cầu là khối lượng RẤT LỚN | ⚠ có thể nhà phân tích thật sự đang quá tải — đó là vấn đề nguồn lực có thật | | ⚠ Kết quả | ⚠ vừa giải quyết xung đột, vừa có thể phát hiện một rủi ro nguồn lực thật của dự án |

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

  • B (hẹn họp ba bên với cấp trên) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe có vẻ minh bạch, ⚠ nhưng đó là LEO THANG khi chưa thử mức thấp nhất; ⚠ có cấp trên ngồi đó thì cả hai đều phòng thủ, khó nói thật.

  • A (nói với cấp trên rằng nhà phân tích không đủ năng lực và xin thay người) — ⚠ phản công cá nhân, ⚠ làm xung đột leo thang, ⚠ và ⚠ loại bỏ con người là phương án gần như luôn sai.

  • C (xin chuyển sang dự án khác) — ⚠ bỏ cuộc, ⚠ né tránh xung đột — chiến lược được đánh giá thấp nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25672 ở lô 178 về năm chiến lược giải quyết xung đột và câu #25753 ở lô 180 về xây dựng niềm tin với bên liên quan hoài nghi. ⚠ Ba câu cùng chủ đề xử lý quan hệ khó.

⚠ Năm chiến lược giải quyết xung đột: | Chiến lược | Áp dụng ở đây | |---|---| | ⚠ Collaborate / Problem Solve | ⚠ ĐÁP ÁN — cùng tìm hiểu và giải quyết, win-win | | ⚠ Compromise | ⚠ mỗi bên nhượng bộ — chưa cần tới | | ⚠ Smooth / Accommodate | ⚠ xoa dịu — không giải quyết gốc | | ⚠ Force / Direct | ⚠ phương án A gần với cái này | | ⚠ Withdraw / Avoid | ⚠ phương án C chính là cái này — thấp nhất |

Từ khoá nhận diện:

"nói chuyện trực tiếp với người kia trước" → ⚠ giải quyết ở mức thấp nhất "kéo cấp trên vào ngay" → ⚠ leo thang quá sớm "xin thay người kia" → ⚠ phản công, gần như luôn sai "xin chuyển dự án" → ⚠ bỏ cuộc, luôn sai

⚠ Thang leo thang xung đột — đúng thứ tự Bước
⚠ 1. Nói chuyện TRỰC TIẾP giữa hai người ⚠ bước của câu này
⚠ 2. Nếu không xong: có người trung gian hỗ trợ
⚠ 3. Nếu vẫn không xong: đưa lên cấp trên ⚠ phương án B là bước này — quá sớm
⚠ 4. Cuối cùng mới tới thay đổi nhân sự
⚠ Nguyên tắc ⚠ luôn bắt đầu ở mức thấp nhất có thể
⚠ Điều nên khám phá trong cuộc trò chuyện Câu hỏi
⚠ "Điều gì khiến anh cảm thấy như vậy?" ⚠ nghe trước, đừng phản bác
⚠ "900 yêu cầu là rất nhiều — anh đang gặp khó ở đâu?" ⚠ có thể vấn đề thật là QUÁ TẢI, không phải về bạn
⚠ "Tôi có thể hỗ trợ cụ thể việc gì?"
⚠ "Chúng ta có nên xin thêm nguồn lực không?" ⚠ biến xung đột thành hành động chung
⚠ Kết quả có thể ⚠ phát hiện dự án THIẾU nhân lực phân tích — một rủi ro thật cần báo cáo
⚠ Còn việc đồng nghiệp đi vượt cấp thì sao Xử lý
⚠ ĐỪNG lấy đó làm trọng tâm cuộc trò chuyện ⚠ tập trung vào vấn đề công việc trước
⚠ Có thể nêu nhẹ nhàng SAU khi đã giải quyết vấn đề chính ⚠ "lần sau anh cứ nói thẳng với tôi nhé"
⚠ Báo lại cấp trên KẾT QUẢ đã giải quyết ⚠ đúng yêu cầu "trấn an cấp trên" của đề
⚠ Đừng ⚠ biến cuộc trò chuyện thành phiên trách móc về việc đi vượt cấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã nói chuyện trực tiếp chưa | ⚠ trước khi làm bất cứ điều gì khác | | Lời phàn nàn có phần nào ĐÚNG không | ⚠ 900 yêu cầu là khối lượng rất lớn | | Cấp trên có được báo lại kết quả không | |

Và điều dễ bỏ qua nhất trong tình huống này: lời phàn nàn có thể chứa một vấn đề THẬT của dự án. 900 yêu cầu cho một người là rủi ro nguồn lực — xử lý đúng thì bạn vừa gỡ được xung đột vừa cứu được tiến độ.

Câu 64 Process
The approach that Emily’s team takes for software at Kitchen Tables International is as follows. The development work is finished, reviewed as part of paired programming, and marked complete. Once complete, the testing team picks it up a few days later, as they are working on two projects simultaneously. After testing, they discuss any issues with the developer, which are corrected before it is considered done. How should this process be changed to minimize waste?
  1. A The delay waiting for the testing team should be removed.
  2. B The delay in updating the team daily on the status should be removed.
  3. C The delay associated with discussing issues during the test cycle should be removed.
  4. D The delay associated with paired programming should be removed.
Xem giải thích

Đáp án

A — Cần loại bỏ ĐỘ TRỄ CHỜ đội kiểm thử.

Vì sao đúng

⚠ Nhận diện lãng phí trong quy trình của Emily: | Bước | Có lãng phí không | |---|---| | ⚠ Lập trình xong | ⚠ công việc tạo giá trị | | ⚠ Rà soát qua lập trình cặp | ⚠ tạo giá trị — bắt lỗi sớm | | ⚠ Đánh dấu hoàn thành | | | ⚠ CHỜ VÀI NGÀY để đội kiểm thử rảnh | ⚠ LÃNG PHÍ THUẦN TUÝ — không tạo giá trị nào | | ⚠ Kiểm thử | ⚠ tạo giá trị | | ⚠ Bàn lỗi với lập trình viên rồi sửa | ⚠ tạo giá trị | | ⚠ Kết luận | ⚠ chỉ có bước CHỜ là lãng phí cần loại bỏ |

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

  • D (bỏ độ trễ do lập trình cặp) — ⚠ lập trình cặp TẠO GIÁ TRỊ: ⚠ bắt lỗi sớm, chia sẻ tri thức; ⚠ bỏ nó là bỏ chi phí phòng ngừa.

  • C (bỏ độ trễ do bàn lỗi trong chu kỳ kiểm thử) — ⚠ việc bàn lỗi để sửa là CẦN THIẾT; ⚠ bỏ đi thì lỗi không được sửa.

  • B (bỏ độ trễ do cập nhật trạng thái hằng ngày) — ⚠ đề không nhắc tới hoạt động này; ⚠ và daily standup là thực hành có giá trị.

Ghi nhớ

⚠ Bảy loại lãng phí trong tư duy Lean: | Loại | Nội dung | |---|---| | ⚠ WAITING — CHỜ ĐỢI | ⚠ công việc nằm im chờ người xử lý — LÃNG PHÍ CỦA CÂU NÀY | | ⚠ Partially done work | ⚠ việc làm dở, chưa giao được | | ⚠ Extra processes | ⚠ thủ tục thừa không ai cần | | ⚠ Extra features | ⚠ tính năng không ai yêu cầu — gold plating | | ⚠ Task switching | ⚠ chuyển qua lại giữa nhiều việc — chính là vấn đề của đội kiểm thử | | ⚠ Motion / Handoffs | ⚠ chuyển giao giữa các nhóm | | ⚠ Defects | ⚠ lỗi phải làm lại |

⚠ Nguyên nhân gốc của độ trễ này: | Nguyên nhân | Nội dung | |---|---| | ⚠ Đội kiểm thử làm HAI DỰ ÁN cùng lúc | ⚠ đề nói rõ | | ⚠ Đây là TASK SWITCHING — cũng là một loại lãng phí | | | ⚠ Đội kiểm thử là NÚT THẮT CỔ CHAI của luồng | | | ⚠ Vậy giải pháp gốc | ⚠ giảm số dự án đội kiểm thử phải gánh, hoặc đưa kiểm thử vào chính đội phát triển |

Từ khoá nhận diện:

"chờ nhóm khác rảnh" → ⚠ lãng phí CHỜ ĐỢI "làm nhiều dự án cùng lúc" → ⚠ task switching, cũng là lãng phí "chuyển giao giữa các nhóm" → ⚠ handoff, sinh ra chờ đợi "lập trình cặp, rà soát mã" → ⚠ tạo giá trị, đừng cắt

⚠ Cách khắc phục theo thứ tự ưu tiên Cách
⚠ 1. Đưa người kiểm thử VÀO đội phát triển ⚠ đội đa kỹ năng — xoá bỏ chuyển giao
⚠ 2. Nếu không được: giảm số dự án đội kiểm thử gánh
⚠ 3. Tự động hoá kiểm thử để giảm phụ thuộc thủ công
⚠ 4. Giới hạn công việc dở dang (WIP limit) ⚠ không đẩy thêm việc vào khi nút thắt đang tắc
⚠ 5. Đưa "đã kiểm thử" vào ĐỊNH NGHĨA DONE ⚠ để việc không được coi là xong khi chưa kiểm
⚠ Lưu ý ⚠ quy trình hiện tại đánh dấu "hoàn thành" TRƯỚC khi kiểm thử — đó là dấu hiệu Definition of Done chưa đủ chặt
⚠ Công cụ phát hiện lãng phí chờ đợi Công cụ
⚠ Value stream mapping ⚠ vẽ toàn bộ luồng, đo thời gian tạo giá trị so với tổng thời gian
⚠ Cumulative flow diagram ⚠ thấy công việc ùn ở khâu nào
⚠ Lead time và cycle time ⚠ đo thời gian từ yêu cầu tới khi giao
⚠ Chỉ số hay dùng ⚠ process efficiency = thời gian tạo giá trị / tổng thời gian — thường thấp tới mức đáng giật mình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công việc của bạn nằm chờ ở đâu lâu nhất | ⚠ đó là nút thắt cần xử lý trước | | Định nghĩa DONE có gồm kiểm thử không | | | Có ai đang làm nhiều dự án cùng lúc không | ⚠ task switching là lãng phí ẩn |

Và điều thường gây bất ngờ khi đo lần đầu: phần lớn thời gian trong quy trình là thời gian CHỜ, không phải thời gian LÀM. Rút ngắn thời gian chờ thường cho kết quả lớn hơn nhiều so với việc bắt người làm nhanh hơn.

Câu 65 People
Nicole is leading an agile project for her organization. The project requirement is significant, and there is an urgency to complete the project work as quickly and accurately as possible. Nicole's project team has contracted developers to augment the local development team members to increase the total story points the team can complete per iteration. The contracted staff will work virtually and will only serve until the project's end and be released. The contractors and the internal project team members have no common past and have never met face-to-face. Where will the team have the most significant risk to team effectiveness in this scenario?
  1. A Coordination
  2. B Communication
  3. C Initial trust
  4. D Job satisfaction
Xem giải thích

Đáp án

C — Initial trust (niềm tin ban đầu).

Vì sao đúng

⚠ Ba yếu tố cộng dồn tạo ra rủi ro niềm tin: | Yếu tố | Ảnh hưởng | |---|---| | ⚠ Làm việc HOÀN TOÀN TỪ XA | ⚠ không có tương tác phi công việc, khó xây quan hệ | | ⚠ CHƯA TỪNG gặp mặt trực tiếp | ⚠ không có nền tảng quan hệ nào | | ⚠ KHÔNG CÓ QUÁ KHỨ CHUNG | ⚠ không có kinh nghiệm hợp tác trước đó để dựa vào | | ⚠ Là NHÂN SỰ THUÊ NGOÀI, sẽ rời đi khi dự án xong | ⚠ đội nội bộ có thể coi họ là "người ngoài" | | ⚠ Dự án GẤP, yêu cầu lớn | ⚠ không có thời gian để niềm tin hình thành tự nhiên | | ⚠ Kết luận | ⚠ thiếu niềm tin ban đầu là rủi ro GỐC — các vấn đề khác đều là hệ quả của nó |

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

  • B (Communication — giao tiếp) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ giao tiếp đúng là khó với đội ảo, ⚠ nhưng giao tiếp có thể khắc phục bằng CÔNG CỤ (hội nghị truyền hình, phần mềm cộng tác); ⚠ niềm tin thì không mua bằng công cụ được.

  • A (Coordination — phối hợp) — ⚠ cũng là hệ quả: ⚠ đội tin nhau thì phối hợp dễ; ⚠ và phối hợp có thể cải thiện bằng quy trình.

  • D (Job satisfaction — sự hài lòng công việc) — ⚠ liên quan tới động lực cá nhân, ⚠ không phải rủi ro lớn nhất của việc ghép hai nhóm xa lạ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25784 ở lô này về công cụ giao tiếp cho đội ảo và câu #25743 ở lô 180 về người mới ngần ngại hoà nhập. ⚠ Ba câu cùng chủ đề đội phân tán và hoà nhập.

⚠ Vì sao niềm tin là nền tảng của đội hiệu quả: | Điều | Nội dung | |---|---| | ⚠ Không tin nhau thì không dám thừa nhận sai lầm | ⚠ lỗi bị giấu tới lúc quá muộn | | ⚠ Không tin nhau thì không dám nhờ giúp đỡ | | | ⚠ Không tin nhau thì tranh luận biến thành công kích | | | ⚠ Không tin nhau thì mọi thứ phải kiểm tra chéo | ⚠ tốn thời gian gấp đôi | | ⚠ Mô hình Lencioni | ⚠ thiếu niềm tin là RỐI LOẠN NỀN TẢNG, dẫn tới sợ xung đột, thiếu cam kết, né trách nhiệm, và không quan tâm kết quả |

Từ khoá nhận diện:

"chưa từng gặp mặt, không có quá khứ chung" → ⚠ rủi ro niềm tin ban đầu "đội ảo, khác múi giờ" → ⚠ thách thức giao tiếp — khắc phục bằng công cụ "nhân sự thuê ngoài tạm thời" → ⚠ rủi ro gắn kết và niềm tin "dự án gấp" → ⚠ không có thời gian cho niềm tin hình thành tự nhiên

⚠ Nicole nên làm gì để xây niềm tin nhanh Cách
⚠ Tổ chức buổi GẶP MẶT ẢO có camera ngay từ đầu ⚠ thấy mặt nhau là bước đầu tiên
⚠ Giới thiệu kỹ về từng người, cả chuyên môn lẫn con người
⚠ Nếu ngân sách cho phép: MỘT buổi gặp trực tiếp lúc khởi động ⚠ hiệu quả cao nhất, thường đáng tiền
⚠ Xây HIẾN CHƯƠNG ĐỘI cùng nhau ⚠ quy tắc chung do cả hai nhóm cùng đặt
⚠ Giao việc CHUNG sớm để hai nhóm phải hợp tác ⚠ đừng chia việc theo kiểu nội bộ làm phần này, thuê ngoài làm phần kia
⚠ Đối xử BÌNH ĐẲNG giữa người nội bộ và người thuê ngoài ⚠ cùng quyền truy cập, cùng dự họp, cùng được ghi nhận
⚠ Tạo thời gian trò chuyện PHI CÔNG VIỆC ⚠ vài phút đầu mỗi buổi họp
⚠ Đừng ⚠ để hai nhóm thành hai ốc đảo — xem câu #25783 về team silo
⚠ Dấu hiệu đội thiếu niềm tin Dấu hiệu
⚠ Không ai đặt câu hỏi trong họp
⚠ Mọi trao đổi đều bằng văn bản, ai cũng cẩn thận từng chữ
⚠ Vấn đề chỉ lộ ra khi đã muộn
⚠ Hai nhóm không nhờ vả nhau bao giờ
⚠ Có "chúng tôi" và "bọn họ" trong cách nói chuyện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hai nhóm đã thật sự làm việc CHUNG chưa | ⚠ hay chỉ chia đôi phần việc | | Người thuê ngoài có được đối xử như thành viên đội không | | | Có ai dám nói tin xấu trong họp không | ⚠ phép thử niềm tin tốt nhất |

Và lý do niềm tin xứng đáng là mối lo hàng đầu: công cụ giải quyết được vấn đề giao tiếp, quy trình giải quyết được vấn đề phối hợp — nhưng không có công cụ nào tạo ra niềm tin. Nó chỉ hình thành qua tương tác, và dự án gấp lại là thứ ít cho thời gian nhất.

Câu 66 Process
Mills wants to ensure that every product he sells is precisely what the buyer expected but recognizes that gathering and implementing feedback is sometimes more art than science. In addition to offering a full refund for any defective or unsatisfactory product, he makes sure to keep a database of return buyers so that he can offer them better prices for subscriptions and buying in bulk. Which quality management practice does this entail?
  1. A Mutually beneficial partnerships
  2. B Customer satisfaction
  3. C Management responsibility
  4. D Continual improvement
Xem giải thích

Đáp án

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

Vì sao đúng

⚠ Những gì Mills làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Đảm bảo sản phẩm ĐÚNG như người mua kỳ vọng | ⚠ quản lý KỲ VỌNG — cốt lõi của customer satisfaction | | ⚠ HOÀN TIỀN đầy đủ cho hàng lỗi hoặc không vừa ý | ⚠ cam kết với sự hài lòng, không chỉ với đặc tả | | ⚠ Giữ cơ sở dữ liệu KHÁCH QUAY LẠI | ⚠ theo dõi mức hài lòng qua hành vi thực tế | | ⚠ Ưu đãi giá cho khách trung thành | ⚠ duy trì quan hệ lâu dài | | ⚠ Thừa nhận việc thu thập phản hồi "nhiều phần là nghệ thuật" | ⚠ hiểu rằng hài lòng khó định lượng hoàn toàn | | ⚠ Kết luận | ⚠ toàn bộ hành động đều hướng tới KHÁCH HÀNG |

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

  • A (Mutually beneficial partnerships) — ⚠ nói về quan hệ với NHÀ CUNG CẤP; ⚠ Mills đang làm việc với NGƯỜI MUA.

  • D (Continual improvement) — ⚠ nói về cải tiến QUY TRÌNH nội bộ; ⚠ việc thu thập phản hồi có thể DẪN TỚI cải tiến, nhưng trọng tâm hành động là hướng tới khách.

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

Ghi nhớ

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ề nguyên tắc quản lý chất lượng, ⚠ và là câu THỨ HAI có khoá "customer satisfaction". ⚠ Bảng đối chiếu cả bốn: | Câu | Lô | Bối cảnh | Khoá | Chữ cái | |---|---|---|---|---| | ⚠ #25744 | ⚠ 180 | ⚠ giám đốc kiểm tra nhân viên có đủ nguồn lực | ⚠ management responsibility | ⚠ C | | ⚠ #25758 | ⚠ 180 | ⚠ thuê công ty khảo sát cộng đồng game | ⚠ customer satisfaction | ⚠ D | | ⚠ #25766 | ⚠ 180 | ⚠ hợp tác với nhà vườn, ghi tên lên nhãn | ⚠ mutually beneficial partnerships | ⚠ D | | ⚠ #25788 | ⚠ 181 | ⚠ hoàn tiền, giữ dữ liệu khách quay lại | ⚠ customer satisfaction | ⚠ B | ⚠ Bốn khoá đều đúng và KHÔNG mâu thuẫn. ⚠ Chú ý #25758 và #25788 cùng khoá nhưng KHÁC CHỮ CÁI (D và B) — bộ đề xáo thứ tự phương án. ⚠ Cách phân biệt chắc chắn nhất: hỏi hành động hướng tới AI — nhân viên, khách hàng, hay nhà cung cấp.

⚠ Năm nguyên tắc quản lý chất lượng — theo đối tượng: | Nguyên tắc | Hướng tới ai | |---|---| | ⚠ Customer satisfaction | ⚠ KHÁCH HÀNG | | ⚠ Mutually beneficial partnerships | ⚠ NHÀ CUNG CẤP | | ⚠ Management responsibility | ⚠ NHÂN VIÊN và nguồn lực | | ⚠ Continual improvement | ⚠ QUY TRÌNH nội bộ | | ⚠ Prevention over inspection | ⚠ cách LÀM RA sản phẩm |

Từ khoá nhận diện:

"hoàn tiền, khách quay lại, kỳ vọng người mua" → ⚠ customer satisfaction "hợp tác với nhà cung cấp" → ⚠ partnerships "cấp nguồn lực cho nhân viên" → ⚠ management responsibility "PDCA, cải tiến quy trình" → ⚠ continual improvement

⚠ Vì sao "khách quay lại" là thước đo tốt Lý do
⚠ Là HÀNH VI THẬT, không phải ý kiến trong khảo sát
⚠ Người hài lòng mới quay lại mua tiếp
⚠ Đo được bằng số, không cần phỏng đoán ⚠ giải quyết đúng vấn đề "khó định lượng" mà Mills nêu
⚠ Liên hệ ⚠ câu #25777 ở lô 180 nói sự hài lòng KHÓ định lượng — Mills chính là ví dụ về cách biến nó thành đo được
⚠ Ba khái niệm chất lượng — nhắc lại Khái niệm
⚠ Conformance to requirements ⚠ đúng đặc tả — hẹp nhất
⚠ Fitness for use ⚠ dùng được cho mục đích thật
⚠ Customer satisfaction ⚠ khách THẤY hài lòng — rộng nhất, gồm cả kỳ vọng ngầm
⚠ Mills nhắm tới ⚠ vế thứ ba — nên mới hoàn tiền cả khi hàng "không vừa ý" chứ không chỉ khi hàng lỗi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đo sự hài lòng bằng ý kiến hay bằng hành vi | ⚠ hành vi đáng tin hơn | | Chính sách của bạn có bao gồm cả "không vừa ý" không | ⚠ rộng hơn "hàng lỗi" rất nhiều | | Có theo dõi tỷ lệ khách quay lại không | |

Và điểm tinh tế trong cách làm của Mills: hoàn tiền cả cho hàng KHÔNG VỪA Ý, không chỉ hàng LỖI. Đó là ranh giới giữa "đúng đặc tả" và "khách hàng hài lòng".

Câu 67 People
Your organization has recently returned from working at home to working together in the office. You are utilizing a scrum approach to project management. Which project team composition includes a set of team members where everyone physically sits together?
  1. A Collocated teams within 33 feet of each other
  2. B Outsourcing to many consultants and vendors all in one locale
  3. C Cross-functional teams within 33 feet of each other
  4. D Virtual teams within 33 meters of each other
Xem giải thích

Đáp án

A — Collocated teams (đội đồng địa điểm) trong phạm vi 33 feet của nhau.

Vì sao đúng

⚠ Collocation là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Mọi thành viên NGỒI CÙNG MỘT NƠI về mặt vật lý | ⚠ đúng điều đề hỏi | | ⚠ Khoảng cách khuyến nghị: trong 33 feet (khoảng 10 mét) | ⚠ con số hay được nhắc trong tài liệu agile | | ⚠ Còn gọi là "tight matrix" hoặc "war room" | | | ⚠ Là công cụ của quy trình Develop Team | | | ⚠ Vì sao 33 feet | ⚠ quá khoảng cách này thì giao tiếp tự phát giảm mạnh — người ta ngại đứng dậy đi hỏi |

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

  • C (Cross-functional teams trong 33 feet) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ "cross-functional" nói về ⚠ THÀNH PHẦN KỸ NĂNG của đội (đủ mọi kỹ năng để giao hàng), ⚠ KHÔNG nói về vị trí ngồi; ⚠ một đội đa kỹ năng hoàn toàn có thể phân tán khắp thế giới.

  • D (Virtual teams trong 33 mét) — ⚠ MÂU THUẪN nội tại: ⚠ đội ảo theo định nghĩa là đội KHÔNG ngồi cùng chỗ.

  • B (thuê ngoài nhiều tư vấn và nhà cung cấp cùng một địa phương) — ⚠ nói về NGUỒN NHÂN LỰC, ⚠ không phải cách bố trí chỗ ngồi; ⚠ cùng địa phương không có nghĩa là cùng phòng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25787 ở lô này về đội ảo và rủi ro niềm tin và câu #25784 về công cụ giao tiếp cho đội ảo. ⚠ Ba câu là bộ đối chiếu hoàn chỉnh giữa đội ngồi cùng chỗ và đội phân tán.

⚠ Ba khái niệm về đội — phân biệt cho chắc: | Khái niệm | Nói về gì | |---|---| | ⚠ Collocated | ⚠ VỊ TRÍ — cùng ngồi một nơi | | ⚠ Virtual / Distributed | ⚠ VỊ TRÍ — phân tán, làm việc qua công nghệ | | ⚠ Cross-functional | ⚠ KỸ NĂNG — có đủ mọi kỹ năng cần để giao hàng | | ⚠ Kết hợp được | ⚠ một đội có thể vừa cross-functional vừa virtual, hoặc vừa cross-functional vừa collocated |

Từ khoá nhận diện:

"ngồi cùng chỗ, trong 33 feet" → ⚠ collocated "đủ mọi kỹ năng để giao hàng" → ⚠ cross-functional "làm việc qua công nghệ, khác địa điểm" → ⚠ virtual "war room, tight matrix" → ⚠ cách gọi khác của collocation

⚠ Lợi ích của đội ngồi cùng chỗ Lợi ích
⚠ Giao tiếp TỰ PHÁT — hỏi ngay không cần hẹn
⚠ Osmotic communication ⚠ nghe lỏm được thông tin hữu ích từ cuộc trò chuyện xung quanh
⚠ Xây niềm tin nhanh hơn nhiều
⚠ Giải quyết vấn đề tại chỗ, không chờ email
⚠ Dùng được bảng vật lý, giấy nhớ, information radiator
⚠ Chi phí ⚠ đòi hỏi mọi người cùng thành phố và tổ chức phải bố trí được không gian
⚠ Nhược điểm của collocation Nhược điểm
⚠ Hạn chế nguồn nhân tài trong phạm vi địa lý
⚠ Chi phí văn phòng
⚠ Dễ bị gián đoạn liên tục ⚠ mặt trái của giao tiếp tự phát
⚠ Không phù hợp với xu hướng làm việc linh hoạt
⚠ Giải pháp dung hoà ⚠ mô hình lai: vài ngày cùng chỗ, vài ngày từ xa
⚠ Vì sao Scrum ưu tiên collocation Lý do
⚠ Daily standup hiệu quả hơn khi đứng cùng nhau
⚠ Bảng công việc vật lý dễ nhìn hơn bảng số
⚠ Đội tự tổ chức cần trao đổi liên tục
⚠ Nhưng ⚠ Scrum vẫn chạy được với đội ảo — chỉ cần công cụ tốt và kỷ luật cao hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn ngồi cách nhau bao xa | ⚠ quá 10 mét là giao tiếp tự phát giảm rõ | | Đội có đủ mọi kỹ năng cần thiết không | ⚠ cross-functional là chuyện khác với collocated | | Có cách nào tạo "cảm giác cùng chỗ" cho người ở xa không | |

Và con số 33 feet không phải quy tắc cứng mà là lời nhắc: khoảng cách vật lý tỷ lệ nghịch với tần suất trao đổi. Ngồi xa một hành lang cũng đủ để hai người ngừng hỏi nhau.

Câu 68 Process
Sebastian has been working as a subject matter expert on completing a high-interest bank mobile banking application. He is in the process of conducting exploratory testing on the done-done stories. This activity will allow him to determine if there are any issues with the deliverable. What is the status of the user stories?
  1. A End of the sprint, going through to final release.
  2. B Release testing, closure phase.
  3. C End of project, going through to the final handoff.
  4. D Delivered to the user groups.
Xem giải thích

Đáp án

D — Đã được GIAO cho các nhóm người dùng (delivered to the user groups).

Vì sao đúng

⚠ "Done-done" nghĩa là gì: | Điều | Nội dung | |---|---| | ⚠ Là cách nói nhấn mạnh HOÀN TOÀN xong | ⚠ không phải "xong theo lời lập trình viên" | | ⚠ Đã qua ĐỦ mọi tiêu chí trong Definition of Done | ⚠ viết mã, rà soát, kiểm thử, tích hợp, tài liệu | | ⚠ Đã được product owner chấp nhận | | | ⚠ ĐÃ SẴN SÀNG hoặc ĐÃ được đưa tới người dùng | | | ⚠ Vì thế | ⚠ Sebastian đang kiểm thử KHÁM PHÁ trên phần đã giao — để tìm những vấn đề mà kiểm thử theo kịch bản bỏ sót |

⚠ Kiểm thử khám phá (exploratory testing) là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ KHÔNG theo kịch bản định sẵn | | | ⚠ Người kiểm thử vừa học vừa thiết kế phép thử vừa chạy | | | ⚠ Dựa vào kinh nghiệm và trực giác của chuyên gia | ⚠ Sebastian là SME — đúng người cho việc này | | ⚠ Tìm ra vấn đề mà kịch bản cố định KHÔNG bắt được | | | ⚠ Thời điểm phù hợp | ⚠ trên phần đã hoàn thiện, để kiểm tra trải nghiệm thực tế |

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

  • A (cuối sprint, đang chuyển sang bản phát hành cuối) — ⚠ chưa tới mức "done-done" và đã giao; ⚠ đề nói story đã done-done.

  • B (kiểm thử phát hành, giai đoạn kết thúc) — ⚠ giai đoạn kết thúc là lúc đóng dự án, ⚠ không phải lúc còn kiểm thử khám phá.

  • C (cuối dự án, chuẩn bị bàn giao cuối cùng) — ⚠ đề không nói dự án sắp kết thúc; ⚠ và "done-done" là trạng thái của TỪNG STORY, không phải của cả dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25786 ở lô này về định nghĩa DONE chưa đủ chặt gây lãng phí và câu #25772 ở lô 180 về phần mềm chạy được là thước đo tiến độ. ⚠ Ba câu cùng xoay quanh khái niệm DONE.

⚠ Definition of Done — vì sao quan trọng: | Điều | Nội dung | |---|---| | ⚠ Là bộ tiêu chí BẮT BUỘC để coi một hạng mục là xong | | | ⚠ Do đội và product owner cùng thống nhất | | | ⚠ Áp dụng cho MỌI hạng mục, không đàm phán từng cái | | | ⚠ Tiêu chí điển hình | ⚠ mã đã viết, đã rà soát, đã kiểm thử đơn vị, đã tích hợp, đã kiểm thử chấp nhận, đã có tài liệu, không còn lỗi nghiêm trọng | | ⚠ Thiếu DoD rõ ràng | ⚠ "xong" trở thành khái niệm mỗi người hiểu một kiểu — chính là vấn đề của câu #25786 |

Từ khoá nhận diện:

"done-done" → ⚠ hoàn toàn xong theo mọi tiêu chí, đã tới người dùng "kiểm thử khám phá" → ⚠ không theo kịch bản, dựa vào kinh nghiệm "definition of done" → ⚠ tiêu chí chung cho mọi hạng mục "acceptance criteria" → ⚠ tiêu chí RIÊNG của từng story — khác với DoD

⚠ Phân biệt DoD và Acceptance Criteria Phân biệt
⚠ Definition of Done ⚠ CHUNG cho mọi story — chuẩn chất lượng của đội
⚠ Acceptance Criteria ⚠ RIÊNG cho từng story — story này phải làm được gì
⚠ Một story xong khi ⚠ đạt CẢ HAI: tiêu chí riêng của nó VÀ chuẩn chung của đội
⚠ Bẫy thi ⚠ đảo hai khái niệm này cho nhau
⚠ Các loại kiểm thử hay ra thi Loại
⚠ Exploratory testing ⚠ không kịch bản, dựa kinh nghiệm — CÂU NÀY
⚠ Scripted testing ⚠ theo kịch bản định sẵn
⚠ Regression testing ⚠ kiểm lại phần cũ sau khi sửa, đảm bảo không hỏng chỗ khác
⚠ Acceptance testing ⚠ khách hàng hoặc người dùng xác nhận đạt yêu cầu
⚠ Smoke testing ⚠ kiểm nhanh các chức năng chính có chạy không
⚠ Vì sao vẫn kiểm thử khám phá dù đã done-done Lý do
⚠ Kịch bản chỉ kiểm được thứ người ta NGHĨ RA để kiểm
⚠ Người dùng thật dùng theo cách không ai lường trước
⚠ Chuyên gia nghiệp vụ nhìn ra vấn đề mà lập trình viên không thấy
⚠ Ứng dụng ngân hàng đòi mức tin cậy rất cao ⚠ bối cảnh của đề
⚠ Kết quả tìm được ⚠ là ESCAPED DEFECT — xem câu #25670 ở lô 178

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Định nghĩa DONE của đội bạn có gồm kiểm thử không | | | Có ai kiểm thử khám phá ngoài kịch bản không | | | Lỗi tìm được sau khi giao có được truy nguyên nhân gốc không | |

Và lý do kiểm thử khám phá vẫn cần thiết dù đã có kịch bản đầy đủ: kịch bản chỉ tìm được những lỗi mà người viết kịch bản đã tưởng tượng ra. Phần còn lại phải trông vào kinh nghiệm và trực giác của người hiểu nghiệp vụ.

Câu 69 Process
Grey is the project manager for project H, which is ten weeks into implementation, has a CPI of .98 and an SPI of 1.05. When Grey reports the status of the project is there is some concern from key stakeholders. What is the likely cause of concern?
  1. A The project is over budget.
  2. B The project is five percent late.
  3. C The project is under budget.
  4. D The project is late.
Xem giải thích

Đáp án

A — Dự án đang VƯỢT NGÂN SÁCH.

Vì sao đúng

⚠ Đọc hai chỉ số: | Chỉ số | Giá trị | Nghĩa | |---|---|---| | ⚠ CPI = 0,98 | ⚠ NHỎ HƠN 1 | ⚠ cứ 1 đồng chi ra chỉ đổi được 0,98 đồng giá trị → VƯỢT CHI khoảng 2% | | ⚠ SPI = 1,05 | ⚠ LỚN HƠN 1 | ⚠ làm được nhiều hơn kế hoạch 5% → SỚM tiến độ | | ⚠ Kết luận | ⚠ tiến độ TỐT, chi phí XẤU — nên lo ngại nằm ở ngân sách |

⚠ Quy tắc đọc chỉ số EVM — thuộc lòng: | Giá trị | Ý nghĩa | |---|---| | ⚠ Chỉ số > 1 | ⚠ TỐT | | ⚠ Chỉ số = 1 | ⚠ đúng kế hoạch | | ⚠ Chỉ số < 1 | ⚠ XẤU | | ⚠ Áp dụng cho | ⚠ cả CPI lẫn SPI |

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

  • C (dự án đang DƯỚI ngân sách) — ⚠ SAI: ⚠ CPI dưới 1 nghĩa là VƯỢT chi, không phải tiết kiệm.

  • D (dự án đang TRỄ) và B (dự án trễ 5%) — ⚠ SAI HẲN: ⚠ SPI = 1,05 nghĩa là dự án ⚠ SỚM hơn kế hoạch 5%, không phải trễ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25754 ở lô 180 (CPI 0,86 và SPI 0,99) và các câu EVM ở lô 179. ⚠ Cùng dạng đọc chỉ số nhưng bộ số khác — điểm chung là phải đọc CẢ HAI chỉ số rồi mới kết luận.

⚠ Bốn tổ hợp CPI và SPI — bảng chẩn đoán nhanh: | CPI | SPI | Chẩn đoán | |---|---|---| | ⚠ > 1 | ⚠ > 1 | ⚠ tốt cả hai — tiết kiệm và sớm | | ⚠ < 1 | ⚠ > 1 | ⚠ CÂU NÀY — sớm tiến độ nhưng vượt chi; thường do dồn nguồn lực để chạy nhanh | | ⚠ > 1 | ⚠ < 1 | ⚠ tiết kiệm nhưng chậm; có thể do thiếu nguồn lực | | ⚠ < 1 | ⚠ < 1 | ⚠ xấu cả hai — tình huống nguy hiểm nhất |

Từ khoá nhận diện:

"CPI dưới 1" → ⚠ vượt chi "SPI trên 1" → ⚠ sớm tiến độ "chỉ số dưới 1" → ⚠ luôn là tin xấu "bên liên quan lo ngại" → ⚠ tìm chỉ số nào dưới 1

⚠ Vì sao tình huống này lại xảy ra Giải thích
⚠ Đội đang chạy NHANH hơn kế hoạch ⚠ SPI 1,05
⚠ Nhưng phải chi nhiều hơn để đạt tốc độ đó ⚠ CPI 0,98
⚠ Có thể do làm thêm giờ, thuê thêm người, hoặc trả phí gấp ⚠ giống hiệu ứng của CRASHING
⚠ Câu hỏi cần đặt ⚠ việc chạy sớm có ĐÁNG với phần chi vượt không?

⚠ Các chỉ số cần tính thêm để đánh giá đầy đủ: | Chỉ số | Vì sao cần | |---|---| | ⚠ EAC = BAC / CPI | ⚠ dự báo tổng chi phí — với CPI 0,98 thì sẽ vượt khoảng 2% ngân sách | | ⚠ VAC = BAC − EAC | ⚠ sẽ vượt bao nhiêu tiền | | ⚠ TCPI | ⚠ phải làm hiệu quả tới mức nào để về đúng ngân sách | | ⚠ Với CPI 0,98 | ⚠ mức vượt còn NHỎ, hoàn toàn có thể khắc phục nếu phát hiện sớm |

⚠ Grey nên báo cáo thế nào Cách
⚠ Nêu CẢ hai chỉ số, không giấu chỉ số xấu
⚠ Giải thích nguyên nhân vượt chi
⚠ Đưa dự báo EAC và VAC
⚠ Đề xuất phương án ⚠ chấp nhận vượt 2%, hoặc giảm tốc để về đúng chi phí
⚠ Điểm tích cực cần nêu ⚠ sớm tiến độ 5% là dư địa để điều chỉnh mà không trễ hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số nào đang dưới 1 | ⚠ đó là chỗ cần lo | | Mức vượt chi dự báo tới cuối dự án là bao nhiêu | | | Việc chạy sớm có mang lại giá trị thật không | ⚠ nếu không thì đang trả tiền cho thứ vô ích |

Và mẹo làm bài không bao giờ sai: chỉ số dưới 1 là tin xấu, trên 1 là tin tốt — áp dụng cho cả CPI lẫn SPI, không có ngoại lệ.

Câu 70 Process
Todd's team produced a line of clothing. Unfortunately, they learn that 1 in every 100,000 pieces produced contains compromised stitching. Without inspecting all the pieces, Todd's team cannot ensure that some of the damaged pieces will not go out, but inspecting all of them will put their shipping timeline at risk. Todd decides to continue with the shipping timeline and to offer a refund or replacement for any of the damaged pieces as they appear. Which risk management option does this represent?
  1. A Mitigate
  2. B Accept
  3. C Avoid
  4. D Transfer
Xem giải thích

Đáp án

B — Accept (chấp nhận rủi ro).

Vì sao đúng

⚠ Vì sao đây là chấp nhận rủi ro: | Chi tiết | Suy ra | |---|---| | ⚠ Todd BIẾT rủi ro tồn tại | ⚠ 1 trên 100.000 sản phẩm bị lỗi đường may | | ⚠ Todd QUYẾT ĐỊNH KHÔNG hành động để ngăn nó | ⚠ không kiểm tra toàn bộ | | ⚠ Lý do: chi phí ứng phó cao hơn giá trị | ⚠ kiểm tra hết sẽ trễ hạn giao hàng | | ⚠ Có KẾ HOẠCH XỬ LÝ khi rủi ro xảy ra | ⚠ hoàn tiền hoặc đổi hàng | | ⚠ Kết luận | ⚠ đây là CHẤP NHẬN CHỦ ĐỘNG — active acceptance, có kế hoạch dự phòng |

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

  • A (Mitigate — giảm nhẹ) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ giảm nhẹ là ⚠ làm giảm XÁC SUẤT hoặc TÁC ĐỘNG trước khi rủi ro xảy ra; ⚠ Todd ⚠ không làm gì để giảm tỷ lệ lỗi — anh chỉ chuẩn bị cách xử lý hậu quả.

  • C (Avoid — né tránh) — ⚠ là LOẠI BỎ khả năng xảy ra; ⚠ kiểm tra toàn bộ mới là né tránh, ⚠ và Todd đã từ chối phương án đó.

  • D (Transfer — chuyển giao) — ⚠ là chuyển hậu quả sang BÊN THỨ BA (bảo hiểm, hợp đồng); ⚠ Todd tự gánh chi phí hoàn tiền và đổi hàng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25688 ở lô 179 về né tránh rủi ro và câu #25709 về rủi ro tồn dư sau khi chuyển giao. ⚠ Ba câu tạo thành bộ đầy đủ về chiến lược ứng phó rủi ro.

⚠ Năm chiến lược ứng phó MỐI ĐE DOẠ: | Chiến lược | Nghĩa | Khi nào | |---|---|---| | ⚠ Avoid | ⚠ loại bỏ khả năng xảy ra | ⚠ rủi ro nghiêm trọng không chấp nhận được | | ⚠ Transfer | ⚠ chuyển hậu quả sang bên thứ ba | ⚠ bảo hiểm, hợp đồng giá cố định | | ⚠ Mitigate | ⚠ giảm xác suất hoặc giảm tác động | ⚠ rủi ro chịu được sau khi giảm | | ⚠ ACCEPT | ⚠ không hành động ngăn chặn | ⚠ rủi ro nhỏ, hoặc chi phí ứng phó CAO HƠN lợi ích — CÂU NÀY | | ⚠ Escalate | ⚠ chuyển lên cấp cao hơn | ⚠ vượt thẩm quyền dự án |

⚠ Hai kiểu chấp nhận: | Kiểu | Nội dung | |---|---| | ⚠ ACTIVE acceptance — chấp nhận CHỦ ĐỘNG | ⚠ có KẾ HOẠCH DỰ PHÒNG và/hoặc quỹ dự phòng — CÁCH CỦA TODD | | ⚠ PASSIVE acceptance — chấp nhận BỊ ĐỘNG | ⚠ không làm gì cả, xử lý khi nào xảy ra thì tính | | ⚠ Todd thuộc kiểu nào | ⚠ CHỦ ĐỘNG — anh đã định sẵn cách xử lý: hoàn tiền hoặc đổi hàng |

Từ khoá nhận diện:

"biết rủi ro nhưng chấp nhận, có kế hoạch xử lý khi xảy ra" → ⚠ active acceptance "làm giảm xác suất hoặc tác động" → ⚠ mitigate "loại bỏ hẳn khả năng" → ⚠ avoid "mua bảo hiểm, ký hợp đồng chuyển rủi ro" → ⚠ transfer

⚠ Vì sao chấp nhận là quyết định HỢP LÝ ở đây Lý do
⚠ Xác suất RẤT THẤP: 1 / 100.000
⚠ Tác động NHỎ: một sản phẩm quần áo
⚠ Chi phí ứng phó CAO: kiểm tra hết sẽ trễ hạn giao
⚠ Có cách xử lý hậu quả rẻ và đơn giản ⚠ hoàn tiền hoặc đổi hàng
⚠ Phép so sánh ⚠ chi phí kiểm tra 100.000 sản phẩm để bắt 1 lỗi lớn hơn nhiều so với chi phí hoàn tiền cho 1 sản phẩm
⚠ Điều Todd nên làm để chấp nhận cho đúng chuẩn Việc
⚠ GHI rủi ro vào risk register ⚠ kèm quyết định chấp nhận và lý do
⚠ Lập DỰ PHÒNG cho chi phí hoàn tiền và đổi hàng ⚠ contingency reserve
⚠ Định sẵn quy trình xử lý khiếu nại
⚠ THEO DÕI tỷ lệ lỗi thực tế ⚠ nếu cao hơn 1/100.000 thì phải xem lại quyết định
⚠ Truy nguyên nhân gốc để cải thiện về lâu dài ⚠ chấp nhận lần này không có nghĩa là chấp nhận mãi
⚠ Lưu ý ⚠ nếu sản phẩm liên quan AN TOÀN thì chấp nhận là KHÔNG được — xem câu #25782

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí ứng phó có thật sự cao hơn thiệt hại kỳ vọng không | ⚠ tính EMV để so | | Đã có dự phòng cho hậu quả chưa | | | Rủi ro này có liên quan an toàn hay pháp lý không | ⚠ nếu có thì không được chấp nhận |

Và ranh giới cần nhớ: chấp nhận rủi ro là quyết định CÓ CÂN NHẮC, không phải sự thờ ơ. Todd đã tính toán và có phương án — đó là điều phân biệt chấp nhận chủ động với việc phớt lờ.