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

Tìm thấy 718 câu.

Câu 171 Process
Devon's latest project, the Starlight Project, is scheduled to last for 30 months and has a budget of $325,000. Devon is thankful to report that the project is on schedule and that 10 percent has been finished. What is the BAC in this scenario?
  1. A $162,500
  2. B $325,000
  3. C $32,500
  4. D $3,250
Xem giải thích

Đáp án

B — 325.000 đô-la.

Vì sao đúng

⚠ BAC là gì: | Khía cạnh | Nội dung | |---|---| | ⚠ BAC = Budget At Completion = NGÂN SÁCH KHI HOÀN THÀNH | ⚠ tổng ngân sách được duyệt cho toàn bộ dự án | | ⚠ Đề cho thẳng: ngân sách 325.000 đô | ⚠ đó chính là BAC, không cần tính gì | | ⚠ Nó KHÔNG đổi theo tiến độ | ⚠ 10% hoàn thành hay 90% thì BAC vẫn thế | | ⚠ Nó chỉ đổi khi có YÊU CẦU THAY ĐỔI được duyệt | ⚠ liên hệ #26524 lô 195 | | ⚠ Kết luận | ⚠ câu hỏi kiểm tra định nghĩa, không kiểm tra phép tính |

⚠ Hai dữ kiện thừa: ⚠ "30 tháng" và "hoàn thành 10%" hoàn toàn KHÔNG cần cho câu hỏi này ⚠ — ⚠ chúng dùng để tính PV và EV, hai đại lượng khác; ⚠ nhận ra dữ kiện thừa cũng là một kỹ năng làm bài, và đề PMP cài chúng rất thường xuyên.

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

  • C (32.500 đô) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đó chính là EV = 325.000 × 10% = 32.500, một đại lượng có thật và tính đúng: ⚠ nhưng ⚠ EV là GIÁ TRỊ THU ĐƯỢC — phần công việc đã làm; BAC là TỔNG NGÂN SÁCH ⚠ — ⚠ đề cài dữ kiện 10% chính là để dụ người đọc nhân lên; ⚠ liên hệ #26599 cùng lô, nơi cùng một kiểu bẫy được dùng với PV và EV.

  • A (162.500 đô) — ⚠ là một nửa ngân sách; ⚠ có thể là kết quả của việc nhầm tưởng phải chia cho gì đó.

  • D (3.250 đô) — ⚠ là 1% ngân sách; ⚠ sai bậc độ lớn.

Ghi nhớ

⚠ Đối chiếu — BỘ GIÁ TRỊ THU ĐƯỢC: ⚠ #26599 cùng lô (tính PV), ⚠ #26478 lô 194 (tính CV), ⚠ #26559 lô 196 (tính EAC), ⚠ #26459 lô 194 (đọc CPI), ⚠ #26523 lô 195 (EVM trải suốt dự án).

⚠ CÁC ĐẠI LƯỢNG NỀN của EVM — bảng chốt: | Ký hiệu | Tên | Nghĩa | Trong bài này | |---|---|---|---| | ⚠ BAC | ⚠ ngân sách khi hoàn thành | ⚠ TỔNG ngân sách được duyệt | ⚠ 325.000 — ĐÁP ÁN | | ⚠ PV | ⚠ giá trị hoạch định | ⚠ theo kế hoạch tới nay phải làm được bao nhiêu | ⚠ cần biết đang ở tháng thứ mấy | | ⚠ EV | ⚠ giá trị thu được | ⚠ thực tế đã làm được bao nhiêu | ⚠ 325.000 × 10% = 32.500 — nhiễu C | | ⚠ AC | ⚠ chi phí thực tế | ⚠ đã tiêu bao nhiêu | ⚠ đề không cho | | ⚠ Mẹo phân biệt BAC và EV | ⚠ BAC là ngân sách CỦA CẢ DỰ ÁN, không bao giờ nhân với phần trăm hoàn thành; EV mới là cái nhân | | |

⚠ Khi nào BAC thay đổi: | Trường hợp | BAC có đổi không | |---|---| | ⚠ Dự án chậm tiến độ | ⚠ KHÔNG | | ⚠ Dự án vượt chi | ⚠ KHÔNG — vượt chi thể hiện ở AC và EAC, không ở BAC | | ⚠ Yêu cầu thay đổi phạm vi ĐƯỢC DUYỆT | ⚠ CÓ — đường cơ sở chi phí được thiết lập lại | | ⚠ Dùng dự phòng bất trắc | ⚠ KHÔNG — dự phòng đã nằm trong đường cơ sở | | ⚠ Dùng dự trữ quản lý | ⚠ CÓ — dự trữ quản lý nằm ngoài đường cơ sở, dùng tới thì đường cơ sở phải cập nhật | | ⚠ Ghi nhớ | ⚠ BAC là một CAM KẾT, không phải một dự báo — thứ dự báo là EAC; nhầm hai cái này là nhầm giữa "chúng ta được duyệt bao nhiêu" và "chúng ta sẽ tốn bao nhiêu"; liên hệ #26559 lô 196 |

⚠ Các dữ kiện thừa hay gặp trong đề EVM: | Dữ kiện | Khi nào là thừa | |---|---| | ⚠ Thời lượng dự án | ⚠ thừa nếu chỉ hỏi BAC hoặc EV | | ⚠ Phần trăm hoàn thành | ⚠ thừa nếu chỉ hỏi BAC hoặc PV | | ⚠ CPI và SPI | ⚠ thừa trong nhiều câu về rủi ro hoặc bên liên quan — liên hệ #26462 lô 194 | | ⚠ Số người trong đội | ⚠ thường chỉ để dựng bối cảnh | | ⚠ Thói quen tốt | ⚠ đọc CÂU HỎI TRƯỚC rồi mới quay lại đọc đề — làm vậy thì các dữ kiện thừa tự động rơi ra khỏi tầm chú ý |

Từ khoá nhận diện:

"BAC" → ⚠ TỔNG ngân sách được duyệt, không nhân với gì cả "phần trăm hoàn thành × ngân sách" → ⚠ cho ra EV, không phải BAC "EAC" → ⚠ dự báo chi phí cuối cùng, khác BAC dữ kiện thừa → ⚠ đọc câu hỏi trước, rồi mới lọc đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | BAC của dự án bạn là bao nhiêu, và nó có đổi lần nào chưa | | | Nếu đổi, đã qua kiểm soát thay đổi chưa | | | Bạn có phân biệt BAC với EAC khi báo cáo không | ⚠ một bên là cam kết, một bên là dự báo |

Và lý do một câu hỏi đơn giản như thế này vẫn có người sai: đề cho sẵn đáp án ngay trong câu thứ nhất, rồi thêm hai con số hấp dẫn ở câu thứ hai — và phản xạ của phần lớn người làm bài là tìm một phép tính để làm, thay vì kiểm xem có cần tính gì không.

Câu 172 Process
Khalid's latest project, the Bamboo Project, will cost his company $250,000 to complete over the next eight months. When the project is completed, the deliverables will start to earn the company $3,500 per month. Of the following choices, which is representative of the time it takes to recover project costs?
  1. A 8 months
  2. B There is not enough information to know
  3. C 5 years
  4. D 72 months
Xem giải thích

Đáp án

D — 72 THÁNG.

Vì sao đúng

⚠ Tính THỜI GIAN HOÀN VỐN: | Bước | Phép tính | Kết quả | |---|---|---| | ⚠ Chi phí dự án | ⚠ đề cho | ⚠ 250.000 đô | | ⚠ Dòng tiền thu về mỗi tháng sau khi xong | ⚠ đề cho | ⚠ 3.500 đô/tháng | | ⚠ Công thức | ⚠ chi phí ÷ dòng tiền mỗi kỳ | | | ⚠ Thay số | ⚠ 250.000 ÷ 3.500 ≈ 71,43 | ⚠ làm tròn lên: 72 THÁNG | | ⚠ Kết luận | ⚠ khớp phương án D; tương đương khoảng 6 năm | |

