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

Đáp án

C — ĐÚNG. CHÚNG TA COI TRỌNG CÁ NHÂN VÀ TƯƠNG TÁC HƠN QUY TRÌNH VÀ CÔNG CỤ.

Vì sao đúng

⚠ Nguyên văn giá trị thứ nhất của Tuyên ngôn Agile: | Thành phần | Nội dung | |---|---| | ⚠ "Cá nhân VÀ TƯƠNG TÁC" | ⚠ hai vế, không phải chỉ "cá nhân" | | ⚠ "hơn quy trình VÀ CÔNG CỤ" | ⚠ cũng hai vế | | ⚠ Chữ "hơn" nghĩa là ưu tiên khi xung đột | ⚠ không phải phủ nhận vế kia | | ⚠ Phương án C chép đúng nguyên văn | | | ⚠ Kết luận | ⚠ câu khẳng định trong đề là ĐÚNG, và C là cách diễn đạt chính xác nhất |

⚠ Chi tiết dễ bị bỏ qua: ⚠ giá trị này không nói "con người quan trọng, quy trình không quan trọng" ⚠ — ⚠ Tuyên ngôn ghi rõ "vế bên phải vẫn có giá trị"; chỉ là khi phải chọn thì chọn vế trái.

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

• D (Đúng. Chúng ta coi trọng cá nhân hơn tương tác) — ⚠ phương án gây nhiễu mạnh nhất, và là loại bẫy tinh vi nhất trong đề PMP: đúng phần kết luận, sai phần nội dung vì ⚠ nó bắt đầu bằng chữ "Đúng" giống đáp án, nên người đọc lướt sẽ dừng lại ở đó: ⚠ nhưng ⚠ nó tách đôi một cụm vốn đi liền và đặt hai nửa đối lập nhau: "cá nhân HƠN tương tác" ⚠; ⚠ Tuyên ngôn không hề so sánh cá nhân với tương tác — cả hai nằm CÙNG một vế, đứng đối lập với "quy trình và công cụ"; ⚠ bài học làm bài: với câu đúng/sai, phải đọc hết cả vế giải thích chứ không dừng ở chữ Đúng hay Sai.

• A (Sai. Coi trọng cá nhân nhưng phải tuân thủ giá trị của quy trình) — ⚠ kết luận sai; ⚠ vế giải thích còn hiểu nhầm chữ "hơn" thành "phải tuân thủ ngang nhau".

• B (Sai. Coi trọng khách hàng trước, tổ chức thứ hai, cá nhân cuối cùng) — ⚠ hoàn toàn bịa; ⚠ không có thứ tự xếp hạng nào như vậy trong bất kỳ tài liệu agile nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26937 cùng lô (tình huống thể hiện hai giá trị agile), ⚠ #26921 lô 203 (agile ưu tiên mặt đối mặt), ⚠ #26950 cùng lô (cả đội cùng giải quyết vấn đề), ⚠ #26960 cùng lô (lãnh đạo phụng sự và tài liệu vừa đủ).

⚠ BỐN GIÁ TRỊ, viết đầy đủ để khỏi nhầm: | Vế được ưu tiên | Vế vẫn có giá trị | |---|---| | ⚠ Cá nhân và tương tác | ⚠ quy trình và công cụ | | ⚠ Phần mềm chạy được | ⚠ tài liệu đầy đủ | | ⚠ Hợp tác với khách hàng | ⚠ thương lượng hợp đồng | | ⚠ Phản hồi thay đổi | ⚠ bám theo kế hoạch | | ⚠ Câu kết của Tuyên ngôn | ⚠ "Nghĩa là, trong khi các mục bên phải vẫn có giá trị, chúng tôi coi trọng các mục bên trái hơn" — câu này bị bỏ quên nhiều nhất, và chính nó ngăn agile bị hiểu thành làm việc không quy trình |

⚠ Những cách hiểu sai phổ biến về giá trị thứ nhất: | Hiểu sai | Thực tế | |---|---| | ⚠ "Agile không cần quy trình" | ⚠ scrum có quy trình rất chặt về nhịp và vai trò | | ⚠ "Agile không cần công cụ" | ⚠ công cụ vẫn dùng, chỉ không để công cụ quyết định cách làm việc | | ⚠ "Cá nhân quan trọng hơn tập thể" | ⚠ ngược lại, TƯƠNG TÁC giữa các cá nhân mới là trọng tâm | | ⚠ Phép thử đơn giản | ⚠ khi công cụ hay quy trình bắt đội làm điều vô lý, agile nói hãy đổi công cụ chứ đừng đổi cách đội làm việc cho vừa công cụ |

⚠ Vì sao "tương tác" mới là từ khoá thật: | Lý do | Nội dung | |---|---| | ⚠ Một tập hợp cá nhân giỏi không tự thành đội giỏi | | | ⚠ Phần lớn giá trị sinh ra ở chỗ hai người trao đổi | ⚠ liên hệ #26937 cùng lô | | ⚠ Quy trình có thể GIẾT tương tác | ⚠ bắt mọi trao đổi phải qua phiếu, qua biểu mẫu | | ⚠ Nhận xét | ⚠ đây là lý do agile đặt các buổi họp ngắn, đội ngồi gần nhau và làm việc trực tiếp lên hàng đầu — không phải vì ghét tài liệu, mà vì tương tác là thứ dễ bị quy trình bóp nghẹt nhất |

Từ khoá nhận diện:

"cá nhân và tương tác hơn quy trình và công cụ" → ⚠ nguyên văn giá trị thứ nhất "cá nhân hơn tương tác" → ⚠ BẪY, tách đôi một cụm đi liền "phải tuân thủ giá trị của quy trình" → ⚠ hiểu sai chữ "hơn" "khách hàng trước, tổ chức sau, cá nhân cuối" → ⚠ hoàn toàn BỊA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đọc lại được bốn giá trị theo đúng thứ tự không | | | Đội bạn có quy trình nào đang cản trở trao đổi trực tiếp không | | | Công cụ của bạn đang phục vụ đội hay đội đang phục vụ công cụ | |

Và điều mà câu kết bị lãng quên của Tuyên ngôn bảo vệ agile khỏi: bị hiểu thành sự tuỳ tiện — vì "coi trọng hơn" luôn khác với "không cần đến".

Đáp án

C — NHÓM TRỌNG TÂM (focus groups).

Vì sao đúng

⚠ Đặc điểm của nhóm trọng tâm: | Yếu tố | Nội dung | |---|---| | ⚠ BẮT BUỘC có người điều phối ĐƯỢC ĐÀO TẠO | ⚠ chi tiết khoá của câu hỏi | | ⚠ Nhóm nhỏ bên liên quan và chuyên gia được chọn trước | | | ⚠ Thảo luận TƯƠNG TÁC, có dẫn dắt | ⚠ không phải hỏi đáp lần lượt | | ⚠ Mục tiêu: hiểu kỳ vọng và thái độ về một sản phẩm | | | ⚠ Người điều phối giữ cho cuộc thảo luận không lạc đề và không bị một người lấn át | | | ⚠ Kết luận | ⚠ đây là kỹ thuật duy nhất trong bốn phương án mà tài liệu PMI gắn thẳng với "trained moderator" |

⚠ Vì sao cần người được đào tạo: ⚠ động lực nhóm rất dễ lệch — một người nói nhiều sẽ dẫn dắt cả nhóm, và ai cũng có xu hướng gật theo ý kiến đầu tiên ⚠ — ⚠ người điều phối chuyên nghiệp tồn tại để chống lại đúng hai hiện tượng đó.

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

• B (kỹ thuật nhóm danh nghĩa — nominal group technique) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là kỹ thuật nhóm, cũng cần người dẫn, và cái tên có chữ "nhóm" nghe rất gần: ⚠ nhưng ⚠ kỹ thuật nhóm danh nghĩa là quy trình có CẤU TRÚC CỨNG: mỗi người viết ý tưởng riêng, lần lượt nêu, rồi bỏ phiếu xếp hạng ⚠; ⚠ chính cấu trúc đó thay thế cho kỹ năng của người điều phối — ai cầm quy trình cũng chạy được; ⚠ trong khi nhóm trọng tâm là thảo luận MỞ, và chất lượng kết quả phụ thuộc gần như hoàn toàn vào tay nghề người dẫn.

