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

Đáp án

C — PHÂN BỔ VÀ CHUYỂN GIAO RỦI RO (allocate and transfer risk).

Vì sao đúng

⚠ IPD (Integrated Project Delivery) là gì: | Đặc trưng | Nội dung | |---|---| | ⚠ Các bên (chủ đầu tư, thiết kế, thi công) ký MỘT hợp đồng nhiều bên | ⚠ thay vì chuỗi hợp đồng riêng lẻ | | ⚠ RỦI RO và LỢI ÍCH được CHIA SẺ chung | ⚠ cùng thắng, cùng chịu | | ⚠ Thành công đo bằng GIÁ TRỊ, không đo bằng phần việc của từng bên | ⚠ phương án B — có | | ⚠ Rủi ro được quản lý TẬP THỂ | ⚠ phương án A — có | | ⚠ Ra quyết định cộng tác, tham gia sớm từ mọi bên | | | ⚠ Vì sao C sai với IPD | ⚠ "phân bổ và chuyển giao rủi ro" là triết lý của hợp đồng TRUYỀN THỐNG — mỗi bên đẩy rủi ro sang bên khác; nó đối lập trực tiếp với việc chia sẻ rủi ro của IPD |

⚠ Cách nhớ nhanh: ⚠ IPD = CHIA SẺ rủi ro; hợp đồng truyền thống = CHUYỂN GIAO rủi ro ⚠ — ⚠ thấy chữ "transfer" trong một câu hỏi về IPD thì gần như chắc chắn đó là đáp án của câu phủ định.

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

• D (nỗ lực đơn phương — unilateral effort) — ⚠ phương án gây nhiễu mạnh nhất, và đây là một câu hỏi có vấn đề vì ⚠ "nỗ lực đơn phương" cũng KHÔNG phải đặc trưng của IPD — IPD là mô hình cộng tác đa bên, hoàn toàn trái với sự đơn phương: ⚠ về mặt logic, cả C và D đều trả lời được câu hỏi phủ định; ⚠ khoá đề chọn C, và lý do có thể chấp nhận là C mô tả một CƠ CHẾ HỢP ĐỒNG cụ thể đối lập trực tiếp với nguyên tắc chia sẻ rủi ro của IPD, còn D chỉ là một cụm từ chung chung không mô tả cơ chế nào; ⚠ xem thêm mục ghi nhớ về chất lượng câu hỏi bên dưới.

• A (rủi ro được quản lý tập thể) — ⚠ ĐÚNG là đặc trưng cốt lõi của IPD; ⚠ nên không phải đáp án của câu phủ định.

• B (thành công của đội dựa trên giá trị) — ⚠ cũng ĐÚNG là đặc trưng; ⚠ IPD gắn thù lao với giá trị chung của dự án.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này có HAI phương án cùng thoả mãn vế phủ định ⚠ — ⚠ C (chuyển giao rủi ro) và D (nỗ lực đơn phương) đều không phải đặc trưng của IPD; ⚠ khoá đáp án được GIỮ NGUYÊN là C theo quy tắc, nhưng khi gặp dạng này trong phòng thi hãy chọn phương án đối lập RÕ RÀNG NHẤT và CỤ THỂ NHẤT với khái niệm được hỏi; ⚠ ở đây "phân bổ và chuyển giao rủi ro" là tên một cơ chế hợp đồng có thật, đối lập từng chữ với "rủi ro được quản lý tập thể" ở phương án A — đó là dấu hiệu người ra đề muốn bạn nhận ra cặp đối lập này.

⚠ Đối chiếu: ⚠ #26558 lô 196 (các loại hợp đồng và cách phân chia rủi ro), ⚠ #26703 cùng lô (hợp đồng như công cụ chuyển giao rủi ro), ⚠ #26684 cùng lô (mô hình thẩm quyền mua sắm), ⚠ #26678 lô 198 (đàm phán theo nguyên tắc), ⚠ #26646 lô 198 (WBS và công việc thuê ngoài).

⚠ IPD so với mô hình giao thầu truyền thống: | Tiêu chí | Truyền thống (design-bid-build) | IPD | |---|---|---| | ⚠ Hợp đồng | ⚠ nhiều hợp đồng song phương riêng lẻ | ⚠ MỘT hợp đồng đa bên | | ⚠ Rủi ro | ⚠ phân bổ và CHUYỂN GIAO — phương án C | ⚠ CHIA SẺ tập thể — phương án A | | ⚠ Lợi nhuận | ⚠ mỗi bên tối ưu phần của mình | ⚠ gắn với kết quả chung — phương án B | | ⚠ Thời điểm nhà thầu tham gia | ⚠ sau khi thiết kế xong | ⚠ ngay từ đầu, cùng thiết kế | | ⚠ Khi có vấn đề | ⚠ tìm xem lỗi thuộc hợp đồng của ai | ⚠ cùng giải quyết | | ⚠ Hệ quả thực tế | ⚠ mô hình truyền thống tạo động lực để mỗi bên tự bảo vệ mình — đó là lý do nó sinh ra rất nhiều yêu cầu thay đổi và tranh chấp; IPD cố gắng loại bỏ chính động lực đó | |

⚠ Bốn cách xử lý rủi ro TIÊU CỰC — chỗ của "chuyển giao": | Cách | Nội dung | |---|---| | ⚠ NÉ TRÁNH (avoid) | ⚠ loại bỏ nguyên nhân, đổi kế hoạch | | ⚠ CHUYỂN GIAO (transfer) | ⚠ đẩy tác động sang bên thứ ba: bảo hiểm, hợp đồng giá cố định — liên hệ #26703 cùng lô | | ⚠ GIẢM NHẸ (mitigate) | ⚠ hạ xác suất hoặc tác động — liên hệ #26607 lô 197 | | ⚠ CHẤP NHẬN (accept) | ⚠ chủ động (có dự phòng) hoặc bị động | | ⚠ Điều tinh tế | ⚠ chuyển giao là một chiến lược HỢP LỆ trong quản lý rủi ro nói chung — nó chỉ trái với triết lý của riêng IPD, nơi các bên cố ý không đẩy rủi ro cho nhau |

Từ khoá nhận diện:

"IPD" → ⚠ chia sẻ rủi ro, chia sẻ lợi ích, hợp đồng đa bên, cộng tác sớm "phân bổ và chuyển giao rủi ro" → ⚠ mô hình truyền thống, KHÔNG phải IPD "quản lý rủi ro tập thể", "thành công dựa trên giá trị" → ⚠ đúng là đặc trưng IPD câu hỏi phủ định có hai đáp án hợp lý → ⚠ chọn cái đối lập cụ thể và rõ ràng nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn khuyến khích các bên hợp tác hay tự bảo vệ | | | Khi có vấn đề, cuộc họp đầu tiên bàn về giải pháp hay về trách nhiệm | | | Nhà thầu của bạn tham gia từ giai đoạn nào | |

Và điều mà Erik phát hiện ra sau khi phân tích đối thủ: các công ty kia không thắng vì làm tốt hơn phần việc của mình, mà vì họ đã bỏ được thói quen tính xem phần việc nào là của ai khi có chuyện xảy ra.

Đáp án

D — QUẢN LÝ (managerial).

Vì sao đúng

⚠ Đọc lại mô tả về Joon và ánh xạ sang chỉ dấu tính cách: | Việc Joon làm | Chỉ dấu | |---|---| | ⚠ Nhận diện điểm mạnh và điểm yếu của từng người | ⚠ đánh giá và bố trí nguồn lực | | ⚠ THIẾT KẾ QUY TRÌNH để mỗi người làm đúng vai mình hợp | ⚠ tổ chức công việc — đặc trưng quản lý | | ⚠ Dựng đội đứng vững rồi bàn giao cho người khác | ⚠ xây dựng cấu trúc bền, không phụ thuộc cá nhân anh | | ⚠ Làm việc này lặp đi lặp lại cho nhiều đội | ⚠ có phương pháp, không phải ngẫu hứng | | ⚠ Kết luận | ⚠ quản trị con người và quy trình một cách có hệ thống = chỉ dấu QUẢN LÝ |

⚠ PMBOK liệt kê một loạt chỉ dấu tính cách mà người quản lý dự án cần: ⚠ chân thành, lịch thiệp, sáng tạo, có văn hoá, cảm xúc, trí tuệ, quản lý, chính trị, định hướng dịch vụ, hệ thống ⚠ — ⚠ chỉ dấu "quản lý" chính là năng lực quản trị con người, quy trình và công việc.

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

