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

Đáp án

D — CƠ CẤU CHỨC NĂNG (functional).

Vì sao đúng

⚠ Vì sao đây là cơ cấu chức năng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Thành viên BÁO CÁO cho một người khác, không phải Cody | ⚠ quản lý chức năng nắm quyền chỉ đạo | | ⚠ Người đó quyết công việc HẰNG NGÀY của họ | ⚠ thu hoạch ruộng nào, bao nhiêu, cất ở đâu | | ⚠ Cody HIẾM KHI được hỏi ý kiến | ⚠ thẩm quyền của quản lý dự án gần như bằng không | | ⚠ Cody gắn với MỘT phòng ban: nghiên cứu và phát triển | ⚠ anh làm việc trong ranh giới phòng ban, không cắt ngang tổ chức | | ⚠ Kết luận | ⚠ quyền lực nằm hoàn toàn ở tuyến chức năng |

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

• A (MA TRẬN) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ trong đề CÓ hai người cùng liên quan tới thành viên (Cody và người quản lý kia), nghe như báo cáo hai tuyến: ⚠ nhưng ⚠ ma trận đòi quản lý dự án phải CÓ MỘT PHẦN thẩm quyền thật sự ⚠ — kể cả ma trận yếu cũng cho quản lý dự án tiếng nói về công việc dự án; ⚠ ở đây Cody hiếm khi được hỏi, tức là không có tuyến báo cáo thứ hai nào cả.

• C (THEO DỰ ÁN — projectized) — ⚠ ngược hoàn toàn: ⚠ ở đó quản lý dự án có toàn quyền và đội chỉ báo cáo cho anh ta.

• B (LAI — hybrid) — ⚠ là sự pha trộn nhiều cơ cấu; ⚠ đề mô tả một mô hình thuần nhất và rõ ràng, không có dấu hiệu pha trộn.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26476 lô 194 (ma trận mạnh — Carlos tự chủ động được), ⚠ #26482 lô 194 (ma trận mạnh — không nhảy bậc lên quản lý chức năng), ⚠ #26486 cùng lô (quản lý chức năng quyền lực cao), ⚠ #26520 cùng lô (ma trận yếu), ⚠ #26489 cùng lô (quyền lực vị trí).

⚠ CÁC CƠ CẤU TỔ CHỨC — bảng đầy đủ: | Cơ cấu | Thẩm quyền quản lý dự án | Ai quản nguồn lực | Quản lý dự án làm toàn thời gian? | |---|---|---|---| | ⚠ CHỨC NĂNG | ⚠ RẤT ÍT hoặc không có | ⚠ quản lý chức năng | ⚠ bán thời gian, thường kiêm nhiệm | | ⚠ MA TRẬN YẾU | ⚠ thấp | ⚠ quản lý chức năng | ⚠ bán thời gian; có khi gọi là điều phối viên dự án | | ⚠ MA TRẬN CÂN BẰNG | ⚠ trung bình | ⚠ chia sẻ | ⚠ toàn thời gian | | ⚠ MA TRẬN MẠNH | ⚠ trung bình đến cao | ⚠ quản lý dự án | ⚠ toàn thời gian | | ⚠ THEO DỰ ÁN | ⚠ CAO tới toàn quyền | ⚠ quản lý dự án | ⚠ toàn thời gian | | ⚠ Cách nhận diện trong đề | ⚠ tìm câu trả lời cho: AI QUYẾT công việc hằng ngày của thành viên đội — đó là người nắm quyền thật | | |

⚠ Cody nên làm gì trong cơ cấu này: | Việc | Nội dung | |---|---| | ⚠ Xây quan hệ tốt với các quản lý chức năng | ⚠ họ là cửa duy nhất để có nguồn lực | | ⚠ THƯƠNG LƯỢNG chứ không ra lệnh | ⚠ anh không có quyền lực vị trí — liên hệ #26489 cùng lô | | ⚠ Dựa vào quyền lực CHUYÊN GIA và THAM CHIẾU | ⚠ hai loại quyền lực không cần chức vụ | | ⚠ Lấy được cam kết bằng VĂN BẢN về thời gian của nhân sự | ⚠ thoả thuận miệng sẽ thua công việc vận hành hằng ngày | | ⚠ Nhờ nhà tài trợ can thiệp khi bị chặn | ⚠ liên hệ #26442 lô 194 — leo thang đúng lúc | | ⚠ Rủi ro lớn nhất của cơ cấu chức năng | ⚠ công việc dự án luôn xếp SAU công việc vận hành, vì người quyết thời gian của đội được đánh giá theo kết quả vận hành chứ không theo kết quả dự án |

⚠ Vì sao tổ chức nông nghiệp này chọn cơ cấu chức năng: | Lý do | Nội dung | |---|---| | ⚠ Công việc chính là VẬN HÀNH lặp lại | ⚠ thu hoạch theo mùa, có quy trình ổn định | | ⚠ Hiệu quả chuyên môn hoá cao | ⚠ mỗi phòng ban làm sâu một việc | | ⚠ Ít dự án, và dự án không phải nguồn thu chính | | | ⚠ Nhận xét công bằng | ⚠ cơ cấu chức năng KHÔNG phải cơ cấu tồi — nó tối ưu cho tổ chức mà vận hành mới là hoạt động chính; nó chỉ tồi cho quản lý dự án, và đó là hai chuyện khác nhau |

Từ khoá nhận diện:

"thành viên báo cáo cho quản lý khác, quản lý dự án hiếm khi được hỏi" → ⚠ CHỨC NĂNG "có hai tuyến báo cáo thật sự" → ⚠ ma trận "quản lý dự án toàn quyền, đội chỉ báo cáo cho anh" → ⚠ theo dự án câu hỏi chẩn đoán → ⚠ AI quyết công việc hằng ngày của thành viên đội

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người trong đội bạn báo cáo cho ai về công việc hằng ngày | | | Khi bạn cần thêm thời gian của họ, bạn xin ai | | | Bạn có thoả thuận bằng văn bản về nguồn lực không | ⚠ trong cơ cấu chức năng đây gần như là điều bắt buộc |

Và điều mà mọi quản lý dự án trong cơ cấu chức năng đều học được sớm: bạn chịu trách nhiệm về kết quả của những người mà bạn không có quyền yêu cầu bất cứ điều gì — nên toàn bộ nghề của bạn ở đây là nghệ thuật khiến người ta muốn giúp.

Đáp án

A — Chỉ cho lập trình viên xem CHÍNH SÁCH TÀI LIỆU của dự án.

Vì sao đúng

⚠ Vì sao đây là câu trả lời đúng của một scrum master: | Lý do | Nội dung | |---|---| | ⚠ Đã có SẴN một chính sách trả lời câu hỏi này | ⚠ báo cáo lưu ở đâu, ai được xem, giữ bao lâu | | ⚠ Chỉ người ta tới NGUỒN thay vì trả lời thay | ⚠ họ tự tra được cho những lần sau | | ⚠ Đây là lãnh đạo phục vụ đúng nghĩa | ⚠ giúp người khác TỰ LÀM ĐƯỢC, không làm hộ | | ⚠ Bảo đảm tính NHẤT QUÁN trong cả đội | ⚠ ai cũng theo cùng một chuẩn | | ⚠ Dự án đang ở vòng lặp thứ CHÍN | ⚠ quy trình đã ổn định, chắc chắn chính sách này tồn tại | | ⚠ Kết luận | ⚠ câu hỏi mang tính quy trình thì trả lời bằng quy trình đã có |

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

• B (bảo lập trình viên chia sẻ báo cáo với đội phát triển) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ minh bạch trong đội là giá trị cốt lõi của agile, nên "chia sẻ với đội" luôn nghe đúng: ⚠ nhưng ⚠ đó là Tiffany TỰ ĐẶT RA một quy tắc trong khi tổ chức đã có chính sách ⚠ — nếu chính sách yêu cầu chia sẻ thì lập trình viên sẽ tự biết khi đọc; ⚠ nếu không thì Tiffany vừa tạo ra một cách làm riêng cho một người, tức là phá tính nhất quán.

• C (trình bày báo cáo ở buổi hồi cứu kế tiếp) — ⚠ hiểu sai mục đích hồi cứu: ⚠ hồi cứu bàn về cách đội làm việc, không phải nơi trình bày báo cáo cho bên liên quan — liên hệ #26508 cùng lô.

