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

Tìm thấy 720 câu.

Câu 241 People
Benji is a project manager for a scrum project that is also using a Kanban board. During the last retrospective, the team agreed on a new process for taking work items from the in-queue column of the Kanban board and moving them into production. Today, Benji overheard a developer arguing with the product manager about the sprint backlog and how to determine which work item should be picked up next. What should Benji do?
  1. A Privately reprimand the developer for not following the process decided during the retrospective.
  2. B Interrupt the argument and decide which task should be next.
  3. C Do nothing. The team recently reviewed how to move items from the Kanban queue into production.
  4. D Intervene and speak with both sides to determine the source of the conflict.
Xem giải thích

Đáp án

D — CAN THIỆP và trao đổi với CẢ HAI BÊN để xác định NGUỒN GỐC của xung đột.

Vì sao đúng

⚠ Vì sao tình huống này cần can thiệp: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Đội VỪA THỐNG NHẤT quy trình mới ở retrospective | ⚠ mà giờ đã cãi nhau về đúng chuyện đó | | ⚠ Tranh cãi giữa LẬP TRÌNH VIÊN và PRODUCT MANAGER | ⚠ hai VAI khác nhau — không phải bất đồng nội bộ đội | | ⚠ Nội dung: sprint backlog và thứ tự lấy việc | ⚠ chạm vào ranh giới thẩm quyền giữa hai vai | | ⚠ Quy trình vừa thống nhất đã không được tuân theo | ⚠ dấu hiệu quy trình đó CHƯA THỰC SỰ được hiểu hoặc chưa phù hợp | | ⚠ Vì sao phải tìm NGUỒN GỐC | ⚠ triệu chứng là cuộc cãi nhau, nguyên nhân có thể là quy trình mơ hồ hoặc thẩm quyền chưa rõ |

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

  • C (không làm gì, đội vừa rà lại cách chuyển việc từ hàng đợi Kanban vào sản xuất) — ⚠ phương án gây nhiễu mạnh nhất vì lý do nghe rất hợp lý: ⚠ nhưng ⚠ chính việc "vừa thống nhất mà vẫn cãi nhau" mới là bằng chứng cần can thiệp; ⚠ nếu quy trình đã đủ rõ thì đã không có tranh cãi.

  • B (cắt ngang cuộc tranh cãi và tự quyết việc nào làm tiếp) — ⚠ quyết thay đội và thay product manager; ⚠ giải quyết triệu chứng, ⚠ không chạm tới nguyên nhân, ⚠ và làm giảm tính tự tổ chức.

  • A (khiển trách riêng lập trình viên vì không theo quy trình) — ⚠ kết luận sớm rằng lập trình viên sai; ⚠ Benji mới chỉ NGHE LỎM, chưa biết ai đúng ai sai; ⚠ và ⚠ có thể chính quy trình mới là thứ có vấn đề.

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

⚠ Đây là câu thứ BA về xử lý xung đột trong CÙNG MỘT LÔ, và cả ba có khoá đáp án KHÁC NHAU: | Câu | Tình huống | Khoá | Vì sao khác | |---|---|---|---| | ⚠ #25937 (Terry) | ⚠ đội bất đồng, giai đoạn SỚM, có yếu tố an toàn tâm lý | ⚠ TRAO QUYỀN cho đội tự giải quyết | ⚠ chưa leo thang, không có dữ kiện phân xử | | ⚠ #25945 (Oscar) | ⚠ hai lập trình viên cãi về CÁCH LÀM một việc kỹ thuật | ⚠ chỉ tới TÀI LIỆU công việc | ⚠ có dữ kiện khách quan phân xử được | | ⚠ #25963 (Benji) | ⚠ tranh cãi GIỮA HAI VAI, vi phạm quy trình vừa thống nhất | ⚠ CAN THIỆP, tìm nguồn gốc | ⚠ đã leo thang, và có dấu hiệu vấn đề hệ thống | ⚠ Ba khoá KHÔNG mâu thuẫn — chúng minh hoạ đúng NGUYÊN TẮC TƯƠNG XỨNG: mức can thiệp phải khớp với mức nghiêm trọng của xung đột. ⚠ Giữ nguyên cả ba khoá. ⚠ Điểm chung của cả ba: người dẫn dắt LUÔN LÀM GÌ ĐÓ, và KHÔNG BAO GIỜ tự quyết thay khi có thể tránh.

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à bộ năm chiến lược xung đột ở lô 177–182.

⚠ Vì sao phải nói với CẢ HAI bên: | Lý do | Nội dung | |---|---| | ⚠ Nghe lỏm chỉ cho một góc nhìn méo mó | | | ⚠ Mỗi bên thường có phần đúng | | | ⚠ Tránh tạo cảm giác thiên vị | ⚠ hại lâu dài lớn nhất nếu làm sai | | ⚠ Nguồn gốc thật thường nằm ở chỗ không ai nói ra | ⚠ thẩm quyền không rõ, áp lực từ bên ngoài, quy trình mâu thuẫn | | ⚠ Cách làm | ⚠ nói RIÊNG với từng bên trước, rồi mới ngồi chung nếu cần |

Từ khoá nhận diện:

"vừa thống nhất quy trình mà vẫn cãi nhau" → ⚠ quy trình có vấn đề, phải can thiệp "không làm gì vì vừa rà lại rồi" → ⚠ bỏ qua bằng chứng ngược lại "tự quyết thay" → ⚠ giải quyết triệu chứng "khiển trách một bên" → ⚠ kết luận trước khi có đủ thông tin

⚠ Nguồn gốc có thể của xung đột này Nguồn gốc
⚠ Quy trình mới viết chưa rõ, hiểu được hai kiểu
⚠ Không rõ AI quyết thứ tự lấy việc ⚠ product manager hay đội tự kéo
⚠ Trộn hai khung Scrum và Kanban chưa nhất quán ⚠ sprint backlog cố định, còn Kanban thì kéo liên tục — hai logic khác nhau
⚠ Áp lực bên ngoài lên product manager
⚠ Điểm đáng chú ý nhất ⚠ dùng Scrum và Kanban cùng lúc rất dễ sinh mâu thuẫn kiểu này nếu không nói rõ hạng mục nào theo luật nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy trình đội bạn thống nhất ở retrospective có được viết ra không | ⚠ thống nhất miệng thì tuần sau mỗi người nhớ một kiểu | | Ai quyết thứ tự công việc trong đội bạn | | | Nếu trộn Scrum và Kanban, luật nào thắng khi mâu thuẫn | |

Và điều Benji nên nhận ra: một quy trình vừa được cả đội đồng ý mà đã bị vi phạm ngay hôm sau thường không phải vì ai đó bướng bỉnh — mà vì nó chưa bao giờ thật sự rõ ràng.

Câu 242 Process
Devin has just completed a project to deliver emergency medical services to community members affected by a significant natural disaster. All of these services were conducted using the company's resources. Devin is working through the administrative closure portion of a project and wants to document some lessons learned in case another disaster occurs in the future. Which of the following considerations would not be relevant in this scenario?
  1. A Relevant scheduling problems or issues.
  2. B Issues that arose within the team or between the team and customers.
  3. C Sellers lessons learned.
  4. D Strategic lessons learned that impacted the organization's project management methodology.
Xem giải thích

Đáp án

C — BÀI HỌC VỀ NHÀ CUNG CẤP (sellers lessons learned) — đây là mục KHÔNG liên quan.

Vì sao đúng

