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

Đáp án

D — Product owner KHÔNG NÊN cố tác động vào việc đội lập kế hoạch thực hiện dự án như thế nào.

Vì sao đúng

⚠ Vì sao product owner sai ở đây: | Lý do | Nội dung | |---|---| | ⚠ SỨC CHỨA của đội do CHÍNH ĐỘI xác định | ⚠ ranh giới vai trò rõ ràng trong Scrum | | ⚠ Velocity KHÔNG chuyển được giữa các đội | ⚠ liên hệ #25908 lô 183 — hỏi gần như cùng vấn đề | | ⚠ Story point mỗi đội quy ước khác nhau | ⚠ 50 điểm của đội cũ không bằng 50 điểm của đội này | | ⚠ Đội mới CHƯA CÓ velocity — 40 điểm chỉ là ước đoán ban đầu | ⚠ và ước đoán đó là quyền của đội | | ⚠ PO được làm gì | ⚠ quyết CÁI GÌ và THỨ TỰ; đội quyết BAO NHIÊU và THẾ NÀO |

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

• B (PO đúng; điểm là quy ước tuỳ ý nên chọn 50 thay vì 40 cũng được) — ⚠ phương án gây nhiễu mạnh nhất vì vế đầu ĐÚNG: ⚠ story point ⚠ thật sự là đơn vị quy ước; ⚠ nhưng kết luận thì SAI — ⚠ chính vì nó là quy ước RIÊNG của mỗi đội nên KHÔNG mượn được từ đội khác; ⚠ nửa đúng ở tiền đề dẫn tới kết luận ngược hẳn.

• A (PO không nên phát biểu vì Scrum Master phụ trách bàn về sức chứa) — ⚠ SAI VAI: ⚠ Scrum Master ⚠ KHÔNG quyết sức chứa ⚠ — đó là việc của đội; ⚠ và PO hoàn toàn được có mặt và phát biểu trong buổi lập kế hoạch sprint.

• C (không phương án nào) — ⚠ sai vì D đúng.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG: ⚠ câu #25908 ở lô 183 ⚠ (đồng nghiệp đưa dữ liệu lịch sử, đề nghị tính velocity và chốt ngày kết thúc → giải thích rằng agile không làm vậy). ⚠ Hai câu cùng chủ đề "không mượn velocity của người khác", khoá NHẤT QUÁN. ⚠ Khác biệt: #25908 là người ngoài đội thiếu hiểu biết về agile, còn ở đây là PRODUCT OWNER — người đáng lẽ phải hiểu vai trò của mình. ⚠ Xem thêm câu #25915 (PO phàn nàn đội không tập trung), #25903 (điều tra biến động velocity), #25931 (người mới làm velocity giảm).

⚠ Ranh giới vai trò trong lập kế hoạch sprint: | Ai | Quyết gì | |---|---| | ⚠ PRODUCT OWNER | ⚠ CÁI GÌ được ưu tiên, VÌ SAO nó quan trọng, mục tiêu sprint mong muốn | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ BAO NHIÊU việc nhận được, LÀM THẾ NÀO, ước lượng | | ⚠ SCRUM MASTER | ⚠ ĐIỀU PHỐI buổi họp, bảo vệ ranh giới vai trò | | ⚠ Vi phạm phổ biến nhất | ⚠ PO hoặc quản lý ép đội nhận nhiều việc hơn sức chứa | | ⚠ Hậu quả | ⚠ đội cam kết quá tay → không giao đủ → mất niềm tin → lần sau cam kết dè dặt hơn thật |

Từ khoá nhận diện:

"lấy velocity của dự án khác làm chuẩn" → ⚠ luôn sai "điểm là quy ước tuỳ ý" → ⚠ đúng, nhưng là quy ước RIÊNG của mỗi đội "Scrum Master quản lý sức chứa" → ⚠ sai vai "PO không được phát biểu" → ⚠ cũng sai — PO được nói, chỉ không được ÁP ĐẶT

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có bị so velocity với đội khác không | | | Ai là người chốt số điểm nhận vào mỗi sprint | | | Velocity của đội bạn có xu hướng tăng đều một cách đáng ngờ không | ⚠ dấu hiệu lạm phát điểm |

Và điều product owner ở đây quên mất: anh ta có toàn quyền quyết định đội làm việc gì trước, và không có chút quyền nào quyết định đội làm được bao nhiêu.

Đáp án

A — BẮT ĐẦU bằng các VÒNG LẶP NGẮN theo hướng đi khả thi nhất, và HỌC DẦN trong quá trình làm.

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Thiết bị lọc nước ĐỘT PHÁ | ⚠ sản phẩm mới hoàn toàn, chưa ai làm | | ⚠ Đội không biết sản phẩm cuối trông thế nào | ⚠ bất định RẤT CAO về cả yêu cầu lẫn kỹ thuật | | ⚠ Đội liên chức năng, có đủ kỹ năng | ⚠ đủ năng lực để tự khám phá | | ⚠ Tổ chức đang chuyển sang agile | ⚠ đây là cơ hội để đội học cách làm mới | | ⚠ Cách đúng | ⚠ không thể lập kế hoạch cho thứ chưa ai biết — phải LÀM để BIẾT |

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

