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

Đáp án

B — ĐI TỚI CHỖ ĐỘI PHÁT TRIỂN VÀ HỎI HỌ CÓ CÂU HỎI GÌ KHÔNG.

Vì sao đúng

⚠ Vì sao đây là việc đúng: | Lý do | Nội dung | |---|---| | ⚠ Chi tiết QUAN TRỌNG với dự án | ⚠ không được để hiểu sai hay bị bỏ sót | | ⚠ Email là kênh MỘT CHIỀU | ⚠ không xác nhận được người đọc đã hiểu | | ⚠ Sally ĐANG LO đội có thể có câu hỏi | ⚠ chính cô đã nhận ra vấn đề | | ⚠ Gặp trực tiếp là kênh GIÀU nhất | ⚠ hỏi đáp ngay, đọc được phản ứng — liên hệ #26692 lô 199 | | ⚠ Scrum master có nhiệm vụ tạo thuận lợi cho giao tiếp | ⚠ không chỉ chuyển tiếp thư | | ⚠ Kết luận | ⚠ giao tiếp chỉ hoàn tất khi người nhận đã HIỂU, không phải khi người gửi đã gửi |

⚠ Mô hình giao tiếp cơ bản có ba phần: MÃ HOÁ – TRUYỀN – GIẢI MÃ, cộng thêm PHẢN HỒI ⚠ — ⚠ email hoàn thành ba phần đầu và bỏ hẳn phần thứ tư; đi tới hỏi chính là phần thứ tư.

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

• D (gửi thêm một email hỏi xem mọi người đã hiểu chưa) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có vẻ đang tìm phản hồi, tức là đúng hướng, và nó ít tốn công hơn: ⚠ nhưng ⚠ nó dùng lại chính kênh đang không chắc chắn để kiểm tra kênh đó ⚠ — ⚠ và câu hỏi "mọi người đã hiểu chưa" gần như luôn nhận được sự im lặng hoặc một chữ "rồi", vì không ai muốn là người duy nhất thừa nhận mình chưa hiểu qua email chung; ⚠ câu hỏi đúng là "anh chị có câu hỏi gì", hỏi trực tiếp, mở đường cho người ta nói.

• A (bảo đội tự liên hệ bên liên quan) — ⚠ đẩy việc; ⚠ có thể hữu ích ở một số ngữ cảnh agile, nhưng ở đây Sally đang là người nắm thông tin và đang lo lắng — cô nên tự xác nhận trước.

• C (không làm gì, đã chuyển tiếp đúng cách rồi) — ⚠ nhầm việc GỬI với việc GIAO TIẾP; ⚠ và nó mâu thuẫn với chính mối lo mà đề nói Sally đang có.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26733 cùng lô (bên liên quan không tìm thấy bản cập nhật), ⚠ #26692 lô 199 (thang độ giàu của kênh giao tiếp), ⚠ #26742 cùng lô (họp đứng hằng ngày của đội từ xa), ⚠ #26769 cùng lô (thu thập ý kiến để cải thiện giao tiếp), ⚠ #26601 lô 197 (đơn giản hoá ngôn ngữ).

⚠ Vì sao email dễ thất bại với thông tin quan trọng: | Vấn đề | Nội dung | |---|---| | ⚠ Không biết ai đã đọc, ai đã hiểu | | | ⚠ Không có giọng điệu, dễ hiểu sai sắc thái | | | ⚠ Người đọc không hỏi lại vì ngại làm phiền | ⚠ hoặc vì không biết mình đang hiểu sai | | ⚠ Chìm giữa hàng chục thư khác | ⚠ liên hệ #26733 cùng lô | | ⚠ Không có cơ hội làm rõ ngay | | | ⚠ Khi nào email vẫn là kênh đúng | ⚠ để LƯU VẾT một quyết định đã được thống nhất bằng miệng — kênh giàu để hiểu nhau, kênh nghèo để ghi lại; dùng ngược thứ tự này là nguồn của phần lớn hiểu lầm trong dự án |

⚠ Cách hỏi để thật sự nhận được câu hỏi: | Nên hỏi | Không nên hỏi | |---|---| | ⚠ "Anh chị có câu hỏi gì về việc này" | ⚠ "mọi người hiểu rồi chứ" — luôn nhận được cái gật đầu | | ⚠ "Ai đó tóm tắt lại giúp tôi được không" | ⚠ "có ai chưa rõ không" | | ⚠ "Điều này ảnh hưởng thế nào tới việc anh chị đang làm" | ⚠ "nếu không có gì thì ta chuyển sang mục sau nhé" | | ⚠ Nguyên tắc | ⚠ câu hỏi ĐÓNG kiểm tra sự lịch sự, câu hỏi MỞ kiểm tra sự hiểu — và với thông tin quan trọng thì chỉ có loại thứ hai đáng tin |

⚠ Vai trò của scrum master trong luồng thông tin: | Việc | Nội dung | |---|---| | ⚠ Tạo thuận lợi cho giao tiếp giữa đội và bên liên quan | ⚠ không phải làm người đưa thư | | ⚠ Về lâu dài: kết nối trực tiếp đội với bên liên quan | ⚠ phương án A đúng ở khía cạnh này, nhưng không phải bước tiếp theo ngay bây giờ | | ⚠ Bảo đảm thông tin quan trọng thật sự tới nơi | ⚠ ĐÁP ÁN | | ⚠ Gỡ vật cản do hiểu nhầm gây ra | ⚠ liên hệ #26702 lô 199 | | ⚠ Mục tiêu cuối cùng | ⚠ một đội tự nói chuyện được với chủ sản phẩm và bên liên quan mà không cần scrum master đứng giữa — nhưng con đường tới đó bắt đầu bằng việc scrum master làm gương cho cách trao đổi cẩn thận, chứ không bằng việc rút lui sớm |

Từ khoá nhận diện:

"thông tin quan trọng gửi qua email, lo đội chưa hiểu" → ⚠ ĐI TỚI HỎI TRỰC TIẾP "gửi thêm email hỏi đã hiểu chưa" → ⚠ dùng lại kênh đang không chắc chắn "đã chuyển tiếp là xong" → ⚠ nhầm gửi với giao tiếp nguyên tắc nền → ⚠ giao tiếp hoàn tất ở phía NGƯỜI NHẬN, không ở phía người gửi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông tin quan trọng gần nhất bạn gửi đi được xác nhận thế nào | | | Bạn hỏi "hiểu chưa" hay hỏi "có câu hỏi gì" | | | Có quyết định nào đội đang hiểu khác bạn không | ⚠ hỏi ai đó tóm tắt lại là biết ngay |

Và điều mà mười bước đi tới bàn của đội thay thế được: một tuần làm việc dựa trên cách hiểu sai — thứ mà không email nào phát hiện ra được cho tới khi đã quá muộn.

Đáp án

B — BIỂU ĐỒ PARETO.

Vì sao đúng

⚠ Đọc thẳng yêu cầu của ban lãnh đạo: | Yêu cầu trong đề | Đặc điểm của biểu đồ Pareto | |---|---| | ⚠ "Sự PHÂN BỐ của các vấn đề" | ⚠ các loại vấn đề xếp thành cột | | ⚠ "và chúng xảy ra BAO NHIÊU LẦN" | ⚠ cột được xếp theo TẦN SUẤT giảm dần | | ⚠ Nhiều vấn đề lộ ra từ kiểm toán chất lượng | ⚠ cần biết xử lý cái nào trước | | ⚠ Kết luận | ⚠ biểu đồ cột theo tần suất giảm dần, kèm đường tích luỹ — đúng định nghĩa Pareto |

⚠ NGUYÊN LÝ PARETO — quy tắc 80/20: ⚠ khoảng 80% vấn đề đến từ khoảng 20% nguyên nhân ⚠ — ⚠ giá trị của biểu đồ này là chỉ ra vài nguyên nhân đáng sửa trước, thay vì để đội dàn đều nỗ lực cho mọi loại lỗi.

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

• D (biểu đồ Ishikawa / xương cá) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là công cụ chất lượng và cũng nói về "vấn đề", nên hai cái rất hay bị hoán đổi: ⚠ nhưng ⚠ xương cá phân tích NGUYÊN NHÂN của MỘT vấn đề, nó không đếm tần suất và không xếp hạng gì cả ⚠ — ⚠ đề yêu cầu thấy sự phân bố và số lần xuất hiện, đó là dữ liệu định lượng mà xương cá không có; ⚠ hai công cụ này thường dùng NỐI TIẾP nhau: Pareto tìm ra vấn đề lớn nhất, xương cá tìm nguyên nhân của chính vấn đề đó.

• A (biểu đồ kiểm soát) — ⚠ theo dõi một quy trình theo THỜI GIAN so với giới hạn kiểm soát; ⚠ liên hệ #26757 cùng lô, nơi biểu đồ kiểm soát mới là đáp án.

