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

Đáp án

D — XÁC ĐỊNH TÁC ĐỘNG LÊN TRẠNG THÁI HIỆN TẠI CỦA HOẠT ĐỘNG XỬ LÝ HÀNH LÝ TẠI SÂN BAY.

Vì sao đúng

⚠ Vì sao đây là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Dự án của bạn là ĐÀO TẠO, không phải phát triển hệ thống | ⚠ hệ thống quét hành lý đã hoàn thành | | ⚠ Muốn thiết kế đào tạo phải biết công việc THAY ĐỔI ra sao | ⚠ quy trình nào đổi, ai bị ảnh hưởng, đổi bao nhiêu | | ⚠ Sân bay hoạt động liên tục | ⚠ đào tạo phải chen vào lịch vận hành thật | | ⚠ Phân tích tác động cho biết PHẠM VI đào tạo | ⚠ ai cần học, học gì, bao lâu | | ⚠ Đây là bước phân tích trước khi lập kế hoạch | ⚠ hiểu trước, thiết kế sau | | ⚠ Kết luận | ⚠ không thể thiết kế chương trình đào tạo khi chưa biết công việc của người học sẽ khác đi thế nào |

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

• A (hỏi người dùng cuối cảm nhận thế nào về hệ thống mới) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ lắng nghe người dùng là việc rất hợp lý và thường là đáp án đúng trong nhiều câu hỏi PMP: ⚠ nhưng ⚠ cảm nhận là dữ liệu MỀM và không đủ để xác định nội dung đào tạo ⚠ — ⚠ thứ quyết định chương trình đào tạo là sự khác biệt KHÁCH QUAN giữa quy trình cũ và quy trình mới; ⚠ hỏi cảm nhận là việc nên làm, nhưng nó bổ sung cho phân tích tác động chứ không thay thế được.

• B (tìm lỗi của hệ thống xử lý hành lý) — ⚠ ngoài phạm vi dự án của bạn; ⚠ hệ thống đã được bàn giao, và tìm lỗi là việc của đội phát triển.

• C (phong toả toàn bộ hoạt động xử lý hành lý cho tới khi đào tạo xong) — ⚠ phản ứng cực đoan; ⚠ dừng hoạt động của cả một sân bay để đào tạo là điều không tổ chức nào chấp nhận.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26819 cùng lô (phát triển kỹ năng đội), ⚠ #26820 cùng lô (đánh giá hiệu quả đào tạo), ⚠ #26716 lô 199 (tổ chức đào tạo khi đội thiếu kỹ năng), ⚠ #26745 lô 200 (liên minh dẫn dắt trong dự án thay đổi), ⚠ #26815 cùng lô (đội học công cụ mới).

⚠ PHÂN TÍCH TÁC ĐỘNG cần trả lời những gì: | Câu hỏi | Nội dung | |---|---| | ⚠ Quy trình nào thay đổi và thay đổi ra sao | ⚠ so sánh trạng thái hiện tại và trạng thái tương lai | | ⚠ Nhóm nhân viên nào bị ảnh hưởng | ⚠ nhân viên soi chiếu, bốc xếp, giám sát, an ninh — mỗi nhóm cần nội dung khác nhau | | ⚠ Kỹ năng nào mới, kỹ năng nào giữ nguyên | ⚠ chỉ đào tạo phần khác biệt, đừng dạy lại thứ họ đã biết | | ⚠ Rủi ro trong giai đoạn chuyển đổi | ⚠ thời gian xử lý chậm hơn, sai sót tăng tạm thời | | ⚠ Cửa sổ thời gian có thể đào tạo | ⚠ sân bay không dừng được, phải theo ca | | ⚠ Đầu ra của bước này | ⚠ một bản mô tả rõ ràng về khoảng cách giữa cái người ta đang làm và cái người ta sẽ phải làm — và chính khoảng cách đó là nội dung của chương trình đào tạo |

⚠ Vì sao dự án này thực chất là một dự án QUẢN LÝ THAY ĐỔI: | Yếu tố | Nội dung | |---|---| | ⚠ Công nghệ đã sẵn sàng, con người thì chưa | ⚠ đây là bài toán tiếp nhận, không phải bài toán kỹ thuật | | ⚠ Thành công đo bằng việc nhân viên VẬN HÀNH ĐƯỢC | ⚠ không đo bằng số buổi học đã tổ chức | | ⚠ Sức đề kháng với công nghệ mới là chuyện bình thường | ⚠ liên hệ #26745 lô 200 — liên minh dẫn dắt | | ⚠ Đội của bạn có thiết kế viên, giảng viên và chuyên gia hệ thống | ⚠ cơ cấu đúng cho một dự án đào tạo bài bản | | ⚠ Nhận xét | ⚠ ban lãnh đạo "rất hào hứng với công nghệ mới" — đó chính là dấu hiệu điển hình của tổ chức đánh giá thấp phần con người; việc của bạn là biến sự hào hứng đó thành một kế hoạch chuyển đổi có căn cứ |

⚠ Trình tự thiết kế một chương trình đào tạo: | Bước | Nội dung | |---|---| | ⚠ 1. PHÂN TÍCH TÁC ĐỘNG và khoảng cách kỹ năng | ⚠ ĐÁP ÁN | | ⚠ 2. Xác định đối tượng và mục tiêu học tập | | | ⚠ 3. Thiết kế nội dung và phương thức | ⚠ lớp học, thực hành trên máy, kèm cặp tại chỗ | | ⚠ 4. Thử nghiệm với một nhóm nhỏ | ⚠ rẻ hơn nhiều so với sửa sau khi đã dạy hết | | ⚠ 5. Triển khai theo ca, không gián đoạn vận hành | | | ⚠ 6. ĐO hiệu quả | ⚠ liên hệ #26820 cùng lô — theo dõi hành vi thật sau đào tạo | | ⚠ Bước hay bị bỏ nhất | ⚠ bước 1 và bước 6 — người ta thường nhảy thẳng vào việc soạn tài liệu, rồi kết thúc bằng việc đếm số người đã dự lớp |

Từ khoá nhận diện:

"dự án đào tạo cho hệ thống mới" → ⚠ XÁC ĐỊNH TÁC ĐỘNG lên công việc hiện tại trước "hỏi cảm nhận của người dùng" → ⚠ hữu ích nhưng không đủ để thiết kế nội dung "tìm lỗi hệ thống" → ⚠ ngoài phạm vi dự án đào tạo "dừng vận hành để đào tạo" → ⚠ cực đoan, không khả thi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết công việc hằng ngày của người học sẽ khác đi thế nào không | | | Chương trình đào tạo của bạn dạy phần khác biệt hay dạy lại từ đầu | | | Bạn đo thành công của đào tạo bằng gì | ⚠ số người dự học không phải là kết quả |

Và điều mà một dự án đào tạo dễ quên nhất giữa sự hào hứng về công nghệ mới: hệ thống quét hành lý không tự nó cải thiện được gì cả — thứ thay đổi kết quả là những gì hàng trăm nhân viên sẽ làm khác đi vào sáng thứ Hai, và đó mới là thứ dự án này phải thiết kế.

Đáp án

B — GẶP BÊN LIÊN QUAN VÀ GIỚI THIỆU CHO HỌ MỘT LƯỢT VỀ PHƯƠNG PHÁP AGILE.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Tổ chức VỪA chuyển sang agile | ⚠ bên liên quan chưa quen cách làm mới | | ⚠ Họ hỏi "kế hoạch chi tiết" vì đó là thứ họ vẫn quen nhận | ⚠ nhu cầu thật là SỰ AN TÂM về tiến độ, không phải bản tài liệu | | ⚠ Giáo dục bên liên quan là một phần vai trò của scrum master | ⚠ giúp tổ chức bên ngoài đội hiểu cách làm việc mới | | ⚠ Gặp trực tiếp cho phép hỏi lại và trấn an | ⚠ liên hệ #26753 lô 200 | | ⚠ Agile CÓ kế hoạch, chỉ khác về hình thức và mức chi tiết | ⚠ tồn đọng, lộ trình phát hành, kế hoạch vòng lặp | | ⚠ Kết luận | ⚠ hiểu nhu cầu thật rồi cho họ thấy agile đáp ứng nó bằng cách nào |

⚠ Nguyên tắc: ⚠ khi bên liên quan đòi một hiện vật của cách làm cũ, đừng chỉ nói "chúng tôi không làm vậy nữa" — hãy tìm hiểu họ cần THÔNG TIN GÌ và chỉ cho họ nơi có thông tin đó trong cách làm mới.

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

