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

Tìm thấy 720 câu.

Câu 181 Process
Kimberly is a scrum master and has noted that her team had completed 20 story points in the last sprint when the average for several prior sprints was 40 points. Kimberly should first
  1. A Reduce the velocity expected for the next sprint.
  2. B Assume that this is an occasional variation attributed to a common cause.
  3. C Leave this to the team to resolve, as the team is self-organizing.
  4. D Investigate this discrepancy, as it is a wide variation from normal.
Xem giải thích

Đáp án

D — ĐIỀU TRA sự chênh lệch này, vì đây là mức dao động RẤT LỚN so với bình thường.

Vì sao đúng

⚠ Vì sao phải điều tra: | Lý do | Nội dung | |---|---| | ⚠ Velocity tụt từ trung bình 40 xuống 20 — GIẢM MỘT NỬA | | | ⚠ Đây KHÔNG phải dao động thông thường | ⚠ dao động bình thường quanh 10–15% | | ⚠ Mức lệch lớn như vậy luôn có NGUYÊN NHÂN XÁC ĐỊNH | ⚠ special cause, không phải common cause | | ⚠ Không tìm nguyên nhân thì không sửa được | | | ⚠ Kết luận | ⚠ thu thập thông tin trước, hành động sau — nguyên tắc lặp lại ở gần như mọi câu tình huống |

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

  • B (coi đây là dao động ngẫu nhiên do nguyên nhân thông thường) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ khái niệm ⚠ common cause (nguyên nhân thông thường) là có thật, ⚠ nhưng giảm MỘT NỬA thì vượt xa dao động ngẫu nhiên — ⚠ đây là ⚠ SPECIAL CAUSE cần điều tra.

  • A (giảm velocity kỳ vọng cho sprint tới) — ⚠ HÀNH ĐỘNG khi chưa biết nguyên nhân; ⚠ nếu nguyên nhân là tạm thời thì giảm kỳ vọng là sai.

  • C (để đội tự giải quyết vì đội tự tổ chức) — ⚠ hiểu SAI về tự tổ chức: ⚠ Scrum Master có trách nhiệm ⚠ GỠ TRỞ NGẠI; ⚠ tự tổ chức không có nghĩa là bỏ mặc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25880 ở lô 182 (velocity dao động vì yêu cầu không rõ và ước lượng kém) và câu #25778 ở lô 180 (dùng velocity kiểm chứng khối lượng sprint). ⚠ Ba câu cùng chủ đề — câu này ở bước ĐIỀU TRA, câu #25880 ở bước đã biết nguyên nhân.

⚠ Common cause và special cause — khái niệm từ kiểm soát chất lượng: | Loại | Nghĩa | Cách xử lý | |---|---|---| | ⚠ COMMON CAUSE | ⚠ dao động NGẪU NHIÊN vốn có của quy trình | ⚠ muốn giảm thì phải THAY ĐỔI QUY TRÌNH | | ⚠ SPECIAL CAUSE | ⚠ nguyên nhân XÁC ĐỊNH, bất thường | ⚠ ĐIỀU TRA và loại bỏ nguyên nhân cụ thể | | ⚠ Sai lầm hai chiều | ⚠ coi special cause là ngẫu nhiên → bỏ lỡ vấn đề; coi common cause là bất thường → can thiệp thừa | | ⚠ Ở đây | ⚠ giảm 50% chắc chắn là SPECIAL CAUSE |

Từ khoá nhận diện:

"lệch rất xa mức bình thường" → ⚠ special cause, phải điều tra "dao động nhỏ quanh mức trung bình" → ⚠ common cause, chấp nhận được "để đội tự giải quyết" → ⚠ hiểu sai về tự tổ chức — SM vẫn phải gỡ trở ngại "giảm kỳ vọng" → ⚠ hành động khi chưa biết nguyên nhân

⚠ Nguyên nhân có thể của việc velocity giảm một nửa Nguyên nhân
⚠ Thành viên NGHỈ hoặc bị điều sang việc khác
⚠ Có trở ngại lớn chặn đội ⚠ môi trường hỏng, chờ phê duyệt, chờ bên thứ ba
⚠ Hạng mục sprint này KHÓ hơn nhiều so với ước lượng
⚠ Nợ kỹ thuật tích tụ khiến mọi việc chậm lại
⚠ Sprint có ngày lễ hoặc đào tạo
⚠ Đội phải xử lý sự cố sản xuất
⚠ Mỗi nguyên nhân ⚠ cần một cách xử lý hoàn toàn khác — nên phải điều tra
⚠ Kimberly nên điều tra thế nào Cách
⚠ Đưa vào RETROSPECTIVE để cả đội cùng nhìn lại ⚠ không phải thẩm vấn từng người
⚠ Mang DỮ LIỆU ra bàn, không mang kết luận ⚠ xem câu #25778 ở lô 180
⚠ Hỏi mở: "điều gì khác biệt trong sprint này?"
⚠ Xem lại sổ vấn đề và các trở ngại đã ghi
⚠ Kiểm tra có ai vắng mặt hoặc bị điều đi không
⚠ Thái độ ⚠ tìm nguyên nhân HỆ THỐNG, không tìm người để trách
⚠ Sau khi biết nguyên nhân thì làm gì Tuỳ nguyên nhân
⚠ Nếu là trở ngại: GỠ nó ⚠ việc chính của Scrum Master
⚠ Nếu là thiếu người: xin bổ sung hoặc điều chỉnh cam kết
⚠ Nếu là ước lượng kém: cải thiện quy trình ước lượng ⚠ lúc này giống câu #25880
⚠ Nếu là nợ kỹ thuật: dành phần sprint để trả nợ
⚠ Nếu là sự kiện một lần: không cần đổi gì ⚠ lúc này phương án B mới đúng
⚠ Nhận xét ⚠ phương án A và B đều có thể ĐÚNG — nhưng chỉ SAU khi điều tra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức dao động này có nằm trong biên độ bình thường không | ⚠ so với các sprint trước | | Có sự kiện bất thường nào trong sprint này không | | | Trở ngại đã ghi trong sổ có được xử lý không | |

Và nguyên tắc phân biệt cần thuộc từ kiểm soát chất lượng: dao động nhỏ là bản chất của quy trình, dao động lớn là tín hiệu. Giảm một nửa là tín hiệu rất rõ.

Câu 182 Process
Mary has recently joined a team that has been using scrum in the project. Being new, Mary consults Tom, the scrum master, who explains the benefits of iterative delivery of value and timeboxing each ceremony. Which of the following best describes timeboxing?
  1. A Working with a fixed time schedule for planned activities
  2. B Working with a team in a boxed-shaped cubicle
  3. C Allowing flexibility of scope after an agreed sprint goal
  4. D Flexibility to expand time to complete as many activities as possible
Xem giải thích

Đáp án

A — Làm việc với một LỊCH THỜI GIAN CỐ ĐỊNH cho các hoạt động đã định.

Vì sao đúng

