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

Tìm thấy 718 câu.

Câu 531 Business Environment
Cara comes to a project without knowing anybody on it. As part of her work to familiarize herself with the stakeholders, she creates an influence-interest matrix of all the stakeholders she meets. During a meeting with the sponsor, she refers to the matrix, which the sponsor asks to see. Cara shows it to the sponsor, who seems surprised that some of the stakeholders are included. The sponsor thanks Cara for bringing the fact to their attention. How is the project manager delivering project value?
  1. A Formalizing objectives
  2. B Mapping stakeholders
  3. C Identifying needs
  4. D Constructing key performance indicators
Xem giải thích

Đáp án

B — LẬP BẢN ĐỒ BÊN LIÊN QUAN (mapping stakeholders).

Vì sao đúng

⚠ Cara đang làm chính xác việc gì: | Hành động | Tên gọi | |---|---| | ⚠ Gặp và ghi nhận các bên liên quan | ⚠ nhận diện | | ⚠ Xếp họ lên ma trận ẢNH HƯỞNG – QUAN TÂM | ⚠ LẬP BẢN ĐỒ — chính là đáp án | | ⚠ Dùng bản đồ đó trong cuộc trao đổi với nhà tài trợ | ⚠ biến phân tích thành đối thoại | | ⚠ Nhà tài trợ phát hiện ra điều mình chưa biết | ⚠ giá trị được tạo ra ngay tại đó | | ⚠ Kết luận | ⚠ giá trị Cara mang lại là làm cho bức tranh bên liên quan trở nên NHÌN THẤY ĐƯỢC |