⚠ Đọc kỹ chi tiết quyết định: | Chi tiết | Ý nghĩa | |---|---| | ⚠ "TẤT CẢ dịch vụ được thực hiện bằng NGUỒN LỰC CỦA CHÍNH CÔNG TY" | ⚠ KHÔNG có nhà cung cấp nào tham gia | | ⚠ Không có mua sắm thì không có bài học về nhà cung cấp | ⚠ không có gì để ghi | | ⚠ Ba phương án còn lại đều áp dụng được | | | ⚠ Bẫy của câu | ⚠ "bài học về nhà cung cấp" nghe rất hợp lý trong danh sách bài học — chỉ MỘT CÂU trong đề loại nó ra | | ⚠ Kỹ năng cần | ⚠ đọc kỹ mọi mệnh đề, kể cả mệnh đề nghe như thông tin nền |

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

  • D (bài học chiến lược ảnh hưởng tới phương pháp quản lý dự án của tổ chức) — ⚠ phương án gây nhiễu mạnh nhất vì nghe "cao siêu" và xa với một dự án cứu trợ: ⚠ nhưng ⚠ đây chính là loại bài học GIÁ TRỊ NHẤT ⚠ — dự án ứng phó thảm hoạ dạy tổ chức cách huy động nhanh, và điều đó phải đi vào phương pháp luận.

  • A (vấn đề về lập lịch) — ⚠ luôn có trong mọi dự án, ⚠ đặc biệt trong dự án khẩn cấp.

  • B (vấn đề trong đội hoặc giữa đội với khách hàng) — ⚠ rất liên quan; ⚠ dự án cứu trợ có áp lực cảm xúc cao, ⚠ bài học về con người là quan trọng nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25911 ở lô 183 (báo cáo bài học cho họp tổng kết), câu #25909 (Milly đóng dự án), câu #25927 (hoạt động của giai đoạn đóng), và câu #25896 (chuyển giao tri thức khó hơn dự tính). ⚠ Bài học kinh nghiệm đã được hỏi tới NĂM lần qua hai lô — chủ đề dày thứ hai sau giao tiếp.

⚠ Bài học kinh nghiệm nên bao phủ những mảng nào: | Mảng | Ghi gì | |---|---| | ⚠ LỊCH TRÌNH | ⚠ ước lượng lệch ở đâu, vì sao | | ⚠ CHI PHÍ | ⚠ khoản nào vượt, khoản nào dư | | ⚠ PHẠM VI | ⚠ thay đổi nào phát sinh và vì sao | | ⚠ CHẤT LƯỢNG | ⚠ lỗi hay gặp, cách phát hiện sớm hơn | | ⚠ CON NGƯỜI | ⚠ xung đột, giao tiếp, động lực | | ⚠ RỦI RO | ⚠ rủi ro nào đã nhận diện, rủi ro nào bất ngờ | | ⚠ MUA SẮM | ⚠ hiệu quả của nhà cung cấp — KHÔNG áp dụng ở đây | | ⚠ CHIẾN LƯỢC | ⚠ điều gì nên đổi trong phương pháp luận của tổ chức | | ⚠ Nguyên tắc | ⚠ chỉ ghi mảng nào THỰC SỰ có trong dự án — ghi mục trống chỉ làm loãng tài liệu |

Từ khoá nhận diện:

"toàn bộ bằng nguồn lực nội bộ" → ⚠ KHÔNG có bài học về nhà cung cấp "đóng hành chính" → ⚠ giai đoạn kết thúc dự án ⚠ Câu có chữ "KHÔNG / EXCEPT" → ⚠ tìm mệnh đề trong đề loại nó ra "bài học chiến lược" → ⚠ loại có giá trị nhất, không phải loại thừa

⚠ Vì sao dự án ứng phó thảm hoạ đặc biệt cần bài học Lý do
⚠ Sẽ có thảm hoạ khác, và thời gian chuẩn bị bằng KHÔNG
⚠ Quyết định phải ra rất nhanh, không có thời gian nghiên cứu lại
⚠ Đội có thể hoàn toàn khác ở lần sau ⚠ tri thức phải ở TÀI LIỆU, không ở trong đầu người
⚠ Sai sót có cái giá là sinh mạng
⚠ Việc Devin đang làm ⚠ đúng và quan trọng hơn nhiều so với một dự án thông thường
⚠ Bài học tốt khác bài học vô dụng ở đâu Phân biệt
⚠ CỤ THỂ, không chung chung ⚠ "cần huy động xe cứu thương trong 4 giờ đầu" chứ không phải "cần phối hợp tốt hơn"
⚠ Có BỐI CẢNH để người sau biết khi nào áp dụng
⚠ Có KHUYẾN NGHỊ hành động, không chỉ mô tả sự việc
⚠ Nằm ở nơi TÌM ĐƯỢC ⚠ kho bài học của tổ chức, không phải ổ đĩa cá nhân
⚠ Kiểm tra nhanh ⚠ người chưa từng làm dự án này đọc có hiểu và dùng được không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bài học của bạn có ghi cả cái LÀM TỐT không | ⚠ không chỉ ghi cái sai | | Có ai đọc bài học của dự án trước khi bắt đầu dự án mới không | | | Bài học có được viết thành THAY ĐỔI trong quy trình không | ⚠ nếu không, nó chỉ là một tài liệu nữa |

Và điều đáng suy nghĩ nhất về việc Devin đang làm: anh viết bài học cho một trận thảm hoạ chưa xảy ra, cho một đội chưa tồn tại. Đó chính là lý do bài học kinh nghiệm là phần dễ bỏ qua nhất và cũng có giá trị nhất của giai đoạn đóng.

Câu 243 Process
Brooke's project team is well underway in the development of a complex technical project. A team member informs Brooke that a functional manager receives the weekly status report but not the monthly progress report. He expressed that he must receive the monthly progress report. What should Brooke do next?
  1. A Brooke should update the communications management plan to include sending the monthly progress report.
  2. B Brooke should send the monthly progress report to all stakeholders and team members.
  3. C Nothing; The stakeholder does not need to receive the monthly progress report because he is receiving the weekly status report.
  4. D Brooke should note this in the issue log and send the monthly progress report to this stakeholder.
Xem giải thích

Đáp án

A — Brooke nên CẬP NHẬT KẾ HOẠCH QUẢN LÝ GIAO TIẾP để bổ sung việc gửi báo cáo tiến độ hằng tháng.

Vì sao đúng

⚠ Vì sao phải sửa kế hoạch chứ không chỉ gửi báo cáo: | Lý do | Nội dung | |---|---| | ⚠ Đây là LỖ HỔNG trong kế hoạch giao tiếp | ⚠ một bên liên quan cần báo cáo mà kế hoạch không ghi | | ⚠ Chỉ gửi một lần thì lần sau lại quên | ⚠ sửa triệu chứng, không sửa nguyên nhân | | ⚠ Kế hoạch giao tiếp là tài liệu SỐNG | ⚠ phải cập nhật khi nhu cầu thay đổi | | ⚠ Cập nhật rồi thì việc gửi tự động diễn ra theo kế hoạch | | | ⚠ Lưu ý | ⚠ cập nhật kế hoạch KHÔNG loại trừ việc gửi ngay báo cáo cho người đó — nhưng câu hỏi hỏi hành động ĐÚNG NHẤT về mặt quy trình |

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

  • D (ghi vào nhật ký vấn đề và gửi báo cáo cho bên liên quan đó) — ⚠ phương án gây nhiễu mạnh nhất vì nó CÓ hành động và CÓ ghi chép: ⚠ nhưng ⚠ nhật ký vấn đề dành cho VẤN ĐỀ cần theo dõi và xử lý, ⚠ còn đây là ⚠ thiếu sót trong kế hoạch cần SỬA KẾ HOẠCH; ⚠ ghi vào nhật ký vấn đề rồi gửi một lần thì kế hoạch vẫn sai.

  • B (gửi báo cáo hằng tháng cho TẤT CẢ bên liên quan và thành viên đội) — ⚠ giao tiếp thừa cũng có hại: ⚠ gửi cho người không cần sẽ khiến họ ngừng đọc mọi thứ bạn gửi.

  • C (không làm gì, đã nhận báo cáo tuần thì không cần báo cáo tháng) — ⚠ tự quyết hộ bên liên quan; ⚠ hai loại báo cáo có mục đích khác nhau.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25949 ở lô này (hỏi Jessie muốn nhận tin thế nào), câu #25961 (Ethel chưa gắn kết bên liên quan), câu #25942 (ràng buộc giao tiếp), và câu #25948 (mô hình mã hoá-giải mã). ⚠ Giao tiếp là chủ đề dày nhất của lô này với SÁU câu.

