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

Tìm thấy 720 câu.

Câu 101 Process
Wanda is a project manager for the Soap Corporation. She is operating in a strong matrix and has led projects for this organization over the past three years. In a status meeting with stakeholders, several people complained that the project reports they have been receiving do not seem to be up to date. What should Wanda do next?
  1. A Refer them to the steering committee for updates.
  2. B Refer to the information radiators for her project.
  3. C Confirm the version number of the reports they have.
  4. D Assign a project team member to update the reports.
Xem giải thích

Đáp án

C — XÁC NHẬN SỐ PHIÊN BẢN của các báo cáo mà họ đang có.

Vì sao đúng

⚠ Vì sao phải xác minh trước: | Lý do | Nội dung | |---|---| | ⚠ CHƯA BIẾT vấn đề nằm ở đâu | ⚠ báo cáo cũ thật, hay họ đang xem bản cũ? | | ⚠ Rất có thể họ đang cầm PHIÊN BẢN CŨ | ⚠ lưu về máy, in ra, hoặc đường dẫn cũ | | ⚠ Xác minh mất vài phút, sửa nhầm tốn nhiều hơn | | | ⚠ Wanda đã làm dự án 3 năm ở tổ chức này | ⚠ nhiều khả năng quy trình báo cáo của cô ấy đã ổn định | | ⚠ Nguyên tắc | ⚠ THU THẬP THÔNG TIN trước, HÀNH ĐỘNG sau |

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

  • D (giao một thành viên cập nhật lại báo cáo) — ⚠ HÀNH ĐỘNG khi chưa biết nguyên nhân; ⚠ nếu vấn đề là bên liên quan xem bản cũ thì làm lại báo cáo cũng vô ích.

  • B (chỉ họ tới các bảng thông tin của dự án) — ⚠ có thể hữu ích nhưng NÉ TRÁNH lời phàn nàn; ⚠ và không giải thích được vì sao báo cáo họ nhận lại cũ.

  • A (chuyển họ sang ban chỉ đạo để lấy cập nhật) — ⚠ đẩy trách nhiệm: ⚠ cung cấp thông tin dự án cho bên liên quan là việc của PM.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25760 ở lô 180 (tài liệu khó tìm → đánh giá cách lưu trữ trước) và câu #25754 ở lô 180 (điều tra nguyên nhân gốc trước khi hành động). ⚠ Ba câu cùng một nguyên tắc: xác minh trước, hành động sau.

⚠ Các nguyên nhân có thể của lời phàn nàn: | Nguyên nhân | Cách kiểm tra | |---|---| | ⚠ Họ đang xem bản CŨ đã lưu về máy | ⚠ hỏi số phiên bản — CÁCH CỦA CÂU NÀY | | ⚠ Đường dẫn họ dùng trỏ tới thư mục cũ | | | ⚠ Email thông báo cập nhật không tới được họ | | | ⚠ Báo cáo THẬT SỰ chưa được cập nhật | ⚠ lúc đó mới cần sửa quy trình | | ⚠ Tần suất báo cáo không đủ với nhu cầu của họ | ⚠ phải sửa kế hoạch giao tiếp | | ⚠ Mỗi nguyên nhân | ⚠ cần một giải pháp hoàn toàn khác |

Từ khoá nhận diện:

"báo cáo có vẻ không cập nhật" → ⚠ kiểm tra phiên bản trước "giao người sửa ngay" → ⚠ hành động khi chưa biết nguyên nhân "chuyển sang bộ phận khác" → ⚠ đẩy trách nhiệm, thường sai "bạn nên làm gì TIẾP THEO" → ⚠ bước thu thập thông tin nhỏ nhất

⚠ Quản lý phiên bản — vì sao quan trọng Lý do
⚠ Nhiều người cùng xem một tài liệu ở các thời điểm khác nhau
⚠ Quyết định dựa trên bản cũ có thể SAI
⚠ Tranh cãi "tôi thấy khác" thường do khác phiên bản
⚠ Cách phòng ⚠ đánh SỐ PHIÊN BẢN và NGÀY rõ ràng trên mọi tài liệu, dùng một nguồn duy nhất
⚠ Giải pháp lâu dài Wanda nên cân nhắc Giải pháp
⚠ Dùng MỘT NGUỒN DUY NHẤT — single source of truth ⚠ thay vì gửi file đính kèm
⚠ Ghi số phiên bản và ngày cập nhật ngay trên trang đầu
⚠ Dùng bảng điều khiển trực tuyến cập nhật thời gian thực ⚠ giao tiếp KÉO — xem câu #25681 ở lô 178
⚠ Thông báo khi có bản mới ⚠ kết hợp kéo với đẩy
⚠ Rà soát lại kế hoạch quản lý giao tiếp ⚠ tần suất và định dạng có phù hợp không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu của bạn có số phiên bản và ngày không | | | Bên liên quan lấy báo cáo từ đâu | ⚠ file đính kèm hay nguồn chung | | Có ai còn dùng đường dẫn cũ không | |

Và bài học nhỏ mà hiệu quả: trước khi sửa quy trình, hãy kiểm tra xem người ta có đang xem đúng bản không. Rất nhiều lời phàn nàn về "thông tin cũ" thực ra là vấn đề phiên bản, không phải vấn đề quy trình.

Câu 102 Process
You are the project manager of a construction project for an office complex development. The Project Management Office (PMO) has provided you flexibility in using a project artifact management system. However, they do require that you use their templates for the weekly status update meetings. Which of the following is not a characteristic of an effective archive management system?
  1. A A flexible process for the review and approval of documents
  2. B A way to produce and control documents without the unnecessary administrative overhead
  3. C Timely distribution of documents
  4. D Version control and security
Xem giải thích

Đáp án

A — Một quy trình LINH HOẠT để rà soát và phê duyệt tài liệu. ⚠ Đây KHÔNG phải đặc điểm của hệ thống lưu trữ hiệu quả.

Vì sao đúng

⚠ Vì sao "linh hoạt" là sai với quy trình duyệt tài liệu: | Lý do | Nội dung | |---|---| | ⚠ Quy trình duyệt phải NHẤT QUÁN và RÕ RÀNG | ⚠ ai duyệt, duyệt thế nào, trong bao lâu | | ⚠ Linh hoạt trong việc duyệt → mỗi tài liệu một kiểu | | | ⚠ Không biết bản nào đã được duyệt, bản nào chưa | | | ⚠ Mất tính KIỂM SOÁT — đúng thứ hệ thống lưu trữ sinh ra để bảo đảm | | | ⚠ Đúng ra phải là | ⚠ quy trình rà soát và phê duyệt CHẶT CHẼ và ĐƯỢC ĐỊNH NGHĨA RÕ |

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

⚠ Cả ba phương án còn lại ĐỀU là đặc điểm của hệ thống lưu trữ tốt:

  • D (kiểm soát phiên bản và bảo mật) — ⚠ hai yêu cầu CỐT LÕI: ⚠ biết bản nào mới nhất và ai được xem gì.

  • B (tạo và kiểm soát tài liệu mà KHÔNG có thủ tục hành chính thừa) — ⚠ ĐÚNG: ⚠ hệ thống tốt phải NHẸ, không cản trở công việc.

  • C (phân phối tài liệu KỊP THỜI) — ⚠ ĐÚNG: ⚠ tài liệu tới muộn thì mất giá trị.

