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

Tìm thấy 720 câu.

Câu 261 Process
As the project manager for Marshall Materials, Deepak is actively working with his project team to monitor the pressure gauge on a piece of equipment. Should the temperature exceed 79 percent, Candace, the engineer, has recommended a series of steps to be implemented. What does the 79 percent mark represent?
  1. A A workaround
  2. B The threshold
  3. C Mitigation
  4. D An upper control limit
Xem giải thích

Đáp án

B — NGƯỠNG (threshold).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Một giá trị CỤ THỂ được định trước: 79% | ⚠ mốc định lượng | | ⚠ VƯỢT mốc đó thì kích hoạt loạt bước đã chuẩn bị sẵn | ⚠ điều kiện kích hoạt | | ⚠ Các bước đã được kỹ sư khuyến nghị TRƯỚC | ⚠ kế hoạch dự phòng có sẵn | | ⚠ Định nghĩa ngưỡng | ⚠ giá trị đo được, khi vượt qua thì đòi hỏi phải HÀNH ĐỘNG | | ⚠ Điểm mấu chốt | ⚠ ngưỡng là ĐIỂM KÍCH HOẠT, còn hành động sau đó mới là ứng phó |

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

  • D (giới hạn kiểm soát trên — upper control limit) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất giống: ⚠ nhưng giới hạn kiểm soát là ⚠ biên của một BIỂU ĐỒ KIỂM SOÁT thống kê, ⚠ tính từ dữ liệu quy trình (thường ±3 độ lệch chuẩn); ⚠ vượt giới hạn kiểm soát nghĩa là quy trình MẤT KIỂM SOÁT, ⚠ khác hẳn một mốc do kỹ sư đặt ra để kích hoạt quy trình ứng phó.

  • C (giảm nhẹ — mitigation) — ⚠ là CHIẾN LƯỢC ứng phó rủi ro, ⚠ tức là loạt bước sẽ thực hiện; ⚠ không phải bản thân con số 79%.

  • A (giải pháp tình thế — workaround) — ⚠ phản ứng KHÔNG CÓ KẾ HOẠCH TRƯỚC với một rủi ro chưa nhận diện; ⚠ ở đây mọi thứ đã được chuẩn bị sẵn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25940 ở lô 184 (giới hạn WIP là cơ chế kiểm soát trong agile), câu #25967 (phân tích xu hướng lỗi), và bộ chiến lược ứng phó rủi ro ở lô 181–182. ⚠ Nhóm giám sát và kiểm soát.

⚠ Phân biệt bốn khái niệm hay lẫn: | Khái niệm | Nghĩa | |---|---| | ⚠ NGƯỠNG (threshold) | ⚠ mốc do người ta ĐẶT RA, vượt thì phải hành động — CÂU NÀY | | ⚠ GIỚI HẠN KIỂM SOÁT | ⚠ biên TÍNH TỪ DỮ LIỆU quy trình, vượt là quy trình mất kiểm soát | | ⚠ GIỚI HẠN ĐẶC TÍNH KỸ THUẬT | ⚠ yêu cầu của KHÁCH HÀNG về sản phẩm | | ⚠ ĐIỂM KÍCH HOẠT RỦI RO (trigger) | ⚠ dấu hiệu cho biết rủi ro sắp xảy ra — rất gần với ngưỡng | | ⚠ Mẹo nhớ | ⚠ ngưỡng do TA đặt, giới hạn kiểm soát do QUY TRÌNH sinh ra, giới hạn đặc tính do KHÁCH HÀNG đòi | | ⚠ Điều dễ nhầm nhất | ⚠ giới hạn kiểm soát thường HẸP HƠN giới hạn đặc tính — quy trình ổn định thì sản phẩm chắc chắn đạt chuẩn |

Từ khoá nhận diện:

"vượt mốc X thì làm loạt bước đã định" → ⚠ ngưỡng "±3 sigma, biểu đồ kiểm soát" → ⚠ giới hạn kiểm soát "khách hàng yêu cầu sản phẩm phải trong khoảng" → ⚠ giới hạn đặc tính kỹ thuật "xử lý bất ngờ, không có kế hoạch trước" → ⚠ giải pháp tình thế

⚠ Ngưỡng được dùng ở đâu trong dự án Nơi dùng
⚠ Ngưỡng RỦI RO ⚠ mức rủi ro chấp nhận được của tổ chức
⚠ Ngưỡng SAI LỆCH chi phí và lịch ⚠ vượt 10% thì phải báo cáo lên nhà tài trợ
⚠ Ngưỡng CHẤT LƯỢNG ⚠ tỷ lệ lỗi tối đa chấp nhận được
⚠ Ngưỡng KỸ THUẬT ⚠ áp suất, nhiệt độ, tải hệ thống — CÂU NÀY
⚠ Ghi ở đâu ⚠ kế hoạch quản lý rủi ro, kế hoạch quản lý chất lượng, kế hoạch quản lý chi phí
⚠ Vì sao đặt ngưỡng TRƯỚC lại quan trọng Lý do
⚠ Quyết định trong lúc khủng hoảng luôn tệ hơn quyết định lúc bình tĩnh
⚠ Ai cũng biết khi nào phải hành động, không phải tranh luận
⚠ Hành động diễn ra NHANH vì đã có kịch bản
⚠ Tránh việc mỗi người có một mức chịu đựng khác nhau
⚠ Ở tình huống này ⚠ 79% là con số kỹ sư đặt ra để còn kịp xử lý trước khi thiết bị gặp sự cố thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có ngưỡng sai lệch nào được ghi ra không | ⚠ hay chỉ là "khi nào thấy nghiêm trọng thì báo" | | Ai được quyền tuyên bố ngưỡng đã bị vượt | | | Hành động sau khi vượt ngưỡng có được chuẩn bị trước không | |

Và giá trị thật của một ngưỡng: nó biến câu hỏi "khi nào thì đáng lo?" thành một con số, và câu trả lời đó được quyết định lúc chưa ai lo lắng cả.

Câu 262 Process
Drew is a project manager on a tight timeline to deliver a software product. After reviewing emails and work logs from the past month, he realizes that his team has several key product features ready to go but that the main components still require development. Drew thinks that putting the completed components into production would not be disruptive. And he believes that the project will begin to lose stakeholder approval if the remaining development continues to lag. How can the project manager deliver business value in this scenario?
  1. A Backlog grooming
  2. B Incremental deliverables
  3. C Testing at all levels
  4. D Acceptance test-driven development
Xem giải thích

Đáp án

B — BÀN GIAO TĂNG DẦN (incremental deliverables).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Một số tính năng ĐÃ SẴN SÀNG | ⚠ có thứ giao được ngay | | ⚠ Các thành phần chính CÒN cần phát triển | ⚠ chưa xong hết | | ⚠ Drew tin việc đưa phần đã xong vào sản xuất KHÔNG gây gián đoạn | ⚠ điều kiện kỹ thuật cho phép | | ⚠ Bên liên quan sắp mất niềm tin nếu phần còn lại tiếp tục chậm | ⚠ áp lực cần chứng minh giá trị | | ⚠ Kết luận | ⚠ giao từng phần dùng được thay vì đợi giao trọn gói — đó là bàn giao tăng dần |

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

  • A (tinh chỉnh backlog — backlog grooming) — ⚠ phương án gây nhiễu mạnh nhất vì là hoạt động agile quen thuộc: ⚠ nhưng tinh chỉnh backlog ⚠ sắp xếp và làm rõ công việc TƯƠNG LAI, ⚠ không GIAO được giá trị nào cho bên liên quan ngay bây giờ ⚠ — đúng thứ Drew đang cần.

  • C (kiểm thử ở mọi cấp) — ⚠ hoạt động chất lượng, ⚠ cần thiết nhưng không tự tạo ra giá trị kinh doanh được giao.

  • D (phát triển hướng kiểm thử chấp nhận — ATDD) — ⚠ một thực hành kỹ thuật giúp làm đúng ngay từ đầu; ⚠ hữu ích nhưng không giải quyết bài toán "giao gì cho bên liên quan ngay bây giờ".

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25972 ở lô 184 (nguyên mẫu và các cách tiếp cận phát triển), câu #25974 (tư duy agile cho dự án dài hạn bất định), và câu #25988 cũng ở lô này (dự án xây dựng → dự đoán). ⚠ Ba câu về việc chọn cách tiếp cận, và câu #25988 là ĐỐI CỰC của câu này — xem đối chiếu ở đó.

