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

Đáp án

D — Rủi ro phải được RÀ SOÁT VÀ CẬP NHẬT LIÊN TỤC trong suốt dự án.

Vì sao đúng

⚠ Vì sao quản lý rủi ro là hoạt động lặp lại: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro MỚI xuất hiện khi dự án tiến triển | ⚠ thứ tuần trước chưa tồn tại thì tuần này có thể có | | ⚠ Rủi ro CŨ đổi xác suất và tác động | ⚠ một số biến mất, một số lớn lên | | ⚠ Ứng phó đã thực hiện để lại RỦI RO TỒN DƯ | ⚠ liên hệ #26462 lô 194 | | ⚠ Bối cảnh bên ngoài thay đổi | ⚠ liên hệ #26480 lô 194 — chính phủ mới | | ⚠ Dự án đang có nguy cơ vượt chi 10.000 đô | ⚠ thêm một lý do rất cụ thể để rà lại ngay lúc này | | ⚠ Kết luận | ⚠ lập kế hoạch rủi ro ban đầu là điểm KHỞI ĐẦU, không phải điểm kết thúc |

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

• A (ban chỉ đạo lo dự án vượt ngân sách) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đề CÓ nói dự án có nguy cơ vượt 10.000 đô, nên nghe như đúng nguyên nhân: ⚠ nhưng ⚠ nó biến một THỰC HÀNH CHUẨN thành phản ứng trước áp lực cấp trên ⚠ — Tanya rà soát rủi ro vì đó là việc phải làm đều đặn, không phải vì bị ai thúc; ⚠ trả lời như vậy còn dạy Thomas một bài học sai: rằng quản lý rủi ro là việc làm khi có người hỏi.

• B (Tanya đã trích dự phòng bất trắc cho việc rà soát rủi ro) — ⚠ hiểu sai dự phòng: ⚠ dự phòng dành cho tác động của rủi ro, không dành để trả tiền cho một cuộc họp.

• C (dự án còn dự trữ thời gian nên Tanya muốn dùng) — ⚠ dự trữ thời gian không phải để lấp bằng họp; ⚠ và không liên quan gì tới lý do rà soát rủi ro.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26322 lô 191 (nhận diện rủi ro diễn ra SUỐT dự án — câu gần như song sinh với câu này), ⚠ #26359 lô 192 (nhận diện bên liên quan cũng lặp lại), ⚠ #26462 lô 194 (rủi ro tồn dư), ⚠ #26480 lô 194 (theo dõi rủi ro chưa thành hình), ⚠ #26501 cùng lô (chia sẻ tri thức cũng diễn ra suốt dự án — cùng một mô-típ đáp án).

⚠ Mô-típ đáng nhớ của đề PMP: ⚠ khi bốn phương án gồm ba mốc thời điểm cụ thể và một phương án "liên tục / suốt dự án", phương án "liên tục" thắng gần như mọi lần ⚠ — điều này đúng với nhận diện rủi ro, nhận diện bên liên quan, chia sẻ tri thức, bài học kinh nghiệm, và giao tiếp.

⚠ SÁU quy trình quản lý rủi ro và nhịp độ của chúng: | Quy trình | Nhóm | Nhịp | |---|---|---| | ⚠ Lập kế hoạch quản lý rủi ro | ⚠ Lập kế hoạch | ⚠ một lần, cập nhật khi cần | | ⚠ Nhận diện rủi ro | ⚠ Lập kế hoạch | ⚠ LẶP LẠI suốt dự án | | ⚠ Phân tích định tính | ⚠ Lập kế hoạch | ⚠ lặp lại | | ⚠ Phân tích định lượng | ⚠ Lập kế hoạch | ⚠ lặp lại, cho rủi ro lớn | | ⚠ Lập kế hoạch ứng phó | ⚠ Lập kế hoạch | ⚠ lặp lại | | ⚠ Thực hiện ứng phó | ⚠ Thực thi | ⚠ khi cần | | ⚠ GIÁM SÁT rủi ro | ⚠ Giám sát và Kiểm soát | ⚠ liên tục — nơi việc rà soát của Tanya thuộc về | | ⚠ Nhận xét | ⚠ năm trong bảy quy trình nằm ở nhóm Lập kế hoạch, nhưng chúng KHÔNG chỉ chạy một lần ở đầu dự án — đó là điều Thomas đang hiểu nhầm | |

⚠ Rà soát rủi ro nên diễn ra khi nào: | Thời điểm | Nội dung | |---|---| | ⚠ Theo LỊCH ĐỊNH KỲ | ⚠ hằng tuần hoặc mỗi vòng lặp | | ⚠ Ở mỗi MỐC hoặc cổng giai đoạn | | | ⚠ Khi có THAY ĐỔI LỚN về phạm vi, đội, hoặc bối cảnh | | | ⚠ Khi một rủi ro XẢY RA | ⚠ để tìm rủi ro thứ cấp và rủi ro tồn dư | | ⚠ Khi chỉ số hiệu năng xấu đi | ⚠ đúng tình huống của dự án này | | ⚠ Nội dung buổi rà soát | ⚠ rủi ro nào đã đóng, rủi ro nào đổi mức, có rủi ro mới nào, ứng phó đã lập còn phù hợp không, dự phòng còn đủ không |

⚠ Câu trả lời Tanya nên nói với Thomas: | Ý | Nội dung | |---|---| | ⚠ Kế hoạch rủi ro ban đầu dựa trên những gì ta BIẾT lúc đó | | | ⚠ Mười tuần đã trôi qua và ta biết nhiều hơn | | | ⚠ Sổ đăng ký rủi ro là tài liệu SỐNG, không phải tài liệu lưu trữ | | | ⚠ Việc nguy cơ vượt chi xuất hiện chính là bằng chứng cho điều đó | ⚠ một rủi ro đang lớn lên | | ⚠ Giá trị của cách trả lời này | ⚠ nó biến một câu hỏi của người mới thành một bài học nghề — và đó là việc kèm cặp, liên hệ #26455 lô 194 về tri thức ẩn |

Từ khoá nhận diện:

"vì sao lại rà soát rủi ro lần nữa" → ⚠ RỦI RO PHẢI ĐƯỢC RÀ SOÁT LIÊN TỤC "vì cấp trên đang lo lắng" → ⚠ biến thực hành chuẩn thành phản ứng bị động "dùng dự phòng để họp" → ⚠ hiểu sai bản chất dự phòng phương án "suốt dự án / liên tục" → ⚠ mô-típ đáp án rất mạnh trong đề PMP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký rủi ro của bạn cập nhật lần cuối khi nào | ⚠ quá một tháng là nó đã thành tài liệu lưu trữ | | Có rủi ro nào trong sổ đã hết ý nghĩa mà vẫn nằm đó không | | | Rủi ro mới nhất bạn ghi vào sổ là khi nào | ⚠ không có rủi ro mới trong nhiều tuần thường nghĩa là không ai đang nhìn |

Và điều mà một sổ đăng ký rủi ro không được cập nhật thật sự chứng minh: không phải dự án đã hết rủi ro, mà là đội đã ngừng tìm — và hai điều đó trông giống hệt nhau trên giấy tờ.

Đáp án

C — NÉ TRÁNH (avoid).

Vì sao đúng

⚠ Vì sao đây là chiến lược né tránh: | Đặc điểm của né tránh | Có trong tình huống | |---|---| | ⚠ Loại bỏ HOÀN TOÀN nguy cơ, đưa xác suất về 0 | ⚠ Robert không vào đội thì rủi ro anh gây mất tinh thần không tồn tại | | ⚠ Thường bằng cách ĐỔI KẾ HOẠCH | ⚠ Sharon đổi phương án phân bổ nguồn lực | | ⚠ Áp dụng cho rủi ro TIÊU CỰC | ⚠ rủi ro về tinh thần đội | | ⚠ Hành động diễn ra TRƯỚC khi rủi ro có cơ hội xảy ra | ⚠ cô quyết ngay ở khâu lập kế hoạch nguồn lực | | ⚠ Kết luận | ⚠ loại bỏ nguyên nhân chứ không giảm hậu quả — đó là ranh giới với giảm nhẹ |

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

• A (GIẢM NHẸ — mitigate) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hai chiến lược này luôn đứng cạnh nhau và đều nhằm làm rủi ro bớt nguy hiểm: ⚠ nhưng ⚠ giảm nhẹ là LÀM GIẢM xác suất hoặc tác động, chứ rủi ro VẪN CÒN ⚠ — nếu Sharon nhận Robert nhưng ghép anh với một người kèm cặp, hoặc giao anh việc làm độc lập, thì đó mới là giảm nhẹ; ⚠ ở đây cô loại hẳn nguồn gốc rủi ro, nên là né tránh.

