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

Đáp án

B — CẬP NHẬT SỔ VẤN ĐỀ (update the issue log).

Vì sao đúng

⚠ Vì sao phải cập nhật chứ không xoá: | Lý do | Nội dung | |---|---| | ⚠ Đánh dấu trạng thái ĐÃ ĐÓNG, ghi ngày và cách giải quyết | ⚠ hồ sơ đầy đủ | | ⚠ Giữ lại LỊCH SỬ để tra cứu về sau | ⚠ vấn đề tương tự có thể tái diễn | | ⚠ Là nguồn cho bài học kinh nghiệm | ⚠ liên hệ #26925 lô 203 | | ⚠ Tạo vết kiểm toán | | | ⚠ Cho biết vấn đề đã mất bao lâu để giải quyết | ⚠ dữ liệu hữu ích cho dự án sau | | ⚠ Kết luận | ⚠ sổ vấn đề là tài liệu SỐNG có lịch sử, không phải danh sách việc cần làm |

⚠ Chú ý: ⚠ "cập nhật" không có nghĩa là chỉ tích một ô ⚠ — ⚠ nó gồm ghi rõ vấn đề đã được giải quyết THẾ NÀO, bởi ai, và mất bao lâu.

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

• A (cập nhật bảng Kanban) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đây là dự án LAI nên có bảng Kanban thật, và nếu việc xử lý vấn đề được theo dõi trên bảng thì đúng là cần cập nhật ở đó nữa: ⚠ nhưng ⚠ câu hỏi hỏi rõ "làm gì với SỔ VẤN ĐỀ" khi vấn đề được giải quyết ⚠; ⚠ bảng Kanban theo dõi CÔNG VIỆC đang chạy, còn sổ vấn đề lưu HỒ SƠ các vấn đề của dự án — hai công cụ khác nhau, và cập nhật cái này không thay được cái kia; ⚠ đây là dạng bẫy trả lời một câu hỏi khác với câu hỏi được đặt ra.

• C (xoá vấn đề đã giải quyết khỏi sổ) — ⚠ mất toàn bộ lịch sử; ⚠ và không còn cách nào biết vấn đề này đã từng xảy ra.

• D (xoá cả sổ vấn đề) — ⚠ vô lý; ⚠ sổ vấn đề tồn tại suốt vòng đời dự án và được lưu trữ khi đóng dự án — liên hệ #26984 lô 205.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27033 lô 206 (cập nhật sổ vấn đề để ngăn tái diễn), ⚠ #26925 lô 203 (sổ bài học kinh nghiệm), ⚠ #26984 lô 205 (lưu trữ hồ sơ khi đóng dự án), ⚠ #27002 lô 205 (ghi nhận cả quyết định từ chối).

⚠ Một mục trong sổ vấn đề, vòng đời đầy đủ: | Giai đoạn | Nội dung ghi | |---|---| | ⚠ Khi phát hiện | ⚠ mô tả, ngày, người phát hiện, mức ưu tiên | | ⚠ Khi phân công | ⚠ người chịu trách nhiệm, hạn xử lý | | ⚠ Trong quá trình xử lý | ⚠ cập nhật tiến triển | | ⚠ Khi ĐÓNG | ⚠ cách giải quyết, ngày đóng, kết quả — bước của câu này | | ⚠ Khi đóng dự án | ⚠ lưu trữ toàn bộ sổ | | ⚠ Trường có giá trị nhất về lâu dài | ⚠ CÁCH GIẢI QUYẾT — vì lần sau gặp vấn đề tương tự, đó là thứ duy nhất tiết kiệm được thời gian; một mục chỉ ghi "đã đóng" thì gần như vô dụng cho tương lai |

⚠ Vì sao không được xoá dữ liệu lịch sử: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề tương tự sẽ tái diễn | ⚠ liên hệ #27033 lô 206 | | ⚠ Cần cho phân tích xu hướng | ⚠ loại vấn đề nào hay xảy ra nhất | | ⚠ Cần cho kiểm toán và tranh chấp | | | ⚠ Người tiếp quản dự án cần đọc | ⚠ liên hệ #26949 lô 204 | | ⚠ Nguyên tắc chung của mọi sổ trong dự án | ⚠ chỉ THÊM và CẬP NHẬT, không bao giờ XOÁ — nếu một mục nhập sai thì đánh dấu là sai và ghi lý do, chứ không xoá đi như thể nó chưa từng tồn tại |

⚠ Sổ vấn đề trong dự án lai: | Yếu tố | Nội dung | |---|---| | ⚠ Vẫn dùng sổ vấn đề như dự án dự đoán | | | ⚠ Vật cản trong chặng thì lên bảng Kanban | ⚠ liên hệ #27027 lô 205 | | ⚠ Vấn đề kéo dài hoặc vượt tầm đội thì vào sổ | | | ⚠ Ranh giới thực dụng | ⚠ thứ giải quyết trong ngày thì để trên bảng; thứ cần theo dõi qua nhiều chặng và có người ngoài đội liên quan thì vào sổ vấn đề — hai công cụ bổ sung nhau chứ không thay thế nhau |

Từ khoá nhận diện:

"vấn đề đã được giải quyết" → ⚠ CẬP NHẬT sổ vấn đề, ghi cách giải quyết "cập nhật bảng Kanban" → ⚠ trả lời một câu hỏi khác "xoá mục đã giải quyết" → ⚠ mất lịch sử "xoá cả sổ" → ⚠ sổ tồn tại suốt vòng đời và được lưu trữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ vấn đề của bạn có ghi CÁCH giải quyết không | | | Bạn có xoá mục nào khỏi sổ bao giờ chưa | | | Có loại vấn đề nào lặp lại nhiều lần trong sổ không | |

Và giá trị thật của một sổ vấn đề, chỉ hiện ra rất lâu sau khi vấn đề đã hết: nó trả lời câu hỏi "chuyện này đã từng xảy ra chưa, và lần trước ta đã làm gì" — câu hỏi mà mọi dự án đều hỏi và ít dự án trả lời được.

Đáp án

A — NỢ KỸ THUẬT (technical debt).

Vì sao đúng

⚠ Vì sao nợ kỹ thuật làm chi phí tăng dần: | Cơ chế | Nội dung | |---|---| | ⚠ Mã chưa được dọn dẹp làm mọi việc sau chậm hơn | ⚠ "lãi" của khoản nợ | | ⚠ Mỗi chặng phải làm việc trên nền ngày càng phức tạp | | | ⚠ Lỗi phát sinh nhiều hơn, tốn công sửa | | | ⚠ Cùng một lượng tính năng nhưng tốn nhiều giờ hơn | ⚠ nên chi phí tăng dần | | ⚠ Xu hướng TĂNG DẦN chứ không nhảy vọt | ⚠ khớp với mô tả của đề | | ⚠ Kết luận | ⚠ chi phí tăng đều qua các chặng là dấu hiệu kinh điển của nợ kỹ thuật tích tụ |

⚠ Vì sao Hugo khó phát hiện: ⚠ nợ kỹ thuật không xuất hiện thành một khoản mục nào trong ngân sách ⚠ — ⚠ nó chỉ hiện ra dưới dạng mọi thứ đều chậm hơn và tốn hơn một chút; liên hệ #26966 lô 204.

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

• C (phình phạm vi — scope creep) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ phình phạm vi cũng làm chi phí tăng và cũng là một nguyên nhân rất phổ biến — trong nhiều tình huống khác thì đây chính là đáp án: ⚠ nhưng ⚠ phình phạm vi làm chi phí tăng vì có THÊM VIỆC, còn nợ kỹ thuật làm chi phí tăng dù khối lượng việc không đổi ⚠; ⚠ và trong agile, việc thêm hạng mục vào tồn đọng là chuyện bình thường và được kiểm soát bởi chủ sản phẩm — nó không âm thầm như phình phạm vi trong dự án dự đoán; ⚠ dấu hiệu phân biệt: nếu số điểm câu chuyện hoàn thành mỗi chặng KHÔNG đổi mà chi phí vẫn tăng thì đó là nợ kỹ thuật; nếu khối lượng công việc tăng thì đó là phình phạm vi.