⚠ Vì sao giao tăng dần tạo ra giá trị kinh doanh: | Lý do | Nội dung | |---|---| | ⚠ Người dùng bắt đầu HƯỞNG LỢI ngay, không đợi tới cuối | | | ⚠ Thu được PHẢN HỒI THẬT từ việc dùng thật | ⚠ quý hơn mọi buổi rà soát yêu cầu | | ⚠ Bên liên quan THẤY tiến triển, giữ được niềm tin | ⚠ đúng vấn đề Drew lo | | ⚠ Giảm rủi ro "làm cả năm rồi mới biết sai" | | | ⚠ Có thể thu hồi vốn sớm | | | ⚠ Nhắc lại | ⚠ giá trị chỉ được ghi nhận khi ĐƯỢC GIAO — liên hệ #25957 lô 184, "xong 90%" không tồn tại |

Từ khoá nhận diện:

"giao phần đã xong, phần còn lại làm tiếp" → ⚠ bàn giao tăng dần "sắp xếp công việc tương lai" → ⚠ tinh chỉnh backlog, chưa giao gì "bên liên quan sắp mất niềm tin" → ⚠ cần thứ GIAO ĐƯỢC, không cần thêm quy trình "kiểm thử, ATDD" → ⚠ thực hành chất lượng, không phải cách giao giá trị

⚠ Điều kiện để giao tăng dần được Điều kiện
⚠ Phần giao ra phải DÙNG ĐƯỢC ĐỘC LẬP ⚠ Drew đã xác nhận điều này
⚠ Không gây gián đoạn hệ thống đang chạy ⚠ Drew cũng đã xác nhận
⚠ Đã qua đủ kiểm thử theo Định nghĩa Hoàn thành ⚠ liên hệ #25953 lô 184
⚠ Người dùng được thông báo và hướng dẫn
⚠ Có kế hoạch quay lui nếu có sự cố
⚠ Điều Drew CHƯA làm ⚠ xác nhận với PRODUCT OWNER và bên liên quan — "tôi tin là không gián đoạn" cần được kiểm chứng, không chỉ là niềm tin
⚠ Phân biệt TĂNG DẦN và LẶP Phân biệt
⚠ TĂNG DẦN ⚠ mỗi lần giao THÊM một phần mới, dùng được — CÂU NÀY
⚠ LẶP ⚠ làm đi làm lại CÙNG MỘT THỨ cho hoàn thiện dần
⚠ Ví dụ tăng dần ⚠ xây xong tầng một thì cho vào ở, rồi xây tầng hai
⚠ Ví dụ lặp ⚠ vẽ phác thảo, rồi vẽ chi tiết, rồi tô màu cùng một bức tranh
⚠ Agile thường dùng ⚠ CẢ HAI cùng lúc — liên hệ ghi chú chất lượng ở #25972 lô 184

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có thứ gì đã xong mà chưa giao không | ⚠ thường là có, và thường không ai để ý | | Phần đó có dùng được độc lập không | | | Bên liên quan có biết là họ có thể nhận sớm không | |

Và điều Drew phát hiện ra khi đọc lại nhật ký công việc: giá trị đã nằm sẵn ở đó cả tháng nay, chỉ là không ai nghĩ tới việc giao nó đi.

Câu 263 Business Environment
You are a project manager for your organization. Your project has a BAC of $400,000 and is expected to last one year. The project work is scheduled to be completed in equal amounts each month. Currently, the project is in month three but is only 20 percent complete. You have spent $35,000 to complete the work. What is the earned value for this project?
  1. A Not enough information has been supplied to determine this.
  2. B –$20,000.
  3. C $80,000.
  4. D $100,000.
Xem giải thích

Đáp án

C — 80.000 đô la.

Vì sao đúng

⚠ Công thức và phép tính: | Đại lượng | Cách tính | Kết quả | |---|---|---| | ⚠ BAC — ngân sách khi hoàn thành | ⚠ đề cho | ⚠ 400.000 | | ⚠ Phần trăm HOÀN THÀNH THẬT | ⚠ đề cho | ⚠ 20% | | ⚠ EV — giá trị thu được | ⚠ BAC × % hoàn thành | ⚠ 400.000 × 0,20 = 80.000 | | ⚠ PV — giá trị kế hoạch | ⚠ 400.000 × 3/12 | ⚠ 100.000 | | ⚠ AC — chi phí thực tế | ⚠ đề cho | ⚠ 35.000 | | ⚠ Điểm mấu chốt | ⚠ EV CHỈ phụ thuộc vào BAC và % HOÀN THÀNH — không dính gì tới thời gian đã trôi qua hay tiền đã tiêu |

⚠ Đọc thêm sức khoẻ dự án: | Chỉ số | Công thức | Kết quả | Ý nghĩa | |---|---|---|---| | ⚠ SV — sai lệch lịch | ⚠ EV − PV | ⚠ 80.000 − 100.000 = −20.000 | ⚠ CHẬM tiến độ | | ⚠ SPI | ⚠ EV ÷ PV | ⚠ 80.000 ÷ 100.000 = 0,80 | ⚠ chỉ đạt 80% tốc độ kế hoạch | | ⚠ CV — sai lệch chi phí | ⚠ EV − AC | ⚠ 80.000 − 35.000 = +45.000 | ⚠ DƯỚI ngân sách | | ⚠ CPI | ⚠ EV ÷ AC | ⚠ 80.000 ÷ 35.000 = 2,29 | ⚠ mỗi đồng bỏ ra thu về 2,29 đồng giá trị | | ⚠ Chẩn đoán | ⚠ chậm tiến độ nhưng rẻ bất thường — thường là dấu hiệu CHƯA HUY ĐỘNG ĐỦ nguồn lực, chứ không phải hiệu quả cao |

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

  • D (100.000) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ đó là ⚠ PV — giá trị KẾ HOẠCH ⚠ tại tháng thứ ba (3/12 của 400.000); ⚠ nhầm PV với EV là lỗi phổ biến nhất khi học EVM.

  • B (−20.000) — ⚠ đó là SV, sai lệch lịch, ⚠ không phải EV.

  • A (không đủ thông tin) — ⚠ đủ hoàn toàn: ⚠ chỉ cần BAC và phần trăm hoàn thành.

Ghi nhớ

⚠ Đối chiếu — họ EVM đã gặp: ⚠ câu #25581 lô 176 (CV), #25648 (CPI 0,91), #25685 lô 179 (CPI 0,96), #25708 (ETC 329.667), #25718 (CPI 0,93), #25920 lô 183 (phần lớn ngân sách nằm ở giai đoạn thực hiện). ⚠ Câu này là câu EVM đầu tiên hỏi trực tiếp về EV.