Ghi nhớ

⚠ Điểm tinh tế của câu này — hai chữ "linh hoạt" khác nhau: | Chỗ nào cần LINH HOẠT | Chỗ nào cần CHẶT CHẼ | |---|---| | ⚠ Việc TẠO tài liệu — không thủ tục thừa | ⚠ việc RÀ SOÁT và PHÊ DUYỆT | | ⚠ Cách trình bày phù hợp người đọc | ⚠ KIỂM SOÁT PHIÊN BẢN | | ⚠ Công cụ dùng để soạn thảo | ⚠ PHÂN QUYỀN truy cập | | ⚠ Nguyên tắc | ⚠ nhẹ về THỦ TỤC, chặt về KIỂM SOÁT — hai chuyện khác nhau |

⚠ Đối chiếu: ⚠ câu #25823 ngay trên về vấn đề phiên bản báo cáo và câu #25760 ở lô 180 về cấu trúc lưu trữ tài liệu. ⚠ Ba câu cùng chủ đề quản lý thông tin dự án.

⚠ Đặc điểm của hệ thống lưu trữ hiệu quả: | Đặc điểm | Nội dung | |---|---| | ⚠ KIỂM SOÁT PHIÊN BẢN | ⚠ luôn biết bản nào mới nhất, xem lại được lịch sử | | ⚠ BẢO MẬT và phân quyền | ⚠ ai được xem, ai được sửa | | ⚠ Quy trình rà soát và phê duyệt RÕ RÀNG | ⚠ không linh hoạt tuỳ tiện | | ⚠ Phân phối KỊP THỜI | | | ⚠ TÌM KIẾM dễ dàng | | | ⚠ Không có thủ tục hành chính thừa | | | ⚠ Có chính sách LƯU TRỮ và HUỶ tài liệu | | | ⚠ Sao lưu và khôi phục được | |

Từ khoá nhận diện:

"linh hoạt trong phê duyệt" → ⚠ SAI — phê duyệt phải nhất quán "không thủ tục thừa" → ⚠ ĐÚNG — nhẹ về hành chính "kiểm soát phiên bản, bảo mật" → ⚠ ĐÚNG — bắt buộc "phân phối kịp thời" → ⚠ ĐÚNG

⚠ Bối cảnh trong đề có ý nghĩa gì Ý nghĩa
⚠ PMO cho LINH HOẠT về hệ thống quản lý hiện vật ⚠ chọn công cụ nào tuỳ dự án
⚠ Nhưng BẮT BUỘC dùng mẫu chuẩn cho họp trạng thái tuần ⚠ nhất quán ở chỗ cần nhất quán
⚠ Đây là ⚠ CONTROLLING PMO — cấp mẫu và yêu cầu tuân thủ; xem câu #25644 ở lô 178
⚠ Cân bằng hợp lý ⚠ linh hoạt về công cụ, chặt chẽ về đầu ra
⚠ Vì sao dự án xây dựng đặc biệt cần lưu trữ tốt Lý do
⚠ Rất nhiều bản vẽ, đặc tả và phiên bản sửa đổi
⚠ Dùng nhầm bản vẽ cũ gây hậu quả VẬT LÝ tốn kém
⚠ Hồ sơ pháp lý phải lưu nhiều năm ⚠ phục vụ kiểm định, bảo hành, tranh chấp
⚠ Nhiều nhà thầu cùng cần truy cập
⚠ Liên hệ ⚠ xem câu #25822 — tranh chấp về vị trí tủ điện giải quyết được nhờ có tài liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai được quyền phê duyệt tài liệu và quy trình ra sao | | | Hệ thống có kiểm soát phiên bản không | | | Thủ tục có nặng tới mức người ta né tránh không | ⚠ nếu có thì họ sẽ dùng file riêng — và mất kiểm soát |

Và nguyên tắc thiết kế hệ thống tài liệu: dễ dùng đúng cách, khó dùng sai cách. Thủ tục quá nặng khiến người ta lách, và lúc đó mọi biện pháp kiểm soát đều vô hiệu.

Câu 103 Business Environment
Your functional manager asks you to add features to the project scope to consume the remaining dollars in the project budget. This is an example of which one of the following?
  1. A Change control
  2. B Functional management
  3. C Cost of quality
  4. D Gold plating
Xem giải thích

Đáp án

D — Gold plating (mạ vàng — thêm thứ không ai yêu cầu).

Vì sao đúng

⚠ Vì sao đây là gold plating: | Chi tiết | Suy ra | |---|---| | ⚠ THÊM tính năng vào phạm vi dự án | | | ⚠ Lý do: để TIÊU HẾT số tiền còn dư trong ngân sách | ⚠ không phải vì khách hàng cần | | ⚠ KHÔNG có yêu cầu nào từ khách hàng | | | ⚠ KHÔNG qua quy trình kiểm soát thay đổi | | | ⚠ Kết luận | ⚠ thêm thứ không ai yêu cầu = gold plating, dù người đề xuất là quản lý chức năng |

⚠ Lý do "tiêu hết ngân sách" là động cơ đặc biệt tệ: | Vấn đề | Nội dung | |---|---| | ⚠ Ngân sách dư là THÀNH TÍCH, không phải vấn đề cần xử lý | | | ⚠ Tiền dư nên trả lại tổ chức để dùng cho việc khác | | | ⚠ Thêm tính năng làm tăng RỦI RO và công việc bảo trì | | | ⚠ Có thể làm chậm dự án | | | ⚠ Động cơ thật đằng sau | ⚠ sợ năm sau bị cắt ngân sách vì năm nay tiêu không hết — vấn đề của cơ chế, không phải của dự án |

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

  • A (Change control — kiểm soát thay đổi) — ⚠ là QUY TRÌNH đúng đắn; ⚠ nếu việc thêm tính năng đi qua quy trình này thì đã không phải gold plating.

  • C (Cost of quality — chi phí chất lượng) — ⚠ là bốn nhóm chi phí liên quan tới chất lượng; ⚠ thêm tính năng thừa không thuộc nhóm nào cả.

  • B (Functional management) — ⚠ không phải một khái niệm mô tả hành vi này.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25635 ở lô 178 ⚠ (Tom cho rằng chất lượng là giao nhiều hơn khách yêu cầu). ⚠ Hai câu ⚠ cùng kiểm tra khái niệm gold plating ⚠ nhưng ⚠ khác động cơ: ⚠ #25635 là "cho khách vui", câu này là "tiêu hết ngân sách". ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ Và câu #25643 ở lô 178 phân biệt gold plating với scope creep.

⚠ Ba hiện tượng phải phân biệt: | Hiện tượng | Ai gây ra | Có qua quy trình không | |---|---|---| | ⚠ Gold plating | ⚠ ĐỘI hoặc NỘI BỘ tổ chức tự thêm | ⚠ KHÔNG — CÂU NÀY | | ⚠ Scope creep | ⚠ bên liên quan / khách hàng xin thêm | ⚠ KHÔNG | | ⚠ Change request hợp lệ | ⚠ bất kỳ ai | ⚠ CÓ — có đánh giá và phê duyệt |