• B (số giờ làm tăng mà không có lý do) — ⚠ đó là TRIỆU CHỨNG chứ không phải nguyên nhân; ⚠ và câu hỏi hỏi NGUYÊN NHÂN có thể gây ra tình trạng đó.

• D (đội đã thêm người kiểm thử) — ⚠ nếu thêm người thì chi phí tăng một BẬC rồi ổn định; ⚠ không khớp với mô tả tăng LIÊN TỤC.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26966 lô 204 (nợ kỹ thuật là rủi ro và làm giảm giá trị), ⚠ #26924 lô 203 (việc dở dang chất đống), ⚠ #26841 lô 202 (vận tốc giảm và cách chẩn đoán), ⚠ #27019 lô 205 (thiếu thời gian cho bảo đảm chất lượng).

⚠ Nợ kỹ thuật hiện ra qua những dấu hiệu nào: | Dấu hiệu | Nội dung | |---|---| | ⚠ Chi phí tăng dần dù khối lượng việc không đổi | ⚠ triệu chứng của đề | | ⚠ Vận tốc giảm dần qua các chặng | ⚠ liên hệ #26841 lô 202 | | ⚠ Tỷ lệ lỗi tăng | | | ⚠ Đội ngại động vào một số phần của hệ thống | ⚠ dấu hiệu rõ ràng nhất | | ⚠ Việc nhỏ mất nhiều thời gian bất ngờ | | | ⚠ Dấu hiệu đáng tin nhất | ⚠ khi đội bắt đầu nói "chỗ đó đừng động vào" — đó là lúc nợ kỹ thuật đã lớn tới mức ảnh hưởng tới quyết định kỹ thuật, và từ đó nó chỉ tăng thêm |

⚠ Hugo nên làm gì tiếp theo: | Bước | Nội dung | |---|---| | ⚠ 1. Xác nhận giả thuyết bằng dữ liệu | ⚠ so chi phí với số điểm hoàn thành mỗi chặng | | ⚠ 2. Hỏi đội trong buổi cải tiến | ⚠ họ biết rõ nhất phần nào đang khó — #27031 lô 205 | | ⚠ 3. Xác định các khoản nợ lớn nhất | | | ⚠ 4. Đưa việc trả nợ vào TỒN ĐỌNG | ⚠ liên hệ #26975 lô 204 và #27083 cùng lô | | ⚠ 5. Dành một tỷ lệ cố định mỗi chặng để trả nợ | ⚠ thường 10 tới 20% | | ⚠ Vì sao cách 5 hiệu quả nhất | ⚠ nếu chờ tới khi "rảnh" mới trả nợ thì sẽ không bao giờ trả — dành một tỷ lệ cố định biến nó thành một phần bình thường của công việc chứ không phải một dự án riêng cần xin phép |

⚠ Trình bày với bên liên quan thế nào: | Nên | Không nên | |---|---| | ⚠ Dùng ẩn dụ khoản vay: gốc và lãi | ⚠ giải thích bằng thuật ngữ kỹ thuật | | ⚠ Cho thấy chi phí mỗi tính năng đang tăng | ⚠ nói chung chung là mã xấu | | ⚠ Đề xuất tỷ lệ trả nợ cụ thể | | | ⚠ Nêu rõ chuyện gì xảy ra nếu không trả | | | ⚠ Cách trình bày thuyết phục nhất | ⚠ vẽ biểu đồ chi phí trên mỗi điểm câu chuyện theo từng chặng — đường đi lên đó nói rõ hơn mọi lời giải thích, và nó cũng cho thấy tốc độ mà vấn đề đang xấu đi |

Từ khoá nhận diện:

"chi phí tăng dần qua từng chặng" → ⚠ NỢ KỸ THUẬT "phình phạm vi" → ⚠ chi phí tăng vì có THÊM VIỆC "số giờ tăng không rõ lý do" → ⚠ triệu chứng, không phải nguyên nhân "thêm người kiểm thử" → ⚠ chi phí tăng một bậc rồi ổn định, không tăng liên tục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí trên mỗi điểm câu chuyện của bạn có tăng theo thời gian không | | | Có phần nào trong hệ thống mà đội ngại động vào không | | | Bạn có dành tỷ lệ cố định mỗi chặng để trả nợ kỹ thuật không | |

Và điều làm cho nợ kỹ thuật nguy hiểm hơn mọi khoản vượt chi khác: không có ai gửi hoá đơn — nó được thanh toán âm thầm bằng việc mọi thứ mỗi tháng lại chậm hơn một chút.

Đáp án

B — GIỮ HỌ HÀI LÒNG (keep satisfied).

Vì sao đúng

⚠ Xếp nhà cung cấp nhựa lên ma trận: | Trục | Đánh giá | |---|---| | ⚠ QUYỀN LỰC: là nhà cung cấp HÀNG ĐẦU của công ty | ⚠ CAO — họ có thể gây ảnh hưởng lớn | | ⚠ QUAN TÂM tới dự án tã vải: chỉ quan tâm ở khía cạnh bị mất việc | ⚠ THẤP về mặt nội dung dự án | | ⚠ Ô quyền lực CAO – quan tâm THẤP | ⚠ chiến lược: GIỮ HÀI LÒNG | | ⚠ Họ không muốn tham gia, chỉ không muốn bị thiệt | | | ⚠ Kết luận | ⚠ thông tin vừa đủ, đừng làm phiền quá mức, nhưng tuyệt đối đừng để họ bất ngờ |

⚠ Vì sao họ nguy hiểm nếu bị bỏ quên: ⚠ một nhà cung cấp lớn đang bị đe doạ mất doanh thu có thể tác động qua nhiều kênh: đàm phán lại giá các mặt hàng khác, vận động nội bộ, hoặc trì hoãn giao hàng ⚠ — ⚠ liên hệ #26913 lô 203 về bên liên quan có thái độ kháng cự.

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

• A (quản lý chặt — manage closely) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ họ là bên liên quan có quyền lực cao và đang phản đối dự án, nên "quản lý chặt" nghe như phản ứng thận trọng và an toàn: ⚠ nhưng ⚠ quản lý chặt dành cho ô quyền lực CAO – quan tâm CAO, tức là những người muốn THAM GIA vào dự án ⚠; ⚠ nhà cung cấp nhựa không muốn tham gia vào việc phát triển tã vải — họ chỉ quan tâm tới doanh thu của mình; ⚠ và kéo họ vào quá sâu còn phản tác dụng: cho một bên đang phản đối nhiều diễn đàn hơn để phản đối là một sai lầm chiến lược.

• C (theo dõi — monitor) — ⚠ dành cho ô quyền lực THẤP – quan tâm THẤP; ⚠ đánh giá thấp quyền lực của một nhà cung cấp hàng đầu là rủi ro lớn.

• D (giữ thông tin đủ — keep informed) — ⚠ dành cho ô quyền lực THẤP – quan tâm CAO; ⚠ và gửi nhiều thông tin về một dự án đang đe doạ họ chỉ làm họ có thêm thời gian chuẩn bị phản ứng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27078 lô 206 (ô quyền lực thấp – quan tâm thấp: theo dõi), ⚠ #26974 lô 204 (ô quyền lực thấp – quan tâm cao), ⚠ #26973 lô 204 (lập bản đồ bên liên quan), ⚠ #27106 cùng lô (một trường hợp thuộc ô theo dõi), ⚠ #26913 lô 203 (bên liên quan phản đối).

⚠ BỐN Ô và bốn chiến lược, bảng đầy đủ: | Ô | Chiến lược | Ví dụ trong các lô gần đây | |---|---|---| | ⚠ Quyền lực CAO – Quan tâm CAO | ⚠ QUẢN LÝ CHẶT | ⚠ nhà tài trợ, khách hàng chính | | ⚠ Quyền lực CAO – Quan tâm THẤP | ⚠ GIỮ HÀI LÒNG | ⚠ #27105 — nhà cung cấp nhựa | | ⚠ Quyền lực THẤP – Quan tâm CAO | ⚠ GIỮ THÔNG TIN ĐỦ | ⚠ #26974 lô 204 — Craig | | ⚠ Quyền lực THẤP – Quan tâm THẤP | ⚠ THEO DÕI | ⚠ #27078 lô 206, #27106 cùng lô | | ⚠ Mẹo nhớ hai trục | ⚠ QUYỀN LỰC quyết định mức đầu tư công sức, QUAN TÂM quyết định lượng thông tin — nhớ hai trục thì suy ra được cả bốn ô mà không cần học thuộc |

