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

Tìm thấy 720 câu.

Câu 221 Process
Betsy is the project manager of the JGB Project for her organization. She would like to solicit seven vendors for a price to supply 1,000 fixtures for her project. What type of document would Betsy issue to the vendors in this scenario?
  1. A A request for proposal
  2. B A request for a quote
  3. C An invitation for a bidders' conference
  4. D A request for information
Xem giải thích

Đáp án

B — YÊU CẦU BÁO GIÁ (Request for Quote, RFQ).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Betsy muốn hỏi GIÁ | ⚠ chỉ cần con số, không cần phương án | | ⚠ Sản phẩm đã rõ: 1.000 bộ thiết bị | ⚠ quy cách đã xác định, không cần nhà cung cấp đề xuất cách làm | | ⚠ Gửi cho BẢY nhà cung cấp | ⚠ so sánh giá giữa nhiều bên | | ⚠ Tiêu chí chọn chủ yếu là GIÁ | ⚠ đúng bản chất của RFQ | | ⚠ Định nghĩa RFQ | ⚠ dùng khi biết CHÍNH XÁC mình cần gì và chỉ cần biết giá bao nhiêu |

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

  • A (yêu cầu đề xuất — RFP) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ RFP dùng khi ⚠ vấn đề đã rõ nhưng GIẢI PHÁP chưa rõ ⚠ — bạn muốn nhà cung cấp đề xuất cách làm; ⚠ ở đây ⚠ không có gì để đề xuất, chỉ có 1.000 bộ thiết bị cần báo giá.

  • D (yêu cầu thông tin — RFI) — ⚠ dùng khi CHƯA BIẾT thị trường có gì; ⚠ Betsy đã biết rõ mình cần gì.

  • C (thư mời dự hội nghị nhà thầu) — ⚠ hội nghị nhà thầu là BƯỚC SAU, ⚠ dành cho việc giải đáp thắc mắc, ⚠ không phải tài liệu mời báo giá.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25941 ở lô này (tìm gói thầu qua quảng cáo), câu #25907 ở lô 183 (make-or-buy), câu #25882 ở lô 182 (PTA của FPIF), và câu #25733/#25765 ở lô 180 (hợp đồng T&M). ⚠ Nhóm mua sắm.

⚠ BA loại tài liệu mời thầu: | Tài liệu | Dùng khi | Nhận lại gì | |---|---|---| | ⚠ RFI — Yêu cầu thông tin | ⚠ chưa biết thị trường có gì, ai làm được | ⚠ danh sách năng lực, thông tin tham khảo | | ⚠ RFQ — Yêu cầu báo giá | ⚠ BIẾT RÕ cần gì, chỉ hỏi giá — CÂU NÀY | ⚠ bảng giá | | ⚠ RFP — Yêu cầu đề xuất | ⚠ biết VẤN ĐỀ nhưng chưa biết GIẢI PHÁP | ⚠ phương án kỹ thuật + giá + kế hoạch | | ⚠ Thứ tự thường dùng | ⚠ RFI → RFP hoặc RFQ → chấm thầu → ký hợp đồng | | ⚠ Mẹo nhớ | ⚠ I = Information (dò đường), Q = Quote (hỏi giá), P = Proposal (xin phương án) |

Từ khoá nhận diện:

"số lượng và quy cách đã rõ, chỉ hỏi giá" → ⚠ RFQ "cần nhà cung cấp đề xuất cách làm" → ⚠ RFP "chưa biết ai làm được việc này" → ⚠ RFI "buổi giải đáp cho các nhà thầu" → ⚠ hội nghị nhà thầu, không phải tài liệu mời

⚠ Hội nghị nhà thầu là gì Nội dung
⚠ Buổi họp giữa bên mua và TẤT CẢ nhà thầu tiềm năng
⚠ Mục đích: giải đáp thắc mắc về tài liệu mời thầu
⚠ Mọi nhà thầu phải nhận CÙNG một thông tin ⚠ bảo đảm công bằng
⚠ Hỏi đáp phải được ghi lại và gửi cho tất cả ⚠ kể cả bên không dự
⚠ Còn gọi là ⚠ hội nghị tiền đấu thầu, hội nghị nhà cung cấp
⚠ Chọn nhà cung cấp chỉ theo GIÁ có ổn không Cân nhắc
⚠ Với hàng hoá tiêu chuẩn thì HỢP LÝ ⚠ 1.000 bộ thiết bị cùng quy cách — đúng trường hợp này
⚠ Nhưng vẫn nên kiểm năng lực giao hàng ⚠ giá rẻ mà giao trễ thì hỏng lịch
⚠ Và kiểm tình hình tài chính của nhà cung cấp ⚠ nhà cung cấp phá sản giữa chừng là rủi ro thật
⚠ Với dịch vụ phức tạp ⚠ phải dùng tiêu chí đa chiều, không chỉ giá — khi đó dùng RFP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã xác định rõ tiêu chí chọn TRƯỚC khi gửi tài liệu chưa | ⚠ quyết tiêu chí sau khi nhận hồ sơ là mở cửa cho thiên vị | | Số nhà cung cấp mời có đủ để có cạnh tranh thật không | | | Có ai kiểm năng lực giao hàng ngoài giá không | |

Và cách chọn nhanh giữa ba tài liệu: hỏi xem mình đang thiếu THÔNG TIN, thiếu GIẢI PHÁP, hay chỉ thiếu CON SỐ.

Câu 222 People
Kiara is the project manager of the Roselyn Hotel project, similar to the Beatrice Hotel project she completed last year. To expedite the organization planning process, which of the following methods can Kiara use?
  1. A She can use the same project team reward structure for the Roselyn project as she did on the Beatrice project.
  2. B Kiara can use the same project team she used on the Beatrice project for the Roselyn project.
  3. C She can use the same roles and responsibilities definitions on the Roselyn project as she did on the Beatrice project.
  4. D She can use the same project plan for the Roselyn project as was used on the Beatrice project.
Xem giải thích

Đáp án

C — Dùng lại ĐỊNH NGHĨA VAI TRÒ VÀ TRÁCH NHIỆM của dự án Beatrice cho dự án Roselyn.

Vì sao đúng