• B (CHUYỂN GIAO — transfer) — ⚠ là đẩy trách nhiệm và hậu quả sang bên thứ ba (bảo hiểm, thuê ngoài, hợp đồng); ⚠ rủi ro vẫn tồn tại, chỉ đổi chủ.

• D (CHẤP NHẬN — accept) — ⚠ là quyết định KHÔNG hành động; ⚠ trái hẳn với việc Sharon đã chủ động đổi kế hoạch.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ quyết định của Sharon dựa trên TIN ĐỒN ("cô nghe nói Robert gây rối") ⚠ — ⚠ về mặt phân loại chiến lược thì đây vẫn là né tránh, và đó là điều đề hỏi; ⚠ nhưng về mặt thực hành quản lý con người, loại một người khỏi dự án dựa trên tin nghe được mà không kiểm chứng là cách làm đáng ngờ, ⚠ đối lập trực tiếp với #26482 lô 194 — nơi đáp án đúng là nói chuyện với chính đương sự thay vì hành động dựa trên lời của người khác. ⚠ Hai câu này không mâu thuẫn về khoá đáp án (một câu hỏi tên chiến lược, một câu hỏi hành động đúng), nhưng đọc cạnh nhau là một bài học tốt.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26438 lô 194 (mất dịch vụ 2 giờ sáng chủ nhật = giảm nhẹ), ⚠ #26462 lô 194 (rủi ro tồn dư), ⚠ #26493 cùng lô (rà soát rủi ro liên tục), ⚠ #26482 lô 194 (nói chuyện với đương sự trước), ⚠ #26469 lô 194 (rối loạn của đội).

⚠ NĂM CHIẾN LƯỢC cho rủi ro TIÊU CỰC: | Chiến lược | Nội dung | Ví dụ | |---|---|---| | ⚠ NÉ TRÁNH | ⚠ loại bỏ nguy cơ, xác suất về 0 | ⚠ không đưa Robert vào đội — câu này | | ⚠ GIẢM NHẸ | ⚠ giảm xác suất hoặc tác động, rủi ro vẫn còn | ⚠ nhận Robert nhưng có người kèm cặp | | ⚠ CHUYỂN GIAO | ⚠ đẩy hậu quả sang bên thứ ba | ⚠ bảo hiểm, thuê ngoài, hợp đồng giá cố định | | ⚠ CHẤP NHẬN | ⚠ không hành động; chủ động thì lập dự phòng, thụ động thì chỉ ghi nhận | ⚠ rủi ro nhỏ, chi phí xử lý lớn hơn tác động | | ⚠ LEO THANG | ⚠ rủi ro vượt thẩm quyền dự án | ⚠ liên hệ #26442 lô 194 | | ⚠ Ranh giới hay hỏi nhất | ⚠ NÉ TRÁNH so với GIẢM NHẸ — hỏi "rủi ro còn tồn tại không?" Còn thì giảm nhẹ, hết thì né tránh | |

⚠ Năm chiến lược ĐỐI XỨNG cho rủi ro TÍCH CỰC (cơ hội): | Rủi ro tiêu cực | Cơ hội | Nghĩa | |---|---|---| | ⚠ Né tránh | ⚠ KHAI THÁC (exploit) | ⚠ làm cho chắc chắn xảy ra — xác suất về 100% | | ⚠ Giảm nhẹ | ⚠ TĂNG CƯỜNG (enhance) | ⚠ tăng xác suất hoặc tác động | | ⚠ Chuyển giao | ⚠ CHIA SẺ (share) | ⚠ hợp tác với bên có khả năng nắm bắt tốt hơn | | ⚠ Chấp nhận | ⚠ CHẤP NHẬN | ⚠ giống nhau ở cả hai phía | | ⚠ Leo thang | ⚠ LEO THANG | ⚠ cũng giống nhau — liên hệ #26442 lô 194 | | ⚠ Mẹo nhớ | ⚠ hai cột đối xứng từng cặp; chấp nhận và leo thang dùng chung tên cho cả hai phía | |

⚠ Cái giá của việc né tránh — thứ đề không nói: | Cái giá | Nội dung | |---|---| | ⚠ Mất đi năng lực của Robert | ⚠ anh vẫn là một lập trình viên, và dự án phần mềm y tế cần người | | ⚠ Quyết định dựa trên thông tin CHƯA KIỂM CHỨNG | ⚠ có thể Robert đã thay đổi, hoặc vấn đề nằm ở đội cũ | | ⚠ Tạo tiền lệ: tin đồn đủ để loại một người | | | ⚠ Không giải quyết vấn đề, chỉ chuyển nó sang dự án khác | | | ⚠ Nhận xét cân bằng | ⚠ né tránh luôn có giá — nó thường đòi bỏ một phương án nào đó; đúng đắn của nó phụ thuộc vào việc cái giá đó có nhỏ hơn rủi ro hay không, và Sharon nên KIỂM CHỨNG trước khi kết luận |

Từ khoá nhận diện:

"loại bỏ hẳn nguồn gốc, rủi ro không còn" → ⚠ NÉ TRÁNH "vẫn làm nhưng giảm xác suất/tác động" → ⚠ giảm nhẹ "bảo hiểm, thuê ngoài" → ⚠ chuyển giao "biết mà không làm gì" → ⚠ chấp nhận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng phó gần nhất của bạn là né tránh hay giảm nhẹ | ⚠ hỏi: sau khi làm xong, rủi ro còn không | | Bạn có tính cái giá của việc né tránh không | ⚠ phương án bị bỏ đi cũng có giá trị | | Quyết định loại trừ ai đó của bạn dựa trên bằng chứng gì | |

Và điều làm né tránh trở thành chiến lược quyến rũ nhất trong năm: nó là chiến lược duy nhất cho bạn cảm giác vấn đề đã biến mất — trong khi thứ thật sự biến mất chỉ là phần của vấn đề nằm trong tầm nhìn của bạn.

Đáp án

B — YÊU CẦU NGUỒN LỰC (resource requirements).

Vì sao đúng

⚠ Vì sao đây là yêu cầu nguồn lực: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Cần MỘT GIẢNG VIÊN — một loại nguồn lực cụ thể | ⚠ nguồn lực con người có kỹ năng xác định | | ⚠ Trong THỜI GIAN xác định: năm tháng | ⚠ yêu cầu nguồn lực luôn gồm cả LƯỢNG và THỜI GIAN | | ⚠ Ở ĐỊA ĐIỂM xác định: cơ sở của khách hàng | ⚠ thuộc tính của nguồn lực cần có | | ⚠ Xuất phát từ nội dung công việc phải làm | ⚠ lớp học cả ngày cho toàn bộ nhân viên khách hàng | | ⚠ Kết luận | ⚠ đây là mô tả CÁI GÌ CẦN ĐỂ LÀM VIỆC — đúng định nghĩa yêu cầu nguồn lực |

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

• C (một VẤN ĐỀ NHÂN SỰ — human resource issue) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ giảng viên đúng là nguồn lực con người, và tìm người cho năm tháng nghe rất giống một bài toán nhân sự: ⚠ nhưng ⚠ "vấn đề" (issue) trong PMP có nghĩa hẹp: một trở ngại ĐANG XẢY RA cần xử lý ⚠ — ở đây chưa có trở ngại nào; ⚠ Nayeem mới đang xác định nhu cầu, và nhu cầu chưa được đáp ứng thì không phải là vấn đề — nó chỉ là yêu cầu.

• A (RÀNG BUỘC CHI PHÍ) — ⚠ đề không nhắc tới giới hạn ngân sách nào; ⚠ nguồn lực này sẽ tốn tiền, nhưng đó không phải điều đề mô tả.

• D (GIẢ ĐỊNH) — ⚠ giả định là điều ta CHO LÀ ĐÚNG mà chưa chứng minh; ⚠ nhu cầu về giảng viên là một sự thật rút ra từ phạm vi công việc, không phải một phỏng đoán.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26487 cùng lô (thoả ước lao động — ràng buộc lên việc dùng nguồn lực), ⚠ #26502 cùng lô (đầu vào của ước lượng thời lượng), ⚠ #26492 cùng lô (ước lượng thời lượng), ⚠ #26465 lô 194 (ràng buộc so với phụ thuộc), ⚠ #26449 lô 194 (ngân sách đào tạo).

⚠ BỐN khái niệm hay bị lẫn — bảng phân biệt: | Khái niệm | Nghĩa | Ví dụ | |---|---|---| | ⚠ YÊU CẦU NGUỒN LỰC | ⚠ CÁI GÌ cần để làm việc: loại, lượng, thời gian | ⚠ một giảng viên trong năm tháng — câu này | | ⚠ RÀNG BUỘC | ⚠ GIỚI HẠN áp lên dự án | ⚠ ngân sách tối đa, hạn chót, thoả ước lao động | | ⚠ GIẢ ĐỊNH | ⚠ điều cho là đúng mà chưa kiểm chứng | ⚠ "khách hàng sẽ bố trí được phòng học" | | ⚠ VẤN ĐỀ (issue) | ⚠ trở ngại ĐANG xảy ra | ⚠ "giảng viên đã nhận việc rồi báo bận" | | ⚠ Mẹo phân biệt | ⚠ yêu cầu = CẦN GÌ; ràng buộc = KHÔNG ĐƯỢC LÀM GÌ; giả định = TIN LÀ GÌ; vấn đề = ĐANG HỎNG GÌ | |