⚠ "Giữ hài lòng" nghĩa là làm gì cụ thể: | Việc | Nội dung | |---|---| | ⚠ Thông báo các quyết định lớn TRƯỚC khi công bố rộng | ⚠ không để họ nghe từ nguồn khác | | ⚠ Trao đổi ngắn gọn, không nhồi chi tiết | ⚠ họ không muốn dự họp hằng tuần | | ⚠ Lắng nghe mối lo của họ một cách nghiêm túc | | | ⚠ Tìm cơ hội cùng có lợi nếu có | ⚠ họ có thể cung cấp cho sản phẩm mới không | | ⚠ Điều tuyệt đối tránh | ⚠ để họ BẤT NGỜ — một bên liên quan quyền lực cao mà biết tin qua kênh khác sẽ phản ứng mạnh hơn nhiều so với khi được báo trước, dù nội dung tin là như nhau |

⚠ Cơ hội bị bỏ qua trong tình huống này: | Hướng | Nội dung | |---|---| | ⚠ Nhà cung cấp có thể cung cấp vật liệu cho tã vải không | ⚠ chuyển từ đối thủ thành đối tác | | ⚠ Sản phẩm mới có cần bao bì nhựa không | | | ⚠ Có thể thoả thuận lộ trình chuyển đổi dần không | | | ⚠ Nhận xét | ⚠ cách tốt nhất để xử lý một bên liên quan phản đối vì lý do KINH TẾ là tìm cho họ một vai trò trong tương lai mới — vì mối lo của họ hoàn toàn hợp lý và sẽ không tan đi bằng lời thuyết phục |

Từ khoá nhận diện:

"nhà cung cấp lớn sẽ mất doanh thu" → ⚠ quyền lực CAO, quan tâm THẤP → GIỮ HÀI LÒNG "quản lý chặt" → ⚠ dành cho người muốn THAM GIA vào dự án "theo dõi" → ⚠ đánh giá quá thấp quyền lực của một nhà cung cấp hàng đầu "giữ thông tin đủ" → ⚠ dành cho quyền lực thấp – quan tâm cao

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bên liên quan quyền lực cao nào đang bị dự án của bạn đe doạ không | | | Họ có được báo trước các quyết định lớn không | | | Bạn đã tìm cơ hội cùng có lợi với họ chưa | |

Và điều nguy hiểm nhất với một bên liên quan quyền lực cao mà bạn xếp vào nhóm ít quan tâm: họ chỉ ít quan tâm cho tới lúc dự án chạm vào lợi ích của họ — và lúc đó họ chuyển ô rất nhanh.

Đáp án

B — THEO DÕI HÀNH ĐỘNG CỦA CÔ BẠN (monitor).

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ⚠ — ⚠ dừng ở "What stakeholder manage", tức là "management strategy should Arya use"; ⚠ bốn phương án cho thấy rõ đây là câu hỏi về bốn ô của ma trận.

Vì sao đúng

⚠ Xếp cô bạn ở phòng nhân sự lên ma trận: | Trục | Đánh giá | |---|---| | ⚠ QUYỀN LỰC / ảnh hưởng: đề nói rõ là ÍT | ⚠ THẤP | | ⚠ QUAN TÂM: đề nói rõ là ÍT | ⚠ THẤP | | ⚠ Ô quyền lực THẤP – quan tâm THẤP | ⚠ chiến lược: THEO DÕI | | ⚠ Dự án nhỏ: 10.000 đô, hai tháng | ⚠ không đủ nguồn lực để đầu tư cho mọi người | | ⚠ Kết luận | ⚠ nỗ lực tối thiểu, nhưng vẫn để mắt phòng khi tình hình đổi |

⚠ Đề đã cho sẵn cả hai toạ độ: ⚠ "ít ảnh hưởng hoặc quan tâm tới loại giấy mới" ⚠ — ⚠ đây là dạng câu hỏi kiểm tra xem bạn có thuộc bảng bốn ô hay không, chứ không đòi hỏi suy luận phức tạp.

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

• C (giữ cô ấy được thông tin — keep informed) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cô ấy là BẠN của Arya và Arya đã tự nhiệt tình kể cho cô ấy nghe — nên việc tiếp tục cập nhật cho bạn mình nghe rất tự nhiên về mặt con người: ⚠ nhưng ⚠ "giữ thông tin đủ" là chiến lược cho ô quyền lực THẤP – quan tâm CAO ⚠ — ⚠ mà đề nói rõ cô ấy KHÔNG quan tâm; ⚠ và đây là bài học quan trọng về quản lý bên liên quan: chiến lược phải dựa trên VỊ TRÍ TRÊN MA TRẬN chứ không dựa trên quan hệ cá nhân; ⚠ liên hệ #27006 lô 205, nơi phương án "mình quý ai hơn" bị loại vì cùng lý do.

• A (quản lý chặt) — ⚠ dành cho quyền lực CAO – quan tâm CAO; ⚠ hoàn toàn không tương xứng.

• D (giữ hài lòng) — ⚠ dành cho quyền lực CAO – quan tâm THẤP; ⚠ cô ấy không có quyền lực đối với dự án này.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27105 cùng lô (quyền lực cao – quan tâm thấp: giữ hài lòng), ⚠ #27078 lô 206 (cũng thuộc ô theo dõi), ⚠ #26974 lô 204 (quyền lực thấp – quan tâm cao), ⚠ #27006 lô 205 (không dựa vào quan hệ cá nhân khi lập chiến lược).

⚠ Bốn ô, ba câu hỏi cùng lô này và lô trước: | Câu | Ô | Chiến lược | |---|---|---| | ⚠ #27105 cùng lô | ⚠ quyền lực CAO – quan tâm THẤP | ⚠ giữ hài lòng | | ⚠ #27106 (câu này) | ⚠ quyền lực THẤP – quan tâm THẤP | ⚠ theo dõi | | ⚠ #27078 lô 206 | ⚠ quyền lực THẤP – quan tâm THẤP | ⚠ theo dõi | | ⚠ #26974 lô 204 | ⚠ quyền lực THẤP – quan tâm CAO | ⚠ giữ thông tin đủ / mời đóng góp | | ⚠ Nhận xét | ⚠ bộ đề hỏi rất nhiều về ma trận này — nên nếu chỉ học thuộc một bảng trong toàn bộ phần bên liên quan thì hãy học bảng bốn ô |

⚠ "Theo dõi" nghĩa là làm gì: | Việc | Nội dung | |---|---| | ⚠ Ghi tên vào sổ đăng ký bên liên quan | ⚠ vẫn phải có tên | | ⚠ Không gửi báo cáo định kỳ riêng | ⚠ tiết kiệm công sức cho cả hai bên | | ⚠ Để mắt xem vị trí của họ có đổi không | ⚠ liên hệ #26957 lô 204 | | ⚠ Có kênh để họ liên hệ nếu muốn | | | ⚠ Điều "theo dõi" KHÔNG có nghĩa là | ⚠ bỏ mặc — một người ở ô này vẫn nằm trong sổ và vẫn được rà lại định kỳ; điểm khác biệt chỉ là bạn không chủ động đầu tư công sức cho họ |

⚠ Vì sao Arya vẫn nên ghi cô bạn vào sổ: | Lý do | Nội dung | |---|---| | ⚠ Cô ấy ĐÃ biết về dự án | ⚠ thông tin đã ra ngoài | | ⚠ Phòng nhân sự có thể liên quan về sau | ⚠ nếu dự án dẫn tới thay đổi nhân sự | | ⚠ Vị trí trên ma trận có thể đổi | | | ⚠ Bài học nhỏ nhưng đáng nhớ | ⚠ Arya đã kể về dự án cho một người vì hào hứng chứ không vì kế hoạch truyền thông — điều đó không sai, nhưng nó tạo ra một bên liên quan mới, và mọi người biết về dự án đều nên có tên trong sổ dù chiến lược dành cho họ chỉ là theo dõi |