• D (phỏng vấn) — ⚠ thường là một–một; ⚠ không có động lực nhóm nên không cần người điều phối chuyên nghiệp.

• A (phân tích quyết định đa tiêu chí) — ⚠ là kỹ thuật RA QUYẾT ĐỊNH bằng ma trận trọng số; ⚠ không phải kỹ thuật thu thập yêu cầu.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26903 lô 203 (kỹ thuật Delphi — ẩn danh, nhiều vòng), ⚠ #26965 cùng lô (wireframe để đạt đồng thuận về thiết kế), ⚠ #26892 lô 203 (thu hút mọi bên liên quan), ⚠ #26976 cùng lô (yêu cầu là nguồn cho ước lượng thô).

⚠ Các kỹ thuật thu thập yêu cầu, phân biệt nhanh: | Kỹ thuật | Đặc trưng | |---|---| | ⚠ NHÓM TRỌNG TÂM | ⚠ thảo luận mở, có người điều phối chuyên nghiệp — ĐÁP ÁN | | ⚠ Hội thảo hỗ trợ (JAD, QFD) | ⚠ nhiều bên liên quan cùng chốt yêu cầu trong một buổi | | ⚠ Phỏng vấn | ⚠ một–một, đào sâu, tốt cho chủ đề nhạy cảm | | ⚠ Bảng hỏi và khảo sát | ⚠ số lượng lớn, ở xa, thống kê được | | ⚠ Động não | ⚠ sinh ý tưởng số lượng lớn, chưa sàng lọc | | ⚠ Nhóm danh nghĩa | ⚠ động não CÓ cấu trúc + bỏ phiếu xếp hạng | | ⚠ Delphi | ⚠ chuyên gia ẨN DANH, nhiều vòng — liên hệ #26903 lô 203 | | ⚠ Quan sát / theo chân (job shadowing) | ⚠ thấy điều người ta LÀM chứ không phải điều họ NÓI | | ⚠ Mẹo phân biệt | ⚠ hỏi ba câu: có ẩn danh không (Delphi), có bỏ phiếu xếp hạng không (nhóm danh nghĩa), có người điều phối chuyên nghiệp dẫn thảo luận mở không (nhóm trọng tâm) |

⚠ Người điều phối được đào tạo làm gì: | Nhiệm vụ | Nội dung | |---|---| | ⚠ Giữ cuộc thảo luận đúng chủ đề | | | ⚠ Bảo đảm mọi người đều được nói | ⚠ chặn người lấn át | | ⚠ Hỏi câu mở, không dẫn dắt câu trả lời | | | ⚠ Trung lập — không bảo vệ giải pháp nào | ⚠ lý do nên dùng người ngoài đội dự án | | ⚠ Ghi nhận cả những ý kiến trái chiều | | | ⚠ Vì sao trung lập quan trọng | ⚠ người quản lý dự án tự điều phối nhóm trọng tâm về sản phẩm của mình sẽ vô thức lái cuộc thảo luận về phía giải pháp mình đã nghĩ ra — và điều tệ nhất là chính họ cũng không nhận ra |

⚠ Vì sao thu thập yêu cầu SỚM lại quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Chi phí sửa yêu cầu tăng theo giai đoạn | ⚠ liên hệ #26925 lô 203 về chi phí chất lượng | | ⚠ Bên liên quan đồng thuận sớm thì ít phản đối muộn | ⚠ liên hệ #26913 lô 203 | | ⚠ Yêu cầu rõ là nền của phạm vi, WBS và mọi ước lượng | ⚠ liên hệ #26910 lô 203 | | ⚠ Nhận xét | ⚠ đề mở đầu bằng "để bảo đảm bên liên quan đồng thuận với mục tiêu dự án" — đó chính là giá trị lớn nhất của việc thu thập yêu cầu, lớn hơn cả bản danh sách yêu cầu thu được |

Từ khoá nhận diện:

"người điều phối được đào tạo" → ⚠ NHÓM TRỌNG TÂM "viết riêng rồi bỏ phiếu xếp hạng" → ⚠ nhóm danh nghĩa "chuyên gia ẩn danh nhiều vòng" → ⚠ Delphi "ma trận trọng số để chọn phương án" → ⚠ quyết định đa tiêu chí, không phải thu thập yêu cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi lấy yêu cầu gần nhất của bạn ai điều phối | | | Có ai lấn át cuộc thảo luận không | | | Bạn có dùng nhiều hơn một kỹ thuật để đối chiếu không | |

Và lý do một người điều phối trung lập đáng giá hơn cả căn phòng đầy chuyên gia: vì thứ quyết định chất lượng của một buổi thu thập yêu cầu không phải ai có mặt, mà là ai được nói.

Đáp án

D — CHI PHÍ CHẤT LƯỢNG (cost of quality).

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ở cuối ⚠ — ⚠ dừng ở "This on-", chắc chắn là "This on-the-job training is an example of…"; ⚠ bối cảnh đã đủ để chọn đáp án.

Vì sao đúng

⚠ Đào tạo tại chỗ thuộc nhóm nào: | Yếu tố | Nội dung | |---|---| | ⚠ Mục đích: đội làm ĐÚNG ngay từ đầu với vật liệu mới | ⚠ ngăn lỗi, không phải sửa lỗi | | ⚠ Đây là chi phí PHÒNG NGỪA | ⚠ một nhánh của chi phí chất lượng | | ⚠ Vật liệu mới lại đắt tiền | ⚠ làm hỏng một mẻ là mất rất nhiều | | ⚠ Nhà tài trợ lo chi phí là ưu tiên số một | ⚠ nên phòng ngừa càng đáng giá | | ⚠ Kết luận | ⚠ đào tạo là khoản đầu tư để tránh chi phí không phù hợp lớn hơn về sau |

⚠ Chi phí chất lượng gồm cả bốn nhóm: ⚠ phòng ngừa, thẩm định, hỏng bên trong, hỏng bên ngoài ⚠ — ⚠ đào tạo nằm ở nhóm đầu tiên, nhóm rẻ nhất.

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

• B (chi phí không phù hợp — cost of non-conformance) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là một phần THẬT của chi phí chất lượng, nên người đọc nhanh sẽ thấy nó "cụ thể hơn" và chọn nó: ⚠ nhưng ⚠ chi phí KHÔNG PHÙ HỢP là tiền mất vì đã LÀM SAI: phế phẩm, làm lại, bảo hành, mất uy tín ⚠ — ⚠ đào tạo là chi phí PHÙ HỢP, tức là tiền bỏ ra để không phải mất khoản kia; ⚠ hai khái niệm này nằm ở hai phía đối lập nhau, và chọn nhầm nghĩa là hiểu ngược hoàn toàn; ⚠ nếu đề cho phương án "chi phí phù hợp" thì đó mới là câu trả lời chính xác nhất — nhưng trong bốn lựa chọn đã cho, "chi phí chất lượng" là khái niệm bao trùm đúng.

• A (chi phí biến đổi) — ⚠ phân loại theo cách chi phí thay đổi theo sản lượng; ⚠ đó là trục phân loại khác hẳn, không nói gì về mục đích của khoản chi.

• C (chi phí chung — overhead) — ⚠ là chi phí gián tiếp không gắn với một sản phẩm cụ thể; ⚠ đào tạo này gắn thẳng với vật liệu của chính dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26925 lô 203 (đào tạo trước là hành động phòng ngừa), ⚠ #26936 cùng lô (bảo vệ ngân sách đào tạo), ⚠ #26894 lô 203 (chất lượng được cải thiện), ⚠ #26938 cùng lô (đường cong học tập).