⚠ Yêu cầu nguồn lực gồm những thành phần nào: | Thành phần | Trong tình huống này | |---|---| | ⚠ LOẠI nguồn lực | ⚠ giảng viên — nguồn lực con người | | ⚠ SỐ LƯỢNG | ⚠ một người | | ⚠ KỸ NĂNG cần có | ⚠ giảng dạy được nội dung, ra và chấm bài đánh giá | | ⚠ KHOẢNG THỜI GIAN cần | ⚠ năm tháng | | ⚠ ĐỊA ĐIỂM | ⚠ cơ sở của khách hàng — ảnh hưởng tới chi phí đi lại và lưu trú | | ⚠ Đầu ra kèm theo | ⚠ CẤU TRÚC PHÂN RÃ NGUỒN LỰC (RBS) và LỊCH NGUỒN LỰC — hai tài liệu đi cùng yêu cầu nguồn lực |

⚠ Từ yêu cầu nguồn lực tới việc có được người: | Bước | Nội dung | |---|---| | ⚠ 1. Ước lượng nguồn lực hoạt động | ⚠ ra yêu cầu nguồn lực — bước của câu này | | ⚠ 2. Quyết định TỰ LÀM hay MUA | ⚠ giảng viên nội bộ hay thuê ngoài — liên hệ #26449 lô 194 | | ⚠ 3. Thu nhận nguồn lực | ⚠ thuộc nhóm Thực thi | | ⚠ 4. Xác nhận lịch sẵn có của người đó | ⚠ năm tháng liên tục là cam kết dài, dễ vỡ | | ⚠ 5. Lập phương án dự phòng | ⚠ giảng viên nghỉ ốm giữa chừng là rủi ro rất thật | | ⚠ Rủi ro nổi bật trong tình huống | ⚠ phụ thuộc vào MỘT cá nhân trong năm tháng là điểm hỏng đơn lẻ — nên có người thứ hai được đào tạo sẵn, đó là giảm nhẹ, liên hệ #26494 cùng lô |

Từ khoá nhận diện:

"cần loại người/thiết bị gì, bao nhiêu, trong bao lâu" → ⚠ YÊU CẦU NGUỒN LỰC "không được vượt quá, phải xong trước" → ⚠ ràng buộc "chúng ta cho rằng…" → ⚠ giả định "đang bị kẹt, cần xử lý ngay" → ⚠ vấn đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu nguồn lực của bạn có ghi rõ kỹ năng và thời gian không | ⚠ hay chỉ ghi số người | | Có vị trí nào chỉ một người làm được không | ⚠ đó là điểm hỏng đơn lẻ | | Bạn có lịch sẵn có của các nguồn lực chính không | |

Và lý do phân biệt bốn khái niệm này không phải chuyện chữ nghĩa: mỗi cái đi vào một tài liệu khác nhau và được xử lý bởi một quy trình khác nhau — gọi sai tên là ghi sai chỗ, và ghi sai chỗ nghĩa là không ai xử lý nó cả.

Đáp án

C — Làm quen với QUẢN LÝ DỰ ÁN AGILE nói chung.

Vì sao đúng

⚠ Vì sao đây là bước chuẩn bị đúng cho Darryl: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ CEO mới muốn công ty NHANH NHẸN, thích ứng nhanh | ⚠ đó chính là ngôn ngữ của agile | | ⚠ PMO bắt đầu thay đổi cách làm và nhân sự | ⚠ thay đổi đã bắt đầu, không còn là suy đoán | | ⚠ Darryl chỉ quen thác nước | ⚠ khoảng trống năng lực rõ ràng | | ⚠ Đề hỏi anh nên "am hiểu" điều gì để DỰ LIỆU thay đổi | ⚠ hỏi về việc chuẩn bị, không hỏi về việc đổi nghề | | ⚠ "Nói chung" là chi tiết quan trọng | ⚠ hiểu tư duy và các khung agile, không cam kết vào một khung cụ thể | | ⚠ Kết luận | ⚠ phản ứng tương xứng: mở rộng năng lực, không đảo lộn sự nghiệp |

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

• B (trở thành SCRUM MASTER) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ Scrum là khung agile phổ biến nhất, nên "học Scrum" nghe như hành động cụ thể và quyết đoán: ⚠ nhưng ⚠ nó QUÁ HẸP và QUÁ SỚM ⚠ — tổ chức chưa tuyên bố sẽ dùng Scrum, có thể là Kanban, SAFe, hoặc mô hình lai; ⚠ và đổi hẳn sang vai trò scrum master là đổi NGHỀ, trong khi Darryl vẫn là quản lý dự án — anh cần hiểu agile để dẫn dắt trong môi trường đó, không cần đổi danh xưng.

• A (đừng đổi, vì anh được tuyển vì kỹ năng hiện có) — ⚠ chống lại thay đổi khi bằng chứng đã rõ ràng; ⚠ đây là con đường ngắn nhất để trở nên lạc lõng.

• D (thạo Microsoft Project hơn vì đây là công ty lớn) — ⚠ đầu tư sâu hơn vào CÔNG CỤ CỦA THẾ GIỚI CŨ; ⚠ đi ngược hướng tổ chức đang đi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26463 lô 194 (hiện vật agile và thác nước), ⚠ #26475 lô 194 (môi trường lai agile–dự đoán), ⚠ #26472 lô 194 (điều chỉnh quy trình theo bối cảnh), ⚠ #26490 cùng lô (định nghĩa hoàn thành), ⚠ #26501 cùng lô (chia sẻ tri thức trong agile).

⚠ Vì sao "agile nói chung" đúng hơn một khung cụ thể: | Lý do | Nội dung | |---|---| | ⚠ Chưa biết tổ chức sẽ chọn khung nào | ⚠ Scrum, Kanban, XP, SAFe, LeSS, hay mô hình lai | | ⚠ Phần lớn tổ chức lớn dùng MÔ HÌNH LAI | ⚠ không bỏ hẳn thác nước — liên hệ #26475 lô 194 | | ⚠ Tư duy quan trọng hơn nghi thức | ⚠ hiểu VÌ SAO agile hoạt động thì học khung nào cũng nhanh | | ⚠ Kinh nghiệm thác nước của Darryl vẫn có giá trị | ⚠ hợp đồng, quản trị, ước lượng, bên liên quan — agile không xoá bỏ những thứ đó | | ⚠ Nguyên tắc của PMBOK 7 | ⚠ phương pháp phải ĐIỀU CHỈNH theo bối cảnh dự án — người biết cả hai đầu quang phổ có giá trị hơn người chỉ biết một đầu |

⚠ Điều một quản lý dự án thác nước cần học đầu tiên khi sang agile: | Chủ đề | Nội dung | |---|---| | ⚠ Tuyên ngôn Agile và 12 nguyên tắc | ⚠ nền tảng tư duy, đọc mất mười lăm phút | | ⚠ Phát triển lặp và tăng dần | ⚠ vì sao giao sớm và thường xuyên lại giảm rủi ro | | ⚠ Vai trò: chủ sản phẩm, scrum master, đội phát triển | ⚠ và vai trò của quản lý dự án nằm ở đâu trong đó | | ⚠ LÃNH ĐẠO PHỤC VỤ | ⚠ thay đổi lớn nhất về hành vi — liên hệ #26475 lô 194 | | ⚠ Hiện vật: backlog, định nghĩa hoàn thành, burndown | ⚠ liên hệ #26463 và #26490 | | ⚠ Đo bằng giá trị giao được, không bằng phần trăm kế hoạch | | | ⚠ Điều khó nhất | ⚠ không phải học thuật ngữ mới, mà là buông bỏ cảm giác kiểm soát mà một bản kế hoạch chi tiết mang lại — liên hệ #26463 lô 194 |

⚠ Đọc tín hiệu tổ chức — điều Darryl đã làm đúng: | Tín hiệu | Ý nghĩa | |---|---| | ⚠ CEO mới KHÔNG đến sau khủng hoảng | ⚠ thay đổi là CHỦ ĐỘNG, nên sẽ có kế hoạch và sẽ bền — không phải cơn sốt nhất thời | | ⚠ Ông không đổi ngành nghề cốt lõi | ⚠ thay đổi nằm ở CÁCH LÀM, không ở LÀM GÌ — tức là ảnh hưởng trực tiếp tới quản lý dự án | | ⚠ PMO đã bắt đầu đổi cả quy trình lẫn nhân sự | ⚠ tín hiệu mạnh nhất: đây không còn là tin đồn | | ⚠ Bài học chung | ⚠ thay đổi chiến lược của tổ chức là một YẾU TỐ MÔI TRƯỜNG DOANH NGHIỆP — quản lý dự án không kiểm soát được nó, nhưng đọc được nó sớm thì có nhiều lựa chọn hơn hẳn người đọc muộn |

