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

Tìm thấy 720 câu.

Câu 151 People
Jada is the project manager for her organization and is serving as a coach and mentor for multiple junior project managers. With her project team, she is currently reviewing the inputs for stakeholder engagement monitoring. Some of the inputs essential to stakeholder engagement monitoring are confusing to Jada’s team members. How does the issue log, one of the inputs to monitoring stakeholder engagement, help Jada prepare to monitor stakeholder engagement?
  1. A This is not true; the issue log is not an input to stakeholder engagement monitoring.
  2. B The issue log assists in communicating the status of issues and helps track and respond to issues
  3. C Only when issues are defined by the stakeholders are issue logs needed.
  4. D The issue log helps discern which stakeholders are causing the project’s issues.
Xem giải thích

Đáp án

B — Sổ vấn đề giúp TRUYỀN ĐẠT trạng thái của các vấn đề, đồng thời giúp THEO DÕI và ỨNG PHÓ với chúng.

Vì sao đúng

⚠ Vì sao sổ vấn đề là đầu vào của Monitor Stakeholder Engagement: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề chưa giải quyết làm bên liên quan BẤT MÃN | ⚠ ảnh hưởng trực tiếp tới mức tham gia của họ | | ⚠ Sổ vấn đề cho biết vấn đề nào ĐANG mở, ai chịu trách nhiệm | | | ⚠ Là bằng chứng dự án CÓ xử lý mối lo của bên liên quan | | | ⚠ Giúp giao tiếp minh bạch về tình trạng xử lý | | | ⚠ Kết luận | ⚠ theo dõi vấn đề chính là theo dõi một phần quan trọng của quan hệ với bên liên quan |

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

  • A (sổ vấn đề KHÔNG phải đầu vào) — ⚠ SAI: ⚠ PMBOK liệt kê issue log là đầu vào chính thức của Monitor Stakeholder Engagement.

  • D (giúp nhận ra bên liên quan nào GÂY RA vấn đề) — ⚠ hiểu sai mục đích: ⚠ sổ vấn đề để ⚠ GIẢI QUYẾT vấn đề, không phải để quy trách nhiệm cho ai.

  • C (chỉ cần sổ vấn đề khi bên liên quan định nghĩa vấn đề) — ⚠ SAI: ⚠ vấn đề có thể phát sinh từ bất kỳ đâu, không riêng bên liên quan.

Ghi nhớ

⚠ Sổ vấn đề — issue log: | Đặc điểm | Nội dung | |---|---| | ⚠ Ghi các vấn đề ĐANG xảy ra cần được xử lý | | | ⚠ Được TẠO RA ở Direct and Manage Project Work | | | ⚠ Nội dung: mã, loại, mô tả, người nêu, ngày nêu, mức ưu tiên, người chịu trách nhiệm, hạn xử lý, trạng thái, giải pháp | | | ⚠ Là đầu vào của RẤT NHIỀU quy trình giám sát | | | ⚠ Khác risk register | ⚠ rủi ro CHƯA xảy ra; vấn đề ĐÃ xảy ra |

⚠ Bốn đầu vào chính của Monitor Stakeholder Engagement: | Đầu vào | Vai trò | |---|---| | ⚠ Project management plan | ⚠ kế hoạch tham gia, kế hoạch giao tiếp, kế hoạch nguồn lực | | ⚠ Project documents | ⚠ ISSUE LOG, lessons learned, sổ đăng ký bên liên quan, dữ liệu hiệu suất | | ⚠ Work performance data | | | ⚠ EEF và OPA | | | ⚠ Đầu ra | ⚠ work performance information, yêu cầu thay đổi, cập nhật kế hoạch và tài liệu |

Từ khoá nhận diện:

"vấn đề đang xảy ra, cần xử lý" → ⚠ issue log "sự kiện chưa chắc chắn có thể xảy ra" → ⚠ risk register "điều coi là đúng mà chưa kiểm chứng" → ⚠ assumption log "quy trách nhiệm cho ai gây ra vấn đề" → ⚠ KHÔNG phải mục đích của sổ vấn đề

⚠ Quan hệ giữa vấn đề và mức tham gia của bên liên quan Quan hệ
⚠ Vấn đề tồn đọng lâu → bên liên quan mất niềm tin
⚠ Vấn đề của HỌ không được xử lý → họ chuyển sang phản đối ⚠ xem câu #25702 ở lô 179
⚠ Xử lý nhanh và minh bạch → tăng niềm tin
⚠ Vì thế ⚠ sổ vấn đề là chỉ báo sớm về sức khoẻ quan hệ với bên liên quan
⚠ Một sổ vấn đề hữu ích cần gì Cần
⚠ Mỗi vấn đề có ĐÚNG MỘT người chịu trách nhiệm
⚠ Có HẠN XỬ LÝ rõ ràng
⚠ Được rà soát ĐỊNH KỲ, không để tồn đọng
⚠ Người nêu vấn đề được PHẢN HỒI kết quả ⚠ không phản hồi thì lần sau họ không nêu nữa
⚠ Dấu hiệu xấu ⚠ sổ vấn đề dài ra mà không có mục nào được đóng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ vấn đề của bạn có được rà soát định kỳ không | | | Mỗi vấn đề có người chịu trách nhiệm và hạn không | | | Người nêu vấn đề có được phản hồi không | |

Và điều sổ vấn đề nói lên về dự án: số vấn đề mở và tuổi trung bình của chúng là thước đo sức khoẻ quan hệ với bên liên quan. Danh sách dài mà không ai đóng là dấu hiệu đáng lo hơn cả chậm tiến độ.

Câu 152 Process
Marc is the project management office manager and is scrambling to fill in for a project manager's role that recently left the organization due to a family emergency. One of Marc's challenges is leveraging his project manager's relationships and contacts in driving his project. What is the likely cause of this challenge from the project management office perspective?
  1. A The communication plan was complete.
  2. B The project manager was not following governance policies set out by the organization.
  3. C The stakeholder register was not up to date.
  4. D Lack of systems to capture institutional knowledge from the projects.
Xem giải thích

Đáp án

D — THIẾU HỆ THỐNG để giữ lại TRI THỨC TỔ CHỨC từ các dự án.

Vì sao đúng

⚠ Bóc tách vấn đề của Marc: | Chi tiết | Suy ra | |---|---| | ⚠ Một quản lý dự án rời tổ chức ĐỘT NGỘT | | | ⚠ Marc khó tận dụng QUAN HỆ và LIÊN HỆ của người đó | ⚠ những thứ chỉ nằm trong đầu người đó | | ⚠ Nhìn từ góc độ PMO | ⚠ đây là vấn đề HỆ THỐNG, không phải vấn đề cá nhân | | ⚠ Kết luận | ⚠ tổ chức không có cơ chế biến tri thức cá nhân thành tài sản tổ chức |

⚠ Vì sao đây là vấn đề của PMO: | Lý do | Nội dung | |---|---| | ⚠ PMO chịu trách nhiệm về TÀI SẢN QUY TRÌNH TỔ CHỨC | | | ⚠ PMO lo tính LIÊN TỤC khi có thay đổi nhân sự | | | ⚠ Đây là RỦI RO nhân sự chủ chốt ở cấp tổ chức | | | ⚠ Giải pháp | ⚠ hệ thống quản lý tri thức, chứ không phải trách người đã đi |

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

  • C (sổ đăng ký bên liên quan chưa được cập nhật) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ đúng là một phần vấn đề, ⚠ nhưng quá HẸP: ⚠ sổ bên liên quan ghi được TÊN và VAI TRÒ, ⚠ nhưng không ghi được ⚠ QUAN HỆ và mức độ tin cậy đã xây dựng — đó là tri thức ẩn.

  • B (quản lý dự án không tuân theo chính sách quản trị) — ⚠ quy lỗi cho người đã đi mà không có căn cứ.

  • A (kế hoạch giao tiếp đã hoàn chỉnh) — ⚠ là điều TỐT, ⚠ không giải thích được vấn đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25868 ở lô này (lập tài liệu bài học trước khi mất đội), câu #25630 ở lô 177 (tri thức ẩn), và câu #25757, #25761 ở lô 180 (thu thập bài học kinh nghiệm). ⚠ Năm câu cùng một chủ đề lớn: tri thức phải được chuyển từ CÁ NHÂN sang TỔ CHỨC.