⚠ Timeboxing là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Ấn định một KHUNG THỜI GIAN CỐ ĐỊNH cho một hoạt động | | | ⚠ Khi hết giờ thì DỪNG, bất kể xong hay chưa | | | ⚠ Thời gian là RÀNG BUỘC CỐ ĐỊNH, phạm vi mới là thứ điều chỉnh | | | ⚠ Áp dụng cho cả SPRINT lẫn từng SỰ KIỆN | | | ⚠ Kết luận | ⚠ thời gian cố định, khối lượng linh hoạt — ngược với cách tiếp cận truyền thống |

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

  • D (linh hoạt kéo dài thời gian để hoàn thành càng nhiều hoạt động càng tốt) — ⚠ NGƯỢC HẲN: ⚠ timeboxing giữ thời gian CỐ ĐỊNH, không kéo dài.

  • C (cho phép linh hoạt về phạm vi sau khi đã thống nhất sprint goal) — ⚠ mô tả một khía cạnh của agile nhưng KHÔNG phải định nghĩa timeboxing; ⚠ và phạm vi trong sprint không được đổi tuỳ tiện sau khi đã cam kết.

  • B (làm việc trong ô làm việc hình hộp) — ⚠ hiểu sai chữ "box" theo nghĩa đen; ⚠ phương án đùa.

Ghi nhớ

⚠ Timebox của các sự kiện Scrum: | Sự kiện | Timebox tối đa cho sprint MỘT THÁNG | |---|---| | ⚠ Sprint | ⚠ tối đa 1 tháng | | ⚠ Sprint Planning | ⚠ 8 giờ | | ⚠ Daily Scrum | ⚠ 15 phút | | ⚠ Sprint Review | ⚠ 4 giờ | | ⚠ Sprint Retrospective | ⚠ 3 giờ | | ⚠ Sprint ngắn hơn | ⚠ các timebox giảm tương ứng |

⚠ Vì sao timeboxing hiệu quả: | Lý do | Nội dung | |---|---| | ⚠ Ép TẬP TRUNG vào điều quan trọng nhất | ⚠ biết có giới hạn thì không lan man | | ⚠ Chống định luật PARKINSON | ⚠ công việc nở ra lấp đầy thời gian được cấp — xem câu #25669 ở lô 179 | | ⚠ Tạo NHỊP ĐỘ đều đặn và dự báo được | | | ⚠ Buộc phải ưu tiên và ra quyết định | | | ⚠ Giới hạn tổn thất nếu hướng đi sai | ⚠ sai thì chỉ mất một sprint | | ⚠ Nguyên tắc nền | ⚠ THỜI GIAN cố định, PHẠM VI linh hoạt |

Từ khoá nhận diện:

"khung thời gian cố định, hết giờ thì dừng" → ⚠ timeboxing "kéo dài để làm cho xong" → ⚠ NGƯỢC với timeboxing "phạm vi cố định, thời gian linh hoạt" → ⚠ cách tiếp cận DỰ ĐOÁN "thời gian cố định, phạm vi linh hoạt" → ⚠ cách tiếp cận AGILE

⚠ So sánh hai triết lý: | Mục | Dự đoán | Agile | |---|---|---| | ⚠ Phạm vi | ⚠ CỐ ĐỊNH | ⚠ linh hoạt | | ⚠ Thời gian và chi phí | ⚠ ước lượng, có thể đổi | ⚠ CỐ ĐỊNH | | ⚠ Cách xử lý khi không kịp | ⚠ xin thêm thời gian hoặc tiền | ⚠ giảm phạm vi trong sprint đó | | ⚠ Gọi là | ⚠ "tam giác ngược" của agile |

⚠ Timeboxing áp dụng cho hoạt động nào ngoài Scrum Áp dụng
⚠ Buổi họp thông thường ⚠ đặt giờ kết thúc và giữ đúng
⚠ SPIKE — nghiên cứu kỹ thuật ⚠ cho tối đa 2 ngày để tìm hiểu, hết giờ thì báo cáo những gì đã biết
⚠ Thảo luận trong họp ⚠ quá giờ thì chuyển sang bàn riêng
⚠ Lợi ích chung ⚠ ngăn việc một chủ đề chiếm hết thời gian của mọi chủ đề khác
⚠ Điều timeboxing KHÔNG có nghĩa là Đính chính
⚠ "Làm ẩu cho kịp giờ" ⚠ SAI — chất lượng vẫn phải đạt Definition of Done
⚠ "Không được kết thúc sớm" ⚠ SAI — xong sớm thì dừng sớm
⚠ "Việc dở dang thì bỏ đi" ⚠ việc chưa xong quay lại backlog
⚠ Đúng ⚠ giảm PHẠM VI, không giảm CHẤT LƯỢNG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các buổi họp của bạn có kết thúc đúng giờ không | | | Khi không kịp, bạn giảm phạm vi hay kéo dài thời gian | | | Việc chưa xong có quay lại backlog không | |

Và điều timeboxing thật sự dạy: giới hạn thời gian buộc người ta phải chọn cái quan trọng nhất. Không có giới hạn thì mọi thứ đều có vẻ quan trọng như nhau.

Câu 183 Process
Erica is the scrum master for a project at Bottle Corporation. Several stakeholders point out that a recent deployment is no longer necessary to the project during a sprint review. What should Erica do next?
  1. A Ignore the stakeholders and continue the meeting.
  2. B Refer the stakeholders to the product owner.
  3. C Refer the stakeholders to the project’s information radiators.
  4. D Ask the stakeholders to submit new story ideas to the project’s backlog.
Xem giải thích

Đáp án

D — Đề nghị các bên liên quan NỘP Ý TƯỞNG HẠNG MỤC MỚI vào backlog của dự án.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Sprint review CHÍNH LÀ nơi thu phản hồi từ bên liên quan | ⚠ họ đang làm đúng việc ở đúng chỗ | | ⚠ Backlog là nơi mọi thay đổi phạm vi đi vào | ⚠ cơ chế chính thức của agile | | ⚠ Product owner sẽ đánh giá và xếp ưu tiên | | | ⚠ Ghi nhận phản hồi thay vì gạt bỏ | | | ⚠ Kết luận | ⚠ hướng phản hồi vào đúng kênh chính thức — đó là việc của Scrum Master |

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

  • B (hướng bên liên quan sang product owner) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ product owner ĐANG CÓ MẶT ở sprint review, ⚠ và cách chuẩn là NỘP VÀO BACKLOG chứ không phải đi tìm một người; ⚠ nộp vào backlog để lại DẤU VẾT, nói miệng thì không.

  • A (phớt lờ và tiếp tục buổi họp) — ⚠ gạt bỏ phản hồi, ⚠ đi ngược mục đích của sprint review.

  • C (hướng họ tới các bảng thông tin của dự án) — ⚠ bảng thông tin để XEM trạng thái, ⚠ không phải nơi nộp ý tưởng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25877 ở lô 182 (mời bên liên quan tới sprint review để xem demo) và câu #25889 ở lô này (product owner xếp backlog theo giá trị kinh doanh). ⚠ Ba câu vẽ đủ chuỗi: mời bên liên quan tới đúng buổi → thu phản hồi → đưa vào backlog → xếp ưu tiên.