⚠ Kế hoạch quản lý giao tiếp phải trả lời: | Câu hỏi | Nội dung | |---|---| | ⚠ AI cần thông tin | ⚠ từng bên liên quan | | ⚠ CẦN thông tin gì | ⚠ loại báo cáo, mức chi tiết | | ⚠ KHI NÀO và BAO LÂU một lần | ⚠ tuần, tháng, theo mốc | | ⚠ QUA KÊNH nào | ⚠ email, họp, bảng thông tin | | ⚠ AI chịu trách nhiệm gửi | | | ⚠ Định dạng và ngôn ngữ | ⚠ quan trọng với dự án đa quốc gia — liên hệ #25942 | | ⚠ Thiếu một dòng | ⚠ là có một người không nhận được thứ họ cần, đúng như tình huống này |

Từ khoá nhận diện:

"bên liên quan thiếu một loại báo cáo" → ⚠ cập nhật kế hoạch giao tiếp "gửi cho tất cả mọi người" → ⚠ giao tiếp thừa, cũng là vấn đề "nhật ký vấn đề" → ⚠ cho VẤN ĐỀ, không cho thiếu sót kế hoạch "không cần vì đã có báo cáo khác" → ⚠ tự quyết hộ người khác

⚠ Báo cáo tuần và báo cáo tháng khác nhau thế nào Khác biệt
⚠ BÁO CÁO TUẦN ⚠ chi tiết vận hành: việc đã làm, việc sắp làm, vướng mắc
⚠ BÁO CÁO THÁNG ⚠ tổng hợp xu hướng: tiến độ so với đường cơ sở, chi phí, rủi ro lớn
⚠ Đối tượng khác nhau ⚠ tuần cho người theo sát, tháng cho người cần bức tranh tổng thể
⚠ Quản lý chức năng cần cả hai ⚠ anh ta có người trong đội (cần báo cáo tuần) và cần biết xu hướng chung (cần báo cáo tháng)
⚠ Vì sao giao tiếp THỪA cũng có hại Lý do
⚠ Người nhận quá tải sẽ ngừng đọc TẤT CẢ ⚠ kể cả thứ quan trọng
⚠ Thông tin nhạy cảm lọt tới người không nên biết
⚠ Tốn thời gian của cả người gửi lẫn người nhận
⚠ Nguyên tắc ⚠ ĐÚNG thông tin, tới ĐÚNG người, vào ĐÚNG lúc, qua ĐÚNG kênh — thừa một yếu tố cũng là sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch giao tiếp của bạn cập nhật lần cuối khi nào | | | Có ai đang nhận báo cáo mà không bao giờ đọc không | ⚠ hỏi thẳng, sẽ tiết kiệm được nhiều thời gian | | Có ai cần thông tin mà chưa có trong kế hoạch không | |

Và điều đáng khen trong tình huống này: một thành viên đội đã nói ra thay vì để mặc. Rất nhiều lỗ hổng giao tiếp tồn tại đơn giản vì không ai nghĩ đó là việc của mình để nêu ra.

Câu 244 Process
A project manager is completing a project to build a new condo. He needs to confirm that any field drawings by the architect match the office drawings that will go into the project archives. Which project management plan ensures that changes to the project scope and the product scope are thoroughly considered and documented?
  1. A The change control system
  2. B The communication management system
  3. C The configuration management plan
  4. D The integrated change control plan
Xem giải thích

Đáp án

C — KẾ HOẠCH QUẢN LÝ CẤU HÌNH (configuration management plan).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Bản vẽ TẠI CÔNG TRƯỜNG phải khớp bản vẽ ở VĂN PHÒNG | ⚠ kiểm soát PHIÊN BẢN của tài liệu kỹ thuật | | ⚠ Bản vẽ sẽ đi vào KHO LƯU TRỮ dự án | ⚠ phải là phiên bản đúng và duy nhất | | ⚠ Câu hỏi nhắc tới CẢ phạm vi DỰ ÁN lẫn phạm vi SẢN PHẨM | ⚠ quản lý cấu hình bao phủ đặc tính SẢN PHẨM | | ⚠ Định nghĩa | ⚠ quản lý cấu hình kiểm soát ĐẶC TÍNH KỸ THUẬT của sản phẩm và tài liệu mô tả chúng | | ⚠ Vì sao không phải kiểm soát thay đổi | ⚠ kiểm soát thay đổi quyết định CÓ ĐỔI HAY KHÔNG; quản lý cấu hình bảo đảm ai cũng đang nhìn ĐÚNG PHIÊN BẢN |

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

  • D (kế hoạch kiểm soát thay đổi tích hợp) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ kiểm soát thay đổi tích hợp là quy trình ⚠ XÉT DUYỆT yêu cầu thay đổi; ⚠ nó trả lời "có nên đổi không", ⚠ không trả lời "bản vẽ nào là bản đúng".

  • A (hệ thống kiểm soát thay đổi) — ⚠ cùng lý do, ⚠ và câu hỏi hỏi ⚠ KẾ HOẠCH QUẢN LÝ DỰ ÁN nào, ⚠ trong khi "hệ thống" là một phần của tài sản quy trình.

  • B (hệ thống quản lý giao tiếp) — ⚠ không liên quan tới kiểm soát phiên bản tài liệu kỹ thuật.

Ghi nhớ

⚠ Đối chiếu — bộ BA câu về quản lý cấu hình đã hoàn tất ở lô 183: ⚠ câu #25886 (HỆ THỐNG quản lý cấu hình — công cụ, sản phẩm), ⚠ câu #25894 (KIỂM SOÁT PHIÊN BẢN — tài liệu), ⚠ câu #25897 (QUẢN LÝ CẤU HÌNH — khái niệm, đặc tính kỹ thuật). ⚠ Câu này là câu thứ TƯ, và là câu duy nhất hỏi về KẾ HOẠCH quản lý cấu hình. ⚠ Bốn khoá đáp án nhất quán, không mâu thuẫn — chúng chỉ nhìn cùng một chủ đề từ bốn góc: hệ thống, kỹ thuật, khái niệm, kế hoạch. ⚠ Xem thêm câu #25840 ở lô 182 (mức quản lý cấu hình phải PHÙ HỢP, không phải TỐI ĐA).