• B (hệ thống — systemic) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ Joon rõ ràng có tư duy bài bản, lặp lại được, nên chữ "hệ thống" nghe rất khớp: ⚠ nhưng ⚠ chỉ dấu "hệ thống" nói về việc NHÌN DỰ ÁN NHƯ MỘT TỔNG THỂ và hiểu các bộ phận tương tác với nhau ra sao trong bối cảnh tổ chức ⚠ — ⚠ còn Joon làm việc với CON NGƯỜI và VAI TRÒ trong đội, đó là quản trị; ⚠ ranh giới: "hệ thống" nhìn ra ngoài và lên trên, "quản lý" nhìn vào bên trong đội.

• C (sáng tạo) — ⚠ là khả năng nghĩ ra giải pháp mới; ⚠ Joon áp dụng một cách làm đã chứng minh được, không phải sáng tạo cái mới.

• A (lịch thiệp — courteous) — ⚠ nói về cách cư xử nhã nhặn với người khác; ⚠ đề không nói gì về phong thái của Joon.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26664 lô 198 (tìm hiểu cách làm việc hợp nhất với từng người), ⚠ #26694 chính là mặt bổ sung của ⚠ #26676 lô 198 (đưa thành viên vào việc ra quyết định), ⚠ #26683 cùng lô (giai đoạn hình thành đội), ⚠ #26709 cùng lô (vận tốc đội), ⚠ #26696 cùng lô (trí tuệ cảm xúc).

⚠ MỘT SỐ CHỈ DẤU TÍNH CÁCH trong PMBOK — phân biệt cho đề thi: | Chỉ dấu | Nghĩa | Ví dụ tình huống | |---|---|---| | ⚠ QUẢN LÝ (managerial) | ⚠ quản trị con người, quy trình, công việc — ĐÁP ÁN | ⚠ bố trí người đúng vai, thiết kế quy trình làm việc | | ⚠ HỆ THỐNG (systemic) | ⚠ nhìn tổng thể, hiểu tương tác giữa các phần | ⚠ thấy thay đổi ở dự án A ảnh hưởng chương trình B | | ⚠ CHÍNH TRỊ (political) | ⚠ hiểu quyền lực và ảnh hưởng trong tổ chức | ⚠ liên hệ #26609 lô 197 | | ⚠ SÁNG TẠO (creative) | ⚠ nghĩ ra cách mới | ⚠ tìm giải pháp chưa ai làm | | ⚠ CẢM XÚC (emotional) | ⚠ hiểu cảm xúc mình và người khác | ⚠ liên hệ #26696 cùng lô | | ⚠ VĂN HOÁ (cultural) | ⚠ nhận thức khác biệt văn hoá | ⚠ liên hệ #26681 lô 198 | | ⚠ Cách làm dạng câu này | ⚠ tìm ĐỘNG TỪ chính trong đề rồi ghép với chỉ dấu: "thiết kế quy trình", "bố trí người" → quản lý; "nhìn ra tác động lan toả" → hệ thống; "đọc được tâm trạng" → cảm xúc |

⚠ Vì sao vai trò của Joon có giá trị với tổ chức: | Giá trị | Nội dung | |---|---| | ⚠ Đội được dựng đúng từ đầu | ⚠ rẻ hơn nhiều so với sửa một đội đã lệch — liên hệ #26648 lô 198 | | ⚠ Người quản lý dự án ít kinh nghiệm tiếp quản được | ⚠ vì cấu trúc đã vững, không phụ thuộc cá nhân Joon | | ⚠ Một chuyên gia phục vụ được nhiều đội | ⚠ dùng năng lực hiếm ở nơi nó tạo giá trị lớn nhất | | ⚠ Đội "lớn lên tự nhiên từ nền móng vững" | ⚠ chính là mô tả của việc vượt qua giai đoạn hình thành và sóng gió nhanh hơn | | ⚠ Rủi ro cần để ý | ⚠ mô hình này chỉ bền khi việc bàn giao được chuẩn bị kỹ — nếu Joon rời đi quá sớm, đội có thể quay lại giai đoạn sóng gió với một người dẫn dắt chưa đủ kinh nghiệm |

Từ khoá nhận diện:

"bố trí người theo điểm mạnh, thiết kế quy trình làm việc" → ⚠ chỉ dấu QUẢN LÝ "nhìn thấy tương tác giữa các phần, bối cảnh tổ chức" → ⚠ chỉ dấu hệ thống "nghĩ ra cách chưa ai làm" → ⚠ chỉ dấu sáng tạo "cư xử nhã nhặn" → ⚠ chỉ dấu lịch thiệp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết điểm mạnh thật của từng người trong đội không | ⚠ không phải chức danh của họ | | Có ai đang làm việc mà họ không hợp không | | | Nếu bạn rời đi tuần sau, đội có tự chạy được không | ⚠ câu trả lời đo đúng thứ Joon giỏi |

Và điều làm nên giá trị của một người như Joon: anh không làm cho đội chạy tốt khi có anh, mà làm cho đội chạy tốt sau khi anh đi — đó là hai kỹ năng rất khác nhau, và chỉ có kỹ năng thứ hai mới nhân rộng được.

Đáp án

A — MỘT CÁCH TRIỂN KHAI SAI của phát triển hướng kiểm thử (Test-Driven Development).

Vì sao đúng

⚠ Mark làm gì và TDD đòi gì: | Mark làm | TDD đòi | |---|---| | ⚠ 1. Viết mã hoàn thành nhiệm vụ | ⚠ 1. Viết KIỂM THỬ trước — và nó phải THẤT BẠI | | ⚠ 2. Sau đó viết kiểm thử để xác nhận mã đúng | ⚠ 2. Viết mã tối thiểu để kiểm thử đạt | | ⚠ (không có bước tái cấu trúc) | ⚠ 3. TÁI CẤU TRÚC mà vẫn giữ kiểm thử xanh | | ⚠ Kết luận | ⚠ Mark làm NGƯỢC thứ tự — đó là TDD sai, không phải TDD |

⚠ Vì sao thứ tự quan trọng đến vậy: ⚠ kiểm thử viết SAU khi có mã sẽ vô thức mô tả đúng những gì mã đã làm, kể cả những chỗ mã làm sai ⚠ — ⚠ nó xác nhận hành vi hiện có chứ không xác nhận YÊU CẦU; ⚠ kiểm thử viết trước buộc bạn phải nói rõ "đúng nghĩa là gì" khi chưa bị mã của chính mình dẫn dắt.

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

• C (triển khai ĐÚNG của TDD) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ Mark có viết kiểm thử, có ý thức về chất lượng, và với nhiều người thì "viết mã rồi viết kiểm thử" đã là một thực hành tốt rồi: ⚠ nhưng ⚠ chữ "DRIVEN" trong Test-Driven nghĩa là kiểm thử DẪN DẮT mã, tức là nó phải TỒN TẠI TRƯỚC ⚠ — ⚠ làm ngược thì mất toàn bộ giá trị dẫn dắt thiết kế của kỹ thuật này; ⚠ cái Mark làm có tên riêng: kiểm thử viết sau (test-after), một thực hành tốt nhưng không phải TDD.

• B (tái cấu trúc kiểm thử — test refactoring) — ⚠ tái cấu trúc là dọn dẹp mã đã có mà không đổi hành vi; ⚠ Mark đang viết mới, không dọn dẹp.

• D (tích hợp liên tục) — ⚠ nói về việc hợp nhất mã vào nhánh chung nhiều lần mỗi ngày kèm build tự động; ⚠ khác hẳn chủ đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26651 lô 198 (định nghĩa hoàn thành), ⚠ #26639 lô 198 (lỗi lọt ra ngoài — escaped defects), ⚠ #26728 cùng lô (tái cấu trúc mỗi sprint), ⚠ #26648 lô 198 (phát hiện và xử lý sớm), ⚠ #26717 cùng lô (cải tiến liên tục).