⚠ Tri thức ẩn và tri thức hiện — nhắc lại: | Loại | Nội dung | Chuyển giao bằng | |---|---|---| | ⚠ EXPLICIT — hiện | ⚠ viết ra được: tài liệu, quy trình, dữ liệu | ⚠ văn bản, cơ sở dữ liệu | | ⚠ TACIT — ẩn | ⚠ QUAN HỆ, kinh nghiệm, trực giác, biết ai nên hỏi việc gì | ⚠ tương tác giữa người với người | | ⚠ Quan hệ và liên hệ của PM | ⚠ thuộc loại ẨN — khó ghi lại nhất và mất nhanh nhất |

Từ khoá nhận diện:

"mất người là mất quan hệ và kinh nghiệm" → ⚠ thiếu hệ thống giữ tri thức tổ chức "sổ đăng ký bên liên quan" → ⚠ ghi được tên và vai trò, không ghi được quan hệ "nhìn từ góc độ PMO" → ⚠ vấn đề HỆ THỐNG, không phải vấn đề cá nhân "quy lỗi cho người đã đi" → ⚠ thường là đáp án sai

⚠ Hệ thống giữ tri thức tổ chức gồm gì Thành phần
⚠ Kho BÀI HỌC KINH NGHIỆM có thể tìm kiếm
⚠ Sổ đăng ký bên liên quan có ghi CHÚ về quan hệ ⚠ ai là người nên tiếp cận cho vấn đề gì
⚠ Danh bạ nhà cung cấp và đánh giá hiệu suất của họ
⚠ Cộng đồng thực hành giữa các quản lý dự án
⚠ Cơ chế BÀN GIAO chuẩn khi PM chuyển đi ⚠ thứ Marc đang thiếu nhất
⚠ Ghép cặp hoặc PM dự bị cho dự án quan trọng
⚠ Marc nên làm gì NGAY và LÂU DÀI Việc
⚠ NGAY: liên hệ người cũ nếu còn được ⚠ xin vài buổi bàn giao
⚠ NGAY: rà soát mọi tài liệu dự án để tìm manh mối
⚠ NGAY: gặp trực tiếp các bên liên quan chính để tự xây quan hệ
⚠ LÂU DÀI: xây quy trình BÀN GIAO bắt buộc khi PM chuyển đi
⚠ LÂU DÀI: yêu cầu ghi bài học kinh nghiệm định kỳ, không đợi cuối dự án
⚠ LÂU DÀI: giảm phụ thuộc vào một cá nhân cho dự án quan trọng
⚠ Vì sao QUAN HỆ khó chuyển giao nhất Lý do
⚠ Niềm tin xây dựng qua thời gian, không chuyển nhượng được
⚠ Nhiều thông tin nằm ở mức "biết ai để hỏi", không viết ra được
⚠ Bên liên quan cũng phải làm quen lại với người mới
⚠ Giảm thiểu bằng cách ⚠ cho nhiều người trong đội tiếp xúc với bên liên quan, không để một người độc quyền quan hệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nếu bạn nghỉ ngày mai, dự án có tiếp tục được không | ⚠ phép thử tốt nhất | | Tổ chức có quy trình bàn giao khi PM chuyển đi không | | | Có ai ngoài bạn biết các bên liên quan chính không | |

Và rủi ro mà mọi tổ chức đều có nhưng ít ai đo: tri thức quan trọng nhất thường nằm trong đầu người, không nằm trong hệ thống. Chỉ tới khi mất người mới phát hiện ra.

Câu 153 People
Joseph has properly incorporated the agile principle of building projects around motivated team members, and he trusts them to get their work done. Which of these scenarios did he implement?
  1. A Joseph provides an assignment list of each cycle of the work to be completed, so the team can pick how they would like to handle those assignments.
  2. B Joseph has implemented the best processes and tools to ensure that the team can keep everyone informed regarding their daily progress.
  3. C Joseph has created a self-organizing team that makes its own decisions daily, receiving additional support from Joseph when they need it
  4. D Joseph and the product owner organize and plan the work in product and sprint backlog sessions. As a self-organizing team, the group then distributes that work, being careful not to exceed the team's capacity.
Xem giải thích

Đáp án

C — Joseph đã tạo ra một đội TỰ TỔ CHỨC, tự ra quyết định hằng ngày, và nhận thêm hỗ trợ từ Joseph khi họ cần.

Vì sao đúng

⚠ Nguyên tắc thứ năm của Tuyên ngôn Agile:

⚠ "Xây dựng dự án quanh những CÁ NHÂN CÓ ĐỘNG LỰC. Trao cho họ MÔI TRƯỜNG và SỰ HỖ TRỢ họ cần, và TIN TƯỞNG rằng họ sẽ hoàn thành công việc."

Yếu tố trong nguyên tắc Phương án C đáp ứng
⚠ Đội TỰ TỔ CHỨC ⚠ tự ra quyết định hằng ngày
⚠ Được TIN TƯỞNG ⚠ Joseph không giao việc chi tiết
⚠ Có SỰ HỖ TRỢ khi cần ⚠ Joseph hỗ trợ khi họ yêu cầu — không áp đặt
⚠ Kết luận ⚠ đủ cả ba yếu tố: động lực, môi trường, và sự tin tưởng

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

  • D (Joseph và product owner tổ chức và lập kế hoạch công việc trong các buổi backlog, rồi đội tự phân chia) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ mô tả đúng cách Scrum vận hành, ⚠ nhưng trọng tâm là QUY TRÌNH lập kế hoạch, không phải sự TIN TƯỞNG và TỰ CHỦ hằng ngày mà nguyên tắc nói tới.

  • A (Joseph cấp danh sách công việc cho mỗi chu kỳ để đội chọn cách xử lý) — ⚠ vẫn là GIAO VIỆC từ trên xuống; ⚠ đội chỉ được chọn cách làm, không được quyết làm gì.

  • B (Joseph triển khai quy trình và công cụ tốt nhất để cập nhật tiến độ) — ⚠ trái với giá trị đầu tiên của tuyên ngôn: ⚠ ⚠ "cá nhân và tương tác HƠN quy trình và công cụ".

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25721 ở lô 179 (đội kiểm soát việc lập kế hoạch chi tiết), câu #25729 (kéo cả đội vào giải quyết vấn đề), và câu #25747 ở lô 180 (hỏi đội muốn xử lý thế nào). ⚠ Bốn câu cùng khẳng định nguyên tắc tự tổ chức.

⚠ Đội tự tổ chức nghĩa là gì: | Có | Không có | |---|---| | ⚠ Tự quyết CÁCH làm việc | ⚠ không tự quyết LÀM GÌ — đó là của product owner | | ⚠ Tự phân công công việc trong đội | ⚠ không tự quyết ngân sách và phạm vi tổng thể | | ⚠ Tự ước lượng khối lượng nhận vào sprint | | | ⚠ Tự quyết phương án kỹ thuật | | | ⚠ Tự tổ chức KHÔNG có nghĩa là | ⚠ không có định hướng, không có ranh giới, hay không cần lãnh đạo |