⚠ Phân biệt hai thứ luôn bị lẫn: | Quản lý CẤU HÌNH | Kiểm soát THAY ĐỔI | |---|---| | ⚠ Nhắm vào ĐẶC TÍNH KỸ THUẬT của sản phẩm | ⚠ Nhắm vào ĐƯỜNG CƠ SỞ của dự án | | ⚠ Trả lời "bản nào là bản đúng" | ⚠ Trả lời "có duyệt thay đổi này không" | | ⚠ Kiểm soát PHIÊN BẢN và TRUY XUẤT | ⚠ Kiểm soát PHẠM VI, LỊCH, CHI PHÍ | | ⚠ Ví dụ: bản vẽ công trường khớp bản vẽ văn phòng | ⚠ Ví dụ: có thêm sàn ngoài trời không | | ⚠ Quan hệ | ⚠ hai quy trình BỔ SUNG nhau: duyệt thay đổi xong thì quản lý cấu hình bảo đảm mọi bản sao đều được cập nhật |

Từ khoá nhận diện:

"bản vẽ, phiên bản, đặc tính kỹ thuật, khớp nhau" → ⚠ quản lý cấu hình "duyệt hay từ chối yêu cầu thay đổi" → ⚠ kiểm soát thay đổi tích hợp "nhật ký ghi mọi thay đổi và trạng thái" → ⚠ nhật ký thay đổi — xem #25956 cùng lô ⚠ Đề hỏi "KẾ HOẠCH nào" → ⚠ loại các phương án là hệ thống hoặc quy trình

⚠ Kế hoạch quản lý cấu hình gồm gì Nội dung
⚠ HẠNG MỤC CẤU HÌNH — cái gì được kiểm soát ⚠ bản vẽ, mã nguồn, tài liệu kỹ thuật
⚠ Cách ĐÁNH SỐ PHIÊN BẢN
⚠ AI được phép sửa và AI phê duyệt
⚠ Cách KIỂM TOÁN cấu hình ⚠ xác nhận thực tế khớp với hồ sơ — đúng việc PM đang làm
⚠ Cách LƯU TRỮ và truy xuất
⚠ Bốn hoạt động cốt lõi ⚠ nhận diện — ghi nhận trạng thái — kiểm soát thay đổi — kiểm toán cấu hình
⚠ Vì sao "bản vẽ công trường khác bản vẽ văn phòng" là chuyện nghiêm trọng Lý do
⚠ Công trình được xây theo bản vẽ SAI
⚠ Hồ sơ hoàn công không phản ánh thực tế ⚠ hại cho việc bảo trì suốt vòng đời công trình
⚠ Tranh chấp pháp lý về sau không có căn cứ
⚠ Sửa chữa trong tương lai dựa vào tài liệu sai
⚠ Vì sao hay xảy ra ⚠ kiến trúc sư sửa tại chỗ để xử lý tình huống thực địa mà không cập nhật ngược về hồ sơ gốc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có bao nhiêu bản sao của cùng một tài liệu | ⚠ càng nhiều nơi lưu càng dễ lệch | | Ai được phép sửa tài liệu kỹ thuật | | | Có ai đối chiếu thực tế với hồ sơ trước khi lưu trữ không | ⚠ đó chính là kiểm toán cấu hình |

Và cái giá của việc bỏ qua quản lý cấu hình thường không lộ ra trong dự án: nó xuất hiện năm năm sau, khi có người mở kho hồ sơ ra để sửa chữa và phát hiện bản vẽ không khớp với toà nhà đang đứng trước mặt.

Câu 245 Process
Andrew is concerned that his team may be getting sloppy as they get closer to the end of the project. He would like to review the defects that remained at the end of the last few sprints to monitor defects in the future. The best tool for him to do this is
  1. A A burndown chart
  2. B A quality assurance report
  3. C A defect trend analysis
  4. D The product backlog
Xem giải thích

Đáp án

C — PHÂN TÍCH XU HƯỚNG LỖI (defect trend analysis).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Andrew muốn xem lỗi CÒN SÓT ở CUỐI vài sprint gần đây | ⚠ nhiều điểm dữ liệu theo THỜI GIAN | | ⚠ Mục đích: THEO DÕI lỗi trong tương lai | ⚠ muốn nhìn XU HƯỚNG, không chỉ nhìn con số hôm nay | | ⚠ Lo đội đang cẩu thả dần khi gần cuối dự án | ⚠ giả thuyết về xu hướng ĐI XUỐNG | | ⚠ Phân tích xu hướng dùng dữ liệu quá khứ để dự báo tương lai | ⚠ đúng công cụ cần | | ⚠ Kết quả kỳ vọng | ⚠ thấy được số lỗi tăng hay giảm qua từng sprint, và tốc độ thay đổi |

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

  • A (biểu đồ burndown) — ⚠ phương án gây nhiễu mạnh nhất vì là biểu đồ quen thuộc nhất của agile: ⚠ nhưng burndown theo dõi ⚠ KHỐI LƯỢNG CÔNG VIỆC CÒN LẠI trong MỘT sprint, ⚠ không theo dõi LỖI, ⚠ và ⚠ không so sánh được giữa nhiều sprint.

  • B (báo cáo đảm bảo chất lượng) — ⚠ báo cáo về tình trạng quy trình chất lượng; ⚠ có thể chứa số liệu lỗi nhưng ⚠ không phải công cụ phân tích xu hướng.

  • D (product backlog) — ⚠ danh sách công việc còn phải làm; ⚠ lỗi có thể nằm trong đó, nhưng nó không cho thấy xu hướng nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25940 ở lô này (giới hạn WIP là cơ chế kiểm soát), câu #25953 (kiểm thử nằm trong DoD), câu #25957 (khi nào phần tăng trưởng xong), và câu #25914 ở lô 183 (thiết kế thực nghiệm). ⚠ Nhóm chất lượng trong agile.

⚠ Các công cụ đo lường trong agile và cái nào đo gì: | Công cụ | Đo gì | |---|---| | ⚠ BURNDOWN | ⚠ khối lượng còn lại trong một sprint hoặc một bản phát hành | | ⚠ BURNUP | ⚠ khối lượng đã hoàn thành, và ĐƯỜNG PHẠM VI thay đổi ra sao | | ⚠ VELOCITY | ⚠ số điểm hoàn thành mỗi sprint | | ⚠ BIỂU ĐỒ LUỒNG TÍCH LUỸ | ⚠ WIP và thời gian chu kỳ theo thời gian | | ⚠ PHÂN TÍCH XU HƯỚNG LỖI | ⚠ số lỗi theo thời gian — CÂU NÀY | | ⚠ Điểm chung của phân tích xu hướng | ⚠ cần ÍT NHẤT ba đến bốn điểm dữ liệu mới nói được gì có ý nghĩa |

Từ khoá nhận diện:

"qua nhiều sprint, theo thời gian" → ⚠ phân tích xu hướng "còn lại bao nhiêu trong sprint này" → ⚠ burndown "đã làm được bao nhiêu và phạm vi đổi thế nào" → ⚠ burnup "số lỗi" → ⚠ chỉ số chất lượng, không phải chỉ số tiến độ