Từ khoá nhận diện:

"thêm tính năng không ai yêu cầu" → ⚠ gold plating "tiêu hết ngân sách còn dư" → ⚠ động cơ sai, dẫn tới gold plating "khách hàng xin thêm không qua quy trình" → ⚠ scope creep "đánh giá tác động rồi trình duyệt" → ⚠ quy trình đúng

⚠ Bạn nên phản hồi quản lý chức năng thế nào Cách
⚠ Giải thích rằng thêm phạm vi phải qua KIỂM SOÁT THAY ĐỔI
⚠ Nêu rõ tác động: rủi ro, lịch trình, bảo trì về sau
⚠ Đề xuất TRẢ LẠI ngân sách dư cho tổ chức ⚠ đó là kết quả tốt, không phải thất bại
⚠ Nếu tính năng thật sự có giá trị: mở yêu cầu thay đổi chính thức ⚠ để khách hàng và nhà tài trợ quyết
⚠ Đừng ⚠ im lặng làm theo chỉ vì người đề nghị là quản lý chức năng
⚠ Vì sao "tiêu hết ngân sách" là văn hoá xấu Lý do
⚠ Khuyến khích lãng phí có hệ thống
⚠ Làm sai lệch dữ liệu ước lượng cho dự án sau
⚠ Trừng phạt người tiết kiệm
⚠ Cách chữa ở cấp tổ chức ⚠ không cắt ngân sách của đơn vị chỉ vì họ tiêu ít hơn dự kiến

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng này có trong phạm vi đã duyệt không | | | Có ai ngoài người đề xuất muốn nó không | | | Bạn đã đưa qua quy trình thay đổi chưa | |

Và điều dễ bị bỏ qua: gold plating không chỉ đến từ đội kỹ thuật. Nó cũng đến từ quản lý — và khi đến từ cấp trên thì càng khó từ chối, nên càng phải dựa vào quy trình.

Câu 104 People
Jonis is a scrum master for a software development project. The project team is made up of nine people, five of which have worked together in the past. During the stand-up, Jonis notices that one of the team members frequently stays quiet and only offers information when explicitly called upon. What should Jonis do?
  1. A Write up the team member for not contributing to stand-up meetings.
  2. B Call out the team member from the next stand-up meeting for not speaking up.
  3. C Nothing, if the team member needs help, he will ask.
  4. D Privately chat with the team member to see if everything is going well.
Xem giải thích

Đáp án

D — NÓI CHUYỆN RIÊNG với thành viên đó để xem mọi việc có ổn không.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ CHƯA BIẾT nguyên nhân — phải tìm hiểu trước | | | ⚠ Nói chuyện RIÊNG thể hiện tôn trọng và quan tâm | | | ⚠ Người ít nói dễ mở lòng khi không có đám đông | | | ⚠ Có thể có vấn đề cá nhân, kỹ thuật, hoặc văn hoá | | | ⚠ Kết luận | ⚠ hỏi trước, kết luận sau — và hỏi ở nơi người ta thấy an toàn |

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

  • B (nêu tên người đó ra trong buổi standup tiếp theo vì không phát biểu) — ⚠ CÔNG KHAI chỉ trích trước cả đội; ⚠ với người vốn đã ngại nói, cách này khiến họ càng thu mình.

  • A (lập biên bản vì không đóng góp trong standup) — ⚠ biện pháp kỷ luật khi chưa tìm hiểu; ⚠ và ⚠ Scrum Master KHÔNG có quyền kỷ luật — đó không phải vai trò quản lý nhân sự.

  • C (không làm gì, cần giúp thì họ sẽ hỏi) — ⚠ BỎ MẶC: ⚠ chính người ngại nói là người ÍT có khả năng chủ động xin giúp đỡ nhất.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25830 CÙNG LÔ ⚠ (Sydney giỏi dựng phim nhưng thiếu tự tin, ngại nêu ý kiến). ⚠ Hai câu ⚠ cùng tình huống thành viên ít phát biểu, ⚠ và cả hai khoá đều theo hướng ⚠ CHỦ ĐỘNG TIẾP CẬN nhẹ nhàng: ⚠ câu này là nói chuyện riêng để tìm hiểu, #25830 là hỏi ý kiến chuyên môn của cô ấy. ⚠ Hai khoá KHÔNG mâu thuẫn mà BỔ SUNG nhau — ⚠ tìm hiểu trước, rồi tạo cơ hội đóng góp. ⚠ Và câu #25743 ở lô 180 (bên liên quan mới ngần ngại tham gia → tạo cơ hội xây dựng đội) là câu thứ ba cùng chủ đề.

⚠ Các nguyên nhân có thể khiến thành viên ít nói: | Nguyên nhân | Dấu hiệu | |---|---| | ⚠ Tính cách hướng nội | ⚠ cần thời gian suy nghĩ trước khi nói — hoàn toàn bình thường | | ⚠ Chưa thấy AN TOÀN trong đội | ⚠ bốn trong chín người là người mới với nhau | | ⚠ Rào cản ngôn ngữ hoặc văn hoá | | | ⚠ Không hiểu công việc đang bàn | ⚠ ngại lộ ra | | ⚠ Có vấn đề cá nhân | | | ⚠ Từng bị gạt bỏ ý kiến trước đây | | | ⚠ Mỗi nguyên nhân | ⚠ cần cách xử lý khác nhau — nên phải HỎI |

Từ khoá nhận diện:

"thành viên ít nói" → ⚠ tìm hiểu riêng trước "nêu tên trước đội" → ⚠ luôn là đáp án sai "lập biên bản, kỷ luật" → ⚠ Scrum Master không có quyền này "cứ để họ tự tìm tới" → ⚠ bỏ mặc, cũng sai

⚠ Cách nói chuyện riêng cho hiệu quả Cách
⚠ Bắt đầu bằng QUAN TÂM, không bằng phê bình ⚠ "dạo này mọi việc ổn chứ?"
⚠ Hỏi mở, không dồn ép
⚠ LẮNG NGHE nhiều hơn nói
⚠ Hỏi họ CẦN GÌ để thoải mái đóng góp hơn
⚠ Đừng hứa điều mình không làm được
⚠ Sau đó ⚠ điều chỉnh cách điều phối standup nếu cần
⚠ Cách điều chỉnh standup cho người hướng nội Cách
⚠ Gửi câu hỏi trước để họ chuẩn bị ⚠ giống tinh thần brainwriting — xem câu #25715
⚠ Cho phép cập nhật bằng văn bản trước buổi họp
⚠ Đi vòng theo thứ tự để ai cũng có lượt
⚠ Đừng ép mọi người phải nói dài ⚠ standup chỉ 15 phút
⚠ Nhớ rằng ⚠ ít nói KHÔNG đồng nghĩa với không đóng góp — nhiều người hướng nội làm việc rất tốt
⚠ Ranh giới vai trò của Scrum Master Ranh giới
⚠ CÓ: quan tâm, gỡ trở ngại, điều phối, huấn luyện
⚠ KHÔNG: kỷ luật, đánh giá hiệu suất, quyết định nhân sự ⚠ đó là việc của quản lý chức năng
⚠ Vì thế ⚠ phương án lập biên bản sai cả về cách làm lẫn về thẩm quyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã hỏi người đó chưa | ⚠ trước khi kết luận bất cứ điều gì | | Đội có đủ an toàn để mọi người nói thật không | | | Cách điều phối họp có phù hợp với mọi kiểu tính cách không | |