• D (không làm gì, bên liên quan đã có báo cáo rồi) — ⚠ bỏ qua việc LƯU TRỮ và truy vết; ⚠ một báo cáo chỉ nằm trong hộp thư người nhận là một báo cáo sẽ biến mất.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26475 lô 194 (lãnh đạo phục vụ), ⚠ #26499 cùng lô (scrum master hướng dẫn đội), ⚠ #26508 cùng lô (hồi cứu bàn về cách làm việc), ⚠ #26511 cùng lô (tài sản quy trình tổ chức), ⚠ #26458 lô 194 (tri thức hiện).

⚠ Vì sao "chỉ tới chính sách" tốt hơn "trả lời thẳng": | Lợi ích | Nội dung | |---|---| | ⚠ Người hỏi học được CÁCH TỰ TÌM | ⚠ lần sau không cần hỏi ai | | ⚠ Câu trả lời nhất quán với mọi người | ⚠ không phụ thuộc vào việc hỏi đúng ai | | ⚠ Chính sách đã cân nhắc các yếu tố người trả lời có thể quên | ⚠ tuân thủ, lưu trữ, bảo mật, phân loại thông tin | | ⚠ Giảm phụ thuộc vào scrum master | ⚠ đội tự chủ hơn | | ⚠ Khi nào KHÔNG nên chỉ tới tài liệu | ⚠ khi chính sách không tồn tại, khi nó mơ hồ, hoặc khi tình huống là ngoại lệ — lúc đó chỉ tới tài liệu trở thành cách né câu hỏi |

⚠ Chính sách tài liệu của dự án thường quy định gì: | Nội dung | Chi tiết | |---|---| | ⚠ Tài liệu nào phải LƯU và lưu Ở ĐÂU | ⚠ kho dùng chung, không phải hộp thư cá nhân | | ⚠ Quy ước ĐẶT TÊN và ĐÁNH PHIÊN BẢN | | | ⚠ AI được xem, ai được sửa | ⚠ phân loại thông tin và quyền truy cập | | ⚠ Giữ trong bao lâu | ⚠ yêu cầu lưu trữ và tuân thủ — liên hệ #26479 lô 194 | | ⚠ Ai duyệt trước khi gửi ra ngoài | ⚠ câu hỏi mà lập trình viên trẻ có lẽ nên hỏi TRƯỚC khi gửi | | ⚠ Nhận xét về tình huống | ⚠ lập trình viên đã GỬI báo cáo rồi mới hỏi phải làm gì tiếp — Tiffany nên nhân dịp này để anh đọc chính sách đầy đủ, vì phần "ai duyệt trước khi gửi" có thể đã bị bỏ qua |

⚠ Vai trò của scrum master trong những tình huống như thế này: | Việc | Nội dung | |---|---| | ⚠ HƯỚNG DẪN, không ra lệnh | ⚠ chỉ tới nguồn, để người ta tự quyết | | ⚠ Bảo đảm đội biết các quy trình hiện hành | ⚠ đặc biệt với thành viên mới hoặc trẻ | | ⚠ Gỡ vật cản nếu chính sách gây khó | ⚠ liên hệ #26475 lô 194 | | ⚠ Không trở thành nút cổ chai của mọi câu hỏi | ⚠ đội hỏi scrum master mọi thứ là dấu hiệu đội chưa tự chủ | | ⚠ Nguyên tắc bao trùm | ⚠ thước đo của một scrum master giỏi là đội cần anh ta ÍT DẦN theo thời gian — trả lời thay cho mọi câu hỏi thì thước đo đó đi ngược |

Từ khoá nhận diện:

"đã có chính sách cho việc này" → ⚠ CHỈ NGƯỜI HỎI TỚI CHÍNH SÁCH "tự đặt ra một cách làm mới cho một người" → ⚠ phá tính nhất quán "đưa vào hồi cứu" → ⚠ hồi cứu bàn về cách làm việc, không phải nơi báo cáo "không làm gì" → ⚠ bỏ qua lưu trữ và truy vết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có chính sách tài liệu không, và đội có biết nó ở đâu không | | | Báo cáo gửi ra ngoài của bạn có ai duyệt trước không | | | Có câu hỏi nào cả đội đều hỏi bạn nhiều lần không | ⚠ đó là câu hỏi cần một tài liệu, không cần thêm một câu trả lời |

Và dấu hiệu nhỏ nhưng đáng chú ý trong tình huống này: một lập trình viên trẻ hỏi "sau khi gửi thì làm gì" nghĩa là anh ta đã gửi trước khi biết quy trình — và câu trả lời hữu ích nhất không phải là bước tiếp theo, mà là bước anh đã bỏ qua.

Đáp án

C — Bảo đảm MỌI cuộc họp đều thân thiện với người ở xa, dùng công nghệ để cả đội tham dự được qua máy tính hoặc điện thoại.

Vì sao đúng

⚠ Vì sao đây là hành động đúng: | Lý do | Nội dung | |---|---| | ⚠ Đội NỬA tại chỗ, NỬA từ xa | ⚠ môi trường "bán ảo" — dạng khó nhất | | ⚠ Vấn đề cần XỬ LÝ GẤP và CÙNG NHAU | ⚠ nhà cung cấp bỏ đi, việc dở dang, không có tài liệu bàn giao | | ⚠ Cần đóng góp của MỌI người, không sót ai | ⚠ phải ghép lại bức tranh từ trí nhớ của cả đội | | ⚠ Nếu ai đó bị thiệt về kênh, thông tin của họ sẽ mất | ⚠ và đó có thể đúng là mảnh còn thiếu | | ⚠ Kết luận | ⚠ san bằng sân chơi trước, rồi mới bàn nội dung |

⚠ Nguyên tắc "một người ở xa thì tất cả ở xa": ⚠ khi có bất kỳ ai tham dự từ xa, cách công bằng nhất là MỌI NGƯỜI cùng vào từ máy của mình ⚠ — ⚠ vì một phòng họp có tám người và hai người trên loa luôn tạo ra hai hạng công dân: người trong phòng nói chen, trao đổi bằng ánh mắt, và người ở xa không bao giờ chen kịp.

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

• B (họp ở phòng hội thảo, người văn phòng dự trực tiếp, người còn lại dự trực tuyến) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó thoạt nhìn rất hợp lý và là cách đại đa số tổ chức thật vẫn làm: ⚠ nhưng ⚠ đó chính là mô hình tạo ra sự bất bình đẳng ⚠ — người ở xa nghe tiếng vọng, không thấy bảng trắng, không bắt được các trao đổi nhỏ trong phòng; ⚠ trong một buổi cần moi thông tin từ mọi người, thiết kế này làm mất đúng phần đóng góp của một nửa đội.

• A (gửi email rồi tổng hợp phản hồi) — ⚠ quá chậm cho một tình huống gấp, ⚠ và giao tiếp một chiều không cho phép hỏi lại, đối chiếu, ghép mảnh.

• D (họp nhanh ở hành lang với người có mặt rồi gửi kết quả cho cả đội) — ⚠ tệ nhất: ⚠ nửa đội bị loại khỏi cuộc thảo luận và chỉ nhận kết quả đã chốt.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26512 cùng lô (ba tầng của làm việc từ xa), ⚠ #26467 lô 194 (đội cùng chỗ và giao tiếp thẩm thấu), ⚠ #26421/#26366 (công cụ cho đội phân tán), ⚠ #26477 lô 194 (gắn kết bên liên quan), ⚠ #26505 cùng lô (cận ngôn ngữ — thứ mất đi khi họp qua loa phòng).

⚠ Vì sao đội BÁN ẢO khó hơn cả đội hoàn toàn từ xa: | Vấn đề | Nội dung | |---|---| | ⚠ Hình thành hai NHÓM NHỎ tự nhiên | ⚠ người văn phòng và người ở nhà | | ⚠ Thông tin không chính thức chỉ chảy trong nhóm văn phòng | ⚠ liên hệ #26467 lô 194 — giao tiếp thẩm thấu chỉ có ở một phía | | ⚠ Quyết định hình thành ngoài hành lang | ⚠ đúng phương án D — và nó xảy ra rất thật | | ⚠ Người ở xa dần mất tiếng nói | ⚠ rồi mất cả sự gắn bó | | ⚠ Nghịch lý | ⚠ một đội HOÀN TOÀN từ xa thường công bằng hơn một đội bán ảo, vì ai cũng ở cùng một hoàn cảnh — bất bình đẳng sinh ra từ sự PHA TRỘN, không từ khoảng cách |

