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

Đáp án

D — BÊN LIÊN QUAN KHÁNG CỰ (resistant).

Vì sao đúng

⚠ Vì sao Paul nhiều khả năng kháng cự: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ Mười năm làm kỹ thuật viên máy chủ VẬT LÝ | ⚠ chuyên môn gắn với công nghệ sắp bị thay thế | | ⚠ KHÔNG nắm được các tiến bộ về lưu trữ đám mây | ⚠ thiếu hiểu biết sinh ra bất an | | ⚠ Dự án chuyển từ máy chủ tại chỗ sang đám mây | ⚠ chạm trực tiếp tới công việc của anh ấy | | ⚠ Đây là dự án ĐẦU TIÊN của tổ chức làm việc này | ⚠ không có tiền lệ để yên tâm | | ⚠ Kết luận | ⚠ mối lo nghề nghiệp cộng với thiếu hiểu biết là công thức kinh điển của sự kháng cự |

⚠ Quan trọng: ⚠ kháng cự KHÔNG có nghĩa Paul là người xấu hay bảo thủ vô cớ ⚠ — ⚠ mối lo của anh ấy hoàn toàn chính đáng, và việc Lina lường trước được điều đó là dấu hiệu của một người quản lý dự án tốt.

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

• B (trung lập — neutral) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ Paul chưa hề nói hay làm gì phản đối cả — anh ấy chỉ đơn giản là không biết về đám mây, và "không biết" nghe gần với "chưa có ý kiến": ⚠ nhưng ⚠ câu hỏi hỏi Lina nên DỰ ĐOÁN Paul sẽ là loại bên liên quan nào, tức là dự báo chứ không mô tả hiện tại ⚠; ⚠ và hai yếu tố trong đề — chuyên môn bị đe doạ cộng với thiếu hiểu biết về công nghệ mới — đều đẩy về phía kháng cự chứ không về phía trung lập; ⚠ trung lập là trạng thái của người mà dự án không ảnh hưởng tới, còn Paul thì bị ảnh hưởng trực tiếp.

• A (ủng hộ — advocate) — ⚠ không có dữ kiện nào ủng hộ; ⚠ và người có chuyên môn bị thay thế hiếm khi trở thành người vận động cho sự thay thế đó.

• C (cơ hội — opportunistic) — ⚠ không phải một mức thái độ chuẩn trong phân loại bên liên quan của PMI.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26913 lô 203 (bên liên quan phản đối vẫn là bên liên quan), ⚠ #27105 lô 207 (nhà cung cấp bị đe doạ mất doanh thu), ⚠ #26957 lô 204 (nhận diện bên liên quan suốt vòng đời), ⚠ #27078 lô 206 (các ô trên ma trận).

⚠ NĂM MỨC THÁI ĐỘ của bên liên quan: | Mức | Nội dung | |---|---| | ⚠ KHÔNG BIẾT (unaware) | ⚠ chưa biết dự án tồn tại | | ⚠ KHÁNG CỰ (resistant) | ⚠ biết và phản đối — ĐÁP ÁN | | ⚠ TRUNG LẬP (neutral) | ⚠ biết nhưng không ủng hộ cũng không phản đối | | ⚠ ỦNG HỘ (supportive) | ⚠ biết và mong dự án thành công | | ⚠ DẪN DẮT (leading) | ⚠ chủ động thúc đẩy dự án thành công | | ⚠ Công cụ đi kèm | ⚠ ma trận mức tham gia HIỆN TẠI so với MONG MUỐN — nó giả định rằng thái độ CÓ THỂ thay đổi, và đó chính là lý do việc nhận diện Paul là người kháng cự lại là một tin tốt: có tên trong ma trận thì mới có chiến lược cho anh ấy |

⚠ Lina nên làm gì với Paul: | Việc | Nội dung | |---|---| | ⚠ Gặp riêng, hỏi mối lo thật của anh ấy | ⚠ có thể là lo mất việc chứ không phải lo kỹ thuật | | ⚠ Đào tạo về công nghệ đám mây | ⚠ giảm bất an do thiếu hiểu biết — #26945 lô 204 | | ⚠ Mời anh ấy tham gia vào thiết kế giải pháp | ⚠ biến người phản đối thành người đóng góp | | ⚠ Tận dụng kinh nghiệm mười năm của anh ấy | ⚠ hiểu biết về hạ tầng hiện tại rất quý | | ⚠ Cách hiệu quả nhất | ⚠ cho Paul một VAI TRÒ trong dự án mới — người hiểu rõ hệ thống cũ nhất chính là người biết những gì không được làm hỏng khi chuyển đổi, và không ai thay thế được kiến thức đó |

⚠ Vì sao kháng cự do nghề nghiệp bị đe doạ lại khó xử lý: | Lý do | Nội dung | |---|---| | ⚠ Mối lo là THẬT, không phải hiểu nhầm | ⚠ không thuyết phục bằng lý lẽ được | | ⚠ Người ta hiếm khi nói thẳng lý do thật | ⚠ họ sẽ nêu các phản đối kỹ thuật thay vào đó | | ⚠ Càng giải thích lợi ích thì càng khẳng định nỗi lo | | | ⚠ Cách duy nhất hiệu quả | ⚠ trả lời câu hỏi họ chưa dám hỏi: "vị trí của tôi sẽ thế nào" — và nếu người quản lý dự án không có thẩm quyền trả lời thì phải tìm người có thẩm quyền, chứ không thể lảng tránh mãi |

Từ khoá nhận diện:

"chuyên môn gắn với công nghệ cũ + không biết công nghệ mới" → ⚠ KHÁNG CỰ "trung lập" → ⚠ dành cho người không bị ảnh hưởng "ủng hộ" → ⚠ không có dữ kiện nào ủng hộ "cơ hội" → ⚠ không phải mức thái độ chuẩn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có đe doạ chuyên môn của ai không | | | Bạn đã hỏi mối lo thật của họ chưa | | | Người phản đối của bạn có vai trò gì trong giải pháp mới không | |

Và điều mà một người mười năm gắn bó với công nghệ sắp bị thay thế thật sự đang hỏi: không phải "công nghệ mới có tốt không", mà "tôi còn chỗ nào trong tương lai này" — và cho tới khi câu đó được trả lời, mọi lập luận kỹ thuật đều không có tác dụng.

Đáp án

A — BỎ PHIẾU NẮM TAY NĂM NGÓN (fist-of-five voting).

Vì sao đúng

⚠ Vì sao kỹ thuật này khớp cả hai yêu cầu: | Yêu cầu | Nắm tay năm ngón đáp ứng thế nào | |---|---| | ⚠ Quyết định NHANH | ⚠ giơ tay một lượt, vài giây là xong | | ⚠ Thể hiện được MỨC ĐỘ ủng hộ khác nhau | ⚠ từ 1 tới 5 ngón — đặc điểm quyết định | | ⚠ Lawrence nêu rõ ý nghĩa từng mức trước khi bỏ phiếu | ⚠ đúng cách vận hành của kỹ thuật này | | ⚠ Kết luận | ⚠ đây là kỹ thuật duy nhất vừa nhanh vừa đo được mức độ, không chỉ đo chiều |

⚠ Ý nghĩa các mức: ⚠ 1 ngón là phản đối mạnh, 3 ngón là "tôi chấp nhận được", 5 ngón là ủng hộ hết mình ⚠ — ⚠ ai giơ dưới 3 ngón sẽ được mời giải thích, và đó chính là phần giá trị nhất của kỹ thuật.

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

• D (giơ ngón cái lên / ngang / xuống) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng nhanh và cũng có BA mức thay vì hai, nên nghe như đã đáp ứng yêu cầu "thể hiện mức độ khác nhau": ⚠ nhưng ⚠ ba mức chỉ phân biệt được đồng ý, trung lập và phản đối — nó không đo được ĐỘ MẠNH của sự ủng hộ ⚠; ⚠ một người ủng hộ dè dặt và một người ủng hộ nhiệt tình đều giơ ngón cái lên, và Lawrence sẽ không biết đội thật sự đứng ở đâu; ⚠ năm mức cho đủ độ phân giải để phát hiện sự đồng thuận yếu — thứ mà ba mức bỏ sót hoàn toàn.

