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

Tìm thấy 718 câu.

Câu 471 People
You are the project manager for the LMG Project. Your project will have several human resource issues that must be coordinated and approved by the union. Which of the following statements is correct about this scenario?
  1. A The union is considered a project stakeholder.
  2. B The union is considered a project team member.
  3. C The union is considered a resource constraint.
  4. D The union is considered a management constraint.
Xem giải thích

Đáp án

A — CÔNG ĐOÀN LÀ MỘT BÊN LIÊN QUAN CỦA DỰ ÁN.

Vì sao đúng

⚠ Định nghĩa bên liên quan theo PMI: | Yếu tố | Nội dung | |---|---| | ⚠ Cá nhân hoặc NHÓM có thể ẢNH HƯỞNG tới dự án | ⚠ công đoàn rõ ràng đang ảnh hưởng | | ⚠ Hoặc BỊ ẢNH HƯỞNG bởi dự án | ⚠ thành viên của họ là người bị tác động | | ⚠ Hoặc TỰ CHO RẰNG mình bị ảnh hưởng | ⚠ chỉ cần nhận thức là đủ, không cần chứng minh | | ⚠ Bên liên quan có thể ỦNG HỘ hoặc PHẢN ĐỐI | ⚠ phản đối KHÔNG loại họ khỏi danh sách | | ⚠ Kết luận | ⚠ công đoàn thoả cả ba vế của định nghĩa |