Và điều dễ hiểu nhầm nhất về người ít nói trong đội: im lặng không có nghĩa là không quan tâm. Rất nhiều người chỉ cần được hỏi đúng cách và đúng chỗ.

Câu 105 People
Your team has had a long year of obstacles that they have overcome on several projects. During the chaos, they have continually handled themselves with professionalism and firmly adhered to the team charter. Throughout the project life cycles, you have acknowledged team members but have decided that there needs to be an additional reward for their exemplary behavior. Which one of the following would not be a good reward in this scenario?
  1. A Time off for the team members
  2. B Bonus pay for the team members
  3. C Team member of the year designation
  4. D Gift cards for dinner at local restaurants
Xem giải thích

Đáp án

C — Danh hiệu "Thành viên của năm". ⚠ Đây KHÔNG phải phần thưởng tốt trong tình huống này.

Vì sao đúng

⚠ Vì sao danh hiệu cá nhân không phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Thành tích là của CẢ ĐỘI | ⚠ đề nói rõ: cả đội cùng vượt qua trở ngại, cùng giữ chuyên nghiệp | | ⚠ Chọn MỘT người trong đội xuất sắc là TẠO SỰ CHIA RẼ | | | ⚠ Những người còn lại cảm thấy công sức bị xem nhẹ | | | ⚠ Có thể tạo cạnh tranh nội bộ không lành mạnh | | | ⚠ Nguyên tắc | ⚠ thành tích TẬP THỂ thì thưởng TẬP THỂ |

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

⚠ Cả ba phương án còn lại đều là phần thưởng cho TOÀN ĐỘI:

  • A (nghỉ phép cho các thành viên đội) — ⚠ ai cũng được, ⚠ và rất có giá trị sau một năm nhiều áp lực.

  • B (tiền thưởng cho các thành viên đội) — ⚠ ai cũng được.

  • D (phiếu ăn tại nhà hàng) — ⚠ ai cũng được, ⚠ và có thể dùng chung để gắn kết đội.

Ghi nhớ

⚠ Nguyên tắc thưởng và ghi nhận trong PMBOK: | Nguyên tắc | Nội dung | |---|---| | ⚠ Thưởng phải KHỚP với hành vi muốn khuyến khích | ⚠ muốn đội hợp tác thì đừng thưởng cá nhân | | ⚠ Chỉ thưởng cho hành vi NGƯỜI TA KIỂM SOÁT ĐƯỢC | | | ⚠ Thưởng phải là thứ người nhận THẬT SỰ MUỐN | ⚠ liên hệ thuyết Vroom — xem câu #25710 ở lô 179 | | ⚠ Ghi nhận KỊP THỜI hiệu quả hơn thưởng lớn muộn màng | | | ⚠ Phần thưởng TẬP THỂ thúc đẩy hợp tác | | | ⚠ Phần thưởng CÁ NHÂN có thể thúc đẩy cạnh tranh nội bộ | ⚠ hại cho đội |

Từ khoá nhận diện:

"thành tích của cả đội" → ⚠ thưởng cả đội "chọn một cá nhân xuất sắc" → ⚠ gây chia rẽ khi thành tích là tập thể "thưởng phải là thứ họ muốn" → ⚠ thuyết kỳ vọng Vroom "ghi nhận kịp thời" → ⚠ hiệu quả hơn thưởng muộn

⚠ Khi nào phần thưởng CÁ NHÂN lại phù hợp Trường hợp
⚠ Thành tích rõ ràng là của một người
⚠ Đóng góp vượt xa vai trò được giao
⚠ Văn hoá tổ chức chấp nhận và minh bạch về tiêu chí
⚠ Nhưng vẫn cần cẩn thận ⚠ và không nên là hình thức DUY NHẤT của việc ghi nhận
⚠ Ý nghĩa của các phần thưởng trong đề Ý nghĩa
⚠ Nghỉ phép ⚠ rất giá trị sau năm nhiều áp lực — phục hồi năng lượng
⚠ Tiền thưởng ⚠ theo Herzberg là yếu tố DUY TRÌ, hiệu quả ngắn hạn
⚠ Phiếu ăn nhà hàng ⚠ có thể dùng chung, tăng gắn kết đội
⚠ Kết hợp với ⚠ sự GHI NHẬN công khai và cụ thể — thứ tạo động lực bền hơn tiền
⚠ Liên hệ với các thuyết động lực Liên hệ
⚠ Herzberg ⚠ tiền thưởng chống bất mãn; sự ghi nhận mới tạo động lực
⚠ Vroom ⚠ phần thưởng phải có GIÁ TRỊ với người nhận
⚠ McClelland ⚠ người thiên affiliation thích ghi nhận tập thể hơn danh hiệu cá nhân
⚠ Bài học ⚠ hỏi đội muốn gì thay vì tự quyết
⚠ Cách ghi nhận hiệu quả mà không tốn tiền Cách
⚠ Nêu CỤ THỂ họ đã làm gì tốt ⚠ "cảm ơn" chung chung ít giá trị
⚠ Ghi nhận trước mặt lãnh đạo cấp cao
⚠ Cho họ chọn dự án tiếp theo
⚠ Cơ hội học hỏi và phát triển
⚠ Trao thêm quyền tự chủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thành tích là của cá nhân hay của tập thể | ⚠ quyết định hình thức thưởng | | Bạn đã hỏi đội muốn gì chưa | | | Phần thưởng có tạo cạnh tranh nội bộ không | |

Và cạm bẫy phổ biến nhất của việc khen thưởng: thưởng cá nhân trong một đội hợp tác sẽ dạy người ta cạnh tranh với nhau. Hành vi bạn thưởng chính là hành vi bạn sẽ nhận được nhiều hơn.

Câu 106 Process
You are the project manager of the KNB Project for your organization. One of the first things you need to determine in your project planning is your grade of material as part of this specific construction project. Danny, a team member, says the grade needs to be high quality, or risks will enter the project. Mark says the quality determines the grade, not the quality. Max says that grade is just a ranking that you use when selecting material. Seth says that grade and the installation of the material constitute the quality of the project. Which team member's statement is correct?
  1. A Danny
  2. B Seth
  3. C Mark
  4. D Max
Xem giải thích

Đáp án

D — Max nói đúng: cấp độ chỉ là một THỨ HẠNG dùng khi lựa chọn vật liệu.

Vì sao đúng

