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

Tìm thấy 720 câu.

Câu 481 People
Fabian and his project team know that stakeholder engagement is of the utmost importance for a project to be successful. This is why the team’s stakeholder management plan includes multiple methods of stakeholder engagement. What other project management plan component should Fabian and his team include?
  1. A Project scope statement
  2. B Project schedule milestone charts
  3. C Project procurement contracts
  4. D Project communications management plan
Xem giải thích

Đáp án

D — KẾ HOẠCH QUẢN LÝ TRUYỀN THÔNG của dự án.

Vì sao đúng

⚠ Vì sao hai kế hoạch này đi liền nhau: | Quan hệ | Nội dung | |---|---| | ⚠ Kế hoạch BÊN LIÊN QUAN nói: gắn kết AI, ở mức nào | | | ⚠ Kế hoạch TRUYỀN THÔNG nói: gửi GÌ, cho ai, khi nào, bằng kênh nào | | | ⚠ Gắn kết bên liên quan THỰC HIỆN CHỦ YẾU qua truyền thông | ⚠ đây là mấu chốt | | ⚠ Có kế hoạch gắn kết mà không có kế hoạch truyền thông = biết muốn gì mà không biết làm thế nào | | | ⚠ Đầu vào của nhau | ⚠ sổ đăng ký bên liên quan là ĐẦU VÀO trực tiếp của quy trình lập kế hoạch truyền thông |

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

  • B (biểu đồ mốc lịch trình) — ⚠ phương án gây nhiễu mạnh nhất vì mốc lịch ⚠ đúng là thứ hay báo cho bên liên quan: ⚠ nhưng đó là ⚠ MỘT NỘI DUNG được truyền đạt, không phải KẾ HOẠCH về cách truyền đạt; ⚠ câu hỏi hỏi thành phần KẾ HOẠCH nào cần bổ sung.

  • A (mô tả phạm vi dự án) — ⚠ cần cho mọi dự án, ⚠ nhưng không gắn riêng với gắn kết bên liên quan.

  • C (hợp đồng mua sắm) — ⚠ chỉ liên quan tới bên liên quan là nhà cung cấp, ⚠ quá hẹp.

Ghi nhớ

⚠ Đối chiếu — nhóm bên liên quan trong lô này: ⚠ #26183 (thống nhất kỳ vọng lệch), ⚠ #26185 (ba bước phân tích), ⚠ #26191 (kỹ năng liên cá nhân), ⚠ #26205 (đưa vấn đề gắn kết vào báo cáo), ⚠ và câu này. ⚠ Năm câu trong một lô — nhóm được hỏi dày nhất. ⚠ Xem thêm #26192 cùng lô (ba yếu tố truyền thông).

⚠ Kế hoạch quản lý truyền thông gồm gì: | Thành phần | Nội dung | |---|---| | ⚠ AI cần thông tin gì | ⚠ lấy từ sổ đăng ký bên liên quan | | ⚠ NỘI DUNG, mức chi tiết, định dạng | ⚠ lãnh đạo cần một trang, đội cần chi tiết | | ⚠ TẦN SUẤT | ⚠ hằng ngày, hằng tuần, theo mốc | | ⚠ KÊNH | ⚠ email, họp, bảng thông tin — liên hệ #26208 cùng lô | | ⚠ AI CHỊU TRÁCH NHIỆM gửi | | | ⚠ Quy trình LEO THANG | ⚠ vấn đề nào báo lên ai, sau bao lâu | | ⚠ Từ điển thuật ngữ chung | ⚠ giảm nhiễu — liên hệ #26192 cùng lô | | ⚠ Cập nhật khi nào | ⚠ mỗi khi danh sách bên liên quan thay đổi |

Từ khoá nhận diện:

"kế hoạch bên liên quan cần đi kèm cái gì" → ⚠ kế hoạch quản lý truyền thông "biểu đồ mốc" → ⚠ nội dung được truyền, không phải kế hoạch truyền thông "mô tả phạm vi" → ⚠ cần nhưng không gắn riêng với gắn kết "hợp đồng mua sắm" → ⚠ chỉ cho nhóm nhà cung cấp

⚠ Hai kế hoạch phối hợp với nhau thế nào Ví dụ cụ thể
⚠ Kế hoạch bên liên quan: "giám đốc tài chính hiện TRUNG LẬP, cần đưa lên ỦNG HỘ" ⚠ mục tiêu
⚠ Kế hoạch truyền thông: "gửi báo cáo tài chính một trang hằng tháng, họp trực tiếp mỗi quý" ⚠ cách đạt mục tiêu
⚠ Không có vế hai ⚠ mục tiêu chỉ là mong muốn
⚠ Không có vế một ⚠ gửi báo cáo cho tất cả mọi người như nhau, tốn công mà không hiệu quả
⚠ Kết luận ⚠ hai kế hoạch này phải đọc cùng nhau mới có nghĩa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch truyền thông của bạn có phân biệt đối tượng không | ⚠ hay gửi cùng một báo cáo cho tất cả | | Mỗi mục trong kế hoạch gắn kết có cách thực hiện cụ thể không | | | Có bên liên quan nào không nhận được thông tin nào không | |

Và lý do hai kế hoạch này hay bị tách rời một cách vô ích: người ta viết kế hoạch gắn kết cho đẹp hồ sơ rồi truyền thông theo thói quen — kết quả là một tài liệu nói một đằng, thực tế làm một nẻo.

Câu 482 People
Petra is a project manager who works for an organization that allows many latitudes to get her work done. She alternates between a traditional waterfall approach and an agile one, and sometimes she mixes the two. Petra just got assigned a project team that has worked in a waterfall approach for a long time. However, they are hungry for a challenge, want to learn new things, and are generally adaptable, and the project may require a lot of changes throughout the process. Should Petra use a waterfall approach to make the team more comfortable or try something else?
  1. A Agile
  2. B Kanban
  3. C Petra should use a waterfall method
  4. D Petra should give the project to another PM
Xem giải thích

Đáp án

A — AGILE.

Vì sao đúng

⚠ Ba tín hiệu trong đề đều chỉ về agile: | Tín hiệu | Ý nghĩa | |---|---| | ⚠ Đội KHÁT KHAO THỬ THÁCH, MUỐN HỌC CÁI MỚI | ⚠ sẵn sàng về mặt con người | | ⚠ Đội DỄ THÍCH NGHI | ⚠ yếu tố then chốt cho chuyển đổi thành công | | ⚠ Dự án CÓ THỂ CÓ NHIỀU THAY ĐỔI | ⚠ đặc điểm quyết định — thay đổi nhiều thì thác nước rất đắt | | ⚠ Tổ chức CHO PHÉP Petra tự do chọn cách làm | ⚠ không có rào cản tổ chức | | ⚠ Kết luận | ⚠ cả BỐN điều kiện đều thuận — đây là trường hợp hiếm mà lựa chọn rất rõ ràng |

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

  • C (dùng thác nước cho đội thấy thoải mái) — ⚠ phương án gây nhiễu mạnh nhất vì "chăm lo cảm giác thoải mái của đội" nghe như lãnh đạo tốt: ⚠ nhưng ⚠ đề đã nói rõ đội MUỐN thử thách — ⚠ chọn thác nước là ⚠ giải quyết một vấn đề KHÔNG TỒN TẠI; ⚠ và với dự án nhiều thay đổi, thác nước là lựa chọn ⚠ tệ về mặt kỹ thuật.

  • B (Kanban) — ⚠ một phương pháp CỤ THỂ trong ô agile; ⚠ đề không mô tả đặc trưng nào của Kanban ⚠ (dòng chảy liên tục, giới hạn việc đang làm).

  • D (giao dự án cho quản lý khác) — ⚠ né tránh; ⚠ Petra thạo cả hai cách tiếp cận, ⚠ cô là người phù hợp nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26195 ở lô này (đề mô tả đặc trưng CỤ THỂ nên chọn "gia tăng" chứ không chọn ô lớn "agile") — ⚠ hai câu ngược nhau về cách chọn, rất đáng đọc cùng lúc: ⚠ #26195 có đặc trưng cụ thể → chọn cái cụ thể; câu này chỉ có ĐIỀU KIỆN chung → chọn ô lớn. ⚠ Xem thêm #26148 lô 188 (lai), #26184 ở lô này (đào tạo trước khi chuyển đổi).