⚠ Vì sao "bàn giao không còn cần thiết" là phản hồi QUÝ: | Lý do | Nội dung | |---|---| | ⚠ Nhu cầu kinh doanh THAY ĐỔI theo thời gian | | | ⚠ Làm tiếp thứ không ai cần là LÃNG PHÍ thuần tuý | | | ⚠ Phát hiện sớm giúp chuyển nguồn lực sang việc có giá trị | | | ⚠ Đây chính là lợi ích của việc lấy phản hồi thường xuyên | ⚠ xem câu #25852 ở lô 182 về vòng phản hồi | | ⚠ Trong dự án dự đoán | ⚠ có thể phải tới cuối dự án mới phát hiện — lúc đó đã tiêu hết tiền |

Từ khoá nhận diện:

"bên liên quan nêu thay đổi ở sprint review" → ⚠ đưa vào backlog "phớt lờ và tiếp tục" → ⚠ luôn là đáp án sai "hướng sang người khác" → ⚠ thường là né trách nhiệm "bảng thông tin" → ⚠ nơi XEM, không phải nơi NỘP

⚠ Erica nên làm gì đầy đủ Bước
⚠ 1. GHI NHẬN phản hồi ngay trong buổi họp
⚠ 2. Đề nghị họ nộp thành hạng mục backlog ⚠ bước của câu này
⚠ 3. Đảm bảo product owner nắm được thông tin ⚠ PO đang có mặt
⚠ 4. Nếu bàn giao đó ĐANG trong sprint: bàn với đội và PO ⚠ có nên dừng ngay không
⚠ 5. Cập nhật backlog theo quyết định của PO
⚠ Lưu ý ⚠ hạng mục "loại bỏ một tính năng" cũng là một hạng mục backlog hợp lệ
⚠ Vì sao nộp vào backlog tốt hơn nói miệng Lý do
⚠ Để lại DẤU VẾT — ai đề xuất, khi nào, vì sao
⚠ Được ĐÁNH GIÁ có hệ thống cùng các hạng mục khác
⚠ Minh bạch — cả đội và bên liên quan đều thấy
⚠ Không bị quên
⚠ Nói miệng ⚠ dễ bị hiểu nhầm và dễ rơi mất
⚠ Vai trò của Scrum Master ở đây Vai trò
⚠ ĐIỀU PHỐI buổi họp, đảm bảo phản hồi được ghi nhận
⚠ HƯỚNG DẪN bên liên quan về cơ chế chính thức ⚠ đặc biệt quan trọng nếu tổ chức mới dùng agile
⚠ KHÔNG tự quyết đưa hay không đưa vào backlog ⚠ đó là quyền của product owner
⚠ KHÔNG gạt bỏ phản hồi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phản hồi ở sprint review có được ghi lại không | | | Bên liên quan có biết cách nộp ý tưởng vào backlog không | | | Có hạng mục nào đang làm mà không còn cần thiết không | ⚠ câu hỏi đáng đặt định kỳ |

Và điều làm nên giá trị của sprint review: nó là cơ hội để phát hiện rằng mình đang làm thứ không còn ai cần. Bên liên quan nêu điều đó là đang giúp dự án, không phải đang gây rối.

Câu 184 Process
Of the following, which best describes a project sponsor's role in a functional organization during project execution activities?
  1. A Assisting the project manager and stakeholders in resolving issues ASAP.
  2. B Deflecting change requests on behalf of the project manager.
  3. C Presenting project progress and status reports to management
  4. D Acting as a sounding board for project stakeholders.
Xem giải thích

Đáp án

A — HỖ TRỢ quản lý dự án và các bên liên quan GIẢI QUYẾT VẤN ĐỀ NHANH NHẤT có thể.

Vì sao đúng

⚠ Vai trò của nhà tài trợ trong giai đoạn THỰC HIỆN: | Vai trò | Nội dung | |---|---| | ⚠ GỠ VƯỚNG vượt thẩm quyền của PM | ⚠ đặc biệt quan trọng trong cơ cấu CHỨC NĂNG khi PM có rất ít quyền | | ⚠ Cấp NGUỒN LỰC khi cần | | | ⚠ Ra quyết định trong phạm vi thẩm quyền của mình | | | ⚠ Bảo vệ dự án trước các ưu tiên cạnh tranh | | | ⚠ Phê duyệt thay đổi lớn | | | ⚠ Trong cơ cấu CHỨC NĂNG | ⚠ vai trò này càng quan trọng vì PM gần như không có quyền gì |

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

  • C (trình bày tiến độ và báo cáo trạng thái cho ban lãnh đạo) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ báo cáo trạng thái là việc của ⚠ QUẢN LÝ DỰ ÁN, ⚠ không phải của nhà tài trợ; ⚠ nhà tài trợ NHẬN báo cáo, không soạn báo cáo.

  • B (chặn các yêu cầu thay đổi thay cho quản lý dự án) — ⚠ SAI về vai trò: ⚠ nhà tài trợ ⚠ PHÊ DUYỆT hoặc TỪ CHỐI thay đổi qua quy trình, ⚠ không "chặn" giúp PM né tránh.

  • D (làm người để bên liên quan trút bầu tâm sự) — ⚠ quá thụ động; ⚠ nhà tài trợ có vai trò CHỦ ĐỘNG hơn nhiều.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25638 ở lô 178 (nhà tài trợ sở hữu business case), câu #25691 ở lô 179 (không có điều lệ nên quản lý chức năng không nhả người), và câu #25855 ở lô 182 (ma trận yếu, quản lý chức năng duyệt lịch). ⚠ Bốn câu cùng chủ đề thẩm quyền và vai trò trong tổ chức.

⚠ Vai trò của nhà tài trợ theo từng giai đoạn: | Giai đoạn | Vai trò | |---|---| | ⚠ KHỞI TẠO | ⚠ sở hữu business case, BAN HÀNH điều lệ, bổ nhiệm PM, cấp nguồn lực ban đầu | | ⚠ LẬP KẾ HOẠCH | ⚠ phê duyệt kế hoạch và đường cơ sở, cam kết nguồn lực | | ⚠ THỰC HIỆN | ⚠ GỠ VƯỚNG, cấp nguồn lực, bảo vệ dự án — CÂU NÀY | | ⚠ GIÁM SÁT VÀ KIỂM SOÁT | ⚠ phê duyệt thay đổi lớn, quyết định tiếp tục hay dừng | | ⚠ KẾT THÚC | ⚠ chấp nhận bàn giao cuối, theo dõi lợi ích sau dự án | | ⚠ Xuyên suốt | ⚠ là tiếng nói của dự án ở cấp lãnh đạo |

Từ khoá nhận diện:

"gỡ vướng, hỗ trợ giải quyết vấn đề" → ⚠ nhà tài trợ trong giai đoạn thực hiện "soạn và trình bày báo cáo trạng thái" → ⚠ quản lý dự án "phê duyệt thay đổi lớn" → ⚠ nhà tài trợ hoặc CCB "chặn thay đổi giúp PM" → ⚠ hiểu sai vai trò