⚠ Phát biểu của Max: | Nội dung | Đánh giá | |---|---| | ⚠ "Grade chỉ là thứ hạng dùng khi chọn vật liệu" | ⚠ ĐÚNG — grade là phân hạng theo đặc tính kỹ thuật | | ⚠ Không gắn grade với quality | ⚠ ĐÚNG — hai khái niệm độc lập | | ⚠ Kết luận | ⚠ phát biểu đơn giản nhưng chính xác nhất |

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

  • A (Danny: cấp độ phải là chất lượng cao, nếu không sẽ có rủi ro) — ⚠ LẪN hai khái niệm: ⚠ cấp độ THẤP không đồng nghĩa với rủi ro; ⚠ vật liệu cấp thấp vẫn đạt chất lượng nếu đúng đặc tả.

  • C (Mark: chất lượng quyết định cấp độ) — ⚠ ĐẢO NGƯỢC quan hệ: ⚠ hai khái niệm ĐỘC LẬP, ⚠ không cái nào quyết định cái nào; ⚠ ngoài ra câu này còn tự mâu thuẫn trong cách diễn đạt.

  • B (Seth: cấp độ và việc lắp đặt hợp thành chất lượng dự án) — ⚠ SAI về định nghĩa: ⚠ chất lượng là mức ĐÁP ỨNG YÊU CẦU, ⚠ không phải tổng của cấp độ và tay nghề lắp đặt.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là câu THỨ BA trong bộ đề về cặp khái niệm quality/grade. ⚠ Bảng đối chiếu: | Câu | Lô | Cách hỏi | Khoá | |---|---|---|---| | ⚠ #25707 | ⚠ 180 | ⚠ đội cần "vật liệu chất lượng cao" — thật ra cần gì? | ⚠ high-GRADE materials | | ⚠ #25816 | ⚠ 181 | ⚠ điền vào câu châm ngôn "thấp ___ có thể ổn, thấp ___ luôn là vấn đề" | ⚠ GRADE, QUALITY | | ⚠ #25828 | ⚠ 181 | ⚠ phát biểu của ai đúng về grade | ⚠ Max — grade là thứ hạng | ⚠ Ba khoá đều đúng và NHẤT QUÁN với nhau. ⚠ Đây là chủ đề được hỏi nhiều nhất trong nhóm quản lý chất lượng của bộ đề này — nên thuộc kỹ.

⚠ Định nghĩa chuẩn: | Khái niệm | Định nghĩa PMBOK | |---|---| | ⚠ QUALITY | ⚠ mức độ mà tập hợp các đặc tính vốn có ĐÁP ỨNG YÊU CẦU | | ⚠ GRADE | ⚠ hạng được gán cho sản phẩm có CÙNG CÔNG DỤNG nhưng khác nhau về ĐẶC TÍNH KỸ THUẬT | | ⚠ Quan hệ | ⚠ ĐỘC LẬP — một sản phẩm có thể ở bất kỳ tổ hợp nào của hai trục |

⚠ Bốn tổ hợp — nhắc lại lần cuối: | Tổ hợp | Chấp nhận được không | |---|---| | ⚠ Quality CAO + Grade CAO | ⚠ tốt nhất, đắt nhất | | ⚠ Quality CAO + Grade THẤP | ⚠ CHẤP NHẬN ĐƯỢC | | ⚠ Quality THẤP + Grade CAO | ⚠ KHÔNG chấp nhận | | ⚠ Quality THẤP + Grade THẤP | ⚠ KHÔNG chấp nhận |

Từ khoá nhận diện:

"thứ hạng, phân loại vật liệu, mức tính năng" → ⚠ GRADE "đáp ứng yêu cầu, không khuyết tật" → ⚠ QUALITY "grade thấp thì có rủi ro" → ⚠ SAI, lẫn hai khái niệm "quality quyết định grade" → ⚠ SAI, hai trục độc lập

⚠ Ví dụ cụ thể trong dự án xây dựng Ví dụ
⚠ Gạch loại A và loại B ⚠ khác GRADE — cả hai đều có thể đạt chất lượng
⚠ Gạch loại A bị nứt ⚠ grade cao, quality thấp — KHÔNG chấp nhận
⚠ Gạch loại B đúng kích thước, không lỗi ⚠ grade thấp, quality cao — hoàn toàn ổn nếu đặc tả cho phép
⚠ Quyết định chọn grade ⚠ thuộc về khách hàng và ngân sách, không thuộc về đội thi công
⚠ Vì sao Danny nhầm lẫn là dễ hiểu Lý do
⚠ Trong đời thường "chất lượng cao" hay được dùng thay cho "hàng xịn"
⚠ Hai từ này thường bị dùng lẫn lộn trong giao tiếp hằng ngày
⚠ Trong PMBOK ⚠ chúng là hai khái niệm TÁCH BẠCH và đây là điểm được kiểm tra rất nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặc tả có ghi rõ GRADE yêu cầu không | | | Khi cắt chi phí, bạn cắt grade hay cắt quality | ⚠ chỉ vế đầu hợp lệ | | Đội có hiểu đúng hai khái niệm này không | ⚠ hiểu sai dẫn tới gold plating hoặc cắt chất lượng |

Và câu ngắn nhất tóm gọn cả chủ đề: grade là thứ bạn CHỌN, quality là thứ bạn PHẢI ĐẠT — Max nói đúng vì anh ấy giữ đúng ranh giới đó.

Câu 107 People
Tyler is new to the agile methodology and is writing his first agile charter. He can most likely expect to focus on
  1. A Acceptance criteria for the known user stories.
  2. B A high-level overview of how the project will be done, sufficient to get approval on the project's major attributes.
  3. C The required scope elements that cannot change during the project.
  4. D All known requirements for the project.
Xem giải thích

Đáp án

B — Một cái nhìn TỔNG QUAN Ở MỨC CAO về cách dự án sẽ được thực hiện, đủ để xin phê duyệt các thuộc tính chính của dự án.

Vì sao đúng

⚠ Đặc điểm của điều lệ trong dự án linh hoạt: | Đặc điểm | Nội dung | |---|---| | ⚠ Ở MỨC CAO, ngắn gọn | ⚠ thường chỉ một tới vài trang | | ⚠ Nêu VÌ SAO làm dự án và MỤC TIÊU là gì | | | ⚠ Không đi vào chi tiết yêu cầu | ⚠ chi tiết nằm trong backlog và sẽ làm rõ dần | | ⚠ Đủ để xin PHÊ DUYỆT và cấp nguồn lực | | | ⚠ Phù hợp với | ⚠ nguyên tắc chi tiết hoá tuần tự — chi tiết đến khi cần, không đến trước |

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

  • D (mọi yêu cầu đã biết của dự án) — ⚠ trái với tinh thần agile: ⚠ yêu cầu được làm rõ DẦN qua các vòng lặp; ⚠ ép liệt kê hết từ đầu là quay về cách dự đoán.

  • C (các thành phần phạm vi BẮT BUỘC không được thay đổi) — ⚠ trái ngược hoàn toàn: ⚠ agile coi thay đổi là bình thường và có giá trị.

  • A (tiêu chí chấp nhận cho các user story đã biết) — ⚠ quá CHI TIẾT cho một điều lệ; ⚠ tiêu chí chấp nhận thuộc về từng story trong backlog.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25695 ở lô 179 (mục đích của điều lệ là CHO PHÉP dự án tồn tại) và câu #25764 ở lô 180 (elevator statement). ⚠ Ba câu cùng chủ đề điều lệ dự án — câu này thêm góc nhìn agile.