⚠ VÒNG LẶP TDD — đỏ, xanh, tái cấu trúc: | Bước | Nội dung | Vì sao | |---|---|---| | ⚠ ĐỎ — viết kiểm thử, chạy và THẤY NÓ HỎNG | ⚠ định nghĩa hành vi mong muốn trước | ⚠ kiểm thử hỏng chứng minh nó thật sự đang kiểm cái gì đó | | ⚠ XANH — viết mã TỐI THIỂU để kiểm thử đạt | ⚠ không viết thừa | ⚠ chống viết tính năng không ai yêu cầu | | ⚠ TÁI CẤU TRÚC — dọn mã, kiểm thử vẫn xanh | ⚠ cải thiện thiết kế an toàn | ⚠ liên hệ #26728 cùng lô | | ⚠ Lặp lại | ⚠ vòng lặp ngắn, thường vài phút một vòng | | | ⚠ Điểm mà Mark bỏ lỡ | ⚠ anh bỏ cả bước ĐỎ lẫn bước TÁI CẤU TRÚC — chỉ giữ lại phần viết mã và phần viết kiểm thử, tức là phần dễ nhất của cả hai |

⚠ TDD cho lại gì ngoài các bài kiểm thử: | Lợi ích | Nội dung | |---|---| | ⚠ Thiết kế tốt hơn | ⚠ mã dễ kiểm thử thường là mã ít phụ thuộc chằng chịt | | ⚠ Yêu cầu được làm rõ trước khi viết mã | ⚠ bạn buộc phải trả lời "đúng nghĩa là gì" | | ⚠ Lưới an toàn cho việc tái cấu trúc | | | ⚠ Tài liệu sống về hành vi mong đợi | | | ⚠ Phát hiện lỗi ngay trong vài phút, không phải vài tuần | ⚠ chi phí sửa thấp nhất — liên hệ #26639 lô 198 | | ⚠ Điều Mark vẫn có được | ⚠ anh vẫn có lưới an toàn cho lần sửa sau, nên việc anh làm KHÔNG vô ích — nó chỉ không phải TDD, và nó không đem lại lợi ích về thiết kế và làm rõ yêu cầu |

⚠ Ba khái niệm hay bị lẫn trong đề agile: | Khái niệm | Nội dung | |---|---| | ⚠ TDD | ⚠ kiểm thử đơn vị viết TRƯỚC mã, dẫn dắt thiết kế | | ⚠ TÍCH HỢP LIÊN TỤC (CI) | ⚠ hợp nhất mã thường xuyên, build và chạy kiểm thử tự động | | ⚠ TÁI CẤU TRÚC (refactoring) | ⚠ sửa cấu trúc mã, KHÔNG đổi hành vi | | ⚠ Quan hệ | ⚠ ba thứ này bổ trợ nhau: TDD tạo ra bộ kiểm thử, CI chạy nó liên tục, tái cấu trúc dựa vào nó để an toàn — nhưng chúng là ba thực hành riêng biệt và đề thi thường hỏi bạn phân biệt |

Từ khoá nhận diện:

"viết mã trước, kiểm thử sau" → ⚠ TDD SAI (test-after) "viết kiểm thử hỏng trước, rồi viết mã cho nó xanh" → ⚠ TDD đúng "hợp nhất mã nhiều lần mỗi ngày, build tự động" → ⚠ tích hợp liên tục "sửa cấu trúc mà không đổi hành vi" → ⚠ tái cấu trúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm thử của bạn có bao giờ ĐỎ trước khi xanh không | ⚠ nếu chưa từng, bạn đang làm test-after | | Bạn có bao giờ thấy một bài kiểm thử luôn xanh dù mã sai không | ⚠ đó là hậu quả điển hình của kiểm thử viết sau | | Sau khi kiểm thử xanh, bạn có dọn lại mã không | |

Và điều mà chữ "driven" trong Test-Driven Development thật sự đòi hỏi: bài kiểm thử phải là thứ quyết định mã sẽ trông như thế nào — chứ không phải thứ được viết ra sau để xác nhận rằng mã bạn đã viết đúng như bạn nghĩ.

Đáp án

B — THẨM QUYỀN (authority).

Vì sao đúng

⚠ Câu hỏi phủ định — soi từng phương án: | Phương án | Có thuộc trí tuệ cảm xúc không | |---|---| | ⚠ A — kỹ năng liên cá nhân | ⚠ CÓ — quản trị quan hệ là một trong bốn trụ | | ⚠ B — THẨM QUYỀN | ⚠ KHÔNG — ĐÁP ÁN | | ⚠ C — quan sát | ⚠ CÓ — nền của tự nhận thức và nhận thức xã hội | | ⚠ D — giao tiếp | ⚠ CÓ — công cụ để thể hiện và điều tiết cảm xúc |

⚠ Vì sao thẩm quyền không liên quan: ⚠ thẩm quyền là QUYỀN LỰC CHÍNH THỨC do vị trí trong tổ chức đem lại — nó được TRAO, không được RÈN ⚠; ⚠ trí tuệ cảm xúc là năng lực CÁ NHÂN về nhận biết và điều tiết cảm xúc, hoàn toàn không phụ thuộc chức vụ; ⚠ thực tế, người có nhiều thẩm quyền nhất trong phòng thường là người ít nhận được phản hồi trung thực nhất, nên họ càng cần trí tuệ cảm xúc chứ không phải càng ít cần.

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

• C (quan sát) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "quan sát" không nằm trong danh sách bốn thành tố kinh điển của Goleman, nên nghe như một từ lạc lõng: ⚠ nhưng ⚠ quan sát chính là CƠ CHẾ để có nhận thức xã hội — đọc nét mặt, giọng nói, ngôn ngữ cơ thể, sự thay đổi trong hành vi ⚠ — ⚠ không quan sát thì không có dữ liệu nào để thấu cảm; ⚠ nó thuộc về trí tuệ cảm xúc, nên không phải đáp án.

• A (kỹ năng liên cá nhân) — ⚠ chính là trụ "quản trị quan hệ"; ⚠ thuộc.

• D (giao tiếp) — ⚠ là cách trí tuệ cảm xúc biểu hiện ra bên ngoài; ⚠ thuộc.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26681 lô 198 (nhận thức văn hoá — trục khác với trí tuệ cảm xúc), ⚠ #26675 lô 198 (quản lý xung đột mang tính xây dựng), ⚠ #26694 cùng lô (các chỉ dấu tính cách), ⚠ #26700 cùng lô (xử lý cãi vã trong buổi hồi cứu), ⚠ #26698 cùng lô (huấn luyện một–một).

⚠ BỐN THÀNH TỐ của trí tuệ cảm xúc (Goleman): | Thành tố | Nội dung | Trong dự án | |---|---|---| | ⚠ TỰ NHẬN THỨC | ⚠ biết mình đang cảm thấy gì và vì sao | ⚠ nhận ra mình đang bực trước khi nói ra điều hối tiếc | | ⚠ TỰ ĐIỀU CHỈNH | ⚠ kiểm soát phản ứng của mình | ⚠ giữ bình tĩnh khi nhận tin xấu về tiến độ | | ⚠ NHẬN THỨC XÃ HỘI (thấu cảm) | ⚠ đọc được cảm xúc người khác — cần QUAN SÁT | ⚠ thấy thành viên im lặng bất thường thì hỏi | | ⚠ QUẢN TRỊ QUAN HỆ | ⚠ kỹ năng liên cá nhân, ảnh hưởng, hoà giải | ⚠ dẫn dắt cuộc trò chuyện khó với bên liên quan | | ⚠ Thứ KHÔNG có trong danh sách | ⚠ thẩm quyền, chức vụ, quyền lực chính thức — chúng thuộc về CẤU TRÚC TỔ CHỨC, không thuộc về năng lực cá nhân |

⚠ Vì sao trí tuệ cảm xúc quan trọng với cuộc trò chuyện khó: | Tình huống | Trí tuệ cảm xúc giúp gì | |---|---| | ⚠ Bên liên quan nổi giận về tiến độ | ⚠ nghe cảm xúc trước, trả lời dữ liệu sau | | ⚠ Phải báo tin xấu | ⚠ chọn thời điểm, cách nói và kênh phù hợp | | ⚠ Hai thành viên xung đột | ⚠ tách vấn đề khỏi con người — liên hệ #26675 lô 198 | | ⚠ Nhà tài trợ ép cắt phạm vi | ⚠ hiểu áp lực thật sự của họ đang đến từ đâu | | ⚠ Điều thẩm quyền KHÔNG làm được | ⚠ bạn có thể ra lệnh cho người ta LÀM, nhưng không ra lệnh được cho người ta TIN, HỢP TÁC hay NÓI THẬT — và đó chính là ba thứ mà một dự án cần nhất |