Từ khoá nhận diện:

"đội tự quyết hằng ngày, được tin tưởng, có hỗ trợ khi cần" → ⚠ nguyên tắc xây quanh người có động lực "cấp danh sách công việc" → ⚠ vẫn là giao việc từ trên xuống "quy trình và công cụ tốt nhất" → ⚠ trái giá trị đầu tiên của tuyên ngôn "lập kế hoạch trong buổi backlog" → ⚠ đúng về quy trình nhưng không phải trọng tâm của nguyên tắc này

⚠ Ba yếu tố nguyên tắc này đòi hỏi Yếu tố
⚠ CÁ NHÂN CÓ ĐỘNG LỰC ⚠ tuyển và giữ đúng người
⚠ MÔI TRƯỜNG phù hợp ⚠ công cụ, không gian, thời gian, ít gián đoạn
⚠ SỰ HỖ TRỢ khi cần ⚠ gỡ trở ngại, không giám sát vi mô
⚠ Và quan trọng nhất: TIN TƯỞNG họ hoàn thành công việc
⚠ Thiếu vế cuối ⚠ hai vế đầu cũng vô nghĩa
⚠ Vì sao "tin tưởng" là phần khó nhất Lý do
⚠ Người quản lý quen kiểm soát khó buông
⚠ Tổ chức thường đo bằng hoạt động thay vì kết quả
⚠ Sợ chịu trách nhiệm nếu đội quyết sai
⚠ Nhưng ⚠ giám sát vi mô giết chết động lực nhanh hơn bất cứ điều gì khác
⚠ Liên hệ ⚠ xem câu #25732 ở lô 179 — đội lâu năm ghét bị sai bảo
⚠ Ranh giới giữa hỗ trợ và can thiệp Ranh giới
⚠ HỖ TRỢ: đội YÊU CẦU thì mình có mặt ⚠ cách của Joseph
⚠ CAN THIỆP: mình tự quyết thay đội
⚠ BỎ MẶC: đội cần mà mình không có mặt ⚠ laissez-faire — xem câu #25881 ở lô này
⚠ Lãnh đạo phục vụ ⚠ nằm đúng giữa: chủ động sẵn sàng nhưng không áp đặt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai quyết định ai làm việc gì trong đội bạn | ⚠ nếu là bạn thì chưa phải tự tổ chức | | Đội có dám ra quyết định mà không hỏi bạn không | | | Bạn có mặt khi đội cần không | ⚠ tin tưởng khác với bỏ mặc |

Và điều phân biệt trao quyền với buông xuôi: trao quyền là tin tưởng KÈM sẵn sàng hỗ trợ. Joseph làm đúng cả hai vế.

Câu 154 Process
You are a project manager for your organization. You have procured four staff members from a vendor to help with the project work. Two of these staff members are no longer needed on the project. Which document will determine how the procured project team members may be excused from the project?
  1. A The schedule management plan
  2. B The scope management plan
  3. C The contract between your organization and the vendor
  4. D The staffing management plan
Xem giải thích

Đáp án

C — HỢP ĐỒNG giữa tổ chức của bạn và nhà cung cấp.

Vì sao đúng

⚠ Vì sao hợp đồng là căn cứ: | Lý do | Nội dung | |---|---| | ⚠ Bốn người này là nhân sự THUÊ TỪ NHÀ CUNG CẤP | ⚠ không phải nhân viên của tổ chức bạn | | ⚠ Quan hệ với họ được điều chỉnh bởi HỢP ĐỒNG | | | ⚠ Hợp đồng quy định điều kiện KẾT THÚC sử dụng nhân sự | ⚠ thời hạn báo trước, phí phạt, thủ tục | | ⚠ Cho nghỉ sai thủ tục có thể VI PHẠM hợp đồng | | | ⚠ Kết luận | ⚠ mọi việc liên quan tới nhân sự thuê ngoài đều tra ở HỢP ĐỒNG |

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

  • D (staffing management plan — kế hoạch quản lý nhân sự) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ kế hoạch này có phần ⚠ release criteria — điều kiện giải phóng nhân sự, ⚠ nhưng nó áp dụng cho NHÂN VIÊN NỘI BỘ; ⚠ với người thuê ngoài thì HỢP ĐỒNG có hiệu lực cao hơn.

  • A (schedule management plan) — ⚠ nói về cách quản lý lịch trình, ⚠ không nói về điều kiện chấm dứt nhân sự.

  • B (scope management plan) — ⚠ nói về cách quản lý phạm vi, ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25652 ở lô 178 (thay đổi ảnh hưởng hợp đồng → Control Procurements), câu #25822 ở lô 181 (đối chiếu hợp đồng khi nhà thầu làm sai), và câu #25871 ở lô này (thư ý định). ⚠ Bốn câu cùng một nguyên tắc: với bên ngoài, HỢP ĐỒNG là căn cứ tối cao.

⚠ Nhân sự nội bộ và nhân sự thuê ngoài — khác nhau ở đâu: | Mục | Nhân viên nội bộ | Nhân sự thuê ngoài | |---|---|---| | ⚠ Căn cứ điều chỉnh | ⚠ chính sách nhân sự, staffing management plan | ⚠ HỢP ĐỒNG | | ⚠ Điều kiện kết thúc | ⚠ release criteria trong kế hoạch nguồn lực | ⚠ điều khoản hợp đồng | | ⚠ Ai quyết định | ⚠ PM phối hợp với quản lý chức năng | ⚠ PM phối hợp với bộ phận MUA SẮM | | ⚠ Rủi ro nếu làm sai | ⚠ vấn đề nhân sự | ⚠ VI PHẠM HỢP ĐỒNG, có thể bị phạt |

Từ khoá nhận diện:

"nhân sự thuê từ nhà cung cấp" → ⚠ mọi thứ tra ở HỢP ĐỒNG "nhân viên nội bộ" → ⚠ staffing management plan, chính sách nhân sự "điều kiện giải phóng nguồn lực" → ⚠ release criteria — có ở cả hai nhưng nguồn khác nhau "thay đổi ảnh hưởng hợp đồng" → ⚠ Control Procurements

⚠ Cần kiểm tra gì trong hợp đồng Nội dung
⚠ Thời hạn BÁO TRƯỚC khi kết thúc sử dụng nhân sự
⚠ Có phí phạt hay không
⚠ Cam kết số lượng tối thiểu hoặc thời gian tối thiểu ⚠ nếu có thì không cho nghỉ sớm được
⚠ Thủ tục thông báo bằng văn bản
⚠ Trách nhiệm bàn giao công việc ⚠ quan trọng — tránh mất tri thức
⚠ Nếu hợp đồng không rõ ⚠ hỏi bộ phận mua sắm và pháp chế trước khi hành động
⚠ Quy trình đúng để cho họ nghỉ Bước
⚠ 1. Đọc kỹ điều khoản hợp đồng
⚠ 2. Phối hợp với bộ phận MUA SẮM ⚠ PM thường không tự ý sửa hợp đồng
⚠ 3. Thông báo cho nhà cung cấp theo đúng thủ tục và thời hạn
⚠ 4. Đảm bảo BÀN GIAO công việc và tri thức ⚠ xem câu #25874 ở lô này
⚠ 5. Cập nhật lịch nguồn lực và kế hoạch
⚠ 6. Thu hồi quyền truy cập hệ thống
⚠ Đừng ⚠ chỉ nói miệng với họ rằng không cần nữa
⚠ Lưu ý về quan hệ với nhà cung cấp Lưu ý
⚠ Cho nghỉ đúng thủ tục giữ được quan hệ tốt
⚠ Có thể còn cần họ ở dự án sau ⚠ xem câu #25766 ở lô 180 về quan hệ đối tác
⚠ Giải thích lý do một cách chuyên nghiệp
⚠ Nhớ rằng ⚠ hai người này không làm gì sai — dự án chỉ đơn giản không còn cần họ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng nói gì về việc kết thúc sớm | | | Bạn có phải phối hợp với bộ phận mua sắm không | ⚠ hầu như luôn là có | | Công việc và tri thức của họ đã được bàn giao chưa | |