⚠ Điều lệ trong dự án dự đoán và dự án linh hoạt: | Mục | Dự đoán | Linh hoạt | |---|---|---| | ⚠ Độ dài | ⚠ chi tiết hơn | ⚠ NGẮN, mức cao | | ⚠ Yêu cầu | ⚠ yêu cầu mức cao, khá rõ | ⚠ rất khái quát, chi tiết nằm ở backlog | | ⚠ Phạm vi | ⚠ ranh giới rõ ràng | ⚠ định hướng, chấp nhận điều chỉnh | | ⚠ Mục đích chung | ⚠ CHO PHÉP dự án tồn tại, bổ nhiệm PM | ⚠ GIỐNG NHAU | | ⚠ Điểm chung quan trọng | ⚠ cả hai đều do người có thẩm quyền BÊN NGOÀI dự án ban hành |

Từ khoá nhận diện:

"mức cao, đủ để xin phê duyệt" → ⚠ điều lệ agile "liệt kê mọi yêu cầu" → ⚠ trái tinh thần agile "phạm vi không được thay đổi" → ⚠ trái tinh thần agile "tiêu chí chấp nhận từng story" → ⚠ thuộc backlog, không thuộc điều lệ

⚠ Nội dung điển hình của điều lệ agile Nội dung
⚠ TẦM NHÌN sản phẩm ⚠ vì sao dự án này đáng làm
⚠ Mục tiêu kinh doanh và tiêu chí thành công
⚠ Ai là người dùng và họ cần gì ở mức khái quát
⚠ Đội và các vai trò chính ⚠ product owner, Scrum Master, thành viên
⚠ Ràng buộc lớn: ngân sách, thời gian, công nghệ
⚠ Rủi ro tổng thể
⚠ Cách làm việc dự kiến ⚠ độ dài vòng lặp, cách ra quyết định
⚠ KHÔNG có ⚠ danh sách yêu cầu chi tiết, tiêu chí chấp nhận từng story, lịch chi tiết
⚠ Vì sao điều lệ agile lại NGẮN Lý do
⚠ Viết khi biết rất ít thông tin
⚠ Chi tiết sẽ lỗi thời rất nhanh
⚠ Chi tiết hoá tuần tự là nguyên tắc nền ⚠ xem câu #25671 ở lô 178
⚠ Tài liệu dài mà không ai đọc là lãng phí ⚠ "phần mềm chạy được hơn tài liệu đầy đủ"
⚠ Nhưng ⚠ NGẮN không có nghĩa là SƠ SÀI — vẫn phải đủ để người phê duyệt quyết định được
⚠ Lời khuyên cho Tyler Lời khuyên
⚠ Tập trung vào VÌ SAO và MỤC TIÊU, không vào CÁI GÌ chi tiết
⚠ Viết đủ để nhà tài trợ nói "được, làm đi"
⚠ Để phần chi tiết cho backlog
⚠ Dùng elevator statement để mở đầu ⚠ xem câu #25764
⚠ Xây điều lệ CÙNG với đội và bên liên quan ⚠ quá trình xây quan trọng không kém sản phẩm cuối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Điều lệ của bạn có đủ để xin phê duyệt không | | | Có chi tiết nào sẽ lỗi thời trong một tháng không | ⚠ nếu có thì nên chuyển sang backlog | | Đội có hiểu VÌ SAO dự án tồn tại sau khi đọc không | |

Và tiêu chí đơn giản để biết điều lệ agile đã đủ chưa: nó có trả lời được câu hỏi "vì sao chúng ta làm việc này và thành công trông như thế nào" không. Nếu có thì đủ; mọi chi tiết khác thuộc về backlog.

Câu 108 People
Daniel is the project manager for a marketing company. Daniel has been tasked with a project to produce a promotional video to sell more of their products. Sydney is a team member on Daniel's team who specializes in video editing. However, Sydney is not very confident in her abilities and is hesitant to express her ideas to the team. What should Daniel do to encourage Sydney to contribute her ideas to the team?
  1. A Recommend having Sydney replaced with a more confident team member.
  2. B Attempt to edit their training video without Sydney's input.
  3. C Ask Sydney her thoughts on decisions relating to video editing.
  4. D Have Sydney make all the final decisions on video editing before implementing them.
Xem giải thích

Đáp án

C — HỎI Ý KIẾN Sydney về các quyết định liên quan tới dựng phim.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Sydney là CHUYÊN GIA về dựng phim | ⚠ đề nói rõ cô ấy chuyên về mảng này | | ⚠ Hỏi ý kiến trong lĩnh vực cô ấy MẠNH NHẤT | ⚠ nơi cô ấy tự tin nhất để bắt đầu | | ⚠ CHỦ ĐỘNG mời đóng góp thay vì đợi cô ấy tự nói | ⚠ người thiếu tự tin ít khi chủ động | | ⚠ Xây dựng sự tự tin DẦN qua từng lần được lắng nghe | | | ⚠ Kết luận | ⚠ tạo cơ hội an toàn để cô ấy đóng góp, thay vì ép hoặc bỏ mặc |

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

  • D (để Sydney tự quyết TẤT CẢ về dựng phim trước khi thực hiện) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe như trao quyền, ⚠ nhưng ĐẨY người thiếu tự tin vào áp lực quá lớn; ⚠ và ⚠ PM không nên từ bỏ trách nhiệm ra quyết định cuối cùng.

  • A (đề nghị thay Sydney bằng người tự tin hơn) — ⚠ loại bỏ người vì tính cách, ⚠ và mất luôn chuyên môn cô ấy có; ⚠ loại người gần như luôn là đáp án SAI.

  • B (cố dựng video mà không cần ý kiến của Sydney) — ⚠ BỎ QUA chuyên gia duy nhất về mảng này; ⚠ chắc chắn làm chất lượng kém đi.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25826 CÙNG LÔ ⚠ (thành viên ít nói trong standup). ⚠ Hai câu ⚠ cùng tình huống thành viên không chủ động đóng góp, ⚠ và hai khoá ⚠ BỔ SUNG nhau chứ không mâu thuẫn: | Câu | Tình huống | Khoá | Logic | |---|---|---|---| | ⚠ #25826 | ⚠ chưa biết vì sao người đó ít nói | ⚠ nói chuyện RIÊNG để tìm hiểu | ⚠ THU THẬP THÔNG TIN trước | | ⚠ #25830 | ⚠ ĐÃ BIẾT lý do: thiếu tự tin | ⚠ HỎI Ý KIẾN chuyên môn | ⚠ HÀNH ĐỘNG khi đã biết nguyên nhân | ⚠ Cách phân biệt: nếu đề CHƯA nêu nguyên nhân thì tìm hiểu trước; nếu đề ĐÃ nêu nguyên nhân thì hành động phù hợp với nguyên nhân đó. ⚠ Và câu #25743 ở lô 180 là câu thứ ba cùng chủ đề.

⚠ Cách xây dựng sự tự tin cho thành viên đội: | Cách | Nội dung | |---|---| | ⚠ Bắt đầu từ lĩnh vực họ MẠNH NHẤT | ⚠ cách của câu này | | ⚠ Hỏi TRỰC TIẾP thay vì chờ họ giơ tay | | | ⚠ GHI NHẬN công khai khi ý kiến của họ được dùng | | | ⚠ Cho thời gian chuẩn bị trước buổi họp | ⚠ gửi câu hỏi trước | | ⚠ Bảo vệ ý kiến của họ khi bị người khác lấn át | | | ⚠ Giao dần trách nhiệm lớn hơn khi họ sẵn sàng | ⚠ KHÔNG nhảy thẳng lên "quyết tất cả" | | ⚠ Nguyên tắc | ⚠ tăng dần, không ép |