Từ khoá nhận diện:

"tổ chức đang chuyển sang linh hoạt, PMO đang thay đổi" → ⚠ HỌC AGILE NÓI CHUNG "trở thành scrum master" → ⚠ quá hẹp, quá sớm, và là đổi vai trò "không cần đổi vì được tuyển vì kỹ năng cũ" → ⚠ chống lại thay đổi đã hiện rõ "thạo công cụ lập lịch hơn" → ⚠ đầu tư sâu hơn vào hướng ngược lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn đang đi về hướng nào | ⚠ nhìn vào việc PMO tuyển ai và bỏ quy trình nào | | Bạn thoải mái ở đầu nào của quang phổ dự đoán–agile | | | Lần cuối bạn học một cách làm việc mới là khi nào | ⚠ không phải một công cụ mới — một cách làm việc mới |

Và điều mà Darryl nhận ra sớm hơn nhiều đồng nghiệp của anh: khi PMO bắt đầu đổi con người chứ không chỉ đổi mẫu tài liệu, thì thay đổi đã đi qua giai đoạn thảo luận — và câu hỏi còn lại chỉ là bạn học kịp hay học sau.

Đáp án

D — Các bên liên quan đã KHÔNG được nhận diện hoặc KHÔNG được gắn kết trong giai đoạn lập kế hoạch.

Vì sao đúng

⚠ Vì sao đây là nguyên nhân gốc: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ SỐ LƯỢNG KỶ LỤC yêu cầu thay đổi | ⚠ không phải vài thay đổi bình thường — đây là dấu hiệu hệ thống | | ⚠ Dự án "không tạo được đà" | ⚠ liên tục đổi hướng nên không hoàn thành được gì | | ⚠ Yêu cầu thay đổi ĐẾN TỪ ĐÂU | ⚠ từ những người đáng lẽ phải nói ra nhu cầu của họ TỪ ĐẦU | | ⚠ Ai không được hỏi ở khâu lập kế hoạch sẽ lên tiếng ở khâu thực thi | ⚠ và lúc đó mỗi tiếng nói là một yêu cầu thay đổi | | ⚠ Đội kiệt sức là HẬU QUẢ, không phải nguyên nhân | | | ⚠ Kết luận | ⚠ thay đổi dồn dập gần như luôn quay về một gốc: yêu cầu chưa được thu thập đủ vì thiếu người |

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

• C (có vấn đề trong quy trình KIỂM SOÁT THAY ĐỔI TÍCH HỢP) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ rất nhiều yêu cầu thay đổi nghe đúng như một quy trình kiểm soát thay đổi đang hỏng: ⚠ nhưng ⚠ kiểm soát thay đổi XỬ LÝ các yêu cầu, nó không SINH RA hay NGĂN CHẶN chúng ⚠ — một quy trình kiểm soát thay đổi hoàn hảo vẫn phải xử lý số yêu cầu kỷ lục đó, chỉ là xử lý gọn gàng hơn; ⚠ đề hỏi điều gì đã SAI, tức hỏi nguyên nhân, và nguyên nhân nằm ở trước đó.

• A (quản lý dự án thiếu thẩm quyền) — ⚠ đề không nói gì về cấu trúc tổ chức hay thẩm quyền.

• B (lập trình viên thiếu kỹ năng) — ⚠ đề nói họ MỆT vì đổi hướng liên tục, không nói họ làm không nổi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26483 cùng lô (hội thảo yêu cầu — chính là cách phòng ngừa tình huống này), ⚠ #26453 lô 194 (kế hoạch gắn kết bên liên quan), ⚠ #26359 lô 192 (nhận diện bên liên quan lặp lại), ⚠ #26477 lô 194 (gắn kết kém), ⚠ #26436 lô 194 (ưu tiên theo tác động).

⚠ Chuỗi nhân quả từ bên liên quan bị bỏ sót tới đội kiệt sức: | Bước | Nội dung | |---|---| | ⚠ 1. Bên liên quan không được nhận diện hoặc không được mời tham gia | ⚠ gốc rễ | | ⚠ 2. Yêu cầu của họ không nằm trong đường cơ sở phạm vi | | | ⚠ 3. Đội bắt đầu làm dựa trên phạm vi thiếu | | | ⚠ 4. Bên liên quan thấy sản phẩm và nhận ra nó không đáp ứng nhu cầu của mình | ⚠ đây là lúc họ xuất hiện | | ⚠ 5. Mỗi người gửi một yêu cầu thay đổi | ⚠ số lượng kỷ lục | | ⚠ 6. Đội đổi hướng liên tục, không hoàn thành gì, kiệt sức | ⚠ triệu chứng mà đề mô tả | | ⚠ Chi phí | ⚠ thay đổi ở bước 5 đắt hơn nhiều lần so với việc hỏi đúng người ở bước 1 — đó là quy tắc 1–10–100, liên hệ #26461 lô 194 |

⚠ Nhận diện bên liên quan cho đầy đủ — cách làm: | Kỹ thuật | Nội dung | |---|---| | ⚠ Rà theo SƠ ĐỒ TỔ CHỨC và theo QUY TRÌNH NGHIỆP VỤ | ⚠ ai chạm vào quy trình mà sản phẩm này thay đổi | | ⚠ Hỏi các bên liên quan đã biết: "còn ai nữa nên tham gia?" | ⚠ kỹ thuật quả cầu tuyết, hiệu quả bất ngờ | | ⚠ Đừng quên các nhóm hay bị bỏ sót | ⚠ VẬN HÀNH, hỗ trợ khách hàng, tuân thủ, bảo mật, pháp chế, đào tạo | | ⚠ Rà soát LẶP LẠI ở mỗi giai đoạn | ⚠ liên hệ #26359 lô 192 và #26493 cùng lô | | ⚠ Ghi cả người PHẢN ĐỐI dự án | ⚠ họ ảnh hưởng mạnh nhất và hay bị bỏ qua nhất | | ⚠ Nhóm bị bỏ sót kinh điển | ⚠ đội VẬN HÀNH — họ chỉ xuất hiện lúc bàn giao và mang theo một danh sách yêu cầu, đúng như #26490 cùng lô |

⚠ Quản lý dự án nên làm gì BÂY GIỜ, khi đã ở giữa tình huống: | Bước | Nội dung | |---|---| | ⚠ 1. DỪNG lại và làm cho được bức tranh đầy đủ | ⚠ tiếp tục chạy trong khi phạm vi còn trôi là đốt sức đội | | ⚠ 2. Nhận diện lại bên liên quan cho đủ | | | ⚠ 3. Gom mọi yêu cầu thay đổi và XẾP ƯU TIÊN chúng cùng nhau | ⚠ liên hệ #26464 lô 194 | | ⚠ 4. Thiết lập lại đường cơ sở phạm vi qua kiểm soát thay đổi | | | ⚠ 5. Bảo vệ đội: chốt phạm vi cho từng chu kỳ | ⚠ không cho đổi hướng giữa chừng | | ⚠ Điều quan trọng nhất | ⚠ nói thẳng với nhà tài trợ rằng nguyên nhân là thiếu bên liên quan chứ không phải đội yếu — chẩn đoán sai ở đây dẫn tới việc thay người, và người mới sẽ gặp đúng vấn đề cũ |

Từ khoá nhận diện:

"số lượng yêu cầu thay đổi kỷ lục" → ⚠ BÊN LIÊN QUAN BỊ BỎ SÓT KHI LẬP KẾ HOẠCH "kiểm soát thay đổi tích hợp" → ⚠ xử lý yêu cầu, không sinh ra và không ngăn được chúng "đội kiệt sức vì đổi hướng liên tục" → ⚠ triệu chứng, không phải nguyên nhân "thiếu kỹ năng / thiếu thẩm quyền" → ⚠ không có căn cứ trong đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu thay đổi của bạn chủ yếu đến từ ai | ⚠ nếu từ những người không dự buổi lập kế hoạch nào thì bạn đã có chẩn đoán | | Đội vận hành và bảo mật có trong sổ bên liên quan không | | | Bạn đã hỏi "còn ai nữa" bao nhiêu lần | |

Và điều mà một dòng lũ yêu cầu thay đổi thực sự là: những cuộc trò chuyện đáng lẽ phải xảy ra ở tháng đầu tiên, nay đang xảy ra ở tháng thứ sáu — với giá cao hơn nhiều lần và với một đội đã mệt.