Và nguyên tắc đơn giản cho mọi tình huống liên quan tới bên ngoài tổ chức: tra hợp đồng trước, hỏi pháp chế sau, hành động cuối cùng.

Câu 155 People
Anna May is a scrum master at the Michigan Plastics Corporation, which recently began using agile methodologies for some projects. Today Anna May overheard two stakeholders talking about dropping into the next sprint stand up to get updates on the project's status. The stakeholders specifically want to see a demo of what the team has created. What should Anna May do?
  1. A Ask someone on the development team to reach out with updates for those stakeholders.
  2. B Connect with the two stakeholders and direct them to the product owner.
  3. C Do nothing. The stakeholders will get the information they need at the next standup.
  4. D Connect with the two stakeholders and invite them to the next sprint review.
Xem giải thích

Đáp án

D — Liên hệ với hai bên liên quan và MỜI HỌ tới buổi SPRINT REVIEW tiếp theo.

Vì sao đúng

⚠ Vì sao sprint review là nơi phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Bên liên quan muốn xem DEMO | ⚠ sprint review chính là nơi trình diễn increment | | ⚠ Sprint review dành cho BÊN LIÊN QUAN tham dự | | | ⚠ Daily standup là buổi của ĐỘI, chỉ 15 phút để đồng bộ | ⚠ không phải nơi trình diễn hay báo cáo | | ⚠ Bên liên quan dự standup làm đội mất tự nhiên | ⚠ họ dễ biến nó thành buổi báo cáo tình trạng | | ⚠ Kết luận | ⚠ hướng họ tới đúng buổi họp phục vụ đúng nhu cầu của họ |

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

  • C (không làm gì, họ sẽ nhận thông tin ở standup) — ⚠ để họ dự sai buổi họp; ⚠ standup không có demo, ⚠ và sự có mặt của họ làm hỏng mục đích của standup.

  • B (kết nối với họ rồi hướng sang product owner) — ⚠ đẩy trách nhiệm: ⚠ hướng dẫn về các sự kiện Scrum là việc của SCRUM MASTER.

  • A (nhờ một thành viên đội liên hệ cập nhật cho họ) — ⚠ giải pháp tạm bợ, ⚠ và vẫn không cho họ xem được demo.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25750 ở lô 180 (sprint review là nơi trình diễn increment) và câu #25869 ở lô này (hỏi bên liên quan xem họ muốn dự họp không). ⚠ Ba câu cùng chủ đề: đưa đúng người tới đúng buổi họp.

⚠ Năm sự kiện Scrum — ai được dự: | Sự kiện | Ai dự | Mục đích | |---|---|---| | ⚠ Sprint Planning | ⚠ đội + PO + SM | ⚠ quyết làm gì trong sprint | | ⚠ Daily Scrum | ⚠ ĐỘI PHÁT TRIỂN | ⚠ đồng bộ 15 phút, gỡ trở ngại | | ⚠ Sprint Review | ⚠ đội + PO + SM + BÊN LIÊN QUAN | ⚠ trình diễn increment, lấy phản hồi — CÂU NÀY | | ⚠ Sprint Retrospective | ⚠ CHỈ đội + SM | ⚠ cải tiến cách làm việc | | ⚠ Bên liên quan | ⚠ CHỈ được mời tới sprint review |

Từ khoá nhận diện:

"bên liên quan muốn xem demo" → ⚠ sprint review "đồng bộ 15 phút mỗi ngày" → ⚠ daily standup, chỉ đội "nhìn lại cách làm việc" → ⚠ retrospective, chỉ đội "quyết làm gì sprint tới" → ⚠ sprint planning

⚠ Vì sao bên liên quan KHÔNG nên dự standup Lý do
⚠ Standup là để ĐỘI đồng bộ với nhau, không phải báo cáo lên trên
⚠ Có người ngoài, thành viên dễ báo cáo thay vì nói thật
⚠ Trở ngại và khó khăn dễ bị giấu
⚠ Buổi họp dễ kéo dài quá 15 phút
⚠ Nếu họ muốn dự ⚠ có thể cho quan sát nhưng KHÔNG phát biểu — và phải giải thích rõ quy tắc
⚠ Anna May nên nói gì với hai bên liên quan Cách
⚠ Cảm ơn sự quan tâm của họ tới dự án
⚠ Giải thích standup là buổi 15 phút của đội, không có demo
⚠ Mời họ tới SPRINT REVIEW — nơi có demo và có thời gian hỏi đáp
⚠ Gửi lịch sprint review định kỳ cho họ
⚠ Nếu họ cần cập nhật giữa kỳ: gợi ý kênh khác ⚠ bảng thông tin, báo cáo tóm tắt
⚠ Thái độ ⚠ HƯỚNG DẪN chứ không từ chối — họ đang quan tâm, đó là điều tốt
⚠ Bối cảnh tổ chức MỚI áp dụng agile Lưu ý
⚠ Bên liên quan chưa hiểu các sự kiện Scrum khác nhau thế nào
⚠ Đây là cơ hội GIÁO DỤC, không phải cơ hội để trách
⚠ Scrum Master có trách nhiệm giúp TỔ CHỨC hiểu Scrum ⚠ một trong ba trách nhiệm chính của vai trò
⚠ Vì thế ⚠ Anna May nên chủ động, không nên "không làm gì"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có biết lịch sprint review không | | | Standup của đội có bị biến thành buổi báo cáo không | | | Bạn có giải thích các sự kiện Scrum cho người ngoài đội không | |

Và cách xử lý đúng khi ai đó muốn tham gia sai chỗ: đừng từ chối, hãy chỉ đúng chỗ. Bên liên quan quan tâm là tài sản của dự án — chỉ cần hướng họ vào đúng kênh.

Câu 156 Process
Lola's company, Indy Tileworks, has been hired to install tile in the 793 rooms at the Speedway Hotel. All of the rooms are identical in design and will need the same amount of materials. Lola and her project team have finished the first three rooms, which took an average of five hours each to complete. Lola calculates the tile installation for each room at five hours. The labor cost for each room is calculated at $650 per room. Lola's project sponsor states that he disagrees with her labor estimate. Of the following choices, which best describes why Lola's project sponsor disagrees with her labor estimate?
  1. A Lola has not factored in all the effort applied to the work.
  2. B The learning curve has not been considered.
  3. C Because Lola has not completed one hotel room yet, she cannot know how long the work will truly take.
  4. D Lola has not considered the law of diminishing returns.
Xem giải thích

Đáp án

B — Chưa tính tới ĐƯỜNG CONG HỌC TẬP (learning curve).

Vì sao đúng

⚠ Vì sao đường cong học tập áp dụng ở đây: | Điều kiện | Có trong đề không | |---|---| | ⚠ Nhiều đơn vị GIỐNG HỆT NHAU | ⚠ 793 phòng thiết kế y hệt, cùng lượng vật tư | | ⚠ Cùng một đội làm lặp đi lặp lại | ⚠ CÓ | | ⚠ Mới làm được RẤT ÍT đơn vị | ⚠ mới 3 trên 793 phòng | | ⚠ Kết luận | ⚠ ba phòng đầu CHẮC CHẮN chậm hơn các phòng sau — lấy trung bình của chúng làm chuẩn cho cả 793 phòng là ƯỚC LƯỢNG THỪA |