• B (bỏ phiếu đơn giản) — ⚠ chỉ có hai lựa chọn đồng ý hoặc không; ⚠ hoàn toàn không thể hiện được mức độ.

• C (Phổ quyết định của Highsmith) — ⚠ là một công cụ có thật nhưng chi tiết hơn và CHẬM hơn; ⚠ nó không phù hợp với yêu cầu quyết định nhanh trong đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26986 lô 205 (bỏ thảo luận thì mất phương án tốt hơn), ⚠ #27088 lô 207 (hội tụ và cộng tác chung), ⚠ #27118 lô 207 (đồng thuận là lợi ích chính), ⚠ #26950 lô 204 (cả đội cùng giải quyết vấn đề).

⚠ Thang năm ngón, ý nghĩa từng mức: | Số ngón | Nghĩa | |---|---| | ⚠ 5 ngón | ⚠ hoàn toàn ủng hộ, sẵn sàng dẫn dắt việc thực hiện | | ⚠ 4 ngón | ⚠ đồng ý, thấy đây là lựa chọn tốt | | ⚠ 3 ngón | ⚠ chấp nhận được, sẽ ủng hộ dù không phải lựa chọn của mình | | ⚠ 2 ngón | ⚠ có mối lo, cần bàn thêm | | ⚠ 1 ngón | ⚠ phản đối mạnh, cần được nghe trước khi chốt | | ⚠ Quy tắc vận hành | ⚠ nếu ai cũng từ 3 ngón trở lên thì chốt; nếu có người dưới 3 thì nghe họ nói rồi bỏ phiếu lại — cách này giữ được tốc độ mà không bỏ mất tiếng nói của thiểu số |

⚠ Vì sao đo MỨC ĐỘ quan trọng hơn đo CHIỀU: | Vấn đề của bỏ phiếu hai chiều | Nội dung | |---|---| | ⚠ Không phân biệt được đồng ý nhiệt tình với đồng ý miễn cưỡng | | | ⚠ Một quyết định "8 thuận 2 chống" trông rất mạnh | ⚠ nhưng có thể 8 người đó chỉ ở mức 3 ngón | | ⚠ Không tạo cơ hội cho người có mối lo lên tiếng | | | ⚠ Giá trị thật của kỹ thuật này | ⚠ nó biến một cuộc bỏ phiếu thành một cuộc trò chuyện — bàn tay giơ lên chỉ là cái cớ để hỏi "vì sao anh chị chỉ giơ hai ngón", và câu trả lời đó thường là thứ quan trọng nhất trong cả buổi |

⚠ Vì sao Lawrence nêu rõ ý nghĩa từng lựa chọn trước: | Lý do | Nội dung | |---|---| | ⚠ Mọi người hiểu giống nhau về thang đo | ⚠ không thì 3 ngón mỗi người một nghĩa | | ⚠ Tránh bỏ phiếu theo cảm tính | | | ⚠ Bảo đảm ai cũng hiểu mình đang chọn gì | | | ⚠ Bước bị bỏ qua nhiều nhất | ⚠ chính bước này — nhiều đội dùng nắm tay năm ngón mà chưa bao giờ thống nhất ý nghĩa từng mức, và kết quả là một con số trung bình vô nghĩa |

Từ khoá nhận diện:

"nhanh + thể hiện được MỨC ĐỘ ủng hộ" → ⚠ NẮM TAY NĂM NGÓN "ngón cái lên/ngang/xuống" → ⚠ ba mức, không đo được độ mạnh "bỏ phiếu đơn giản" → ⚠ hai lựa chọn, không có mức độ "Phổ quyết định Highsmith" → ⚠ chi tiết hơn nhưng chậm hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có phân biệt được đồng ý nhiệt tình với đồng ý miễn cưỡng không | | | Bạn có hỏi lý do khi ai đó ủng hộ yếu không | | | Các mức trên thang bỏ phiếu của bạn có được định nghĩa rõ không | |

Và điều mà một cuộc bỏ phiếu năm mức cho thấy còn cuộc bỏ phiếu hai mức thì che mất: sự khác nhau giữa một đội đồng ý và một đội chỉ thôi phản đối.

Đáp án

C — LẬP MA TRẬN QUYẾT ĐỊNH (decision matrix).

Vì sao đúng

⚠ Ma trận quyết định là công cụ nền của phân tích đa tiêu chí: | Thành phần | Nội dung | |---|---| | ⚠ Các PHƯƠNG ÁN xếp theo hàng | ⚠ ở đây là các yêu cầu thay đổi | | ⚠ Các TIÊU CHÍ xếp theo cột | ⚠ chi phí, rủi ro, giá trị, mức phức tạp | | ⚠ Mỗi tiêu chí có TRỌNG SỐ | ⚠ tiêu chí quan trọng hơn thì nặng hơn | | ⚠ Chấm điểm từng ô rồi nhân trọng số | | | ⚠ Tổng điểm cho ra thứ tự khách quan | | | ⚠ Kết luận | ⚠ muốn phân tích đa tiêu chí thì trước hết phải có bảng chứa các tiêu chí đó |

⚠ Vì sao Abraham cần nó: ⚠ dự án phức tạp, nhiều bên liên quan đa dạng, đội liên chức năng trong ma trận ⚠ — ⚠ nghĩa là mỗi yêu cầu thay đổi sẽ có nhiều người đánh giá theo nhiều tiêu chí khác nhau, và một bảng chung giúp cuộc tranh luận có căn cứ.

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

• A (lập cây quyết định) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cây quyết định cũng là công cụ RA QUYẾT ĐỊNH và tên gọi có chữ "quyết định" — liên hệ #27038 lô 206: ⚠ nhưng ⚠ cây quyết định dùng cho các lựa chọn có XÁC SUẤT và giá trị tiền tệ, tính EMV để chọn nhánh tốt nhất ⚠; ⚠ ở đây Abraham đánh giá các yêu cầu thay đổi theo NHIỀU TIÊU CHÍ khác nhau, không phải theo xác suất của các kịch bản; ⚠ mẹo phân biệt: cây quyết định trả lời "chọn nhánh nào khi có may rủi", ma trận trả lời "xếp hạng các phương án theo nhiều tiêu chí".

• B (biểu đồ xương cá) — ⚠ công cụ tìm NGUYÊN NHÂN của một vấn đề; ⚠ liên hệ #27110 lô 207.

• D (biểu đồ kiểm soát) — ⚠ công cụ CHẤT LƯỢNG, theo dõi quy trình có ổn định không; ⚠ liên hệ #27011 lô 205.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27038 lô 206 (cây quyết định cho bài toán tự làm hay mua), ⚠ #26944 lô 204 (phân tích quyết định đa tiêu chí trong thu thập yêu cầu), ⚠ #27061 lô 206 (kiểm soát thay đổi tích hợp), ⚠ #27110 lô 207 (các công cụ tìm nguyên nhân gốc).

⚠ Các bước dùng phân tích đa tiêu chí: | Bước | Nội dung | |---|---| | ⚠ 1. LẬP MA TRẬN với phương án và tiêu chí | ⚠ ĐÁP ÁN — bước nền | | ⚠ 2. Thống nhất TRỌNG SỐ cho từng tiêu chí | ⚠ bước dễ gây tranh cãi nhất | | ⚠ 3. Chấm điểm từng phương án theo từng tiêu chí | | | ⚠ 4. Nhân điểm với trọng số rồi cộng lại | | | ⚠ 5. Xếp hạng và ra quyết định | | | ⚠ Giá trị lớn nhất của phương pháp | ⚠ nó buộc mọi người thống nhất TIÊU CHÍ trước khi bàn tới các phương án cụ thể — và khi tiêu chí đã được thống nhất thì phần lớn tranh cãi tự biến mất |