⚠ Vì sao cơ cấu CHỨC NĂNG làm vai trò này càng quan trọng Lý do
⚠ PM có quyền RẤT ÍT trong cơ cấu chức năng
⚠ Nguồn lực do các quản lý chức năng kiểm soát
⚠ PM không thể tự gỡ vướng liên phòng ban
⚠ Nhà tài trợ là người DUY NHẤT có thẩm quyền để can thiệp
⚠ Không có nhà tài trợ tích cực ⚠ dự án trong cơ cấu chức năng gần như chắc chắn gặp khó
⚠ Vấn đề PM cần leo thang lên nhà tài trợ Loại vấn đề
⚠ Tranh chấp nguồn lực giữa các phòng ban
⚠ Bên liên quan cấp cao phản đối dự án ⚠ xem câu #25702 ở lô 179
⚠ Quyết định vượt thẩm quyền tài chính của PM
⚠ Xung đột ưu tiên với dự án khác ⚠ rủi ro hệ thống — xem câu #25892 ở lô này
⚠ Rủi ro ở mức tổ chức ⚠ chiến lược ESCALATE
⚠ Nguyên tắc ⚠ leo thang khi VƯỢT THẨM QUYỀN, không leo thang để né trách nhiệm
⚠ Làm sao để có nhà tài trợ tích cực Cách
⚠ Làm rõ KỲ VỌNG về vai trò của họ ngay từ đầu
⚠ Báo cáo ĐỀU ĐẶN, không chỉ khi có sự cố
⚠ Khi cần giúp thì nêu VẤN ĐỀ CỤ THỂ và ĐỀ XUẤT phương án ⚠ không mang vấn đề trống tới
⚠ Ghi nhận khi họ đã giúp
⚠ Sai lầm ⚠ chỉ tìm nhà tài trợ khi mọi thứ đã hỏng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhà tài trợ của bạn có biết mình cần làm gì không | ⚠ nhiều người nhận vai trò mà không rõ trách nhiệm | | Bạn có kênh liên hệ trực tiếp với họ không | | | Bạn mang vấn đề hay mang phương án tới họ | |

Và giá trị lớn nhất một nhà tài trợ mang lại trong giai đoạn thực hiện: họ mở được những cánh cửa mà quản lý dự án không mở được. Trong cơ cấu chức năng, đó thường là điều quyết định dự án thành hay bại.

Câu 185 Process
You are trying to determine whether you should make or buy a piece of software. If you create the software, it will cost your organization $45,000 to create it and $3,400 each month to support it. A vendor, however, can create the software for $12,000 and will charge you $0.17 per transaction per month. According to your calculations, you will have 31,400 transactions each month. What should you do?
  1. A Hire the vendor if the transactions will be less than 30,000 per month.
  2. B Hire the vendor if the software will be replaced within 17 months.
  3. C Make the software and reduce your monthly expenses by paying the vendor for the transactions.
  4. D Hire the vendor if the software will be kept longer than 17 months.
Xem giải thích

Đáp án

B — Thuê nhà cung cấp NẾU phần mềm sẽ được thay thế TRONG VÒNG 17 THÁNG.

Vì sao đúng

⚠ Phép tính make-or-buy: | Khoản | Tự làm | Thuê ngoài | |---|---|---| | ⚠ Chi phí ban đầu | ⚠ 45.000 | ⚠ 12.000 | | ⚠ Chi phí hằng tháng | ⚠ 3.400 | ⚠ 0,17 × 31.400 = 5.338 | | ⚠ Chênh lệch ban đầu | ⚠ thuê ngoài rẻ hơn 33.000 | | | ⚠ Chênh lệch hằng tháng | ⚠ thuê ngoài đắt hơn 1.938 mỗi tháng | | | ⚠ ĐIỂM HOÀ VỐN | ⚠ 33.000 ÷ 1.938 = 17,03 tháng | |

⚠ Đọc kết quả: | Thời gian dùng | Nên chọn | |---|---| | ⚠ DƯỚI 17 tháng | ⚠ THUÊ NGOÀI — chưa kịp bù hết khoản tiết kiệm ban đầu | | ⚠ TRÊN 17 tháng | ⚠ TỰ LÀM — chi phí tháng thấp hơn bù lại đầu tư ban đầu | | ⚠ Đúng 17 tháng | ⚠ hai bên xấp xỉ bằng nhau |

⚠ Đề nói "được THAY THẾ trong vòng 17 tháng" tức là chỉ dùng dưới 17 tháng → thuê ngoài. Đúng.

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

  • D (thuê nhà cung cấp nếu giữ LÂU HƠN 17 tháng) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ĐẢO NGƯỢC kết luận; ⚠ giữ lâu hơn 17 tháng thì phải TỰ LÀM.

  • A (thuê nếu giao dịch dưới 30.000/tháng) — ⚠ đề đã cho con số 31.400, ⚠ không phải biến số; ⚠ và ngưỡng hoà vốn theo giao dịch không phải 30.000.

  • C (tự làm và giảm chi phí bằng cách trả cho nhà cung cấp theo giao dịch) — ⚠ mâu thuẫn tự thân: ⚠ tự làm thì không trả theo giao dịch.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25887 ở lô này (rà soát hợp đồng nhà cung cấp), câu #25733 và #25765 ở lô 180 (hợp đồng T&M), và câu #25882 ở lô 182 (PTA của FPIF). ⚠ Cả nhóm cùng chủ đề mua sắm.

⚠ Công thức điểm hoà vốn make-or-buy: | Thành phần | Công thức | |---|---| | ⚠ Chênh lệch chi phí BAN ĐẦU | ⚠ (chi phí tự làm − chi phí thuê) | | ⚠ Chênh lệch chi phí ĐỊNH KỲ | ⚠ (chi phí tháng thuê − chi phí tháng tự làm) | | ⚠ Số tháng hoà vốn | ⚠ chênh ban đầu ÷ chênh định kỳ | | ⚠ Ở câu này | ⚠ 33.000 ÷ 1.938 ≈ 17 | | ⚠ Lưu ý | ⚠ luôn kiểm CHIỀU của bất đẳng thức — đây là chỗ đề gài bẫy |

Từ khoá nhận diện:

"chi phí ban đầu cao + chi phí tháng thấp" → ⚠ có lợi khi dùng LÂU "chi phí ban đầu thấp + chi phí tháng cao" → ⚠ có lợi khi dùng NGẮN "điểm hoà vốn" → ⚠ chênh ban đầu ÷ chênh định kỳ ⚠ Hai phương án ngược chiều nhau cùng một con số → ⚠ đề đang thử chiều bất đẳng thức