⚠ Nhận diện các câu hỏi phủ định trong đề PMP: | Mẹo | Nội dung | |---|---| | ⚠ Gạch chân chữ "không", "ngoại trừ", "NOT" | ⚠ đọc vội là mất điểm dù hiểu bài | | ⚠ Đánh dấu Đ/S cho từng phương án | ⚠ rồi tìm cái duy nhất khác biệt | | ⚠ Cảnh giác với phương án thuộc phạm trù KHÁC HẲN | ⚠ thẩm quyền là khái niệm về tổ chức, ba cái kia là năng lực cá nhân — đó là dấu hiệu rõ nhất | | ⚠ Nguyên tắc | ⚠ trong câu phủ định, đáp án thường là phương án "lạc loài" về mặt phạm trù, chứ không phải phương án sai một chút về mức độ |

Từ khoá nhận diện:

"thẩm quyền, chức vụ, quyền lực chính thức" → ⚠ KHÔNG thuộc trí tuệ cảm xúc "tự nhận thức, tự điều chỉnh, thấu cảm, quản trị quan hệ" → ⚠ bốn trụ "quan sát" → ⚠ cơ chế của thấu cảm, vẫn thuộc "giao tiếp" → ⚠ cách trí tuệ cảm xúc biểu hiện, vẫn thuộc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có nhận ra cảm xúc của mình trước khi phản ứng không | | | Lần gần nhất bạn thay đổi cách nói vì đọc được tâm trạng người nghe là khi nào | | | Bạn dựa vào chức vụ hay vào quan hệ để việc được làm | |

Và điều đáng nhớ nhất về sự khác nhau giữa thẩm quyền và trí tuệ cảm xúc: thẩm quyền quyết định ai phải nghe bạn nói, còn trí tuệ cảm xúc quyết định họ có nói thật với bạn hay không.

Đáp án

B — "Quy trình kiểm soát chất lượng là việc hoàn thành phạm vi đã xác định, nơi công việc dự án cần được định hướng." (phát biểu SAI)

Vì sao đúng

⚠ Vì sao phát biểu B sai: | Lý do | Nội dung | |---|---| | ⚠ Nó mô tả quy trình CHỈ ĐẠO VÀ QUẢN LÝ CÔNG VIỆC DỰ ÁN | ⚠ nơi công việc được dẫn dắt để hoàn thành phạm vi — liên hệ #26677 lô 198 | | ⚠ Kiểm soát chất lượng KHÔNG tạo ra công việc | ⚠ nó ĐO công việc đã có | | ⚠ Kiểm soát chất lượng thuộc nhóm GIÁM SÁT VÀ KIỂM SOÁT | ⚠ không thuộc nhóm THỰC THI | | ⚠ "Hoàn thành phạm vi" là chuyện của thực thi và của xác nhận phạm vi | ⚠ liên hệ #26686 cùng lô | | ⚠ Kết luận | ⚠ B lẫn lộn giữa việc LÀM RA sản phẩm và việc KIỂM sản phẩm — đó là chỗ sai |

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

• D ("kiểm soát chất lượng là giai đoạn đường cơ sở chất lượng trong các thay đổi đã được phê duyệt") — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ câu chữ của nó lủng củng và tối nghĩa, nên rất dễ bị chọn là "câu sai" chỉ vì khó đọc: ⚠ nhưng ⚠ nội dung của nó vẫn ĐÚNG về bản chất — kiểm soát chất lượng kiểm chứng sản phẩm so với đường cơ sở chất lượng, và các thay đổi đã duyệt cũng phải được kiểm chứng ⚠ — ⚠ bài học đọc đề: câu VIẾT DỞ không đồng nghĩa với câu SAI NỘI DUNG, còn câu B đọc rất trôi chảy nhưng mô tả nhầm quy trình.

• A (ngăn ngừa sự không tuân thủ, khuyến nghị sửa lỗi, thay đổi, hành động khắc phục và phòng ngừa) — ⚠ ĐÚNG: đây là các đầu ra thật của kiểm soát chất lượng, chuyển sang kiểm soát thay đổi tích hợp.

• C (sản phẩm bàn giao phải tuân thủ các tiêu chuẩn chất lượng liên quan) — ⚠ ĐÚNG: đó chính là định nghĩa của kiểm soát chất lượng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26686 cùng lô (xác nhận phạm vi — khách nghiệm thu), ⚠ #26677 lô 198 (chỉ đạo và quản lý công việc dự án), ⚠ #26658 lô 198 (cập nhật kế hoạch bảo đảm chất lượng), ⚠ #26654 lô 198 (phép đo chất lượng), ⚠ #26679 lô 198 (chi phí thẩm định).

⚠ BA QUY TRÌNH CHẤT LƯỢNG — bảng phân biệt cốt lõi: | Quy trình | Nhóm | Câu hỏi | Đầu ra chính | |---|---|---|---| | ⚠ LẬP KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG | ⚠ Lập kế hoạch | ⚠ "chất lượng nghĩa là gì với dự án này" | ⚠ kế hoạch chất lượng, phép đo | | ⚠ QUẢN LÝ CHẤT LƯỢNG (assurance) | ⚠ Thực thi | ⚠ "QUY TRÌNH của ta có đúng không" | ⚠ báo cáo kiểm toán chất lượng, cải tiến | | ⚠ KIỂM SOÁT CHẤT LƯỢNG | ⚠ Giám sát và kiểm soát | ⚠ "SẢN PHẨM có đúng không" | ⚠ phép đo kiểm chứng, sản phẩm đã kiểm chứng | | ⚠ Cách nhớ | ⚠ bảo đảm nhìn vào QUY TRÌNH và phòng ngừa; kiểm soát nhìn vào SẢN PHẨM và phát hiện — liên hệ #26658 lô 198 | | |

⚠ Chuỗi bốn bước của một sản phẩm bàn giao: | Bước | Quy trình | Ai làm | |---|---|---| | ⚠ 1. Tạo ra sản phẩm | ⚠ Chỉ đạo và quản lý công việc dự án | ⚠ đội dự án — chính là điều phương án B mô tả nhầm | | ⚠ 2. Kiểm sản phẩm có đúng đặc tả | ⚠ KIỂM SOÁT CHẤT LƯỢNG | ⚠ đội chất lượng | | ⚠ 3. Khách hàng nghiệm thu | ⚠ Xác nhận phạm vi | ⚠ khách hàng — liên hệ #26686 cùng lô | | ⚠ 4. Bàn giao và đóng | ⚠ Đóng dự án hoặc giai đoạn | ⚠ liên hệ #26689 cùng lô | | ⚠ Sai lầm thường gặp | ⚠ gộp bước 2 và bước 3 làm một — chúng khác nhau về NGƯỜI LÀM và về CÂU HỎI được trả lời |

⚠ Đầu ra của kiểm soát chất lượng — vì sao phương án A đúng: | Đầu ra | Nội dung | |---|---| | ⚠ Phép đo kiểm soát chất lượng | ⚠ kết quả đo được, ghi lại | | ⚠ Sản phẩm bàn giao đã được kiểm chứng | ⚠ đầu vào cho xác nhận phạm vi | | ⚠ Yêu cầu thay đổi | ⚠ gồm sửa lỗi, hành động khắc phục và phòng ngừa — đúng như A mô tả | | ⚠ Thông tin hiệu năng công việc | | | ⚠ Cập nhật tài liệu và kế hoạch | | | ⚠ Điểm quan trọng | ⚠ kiểm soát chất lượng KHÔNG tự sửa lỗi — nó phát hiện và KHUYẾN NGHỊ; việc sửa quay lại nhóm thực thi sau khi thay đổi được duyệt |

Từ khoá nhận diện:

"nơi công việc được định hướng để hoàn thành phạm vi" → ⚠ chỉ đạo và quản lý công việc dự án, KHÔNG phải kiểm soát chất lượng "sản phẩm có tuân thủ tiêu chuẩn không" → ⚠ kiểm soát chất lượng "quy trình có đúng không" → ⚠ quản lý/bảo đảm chất lượng câu viết lủng củng → ⚠ không đồng nghĩa với câu sai nội dung

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai kiểm sản phẩm của bạn trước khi khách hàng nhìn thấy | | | Lỗi phát hiện được có sinh ra yêu cầu thay đổi có hồ sơ không | | | Bạn có phân biệt được kiểm quy trình và kiểm sản phẩm trong dự án mình không | |

Và điều mà một câu hỏi phủ định về kiểm soát chất lượng thật ra đang kiểm tra: bạn có phân biệt được việc LÀM RA thứ gì đó với việc BIẾT thứ đó có đúng hay không — hai việc dùng chung một cái tên "chất lượng" nhưng thuộc hai nhóm quy trình khác nhau.