⚠ Đường cong học tập là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Càng làm nhiều đơn vị giống nhau, thời gian mỗi đơn vị càng GIẢM | | | ⚠ Người làm thạo tay, quy trình được tối ưu, bớt sai sót | | | ⚠ Mức giảm mạnh nhất ở những đơn vị ĐẦU TIÊN | | | ⚠ Sau đó chững lại ở một mức ổn định | | | ⚠ Hệ quả với ước lượng | ⚠ ước lượng dựa trên vài đơn vị đầu sẽ cao hơn thực tế rất nhiều |

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

  • A (chưa tính hết công sức bỏ ra) — ⚠ đây là lỗi THIẾU, ⚠ trong khi vấn đề ở đây là ước lượng THỪA.

  • D (chưa tính quy luật lợi ích cận biên giảm dần) — ⚠ quy luật đó nói về việc THÊM nguồn lực mang lại lợi ích giảm dần; ⚠ không liên quan tới việc lặp lại công việc.

  • C (chưa làm xong phòng nào nên không thể biết) — ⚠ SAI về dữ kiện: ⚠ đề nói rõ đã hoàn thành BA phòng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25739 ở lô 180 (value engineering, trong đó learning curve là phương án nhiễu) và câu #25722 (bẫy của ước lượng tham số khi có nhiều đơn vị). ⚠ Ba câu cùng chủ đề — và câu này là lần đầu learning curve trở thành ĐÁP ÁN.

⚠ Phân biệt learning curve với value engineering: | Khái niệm | Nội dung | |---|---| | ⚠ Learning curve | ⚠ hiệu ứng TỰ NHIÊN — càng làm càng nhanh, không cần ai can thiệp | | ⚠ Value engineering | ⚠ NGHIÊN CỨU CHỦ ĐỘNG để tìm cách làm rẻ hơn và tốt hơn | | ⚠ Cả hai | ⚠ đều làm giảm chi phí đơn vị khi làm nhiều — nhưng một cái tự nhiên, một cái có chủ đích |

Từ khoá nhận diện:

"nhiều đơn vị giống nhau, mới làm vài cái đầu" → ⚠ learning curve "nghiên cứu để làm nhanh hơn rẻ hơn" → ⚠ value engineering "thêm nguồn lực nhưng lợi ích giảm dần" → ⚠ law of diminishing returns "đơn giá nhân số lượng" → ⚠ parametric — và đây là chỗ learning curve làm sai lệch kết quả

⚠ Lola nên ước lượng thế nào cho đúng Cách
⚠ Làm THÊM vài phòng nữa để thấy xu hướng ⚠ ba phòng là quá ít
⚠ Áp dụng hệ số đường cong học tập ⚠ ví dụ đường cong 90% — mỗi khi số lượng gấp đôi, thời gian đơn vị giảm 10%
⚠ Tham khảo DỮ LIỆU LỊCH SỬ của các dự án tương tự ⚠ tổ chức đã lát gạch nhiều lần thì phải có số liệu
⚠ Ước lượng theo NHÓM phòng thay vì đồng đều ⚠ 50 phòng đầu, 200 phòng giữa, phần còn lại
⚠ Nêu rõ GIẢ ĐỊNH trong ước lượng
⚠ Với 793 phòng ⚠ chênh lệch do learning curve có thể lên tới hàng chục phần trăm tổng chi phí nhân công

⚠ Ví dụ minh hoạ tác động: | Giả định | Kết quả | |---|---| | ⚠ Ước lượng thẳng: 793 × 650 | ⚠ = 515.450 | | ⚠ Nếu thời gian giảm dần và trung bình thực tế chỉ còn 4 giờ mỗi phòng | ⚠ chi phí nhân công giảm khoảng 20% | | ⚠ Nhận xét | ⚠ nhà tài trợ có lý khi cho rằng ước lượng quá cao |

⚠ Vì sao nhà tài trợ nhận ra điều này Lý do
⚠ Ông ấy có kinh nghiệm với các dự án lặp lại
⚠ Ba mẫu là quá ít để suy ra 793 đơn vị
⚠ Ước lượng quá cao làm dự án mất tính cạnh tranh khi báo giá
⚠ Bài học ⚠ phản đối của nhà tài trợ là góp ý chuyên môn có giá trị, không phải sự khó tính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công việc của bạn có tính LẶP LẠI cao không | ⚠ nếu có thì phải tính learning curve | | Bạn ước lượng dựa trên bao nhiêu mẫu | ⚠ vài mẫu đầu luôn chậm hơn thực tế | | Có dữ liệu lịch sử để đối chiếu không | |

Và cạm bẫy ước lượng kinh điển với công việc lặp lại: lấy trung bình của vài đơn vị đầu tiên nhân với tổng số. Với 793 phòng, sai lầm đó đủ để mất một hợp đồng vì báo giá quá cao.

Câu 157 Business Environment
Sean is the scrum master for Project E, which is beginning its first iteration. After the kickoff meeting, a stakeholder approaches Sean and tells him he is concerned his team will not benefit from Project E until the project is done. How is Sean most likely to respond?
  1. A Re-prioritize tasks so this stakeholder benefits sooner.
  2. B Agile projects deploy incremental benefits over each iteration.
  3. C Refer the stakeholder to the product owner.
  4. D The stakeholder is correct; the team will only benefit once the project is complete.
Xem giải thích

Đáp án

B — Dự án agile triển khai LỢI ÍCH TĂNG DẦN qua mỗi vòng lặp.

Vì sao đúng

⚠ Vì sao đây là câu trả lời đúng: | Lý do | Nội dung | |---|---| | ⚠ Agile giao phần sản phẩm DÙNG ĐƯỢC sau mỗi vòng lặp | | | ⚠ Bên liên quan nhận giá trị TỪ SỚM, không đợi tới cuối | | | ⚠ Đây là khác biệt CỐT LÕI so với cách tiếp cận dự đoán | | | ⚠ Trấn an đúng nỗi lo của bên liên quan | ⚠ họ sợ phải đợi tới hết dự án | | ⚠ Kết luận | ⚠ Sean giải thích một đặc tính THẬT của agile, không phải hứa suông |

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

  • D (bên liên quan nói đúng, chỉ được lợi khi dự án xong) — ⚠ mô tả cách tiếp cận DỰ ĐOÁN, ⚠ trái hẳn với agile.

  • A (sắp lại ưu tiên để bên liên quan này được lợi sớm hơn) — ⚠ hai vấn đề: ⚠ Sean là Scrum Master, ⚠ KHÔNG có quyền sắp lại backlog — đó là của product owner; ⚠ và hứa ưu tiên cho một bên liên quan mà chưa cân nhắc tổng thể là sai.

  • C (hướng bên liên quan sang product owner) — ⚠ đẩy trách nhiệm: ⚠ giải thích cách agile vận hành là việc của Scrum Master.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25842 ở lô này (đường cong giá trị của agile tăng dần, không dồn về cuối) và câu #25781 ở lô 180 (vòng đời tăng dần). ⚠ Ba câu cùng một nội dung nhìn từ ba góc: xu hướng, vòng đời, và cách giải thích cho bên liên quan.