⚠ Vì sao "cẩu thả dần khi gần cuối" là mối lo có thật Lý do
⚠ Áp lực hoàn thành đúng hạn tăng lên
⚠ Đội mệt mỏi sau nhiều sprint liên tiếp
⚠ Cảm giác "sắp xong rồi, làm nhanh cho xong"
⚠ Định nghĩa Hoàn thành bị nới lỏng ngầm ⚠ liên hệ #25936 — bốn điều cấm khi sprint gặp sự cố
⚠ Cách phát hiện sớm ⚠ theo dõi số lỗi và nợ kỹ thuật, không chỉ theo dõi velocity
⚠ Đọc xu hướng lỗi thế nào Cách đọc
⚠ Lỗi TĂNG dần ⚠ chất lượng đang xuống — điều Andrew nghi ngờ
⚠ Lỗi GIẢM dần ⚠ đội đang trưởng thành, hoặc đang kiểm thử ít đi (cẩn thận!)
⚠ Lỗi ỔN ĐỊNH ở mức cao ⚠ quy trình có vấn đề hệ thống
⚠ Lỗi dao động mạnh ⚠ có thể do độ khó của hạng mục thay đổi, cần xem thêm bối cảnh
⚠ Cảnh báo ⚠ số lỗi GIẢM chưa chắc là tin tốt — phải kiểm xem có phải do kiểm thử ít đi không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có đếm lỗi còn sót cuối mỗi sprint không | | | Số đó có được nhìn theo xu hướng hay chỉ nhìn từng sprint | | | Có ai đối chiếu xu hướng lỗi với velocity không | ⚠ velocity tăng mà lỗi cũng tăng là dấu hiệu xấu, không phải tốt |

Và điều một biểu đồ xu hướng làm được mà một con số đơn lẻ không làm được: nó biến linh cảm "hình như đội đang cẩu thả" thành một câu hỏi có thể trả lời bằng dữ liệu.

Câu 246 People
Quincy is the scrum master for Project D, which is in its ninth iteration, has a velocity of 99 story points, and is on budget. After a recent retrospective, a developer approached Quincy with several insightful ideas on the project. The developer also let Quincy know they are too shy to share these in the retrospective. What should Quincy do next?
  1. A Record those ideas in the project documentation.
  2. B Refer the developer to the product owner.
  3. C Encourage the developer to share those ideas during the retrospective, but offer to share the updates on their behalf if they prefer.
  4. D Reject those ideas since they were shared after the retrospective.
Xem giải thích

Đáp án

C — KHUYẾN KHÍCH lập trình viên tự chia sẻ ý tưởng trong retrospective, NHƯNG đề nghị nói giúp nếu họ muốn.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Thành phần | Nội dung | |---|---| | ⚠ KHUYẾN KHÍCH tự nói — giúp họ trưởng thành | ⚠ mục tiêu dài hạn: người này phải nói được trong đội | | ⚠ ĐỀ NGHỊ nói giúp — tôn trọng sự lựa chọn | ⚠ không ép buộc người ngại nói phải phát biểu | | ⚠ Ý tưởng KHÔNG bị mất dù họ chọn cách nào | ⚠ kết quả được bảo đảm | | ⚠ Xây dựng an toàn tâm lý từng bước | ⚠ liên hệ #25922 lô 183 | | ⚠ Cân bằng | ⚠ vừa phát triển con người, vừa không để giá trị bị bỏ phí |

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

  • A (ghi những ý tưởng đó vào tài liệu dự án) — ⚠ phương án gây nhiễu mạnh nhất vì có vẻ giữ lại được ý tưởng: ⚠ nhưng ⚠ tài liệu KHÔNG thay thế được cuộc thảo luận của đội; ⚠ ý tưởng cải tiến cần được cả đội bàn và đồng thuận mới thành hành động, ⚠ và cách này bỏ mặc vấn đề gốc là người đó ngại nói.

  • B (chỉ lập trình viên sang product owner) — ⚠ sai địa chỉ: ⚠ ý tưởng về DỰ ÁN và cách làm việc thuộc phạm vi retrospective, ⚠ không phải việc của PO.

  • D (từ chối vì ý tưởng được nêu sau retrospective) — ⚠ cứng nhắc và gạt bỏ giá trị; ⚠ retrospective là nhịp cải tiến, không phải hạn nộp hồ sơ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25891 ở lô 183 (để Lena tự nói với bên liên quan thay vì nói hộ) — ⚠ hai câu cùng một tinh thần: người dẫn dắt giúp người khác tự lên tiếng, chứ không lên tiếng thay. ⚠ Xem thêm câu #25925 (Megan học nghe đồng cảm), câu #25952 (lãnh đạo phục vụ), và câu #25937 (trao quyền cho đội).

⚠ Vì sao có người ngại nói trong retrospective: | Nguyên nhân | Nội dung | |---|---| | ⚠ Tính cách hướng nội | ⚠ cần thời gian suy nghĩ, không hợp với nói ngay tại chỗ | | ⚠ Chưa đủ AN TOÀN TÂM LÝ trong đội | ⚠ sợ bị phản bác hoặc bị đánh giá | | ⚠ Người mới, chưa quen | | | ⚠ Khác biệt văn hoá hoặc ngôn ngữ | ⚠ liên hệ #25942 — dự án đa quốc gia | | ⚠ Có người nói át trong đội | ⚠ liên hệ #25916 lô 183 — Fabian | | ⚠ Việc của Scrum Master | ⚠ tìm ĐÚNG nguyên nhân, vì mỗi nguyên nhân cần cách xử lý khác nhau |

Từ khoá nhận diện:

"ngại chia sẻ trong họp" → ⚠ khuyến khích tự nói, đề nghị hỗ trợ "nói thay hoàn toàn" → ⚠ giải quyết ngắn hạn, hại dài hạn "chỉ ghi vào tài liệu" → ⚠ ý tưởng chết trong tài liệu "từ chối vì sai thời điểm" → ⚠ cứng nhắc, gạt bỏ giá trị

⚠ Làm retrospective sao cho người ngại nói vẫn tham gia Cách
⚠ Viết ý kiến ra giấy hoặc bảng trực tuyến TRƯỚC khi thảo luận ⚠ kỹ thuật hiệu quả nhất cho người hướng nội
⚠ Thu thập ẩn danh
⚠ Chia nhóm nhỏ trước khi ra nhóm lớn
⚠ Đi vòng để ai cũng được nói ⚠ nhưng cho phép "tôi qua lượt"
⚠ Đổi hình thức retrospective định kỳ ⚠ cùng một khuôn mãi thì ai cũng chán
⚠ Nguyên tắc ⚠ thiết kế buổi họp cho MỌI kiểu người, đừng chỉ cho người nói giỏi
⚠ Nếu Quincy nói giúp thì nói thế nào cho đúng Cách
⚠ Hỏi trước xem có được nêu tên người đề xuất không ⚠ có người muốn ẩn danh, có người muốn được ghi nhận
⚠ Trình bày ý tưởng ĐÚNG như họ nói, không diễn giải lại
⚠ Sau đó ghi nhận công lao nếu họ đồng ý ⚠ cách xây dựng tự tin cho lần sau
⚠ Mục tiêu dài hạn ⚠ lần sau họ tự nói được — nếu năm lần sau vẫn phải nói hộ thì Quincy đang chưa giải quyết vấn đề gốc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong retrospective gần nhất, có ai không nói câu nào không | | | Bạn có cách nào thu ý kiến ngoài việc phát biểu miệng không | | | Ý tưởng cải tiến gần nhất đến từ ai | ⚠ nếu luôn là cùng một người thì buổi họp đang chỉ phục vụ một kiểu người |

Và điều dễ bỏ lỡ nhất: người ngại nói thường là người quan sát nhiều nhất. Ý tưởng của họ đáng giá đúng vì họ đã ngồi im và nhìn suốt chín vòng lặp.

Câu 247 Process
Chase is the procurement manager and is working on completing contractors with three different vendors. Chase has reviewed all the documentation and believes every contractor has met all the terms and conditions. However, one of the contractors believes they have been underpaid for their work on the project and is requesting compensation plus a late fee from Chase. When would procurements be considered closed?
  1. A When all payments have been issued to the seller
  2. B When the buyer no longer needs the seller's services
  3. C When the contract terms of procurement have been satisfied by both the buyer and seller
  4. D When the agreed-upon contract terms have been breached