Đáp án

B — ĐIỂM XẾP HẠNG RỦI RO (risk rating score) — thứ này KHÔNG nằm trong sổ vấn đề.

Vì sao đúng

⚠ Vì sao điểm xếp hạng rủi ro không thuộc sổ vấn đề: | Lý do | Nội dung | |---|---| | ⚠ Điểm rủi ro = xác suất × tác động | ⚠ nó đo mức độ của một điều CHƯA XẢY RA | | ⚠ Vấn đề là điều ĐÃ XẢY RA — xác suất bằng 100% | ⚠ nhân với xác suất là vô nghĩa | | ⚠ Điểm xếp hạng thuộc SỔ ĐĂNG KÝ RỦI RO | ⚠ một tài liệu khác | | ⚠ Bão đã đi qua, máy chủ đã hỏng, lợi nhuận đã mất | ⚠ tất cả đều là sự kiện đã hoàn tất | | ⚠ Kết luận | ⚠ sổ vấn đề xếp theo mức ƯU TIÊN hoặc MỨC NGHIÊM TRỌNG, không theo điểm rủi ro |

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

• A, C, D — ⚠ cả ba ĐỀU LÀ trường chuẩn của sổ vấn đề, nên đều sai với câu hỏi phủ định này:
  • ⚠ MÔ TẢ VẤN ĐỀ — nói rõ chuyện gì đang xảy ra.
  • ⚠ SỐ HIỆU NHẬN DIỆN — để tham chiếu và theo dõi.
  • ⚠ CHỦ SỞ HỮU — người chịu trách nhiệm xử lý; ⚠ trường quan trọng nhất, vì vấn đề không có chủ là vấn đề không được giải quyết.

⚠ Vì sao "chủ sở hữu" là phương án gây nhiễu đáng nói: ⚠ cả sổ rủi ro và sổ vấn đề đều có trường này, ⚠ nên người nhớ mang máng dễ nghĩ nó chỉ thuộc về một bên; ⚠ thực tế cả hai đều cần một người chịu trách nhiệm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26394/#26396 lô 193 (vấn đề so với rủi ro — cặp câu nền tảng), ⚠ #26480 lô 194 (rủi ro chưa thành hình thì theo dõi), ⚠ #26484 cùng lô (ưu tiên vấn đề theo mức nghiêm trọng), ⚠ #26493 cùng lô (rà soát rủi ro liên tục), ⚠ #26462 lô 194 (rủi ro tồn dư).

⚠ SỔ VẤN ĐỀ và SỔ ĐĂNG KÝ RỦI RO — bảng phân biệt đầy đủ: | | Sổ vấn đề | Sổ đăng ký rủi ro | |---|---|---| | ⚠ Ghi gì | ⚠ điều ĐÃ xảy ra | ⚠ điều CÓ THỂ xảy ra | | ⚠ Xác suất | ⚠ 100% — không cần ghi | ⚠ trường bắt buộc | | ⚠ Điểm xếp hạng | ⚠ KHÔNG — câu này | ⚠ CÓ: xác suất × tác động | | ⚠ Trường chung | ⚠ số hiệu, mô tả, chủ sở hữu, trạng thái, ngày, mức ưu tiên | ⚠ cùng có các trường này | | ⚠ Trường riêng | ⚠ hành động khắc phục, hạn giải quyết, ngày đóng | ⚠ tác nhân kích hoạt, chiến lược ứng phó, rủi ro tồn dư, rủi ro thứ cấp | | ⚠ Cập nhật ở | ⚠ Chỉ đạo và Quản lý công việc; Giám sát và Kiểm soát | ⚠ suốt các quy trình rủi ro | | ⚠ Quan hệ giữa hai sổ | ⚠ một rủi ro XẢY RA thì đóng ở sổ rủi ro và MỞ ở sổ vấn đề — dòng chảy một chiều này là thứ đề hay kiểm tra | |

⚠ Sổ vấn đề nên có những trường nào: | Trường | Vì sao cần | |---|---| | ⚠ Số hiệu | ⚠ tham chiếu trong biên bản họp và báo cáo | | ⚠ Mô tả | ⚠ đủ rõ để người không dự họp cũng hiểu | | ⚠ Loại / phân nhóm | ⚠ kỹ thuật, nguồn lực, bên liên quan, bên ngoài | | ⚠ Mức ưu tiên hoặc nghiêm trọng | ⚠ để xếp thứ tự xử lý — liên hệ #26484 cùng lô | | ⚠ CHỦ SỞ HỮU | ⚠ một cái tên, không phải một phòng ban | | ⚠ Hạn giải quyết | | | ⚠ Trạng thái và ngày đóng | | | ⚠ Hành động đã và đang làm | | | ⚠ Sai lầm phổ biến | ⚠ ghi chủ sở hữu là một PHÒNG BAN — khi đó không ai thấy mình có trách nhiệm, và vấn đề nằm trong sổ tới ngày dự án kết thúc |

⚠ Tình huống bão của Michael — phân loại từng thiệt hại: | Thiệt hại | Vấn đề hay rủi ro | |---|---| | ⚠ Mất điện | ⚠ VẤN ĐỀ — đã xảy ra | | ⚠ Máy chủ bị phá huỷ | ⚠ VẤN ĐỀ — đã xảy ra | | ⚠ Mất lợi nhuận do ngừng việc | ⚠ VẤN ĐỀ — đã xảy ra | | ⚠ Khả năng có cơn bão tiếp theo trong mùa này | ⚠ RỦI RO — nếu ghi thì ghi vào sổ rủi ro, có điểm xếp hạng | | ⚠ Điểm cần chú ý | ⚠ cùng một cơn bão sinh ra cả mục ở sổ vấn đề lẫn mục ở sổ rủi ro — nó không thuộc riêng sổ nào, mà tuỳ vào việc ta đang nói về lần đã qua hay lần sắp tới |

Từ khoá nhận diện:

"điểm xếp hạng rủi ro / xác suất × tác động" → ⚠ SỔ RỦI RO, không phải sổ vấn đề "mô tả, số hiệu, chủ sở hữu" → ⚠ trường chuẩn của cả hai sổ "đã xảy ra" → ⚠ sổ vấn đề "có thể xảy ra" → ⚠ sổ rủi ro

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ vấn đề của bạn có ai làm chủ sở hữu từng mục không | ⚠ tên người, không phải tên phòng | | Có vấn đề nào mở quá lâu không | ⚠ thường vì không có hạn hoặc không có chủ | | Khi một rủi ro xảy ra, bạn có chuyển nó sang sổ vấn đề không | ⚠ hay nó nằm mãi ở sổ rủi ro với trạng thái "đang theo dõi" |

Và lý do hai cuốn sổ không nên gộp làm một: một cuốn hỏi "chúng ta phải sửa gì hôm nay", cuốn kia hỏi "chúng ta phải chuẩn bị gì cho ngày mai" — gộp lại thì việc cấp bách sẽ nuốt hết chỗ của việc quan trọng.

Đáp án

D — Mark muốn XÁC NHẬN rằng đội đã hiểu đúng những gì anh nói.

Vì sao đúng

⚠ Vì sao đây là kỹ thuật xác nhận hiểu biết: | Lý do | Nội dung | |---|---| | ⚠ Nhắc lại BẰNG LỜI CỦA MÌNH đòi hỏi phải HIỂU | ⚠ nhắc lại nguyên văn thì chỉ cần nhớ | | ⚠ Đây là VÒNG PHẢN HỒI trong mô hình giao tiếp | ⚠ người gửi kiểm chứng rằng thông điệp tới nơi nguyên vẹn | | ⚠ Buổi planning poker ĐẦU TIÊN của đội | ⚠ thời điểm hiểu sai gây thiệt hại lâu dài nhất | | ⚠ Mark hỏi NHIỀU người khác nhau | ⚠ kiểm tra cả đội, không chỉ một người | | ⚠ Đây là hành vi của người điều phối tốt | ⚠ liên hệ lãnh đạo phục vụ — #26475 lô 194 | | ⚠ Kết luận | ⚠ một kỹ thuật giao tiếp cơ bản và có chủ đích |

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

• B (nhắc lại hướng dẫn là một PHẦN CỦA planning poker) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như một quy tắc thật của kỹ thuật này, và người chưa từng chơi rất dễ tin: ⚠ nhưng ⚠ planning poker KHÔNG có bước nào như vậy ⚠ — luật của nó là: chủ sản phẩm mô tả hạng mục, mỗi người chọn một lá bài kín, lật đồng thời, người cao nhất và thấp nhất giải thích, rồi bầu lại; ⚠ việc Mark làm là kỹ năng điều phối chung, không phải luật chơi.