⚠ So sánh đường cong giá trị: | Cách tiếp cận | Khi nào bên liên quan nhận được giá trị | |---|---| | ⚠ Dự đoán | ⚠ MỘT LẦN, ở CUỐI dự án khi bàn giao | | ⚠ Lặp (iterative) | ⚠ cũng ở cuối — vì các vòng lặp để TINH CHỈNH cùng một thứ | | ⚠ Tăng dần (incremental) | ⚠ NHIỀU LẦN, mỗi lần thêm chức năng dùng được | | ⚠ Agile | ⚠ kết hợp cả hai — giá trị tăng DẦN từ sớm |

Từ khoá nhận diện:

"lợi ích tăng dần qua từng vòng lặp" → ⚠ đặc trưng agile "chỉ được lợi khi dự án xong" → ⚠ cách tiếp cận dự đoán "sắp lại ưu tiên" → ⚠ quyền của PRODUCT OWNER, không phải Scrum Master "hướng sang người khác" → ⚠ đẩy trách nhiệm khi câu hỏi thuộc phạm vi của mình

⚠ Sean nên giải thích cụ thể thế nào Cách
⚠ Nêu rằng mỗi vòng lặp cho ra phần DÙNG ĐƯỢC
⚠ Mời bên liên quan tới SPRINT REVIEW để tự thấy ⚠ xem câu #25877 ở lô này
⚠ Giải thích BACKLOG được xếp ưu tiên theo giá trị ⚠ xem câu #25805 ở lô 181
⚠ Nói rõ họ có tiếng nói trong việc xếp ưu tiên qua product owner
⚠ Không hứa ⚠ rằng nhu cầu của riêng họ sẽ được ưu tiên trước — đó không phải quyền của Sean
⚠ Nỗi lo của bên liên quan có chính đáng không Đánh giá
⚠ CHÍNH ĐÁNG — nếu họ quen với cách tiếp cận dự đoán
⚠ Tổ chức đang bắt đầu dùng agile nên họ chưa quen
⚠ Đây là cơ hội GIÁO DỤC về cách agile vận hành
⚠ Thái độ đúng ⚠ giải thích, không gạt bỏ, cũng không hứa quá
⚠ Cạm bẫy cần tránh khi giải thích Cạm bẫy
⚠ Hứa rằng agile luôn nhanh hơn ⚠ KHÔNG đúng — agile giao GIÁ TRỊ sớm hơn, không nhất thiết xong sớm hơn
⚠ Hứa rằng chi phí sẽ thấp hơn ⚠ cũng không phải lời hứa của agile — xem câu #25805
⚠ Hứa ưu tiên cho một bên liên quan cụ thể
⚠ Nói đúng sự thật ⚠ giá trị đến DẦN, và thứ tự do product owner quyết dựa trên giá trị kinh doanh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi vòng lặp của bạn có tạo ra phần DÙNG ĐƯỢC không | ⚠ nếu không thì lời hứa này không thành sự thật | | Bên liên quan có thấy được kết quả mỗi vòng lặp không | | | Backlog có được xếp theo giá trị kinh doanh không | |

Và điều kiện để lời giải thích của Sean thành sự thật: increment mỗi vòng lặp phải THẬT SỰ dùng được. Nếu chỉ là phần việc dở dang thì lợi ích tăng dần chỉ là lý thuyết.

Câu 158 Process
Dave is a scrum master for the Digital Library Project. The project is eight iterations into its deployment and has recently had a wide variation in velocity. The project team is frustrated that they have not finished the sprint backlog as planned. During the retrospective, they discuss how the requirements are unclear, and they do not understand the size and effort of the project work. What should Dave do next?
  1. A Assign more people to fewer tasks.
  2. B Change the team's velocity.
  3. C Work with the team and product owner for better estimating.
  4. D Coach the team to choose fewer stories.
Xem giải thích

Đáp án

C — LÀM VIỆC VỚI ĐỘI và PRODUCT OWNER để ước lượng tốt hơn.

Vì sao đúng

⚠ Bóc tách nguyên nhân gốc: | Triệu chứng | Nguyên nhân đội tự nêu | |---|---| | ⚠ Velocity DAO ĐỘNG MẠNH qua 8 vòng lặp | ⚠ bình thường velocity ổn định sau 3–5 vòng | | ⚠ Không hoàn thành sprint backlog như kế hoạch | | | ⚠ Đội nói YÊU CẦU KHÔNG RÕ RÀNG | ⚠ nguyên nhân thứ nhất — thuộc product owner | | ⚠ Đội nói KHÔNG HIỂU quy mô và công sức của công việc | ⚠ nguyên nhân thứ hai — thuộc kỹ năng ước lượng | | ⚠ Kết luận | ⚠ cả hai nguyên nhân đều dẫn tới việc phải cải thiện QUY TRÌNH ƯỚC LƯỢNG, với sự tham gia của CẢ product owner |

⚠ Vì sao phải có CẢ product owner: | Lý do | Nội dung | |---|---| | ⚠ Yêu cầu không rõ là vấn đề của BACKLOG | ⚠ product owner sở hữu backlog | | ⚠ Product owner phải làm rõ hạng mục trước khi đội ước lượng | ⚠ backlog refinement | | ⚠ Ước lượng chỉ chính xác khi hiểu rõ yêu cầu | | | ⚠ Chỉ làm việc với đội | ⚠ không giải quyết được nguyên nhân yêu cầu mơ hồ |

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

  • D (huấn luyện đội chọn ít story hơn) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nhận ít việc hơn sẽ ⚠ giảm dao động velocity, ⚠ nhưng KHÔNG sửa nguyên nhân gốc — yêu cầu vẫn mơ hồ, ước lượng vẫn kém; ⚠ và nó làm giảm năng lực giao hàng.

  • B (thay đổi velocity của đội) — ⚠ VÔ NGHĨA: ⚠ velocity là số liệu ĐO ĐƯỢC, không phải con số đặt ra; ⚠ sửa nó là tự lừa mình.

  • A (phân nhiều người vào ít việc hơn) — ⚠ không giải quyết vấn đề ước lượng, ⚠ và thêm người vào một việc không phải lúc nào cũng nhanh hơn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25778 ở lô 180 (dùng velocity để kiểm chứng khối lượng sprint), câu #25818 ở lô 181 (throughput và định luật Little), và câu #25852 ở lô này (vòng phản hồi tạo cải tiến liên tục). ⚠ Bốn câu cùng chủ đề đo lường và cải tiến trong agile.

⚠ Vì sao velocity dao động mạnh là dấu hiệu xấu: | Nguyên nhân có thể | Nội dung | |---|---| | ⚠ Ước lượng KHÔNG NHẤT QUÁN | ⚠ cùng một mức công sức nhưng cho điểm khác nhau | | ⚠ Yêu cầu MƠ HỒ nên phát sinh việc ngoài dự kiến | ⚠ đúng điều đội nêu | | ⚠ Hạng mục QUÁ LỚN, không chia nhỏ được | | | ⚠ Nhiều việc bị chặn bởi phụ thuộc bên ngoài | | | ⚠ Thành viên thay đổi liên tục | | | ⚠ Sau 8 vòng lặp mà vẫn dao động | ⚠ chắc chắn có vấn đề hệ thống, không phải ngẫu nhiên |

Từ khoá nhận diện:

"yêu cầu không rõ, không hiểu quy mô công việc" → ⚠ cải thiện ước lượng CÙNG product owner "thay đổi velocity" → ⚠ vô nghĩa, velocity là số đo "chọn ít story hơn" → ⚠ giảm triệu chứng, không sửa gốc "thêm người" → ⚠ không liên quan tới vấn đề ước lượng