⚠ Làm cho cuộc họp thân thiện với người ở xa: | Việc | Nội dung | |---|---| | ⚠ Mỗi người vào từ máy riêng, kể cả người ngồi cùng phòng | ⚠ quy tắc quan trọng nhất | | ⚠ Bật camera | ⚠ trả lại tầng phi ngôn ngữ — liên hệ #26505 cùng lô | | ⚠ Dùng bảng trắng số, không dùng bảng vật lý | | | ⚠ Có người điều phối chú ý mời người ở xa phát biểu | | | ⚠ Ghi chú chung theo thời gian thực, ai cũng xem được | | | ⚠ Quyết định chỉ được chốt TRONG cuộc họp | ⚠ không chốt lại ở hành lang sau đó | | ⚠ Chi phí và lợi ích | ⚠ người ở văn phòng thấy bất tiện khi phải đeo tai nghe dù ngồi cạnh nhau — đó là cái giá nhỏ để đổi lấy việc một nửa đội không bị vô hình |

⚠ Việc Claude cần làm trong chính cuộc họp đó: | Việc | Nội dung | |---|---| | ⚠ Xác định công việc nào ĐÃ xong, dựa trên trí nhớ của cả đội | ⚠ nhà cung cấp không để lại tài liệu | | ⚠ Lập danh sách việc còn dở | | | ⚠ Đánh giá tác động lên tiến độ và chi phí | | | ⚠ Quyết: đội tự làm hay tìm nhà cung cấp khác | ⚠ liên hệ #26509 cùng lô | | ⚠ Ghi vào SỔ VẤN ĐỀ với chủ sở hữu và hạn | ⚠ liên hệ #26498 cùng lô | | ⚠ Bài học cho hợp đồng sau | ⚠ yêu cầu bàn giao tài liệu ĐỊNH KỲ trong suốt hợp đồng, không phải ở cuối — vì "cuối" là thứ nhà cung cấp bỏ đi giữa chừng sẽ không bao giờ tới |

Từ khoá nhận diện:

"đội nửa tại chỗ nửa từ xa" → ⚠ MỌI NGƯỜI VÀO HỌP TỪ MÁY RIÊNG "phòng họp + người trên loa" → ⚠ mô hình tạo hai hạng người tham dự "gửi email rồi tổng hợp" → ⚠ một chiều, chậm, không đối chiếu được "họp hành lang rồi báo lại" → ⚠ loại nửa đội ra khỏi quyết định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong họp gần nhất, người ở xa nói bao nhiêu phút | ⚠ so với người trong phòng | | Quyết định của đội bạn hình thành ở đâu | ⚠ trong cuộc họp hay sau đó ở hành lang | | Người ở xa có bị hỏi lại "xin lỗi, nhắc lại được không" nhiều lần không | |

Và điều mà một chiếc loa hội nghị đặt giữa bàn thật sự truyền đi: rằng cuộc họp đang diễn ra trong căn phòng đó, và những người ở đầu dây kia là khán giả.

Đáp án

D — Ghi vào DANH SÁCH THEO DÕI rủi ro mức thấp (low-level risk watchlist).

Vì sao đúng

⚠ Vì sao rủi ro thấp vẫn phải được ghi lại: | Lý do | Nội dung | |---|---| | ⚠ Chúng đã được NHẬN DIỆN — tri thức không nên vứt đi | | | ⚠ Rủi ro có thể LỚN LÊN khi bối cảnh đổi | ⚠ liên hệ #26493 cùng lô — rủi ro phải rà soát liên tục | | ⚠ Danh sách theo dõi là cơ chế chính thức của PMBOK | ⚠ một phần của sổ đăng ký rủi ro | | ⚠ Không tốn nguồn lực phân tích sâu hay lập ứng phó | ⚠ chỉ theo dõi định kỳ | | ⚠ Kết luận | ⚠ giữ lại thông tin mà không đầu tư quá mức — phản ứng tương xứng |

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