⚠ Bộ công thức EVM cần thuộc: | Chỉ số | Công thức | Nghĩa | |---|---|---| | ⚠ EV | ⚠ BAC × % hoàn thành | ⚠ giá trị công việc ĐÃ LÀM XONG | | ⚠ PV | ⚠ BAC × % thời gian theo kế hoạch | ⚠ đáng lẽ phải làm xong bao nhiêu | | ⚠ AC | ⚠ tiền đã tiêu thật | | | ⚠ SV / SPI | ⚠ EV − PV / EV ÷ PV | ⚠ tiến độ | | ⚠ CV / CPI | ⚠ EV − AC / EV ÷ AC | ⚠ chi phí | | ⚠ EAC | ⚠ BAC ÷ CPI | ⚠ dự báo tổng chi phí cuối cùng | | ⚠ ETC | ⚠ EAC − AC | ⚠ còn phải tiêu bao nhiêu nữa | | ⚠ VAC | ⚠ BAC − EAC | ⚠ dự báo dư hay vượt ngân sách | | ⚠ Mẹo nhớ dấu | ⚠ mọi chỉ số SAI LỆCH đều là "EV trừ đi cái kia"; ÂM là xấu, DƯƠNG là tốt | | ⚠ Mẹo nhớ tỷ số | ⚠ mọi chỉ số hiệu suất đều là "EV chia cho cái kia"; DƯỚI 1 là xấu |

Từ khoá nhận diện:

"giá trị thu được / earned value" → ⚠ BAC × % hoàn thành "đáng lẽ phải làm được bao nhiêu" → ⚠ PV "đã tiêu bao nhiêu" → ⚠ AC ⚠ Đề cho cả ba con số thời gian, tiền và phần trăm → ⚠ chỉ lấy đúng cái cần, đừng dùng hết

⚠ Bẫy thường gặp của câu hỏi EV Bẫy
⚠ Đưa AC vào để dụ tính CV ⚠ 35.000 hoàn toàn không cần cho câu này
⚠ Đưa mốc thời gian để dụ tính PV ⚠ tháng thứ ba cũng không cần
⚠ Câu chữ "chỉ 20% hoàn thành" nghe như tin xấu ⚠ nhưng EV vẫn tính bình thường
⚠ Nguyên tắc làm bài ⚠ xác định ĐÚNG công thức trước, rồi mới lấy số — đừng lấy số trước rồi tìm cách ghép

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 400.000 × 0,20 = 80.000 | ⚠ kiểm lại phép nhân | | 400.000 × 3/12 = 100.000 | ⚠ đó là PV, không phải EV | | CPI 2,29 có hợp lý không | ⚠ hiếm khi thật — thường là chưa huy động đủ người, hoặc chi phí chưa được ghi nhận hết |

Và câu hỏi thực tế mà bộ số này gợi ra: một dự án chậm 20% tiến độ mà mới tiêu 35% số tiền lẽ ra phải tiêu, gần như luôn có nghĩa là chưa ai thật sự bắt tay vào làm.

Câu 264 Process
Samuel loves the continuous integration they have just started to use in their project at Khal’s Kittens. Samuel can expect the impact on his project to be
  1. A No production bugs.
  2. B There will be no impact at all on those that write test scripts.
  3. C Additional time spent on the implementation of automated testing as part of their build efforts.
  4. D A large burden on the testing team each time they do a release.
Xem giải thích

Đáp án

C — TỐN THÊM THỜI GIAN để dựng KIỂM THỬ TỰ ĐỘNG như một phần của quá trình build.

Vì sao đúng

⚠ Tích hợp liên tục đòi hỏi gì: | Yêu cầu | Nội dung | |---|---| | ⚠ Mỗi lần đưa mã lên đều CHẠY BUILD TỰ ĐỘNG | | | ⚠ Build phải kèm BỘ KIỂM THỬ TỰ ĐỘNG | ⚠ không có kiểm thử thì CI chỉ là biên dịch tự động | | ⚠ Bộ kiểm thử đó phải được VIẾT ra | ⚠ đây chính là khoản đầu tư thời gian ban đầu | | ⚠ Và phải được BẢO TRÌ liên tục | ⚠ chi phí lâu dài, không chỉ một lần | | ⚠ Nói cách khác | ⚠ CI dịch chuyển công sức kiểm thử từ CUỐI chu kỳ sang TỪNG NGÀY — tổng công sức ban đầu TĂNG, nhưng phân bố đều và phát hiện lỗi sớm hơn nhiều |

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

  • D (gánh nặng lớn cho đội kiểm thử mỗi lần phát hành) — ⚠ phương án gây nhiễu mạnh nhất vì mô tả đúng tình trạng KHI KHÔNG CÓ CI: ⚠ nhưng CI làm điều ⚠ NGƯỢC LẠI ⚠ — nó GIẢM gánh nặng kiểm thử thủ công ở thời điểm phát hành, vì phần lớn đã được kiểm tự động mỗi ngày.

  • A (không còn lỗi trên môi trường sản xuất) — ⚠ hứa hẹn quá mức; ⚠ CI ⚠ GIẢM ⚠ lỗi, không LOẠI BỎ hoàn toàn; ⚠ phương án nào nói "không còn lỗi nào" gần như luôn sai.

  • B (không ảnh hưởng gì tới người viết kịch bản kiểm thử) — ⚠ sai hẳn: ⚠ chính họ là người bị ảnh hưởng NHIỀU NHẤT, ⚠ vì công việc chuyển từ kiểm thử thủ công sang viết và bảo trì kiểm thử tự động.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25953 ở lô 184 (kiểm thử phải nằm trong Định nghĩa Hoàn thành), câu #25967 (phân tích xu hướng lỗi), và câu #25984 ở lô này (bàn giao tăng dần). ⚠ Cả nhóm về chất lượng và nhịp giao hàng trong agile.

⚠ Ba khái niệm hay bị gộp làm một: | Khái niệm | Nghĩa | |---|---| | ⚠ TÍCH HỢP LIÊN TỤC (CI) | ⚠ hợp nhất mã thường xuyên, mỗi lần đều build và chạy kiểm thử tự động — CÂU NÀY | | ⚠ GIAO HÀNG LIÊN TỤC (CD — delivery) | ⚠ luôn có bản SẴN SÀNG phát hành, nhưng bấm nút phát hành là quyết định của con người | | ⚠ TRIỂN KHAI LIÊN TỤC (CD — deployment) | ⚠ mọi thay đổi qua được kiểm thử là TỰ ĐỘNG lên sản xuất | | ⚠ Thứ tự trưởng thành | ⚠ CI là nền móng — không có CI thì hai cái sau không thể có |

Từ khoá nhận diện:

"tích hợp liên tục" → ⚠ đầu tư vào kiểm thử tự động "không còn lỗi nào" → ⚠ hứa hẹn quá mức, luôn sai "không ảnh hưởng gì" → ⚠ hầu như luôn sai với một thay đổi thực hành lớn "gánh nặng dồn vào lúc phát hành" → ⚠ mô tả tình trạng KHÔNG có CI

⚠ Lợi ích thật của CI Lợi ích
⚠ Phát hiện lỗi TÍCH HỢP trong vài phút thay vì vài tuần ⚠ lợi ích lớn nhất
⚠ Mã luôn ở trạng thái build được
⚠ Giảm "địa ngục hợp nhất" ở cuối chu kỳ
⚠ Tạo lưới an toàn cho việc tái cấu trúc
⚠ Cho phép giao hàng thường xuyên ⚠ liên hệ #25984 — bàn giao tăng dần
⚠ Chi phí đổi lại ⚠ thời gian viết kiểm thử, hạ tầng build, và kỷ luật của cả đội
⚠ CI thất bại khi nào Trường hợp
⚠ Bộ kiểm thử chạy quá lâu ⚠ quá 10 phút là đội bắt đầu bỏ qua
⚠ Kiểm thử "chập chờn" — lúc xanh lúc đỏ vô cớ ⚠ giết niềm tin vào CI nhanh nhất
⚠ Đội để build đỏ mà vẫn làm tiếp ⚠ build đỏ phải là ưu tiên số một
⚠ Chỉ có CI mà không viết kiểm thử ⚠ khi đó chỉ là biên dịch tự động
⚠ Nguyên tắc ⚠ CI là một THÓI QUEN của đội, không phải một công cụ mua về là xong

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Build của đội bạn mất bao lâu | | | Có kiểm thử nào hay hỏng vô cớ không | ⚠ sửa hoặc xoá, đừng để nó ở đó | | Khi build đỏ, đội phản ứng trong bao lâu | |