Đáp án

B — HUẤN LUYỆN (coaching).

Vì sao đúng

⚠ Vì sao cuộc gặp này là huấn luyện: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Gặp MỘT–MỘT | ⚠ riêng tư, tập trung vào một người | | ⚠ Về một VẤN ĐỀ CỤ THỂ đang xảy ra | ⚠ quyết định của đội mà người này chưa thông | | ⚠ Mục đích là để người đó tự nói ra và tự tìm hướng | ⚠ không phải để dạy kiến thức | | ⚠ Diễn ra NGAY GIỮA vòng lặp, đúng lúc vấn đề còn nóng | ⚠ huấn luyện luôn gắn với tình huống hiện tại | | ⚠ Kết luận | ⚠ đối thoại một–một để tháo gỡ một vướng mắc cụ thể = huấn luyện |

⚠ Vai trò của Mike ở đây rất đúng chất scrum master: ⚠ anh không ép người đó phải theo quyết định của đội, cũng không bỏ qua sự bất đồng — anh mở một không gian riêng để hiểu vì sao.

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

• D (cố vấn — mentoring) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cố vấn cũng là quan hệ một–một, cũng mang tính hỗ trợ và phát triển con người: ⚠ nhưng ⚠ cố vấn hướng tới SỰ NGHIỆP DÀI HẠN và dựa trên kinh nghiệm của người cố vấn, còn huấn luyện hướng tới MỘT VẤN ĐỀ CỤ THỂ NGAY BÂY GIỜ ⚠ — ⚠ ở đây có một quyết định cụ thể trong một vòng lặp cụ thể đang gây vướng, nên nó là huấn luyện; ⚠ mẹo phân biệt: cố vấn hỏi "em muốn đi tới đâu trong ba năm tới", huấn luyện hỏi "chuyện gì đang khiến anh chưa thoải mái với quyết định này".

• A (chỉ đạo — directing) — ⚠ là bảo người ta phải làm gì; ⚠ trái với tinh thần agile và trái với việc "thảo luận" mà đề nêu.

• C (đào tạo — training) — ⚠ truyền đạt KIẾN THỨC hoặc KỸ NĂNG mới, thường theo nhóm và có giáo trình; ⚠ ở đây không ai thiếu kiến thức.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26658 lô 198 và ⚠ #26660 lô 198 (kèm cặp — shadowing), ⚠ #26719 cùng lô (mục tiêu của chương trình cố vấn trong OPM), ⚠ #26700 cùng lô (hồi cứu là để cải tiến, không phải để đổ lỗi), ⚠ #26675 lô 198 (xung đột mang tính xây dựng), ⚠ #26676 lô 198 (đưa thành viên vào việc ra quyết định).

⚠ BỐN KIỂU CAN THIỆP với con người — bảng phân biệt: | Kiểu | Trọng tâm | Thời gian | Ai nói nhiều | |---|---|---|---| | ⚠ CHỈ ĐẠO (directing) | ⚠ việc phải làm | ⚠ ngay lập tức | ⚠ người dẫn dắt | | ⚠ ĐÀO TẠO (training) | ⚠ kiến thức, kỹ năng | ⚠ có giáo trình, theo lịch | ⚠ người dạy | | ⚠ HUẤN LUYỆN (coaching) | ⚠ một vấn đề cụ thể, hiệu suất hiện tại — ĐÁP ÁN | ⚠ ngắn hạn, gắn tình huống | ⚠ NGƯỜI ĐƯỢC HUẤN LUYỆN | | ⚠ CỐ VẤN (mentoring) | ⚠ con đường sự nghiệp, phát triển dài hạn | ⚠ kéo dài nhiều tháng, nhiều năm | ⚠ cả hai, người cố vấn chia sẻ kinh nghiệm | | ⚠ Điểm phân biệt then chốt | ⚠ huấn luyện hỏi để người kia TỰ TÌM RA câu trả lời; cố vấn KỂ LẠI kinh nghiệm của mình; đào tạo TRUYỀN ĐẠT nội dung; chỉ đạo RA LỆNH |

⚠ Mike nên làm gì trong cuộc gặp đó: | Việc | Nội dung | |---|---| | ⚠ Hỏi và LẮNG NGHE trước | ⚠ "điều gì khiến anh chưa yên tâm với quyết định này" | | ⚠ Tìm hiểu đó là bất đồng về KỸ THUẬT hay về CẢM XÚC | ⚠ hai loại này cần hai cách xử lý khác nhau | | ⚠ Kiểm xem có thông tin nào đội chưa biết không | ⚠ người phản đối đôi khi là người duy nhất nhìn thấy rủi ro | | ⚠ Nếu là mối lo chính đáng, đưa lại ra đội | ⚠ không phải để lật quyết định, mà để đội biết | | ⚠ Nếu là chuyện cảm xúc, giúp họ nói ra và được ghi nhận | | | ⚠ Điều KHÔNG nên làm | ⚠ thuyết phục người đó im lặng để giữ hoà khí — một mối lo bị dập tắt sẽ quay lại dưới dạng công việc bị trì hoãn hoặc chất lượng đi xuống, và lúc đó không ai truy được nguyên nhân |

⚠ Vì sao xử lý ngay giữa vòng lặp là đúng: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề còn nhỏ và còn nóng | ⚠ liên hệ #26648 lô 198 — xử lý sớm | | ⚠ Chờ tới buổi hồi cứu thì đã trễ một vòng lặp | ⚠ và có thể đã ảnh hưởng tới công việc | | ⚠ Bất đồng không nói ra sẽ hoá thành sự rút lui thầm lặng | ⚠ liên hệ #26537 lô 196 — sợ xung đột | | ⚠ Gặp riêng bảo vệ được thể diện của người đó trước đội | | | ⚠ Nguyên tắc | ⚠ khen trước đội, góp ý riêng — và đặc biệt, một mối bất đồng cá nhân thì bàn riêng trước rồi mới quyết định có cần đưa ra tập thể hay không |

Từ khoá nhận diện:

"gặp riêng về một vấn đề cụ thể đang xảy ra" → ⚠ HUẤN LUYỆN "phát triển sự nghiệp dài hạn" → ⚠ cố vấn "truyền đạt kiến thức, kỹ năng mới" → ⚠ đào tạo "bảo phải làm gì" → ⚠ chỉ đạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong cuộc gặp một–một gần nhất, ai nói nhiều hơn | ⚠ nếu là bạn, đó không phải huấn luyện | | Có ai trong đội đang im lặng không đồng ý không | | | Bạn phát hiện bất đồng bằng cách nào — chờ họ nói hay chủ động hỏi | |

Và điều mà một cuộc trò chuyện riêng đúng lúc thường mang lại: không phải là việc thuyết phục người đó đồng ý, mà là việc phát hiện ra rằng cả đội đã bỏ sót đúng điều mà người đó nhìn thấy.

Đáp án

C — MỘT NĂM.

Vì sao đúng

⚠ Tính từng bước: | Bước | Phép tính | Kết quả | |---|---|---| | ⚠ Tồn đọng còn lại | ⚠ 459 điểm | ⚠ 459 | | ⚠ Cộng yêu cầu mới của chủ sản phẩm | ⚠ 459 + 12 | ⚠ 471 điểm | | ⚠ Số vòng lặp cần | ⚠ 471 ÷ 36 | ⚠ 13,08 → khoảng 13 vòng lặp | | ⚠ Đổi ra tuần | ⚠ 13 × 4 tuần | ⚠ 52 tuần | | ⚠ Đổi ra năm | ⚠ 52 tuần | ⚠ ĐÚNG MỘT NĂM | | ⚠ Kiểm lại không cộng 12 điểm | ⚠ 459 ÷ 36 = 12,75 → 13 vòng lặp → 52 tuần | ⚠ vẫn ra một năm |

⚠ Con số rất "sạch" — đó là dấu hiệu người ra đề muốn bạn tới đúng mốc này: ⚠ cả khi cộng và khi không cộng yêu cầu mới, kết quả đều là 13 vòng lặp và 52 tuần; ⚠ 13,08 vòng lặp về mặt chặt chẽ sẽ cần vòng thứ 14 để dọn nốt 3 điểm dư, nhưng trong bốn phương án được đưa ra thì "một năm" là con số duy nhất đúng cỡ.

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