• C (lưu đồ) — ⚠ vẽ CÁC BƯỚC của một quy trình; ⚠ không chứa số liệu tần suất.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26755 cùng lô (CÂU CẶP — nhận diện chính biểu đồ này qua công dụng), ⚠ #26757 cùng lô (biểu đồ kiểm soát — công cụ khác, câu hỏi khác), ⚠ #26656 lô 198 (lưu đồ), ⚠ #26741 cùng lô (tìm nguồn gốc của việc phải làm lại), ⚠ #26639 lô 198 (lỗi thoát ra ngoài).

⚠ CÁC CÔNG CỤ CHẤT LƯỢNG — bảng phân biệt: | Công cụ | Trả lời câu hỏi | Hình dạng | |---|---|---| | ⚠ PARETO | ⚠ "vấn đề nào xảy ra nhiều nhất, sửa cái nào trước" — ĐÁP ÁN | ⚠ cột giảm dần + đường tích luỹ | | ⚠ XƯƠNG CÁ (Ishikawa) | ⚠ "vì sao vấn đề NÀY xảy ra" | ⚠ xương cá, các nhánh nguyên nhân | | ⚠ BIỂU ĐỒ KIỂM SOÁT | ⚠ "quy trình có ổn định không" | ⚠ đường theo thời gian + giới hạn kiểm soát — #26757 cùng lô | | ⚠ LƯU ĐỒ | ⚠ "quy trình gồm những bước nào" | ⚠ sơ đồ khối | | ⚠ BIỂU ĐỒ PHÂN TÁN | ⚠ "hai biến có liên quan không" | ⚠ các điểm trên hai trục | | ⚠ BIỂU ĐỒ TẦN SUẤT (histogram) | ⚠ "dữ liệu phân bố ra sao" | ⚠ cột theo khoảng giá trị, KHÔNG xếp hạng | | ⚠ Phân biệt Pareto và histogram | ⚠ cả hai đều là biểu đồ cột, nhưng Pareto XẾP THEO THỨ TỰ GIẢM DẦN và có đường tích luỹ — đó là điểm khiến nó trở thành công cụ ưu tiên chứ không chỉ là công cụ mô tả |

⚠ Cách đọc và dùng biểu đồ Pareto: | Bước | Nội dung | |---|---| | ⚠ Phân loại các vấn đề thành nhóm | ⚠ phân loại tốt quyết định giá trị của biểu đồ | | ⚠ Đếm số lần xuất hiện của từng nhóm | | | ⚠ Xếp cột theo thứ tự giảm dần | | | ⚠ Vẽ đường phần trăm tích luỹ | ⚠ để thấy vài nhóm đầu chiếm bao nhiêu phần trăm tổng số | | ⚠ Tập trung nguồn lực vào các nhóm bên trái | | | ⚠ Lưu ý quan trọng | ⚠ tần suất không phải lúc nào cũng bằng mức nghiêm trọng — một lỗi hiếm gây mất dữ liệu có thể quan trọng hơn năm mươi lỗi hiển thị; với những trường hợp đó, hãy vẽ Pareto theo CHI PHÍ hoặc theo TÁC ĐỘNG thay vì theo số lần |

⚠ Vì sao ban lãnh đạo yêu cầu đúng công cụ này: | Lý do | Nội dung | |---|---| | ⚠ Kiểm toán lộ ra NHIỀU vấn đề cùng lúc | ⚠ không thể sửa hết ngay | | ⚠ Cần cơ sở khách quan để chọn ưu tiên | ⚠ thay vì sửa cái nào kêu to nhất | | ⚠ Dễ trình bày cho người không chuyên | ⚠ một hình là hiểu ngay | | ⚠ Đo được tiến bộ sau khi sửa | ⚠ vẽ lại biểu đồ sau vài tháng | | ⚠ Bước tiếp theo hợp lý | ⚠ lấy cột cao nhất trong biểu đồ Pareto rồi vẽ một biểu đồ XƯƠNG CÁ cho riêng nó — đó là cách hai công cụ này phối hợp và là quy trình cải tiến chất lượng kinh điển |

Từ khoá nhận diện:

"phân bố vấn đề và tần suất xuất hiện" → ⚠ BIỂU ĐỒ PARETO "vì sao vấn đề này xảy ra" → ⚠ xương cá "quy trình có ổn định theo thời gian không" → ⚠ biểu đồ kiểm soát "các bước của quy trình" → ⚠ lưu đồ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết ba loại lỗi phổ biến nhất trong dự án mình không | | | Bạn ưu tiên sửa lỗi theo tần suất hay theo mức độ ồn ào | | | Sau khi sửa, bạn có đo lại không | |

Và điều mà một biểu đồ cột xếp theo thứ tự giảm dần làm được cho một cuộc họp đang bế tắc: nó biến câu hỏi "sửa cái nào trước" từ một cuộc tranh luận về ý kiến thành một câu trả lời mà ai nhìn cũng thấy.

Đáp án

A — GIÚP ĐỘI NHẬN DIỆN VÀ XỬ LÝ CÁC LỖI XẢY RA THƯỜNG XUYÊN NHẤT.

Vì sao đúng

⚠ Suy ra từ chính bốn phương án — sơ đồ này là BIỂU ĐỒ PARETO: | Manh mối | Ý nghĩa | |---|---| | ⚠ "Các lỗi xảy ra THƯỜNG XUYÊN NHẤT" | ⚠ xếp hạng theo tần suất — dấu hiệu của Pareto | | ⚠ Treo trong khu làm việc của đội | ⚠ bảng thông tin trực quan — liên hệ #26714 lô 199 | | ⚠ Dự án đang hơi vượt ngân sách | ⚠ chi phí do làm lại là nghi phạm hàng đầu | | ⚠ Ba phương án còn lại đều mô tả biểu đồ KHÁC | ⚠ loại trừ được bằng logic | | ⚠ Kết luận | ⚠ công dụng của biểu đồ Pareto là chỉ ra vài loại lỗi chiếm phần lớn số lần xảy ra |

⚠ Câu này và #26754 cùng lô là một CẶP: ⚠ #26754 hỏi "cần biểu đồ nào" và trả lời là Pareto; câu này đưa ra một biểu đồ và hỏi "nó dùng để làm gì" ⚠ — ⚠ hai chiều của cùng một kiến thức.

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

• C (giúp đội động não về mối quan hệ giữa các vấn đề) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó mô tả BIỂU ĐỒ XƯƠNG CÁ, công cụ cũng thường được treo trong khu làm việc và cũng nói về vấn đề chất lượng: ⚠ nhưng ⚠ xương cá dùng để tìm NGUYÊN NHÂN của MỘT vấn đề, nó không xếp hạng và không nói về tần suất ⚠ — ⚠ còn phương án A nói rõ "các lỗi thường xuyên nhất", tức là có thứ hạng theo số lần; ⚠ liên hệ #26754 cùng lô để thấy đúng cặp phân biệt này.

• B (hiển thị số điểm câu chuyện đội đã hoàn thành) — ⚠ mô tả biểu đồ BURNDOWN hoặc BURNUP; ⚠ liên hệ #26729 lô 199.

• D (theo dõi lượng email của đội) — ⚠ không phải công cụ quản lý dự án nào cả; ⚠ phương án loại nhanh.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này PHỤ THUỘC VÀO HÌNH ẢNH — đề nói "anh ta nhìn thấy sơ đồ sau đây được dán trong khu làm việc" nhưng hình không được nhập vào ngân hàng đề ⚠ — ⚠ khoá đáp án được giữ nguyên vì bốn phương án đã mô tả bốn loại biểu đồ khác nhau đủ rõ để suy ra ý định của đề; ⚠ kỹ năng cần dùng khi gặp câu phụ thuộc ảnh: đọc bốn phương án, nhận ra mỗi phương án ứng với một công cụ nào, rồi chọn công cụ khớp nhất với bối cảnh của đề — ở đây bối cảnh là chất lượng và chi phí vượt dự toán, nên công cụ về lỗi là hợp lý nhất.

⚠ Đối chiếu: ⚠ #26754 cùng lô (CÂU CẶP — biểu đồ Pareto), ⚠ #26757 cùng lô (biểu đồ kiểm soát), ⚠ #26714 lô 199 (bảng thông tin trực quan), ⚠ #26729 lô 199 (burndown — phương án nhiễu B), ⚠ #26656 lô 198 (lưu đồ).

⚠ Bốn phương án — bốn biểu đồ khác nhau: | Phương án | Biểu đồ tương ứng | |---|---| | ⚠ A — lỗi thường gặp nhất | ⚠ PARETO — ĐÁP ÁN | | ⚠ B — điểm câu chuyện đã hoàn thành | ⚠ burndown / burnup — liên hệ #26729 lô 199 | | ⚠ C — quan hệ giữa các vấn đề | ⚠ xương cá (Ishikawa) | | ⚠ D — lượng email | ⚠ không phải công cụ nào | | ⚠ Kỹ thuật làm bài | ⚠ với câu phụ thuộc ảnh, hãy ánh xạ từng phương án về một công cụ cụ thể; thường chỉ có một phương án khớp với cả bối cảnh lẫn cách diễn đạt của đề |