⚠ Tiêu chí thường dùng để đánh giá yêu cầu thay đổi: | Tiêu chí | Nội dung | |---|---| | ⚠ Giá trị kinh doanh mang lại | | | ⚠ Chi phí thực hiện | | | ⚠ Tác động lên tiến độ | | | ⚠ Mức rủi ro phát sinh | | | ⚠ Mức phức tạp kỹ thuật và tích hợp | ⚠ quan trọng với dự án của Abraham | | ⚠ Tính bắt buộc về pháp lý hoặc tuân thủ | ⚠ thường có trọng số cao nhất | | ⚠ Lời khuyên thực dụng | ⚠ giữ số tiêu chí ở mức bốn tới sáu — nhiều hơn thì việc chấm điểm trở nên mệt mỏi và người ta bắt đầu điền cho xong, lúc đó ma trận mất hết giá trị |

⚠ Cạm bẫy khi dùng ma trận quyết định: | Bẫy | Nội dung | |---|---| | ⚠ Điều chỉnh trọng số để ra kết quả mong muốn | ⚠ phổ biến hơn người ta tưởng | | ⚠ Con số tạo cảm giác khách quan giả | ⚠ điểm số vẫn là đánh giá chủ quan | | ⚠ Bỏ qua các yếu tố khó chấm điểm | ⚠ chúng biến mất khỏi quyết định | | ⚠ Cách giảm thiểu | ⚠ thống nhất trọng số TRƯỚC khi nhìn vào các phương án cụ thể — đặt trọng số sau khi đã biết mình muốn chọn gì là cách hợp thức hoá một quyết định đã có sẵn |

Từ khoá nhận diện:

"phân tích quyết định đa tiêu chí, bước đầu tiên" → ⚠ MA TRẬN QUYẾT ĐỊNH "cây quyết định" → ⚠ cho lựa chọn có xác suất và giá trị tiền "biểu đồ xương cá" → ⚠ tìm nguyên nhân của vấn đề "biểu đồ kiểm soát" → ⚠ công cụ chất lượng, theo dõi quy trình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tiêu chí cố định để đánh giá yêu cầu thay đổi không | | | Trọng số được thống nhất trước hay sau khi xem các phương án | | | Có yếu tố quan trọng nào không chấm điểm được mà bị bỏ qua không | |

Và điều mà một ma trận quyết định mang lại nhiều hơn cả một thứ hạng: một cuộc tranh luận về TIÊU CHÍ thay vì về SỞ THÍCH — và cuộc tranh luận đó chỉ cần diễn ra một lần cho tất cả các quyết định về sau.

Đáp án

B — TỔ CHỨC MỘT VÀI BUỔI GẶP TRỰC TIẾP BAN ĐẦU ĐỂ MỌI NGƯỜI GẶP VÀ LÀM QUEN NHAU.

Vì sao đúng

⚠ Vì sao gặp mặt ban đầu lại hiệu quả: | Lý do | Nội dung | |---|---| | ⚠ Agile ưu tiên giao tiếp trực tiếp | ⚠ đề nêu rõ nguyên tắc này | | ⚠ Đội phân tán không thể gặp thường xuyên | ⚠ nên phải dùng cơ hội đầu tiên cho hiệu quả | | ⚠ Gặp mặt một lần tạo nền cho mọi trao đổi từ xa về sau | ⚠ điểm mấu chốt | | ⚠ Xây được lòng tin và quan hệ cá nhân | | | ⚠ Kết luận | ⚠ đầu tư một lần vào việc gặp mặt để mọi cuộc gọi video sau đó hiệu quả hơn |

⚠ Hiện tượng đã được quan sát nhiều lần: ⚠ các đội phân tán từng gặp nhau trực tiếp trao đổi từ xa tốt hơn hẳn các đội chưa bao giờ gặp ⚠ — ⚠ vì khi đã biết mặt và biết tính nhau, người ta diễn giải tin nhắn theo hướng thiện chí hơn nhiều.

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