Và điều Samuel sẽ nhận ra sau vài tháng: thời gian bỏ ra viết kiểm thử tự động không biến mất — nó chỉ chuyển từ những đêm sửa lỗi trước ngày phát hành sang những buổi chiều bình thường.

Câu 265 Process
Luis is the scrum master for Project Mix-it-Up, its fifth iteration, and has a velocity of twenty-five story points. The project is nearly complete, and the team is ready to move on to other work. However, a key stakeholder approached Luis with a new feature they would like to add to the project. What should Luis do?
  1. A Add the feature to the backlog as change is welcome at any time.
  2. B Direct the stakeholder to the change control board because of the timing of the project completion.
  3. C Decline the request as the change is coming too late for the project.
  4. D Submit the feature for the team to review since they are almost done with the work.
Xem giải thích

Đáp án

A — THÊM tính năng vào BACKLOG, vì trong agile thay đổi được chào đón ở bất kỳ thời điểm nào.

Vì sao đúng

⚠ Nguyên tắc agile áp dụng ở đây: | Nguyên tắc | Nội dung | |---|---| | ⚠ CHÀO ĐÓN thay đổi yêu cầu, kể cả muộn | ⚠ nguyên tắc số 2 của Tuyên ngôn Agile | | ⚠ Backlog là nơi MỌI yêu cầu mới đi vào | ⚠ liên hệ #25905 lô 183 | | ⚠ Thêm vào backlog KHÔNG có nghĩa là sẽ làm | ⚠ điểm mấu chốt — product owner mới là người quyết | | ⚠ Không có "quá muộn để ĐỀ XUẤT" | ⚠ chỉ có "quyết định không làm trong dự án này" | | ⚠ Vai của Luis | ⚠ Scrum Master hướng yêu cầu vào đúng kênh, không phán xét nội dung |

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

  • B (chuyển bên liên quan sang ban kiểm soát thay đổi vì dự án sắp xong) — ⚠ phương án gây nhiễu mạnh nhất vì CCB là cơ chế đúng trong dự án DỰ ĐOÁN: ⚠ nhưng ⚠ dự án agile KHÔNG dùng CCB cho từng hạng mục backlog ⚠ — product owner có thẩm quyền xếp và loại hạng mục; ⚠ dựng CCB vào giữa là mang bộ máy dự đoán áp lên agile.

  • C (từ chối vì thay đổi tới quá muộn) — ⚠ đi ngược nguyên tắc nền tảng của agile.

  • D (đưa cho đội xem xét vì họ sắp xong việc) — ⚠ SAI VAI: ⚠ đội ước lượng NỖ LỰC, ⚠ PRODUCT OWNER quyết có đưa vào và xếp ở đâu ⚠ — liên hệ #25915 lô 183.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25905 ở lô 183 (hướng phản hồi bên liên quan vào backlog), câu #25912 (PO xếp backlog theo rủi ro), câu #25915 (PO chưa xếp backlog), và câu #25978 ở lô 184 (bên liên quan xin dời mốc trong dự án dự đoán → phân tích tác động). ⚠ #25978 và câu này là cặp ĐỐI CHIẾU đẹp nhất về hai cách xử lý thay đổi.

⚠ Xử lý yêu cầu thay đổi: DỰ ĐOÁN và AGILE: | | Dự đoán | Agile | |---|---|---| | ⚠ Nơi tiếp nhận | ⚠ yêu cầu thay đổi chính thức | ⚠ product backlog | | ⚠ Ai quyết | ⚠ CCB hoặc nhà tài trợ | ⚠ product owner | | ⚠ Chi phí thay đổi | ⚠ tăng mạnh về cuối dự án | ⚠ giữ tương đối phẳng | | ⚠ Thái độ với thay đổi | ⚠ KIỂM SOÁT — bảo vệ đường cơ sở | ⚠ CHÀO ĐÓN — coi là nguồn giá trị | | ⚠ Thủ tục | ⚠ nặng, có phân tích tác động | ⚠ nhẹ, chỉ cần xếp lại ưu tiên | | ⚠ Điểm chung | ⚠ cả hai đều KHÔNG cho phép làm thay đổi mà không qua cơ chế nào cả — liên hệ #25975 lô 184, mạ vàng |

Từ khoá nhận diện:

"agile, backlog, sprint" → ⚠ thay đổi vào backlog, PO quyết "đường cơ sở, CCB, yêu cầu thay đổi" → ⚠ dự án dự đoán "quá muộn để thay đổi" → ⚠ sai trong agile "đội quyết có nhận tính năng không" → ⚠ sai vai, đó là việc của PO

⚠ Nhưng thực tế thì tính năng đó có được làm không Câu trả lời
⚠ PO xem xét GIÁ TRỊ so với các hạng mục còn lại
⚠ Dự án sắp kết thúc — có thể không còn sprint nào để làm
⚠ Khi đó hạng mục ở lại backlog cho SẢN PHẨM, không cho DỰ ÁN này ⚠ backlog sản phẩm sống lâu hơn dự án
⚠ Hoặc trở thành đầu vào cho một dự án sau
⚠ Điều quan trọng ⚠ yêu cầu được GHI NHẬN và MINH BẠCH, chứ không bị gạt đi bằng một câu "muộn rồi"
⚠ Vì sao "chào đón thay đổi" không phải là "nhận mọi thứ" Giải thích
⚠ Chào đón nghĩa là không PHẠT người đề xuất
⚠ Vẫn phải đánh đổi: thêm cái này thì bớt cái kia ⚠ sức chứa của đội là hữu hạn
⚠ PO công khai đánh đổi đó với bên liên quan
⚠ Hiểu sai thường gặp ⚠ coi agile là "muốn gì cũng được" — dẫn thẳng tới đội kiệt sức và sản phẩm chắp vá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan có biết cách đưa ý tưởng vào backlog không | | | Backlog của bạn có hạng mục nào nằm mãi không được xét không | | | Khi thêm việc mới, có ai nói rõ việc gì bị đẩy lùi không | |

Và cách trả lời đúng nhất mà Luis nên nói với bên liên quan: "tôi sẽ đưa vào backlog ngay — còn có kịp làm trong dự án này hay không thì để product owner cân với những việc còn lại."

Câu 266 Process

Hugh provides general contracting services for residential and light commercial projects. He usually begins by digging a foundation, after which he pours concrete and creates support structures. He has some leeway in deciding which steps come next, but he usually prefers to do the framing and electrical work before doing any ductwork for climate control systems. His projects come together piece by piece, but they cannot be considered complete until all the pieces are in place. Which project methodology is appropriate?

  1. A Incremental
  2. B Iterative
  3. C Agile
  4. D Predictive
Xem giải thích

Đáp án