⚠ Vì sao một biểu đồ Pareto treo ở khu làm việc lại hữu ích: | Lợi ích | Nội dung | |---|---| | ⚠ Cả đội cùng thấy loại lỗi nào đang chiếm phần lớn | ⚠ thống nhất về ưu tiên mà không cần họp | | ⚠ Người ngoài đi qua cũng hiểu tình hình chất lượng | ⚠ như Jeff trong đề | | ⚠ Tạo áp lực tích cực để cột cao nhất thấp xuống | | | ⚠ Đo được tiến bộ khi vẽ lại sau mỗi giai đoạn | | | ⚠ Điều kiện để nó có tác dụng | ⚠ phải được CẬP NHẬT — một biểu đồ Pareto của quý trước treo trên tường chỉ còn là vật trang trí, và tệ hơn là nó khiến đội tưởng mình đang theo dõi chất lượng, liên hệ #26714 lô 199 |

⚠ Liên hệ với việc dự án đang vượt ngân sách: | Quan hệ | Nội dung | |---|---| | ⚠ Lỗi lặp lại sinh ra chi phí LÀM LẠI | ⚠ chi phí không phù hợp — liên hệ #26525 lô 195 | | ⚠ Giảm lỗi phổ biến nhất là cách nhanh nhất hạ chi phí đó | | | ⚠ Vài loại lỗi chiếm phần lớn thời gian sửa | ⚠ nguyên lý 80/20 | | ⚠ Nhận xét | ⚠ việc đội treo biểu đồ này lên tường là dấu hiệu tốt — nó cho thấy họ đang tự nhìn vào nguyên nhân thay vì chỉ chịu đựng hậu quả, và với một dự án vượt ngân sách nhẹ thì đó thường là con đường quay lại đúng quỹ đạo |

Từ khoá nhận diện:

"lỗi xảy ra thường xuyên nhất" → ⚠ BIỂU ĐỒ PARETO "quan hệ giữa các vấn đề, tìm nguyên nhân" → ⚠ xương cá "điểm câu chuyện đã xong" → ⚠ burndown / burnup câu phụ thuộc ảnh → ⚠ ánh xạ từng phương án về một công cụ rồi so với bối cảnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trên tường khu làm việc của bạn có gì | | | Những thứ treo ở đó được cập nhật lần cuối khi nào | | | Người ngoài đi ngang có hiểu được chúng không | |

Và điều mà một bên liên quan như Jeff nhận ra khi đi ngang qua tấm biểu đồ ấy: đội này biết chính xác cái gì đang làm họ chậm — và điều đó thường đáng tin cậy hơn nhiều so với một báo cáo tình trạng nói rằng mọi thứ đều ổn.

Đáp án

C — BẤT KỲ PHƯƠNG PHÁP NÀO, VÌ KHÔNG CÓ MỘT PHƯƠNG PHÁP DUY NHẤT TỐT NHẤT ĐỂ XẾP ƯU TIÊN CÔNG VIỆC TRONG DỰ ÁN AGILE.

Vì sao đúng

⚠ Vì sao không có phương pháp duy nhất: | Lý do | Nội dung | |---|---| | ⚠ Agile là bộ GIÁ TRỊ và NGUYÊN TẮC, không phải bộ thủ tục bắt buộc | ⚠ các khung cụ thể để đội tự chọn công cụ | | ⚠ Mỗi phương pháp phù hợp với một loại tình huống | ⚠ MoSCoW, Kano, mua tính năng, xếp hạng tuyệt đối, WSJF | | ⚠ Loại sản phẩm và loại bên liên quan khác nhau | | | ⚠ Đội tự tổ chức được quyền chọn cách làm việc của mình | | | ⚠ Điều quan trọng là KẾT QUẢ: một tồn đọng có thứ tự rõ ràng | ⚠ không phải tên của phương pháp | | ⚠ Kết luận | ⚠ chọn phương pháp phù hợp với đội và bối cảnh, rồi cải tiến dần qua các buổi hồi cứu |

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

• D (phương pháp MoSCoW) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ MoSCoW là phương pháp xếp ưu tiên nổi tiếng nhất và hoàn toàn hợp lệ, nên chọn nó có vẻ an toàn: ⚠ nhưng ⚠ câu hỏi hỏi cách tiếp cận TỐT NHẤT, và việc khẳng định một phương pháp cụ thể là tốt nhất cho mọi tình huống chính là điều trái với tinh thần agile ⚠ — ⚠ MoSCoW cũng có nhược điểm riêng: rất dễ dẫn tới việc mọi thứ đều thành "bắt buộc phải có", liên hệ #26720 lô 199; ⚠ trong đề PMP, phương án tuyệt đối hoá một công cụ thường sai, còn phương án nói về sự phù hợp với bối cảnh thường đúng.

• B (không phương pháp nào, việc xếp ưu tiên do chủ sản phẩm làm riêng) — ⚠ chủ sản phẩm ĐÚNG là người quyết định cuối cùng về thứ tự tồn đọng; ⚠ nhưng làm việc đó MỘT MÌNH, tách khỏi đội, thì mất đi thông tin về công sức, phụ thuộc kỹ thuật và rủi ro — đề cũng nói rõ Gary đang ngồi CÙNG ĐỘI.

• A (biểu quyết nhiều lựa chọn — multi-voting) — ⚠ là một kỹ thuật hợp lệ nhưng chỉ là MỘT trong nhiều cách; ⚠ nêu nó như câu trả lời duy nhất mắc đúng lỗi của phương án D.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26720 lô 199 (nhược điểm của sơ đồ xếp ưu tiên quá đơn giản), ⚠ #26767 cùng lô (MoSCoW — phân loại "could have"), ⚠ #26749 cùng lô (ưu tiên hạng mục rủi ro cao), ⚠ #26711 lô 199 (thu hẹp về hạng mục lõi), ⚠ #26765 cùng lô (chia nhỏ câu chuyện phức tạp).

⚠ CÁC PHƯƠNG PHÁP XẾP ƯU TIÊN và điểm mạnh của từng cái: | Phương pháp | Mạnh ở | Yếu ở | |---|---|---| | ⚠ MoSCoW | ⚠ dễ hiểu, dễ trao đổi với bên liên quan | ⚠ mọi thứ dễ thành "must" — #26720 lô 199 | | ⚠ XẾP HẠNG TUYỆT ĐỐI | ⚠ buộc phải chọn, không có đồng hạng | ⚠ tốn công khi tồn đọng lớn | | ⚠ MUA TÍNH NĂNG | ⚠ ngân sách hữu hạn buộc phải đánh đổi | ⚠ cần tổ chức buổi hội thảo | | ⚠ MÔ HÌNH KANO | ⚠ phân biệt tính năng cơ bản, hiệu năng và hấp dẫn | ⚠ cần khảo sát khách hàng | | ⚠ WSJF (chi phí trì hoãn chia thời lượng) | ⚠ định lượng, hợp với quy mô lớn | ⚠ cần ước lượng nhiều tham số | | ⚠ Ma trận GIÁ TRỊ – CÔNG SỨC | ⚠ trực quan, nhanh | ⚠ thô, chỉ chia bốn ô — liên hệ #26715 lô 199 | | ⚠ Điểm chung của mọi phương pháp tốt | ⚠ chúng buộc người ta phải ĐÁNH ĐỔI; phương pháp nào cho phép mọi hạng mục cùng ở mức cao nhất thì đã hỏng, bất kể tên gọi của nó là gì |

⚠ Vì sao việc Gary ngồi cùng đội là chi tiết quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Đội biết CÔNG SỨC và PHỤ THUỘC KỸ THUẬT | ⚠ thông tin mà chủ sản phẩm không có | | ⚠ Chủ sản phẩm biết GIÁ TRỊ KINH DOANH | ⚠ thông tin mà đội không có | | ⚠ Xếp ưu tiên tốt cần cả hai loại thông tin | | | ⚠ Cùng làm thì cả đội hiểu VÌ SAO thứ tự là như vậy | ⚠ và sẽ bảo vệ nó khi bị ép | | ⚠ Ranh giới cần giữ | ⚠ đội ĐÓNG GÓP thông tin, chủ sản phẩm QUYẾT ĐỊNH cuối cùng — phương án B đúng ở vế thứ hai nhưng bỏ mất vế thứ nhất, và đó là lý do nó không phải đáp án |