• D (13 tuần) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ con số 13 xuất hiện thật trong phép tính, và người vội vàng sẽ lấy ngay 471 ÷ 36 ≈ 13 rồi gắn luôn đơn vị "tuần": ⚠ nhưng ⚠ 13 là số VÒNG LẶP, mà mỗi vòng lặp dài BỐN TUẦN ⚠ — ⚠ quên nhân 4 là lỗi phổ biến nhất ở dạng bài này, và đề cố ý đặt sẵn con số 13 vào phương án để bắt lỗi đó; ⚠ luôn viết rõ đơn vị của từng con số khi tính.

• A (36 tuần) — ⚠ lấy nhầm VẬN TỐC (36 điểm/vòng) làm số tuần; ⚠ hai đại lượng khác đơn vị hoàn toàn.

• B (không thể xác định được) — ⚠ đề đã cho đủ ba dữ kiện: tồn đọng, vận tốc, độ dài vòng lặp; ⚠ trong đề PMP, phương án "không đủ thông tin" gần như luôn sai khi các con số đã được cho đầy đủ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26709 cùng lô (định nghĩa vận tốc), ⚠ #26702 cùng lô và ⚠ #26725 cùng lô (cùng bối cảnh scrum, vận tốc nêu trong đề), ⚠ #26614 lô 197 (tính số tháng hoàn vốn), ⚠ #26729 cùng lô (biểu đồ burndown — công cụ trực quan cho chính phép tính này).

⚠ CÔNG THỨC DỰ BÁO BẰNG VẬN TỐC: | Đại lượng | Công thức | |---|---| | ⚠ Số vòng lặp còn lại | ⚠ tổng điểm tồn đọng ÷ vận tốc | | ⚠ Thời gian còn lại | ⚠ số vòng lặp × ĐỘ DÀI mỗi vòng lặp | | ⚠ Ngày hoàn thành dự kiến | ⚠ hôm nay + thời gian còn lại | | ⚠ Ba chỗ hay sai | ⚠ (1) quên nhân độ dài vòng lặp; (2) quên cộng các hạng mục mới thêm vào tồn đọng; (3) dùng vận tốc của MỘT vòng tốt nhất thay vì vận tốc TRUNG BÌNH |

⚠ Vì sao dự báo bằng vận tốc chỉ đáng tin có điều kiện: | Điều kiện | Nội dung | |---|---| | ⚠ Vận tốc phải ỔN ĐỊNH qua vài vòng lặp | ⚠ ở đây đội đã chạy bốn vòng — vừa đủ để trung bình có nghĩa | | ⚠ Đội không thay đổi thành viên | ⚠ thêm hay bớt người là vận tốc đổi | | ⚠ Cách ước lượng điểm không đổi | ⚠ điểm là đơn vị tương đối của riêng đội đó | | ⚠ Tồn đọng phải được ước lượng hết | ⚠ hạng mục chưa ước lượng không nằm trong phép chia | | ⚠ Điều chắc chắn sẽ xảy ra | ⚠ chủ sản phẩm sẽ tiếp tục thêm hạng mục mới — như chính đề vừa mô tả với 12 điểm; nên con số "một năm" là dự báo theo tồn đọng HÔM NAY, không phải lời hứa về ngày kết thúc |

⚠ Cách trình bày dự báo này với bên liên quan: | Nên | Không nên | |---|---| | ⚠ "Với tồn đọng hiện tại và vận tốc hiện tại, khoảng 13 vòng lặp — tức một năm" | ⚠ "Dự án sẽ xong vào ngày X" | | ⚠ Nêu rõ giả định: vận tốc giữ nguyên, tồn đọng không tăng | ⚠ giấu giả định đi | | ⚠ Cập nhật lại sau mỗi vòng lặp | ⚠ báo một lần rồi thôi | | ⚠ Dùng biểu đồ burndown để mọi người tự thấy | ⚠ liên hệ #26729 cùng lô | | ⚠ Ghi nhớ | ⚠ mỗi hạng mục mới được đưa lên đầu tồn đọng đều đẩy ngày kết thúc ra xa — và cách tốt nhất để chủ sản phẩm hiểu điều đó là cho họ thấy phép tính, chứ không phải tranh luận về nó |

Từ khoá nhận diện:

"tồn đọng ÷ vận tốc" → ⚠ ra SỐ VÒNG LẶP, chưa phải thời gian "× độ dài vòng lặp" → ⚠ bước bắt buộc, hay bị quên nhất "cộng hạng mục mới vào tồn đọng" → ⚠ đọc kỹ, đề cố ý thêm vào "không thể xác định" → ⚠ gần như luôn sai khi đề đã cho đủ số

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vận tốc bạn dùng là trung bình mấy vòng | ⚠ một vòng thì chưa đủ | | Toàn bộ tồn đọng của bạn đã được ước lượng chưa | | | Bên liên quan có biết dự báo dựa trên giả định nào không | |

Và điều mà phép chia 471 cho 36 thật sự nói với chủ sản phẩm: mỗi lần thêm một hạng mục vào đầu danh sách, ai đó ở cuối danh sách phải chờ thêm — và con số một năm là cách duy nhất để biến sự đánh đổi ấy thành thứ nhìn thấy được.

Đáp án

C — NHẮC CẢ ĐỘI RẰNG BUỔI HỒI CỨU LÀ ĐỂ CẢI TIẾN, KHÔNG PHẢI ĐỂ QUY TRÁCH NHIỆM.

Vì sao đúng

⚠ Vì sao đây là việc đúng của scrum master: | Lý do | Nội dung | |---|---| | ⚠ Scrum master là người GIỮ QUY TRÌNH và bảo vệ không gian an toàn | ⚠ can thiệp khi buổi họp đi chệch mục đích | | ⚠ Hồi cứu tồn tại để cải thiện CÁCH LÀM VIỆC | ⚠ không phải để tìm ra ai có lỗi | | ⚠ Đội còn mới với agile và chưa từng làm việc cùng nhau | ⚠ đang ở giai đoạn SÓNG GIÓ — cần được nhắc lại luật chơi | | ⚠ Can thiệp NGAY, ngay trong buổi họp | ⚠ để không ai mang cảm giác bị buộc tội ra về | | ⚠ Nói với CẢ ĐỘI, không nhắm vào hai người | ⚠ giữ thể diện, đồng thời thiết lập chuẩn mực chung | | ⚠ Kết luận | ⚠ chuyển câu hỏi từ "lỗi tại ai" sang "quy trình nào đã để chuyện đó xảy ra" |

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