⚠ Vì sao làm tròn LÊN: ⚠ sau 71 tháng mới thu được 248.500 đô — vẫn chưa đủ 250.000 ⚠ — ⚠ phải sang tháng thứ 72 mới hoà vốn; ⚠ thời gian hoàn vốn luôn làm tròn lên tới kỳ đầu tiên mà dòng tiền tích luỹ đạt hoặc vượt chi phí.

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

  • C (5 năm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đáp án đúng là 72 tháng tức 6 năm, và 5 năm nghe rất gần: ⚠ nhưng ⚠ 5 năm = 60 tháng, chỉ thu được 60 × 3.500 = 210.000 đô — thiếu 40.000 ⚠; ⚠ phương án này bẫy người ước lượng thô trong đầu thay vì chia thật; ⚠ và nó còn đổi đơn vị sang NĂM trong khi mọi dữ kiện đều theo tháng — đổi đơn vị giữa chừng luôn là dấu hiệu đáng ngờ.

  • A (8 tháng) — ⚠ đó là THỜI GIAN THỰC HIỆN dự án, không phải thời gian hoàn vốn; ⚠ một con số có sẵn trong đề.

  • B (không đủ thông tin) — ⚠ đề đã cho đủ hai con số cần thiết: ⚠ chi phí và dòng tiền mỗi kỳ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26517 lô 195 (chi phí cơ hội), ⚠ #26549 lô 196 (khấu hao đường thẳng), ⚠ #26346/#26360 lô 192 (chọn dự án theo NPV), ⚠ #26613 cùng lô (BAC), ⚠ #26503/#26528 lô 195 (phân loại chi phí).

⚠ CÁC PHƯƠNG PHÁP ĐÁNH GIÁ ĐẦU TƯ — bảng so sánh: | Phương pháp | Cách chọn | Ưu điểm | Nhược điểm | |---|---|---|---| | ⚠ THỜI GIAN HOÀN VỐN | ⚠ càng NGẮN càng tốt | ⚠ dễ tính, dễ hiểu — CÂU NÀY | ⚠ bỏ qua dòng tiền SAU khi hoàn vốn và bỏ qua giá trị thời gian của tiền | | ⚠ NPV — giá trị hiện tại ròng | ⚠ càng CAO càng tốt, phải DƯƠNG | ⚠ tính cả giá trị thời gian của tiền | ⚠ cần biết tỉ lệ chiết khấu | | ⚠ IRR — tỉ suất hoàn vốn nội bộ | ⚠ càng CAO càng tốt | ⚠ so sánh được với chi phí vốn | ⚠ có thể có nhiều nghiệm | | ⚠ BCR — tỉ số lợi ích trên chi phí | ⚠ càng CAO càng tốt, phải LỚN HƠN 1 | ⚠ trực quan | ⚠ nhạy với cách tính chi phí | | ⚠ Bẫy thường gặp | ⚠ thời gian hoàn vốn CÀNG NGẮN càng tốt, còn NPV, IRR, BCR thì CÀNG CAO càng tốt — đề rất hay hỏi "chọn dự án nào" và trộn các chỉ số này với nhau | | |

⚠ Giới hạn của phương pháp thời gian hoàn vốn: | Giới hạn | Nội dung | |---|---| | ⚠ Bỏ qua mọi dòng tiền SAU điểm hoàn vốn | ⚠ một dự án hoàn vốn ở tháng 72 rồi sinh lời 20 năm sẽ bị đánh giá thấp hơn thực tế | | ⚠ Bỏ qua GIÁ TRỊ THỜI GIAN của tiền | ⚠ 3.500 đô ở tháng thứ 70 không bằng 3.500 đô hôm nay | | ⚠ Không nói gì về mức sinh lời | | | ⚠ Vì sao vẫn được dùng nhiều | ⚠ nó trả lời một câu hỏi rất thực tế: "bao lâu thì tổ chức lấy lại được tiền của mình" — đó là câu hỏi về RỦI RO THANH KHOẢN, và với công ty đang eo hẹp tiền mặt thì nó quan trọng hơn cả NPV |

⚠ Đọc kết quả 72 tháng trong bối cảnh dự án: | Nhận xét | Nội dung | |---|---| | ⚠ Dự án làm trong 8 tháng, hoàn vốn trong 72 tháng | ⚠ tổng cộng 80 tháng, gần 7 năm mới hoà | | ⚠ Đó là một thời gian rất dài với một khoản 250.000 đô | | | ⚠ Cần kiểm: dòng tiền 3.500 đô/tháng kéo dài được bao lâu | ⚠ nếu sản phẩm chỉ dùng được 5 năm thì dự án LỖ | | ⚠ Câu hỏi Khalid nên đặt tiếp | ⚠ "sản phẩm này còn tạo ra dòng tiền trong bao nhiêu năm nữa?" — vì thời gian hoàn vốn dài chỉ chấp nhận được khi vòng đời sản phẩm còn dài hơn nhiều so với nó |

Từ khoá nhận diện:

"bao lâu thu hồi được chi phí" → ⚠ chi phí ÷ dòng tiền mỗi kỳ, LÀM TRÒN LÊN "thời gian thực hiện dự án" → ⚠ dữ kiện khác, không phải thời gian hoàn vốn phương án đổi đơn vị từ tháng sang năm → ⚠ kiểm lại phép chia, thường là bẫy "thời gian hoàn vốn" → ⚠ càng NGẮN càng tốt; ngược với NPV và IRR

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn hoàn vốn sau bao lâu | | | Vòng đời sản phẩm có dài hơn thời gian hoàn vốn nhiều không | | | Tổ chức bạn dùng chỉ số nào để chọn dự án | ⚠ và bạn có biết ngưỡng chấp nhận của họ không |

Và điều mà con số 72 tháng nói với Khalid rõ hơn bất kỳ bản kế hoạch nào: dự án của anh chỉ mất tám tháng để làm xong, nhưng phải mất sáu năm nữa tổ chức mới thật sự bắt đầu có lãi từ nó — và mọi quyết định về dự án này nên được đưa ra với con số thứ hai trong đầu, không phải con số thứ nhất.

Câu 173 People
Eric is the project manager for Project ELN, which is in its fifteenth week of deployment, has a CPI of 1.01 and an SPI of .96. A portion of the project has been outsourced to a vendor. The centralized contracting of the organization has issued a purchase order and contract for the procured work. Now, the vendor has reported the completion of all their assigned project work and requested payment from Eric's organization. What should Eric do next?
  1. A Ask the project sponsor if the vendor can be paid.
  2. B Pay the vendor as the work is reported as complete.
  3. C Extend the vendor's contract for more assignments in the project.
  4. D Verify if the vendor's work was completed satisfactorily.
Xem giải thích

Đáp án

D — XÁC MINH xem công việc của nhà cung cấp đã hoàn thành ĐẠT YÊU CẦU hay chưa.

Vì sao đúng

⚠ Vì sao xác minh là việc bắt buộc trước khi thanh toán: | Lý do | Nội dung | |---|---| | ⚠ Nhà cung cấp mới chỉ BÁO CÁO là đã xong | ⚠ báo cáo không phải bằng chứng | | ⚠ Thanh toán phải dựa trên công việc ĐÃ ĐƯỢC KIỂM CHỨNG | ⚠ theo tiêu chí chấp nhận trong hợp đồng | | ⚠ Đây là quy trình KIỂM SOÁT MUA SẮM | ⚠ giám sát hiệu quả nhà cung cấp và quản lý thay đổi hợp đồng | | ⚠ Trả tiền cho việc chưa kiểm là mất đòn bẩy duy nhất còn lại | ⚠ sau khi trả thì rất khó đòi sửa | | ⚠ Sản phẩm phải qua KIỂM SOÁT CHẤT LƯỢNG và XÁC NHẬN PHẠM VI | ⚠ liên hệ #26457 lô 194 và #26420 lô 193 | | ⚠ Kết luận | ⚠ xác minh trước, thanh toán sau — không có ngoại lệ |

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

  • B (thanh toán vì công việc đã được báo cáo là hoàn thành) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nhà cung cấp đã báo xong và việc trả tiền đúng hạn là một nghĩa vụ hợp đồng nghiêm túc: ⚠ nhưng ⚠ nghĩa vụ thanh toán chỉ phát sinh khi công việc ĐƯỢC CHẤP NHẬN, không phải khi được BÁO CÁO ⚠ — ⚠ trả tiền cho một báo cáo là bỏ qua toàn bộ cơ chế bảo vệ của hợp đồng; ⚠ và nếu sau này phát hiện thiếu sót thì Eric không còn công cụ nào để yêu cầu khắc phục.

  • A (hỏi nhà tài trợ xem có được trả tiền nhà cung cấp không) — ⚠ leo thang một việc thuộc thẩm quyền của mình; ⚠ Eric có quy trình để làm việc này.

  • C (gia hạn hợp đồng để giao thêm việc) — ⚠ hoàn toàn không liên quan tới câu hỏi; ⚠ và gia hạn khi chưa kiểm chứng chất lượng công việc đã làm là quyết định rất mạo hiểm.

⚠ Chi tiết bối cảnh: ⚠ CPI 1,01 và SPI 0,96 là dữ kiện THỪA ⚠ — ⚠ chúng chỉ dựng bối cảnh một dự án gần đúng kế hoạch; ⚠ quyết định về thanh toán không phụ thuộc vào các chỉ số này; ⚠ liên hệ #26613 cùng lô về dữ kiện thừa.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26583 cùng lô (đóng hợp đồng sau khi nghiệm thu), ⚠ #26556 lô 196 (tiêu chí chấp nhận vật tư), ⚠ #26558 lô 196 (các loại hợp đồng), ⚠ #26610 cùng lô (privity), ⚠ #26420/#26429 lô 193 (Xác nhận phạm vi).

⚠ QUY TRÌNH nghiệm thu và thanh toán cho nhà cung cấp: | Bước | Nội dung | |---|---| | ⚠ 1. Nhà cung cấp báo hoàn thành | ⚠ kèm hồ sơ theo hợp đồng | | ⚠ 2. KIỂM SOÁT CHẤT LƯỢNG sản phẩm bàn giao | ⚠ đo, thử, đối chiếu quy cách — liên hệ #26457 lô 194 | | ⚠ 3. Đối chiếu với TIÊU CHÍ CHẤP NHẬN trong hợp đồng | ⚠ đáp án của câu này | | ⚠ 4. Chính thức CHẤP NHẬN hoặc yêu cầu khắc phục | ⚠ bằng văn bản | | ⚠ 5. Thanh toán theo điều khoản hợp đồng | ⚠ có thể giữ lại một phần tới hết bảo hành | | ⚠ 6. Đánh giá hiệu quả nhà cung cấp | ⚠ đưa vào dữ liệu cho các dự án sau | | ⚠ 7. ĐÓNG hợp đồng | ⚠ liên hệ #26583 cùng lô | | ⚠ Nguyên tắc | ⚠ thanh toán là ĐÒN BẨY DUY NHẤT còn lại của bên mua sau khi công việc đã làm xong — dùng nó trước khi kiểm chứng là tự tước vũ khí của mình |

⚠ Vì sao "mua sắm tập trung" trong đề là chi tiết quan trọng: | Khía cạnh | Nội dung | |---|---| | ⚠ Đơn hàng và hợp đồng do bộ phận MUA SẮM TẬP TRUNG phát hành | ⚠ không phải Eric tự ký | | ⚠ Nên việc thanh toán cũng đi qua quy trình của họ | | | ⚠ Nhưng việc XÁC MINH công việc là của DỰ ÁN | ⚠ chỉ đội dự án biết công việc có đạt hay không | | ⚠ Phân vai rõ ràng | ⚠ mua sắm lo THỦ TỤC và HỢP ĐỒNG; dự án lo XÁC MINH KỸ THUẬT — nhầm vai ở đây dẫn tới việc hoặc dự án tự ý trả tiền, hoặc mua sắm trả tiền cho thứ chưa ai kiểm |

⚠ Xác minh cụ thể là làm gì: | Việc | Nội dung | |---|---| | ⚠ Đối chiếu với TUYÊN BỐ CÔNG VIỆC trong hợp đồng | ⚠ đủ hạng mục chưa | | ⚠ Kiểm tra quy cách kỹ thuật và tiêu chí chấp nhận | | | ⚠ Rà hồ sơ phải nộp: chứng nhận, kết quả kiểm định, tài liệu | ⚠ liên hệ #26556 lô 196 | | ⚠ Kiểm tra thực tế hoặc chạy thử | | | ⚠ Lấy xác nhận của người sử dụng cuối nếu cần | | | ⚠ Nếu phát hiện thiếu sót | ⚠ ghi lại bằng văn bản, yêu cầu khắc phục theo điều khoản hợp đồng, và chỉ thanh toán phần đã đạt — làm mọi thứ bằng văn bản là điều quan trọng nhất trong giai đoạn này |

Từ khoá nhận diện:

"nhà cung cấp báo xong và xin thanh toán" → ⚠ XÁC MINH TRƯỚC "trả tiền vì họ đã báo cáo hoàn thành" → ⚠ báo cáo không phải bằng chứng "hỏi nhà tài trợ có được trả không" → ⚠ leo thang việc thuộc thẩm quyền mình "gia hạn hợp đồng" → ⚠ lạc đề và mạo hiểm khi chưa kiểm chứng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ở dự án bạn, ai xác nhận công việc nhà cung cấp đã đạt | | | Việc xác nhận đó có được ghi bằng văn bản không | | | Hợp đồng của bạn có điều khoản giữ lại một phần thanh toán không | |

Và lý do bước xác minh không bao giờ nên bỏ qua dù nhà cung cấp có đáng tin tới đâu: không phải vì bạn nghi ngờ họ, mà vì sau khi tiền đã chuyển đi, "đạt yêu cầu" trở thành một chuyện để thương lượng thay vì một điều kiện để thanh toán.

Câu 174 Process
Lucas, the project manager for the Clocks Project, is creating a schedule duration estimate for the project's activities. To predict the schedule, Lucas and his project team compare the results of a past project similar to the Clocks Project. Lucas is using which estimating approach?
  1. A Parametric
  2. B Analogous
  3. C Organizational process assets
  4. D PERT
Xem giải thích

Đáp án

B — Ước lượng TƯƠNG TỰ (analogous).

Vì sao đúng

⚠ Vì sao đây là ước lượng tương tự: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ SO SÁNH với một dự án ĐÃ QUA và TƯƠNG TỰ | ⚠ định nghĩa trực tiếp của kỹ thuật này | | ⚠ Dùng kết quả thật của dự án cũ làm cơ sở | ⚠ dữ liệu lịch sử | | ⚠ Ước lượng ở mức TỔNG THỂ, từ TRÊN XUỐNG | ⚠ không phân rã từng hoạt động | | ⚠ Nhanh và ít tốn công | ⚠ đánh đổi bằng độ chính xác thấp hơn | | ⚠ Kết luận | ⚠ thuật ngữ chuẩn cho việc "lấy dự án cũ tương tự làm chuẩn" |

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

  • A (THAM SỐ — parametric) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng dựa trên dữ liệu lịch sử và cũng là kỹ thuật ước lượng chính thức: ⚠ nhưng ⚠ tham số dùng một QUAN HỆ THỐNG KÊ: ĐƠN GIÁ × KHỐI LƯỢNG ⚠ — ví dụ "0,5 giờ mỗi mét vuông × 2.000 mét vuông"; ⚠ đề không nói tới bất kỳ định mức đơn vị nào, chỉ nói SO SÁNH TỔNG THỂ với một dự án; ⚠ mẹo phân biệt: có ĐƠN GIÁ và KHỐI LƯỢNG thì là tham số; chỉ có "dự án cũ giống thế này" thì là tương tự.

  • D (PERT) — ⚠ là ước lượng BA ĐIỂM với trọng số cho giá trị khả dĩ nhất; ⚠ đề không nhắc tới ba con số lạc quan – khả dĩ – bi quan; ⚠ liên hệ #26522 lô 195.

  • C (tài sản quy trình tổ chức) — ⚠ là một NGUỒN DỮ LIỆU, không phải một KỸ THUẬT ước lượng; ⚠ dữ liệu dự án cũ đúng là nằm ở đó, nhưng đề hỏi cách tiếp cận ước lượng nào; ⚠ lỗi lạc phạm trù — liên hệ #26503 lô 195.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26519 lô 195 (ước lượng tương tự kém chính xác hơn — câu bổ trợ trực tiếp), ⚠ #26522 lô 195 (ba điểm và PERT), ⚠ #26492 lô 195 (CSDL định mức thương mại), ⚠ #26502 lô 195 (đầu vào của ước lượng thời lượng), ⚠ #26577 lô 196 (WBS là đầu vào của ước lượng chi phí).

⚠ CÁC KỸ THUẬT ƯỚC LƯỢNG — bảng phân biệt: | Kỹ thuật | Cách làm | Dấu hiệu nhận diện trong đề | |---|---|---| | ⚠ TƯƠNG TỰ (analogous) | ⚠ lấy dự án cũ GIỐNG làm chuẩn, điều chỉnh | ⚠ "dự án tương tự", "so sánh với lần trước" — CÂU NÀY | | ⚠ THAM SỐ (parametric) | ⚠ đơn giá × khối lượng | ⚠ "X giờ mỗi đơn vị", "Y đô mỗi mét vuông" | | ⚠ BA ĐIỂM (PERT/tam giác) | ⚠ lạc quan, khả dĩ nhất, bi quan | ⚠ ba con số O, M, P | | ⚠ TỪ DƯỚI LÊN | ⚠ ước từng gói công việc rồi cộng | ⚠ "chi tiết từng hoạt động", "cộng lại" | | ⚠ PHÁN ĐOÁN CHUYÊN GIA | ⚠ hỏi người có kinh nghiệm | ⚠ "tham vấn chuyên gia" — bổ trợ cho mọi kỹ thuật | | ⚠ Sắp xếp theo độ chính xác | ⚠ từ dưới lên > tham số ≈ ba điểm > tương tự — liên hệ #26519 lô 195 | |

⚠ ƯỚC LƯỢNG TƯƠNG TỰ — dùng đúng cách: | Việc | Nội dung | |---|---| | ⚠ Chọn dự án tham chiếu THẬT SỰ giống | ⚠ giống về quy mô, công nghệ, đội, bối cảnh — không chỉ giống tên | | ⚠ ĐIỀU CHỈNH cho các khác biệt đã biết | ⚠ quy mô gấp đôi không có nghĩa thời gian gấp đôi | | ⚠ Kết hợp với phán đoán chuyên gia | ⚠ người từng làm dự án cũ biết chỗ nào khác | | ⚠ CÔNG BỐ RÕ mức sai số | ⚠ liên hệ #26291 lô 191 — bậc độ lớn thô | | ⚠ Cam kết ước lượng lại khi có thêm thông tin | ⚠ liên hệ #26448 lô 194 | | ⚠ Khi nào nó là lựa chọn đúng | ⚠ giai đoạn ĐẦU, ít thông tin, cần con số nhanh để quyết định có làm dự án hay không — dùng nó ở giai đoạn cam kết ngân sách chính thức mới là sai |

⚠ Vì sao Lucas làm việc này CÙNG ĐỘI là điểm cộng: | Lý do | Nội dung | |---|---| | ⚠ Đội biết chỗ nào dự án mới KHÁC dự án cũ | ⚠ điều chỉnh sẽ sát hơn | | ⚠ Nhiều góc nhìn giảm thiên kiến lạc quan | ⚠ liên hệ #26448 lô 194 | | ⚠ Đội cam kết hơn với con số họ tham gia đặt ra | | | ⚠ So sánh với #26448 lô 194 | ⚠ ở đó Darrell ước lượng MỘT MÌNH và đó là rủi ro; ở đây Lucas làm cùng đội — hai câu tạo thành một cặp đối lập đáng nhớ về cùng một chủ đề |

Từ khoá nhận diện:

"so sánh với dự án tương tự đã qua" → ⚠ ƯỚC LƯỢNG TƯƠNG TỰ "đơn giá nhân khối lượng" → ⚠ tham số "lạc quan, khả dĩ nhất, bi quan" → ⚠ ba điểm / PERT "tài sản quy trình tổ chức" → ⚠ nguồn dữ liệu, không phải kỹ thuật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng của bạn dựa trên dự án cũ nào, và nó giống tới mức nào | | | Bạn có điều chỉnh cho các khác biệt đã biết không | | | Bạn có công bố mức sai số kèm con số không | ⚠ liên hệ #26519 lô 195 |

Và điều khiến ước lượng tương tự vừa hữu ích vừa nguy hiểm: nó cho ra một con số rất nhanh và nghe rất có cơ sở — nên nó thường sống sót qua nhiều tháng sau khi lẽ ra đã phải được thay bằng một ước lượng tử tế hơn.

Câu 175 People
Elijah is a new project manager at Sunflower Construction. Lucas, Elijah's manager, has asked him to read the Agile Manifesto. Several parts of the Manifesto highlight working collaboratively. Elijah finds that his manager engages stakeholders much more frequently during the project than he has seen in past projects. How does the manager, Lucas, find this practice beneficial?
  1. A It is Lucas' belief that frequent meetings are a good respite from heads-down work.
  2. B All stakeholders will become better acquainted with each other.
  3. C Frequent stakeholder engagement allows the team to develop stronger problem-solving skills, receive valuable ideas and input, and take ownership.
  4. D Instead of being singled out for overstepping boundaries, the stakeholders stay in their own lanes.
Xem giải thích

Đáp án

C — Gắn kết bên liên quan thường xuyên giúp đội PHÁT TRIỂN KỸ NĂNG GIẢI QUYẾT VẤN ĐỀ, NHẬN ĐƯỢC Ý TƯỞNG VÀ ĐÓNG GÓP GIÁ TRỊ, và LÀM CHỦ công việc.

Vì sao đúng

⚠ Ba lợi ích trong phương án đều là lợi ích thật: | Lợi ích | Nội dung | |---|---| | ⚠ Kỹ năng GIẢI QUYẾT VẤN ĐỀ tốt hơn | ⚠ đội phải trả lời câu hỏi thật từ người dùng thật, thường xuyên | | ⚠ Nhận được Ý TƯỞNG và ĐÓNG GÓP có giá trị | ⚠ bên liên quan biết những điều đội không biết | | ⚠ LÀM CHỦ công việc | ⚠ hiểu vì sao mình làm thì cam kết cao hơn hẳn | | ⚠ Khớp với Tuyên ngôn Agile | ⚠ "hợp tác với khách hàng hơn là đàm phán hợp đồng" | | ⚠ Phản hồi sớm và liên tục làm giảm rủi ro | ⚠ phát hiện hiểu sai khi còn rẻ để sửa | | ⚠ Kết luận | ⚠ phương án duy nhất nêu LỢI ÍCH THỰC CHẤT cho dự án |

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

  • B (mọi bên liên quan sẽ hiểu nhau hơn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đó là một lợi ích PHỤ có thật của việc gặp nhau thường xuyên: ⚠ nhưng ⚠ nó không phải LÝ DO của thực hành này ⚠ — ⚠ mục đích của việc gắn kết bên liên quan là làm ra SẢN PHẨM ĐÚNG, không phải để mọi người thân nhau hơn; ⚠ đây là cùng một dạng bẫy "tác dụng phụ đội lốt mục đích" với #26456 lô 194 và #26572 lô 196.

  • A (Lucas tin rằng họp thường xuyên là dịp nghỉ ngơi khỏi công việc tập trung) — ⚠ biến một thực hành có chủ đích thành sở thích cá nhân; ⚠ và họp KHÔNG phải nghỉ ngơi — liên hệ #26591 cùng lô về nhu cầu tập trung sâu.

  • D (bên liên quan sẽ ở yên trong phần việc của mình thay vì lấn sang việc khác) — ⚠ mô tả một mục đích KIỂM SOÁT, trái hẳn tinh thần hợp tác của agile.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26569 lô 196 (quyết định tập thể trong agile), ⚠ #26542 lô 196 (chủ sản phẩm thương lượng với đội), ⚠ #26608 cùng lô (bên liên quan quan tâm cao), ⚠ #26596 cùng lô (kế hoạch giao tiếp), ⚠ #26483 lô 195 (hội thảo yêu cầu).

⚠ VÌ SAO agile đòi gắn kết bên liên quan liên tục: | Lý do | Nội dung | |---|---| | ⚠ Yêu cầu KHÔNG được chốt từ đầu | ⚠ nên phải liên tục kiểm chứng hiểu biết | | ⚠ Phản hồi sớm rẻ hơn nhiều so với sửa muộn | ⚠ liên hệ quy tắc 1–10–100 ở #26461 lô 194 | | ⚠ Bên liên quan thấy tiến triển thật, không chỉ báo cáo | ⚠ buổi rà soát sprint là bằng chứng sống | | ⚠ Đội hiểu NGỮ CẢNH, không chỉ hiểu yêu cầu | ⚠ nhờ đó ra quyết định tốt hơn khi gặp tình huống ngoài dự kiến | | ⚠ Giảm rủi ro làm sai thứ | ⚠ rủi ro tốn kém nhất trong mọi dự án phần mềm | | ⚠ So sánh với thác nước | ⚠ thác nước gặp bên liên quan nhiều ở ĐẦU và CUỐI; agile gặp SUỐT — đó là khác biệt mà Elijah đang quan sát thấy |

⚠ Vì sao "làm chủ công việc" là lợi ích đáng giá nhất: | Khía cạnh | Nội dung | |---|---| | ⚠ Đội biết VÌ SAO một tính năng quan trọng | ⚠ không chỉ biết phải làm gì | | ⚠ Họ tự ra được quyết định nhỏ mà không cần hỏi | ⚠ giảm độ trễ, giảm tải cho chủ sản phẩm | | ⚠ Họ đề xuất phương án tốt hơn thay vì làm đúng yêu cầu | ⚠ liên hệ #26542 lô 196 | | ⚠ Động lực nội tại tăng | ⚠ liên hệ #26567 lô 196 — Thuyết Y | | ⚠ Điều kiện để có được | ⚠ đội phải được TIẾP XÚC TRỰC TIẾP với bên liên quan, không qua trung gian — mọi lớp trung gian đều lọc bớt ngữ cảnh, và ngữ cảnh mới là thứ tạo ra quyền làm chủ |

⚠ Gắn kết thường xuyên — làm sao để không thành gánh nặng: | Việc | Nội dung | |---|---| | ⚠ Có NHỊP cố định: rà soát sprint, buổi làm rõ backlog | ⚠ thay vì họp bất chợt | | ⚠ Mỗi buổi có MỤC TIÊU rõ | ⚠ liên hệ #26557 lô 196 | | ⚠ Mời đúng người cho đúng chủ đề | ⚠ không phải ai cũng dự mọi buổi — liên hệ #26608 cùng lô | | ⚠ Cho bên liên quan thấy phản hồi của họ được dùng | ⚠ nếu không, họ sẽ ngừng đến | | ⚠ Rủi ro nếu làm quá | ⚠ đội bị gián đoạn liên tục và mất thời gian tập trung sâu — cân bằng là việc của scrum master, liên hệ #26591 cùng lô về hang và sân chung |

Từ khoá nhận diện:

"gắn kết bên liên quan thường xuyên có lợi gì" → ⚠ GIẢI QUYẾT VẤN ĐỀ TỐT HƠN, Ý TƯỞNG GIÁ TRỊ, LÀM CHỦ CÔNG VIỆC "mọi người quen nhau hơn" → ⚠ tác dụng phụ, không phải mục đích "họp là dịp nghỉ ngơi" → ⚠ biến thực hành có chủ đích thành sở thích "để bên liên quan không lấn việc" → ⚠ mục đích kiểm soát, trái tinh thần agile

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có tiếp xúc trực tiếp với người dùng thật không | ⚠ hay chỉ nhận yêu cầu qua trung gian | | Bên liên quan có thấy phản hồi của họ dẫn tới thay đổi không | | | Đội bạn có giải thích được VÌ SAO họ đang làm tính năng hiện tại không | |

Và điều mà Elijah sẽ nhận ra sau vài tháng làm việc theo cách của Lucas: một đội được nói chuyện thường xuyên với người sẽ dùng sản phẩm sẽ tự động làm ra thứ tốt hơn — không phải vì họ chăm chỉ hơn, mà vì họ thôi phải đoán.

Câu 176 Process
Denise wants to collocate with her team on their agile project. This means that:
  1. A None of the above.
  2. B Her team is physically together, with walls between the functional groups.
  3. C Her team is physically together without any barriers or walls between them or is virtually collocated if any team members are remote.
  4. D Her team is physically together without barriers or walls, as agile teams cannot be remotely located.
Xem giải thích

Đáp án

C — Đội ở cùng một nơi VẬT LÝ, KHÔNG có vách ngăn hay tường giữa họ; HOẶC cùng chỗ ẢO nếu có thành viên làm từ xa.

⚠ Đối chiếu bắt buộc — câu GẦN TRÙNG với #26467 lô 194: ⚠ cùng hỏi định nghĩa "cùng chỗ" (collocated) ⚠ — ⚠ ở #26467, đáp án nhấn vào ngưỡng vật lý: trong khoảng 10 mét (33 feet) và KHÔNG có vách ngăn; ⚠ ở câu này, đáp án nhấn vào không có vách ngăn, VÀ bổ sung khái niệm CÙNG CHỖ ẢO cho đội có người từ xa. ⚠ Hash MD5 không bắt được; hai khoá KHÔNG mâu thuẫn — chúng bổ sung cho nhau, một câu cho ngưỡng vật lý, một câu mở rộng khái niệm sang môi trường ảo.

Vì sao đúng

⚠ Hai yếu tố làm phương án này đúng: | Yếu tố | Nội dung | |---|---| | ⚠ Cùng một nơi vật lý, KHÔNG vách ngăn | ⚠ điều kiện cho giao tiếp thẩm thấu — liên hệ #26467 lô 194 | | ⚠ "HOẶC cùng chỗ ẢO nếu có người ở xa" | ⚠ chi tiết QUYẾT ĐỊNH — đây là điều làm nó khác các phương án kia | | ⚠ Cùng chỗ ảo: công cụ mô phỏng sự gần gũi | ⚠ kênh video luôn mở, bảng chung, chat tức thời | | ⚠ Thực tế hiện nay hiếm đội nào hoàn toàn cùng chỗ | ⚠ nên khái niệm đã được mở rộng | | ⚠ Kết luận | ⚠ định nghĩa đầy đủ nhất và phản ánh đúng thực tế |

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

  • D (cùng một nơi, không vách ngăn, vì đội agile KHÔNG THỂ ở xa) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nửa đầu HOÀN TOÀN ĐÚNG và trùng với #26467 lô 194: ⚠ nhưng ⚠ mệnh đề "đội agile không thể làm việc từ xa" là SAI ⚠ — ⚠ hàng nghìn đội agile phân tán vẫn hoạt động hiệu quả; ⚠ lại một lần nữa, một phương án đúng nửa đầu nhưng chứa một khẳng định tuyệt đối sai ở nửa sau vẫn là phương án sai — cùng dạng với #26576 lô 196.

  • B (cùng một nơi nhưng CÓ TƯỜNG giữa các nhóm chức năng) — ⚠ vách ngăn PHÁ VỠ chính lợi ích của việc cùng chỗ; ⚠ liên hệ #26591 cùng lô — mô hình hang và sân chung mới là cách xử lý đúng nhu cầu yên tĩnh.

  • A (không phương án nào đúng) — ⚠ sai vì phương án C đúng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26467 lô 194 (ngưỡng 10 mét, không vách ngăn), ⚠ #26554 lô 196 (lợi ích của cùng chỗ), ⚠ #26527 lô 195 (cái nào KHÔNG phải đội ảo), ⚠ #26591 cùng lô (hang và sân chung), ⚠ #26589 cùng lô (ghép cặp trong đội phân tán).

⚠ CÙNG CHỖ — ba mức: | Mức | Đặc điểm | Chất lượng giao tiếp | |---|---|---| | ⚠ CÙNG CHỖ VẬT LÝ | ⚠ trong khoảng 10 mét, không vách ngăn | ⚠ cao nhất — liên hệ #26467 lô 194 | | ⚠ CÙNG CHỖ ẢO | ⚠ phân tán nhưng dùng công cụ mô phỏng sự gần gũi | ⚠ thấp hơn nhưng có thể rất tốt nếu làm có chủ ý | | ⚠ PHÂN TÁN thông thường | ⚠ không có nỗ lực đặc biệt nào | ⚠ thấp — liên hệ #26512 lô 195 | | ⚠ Khác biệt then chốt | ⚠ cùng chỗ ẢO khác PHÂN TÁN ở chỗ CÓ CHỦ Ý: đội cố tình dựng những điều kiện mà đội cùng chỗ có được miễn phí | |

⚠ CÙNG CHỖ ẢO — dựng bằng cách nào: | Công cụ / thực hành | Mô phỏng điều gì | |---|---| | ⚠ Kênh video LUÔN MỞ trong giờ làm | ⚠ cảm giác ngồi cùng phòng, quay sang là hỏi được | | ⚠ Kênh chat tức thời của đội | ⚠ giao tiếp thẩm thấu — nghe được vấn đề của người khác | | ⚠ Bảng công việc điện tử ai cũng thấy | ⚠ bảng thông tin trên tường — liên hệ #26530 lô 195 | | ⚠ Ghép cặp làm việc từ xa | ⚠ liên hệ #26589 cùng lô | | ⚠ Giờ làm việc trùng nhau được thoả thuận | ⚠ liên hệ #26512 lô 195 | | ⚠ Điều kiện tiên quyết | ⚠ những thứ này chỉ hoạt động khi cả đội đồng ý và duy trì — một kênh video mở mà không ai bật camera thì chỉ là một biểu tượng trên màn hình |

⚠ Vì sao vách ngăn là kẻ thù của cùng chỗ: | Lý do | Nội dung | |---|---| | ⚠ Chặn giao tiếp thẩm thấu | ⚠ không nghe được vấn đề của người khác | | ⚠ Tạo ranh giới tâm lý giữa các nhóm chức năng | ⚠ đúng điều phương án B mô tả — và đó là mô hình phòng ban, không phải đội | | ⚠ Làm chậm việc hỏi đáp | ⚠ phải đứng dậy, đi vòng, gõ cửa | | ⚠ Nhưng nhu cầu yên tĩnh là thật | ⚠ và cách giải quyết đúng KHÔNG phải dựng vách ngăn cố định, mà là mô hình HANG VÀ SÂN CHUNG — liên hệ #26591 cùng lô |

Từ khoá nhận diện:

"cùng một nơi, không vách ngăn, hoặc cùng chỗ ảo nếu có người ở xa" → ⚠ ĐỊNH NGHĨA ĐẦY ĐỦ "đội agile không thể làm từ xa" → ⚠ khẳng định SAI, làm hỏng cả phương án "có tường giữa các nhóm chức năng" → ⚠ phá vỡ chính lợi ích của cùng chỗ "trong khoảng 10 mét" → ⚠ ngưỡng vật lý — #26467 lô 194

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn cùng chỗ vật lý, cùng chỗ ảo, hay chỉ đơn giản là phân tán | | | Nếu có người ở xa, bạn có làm gì để mô phỏng sự gần gũi không | | | Có vách ngăn nào giữa những người cần trao đổi hằng ngày không | |

Và điều mà việc bổ sung khái niệm "cùng chỗ ảo" thừa nhận: agile được thiết kế cho một thế giới mà cả đội ngồi cùng một phòng — và vì thế giới đó không còn phổ biến nữa, phần khó nhất của agile hiện đại là tái tạo lại bằng công cụ những gì một căn phòng từng cho không.

Câu 177 Process
Your colleague, Jesse, is away on vacation, and he left you in charge of his projects. A sudden and significant opportunity presents itself, putting your organization at a great advantage. Still, you need to submit a request for a proposal by the end of the day to meet the submission deadline. You need to act quickly but have no way to reach Jesse to determine where the documents are kept. However, you have access to the project folders within the company's cloud storage system. In which folder are you most likely to find the source selection criteria, procurement statement of work, and a list of potential sellers?
  1. A Bid documents
  2. B Procurement documentation
  3. C Product requirements documents
  4. D Source Selection Criteria
Xem giải thích

Đáp án

B — Thư mục TÀI LIỆU MUA SẮM (procurement documentation).

Vì sao đúng

⚠ Vì sao ba thứ cần tìm đều nằm ở đây: | Tài liệu cần tìm | Thuộc nhóm | |---|---| | ⚠ TIÊU CHÍ CHỌN NGUỒN (source selection criteria) | ⚠ tài liệu mua sắm | | ⚠ TUYÊN BỐ CÔNG VIỆC MUA SẮM (procurement SOW) | ⚠ tài liệu mua sắm | | ⚠ DANH SÁCH NHÀ CUNG CẤP TIỀM NĂNG | ⚠ tài liệu mua sắm | | ⚠ Cả ba là ĐẦU RA của quy trình Lập kế hoạch quản lý mua sắm | ⚠ nên được lưu cùng một chỗ | | ⚠ Kết luận | ⚠ thư mục bao trùm cả ba, không phải một trong ba |

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

  • D (Tiêu chí chọn nguồn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là tên của CHÍNH MỘT trong ba thứ cần tìm, nên xuất hiện rất nổi bật: ⚠ nhưng ⚠ nó chỉ chứa MỘT trong ba ⚠ — ⚠ câu hỏi cần một thư mục chứa CẢ BA; ⚠ đây là bẫy lấy tên một thành phần đặt cạnh tên của cái bao trùm, và người đọc vội sẽ chọn cái tên mình vừa nhìn thấy trong câu hỏi.

  • A (Tài liệu mời thầu — bid documents) — ⚠ là RFI, RFP, RFQ, tức các tài liệu GỬI RA cho nhà cung cấp; ⚠ chúng là một phần của tài liệu mua sắm, nhưng không chứa tiêu chí chọn nguồn nội bộ hay danh sách nhà cung cấp tiềm năng; ⚠ liên hệ #26531 lô 195.

  • C (Tài liệu yêu cầu sản phẩm) — ⚠ mô tả sản phẩm cần đạt được, thuộc lĩnh vực Phạm vi; ⚠ hoàn toàn khác nhóm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26531 lô 195 (RFI, RFQ, RFP, SOW — bảng phân biệt tài liệu mời thầu), ⚠ #26558 lô 196 (các loại hợp đồng), ⚠ #26615 cùng lô (xác minh trước khi thanh toán), ⚠ #26583 cùng lô (đóng hợp đồng), ⚠ #26565 lô 196 (trần cho hợp đồng T&M).

⚠ TÀI LIỆU MUA SẮM — thư mục này chứa gì: | Tài liệu | Nội dung | |---|---| | ⚠ Kế hoạch quản lý mua sắm | ⚠ cách dự án sẽ mua sắm: loại hợp đồng, ngưỡng, vai trò | | ⚠ TUYÊN BỐ CÔNG VIỆC MUA SẮM (SOW) | ⚠ mô tả chính xác thứ cần mua — liên hệ #26531 lô 195 | | ⚠ TIÊU CHÍ CHỌN NGUỒN | ⚠ chấm nhà cung cấp theo gì, trọng số bao nhiêu | | ⚠ DANH SÁCH NHÀ CUNG CẤP tiềm năng | | | ⚠ Tài liệu mời thầu: RFI, RFP, RFQ | ⚠ phương án A — một phần của nhóm này | | ⚠ Ước lượng chi phí độc lập | ⚠ để so với báo giá nhận về | | ⚠ Hợp đồng đã ký và các phụ lục | | | ⚠ Ghi nhớ về cấu trúc | ⚠ "tài liệu mua sắm" là THƯ MỤC BAO TRÙM; RFP, SOW, tiêu chí chọn nguồn đều nằm bên trong — nhầm một thành phần với cả nhóm là lỗi phổ biến nhất trong lĩnh vực này |

⚠ TIÊU CHÍ CHỌN NGUỒN — thứ đang gấp nhất với bạn: | Khía cạnh | Nội dung | |---|---| | ⚠ Là gì | ⚠ bộ tiêu chí và trọng số để chấm các đề xuất nhận được | | ⚠ Ví dụ tiêu chí | ⚠ giá, năng lực kỹ thuật, kinh nghiệm tương tự, tình hình tài chính, cách tiếp cận, đội ngũ đề xuất | | ⚠ Phải xác định TRƯỚC khi nhận đề xuất | ⚠ để việc chấm khách quan và bảo vệ được | | ⚠ Thường có trọng số cho từng tiêu chí | | | ⚠ Vì sao quan trọng với tình huống này | ⚠ bạn đang nộp một đề xuất gấp — biết tiêu chí chọn nguồn của lần trước giúp hiểu tổ chức thường đánh giá theo gì, và tránh phải phát minh lại từ đầu trong vài giờ |

⚠ Bài học tổ chức ẩn trong tình huống: | Quan sát | Nội dung | |---|---| | ⚠ Jesse đi nghỉ và không ai biết tài liệu ở đâu | ⚠ tri thức về CẤU TRÚC LƯU TRỮ đang nằm trong đầu một người | | ⚠ May mắn là có kho lưu trữ đám mây dùng chung | ⚠ nếu tài liệu nằm ở máy cá nhân thì đã hỏng | | ⚠ Nhưng cấu trúc thư mục không hiển nhiên với người ngoài | | | ⚠ Việc tổ chức nên làm | ⚠ chuẩn hoá cấu trúc thư mục dự án — đó là một TÀI SẢN QUY TRÌNH đơn giản mà hiệu quả bất ngờ; liên hệ #26511 lô 195 và #26543 lô 196 | | ⚠ Với cá nhân | ⚠ trước khi đi nghỉ dài, để lại một trang ghi chú về nơi lưu các tài liệu quan trọng — tốn mười phút và tiết kiệm cho đồng nghiệp cả buổi chiều như hôm nay |

Từ khoá nhận diện:

"tiêu chí chọn nguồn + SOW mua sắm + danh sách nhà cung cấp" → ⚠ THƯ MỤC TÀI LIỆU MUA SẮM "tiêu chí chọn nguồn" → ⚠ chỉ MỘT trong ba thứ cần tìm, không phải thư mục bao trùm "tài liệu mời thầu" → ⚠ RFI/RFP/RFQ, một phần của tài liệu mua sắm "tài liệu yêu cầu sản phẩm" → ⚠ thuộc lĩnh vực Phạm vi, khác nhóm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu dự án của bạn có cấu trúc thư mục chuẩn không | | | Nếu bạn nghỉ một tuần, đồng nghiệp có tìm được tài liệu quan trọng không | | | Tiêu chí chọn nguồn của bạn được viết trước hay sau khi nhận đề xuất | ⚠ sau là mất tính khách quan |

Và điều mà một buổi chiều đi tìm tài liệu của người khác dạy rõ hơn mọi khoá đào tạo về quản lý tri thức: một tổ chức không có cấu trúc lưu trữ chung không phải là tổ chức thiếu tài liệu — nó là tổ chức mà mỗi tài liệu chỉ tìm được bởi đúng người đã tạo ra nó.

Câu 178 Process
Mia is working on a new project with Bolt Consulting. One of the project stakeholders wants to know why she considers the scope statement so important in the methodology of project management. How does Mia answer the stakeholder's question?
  1. A Before any change authorization, the plan must be consulted.
  2. B Before a change is approved or declined, the project manager must document the change.
  3. C The EVM and project plan must work together to assess the risk involved with proposed changes.
  4. D The project scope statement guides all change requests to decide if the change is in or out of scope.
Xem giải thích

Đáp án

D — Tuyên bố phạm vi dự án DẪN ĐƯỜNG cho mọi yêu cầu thay đổi, để quyết định thay đổi đó NẰM TRONG hay NGOÀI phạm vi.

Vì sao đúng

⚠ Vì sao đây là vai trò then chốt của tuyên bố phạm vi: | Lý do | Nội dung | |---|---| | ⚠ Nó định nghĩa RANH GIỚI của dự án | ⚠ cái gì thuộc phạm vi, cái gì không | | ⚠ Mọi yêu cầu thay đổi đều phải đối chiếu với nó | ⚠ đó là chuẩn để đo | | ⚠ Không có nó thì không phân biệt được thay đổi với ĐỘN PHẠM VI | ⚠ liên hệ #26524 lô 195 | | ⚠ Nó chứa cả PHẠM VI LOẠI TRỪ | ⚠ những gì dự án CỐ Ý không làm — phần quan trọng và hay bị bỏ | | ⚠ Nó là căn cứ để nghiệm thu sản phẩm | ⚠ liên hệ #26420 lô 193 — Xác nhận phạm vi | | ⚠ Kết luận | ⚠ phương án duy nhất nói tới VAI TRÒ của tuyên bố phạm vi trong quản lý thay đổi |

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

  • A (trước khi phê duyệt bất kỳ thay đổi nào, phải tham chiếu KẾ HOẠCH) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó ĐÚNG về nguyên tắc — kế hoạch quản lý dự án đúng là phải được tham chiếu: ⚠ nhưng ⚠ câu hỏi hỏi riêng về TUYÊN BỐ PHẠM VI, và phương án này nói về "kế hoạch" nói chung ⚠ — ⚠ đây là bẫy phương án bao trùm thay cho phương án cụ thể, cùng dạng với #26453 lô 194 và #26577 lô 196.

  • B (trước khi duyệt hay từ chối, quản lý dự án phải TÀI LIỆU HOÁ thay đổi) — ⚠ đúng về quy trình nhưng ⚠ nói về việc GHI CHÉP, không nói về vai trò của tuyên bố phạm vi.

  • C (EVM và kế hoạch dự án phải phối hợp để đánh giá rủi ro của thay đổi) — ⚠ trộn lẫn các khái niệm; ⚠ EVM đo hiệu năng, không dùng để quyết định thay đổi có trong phạm vi hay không.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26524 lô 195 (công việc ngoài phạm vi → dừng và nộp yêu cầu thay đổi), ⚠ #26577 lô 196 (WBS là đầu vào ước lượng chi phí), ⚠ #26511 lô 195 (WBS thuộc đường cơ sở phạm vi), ⚠ #26497 lô 195 (yêu cầu thay đổi dồn dập), ⚠ #26420 lô 193 (Xác nhận phạm vi).

⚠ TUYÊN BỐ PHẠM VI DỰ ÁN chứa gì: | Nội dung | Chi tiết | |---|---| | ⚠ Mô tả phạm vi sản phẩm | ⚠ đặc tính của sản phẩm hoặc dịch vụ | | ⚠ Sản phẩm bàn giao chính | | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ điều kiện để sản phẩm được nghiệm thu | | ⚠ PHẠM VI LOẠI TRỪ | ⚠ những gì dự án KHÔNG làm — mục ngăn tranh cãi hiệu quả nhất | | ⚠ Ràng buộc | ⚠ liên hệ #26487 lô 195 | | ⚠ Giả định | ⚠ liên hệ #26495 lô 195 | | ⚠ Vị trí trong đường cơ sở | ⚠ ĐƯỜNG CƠ SỞ PHẠM VI = tuyên bố phạm vi + WBS + từ điển WBS — cả ba cùng nhau, và mọi thay đổi phạm vi đều phải cập nhật đủ ba |

⚠ Vì sao mục PHẠM VI LOẠI TRỪ lại quan trọng bất ngờ: | Lý do | Nội dung | |---|---| | ⚠ Nó ngăn tranh cãi "tôi tưởng cái đó cũng thuộc dự án" | | | ⚠ Nó làm lộ ra hiểu lầm NGAY Ở KHÂU LẬP KẾ HOẠCH | ⚠ khi sửa còn rẻ | | ⚠ Nó là cơ sở rõ ràng nhất để nói "không" một cách lịch sự | | | ⚠ Nhưng nó thường bị bỏ trống vì viết ra rất mất công | | | ⚠ Mẹo thực dụng | ⚠ mỗi lần có người hỏi "cái này có nằm trong dự án không?" thì dù câu trả lời là gì, hãy ghi câu trả lời đó vào tuyên bố phạm vi — sau vài lần bạn sẽ có một mục loại trừ rất giá trị |

⚠ Vai trò của tuyên bố phạm vi trong KIỂM SOÁT THAY ĐỔI: | Bước | Nội dung | |---|---| | ⚠ 1. Nhận yêu cầu thay đổi | | | ⚠ 2. Đối chiếu với TUYÊN BỐ PHẠM VI | ⚠ trong phạm vi hay ngoài phạm vi — đáp án của câu này | | ⚠ 3a. Nếu TRONG phạm vi | ⚠ có thể chỉ là làm rõ, không cần thay đổi đường cơ sở | | ⚠ 3b. Nếu NGOÀI phạm vi | ⚠ phải phân tích tác động và đi qua kiểm soát thay đổi đầy đủ | | ⚠ 4. Phân tích tác động lên thời gian, chi phí, chất lượng, rủi ro | | | ⚠ 5. Duyệt hoặc từ chối, rồi cập nhật đường cơ sở nếu duyệt | | | ⚠ Vì sao bước 2 là bước then chốt | ⚠ nó quyết định toàn bộ quy trình còn lại; không có tuyên bố phạm vi rõ ràng thì mọi yêu cầu đều trở thành một cuộc thương lượng, và người kiên trì nhất sẽ thắng — đó chính là cơ chế sinh ra độn phạm vi |

Từ khoá nhận diện:

"tuyên bố phạm vi quan trọng vì sao" → ⚠ DẪN ĐƯỜNG cho việc xác định thay đổi TRONG hay NGOÀI phạm vi "tham chiếu kế hoạch" → ⚠ đúng nhưng quá bao trùm khi câu hỏi hỏi về tuyên bố phạm vi "tài liệu hoá thay đổi" → ⚠ nói về quy trình ghi chép, không nói về vai trò của tài liệu này "EVM đánh giá rủi ro của thay đổi" → ⚠ trộn lẫn khái niệm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyên bố phạm vi của bạn có mục PHẠM VI LOẠI TRỪ không | | | Khi có yêu cầu mới, bạn đối chiếu với cái gì | ⚠ hay chỉ dựa vào cảm nhận | | Có tranh cãi nào ở dự án bạn về việc "cái này có thuộc dự án không" chưa | ⚠ mỗi lần như vậy là một dòng cần thêm vào tuyên bố phạm vi |

Và lý do Mia coi tuyên bố phạm vi là quan trọng đến vậy: nó là tài liệu duy nhất cho phép bạn nói "không" mà không phải dựa vào quyền lực của mình — bạn chỉ cần chỉ vào một trang giấy mà chính người đang hỏi đã từng đồng ý.

Câu 179 Process
Your firm has experienced a challenging quarter due to marketplace conditions. The organizational income has affected all of the projects that were expected to be completed. After meeting with several stakeholders, you have found a significant bottleneck in procurement, causing schedule impacts. There is only one person in the procurement office who is authorized to approve any company charges. Knowing how tight funds are in the company, this person scrutinizes every purchase and contract before approving the purchase. What should you do next in this scenario?
  1. A Alert the project sponsor to the delay that is likely to occur.
  2. B Review the resource management plan.
  3. C Consult with the head of the procurement office.
  4. D Review project constraints and assumptions.
Xem giải thích

Đáp án

C — TRAO ĐỔI VỚI TRƯỞNG PHÒNG MUA SẮM.

Vì sao đúng

⚠ Vì sao đây là bước tiếp theo đúng: | Lý do | Nội dung | |---|---| | ⚠ Tắc nghẽn nằm TRONG phòng mua sắm | ⚠ nên phải nói chuyện với người phụ trách nơi đó | | ⚠ Trưởng phòng có thẩm quyền đổi cách làm | ⚠ thêm người duyệt, đặt ngưỡng, phân quyền | | ⚠ Đi thẳng tới nguồn thay vì leo thang vòng | ⚠ nhanh hơn và tôn trọng hơn | | ⚠ Bạn đã CÓ DỮ LIỆU: đã họp với bên liên quan và xác định được điểm tắc | ⚠ nên cuộc trao đổi sẽ có nội dung | | ⚠ Vấn đề ảnh hưởng NHIỀU DỰ ÁN, không riêng của bạn | ⚠ đề nói rõ — nên đây là một cải tiến quy trình chung | | ⚠ Kết luận | ⚠ giải quyết ở nơi có tắc nghẽn và có thẩm quyền sửa |

⚠ Điểm cần nhận ra: ⚠ người duyệt đang soi kỹ mọi khoản chi là hành xử ĐÚNG VAI TRÒ trong hoàn cảnh công ty eo hẹp ⚠ — ⚠ đây không phải vấn đề về con người mà là vấn đề về THIẾT KẾ QUY TRÌNH: chỉ có MỘT người được duyệt; ⚠ nhận ra điều này quyết định cách bạn mở đầu cuộc trò chuyện.

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

  • A (báo nhà tài trợ về khả năng chậm trễ) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thông báo sớm cho nhà tài trợ là thực hành tốt và trong nhiều câu khác chính là đáp án: ⚠ nhưng ⚠ ở đây bạn CHƯA THỬ giải quyết vấn đề bằng con đường trực tiếp ⚠ — ⚠ leo thang trước khi tự làm gì là chuyển vấn đề chứ không phải giải quyết vấn đề; ⚠ và nếu trưởng phòng mua sắm biết bạn báo lên trước khi nói với họ, quan hệ làm việc sẽ khó hơn hẳn; ⚠ liên hệ #26476 lô 194.

  • B (rà soát kế hoạch quản lý nguồn lực) — ⚠ sai lĩnh vực: ⚠ đây là vấn đề QUY TRÌNH MUA SẮM, không phải phân bổ nguồn lực của dự án.

  • D (rà soát ràng buộc và giả định của dự án) — ⚠ là việc phân tích hữu ích, ⚠ nhưng không giải quyết được điểm tắc; ⚠ và bạn đã biết nguyên nhân rồi, không cần phân tích thêm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26475 lô 194 (quy trình gây tắc nghẽn — cùng kiểm toán viên tinh gọn), ⚠ #26451 lô 194 (ngưỡng phê duyệt mua sắm), ⚠ #26561 lô 196 (điểm tắc nghẽn quyết định thông lượng), ⚠ #26582 lô 196 (quản trị dự án), ⚠ #26442 lô 194 (khi nào leo thang).

⚠ XỬ LÝ MỘT ĐIỂM TẮC NGHẼN — trình tự: | Bước | Nội dung | |---|---| | ⚠ 1. XÁC ĐỊNH điểm tắc bằng dữ liệu | ⚠ bạn đã làm — họp bên liên quan và tìm ra | | ⚠ 2. Trao đổi với người CHỊU TRÁCH NHIỆM nơi đó | ⚠ đáp án — hiểu ràng buộc của họ trước khi đề xuất | | ⚠ 3. Cùng tìm phương án | ⚠ thêm người duyệt, đặt ngưỡng, duyệt theo lô, uỷ quyền có giới hạn | | ⚠ 4. Nếu không giải quyết được thì mới LEO THANG | ⚠ phương án A thuộc bước này | | ⚠ 5. Ghi vào sổ vấn đề và theo dõi | | | ⚠ Nguyên tắc | ⚠ một điểm tắc nghẽn quyết định thông lượng của cả hệ thống — mọi cải tiến ở nơi khác đều vô ích cho tới khi nó được xử lý; liên hệ #26561 lô 196 |

⚠ Các phương án có thể đề xuất với trưởng phòng mua sắm: | Phương án | Nội dung | |---|---| | ⚠ NGƯỠNG phê duyệt theo giá trị | ⚠ khoản nhỏ do người khác duyệt, khoản lớn mới lên người đó — liên hệ #26451 lô 194 | | ⚠ Uỷ quyền dự phòng khi người đó bận hoặc nghỉ | ⚠ loại bỏ điểm hỏng đơn lẻ | | ⚠ Duyệt theo LÔ ở khung giờ cố định | ⚠ giảm chuyển đổi ngữ cảnh cho người duyệt | | ⚠ Đơn giản hoá hồ sơ cho khoản chi định kỳ | ⚠ liên hệ #26475 lô 194 | | ⚠ Cho phòng mua sắm thấy TÁC ĐỘNG bằng số liệu | ⚠ bao nhiêu ngày chờ, ảnh hưởng bao nhiêu dự án | | ⚠ Cách mở đầu cuộc trò chuyện | ⚠ KHÔNG bắt đầu bằng "phòng anh đang làm chậm dự án của tôi" — bắt đầu bằng "tôi muốn hiểu quy trình của anh để xem chúng tôi có thể chuẩn bị hồ sơ tốt hơn không"; cách mở đầu quyết định phần lớn kết quả |

⚠ Vì sao KHÔNG nên coi đây là lỗi của người duyệt: | Lý do | Nội dung | |---|---| | ⚠ Họ đang làm ĐÚNG việc được giao trong hoàn cảnh tiền eo hẹp | ⚠ soi kỹ chi tiêu là trách nhiệm của họ | | ⚠ Vấn đề là THIẾT KẾ: chỉ một người được duyệt | ⚠ đó là một điểm hỏng đơn lẻ về mặt tổ chức | | ⚠ Trách người sẽ khiến họ phòng thủ và mọi thứ chậm hơn | | | ⚠ Nguyên tắc quản trị | ⚠ khi một người trở thành điểm tắc, hầu như luôn là do hệ thống đặt quá nhiều thứ lên một người — chứ không phải do người đó chậm; sửa hệ thống thì cả hai bên đều nhẹ đi |

Từ khoá nhận diện:

"tắc nghẽn ở một phòng ban khác" → ⚠ TRAO ĐỔI VỚI NGƯỜI PHỤ TRÁCH NƠI ĐÓ TRƯỚC "báo nhà tài trợ ngay" → ⚠ leo thang khi chưa thử giải quyết trực tiếp "chỉ một người được duyệt" → ⚠ điểm hỏng đơn lẻ, vấn đề THIẾT KẾ không phải vấn đề con người "rà kế hoạch nguồn lực / ràng buộc" → ⚠ phân tích thêm khi đã biết nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn đang chờ ở khâu nào lâu nhất | | | Khâu đó có bao nhiêu người xử lý được | ⚠ một người là điểm hỏng đơn lẻ | | Bạn đã nói chuyện với người phụ trách khâu đó chưa | ⚠ hay mới chỉ than phiền trong nội bộ đội |

Và điều mà một cuộc trò chuyện mười lăm phút với trưởng phòng mua sắm thường mang lại nhiều hơn ba tuần chờ đợi: hoá ra họ cũng đang khó chịu với chính điểm tắc đó — chỉ là chưa ai mang tới cho họ một con số cho thấy nó đang tốn của tổ chức bao nhiêu.

Câu 180 Process
Frank is the scrum master for Project Daytime, which is in its third iteration. The team is performing well. Recently a team member noted that some project tasks appear to be dependent on other work that is not included in Project Daytime but comes from another project in the organization. What should Frank do with this information?
  1. A Assign the team member to close the gaps in the project.
  2. B Have the project team work extra hours to cover the gaps.
  3. C Identify the dependencies and add appropriate tasks to the backlog.
  4. D Do nothing. The product owner owns the backlog.
Xem giải thích

Đáp án

C — NHẬN DIỆN các phụ thuộc và THÊM các công việc phù hợp vào backlog.

Vì sao đúng

⚠ Vì sao đây là hành động đúng: | Lý do | Nội dung | |---|---| | ⚠ Phụ thuộc BÊN NGOÀI đã được phát hiện | ⚠ việc đầu tiên là làm cho nó HIỆN RA | | ⚠ Đưa vào backlog để nó được nhìn thấy và xếp ưu tiên | ⚠ thứ không có trong backlog thì không tồn tại với đội | | ⚠ Có công việc thật cần làm: điều phối, chờ, tích hợp | ⚠ những việc đó cũng tốn thời gian và phải được tính | | ⚠ Phụ thuộc chưa quản lý là RỦI RO tiến độ lớn | ⚠ đội có thể bị chặn hoàn toàn | | ⚠ Đội đang làm tốt và ở vòng lặp thứ ba | ⚠ phát hiện sớm, còn nhiều thời gian xử lý | | ⚠ Kết luận | ⚠ biến một phát hiện thành công việc cụ thể trong hệ thống của đội |

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

  • D (không làm gì, chủ sản phẩm sở hữu backlog) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ mệnh đề "chủ sản phẩm sở hữu backlog" HOÀN TOÀN ĐÚNG, và nó chính là đáp án của #26604 cùng lô: ⚠ nhưng ⚠ ở đây đây là VẤN ĐỀ VỀ TIẾN TRÌNH và VẬT CẢN, đúng phạm vi của scrum master ⚠ — ⚠ Frank không tự quyết thứ tự ưu tiên, nhưng anh phải làm cho phụ thuộc HIỆN RA và phối hợp với chủ sản phẩm để đưa vào backlog; ⚠ "không làm gì" biến một nguyên tắc đúng về vai trò thành một cái cớ để bỏ mặc.

  • A (giao thành viên đó tự lấp các khoảng trống) — ⚠ giao một vấn đề LIÊN DỰ ÁN cho một cá nhân; ⚠ họ không có thẩm quyền phối hợp với dự án khác.

  • B (bảo đội làm thêm giờ để bù) — ⚠ làm thêm giờ không giải quyết được phụ thuộc; ⚠ nếu công việc đến từ dự án khác thì đội có làm bao nhiêu giờ cũng không tự tạo ra nó được.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26604 cùng lô (chỉ bên liên quan sang chủ sản phẩm — ranh giới vai trò), ⚠ #26465 lô 194 (các loại phụ thuộc), ⚠ #26575 lô 196 (phối hợp giữa nhiều đội), ⚠ #26552 lô 196 (xác định tác động trước), ⚠ #26551 lô 196 (tác nhân kích hoạt).

⚠ BỐN LOẠI PHỤ THUỘC — phụ thuộc này thuộc loại nào: | Loại | Nghĩa | Trong tình huống này | |---|---|---| | ⚠ BẮT BUỘC | ⚠ do bản chất công việc | ⚠ có thể — nếu thật sự phải chờ kết quả kia | | ⚠ TUỲ Ý | ⚠ do lựa chọn của đội | | | ⚠ BÊN NGOÀI | ⚠ ngoài tầm kiểm soát dự án | ⚠ ĐÚNG — phụ thuộc vào một dự án KHÁC | | ⚠ BÊN TRONG | ⚠ trong tầm kiểm soát dự án | | | ⚠ Vì sao phân loại quan trọng | ⚠ phụ thuộc BÊN NGOÀI cần PHỐI HỢP và THEO DÕI, không thể tự giải quyết bằng nỗ lực của đội — đó là lý do phương án "làm thêm giờ" hoàn toàn sai hướng; liên hệ #26465 lô 194 | |

⚠ Quản lý phụ thuộc liên dự án — việc cần làm: | Việc | Nội dung | |---|---| | ⚠ Ghi rõ phụ thuộc: cần GÌ, từ AI, KHI NÀO | | | ⚠ Thêm công việc điều phối vào backlog | ⚠ đáp án — việc phối hợp cũng là công việc thật | | ⚠ Liên hệ với quản lý dự án kia | ⚠ xác nhận thời điểm họ có thể giao | | ⚠ Ghi vào SỔ RỦI RO nếu thời điểm chưa chắc chắn | ⚠ kèm tác nhân kích hoạt — liên hệ #26551 lô 196 | | ⚠ Lập phương án B nếu bên kia trễ | ⚠ giả lập tạm, làm phần khác trước, hoặc tự làm | | ⚠ Báo chủ sản phẩm để xếp ưu tiên phù hợp | ⚠ có thể phải đảo thứ tự công việc trong các vòng lặp tới | | ⚠ Nếu vượt tầm | ⚠ leo thang lên cấp CHƯƠNG TRÌNH — phụ thuộc giữa các dự án là lý do chính khiến các tổ chức lập cấp quản lý chương trình; liên hệ #26582 lô 196 |

⚠ Ranh giới vai trò của Frank — vì sao anh vẫn phải hành động: | Việc Frank LÀM | Việc Frank KHÔNG làm | |---|---| | ⚠ Làm cho phụ thuộc HIỆN RA và được ghi lại | ⚠ quyết định thứ tự ưu tiên trong backlog | | ⚠ Điều phối với đội và dự án khác | ⚠ cam kết thay chủ sản phẩm về phạm vi | | ⚠ GỠ VẬT CẢN cho đội | ⚠ tự giải quyết vấn đề kỹ thuật thay đội | | ⚠ Đưa vấn đề vào các nghi thức phù hợp | ⚠ bỏ mặc vì "đó không phải việc của tôi" | | ⚠ Nguyên tắc | ⚠ scrum master không sở hữu backlog nhưng chịu trách nhiệm bảo đảm mọi vật cản đều được NHÌN THẤY — một phụ thuộc chưa ai biết là vật cản nguy hiểm nhất, vì nó chỉ lộ ra vào đúng ngày đội bị chặn |

Từ khoá nhận diện:

"phát hiện phụ thuộc vào dự án khác" → ⚠ NHẬN DIỆN và THÊM CÔNG VIỆC VÀO BACKLOG "chủ sản phẩm sở hữu backlog nên không làm gì" → ⚠ nguyên tắc đúng bị dùng làm cớ bỏ mặc "làm thêm giờ để bù" → ⚠ không tạo ra được công việc đến từ dự án khác "giao một cá nhân tự lấp" → ⚠ vấn đề liên dự án vượt thẩm quyền cá nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có phụ thuộc nào vào đội khác không | ⚠ và chúng có được ghi ở đâu không | | Ai đang theo dõi thời điểm bên kia giao | | | Bạn có phương án B nếu họ trễ không | |

Và lý do một phụ thuộc được ghi vào backlog lại có giá trị hơn hẳn một phụ thuộc chỉ nằm trong đầu ai đó: backlog là thứ cả đội nhìn vào mỗi ngày — và một rủi ro được nhìn thấy mỗi ngày rất hiếm khi trở thành một bất ngờ.