• D (quy định giờ làm việc chung để mọi người trao đổi tốt hơn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ giờ trùng nhau đúng là điều kiện cần cho một đội phân tán, và nhiều đội thật sự phải làm điều này: ⚠ nhưng ⚠ nó giải quyết vấn đề THỜI GIAN chứ không giải quyết vấn đề mà đề nêu ra, là thiếu giao tiếp TRỰC TIẾP ⚠; ⚠ hai người ở hai múi giờ có giờ trùng nhau vẫn có thể trao đổi rất kém nếu chưa bao giờ gặp nhau; ⚠ và với các đội cách nhau nhiều múi giờ, việc ép giờ chung còn tạo ra sự bất công vì luôn có người phải làm ngoài giờ; ⚠ liên hệ #27057 lô 206 và #27113 lô 207 về các vấn đề của đội ảo.

• A (dùng chung một ngôn ngữ cho mọi trao đổi) — ⚠ là quy ước cần thiết nhưng không phải điều đề đang hỏi; ⚠ và liên hệ #27094 lô 207: chỉ quy định ngôn ngữ chung không giải quyết được rào cản trình độ.

• C (yêu cầu mọi người chia sẻ ảnh của mình) — ⚠ là một biện pháp nhỏ, hời hợt; ⚠ nó không tạo ra được quan hệ thật.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26921 lô 203 (agile ưu tiên mặt đối mặt), ⚠ #27057 lô 206 (gắn kết cho đội từ xa), ⚠ #27113 lô 207 (đo mức tương tác của đội ảo), ⚠ #26900 lô 203 (khi nào đội ảo là cần thiết).

⚠ Vì sao một lần gặp mặt lại tạo khác biệt lớn: | Cơ chế | Nội dung | |---|---| | ⚠ Có khuôn mặt và giọng nói gắn với cái tên | ⚠ tin nhắn được đọc bằng giọng của người đó | | ⚠ Biết tính cách và cách làm việc của nhau | | | ⚠ Có kỷ niệm chung để tham chiếu | | | ⚠ Dễ nhấc máy gọi hơn khi đã quen | ⚠ rào cản tâm lý giảm hẳn | | ⚠ Hiệu ứng quan trọng nhất | ⚠ một tin nhắn cụt lủn từ người lạ dễ bị hiểu là lạnh lùng, còn cũng tin nhắn đó từ người đã cùng ăn trưa thì được hiểu là đang bận — cùng một văn bản, hai cách diễn giải, và khác biệt nằm ở việc đã từng gặp nhau hay chưa |

⚠ Buổi gặp mặt ban đầu nên làm gì: | Hoạt động | Nội dung | |---|---| | ⚠ Giới thiệu từng người và vai trò | | | ⚠ Cùng xây quy tắc ứng xử của đội | ⚠ liên hệ #27072 lô 206 | | ⚠ Thoả thuận cách trao đổi từ xa | ⚠ kênh nào cho việc gì, thời gian phản hồi | | ⚠ Lập kế hoạch cho vài chặng đầu | | | ⚠ Dành thời gian cho hoạt động phi công việc | ⚠ phần tạo ra quan hệ thật | | ⚠ Điều nên tránh | ⚠ nhồi kín lịch bằng các phiên làm việc — phần giá trị nhất của một chuyến gặp mặt thường nằm ở bữa ăn tối và các cuộc trò chuyện ngoài lề, chứ không nằm ở các buổi họp có chương trình |

⚠ Các biện pháp bổ sung sau khi đã gặp mặt: | Biện pháp | Nội dung | |---|---| | ⚠ Bật camera trong các cuộc họp | ⚠ giữ lại tín hiệu hình ảnh | | ⚠ Buổi gặp ảo không bàn công việc | ⚠ liên hệ #27057 lô 206 | | ⚠ Xác định giờ trùng nhau tối thiểu | ⚠ phương án D, vẫn hữu ích như biện pháp bổ sung | | ⚠ Bảng công việc trực tuyến ai cũng thấy | ⚠ liên hệ #27003 lô 205 | | ⚠ Nhận xét | ⚠ ba phương án nhiễu trong câu này đều là việc NÊN LÀM — chúng chỉ không phải câu trả lời TỐT NHẤT cho vấn đề mà đề nêu ra, và đó là dạng câu hỏi khó nhất vì không có phương án nào sai hẳn |

Từ khoá nhận diện:

"đội phân tán mà agile cần mặt đối mặt" → ⚠ GẶP TRỰC TIẾP ban đầu "quy định giờ làm chung" → ⚠ giải quyết vấn đề thời gian, không phải vấn đề quan hệ "dùng chung ngôn ngữ" → ⚠ quy ước cần thiết nhưng không đủ "chia sẻ ảnh" → ⚠ biện pháp hời hợt, không tạo quan hệ thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội phân tán của bạn đã từng gặp nhau chưa | | | Có ai trong đội chưa bao giờ nhìn thấy mặt đồng nghiệp không | | | Ngân sách dự án của bạn có khoản cho một chuyến gặp mặt không | |

Và lý do một chuyến đi tốn kém ở đầu dự án thường là khoản đầu tư rẻ nhất cho một đội phân tán: vì mọi cuộc trao đổi trong suốt phần còn lại của dự án đều diễn ra trên nền của việc người ta có biết nhau hay không.

Đáp án

C — MỌI THAY ĐỔI PHẢI ĐƯỢC XEM XÉT QUA MỘT QUY TRÌNH KIỂM SOÁT THAY ĐỔI.

Vì sao đúng

⚠ Vì sao đây là câu trả lời cân bằng nhất: | Yếu tố | Nội dung | |---|---| | ⚠ Thừa nhận thay đổi LÀ chuyện bình thường | ⚠ không hứa rằng sẽ không có thay đổi | | ⚠ Nhưng có CƠ CHẾ kiểm soát chúng | ⚠ trấn an mối lo của bên liên quan | | ⚠ Mọi đề xuất được đánh giá tác động trước khi quyết | | | ⚠ Bên liên quan biết mình có kênh chính thức để đề xuất | | | ⚠ Kết luận | ⚠ không cấm thay đổi, cũng không để nó tự do — đó chính là ý nghĩa của chữ "kiểm soát" |

⚠ Mối lo của bên liên quan mới là rất phổ biến: ⚠ họ sợ dự án sẽ trôi dạt vô định ⚠ — ⚠ và câu trả lời đúng vừa xác nhận rằng nỗi lo đó chính đáng vừa cho thấy đã có cơ chế xử lý.

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

• A (khi dự án bắt đầu thì phạm vi bị khoá, thay đổi có thể bỏ qua) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như đúng thứ bên liên quan đang muốn nghe: một lời bảo đảm rằng sẽ không có gì thay đổi: ⚠ nhưng ⚠ nó KHÔNG ĐÚNG với bất kỳ dự án thực tế nào — thay đổi luôn xảy ra, và hứa điều ngược lại là hứa thứ không giữ được ⚠; ⚠ và cụm "thay đổi có thể bị bỏ qua" còn nguy hiểm hơn: bỏ qua một thay đổi cần thiết có thể khiến dự án bàn giao thứ không còn ai cần; ⚠ đường cơ sở được CHỐT chứ không bị KHOÁ — nó thay đổi được, chỉ là phải qua phê duyệt; liên hệ #27014 lô 205.

• B (chỉ người quản lý dự án được phê duyệt thay đổi) — ⚠ sai thẩm quyền; ⚠ thay đổi lớn thuộc ban kiểm soát thay đổi, và người quản lý dự án chỉ được duyệt trong hạn mức đã được uỷ quyền.

• D (chỉ ban chỉ đạo được nộp yêu cầu thay đổi) — ⚠ sai; ⚠ bất kỳ bên liên quan nào cũng có thể NỘP yêu cầu thay đổi, chỉ việc PHÊ DUYỆT mới bị giới hạn.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27159 cùng lô (hướng lập trình viên tới quy trình kiểm soát thay đổi), ⚠ #27061 lô 206 (kiểm soát thay đổi tích hợp), ⚠ #26935 lô 204 (đánh giá rồi nộp yêu cầu thay đổi), ⚠ #27014 lô 205 (định nghĩa phạm vi và mục loại trừ).

⚠ Ai làm gì trong quy trình kiểm soát thay đổi: | Vai trò | Quyền hạn | |---|---| | ⚠ BẤT KỲ AI | ⚠ NỘP yêu cầu thay đổi | | ⚠ Người quản lý dự án | ⚠ đánh giá tác động, duyệt trong hạn mức được uỷ quyền | | ⚠ Ban kiểm soát thay đổi (CCB) | ⚠ duyệt các thay đổi lớn | | ⚠ Nhà tài trợ | ⚠ duyệt các thay đổi vượt thẩm quyền CCB | | ⚠ Điều nên nói rõ ngay từ đầu dự án | ⚠ hạn mức uỷ quyền cho người quản lý dự án — nếu không có ngưỡng rõ ràng thì mọi thay đổi nhỏ đều phải chờ hội đồng, và quy trình sẽ bị coi là rào cản rồi bị đi vòng qua |

⚠ Trả lời bên liên quan mới thế nào cho tốt: | Nên nói | Không nên nói | |---|---| | ⚠ "Thay đổi là bình thường, và ta có cơ chế cho nó" | ⚠ "sẽ không có thay đổi nào" | | ⚠ Giải thích các bước của quy trình | ⚠ chỉ nói tên quy trình | | ⚠ Nêu rõ ai được nộp và ai được duyệt | | | ⚠ Nói rõ mất bao lâu để có câu trả lời | ⚠ để họ chờ không biết tới bao giờ | | ⚠ Điểm trấn an hiệu quả nhất | ⚠ cho họ biết rằng chính họ cũng có thể nộp yêu cầu thay đổi — mối lo về việc "phạm vi bị đổi" thường đi kèm mối lo ngầm rằng "tôi sẽ không có tiếng nói", và câu này giải quyết cả hai |

⚠ Vì sao "khoá phạm vi" là lời hứa không giữ được: | Nguyên nhân thay đổi | Nội dung | |---|---| | ⚠ Hiểu biết tăng lên trong quá trình làm | ⚠ không tránh được | | ⚠ Thị trường và bối cảnh kinh doanh đổi | ⚠ liên hệ #27153 cùng lô | | ⚠ Quy định pháp lý mới | ⚠ liên hệ #27158 cùng lô | | ⚠ Sai sót được phát hiện | | | ⚠ Kết luận thực tế | ⚠ một dự án không có thay đổi nào trong sáu tháng thường không phải dự án được lập kế hoạch hoàn hảo, mà là dự án không ai nhìn tới |

Từ khoá nhận diện:

"lo thay đổi phạm vi sau khi bắt đầu" → ⚠ quy trình KIỂM SOÁT THAY ĐỔI "phạm vi bị khoá, bỏ qua thay đổi" → ⚠ hứa thứ không giữ được, và nguy hiểm "chỉ PM được duyệt" → ⚠ sai thẩm quyền, thay đổi lớn thuộc CCB "chỉ ban chỉ đạo được nộp" → ⚠ ai cũng NỘP được, chỉ PHÊ DUYỆT mới giới hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có biết cách nộp yêu cầu thay đổi không | | | Bạn có hạn mức uỷ quyền rõ ràng không | | | Quy trình của bạn mất bao lâu để trả lời một đề xuất | |

Và điều mà một quy trình kiểm soát thay đổi thật sự hứa với bên liên quan, thay cho lời hứa không thể giữ về sự bất biến: rằng mọi thay đổi sẽ được cân nhắc công khai, và không có gì lặng lẽ trôi vào dự án mà họ không biết.

Đáp án

A — KHÔNG LÀM GÌ CẢ. PHẠM VI DỰ ÁN CỦA BẠN ĐÃ HOÀN THÀNH.

⚠ CÂU GẦN TRÙNG: ⚠ #26946 lô 204 mô tả gần như y hệt tình huống này ⚠ — ⚠ ở đó là 8.453 tay nắm cửa cho một khách sạn, ở đây là 10.000 biển báo cho một khu bệnh viện; cả hai đều là khách hàng đã nghiệm thu và ký nhận, rồi người quản lý dự án của đội LẮP ĐẶT hỏi khi nào bạn sang giúp lắp; ⚠ cả hai đều có cùng khoá đáp án về nội dung: không làm gì vì phạm vi đã hoàn thành; ⚠ hash MD5 không bắt được cặp này vì đổi tên sản phẩm và con số — hãy đọc hai bài liền nhau.

Vì sao đúng

⚠ Ba dấu hiệu cho thấy dự án đã đóng: | Dấu hiệu | Nội dung | |---|---| | ⚠ Đội đã hoàn thành toàn bộ 10.000 biển báo | | | ⚠ Khách hàng ĐỒNG Ý phạm vi đã hoàn thành | ⚠ nghiệm thu chính thức | | ⚠ Khách hàng đã KÝ NHẬN sản phẩm bàn giao | ⚠ mốc kết thúc rõ ràng | | ⚠ Việc LẮP ĐẶT thuộc phạm vi của đội khác | ⚠ đề nói rõ ngay từ đầu | | ⚠ Kết luận | ⚠ phạm vi đã hoàn thành và được chấp nhận thì đề nghị của người khác không tạo ra nghĩa vụ mới |

⚠ Cách trả lời cho lịch sự: ⚠ giải thích rõ ràng rằng phạm vi hợp đồng của bạn là sản xuất, đã được nghiệm thu xong ⚠ — ⚠ và nếu tổ chức muốn nhận thêm việc lắp đặt thì đó là một dự án MỚI với hợp đồng mới.

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

• B (làm một yêu cầu thay đổi để giúp lắp đặt) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ yêu cầu thay đổi là cơ chế đúng cho mọi thay đổi phạm vi, và câu trả lời này nghe rất đúng quy trình: ⚠ nhưng ⚠ không thể thay đổi phạm vi của một dự án đã ĐÓNG — khách hàng đã ký nghiệm thu, nghĩa là mọi quy trình kiểm soát thay đổi cũng đã kết thúc ⚠; ⚠ và quan trọng hơn: việc lắp đặt thuộc phạm vi của DỰ ÁN KHÁC, không phải của dự án bạn — nên nó không phải một thay đổi mà là một công việc hoàn toàn mới; ⚠ so sánh với #26946 lô 204, nơi cùng một phương án nhiễu xuất hiện với cùng một lỗi logic.

• D (lập một điều lệ dự án mới để lắp biển báo) — ⚠ về mặt kỹ thuật thì một công việc mới đúng là cần điều lệ mới; ⚠ nhưng đó là quyết định của tổ chức và khách hàng, không phải điều bạn tự khởi xướng khi vừa giao hàng.

• C (cười vì cho rằng người kia đang đùa) — ⚠ thiếu chuyên nghiệp; ⚠ đề nghị của họ hoàn toàn nghiêm túc, chỉ là dựa trên một hiểu nhầm về phạm vi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26946 lô 204 (CÂU GẦN TRÙNG — cùng tình huống với tay nắm cửa), ⚠ #27127 lô 207 (kế hoạch quản lý phạm vi và nghiệm thu chính thức), ⚠ #26998 lô 205 (mục loại trừ khỏi phạm vi), ⚠ #26984 lô 205 (lưu trữ hồ sơ khi đóng dự án).

⚠ Vì sao chữ ký nghiệm thu quan trọng đến vậy: | Ý nghĩa | Nội dung | |---|---| | ⚠ Xác nhận sản phẩm đạt yêu cầu | | | ⚠ Chuyển trách nhiệm sang khách hàng | | | ⚠ Cho phép đóng dự án và giải phóng nguồn lực | | | ⚠ Là ranh giới pháp lý cho mọi yêu cầu sau đó | ⚠ điểm quan trọng nhất ở đây | | ⚠ Bài học | ⚠ mọi yêu cầu đến SAU chữ ký nghiệm thu đều là công việc mới — và việc này rõ ràng tới mức không cần tranh cãi, miễn là có chữ ký; đó là lý do không bao giờ nên bỏ qua bước nghiệm thu chính thức dù khách hàng có vẻ hài lòng |

⚠ Cách từ chối cho đúng mực: | Nên nói | Không nên nói | |---|---| | ⚠ "Phạm vi của chúng tôi là sản xuất, đã nghiệm thu xong" | ⚠ "chúng tôi bận lắm" | | ⚠ "Việc lắp đặt nằm ngoài hợp đồng của bên tôi" | ⚠ "để tôi hỏi lại xem sao" | | ⚠ "Nếu cần hỗ trợ, anh liên hệ bộ phận kinh doanh" | ⚠ cười cợt hoặc coi thường đề nghị | | ⚠ Vì sao phải rõ ràng ngay | ⚠ một câu trả lời mơ hồ sẽ được hiểu là "có thể" — và tuần sau bạn sẽ nhận lại đúng câu hỏi đó, lúc đó khó từ chối hơn nhiều vì người ta đã kịp lên kế hoạch dựa trên sự mơ hồ của bạn |

⚠ Vì sao hai câu hỏi này lặp lại trong bộ đề: | Ý nghĩa | Nội dung | |---|---| | ⚠ Phình phạm vi sau nghiệm thu rất phổ biến | ⚠ và luôn bắt đầu bằng một đề nghị thân thiện | | ⚠ Người quản lý dự án hay ngại từ chối | | | ⚠ Công việc thêm sau nghiệm thu không được trả tiền | | | ⚠ Nguyên tắc cần thuộc | ⚠ giúp đỡ một lần là lịch sự, nhưng nó phải được nhận diện đúng là một sự giúp đỡ NGOÀI phạm vi chứ không được để trở thành một phần công việc mặc nhiên; liên hệ #26946 lô 204 |

Từ khoá nhận diện:

"khách đã nghiệm thu và ký nhận" → ⚠ dự án ĐÃ ĐÓNG, không làm gì thêm "làm yêu cầu thay đổi" → ⚠ không thể đổi phạm vi một dự án đã đóng "lập điều lệ mới" → ⚠ là việc của tổ chức, không phải bạn tự khởi xướng "coi như họ đùa" → ⚠ thiếu chuyên nghiệp, đề nghị của họ nghiêm túc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án gần nhất của bạn có biên bản nghiệm thu có chữ ký không | | | Bạn có đang làm giúp việc gì sau khi đã nghiệm thu không | | | Bạn từ chối bằng ranh giới hay bằng sự bận rộn | |

Và điều mà một chữ ký nghiệm thu mua được cho người quản lý dự án, ngoài việc kết thúc một dự án: quyền nói không mà không cần giải thích dài dòng — vì ranh giới đã được cả hai bên đồng ý từ trước, chứ không phải được nghĩ ra vào lúc bị hỏi.

Đáp án

B — KHUYẾN KHÍCH GIẢI QUYẾT VẤN ĐỀ CÙNG NHAU (collaborative problem-solving).

Vì sao đúng

⚠ Vấn đề chính xác mà Jackson đang gặp: | Triệu chứng | Ý nghĩa | |---|---| | ⚠ Hai người CÙNG giải một bài toán theo hai hướng | ⚠ trùng lặp công sức | | ⚠ Việc khác bị bỏ trống vì họ dồn vào một chỗ | ⚠ thiệt hại thật cho đội | | ⚠ Họ CÓ nói chuyện với nhau | ⚠ nên không phải vấn đề giao tiếp | | ⚠ Nhưng BỎ LỠ cơ hội làm việc cùng nhau | ⚠ đúng điểm cần can thiệp | | ⚠ Kết luận | ⚠ họ cần học cách CỘNG TÁC, không phải học cách nói chuyện hay hoà giải |

⚠ Chi tiết quyết định: ⚠ đề nói rõ "họ có nói chuyện với nhau" ⚠ — ⚠ câu đó loại bỏ các phương án về giao tiếp và về xung đột, chỉ còn lại vấn đề về cộng tác.

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

• D (sử dụng giao tiếp cởi mở và hiệu quả) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ giao tiếp là gốc rễ của rất nhiều vấn đề trong đội, và nếu hai người trao đổi tốt hơn thì đúng là họ sẽ phát hiện ra mình đang làm trùng: ⚠ nhưng ⚠ đề đã CHỦ ĐỘNG loại trừ khả năng này bằng câu "các lập trình viên có nói chuyện với nhau" ⚠; ⚠ vấn đề không phải là họ không trao đổi, mà là dù có trao đổi họ vẫn không nghĩ tới việc GIẢI QUYẾT VẤN ĐỀ CÙNG NHAU; ⚠ đó là hai việc khác nhau: nói cho nhau biết mình đang làm gì khác với cùng ngồi xuống giải một bài toán.

• A (quản lý xung đột một cách xây dựng) — ⚠ không có XUNG ĐỘT nào ở đây; ⚠ hai người cạnh tranh nhưng không mâu thuẫn, và sản phẩm vẫn ra đúng hạn.

• C (tạo cơ hội xây dựng đội) — ⚠ họ đã là một đội hoạt động tốt; ⚠ vấn đề nằm ở cách phân công và cách tiếp cận công việc, không nằm ở sự gắn kết.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26950 lô 204 (cả đội cùng giải quyết vấn đề), ⚠ #27118 lô 207 (lợi ích của việc cùng tìm giải pháp), ⚠ #26948 lô 204 (lập trình đôi), ⚠ #27112 lô 207 (hai thành viên không hợp tác được).

⚠ Phân biệt bốn vấn đề nghe giống nhau: | Vấn đề | Dấu hiệu | Cách chữa | |---|---|---| | ⚠ Thiếu GIAO TIẾP | ⚠ không ai biết người kia làm gì | ⚠ họp đứng, bảng công việc | | ⚠ XUNG ĐỘT | ⚠ có mâu thuẫn, né tránh nhau | ⚠ hoà giải — #27112 lô 207 | | ⚠ Thiếu GẮN KẾT | ⚠ đội rời rạc, không tin nhau | ⚠ xây dựng đội | | ⚠ Thiếu CỘNG TÁC | ⚠ biết việc của nhau nhưng vẫn làm riêng — ĐÁP ÁN | ⚠ ghép cặp, giao việc chung | | ⚠ Cách phân biệt | ⚠ hỏi "họ có biết người kia đang làm gì không" — biết mà vẫn làm riêng thì đó là vấn đề cộng tác chứ không phải giao tiếp |

⚠ Jackson có thể làm gì cụ thể: | Biện pháp | Nội dung | |---|---| | ⚠ Giao cho họ CÙNG một bài toán khó | ⚠ buộc phải cộng tác thật | | ⚠ Thử lập trình đôi cho các phần phức tạp | ⚠ liên hệ #26948 lô 204 | | ⚠ Làm rõ ai phụ trách hạng mục nào | ⚠ tránh trùng lặp ngay từ khâu phân công | | ⚠ Đưa việc trùng lặp ra buổi cải tiến | ⚠ để đội tự nhận ra chi phí của nó | | ⚠ Ghi nhận các lần họ cộng tác thành công | | | ⚠ Điều cần cẩn thận | ⚠ tính cạnh tranh và độc lập của hai người là thứ tạo ra sản phẩm tốt và đúng hạn — mục tiêu là thêm sự cộng tác chứ không phải dập tắt tính cạnh tranh, vì làm mất nó có thể khiến cả hai kém đi |

⚠ Vì sao trùng lặp công sức khó phát hiện: | Lý do | Nội dung | |---|---| | ⚠ Cả hai đều đang làm việc chăm chỉ | ⚠ nhìn vào ai cũng thấy bận | | ⚠ Kết quả cuối vẫn ra đúng hạn | ⚠ các chỉ số không báo động gì | | ⚠ Chi phí ẩn nằm ở việc KHÔNG LÀM | ⚠ các hạng mục bị bỏ trống | | ⚠ Cách phát hiện | ⚠ nhìn vào các việc KHÔNG ai làm chứ đừng chỉ nhìn vào các việc đang được làm — một bảng công việc có nhiều thẻ ở cột chờ trong khi ai cũng bận là dấu hiệu điển hình; liên hệ #26924 lô 203 |

Từ khoá nhận diện:

"có nói chuyện với nhau nhưng vẫn làm trùng" → ⚠ thiếu CỘNG TÁC "giao tiếp cởi mở" → ⚠ đề đã loại trừ: họ CÓ nói chuyện "quản lý xung đột" → ⚠ không có xung đột nào "xây dựng đội" → ⚠ họ đã là một đội hoạt động tốt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai trong đội bạn đang làm trùng việc nhau không | | | Có hạng mục nào không ai nhận trong khi ai cũng bận không | | | Đội bạn có bao giờ hai người cùng giải một bài toán không | |

Và khác biệt giữa một đội biết việc của nhau và một đội làm việc cùng nhau: cái thứ nhất tránh được sự bất ngờ, còn cái thứ hai mới tránh được sự lãng phí.

Đáp án

B — WBS QUYẾT ĐỊNH YÊU CẦU THAY ĐỔI NÊN ĐƯỢC DUYỆT HAY BỊ TỪ CHỐI.

Vì sao đúng

⚠ Vì sao câu này SAI: | Lý do | Nội dung | |---|---| | ⚠ WBS là một TÀI LIỆU, không phải cơ chế ra quyết định | ⚠ nó không quyết định gì cả | | ⚠ Việc duyệt thay đổi thuộc BAN KIỂM SOÁT THAY ĐỔI | ⚠ hoặc người được uỷ quyền | | ⚠ WBS chỉ là ĐẦU VÀO để đánh giá tác động | ⚠ cho biết thay đổi chạm tới gói công việc nào | | ⚠ Quyết định còn cần xét chi phí, rủi ro, giá trị | ⚠ những thứ WBS không chứa | | ⚠ Kết luận | ⚠ WBS cung cấp thông tin cho quyết định, nó không đưa ra quyết định |

⚠ Ba câu còn lại đều đúng: ⚠ WBS giúp kiểm soát phình phạm vi, giúp xác định vai trò, và là công cụ trao đổi về dự án ⚠ — ⚠ liên hệ #26959 lô 204 về việc lập WBS cùng nhau cũng là hoạt động xây dựng đội.

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

• A (WBS giúp kiểm soát phình phạm vi) — ⚠ phương án gây nhiễu mạnh nhất trong ba câu ĐÚNG vì ⚠ nghe như một tuyên bố mạnh: một cái cây phân rã công việc thì làm sao "kiểm soát" được điều gì: ⚠ nhưng ⚠ nó ĐÚNG — WBS định nghĩa toàn bộ công việc thuộc phạm vi, nên bất kỳ việc nào không có trong WBS đều là việc ngoài phạm vi ⚠; ⚠ đó chính là cơ chế phát hiện phình phạm vi: đối chiếu việc đang làm với cây WBS; ⚠ liên hệ #26968 lô 204 về đầu ra của kiểm soát phạm vi.

• C (WBS giúp xác định vai trò của thành viên) — ⚠ ĐÚNG; ⚠ ma trận trách nhiệm được xây từ WBS, và mỗi gói công việc được gán cho một người phụ trách.

• D (WBS dùng làm công cụ trao đổi về dự án) — ⚠ ĐÚNG; ⚠ nó cho mọi người một bức tranh chung về toàn bộ công việc — liên hệ #26959 lô 204.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26959 lô 204 (lập WBS cùng nhau là hoạt động xây dựng đội), ⚠ #26910 lô 203 (WBS là nền của mọi ước lượng), ⚠ #27042 lô 206 (mã tài khoản đánh số cho WBS), ⚠ #26968 lô 204 (kiểm soát phạm vi và phình phạm vi).

⚠ WBS dùng để làm gì: | Công dụng | Nội dung | |---|---| | ⚠ Định nghĩa TOÀN BỘ phạm vi công việc | ⚠ quy tắc 100% | | ⚠ Nền cho ước lượng thời gian và chi phí | ⚠ liên hệ #26910 lô 203 | | ⚠ Nền cho lập tiến độ và phân công | | | ⚠ Phát hiện phình phạm vi | ⚠ phương án A | | ⚠ Công cụ trao đổi và xây dựng đội | ⚠ phương án C và D | | ⚠ KHÔNG phải cơ chế phê duyệt thay đổi | ⚠ ĐÁP ÁN — điều WBS không làm | | ⚠ Quy tắc 100% | ⚠ WBS phải chứa 100% công việc của dự án, không thừa không thiếu — thứ không có trong WBS thì không thuộc dự án, và đó chính là cơ sở để nó kiểm soát được phình phạm vi |

⚠ Vai trò của WBS trong quy trình thay đổi: | Bước | WBS tham gia thế nào | |---|---| | ⚠ Nhận yêu cầu thay đổi | ⚠ không liên quan | | ⚠ ĐÁNH GIÁ TÁC ĐỘNG | ⚠ WBS cho biết gói công việc nào bị ảnh hưởng | | ⚠ Ra quyết định duyệt hay từ chối | ⚠ BAN KIỂM SOÁT THAY ĐỔI, không phải WBS | | ⚠ Cập nhật đường cơ sở nếu duyệt | ⚠ WBS được cập nhật — liên hệ #26964 lô 204 | | ⚠ Vai trò thật của WBS | ⚠ nó là ĐẦU VÀO ở bước hai và ĐẦU RA ở bước bốn — nhưng không bao giờ là người ra quyết định ở bước ba |

⚠ Trả lời câu hỏi của Evan thế nào: | Nội dung | Vì sao hữu ích | |---|---| | ⚠ WBS vẫn dùng sau khi lập kế hoạch xong | ⚠ đúng thứ Evan đang hỏi | | ⚠ Nó là chuẩn để đo tiến độ | ⚠ phần trăm hoàn thành tính trên các gói công việc | | ⚠ Nó là chuẩn để phát hiện việc ngoài phạm vi | | | ⚠ Nó là bản đồ để định vị mọi thay đổi | | | ⚠ Nhận xét | ⚠ câu hỏi của Evan rất hay và rất phổ biến — nhiều người coi WBS là một bài tập của giai đoạn lập kế hoạch rồi cất đi, trong khi giá trị lớn nhất của nó nằm ở việc được dùng làm chuẩn tham chiếu suốt phần còn lại của dự án |

Từ khoá nhận diện:

"WBS quyết định duyệt hay từ chối thay đổi" → ⚠ SAI, đó là việc của ban kiểm soát thay đổi "WBS giúp kiểm soát phình phạm vi" → ⚠ ĐÚNG, nhờ quy tắc 100% "WBS giúp xác định vai trò" → ⚠ ĐÚNG, ma trận trách nhiệm xây từ WBS "WBS là công cụ trao đổi" → ⚠ ĐÚNG, cho bức tranh chung

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn còn dùng WBS sau khi lập kế hoạch xong không | | | Có việc nào đang làm mà không có trong WBS không | | | WBS của bạn có chứa đủ 100% công việc không | |

Và điều mà một cái cây phân rã công việc làm được suốt dự án, chứ không chỉ trong tuần nó được vẽ ra: cho bạn một câu trả lời dứt khoát cho câu hỏi "việc này có thuộc dự án không" — mỗi lần có ai đó đề nghị thêm một thứ nhỏ.

Đáp án

D — LẬP BẢN TUYÊN BỐ PHẠM VI DỰ ÁN (project scope statement).

Vì sao đúng

⚠ Vì sao đây là bước tiếp theo: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ Đã có yêu cầu RÕ RÀNG và ĐÃ XẾP ƯU TIÊN | ⚠ đầu vào của bản tuyên bố phạm vi đã sẵn | | ⚠ Dự án dùng vòng đời DỰ ĐOÁN | ⚠ nên phạm vi được xác định chi tiết từ đầu | | ⚠ Có yêu cầu TUÂN THỦ cần xử lý sớm | ⚠ phải được ghi vào phạm vi | | ⚠ Kendra đang ở giai đoạn LẬP KẾ HOẠCH | | | ⚠ Kết luận | ⚠ từ yêu cầu sang bản tuyên bố phạm vi là bước kế tiếp trong chuỗi lập kế hoạch |

⚠ Chuỗi chuẩn: ⚠ điều lệ → thu thập yêu cầu → BẢN TUYÊN BỐ PHẠM VI → WBS → danh sách hoạt động → tiến độ ⚠ — ⚠ Kendra đang ở đúng mắt xích thứ ba; liên hệ #26912 lô 203.

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

• B (lập danh sách hoạt động cùng đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ danh sách hoạt động đúng là một bước của lập kế hoạch và nó đến khá sớm, nên nó nghe hợp lý: ⚠ nhưng ⚠ nó đến SAU bản tuyên bố phạm vi và SAU WBS — hoạt động được suy ra từ các gói công việc, mà gói công việc thì đến từ WBS ⚠; ⚠ nhảy thẳng vào danh sách hoạt động khi chưa có phạm vi được viết ra sẽ bỏ sót công việc, và không có cách nào kiểm tra được là đã đủ hay chưa; ⚠ liên hệ #26912 lô 203 về thứ tự bắt buộc của việc lập tiến độ.

• A (lập điều lệ dự án) — ⚠ điều lệ đã có; ⚠ đề nói nhà tài trợ đã tham gia và cung cấp yêu cầu, nghĩa là dự án đã được uỷ quyền.

• C (lập tiến độ cho các yêu cầu tuân thủ) — ⚠ quá xa về phía sau; ⚠ tiến độ cần WBS và danh sách hoạt động trước, và lập tiến độ cho một phần riêng lẻ là làm rời rạc.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26912 lô 203 (trình tự lập tiến độ), ⚠ #26910 lô 203 (WBS và từ điển WBS), ⚠ #26998 lô 205 (bản tuyên bố phạm vi gồm gì), ⚠ #27128 lô 207 (nhóm quy trình lập kế hoạch).

⚠ Chuỗi lập kế hoạch phạm vi và tiến độ: | Bước | Đầu ra | |---|---| | ⚠ 1. Điều lệ dự án | ⚠ uỷ quyền, mục tiêu khái quát — ĐÃ CÓ | | ⚠ 2. Thu thập yêu cầu | ⚠ tài liệu yêu cầu — ĐÃ CÓ | | ⚠ 3. Định nghĩa phạm vi | ⚠ BẢN TUYÊN BỐ PHẠM VI — ĐÁP ÁN | | ⚠ 4. Tạo WBS | ⚠ gói công việc | | ⚠ 5. Xác định hoạt động | ⚠ danh sách hoạt động — phương án B | | ⚠ 6. Xác định trình tự | ⚠ sơ đồ mạng | | ⚠ 7. Ước lượng thời lượng | | | ⚠ 8. Lập tiến độ | ⚠ phương án C | | ⚠ Vì sao thứ tự này bắt buộc | ⚠ mỗi bước dùng đầu ra của bước trước làm đầu vào — bỏ qua một bước nghĩa là bước sau phải đoán, và mọi thứ xây trên phỏng đoán đó đều thừa hưởng sai số |

⚠ Yêu cầu tuân thủ cần được xử lý thế nào: | Việc | Nội dung | |---|---| | ⚠ Ghi rõ trong bản tuyên bố phạm vi | ⚠ để nó là phạm vi bắt buộc, không phải tuỳ chọn | | ⚠ Đưa vào tiêu chí chấp nhận | | | ⚠ Xác định các sản phẩm bàn giao liên quan | ⚠ báo cáo, chứng nhận, hồ sơ | | ⚠ Đưa vào định nghĩa hoàn thành | ⚠ liên hệ #27059 lô 206 | | ⚠ Vì sao phải làm SỚM | ⚠ yêu cầu tuân thủ thường không thương lượng được và có thể quyết định cả kiến trúc giải pháp — phát hiện muộn thì phải làm lại từ đầu, chứ không phải chỉ thêm một hạng mục |

⚠ Bản tuyên bố phạm vi gồm gì: | Thành phần | Nội dung | |---|---| | ⚠ Mô tả phạm vi sản phẩm | | | ⚠ Sản phẩm bàn giao | | | ⚠ Tiêu chí chấp nhận | | | ⚠ LOẠI TRỪ khỏi phạm vi | ⚠ mục giá trị nhất — liên hệ #26998 lô 205 | | ⚠ Ràng buộc và giả định | ⚠ yêu cầu tuân thủ là một ràng buộc | | ⚠ Vì sao nó là mắt xích quan trọng nhất | ⚠ mọi thứ sau đó — WBS, tiến độ, chi phí, nghiệm thu — đều được đo bằng nó; một bản phạm vi mơ hồ sẽ làm mọi con số phía sau trở nên vô nghĩa |

Từ khoá nhận diện:

"đã có yêu cầu ưu tiên rõ, dự án dự đoán" → ⚠ lập BẢN TUYÊN BỐ PHẠM VI "danh sách hoạt động" → ⚠ đến sau WBS "điều lệ dự án" → ⚠ đã có, nhà tài trợ đã tham gia "tiến độ cho yêu cầu tuân thủ" → ⚠ quá xa, cần WBS và hoạt động trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có bản tuyên bố phạm vi được viết ra không | | | Các yêu cầu tuân thủ đã nằm trong đó chưa | | | Bạn có bỏ qua bước nào trong chuỗi tám bước không | |

Và lý do bản tuyên bố phạm vi đáng bỏ công dù nó chỉ là văn bản: vì đó là lần cuối cùng bạn còn có thể thay đổi hiểu biết chung về dự án bằng một cuộc trò chuyện, thay vì bằng một yêu cầu thay đổi.

Đáp án

B — BUỔI RÚT KINH NGHIỆM (debriefing).

Vì sao đúng

⚠ Vì sao buổi cải tiến tương ứng với buổi rút kinh nghiệm: | Điểm chung | Nội dung | |---|---| | ⚠ Diễn ra SAU một giai đoạn công việc | ⚠ cuối chặng hoặc cuối giai đoạn | | ⚠ Nhìn lại điều gì tốt, điều gì chưa tốt | ⚠ đúng nội dung Tracey yêu cầu điền | | ⚠ Rút ra hành động cải tiến cho lần sau | | | ⚠ Do chính đội thực hiện | ⚠ không phải bên ngoài đánh giá | | ⚠ Kết luận | ⚠ buổi cải tiến là phiên bản định kỳ và ngắn hơn của buổi rút kinh nghiệm truyền thống |

⚠ Khác biệt về TẦN SUẤT: ⚠ dự án dự đoán thường rút kinh nghiệm ở cuối giai đoạn hoặc cuối dự án, còn agile làm ở cuối MỖI chặng ⚠ — ⚠ đó là lý do agile học nhanh hơn; liên hệ #27031 lô 205.

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

• C (rà soát — reviewing) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ agile CÓ một sự kiện tên là "sprint review" và từ "review" xuất hiện ngay trong tên gọi, nên rất dễ chọn nhầm: ⚠ nhưng ⚠ buổi RÀ SOÁT CHẶNG bàn về SẢN PHẨM và có bên liên quan tham dự, còn buổi CẢI TIẾN bàn về CÁCH LÀM VIỆC và chỉ có đội ⚠; ⚠ đề mô tả rõ nội dung là "điều gì tốt, điều gì cần cải thiện, hành động cho các chặng sau" — toàn bộ là về quy trình chứ không về sản phẩm; ⚠ liên hệ #27031 lô 205 và #26905 lô 203: đây là cặp sự kiện bị nhầm nhiều nhất trong scrum.

• A (bảo đảm chất lượng) — ⚠ là hoạt động kiểm tra QUY TRÌNH có được tuân thủ không; ⚠ do bên thứ ba thực hiện, không phải đội tự nhìn lại.

• D (kiểm toán) — ⚠ là đánh giá độc lập từ BÊN NGOÀI; ⚠ mang tính tuân thủ và thường có yếu tố chính thức, khác hẳn không khí của một buổi cải tiến.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27031 lô 205 (buổi cải tiến sinh ra hành động cải tiến), ⚠ #26905 lô 203 (cả đội dự buổi cải tiến), ⚠ #27150 cùng lô (nêu lỗi ở buổi cải tiến mà không đổ lỗi), ⚠ #27116 lô 207 (giá trị tôn trọng trong buổi cải tiến).

⚠ Đối chiếu sự kiện agile với hoạt động truyền thống: | Agile | Tương đương truyền thống | |---|---| | ⚠ Buổi CẢI TIẾN | ⚠ buổi rút kinh nghiệm, bài học kinh nghiệm — ĐÁP ÁN | | ⚠ Buổi RÀ SOÁT CHẶNG | ⚠ rà soát giai đoạn, nghiệm thu từng phần | | ⚠ Họp đứng hằng ngày | ⚠ họp tình trạng, nhưng ngắn hơn nhiều | | ⚠ Lập kế hoạch chặng | ⚠ lập kế hoạch giai đoạn | | ⚠ Tinh chỉnh tồn đọng | ⚠ làm rõ yêu cầu | | ⚠ Khác biệt xuyên suốt | ⚠ agile không phát minh ra hoạt động mới — nó chỉ làm cùng những hoạt động đó với tần suất cao hơn nhiều, và chính tần suất mới là điều tạo ra khác biệt |

⚠ Vì sao rút kinh nghiệm thường xuyên tốt hơn: | Lý do | Nội dung | |---|---| | ⚠ Trí nhớ còn tươi | ⚠ chi tiết chưa bị quên | | ⚠ Cải tiến áp dụng được NGAY ở chặng sau | ⚠ không phải chờ dự án sau | | ⚠ Vấn đề nhỏ được xử lý trước khi tích tụ | | | ⚠ Đội thấy được kết quả của việc mình đề xuất | ⚠ nên tiếp tục đề xuất | | ⚠ Vấn đề của cách truyền thống | ⚠ bài học rút ra ở cuối dự án chỉ giúp được dự án SAU, mà dự án sau thường có đội khác và bối cảnh khác — nên phần lớn giá trị bị mất; liên hệ #26925 lô 203 |

⚠ Điều Tracey làm đúng: | Việc | Nội dung | |---|---| | ⚠ Ba câu hỏi rõ ràng, không mơ hồ | ⚠ tốt, chưa tốt, hành động | | ⚠ Dùng bảng trực quan để mọi người cùng điền | ⚠ liên hệ #27003 lô 205 | | ⚠ Có mục HÀNH ĐỘNG chứ không chỉ nhận xét | ⚠ phần quan trọng nhất — #27031 lô 205 | | ⚠ Tần suất hai tuần một lần | ⚠ đủ thường xuyên để nhớ, đủ thưa để có thay đổi | | ⚠ Nhận xét | ⚠ việc yêu cầu điền TRƯỚC buổi họp cũng là một chi tiết hay — nó cho người hướng nội thời gian suy nghĩ và ngăn buổi họp bị chi phối bởi vài người nói nhanh nhất; liên hệ #27113 lô 207 |

Từ khoá nhận diện:

"nhìn lại điều tốt, điều cần cải thiện, hành động" → ⚠ buổi RÚT KINH NGHIỆM (debriefing) "rà soát" → ⚠ bàn về SẢN PHẨM, có bên liên quan dự "bảo đảm chất lượng" → ⚠ kiểm tra quy trình có được tuân thủ không "kiểm toán" → ⚠ đánh giá độc lập từ bên ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn rút kinh nghiệm bao lâu một lần | | | Bài học của bạn có được áp dụng ngay không hay chờ dự án sau | | | Buổi cải tiến của bạn có mục hành động không | |

Và điều mà việc rút kinh nghiệm hai tuần một lần mang lại mà việc rút kinh nghiệm cuối dự án thì không: cơ hội áp dụng bài học cho chính đội đã học được nó.