D — DỰ ĐOÁN (predictive).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Trình tự công việc CỐ ĐỊNH: đào móng → đổ bê tông → kết cấu chịu lực | ⚠ ràng buộc BẮT BUỘC, không đảo được | | ⚠ Hugh CÓ chút linh hoạt ở các bước sau | ⚠ ràng buộc TUỲ CHỌN — nhưng vẫn trong khung kế hoạch | | ⚠ Anh làm việc này LẶP ĐI LẶP LẠI, đã có quy trình quen | ⚠ bất định thấp | | ⚠ "Không thể coi là hoàn thành cho tới khi mọi phần đã vào chỗ" | ⚠ câu quyết định — KHÔNG giao được từng phần | | ⚠ Kết luận | ⚠ phạm vi rõ, công nghệ quen, không giao được tăng dần → DỰ ĐOÁN |

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

  • A (tăng dần — incremental) — ⚠ phương án gây nhiễu mạnh nhất vì đề có cụm ⚠ "dự án ghép lại từng mảnh một": ⚠ nhưng ⚠ "ghép từng mảnh" KHÔNG phải "giao được từng mảnh"; ⚠ đề nói rõ ⚠ chưa đủ mọi phần thì chưa hoàn thành ⚠ — mà tăng dần đòi hỏi mỗi phần phải DÙNG ĐƯỢC ĐỘC LẬP. ⚠ Không ai ở được trong một ngôi nhà mới có móng và khung.

  • B (lặp — iterative) — ⚠ lặp là làm lại cùng một thứ để hoàn thiện dần; ⚠ Hugh không đổ móng ba lần cho đẹp hơn.

  • C (agile) — ⚠ cần bất định cao và khả năng giao từng phần; ⚠ cả hai đều không có ở đây.

Ghi nhớ

⚠ Đối chiếu — cặp ĐỐI CỰC trong cùng một lô: ⚠ câu #25984 ⚠ (phần mềm có tính năng đã xong, đưa vào sản xuất được ngay → BÀN GIAO TĂNG DẦN) ⚠ và câu này ⚠ (xây nhà, chưa đủ mọi phần thì chưa dùng được → DỰ ĐOÁN). ⚠ Hai câu cùng có hình ảnh "ghép từng phần", nhưng khoá ngược nhau — và lý do nằm ở ĐÚNG MỘT câu hỏi: phần đã xong có DÙNG ĐƯỢC ĐỘC LẬP không? ⚠ Xem thêm câu #25972 và #25974 ở lô 184.

⚠ Câu hỏi phân biệt duy nhất cần nhớ: | Câu hỏi | Nếu CÓ | Nếu KHÔNG | |---|---|---| | ⚠ Phần đã xong có dùng được độc lập không? | ⚠ TĂNG DẦN | ⚠ DỰ ĐOÁN | | ⚠ Yêu cầu có còn mơ hồ, cần thử để làm rõ không? | ⚠ LẶP | ⚠ DỰ ĐOÁN | | ⚠ Cả hai đều CÓ? | ⚠ AGILE | | | ⚠ Dự án lớn, phần này có phần kia không? | ⚠ LAI | | | ⚠ Áp dụng cho Hugh | ⚠ cả hai đều KHÔNG → dự đoán |

Từ khoá nhận diện:

"trình tự cố định, quy trình quen thuộc" → ⚠ dự đoán "chưa đủ mọi phần thì chưa hoàn thành" → ⚠ KHÔNG phải tăng dần "ghép từng mảnh" → ⚠ bẫy — hỏi thêm: mảnh đó dùng được chưa? "yêu cầu chưa rõ, cần phản hồi" → ⚠ thích ứng

⚠ Vì sao ngành xây dựng chủ yếu dùng dự đoán Lý do
⚠ Ràng buộc VẬT LÝ không đảo ngược được ⚠ không thể lợp mái trước khi dựng tường
⚠ Sửa sai rất đắt ⚠ đập đi xây lại, khác hẳn sửa một dòng mã
⚠ Quy định, giấy phép, nghiệm thu theo giai đoạn
⚠ Yêu cầu thường rõ từ đầu qua bản vẽ thiết kế
⚠ Nhưng vẫn có chỗ cho thực hành thích ứng ⚠ lập kế hoạch cuốn chiếu, họp ngắn hằng ngày trên công trường, cải tiến liên tục — nhiều nhà thầu đã áp dụng
⚠ "Có chút linh hoạt trong thứ tự" nói lên điều gì Ý nghĩa
⚠ Đó là ràng buộc TUỲ CHỌN, không phải bằng chứng của agile
⚠ Dự án dự đoán VẪN có lựa chọn trong khuôn khổ kế hoạch
⚠ Chính chỗ linh hoạt này là nơi FAST TRACKING khả thi ⚠ liên hệ #25938 lô 184 — nén lịch
⚠ Đừng nhầm ⚠ linh hoạt về THỨ TỰ khác hẳn linh hoạt về PHẠM VI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có giao được phần nào độc lập không | ⚠ câu hỏi quyết định cách tiếp cận | | Yêu cầu đã rõ tới mức nào | | | Sửa sai ở dự án của bạn đắt tới mức nào | ⚠ càng đắt thì càng nghiêng về dự đoán |

Và cách kiểm tra nhanh nhất mọi câu hỏi kiểu này: hỏi xem khách hàng có dùng được nửa sản phẩm không. Nếu không, mọi lựa chọn thích ứng đều bị loại ngay.

Câu 267 Process
Enrique is concerned about the scope of his project. Although he tried to be mindful of his project's resources when defining the project's deliverables, Enrique worries that he will be unable to deliver unless he is explicit with the stakeholders about what his team can and cannot reasonably be expected to produce. For instance, one of the stakeholders is especially interested in cosmetic features that are subjective and outside of Enrique's expertise. Rather than letting the stakeholder argue for inclusions like these in the project scope statement, as the project proceeds, Enrique puts together a list of what his team will do in the allotted time and clarifies that any additional work will require contract modifications. This is an example of which part of the project scope statement?
  1. A Product scope description
  2. B Acceptance criteria
  3. C Deliverables
  4. D

    Scope exclusions
Xem giải thích

Đáp án

D — LOẠI TRỪ KHỎI PHẠM VI (scope exclusions).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Enrique nói RÕ RÀNG đội có thể và KHÔNG THỂ làm gì | ⚠ vạch ranh giới | | ⚠ Ngăn bên liên quan cài thêm các mục thẩm mỹ vào phạm vi | ⚠ chặn trượt phạm vi từ đầu | | ⚠ Ghi rõ mọi việc thêm sẽ cần SỬA HỢP ĐỒNG | ⚠ hệ quả của việc vượt ranh giới | | ⚠ Các mục thẩm mỹ là CHỦ QUAN và ngoài chuyên môn của đội | ⚠ lý do chính đáng để loại trừ | | ⚠ Định nghĩa | ⚠ loại trừ khỏi phạm vi ghi rõ những gì KHÔNG nằm trong dự án, để quản lý kỳ vọng |

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

  • C (bàn giao) — ⚠ phương án gây nhiễu mạnh nhất vì Enrique có lập một DANH SÁCH những việc đội sẽ làm: ⚠ nhưng ⚠ trọng tâm của cả đoạn văn là việc VẠCH RA CÁI KHÔNG LÀM ⚠ và hệ quả hợp đồng của nó; ⚠ danh sách việc sẽ làm chỉ là mặt bên kia của cùng một ranh giới.

  • B (tiêu chí chấp nhận) — ⚠ điều kiện để được NGHIỆM THU; ⚠ ở đây chưa nói tới điều kiện nghiệm thu nào.

  • A (mô tả phạm vi sản phẩm) — ⚠ mô tả ĐẶC ĐIỂM sản phẩm; ⚠ không phải ranh giới công việc.

Ghi nhớ