Từ khoá nhận diện:

"thiếu tự tin nhưng có chuyên môn" → ⚠ hỏi ý kiến trong lĩnh vực họ mạnh "để họ quyết tất cả" → ⚠ áp lực quá lớn, và PM bỏ trách nhiệm "thay người tự tin hơn" → ⚠ loại người, luôn sai "làm mà không cần họ" → ⚠ bỏ phí chuyên môn

⚠ Vì sao phương án D nghe hay mà lại sai Lý do
⚠ Trao quyền là tốt, nhưng phải ĐÚNG LIỀU
⚠ Người thiếu tự tin cần bước nhỏ, không phải bước nhảy
⚠ "Quyết TẤT CẢ" có thể khiến cô ấy càng lo lắng
⚠ PM vẫn chịu trách nhiệm cuối cùng về dự án ⚠ accountability không uỷ thác được — xem câu #25614 ở lô 177
⚠ Cách đúng ⚠ hỏi ý kiến → dùng ý kiến → ghi nhận → giao dần trách nhiệm lớn hơn
⚠ Liên hệ với lãnh đạo phục vụ Liên hệ
⚠ Servant leader tạo điều kiện để đội phát huy
⚠ Không ra lệnh, cũng không bỏ mặc
⚠ Gỡ trở ngại — ở đây trở ngại là sự thiếu tự tin
⚠ Xem thêm ⚠ câu #25732 ở lô 179 và #25806 ở lô này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có chủ động hỏi ý kiến từng người không | ⚠ hay chỉ nghe ai nói to nhất | | Ý kiến của người ít nói có được dùng không | ⚠ hỏi mà không dùng thì lần sau họ không nói nữa | | Bạn đang tăng dần trách nhiệm hay đang ép | |

Và cách đơn giản nhất để một người thiếu tự tin bắt đầu lên tiếng: hỏi họ đúng câu hỏi mà họ biết câu trả lời rõ hơn ai hết. Với Sydney, đó là câu hỏi về dựng phim.

Câu 109 People
Joel, a young, enthusiastic employee, recently transferred to one of his company's satellite offices in Japan. During Joel's first meeting with his new team, a project manager introduces Joel and quickly transitions to a discussion about the project's status to date, noting that they have a supply chain issue and beginning an in-depth presentation about it. Eager to contribute, Joel shares with the group that his former office encountered the same issue and gives an overview of how they solved it. The project manager thanks Joel for his contribution and continues the presentation. One week later, Joel realizes that he has not been invited to an important meeting with the team. What is the source of the conflict?
  1. A Team environment
  2. B Cultural differences
  3. C Personality
  4. D Project priorities
Xem giải thích

Đáp án

B — Cultural differences (khác biệt văn hoá).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Joel vừa chuyển sang văn phòng ở NHẬT BẢN | ⚠ bối cảnh đa văn hoá được nêu rõ ràng | | ⚠ Joel NGẮT NGANG bài trình bày để đóng góp | ⚠ hành vi được coi là năng động ở nhiều nơi phương Tây | | ⚠ Quản lý dự án cảm ơn rồi TIẾP TỤC bài trình bày | ⚠ phản ứng lịch sự nhưng không tiếp nhận ngay | | ⚠ Joel là người MỚI, TRẺ, và rất hăng hái | | | ⚠ Kết luận | ⚠ đây là va chạm về CHUẨN MỰC GIAO TIẾP giữa hai nền văn hoá |

⚠ Vài chuẩn mực khác biệt cần biết: | Chuẩn mực | Nội dung | |---|---| | ⚠ Nhiều nền văn hoá Đông Á coi trọng THỨ BẬC và THÂM NIÊN | ⚠ người mới thường quan sát trước, phát biểu sau | | ⚠ Ngắt lời trong buổi trình bày có thể bị coi là thiếu tôn trọng | | | ⚠ Ý kiến thường được trao đổi RIÊNG trước, rồi mới nêu trong họp | ⚠ nemawashi — vận động đồng thuận trước | | ⚠ Giao tiếp thiên về NGỮ CẢNH CAO | ⚠ nhiều điều được hiểu ngầm, không nói thẳng | | ⚠ Vì thế | ⚠ lời cảm ơn rồi tiếp tục có thể là cách từ chối lịch sự, hoặc đơn giản là "để bàn sau" |

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

  • A (Team environment — môi trường đội) — ⚠ quá chung chung; ⚠ đề nhấn mạnh bối cảnh CHUYỂN SANG NƯỚC KHÁC, không nói về không khí đội.

  • C (Personality — tính cách) — ⚠ có thể là một phần, ⚠ nhưng đề đặt trọng tâm ở việc chuyển văn phòng sang quốc gia khác.

  • D (Project priorities — ưu tiên dự án) — ⚠ không liên quan; ⚠ vấn đề nằm ở cách giao tiếp, không ở thứ tự ưu tiên.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25740 ở lô 180 về yếu tố ảnh hưởng giao tiếp trong dự án đa quốc gia và câu #25787 ở lô này về rủi ro niềm tin trong đội phân tán. ⚠ Ba câu cùng chủ đề làm việc xuyên văn hoá.

⚠ Các chiều khác biệt văn hoá ảnh hưởng tới dự án: | Chiều | Nội dung | |---|---| | ⚠ Khoảng cách quyền lực | ⚠ mức chấp nhận thứ bậc và việc chất vấn cấp trên | | ⚠ Cá nhân so với tập thể | ⚠ đề cao thành tích cá nhân hay hài hoà nhóm | | ⚠ Ngữ cảnh cao so với ngữ cảnh thấp | ⚠ nói ngầm hay nói thẳng | | ⚠ Thái độ với thời gian | ⚠ đúng giờ tuyệt đối hay linh hoạt | | ⚠ Tránh né bất định | ⚠ mức thoải mái với sự mơ hồ | | ⚠ Không có nền văn hoá nào ĐÚNG hay SAI | ⚠ chỉ khác nhau — và phải hiểu để làm việc được |

Từ khoá nhận diện:

"chuyển sang văn phòng ở nước khác" → ⚠ khác biệt văn hoá "đóng góp bị đón nhận lạnh nhạt" → ⚠ có thể do chuẩn mực giao tiếp khác "đội phân tán nhiều quốc gia" → ⚠ yếu tố ảnh hưởng giao tiếp "tính cách cá nhân" → ⚠ DISC, MBTI — khác với văn hoá