Từ khoá nhận diện:

"ít ảnh hưởng, ít quan tâm" → ⚠ THEO DÕI "giữ thông tin đủ" → ⚠ dành cho người QUAN TÂM CAO "giữ hài lòng" → ⚠ dành cho người QUYỀN LỰC CAO "quản lý chặt" → ⚠ dành cho người cao cả hai trục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn xếp được từng bên liên quan vào một trong bốn ô không | | | Có ai đang được đầu tư công sức vượt mức cần thiết không | | | Chiến lược của bạn dựa trên ma trận hay dựa trên quan hệ cá nhân | |

Và điều mà ma trận bốn ô bảo vệ người quản lý dự án khỏi: việc phân bổ sự chú ý theo mức độ quen biết thay vì theo mức độ ảnh hưởng tới dự án.

Đáp án

B — GẶP RIÊNG TỪNG LẬP TRÌNH VIÊN ĐỂ HIỂU NGUỒN CƠN BẤT ĐỒNG.

Vì sao đúng

⚠ Vì sao gặp riêng là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Melissa CHƯA BIẾT nguyên nhân bất đồng | ⚠ chưa có thông tin thì chưa giải quyết được | | ⚠ Người ta nói thật hơn khi không có bên kia | | | ⚠ Mỗi bên có một phiên bản câu chuyện | ⚠ sự thật thường ở giữa | | ⚠ Cô ấy đã CHỜ vài ngày mà không cải thiện | ⚠ cơ chế tự giải quyết đã thất bại | | ⚠ Tiến độ dự án đang bị ảnh hưởng | ⚠ không thể chờ thêm | | ⚠ Kết luận | ⚠ hiểu trước, hoà giải sau — và gặp riêng là cách duy nhất để hiểu ở giai đoạn này |

⚠ Việc chờ vài ngày không phải sai lầm: ⚠ cho người ta cơ hội tự giải quyết là hợp lý ⚠ — ⚠ sai lầm sẽ là tiếp tục chờ sau khi đã thấy rõ rằng nó không tự hết; liên hệ #27025 lô 205.

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