• C (thực hiện một research spike) — ⚠ phương án gây nhiễu mạnh nhất và ⚠ KHÔNG hề sai về nguyên tắc ⚠ — spike là công cụ đúng để giảm bất định kỹ thuật (liên hệ #25919 lô 183): ⚠ nhưng ở đây bất định lớn tới mức ⚠ một spike đơn lẻ không đủ; ⚠ cả dự án cần chạy theo vòng lặp, chứ không chỉ cần một lần nghiên cứu rồi mới bắt đầu. ⚠ Spike là một BƯỚC bên trong phương án A, không phải phương án thay thế.

• B (hỏi khách hàng thông tin chi tiết hơn) — ⚠ khách hàng CŨNG KHÔNG BIẾT; ⚠ đây là sản phẩm đột phá, không phải sản phẩm sao chép; ⚠ hỏi thêm chỉ nhận về phỏng đoán.

• D (làm theo điều lệ dự án) — ⚠ điều lệ nêu MỤC TIÊU cấp cao, ⚠ không nói cách tạo ra một thiết bị chưa ai từng làm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25988 ở lô này (xây nhà → dự đoán) là ĐỐI CỰC của câu này; ⚠ câu #25984 (bàn giao tăng dần), câu #25974 ở lô 184 (tư duy agile cho dự án dài hạn bất định), và câu #25972 (nguyên mẫu kiểm chứng ý tưởng). ⚠ Cả nhóm về chọn cách tiếp cận theo mức bất định.

⚠ Vì sao vòng lặp ngắn là câu trả lời cho bất định cao: | Lý do | Nội dung | |---|---| | ⚠ Mỗi vòng lặp tạo ra KIẾN THỨC MỚI | ⚠ thứ có giá trị nhất khi chưa biết gì | | ⚠ Sai thì sai NHỎ và sai SỚM | | | ⚠ Đổi hướng được mà không mất nhiều | | | ⚠ Có thứ CỤ THỂ để bên liên quan phản hồi | ⚠ mô tả bằng lời không bao giờ đủ | | ⚠ Nguyên tắc nền | ⚠ khi không thể lập kế hoạch cho toàn bộ, hãy lập kế hoạch cho bước tiếp theo và học từ nó |

Từ khoá nhận diện:

"chưa biết sản phẩm cuối trông thế nào" → ⚠ vòng lặp ngắn, học dần "hỏi khách hàng chi tiết hơn" → ⚠ vô ích khi chính khách hàng cũng chưa biết "làm theo điều lệ" → ⚠ điều lệ nêu mục tiêu, không nêu cách làm "spike" → ⚠ công cụ đúng, nhưng là MỘT BƯỚC chứ không phải cả chiến lược

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Điều bất định nhất trong dự án của bạn là gì | ⚠ đó nên là thứ làm trước | | Vòng lặp của bạn dài bao lâu | ⚠ bất định càng cao thì vòng lặp càng nên ngắn | | Tổ chức có chấp nhận kết quả "hướng này không đi được" không | |

Và điều đội của Skylark cần nghe nhất lúc này: việc không biết sản phẩm cuối trông thế nào không phải là vấn đề cần giải quyết trước khi bắt đầu — nó chính là lý do phải bắt đầu.

Đáp án

C — SIÊU DỰ ÁN (megaproject).

Vì sao đúng

⚠ Ba tiêu chí trong đề đều là định nghĩa siêu dự án: | Tiêu chí | Ngưỡng | |---|---| | ⚠ CHI PHÍ | ⚠ từ 1 tỷ đô la trở lên | | ⚠ SỐ NGƯỜI ẢNH HƯỞNG | ⚠ từ 1 triệu người trở lên | | ⚠ THỜI GIAN | ⚠ kéo dài nhiều năm | | ⚠ Ví dụ thực tế | ⚠ tàu điện ngầm đô thị, sân bay quốc tế, đập thuỷ điện, mạng lưới đường cao tốc, chương trình vũ trụ | | ⚠ Đặc điểm khác | ⚠ rất nhiều bên liên quan, chịu giám sát chính trị và truyền thông, rủi ro cực cao |

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

• A (chương trình — program) — ⚠ phương án gây nhiễu mạnh nhất vì siêu dự án thường ĐƯỢC quản lý dưới dạng chương trình: ⚠ nhưng chương trình được định nghĩa bằng ⚠ CẤU TRÚC — một nhóm dự án liên quan được quản lý phối hợp để thu lợi ích mà quản lý riêng lẻ không có được ⚠ — chứ ⚠ KHÔNG định nghĩa bằng QUY MÔ TIỀN hay SỐ NGƯỜI; ⚠ một chương trình có thể chỉ vài triệu đô.

• D (danh mục — portfolio) — ⚠ tập hợp dự án, chương trình và hoạt động vận hành được quản lý chung để đạt MỤC TIÊU CHIẾN LƯỢC; ⚠ các thành phần trong danh mục ⚠ KHÔNG nhất thiết liên quan tới nhau.

• B (macro project) — ⚠ KHÔNG phải thuật ngữ chuẩn trong tài liệu PMI.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25601/#25644/#25861 (ba câu về các loại PMO), câu #25892 ở lô 183 (rủi ro hệ thống → leo thang), và câu #25973 ở lô 184 (bên liên quan chính của mọi dự án). ⚠ Nhóm quản trị dự án ở tầng tổ chức.

⚠ Bốn tầng của quản trị theo dự án: | Tầng | Định nghĩa | Đo bằng | |---|---|---| | ⚠ DỰ ÁN | ⚠ nỗ lực TẠM THỜI tạo ra sản phẩm hoặc kết quả DUY NHẤT | ⚠ có ngày bắt đầu và kết thúc | | ⚠ CHƯƠNG TRÌNH | ⚠ nhóm dự án LIÊN QUAN quản lý phối hợp | ⚠ lợi ích cộng hưởng | | ⚠ DANH MỤC | ⚠ tập hợp dự án, chương trình, vận hành phục vụ CHIẾN LƯỢC | ⚠ không cần liên quan nhau | | ⚠ SIÊU DỰ ÁN | ⚠ dự án cực lớn — CÂU NÀY | ⚠ tiền, số người, thời gian | | ⚠ Điểm phân biệt cốt lõi | ⚠ ba tầng đầu định nghĩa bằng CẤU TRÚC và MỤC ĐÍCH; siêu dự án định nghĩa bằng QUY MÔ |

Từ khoá nhận diện:

"1 tỷ đô, 1 triệu người, nhiều năm" → ⚠ siêu dự án "nhóm dự án liên quan, lợi ích cộng hưởng" → ⚠ chương trình "phù hợp với chiến lược, không cần liên quan nhau" → ⚠ danh mục ⚠ Thuật ngữ nghe lạ tai như "macro project" → ⚠ thường là phương án bịa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công việc của bạn là dự án, chương trình hay danh mục | ⚠ gọi sai tên thì áp sai cơ chế quản trị | | Các dự án của bạn có liên quan tới nhau không | ⚠ có thì nên quản lý như chương trình | | Danh mục của tổ chức có gắn với chiến lược không | |

Và điều thú vị về câu hỏi này: nó là câu duy nhất trong bộ đề mà đáp án được xác định hoàn toàn bằng CON SỐ, chứ không bằng bản chất công việc.

Đáp án

D — LẬP KẾ HOẠCH MUA SẮM (procurement planning).

Vì sao đúng

⚠ Vì sao phân tích make-or-buy thuộc bước lập kế hoạch: | Lý do | Nội dung | |---|---| | ⚠ Nó trả lời câu hỏi CÓ MUA HAY KHÔNG | ⚠ quyết định này phải có TRƯỚC mọi hoạt động mua sắm khác | | ⚠ Kết quả quyết định có cần tài liệu mời thầu hay không | ⚠ liên hệ #25943 lô 184 — RFQ/RFP/RFI | | ⚠ Là đầu vào để lập KẾ HOẠCH QUẢN LÝ MUA SẮM | | | ⚠ Diễn ra ở giai đoạn LẬP KẾ HOẠCH của dự án | | | ⚠ Logic đơn giản | ⚠ chưa quyết mua hay tự làm thì chưa có gì để chọn nhà cung cấp hay để đóng hợp đồng |

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

• C (chọn nhà cung cấp — source selection) — ⚠ phương án gây nhiễu mạnh nhất vì cũng thuộc mua sắm: ⚠ nhưng chọn nhà cung cấp diễn ra ⚠ SAU KHI đã quyết định MUA; ⚠ nếu kết luận là TỰ LÀM thì bước này không bao giờ xảy ra.

• B (đóng hợp đồng — contract closeout) — ⚠ bước CUỐI CÙNG ⚠ (liên hệ #25969 lô 184); ⚠ muộn hơn rất nhiều.

• A (khởi tạo) — ⚠ giai đoạn xác lập dự án và ban hành điều lệ; ⚠ chưa đi vào chi tiết mua sắm.

Ghi nhớ

⚠ Đối chiếu — bộ câu về mua sắm đã lên SÁU câu: ⚠ #25907 lô 183 (tính điểm hoà vốn make-or-buy = 17 tháng), ⚠ #25941 lô 184 (tìm gói thầu qua quảng cáo), ⚠ #25943 (RFQ), ⚠ #25951 (mua sắm agile), ⚠ #25960 (T&M phải có trần), ⚠ #25969 (đóng mua sắm khi cả hai bên thoả mãn), ⚠ và câu này. ⚠ #25907 và câu này là cặp đẹp: một câu hỏi TÍNH make-or-buy thế nào, câu này hỏi nó NẰM Ở ĐÂU trong quy trình.

⚠ Trình tự quản lý mua sắm: | Bước | Nội dung | |---|---| | ⚠ 1. LẬP KẾ HOẠCH MUA SẮM | ⚠ phân tích make-or-buy, chọn loại hợp đồng, soạn phạm vi công việc — CÂU NÀY | | ⚠ 2. THỰC HIỆN MUA SẮM | ⚠ quảng cáo, hội nghị nhà thầu, nhận hồ sơ, CHỌN NHÀ CUNG CẤP, ký hợp đồng | | ⚠ 3. KIỂM SOÁT MUA SẮM | ⚠ giám sát hiệu quả, quản lý thay đổi hợp đồng, thanh toán | | ⚠ 4. ĐÓNG MUA SẮM | ⚠ nghiệm thu, giải quyết khiếu nại, lưu hồ sơ | | ⚠ Lưu ý | ⚠ PMBOK phiên bản mới gộp bước 4 vào bước 3, nhưng đề vẫn hay hỏi theo bốn bước |

⚠ Phân tích make-or-buy xét những gì: | Yếu tố | Nội dung | |---|---| | ⚠ CHI PHÍ trực tiếp và gián tiếp | ⚠ liên hệ #25907 — điểm hoà vốn | | ⚠ NĂNG LỰC nội bộ có làm nổi không | | | ⚠ Có phải NĂNG LỰC CỐT LÕI của tổ chức không | ⚠ cốt lõi thì nên tự làm dù đắt hơn | | ⚠ THỜI GIAN — bên nào nhanh hơn | ⚠ rất quan trọng vì đề nói dự án ĐANG TRỄ | | ⚠ RỦI RO phụ thuộc nhà cung cấp | | | ⚠ Quyền SỞ HỮU TRÍ TUỆ | | | ⚠ Chi phí bảo trì lâu dài | | | ⚠ Ở tình huống này | ⚠ dự án đang TRỄ nên yếu tố THỜI GIAN có thể quan trọng hơn cả chi phí — mua sẵn thường nhanh hơn tự viết |

Từ khoá nhận diện:

"tự làm hay mua" → ⚠ lập kế hoạch mua sắm "chọn nhà thầu nào" → ⚠ thực hiện mua sắm "giám sát nhà thầu, thanh toán" → ⚠ kiểm soát mua sắm "nghiệm thu, lưu hồ sơ, khiếu nại" → ⚠ đóng mua sắm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyết định make-or-buy của bạn có tính cả thời gian mua sắm không | | | Đây có phải năng lực cốt lõi của tổ chức không | | | Ai sẽ bảo trì phần này sau khi dự án đóng | ⚠ câu hỏi hay bị bỏ qua nhất khi mua ngoài |

Và điều đáng nhớ về vị trí của phân tích này trong quy trình: nó là cánh cửa đầu tiên của mua sắm. Quyết định sai ở đây thì mọi bước sau, dù làm tốt tới đâu, cũng chỉ là thực hiện xuất sắc một lựa chọn sai.

Đáp án

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

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Tài liệu bao quát NHU CẦU TỔNG THỂ của dự án | ⚠ mô tả ở mức sản phẩm | | ⚠ Cung cấp ĐẶC TẢ cho từng bàn giao | ⚠ từ khoá quyết định — đặc tả là mô tả đặc điểm | | ⚠ Ứng dụng web gồm phần hoá đơn, bán hàng, chăm sóc khách hàng | ⚠ cấu trúc của sản phẩm | | ⚠ Liệt kê CHỨC NĂNG MONG MUỐN của từng phần | ⚠ đặc điểm, không phải điều kiện nghiệm thu | | ⚠ Định nghĩa | ⚠ mô tả phạm vi sản phẩm nêu ĐẶC ĐIỂM của sản phẩm hoặc dịch vụ mà dự án tạo ra |

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

• D (bàn giao) — ⚠ phương án gây nhiễu mạnh nhất vì đề có chữ "nhiều bàn giao": ⚠ nhưng ⚠ bàn giao là DANH SÁCH những thứ phải tạo ra, ⚠ còn ở đây trọng tâm là ⚠ ĐẶC TẢ và CHỨC NĂNG của từng thứ ⚠ — đó là mô tả phạm vi sản phẩm.

• A (tiêu chí chấp nhận) — ⚠ điều kiện để được NGHIỆM THU; ⚠ đề mô tả sản phẩm CÓ GÌ, không nói thế nào thì được chấp nhận.

• B (loại trừ khỏi phạm vi) — ⚠ những thứ dự án KHÔNG làm; ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Đối chiếu — BỘ BỐN MỤC của tuyên bố phạm vi ĐÃ ĐỦ, qua ba lô: | Mục | Câu | Nội dung tình huống | |---|---|---| | ⚠ BÀN GIAO | ⚠ #25959 (lô 184) | ⚠ 100 máy in, mực, phụ tùng, bảo trì một năm | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ #25977 (lô 184) | ⚠ bản mẫu bị từ chối vì bảng màu không thân thiện với người mù màu | | ⚠ LOẠI TRỪ KHỎI PHẠM VI | ⚠ #25989 (lô này) | ⚠ Enrique nói rõ đội không làm phần thẩm mỹ | | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | ⚠ #25997 (lô này) | ⚠ ứng dụng web ba phần với chức năng của từng phần | | ⚠ Bốn khoá HOÀN TOÀN NHẤT QUÁN | ⚠ bốn câu hỏi về bốn mục khác nhau của cùng một tài liệu — bộ đề kiểm tra từng mục một cách có hệ thống | | ⚠ Ghi chú ở #25989 đã dự đoán đúng | ⚠ "nếu gặp câu về đặc điểm kỹ thuật của sản phẩm thì đó là mục thứ tư" — chính là câu này |

⚠ Bảng phân biệt bốn mục — câu hỏi để chọn: | Nếu đề nhấn vào... | Thì là mục... | |---|---| | ⚠ Sản phẩm CÓ GÌ, chức năng thế nào | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | | ⚠ Phải TẠO RA những gì, số lượng bao nhiêu | ⚠ BÀN GIAO | | ⚠ Thế nào thì ĐƯỢC CHẤP NHẬN | ⚠ TIÊU CHÍ CHẤP NHẬN | | ⚠ KHÔNG làm gì | ⚠ LOẠI TRỪ KHỎI PHẠM VI | | ⚠ Mẹo nhanh nhất | ⚠ hỏi xem đề đang mô tả SẢN PHẨM hay đang mô tả CÔNG VIỆC hay đang mô tả ĐIỀU KIỆN |

Từ khoá nhận diện:

"đặc tả, chức năng, thành phần của sản phẩm" → ⚠ mô tả phạm vi sản phẩm "danh sách phải giao, số lượng" → ⚠ bàn giao "chấp nhận / từ chối vì một điều kiện" → ⚠ tiêu chí chấp nhận "không thuộc dự án này" → ⚠ loại trừ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyên bố phạm vi của bạn có đủ bốn mục không | | | Mô tả phạm vi sản phẩm có đủ chi tiết để lập WBS không | | | Bên liên quan đã xác nhận nó chưa | |

Và lý do bộ đề hỏi cả bốn mục qua ba lô liên tiếp: tuyên bố phạm vi là tài liệu mà mọi tranh chấp về sau đều quay lại tra cứu — và mỗi mục trong đó chặn một loại tranh chấp khác nhau.

Đáp án

D — Mục tiêu của CÔNG TY và của ĐỘI TRỘI HƠN mục tiêu cá nhân, nhưng vẫn luôn quan trọng khi đáp ứng được cả mục tiêu cá nhân.

Vì sao đúng

⚠ Vì sao đây là câu trả lời cân bằng đúng: | Vế | Nội dung | |---|---| | ⚠ Mục tiêu tổ chức và đội được ưu tiên | ⚠ dự án tồn tại để phục vụ mục tiêu kinh doanh | | ⚠ Nhưng KHÔNG bỏ qua mục tiêu cá nhân | ⚠ vì đó là nguồn động lực | | ⚠ Roy là HUẤN LUYỆN VIÊN, gặp riêng từng người | ⚠ đúng bối cảnh để tìm hiểu động lực cá nhân | | ⚠ Ba phương án còn lại đều cực đoan về một phía | ⚠ mẫu hình quen thuộc: đáp án đúng thường là câu cân bằng có điều kiện | | ⚠ Thực tế | ⚠ người ta làm việc hết mình khi thấy mục tiêu chung có chỗ cho mục tiêu riêng của mình |

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

• B (mục tiêu cá nhân QUAN TRỌNG NGANG mục tiêu khác) — ⚠ phương án gây nhiễu mạnh nhất vì agile thật sự đề cao "cá nhân và tương tác": ⚠ nhưng giá trị đó nói về ⚠ cách LÀM VIỆC với con người, ⚠ không có nghĩa mục tiêu riêng ngang hàng với mục tiêu kinh doanh của dự án; ⚠ nếu ngang hàng thì khi mâu thuẫn sẽ không có cách nào quyết.

• C (mục tiêu công ty quan trọng hơn tất cả) — ⚠ cực đoan ngược lại; ⚠ bỏ qua động lực cá nhân là cách nhanh nhất để mất người giỏi.

• A (mục tiêu dự án quan trọng hơn mọi thứ) — ⚠ đặt DỰ ÁN lên trên CÔNG TY, ⚠ sai thứ tự; ⚠ dự án phục vụ tổ chức, không phải ngược lại.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25930 ở lô 183 (thuyết kỳ vọng Vroom — ba thành phần của động lực), câu #25952 ở lô 184 (Carol thể hiện lãnh đạo phục vụ), câu #25958 (tổ chức gọi quản lý là huấn luyện viên), và câu #25992 ở lô này (môi trường an toàn để bất đồng). ⚠ Nhóm lãnh đạo và động lực đã lên năm câu.

⚠ Ba tầng mục tiêu và cách xử lý khi mâu thuẫn: | Tầng | Ví dụ | Ưu tiên | |---|---|---| | ⚠ TỔ CHỨC | ⚠ tăng thị phần, giảm chi phí vận hành | ⚠ cao nhất | | ⚠ ĐỘI / DỰ ÁN | ⚠ giao sản phẩm đúng hạn, đạt chất lượng | ⚠ phục vụ tầng trên | | ⚠ CÁ NHÂN | ⚠ học công nghệ mới, thăng tiến, cân bằng cuộc sống | ⚠ cần được đáp ứng khi có thể | | ⚠ Khi mâu thuẫn | ⚠ ưu tiên tầng cao hơn, nhưng phải NÓI RÕ lý do và tìm cách bù đắp | | ⚠ Khi trùng nhau | ⚠ đó là điểm ngọt — giao đúng việc cho đúng người thì cả ba tầng cùng thắng |

Từ khoá nhận diện:

"cân bằng, trội hơn nhưng vẫn quan trọng" → ⚠ thường là đáp án đúng "quan trọng hơn tất cả" → ⚠ cực đoan, thường sai "ngang bằng nhau hoàn toàn" → ⚠ cũng cực đoan, không giải quyết được mâu thuẫn "dự án quan trọng hơn công ty" → ⚠ sai thứ tự

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết mục tiêu nghề nghiệp của từng người trong đội không | | | Có ai đang làm việc hoàn toàn không giúp gì cho mục tiêu riêng của họ không | | | Buổi gặp riêng của bạn nói về con người hay về tiến độ | |

Và điều một huấn luyện viên giỏi hiểu về thứ tự ưu tiên này: nói rằng mục tiêu công ty quan trọng hơn là điều dễ. Việc khó là làm cho công việc phục vụ mục tiêu công ty đồng thời cũng đưa từng người tiến thêm một bước trên con đường của họ.

Đáp án

A — CÁCH TIẾN HÀNH KIỂM TOÁN CHẤT LƯỢNG (đây KHÔNG phải chủ đề của buổi họp kết thúc).

Vì sao đúng

⚠ Vì sao chủ đề này không thuộc buổi họp kết thúc: | Lý do | Nội dung | |---|---| | ⚠ Kiểm toán chất lượng diễn ra TRONG lúc dự án chạy | ⚠ liên hệ #25947 lô 184 — kiểm toán tìm nguyên nhân gốc giữa dự án | | ⚠ "CÁCH TIẾN HÀNH" là hướng dẫn QUY TRÌNH, không phải nội dung tổng kết | ⚠ thuộc kế hoạch quản lý chất lượng | | ⚠ Buổi kết thúc bàn về KẾT QUẢ và BÀI HỌC, không dạy quy trình | | | ⚠ Ba phương án còn lại | ⚠ đều khớp với danh sách chủ đề mà đội và Clark đã chuẩn bị | | ⚠ Lưu ý | ⚠ "kết quả của các cuộc kiểm toán đã làm" thì CÓ THỂ bàn — nhưng "cách tiến hành kiểm toán" thì không |

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

• B (đào tạo nhân sự về quy trình quản lý dự án nội bộ và cải tiến các quy trình đó) — ⚠ phương án gây nhiễu mạnh nhất vì cũng nghe như chuyện quy trình: ⚠ nhưng nó khớp trực tiếp với ⚠ khuyến nghị phần mềm quản lý dự án hiệu quả hơn ⚠ mà đội đã nêu, ⚠ và cải tiến quy trình tổ chức là ⚠ BÀI HỌC CHIẾN LƯỢC ⚠ — đúng đầu ra của buổi kết thúc (liên hệ #25964 lô 184).

• C (lấy nghiệm thu chính thức của khách hàng) — ⚠ hoạt động TRUNG TÂM của giai đoạn đóng ⚠ (liên hệ #25927 lô 183).

• D (mức độ phối hợp của đội dự án) — ⚠ bài học về con người, ⚠ khớp với việc đội đã nêu chuyện giao tiếp với khách hàng.

Ghi nhớ

⚠ Đối chiếu — nhóm giai đoạn ĐÓNG đã lên SÁU câu: ⚠ #25909 lô 183 (yếu tố khiến dự án hết cần thiết), ⚠ #25911 (báo cáo bài học cho họp tổng kết), ⚠ #25918 (rà soát mục tiêu đã hoàn thành), ⚠ #25927 (hoạt động của giai đoạn đóng), ⚠ #25964 lô 184 (không có bài học nhà cung cấp vì dùng nguồn lực nội bộ), ⚠ và câu này. ⚠ Xem thêm câu #26006 cũng ở lô này (vì sao phải viết bài học).

⚠ Chủ đề NÊN bàn trong buổi họp kết thúc: | Chủ đề | Nội dung | |---|---| | ⚠ Kết quả so với MỤC TIÊU và đường cơ sở | ⚠ liên hệ #25918 | | ⚠ NGHIỆM THU chính thức từ khách hàng | | | ⚠ Mức độ hài lòng của khách hàng | ⚠ Clark đã hỏi trước — chuẩn bị tốt | | ⚠ Bài học về QUY TRÌNH và công cụ | | | ⚠ Bài học về CON NGƯỜI và phối hợp | | | ⚠ Bài học CHIẾN LƯỢC ảnh hưởng tới phương pháp luận tổ chức | ⚠ liên hệ #25964 | | ⚠ Tình trạng hợp đồng và thanh toán | ⚠ liên hệ #25969 lô 184 | | ⚠ Kế hoạch chuyển giao cho vận hành | | | ⚠ KHÔNG bàn | ⚠ hướng dẫn quy trình, đào tạo kỹ thuật, kế hoạch cho dự án khác |

Từ khoá nhận diện:

"kết quả, bài học, nghiệm thu, hài lòng" → ⚠ thuộc buổi kết thúc "CÁCH TIẾN HÀNH một quy trình" → ⚠ thuộc kế hoạch, không thuộc buổi kết thúc "cải tiến quy trình cho tương lai" → ⚠ CÓ thuộc — đó là bài học chiến lược ⚠ Câu có chữ "KHÔNG" → ⚠ tìm cái khác nhóm, đừng tìm cái sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi kết thúc gần nhất của bạn có chương trình họp không | | | Bạn có hỏi khách hàng về mức hài lòng trước không | | | Bài học từ buổi đó có tới được kho của tổ chức không | |

Và tiêu chí đơn giản để lọc chương trình buổi họp kết thúc: mọi chủ đề phải trả lời được câu hỏi "chuyện gì đã xảy ra và ta học được gì" — bất cứ chủ đề nào trả lời "làm thế nào" đều thuộc một buổi họp khác.

Đáp án

B — Để KIỂM CHỨNG chức năng, BỔ SUNG THÊM cho kiểm thử tập trung vào chức năng.

Vì sao đúng

⚠ Kiểm thử thăm dò là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Người kiểm thử ĐỒNG THỜI thiết kế và thực hiện kiểm thử | ⚠ không theo kịch bản viết sẵn | | ⚠ Dựa vào KINH NGHIỆM và TRỰC GIÁC | | | ⚠ Tìm ra thứ mà kịch bản kiểm thử KHÔNG NGHĨ TỚI | ⚠ giá trị lớn nhất | | ⚠ BỔ SUNG, không thay thế kiểm thử theo kịch bản | ⚠ điểm mấu chốt của câu này | | ⚠ Vì sao cần cả hai | ⚠ kiểm thử theo kịch bản bảo đảm PHỦ những gì ĐÃ BIẾT; kiểm thử thăm dò tìm những gì CHƯA AI NGHĨ TỚI |

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

• C (dùng THAY CHO kiểm thử tập trung vào chức năng) — ⚠ phương án gây nhiễu mạnh nhất vì chỉ khác một chữ so với đáp án đúng: ⚠ nhưng ⚠ thăm dò KHÔNG THAY THẾ được kiểm thử theo kịch bản ⚠ — bỏ kịch bản đi thì mất tính lặp lại, mất phủ yêu cầu, và không tự động hoá được ⚠ (liên hệ #25986 cùng lô — CI cần kiểm thử tự động).

• A (để khám phá chức năng bên trong một user story) — ⚠ hiểu sai mục đích: ⚠ thăm dò để ⚠ TÌM LỖI, ⚠ không phải để tìm hiểu xem story có gì; ⚠ việc sau là của tinh chỉnh backlog.

• D (không dùng vào việc gì vì không phù hợp với dự án agile) — ⚠ sai hẳn: ⚠ thăm dò ⚠ RẤT phù hợp với agile ⚠ vì nhanh, linh hoạt và không cần tài liệu nặng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25986 ở lô này (tích hợp liên tục cần kiểm thử tự động), câu #25953 ở lô 184 (kiểm thử nằm trong Định nghĩa Hoàn thành), câu #25967 (phân tích xu hướng lỗi), và câu #25914 ở lô 183 (thiết kế thực nghiệm). ⚠ Nhóm chất lượng và kiểm thử.

⚠ Các loại kiểm thử và vai trò của chúng: | Loại | Đặc điểm | |---|---| | ⚠ KIỂM THỬ THEO KỊCH BẢN | ⚠ có bước viết sẵn, lặp lại được, TỰ ĐỘNG HOÁ được | | ⚠ KIỂM THỬ THĂM DÒ | ⚠ vừa thiết kế vừa chạy, dựa vào kinh nghiệm — CÂU NÀY | | ⚠ KIỂM THỬ TỰ ĐỘNG | ⚠ chạy trong CI mỗi lần build | | ⚠ KIỂM THỬ CHẤP NHẬN | ⚠ người dùng xác nhận đúng nhu cầu | | ⚠ Kết hợp đúng | ⚠ tự động hoá phần lặp lại, dành thời gian con người cho thăm dò — đó mới là dùng người đúng chỗ |

Từ khoá nhận diện:

"bổ sung thêm cho" → ⚠ thường là đáp án đúng khi hỏi về hai kỹ thuật cùng tồn tại "thay thế hoàn toàn" → ⚠ thường là cực đoan và sai "không phù hợp với agile" → ⚠ hầu như luôn sai với một thực hành kiểm thử chính thống "vừa thiết kế vừa chạy kiểm thử" → ⚠ thăm dò

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có dành thời gian cho kiểm thử thăm dò không | | | Lỗi nghiêm trọng gần nhất được tìm ra bằng cách nào | ⚠ kịch bản hay tình cờ | | Lỗi tìm được có được biến thành kiểm thử tự động không | |

Và lý do hai loại kiểm thử này không bao giờ thay thế nhau: kiểm thử theo kịch bản chứng minh phần mềm làm đúng những gì ta bảo nó làm; kiểm thử thăm dò tìm ra những gì ta quên chưa bảo nó.

Đáp án

C — GẶP CẢ HAI NHÓM và xác định thứ tự họ nhận bàn giao.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Nghe CẢ HAI phía trước khi quyết | ⚠ mỗi bên có nhu cầu kinh doanh thật của họ | | ⚠ Quyết định dựa trên NHU CẦU, không dựa trên QUYỀN LỰC | | | ⚠ Kết quả là một THỨ TỰ, không phải một bên thắng một bên thua | ⚠ cả hai đều nhận được, chỉ khác thời điểm | | ⚠ Hank ĐIỀU PHỐI, không phán xử | | | ⚠ Điểm quan trọng | ⚠ chuyển bài toán từ "AI ĐƯỢC" sang "THEO THỨ TỰ NÀO" — đó là cách gỡ bế tắc |

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

• D (giao cho bên liên quan có ẢNH HƯỞNG lớn hơn) và A (giao cho bên có QUYỀN LỰC lớn hơn) — ⚠ hai phương án gây nhiễu mạnh nhất vì ma trận quyền lực–quan tâm là công cụ có thật: ⚠ nhưng ⚠ ma trận đó dùng để lập KẾ HOẠCH GIAO TIẾP, KHÔNG dùng để phân xử tranh chấp; ⚠ quyết theo quyền lực sẽ dạy cả tổ chức rằng ⚠ muốn được ưu tiên thì phải to tiếng hơn.

• B (cho đội dự án bỏ phiếu) — ⚠ SAI VAI: ⚠ đội quyết CÁCH LÀM, ⚠ không quyết ai nhận sản phẩm trước; ⚠ và kéo đội vào tranh chấp giữa các bên liên quan là đặt họ vào thế khó.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG: ⚠ câu #25982 ở lô 184 ⚠ (hai bên liên quan cãi nhau về thứ tự ưu tiên công việc → xem lại thông tin từng bên rồi gặp chung thương lượng). ⚠ Hai câu gần như cùng một tình huống, khoá NHẤT QUÁN: gặp cả hai, không quyết thay, không theo quyền lực. ⚠ Khác biệt nhỏ: #25982 nhấn vào bước CHUẨN BỊ trước khi họp, câu này nhấn vào việc XÁC ĐỊNH THỨ TỰ như một giải pháp. ⚠ Xem thêm bộ bốn câu xung đột ở lô 184 (#25937, #25945, #25963, #25982) — ⚠ câu này là câu thứ NĂM, và cũng theo đúng nguyên tắc tương xứng.

⚠ Vì sao "xác định thứ tự" gỡ được bế tắc: | Lý do | Nội dung | |---|---| | ⚠ Biến bài toán ĐƯỢC/MẤT thành bài toán TRƯỚC/SAU | ⚠ cả hai đều được, chỉ là lệch thời gian | | ⚠ Có thể dựa trên tiêu chí KHÁCH QUAN | ⚠ nhóm nào cần gấp hơn, nhóm nào tạo giá trị sớm hơn | | ⚠ Nhóm nhận sau vẫn có ngày cụ thể để lập kế hoạch | ⚠ sự bất định mới là thứ khiến người ta lo lắng, không phải việc phải chờ | | ⚠ Đây chính là | ⚠ hướng tới giải pháp THẮNG-THẮNG, thay vì thắng-thua — liên hệ #25916 lô 183 |

Từ khoá nhận diện:

"hai nhóm tranh nhau nhận trước" → ⚠ gặp cả hai, xác định thứ tự "giao cho bên quyền lực hơn" → ⚠ né tránh việc phân xử, tạo tiền lệ xấu "cho đội bỏ phiếu" → ⚠ sai vai "ma trận quyền lực–quan tâm" → ⚠ để lập kế hoạch giao tiếp, không để phân xử

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có tiêu chí công khai để xếp thứ tự nhận bàn giao không | | | Bên liên quan có biết mình sẽ nhận cái gì vào lúc nào không | | | Tranh chấp gần nhất được giải quyết bằng lý lẽ hay bằng chức vụ | |

Và điều Hank cần nhớ khi bước vào cuộc gặp đó: không ai trong hai nhóm đang đòi hỏi vô lý — cả hai đều có việc phải làm và cần công cụ để làm. Việc của anh là sắp xếp thời gian, không phải chọn người thắng.

Đáp án

D — LÀM VIỆC CÙNG bên liên quan để XẾP HẠNG TUYỆT ĐỐI các công việc (stack rank).

Vì sao đúng

⚠ Vì sao xếp hạng tuyệt đối là lời giải: | Lý do | Nội dung | |---|---| | ⚠ "Mọi thứ đều ưu tiên cao nhất" = KHÔNG có ưu tiên nào | ⚠ về mặt logic, ưu tiên chỉ có nghĩa khi có thứ được xếp sau | | ⚠ Xếp hạng TUYỆT ĐỐI buộc phải chọn thứ tự 1, 2, 3... | ⚠ không cho phép hai việc cùng hạng | | ⚠ CÙNG bên liên quan làm, không tự làm | ⚠ họ mới biết giá trị kinh doanh | | ⚠ Buộc cuộc thảo luận đối diện với ĐÁNH ĐỔI thật | | | ⚠ Câu hỏi mở khoá | ⚠ "nếu chỉ làm được MỘT việc trong tuần tới thì đó là việc nào?" |

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

• A (đồng ý, nhưng tự gán mức ưu tiên khác nhau) — ⚠ phương án gây nhiễu mạnh nhất vì nó CÓ tạo ra thứ tự và tránh được xung đột: ⚠ nhưng ⚠ quản lý dự án KHÔNG có thẩm quyền quyết giá trị kinh doanh ⚠ (liên hệ #25982 lô 184 và #26001 cùng lô), ⚠ và làm sau lưng bên liên quan sẽ đổ vỡ ngay lần đầu họ phát hiện.

• B (xếp mọi việc ở mức cao) — ⚠ chấp nhận tình trạng vô nghĩa; ⚠ không giải quyết gì cả.

• C (leo thang lên uỷ ban chỉ đạo) — ⚠ quá sớm; ⚠ Zane chưa thử điều phối lần nào; ⚠ leo thang là bước SAU khi đã cố gắng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25982 ở lô 184 (hai bên liên quan bất đồng về ưu tiên), câu #26001 ở lô này (tranh nhau nhận bàn giao trước), câu #25912 ở lô 183 (PO xếp backlog theo rủi ro), và câu #25889 (xếp theo giá trị kinh doanh). ⚠ Xếp ưu tiên là chủ đề được hỏi rất dày.

⚠ Các kỹ thuật xếp ưu tiên: | Kỹ thuật | Cách làm | |---|---| | ⚠ XẾP HẠNG TUYỆT ĐỐI (stack ranking) | ⚠ buộc thành một danh sách 1, 2, 3... không có đồng hạng — CÂU NÀY | | ⚠ MoSCoW | ⚠ bắt buộc / nên có / có thì tốt / lần này không | | ⚠ Ma trận GIÁ TRỊ – NỖ LỰC | ⚠ làm trước thứ giá trị cao nỗ lực thấp | | ⚠ WSJF | ⚠ chi phí trì hoãn chia cho quy mô | | ⚠ Cho điểm 100 | ⚠ phát 100 điểm, bên liên quan tự phân bổ — rất hiệu quả với tình huống này | | ⚠ Điểm chung của mọi kỹ thuật tốt | ⚠ chúng buộc người ta phải ĐÁNH ĐỔI, chứ không cho phép nói "cái nào cũng quan trọng" |

Từ khoá nhận diện:

"mọi thứ đều ưu tiên cao nhất" → ⚠ xếp hạng tuyệt đối cùng bên liên quan "PM tự quyết ưu tiên" → ⚠ vượt thẩm quyền "leo thang ngay" → ⚠ quá sớm khi chưa thử điều phối "đồng ý cho xong" → ⚠ né tránh, vấn đề quay lại sau nặng hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách công việc của bạn có thứ tự tuyệt đối không | ⚠ hay có mười việc cùng hạng "cao" | | Bên liên quan có biết sức chứa thật của đội không | | | Việc xếp hạng thấp có bao giờ được làm không | ⚠ nếu không bao giờ, thì lần sau ai cũng sẽ nói việc mình là gấp |

Và câu nói mà Zane nên mang vào cuộc họp tiếp theo: "tôi tin là cả mười việc đều quan trọng — nên tôi cần các anh giúp tôi biết nên bắt đầu từ việc nào."