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

⚠ Ghi nhớ về chất lượng câu hỏi — CÂU TRÙNG HOÀN TOÀN: ⚠ câu này TRÙNG NGUYÊN VĂN với #25919 lô 183 ⚠ — ⚠ cùng tình huống Ike và David, cùng bốn phương án, cùng khoá đáp án về nội dung; ⚠ khác biệt DUY NHẤT là THỨ TỰ CHỮ CÁI bị ĐẢO NGƯỢC HOÀN TOÀN: A↔D và B↔C, nên đáp án từ phương án B của bản cũ thành phương án C ở bản này; ⚠ giải thích dưới đây được dùng lại và đã chỉnh lại toàn bộ chữ cái cho khớp với thứ tự mới; ⚠ bài học cho phòng thi: bộ đề xáo chữ cái giữa các lần ra đề, nên đừng bao giờ học thuộc chữ cái — hãy nhớ NỘI DUNG của phương án đúng.

Đáp án

C — PHÂN TÍCH thông tin dự án để đưa ra quyết định tốt nhất CÙNG VỚI ĐỘI.

Vì sao đúng

⚠ Vì sao đây là lời khuyên đúng cho David: | Lý do | Nội dung | |---|---| | ⚠ Agile đề cao ĐỘI TỰ TỔ CHỨC | ⚠ quyết định kỹ thuật thuộc về đội phát triển | | ⚠ Quyết định dựa trên THÔNG TIN, không dựa trên cảm giác | ⚠ cách chữa nỗi sợ là dữ liệu | | ⚠ Quyết định CÙNG ĐỘI thì đội cùng chịu trách nhiệm | ⚠ giảm áp lực đè lên một mình David | | ⚠ Scrum Master ĐIỀU PHỐI, không QUYẾT THAY | | | ⚠ Nguyên tắc agile | ⚠ kiến trúc tốt nhất nổi lên từ ĐỘI TỰ TỔ CHỨC — nguyên tắc số 11 của Tuyên ngôn Agile |

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

• B (hỏi quản lý của đội để hiểu vấn đề) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe như tìm lời khuyên có kinh nghiệm, ⚠ nhưng nó ⚠ đưa quyết định kỹ thuật ra NGOÀI đội ⚠ và ⚠ phá vỡ tính tự tổ chức; ⚠ quản lý chức năng cũng không nắm bối cảnh bằng đội.

• D (chỉ định một agile champion) — ⚠ không giải quyết quyết định kiến trúc trước mắt; ⚠ champion là vai trò thúc đẩy chuyển đổi agile trong tổ chức, khác hẳn.

• A (thay product owner bằng nhà tài trợ) — ⚠ hoàn toàn lạc đề; ⚠ vấn đề không nằm ở PO, ⚠ và thay người là phản ứng cực đoan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25913 ở lô này (Scrum Master huấn luyện bên liên quan), câu #25915 (Scrum Master xử lý khi PO phàn nàn), và câu #25901 ở lô này (phong cách lãnh đạo HỖ TRỢ). ⚠ Cùng nhóm: Scrum Master phục vụ chứ không chỉ huy.

⚠ Đội sợ quyết định sai thì làm gì: | Cách | Nội dung | |---|---| | ⚠ Thu thập THÔNG TIN để giảm bất định | ⚠ bước đầu tiên — CÂU NÀY | | ⚠ Chạy SPIKE — thử nghiệm nhỏ có hộp thời gian | ⚠ cách agile chuẩn để giảm rủi ro kỹ thuật | | ⚠ Ghi ADR — biên bản quyết định kiến trúc | ⚠ ghi lại lý do để sau này hiểu vì sao chọn | | ⚠ Chọn quyết định ĐẢO NGƯỢC ĐƯỢC nếu có | ⚠ quyết định một chiều mới cần cân nhắc kỹ | | ⚠ Trì hoãn tới THỜI ĐIỂM MUỘN NHẤT CÓ TRÁCH NHIỆM | ⚠ nguyên tắc của lean | | ⚠ Điều KHÔNG nên làm | ⚠ để nỗi sợ làm tê liệt — không quyết cũng là một quyết định, và thường là quyết định tệ nhất |

Từ khoá nhận diện:

"đội sợ quyết định sai" → ⚠ thu thập thông tin và quyết cùng đội "hỏi quản lý bên ngoài" → ⚠ phá tính tự tổ chức "thay người" → ⚠ gần như luôn là đáp án sai trong đề PMP "Scrum Master ra quyết định kỹ thuật thay đội" → ⚠ sai vai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyết định kỹ thuật trong đội bạn do ai chốt | | | Có quyết định nào đang bị treo vì sợ sai không | | | Đội có ghi lại lý do của các quyết định lớn không | ⚠ sáu tháng sau sẽ rất cần |

Và điều một Scrum Master phải học sớm: cảm giác "mình phải quyết cái này" thường là dấu hiệu bạn đang làm sai vai, chứ không phải dấu hiệu bạn đang gánh trách nhiệm tốt.

Đáp án

B — WANDA ĐÃ DÙNG SAI CHIẾN LƯỢC ĐỂ GIẢI QUYẾT XUNG ĐỘT NÀY.

Vì sao đúng

⚠ Chuỗi nhân quả mà đề mô tả: | Sự việc | Ý nghĩa | |---|---| | ⚠ Vài thành viên bất đồng về cách xử lý một vấn đề | ⚠ xung đột về NỘI DUNG, vốn là loại lành mạnh | | ⚠ Wanda "giải quyết" xung đột | ⚠ chú ý: cô ấy tự giải quyết chứ không để đội giải quyết | | ⚠ NGAY SAU ĐÓ vận tốc tụt từ 53 xuống 39 | ⚠ giảm hơn một phần tư | | ⚠ Không có dữ kiện nào khác thay đổi | ⚠ nên nguyên nhân hợp lý nhất là cách xử lý | | ⚠ Kết luận | ⚠ xung đột được dập tắt nhưng nguyên nhân và cảm xúc thì không, nên năng suất tụt |

⚠ Dấu hiệu của chiến lược sai: ⚠ nếu Wanda dùng ÉP BUỘC hoặc RÚT LUI, xung đột sẽ biến mất khỏi bề mặt nhưng để lại sự bất mãn ⚠ — ⚠ và người thua trong một cuộc ép buộc thường giảm mức đóng góp mà không nói ra; liên hệ #26941 lô 204.

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