⚠ Sai lầm phổ biến: ⚠ nghĩ rằng "bên liên quan" là những người ủng hộ dự án ⚠ — ⚠ thực tế bên liên quan PHẢN ĐỐI thường là nhóm cần quản lý kỹ nhất; liên hệ #26892 cùng lô.

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

  • C (công đoàn là bên liên quan tiêu cực nên cần bị loại khỏi dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nửa đầu của nó ĐÚNG: công đoàn đúng là bên liên quan có thái độ tiêu cực, và PMI có dùng khái niệm đó: ⚠ nhưng ⚠ nửa sau thì sai hoàn toàn — không có bên liên quan nào bị "loại khỏi dự án" vì thái độ của họ ⚠; ⚠ bên liên quan tiêu cực được QUẢN LÝ chặt hơn chứ không bị gạt ra: tăng tần suất trao đổi, tìm hiểu mối lo thật sự, tìm điểm chung; ⚠ và trong trường hợp công đoàn, việc "loại họ ra" thậm chí không khả thi về mặt pháp lý.

  • B (công đoàn chỉ là bên liên quan nếu có thành viên tham gia đội dự án) — ⚠ hiểu sai định nghĩa; ⚠ tác động chứ không phải tư cách thành viên mới là tiêu chí.

  • D (không, vì công đoàn ở ngoài tổ chức thực hiện dự án) — ⚠ bên liên quan có cả bên trong lẫn bên NGOÀI; ⚠ khách hàng, nhà cung cấp, cơ quan quản lý, cộng đồng đều ở ngoài.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26892 cùng lô (mọi bên liên quan kể cả khách hàng), ⚠ #26900 cùng lô (ràng buộc từ bên ngoài), ⚠ #26757 lô 200 (phân tích quyền lực – quan tâm), ⚠ #26884 cùng lô (thu hút bên liên quan).

⚠ Bốn nhóm THÁI ĐỘ của bên liên quan: | Thái độ | Cách xử lý | |---|---| | ⚠ Không biết (unaware) | ⚠ thông tin cho họ biết | | ⚠ Kháng cự (resistant) | ⚠ công đoàn ở đây — tìm hiểu lý do, tìm điểm chung | | ⚠ Trung lập (neutral) | ⚠ giữ thông tin đều đặn | | ⚠ Ủng hộ / Dẫn dắt (supportive / leading) | ⚠ tận dụng để tác động lên nhóm kháng cự | | ⚠ Điều đáng nhớ | ⚠ công cụ của PMI là ma trận "mức độ hiện tại → mức độ mong muốn", tức là mặc định rằng thái độ CÓ THỂ THAY ĐỔI — và một bên bị loại ra thì không bao giờ thay đổi được |

⚠ Vì sao công đoàn là nhóm đặc biệt cần chú ý: | Đặc điểm | Hệ quả | |---|---| | ⚠ Có quyền lực thật, không chỉ ảnh hưởng mềm | ⚠ có thể dừng công việc | | ⚠ Đại diện cho một số đông người lao động | ⚠ tiếng nói tập thể | | ⚠ Thường có cơ sở pháp lý và hợp đồng lao động | | | ⚠ Mối lo của họ thường CHÍNH ĐÁNG | ⚠ lo mất việc, đổi điều kiện làm việc, an toàn | | ⚠ Cách tiếp cận đúng | ⚠ mời họ vào bàn SỚM, trước khi kế hoạch chốt — vì phản đối muộn tốn kém hơn nhiều so với việc điều chỉnh sớm; liên hệ #26928 về nguyên tắc phát hiện rủi ro sớm |

⚠ Bên liên quan BÊN NGOÀI thường bị bỏ sót: | Nhóm | Ví dụ | |---|---| | ⚠ Công đoàn | ⚠ câu này | | ⚠ Cơ quan quản lý, chính quyền địa phương | | | ⚠ Cộng đồng dân cư quanh dự án | | | ⚠ Nhà cung cấp và nhà thầu phụ | | | ⚠ Nhóm bảo vệ môi trường, báo chí | | | ⚠ Nhận xét | ⚠ danh sách bên liên quan chỉ ghi người trong tổ chức là dấu hiệu rõ nhất của một bản phân tích làm cho có — và những nhóm bị bỏ sót đó chính là nơi rủi ro lớn nhất xuất hiện |

Từ khoá nhận diện:

"công đoàn phản đối" → ⚠ VẪN LÀ bên liên quan, thuộc nhóm KHÁNG CỰ "bên liên quan tiêu cực nên loại ra" → ⚠ sai — quản lý chặt hơn chứ không loại "phải có người trong đội mới tính" → ⚠ sai tiêu chí, tác động mới là tiêu chí "ở ngoài tổ chức nên không tính" → ⚠ bên liên quan có cả trong lẫn ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách bên liên quan của bạn có ai ở ngoài tổ chức không | | | Có nhóm nào đang phản đối mà bạn chưa ghi vào danh sách không | | | Bạn đã hỏi nhóm kháng cự xem họ lo điều gì chưa | |

Và điều mà việc thừa nhận một nhóm phản đối là bên liên quan mở ra: khả năng nói chuyện với họ — vì chỉ khi tên họ nằm trong danh sách thì mới có kế hoạch trao đổi, và chỉ khi có trao đổi thì thái độ mới đổi được.

Câu 472 Process
Linda and her team have produced a new working software that is exactly what the customer requested. They demonstrated the software, and the customer realized that what they asked for was not really what they wanted. What is the best agile approach to resolving this issue?
  1. A The team should employ a flexible contract model and adjust the shared definition of done with the customer to accommodate their changing preferences.
  2. B The project manager should have a firm discussion with the customer, who should know that they cannot change things once an iteration has begun.
  3. C The project manager should immediately submit a change control request to the change review board to ensure the customer’s change is considered as quickly as possible.
  4. D The team should execute the appropriate change control process to ensure that the client cannot introduce changes that were not in the original contract without the proper series of approvals.
Xem giải thích

⚠ Ghi nhớ về chất lượng câu hỏi — CÂU TRÙNG HOÀN TOÀN: ⚠ câu này TRÙNG NGUYÊN VĂN với #26818 lô 201 ⚠ — ⚠ cùng tình huống Linda, cùng bốn phương án, cùng khoá đáp án về nội dung; ⚠ khác biệt DUY NHẤT là THỨ TỰ CHỮ CÁI bị xáo: ở #26818 đáp án là phương án D, ở đây nó là phương án A; và hai phương án A và D của bản cũ đã hoán đổi vị trí cho nhau; ⚠ giải thích dưới đây được dùng lại và đã chỉnh lại toàn bộ chữ cái cho khớp với thứ tự mới; ⚠ bài học cho phòng thi: bộ đề xáo chữ cái giữa các lần ra đề, nên đừng bao giờ học thuộc chữ cái — hãy nhớ NỘI DUNG của phương án đúng.

Đáp án

A — ĐỘI NÊN DÙNG MÔ HÌNH HỢP ĐỒNG LINH HOẠT VÀ ĐIỀU CHỈNH ĐỊNH NGHĨA HOÀN THÀNH CHUNG VỚI KHÁCH HÀNG ĐỂ ĐÁP ỨNG SỞ THÍCH ĐANG THAY ĐỔI CỦA HỌ.

Vì sao đúng

⚠ Vì sao đây là cách tiếp cận agile đúng: | Nguyên tắc agile | Nội dung | |---|---| | ⚠ "Hợp tác với khách hàng hơn là đàm phán hợp đồng" | ⚠ một trong bốn giá trị của Tuyên ngôn Agile | | ⚠ "Chào đón thay đổi, kể cả muộn trong quá trình phát triển" | ⚠ một trong mười hai nguyên tắc | | ⚠ Việc khách nhận ra điều mình thật sự muốn là THÀNH CÔNG của vòng phản hồi | ⚠ không phải thất bại của đội | | ⚠ Định nghĩa hoàn thành CHUNG với khách hàng thì điều chỉnh được | ⚠ liên hệ #26748 lô 200 | | ⚠ Hợp đồng linh hoạt cho phép đổi phạm vi trong khuôn khổ đã thoả thuận | | | ⚠ Kết luận | ⚠ agile được thiết kế chính xác cho tình huống này |

⚠ Đội đã làm ĐÚNG: ⚠ họ trình diễn phần mềm và khách hàng phát hiện ra sự khác biệt giữa điều đã yêu cầu và điều thật sự cần ⚠ — ⚠ phát hiện điều đó sau một vòng lặp rẻ hơn rất nhiều so với phát hiện sau mười tám tháng.

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

  • C (nộp ngay yêu cầu thay đổi cho ban kiểm soát để thay đổi của khách được xét nhanh nhất) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có thiện chí, hướng tới việc phục vụ khách hàng nhanh chóng, và cũng tuân thủ quy trình: ⚠ nhưng ⚠ nó áp cơ chế của vòng đời DỰ ĐOÁN vào một dự án agile ⚠ — ⚠ trong agile, thay đổi về nội dung sản phẩm được xử lý qua TỒN ĐỌNG và việc xếp lại ưu tiên, không qua ban kiểm soát thay đổi; ⚠ ban kiểm soát thay đổi dành cho các thay đổi chạm tới đường cơ sở của dự án, không phải cho mỗi lần điều chỉnh một tính năng; ⚠ liên hệ #26803 cùng lô.

  • D (thực hiện quy trình kiểm soát thay đổi để khách không thể đưa thay đổi ngoài hợp đồng gốc) — ⚠ dùng quy trình như một RÀO CẢN chống lại khách hàng; ⚠ trái hoàn toàn với giá trị hợp tác của agile.

  • B (nói thẳng với khách rằng không được đổi khi vòng lặp đã bắt đầu) — ⚠ nửa đúng nửa sai: ⚠ đúng là không chen thay đổi vào vòng lặp ĐANG chạy, nhưng thay đổi hoàn toàn được đưa vào tồn đọng cho vòng lặp SAU — cách nói này đóng cửa thay vì mở đường.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26818 lô 201 (CÂU TRÙNG — cùng khoá, khác chữ cái), ⚠ #26748 lô 200 (định nghĩa hoàn thành), ⚠ #26825 cùng lô (tồn đọng phải được xếp lại khi có yêu cầu mới), ⚠ #26806 cùng lô (không xác định hết yêu cầu từ đầu), ⚠ #26784 cùng lô (giải thích agile cho bên liên quan), ⚠ #26788 cùng lô (chọn vòng đời phù hợp).

⚠ Vì sao "đúng yêu cầu" mà vẫn "không đúng ý" là chuyện bình thường: | Nguyên nhân | Nội dung | |---|---| | ⚠ Người ta khó hình dung thứ chưa tồn tại | ⚠ chỉ khi nhìn thấy mới biết mình muốn gì | | ⚠ Yêu cầu viết ra luôn mất mát so với ý định | ⚠ ngôn ngữ không mô tả đủ trải nghiệm | | ⚠ Bối cảnh kinh doanh thay đổi trong lúc làm | | | ⚠ Người viết yêu cầu có thể không phải người dùng thật | | | ⚠ Vì sao agile ra đời | ⚠ đây chính là vấn đề mà vòng lặp ngắn và trình diễn thường xuyên được thiết kế để giải quyết — coi nó là lỗi của khách hàng là hiểu ngược toàn bộ tinh thần của phương pháp |

⚠ HỢP ĐỒNG LINH HOẠT cho dự án agile: | Mô hình | Nội dung | |---|---| | ⚠ Thời gian và vật tư có TRẦN | ⚠ khách trả theo thực tế nhưng có giới hạn tối đa | | ⚠ Giá cố định theo GIA SỐ | ⚠ mỗi vòng lặp là một đơn vị mua | | ⚠ Điều khoản "đổi ngang phạm vi" | ⚠ thêm một tính năng thì bỏ một tính năng tương đương | | ⚠ Chia sẻ tiết kiệm | ⚠ xong sớm thì hai bên cùng hưởng | | ⚠ Chia sẻ rủi ro và lợi ích | ⚠ liên hệ #26693 lô 199 — tinh thần của IPD | | ⚠ Điểm chung | ⚠ mọi mô hình này đều chấp nhận rằng phạm vi chi tiết sẽ thay đổi, và chuyển sự chắc chắn từ PHẠM VI sang NGÂN SÁCH hoặc THỜI GIAN — đó là sự đánh đổi trung thực nhất mà một hợp đồng agile có thể đưa ra |

⚠ Đội của Linda nên làm gì cụ thể: | Bước | Việc | |---|---| | ⚠ Ghi nhận phản hồi của khách như một đầu vào giá trị | ⚠ không phòng thủ, không đổ lỗi | | ⚠ Làm rõ điều khách THẬT SỰ cần | ⚠ hỏi về mục tiêu, không hỏi về giải pháp | | ⚠ Đưa vào tồn đọng và xếp lại ưu tiên với chủ sản phẩm | ⚠ liên hệ #26825 cùng lô | | ⚠ Cập nhật định nghĩa hoàn thành nếu tiêu chí đã đổi | ⚠ ĐÁP ÁN | | ⚠ Nói rõ sự đánh đổi: thêm cái này thì cái gì lùi lại | | | ⚠ Rà lại mô hình hợp đồng nếu nó đang cản trở | ⚠ phần thứ hai của đáp án | | ⚠ Điều quan trọng nhất | ⚠ phần mềm đã làm ra KHÔNG lãng phí — nó là thứ đã giúp khách hàng hiểu ra điều họ cần, và đó là giá trị thật dù nó không đi vào sản phẩm cuối |

Từ khoá nhận diện:

"khách nhận ra thứ mình xin không phải thứ mình muốn" → ⚠ HỢP ĐỒNG LINH HOẠT + điều chỉnh định nghĩa hoàn thành "dùng kiểm soát thay đổi để chặn khách" → ⚠ trái tinh thần hợp tác "nộp yêu cầu thay đổi lên ban kiểm soát" → ⚠ cơ chế của vòng đời dự đoán "không được đổi khi vòng lặp đã bắt đầu" → ⚠ đúng cho vòng lặp hiện tại, sai khi đóng cửa hoàn toàn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có cho phép thay đổi phạm vi không | | | Khách hàng của bạn thấy sản phẩm bao lâu một lần | ⚠ càng thưa thì bất ngờ càng lớn | | Đội bạn phản ứng thế nào khi khách đổi ý | ⚠ phòng thủ hay tò mò |

Và điều mà buổi trình diễn ấy thật sự mang lại, dù kết quả nghe như một thất bại: khách hàng vừa học được điều mà họ không thể học bằng cách nào khác — và cả hai bên vừa tránh được việc xây tiếp mười một tháng nữa cho một thứ không ai muốn.

Câu 473 People
Greg is a veteran project manager who recently joined a company with a reputation for its management being rigid and firm. The management directs, and the employees respond. There is little room for discussion or suggestions in the culture. This has created an environment where people do not take the initiative and only work when they are told exactly what to do. The new CEO recently took over, and he endeavors to reverse this trend in the culture. The new CEO wants more openness and for his employees to feel valued. Greg is on board with the culture change, but it is deeply ingrained in the employees who have been in the organization prior to his start. When he tries to engage his project team, they are withdrawn and want to be told what to do. Greg is determined to reverse this "just do what you are told" dynamic. What management style are Greg and the new CEO attempting to change?
  1. A Autosynchronous
  2. B Laissez-Faire
  3. C Servant leadership
  4. D Directing
Xem giải thích

Đáp án

D — CHỈ ĐẠO (Directing).

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bài bị CẮT CỤT ở giữa câu ⚠ — ⚠ dừng ở "When he tries to engage his…"; ⚠ phải suy ra ý còn lại từ đoạn mô tả văn hoá phía trước, và may là đoạn đó đã đủ rõ để chọn được đáp án.

Vì sao đúng

⚠ Vì sao Greg buộc phải dùng phong cách CHỈ ĐẠO lúc này: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ "Ban lãnh đạo ra lệnh, nhân viên đáp ứng" | ⚠ văn hoá một chiều đã ăn sâu | | ⚠ "Không có chỗ cho thảo luận hay đề xuất" | ⚠ nhân viên chưa từng được mời góp ý | | ⚠ "Chỉ làm khi được bảo chính xác phải làm gì" | ⚠ mức TRƯỞNG THÀNH thấp về mặt chủ động | | ⚠ Nhân viên đã ở đây từ trước khi Greg đến | ⚠ thói quen hình thành qua nhiều năm | | ⚠ Kết luận | ⚠ lãnh đạo theo tình huống: người CHƯA SẴN SÀNG tự chủ thì phải bắt đầu bằng CHỈ ĐẠO |

⚠ Điểm tinh tế: ⚠ Greg ỦNG HỘ việc đổi văn hoá, nhưng không thể nhảy thẳng tới trao quyền ⚠ — ⚠ thang cần leo từng bậc: Chỉ đạo → Huấn luyện → Hỗ trợ → Uỷ quyền; liên hệ #26867 lô 202.

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

  • B (Laissez-Faire — buông cho tự lo) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như đối cực của văn hoá cứng nhắc, nên có vẻ đúng là thứ CEO muốn hướng tới: ⚠ nhưng ⚠ buông tay cho một đội chưa bao giờ được phép tự quyết sẽ tạo ra tê liệt chứ không tạo ra chủ động ⚠ — ⚠ họ sẽ đứng chờ, công việc đình trệ, và bài học họ rút ra sẽ là "thay đổi này không hiệu quả"; ⚠ trao quyền là ĐÍCH ĐẾN chứ không phải phương tiện, và nó chỉ hoạt động khi người ta đã có kỹ năng lẫn sự tự tin.

  • C (Lãnh đạo phụng sự) — ⚠ cũng là đích đến chứ không phải điểm bắt đầu; ⚠ dọn vật cản cho người chưa biết tự đặt mục tiêu thì họ vẫn không đi đâu cả.

  • A (Autosynchronous) — ⚠ THUẬT NGỮ BỊA; ⚠ không có phong cách lãnh đạo nào tên như vậy trong tài liệu PMI.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26867 lô 202 (lãnh đạo theo tình huống), ⚠ #26877 lô 202 (Thuyết X và Thuyết Y), ⚠ #26923 cùng lô (thuyết kỳ vọng Vroom), ⚠ #26853 lô 202 (các giai đoạn hình thành đội).

⚠ BỐN PHONG CÁCH theo lãnh đạo tình huống (Hersey–Blanchard): | Phong cách | Dùng khi | |---|---| | ⚠ CHỈ ĐẠO (S1) | ⚠ năng lực thấp, cam kết thấp — trường hợp của Greg | | ⚠ HUẤN LUYỆN (S2) | ⚠ có chút năng lực nhưng cam kết dao động | | ⚠ HỖ TRỢ (S3) | ⚠ năng lực khá, thiếu tự tin | | ⚠ UỶ QUYỀN (S4) | ⚠ năng lực cao, cam kết cao | | ⚠ Nguyên tắc | ⚠ phong cách đi theo NGƯỜI và TÌNH HUỐNG, không phải theo sở thích của người lãnh đạo — và một người quản lý giỏi thường phải dùng cả bốn trong cùng một tuần với những người khác nhau |

⚠ Đổi văn hoá thì bắt đầu từ đâu: | Việc | Nội dung | |---|---| | ⚠ Giao việc rõ ràng như cũ, nhưng HỎI THÊM một câu | ⚠ "anh thấy cách nào tốt hơn không" | | ⚠ Khi có người góp ý, PHẢI dùng góp ý đó | ⚠ lần đầu bị phớt lờ là lần cuối họ góp ý | | ⚠ Khen công khai người dám nêu ý kiến | ⚠ tín hiệu cho cả nhóm | | ⚠ Bỏ dần chi tiết trong chỉ đạo theo từng tuần | ⚠ chuyển S1 sang S2 | | ⚠ Vì sao chậm mà chắc | ⚠ nhân viên đang thử xem lời hứa về "cởi mở" có thật không; một lần ý kiến bị gạt đi sẽ đưa mọi thứ về mốc xuất phát, và lần sau sẽ khó hơn lần này |

⚠ Phân biệt CHỈ ĐẠO với văn hoá cứng nhắc mà đề mô tả: | Chỉ đạo (đúng) | Cứng nhắc (sai) | |---|---| | ⚠ Nói rõ việc cần làm VÀ vì sao | ⚠ chỉ nói việc cần làm | | ⚠ Là bước tạm thời, có lộ trình đi lên | ⚠ là trạng thái vĩnh viễn | | ⚠ Vẫn mời góp ý dù chưa trông đợi nhiều | ⚠ không có chỗ cho thảo luận | | ⚠ Khác biệt cốt lõi | ⚠ cùng một hành vi bề ngoài nhưng khác nhau ở Ý ĐỊNH: một bên xây dựng năng lực để rồi buông ra, một bên duy trì sự phụ thuộc |

Từ khoá nhận diện:

"chỉ làm khi được bảo chính xác phải làm gì" → ⚠ CHỈ ĐẠO (S1) "Laissez-Faire" → ⚠ buông tay quá sớm sẽ gây tê liệt "lãnh đạo phụng sự" → ⚠ đích đến, không phải điểm bắt đầu "Autosynchronous" → ⚠ thuật ngữ BỊA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang dùng phong cách nào với từng người trong đội | | | Có ai đã sẵn sàng cho mức tự chủ cao hơn mà bạn vẫn giữ ở S1 không | | | Lần gần nhất có người góp ý, bạn đã làm gì với góp ý đó | |

Và điều mà một văn hoá cứng nhắc dạy cho nhân viên: rằng chủ động là việc rủi ro — nên muốn đảo ngược, việc đầu tiên phải chứng minh là điều ngược lại, và chứng minh bằng hành động chứ không bằng thông báo.

Câu 474 Process
As the project manager for the Wilbur MGR company, you are working on a new project where you will need to purchase laptops, software, networking equipment, and three new servers. Procurement is centralized for all projects within your project management office. The project management office leader, Ted, tells you that a typical competitive procurement process may not be necessary under certain circumstances. Under which circumstances would this be the case?
  1. A Your project requires special software from a specific vendor.
  2. B Your project will purchase the same equipment as previous projects.
  3. C Your project needs standard equipment and software that most vendors can provide.
  4. D Your project has a predefined scope and schedule, and the purchasing is not unique.
Xem giải thích

Đáp án

B — DỰ ÁN CỦA BẠN SẼ MUA CÙNG LOẠI THIẾT BỊ VỚI CÁC DỰ ÁN TRƯỚC.

Vì sao đúng

⚠ Vì sao mua lặp lại thì không cần đấu thầu lại: | Lý do | Nội dung | |---|---| | ⚠ Mua sắm được TẬP TRUNG ở PMO | ⚠ đề nêu rõ điều này ngay từ đầu | | ⚠ PMO đã từng chạy quy trình cạnh tranh cho đúng thiết bị đó | ⚠ việc so sánh giá đã làm rồi | | ⚠ Thường đã có HỢP ĐỒNG KHUNG hoặc thoả thuận dài hạn | ⚠ chỉ cần phát lệnh mua theo hợp đồng có sẵn | | ⚠ Đấu thầu lại cho cùng thứ đã mua là lãng phí | ⚠ tốn thời gian mà kết quả gần như chắc chắn giống cũ | | ⚠ Kết luận | ⚠ mua lặp lại theo hợp đồng đã có là ngoại lệ hợp lệ và phổ biến nhất của quy trình cạnh tranh |

⚠ Vai trò của PMO ở đây: ⚠ chính vì mua sắm tập trung nên PMO NHỚ được các lần mua trước và tái sử dụng được kết quả đấu thầu cũ ⚠ — ⚠ một dự án đơn lẻ tự mua thì không có lợi thế đó.

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

  • A (dự án cần phần mềm đặc biệt từ một nhà cung cấp cụ thể) — ⚠ phương án gây nhiễu mạnh nhất, và thành thật mà nói nó CŨNG ĐÚNG theo sách vì ⚠ "nhà cung cấp duy nhất" (sole source) là lý do kinh điển để miễn đấu thầu: ⚠ nhưng ⚠ đề đã cài sẵn manh mối "mua sắm TẬP TRUNG ở PMO" và người hỏi là lãnh đạo PMO, nên trọng tâm câu hỏi là lợi thế của việc mua tập trung chứ không phải quy tắc sole source ⚠; ⚠ xem thêm mục "Ghi nhớ về chất lượng câu hỏi" bên dưới — đây là câu có hai đáp án bảo vệ được.

  • C (thiết bị tiêu chuẩn mà hầu hết nhà cung cấp đều có) — ⚠ ngược lại; ⚠ nhiều nhà cung cấp cùng cấp được chính là điều kiện LÝ TƯỞNG để đấu thầu cạnh tranh.

  • D (phạm vi và tiến độ đã định trước, việc mua không có gì đặc biệt) — ⚠ không liên quan tới việc có cần cạnh tranh hay không; ⚠ phạm vi rõ ràng chỉ giúp viết hồ sơ mời thầu dễ hơn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này có HAI phương án bảo vệ được ⚠ — ⚠ B (khoá chính thức, dựa vào hợp đồng khung đã đấu thầu trước đó) và A (sole source, lý do miễn đấu thầu được nêu thẳng trong tài liệu mua sắm); ⚠ khi gặp dạng này trong phòng thi, hãy bám vào chi tiết mà đề CỐ TÌNH cài: ở đây là "mua sắm tập trung cho toàn bộ dự án trong PMO", một câu không cần thiết cho phương án A nhưng lại là chìa khoá cho phương án B; ⚠ quy tắc chung: chi tiết thừa trong đề PMP hiếm khi thừa thật.

⚠ Đối chiếu: ⚠ #26850 lô 202 (nguồn duy nhất và nguồn độc quyền), ⚠ #26886 cùng lô (RFQ dùng khi hỏi giá), ⚠ #26930 cùng lô (hợp đồng có thưởng), ⚠ #26794 lô 201 (kiểm soát mua sắm).

⚠ Các trường hợp KHÔNG cần đấu thầu cạnh tranh: | Trường hợp | Ghi chú | |---|---| | ⚠ Đã có hợp đồng khung cho đúng mặt hàng đó | ⚠ ĐÁP ÁN của câu này | | ⚠ Nguồn duy nhất (sole source) | ⚠ chỉ một nhà cung cấp trên thị trường | | ⚠ Nguồn độc quyền (single source) | ⚠ tổ chức CHỌN một nhà cung cấp dù có nhiều lựa chọn | | ⚠ Giá trị dưới ngưỡng bắt buộc đấu thầu | ⚠ mỗi tổ chức có ngưỡng riêng | | ⚠ Tình huống khẩn cấp | ⚠ thường phải có phê duyệt cấp cao | | ⚠ Điểm chung | ⚠ mọi ngoại lệ đều phải có LÝ DO ĐƯỢC GHI LẠI — bỏ đấu thầu mà không ghi lý do là điểm mà kiểm toán sẽ dừng lại rất lâu |

⚠ Ba loại tài liệu mời thầu, đừng lẫn: | Tài liệu | Dùng khi | |---|---| | ⚠ RFI (yêu cầu thông tin) | ⚠ chưa biết thị trường có gì | | ⚠ RFQ (yêu cầu báo giá) | ⚠ đã biết cần gì, chỉ so GIÁ — liên hệ #26886 cùng lô | | ⚠ RFP (yêu cầu đề xuất) | ⚠ cần nhà cung cấp đề xuất GIẢI PHÁP | | ⚠ Ghi nhớ | ⚠ mua laptop và máy chủ tiêu chuẩn thì dùng RFQ; nhưng nếu đã có hợp đồng khung thì thậm chí không cần cả RFQ |

Từ khoá nhận diện:

"mua cùng thứ với dự án trước" + "mua sắm tập trung" → ⚠ dùng hợp đồng đã có, KHÔNG cần đấu thầu lại "phần mềm đặc biệt từ một nhà cung cấp" → ⚠ sole source — cũng miễn đấu thầu, nhưng không phải trọng tâm câu này "nhiều nhà cung cấp đều cung cấp được" → ⚠ điều kiện LÝ TƯỞNG để đấu thầu "phạm vi và tiến độ đã định" → ⚠ không liên quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có danh sách hợp đồng khung đang hiệu lực không | | | Ngưỡng giá trị bắt buộc đấu thầu của bạn là bao nhiêu | | | Lần gần nhất bỏ qua đấu thầu, lý do có được ghi lại không | |

Và điều mà việc mua sắm tập trung mang lại nhiều hơn cả giá tốt: trí nhớ — vì một tổ chức nhớ được mình đã mua gì và mua thế nào thì lần sau không phải làm lại từ đầu.

Câu 475 Business Environment
Barbara is the scrum master for Project W, which is eight iterations into deployment and over budget by $10,000. The project team has provided several main deliverables of Project W, but several stakeholders are agitated over cost overruns and are concerned Project W will fail. What should Barbara do to address their concerns?
  1. A Remove some expensive tasks from the project.
  2. B Fast track as many tasks as possible.
  3. C Remind the stakeholders about the value already provided.
  4. D Ask the steering committee for more funding.
Xem giải thích

Đáp án

C — NHẮC BÊN LIÊN QUAN VỀ GIÁ TRỊ ĐÃ ĐƯỢC BÀN GIAO.

Vì sao đúng

⚠ Vì sao đây là phản ứng đúng của scrum master: | Dữ kiện trong đề | Ý nghĩa | |---|---| | ⚠ Đã qua TÁM vòng lặp và đang TRIỂN KHAI | ⚠ sản phẩm đã ra tới tay người dùng | | ⚠ "Đã bàn giao vài hạng mục CHÍNH" | ⚠ có giá trị thật, đo được | | ⚠ Vượt ngân sách 10.000 đô | ⚠ con số cần đặt cạnh giá trị nhận được | | ⚠ Bên liên quan lo dự án sẽ THẤT BẠI | ⚠ họ đang chỉ nhìn một nửa bức tranh | | ⚠ Kết luận | ⚠ chi phí chỉ có nghĩa khi so với GIÁ TRỊ; nhắc lại giá trị là đưa nửa còn lại vào cuộc trò chuyện |

⚠ Điểm cốt lõi của agile: ⚠ thành công đo bằng giá trị bàn giao chứ không chỉ bằng bám sát ngân sách ⚠ — ⚠ một dự án vượt 10.000 mà đã đưa được vài tính năng chính vào vận hành có thể vẫn đang lãi; liên hệ #26888 cùng lô.

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

  • D (xin ban chỉ đạo cấp thêm kinh phí) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ vượt ngân sách thì xin thêm tiền nghe như bước xử lý thực tế nhất, và đúng là ở một thời điểm nào đó có thể phải làm: ⚠ nhưng ⚠ câu hỏi là làm gì để XỬ LÝ MỐI LO của bên liên quan, không phải làm gì để có thêm tiền ⚠ — ⚠ xin thêm kinh phí trước khi họ hiểu được giá trị đã nhận sẽ càng xác nhận nỗi sợ của họ rằng dự án đang mất kiểm soát; ⚠ thứ tự đúng là: cho họ thấy bức tranh đầy đủ trước, rồi mới cùng quyết định có đáng đầu tư tiếp hay không.

  • A (bỏ bớt các công việc tốn kém) — ⚠ cắt việc theo giá chứ không theo giá trị; ⚠ trong agile, việc điều chỉnh phải do chủ sản phẩm xếp lại thứ tự tồn đọng theo giá trị.

  • B (đẩy nhanh bằng cách chạy song song tối đa) — ⚠ fast tracking xử lý vấn đề TIẾN ĐỘ chứ không xử lý chi phí; ⚠ chạy song song thường còn làm tăng rủi ro và chi phí làm lại.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26888 cùng lô (rủi ro là mặt trái của giá trị), ⚠ #26837 lô 202 (điểm chạm với bên liên quan), ⚠ #26840 lô 202 (ROI 10% chỉ chứng minh có lãi), ⚠ #26922 cùng lô (CPI cho biết mức hiệu quả chi phí).

⚠ Nói chuyện với bên liên quan đang lo lắng — bốn bước: | Bước | Nội dung | |---|---| | ⚠ 1. Thừa nhận mối lo là chính đáng | ⚠ đừng bắt đầu bằng cách bảo vệ dự án | | ⚠ 2. Trình bày GIÁ TRỊ đã bàn giao, cụ thể và đo được | ⚠ tính năng nào, ai đang dùng, tác dụng ra sao | | ⚠ 3. Đặt con số 10.000 cạnh giá trị đó | ⚠ để họ tự thấy tỷ lệ | | ⚠ 4. Cùng quyết định bước tiếp theo | ⚠ tiếp tục, điều chỉnh phạm vi, hay dừng | | ⚠ Điều đáng nhớ | ⚠ agile cho phép DỪNG ở bất kỳ vòng lặp nào mà vẫn giữ được toàn bộ giá trị đã bàn giao — đó là câu trả lời mạnh nhất cho nỗi sợ "dự án sẽ thất bại", vì nó cho thấy kịch bản mất trắng gần như không tồn tại.

⚠ Vì sao vượt ngân sách trong agile khác vượt ngân sách trong dự đoán: | Dự đoán (waterfall) | Agile | |---|---| | ⚠ Giá trị dồn về cuối | ⚠ giá trị đến từng vòng lặp | | ⚠ Vượt ngân sách trước khi bàn giao = rủi ro mất trắng | ⚠ vượt ngân sách sau tám vòng = đã có sản phẩm trong tay | | ⚠ Dừng giữa chừng thường không thu lại được gì | ⚠ dừng giữa chừng vẫn giữ nguyên phần đã dùng được | | ⚠ Hệ quả cho Barbara | ⚠ cùng một con số vượt ngân sách nhưng ý nghĩa rủi ro hoàn toàn khác nhau, và đó chính là điều bên liên quan chưa nhìn ra |

⚠ Trình bày giá trị thế nào cho thuyết phục: | Nên | Không nên | |---|---| | ⚠ Số người dùng thật của tính năng đã bàn giao | ⚠ liệt kê số câu chuyện đã hoàn thành | | ⚠ Thời gian hoặc chi phí tiết kiệm được | ⚠ nói chung chung "đội đã làm việc rất chăm chỉ" | | ⚠ Phản hồi trực tiếp từ người dùng | ⚠ biểu đồ vận tốc — đó là chỉ số nội bộ của đội | | ⚠ Nguyên tắc | ⚠ bên liên quan đo giá trị bằng đơn vị của HỌ, không bằng đơn vị của đội phát triển — dịch sang ngôn ngữ của họ là phần việc quan trọng nhất |

Từ khoá nhận diện:

"vượt ngân sách nhưng đã bàn giao được hạng mục chính" → ⚠ NHẮC LẠI GIÁ TRỊ đã có "xin thêm kinh phí" → ⚠ có thể cần, nhưng không phải cách xử lý MỐI LO "bỏ bớt việc tốn kém" → ⚠ cắt theo giá thay vì theo giá trị "chạy song song tối đa" → ⚠ giải pháp cho tiến độ, không phải cho chi phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có nói được giá trị dự án đã tạo ra bằng một câu không | | | Bên liên quan của bạn đang nhìn chi phí hay nhìn giá trị | | | Lần gần nhất báo cáo, bạn có đặt hai con số đó cạnh nhau không | |

Và điều mà một con số chi phí đứng một mình không bao giờ nói được: nó đắt hay rẻ — vì đắt rẻ là một phép so sánh, và nửa còn lại của phép so sánh đó luôn là giá trị nhận được.

Câu 476 People
Dylan completes one-on-one coaching activities with his team. When he learns that Beverly has a concern, he brings it up to the team in their subsequent daily standup. His agile mentor tells him that
  1. A This was appropriate, as Dylan knows a couple of other team members have a similar issue.
  2. B This was not appropriate, as one-on-one coaching should be kept confidential.
  3. C This was not appropriate, as the daily standup should not involve discussion of roadblocks.
  4. D This was appropriate, as the best thing to do is always bring issues up to the team.
Xem giải thích

Đáp án

B — KHÔNG PHÙ HỢP, VÌ NỘI DUNG KÈM CẶP MỘT–MỘT PHẢI ĐƯỢC GIỮ KÍN.

Vì sao đúng

⚠ Vì sao Dylan làm sai: | Nguyên tắc | Nội dung | |---|---| | ⚠ Kèm cặp một–một dựa hoàn toàn vào SỰ TIN CẬY | ⚠ người ta nói thật vì tin là chuyện ở lại trong phòng | | ⚠ Beverly KHÔNG đồng ý cho nêu công khai | ⚠ đề không hề nhắc tới việc xin phép | | ⚠ Nêu tên ra giữa buổi họp đứng là công khai hoá | ⚠ trước toàn đội, không báo trước | | ⚠ Hệ quả lan sang cả đội | ⚠ những người khác sẽ thôi nói thật trong buổi kèm cặp của mình | | ⚠ Kết luận | ⚠ một lần lộ chuyện riêng đủ để phá hỏng công cụ kèm cặp cho toàn bộ đội |

⚠ Cách làm đúng: ⚠ hỏi Beverly "chị có muốn tôi nêu chuyện này ra với đội không, hay chị muốn tự nói" ⚠ — ⚠ xin phép mất mười giây và giữ nguyên được lòng tin.

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

  • A (phù hợp, vì Dylan biết có vài người khác cũng gặp vấn đề tương tự) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó đúng ở chỗ vấn đề CHUNG thì nên bàn chung, và người kèm cặp đúng là hay nhìn thấy khuôn mẫu mà từng cá nhân không thấy: ⚠ nhưng ⚠ việc nhiều người cùng gặp một vấn đề không cho Dylan quyền nêu ĐÍCH DANH mối lo của Beverly ⚠ — ⚠ cách xử lý đúng là nêu vấn đề ở dạng ẨN DANH và khái quát: "tôi thấy có mấy chuyện lặp lại trong các buổi trao đổi riêng, ta bàn chung được không"; ⚠ cùng một nội dung được đưa ra bàn, nhưng không ai bị lộ.

  • D (phù hợp, vì tốt nhất luôn nên đưa mọi vấn đề ra trước đội) — ⚠ chữ "LUÔN LUÔN" là dấu hiệu của phương án sai; ⚠ minh bạch là giá trị tốt nhưng không đứng trên sự đồng ý của người trong cuộc.

  • C (không phù hợp, vì họp đứng không được bàn về vật cản) — ⚠ sai về bản chất buổi họp đứng; ⚠ nêu vật cản chính là một trong ba nội dung chuẩn của nó — liên hệ #26911 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26911 cùng lô (họp đứng là nơi nêu vật cản), ⚠ #26859 lô 202 (gặp riêng khi vấn đề thuộc về cá nhân), ⚠ #26905 cùng lô (họp cải tiến cuối chặng), ⚠ #26931 cùng lô (nhắc riêng về quy tắc ứng xử), ⚠ #26927 cùng lô (thấu cảm).

⚠ Chuyện gì được nêu công khai, chuyện gì không: | Nêu công khai được | Phải giữ kín (trừ khi được phép) | |---|---| | ⚠ Vật cản kỹ thuật ai cũng thấy | ⚠ mối lo cá nhân nói trong buổi kèm cặp | | ⚠ Số liệu tiến độ của đội | ⚠ đánh giá về đồng nghiệp | | ⚠ Quyết định ảnh hưởng tới cả đội | ⚠ hoàn cảnh riêng, sức khoẻ, gia đình | | ⚠ Bài học rút ra ở dạng khái quát | ⚠ mâu thuẫn giữa hai người cụ thể | | ⚠ Ranh giới thực dụng | ⚠ nếu bạn phải cân nhắc xem có nên nêu ra không, thì câu trả lời là hãy đi hỏi người đó — và câu hỏi đó gần như luôn được đón nhận tốt |

⚠ Ngoại lệ — khi nào KHÔNG giữ kín được: | Trường hợp | Nghĩa vụ | |---|---| | ⚠ Có nguy cơ tới an toàn của ai đó | ⚠ phải báo, và nên nói trước với người trong cuộc | | ⚠ Hành vi vi phạm pháp luật hoặc quy tắc đạo đức | ⚠ có kênh báo cáo riêng | | ⚠ Quấy rối hoặc phân biệt đối xử | ⚠ theo quy trình của tổ chức | | ⚠ Nguyên tắc | ⚠ nên nói rõ ranh giới này NGAY TỪ BUỔI KÈM CẶP ĐẦU TIÊN — "chuyện ở đây ở lại đây, trừ ba trường hợp sau" — như vậy không ai bị bất ngờ về sau|

⚠ Vì sao lòng tin khó xây mà dễ mất: | Đặc điểm | Nội dung | |---|---| | ⚠ Xây bằng nhiều lần nhỏ, mất bằng MỘT lần | | | ⚠ Người mất lòng tin thường không nói ra | ⚠ họ chỉ im lặng hơn | | ⚠ Hiệu ứng lan sang người thứ ba | ⚠ Beverly sẽ kể lại cho đồng nghiệp | | ⚠ Dylan nên làm gì bây giờ | ⚠ xin lỗi Beverly RIÊNG, thừa nhận đã sai, hỏi cô ấy muốn xử lý tiếp thế nào — và tuyệt đối không xin lỗi công khai giữa đội, vì như vậy là nêu tên cô ấy lần thứ hai |

Từ khoá nhận diện:

"đưa mối lo từ buổi 1-1 ra họp đứng" → ⚠ KHÔNG phù hợp, phải xin phép trước "vì nhiều người cùng gặp" → ⚠ nêu vấn đề ẩn danh, đừng nêu tên "luôn luôn nên đưa ra trước đội" → ⚠ chữ LUÔN LUÔN là dấu hiệu sai "họp đứng không bàn vật cản" → ⚠ sai, đó chính là nội dung chuẩn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có biết ranh giới bảo mật của buổi trao đổi riêng không | | | Lần gần nhất bạn nêu lại chuyện của người khác, có xin phép không | | | Có ai trong đội đã im lặng hơn trước không | |

Và điều mà một người quản lý đánh mất khi kể lại chuyện được nói riêng: không phải lòng tin của một người, mà là quyền được nghe sự thật từ tất cả những người còn lại.

Câu 477 Process
Samantha is a scrum master for a project which is just starting its first iteration. This project will create a phone app that will enable salespeople to provide and email cost estimates to clients from their phones rather than from the company's website. The product owner and the team have written many user stories, and the product owner has prioritized the product backlog. Samantha has gathered the development team to begin estimating story points for the first set of prioritized tasks. What must the team do before they may assign story points to stories?
  1. A Consult with the product owner.
  2. B Determine a baseline for what a story point is worth.
  3. C Review the team's ground rules.
  4. D Play planning poker.
Xem giải thích

Đáp án

B — XÁC ĐỊNH MỘT MỐC CHUẨN CHO GIÁ TRỊ CỦA MỘT ĐIỂM CÂU CHUYỆN.

Vì sao đúng

⚠ Vì sao phải có mốc chuẩn trước: | Lý do | Nội dung | |---|---| | ⚠ Điểm câu chuyện là đơn vị TƯƠNG ĐỐI, không tuyệt đối | ⚠ nó chỉ có nghĩa khi so với một cái gì đó | | ⚠ Đây là vòng lặp ĐẦU TIÊN của dự án | ⚠ đội chưa có tiền lệ nào để so | | ⚠ Không có mốc thì mỗi người hiểu "5 điểm" một kiểu | ⚠ ước lượng thành vô nghĩa | | ⚠ Cách làm chuẩn: chọn một câu chuyện nhỏ, rõ, ai cũng hiểu | ⚠ gán cho nó 1 hoặc 2 điểm làm chuẩn | | ⚠ Kết luận | ⚠ mọi câu chuyện sau đó được ước lượng bằng cách so với câu chuẩn đó |

⚠ Điểm quan trọng nhất: ⚠ mốc chuẩn là của RIÊNG đội này, không mượn được từ đội khác ⚠ — ⚠ năm điểm của đội A không bằng năm điểm của đội B, và đó là lý do vận tốc không dùng để so sánh giữa các đội; liên hệ #26709 lô 199.

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

  • D (chơi planning poker) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ planning poker đúng là kỹ thuật gán điểm câu chuyện, và nó đúng là việc Samantha sắp làm: ⚠ nhưng ⚠ câu hỏi là phải làm gì TRƯỚC KHI gán điểm, còn planning poker CHÍNH LÀ việc gán điểm ⚠ — ⚠ đây là dạng bẫy "chọn chính việc đang được hỏi"; ⚠ hơn nữa, chơi planning poker mà chưa có mốc chuẩn thì các lá bài giơ lên sẽ lệch nhau rất xa và cuộc thảo luận biến thành tranh cãi về đơn vị chứ không phải về công việc.

  • A (hỏi ý chủ sản phẩm) — ⚠ ước lượng là việc của ĐỘI PHÁT TRIỂN; ⚠ chủ sản phẩm xếp thứ tự ưu tiên và làm rõ yêu cầu, nhưng không tham gia định lượng công sức.

  • C (xem lại quy tắc ứng xử của đội) — ⚠ không liên quan tới đơn vị ước lượng; ⚠ quy tắc ứng xử là chuyện cách làm việc với nhau.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26709 lô 199 (vận tốc không so được giữa các đội), ⚠ #26891 cùng lô (tồn đọng chặng), ⚠ #26869 lô 202 (lập kế hoạch theo lớp sóng), ⚠ #26912 cùng lô (trình tự lập tiến độ dự đoán).

⚠ Điểm câu chuyện đo cái gì: | Thành phần | Nội dung | |---|---| | ⚠ Khối lượng công việc | ⚠ nhiều hay ít | | ⚠ Độ phức tạp | ⚠ khó hay dễ về mặt kỹ thuật | | ⚠ Mức bất định / rủi ro | ⚠ có nhiều thứ chưa biết không | | ⚠ KHÔNG đo thời gian trực tiếp | ⚠ đó là điểm hay bị hiểu sai nhất | | ⚠ Vì sao không đo bằng giờ | ⚠ con người ước lượng SO SÁNH giỏi hơn ước lượng tuyệt đối rất nhiều — hỏi "cái này to gấp mấy lần cái kia" luôn cho câu trả lời ổn định hơn hỏi "cái này mất bao nhiêu giờ" |

⚠ Cách thiết lập mốc chuẩn cho đội mới: | Bước | Nội dung | |---|---| | ⚠ 1. Chọn một câu chuyện NHỎ và RÕ RÀNG | ⚠ ai trong đội cũng hình dung được | | ⚠ 2. Gán cho nó 1 hoặc 2 điểm | ⚠ đừng chọn 1 nếu còn có thứ nhỏ hơn | | ⚠ 3. Chọn thêm một câu chuyện TRUNG BÌNH làm mốc thứ hai | ⚠ thường là 5 hoặc 8 | | ⚠ 4. Ước lượng phần còn lại bằng cách so với hai mốc đó | | | ⚠ 5. Sau 2–3 chặng thì hiệu chỉnh lại | ⚠ mốc ban đầu gần như chắc chắn lệch, và điều đó bình thường | | ⚠ Lưu ý | ⚠ đừng dành cả buổi để tìm mốc hoàn hảo — mốc chỉ cần đủ tốt để cả đội hiểu giống nhau, phần chính xác sẽ tự đến qua vài chặng |

⚠ Dãy Fibonacci và lý do dùng nó: | Vấn đề | Cách dãy Fibonacci xử lý | |---|---| | ⚠ Việc càng lớn ước lượng càng kém chính xác | ⚠ khoảng cách giữa các số càng lớn càng xa | | ⚠ Tránh tranh cãi vô ích giữa 6 và 7 | ⚠ không có hai số đó, chỉ có 5 và 8 | | ⚠ Số quá lớn (21, 34) là tín hiệu | ⚠ câu chuyện cần được chẻ nhỏ | | ⚠ Nhận xét | ⚠ giá trị lớn nhất của buổi ước lượng không phải con số cuối cùng mà là cuộc TRANH LUẬN khi hai người giơ lá bài khác nhau xa — chỗ đó thường lộ ra một yêu cầu chưa được hiểu giống nhau |

Từ khoá nhận diện:

"trước khi gán điểm câu chuyện" → ⚠ thiết lập MỐC CHUẨN "planning poker" → ⚠ chính là việc gán điểm, không phải bước trước đó "hỏi chủ sản phẩm" → ⚠ ước lượng là việc của đội phát triển "điểm câu chuyện" → ⚠ đơn vị TƯƠNG ĐỐI, riêng của từng đội

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có câu chuyện chuẩn để so không | | | Mọi người trong đội có hiểu "3 điểm" giống nhau không | | | Bạn có đang so vận tốc giữa hai đội không | |

Và điều mà mốc chuẩn mang lại cho một đội mới: một ngôn ngữ chung — vì trước khi có nó, mỗi con số nói ra đều mang một nghĩa khác nhau trong đầu mỗi người.

Câu 478 People
Katie recently lost an employee to a rival firm. The employee had several tasks expected to complete each month, all of which were highly autonomous and seldom collaborative. To resume operations, Katie needs to add knowledge about the tasks to her project's knowledge repository or, at the very least, take some notes about the tasks to prepare the employee's replacement. Katie decides that she will call the employee to ask about the tasks. Which level of knowledge is required?
  1. A Project-level
  2. B Surface-level
  3. C Individual-level
  4. D Portfolio-level
Xem giải thích

Đáp án

C — TRI THỨC MỨC CÁ NHÂN (individual-level).

Vì sao đúng

⚠ Vì sao là tri thức mức cá nhân: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Công việc "hết sức tự chủ, hiếm khi phối hợp" | ⚠ không ai khác từng làm cùng | | ⚠ Chỉ MỘT người nắm cách làm | ⚠ tri thức nằm trong đầu một cá nhân | | ⚠ Không có trong kho tri thức của dự án | ⚠ chưa từng được viết ra | | ⚠ Katie phải GỌI ĐIỆN cho chính người đó | ⚠ không có nguồn nào khác để hỏi | | ⚠ Kết luận | ⚠ đây là định nghĩa của tri thức mức cá nhân — và của tri thức ẩn |

⚠ Bài học phòng ngừa: ⚠ công việc tự chủ hoàn toàn, không phối hợp với ai, chính là công thức tạo ra "điểm chết một người" ⚠ — ⚠ liên hệ #26605 lô 197 và #26864 lô 202 về chia sẻ tri thức.

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

  • B (surface-level — mức bề mặt) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nghe rất hợp lý: Katie chỉ cần "ghi vài ghi chú", tức là tri thức nông chứ không sâu: ⚠ nhưng ⚠ "surface-level" KHÔNG PHẢI là một mức tri thức trong tài liệu PMI — đây là THUẬT NGỮ BỊA ⚠; ⚠ và ngay cả về mặt nội dung nó cũng sai: thứ Katie cần chính là phần sâu nhất, cái mà người đó biết mà chưa bao giờ viết ra; ⚠ hãy để ý dạng bẫy này: một từ tiếng Anh nghe rất tự nhiên, ghép với "-level" cho giống các mức thật.

  • A (mức dự án) — ⚠ tri thức mức dự án là thứ cả đội cùng tạo ra và cùng dùng; ⚠ ở đây không ai khác biết gì cả.

  • D (mức danh mục đầu tư) — ⚠ mức cao nhất, nói về bài học chung của nhiều chương trình; ⚠ hoàn toàn sai quy mô cho một danh sách công việc hằng tháng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26605 lô 197 (tri thức ẩn và tri thức hiện), ⚠ #26864 lô 202 (chia sẻ tri thức trong đội), ⚠ #26883 cùng lô (chuyển giao tri thức), ⚠ #26838 lô 202 (sổ bài học kinh nghiệm).

⚠ BA MỨC TRI THỨC trong tổ chức: | Mức | Nội dung | |---|---| | ⚠ CÁ NHÂN | ⚠ nằm trong đầu một người — ĐÁP ÁN của câu này | | ⚠ DỰ ÁN / NHÓM | ⚠ đội cùng biết, có trong tài liệu dự án | | ⚠ TỔ CHỨC / DANH MỤC | ⚠ quy trình, chuẩn, bài học tích luỹ qua nhiều dự án | | ⚠ Hướng đi mong muốn | ⚠ đưa tri thức từ mức CÁ NHÂN lên mức DỰ ÁN rồi TỔ CHỨC — vì tri thức chỉ nằm ở mức cá nhân thì nó rời khỏi công ty cùng với người đó, đúng như chuyện đang xảy ra với Katie |

⚠ Tri thức ẨN và tri thức HIỆN: | Loại | Đặc điểm | |---|---| | ⚠ HIỆN (explicit) | ⚠ viết ra được: tài liệu, quy trình, mã nguồn | | ⚠ ẨN (tacit) | ⚠ kinh nghiệm, trực giác, "mẹo" — khó viết | | ⚠ Thứ Katie cần | ⚠ chủ yếu là tri thức ẨN, nên gọi điện nói chuyện là cách đúng | | ⚠ Vì sao gọi điện chứ không gửi email | ⚠ tri thức ẩn được lôi ra bằng CÂU HỎI TIẾP NỐI — người ta không tự nghĩ ra để kể, phải có người hỏi "thế lúc gặp trường hợp X thì sao" |

⚠ Phòng ngừa mất tri thức khi có người nghỉ: | Biện pháp | Nội dung | |---|---| | ⚠ Lập trình đôi hoặc làm việc cặp | ⚠ hai người luôn biết cùng một thứ | | ⚠ Luân phiên công việc | ⚠ không ai độc quyền một mảng | | ⚠ Yêu cầu ghi tài liệu như một phần của định nghĩa hoàn thành | | | ⚠ Phỏng vấn bàn giao TRƯỚC ngày nghỉ cuối | ⚠ đừng đợi tới lúc phải gọi điện xin | | ⚠ Nhận xét về tình huống của Katie | ⚠ cô ấy đang làm đúng việc cần làm bây giờ, nhưng người đã sang công ty đối thủ không có nghĩa vụ nào phải trả lời — nên đây là bài học về phòng ngừa nhiều hơn là về xử lý |

Từ khoá nhận diện:

"chỉ một người biết, không ai làm cùng" → ⚠ tri thức mức CÁ NHÂN "surface-level" → ⚠ THUẬT NGỮ BỊA, không có trong tài liệu PMI "mức dự án" → ⚠ cả đội cùng biết "mức danh mục" → ⚠ bài học xuyên nhiều chương trình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong đội bạn có việc nào chỉ đúng một người làm được không | | | Người đó nghỉ một tháng thì việc gì sẽ dừng | | | Bạn có phỏng vấn bàn giao khi có người nghỉ không | |

Và điều mà một công việc "hết sức tự chủ" che giấu cho tới ngày người ta nghỉ: rằng nó chưa bao giờ thuộc về tổ chức, nó chỉ thuộc về một người.

Câu 479 People
Of the following, which is the agile method's preferred communication method?
  1. A E-mail
  2. B Face-to-face interaction
  3. C Instant messaging
  4. D Conference calls
Xem giải thích

Đáp án

B — TRAO ĐỔI TRỰC TIẾP MẶT ĐỐI MẶT (face-to-face interaction).

Vì sao đúng

⚠ Nguyên tắc số 6 của Tuyên ngôn Agile: | Nội dung | Ý nghĩa | |---|---| | ⚠ "Cách truyền đạt thông tin HIỆU QUẢ NHẤT là nói chuyện trực tiếp" | ⚠ nguyên văn nguyên tắc | | ⚠ Băng thông cao nhất trong mọi kênh | ⚠ lời nói + giọng điệu + ngôn ngữ cơ thể | | ⚠ Phản hồi tức thì | ⚠ hiểu nhầm được sửa ngay tại chỗ | | ⚠ Cho phép hỏi lại ngay | ⚠ không phải chờ vòng email | | ⚠ Kết luận | ⚠ mọi kênh khác đều là bản thay thế khi không gặp được trực tiếp |

⚠ Với đội phân tán: ⚠ gọi video là bản thay thế gần nhất, vì nó giữ lại được phần lớn tín hiệu phi lời nói ⚠ — ⚠ liên hệ #26900 cùng lô về đội ảo.

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

  • D (gọi hội nghị) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là kênh ĐỒNG BỘ và có tương tác hai chiều, tức là gần với mặt đối mặt nhất trong ba phương án còn lại: ⚠ nhưng ⚠ gọi thoại thuần mất toàn bộ tín hiệu hình ảnh — nét mặt, cử chỉ, ánh mắt — vốn chiếm phần lớn thông tin trong giao tiếp ⚠; ⚠ agile không nói "kênh đồng bộ", nó nói cụ thể là TRỰC TIẾP; ⚠ liên hệ #26889 cùng lô về tỷ trọng của giao tiếp phi lời nói.

  • A (email) — ⚠ kênh một chiều, không đồng bộ, không có phản hồi tức thì; ⚠ tốt cho việc lưu vết chứ không tốt cho việc hiểu nhau.

  • C (nhắn tin tức thời) — ⚠ nhanh nhưng băng thông rất hẹp; ⚠ dễ hiểu nhầm giọng điệu, và câu ngắn thường bỏ mất ngữ cảnh.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26889 cùng lô (giao tiếp phi lời nói chiếm hơn một nửa), ⚠ #26900 cùng lô (khi nào đội ảo là cần thiết), ⚠ #26883 cùng lô (mô hình truyền thông), ⚠ #26827 lô 201 (chọn kênh cho đội từ xa), ⚠ #26932 cùng lô (giao tiếp phi chính thức bằng lời).

⚠ Thứ tự BĂNG THÔNG của các kênh: | Kênh | Băng thông | |---|---| | ⚠ Mặt đối mặt, có bảng trắng | ⚠ cao nhất | | ⚠ Mặt đối mặt, không bảng | | | ⚠ Gọi video | ⚠ bản thay thế tốt nhất cho đội phân tán | | ⚠ Gọi thoại | ⚠ mất tín hiệu hình ảnh | | ⚠ Nhắn tin tức thời | | | ⚠ Email | ⚠ thấp nhất về mặt tương tác | | ⚠ Cách dùng bảng này | ⚠ việc càng nhiều bất định và càng dễ gây hiểu nhầm thì càng phải dùng kênh ở phía trên — còn thứ đã rõ ràng và cần lưu vết thì email lại là lựa chọn đúng |

⚠ Vì sao agile nhấn mạnh điều này: | Lý do | Nội dung | |---|---| | ⚠ Yêu cầu trong agile luôn còn mơ hồ khi bắt đầu | ⚠ cần hỏi đi hỏi lại mới rõ | | ⚠ Tài liệu không bao giờ chứa hết ngữ cảnh | | | ⚠ Vòng phản hồi ngắn là cốt lõi của agile | ⚠ nói chuyện là vòng phản hồi ngắn nhất | | ⚠ Hệ quả về bố trí chỗ ngồi | ⚠ đó là lý do agile ưu tiên đội ngồi CÙNG PHÒNG, và vì sao nhiều nhóm chấp nhận đánh đổi rất lớn để giữ điều đó |

Từ khoá nhận diện:

"cách trao đổi agile ưu tiên" → ⚠ MẶT ĐỐI MẶT "đội phân tán" → ⚠ gọi VIDEO là bản thay thế gần nhất "email" → ⚠ để lưu vết, không để hiểu nhau "gọi hội nghị" → ⚠ đồng bộ nhưng mất tín hiệu hình ảnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc phức tạp gần nhất của bạn được bàn qua kênh nào | | | Có cuộc trao đổi email dài nào lẽ ra chỉ cần năm phút nói chuyện không | | | Đội từ xa của bạn có bật camera không | |

Và lý do một cuộc nói chuyện năm phút thường thắng một chuỗi email cả ngày: vì hiểu nhầm được sửa ngay khi nó vừa xuất hiện, chứ không phải sau khi nó đã kịp sinh ra công việc sai.

Câu 480 Process
A project team has just completed the final work packages for a project. The project manager needs to find the final CPI for the project. The BAC was $250,000, but the actual costs came in at $286,000. What's the final CPI?
  1. A –$36,000
  2. B $0.87
  3. C $286,000
  4. D The earned value information is needed to answer this question.
Xem giải thích

Đáp án

B — 0,87.

Vì sao đúng

⚠ Phép tính từng bước: | Bước | Nội dung | |---|---| | ⚠ Công thức: CPI = EV ÷ AC | | | ⚠ Dự án ĐÃ HOÀN THÀNH toàn bộ gói công việc | ⚠ chi tiết quyết định của đề | | ⚠ Hoàn thành 100% ⇒ EV = BAC = 250.000 | ⚠ giá trị thu được đúng bằng ngân sách khi xong hết | | ⚠ AC = 286.000 | ⚠ đề cho thẳng | | ⚠ CPI = 250.000 ÷ 286.000 = 0,874… | ⚠ làm tròn 0,87 | | ⚠ Diễn giải | ⚠ cứ mỗi đồng bỏ ra chỉ thu về 0,87 đồng giá trị — dự án vượt chi |

⚠ Chìa khoá của cả câu: ⚠ nhận ra rằng "đã hoàn thành các gói công việc cuối cùng" chính là cách đề cho biết EV ⚠ — ⚠ không có câu đó thì đúng là thiếu dữ kiện thật.

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

  • D (cần thêm thông tin giá trị thu được mới trả lời được) — ⚠ phương án gây nhiễu mạnh nhất, và là bẫy chính của câu này vì ⚠ đề quả thật KHÔNG viết chữ "EV" ở đâu cả, nên người đọc nhanh sẽ thấy thiếu dữ kiện: ⚠ nhưng ⚠ EV đã được cho một cách GIÁN TIẾP qua câu "vừa hoàn thành các gói công việc cuối cùng" ⚠ — ⚠ khi tiến độ đạt 100%, giá trị thu được nhất thiết bằng ngân sách hoàn thành; ⚠ PMI rất hay dùng kiểu cho dữ kiện gián tiếp này, và phương án "không đủ dữ kiện" gần như luôn sai khi bài toán có một mối quan hệ ẩn như vậy.

  • A (−36.000) — ⚠ đó là CV (chênh lệch chi phí) chứ không phải CPI; ⚠ CV = EV − AC = 250.000 − 286.000 = −36.000, và CV là số tiền còn CPI là tỷ số.

  • C (286.000) — ⚠ đó chính là AC; ⚠ chép lại một dữ kiện của đề chứ không tính gì.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án đúng viết là "$0.87", tức là gắn ký hiệu tiền tệ vào CPI ⚠ — ⚠ CPI là một TỶ SỐ giữa hai số tiền nên nó KHÔNG CÓ ĐƠN VỊ; viết "$0,87" là sai về mặt đơn vị; ⚠ cách viết đúng là "CPI = 0,87"; ⚠ trong phòng thi vẫn chọn phương án đó vì con số đúng, nhưng đừng học theo cách ghi — và hãy để ý rằng chính lỗi đơn vị này giúp loại nhanh phương án A (−36.000, có đơn vị tiền, là CV) và C (286.000, cũng có đơn vị tiền, là AC).

⚠ Đối chiếu: ⚠ #26812 lô 201 (CPI = 240.000 ÷ 270.000 = 0,89), ⚠ #26810 lô 201 (giá trị thu được), ⚠ #26895 cùng lô (phân tích xu hướng), ⚠ #26840 lô 202 (ROI).

⚠ Bốn con số nền và cách phân biệt: | Ký hiệu | Nghĩa | |---|---| | ⚠ PV | ⚠ giá trị kế hoạch — lẽ ra phải làm được bao nhiêu tới lúc này | | ⚠ EV | ⚠ giá trị thu được — thực tế đã làm được bao nhiêu, tính theo ngân sách | | ⚠ AC | ⚠ chi phí thực tế — đã tiêu bao nhiêu | | ⚠ BAC | ⚠ ngân sách khi hoàn thành — tổng kế hoạch | | ⚠ Quan hệ then chốt của câu này | ⚠ khi dự án xong 100%: EV = BAC, và PV cũng bằng BAC — nên chỉ cần BAC và AC là tính được cả CPI lẫn CV cuối cùng |

⚠ Bảng công thức và cách đọc: | Công thức | Đọc thế nào | |---|---| | ⚠ CV = EV − AC | ⚠ số ÂM là vượt chi — ở đây −36.000 | | ⚠ CPI = EV ÷ AC | ⚠ dưới 1 là vượt chi — ở đây 0,87 | | ⚠ SV = EV − PV | ⚠ âm là chậm tiến độ | | ⚠ SPI = EV ÷ PV | ⚠ ở đây = 1 vì đã xong hết | | ⚠ Mẹo nhớ | ⚠ chỉ số nào cũng lấy EV làm số đầu; TRỪ ra chênh lệch bằng tiền, CHIA ra chỉ số không đơn vị — và nhớ "dưới 1 hoặc dưới 0 đều là xấu" |

⚠ CPI 0,87 nghĩa là gì với dự án này: | Góc nhìn | Nội dung | |---|---| | ⚠ Vượt chi 36.000 trên ngân sách 250.000 | ⚠ khoảng 14,4% | | ⚠ Hiệu quả chi phí đạt 87% | | | ⚠ Dự án đã XONG nên đây là con số CUỐI CÙNG | ⚠ không còn cơ hội cải thiện | | ⚠ Giá trị của việc tính nó | ⚠ CPI cuối cùng là dữ liệu để hiệu chỉnh cách ước lượng cho dự án SAU — nếu các dự án của bạn đều kết thúc quanh 0,87 thì vấn đề nằm ở cách ước lượng chứ không ở việc thực thi |

Từ khoá nhận diện:

"đã hoàn thành các gói công việc cuối cùng" → ⚠ EV = BAC, đây là dữ kiện ẩn "CPI" → ⚠ EV ÷ AC, TỶ SỐ không có đơn vị tiền "−36.000" → ⚠ đó là CV, không phải CPI "cần thêm EV" → ⚠ bẫy — EV đã được cho gián tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tính lại 250.000 ÷ 286.000 để tự xác nhận 0,87 không | | | Bạn có phân biệt được CV và CPI khi nhìn con số trần không | | | Dự án gần nhất của bạn kết thúc với CPI bao nhiêu | |

Và điều mà một CPI cuối cùng bằng 0,87 nói về tổ chức nhiều hơn về dự án: rằng ước lượng ban đầu đã lệch khoảng một phần bảy — và con số đó chỉ có ích nếu dự án sau được lập kế hoạch với nó trong tay.