• C (CHẤP NHẬN rủi ro và LOẠI BỎ chúng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ CHẤP NHẬN đúng là chiến lược hợp lệ cho rủi ro nhỏ, nên nửa đầu của phương án hoàn toàn chính xác: ⚠ nhưng ⚠ chữ "LOẠI BỎ" (dismiss) mới là chỗ sai ⚠ — chấp nhận thụ động vẫn nghĩa là ghi lại và theo dõi, không phải xoá khỏi tầm mắt; ⚠ một phương án đúng một nửa vẫn là phương án sai, và đây là bẫy rất hay gặp.

• A (đưa sang phân tích ĐỊNH LƯỢNG) — ⚠ lãng phí: ⚠ phân tích định lượng tốn kém, chỉ dành cho rủi ro lớn — đúng như đề đã nói về các rủi ro nghiêm trọng.

• B (ghi vào KẾ HOẠCH ỨNG PHÓ rủi ro) — ⚠ rủi ro mức thấp thường KHÔNG cần kế hoạch ứng phó riêng; ⚠ lập ứng phó cho mọi rủi ro nhỏ là chôn kế hoạch trong giấy tờ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26493 cùng lô (rà soát rủi ro liên tục), ⚠ #26494 cùng lô (năm chiến lược ứng phó), ⚠ #26498 cùng lô (sổ vấn đề so với sổ rủi ro), ⚠ #26462 lô 194 (rủi ro tồn dư), ⚠ #26480 lô 194 (theo dõi rủi ro chưa thành hình).

⚠ PHÂN TÍCH ĐỊNH TÍNH — ba nhánh kết quả: | Mức rủi ro | Đi về đâu | |---|---| | ⚠ CAO (xác suất cao × tác động lớn) | ⚠ phân tích ĐỊNH LƯỢNG rồi lập kế hoạch ứng phó | | ⚠ TRUNG BÌNH | ⚠ lập kế hoạch ứng phó, không nhất thiết phân tích định lượng | | ⚠ THẤP (xác suất thấp × tác động nhỏ) | ⚠ DANH SÁCH THEO DÕI — câu này | | ⚠ Công cụ phân loại | ⚠ MA TRẬN XÁC SUẤT – TÁC ĐỘNG: chấm từng rủi ro vào ô, ô quyết định nhánh | | | ⚠ Lưu ý | ⚠ ngưỡng giữa ba nhóm do TỔ CHỨC đặt, dựa trên mức chấp nhận rủi ro — không có con số phổ quát | |

⚠ DANH SÁCH THEO DÕI hoạt động thế nào: | Khía cạnh | Nội dung | |---|---| | ⚠ Nằm trong sổ đăng ký rủi ro, ở một mục riêng | ⚠ không phải một tài liệu tách rời | | ⚠ Không phân tích sâu, không lập ứng phó chi tiết | | | ⚠ Được RÀ LẠI ở mỗi kỳ rà soát rủi ro | ⚠ liên hệ #26493 cùng lô | | ⚠ Rủi ro có thể ĐƯỢC NÂNG LÊN nếu xác suất hoặc tác động tăng | ⚠ đó là toàn bộ lý do nó tồn tại | | ⚠ Cũng có thể bị ĐÓNG khi không còn khả năng xảy ra | | | ⚠ Câu hỏi hay gặp trong đề | ⚠ "rủi ro thấp thì làm gì" — đáp án gần như luôn là danh sách theo dõi, không phải bỏ qua và cũng không phải phân tích tiếp |

⚠ Vì sao "chấp nhận rồi quên đi" là sai lầm nguy hiểm: | Lý do | Nội dung | |---|---| | ⚠ Bối cảnh dự án thay đổi liên tục | ⚠ một rủi ro nhỏ ở tháng đầu có thể lớn ở tháng sáu | | ⚠ Nhiều rủi ro nhỏ có thể CỘNG DỒN | ⚠ hoặc kích hoạt lẫn nhau | | ⚠ Không ghi lại thì không ai nhớ đã từng cân nhắc | ⚠ và sẽ tranh luận lại từ đầu | | ⚠ Mất bằng chứng cho việc mình đã làm đúng quy trình | | | ⚠ Phân biệt hai kiểu chấp nhận | ⚠ CHẤP NHẬN CHỦ ĐỘNG: ghi lại và lập dự phòng; CHẤP NHẬN THỤ ĐỘNG: ghi lại và theo dõi — cả hai đều có chữ GHI LẠI, và đó chính là điều phương án C thiếu |

Từ khoá nhận diện:

"xác suất thấp, tác động thấp" → ⚠ DANH SÁCH THEO DÕI RỦI RO MỨC THẤP "chấp nhận và loại bỏ" → ⚠ đúng nửa đầu, sai ở chữ loại bỏ "rủi ro nghiêm trọng" → ⚠ phân tích định lượng rồi lập ứng phó "phương án đúng một nửa" → ⚠ vẫn là phương án sai — kiểm cả câu, đừng dừng ở nửa đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có mục theo dõi mức thấp không | | | Có rủi ro nào từ mức thấp đã lớn lên mà bạn không nhận ra không | | | Bạn có rà lại danh sách theo dõi ở mỗi kỳ không | ⚠ không rà thì nó chỉ là một nghĩa trang thông tin |

Và lý do một danh sách rủi ro nhỏ vẫn đáng giữ: rủi ro thật sự làm hỏng dự án hiếm khi là rủi ro bạn đánh giá cao rồi chuẩn bị kỹ — nó thường là rủi ro bạn đã nhìn thấy một lần, chấm là "nhỏ", rồi không bao giờ nhìn lại.

Đáp án

A — 17.000 đô-la.

Vì sao đúng

⚠ Định nghĩa và phép tính: | Bước | Nội dung | |---|---| | ⚠ CHI PHÍ CƠ HỘI = giá trị của phương án TỐT NHẤT BỊ BỎ QUA | ⚠ không phải hiệu số, không phải giá trị của cái được chọn | | ⚠ Ban lãnh đạo chọn Dự án Deux — 22.000 đô | ⚠ phương án được chọn | | ⚠ Phương án bị bỏ là Dự án Uno — 17.000 đô | ⚠ giá trị bị từ bỏ | | ⚠ Vậy chi phí cơ hội = 17.000 đô | ⚠ toàn bộ giá trị của cơ hội đã không theo đuổi | | ⚠ Kết luận | ⚠ luôn lấy NGUYÊN giá trị của phương án bị bỏ, không trừ đi gì cả |

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

• B (5.000 đô) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ 22.000 − 17.000 = 5.000 là phép tính đầu tiên mà bộ não nhảy tới: ⚠ nhưng ⚠ 5.000 là LỢI ÍCH GIA TĂNG của việc chọn Deux thay vì Uno, KHÔNG phải chi phí cơ hội ⚠ — đó là hai đại lượng khác nhau, và đề PMP cài phương án này ở gần như mọi câu về chi phí cơ hội.

• C (22.000 đô) — ⚠ là giá trị của dự án ĐƯỢC CHỌN; ⚠ nhầm chiều hoàn toàn.

• D (bằng không vì Deux có giá trị lớn hơn) — ⚠ hiểu sai bản chất: ⚠ chi phí cơ hội luôn tồn tại khi phải chọn một trong nhiều phương án loại trừ nhau, bất kể chọn đúng hay sai.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26346/#26360 lô 192 (chọn dự án theo NPV cao nhất), ⚠ #26503 cùng lô (phân loại chi phí), ⚠ #26488 cùng lô (dự trữ quản lý), ⚠ #26478 lô 194 (chênh lệch chi phí).

⚠ CÁC KHÁI NIỆM CHỌN DỰ ÁN thường bị lẫn: | Khái niệm | Định nghĩa | Trong ví dụ này | |---|---|---| | ⚠ CHI PHÍ CƠ HỘI | ⚠ giá trị phương án tốt nhất BỊ BỎ | ⚠ 17.000 đô | | ⚠ Lợi ích gia tăng | ⚠ chênh lệch giữa hai phương án | ⚠ 5.000 đô | | ⚠ CHI PHÍ CHÌM | ⚠ tiền ĐÃ CHI, không thu hồi được | ⚠ không có trong ví dụ; nguyên tắc: KHÔNG được dùng để quyết định tiếp | | ⚠ NPV — giá trị hiện tại ròng | ⚠ giá trị dòng tiền quy về hiện tại | ⚠ chọn dự án có NPV cao nhất | | ⚠ IRR — tỉ suất hoàn vốn nội bộ | ⚠ tỉ lệ sinh lời | ⚠ càng cao càng tốt | | ⚠ Thời gian hoàn vốn | ⚠ bao lâu thu hồi vốn | ⚠ càng ngắn càng tốt, nhưng bỏ qua dòng tiền sau đó | | ⚠ Quy tắc vàng của chi phí cơ hội | ⚠ lấy NGUYÊN giá trị phương án bị bỏ — không trừ, không chia; nếu có ba phương án thì lấy cái TỐT NHẤT trong số bị bỏ | |

⚠ Vì sao chi phí cơ hội quan trọng với quản lý dự án: | Lý do | Nội dung | |---|---| | ⚠ Nguồn lực tổ chức là HỮU HẠN | ⚠ làm dự án này nghĩa là không làm dự án kia | | ⚠ Nó làm lộ ra cái giá ẩn của mọi lựa chọn | ⚠ kể cả lựa chọn đúng cũng có giá | | ⚠ Nó áp cả trong nội bộ một dự án | ⚠ giao người giỏi nhất cho tính năng A nghĩa là tính năng B mất họ | | ⚠ Nó là lập luận mạnh khi xin thêm nguồn lực | ⚠ "chậm dự án này thì tổ chức mất cơ hội kia" | | ⚠ Liên hệ với thực tế | ⚠ mọi quyết định xếp ưu tiên thực chất là một phép tính chi phí cơ hội — liên hệ #26464 lô 194 và #26507 cùng lô |

⚠ CHI PHÍ CHÌM — người anh em hay bị hỏi cùng: | Khía cạnh | Nội dung | |---|---| | ⚠ Là tiền ĐÃ CHI và KHÔNG thu hồi được | | | ⚠ Nguyên tắc: KHÔNG được đưa vào quyết định tiếp tục hay dừng | ⚠ chỉ nhìn chi phí và lợi ích TỪ ĐÂY VỀ SAU | | ⚠ Nguỵ biện chi phí chìm | ⚠ "đã tiêu 2 triệu rồi, giờ dừng thì phí" — lập luận sai kinh điển | | ⚠ Trong đề PMP | ⚠ mọi phương án viện dẫn số tiền đã chi để biện minh cho việc tiếp tục đều SAI — không có ngoại lệ |

Từ khoá nhận diện:

"chi phí cơ hội" → ⚠ NGUYÊN giá trị phương án bị bỏ "hiệu số giữa hai phương án" → ⚠ lợi ích gia tăng, bẫy phổ biến nhất "tiền đã chi rồi" → ⚠ chi phí chìm, bỏ qua khi ra quyết định "chọn cái lớn hơn nên không mất gì" → ⚠ hiểu sai: chi phí cơ hội luôn tồn tại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn đang khiến tổ chức không làm được việc gì khác | | | Có quyết định nào ở chỗ bạn được biện minh bằng số tiền đã tiêu không | ⚠ đó là nguỵ biện chi phí chìm | | Khi xếp ưu tiên, bạn có nêu rõ cái gì đang bị bỏ không | |

Và điều mà con số 17.000 đô nhắc ta: mọi lựa chọn đều có giá, kể cả lựa chọn đúng — và một tổ chức không bao giờ nói ra cái giá đó sẽ dần tin rằng mình có thể làm mọi thứ.

Đáp án

A — Alina phải BÁO NGAY cho nhà tài trợ dự án.

Vì sao đúng

⚠ Vì sao báo ngay là đúng đắn cả về nghiệp vụ lẫn đạo đức: | Lý do | Nội dung | |---|---| | ⚠ Thông tin đến từ MỘT BÀI BÁO CÔNG KHAI | ⚠ thông cáo báo chí — không có gì bí mật hay bất hợp pháp | | ⚠ Đây là RỦI RO NGHIÊM TRỌNG với tình huống kinh doanh | ⚠ sản phẩm được xây trên giả định "độc nhất" nay không còn độc nhất | | ⚠ Nhà tài trợ là người quyết định hướng đi của dự án | ⚠ tiếp tục, đổi hướng, tăng tốc, hay dừng — đều vượt thẩm quyền Alina | | ⚠ Giữ thông tin lại là VI PHẠM nghĩa vụ minh bạch | ⚠ quy tắc ứng xử của PMI đòi trung thực và kịp thời | | ⚠ Càng biết sớm càng nhiều lựa chọn | ⚠ đối thủ ra mắt TUẦN SAU — thời gian cực gấp | | ⚠ Kết luận | ⚠ leo thang đúng người, đúng lúc, với thông tin hợp pháp |

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

• B (không làm gì vì cô không được phép biết và hành động là phi đạo đức) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó khoác áo đạo đức, và đề PMP thường thưởng cho phương án đạo đức: ⚠ nhưng ⚠ tiền đề của nó SAI ⚠ — thông tin đến từ một bài báo công khai ai cũng đọc được, không phải bí mật kinh doanh bị rò rỉ; ⚠ và im lặng trước một rủi ro nghiêm trọng mới chính là hành vi phi đạo đức, vì nó khiến tổ chức tiếp tục đầu tư trên một giả định đã sai.

• D (thúc đội làm nhanh hơn để ra mắt trước) — ⚠ Alina TỰ QUYẾT một thay đổi chiến lược lớn; ⚠ và đối thủ ra mắt tuần sau — chạy đua là bất khả thi, chỉ tổ đốt sức đội và hại chất lượng.

• C (đề nghị mua lại phần mềm của bạn mình) — ⚠ vượt xa thẩm quyền, ⚠ và dùng quan hệ cá nhân cho một giao dịch giữa hai công ty là xung đột lợi ích rõ ràng.

⚠ Ranh giới đạo đức cần phân biệt rõ: ⚠ nếu người bạn tiết lộ THÔNG TIN NỘI BỘ chưa công bố thì Alina KHÔNG được dùng — đó mới là tình huống của phương án B ⚠ — ⚠ nhưng ở đây là thông cáo báo chí công khai, nên việc dùng nó là hoàn toàn hợp pháp và bắt buộc phải làm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26484 cùng lô (vấn đề pháp lý — leo thang đúng bộ phận), ⚠ #26442 lô 194 (cơ hội ngoài phạm vi thì leo thang), ⚠ #26480 lô 194 (rủi ro bên ngoài — theo dõi hay hành động), ⚠ #26451 lô 194 (không lách quy định), ⚠ #26452 lô 194 (tuân thủ không thương lượng).

⚠ Vì sao thông tin này quan trọng tới mức phải báo ngay: | Tác động | Nội dung | |---|---| | ⚠ TÌNH HUỐNG KINH DOANH có thể không còn hiệu lực | ⚠ dự án được duyệt dựa trên tính độc nhất | | ⚠ Lợi thế người đi đầu đã mất | | | ⚠ Có thể cần đổi ĐỊNH VỊ sản phẩm | ⚠ khác biệt hoá thay vì độc nhất | | ⚠ Có thể cần đổi phạm vi hoặc thời điểm ra mắt | | | ⚠ Có thể phải xem xét dừng dự án | ⚠ quyết định chỉ nhà tài trợ mới có quyền | | ⚠ Điều Alina KHÔNG nên làm | ⚠ tự đánh giá xem tin này có nghiêm trọng không rồi quyết định có báo hay không — việc của cô là báo, việc của nhà tài trợ là đánh giá |

⚠ Cách Alina nên báo: | Việc | Nội dung | |---|---| | ⚠ Báo NGAY, không đợi buổi báo cáo định kỳ | ⚠ đối thủ ra mắt tuần sau | | ⚠ Kèm NGUỒN: đường dẫn tới bài báo công khai | ⚠ để nhà tài trợ tự kiểm chứng | | ⚠ Nêu rõ đây là thông tin CÔNG KHAI | ⚠ tránh mọi hiểu lầm về nguồn gốc | | ⚠ Trình bày TÁC ĐỘNG có thể có, không kèm kết luận | ⚠ cô cung cấp phân tích, không cung cấp quyết định | | ⚠ Ghi vào SỔ RỦI RO hoặc SỔ VẤN ĐỀ | ⚠ liên hệ #26498 cùng lô — đây thực chất đã là VẤN ĐỀ, vì sự kiện đã chắc chắn xảy ra | | ⚠ Điều nên tránh | ⚠ nói với đội trước khi nói với nhà tài trợ — tin đồn về việc dự án có thể bị dừng lan nhanh hơn mọi thông báo chính thức |

⚠ Quy tắc ứng xử của PMI liên quan tới tình huống này: | Giá trị | Nội dung | |---|---| | ⚠ TRÁCH NHIỆM | ⚠ báo cáo kịp thời điều ảnh hưởng tới tổ chức | | ⚠ TRUNG THỰC | ⚠ không giấu thông tin bất lợi | | ⚠ CÔNG BẰNG | ⚠ không dùng quan hệ cá nhân để trục lợi — lý do phương án C sai | | ⚠ TÔN TRỌNG | ⚠ không dùng thông tin có được một cách không chính đáng | | ⚠ Nguyên tắc thực dụng | ⚠ nếu thông tin CÔNG KHAI thì dùng và báo; nếu là bí mật của bên khác thì không dùng và cũng không báo — hai vế này không được lẫn vào nhau |

Từ khoá nhận diện:

"thông tin công khai ảnh hưởng tới dự án" → ⚠ BÁO NGAY CHO NHÀ TÀI TRỢ "im lặng cho đạo đức" → ⚠ sai tiền đề khi thông tin là công khai "tự thúc đội chạy đua" → ⚠ tự quyết thay đổi chiến lược, vượt thẩm quyền "dùng quan hệ cá nhân để giao dịch" → ⚠ xung đột lợi ích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có theo dõi thông tin thị trường liên quan tới dự án không | ⚠ hay chỉ nhìn vào bên trong | | Khi biết tin xấu, bạn báo trong bao lâu | | | Bạn có phân biệt được thông tin công khai và thông tin nội bộ của bên khác không | |

Và phép thử đơn giản cho mọi tình huống dạng này: nếu ba tháng sau người ta hỏi "lúc đó anh có biết không?", câu trả lời duy nhất bạn muốn có là "có, và tôi đã báo ngay ngày hôm đó".

Đáp án

C — Nó KÉM CHÍNH XÁC hơn (less accurate).

Vì sao đúng

⚠ Vì sao ước lượng tương tự kém chính xác: | Lý do | Nội dung | |---|---| | ⚠ Dựa trên MỘT dự án trước đó ở mức TỔNG THỂ | ⚠ không phân rã, không tính từng phần | | ⚠ Hai dự án "giống nhau" luôn có khác biệt chưa lộ ra | ⚠ đội khác, bối cảnh khác, yêu cầu khác đôi chút | | ⚠ Nó là ước lượng TỪ TRÊN XUỐNG | ⚠ ngược với từ dưới lên, kỹ thuật chính xác nhất | | ⚠ Bù lại: NHANH và RẺ | ⚠ đó chính là lý do người ta vẫn dùng nó | | ⚠ Kết luận | ⚠ đánh đổi kinh điển: tốc độ đổi lấy độ chính xác |

⚠ Vì sao Angel vẫn chọn đúng: ⚠ cô mới ở giai đoạn LẬP ƯỚC LƯỢNG CHI PHÍ ban đầu và có một dự án tương tự mới hoàn thành vài tháng trước ⚠ — ⚠ đó là điều kiện lý tưởng cho ước lượng tương tự; ⚠ "kém chính xác hơn" là một ĐẶC ĐIỂM cần biết và công bố, không phải một lỗi.

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

• D (nó CHÍNH XÁC HƠN) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó chỉ khác đáp án đúng một chữ, và người đọc vội rất dễ chọn nhầm: ⚠ nhưng ⚠ ngược hoàn toàn với sự thật ⚠ — trong bộ kỹ thuật ước lượng, tương tự nằm ở đáy về độ chính xác; ⚠ cặp phương án đối nghịch nhau như thế này luôn nghĩa là một trong hai là đáp án — hãy đọc kỹ chữ cuối.

• A (nó là ước lượng TỪ DƯỚI LÊN) — ⚠ SAI VỀ ĐỊNH NGHĨA: ⚠ tương tự là từ trên xuống, từ dưới lên là kỹ thuật hoàn toàn khác và cho độ chính xác cao nhất.

• B (nó là PHÂN TÍCH HỒI QUY) — ⚠ hồi quy là một kỹ thuật THỐNG KÊ, thuộc nhóm ước lượng tham số, không phải tương tự.

Ghi nhớ

⚠ Đối chiếu — BỘ ƯỚC LƯỢNG: ⚠ #26492 cùng lô (CSDL ước lượng thương mại), ⚠ #26502 cùng lô (đầu vào của ước lượng thời lượng), ⚠ #26522 cùng lô (ước lượng ba điểm), ⚠ #26413 lô 193 (từ dưới lên), ⚠ #26291 lô 191 (các mức độ chính xác), ⚠ #26331 lô 191 (phán đoán chuyên gia).

⚠ CÁC KỸ THUẬT ƯỚC LƯỢNG xếp theo ĐỘ CHÍNH XÁC: | Kỹ thuật | Độ chính xác | Chi phí và thời gian | Dùng khi | |---|---|---|---| | ⚠ TƯƠNG TỰ (analogous) | ⚠ THẤP NHẤT — câu này | ⚠ rẻ và nhanh nhất | ⚠ giai đoạn đầu, ít thông tin, có dự án tương tự | | ⚠ THAM SỐ (parametric) | ⚠ trung bình đến cao | ⚠ trung bình | ⚠ có định mức đơn vị đáng tin cậy | | ⚠ BA ĐIỂM | ⚠ trung bình đến cao | ⚠ trung bình | ⚠ bất định cao, cần thể hiện khoảng | | ⚠ TỪ DƯỚI LÊN | ⚠ CAO NHẤT | ⚠ đắt và chậm nhất | ⚠ có WBS chi tiết, cần con số cam kết | | ⚠ Quy luật xuyên suốt | ⚠ độ chính xác TỈ LỆ THUẬN với công sức bỏ ra — không có kỹ thuật nào vừa nhanh vừa chính xác | | |

⚠ ƯỚC LƯỢNG TƯƠNG TỰ dùng đúng cách: | Việc | Nội dung | |---|---| | ⚠ Chọn dự án tham chiếu THẬT SỰ giống | ⚠ giống về quy mô, công nghệ, đội, bối cảnh — không chỉ giống tên | | ⚠ ĐIỀU CHỈNH cho các khác biệt đã biết | ⚠ quy mô lớn hơn 30% thì không nhân đơn giản 1,3 — thường có yếu tố phi tuyến | | ⚠ Kết hợp với PHÁN ĐOÁN CHUYÊN GIA | ⚠ người từng làm dự án cũ biết chỗ nào khác — liên hệ #26331 lô 191 | | ⚠ CÔNG BỐ RÕ mức sai số | ⚠ bậc độ lớn thô: −25% tới +75%, liên hệ #26291 lô 191 | | ⚠ CAM KẾT ước lượng lại khi có thêm thông tin | ⚠ liên hệ #26448 lô 194 | | ⚠ Sai lầm chết người | ⚠ để một ước lượng tương tự trở thành ngân sách chính thức mà không ai nhớ nó chỉ là con số ban đầu — đây là nguyên nhân gốc của rất nhiều dự án "vượt chi" |

⚠ Vì sao "kém chính xác" không có nghĩa là "tệ": | Lý do | Nội dung | |---|---| | ⚠ Ở giai đoạn đầu KHÔNG CÓ dữ liệu cho kỹ thuật chính xác hơn | ⚠ chưa có WBS thì không thể ước lượng từ dưới lên | | ⚠ Chi phí của việc ước lượng cũng là chi phí dự án | ⚠ ước lượng từ dưới lên cho một ý tưởng chưa được duyệt là lãng phí | | ⚠ Một con số thô có kèm sai số hữu ích hơn KHÔNG có con số nào | | | ⚠ Nguyên tắc | ⚠ chọn kỹ thuật theo lượng THÔNG TIN đang có và mức CHÍNH XÁC đang cần — không phải theo kỹ thuật nào nghe chuyên nghiệp nhất |

Từ khoá nhận diện:

"ước lượng tương tự" → ⚠ TỪ TRÊN XUỐNG, nhanh, rẻ, KÉM CHÍNH XÁC "từ dưới lên" → ⚠ chính xác nhất, tốn công nhất "phân tích hồi quy" → ⚠ thuộc nhóm tham số hai phương án đối nghịch nhau → ⚠ một trong hai là đáp án, đọc kỹ chữ cuối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Con số ước lượng hiện tại của bạn đến từ kỹ thuật nào | | | Bạn có công bố mức sai số kèm theo không | | | Có ai đang coi ước lượng sơ bộ của bạn là cam kết không | |

Và điều mà mọi ước lượng tương tự cần đi kèm nhưng thường bị bỏ quên: một câu nói rõ nó sai được bao nhiêu — vì con số thì luôn được nhớ, còn giới hạn của nó thì không.

Đáp án

D — KHEN NGỢI cá nhân đó TRONG BUỔI HỌP ĐỘI kế tiếp.

Vì sao đúng

⚠ Vì sao ghi nhận công khai là phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Thành tích liên quan tới một MỐC QUAN TRỌNG của dự án | ⚠ cả đội có lợi từ việc biết điều này | | ⚠ Lần đầu người đó tự triển khai không cần hỗ trợ | ⚠ một bước trưởng thành đáng đánh dấu | | ⚠ Ghi nhận công khai củng cố hành vi cho CẢ ĐỘI | ⚠ cho thấy tiêu chuẩn nào được coi trọng | | ⚠ Nó thoả mãn nhu cầu VỊ THẾ trong mô hình SCARF | ⚠ liên hệ #26460 lô 194 | | ⚠ Nancy làm được ngay, không cần xin phép ai | ⚠ quan trọng vì đây là MA TRẬN YẾU | | ⚠ Kết luận | ⚠ kịp thời, công khai, trong tầm thẩm quyền |

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

• A (khen RIÊNG cá nhân đó) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ khen riêng là việc tốt, chân thành, và tránh làm người hướng nội khó xử: ⚠ nhưng ⚠ nó BỎ MẤT hiệu ứng lan toả tới cả đội ⚠ — đề nhấn mạnh đây là mốc quan trọng của dự án, tức là chuyện của tập thể; ⚠ cách tốt nhất là làm CẢ HAI, nhưng nếu chỉ chọn một thì công khai mang lại nhiều giá trị hơn.

• B (email cho quản lý của người đó) — ⚠ cũng là việc nên làm và rất có giá trị trong ma trận yếu, ⚠ nhưng người được khen có thể không bao giờ biết, và cả đội cũng không biết; ⚠ nó là bổ sung, không phải hành động chính.

• C (tăng lương) — ⚠ NGOÀI THẨM QUYỀN của Nancy: ⚠ trong ma trận yếu, quản lý chức năng mới quyết lương; ⚠ và tăng lương cho một lần hoàn thành việc là phản ứng không tương xứng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26488 cùng lô (hệ thống khen thưởng), ⚠ #26504 cùng lô (củng cố trong ADKAR), ⚠ #26460 lô 194 (SCARF — vị thế), ⚠ #26513 cùng lô (các cơ cấu tổ chức), ⚠ #26469 lô 194 (lòng tin trong đội).

⚠ Vì sao chi tiết MA TRẬN YẾU quyết định câu trả lời: | Khía cạnh | Nội dung | |---|---| | ⚠ Nancy KHÔNG quản lương, thăng chức, đánh giá hiệu suất | ⚠ loại thẳng phương án C | | ⚠ Thành viên báo cáo cho quản lý chức năng | ⚠ nên phương án B có giá trị BỔ SUNG thật | | ⚠ Công cụ Nancy CÓ là sự ghi nhận và quan hệ | ⚠ quyền lực tham chiếu, không phải quyền lực vị trí — liên hệ #26489 cùng lô | | ⚠ Bài học chung | ⚠ trong ma trận yếu, quản lý dự án phải dùng những đòn bẩy KHÔNG tốn tiền và KHÔNG cần thẩm quyền: ghi nhận, cơ hội học hỏi, giao việc thú vị, và nói tốt về người ta với quản lý của họ |

⚠ Ghi nhận công khai — làm sao cho hiệu quả: | Nguyên tắc | Nội dung | |---|---| | ⚠ KỊP THỜI | ⚠ buổi họp kế tiếp, không phải cuối quý | | ⚠ CỤ THỂ | ⚠ nói rõ đã làm gì và vì sao nó quan trọng, không nói chung chung "làm tốt lắm" | | ⚠ CHÂN THÀNH | ⚠ khen quá lời làm mất giá trị của mọi lời khen sau đó | | ⚠ CÔNG BẰNG | ⚠ đừng luôn khen cùng một người — liên hệ #26460 lô 194, Fairness | | ⚠ Chú ý tính cách người nhận | ⚠ người rất hướng nội có thể thấy ngại — biết trước thì khen ngắn gọn | | ⚠ Cách bao quát nhất | ⚠ khen công khai TRONG đội + báo riêng cho quản lý chức năng + một lời cảm ơn riêng — ba việc, tốn năm phút, và chạm được cả ba nhu cầu khác nhau |

⚠ Sự khác nhau giữa GHI NHẬN và KHEN THƯỞNG: | | Ghi nhận (recognition) | Khen thưởng (reward) | |---|---|---| | ⚠ Hình thức | ⚠ lời nói, sự chú ý, công nhận công khai | ⚠ vật chất: tiền, quà, ngày nghỉ | | ⚠ Chi phí | ⚠ gần như bằng không | ⚠ cần ngân sách | | ⚠ Ai làm được | ⚠ BẤT KỲ AI, kể cả đồng nghiệp | ⚠ người có thẩm quyền ngân sách | | ⚠ Hiệu lực | ⚠ tức thì, lặp lại được thường xuyên | ⚠ mạnh nhưng dễ thành kỳ vọng | | ⚠ Trong tình huống này | ⚠ Nancy chỉ có công cụ đầu — và đó là công cụ đủ dùng, liên hệ #26488 cùng lô | |

Từ khoá nhận diện:

"ghi nhận thành tích, mốc quan trọng" → ⚠ KHEN CÔNG KHAI TRONG BUỔI HỌP ĐỘI "khen riêng" → ⚠ tốt nhưng mất hiệu ứng lan toả "email cho quản lý của họ" → ⚠ giá trị bổ sung, đặc biệt trong ma trận yếu "tăng lương" → ⚠ ngoài thẩm quyền quản lý dự án trong ma trận yếu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần gần nhất bạn khen ai đó trước cả đội là khi nào | | | Bạn có báo lại thành tích cho quản lý chức năng của họ không | ⚠ điều này ảnh hưởng tới đánh giá cuối năm của họ | | Bạn có đang khen đi khen lại cùng một vài người không | |

Và lý do năm phút đầu buổi họp dành cho việc ghi nhận không bao giờ là thời gian lãng phí: nó là cách rẻ nhất để nói với cả đội rằng ở đây, việc làm tốt được người khác nhìn thấy — và đó là thứ mà không có ngân sách nào mua được nếu bạn không nói ra.

Đáp án

B — ĐIỂM CÂU CHUYỆN (story points).

Vì sao đúng

⚠ Vì sao điểm câu chuyện là câu trả lời: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Đội ĐÁNH GIÁ ĐỘ KHÓ của các yêu cầu | ⚠ đúng chức năng của điểm câu chuyện | | ⚠ Mục đích: biết bao nhiêu yêu cầu làm được trong một sprint | ⚠ tổng điểm làm được chính là TỐC ĐỘ của đội | | ⚠ Đề dùng chữ "xếp hạng/đánh giá" (rating) | ⚠ điểm câu chuyện là một thang đo TƯƠNG ĐỐI | | ⚠ Bối cảnh agile | ⚠ thuật ngữ chuẩn của Scrum và các khung agile | | ⚠ Kết luận | ⚠ khái niệm duy nhất trong bốn phương án là một THANG ĐO cho hạng mục công việc |

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

• A (BACKLOG SPRINT) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là thứ chứa chính các yêu cầu được nói tới, nên xuất hiện đúng chỗ trong tình huống: ⚠ nhưng ⚠ backlog sprint là một DANH SÁCH công việc, không phải một thang đánh giá ⚠ — nó là cái được đo, không phải thước đo; ⚠ đây là bẫy lẫn giữa vật chứa và đơn vị đo.

• D (bỏ phiếu NẮM TAY TỚI NĂM — fist-to-five) — ⚠ là kỹ thuật đo mức ĐỒNG THUẬN với một quyết định, không phải đo độ khó công việc; ⚠ giơ nắm tay là phản đối, giơ năm ngón là hoàn toàn ủng hộ.

• C (PHÂN TÍCH GIÁ TRỊ) — ⚠ về GIÁ TRỊ kinh doanh của hạng mục, không phải về CÔNG SỨC; ⚠ hai trục khác nhau, dù cả hai đều dùng để xếp ưu tiên.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26499 cùng lô (planning poker — công cụ để gán điểm câu chuyện), ⚠ #26506 cùng lô (Scrum), ⚠ #26490 cùng lô (định nghĩa hoàn thành), ⚠ #26519 cùng lô (các kỹ thuật ước lượng), ⚠ #26464 lô 194 (xếp ưu tiên).

⚠ ĐIỂM CÂU CHUYỆN — bản chất và cách dùng: | Khía cạnh | Nội dung | |---|---| | ⚠ Đo cái gì | ⚠ ĐỘ PHỨC TẠP + CÔNG SỨC + BẤT ĐỊNH — gộp trong một con số | | ⚠ KHÔNG đo cái gì | ⚠ KHÔNG đo giờ; đây là điểm hay bị hiểu sai nhất | | ⚠ Là thang TƯƠNG ĐỐI | ⚠ một hạng mục 8 điểm khó gấp đôi hạng mục 4 điểm, không nói gì về số giờ | | ⚠ Thang thường dùng | ⚠ Fibonacci: 1, 2, 3, 5, 8, 13, 21 — khoảng cách rộng dần vì việc càng lớn càng khó ước chính xác | | ⚠ Ai gán điểm | ⚠ ĐỘI PHÁT TRIỂN, không phải chủ sản phẩm hay quản lý | | ⚠ Gán bằng gì | ⚠ planning poker — liên hệ #26499 cùng lô | | ⚠ Vì sao dùng điểm thay vì giờ | ⚠ giờ khác nhau theo từng người; độ phức tạp thì cả đội nhìn giống nhau — và điểm không thể bị dùng để so sánh năng suất cá nhân, đó là một tính năng chứ không phải khiếm khuyết |

⚠ TỐC ĐỘ (velocity) — thứ điểm câu chuyện tạo ra: | Khía cạnh | Nội dung | |---|---| | ⚠ Là tổng điểm HOÀN THÀNH trong một sprint | ⚠ chỉ tính hạng mục đạt định nghĩa hoàn thành — liên hệ #26490 cùng lô | | ⚠ Dùng để DỰ BÁO | ⚠ backlog còn 200 điểm, tốc độ 40 → còn khoảng 5 sprint | | ⚠ Ổn định sau vài sprint đầu | ⚠ sprint đầu tiên gần như luôn sai | | ⚠ KHÔNG so sánh giữa các đội | ⚠ mỗi đội có thang riêng — 8 điểm của đội A không bằng 8 điểm của đội B | | ⚠ Cách lạm dụng phổ biến nhất | ⚠ dùng tốc độ làm chỉ tiêu năng suất và ép tăng — đội sẽ chỉ đơn giản chấm điểm cao hơn cho cùng một công việc, và bạn mất luôn công cụ dự báo |

⚠ Bốn phương án của câu này thuộc bốn phạm trù khác nhau: | Phương án | Là gì | |---|---| | ⚠ Điểm câu chuyện | ⚠ ĐƠN VỊ ĐO công sức — đáp án | | ⚠ Backlog sprint | ⚠ DANH SÁCH công việc của sprint | | ⚠ Phân tích giá trị | ⚠ PHƯƠNG PHÁP đánh giá giá trị kinh doanh | | ⚠ Nắm tay tới năm | ⚠ KỸ THUẬT đo đồng thuận | | ⚠ Kỹ thuật làm bài | ⚠ khi bốn phương án thuộc bốn phạm trù khác nhau, hãy xác định đề đang hỏi PHẠM TRÙ nào trước — ở đây đề hỏi "thuật ngữ mô tả việc XẾP HẠNG các yêu cầu", tức là hỏi một đơn vị đo |

Từ khoá nhận diện:

"đánh giá độ khó của yêu cầu" → ⚠ ĐIỂM CÂU CHUYỆN "danh sách công việc của sprint" → ⚠ backlog sprint "đo mức đồng thuận" → ⚠ nắm tay tới năm "giá trị kinh doanh" → ⚠ phân tích giá trị, khác trục với công sức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn ước lượng bằng điểm hay bằng giờ | | | Có ai đang so sánh tốc độ giữa các đội không | ⚠ đó là phép so sánh không có nghĩa | | Tốc độ của bạn có ổn định qua các sprint không | ⚠ dao động lớn thường nghĩa là định nghĩa hoàn thành chưa nhất quán |

Và điều mà điểm câu chuyện bảo vệ mà giờ công thì không: nó cho phép cả đội thừa nhận rằng một việc rất khó mà không ai phải nói mình sẽ làm chậm.

Đáp án

A — 6 TUẦN.

Vì sao đúng

⚠ Tính bằng phân phối TAM GIÁC (trung bình đơn giản): | Bước | Phép tính | Kết quả | |---|---|---| | ⚠ Lạc quan (O) | ⚠ đề cho | ⚠ 4 | | ⚠ Khả dĩ nhất (M) | ⚠ đề cho | ⚠ 5 | | ⚠ Bi quan (P) | ⚠ đề cho | ⚠ 9 | | ⚠ Công thức tam giác | ⚠ (O + M + P) ÷ 3 | | | ⚠ Thay số | ⚠ (4 + 5 + 9) ÷ 3 = 18 ÷ 3 | ⚠ 6 TUẦN | | ⚠ Kết luận | ⚠ khớp chính xác phương án A |

⚠ Ghi nhớ về chất lượng câu hỏi — đề KHÔNG nói rõ dùng phân phối nào: ⚠ "ước lượng ba điểm" có HAI công thức, và chúng cho hai kết quả khác nhau ⚠ — ⚠ TAM GIÁC: (4 + 5 + 9) ÷ 3 = 6 ⚠ (khớp đáp án); ⚠ PERT BETA: (O + 4M + P) ÷ 6 = (4 + 20 + 9) ÷ 6 = 33 ÷ 6 = 5,5 ⚠ (KHÔNG có trong các phương án). ⚠ Vì 5,5 không xuất hiện, đề ngầm định dùng TAM GIÁC ⚠ — ⚠ cách làm bài an toàn: tính CẢ HAI rồi chọn kết quả có mặt trong danh sách phương án; ⚠ cùng thủ thuật đã dùng ở #26417 lô 193.

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

• C (33,33 ngày) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ con số 33 chính là TỬ SỐ của công thức PERT (O + 4M + P = 33): ⚠ nhưng ⚠ nó là bước tính DỞ DANG — chưa chia cho 6 ⚠; ⚠ và nó còn đổi đơn vị sang NGÀY trong khi mọi dữ liệu đầu vào đều theo tuần — ⚠ đổi đơn vị giữa chừng luôn là dấu hiệu của một phương án bẫy.

• D (18 tuần) — ⚠ là TỔNG ba con số, chưa chia cho 3.

• B (3 tuần) — ⚠ không khớp phép tính nào; ⚠ có thể là số 3 của mẫu số bị lấy nhầm thành kết quả.

Ghi nhớ

⚠ Đối chiếu — BỘ ƯỚC LƯỢNG BA ĐIỂM: ⚠ #26241 lô 189 (vì sao dùng ba điểm cho việc chưa từng làm), ⚠ #26417 lô 193 (bài toán tam giác trong bối cảnh TIẾT KIỆM — giá trị lạc quan là số LỚN hơn), ⚠ #26519 cùng lô (ước lượng tương tự), ⚠ #26492 cùng lô (CSDL định mức), ⚠ #26502 cùng lô (đầu vào của ước lượng).

⚠ HAI CÔNG THỨC ba điểm — bảng so sánh: | | Tam giác (triangular) | PERT beta | |---|---|---| | ⚠ Công thức | ⚠ (O + M + P) ÷ 3 | ⚠ (O + 4M + P) ÷ 6 | | ⚠ Trọng số cho M | ⚠ bằng O và P | ⚠ gấp BỐN lần | | ⚠ Giả định | ⚠ ba khả năng ngang nhau | ⚠ giá trị khả dĩ nhất có xác suất cao hơn hẳn | | ⚠ Dùng khi | ⚠ ít dữ liệu, không tin M hơn hai cái kia | ⚠ có cơ sở tin vào M | | ⚠ Với số của bài này | ⚠ 6 tuần — đáp án | ⚠ 5,5 tuần | | ⚠ Mẹo làm bài | ⚠ PERT luôn kéo kết quả về gần M hơn; tam giác thì bị các giá trị cực đoan kéo mạnh hơn | |

⚠ Các công thức PERT khác cần nhớ: | Đại lượng | Công thức | Với bài này | |---|---|---| | ⚠ Trung bình PERT | ⚠ (O + 4M + P) ÷ 6 | ⚠ 5,5 tuần | | ⚠ ĐỘ LỆCH CHUẨN | ⚠ (P − O) ÷ 6 | ⚠ (9 − 4) ÷ 6 ≈ 0,83 tuần | | ⚠ PHƯƠNG SAI | ⚠ [(P − O) ÷ 6]² | ⚠ ≈ 0,69 | | ⚠ Khoảng ±1 độ lệch chuẩn | ⚠ ≈ 68% khả năng | ⚠ 4,67 – 6,33 tuần | | ⚠ Khoảng ±2 độ lệch chuẩn | ⚠ ≈ 95% khả năng | ⚠ 3,83 – 7,17 tuần | | ⚠ Giá trị thực tế | ⚠ độ lệch chuẩn cho biết ước lượng CHẮC tới đâu — một con số 6 tuần kèm sai số ±0,83 hữu ích hơn nhiều so với con số 6 tuần đứng một mình | |

⚠ Vì sao ước lượng ba điểm tốt hơn ước lượng một con số: | Lý do | Nội dung | |---|---| | ⚠ Buộc phải nghĩ tới TRƯỜNG HỢP XẤU | ⚠ con số P làm lộ ra rủi ro chưa được nói tới | | ⚠ Thể hiện được mức BẤT ĐỊNH | ⚠ khoảng cách P − O chính là thước đo bất định | | ⚠ Cho cơ sở tính DỰ PHÒNG | ⚠ liên hệ #26397 lô 193 | | ⚠ Giảm thiên kiến lạc quan | ⚠ liên hệ #26448 lô 194 | | ⚠ Dấu hiệu cần chú ý | ⚠ khi P lớn hơn O rất nhiều (ở đây 9 so với 4, hơn gấp đôi), đó là tín hiệu hoạt động này CÓ RỦI RO — đáng đưa vào sổ đăng ký rủi ro chứ không chỉ tính trung bình rồi đi tiếp |

Từ khoá nhận diện:

"(O + M + P) ÷ 3" → ⚠ TAM GIÁC — công thức của bài này "(O + 4M + P) ÷ 6" → ⚠ PERT beta "(P − O) ÷ 6" → ⚠ độ lệch chuẩn đề không nói rõ phân phối → ⚠ tính cả hai, chọn kết quả có trong phương án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng của bạn có ba con số hay một con số | | | Khoảng cách giữa lạc quan và bi quan của bạn là bao nhiêu | ⚠ rộng nghĩa là bất định cao, cần dự phòng tương xứng | | Bạn có ghi rủi ro cho các hoạt động có khoảng dao động rộng không | |

Và giá trị lớn nhất của ước lượng ba điểm nằm ở chỗ ít ai để ý: không phải ở con số trung bình cuối cùng, mà ở cuộc trò chuyện diễn ra khi cả đội phải trả lời câu hỏi "nếu mọi thứ đều trục trặc thì mất bao lâu?".