⚠ Khi nào chọn agile, khi nào chọn dự đoán: | Yếu tố | Nghiêng về AGILE | Nghiêng về DỰ ĐOÁN | |---|---|---| | ⚠ Yêu cầu | ⚠ hay thay đổi, chưa rõ | ⚠ ổn định, rõ từ đầu | | ⚠ Sự tham gia của khách hàng | ⚠ thường xuyên, sẵn sàng | ⚠ ít, chỉ ở các mốc | | ⚠ Đội | ⚠ tự tổ chức, đa kỹ năng, ham học | ⚠ chuyên môn hoá, quen quy trình | | ⚠ Rủi ro và bất định | ⚠ cao | ⚠ thấp | | ⚠ Yêu cầu tuân thủ và tài liệu | ⚠ linh hoạt | ⚠ nghiêm ngặt, có quy định | | ⚠ Tình huống của Petra | ⚠ bốn trên năm yếu tố nghiêng về agile | | | ⚠ Khi các yếu tố lẫn lộn | ⚠ chọn cách tiếp cận LAI — liên hệ #26148 lô 188 |

Từ khoá nhận diện:

"đội ham học, dự án nhiều thay đổi" → ⚠ agile "đội quen thác nước, muốn cho thoải mái" → ⚠ bẫy — đề đã nói đội MUỐN thử thách "dòng chảy liên tục, giới hạn việc đang làm" → ⚠ Kanban "giao cho người khác" → ⚠ né tránh, không phải quyết định quản lý

⚠ Petra nên làm gì sau khi quyết chọn agile Bước
⚠ ĐÀO TẠO đội — họ chưa từng làm agile ⚠ liên hệ #26184 cùng lô — đừng để "kinh nghiệm tự dạy"
⚠ Bắt đầu với sprint NGẮN để học nhanh
⚠ Xác định rõ vai product owner ⚠ liên hệ #26041 lô 186
⚠ Chuẩn bị cho bên liên quan về nhịp mới ⚠ họ sẽ hỏi "bao giờ xong hết" — liên hệ #26118 lô 188
⚠ Chấp nhận vài sprint đầu chưa hiệu quả ⚠ đội đang ở giai đoạn Storming — liên hệ #26156 lô 188
⚠ Điều Petra có lợi thế ⚠ cô thạo CẢ HAI cách, nên biết lúc nào cần mượn thực hành của bên kia

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có bao nhiêu thay đổi mỗi tháng | ⚠ nhiều thì thác nước đang rất đắt | | Đội bạn muốn học cái mới hay muốn ổn định | ⚠ hỏi thẳng, đừng đoán | | Tổ chức bạn có cho phép chọn cách tiếp cận không | |

Và điều đề này nhắc khéo: cản trở lớn nhất của chuyển đổi agile thường không phải là đội — mà là giả định của người quản lý rằng đội sẽ không muốn.

Câu 483 People
Jerry wants to ensure that the level of stakeholder involvement in his project is solid at Tarth's Tarps. An excellent way to do this within an agile project is to
  1. A Escalate to the stakeholder's supervisor whenever their participation is less than expected.
  2. B Make a graph on the wall including the number of hours of stakeholder time committed per sprint.
  3. C Report it daily in standup meetings.
  4. D Include information about any benefits or issues relating to stakeholder involvement in the project and executive reports.
Xem giải thích

Đáp án

D — ĐƯA thông tin về lợi ích hoặc vấn đề liên quan tới sự tham gia của bên liên quan VÀO BÁO CÁO dự án và báo cáo cho lãnh đạo.

Vì sao đúng

