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

Tìm thấy 718 câu.

Câu 591 Process
Mark manages a telecommunications upgrade project and comes across multiple end-users who are not happy with the project team's solution. After discussion with user group leads, it becomes clear that this has become a trend with each incremental upgrade due to inadequate training. What has Mark failed to address in managing the project artifacts so that the same issues are not repeated?
  1. A Updating the issue log.
  2. B Updating the project management plan with training requirements.
  3. C Coordination of additional training.
  4. D Performing root cause analysis.
Xem giải thích

Đáp án

A — CẬP NHẬT SỔ VẤN ĐỀ (issue log).

Vì sao đúng

⚠ Chú ý chữ khoá trong câu hỏi: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Đề hỏi về "quản lý TÀI LIỆU DỰ ÁN" (project artifacts) | ⚠ giới hạn câu trả lời vào các TÀI LIỆU | | ⚠ Vấn đề LẶP LẠI qua từng đợt nâng cấp | ⚠ dấu hiệu rõ nhất của việc không ghi lại | | ⚠ Sổ vấn đề là nơi ghi các vấn đề đang mở | ⚠ kèm người phụ trách và trạng thái | | ⚠ Không ghi thì mỗi đợt lại phát hiện lại từ đầu | | | ⚠ Kết luận | ⚠ Mark bỏ sót đúng cái tài liệu sinh ra để ngăn một vấn đề tái diễn |

⚠ Vì sao sổ vấn đề quan trọng đến vậy: ⚠ nó biến một chuyện "ai cũng biết" thành một mục có người chịu trách nhiệm và có hạn xử lý ⚠ — ⚠ chuyện không được ghi thì không ai sở hữu, và không ai sở hữu thì nó quay lại ở đợt sau.

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

  • D (phân tích nguyên nhân gốc) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ vấn đề lặp đi lặp lại đúng là dấu hiệu kinh điển cần phân tích nguyên nhân gốc, và trong nhiều câu hỏi khác thì đó chính là đáp án — liên hệ #27024 lô 205: ⚠ nhưng ⚠ ở đây nguyên nhân gốc ĐÃ ĐƯỢC XÁC ĐỊNH rồi: đề nói rõ là "do đào tạo không đầy đủ" ⚠; ⚠ và câu hỏi giới hạn vào việc quản lý TÀI LIỆU, mà phân tích nguyên nhân gốc là một kỹ thuật chứ không phải một tài liệu; ⚠ kỹ thuật làm bài: gạch chân phạm vi mà câu hỏi giới hạn — ở đây là "project artifacts" — rồi loại mọi phương án không thuộc phạm vi đó.

  • B (cập nhật kế hoạch quản lý dự án với yêu cầu đào tạo) — ⚠ là hành động ĐÚNG nhưng đến SAU; ⚠ vấn đề phải được ghi nhận và phân tích trước khi kế hoạch được sửa.

  • C (tổ chức thêm buổi đào tạo) — ⚠ giải quyết triệu chứng của đợt này; ⚠ và cũng không phải một tài liệu dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27024 lô 205 (tìm nguyên nhân gốc khi chưa ai phân tích), ⚠ #26925 lô 203 (hành động phòng ngừa dựa trên bài học), ⚠ #27019 lô 205 (biến kết luận thành hành động), ⚠ #26838 lô 202 (sổ bài học kinh nghiệm).

⚠ Các sổ theo dõi trong dự án, đừng lẫn: | Sổ | Ghi cái gì | |---|---| | ⚠ SỔ VẤN ĐỀ (issue log) | ⚠ chuyện ĐÃ xảy ra và đang cần xử lý — ĐÁP ÁN | | ⚠ SỔ RỦI RO (risk register) | ⚠ chuyện CHƯA xảy ra nhưng có thể xảy ra | | ⚠ NHẬT KÝ THAY ĐỔI (change log) | ⚠ các yêu cầu thay đổi và kết quả xử lý | | ⚠ SỔ BÀI HỌC (lessons learned) | ⚠ điều rút ra được để dùng cho dự án sau | | ⚠ SỔ GIẢ ĐỊNH (assumption log) | ⚠ những điều đang được cho là đúng | | ⚠ Ranh giới hay bị nhầm | ⚠ rủi ro khi XẢY RA thì trở thành vấn đề và chuyển từ sổ rủi ro sang sổ vấn đề — nhiều người quên bước chuyển này và để rủi ro đã xảy ra nằm mãi trong sổ rủi ro |

⚠ Một mục trong sổ vấn đề cần có gì: | Trường | Nội dung | |---|---| | ⚠ Mô tả vấn đề, cụ thể và khách quan | | | ⚠ Ngày phát hiện và người phát hiện | | | ⚠ Mức độ ưu tiên và tác động | | | ⚠ NGƯỜI CHỊU TRÁCH NHIỆM | ⚠ trường quan trọng nhất | | ⚠ Hành động đang thực hiện và hạn xử lý | | | ⚠ Trạng thái: mở, đang xử lý, đã đóng | | | ⚠ Vì sao trường người phụ trách quyết định tất cả | ⚠ một vấn đề không có tên người bên cạnh sẽ nằm trong sổ mãi mãi — và sau vài tháng thì cả cuốn sổ trở thành danh sách những chuyện ai cũng biết mà không ai làm |

⚠ Chuỗi việc Mark nên làm đầy đủ: | Bước | Nội dung | |---|---| | ⚠ 1. GHI vào sổ vấn đề | ⚠ ĐÁP ÁN — bước đang bị bỏ sót | | ⚠ 2. Giao người phụ trách và hạn xử lý | | | ⚠ 3. Cập nhật kế hoạch với yêu cầu đào tạo | ⚠ phương án B, đến sau | | ⚠ 4. Tổ chức đào tạo cho đợt hiện tại | ⚠ phương án C | | ⚠ 5. Đưa vào sổ bài học cho các dự án sau | | | ⚠ Nhận xét | ⚠ ba phương án nhiễu trong câu này đều là việc NÊN LÀM — chúng chỉ sai về thứ tự hoặc về loại; đó là dạng câu hỏi khó nhất trong đề PMP vì không có phương án nào sai hẳn |

Từ khoá nhận diện:

"quản lý TÀI LIỆU dự án + vấn đề lặp lại" → ⚠ SỔ VẤN ĐỀ "phân tích nguyên nhân gốc" → ⚠ kỹ thuật, không phải tài liệu; và nguyên nhân đã rõ "cập nhật kế hoạch" → ⚠ đúng nhưng đến sau bước ghi nhận "tổ chức thêm đào tạo" → ⚠ xử lý triệu chứng của đợt này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ vấn đề của bạn có bao nhiêu mục không có người phụ trách | | | Có vấn đề nào lặp lại qua nhiều giai đoạn mà chưa được ghi không | | | Rủi ro đã xảy ra của bạn có được chuyển sang sổ vấn đề không | |

Và lý do việc ghi một dòng vào sổ vấn đề đáng giá hơn cảm giác của nó: một chuyện được viết ra là một chuyện có thể được giao cho ai đó — còn một chuyện chỉ được nói ra thì sẽ được nói lại ở đợt sau.

Câu 592 People
Ruth is part of a team working to deploy a quality product with a deadline of Q4. Recently there have been several instances of miscommunication that have caused issues in the project. Ruth and the other team members have discussed ways to avoid any further communication failures that could hinder the project. The team decides that they should bring the matter to the project manager, Beth. What are ways that Beth could help the team become more effective in communication?
  1. A Restructure the team where the most efficient person at communication becomes the one responsible for all communication.
  2. B Incorporate open networking forums with specialists that would allow team members to post questions for knowledge sharing.
  3. C Assign a facilitator within the team to ensure effective participation and communication, which allows for full buy-in for the agreements and actions to be dealt with following the decision process established for the project.
  4. D Call a meeting to discuss ways that deadlines are essential to job security, and better communication is a must to meet those deadlines.
Xem giải thích

Đáp án

C — CHỈ ĐỊNH MỘT NGƯỜI ĐIỀU PHỐI TRONG ĐỘI ĐỂ BẢO ĐẢM MỌI NGƯỜI THAM GIA VÀ TRAO ĐỔI HIỆU QUẢ, TỪ ĐÓ ĐẠT ĐƯỢC SỰ ĐỒNG THUẬN ĐẦY ĐỦ VỚI CÁC THOẢ THUẬN VÀ HÀNH ĐỘNG SAU KHI RA QUYẾT ĐỊNH.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ chính phương án đúng bị CẮT CỤT giữa câu trong đề ⚠ — ⚠ dừng ở "…to be dealt with following the deci…", tức là "following the decision"; ⚠ may là phần đầu đã đủ rõ để nhận ra đây là phương án về vai trò điều phối.