• A (vài thành viên đã rời đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ mất người là lời giải thích trực tiếp và dễ hiểu nhất cho việc vận tốc giảm, và giảm 14 trên 53 điểm cũng gần đúng tỷ lệ nếu mất hai người trong bảy: ⚠ nhưng ⚠ đề KHÔNG hề nói ai rời đội — đó là dữ kiện tự thêm vào ⚠; ⚠ và đề đã nêu rõ mốc thời gian: vận tốc tụt SAU KHI Wanda giải quyết xung đột, nên mối liên hệ nhân quả đã được đề chỉ ra; ⚠ quy tắc làm bài: không bao giờ thêm dữ kiện không có trong đề, nhất là khi đề đã cho một trình tự thời gian rõ ràng.

• C (đội đã làm hết tồn đọng nên không đủ việc) — ⚠ dự án mới ở chặng thứ bảy; ⚠ và nếu hết việc thì đó là vấn đề của chủ sản phẩm chứ không liên quan tới xung đột.

• D (không có xung đột chung nên đội mất động lực) — ⚠ lập luận vô lý; ⚠ không có lý thuyết nào cho rằng đội cần xung đột để có động lực.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27047 cùng lô (chọn kỹ thuật xử lý xung đột theo hoàn cảnh), ⚠ #27055 cùng lô (trí tuệ cảm xúc trong xử lý xung đột), ⚠ #26950 lô 204 (cả đội cùng giải quyết vấn đề tạo đồng thuận), ⚠ #26841 lô 202 (vận tốc giảm và cách chẩn đoán).

⚠ Năm chiến lược và hậu quả về năng suất: | Chiến lược | Hậu quả điển hình | |---|---| | ⚠ HỢP TÁC / giải quyết vấn đề | ⚠ năng suất giữ hoặc tăng, cam kết cao | | ⚠ THOẢ HIỆP | ⚠ năng suất ổn, nhưng không ai hoàn toàn hài lòng | | ⚠ XOA DỊU | ⚠ êm tạm thời, vấn đề quay lại | | ⚠ ÉP BUỘC | ⚠ NĂNG SUẤT TỤT, người thua rút lui — nghi ngờ hàng đầu ở đây | | ⚠ RÚT LUI / né tránh | ⚠ vấn đề âm ỉ, đội mất niềm tin vào người dẫn dắt | | ⚠ Nhận xét | ⚠ chỉ có HỢP TÁC là chiến lược mà sau đó năng suất thường TỐT LÊN, vì nó vừa giải quyết vấn đề vừa để lại một đội hiểu nhau hơn — bốn cái còn lại tốt nhất là giữ nguyên hiện trạng |

⚠ Wanda nên làm gì bây giờ: | Bước | Nội dung | |---|---| | ⚠ 1. Thừa nhận rằng có gì đó chưa ổn | ⚠ số liệu đã nói rõ | | ⚠ 2. Gặp riêng những người liên quan, lắng nghe | ⚠ liên hệ #27025 lô 205 | | ⚠ 3. Hỏi xem quyết định đó có được chấp nhận thật không | | | ⚠ 4. Mở lại vấn đề nếu cần, lần này để ĐỘI giải quyết | ⚠ liên hệ #26950 lô 204 | | ⚠ 5. Đưa vào buổi cải tiến để rút kinh nghiệm chung | | | ⚠ Điều khó nhất | ⚠ thừa nhận rằng cách mình xử lý đã gây ra vấn đề — nhưng một scrum master làm được điều đó sẽ lấy lại được lòng tin nhanh hơn nhiều so với việc tiếp tục bảo vệ quyết định cũ |

⚠ Vận tốc giảm đột ngột: các nguyên nhân cần loại trừ: | Nguyên nhân | Cách kiểm tra | |---|---| | ⚠ Mất người hoặc người nghỉ phép | ⚠ xem lịch nguồn lực — #27053 cùng lô | | ⚠ Công việc chặng này khó hơn bất thường | ⚠ xem loại việc đã nhận | | ⚠ Nợ kỹ thuật tích tụ | ⚠ liên hệ #26966 lô 204 | | ⚠ Vấn đề về tinh thần và quan hệ trong đội | ⚠ nguyên nhân của câu này | | ⚠ Vật cản bên ngoài | ⚠ liên hệ #27027 lô 205 | | ⚠ Cách chẩn đoán đúng | ⚠ hỏi đội trong buổi cải tiến thay vì tự suy đoán — và nếu đội im lặng khi được hỏi về một chặng có vận tốc tụt mạnh, thì bản thân sự im lặng đó đã là câu trả lời |

Từ khoá nhận diện:

"xử lý xung đột xong thì vận tốc tụt" → ⚠ SAI CHIẾN LƯỢC xử lý xung đột "vài người rời đội" → ⚠ dữ kiện KHÔNG có trong đề "hết tồn đọng" → ⚠ mới chặng thứ bảy, và không liên quan xung đột "thiếu xung đột nên mất động lực" → ⚠ lập luận vô lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xung đột gần nhất trong đội bạn được giải quyết bằng chiến lược nào | | | Sau đó năng suất và tinh thần thay đổi ra sao | | | Người "thua" trong lần đó có còn đóng góp như trước không | |

Và dấu hiệu đáng tin nhất cho biết một xung đột đã được giải quyết hay chỉ bị dập tắt: điều xảy ra với năng suất trong hai tuần kế tiếp.

Đáp án

C — THỨ TỰ ƯU TIÊN GIỮA CÁC DỰ ÁN (project priorities).

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ⚠ — ⚠ dừng ở "…he explains that he thought", tức là "…he thought the new project was the priority"; ⚠ phần còn lại đã đủ rõ.

Vì sao đúng

⚠ Nguyên nhân gốc của vấn đề: | Sự việc | Ý nghĩa | |---|---| | ⚠ Xiao thoả thuận chia thời gian của James với PM kia | ⚠ hai người quản lý thống nhất với nhau | | ⚠ Nhưng KHÔNG BÁO cho James | ⚠ người trực tiếp thực hiện không biết gì | | ⚠ James tự suy đoán về thứ tự ưu tiên | ⚠ anh ấy nghĩ dự án mới quan trọng hơn | | ⚠ Kết quả: trễ hạn ở dự án của Xiao | ⚠ hệ quả tất yếu | | ⚠ Kết luận | ⚠ James không được cho biết ưu tiên nào cao hơn, nên anh ấy tự chọn — và chọn khác với ý Xiao |

⚠ Lỗi thuộc về Xiao chứ không phải James: ⚠ anh ấy phản ứng phòng thủ vì đang bị trách về một điều chưa từng được nói cho biết ⚠ — ⚠ đây là lỗi truyền thông của người quản lý, không phải lỗi thái độ của nhân viên.

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

• B (môi trường đội — team environment) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ việc một người bị chia cho hai dự án đúng là một đặc điểm môi trường, và làm việc đa dự án thật sự gây căng thẳng — nghe rất hợp lý ở mức khái quát: ⚠ nhưng ⚠ "môi trường đội" là mô tả BỐI CẢNH chứ không phải nguyên nhân ⚠ — ⚠ nếu Xiao đã nói rõ với James rằng dự án nào ưu tiên và anh ấy dành bao nhiêu thời gian cho mỗi bên, thì cùng môi trường đó vẫn hoạt động bình thường; ⚠ hãy chọn nguyên nhân CỤ THỂ và có thể sửa được, thay vì một mô tả hoàn cảnh chung.

• A (tính cách — personality) — ⚠ phản ứng phòng thủ của James là hệ quả, không phải nguyên nhân; ⚠ và đổ cho tính cách sẽ dẫn tới việc "chấn chỉnh" nhầm người.

• D (khác biệt văn hoá) — ⚠ không có yếu tố nào về văn hoá trong tình huống; ⚠ tự thêm dữ kiện.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26978 lô 204 (thương lượng nguồn lực dùng chung), ⚠ #26995 lô 205 (hai đội tranh cùng một nguồn lực), ⚠ #26941 lô 204 (không được tham gia quyết định thì mất cam kết), ⚠ #27053 cùng lô (lịch nguồn lực).

⚠ Xiao đã bỏ sót những gì: | Việc bị bỏ sót | Hậu quả | |---|---| | ⚠ Không nói với James về thoả thuận | ⚠ anh ấy tự đoán ưu tiên | | ⚠ Không nêu rõ tỷ lệ thời gian cho mỗi dự án | ⚠ không biết dành bao nhiêu cho ai | | ⚠ Không thoả thuận cách xử lý khi hai bên cùng gấp | ⚠ tình huống chắc chắn sẽ xảy ra | | ⚠ Không hỏi ý kiến James về khả năng của anh ấy | ⚠ có thể anh ấy đã nói là không kham nổi | | ⚠ Không thông báo cho quản lý chức năng của James | | | ⚠ Việc quan trọng nhất bị bỏ sót | ⚠ thoả thuận về THỨ TỰ ƯU TIÊN khi hai dự án cùng cần — vì đó chính xác là tình huống đã xảy ra, và nó có thể lường trước được ngay từ lúc chia người |

⚠ Quản lý người làm nhiều dự án cùng lúc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Người đó phải BIẾT và ĐỒNG Ý với thoả thuận | ⚠ không phải là món hàng được trao đổi | | ⚠ Ghi rõ tỷ lệ thời gian và cách đo | ⚠ "50/50" nghe rõ nhưng thực tế rất mơ hồ | | ⚠ Xác định ai là người quyết khi có xung đột | | | ⚠ Tính tới chi phí chuyển đổi ngữ cảnh | ⚠ hai dự án nửa thời gian cho ra ít hơn một dự án toàn thời gian | | ⚠ Rà soát định kỳ xem còn khả thi không | | | ⚠ Con số đáng nhớ | ⚠ làm việc song song hai dự án thường mất khoảng 20% năng suất cho việc chuyển đổi ngữ cảnh — nên "một nửa thời gian" trên giấy thực tế chỉ còn khoảng 40%; liên hệ #26924 lô 203 |

⚠ Xiao nên xử lý thế nào bây giờ: | Bước | Nội dung | |---|---| | ⚠ 1. Xin lỗi vì đã không thông báo | ⚠ lỗi rõ ràng thuộc về cô ấy | | ⚠ 2. Nói rõ thoả thuận và tỷ lệ thời gian | | | ⚠ 3. Cùng James xem lại các hạn còn lại | ⚠ cái nào còn khả thi, cái nào không | | ⚠ 4. Thống nhất với PM kia về thứ tự ưu tiên | | | ⚠ 5. Cho James biết ai là người quyết khi hai bên xung đột | | | ⚠ Điều cần tránh nhất | ⚠ tiếp tục coi đây là vấn đề thái độ của James — anh ấy phòng thủ vì bị trách oan, và nếu Xiao không nhận phần lỗi của mình thì cô ấy vừa mất một nhân sự giỏi vừa không sửa được nguyên nhân |

Từ khoá nhận diện:

"chia người sang dự án khác mà không báo" → ⚠ xung đột về THỨ TỰ ƯU TIÊN dự án "môi trường đội" → ⚠ mô tả bối cảnh, không phải nguyên nhân sửa được "tính cách" → ⚠ phản ứng phòng thủ là hệ quả, không phải nguyên nhân "khác biệt văn hoá" → ⚠ không có dữ kiện nào trong đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người làm nhiều dự án của bạn có biết ưu tiên nào cao hơn không | | | Có ai đang bị chia thời gian mà chưa được hỏi ý không | | | Khi hai dự án cùng gấp, ai là người quyết | |

Và điều mà hai người quản lý dự án thoả thuận với nhau về thời gian của một người thứ ba thường quên mất: người thứ ba đó là người duy nhất phải thực hiện thoả thuận, và cũng là người duy nhất chưa được cho biết nó tồn tại.

Đáp án

D — HỢP ĐỒNG THỜI GIAN VÀ VẬT TƯ (time and materials).

Vì sao đúng

⚠ Nhận diện từ cấu trúc thanh toán: | Yếu tố | Nội dung | |---|---| | ⚠ Tính 210 đô mỗi GIỜ | ⚠ đơn giá theo THỜI GIAN | | ⚠ Cộng thêm chi phí VẬT TƯ | ⚠ vật tư tính theo thực tế | | ⚠ Không có tổng giá cố định | ⚠ tổng phụ thuộc vào số giờ thực tế | | ⚠ Không có phí cố định riêng biệt | ⚠ phân biệt với các hợp đồng cost-plus | | ⚠ Kết luận | ⚠ thời gian tính theo đơn giá giờ + vật tư tính theo thực tế = đúng định nghĩa T&M |

⚠ Đặc điểm của T&M: ⚠ nó là một dạng lai giữa giá cố định và hoàn trả chi phí ⚠ — ⚠ đơn giá thì cố định, nhưng tổng khối lượng thì không, nên tổng chi phí là biến số.

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

• A (đơn giá — unit price) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ T&M CÓ dùng đơn giá (210 đô mỗi giờ), nên về mặt câu chữ nó rất gần: ⚠ nhưng ⚠ hợp đồng đơn giá thuần tính theo ĐƠN VỊ SẢN PHẨM hoặc đơn vị công việc: bao nhiêu đô mỗi mét vuông, mỗi tấn, mỗi thiết bị lắp đặt ⚠; ⚠ T&M tính theo THỜI GIAN LÀM VIỆC cộng vật tư, tức là trả cho nỗ lực bỏ ra chứ không trả cho kết quả tạo ra; ⚠ khác biệt này rất quan trọng về mặt rủi ro: với đơn giá, nhà thầu làm chậm thì họ chịu; với T&M, nhà thầu làm chậm thì BÊN MUA trả thêm.

• B (trọn gói — lump sum) — ⚠ là một tên gọi khác của giá cố định; ⚠ tổng giá được chốt trước, ngược hẳn với tình huống này — liên hệ #27077 cùng lô.

• C (chi phí cộng phí cố định — CPFF) — ⚠ hoàn trả chi phí thực tế CỘNG một khoản phí cố định riêng; ⚠ ở đây không có khoản phí cố định nào, chỉ có đơn giá giờ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27077 cùng lô (hợp đồng nào buộc bên bán gánh rủi ro vượt chi), ⚠ #27046 cùng lô (loại hợp đồng ít nguy hiểm nhất), ⚠ #26930 lô 203 (hợp đồng CPIF), ⚠ #27082 cùng lô (hợp đồng agile).

⚠ Ba họ hợp đồng và vị trí của T&M: | Họ | Đặc điểm | |---|---| | ⚠ GIÁ CỐ ĐỊNH | ⚠ tổng giá chốt trước, bên bán gánh rủi ro | | ⚠ THỜI GIAN VÀ VẬT TƯ | ⚠ đơn giá chốt, khối lượng mở — ĐÁP ÁN, nằm ở GIỮA | | ⚠ HOÀN TRẢ CHI PHÍ | ⚠ trả chi phí thực + phí, bên mua gánh rủi ro | | ⚠ Vì sao T&M nằm ở giữa | ⚠ bên mua biết chắc mình trả bao nhiêu MỖI GIỜ nhưng không biết sẽ mất bao nhiêu giờ — nên rủi ro được chia đôi theo một cách rất riêng |

⚠ Khi nào dùng T&M là hợp lý: | Trường hợp | Vì sao | |---|---| | ⚠ Phạm vi chưa rõ, khó định giá trọn gói | ⚠ lý do phổ biến nhất | | ⚠ Cần bắt đầu ngay, chưa kịp làm rõ phạm vi | | | ⚠ Bổ sung nhân lực chuyên môn ngắn hạn | ⚠ thuê chuyên gia theo giờ | | ⚠ Công việc nhỏ, chi phí đàm phán trọn gói không đáng | | | ⚠ Điều BẮT BUỘC phải có | ⚠ một TRẦN CHI PHÍ hoặc trần số giờ — không có trần thì hợp đồng T&M là một tấm séc để trống, và đó là sai lầm phổ biến nhất khi dùng loại này |

⚠ Kiểm soát hợp đồng T&M thế nào: | Biện pháp | Nội dung | |---|---| | ⚠ Đặt trần tổng chi phí hoặc tổng giờ | ⚠ quan trọng nhất | | ⚠ Yêu cầu báo cáo giờ chi tiết theo công việc | | | ⚠ Duyệt trước các khoản vật tư lớn | | | ⚠ Rà soát tiến độ so với giờ đã tiêu định kỳ | | | ⚠ Định nghĩa rõ kết quả mong đợi dù trả theo giờ | | | ⚠ Rủi ro cốt lõi | ⚠ nhà thầu không có động lực làm nhanh — mỗi giờ thêm là thêm doanh thu cho họ; nên với T&M, việc giám sát của bên mua không phải là sự thiếu tin tưởng mà là một phần bắt buộc của mô hình |

Từ khoá nhận diện:

"tính theo GIỜ cộng chi phí vật tư" → ⚠ THỜI GIAN VÀ VẬT TƯ (T&M) "đơn giá" → ⚠ tính theo đơn vị SẢN PHẨM, không theo giờ làm việc "trọn gói" → ⚠ tổng giá chốt trước "chi phí cộng phí cố định" → ⚠ có một khoản phí cố định riêng, ở đây không có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng T&M của bạn có trần không | | | Bạn có nhận được báo cáo giờ chi tiết không | | | Bạn có định nghĩa kết quả mong đợi dù trả theo giờ không | |

Và điều mà mọi hợp đồng thời gian và vật tư đòi hỏi bên mua chấp nhận: rằng bạn đang mua NỖ LỰC chứ không mua KẾT QUẢ — nên việc bảo đảm nỗ lực đó tạo ra kết quả trở thành công việc của chính bạn.

Đáp án

C — TRỌN GÓI (lump-sum).

Vì sao đúng

⚠ Vì sao bên bán gánh rủi ro trong hợp đồng trọn gói: | Cơ chế | Nội dung | |---|---| | ⚠ Tổng giá được CHỐT trước khi làm | ⚠ bên mua trả đúng ngần ấy | | ⚠ Chi phí thực tế vượt dự tính thì bên bán chịu | ⚠ lợi nhuận của họ giảm hoặc thành lỗ | | ⚠ Chi phí thấp hơn dự tính thì bên bán hưởng | ⚠ rủi ro đi kèm cơ hội | | ⚠ Bên mua biết chắc số tiền phải trả | | | ⚠ Kết luận | ⚠ trọn gói là tên gọi khác của giá cố định — bên bán gánh toàn bộ rủi ro chi phí |

⚠ Đây là câu ĐẢO CHIỀU của #27046 cùng lô: ⚠ câu kia hỏi loại nào ít nguy hiểm nhất cho DỰ ÁN (bên mua), câu này hỏi loại nào buộc BÊN BÁN gánh rủi ro ⚠ — ⚠ và cả hai đều có cùng một đáp án về bản chất: giá cố định; hãy đọc kỹ đề hỏi từ góc nhìn của bên nào.

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

• A (thời gian và vật tư — T&M) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có đơn giá cố định theo giờ, nên nghe như bên bán cũng bị ràng buộc bởi một mức giá: ⚠ nhưng ⚠ cái cố định là ĐƠN GIÁ chứ không phải TỔNG GIÁ — nếu công việc mất nhiều giờ hơn dự tính thì bên mua trả nhiều hơn ⚠; ⚠ nói cách khác, bên bán không chịu rủi ro về khối lượng, và trong nhiều trường hợp họ còn hưởng lợi từ việc công việc kéo dài; ⚠ liên hệ #27076 cùng lô: T&M nằm ở giữa thang rủi ro chứ không ở đầu nào cả.

• B (chi phí cộng phí cố định — CPFF) — ⚠ bên mua hoàn trả mọi chi phí thực tế; ⚠ bên bán gần như không chịu rủi ro chi phí nào.

• D (chi phí cộng phí thưởng — CPIF) — ⚠ bên mua vẫn hoàn trả chi phí; ⚠ khoản thưởng chia sẻ một PHẦN rủi ro theo tỷ lệ đã thoả thuận, nhưng không chuyển toàn bộ sang bên bán — liên hệ #26930 lô 203.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27046 cùng lô (loại hợp đồng ít nguy hiểm nhất cho bên mua — CÂU ĐẢO CHIỀU), ⚠ #27076 cùng lô (T&M), ⚠ #26930 lô 203 (CPIF và cách kiểm soát bằng khoản thưởng), ⚠ #27029 lô 205 (hợp đồng agile).

⚠ Thang rủi ro nhìn từ hai phía: | Loại hợp đồng | Rủi ro BÊN MUA | Rủi ro BÊN BÁN | |---|---|---| | ⚠ TRỌN GÓI / giá cố định | ⚠ thấp nhất | ⚠ CAO NHẤT — ĐÁP ÁN | | ⚠ Giá cố định có thưởng | ⚠ thấp | ⚠ cao | | ⚠ Thời gian và vật tư | ⚠ trung bình | ⚠ trung bình | | ⚠ Chi phí cộng phí thưởng | ⚠ cao | ⚠ thấp | | ⚠ Chi phí cộng phí cố định | ⚠ cao hơn | ⚠ thấp hơn | | ⚠ Chi phí cộng phần trăm chi phí | ⚠ cao nhất | ⚠ thấp nhất | | ⚠ Quy tắc bất biến | ⚠ hai cột này luôn ĐỐI XỨNG — rủi ro không biến mất, nó chỉ chuyển từ bên này sang bên kia; và bên nhận rủi ro luôn tính phí cho việc đó |

⚠ Vì sao bên bán vẫn chấp nhận hợp đồng trọn gói: | Lý do | Nội dung | |---|---| | ⚠ Họ tính phí rủi ro vào giá | ⚠ nên giá cao hơn hợp đồng hoàn trả chi phí | | ⚠ Nếu làm hiệu quả thì họ hưởng phần tiết kiệm | ⚠ cơ hội đi kèm rủi ro | | ⚠ Công việc quen thuộc thì rủi ro thấp | ⚠ họ ước lượng khá chắc | | ⚠ Dễ quản lý, ít phải báo cáo chi phí | | | ⚠ Điều bên mua cần hiểu | ⚠ bạn không "chuyển rủi ro" miễn phí — bạn MUA việc chuyển rủi ro đó, và giá của nó nằm ẩn trong con số trọn gói; với một phạm vi rất rõ ràng thì phí này nhỏ, còn với phạm vi mơ hồ thì nó có thể rất lớn |

⚠ Lump-sum và fixed-price có khác nhau không: | Khái niệm | Nội dung | |---|---| | ⚠ Fixed-price (giá cố định) | ⚠ tên gọi chung của cả họ hợp đồng | | ⚠ Lump-sum (trọn gói) | ⚠ cách nói phổ biến trong ngành xây dựng cho cùng ý | | ⚠ FFP (firm fixed price) | ⚠ dạng chặt nhất: một giá duy nhất, không điều chỉnh | | ⚠ Trong đề thi | ⚠ ba tên gọi này thường được dùng thay thế cho nhau; nếu chúng cùng xuất hiện trong bốn phương án thì hãy tìm sự khác biệt ở phần mô tả chứ không ở tên gọi |

Từ khoá nhận diện:

"bên BÁN gánh rủi ro vượt chi" → ⚠ TRỌN GÓI / giá cố định "thời gian và vật tư" → ⚠ cố định ĐƠN GIÁ, không cố định tổng "chi phí cộng phí cố định" → ⚠ bên mua hoàn trả chi phí thực "chi phí cộng phí thưởng" → ⚠ chia sẻ một phần rủi ro, không chuyển hết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn đẩy rủi ro về phía nào | | | Bạn có đang trả phí rủi ro cho một phạm vi vốn đã rất rõ không | | | Nếu phạm vi còn mơ hồ, hợp đồng trọn gói có phải lựa chọn đúng không | |

Và quy luật không bao giờ sai của mọi loại hợp đồng: rủi ro không biến mất khi bạn chuyển nó sang bên kia — nó chỉ xuất hiện lại trong giá, dưới một cái tên khác.

Đáp án

A — THEO DÕI (monitor).

Vì sao đúng

⚠ Chiếu vào ma trận quyền lực – quan tâm: | Yếu tố | Nội dung | |---|---| | ⚠ 76% người mua hàng KHÔNG có ý kiến mạnh | ⚠ mức QUAN TÂM thấp | | ⚠ Họ là người tiêu dùng lẻ, mỗi người mua ít | ⚠ mức QUYỀN LỰC / ảnh hưởng thấp | | ⚠ Ô quyền lực thấp – quan tâm thấp | ⚠ chiến lược: THEO DÕI | | ⚠ Không đầu tư nhiều công sức vào nhóm này | ⚠ nhưng vẫn để mắt | | ⚠ Kết luận | ⚠ theo dõi với nỗ lực tối thiểu, sẵn sàng điều chỉnh nếu thái độ họ đổi |

⚠ Vì sao "không có ý kiến" cũng là một kết quả có ích: ⚠ nó cho biết việc đổi bao bì sang loại phân huỷ sinh học nhiều khả năng KHÔNG gặp phản đối từ người tiêu dùng ⚠ — ⚠ đó là thông tin quan trọng cho quyết định của dự án, dù nghe như một cuộc khảo sát thất bại.

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

• B (giữ cho họ được thông tin — keep informed) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cung cấp thông tin nghe luôn là việc tốt, và nhiều người nghĩ rằng người tiêu dùng không quan tâm thì cần được "giáo dục" để họ quan tâm hơn: ⚠ nhưng ⚠ "giữ thông tin đủ" là chiến lược cho ô QUYỀN LỰC THẤP – QUAN TÂM CAO ⚠ — ⚠ những người quan tâm nhiều nhưng ít ảnh hưởng; liên hệ #26974 lô 204 về trường hợp Craig; ⚠ ở đây người ta đã nói rõ là họ KHÔNG quan tâm, nên đổ thông tin vào một nhóm không muốn nhận là lãng phí và có thể gây phản tác dụng.

• C (giữ họ hài lòng — keep satisfied) — ⚠ chiến lược cho ô QUYỀN LỰC CAO – QUAN TÂM THẤP; ⚠ những người có ảnh hưởng lớn nhưng ít để tâm, ví dụ một giám đốc điều hành.

• D (quản lý chặt — manage closely) — ⚠ chiến lược cho ô QUYỀN LỰC CAO – QUAN TÂM CAO; ⚠ tốn nhiều công sức nhất và hoàn toàn không tương xứng ở đây.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26973 lô 204 (lập bản đồ bên liên quan bằng ma trận), ⚠ #26974 lô 204 (ô quyền lực thấp – quan tâm cao), ⚠ #27030 lô 205 (lưới quyền lực – ảnh hưởng), ⚠ #26957 lô 204 (nhận diện bên liên quan suốt vòng đời).

⚠ BỐN Ô và bốn chiến lược, học thuộc bảng này: | Ô | Chiến lược | Ví dụ | |---|---|---| | ⚠ 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 | ⚠ lãnh đạo cấp cao bận rộn | | ⚠ Quyền lực THẤP – Quan tâm CAO | ⚠ GIỮ THÔNG TIN ĐỦ | ⚠ người dùng cuối nhiệt tình | | ⚠ Quyền lực THẤP – Quan tâm THẤP | ⚠ THEO DÕI — ĐÁP ÁN | ⚠ công chúng nói chung | | ⚠ Mẹo nhớ | ⚠ 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 gửi đi — nhớ theo hai trục thay vì học thuộc bốn cụm từ sẽ ít nhầm hơn nhiều |

⚠ Theo dõi không có nghĩa là bỏ mặc: | Việc vẫn nên làm | Nội dung | |---|---| | ⚠ Khảo sát lại định kỳ | ⚠ thái độ có thể đổi | | ⚠ Để ý các tín hiệu bất thường | ⚠ mạng xã hội, phản hồi bán hàng | | ⚠ Có kênh để họ lên tiếng nếu muốn | | | ⚠ Cập nhật vị trí của họ trên ma trận | ⚠ liên hệ #26957 lô 204 | | ⚠ Vì sao vẫn phải để mắt | ⚠ một nhóm quyền lực thấp có thể trở thành quyền lực cao rất nhanh nếu họ tập hợp lại — với người tiêu dùng thì một chiến dịch trên mạng xã hội có thể làm điều đó trong vài ngày, nên "theo dõi" là một chiến lược chủ động chứ không phải sự lãng quên |

⚠ Terrance nên hiểu kết quả khảo sát thế nào: | Cách đọc | Nội dung | |---|---| | ⚠ 76% không có ý kiến mạnh | ⚠ nghĩa là không có phản đối đáng kể | | ⚠ 24% CÓ ý kiến mới là nhóm đáng phân tích | ⚠ họ ủng hộ hay phản đối | | ⚠ Việc đổi bao bì ít rủi ro về mặt thị trường | | | ⚠ Việc đáng làm tiếp theo | ⚠ phân tích riêng nhóm 24% có ý kiến — một nhóm nhỏ có quan điểm mạnh thường có ảnh hưởng lớn hơn nhiều so với tỷ lệ của họ, và đó mới là nơi cần dồn công sức |

Từ khoá nhận diện:

"quyền lực thấp – quan tâm thấp" → ⚠ THEO DÕI "giữ thông tin đủ" → ⚠ quyền lực thấp – quan tâm CAO "giữ hài lòng" → ⚠ quyền lực CAO – quan tâm thấp "quản lý chặt" → ⚠ quyền lực CAO – quan tâm CAO

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có xếp được từng bên liên quan vào một trong bốn ô không | | | Có nhóm nào đang được đầu tư công sức quá mức cần thiết không | | | Có nhóm nào vừa chuyển ô mà bạn chưa nhận ra không | |

Và điều mà một cuộc khảo sát cho kết quả "phần lớn không quan tâm" thật sự mang lại: không phải sự thất vọng, mà là một rủi ro vừa được loại khỏi danh sách.

Đáp án

A — MỘT THAY ĐỔI (a change).

Vì sao đúng

⚠ Vì sao đây là một thay đổi: | Yếu tố | Nội dung | |---|---| | ⚠ Cách làm việc đã được thoả thuận từ đầu | ⚠ rà soát từng công việc trong WBS | | ⚠ Nay được sửa thành cách khác | ⚠ rà soát từng gói công việc | | ⚠ Có một quyết định được đưa ra để sửa | ⚠ bên liên quan cùng quyết định | | ⚠ Kết quả là quy trình dự án khác đi | ⚠ ít lần rà soát hơn | | ⚠ Kết luận | ⚠ thay đổi so với cách đã thoả thuận = một thay đổi, dù nó cải thiện tình hình |

⚠ Chú ý: ⚠ thay đổi không chỉ áp dụng cho phạm vi sản phẩm ⚠ — ⚠ cách quản lý dự án, quy trình rà soát, tần suất báo cáo cũng đều là những thứ có thể thay đổi và cần được ghi nhận; liên hệ #27061 lô 206 về kiểm soát thay đổi tích hợp.

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

• C (một vấn đề — an issue) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ việc rà soát từng công việc ĐÃ gây chậm trễ đáng kể, và chậm trễ đúng là một vấn đề — nên nhiều người dừng lại ở đó: ⚠ nhưng ⚠ đề không hỏi về sự chậm trễ, nó hỏi về việc BÊN LIÊN QUAN QUYẾT ĐỊNH ĐỔI CÁCH LÀM ⚠; ⚠ sự chậm trễ là vấn đề, còn quyết định sửa cách làm là một THAY ĐỔI — đó là hai sự việc khác nhau và đề đang hỏi cái thứ hai; ⚠ hãy đọc kỹ câu hỏi trỏ vào phần nào của đoạn văn.

• B (một sản phẩm bàn giao) — ⚠ sản phẩm bàn giao là kết quả hữu hình mà dự án tạo ra; ⚠ một quyết định về quy trình không phải sản phẩm bàn giao.

• D (một rủi ro) — ⚠ rủi ro là chuyện CHƯA xảy ra; ⚠ ở đây quyết định đã được đưa ra và cách làm đã đổi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27061 cùng lô (kiểm soát thay đổi tích hợp), ⚠ #27033 cùng lô (phân biệt sổ vấn đề với các sổ khác), ⚠ #26964 lô 204 (cập nhật đường cơ sở sau khi duyệt), ⚠ #27002 lô 205 (ghi nhận quyết định của ban kiểm soát thay đổi).

⚠ Phân biệt bốn khái niệm hay bị lẫn: | Khái niệm | Định nghĩa | |---|---| | ⚠ THAY ĐỔI | ⚠ sửa đổi so với thứ đã được thoả thuận — ĐÁP ÁN | | ⚠ VẤN ĐỀ | ⚠ chuyện đã xảy ra, cần xử lý | | ⚠ RỦI RO | ⚠ chuyện chưa xảy ra, có thể xảy ra | | ⚠ SẢN PHẨM BÀN GIAO | ⚠ kết quả hữu hình dự án tạo ra | | ⚠ Chuỗi liên hệ trong tình huống này | ⚠ rà soát từng công việc gây CHẬM TRỄ (vấn đề) → bên liên quan quyết định đổi cách rà soát (THAY ĐỔI) → quy trình mới được áp dụng; ba bước, và câu hỏi trỏ vào bước giữa |

⚠ Vì sao thay đổi này là một thay đổi TỐT: | Lợi ích | Nội dung | |---|---| | ⚠ Giảm mạnh số lần rà soát | ⚠ gói công việc gộp nhiều công việc con | | ⚠ Bên liên quan xem xét ở mức phù hợp hơn | ⚠ họ không cần biết chi tiết từng việc nhỏ | | ⚠ Đội bớt bị gián đoạn | | | ⚠ Bản thân bên liên quan tự đề xuất | ⚠ nên họ cam kết với cách mới | | ⚠ Bài học rút ra | ⚠ kỳ vọng ban đầu của bên liên quan thường vượt quá mức họ thật sự cần — và cách hiệu quả nhất để họ nhận ra điều đó là để chính họ trải nghiệm cái giá của kỳ vọng đó, rồi tự đề nghị điều chỉnh |

⚠ Thay đổi này vẫn cần được xử lý đúng quy trình: | Việc | Nội dung | |---|---| | ⚠ Ghi vào nhật ký thay đổi | ⚠ kể cả thay đổi có lợi — liên hệ #27002 lô 205 | | ⚠ Cập nhật kế hoạch quản lý dự án | ⚠ phần mô tả quy trình rà soát | | ⚠ Thông báo cho mọi bên liên quan | ⚠ không phải ai cũng dự cuộc họp đó | | ⚠ Cập nhật lịch các mốc rà soát | | | ⚠ Điều dễ bỏ qua nhất | ⚠ những thay đổi về QUY TRÌNH thường không được ghi lại vì chúng không đụng tới phạm vi hay ngân sách — nhưng chúng đụng tới kỳ vọng của người khác, và người không dự cuộc họp sẽ vẫn chờ được rà soát từng việc |

Từ khoá nhận diện:

"quyết định đổi cách làm đã thoả thuận" → ⚠ một THAY ĐỔI "chậm trễ do rà soát quá nhiều" → ⚠ đó là VẤN ĐỀ, nhưng không phải câu hỏi "sản phẩm bàn giao" → ⚠ kết quả hữu hình, không phải quyết định quy trình "rủi ro" → ⚠ chuyện chưa xảy ra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các thay đổi về quy trình của bạn có được ghi lại không | | | Bên liên quan có đang đòi mức rà soát vượt nhu cầu thật không | | | Ai chưa biết về thay đổi quy trình gần nhất | |

Và điều mà tình huống này minh hoạ rất hay về kỳ vọng của bên liên quan: họ thường tự điều chỉnh xuống mức hợp lý sau khi trải nghiệm cái giá của mức họ đã yêu cầu — miễn là có ai đó để cho họ thấy cái giá đó bằng số liệu.

Đáp án

C — RÀ SOÁT VIỆC SỬA LỖI (review the defect repair).

Vì sao đúng

⚠ Vì sao phải rà soát lại phần đã sửa: | Lý do | Nội dung | |---|---| | ⚠ Đội vừa làm lại phần việc đã làm sai | ⚠ đó chính là SỬA LỖI (defect repair) | | ⚠ Phải xác nhận lần này đã đúng chưa | ⚠ không thể mặc định là đã đúng | | ⚠ Rà soát sửa lỗi là bước bắt buộc của kiểm soát chất lượng | | | ⚠ Việc làm lại cũng có thể sai tiếp | ⚠ nhất là nếu nguyên nhân gốc chưa được xử lý | | ⚠ Kết luận | ⚠ vòng lặp chỉ khép lại khi có bước xác nhận, không khép lại khi công việc được tuyên bố là xong |

⚠ Sửa lỗi phải được kiểm tra như bất kỳ sản phẩm nào: ⚠ và trong nhiều trường hợp còn phải kiểm tra kỹ hơn ⚠ — ⚠ vì một lần sửa vội có thể tạo ra lỗi mới ở chỗ khác; liên hệ #26925 lô 203 về phân biệt các loại hành động.

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

• A (phân tích độ trễ do việc làm lại gây ra) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ việc làm lại chắc chắn đã gây chậm trễ và tốn thêm chi phí, nên phân tích tác động nghe rất hợp lý và đúng nghiệp vụ: ⚠ nhưng ⚠ đó là bước SAU ⚠ — ⚠ trước hết phải biết công việc lần này đã ĐẠT hay chưa, vì nếu chưa đạt thì độ trễ vừa tính sẽ lập tức sai; ⚠ và quan trọng hơn: chưa xác nhận chất lượng thì chưa thể coi công việc là hoàn thành để mà tính toán gì; ⚠ thứ tự luôn là XÁC NHẬN trước, PHÂN TÍCH TÁC ĐỘNG sau.

• D (đánh giá hiệu suất của từng thành viên trong đội) — ⚠ chuyển sang truy tìm cá nhân; ⚠ và trong hầu hết trường hợp, làm sai một lần là vấn đề của quy trình chứ không của con người — liên hệ #27024 lô 205.

• B (yêu cầu chủ sản phẩm thêm một việc để rà soát phần đã sửa) — ⚠ rà soát sửa lỗi là một phần của kiểm soát chất lượng; ⚠ nó không phải một hạng mục tồn đọng cần chủ sản phẩm phê duyệt.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26925 lô 203 (phân biệt phòng ngừa, khắc phục, sửa lỗi), ⚠ #26968 lô 204 (đầu ra của kiểm soát phạm vi), ⚠ #27024 lô 205 (tìm nguyên nhân gốc của chất lượng kém), ⚠ #27065 cùng lô (quản lý cấu hình bảo đảm tính toàn vẹn sản phẩm).

⚠ Chuỗi xử lý một sản phẩm bàn giao bị lỗi: | Bước | Nội dung | |---|---| | ⚠ 1. Phát hiện lỗi qua kiểm soát chất lượng | | | ⚠ 2. Ghi nhận và phân loại | ⚠ sổ vấn đề — liên hệ #27033 cùng lô | | ⚠ 3. Yêu cầu SỬA LỖI | ⚠ một dạng yêu cầu thay đổi | | ⚠ 4. Đội thực hiện việc sửa | ⚠ bước vừa hoàn thành trong đề | | ⚠ 5. RÀ SOÁT VIỆC SỬA LỖI | ⚠ ĐÁP ÁN — xác nhận đã đạt | | ⚠ 6. Cập nhật hồ sơ và phân tích tác động | ⚠ phương án A thuộc bước này | | ⚠ 7. Tìm nguyên nhân gốc để không lặp lại | ⚠ liên hệ #27024 lô 205 | | ⚠ Bước bị bỏ qua nhiều nhất trong thực tế | ⚠ bước 5 và bước 7 — người ta vui mừng vì việc đã xong rồi chuyển sang việc khác, nên không ai xác nhận và cũng không ai hỏi vì sao nó sai ngay từ đầu |

⚠ Rà soát việc sửa lỗi cần kiểm tra gì: | Nội dung | Vì sao | |---|---| | ⚠ Lỗi ban đầu đã hết chưa | ⚠ hiển nhiên nhưng vẫn phải kiểm | | ⚠ Có phát sinh lỗi mới không | ⚠ rủi ro lớn nhất của việc sửa vội | | ⚠ Phần liên quan có còn hoạt động đúng không | ⚠ kiểm thử hồi quy | | ⚠ Có đạt tiêu chí chấp nhận ban đầu không | | | ⚠ Hồ sơ và cấu hình đã được cập nhật chưa | ⚠ liên hệ #27065 cùng lô | | ⚠ Điểm quan trọng | ⚠ một bản sửa lỗi làm hỏng thứ khác là tình huống rất phổ biến — và nó đặc biệt nguy hiểm vì mọi người đã chuyển sự chú ý sang chỗ khác, nên lỗi mới thường không được phát hiện cho tới rất muộn |

⚠ Bối cảnh dự án lai của đề: | Yếu tố | Nội dung | |---|---| | ⚠ Dùng kiểm soát thay đổi kiểu dự đoán | ⚠ nên sửa lỗi đi qua quy trình chính thức | | ⚠ Có tồn đọng sản phẩm được xếp thứ tự | ⚠ phần agile của dự án | | ⚠ Việc sửa lỗi thuộc kiểm soát chất lượng | ⚠ không phải một hạng mục tồn đọng | | ⚠ Ranh giới cần nhớ trong dự án lai | ⚠ việc mới thì vào tồn đọng, còn việc SỬA thứ đáng lẽ phải đúng thì thuộc kiểm soát chất lượng — nhầm hai thứ này sẽ khiến các lỗi phải cạnh tranh vị trí ưu tiên với tính năng mới, và chúng gần như luôn thua |

Từ khoá nhận diện:

"đội vừa làm lại phần việc sai" → ⚠ RÀ SOÁT VIỆC SỬA LỖI "phân tích độ trễ" → ⚠ bước SAU khi đã xác nhận chất lượng "đánh giá hiệu suất từng người" → ⚠ truy tìm cá nhân cho một vấn đề quy trình "thêm việc vào tồn đọng để rà soát" → ⚠ rà soát sửa lỗi thuộc kiểm soát chất lượng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc sửa lỗi gần nhất của bạn có được rà soát lại không | | | Bạn có kiểm tra xem bản sửa có tạo lỗi mới không | | | Bạn có tìm nguyên nhân gốc sau khi sửa xong không | |

Và lý do bước xác nhận sau khi sửa lỗi hay bị bỏ qua nhất: vì lúc đó ai cũng muốn tin rằng vấn đề đã kết thúc — và niềm tin đó là thứ duy nhất chưa được kiểm chứng.

Đáp án

C — TÌM CÁCH GHI NHẬN DERRICK MỘT CÁCH CÔNG KHAI.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ở cuối ⚠ — ⚠ dừng ở "…while you wait for the company's fortunes to", tức là "…to change"; ⚠ bối cảnh đã đủ rõ.

Vì sao đúng

⚠ Vì sao ghi nhận công khai là công cụ đúng lúc này: | Ràng buộc | Cách ghi nhận công khai đáp ứng | |---|---| | ⚠ Đóng băng tuyển dụng và thăng chức | ⚠ ghi nhận không cần chức danh mới | | ⚠ Không tăng lương được trong hai năm | ⚠ ghi nhận không tốn tiền | | ⚠ Cần giữ Derrick lại | ⚠ được công nhận là một nhu cầu thật | | ⚠ Anh ấy đóng góp hết mình và giúp đồng đội | ⚠ có nội dung cụ thể để ghi nhận | | ⚠ Kết luận | ⚠ đây là phương án duy nhất khả thi trong mọi ràng buộc mà vẫn tạo ra giá trị thật |

⚠ Theo Herzberg: ⚠ lương là yếu tố DUY TRÌ, còn SỰ CÔNG NHẬN là yếu tố ĐỘNG VIÊN ⚠ — ⚠ nên khi không thể tăng lương, tác động vào cột động viên lại là việc hiệu quả hơn nhiều so với người ta tưởng; liên hệ #26988 lô 205.

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

• D (xin lãnh đạo cấp trên cấp kinh phí để tăng lương cho Derrick) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nhắm thẳng vào thứ Derrick xứng đáng nhất, và đấu tranh cho nhân viên của mình là hành vi đáng khen của một người quản lý: ⚠ nhưng ⚠ đề đã nói rõ có lệnh đóng băng toàn công ty do suy thoái kinh tế ⚠ — ⚠ xin ngoại lệ cho một người trong hoàn cảnh đó gần như chắc chắn bị từ chối, và nếu được duyệt thì tạo ra bất công với những người khác; ⚠ thêm nữa, nó khiến Derrick kỳ vọng rồi thất vọng, kết quả còn tệ hơn không hứa gì; ⚠ hãy chọn phương án khả thi TRONG các ràng buộc đã cho, không phải phương án đòi bỏ ràng buộc đi.

• A (giáng chức một người khác để trao vị trí đó cho Derrick) — ⚠ phi đạo đức và phá huỷ tinh thần cả đội; ⚠ đổi một người ở lại lấy một người ra đi.

• B (không làm gì, cứ chờ) — ⚠ gần như chắc chắn mất Derrick; ⚠ người giỏi không chờ hai năm để được ghi nhận.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26988 lô 205 (Herzberg: yếu tố duy trì và động viên), ⚠ #26923 lô 203 (thuyết kỳ vọng Vroom), ⚠ #27063 cùng lô (Thuyết Z và sự tham gia), ⚠ #27057 cùng lô (giữ gắn kết khi không có công cụ vật chất).

⚠ Các cách ghi nhận không tốn tiền: | Cách | Nội dung | |---|---| | ⚠ Nêu tên và đóng góp cụ thể trước cả đội | ⚠ cụ thể mới có giá trị, không nói chung chung | | ⚠ Báo cáo đóng góp của anh ấy lên cấp trên | ⚠ có ghi vào hồ sơ, hữu ích khi hết đóng băng | | ⚠ Giao việc thú vị hơn hoặc có tầm ảnh hưởng hơn | ⚠ bản thân công việc là yếu tố động viên | | ⚠ Cho anh ấy quyền tự chủ lớn hơn | | | ⚠ Cơ hội học hỏi, dự hội thảo, dẫn dắt một mảng | | | ⚠ Vai trò cố vấn cho người trẻ hơn | ⚠ liên hệ #27048 cùng lô | | ⚠ Điều hiệu quả nhất | ⚠ giao một việc mà chỉ người xuất sắc mới làm được, rồi nói rõ vì sao chọn anh ấy — nó vừa là ghi nhận vừa là cơ hội phát triển, và nó không cần bất kỳ khoản chi nào |

⚠ Ghi nhận thế nào cho có tác dụng thật: | Nên | Không nên | |---|---| | ⚠ CỤ THỂ: nêu rõ việc gì, tác động ra sao | ⚠ "Derrick làm việc rất tốt" | | ⚠ KỊP THỜI: gần với thời điểm đóng góp | ⚠ để dành tới kỳ đánh giá cuối năm | | ⚠ Công khai trước những người anh ấy coi trọng | ⚠ chỉ nói riêng rồi thôi | | ⚠ Chân thành, không hình thức | ⚠ luân phiên khen mỗi người một lần cho công bằng | | ⚠ Cái bẫy của ghi nhận hình thức | ⚠ một lời khen chung chung lặp đi lặp lại còn tệ hơn im lặng — nó nói rằng bạn không thật sự để ý tới việc người ta làm, và một người như Derrick sẽ nhận ra điều đó ngay |

⚠ Cũng nên trung thực với Derrick: | Việc | Nội dung | |---|---| | ⚠ Nói thật về tình hình đóng băng | ⚠ đừng để anh ấy tự đoán | | ⚠ Nói rõ bạn đang làm gì cho anh ấy | ⚠ ghi vào hồ sơ, đề xuất khi có cơ hội | | ⚠ Đừng hứa điều mình không quyết được | | | ⚠ Hỏi anh ấy điều gì có ý nghĩa nhất với mình | ⚠ có thể không phải tiền — liên hệ #26923 lô 203 | | ⚠ Nhận xét | ⚠ rất nhiều người ở lại một công việc lương thấp hơn vì họ được coi trọng và được làm việc có ý nghĩa — nhưng gần như không ai ở lại một nơi mà họ cảm thấy đóng góp của mình không được ai nhìn thấy |

Từ khoá nhận diện:

"đóng băng lương thưởng nhưng cần giữ người giỏi" → ⚠ GHI NHẬN CÔNG KHAI "xin ngoại lệ tăng lương" → ⚠ đòi bỏ ràng buộc, gần như chắc chắn bị từ chối "giáng chức người khác" → ⚠ phi đạo đức, mất thêm người "không làm gì, chờ" → ⚠ gần như chắc chắn mất Derrick

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần gần nhất bạn ghi nhận ai đó công khai là khi nào | | | Bạn có nêu được đóng góp cụ thể của họ không | | | Bạn có biết điều gì có ý nghĩa nhất với từng người trong đội không | |

Và điều mà một người như Derrick cần nhất khi tổ chức không thể trả thêm cho anh ấy: bằng chứng rằng có người đang nhìn thấy — vì thứ khiến người giỏi ra đi hiếm khi là tiền, mà là cảm giác mình có thể biến mất mà không ai nhận ra.

Đáp án

C — KHÔNG TÍNH THÊM TIỀN CHO CÁC THAY ĐỔI NẾU CHÚNG KHÔNG LÀM TĂNG KHỐI LƯỢNG CÔNG VIỆC.

Vì sao đúng

⚠ Nguyên tắc nền của hợp đồng agile: | Yếu tố | Nội dung | |---|---| | ⚠ Cố định KHỐI LƯỢNG hoặc THỜI GIAN, mở NỘI DUNG | ⚠ cấu trúc đặc trưng | | ⚠ Khách hàng được xếp lại thứ tự tồn đọng tự do | ⚠ đó là quyền cốt lõi của họ | | ⚠ Đổi ngang: thêm việc mới thì bỏ việc cũ tương đương | ⚠ tổng khối lượng không đổi | | ⚠ Tổng khối lượng không đổi ⇒ giá không đổi | ⚠ hoàn toàn logic | | ⚠ Kết luận | ⚠ nhà cung cấp không tính thêm vì họ vẫn làm đúng ngần ấy công việc, chỉ khác thứ tự và nội dung |

⚠ Vì sao mô hình này hoạt động được: ⚠ nhà cung cấp bán CÔNG SUẤT chứ không bán một danh sách tính năng cố định ⚠ — ⚠ nên với họ, việc khách đổi ý về nội dung không phải rủi ro; liên hệ #27029 lô 205 và #26963 lô 204.

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

• A (thương lượng lại hợp đồng để đưa các thay đổi vào) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đó chính xác là điều PHẢI làm trong một hợp đồng truyền thống, và nhiều người mang phản xạ đó sang agile: ⚠ nhưng ⚠ nếu mỗi lần xếp lại tồn đọng đều phải thương lượng lại hợp đồng thì toàn bộ lợi thế linh hoạt của agile biến mất ⚠ — ⚠ và chi phí giao dịch sẽ vượt xa giá trị của sự linh hoạt; ⚠ hợp đồng agile được thiết kế để CHỨA SẴN khả năng thay đổi, nên không cần thương lượng lại mỗi lần; ⚠ liên hệ #26963 lô 204: cho phép xếp lại thứ tự phạm vi chính là đặc điểm trung tâm của hợp đồng agile.

• D (chạy quy trình kiểm soát thay đổi chính thức với sự phê duyệt của cả đội) — ⚠ là cơ chế của dự án dự đoán; ⚠ và trong agile, việc xếp lại tồn đọng là quyền thường trực của chủ sản phẩm, không cần hội đồng nào duyệt — liên hệ #27022 lô 205.

• B (huỷ hợp đồng) — ⚠ phản ứng cực đoan và vô lý; ⚠ khách hàng đang làm đúng điều mà hợp đồng agile cho phép.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27029 lô 205 (đổi loại hợp đồng khi chuyển sang agile), ⚠ #26963 lô 204 (hợp đồng agile cho phép xếp lại phạm vi), ⚠ #26914 lô 203 và #26818 lô 201 (mô hình hợp đồng linh hoạt), ⚠ #27022 lô 205 (thêm việc vào tồn đọng).

⚠ Điều khoản ĐỔI NGANG trong hợp đồng agile: | Yếu tố | Nội dung | |---|---| | ⚠ Khách được thay bất kỳ hạng mục nào chưa làm | | | ⚠ Bằng một hạng mục có KÍCH THƯỚC tương đương | ⚠ đo bằng điểm câu chuyện hoặc giờ công | | ⚠ Không phát sinh chi phí, không thương lượng lại | | | ⚠ Nếu khối lượng TĂNG thì mới tính thêm | ⚠ ranh giới rõ ràng | | ⚠ Vì sao điều khoản này công bằng cho cả hai | ⚠ khách có được sự linh hoạt mà họ cần, nhà cung cấp có được sự chắc chắn về khối lượng công việc — không bên nào phải gánh rủi ro của bên kia |

⚠ Điều kiện để mô hình này hoạt động: | Điều kiện | Nội dung | |---|---| | ⚠ Phải có cách ĐO khối lượng công việc | ⚠ điểm câu chuyện, giờ công, hoặc gói công việc | | ⚠ Cả hai bên tin vào cách đo đó | | | ⚠ Chỉ áp dụng cho hạng mục CHƯA bắt đầu | ⚠ đổi việc đang làm dở thì có lãng phí thật | | ⚠ Có cơ chế xử lý khi hai bên bất đồng về kích thước | | | ⚠ Điểm dễ gây tranh chấp nhất | ⚠ ai là người quyết một hạng mục mới "tương đương" với hạng mục cũ hay không — điều này phải được ghi rõ trong hợp đồng, thường là do đội ước lượng và hai bên xác nhận |

⚠ Khi nào nhà cung cấp ĐƯỢC tính thêm tiền: | Trường hợp | Nội dung | |---|---| | ⚠ Tổng khối lượng công việc TĂNG | ⚠ thêm mà không bỏ bớt | | ⚠ Đổi hạng mục đang làm dở | ⚠ phần đã làm bị bỏ đi | | ⚠ Thay đổi làm phát sinh công việc kỹ thuật nền mới | | | ⚠ Yêu cầu kéo dài thời gian dự án | ⚠ chi phí duy trì đội | | ⚠ Nguyên tắc phân định | ⚠ câu hỏi luôn là "tổng công sức có tăng không", chứ không phải "nội dung có đổi không" — và chính sự phân biệt đó làm cho hợp đồng agile vừa linh hoạt vừa công bằng |

Từ khoá nhận diện:

"xếp lại tồn đọng, khối lượng không tăng" → ⚠ KHÔNG tính thêm tiền "thương lượng lại hợp đồng" → ⚠ phản xạ của hợp đồng truyền thống, phá vỡ lợi thế agile "kiểm soát thay đổi chính thức" → ⚠ cơ chế của dự án dự đoán "huỷ hợp đồng" → ⚠ khách đang làm đúng điều hợp đồng cho phép

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có điều khoản đổi ngang không | | | Hai bên có thống nhất cách đo khối lượng công việc không | | | Ai quyết định hai hạng mục có tương đương nhau hay không | |

Và điều mà một hợp đồng agile tốt bán cho khách hàng, khác hẳn hợp đồng truyền thống: không phải một danh sách tính năng, mà quyền được đổi ý về danh sách đó cho tới khi công việc thật sự bắt đầu.