Xem giải thích

Đáp án

C — Khi CÁC ĐIỀU KHOẢN HỢP ĐỒNG đã được CẢ BÊN MUA LẪN BÊN BÁN thoả mãn.

Vì sao đúng

⚠ Điều kiện đóng mua sắm: | Điều kiện | Nội dung | |---|---| | ⚠ CẢ HAI BÊN đều hoàn thành nghĩa vụ của mình | ⚠ không phải chỉ một bên | | ⚠ Bên bán giao đủ và đúng | | | ⚠ Bên mua thanh toán đầy đủ | | | ⚠ Mọi khiếu nại và tranh chấp đã được giải quyết | ⚠ đúng vấn đề Chase đang gặp | | ⚠ Ở tình huống này | ⚠ một nhà thầu đang KHIẾU NẠI thiếu tiền — nên hợp đồng đó CHƯA ĐÓNG được | | ⚠ Điểm mấu chốt | ⚠ Chase tin rằng mọi bên đã hoàn thành, nhưng NIỀM TIN của một bên không đủ để đóng hợp đồng |

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

  • A (khi mọi khoản thanh toán đã được chuyển cho bên bán) — ⚠ phương án gây nhiễu mạnh nhất vì thanh toán đúng là bước cuối cùng thường thấy: ⚠ nhưng ⚠ thanh toán chỉ là nghĩa vụ của BÊN MUA; ⚠ nếu bên bán chưa giao đủ hoặc còn nghĩa vụ bảo hành thì hợp đồng vẫn chưa đóng.

  • B (khi bên mua không còn cần dịch vụ của bên bán) — ⚠ KHÔNG cần dùng nữa không có nghĩa là hết nghĩa vụ; ⚠ muốn dừng sớm thì phải theo điều khoản chấm dứt hợp đồng.

  • D (khi các điều khoản đã thoả thuận bị VI PHẠM) — ⚠ vi phạm dẫn tới TRANH CHẤP hoặc chấm dứt, ⚠ không phải đóng bình thường.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25960 ở lô này (T&M phải có điều khoản trần), câu #25943 (RFQ), câu #25951 (mua sắm agile), và câu #25887 ở lô 183 (rà soát hợp đồng nhà cung cấp). ⚠ Nhóm mua sắm có NĂM câu qua hai lô.

⚠ Quy trình đóng mua sắm: | Bước | Nội dung | |---|---| | ⚠ Xác minh bên bán đã giao đủ theo hợp đồng | | | ⚠ Nghiệm thu chính thức | | | ⚠ Giải quyết mọi KHIẾU NẠI và tranh chấp | ⚠ bước Chase đang mắc kẹt | | ⚠ Thanh toán cuối cùng | | | ⚠ Cập nhật hồ sơ và lưu trữ | | | ⚠ Đánh giá hiệu quả nhà cung cấp | ⚠ để dùng cho lần mua sắm sau | | ⚠ Thông báo ĐÓNG hợp đồng bằng văn bản | ⚠ phải bằng văn bản, không phải hiểu ngầm | | ⚠ Lưu ý | ⚠ mọi hợp đồng phải được đóng TRƯỚC khi dự án đóng — liên hệ #25909 và #25927 lô 183 |

Từ khoá nhận diện:

"cả hai bên hoàn thành nghĩa vụ" → ⚠ mua sắm đóng "đã trả hết tiền" → ⚠ chỉ là nghĩa vụ của một bên "không cần nữa" → ⚠ phải theo điều khoản chấm dứt "vi phạm hợp đồng" → ⚠ tranh chấp, không phải đóng

⚠ Chase nên làm gì với khiếu nại này Bước
⚠ 1. KHÔNG đóng hợp đồng đó cho tới khi giải quyết xong
⚠ 2. Đối chiếu hồ sơ thanh toán với điều khoản hợp đồng ⚠ dữ liệu trước, ý kiến sau
⚠ 3. Nghe lập luận của nhà thầu, xem họ căn cứ vào đâu ⚠ có thể có công việc phát sinh chưa được ghi nhận
⚠ 4. Nếu vẫn bất đồng thì theo cơ chế GIẢI QUYẾT TRANH CHẤP trong hợp đồng ⚠ thương lượng → hoà giải → trọng tài → toà án
⚠ 5. Ghi lại toàn bộ quá trình
⚠ Điều KHÔNG nên làm ⚠ trả cho xong để êm chuyện, hoặc phớt lờ khiếu nại — cả hai đều tạo tiền lệ xấu
⚠ Vì sao tranh chấp thanh toán hay xảy ra Lý do
⚠ Công việc phát sinh không được lập yêu cầu thay đổi chính thức ⚠ nguyên nhân số một
⚠ Điều khoản mô tả phạm vi công việc mơ hồ
⚠ Cách tính giờ hoặc vật tư hiểu khác nhau ⚠ đặc biệt với hợp đồng T&M — xem #25960
⚠ Hồ sơ nghiệm thu không đầy đủ
⚠ Cách phòng ngừa ⚠ mọi thay đổi phải qua văn bản, kể cả thay đổi nhỏ mà hai bên đã "nói miệng với nhau rồi"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có ghi rõ cơ chế giải quyết tranh chấp không | | | Có công việc nào nhà thầu đã làm mà chưa có văn bản không | | | Bạn có thông báo đóng hợp đồng bằng văn bản không | |

Và điều Chase đang học được: "tôi tin rằng mọi bên đã hoàn thành" là một câu nói về niềm tin, còn đóng hợp đồng đòi hỏi một câu nói về bằng chứng.

Câu 248 People
During the initial project team meeting, the project manager and the project team established ground rules for operating project team meetings. Tina, a project team member, is not obeying the project rules. Who has the responsibility to enforce the rules?
  1. A The project manager
  2. B The project sponsor
  3. C The project team
  4. D The human resources department
Xem giải thích

Đáp án

C — ĐỘI DỰ ÁN.

Vì sao đúng