⚠ Đối chiếu — BỘ BỐN MỤC của tuyên bố phạm vi đã HOÀN TẤT qua ba lô: | Mục | Câu | Nội dung | |---|---|---| | ⚠ BÀN GIAO | ⚠ #25959 (lô 184) | ⚠ 100 máy in, mực, phụ tùng, bảo trì một năm | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ #25977 (lô 184) | ⚠ bản mẫu bị từ chối vì bảng màu không thân thiện với người mù màu | | ⚠ LOẠI TRỪ KHỎI PHẠM VI | ⚠ #25989 (lô này) | ⚠ Enrique nói rõ đội không làm phần thẩm mỹ | | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | ⚠ chưa từng làm khoá đáp án | ⚠ luôn xuất hiện làm phương án nhiễu | | ⚠ Bốn khoá NHẤT QUÁN | ⚠ mỗi câu hỏi về một mục khác nhau của cùng một tài liệu — không có mâu thuẫn nào | | ⚠ Dự đoán cho lô sau | ⚠ nếu gặp câu về "đặc điểm kỹ thuật của sản phẩm" thì đó là mục thứ tư |

⚠ Vì sao mục LOẠI TRỪ lại quan trọng nhất trong thực tế: | Lý do | Nội dung | |---|---| | ⚠ Ngăn TRƯỢT PHẠM VI ngay từ gốc | ⚠ liên hệ #25975 lô 184 — mạ vàng và trượt phạm vi | | ⚠ Quản lý kỳ vọng TRƯỚC khi có tranh cãi | | | ⚠ Là căn cứ khi phải từ chối yêu cầu về sau | ⚠ "cái này ta đã ghi rõ là không thuộc dự án" | | ⚠ Bảo vệ đội khỏi việc không có chuyên môn | ⚠ đúng tình huống của Enrique | | ⚠ Nhưng | ⚠ đây lại là mục BỊ BỎ TRỐNG nhiều nhất trong các tuyên bố phạm vi thực tế |

Từ khoá nhận diện:

"nói rõ những gì KHÔNG làm" → ⚠ loại trừ khỏi phạm vi "danh sách những thứ phải giao" → ⚠ bàn giao "điều kiện để được chấp nhận" → ⚠ tiêu chí chấp nhận "đặc điểm, tính năng sản phẩm" → ⚠ mô tả phạm vi sản phẩm

⚠ Enrique đã làm đúng những gì Việc
⚠ Nhận diện SỚM bên liên quan có kỳ vọng vượt phạm vi
⚠ Vạch ranh giới TRƯỚC khi dự án chạy ⚠ muộn hơn thì thành tranh cãi
⚠ Nêu rõ HỆ QUẢ: thêm việc thì phải sửa hợp đồng ⚠ gắn ranh giới với cơ chế thực thi
⚠ Trung thực về giới hạn năng lực của đội ⚠ nhận việc ngoài chuyên môn là rủi ro lớn
⚠ Nên làm thêm ⚠ cho bên liên quan KÝ XÁC NHẬN tuyên bố phạm vi — mục loại trừ chỉ có sức nặng khi được đồng thuận
⚠ Viết mục loại trừ thế nào cho hiệu quả Cách
⚠ CỤ THỂ, không chung chung ⚠ "không bao gồm thiết kế đồ hoạ và lựa chọn màu sắc" chứ không phải "không bao gồm việc ngoài phạm vi"
⚠ Nêu những thứ người ta HAY GIẢ ĐỊNH là có ⚠ đào tạo, di chuyển dữ liệu, bảo trì sau bàn giao
⚠ Nói kèm nơi có thể lấy phần đó ⚠ "phần này sẽ do một hợp đồng riêng đảm nhiệm"
⚠ Tránh ⚠ để trống mục này vì "chưa ai hỏi tới"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyên bố phạm vi gần nhất của bạn có mục loại trừ không | | | Nếu có, nó có cụ thể tới mức người đọc hiểu ngay không | | | Bên liên quan có ký xác nhận không | |

Và một dòng trong mục loại trừ có sức mạnh mà cả trang mô tả phạm vi không có: nó là nơi duy nhất trong tài liệu nói cho khách hàng biết thứ họ sẽ KHÔNG nhận được, vào lúc còn đủ sớm để họ đi tìm nó ở chỗ khác.

Câu 268 Process
Management wants to know how long the project work will take. The project manager uses a similar project to predict the duration of the current project work. The project manager is using which form of estimating?
  1. A Parametric
  2. B Expert judgment
  3. C Analogous
  4. D Bottom-up
Xem giải thích

Đáp án

C — ƯỚC LƯỢNG TƯƠNG TỰ (analogous estimating).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Dùng một dự án TƯƠNG TỰ để dự báo | ⚠ so sánh với dữ liệu lịch sử của dự án giống nhau | | ⚠ Không nhắc tới tham số hay đơn giá nào | ⚠ loại ước lượng tham số | | ⚠ Không nhắc tới việc chia nhỏ công việc | ⚠ loại ước lượng từ dưới lên | | ⚠ Định nghĩa | ⚠ lấy thời lượng hoặc chi phí của dự án tương tự trong quá khứ làm cơ sở cho dự án hiện tại | | ⚠ Đặc điểm | ⚠ NHANH nhất và RẺ nhất, nhưng cũng KÉM CHÍNH XÁC nhất |

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

  • B (phán đoán chuyên gia) — ⚠ phương án gây nhiễu mạnh nhất vì ước lượng tương tự thường ĐI KÈM phán đoán chuyên gia: ⚠ nhưng phán đoán chuyên gia dựa vào ⚠ KIẾN THỨC và KINH NGHIỆM của một người, ⚠ còn ở đây có ⚠ một DỰ ÁN THAM CHIẾU cụ thể ⚠ — đó là dấu hiệu rõ ràng của ước lượng tương tự.

  • A (ước lượng tham số) — ⚠ dùng QUAN HỆ THỐNG KÊ và ĐƠN GIÁ: ⚠ "1.000 mét cáp × 2 giờ mỗi mét"; ⚠ đề không nhắc tới đơn giá nào.

  • D (ước lượng từ dưới lên) — ⚠ chia nhỏ tới từng gói công việc rồi CỘNG LẠI: ⚠ chính xác nhất nhưng tốn công nhất; ⚠ đề không mô tả việc chia nhỏ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25944 ở lô 184 (dùng lại định nghĩa vai trò từ dự án khách sạn tương tự) — ⚠ cùng một tinh thần: khai thác dự án tương tự trong quá khứ. ⚠ Xem thêm câu #25716 ở lô 179 (ước lượng ba điểm — tam giác 65 so với beta 62,5), câu #25917 ở lô 183 (quy luật lợi ích giảm dần), và câu #25985 ở lô này (EVM).

⚠ BỐN kỹ thuật ước lượng — bảng đối chiếu: | Kỹ thuật | Cách làm | Chính xác | Tốn công | |---|---|---|---| | ⚠ TƯƠNG TỰ | ⚠ lấy dự án giống trước đây làm chuẩn | ⚠ thấp nhất | ⚠ ít nhất — CÂU NÀY | | ⚠ THAM SỐ | ⚠ đơn giá × khối lượng, dựa trên thống kê | ⚠ trung bình tới cao | ⚠ trung bình | | ⚠ BA ĐIỂM | ⚠ lạc quan, khả dĩ nhất, bi quan | ⚠ cao, có tính tới bất định | ⚠ trung bình | | ⚠ TỪ DƯỚI LÊN | ⚠ chia nhỏ tới gói công việc rồi cộng | ⚠ cao nhất | ⚠ nhiều nhất | | ⚠ Chọn thế nào | ⚠ giai đoạn ĐẦU dùng tương tự (chưa có chi tiết), càng về sau càng dùng kỹ thuật chính xác hơn |