• A (Mark lo đội không thừa nhận thẩm quyền của anh) — ⚠ gán động cơ bất an; ⚠ và scrum master vốn không dựa vào thẩm quyền — liên hệ #26489 cùng lô.

• C (Mark không chắc mình hiểu đúng, mong ai đó sửa) — ⚠ gán động cơ thiếu năng lực; ⚠ đề nói rõ anh đã hướng dẫn đội trước đó.

⚠ Mô-típ đáng nhớ: ⚠ hai phương án nhiễu A và C đều gán ĐỘNG CƠ TIÊU CỰC cho một hành vi chuyên nghiệp bình thường ⚠ — ⚠ đề PMP gần như không bao giờ chọn phương án bôi đen động cơ của quản lý dự án hay scrum master; ⚠ gặp cấu trúc này thì loại chúng trước.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26450 lô 194 (lắng nghe chủ động — xác nhận lại là một bước của nó), ⚠ #26444 lô 194 (truyền phát so với tương tác), ⚠ #26474 lô 194 (5C của giao tiếp viết), ⚠ #26456 lô 194 (hỏi cách phát âm tên), ⚠ #26501 cùng lô (chia sẻ tri thức).

⚠ MÔ HÌNH GIAO TIẾP và vị trí của bước Mark làm: | Bước | Nội dung | |---|---| | ⚠ 1. MÃ HOÁ | ⚠ người gửi biến ý nghĩ thành lời | | ⚠ 2. TRUYỀN qua kênh | ⚠ nói trực tiếp trong buổi họp | | ⚠ 3. NHIỄU | ⚠ mất tập trung, khác biệt ngôn ngữ, giả định khác nhau | | ⚠ 4. GIẢI MÃ | ⚠ người nhận hiểu theo cách của họ | | ⚠ 5. XÁC NHẬN đã nhận | ⚠ "tôi nghe rồi" — mới chỉ là đã nhận | | ⚠ 6. PHẢN HỒI / trả lời | ⚠ bước Mark đang làm — chứng minh đã HIỂU, không chỉ đã nghe | | ⚠ Khác biệt then chốt | ⚠ XÁC NHẬN ĐÃ NHẬN khác XÁC NHẬN ĐÃ HIỂU — một cái gật đầu chỉ chứng minh vế đầu, và phần lớn hiểu lầm trong dự án nằm đúng ở khoảng cách giữa hai vế |

⚠ PLANNING POKER — luật chơi thật: | Bước | Nội dung | |---|---| | ⚠ 1. Chủ sản phẩm mô tả hạng mục và trả lời câu hỏi | | | ⚠ 2. Mỗi thành viên chọn một lá bài, ÚP XUỐNG | ⚠ thang Fibonacci: 1, 2, 3, 5, 8, 13, 21 | | ⚠ 3. LẬT ĐỒNG THỜI | ⚠ điểm mấu chốt: tránh hiệu ứng neo, ai lật trước thì cả nhóm bị ảnh hưởng | | ⚠ 4. Người ước cao nhất và thấp nhất GIẢI THÍCH | ⚠ giá trị thật của kỹ thuật nằm ở cuộc trò chuyện này, không ở con số | | ⚠ 5. Bầu lại tới khi hội tụ | | | ⚠ Vì sao nó hiệu quả | ⚠ nó là một dạng ước lượng nhóm ẩn danh có thảo luận — cùng nguyên lý với kỹ thuật Delphi ở #26406 lô 193 và nhóm danh nghĩa ở #26445 lô 194 | | ⚠ Lưu ý | ⚠ ước lượng bằng ĐIỂM TƯƠNG ĐỐI, không phải giờ — điểm đo độ phức tạp và bất định, không đo thời gian |

⚠ Các cách xác nhận người khác đã hiểu: | Cách | Đánh giá | |---|---| | ⚠ "Có ai thắc mắc gì không?" | ⚠ YẾU NHẤT — im lặng thường là không dám hỏi, không phải đã hiểu | | ⚠ "Mọi người hiểu chứ?" | ⚠ yếu — câu hỏi đóng, ai cũng gật | | ⚠ "Anh diễn giải lại giúp tôi được không?" | ⚠ MẠNH — buộc phải xử lý thông tin, đúng cách Mark làm | | ⚠ Cho làm thử một ví dụ | ⚠ mạnh nhất — với planning poker thì chơi thử một hạng mục | | ⚠ Lưu ý về cách hỏi | ⚠ phải hỏi sao cho không giống KIỂM TRA BÀI — "giúp tôi kiểm tra xem tôi giải thích có rõ không" đặt gánh nặng lên người nói chứ không lên người nghe, và đó là cách hỏi an toàn về mặt tâm lý |

Từ khoá nhận diện:

"nhắc lại bằng lời của mình" → ⚠ XÁC NHẬN ĐÃ HIỂU, vòng phản hồi "đó là một phần của planning poker" → ⚠ không có bước này trong luật chơi phương án gán động cơ bất an hoặc thiếu năng lực → ⚠ gần như luôn sai trong đề PMP "có ai thắc mắc không" → ⚠ cách xác nhận yếu nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn kết thúc phần giải thích bằng câu hỏi nào | | | Đội bạn có bao giờ diễn giải lại yêu cầu cho bạn nghe không | | | Hiểu lầm gần nhất trong dự án của bạn bắt đầu từ đâu | ⚠ thường từ một cái gật đầu |

Và điều mà Mark hiểu rõ hơn nhiều người điều hành họp: một căn phòng im lặng sau câu "mọi người rõ chưa" không phải là bằng chứng của sự rõ ràng — nó chỉ là bằng chứng rằng bạn đã hỏi sai câu.

Đáp án

C — LẬP KẾ HOẠCH CHẤT LƯỢNG (quality planning).

⚠ Ghi nhớ về chất lượng câu hỏi — câu GẦN TRÙNG trong cùng lô: ⚠ câu này và #26491 cùng lô là hai phiên bản của cùng một câu hỏi, cùng bốn phương án và CÙNG KHOÁ ĐÁP ÁN (lập kế hoạch chất lượng) ⚠ — ⚠ hash MD5 không bắt được vì đề bài viết khác nhau: một bên là Bruno với tiêu chuẩn ngành, một bên là Mia với "không lệch khỏi yêu cầu". ⚠ Hai khoá KHÔNG mâu thuẫn, nên giữ nguyên cả hai; ⚠ đọc hai câu cạnh nhau là cách tốt để thấy đề xoay cùng một khái niệm bằng hai lối diễn đạt. ⚠ Đề bài của câu này mơ hồ hơn — xem phần dưới.

Vì sao đúng

⚠ Vì sao vẫn là lập kế hoạch chất lượng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Mia đang HỌP VỚI ĐỘI, chưa làm gì cả | ⚠ chưa có sản phẩm bàn giao nào để đo | | ⚠ Mục tiêu là BẢO ĐẢM dự án hoàn thành đúng yêu cầu | ⚠ dự phòng, hướng về tương lai | | ⚠ "Không lệch khỏi yêu cầu" = định nghĩa chất lượng của PMI | ⚠ chất lượng là mức độ đáp ứng YÊU CẦU | | ⚠ Việc bảo đảm điều đó bắt đầu bằng một KẾ HOẠCH | ⚠ xác định tiêu chuẩn, phép đo, cách kiểm | | ⚠ Kết luận | ⚠ cùng logic với #26491: chưa có sản phẩm thì chưa phải QA hay QC |

⚠ Điểm mơ hồ cần thừa nhận: ⚠ cụm "bảo đảm hoàn thành không lệch khỏi yêu cầu" nếu tách riêng thì cũng đọc được thành QA hoặc QC ⚠ — thứ quyết định là thời điểm: Mia đang họp đầu để chuẩn bị, chưa có gì để bảo đảm hay để đo; ⚠ đây là câu đòi bám vào bối cảnh chứ không bám vào từ ngữ.

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

• A (BẢO ĐẢM CHẤT LƯỢNG — QA) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chữ "bảo đảm" (ensure) trong đề trùng nghĩa với chữ "assurance": ⚠ nhưng ⚠ QA thuộc nhóm THỰC THI — nó kiểm tra việc TUÂN THỦ một kế hoạch đã có ⚠ — Mia còn chưa có kế hoạch đó.
• B (KIỂM SOÁT CHẤT LƯỢNG) — ⚠ đo sản phẩm đã làm xong; ⚠ chưa có sản phẩm nào.
• D (QUẢN LÝ CHẤT LƯỢNG) — ⚠ tên của cả lĩnh vực kiến thức, quá rộng; ⚠ cùng kiểu bẫy với #26491.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26491 cùng lô (câu song sinh — đọc cùng nhau), ⚠ #26470 lô 194 (chất lượng được lập kế hoạch vào, không phải kiểm tra vào), ⚠ #26457 lô 194 (QA và QC), ⚠ #26461 lô 194 (chi phí chất lượng), ⚠ #26441 lô 194 (công cụ lập kế hoạch chất lượng).