• D (nhắc cả đội về tầm quan trọng của làm việc nhóm ở buổi họp đứng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó tránh chỉ đích danh ai, giữ thể diện cho cả hai, và nghe như một cách khéo léo để nhắc nhở gián tiếp: ⚠ nhưng ⚠ nó nói với TẤT CẢ về vấn đề của HAI người, khiến những người không liên quan cảm thấy bị trách oan ⚠; ⚠ và hai người trong cuộc sẽ biết chính xác lời nhắc đó nhắm vào ai, nên nó vừa không kín đáo vừa không hiệu quả; ⚠ quan trọng nhất: nó không hề tìm hiểu NGUYÊN NHÂN, mà một mâu thuẫn không rõ nguyên nhân thì không thể giải quyết bằng một lời nhắc chung chung.

• C (loại hai người khỏi đội dự án) — ⚠ phản ứng cực đoan nhất khi chưa biết chuyện gì xảy ra; ⚠ và mất hai lập trình viên giữa dự án là tổn thất rất lớn.

• A (báo cáo hai người lên chủ sản phẩm) — ⚠ sai người; ⚠ chủ sản phẩm lo giá trị và tồn đọng, không lo quan hệ nội bộ đội.

Ghi nhớ

⚠ Ghi chú đối chiếu quan trọng: ⚠ #27112 cùng lô cũng mô tả hai thành viên không làm việc được với nhau, nhưng khoá ở đó là THOẢ HIỆP bằng cách làm việc với từng người ⚠ — ⚠ hai khoá không mâu thuẫn mà nằm ở hai GIAI ĐOẠN khác nhau của cùng một quy trình; ⚠ ở câu này Melissa CHƯA BIẾT nguyên nhân nên bước đầu tiên là TÌM HIỂU; ở #27112 thì nguyên nhân đã rõ (quan hệ gia đình lâu năm) và câu hỏi là chọn CHIẾN LƯỢC xử lý xung đột ⚠; ⚠ quy tắc rút ra: chưa biết nguyên nhân thì gặp riêng để hiểu; đã biết rồi thì chọn chiến lược phù hợp với hoàn cảnh.

⚠ Đối chiếu: ⚠ #27112 cùng lô (đã biết nguyên nhân, chọn chiến lược), ⚠ #27025 lô 205 (hai nhóm bên liên quan mâu thuẫn — cùng cách tiếp cận), ⚠ #26979 lô 204 (xung đột giữa hai nhà thầu), ⚠ #27074 lô 206 (dùng sai chiến lược làm vận tốc tụt).

⚠ Quy trình hoà giải, năm bước: | Bước | Nội dung | |---|---| | ⚠ 1. Gặp RIÊNG từng người, chủ yếu để nghe | ⚠ ĐÁP ÁN của câu này | | ⚠ 2. Tìm lợi ích thật của mỗi bên | ⚠ chuyển từ lập trường sang lợi ích | | ⚠ 3. Chuẩn bị khung cho buổi gặp chung | | | ⚠ 4. Tổ chức buổi gặp chung có điều phối | | | ⚠ 5. Chốt thoả thuận về cách làm việc | | | ⚠ Sai lầm hay gặp | ⚠ nhảy thẳng tới bước 4 — nó tiết kiệm vài ngày nhưng thường đốt cháy cơ hội duy nhất để hai bên ngồi lại, vì buổi gặp chung không có chuẩn bị rất dễ biến thành cuộc đối đầu |

⚠ Cần hỏi gì trong buổi gặp riêng: | Câu hỏi | Mục đích | |---|---| | ⚠ Chuyện bắt đầu từ khi nào, từ việc gì | ⚠ thường có một sự kiện gốc | | ⚠ Điều gì làm anh chị khó chịu nhất | | | ⚠ Anh chị cần gì để làm việc được với nhau | ⚠ chuyển sang giải pháp | | ⚠ Anh chị nghĩ người kia muốn gì | ⚠ lộ ra hiểu nhầm | | ⚠ Điều cần hứa và giữ | ⚠ giữ kín nội dung trao đổi riêng — nếu Melissa kể lại lời của người này cho người kia thì cả hai sẽ thôi nói thật, và cơ hội hoà giải cũng mất theo; liên hệ #26918 lô 203 |

⚠ Vì sao mâu thuẫn giữa hai người ảnh hưởng cả dự án: | Tác động | Nội dung | |---|---| | ⚠ Công việc phụ thuộc lẫn nhau bị chặn | ⚠ đề nói tiến độ đang bị ảnh hưởng | | ⚠ Thông tin không được chia sẻ | | | ⚠ Cả đội phải né tránh, tốn năng lượng | | | ⚠ Người khác bị kéo vào phe | ⚠ rủi ro lớn nhất nếu để lâu | | ⚠ Vì sao phải xử lý sớm | ⚠ một mâu thuẫn hai người còn giải quyết được; khi nó lan thành hai phe thì phải xử lý ở cấp cả đội và mất nhiều thời gian hơn rất nhiều |

Từ khoá nhận diện:

"hai người thôi làm việc với nhau, CHƯA BIẾT vì sao" → ⚠ GẶP RIÊNG từng người "nhắc cả đội về làm việc nhóm" → ⚠ trách oan người khác, không tìm nguyên nhân "loại khỏi đội" → ⚠ cực đoan khi chưa biết chuyện gì "báo chủ sản phẩm" → ⚠ sai người, đó không phải việc của họ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hai người nào trong đội bạn đang né tránh nhau không | | | Bạn đã nghe riêng từng bên chưa | | | Bạn có giữ kín nội dung trao đổi riêng không | |

Và điều mà việc chờ vài ngày cho một mâu thuẫn tự hết dạy cho người quản lý: cho người ta cơ hội tự giải quyết là đúng, nhưng chỉ đúng một lần — và sau đó thì sự chờ đợi biến thành sự né tránh.

Đáp án

A — QUẢN LÝ VI MÔ (micromanagement).

Vì sao đúng

⚠ Thuyết X giả định gì về người lao động: | Giả định | Hệ quả trong cách quản lý | |---|---| | ⚠ Người ta vốn LƯỜI, không thích làm việc | ⚠ phải thúc ép | | ⚠ Cần bị KIỂM SOÁT và giám sát chặt | ⚠ QUẢN LÝ VI MÔ — ĐÁP ÁN | | ⚠ Tránh trách nhiệm, thích được chỉ đạo | ⚠ ra lệnh chi tiết | | ⚠ Chỉ làm vì tiền và vì sợ bị phạt | ⚠ thưởng phạt là công cụ chính | | ⚠ Kết luận | ⚠ quản lý vi mô là biểu hiện hành vi trực tiếp nhất của các giả định Thuyết X |

⚠ Thuyết Y thì ngược lại: ⚠ người ta thích làm việc, tự tạo động lực, sẵn sàng nhận trách nhiệm ⚠ — ⚠ nên người quản lý theo Thuyết Y sẽ trao quyền thay vì giám sát; liên hệ #26877 lô 202.

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

• B (đội dự án tự dẫn dắt) — ⚠ phương án gây nhiễu mạnh nhất theo hướng ngược lại vì ⚠ nó là một khái niệm quản lý rõ ràng và người đọc vội có thể chọn bừa một phương án nghe chuyên môn: ⚠ nhưng ⚠ đội tự dẫn dắt là biểu hiện của Thuyết Y, tức là CỰC ĐỐI LẬP ⚠; ⚠ và đề hỏi ví dụ về Thuyết X; ⚠ cách phòng: với mọi câu hỏi về cặp X và Y, hãy xác định rõ đề đang hỏi vế nào trước khi đọc phương án — vì bộ đề luôn đặt cả hai vế cạnh nhau.

• C (thành viên làm việc theo ý mình) — ⚠ cũng là biểu hiện của Thuyết Y; ⚠ tự chủ và tự tạo động lực.

• D (quản lý giá trị thu được) — ⚠ là một kỹ thuật ĐO LƯỜNG dự án; ⚠ hoàn toàn không liên quan tới giả định về bản chất con người.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26877 lô 202 (Thuyết X và Y), ⚠ #26988 lô 205 (Herzberg và yếu tố duy trì), ⚠ #27063 lô 206 (Thuyết Z của Ouchi), ⚠ #26923 lô 203 (thuyết kỳ vọng Vroom), ⚠ #26915 lô 203 (văn hoá cứng nhắc và phong cách chỉ đạo).

⚠ Thuyết X và Thuyết Y, bảng đối chiếu: | Thuyết X | Thuyết Y | |---|---| | ⚠ Người ta lười, tránh việc | ⚠ làm việc là tự nhiên như nghỉ ngơi | | ⚠ Phải ép buộc và giám sát | ⚠ tự định hướng khi cam kết với mục tiêu | | ⚠ Tránh trách nhiệm | ⚠ tìm kiếm trách nhiệm | | ⚠ Ít sáng tạo | ⚠ sáng tạo phân bố rộng trong dân số | | ⚠ Biểu hiện: QUẢN LÝ VI MÔ | ⚠ biểu hiện: TRAO QUYỀN, đội tự tổ chức | | ⚠ Điểm quan trọng nhất của thuyết | ⚠ đây là GIẢ ĐỊNH của người quản lý, không phải sự thật về nhân viên — và nó tự ứng nghiệm: quản lý theo X thì nhân viên hành xử như X, tạo ra bằng chứng củng cố cho chính giả định đó |

⚠ Vì sao quản lý vi mô phản tác dụng: | Tác hại | Nội dung | |---|---| | ⚠ Người giỏi cảm thấy không được tin và bỏ đi | ⚠ liên hệ #26947 lô 204 | | ⚠ Không ai dám quyết, mọi việc chờ người quản lý | ⚠ tạo nút thắt | | ⚠ Đội thôi suy nghĩ, chỉ chờ được bảo | ⚠ liên hệ #26915 lô 203 | | ⚠ Người quản lý kiệt sức vì ôm hết | | | ⚠ Vòng luẩn quẩn | ⚠ quản lý vi mô làm đội mất chủ động, sự mất chủ động đó lại được coi là bằng chứng rằng đội cần được giám sát chặt hơn — và vòng xoáy siết chặt dần cho tới khi người giỏi nhất rời đi |

⚠ Agile đứng ở đâu trong hai thuyết: | Yếu tố | Nội dung | |---|---| | ⚠ Đội TỰ TỔ CHỨC | ⚠ giả định Thuyết Y | | ⚠ Đội tự quyết cách làm | ⚠ Thuyết Y | | ⚠ Lãnh đạo phụng sự thay vì chỉ huy | ⚠ Thuyết Y | | ⚠ Hệ quả cho tổ chức chuyển đổi agile | ⚠ một người quản lý mang giả định Thuyết X sẽ không thể vận hành một đội agile thật sự, dù có học đủ mọi nghi thức — vì giả định về con người quyết định hành vi mạnh hơn quy trình rất nhiều; liên hệ #26915 lô 203 |

Từ khoá nhận diện:

"quản lý vi mô" → ⚠ THUYẾT X "đội tự dẫn dắt / tự làm theo ý mình" → ⚠ Thuyết Y, cực đối lập "quản lý giá trị thu được" → ⚠ kỹ thuật đo lường, không liên quan "Thuyết X và Y" → ⚠ nói về GIẢ ĐỊNH của người quản lý, không phải sự thật về nhân viên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn hành xử theo giả định X hay Y với đội của mình | | | Có việc nào bạn đang giám sát chi tiết mà lẽ ra nên giao hẳn không | | | Đội bạn có chờ bạn quyết những việc họ tự quyết được không | |

Và điều đáng lo nhất về Thuyết X: nó luôn tìm được bằng chứng cho mình — vì một đội bị quản lý như thể họ lười sẽ dần hành xử đúng như vậy, và người quản lý sẽ tin rằng mình đã đúng ngay từ đầu.

Đáp án

C — 160 ĐÔ (thấp hơn mức đúng hạn).

Vì sao đúng

⚠ Hợp đồng giá cố định BẬC THANG hoạt động thế nào: | Cơ chế | Nội dung | |---|---| | ⚠ Đơn giá THAY ĐỔI theo mức hiệu suất đạt được | ⚠ không phải một mức duy nhất | | ⚠ Hoàn thành ĐÚNG HẠN ⇒ đơn giá chuẩn | ⚠ 175 đô mỗi giờ | | ⚠ Hoàn thành SỚM ⇒ đơn giá CAO hơn | ⚠ phần thưởng, ví dụ 190 đô | | ⚠ Hoàn thành MUỘN ⇒ đơn giá THẤP hơn | ⚠ 160 đô — ĐÁP ÁN | | ⚠ Kết luận | ⚠ cơ chế gắn đơn giá với hiệu suất tạo động lực hoàn thành sớm và phạt việc chậm trễ |

⚠ Logic đằng sau: ⚠ nhà cung cấp chịu hậu quả tài chính trực tiếp khi chậm ⚠ — ⚠ đó là cách chuyển một phần rủi ro tiến độ sang họ mà không cần điều khoản phạt riêng.

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

• D (190 đô) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là mức đơn giá CAO hơn, và trong một hợp đồng bậc thang thì mức cao đó có tồn tại thật — chỉ là nó dành cho việc hoàn thành SỚM: ⚠ nhưng ⚠ áp mức cao cho việc hoàn thành MUỘN là đảo ngược hoàn toàn cơ chế khuyến khích ⚠; ⚠ nó sẽ thưởng cho việc chậm trễ, tức là tạo ra động cơ ngược — giống hệt khiếm khuyết của hợp đồng chi phí cộng phần trăm chi phí; liên hệ #27046 lô 206; ⚠ đây là bẫy chọn đúng bậc nhưng sai chiều.

• B (vẫn 175 đô) — ⚠ nếu đơn giá không đổi thì đó là hợp đồng giá cố định thông thường; ⚠ chữ "bậc thang" trong đề sẽ trở nên vô nghĩa.

• A (không đủ thông tin để xác định) — ⚠ đề đã cho đủ: biết cơ chế bậc thang và biết mức chuẩn thì suy ra được CHIỀU của mức khi chậm; ⚠ câu hỏi cũng chỉ hỏi mức "nhiều khả năng nhất".

Ghi nhớ

⚠ Đối chiếu: ⚠ #27029 lô 205 (hợp đồng giá cố định bậc thang cho dự án agile), ⚠ #27077 lô 206 (hợp đồng trọn gói và rủi ro bên bán), ⚠ #26930 lô 203 (CPIF và cơ chế thưởng), ⚠ #27046 lô 206 (thang rủi ro theo loại hợp đồng).

⚠ Các cơ chế gắn tiền với hiệu suất: | Cơ chế | Nội dung | |---|---| | ⚠ GIÁ CỐ ĐỊNH BẬC THANG | ⚠ đơn giá đổi theo mức hiệu suất — câu này | | ⚠ Giá cố định có phí thưởng (FPIF) | ⚠ giá cố định cộng thưởng nếu vượt mục tiêu | | ⚠ Chi phí cộng phí thưởng (CPIF) | ⚠ hoàn trả chi phí cộng thưởng chia sẻ | | ⚠ Điều khoản phạt chậm tiến độ | ⚠ khoản trừ cố định cho mỗi ngày chậm | | ⚠ Điểm chung | ⚠ tất cả đều nhằm làm cho lợi ích của nhà cung cấp TRÙNG với lợi ích của bên mua — và mọi hợp đồng thất bại về hiệu suất đều là hợp đồng mà hai lợi ích đó tách rời nhau |

⚠ Thiết kế bậc thang cho hợp lý: | Yêu cầu | Nội dung | |---|---| | ⚠ Các mốc hiệu suất phải ĐO ĐƯỢC | ⚠ ngày hoàn thành là mốc rõ ràng nhất | | ⚠ Chênh lệch đơn giá đủ lớn để tạo động lực | ⚠ chênh 1% thì không ai quan tâm | | ⚠ Nhưng không quá lớn tới mức khuyến khích làm ẩu | ⚠ rủi ro chất lượng | | ⚠ Ghi rõ cách xử lý khi chậm do lỗi BÊN MUA | ⚠ điều khoản hay bị bỏ sót | | ⚠ Điều khoản quan trọng nhất bị bỏ sót | ⚠ cái cuối cùng — nếu nhà cung cấp chậm vì bên mua duyệt tài liệu muộn thì việc hạ đơn giá là bất công, và đó là nguồn tranh chấp phổ biến nhất của loại hợp đồng này; liên hệ #27052 lô 206 |

⚠ Rủi ro của việc gắn tiền với tốc độ: | Rủi ro | Nội dung | |---|---| | ⚠ Nhà cung cấp cắt bớt chất lượng để kịp hạn | ⚠ liên hệ #27019 lô 205 | | ⚠ Báo cáo tiến độ lạc quan hơn thực tế | | | ⚠ Tranh chấp về việc ai gây ra chậm trễ | | | ⚠ Cách giảm thiểu | ⚠ luôn gắn mốc hiệu suất với cả TIẾN ĐỘ lẫn CHẤT LƯỢNG — một hợp đồng chỉ thưởng cho tốc độ sẽ nhận về đúng thứ nó trả tiền, và phần chất lượng sẽ là thứ bị hy sinh trước tiên |

Từ khoá nhận diện:

"giá cố định bậc thang, hoàn thành MUỘN" → ⚠ đơn giá THẤP hơn (160 đô) "190 đô" → ⚠ mức dành cho hoàn thành SỚM, chọn đúng bậc sai chiều "vẫn 175 đô" → ⚠ thì chữ "bậc thang" vô nghĩa "không đủ thông tin" → ⚠ đề đã cho đủ để suy ra chiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có gắn tiền với hiệu suất không | | | Các mốc hiệu suất có đo được khách quan không | | | Có điều khoản xử lý khi chậm do lỗi bên mua không | |

Và nguyên tắc thiết kế mọi cơ chế khuyến khích trong hợp đồng: nhà cung cấp sẽ tối ưu chính xác thứ bạn trả tiền cho — nên hãy chắc rằng thứ đó là thứ bạn thật sự muốn.

Đáp án

B — KHI VẤN ĐỀ KHÔNG TÁI DIỄN SAU KHI CÁC NGUYÊN NHÂN GỐC ĐÃ ĐƯỢC LOẠI BỎ.

Vì sao đúng

⚠ Vì sao đây là phép thử duy nhất đáng tin: | Lý do | Nội dung | |---|---| | ⚠ Nguyên nhân gốc là thứ mà loại bỏ nó thì vấn đề BIẾN MẤT | ⚠ đúng định nghĩa | | ⚠ Chỉ kiểm chứng được bằng KẾT QUẢ thực tế | ⚠ không phải bằng lập luận | | ⚠ Nếu vấn đề vẫn tái diễn thì chưa tìm đúng gốc | ⚠ hoặc còn nguyên nhân khác | | ⚠ Phép thử này khách quan, không phụ thuộc ý kiến | | | ⚠ Kết luận | ⚠ phân tích cho ra GIẢ THUYẾT, còn thực tế mới XÁC NHẬN nó |

⚠ Hệ quả thực tiễn: ⚠ phải THEO DÕI sau khi đã áp dụng biện pháp ⚠ — ⚠ rất nhiều tổ chức phân tích rất kỹ rồi không bao giờ quay lại kiểm tra xem vấn đề có hết thật không; liên hệ #27080 lô 206.

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

• D (khi đã hỏi tại sao bảy lần) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "năm lần hỏi tại sao" là một kỹ thuật có thật và rất nổi tiếng, nên một con số cụ thể nghe rất đáng tin: ⚠ nhưng ⚠ con số trong kỹ thuật đó là NĂM chứ không phải bảy, và quan trọng hơn: đó chỉ là một con số GỢI Ý chứ không phải một quy tắc ⚠; ⚠ có vấn đề chỉ cần hỏi ba lần đã tới gốc, có vấn đề hỏi tám lần vẫn chưa tới; ⚠ dừng lại vì đã đủ số lần hỏi là nhầm hình thức với kết quả — kỹ thuật này kết thúc khi câu trả lời không còn dẫn tới nguyên nhân sâu hơn, không phải khi đếm đủ số.

• A (vì phân tích chỉ tạo ra giả thuyết nên sẽ không bao giờ biết) — ⚠ vế đầu đúng nhưng kết luận sai; ⚠ giả thuyết kiểm chứng được bằng kết quả thực tế, nên hoàn toàn có cách biết.

• C (khi tìm được ba nguyên nhân gốc liên kết bởi thiết kế quy trình) — ⚠ con số ba là tuỳ tiện; ⚠ một vấn đề có thể có một hoặc nhiều nguyên nhân gốc, không có quy tắc nào về số lượng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27024 lô 205 (điều tra nguyên nhân gốc của chất lượng kém), ⚠ #26898 lô 203 (phân tích nguyên nhân gốc), ⚠ #27080 lô 206 (rà soát việc sửa lỗi để xác nhận), ⚠ #27033 lô 206 (vấn đề lặp lại là dấu hiệu chưa xử lý gốc).

⚠ Các kỹ thuật tìm nguyên nhân gốc: | Kỹ thuật | Cách dùng | |---|---| | ⚠ Năm lần hỏi tại sao | ⚠ hỏi tại sao liên tiếp cho tới khi không sâu thêm được | | ⚠ Biểu đồ xương cá (Ishikawa) | ⚠ nhóm nguyên nhân theo con người, quy trình, thiết bị, vật liệu, môi trường | | ⚠ Biểu đồ Pareto | ⚠ tìm nhóm nguyên nhân chiếm phần lớn | | ⚠ Phân tích cây lỗi | ⚠ truy ngược từ sự cố về các nguyên nhân có thể | | ⚠ Điểm chung của tất cả | ⚠ chúng chỉ SINH RA giả thuyết — không kỹ thuật nào tự chứng minh được rằng nó đã tìm đúng, và bước xác nhận bằng thực tế luôn nằm ngoài chúng |

⚠ Vì sao "năm lần" chỉ là con số gợi ý: | Tình huống | Số lần hỏi cần thiết | |---|---| | ⚠ Vấn đề đơn giản, nguyên nhân rõ | ⚠ hai tới ba lần | | ⚠ Vấn đề hệ thống, nhiều tầng | ⚠ có thể sáu tới bảy lần | | ⚠ Vấn đề có nhiều nguyên nhân song song | ⚠ phải hỏi theo nhiều nhánh | | ⚠ Dấu hiệu đã tới gốc | ⚠ khi câu trả lời tiếp theo nằm ngoài tầm kiểm soát của tổ chức, hoặc khi lặp lại chính câu trả lời trước — chứ không phải khi đã đếm đủ năm lần |

⚠ Shamika nên làm gì sau khi đã áp dụng biện pháp: | Bước | Nội dung | |---|---| | ⚠ 1. Ghi lại giả thuyết về nguyên nhân gốc | | | ⚠ 2. Áp dụng biện pháp loại bỏ nguyên nhân đó | | | ⚠ 3. XÁC ĐỊNH cách đo xem vấn đề có hết không | ⚠ chỉ số cụ thể, không dựa vào cảm giác | | ⚠ 4. THEO DÕI trong một khoảng đủ dài | | | ⚠ 5. Nếu vẫn tái diễn thì quay lại phân tích | | | ⚠ Bước bị bỏ qua nhiều nhất | ⚠ bước 4 — vấn đề không tái diễn trong hai tuần chưa chứng minh được gì nếu chu kỳ tự nhiên của nó là hàng tháng; khoảng theo dõi phải dài hơn chu kỳ xuất hiện của chính vấn đề đó |

Từ khoá nhận diện:

"làm sao biết đã tìm ra nguyên nhân gốc" → ⚠ vấn đề KHÔNG TÁI DIỄN sau khi loại bỏ "hỏi tại sao bảy lần" → ⚠ con số tuỳ tiện, và kỹ thuật gốc là NĂM lần gợi ý "ba nguyên nhân gốc" → ⚠ số lượng tuỳ tiện, không có quy tắc "sẽ không bao giờ biết" → ⚠ giả thuyết kiểm chứng được bằng kết quả thực tế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sau lần phân tích nguyên nhân gốc gần nhất, bạn có theo dõi kết quả không | | | Bạn có chỉ số để biết vấn đề đã hết chưa | | | Khoảng theo dõi của bạn có dài hơn chu kỳ xuất hiện của vấn đề không | |

Và điều phân biệt một cuộc phân tích nguyên nhân gốc thành công với một cuộc họp thông minh: cuộc thứ nhất kết thúc vài tháng sau đó, khi có người quay lại kiểm tra xem vấn đề còn xuất hiện nữa không.

Đáp án

D — SỐ ĐIỂM CÂU CHUYỆN GẮN VỚI CÁC CÂU CHUYỆN NGƯỜI DÙNG ĐƯỢC CHỦ SẢN PHẨM CHẤP NHẬN MỖI THÁNG.

Vì sao đúng

⚠ Vì sao chỉ số này đo đúng sức khoẻ dự án: | Yếu tố | Nội dung | |---|---| | ⚠ ĐIỂM CÂU CHUYỆN phản ánh KHỐI LƯỢNG công việc | ⚠ không phải chỉ đếm số hạng mục | | ⚠ ĐƯỢC CHẤP NHẬN nghĩa là đã ĐẠT chất lượng | ⚠ không tính việc làm dở hay bị trả lại | | ⚠ Chủ sản phẩm chấp nhận = có giá trị nghiệp vụ thật | | | ⚠ Theo tháng thì so sánh được giữa các kỳ | ⚠ cho thấy xu hướng | | ⚠ Kết luận | ⚠ kết hợp cả khối lượng, chất lượng và giá trị trong một con số duy nhất |

⚠ Đây chính là VẬN TỐC quy về mốc tháng: ⚠ thước đo chuẩn về năng lực bàn giao của một đội agile ⚠ — ⚠ liên hệ #26919 lô 203 về bản chất của điểm câu chuyện.

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

• A (số câu chuyện người dùng được chấp nhận mỗi tháng) — ⚠ phương án gây nhiễu mạnh nhất, và nó chỉ khác đáp án đúng một điểm vì ⚠ nó cũng đếm thứ đã được chấp nhận, cũng theo tháng, cũng do chủ sản phẩm duyệt: ⚠ nhưng ⚠ nó đếm SỐ LƯỢNG hạng mục chứ không đo KHỐI LƯỢNG công việc ⚠ — ⚠ mười câu chuyện nhỏ và ba câu chuyện lớn có thể là cùng một lượng công sức, nhưng con số báo cáo sẽ chênh nhau hơn ba lần; ⚠ và nó tạo ra động cơ xấu: chẻ nhỏ câu chuyện để con số đẹp hơn; ⚠ điểm câu chuyện tồn tại chính là để giải quyết vấn đề này.

• C (số giờ dành cho câu chuyện mỗi tháng) — ⚠ đo ĐẦU VÀO chứ không đo KẾT QUẢ; ⚠ đội làm nhiều giờ mà không bàn giao được gì thì con số này vẫn đẹp.

• B (không có gì, vì chỉ số hiệu suất chỉ dành cho dự án truyền thống) — ⚠ sai hoàn toàn; ⚠ dự án agile có bộ chỉ số riêng rất phong phú.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26919 lô 203 (điểm câu chuyện là đơn vị tương đối), ⚠ #26841 lô 202 (vận tốc giảm và cách chẩn đoán), ⚠ #26906 lô 203 (chỉ số hiệu suất chính), ⚠ #27104 cùng lô (chi phí trên mỗi điểm tăng dần là dấu hiệu nợ kỹ thuật).

⚠ Các chỉ số thường dùng cho dự án agile: | Chỉ số | Đo cái gì | |---|---| | ⚠ VẬN TỐC (điểm được chấp nhận) | ⚠ năng lực bàn giao — ĐÁP ÁN | | ⚠ Biểu đồ burndown / burnup | ⚠ tiến độ so với mục tiêu | | ⚠ Thời gian chu kỳ (cycle time) | ⚠ một hạng mục mất bao lâu từ đầu tới cuối | | ⚠ Tỷ lệ lỗi thoát ra sản xuất | ⚠ chất lượng | | ⚠ Mức hài lòng của khách hàng | ⚠ giá trị thật | | ⚠ Burndown rủi ro | ⚠ liên hệ #27086 cùng lô | | ⚠ Cảnh báo quan trọng | ⚠ vận tốc là chỉ số của ĐỘI, không dùng để so sánh giữa các đội — mỗi đội có thang điểm riêng, và so vận tốc giữa hai đội là phép so sánh vô nghĩa; liên hệ #26709 lô 199 |

⚠ Vì sao "được chấp nhận" là từ khoá quan trọng: | Trạng thái | Có tính không | |---|---| | ⚠ Đã viết mã xong | ⚠ KHÔNG | | ⚠ Đã kiểm thử xong | ⚠ KHÔNG | | ⚠ Đã trình diễn nhưng chưa duyệt | ⚠ KHÔNG | | ⚠ Chủ sản phẩm ĐÃ CHẤP NHẬN | ⚠ CÓ — chỉ trạng thái này mới tính | | ⚠ Vì sao nghiêm ngặt như vậy | ⚠ chỉ tính thứ đã được chấp nhận sẽ ngăn được việc báo cáo tiến độ dựa trên công việc dở dang — thứ mà mọi dự án gặp khó khăn đều có rất nhiều; liên hệ #26924 lô 203 |

⚠ Trình bày với lãnh đạo cấp cao thế nào: | Nên | Không nên | |---|---| | ⚠ Một biểu đồ xu hướng theo tháng | ⚠ bảng số liệu chi tiết | | ⚠ Kèm nhận định về xu hướng | ⚠ để họ tự diễn giải | | ⚠ Nêu điều bất thường nếu có | | | ⚠ Quy đổi ra ngôn ngữ kinh doanh nếu được | ⚠ tính năng nào đã tới tay người dùng | | ⚠ Điều lãnh đạo thật sự muốn biết | ⚠ không phải con số điểm câu chuyện mà là "dự án có đang đi đúng hướng không" — nên con số phải được kèm một câu trả lời cho chính câu hỏi đó, chứ đừng để họ tự suy ra |

Từ khoá nhận diện:

"chỉ số sức khoẻ dự án agile" → ⚠ ĐIỂM câu chuyện được CHẤP NHẬN "số lượng câu chuyện" → ⚠ đếm hạng mục, không đo khối lượng "số giờ đã dành" → ⚠ đo đầu vào, không đo kết quả "agile không có chỉ số" → ⚠ sai hoàn toàn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn báo cáo điểm câu chuyện hay số hạng mục | | | Bạn có tính cả việc chưa được chấp nhận không | | | Có ai đang so vận tốc giữa hai đội không | |

Và điều mà việc chỉ đếm thứ ĐÃ ĐƯỢC CHẤP NHẬN bảo vệ mọi báo cáo tiến độ khỏi: ảo giác về sự tiến triển tạo ra bởi một đống công việc gần xong.

Đáp án

D — THOẢ HIỆP BẰNG CÁCH LÀM VIỆC VỚI TỪNG THÀNH VIÊN.

Vì sao đúng

⚠ Vì sao thoả hiệp phù hợp với hoàn cảnh này: | Ràng buộc | Nội dung | |---|---| | ⚠ Cả hai người đều GIÁ TRỊ và KHÓ THAY THẾ | ⚠ không thể loại ai | | ⚠ Mâu thuẫn có yếu tố QUAN HỆ GIA ĐÌNH lâu năm | ⚠ không giải quyết triệt để được trong dự án | | ⚠ Đang ảnh hưởng tới tinh thần và năng suất cả đội | ⚠ phải xử lý ngay | | ⚠ Frank hành động với tư cách NGƯỜI QUẢN LÝ DỰ ÁN | ⚠ đề nêu rõ vai trò | | ⚠ Kết luận | ⚠ tìm một dàn xếp làm việc được cho cả hai, dù không ai hoàn toàn hài lòng |

⚠ Vì sao không nhắm tới giải pháp triệt để: ⚠ mâu thuẫn có gốc từ quan hệ gia đình nhiều năm nằm ngoài phạm vi mà một dự án có thể giải quyết ⚠ — ⚠ mục tiêu thực tế là làm cho họ LÀM VIỆC ĐƯỢC với nhau, không phải làm cho họ hoà thuận.

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

• A (thích ứng, cứ để họ làm theo cách họ muốn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ xoa dịu và thích ứng là một chiến lược hợp lệ, và trong một số hoàn cảnh nó đúng — liên hệ #27047 lô 206: ⚠ nhưng ⚠ ở đây "cách họ muốn" chính là làm những việc NGOÀI chặng hiện tại, tức là dự án đang bị thiệt hại thật ⚠; ⚠ thích ứng chỉ hợp lý khi cái giá của việc nhượng bộ là nhỏ, còn ở đây nó đang làm hỏng cả tinh thần lẫn năng suất của đội; ⚠ và nó cũng gửi tín hiệu tới cả đội rằng ai không thích làm việc cùng ai thì được phép tự chọn việc khác.

• B (ép họ làm theo lệnh) — ⚠ ép buộc với hai người khó thay thế là chiến thuật tồi; ⚠ và nó không giải quyết được nguyên nhân, chỉ đẩy mâu thuẫn xuống dưới.

• C (né tránh, để thời gian giải quyết) — ⚠ mâu thuẫn đang gây thiệt hại rõ ràng; ⚠ và đề không cho thấy dấu hiệu nào là nó sẽ tự hết.

Ghi nhớ

⚠ Ghi chú đối chiếu: ⚠ #27107 cùng lô cũng là hai thành viên không làm việc được với nhau, nhưng khoá ở đó là GẶP RIÊNG ĐỂ HIỂU NGUỒN CƠN ⚠ — ⚠ khác biệt nằm ở chỗ: ở #27107, Melissa CHƯA BIẾT nguyên nhân nên phải tìm hiểu trước; còn ở đây nguyên nhân đã rõ (quan hệ gia đình lâu năm) nên câu hỏi chuyển sang việc CHỌN CHIẾN LƯỢC; ⚠ hai câu tạo thành một cặp rất đáng đọc liền nhau: một câu về bước THU THẬP THÔNG TIN, một câu về bước RA QUYẾT ĐỊNH.

⚠ Đối chiếu: ⚠ #27107 cùng lô (gặp riêng khi chưa biết nguyên nhân), ⚠ #27047 lô 206 (xoa dịu khi quan hệ quan trọng hơn vấn đề), ⚠ #27074 lô 206 (dùng sai chiến lược làm vận tốc tụt), ⚠ #26979 lô 204 (giải quyết xung đột giữa hai bên).

⚠ Năm chiến lược và khi nào dùng: | Chiến lược | Phù hợp khi | |---|---| | ⚠ HỢP TÁC / giải quyết vấn đề | ⚠ có thời gian, hai bên thiện chí — tốt nhất về lâu dài | | ⚠ THOẢ HIỆP | ⚠ cần giải pháp làm việc được ngay, hai bên đều quan trọng — ĐÁP ÁN | | ⚠ XOA DỊU / thích ứng | ⚠ quan hệ quan trọng hơn vấn đề | | ⚠ ÉP BUỘC | ⚠ khẩn cấp hoặc vấn đề an toàn | | ⚠ NÉ TRÁNH | ⚠ vấn đề nhỏ hoặc cần hạ nhiệt | | ⚠ Vì sao không chọn hợp tác ở đây | ⚠ hợp tác đòi hỏi cả hai bên cùng muốn giải quyết vấn đề gốc — mà gốc ở đây là mâu thuẫn gia đình lâu năm, thứ mà họ có thể không muốn và cũng không có nghĩa vụ phải giải quyết trong bối cảnh công việc |

⚠ Thoả hiệp trong tình huống này trông thế nào: | Dàn xếp có thể | Nội dung | |---|---| | ⚠ Phân công để hai người ít phải phối hợp trực tiếp | ⚠ giảm điểm va chạm | | ⚠ Quy định kênh trao đổi chính thức giữa hai người | ⚠ qua bảng công việc thay vì nói trực tiếp | | ⚠ Mỗi người nhượng bộ một phần về cách làm việc | | | ⚠ Thoả thuận rõ: không mang chuyện riêng vào việc chung | | | ⚠ Điều Frank cần nói rõ với cả hai | ⚠ rằng cả hai đều được coi trọng và không ai bị đổ lỗi — nhưng việc họ tự chọn làm những thứ ngoài chặng là điều không thể tiếp tục, vì nó ảnh hưởng tới người khác |

⚠ Dấu hiệu cần chuyển sang biện pháp mạnh hơn: | Dấu hiệu | Nội dung | |---|---| | ⚠ Thoả hiệp đã thử mà tình hình không đổi | | | ⚠ Người khác trong đội bị kéo vào | ⚠ liên hệ #27107 cùng lô | | ⚠ Có hành vi vượt ranh giới ứng xử | ⚠ liên hệ #27098 cùng lô | | ⚠ Bước tiếp theo khi đó | ⚠ phối hợp với quản lý chức năng — nhưng chỉ sau khi đã thử các biện pháp trong tầm mình, và mang theo bằng chứng cụ thể chứ không phải cảm nhận chung |

Từ khoá nhận diện:

"hai người quan trọng, đã biết nguyên nhân, cần làm việc được ngay" → ⚠ THOẢ HIỆP "chưa biết nguyên nhân" → ⚠ GẶP RIÊNG để hiểu (xem #27107 cùng lô) "cứ để họ làm theo ý" → ⚠ dự án đang chịu thiệt hại thật "ép buộc" → ⚠ tồi với hai người khó thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai trong đội bạn đang tự chọn việc ngoài phạm vi chặng không | | | Bạn đã biết nguyên nhân mâu thuẫn hay mới chỉ thấy triệu chứng | | | Chiến lược bạn chọn có phù hợp với hoàn cảnh cụ thể không | |

Và điều mà một người quản lý dự án phải chấp nhận với những mâu thuẫn có gốc rễ ngoài công việc: mục tiêu không phải làm cho họ hoà thuận, mà làm cho dự án chạy được — và hai điều đó không phải lúc nào cũng đi cùng nhau.