⚠ Hai công thức ước lượng ba điểm cần thuộc: | Phân bố | Công thức | |---|---| | ⚠ TAM GIÁC | ⚠ (O + M + P) ÷ 3 | | ⚠ BETA (PERT) | ⚠ (O + 4M + P) ÷ 6 | | ⚠ Khác nhau ở đâu | ⚠ beta cho ước lượng khả dĩ nhất trọng số GẤP BỐN — sát thực tế hơn |

Từ khoá nhận diện:

"dự án tương tự trước đây" → ⚠ ước lượng tương tự "đơn giá, hệ số, mỗi mét mất bao nhiêu giờ" → ⚠ ước lượng tham số "lạc quan, bi quan, khả dĩ nhất" → ⚠ ba điểm "chia nhỏ rồi cộng lại" → ⚠ từ dưới lên "ý kiến người có kinh nghiệm" → ⚠ phán đoán chuyên gia

⚠ Khi nào ước lượng tương tự đáng tin Điều kiện
⚠ Dự án tham chiếu THẬT SỰ giống ⚠ cùng loại, cùng quy mô, cùng công nghệ, cùng đội
⚠ Dữ liệu lịch sử được ghi chép ĐẦY ĐỦ ⚠ nhiều tổ chức không có
⚠ Có điều chỉnh cho khác biệt đã biết ⚠ lạm phát, quy mô, độ phức tạp
⚠ Được dùng làm ĐIỂM XUẤT PHÁT, không phải kết luận cuối
⚠ Rủi ro lớn nhất ⚠ hai dự án "trông giống nhau" ở bề ngoài nhưng khác hẳn ở bên trong
⚠ Vì sao lãnh đạo hay đòi con số ngay Bối cảnh
⚠ Cần ra quyết định đầu tư sớm
⚠ Chưa có đủ chi tiết cho kỹ thuật chính xác hơn
⚠ Cách trả lời chuyên nghiệp ⚠ đưa con số KÈM KHOẢNG SAI SỐ — "khoảng 8–14 tháng, dựa trên dự án X, sẽ chính xác hơn sau khi lập WBS"
⚠ Sai lầm ⚠ đưa một con số duy nhất rồi bị coi là cam kết — ước lượng bậc thô có sai số tới ±50%

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có lưu dữ liệu thời lượng thực tế của dự án cũ không | ⚠ không có thì không thể ước lượng tương tự | | Dự án tham chiếu giống dự án hiện tại ở những điểm nào | | | Bạn có đưa kèm khoảng sai số khi báo con số không | |

Và điều cần nói kèm mỗi khi dùng ước lượng tương tự: đây là con số để QUYẾT ĐỊNH CÓ LÀM HAY KHÔNG, không phải con số để CAM KẾT NGÀY GIAO HÀNG.

Câu 269 Process
You and the project team are creating the change control approach for your project. Marcy, a project team member, wants to know why there is so much emphasis on creating and documenting the change control processes for the project. Which one of the following is the best answer to Marcy’s query?
  1. A A documented change control approach allows the project’s profitability to improve because each change may affect the profit and loss of the project.
  2. B A documented change control approach allows the project to improve because the impact of each change must be considered before it is approved.
  3. C A documented change control approach is required by management.
  4. D A documented change control approach is required by the project customer.
Xem giải thích

Đáp án

B — Quy trình kiểm soát thay đổi được ghi thành văn giúp dự án TỐT LÊN, vì TÁC ĐỘNG của mỗi thay đổi PHẢI ĐƯỢC XEM XÉT trước khi được phê duyệt.

Vì sao đúng

⚠ Vì sao đây là câu trả lời đúng cho Marcy: | Lý do | Nội dung | |---|---| | ⚠ Nêu MỤC ĐÍCH THẬT của quy trình, không nêu ai bắt làm | | | ⚠ Phân tích tác động là GIÁ TRỊ CỐT LÕI của kiểm soát thay đổi | ⚠ liên hệ #25978 lô 184 — thu thập dữ liệu về tác động trước | | ⚠ Áp dụng cho MỌI dự án, không phụ thuộc bối cảnh | | | ⚠ Thay đổi được duyệt trong hiểu biết đầy đủ mới là thay đổi tốt | | | ⚠ Tác động phải xét gồm | ⚠ phạm vi, lịch, chi phí, chất lượng, nguồn lực, rủi ro, và cả các thay đổi khác đã duyệt |

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

  • A (giúp cải thiện LỢI NHUẬN vì mỗi thay đổi ảnh hưởng lãi lỗ) — ⚠ phương án gây nhiễu mạnh nhất vì tài chính đúng là một phần của tác động: ⚠ nhưng nó ⚠ THU HẸP mục đích xuống chỉ còn tiền; ⚠ rất nhiều dự án không có lãi lỗ nào ⚠ — dự án nội bộ, dự án phi lợi nhuận, dự án tuân thủ.

  • C (vì lãnh đạo yêu cầu) — ⚠ trả lời "AI BẮT", không trả lời "VÌ SAO"; ⚠ và câu trả lời kiểu này không thuyết phục được ai.

  • D (vì khách hàng yêu cầu) — ⚠ cùng vấn đề, ⚠ và không phải khách hàng nào cũng yêu cầu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25978 ở lô 184 (bên liên quan xin dời mốc → thu thập dữ liệu tác động), câu #25956 (nhật ký thay đổi ghi cả thay đổi bị từ chối), câu #25975 (mạ vàng), và câu #25987 ở lô này (agile đưa thay đổi vào backlog). ⚠ Nhóm kiểm soát thay đổi có năm câu qua ba lô.

⚠ Vì sao kiểm soát thay đổi làm dự án TỐT LÊN chứ không làm chậm lại: | Lý do | Nội dung | |---|---| | ⚠ Ngăn thay đổi "nghe hay" nhưng hại nhiều hơn lợi | | | ⚠ Cho thấy CHI PHÍ THẬT trước khi cam kết | ⚠ người đề xuất thường không biết cái giá của thứ mình xin | | ⚠ Phát hiện thay đổi MÂU THUẪN với thay đổi khác | ⚠ lý do rất hay bị quên | | ⚠ Bảo đảm đường cơ sở luôn phản ánh thực tế | ⚠ không có nó thì mọi báo cáo tiến độ đều vô nghĩa | | ⚠ Tạo dấu vết cho tranh chấp về sau | | | ⚠ Nghịch lý thường gặp | ⚠ đội coi kiểm soát thay đổi là thủ tục làm chậm việc — trong khi nó chính là thứ ngăn việc phải làm đi làm lại |

Từ khoá nhận diện:

"vì sao cần kiểm soát thay đổi" → ⚠ để xem xét TÁC ĐỘNG trước khi duyệt "vì lãnh đạo/khách hàng yêu cầu" → ⚠ trả lời AI, không trả lời VÌ SAO "cải thiện lợi nhuận" → ⚠ thu hẹp mục đích, không đúng với mọi dự án ⚠ Câu hỏi "câu trả lời TỐT NHẤT" → ⚠ tìm câu đúng với MỌI dự án, không chỉ dự án này