⚠ Các kỹ thuật cải thiện ước lượng Kỹ thuật
⚠ BACKLOG REFINEMENT thường xuyên ⚠ làm rõ hạng mục TRƯỚC khi đưa vào sprint planning
⚠ Planning poker ⚠ cả đội cùng ước lượng, thảo luận khi lệch nhau
⚠ Dùng hạng mục THAM CHIẾU ⚠ chọn một story làm mốc, so các story khác với nó
⚠ CHIA NHỎ hạng mục lớn ⚠ hạng mục nhỏ ước lượng chính xác hơn nhiều
⚠ Tiêu chí chấp nhận RÕ RÀNG cho mỗi story ⚠ giải quyết trực tiếp vấn đề "yêu cầu không rõ"
⚠ Định nghĩa READY — hạng mục đủ rõ mới được đưa vào sprint ⚠ giải pháp hiệu quả nhất cho tình huống này
⚠ Definition of Ready — công cụ Dave nên giới thiệu Nội dung
⚠ Bộ tiêu chí để một hạng mục ĐỦ RÕ để đưa vào sprint
⚠ Ví dụ: có mô tả rõ, có tiêu chí chấp nhận, đã được ước lượng, đủ nhỏ, không bị chặn
⚠ Ngăn việc nhận vào sprint những thứ chưa hiểu
⚠ Đối xứng với ⚠ Definition of Done — một cái ở đầu, một cái ở cuối
⚠ Vai trò của Dave trong việc này Vai trò
⚠ ĐIỀU PHỐI cuộc trao đổi giữa đội và product owner
⚠ HUẤN LUYỆN đội về kỹ thuật ước lượng
⚠ HUẤN LUYỆN product owner về việc làm rõ backlog ⚠ trách nhiệm chính thức của Scrum Master
⚠ Đề xuất buổi refinement định kỳ
⚠ Không làm ⚠ tự sửa velocity hoặc tự quyết đội nhận bao nhiêu việc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạng mục có được làm rõ TRƯỚC sprint planning không | | | Mỗi story có tiêu chí chấp nhận rõ không | | | Velocity của bạn có ổn định sau vài vòng lặp không | ⚠ dao động kéo dài là dấu hiệu vấn đề hệ thống |

Và nguyên nhân gốc mà đội đã tự chỉ ra: không thể ước lượng chính xác thứ mình chưa hiểu rõ. Sửa velocity hay nhận ít việc hơn đều chỉ che triệu chứng — phải làm rõ yêu cầu trước.

Câu 159 People
Alex is a project manager for Relia Info, Llc. He was recently put in charge of the PWD team. The PWD team has a history of completing projects by utilizing positional power to move their assigned tasks to the top of resources to-do lists. Alex does not want to upset the team's flow and decides to let the team continue getting things done utilizing positional power. What type of leadership style is Alex utilizing?
  1. A Charismatic
  2. B Laissez-faire
  3. C Transactional
  4. D Interactional
Xem giải thích

Đáp án

B — Laissez-faire (buông lỏng).

Vì sao đúng

⚠ Dấu hiệu laissez-faire trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Alex KHÔNG MUỐN làm gián đoạn cách làm của đội | | | ⚠ Alex QUYẾT ĐỊNH ĐỂ MẶC đội tiếp tục như cũ | ⚠ không can thiệp | | ⚠ Không định hướng, không điều chỉnh, không đặt chuẩn mực | | | ⚠ Kết luận | ⚠ đúng định nghĩa laissez-faire — người dẫn dắt không can thiệp, để đội tự xoay xở |

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

  • C (Transactional — giao dịch) — ⚠ là phong cách thưởng phạt theo kết quả; ⚠ Alex không thiết lập cơ chế thưởng phạt nào.

  • A (Charismatic — lôi cuốn) — ⚠ dựa vào sức hút cá nhân để truyền cảm hứng; ⚠ Alex không làm gì cả.

  • D (Interactional — tương tác) — ⚠ kết hợp nhiều phong cách tuỳ tình huống; ⚠ Alex chỉ áp dụng một cách duy nhất là không can thiệp.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này khác với hai câu trước về laissez-faire ở một điểm quan trọng. ⚠ Bảng đối chiếu: | Câu | Lô | Tình huống | Khoá | Đánh giá về hành vi | |---|---|---|---|---| | ⚠ #25588 | ⚠ 177 | ⚠ hỏi định nghĩa laissez-faire | ⚠ laissez-faire | ⚠ trung tính | | ⚠ #25732 | ⚠ 179 | ⚠ đội giỏi, ghét bị sai bảo, PM mới muốn được tôn trọng | ⚠ SERVANT LEADERSHIP | ⚠ laissez-faire là phương án SAI | | ⚠ #25881 | ⚠ 182 | ⚠ để mặc đội dùng quyền chức vụ chen ngang | ⚠ LAISSEZ-FAIRE | ⚠ đây là hành vi ĐÁNG LO | ⚠ Ba khoá đều đúng và không mâu thuẫn. ⚠ Điểm đáng chú ý: #25732 cho thấy laissez-faire là phương án SAI khi đội cần được dẫn dắt; câu này cho thấy Alex đang RƠI VÀO chính phong cách đó.

⚠ Vì sao hành vi của Alex đáng lo: | Lý do | Nội dung | |---|---| | ⚠ Đội dùng QUYỀN CHỨC VỤ để chen việc của mình lên đầu | ⚠ đây là hành vi có VẤN ĐỀ, không phải "cách làm hiệu quả" | | ⚠ Nó đẩy chi phí sang các đội khác | ⚠ việc của họ bị đẩy xuống | | ⚠ Gây tổn hại quan hệ trong tổ chức | | | ⚠ Không bền vững — người ta sẽ phản ứng lại | | | ⚠ Alex nhìn thấy nhưng không can thiệp | ⚠ đó chính là buông lỏng |

⚠ Phân biệt ba khái niệm rất dễ lẫn: | Phong cách | Mức tham gia | Có định hướng không | |---|---|---| | ⚠ SERVANT LEADERSHIP | ⚠ CHỦ ĐỘNG hỗ trợ, gỡ trở ngại | ⚠ CÓ — có giá trị và chuẩn mực rõ ràng | | ⚠ DELEGATING | ⚠ giao quyền có chủ đích cho đội trưởng thành | ⚠ CÓ — có ranh giới và theo dõi kết quả | | ⚠ LAISSEZ-FAIRE | ⚠ KHÔNG can thiệp | ⚠ KHÔNG — để mặc | | ⚠ Điểm giống | ⚠ cả ba đều không ra lệnh chi tiết — đó là chỗ dễ nhầm nhất |

Từ khoá nhận diện:

"để mặc, không muốn can thiệp" → ⚠ laissez-faire "chủ động hỗ trợ, gỡ trở ngại" → ⚠ servant leadership "thưởng phạt theo kết quả" → ⚠ transactional "truyền cảm hứng bằng tầm nhìn" → ⚠ transformational "sức hút cá nhân" → ⚠ charismatic

⚠ Alex nên làm gì thay vì buông lỏng Việc
⚠ TÌM HIỂU vì sao đội phải dùng quyền chức vụ để chen việc ⚠ có thể do quy trình phân bổ nguồn lực có vấn đề
⚠ Đánh giá tác động lên các đội khác
⚠ Trao đổi với các quản lý dự án khác ⚠ giao tiếp NGANG — xem câu #25847
⚠ Đề xuất cơ chế ưu tiên minh bạch ở cấp tổ chức
⚠ Nếu vượt thẩm quyền: leo thang lên PMO
⚠ Đừng ⚠ giữ nguyên chỉ vì "đang hiệu quả" — hiệu quả cho một đội, thiệt hại cho tổ chức
⚠ Khi nào laissez-faire lại HỢP LÝ Trường hợp
⚠ Đội RẤT trưởng thành và tự chủ hoàn toàn
⚠ Công việc sáng tạo cần tự do tuyệt đối
⚠ Người dẫn dắt thiếu chuyên môn hơn đội rất nhiều
⚠ Nhưng ngay cả khi đó ⚠ vẫn phải có mặt khi đội cần và vẫn phải đặt ranh giới đạo đức
⚠ Ở đây ⚠ KHÔNG hợp lý — vì hành vi của đội đang gây hại cho tổ chức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn không can thiệp vì TIN TƯỞNG hay vì NGẠI va chạm | ⚠ hai lý do rất khác nhau | | Cách làm hiệu quả của đội có gây hại cho ai không | | | Bạn có mặt khi đội cần không | ⚠ ranh giới giữa trao quyền và bỏ mặc |