⚠ Joel nên làm gì Việc
⚠ QUAN SÁT cách đồng nghiệp trao đổi trước khi bắt chước
⚠ Trao đổi ý kiến RIÊNG với quản lý dự án trước buổi họp
⚠ Hỏi thẳng một đồng nghiệp thân thiện về chuẩn mực nơi đây
⚠ Kiên nhẫn — sự tôn trọng cần thời gian xây dựng
⚠ Đừng kết luận là mình bị gạt bỏ ⚠ lời cảm ơn có thể là thật, chỉ là cách thể hiện khác
⚠ Quản lý dự án nên làm gì Việc
⚠ Gặp riêng Joel để giải thích chuẩn mực giao tiếp của đội
⚠ Tạo kênh cho Joel đóng góp mà không phá vỡ chuẩn mực ⚠ ví dụ mời anh ấy trình bày ở buổi riêng
⚠ Đưa nội dung về khác biệt văn hoá vào hiến chương đội
⚠ Không để kinh nghiệm của Joel bị lãng phí ⚠ anh ấy có giải pháp thật cho vấn đề chuỗi cung ứng
⚠ Nhớ rằng ⚠ PMBOK coi ĐA DẠNG VĂN HOÁ là nguồn sức mạnh nếu được quản lý tốt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có thành viên từ nhiều nền văn hoá không | | | Chuẩn mực giao tiếp có được nói rõ với người mới không | | | Ý kiến của người mới có được ghi nhận theo cách phù hợp không | |

Và điều dễ hiểu nhầm nhất khi làm việc xuyên văn hoá: một phản ứng lạnh nhạt không nhất thiết là sự từ chối. Ở nhiều nơi, "cảm ơn rồi tiếp tục" chỉ có nghĩa là "chúng ta sẽ bàn riêng chuyện này".

Câu 110 Process
Heather’s team has determined that their software would benefit from a few customers reviewing the user story and agreeing that it is finished. Her team is most likely doing this because
  1. A They have a software that every user will like.
  2. B The team has agreed that ‘tested’ is the definition of done.
  3. C Customers are involved in their retrospectives.
  4. D The team has agreed that ‘accepted’ is the definition of done.
Xem giải thích

Đáp án

D — Đội đã thống nhất rằng "ĐƯỢC CHẤP NHẬN" là định nghĩa của DONE.

Vì sao đúng

⚠ Bóc tách tình huống: | Chi tiết | Suy ra | |---|---| | ⚠ Vài KHÁCH HÀNG xem lại user story | ⚠ người ngoài đội tham gia đánh giá | | ⚠ Và ĐỒNG Ý rằng nó đã hoàn thành | ⚠ sự chấp nhận CHÍNH THỨC | | ⚠ Đây là điều kiện để coi story là xong | | | ⚠ Kết luận | ⚠ định nghĩa DONE của đội bao gồm cả bước KHÁCH HÀNG CHẤP NHẬN, không dừng ở "đã kiểm thử" |

⚠ Thang mức độ "xong" mà các đội hay dùng: | Mức | Nội dung | |---|---| | ⚠ Coded | ⚠ đã viết xong mã | | ⚠ Reviewed | ⚠ đã rà soát mã | | ⚠ TESTED | ⚠ đã kiểm thử — mức nhiều đội dừng lại | | ⚠ Integrated | ⚠ đã tích hợp vào sản phẩm | | ⚠ ACCEPTED | ⚠ KHÁCH HÀNG hoặc product owner chấp nhận — MỨC CỦA CÂU NÀY | | ⚠ Deployed | ⚠ đã triển khai tới người dùng | | ⚠ Đội càng đặt DONE ở mức CAO | ⚠ càng ít rủi ro có việc "xong rồi lại phải làm lại" |

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

  • B (đội đã thống nhất "đã kiểm thử" là định nghĩa DONE) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nếu DONE chỉ là "đã kiểm thử" thì ⚠ KHÔNG cần khách hàng xem lại và đồng ý; ⚠ chính bước khách hàng chấp nhận cho thấy DONE ở mức cao hơn.

  • C (khách hàng tham gia buổi retrospective) — ⚠ retrospective bàn về CÁCH LÀM VIỆC của đội, ⚠ không phải nơi nghiệm thu story; ⚠ và thường chỉ có đội tham dự.

  • A (họ có phần mềm mà mọi người dùng đều thích) — ⚠ kết luận vô căn cứ; ⚠ vài khách hàng đồng ý không có nghĩa mọi người dùng đều thích.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25790 ở lô này về story "done-done", câu #25786 về định nghĩa DONE chưa đủ chặt gây lãng phí, và câu #25750 ở lô 180 về sprint review. ⚠ Bốn câu cùng chủ đề DONE — chủ đề được hỏi nhiều nhất về agile trong bộ đề này.

⚠ Definition of Done — những điều cần thuộc: | Điều | Nội dung | |---|---| | ⚠ Là bộ tiêu chí CHUNG cho MỌI hạng mục | | | ⚠ Do ĐỘI và product owner cùng thống nhất | | | ⚠ Áp dụng nhất quán, không đàm phán từng story | | | ⚠ Có thể NÂNG DẦN theo thời gian | ⚠ đội trưởng thành thì DoD chặt hơn | | ⚠ Là một trong ba CAM KẾT của Scrum | ⚠ gắn với hiện vật Increment | | ⚠ Thiếu DoD rõ ràng | ⚠ "xong" trở thành khái niệm mỗi người hiểu một kiểu |

⚠ Phân biệt Definition of Done và Acceptance Criteria: | Mục | Definition of Done | Acceptance Criteria | |---|---|---| | ⚠ Phạm vi | ⚠ CHUNG cho mọi story | ⚠ RIÊNG cho từng story | | ⚠ Nội dung | ⚠ chuẩn chất lượng của đội | ⚠ story này phải làm được gì | | ⚠ Ai đặt ra | ⚠ đội + product owner | ⚠ product owner, với đầu vào từ đội | | ⚠ Một story xong khi | ⚠ đạt CẢ HAI |

Từ khoá nhận diện:

"khách hàng xem và đồng ý là xong" → ⚠ DONE ở mức ACCEPTED "đã kiểm thử là xong" → ⚠ DONE ở mức TESTED — thấp hơn "tiêu chí riêng của từng story" → ⚠ acceptance criteria "nhìn lại cách làm việc" → ⚠ retrospective, không phải nghiệm thu

⚠ Lợi ích khi đặt DONE ở mức "được chấp nhận" Lợi ích
⚠ Không có việc "xong rồi lại phải sửa"
⚠ Phản hồi khách hàng đến SỚM
⚠ Giảm rủi ro làm sai thứ khách cần
⚠ Velocity phản ánh GIÁ TRỊ THẬT được giao ⚠ không phải khối lượng công việc đã làm
⚠ Cái giá ⚠ cần khách hàng SẴN SÀNG tham gia đều đặn — không phải lúc nào cũng có
⚠ Rủi ro nếu DONE quá THẤP Rủi ro
⚠ Nợ kỹ thuật tích tụ
⚠ Increment không thật sự bàn giao được
⚠ Velocity ảo — điểm được tính cho việc chưa hoàn thiện
⚠ Liên hệ ⚠ xem câu #25786 — quy trình của Emily đánh dấu "hoàn thành" TRƯỚC khi kiểm thử, đó là DoD quá thấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Định nghĩa DONE của đội bạn dừng ở mức nào | | | Có ai ngoài đội xác nhận trước khi tính là xong không | | | DoD có được nâng dần theo thời gian không | |

Và câu hỏi kiểm tra sức khoẻ của một đội agile: "xong" của các bạn nghĩa là gì?. Nếu mỗi người trả lời một kiểu thì mọi con số tiến độ đều không đáng tin.