• D (không làm gì, đội tự chịu trách nhiệm về buổi hồi cứu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ agile đúng là đề cao đội TỰ QUẢN, và scrum master không nên can thiệp vào nội dung thảo luận của đội: ⚠ nhưng ⚠ tự quản áp dụng cho NỘI DUNG công việc, không áp dụng cho việc để một buổi họp biến thành cuộc đổ lỗi ⚠ — ⚠ và đề nói rõ đội MỚI với agile, chưa từng làm việc cùng nhau, nên chưa hình thành được chuẩn mực để tự điều chỉnh; ⚠ lãnh đạo phục vụ không có nghĩa là đứng nhìn.

• A (khiển trách cả hai) — ⚠ chính là hành vi quy trách nhiệm mà buổi hồi cứu cần tránh; ⚠ nó xác nhận rằng nơi này đúng là nơi để phán xét.

• B (báo lên quản lý chức năng của họ) — ⚠ leo thang quá mức cho một cuộc tranh cãi trong họp; ⚠ nó phá huỷ an toàn tâm lý của cả đội ngay lập tức.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26537 lô 196 và ⚠ #26469 lô 194 (năm rối loạn của Lencioni), ⚠ #26675 lô 198 (xung đột xây dựng), ⚠ #26698 cùng lô (huấn luyện một–một sau khi lập lại trật tự), ⚠ #26704 cùng lô (mục đích thật của hồi cứu), ⚠ #26639 lô 198 (tập trung vào hệ thống thay vì cá nhân).

⚠ HỒI CỨU — bốn nguyên tắc nền: | Nguyên tắc | Nội dung | |---|---| | ⚠ Chỉ thị chính (prime directive) | ⚠ "tin rằng mọi người đã làm tốt nhất có thể với thông tin và nguồn lực họ có lúc đó" | | ⚠ Nhìn HỆ THỐNG, không nhìn CÁ NHÂN | ⚠ hỏi "quy trình nào cho phép chuyện này xảy ra" | | ⚠ Kết quả phải là HÀNH ĐỘNG CỤ THỂ | ⚠ có người chịu trách nhiệm, có hạn — nếu không thì buổi họp chỉ là than phiền | | ⚠ AN TOÀN TÂM LÝ là điều kiện tiên quyết | ⚠ không an toàn thì không ai nói ra sự thật, và buổi hồi cứu thành vô dụng | | ⚠ Vì sao chỉ thị chính lại được đọc to ở đầu buổi | ⚠ nó là lời cam kết công khai rằng buổi này không phải phiên toà — và với một đội mới, việc đọc nó lên có tác dụng thật, không phải nghi thức |

⚠ Samantha nên xử lý theo thứ tự nào: | Bước | Việc | |---|---| | ⚠ 1. Dừng cuộc tranh cãi ngay, nhẹ nhàng | ⚠ không để leo thang trước mặt cả đội | | ⚠ 2. Nhắc lại mục đích của buổi hồi cứu | ⚠ ĐÁP ÁN — nói với cả đội, không chỉ hai người | | ⚠ 3. Chuyển câu hỏi sang hệ thống | ⚠ "nhiệm vụ đó đã đi chệch ở chỗ nào trong quy trình của chúng ta" | | ⚠ 4. Ghi lại hành động cải tiến cụ thể | | | ⚠ 5. Gặp riêng hai người SAU buổi họp nếu cần | ⚠ liên hệ #26698 cùng lô — huấn luyện một–một | | ⚠ Vì sao bước 5 quan trọng | ⚠ việc lập lại trật tự trong phòng họp không giải quyết được mâu thuẫn giữa hai người; nó chỉ đảm bảo mâu thuẫn đó không lây sang cả đội — phần còn lại phải xử lý riêng |

⚠ Đội mới với agile — vì sao xung đột kiểu này là bình thường: | Lý do | Nội dung | |---|---| | ⚠ Đội đang ở giai đoạn SÓNG GIÓ của Tuckman | ⚠ va chạm là dấu hiệu của tiến triển, không phải thất bại | | ⚠ Chưa có chuẩn mực chung về cách nói về sai sót | ⚠ liên hệ #26683 cùng lô — quy tắc ứng xử | | ⚠ Người quen môi trường truyền thống mang theo phản xạ tìm người chịu trách nhiệm | | | ⚠ Minh bạch của agile khiến sai sót lộ ra rõ hơn | ⚠ và đội chưa quen với việc đó | | ⚠ Việc của scrum master | ⚠ dạy đội cách nói về sai sót mà không nói về người — đó là kỹ năng phải học, không phải bản năng; và một đội học được kỹ năng đó chính là một đội bước qua được giai đoạn sóng gió |

Từ khoá nhận diện:

"cãi nhau xem lỗi tại ai trong buổi hồi cứu" → ⚠ NHẮC LẠI MỤC ĐÍCH: cải tiến, không quy tội "khiển trách" → ⚠ chính là hành vi cần tránh "báo lên quản lý chức năng" → ⚠ leo thang phá huỷ an toàn tâm lý "đội tự chịu trách nhiệm nên không can thiệp" → ⚠ tự quản không có nghĩa là bỏ mặc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi hồi cứu gần nhất của bạn kết thúc bằng hành động hay bằng cảm giác | | | Có ai im lặng suốt buổi không | ⚠ im lặng thường là dấu hiệu thiếu an toàn | | Khi có sự cố, câu hỏi đầu tiên của đội bạn là "ai" hay "cái gì" | |

Và điều mà một câu nhắc đúng lúc của Samantha bảo vệ được: không phải hai người đang cãi nhau, mà là tất cả những người còn lại đang lặng lẽ quyết định xem lần sau có nên nói ra sai sót của mình hay không.

Đáp án

D — BẮT ĐẦU–BẮT ĐẦU (start-to-start, SS).

Vì sao đúng

⚠ Đọc thẳng từ đề: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ "lắp tủ lạnh BẮT ĐẦU CÙNG LÚC với lắp tủ đông" | ⚠ hai việc cùng khởi động | | ⚠ Ràng buộc nằm ở điểm BẮT ĐẦU của cả hai | ⚠ không nói gì tới điểm kết thúc | | ⚠ Việc sau không phải chờ việc trước xong | ⚠ loại FS ngay | | ⚠ Kết luận | ⚠ việc B bắt đầu khi việc A bắt đầu = quan hệ SS |

⚠ Cách đọc tên bốn quan hệ: ⚠ chữ ĐẦU nói về việc TRƯỚC (predecessor), chữ SAU nói về việc SAU (successor) ⚠ — ⚠ "start-to-start" = việc trước BẮT ĐẦU thì việc sau mới được BẮT ĐẦU; ⚠ nắm quy ước này thì bốn quan hệ không bao giờ lẫn nữa.

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

• B (kết thúc–kết thúc, FF) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là quan hệ mô tả hai việc chạy SONG SONG, giống hệt hình dung trực quan về hai chiếc tủ được lắp cùng lúc: ⚠ nhưng ⚠ FF ràng buộc điểm KẾT THÚC — "việc sau không thể xong trước khi việc trước xong" ⚠ — ⚠ còn đề nói rõ ràng buộc nằm ở điểm BẮT ĐẦU; ⚠ hai việc song song có thể ràng buộc ở đầu, ở cuối, hoặc cả hai — phải đọc đúng chữ trong đề.

• A (kết thúc–bắt đầu, FS) — ⚠ quan hệ phổ biến nhất: việc trước xong thì việc sau mới bắt đầu; ⚠ trái với đề.

• C (bắt đầu–kết thúc, SF) — ⚠ hiếm nhất: việc trước bắt đầu thì việc sau mới được kết thúc; ⚠ điển hình là ca trực mới tới thì ca cũ mới được về.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26666 lô 198 (độ trễ — lag), ⚠ #26563 lô 196 (fast-tracking và rút ngắn tiến độ), ⚠ #26712 cùng lô (san bằng nguồn lực làm tiến độ dài ra), ⚠ #26685 cùng lô (điều phối nguồn lực dùng chung), ⚠ #26653 lô 198 (mức sẵn có của nguồn lực).

⚠ BỐN QUAN HỆ LOGIC trong sơ đồ ưu tiên (PDM): | Quan hệ | Nghĩa | Ví dụ | |---|---|---| | ⚠ FS — kết thúc–bắt đầu | ⚠ A xong thì B mới bắt đầu | ⚠ đổ móng xong mới xây tường — phổ biến nhất, chiếm phần lớn tiến độ | | ⚠ SS — bắt đầu–bắt đầu | ⚠ A bắt đầu thì B mới bắt đầu — ĐÁP ÁN | ⚠ lắp tủ lạnh và tủ đông cùng lúc; đổ bê tông và san phẳng mặt | | ⚠ FF — kết thúc–kết thúc | ⚠ A xong thì B mới xong | ⚠ viết mã và viết tài liệu — tài liệu không xong trước khi mã xong | | ⚠ SF — bắt đầu–kết thúc | ⚠ A bắt đầu thì B mới được xong | ⚠ ca trực mới bắt đầu thì ca cũ mới kết thúc — rất hiếm | | ⚠ Mẹo nhớ | ⚠ đọc từ trái sang phải: vế đầu là việc TRƯỚC, vế sau là việc SAU — "start-to-start" nghĩa là "bắt đầu (của việc trước) dẫn tới bắt đầu (của việc sau)" |

⚠ Vì sao Jonette dùng SS ở đây là hợp lý: | Lý do | Nội dung | |---|---| | ⚠ Hai thiết bị độc lập về kỹ thuật | ⚠ không cái nào cần cái kia xong trước | | ⚠ Cùng một đội thợ, cùng một khu vực bếp | ⚠ tổ chức làm cùng lúc thì hiệu quả hơn | | ⚠ Rút ngắn tổng thời gian | ⚠ song song thay vì nối tiếp | | ⚠ Cùng cần nguồn điện và đường ống lắp sẵn | ⚠ điều kiện chung, nên khởi động chung | | ⚠ Điều cần để ý | ⚠ quan hệ SS cho phép hai việc kết thúc ở thời điểm khác nhau — nếu Jonette cũng cần chúng xong cùng lúc thì phải thêm cả ràng buộc FF, hai quan hệ này dùng chung được |

⚠ Độ trễ (lag) và độ sớm (lead) đi kèm quan hệ: | Khái niệm | Nghĩa | Ví dụ với SS | |---|---|---| | ⚠ ĐỘ TRỄ (lag) | ⚠ bắt buộc CHỜ thêm | ⚠ "SS + 2 ngày": tủ đông bắt đầu hai ngày sau khi tủ lạnh bắt đầu | | ⚠ ĐỘ SỚM (lead) | ⚠ cho phép việc sau bắt đầu SỚM hơn | ⚠ "FS − 3 ngày": việc sau khởi động trước khi việc trước xong ba ngày | | ⚠ Ghi nhớ | ⚠ liên hệ #26666 lô 198 — độ trễ là thời gian bắt buộc trôi qua, không phải thời gian làm việc; đừng lẫn nó với thời lượng của một hoạt động |

Từ khoá nhận diện:

"bắt đầu cùng lúc" → ⚠ BẮT ĐẦU–BẮT ĐẦU (SS) "phải xong cùng lúc / không xong trước" → ⚠ kết thúc–kết thúc (FF) "xong cái này mới làm cái kia" → ⚠ kết thúc–bắt đầu (FS) "ca trực nối nhau" → ⚠ bắt đầu–kết thúc (SF), hiếm gặp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiến độ của bạn có quan hệ nào ngoài FS không | ⚠ toàn FS thường là dấu hiệu chưa tìm cơ hội chạy song song | | Các quan hệ SS trong tiến độ có ràng buộc kết thúc không | | | Độ trễ trong tiến độ của bạn có được giải thích lý do không | |

Và điều mà việc chọn đúng loại quan hệ quyết định: hai chiếc tủ lắp cùng lúc hay lắp nối nhau chỉ khác nhau một chữ trong sơ đồ — nhưng đó là chữ quyết định bản tiến độ của bạn dài thêm bao nhiêu ngày.

Đáp án

B — HỌP VỚI QUẢN LÝ ĐỘI VẬN HÀNH VÀ CHỦ SẢN PHẨM để giải quyết vấn đề.

Vì sao đúng

⚠ Vì sao đây là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Vướng mắc nằm với một đội BÊN NGOÀI đội dự án | ⚠ đội của Carrie không tự gỡ được | | ⚠ Quản lý đội vận hành là người có thẩm quyền với đội đó | ⚠ đi thẳng tới nơi có quyền quyết định | | ⚠ Chủ sản phẩm có tiếng nói về ưu tiên và định nghĩa hoàn thành | ⚠ đúng nội dung đang tranh cãi | | ⚠ Scrum master có nhiệm vụ GỠ VẬT CẢN cho đội | ⚠ đây là định nghĩa công việc của cô | | ⚠ Vấn đề đang làm CHẬM công việc | ⚠ cần giải quyết ở cấp có thẩm quyền, không chỉ bàn nội bộ | | ⚠ Kết luận | ⚠ đưa đúng người vào một phòng: người có quyền với đội vận hành và người có quyền với sản phẩm |

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

• C (bàn với đội dự án để cùng tìm giải pháp) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "để đội tự giải quyết" là phản xạ agile đúng trong hầu hết tình huống, và nó tôn trọng tính tự quản: ⚠ nhưng ⚠ vật cản này nằm NGOÀI tầm kiểm soát của đội — đội không thể tự quyết định thay cho đội vận hành ⚠ — ⚠ đội đã nêu mối lo rồi, và việc bàn thêm với nhau chỉ tạo cảm giác đang xử lý mà không thay đổi được gì; ⚠ tự quản áp dụng cho việc TRONG tầm tay đội, gỡ vật cản BÊN NGOÀI là việc của scrum master.

• A (yêu cầu chuyển người "khó tính" của đội vận hành đi chỗ khác) — ⚠ quy vấn đề về CON NGƯỜI thay vì về quy trình; ⚠ vượt thẩm quyền, phá quan hệ, và gần như chắc chắn không giải quyết được nguyên nhân thật.

• D (leo thang lên ban chỉ đạo và chủ sản phẩm) — ⚠ leo thang QUÁ SỚM; ⚠ chưa thử con đường trực tiếp mà đã lên ban chỉ đạo là cách nhanh nhất làm hỏng quan hệ với đội vận hành — liên hệ #26621 lô 197.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26621 lô 197 (gặp người phụ trách trước khi leo thang), ⚠ #26680 lô 198 (nói chuyện với quản lý chức năng trước), ⚠ #26651 lô 198 (định nghĩa hoàn thành), ⚠ #26533 lô 196 (thoả thuận với bộ phận dùng chung), ⚠ #26673 lô 198 (gặp cả hai bên để hoà giải).

⚠ THANG LEO THANG chuẩn cho một vật cản liên bộ phận: | Bậc | Việc | Khi nào | |---|---|---| | ⚠ 1. Đội tự xử lý | ⚠ nếu vật cản nằm trong tầm tay đội | ⚠ không phải ca này | | ⚠ 2. Scrum master gặp bên liên quan trực tiếp | ⚠ quản lý đội vận hành + chủ sản phẩm — ĐÁP ÁN | ⚠ ca này | | ⚠ 3. Thoả thuận cách làm việc chung và ghi lại | ⚠ định nghĩa hoàn thành chung, thời gian phản hồi cam kết | | | ⚠ 4. Leo thang lên nhà tài trợ hoặc ban chỉ đạo | ⚠ chỉ khi bậc 2 và 3 đã thử mà không xong | ⚠ phương án D thuộc bậc này | | ⚠ Nguyên tắc | ⚠ leo thang là công cụ, không phải thất bại — nhưng leo thang khi chưa thử nói chuyện thì bạn vừa không giải quyết được vấn đề vừa mất một đồng minh |

⚠ Bàn gì trong cuộc họp ba bên: | Nội dung | Vì sao | |---|---| | ⚠ Thống nhất ĐỊNH NGHĨA HOÀN THÀNH cho các tính năng | ⚠ đây là nội dung đang tranh cãi — liên hệ #26651 lô 198 | | ⚠ Ai duyệt cái gì và trong bao lâu | ⚠ cam kết thời gian phản hồi cụ thể | | ⚠ Đội vận hành cần gì để làm việc được | ⚠ có thể họ đang thiếu thông tin hoặc thiếu người | | ⚠ Ưu tiên: việc này đứng ở đâu trong danh sách của họ | ⚠ chủ sản phẩm có thể thương lượng phần này | | ⚠ Cách phối hợp cho các vòng lặp sau | ⚠ giải quyết một lần cho nhiều lần | | ⚠ Mục tiêu thật của cuộc họp | ⚠ không phải để đội vận hành nhượng bộ, mà để hai bên thấy được ràng buộc của nhau — họ có thể đang chịu áp lực từ một phía mà đội của Carrie không nhìn thấy |

⚠ Vì sao đội vận hành thường là vật cản kinh điển trong agile: | Nguyên nhân | Nội dung | |---|---| | ⚠ Họ chạy theo nhịp khác — sự cố và yêu cầu đến bất chợt | ⚠ không có vòng lặp cố định như đội phát triển | | ⚠ Ưu tiên của họ do bộ phận khác đặt ra | | | ⚠ Mục tiêu của họ là ỔN ĐỊNH, của đội phát triển là THAY ĐỔI | ⚠ hai mục tiêu tự nhiên căng nhau | | ⚠ Họ thường không có mặt trong buổi lập kế hoạch vòng lặp | ⚠ nên cam kết được đưa ra mà không có họ | | ⚠ Hướng giải quyết dài hạn | ⚠ mời đại diện vận hành tham gia từ lúc lập kế hoạch, và đưa yêu cầu của họ vào chính định nghĩa hoàn thành — đó là tinh thần DevOps, và nó rẻ hơn nhiều so với việc thương lượng lại ở cuối mỗi vòng lặp |

Từ khoá nhận diện:

"vật cản nằm ở bộ phận khác" → ⚠ SCRUM MASTER GẶP QUẢN LÝ BỘ PHẬN ĐÓ "bàn tiếp với đội mình" → ⚠ không giải quyết được thứ ngoài tầm đội "yêu cầu chuyển người khó tính đi" → ⚠ quy vấn đề về con người, vượt thẩm quyền "lên ban chỉ đạo ngay" → ⚠ leo thang quá sớm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vật cản gần nhất của đội bạn nằm trong hay ngoài tầm tay đội | | | Bạn có biết ai là người quyết định ở bộ phận đang cản bạn không | | | Định nghĩa hoàn thành của bạn có được bộ phận vận hành đồng ý không | |

Và điều mà một cuộc họp ba bên thường phát hiện ra: đội vận hành không cố tình cản đường — họ đang cân đúng loại áp lực mà đội của Carrie cũng đang chịu, chỉ là từ một phía khác mà không ai nói cho ai biết.