⚠ Yếu tố ngoài tiền cũng phải cân nhắc Yếu tố
⚠ Năng lực nội bộ có làm nổi không
⚠ Phần mềm này có phải năng lực cốt lõi không ⚠ cốt lõi thì nên tự làm dù đắt
⚠ Rủi ro phụ thuộc nhà cung cấp
⚠ Quyền sở hữu trí tuệ
⚠ Chi phí chuyển đổi về sau
⚠ Đề thi ⚠ thường chỉ hỏi phần tiền, nhưng thực tế phải xét đủ
⚠ Ba sai lầm hay gặp khi tính Sai lầm
⚠ Quên nhân số giao dịch với đơn giá ⚠ 0,17 chứ không phải 0,17 × 31.400
⚠ Trừ nhầm chiều
⚠ Đọc "thay thế trong vòng" thành "giữ lâu hơn" ⚠ bẫy chính của câu này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 5.338 = 0,17 × 31.400 | ⚠ kiểm lại phép nhân | | 33.000 ÷ 1.938 = 17,03 | ⚠ kiểm lại phép chia | | Dùng ngắn thì bên nào lợi | ⚠ bên có chi phí ban đầu thấp |

Và mấu chốt của câu này: con số 17 chỉ là một nửa đáp án — nửa còn lại là biết 17 đó nằm ở phía nào của dấu bất đẳng thức.

Câu 186 Process
You have been hired as an agile project manager by an organization that is new to agile. They have been utilizing waterfall methodologies to execute their projects and counting on your agile experience to bring incremental value to the business. You have been assigned a project. Your colleague provides you with historical data from similar projects on your first assignment and suggests that you calculate your team’s velocity and calculate your agile project’s end date. What would be your approach?
  1. A Advise your colleague that agile projects rely on detailed short-term planning and are focused on bringing incremental value over a long-term plan with one final product.
  2. B Thank your colleague and use the provided information as input to your planning processes.
  3. C Share the information with your team and ask for their input.
  4. D Use the bottom-up technique to estimate the duration of your project using historical data.
Xem giải thích

Đáp án

A — Nói với đồng nghiệp rằng dự án agile dựa trên LẬP KẾ HOẠCH NGẮN HẠN CHI TIẾT và tập trung mang lại GIÁ TRỊ TĂNG DẦN, chứ không phải một kế hoạch dài hạn với một sản phẩm cuối duy nhất.

Vì sao đúng

⚠ Vì sao không lấy velocity từ dữ liệu lịch sử của đội khác: | Lý do | Nội dung | |---|---| | ⚠ Velocity là chỉ số CỦA RIÊNG MỘT ĐỘI | ⚠ không so sánh được giữa các đội | | ⚠ Story point mỗi đội quy ước khác nhau | ⚠ 5 điểm của đội A không bằng 5 điểm của đội B | | ⚠ Đội mới CHƯA CÓ velocity | ⚠ phải chạy vài sprint mới đo được | | ⚠ Dữ liệu lịch sử là của dự án WATERFALL | ⚠ càng không dùng được | | ⚠ Agile không chốt ngày kết thúc từ đầu | ⚠ phạm vi mới là biến số | | ⚠ Vai trò của bạn | ⚠ họ thuê bạn để mang agile vào — GIÁO DỤC là việc đầu tiên |

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

  • B (cảm ơn và dùng thông tin đó làm đầu vào lập kế hoạch) — ⚠ phương án gây nhiễu mạnh nhất vì nghe lịch sự: ⚠ nhưng nó ⚠ CỦNG CỐ hiểu lầm thay vì sửa; ⚠ và tổ chức thuê bạn chính vì kinh nghiệm agile.

  • C (chia sẻ với đội và hỏi ý kiến) — ⚠ né trách nhiệm giáo dục; ⚠ đội cũng chưa quen agile.

  • D (dùng kỹ thuật bottom-up ước lượng thời lượng từ dữ liệu lịch sử) — ⚠ kỹ thuật của dự án DỰ ĐOÁN, ⚠ không phải cách agile lập kế hoạch.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25903 ở lô này (điều tra biến động velocity), câu #25913 cũng ở lô này (bên liên quan không hiểu story point), và câu #25904 (timeboxing). ⚠ Cả nhóm đều về việc GIÁO DỤC tổ chức mới dùng agile.

⚠ Velocity — dùng đúng và dùng sai: | Dùng ĐÚNG | Dùng SAI | |---|---| | ⚠ Đội tự dự báo được bao nhiêu việc cho sprint tới | ⚠ So sánh giữa các đội | | ⚠ Nhìn xu hướng ổn định của chính đội mình | ⚠ Dùng làm chỉ tiêu ép đội chạy nhanh hơn | | ⚠ Dự báo THÔ thời điểm hoàn thành backlog hiện tại | ⚠ Chốt ngày kết thúc cứng từ đầu dự án | | ⚠ Phát hiện bất thường để tìm hiểu nguyên nhân | ⚠ Lấy velocity của đội khác áp cho đội mình | | ⚠ Nguyên tắc | ⚠ velocity là công cụ DỰ BÁO của đội, không phải thước đo NĂNG SUẤT của quản lý |

Từ khoá nhận diện:

"tổ chức mới dùng agile" → ⚠ giáo dục là việc đầu tiên "lấy velocity từ dự án trước" → ⚠ sai — velocity không chuyển được "chốt ngày kết thúc từ dữ liệu lịch sử" → ⚠ tư duy dự đoán "cảm ơn và cứ dùng" → ⚠ lịch sự nhưng bỏ lỡ cơ hội sửa hiểu lầm

⚠ Agile lập kế hoạch thế nào Cách
⚠ Kế hoạch NHIỀU TẦNG ⚠ tầm nhìn → lộ trình → phát hành → sprint → ngày
⚠ Càng gần càng CHI TIẾT ⚠ sprint tới rõ từng việc, quý sau chỉ là chủ đề lớn
⚠ Lập kế hoạch LIÊN TỤC, không phải một lần
⚠ Phạm vi là biến số, thời gian và nguồn lực cố định ⚠ ngược với tam giác dự đoán
⚠ Kết quả ⚠ giao giá trị tăng dần, không đợi tới cuối mới có sản phẩm
⚠ Nói chuyện với đồng nghiệp này thế nào cho khéo Cách
⚠ GHI NHẬN thiện chí — họ đang cố giúp
⚠ Giải thích VÌ SAO velocity không chuyển được ⚠ không chỉ nói "không được"
⚠ Nói agile vẫn dự báo được, chỉ là cách khác
⚠ Mời họ tham gia sprint review để tự thấy
⚠ Tránh ⚠ nói kiểu "ở đây chúng ta làm agile" — không thuyết phục ai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có bị so velocity với đội khác không | ⚠ dấu hiệu tổ chức hiểu sai agile | | Có ai đòi ngày kết thúc cứng cho toàn backlog không | | | Đội đã chạy bao nhiêu sprint rồi | ⚠ dưới 3 sprint thì velocity chưa đáng tin |

Và điều một agile PM ở tổ chức mới chuyển đổi phải chấp nhận: phần lớn công việc thật không phải chạy sprint, mà là giải thích đi giải thích lại vì sao cách cũ không áp được vào cách mới.

Câu 187 Process
Milly is in the closing phase of a project. She ensures all invoices are paid, contracts are closed out, and lessons learned from the project are discussed and documented in the company's lessons learned repository. Milly's supervisor believes the project has successfully achieved its objectives and is ready to be handed over to the next project team. Which of the following factors for eliminating the need for a project would not be considered external?
  1. A Change in laws or regulations.
  2. B Mergers or acquisitions that affect the organization.
  3. C Shifts in the organizational structure.
  4. D Global or national economic changes.