Vì sao đúng

⚠ Người điều phối giải đúng vấn đề của đội: | Vấn đề | Cách người điều phối xử lý | |---|---| | ⚠ Nhiều lần hiểu nhầm gây sự cố | ⚠ bảo đảm thông điệp được xác nhận lại | | ⚠ Có người không được nói, có người lấn át | ⚠ cân bằng sự tham gia | | ⚠ Quyết định không ai thực sự đồng ý | ⚠ tạo sự đồng thuận thật | | ⚠ Sau họp không rõ ai làm gì | ⚠ chốt hành động cụ thể | | ⚠ Kết luận | ⚠ đây là giải pháp về QUY TRÌNH TRAO ĐỔI, đúng loại vấn đề mà đội đang gặp |

⚠ Điểm quan trọng: người điều phối nằm TRONG đội: ⚠ không phải Beth ôm hết việc, cũng không phải thuê người ngoài ⚠ — ⚠ đội tự giải quyết vấn đề của mình, còn Beth tạo điều kiện; liên hệ #26944 lô 204.

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

  • B (lập diễn đàn mở với các chuyên gia để mọi người đăng câu hỏi chia sẻ tri thức) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chia sẻ tri thức là việc tốt, và một diễn đàn nghe rất hiện đại và có tính xây dựng: ⚠ nhưng ⚠ vấn đề của đội là HIỂU NHẦM trong trao đổi, không phải THIẾU KIẾN THỨC ⚠; ⚠ thêm một kênh viết không đồng bộ vào một đội vốn đã hiểu nhầm nhau thường làm mọi thứ tệ hơn — chữ viết mất giọng điệu và mất phản hồi tức thì, đúng hai thứ mà hiểu nhầm cần nhất; liên hệ #26921 lô 203; ⚠ và một dự án có hạn chót quý IV không có thời gian chờ một diễn đàn hình thành thói quen sử dụng.

  • A (giao toàn bộ việc trao đổi cho người giỏi giao tiếp nhất) — ⚠ tạo ra một nút thắt và một điểm chết duy nhất; ⚠ nó cũng tước quyền trao đổi trực tiếp của các thành viên khác.

  • D (họp để nói rằng hạn chót gắn với sự an toàn của công việc) — ⚠ dùng nỗi sợ làm động lực; ⚠ nó không sửa gì về cách trao đổi và còn phá huỷ sự an toàn tâm lý.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26944 lô 204 (người điều phối được đào tạo), ⚠ #27017 lô 205 (lắng nghe chủ động), ⚠ #27050 cùng lô (làm cho cuộc họp hiệu quả hơn), ⚠ #26950 lô 204 (cả đội cùng giải quyết vấn đề tạo đồng thuận).

⚠ Người điều phối trong đội làm gì: | Nhiệm vụ | Nội dung | |---|---| | ⚠ Giữ cuộc trao đổi đúng chủ đề và đúng giờ | | | ⚠ Bảo đảm mọi người được nói | ⚠ chặn người lấn át, mời người im lặng | | ⚠ Xác nhận lại các điểm đã thống nhất | ⚠ chống hiểu nhầm ngay tại chỗ | | ⚠ Chốt hành động và người phụ trách | | | ⚠ Trung lập về nội dung | ⚠ lo cách bàn, không lo bàn cái gì | | ⚠ Mẹo thực dụng | ⚠ vai trò này nên LUÂN PHIÊN giữa các thành viên — vừa tránh gánh nặng dồn vào một người, vừa giúp cả đội học được kỹ năng điều phối, và người từng làm điều phối viên sẽ hợp tác tốt hơn khi tới lượt người khác |

⚠ Các nguyên nhân thường gặp của hiểu nhầm trong đội: | Nguyên nhân | Cách chữa | |---|---| | ⚠ Giả định rằng người kia đã hiểu | ⚠ yêu cầu nhắc lại bằng lời của họ | | ⚠ Dùng thuật ngữ chuyên môn khác nhau | ⚠ lập bảng thuật ngữ chung | | ⚠ Trao đổi bằng kênh băng thông thấp | ⚠ chuyện phức tạp thì nói chuyện trực tiếp | | ⚠ Không chốt lại sau cuộc họp | ⚠ gửi bản tóm tắt các quyết định | | ⚠ Người im lặng bị hiểu là đồng ý | ⚠ hỏi thẳng từng người | | ⚠ Nguyên nhân nguy hiểm nhất | ⚠ cái cuối cùng — im lặng được diễn giải thành đồng thuận, rồi tới lúc thực hiện mới lộ ra là không ai đồng ý; đó chính là thứ mà cụm "full buy-in" trong đáp án nhắm tới |

⚠ Vì sao Beth không nên tự làm hết: | Lý do | Nội dung | |---|---| | ⚠ Đội tự sở hữu giải pháp thì mới duy trì được | ⚠ liên hệ #26941 lô 204 | | ⚠ Beth không có mặt trong mọi cuộc trao đổi | | | ⚠ Đội học được kỹ năng dùng lại ở dự án sau | | | ⚠ Nhận xét về cách đội hành xử | ⚠ chính đội đã tự bàn cách khắc phục rồi mới mang tới Beth — đó là dấu hiệu của một đội trưởng thành, và phản ứng đúng của Beth là trao cho họ công cụ chứ không phải nhận việc về mình |

Từ khoá nhận diện:

"đội hay hiểu nhầm nhau" → ⚠ NGƯỜI ĐIỀU PHỐI trong đội "lập diễn đàn chia sẻ tri thức" → ⚠ sai loại vấn đề, lại là kênh băng thông thấp "giao hết cho người giỏi giao tiếp nhất" → ⚠ tạo nút thắt và điểm chết "nhắc về an toàn công việc" → ⚠ dùng nỗi sợ, phá huỷ an toàn tâm lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cuộc họp của đội bạn có ai điều phối không | | | Bạn có coi im lặng là đồng ý không | | | Sau họp có bản tóm tắt quyết định không | |

Và điều mà một người điều phối tốt tạo ra, quan trọng hơn cả một cuộc họp trôi chảy: sự chắc chắn rằng khi mọi người rời phòng, họ đang mang theo cùng một hiểu biết.

Câu 593 Process
George is working on calculating the severity of the risks on his project. One of the inputs he will need to calculate this number is the
  1. A Risk action cost
  2. B Risk probability
  3. C ROI
  4. D EMV
Xem giải thích

Đáp án

B — XÁC SUẤT XẢY RA CỦA RỦI RO (risk probability).

Vì sao đúng

⚠ Mức nghiêm trọng của rủi ro được tính thế nào: | Thành phần | Nội dung | |---|---| | ⚠ Mức nghiêm trọng = XÁC SUẤT × TÁC ĐỘNG | ⚠ công thức nền của phân tích định tính | | ⚠ XÁC SUẤT: khả năng rủi ro xảy ra | ⚠ một trong hai đầu vào — ĐÁP ÁN | | ⚠ TÁC ĐỘNG: hậu quả nếu nó xảy ra | ⚠ đầu vào còn lại | | ⚠ Kết quả dùng để XẾP HẠNG rủi ro | ⚠ quyết định rủi ro nào được chú ý trước | | ⚠ Kết luận | ⚠ trong bốn phương án, chỉ có xác suất là đầu vào trực tiếp của phép tính này |