⚠ Vì sao đây là cách rút ngắn hợp lý: | Lý do | Nội dung | |---|---| | ⚠ Hai dự án TƯƠNG TỰ nhau — cùng là dự án khách sạn | ⚠ cơ cấu công việc gần giống nhau | | ⚠ Vai trò và trách nhiệm là TÀI SẢN QUY TRÌNH có thể dùng lại | | | ⚠ Đây là ví dụ kinh điển của MẪU (template) | ⚠ kỹ thuật chính thức để rút ngắn lập kế hoạch tổ chức | | ⚠ Vẫn phải RÀ SOÁT và điều chỉnh cho phù hợp | ⚠ dùng lại không có nghĩa là bê nguyên | | ⚠ Kết quả | ⚠ tiết kiệm thời gian mà không hy sinh chất lượng kế hoạch |

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

  • B (dùng lại chính đội của dự án Beatrice) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất hiệu quả: ⚠ nhưng ⚠ Kiara thường KHÔNG có quyền quyết định điều đó ⚠ (nguồn lực do tổ chức phân bổ — xem #25935), ⚠ và nó ⚠ không phải phương pháp rút ngắn LẬP KẾ HOẠCH TỔ CHỨC ⚠ — nó là một mong muốn về nhân sự.

  • D (dùng lại nguyên kế hoạch dự án Beatrice) — ⚠ quá mức: ⚠ hai dự án tương tự chứ không giống hệt; ⚠ bê nguyên kế hoạch sẽ mang theo cả những thứ không còn đúng.

  • A (dùng lại cơ cấu khen thưởng) — ⚠ có thể dùng lại được, ⚠ nhưng nó ⚠ không rút ngắn quy trình lập kế hoạch tổ chức ⚠ — nó chỉ là một chi tiết nhỏ về động lực.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25898 ở lô 183 (xác định vai trò và trách nhiệm là yếu tố quản trị dự án) và bộ yếu tố quản trị đã thành SÁU CÂU ⚠ (#25730 rủi ro · #25757 bài học · #25761 bài học · #25843 vai trò · #25898 vai trò · và họ hàng). ⚠ "Rà soát cổng giai đoạn" vẫn là mục duy nhất chưa từng làm khoá đáp án. ⚠ Xem thêm câu #25911 ở lô 183 (bài học kinh nghiệm) — ⚠ đây chính là lúc kho bài học phát huy tác dụng.

⚠ Tài sản quy trình nào dùng lại được giữa các dự án tương tự: | Tài sản | Dùng lại thế nào | |---|---| | ⚠ Định nghĩa vai trò và trách nhiệm | ⚠ gần như dùng lại được nguyên — CÂU NÀY | | ⚠ Ma trận RACI | ⚠ điều chỉnh tên người, giữ cấu trúc | | ⚠ Mẫu WBS | ⚠ rất hiệu quả với dự án lặp lại | | ⚠ Danh sách kiểm rủi ro | ⚠ rủi ro dự án khách sạn phần lớn giống nhau | | ⚠ Ước lượng và định mức | ⚠ ước lượng tương tự — analogous estimating | | ⚠ Bài học kinh nghiệm | ⚠ giá trị nhất, và bị dùng ít nhất | | ⚠ Nguyên tắc chung | ⚠ dùng lại KHUNG, xem lại NỘI DUNG |

Từ khoá nhận diện:

"dự án tương tự dự án trước" → ⚠ dùng lại mẫu và tài sản quy trình "dùng lại nguyên kế hoạch" → ⚠ quá đà, tương tự ≠ giống hệt "dùng lại đúng đội cũ" → ⚠ mong muốn về nguồn lực, không phải kỹ thuật lập kế hoạch "ước lượng tương tự" → ⚠ kỹ thuật cùng họ, dùng dữ liệu dự án trước

⚠ Ma trận RACI — công cụ chính của việc này Vai
⚠ R — Responsible ⚠ người THỰC HIỆN công việc
⚠ A — Accountable ⚠ người CHỊU TRÁCH NHIỆM cuối cùng — chỉ MỘT người cho mỗi việc
⚠ C — Consulted ⚠ người được HỎI Ý KIẾN trước khi làm
⚠ I — Informed ⚠ người được THÔNG BÁO sau khi làm
⚠ Lỗi hay gặp ⚠ đặt hai chữ A cho một việc — khi đó thực chất là KHÔNG AI chịu trách nhiệm
⚠ Nguy hiểm khi dùng lại mà không rà soát Nguy hiểm
⚠ Mang theo giả định không còn đúng ⚠ quy định xây dựng có thể đã đổi
⚠ Mang theo cả LỖI của dự án trước ⚠ nếu không đọc bài học kinh nghiệm
⚠ Đội mới không thấy mình có phần trong kế hoạch ⚠ giảm cam kết
⚠ Cách làm đúng ⚠ lấy mẫu làm ĐIỂM XUẤT PHÁT rồi cùng đội rà lại — nhanh hơn viết mới, an toàn hơn bê nguyên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có kho mẫu dùng chung không | | | Lần cuối các mẫu đó được cập nhật là khi nào | ⚠ mẫu cũ mười năm còn hại hơn không có mẫu | | Bạn có đọc bài học của dự án tương tự trước khi bắt đầu không | |

Và giá trị thật của việc dùng lại: không phải để đỡ phải nghĩ, mà để dành công sức nghĩ cho những chỗ thật sự khác biệt giữa hai dự án.

Câu 223 People
Oscar is the scrum master for Project S, which is in its ninth iteration and has a velocity of 59. Recently two of his developers got into an argument over how a specific task should be accomplished. What is the next best step for Oscar?
  1. A Do nothing. The team will figure it out on their own.
  2. B Wait until the next retrospective.
  3. C Refer the developers to the tasks documentation.
  4. D Refer to Project S’s information radiators.
Xem giải thích

Đáp án

C — Chỉ hai lập trình viên tới TÀI LIỆU CỦA CÔNG VIỆC đó.

Vì sao đúng

⚠ Vì sao tài liệu là bước tiếp theo tốt nhất: | Lý do | Nội dung | |---|---| | ⚠ Tranh cãi là về CÁCH THỰC HIỆN MỘT CÔNG VIỆC CỤ THỂ | ⚠ đây là bất đồng có thể phân xử bằng DỮ KIỆN | | ⚠ Tài liệu công việc chứa yêu cầu, tiêu chí chấp nhận, ràng buộc kỹ thuật | ⚠ thường trả lời được ngay câu đang cãi | | ⚠ Đưa cuộc tranh luận từ Ý KIẾN sang BẰNG CHỨNG | ⚠ cách hạ nhiệt hiệu quả nhất | | ⚠ Oscar KHÔNG quyết thay, cũng KHÔNG bỏ mặc | ⚠ đúng vai Scrum Master: gỡ vật cản, cung cấp thông tin | | ⚠ Kết quả | ⚠ đội tự giải quyết, nhưng có công cụ để giải quyết |

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

  • A (không làm gì, đội sẽ tự xử lý) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe giống nguyên tắc "để đội tự giải quyết", ⚠ nhưng ⚠ "KHÔNG LÀM GÌ" khác với "TRAO CÔNG CỤ để họ tự giải quyết"; ⚠ Oscar đã biết chuyện, bỏ mặc là né trách nhiệm.

  • B (đợi tới buổi retrospective) — ⚠ quá muộn; ⚠ công việc đang bị chặn ngay bây giờ; ⚠ retrospective bàn về QUY TRÌNH, không phải nơi phân xử một việc cụ thể.

  • D (chỉ họ tới các bảng thông tin của dự án) — ⚠ bảng thông tin hiển thị TRẠNG THÁI CHUNG ⚠ (velocity, tiến độ, vật cản), ⚠ không chứa chi tiết kỹ thuật của một công việc.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với câu #25937 trong CÙNG MỘT LÔ ⚠ (Terry: đội bất đồng, nên trao quyền cho họ tự giải quyết). ⚠ Hai khoá đáp án THOẠT NHÌN mâu thuẫn — một câu bảo "để đội tự xử", câu kia lại loại phương án "để đội tự xử". ⚠ Cả hai khoá đều được giữ nguyên, vì hai tình huống khác nhau ở ba điểm: | Điểm khác | #25937 (Terry) | #25945 (Oscar) | |---|---|---| | ⚠ Bản chất bất đồng | ⚠ về một VẤN ĐỀ của đội, có yếu tố cảm xúc và an toàn tâm lý | ⚠ về CÁCH LÀM một công việc kỹ thuật cụ thể | | ⚠ Có dữ kiện phân xử không | ⚠ KHÔNG — không có tài liệu nào nói ai đúng | ⚠ CÓ — tài liệu công việc trả lời được | | ⚠ Phương án đúng diễn đạt thế nào | ⚠ "TRAO QUYỀN" — hành động chủ động | ⚠ "chỉ tới tài liệu" — cũng là hành động chủ động | | ⚠ Điểm CHUNG của hai khoá | ⚠ cả hai đều CHỦ ĐỘNG làm gì đó, và cả hai đều KHÔNG quyết thay đội | | ⚠ Lưu ý khi đi thi | ⚠ "KHÔNG LÀM GÌ CẢ" gần như luôn là phương án sai; "trao quyền" và "cung cấp thông tin" thì đúng — đừng đọc chúng thành một |

Ghi nhớ

⚠ Đối chiếu thêm: ⚠ câu #25916 ở lô 183 (Eva nhường-thua), câu #25926 (bất đồng và cam kết), và câu #25919 (đội sợ chọn sai kiến trúc → phân tích thông tin). ⚠ Câu #25919 và câu này cùng một logic: chữa bất định và bất đồng bằng THÔNG TIN.

⚠ Chọn cách xử lý theo BẢN CHẤT bất đồng: | Bất đồng về | Cách xử lý | |---|---| | ⚠ Dữ kiện kỹ thuật | ⚠ tra tài liệu, chạy thử nghiệm, đo — CÂU NÀY | | ⚠ Cách ưu tiên công việc | ⚠ hỏi product owner | | ⚠ Cách làm việc của đội | ⚠ đưa ra retrospective | | ⚠ Quan hệ cá nhân | ⚠ trao đổi riêng, có thể cần điều phối | | ⚠ Sai lầm phổ biến | ⚠ dùng cách của loại này cho loại kia — ví dụ mang chuyện kỹ thuật ra retrospective |

Từ khoá nhận diện:

"cãi nhau về cách làm một việc cụ thể" → ⚠ tra tài liệu công việc "không làm gì cả" → ⚠ gần như luôn sai "đợi tới retrospective" → ⚠ sai khi việc đang bị chặn "bảng thông tin" → ⚠ trạng thái chung, không phải chi tiết kỹ thuật

⚠ Chi tiết "vòng lặp thứ 9, velocity 59" nói lên gì Ý nghĩa
⚠ Đội đã trưởng thành, quen việc ⚠ theo Tuckman thì đã qua giai đoạn bão tố
⚠ Bất đồng kỹ thuật ở đội trưởng thành là chuyện LÀNH MẠNH ⚠ dấu hiệu họ quan tâm tới chất lượng
⚠ Không cần can thiệp nặng ⚠ chỉ cần cung cấp dữ kiện
⚠ Nếu là đội mới hình thành ⚠ có thể cần điều phối nhiều hơn
⚠ Nếu tài liệu KHÔNG trả lời được thì sao Bước tiếp
⚠ Chạy một SPIKE ngắn để thử cả hai cách ⚠ dữ liệu thắng tranh luận
⚠ Hỏi ý kiến cả đội trong buổi thiết kế ngắn
⚠ Chọn cách ĐẢO NGƯỢC ĐƯỢC nếu vẫn chưa rõ ⚠ liên hệ #25919
⚠ Cuối cùng ⚠ ghi lại quyết định và lý do — để lần sau không cãi lại từ đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu công việc của đội bạn có đủ để phân xử tranh luận không | | | Tranh luận kỹ thuật thường kết thúc bằng gì | ⚠ dữ liệu, hay ai có thâm niên hơn | | Quyết định kỹ thuật có được ghi lại không | |

Và điều tinh tế nhất của câu này: Oscar không giải quyết tranh cãi. Anh chỉ đưa cho hai người thứ mà họ cần để tự giải quyết — đó mới đúng là việc của Scrum Master.

Câu 224 People
You are the project manager for the GBK Project. This project affects a line of business, and the customer is anxious about the success of the project. Which of the following is likely not a top concern for the customer?
  1. A Schedule
  2. B Project priorities
  3. C Personality conflicts
  4. D Cost
Xem giải thích

Đáp án

C — XUNG ĐỘT TÍNH CÁCH trong đội (đây KHÔNG phải mối quan tâm hàng đầu của khách hàng).

Vì sao đúng

⚠ Khách hàng quan tâm gì: | Mối quan tâm | Vì sao | |---|---| | ⚠ LỊCH TRÌNH | ⚠ khi nào có kết quả — ảnh hưởng trực tiếp tới hoạt động kinh doanh của họ | | ⚠ CHI PHÍ | ⚠ họ trả tiền | | ⚠ ƯU TIÊN CỦA DỰ ÁN | ⚠ cái gì được làm trước, vì đề nói dự án ảnh hưởng tới một mảng kinh doanh | | ⚠ XUNG ĐỘT TÍNH CÁCH | ⚠ chuyện NỘI BỘ của đội — khách hàng không quan tâm và cũng không nên quan tâm | | ⚠ Ranh giới | ⚠ khách hàng quan tâm KẾT QUẢ, quản lý dự án lo QUÁ TRÌNH tạo ra kết quả đó |

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

  • B (ưu tiên của dự án) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như chuyện nội bộ của đội: ⚠ nhưng ⚠ ưu tiên quyết định thứ tự khách hàng NHẬN ĐƯỢC giá trị, ⚠ và đề nói rõ dự án ⚠ ảnh hưởng tới một mảng kinh doanh ⚠ — khách hàng chắc chắn quan tâm cái gì đến trước.

  • A (lịch trình) và D (chi phí) — ⚠ hai mối quan tâm kinh điển nhất của mọi khách hàng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25945 ở lô này (bất đồng kỹ thuật trong đội), câu #25937 (xung đột giai đoạn sớm), và câu #25916 ở lô 183 (Eva nhường-thua). ⚠ Bộ câu hỏi về xung đột trong lô này bổ sung một góc mới: xung đột là việc PHẢI XỬ LÝ, nhưng KHÔNG PHẢI việc để báo cáo ra ngoài.

⚠ Vì sao KHÔNG mang xung đột nội bộ ra với khách hàng: | Lý do | Nội dung | |---|---| | ⚠ Làm khách hàng MẤT LÒNG TIN vào năng lực của đội | | | ⚠ Khách hàng không có công cụ nào để giúp | ⚠ chỉ tạo thêm lo lắng vô ích | | ⚠ Xung đột là chuyện BÌNH THƯỜNG của mọi đội | ⚠ giai đoạn bão tố của Tuckman | | ⚠ Việc của PM là GIẢI QUYẾT, không phải chuyển tiếp lên | | | ⚠ Ngoại lệ | ⚠ nếu xung đột ĐÃ ẢNH HƯỞNG tới lịch hoặc chất lượng thì phải báo TÁC ĐỘNG, chứ vẫn không kể chi tiết ai cãi ai |

Từ khoá nhận diện:

"lịch, chi phí, phạm vi, chất lượng" → ⚠ khách hàng luôn quan tâm "chuyện nội bộ của đội" → ⚠ khách hàng không quan tâm "ưu tiên" → ⚠ khách hàng CÓ quan tâm, vì nó quyết định thứ tự nhận giá trị ⚠ Câu có chữ "KHÔNG" → ⚠ tìm cái KHÁC NHÓM

⚠ Báo cáo cho khách hàng nên có gì Nội dung
⚠ Tiến độ so với đường cơ sở
⚠ Chi phí so với ngân sách
⚠ Bàn giao đã hoàn thành và sắp tới
⚠ Vấn đề và rủi ro CÓ ẢNH HƯỞNG TỚI HỌ ⚠ kèm phương án xử lý, không chỉ nêu vấn đề
⚠ Việc cần khách hàng quyết hoặc hỗ trợ
⚠ Không nên có ⚠ chuyện nhân sự nội bộ, đổ lỗi, chi tiết kỹ thuật không liên quan tới quyết định của họ
⚠ "Khách hàng lo lắng về thành công của dự án" — xử lý thế nào Cách
⚠ Tăng TẦN SUẤT giao tiếp, không tăng độ dài báo cáo
⚠ Cho họ thấy kết quả THẬT sớm và thường xuyên ⚠ liên hệ #25877 lô 182 — mời bên liên quan tới demo
⚠ Minh bạch về rủi ro kèm phương án ⚠ giấu rủi ro làm lo lắng tăng lên khi nó lộ ra
⚠ Hỏi họ ĐANG LO ĐIỀU GÌ CỤ THỂ ⚠ thường khác với điều mình đoán
⚠ Điều làm lo lắng tăng nhất ⚠ im lặng — không có tin tức thì người ta tự tưởng tượng ra tin xấu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết khách hàng lo nhất điều gì không | ⚠ hỏi thẳng, đừng đoán | | Báo cáo của bạn có chứa thứ khách hàng không cần không | | | Khách hàng biết tin xấu từ bạn hay từ nguồn khác | ⚠ nguồn khác là dấu hiệu rất xấu |

Và ranh giới cần giữ: khách hàng có quyền biết mọi thứ ảnh hưởng tới kết quả họ nhận được, và không cần biết bất cứ điều gì khác về đội của bạn.

Câu 225 Process
Tracey is working on a project that has run into several major issues. The team is not communicating with each other, the monthly reports have been very general, and the team's overall morale is generally low. Tracey's supervisor has noted the team's inadequate progress and is scheduling a meeting to determine the root cause of the problem. This meeting is meant to review the project team's goals and achievements and its compliance with applicable methodologies and regulations. What term best describes the situation above?
  1. A Debriefing
  2. B Auditing
  3. C Reviewing
  4. D Quality assurance
Xem giải thích

Đáp án

B — KIỂM TOÁN (auditing).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Xem xét mức TUÂN THỦ các phương pháp và quy định áp dụng | ⚠ từ khoá quyết định — kiểm tra sự tuân thủ là bản chất của kiểm toán | | ⚠ Do CẤP TRÊN của Tracey tổ chức, không phải đội tự làm | ⚠ kiểm toán do bên ĐỘC LẬP thực hiện | | ⚠ Nhằm tìm NGUYÊN NHÂN GỐC của vấn đề | | | ⚠ Rà soát mục tiêu và thành quả của đội | | | ⚠ Định nghĩa | ⚠ kiểm toán là việc rà soát CÓ CẤU TRÚC và ĐỘC LẬP, xem công việc có tuân theo chính sách, quy trình và quy định hay không |

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

  • D (đảm bảo chất lượng) — ⚠ phương án gây nhiễu mạnh nhất vì kiểm toán chất lượng là một công cụ của đảm bảo chất lượng: ⚠ nhưng đảm bảo chất lượng là ⚠ CẢ MỘT QUY TRÌNH rộng, ⚠ còn câu hỏi hỏi ⚠ TÊN của BUỔI HỌP cụ thể này ⚠ — và đề nhấn vào tuân thủ quy định, tức là kiểm toán.

  • C (rà soát — reviewing) — ⚠ quá chung chung; ⚠ mọi cuộc họp đều "rà soát" cái gì đó; ⚠ thiếu yếu tố ĐỘC LẬP và TUÂN THỦ.

  • A (họp rút kinh nghiệm — debriefing) — ⚠ diễn ra SAU khi một việc kết thúc, ⚠ nhằm rút bài học; ⚠ ở đây dự án ĐANG chạy và đang có vấn đề.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25939 ở lô này (hành động khắc phục), câu #25933 (sửa lỗi), và câu #25924 ở lô 183 (chi phí phù hợp với chất lượng). ⚠ Nhóm chất lượng.

⚠ Phân biệt các loại buổi rà soát: | Loại | Ai làm | Khi nào | Mục đích | |---|---|---|---| | ⚠ KIỂM TOÁN | ⚠ bên ĐỘC LẬP | ⚠ bất kỳ lúc nào | ⚠ kiểm TUÂN THỦ quy trình và quy định — CÂU NÀY | | ⚠ RÀ SOÁT CHÉO (peer review) | ⚠ đồng nghiệp cùng đội | ⚠ trong lúc làm | ⚠ tìm lỗi kỹ thuật | | ⚠ RETROSPECTIVE | ⚠ chính đội | ⚠ cuối mỗi sprint | ⚠ cải tiến cách làm việc | | ⚠ DEBRIEFING | ⚠ người tham gia | ⚠ sau một sự kiện | ⚠ rút bài học ngay | | ⚠ RÀ SOÁT CỔNG GIAI ĐOẠN | ⚠ lãnh đạo | ⚠ cuối mỗi giai đoạn | ⚠ quyết đi tiếp hay dừng | | ⚠ Điểm phân biệt then chốt | ⚠ kiểm toán là loại DUY NHẤT nhấn mạnh tính ĐỘC LẬP và sự TUÂN THỦ |

Từ khoá nhận diện:

"tuân thủ quy định, phương pháp, chính sách" → ⚠ kiểm toán "bên thứ ba, độc lập, cấp trên tổ chức" → ⚠ kiểm toán "cải tiến cách làm của chính đội" → ⚠ retrospective "rút kinh nghiệm sau sự kiện" → ⚠ debriefing

⚠ Các dấu hiệu bệnh trong đề của Tracey Dấu hiệu
⚠ Đội không giao tiếp với nhau ⚠ vấn đề giao tiếp hoặc lòng tin
⚠ Báo cáo tháng RẤT CHUNG CHUNG ⚠ dấu hiệu che giấu, hoặc không có dữ liệu thật
⚠ Tinh thần chung thấp ⚠ thường là HỆ QUẢ, không phải nguyên nhân
⚠ Tiến độ không đạt
⚠ Vì sao cần kiểm toán độc lập ⚠ khi báo cáo nội bộ đã không còn đáng tin thì phải có người ngoài nhìn vào
⚠ Kiểm toán KHÔNG phải để làm gì Nội dung
⚠ KHÔNG phải để tìm người đổ lỗi ⚠ hiểu lầm phổ biến nhất, và làm hỏng mọi cuộc kiểm toán
⚠ KHÔNG phải để phạt
⚠ Mục đích là tìm LỖ HỔNG QUY TRÌNH và khuyến nghị cải tiến
⚠ PM nên phản ứng thế nào ⚠ hợp tác đầy đủ, cung cấp dữ liệu thật — chống đối chỉ khiến kết luận xấu hơn
⚠ Đầu ra ⚠ báo cáo kiểm toán kèm phát hiện và khuyến nghị, thường dẫn tới HÀNH ĐỘNG KHẮC PHỤC — xem #25939

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo của bạn có đủ cụ thể để người ngoài hiểu tình hình thật không | | | Đội có sợ kiểm toán không | ⚠ sợ là dấu hiệu văn hoá đổ lỗi | | Khuyến nghị của lần kiểm toán trước đã được làm chưa | |

Và điều một quản lý dự án nên nhận ra khi bị kiểm toán: cuộc kiểm toán không phải là vấn đề. Nó là hệ quả của việc những vấn đề khác đã không được nói ra sớm hơn.

Câu 226 People
Rosa is the project manager for her organization's new project, which will use push and pull communication both daily. The project sponsor has sent a memo to Rosa, the project team members, and the project customers. Who is the encoder here?
  1. A Project team members
  2. B Project customers
  3. C Project manager
  4. D Project sponsor
Xem giải thích

Đáp án

D — NHÀ TÀI TRỢ DỰ ÁN.

Vì sao đúng

⚠ Mô hình giao tiếp cơ bản: | Thành phần | Nghĩa | Trong tình huống này | |---|---|---| | ⚠ NGƯỜI GỬI / MÃ HOÁ (encoder) | ⚠ người biến ý nghĩ thành thông điệp | ⚠ NHÀ TÀI TRỢ — người soạn và gửi bản ghi nhớ | | ⚠ THÔNG ĐIỆP | ⚠ nội dung được truyền | ⚠ bản ghi nhớ | | ⚠ PHƯƠNG TIỆN | ⚠ kênh truyền | ⚠ văn bản | | ⚠ NGƯỜI NHẬN / GIẢI MÃ (decoder) | ⚠ người diễn giải thông điệp | ⚠ Rosa, đội dự án, khách hàng | | ⚠ NHIỄU | ⚠ thứ làm méo thông điệp | ⚠ từ ngữ mơ hồ, khác biệt ngôn ngữ, thiếu bối cảnh | | ⚠ PHẢN HỒI | ⚠ xác nhận đã hiểu | ⚠ thư trả lời | | ⚠ Quy tắc nhớ | ⚠ AI GỬI thì người đó MÃ HOÁ, ai NHẬN thì người đó GIẢI MÃ — đơn giản vậy thôi |

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

  • C (quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất vì Rosa là nhân vật chính của đề và thường là người giao tiếp nhiều nhất: ⚠ nhưng ở ⚠ thông điệp CỤ THỂ này, ⚠ Rosa nằm trong danh sách NHẬN — ⚠ cô là người GIẢI MÃ, không phải mã hoá.

  • A (thành viên đội dự án) và B (khách hàng) — ⚠ cũng là người NHẬN, ⚠ nên cũng giải mã.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25942 ở lô này (ràng buộc giao tiếp — vị trí địa lý), câu #25885 ở lô 183 (bố trí đội ngồi chung), và câu #25906 (vai trò nhà tài trợ). ⚠ Nhóm quản lý giao tiếp.

⚠ Chi tiết "đẩy và kéo" trong đề nghĩa là gì: | Kiểu | Nghĩa | Ví dụ | |---|---|---| | ⚠ TƯƠNG TÁC (interactive) | ⚠ trao đổi hai chiều theo thời gian thực | ⚠ họp, gọi điện, thảo luận | | ⚠ ĐẨY (push) | ⚠ gửi tới người nhận cụ thể, KHÔNG chắc họ đã đọc | ⚠ email, bản ghi nhớ — CHÍNH LÀ TÌNH HUỐNG NÀY | | ⚠ KÉO (pull) | ⚠ để ở nơi chung, người cần TỰ LẤY | ⚠ kho tài liệu, bảng thông tin, mạng nội bộ | | ⚠ Điểm quan trọng nhất | ⚠ ĐẨY bảo đảm ĐÃ GỬI, KHÔNG bảo đảm ĐÃ HIỂU — đó là lý do phản hồi tồn tại trong mô hình | | ⚠ Chọn kiểu nào | ⚠ thông tin quan trọng và phức tạp thì dùng TƯƠNG TÁC, không dùng đẩy |

Từ khoá nhận diện:

"ai là người mã hoá" → ⚠ người GỬI thông điệp "ai là người giải mã" → ⚠ người NHẬN thông điệp "email, bản ghi nhớ, báo cáo gửi đi" → ⚠ giao tiếp ĐẨY "bảng thông tin, kho tài liệu" → ⚠ giao tiếp KÉO "họp, gọi điện" → ⚠ giao tiếp TƯƠNG TÁC

⚠ Nhiễu trong giao tiếp đến từ đâu Nguồn nhiễu
⚠ Khác biệt ngôn ngữ và văn hoá ⚠ liên hệ #25942 — dự án đa quốc gia
⚠ Thuật ngữ chuyên ngành người nhận không hiểu ⚠ liên hệ #25913 lô 183 — story point
⚠ Thiếu bối cảnh, viết quá ngắn gọn
⚠ Cảm xúc và định kiến sẵn có của người nhận
⚠ Kênh không phù hợp với nội dung ⚠ tin nhạy cảm gửi bằng email nhóm
⚠ Cách giảm nhiễu ⚠ chọn đúng kênh, viết rõ, và LUÔN có cơ chế phản hồi
⚠ Vì sao mô hình này quan trọng trong thực tế Lý do
⚠ PM dành 80–90% thời gian để giao tiếp ⚠ con số kinh điển của PMI
⚠ Phần lớn vấn đề dự án bắt nguồn từ giao tiếp
⚠ "Đã gửi rồi" không phải là đã giao tiếp ⚠ bài học rút ra từ chính mô hình này
⚠ Kiểm tra đơn giản ⚠ hỏi lại người nhận xem họ hiểu thông điệp thế nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông tin quan trọng gần nhất bạn gửi bằng kênh nào | | | Bạn có xác nhận người ta đã hiểu không, hay chỉ biết đã gửi | | | Kho tài liệu (kênh kéo) của dự án có ai vào không | ⚠ kênh kéo chỉ hiệu quả khi người ta biết và nhớ vào lấy |

Và điều đơn giản mà mô hình này dạy: trách nhiệm làm cho thông điệp được hiểu thuộc về người gửi, không thuộc về người nhận.

Câu 227 Process
You are meeting with Jessie, a project stakeholder with low interest and low influence. You need to account for Jessie in the communications management plan, so you ask him how he prefers communication. He tells you that you can send him an instant message (IM) about project developments. What type of communication is this?
  1. A Informal written
  2. B Informal verbal
  3. C Formal written
  4. D Formal verbal
Xem giải thích

Đáp án

A — VĂN BẢN KHÔNG CHÍNH THỨC (informal written).

Vì sao đúng

⚠ Phân loại tin nhắn nhanh: | Chiều phân loại | Kết quả | |---|---| | ⚠ VIẾT hay NÓI? | ⚠ VIẾT — tin nhắn là chữ | | ⚠ CHÍNH THỨC hay KHÔNG? | ⚠ KHÔNG chính thức — không theo mẫu, không lưu hồ sơ, không cần phê duyệt | | ⚠ Kết luận | ⚠ văn bản không chính thức | | ⚠ Phù hợp với ai | ⚠ Jessie có ÍT quan tâm và ÍT ảnh hưởng — kênh nhẹ nhàng là đúng mức | | ⚠ Nguyên tắc | ⚠ mức trang trọng phải TƯƠNG XỨNG với tầm quan trọng của bên liên quan và của nội dung |

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

  • C (văn bản chính thức) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là văn bản: ⚠ nhưng văn bản chính thức là ⚠ hợp đồng, điều lệ, báo cáo trạng thái chính thức, thư khiếu nại ⚠ — có mẫu, có lưu trữ, có giá trị pháp lý hoặc hợp đồng; ⚠ tin nhắn nhanh không có gì trong số đó.

  • B (lời nói không chính thức) — ⚠ trò chuyện, gọi điện tán gẫu; ⚠ tin nhắn là chữ viết, không phải lời nói.

  • D (lời nói chính thức) — ⚠ thuyết trình, phát biểu chính thức; ⚠ cũng không phải.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25948 ở lô này (mô hình mã hoá-giải mã, ba kiểu đẩy/kéo/tương tác), câu #25942 (ràng buộc giao tiếp), và câu #25954 cũng ở lô này (giao tiếp trực tiếp hiệu quả nhất). ⚠ BỐN câu về giao tiếp trong cùng một lô — chủ đề dày nhất của lô này.

⚠ BỐN Ô của ma trận giao tiếp: | Kiểu | Ví dụ | Dùng khi | |---|---|---| | ⚠ VĂN BẢN CHÍNH THỨC | ⚠ hợp đồng, điều lệ, báo cáo chính thức, thông báo pháp lý | ⚠ cần lưu vết và ràng buộc | | ⚠ VĂN BẢN KHÔNG CHÍNH THỨC | ⚠ email nhanh, tin nhắn, ghi chú — CÂU NÀY | ⚠ trao đổi hằng ngày | | ⚠ LỜI NÓI CHÍNH THỨC | ⚠ thuyết trình, họp lãnh đạo, phát biểu | ⚠ truyền đạt quan trọng có nghi thức | | ⚠ LỜI NÓI KHÔNG CHÍNH THỨC | ⚠ trò chuyện, gọi điện nhanh, tán gẫu bên máy pha cà phê | ⚠ xây quan hệ, nắm tin nhanh | | ⚠ Mẹo phân loại | ⚠ hỏi hai câu: VIẾT hay NÓI, và CÓ LƯU HỒ SƠ RÀNG BUỘC hay không |

Từ khoá nhận diện:

"tin nhắn, email nhanh, ghi chú" → ⚠ văn bản không chính thức "hợp đồng, điều lệ, khiếu nại" → ⚠ văn bản chính thức "thuyết trình" → ⚠ lời nói chính thức "trò chuyện" → ⚠ lời nói không chính thức

⚠ Ma trận quyền lực – quan tâm Nhóm Cách đối xử
⚠ Quyền cao – Quan tâm cao ⚠ QUẢN LÝ CHẶT CHẼ ⚠ giao tiếp thường xuyên, trang trọng
⚠ Quyền cao – Quan tâm thấp ⚠ GIỮ HÀI LÒNG ⚠ báo cáo tóm tắt, đừng làm phiền quá mức
⚠ Quyền thấp – Quan tâm cao ⚠ GIỮ THÔNG TIN ĐẦY ĐỦ ⚠ họ quan tâm nên muốn biết chi tiết
⚠ Quyền thấp – Quan tâm thấp ⚠ THEO DÕI — chính là Jessie ⚠ kênh nhẹ, tần suất thấp
⚠ Lưu ý ⚠ vị trí trên ma trận CÓ THỂ THAY ĐỔI trong dự án — phải rà lại định kỳ
⚠ Rủi ro của kênh không chính thức Rủi ro
⚠ Không có dấu vết khi cần chứng minh đã báo
⚠ Dễ bị hiểu sai giọng điệu ⚠ chữ viết ngắn rất dễ đọc thành gay gắt
⚠ Thông tin quan trọng lẫn vào dòng tin nhắn rồi trôi mất
⚠ Nguyên tắc an toàn ⚠ quyết định quan trọng dù bàn ở kênh nào cũng phải được GHI LẠI ở kênh chính thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có HỎI từng bên liên quan họ muốn nhận tin thế nào không | ⚠ đúng việc bạn vừa làm với Jessie | | Quyết định bàn qua tin nhắn có được ghi lại ở đâu không | | | Có bên liên quan nào đang nhận quá nhiều hoặc quá ít thông tin không | |

Và điều hay nhất trong tình huống này không phải là phân loại đúng kênh: đó là việc bạn đã hỏi Jessie thay vì tự quyết hộ anh ấy.

Câu 228 People
Farah is the project manager of a massive technical project. She believes one of her team members, Kathy, has received an important message but based on her body language; she disagrees with it. What is this known as?
  1. A Decoder
  2. B Acknowledgment
  3. C Transmission
  4. D Negotiation
Xem giải thích

Đáp án

B — XÁC NHẬN (acknowledgment).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Farah tin rằng Kathy ĐÃ NHẬN được thông điệp | ⚠ thông điệp đã tới đích | | ⚠ Căn cứ vào NGÔN NGỮ CƠ THỂ của Kathy | ⚠ tín hiệu phi lời cho biết đã tiếp nhận | | ⚠ Kathy KHÔNG ĐỒNG TÌNH với nội dung | ⚠ đây là điểm mấu chốt | | ⚠ XÁC NHẬN nghĩa là đã NHẬN, KHÔNG có nghĩa là ĐỒNG Ý | ⚠ định nghĩa chính xác của thuật ngữ | | ⚠ Kết luận | ⚠ Farah đang quan sát được sự XÁC NHẬN, chưa phải sự đồng thuận |

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

  • A (người giải mã — decoder) — ⚠ phương án gây nhiễu mạnh nhất vì Kathy đúng là người giải mã: ⚠ nhưng câu hỏi hỏi ⚠ HIỆN TƯỢNG mà Farah quan sát được TÊN LÀ GÌ, ⚠ không hỏi Kathy đóng vai gì trong mô hình; ⚠ "người giải mã" là một VAI, không phải một hiện tượng.

  • C (truyền tải — transmission) — ⚠ là bước GỬI thông điệp đi, ⚠ đã xảy ra trước đó rồi.

  • D (thương lượng) — ⚠ quá trình hai bên tìm điểm chung; ⚠ chưa xảy ra ở đây.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25948 ở lô này (nhà tài trợ là người mã hoá) — ⚠ hai câu cùng khai thác mô hình giao tiếp, một câu hỏi VAI, một câu hỏi HIỆN TƯỢNG. ⚠ Xem thêm câu #25925 ở lô 183 (Megan học nghe đồng cảm) và câu #25926 (bất đồng và cam kết).

⚠ BA mức phản hồi cần phân biệt rõ: | Mức | Nghĩa | |---|---| | ⚠ XÁC NHẬN (acknowledgment) | ⚠ "tôi đã NHẬN được thông điệp" — CÂU NÀY | | ⚠ HIỂU (understanding) | ⚠ "tôi hiểu ĐÚNG ý bạn muốn nói" | | ⚠ ĐỒNG THUẬN (agreement) | ⚠ "tôi ĐỒNG Ý với nội dung đó" | | ⚠ Sai lầm nguy hiểm nhất | ⚠ coi xác nhận là đồng thuận — người gật đầu chưa chắc đã đồng ý, thậm chí chưa chắc đã hiểu | | ⚠ Ở tình huống này | ⚠ Kathy XÁC NHẬN nhưng KHÔNG ĐỒNG THUẬN, và Farah đọc được điều đó qua ngôn ngữ cơ thể |

Từ khoá nhận diện:

"đã nhận được nhưng không đồng ý" → ⚠ xác nhận "gửi thông điệp đi" → ⚠ truyền tải "người diễn giải thông điệp" → ⚠ người giải mã (một VAI, không phải hiện tượng) "tìm điểm chung giữa hai bên" → ⚠ thương lượng

⚠ Ngôn ngữ phi lời chiếm bao nhiêu Nội dung
⚠ Phần lớn ý nghĩa đến từ giọng điệu và ngôn ngữ cơ thể ⚠ chứ không phải từ ngữ
⚠ Vì thế giao tiếp TRỰC TIẾP hiệu quả nhất ⚠ liên hệ #25954 cùng lô
⚠ Email và tin nhắn mất hoàn toàn tầng này ⚠ nguồn hiểu lầm lớn nhất trong đội phân tán
⚠ Bài học cho đội từ xa ⚠ bật camera không phải để giám sát, mà để lấy lại tầng thông tin đã mất
⚠ Farah nên làm gì tiếp theo Việc
⚠ HỎI THẲNG Kathy nghĩ gì ⚠ đừng suy diễn từ ngôn ngữ cơ thể rồi tự kết luận
⚠ Tạo không gian an toàn để cô nói ra ⚠ liên hệ #25922 lô 183
⚠ Nếu Kathy không đồng tình, khuyến khích cô NÊU rồi CAM KẾT ⚠ liên hệ #25926
⚠ Điều KHÔNG nên làm ⚠ giả vờ không thấy — bất đồng ngầm luôn quay lại vào lúc bất tiện nhất
⚠ Cẩn trọng ⚠ ngôn ngữ cơ thể có thể bị đọc sai, nhất là giữa các nền văn hoá khác nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong họp gần nhất, có ai gật đầu mà bạn nghi là không đồng ý không | | | Bạn có hỏi lại hay bỏ qua | | | Đội bạn có cách nào để nêu bất đồng an toàn không | |

Và bài học gọn nhất của câu này: "đã nhận được" và "đã đồng ý" là hai chuyện hoàn toàn khác nhau — nhầm hai thứ đó là nguồn gốc của rất nhiều bất ngờ muộn màng trong dự án.

Câu 229 Business Environment
At Massive Dynamic, they use agile project accounting. What is the most likely benefit of this approach regarding procurement?
  1. A Procurement is consistent regardless of the approach.
  2. B The process is often much faster due to smaller statements of work and less legal wrangling.
  3. C The legal review must be completed within the timebox related to each sprint.
  4. D Contracts must be evaluated each day as part of scrum sessions.
Xem giải thích

Đáp án

B — Quy trình thường NHANH HƠN NHIỀU nhờ phạm vi công việc NHỎ HƠN và ÍT GIẰNG CO PHÁP LÝ hơn.

Vì sao đúng

⚠ Vì sao mua sắm trong agile nhanh hơn: | Lý do | Nội dung | |---|---| | ⚠ Phạm vi công việc (SOW) NHỎ hơn | ⚠ mua theo từng phần giá trị, không mua trọn gói cả dự án | | ⚠ Giá trị hợp đồng nhỏ hơn nên ÍT tầng phê duyệt | | | ⚠ Ít điều khoản phải thương lượng | ⚠ hợp đồng ngắn thì luật sư hai bên ít việc để cãi | | ⚠ Rủi ro chia nhỏ theo từng phần | ⚠ không phải khoá chặt mọi thứ trong một văn bản duy nhất | | ⚠ Điều chỉnh dễ hơn khi nhu cầu thay đổi | | | ⚠ Đánh đổi | ⚠ phải ký nhiều lần hơn, nên cần quan hệ tin cậy với nhà cung cấp |

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

  • A (mua sắm giống nhau bất kể phương pháp tiếp cận) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như một nguyên tắc chung: ⚠ nhưng ⚠ cách tiếp cận ẢNH HƯỞNG RẤT LỚN tới mua sắm ⚠ — dự án dự đoán hợp với giá cố định trọn gói, dự án agile hợp với hợp đồng linh hoạt theo từng phần.

  • C (rà soát pháp lý phải xong trong hộp thời gian của mỗi sprint) — ⚠ hiểu sai timeboxing: ⚠ hộp thời gian áp cho công việc của ĐỘI, ⚠ không áp cho quy trình pháp lý của tổ chức.

  • D (hợp đồng phải được xem xét hằng ngày trong buổi scrum) — ⚠ sai hoàn toàn về daily scrum ⚠ (xem #25921 lô 183 — chỉ ba câu hỏi, 15 phút).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25943 ở lô này (RFQ), câu #25941 (tìm gói thầu), câu #25907 ở lô 183 (make-or-buy), và câu #25882 ở lô 182 (PTA của FPIF). ⚠ Nhóm mua sắm — và đây là câu duy nhất nhìn mua sắm từ góc AGILE.

⚠ Kiểu hợp đồng theo cách tiếp cận: | Cách tiếp cận | Hợp đồng phù hợp | Vì sao | |---|---|---| | ⚠ DỰ ĐOÁN, phạm vi rõ | ⚠ Giá cố định trọn gói (FFP) | ⚠ biết chính xác mua gì | | ⚠ AGILE, phạm vi tiến hoá | ⚠ Thời gian và vật tư (T&M), hoặc giá cố định theo từng phần giao | ⚠ linh hoạt theo nhu cầu — CÂU NÀY | | ⚠ Nghiên cứu, bất định cao | ⚠ Hoàn phí (CR) | ⚠ không ai dám nhận giá cố định | | ⚠ Biến thể hay dùng trong agile | ⚠ hợp đồng "giá trần có chia sẻ tiết kiệm", hoặc mua theo từng SPRINT / từng bản phát hành | | ⚠ Điều khoản đặc trưng của agile | ⚠ cho phép ĐỔI hạng mục có cùng kích cỡ mà không cần sửa hợp đồng |

Từ khoá nhận diện:

"phạm vi công việc nhỏ, hợp đồng ngắn" → ⚠ mua sắm kiểu agile "mua sắm giống nhau bất kể cách tiếp cận" → ⚠ sai — cách tiếp cận quyết định kiểu hợp đồng "pháp lý phải xong trong sprint" → ⚠ hiểu sai timeboxing "bàn hợp đồng trong daily scrum" → ⚠ sai hoàn toàn về daily scrum

⚠ "Kế toán dự án theo agile" nghĩa là gì Nội dung
⚠ Cấp vốn theo TỪNG PHẦN, không cấp trọn gói một lần
⚠ Đo giá trị GIAO ĐƯỢC, không đo phần trăm hoàn thành kế hoạch
⚠ Quyết định tiếp tục đầu tư ở mỗi mốc ⚠ có thể dừng sớm nếu giá trị không như kỳ vọng
⚠ Ngân sách gắn với ĐỘI ổn định, không gắn với dự án ⚠ mô hình "cấp vốn cho đội, không cấp vốn cho dự án"
⚠ Lợi ích lớn nhất ⚠ tiền chỉ chảy tiếp khi giá trị đã được chứng minh
⚠ Khó khăn thật của mua sắm agile Khó khăn
⚠ Bộ phận pháp chế quen với hợp đồng trọn gói ⚠ cần thời gian và ví dụ để thuyết phục
⚠ Nhà cung cấp muốn chắc chắn về doanh thu
⚠ Khó viết điều khoản khi phạm vi còn tiến hoá ⚠ giải pháp: cố định QUY TRÌNH và CHẤT LƯỢNG, linh hoạt NỘI DUNG
⚠ Điều kiện thành công ⚠ quan hệ đối tác dựa trên tin cậy, không phải quan hệ mua-bán một lần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn khoá cứng phạm vi hay khoá cứng quy trình | | | Mất bao lâu để ký một hợp đồng nhỏ ở tổ chức bạn | ⚠ nếu quá lâu thì mua sắm agile khó áp dụng | | Nhà cung cấp có được mời vào sprint review không | |

Và điểm cốt lõi thường bị bỏ qua: mua sắm agile không phải là ký hợp đồng lỏng lẻo hơn — nó là ký nhiều hợp đồng chặt chẽ nhưng nhỏ hơn, để mỗi lần sai thì thiệt hại cũng nhỏ hơn.

Câu 230 People
Carol leads her agile team well. She ensures that her team members are recognized for their efforts, that they have the proper tools for their work, and that the pay and benefits are well-researched and appropriate for each role. She has a team gathering scheduled after work on Friday to celebrate the team's recent success. The best term for what Carol is displaying is
  1. A Pavlovian leadership
  2. B Servant leadership
  3. C A management focus
  4. D Management skills
Xem giải thích

Đáp án

B — LÃNH ĐẠO PHỤC VỤ (servant leadership).

Vì sao đúng

⚠ Những việc Carol làm và ý nghĩa: | Việc | Ý nghĩa | |---|---| | ⚠ Bảo đảm thành viên được GHI NHẬN công sức | ⚠ đáp ứng nhu cầu được tôn trọng | | ⚠ Bảo đảm họ có ĐÚNG CÔNG CỤ để làm việc | ⚠ gỡ vật cản — việc kinh điển của lãnh đạo phục vụ | | ⚠ Nghiên cứu kỹ lương và phúc lợi cho từng vai | ⚠ chăm lo nhu cầu cơ bản, xây lòng tin | | ⚠ Tổ chức buổi ăn mừng thành công | ⚠ xây dựng tinh thần đội | | ⚠ Điểm chung của cả bốn việc | ⚠ Carol PHỤC VỤ nhu cầu của đội để đội làm việc tốt nhất — đúng định nghĩa lãnh đạo phục vụ |

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

  • D (kỹ năng quản lý) — ⚠ phương án gây nhiễu mạnh nhất vì các việc Carol làm nghe cũng giống việc quản lý: ⚠ nhưng ⚠ quản lý tập trung vào CÔNG VIỆC và HỆ THỐNG, ⚠ còn ⚠ lãnh đạo phục vụ tập trung vào CON NGƯỜI ⚠ — và mọi hành động của Carol đều hướng vào người.

  • C (định hướng quản lý) — ⚠ cùng lý do: ⚠ mô tả người lo kiểm soát và quy trình, ⚠ không phải người phục vụ đội.

  • A (lãnh đạo kiểu Pavlov) — ⚠ KHÔNG PHẢI thuật ngữ chuẩn; ⚠ Pavlov gắn với phản xạ có điều kiện, ⚠ hàm ý thưởng-phạt máy móc — ⚠ ngược hẳn với những gì Carol làm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25922 ở lô 183 (lãnh đạo agile thừa nhận sai lầm), câu #25901 (phong cách lãnh đạo hỗ trợ), câu #25930 (thuyết kỳ vọng của Vroom), và câu #25919 (Scrum Master quyết cùng đội). ⚠ Bộ câu hỏi về lãnh đạo trong agile đã lên tới năm câu qua hai lô.

⚠ QUẢN LÝ và LÃNH ĐẠO khác nhau thế nào: | Quản lý | Lãnh đạo | |---|---| | ⚠ Tập trung vào HỆ THỐNG và cấu trúc | ⚠ Tập trung vào CON NGƯỜI | | ⚠ Dựa vào KIỂM SOÁT | ⚠ Dựa vào TIN CẬY | | ⚠ Hỏi KHI NÀO và THẾ NÀO | ⚠ Hỏi CÁI GÌ và TẠI SAO | | ⚠ Làm ĐÚNG VIỆC theo quy trình | ⚠ Làm VIỆC ĐÚNG | | ⚠ Duy trì | ⚠ Phát triển | | ⚠ Điểm quan trọng | ⚠ KHÔNG phải quản lý xấu, lãnh đạo tốt — dự án cần CẢ HAI; câu hỏi chỉ hỏi Carol đang thể hiện cái nào |

Từ khoá nhận diện:

"ghi nhận, gỡ vật cản, chăm lo nhu cầu, ăn mừng" → ⚠ lãnh đạo phục vụ "kiểm soát, quy trình, báo cáo, phân việc" → ⚠ quản lý "thưởng phạt máy móc" → ⚠ không phải thuật ngữ chuẩn trong PMP ⚠ Phương án chứa tên nhà khoa học không thuộc lĩnh vực quản trị → ⚠ thường là phương án bịa

⚠ Đặc điểm của lãnh đạo phục vụ: | Đặc điểm | Nội dung | |---|---| | ⚠ LẮNG NGHE | ⚠ liên hệ #25925 lô 183 — Megan học nghe đồng cảm | | ⚠ ĐỒNG CẢM | | | ⚠ CHỮA LÀNH quan hệ trong đội | | | ⚠ NHẬN THỨC về mình và về môi trường | | | ⚠ THUYẾT PHỤC thay vì áp đặt quyền lực | | | ⚠ PHÁT TRIỂN con người | | | ⚠ XÂY DỰNG cộng đồng | ⚠ buổi ăn mừng của Carol | | ⚠ Câu hỏi kiểm tra | ⚠ "người được phục vụ có trưởng thành hơn không?" |

⚠ Vì sao chi tiết "lương và phúc lợi" lại đáng chú ý Ý nghĩa
⚠ Theo Herzberg, lương là YẾU TỐ DUY TRÌ ⚠ không tạo động lực, nhưng thiếu thì gây bất mãn
⚠ Carol xử lý ĐÚNG: bảo đảm nó công bằng rồi tập trung vào ghi nhận ⚠ ghi nhận mới là yếu tố tạo động lực
⚠ Nhiều người lãnh đạo chỉ làm một trong hai ⚠ hoặc chỉ trả tiền, hoặc chỉ vỗ vai
⚠ Bài học ⚠ phải làm CẢ HAI mới đủ — liên hệ #25930 về ba thành phần của Vroom

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có đủ công cụ để làm việc không | ⚠ hỏi thẳng, câu trả lời thường bất ngờ | | Lần cuối bạn ghi nhận ai đó là khi nào | | | Đội có ăn mừng thành công không | ⚠ không ăn mừng thì mọi thắng lợi đều trôi qua như không có gì xảy ra |

Và thước đo thật của lãnh đạo phục vụ: không phải đội quý bạn tới mức nào, mà đội có làm được việc tốt hơn nhờ có bạn hay không.