Xem giải thích

Đáp án

C — THAY ĐỔI CƠ CẤU TỔ CHỨC (đây là yếu tố NỘI BỘ, không phải bên ngoài).

Vì sao đúng

⚠ Phân loại yếu tố khiến dự án không còn cần thiết: | Yếu tố | Bên ngoài hay nội bộ | |---|---| | ⚠ Thay đổi luật hoặc quy định | ⚠ BÊN NGOÀI — nhà nước quyết, tổ chức không kiểm soát | | ⚠ Sáp nhập hoặc mua bán doanh nghiệp | ⚠ BÊN NGOÀI — thị trường và bên thứ ba quyết | | ⚠ Biến động kinh tế toàn cầu hoặc quốc gia | ⚠ BÊN NGOÀI — hoàn toàn ngoài tầm với | | ⚠ Thay đổi cơ cấu tổ chức | ⚠ NỘI BỘ — chính tổ chức tự quyết — ĐÁP ÁN | | ⚠ Tiêu chí phân biệt | ⚠ tổ chức có QUYỀN QUYẾT ĐỊNH việc đó không |

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

  • B (sáp nhập hoặc mua bán ảnh hưởng tới tổ chức) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe như chuyện nội bộ vì nó xảy ra VỚI tổ chức, ⚠ nhưng ⚠ giao dịch M&A do bên ngoài và thị trường định đoạt, ⚠ và đề nói rõ "ảnh hưởng TỚI tổ chức" tức là đến từ ngoài vào.

  • A (thay đổi luật hoặc quy định) — ⚠ rõ ràng là bên ngoài.

  • D (biến động kinh tế toàn cầu hoặc quốc gia) — ⚠ rõ ràng là bên ngoài.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25892 ở lô này (rủi ro hệ thống) và câu #25843/#25898 (các yếu tố quản trị dự án). ⚠ Cùng nhóm phân biệt yếu tố nội bộ và bên ngoài.

⚠ Vì sao dự án bị kết thúc sớm: | Nhóm | Ví dụ | |---|---| | ⚠ BÊN NGOÀI | ⚠ luật mới cấm, kinh tế suy thoái, đối thủ ra sản phẩm trước, nhà cung cấp phá sản, thiên tai | | ⚠ NỘI BỘ | ⚠ tái cơ cấu, đổi chiến lược, đổi lãnh đạo, hết ngân sách, ưu tiên khác chen lên | | ⚠ THUỘC VỀ DỰ ÁN | ⚠ vượt chi phí quá mức, không khả thi kỹ thuật, mất nhà tài trợ | | ⚠ Điểm chung | ⚠ dự án hết lý do tồn tại — business case không còn đứng vững |

Từ khoá nhận diện:

"luật, quy định, kinh tế, thị trường, M&A" → ⚠ BÊN NGOÀI "cơ cấu tổ chức, chiến lược, ngân sách, nhân sự lãnh đạo" → ⚠ NỘI BỘ ⚠ Câu hỏi có chữ "KHÔNG" → ⚠ đọc kỹ, tìm cái KHÁC BIỆT chứ không tìm cái đúng

⚠ Kết thúc dự án sớm phải làm gì Việc
⚠ Vẫn chạy ĐẦY ĐỦ quy trình Kết thúc dự án ⚠ không phải bỏ ngang là xong
⚠ Thanh toán và đóng hợp đồng ⚠ giống việc Milly đang làm
⚠ Ghi bài học kinh nghiệm ⚠ dự án bị huỷ cũng có bài học, thậm chí nhiều hơn
⚠ Lưu trữ tài liệu
⚠ Giải phóng nguồn lực về tổ chức
⚠ Ghi rõ LÝ DO kết thúc trong báo cáo cuối ⚠ để lần sau nhận diện sớm hơn
⚠ Sai lầm ⚠ bỏ ngang không đóng gì — hợp đồng treo, bài học mất, nguồn lực kẹt
⚠ Vì sao phân biệt nội bộ và bên ngoài lại quan trọng Lý do
⚠ Yếu tố NỘI BỘ có thể tác động và thương lượng được ⚠ nhà tài trợ có thể can thiệp
⚠ Yếu tố BÊN NGOÀI chỉ có thể theo dõi và thích nghi
⚠ Chiến lược ứng phó rủi ro khác nhau ⚠ nội bộ thì giảm nhẹ, bên ngoài thường là chấp nhận hoặc leo thang
⚠ Trong phân tích PESTLE ⚠ chỉ quét yếu tố bên ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Business case của dự án còn đứng vững không | ⚠ nên xem lại ở mỗi cổng giai đoạn | | Tổ chức có sắp tái cơ cấu không | | | Có quy định mới nào sắp có hiệu lực không | |

Và điều dễ bị bỏ qua: dự án bị dừng vì lý do đúng không phải là thất bại. Tiêu tiền tiếp cho một dự án đã hết ý nghĩa mới là thất bại.

Câu 188 Process
Anders is working on scheduling several tasks as part of a construction project. Now that the rebar has been installed, he must ensure that the concrete leveling and pouring schedule are correct. He checks the schedule and sees that the concrete's leveling comes before the pouring, which is incorrect. Andres changes the schedule so that the concrete pouring team has an opportunity to complete its task before the concrete leveling team can start. Which of the following precedence diagramming method (PDM) dependencies is being used to construct the schedule model?
  1. A Start-to-finish
  2. B Start-to-start
  3. C Finish-to-finish
  4. D Finish-to-start
Xem giải thích

Đáp án

D — KẾT THÚC-BẮT ĐẦU (Finish-to-Start, FS).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Đội đổ bê tông phải HOÀN THÀNH việc của mình | ⚠ hoạt động trước phải KẾT THÚC | | ⚠ Trước khi đội cán phẳng được BẮT ĐẦU | ⚠ hoạt động sau mới BẮT ĐẦU | | ⚠ KẾT THÚC → BẮT ĐẦU | ⚠ chính là FS | | ⚠ Về mặt vật lý | ⚠ chưa có bê tông thì cán phẳng cái gì — đây là ràng buộc BẮT BUỘC |

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

  • A (Bắt đầu-Kết thúc, SF) — ⚠ phương án gây nhiễu mạnh nhất vì hiếm gặp nên dễ chọn liều: ⚠ SF nghĩa là ⚠ hoạt động sau BẮT ĐẦU thì hoạt động trước mới được KẾT THÚC; ⚠ ví dụ kinh điển là ca trực mới tới thì ca cũ mới về được. ⚠ Không phải tình huống này.

  • B (Bắt đầu-Bắt đầu, SS) — ⚠ hai việc bắt đầu cùng lúc; ⚠ đề nói rõ phải xong việc này mới làm việc kia.

  • C (Kết thúc-Kết thúc, FF) — ⚠ hai việc kết thúc cùng lúc; ⚠ cũng không đúng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25623 ở lô 177 (ràng buộc bắt buộc và hard logic), câu #25703 ở lô 179 (thuộc tính hoạt động), và câu #25902 ở lô này (độ trễ toàn phần). ⚠ Cả nhóm đều về sơ đồ mạng và lịch trình.