⚠ Bảy bước của kiểm soát thay đổi tích hợp Bước
⚠ 1. Tiếp nhận yêu cầu thay đổi ⚠ bằng văn bản, có người đề xuất rõ ràng
⚠ 2. Ghi vào NHẬT KÝ THAY ĐỔI ⚠ liên hệ #25956
⚠ 3. PHÂN TÍCH TÁC ĐỘNG ⚠ trọng tâm của câu này
⚠ 4. Trình CCB hoặc người có thẩm quyền
⚠ 5. Quyết định: duyệt / từ chối / hoãn
⚠ 6. Cập nhật kế hoạch và đường cơ sở nếu duyệt
⚠ 7. THÔNG BÁO cho các bên liên quan ⚠ bước hay bị bỏ nhất
⚠ Thiếu bước 3 ⚠ thì sáu bước còn lại chỉ là thủ tục hành chính
⚠ Trả lời Marcy thế nào cho thuyết phục Cách
⚠ Đưa một VÍ DỤ CỤ THỂ từ dự án trước ⚠ "thay đổi tưởng nhỏ đó đã đội chi phí lên 30%"
⚠ Nhấn mạnh nó BẢO VỆ đội, không phải trói buộc đội ⚠ không có nó thì đội nhận thêm việc mà không được thêm thời gian
⚠ Nói rõ mức độ thủ tục sẽ TƯƠNG XỨNG với quy mô thay đổi ⚠ liên hệ #25840 lô 182 — mức quản lý cấu hình phải PHÙ HỢP
⚠ Tránh ⚠ nói "vì quy trình bắt phải thế" — đó chính là phương án C và D

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có hiểu VÌ SAO phải qua kiểm soát thay đổi không | ⚠ hay chỉ biết là phải làm | | Phân tích tác động của bạn có xét đủ sáu chiều không | | | Có thay đổi nào đang được làm mà chưa qua quy trình không | ⚠ liên hệ #25975 — mạ vàng |

Và câu trả lời ngắn gọn nhất cho Marcy: quy trình này không tồn tại để nói KHÔNG với thay đổi — nó tồn tại để không ai phải nói CÓ khi chưa biết mình đang đồng ý với điều gì.

Câu 270 People
Damian is an effective team leader who has built a safe environment for disagreement. Therefore, the team feels empowered to move forward without obstacles. Why?
  1. A The team can create a list of reasons why tasks are incomplete and present it to management.
  2. B In order to make better decisions, Damian encourages the team to engage in constructive conflict.
  3. C The team has chosen to avoid conflict of any kind.
  4. D As a team leader, Damian takes responsibility for every decision that is made.
Xem giải thích

Đáp án

B — Để ra được QUYẾT ĐỊNH TỐT HƠN, Damian khuyến khích đội tham gia vào XUNG ĐỘT XÂY DỰNG.

Vì sao đúng

⚠ Vì sao môi trường an toàn dẫn tới đội không còn vật cản: | Lý do | Nội dung | |---|---| | ⚠ An toàn tâm lý cho phép người ta NÓI RA điều mình nghĩ | ⚠ kể cả điều trái ý số đông | | ⚠ Ý kiến trái chiều được nêu SỚM thay vì bị nén lại | | | ⚠ Vấn đề được nhìn từ nhiều góc trước khi quyết | ⚠ quyết định tốt hơn | | ⚠ Không còn bất đồng ngầm phá hoại về sau | ⚠ đó chính là "không còn vật cản" | | ⚠ Từ khoá | ⚠ XUNG ĐỘT XÂY DỰNG — bất đồng về VẤN ĐỀ, không phải công kích CON NGƯỜI |

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

  • C (đội đã chọn cách né tránh mọi loại xung đột) — ⚠ phương án gây nhiễu mạnh nhất vì "không có xung đột" nghe như một đội hoà thuận: ⚠ nhưng ⚠ đội KHÔNG BAO GIỜ bất đồng là đội đang che giấu, không phải đội đồng thuận; ⚠ và né tránh mọi xung đột thì không giải quyết được gì cả ⚠ (liên hệ #25775 lô 180 — né tránh thường bị xếp thấp nhất).

  • D (Damian nhận trách nhiệm cho mọi quyết định) — ⚠ ngược với việc trao quyền; ⚠ đề nói đội cảm thấy ĐƯỢC TRAO QUYỀN, không phải được che chắn.

  • A (đội lập danh sách lý do công việc chưa xong để trình lãnh đạo) — ⚠ văn hoá bào chữa, ⚠ hoàn toàn không liên quan tới môi trường an toàn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25922 ở lô 183 (lãnh đạo thừa nhận sai lầm → an toàn tâm lý), câu #25916 (Eva nhường-thua vì không thấy an toàn để tranh luận tiếp), câu #25926 (bất đồng và cam kết), và bộ bốn câu xung đột ở lô 184 (#25937, #25945, #25963, #25982). ⚠ Câu này bổ sung góc nhìn PHÒNG NGỪA: xây môi trường để xung đột trở nên có ích ngay từ đầu.

⚠ XUNG ĐỘT XÂY DỰNG và XUNG ĐỘT PHÁ HOẠI: | Xây dựng | Phá hoại | |---|---| | ⚠ Nói về VẤN ĐỀ và Ý TƯỞNG | ⚠ Nói về CON NGƯỜI | | ⚠ Dựa trên dữ liệu và lập luận | ⚠ Dựa trên cảm xúc và quyền lực | | ⚠ Mọi người vẫn tôn trọng nhau sau đó | ⚠ Để lại oán giận | | ⚠ Kết thúc bằng quyết định tốt hơn | ⚠ Kết thúc bằng bên thắng và bên thua | | ⚠ Ai cũng dám tham gia | ⚠ Người yếu thế im lặng | | ⚠ Ranh giới | ⚠ là mức 1 và mức 2 trong thang xung đột — liên hệ #25937 lô 184 |

Từ khoá nhận diện:

"môi trường an toàn để bất đồng" → ⚠ xung đột xây dựng, quyết định tốt hơn "đội không bao giờ có xung đột" → ⚠ dấu hiệu xấu, không phải tốt "lãnh đạo gánh mọi quyết định" → ⚠ ngược với trao quyền "danh sách lý do chưa xong" → ⚠ văn hoá bào chữa

⚠ Xây môi trường an toàn bằng cách nào Cách
⚠ Lãnh đạo TỰ NHẬN SAI trước ⚠ liên hệ #25922 — bằng chứng không thể làm giả
⚠ Phản ứng với tin xấu bằng lời CẢM ƠN ⚠ không phải bằng câu hỏi "tại sao để xảy ra"
⚠ Hỏi ý kiến người ít nói TRƯỚC ⚠ trước khi số đông định hình quan điểm
⚠ Tách ý kiến khỏi người nêu ý kiến ⚠ "ý này có điểm yếu" chứ không phải "anh sai rồi"
⚠ Đặt quy tắc chung cho tranh luận ⚠ liên hệ #25970 lô 184
⚠ Điều phá hỏng nhanh nhất ⚠ một lần trừng phạt người nói thật là đủ để cả đội im lặng nhiều tháng
⚠ Vì sao đội "không có vật cản" Giải thích
⚠ Vật cản lớn nhất thường KHÔNG phải kỹ thuật ⚠ mà là điều không ai dám nói ra
⚠ Nêu sớm thì gỡ được sớm
⚠ Quyết định có sự đồng thuận thật thì không bị phá ngầm ⚠ liên hệ #25926 — bất đồng và cam kết
⚠ Kết quả đo được ⚠ đội trao đổi thẳng thắn giao hàng đều hơn, không phải vì họ giỏi hơn mà vì họ ít phải quay lại sửa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần cuối có người phản đối bạn trong cuộc họp là khi nào | ⚠ nếu không nhớ nổi thì đó là dấu hiệu đáng lo | | Tin xấu đến với bạn sớm hay muộn | | | Người ít nói nhất trong đội có bao giờ được hỏi ý kiến không | |

Và điều dễ hiểu ngược nhất về một đội hiệu quả: họ tranh luận nhiều hơn, chứ không phải ít hơn. Sự im lặng dễ chịu trong phòng họp hiếm khi là dấu hiệu của sự đồng thuận.