⚠ BỐN NHÓM chi phí chất lượng: | Nhóm | Ví dụ | |---|---| | ⚠ PHÒNG NGỪA (phù hợp) | ⚠ đào tạo, tài liệu quy trình, thiết bị đúng chuẩn — trường hợp này | | ⚠ THẨM ĐỊNH (phù hợp) | ⚠ kiểm tra, đo đạc, thử nghiệm, đánh giá | | ⚠ HỎNG BÊN TRONG (không phù hợp) | ⚠ phế phẩm, làm lại — phát hiện trước khi giao | | ⚠ HỎNG BÊN NGOÀI (không phù hợp) | ⚠ bảo hành, thu hồi, mất uy tín — sau khi giao | | ⚠ Quan hệ giữa các nhóm | ⚠ tăng chi cho hai nhóm đầu thường làm giảm mạnh hai nhóm sau, và tổng chi phí chất lượng đi xuống — đó là toàn bộ lập luận cho việc chi tiền đào tạo |

⚠ Vì sao vật liệu đắt tiền làm phòng ngừa càng đáng giá: | Yếu tố | Nội dung | |---|---| | ⚠ Một mẻ hỏng mất cả tiền vật liệu lẫn công | | | ⚠ Vật liệu mới thường khó mua lại nhanh | ⚠ kéo theo chậm tiến độ | | ⚠ Đội chưa quen nên xác suất hỏng cao ở giai đoạn đầu | ⚠ liên hệ #26938 cùng lô về đường cong học tập | | ⚠ Cách trình bày với nhà tài trợ | ⚠ so chi phí đào tạo với chi phí của MỘT mẻ hỏng — nếu buổi đào tạo rẻ hơn một lần làm hỏng thì lập luận tự nó đứng vững, không cần bàn về nguyên tắc |

⚠ Vì sao "đào tạo tại chỗ" là lựa chọn hợp lý ở đây: | Ưu điểm | Nội dung | |---|---| | ⚠ Học trên đúng vật liệu sẽ dùng thật | ⚠ không có khoảng cách giữa lớp học và công trường | | ⚠ Cả đội học CÙNG NHAU, chuẩn thống nhất | ⚠ đề nhấn mạnh chữ "collectively" | | ⚠ Rẻ hơn khoá đào tạo bên ngoài | ⚠ phù hợp với ưu tiên chi phí của nhà tài trợ | | ⚠ Tri thức ở lại trong tổ chức | ⚠ liên hệ #26920 lô 203 và #26948 cùng lô | | ⚠ Nhận xét | ⚠ người quản lý này đã tìm được cách vừa tôn trọng ưu tiên chi phí của nhà tài trợ vừa không bỏ qua rủi ro tay nghề — đó mới là câu trả lời đúng cho một ràng buộc, thay vì chọn một trong hai |

Từ khoá nhận diện:

"đào tạo để làm đúng ngay từ đầu" → ⚠ CHI PHÍ CHẤT LƯỢNG, nhánh PHÒNG NGỪA "chi phí không phù hợp" → ⚠ tiền mất vì đã làm sai, ngược với đào tạo "chi phí biến đổi" → ⚠ trục phân loại theo sản lượng, không liên quan "chi phí chung" → ⚠ gián tiếp, không gắn với sản phẩm cụ thể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngân sách của bạn có tách riêng chi phí chất lượng không | | | Bạn ước tính được chi phí của một lần làm lại không | | | Khoản phòng ngừa nào của bạn đang bị coi là "cắt được" | |

Và điều mà khái niệm chi phí chất lượng thay đổi trong cách nhìn về ngân sách: đào tạo không phải một khoản chi thêm, nó là khoản chi rẻ hơn được chọn thay cho khoản chi đắt hơn mà bạn chưa nhìn thấy.

Đáp án

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

Vì sao đúng

⚠ Ba dấu hiệu cho thấy dự án đã đóng: | Dấu hiệu | Nội dung | |---|---| | ⚠ Đội đã HOÀN THÀNH toàn bộ công việc | ⚠ 8.453 tay nắm cửa đã làm xong | | ⚠ Khách hàng đã CHẤP NHẬN sản phẩm bàn giao | ⚠ nghiệm thu chính thức | | ⚠ Khách hàng đã KÝ nhận công việc dự án | ⚠ chữ ký là mốc kết thúc | | ⚠ Phạm vi KHÔNG bao gồm việc lắp đặt | ⚠ đó là dự án của đội khác | | ⚠ Kết luận | ⚠ phạm vi đã hoàn thành và được chấp nhận thì lời đề nghị của người khác không tạo ra nghĩa vụ mới |

⚠ Việc chở hàng sang giúp là một phép lịch sự, không phải một phần phạm vi: ⚠ và một phép lịch sự không mở rộng phạm vi ⚠ — ⚠ đây chính là cách "phình phạm vi" (scope creep) bắt đầu: từ một việc nhỏ làm giúp.

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

• D (hỏi khách hàng xem họ có muốn thuê bạn lắp đặt không, có tính phí) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có vẻ vừa chuyên nghiệp vừa nhạy bén kinh doanh: không làm không công, mà lại mở ra cơ hội doanh thu mới: ⚠ nhưng ⚠ câu hỏi là "bạn NÊN LÀM GÌ" trong tình huống trước mặt, và câu trả lời đúng về mặt quản lý dự án là dự án này đã đóng ⚠; ⚠ việc bán thêm dịch vụ là một DỰ ÁN MỚI với hợp đồng mới, và nó không phải việc bạn khởi xướng ngay tại chỗ khi vừa chở hàng tới ⚠; ⚠ nếu tổ chức của bạn muốn theo đuổi cơ hội đó thì nó đi qua bộ phận kinh doanh, không đi qua một cuộc trò chuyện ở bãi giao hàng.

• B (không làm gì vì đội đã chuyển sang dự án khác) — ⚠ kết luận đúng nhưng LÝ DO sai; ⚠ dự án kết thúc vì phạm vi đã hoàn thành và được nghiệm thu, không phải vì đội bận việc khác — nếu lý do là "bận" thì hàm ý rằng rảnh thì phải làm.

• C (làm yêu cầu thay đổi để thêm việc lắp đặt) — ⚠ không thể thay đổi một dự án đã ĐÓNG; ⚠ và việc này thuộc phạm vi của dự án khác, không thuộc dự án bạn.

Ghi nhớ

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

⚠ Đối chiếu: ⚠ #26899 lô 203 (nghiệm thu chấp nhận sản phẩm), ⚠ #26964 cùng lô (thay đổi phải cập nhật đường cơ sở), ⚠ #26955 cùng lô (bên liên quan tự ý nhận việc thay đội), ⚠ #26979 cùng lô (nhà cung cấp và ranh giới hợp đồng).

⚠ Vì sao lý do đúng lại quan trọng như đáp án đúng: | Lý do được nêu | Hàm ý | |---|---| | ⚠ "Dự án đã xong" | ⚠ ranh giới phạm vi rõ ràng, đúng — ĐÁP ÁN | | ⚠ "Đội đang bận việc khác" | ⚠ ngụ ý rằng nếu rảnh thì sẽ làm — mở cửa cho phình phạm vi | | ⚠ Bài học | ⚠ cách bạn TỪ CHỐI quyết định việc lần sau người ta có hỏi nữa hay không, và hỏi với kỳ vọng thế nào — nên hãy từ chối bằng ranh giới, đừng từ chối bằng sự bận rộn |

⚠ Đóng dự án gồm những gì: | Việc | Nội dung | |---|---| | ⚠ Nghiệm thu chính thức sản phẩm bàn giao | ⚠ có chữ ký — đã làm xong | | ⚠ Đóng toàn bộ hợp đồng mua sắm | | | ⚠ Ghi lại bài học kinh nghiệm | ⚠ liên hệ #26925 lô 203 | | ⚠ Giải phóng nguồn lực | | | ⚠ Lưu trữ hồ sơ dự án | ⚠ liên hệ #26949 cùng lô về giá trị của hồ sơ | | ⚠ Nguyên tắc | ⚠ sau khi những việc này hoàn tất, mọi yêu cầu mới là một dự án mới — dù nó nhỏ đến đâu và người hỏi thân thiện đến đâu |

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

Từ khoá nhận diện:

"khách đã chấp nhận và ký nhận" → ⚠ dự án ĐÃ ĐÓNG "làm giúp một việc nhỏ" → ⚠ không mở rộng phạm vi "đội đang bận việc khác" → ⚠ kết luận đúng, lý do sai "bán thêm dịch vụ có tính phí" → ⚠ là dự án MỚI, không phải việc xử lý tại chỗ

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

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