Và ranh giới mỏng mà mọi người dẫn dắt phải giữ: không can thiệp vì tin tưởng là trao quyền; không can thiệp vì ngại va chạm là buông lỏng. Alex đang ở vế thứ hai.

Câu 160 People
Your project is wrapping up and is over budget. Most of the project was contracted out to LS Building, a reputable engineering consulting group. Your contract with them was a fixed-price incentive fee contract. The target cost for the project was $6,000,000. LS Building stipulated a target fee of $40,000. The contract's target price was initially $6,500,000. The contract's sharing ratio was 60% to the buyer and 40% to the seller, and the ceiling price was $7,000,000. Calculate the point of total assumption.
  1. A $6,833,333.33
  2. B $500,000.00
  3. C $7,250,000.00
  4. D $2,800,000.00
Xem giải thích

Đáp án

A — 6.833.333,33.

Vì sao đúng

⚠ Công thức PTA — Point of Total Assumption:

⚠ PTA = ((Giá TRẦN − Giá MỤC TIÊU) / Tỷ lệ chia của NGƯỜI MUA) + Chi phí MỤC TIÊU

⚠ Thay số: | Bước | Phép tính | |---|---| | ⚠ Giá trần (ceiling price) | ⚠ 7.000.000 | | ⚠ Giá mục tiêu (target price) | ⚠ 6.500.000 | | ⚠ Hiệu | ⚠ 7.000.000 − 6.500.000 = 500.000 | | ⚠ Tỷ lệ chia của NGƯỜI MUA | ⚠ 60% = 0,60 | | ⚠ Chia | ⚠ 500.000 / 0,60 = 833.333,33 | | ⚠ Cộng chi phí mục tiêu | ⚠ 833.333,33 + 6.000.000 = 6.833.333,33 |

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

  • B (500.000) — ⚠ chỉ là HIỆU giữa giá trần và giá mục tiêu, ⚠ mới xong bước một.

  • C (7.250.000) — ⚠ không khớp phép tính nào; ⚠ và PTA phải NHỎ HƠN giá trần trong trường hợp này.

  • D (2.800.000) — ⚠ không khớp phép tính nào.

Ghi nhớ

⚠ PTA nghĩa là gì: | Điều | Nội dung | |---|---| | ⚠ Là mức CHI PHÍ THỰC TẾ mà từ đó NHÀ CUNG CẤP chịu 100% phần vượt | | | ⚠ Dưới PTA: chi phí vượt được CHIA theo tỷ lệ đã thoả thuận | ⚠ 60/40 ở bài này | | ⚠ Trên PTA: nhà cung cấp gánh TOÀN BỘ | ⚠ vì người mua đã chạm giá trần | | ⚠ Chỉ áp dụng với hợp đồng FPIF | ⚠ Fixed Price Incentive Fee | | ⚠ Ý nghĩa với người mua | ⚠ PTA càng thấp thì người mua càng được bảo vệ sớm |

⚠ Các thuật ngữ trong hợp đồng FPIF: | Thuật ngữ | Trong bài này | |---|---| | ⚠ Target cost — chi phí mục tiêu | ⚠ 6.000.000 — chi phí dự kiến của nhà cung cấp | | ⚠ Target fee — phí mục tiêu | ⚠ 40.000 — lợi nhuận dự kiến | | ⚠ Target price — giá mục tiêu | ⚠ 6.500.000 — lưu ý: KHÔNG bằng 6.000.000 + 40.000 | | ⚠ Ceiling price — giá trần | ⚠ 7.000.000 — mức tối đa người mua trả | | ⚠ Sharing ratio — tỷ lệ chia | ⚠ 60% người mua / 40% nhà cung cấp | | ⚠ Lưu ý | ⚠ đề cho target price riêng, không cần tự tính từ target cost + target fee |

⚠ Ví dụ minh hoạ cách chia phần vượt: | Tình huống | Ai trả | |---|---| | ⚠ Chi phí thực tế = 6.000.000 | ⚠ đúng mục tiêu, nhà cung cấp nhận đủ phí 40.000 | | ⚠ Chi phí thực tế = 6.500.000 | ⚠ vượt 500.000; người mua chịu 60% = 300.000, nhà cung cấp chịu 40% = 200.000 trừ vào phí | | ⚠ Chi phí thực tế = 6.833.333 | ⚠ ĐÚNG PTA — người mua đã trả tới giá trần 7.000.000 | | ⚠ Chi phí thực tế > 6.833.333 | ⚠ nhà cung cấp gánh 100% phần vượt |

Từ khoá nhận diện:

"point of total assumption" → ⚠ (trần − mục tiêu) / tỷ lệ người mua + chi phí mục tiêu "sharing ratio 60/40" → ⚠ số ĐẦU là của NGƯỜI MUA "ceiling price" → ⚠ mức tối đa người mua trả "chỉ có ở hợp đồng nào" → ⚠ FPIF

⚠ Mẹo nhớ công thức Mẹo
⚠ Bắt đầu từ CHÊNH LỆCH giữa trần và mục tiêu ⚠ phần đệm mà người mua còn chấp nhận trả
⚠ Chia cho TỶ LỆ NGƯỜI MUA ⚠ vì người mua chỉ chịu phần đó của mỗi đồng vượt
⚠ Cộng CHI PHÍ mục tiêu ⚠ để ra mức chi phí tuyệt đối
⚠ Lỗi hay gặp ⚠ chia nhầm cho tỷ lệ của NHÀ CUNG CẤP (40%) — sẽ ra 7.250.000, chính là phương án C

⚠ Phát hiện đáng chú ý: ⚠ phương án C (7.250.000) chính là kết quả khi CHIA NHẦM cho 40% thay vì 60% — ⚠ 500.000 / 0,40 = 1.250.000, cộng 6.000.000 = 7.250.000. ⚠ Đây là bẫy được cài rất có chủ đích.

⚠ Kiểm tra kết quả cho hợp lý Kiểm tra
⚠ PTA phải LỚN HƠN chi phí mục tiêu ⚠ 6.833.333 > 6.000.000 ✓
⚠ PTA thường NHỎ HƠN giá trần ⚠ 6.833.333 < 7.000.000 ✓
⚠ Nếu kết quả vượt giá trần ⚠ chắc chắn đã chia nhầm tỷ lệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn dùng tỷ lệ của người MUA hay của nhà CUNG CẤP | ⚠ phải là người MUA | | Kết quả có nằm giữa chi phí mục tiêu và giá trần không | | | Đề cho target price hay bạn phải tự tính | ⚠ có đề cho sẵn, có đề bắt tính từ target cost + target fee |

Và ý nghĩa thực tế của con số này với dự án đang vượt ngân sách: biết PTA là biết chính xác từ mức nào trở đi mình không phải trả thêm nữa. Đó là lằn ranh bảo vệ mà hợp đồng FPIF mang lại cho người mua.