• D (nói với bên liên quan rằng agile không dùng kế hoạch dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như một sự khẳng định nguyên tắc agile, và nhiều người thật sự tin rằng agile nghĩa là không lập kế hoạch: ⚠ nhưng ⚠ phát biểu này SAI VỀ SỰ THẬT — agile lập kế hoạch liên tục và ở nhiều tầng: lộ trình sản phẩm, kế hoạch phát hành, kế hoạch vòng lặp ⚠ — ⚠ cái agile không làm là cố định toàn bộ chi tiết từ đầu; ⚠ và nó bỏ mặc bên liên quan với đúng nhu cầu mà họ vừa nêu, khiến họ càng nghi ngờ cách làm mới.

• C (gửi email kèm bản kế hoạch dự án) — ⚠ trong dự án agile không có "bản kế hoạch chi tiết" theo nghĩa họ mong đợi; ⚠ và gửi một tài liệu qua email không giải quyết được sự thiếu hiểu biết.

• A (nhờ một thành viên cập nhật cho họ mỗi thứ Sáu) — ⚠ cung cấp thông tin nhưng không giải quyết nguyên nhân; ⚠ và đẩy việc giao tiếp với bên liên quan sang một thành viên trong đội.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26821 cùng lô (dự báo ngày hoàn thành trong agile), ⚠ #26806 cùng lô (không thể xác định hết công việc từ đầu), ⚠ #26818 cùng lô (khách đổi ý — cách agile xử lý), ⚠ #26788 cùng lô (chọn vòng đời phù hợp), ⚠ #26825 cùng lô (xếp lại ưu tiên tồn đọng).

⚠ Agile CÓ những "kế hoạch" nào: | Tầng | Nội dung | Tương ứng với cái gì trong dự đoán | |---|---|---| | ⚠ TẦM NHÌN SẢN PHẨM | ⚠ mục tiêu dài hạn | ⚠ hiến chương dự án | | ⚠ LỘ TRÌNH SẢN PHẨM | ⚠ các chủ đề lớn theo quý | ⚠ tiến độ tổng thể | | ⚠ KẾ HOẠCH PHÁT HÀNH | ⚠ những gì sẽ có trong bản phát hành tới | ⚠ tiến độ chi tiết theo giai đoạn | | ⚠ TỒN ĐỌNG SẢN PHẨM có xếp ưu tiên | ⚠ danh sách công việc còn lại | ⚠ WBS | | ⚠ KẾ HOẠCH VÒNG LẶP | ⚠ chi tiết cho hai tuần tới | ⚠ kế hoạch chi tiết ngắn hạn | | ⚠ Điểm khác biệt cốt lõi | ⚠ agile lập kế hoạch CHI TIẾT cho phần GẦN và THÔ cho phần XA, rồi làm mịn dần — đó là lập kế hoạch theo lớp sóng, không phải là không lập kế hoạch |

⚠ Sally nên nói gì trong buổi gặp: | Nội dung | Cách trình bày | |---|---| | ⚠ Hỏi trước: anh chị cần biết điều gì | ⚠ ngày ra mắt, phạm vi, rủi ro, chi phí — mỗi nhu cầu có một câu trả lời khác nhau | | ⚠ Cho xem TỒN ĐỌNG và LỘ TRÌNH | ⚠ đó là "kế hoạch" của agile | | ⚠ Giải thích cách dự báo bằng vận tốc | ⚠ liên hệ #26821 cùng lô | | ⚠ Mời họ dự buổi rà soát cuối mỗi vòng lặp | ⚠ họ được thấy sản phẩm thật, không chỉ báo cáo | | ⚠ Thoả thuận nhịp và hình thức cập nhật | ⚠ liên hệ #26826 cùng lô — kế hoạch giao tiếp | | ⚠ Lợi ích lớn nhất | ⚠ bên liên quan hiểu agile sẽ trở thành người ủng hộ; bên liên quan không hiểu sẽ liên tục đòi các hiện vật của cách làm cũ, và đội sẽ phải sản xuất chúng song song — đó là chi phí ẩn lớn nhất của một quá trình chuyển đổi nửa vời |

⚠ Vì sao "cách làm cũ" vẫn còn sức nặng: | Lý do | Nội dung | |---|---| | ⚠ Bản kế hoạch dày tạo cảm giác kiểm soát | ⚠ dù nó thường sai ngay từ tháng thứ hai | | ⚠ Người ta đã quen đánh giá dự án qua tài liệu | | | ⚠ Cấp trên của họ có thể vẫn đòi báo cáo kiểu cũ | ⚠ áp lực đến từ trên xuống chứ không từ chính họ | | ⚠ Cách xử lý thực dụng | ⚠ hỏi xem họ phải báo cáo gì cho cấp trên, rồi cùng thiết kế một hiện vật agile đáp ứng được yêu cầu đó — thường chỉ cần một trang lộ trình và một biểu đồ burnup là đủ |

Từ khoá nhận diện:

"bên liên quan đòi kế hoạch chi tiết trong dự án agile" → ⚠ GẶP VÀ GIẢI THÍCH CÁCH LÀM MỚI "agile không có kế hoạch" → ⚠ SAI — agile có nhiều tầng kế hoạch "gửi email bản kế hoạch" → ⚠ không giải quyết sự thiếu hiểu biết "nhờ người khác cập nhật hằng tuần" → ⚠ chữa triệu chứng, đẩy việc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có hiểu cách làm việc của đội không | | | Họ có nơi nào để tự xem tiến độ không | | | Đội bạn có đang sản xuất song song hai bộ tài liệu không | ⚠ dấu hiệu của chuyển đổi nửa vời |

Và điều mà một buổi giới thiệu ba mươi phút thay thế được: mười lăm tháng liên tục nhận những yêu cầu về các bản kế hoạch mà không ai thật sự cần — vì thứ bên liên quan muốn chưa bao giờ là tài liệu, mà là cảm giác biết dự án đang đi tới đâu.

Đáp án

C — CÓ THỂ NHẬN ĐƯỢC LỢI ÍCH SỚM HƠN BẰNG CÁCH PHÂN TÍCH VÀ SẮP XẾP LẠI TIẾN ĐỘ CHO PHÙ HỢP.

Vì sao đúng

⚠ Vì sao đây là câu trả lời đúng: | Lý do | Nội dung | |---|---| | ⚠ Dự án mới đi được MỘT tháng trong mười lăm tháng | ⚠ còn rất nhiều dư địa để sắp xếp lại | | ⚠ Lợi ích ở tháng 13 có thể do THỨ TỰ công việc, không do ràng buộc kỹ thuật | ⚠ phải phân tích mới biết | | ⚠ Sắp xếp lại tiến độ KHÔNG tốn thêm tiền và không tăng rủi ro | ⚠ khác hẳn hai phương án rút ngắn | | ⚠ Câu trả lời thận trọng: "CÓ THỂ", kèm điều kiện phân tích | ⚠ không hứa suông | | ⚠ Quản lý lợi ích là trách nhiệm của quản lý dự án | ⚠ giao giá trị sớm là mục tiêu chính đáng | | ⚠ Kết luận | ⚠ xem lại thứ tự công việc trước khi nghĩ tới việc chi thêm tiền hay chấp nhận thêm rủi ro |

⚠ Đây cũng là tinh thần của cách tiếp cận GIA SỐ: ⚠ kéo phần tạo ra lợi ích lên trước, giao nó, rồi làm tiếp phần còn lại ⚠ — ⚠ liên hệ #26768 lô 200.

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

• A (chạy song song — fast-tracking sẽ giúp nhận lợi ích sớm hơn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ fast-tracking thật sự rút ngắn được tiến độ và là kỹ thuật hợp lệ, nên nó nghe như một câu trả lời chuyên nghiệp: ⚠ nhưng ⚠ nó khẳng định CHẮC CHẮN mà chưa phân tích gì, và nó TĂNG RỦI RO cùng khả năng phải làm lại ⚠ — ⚠ quan trọng hơn: rút ngắn toàn bộ dự án khác với việc đưa MỘT LỢI ÍCH cụ thể lên sớm; ⚠ sắp xếp lại thứ tự thường đạt được mục tiêu này mà không tốn gì, nên phải thử trước.

• B (rút ngắn — crashing sẽ giúp nhận lợi ích sớm hơn) — ⚠ tốn thêm TIỀN và cũng khẳng định chắc chắn khi chưa phân tích; ⚠ liên hệ #26752 lô 200.

• D (không thể được vì các phụ thuộc cụ thể) — ⚠ kết luận phủ định khi chưa xem xét gì; ⚠ và nhiều phụ thuộc là TUỲ CHỌN chứ không bắt buộc — liên hệ #26776 lô 200.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26768 lô 200 (vòng đời gia số để giao giá trị sớm), ⚠ #26752 lô 200 (crashing tốn chi phí), ⚠ #26776 lô 200 (phụ thuộc bắt buộc và tuỳ chọn), ⚠ #26798 cùng lô (đo tiến độ giao giá trị bằng SPI), ⚠ #26749 lô 200 (sắp xếp lại thứ tự theo rủi ro).

⚠ Các cách đưa lợi ích lên sớm — theo thứ tự nên thử: | Cách | Chi phí | Rủi ro | |---|---|---| | ⚠ SẮP XẾP LẠI THỨ TỰ công việc | ⚠ gần như bằng không — ĐÁP ÁN | ⚠ thấp | | ⚠ Tách phần tạo lợi ích thành một gia số riêng | ⚠ thấp | ⚠ thấp | | ⚠ CHẠY SONG SONG (fast-tracking) | ⚠ không tốn thêm tiền | ⚠ TĂNG rủi ro và khả năng làm lại | | ⚠ RÚT NGẮN (crashing) | ⚠ TỐN THÊM TIỀN | ⚠ trung bình | | ⚠ Giảm phạm vi của gia số đầu | ⚠ thấp | ⚠ cần khách hàng đồng ý | | ⚠ Nguyên tắc | ⚠ luôn thử các cách MIỄN PHÍ trước khi đề xuất các cách tốn tiền hoặc tốn rủi ro — và ở tháng thứ nhất của một dự án mười lăm tháng thì các cách miễn phí gần như chắc chắn còn nguyên |

⚠ Abigail nên phân tích những gì: | Việc | Nội dung | |---|---| | ⚠ Xác định chính xác lợi ích đó phụ thuộc vào công việc nào | ⚠ truy ngược từ lợi ích về các gói công việc | | ⚠ Kiểm tra các phụ thuộc là BẮT BUỘC hay TUỲ CHỌN | ⚠ liên hệ #26776 lô 200 | | ⚠ Xem có thể tách một phần chức năng đủ dùng ra sớm không | ⚠ liên hệ #26765 lô 200 — chia nhỏ | | ⚠ Đánh giá tác động lên các công việc khác | ⚠ kéo cái này lên thì cái gì bị đẩy xuống | | ⚠ Đưa thay đổi tiến độ qua kiểm soát thay đổi | ⚠ đường cơ sở tiến độ bị ảnh hưởng | | ⚠ Điều cần nói rõ với bên liên quan | ⚠ kéo một lợi ích lên sớm thường có nghĩa là một lợi ích khác bị lùi lại — hãy đưa ra sự đánh đổi đó bằng con số, để chính họ chọn |

⚠ Vì sao "quản lý lợi ích" đáng được quan tâm sớm: | Lý do | Nội dung | |---|---| | ⚠ Lợi ích nhận sớm có giá trị hơn lợi ích nhận muộn | ⚠ giá trị thời gian của tiền | | ⚠ Lợi ích sớm tạo niềm tin cho phần còn lại của dự án | ⚠ liên hệ #26780 lô 200 — dự án không có kết quả trung gian | | ⚠ Bên liên quan gắn kết hơn khi thấy kết quả | | | ⚠ Dự án dài có nguy cơ bị cắt ngân sách giữa chừng | ⚠ có lợi ích đã giao thì vị thế vững hơn nhiều | | ⚠ Nhận xét về câu hỏi | ⚠ bên liên quan hỏi đúng câu hỏi mà một người quản lý dự án tốt lẽ ra nên tự hỏi trước — và câu trả lời đúng không phải "được" hay "không được", mà là "để tôi phân tích và quay lại với các phương án cùng cái giá của chúng" |

Từ khoá nhận diện:

"có thể nhận lợi ích sớm hơn không" → ⚠ PHÂN TÍCH VÀ SẮP XẾP LẠI TIẾN ĐỘ "fast-tracking / crashing" → ⚠ có tác dụng nhưng có giá; không phải bước đầu "không thể được" → ⚠ kết luận khi chưa phân tích nguyên tắc → ⚠ thử cách miễn phí trước, và đừng khẳng định trước khi phân tích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lợi ích đầu tiên của dự án bạn xuất hiện ở tháng thứ mấy | | | Nó nằm ở đó vì ràng buộc kỹ thuật hay vì thứ tự bạn đã chọn | | | Có phần nào tách ra giao sớm được không | |

Và điều mà câu hỏi của bên liên quan ở tháng thứ nhất thật sự là một món quà: nó buộc dự án phải xem lại thứ tự công việc vào lúc việc đổi thứ tự vẫn còn gần như không tốn gì — điều mà cùng câu hỏi ấy ở tháng thứ mười sẽ không còn mua được nữa.

Đáp án

B — CUNG CẤP SỰ RÕ RÀNG VÀ GIẢM NHẦM LẪN TRONG NHỮNG TÌNH HUỐNG CÓ QUAN ĐIỂM TRÁI CHIỀU.

Vì sao đúng

⚠ Vì sao đặc tính này là ưu tiên số một trong tình huống của Bruce: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Đội trải nhiều quốc gia | ⚠ khác múi giờ, khác văn hoá, khác quy ước làm việc | | ⚠ LẦN ĐẦU có thành viên không thạo tiếng Anh | ⚠ đây là chi tiết mới so với ba dự án trước của Bruce | | ⚠ Bruce lập hiến chương CỐT ĐỂ TRÁNH HIỂU LẦM | ⚠ đề nói rõ mục đích | | ⚠ Hiểu lầm nguy hiểm nhất khi có bất đồng | ⚠ đúng lúc ngôn ngữ trở nên phức tạp và cảm xúc dâng cao | | ⚠ Kết luận | ⚠ đặc tính LÀM RÕ và GIẢM NHẦM LẪN khớp trực tiếp với rủi ro mà Bruce đang phòng ngừa |

⚠ Ba phương án còn lại đều là đặc tính THẬT của hiến chương đội, nhưng chúng không nhắm vào rủi ro NGÔN NGỮ ⚠ — ⚠ dạng câu hỏi "cái nào TRƯỚC" luôn được giải bằng cách khớp phương án với rủi ro cụ thể mà đề vừa nêu.

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

• A (buộc mọi thành viên, kể cả người lãnh đạo, tuân theo cùng các nguyên tắc) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đây là một đặc tính rất quan trọng và đúng đắn của hiến chương đội: quy tắc áp cho tất cả, kể cả người đứng đầu: ⚠ nhưng ⚠ nó nhắm vào vấn đề CÔNG BẰNG và QUYỀN LỰC, không nhắm vào vấn đề HIỂU LẦM DO NGÔN NGỮ ⚠ — ⚠ nó rất giá trị trong đội có khoảng cách quyền lực cao, liên hệ #26681 lô 198, nhưng đề này nêu rõ rủi ro là giao tiếp; ⚠ cả bốn phương án đều đúng về mặt lý thuyết — chọn cái khớp với rủi ro được nêu.

• C (thể hiện minh bạch mục đích và sứ mệnh của đội với phần còn lại của tổ chức) — ⚠ hướng RA NGOÀI đội; ⚠ vấn đề của Bruce nằm bên trong.

• D (giành được sự đồng thuận của mọi thành viên, kể cả người ban đầu miễn cưỡng) — ⚠ nhắm vào sự CAM KẾT; ⚠ đề không nói ai miễn cưỡng cả.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26779 lô 200 (hiến chương đội là tài liệu sống), ⚠ #26759 lô 200 (quy tắc ứng xử làm chuẩn hành vi), ⚠ #26681 lô 198 (nhận thức văn hoá — câu đùa bị hiểu theo nghĩa đen), ⚠ #26601 lô 197 (đơn giản hoá ngôn ngữ cho người không nói bản ngữ), ⚠ #26799 cùng lô (đội đa quốc gia — cân nhắc múi giờ).

⚠ Hiến chương đội nên có gì cho một đội đa ngôn ngữ: | Nội dung | Vì sao | |---|---| | ⚠ Quy ước xác nhận đã hiểu | ⚠ "hãy nhắc lại theo cách hiểu của anh chị" thay vì hỏi "rõ chưa" | | ⚠ Cam kết viết lại các quyết định quan trọng | ⚠ văn bản cho người ta thời gian đọc lại | | ⚠ Khuyến khích hỏi lại, không ai bị coi là phiền | ⚠ gỡ rào cản thể diện | | ⚠ Tránh thành ngữ, tiếng lóng và nói đùa nhiều nghĩa | ⚠ liên hệ #26681 lô 198 | | ⚠ Quy trình rõ ràng khi có bất đồng | ⚠ ĐÁP ÁN — ai nói gì trước, quyết định thế nào | | ⚠ Ngôn ngữ chung và mức trang trọng | | | ⚠ Vì sao mục cuối cùng quan trọng | ⚠ khi có bất đồng, người ta nói nhanh hơn, dùng từ phức tạp hơn và ít kiên nhẫn hơn — đó chính là lúc rào cản ngôn ngữ gây thiệt hại lớn nhất, và cũng là lúc một quy trình đã thoả thuận trước phát huy tác dụng |

⚠ Vì sao Bruce làm đúng khi cùng đội xây hiến chương qua họp video: | Việc | Nội dung | |---|---| | ⚠ CÙNG XÂY, không phát xuống | ⚠ liên hệ #26779 lô 200 — đội sở hữu tài liệu này | | ⚠ Dùng kênh có HÌNH | ⚠ với người không thạo ngôn ngữ, nét mặt và cử chỉ bù đắp rất nhiều — liên hệ #26692 lô 199 | | ⚠ Làm NGAY ĐẦU dự án | ⚠ trước khi hiểu lầm đầu tiên xảy ra | | ⚠ Đưa mọi người vào cùng một cuộc trò chuyện | ⚠ thay vì phổ biến từng nhóm | | ⚠ Việc nên làm thêm | ⚠ ghi lại hiến chương bằng ngôn ngữ ĐƠN GIẢN và gửi bản viết cho mọi người đọc lại — với đội đa ngôn ngữ, nghe một lần trong cuộc họp là không đủ |

⚠ Cách đọc dạng câu "đặc tính nào TRƯỚC": | Bước | Nội dung | |---|---| | ⚠ 1. Xác định RỦI RO cụ thể mà đề nêu | ⚠ ở đây: hiểu lầm do rào cản ngôn ngữ | | ⚠ 2. Đọc bốn phương án như bốn công dụng khác nhau | | | ⚠ 3. Chọn công dụng khớp trực tiếp với rủi ro đó | | | ⚠ Cạm bẫy | ⚠ cả bốn phương án đều đúng về mặt lý thuyết, nên đọc lướt sẽ thấy phương án nào cũng chọn được — thứ phân định là câu văn mô tả hoàn cảnh, không phải bản thân các phương án |

Từ khoá nhận diện:

"đội đa ngôn ngữ, sợ hiểu lầm" → ⚠ LÀM RÕ và GIẢM NHẦM LẪN khi có quan điểm trái chiều "quy tắc áp cho cả lãnh đạo" → ⚠ nhắm vào công bằng và quyền lực "thể hiện sứ mệnh ra bên ngoài" → ⚠ hướng ra ngoài đội "giành sự đồng thuận của người miễn cưỡng" → ⚠ nhắm vào cam kết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai không dùng ngôn ngữ làm việc làm tiếng mẹ đẻ không | | | Khi bất đồng, đội bạn xử lý theo quy trình nào | ⚠ có thoả thuận trước hay ứng biến | | Bạn kiểm tra sự hiểu bằng câu hỏi nào | ⚠ "rõ chưa" luôn nhận được cái gật đầu |

Và điều mà Bruce nhận ra ở dự án ảo thứ tư mà ba dự án trước chưa dạy anh: khoảng cách địa lý chỉ tạo ra sự bất tiện, còn khoảng cách ngôn ngữ tạo ra những cách hiểu khác nhau về cùng một câu — và cái sau chỉ lộ ra vào đúng lúc không ai còn thời gian để phát hiện ra nó.

Đáp án

B — BÁO NGAY CHO CÁC BÊN LIÊN QUAN VỀ SỰ CỐ VÀ VỀ KẾ HOẠCH KHẮC PHỤC.

Vì sao đúng

⚠ Vì sao phải báo ngay: | Lý do | Nội dung | |---|---| | ⚠ Minh bạch là giá trị cốt lõi của agile | ⚠ và là nghĩa vụ nghề nghiệp theo quy tắc PMI | | ⚠ Sự việc ẢNH HƯỞNG tới tiến độ giao hàng | ⚠ bên liên quan có quyền được biết | | ⚠ Báo KÈM kế hoạch khắc phục | ⚠ không phải chỉ báo tin xấu — đó là điểm quan trọng | | ⚠ Che giấu rồi bị phát hiện thì tổn hại lớn hơn nhiều | ⚠ mất tiến độ có thể bù, mất lòng tin thì không | | ⚠ Nguyên nhân là cấu hình thiếu dự phòng | ⚠ một vấn đề hệ thống cần được ghi nhận, không giấu đi | | ⚠ Kết luận | ⚠ báo sớm, báo đủ, kèm cách xử lý |

⚠ Chữ "xấu hổ" trong đề chính là cái bẫy cảm xúc: ⚠ sự ngại ngùng của Edith và đội là lý do khiến ba phương án trì hoãn trở nên hấp dẫn ⚠ — ⚠ nhưng cảm giác khó xử của người báo tin không phải là căn cứ để quyết định có báo hay không.

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

• A (chờ tới buổi rà soát sprint tiếp theo mới thông báo) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ buổi rà soát sprint đúng là nơi chính thức để trao đổi với bên liên quan, nên việc chờ tới đó nghe như tuân thủ quy trình: ⚠ nhưng ⚠ đây là sự cố ẢNH HƯỞNG TỚI CAM KẾT, và loại thông tin đó không được xếp hàng chờ tới nhịp họp định kỳ ⚠ — ⚠ nhịp họp là mặc định cho thông tin thường lệ, còn tin xấu có ảnh hưởng thì đi ngay; ⚠ và nếu bên liên quan biết được từ nguồn khác trước buổi rà soát, tổn hại sẽ nhân đôi.

• C (không làm gì, dự án rồi sẽ trở lại đúng hướng) — ⚠ che giấu; ⚠ và nó dựa trên một hy vọng chứ không phải một kế hoạch.

• D (dùng quỹ dự phòng thuê tư vấn bán thời gian) — ⚠ có thể là một phương án khắc phục, nhưng KHÔNG PHẢI bước tiếp theo; ⚠ đội đã có kế hoạch tự bù, và dùng quỹ dự phòng cũng là thứ cần được thông báo chứ không tự quyết trong im lặng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26777 lô 200 (đúng rủi ro này: máy chủ hỏng, thiếu dự phòng — nhưng ở đó chưa xảy ra), ⚠ #26778 lô 200 (gặp bên liên quan khi có khủng hoảng), ⚠ #26751 lô 200 (chọn quy mô giao tiếp phù hợp), ⚠ #26804 cùng lô (cập nhật ngân sách và báo bên liên quan), ⚠ #26744 lô 200 (rủi ro đã xảy ra thì tra sổ).

⚠ Đối chiếu đặc biệt đáng chú ý: ⚠ #26777 lô 200 mô tả CHÍNH XÁC rủi ro này ở trạng thái CHƯA XẢY RA — Alana cảnh báo máy chủ có thể sập, đội lập kế hoạch dựng máy chủ dự phòng ⚠ — ⚠ còn ở đây rủi ro ĐÃ hiện thực hoá vì máy chủ không được cấu hình dự phòng; ⚠ đọc hai câu cạnh nhau là thấy trọn vẹn cái giá của việc bỏ qua một cảnh báo đã được nêu ra.

⚠ Edith nên báo những gì: | Nội dung | Chi tiết | |---|---| | ⚠ Chuyện gì đã xảy ra | ⚠ sự việc, thời điểm, phạm vi ảnh hưởng | | ⚠ Mất bao nhiêu công việc | ⚠ con số cụ thể, không nói mơ hồ | | ⚠ Kế hoạch khắc phục và thời gian | ⚠ đội tin có thể bù trong sprint tới | | ⚠ Cái giá của kế hoạch đó | ⚠ đội sẽ làm cuối tuần — bên liên quan cần biết điều này | | ⚠ Biện pháp ngăn tái diễn | ⚠ cấu hình dự phòng, sao lưu — quan trọng nhất | | ⚠ Điều Edith nên cân nhắc kỹ | ⚠ việc đội tình nguyện làm cuối tuần là thiện chí, nhưng nó không nên trở thành giải pháp mặc định — liên hệ #26674 lô 198; nếu nhịp độ này lặp lại thì vấn đề đã chuyển từ một sự cố hạ tầng thành một vấn đề về cách vận hành đội |

⚠ Nguyên tắc báo tin xấu trong dự án: | Nguyên tắc | Nội dung | |---|---| | ⚠ Báo SỚM — càng muộn càng tệ | ⚠ thời gian không làm tin xấu nhẹ đi | | ⚠ Báo KÈM phương án, không chỉ kèm vấn đề | ⚠ điều phân biệt một báo cáo chuyên nghiệp | | ⚠ Báo bằng SỐ LIỆU, không bằng cảm xúc | | | ⚠ Nhận trách nhiệm, không đổ lỗi | | | ⚠ Nói rõ cách ngăn tái diễn | ⚠ thứ bên liên quan quan tâm nhất sau khi nguôi | | ⚠ Ghi nhớ | ⚠ bên liên quan hiếm khi nổi giận vì một sự cố kỹ thuật; họ nổi giận vì biết muộn — và đó là phần duy nhất trong toàn bộ chuyện này mà Edith hoàn toàn kiểm soát được |

Từ khoá nhận diện:

"sự cố ảnh hưởng tiến độ" → ⚠ BÁO NGAY kèm kế hoạch khắc phục "chờ tới buổi rà soát định kỳ" → ⚠ nhịp họp dành cho thông tin thường lệ, không cho tin xấu "rồi sẽ ổn thôi" → ⚠ che giấu dựa trên hy vọng "dùng quỹ dự phòng thuê người" → ⚠ một phương án khắc phục, không phải bước tiếp theo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tin xấu gần nhất trong dự án bạn mất bao lâu để tới bên liên quan | | | Bạn có báo kèm phương án không | | | Có cảnh báo kỹ thuật nào đang bị bỏ qua trong dự án bạn không | ⚠ liên hệ #26777 lô 200 |

Và điều mà một cuộc gọi khó chịu trong ngày hôm nay mua được: quyền được là người kể câu chuyện đó — thay vì là người phải giải thích vì sao mình đã im lặng khi ai khác kể nó trước.

Đáp án

A — VÒNG ĐỜI DỰ ĐOÁN, THÍCH ỨNG HOẶC LAI ĐỀU CÓ THỂ TỎ RA HỮU ÍCH NHẤT.

Vì sao đúng

⚠ Vì sao câu trả lời phải là "tuỳ dự án": | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Mario giám sát NĂM dự án rất khác nhau | ⚠ từ ngân sách nhỏ tới giải pháp phức tạp | | ⚠ Có dự án cần lộ trình sản phẩm dài | ⚠ loại này hợp cách tiếp cận thích ứng hoặc lai | | ⚠ Có dự án nhỏ, đơn giản | ⚠ loại này thường hợp cách dự đoán | | ⚠ Ngành hàng không có yêu cầu tuân thủ chặt | ⚠ một số phần bắt buộc phải dự đoán | | ⚠ Kết luận | ⚠ một danh mục đa dạng không thể ép vào một vòng đời duy nhất |

⚠ Nguyên tắc của PMBOK bản mới: ⚠ vòng đời được CHỌN theo đặc điểm của từng dự án — mức độ bất định, tần suất giao hàng, mức độ thay đổi của yêu cầu, yêu cầu tuân thủ ⚠ — ⚠ không có vòng đời nào tốt hơn vòng đời nào một cách phổ quát.

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

• B (có thể cần áp dụng vòng đời thích ứng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ agile đang là xu hướng và nhiều người mặc định coi thích ứng là câu trả lời hiện đại và đúng đắn cho mọi bối cảnh: ⚠ nhưng ⚠ nó tuyệt đối hoá MỘT vòng đời cho cả một danh mục đa dạng ⚠ — ⚠ một dự án ngân sách nhỏ với yêu cầu rõ ràng không cần tới bộ máy của agile, và trong ngành hàng không có những phần bắt buộc phải theo quy trình dự đoán vì lý do chứng nhận; ⚠ trong đề PMP, phương án nói về sự PHÙ HỢP thường thắng phương án tuyệt đối hoá một cách làm.

• D (bắt buộc phải áp dụng lập kế hoạch theo lớp sóng) — ⚠ chữ "BẮT BUỘC" làm phương án này sai; ⚠ lập kế hoạch theo lớp sóng là một kỹ thuật hữu ích nhưng không bắt buộc ở mọi nơi.

• C (không cần văn phòng quản lý dự án để tổ chức nhiều loại dự án) — ⚠ trái với thực tế của đề: tổ chức ĐANG dùng PMO và nó chính là thứ giúp điều phối một danh mục đa dạng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26768 lô 200 (vòng đời gia số để giao giá trị sớm), ⚠ #26819 cùng lô (dự án lai — waterfall cộng scrum), ⚠ #26784 cùng lô (giải thích agile cho bên liên quan), ⚠ #26756 lô 200 (không có phương pháp xếp ưu tiên duy nhất tốt nhất), ⚠ #26806 cùng lô (dự đoán không bắt được hết yêu cầu từ đầu).

⚠ CHỌN VÒNG ĐỜI theo đặc điểm dự án: | Đặc điểm | Nghiêng về DỰ ĐOÁN | Nghiêng về THÍCH ỨNG | |---|---|---| | ⚠ Yêu cầu | ⚠ rõ ràng, ổn định | ⚠ chưa rõ, hay thay đổi | | ⚠ Mức độ bất định kỹ thuật | ⚠ thấp, đã làm nhiều lần | ⚠ cao, cần thử nghiệm | | ⚠ Sự tham gia của khách hàng | ⚠ ở các mốc | ⚠ liên tục | | ⚠ Tần suất bàn giao | ⚠ một lần hoặc vài mốc lớn | ⚠ thường xuyên | | ⚠ Yêu cầu tuân thủ và chứng nhận | ⚠ CAO — hàng không, y tế | ⚠ thấp hơn | | ⚠ Chi phí của thay đổi | ⚠ cao (xây dựng, phần cứng) | ⚠ thấp (phần mềm) | | ⚠ Vì sao mô hình LAI phổ biến nhất trong thực tế | ⚠ rất ít dự án nằm trọn ở một cực — phần phần cứng và chứng nhận chạy dự đoán, phần phần mềm chạy thích ứng, và đó chính là bức tranh của một công ty hàng không |

⚠ Vai trò của PMO trong một danh mục đa dạng: | Việc | Nội dung | |---|---| | ⚠ Cung cấp CHUẨN và bộ công cụ cho từng vòng đời | ⚠ không ép một khuôn cho tất cả | | ⚠ Hướng dẫn cách CHỌN vòng đời | ⚠ thường bằng một bảng tiêu chí | | ⚠ Tổng hợp báo cáo ở mức danh mục | ⚠ để lãnh đạo so sánh được các dự án khác loại | | ⚠ Chia sẻ bài học giữa các dự án | ⚠ liên hệ #26726 lô 199 | | ⚠ Quản lý nguồn lực dùng chung | ⚠ liên hệ #26685 lô 199 | | ⚠ Sai lầm phổ biến của PMO | ⚠ ép mọi dự án dùng cùng một quy trình vì như thế dễ báo cáo hơn — nó khiến dự án nhỏ chết ngộp trong thủ tục và dự án phức tạp bị bó trong một kế hoạch không còn đúng từ tháng thứ hai |

⚠ Mario cần làm gì với năm dự án của mình: | Việc | Nội dung | |---|---| | ⚠ Đánh giá từng dự án theo bảng tiêu chí | ⚠ bất định, tần suất giao hàng, tuân thủ | | ⚠ Chọn vòng đời phù hợp cho từng dự án | ⚠ và giải thích lý do trong kế hoạch — liên hệ #26735 lô 200 | | ⚠ Thống nhất bộ chỉ số chung ở mức danh mục | ⚠ để so sánh được dù cách làm khác nhau | | ⚠ Bảo đảm mọi đội hiểu cách làm được chọn | ⚠ liên hệ #26784 cùng lô | | ⚠ Giá trị của việc chọn có ý thức | ⚠ vòng đời được chọn vì lý do rõ ràng thì bảo vệ được trước mọi câu hỏi; vòng đời được dùng vì "chúng tôi luôn làm thế" thì không |

Từ khoá nhận diện:

"danh mục nhiều loại dự án khác nhau" → ⚠ DỰ ĐOÁN, THÍCH ỨNG hoặc LAI đều có thể phù hợp "phải dùng thích ứng" → ⚠ tuyệt đối hoá một cách làm "bắt buộc phải lập kế hoạch theo lớp sóng" → ⚠ chữ "bắt buộc" làm nó sai "không cần PMO" → ⚠ trái với bối cảnh của đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn chọn vòng đời cho dự án dựa trên tiêu chí gì | ⚠ hay chỉ theo thói quen của tổ chức | | Có dự án nào đang dùng cách làm không hợp với bản chất của nó không | | | Tổ chức bạn có hướng dẫn về việc chọn cách tiếp cận không | |

Và điều mà một người quản lý dự án dày dạn như Mario mang lại cho một danh mục đa dạng: không phải một phương pháp mà anh tin tưởng, mà khả năng nhìn năm dự án khác nhau và chọn đúng năm cách làm khác nhau cho chúng.

Đáp án

B — LÀM VIỆC NHÓM VÀ TINH CHỈNH TỒN ĐỌNG TRONG BUỔI LẬP KẾ HOẠCH SPRINT.

Vì sao đúng

⚠ Đọc thẳng từ đề: | Việc trong đề | Tên gọi | |---|---| | ⚠ Natasha, ĐỘI PHÁT TRIỂN và CHỦ SẢN PHẨM cùng làm | ⚠ làm việc nhóm — cả ba vai đều tham gia | | ⚠ Cùng VIẾT câu chuyện người dùng | ⚠ làm rõ và chi tiết hoá hạng mục tồn đọng | | ⚠ Xem xét câu chuyện sẽ được XẾP ƯU TIÊN thế nào | ⚠ tinh chỉnh tồn đọng (backlog grooming/refinement) | | ⚠ Bối cảnh: sắp xếp lại các câu chuyện trước vòng lặp | ⚠ đúng thời điểm của việc lập kế hoạch sprint | | ⚠ Kết luận | ⚠ tinh chỉnh tồn đọng có sự tham gia của cả ba vai — đúng phương án B |

⚠ TINH CHỈNH TỒN ĐỌNG là hoạt động LIÊN TỤC, không phải một sự kiện cố định trong Scrum ⚠ — ⚠ nó gồm việc thêm chi tiết, ước lượng, chia nhỏ và sắp xếp lại thứ tự các hạng mục.

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

• D (lãnh đạo phục vụ vì giá trị của dự án trong buổi hồi cứu sprint) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ lãnh đạo phục vụ đúng là vai trò của scrum master, và Natasha đang tạo điều kiện cho cả nhóm làm việc cùng nhau — nghe rất khớp: ⚠ nhưng ⚠ nó gắn hoạt động vào SAI SỰ KIỆN — buổi hồi cứu nhìn lại CÁCH LÀM VIỆC của đội, không phải nơi viết câu chuyện người dùng ⚠ — ⚠ liên hệ #26704 lô 199; ⚠ trong dạng câu hỏi này, nửa đầu của phương án có thể đúng nhưng nửa sau lại gắn sai sự kiện — phải đọc hết cả câu.

• A (xác định mức rủi ro của một câu chuyện trong một risk spike) — ⚠ spike là hạng mục nghiên cứu có thời lượng giới hạn; ⚠ đề không nói tới việc nghiên cứu hay giảm bất định nào.

• C (lập bảng kiểm trong buổi rà soát sprint) — ⚠ buổi rà soát dành cho việc trình diễn sản phẩm với bên liên quan; ⚠ liên hệ #26704 lô 199, và cũng không có bảng kiểm nào trong đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26825 cùng lô (tồn đọng sản phẩm không được xếp lại ưu tiên), ⚠ #26803 cùng lô (ai xếp ưu tiên tồn đọng), ⚠ #26809 cùng lô (vai trò của chủ sản phẩm), ⚠ #26765 lô 200 (chia nhỏ câu chuyện phức tạp), ⚠ #26756 lô 200 (các phương pháp xếp ưu tiên).

⚠ CÁC SỰ KIỆN trong Scrum — đừng lẫn: | Sự kiện | Mục đích | Ai dự | |---|---|---| | ⚠ LẬP KẾ HOẠCH SPRINT | ⚠ chọn việc cho vòng lặp tới, làm rõ hạng mục — CÂU NÀY | ⚠ cả đội + chủ sản phẩm | | ⚠ HỌP ĐỨNG HẰNG NGÀY | ⚠ đồng bộ trong ngày, nêu vật cản | ⚠ đội phát triển — liên hệ #26742 lô 200 | | ⚠ RÀ SOÁT SPRINT | ⚠ trình diễn sản phẩm, lấy phản hồi | ⚠ cả đội + BÊN LIÊN QUAN | | ⚠ HỒI CỨU SPRINT | ⚠ cải tiến CÁCH LÀM VIỆC | ⚠ chỉ đội — liên hệ #26704 lô 199 | | ⚠ TINH CHỈNH TỒN ĐỌNG | ⚠ hoạt động LIÊN TỤC, không phải sự kiện cố định | ⚠ đội + chủ sản phẩm | | ⚠ Mẹo làm bài | ⚠ xác định hoạt động đang diễn ra là gì, rồi kiểm xem phương án có gắn nó vào ĐÚNG sự kiện không — rất nhiều phương án sai chỉ vì gắn đúng việc vào sai chỗ |

⚠ TINH CHỈNH TỒN ĐỌNG gồm những gì: | Việc | Nội dung | |---|---| | ⚠ Thêm chi tiết cho các hạng mục sắp làm | ⚠ tiêu chí nghiệm thu, ràng buộc | | ⚠ Ước lượng | ⚠ điểm câu chuyện — liên hệ #26709 lô 199 | | ⚠ CHIA NHỎ hạng mục quá lớn | ⚠ liên hệ #26765 lô 200 | | ⚠ Sắp xếp lại thứ tự khi có thông tin mới | ⚠ đúng điều đang diễn ra trong đề | | ⚠ Loại bỏ hạng mục không còn giá trị | | | ⚠ Khuyến nghị thường gặp | ⚠ dành khoảng 5–10% thời gian mỗi vòng lặp cho việc này — bỏ qua nó thì buổi lập kế hoạch sprint sẽ biến thành buổi phân tích yêu cầu, và vòng lặp mất một ngày đầu tiên |

⚠ Ba vai và phần việc của họ trong tình huống này: | Vai | Việc | |---|---| | ⚠ CHỦ SẢN PHẨM | ⚠ mang yêu cầu mới tới, quyết định thứ tự cuối cùng — liên hệ #26809 cùng lô | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ làm rõ về mặt kỹ thuật, ước lượng, nêu phụ thuộc | | ⚠ SCRUM MASTER (Natasha) | ⚠ tạo điều kiện cho cuộc trao đổi, giữ nó đúng trọng tâm | | ⚠ Điều đáng ghi nhận | ⚠ chủ sản phẩm mang một yêu cầu "phải làm ngay" nhưng vẫn ngồi lại cùng đội để viết và xếp ưu tiên — đó là cách xử lý đúng, khác hẳn với việc chen ngang một hạng mục vào vòng lặp đang chạy |

Từ khoá nhận diện:

"cả đội cùng viết câu chuyện và xếp ưu tiên" → ⚠ LÀM VIỆC NHÓM + TINH CHỈNH TỒN ĐỌNG "buổi hồi cứu" → ⚠ nhìn lại cách làm việc, không viết câu chuyện "buổi rà soát" → ⚠ trình diễn sản phẩm với bên liên quan "spike" → ⚠ hạng mục nghiên cứu có thời lượng giới hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn dành bao nhiêu thời gian cho việc tinh chỉnh tồn đọng | | | Buổi lập kế hoạch sprint của bạn kéo dài bao lâu | ⚠ quá dài thường nghĩa là tinh chỉnh chưa đủ | | Yêu cầu gấp trong đội bạn được xử lý thế nào | ⚠ chen ngang hay đưa vào tồn đọng |

Và điều mà việc ba vai cùng ngồi viết một câu chuyện người dùng tạo ra: một hạng mục mà đội hiểu đúng ý chủ sản phẩm ngay từ đầu — thay vì một dòng mô tả được chuyển qua chuyển lại rồi hoá ra ai cũng hiểu một kiểu khi bắt tay vào làm.

Đáp án

C — HIỆU SUẤT (Performing).

Vì sao đúng

⚠ Các dấu hiệu trong đề đều thuộc giai đoạn hiệu suất: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ "Đã đi qua giai đoạn hình thành từ lâu" | ⚠ đề tự loại phương án D | | ⚠ "Thôi nghĩ như những cá nhân riêng lẻ" | ⚠ bản sắc tập thể đã hình thành | | ⚠ "Chấp nhận khác biệt của nhau" | ⚠ đã vượt qua giai đoạn sóng gió | | ⚠ "Đã ổn định vào công việc" | ⚠ đã qua cả giai đoạn ổn định | | ⚠ Đón nhận việc bỏ chức danh và làm việc TỰ CHỦ | ⚠ dấu hiệu rõ nhất — đội tự vận hành mà không cần cấu trúc chính thức | | ⚠ Kết luận | ⚠ đội đã đạt tới mức tự tổ chức thật sự |

⚠ Chi tiết quyết định là phản ứng với chương trình thí điểm: ⚠ một đội chưa vững sẽ hoang mang khi chức danh bị xoá bỏ; đội ở giai đoạn hiệu suất lại đón nhận điều đó vì họ đã làm việc theo năng lực chứ không theo chức danh từ lâu.

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

• B (Ổn định — Norming) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cụm "chấp nhận khác biệt của nhau" và "đã ổn định vào công việc" là mô tả kinh điển của giai đoạn ổn định, nên đọc tới đó là rất dễ dừng lại: ⚠ nhưng ⚠ giai đoạn ổn định là lúc đội mới hình thành được các quy tắc chung và bắt đầu làm việc trơn tru ⚠ — ⚠ còn đề nói thêm rằng đội "đã ở cùng nhau một thời gian dài" và sẵn sàng làm việc với sự TỰ CHỦ cao mà không cần chức danh; ⚠ đó là mức độ trưởng thành vượt qua ổn định; ⚠ ranh giới: ổn định là đội làm việc ĐƯỢC với nhau; hiệu suất là đội làm việc TỐT NHẤT mà không cần ai điều phối.

• A (Sóng gió — Storming) — ⚠ giai đoạn va chạm về vai trò và cách làm; ⚠ đề nói rõ đội đã chấp nhận khác biệt.

• D (Hình thành — Forming) — ⚠ đề nói thẳng "đã đi qua giai đoạn này từ lâu".

Ghi nhớ

⚠ Đối chiếu: ⚠ #26683 lô 199 (giai đoạn hình thành — họp đầu tiên), ⚠ #26759 lô 200 (quy tắc ứng xử cho đội mới), ⚠ #26750 lô 200 (đội chưa vượt qua được sóng gió), ⚠ #26816 cùng lô (đội trưởng thành tự tìm giải pháp làm việc), ⚠ #26832 cùng lô (đội mới cần xây lòng tin).

⚠ NĂM GIAI ĐOẠN TUCKMAN — bảng đầy đủ: | Giai đoạn | Đặc điểm | Việc của người dẫn dắt | |---|---|---| | ⚠ HÌNH THÀNH (forming) | ⚠ lịch sự, dè dặt, phụ thuộc người dẫn dắt | ⚠ định hướng, giới thiệu, làm rõ mục tiêu | | ⚠ SÓNG GIÓ (storming) | ⚠ va chạm về vai trò, cách làm, quyền lực | ⚠ hoà giải, nhắc quy tắc, huấn luyện | | ⚠ ỔN ĐỊNH (norming) | ⚠ hình thành quy tắc chung, bắt đầu tin nhau | ⚠ củng cố, lùi lại một bước | | ⚠ HIỆU SUẤT (performing) | ⚠ tự tổ chức, tin nhau hoàn toàn — ĐÁP ÁN | ⚠ gỡ vật cản, bảo vệ đội, trao quyền | | ⚠ GIẢI THỂ (adjourning) | ⚠ kết thúc, chia tay | ⚠ ghi nhận, tổng kết bài học | | ⚠ Điều quan trọng ít người nhớ | ⚠ các giai đoạn KHÔNG một chiều — thêm một người mới, đổi mục tiêu hoặc thay người dẫn dắt đều có thể đẩy đội quay lại sóng gió; liên hệ #26766 lô 200 |

⚠ Donovan nên lãnh đạo thế nào ở giai đoạn này: | Nên | Không nên | |---|---| | ⚠ TRAO QUYỀN và lùi lại | ⚠ chỉ đạo chi tiết | | ⚠ Gỡ vật cản từ bên ngoài | ⚠ can thiệp vào cách đội làm việc | | ⚠ Bảo vệ đội khỏi nhiễu động | ⚠ chuyển mọi áp lực xuống đội | | ⚠ Tìm thử thách mới để đội không chững lại | ⚠ để đội làm mãi một loại việc | | ⚠ Rủi ro đặc trưng của giai đoạn hiệu suất | ⚠ người quản lý can thiệp quá nhiều vì thấy mình "không có việc gì" — đó là cách nhanh nhất kéo một đội đang vận hành tốt trở lại giai đoạn trước |

⚠ Vì sao chương trình thí điểm bỏ chức danh lại phù hợp với đội này: | Lý do | Nội dung | |---|---| | ⚠ Đội đã làm việc theo NĂNG LỰC chứ không theo chức danh | ⚠ bỏ chức danh chỉ là chính thức hoá thực tế | | ⚠ Lòng tin đủ cao để không cần cấu trúc bảo vệ | ⚠ liên hệ #26537 lô 196 — tin cậy là tầng nền | | ⚠ Tự chủ là điều kiện của đội tự tổ chức trong agile | | | ⚠ Đội "đón nhận hoàn toàn" — không ai lo mất vị thế | ⚠ dấu hiệu không còn xung đột về quyền lực | | ⚠ Cảnh báo cho lãnh đạo cấp cao | ⚠ chương trình này thành công với đội của Donovan KHÔNG có nghĩa là nó sẽ thành công với mọi đội — một đội đang ở giai đoạn sóng gió mà bị bỏ chức danh sẽ mất luôn cả cơ chế phân xử cuối cùng |

Từ khoá nhận diện:

"tự chủ cao, không cần chức danh, tin nhau hoàn toàn" → ⚠ HIỆU SUẤT "vừa hình thành quy tắc chung, bắt đầu trơn tru" → ⚠ ổn định "va chạm về vai trò" → ⚠ sóng gió "lịch sự, dè dặt, mới gặp" → ⚠ hình thành

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn đang ở giai đoạn nào | ⚠ và bạn đang lãnh đạo theo giai đoạn nào | | Nếu bạn vắng một tuần, đội có tự chạy được không | ⚠ câu hỏi phân định rõ nhất giữa ổn định và hiệu suất | | Có ai mới vào đội gần đây không | ⚠ nếu có, đội có thể đã lùi một giai đoạn mà bạn chưa để ý |

Và điều mà một đội ở giai đoạn hiệu suất cho phép người dẫn dắt làm: dành thời gian nhìn ra bên ngoài thay vì nhìn vào bên trong — vì bên trong đã tự vận hành, và công việc còn lại của Donovan là bảo đảm không có gì từ bên ngoài phá vỡ điều đó.

Đáp án

B — XÂY DỰNG MỘT KẾ HOẠCH QUẢN LÝ NGUỒN LỰC HIỆU QUẢ.

Vì sao đúng

⚠ Vì sao kế hoạch quản lý nguồn lực là câu trả lời: | Lý do | Nội dung | |---|---| | ⚠ Ban lãnh đạo yêu cầu "tạo ra CÁC QUY TẮC VÀ CHÍNH SÁCH" | ⚠ đó chính là nội dung của một kế hoạch | | ⚠ Phải áp dụng cho MỌI dự án trong tổ chức | ⚠ cần một khung chuẩn, không phải xử lý từng ca | | ⚠ Kế hoạch quản lý nguồn lực bao gồm phát triển và quản lý đội | ⚠ kể cả đội phân tán và đa văn hoá | | ⚠ Nó ghi rõ vai trò, cách giao tiếp, cách đào tạo, cách khen thưởng | ⚠ tất cả đều cần điều chỉnh cho bối cảnh đa văn hoá | | ⚠ Kết luận | ⚠ viết ra thành kế hoạch thì quy tắc mới nhất quán và áp dụng được cho mọi dự án |

⚠ Nguyên tắc chung: ⚠ khi đề hỏi "người quản lý dự án NÊN LÀM GÌ" trong một bối cảnh có nhiều yếu tố cần cân nhắc, câu trả lời thường là LẬP KẾ HOẠCH cho lĩnh vực đó — vì kế hoạch là nơi các cân nhắc được ghi lại và biến thành hành động nhất quán.

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

• D (dành nhiều thời gian hơn cho phát triển đội ngay cả khi mọi người ở cùng một nơi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đầu tư vào phát triển đội là việc luôn đúng và rất phù hợp với bối cảnh đa văn hoá: ⚠ nhưng ⚠ nó chỉ là MỘT hoạt động, trong khi đề yêu cầu tạo ra QUY TẮC VÀ CHÍNH SÁCH cho toàn tổ chức ⚠ — ⚠ và phần "ngay cả khi ở cùng một nơi" làm phương án lệch khỏi trọng tâm là làm việc từ xa; ⚠ phát triển đội là một mục BÊN TRONG kế hoạch quản lý nguồn lực, nên phương án B bao trùm phương án D.

• C (kiểm soát nguồn lực chặt hơn so với khi họ làm cùng chỗ) — ⚠ phản ứng sai với việc làm từ xa; ⚠ giám sát chặt hơn phá huỷ lòng tin, và đội phân tán cần TỰ CHỦ cùng sự rõ ràng chứ không cần bị theo dõi.

• A (xây dựng một đội quản lý dự án mạnh) — ⚠ quá chung chung; ⚠ nó không trả lời câu hỏi về việc xử lý khác biệt văn hoá.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26766 lô 200 (kế hoạch quản lý nguồn lực quy định hệ thống khen thưởng), ⚠ #26786 cùng lô (hiến chương đội cho đội đa ngôn ngữ), ⚠ #26799 cùng lô (đội ba châu lục — cân nhắc múi giờ), ⚠ #26681 lô 198 (nhận thức văn hoá), ⚠ #26832 cùng lô (xây lòng tin trong đội ảo).

⚠ KẾ HOẠCH QUẢN LÝ NGUỒN LỰC cho đội đa văn hoá cần thêm gì: | Nội dung | Chi tiết | |---|---| | ⚠ Quy ước về múi giờ và giờ họp | ⚠ luân phiên giờ bất tiện, không để một nhóm luôn chịu thiệt | | ⚠ Lịch nghỉ lễ của từng quốc gia | ⚠ liên hệ #26828 cùng lô — Tết Nguyên đán | | ⚠ Ngôn ngữ làm việc và quy ước giao tiếp | ⚠ liên hệ #26786 cùng lô | | ⚠ Cách ra quyết định phù hợp với khoảng cách quyền lực khác nhau | ⚠ có văn hoá không phản đối cấp trên công khai | | ⚠ Đào tạo nhận thức văn hoá | ⚠ liên hệ #26681 lô 198 | | ⚠ Hệ thống ghi nhận phù hợp với từng nơi | ⚠ khen cá nhân hay khen tập thể tuỳ văn hoá | | ⚠ Nguyên tắc thiết kế | ⚠ kế hoạch phải nêu NGUYÊN TẮC CHUNG nhưng cho phép ĐIỀU CHỈNH ĐỊA PHƯƠNG — một chính sách áp cứng cho năm quốc gia sẽ sai ở ít nhất bốn nơi |

⚠ Vì sao giám sát chặt hơn là phản ứng sai: | Vấn đề | Nội dung | |---|---| | ⚠ Phá huỷ lòng tin — thứ khó xây nhất ở đội phân tán | ⚠ liên hệ #26832 cùng lô | | ⚠ Nhầm SỰ HIỆN DIỆN với NĂNG SUẤT | ⚠ đo giờ trực tuyến không đo được kết quả | | ⚠ Một số văn hoá coi sự giám sát chặt là dấu hiệu bị nghi ngờ | | | ⚠ Tốn thời gian của cả người quản lý lẫn đội | | | ⚠ Cách đúng | ⚠ làm rõ KỲ VỌNG và KẾT QUẢ, rồi trao quyền — đội từ xa cần biết rõ mình phải giao gì và khi nào, chứ không cần ai đó biết mình đang làm gì vào lúc mười giờ sáng |

⚠ Trình tự việc bạn nên làm: | Bước | Nội dung | |---|---| | ⚠ 1. Tìm hiểu đặc điểm văn hoá của năm quốc gia | ⚠ không phải để dán nhãn mà để lường trước khác biệt | | ⚠ 2. Hỏi chính các thành viên về nhu cầu của họ | ⚠ quan trọng hơn mọi tài liệu về văn hoá | | ⚠ 3. Soạn kế hoạch quản lý nguồn lực | ⚠ ĐÁP ÁN | | ⚠ 4. Cùng từng đội xây hiến chương đội | ⚠ liên hệ #26786 cùng lô | | ⚠ 5. Đào tạo nhận thức văn hoá cho quản lý dự án | | | ⚠ 6. Rà lại định kỳ và điều chỉnh | | | ⚠ Điểm dễ bỏ sót nhất | ⚠ bước 2 — rất nhiều chính sách đa văn hoá được viết bởi người chưa từng hỏi những người mà chính sách đó áp dụng lên |

Từ khoá nhận diện:

"tạo quy tắc và chính sách cho đội đa văn hoá" → ⚠ KẾ HOẠCH QUẢN LÝ NGUỒN LỰC "giám sát chặt hơn vì làm từ xa" → ⚠ phá huỷ lòng tin, phản tác dụng "dành thêm thời gian phát triển đội" → ⚠ một hoạt động bên trong kế hoạch, không bao trùm "xây đội quản lý mạnh" → ⚠ quá chung chung

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có chính sách nào cho đội đa quốc gia không | | | Ai chịu giờ họp bất tiện trong đội bạn | ⚠ nếu luôn là cùng một nhóm thì đó là vấn đề | | Bạn có biết lịch nghỉ lễ của từng nước trong đội không | |

Và điều mà một kế hoạch được viết trước khi mở rộng ra năm quốc gia mua được: quyền không phải xử lý từng khác biệt văn hoá như một sự cố bất ngờ — vì phần lớn chúng hoàn toàn có thể lường trước, chỉ cần có ai đó chịu ngồi xuống viết ra.

Đáp án

D — NẾU RỦI RO ĐI KÈM VỚI PHẦN THƯỞNG TƯƠNG XỨNG THÌ VIỆC CHẤP NHẬN RỦI RO LÀ HỢP LÝ.

Vì sao đúng

⚠ Nguyên lý nền của quản lý rủi ro: | Nguyên lý | Nội dung | |---|---| | ⚠ Rủi ro và phần thưởng luôn đi cùng nhau | ⚠ không có dự án nào không có rủi ro | | ⚠ CHẤP NHẬN là một trong bốn chiến lược HỢP LỆ | ⚠ ngang hàng với né tránh, chuyển giao, giảm nhẹ | | ⚠ Chi phí xử lý rủi ro có thể LỚN HƠN tác động của nó | ⚠ khi đó chấp nhận là lựa chọn kinh tế nhất | | ⚠ Quyết định phải dựa trên KHẨU VỊ RỦI RO của tổ chức | ⚠ liên hệ #26743 lô 200 | | ⚠ Kết luận | ⚠ chấp nhận rủi ro là một quyết định có căn cứ khi lợi ích xứng đáng với mức rủi ro |

⚠ Fern hoàn toàn đúng khi giải thích với Janet: ⚠ cố xử lý MỌI rủi ro là cách tiêu hết ngân sách vào những việc có thể không bao giờ xảy ra ⚠ — ⚠ quản lý rủi ro tốt là biết chọn cái nào đáng xử lý, không phải xử lý tất cả.

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

• C (mọi rủi ro đều phải được giảm nhẹ và chuyển giao) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như một nguyên tắc thận trọng và có trách nhiệm — đúng thứ mà một người giám sát lo lắng như Janet muốn nghe: ⚠ nhưng ⚠ nó sai ở hai điểm: từ "MỌI" và việc gộp hai chiến lược lại như thể phải làm cả hai ⚠ — ⚠ giảm nhẹ và chuyển giao đều TỐN TIỀN, và với một rủi ro xác suất thấp tác động nhỏ thì chi phí xử lý có thể cao hơn chính rủi ro đó; ⚠ mọi phương án chứa từ tuyệt đối như "luôn luôn", "mọi", "không bao giờ" đều đáng nghi trong đề PMP.

• A (không bao giờ có thời điểm hợp lý để chấp nhận rủi ro) — ⚠ phủ định tuyệt đối; ⚠ chấp nhận là chiến lược chuẩn trong PMBOK.

• B (nếu đội chưa từng làm loại dự án này thì chấp nhận rủi ro là hợp lý) — ⚠ lập luận ngược; ⚠ thiếu kinh nghiệm làm rủi ro CAO HƠN, đó là lý do phải xử lý chứ không phải lý do để chấp nhận.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26764 lô 200 (đánh giá và giảm nhẹ rủi ro an toàn), ⚠ #26703 lô 199 (chuyển giao bằng hợp đồng), ⚠ #26817 cùng lô (xếp ưu tiên rủi ro theo giá trị tiền tệ kỳ vọng), ⚠ #26743 lô 200 (kế hoạch quản lý rủi ro và ngưỡng chịu đựng), ⚠ #26725 lô 199 (giám sát rủi ro chưa xảy ra).

⚠ CHẤP NHẬN RỦI RO — hai hình thức: | Hình thức | Nội dung | |---|---| | ⚠ CHẤP NHẬN CHỦ ĐỘNG | ⚠ lập quỹ dự phòng hoặc kế hoạch dự phòng, sẵn sàng nếu nó xảy ra | | ⚠ CHẤP NHẬN BỊ ĐỘNG | ⚠ không làm gì cả, xử lý khi nó xảy ra | | ⚠ Điểm chung | ⚠ cả hai đều là quyết định CÓ Ý THỨC và phải được GHI VÀO SỔ ĐĂNG KÝ RỦI RO — chấp nhận rủi ro khác hoàn toàn với việc quên mất nó, dù kết quả trước mắt trông giống nhau |

⚠ Khi nào CHẤP NHẬN là lựa chọn đúng: | Tình huống | Nội dung | |---|---| | ⚠ Chi phí xử lý cao hơn tác động kỳ vọng | ⚠ so bằng giá trị tiền tệ kỳ vọng — liên hệ #26817 cùng lô | | ⚠ Xác suất rất thấp và tác động nhỏ | | | ⚠ Không có phương án xử lý khả thi | ⚠ ví dụ rủi ro thiên tai, biến động thị trường | | ⚠ Rủi ro nằm trong NGƯỠNG CHỊU ĐỰNG của tổ chức | | | ⚠ Cơ hội đi kèm đủ lớn | ⚠ ĐÁP ÁN — rủi ro tương xứng với phần thưởng | | ⚠ Khi nào KHÔNG được chấp nhận | ⚠ rủi ro về AN TOÀN CON NGƯỜI và rủi ro TUÂN THỦ PHÁP LUẬT — hai loại này không có ngưỡng chấp nhận nào, liên hệ #26764 lô 200 và #26811 cùng lô |

⚠ Fern nên nói gì thêm với Janet: | Nội dung | Cách trình bày | |---|---| | ⚠ Đưa ra con số: xác suất, tác động, giá trị kỳ vọng | ⚠ biến cuộc tranh luận thành phép so sánh | | ⚠ So chi phí xử lý với tác động kỳ vọng | | | ⚠ Nêu rõ đây là chấp nhận CHỦ ĐỘNG hay BỊ ĐỘNG | ⚠ nếu chủ động thì có quỹ dự phòng bao nhiêu | | ⚠ Chỉ ra rủi ro đã được GHI trong sổ và có chủ rủi ro | ⚠ liên hệ #26777 lô 200 | | ⚠ Đối chiếu với ngưỡng chịu đựng của tổ chức | | | ⚠ Điều làm Janet yên tâm nhất | ⚠ không phải là việc rủi ro được xử lý, mà là việc nó được NHÌN THẤY, được tính toán và có người theo dõi — phần lớn nỗi lo của cấp trên đến từ cảm giác có thứ gì đó không ai để mắt tới |

Từ khoá nhận diện:

"rủi ro tương xứng với phần thưởng" → ⚠ CHẤP NHẬN là hợp lý "mọi rủi ro đều phải giảm nhẹ và chuyển giao" → ⚠ từ tuyệt đối, và tốn kém vô ích "không bao giờ được chấp nhận rủi ro" → ⚠ phủ định tuyệt đối, sai "chưa có kinh nghiệm nên chấp nhận rủi ro" → ⚠ lập luận ngược

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có rủi ro nào được ghi là "chấp nhận" không | ⚠ nếu không có cái nào, có thể bạn đang xử lý quá mức | | Bạn có so chi phí xử lý với tác động kỳ vọng không | | | Tổ chức bạn có ngưỡng chịu đựng rủi ro bằng con số không | |

Và điều mà một người quản lý dự án trưởng thành hiểu về rủi ro mà người mới thường chưa: mục tiêu không phải là một dự án không có rủi ro nào — mà là một dự án nơi mọi rủi ro còn lại đều đã được nhìn thấy, được cân đo, và được ai đó cố ý quyết định là đáng chấp nhận.