Đáp án

A — TRÍ TUỆ CẢM XÚC (Emotional Intelligence).

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT giữa câu ⚠ — ⚠ dừng ở "they feel disconnected from…", nhiều khả năng là "…from the work" hoặc "…from Christopher"; ⚠ câu hỏi ẩn chắc chắn là "Christopher còn thiếu điều gì".

Vì sao đúng

⚠ Chân dung một người thiếu trí tuệ cảm xúc: | Dữ kiện trong đề | Ý nghĩa | |---|---| | ⚠ Dự án luôn đúng hạn, đúng ngân sách, vượt kỳ vọng | ⚠ năng lực chuyên môn không phải vấn đề | | ⚠ Chuyên gia ở nhiều lĩnh vực | ⚠ kiến thức không phải vấn đề | | ⚠ LUÔN CÓ CÂU TRẢ LỜI NGẮN GỌN cho mọi câu hỏi | ⚠ dấu hiệu quan trọng nhất — anh ấy không hỏi lại, không lắng nghe | | ⚠ Đội kiệt sức sau một hai năm rồi xin chuyển | ⚠ kết quả lặp lại, không phải ngẫu nhiên | | ⚠ KHÔNG ai tố cáo anh ấy sai phạm gì | ⚠ loại trừ hành vi xấu — vấn đề tinh tế hơn | | ⚠ Họ nói họ cảm thấy "bị mất kết nối" | ⚠ chính là ngôn ngữ của thiếu kết nối cảm xúc | | ⚠ Kết luận | ⚠ giỏi việc nhưng không đọc được con người — định nghĩa của thiếu trí tuệ cảm xúc |

⚠ Chi tiết đắt nhất: ⚠ "luôn có câu trả lời ngắn gọn" ⚠ — ⚠ nghe như lời khen nhưng thật ra là mô tả một người trả lời thay vì lắng nghe, khiến đội không bao giờ được tham gia vào việc nghĩ; liên hệ #26941 cùng lô về Alice.

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