⚠ Bốn quan hệ của PDM: | Quan hệ | Nghĩa | Ví dụ | |---|---|---| | ⚠ FS — Kết thúc-Bắt đầu | ⚠ A xong thì B mới bắt đầu | ⚠ đổ bê tông xong mới cán phẳng — PHỔ BIẾN NHẤT | | ⚠ SS — Bắt đầu-Bắt đầu | ⚠ A bắt đầu thì B mới bắt đầu | ⚠ bắt đầu san nền thì bắt đầu lu lèn | | ⚠ FF — Kết thúc-Kết thúc | ⚠ A xong thì B mới xong | ⚠ viết code xong thì viết tài liệu mới xong | | ⚠ SF — Bắt đầu-Kết thúc | ⚠ B bắt đầu thì A mới kết thúc | ⚠ ca trực mới đến thì ca cũ mới về — HIẾM NHẤT | | ⚠ Mẹo đọc tên | ⚠ chữ ĐẦU là của hoạt động TRƯỚC, chữ SAU là của hoạt động SAU |

Từ khoá nhận diện:

"phải hoàn thành trước khi bắt đầu" → ⚠ FS "bắt đầu cùng lúc / vừa bắt đầu thì" → ⚠ SS "phải xong cùng lúc / không được xong trước" → ⚠ FF "bàn giao ca, thay thế hệ thống cũ" → ⚠ SF

⚠ Bốn loại phụ thuộc (khác với bốn quan hệ trên) Loại
⚠ BẮT BUỘC (hard logic) ⚠ bản chất công việc bắt phải vậy — như câu này
⚠ TUỲ CHỌN (soft logic) ⚠ do thực hành tốt hoặc lựa chọn của đội
⚠ BÊN NGOÀI ⚠ phụ thuộc vào bên ngoài dự án — giấy phép, nhà cung cấp
⚠ BÊN TRONG ⚠ giữa các hoạt động trong dự án, đội kiểm soát được
⚠ Lưu ý ⚠ hai cách phân loại này ĐỘC LẬP — một liên kết FS có thể là bắt buộc hoặc tuỳ chọn
⚠ Lead và lag Khái niệm
⚠ LEAD (đẩy sớm) ⚠ cho hoạt động sau bắt đầu SỚM hơn — "FS trừ 2 ngày"
⚠ LAG (chờ) ⚠ buộc hoạt động sau chờ thêm — "FS cộng 3 ngày cho bê tông đông cứng"
⚠ Ở tình huống này ⚠ thực tế thường có LAG chờ bê tông đủ cứng trước khi cán
⚠ Đừng nhầm ⚠ lag KHÔNG phải là một hoạt động, nó là độ trễ trên liên kết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Anders sửa lịch thế này có phải yêu cầu thay đổi không | ⚠ nếu lịch đã có đường cơ sở thì CÓ | | Lịch của bạn có liên kết SF nào không | ⚠ rất hiếm — thấy nhiều là có thể đang khai sai | | Các liên kết tuỳ chọn có được rà lại khi cần nén lịch không | ⚠ fast tracking chính là gỡ bớt liên kết tuỳ chọn |

Và bài học từ chính tình huống này: thứ tự sai trong sơ đồ mạng không tự lộ ra cho đến khi có người đối chiếu với thực tế công trường. Anders phát hiện được là nhờ đọc lại lịch, không phải nhờ phần mềm báo lỗi.

Câu 189 Process
Kenneth has completed a project to build a new art studio for university students. The professors are satisfied with the artistic decorations and resources available for their students. Kenneth has collected the feedback from the university staff and students and is preparing to archive them. The project sponsor has requested Kenneth to schedule a close-out meeting to review all relevant documentation before signing off on project completion. Which document would be most relevant to prepare for the meeting?
  1. A Lessons learned report
  2. B Change request
  3. C Project management plan
  4. D Project charter
Xem giải thích

Đáp án

A — BÁO CÁO BÀI HỌC KINH NGHIỆM (lessons learned report).

Vì sao đúng

