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

Đáp án

C — HỎI CHỦ SẢN PHẨM XEM TÍNH KHẢ THI CỦA DỰ ÁN CÓ THẬT SỰ THAY ĐỔI KHÔNG.

Vì sao đúng

⚠ Vì sao phải qua chủ sản phẩm: | Lý do | Nội dung | |---|---| | ⚠ Chủ sản phẩm sở hữu GIÁ TRỊ và tính khả thi của sản phẩm | ⚠ đây là quyết định của họ | | ⚠ Keith chỉ nghe từ MỘT bên liên quan | ⚠ cần xác minh | | ⚠ Đây là quyết định cấp SẢN PHẨM, không phải cấp chặng | | | ⚠ Scrum master không có thẩm quyền dừng hay đổi hướng dự án | | | ⚠ Kết luận | ⚠ xác minh với đúng người có thẩm quyền trước khi làm bất cứ gì |

⚠ Quy mô của quyết định: ⚠ "sản phẩm không còn khả thi" là tuyên bố có thể dẫn tới việc DỪNG cả dự án một năm ⚠ — ⚠ không phải loại quyết định được đưa ra từ một cuộc trò chuyện ở hành lang.

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

• A (huỷ chặng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ huỷ chặng là một cơ chế CÓ THẬT trong scrum, dùng đúng khi mục tiêu chặng đã trở nên vô nghĩa — và nếu sản phẩm thật sự không còn khả thi thì mục tiêu chặng đúng là vô nghĩa: ⚠ nhưng ⚠ quyền huỷ chặng thuộc về CHỦ SẢN PHẨM, không phải scrum master ⚠; ⚠ và quan trọng hơn: Keith chưa xác minh thông tin — huỷ một chặng dựa trên lời của một bên liên quan mà chưa hỏi chủ sản phẩm là hành động vượt thẩm quyền dựa trên thông tin chưa kiểm chứng; ⚠ huỷ chặng có thể là bước ĐÚNG, nhưng nó đến SAU khi chủ sản phẩm xác nhận.

• B (cùng đội xếp lại thứ tự tồn đọng) — ⚠ cũng là việc của chủ sản phẩm; ⚠ và xếp lại tồn đọng chỉ có ý nghĩa nếu sản phẩm vẫn còn được tiếp tục.

• D (chuẩn bị cho đội chuyển sang dự án khác) — ⚠ hành động dựa trên kết luận chưa được xác nhận; ⚠ và nó sẽ làm đội hoang mang ngay lập tức.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26993 lô 205 (thay đổi chiến lược tổ chức tác động tới dự án), ⚠ #27117 lô 207 (sự kiện bên ngoài tác động tới dự án agile), ⚠ #27124 lô 207 (chủ sản phẩm sở hữu giá trị), ⚠ #27051 lô 206 (đánh giá tác động trước khi hành động).

⚠ Ai có quyền làm gì khi sản phẩm mất tính khả thi: | Quyết định | Thuộc về ai | |---|---| | ⚠ Xác nhận sản phẩm còn khả thi không | ⚠ CHỦ SẢN PHẨM cùng bên liên quan | | ⚠ Huỷ chặng | ⚠ CHỦ SẢN PHẨM | | ⚠ Dừng hoặc đổi hướng dự án | ⚠ nhà tài trợ và cấp danh mục | | ⚠ Xếp lại tồn đọng | ⚠ chủ sản phẩm | | ⚠ Tạo điều kiện cho các cuộc trao đổi này | ⚠ SCRUM MASTER — vai của Keith | | ⚠ Vai trò thật của Keith lúc này | ⚠ kết nối bên liên quan với chủ sản phẩm và bảo đảm quyết định được đưa ra bởi đúng người, có đủ thông tin — chứ không phải tự quyết bất kỳ điều gì |

⚠ Vì sao phải xác minh trước: | Rủi ro nếu hành động ngay | Nội dung | |---|---| | ⚠ Một bên liên quan có thể nhận định sai | | | ⚠ Có thể chỉ MỘT PHẦN sản phẩm mất giá trị | ⚠ phần còn lại vẫn đáng làm | | ⚠ Có thể chuyển hướng thay vì dừng hẳn | | | ⚠ Huỷ nhầm gây thiệt hại rất lớn | ⚠ dự án một năm, đã đi được nhiều tháng | | ⚠ Câu hỏi cần trả lời trước tiên | ⚠ "thị trường đổi tới mức nào, và phần nào của sản phẩm bị ảnh hưởng" — câu trả lời có thể là dừng hẳn, cũng có thể chỉ là xếp lại ưu tiên; hai kết luận đó cách nhau rất xa |

⚠ Nếu chủ sản phẩm xác nhận là đúng: | Bước tiếp theo | Nội dung | |---|---| | ⚠ Chủ sản phẩm cân nhắc huỷ chặng | ⚠ phương án A, nhưng đến sau | | ⚠ Đánh giá lại toàn bộ tồn đọng | ⚠ phần nào còn giá trị | | ⚠ Trình bày các phương án cho nhà tài trợ | ⚠ dừng, chuyển hướng, hoặc thu hẹp | | ⚠ Thông tin cho đội một cách trung thực | | | ⚠ Điều Keith cần chuẩn bị tinh thần | ⚠ dừng một dự án đã đi được nhiều tháng là quyết định đúng đắn khi sản phẩm không còn giá trị — và trong agile, khả năng dừng sớm với phần công việc đã bàn giao còn nguyên giá trị chính là một trong những lợi thế lớn nhất; liên hệ #26917 lô 203 |

Từ khoá nhận diện:

"bên liên quan nói sản phẩm không còn khả thi" → ⚠ XÁC MINH với CHỦ SẢN PHẨM trước "huỷ chặng" → ⚠ quyền của chủ sản phẩm, và phải sau khi xác minh "xếp lại tồn đọng" → ⚠ cũng của chủ sản phẩm, và chỉ có nghĩa nếu dự án tiếp tục "chuẩn bị chuyển đội" → ⚠ hành động dựa trên kết luận chưa xác nhận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có xác minh thông tin lớn trước khi hành động không | | | Ai trong dự án bạn có thẩm quyền tuyên bố sản phẩm mất giá trị | | | Bạn có phân biệt được quyết định cấp chặng với cấp sản phẩm không | |

Và điều mà một tin lớn nghe được từ một người duy nhất luôn xứng đáng, trước bất kỳ hành động nào: một cuộc gọi để xác minh — vì cái giá của việc hỏi thêm luôn nhỏ hơn nhiều so với cái giá của việc hành động dựa trên một nửa bức tranh.

Đáp án

B — MA TRẬN VAI TRÒ VÀ TRÁCH NHIỆM (roles and responsibilities matrix).

Vì sao đúng

⚠ Vì sao đây là công cụ đúng: | Yêu cầu của lãnh đạo | Ma trận đáp ứng thế nào | |---|---| | ⚠ Thể hiện toàn bộ NHU CẦU NGUỒN LỰC | ⚠ liệt kê mọi vai trò trong dự án | | ⚠ Và các HOẠT ĐỘNG liên quan | ⚠ liệt kê công việc theo cột | | ⚠ Nối hai thứ đó với nhau | ⚠ mỗi ô cho biết ai làm gì với việc nào | | ⚠ Đội mười người, dự án mười một tháng | ⚠ đủ lớn để cần một bảng phân vai rõ ràng | | ⚠ Kết luận | ⚠ đây là công cụ duy nhất kết hợp được CON NGƯỜI với CÔNG VIỆC trong một bảng |

⚠ Dạng phổ biến nhất là ma trận RACI: ⚠ Responsible (thực hiện), Accountable (chịu trách nhiệm cuối cùng), Consulted (được hỏi ý), Informed (được thông báo) ⚠ — ⚠ mỗi ô là một trong bốn chữ đó.

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

• A (biểu đồ Gantt) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là biểu đồ nổi tiếng nhất trong quản lý dự án, cũng hiển thị các hoạt động, và nhiều phần mềm còn cho gán tên người vào từng thanh: ⚠ nhưng ⚠ Gantt là công cụ TIẾN ĐỘ — trục hoành của nó là THỜI GIAN, và nó trả lời câu hỏi "việc nào diễn ra khi nào" ⚠; ⚠ còn lãnh đạo hỏi về NHU CẦU NGUỒN LỰC và các hoạt động liên quan, tức là câu hỏi "ai chịu trách nhiệm việc gì"; ⚠ hai câu hỏi khác nhau cần hai công cụ khác nhau, và một biểu đồ Gantt mười một tháng sẽ không cho thấy ranh giới trách nhiệm chút nào.

• C (ma trận vai trò) và D (biểu đồ vai trò) — ⚠ cả hai đều là THUẬT NGỮ BỊA; ⚠ chúng cắt bớt tên gọi thật để nghe gần giống, và đây là dạng bẫy dùng tên gọi không đầy đủ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27125 lô 207 (kế hoạch quản lý nguồn lực), ⚠ #26910 lô 203 (WBS là nền để phân vai), ⚠ #27140 cùng lô (WBS giúp xác định vai trò), ⚠ #27091 lô 207 (nguồn lực dùng chung trong ma trận).

⚠ Ma trận RACI, bốn chữ và ý nghĩa: | Chữ | Nghĩa | Quy tắc | |---|---|---| | ⚠ R — Responsible | ⚠ người THỰC HIỆN công việc | ⚠ có thể có nhiều người | | ⚠ A — Accountable | ⚠ người chịu trách nhiệm CUỐI CÙNG | ⚠ chỉ MỘT người cho mỗi việc | | ⚠ C — Consulted | ⚠ được hỏi ý kiến trước khi làm | ⚠ trao đổi hai chiều | | ⚠ I — Informed | ⚠ được thông báo sau khi xong | ⚠ một chiều | | ⚠ Quy tắc quan trọng nhất | ⚠ mỗi hoạt động chỉ được có ĐÚNG MỘT chữ A — hai người cùng chịu trách nhiệm cuối cùng nghĩa là không ai chịu trách nhiệm, và đó là lỗi phổ biến nhất khi lập ma trận RACI |

⚠ Cách đọc một ma trận RACI để phát hiện vấn đề: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Một hàng không có chữ A | ⚠ không ai chịu trách nhiệm việc đó | | ⚠ Một hàng có nhiều chữ A | ⚠ trách nhiệm bị phân tán | | ⚠ Một cột đầy chữ R | ⚠ người đó bị quá tải | | ⚠ Quá nhiều chữ C | ⚠ mọi quyết định đều chậm vì phải hỏi quá nhiều người | | ⚠ Một người chỉ toàn chữ I | ⚠ có thể họ không cần trong dự án này | | ⚠ Giá trị lớn nhất của ma trận | ⚠ nó biến các giả định ngầm về trách nhiệm thành thứ nhìn thấy được — và phần lớn tranh chấp kiểu "tôi tưởng anh làm việc đó" biến mất ngay khi bảng này được lập |

⚠ Khi nào cần ma trận vai trò và trách nhiệm: | Tình huống | Nội dung | |---|---| | ⚠ Đội đông, nhiều bộ phận tham gia | ⚠ mười người của Anika | | ⚠ Dự án dài | ⚠ mười một tháng, nhân sự có thể đổi | | ⚠ Tổ chức ma trận, nguồn lực dùng chung | ⚠ liên hệ #27091 lô 207 | | ⚠ Có bên ngoài tham gia | | | ⚠ Khi nào không cần | ⚠ đội bốn người ngồi cùng phòng làm một việc — lúc đó ma trận RACI là thủ tục thừa, và nguyên tắc tailoring cho phép bỏ nó; liên hệ #27043 lô 206 |

Từ khoá nhận diện:

"nhu cầu nguồn lực và các hoạt động liên quan" → ⚠ MA TRẬN VAI TRÒ VÀ TRÁCH NHIỆM "biểu đồ Gantt" → ⚠ công cụ TIẾN ĐỘ, trục thời gian "ma trận vai trò" / "biểu đồ vai trò" → ⚠ THUẬT NGỮ BỊA, cắt bớt tên thật "RACI" → ⚠ dạng phổ biến nhất của ma trận này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có ma trận trách nhiệm không | | | Mỗi hoạt động có đúng một người chịu trách nhiệm cuối cùng không | | | Có ai trong đội bị dồn quá nhiều chữ R không | |

Và điều mà một bảng phân vai làm được trước khi tranh chấp xảy ra: loại bỏ câu "tôi tưởng người kia làm việc đó" — câu nói xuất hiện nhiều nhất trong mọi buổi phân tích một việc bị bỏ sót.

Đáp án

C — NHIỀU LỖI CÓ THỂ ĐƯỢC BẮT SỚM TRONG CHU KỲ PHÁT TRIỂN PHẦN MỀM.

Vì sao đúng

⚠ Vì sao TDD bắt lỗi sớm: | Cơ chế | Nội dung | |---|---| | ⚠ Viết kiểm thử TRƯỚC khi viết mã | ⚠ buộc phải nghĩ rõ hành vi mong muốn | | ⚠ Kiểm thử chạy sau mỗi thay đổi nhỏ | ⚠ lỗi lộ ra trong vài phút | | ⚠ Lỗi được phát hiện khi mã còn trong đầu người viết | ⚠ sửa rất nhanh | | ⚠ Bộ kiểm thử tích luỹ thành lưới an toàn | ⚠ bắt được lỗi hồi quy về sau | | ⚠ Kết luận | ⚠ giá trị lớn nhất nằm ở THỜI ĐIỂM phát hiện lỗi, không ở số lượng lỗi bắt được |

⚠ Vì sao thời điểm quan trọng tới vậy: ⚠ chi phí sửa một lỗi tăng khoảng mười lần qua mỗi giai đoạn phát hiện muộn hơn ⚠ — ⚠ liên hệ #26945 lô 204 về chi phí chất lượng.

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

• B (nhanh hơn nhiều so với cách phát triển thông thường) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ TDD thật sự làm dự án nhanh hơn TÍNH TỔNG, nhờ ít lỗi và ít phải làm lại — nên câu này đúng ở mức kết quả cuối cùng: ⚠ nhưng ⚠ ở mức viết mã ban đầu, TDD CHẬM HƠN vì phải viết cả kiểm thử ⚠; ⚠ và tốc độ không phải lợi ích được nêu trong tài liệu về TDD — lợi ích chính luôn là chất lượng và việc phát hiện lỗi sớm; ⚠ nói TDD nhanh hơn dễ dẫn tới thất vọng cho đội mới áp dụng, vì vài chặng đầu họ sẽ thấy mình chậm hẳn đi.

• A (chuyển bớt việc sang đội kiểm thử) — ⚠ ngược lại; ⚠ TDD chuyển việc kiểm thử VÀO tay lập trình viên chứ không đẩy ra ngoài.

• D (bảo đảm mọi giao diện người dùng được kiểm thử đầy đủ) — ⚠ TDD tập trung vào kiểm thử ĐƠN VỊ ở tầng mã; ⚠ giao diện thường cần loại kiểm thử khác.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27026 lô 205 (ATDD khác TDD ở chỗ nào), ⚠ #26994 lô 205 (đội mới áp dụng ATDD), ⚠ #26945 lô 204 (chi phí chất lượng và việc phòng ngừa), ⚠ #26948 lô 204 (lập trình đôi giữ chất lượng mã).

⚠ Chu trình TDD, ba bước lặp lại: | Bước | Nội dung | |---|---| | ⚠ ĐỎ: viết một kiểm thử, nó thất bại | ⚠ xác nhận kiểm thử thật sự kiểm tra được gì đó | | ⚠ XANH: viết mã tối thiểu để kiểm thử qua | ⚠ không làm nhiều hơn mức cần | | ⚠ TÁI CẤU TRÚC: dọn dẹp mã, kiểm thử vẫn xanh | ⚠ bước hay bị bỏ qua nhất | | ⚠ Vì sao bước ba quan trọng | ⚠ bỏ qua nó thì TDD chỉ tạo ra mã chạy đúng mà vẫn lộn xộn — và nợ kỹ thuật vẫn tích tụ như thường; liên hệ #26966 lô 204 và #27104 lô 207 |

⚠ Chi phí sửa lỗi theo thời điểm phát hiện: | Phát hiện ở đâu | Chi phí tương đối | |---|---| | ⚠ Khi đang viết mã | ⚠ thấp nhất — nơi TDD hoạt động | | ⚠ Khi kiểm thử tích hợp | ⚠ cao hơn nhiều | | ⚠ Khi nghiệm thu | ⚠ cao hơn nữa | | ⚠ Sau khi ra sản xuất | ⚠ cao nhất, cộng thêm uy tín | | ⚠ Ý nghĩa với đội | ⚠ mỗi phút bỏ ra viết kiểm thử là một khoản đầu tư vào việc phát hiện sớm — và giá trị của nó không nằm ở số lỗi bắt được mà ở việc chúng được bắt ở giai đoạn rẻ nhất |

⚠ Các lợi ích khác của TDD, ngoài việc bắt lỗi: | Lợi ích | Nội dung | |---|---| | ⚠ Bộ kiểm thử là TÀI LIỆU SỐNG | ⚠ mô tả hành vi mong đợi của hệ thống | | ⚠ Dám tái cấu trúc mà không sợ hỏng | ⚠ lưới an toàn | | ⚠ Buộc thiết kế mã dễ kiểm thử | ⚠ thường cũng là mã dễ bảo trì | | ⚠ Chia bài toán thành các bước nhỏ | | | ⚠ Lợi ích ít được nói tới nhất | ⚠ việc phải viết kiểm thử trước buộc lập trình viên làm rõ mình định xây cái gì — và khá nhiều yêu cầu mơ hồ bị phát hiện ngay ở bước đó, trước khi có dòng mã nào |

Từ khoá nhận diện:

"lợi ích lớn nhất của TDD" → ⚠ BẮT LỖI SỚM trong chu kỳ phát triển "nhanh hơn cách thông thường" → ⚠ chậm hơn khi viết, nhanh hơn tính tổng — không phải lợi ích được nêu "chuyển việc sang đội kiểm thử" → ⚠ ngược lại, TDD đưa kiểm thử vào tay lập trình viên "kiểm thử giao diện đầy đủ" → ⚠ TDD tập trung ở tầng đơn vị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi của đội bạn thường được phát hiện ở giai đoạn nào | | | Đội bạn có bỏ qua bước tái cấu trúc không | | | Bộ kiểm thử của bạn có đủ để dám sửa mã cũ không | |

Và điều mà TDD thật sự mua cho một đội, đắt hơn nhiều so với vài lỗi được bắt: sự tự tin để sửa mã cũ — vì một đội không dám động vào mã đã chạy được là một đội đã ngừng cải thiện sản phẩm của mình.

Đáp án

D — XÁC NHẬN RẰNG GIAI ĐOẠN MỘT ĐÃ ĐẠT MỤC TIÊU VÀ CÁC SẢN PHẨM BÀN GIAO ĐÃ ĐƯỢC NGHIỆM THU CHÍNH THỨC.

Vì sao đúng

⚠ Vì sao đây là việc đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Bạn chỉ có LỜI NÓI của người quản lý cũ | ⚠ "vừa xong giai đoạn một" cần được kiểm chứng | | ⚠ Giai đoạn hai xây trên kết quả của giai đoạn một | ⚠ nền không vững thì mọi thứ sau đều lung lay | | ⚠ Nghiệm thu CHÍNH THỨC là bằng chứng duy nhất | ⚠ có chữ ký, không phải cảm nhận | | ⚠ Người quản lý cũ sắp rời công ty | ⚠ sau đó không hỏi lại được nữa | | ⚠ Kết luận | ⚠ xác minh điểm xuất phát trước khi bước tiếp — và làm ngay khi người bàn giao còn ở đó |

⚠ Chi tiết quan trọng về thời điểm: ⚠ người quản lý cũ đang RỜI CÔNG TY ⚠ — ⚠ nên mọi câu hỏi cần hỏi phải được hỏi ngay bây giờ, đây là cửa sổ duy nhất; liên hệ #26949 lô 204.

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

• B (kiểm tra tình trạng dự án so với kế hoạch) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đây đúng là một việc phải làm khi tiếp quản, và nó nghe rất giống việc xác minh: ⚠ nhưng ⚠ nó rộng hơn và mơ hồ hơn — "so với kế hoạch" có thể là tiến độ, chi phí, hoặc phạm vi ⚠; ⚠ còn câu hỏi hỏi việc ĐẦU TIÊN cần làm TRƯỚC KHI BẮT ĐẦU GIAI ĐOẠN HAI, và điều kiện tiên quyết cụ thể để bắt một giai đoạn là giai đoạn trước đã được ĐÓNG đúng cách; ⚠ kiểm tra tình trạng tổng thể là việc quan trọng nhưng đến sau khi đã biết chắc mình đang đứng ở đâu.

• A (khuyến nghị hành động khắc phục để bù khoảng cách) — ⚠ hành động khi chưa biết có khoảng cách nào không; ⚠ đề không nói dự án đang lệch.

• C (bảo đảm nguồn lực cho giai đoạn tiếp theo) — ⚠ việc cần làm nhưng đến sau; ⚠ vô nghĩa nếu giai đoạn một chưa thật sự hoàn thành.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27084 lô 207 (nhận diện bên liên quan khi chuyển giai đoạn), ⚠ #26949 lô 204 (tiếp quản dự án từ người quản lý cũ), ⚠ #27127 lô 207 (nghiệm thu chính thức thuộc kế hoạch quản lý phạm vi), ⚠ #26946 lô 204 (chữ ký nghiệm thu là mốc kết thúc).

⚠ Cổng giai đoạn: điều kiện để bắt giai đoạn tiếp theo: | Điều kiện | Nội dung | |---|---| | ⚠ Sản phẩm bàn giao của giai đoạn trước ĐÃ ĐƯỢC NGHIỆM THU | ⚠ ĐÁP ÁN — điều kiện tiên quyết | | ⚠ Mục tiêu giai đoạn đã đạt | | | ⚠ Bài học đã được ghi lại | | | ⚠ Bên liên quan cho giai đoạn mới đã được nhận diện | ⚠ liên hệ #27084 lô 207 | | ⚠ Nguồn lực đã sẵn sàng | ⚠ phương án C, đến sau | | ⚠ Có phê duyệt để đi tiếp | | | ⚠ Giá trị của cổng giai đoạn | ⚠ đó là điểm dừng có kiểm soát để hỏi "có nên đi tiếp không" — và với một dự án vừa đổi người quản lý thì câu hỏi đó lại càng đáng được đặt ra một cách nghiêm túc |

⚠ Danh sách việc cần làm khi tiếp quản dự án: | Việc | Nội dung | |---|---| | ⚠ Xác nhận trạng thái thật của giai đoạn đã qua | ⚠ ĐÁP ÁN — làm trước tiên | | ⚠ Đọc kỹ toàn bộ hồ sơ dự án | ⚠ liên hệ #26949 lô 204 | | ⚠ Gặp các bên liên quan chính | | | ⚠ Rà soát sổ rủi ro và sổ vấn đề | | | ⚠ Kiểm tra nguồn lực và cam kết hiện có | | | ⚠ Việc cấp bách nhất vì lý do thời gian | ⚠ hỏi người quản lý cũ mọi thứ cần hỏi TRƯỚC khi họ rời đi — tri thức ẩn của họ về dự án sẽ biến mất cùng họ, và không tài liệu nào thay thế được; liên hệ #26920 lô 203 |

⚠ Vì sao "vừa xong giai đoạn một" cần được kiểm chứng: | Rủi ro | Nội dung | |---|---| | ⚠ "Xong" có thể là xong theo cảm nhận | ⚠ chưa có nghiệm thu chính thức | | ⚠ Có thể còn hạng mục dở dang | | | ⚠ Khách hàng có thể chưa ký chấp nhận | | | ⚠ Người sắp rời công ty có động cơ báo cáo lạc quan | ⚠ không nhất thiết cố ý | | ⚠ Cách kiểm chứng | ⚠ tìm BIÊN BẢN NGHIỆM THU CÓ CHỮ KÝ — nếu không có thì giai đoạn một chưa thật sự đóng, dù mọi người đều tin là đã xong; liên hệ #26946 lô 204 |

Từ khoá nhận diện:

"tiếp quản dự án, sắp bắt đầu giai đoạn hai" → ⚠ XÁC NHẬN giai đoạn một đã được nghiệm thu "kiểm tra tình trạng so với kế hoạch" → ⚠ rộng và mơ hồ hơn, đến sau "khuyến nghị hành động khắc phục" → ⚠ hành động khi chưa biết có lệch không "bảo đảm nguồn lực" → ⚠ vô nghĩa nếu giai đoạn trước chưa xong thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giai đoạn gần nhất của bạn có biên bản nghiệm thu không | | | Nếu bạn phải bàn giao ngày mai, người tiếp quản sẽ đọc gì | | | Bạn có hỏi hết mọi thứ trước khi người bàn giao rời đi không | |

Và điều mà người tiếp quản một dự án nên xác minh trước bất kỳ điều gì khác: rằng điểm xuất phát mình được nói cho biết là điểm xuất phát thật — vì mọi kế hoạch phía sau đều được xây trên đúng giả định đó.

Đáp án

B — XIN TƯ VẤN TỪ VĂN PHÒNG QUẢN LÝ CHƯƠNG TRÌNH.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu THỨ BA trong bộ đề về việc vi phạm quy tắc ứng xử, và cả ba có khoá KHÁC NHAU ⚠ — ⚠ #26931 lô 203: một người đi họp muộn một tuần → NHẮC RIÊNG; #27098 lô 207: một người liên tục ngắt lời qua bốn chặng, nhiều người phàn nàn → NÊU Ở BUỔI CẢI TIẾN; câu này: NHIỀU người LẶP LẠI việc vi phạm → XIN TƯ VẤN; ⚠ ba khoá không mâu thuẫn mà tạo thành một THANG LEO THANG theo mức độ: một người một lần → riêng tư; cả đội hoặc kéo dài → buổi cải tiến; nhiều người lặp lại dù đã xử lý → tìm hỗ trợ bên ngoài; ⚠ hãy đọc cả ba bài liền nhau, chúng chỉ có nghĩa đầy đủ khi đặt cạnh nhau.

Vì sao đúng

⚠ Vì sao xin tư vấn là bước phù hợp ở đây: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ NHIỀU thành viên cùng vi phạm | ⚠ vấn đề hệ thống, không phải cá nhân | | ⚠ Vi phạm LẶP ĐI LẶP LẠI | ⚠ các biện pháp thông thường đã không hiệu quả | | ⚠ Quy tắc do chính đội đã đồng ý | ⚠ nên lý do không phải là họ không biết | | ⚠ Isabella là scrum master, quyền hạn hạn chế | | | ⚠ Kết luận | ⚠ khi công cụ trong tầm mình đã cạn, tìm lời khuyên từ nơi có kinh nghiệm là bước hợp lý tiếp theo |

⚠ Điểm quan trọng: XIN TƯ VẤN khác BÁO CÁO: ⚠ Isabella tìm lời khuyên để tự xử lý tốt hơn, chứ không giao vấn đề cho người khác ⚠ — ⚠ đó là khác biệt giữa phương án B và các phương án còn lại.

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

• D (báo cáo các thành viên đó lên quản lý chức năng của họ) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ quản lý chức năng đúng là người có thẩm quyền kỷ luật, và với vi phạm lặp lại thì việc phối hợp với họ đúng là một bước hợp lệ: ⚠ nhưng ⚠ nó biến chuyện thành vấn đề KỶ LUẬT khi chưa thử tìm hiểu nguyên nhân hệ thống ⚠; ⚠ nhiều người cùng lặp lại một vi phạm thường có nguyên nhân chung: quy tắc không thực tế, hoặc điều kiện làm việc không cho phép tuân thủ; ⚠ báo cáo lên quản lý chức năng sẽ phá huỷ quan hệ với đội, và nếu nguyên nhân nằm ở chính quy tắc thì nó còn xử lý oan người; ⚠ liên hệ #27150 cùng lô: nhiều người cùng mắc lỗi là dấu hiệu của hệ thống.

• A (phạt công khai các thành viên đó) — ⚠ làm mất mặt trước tập thể; ⚠ trái nguyên tắc "khen công khai, góp ý riêng tư" và gần như chắc chắn phản tác dụng.

• C (than phiền với ban chỉ đạo) — ⚠ sai kênh và mang tính than phiền chứ không tìm giải pháp; ⚠ ban chỉ đạo lo về hướng đi của dự án, không lo quy tắc nội bộ của đội.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26931 lô 203 (MỘT người, mới xảy ra → nhắc riêng), ⚠ #27098 lô 207 (ảnh hưởng cả đội, kéo dài → buổi cải tiến), ⚠ #27150 cùng lô (nhiều người cùng mắc lỗi → buổi cải tiến không đổ lỗi), ⚠ #27072 lô 206 (mục đích của quy tắc ứng xử).

⚠ THANG LEO THANG khi quy tắc bị vi phạm: | Mức | Tình huống | Cách xử lý | |---|---|---| | ⚠ 1 | ⚠ một người, một lần | ⚠ nhắc riêng — #26931 lô 203 | | ⚠ 2 | ⚠ kéo dài hoặc ảnh hưởng cả đội | ⚠ nêu ở buổi cải tiến — #27098 lô 207 | | ⚠ 3 | ⚠ nhiều người cùng mắc | ⚠ buổi cải tiến, tìm nguyên nhân hệ thống — #27150 cùng lô | | ⚠ 4 | ⚠ LẶP LẠI dù đã xử lý | ⚠ XIN TƯ VẤN — câu này | | ⚠ 5 | ⚠ vẫn không chuyển biến | ⚠ phối hợp với quản lý chức năng | | ⚠ Nguyên tắc xuyên suốt | ⚠ luôn bắt đầu ở mức THẤP NHẤT có thể giải quyết được, và chỉ leo thang khi mức đó đã được thử mà không hiệu quả — leo thang sớm phá quan hệ, leo thang muộn khiến quy tắc mất giá trị |

⚠ Vì sao nhiều người lặp lại vi phạm thường là lỗi hệ thống: | Nguyên nhân có thể | Nội dung | |---|---| | ⚠ Quy tắc không thực tế | ⚠ "họp 8h30" khi nhiều người đưa con đi học | | ⚠ Điều kiện làm việc không cho phép tuân thủ | | | ⚠ Quy tắc được đặt ra bởi một nhóm nhỏ | ⚠ những người khác chưa bao giờ thật sự đồng ý | | ⚠ Bối cảnh đã đổi từ khi đặt quy tắc | | | ⚠ Không ai nhắc trong thời gian dài | ⚠ quy tắc đã tự hết hiệu lực | | ⚠ Câu hỏi Isabella nên hỏi trước tiên | ⚠ "quy tắc này có còn phù hợp không" — và đôi khi lời tư vấn đúng đắn nhất từ PMO cũng chính là câu hỏi đó |

⚠ Xin tư vấn khác báo cáo thế nào: | Xin tư vấn | Báo cáo | |---|---| | ⚠ Mình vẫn giữ trách nhiệm xử lý | ⚠ giao vấn đề cho người khác | | ⚠ Tìm kinh nghiệm và góc nhìn | ⚠ tìm thẩm quyền và biện pháp | | ⚠ Giữ được quan hệ với đội | ⚠ đội biết mình bị báo cáo | | ⚠ Vì sao khác biệt này quan trọng | ⚠ Isabella vẫn phải làm việc với đội này hằng ngày — cách cô ấy tìm sự giúp đỡ sẽ quyết định đội coi cô ấy là người đứng cùng phía hay là người đi mách |

Từ khoá nhận diện:

"NHIỀU người LẶP LẠI vi phạm" → ⚠ XIN TƯ VẤN, tìm nguyên nhân hệ thống "một người một lần" → ⚠ nhắc riêng (#26931 lô 203) "báo lên quản lý chức năng" → ⚠ biến thành kỷ luật khi chưa tìm nguyên nhân "phạt công khai" → ⚠ làm mất mặt, chắc chắn phản tác dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc nào của đội bạn hay bị vi phạm nhất | | | Quy tắc đó có còn phù hợp với thực tế không | | | Bạn đã thử mức thấp trước khi leo thang chưa | |

Và điều mà một quy tắc bị nhiều người vi phạm lặp đi lặp lại thường đang nói: không phải rằng đội thiếu kỷ luật, mà rằng quy tắc đó đã không còn khớp với cách công việc thật sự diễn ra.

Đáp án

D — TUYÊN BỐ TẦM NHÌN (vision statement).

Vì sao đúng

⚠ Kế hoạch tuân thủ chứa gì: | Thành phần | Nội dung | |---|---| | ⚠ Các yêu cầu pháp lý và quy định áp dụng | ⚠ báo cáo khí thải hằng năm | | ⚠ RỦI RO tuân thủ và cách ứng phó | ⚠ phương án A — CÓ | | ⚠ Tiêu chuẩn CHẤT LƯỢNG phải đạt | ⚠ phương án B — CÓ, ngưỡng khí thải | | ⚠ Quy trình quản lý THAY ĐỔI về tuân thủ | ⚠ phương án C — CÓ, quy định có thể đổi | | ⚠ Vai trò, trách nhiệm, lịch kiểm tra và báo cáo | | | ⚠ TẦM NHÌN | ⚠ KHÔNG thuộc kế hoạch này — ĐÁP ÁN | | ⚠ Lý do | ⚠ tầm nhìn thuộc điều lệ dự án hoặc chiến lược tổ chức, không thuộc một kế hoạch chuyên môn |

⚠ Phân biệt cốt lõi: ⚠ tầm nhìn nói về ĐÍCH ĐẾN mong muốn, còn kế hoạch tuân thủ nói về VIỆC BẮT BUỘC phải làm để không vi phạm ⚠ — ⚠ hai loại nội dung hoàn toàn khác nhau.

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

• C (thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "thay đổi" nghe như một lĩnh vực riêng có kế hoạch riêng của nó, nên dễ nghĩ rằng nó không thuộc kế hoạch tuân thủ: ⚠ nhưng ⚠ quản lý thay đổi là phần BẮT BUỘC của bất kỳ kế hoạch tuân thủ nào — vì chính các quy định pháp lý cũng thay đổi ⚠; ⚠ luật mới vừa được thông qua trong đề là một ví dụ sống: nếu ngưỡng khí thải bị siết chặt thêm sau hai năm thì kế hoạch phải có cơ chế để phát hiện và điều chỉnh; ⚠ một kế hoạch tuân thủ không có phần thay đổi sẽ lỗi thời ngay lần đầu quy định được sửa.

• A (rủi ro) — ⚠ CÓ; ⚠ và rủi ro tuân thủ ở đây rất nghiêm trọng: không đạt ngưỡng thì phải dừng hoạt động — liên hệ #27059 lô 206.

• B (chất lượng) — ⚠ CÓ; ⚠ các ngưỡng khí thải chính là tiêu chuẩn chất lượng phải đo và đạt.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27059 lô 206 (rủi ro tuân thủ và cách xử lý khác biệt), ⚠ #27099 lô 207 (đề xuất trái luật của bên liên quan), ⚠ #27001 lô 205 (ngành có quản lý chặt, chất lượng là ràng buộc cứng), ⚠ #27115 lô 207 (mỗi tài liệu chỉ chứa phần của mình).

⚠ Kế hoạch tuân thủ nên trả lời những câu nào: | Câu hỏi | Nội dung | |---|---| | ⚠ Quy định nào áp dụng cho dự án này | ⚠ liệt kê cụ thể, có trích dẫn | | ⚠ Ngưỡng và tiêu chuẩn phải đạt là gì | ⚠ phần chất lượng | | ⚠ Đo và báo cáo thế nào, bao lâu một lần | ⚠ hằng năm trong đề | | ⚠ Ai chịu trách nhiệm cho từng phần | | | ⚠ Rủi ro nếu không đạt và cách ứng phó | ⚠ phần rủi ro | | ⚠ Xử lý thế nào khi quy định thay đổi | ⚠ phần thay đổi | | ⚠ Điều đáng lo nhất trong đề | ⚠ hậu quả không đạt là PHẢI DỪNG HOẠT ĐỘNG — nên đây không phải rủi ro dự án mà là rủi ro sống còn của cả công ty, và kế hoạch tuân thủ xứng đáng được xem là tài liệu quan trọng nhất của dự án này |

⚠ Vì sao tầm nhìn không thuộc kế hoạch chuyên môn: | Loại tài liệu | Chứa tầm nhìn không | |---|---| | ⚠ Điều lệ dự án | ⚠ CÓ — mục tiêu và lý do tồn tại | | ⚠ Luận chứng kinh doanh | ⚠ CÓ — liên hệ #27115 lô 207 | | ⚠ Kế hoạch tuân thủ | ⚠ KHÔNG — nó nói về nghĩa vụ bắt buộc | | ⚠ Kế hoạch quản lý chất lượng, rủi ro, phạm vi | ⚠ KHÔNG — đều là kế hoạch chuyên môn | | ⚠ Nguyên tắc chung | ⚠ mỗi tài liệu chỉ nên chứa phần trả lời câu hỏi của mình — lặp nội dung ở nhiều chỗ sẽ khiến chúng lệch nhau sau vài lần cập nhật, và không ai biết bản nào đúng; liên hệ #27115 lô 207 |

⚠ Đặc thù của dự án tuân thủ môi trường: | Yếu tố | Nội dung | |---|---| | ⚠ Hạn chót do PHÁP LUẬT đặt ra | ⚠ hai năm, không thương lượng được | | ⚠ Hậu quả cực đoan nếu không đạt | ⚠ dừng hoạt động | | ⚠ Phải báo cáo định kỳ cho cơ quan quản lý | ⚠ hằng năm | | ⚠ Có thể phát sinh quy định chặt hơn | | | ⚠ Hệ quả cho cách quản lý dự án | ⚠ với hạn chót cứng và hậu quả sống còn, phạm vi và chi phí phải là biến số còn thời gian là hằng số — và mọi quyết định đánh đổi đều phải xuất phát từ nguyên tắc đó |

Từ khoá nhận diện:

"tuyên bố tầm nhìn" → ⚠ KHÔNG thuộc kế hoạch tuân thủ "thay đổi" → ⚠ CÓ, vì chính quy định cũng thay đổi "rủi ro" → ⚠ CÓ, và ở đây rất nghiêm trọng "chất lượng" → ⚠ CÓ, các ngưỡng phải đo và đạt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có kế hoạch tuân thủ không | | | Nó có cơ chế phát hiện khi quy định thay đổi không | | | Ai chịu trách nhiệm báo cáo cho cơ quan quản lý | |

Và điều làm cho một kế hoạch tuân thủ khác mọi kế hoạch khác của dự án: các mục tiêu trong đó không do tổ chức đặt ra, nên chúng cũng không thể được tổ chức điều chỉnh khi thấy khó.

Đáp án

C — HƯỚNG ANH ẤY TỚI QUY TRÌNH KIỂM SOÁT THAY ĐỔI.

Vì sao đúng

⚠ Vì sao đây là câu trả lời đúng: | Yếu tố | Nội dung | |---|---| | ⚠ Dự án dùng cách tiếp cận WATERFALL | ⚠ đã có đường cơ sở được duyệt | | ⚠ Thêm việc mới là THAY ĐỔI PHẠM VI | ⚠ phải qua quy trình chính thức | | ⚠ Đề xuất được GHI NHẬN chứ không bị gạt bỏ | ⚠ giữ tinh thần chủ động của đội | | ⚠ Quy trình sẽ đánh giá tác động đầy đủ | ⚠ chi phí, tiến độ, rủi ro | | ⚠ Kết luận | ⚠ hướng ý tưởng tốt vào đúng kênh, không nói không cũng không nói có ngay |

⚠ Chi tiết "waterfall" là chìa khoá: ⚠ trong dự án dự đoán, mọi thay đổi phạm vi đều đi qua kiểm soát thay đổi ⚠ — ⚠ còn trong agile thì ý tưởng này sẽ vào tồn đọng; liên hệ #27022 lô 205.

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

• B (hướng anh ấy tới tồn đọng sản phẩm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "thêm vào tồn đọng" là câu trả lời đúng cho gần như mọi câu hỏi tương tự trong dự án AGILE — và bộ đề có rất nhiều câu như vậy: ⚠ nhưng ⚠ đề nói rõ dự án này dùng WATERFALL, nên không có tồn đọng sản phẩm nào cả ⚠; ⚠ đây là bẫy kiểm tra xem thí sinh có đọc kỹ loại vòng đời của dự án hay chỉ phản xạ theo thói quen; ⚠ liên hệ #27123 lô 207: cùng một tình huống trong dự án agile thì đáp án đúng lại là thêm vào tồn đọng — hai câu này đáng đọc cạnh nhau.

• A (nói rằng phạm vi đã bị khoá) — ⚠ sai và dập tắt sáng kiến; ⚠ đường cơ sở được chốt chứ không bị khoá vĩnh viễn — liên hệ #27137 cùng lô.

• D (khiển trách vì không làm việc được giao) — ⚠ trừng phạt một hành vi đáng khuyến khích; ⚠ và sẽ khiến không ai đề xuất gì nữa.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27123 lô 207 (cùng tình huống trong dự án AGILE → thêm vào tồn đọng), ⚠ #27137 cùng lô (mọi thay đổi qua quy trình kiểm soát), ⚠ #26935 lô 204 (đánh giá rồi nộp yêu cầu thay đổi), ⚠ #27069 lô 206 (cảm ơn và chuyển đề xuất lên CCB).

⚠ Cùng một đề xuất, hai vòng đời, hai câu trả lời: | Vòng đời | Cách xử lý đề xuất mới | |---|---| | ⚠ DỰ ĐOÁN / waterfall | ⚠ yêu cầu thay đổi, qua CCB — câu này | | ⚠ AGILE | ⚠ thêm vào tồn đọng, chủ sản phẩm xếp thứ tự — #27123 lô 207 | | ⚠ LAI | ⚠ tuỳ phần nào của dự án bị ảnh hưởng | | ⚠ Điểm chung của cả ba | ⚠ đều GHI NHẬN đề xuất và đều có cơ chế đánh giá — không vòng đời nào cho phép gạt bỏ ý tưởng hay áp dụng ngay mà không xem xét |

⚠ Người quản lý dự án nên nói gì với Yuri: | Nên nói | Không nên nói | |---|---| | ⚠ "Ý hay, chúng ta đưa qua quy trình thay đổi" | ⚠ "phạm vi đã chốt rồi" | | ⚠ Giải thích các bước và thời gian dự kiến | ⚠ chỉ nói tên quy trình rồi thôi | | ⚠ Đề nghị anh ấy giúp mô tả lợi ích cụ thể | ⚠ để anh ấy tự xoay xở | | ⚠ BÁO LẠI kết quả dù được duyệt hay không | ⚠ im lặng sau khi nộp | | ⚠ Việc quyết định anh ấy có đề xuất lần nữa hay không | ⚠ bước cuối cùng — nếu Yuri không bao giờ biết chuyện gì đã xảy ra với ý tưởng của mình, anh ấy sẽ kết luận rằng nêu sáng kiến là việc vô ích; liên hệ #27069 lô 206 |

⚠ Đánh giá đề xuất của Yuri cần xét gì: | Khía cạnh | Câu hỏi | |---|---| | ⚠ Lợi ích thật sự là gì, đo được không | | | ⚠ Chi phí và thời gian bổ sung | ⚠ dự án đang ở tuần 8 trên 20 | | ⚠ Rủi ro khi đưa công nghệ mới vào giữa chừng | ⚠ rủi ro chính trong tình huống này | | ⚠ Tác động lên các phần đã hoàn thành | | | ⚠ Cân nhắc đặc thù | ⚠ thêm công nghệ MỚI vào một dự án waterfall đã đi được gần một nửa là loại thay đổi rủi ro nhất — nó có thể rất đáng làm, nhưng cũng có thể là thứ nên để dành cho dự án sau; chỉ việc đánh giá đầy đủ mới phân biệt được |

Từ khoá nhận diện:

"dự án WATERFALL, đề xuất thêm việc" → ⚠ QUY TRÌNH KIỂM SOÁT THAY ĐỔI "tồn đọng sản phẩm" → ⚠ dự án waterfall không có tồn đọng (xem #27123 lô 207 cho agile) "phạm vi đã khoá" → ⚠ sai, và dập tắt sáng kiến "khiển trách" → ⚠ trừng phạt một hành vi đáng khuyến khích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có biết cách nộp một đề xuất không | | | Đề xuất gần nhất có được báo lại kết quả không | | | Bạn có phân biệt cách xử lý theo loại vòng đời không | |

Và điều mà cách một người quản lý dự án phản ứng với đề xuất đầu tiên của một thành viên quyết định: liệu người đó có bao giờ nêu ý tưởng thứ hai hay không — và những ý tưởng không bao giờ được nói ra là thứ tổn thất mà không báo cáo nào ghi lại.

Đáp án

C — AVI MUỐN ĐỘI TỰ THỬ GIẢI QUYẾT KHÁC BIỆT TRƯỚC.

Vì sao đúng

⚠ Vì sao đây là lời giải thích hợp lý nhất: | Lý do | Nội dung | |---|---| | ⚠ Đội agile TỰ TỔ CHỨC | ⚠ giải quyết bất đồng nội bộ là năng lực họ cần có | | ⚠ Bất đồng về YÊU CẦU là bất đồng lành mạnh | ⚠ không phải xung đột cá nhân | | ⚠ Can thiệp quá sớm cản trở sự trưởng thành của đội | | | ⚠ Lãnh đạo phụng sự tạo điều kiện chứ không quyết thay | ⚠ liên hệ #26969 lô 204 | | ⚠ Kết luận | ⚠ giữ khoảng cách CÓ CHỦ Ý là một lựa chọn lãnh đạo, không phải sự thờ ơ |

⚠ Nhưng khoảng cách này có giới hạn: ⚠ nếu đội không tự giải quyết được và công việc bị ảnh hưởng thì Avi phải bước vào ⚠ — ⚠ liên hệ #27107 lô 207, nơi Melissa đã chờ vài ngày rồi phải hành động.

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

• D (Avi không biết cách giải quyết) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ sự thụ động bên ngoài trông giống hệt nhau dù nguyên nhân là chủ ý hay là bất lực — và người quan sát không phân biệt được: ⚠ nhưng ⚠ đề gọi Avi là "agile team leader", tức là người có vai trò và kinh nghiệm dẫn dắt ⚠; ⚠ và nó gán một lời giải thích tiêu cực không có căn cứ nào trong đề; ⚠ quy tắc chung của đề PMP: giữa một lời giải thích tích cực phù hợp với vai trò và một lời giải thích tiêu cực không có bằng chứng, luôn chọn cái thứ nhất; liên hệ #27048 lô 206 và #27143 cùng lô.

• A (Avi chờ đội bùng nổ rồi mới can thiệp) — ⚠ gán một động cơ vừa tiêu cực vừa phi lý; ⚠ không người lãnh đạo nào cố ý để tình hình xấu đi.

• B (một bên trong tranh cãi là bạn của Avi) — ⚠ hoàn toàn không có dữ kiện; ⚠ và nó ngụ ý thiên vị, một cáo buộc nghiêm trọng không có căn cứ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27107 lô 207 (khi nào người quản lý phải bước vào), ⚠ #27121 lô 207 (các nhóm chuyên môn bất đồng), ⚠ #26950 lô 204 (cả đội cùng giải quyết vấn đề), ⚠ #26969 lô 204 (scrum master lãnh đạo bằng ảnh hưởng).

⚠ Khi nào để đội tự giải quyết, khi nào bước vào: | Để đội tự giải quyết | Cần can thiệp | |---|---| | ⚠ Bất đồng về kỹ thuật hoặc yêu cầu | ⚠ xung đột cá nhân leo thang | | ⚠ Đội đang trao đổi với nhau | ⚠ hai bên đã ngừng nói chuyện | | ⚠ Công việc vẫn tiến triển | ⚠ tiến độ bị chặn | | ⚠ Chưa ai bị tổn thương | ⚠ có hành vi vượt ranh giới ứng xử | | ⚠ Đội đã từng tự giải quyết được trước đây | ⚠ đội chưa có kinh nghiệm hoặc đã thử mà không xong | | ⚠ Ranh giới thực dụng | ⚠ đặt cho mình một MỐC THỜI GIAN — "nếu tới cuối tuần họ chưa giải quyết được thì mình vào"; giữ khoảng cách vô thời hạn không còn là chiến lược mà là sự né tránh |

⚠ Vì sao để đội tự giải quyết lại có giá trị: | Lợi ích | Nội dung | |---|---| | ⚠ Đội học được cách xử lý bất đồng | ⚠ năng lực dùng lại được | | ⚠ Giải pháp do họ tìm ra thì họ cam kết | ⚠ liên hệ #27118 lô 207 | | ⚠ Không tạo thói quen chờ người lãnh đạo phán xử | | | ⚠ Người lãnh đạo giữ được vị thế trung lập | ⚠ cho những lần thật sự cần tới | | ⚠ Rủi ro nếu can thiệp quá sớm | ⚠ đội sẽ mang mọi bất đồng nhỏ tới cho bạn xử — và bạn trở thành nút thắt cho những chuyện lẽ ra họ tự làm được; liên hệ #26947 lô 204 |

⚠ Avi nên làm gì trong lúc giữ khoảng cách: | Việc | Nội dung | |---|---| | ⚠ Quan sát xem cuộc trao đổi có lành mạnh không | ⚠ không phải bỏ mặc hoàn toàn | | ⚠ Đặt mốc thời gian cho chính mình | | | ⚠ Chuẩn bị sẵn cách hỗ trợ nếu cần | ⚠ tiêu chí chung, người điều phối | | ⚠ Cho đội biết rằng mình sẵn sàng giúp nếu họ cần | | | ⚠ Điều làm nên khác biệt | ⚠ nói với đội rằng "tôi tin các bạn xử lý được, và tôi ở đây nếu cần" — một câu đó biến sự im lặng từ chỗ có thể bị hiểu là thờ ơ thành một sự tin tưởng có tuyên bố |

Từ khoá nhận diện:

"lãnh đạo giữ khoảng cách với tranh cãi của đội" → ⚠ muốn đội TỰ GIẢI QUYẾT trước "không biết cách giải quyết" → ⚠ gán lời giải thích tiêu cực không có căn cứ "chờ đội bùng nổ" → ⚠ động cơ vừa tiêu cực vừa phi lý "vì có bạn trong cuộc" → ⚠ cáo buộc thiên vị không có dữ kiện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có tự giải quyết được bất đồng không | | | Bạn có đặt mốc thời gian trước khi can thiệp không | | | Đội có biết bạn đang tin tưởng chứ không phải đang thờ ơ không | |

Và khác biệt duy nhất giữa sự tin tưởng và sự thờ ơ, khi nhìn từ bên ngoài chúng giống hệt nhau: việc người lãnh đạo có nói ra điều đó hay không.