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

Tìm thấy 718 câu.

Câu 361 Business Environment
Rachel ensures that her project is aligned with her stakeholder’s priorities by:
  1. A Using the planning poker method to prioritize the backlog.
  2. B Having the full stakeholder team agree on the prioritization of the backlog.
  3. C Comparing the priorities listed in the charter with the planned release schedule and prioritizing the backlog accordingly.
  4. D Having the product owner and delivery team prioritize the backlog.
Xem giải thích

Đáp án

D — ĐỂ CHỦ SẢN PHẨM VÀ ĐỘI GIAO HÀNG CÙNG XẾP ƯU TIÊN TỒN ĐỌNG.

Vì sao đúng

⚠ Vì sao đây là cơ chế đúng: | Lý do | Nội dung | |---|---| | ⚠ CHỦ SẢN PHẨM là ĐẠI DIỆN CHÍNH THỨC của bên liên quan | ⚠ vai trò này tồn tại để làm đúng việc đó | | ⚠ Chủ sản phẩm nắm giá trị kinh doanh và ưu tiên của bên liên quan | | | ⚠ ĐỘI GIAO HÀNG nắm công sức, phụ thuộc và rủi ro kỹ thuật | ⚠ thông tin mà chủ sản phẩm không có | | ⚠ Xếp ưu tiên tốt cần CẢ HAI loại thông tin | ⚠ giá trị chia cho công sức | | ⚠ Có MỘT người quyết định cuối cùng | ⚠ tránh bế tắc — liên hệ #26809 cùng lô | | ⚠ Kết luận | ⚠ dự án bám sát ưu tiên của bên liên quan thông qua chủ sản phẩm, chứ không bằng cách hỏi trực tiếp tất cả họ |

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

  • B (để TOÀN BỘ nhóm bên liên quan cùng thống nhất về thứ tự tồn đọng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nghe rất dân chủ và có vẻ là cách chắc chắn nhất để dự án khớp với ưu tiên của bên liên quan: ⚠ nhưng ⚠ nó BẤT KHẢ THI trong thực tế và trái với thiết kế của Scrum ⚠ — ⚠ bên liên quan có lợi ích xung đột nhau, và đòi tất cả cùng đồng ý về thứ tự sẽ dẫn tới bế tắc hoặc tới việc người có tiếng nói to nhất thắng; ⚠ vai trò chủ sản phẩm ra đời chính là để giải bài toán này: MỘT người lắng nghe tất cả rồi chịu trách nhiệm về quyết định cuối cùng.

  • C (so ưu tiên trong hiến chương với lịch phát hành rồi xếp theo đó) — ⚠ hiến chương là tài liệu ở mức rất cao và được viết từ đầu; ⚠ ưu tiên thay đổi liên tục, và cách này bỏ qua thông tin mới.

  • A (dùng planning poker để xếp ưu tiên tồn đọng) — ⚠ planning poker là kỹ thuật ƯỚC LƯỢNG công sức, không phải kỹ thuật xếp ưu tiên; ⚠ nhầm công cụ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26809 cùng lô (vai trò chủ sản phẩm là duy trì tồn đọng), ⚠ #26825 cùng lô (tồn đọng không được xếp lại ưu tiên), ⚠ #26789 cùng lô (tinh chỉnh tồn đọng cùng nhau), ⚠ #26756 lô 200 (không có phương pháp xếp ưu tiên duy nhất), ⚠ #26767 lô 200 (MoSCoW).

⚠ Ai làm gì trong việc xếp ưu tiên: | Vai | Đóng góp | |---|---| | ⚠ BÊN LIÊN QUAN | ⚠ nêu nhu cầu và mức độ quan trọng với họ | | ⚠ CHỦ SẢN PHẨM | ⚠ tổng hợp, cân nhắc, QUYẾT ĐỊNH thứ tự — ĐÁP ÁN | | ⚠ ĐỘI GIAO HÀNG | ⚠ ước lượng công sức, nêu phụ thuộc kỹ thuật và rủi ro | | ⚠ SCRUM MASTER | ⚠ tạo điều kiện cho cuộc trao đổi, không quyết nội dung | | ⚠ Vì sao mô hình này hoạt động | ⚠ nó tách bạch giữa việc LẮNG NGHE (rộng) và việc QUYẾT ĐỊNH (một người) — thiếu vế đầu thì quyết định thiếu căn cứ, thiếu vế sau thì không có quyết định nào |

⚠ Chủ sản phẩm bám sát ưu tiên bên liên quan bằng cách nào: | Việc | Nội dung | |---|---| | ⚠ Gặp bên liên quan thường xuyên | ⚠ hiểu nhu cầu thay đổi theo thời gian | | ⚠ Mời họ dự buổi rà soát sprint | ⚠ thấy sản phẩm thật rồi cho phản hồi — liên hệ #26825 cùng lô | | ⚠ Giải thích các đánh đổi bằng con số | ⚠ kéo cái này lên thì cái kia lùi xuống | | ⚠ Công khai tồn đọng và thứ tự của nó | ⚠ minh bạch giảm rất nhiều tranh cãi | | ⚠ Dùng dữ liệu sử dụng thật để điều chỉnh | | | ⚠ Rủi ro của vai trò chủ sản phẩm | ⚠ một chủ sản phẩm không gặp bên liên quan sẽ xếp ưu tiên theo phỏng đoán của riêng mình — và khi đó cả cơ chế mất đi ý nghĩa, đúng như tình huống mà #26825 cùng lô mô tả |

⚠ Phân biệt các kỹ thuật hay bị nhầm: | Kỹ thuật | Dùng để | |---|---| | ⚠ PLANNING POKER | ⚠ ƯỚC LƯỢNG công sức — phương án nhiễu A | | ⚠ MoSCoW, xếp hạng tuyệt đối, mua tính năng | ⚠ XẾP ƯU TIÊN — liên hệ #26767 lô 200 | | ⚠ TINH CHỈNH TỒN ĐỌNG | ⚠ hoạt động bao trùm: làm rõ, ước lượng, chia nhỏ, xếp lại — liên hệ #26789 cùng lô | | ⚠ Mẹo phân biệt | ⚠ hỏi "kỹ thuật này trả lời câu hỏi nào": BAO NHIÊU CÔNG SỨC là ước lượng; LÀM CÁI NÀO TRƯỚC là xếp ưu tiên |

Từ khoá nhận diện:

"bám sát ưu tiên của bên liên quan" → ⚠ CHỦ SẢN PHẨM + ĐỘI GIAO HÀNG xếp ưu tiên "toàn bộ bên liên quan cùng thống nhất" → ⚠ bất khả thi, dẫn tới bế tắc "planning poker" → ⚠ kỹ thuật ước lượng, không phải xếp ưu tiên "so với hiến chương" → ⚠ tài liệu mức cao, bỏ qua thông tin mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chủ sản phẩm của bạn gặp bên liên quan bao lâu một lần | | | Đội có được góp ý về thứ tự tồn đọng không | | | Bên liên quan có xem được tồn đọng không | |

Và điều mà vai trò chủ sản phẩm thật sự giải quyết: không phải việc ai đó phải viết ra danh sách công việc, mà việc phải có MỘT người chịu trách nhiệm khi mười bên liên quan cùng muốn thứ của mình được làm trước.

Câu 362 Process
Rebecca is the project manager for Project Light, which will deliver three new condo buildings for the Light Management Company. Project Light is ten weeks into the project's construction phase, $20,000 over budget, and two weeks behind schedule. Recently, a contracting company had to be replaced to correct an unanticipated challenge with the project's first milestone. What should Rebecca do next?
  1. A Have the contractor train the team on what they did.
  2. B Update the budget and inform stakeholders.
  3. C Escalate the issue to the project management office.
  4. D Do nothing. It likely will not happen again.
Xem giải thích

Đáp án

B — CẬP NHẬT NGÂN SÁCH VÀ THÔNG BÁO CHO CÁC BÊN LIÊN QUAN.

Vì sao đúng

⚠ Vì sao đây là bước tiếp theo: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Dự án đã VƯỢT CHI 20.000 đô và TRỄ hai tuần | ⚠ sai lệch thật, cần được ghi nhận | | ⚠ Vừa phải THAY một nhà thầu | ⚠ sự kiện lớn, chắc chắn làm chi phí thay đổi thêm | | ⚠ Bên liên quan cần biết tình hình tài chính thật | ⚠ quản lý kỳ vọng | | ⚠ Cập nhật ngân sách là việc bắt buộc sau một sai lệch lớn | ⚠ dự báo mới, EAC mới | | ⚠ Kết luận | ⚠ ghi nhận tác động tài chính rồi minh bạch với bên liên quan |

⚠ Hai vế của đáp án đều cần thiết: ⚠ cập nhật con số mà không báo thì bên liên quan vẫn đang dùng số cũ; báo mà chưa cập nhật thì báo cáo không có căn cứ ⚠ — ⚠ các phương án khác thiếu một trong hai vế hoặc thiếu cả hai.

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

  • C (leo thang vấn đề lên văn phòng quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ PMO đúng là nơi hỗ trợ khi dự án gặp khó, và vượt chi hai mươi nghìn đô nghe đủ nghiêm trọng để báo cáo lên: ⚠ nhưng ⚠ Rebecca chưa làm việc cơ bản nhất là CẬP NHẬT CON SỐ của chính mình ⚠ — ⚠ leo thang mà chưa có bức tranh tài chính cập nhật là leo thang tay không; ⚠ và PMO cũng là một bên nhận thông tin — nên việc báo cáo cho họ nằm gọn trong vế "thông báo cho bên liên quan" của đáp án.

  • A (nhờ nhà thầu cũ đào tạo lại đội về những gì họ đã làm) — ⚠ có thể hữu ích về mặt chuyển giao tri thức, nhưng không phải bước tiếp theo; ⚠ và nhà thầu vừa bị thay thường không hợp tác.

  • D (không làm gì, chuyện này chắc không lặp lại) — ⚠ bỏ qua một sai lệch đã xảy ra; ⚠ và dựa trên một giả định không có căn cứ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26787 cùng lô (báo sớm sự cố kèm kế hoạch), ⚠ #26795 cùng lô (đọc CPI và SPI), ⚠ #26798 cùng lô (chọn chỉ số phù hợp với ràng buộc), ⚠ #26778 lô 200 (gặp bên liên quan khi dự án gặp khó), ⚠ #26794 cùng lô (quản lý thay đổi hợp đồng).

⚠ Sau khi phải thay một nhà thầu, cần làm những gì: | Việc | Nội dung | |---|---| | ⚠ CẬP NHẬT NGÂN SÁCH và dự báo | ⚠ ĐÁP ÁN — tính lại EAC | | ⚠ Cập nhật tiến độ và đường cơ sở nếu cần | ⚠ qua kiểm soát thay đổi — liên hệ #26739 lô 200 | | ⚠ THÔNG BÁO cho bên liên quan | ⚠ ĐÁP ÁN — vế thứ hai | | ⚠ Đóng hợp đồng cũ đúng thủ tục | ⚠ liên hệ #26795 cùng lô | | ⚠ Ghi vào sổ vấn đề và sổ bài học | ⚠ liên hệ #26726 lô 199 | | ⚠ Rà soát lại rủi ro với nhà thầu mới | ⚠ liên hệ #26777 lô 200 | | ⚠ Việc quan trọng ít ai làm | ⚠ phân tích VÌ SAO nhà thầu cũ thất bại — nếu nguyên nhân nằm ở khâu lựa chọn hoặc ở tuyên bố công việc mơ hồ thì nhà thầu mới sẽ gặp đúng vấn đề đó |

⚠ Cập nhật ngân sách nghĩa là làm gì: | Việc | Nội dung | |---|---| | ⚠ Ghi nhận chi phí thực tế tới nay | ⚠ AC | | ⚠ Tính lại chỉ số hiệu năng chi phí | ⚠ CPI — liên hệ #26812 cùng lô | | ⚠ Dự báo chi phí khi hoàn thành | ⚠ EAC | | ⚠ Tính phần còn cần | ⚠ ETC | | ⚠ Kiểm tra quỹ dự phòng còn lại | | | ⚠ Vì sao con số quan trọng hơn lời giải thích | ⚠ bên liên quan có thể chấp nhận một dự án vượt chi, nhưng rất khó chấp nhận một dự án mà không ai nói được nó sẽ vượt bao nhiêu — sự bất định luôn đáng sợ hơn một con số xấu |

⚠ Cách thông báo cho bên liên quan trong tình huống này: | Nội dung | Chi tiết | |---|---| | ⚠ Chuyện gì đã xảy ra | ⚠ nhà thầu không đạt ở mốc đầu tiên, đã thay thế | | ⚠ Tác động: con số cụ thể | ⚠ vượt chi bao nhiêu, trễ bao lâu, dự báo mới là gì | | ⚠ Đã làm gì để xử lý | ⚠ thay nhà thầu là một hành động khắc phục | | ⚠ Kế hoạch bù đắp nếu có | | | ⚠ Điều cần bên liên quan quyết định | ⚠ có nới ngân sách, nới hạn, hay cắt phạm vi | | ⚠ Nhắc nhở | ⚠ thay được nhà thầu ngay ở mốc đầu tiên thực ra là một tin TỐT về năng lực quản lý — nó cho thấy vấn đề được phát hiện sớm và xử lý dứt khoát; cách trình bày quyết định việc bên liên quan nhìn thấy sự cố hay nhìn thấy sự chủ động |

Từ khoá nhận diện:

"vượt chi và vừa thay nhà thầu" → ⚠ CẬP NHẬT NGÂN SÁCH + BÁO BÊN LIÊN QUAN "leo thang lên PMO" → ⚠ chưa có bức tranh tài chính thì leo thang tay không "nhờ nhà thầu cũ đào tạo lại" → ⚠ không phải bước tiếp theo "không làm gì" → ⚠ gần như luôn sai trong đề PMP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết dự báo chi phí cuối cùng của dự án mình không | | | Bên liên quan đang dùng con số nào — con số cũ hay con số mới nhất | | | Sau mỗi sai lệch lớn, bao lâu thì bạn cập nhật dự báo | |

Và điều mà một con số được cập nhật kịp thời làm được cho một dự án đang gặp khó: nó biến một tình huống xấu thành một tình huống ĐƯỢC KIỂM SOÁT — và với phần lớn bên liên quan, sự khác biệt giữa hai điều đó quan trọng hơn cả bản thân con số.

Câu 363 Process
Victoria is the scrum master for Project EZ, which is in its initial planning stages and expected to cost around $76,000 based on the current set of requirements and budget. During planning, she realizes this project will require some specialized resources that may not be available at her company. What should she do next?
  1. A Do nothing. The product owner will deal with this.
  2. B Let the product owner know.
  3. C Inform the steering committee.
  4. D Solicit vendors.
Xem giải thích

Đáp án

B — BÁO CHO CHỦ SẢN PHẨM BIẾT.

Vì sao đúng

⚠ Vì sao chủ sản phẩm là người cần biết trước: | Lý do | Nội dung | |---|---| | ⚠ Thiếu nguồn lực ảnh hưởng tới việc GIAO ĐƯỢC GÌ | ⚠ đó là lĩnh vực của chủ sản phẩm | | ⚠ Chủ sản phẩm có thể điều chỉnh phạm vi hoặc thứ tự | ⚠ giải pháp có thể nằm ở tồn đọng chứ không ở nguồn lực | | ⚠ Chủ sản phẩm là cầu nối với bên liên quan và ngân sách | ⚠ họ có kênh xin thêm nguồn lực | | ⚠ Dự án ĐANG Ở GIAI ĐOẠN LẬP KẾ HOẠCH BAN ĐẦU | ⚠ phát hiện sớm, còn nhiều dư địa xử lý | | ⚠ Scrum master có nhiệm vụ nêu vật cản, không tự đi mua sắm | ⚠ liên hệ #26702 lô 199 | | ⚠ Kết luận | ⚠ nêu vật cản với đúng người trước khi tự hành động |

⚠ Nguyên tắc: ⚠ scrum master GỠ vật cản, nhưng những vật cản chạm tới PHẠM VI, NGÂN SÁCH hoặc NHÀ CUNG CẤP đều phải đi qua chủ sản phẩm — vì đó là người chịu trách nhiệm về giá trị và về ngân sách sản phẩm.

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

  • D (đi tìm nhà cung cấp) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là hành động chủ động và trực tiếp giải quyết vấn đề, đúng tinh thần "gỡ vật cản" của scrum master: ⚠ nhưng ⚠ nó BỎ QUA việc thông báo và bỏ qua khả năng có giải pháp rẻ hơn ⚠ — ⚠ chủ sản phẩm có thể quyết định điều chỉnh phạm vi, đổi thứ tự, hoặc dùng nguồn lực nội bộ mà Victoria chưa biết tới; ⚠ và việc tìm nhà cung cấp kéo theo ngân sách và hợp đồng, hai thứ vượt thẩm quyền của một scrum master — liên hệ #26684 lô 199.

  • C (báo cho ban chỉ đạo) — ⚠ leo thang quá sớm; ⚠ chưa thử kênh gần nhất là chủ sản phẩm.

  • A (không làm gì, chủ sản phẩm sẽ tự lo) — ⚠ chủ sản phẩm không thể lo một việc mà họ chưa biết; ⚠ đây là sự thụ động trá hình.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26800 cùng lô (yêu cầu nhân sự — cùng chủ đề thiếu nguồn lực chuyên biệt), ⚠ #26702 lô 199 (scrum master gỡ vật cản với đúng người), ⚠ #26809 cùng lô (vai trò chủ sản phẩm), ⚠ #26680 lô 198 (thiếu nguồn lực trong ma trận yếu), ⚠ #26716 lô 199 (đào tạo người sẵn có).

⚠ Vật cản nào đi tới ai: | Loại vật cản | Người xử lý | |---|---| | ⚠ Cản trở kỹ thuật trong tầm đội | ⚠ chính đội tự giải quyết | | ⚠ Vật cản về quy trình, công cụ, môi trường làm việc | ⚠ SCRUM MASTER | | ⚠ Vật cản chạm tới PHẠM VI, NGÂN SÁCH, ưu tiên | ⚠ CHỦ SẢN PHẨM — ĐÁP ÁN | | ⚠ Vật cản ở bộ phận khác | ⚠ scrum master gặp quản lý bộ phận đó — liên hệ #26702 lô 199 | | ⚠ Vật cản ở cấp tổ chức | ⚠ leo thang lên nhà tài trợ hoặc ban chỉ đạo | | ⚠ Nguyên tắc | ⚠ luôn đưa vật cản tới NGƯỜI GẦN NHẤT CÓ THẨM QUYỀN GIẢI QUYẾT — không tự làm thay, cũng không nhảy cóc lên cấp cao nhất |

⚠ Các phương án chủ sản phẩm có thể chọn: | Phương án | Nội dung | |---|---| | ⚠ Điều chỉnh PHẠM VI để không cần kỹ năng đó | ⚠ rẻ nhất, thường bị bỏ qua | | ⚠ Đổi THỨ TỰ tồn đọng, làm phần khác trước | ⚠ mua thêm thời gian tìm người | | ⚠ Xin nguồn lực từ bộ phận khác trong tổ chức | | | ⚠ Đào tạo người sẵn có | ⚠ liên hệ #26716 lô 199 | | ⚠ Thuê ngoài | ⚠ phương án D — nhưng là quyết định của chủ sản phẩm, không của scrum master | | ⚠ Vì sao thứ tự này quan trọng | ⚠ ngân sách khoảng 76.000 đô là không lớn — một hợp đồng chuyên gia có thể chiếm phần đáng kể trong đó; nên việc xem xét các phương án rẻ hơn trước không phải là sự chậm chạp mà là sự cẩn trọng cần thiết |

⚠ Victoria nên trình bày vật cản thế nào: | Việc | Nội dung | |---|---| | ⚠ Nêu rõ kỹ năng nào thiếu và cho hạng mục nào | ⚠ liên hệ #26800 cùng lô | | ⚠ Nêu thời điểm cần và thời lượng | | | ⚠ Nêu TÁC ĐỘNG nếu không có | ⚠ hạng mục nào không làm được, ảnh hưởng gì tới giá trị | | ⚠ Đề xuất vài phương án đã cân nhắc | ⚠ biến việc báo cáo vấn đề thành việc đóng góp | | ⚠ Nói rõ mình cần chủ sản phẩm quyết điều gì | | | ⚠ Điểm đáng ghi nhận | ⚠ Victoria phát hiện ra điều này TRONG LÚC LẬP KẾ HOẠCH chứ không phải giữa vòng lặp — đó là thời điểm rẻ nhất để xử lý, và việc nêu ra ngay lúc đó là hành vi đúng dù câu trả lời cuối cùng là gì |

Từ khoá nhận diện:

"thiếu nguồn lực chuyên biệt trong dự án agile" → ⚠ BÁO CHO CHỦ SẢN PHẨM "tự đi tìm nhà cung cấp" → ⚠ vượt thẩm quyền và bỏ qua phương án rẻ hơn "báo ban chỉ đạo" → ⚠ leo thang quá sớm "chủ sản phẩm sẽ tự lo" → ⚠ họ không lo được thứ chưa biết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có kênh nào để nêu vật cản không | | | Vật cản gần nhất mất bao lâu để tới người có thẩm quyền | | | Bạn có tự xử lý việc gì vượt thẩm quyền của mình không | |

Và điều mà một câu báo sớm với chủ sản phẩm mở ra: có thể hoá ra hạng mục cần kỹ năng đó lại không nằm trong phần quan trọng nhất của sản phẩm — và một cuộc trò chuyện năm phút vừa tiết kiệm được cả một hợp đồng chuyên gia.

Câu 364 Process
As the project manager for a technical project, Gerald works with the team and key stakeholders to plan out the project work. Beth, a key stakeholder, asks how the team can be certain that all of the project's work will be identified before the work begins. How is Gerald likely to respond?
  1. A There may be changes in the project, and the change control process is followed.
  2. B All changes will flow through the project steering committee and the stakeholders.
  3. C The scope is reviewed and approved by all stakeholders before project work begins.
  4. D Predictive projects ensure they catch all requirements before starting any work.
Xem giải thích

Đáp án

A — CÓ THỂ SẼ CÓ NHỮNG THAY ĐỔI TRONG DỰ ÁN, VÀ CHÚNG TA TUÂN THEO QUY TRÌNH KIỂM SOÁT THAY ĐỔI.

Vì sao đúng

⚠ Vì sao đây là câu trả lời trung thực và đúng: | Lý do | Nội dung | |---|---| | ⚠ KHÔNG dự án nào xác định được 100% công việc từ đầu | ⚠ đó là bản chất của dự án, không phải khuyết điểm của kế hoạch | | ⚠ LẬP KẾ HOẠCH THEO LỚP SÓNG là thực hành chuẩn | ⚠ chi tiết cho phần gần, thô cho phần xa | | ⚠ Cơ chế xử lý điều chưa biết là KIỂM SOÁT THAY ĐỔI | ⚠ liên hệ #26739 lô 200 | | ⚠ Hứa "sẽ bắt hết mọi thứ" là hứa điều không giữ được | ⚠ và nó tạo kỳ vọng sai cho Beth | | ⚠ Kết luận | ⚠ thừa nhận sự bất định và chỉ ra cơ chế xử lý nó — đó là câu trả lời chuyên nghiệp |

⚠ Điều Beth thật sự đang hỏi là: ⚠ "làm sao tôi biết dự án này không bị bất ngờ" ⚠ — ⚠ và câu trả lời đúng không phải là "sẽ không có bất ngờ" mà là "khi có bất ngờ, đây là cách chúng ta xử lý nó một cách có kiểm soát".

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

  • C (phạm vi được mọi bên liên quan rà soát và phê duyệt trước khi bắt đầu công việc) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ rà soát và phê duyệt phạm vi ĐÚNG là việc phải làm, và nó nghe như một sự bảo đảm vững chắc — đúng thứ Beth muốn nghe: ⚠ nhưng ⚠ nó ngầm hứa rằng việc phê duyệt sẽ bảo đảm không bỏ sót gì ⚠ — ⚠ phê duyệt chỉ xác nhận rằng mọi người ĐỒNG Ý với những gì ĐÃ BIẾT tại thời điểm đó, nó không biến điều chưa biết thành điều đã biết; ⚠ và câu hỏi của Beth chính là về những thứ chưa ai nghĩ tới.

  • D (dự án dự đoán bảo đảm bắt được hết mọi yêu cầu trước khi bắt đầu) — ⚠ phát biểu SAI; ⚠ không có vòng đời nào bảo đảm được điều đó.

  • B (mọi thay đổi sẽ đi qua ban chỉ đạo và các bên liên quan) — ⚠ gần đúng nhưng sai chi tiết; ⚠ thay đổi đi qua BAN KIỂM SOÁT THAY ĐỔI theo quy trình đã định, và không phải mọi thay đổi đều cần lên tới ban chỉ đạo — liên hệ #26710 lô 199.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26739 lô 200 (kiểm soát thay đổi tích hợp), ⚠ #26801 cùng lô (ghi lại yêu cầu thay đổi), ⚠ #26747 lô 200 (tất cả và chỉ công việc cần thiết), ⚠ #26788 cùng lô (chọn vòng đời phù hợp với mức bất định), ⚠ #26818 cùng lô (khách hàng đổi ý sau khi thấy sản phẩm).

⚠ LẬP KẾ HOẠCH THEO LỚP SÓNG (rolling wave planning): | Đặc điểm | Nội dung | |---|---| | ⚠ Chi tiết cao cho công việc SẮP LÀM | ⚠ vài tuần hoặc vài tháng tới | | ⚠ Chi tiết thô cho công việc XA | ⚠ gói lập kế hoạch (planning package) | | ⚠ Làm mịn dần khi tới gần | | | ⚠ Là một dạng lập kế hoạch chi tiết dần | ⚠ hoàn toàn hợp lệ trong vòng đời dự đoán | | ⚠ Vì sao nó tồn tại | ⚠ lập kế hoạch chi tiết cho công việc của mười tháng nữa là tiêu công sức vào những giả định gần như chắc chắn sẽ đổi — và bản kế hoạch đó còn tạo ra ảo giác về sự chắc chắn, thứ nguy hiểm hơn cả việc thiếu kế hoạch |

⚠ Vì sao không thể biết hết mọi việc từ đầu: | Nguyên nhân | Nội dung | |---|---| | ⚠ Yêu cầu được làm rõ dần khi người ta thấy sản phẩm | ⚠ liên hệ #26818 cùng lô | | ⚠ Môi trường kinh doanh thay đổi | ⚠ quy định mới, đối thủ mới — liên hệ #26634 lô 198 | | ⚠ Rủi ro xảy ra và sinh ra công việc mới | | | ⚠ Giải pháp kỹ thuật lộ ra vấn đề khi bắt tay làm | | | ⚠ Bên liên quan mới xuất hiện | ⚠ liên hệ #26721 lô 199 | | ⚠ Kết luận | ⚠ mục tiêu của việc lập kế hoạch không phải là loại bỏ điều chưa biết — mà là giảm nó xuống mức chấp nhận được và có cơ chế xử lý phần còn lại |

⚠ Gerald nên nói thêm gì với Beth để cô yên tâm: | Nội dung | Chi tiết | |---|---| | ⚠ Chúng ta dùng nhiều kỹ thuật để bắt yêu cầu sớm nhất có thể | ⚠ phỏng vấn, hội thảo, mẫu, WBS | | ⚠ Có QUỸ DỰ PHÒNG cho những điều đã lường trước | ⚠ liên hệ #26744 lô 200 | | ⚠ Có quy trình rõ ràng khi phát sinh | ⚠ ĐÁP ÁN | | ⚠ Bên liên quan sẽ được thông báo về mọi thay đổi lớn | | | ⚠ Chúng ta rà soát và làm mịn kế hoạch định kỳ | | | ⚠ Điều làm Beth thật sự yên tâm | ⚠ không phải lời hứa rằng sẽ không có gì bất ngờ — mà là bằng chứng rằng khi bất ngờ xảy ra, sẽ có người phát hiện ra nó, đánh giá được nó và đưa nó tới đúng bàn quyết định |

Từ khoá nhận diện:

"làm sao chắc chắn bắt hết công việc từ đầu" → ⚠ SẼ CÓ THAY ĐỔI, và ta có quy trình kiểm soát thay đổi "phê duyệt phạm vi trước khi bắt đầu" → ⚠ chỉ xác nhận điều ĐÃ BIẾT "dự đoán bảo đảm bắt hết yêu cầu" → ⚠ phát biểu sai "mọi thay đổi qua ban chỉ đạo" → ⚠ sai kênh và sai mức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch của bạn có phần nào còn ở mức thô không | ⚠ nếu mọi thứ đều chi tiết thì có thể bạn đang giả vờ chắc chắn | | Bên liên quan có biết quy trình xử lý thay đổi không | | | Bạn có quỹ dự phòng cho điều chưa lường trước không | |

Và điều mà một câu trả lời trung thực dạy được cho một bên liên quan đang lo lắng: sự chắc chắn mà cô đang tìm không tồn tại trong bất kỳ dự án nào — nhưng thứ thay thế nó thì tốt hơn, đó là một đội nhìn thấy điều bất ngờ sớm và biết phải làm gì với nó.

Câu 365 Process
Anthony’s team displays several success modes that help their project. One of those success modes is that his delivery team is good at observing, reviewing, and noticing when things are not right. His delivery team displays this most often in
  1. A Sprint review meetings
  2. B Daily standup meetings
  3. C Paired programming
  4. D Sprint retrospective meetings
Xem giải thích

Đáp án

C — LẬP TRÌNH CẶP (paired programming).

Vì sao đúng

⚠ Vì sao lập trình cặp là nơi hành vi này thể hiện rõ nhất: | Đặc điểm | Nội dung | |---|---| | ⚠ Hai người cùng làm trên một đoạn công việc, LIÊN TỤC | ⚠ quan sát và rà soát diễn ra theo thời gian thực | | ⚠ Một người viết, một người quan sát và nghĩ trước một bước | ⚠ đúng vai trò "nhận ra khi có gì đó không ổn" | | ⚠ Phát hiện ngay trong lúc làm, không phải sau đó | ⚠ rẻ nhất có thể | | ⚠ Diễn ra HẰNG NGÀY, không theo nhịp sự kiện | ⚠ "thể hiện thường xuyên nhất" — đúng chữ trong đề | | ⚠ Kết luận | ⚠ lập trình cặp là hình thức rà soát liên tục nhất trong các thực hành agile |

⚠ Ba phương án còn lại đều là SỰ KIỆN ĐỊNH KỲ: ⚠ buổi rà soát, họp đứng và hồi cứu đều diễn ra theo nhịp ⚠ — ⚠ chỉ lập trình cặp là hoạt động diễn ra liên tục trong lúc công việc đang được làm.

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

  • D (buổi hồi cứu sprint) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hồi cứu chính là nơi đội "nhìn lại và nhận ra điều gì chưa ổn" — nghe khớp gần như từng chữ với đề: ⚠ nhưng ⚠ hồi cứu nhìn lại CÁCH LÀM VIỆC sau khi vòng lặp đã kết thúc, tức là muộn nhất trong bốn phương án ⚠ — ⚠ còn đề mô tả năng lực "quan sát, rà soát và nhận ra khi có gì đó không đúng", một hành vi diễn ra trong lúc làm việc; ⚠ hồi cứu bắt được vấn đề về QUY TRÌNH; lập trình cặp bắt được vấn đề trong chính SẢN PHẨM, ngay lúc nó vừa sinh ra.

  • B (họp đứng hằng ngày) — ⚠ diễn ra mỗi ngày nhưng chỉ mười lăm phút và để đồng bộ, nêu vật cản; ⚠ nó không phải nơi rà soát công việc — liên hệ #26742 lô 200.

  • A (buổi rà soát sprint) — ⚠ trình diễn sản phẩm cho bên liên quan cuối vòng lặp; ⚠ muộn và hướng ra ngoài.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26793 cùng lô (các thực hành cốt lõi của XP), ⚠ #26740 lô 200 (rà soát mã giúp tránh làm lại), ⚠ #26695 lô 199 (TDD), ⚠ #26816 cùng lô (caves and commons — không gian làm việc), ⚠ #26704 lô 199 (hồi cứu).

⚠ CÁC VÒNG PHẢN HỒI trong agile — từ nhanh nhất tới chậm nhất: | Vòng | Chu kỳ | Bắt được gì | |---|---|---| | ⚠ LẬP TRÌNH CẶP | ⚠ từng phút — ĐÁP ÁN | ⚠ lỗi logic, thiết kế kém, hiểu sai yêu cầu | | ⚠ Kiểm thử đơn vị tự động | ⚠ từng phút | ⚠ lỗi chức năng — liên hệ #26695 lô 199 | | ⚠ Tích hợp liên tục | ⚠ từng giờ | ⚠ lỗi tích hợp — liên hệ #26793 cùng lô | | ⚠ Họp đứng hằng ngày | ⚠ mỗi ngày | ⚠ vật cản, lệch hướng trong ngày | | ⚠ Rà soát sprint | ⚠ mỗi vòng lặp | ⚠ sản phẩm có đúng ý khách không | | ⚠ Hồi cứu | ⚠ mỗi vòng lặp | ⚠ quy trình của đội có gì cần sửa | | ⚠ Nguyên tắc nền | ⚠ vòng phản hồi càng ngắn thì lỗi càng rẻ — toàn bộ thiết kế của agile xoay quanh việc rút ngắn các vòng này, và lập trình cặp là vòng ngắn nhất trong tất cả |

⚠ LẬP TRÌNH CẶP mang lại gì: | Lợi ích | Nội dung | |---|---| | ⚠ Rà soát mã theo thời gian thực | ⚠ thay thế được phần lớn việc rà soát sau — liên hệ #26740 lô 200 | | ⚠ Lan truyền tri thức trong đội | ⚠ giảm phụ thuộc vào một người | | ⚠ Thiết kế tốt hơn nhờ hai góc nhìn | | | ⚠ Ít bị phân tâm hơn | ⚠ khó lơ đãng khi có người ngồi cạnh | | ⚠ Người mới học nhanh hơn nhiều | ⚠ liên hệ #26819 cùng lô | | ⚠ Chi phí và cách nhìn đúng | ⚠ hai người một máy trông như tốn gấp đôi, nhưng phần lớn nghiên cứu cho thấy tổng chi phí tăng khoảng 15% trong khi số lỗi giảm mạnh — nó là một khoản đầu tư vào chất lượng, không phải một sự lãng phí nhân lực |

⚠ Lập trình cặp cần điều kiện gì: | Điều kiện | Nội dung | |---|---| | ⚠ Không gian làm việc phù hợp | ⚠ liên hệ #26816 cùng lô — caves and commons | | ⚠ Luân phiên cặp thường xuyên | ⚠ để tri thức lan ra cả đội chứ không chỉ giữa hai người | | ⚠ Nghỉ giải lao đều đặn | ⚠ cường độ tập trung cao hơn làm một mình | | ⚠ Văn hoá góp ý an toàn | ⚠ liên hệ #26700 lô 199 | | ⚠ Khi nào KHÔNG nên ghép cặp | ⚠ các việc đơn giản, lặp lại hoặc thuần tuý cơ học — ghép cặp cho những việc đó thật sự là lãng phí; hãy dành nó cho phần khó, phần mới và phần quan trọng |

Từ khoá nhận diện:

"quan sát và nhận ra sai sót ngay trong lúc làm" → ⚠ LẬP TRÌNH CẶP "nhìn lại cách làm việc sau vòng lặp" → ⚠ hồi cứu "đồng bộ mười lăm phút mỗi ngày" → ⚠ họp đứng "trình diễn cho bên liên quan" → ⚠ rà soát sprint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi trong đội bạn thường được phát hiện ở vòng phản hồi nào | | | Có phần nào của hệ thống chỉ một người hiểu không | | | Đội bạn có ghép cặp cho các phần khó không | |

Và điều mà hai người ngồi cùng một màn hình tạo ra mà không quy trình rà soát nào tạo được: sai sót được nhận ra trước khi nó kịp trở thành mã đã viết xong — và đó là thời điểm duy nhất mà việc sửa nó gần như không tốn gì.

Câu 366 Process
The main reason that the team at Global Digital News limits their development work in progress is
  1. A To best visualize and correct any major bottlenecks.
  2. B To ensure that the appropriate process is followed for each item.
  3. C Due to the limited time of the product owner to visualize the work in each iteration.
  4. D Each programmer can have no more than two items in queue per the Kanban methodology.
Xem giải thích

Đáp án

A — ĐỂ NHÌN THẤY RÕ VÀ XỬ LÝ CÁC NÚT THẮT CỔ CHAI LỚN.

Vì sao đúng

⚠ Vì sao giới hạn công việc đang làm lại làm lộ nút thắt: | Cơ chế | Nội dung | |---|---| | ⚠ Khi WIP bị giới hạn, công việc DỒN LẠI trước bước chậm nhất | ⚠ nút thắt hiện ra ngay trên bảng | | ⚠ Không giới hạn thì mọi cột đều đầy | ⚠ và không ai biết chỗ nào mới thật sự nghẽn | | ⚠ Người ở bước sau rảnh sẽ sang giúp bước nghẽn | ⚠ thay vì bắt đầu thêm việc mới | | ⚠ Giảm WIP làm giảm THỜI GIAN CHU KỲ | ⚠ theo định luật Little | | ⚠ Kết luận | ⚠ giới hạn WIP biến một vấn đề vô hình thành một vấn đề nhìn thấy được |

⚠ ĐỊNH LUẬT LITTLE: ⚠ thời gian chu kỳ = số việc đang làm ÷ thông lượng ⚠ — ⚠ giữ nguyên năng lực đội mà giảm số việc đang làm thì mỗi việc xong nhanh hơn; làm nhiều việc cùng lúc không làm xong nhiều hơn, chỉ làm mọi thứ xong muộn hơn.

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

  • B (để bảo đảm quy trình phù hợp được tuân thủ cho từng hạng mục) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ bảng Kanban đúng là thể hiện các bước của quy trình, nên việc giới hạn WIP có vẻ như để kiểm soát quy trình: ⚠ nhưng ⚠ giới hạn WIP không kiểm tra chất lượng hay sự tuân thủ của từng hạng mục — nó chỉ giới hạn SỐ LƯỢNG việc ở mỗi cột ⚠ — ⚠ thứ bảo đảm quy trình được tuân thủ là ĐỊNH NGHĨA HOÀN THÀNH và các tiêu chí chuyển cột, liên hệ #26748 lô 200; ⚠ hai cơ chế khác nhau, phục vụ hai mục đích khác nhau.

  • C (do chủ sản phẩm có ít thời gian để nhìn hết công việc mỗi vòng lặp) — ⚠ lý do bịa; ⚠ giới hạn WIP phục vụ dòng chảy công việc, không phục vụ lịch của chủ sản phẩm.

  • D (mỗi lập trình viên không được có quá hai việc trong hàng đợi theo phương pháp Kanban) — ⚠ Kanban KHÔNG quy định con số cố định nào; ⚠ giới hạn WIP do chính đội đặt ra và điều chỉnh dần dựa trên quan sát.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26757 lô 200 (biểu đồ kiểm soát — đo thời gian chờ ở khâu cuối), ⚠ #26709 lô 199 (các thước đo agile: thông lượng, thời gian chu kỳ), ⚠ #26714 lô 199 (bảng thông tin trực quan), ⚠ #26793 cùng lô (tích hợp liên tục — cũng là một cách giảm việc dở dang), ⚠ #26765 lô 200 (chia nhỏ hạng mục).

⚠ VÌ SAO NHIỀU VIỆC CÙNG LÚC LẠI CHẬM HƠN: | Vấn đề | Nội dung | |---|---| | ⚠ Chi phí CHUYỂN NGỮ CẢNH | ⚠ mỗi lần đổi việc mất thời gian lấy lại mạch | | ⚠ Công việc dở dang không tạo ra giá trị nào | ⚠ chỉ việc HOÀN THÀNH mới có giá trị | | ⚠ Lỗi được phát hiện muộn hơn | ⚠ vì mọi thứ đều chưa xong | | ⚠ Nút thắt bị che giấu | ⚠ ai cũng bận nên trông như mọi thứ đều ổn | | ⚠ Thời gian chu kỳ dài ra | ⚠ theo định luật Little | | ⚠ Câu hỏi kiểm tra hữu ích | ⚠ "đội đang làm bao nhiêu việc, và bao nhiêu việc đã thật sự XONG tuần này" — khoảng cách giữa hai con số đó chính là thứ mà giới hạn WIP thu hẹp lại |

⚠ Cách đặt giới hạn WIP cho hiệu quả: | Nguyên tắc | Nội dung | |---|---| | ⚠ Bắt đầu từ con số hiện tại rồi GIẢM DẦN | ⚠ không áp một con số lý thuyết ngay | | ⚠ Đặt giới hạn cho TỪNG CỘT, không chỉ cho cả bảng | ⚠ để thấy nút thắt nằm ở cột nào | | ⚠ Khi chạm giới hạn: KHÔNG bắt đầu việc mới | ⚠ quy tắc quan trọng nhất — sang giúp cột đang nghẽn | | ⚠ Quan sát rồi điều chỉnh | ⚠ giới hạn không phải hằng số | | ⚠ Đo thời gian chu kỳ để kiểm chứng hiệu quả | | | ⚠ Khẩu hiệu của Kanban | ⚠ "dừng bắt đầu, bắt đầu hoàn thành" — nghe đơn giản nhưng nó đảo ngược bản năng của gần như mọi đội đang chịu áp lực |

⚠ Xử lý nút thắt sau khi nhìn thấy nó: | Bước | Nội dung | |---|---| | ⚠ 1. Xác định cột nào công việc dồn lại | ⚠ đó là nút thắt | | ⚠ 2. Dồn nguồn lực vào cột đó | ⚠ người ở cột khác sang giúp | | ⚠ 3. Tìm nguyên nhân gốc | ⚠ thiếu người, thiếu kỹ năng, chờ phê duyệt, phụ thuộc bên ngoài | | ⚠ 4. Cải thiện năng lực của bước đó | ⚠ đào tạo, tự động hoá, bỏ bước thừa | | ⚠ 5. Tìm nút thắt tiếp theo | ⚠ luôn còn một cái — cải tiến là việc liên tục | | ⚠ Điểm cần nhớ | ⚠ cải thiện một bước KHÔNG PHẢI nút thắt thì tổng thông lượng không đổi — nó chỉ làm hàng chờ trước nút thắt dài thêm; đây là nguyên lý cốt lõi của lý thuyết ràng buộc và là lý do việc NHÌN THẤY nút thắt lại quan trọng tới vậy |

Từ khoá nhận diện:

"giới hạn công việc đang làm" → ⚠ NHÌN RA và XỬ LÝ NÚT THẮT "bảo đảm quy trình được tuân thủ" → ⚠ việc của định nghĩa hoàn thành và tiêu chí chuyển cột "tối đa hai việc mỗi người theo Kanban" → ⚠ Kanban không quy định con số nào định luật Little → ⚠ thời gian chu kỳ = việc đang làm ÷ thông lượng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi người trong đội bạn đang làm bao nhiêu việc cùng lúc | | | Bảng của bạn có giới hạn WIP cho từng cột không | | | Cột nào trên bảng luôn đầy nhất | ⚠ đó là nút thắt của bạn |

Và điều mà một con số nhỏ viết trên đầu mỗi cột làm được: nó buộc cả đội phải nhìn vào chỗ đang nghẽn thay vì mỗi người tự tìm thêm một việc mới để trông có vẻ bận rộn.

Câu 367 People
John is the project manager of a software development project. His organization has chosen to use the Scrum framework for software development projects. His team, however, does not have any agile experience. John explains the agile lifecycle and the iterative approach the project will take. John works with the product owner and the development team to help them better understand Scrum. Since this is a new team, John and the team elect to utilize a two-week approach for each sprint. The team is confused about what the product owner will do on the project and who is in charge. What is the primary role of the product owner?
  1. A To oversee the sprint review work that the team completes
  2. B To coach the team on user stories for the product backlog
  3. C To build the product scope
  4. D To maintain the product backlog
Xem giải thích

Đáp án

D — DUY TRÌ TỒN ĐỌNG SẢN PHẨM (maintain the product backlog).

Vì sao đúng

⚠ Vì sao đây là vai trò CHÍNH: | Lý do | Nội dung | |---|---| | ⚠ Tồn đọng sản phẩm là hiện vật do chủ sản phẩm SỞ HỮU | ⚠ duy nhất trong Scrum | | ⚠ Duy trì gồm: thêm, xoá, làm rõ và XẾP THỨ TỰ | ⚠ quyết định làm gì trước, làm gì sau | | ⚠ Qua đó chủ sản phẩm tối đa hoá GIÁ TRỊ của sản phẩm | ⚠ mục đích tồn tại của vai trò này | | ⚠ Đội mới với Scrum đang hỏi "ai là người phụ trách" | ⚠ câu trả lời rõ ràng: chủ sản phẩm phụ trách CÁI GÌ được làm | | ⚠ Kết luận | ⚠ tồn đọng là công cụ, và việc sở hữu nó chính là quyền lực của vai trò này |

⚠ Phân chia trách nhiệm trong Scrum, nói gọn: ⚠ CHỦ SẢN PHẨM quyết định LÀM GÌ; ĐỘI PHÁT TRIỂN quyết định LÀM THẾ NÀO và làm được BAO NHIÊU; SCRUM MASTER lo QUY TRÌNH và gỡ vật cản ⚠ — ⚠ không ai trong ba vai "làm sếp" của hai vai còn lại.

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

  • C (xây dựng phạm vi sản phẩm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chủ sản phẩm thật sự là người định hình sản phẩm sẽ có gì, nên "xây dựng phạm vi" nghe rất gần với sự thật: ⚠ nhưng ⚠ phạm vi trong agile KHÔNG được "xây dựng" một lần rồi cố định — nó tiến hoá liên tục qua tồn đọng ⚠ — ⚠ và cách nói "xây dựng phạm vi" mang màu sắc của vòng đời dự đoán; ⚠ cụm từ chính xác trong Scrum là DUY TRÌ TỒN ĐỌNG, vì nó chứa cả tính liên tục lẫn tính sở hữu.

  • B (huấn luyện đội về câu chuyện người dùng cho tồn đọng) — ⚠ hoạt động huấn luyện thường thuộc SCRUM MASTER; ⚠ chủ sản phẩm có tham gia làm rõ nhưng đó không phải vai trò chính.

  • A (giám sát công việc mà đội hoàn thành trong buổi rà soát sprint) — ⚠ chủ sản phẩm nghiệm thu hạng mục, nhưng "giám sát" không mô tả đúng vai trò; ⚠ và nó chỉ là một phần nhỏ trong một sự kiện.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26803 cùng lô (chủ sản phẩm và đội cùng xếp ưu tiên), ⚠ #26825 cùng lô (hậu quả khi tồn đọng không được xếp lại), ⚠ #26789 cùng lô (tinh chỉnh tồn đọng), ⚠ #26805 cùng lô (báo vật cản cho chủ sản phẩm), ⚠ #26765 lô 200 (chia nhỏ hạng mục).

⚠ BA VAI TRÒ TRONG SCRUM: | Vai | Chịu trách nhiệm về | KHÔNG làm gì | |---|---|---| | ⚠ CHỦ SẢN PHẨM | ⚠ GIÁ TRỊ — duy trì và xếp thứ tự tồn đọng — ĐÁP ÁN | ⚠ không quyết cách làm, không giao việc cho từng người | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ CÁCH LÀM và lượng việc nhận được | ⚠ không tự đổi thứ tự ưu tiên | | ⚠ SCRUM MASTER | ⚠ QUY TRÌNH, gỡ vật cản, huấn luyện | ⚠ không quản lý con người, không quyết nội dung | | ⚠ Câu hỏi của đội John | ⚠ "ai là người phụ trách" — câu trả lời đúng là KHÔNG AI phụ trách tất cả; ba vai chia nhau ba loại quyết định, và đó chính là điều làm một đội quen mô hình phân cấp thấy khó hiểu nhất khi mới chuyển sang Scrum |

⚠ Chủ sản phẩm duy trì tồn đọng nghĩa là làm gì: | Việc | Nội dung | |---|---| | ⚠ Diễn đạt rõ ràng từng hạng mục | | | ⚠ XẾP THỨ TỰ để tối đa hoá giá trị | ⚠ phần quan trọng nhất — liên hệ #26803 cùng lô | | ⚠ Bảo đảm tồn đọng MINH BẠCH và ai cũng xem được | | | ⚠ Bảo đảm đội hiểu các hạng mục ở mức cần thiết | | | ⚠ Cập nhật khi có thông tin mới từ bên liên quan | ⚠ liên hệ #26825 cùng lô | | ⚠ Điều quan trọng | ⚠ chủ sản phẩm có thể để người khác GIÚP làm các việc trên, nhưng vẫn là người CHỊU TRÁCH NHIỆM — và để vai trò này hoạt động, quyết định của họ phải được cả tổ chức tôn trọng, kể cả khi có người không đồng ý |

⚠ Lời khuyên cho John với một đội mới: | Việc | Nội dung | |---|---| | ⚠ Giải thích ba vai bằng CÂU HỎI mà mỗi vai trả lời | ⚠ cái gì / thế nào / quy trình | | ⚠ Cho đội thấy tồn đọng thật, không chỉ nói lý thuyết | | | ⚠ Bắt đầu bằng vòng lặp ngắn | ⚠ hai tuần như John đã chọn — hợp lý cho đội mới | | ⚠ Kiên nhẫn với các câu hỏi về thẩm quyền | ⚠ đây là câu hỏi mọi đội mới đều có | | ⚠ Làm mẫu bằng hành vi, không chỉ bằng giải thích | | | ⚠ Nhận xét | ⚠ việc đội hỏi "ai là người phụ trách" không phải là dấu hiệu họ chậm hiểu — nó là dấu hiệu họ đang cố ánh xạ mô hình mới vào mô hình cũ, và cách chữa là cho họ trải nghiệm một vài vòng lặp chứ không phải giải thích thêm một lần nữa |

Từ khoá nhận diện:

"vai trò chính của chủ sản phẩm" → ⚠ DUY TRÌ TỒN ĐỌNG SẢN PHẨM "xây dựng phạm vi" → ⚠ ngôn ngữ của vòng đời dự đoán "huấn luyện đội" → ⚠ thường là việc của scrum master ba vai → ⚠ CÁI GÌ / THẾ NÀO / QUY TRÌNH

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có biết ai quyết định thứ tự công việc không | | | Quyết định của chủ sản phẩm có được tôn trọng không | ⚠ hay vẫn bị các bên khác lật lại | | Tồn đọng của bạn có ai xem được không | |

Và điều mà một câu trả lời rõ ràng về vai trò mang lại cho một đội vừa chuyển sang Scrum: họ thôi tìm một người sếp trong ba cái tên, và bắt đầu hiểu rằng ba loại quyết định khác nhau đã được đặt vào ba chỗ khác nhau một cách có chủ ý.

Câu 368 Process
Jeremy is the project manager for Floor World. His latest project is to install new tile flooring in all of the company's buildings. Though his plan called for him to be done with 45 percent of the project by this time, Jeremy is only 40 percent done. His BAC is $600,000. What is the earned value?
  1. A $270,000
  2. B -$30,000
  3. C $240,000
  4. D $30,000
Xem giải thích

Đáp án

C — 240.000 ĐÔ LA.

Vì sao đúng

⚠ Phép tính giá trị thu được: | Bước | Phép tính | Kết quả | |---|---|---| | ⚠ Công thức | ⚠ EV = phần trăm HOÀN THÀNH THỰC TẾ × BAC | | | ⚠ Phần trăm hoàn thành thực tế | ⚠ 40% — con số THỰC TẾ, không phải kế hoạch | ⚠ 0,40 | | ⚠ Ngân sách khi hoàn thành | ⚠ BAC = 600.000 đô | | | ⚠ Thay số | ⚠ 0,40 × 600.000 | ⚠ 240.000 đô | | ⚠ Kết luận | ⚠ giá trị thu được là 240.000 đô | |

⚠ Chi tiết quyết định: ⚠ EV luôn dùng phần trăm THỰC TẾ hoàn thành, không dùng phần trăm kế hoạch ⚠ — ⚠ con số 45% trong đề là PV, và nó có mặt ở đó chỉ để gây nhiễu.

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

  • A (270.000 đô) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là kết quả của phép tính 45% × 600.000, tức là dùng nhầm con số KẾ HOẠCH thay cho con số THỰC TẾ: ⚠ nhưng ⚠ 45% × 600.000 = 270.000 chính là GIÁ TRỊ KẾ HOẠCH (PV), không phải giá trị thu được ⚠ — ⚠ đây là lỗi phổ biến nhất với dạng bài này, và người ra đề luôn đặt sẵn con số đó vào một phương án; ⚠ mẹo chống nhầm: gạch chân chữ "chỉ mới hoàn thành" trong đề — nó chỉ ra con số thực tế.

  • D (30.000 đô) — ⚠ là chênh lệch giữa PV và EV: 270.000 − 240.000; ⚠ đó là độ lớn của SAI LỆCH TIẾN ĐỘ, không phải EV.

  • B (−30.000 đô) — ⚠ chính là SAI LỆCH TIẾN ĐỘ SV = EV − PV = 240.000 − 270.000; ⚠ một con số đúng nhưng trả lời sai câu hỏi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26812 cùng lô (CÂU CẶP — cùng bối cảnh 45%/40%/BAC 600.000, hỏi CPI), ⚠ #26798 cùng lô (SPI để đo việc giao giá trị sớm), ⚠ #26795 cùng lô (đọc CPI và SPI cùng nhau), ⚠ #26559 lô 196 (bài tính EVM đầy đủ), ⚠ #26478 lô 194 (tính sai lệch chi phí).

⚠ Ghi chú về CÂU CẶP: ⚠ #26810 và #26812 cùng lô dùng CÙNG một bộ số liệu — kế hoạch 45%, thực tế 40%, BAC 600.000 ⚠ — ⚠ câu này hỏi EV và dừng ở đó; #26812 cho thêm AC = 270.000 rồi hỏi CPI; ⚠ giải câu này xong thì câu kia chỉ còn một phép chia — hãy nhận ra cặp này nếu gặp cả hai trong cùng đề thi.

⚠ Bốn con số nền của giá trị thu được: | Ký hiệu | Tên | Nghĩa | Trong đề này | |---|---|---|---| | ⚠ BAC | ⚠ ngân sách khi hoàn thành | ⚠ tổng ngân sách đã duyệt | ⚠ 600.000 | | ⚠ PV | ⚠ giá trị kế hoạch | ⚠ % KẾ HOẠCH × BAC | ⚠ 45% × 600.000 = 270.000 | | ⚠ EV | ⚠ giá trị thu được | ⚠ % THỰC TẾ × BAC — CÂU NÀY | ⚠ 40% × 600.000 = 240.000 | | ⚠ AC | ⚠ chi phí thực tế | ⚠ tiền đã tiêu thật | ⚠ đề này không cho — #26812 mới cho | | ⚠ Mẹo nhớ | ⚠ PV là "lẽ ra"; EV là "thực sự đã xong"; AC là "thực sự đã tiêu" — mọi công thức EVM đều chỉ là các phép cộng trừ nhân chia giữa ba con số này |

⚠ Các chỉ số suy ra được từ ba con số: | Chỉ số | Công thức | Ý nghĩa | |---|---|---| | ⚠ SV | ⚠ EV − PV | ⚠ sai lệch tiến độ — ở đây là −30.000, tức là CHẬM | | ⚠ SPI | ⚠ EV ÷ PV = 240.000 ÷ 270.000 = 0,89 | ⚠ dưới 1, chậm hơn kế hoạch — liên hệ #26798 cùng lô | | ⚠ CV | ⚠ EV − AC | ⚠ cần AC, không có trong đề này | | ⚠ CPI | ⚠ EV ÷ AC | ⚠ liên hệ #26812 cùng lô | | ⚠ Đọc kết quả của Jeremy | ⚠ SPI 0,89 nghĩa là cứ mỗi đồng công việc lẽ ra phải xong thì mới xong 0,89 đồng — dự án chậm khoảng 11% so với kế hoạch, và với dự án lát sàn thì đó thường là dấu hiệu về nguồn lực hoặc về tiếp cận mặt bằng |

⚠ Ba lỗi thường gặp khi tính EV: | Lỗi | Cách tránh | |---|---| | ⚠ Dùng % kế hoạch thay vì % thực tế | ⚠ gạch chân chữ "thực tế đã hoàn thành" — phương án A là bẫy này | | ⚠ Nhầm EV với AC | ⚠ EV là GIÁ TRỊ đã tạo ra, AC là TIỀN đã tiêu — hai thứ khác nhau | | ⚠ Trả lời bằng sai lệch thay vì bằng giá trị | ⚠ phương án B và D là bẫy này | | ⚠ Thói quen tốt | ⚠ viết ra cả ba con số PV, EV, AC trước khi tính bất cứ chỉ số nào — mất mười giây và loại được gần hết các phương án nhiễu |

Từ khoá nhận diện:

"đã hoàn thành thực tế X%" → ⚠ dùng cho EV "kế hoạch lẽ ra phải xong Y%" → ⚠ dùng cho PV EV → ⚠ % thực tế × BAC con số bằng hiệu của hai giá trị → ⚠ đó là SAI LỆCH, không phải giá trị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn tính % hoàn thành thực tế bằng cách nào | ⚠ theo cảm nhận hay theo quy tắc rõ ràng | | Dự án của bạn dùng quy tắc 0/100, 50/50 hay theo mốc | | | Bạn có ba con số PV, EV, AC cập nhật không | |

Và điều mà một phép nhân đơn giản đòi hỏi trước tiên: biết chắc con số phần trăm nào là thực tế và con số nào là kế hoạch — vì toàn bộ bài toán chỉ có một chỗ để sai, và người ra đề luôn đặt sẵn đáp số của cái sai đó vào danh sách.

Câu 369 Business Environment
Carla is a project manager for the Bore Corporation. She is launching a new project for her organization that will affect the entire organization and the community around the business headquarters. During a recent planning session, she noticed that several project requirements for this new project might violate local regulations. What is the next best step for Carla to take?
  1. A Speak with Bore Corporation’s legal team.
  2. B Adjust those tasks so that they do not violate regulations.
  3. C Remove those tasks from the project.
  4. D Escalate the issue to the steering committee.
Xem giải thích

Đáp án

A — TRAO ĐỔI VỚI BỘ PHẬN PHÁP CHẾ CỦA CÔNG TY.

Vì sao đúng

⚠ Vì sao đây là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Carla mới chỉ NGHI NGỜ rằng có vi phạm | ⚠ cô không phải luật sư và không có căn cứ chắc chắn | | ⚠ Bộ phận pháp chế có CHUYÊN MÔN để xác định | ⚠ vi phạm hay không, ở mức nào | | ⚠ Hậu quả của vi phạm quy định là PHI TUYẾN | ⚠ phạt, đình chỉ, mất giấy phép, tổn hại uy tín | | ⚠ Đang ở giai đoạn LẬP KẾ HOẠCH | ⚠ thời điểm rẻ nhất để phát hiện và sửa | | ⚠ Dự án ảnh hưởng cả tổ chức và cả CỘNG ĐỒNG xung quanh | ⚠ rủi ro tuân thủ càng cao | | ⚠ Kết luận | ⚠ xác minh với người có chuyên môn trước khi hành động |

⚠ Nguyên tắc không thương lượng: ⚠ tuân thủ pháp luật là ranh giới cứng — không có ngưỡng chấp nhận rủi ro nào cho việc vi phạm, và không mục tiêu dự án nào biện minh được cho nó ⚠ — ⚠ liên hệ #26775 lô 200 và #26792 cùng lô.

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

  • B (tự điều chỉnh các nhiệm vụ đó để không vi phạm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó chủ động, nhanh và có vẻ giải quyết được vấn đề ngay lập tức: ⚠ nhưng ⚠ Carla đang tự đánh giá một vấn đề PHÁP LÝ mà cô không có chuyên môn ⚠ — ⚠ cô có thể sửa nhầm chỗ, sửa chưa đủ, hoặc sửa một thứ vốn không hề vi phạm và làm mất giá trị của dự án; ⚠ và nếu về sau vẫn có vi phạm, việc cô đã tự ý sửa mà không hỏi ai sẽ khiến tình huống nghiêm trọng hơn nhiều.

  • C (loại các nhiệm vụ đó khỏi dự án) — ⚠ cực đoan hơn phương án B; ⚠ có thể cắt mất phần quan trọng của dự án chỉ vì một nghi ngờ chưa được xác minh.

  • D (leo thang lên ban chỉ đạo) — ⚠ chưa đúng thời điểm; ⚠ ban chỉ đạo cần một bức tranh rõ ràng để quyết định, và bức tranh đó phải do pháp chế cung cấp trước.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26775 lô 200 (hợp đồng không được chứa hoạt động bất hợp pháp), ⚠ #26797 cùng lô (giám sát tuân thủ trong lúc thực thi), ⚠ #26706 lô 199 (tài liệu tuân thủ), ⚠ #26792 cùng lô (rủi ro nào không được chấp nhận), ⚠ #26634 lô 198 (quy định mới xuất hiện giữa dự án).

⚠ RỦI RO TUÂN THỦ khác các rủi ro khác ở chỗ nào: | Đặc điểm | Nội dung | |---|---| | ⚠ KHÔNG có ngưỡng chấp nhận | ⚠ khác với rủi ro chi phí hay tiến độ — liên hệ #26792 cùng lô | | ⚠ Hậu quả không tỉ lệ với mức độ sai | ⚠ một vi phạm nhỏ vẫn có thể dẫn tới đình chỉ | | ⚠ Trách nhiệm có thể thuộc về cá nhân, không chỉ tổ chức | | | ⚠ Không thể chuyển giao hoàn toàn bằng hợp đồng | ⚠ liên hệ #26703 lô 199 | | ⚠ Thường xuất hiện ở nơi ít ai để ý | ⚠ quy định địa phương, quy định ngành, quy định môi trường | | ⚠ Cách xử lý đúng | ⚠ NÉ TRÁNH hoặc TUÂN THỦ ĐẦY ĐỦ — hai lựa chọn duy nhất; giảm nhẹ hay chấp nhận đều không áp dụng được cho loại rủi ro này |

⚠ Carla nên chuẩn bị gì khi gặp pháp chế: | Việc | Nội dung | |---|---| | ⚠ Liệt kê cụ thể các yêu cầu đáng ngờ | ⚠ không nói chung chung "có vẻ có vấn đề" | | ⚠ Nêu quy định nào cô nghĩ là bị chạm tới | | | ⚠ Giải thích bối cảnh dự án và mục tiêu kinh doanh | ⚠ để pháp chế đề xuất được cách làm hợp pháp thay thế | | ⚠ Hỏi về thời gian phản hồi | ⚠ để đưa vào tiến độ lập kế hoạch | | ⚠ Ghi lại kết luận bằng văn bản | ⚠ liên hệ #26706 lô 199 — tài liệu tuân thủ | | ⚠ Kết quả mong đợi | ⚠ pháp chế hiếm khi chỉ nói "được" hay "không được" — họ thường chỉ ra cách đạt được cùng mục tiêu theo con đường hợp pháp, và đó là lý do việc hỏi sớm có giá trị hơn nhiều so với việc tự sửa |

⚠ Sau khi có kết luận của pháp chế: | Kết luận | Việc tiếp theo | |---|---| | ⚠ Không vi phạm | ⚠ ghi lại kết luận vào hồ sơ tuân thủ và tiếp tục | | ⚠ Có vi phạm, sửa được | ⚠ điều chỉnh yêu cầu theo hướng dẫn, cập nhật phạm vi | | ⚠ Có vi phạm, không sửa được | ⚠ loại bỏ phần đó, đưa lên nhà tài trợ vì nó đổi trường hợp kinh doanh | | ⚠ Cần xin giấy phép hoặc phê duyệt | ⚠ đưa vào tiến độ như một công việc thật, thường mất nhiều thời gian | | ⚠ Trong mọi trường hợp | ⚠ ghi rủi ro tuân thủ vào sổ đăng ký rủi ro và tiếp tục theo dõi tới hết dự án — quy định có thể thay đổi giữa chừng, liên hệ #26634 lô 198 |

Từ khoá nhận diện:

"nghi ngờ vi phạm quy định" → ⚠ HỎI PHÁP CHẾ trước "tự sửa cho khỏi vi phạm" → ⚠ tự đánh giá vấn đề pháp lý không thuộc chuyên môn của mình "bỏ hẳn các nhiệm vụ đó" → ⚠ cực đoan khi chưa xác minh "leo thang ngay" → ⚠ ban chỉ đạo cần bức tranh rõ ràng trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết ai là đầu mối pháp chế cho dự án mình không | ⚠ biết trước khi cần là một phần của việc chuẩn bị | | Dự án bạn chạm tới những quy định nào | | | Kết luận pháp lý của bạn có được ghi lại không | ⚠ lời tư vấn miệng không giúp được gì khi bị kiểm toán |

Và điều mà việc gõ cửa phòng pháp chế trong giai đoạn lập kế hoạch mua được: một câu trả lời trước khi bất kỳ ai đầu tư công sức vào một thứ có thể phải bỏ đi — và trong quản lý tuân thủ, đó luôn là cuộc trò chuyện rẻ nhất mà bạn có thể có.

Câu 370 Process
Lila is the project manager for the Marble Project, a new project tasked to install marble countertops in all her company's apartments. Her plan called for her to be 45 percent done with the project at this point, but she is only 40 percent done. Her BAC is $600,000; she has spent $270,000. What is Lila's CPI?
  1. A 89
  2. B 100
  3. C 0.79
  4. D 0.89
Xem giải thích

Đáp án

D — 0,89.

Vì sao đúng

⚠ Tính từng bước: | Bước | Phép tính | Kết quả | |---|---|---| | ⚠ Giá trị thu được | ⚠ EV = % THỰC TẾ × BAC = 0,40 × 600.000 | ⚠ 240.000 đô | | ⚠ Chi phí thực tế | ⚠ AC = đề cho | ⚠ 270.000 đô | | ⚠ Chỉ số hiệu năng chi phí | ⚠ CPI = EV ÷ AC = 240.000 ÷ 270.000 | ⚠ 0,888… ≈ 0,89 | | ⚠ Đọc kết quả | ⚠ CPI dưới 1 → dự án đang VƯỢT CHI: mỗi đồng bỏ ra chỉ tạo được 0,89 đồng giá trị | |

⚠ CPI là một TỈ SỐ, không phải phần trăm và không phải số tiền ⚠ — ⚠ nó luôn được viết ở dạng thập phân quanh giá trị 1.

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

  • C (0,79) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là một tỉ số thập phân dưới 1, đúng dạng của CPI, nên trông hoàn toàn hợp lệ và người tính vội sẽ không thấy gì bất thường: ⚠ nhưng ⚠ không phép tính hợp lý nào từ các số liệu của đề cho ra 0,79 ⚠ — ⚠ nó là một con số được đặt vào để bắt những người ước lượng thay vì tính; ⚠ cách phòng: luôn thực hiện phép chia thật, 240 chia 270 chứ đừng đoán "khoảng tám mươi phần trăm".

  • A (89) — ⚠ đúng chữ số nhưng SAI ĐỊNH DẠNG; ⚠ CPI là tỉ số 0,89 chứ không phải 89 — đây là bẫy về đơn vị.

  • B (100) — ⚠ không tương ứng với phép tính nào; ⚠ có lẽ là ý "100%", tức là hoà vốn, nhưng dự án đang vượt chi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26810 cùng lô (CÂU CẶP — cùng bộ số liệu, hỏi EV), ⚠ #26795 cùng lô (đọc CPI 0,94 và SPI 1,01 cùng nhau), ⚠ #26798 cùng lô (chọn chỉ số theo ràng buộc của dự án), ⚠ #26559 lô 196 (bài EVM đầy đủ có EAC), ⚠ #26804 cùng lô (cập nhật ngân sách sau sai lệch).

⚠ Ghi chú về CÂU CẶP: ⚠ câu này dùng CÙNG bộ số liệu với #26810 cùng lô — kế hoạch 45%, thực tế 40%, BAC 600.000 ⚠ — ⚠ khác biệt duy nhất: ở đây đề cho thêm AC = 270.000 và hỏi CPI thay vì hỏi EV; ⚠ lưu ý con số 270.000 xuất hiện ở CẢ HAI câu nhưng với vai trò KHÁC NHAU: ở #26810 nó là PV (45% × 600.000), ở đây nó là AC (tiền đã tiêu) — một trùng hợp cố ý của người ra đề, và là chỗ dễ nhầm nhất khi làm liên tiếp hai câu.

⚠ ĐỌC CPI như thế nào: | Giá trị | Ý nghĩa | |---|---| | ⚠ CPI > 1 | ⚠ hiệu quả chi phí TỐT — tiêu ít hơn giá trị tạo ra | | ⚠ CPI = 1 | ⚠ đúng ngân sách | | ⚠ CPI < 1 | ⚠ VƯỢT CHI — trường hợp của Lila | | ⚠ CPI = 0,89 | ⚠ mỗi đồng chi ra chỉ tạo được 0,89 đồng giá trị, tức là kém hiệu quả khoảng 11% | | ⚠ Dự báo nhanh | ⚠ EAC = BAC ÷ CPI = 600.000 ÷ 0,89 ≈ 674.000 đô — nếu xu hướng hiện tại tiếp diễn thì dự án sẽ vượt ngân sách khoảng 74.000 đô, và đó là con số mà Lila cần báo cho bên liên quan, liên hệ #26804 cùng lô |

⚠ Bức tranh đầy đủ của dự án Marble: | Chỉ số | Phép tính | Kết quả | Ý nghĩa | |---|---|---|---| | ⚠ PV | ⚠ 0,45 × 600.000 | ⚠ 270.000 | ⚠ lẽ ra phải xong chừng này | | ⚠ EV | ⚠ 0,40 × 600.000 | ⚠ 240.000 | ⚠ thực tế xong chừng này | | ⚠ AC | ⚠ đề cho | ⚠ 270.000 | ⚠ đã tiêu chừng này | | ⚠ SV | ⚠ 240.000 − 270.000 | ⚠ −30.000 | ⚠ CHẬM tiến độ | | ⚠ CV | ⚠ 240.000 − 270.000 | ⚠ −30.000 | ⚠ VƯỢT chi | | ⚠ SPI | ⚠ 240.000 ÷ 270.000 | ⚠ 0,89 | ⚠ chậm 11% | | ⚠ CPI | ⚠ 240.000 ÷ 270.000 | ⚠ 0,89 | ⚠ vượt chi 11% — ĐÁP ÁN | | ⚠ Nhận xét | ⚠ SPI và CPI trùng nhau là vì AC tình cờ bằng PV — đây là một sự trùng hợp của bộ số liệu, không phải một quy luật; đừng suy ra rằng hai chỉ số này luôn bằng nhau |

⚠ Lila nên làm gì với con số này: | Việc | Nội dung | |---|---| | ⚠ Tính EAC và báo dự báo mới | ⚠ liên hệ #26804 cùng lô | | ⚠ Tìm nguyên nhân vượt chi | ⚠ giá vật liệu, năng suất, làm lại, ước lượng ban đầu quá lạc quan | | ⚠ Kiểm tra xem xu hướng có ổn định không | ⚠ một điểm dữ liệu chưa thành xu hướng | | ⚠ Đề xuất phương án cho bên liên quan | ⚠ xin thêm ngân sách, cắt phạm vi, hoặc chấp nhận | | ⚠ Điều đáng chú ý | ⚠ dự án vừa chậm vừa vượt chi cùng một lúc — mô thức này thường có một nguyên nhân chung, và tìm ra nó có giá trị hơn nhiều so với việc xử lý riêng lẻ hai triệu chứng |

Từ khoá nhận diện:

"CPI" → ⚠ EV ÷ AC, kết quả là một TỈ SỐ quanh 1 "89" không có dấu phẩy → ⚠ bẫy về định dạng con số không suy ra được từ đề → ⚠ bẫy dành cho người ước lượng thay vì tính chữ C → ⚠ cost, chi phí; chữ S là schedule, tiến độ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết CPI hiện tại của dự án mình không | | | Bạn có tính EAC từ nó chưa | | | CPI của bạn đang tăng hay giảm qua các kỳ báo cáo | ⚠ xu hướng quan trọng hơn một con số đơn lẻ |

Và điều mà một tỉ số 0,89 nói với Lila rõ hơn mọi bản báo cáo dài: nếu không có gì thay đổi, dự án lát đá này sẽ tốn khoảng 674 nghìn thay vì 600 nghìn — và con số đó cần tới bàn của bên liên quan hôm nay, chứ không phải ở tuần cuối cùng.