Ngân hàng đề — PMP® Mock Exam Set II Exam
Tìm thấy 718 câu.
- A Continual requests for involvement
- B Resistance to changes forced upon them by "management"
- C Apparent lack of control
- D Lack of a visible endpoint
Xem giải thích
Đáp án
B — SỰ KHÁNG CỰ TRƯỚC NHỮNG THAY ĐỔI BỊ "BAN LÃNH ĐẠO" ÁP XUỐNG.
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề dùng lẫn lộn hai từ ⚠ — ⚠ phần mô tả nói về "stakeholders" (bên liên quan) nhưng câu hỏi lại hỏi về "investors" (nhà đầu tư); ⚠ hai nhóm này không đồng nhất: mọi nhà đầu tư đều là bên liên quan nhưng ngược lại thì không; ⚠ may là ba phương án còn lại đều là mối lo kinh điển của bên NGOÀI nhìn vào dự án, nên đáp án vẫn xác định được bằng loại trừ.
Vì sao đúng
⚠ Vì sao B là thứ KHÔNG thuộc mối lo của nhà đầu tư: | Yếu tố | Nội dung | |---|---| | ⚠ Kháng cự thay đổi là mối lo của NGƯỜI BÊN TRONG | ⚠ nhân viên, đội thực hiện | | ⚠ Nó nói về cảm giác bị áp đặt | ⚠ chỉ có ý nghĩa với người phải thay đổi cách làm | | ⚠ Nhà đầu tư đứng NGOÀI công việc hằng ngày | ⚠ họ không bị "ban lãnh đạo" ép làm gì cả | | ⚠ Ba phương án còn lại đều là góc nhìn từ ngoài vào | ⚠ mất kiểm soát, không thấy điểm kết thúc, bị đòi tham gia liên tục | | ⚠ Kết luận | ⚠ B là mối lo của người TRONG tổ chức, ba cái kia là mối lo của người theo dõi dự án từ bên ngoài |
⚠ Cách làm dạng câu hỏi phủ định: ⚠ tìm ba phương án cùng thuộc một nhóm rồi loại cái còn lại ⚠ — ⚠ ở đây ba phương án cùng là mối lo về khả năng nhìn thấy và kiểm soát dự án.
Vì sao các phương án khác sai
-
C (cảm giác thiếu kiểm soát) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe rất giống một mối lo "nội bộ" và cũng có màu sắc cảm xúc, nên dễ bị nhóm chung với B: ⚠ nhưng ⚠ đây chính là mối lo hàng đầu của nhà đầu tư khi dự án chuyển sang cách làm lặp ⚠ — ⚠ họ quen với kế hoạch cố định và báo cáo theo cột mốc, còn tồn đọng thay đổi mỗi chặng làm họ thấy như dự án đang trôi; ⚠ cách chữa là cho họ thấy tiến độ bằng sản phẩm chạy được ở mỗi buổi rà soát, thứ còn cụ thể hơn cả biểu đồ Gantt.
-
D (không nhìn thấy điểm kết thúc) — ⚠ mối lo kinh điển của người ngoài với dự án lặp; ⚠ vì phạm vi được xếp lại liên tục nên "bao giờ xong" khó trả lời hơn.
-
A (liên tục bị yêu cầu tham gia) — ⚠ cũng là mối lo thật; ⚠ agile đòi bên liên quan có mặt thường xuyên, và không phải ai cũng có thời gian cho việc đó.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26942 cùng lô (bên liên quan dự buổi rà soát chặng), ⚠ #26917 lô 203 (bên liên quan lo vượt ngân sách), ⚠ #26913 lô 203 (bên liên quan phản đối), ⚠ #26957 cùng lô (nhận diện bên liên quan suốt vòng đời).
⚠ Ba mối lo của người ngoài nhìn vào dự án lặp, và cách chữa: | Mối lo | Cách chữa | |---|---| | ⚠ Cảm giác mất kiểm soát | ⚠ mời dự buổi rà soát, cho thấy sản phẩm chạy được | | ⚠ Không thấy điểm kết thúc | ⚠ lộ trình theo quý, biểu đồ burn-up — liên hệ #26981 cùng lô | | ⚠ Bị đòi tham gia liên tục | ⚠ thoả thuận mức tham gia tối thiểu, gộp các buổi lại | | ⚠ Điểm chung của cả ba | ⚠ đều là vấn đề về KHẢ NĂNG NHÌN THẤY chứ không phải về kết quả — và cả ba đều được chữa bằng cùng một thứ: minh bạch nhiều hơn, thường xuyên hơn |
⚠ Bối cảnh của đề cũng đáng chú ý: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ Tổ chức dùng ma trận chặt (tight matrix) | ⚠ đội ngồi cùng chỗ, người quản lý dự án có quyền lực đáng kể | | ⚠ Có yêu cầu tuân thủ quy định nhà nước | ⚠ tài liệu và vết kiểm toán là bắt buộc | | ⚠ Bên liên quan không hài lòng với cách đường được thiết kế và thi công | ⚠ đây là phản hồi về CÁCH LÀM, không phải về kết quả | | ⚠ Nhận xét | ⚠ trong ngành có quản lý chặt, mối lo "mất kiểm soát" của bên ngoài càng lớn — và câu trả lời không phải là làm ít minh bạch đi cho đỡ bị hỏi, mà là chọn đúng thứ để cho họ thấy |
⚠ Kháng cự thay đổi thuộc về ai: | Nhóm | Biểu hiện | |---|---| | ⚠ Nhân viên thực hiện | ⚠ "cách cũ vẫn chạy tốt mà" — nhóm của phương án B | | ⚠ Quản lý cấp trung | ⚠ sợ mất vai trò kiểm soát | | ⚠ Bên liên quan bên ngoài | ⚠ thường lo về KẾT QUẢ hơn là về cách làm | | ⚠ Cách phân biệt trong đề thi | ⚠ mối lo nào nhắc tới "bị ép", "bị áp đặt", "phải đổi cách làm việc" thì thuộc về người BÊN TRONG; mối lo nào nhắc tới "không thấy", "không kiểm soát được", "bao giờ xong" thì thuộc về người BÊN NGOÀI |
Từ khoá nhận diện:
"kháng cự thay đổi bị áp đặt" → ⚠ mối lo của người BÊN TRONG, không phải nhà đầu tư "thiếu kiểm soát" → ⚠ mối lo số một của người ngoài với dự án lặp "không thấy điểm kết thúc" → ⚠ mối lo thật, chữa bằng lộ trình theo quý "bị đòi tham gia liên tục" → ⚠ mối lo thật, chữa bằng thoả thuận mức tham gia
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có nhìn thấy tiến độ thật không | | | Bạn trả lời được câu "bao giờ xong" thế nào | | | Ai trong tổ chức đang kháng cự cách làm mới | |
Và điều phân biệt mối lo của người trong với người ngoài: người bên trong lo về việc họ phải thay đổi, còn người bên ngoài lo về việc họ không nhìn thấy — và hai nỗi lo đó cần hai câu trả lời hoàn toàn khác nhau.
- A Consult with her project management office.
- B Meet with all the stakeholders to determine roles and responsibilities.
- C Do nothing. The product owner is responsible for this.
- D Speak to other scrum masters or project managers.
Xem giải thích
Đáp án
A — HỎI VĂN PHÒNG QUẢN LÝ DỰ ÁN (PMO) CỦA MÌNH.
Vì sao đúng
⚠ Vì sao PMO là nơi đúng: | Lý do | Nội dung | |---|---| | ⚠ Samantha cần HƯỚNG DẪN CHÍNH THỨC | ⚠ từ khoá của câu hỏi: "formal guidelines" | | ⚠ PMO là nơi giữ chuẩn, mẫu biểu và quy trình | ⚠ đúng chức năng của nó | | ⚠ Bảo đảm nhất quán giữa các dự án trong tổ chức | | | ⚠ Cô ấy ĐÃ tự xác định các nhóm bên liên quan tương tác ra sao | ⚠ phần phân tích đã làm, chỉ thiếu khuôn khổ chính thức | | ⚠ Kết luận | ⚠ cần cái gì chính thức thì hỏi nơi ban hành cái chính thức |
⚠ PMO thường có sẵn: ⚠ mẫu sổ đăng ký bên liên quan, ma trận trách nhiệm RACI, mẫu kế hoạch truyền thông, quy tắc leo thang ⚠ — ⚠ Samantha không cần phát minh lại; liên hệ #26893 lô 203 về việc leo thang theo hướng dẫn của dự án.
Vì sao các phương án khác sai
-
D (hỏi các scrum master hoặc người quản lý dự án khác) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ học từ đồng nghiệp là việc rất tốt và thường nhanh hơn nhiều so với đi qua kênh chính thức: ⚠ nhưng ⚠ đồng nghiệp cho bạn kinh nghiệm cá nhân, không cho bạn hướng dẫn CHÍNH THỨC ⚠ — ⚠ mỗi người sẽ làm một kiểu, và Samantha sẽ phải tự chọn giữa các cách trái ngược nhau mà không biết cách nào được tổ chức công nhận; ⚠ đây là bổ sung rất tốt SAU khi đã có chuẩn của PMO, nhưng không thay thế được nó; ⚠ quy tắc chung cho đề PMP: khi câu hỏi có chữ "chính thức" hoặc "chuẩn", hãy tìm nguồn có thẩm quyền chứ không tìm nguồn thuận tiện.
-
B (họp với tất cả bên liên quan để xác định vai trò và trách nhiệm) — ⚠ là việc sẽ làm SAU khi có khuôn khổ; ⚠ mở một cuộc họp lớn mà chưa có cấu trúc thường tốn thời gian mà không ra kết quả.
-
C (không làm gì, đó là việc của chủ sản phẩm) — ⚠ sai vai trò; ⚠ chủ sản phẩm quản lý tồn đọng và giá trị, còn thu hút bên liên quan là việc của cả đội với sự dẫn dắt của scrum master.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26893 lô 203 (leo thang theo hướng dẫn dự án), ⚠ #26957 cùng lô (nhận diện bên liên quan là việc suốt vòng đời), ⚠ #26973 cùng lô (ma trận ảnh hưởng – quan tâm), ⚠ #26970 cùng lô (hỏi bộ phận chuyên trách trước khi tự dựng kênh).
⚠ BA KIỂU PMO và mức can thiệp: | Kiểu | Vai trò | |---|---| | ⚠ HỖ TRỢ (supportive) | ⚠ cung cấp mẫu, đào tạo, bài học — mức kiểm soát THẤP | | ⚠ KIỂM SOÁT (controlling) | ⚠ yêu cầu tuân thủ khung và quy trình — mức TRUNG BÌNH | | ⚠ CHỈ ĐẠO (directive) | ⚠ trực tiếp quản lý các dự án — mức CAO | | ⚠ Điều đáng nhớ | ⚠ dù thuộc kiểu nào, PMO cũng là nơi lưu giữ chuẩn và bài học của tổ chức — nên nó luôn là nơi hỏi đầu tiên khi cần một hướng dẫn chính thức, kể cả ở PMO kiểu hỗ trợ vốn không ép buộc gì |
⚠ Thu hút bên liên quan gồm bốn quy trình: | Quy trình | Nội dung | |---|---| | ⚠ NHẬN DIỆN bên liên quan | ⚠ liên tục suốt dự án — liên hệ #26957 cùng lô | | ⚠ LẬP KẾ HOẠCH thu hút | ⚠ bước Samantha đang làm | | ⚠ QUẢN LÝ sự tham gia | ⚠ trao đổi, xử lý mối lo, thương lượng | | ⚠ GIÁM SÁT sự tham gia | ⚠ theo dõi thái độ có đổi không | | ⚠ Công cụ trung tâm | ⚠ sổ đăng ký bên liên quan và ma trận mức tham gia hiện tại – mong muốn; cả hai đều là thứ PMO thường có sẵn mẫu |
⚠ Vì sao cần khuôn khổ chính thức chứ không tự làm: | Lý do | Nội dung | |---|---| | ⚠ Bên liên quan thường tham gia nhiều dự án cùng lúc | ⚠ mỗi dự án một kiểu thì họ rất mệt | | ⚠ Có thể có yêu cầu tuân thủ hoặc kiểm toán | | | ⚠ Người mới tiếp quản dự án đọc hiểu được ngay | ⚠ liên hệ #26949 cùng lô | | ⚠ Tránh phát minh lại thứ tổ chức đã có | | | ⚠ Nhận xét | ⚠ Samantha đã làm phần khó — hiểu các nhóm bên liên quan tương tác thế nào; phần còn lại chỉ là đặt hiểu biết đó vào khuôn khổ có sẵn, và đi hỏi là cách nhanh nhất chứ không phải cách yếu đuối nhất |
Từ khoá nhận diện:
"cần hướng dẫn CHÍNH THỨC" → ⚠ hỏi PMO "hỏi đồng nghiệp" → ⚠ kinh nghiệm cá nhân, không phải chuẩn tổ chức "họp tất cả bên liên quan ngay" → ⚠ làm sau khi đã có khuôn khổ "việc của chủ sản phẩm" → ⚠ sai vai trò
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có PMO và bạn biết họ có sẵn những mẫu gì không | | | Sổ đăng ký bên liên quan của bạn có theo chuẩn chung không | | | Bạn có đang tự dựng thứ tổ chức đã có sẵn không | |
Và điều mà một PMO tồn tại để tiết kiệm cho từng người quản lý dự án: quãng thời gian nghĩ ra lần thứ hai một thứ mà tổ chức đã nghĩ ra rồi.
- A Lack of stakeholder management
- B Lack of active listening
- C Lack of leadership
- D Lack of cultural awareness
Xem giải thích
Đáp án
A — THIẾU SỰ QUẢN LÝ BÊN LIÊN QUAN.
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ⚠ — ⚠ dừng ở "Menuka is concerned about allocating resources acros…", tức là "…across projects. This situation demonstrates a…"; ⚠ ý câu hỏi vẫn rõ: tình huống này cho thấy điều gì đang thiếu.
Vì sao đúng
⚠ Vì sao đây là vấn đề quản lý bên liên quan: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ Jan hành động VƯỢT quá vai trò bên liên quan | ⚠ anh ấy cam kết thay cho đội của người khác | | ⚠ Không ai đặt ranh giới cho anh ấy | ⚠ đó chính là phần bị thiếu | | ⚠ Menuka đã NHẬN THẤY dấu hiệu từ trước | ⚠ "đôi lúc thấy Jan như muốn làm trong đội" — nhưng không xử lý | | ⚠ Hậu quả: nguồn lực bị cam kết mà đội không biết | ⚠ rủi ro thật cho dự án | | ⚠ Kết luận | ⚠ thiếu bước THOẢ THUẬN RÕ vai trò và giới hạn thẩm quyền của một bên liên quan |
⚠ Điểm dễ bỏ qua: ⚠ Jan là bên liên quan TỐT — anh ấy bảo vệ đội, lo nguồn lực, dọn vật cản nội bộ ⚠ — ⚠ quản lý bên liên quan không chỉ là xử lý người phản đối, nó cũng là định hướng cho người quá nhiệt tình.
Vì sao các phương án khác sai
-
C (thiếu năng lực lãnh đạo) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ có thể lập luận rằng nếu Menuka lãnh đạo tốt hơn thì cô ấy đã ngăn chuyện này từ sớm, và lãnh đạo là một cái ô rất rộng che được gần như mọi tình huống: ⚠ nhưng ⚠ chính vì nó quá rộng nên nó là câu trả lời kém chính xác nhất ⚠ — ⚠ đề mô tả rất cụ thể một BÊN LIÊN QUAN vượt ranh giới, và PMI có hẳn một lĩnh vực kiến thức cho việc đó; ⚠ quy tắc làm bài: khi có một phương án khớp chính xác với lĩnh vực kiến thức mà tình huống mô tả, đừng chọn phương án tổng quát hơn.
-
B (thiếu lắng nghe chủ động) — ⚠ Menuka đã nghe và đã hiểu được ý đồ của Jan; ⚠ vấn đề là cô ấy chưa HÀNH ĐỘNG sau khi nghe.
-
D (thiếu nhận thức văn hoá) — ⚠ không có yếu tố đa văn hoá nào trong tình huống; ⚠ tự thêm dữ kiện không có trong đề.
Ghi nhớ
⚠ Ghi chú đối chiếu quan trọng — CẶP CÂU KHOÁ NGƯỢC NHAU: ⚠ #27007 lô 205 dùng ĐÚNG BỐN PHƯƠNG ÁN NÀY (thiếu quản lý bên liên quan / thiếu lắng nghe chủ động / thiếu lãnh đạo / thiếu nhận thức văn hoá) nhưng khoá là "THIẾU LÃNH ĐẠO", còn câu này khoá là "THIẾU QUẢN LÝ BÊN LIÊN QUAN" ⚠ — ⚠ hai khoá KHÔNG mâu thuẫn vì hai tình huống khác nhau về bản chất; ⚠ cách phân biệt: ở đây Menuka CÓ MẶT và có thẩm quyền, chỉ là cô ấy không đặt ranh giới cho một bên liên quan quá nhiệt tình → lỗi ở khâu QUẢN LÝ BÊN LIÊN QUAN; ở #27007 thì ghế nhà tài trợ BỎ TRỐNG và không ai đảm nhận vai trò dẫn dắt → lỗi ở khâu LÃNH ĐẠO; ⚠ quy tắc chung: hỏi "có người ở đúng vị trí không" — nếu có mà làm chưa tốt thì chọn lỗi kỹ năng cụ thể; nếu vị trí đó bỏ trống thì chọn thiếu lãnh đạo.
⚠ Đối chiếu: ⚠ #26913 lô 203 (bên liên quan phản đối vẫn là bên liên quan), ⚠ #26942 cùng lô (bên liên quan quan tâm nhiều phần của dự án), ⚠ #26946 cùng lô (ranh giới phạm vi và lời hứa ngoài phạm vi), ⚠ #26973 cùng lô (ma trận ảnh hưởng – quan tâm).
⚠ Bên liên quan QUÁ NHIỆT TÌNH cũng cần quản lý: | Rủi ro | Nội dung | |---|---| | ⚠ Cam kết thay đội mà không hỏi | ⚠ đúng chuyện Jan vừa làm | | ⚠ Can thiệp vào quyết định kỹ thuật | | | ⚠ Vượt cấp, làm rối kênh báo cáo | | | ⚠ Tạo kỳ vọng ở nơi khác mà đội không biết | | | ⚠ Vì sao khó xử lý hơn người phản đối | ⚠ thiện chí của họ là thật và đóng góp của họ là thật, nên rất khó nói "anh dừng lại" mà không làm mất một đồng minh — cách duy nhất hiệu quả là biến năng lượng đó thành một vai trò có ranh giới rõ ràng |
⚠ Menuka nên làm gì bây giờ: | Bước | Nội dung | |---|---| | ⚠ 1. Gặp riêng Jan, CẢM ƠN trước | ⚠ ghi nhận những gì anh ấy đã làm cho đội | | ⚠ 2. Nói rõ tác động của việc cam kết thay đội | ⚠ nguồn lực, ưu tiên, cam kết hiện có | | ⚠ 3. Thoả thuận quy tắc: hỏi trước khi hứa | ⚠ cụ thể, không chung chung | | ⚠ 4. Cho anh ấy một vai trò rõ ràng và có ích | ⚠ hướng nhiệt tình vào đúng chỗ | | ⚠ 5. Xử lý lời hứa đã lỡ với bộ phận kia | ⚠ trung thực và sớm | | ⚠ Điều dễ làm sai nhất | ⚠ im lặng chấp nhận lần này vì ngại làm Jan phật ý — nhưng im lặng chính là điều đã dẫn tới đây, và lần sau quy mô lời hứa sẽ lớn hơn |
⚠ Công cụ ngăn chuyện này từ đầu: | Công cụ | Tác dụng | |---|---| | ⚠ Sổ đăng ký bên liên quan có ghi VAI TRÒ và THẨM QUYỀN | ⚠ liên hệ #26954 cùng lô | | ⚠ Ma trận RACI | ⚠ ai được quyết, ai chỉ được hỏi ý | | ⚠ Kế hoạch thu hút bên liên quan | ⚠ mức tham gia mong muốn của từng người | | ⚠ Quy tắc rõ về việc cam kết nguồn lực | ⚠ chỉ người quản lý dự án mới được hứa thay đội | | ⚠ Nhận xét | ⚠ thẩm quyền không được ghi ra thì sẽ được suy đoán — và một người nhiệt tình luôn suy đoán theo hướng rộng hơn thực tế |
Từ khoá nhận diện:
"bên liên quan tự ý hứa thay đội" → ⚠ thiếu QUẢN LÝ BÊN LIÊN QUAN "thiếu lãnh đạo" → ⚠ quá tổng quát khi đã có lĩnh vực khớp chính xác "thiếu lắng nghe" → ⚠ cô ấy đã nghe, chỉ chưa hành động "thiếu nhận thức văn hoá" → ⚠ không có dữ kiện nào về văn hoá trong đề
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ bên liên quan của bạn có ghi thẩm quyền từng người không | | | Có ai đang hứa thay bạn ở nơi khác không | | | Bạn có đang im lặng trước một hành vi vượt ranh giới vì ngại không | |
Và điều mà một bên liên quan nhiệt tình dạy về quản lý bên liên quan: rằng công việc đó không phải là phân loại người ta thành ủng hộ hay phản đối, mà là giúp mỗi người biết chính xác phần của mình dừng ở đâu.
- A Outsource this step of the production workflow to a contracted group.
- B Do nothing, as the probability of this occurrence is low.
- C Discuss risk triggers with the team and strategize to develop a workaround should this issue present itself.
- D Cancel this step of the production workflow and proceed along with the project without this work.
Xem giải thích
Đáp án
C — BÀN VỚI ĐỘI VỀ CÁC DẤU HIỆU KÍCH HOẠT RỦI RO VÀ CHUẨN BỊ SẴN CÁCH XỬ LÝ NẾU NÓ XẢY RA.
Vì sao đúng
⚠ Loại từng phương án theo chiến lược ứng phó: | Phương án | Chiến lược thật sự | |---|---| | ⚠ A — Thuê ngoài công đoạn đó | ⚠ CHUYỂN GIAO (transfer) | | ⚠ B — Không làm gì vì xác suất thấp | ⚠ CHẤP NHẬN thụ động | | ⚠ D — Bỏ hẳn công đoạn đó | ⚠ NÉ TRÁNH (avoid) | | ⚠ C — Theo dõi dấu hiệu, chuẩn bị cách xử lý | ⚠ phương án duy nhất còn lại — ĐÁP ÁN | | ⚠ Kết luận | ⚠ ba phương án kia đều là các chiến lược KHÁC, được đặt tên rất rõ ràng, nên C là câu trả lời bằng loại trừ |
⚠ Vì sao chuẩn bị trước lại làm giảm rủi ro: ⚠ một rủi ro tác động cao mà có sẵn phương án xử lý sẽ gây thiệt hại nhỏ hơn nhiều so với cùng rủi ro đó khi không ai chuẩn bị ⚠ — ⚠ giảm nhẹ là giảm XÁC SUẤT hoặc giảm TÁC ĐỘNG, và ở đây là giảm tác động.
Vì sao các phương án khác sai
-
A (thuê ngoài công đoạn đó cho một nhà thầu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thuê ngoài đúng là làm rủi ro rời khỏi dự án của bạn, nên cảm giác chủ quan là "rủi ro đã giảm": ⚠ nhưng ⚠ đó là CHUYỂN GIAO chứ không phải giảm nhẹ — rủi ro vẫn tồn tại nguyên vẹn, chỉ đổi người gánh ⚠; ⚠ và bạn phải trả phí bảo hiểm cho việc đó dưới dạng giá hợp đồng cao hơn; ⚠ phân biệt cốt lõi: GIẢM NHẸ làm rủi ro NHỎ ĐI, CHUYỂN GIAO làm rủi ro ĐỔI CHỦ.
-
D (bỏ hẳn công đoạn đó khỏi quy trình) — ⚠ là NÉ TRÁNH; ⚠ và nó còn thay đổi phạm vi, tức là phải qua kiểm soát thay đổi.
-
B (không làm gì vì xác suất thấp) — ⚠ là CHẤP NHẬN thụ động; ⚠ và nó bỏ qua chi tiết quan trọng nhất của đề: tác động CAO trên một dự án 6 triệu đô.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ cách diễn đạt của phương án C nghiêng về KẾ HOẠCH DỰ PHÒNG hơn là giảm nhẹ theo nghĩa chặt ⚠ — ⚠ "bàn về dấu hiệu kích hoạt và chuẩn bị cách xử lý" là mô tả kinh điển của phản ứng dự phòng, còn giảm nhẹ điển hình là những việc như thử nghiệm trước, thêm dư thừa, đơn giản hoá quy trình; ⚠ tuy vậy hai khái niệm này chồng lấn nhau vì kế hoạch dự phòng làm giảm TÁC ĐỘNG, mà giảm tác động chính là một nửa định nghĩa của giảm nhẹ; ⚠ quan trọng hơn: ba phương án kia đã được gán nhãn quá rõ cho ba chiến lược khác, nên trong phòng thi vẫn chọn C bằng loại trừ.
⚠ Đối chiếu: ⚠ #26928 lô 203 (nhận diện rủi ro càng sớm càng tốt), ⚠ #26897 lô 203 (Monte Carlo), ⚠ #26792 lô 201 (khi nào chấp nhận rủi ro), ⚠ #26974 cùng lô (mời chuyên gia phân tích rủi ro).
⚠ Chiến lược cho rủi ro TIÊU CỰC (đe doạ): | Chiến lược | Nội dung | |---|---| | ⚠ NÉ TRÁNH (avoid) | ⚠ loại bỏ nguyên nhân hoặc đổi kế hoạch để rủi ro không thể xảy ra | | ⚠ GIẢM NHẸ (mitigate) | ⚠ giảm xác suất hoặc giảm tác động — ĐÁP ÁN | | ⚠ CHUYỂN GIAO (transfer) | ⚠ bảo hiểm, hợp đồng, thuê ngoài — bên khác gánh | | ⚠ LEO THANG (escalate) | ⚠ rủi ro nằm ngoài thẩm quyền dự án | | ⚠ CHẤP NHẬN (accept) | ⚠ chủ động (có dự phòng) hoặc thụ động (không làm gì) | | ⚠ Đối xứng với rủi ro TÍCH CỰC | ⚠ khai thác, tăng cường, chia sẻ, leo thang, chấp nhận — năm chiến lược, tương ứng từng cặp một |
⚠ Dấu hiệu kích hoạt rủi ro (risk trigger) là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Là dấu hiệu cảnh báo rằng rủi ro SẮP hoặc ĐANG xảy ra | | | ⚠ Phải quan sát được và đo được | ⚠ "tỷ lệ lỗi vượt 3%" chứ không phải "chất lượng có vẻ kém" | | ⚠ Phải có người được giao theo dõi | ⚠ chủ rủi ro | | ⚠ Gắn với một phản ứng đã chuẩn bị sẵn | | | ⚠ Vì sao dấu hiệu quan trọng đến vậy | ⚠ một phương án dự phòng hay đến mấy cũng vô dụng nếu không ai nhận ra thời điểm phải kích hoạt nó — và với rủi ro xác suất thấp thì mọi người lại càng dễ quên là nó có tồn tại |
⚠ Vì sao rủi ro xác suất thấp – tác động cao là loại nguy hiểm nhất: | Lý do | Nội dung | |---|---| | ⚠ Dễ bị bỏ qua vì "chắc không xảy ra đâu" | ⚠ đúng như phương án B | | ⚠ Khi xảy ra thì thiệt hại rất lớn | ⚠ dự án 6 triệu đô | | ⚠ Không ai có kinh nghiệm xử lý vì nó hiếm | | | ⚠ Nhận xét | ⚠ rủi ro xác suất cao thì ai cũng thấy và ai cũng lo; rủi ro hiếm mà nặng thì cần một quy trình để buộc người ta phải nghĩ tới — và đó chính là lý do sổ rủi ro tồn tại |
Từ khoá nhận diện:
"theo dõi dấu hiệu, chuẩn bị cách xử lý" → ⚠ GIẢM NHẸ / dự phòng "thuê ngoài" → ⚠ CHUYỂN GIAO, rủi ro đổi chủ chứ không nhỏ đi "bỏ hẳn công đoạn" → ⚠ NÉ TRÁNH, và đổi phạm vi "xác suất thấp nên không làm gì" → ⚠ CHẤP NHẬN thụ động, bỏ qua tác động cao
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có ghi dấu hiệu kích hoạt cho từng dòng không | | | Mỗi rủi ro có một người chịu trách nhiệm theo dõi không | | | Rủi ro hiếm mà nặng nhất của bạn đã có phương án chưa | |
Và điều mà việc chuẩn bị sẵn phản ứng làm được cho một rủi ro hiếm gặp: biến một cuộc khủng hoảng thành một quy trình — vì thứ quyết định thiệt hại không phải là rủi ro có xảy ra hay không, mà là bạn mất bao lâu để bắt đầu xử lý nó.
- A To be completed throughout the lifecycle of the project.
- B The project sponsor's responsibility.
- C Should not be completed in any phase of the project.
- D Only for stakeholders who will give positive contributions to the project.
Xem giải thích
Đáp án
A — LÀ VIỆC PHẢI THỰC HIỆN XUYÊN SUỐT VÒNG ĐỜI DỰ ÁN.
Vì sao đúng
⚠ Vì sao nhận diện bên liên quan không bao giờ kết thúc: | Lý do | Nội dung | |---|---| | ⚠ Bên liên quan MỚI xuất hiện ở mọi giai đoạn | ⚠ nhà cung cấp, cơ quan quản lý, phòng ban mới bị ảnh hưởng | | ⚠ Người cũ rời đi, người thay thế có quan điểm khác | | | ⚠ Mức quan tâm và ảnh hưởng THAY ĐỔI theo thời gian | ⚠ người thờ ơ lúc đầu có thể thành người quyết định | | ⚠ Phạm vi thay đổi kéo theo nhóm bị ảnh hưởng thay đổi | | | ⚠ Kết luận | ⚠ sổ đăng ký bên liên quan là tài liệu SỐNG, phải cập nhật liên tục |
⚠ Áp dụng cho Norah: ⚠ triển khai một hệ thống máy tính mới sẽ chạm tới nhiều phòng ban hơn con số cô ấy nhìn thấy hôm nay ⚠ — ⚠ những người chỉ nhận ra mình bị ảnh hưởng khi hệ thống sắp chạy chính là nguồn phản đối muộn và tốn kém nhất.
Vì sao các phương án khác sai
-
D (chỉ dành cho những bên liên quan sẽ đóng góp tích cực) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ về mặt thực dụng, ai cũng muốn dành thời gian cho người ủng hộ mình thay vì cho người gây khó dễ: ⚠ nhưng ⚠ chính đề bài đã bác bỏ nó — đề nói rõ bên liên quan "có thể tác động TÍCH CỰC HOẶC TIÊU CỰC" ⚠; ⚠ và về bản chất, bên liên quan tiêu cực mới là nhóm cần được nhận diện SỚM NHẤT, vì họ là nguồn rủi ro lớn nhất cho dự án; ⚠ liên hệ #26913 lô 203: công đoàn phản đối vẫn là bên liên quan, và bỏ họ khỏi danh sách không làm họ biến mất.
-
B (là trách nhiệm của nhà tài trợ) — ⚠ nhà tài trợ giúp nhận diện, nhất là ở cấp lãnh đạo; ⚠ nhưng trách nhiệm thuộc về người quản lý dự án.
-
C (không nên làm ở bất kỳ giai đoạn nào) — ⚠ vô lý và mâu thuẫn với chính việc Norah đang làm.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26913 lô 203 (bên liên quan phản đối vẫn là bên liên quan), ⚠ #26954 cùng lô (khuôn khổ chính thức từ PMO), ⚠ #26973 cùng lô (ma trận ảnh hưởng – quan tâm), ⚠ #26974 cùng lô (thu hút một bên liên quan có kinh nghiệm), ⚠ #26955 cùng lô (quản lý bên liên quan quá nhiệt tình).
⚠ Khi nào nên rà lại danh sách bên liên quan: | Thời điểm | Vì sao | |---|---| | ⚠ Khi bắt đầu mỗi giai đoạn mới | ⚠ giai đoạn khác chạm tới nhóm khác | | ⚠ Sau mỗi thay đổi phạm vi được duyệt | ⚠ phạm vi mới, người bị ảnh hưởng mới | | ⚠ Khi có thay đổi nhân sự ở phía bên liên quan | ⚠ người mới không có cùng cam kết với người cũ | | ⚠ Khi có tái cơ cấu tổ chức | | | ⚠ Khi phát sinh vấn đề từ một hướng không ngờ tới | ⚠ dấu hiệu bạn đã bỏ sót ai đó | | ⚠ Thực hành đơn giản mà hiệu quả | ⚠ đưa câu "có ai mới cần đưa vào danh sách không" vào phần cố định của buổi họp tình trạng — nó tốn ba mươi giây và bắt được phần lớn các trường hợp bỏ sót |
⚠ Sổ đăng ký bên liên quan nên có gì: | Trường | Nội dung | |---|---| | ⚠ Tên, vai trò, phòng ban | | | ⚠ Mức ẢNH HƯỞNG và mức QUAN TÂM | ⚠ liên hệ #26973 cùng lô | | ⚠ Thái độ hiện tại và thái độ MONG MUỐN | ⚠ không biết, kháng cự, trung lập, ủng hộ, dẫn dắt | | ⚠ Kỳ vọng và mối lo chính | | | ⚠ Chiến lược trao đổi và tần suất | | | ⚠ Lưu ý về bảo mật | ⚠ sổ này chứa đánh giá về con người nên KHÔNG phải tài liệu công khai — ghi khách quan và đừng viết điều bạn không muốn chính người đó đọc được |
⚠ Cái giá của việc bỏ sót một bên liên quan: | Hệ quả | Nội dung | |---|---| | ⚠ Yêu cầu quan trọng bị bỏ quên | ⚠ phát hiện lúc nghiệm thu | | ⚠ Phản đối vào phút chót | ⚠ đúng lúc đắt nhất để thay đổi | | ⚠ Người bị bỏ quên thành người phản đối | ⚠ kể cả khi ban đầu họ trung lập | | ⚠ Nhận xét | ⚠ phần lớn "bên liên quan gây khó dễ" thật ra là bên liên quan bị bỏ quên — người ta hiếm khi phản đối một dự án mà họ được mời tham gia từ đầu |
Từ khoá nhận diện:
"nhận diện bên liên quan" → ⚠ SUỐT VÒNG ĐỜI, không phải một lần "chỉ nhận diện người đóng góp tích cực" → ⚠ sai, người tiêu cực còn cần nhận diện sớm hơn "trách nhiệm của nhà tài trợ" → ⚠ nhà tài trợ hỗ trợ, PM chịu trách nhiệm "sổ đăng ký bên liên quan" → ⚠ tài liệu SỐNG, cập nhật liên tục
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ bên liên quan của bạn cập nhật lần cuối khi nào | | | Có ai đang bị dự án của bạn ảnh hưởng mà chưa có trong sổ không | | | Ai đã thay đổi thái độ từ đầu dự án tới giờ | |
Và điều mà mọi dự án học được theo cách đắt nhất về bên liên quan: danh sách bạn lập trong tuần đầu tiên luôn là danh sách thiếu — vấn đề chỉ là bạn phát hiện điều đó ở tháng thứ hai hay ở buổi nghiệm thu.
- A Timeframe
- B Risks
- C Target benefits
- D Cultural alignment
Xem giải thích
Đáp án
D — SỰ PHÙ HỢP VỀ VĂN HOÁ (cultural alignment).
Vì sao đúng
⚠ Kế hoạch quản lý lợi ích gồm những gì: | Thành phần | Nội dung | |---|---| | ⚠ LỢI ÍCH MỤC TIÊU | ⚠ giá trị hữu hình và vô hình dự kiến đạt được | | ⚠ SỰ PHÙ HỢP CHIẾN LƯỢC | ⚠ dự án gắn với chiến lược tổ chức thế nào | | ⚠ KHUNG THỜI GIAN | ⚠ khi nào lợi ích bắt đầu và kéo dài bao lâu | | ⚠ CHỦ SỞ HỮU LỢI ÍCH | ⚠ ai chịu trách nhiệm theo dõi và thu về | | ⚠ CHỈ SỐ ĐO | ⚠ đo lợi ích bằng gì | | ⚠ GIẢ ĐỊNH và RỦI RO | | | ⚠ Kết luận | ⚠ "phù hợp VĂN HOÁ" không nằm trong danh sách — thứ có trong đó là phù hợp CHIẾN LƯỢC |
⚠ Bẫy nằm ở một chữ: ⚠ đổi "chiến lược" thành "văn hoá" và cụm từ vẫn nghe rất thuận tai ⚠ — ⚠ đây là dạng thuật ngữ bịa tinh vi nhất: không bịa hẳn một từ mới mà chỉ thay một chữ trong một cụm có thật.
Vì sao các phương án khác sai
-
B (rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ rủi ro có kế hoạch riêng của nó và có sổ rủi ro riêng, nên rất dễ nghĩ rằng nó không thuộc kế hoạch quản lý lợi ích: ⚠ nhưng ⚠ kế hoạch quản lý lợi ích CÓ mục rủi ro — đó là các rủi ro đe doạ việc THU VỀ được lợi ích, một loại rủi ro khác với rủi ro thực hiện dự án ⚠; ⚠ ví dụ: dự án cải thiện tinh thần nhân viên có thể hoàn thành đúng hạn nhưng lợi ích không tới nếu quản lý cấp trung không thay đổi hành vi; ⚠ rủi ro dự án hỏi "ta có làm xong được không", rủi ro lợi ích hỏi "làm xong rồi thì có được gì không".
-
A (khung thời gian) — ⚠ có trong kế hoạch; ⚠ lợi ích thường đến SAU khi dự án kết thúc nên mốc thời gian là bắt buộc.
-
C (lợi ích mục tiêu) — ⚠ là thành phần trung tâm của cả kế hoạch.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26977 cùng lô (đo lợi ích của từng sản phẩm bàn giao), ⚠ #26971 cùng lô (các thành phần của giá trị kinh doanh), ⚠ #26840 lô 202 (ROI), ⚠ #26917 lô 203 (nhắc lại giá trị đã bàn giao).
⚠ Kế hoạch quản lý lợi ích khác kế hoạch quản lý dự án thế nào: | Kế hoạch dự án | Kế hoạch quản lý lợi ích | |---|---| | ⚠ Trả lời "làm thế nào để hoàn thành" | ⚠ trả lời "làm xong rồi thì thu được gì" | | ⚠ Kết thúc khi dự án đóng | ⚠ kéo dài SAU khi dự án đóng | | ⚠ Chủ sở hữu: người quản lý dự án | ⚠ chủ sở hữu: bên nghiệp vụ hưởng lợi | | ⚠ Đo bằng phạm vi, tiến độ, chi phí | ⚠ đo bằng chỉ số nghiệp vụ | | ⚠ Vì sao phải tách ra | ⚠ rất nhiều dự án hoàn thành đúng ba ràng buộc mà không mang lại lợi ích nào — và nếu không ai được giao theo dõi phần lợi ích thì sẽ không bao giờ có ai phát hiện ra điều đó |
⚠ Áp dụng cho dự án cải thiện tinh thần trong đề: | Thành phần | Ví dụ cụ thể | |---|---| | ⚠ Lợi ích mục tiêu | ⚠ giảm tỷ lệ nghỉ việc, tăng điểm gắn kết | | ⚠ Phù hợp chiến lược | ⚠ giữ người là mục tiêu của tổ chức | | ⚠ Khung thời gian | ⚠ đo sau 6 và 12 tháng, không đo ngay | | ⚠ Chủ sở hữu lợi ích | ⚠ trưởng bộ phận nhân sự | | ⚠ Chỉ số | ⚠ tỷ lệ nghỉ việc, khảo sát định kỳ, số lời khen được ghi nhận | | ⚠ Rủi ro lợi ích | ⚠ quản lý cấp trung vẫn nhận công của nhân viên — thì mọi quy trình mới đều vô ích | | ⚠ Nhận xét về sự nhiệt tình cá nhân | ⚠ đề nói bạn đích thân chứng kiến vấn đề và rất tâm huyết — đó là động lực tốt, nhưng chính vì thế mà càng cần các CHỈ SỐ khách quan, vì người tâm huyết dễ nhìn thấy tiến bộ ở nơi chưa có |
⚠ Phù hợp CHIẾN LƯỢC là gì, để khỏi nhầm với văn hoá: | Khái niệm | Nội dung | |---|---| | ⚠ Phù hợp chiến lược | ⚠ dự án phục vụ mục tiêu chiến lược nào của tổ chức — CÓ trong kế hoạch | | ⚠ Phù hợp văn hoá | ⚠ cách làm việc hợp với giá trị và thói quen của tổ chức — không phải mục của kế hoạch này | | ⚠ Vì sao dễ lẫn | ⚠ cả hai đều nói về việc "hợp với tổ chức", nhưng một cái nói về MỤC TIÊU còn cái kia nói về CÁCH LÀM — và chỉ cái thứ nhất mới quyết định dự án có đáng đầu tư hay không |
Từ khoá nhận diện:
"phù hợp văn hoá" → ⚠ KHÔNG có trong kế hoạch quản lý lợi ích "phù hợp chiến lược" → ⚠ CÓ, và là thành phần bắt buộc "rủi ro" → ⚠ CÓ, nhưng là rủi ro với việc THU VỀ lợi ích "khung thời gian" → ⚠ CÓ, vì lợi ích thường đến sau khi dự án đóng
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có kế hoạch quản lý lợi ích không | | | Ai được giao theo dõi lợi ích sau khi dự án đóng | | | Bạn đo lợi ích bằng chỉ số gì | |
Và câu hỏi mà kế hoạch quản lý lợi ích buộc tổ chức phải trả lời, còn kế hoạch dự án thì không: sáu tháng sau khi mọi người đã chuyển sang việc khác, ai sẽ là người kiểm tra xem tất cả những việc này có đáng làm hay không.
- A This is true; creating a WBS is engaging and collaborative for team members.
- B This is true; creating a WBS allows for role definition and team composition to be finalized.
- C This is not true; creating a WBS is done before a team is formed.
- D This is not true; creating a WBS is done solely by the project manager.
Xem giải thích
Đáp án
A — ĐÚNG; VIỆC LẬP WBS CUỐN HÚT VÀ MANG TÍNH HỢP TÁC ĐỐI VỚI CÁC THÀNH VIÊN TRONG ĐỘI.
Vì sao đúng
⚠ Vì sao lập WBS lại là hoạt động xây dựng đội: | Yếu tố | Nội dung | |---|---| | ⚠ Cả đội cùng chẻ nhỏ công việc | ⚠ mọi người đều đóng góp chuyên môn của mình | | ⚠ Ai cũng nhìn thấy bức tranh TOÀN CẢNH | ⚠ hiểu phần mình khớp vào đâu | | ⚠ Tạo hiểu biết CHUNG về phạm vi | ⚠ nền tảng của mọi việc sau này | | ⚠ Tạo QUYỀN SỞ HỮU với kế hoạch | ⚠ liên hệ #26950 cùng lô về sự đồng thuận | | ⚠ Là dịp các thành viên mới học về dự án và về nhau | | | ⚠ Kết luận | ⚠ xây dựng đội không nhất thiết phải là trò chơi hay buổi dã ngoại — làm việc thật cùng nhau là cách xây đội hiệu quả nhất |
⚠ Nguyên tắc của PMI: ⚠ lập kế hoạch có sự tham gia vừa cho kế hoạch tốt hơn vừa cho đội gắn kết hơn ⚠ — ⚠ đó là hai lợi ích từ cùng một buổi làm việc.
Vì sao các phương án khác sai
-
B (Đúng; vì lập WBS cho phép chốt định nghĩa vai trò và thành phần đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng bắt đầu bằng chữ "Đúng" giống đáp án, và WBS quả thật CÓ dẫn tới việc phân vai — ma trận RACI được xây từ WBS: ⚠ nhưng ⚠ lý do nó nêu là SAI về mặt thứ tự: WBS chẻ nhỏ SẢN PHẨM BÀN GIAO chứ không phân công người ⚠ — ⚠ việc phân vai và xác định thành phần đội diễn ra ở quy trình khác, sau khi đã có danh sách hoạt động; ⚠ và quan trọng hơn, "chốt vai trò" không phải là lý do khiến một hoạt động trở thành hoạt động XÂY DỰNG ĐỘI — thứ làm nên điều đó là sự tham gia và hợp tác; ⚠ dạng bẫy quen thuộc: kết luận đúng, lý do sai — luôn phải đọc hết cả vế sau dấu chấm phẩy.
-
C (Không đúng; WBS được lập trước khi có đội) — ⚠ sai thực tế; ⚠ đội cốt lõi phải có mặt để lập WBS, vì chính họ có chuyên môn để chẻ nhỏ công việc.
-
D (Không đúng; WBS do một mình người quản lý dự án lập) — ⚠ sai và là một trong những sai lầm tai hại nhất trong thực tế; ⚠ WBS do một người tự lập gần như luôn thiếu sót và không ai thấy mình có trách nhiệm với nó.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26910 lô 203 (WBS là nền của mọi ước lượng), ⚠ #26912 lô 203 (trình tự lập tiến độ sau WBS), ⚠ #26950 cùng lô (cả đội cùng giải quyết vấn đề tạo đồng thuận), ⚠ #26941 cùng lô (tham gia quyết định tạo cam kết).
⚠ Các hoạt động lập kế hoạch cũng là xây dựng đội: | Hoạt động | Lợi ích kép | |---|---| | ⚠ Lập WBS cùng nhau | ⚠ hiểu chung về phạm vi — câu này | | ⚠ Nhận diện rủi ro tập thể | ⚠ cả đội cùng nhìn ra nguy cơ | | ⚠ Ước lượng bằng planning poker | ⚠ tranh luận làm lộ ra hiểu nhầm — liên hệ #26919 lô 203 | | ⚠ Thoả thuận quy tắc ứng xử | ⚠ liên hệ #26931 lô 203 | | ⚠ Buổi cải tiến cuối chặng | ⚠ liên hệ #26905 lô 203 | | ⚠ Điểm chung | ⚠ tất cả đều là công việc THẬT làm cùng nhau — và đó là lý do chúng xây đội hiệu quả hơn nhiều so với các hoạt động gắn kết tách rời khỏi công việc |
⚠ WBS lập một mình khác WBS lập cùng đội thế nào: | Lập một mình | Lập cùng đội | |---|---| | ⚠ Thiếu các gói công việc mà chỉ chuyên gia biết | ⚠ đầy đủ hơn nhiều | | ⚠ Đội nhận kế hoạch như nhận một mệnh lệnh | ⚠ đội coi đó là kế hoạch của mình | | ⚠ Sai sót lộ ra khi đã bắt đầu làm | ⚠ sai sót lộ ra ngay trong buổi lập | | ⚠ Nhanh trong ngày hôm đó | ⚠ tốn một buổi, tiết kiệm nhiều tuần | | ⚠ Nhận xét | ⚠ thời gian bỏ ra để cả đội cùng lập WBS gần như luôn được hoàn lại — không phải bằng một bản WBS đẹp hơn, mà bằng việc không ai còn hỏi "sao lại phải làm cái này" |
⚠ Bốn giai đoạn phát triển đội và chỗ của buổi lập WBS: | Giai đoạn | Nội dung | |---|---| | ⚠ Hình thành (forming) | ⚠ làm quen, dè dặt — buổi lập WBS rất hợp ở đây | | ⚠ Bão tố (storming) | ⚠ va chạm quan điểm, và tranh luận về phạm vi là dạng va chạm lành mạnh | | ⚠ Định chuẩn (norming) | ⚠ hình thành cách làm việc chung | | ⚠ Thể hiện (performing) | ⚠ làm việc hiệu quả | | ⚠ Vì sao WBS hợp với giai đoạn đầu | ⚠ nó cho mọi người một lý do cụ thể để nói chuyện với nhau về công việc, thay vì phải làm quen bằng những cuộc trò chuyện xã giao mà nhiều kỹ sư rất ngại |
Từ khoá nhận diện:
"lập WBS là hoạt động xây dựng đội" → ⚠ ĐÚNG, vì cuốn hút và hợp tác "vì nó chốt vai trò và thành phần đội" → ⚠ kết luận đúng, LÝ DO sai "WBS lập trước khi có đội" → ⚠ sai, cần đội cốt lõi tham gia "WBS do một mình PM lập" → ⚠ sai, và là sai lầm phổ biến trong thực tế
Ba việc kiểm chứng: | Việc | Cách | |---|---| | WBS gần nhất của bạn do bao nhiêu người cùng lập | | | Đội bạn có ai chưa từng nhìn thấy WBS toàn dự án không | | | Buổi lập kế hoạch của bạn có phải là dịp đội nói chuyện với nhau không | |
Và điều mà một buổi cả đội cùng chẻ nhỏ công việc tạo ra ngoài bản WBS: một nhóm người đã cùng tranh luận về ranh giới công việc của nhau — và sau đó thì không ai còn hiểu phạm vi theo một kiểu riêng nữa.
- A Assistance with creating a shared understanding of how agile deliverables meet those requirements.
- B Compromising with all parties so that everyone receives a feature they want.
- C Evaluating the amount of documentation required, so teams are spending more time delivering a valuable product instead of producing exhaustive documentation.
- D Working with the R&D department to review the required documentation.
Xem giải thích
Đáp án
B — THOẢ HIỆP VỚI TẤT CẢ CÁC BÊN ĐỂ AI CŨNG NHẬN ĐƯỢC MỘT TÍNH NĂNG MÀ HỌ MUỐN.
Vì sao đúng
⚠ Vì sao đây là việc KHÔNG nên làm: | Vấn đề | Nội dung | |---|---| | ⚠ Câu hỏi là về HIỂU BIẾT CHUNG, không phải về chia phần | ⚠ đề hỏi cách tạo shared understanding | | ⚠ Cho mỗi bên một tính năng là mua sự im lặng | ⚠ không giải quyết bất đồng thật | | ⚠ Bỏ qua thứ tự ưu tiên theo GIÁ TRỊ | ⚠ tính năng được chọn vì ai đòi, không vì nó đáng làm | | ⚠ Lãnh đạo phụng sự KHÔNG phải là làm hài lòng tất cả | ⚠ hiểu nhầm phổ biến nhất về vai trò này | | ⚠ Kết luận | ⚠ thoả hiệp kiểu chia phần tạo ra sản phẩm chắp vá và một sự đồng thuận giả |
⚠ Ba phương án còn lại đều hướng tới cùng một việc: ⚠ giúp hai bên HIỂU nhau — bộ phận R&D cần thấy sản phẩm agile vẫn đáp ứng yêu cầu của họ, còn đội agile cần hiểu vì sao R&D đòi tài liệu ⚠ — ⚠ đó là công việc thật của lãnh đạo phụng sự.
Vì sao các phương án khác sai
-
C (đánh giá lượng tài liệu cần thiết để đội dành nhiều thời gian hơn cho việc tạo giá trị) — ⚠ phương án gây nhiễu mạnh nhất trong ba phương án "nên làm" vì ⚠ nó nghe hơi thiên vị đội agile, như thể mục tiêu là cắt bớt tài liệu của R&D, nên dễ bị chọn nhầm là việc không nên làm: ⚠ nhưng ⚠ nó nói "ĐÁNH GIÁ lượng tài liệu cần thiết", tức là cùng nhau xem xét xem thật sự cần bao nhiêu — chứ không phải đơn phương cắt ⚠; ⚠ và điều này khớp đúng với giá trị agile: tài liệu VỪA ĐỦ, không phải KHÔNG tài liệu; ⚠ trong một môi trường R&D có yêu cầu tuân thủ, việc cùng xác định mức tài liệu tối thiểu cần thiết là một cuộc trò chuyện rất chính đáng.
-
A (giúp tạo hiểu biết chung về việc sản phẩm agile đáp ứng các yêu cầu đó thế nào) — ⚠ đúng trọng tâm câu hỏi; ⚠ đây là việc nên làm.
-
D (làm việc với bộ phận R&D để rà soát tài liệu được yêu cầu) — ⚠ cũng là việc nên làm; ⚠ hiểu yêu cầu của bên kia trước khi bàn cách đáp ứng.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26943 cùng lô (phần mềm chạy được hơn tài liệu đầy đủ, nhưng tài liệu vẫn có giá trị), ⚠ #26927 lô 203 (các nguyên lý lãnh đạo phụng sự), ⚠ #26963 cùng lô (hợp đồng agile và sự phù hợp với mục đích nghiệp vụ), ⚠ #26950 cùng lô (tạo sự đồng thuận thật).
⚠ Lãnh đạo phụng sự LÀ gì và KHÔNG PHẢI gì: | Là | Không phải là | |---|---| | ⚠ Dọn vật cản cho đội | ⚠ làm hài lòng tất cả mọi người | | ⚠ Tạo điều kiện để đội tự quyết | ⚠ né mọi xung đột | | ⚠ Bảo vệ đội khỏi nhiễu bên ngoài | ⚠ đồng ý với mọi yêu cầu | | ⚠ Giúp các bên hiểu nhau | ⚠ chia phần cho công bằng | | ⚠ Khác biệt cốt lõi | ⚠ phụng sự nghĩa là phục vụ MỤC TIÊU CHUNG và sự phát triển của đội, không phải phục vụ mong muốn của từng người — và đôi khi phục vụ đúng nghĩa là nói không |
⚠ Vì sao "ai cũng được một tính năng" là cái bẫy: | Hậu quả | Nội dung | |---|---| | ⚠ Tồn đọng bị xếp theo CHÍNH TRỊ, không theo giá trị | | | ⚠ Sản phẩm mất tính nhất quán | ⚠ máy xay êm mà đầy tính năng lạc lõng | | ⚠ Bất đồng thật bị đẩy xuống dưới | ⚠ và nó sẽ quay lại ở chặng sau | | ⚠ Tạo tiền lệ: cứ đòi thì sẽ được | | | ⚠ Cách xử lý đúng | ⚠ đưa mọi yêu cầu vào cùng một tồn đọng và để chủ sản phẩm xếp theo giá trị — cách này khó chịu hơn trong ngắn hạn nhưng là cách duy nhất giữ được tính toàn vẹn của sản phẩm; liên hệ #26961 cùng lô |
⚠ Cầu nối giữa đội agile và bộ phận đòi tài liệu: | Việc nên làm | Nội dung | |---|---| | ⚠ Hỏi tài liệu đó phục vụ MỤC ĐÍCH gì | ⚠ thường là tuân thủ, an toàn, hoặc bàn giao | | ⚠ Tìm dạng tài liệu nhẹ hơn đáp ứng cùng mục đích | ⚠ quyết định kiến trúc ngắn, kiểm thử tự động, video demo | | ⚠ Mời R&D dự buổi rà soát chặng | ⚠ thấy sản phẩm chạy được thường thuyết phục hơn tài liệu | | ⚠ Sinh tài liệu như một phần của định nghĩa hoàn thành | ⚠ không dồn về cuối | | ⚠ Nguyên tắc | ⚠ agile không chống lại tài liệu, nó chống lại tài liệu KHÔNG AI ĐỌC — nên câu hỏi đúng luôn là "ai sẽ đọc cái này và để làm gì", chứ không phải "có bắt buộc không" |
Từ khoá nhận diện:
"thoả hiệp để ai cũng có một tính năng" → ⚠ KHÔNG nên làm, mua sự im lặng "tạo hiểu biết chung" → ⚠ đúng trọng tâm của lãnh đạo phụng sự "đánh giá lượng tài liệu cần thiết" → ⚠ nên làm, tài liệu VỪA ĐỦ "rà soát yêu cầu tài liệu cùng R&D" → ⚠ nên làm, hiểu bên kia trước
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tồn đọng của bạn có tính năng nào được thêm chỉ vì ai đó đòi không | | | Bạn có biết tài liệu bắt buộc của mình phục vụ ai không | | | Bạn có đang giải quyết bất đồng hay đang mua sự im lặng | |
Và điều mà một sự thoả hiệp chia đều thường che giấu: rằng chưa ai thật sự hiểu bên kia cần gì — người ta chỉ vừa đồng ý thôi tranh luận.
- A Tell the product owner to remove the stories since the development team has not signed off on them.
- B Contact the user who submitted the stories and tell them to stop giving her team more work.
- C Assign the stories to the project team.
- D Review the new stories with the product owner to determine if they add value to the project.
Xem giải thích
Đáp án
D — RÀ SOÁT CÁC CÂU CHUYỆN MỚI CÙNG CHỦ SẢN PHẨM ĐỂ XÁC ĐỊNH CHÚNG CÓ THÊM GIÁ TRỊ CHO DỰ ÁN KHÔNG.
Vì sao đúng
⚠ Vì sao đây là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Nguồn gốc một yêu cầu KHÔNG quyết định thứ tự ưu tiên | ⚠ giá trị mới quyết định | | ⚠ Người dùng cuối là nguồn phản hồi quý | ⚠ nên không được gạt bỏ | | ⚠ Nhưng "từ người dùng" không đồng nghĩa "quan trọng nhất" | | | ⚠ Chủ sản phẩm là người sở hữu thứ tự tồn đọng | ⚠ scrum master không được tự quyết | | ⚠ Rà soát là hành động HỢP TÁC, đúng vai của scrum master | | | ⚠ Kết luận | ⚠ không gạt đi, không nhận ngay — đánh giá theo giá trị, cùng đúng người |
⚠ Chi tiết đáng chú ý: ⚠ đề gọi người đối thoại là "product manager" nhưng vai trò trong scrum là "product owner" ⚠ — ⚠ dù tên gọi thế nào, người sở hữu tồn đọng vẫn là người quyết thứ tự, còn Lisa hỗ trợ họ ra quyết định tốt.
Vì sao các phương án khác sai
-
C (giao luôn các câu chuyện đó cho đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có vẻ tuân theo đúng chỉ đạo của người quản lý sản phẩm, mà làm theo ý chủ sản phẩm nghe như việc đúng của một scrum master: ⚠ nhưng ⚠ nó sai ở HAI tầng cùng lúc ⚠ — ⚠ thứ nhất, scrum master không GIAO việc cho đội, đội tự nhận việc từ tồn đọng đã được xếp thứ tự; thứ hai, các câu chuyện này chưa được ước lượng, chưa được làm rõ và chưa được so với những việc đang chờ trong tồn đọng; ⚠ chèn việc chưa qua đánh giá vào một chặng đang chạy là cách nhanh nhất phá vỡ cam kết của chặng đó.
-
A (bảo chủ sản phẩm gỡ bỏ vì đội chưa duyệt) — ⚠ đội KHÔNG duyệt nội dung tồn đọng; ⚠ đội ước lượng và cam kết khối lượng, còn nội dung là quyền của chủ sản phẩm.
-
B (liên hệ người dùng bảo họ đừng gửi thêm việc) — ⚠ chặn đứng kênh phản hồi quý nhất; ⚠ đây là hành động tệ nhất trong bốn phương án.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26969 cùng lô (đề nghị chủ sản phẩm làm rõ thứ tự ưu tiên), ⚠ #26951 cùng lô (vai trò chủ sản phẩm), ⚠ #26975 cùng lô (bổ sung việc thiếu vào tồn đọng), ⚠ #26825 lô 201 (tồn đọng phải được xếp lại khi có yêu cầu mới).
⚠ Đánh giá một câu chuyện mới theo tiêu chí gì: | Tiêu chí | Câu hỏi | |---|---| | ⚠ GIÁ TRỊ nghiệp vụ | ⚠ nó giải quyết vấn đề gì, cho bao nhiêu người | | ⚠ Phù hợp mục tiêu sản phẩm | ⚠ có nằm trong tầm nhìn không | | ⚠ Kích thước và độ phức tạp | ⚠ cần ước lượng trước khi xếp | | ⚠ Sự phụ thuộc | ⚠ có cần thứ gì chưa làm không | | ⚠ So với các việc đang chờ | ⚠ quan trọng nhất — mọi thứ đều tương đối | | ⚠ Nguyên tắc | ⚠ thêm một việc vào đầu hàng nghĩa là đẩy một việc khác xuống — nên câu hỏi đúng không phải "cái này có đáng làm không" mà là "cái này có đáng làm TRƯỚC cái kia không" |
⚠ Vì sao "từ người dùng cuối" không tự động là ưu tiên cao: | Lý do | Nội dung | |---|---| | ⚠ Người dùng mô tả GIẢI PHÁP họ nghĩ ra | ⚠ chứ không phải vấn đề gốc | | ⚠ Một người dùng không đại diện cho tất cả | | | ⚠ Có thể trùng với thứ đã có trong tồn đọng | | | ⚠ Có thể mâu thuẫn với hướng đi của sản phẩm | | | ⚠ Cách khai thác đúng | ⚠ hỏi ngược lại xem người dùng đang gặp VẤN ĐỀ gì — rất thường xuyên, có một cách giải quyết rẻ hơn và tốt hơn cái họ đề nghị, và chỉ tìm ra được nó khi hỏi tới nơi |
⚠ Ranh giới vai trò mà Lisa phải giữ: | Việc của scrum master | Việc KHÔNG phải của scrum master | |---|---| | ⚠ Tạo điều kiện cho buổi tinh chỉnh tồn đọng | ⚠ quyết định thứ tự ưu tiên | | ⚠ Bảo vệ chặng đang chạy khỏi việc chèn ngang | ⚠ từ chối yêu cầu thay cho chủ sản phẩm | | ⚠ Nhắc nguyên tắc và quy trình | ⚠ giao việc cho đội | | ⚠ Giúp chủ sản phẩm có đủ thông tin để quyết | ⚠ thay chủ sản phẩm nói chuyện với người dùng | | ⚠ Nhận xét | ⚠ áp lực "làm ngay đi" luôn có, và giá trị lớn nhất của scrum master trong khoảnh khắc đó là chậm lại nửa nhịp để câu hỏi về giá trị được đặt ra — chứ không phải để nói không |
Từ khoá nhận diện:
"câu chuyện từ người dùng, đòi làm ngay" → ⚠ RÀ SOÁT CÙNG CHỦ SẢN PHẨM theo giá trị "giao luôn cho đội" → ⚠ sai vai trò và bỏ qua đánh giá "gỡ bỏ vì đội chưa duyệt" → ⚠ đội không duyệt nội dung tồn đọng "bảo người dùng đừng gửi nữa" → ⚠ chặn kênh phản hồi quý nhất
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai trong dự án của bạn thực sự quyết thứ tự tồn đọng | | | Việc mới có được so với việc đang chờ không | | | Bạn có hỏi vấn đề gốc khi nhận một đề nghị tính năng không | |
Và câu hỏi mà mọi yêu cầu mới nên gặp trước khi được nhận vào: không phải "ai đề nghị việc này", mà "việc này thay thế cho việc nào đang chờ".
- A Project budget
- B Project's scope statement
- C Procurement guidelines
- D List of available resources
Xem giải thích
Đáp án
B — BẢN TUYÊN BỐ PHẠM VI DỰ ÁN (project scope statement).
Vì sao đúng
⚠ Vì sao phạm vi là thông tin hữu ích nhất để lập đội: | Lý do | Nội dung | |---|---| | ⚠ Phạm vi cho biết phải LÀM những gì | ⚠ từ đó suy ra cần kỹ năng gì | | ⚠ Biết cần kỹ năng gì mới biết cần AI | ⚠ thứ tự suy luận bắt buộc | | ⚠ Cho biết quy mô công việc | ⚠ từ đó suy ra cần bao nhiêu người | | ⚠ Có cả những gì KHÔNG thuộc phạm vi | ⚠ tránh tuyển thừa kỹ năng không dùng tới | | ⚠ Kết luận | ⚠ mọi quyết định về nguồn lực đều bắt nguồn từ phạm vi — đó là điểm khởi đầu duy nhất hợp lý |
⚠ Chỉ dẫn "ưu tiên nhân sự cơ hữu trước, sau đó mới bàn tới thuê ngoài" cũng cần phạm vi: ⚠ phải biết cần những kỹ năng nào thì mới đối chiếu được với người sẵn có, rồi mới biết còn thiếu gì để đi thuê ⚠.
Vì sao các phương án khác sai
-
D (danh sách nguồn lực sẵn có) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chỉ dẫn của ban chỉ đạo nói rất rõ là dùng nhân viên cơ hữu trước, nên danh sách người sẵn có nghe như đúng thứ Paul cần cầm trên tay: ⚠ nhưng ⚠ danh sách đó chỉ trả lời được "có ai" chứ không trả lời được "cần ai" ⚠ — ⚠ cầm một danh sách nhân sự mà không biết dự án cần kỹ năng gì thì không chọn được người nào; ⚠ thứ tự đúng luôn là: PHẠM VI trước, rồi mới đối chiếu với nguồn lực sẵn có ⚠; ⚠ đây là dạng bẫy phổ biến — chọn phương án gần nhất với chi tiết cuối cùng trong đề thay vì phương án trả lời đúng câu hỏi.
-
A (ngân sách dự án) — ⚠ giới hạn được số người thuê ngoài; ⚠ nhưng không cho biết cần kỹ năng gì, và đề còn nói dự án mới ở giai đoạn lập kế hoạch.
-
C (hướng dẫn mua sắm) — ⚠ chỉ liên quan tới phần thuê ngoài; ⚠ mà phần đó ban chỉ đạo đã nói là bàn sau.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26910 lô 203 (WBS và bản tuyên bố phạm vi), ⚠ #26912 lô 203 (từ WBS tới tiến độ), ⚠ #26978 cùng lô (thương lượng nguồn lực dùng chung), ⚠ #26946 cùng lô (ranh giới phạm vi).
⚠ Bản tuyên bố phạm vi có gì: | Thành phần | Nội dung | |---|---| | ⚠ Mô tả phạm vi sản phẩm | ⚠ sản phẩm là gì | | ⚠ Danh sách sản phẩm bàn giao | ⚠ nguồn để suy ra kỹ năng cần | | ⚠ Tiêu chí chấp nhận | | | ⚠ LOẠI TRỪ khỏi phạm vi | ⚠ mục hay bị bỏ quên mà rất giá trị | | ⚠ Ràng buộc và giả định | ⚠ "ưu tiên nhân sự cơ hữu" chính là một ràng buộc | | ⚠ Vì sao mục loại trừ quan trọng | ⚠ nó ngăn việc tuyển hoặc giữ những kỹ năng mà dự án sẽ không dùng tới — và cũng ngăn tranh chấp lúc nghiệm thu; liên hệ #26946 cùng lô |
⚠ Trình tự lập đội dự án: | Bước | Nội dung | |---|---| | ⚠ 1. Đọc PHẠM VI, xác định sản phẩm bàn giao | ⚠ bước Paul đang cần — ĐÁP ÁN | | ⚠ 2. Suy ra các kỹ năng và vai trò cần thiết | | | ⚠ 3. Đối chiếu với danh sách nguồn lực sẵn có | ⚠ theo chỉ đạo: nhân sự cơ hữu trước | | ⚠ 4. Xác định khoảng trống kỹ năng còn lại | | | ⚠ 5. Bàn phương án thuê ngoài cho phần thiếu | ⚠ lúc này mới cần hướng dẫn mua sắm | | ⚠ Điểm dễ làm sai | ⚠ bắt đầu từ danh sách người rảnh rồi ghép việc cho họ — cách này cho ra một đội đầy đủ về số lượng nhưng thiếu đúng những kỹ năng khó nhất, và điều đó chỉ lộ ra ở giai đoạn thực hiện |
⚠ Vì sao ưu tiên nhân sự cơ hữu là chỉ đạo hợp lý: | Lý do | Nội dung | |---|---| | ⚠ Đã hiểu tổ chức, quy trình và hệ thống | ⚠ không mất thời gian hoà nhập | | ⚠ Chi phí thường thấp hơn thuê ngoài | | | ⚠ Tri thức Ở LẠI với tổ chức | ⚠ liên hệ #26948 cùng lô | | ⚠ Không phát sinh rủi ro và công việc hợp đồng | | | ⚠ Đánh đổi phải cân nhắc | ⚠ người cơ hữu thường đã bận với việc khác, nên "sẵn có" trên giấy chưa chắc là sẵn có thật — đó là lý do bước ba của trình tự trên phải bao gồm cả việc thương lượng thời gian, xem #26978 cùng lô |
Từ khoá nhận diện:
"cần lập đội cho dự án" → ⚠ bắt đầu từ BẢN TUYÊN BỐ PHẠM VI "danh sách nguồn lực sẵn có" → ⚠ trả lời "có ai", không trả lời "cần ai" "ngân sách" → ⚠ giới hạn số lượng, không cho biết kỹ năng "hướng dẫn mua sắm" → ⚠ chỉ cần khi đã xác định phần phải thuê ngoài
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn liệt kê được các kỹ năng dự án cần từ phạm vi không | | | Đội hiện tại của bạn được lập từ nhu cầu hay từ người rảnh | | | Bản phạm vi của bạn có mục loại trừ không | |
Và lý do mọi câu hỏi về nguồn lực đều quay về phạm vi: vì "cần ai" chỉ là một cách hỏi khác của "phải làm gì" — và không ai trả lời được câu đầu khi chưa trả lời xong câu sau.