⚠ Kiểu câu hỏi "không có cách nào là tốt nhất": | Dấu hiệu | Nội dung | |---|---| | ⚠ Đề hỏi cách tiếp cận TỐT NHẤT cho một hoạt động agile chung chung | | | ⚠ Các phương án nêu tên những công cụ đều hợp lệ | | | ⚠ Có một phương án nói về sự PHÙ HỢP VỚI BỐI CẢNH | ⚠ thường là đáp án | | ⚠ Cảnh báo ngược lại | ⚠ đừng áp dụng máy móc — khi đề mô tả một tình huống CỤ THỂ với ràng buộc rõ ràng, thì phương án cụ thể mới đúng; "tuỳ bối cảnh" chỉ thắng khi câu hỏi thật sự chung chung như câu này |

Từ khoá nhận diện:

"cách tốt nhất để xếp ưu tiên tồn đọng" → ⚠ KHÔNG có phương pháp duy nhất tốt nhất "chỉ MoSCoW" → ⚠ tuyệt đối hoá một công cụ "chủ sản phẩm làm một mình" → ⚠ mất thông tin về công sức và rủi ro kỹ thuật "chỉ biểu quyết" → ⚠ cũng là tuyệt đối hoá một kỹ thuật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn xếp ưu tiên bằng cách nào, và ai tham gia | | | Phương pháp đó có buộc phải đánh đổi không | | | Đội có hiểu vì sao hạng mục đầu tiên lại đứng đầu không | |

Và điều mà một buổi xếp ưu tiên tốt để lại, dù dùng phương pháp nào: cả đội bước ra khỏi phòng với cùng một câu trả lời cho câu hỏi tuần sau chúng ta làm gì trước — và biết vì sao lại là thứ đó.

Đáp án

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

Vì sao đúng

⚠ Câu hỏi hỏi đúng công dụng riêng của biểu đồ kiểm soát: | Yêu cầu trong đề | Đặc điểm biểu đồ kiểm soát | |---|---| | ⚠ "Xác định quy trình CÓ TRONG TẦM KIỂM SOÁT hay không" | ⚠ đây là định nghĩa nguyên văn của công cụ này | | ⚠ Sharon đo THỜI GIAN từ khi sản phẩm sẵn sàng tới khi được dùng | ⚠ một biến số đo lặp lại theo thời gian | | ⚠ Cô nghi ngờ quy trình đang có vấn đề hệ thống | ⚠ cần phân biệt biến thiên thường và biến thiên bất thường | | ⚠ Kết luận | ⚠ biểu đồ kiểm soát là công cụ duy nhất trả lời được câu hỏi "quy trình có ổn định không" |

⚠ Biểu đồ kiểm soát có ba đường: ⚠ giới hạn kiểm soát trên, đường trung tâm, giới hạn kiểm soát dưới ⚠ — ⚠ điểm nằm trong giới hạn là biến thiên BÌNH THƯỜNG của quy trình; điểm vượt ra ngoài là dấu hiệu có NGUYÊN NHÂN ĐẶC BIỆT cần điều tra.

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