⚠ Vì sao trách nhiệm thuộc về đội: | Lý do | Nội dung | |---|---| | ⚠ Quy tắc chung do CHÍNH ĐỘI cùng đặt ra | ⚠ đề nói rõ "quản lý dự án VÀ đội cùng thiết lập" | | ⚠ Ai đặt ra luật thì người đó sở hữu luật | | | ⚠ Đội tự thực thi làm tăng trách nhiệm tập thể | | | ⚠ Quản lý dự án đi phạt từng người sẽ biến quy tắc thành mệnh lệnh áp đặt | | | ⚠ Vai trò của PM | ⚠ nhắc nhở, làm gương, và hỗ trợ khi đội không tự xử lý được — nhưng KHÔNG phải người thực thi chính |

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

  • A (quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất vì PM là người đứng đầu dự án: ⚠ nhưng ⚠ quy tắc do TẬP THỂ đặt ra thì TẬP THỂ giữ; ⚠ nếu PM đơn phương thực thi thì đội mất cảm giác sở hữu và quy tắc trở thành nội quy áp xuống.

  • B (nhà tài trợ dự án) — ⚠ quá xa; ⚠ nhà tài trợ không tham gia sinh hoạt hằng ngày của đội.

  • D (phòng nhân sự) — ⚠ chỉ liên quan khi vi phạm chạm tới chính sách nhân sự của công ty; ⚠ vi phạm quy tắc họp của đội không tới mức đó.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25883 ở lô 183 (thoả thuận làm việc nhóm — teaming agreement), câu #25937 ở lô này (trao quyền cho đội tự giải quyết xung đột), và câu #25963 (can thiệp khi quy trình vừa thống nhất bị vi phạm). ⚠ Ba câu vẽ đủ một chuỗi: đội tự đặt quy tắc → đội tự giữ → người dẫn dắt chỉ can thiệp khi đội không tự xử lý được.

⚠ Quy tắc chung (ground rules) là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Do ĐỘI cùng xây dựng, không phải áp từ trên xuống | | | ⚠ Ghi rõ hành vi MONG ĐỢI, không chỉ hành vi bị cấm | | | ⚠ Nằm trong kế hoạch quản lý nguồn lực | | | ⚠ Được nhắc lại và rà soát định kỳ | | | ⚠ Ví dụ điển hình | ⚠ họp đúng giờ, tắt chuông điện thoại, không cắt lời, mỗi người có tiếng nói, quyết định gì thì ghi lại | | ⚠ Vì sao hiệu quả | ⚠ người ta tuân theo luật mình tham gia đặt ra dễ hơn nhiều so với luật người khác áp xuống |

Từ khoá nhận diện:

"quy tắc do đội cùng đặt" → ⚠ đội tự thực thi "nội quy công ty" → ⚠ phòng nhân sự và quản lý "quản lý dự án đi phạt" → ⚠ biến quy tắc thành mệnh lệnh "nhà tài trợ" → ⚠ quá xa với sinh hoạt hằng ngày của đội

⚠ Đội thực thi quy tắc thế nào cho lành mạnh Cách
⚠ Nhắc nhẹ NGAY TẠI CHỖ, không đợi tích tụ ⚠ "mình đã thống nhất là không cắt lời nhau nhỉ"
⚠ Nhắc HÀNH VI, không công kích CON NGƯỜI
⚠ Đưa ra retrospective nếu lặp lại nhiều lần ⚠ có thể quy tắc đó không còn phù hợp
⚠ Rà soát lại quy tắc khi có người mới vào đội ⚠ người mới không có mặt lúc đặt ra luật
⚠ Khi nào PM phải can thiệp ⚠ khi vi phạm lặp lại và ảnh hưởng tới công việc, hoặc khi đội không dám nhắc nhau
⚠ Vì sao quy tắc chung hay thất bại Nguyên nhân
⚠ Đặt ra ở buổi đầu rồi không bao giờ nhắc lại ⚠ nguyên nhân phổ biến nhất
⚠ Quá nhiều quy tắc, không ai nhớ nổi ⚠ năm tới bảy điều là đủ
⚠ Viết chung chung: "tôn trọng lẫn nhau" ⚠ không kiểm chứng được
⚠ Người dẫn dắt tự vi phạm ⚠ giết chết quy tắc nhanh nhất
⚠ Cách giữ cho nó sống ⚠ treo ở nơi ai cũng thấy, và nhắc lại đầu mỗi buổi họp quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có quy tắc chung viết ra không | | | Có ai nhớ được ba điều trong đó không | ⚠ thử hỏi bất chợt | | Lần cuối có người nhắc nhau về quy tắc là khi nào | |

Và điều làm nên sự khác biệt giữa quy tắc chung và nội quy: nội quy được thi hành bởi người có quyền, còn quy tắc chung được giữ bởi những người đã cùng nhau viết ra nó.

Câu 249 Process
You are the project manager for your company, and you have recently been assigned to a new high-profile project. When should the project kick-off meeting happen?
  1. A At the start of scope validation
  2. B When management has approved the initial project plan
  3. C When the project manager has the project team assembled for the first time
  4. D When the project manager has approved the project plan
Xem giải thích

Đáp án

B — KHI LÃNH ĐẠO ĐÃ PHÊ DUYỆT KẾ HOẠCH DỰ ÁN BAN ĐẦU.

Vì sao đúng

⚠ Vì sao đây là thời điểm đúng: | Lý do | Nội dung | |---|---| | ⚠ Có kế hoạch được duyệt thì mới có gì để TRÌNH BÀY | ⚠ mục tiêu, phạm vi, mốc thời gian, cách làm việc | | ⚠ Có phê duyệt thì cam kết mới THẬT | ⚠ không phải bàn về một dự án còn chưa chắc có | | ⚠ Đủ sớm để đặt kỳ vọng trước khi thực hiện | | | ⚠ Đủ muộn để không phải nói "chúng tôi chưa biết" | | | ⚠ Kick-off KHÔNG phải nơi lập kế hoạch | ⚠ nó là nơi CÔNG BỐ kế hoạch đã có |

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

  • C (khi quản lý dự án tập hợp được đội lần đầu tiên) — ⚠ phương án gây nhiễu mạnh nhất vì kick-off đúng là dịp đội gặp nhau: ⚠ nhưng ⚠ có đủ người KHÔNG có nghĩa là có đủ nội dung; ⚠ họp khởi động mà chưa có kế hoạch được duyệt thì chỉ là buổi giới thiệu làm quen.

  • D (khi quản lý dự án đã phê duyệt kế hoạch) — ⚠ SAI VỀ THẨM QUYỀN: ⚠ quản lý dự án ⚠ SOẠN ⚠ kế hoạch, ⚠ LÃNH ĐẠO hoặc NHÀ TÀI TRỢ mới PHÊ DUYỆT.

  • A (khi bắt đầu xác nhận phạm vi) — ⚠ xác nhận phạm vi diễn ra ở CUỐI dự án ⚠ (xem #25956 cùng lô), ⚠ muộn hơn kick-off rất nhiều.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG: ⚠ câu #25932 ở lô 183 ⚠ (buổi họp đầu dự án mời đủ bên liên quan, đội và lãnh đạo gọi là gì → HỌP KHỞI ĐỘNG). ⚠ Hai câu cùng chủ đề, một câu hỏi TÊN GỌI, câu này hỏi THỜI ĐIỂM — hai khoá đáp án NHẤT QUÁN, bổ sung nhau. ⚠ Ghi chú ở #25932 đã nêu: trong dự án dự đoán, kick-off diễn ra SAU khi lập kế hoạch xong và TRƯỚC khi bắt đầu thực hiện — chính là điều câu này khẳng định.

⚠ Thời điểm kick-off theo từng loại dự án: | Loại dự án | Thời điểm | |---|---| | ⚠ DỰ ĐOÁN | ⚠ sau khi kế hoạch được duyệt, trước khi thực hiện — CÂU NÀY | | ⚠ Dự án nhỏ, đội đã quen nhau | ⚠ ngay sau khi ban hành điều lệ | | ⚠ AGILE | ⚠ có thể có kick-off cho mỗi bản phát hành | | ⚠ Nhiều giai đoạn | ⚠ mỗi giai đoạn có thể có buổi khởi động riêng | | ⚠ Nguyên tắc chung | ⚠ kick-off nằm ở RANH GIỚI giữa lập kế hoạch và thực hiện |

Từ khoá nhận diện:

"kế hoạch đã được lãnh đạo duyệt" → ⚠ thời điểm kick-off "quản lý dự án tự duyệt kế hoạch" → ⚠ sai thẩm quyền, luôn là phương án sai "xác nhận phạm vi" → ⚠ cuối dự án "đội vừa tập hợp đủ" → ⚠ điều kiện cần, không phải điều kiện đủ

⚠ Ai PHÊ DUYỆT cái gì Tài liệu Người duyệt
⚠ ĐIỀU LỆ DỰ ÁN ⚠ NHÀ TÀI TRỢ ban hành
⚠ KẾ HOẠCH QUẢN LÝ DỰ ÁN ⚠ nhà tài trợ hoặc lãnh đạo duyệt
⚠ YÊU CẦU THAY ĐỔI lớn ⚠ CCB hoặc nhà tài trợ
⚠ NGHIỆM THU BÀN GIAO ⚠ khách hàng
⚠ Vai trò của PM ⚠ SOẠN và THỰC HIỆN, hiếm khi là người PHÊ DUYỆT
⚠ Mẹo làm đề ⚠ phương án nào để PM tự duyệt việc của chính mình thì gần như chắc chắn sai
⚠ Vì sao dự án "cấp cao" càng cần kick-off tốt Lý do
⚠ Nhiều bên liên quan, nhiều kỳ vọng khác nhau
⚠ Lãnh đạo quan sát sát sao ngay từ đầu
⚠ Ấn tượng ban đầu ảnh hưởng tới mức tin tưởng suốt dự án
⚠ Chuẩn bị gì ⚠ kế hoạch đã duyệt, thông điệp rõ ràng, và dành đủ thời gian cho hỏi đáp — liên hệ #25932

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch dự án của bạn đã được ai duyệt bằng văn bản chưa | | | Kick-off của bạn có nội dung để trình bày hay chỉ để làm quen | | | Nhà tài trợ có tham dự và phát biểu không | |

Và lý do thứ tự này quan trọng: một buổi khởi động không có kế hoạch được duyệt sẽ biến thành buổi họp lập kế hoạch bất đắc dĩ, với đầy đủ những người không nên có mặt trong đó.

Câu 250 Process
The COO of your software development company has asked you to develop a rough prototype of a piece of software to test a proof of concept for her team. Which development approach is best suited for this project?
  1. A Predictive development
  2. B Incremental development
  3. C Hybrid development
  4. D Waterfall development
Xem giải thích

Đáp án

B — PHÁT TRIỂN TĂNG DẦN (incremental development).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Nguyên mẫu THÔ (rough prototype) | ⚠ chưa hoàn chỉnh, chỉ để thử | | ⚠ Mục đích: KIỂM CHỨNG Ý TƯỞNG (proof of concept) | ⚠ cần kết quả nhanh để học, không cần sản phẩm hoàn thiện | | ⚠ Cho đội của giám đốc vận hành dùng thử | ⚠ cần phản hồi sớm | | ⚠ Yêu cầu chắc chắn sẽ thay đổi sau khi thử | ⚠ không thể lập kế hoạch chi tiết từ đầu | | ⚠ Vì sao KHÔNG dùng dự đoán | ⚠ dự đoán đòi hỏi phạm vi rõ ràng ngay từ đầu — điều mà một nguyên mẫu thử nghiệm không thể có |

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

  • C (phát triển lai — hybrid) — ⚠ phương án gây nhiễu mạnh nhất vì lai luôn nghe an toàn: ⚠ nhưng lai là ⚠ kết hợp dự đoán và thích ứng cho dự án LỚN có nhiều phần khác nhau; ⚠ một nguyên mẫu thô nhỏ gọn ⚠ không cần tới sự phức tạp đó.

  • A (phát triển dự đoán) và D (thác nước) — ⚠ cả hai đòi hỏi PHẠM VI XÁC ĐỊNH TRƯỚC; ⚠ hoàn toàn không hợp với việc kiểm chứng ý tưởng.

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

⚠ Theo phân loại chuẩn, "làm nguyên mẫu để kiểm chứng ý tưởng" khớp với LẶP (iterative) hơn là TĂNG DẦN (incremental): | Cách tiếp cận | Đặc trưng | |---|---| | ⚠ LẶP (iterative) | ⚠ làm đi làm lại để HOÀN THIỆN DẦN cùng một thứ — đúng bản chất của nguyên mẫu | | ⚠ TĂNG DẦN (incremental) | ⚠ giao từng PHẦN dùng được, mỗi phần bổ sung tính năng mới | | ⚠ Vấn đề của đề | ⚠ bộ phương án KHÔNG có lựa chọn "lặp" — chỉ có dự đoán, tăng dần, lai, thác nước | | ⚠ Xử lý | ⚠ GIỮ NGUYÊN khoá B: trong bốn phương án được cho, "tăng dần" là lựa chọn thích ứng duy nhất và là đáp án bảo vệ được | | ⚠ Lưu ý khi đi thi | ⚠ nếu thấy cả "lặp" và "tăng dần" trong cùng bộ phương án, hãy chọn LẶP cho nguyên mẫu và TĂNG DẦN cho việc giao từng phần |

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25919 ở lô 183 (chạy spike để giảm bất định kỹ thuật) — ⚠ spike chính là hình thức agile của proof of concept. ⚠ Xem thêm câu #25908 (agile lập kế hoạch nhiều tầng) và câu #25951 ở lô này (mua sắm agile).

⚠ BỐN cách tiếp cận phát triển: | Cách | Đặc trưng | Dùng khi | |---|---|---| | ⚠ DỰ ĐOÁN | ⚠ lập kế hoạch đầy đủ trước, thực hiện theo | ⚠ yêu cầu rõ, ít thay đổi, công nghệ quen thuộc | | ⚠ LẶP | ⚠ hoàn thiện dần qua các vòng | ⚠ yêu cầu chưa rõ, cần phản hồi để làm rõ | | ⚠ TĂNG DẦN | ⚠ giao từng phần dùng được | ⚠ cần có giá trị sớm, phạm vi chia nhỏ được | | ⚠ LAI | ⚠ kết hợp — phần này dự đoán, phần kia thích ứng | ⚠ dự án lớn có nhiều loại công việc khác nhau | | ⚠ Thực tế | ⚠ agile thường dùng CẢ lặp LẪN tăng dần cùng lúc |

Từ khoá nhận diện:

"nguyên mẫu, kiểm chứng ý tưởng, thử nghiệm" → ⚠ thích ứng — lặp hoặc tăng dần "yêu cầu rõ ràng, không đổi" → ⚠ dự đoán "dự án lớn có phần rõ, phần chưa rõ" → ⚠ lai "thác nước" → ⚠ một dạng của dự đoán, gần như không bao giờ là đáp án đúng trong đề agile

⚠ Nguyên mẫu (prototype) dùng để làm gì Mục đích
⚠ Làm rõ YÊU CẦU bằng thứ nhìn được và chạm được ⚠ người dùng mô tả nhu cầu kém, nhưng chỉ ra cái sai rất giỏi
⚠ Kiểm chứng khả thi KỸ THUẬT ⚠ proof of concept — đúng tình huống này
⚠ Giảm rủi ro trước khi đầu tư lớn
⚠ Thuyết phục bên liên quan bằng thứ cụ thể
⚠ Rủi ro lớn nhất ⚠ nguyên mẫu THÔ bị đưa thẳng vào sản xuất — phải nói rõ ngay từ đầu là nó SẼ BỊ VỨT ĐI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguyên mẫu của bạn có được thống nhất là sẽ vứt đi không | ⚠ nếu không, hãy chuẩn bị tinh thần nó sẽ thành sản phẩm thật | | Bạn định học được điều gì cụ thể từ nguyên mẫu này | ⚠ không rõ mục tiêu học thì làm xong cũng không biết kết luận gì | | Có đặt hộp thời gian cho việc làm nguyên mẫu không | ⚠ spike luôn phải có hộp thời gian |

Và cái bẫy kinh điển của mọi nguyên mẫu thô: nó chạy được, ai đó nhìn thấy, và câu hỏi tiếp theo luôn là "sao không dùng luôn cái này?"