⚠ Vì sao báo cáo bài học phù hợp nhất với buổi họp này: | Lý do | Nội dung | |---|---| | ⚠ Kenneth vừa THU THẬP PHẢN HỒI từ giảng viên và sinh viên | ⚠ đó chính là nguyên liệu của báo cáo bài học | | ⚠ Buổi họp là để RÀ SOÁT trước khi ký nghiệm thu | ⚠ cần bản tổng hợp những gì học được | | ⚠ Báo cáo bài học là ĐẦU RA của quy trình Kết thúc dự án | | | ⚠ Nó tổng hợp cả cái làm tốt và cái cần cải thiện | | | ⚠ Sau buổi họp | ⚠ báo cáo được nạp vào kho bài học của tổ chức làm tài sản quy trình |

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

  • C (kế hoạch quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ kế hoạch dùng để ⚠ ĐỐI CHIẾU kết quả thực tế, ⚠ nhưng nó là tài liệu của giai đoạn LẬP KẾ HOẠCH và THỰC HIỆN, ⚠ không phải thứ chuẩn bị riêng cho buổi họp kết thúc.

  • D (điều lệ dự án) — ⚠ tài liệu KHỞI TẠO; ⚠ có ích khi kiểm mục tiêu ban đầu, nhưng không phải trọng tâm buổi tổng kết.

  • B (yêu cầu thay đổi) — ⚠ không liên quan: ⚠ dự án đã xong, không còn thay đổi nào để duyệt.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25757 và #25761 ở lô 180 (bài học kinh nghiệm là yếu tố quản trị dự án), câu #25896 ở lô này (chuyển giao tri thức khó hơn dự tính), và câu #25909 cũng ở lô này (Milly ghi bài học khi đóng dự án). ⚠ Bài học kinh nghiệm đã xuất hiện BỐN lần trong hai lô gần nhau — chủ đề được hỏi rất dày.

⚠ Việc phải làm khi ĐÓNG dự án: | Việc | Nội dung | |---|---| | ⚠ Nghiệm thu bàn giao cuối cùng | ⚠ khách hàng ký chấp nhận | | ⚠ Đóng hợp đồng, thanh toán hết hoá đơn | ⚠ việc Milly làm ở câu #25909 | | ⚠ Hoàn tất báo cáo BÀI HỌC KINH NGHIỆM | ⚠ CÂU NÀY | | ⚠ Lưu trữ toàn bộ tài liệu dự án | | | ⚠ Giải phóng nguồn lực | | | ⚠ Cập nhật tài sản quy trình của tổ chức | | | ⚠ Báo cáo kết thúc cuối cùng | | | ⚠ Nguyên tắc | ⚠ dự án hoàn thành HAY bị huỷ đều phải chạy đủ các bước này |

Từ khoá nhận diện:

"họp tổng kết, đóng dự án, tổng hợp phản hồi" → ⚠ báo cáo bài học kinh nghiệm "kế hoạch quản lý dự án" → ⚠ dùng để đối chiếu, không phải sản phẩm của việc đóng "điều lệ dự án" → ⚠ giai đoạn khởi tạo "yêu cầu thay đổi" → ⚠ giai đoạn giám sát và kiểm soát

⚠ Báo cáo bài học nên có gì Nội dung
⚠ Việc gì đã làm TỐT và vì sao ⚠ đừng chỉ ghi cái sai
⚠ Việc gì KHÔNG ổn và nguyên nhân gốc
⚠ Khuyến nghị CỤ THỂ cho dự án sau ⚠ "giao tiếp tốt hơn" là vô dụng
⚠ Số liệu thực tế so với đường cơ sở
⚠ Phản hồi của bên liên quan ⚠ của Kenneth là phản hồi giảng viên và sinh viên
⚠ Sai lầm thường gặp ⚠ viết cho có rồi không ai đọc lại — xem câu #25896
⚠ Vì sao bài học hay bị bỏ qua Lý do
⚠ Đội đã bị điều sang dự án khác
⚠ Ngân sách đã đóng, không ai trả tiền cho việc này
⚠ Không có văn hoá đọc lại kho bài học
⚠ Ghi kiểu đổ lỗi nên không ai muốn thành thật
⚠ Cách chữa ⚠ thu bài học LIÊN TỤC trong dự án chứ không đợi tới cuối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có kho bài học không | | | Lần cuối bạn ĐỌC bài học của dự án khác là khi nào | ⚠ câu hỏi thật sự đáng hỏi | | Bài học có được thu trong lúc chạy hay chỉ ở cuối | |

Và điều làm nên giá trị của buổi họp này: nó là lần cuối cùng cả nhóm còn ngồi được với nhau. Bỏ qua nó thì mọi thứ học được sẽ đi theo từng người sang dự án khác, không ở lại với tổ chức.

Câu 190 Process
Kenneth is a product owner in a highly risk-averse company. For him to adjust the backlog based on risk to the company, he is most likely first to need to know the ________________.
  1. A The number of customers expected to use the product within the first two years
  2. B Full details of the user stories
  3. C The cost of the team during the delivery of the software
  4. D The financial return expected of the whole project
Xem giải thích

Đáp án

D — LỢI NHUẬN TÀI CHÍNH KỲ VỌNG CỦA CẢ DỰ ÁN.

Vì sao đúng

⚠ Vì sao đây là thứ cần biết TRƯỚC TIÊN: | Lý do | Nội dung | |---|---| | ⚠ Muốn xếp backlog theo RỦI RO thì phải biết rủi ro so với CÁI GÌ | ⚠ phải có mẫu số để so | | ⚠ Lợi nhuận kỳ vọng của cả dự án là NGƯỠNG THAM CHIẾU | ⚠ rủi ro lớn hay nhỏ đều tương đối với con số này | | ⚠ Công ty rất NGẠI RỦI RO | ⚠ khẩu vị rủi ro thấp → phải định lượng được ảnh hưởng tài chính | | ⚠ Product owner sở hữu GIÁ TRỊ, nên tư duy bằng tiền | | | ⚠ Có con số này rồi | ⚠ mới nói được "hạng mục này rủi ro 200.000 trên tổng lợi ích 1 triệu" — mới xếp ưu tiên được |

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

  • B (chi tiết đầy đủ của các user story) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe rất hợp lý vì PO làm việc với story, ⚠ nhưng ⚠ agile CỐ Ý không viết chi tiết đầy đủ mọi story từ đầu ⚠ (chi tiết dần theo tầng — xem câu #25908), ⚠ và chi tiết story không cho biết mức rủi ro so với giá trị tổng thể.

  • A (số khách hàng dự kiến trong hai năm đầu) — ⚠ một đầu vào để TÍNH lợi nhuận, ⚠ không phải thứ cần biết trước tiên.

  • C (chi phí đội trong quá trình bàn giao) — ⚠ chỉ là phần CHI PHÍ; ⚠ rủi ro phải so với LỢI ÍCH mới có nghĩa.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25889 ở lô này (xếp backlog theo EMV hoặc giá trị kinh doanh), câu #25892 (rủi ro hệ thống), và câu #25905 (đưa phản hồi vào backlog). ⚠ Bốn câu vẽ đủ bức tranh product owner quản trị backlog.

⚠ Các cách xếp ưu tiên backlog: | Cách | Cơ sở | |---|---| | ⚠ Giá trị kinh doanh | ⚠ hạng mục nào mang lại nhiều tiền hoặc lợi ích nhất | | ⚠ RỦI RO | ⚠ làm sớm phần rủi ro cao để phát hiện vấn đề sớm — CÂU NÀY | | ⚠ MoSCoW | ⚠ bắt buộc / nên có / có thì tốt / lần này không | | ⚠ WSJF (chi phí trì hoãn ÷ quy mô) | ⚠ của SAFe | | ⚠ Kano | ⚠ cơ bản / hiệu năng / gây thích thú | | ⚠ Thực tế | ⚠ thường KẾT HỢP giá trị và rủi ro chứ không dùng một tiêu chí |

Từ khoá nhận diện:

"xếp backlog theo rủi ro" → ⚠ phải biết giá trị tổng để so "công ty ngại rủi ro" → ⚠ cần con số định lượng, không nói định tính "chi tiết đầy đủ mọi story" → ⚠ trái tinh thần chi tiết dần của agile "product owner" → ⚠ người chịu trách nhiệm TỐI ĐA HOÁ GIÁ TRỊ

⚠ Vì sao agile ưu tiên làm phần RỦI RO CAO trước Lý do
⚠ Thất bại sớm thì rẻ ⚠ phát hiện ở sprint 2 rẻ hơn nhiều so với ở tháng thứ 10
⚠ Giảm bất định sớm cho phần còn lại của kế hoạch
⚠ Có thời gian xoay xở nếu phải đổi hướng
⚠ Bên liên quan thấy phần khó nhất đã xong thì yên tâm
⚠ Đối lập ⚠ làm phần dễ trước cho đẹp biểu đồ là tự lừa mình
⚠ Công ty NGẠI RỦI RO thì PO nên làm gì Việc
⚠ Định lượng rủi ro bằng TIỀN, không nói "cao/thấp" ⚠ lãnh đạo ngại rủi ro nghe con số mới tin
⚠ Chia nhỏ hạng mục rủi ro cao để thử nghiệm rẻ ⚠ spike, prototype
⚠ Trình bày cả rủi ro của việc KHÔNG LÀM ⚠ thường bị bỏ quên
⚠ Minh bạch trong backlog ⚠ ghi rõ hạng mục nào rủi ro cao
⚠ Lưu ý ⚠ ngại rủi ro không có nghĩa là né mọi rủi ro — nghĩa là phải BIẾT rủi ro mình nhận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết dự án mình kỳ vọng thu về bao nhiêu không | ⚠ rất nhiều đội không biết | | Backlog có ghi mức rủi ro của từng hạng mục không | | | Hạng mục rủi ro cao đang nằm ở đầu hay cuối backlog | |

Và điều một product owner giỏi hiểu sớm: không có con số giá trị tổng thì mọi cuộc tranh luận về ưu tiên đều là tranh luận về cảm tính.