• D (không thiếu gì cả, vì dự án của anh ấy vẫn hoàn thành) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó dựa vào một sự thật không thể chối cãi: các chỉ số dự án của Christopher đều rất đẹp, và trong nhiều tổ chức thì đó là toàn bộ thước đo: ⚠ nhưng ⚠ nó bỏ qua một chi phí không nằm trong báo cáo nào: tổ chức mất trắng cả đội sau mỗi hai năm ⚠ — ⚠ chi phí tuyển mới, đào tạo lại, tri thức mất theo người ra đi (liên hệ #26948 cùng lô) đều lớn hơn nhiều so với phần "vượt kỳ vọng" mà anh ấy tạo ra; ⚠ và mô hình này không bền: sớm hay muộn sẽ tới lúc không ai muốn vào đội của anh ấy nữa.

• B (bedside manner — cách cư xử với bệnh nhân) — ⚠ là cách nói dân dã trong ngành y; ⚠ nó mô tả một phần biểu hiện nhưng không phải khái niệm chuẩn trong quản lý dự án.

• C (phương pháp agile) — ⚠ không liên quan; ⚠ vấn đề của Christopher không thay đổi dù dùng dự đoán hay agile.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26696 lô 199 (trí tuệ cảm xúc), ⚠ #26927 lô 203 (thấu cảm), ⚠ #26941 cùng lô (không được tham gia quyết định thì mất gắn kết), ⚠ #26940 cùng lô (giao tiếp là kỹ năng quan trọng nhất).

⚠ BỐN THÀNH PHẦN của trí tuệ cảm xúc: | Thành phần | Nội dung | |---|---| | ⚠ Tự nhận thức | ⚠ hiểu cảm xúc và tác động của chính mình — chỗ Christopher yếu nhất | | ⚠ Tự điều chỉnh | ⚠ kiểm soát phản ứng của mình | | ⚠ Nhận thức xã hội (thấu cảm) | ⚠ đọc được cảm xúc người khác | | ⚠ Quản lý quan hệ | ⚠ xây dựng và duy trì kết nối | | ⚠ Điều đáng chú ý | ⚠ Christopher hoàn toàn không biết đội mình đang mòn dần — đó là lỗi ở thành phần THỨ NHẤT, và chính vì thiếu tự nhận thức mà anh ấy không có lý do gì để thay đổi |

⚠ Vì sao "luôn có câu trả lời" lại làm hỏng đội: | Hệ quả | Nội dung | |---|---| | ⚠ Đội thôi suy nghĩ, chỉ chờ được bảo | ⚠ liên hệ #26915 lô 203 về văn hoá chỉ đạo | | ⚠ Không ai được học từ việc tự giải quyết vấn đề | ⚠ nên không ai phát triển | | ⚠ Người giỏi thấy mình không được dùng đến | ⚠ và họ là những người ra đi đầu tiên | | ⚠ Sự đóng góp của đội trở nên vô hình | ⚠ thành công luôn mang tên Christopher | | ⚠ Điều Christopher nên thử | ⚠ im lặng năm giây và hỏi "anh chị nghĩ nên làm thế nào" trước khi đưa ra câu trả lời của mình — thay đổi nhỏ đó thường tạo khác biệt lớn nhất, dù rất khó với người quen biết đáp án |

⚠ Vì sao tổ chức nên coi đây là vấn đề nghiêm trọng: | Chi phí ẩn | Nội dung | |---|---| | ⚠ Tuyển và đào tạo người thay thế | ⚠ thường bằng vài tháng lương | | ⚠ Tri thức ra đi cùng người | ⚠ liên hệ #26920 lô 203 và #26948 cùng lô | | ⚠ Năng suất đội mới thấp trong nhiều tháng | ⚠ đường cong học tập lại từ đầu — #26938 cùng lô | | ⚠ Tiếng xấu lan trong tổ chức | | | ⚠ Nhận xét | ⚠ các chỉ số dự án đo được thứ Christopher tạo ra, nhưng không đo được thứ anh ấy tiêu hao — và một tổ chức chỉ nhìn vào cột thứ nhất sẽ tiếp tục thăng chức cho đúng kiểu người này |

Từ khoá nhận diện:

"giỏi việc nhưng đội cứ kiệt sức rồi bỏ đi" → ⚠ thiếu TRÍ TUỆ CẢM XÚC "không ai tố cáo hành vi sai" → ⚠ loại trừ vấn đề đạo đức, chỉ còn vấn đề kết nối "dự án vẫn xong nên không sao" → ⚠ bỏ qua chi phí ẩn của việc mất người "luôn có câu trả lời ngắn gọn" → ⚠ dấu hiệu của người không lắng nghe

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội của bạn có ai đã ở lâu hơn hai năm không | | | Bạn trả lời trước hay hỏi trước khi có người mang vấn đề tới | | | Bạn có biết ai trong đội đang mất kết nối không | |

Và điều mà một chuỗi dự án thành công không bao giờ hiển thị: những người đã rời đi để tạo ra nó — và họ chỉ xuất hiện trong sổ sách của bộ phận nhân sự, không bao giờ trong báo cáo dự án.

Đáp án

B — LẬP TRÌNH ĐÔI (pair programming).

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ⚠ — ⚠ dừng ở "To better manage the knowledge and fill this skill ga…", tức là "…gap, what should Juliette recommend?"; ⚠ ý câu hỏi đã rõ hoàn toàn.

Vì sao đúng

⚠ Vì sao lập trình đôi giải đúng vấn đề: | Vấn đề trong đề | Cách lập trình đôi xử lý | |---|---| | ⚠ Tỷ lệ nghỉ việc cao, người đi mang tri thức theo | ⚠ luôn có ÍT NHẤT HAI người biết mỗi phần | | ⚠ Người mới khó xử lý vấn đề nghiệp vụ cũ | ⚠ học trực tiếp từ người đang làm | | ⚠ Tri thức để gỡ lỗi và ra quyết định thiết kế đã mất | ⚠ đây là tri thức ẨN, chỉ truyền được bằng cùng làm | | ⚠ Nhiều dự án ngắn chạy song song | ⚠ không đủ thời gian viết tài liệu đầy đủ | | ⚠ Kết luận | ⚠ lập trình đôi biến việc truyền tri thức thành một phần của công việc hằng ngày, không cần dự án riêng |

⚠ Điểm mấu chốt: ⚠ thứ tổ chức này mất là tri thức ẨN — kinh nghiệm gỡ lỗi, lý do đằng sau các quyết định thiết kế ⚠ — ⚠ và tri thức ẩn không viết tài liệu được, nó chỉ truyền được qua việc cùng làm; liên hệ #26920 lô 203.

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

• D (phát triển hướng kiểm thử — TDD) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó CÓ tạo ra một dạng tài liệu sống: bộ kiểm thử mô tả hành vi mong đợi của hệ thống, và điều đó thật sự giúp người mới hiểu mã: ⚠ nhưng ⚠ kiểm thử ghi lại hệ thống LÀM GÌ, chứ không ghi lại VÌ SAO nó được thiết kế như vậy ⚠ — ⚠ mà "vì sao" mới chính là thứ đề nói đã mất đi: lý do đằng sau các quyết định thiết kế; ⚠ TDD là thực hành rất tốt và nên có, nhưng nó xử lý chất lượng mã chứ không xử lý khoảng trống tri thức giữa người cũ và người mới.

• C (tích hợp liên tục) — ⚠ giải quyết vấn đề gộp mã và phát hiện lỗi sớm; ⚠ không liên quan tới việc truyền tri thức giữa người với người.

• A (divergence — phân kỳ) — ⚠ là giai đoạn mở rộng ý tưởng trong tư duy thiết kế; ⚠ không phải một thực hành quản lý tri thức.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26920 lô 203 (tri thức mức cá nhân, tri thức ẩn), ⚠ #26947 cùng lô (mất người là mất tri thức), ⚠ #26864 lô 202 (chia sẻ tri thức trong đội), ⚠ #26938 cùng lô (người mới bắt đầu lại từ đầu đường cong học tập).

⚠ Lập trình đôi mang lại gì ngoài việc truyền tri thức: | Lợi ích | Nội dung | |---|---| | ⚠ Rà soát mã diễn ra LIÊN TỤC | ⚠ không cần hàng đợi chờ review — liên hệ #26924 lô 203 | | ⚠ Ít lỗi hơn ngay từ đầu | | | ⚠ Người mới hoà nhập nhanh hơn nhiều | | | ⚠ Giảm "điểm chết một người" | ⚠ không ai là người duy nhất biết một mảng | | ⚠ Chuẩn mã và cách làm thống nhất tự nhiên | | | ⚠ Phản biện thường gặp | ⚠ "hai người làm một việc thì tốn gấp đôi" — nhưng phép so sánh đúng phải tính cả thời gian rà soát mã, thời gian sửa lỗi lọt lưới và thời gian đào tạo người mới, và khi tính đủ thì khoảng cách hẹp lại rất nhiều |

⚠ Các cách khác để giữ tri thức, dùng kèm được: | Cách | Ghi chú | |---|---| | ⚠ Luân phiên công việc | ⚠ không ai độc quyền một mảng lâu | | ⚠ Lập trình theo bầy (mob programming) | ⚠ cả đội cùng một bài toán, hiệu quả truyền tri thức cao nhất | | ⚠ Ghi lại QUYẾT ĐỊNH KIẾN TRÚC và lý do | ⚠ ngắn gọn, đúng thứ mà đề nói đang thiếu | | ⚠ Phỏng vấn bàn giao trước khi nghỉ | ⚠ liên hệ #26920 lô 203 | | ⚠ Kho tri thức tra cứu được | ⚠ liên hệ #26926 lô 203 về truyền thông kéo | | ⚠ Lời khuyên tổng hợp cho Juliette | ⚠ lập trình đôi xử lý phần tri thức ẩn, còn ghi lại lý do của các quyết định thiết kế xử lý phần tri thức hiện — cần cả hai, nhưng chỉ có cái thứ nhất hoạt động được khi người ta nghỉ đột ngột |

⚠ Vì sao tỷ lệ nghỉ việc cao là vấn đề gốc: | Ý nghĩa | Nội dung | |---|---| | ⚠ Lập trình đôi GIẢM THIỆT HẠI, không chữa nguyên nhân | | | ⚠ Juliette nên nêu cả nguyên nhân với lãnh đạo | ⚠ vì sao người ta nghỉ nhiều đến vậy | | ⚠ Tổ chức đang chuyển sang agile, đây là cơ hội | | | ⚠ Nhận xét | ⚠ một tổ chức mất người liên tục thì mọi thực hành kỹ thuật chỉ là băng cứu thương — nhưng băng cứu thương vẫn cần thiết trong lúc chờ chữa vết thương thật, và lập trình đôi là loại băng tốt nhất trong bốn phương án |

Từ khoá nhận diện:

"người nghỉ mang tri thức đi, người mới không xử lý được" → ⚠ LẬP TRÌNH ĐÔI "phát triển hướng kiểm thử" → ⚠ ghi lại hệ thống LÀM GÌ, không ghi VÌ SAO "tích hợp liên tục" → ⚠ vấn đề gộp mã, không phải tri thức "divergence" → ⚠ giai đoạn tư duy thiết kế, không phải quản lý tri thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong đội bạn có mảng nào chỉ một người hiểu không | | | Lý do của các quyết định thiết kế lớn được ghi ở đâu | | | Người mới của bạn mất bao lâu để tự xử lý được một lỗi | |

Và lý do lập trình đôi thắng mọi tài liệu trong việc giữ tri thức: vì thứ quý nhất trong đầu một lập trình viên kỳ cựu không phải là điều họ biết, mà là cách họ nghĩ khi gặp một vấn đề chưa từng thấy — và điều đó chỉ nhìn thấy được khi ngồi cạnh họ.

Đáp án

B — ĐỌC KỸ TOÀN BỘ TÀI LIỆU KẾ HOẠCH VÀ HỒ SƠ DỰ ÁN.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ⚠ — ⚠ dừng ở "You also experience other stakeholders that are keeping th…", nhiều khả năng là "…keeping their distance"; ⚠ bối cảnh đã đủ rõ: bạn bị cô lập cả từ đội lẫn từ bên liên quan.

Vì sao đúng

⚠ Vì sao hồ sơ dự án là nơi bắt đầu đúng: | Lý do | Nội dung | |---|---| | ⚠ Đó là nguồn thông tin KHÔNG phụ thuộc vào ai muốn nói chuyện với bạn | ⚠ quan trọng nhất trong tình huống này | | ⚠ Cho biết phạm vi, đường cơ sở, rủi ro, quyết định đã ra | | | ⚠ Cho biết dự án đã lệch ở đâu và từ khi nào | | | ⚠ Cho bạn NGỮ CẢNH để hỏi những câu đúng | ⚠ và câu hỏi đúng mới mở được cánh cửa với đội | | ⚠ Làm được ngay, không cần ai cho phép | | | ⚠ Kết luận | ⚠ khi con người chưa sẵn sàng nói, hãy bắt đầu từ tài liệu — rồi dùng chính hiểu biết đó để xây lại quan hệ |

⚠ Vì sao đội không hợp tác là điều dễ hiểu: ⚠ họ trung thành với người quản lý cũ và đang giận về cách chuyện đã xảy ra ⚠ — ⚠ đó là phản ứng bình thường trước mất mát, không phải sự chống đối cá nhân nhắm vào bạn.

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

• A (bạn phải làm lại từ đầu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ dự án đang có vấn đề nghiêm trọng và đội thì không hợp tác, nên "xoá đi làm lại" nghe như một khởi đầu sạch sẽ và dứt khoát: ⚠ nhưng ⚠ nó vứt bỏ toàn bộ công sức đã bỏ ra, toàn bộ đường cơ sở và toàn bộ bài học đã tích luỹ ⚠; ⚠ và về mặt quan hệ với đội, đó là hành động tệ nhất có thể làm: nó tuyên bố rằng mọi thứ họ làm cùng người quản lý cũ đều vô giá trị ⚠ — ⚠ một đội vốn đã không chào đón bạn sẽ chuyển sang thù địch hẳn.

• C (gọi người quản lý cũ nhờ giúp) — ⚠ người đó vừa bị sa thải vì lý do hiệu suất; ⚠ thông tin sẽ thiên lệch, và việc này cũng đặt cả bạn lẫn tổ chức vào tình thế khó xử.

• D (cứ làm tiếp, vấn đề rồi sẽ tự lộ ra) — ⚠ thụ động trong khi lãnh đạo cấp cao đang trông đợi bạn xoay chuyển tình thế; ⚠ vấn đề sẽ lộ ra, nhưng lộ ra dưới dạng sự cố.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26938 cùng lô (hồ sơ và bài học của dự án trước), ⚠ #26925 lô 203 (đọc sổ bài học trước khi hành động), ⚠ #26927 lô 203 (thấu cảm khi làm việc với con người), ⚠ #26941 cùng lô (đội mất gắn kết vì cảm thấy bị gạt ra).

⚠ Nên đọc gì trước, theo thứ tự: | Tài liệu | Cho biết gì | |---|---| | ⚠ Điều lệ dự án | ⚠ mục tiêu, thẩm quyền, nhà tài trợ | | ⚠ Kế hoạch quản lý dự án và các đường cơ sở | ⚠ lẽ ra dự án phải ở đâu lúc này | | ⚠ Báo cáo tình trạng gần nhất | ⚠ dự án đang thật sự ở đâu | | ⚠ Sổ rủi ro và sổ vấn đề | ⚠ cái gì đã được biết trước mà không xử lý | | ⚠ Nhật ký thay đổi | ⚠ phạm vi đã trôi đi thế nào | | ⚠ Danh sách bên liên quan | ⚠ ai là ai, ai có ảnh hưởng | | ⚠ Điều cần tìm nhất | ⚠ khoảng cách giữa báo cáo và thực tế — nếu người quản lý cũ bị sa thải vì hiệu suất, rất có thể các báo cáo đã lạc quan hơn tình hình thật, và đó là điều bạn phải xác minh trước tiên |

⚠ Sau khi đọc xong thì làm gì với đội: | Bước | Nội dung | |---|---| | ⚠ Gặp riêng từng người, chủ yếu để NGHE | ⚠ không hứa hẹn, không phê phán người cũ | | ⚠ Thừa nhận rằng thay đổi này khó với họ | ⚠ liên hệ #26927 lô 203 về thấu cảm | | ⚠ Hỏi họ điều gì đang cản trở công việc | ⚠ rồi dọn thật một vật cản, càng sớm càng tốt | | ⚠ Không nói xấu người quản lý cũ, một lời cũng không | ⚠ họ vẫn trung thành với người đó | | ⚠ Cách nhanh nhất để có lòng tin | ⚠ giải quyết được MỘT vấn đề mà họ đã than phiền từ lâu — hành động đó nói nhiều hơn bất kỳ bài phát biểu nhận nhiệm vụ nào |

⚠ Vì sao bên liên quan cũng đang giữ khoảng cách: | Nguyên nhân | Cách xử lý | |---|---| | ⚠ Họ đã mất niềm tin vào dự án | ⚠ đưa ra số liệu thật, không hứa suông | | ⚠ Họ chưa biết bạn là ai | ⚠ gặp từng người, nghe kỳ vọng của họ | | ⚠ Họ chờ xem bạn có trụ được không | ⚠ giao được một kết quả nhỏ và sớm | | ⚠ Nhận xét | ⚠ là người quản lý thuê ngoài, bạn không có quyền lực chức vụ lẫn quan hệ sẵn có — nên thứ duy nhất bạn có thể xây nhanh là UY TÍN, và uy tín bắt đầu từ việc bạn nắm dự án chắc hơn bất kỳ ai trong phòng |

Từ khoá nhận diện:

"nhận lại dự án, không ai chịu nói chuyện" → ⚠ ĐỌC KỸ HỒ SƠ trước "làm lại từ đầu" → ⚠ vứt bỏ công sức và xúc phạm đội "gọi PM cũ" → ⚠ thông tin thiên lệch, tình thế khó xử "cứ làm rồi vấn đề sẽ lộ" → ⚠ thụ động trong lúc bị trông đợi xoay chuyển

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hồ sơ dự án của bạn có đủ để người khác tiếp quản không | | | Báo cáo tình trạng của bạn có khớp với thực tế không | | | Nếu bạn nghỉ ngày mai, người kế nhiệm sẽ đọc gì | |

Và điều mà một bộ hồ sơ dự án đầy đủ trao cho người tiếp quản khi không ai muốn nói chuyện: một cách để hiểu dự án mà không cần xin phép ai — và đó thường là bước đầu tiên để người ta bắt đầu chịu nói chuyện.

Đáp án

D — ĐỂ TẠO SỰ ĐỒNG THUẬN: CẢ NHÓM CÙNG NHAU NHẬN DIỆN, CHẨN ĐOÁN VÀ CUỐI CÙNG GIẢI QUYẾT VẤN ĐỀ.

Vì sao đúng

⚠ Vì sao kéo cả đội vào lại hiệu quả: | Lý do | Nội dung | |---|---| | ⚠ Người tham gia tìm ra giải pháp sẽ CAM KẾT thực hiện nó | ⚠ đây là ý chính — "buy-in" | | ⚠ Người làm việc hằng ngày biết vật cản thật nằm ở đâu | ⚠ lãnh đạo thường chỉ thấy triệu chứng | | ⚠ Ba bước đầy đủ: nhận diện, chẩn đoán, giải quyết | ⚠ cả đội tham gia cả ba, không chỉ bước cuối | | ⚠ Đội tự tổ chức là nguyên tắc nền của agile | | | ⚠ Kết luận | ⚠ giải pháp do đội tìm ra được thực hiện tốt hơn giải pháp hay hơn nhưng do người khác áp xuống |

⚠ Chi tiết quan trọng trong đáp án: ⚠ nó nêu cả BA bước, không chỉ bước sinh giải pháp ⚠ — ⚠ rất nhiều vấn đề bị chẩn đoán sai ngay từ đầu, và chỉ người trực tiếp làm mới phát hiện ra điều đó.

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

• B (đội sẽ đưa ra nhiều giải pháp hơn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó ĐÚNG về mặt sự thật: nhiều người tham gia thì đúng là sinh ra nhiều phương án hơn, đó là lập luận cơ bản của động não: ⚠ nhưng ⚠ nó chỉ nêu MỘT lợi ích phụ, còn lý do chính mà agile kéo cả đội vào là SỰ ĐỒNG THUẬN ⚠; ⚠ nếu chỉ cần nhiều ý tưởng thì Maurice có thể thu thập ý kiến qua bảng hỏi hoặc hỏi riêng từng người, không cần họp cả đội; ⚠ thứ chỉ có được khi cùng ngồi với nhau là cảm giác rằng đây là giải pháp CỦA CHÚNG TA — và đó mới là thứ quyết định nó có được thực hiện hay không.

• A (họp sẽ ngắn hơn khi có cả đội) — ⚠ ngược lại; ⚠ càng đông càng lâu, đó là cái giá phải trả để đổi lấy sự đồng thuận.

• C (giải pháp lý thuyết tốt nhất đến từ lập trình viên) — ⚠ mâu thuẫn với chính câu hỏi; ⚠ đề đang nói về việc mời TOÀN ĐỘI chứ không phải đề cao một vai trò.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26941 cùng lô (không được tham gia quyết định thì mất cam kết), ⚠ #26937 cùng lô (cùng ngồi làm rõ vấn đề tại chỗ), ⚠ #26905 lô 203 (cả đội dự buổi cải tiến), ⚠ #26898 lô 203 (phân tích nguyên nhân gốc).

⚠ Ba bước của một buổi giải quyết vấn đề tốt: | Bước | Nội dung | |---|---| | ⚠ NHẬN DIỆN | ⚠ mô tả đúng vấn đề đang gặp, bằng dữ kiện | | ⚠ CHẨN ĐOÁN | ⚠ tìm nguyên nhân GỐC, không dừng ở triệu chứng | | ⚠ GIẢI QUYẾT | ⚠ chọn phương án và phân công người làm | | ⚠ Sai lầm phổ biến nhất | ⚠ nhảy thẳng vào bước ba — cả phòng bàn giải pháp cho một vấn đề chưa ai định nghĩa giống nhau, và đó là cách một cuộc họp hai tiếng kết thúc mà không ai biết đã quyết cái gì |

⚠ Vì sao sự đồng thuận quan trọng hơn chất lượng giải pháp: | So sánh | Kết quả | |---|---| | ⚠ Giải pháp 8 điểm mà đội tin và làm hết sức | ⚠ thường thắng | | ⚠ Giải pháp 10 điểm mà đội thấy bị áp đặt | ⚠ thường thất bại khi triển khai | | ⚠ Lý do | ⚠ mọi giải pháp đều cần điều chỉnh khi va vào thực tế, và chỉ người TIN vào nó mới chịu điều chỉnh thay vì chờ nó hỏng để chứng minh mình đúng |

⚠ Vai trò của Maurice trong buổi họp này: | Nên làm | Không nên làm | |---|---| | ⚠ Điều phối, giữ cho buổi họp đi đúng ba bước | ⚠ đưa sẵn giải pháp của mình ngay từ đầu | | ⚠ Bảo đảm người ít nói cũng được nêu ý kiến | ⚠ để một người lấn át — liên hệ #26944 cùng lô | | ⚠ Ghi lại quyết định và người chịu trách nhiệm | ⚠ kết thúc mà không có hành động cụ thể | | ⚠ Bảo vệ nguyên tắc không đổ lỗi | ⚠ để buổi họp thành cuộc truy tìm thủ phạm | | ⚠ Chi tiết quyết định thành bại | ⚠ nếu người lãnh đạo nói ra ý mình TRƯỚC, phần lớn cuộc thảo luận sau đó chỉ là mọi người tìm cách đồng ý với ý đó — nên hãy nói sau cùng, hoặc tốt hơn là đừng nói |

Từ khoá nhận diện:

"vì sao mời cả đội chứ không chỉ vài người" → ⚠ tạo SỰ ĐỒNG THUẬN "nhiều giải pháp hơn" → ⚠ đúng nhưng chỉ là lợi ích phụ "họp sẽ ngắn hơn" → ⚠ ngược lại, đông thì lâu hơn "lập trình viên có giải pháp tốt nhất" → ⚠ mâu thuẫn với ý cả đội cùng tham gia

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vật cản gần nhất của đội bạn do ai chẩn đoán | | | Trong buổi họp gần nhất, bạn nói ý mình vào lúc nào | | | Có ai trong đội chưa từng nêu ý kiến trong các buổi đó không | |

Và điều mà một giải pháp do cả đội tìm ra có mà giải pháp áp từ trên xuống không bao giờ có: những người sẽ sửa nó khi nó không chạy đúng như dự tính.

Đáp án

D — XIN ĐƯỢC HUẤN LUYỆN VIÊN AGILE KÈM CẶP, VÌ VAI TRÒ CỦA ANH ẤY GẦN VỚI VAI TRÒ CHỦ SẢN PHẨM.

Vì sao đúng

⚠ Vì sao đây là hành động đúng: | Lý do | Nội dung | |---|---| | ⚠ Kevin thiếu KIẾN THỨC, không thiếu năng lực | ⚠ chữa bằng học, không bằng đổi người | | ⚠ Vai trò phân tích nghiệp vụ gần với CHỦ SẢN PHẨM | ⚠ cùng làm việc với yêu cầu, giá trị, thứ tự ưu tiên | | ⚠ Huấn luyện viên agile tồn tại chính để làm việc này | ⚠ dẫn dắt tổ chức đang chuyển đổi | | ⚠ Tổ chức ĐANG chuyển sang scrum | ⚠ nên chắc chắn có sẵn hỗ trợ chuyển đổi | | ⚠ Kết luận | ⚠ giải quyết khoảng trống của chính mình, đúng người, đúng cách, và giữ được đóng góp của Kevin cho dự án |

⚠ Cầu nối vai trò: ⚠ kỹ năng cốt lõi của chuyên viên phân tích — khai thác yêu cầu, viết tiêu chí chấp nhận, làm rõ nhu cầu bên liên quan — chính là những gì chủ sản phẩm cần ⚠ — ⚠ thứ Kevin thiếu chỉ là cách những kỹ năng đó được dùng trong nhịp scrum.

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

• C (xin chuyển sang dự án khác vì chỉ quen quản lý dự án truyền thống) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như sự tự nhận thức trung thực: biết mình chưa đủ năng lực nên nhường chỗ cho người phù hợp hơn: ⚠ nhưng ⚠ nó bỏ chạy khỏi một khoảng trống hoàn toàn có thể lấp được bằng vài tuần học hỏi ⚠; ⚠ và nó bỏ qua điều quan trọng nhất: Kevin nắm NGHIỆP VỤ nông nghiệp và nắm bên liên quan, phần khó thay thế nhất — còn scrum chỉ là khung làm việc, học được; ⚠ về mặt nghề nghiệp, tổ chức đang chuyển đổi là cơ hội tốt nhất để học agile, và bỏ lỡ nó là một quyết định tệ.

• A (nhờ một kiểm thử viên đóng vai người dùng cuối và xếp thứ tự tồn đọng) — ⚠ giao vai chủ sản phẩm cho người không có thẩm quyền; ⚠ và bản thân Kevin mới là người gần vai trò đó nhất.

• B (nhờ người kiểm thử giỏi nhất duyệt sản phẩm khả dụng tối thiểu ở mỗi buổi rà soát) — ⚠ chấp nhận sản phẩm là quyền của chủ sản phẩm, không phải của người rành kỹ thuật nhất; ⚠ nhầm giữa "hiểu phần mềm" và "đại diện cho giá trị nghiệp vụ".

Ghi nhớ

⚠ Đối chiếu: ⚠ #26969 cùng lô (thứ tự ưu tiên tồn đọng là việc của chủ sản phẩm), ⚠ #26961 cùng lô (rà soát câu chuyện mới cùng chủ sản phẩm), ⚠ #26919 lô 203 (ước lượng là việc của đội phát triển), ⚠ #26948 cùng lô (kèm cặp để lấp khoảng trống kỹ năng).

⚠ BA VAI TRÒ trong Scrum và ai làm gì: | Vai trò | Trách nhiệm | |---|---| | ⚠ CHỦ SẢN PHẨM | ⚠ tối đa hoá giá trị, sở hữu và xếp thứ tự tồn đọng, chấp nhận sản phẩm — vai gần Kevin nhất | | ⚠ SCRUM MASTER | ⚠ phục vụ đội, dọn vật cản, bảo vệ quy trình — không xếp ưu tiên | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ quyết định CÁCH làm và bao nhiêu việc lấy vào chặng | | ⚠ Ranh giới hay bị vi phạm nhất | ⚠ người ngoài xếp thứ tự tồn đọng, hoặc chủ sản phẩm bảo đội phải làm bằng cách nào — cả hai đều phá vỡ nguyên tắc, và cả hai đều rất phổ biến ở tổ chức mới chuyển đổi |

⚠ Chuyên viên phân tích nghiệp vụ chuyển sang agile thì đổi gì: | Trước đây | Trong scrum | |---|---| | ⚠ Viết tài liệu đặc tả yêu cầu đầy đủ trước | ⚠ viết câu chuyện người dùng, làm rõ dần theo chặng | | ⚠ Bàn giao tài liệu rồi rút lui | ⚠ có mặt liên tục để trả lời câu hỏi | | ⚠ Yêu cầu cố định sau khi ký duyệt | ⚠ tồn đọng được xếp lại mỗi chặng | | ⚠ Đo bằng độ đầy đủ của tài liệu | ⚠ đo bằng giá trị đã bàn giao | | ⚠ Điều KHÔNG đổi | ⚠ việc hiểu nghiệp vụ và hiểu bên liên quan — đó vẫn là giá trị lớn nhất Kevin mang lại, và không khung làm việc nào thay thế được nó |

⚠ Vì sao xin kèm cặp là hành động của người chuyên nghiệp: | Ý nghĩa | Nội dung | |---|---| | ⚠ Thừa nhận khoảng trống là bước đầu để lấp nó | | | ⚠ Chủ động, không chờ người khác nhận ra | | | ⚠ Dùng đúng nguồn lực tổ chức đã có sẵn | | | ⚠ Nhận xét | ⚠ trong bốn phương án, chỉ có một phương án Kevin tự làm cho MÌNH; ba phương án còn lại đều là đẩy trách nhiệm sang người khác — và đó thường là cách nhanh nhất để nhận ra đáp án đúng trong dạng câu hỏi "anh ta nên yêu cầu gì" |

Từ khoá nhận diện:

"chuyên viên phân tích chưa quen scrum" → ⚠ XIN KÈM CẶP, vai gần CHỦ SẢN PHẨM "xin chuyển dự án khác" → ⚠ bỏ chạy khỏi khoảng trống học được "nhờ kiểm thử viên xếp ưu tiên" → ⚠ sai vai trò, không có thẩm quyền "người rành kỹ thuật nhất duyệt MVP" → ⚠ chấp nhận sản phẩm là quyền chủ sản phẩm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong đội bạn ai đang thực sự xếp thứ tự tồn đọng | | | Ai có quyền chấp nhận sản phẩm bàn giao | | | Bạn có khoảng trống kỹ năng nào đang né tránh không | |

Và điều mà một chuyên viên phân tích nghiệp vụ mang sang scrum quý hơn mọi kiến thức về khung làm việc: sự hiểu biết về việc khách hàng thật sự cần gì — thứ mà không buổi đào tạo scrum nào dạy được.

Đáp án

B — ĐỘI DỰ ÁN.

Vì sao đúng

⚠ Vì sao đội dự án chịu trách nhiệm: | Lý do | Nội dung | |---|---| | ⚠ Đội là người TẠO RA sản phẩm bàn giao | ⚠ chất lượng được xây vào lúc làm, không kiểm tra ra sau | | ⚠ Chất lượng = mức đáp ứng YÊU CẦU đã thoả thuận | ⚠ và đội là người thực hiện yêu cầu đó | | ⚠ Người quản lý dự án chịu trách nhiệm CUỐI CÙNG | ⚠ nhưng câu hỏi đang hỏi về quản lý chất lượng nói chung | | ⚠ Greg và khách hàng đang định nghĩa phạm vi | ⚠ phạm vi định nghĩa chất lượng — đội thực hiện nó | | ⚠ Kết luận | ⚠ chất lượng không phải việc của một bộ phận kiểm tra tách rời, nó là việc của những người làm ra sản phẩm |

⚠ Nguyên tắc nền: ⚠ chất lượng được LẬP KẾ HOẠCH và XÂY VÀO sản phẩm, không phải được kiểm tra để phát hiện ra ⚠ — ⚠ liên hệ #26945 cùng lô về chi phí phòng ngừa.

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

• A (mọi người) — ⚠ phương án gây nhiễu mạnh nhất, và cần nói thẳng rằng nó CŨNG ĐÚNG theo một cách đọc phổ biến vì ⚠ tài liệu quản lý chất lượng nào cũng có câu "chất lượng là trách nhiệm của tất cả mọi người": ⚠ nhưng ⚠ trong bốn phương án đã cho, "mọi người" là câu trả lời KHÔNG CỤ THỂ — nó bao gồm cả nhà tài trợ, cả bên liên quan bên ngoài, những người không hề tạo ra sản phẩm bàn giao ⚠; ⚠ câu hỏi của khách hàng là "ai chịu trách nhiệm", và một câu trả lời gồm tất cả mọi người thì không xác định được ai cả; ⚠ xem thêm mục "Ghi nhớ về chất lượng câu hỏi" bên dưới.

• C (người bảo trợ dự án — project champion) — ⚠ là người ủng hộ và vận động cho dự án trong tổ chức; ⚠ vai trò chính trị, không phải vai trò chất lượng.

• D (bên liên quan) — ⚠ bên liên quan ĐỊNH NGHĨA kỳ vọng và NGHIỆM THU kết quả; ⚠ nhưng họ không làm ra sản phẩm nên không chịu trách nhiệm tạo ra chất lượng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này có hai phương án bảo vệ được ⚠ — ⚠ B (đội dự án, những người trực tiếp tạo ra sản phẩm) và A (mọi người, theo châm ngôn quản lý chất lượng toàn diện); ⚠ cách phân biệt trong phòng thi: khi đề hỏi ai chịu trách nhiệm cho CHẤT LƯỢNG CỦA SẢN PHẨM BÀN GIAO thì chọn ĐỘI DỰ ÁN; khi đề hỏi về văn hoá chất lượng hoặc quản lý chất lượng toàn diện thì chọn MỌI NGƯỜI; ⚠ và nhớ thêm một cặp hay bị lẫn: người quản lý dự án chịu trách nhiệm CUỐI CÙNG về dự án, nhưng đội mới là người tạo ra chất lượng — hai điều này không mâu thuẫn.

⚠ Đối chiếu: ⚠ #26945 cùng lô (chi phí chất lượng), ⚠ #26894 lô 203 (chất lượng được cải thiện), ⚠ #26925 lô 203 (hành động phòng ngừa), ⚠ #26960 cùng lô (tài liệu vừa đủ).

⚠ Ai làm gì trong quản lý chất lượng: | Vai | Trách nhiệm | |---|---| | ⚠ ĐỘI DỰ ÁN | ⚠ tạo ra chất lượng trong từng sản phẩm bàn giao — ĐÁP ÁN | | ⚠ Người quản lý dự án | ⚠ lập kế hoạch chất lượng, chịu trách nhiệm cuối cùng | | ⚠ Bộ phận bảo đảm chất lượng | ⚠ kiểm tra QUY TRÌNH có được tuân thủ không | | ⚠ Khách hàng / bên liên quan | ⚠ định nghĩa yêu cầu và nghiệm thu | | ⚠ Lãnh đạo cấp cao | ⚠ tạo môi trường và cấp nguồn lực cho chất lượng | | ⚠ Câu của Deming đáng nhớ | ⚠ phần lớn vấn đề chất lượng bắt nguồn từ HỆ THỐNG chứ không từ người lao động — nên khi chất lượng kém, hãy xem lại quy trình, đào tạo và công cụ trước khi xem lại con người |

⚠ Vì sao định nghĩa phạm vi lại định nghĩa chất lượng: | Quan hệ | Nội dung | |---|---| | ⚠ Chất lượng = mức đáp ứng YÊU CẦU | ⚠ không phải mức "cao cấp" | | ⚠ Yêu cầu không rõ ⇒ chất lượng không đo được | | | ⚠ Phạm vi mơ hồ là nguồn tranh chấp nghiệm thu | | | ⚠ Phân biệt quan trọng | ⚠ CHẤT LƯỢNG là làm đúng yêu cầu đã thoả thuận, còn CẤP ĐỘ (grade) là mức tính năng và độ tinh xảo — một sản phẩm cấp thấp nhưng đúng yêu cầu vẫn là chất lượng tốt; cấp thấp thì chấp nhận được, chất lượng thấp thì không |

Từ khoá nhận diện:

"ai chịu trách nhiệm chất lượng sản phẩm bàn giao" → ⚠ ĐỘI DỰ ÁN "mọi người" → ⚠ đúng về văn hoá nhưng không xác định được ai "người bảo trợ dự án" → ⚠ vai trò vận động, không phải chất lượng "bên liên quan" → ⚠ định nghĩa yêu cầu và nghiệm thu, không tạo ra chất lượng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có coi chất lượng là việc của mình hay của khâu kiểm thử | | | Yêu cầu của bạn có đủ rõ để đo chất lượng không | | | Bạn có phân biệt được chất lượng và cấp độ không | |

Và điều mà việc đặt trách nhiệm chất lượng vào tay đội thay đổi trong cách làm việc: chất lượng thôi là một cửa kiểm tra ở cuối dây chuyền và trở thành một quyết định được lặp lại ở từng bước.