⚠ Chi tiết hay nhất của tình huống: ⚠ nhà tài trợ ngạc nhiên vì có những cái tên anh không ngờ tới, rồi CẢM ƠN Cara ⚠ — ⚠ một người mới hoàn toàn lại chỉ ra cho người kỳ cựu thấy điều họ bỏ sót, và đó chính là sức mạnh của một công cụ trực quan.

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

  • C (xác định nhu cầu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hiểu nhu cầu bên liên quan đúng là một cách tạo giá trị, và việc gặp gỡ từng người nghe rất giống việc thu thập nhu cầu: ⚠ nhưng ⚠ đề không hề nói Cara hỏi ai cần gì — cô ấy xếp họ theo MỨC ẢNH HƯỞNG và MỨC QUAN TÂM ⚠; ⚠ đó là hai chiều của một bản đồ quyền lực, không phải danh sách nhu cầu; ⚠ xác định nhu cầu là bước tiếp theo, sau khi đã biết cần hỏi ai và hỏi kỹ tới đâu.

  • A (chính thức hoá mục tiêu) — ⚠ liên quan tới việc biến mong muốn thành mục tiêu đo được; ⚠ không có gì như vậy trong tình huống.

  • D (xây dựng chỉ số hiệu suất chính) — ⚠ là việc thiết lập thước đo cho dự án; ⚠ hoàn toàn khác với việc lập bản đồ con người.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26957 cùng lô (nhận diện bên liên quan suốt vòng đời), ⚠ #26974 cùng lô (dùng bản đồ để chọn chiến lược thu hút), ⚠ #26955 cùng lô (bên liên quan vượt ranh giới), ⚠ #26757 lô 200 (phân tích quyền lực – quan tâm).

⚠ MA TRẬN QUYỀN LỰC – QUAN TÂM và chiến lược cho từng ô: | Ô | Chiến lược | |---|---| | ⚠ Quyền lực CAO – Quan tâm CAO | ⚠ QUẢN LÝ CHẶT: trao đổi thường xuyên, kéo vào quyết định | | ⚠ Quyền lực CAO – Quan tâm THẤP | ⚠ GIỮ HÀI LÒNG: báo cáo gọn, đừng làm phiền quá mức | | ⚠ Quyền lực THẤP – Quan tâm CAO | ⚠ GIỮ THÔNG TIN ĐỦ: họ là nguồn phản hồi tốt — ô của Craig, #26974 | | ⚠ Quyền lực THẤP – Quan tâm THẤP | ⚠ THEO DÕI: tốn ít công, nhưng vẫn để mắt | | ⚠ Điều cần nhớ | ⚠ vị trí của một người trên ma trận THAY ĐỔI theo giai đoạn dự án — người ở góc dưới hôm nay có thể lên góc trên khi dự án chạm tới bộ phận của họ; liên hệ #26957 cùng lô |

⚠ Các mô hình phân loại bên liên quan khác: | Mô hình | Trục phân loại | |---|---| | ⚠ Quyền lực – Quan tâm | ⚠ phổ biến nhất, Cara đang dùng | | ⚠ Quyền lực – Ảnh hưởng | | | ⚠ Ảnh hưởng – Tác động | | | ⚠ Mô hình nổi bật (salience) | ⚠ ba chiều: quyền lực, tính cấp bách, tính chính danh | | ⚠ Khối lập phương bên liên quan | ⚠ ba chiều, chi tiết hơn | | ⚠ Lời khuyên thực dụng | ⚠ mô hình hai chiều đơn giản thường đủ dùng và có một lợi thế lớn: nó vẽ được lên một tờ giấy và cho người khác xem — đúng như điều đã tạo ra giá trị trong tình huống này |

⚠ Vì sao một người MỚI lại lập được bản đồ tốt: | Lý do | Nội dung | |---|---| | ⚠ Không có định kiến sẵn về ai quan trọng | | | ⚠ Phải gặp từng người nên gặp cả người ít nổi bật | | | ⚠ Ghi lại một cách có hệ thống vì chưa thuộc ai | | | ⚠ Nhận xét | ⚠ người ở lâu thường có bản đồ trong đầu và không bao giờ vẽ nó ra — nên họ không phát hiện được phần mình bỏ sót; đó chính xác là điều đã xảy ra với nhà tài trợ trong câu này |

Từ khoá nhận diện:

"ma trận ảnh hưởng – quan tâm" → ⚠ LẬP BẢN ĐỒ BÊN LIÊN QUAN "xác định nhu cầu" → ⚠ bước tiếp theo, cần hỏi ai cần gì "chính thức hoá mục tiêu" → ⚠ biến mong muốn thành mục tiêu đo được "chỉ số hiệu suất chính" → ⚠ thước đo dự án, không phải bản đồ con người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có bản đồ bên liên quan vẽ ra được không | | | Bạn có cho nhà tài trợ xem nó bao giờ chưa | | | Ai vừa chuyển ô trong tháng qua | |

Và điều mà một bản đồ vẽ trên giấy làm được mà một bản đồ trong đầu thì không: cho người khác nhìn vào và nói "còn thiếu người này" — thứ mà không ai làm được với một danh sách chỉ tồn tại trong trí nhớ của bạn.

Câu 532 People
Craig is a junior software developer with relatively low influence at your organization. However, Craig is extraordinarily interested in a web design project that you are managing. Craig worked on a very similar project at his previous organization. Craig's project was fraught with risk, but his team delivered the project's deliverables successfully. How would you best manage Craig's engagement as a stakeholder?
  1. A Train Craig on the technical requirements for the project.
  2. B Invite Craig to help analyze project risks in all project work.
  3. C Ensure that you understand what Craig needs, include him in all team meetings, and ensure he receives project reports.
  4. D Meet with Craig periodically and keep him informed of risk reviews.
Xem giải thích

Đáp án

B — MỜI CRAIG THAM GIA PHÂN TÍCH RỦI RO TRONG TOÀN BỘ CÔNG VIỆC DỰ ÁN.

Vì sao đúng

⚠ Ghép ba dữ kiện về Craig: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ Ảnh hưởng THẤP trong tổ chức | ⚠ ô "quyền lực thấp – quan tâm cao" | | ⚠ QUAN TÂM đặc biệt cao tới dự án | ⚠ sẵn sàng dành thời gian | | ⚠ Đã làm dự án RẤT TƯƠNG TỰ ở công ty cũ | ⚠ kinh nghiệm trực tiếp áp dụng được | | ⚠ Dự án đó ĐẦY RỦI RO nhưng vẫn bàn giao thành công | ⚠ anh ấy biết rủi ro nào có thật và cách vượt qua | | ⚠ Kết luận | ⚠ dùng đúng thứ anh ấy có: kinh nghiệm rủi ro; và đáp ứng đúng thứ anh ấy muốn: được tham gia |

⚠ Đây là ví dụ mẫu mực về thu hút bên liên quan: ⚠ biến sự quan tâm thành đóng góp cụ thể, thay vì chỉ gửi báo cáo cho có ⚠ — ⚠ liên hệ #26928 lô 203: nhận diện rủi ro sớm là việc quan trọng nhất giai đoạn lập kế hoạch.

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

  • C (hiểu nhu cầu của Craig, mời anh dự MỌI buổi họp và gửi anh mọi báo cáo) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe rất chu đáo và đúng sách: hiểu nhu cầu, đưa vào cuộc, thông tin đầy đủ: ⚠ nhưng ⚠ đó là chiến lược dành cho ô "quyền lực CAO – quan tâm CAO", tức là quản lý chặt, còn Craig có ảnh hưởng THẤP ⚠; ⚠ mời một lập trình viên cấp thấp dự mọi buổi họp là tiêu tốn thời gian của anh ấy và của cả đội mà không tương xứng với vai trò; ⚠ và quan trọng hơn, nó KHÔNG DÙNG tới thứ quý nhất Craig có — kinh nghiệm rủi ro từ một dự án tương tự; ⚠ thu hút bên liên quan là ghép đúng đóng góp với đúng người, không phải mời tất cả vào tất cả.

  • D (gặp định kỳ và cập nhật cho anh ấy về các đợt rà soát rủi ro) — ⚠ đúng chủ đề nhưng biến Craig thành người NGHE; ⚠ trong khi anh ấy có thể là người đóng góp.

  • A (đào tạo Craig về yêu cầu kỹ thuật của dự án) — ⚠ đầu tư vào thứ anh ấy không thiếu; ⚠ Craig đã làm dự án tương tự, và điều này cũng chẳng mang lại gì cho dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26973 cùng lô (ma trận ảnh hưởng – quan tâm), ⚠ #26957 cùng lô (nhận diện bên liên quan suốt vòng đời), ⚠ #26928 lô 203 (rủi ro càng phát hiện sớm càng nhiều lựa chọn), ⚠ #26956 cùng lô (các chiến lược ứng phó rủi ro).

⚠ Vì sao ô "ảnh hưởng thấp – quan tâm cao" là mỏ vàng bị bỏ quên: | Đặc điểm | Nội dung | |---|---| | ⚠ Họ SẴN SÀNG dành thời gian | ⚠ khác với người bận ở ô quyền lực cao | | ⚠ Họ thường có kiến thức chuyên môn cụ thể | | | ⚠ Họ trở thành người ủng hộ trung thành nếu được coi trọng | | | ⚠ Chi phí thu hút gần bằng không | | | ⚠ Sai lầm phổ biến | ⚠ chỉ gửi bản tin cho nhóm này rồi coi như xong — trong khi họ là nhóm duy nhất thật sự đọc bản tin đó, và nhiều người trong số họ đủ sức đóng góp nhiều hơn thế rất nhiều |

⚠ Craig có thể đóng góp cụ thể gì: | Đóng góp | Nội dung | |---|---| | ⚠ Nêu các rủi ro anh ấy đã GẶP THẬT ở dự án cũ | ⚠ quý hơn động não lý thuyết rất nhiều | | ⚠ Cho biết biện pháp ứng phó nào đã hiệu quả | | | ⚠ Chỉ ra các giả định mà đội đang mặc định là đúng | | | ⚠ Cảnh báo về dấu hiệu kích hoạt rủi ro | ⚠ liên hệ #26956 cùng lô | | ⚠ Vì sao kinh nghiệm này hiếm | ⚠ rất ít tổ chức có sẵn người từng làm đúng loại dự án này và từng thất bại hụt trong đó — có một người như vậy đang muốn tham gia mà không dùng tới là một sự lãng phí đáng tiếc |

⚠ Nhớ giữ ranh giới cho đúng: | Nên | Không nên | |---|---| | ⚠ Mời tham gia các buổi phân tích rủi ro | ⚠ mời dự mọi buổi họp của đội | | ⚠ Ghi nhận đóng góp của anh ấy công khai | ⚠ để đóng góp trôi qua không ai biết | | ⚠ Thoả thuận với quản lý trực tiếp của Craig về thời gian | ⚠ lấy thời gian của anh ấy mà không hỏi ai | | ⚠ Cho anh ấy biết kết quả các rủi ro anh nêu ra | ⚠ hỏi xong rồi im lặng | | ⚠ Nhận xét | ⚠ Craig có ảnh hưởng thấp nghĩa là anh ấy không tự sắp xếp được thời gian của mình — nên bước đầu tiên và dễ quên nhất là xin phép quản lý của anh ấy |

Từ khoá nhận diện:

"ảnh hưởng thấp, quan tâm cao, có kinh nghiệm liên quan" → ⚠ MỜI ĐÓNG GÓP đúng chuyên môn "mời dự mọi họp, gửi mọi báo cáo" → ⚠ chiến lược cho ô quyền lực CAO "cập nhật cho anh ấy về rà soát rủi ro" → ⚠ biến người đóng góp thành người nghe "đào tạo kỹ thuật cho anh ấy" → ⚠ đầu tư vào thứ anh ấy không thiếu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong danh sách bên liên quan của bạn ai đang ở ô quan tâm cao – ảnh hưởng thấp | | | Có ai từng làm dự án tương tự mà bạn chưa hỏi không | | | Bạn đang gửi báo cáo cho ai mà lẽ ra nên mời họ đóng góp | |

Và điều mà chiến lược thu hút bên liên quan thật sự tối ưu: không phải mức độ thông tin mỗi người nhận được, mà mức độ khớp giữa thứ họ có thể cho và thứ dự án đang cần.

Câu 533 Process
Helen is the scrum master for Project S, eight iterations into deployment, has a velocity of 35 story points, and is one week ahead of schedule. During a recent sprint planning session, it was discovered that several user stories could not be implemented as critical infrastructure is missing. What should Helen do next?
  1. A Determine what is missing and add appropriate tasks to the backlog.
  2. B Remove those stories from Project S.
  3. C Speak with the product owner about deprioritizing those stories.
  4. D Do nothing. The project team will figure it out.
Xem giải thích

Đáp án

A — XÁC ĐỊNH PHẦN CÒN THIẾU VÀ BỔ SUNG CÁC CÔNG VIỆC TƯƠNG ỨNG VÀO TỒN ĐỌNG.

Vì sao đúng

⚠ Vì sao đây là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Hạ tầng thiếu là một PHỤ THUỘC, không phải một lỗi | ⚠ nó chỉ chưa được nhận diện thôi | | ⚠ Công việc hạ tầng là công việc THẬT | ⚠ nên nó thuộc về tồn đọng | | ⚠ Đưa vào tồn đọng thì nó được nhìn thấy và ước lượng | ⚠ thay vì làm lén hoặc bỏ quên | | ⚠ Các câu chuyện phụ thuộc vẫn còn giá trị | ⚠ chỉ là chưa tới lượt | | ⚠ Dự án đang SỚM hơn tiến độ một tuần | ⚠ có dư địa để xử lý | | ⚠ Kết luận | ⚠ biến một vật cản thành các mục công việc rõ ràng, rồi để chủ sản phẩm xếp thứ tự |

⚠ Nguyên tắc chung: ⚠ mọi thứ cần làm để bàn giao giá trị đều phải nằm trong tồn đọng ⚠ — ⚠ hạ tầng, công cụ, thiết lập môi trường, tài liệu bắt buộc; thứ không nằm trong tồn đọng thì không được ước lượng và không ai lên kế hoạch cho nó.

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

  • C (bàn với chủ sản phẩm để hạ mức ưu tiên của các câu chuyện đó) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó tôn trọng đúng vai trò của chủ sản phẩm và về mặt thực tế thì các câu chuyện đó đúng là sẽ phải lùi lại: ⚠ nhưng ⚠ nó chỉ xử lý TRIỆU CHỨNG mà bỏ qua nguyên nhân — hạ tầng vẫn thiếu, và nó sẽ chặn đúng những câu chuyện đó ở chặng sau, rồi chặng sau nữa ⚠; ⚠ hạ mức ưu tiên mà không thêm việc xây hạ tầng nghĩa là đẩy vấn đề đi chứ không giải quyết nó; ⚠ cách đúng là làm cả hai: thêm công việc hạ tầng vào tồn đọng, rồi để chủ sản phẩm quyết thứ tự của cả nhóm việc đó.

  • B (loại các câu chuyện đó khỏi dự án) — ⚠ vứt bỏ giá trị vì một trở ngại tạm thời; ⚠ và chỉ chủ sản phẩm mới có quyền bỏ một câu chuyện.

  • D (không làm gì, đội sẽ tự xoay xở) — ⚠ bỏ mặc một vật cản đã được nhận diện; ⚠ trái ngược với vai trò dọn vật cản của scrum master.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26961 cùng lô (rà soát việc mới cùng chủ sản phẩm), ⚠ #26969 cùng lô (làm rõ thứ tự ưu tiên), ⚠ #26912 lô 203 (xác định phụ thuộc), ⚠ #26966 cùng lô (nợ kỹ thuật cũng phải nằm trong tồn đọng).

⚠ Những loại công việc hay bị quên khỏi tồn đọng: | Loại | Ví dụ | |---|---| | ⚠ Hạ tầng và môi trường | ⚠ máy chủ, đường ống triển khai — trường hợp này | | ⚠ Công việc kỹ thuật nền | ⚠ thư viện dùng chung, khung kiểm thử | | ⚠ Nợ kỹ thuật đã nhận | ⚠ liên hệ #26966 cùng lô | | ⚠ Tài liệu bắt buộc theo quy định | ⚠ liên hệ #26960 cùng lô | | ⚠ Đào tạo và chuyển giao vận hành | | | ⚠ Hậu quả của việc bỏ quên | ⚠ vận tốc của đội trông như giảm mà không ai giải thích được — vì họ vẫn làm việc nhưng phần lớn công sức chảy vào những việc không có trên bảng; liên hệ #26841 lô 202 |

⚠ Vì sao phát hiện được ở buổi lập kế hoạch là tin tốt: | So sánh | Nội dung | |---|---| | ⚠ Phát hiện lúc LẬP KẾ HOẠCH | ⚠ chưa cam kết, còn đổi được — trường hợp này | | ⚠ Phát hiện GIỮA chặng | ⚠ cam kết đã đưa ra, phải điều chỉnh giữa chừng | | ⚠ Phát hiện ở buổi RÀ SOÁT | ⚠ bên liên quan chứng kiến việc không bàn giao được | | ⚠ Nhận xét | ⚠ buổi lập kế hoạch chặng tồn tại chính là để những chuyện như thế này lộ ra — nên phát hiện ra một phụ thuộc bị bỏ sót ở đây là dấu hiệu quy trình đang hoạt động, không phải dấu hiệu ai đó đã sai |

⚠ Các bước Helen nên làm theo thứ tự: | Bước | Nội dung | |---|---| | ⚠ 1. Cùng đội xác định CHÍNH XÁC hạ tầng nào còn thiếu | | | ⚠ 2. Viết thành các mục công việc cụ thể | | | ⚠ 3. Ước lượng chúng | | | ⚠ 4. Đưa vào tồn đọng để chủ sản phẩm xếp thứ tự | | | ⚠ 5. Chọn việc khác cho chặng này | ⚠ đội vẫn có việc làm, không đứng chờ | | ⚠ Điều nên nói với bên liên quan | ⚠ nêu sớm rằng thứ tự bàn giao sẽ đổi và vì sao — dự án đang sớm một tuần nên đây là tin nhẹ, và một tin nhẹ được báo sớm luôn tốt hơn một tin nặng được báo muộn |

Từ khoá nhận diện:

"thiếu hạ tầng nên không làm được" → ⚠ THÊM VIỆC vào tồn đọng "hạ mức ưu tiên các câu chuyện đó" → ⚠ xử lý triệu chứng, hạ tầng vẫn thiếu "loại khỏi dự án" → ⚠ vứt bỏ giá trị vì trở ngại tạm thời "đội sẽ tự xoay xở" → ⚠ bỏ mặc vật cản đã nhận diện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tồn đọng của bạn có các mục hạ tầng và kỹ thuật không | | | Có công việc nào đội đang làm mà không có trên bảng không | | | Buổi lập kế hoạch của bạn có kiểm tra phụ thuộc không | |

Và điều mà việc đưa một vật cản vào tồn đọng thay đổi ngay lập tức: nó thôi là một lời phàn nàn và trở thành một hạng mục công việc có người làm, có ước lượng và có thứ tự — tức là một thứ sẽ thật sự được giải quyết.

Câu 534 Process
Jon is the scrum master for Project CAD, intended to revamp a company's website with catalog and purchasing service, chat functionality, and other new features. During a planning session for the project, Jon is asked to offer a ROM estimate. What is the best place for information to help Jon with this task?
  1. A Examine the set of requirements offered by the product owner.
  2. B Consult with other scrum masters he knows.
  3. C He cannot, because as an agile project, the budget and scope frequently change.
  4. D Ask his project team about other projects they have worked on together.
Xem giải thích

Đáp án

A — XEM XÉT BỘ YÊU CẦU DO CHỦ SẢN PHẨM CUNG CẤP.

Vì sao đúng

⚠ Vì sao yêu cầu là nguồn đúng cho ước lượng thô: | Lý do | Nội dung | |---|---| | ⚠ Ước lượng phải xuất phát từ PHẠM VI công việc | ⚠ không có phạm vi thì không có gì để ước lượng | | ⚠ Chủ sản phẩm là người sở hữu yêu cầu | ⚠ nguồn có thẩm quyền duy nhất | | ⚠ Đề đã liệt kê phạm vi khá rõ | ⚠ danh mục, mua hàng, trò chuyện, tính năng mới | | ⚠ ROM chỉ cần độ chính xác thô | ⚠ thường −25% tới +75% | | ⚠ Kết luận | ⚠ có yêu cầu ở mức khái quát là đủ để đưa ra một ước lượng thô có căn cứ |

⚠ ROM không phải là đoán bừa: ⚠ nó là một ước lượng có căn cứ với biên độ rộng và được tuyên bố rõ là rộng ⚠ — ⚠ giá trị của nó nằm ở chỗ giúp quyết định có nên theo đuổi dự án hay không.

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

  • C (không thể ước lượng, vì dự án agile thì ngân sách và phạm vi luôn thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó dựa trên một sự thật: agile đúng là để phạm vi linh hoạt, và nhiều người kết luận từ đó rằng agile không ước lượng dài hạn: ⚠ nhưng ⚠ đó là hiểu nhầm phổ biến nhất về agile ⚠ — ⚠ agile vẫn ước lượng, vẫn có lộ trình, vẫn trả lời được câu "khoảng bao nhiêu tiền"; ⚠ cái khác biệt là ước lượng được nêu kèm mức bất định và được cập nhật liên tục, chứ không phải là không có ước lượng; ⚠ một dự án không đưa ra được con số nào sẽ không được cấp vốn — và "chúng tôi làm agile" không phải là câu trả lời chấp nhận được cho một nhà tài trợ; ⚠ liên hệ #26981 cùng lô về lập kế hoạch dài hạn trong agile.

  • D (hỏi đội xem họ từng làm dự án nào khác cùng nhau) — ⚠ dữ liệu lịch sử của đội có ích cho vận tốc; ⚠ nhưng nó không cho biết dự án NÀY cần làm những gì.

  • B (hỏi các scrum master khác mà anh ấy quen) — ⚠ họ không biết phạm vi dự án của Jon; ⚠ có thể hữu ích để đối chiếu phương pháp, không hữu ích để ra con số.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26962 cùng lô (phạm vi là nền của mọi quyết định nguồn lực), ⚠ #26981 cùng lô (lộ trình theo quý), ⚠ #26919 lô 203 (mốc chuẩn cho điểm câu chuyện), ⚠ #26938 cùng lô (đường cong học tập ảnh hưởng ước lượng).

⚠ Ba mức độ chính xác của ước lượng: | Mức | Biên độ | Dùng khi | |---|---|---| | ⚠ ROM (thô) | ⚠ −25% tới +75% | ⚠ giai đoạn khởi đầu, quyết định có làm hay không | | ⚠ Ngân sách sơ bộ | ⚠ −10% tới +25% | ⚠ khi đã có kế hoạch sơ bộ | | ⚠ Ước lượng xác định | ⚠ −5% tới +10% | ⚠ khi đã có thiết kế chi tiết | | ⚠ Điều bắt buộc phải làm | ⚠ luôn NÊU RÕ mức độ chính xác kèm con số — một con số ROM đưa ra trần trụi sẽ được nhớ như một cam kết, và nó sẽ quay lại vào tháng thứ sáu; liên hệ #26912 lô 203 |

⚠ Ước lượng thô trong dự án agile làm thế nào: | Cách | Nội dung | |---|---| | ⚠ Chia yêu cầu thành các khối lớn (epic) | | | ⚠ Ước lượng tương đối bằng cỡ áo hoặc điểm | ⚠ S, M, L, XL | | ⚠ Dùng vận tốc dự kiến để quy ra số chặng | ⚠ cần một mốc chuẩn — liên hệ #26919 lô 203 | | ⚠ Nhân với chi phí mỗi chặng | | | ⚠ Nêu kết quả dưới dạng KHOẢNG | ⚠ "8 đến 14 chặng", không phải "11 chặng" | | ⚠ Vì sao nêu khoảng lại thuyết phục hơn | ⚠ một con số đơn lẻ ngụ ý mức chính xác mà bạn không có; một khoảng nói đúng những gì bạn biết, và người nghe có kinh nghiệm luôn tin khoảng hơn tin điểm |

⚠ Cải thiện độ chính xác theo thời gian: | Thời điểm | Nội dung | |---|---| | ⚠ Đầu dự án | ⚠ chỉ có yêu cầu khái quát, biên độ rộng nhất | | ⚠ Sau 2–3 chặng | ⚠ đã có vận tốc thật, biên độ hẹp lại nhiều | | ⚠ Giữa dự án | ⚠ dự báo khá tin cậy | | ⚠ Nguyên tắc | ⚠ cam kết lại ước lượng ở mỗi mốc thay vì bảo vệ con số ban đầu — hình nón bất định hẹp lại một cách tự nhiên, và việc của bạn là cập nhật theo nó chứ không phải giữ nguyên con số cũ cho khỏi mất mặt |

Từ khoá nhận diện:

"cần ước lượng thô ROM" → ⚠ bắt đầu từ BỘ YÊU CẦU của chủ sản phẩm "agile nên không ước lượng được" → ⚠ hiểu nhầm phổ biến nhất về agile "hỏi các dự án cũ của đội" → ⚠ cho vận tốc, không cho phạm vi "hỏi scrum master khác" → ⚠ họ không biết phạm vi dự án này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng gần nhất của bạn có nêu kèm biên độ không | | | Bạn có cập nhật lại ước lượng sau vài chặng không | | | Nhà tài trợ của bạn có hiểu ROM nghĩa là gì không | |

Và điều làm nên khác biệt giữa một ước lượng thô có ích và một con số vô trách nhiệm: không phải độ chính xác, mà việc người nghe được cho biết chính xác tới đâu.

Câu 535 Business Environment
Olga is the project manager for Ballers Corporation. During a recent stakeholder meeting, Olga updates the stakeholders on the project's status, including how Ballers Corporation is benefiting from recent updates. One of the stakeholders asks how Olga can determine how Ballers Corporation benefits from the project. How is Olga likely to respond?
  1. A By measuring the benefits, each deliverable provides
  2. B By using qualitative analysis
  3. C By asking a consultant to determine the value
  4. D By asking the project team to report on perceived benefits
Xem giải thích

Đáp án

A — BẰNG CÁCH ĐO LƯỜNG LỢI ÍCH MÀ TỪNG SẢN PHẨM BÀN GIAO MANG LẠI.

Vì sao đúng

⚠ Vì sao đo từng sản phẩm bàn giao là cách đúng: | Lý do | Nội dung | |---|---| | ⚠ Lợi ích được tạo ra bởi SẢN PHẨM BÀN GIAO, không phải bởi hoạt động | ⚠ đó là đơn vị đúng để đo | | ⚠ Đo được thì chứng minh được, không cần tranh cãi | | | ⚠ Từng phần có thể đo ngay khi bàn giao | ⚠ không phải chờ tới cuối dự án | | ⚠ Cho biết phần nào có giá trị, phần nào không | ⚠ thông tin để xếp lại ưu tiên | | ⚠ Kết luận | ⚠ câu trả lời phải dựa trên số liệu khách quan, và đơn vị đo là sản phẩm bàn giao |

⚠ Gắn với kế hoạch quản lý lợi ích: ⚠ mỗi lợi ích mục tiêu phải có chỉ số đo và người chịu trách nhiệm theo dõi ⚠ — ⚠ liên hệ #26958 cùng lô.

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

  • B (dùng phân tích định tính) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ có những lợi ích thật sự khó lượng hoá — tinh thần nhân viên, uy tín thương hiệu — nên phân tích định tính nghe như một công cụ hợp lệ: ⚠ nhưng ⚠ bên liên quan đang hỏi công ty ĐƯỢC GÌ, và câu trả lời bằng nhận định chủ quan không thuyết phục được ai ⚠; ⚠ ngay cả lợi ích vô hình cũng có thể gắn với chỉ số gián tiếp: tỷ lệ nghỉ việc, điểm hài lòng, số lượt nhắc tới thương hiệu; ⚠ định tính bổ sung cho định lượng chứ không thay thế nó, và trong một buổi báo cáo cho bên liên quan thì con số luôn phải đi trước.

  • D (hỏi đội dự án cảm nhận về lợi ích) — ⚠ cảm nhận của người trong cuộc là nguồn thiên lệch nhất có thể; ⚠ ai cũng nghĩ việc mình làm là có giá trị.

  • C (thuê tư vấn xác định giá trị) — ⚠ tốn kém và không cần thiết; ⚠ Olga hoàn toàn tự đo được nếu kế hoạch đã có chỉ số.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26958 cùng lô (kế hoạch quản lý lợi ích), ⚠ #26971 cùng lô (các thành phần giá trị kinh doanh), ⚠ #26917 lô 203 (nhắc lại giá trị đã bàn giao cho bên liên quan), ⚠ #26906 lô 203 (chỉ số hiệu suất chính).

⚠ Đo lợi ích của một sản phẩm bàn giao thế nào: | Bước | Nội dung | |---|---| | ⚠ 1. Xác định lợi ích kỳ vọng TRƯỚC khi làm | ⚠ nếu không thì sau này chỉ còn cách biện minh | | ⚠ 2. Chọn chỉ số đo và mốc so sánh ban đầu | ⚠ không có mốc gốc thì không đo được cải thiện | | ⚠ 3. Đo lại sau khi bàn giao và ổn định | ⚠ cho một khoảng thời gian đủ dài | | ⚠ 4. Quy đổi ra giá trị nghiệp vụ nếu được | ⚠ tiền, thời gian tiết kiệm, doanh thu thêm | | ⚠ 5. Báo cáo cho bên liên quan bằng ngôn ngữ của họ | | | ⚠ Bước bị bỏ qua nhiều nhất | ⚠ bước 2 — không ai đo trạng thái TRƯỚC khi thay đổi, nên sau đó không thể chứng minh được điều gì; và lúc nhận ra thì đã quá muộn để quay lại đo |

⚠ Ví dụ chỉ số cho các loại lợi ích: | Loại lợi ích | Chỉ số | |---|---| | ⚠ Tiết kiệm chi phí | ⚠ chi phí vận hành trước và sau | | ⚠ Tăng doanh thu | ⚠ doanh số từ tính năng mới | | ⚠ Tăng hiệu suất | ⚠ thời gian xử lý một giao dịch | | ⚠ Cải thiện chất lượng | ⚠ tỷ lệ lỗi, số khiếu nại | | ⚠ Lợi ích vô hình | ⚠ khảo sát, tỷ lệ giữ chân, điểm hài lòng | | ⚠ Nguyên tắc | ⚠ mọi lợi ích đều đo được ở một mức nào đó — thứ thường thiếu không phải là cách đo mà là ai đó chịu trách nhiệm đo, và điều đó phải được giao từ lúc lập kế hoạch |

⚠ Vì sao câu hỏi của bên liên quan là câu hỏi tốt: | Ý nghĩa | Nội dung | |---|---| | ⚠ Họ đang chuyển từ hỏi "tiến độ thế nào" sang hỏi "được gì" | ⚠ dấu hiệu của bên liên quan trưởng thành | | ⚠ Nó buộc dự án phải chứng minh giá trị | | | ⚠ Nó tạo cơ hội xếp lại ưu tiên theo giá trị thật | | | ⚠ Nhận xét | ⚠ nếu Olga trả lời được bằng số ngay tại chỗ thì cô ấy đã làm đúng phần lập kế hoạch từ đầu; còn nếu phải hẹn trả lời sau thì đó là dấu hiệu kế hoạch quản lý lợi ích chưa được lập — và đó cũng là một câu trả lời hữu ích, chỉ là khó nghe hơn |

Từ khoá nhận diện:

"làm sao biết công ty được lợi gì" → ⚠ ĐO LỢI ÍCH của từng sản phẩm bàn giao "phân tích định tính" → ⚠ bổ sung, không thay thế con số "hỏi đội cảm nhận" → ⚠ nguồn thiên lệch nhất "thuê tư vấn" → ⚠ tốn kém và không cần thiết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi sản phẩm bàn giao của bạn có chỉ số lợi ích không | | | Bạn có đo trạng thái trước khi thay đổi không | | | Ai chịu trách nhiệm đo sau khi dự án đóng | |

Và câu hỏi mà mọi dự án nên trả lời được bất cứ lúc nào bị hỏi: thứ chúng ta vừa bàn giao đã thay đổi được con số nào — vì nếu không có con số nào đổi, thì rất khó nói là đã có gì thay đổi.

Câu 536 Process
Eugene is the project manager for the Orange Project, which is in its planning stage. The organization is a matrix structure and Eugene has authority over the project team. His project team has informed him they require several pieces of equipment currently being used by other projects at their company. What should Eugene do?
  1. A Purchase additional pieces of equipment.
  2. B Submit a purchase order to the teams using the equipment.
  3. C Develop a project calendar for resource utilization.
  4. D Meet with the other teams to negotiate a time to use the equipment.
Xem giải thích

Đáp án

D — GẶP CÁC ĐỘI KHÁC ĐỂ THƯƠNG LƯỢNG THỜI GIAN SỬ DỤNG THIẾT BỊ.

Vì sao đúng

⚠ Vì sao thương lượng là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Thiết bị đang được dùng, không phải không tồn tại | ⚠ vấn đề là LỊCH, không phải thiếu tài sản | | ⚠ Tổ chức ma trận nghĩa là nguồn lực DÙNG CHUNG | ⚠ thương lượng là cách làm việc chuẩn ở đây | | ⚠ Dự án đang ở giai đoạn LẬP KẾ HOẠCH | ⚠ còn thời gian để sắp xếp lịch | | ⚠ Giải pháp rẻ nhất và nhanh nhất | ⚠ không tốn thêm đồng nào | | ⚠ Kết luận | ⚠ thương lượng trước, các phương án tốn kém chỉ dùng khi thương lượng thất bại |

⚠ Kỹ năng cốt lõi trong tổ chức ma trận: ⚠ người quản lý dự án có thẩm quyền với đội nhưng KHÔNG sở hữu nguồn lực dùng chung ⚠ — ⚠ nên thương lượng và xây quan hệ với các đội khác là công cụ chính.

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

  • C (lập lịch sử dụng nguồn lực cho dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ lịch nguồn lực đúng là công cụ chuẩn của quản lý nguồn lực, và nó nghe rất "đúng quy trình": ⚠ nhưng ⚠ lập lịch một mình chỉ ghi lại thời điểm bạn MUỐN dùng, nó không tạo ra quyền được dùng ⚠ — ⚠ các đội khác không biết và không bị ràng buộc gì bởi cái lịch đó; ⚠ thứ tự đúng là THƯƠNG LƯỢNG trước để có cam kết, rồi mới đưa vào lịch — làm ngược lại sẽ tạo ra một bản kế hoạch trông chắc chắn mà thực tế không ai đồng ý.

  • A (mua thêm thiết bị) — ⚠ tốn kém khi tổ chức đã có sẵn; ⚠ và mua trước khi thử thương lượng là bỏ qua giải pháp rẻ nhất.

  • B (gửi đơn đặt hàng cho các đội đang dùng thiết bị) — ⚠ hiểu sai cơ chế; ⚠ đơn đặt hàng dùng để mua từ nhà cung cấp bên ngoài, không dùng để đòi nguồn lực nội bộ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26962 cùng lô (lập đội từ phạm vi và nguồn lực sẵn có), ⚠ #26933 cùng lô (thương lượng hướng tới cùng thắng), ⚠ #26979 cùng lô (xử lý xung đột giữa các bên), ⚠ #26978 liên hệ với cấu trúc tổ chức ma trận.

⚠ Quyền lực của người quản lý dự án theo cấu trúc tổ chức: | Cấu trúc | Quyền của PM | |---|---| | ⚠ Chức năng | ⚠ rất thấp, gần như là người điều phối | | ⚠ Ma trận yếu | ⚠ thấp, quản lý chức năng nắm nguồn lực | | ⚠ Ma trận cân bằng | ⚠ trung bình, chia sẻ quyền | | ⚠ Ma trận mạnh | ⚠ cao — trường hợp của Eugene | | ⚠ Dự án hoá (projectized) | ⚠ gần như toàn quyền | | ⚠ Điểm quan trọng của câu này | ⚠ Eugene có quyền với ĐỘI của mình, nhưng thiết bị là tài sản dùng chung của tổ chức — quyền với con người trong đội không tự động thành quyền với tài sản mà đội khác đang dùng |

⚠ Chuẩn bị gì trước khi thương lượng với đội khác: | Việc | Nội dung | |---|---| | ⚠ Biết chính xác cần thiết bị nào, khi nào, bao lâu | ⚠ đề nghị mơ hồ luôn bị từ chối | | ⚠ Tìm hiểu lịch của họ trước | ⚠ có thể có khoảng trống bạn dùng được | | ⚠ Chuẩn bị phương án linh hoạt | ⚠ ca đêm, cuối tuần, chia nhỏ thời gian | | ⚠ Nghĩ xem bạn có gì để đổi lại | ⚠ nguồn lực khác, hỗ trợ kỹ thuật, thứ tự ưu tiên | | ⚠ Biết mức độ ưu tiên của dự án mình trong tổ chức | ⚠ để biết khi nào nên leo thang | | ⚠ Nếu thương lượng thất bại | ⚠ lúc đó mới leo thang lên nhà tài trợ hoặc PMO, và lúc đó mới cân nhắc thuê hoặc mua — nhưng phải mang theo bằng chứng rằng đã thử thương lượng |

⚠ Xung đột nguồn lực là chuyện bình thường, không phải sự cố: | Ý nghĩa | Nội dung | |---|---| | ⚠ Ma trận sinh ra chính là để dùng chung nguồn lực | | | ⚠ Nếu không bao giờ có xung đột thì tổ chức đang thừa tài sản | | | ⚠ Điều quan trọng là phát hiện SỚM | ⚠ Eugene đang ở giai đoạn lập kế hoạch, rất tốt | | ⚠ Nhận xét | ⚠ thứ phân biệt một người quản lý dự án có kinh nghiệm trong tổ chức ma trận không phải là tránh được xung đột nguồn lực, mà là phát hiện nó từ giai đoạn lập kế hoạch thay vì từ tuần cần dùng |

Từ khoá nhận diện:

"thiết bị đang được đội khác dùng" → ⚠ GẶP HỌ THƯƠNG LƯỢNG lịch "lập lịch nguồn lực" → ⚠ ghi mong muốn, không tạo ra cam kết "mua thêm" → ⚠ tốn kém khi tổ chức đã có sẵn "gửi đơn đặt hàng cho đội khác" → ⚠ hiểu sai cơ chế nội bộ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch của bạn có phụ thuộc vào nguồn lực dùng chung nào không | | | Bạn đã nói chuyện với người đang giữ nguồn lực đó chưa | | | Lịch nguồn lực của bạn dựa trên cam kết hay trên mong muốn | |

Và điều mà một bản lịch nguồn lực chỉ có giá trị khi có: những cuộc trò chuyện đã diễn ra trước khi nó được viết ra — vì nếu không, nó chỉ là danh sách những điều bạn hy vọng.

Câu 537 People
As the project manager for Lopez Logistics, Jenna has contracted two companies to complete part of the latest project, who will need to work together on certain parts of the project. One vendor is responsible for connecting the networking cables to a central patch panel and to the individual network receptacles; the other vendor is responsible for network cable installation throughout a building. The vendors cannot agree on how the work should take place. For Jenna to manage this scenario effectively, what is the best approach to use?
  1. A Because vendors are not stakeholders, they need to live up to their contract terms.
  2. B To find the best solution for the project, use conflict resolution because the vendors are stakeholders.
  3. C To find the best solution for the contracted work, use conflict resolution, even though the vendors are not stakeholders.
  4. D Because vendors are stakeholders, figure out who will do what activities in the project.
Xem giải thích

Đáp án

B — DÙNG KỸ THUẬT GIẢI QUYẾT XUNG ĐỘT ĐỂ TÌM GIẢI PHÁP TỐT NHẤT CHO DỰ ÁN, VÌ NHÀ CUNG CẤP LÀ BÊN LIÊN QUAN.

Vì sao đúng

⚠ Hai vế của đáp án đều phải đúng: | Vế | Nội dung | |---|---| | ⚠ Nhà cung cấp LÀ bên liên quan | ⚠ họ ảnh hưởng tới dự án và bị dự án ảnh hưởng | | ⚠ Nên áp dụng kỹ thuật giải quyết xung đột | ⚠ đúng công cụ cho một bất đồng giữa hai bên | | ⚠ Mục tiêu là giải pháp tốt nhất CHO DỰ ÁN | ⚠ không phải cho một trong hai nhà thầu | | ⚠ Công việc của họ có phụ thuộc lẫn nhau | ⚠ đi dây và đấu nối phải khớp nhau | | ⚠ Kết luận | ⚠ Jenna phải chủ động điều phối vì không ai khác nhìn thấy toàn cảnh |

⚠ Vì sao Jenna không thể đứng ngoài: ⚠ hai nhà thầu chỉ có hợp đồng với Jenna, không có hợp đồng với nhau ⚠ — ⚠ nên không có cơ chế nào buộc họ tự thoả thuận; người duy nhất kết nối được hai bên là cô ấy.

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

  • D (vì nhà cung cấp là bên liên quan, hãy tự phân định ai làm việc gì) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó bắt đầu bằng vế ĐÚNG — nhà cung cấp là bên liên quan — và một người đọc nhanh sẽ dừng lại ở đó: ⚠ nhưng ⚠ vế sau lại đề xuất Jenna đơn phương phân việc, tức là ÁP ĐẶT thay vì giải quyết ⚠; ⚠ và có một vấn đề pháp lý thật: phạm vi công việc của mỗi nhà thầu đã được định trong HỢP ĐỒNG của họ — Jenna tự phân lại việc là can thiệp vào phạm vi hợp đồng, và điều đó có thể dẫn tới yêu cầu thanh toán thêm hoặc tranh chấp; ⚠ cách đúng là đưa hai bên vào cùng một bàn để họ tự thống nhất trình tự phối hợp trong khuôn khổ hợp đồng đã có.

  • C (dùng giải quyết xung đột, dù nhà cung cấp KHÔNG phải bên liên quan) — ⚠ hành động đúng nhưng lý do sai; ⚠ nhà cung cấp chắc chắn là bên liên quan.

  • A (vì nhà cung cấp không phải bên liên quan nên cứ để họ thực hiện đúng hợp đồng) — ⚠ sai cả hai vế; ⚠ và "cứ theo hợp đồng" không giải quyết được bất đồng về TRÌNH TỰ, thứ mà hợp đồng thường không quy định.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26913 lô 203 (định nghĩa bên liên quan), ⚠ #26957 cùng lô (bên liên quan gồm cả bên ngoài), ⚠ #26933 cùng lô (thương lượng hướng tới cùng thắng), ⚠ #26978 cùng lô (thương lượng nguồn lực), ⚠ #26950 cùng lô (cả nhóm cùng giải quyết vấn đề).

⚠ Năm cách xử lý xung đột, xếp theo hiệu quả: | Cách | Nội dung | |---|---| | ⚠ HỢP TÁC / GIẢI QUYẾT VẤN ĐỀ | ⚠ tìm giải pháp cả hai chấp nhận — tốt nhất, và là điều Jenna nên nhắm tới | | ⚠ THOẢ HIỆP | ⚠ mỗi bên nhượng một phần, ai cũng hơi thiệt | | ⚠ XOA DỊU / THÍCH ỨNG | ⚠ nhấn mạnh điểm chung, gác khác biệt | | ⚠ ÉP BUỘC | ⚠ áp đặt — điều phương án D đề xuất | | ⚠ RÚT LUI / NÉ TRÁNH | ⚠ hoãn lại, thường tệ nhất | | ⚠ Vì sao hợp tác phù hợp ở đây | ⚠ hai nhà thầu là chuyên gia trong phần việc của mình và họ biết ràng buộc kỹ thuật rõ hơn Jenna — nên giải pháp tốt nhất gần như chắc chắn đến từ họ, chỉ cần có người tổ chức cuộc trò chuyện |

⚠ Jenna nên tổ chức buổi làm việc thế nào: | Bước | Nội dung | |---|---| | ⚠ 1. Mời cả hai nhà thầu ngồi cùng một bàn | ⚠ không xử lý riêng lẻ từng bên | | ⚠ 2. Nêu lại MỤC TIÊU CHUNG của dự án | ⚠ khung tham chiếu chung | | ⚠ 3. Để mỗi bên trình bày ràng buộc kỹ thuật của mình | | | ⚠ 4. Tìm phương án khớp cả hai | ⚠ thường có, chỉ chưa ai nói ra | | ⚠ 5. GHI LẠI thoả thuận về trình tự và giao diện công việc | ⚠ bằng văn bản, gửi cả hai | | ⚠ Bước quan trọng nhất về sau | ⚠ bước 5 — một thoả thuận miệng giữa hai nhà thầu sẽ biến mất ngay khi có người đổi ca, và tranh cãi sẽ quay lại y hệt vào tuần sau |

⚠ Bài học phòng ngừa cho lần sau: | Việc | Nội dung | |---|---| | ⚠ Định rõ GIAO DIỆN giữa các gói thầu ngay trong hồ sơ mời thầu | ⚠ ai làm tới đâu, bàn giao cho nhau ở đâu | | ⚠ Đưa nghĩa vụ phối hợp vào hợp đồng | | | ⚠ Tổ chức họp khởi động chung cho các nhà thầu | ⚠ trước khi bắt đầu, không phải khi đã tắc | | ⚠ Nhận xét | ⚠ xung đột giữa hai nhà thầu hầu như luôn xảy ra ở đúng chỗ mà hai hợp đồng gặp nhau — nên vùng ranh giới đó xứng đáng được viết kỹ hơn phần lõi của mỗi gói thầu |

Từ khoá nhận diện:

"hai nhà thầu bất đồng về cách phối hợp" → ⚠ GIẢI QUYẾT XUNG ĐỘT, họ LÀ bên liên quan "tự phân định ai làm gì" → ⚠ áp đặt, và động vào phạm vi hợp đồng "nhà cung cấp không phải bên liên quan" → ⚠ sai định nghĩa "cứ để họ theo hợp đồng" → ⚠ hợp đồng thường không quy định trình tự phối hợp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có định rõ giao diện giữa các nhà thầu không | | | Các nhà thầu của bạn đã gặp nhau bao giờ chưa | | | Thoả thuận phối hợp gần nhất có được ghi lại không | |

Và nơi mà mọi dự án nhiều nhà thầu gặp rắc rối: không phải ở giữa phần việc của ai, mà ở đúng chỗ hai phần việc chạm vào nhau — nơi cả hai hợp đồng đều im lặng.

Câu 538 Process
Agile practices include numerous points at which feedback is given. Feedback is a primary feature of all the following events except
  1. A Daily standups
  2. B Paired programming
  3. C Retrospectives
  4. D Continuous integration
Xem giải thích

Đáp án

A — HỌP ĐỨNG HẰNG NGÀY (daily standups).

Vì sao đúng

⚠ Mục đích chính của từng sự kiện: | Sự kiện | Mục đích chính | |---|---| | ⚠ HỌP ĐỨNG HẰNG NGÀY | ⚠ ĐỒNG BỘ và phối hợp — ai làm gì, có gì cản trở | | ⚠ Lập trình đôi | ⚠ phản hồi TỨC THÌ về từng dòng mã | | ⚠ Họp cải tiến | ⚠ phản hồi về CÁCH LÀM VIỆC của đội | | ⚠ Tích hợp liên tục | ⚠ phản hồi TỰ ĐỘNG về tình trạng mã trong vài phút | | ⚠ Kết luận | ⚠ ba cái sau sinh ra để tạo vòng phản hồi; buổi họp đứng sinh ra để đồng bộ kế hoạch trong ngày |

⚠ Phân biệt tinh tế: ⚠ buổi họp đứng có nêu vật cản, nhưng nêu vật cản là YÊU CẦU HỖ TRỢ chứ không phải nhận phản hồi về công việc mình đã làm ⚠ — ⚠ liên hệ #26911 lô 203.

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

  • C (họp cải tiến — retrospective) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là sự kiện diễn ra thưa nhất trong bốn cái, nên dễ bị nghĩ là ngoại lệ: ⚠ nhưng ⚠ họp cải tiến là sự kiện phản hồi THUẦN TUÝ NHẤT của cả khung scrum — toàn bộ buổi họp dành cho việc đội nhìn lại và phản hồi về chính cách mình làm việc ⚠; ⚠ nó là vòng phản hồi ở cấp QUY TRÌNH, trong khi lập trình đôi và tích hợp liên tục là vòng phản hồi ở cấp SẢN PHẨM; ⚠ cả ba đều là phản hồi, chỉ khác đối tượng được phản hồi.

  • B (lập trình đôi) — ⚠ phản hồi liên tục theo thời gian thực; ⚠ vòng phản hồi ngắn nhất trong mọi thực hành agile.

  • D (tích hợp liên tục) — ⚠ phản hồi tự động về chất lượng mã; ⚠ báo hỏng trong vài phút thay vì vài tuần.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26911 lô 203 (hỏi về vật cản trong buổi họp đứng), ⚠ #26905 lô 203 (cả đội dự buổi cải tiến), ⚠ #26948 cùng lô (lập trình đôi), ⚠ #26942 cùng lô (buổi rà soát chặng — phản hồi từ bên liên quan).

⚠ Các vòng phản hồi trong agile, từ ngắn tới dài: | Vòng | Chu kỳ | |---|---| | ⚠ Lập trình đôi | ⚠ vài giây tới vài phút | | ⚠ Kiểm thử tự động / tích hợp liên tục | ⚠ vài phút | | ⚠ Rà soát mã | ⚠ vài giờ tới một ngày | | ⚠ Họp đứng | ⚠ một ngày — nhưng để ĐỒNG BỘ, không phải phản hồi | | ⚠ Rà soát chặng | ⚠ một tới bốn tuần, phản hồi từ bên liên quan | | ⚠ Họp cải tiến | ⚠ một tới bốn tuần, phản hồi về quy trình | | ⚠ Nguyên tắc nền của agile | ⚠ vòng phản hồi càng ngắn thì sai lầm càng rẻ — toàn bộ bộ thực hành kỹ thuật của agile có thể đọc như một nỗ lực rút ngắn các vòng này xuống ngắn nhất có thể |

⚠ Ba câu hỏi chuẩn của buổi họp đứng: | Câu hỏi | Mục đích | |---|---| | ⚠ Hôm qua tôi đã làm gì | ⚠ đồng bộ thông tin | | ⚠ Hôm nay tôi sẽ làm gì | ⚠ phối hợp kế hoạch | | ⚠ Có gì đang cản trở tôi không | ⚠ yêu cầu hỗ trợ | | ⚠ Vì sao đây không phải phản hồi | ⚠ không ai đánh giá công việc của ai, không ai nhận xét về chất lượng — buổi họp đứng là để đội biết nhau đang ở đâu, và biến nó thành buổi báo cáo hoặc buổi góp ý là cách nhanh nhất phá hỏng nó |

⚠ Lỗi thường gặp biến họp đứng thành thứ khác: | Lỗi | Hậu quả | |---|---| | ⚠ Báo cáo cho scrum master thay vì nói với đội | ⚠ thành buổi kiểm tra tiến độ | | ⚠ Đi sâu giải quyết vấn đề ngay tại chỗ | ⚠ kéo dài, đa số người ngồi nghe vô ích | | ⚠ Nhận xét chất lượng công việc của nhau | ⚠ thành buổi rà soát, sai chỗ | | ⚠ Vượt quá 15 phút | ⚠ mất tính chất "đứng" | | ⚠ Cách chữa | ⚠ ghi lại các vấn đề cần bàn sâu rồi xử lý sau buổi họp với đúng những người liên quan — kỹ thuật này thường được gọi là "bãi đỗ xe" và nó cứu được rất nhiều buổi họp đứng |

Từ khoá nhận diện:

"phản hồi là đặc trưng chính, TRỪ" → ⚠ HỌP ĐỨNG (mục đích là đồng bộ) "họp cải tiến" → ⚠ phản hồi thuần tuý nhất, về CÁCH LÀM VIỆC "lập trình đôi" → ⚠ vòng phản hồi ngắn nhất "tích hợp liên tục" → ⚠ phản hồi tự động về mã

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi họp đứng của bạn kéo dài bao lâu | | | Mọi người nói với đội hay báo cáo cho một người | | | Vòng phản hồi ngắn nhất của đội bạn dài bao lâu | |

Và điều phân biệt buổi họp đứng với mọi sự kiện agile khác: nó không hỏi việc đã làm tốt hay chưa, nó chỉ hỏi mọi người có đang đi cùng hướng không.

Câu 539 Process
Kendra is the scrum master for Project Earrings, which is in its planning stages and has a budget of $175,000. During a recent meeting, the product owner asked Kendra how they will perform long-term planning, given this is an agile project. How is Kendra likely to respond?
  1. A Plan every iteration at the start of the project.
  2. B Build a work breakdown structure.
  3. C Loosely group tasks by quarterly releases.
  4. D Consult with subject matter experts.
Xem giải thích

Đáp án

C — NHÓM CÁC CÔNG VIỆC MỘT CÁCH LỎNG LẺO THEO CÁC ĐỢT PHÁT HÀNH THEO QUÝ.

Vì sao đúng

⚠ Vì sao đây là cách lập kế hoạch dài hạn của agile: | Yếu tố | Nội dung | |---|---| | ⚠ Có hướng đi dài hạn để bên liên quan nhìn thấy | ⚠ giải quyết mối lo "không thấy điểm kết thúc" | | ⚠ Nhưng chi tiết ở mức LỎNG, không cố định | ⚠ giữ được khả năng thích ứng | | ⚠ Đơn vị QUÝ đủ xa để có ý nghĩa chiến lược | ⚠ và đủ gần để còn dự đoán được | | ⚠ Chi tiết được làm rõ dần khi tới gần | ⚠ chính là lập kế hoạch theo lớp sóng | | ⚠ Kết luận | ⚠ agile CÓ lập kế hoạch dài hạn, chỉ khác ở mức độ chi tiết theo khoảng cách thời gian |

⚠ Đây chính là lộ trình sản phẩm (product roadmap): ⚠ các chủ đề lớn theo quý, không phải danh sách tính năng có ngày cụ thể ⚠ — ⚠ liên hệ #26869 lô 202 về lập kế hoạch theo lớp sóng.

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

  • A (lập kế hoạch cho mọi chặng ngay từ đầu dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như phiên bản "kỹ lưỡng" của việc lập kế hoạch, và với một người quen tư duy dự đoán thì đó chính là định nghĩa của chuẩn bị tốt: ⚠ nhưng ⚠ nó phá huỷ toàn bộ lợi thế của agile ⚠ — ⚠ kế hoạch chi tiết cho chặng thứ mười lăm sẽ lỗi thời trước khi tới đó, và toàn bộ công sức lập nó bị lãng phí; ⚠ tệ hơn, một kế hoạch chi tiết tạo ra áp lực tâm lý phải bám theo nó, khiến đội ngại điều chỉnh dù đã có thông tin mới; ⚠ nguyên tắc: chi tiết hoá chỉ tới mức mà thông tin hiện có cho phép.

  • B (xây dựng cấu trúc phân rã công việc) — ⚠ WBS là công cụ của dự án dự đoán; ⚠ agile dùng tồn đọng sản phẩm được xếp theo giá trị, một cấu trúc động chứ không phải cây phân rã cố định.

  • D (hỏi ý kiến chuyên gia) — ⚠ là một kỹ thuật hỗ trợ, không phải một CÁCH lập kế hoạch dài hạn; ⚠ hỏi chuyên gia rồi vẫn phải có hình thức nào đó để ghi lại kế hoạch.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26869 lô 202 (lập kế hoạch theo lớp sóng), ⚠ #26976 cùng lô (ước lượng thô ROM trong agile), ⚠ #26953 cùng lô (bên liên quan lo không thấy điểm kết thúc), ⚠ #26963 cùng lô (hợp đồng agile cho phép xếp lại phạm vi).

⚠ Các tầng lập kế hoạch trong agile: | Tầng | Tầm nhìn | Mức chi tiết | |---|---|---| | ⚠ Tầm nhìn sản phẩm | ⚠ nhiều năm | ⚠ định hướng, không có việc cụ thể | | ⚠ LỘ TRÌNH theo quý | ⚠ 6–12 tháng | ⚠ chủ đề lớn — ĐÁP ÁN của câu này | | ⚠ Kế hoạch phát hành | ⚠ vài chặng | ⚠ các khối tính năng | | ⚠ Kế hoạch chặng | ⚠ 1–4 tuần | ⚠ câu chuyện chi tiết, có tiêu chí chấp nhận | | ⚠ Kế hoạch ngày | ⚠ một ngày | ⚠ buổi họp đứng | | ⚠ Nguyên tắc xuyên suốt | ⚠ càng xa càng thô, càng gần càng chi tiết — nói cách khác, agile không lập kế hoạch ÍT hơn, nó lập kế hoạch THƯỜNG XUYÊN hơn và ở đúng mức chi tiết |

⚠ Kendra nên trả lời chủ sản phẩm thế nào: | Nội dung | Cách diễn đạt | |---|---| | ⚠ Có kế hoạch dài hạn, dạng lộ trình theo quý | ⚠ "chúng ta biết mình đi đâu" | | ⚠ Chi tiết được làm rõ dần theo từng chặng | ⚠ "nhưng không giả vờ biết chi tiết của tháng thứ chín" | | ⚠ Ngân sách 175.000 là ràng buộc đã biết | ⚠ dùng nó để giới hạn phạm vi lộ trình | | ⚠ Lộ trình được cập nhật định kỳ | ⚠ thường mỗi quý hoặc khi có thay đổi lớn | | ⚠ Điểm nên nhấn mạnh | ⚠ lộ trình theo quý ghi CHỦ ĐỀ và MỤC TIÊU, không ghi ngày giao của từng tính năng — vì mọi ngày ghi ra đều sẽ được nhớ như một lời hứa, kể cả khi có ghi chú rằng nó chỉ là dự kiến |

⚠ Vì sao đơn vị QUÝ lại phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Khớp với chu kỳ ngân sách và báo cáo của tổ chức | | | ⚠ Đủ dài để chứa nhiều chặng và một khối giá trị có nghĩa | | | ⚠ Đủ ngắn để dự đoán còn tương đối đáng tin | | | ⚠ Cho một nhịp rà soát và điều chỉnh tự nhiên | | | ⚠ Nhận xét | ⚠ lộ trình theo quý là điểm gặp giữa nhu cầu nhìn xa của lãnh đạo và nhu cầu linh hoạt của đội — nó đủ cụ thể để cấp vốn và đủ lỏng để không nói dối |

Từ khoá nhận diện:

"lập kế hoạch dài hạn trong agile" → ⚠ nhóm LỎNG theo các đợt phát hành QUÝ "lập kế hoạch mọi chặng từ đầu" → ⚠ phá huỷ lợi thế thích ứng của agile "xây dựng WBS" → ⚠ công cụ của dự án dự đoán "hỏi chuyên gia" → ⚠ kỹ thuật hỗ trợ, không phải cách lập kế hoạch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sản phẩm của bạn có lộ trình theo quý không | | | Lộ trình đó ghi chủ đề hay ghi ngày giao từng tính năng | | | Bạn cập nhật lộ trình bao lâu một lần | |

Và điều mà một lộ trình theo quý trung thực hơn một kế hoạch chi tiết mười tám tháng: nó thừa nhận đúng những gì bạn biết và những gì bạn chưa biết — trong khi bản kia giả vờ rằng bạn đã biết cả hai.

Câu 540 Process
You are a project manager for your organization. Your project has a BAC of $250,000 and is expected to last ten months. Currently, the project is in month six and is 40 percent complete, but the project was expected to be 60 percent complete by this time. You have spent $125,000 to complete the work. What is the schedule performance index of the project?
  1. A 0.67
  2. B $80,000
  3. C $67,000
  4. D 0.8
Xem giải thích

Đáp án

A — 0,67.

Vì sao đúng

⚠ Phép tính từng bước: | Bước | Nội dung | |---|---| | ⚠ Công thức: SPI = EV ÷ PV | | | ⚠ EV = phần trăm ĐÃ HOÀN THÀNH × BAC | ⚠ 0,40 × 250.000 = 100.000 | | ⚠ PV = phần trăm KẾ HOẠCH × BAC | ⚠ 0,60 × 250.000 = 150.000 | | ⚠ SPI = 100.000 ÷ 150.000 = 0,6667 | ⚠ làm tròn 0,67 | | ⚠ AC = 125.000 KHÔNG dùng trong công thức này | ⚠ nó chỉ để gài bẫy | | ⚠ Diễn giải | ⚠ dự án chỉ đạt 67% tốc độ kế hoạch — chậm tiến độ đáng kể |

⚠ Chìa khoá của cả câu: ⚠ nhận ra rằng chỉ số TIẾN ĐỘ không cần tới chi phí thực tế ⚠ — ⚠ SPI chỉ so tiến độ với tiến độ, còn AC là con số dành cho CPI.

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

  • D (0,8) — ⚠ phương án gây nhiễu mạnh nhất, và là bẫy trung tâm của câu này vì ⚠ nó là một con số có thật, tính đúng, từ chính các dữ kiện của đề — chỉ có điều nó là CPI chứ không phải SPI: ⚠ nhưng ⚠ CPI = EV ÷ AC = 100.000 ÷ 125.000 = 0,80 ⚠; ⚠ người làm bài vội sẽ lấy hai con số dễ thấy nhất (EV và số tiền đã chi) rồi chia cho nhau; ⚠ cách phòng bẫy: trước khi tính, viết ra công thức và hỏi con số nào thuộc về nó — chữ S trong SPI là SCHEDULE, và tiến độ không liên quan gì tới số tiền đã tiêu.

  • B (80.000 đô) — ⚠ có đơn vị tiền tệ nên chắc chắn không phải chỉ số; ⚠ SPI là tỷ số không đơn vị.

  • C (67.000 đô) — ⚠ đúng con số nhưng gắn ký hiệu tiền tệ; ⚠ dạng bẫy "đúng số, sai đơn vị", loại ngay được nếu nhớ rằng mọi chỉ số PI đều không có đơn vị.

Ghi nhớ

⚠ Ghi nhớ đối chiếu quan trọng — CÂU GẦN TRÙNG: ⚠ #27058 lô 206 dùng ĐÚNG TỪNG CON SỐ của câu này ⚠ — ⚠ cùng BAC 250.000, cùng mốc tháng 6/10, cùng 40% hoàn thành so với kế hoạch 60%, cùng đã chi 125.000; ⚠ khác biệt DUY NHẤT là ở đó đề hỏi CPI chứ không hỏi SPI, nên đáp án là 0,80 — đúng bằng con số bẫy của câu này; ⚠ hash MD5 không bắt được cặp này vì đề chỉ khác vài chữ; hãy đọc hai bài liền nhau, chúng tạo thành một bài học hoàn chỉnh về việc phân biệt SPI (EV ÷ PV) với CPI (EV ÷ AC).

⚠ Đối chiếu: ⚠ #26922 lô 203 (CPI = 250.000 ÷ 286.000 = 0,87), ⚠ #26812 lô 201 (CPI = 0,89), ⚠ #26810 lô 201 (giá trị thu được), ⚠ #26895 lô 203 (phân tích xu hướng).

⚠ Toàn bộ số liệu của bài này: | Ký hiệu | Giá trị | |---|---| | ⚠ BAC | ⚠ 250.000 | | ⚠ EV (40% hoàn thành) | ⚠ 100.000 | | ⚠ PV (60% theo kế hoạch) | ⚠ 150.000 | | ⚠ AC (đã chi) | ⚠ 125.000 | | ⚠ SV = EV − PV | ⚠ −50.000 — chậm tiến độ | | ⚠ CV = EV − AC | ⚠ −25.000 — vượt chi | | ⚠ SPI = EV ÷ PV | ⚠ 0,67 — ĐÁP ÁN | | ⚠ CPI = EV ÷ AC | ⚠ 0,80 — bẫy | | ⚠ Bức tranh tổng thể | ⚠ dự án vừa CHẬM vừa VƯỢT CHI, và chậm nặng hơn vượt chi — một tổ hợp cần can thiệp ngay chứ không chờ tới tháng sau |

⚠ Mẹo nhớ để không lẫn hai chỉ số: | Chỉ số | Mẹo | |---|---| | ⚠ SPI = EV ÷ PV | ⚠ cả hai chữ P và V đều thuộc "kế hoạch" — S là SCHEDULE, không dính tới tiền thật | | ⚠ CPI = EV ÷ AC | ⚠ C là COST, nên phải có chi phí THỰC TẾ trong đó | | ⚠ EV luôn là TỬ SỐ | ⚠ đúng cho cả hai | | ⚠ Nhỏ hơn 1 là xấu | ⚠ đúng cho cả hai | | ⚠ Cách kiểm tra nhanh | ⚠ nếu bài toán chỉ hỏi tiến độ mà bạn phải dùng tới con số tiền đã chi thì gần như chắc chắn bạn đang tính nhầm chỉ số |

⚠ Diễn giải kết quả cho người quản lý dự án: | Con số | Ý nghĩa | |---|---| | ⚠ SPI 0,67 | ⚠ cứ 3 ngày công việc kế hoạch thì mới làm được 2 | | ⚠ Tháng 6/10, mới xong 40% | ⚠ theo nhịp này sẽ mất khoảng 15 tháng thay vì 10 | | ⚠ CPI 0,80 | ⚠ mỗi đồng chi ra chỉ tạo 0,8 đồng giá trị | | ⚠ Việc cần làm | ⚠ tìm NGUYÊN NHÂN của độ chậm trước khi bàn tới rút ngắn hay chạy song song — vì hai biện pháp đó đều tốn tiền hoặc tăng rủi ro, và cả hai đều vô nghĩa nếu nguyên nhân gốc chưa được xử lý |

Từ khoá nhận diện:

"chỉ số hiệu suất TIẾN ĐỘ" → ⚠ SPI = EV ÷ PV, không dùng AC "0,8" → ⚠ đó là CPI, bẫy trung tâm của câu "$67.000" → ⚠ đúng số, sai đơn vị — chỉ số không có đơn vị tiền "% hoàn thành × BAC" → ⚠ cách tính EV; "% kế hoạch × BAC" là PV

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn tự tính lại 100.000 ÷ 150.000 ra 0,67 chưa | | | Bạn phân biệt được lúc nào dùng PV lúc nào dùng AC chưa | | | Dự án của bạn hiện có SPI và CPI là bao nhiêu | |

Và điều mà một chỉ số SPI bằng 0,67 ở tháng thứ sáu nói rõ hơn mọi báo cáo tình trạng: rằng vấn đề không nằm ở tháng vừa rồi — nó đã tích luỹ đủ lâu để tạo ra một khoảng cách bằng một phần ba khối lượng công việc.