⚠ Ba quy trình chất lượng — nhận diện bằng BỐI CẢNH, không bằng từ khoá: | Trong đề có gì | Quy trình | |---|---| | ⚠ Chưa có sản phẩm; đang bàn tiêu chuẩn, cách làm, phép đo | ⚠ LẬP KẾ HOẠCH chất lượng | | ⚠ Đang làm; kiểm xem QUY TRÌNH có được tuân thủ không; kiểm toán | ⚠ QA — Quản lý chất lượng | | ⚠ Có sản phẩm cụ thể; đang ĐO, thử, đếm khuyết tật | ⚠ QC — Kiểm soát chất lượng | | ⚠ Khách hàng ký nhận | ⚠ Xác nhận phạm vi — thuộc lĩnh vực Phạm vi, không phải Chất lượng | | ⚠ Cạm bẫy từ ngữ | ⚠ chữ "bảo đảm/ensure" trong tiếng Anh gợi tới "assurance", nhưng nó là một động từ thông thường — đừng để nó quyết định câu trả lời thay cho bối cảnh | |

⚠ Mia nên làm gì trong buổi họp đó: | Việc | Nội dung | |---|---| | ⚠ Cùng đội rà lại YÊU CẦU và tiêu chí chấp nhận | ⚠ không lệch khỏi yêu cầu thì trước hết phải biết yêu cầu là gì | | ⚠ Xác định tiêu chuẩn chất lượng áp dụng | ⚠ cho sản phẩm gạch ốp lát: kích thước, độ bền, màu sắc, dung sai | | ⚠ Thống nhất PHÉP ĐO và ngưỡng chấp nhận | ⚠ đo bằng gì, bao nhiêu là đạt | | ⚠ Quyết định hoạt động phòng ngừa | ⚠ đào tạo, hiệu chuẩn thiết bị, mẫu đối chứng | | ⚠ Lập kế hoạch kiểm tra và lấy mẫu | ⚠ QC sẽ dùng về sau | | ⚠ Nguyên tắc bao trùm | ⚠ mọi thứ đo được về sau đều phải được ĐỊNH NGHĨA từ bây giờ — đó là lý do lập kế hoạch chất lượng đứng trước hai quy trình kia, liên hệ #26470 lô 194 |

Từ khoá nhận diện:

"họp với đội để bảo đảm làm đúng yêu cầu, chưa có sản phẩm" → ⚠ LẬP KẾ HOẠCH CHẤT LƯỢNG "chữ ensure/assurance" → ⚠ không tự động nghĩa là QA "đo sản phẩm cụ thể" → ⚠ QC "quản lý chất lượng" → ⚠ tên lĩnh vực, quá rộng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn định nghĩa "đạt yêu cầu" bằng con số hay bằng cảm nhận | | | Buổi họp chất lượng đầu tiên của dự án bạn diễn ra khi nào | ⚠ sau khi có sản phẩm là đã muộn | | Đội bạn có biết tiêu chí chấp nhận trước khi bắt tay làm không | |

Và điều mà cả hai câu song sinh trong lô này cùng chỉ về: chất lượng không phải là thứ bạn kiểm tra ở cuối — nó là thứ bạn quyết định ở đầu, và mọi việc sau đó chỉ là kiểm chứng xem quyết định ấy có được thực hiện hay không.

Đáp án

C — SUỐT CẢ DỰ ÁN (throughout the whole project).

Vì sao đúng

⚠ Vì sao chia sẻ tri thức phải diễn ra liên tục: | Lý do | Nội dung | |---|---| | ⚠ Tri thức được TẠO RA liên tục trong lúc làm việc | ⚠ đợi tới cuối là đã quên phần lớn | | ⚠ Nó chỉ có giá trị khi tới NGƯỜI CẦN, ĐÚNG LÚC họ cần | ⚠ một bài học chia sẻ muộn ba tháng là một bài học vô dụng | | ⚠ Agile dựa trên vòng lặp học hỏi ngắn | ⚠ họp đứng hằng ngày, hồi cứu mỗi vòng lặp, làm việc theo cặp | | ⚠ Chia sẻ liên tục làm giảm phụ thuộc vào cá nhân | ⚠ giảm điểm hỏng đơn lẻ | | ⚠ Đây là vai trò cốt lõi của người dẫn dắt đội agile | ⚠ tạo môi trường để tri thức chảy, không phải tự mình nắm giữ | | ⚠ Kết luận | ⚠ liên tục, không phải một sự kiện có lịch |

⚠ Mô-típ lặp lại — nhắc lại từ #26493 cùng lô: ⚠ khi ba phương án là ba thời điểm cụ thể và một phương án là "suốt dự án", phương án liên tục gần như luôn đúng ⚠ — điều này đúng với nhận diện rủi ro (#26322 lô 191), nhận diện bên liên quan (#26359 lô 192), rà soát rủi ro (#26493 cùng lô) và chia sẻ tri thức (câu này).

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

• B (khi vòng lặp KẾT THÚC) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ buổi HỒI CỨU cuối vòng lặp ĐÚNG LÀ một dịp chia sẻ tri thức chính thức và quan trọng: ⚠ nhưng ⚠ nó chỉ là MỘT trong nhiều dịp ⚠ — nếu chỉ chia sẻ vào cuối vòng lặp thì mọi thứ học được ở ngày thứ hai phải chờ mười hai ngày mới tới tay người cần; ⚠ hồi cứu là điểm nhấn, không phải toàn bộ cơ chế.

• D (khi dự án KẾT THÚC) — ⚠ muộn nhất có thể; ⚠ đây chính là cách làm bài học kinh nghiệm kiểu cũ mà agile cố ý bỏ.

• A (khi một thành viên tỏ ra quan tâm tới một việc) — ⚠ biến chia sẻ tri thức thành việc tuỳ hứng; ⚠ phụ thuộc vào việc có ai chủ động hỏi hay không.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26455/#26458 lô 194 (tri thức ẩn và tri thức hiện), ⚠ #26493 cùng lô (rà soát rủi ro liên tục — cùng mô-típ), ⚠ #26467 lô 194 (cùng chỗ và giao tiếp thẩm thấu), ⚠ #26499 cùng lô (xác nhận đã hiểu), ⚠ #26490 cùng lô (định nghĩa hoàn thành).

⚠ Các cơ chế chia sẻ tri thức trong đội agile — theo nhịp độ: | Nhịp | Cơ chế | |---|---| | ⚠ LIÊN TỤC | ⚠ giao tiếp thẩm thấu khi cùng chỗ, kênh chat mở, bảng thông tin trên tường | | ⚠ HẰNG NGÀY | ⚠ họp đứng, làm việc theo cặp, rà soát mã | | ⚠ TRONG VÒNG LẶP | ⚠ kèm cặp tại chỗ, xoay vòng công việc, buổi chia sẻ ngắn | | ⚠ CUỐI VÒNG LẶP | ⚠ buổi rà soát sản phẩm và HỒI CỨU — phương án B | | ⚠ ĐỊNH KỲ dài hơn | ⚠ cộng đồng thực hành, buổi trình bày nội bộ | | ⚠ Nhận xét | ⚠ cột trên cùng có băng thông cao nhất và chi phí thấp nhất; càng xuống dưới càng chính thức và càng chậm — một đội khoẻ mạnh dựa chủ yếu vào hai hàng đầu |

⚠ Vì sao chờ tới cuối dự án là sai lầm kinh điển: | Vấn đề | Nội dung | |---|---| | ⚠ Người ta đã quên chi tiết | ⚠ và chi tiết mới là phần có giá trị | | ⚠ Đội đã tan rã hoặc chuyển sang việc khác | | | ⚠ Không ai còn động lực nhìn lại | ⚠ dự án xong rồi, ai cũng muốn đi tiếp | | ⚠ Bài học không cứu được CHÍNH dự án đó | ⚠ điểm quan trọng nhất — học liên tục thì dự án hiện tại được lợi ngay | | ⚠ Khác biệt về triết lý | ⚠ cách làm cũ coi bài học là DI SẢN để lại cho dự án sau; agile coi nó là CÔNG CỤ ĐIỀU CHỈNH cho chính chu kỳ tới — cùng một hoạt động, giá trị khác hẳn nhau |