⚠ Vì sao cách này hiệu quả: | Lý do | Nội dung | |---|---| | ⚠ Làm cho sự tham gia trở nên NHÌN THẤY ĐƯỢC | ⚠ thứ được báo cáo là thứ được chú ý | | ⚠ Nêu cả LỢI ÍCH lẫn VẤN ĐỀ | ⚠ không chỉ than phiền — ghi nhận cả người tham gia tốt | | ⚠ Lãnh đạo thấy TÁC ĐỘNG THẬT của việc thiếu tham gia | ⚠ "chậm ba ngày vì chưa có phê duyệt" mạnh hơn mọi lời nhắc | | ⚠ Tạo áp lực TÍCH CỰC, không đối đầu cá nhân | | | ⚠ Phù hợp với agile | ⚠ minh bạch là giá trị cốt lõi — liên hệ #26145 lô 188 |

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

  • B (vẽ biểu đồ trên tường ghi SỐ GIỜ mỗi bên liên quan cam kết mỗi sprint) — ⚠ phương án gây nhiễu mạnh nhất vì bảng thông tin trên tường ⚠ rất đúng tinh thần agile: ⚠ nhưng nó ⚠ đo SAI THỨ — ⚠ số giờ không phải chất lượng tham gia; ⚠ và ⚠ công khai bêu tên người tham gia ít là đối đầu, dễ phản tác dụng.

  • A (leo thang lên cấp trên của họ mỗi khi tham gia ít hơn kỳ vọng) — ⚠ QUÁ TAY và phá hỏng quan hệ; ⚠ leo thang là biện pháp cuối, không phải phản xạ đầu tiên.

  • C (báo cáo hằng ngày ở họp đứng) — ⚠ SAI MỤC ĐÍCH của họp đứng: ⚠ họp đứng dành cho ĐỘI phối hợp công việc ⚠ (liên hệ #26093 lô 187), ⚠ không phải nơi điểm danh bên liên quan.

Ghi nhớ về chất lượng câu hỏi

⚠ CÂU NÀY GẦN TRÙNG với câu #26217 CÙNG LÔ ⚠ (Marco — quản lý agile giữ bên liên quan gắn kết). ⚠ Hai đề khác nhân vật và khác cách diễn đạt phương án, ⚠ nhưng ⚠ hỏi cùng một điều và có CÙNG KHOÁ ĐÁP ÁN: đưa vào báo cáo — ⚠ hai khoá NHẤT QUÁN, không mâu thuẫn. ⚠ Hash MD5 không bắt được cặp này vì chữ nghĩa khác nhau; ⚠ bảng đối chiếu đầy đủ nằm ở #26217.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26170 lô 188 (gắn kết bên liên quan là yếu tố then chốt), ⚠ câu #26203 ở lô này (kế hoạch truyền thông đi kèm kế hoạch gắn kết), ⚠ câu #26185 ở lô này (ba bước phân tích), ⚠ câu #26208 ở lô này (bảng thông tin phải có mốc thời gian).

⚠ Đo mức gắn kết bên liên quan bằng gì: | Cách đo | Chất lượng | |---|---| | ⚠ SỐ GIỜ tham gia | ⚠ dễ đo nhưng ít ý nghĩa — phương án B | | ⚠ TỶ LỆ dự các buổi quan trọng | ⚠ khá hơn | | ⚠ THỜI GIAN CHỜ phê duyệt hoặc phản hồi | ⚠ đo được TÁC ĐỘNG thật lên dự án | | ⚠ Số quyết định bị TREO vì thiếu ý kiến | ⚠ thước đo mạnh nhất | | ⚠ MA TRẬN mức gắn kết: hiện tại và mong muốn | ⚠ công cụ chuẩn của PMBOK | | ⚠ Nguyên tắc | ⚠ đo TÁC ĐỘNG lên dự án, đừng đo SỰ CÓ MẶT |

Từ khoá nhận diện:

"đưa vào báo cáo dự án và báo cáo lãnh đạo" → ⚠ cách bền vững nhất "đếm số giờ, dán lên tường" → ⚠ đo sai thứ và dễ gây đối đầu "leo thang lên sếp của họ" → ⚠ biện pháp cuối cùng, không phải đầu tiên "báo cáo ở họp đứng hằng ngày" → ⚠ sai mục đích của họp đứng

⚠ Ghi vào báo cáo thế nào cho có tác dụng Cách viết
⚠ Nêu SỰ VIỆC, không nêu lời trách ⚠ "đợi phê duyệt 5 ngày" chứ không phải "phòng X chậm chạp"
⚠ Nêu HỆ QUẢ lên dự án ⚠ "đẩy lùi hai hạng mục sang sprint sau"
⚠ Nêu cả điều TỐT ⚠ "phản hồi nhanh của phòng Y giúp rút ngắn hai ngày"
⚠ Đề xuất HÀNH ĐỘNG cụ thể ⚠ "cần một người thay thế khi trưởng phòng đi công tác"
⚠ Vì sao hiệu quả ⚠ lãnh đạo can thiệp vì thấy số liệu ảnh hưởng tiến độ, không phải vì nghe than phiền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo của bạn có mục về sự tham gia của bên liên quan không | | | Bạn có ghi nhận người tham gia tốt không | ⚠ hay chỉ nêu người chậm trễ | | Có quyết định nào đang treo vì thiếu ý kiến ai không | |

Và lý do cách này hiệu quả hơn nhắc nhở riêng: một dòng trong báo cáo hằng tuần nhắc đều đặn mà không cần ai phải trách ai — và nó vẫn ở đó cho tới khi vấn đề được giải quyết.

Câu 484 Process
Holly is the project manager of the UIM Project for her company. A new change request has moved through the change control board and was approved. Now Holly needs to incorporate the change into the project to reflect the additional scope requirements. All of the following are results of approved changes except for which one?
  1. A WBS updates
  2. B Project scope updates
  3. C Project charter updates
  4. D WBS dictionary updates
Xem giải thích

Đáp án

C — Cập nhật ĐIỀU LỆ DỰ ÁN (project charter) — đây là thứ KHÔNG phải kết quả của thay đổi được duyệt.

Vì sao đúng

⚠ Vì sao điều lệ dự án không nằm trong danh sách: | Lý do | Nội dung | |---|---| | ⚠ Điều lệ do NHÀ TÀI TRỢ ban hành, không do đội dự án | | | ⚠ Điều lệ cho phép dự án TỒN TẠI và trao quyền cho quản lý dự án | | | ⚠ Nó ở TẦNG CAO — mục đích, mục tiêu ở mức tổng quan | | | ⚠ Một thay đổi phạm vi thông thường KHÔNG chạm tới tầng đó | ⚠ đây là mấu chốt | | ⚠ Khi nào điều lệ mới đổi | ⚠ khi chính MỤC ĐÍCH hoặc BIỆN MINH của dự án thay đổi — hiếm, và do nhà tài trợ quyết |

Vì sao các phương án khác sai — ba phương án còn lại ĐỀU là kết quả đúng

  • A (cập nhật WBS) — ⚠ ĐÚNG là kết quả: ⚠ thêm phạm vi thì phải thêm gói công việc.
  • B (cập nhật phạm vi dự án) — ⚠ ĐÚNG là kết quả: ⚠ đề nói rõ có thêm yêu cầu phạm vi.
  • D (cập nhật từ điển WBS) — ⚠ ĐÚNG là kết quả: ⚠ mỗi gói công việc mới cần mô tả chi tiết trong từ điển.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26023 lô 185 (đổi đường cơ sở phải qua kiểm soát thay đổi), ⚠ câu #26101 lô 187 (quy trình kiểm soát thay đổi), ⚠ câu #26180 lô 188 (duy trì và phê duyệt đường cơ sở phạm vi), ⚠ câu #26194 ở lô này (cắt phạm vi phải trình yêu cầu thay đổi).

⚠ Thay đổi phạm vi được duyệt kéo theo cập nhật những gì: | Tài liệu | Cập nhật gì | |---|---| | ⚠ MÔ TẢ PHẠM VI | ⚠ thêm bàn giao, sửa tiêu chí nghiệm thu | | ⚠ WBS | ⚠ thêm gói công việc | | ⚠ TỪ ĐIỂN WBS | ⚠ mô tả chi tiết gói mới | | ⚠ ĐƯỜNG CƠ SỞ PHẠM VI | ⚠ ba tài liệu trên hợp thành đường cơ sở này | | ⚠ LỊCH TRÌNH và NGÂN SÁCH | ⚠ việc thêm thì tốn thời gian và tiền | | ⚠ MA TRẬN TRUY VẾT YÊU CẦU | ⚠ liên hệ #26095 lô 187 | | ⚠ SỔ RỦI RO | ⚠ phạm vi mới sinh rủi ro mới | | ⚠ Nhưng KHÔNG cập nhật | ⚠ ĐIỀU LỆ DỰ ÁN — trừ khi mục đích dự án thay đổi |

Từ khoá nhận diện:

"kết quả của thay đổi được duyệt" → ⚠ phạm vi, WBS, từ điển WBS, lịch, ngân sách "điều lệ dự án" → ⚠ KHÔNG đổi theo thay đổi thông thường "do nhà tài trợ ban hành" → ⚠ dấu hiệu của điều lệ "đổi đường cơ sở" → ⚠ phải có phê duyệt chính thức

⚠ Ba tầng tài liệu — tầng nào đổi dễ, tầng nào đổi khó Tầng
⚠ TẦNG TỔ CHỨC: điều lệ, tình huống kinh doanh ⚠ đổi rất hiếm, do nhà tài trợ và lãnh đạo
⚠ TẦNG KẾ HOẠCH: các kế hoạch phụ và đường cơ sở ⚠ đổi qua kiểm soát thay đổi chính thức
⚠ TẦNG TÀI LIỆU DỰ ÁN: sổ rủi ro, sổ vấn đề, nhật ký ⚠ cập nhật thường xuyên, không cần phê duyệt
⚠ Mẹo làm bài ⚠ thấy phương án nhắc điều lệ trong danh sách "kết quả của thay đổi" thì gần như chắc chắn đó là đáp án của câu hỏi phủ định
⚠ Ngoại lệ duy nhất ⚠ thay đổi lớn tới mức đổi mục tiêu dự án — khi đó thường là dự án MỚI, không phải sửa điều lệ cũ
⚠ Holly cần làm gì sau khi thay đổi được duyệt Bước
⚠ Cập nhật đường cơ sở phạm vi (mô tả + WBS + từ điển)
⚠ Đánh giá tác động lên lịch và chi phí
⚠ Cập nhật sổ rủi ro
⚠ THÔNG BÁO cho đội và bên liên quan ⚠ bước hay bị quên nhất — liên hệ #26203 cùng lô
⚠ Ghi vào NHẬT KÝ THAY ĐỔI ⚠ để về sau truy được vì sao phạm vi khác lúc đầu
⚠ Lưu ý ⚠ thay đổi được duyệt là ĐẦU VÀO của Chỉ đạo và Quản lý công việc dự án — nó phải được THỰC HIỆN, không chỉ được ghi nhận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thay đổi gần nhất của bạn đã cập nhật đủ tài liệu chưa | | | Điều lệ dự án của bạn có bị sửa lặt vặt không | ⚠ nếu có thì có gì đó sai trong quy trình | | Đội bạn có biết phạm vi đã thay đổi không | ⚠ duyệt xong mà không báo thì thay đổi chỉ nằm trên giấy |

Và điều dễ quên nhất trong quản lý thay đổi: được phê duyệt mới là nửa đầu — nửa sau là cập nhật đủ tài liệu và báo cho đủ người, và chính nửa sau mới quyết định thay đổi đó có thật sự xảy ra hay không.

Câu 485 Business Environment
Benefits realization management is marked by a process where benefits are identified, defined, linked to company strategy, delivered, and wholly realized. Benefits Realization Management is not a specific process with steps, and the roles and responsibilities can change from organization to organization. In other words, there is no one right way to do it. When a company implements a process of Benefits Realization Management, what are two hallmarks of this?
  1. A Value-driven culture and clear accountability
  2. B Cost-benefit analysis and Value-driven culture
  3. C Support by project sponsor and responsibility
  4. D Clear accountability and responsibility
Xem giải thích

Đáp án

A — VĂN HOÁ HƯỚNG GIÁ TRỊ và TRÁCH NHIỆM GIẢI TRÌNH RÕ RÀNG.

Vì sao đúng

⚠ Hai dấu hiệu, mỗi cái giải một vấn đề: | Dấu hiệu | Giải quyết vấn đề gì | |---|---| | ⚠ VĂN HOÁ HƯỚNG GIÁ TRỊ | ⚠ cả tổ chức hỏi "việc này mang lại giá trị gì" chứ không chỉ hỏi "đã xong chưa" | | ⚠ Nó biến lợi ích thành thứ mọi người quan tâm | ⚠ không chỉ là mục trong báo cáo | | ⚠ TRÁCH NHIỆM GIẢI TRÌNH RÕ RÀNG | ⚠ có TÊN NGƯỜI chịu trách nhiệm cho từng lợi ích | | ⚠ Lợi ích thường hiện ra SAU khi dự án đóng | ⚠ không có chủ thì không ai theo dõi tiếp | | ⚠ Vì sao cần CẢ HAI | ⚠ văn hoá không có người chịu trách nhiệm thì chỉ là khẩu hiệu; người chịu trách nhiệm trong văn hoá chỉ đếm việc thì không ai giúp |

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

  • D (trách nhiệm giải trình rõ ràng và trách nhiệm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ một nửa đúng: ⚠ nhưng ⚠ "trách nhiệm giải trình" (accountability) và "trách nhiệm" (responsibility) gần như CÙNG MỘT Ý ⚠ trong ngữ cảnh này — ⚠ nêu hai lần một điều thì thiếu mất vế văn hoá.

  • B (phân tích lợi ích – chi phí và văn hoá hướng giá trị) — ⚠ phân tích lợi ích – chi phí là CÔNG CỤ ở giai đoạn CHỌN dự án, ⚠ không phải dấu hiệu của quản lý hiện thực hoá lợi ích.

  • C (nhà tài trợ ủng hộ và trách nhiệm) — ⚠ ủng hộ của nhà tài trợ cần cho mọi dự án, ⚠ không đặc trưng cho quản lý lợi ích.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26200 ở lô này (nhu cầu kinh doanh là yếu tố chọn dự án quan trọng nhất), ⚠ câu #26189 ở lô này (giá trị đo được trong IPD), ⚠ câu #26171 lô 188 (phân tích giá trị), ⚠ câu #25907 lô 183 (điểm hoà vốn).

⚠ Vòng đời quản lý hiện thực hoá lợi ích: | Bước | Việc | Ai chịu trách nhiệm | |---|---|---| | ⚠ 1. NHẬN DIỆN lợi ích | ⚠ trước khi phê duyệt dự án | ⚠ nhà tài trợ và chủ sở hữu kinh doanh | | ⚠ 2. ĐỊNH NGHĨA — đo bằng gì, đến khi nào | ⚠ kế hoạch quản lý lợi ích | | | ⚠ 3. GẮN với chiến lược công ty | ⚠ lợi ích không gắn chiến lược thì dễ bị cắt | | | ⚠ 4. GIAO — dự án tạo ra năng lực | ⚠ đây là phần quản lý dự án lo | ⚠ quản lý dự án | | ⚠ 5. HIỆN THỰC HOÁ — lợi ích thật sự xuất hiện | ⚠ thường SAU khi dự án đóng | ⚠ chủ sở hữu kinh doanh | | ⚠ Chỗ đứt gãy phổ biến nhất | ⚠ giữa bước 4 và bước 5 — dự án đóng, mọi người giải tán, không ai đo xem lợi ích có tới không |

Từ khoá nhận diện:

"hai dấu hiệu của quản lý hiện thực hoá lợi ích" → ⚠ văn hoá hướng giá trị + trách nhiệm giải trình rõ ràng "phân tích lợi ích – chi phí" → ⚠ công cụ CHỌN dự án "trách nhiệm giải trình + trách nhiệm" → ⚠ nói hai lần một ý "nhà tài trợ ủng hộ" → ⚠ cần cho mọi dự án, không đặc trưng

⚠ Vì sao "văn hoá hướng giá trị" khó xây nhất Lý do
⚠ Đo "đã xong" dễ hơn nhiều so với đo "có giá trị"
⚠ Giá trị xuất hiện muộn, thường sau khi mọi người đã chuyển sang việc khác
⚠ Thừa nhận một dự án không mang lại giá trị là điều khó nói
⚠ Hệ thống khen thưởng thường gắn với BÀN GIAO chứ không gắn với KẾT QUẢ ⚠ gốc rễ của vấn đề
⚠ Dấu hiệu tổ chức có văn hoá này ⚠ họ dám DỪNG một dự án khi lợi ích kỳ vọng không còn — liên hệ #26200 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án gần nhất của bạn có ai theo dõi lợi ích sau khi đóng không | | | Lợi ích kỳ vọng có ghi con số và mốc thời gian không | | | Tổ chức bạn khen thưởng theo bàn giao hay theo kết quả kinh doanh | |

Và câu hỏi phân biệt một tổ chức thật sự quản lý lợi ích: sáu tháng sau khi dự án đóng, có ai còn kiểm tra xem lợi ích đã hứa có tới hay không — và có ai phải trả lời câu hỏi đó không.

Câu 486 Process
Xavier is the scrum master for Project X, which has entered its fifth iteration and has a velocity of 25 story points. Xavier has received reports that some stakeholders are viewing outdated information on various information radiators and have become confused about Project X's status. What should Xavier do to correct this problem?
  1. A Have a developer meet the stakeholders and investigate what is going on.
  2. B Email updates every day.
  3. C Have one information radiator with a timestamp of when the information is updated.
  4. D Print hard copies of the information radiators every day and deliver them to stakeholders.
Xem giải thích

Đáp án

C — Dùng MỘT bảng thông tin DUY NHẤT có DẤU THỜI GIAN ghi rõ thông tin được cập nhật lúc nào.

Vì sao đúng

⚠ Giải pháp gồm hai phần, cả hai đều cần: | Phần | Giải quyết vấn đề gì | |---|---| | ⚠ MỘT bảng duy nhất | ⚠ loại bỏ tình trạng nhiều bảng mâu thuẫn nhau | | ⚠ Đề bài ghi rõ "NHIỀU bảng thông tin" | ⚠ đây là gốc rễ của sự nhầm lẫn | | ⚠ Có DẤU THỜI GIAN | ⚠ ai xem cũng biết ngay dữ liệu cũ hay mới | | ⚠ Bên liên quan tự đánh giá được độ tin cậy | ⚠ không cần hỏi ai | | ⚠ Nguyên tắc nền | ⚠ MỘT NGUỒN SỰ THẬT DUY NHẤT (single source of truth) |

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

  • B (gửi email cập nhật mỗi ngày) — ⚠ phương án gây nhiễu mạnh nhất vì nó ⚠ có vẻ giải quyết được vấn đề thông tin cũ: ⚠ nhưng nó ⚠ KHÔNG gỡ gốc rễ — ⚠ các bảng cũ vẫn treo đó và vẫn sai; ⚠ và nó ⚠ TẠO THÊM một nguồn thông tin thứ n, ⚠ đi ngược tinh thần bảng thông tin agile ⚠ (thông tin tự toả ra, không cần đẩy).

  • D (in bản cứng mỗi ngày mang tới cho bên liên quan) — ⚠ tốn công, và bản in LẬP TỨC lỗi thời — ⚠ đúng cái vấn đề đang gặp.

  • A (cử một lập trình viên đi tìm hiểu chuyện gì xảy ra) — ⚠ lãng phí người; ⚠ và Xavier ĐÃ BIẾT nguyên nhân: ⚠ nhiều bảng, thông tin cũ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26205 ở lô này (đưa vấn đề gắn kết vào báo cáo), ⚠ câu #26203 ở lô này (kế hoạch truyền thông), ⚠ câu #26192 ở lô này (NHIỄU trong mô hình truyền thông — nhiều nguồn mâu thuẫn chính là nhiễu), ⚠ câu #26158 lô 188 (bảng Kanban).

⚠ Bảng thông tin (information radiator) là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Hiển thị lớn, đặt ở nơi ai cũng thấy | ⚠ thông tin TOẢ RA, không cần ai hỏi | | ⚠ Cập nhật thường xuyên, tốt nhất là tự động | | | ⚠ Đơn giản, đọc hiểu trong vài giây | | | ⚠ Ví dụ: biểu đồ burndown, bảng Kanban, tốc độ, chất lượng build | | | ⚠ Nguyên tắc vàng | ⚠ thà MỘT bảng đúng còn hơn NĂM bảng đẹp mà mâu thuẫn nhau | | ⚠ Vì sao dấu thời gian quan trọng | ⚠ thông tin không có mốc thời gian thì không thể đánh giá độ tin cậy — người xem buộc phải TIN hoặc BỎ QUA |

Từ khoá nhận diện:

"nhiều bảng, thông tin cũ, gây nhầm lẫn" → ⚠ một bảng duy nhất có dấu thời gian "gửi email hằng ngày" → ⚠ thêm nguồn thứ n, không gỡ gốc "in bản cứng" → ⚠ lỗi thời ngay khi in xong "cử người đi tìm hiểu" → ⚠ đã biết nguyên nhân rồi

⚠ Vì sao NHIỀU NGUỒN THÔNG TIN nguy hiểm hơn ÍT THÔNG TIN Lý do
⚠ Bên liên quan không biết tin cái nào
⚠ Mỗi người ra quyết định dựa trên một phiên bản khác nhau ⚠ hậu quả nặng nhất
⚠ Mất niềm tin vào TOÀN BỘ thông tin dự án ⚠ kể cả bảng đúng cũng bị nghi ngờ
⚠ Tốn thời gian đối chiếu và giải thích
⚠ Trong tình huống của Xavier ⚠ dự án đang ở vòng lặp thứ năm với tốc độ 25 điểm — dự án chạy tốt, vấn đề nằm HOÀN TOÀN ở truyền thông
⚠ Xavier nên làm gì cụ thể Việc
⚠ GỠ BỎ hoặc gộp các bảng cũ ⚠ quan trọng nhất — để bảng sai treo đó là để nó tiếp tục gây hại
⚠ Chọn MỘT bảng chính thức
⚠ Thêm dấu thời gian tự động nếu có thể ⚠ tự động thì không quên cập nhật
⚠ Báo cho bên liên quan chỗ xem duy nhất
⚠ Giao trách nhiệm cập nhật cho một người cụ thể ⚠ liên hệ #26179 lô 188 — không có chủ thì không ai làm
⚠ Sau đó ⚠ kiểm lại sau vài sprint xem bên liên quan còn nhầm lẫn không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có bao nhiêu nơi hiển thị trạng thái | ⚠ nhiều hơn một là đã có rủi ro mâu thuẫn | | Các bảng đó có dấu thời gian không | | | Ai chịu trách nhiệm cập nhật từng bảng | ⚠ không trả lời được thì bảng đó sẽ cũ dần |

Và bài học chung của câu này: một bảng thông tin lỗi thời không phải là thông tin trung tính — nó là thông tin SAI, và nó gây hại nhiều hơn việc không có bảng nào cả.

Câu 487 Process
Sharon, a project manager, investigates the deliverable process and would like to determine the output quality. She is looking for bottlenecks in the delivery process as she suspects the process duration is random and unreliable. Which tool will best serve Sharon to identify whether the process is under control or not?
  1. A Pareto chart
  2. B Run chart
  3. C Control chart
  4. D Ishikawa diagram
Xem giải thích

Đáp án

C — BIỂU ĐỒ KIỂM SOÁT (control chart).

Vì sao đúng

⚠ Biểu đồ kiểm soát làm gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Vẽ dữ liệu theo thời gian kèm GIỚI HẠN KIỂM SOÁT trên và dưới | | | ⚠ Trả lời đúng câu hỏi: quy trình có ỔN ĐỊNH không | ⚠ đúng điều Sharon cần | | ⚠ Phân biệt BIẾN THIÊN THÔNG THƯỜNG và BIẾN THIÊN ĐẶC BIỆT | ⚠ mấu chốt | | ⚠ Sharon nghi thời lượng quy trình NGẪU NHIÊN và KHÔNG ĐÁNG TIN | ⚠ đây chính là câu hỏi về tính ổn định | | ⚠ Kết luận từ biểu đồ | ⚠ điểm nằm ngoài giới hạn = quy trình MẤT kiểm soát, cần tìm nguyên nhân đặc biệt |

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

  • B (biểu đồ chuỗi — run chart) — ⚠ phương án gây nhiễu mạnh nhất vì nó ⚠ cũng vẽ dữ liệu theo thời gian và cũng thấy xu hướng: ⚠ nhưng nó ⚠ KHÔNG CÓ GIỚI HẠN KIỂM SOÁT ⚠ — nên nó cho thấy dữ liệu ⚠ thay đổi thế nào, ⚠ không trả lời được "có trong tầm kiểm soát hay không"; ⚠ đây đúng là câu hỏi Sharon đặt ra.

  • A (biểu đồ Pareto) — ⚠ xếp hạng nguyên nhân theo tần suất, ⚠ trả lời "vấn đề nào nhiều nhất", ⚠ không trả lời "ổn định hay không".

  • D (biểu đồ Ishikawa / xương cá) — ⚠ tìm NGUYÊN NHÂN GỐC, ⚠ dùng SAU khi đã biết có vấn đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26103 lô 187 (biểu đồ xương cá tìm nguyên nhân gốc), ⚠ câu #26013 lô 185 và #25626 lô 177 ("xương cá" và "Ishikawa" bị liệt kê thành HAI phương án dù là MỘT công cụ — lỗi đề đã ghi nhận hai lần), ⚠ câu #26150 lô 188 (chi phí lỗi bên ngoài), ⚠ câu #26142 lô 188 (mục tiêu chất lượng).

⚠ BẢY công cụ chất lượng cơ bản — dùng cái nào khi nào: | Công cụ | Trả lời câu hỏi gì | |---|---| | ⚠ BIỂU ĐỒ KIỂM SOÁT | ⚠ quy trình có ổn định không — CÂU NÀY | | ⚠ BIỂU ĐỒ CHUỖI | ⚠ dữ liệu thay đổi thế nào theo thời gian | | ⚠ PARETO | ⚠ vấn đề nào chiếm phần lớn — quy tắc 80/20 | | ⚠ XƯƠNG CÁ (Ishikawa) | ⚠ nguyên nhân gốc là gì | | ⚠ HISTOGRAM | ⚠ dữ liệu phân bố ra sao | | ⚠ BIỂU ĐỒ PHÂN TÁN | ⚠ hai biến có liên hệ không | | ⚠ PHIẾU KIỂM TRA | ⚠ thu thập dữ liệu có cấu trúc | | ⚠ LƯU ĐỒ | ⚠ quy trình chạy thế nào, nút thắt ở đâu | | ⚠ Trình tự dùng thường gặp | ⚠ phiếu kiểm tra thu số liệu → biểu đồ kiểm soát thấy bất ổn → Pareto khoanh vùng → xương cá tìm gốc |

Từ khoá nhận diện:

"có trong tầm kiểm soát không, ổn định không" → ⚠ biểu đồ kiểm soát "xu hướng theo thời gian, không có giới hạn" → ⚠ biểu đồ chuỗi "vấn đề nào chiếm đa số" → ⚠ Pareto "vì sao xảy ra" → ⚠ xương cá

⚠ Đọc biểu đồ kiểm soát — bốn dấu hiệu mất kiểm soát Dấu hiệu
⚠ Một điểm NGOÀI giới hạn kiểm soát ⚠ rõ ràng nhất
⚠ BẢY điểm liên tiếp cùng một phía đường trung tâm ⚠ quy tắc bảy — có xu hướng lệch
⚠ Bảy điểm liên tiếp tăng hoặc giảm đều
⚠ Mẫu hình có chu kỳ lặp lại
⚠ Phân biệt hai loại nguyên nhân ⚠ THÔNG THƯỜNG là bản chất quy trình, muốn giảm phải ĐỔI quy trình; ĐẶC BIỆT là sự cố, tìm và loại bỏ được
⚠ Sai lầm phổ biến ⚠ can thiệp vào biến thiên thông thường — càng chỉnh càng loạn, gọi là "nghịch quy trình"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đo thời lượng quy trình theo thời gian không | ⚠ không có dữ liệu thì không vẽ được gì | | Bạn phân biệt được biến thiên thông thường và đặc biệt không | | | Bạn có đang chỉnh quy trình sau mỗi lần lệch nhỏ không | ⚠ đó là nghịch quy trình |

Và điều biểu đồ kiểm soát dạy rõ nhất: không phải mọi biến động đều là vấn đề — và can thiệp vào biến động bình thường sẽ làm quy trình tệ hơn, chứ không tốt hơn.

Câu 488 Process
Edward is working on the construction of a ship for a major cruise company. The ship's overall frame has been constructed, and Edward has been authorized to have the ventilation, electrical, pneumatic, and hydraulic systems installed at the same time. Although some system components are dependent on other systems to be placed into commission, Edward is confident that he can have each contractor install their respective hardware components simultaneously. What kind of relationship describes the scenario above?
  1. A Overlapping relationship
  2. B Project dependency relationship
  3. C Phase gate relationship
  4. D Sequential relationship
Xem giải thích

Đáp án

A — QUAN HỆ CHỒNG LẤN (overlapping relationship).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Khung tàu ĐÃ dựng xong | ⚠ giai đoạn trước đã hoàn tất | | ⚠ Thông gió, điện, khí nén, thuỷ lực lắp CÙNG LÚC | ⚠ các hạng mục chạy SONG SONG | | ⚠ MỘT SỐ bộ phận PHỤ THUỘC hệ thống khác mới vận hành được | ⚠ có phụ thuộc nhưng không chặn hoàn toàn | | ⚠ Vẫn cho các nhà thầu lắp đồng thời | ⚠ chấp nhận chồng lấn để rút ngắn lịch | | ⚠ Định nghĩa | ⚠ quan hệ chồng lấn: giai đoạn sau BẮT ĐẦU trước khi giai đoạn trước KẾT THÚC |

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

  • D (quan hệ tuần tự — sequential) — ⚠ phương án gây nhiễu mạnh nhất vì nó là ⚠ cặp đối lập trực tiếp và cũng là quan hệ giữa các giai đoạn: ⚠ nhưng tuần tự nghĩa là ⚠ giai đoạn sau chỉ bắt đầu KHI giai đoạn trước ĐÃ XONG HẲN; ⚠ đề nói rõ các hệ thống lắp ⚠ ĐỒNG THỜI — ⚠ trái ngược.

  • C (quan hệ cổng giai đoạn) — ⚠ cổng giai đoạn là ĐIỂM RÀ SOÁT giữa hai giai đoạn ⚠ (liên hệ #26114 lô 187), ⚠ không phải một loại quan hệ.

  • B (quan hệ phụ thuộc dự án) — ⚠ KHÔNG phải thuật ngữ chuẩn cho quan hệ GIAI ĐOẠN; ⚠ phụ thuộc là quan hệ giữa các HOẠT ĐỘNG.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26114 lô 187 (cổng giai đoạn), ⚠ câu #26155 lô 188 (giai đoạn dự án), ⚠ câu #26051 lô 186 (độ trễ trong quan hệ phụ thuộc), ⚠ câu #26198 ở lô này (đường găng khi có nhiều phụ thuộc).

⚠ BA quan hệ giữa các giai đoạn dự án: | Quan hệ | Đặc điểm | Đánh đổi | |---|---|---| | ⚠ TUẦN TỰ (sequential) | ⚠ xong hẳn giai đoạn trước mới sang giai đoạn sau | ⚠ an toàn nhất, CHẬM nhất | | ⚠ CHỒNG LẤN (overlapping) | ⚠ giai đoạn sau bắt đầu khi giai đoạn trước chưa xong | ⚠ NHANH hơn, RỦI RO cao hơn — CÂU NÀY | | ⚠ LẶP (iterative) | ⚠ chỉ lập kế hoạch chi tiết cho giai đoạn kế tiếp | ⚠ linh hoạt nhất, khó dự báo tổng thể nhất | | ⚠ Chồng lấn còn có tên khác | ⚠ THEO DÕI NHANH (fast tracking) khi áp dụng cho hoạt động — liên hệ #26194 cùng lô | | ⚠ Rủi ro chính của chồng lấn | ⚠ PHẢI LÀM LẠI nếu giai đoạn trước có thay đổi ảnh hưởng phần đã làm song song |

Từ khoá nhận diện:

"làm đồng thời dù có phụ thuộc" → ⚠ quan hệ chồng lấn "xong hẳn mới sang bước sau" → ⚠ tuần tự "điểm rà soát để quyết đi tiếp hay dừng" → ⚠ cổng giai đoạn "lập kế hoạch chi tiết dần theo từng vòng" → ⚠ lặp

⚠ Vì sao Edward dám chồng lấn Điều kiện cho phép
⚠ Khung tàu đã dựng xong — nền tảng đã ỔN ĐỊNH ⚠ điều kiện quan trọng nhất
⚠ Bốn hệ thống chạy ở các khu vực khác nhau của tàu ⚠ ít va chạm không gian
⚠ Phụ thuộc chỉ ở khâu VẬN HÀNH, không ở khâu LẮP ĐẶT ⚠ chi tiết mấu chốt trong đề
⚠ Bốn nhà thầu khác nhau — không tranh nhau nhân lực
⚠ Nếu thiếu một điều kiện ⚠ chồng lấn sẽ sinh xung đột hiện trường và phải tháo ra làm lại
⚠ Chồng lấn cần quản lý thêm những gì Việc thêm
⚠ ĐIỀU PHỐI chặt giữa các nhà thầu ⚠ họp phối hợp thường xuyên hơn
⚠ Quản lý GIAO DIỆN giữa các hệ thống ⚠ chỗ hai hệ thống gặp nhau là chỗ hay sai nhất
⚠ Chuẩn bị cho việc LÀM LẠI một phần ⚠ dự trù chi phí và thời gian
⚠ Kiểm soát thay đổi chặt hơn ⚠ một thay đổi lan ra bốn nhà thầu
⚠ Kết luận ⚠ chồng lấn mua thời gian bằng cách trả thêm công điều phối và rủi ro — biết mình mua gì bằng gì là đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các giai đoạn dự án bạn có chồng lấn không, và có chủ đích không | | | Chỗ giao diện giữa các phần song song đã có ai quản lý chưa | | | Bạn có dự trù cho việc phải làm lại không | |

Và điều làm nên khác biệt giữa chồng lấn có tính toán và chồng lấn liều lĩnh: Edward chồng lấn vì phần nền đã xong và phụ thuộc chỉ nằm ở khâu vận hành — không phải vì lịch đang trễ.

Câu 489 Process
Timothy is the scrum master for Project Elephant, in its sixth iteration, has a velocity of ninety-three story points, and is over budget by $5,000. During a recent retrospective, the team realized that several tasks they had worked on did not seem to provide any value for Project Elephant. What should Timothy do with this information?
  1. A Raise the issue at the next sprint review.
  2. B Do nothing. The product owner prioritized them.
  3. C Have the project team ignore similar tasks going forward.
  4. D Speak with the product owner about the issue.
Xem giải thích

Đáp án

D — NÓI CHUYỆN VỚI PRODUCT OWNER về vấn đề này.

Vì sao đúng

⚠ Vì sao product owner là người phải nghe: | Lý do | Nội dung | |---|---| | ⚠ PRODUCT OWNER là người XẾP ƯU TIÊN backlog | ⚠ liên hệ #26041 lô 186 | | ⚠ Việc không tạo giá trị lọt vào sprint = vấn đề của backlog | ⚠ đúng địa chỉ | | ⚠ Scrum Master GỠ VẬT CẢN, và đây là một vật cản | ⚠ liên hệ #26179 lô 188 | | ⚠ Dự án đang VƯỢT CHI 5.000 đô | ⚠ làm việc vô ích khiến vượt chi nặng thêm | | ⚠ Đội đã phát hiện đúng chỗ | ⚠ buổi nhìn lại là nơi để nêu, nhưng GIẢI QUYẾT phải qua product owner |

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

  • A (nêu ở buổi rà soát sprint tiếp theo) — ⚠ phương án gây nhiễu mạnh nhất vì buổi rà soát ⚠ có mặt product owner và bên liên quan: ⚠ nhưng ⚠ CHỜ tới buổi sau là mất thêm một sprint làm việc vô ích; ⚠ và ⚠ buổi rà soát dành cho DEMO sản phẩm và phản hồi, ⚠ không phải nơi bàn lại tiêu chí ưu tiên.

  • B (không làm gì vì product owner đã xếp ưu tiên) — ⚠ product owner CÓ THỂ SAI; ⚠ và im lặng đi ngược tinh thần cải tiến liên tục.

  • C (bảo đội bỏ qua các việc tương tự trong tương lai) — ⚠ NGUY HIỂM: ⚠ đội ⚠ KHÔNG được tự ý bỏ việc trong backlog ⚠ — đó là quyền của product owner.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26041 lô 186 (product owner quyết backlog), ⚠ câu #26145 lô 188 (chia sẻ minh bạch ở buổi nhìn lại), ⚠ câu #26149 lô 188 (xếp ưu tiên tương đối), ⚠ câu #26171 lô 188 (phân tích giá trị), ⚠ câu #26179 lô 188 (vật cản phải có người phụ trách).

⚠ Bốn sự kiện scrum — bàn chuyện này ở đâu: | Sự kiện | Mục đích | Có phải chỗ này không | |---|---|---| | ⚠ HỌP KẾ HOẠCH SPRINT | ⚠ chọn việc cho sprint tới | ⚠ chỗ NGĂN vấn đề tái diễn | | ⚠ HỌP ĐỨNG HẰNG NGÀY | ⚠ đội phối hợp công việc trong ngày | ⚠ không | | ⚠ RÀ SOÁT SPRINT | ⚠ demo sản phẩm, lấy phản hồi bên liên quan | ⚠ không phải chỗ chính | | ⚠ NHÌN LẠI (retrospective) | ⚠ cải tiến CÁCH LÀM VIỆC | ⚠ chỗ PHÁT HIỆN — đội đã làm đúng | | ⚠ Nhưng phát hiện xong thì | ⚠ phải HÀNH ĐỘNG — nói với product owner NGAY, không chờ sự kiện tiếp theo | | ⚠ Nguyên tắc | ⚠ buổi nhìn lại sinh ra HÀNH ĐỘNG, không phải sinh ra danh sách để đó |

Từ khoá nhận diện:

"việc không tạo giá trị" → ⚠ nói với product owner ngay "chờ buổi rà soát sprint" → ⚠ chậm mất một sprint "product owner đã quyết rồi nên thôi" → ⚠ product owner cũng sai được "đội tự bỏ qua việc" → ⚠ vượt quyền, rất nguy hiểm

⚠ Timothy nên nói gì với product owner Nội dung
⚠ Nêu CỤ THỂ việc nào, tốn bao nhiêu điểm ⚠ có số liệu thì thuyết phục hơn
⚠ Hỏi mục tiêu giá trị của những việc đó ⚠ có thể product owner có lý do đội chưa biết
⚠ Đề nghị làm rõ TIÊU CHÍ ƯU TIÊN cho các sprint sau
⚠ Gắn với con số vượt chi 5.000 đô ⚠ cho thấy tác động thật
⚠ Giọng điệu ⚠ HỎI chứ không TRÁCH — đội có thể chưa hiểu hết bối cảnh kinh doanh
⚠ Nếu product owner có lý do chính đáng ⚠ thì vấn đề là TRUYỀN THÔNG: đội cần biết vì sao việc đó có giá trị
⚠ Hai khả năng đằng sau tình huống này Khả năng
⚠ Việc THẬT SỰ không có giá trị ⚠ product owner cần chỉnh cách xếp ưu tiên
⚠ Việc CÓ giá trị nhưng đội không thấy ⚠ product owner cần giải thích bối cảnh rõ hơn
⚠ Cả hai đều cần ⚠ một cuộc trò chuyện — đó là lý do đáp án là "nói chuyện", không phải "sửa" hay "bỏ qua"
⚠ Bài học chung ⚠ đội hiểu VÌ SAO làm một việc thì làm tốt hơn hẳn đội chỉ biết PHẢI làm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có biết vì sao mỗi hạng mục được ưu tiên không | | | Buổi nhìn lại gần nhất sinh ra hành động nào chưa | | | Có bao nhiêu phần trăm công sức sprint trước tạo ra giá trị thấy được | |

Và điều câu này nhắc rõ nhất: phát hiện ra vấn đề ở buổi nhìn lại là nửa việc — nửa còn lại là mang nó tới đúng người, ngay hôm đó.

Câu 490 People
Bernie’s agile team has a decision to make. It is decided that they will use the thumbs up/down/sideways decision model. It’s understandable what the thumbs up and down mean but what does the thumb sideways mean?
  1. A A thumb sideways means a team member does not have enough information to vote.
  2. B A thumb sideways means a team member has a question that needs to be further discussed.
  3. C A thumb sideways means a team member is unable to make a decision.
  4. D A thumb sideways means a team member does not care either way.
Xem giải thích

Đáp án

B — Ngón cái NGANG nghĩa là thành viên đó CÓ CÂU HỎI cần bàn thêm.

Vì sao đúng

⚠ Mô hình ba trạng thái ngón cái: | Trạng thái | Ý nghĩa | |---|---| | ⚠ NGÓN CÁI LÊN | ⚠ ủng hộ, đồng ý tiến hành | | ⚠ NGÓN CÁI XUỐNG | ⚠ phản đối, không đồng ý | | ⚠ NGÓN CÁI NGANG | ⚠ CÓ CÂU HỎI hoặc băn khoăn cần thảo luận thêm | | ⚠ Ngang KHÔNG phải "trung lập" hay "sao cũng được" | ⚠ đây là điểm bị hiểu sai nhiều nhất | | ⚠ Vì sao thiết kế như vậy | ⚠ để người còn băn khoăn có cách nói ra mà KHÔNG phải phản đối hẳn |

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

  • A (không đủ thông tin để bỏ phiếu) — ⚠ phương án gây nhiễu mạnh nhất vì rất gần với đáp án: ⚠ thiếu thông tin quả thật là một lý do giơ ngang; ⚠ nhưng nó ⚠ HẸP HƠN — ⚠ ngón cái ngang bao gồm ⚠ mọi loại băn khoăn cần bàn thêm, ⚠ không chỉ chuyện thiếu thông tin.

  • C (không thể ra quyết định) — ⚠ mô tả trạng thái BẾ TẮC; ⚠ ngón cái ngang là ⚠ hành động CHỦ ĐỘNG mời thảo luận, ⚠ không phải sự bất lực.

  • D (không quan tâm thế nào cũng được) — ⚠ SAI HOÀN TOÀN: ⚠ thờ ơ khác hẳn có băn khoăn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26149 lô 188 (xếp ưu tiên tương đối), ⚠ câu #26197 ở lô này (phong cách hợp tác), ⚠ câu #26145 lô 188 (minh bạch ở buổi nhìn lại), ⚠ câu #26211 ở lô này (nói ra vấn đề với đúng người).

⚠ Vì sao mô hình ba ngón cái hữu ích: | Ưu điểm | Nội dung | |---|---| | ⚠ NHANH — thấy ngay lập trường cả đội trong ba giây | | | ⚠ TRỰC QUAN — ai cũng hiểu, không cần giải thích | | | ⚠ Có chỗ cho sự CHƯA CHẮC CHẮN | ⚠ biểu quyết hai trạng thái ép người ta chọn bừa | | ⚠ Ngón cái ngang MỜI thảo luận thay vì chặn quyết định | ⚠ giá trị lớn nhất | | ⚠ Điều cần nhớ về ngón cái ngang | ⚠ nó KHÔNG chặn quyết định — nó chỉ nói "hãy nói thêm một chút trước khi chốt" |

Từ khoá nhận diện:

"ngón cái ngang" → ⚠ có câu hỏi cần bàn thêm "trung lập, sao cũng được" → ⚠ hiểu sai phổ biến nhất "không đủ thông tin" → ⚠ một trường hợp, không phải toàn bộ ý nghĩa "bế tắc, không quyết được" → ⚠ không phải tinh thần của mô hình này

⚠ Các kỹ thuật ra quyết định nhóm trong agile Kỹ thuật
⚠ BA NGÓN CÁI ⚠ nhanh, xem lập trường — CÂU NÀY
⚠ NĂM NGÓN TAY (fist of five) ⚠ chi tiết hơn: 1 ngón là phản đối mạnh, 5 ngón là ủng hộ hết mình
⚠ CHẤM BIỂU QUYẾT (dot voting) ⚠ xếp ưu tiên nhiều lựa chọn
⚠ ĐỒNG THUẬN LỎNG (disagree and commit) ⚠ không đồng ý nhưng cam kết theo quyết định chung
⚠ QUY TẮC ĐA SỐ hoặc ĐỘC ĐOÁN CÓ THAM VẤN ⚠ khi cần quyết nhanh
⚠ Nguyên tắc chung ⚠ mục đích KHÔNG phải là đếm phiếu, mà là LỘ RA những băn khoăn còn giấu
⚠ Điều hành viên nên làm gì khi thấy ngón cái ngang Việc
⚠ HỎI NGAY người đó băn khoăn gì ⚠ đừng bỏ qua rồi chốt luôn
⚠ Nghe hết trước khi biểu quyết lại
⚠ Biểu quyết lại sau khi đã làm rõ
⚠ Nếu vẫn ngang thì ghi lại băn khoăn đó ⚠ có thể là rủi ro cần theo dõi
⚠ Sai lầm hay gặp ⚠ coi ngón cái ngang như phiếu trắng rồi đếm là "không phản đối" — làm vậy vài lần thì lần sau không ai giơ ngang nữa, và đội mất kênh nêu băn khoăn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có cách nào để nói "tôi còn băn khoăn" không | | | Băn khoăn nêu ra có được xử lý hay bị bỏ qua | | | Quyết định gần nhất có ai im lặng mà thật ra không đồng ý không | |

Và giá trị thật sự của ngón cái ngang: nó cho phép một người nói "khoan đã" mà không phải nói "không" — và chính khoảng giữa đó là nơi những rủi ro chưa ai thấy hay xuất hiện.