⚠ Vì sao phải xếp hạng: ⚠ một dự án có thể có hàng trăm rủi ro, nhưng nguồn lực để xử lý thì hữu hạn ⚠ — ⚠ điểm nghiêm trọng cho biết nên dồn công sức vào đâu; liên hệ #26928 lô 203.

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

  • D (EMV — giá trị tiền tệ kỳ vọng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ EMV cũng dùng chính xác suất làm đầu vào, cũng là một cách đo mức độ nghiêm trọng, nên nó nghe rất liên quan: ⚠ nhưng ⚠ EMV là ĐẦU RA của một phép tính khác chứ không phải đầu vào — EMV = xác suất × tác động TÍNH BẰNG TIỀN ⚠; ⚠ nó thuộc phân tích ĐỊNH LƯỢNG, còn điểm nghiêm trọng thuộc phân tích ĐỊNH TÍNH; ⚠ và chọn EMV làm đầu vào là lỗi logic: bạn không thể dùng kết quả để tính ra chính thứ tạo ra nó; liên hệ #26810 và #26817 lô 201.

  • A (chi phí của hành động ứng phó rủi ro) — ⚠ cần khi quyết định CÓ NÊN ứng phó hay không; ⚠ nhưng nó không tham gia vào việc tính mức nghiêm trọng.

  • C (ROI) — ⚠ là chỉ số tài chính để đánh giá dự án; ⚠ hoàn toàn không liên quan tới phân tích rủi ro.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26817 lô 201 (so sánh EMV của các phương án), ⚠ #26810 lô 201 (EMV = 0,40 × 600.000), ⚠ #26956 lô 204 (các chiến lược ứng phó rủi ro), ⚠ #26928 lô 203 (nhận diện rủi ro sớm), ⚠ #27059 cùng lô (rủi ro tuân thủ).

⚠ Phân tích ĐỊNH TÍNH và ĐỊNH LƯỢNG: | Định tính | Định lượng | |---|---| | ⚠ Xếp hạng bằng thang: thấp, trung bình, cao | ⚠ tính bằng con số cụ thể | | ⚠ Xác suất × tác động = ĐIỂM NGHIÊM TRỌNG | ⚠ xác suất × tác động tiền = EMV | | ⚠ Làm cho MỌI rủi ro | ⚠ chỉ làm cho rủi ro lớn nhất | | ⚠ Nhanh, rẻ, chủ quan | ⚠ tốn công, cần dữ liệu, khách quan hơn | | ⚠ Công cụ: ma trận xác suất – tác động | ⚠ công cụ: cây quyết định, Monte Carlo | | ⚠ Thứ tự thực hiện | ⚠ luôn định tính TRƯỚC để sàng lọc, rồi mới định lượng cho nhóm rủi ro đứng đầu — làm định lượng cho tất cả là lãng phí công sức lớn |

⚠ Ma trận xác suất – tác động hoạt động ra sao: | Yếu tố | Nội dung | |---|---| | ⚠ Trục dọc: xác suất, thường 5 mức | ⚠ rất thấp tới rất cao | | ⚠ Trục ngang: tác động, thường 5 mức | | | ⚠ Mỗi ô có một điểm số | ⚠ tích của hai mức | | ⚠ Vùng đỏ, vàng, xanh | ⚠ quyết định mức chú ý | | ⚠ Điều tổ chức phải định nghĩa trước | ⚠ thế nào là tác động "cao" — 50.000 đô là cao với dự án này nhưng không đáng kể với dự án kia; không có định nghĩa chung thì điểm số của hai dự án không so được với nhau, xem #26743 lô 200 |

⚠ Cạm bẫy khi dùng điểm nghiêm trọng: | Bẫy | Nội dung | |---|---| | ⚠ Rủi ro xác suất thấp – tác động RẤT cao bị xếp thấp | ⚠ nhưng đó là loại có thể giết dự án — liên hệ #26956 lô 204 | | ⚠ Điểm số tạo cảm giác khách quan giả | ⚠ hai đầu vào đều là ước lượng chủ quan | | ⚠ Xếp hạng một lần rồi không cập nhật | ⚠ liên hệ #26992 lô 205 | | ⚠ Cách giảm thiểu | ⚠ luôn xem lại riêng nhóm rủi ro có TÁC ĐỘNG cực cao dù xác suất thấp — nhiều tổ chức tách hẳn nhóm này ra thành một danh mục riêng thay vì để nó chìm trong bảng xếp hạng chung |

Từ khoá nhận diện:

"đầu vào để tính mức nghiêm trọng" → ⚠ XÁC SUẤT (cùng với tác động) "EMV" → ⚠ là ĐẦU RA của phép nhân, không phải đầu vào "chi phí ứng phó" → ⚠ dùng khi quyết định có ứng phó hay không "ROI" → ⚠ chỉ số tài chính, không liên quan phân tích rủi ro

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có định nghĩa thang tác động chung không | | | Rủi ro hiếm mà nặng của bạn có bị chìm trong bảng xếp hạng không | | | Điểm nghiêm trọng của bạn được cập nhật lần cuối khi nào | |

Và điều mà điểm nghiêm trọng thật sự dùng để làm: quyết định dồn sự chú ý hữu hạn vào đâu — chứ không phải để tạo ra cảm giác rằng rủi ro đã được kiểm soát.

Câu 594 Process
Zachary wants to ensure that his team shares as much product and project knowledge as possible in their agile projects. To do that, they are most likely to use:
  1. A Automated reporting and weekly training sessions
  2. B Kanban boards and wireframes
  3. C Detailed requirements
  4. D Acceptance Test-Driven Development
Xem giải thích

Đáp án

B — BẢNG KANBAN VÀ WIREFRAME (kanban boards and wireframes).

Vì sao đúng

⚠ Vì sao hai công cụ này chia sẻ tri thức tốt nhất: | Công cụ | Chia sẻ tri thức gì | |---|---| | ⚠ BẢNG KANBAN | ⚠ tri thức về DỰ ÁN: ai làm gì, đang tắc ở đâu, còn gì phải làm | | ⚠ WIREFRAME | ⚠ tri thức về SẢN PHẨM: nó trông thế nào, luồng ra sao | | ⚠ Cả hai đều TRỰC QUAN và luôn hiển thị | ⚠ không cần ai hỏi ai | | ⚠ Cả hai đều là nơi các cuộc trò chuyện diễn ra | ⚠ đứng trước bảng mà bàn | | ⚠ Kết luận | ⚠ đề hỏi cả tri thức SẢN PHẨM lẫn tri thức DỰ ÁN, và chỉ phương án này phủ được cả hai |

⚠ Điểm mấu chốt của câu hỏi: ⚠ đề nói "product AND project knowledge" ⚠ — ⚠ đó là gợi ý rằng đáp án phải gồm hai công cụ cho hai loại tri thức; liên hệ #27003 lô 205 về quản lý trực quan.

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

  • D (Phát triển hướng kiểm thử chấp nhận — ATDD) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ ATDD thật sự CÓ chia sẻ tri thức rất tốt: nó buộc ba vai ngồi lại làm rõ yêu cầu, và bộ kiểm thử trở thành tài liệu sống — liên hệ #26994 và #27026 lô 205: ⚠ nhưng ⚠ nó chỉ chạm tới tri thức về SẢN PHẨM và về YÊU CẦU, không nói gì về tri thức DỰ ÁN — ai đang làm gì, tiến độ ra sao, tắc ở đâu ⚠; ⚠ và nó là một thực hành kỹ thuật của đội phát triển phần mềm, trong khi câu hỏi nói về "các dự án agile" nói chung; ⚠ khi đề nêu HAI loại tri thức, hãy tìm phương án phủ được cả hai.

  • C (yêu cầu chi tiết) — ⚠ tài liệu đặc tả dày là cách làm của dự án dự đoán; ⚠ agile ưu tiên phần mềm chạy được hơn tài liệu đầy đủ — liên hệ #26943 lô 204.

  • A (báo cáo tự động và các buổi đào tạo hằng tuần) — ⚠ báo cáo là truyền thông một chiều, đào tạo hằng tuần thì tốn thời gian và không giải quyết tri thức dự án; ⚠ cả hai đều là kênh định kỳ chứ không liên tục.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27003 lô 205 (thẻ trên tường để lập kế hoạch), ⚠ #26965 lô 204 (wireframe để đạt đồng thuận về thiết kế), ⚠ #26924 lô 203 (bảng công việc lộ ra vấn đề dở dang), ⚠ #26948 lô 204 (lập trình đôi truyền tri thức ẩn).

⚠ Bảng Kanban truyền tải những gì mà báo cáo không: | Thông tin | Nội dung | |---|---| | ⚠ Trạng thái thật, ngay lúc này | ⚠ không có độ trễ như báo cáo | | ⚠ Nút thắt nhìn thấy được ngay | ⚠ cột nào chất đống thẻ | | ⚠ Ai đang làm gì | ⚠ không cần hỏi | | ⚠ Lượng việc dở dang | ⚠ liên hệ #26924 lô 203 | | ⚠ Việc còn lại và thứ tự | | | ⚠ Lợi thế lớn nhất | ⚠ nó luôn ĐÚNG vì được cập nhật bởi chính người làm việc — trong khi mọi báo cáo đều là ảnh chụp của một thời điểm đã qua, được viết bởi người không trực tiếp làm |

⚠ Wireframe truyền tải tri thức sản phẩm ra sao: | Cơ chế | Nội dung | |---|---| | ⚠ Ai cũng nhìn vào CÙNG MỘT hình | ⚠ hết mỗi người tưởng tượng một kiểu | | ⚠ Bất đồng lộ ra trong vài phút | | | ⚠ Vẽ thô nên mời gọi góp ý | ⚠ liên hệ #26965 lô 204 | | ⚠ Không cần biết chuyên môn kỹ thuật để đọc | ⚠ bên liên quan cũng tham gia được | | ⚠ Nhận xét | ⚠ hai công cụ này bổ sung cho nhau rất khéo: kanban trả lời "chúng ta đang ở đâu", wireframe trả lời "chúng ta đang xây cái gì" — và một đội trả lời được cả hai câu đó bất cứ lúc nào là một đội đã chia sẻ tri thức rất tốt |

⚠ Các cách chia sẻ tri thức khác trong agile: | Cách | Loại tri thức | |---|---| | ⚠ Lập trình đôi và lập trình theo bầy | ⚠ tri thức ẩn về kỹ thuật — #26948 lô 204 | | ⚠ Buổi rà soát chặng | ⚠ tri thức về sản phẩm cho bên liên quan | | ⚠ Buổi cải tiến | ⚠ tri thức về cách làm việc — #27031 lô 205 | | ⚠ Đội ngồi cùng chỗ | ⚠ mọi loại, qua trao đổi tình cờ | | ⚠ Điểm chung của tất cả | ⚠ agile chia sẻ tri thức bằng cách để người ta CÙNG LÀM và CÙNG NHÌN, chứ không bằng cách viết ra rồi gửi đi — đó là hệ quả trực tiếp của giá trị "cá nhân và tương tác hơn quy trình và công cụ" |

Từ khoá nhận diện:

"chia sẻ cả tri thức SẢN PHẨM lẫn DỰ ÁN" → ⚠ KANBAN + WIREFRAME "ATDD" → ⚠ chỉ chạm tri thức sản phẩm và yêu cầu "yêu cầu chi tiết" → ⚠ cách làm của dự án dự đoán "báo cáo tự động + đào tạo hằng tuần" → ⚠ một chiều và định kỳ, không liên tục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới vào đội bạn nhìn vào đâu để biết đang làm gì | | | Đội bạn có hình vẽ nào về sản phẩm treo ở nơi ai cũng thấy không | | | Tri thức quan trọng nhất của đội đang nằm trong đầu ai | |

Và điều mà hai tấm bảng treo trên tường làm được mà một kho tài liệu không bao giờ làm được: trả lời câu hỏi mà người ta chưa kịp nghĩ ra là mình cần hỏi.

Câu 595 People
Janet is the project manager of a condo construction project for her organization. As part of her role, Janet is responsible for negotiating the contractual terms of the project, which has a $20,000,000 budget. She has identified a contractor she would like to work with and now and must negotiate the terms. Which of the following is she likely to negotiate first?
  1. A Scope
  2. B Schedule
  3. C Price
  4. D Risk
Xem giải thích

Đáp án

A — PHẠM VI (scope).

Vì sao đúng

⚠ Vì sao phạm vi phải bàn trước tiên: | Lý do | Nội dung | |---|---| | ⚠ Không biết làm GÌ thì không định được giá | ⚠ giá là hàm của phạm vi | | ⚠ Không biết làm GÌ thì không lập được tiến độ | | | ⚠ Rủi ro cũng phát sinh từ nội dung công việc | | | ⚠ Ba yếu tố kia đều PHỤ THUỘC vào phạm vi | | | ⚠ Kết luận | ⚠ phạm vi là biến độc lập, tiến độ – giá – rủi ro là các biến phụ thuộc |

⚠ Với dự án 20 triệu đô, sai lệch nhỏ về phạm vi là sai lệch rất lớn về tiền: ⚠ một điều khoản mơ hồ về "hoàn thiện nội thất" có thể chênh nhau hàng triệu đô ⚠ — ⚠ nên thời gian bỏ ra để thống nhất phạm vi luôn được hoàn lại.

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

  • C (giá) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trong thực tế, giá thường là thứ mà cả hai bên quan tâm nhất và hay được đưa ra bàn sớm nhất: ⚠ nhưng ⚠ thương lượng giá khi phạm vi chưa rõ là thương lượng một con số không có nội dung ⚠ — ⚠ nhà thầu sẽ báo giá theo cách hiểu rộng nhất có lợi cho họ, hoặc theo cách hiểu hẹp nhất rồi tính phát sinh về sau; ⚠ và mọi tranh chấp hợp đồng xây dựng lớn đều bắt nguồn từ chỗ hai bên hiểu khác nhau về việc cái gì đã nằm trong giá; ⚠ liên hệ #26946 lô 204 về giá trị của mục loại trừ khỏi phạm vi.

  • B (tiến độ) — ⚠ cũng phụ thuộc vào khối lượng công việc; ⚠ không định được thời gian cho một phạm vi chưa xác định.

  • D (rủi ro) — ⚠ rủi ro phát sinh từ nội dung công việc và cách phân chia trách nhiệm; ⚠ nên nó được bàn sau khi đã rõ ai làm gì.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26933 lô 204 (chiến thuật thương lượng với nhà cung cấp), ⚠ #26946 lô 204 (ranh giới phạm vi), ⚠ #27066 cùng lô (bản mô tả công việc trong hợp đồng), ⚠ #26962 lô 204 (phạm vi là nền của mọi quyết định).

⚠ Thứ tự thương lượng hợp lý: | Thứ tự | Nội dung | |---|---| | ⚠ 1. PHẠM VI | ⚠ làm gì, không làm gì, tiêu chí chấp nhận — ĐÁP ÁN | | ⚠ 2. TIẾN ĐỘ | ⚠ khi nào giao, các mốc trung gian | | ⚠ 3. GIÁ và điều khoản thanh toán | ⚠ giờ mới định giá được | | ⚠ 4. Phân chia RỦI RO | ⚠ ai gánh chuyện gì khi có biến | | ⚠ 5. Các điều khoản khác | ⚠ bảo hành, phạt, chấm dứt, tranh chấp | | ⚠ Lưu ý | ⚠ trong thực tế các yếu tố này được bàn đan xen và có đánh đổi qua lại — nhưng phạm vi vẫn phải được LÀM RÕ trước, vì mọi cuộc mặc cả về ba yếu tố sau đều là mặc cả về những phần cụ thể của phạm vi |

⚠ Bản mô tả công việc (SOW) cần rõ tới mức nào: | Yêu cầu | Nội dung | |---|---| | ⚠ Mô tả sản phẩm bàn giao cụ thể, đo được | | | ⚠ Tiêu chuẩn kỹ thuật và chất lượng áp dụng | ⚠ liên hệ #27000 lô 205 về chỉ số chất lượng | | ⚠ Những gì KHÔNG thuộc phạm vi hợp đồng | ⚠ mục quý nhất | | ⚠ Trách nhiệm của mỗi bên | ⚠ ai cấp vật tư, ai lo giấy phép | | ⚠ Tiêu chí nghiệm thu | | | ⚠ Phép thử đơn giản | ⚠ đưa bản mô tả cho một người thứ ba đọc và hỏi họ hiểu nhà thầu phải giao cái gì — nếu câu trả lời của họ khác với câu trả lời của bạn thì bản mô tả chưa xong |

⚠ Vì sao thứ tự này quan trọng với dự án 20 triệu đô: | Rủi ro nếu làm ngược | Nội dung | |---|---| | ⚠ Chốt giá rồi mới làm rõ phạm vi | ⚠ mọi làm rõ đều thành yêu cầu phát sinh | | ⚠ Nhà thầu bù rủi ro phạm vi mơ hồ vào giá | ⚠ bạn trả tiền cho sự không chắc chắn | | ⚠ Tranh chấp về việc "cái đó có trong hợp đồng không" | | | ⚠ Nhận xét | ⚠ trong hợp đồng lớn, phần đắt nhất thường không phải là thứ được ghi trong đó mà là thứ KHÔNG được ghi rõ — và mỗi vùng mơ hồ đều sẽ được diễn giải theo hướng có lợi cho bên đang cầm bút |

Từ khoá nhận diện:

"thương lượng hợp đồng, bàn gì trước" → ⚠ PHẠM VI "giá" → ⚠ không định giá được cho một phạm vi chưa rõ "tiến độ" → ⚠ phụ thuộc vào khối lượng công việc "rủi ro" → ⚠ phát sinh từ nội dung công việc, bàn sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có mục loại trừ khỏi phạm vi không | | | Hai bên có hiểu giống nhau về từng sản phẩm bàn giao không | | | Bạn bàn giá trước hay bàn phạm vi trước | |

Và lý do phạm vi luôn phải đứng đầu bàn thương lượng: giá là một câu trả lời, và bạn không thể mặc cả một câu trả lời khi chưa thống nhất được câu hỏi.

Câu 596 Process
You are the project manager for your organization. Your latest project is to create a web interface that allows customers to purchase items from an online catalog. If you create the product in-house, it will cost $150,000 to create and nearly $4,500 each month in administration costs and fees. A vendor has supplied a quote to create the software for $160,000 and to handle the administration for 5 cents per transaction. There are expected to be 65,000 transactions each month. Which one of the following will help you determine which decision has the best value?
  1. A A decision tree
  2. B A Pareto chart
  3. C Trend analysis
  4. D A control chart
Xem giải thích

Đáp án

A — CÂY QUYẾT ĐỊNH (a decision tree).

Vì sao đúng

⚠ Vì sao cây quyết định là công cụ đúng: | Đặc điểm bài toán | Cây quyết định xử lý thế nào | |---|---| | ⚠ Có HAI phương án loại trừ nhau | ⚠ tự làm hay thuê ngoài — hai nhánh | | ⚠ Mỗi phương án có chi phí ban đầu và chi phí định kỳ | ⚠ tính tổng chi phí cho từng nhánh | | ⚠ Cần so sánh GIÁ TRỊ của hai lựa chọn | ⚠ đúng mục đích của cây quyết định | | ⚠ Có thể mở rộng cho các kịch bản có xác suất | | | ⚠ Kết luận | ⚠ cây quyết định là công cụ chuẩn cho bài toán tự làm hay mua (make-or-buy) |

⚠ Số học của chính bài toán này: | Khoản | Tự làm | Thuê ngoài | |---|---|---| | ⚠ Chi phí ban đầu | ⚠ 150.000 | ⚠ 160.000 | | ⚠ Chi phí mỗi tháng | ⚠ 4.500 | ⚠ 65.000 × 0,05 = 3.250 | | ⚠ Chênh lệch ban đầu | ⚠ thuê ngoài đắt hơn 10.000 | | | ⚠ Tiết kiệm mỗi tháng khi thuê ngoài | ⚠ 4.500 − 3.250 = 1.250 | | | ⚠ ĐIỂM HOÀ VỐN | ⚠ 10.000 ÷ 1.250 = 8 tháng | | | ⚠ Kết luận | ⚠ dùng trên 8 tháng thì thuê ngoài rẻ hơn; ví dụ sau 24 tháng: tự làm 258.000, thuê ngoài 238.000 |

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

  • C (phân tích xu hướng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ bài toán có yếu tố THỜI GIAN (chi phí hằng tháng), nên "xu hướng" nghe như đúng thứ cần phân tích: ⚠ nhưng ⚠ phân tích xu hướng dùng DỮ LIỆU QUÁ KHỨ để dự báo tương lai của một thứ đang diễn ra ⚠ — ⚠ ở đây chưa có gì diễn ra cả, ta đang so sánh hai phương án chưa được chọn; ⚠ liên hệ #26895 lô 203: phân tích xu hướng dùng để theo dõi hiệu suất dự án đang chạy, không dùng để chọn giữa hai lựa chọn.

  • B (biểu đồ Pareto) — ⚠ là công cụ CHẤT LƯỢNG; ⚠ nó xếp hạng các loại lỗi theo tần suất để tìm nhóm gây ra phần lớn vấn đề — liên hệ #27024 lô 205.

  • D (biểu đồ kiểm soát) — ⚠ cũng là công cụ chất lượng; ⚠ nó phân biệt biến thiên thông thường với nguyên nhân đặc biệt — liên hệ #27011 lô 205.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26691 lô 199 (mua – thuê – điểm hoà vốn), ⚠ #26996 lô 205 (so sánh giá trị hai dự án), ⚠ #26817 lô 201 (so sánh EMV của các phương án), ⚠ #26895 lô 203 (phân tích xu hướng dùng khi nào).

⚠ Cây quyết định gồm những gì: | Thành phần | Ký hiệu và ý nghĩa | |---|---| | ⚠ Nút QUYẾT ĐỊNH | ⚠ hình vuông — nơi ta chọn | | ⚠ Nút CƠ HỘI | ⚠ hình tròn — nơi may rủi quyết định | | ⚠ Nhánh | ⚠ các phương án hoặc kết quả có thể | | ⚠ Xác suất trên mỗi nhánh cơ hội | ⚠ cộng lại bằng 100% | | ⚠ Giá trị ở cuối mỗi nhánh | ⚠ chi phí hoặc lợi ích | | ⚠ Cách tính | ⚠ tính ngược từ phải sang trái: nhân xác suất với giá trị ở các nút cơ hội để ra EMV, rồi chọn nhánh tốt nhất ở các nút quyết định — liên hệ #26817 lô 201 |

⚠ Bài toán tự làm hay mua cần xem thêm gì ngoài tiền: | Yếu tố | Nội dung | |---|---| | ⚠ Năng lực nội bộ có sẵn không | ⚠ liên hệ #27010 lô 205 về xác định kỹ năng | | ⚠ Đây có phải năng lực CỐT LÕI cần giữ không | ⚠ thuê ngoài thì tri thức ra ngoài — #26948 lô 204 | | ⚠ Rủi ro phụ thuộc nhà cung cấp | ⚠ liên hệ #26933 lô 204 | | ⚠ Thời gian đưa ra thị trường | | | ⚠ Dự kiến dùng bao lâu | ⚠ quyết định điểm hoà vốn có ý nghĩa hay không | | ⚠ Điểm mấu chốt trong bài này | ⚠ con số 8 tháng chỉ có nghĩa khi biết hệ thống sẽ được dùng bao lâu — nếu đây là giải pháp tạm cho sáu tháng thì tự làm rẻ hơn, còn nếu dùng nhiều năm thì thuê ngoài thắng rõ rệt |

⚠ Phân biệt bốn công cụ trong bốn phương án: | Công cụ | Dùng để | |---|---| | ⚠ CÂY QUYẾT ĐỊNH | ⚠ chọn giữa các phương án có chi phí và xác suất — ĐÁP ÁN | | ⚠ Biểu đồ Pareto | ⚠ tìm ít nguyên nhân gây phần lớn vấn đề | | ⚠ Phân tích xu hướng | ⚠ dự báo tương lai từ dữ liệu quá khứ | | ⚠ Biểu đồ kiểm soát | ⚠ theo dõi một quy trình có ổn định không | | ⚠ Mẹo phân biệt nhanh | ⚠ ba công cụ sau đều cần DỮ LIỆU ĐÃ CÓ về một thứ đang diễn ra; chỉ cây quyết định làm việc với các phương án CHƯA xảy ra — và câu hỏi ở đây rõ ràng là về một lựa chọn chưa được đưa ra |

Từ khoá nhận diện:

"chọn giữa tự làm và thuê ngoài" → ⚠ CÂY QUYẾT ĐỊNH "phân tích xu hướng" → ⚠ cần dữ liệu quá khứ của thứ đang diễn ra "Pareto / biểu đồ kiểm soát" → ⚠ công cụ chất lượng "điểm hoà vốn" → ⚠ 10.000 ÷ 1.250 = 8 tháng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn tự tính lại 65.000 × 0,05 = 3.250 chưa | | | Bạn biết hệ thống sẽ được dùng bao lâu không | | | Quyết định tự làm hay mua của bạn có tính tới năng lực cốt lõi không | |

Và điều mà một phép tính điểm hoà vốn buộc phải hỏi trước khi trả lời: thứ này sẽ được dùng trong bao lâu — vì trước khi có câu trả lời đó, cả hai phương án đều có thể là phương án rẻ hơn.

Câu 597 Process
Adam wants to let the other stakeholders know about an issue he is having on their project. The most appropriate way to do this in an agile project is to:
  1. A Discuss this in the next daily standup with the team.
  2. B Share this information in their next sprint review.
  3. C Document this issue in an email so it can be added to the risk log.
  4. D Share this information with the scrum master, who would then ask him to share this in the daily standup.
Xem giải thích

Đáp án

A — NÊU CHUYỆN NÀY VỚI ĐỘI Ở BUỔI HỌP ĐỨNG TIẾP THEO.

Vì sao đúng

⚠ Vì sao buổi họp đứng là kênh đúng: | Lý do | Nội dung | |---|---| | ⚠ Đây là kênh CHÍNH THỨC để nêu vật cản và vấn đề | ⚠ một trong ba câu hỏi chuẩn | | ⚠ Diễn ra hằng ngày nên nhanh nhất | ⚠ không phải chờ tới cuối chặng | | ⚠ Cả đội cùng nghe, ai giúp được sẽ lên tiếng | | | ⚠ Adam tự nêu, không cần trung gian | ⚠ đội tự tổ chức | | ⚠ Kết luận | ⚠ dùng đúng cơ chế đã có, ở nhịp nhanh nhất, không qua ai cả |

⚠ Chi tiết đáng chú ý: ⚠ đề nói Adam muốn cho "các bên liên quan khác" biết, và trong ngữ cảnh agile thì đội chính là nhóm bên liên quan gần nhất và có khả năng giúp nhất ⚠ — ⚠ nếu vấn đề vượt tầm đội thì scrum master sẽ leo thang sau đó.

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

  • D (nói với scrum master, rồi người này sẽ bảo anh ấy nêu ở buổi họp đứng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó dẫn tới ĐÚNG cùng một kết quả cuối cùng, và việc báo cho scrum master nghe rất đúng quy trình: ⚠ nhưng ⚠ nó thêm một bước trung gian hoàn toàn thừa ⚠ — ⚠ Adam có thể nêu thẳng, và chính scrum master cũng có mặt ở buổi họp đứng để nghe; ⚠ quan trọng hơn về mặt nguyên tắc: đội agile TỰ TỔ CHỨC, không cần xin phép ai để nêu một vấn đề; ⚠ thói quen phải "báo cáo lên trên trước" là dấu hiệu của tư duy phân cấp còn sót lại, và nó làm chậm mọi vòng phản hồi.

  • B (chia sẻ ở buổi rà soát chặng tiếp theo) — ⚠ quá muộn; ⚠ buổi rà soát chặng có thể còn cách hai tuần, và nó dành để trình diễn sản phẩm chứ không phải nêu vấn đề nội bộ.

  • C (ghi vào email để đưa vào sổ rủi ro) — ⚠ nhầm VẤN ĐỀ với RỦI RO; ⚠ vấn đề đã xảy ra thì vào sổ vấn đề, không vào sổ rủi ro — liên hệ #27033 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26911 lô 203 (hỏi về vật cản trong buổi họp đứng), ⚠ #27027 lô 205 (thế nào là một vật cản thật), ⚠ #27033 cùng lô (sổ vấn đề khác sổ rủi ro), ⚠ #26980 lô 204 (họp đứng để đồng bộ).

⚠ Nêu vấn đề ở đâu, theo mức độ: | Mức | Kênh | |---|---| | ⚠ Vấn đề hằng ngày, cần đội biết | ⚠ HỌP ĐỨNG — ĐÁP ÁN | | ⚠ Vấn đề về cách làm việc của đội | ⚠ buổi cải tiến | | ⚠ Vấn đề về sản phẩm cần bên liên quan biết | ⚠ buổi rà soát chặng | | ⚠ Vấn đề vượt tầm đội | ⚠ scrum master leo thang | | ⚠ Vấn đề khẩn cấp | ⚠ nói ngay, không chờ họp nào cả | | ⚠ Nguyên tắc chung | ⚠ dùng kênh NHANH NHẤT phù hợp với mức độ — chờ đúng buổi họp cho một chuyện gấp là hình thức chủ nghĩa, còn triệu tập cả đội cho một chuyện nhỏ là lãng phí |

⚠ Phân biệt vấn đề, rủi ro và vật cản: | Khái niệm | Đặc điểm | Ghi ở đâu | |---|---|---| | ⚠ RỦI RO | ⚠ chưa xảy ra, có thể xảy ra | ⚠ sổ rủi ro | | ⚠ VẤN ĐỀ | ⚠ đã xảy ra, cần xử lý | ⚠ sổ vấn đề | | ⚠ VẬT CẢN | ⚠ vấn đề đang CHẶN ĐỨNG công việc | ⚠ bảng vật cản, nêu ngay trong họp đứng | | ⚠ Nhầm lẫn phổ biến nhất | ⚠ ghi một vấn đề đã xảy ra vào sổ rủi ro — nó sẽ nằm đó chờ "theo dõi" trong khi thứ nó cần là một người xử lý và một hạn chót |

⚠ Vì sao đội tự nêu tốt hơn qua trung gian: | Lợi ích | Nội dung | |---|---| | ⚠ Nhanh hơn, ít nhất một vòng | | | ⚠ Thông tin không bị tam sao thất bản | ⚠ người gặp vấn đề mô tả chính xác nhất | | ⚠ Người khác trong đội có thể đã gặp rồi | ⚠ và có sẵn cách xử lý | | ⚠ Củng cố văn hoá tự tổ chức | | | ⚠ Vai trò thật của scrum master | ⚠ không phải là người trung chuyển thông tin, mà là người GỠ những vật cản mà đội không tự gỡ được — nếu mọi thứ đều phải đi qua họ thì họ trở thành nút thắt thay vì người dọn đường |

Từ khoá nhận diện:

"nêu vấn đề trong dự án agile" → ⚠ BUỔI HỌP ĐỨNG tiếp theo "báo scrum master để họ bảo mình nêu" → ⚠ bước trung gian thừa "chờ buổi rà soát chặng" → ⚠ quá muộn và sai mục đích buổi họp "ghi vào sổ rủi ro" → ⚠ vấn đề đã xảy ra thì vào SỔ VẤN ĐỀ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có nêu thẳng vấn đề hay phải qua người quản lý | | | Vấn đề đã xảy ra của bạn đang nằm trong sổ nào | | | Từ lúc gặp vấn đề tới lúc cả đội biết mất bao lâu | |

Và điều mà một đội tự nêu vấn đề thẳng với nhau tiết kiệm được, ngoài thời gian: độ chính xác của thông tin — vì mỗi lần một vấn đề được kể lại, nó lại mất đi một phần chi tiết mà người giải quyết cần.

Câu 598 Process
Lenny is the project manager of the GHA Project for his company. A recent earned value management calculation shows that Lenny has a CPI of 0.98 on this project. A project that has a CPI of 0.98 means what?
  1. A The project is making money.
  2. B The project is 98 percent complete.
  3. C The project is late.
  4. D The project must spend one dollar for every 98 cents of work it receives.
Xem giải thích

Đáp án

D — DỰ ÁN PHẢI CHI MỘT ĐÔ LA CHO MỖI 98 XU GIÁ TRỊ CÔNG VIỆC THU ĐƯỢC.

Vì sao đúng

⚠ Đọc CPI cho đúng: | Yếu tố | Nội dung | |---|---| | ⚠ CPI = EV ÷ AC | ⚠ giá trị thu được chia chi phí thực tế | | ⚠ CPI = 0,98 nghĩa là mỗi đồng chi ra thu về 0,98 đồng giá trị | | | ⚠ Nói cách khác: chi 1 đô để nhận 98 xu công việc | ⚠ đúng phương án D | | ⚠ Dưới 1 = VƯỢT CHI, dù chỉ nhẹ | | | ⚠ Đánh giá mức độ | ⚠ 0,98 là vượt chi khoảng 2% — nhẹ, nhưng vẫn là vượt chi |

⚠ Cách đọc nhanh mọi chỉ số PI: ⚠ trên 1 là tốt, bằng 1 là đúng kế hoạch, dưới 1 là xấu ⚠ — ⚠ và con số cho biết cả MỨC ĐỘ: 0,98 lệch 2%, 0,80 lệch 20%; liên hệ #27058 cùng lô.

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

  • A (dự án đang có lãi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ 0,98 gần bằng 1 nên nghe như "gần đúng kế hoạch", và nhiều người dịch "gần đúng" thành "ổn, đang có lãi": ⚠ nhưng ⚠ CPI đo HIỆU QUẢ CHI PHÍ so với kế hoạch, hoàn toàn không nói gì về LỢI NHUẬN ⚠ — ⚠ một dự án nội bộ không tạo doanh thu vẫn có CPI, và một dự án CPI 1,2 vẫn có thể lỗ nếu giá bán quá thấp; ⚠ hơn nữa, 0,98 là dưới 1 nên nó đang vượt chi chứ không phải tiết kiệm; ⚠ hai lỗi trong cùng một phương án: sai khái niệm và sai chiều.

  • B (dự án hoàn thành 98%) — ⚠ nhầm CPI với phần trăm hoàn thành; ⚠ hai đại lượng hoàn toàn khác nhau, một dự án mới xong 10% vẫn có thể có CPI 0,98.

  • C (dự án bị chậm tiến độ) — ⚠ nhầm CPI với SPI; ⚠ chỉ số tiến độ là SPI = EV ÷ PV — liên hệ #26982 lô 204.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27058 cùng lô (CPI = 0,80 trong cùng bài toán với SPI), ⚠ #26982 lô 204 (SPI = 0,67, cùng bộ số), ⚠ #26922 lô 203 (CPI = 0,87 khi dự án đã xong), ⚠ #26812 lô 201 (CPI = 0,89).

⚠ Bảng đọc nhanh các chỉ số: | Chỉ số | Công thức | Đọc | |---|---|---| | ⚠ CPI | ⚠ EV ÷ AC | ⚠ >1 tiết kiệm, <1 vượt chi — câu này | | ⚠ SPI | ⚠ EV ÷ PV | ⚠ >1 sớm, <1 chậm | | ⚠ CV | ⚠ EV − AC | ⚠ dương là tiết kiệm, âm là vượt chi (tiền) | | ⚠ SV | ⚠ EV − PV | ⚠ dương là sớm, âm là chậm (tiền) | | ⚠ Mẹo nhớ tổng quát | ⚠ EV luôn ở đầu; CHIA ra chỉ số không đơn vị, TRỪ ra chênh lệch bằng tiền; chữ C gắn với AC (chi phí thực), chữ S gắn với PV (kế hoạch) |

⚠ CPI 0,98 nên được xử lý thế nào: | Góc nhìn | Nội dung | |---|---| | ⚠ Mức vượt chi chỉ khoảng 2% | ⚠ nằm trong sai số của phần lớn dự án | | ⚠ Nhưng cần xem XU HƯỚNG | ⚠ 0,98 rồi 0,96 rồi 0,94 là chuyện khác hẳn | | ⚠ Và cần biết dự án đang ở giai đoạn nào | ⚠ 0,98 ở tháng đầu đáng lo hơn ở tháng cuối | | ⚠ Điều quan trọng nhất | ⚠ một chỉ số đơn lẻ gần như không nói lên điều gì — giá trị của EVM nằm ở việc theo dõi chuỗi số qua nhiều kỳ; liên hệ #26895 lô 203 về phân tích xu hướng |

⚠ Những điều CPI KHÔNG nói cho bạn biết: | Không nói về | Vì sao | |---|---| | ⚠ Lợi nhuận của dự án | ⚠ CPI so với NGÂN SÁCH, không so với doanh thu | | ⚠ Tiến độ | ⚠ đó là việc của SPI | | ⚠ Phần trăm hoàn thành | ⚠ đó là EV ÷ BAC | | ⚠ Chất lượng sản phẩm | ⚠ hoàn toàn không đo | | ⚠ Cảnh báo thực tế | ⚠ một dự án có thể có CPI đẹp nhờ cắt bớt kiểm thử và làm ẩu — nên CPI luôn phải được đọc cùng với các chỉ số chất lượng, không bao giờ đọc một mình; liên hệ #27024 lô 205 |

Từ khoá nhận diện:

"CPI = 0,98" → ⚠ chi 1 đô nhận 98 xu giá trị, VƯỢT CHI nhẹ "dự án đang có lãi" → ⚠ CPI không nói gì về lợi nhuận, và 0,98 là vượt chi "hoàn thành 98%" → ⚠ nhầm với EV ÷ BAC "bị chậm tiến độ" → ⚠ nhầm CPI với SPI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CPI của bạn qua ba kỳ gần nhất là bao nhiêu | | | Xu hướng đang đi lên hay đi xuống | | | Bạn có đọc CPI cùng với chỉ số chất lượng không | |

Và điều mà một CPI 0,98 nói ít hơn nhiều so với vẻ chính xác của nó: nó chỉ cho biết hôm nay bạn đang ở đâu, còn thứ đáng lo hay đáng mừng nằm ở việc bạn đã đi từ đâu tới đó.

Câu 599 Process
The most significant way that stakeholder management in an agile project differs from that done in a traditional project is:
  1. A It focuses only on communicating information via information radiators.
  2. B It is focused on letting the team decide what they want to tell the stakeholders.
  3. C It is not focused on telling people what they should do and controlling their tasks.
  4. D Stakeholders are a much smaller group, so managing is easier.
Xem giải thích

Đáp án

C — NÓ KHÔNG TẬP TRUNG VÀO VIỆC BẢO NGƯỜI TA PHẢI LÀM GÌ VÀ KIỂM SOÁT CÔNG VIỆC CỦA HỌ.

Vì sao đúng

⚠ Khác biệt cốt lõi giữa hai cách tiếp cận: | Dự đoán | Agile | |---|---| | ⚠ Bên liên quan được QUẢN LÝ và KIỂM SOÁT | ⚠ bên liên quan được THU HÚT và CỘNG TÁC | | ⚠ Thông tin được phân phối theo kế hoạch | ⚠ thông tin luôn sẵn có, họ tự lấy | | ⚠ Tham gia ở các mốc định sẵn | ⚠ tham gia liên tục mỗi chặng | | ⚠ Người quản lý là trung tâm điều phối | ⚠ đội và bên liên quan nói chuyện trực tiếp | | ⚠ Kết luận | ⚠ agile chuyển từ KIỂM SOÁT sang CỘNG TÁC — đó là khác biệt lớn nhất |

⚠ Ngay cả từ vựng cũng phản ánh điều này: ⚠ PMI đã đổi tên lĩnh vực từ "quản lý bên liên quan" sang "THU HÚT bên liên quan" ⚠ — ⚠ vì bạn không thật sự "quản lý" được những người không thuộc quyền mình.

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

  • B (nó tập trung vào việc để đội tự quyết muốn nói gì với bên liên quan) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ agile ĐÚNG LÀ trao rất nhiều quyền tự chủ cho đội, và đội đúng là nói chuyện trực tiếp với bên liên quan: ⚠ nhưng ⚠ nó biến sự tự chủ thành quyền lựa chọn thông tin nào được chia sẻ, tức là ngược hẳn với nguyên tắc MINH BẠCH của agile ⚠; ⚠ agile hướng tới việc mọi thứ đều hiển thị: bảng công việc, biểu đồ burndown, sản phẩm chạy được mỗi chặng — không có chuyện đội chọn lọc điều muốn cho biết; ⚠ liên hệ #27003 lô 205 về radiator thông tin: thông tin toả ra chứ không được phân phát có chọn lọc.

  • A (chỉ tập trung vào việc truyền tin qua các radiator thông tin) — ⚠ chữ "CHỈ" làm phương án này sai; ⚠ radiator là một công cụ quan trọng nhưng agile còn nhấn mạnh đối thoại trực tiếp và buổi rà soát chặng.

  • D (nhóm bên liên quan nhỏ hơn nhiều nên dễ quản lý hơn) — ⚠ không có cơ sở; ⚠ số lượng bên liên quan phụ thuộc vào bản chất dự án, không phụ thuộc vào phương pháp.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26953 lô 204 (mối lo của người ngoài với dự án lặp), ⚠ #26942 lô 204 (bên liên quan dự buổi rà soát chặng), ⚠ #27003 lô 205 (quản lý trực quan), ⚠ #26943 lô 204 (hợp tác với khách hàng hơn thương lượng hợp đồng).

⚠ Thu hút bên liên quan trong agile diễn ra ở đâu: | Cơ chế | Nội dung | |---|---| | ⚠ Buổi rà soát chặng | ⚠ bên liên quan thấy sản phẩm thật và cho phản hồi | | ⚠ Chủ sản phẩm là cầu nối thường trực | | | ⚠ Radiator thông tin luôn hiển thị | ⚠ ai muốn biết thì tự xem | | ⚠ Bên liên quan tham gia xếp thứ tự tồn đọng | | | ⚠ Đội và bên liên quan nói chuyện trực tiếp | ⚠ không qua trung gian | | ⚠ Điểm khác biệt lớn nhất về tần suất | ⚠ dự đoán cho bên liên quan vài cơ hội tác động ở các mốc; agile cho họ một cơ hội ở MỖI chặng — nên tổng số lần họ can thiệp nhiều hơn hẳn, chỉ là mỗi lần nhỏ hơn |

⚠ Vì sao "kiểm soát" không hoạt động với bên liên quan: | Lý do | Nội dung | |---|---| | ⚠ Phần lớn họ không thuộc quyền người quản lý dự án | | | ⚠ Họ có ưu tiên riêng và sếp riêng | | | ⚠ Ép buộc tạo ra kháng cự ngầm | ⚠ liên hệ #26913 lô 203 | | ⚠ Sự tham gia thật không ép được | | | ⚠ Thứ thay thế cho kiểm soát | ⚠ ẢNH HƯỞNG — xây trên uy tín, minh bạch và việc giữ lời; liên hệ #26989 lô 205 về năng lực ảnh hưởng |

⚠ Điều KHÔNG đổi giữa hai cách tiếp cận: | Việc | Nội dung | |---|---| | ⚠ Vẫn phải NHẬN DIỆN bên liên quan | ⚠ liên hệ #26957 lô 204 | | ⚠ Vẫn phải hiểu quyền lực và ảnh hưởng của họ | ⚠ liên hệ #27030 lô 205 | | ⚠ Vẫn phải điều chỉnh cách trao đổi theo từng người | ⚠ liên hệ #27006 lô 205 | | ⚠ Vẫn phải theo dõi thái độ của họ | | | ⚠ Nhận xét | ⚠ agile không bỏ bất kỳ việc nào trong số này — nó chỉ đổi cách thực hiện chúng, từ lập kế hoạch một lần rồi thi hành sang điều chỉnh liên tục theo phản hồi thật |

Từ khoá nhận diện:

"khác biệt lớn nhất của quản lý bên liên quan trong agile" → ⚠ không KIỂM SOÁT, mà CỘNG TÁC "đội tự quyết nói gì với bên liên quan" → ⚠ ngược với nguyên tắc minh bạch "CHỈ dùng radiator thông tin" → ⚠ chữ CHỈ làm phương án sai "nhóm bên liên quan nhỏ hơn" → ⚠ không có cơ sở

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn tự xem được tiến độ hay phải chờ báo cáo | | | Đội bạn có nói chuyện trực tiếp với bên liên quan không | | | Bạn đang kiểm soát hay đang tạo điều kiện | |

Và điều mà việc đổi từ "quản lý" sang "thu hút" bên liên quan thừa nhận: rằng phần lớn những người quyết định số phận dự án của bạn đều không làm việc cho bạn.

Câu 600 Process
You are a project manager for your organization, and you are using a hybrid approach to your projects. Some of the predictive project management approach elements work well, and you are utilizing the iterative approach in agile. In your hybrid approach, management would like for you to identify each deliverable within the WBS with a number. The numbering system you should use with your WBS is called what?
  1. A Chart of accounts.
  2. B Hybrid projects do not use a WBS.
  3. C Code of accounts.
  4. D WBS dictionary.
Xem giải thích

Đáp án

C — MÃ TÀI KHOẢN (code of accounts).

Vì sao đúng

⚠ Mã tài khoản là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Hệ thống ĐÁNH SỐ cho từng thành phần của WBS | ⚠ đúng thứ đề mô tả | | ⚠ Có cấu trúc phân cấp: 1, 1.1, 1.1.1 | ⚠ phản ánh cây phân rã | | ⚠ Cho phép tổng hợp chi phí từ dưới lên | ⚠ cộng dồn theo nhánh | | ⚠ Là mã định danh duy nhất của mỗi thành phần | | | ⚠ Kết luận | ⚠ đây là tên chính thức của hệ thống đánh số WBS trong tài liệu PMI |

⚠ Vì sao đánh số lại quan trọng: ⚠ nó cho phép nói về một gói công việc mà không cần đọc cả tên dài, và cho phép nối WBS với hệ thống kế toán, tiến độ, và báo cáo ⚠ — ⚠ liên hệ #26910 lô 203.

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

  • A (biểu đồ tài khoản — chart of accounts) — ⚠ phương án gây nhiễu mạnh nhất, và là một cặp khái niệm cố tình đặt cạnh nhau vì ⚠ hai tên gọi gần như giống hệt và cả hai đều liên quan tới việc mã hoá chi phí: ⚠ nhưng ⚠ BIỂU ĐỒ tài khoản là hệ thống mã KẾ TOÁN của TỔ CHỨC — nó phân loại chi phí theo lương, vật tư, khấu hao, và dùng cho toàn công ty ⚠; ⚠ còn MÃ tài khoản là hệ thống đánh số của một WBS CỤ THỂ của một dự án; ⚠ mẹo nhớ: "code" gắn với WBS của dự án, "chart" gắn với sổ sách của tổ chức — và mã tài khoản của dự án thường được ÁNH XẠ vào biểu đồ tài khoản của công ty để chi phí dự án vào đúng đầu mục kế toán.

  • D (từ điển WBS) — ⚠ là tài liệu MÔ TẢ CHI TIẾT từng gói công việc; ⚠ nó chứa mã tài khoản như một trường thông tin, nhưng bản thân nó không phải hệ thống đánh số.

  • B (dự án lai không dùng WBS) — ⚠ sai; ⚠ dự án lai dùng WBS cho phần dự đoán và tồn đọng cho phần lặp, và chính đề đã nói lãnh đạo muốn có WBS.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26910 lô 203 (cập nhật bản phạm vi, WBS và từ điển WBS), ⚠ #27021 lô 205 (WBS không phải danh mục kiểm tra), ⚠ #26912 lô 203 (từ WBS tới trình tự hoạt động), ⚠ #26962 lô 204 (phạm vi là nền của mọi thứ).

⚠ Bộ ba tài liệu phạm vi và vai trò từng cái: | Tài liệu | Nội dung | |---|---| | ⚠ Bản tuyên bố phạm vi | ⚠ mô tả phạm vi bằng lời, kèm loại trừ và tiêu chí chấp nhận | | ⚠ WBS | ⚠ cây phân rã sản phẩm bàn giao thành gói công việc | | ⚠ MÃ TÀI KHOẢN | ⚠ hệ thống đánh số cho cây đó — ĐÁP ÁN | | ⚠ Từ điển WBS | ⚠ mô tả chi tiết từng gói: nội dung, tiêu chí, nguồn lực, chi phí | | ⚠ Cả bốn hợp thành | ⚠ đường cơ sở phạm vi — chỉ thay đổi được qua kiểm soát thay đổi; liên hệ #26964 lô 204 |

⚠ Mã tài khoản dùng để làm gì trong thực tế: | Ứng dụng | Nội dung | |---|---| | ⚠ Tổng hợp chi phí theo nhánh | ⚠ cộng 1.1.1 và 1.1.2 ra 1.1 | | ⚠ Nối WBS với phần mềm quản lý dự án | | | ⚠ Báo cáo theo bất kỳ cấp nào của cây | ⚠ lãnh đạo xem cấp 1, đội xem cấp 3 | | ⚠ Ánh xạ sang hệ thống kế toán tổ chức | ⚠ qua biểu đồ tài khoản | | ⚠ Tham chiếu ngắn gọn khi trao đổi | ⚠ "gói 2.3.4" thay vì đọc cả tên | | ⚠ Giá trị thực dụng lớn nhất | ⚠ khả năng tổng hợp theo nhiều cấp — nó cho phép cùng một dữ liệu phục vụ cả người quản lý gói công việc lẫn nhà tài trợ, mà không cần lập hai hệ thống báo cáo |

⚠ WBS trong dự án lai: | Phần | Cách tổ chức | |---|---| | ⚠ Phần dự đoán, đã rõ yêu cầu | ⚠ WBS chi tiết tới gói công việc | | ⚠ Phần lặp, còn nhiều bất định | ⚠ để ở mức khái quát, chi tiết dần theo chặng | | ⚠ Điểm nối giữa hai phần | ⚠ phải được định nghĩa rõ ràng | | ⚠ Nguyên tắc | ⚠ lập kế hoạch theo lớp sóng áp dụng được cho cả WBS — phần gần thì chi tiết, phần xa thì thô; liên hệ #26869 lô 202 và #26981 lô 204 |

Từ khoá nhận diện:

"hệ thống đánh số cho từng thành phần WBS" → ⚠ MÃ TÀI KHOẢN (code of accounts) "biểu đồ tài khoản" → ⚠ hệ thống mã KẾ TOÁN của tổ chức "từ điển WBS" → ⚠ mô tả chi tiết từng gói, không phải hệ thống số "dự án lai không dùng WBS" → ⚠ sai, vẫn dùng cho phần dự đoán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WBS của bạn có được đánh số theo cấp không | | | Mã đó có nối được với hệ thống kế toán của công ty không | | | Bạn báo cáo được ở nhiều cấp từ cùng một dữ liệu không | |

Và điều mà một hệ thống đánh số tưởng như khô khan mang lại: khả năng nói về cùng một công việc theo nhiều mức chi tiết mà không ai hiểu nhầm là đang nói về việc khác.