• D (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à trông rất giống biểu đồ kiểm soát khi nhìn thoáng: ⚠ nhưng ⚠ biểu đồ chuỗi KHÔNG CÓ giới hạn kiểm soát — nó chỉ cho thấy xu hướng, không phán xét được quy trình có nằm trong tầm kiểm soát hay không ⚠ — ⚠ mà chính chữ "trong tầm kiểm soát" trong câu hỏi là thuật ngữ kỹ thuật gắn liền với các đường giới hạn; ⚠ biểu đồ kiểm soát chính là biểu đồ chuỗi CỘNG THÊM các giới hạn thống kê.

• B (biểu đồ xương cá) — ⚠ phân tích NGUYÊN NHÂN của một vấn đề; ⚠ không có dữ liệu theo thời gian.

• C (biểu đồ Pareto) — ⚠ xếp hạng vấn đề theo TẦN SUẤT; ⚠ liên hệ #26754 và #26755 cùng lô, nơi Pareto mới là đáp án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26754 cùng lô và ⚠ #26755 cùng lô (Pareto — công cụ khác, câu hỏi khác), ⚠ #26654 lô 198 (phép đo chất lượng), ⚠ #26708 lô 199 (bàn giao sớm để rút ngắn thời gian tới tay người dùng), ⚠ #26741 cùng lô (tìm nguyên nhân gốc), ⚠ #26674 lô 198 (nhịp độ bền vững — mối lo của Sharon về áp lực đội).

⚠ BIỂU ĐỒ KIỂM SOÁT — các khái niệm cần nhớ: | Khái niệm | Nội dung | |---|---| | ⚠ GIỚI HẠN KIỂM SOÁT (control limits) | ⚠ tính từ DỮ LIỆU của chính quy trình, thường ±3 độ lệch chuẩn | | ⚠ GIỚI HẠN ĐẶC TẢ (specification limits) | ⚠ do KHÁCH HÀNG hoặc hợp đồng đặt ra — khác hoàn toàn | | ⚠ NGUYÊN NHÂN THÔNG THƯỜNG | ⚠ biến thiên tự nhiên, nằm trong giới hạn — đừng can thiệp | | ⚠ NGUYÊN NHÂN ĐẶC BIỆT | ⚠ điểm vượt giới hạn — phải điều tra | | ⚠ QUY TẮC BẢY (rule of seven) | ⚠ bảy điểm liên tiếp cùng một phía đường trung tâm là bất thường, dù vẫn trong giới hạn | | ⚠ Sai lầm tốn kém nhất | ⚠ can thiệp vào biến thiên thông thường — nó làm quy trình BẤT ỔN HƠN chứ không tốt hơn; đây là điều Deming gọi là can thiệp thái quá, và nó phổ biến hơn nhiều so với việc bỏ sót nguyên nhân đặc biệt |

⚠ Sharon nên đo và vẽ gì: | Việc | Nội dung | |---|---| | ⚠ Biến số: thời gian từ "sẵn sàng" tới "được sử dụng" | ⚠ chính là THỜI GIAN CHỜ ở khâu cuối | | ⚠ Vẽ theo thứ tự thời gian của từng sản phẩm bàn giao | | | ⚠ Tính giới hạn kiểm soát từ dữ liệu quá khứ | | | ⚠ Tìm điểm vượt giới hạn và các chuỗi bất thường | | | ⚠ Điều tra nguyên nhân đặc biệt bằng xương cá | ⚠ liên hệ #26754 cùng lô | | ⚠ Điều Sharon có thể phát hiện | ⚠ nếu độ trễ ổn định ở mức cao thì đó là vấn đề của chính QUY TRÌNH, không phải của con người — và khi đó việc ép đội chạy nhanh hơn không những vô ích mà còn làm hỏng thêm, đúng như mối lo của cô về tâm lý vội vã |

⚠ Vì sao vấn đề của Sharon là vấn đề hệ thống chứ không phải vấn đề nỗ lực: | Dấu hiệu | Nội dung | |---|---| | ⚠ Đội chịu áp lực hoàn thành công việc | ⚠ họ đang làm nhanh hết mức | | ⚠ Nhưng công việc xong lại nằm chờ nhiều ngày, nhiều tuần | ⚠ nút thắt nằm SAU đội, không nằm ở đội | | ⚠ Ép đội nhanh hơn chỉ làm hàng chờ dài thêm | ⚠ tinh thần của tư duy tinh gọn | | ⚠ Kết luận đáng nói với ban lãnh đạo | ⚠ giảm thời gian chờ ở khâu triển khai sẽ rút ngắn tổng thời gian giao giá trị nhiều hơn bất kỳ nỗ lực tăng tốc nào ở khâu phát triển — và đó là một lập luận chỉ có sức nặng khi kèm theo dữ liệu từ biểu đồ kiểm soát |

Từ khoá nhận diện:

"quy trình có trong tầm kiểm soát không" → ⚠ BIỂU ĐỒ KIỂM SOÁT "chỉ vẽ xu hướng theo thời gian, không có giới hạn" → ⚠ biểu đồ chuỗi "lỗi nào hay xảy ra nhất" → ⚠ Pareto "vì sao vấn đề này xảy ra" → ⚠ xương cá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đo thời gian từ lúc hoàn thành tới lúc được dùng không | | | Khi một con số xấu đi, bạn kiểm tra xem đó có phải biến thiên bình thường không | | | Nút thắt thật của dòng giá trị trong dự án bạn nằm ở đâu | |

Và điều mà một biểu đồ kiểm soát nói với người quản lý đang định thúc đội chạy nhanh hơn: phần lớn biến thiên mà bạn nhìn thấy không phải do ai lười — nó là tiếng nói của chính quy trình, và chỉ có quy trình mới sửa được nó.

Đáp án

A — GHI NHỚ TƯƠNG LAI (Remember the Future).

Vì sao đúng

⚠ Đề mô tả đúng cách chơi của trò này: | Bước trong đề | Đặc điểm của trò chơi | |---|---| | ⚠ Hình dung mình đang ở một thời điểm SAU khi phát hành | ⚠ dịch chuyển góc nhìn về tương lai | | ⚠ Liệt kê những gì ĐÃ được bàn giao | ⚠ nói ở thì QUÁ KHỨ về một việc chưa xảy ra | | ⚠ Mô tả buổi phát hành ĐÃ diễn ra thế nào | ⚠ kể lại như một ký ức | | ⚠ Kết luận | ⚠ đúng công thức "nhớ lại tương lai" — trò chơi cộng tác kinh điển trong agile |

⚠ Vì sao thủ thuật ngôn ngữ này hiệu quả: ⚠ con người mô tả QUÁ KHỨ cụ thể và tự tin hơn nhiều so với dự đoán TƯƠNG LAI ⚠ — ⚠ hỏi "chúng ta sẽ làm gì" thì nhận được các câu chung chung; hỏi "chúng ta đã làm được gì" thì nhận được danh sách cụ thể.

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

• C (Future Visualization) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cụm từ này mô tả gần đúng hoạt động — hình dung tương lai — nên nghe rất hợp lý với người chưa biết tên chính thức: ⚠ nhưng ⚠ nó KHÔNG phải tên của một kỹ thuật agile nào; đây là một thuật ngữ được bịa ra bằng cách diễn giải chính đề bài ⚠ — ⚠ và nó bỏ mất yếu tố đặc trưng nhất của trò chơi thật: việc kể lại ở THÌ QUÁ KHỨ; ⚠ dạng bẫy này rất phổ biến: lấy nội dung câu hỏi diễn đạt thành một cái tên nghe hợp lý.

• B (Post-Release Planning) — ⚠ cũng là thuật ngữ bịa; ⚠ nghe như một hoạt động lập kế hoạch sau phát hành, không liên quan tới việc hình dung.

• D (Back to the Future) — ⚠ tên một bộ phim; ⚠ phương án hài hước để loại.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26722 lô 199 (trò chơi cộng tác để đạt đồng thuận — trò này nằm trong danh sách đó), ⚠ #26643 lô 198 (phân tích tiền tử thi — kỹ thuật anh em), ⚠ #26688 lô 199 (viết thầm), ⚠ #26760 cùng lô (round robin), ⚠ #26749 cùng lô (nhận diện rủi ro sớm).

⚠ GHI NHỚ TƯƠNG LAI và TIỀN TỬ THI — hai anh em: | Tiêu chí | GHI NHỚ TƯƠNG LAI | TIỀN TỬ THI (pre-mortem) | |---|---|---| | ⚠ Giả định | ⚠ dự án đã THÀNH CÔNG | ⚠ dự án đã THẤT BẠI | | ⚠ Câu hỏi | ⚠ "chúng ta đã làm được những gì" | ⚠ "vì sao nó đã hỏng" — liên hệ #26643 lô 198 | | ⚠ Đầu ra | ⚠ danh sách mục tiêu và tiêu chí thành công cụ thể | ⚠ danh sách rủi ro | | ⚠ Dùng khi | ⚠ lập kế hoạch phát hành, thống nhất tầm nhìn | ⚠ lập kế hoạch rủi ro | | ⚠ Điểm chung | ⚠ cả hai đều dùng chung một thủ thuật tâm lý: nói về một tương lai giả định ở THÌ QUÁ KHỨ, vì trí óc con người mô tả những gì đã xảy ra cụ thể hơn rất nhiều so với những gì có thể xảy ra |

⚠ Buổi hội thảo của Arthur sẽ cho ra gì: | Đầu ra | Nội dung | |---|---| | ⚠ Danh sách các hạng mục cụ thể đội mong bàn giao | ⚠ đầu vào cho tồn đọng phát hành | | ⚠ Định nghĩa chung về "phát hành thành công" | ⚠ liên hệ #26662 lô 198 | | ⚠ Kỳ vọng ngầm được nói thành lời | ⚠ giá trị lớn nhất — mọi người thường tưởng mình đang cùng nghĩ một thứ | | ⚠ Các chỉ số để đo sau khi phát hành | ⚠ liên hệ #26713 lô 199 — KPI | | ⚠ Sự hào hứng và cảm giác sở hữu chung | | | ⚠ Bước tiếp theo | ⚠ đối chiếu danh sách "đã bàn giao" của trí tưởng tượng với tồn đọng THẬT — khoảng cách giữa hai danh sách đó chính là thứ cần bàn tiếp, và nó thường lớn hơn mọi người nghĩ |

⚠ Nhận diện thuật ngữ bịa trong đề agile: | Dấu hiệu | Ví dụ | |---|---| | ⚠ Tên là bản diễn giải trực tiếp của đề bài | ⚠ "Future Visualization" — câu này | | ⚠ Ghép các từ chuyên môn quen thuộc | ⚠ "Post-Release Planning" | | ⚠ Tên văn hoá đại chúng | ⚠ "Back to the Future" | | ⚠ Danh sách thuật ngữ bịa đã gặp trong bộ đề này | ⚠ "ma trận tác động giao tiếp", "coupled vision", "risk assurance", "halo power", "net investment value", "return on income", "technical assessment board compliance", "Kanban completion" — và nay thêm ba cái nữa |

Từ khoá nhận diện:

"hình dung đã phát hành xong rồi kể lại" → ⚠ GHI NHỚ TƯƠNG LAI "hình dung dự án đã thất bại" → ⚠ tiền tử thi "Future Visualization", "Post-Release Planning" → ⚠ thuật ngữ bịa thủ thuật chung → ⚠ nói về tương lai ở THÌ QUÁ KHỨ để có câu trả lời cụ thể hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có định nghĩa chung về thành công của lần phát hành tới không | | | Nếu hỏi ba người, bạn có nhận được ba câu trả lời khác nhau không | | | Bạn có bao giờ hỏi đội "vì sao việc này đã hỏng" trước khi nó hỏng chưa | |

Và điều mà một thủ thuật ngữ pháp đơn giản mở ra được: khi được phép nói về tương lai như một điều đã xảy ra, người ta thôi dè dặt và bắt đầu mô tả chính xác thứ mà họ vẫn luôn hy vọng — thứ mà câu hỏi "anh mong đợi gì" hiếm khi lấy ra được.

Đáp án

A — ĐỂ ĐỘI CÓ MỘT BỘ THỰC HÀNH CHUNG DÙNG LÀM CHUẨN CHO HÀNH VI (baseline behaviors).

Vì sao đúng

⚠ Vì sao đây là mô tả đúng nhất: | Lý do | Nội dung | |---|---| | ⚠ Quy tắc ứng xử tạo ra một CHUẨN mà mọi người cùng chiếu vào | ⚠ chữ "baseline" nói đúng bản chất | | ⚠ Nó bao trùm mọi loại hành vi, không chỉ một khía cạnh | ⚠ họp hành, giao tiếp, quyết định, xung đột, tôn trọng lẫn nhau | | ⚠ Đội đang ở giai đoạn HÌNH THÀNH | ⚠ chưa có chuẩn chung nào — cần xây | | ⚠ Có chuẩn thì mới nhắc nhau được mà không thành công kích cá nhân | ⚠ "ta đã thống nhất là..." khác hẳn "anh sai rồi" | | ⚠ Kết luận | ⚠ quy tắc ứng xử là nền hành vi chung của đội |

⚠ Ba phương án còn lại đều mô tả MỘT PHẦN của tác dụng, còn phương án A mô tả BẢN CHẤT ⚠ — ⚠ dạng câu hỏi "mô tả nào đúng nhất" thường được thiết kế đúng theo kiểu này.

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

• B (nêu ra các hướng dẫn đội sẽ tuân theo khi RA QUYẾT ĐỊNH) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cách ra quyết định thật sự là một nội dung quan trọng của quy tắc ứng xử, nên phát biểu này không sai: ⚠ nhưng ⚠ nó chỉ là MỘT trong nhiều lĩnh vực mà quy tắc ứng xử bao trùm ⚠ — ⚠ quy tắc còn nói về giờ họp, cách phản hồi, cách xử lý bất đồng, cách tôn trọng thời gian của nhau; ⚠ phương án A bao trùm cả phương án B, nên A là câu trả lời đúng nhất.

• C (nêu rõ vai trò và trách nhiệm của từng thành viên) — ⚠ đó là việc của MA TRẬN TRÁCH NHIỆM (RACI) hoặc bản mô tả vai trò; ⚠ khác với quy tắc hành vi.

• D (ngăn xung đột trong suốt vòng đời dự án) — ⚠ hứa hẹn quá mức; ⚠ quy tắc ứng xử giúp XỬ LÝ xung đột một cách xây dựng chứ không ngăn được xung đột — và xung đột về nhiệm vụ còn là điều lành mạnh, liên hệ #26675 lô 198.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26683 lô 199 (họp đội lần đầu — giới thiệu trước, quy tắc sau), ⚠ #26750 cùng lô (đội im lặng vì thiếu chuẩn an toàn), ⚠ #26779 cùng lô (hiến chương đội — nơi chứa quy tắc ứng xử), ⚠ #26742 cùng lô (quy ước cho buổi họp hằng ngày), ⚠ #26700 lô 199 (quy tắc của buổi hồi cứu).

⚠ QUY TẮC ỨNG XỬ nên bao gồm gì: | Lĩnh vực | Ví dụ | |---|---| | ⚠ Họp hành | ⚠ bắt đầu đúng giờ, tắt thông báo, ai vắng thì báo trước | | ⚠ Giao tiếp | ⚠ kênh nào cho việc gì, thời gian phản hồi mong đợi | | ⚠ Ra quyết định | ⚠ đồng thuận hay đa số, ai quyết khi bế tắc — phương án B | | ⚠ Xung đột | ⚠ nói thẳng với người liên quan trước khi leo thang | | ⚠ Phản hồi | ⚠ góp ý về việc, không về người — liên hệ #26700 lô 199 | | ⚠ Tôn trọng thời gian | ⚠ không nhắn ngoài giờ, tôn trọng múi giờ khác nhau | | ⚠ Điều kiện quan trọng nhất | ⚠ quy tắc phải do ĐỘI TỰ XÂY, không phải do người quản lý phát xuống — quy tắc áp đặt sẽ bị bỏ qua ngay tuần đầu tiên, còn quy tắc tự thoả thuận thì chính đội sẽ nhắc nhau |

⚠ Vì sao đội ở giai đoạn HÌNH THÀNH cần điều này: | Đặc điểm giai đoạn | Nội dung | |---|---| | ⚠ Mọi người còn dè dặt, lịch sự | ⚠ chưa ai biết giới hạn ở đâu | | ⚠ Chưa có chuẩn chung nào | ⚠ mỗi người mang thói quen từ đội cũ tới | | ⚠ Giai đoạn SÓNG GIÓ sắp tới | ⚠ có quy tắc trước thì va chạm sẽ ít gây tổn thương hơn | | ⚠ Dự án dài một năm, ngân sách lớn | ⚠ đủ dài để một hành vi xấu trở thành thói quen cố hữu | | ⚠ Thời điểm tốt nhất | ⚠ ngay trong buổi họp đầu tiên hoặc buổi thứ hai, sau khi mọi người đã biết nhau — liên hệ #26683 lô 199, giới thiệu đứng trước quy tắc |

⚠ Quy tắc ứng xử phát huy tác dụng khi nào: | Điều kiện | Nội dung | |---|---| | ⚠ Cụ thể, không chung chung | ⚠ "trả lời tin nhắn trong một ngày làm việc" thay vì "giao tiếp tốt" | | ⚠ Được viết ra và nhìn thấy được | ⚠ liên hệ #26714 lô 199 | | ⚠ Được rà lại định kỳ trong buổi hồi cứu | | | ⚠ Người dẫn dắt làm gương trước | ⚠ một quy tắc mà người quản lý phá là một quy tắc đã chết | | ⚠ Có cách nhắc nhau khi ai đó quên | | | ⚠ Giá trị lớn nhất | ⚠ khi có chuẩn chung, việc nhắc nhở không còn là công kích cá nhân — đó chính là thứ giúp một đội đi qua giai đoạn sóng gió mà không tan rã |

Từ khoá nhận diện:

"quy tắc ứng xử của đội" → ⚠ BỘ THỰC HÀNH CHUNG làm chuẩn cho hành vi "hướng dẫn ra quyết định" → ⚠ chỉ MỘT phần của quy tắc "vai trò và trách nhiệm" → ⚠ ma trận trách nhiệm, khác công cụ "ngăn mọi xung đột" → ⚠ hứa quá mức; xung đột nhiệm vụ còn là điều lành mạnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có quy tắc ứng xử viết ra không | | | Chúng do đội tự xây hay do ai đó phát xuống | | | Lần cuối có người viện dẫn một quy tắc để nhắc nhau là khi nào | ⚠ chưa từng nghĩa là quy tắc đã bị quên |

Và điều mà một trang quy tắc được cả đội cùng viết trong tuần đầu tiên mua được: quyền nói "chúng ta đã thống nhất là không làm vậy" vào tháng thứ bảy — một câu mà không ai nói nổi nếu tuần đầu tiên đã bỏ qua bước này.

Đáp án

A — SẮP XẾP BUỔI HỘI THẢO THEO KỸ THUẬT VÒNG TRÒN (round-robin).

Vì sao đúng

⚠ Vì sao vòng tròn giải quyết được vấn đề của Lauren: | Lý do | Nội dung | |---|---| | ⚠ Nó là giải pháp về CẤU TRÚC, không phải về con người | ⚠ không ai bị nhắm tới, không ai mất mặt | | ⚠ Mỗi người đều có lượt, lần lượt | ⚠ Bob vẫn được nói, chỉ là không nói mãi | | ⚠ Tự động tạo không gian cho người ít nói | ⚠ lợi ích lớn hơn cả mục tiêu ban đầu | | ⚠ Áp dụng cho TẤT CẢ nên công bằng | ⚠ không phải luật riêng cho Bob | | ⚠ Bob vẫn đóng góp được kinh nghiệm của mình | ⚠ anh là người dày dạn nhất — ý kiến của anh có giá trị | | ⚠ Kết luận | ⚠ thay đổi luật chơi thì hiệu quả hơn nhiều so với thay đổi một con người |

⚠ Nguyên tắc điều phối: ⚠ khi một hành vi lặp lại trong các buổi họp, hãy sửa THIẾT KẾ của buổi họp trước khi sửa người ⚠ — ⚠ phần lớn tình trạng một người nói át là hệ quả của việc không có cấu trúc chứ không phải của ý đồ xấu.

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

• B (nói chuyện trước với Bob về việc tôn trọng đồng đội và đừng nói quá nhiều) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trao đổi riêng và thẳng thắn thường là lời khuyên đúng trong đề PMP, và nó nghe rất trưởng thành: ⚠ nhưng ⚠ nó biến một vấn đề về THIẾT KẾ CUỘC HỌP thành một lời phê bình về TÍNH CÁCH ⚠ — ⚠ Bob chưa làm gì sai: anh nhiệt tình và có nhiều kinh nghiệm để chia sẻ; ⚠ và nó có nguy cơ làm anh im lặng hẳn, mất đi đúng người hiểu biết nhất trong phòng; ⚠ cuộc trò chuyện riêng có thể cần, nhưng nó là bước sau nếu cấu trúc không đủ.

• C (giới hạn mỗi lần phát biểu của anh không quá hai phút) — ⚠ luật riêng cho một người; ⚠ vừa lộ liễu vừa khó thực thi, và nó nói với cả phòng rằng Bob là vấn đề.

• D (không mời Bob dự hội thảo) — ⚠ loại bỏ người có nhiều kinh nghiệm nhất; ⚠ vừa mất chuyên môn vừa phá quan hệ, và gần như luôn là phương án sai trong đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26688 lô 199 (viết thầm — kỹ thuật chống hiệu ứng neo), ⚠ #26722 lô 199 (trò chơi cộng tác), ⚠ #26758 cùng lô (ghi nhớ tương lai), ⚠ #26742 cùng lô (giữ buổi họp trong khung giờ), ⚠ #26769 cùng lô (thu thập ý kiến từ mọi người).

⚠ CÁC KỸ THUẬT ĐIỀU PHỐI chống tình trạng một người nói át: | Kỹ thuật | Cách hoạt động | |---|---| | ⚠ VÒNG TRÒN (round robin) | ⚠ lần lượt từng người, ai cũng có lượt — ĐÁP ÁN | | ⚠ VIẾT THẦM (quiet writing) | ⚠ ai cũng viết trước khi ai kịp ảnh hưởng tới ai — liên hệ #26688 lô 199 | | ⚠ NHÓM DANH NGHĨA | ⚠ sinh ý tưởng riêng rồi bỏ phiếu | | ⚠ DELPHI | ⚠ ẩn danh nhiều vòng, chống ảnh hưởng của người có uy tín | | ⚠ Chia nhóm nhỏ rồi báo cáo lại | ⚠ giảm số người trong mỗi cuộc trò chuyện | | ⚠ Người điều phối trung lập | ⚠ có quyền cắt lời một cách lịch sự | | ⚠ Điểm chung | ⚠ tất cả đều thay đổi CẤU TRÚC của cuộc trò chuyện thay vì yêu cầu con người tự kiềm chế — vì tự kiềm chế là thứ rất khó duy trì khi người ta thật sự hào hứng với chủ đề |

⚠ Vì sao việc Bob nói nhiều là vấn đề thật: | Hậu quả | Nội dung | |---|---| | ⚠ HIỆU ỨNG NEO | ⚠ ý kiến của người nói đầu và nói nhiều định hình cả cuộc thảo luận | | ⚠ Người ít kinh nghiệm hơn ngại lên tiếng | ⚠ và họ thường là người gần công việc nhất — liên hệ #26682 lô 198 | | ⚠ Nhóm mất tính đa dạng của ý tưởng | | | ⚠ Quyết định trông như đồng thuận nhưng thực ra là sự im lặng | ⚠ liên hệ #26722 lô 199 | | ⚠ Điều Lauren làm đúng | ⚠ cô nhận ra vấn đề TRƯỚC buổi hội thảo và thiết kế cách phòng ngừa, thay vì cố xoay xở giữa buổi — đó chính là công việc của người điều phối |

⚠ Cách chạy một vòng tròn cho hiệu quả: | Việc | Nội dung | |---|---| | ⚠ Nói rõ luật chơi từ đầu | ⚠ để không ai cảm thấy bị nhắm tới giữa chừng | | ⚠ Cho phép "bỏ lượt" | ⚠ không ép người chưa có ý kiến phải nói | | ⚠ Giới hạn thời gian mỗi lượt, áp dụng cho tất cả | | | ⚠ Ghi lại ý kiến ở nơi ai cũng thấy | ⚠ liên hệ #26714 lô 199 | | ⚠ Sau vòng đầu mới mở thảo luận tự do | ⚠ khi đó mọi ý kiến đã có mặt trên bàn | | ⚠ Kết hợp mạnh nhất | ⚠ viết thầm trước, rồi vòng tròn để chia sẻ — cách này vừa chống hiệu ứng neo vừa bảo đảm ai cũng được nghe, và nó chỉ tốn thêm năm phút so với một cuộc thảo luận tự do |

Từ khoá nhận diện:

"một người nói quá nhiều trong hội thảo" → ⚠ VÒNG TRÒN — sửa cấu trúc, không sửa người "nói riêng về việc đừng nói nhiều" → ⚠ biến vấn đề thiết kế thành lời phê bình tính cách "giới hạn hai phút cho riêng anh ấy" → ⚠ luật riêng, lộ liễu "không mời" → ⚠ mất người hiểu biết nhất, gần như luôn sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong buổi họp gần nhất, một người chiếm bao nhiêu phần thời gian nói | | | Có ai chưa từng phát biểu trong ba buổi liên tiếp không | | | Buổi họp của bạn có cấu trúc hay chỉ có chương trình | ⚠ hai thứ đó khác nhau |

Và điều mà một luật chơi đơn giản làm được mà một cuộc trò chuyện tế nhị không làm nổi: nó cho những người vẫn im lặng một lý do chính đáng để lên tiếng, thay vì đòi người đang nói phải tự thấy mình nói quá nhiều.

Đáp án

A — KIỂM SOÁT MUA SẮM (control procurements).

Vì sao đúng

⚠ Chi tiết quyết định: công việc do NHÀ THẦU thực hiện: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Công việc mộc bên ngoài do NHÀ THẦU CHUYÊN NGÀNH làm | ⚠ đây là công việc thuộc hợp đồng | | ⚠ Nhà thầu đã hoàn thành 35% khối lượng | ⚠ hợp đồng đang được thực hiện | | ⚠ Thay đổi phạm vi đã được ban kiểm soát thay đổi DUYỆT | ⚠ bước phê duyệt đã xong | | ⚠ Câu hỏi: thay đổi được THỰC HIỆN ở quy trình nào | ⚠ thực hiện, không phải phê duyệt | | ⚠ Kết luận | ⚠ thay đổi tác động tới công việc của nhà thầu thì được quản lý qua quy trình kiểm soát mua sắm |

⚠ Kiểm soát mua sắm là nơi các thay đổi hợp đồng được quản lý và thực hiện: ⚠ nó bao gồm việc quản trị hợp đồng, giám sát hiệu năng nhà thầu, xử lý yêu cầu thay đổi và ký các sửa đổi ⚠ — ⚠ liên hệ #26738 cùng lô về hệ thống kiểm soát thay đổi hợp đồng.

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

• D (chỉ đạo và quản lý công việc dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đây là quy trình chuẩn để THỰC HIỆN các thay đổi đã duyệt, và trong đa số câu hỏi PMP thì đó chính là đáp án: ⚠ nhưng ⚠ nó áp dụng cho công việc do CHÍNH ĐỘI DỰ ÁN thực hiện ⚠ — ⚠ ở đây công việc thuộc về nhà thầu, và mọi thứ liên quan tới hợp đồng đều đi qua kênh mua sắm; ⚠ đây là dạng bẫy "câu trả lời đúng trong trường hợp chung, sai trong trường hợp cụ thể mà đề vừa mô tả".

• B (kiểm soát phạm vi) — ⚠ là quy trình GIÁM SÁT phạm vi và theo dõi thay đổi; ⚠ nó phát hiện và theo dõi, nhưng không phải nơi thay đổi được thực hiện.

• C (lập kế hoạch quản lý phạm vi) — ⚠ thuộc nhóm LẬP KẾ HOẠCH, diễn ra từ đầu dự án; ⚠ hoàn toàn sai giai đoạn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi — câu GẦN TRÙNG: ⚠ #26794 lô 201 lặp lại gần như nguyên vẹn cấu trúc của câu này ⚠ — ⚠ ở đó là nhà thầu phun cát và sơn một cầu nâng, đã hoàn thành 55%, cũng có thay đổi phạm vi được ban kiểm soát thay đổi duyệt, và cũng hỏi thay đổi được THỰC HIỆN ở quy trình nào; ⚠ KHOÁ CỦA HAI CÂU NHẤT QUÁN — đều là kiểm soát mua sắm, nên không có mâu thuẫn nào; ⚠ nhưng THỨ TỰ PHƯƠNG ÁN bị xáo: ở câu này kiểm soát mua sắm là phương án A, ở #26794 nó là phương án D — hãy học nội dung, đừng học chữ cái.

⚠ Đối chiếu: ⚠ #26794 lô 201 (CÂU GẦN TRÙNG — cùng khoá), ⚠ #26738 cùng lô (cập nhật thoả thuận qua hệ thống kiểm soát thay đổi hợp đồng), ⚠ #26739 cùng lô (kiểm soát thay đổi tích hợp), ⚠ #26705 lô 199 (cắt phạm vi khi hợp đồng đã ký), ⚠ #26684 lô 199 (thẩm quyền mua sắm), ⚠ #26747 cùng lô (quản lý phạm vi).

⚠ Vòng đời của một thay đổi — ai làm gì ở đâu: | Giai đoạn | Quy trình | |---|---| | ⚠ Phát hiện nhu cầu thay đổi | ⚠ bất kỳ quy trình giám sát nào — ở đây là kiểm soát phạm vi | | ⚠ Lập yêu cầu thay đổi | ⚠ quy trình phát hiện ra nó | | ⚠ PHÊ DUYỆT | ⚠ KIỂM SOÁT THAY ĐỔI TÍCH HỢP — đã xong trong đề | | ⚠ THỰC HIỆN (công việc của đội) | ⚠ chỉ đạo và quản lý công việc dự án — phương án D | | ⚠ THỰC HIỆN (công việc của nhà thầu) | ⚠ KIỂM SOÁT MUA SẮM — ĐÁP ÁN | | ⚠ Kiểm chứng kết quả | ⚠ kiểm soát chất lượng rồi xác nhận phạm vi | | ⚠ Câu hỏi phân định | ⚠ "ai làm công việc bị ảnh hưởng" — đội mình hay bên ngoài; đó là toàn bộ sự khác nhau giữa hai phương án cuối |

⚠ KIỂM SOÁT MUA SẮM gồm những gì: | Hoạt động | Nội dung | |---|---| | ⚠ Quản trị việc thực hiện hợp đồng | ⚠ theo dõi nhà thầu có làm đúng cam kết không | | ⚠ Xử lý và thực hiện các thay đổi hợp đồng | ⚠ ĐÁP ÁN — trường hợp của Ahmed | | ⚠ Giám sát hiệu năng của nhà thầu | ⚠ báo cáo, kiểm tra, nghiệm thu từng phần | | ⚠ Quản lý thanh toán | ⚠ liên hệ #26684 lô 199 | | ⚠ Xử lý khiếu nại và tranh chấp | | | ⚠ Lưu hồ sơ hợp đồng | | | ⚠ Điều Ahmed cần làm cụ thể | ⚠ thông báo chính thức cho nhà thầu, thống nhất giá và thời gian cho phần việc thay đổi, ký phụ lục sửa đổi, cập nhật đường cơ sở và theo dõi việc thực hiện — không có bước nào trong số đó nằm ngoài quy trình mua sắm |

⚠ Vì sao mốc 35% khối lượng là chi tiết đáng chú ý: | Ý nghĩa | Nội dung | |---|---| | ⚠ Nhà thầu đã đầu tư đáng kể vào cách làm hiện tại | ⚠ vật tư, nhân công, kế hoạch | | ⚠ Thay đổi có thể ảnh hưởng phần đã làm | ⚠ cần đánh giá xem có phải làm lại không | | ⚠ Còn 65% để hấp thụ thay đổi | ⚠ thời điểm vẫn còn tương đối thuận lợi | | ⚠ Nguồn gốc thay đổi là hướng dẫn của hội đồng thành phố | ⚠ yêu cầu tuân thủ, không thương lượng được — liên hệ #26706 lô 199 | | ⚠ Nhận xét | ⚠ thay đổi vì lý do tuân thủ luôn phải được thực hiện, nên câu hỏi duy nhất còn lại là chi phí và thời gian bao nhiêu — và đó chính xác là những gì được thương lượng trong quy trình kiểm soát mua sắm |

Từ khoá nhận diện:

"thay đổi ảnh hưởng công việc của NHÀ THẦU" → ⚠ KIỂM SOÁT MUA SẮM "thay đổi ảnh hưởng công việc của ĐỘI" → ⚠ chỉ đạo và quản lý công việc dự án "phê duyệt thay đổi" → ⚠ kiểm soát thay đổi tích hợp "lập kế hoạch quản lý phạm vi" → ⚠ sai giai đoạn hoàn toàn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thay đổi gần nhất của bạn có ảnh hưởng tới nhà thầu nào không | | | Nếu có, nó đã được đưa vào hợp đồng bằng văn bản chưa | | | Ai theo dõi việc nhà thầu thực hiện đúng thay đổi đó | |

Và điều mà một thay đổi được đưa đúng kênh bảo đảm: nhà thầu nhận được một chỉ dẫn có hiệu lực chứ không phải một tin nhắn thân thiện — và ba tháng sau, khi thanh toán, không ai phải tranh cãi xem phần việc thêm ấy có được đặt hàng hay không.

Đáp án

B — CÔNG TY ĐỐI THỦ CŨNG DỰ THẦU DỰ ÁN NÀY.

Vì sao đúng

⚠ Câu hỏi phủ định — ai là bên liên quan cần theo dõi: | Nhóm | Có phải bên liên quan của dự án không | |---|---| | ⚠ A — nhà cung cấp xi măng | ⚠ CÓ — nguồn cung ảnh hưởng trực tiếp tới tiến độ và chi phí | | ⚠ B — CÔNG TY ĐỐI THỦ ĐÃ THUA THẦU | ⚠ KHÔNG — ĐÁP ÁN | | ⚠ C — quan chức thành phố nơi xây cầu | ⚠ CÓ — cấp phép, quy định, chính trị địa phương | | ⚠ D — người dân trong vùng | ⚠ CÓ — bị ảnh hưởng trực tiếp, có thể phản đối |

⚠ Vì sao đối thủ thua thầu không còn là bên liên quan: ⚠ gói thầu ĐÃ ĐƯỢC TRAO cho Benji — công ty kia không còn vai trò gì, không cung cấp gì, không phê duyệt gì và không chịu tác động gì từ cây cầu ⚠ — ⚠ họ là đối thủ trên thị trường, nhưng bên liên quan của MỘT DỰ ÁN được định nghĩa bằng việc có ẢNH HƯỞNG TỚI hoặc CHỊU ẢNH HƯỞNG TỪ dự án đó.

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

• D (người dân trong vùng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ người dân không ký hợp đồng nào, không cấp phép gì, và nhiều người quen nghĩ bên liên quan là những ai có vai trò chính thức trong dự án: ⚠ nhưng ⚠ đề nói rõ dự án "ẢNH HƯỞNG TỚI PHẦN LỚN cư dân trong cộng đồng" ⚠ — ⚠ và một dự án hạ tầng công cộng bị người dân phản đối có thể bị đình trệ hoàn toàn, bất kể hợp đồng đã ký; ⚠ họ là nhóm cần theo dõi sát nhất chứ không phải nhóm được bỏ qua, liên hệ #26642 lô 198.

• A (nhà cung cấp xi măng) — ⚠ rủi ro chuỗi cung ứng là rủi ro hàng đầu của dự án xây dựng; ⚠ giá và tiến độ giao hàng biến động sẽ tác động trực tiếp.

• C (quan chức thành phố) — ⚠ giấy phép, kiểm định, quy định — họ có quyền dừng dự án; ⚠ liên hệ #26761 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26687 lô 199 (mô hình nổi bật để phân loại bên liên quan), ⚠ #26731 lô 199 (gắn kết bên liên quan từ đầu), ⚠ #26780 cùng lô (bên liên quan hoài nghi), ⚠ #26642 lô 198 (công chúng hiểu sai về dự án), ⚠ #26727 lô 199 (mối quan tâm khác nhau của từng nhóm).

⚠ Định nghĩa BÊN LIÊN QUAN — hai chiều: | Chiều | Nội dung | |---|---| | ⚠ Có thể ẢNH HƯỞNG TỚI dự án | ⚠ nhà cung cấp, cơ quan cấp phép, nhà tài trợ | | ⚠ CHỊU ẢNH HƯỞNG TỪ dự án | ⚠ người dân, người dùng cuối, cộng đồng | | ⚠ Hoặc TỰ CHO RẰNG mình bị ảnh hưởng | ⚠ định nghĩa của PMBOK bao gồm cả điều này | | ⚠ Vì sao vế thứ ba quan trọng | ⚠ một nhóm tin rằng mình bị ảnh hưởng sẽ hành động y như thể họ thật sự bị ảnh hưởng — và với dự án hạ tầng công cộng thì đó thường là nguồn phản đối lớn nhất |

⚠ Bên liên quan của một dự án xây cầu công cộng: | Nhóm | Mối quan tâm | |---|---| | ⚠ Chính quyền thành phố | ⚠ giấy phép, an toàn, ngân sách công, tiến độ | | ⚠ Người dân trong vùng | ⚠ tiếng ồn, giao thông tắc, giá trị bất động sản, thời gian thi công | | ⚠ Người sử dụng cầu cũ | ⚠ lộ trình thay thế trong lúc thi công | | ⚠ Nhà cung cấp vật tư | ⚠ hợp đồng, lịch giao, thanh toán | | ⚠ Cơ quan môi trường | ⚠ tác động tới dòng sông và hệ sinh thái | | ⚠ Báo chí địa phương | ⚠ liên hệ #26687 lô 199 — nhóm có tiếng nói nhưng ít tư cách chính danh | | ⚠ Nhóm hay bị bỏ sót nhất | ⚠ người dân — vì họ không có mặt trong bất kỳ cuộc họp chính thức nào cho tới ngày họ xuất hiện ở cuộc họp hội đồng thành phố để phản đối |

⚠ Đối thủ cạnh tranh — khi nào thì đáng theo dõi: | Tình huống | Có phải bên liên quan không | |---|---| | ⚠ Đã thua thầu, không còn vai trò gì | ⚠ KHÔNG — trường hợp của đề | | ⚠ Là nhà thầu phụ trong chính dự án | ⚠ CÓ | | ⚠ Khiếu nại kết quả đấu thầu | ⚠ CÓ, tạm thời — nhưng đề không nói tới việc này | | ⚠ Ra sản phẩm cạnh tranh ảnh hưởng trường hợp kinh doanh | ⚠ có thể là RỦI RO của dự án, vẫn không phải bên liên quan | | ⚠ Phân biệt cần nhớ | ⚠ đối thủ là mối quan tâm của chiến lược DOANH NGHIỆP, không phải của quản lý bên liên quan trong một DỰ ÁN — trừ khi họ có vai trò cụ thể trong chính dự án đó |

Từ khoá nhận diện:

"đối thủ đã thua thầu" → ⚠ KHÔNG còn là bên liên quan của dự án "người dân bị ảnh hưởng" → ⚠ LÀ bên liên quan, thường là nhóm quan trọng nhất "nhà cung cấp, cơ quan cấp phép" → ⚠ đều là bên liên quan định nghĩa → ⚠ ảnh hưởng tới, chịu ảnh hưởng từ, hoặc TIN rằng mình bị ảnh hưởng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký bên liên quan của bạn có nhóm nào không có vai trò chính thức không | ⚠ nếu không có, có thể bạn đang bỏ sót | | Ai là người có thể dừng dự án của bạn mà bạn chưa từng nói chuyện | | | Có nhóm nào TIN rằng họ bị ảnh hưởng dù thực tế không không | |

Và điều mà một dự án hạ tầng công cộng thường học được theo cách đắt đỏ nhất: hợp đồng được ký với chính quyền, nhưng dự án được cho phép tiếp tục bởi những người sống cạnh công trường — và họ không có mặt trong bất kỳ cuộc họp nào cho tới lúc đã quá muộn để lắng nghe.