⚠ Người dẫn dắt đội agile làm gì để tri thức chảy: | Việc | Nội dung | |---|---| | ⚠ Tạo AN TOÀN TÂM LÝ để người ta dám nói mình không biết | ⚠ liên hệ #26469 lô 194 — thiếu lòng tin chặn mọi chia sẻ | | ⚠ Tổ chức làm việc theo cặp và xoay vòng vị trí | ⚠ chuyển giao tri thức ẩn hiệu quả nhất | | ⚠ Giữ tài liệu vừa đủ và dễ tìm | ⚠ tri thức hiện — liên hệ #26458 lô 194 | | ⚠ Bảo đảm hồi cứu ra được HÀNH ĐỘNG cụ thể | ⚠ hồi cứu chỉ than phiền là hồi cứu vô ích | | ⚠ Ghi nhận người chia sẻ | ⚠ liên hệ #26488 cùng lô — hệ thống khen thưởng | | ⚠ Chỉ dấu của một đội chia sẻ tốt | ⚠ khi một người nghỉ một tuần, công việc vẫn chạy — nếu không thì tri thức đang bị nhốt trong đầu vài người, và đó là một rủi ro chưa ai ghi vào sổ |

Từ khoá nhận diện:

"chia sẻ tri thức diễn ra khi nào" → ⚠ SUỐT CẢ DỰ ÁN "cuối vòng lặp / hồi cứu" → ⚠ một dịp quan trọng, không phải toàn bộ "cuối dự án" → ⚠ cách làm cũ, muộn nhất có thể "khi có ai đó quan tâm" → ⚠ tuỳ hứng, không phải cơ chế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn chia sẻ tri thức ở đâu ngoài buổi hồi cứu | | | Nếu người giỏi nhất nghỉ một tuần, việc có dừng không | | | Hồi cứu gần nhất của bạn ra được mấy hành động cụ thể | ⚠ không có hành động thì đó chỉ là một buổi tâm sự |

Và lý do agile đẩy việc chia sẻ tri thức ra khỏi buổi họp cuối cùng: một bài học rút ra vào ngày kết thúc dự án chỉ có thể giúp một dự án khác, với một đội khác, trong một bối cảnh khác — tức là gần như không giúp được ai.

Đáp án

C — ĐIỀU LỆ DỰ ÁN (project charter) — đây là thứ KHÔNG hữu ích cho việc ước lượng thời lượng hoạt động.

Vì sao đúng

⚠ Vì sao điều lệ dự án không giúp ước lượng thời lượng: | Lý do | Nội dung | |---|---| | ⚠ Điều lệ nằm ở mức RẤT CAO | ⚠ mục tiêu, mốc lớn, thẩm quyền của quản lý dự án, bên liên quan chính | | ⚠ Nó KHÔNG chứa danh sách hoạt động | ⚠ mà ước lượng thời lượng là ước lượng cho TỪNG HOẠT ĐỘNG | | ⚠ Nó được viết TRƯỚC khi có WBS | ⚠ nên không thể chứa chi tiết cần thiết | | ⚠ Vai trò của nó là CHO PHÉP dự án tồn tại | ⚠ không phải cung cấp dữ liệu lập kế hoạch | | ⚠ Kết luận | ⚠ hữu ích cho nhiều việc khác, nhưng không cho phép tính này |

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

• A, B, D — ⚠ cả ba ĐỀU LÀ đầu vào thật của quy trình Ước lượng thời lượng hoạt động, nên đều sai với câu hỏi phủ định:
  • ⚠ GIẢ ĐỊNH — mọi ước lượng đều dựa trên giả định (năng suất, sự sẵn có của nguồn lực, điều kiện thời tiết); ⚠ chúng nằm trong nhật ký giả định, một đầu vào chính thức.
  • ⚠ RỦI RO ĐÃ NHẬN DIỆN — rủi ro làm thời lượng dài ra và là cơ sở cho dự phòng; ⚠ sổ đăng ký rủi ro là đầu vào.
  • ⚠ RÀNG BUỘC — hạn chót, giới hạn nguồn lực, thoả ước lao động đều bó hẹp ước lượng khả thi; ⚠ liên hệ #26487 cùng lô.

⚠ Phương án gây nhiễu mạnh nhất là B (rủi ro đã nhận diện) ⚠ — vì ⚠ nhiều người nghĩ rủi ro chỉ liên quan tới dự phòng chứ không liên quan tới bản thân con số ước lượng: ⚠ nhưng ⚠ PMBOK ghi rõ sổ đăng ký rủi ro là đầu vào của Ước lượng thời lượng hoạt động ⚠ — một hoạt động có rủi ro cao thì bản thân thời lượng ước lượng cũng phải phản ánh điều đó, chưa nói tới dự phòng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26492 cùng lô (CSDL ước lượng thương mại), ⚠ #26495 cùng lô (yêu cầu nguồn lực — cũng là đầu vào), ⚠ #26448 lô 194 (ước lượng một mình), ⚠ #26413/#26417 lô 193 (từ dưới lên; tam giác), ⚠ #26241 lô 189 (ba điểm), ⚠ #26291 lô 191 (mức độ chính xác).

⚠ ĐẦU VÀO của Ước lượng thời lượng hoạt động: | Đầu vào | Vai trò | |---|---| | ⚠ DANH SÁCH HOẠT ĐỘNG và thuộc tính hoạt động | ⚠ chính là thứ cần ước lượng | | ⚠ YÊU CẦU NGUỒN LỰC | ⚠ có bao nhiêu người thì mất bao lâu — liên hệ #26495 cùng lô | | ⚠ LỊCH NGUỒN LỰC | ⚠ khi nào họ rảnh | | ⚠ NHẬT KÝ GIẢ ĐỊNH | ⚠ phương án A | | ⚠ SỔ ĐĂNG KÝ RỦI RO | ⚠ phương án B | | ⚠ Đường cơ sở PHẠM VI (chứa ràng buộc) | ⚠ phương án D | | ⚠ Sổ bài học kinh nghiệm | ⚠ dữ liệu từ dự án trước | | ⚠ Yếu tố môi trường doanh nghiệp | ⚠ CSDL định mức thương mại nằm ở đây — liên hệ #26492 cùng lô | | ⚠ Điều lệ dự án | ⚠ KHÔNG có trong danh sách — đó là toàn bộ nội dung của câu hỏi này |

⚠ ĐIỀU LỆ DỰ ÁN chứa gì và dùng vào việc gì: | Nội dung | Vai trò | |---|---| | ⚠ Mục đích và biện minh của dự án | ⚠ vì sao dự án tồn tại | | ⚠ Mục tiêu ở mức cao và tiêu chí thành công | | | ⚠ Yêu cầu và mô tả sản phẩm ở mức cao | ⚠ rất thô, không đủ để ước lượng | | ⚠ Rủi ro tổng thể ở mức cao | | | ⚠ Lịch MỐC tóm tắt và ngân sách tóm tắt | ⚠ là RÀNG BUỘC, không phải dữ liệu ước lượng | | ⚠ Bên liên quan chính | | | ⚠ THẨM QUYỀN của quản lý dự án | ⚠ giá trị lớn nhất của điều lệ với chính quản lý dự án | | ⚠ Điểm dễ nhầm | ⚠ điều lệ CÓ mốc thời gian, nên trông như giúp được cho lịch — nhưng đó là mốc do lãnh đạo ĐẶT RA, tức là thứ ước lượng phải đối chiếu, không phải thứ ước lượng dựa vào |

⚠ Vì sao câu hỏi này quan trọng hơn vẻ ngoài: | Lý do | Nội dung | |---|---| | ⚠ Nó kiểm tra hiểu về MỨC ĐỘ CHI TIẾT của các tài liệu | ⚠ tài liệu mức cao không dùng cho phép tính mức thấp | | ⚠ Nó ngăn một sai lầm rất thật | ⚠ lấy mốc trong điều lệ rồi chia ngược ra thời lượng cho từng hoạt động | | ⚠ Cách làm ngược đó có tên: ước lượng bị áp đặt | ⚠ con số có trước, công việc bị ép vừa vào sau | | ⚠ Hệ quả | ⚠ đó là cách một dự án có bản lịch trông rất đẹp và không có liên hệ nào với thực tế công việc — liên hệ #26448 lô 194 về ước lượng vội dưới sức ép |

Từ khoá nhận diện:

"điều lệ dự án" → ⚠ tài liệu MỨC CAO, KHÔNG dùng để ước lượng thời lượng hoạt động "giả định, rủi ro đã nhận diện, ràng buộc" → ⚠ đều là đầu vào thật "mốc trong điều lệ" → ⚠ là ràng buộc để đối chiếu, không phải dữ liệu để tính câu hỏi "cái nào KHÔNG hữu ích" → ⚠ chấm từng cái, chọn cái lẻ loi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng của bạn dựa trên danh sách hoạt động hay dựa trên hạn chót | | | Nhật ký giả định của bạn có được dùng khi ước lượng không | ⚠ hay chỉ được viết ra rồi để đó | | Rủi ro đã nhận diện có ảnh hưởng tới con số nào trong lịch của bạn không | |

Và câu hỏi phân biệt một bản lịch thật với một bản lịch được vẽ ngược: con số của bạn đến từ công việc, hay đến từ ngày mà ai đó đã hứa trước khi công việc được mô tả?