Ngân hàng đề — PMP® Mock Exam Set I Exam
Tìm thấy 720 câu.
- A Ensure adherence to the sprint timelines.
- B Increase their agile understanding.
- C Help team members improve their skills, get past issues, and stay on track.
- D Create solutions for roadblocks.
Xem giải thích
Đáp án
C — GIÚP THÀNH VIÊN NÂNG CAO KỸ NĂNG, VƯỢT QUA VẤN ĐỀ và GIỮ ĐÚNG HƯỚNG.
Vì sao đúng
⚠ Vì sao đây là mục đích BAO TRÙM nhất: | Thành phần | Nội dung | |---|---| | ⚠ NÂNG KỸ NĂNG — phát triển năng lực dài hạn | | | ⚠ VƯỢT QUA VẤN ĐỀ — gỡ vướng ngay trước mắt | | | ⚠ GIỮ ĐÚNG HƯỚNG — không lệch khỏi mục tiêu | | | ⚠ Bao gồm cả ba chiều: năng lực, vấn đề, định hướng | ⚠ ba phương án còn lại chỉ nêu MỘT phần | | ⚠ Huấn luyện là gì | ⚠ HỎI để người ta tự tìm ra câu trả lời — liên hệ #26146 cùng lô |
Vì sao các phương án khác sai
-
B (tăng hiểu biết về agile) — ⚠ phương án gây nhiễu mạnh nhất vì đó ĐÚNG LÀ một mục đích thật của huấn luyện trong đội agile: ⚠ nhưng nó ⚠ QUÁ HẸP ⚠ — huấn luyện không chỉ về agile mà về mọi năng lực và vấn đề của người được huấn luyện.
-
D (tạo giải pháp cho các vật cản) — ⚠ SAI VỀ BẢN CHẤT: ⚠ huấn luyện viên ⚠ KHÔNG tạo giải pháp thay người khác ⚠ — họ giúp người kia tự tìm ra; ⚠ và gỡ vật cản là việc riêng của Scrum Master.
-
A (bảo đảm tuân thủ thời hạn sprint) — ⚠ đó là mục tiêu QUẢN LÝ, không phải mục đích huấn luyện; ⚠ huấn luyện nhắm vào CON NGƯỜI, không vào lịch trình.
Ghi nhớ
⚠ Đối chiếu — cặp câu về HUẤN LUYỆN trong CÙNG MỘT LÔ: | Câu | Câu hỏi | Khoá | |---|---|---| | ⚠ #26146 | ⚠ hoạt động phổ biến NHẤT giúp đội phát triển tri thức | ⚠ HUẤN LUYỆN | | ⚠ #26173 (câu này) | ⚠ LÝ DO CHÍNH thực hiện huấn luyện | ⚠ nâng kỹ năng, vượt vấn đề, đi đúng hướng | | ⚠ Hai câu bổ sung nhau | ⚠ câu kia xác định NÓ LÀ GÌ, câu này xác định VÌ SAO LÀM | | ⚠ Xem thêm | ⚠ #25913 lô 183 (SM huấn luyện bên liên quan), #26019 lô 185 (ghép cặp), #25958 lô 184 (tổ chức gọi quản lý là huấn luyện viên) |
⚠ BỐN cách phát triển năng lực — nhắc lại: | Cách | Bản chất | Nhịp độ | |---|---|---| | ⚠ HUẤN LUYỆN | ⚠ HỎI để người ta tự tìm ra | ⚠ liên tục, hằng ngày | | ⚠ KÈM CẶP | ⚠ CHIA SẺ kinh nghiệm, định hướng nghề nghiệp | ⚠ dài hạn, định kỳ | | ⚠ ĐÀO TẠO | ⚠ DẠY kiến thức có cấu trúc | ⚠ theo khoá | | ⚠ ĐÁNH GIÁ | ⚠ ĐO năng lực hiện có | ⚠ định kỳ | | ⚠ Mẹo nhớ | ⚠ huấn luyện HỎI, kèm cặp KỂ, đào tạo DẠY, đánh giá ĐO — liên hệ #26146 cùng lô |
Từ khoá nhận diện:
"nâng kỹ năng, vượt vấn đề, đi đúng hướng" → ⚠ mục đích bao trùm của huấn luyện "tăng hiểu biết agile" → ⚠ một phần, quá hẹp "tạo giải pháp thay họ" → ⚠ sai bản chất huấn luyện "bảo đảm đúng hạn" → ⚠ mục tiêu quản lý, không phải huấn luyện
| ⚠ Huấn luyện KHÔNG phải là gì | Không phải |
|---|---|
| ⚠ KHÔNG phải đưa ra câu trả lời | ⚠ đó là tư vấn hoặc kèm cặp |
| ⚠ KHÔNG phải giám sát tiến độ | ⚠ đó là quản lý |
| ⚠ KHÔNG phải đánh giá năng lực | ⚠ đó là việc của quản lý nhân sự |
| ⚠ KHÔNG phải làm hộ khi họ bí | ⚠ liên hệ #25936 lô 184 — Scrum Master không nhảy vào code thay đội |
| ⚠ Ranh giới | ⚠ huấn luyện viên chịu trách nhiệm về QUÁ TRÌNH học; người được huấn luyện chịu trách nhiệm về KẾT QUẢ |
| ⚠ Câu hỏi huấn luyện tốt | Ví dụ |
|---|---|
| ⚠ "Bạn đã thử những cách nào rồi?" | ⚠ giúp họ tự tổng kết |
| ⚠ "Điều gì đang cản trở bạn nhất?" | |
| ⚠ "Nếu không có ràng buộc nào, bạn sẽ làm gì?" | ⚠ mở khoá tư duy |
| ⚠ "Bạn cần gì từ tôi?" | ⚠ để họ tự nêu nhu cầu, không áp đặt |
| ⚠ Kỹ thuật khó nhất | ⚠ im lặng và chờ — phần lớn người huấn luyện nói quá nhiều |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khi ai đó hỏi, bạn trả lời hay hỏi lại | | | Người bạn huấn luyện có tự giải quyết được vấn đề mới không | ⚠ thước đo duy nhất | | Bạn dành bao nhiêu phần trăm thời gian để nói trong buổi huấn luyện | ⚠ dưới 30% là tốt |
Và điều Rose đang xây dựng qua từng buổi huấn luyện nhỏ: một đội mà mỗi năm sau lại cần cô ít hơn năm trước — và đó chính là dấu hiệu cô đang làm rất tốt việc của mình.
- A Do nothing. The project is complete.
- B Analyze how Project Cali will impact the overall organization.
- C Plan a follow-up project.
- D Begin looking for another job.
Xem giải thích
Đáp án
B — PHÂN TÍCH TÁC ĐỘNG của Project Cali lên TOÀN TỔ CHỨC.
Vì sao đúng
⚠ Vì sao giao sản phẩm chưa đủ: | Lý do | Nội dung | |---|---| | ⚠ Sản phẩm là HỆ THỐNG THÔNG TIN NHÂN SỰ dùng toàn công ty | ⚠ ảnh hưởng tới MỌI nhân viên | | ⚠ Giao xong không có nghĩa là được DÙNG | ⚠ liên hệ #26034 lô 186 — bàn giao xong vẫn cần quản trị thay đổi văn hoá | | ⚠ Cần biết tác động tới quy trình, vai trò, cách làm việc hiện tại | | | ⚠ Lợi ích chỉ hiện thực hoá khi tổ chức THÍCH NGHI | | | ⚠ Chuỗi giá trị | ⚠ ĐẦU RA (hệ thống) → KẾT QUẢ (người ta dùng) → LỢI ÍCH (quản lý dữ liệu tốt hơn) |
Vì sao các phương án khác sai
-
C (lập kế hoạch cho một dự án tiếp theo) — ⚠ phương án gây nhiễu mạnh nhất vì nghĩ xa là điều tốt: ⚠ nhưng ⚠ đó không phải việc của Simon lúc này, ⚠ và ⚠ lập dự án mới khi chưa biết dự án hiện tại tác động ra sao là làm ngược thứ tự.
-
A (không làm gì, dự án đã hoàn thành) — ⚠ dự án MỚI GẦN xong, chưa xong; ⚠ và còn cả giai đoạn đóng lẫn hiện thực hoá lợi ích.
-
D (bắt đầu tìm việc mới) — ⚠ phương án đùa, ⚠ hiển nhiên sai.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #26034 ở lô 186 (Georgia bàn giao mạng xã hội nội bộ → phối hợp với nhân sự về thay đổi văn hoá) — ⚠ hai câu gần như CÙNG MỘT TÌNH HUỐNG: sản phẩm nội bộ sắp bàn giao, và câu trả lời đều là NHÌN RA NGOÀI PHẠM VI DỰ ÁN. ⚠ Xem thêm câu #26054 lô 186 (xây KPI để đo giá trị), câu #26123 lô 187 (nhận diện nhu cầu), và câu #26118 (agile cục bộ không lan toả).
⚠ Chuỗi ĐẦU RA → KẾT QUẢ → LỢI ÍCH: | Bậc | Với Project Cali | |---|---| | ⚠ ĐẦU RA (output) | ⚠ hệ thống thông tin nhân sự đã cài đặt và chạy | | ⚠ KẾT QUẢ (outcome) | ⚠ bộ phận nhân sự và nhân viên THẬT SỰ dùng nó | | ⚠ LỢI ÍCH (benefit) | ⚠ dữ liệu nhân viên được quản lý tốt hơn, ra quyết định nhanh hơn | | ⚠ Dự án chịu trách nhiệm tới đâu | ⚠ truyền thống là tới ĐẦU RA; thực hành hiện đại đòi hỏi quan tâm tới KẾT QUẢ | | ⚠ Vì sao nhiều dự án "thành công" mà vô ích | ⚠ giao đúng hạn, đúng ngân sách, đúng phạm vi — rồi không ai dùng |
Từ khoá nhận diện:
"sản phẩm ảnh hưởng toàn tổ chức" → ⚠ phân tích tác động, quản trị thay đổi "dự án xong rồi, không cần làm gì" → ⚠ luôn sai "lập dự án tiếp theo" → ⚠ chưa phải lúc "đầu ra và kết quả" → ⚠ hai thứ khác nhau, và dự án chỉ tự động tạo ra cái đầu tiên
| ⚠ Phân tích tác động tổ chức gồm gì | Nội dung |
|---|---|
| ⚠ QUY TRÌNH nào thay đổi | ⚠ cách nhập dữ liệu, cách duyệt nghỉ phép, cách báo cáo |
| ⚠ VAI TRÒ nào thay đổi | ⚠ ai làm việc gì khác đi |
| ⚠ Ai cần ĐÀO TẠO và đào tạo cái gì | |
| ⚠ Hệ thống cũ xử lý ra sao | ⚠ chạy song song, ngừng, hay chuyển dữ liệu |
| ⚠ Ai sẽ CHỐNG ĐỐI và vì sao | ⚠ liên hệ #26074 lô 186 — quản lý thái độ bên liên quan |
| ⚠ Ai VẬN HÀNH và HỖ TRỢ sau khi đội giải tán | ⚠ câu hỏi hay bị quên nhất |
| ⚠ Kết quả | ⚠ kế hoạch chuyển giao và quản trị thay đổi, không chỉ là bàn giao kỹ thuật |
| ⚠ Simon vẫn phải làm những việc đóng dự án | Việc |
|---|---|
| ⚠ Nghiệm thu chính thức | |
| ⚠ Bài học kinh nghiệm | ⚠ liên hệ #26141 cùng lô |
| ⚠ Lưu trữ tài liệu theo chuẩn của PMO | ⚠ liên hệ #26138 cùng lô |
| ⚠ Giải phóng nguồn lực | |
| ⚠ Chuyển giao cho vận hành | |
| ⚠ Thứ tự ưu tiên | ⚠ việc ảnh hưởng tới LỢI ÍCH làm trước; việc hành chính làm song song |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sản phẩm của bạn đòi hỏi ai đổi cách làm việc | | | Có kế hoạch quản trị thay đổi cho họ không | | | Ai đo mức độ SỬ DỤNG sau khi dự án đóng | ⚠ thường không ai — và đó là lý do lợi ích bốc hơi |
Và câu hỏi Simon nên đặt ngay bây giờ, khi còn kịp: sáu tháng nữa, nếu bộ phận nhân sự vẫn dùng bảng tính cũ song song với hệ thống mới, thì dự án này có được coi là thành công không?
- A Update the risk plan and risk response plan.
- B Document lessons learned.
- C Hold a change control meeting.
- D Implement approved changes.
Xem giải thích
Đáp án
B — GHI LẠI BÀI HỌC KINH NGHIỆM.
Vì sao đúng
⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Vừa hoàn thành GIAI ĐOẠN ĐẦU của một dự án liên phòng ban | ⚠ còn nhiều giai đoạn phía sau | | ⚠ Các quản lý dự án nêu điều LÀM TỐT và điều CẦN CẢI THIỆN | ⚠ nguyên liệu của bài học | | ⚠ Nhiều điểm có CHỦ ĐỀ LẶP LẠI | ⚠ dấu hiệu vấn đề HỆ THỐNG, không phải ngẫu nhiên | | ⚠ Mục tiêu: giai đoạn hai chạy trơn tru hơn | ⚠ đúng mục đích của bài học kinh nghiệm | | ⚠ Điểm mấu chốt | ⚠ bài học ở CUỐI GIAI ĐOẠN áp dụng được NGAY cho giai đoạn sau — không phải chờ dự án khác |
Vì sao các phương án khác sai
-
A (cập nhật kế hoạch rủi ro và kế hoạch ứng phó) — ⚠ phương án gây nhiễu mạnh nhất vì các chủ đề lặp lại ĐÚNG LÀ có thể chỉ ra rủi ro: ⚠ nhưng đó là ⚠ MỘT HỆ QUẢ CÓ THỂ CÓ, không phải BƯỚC ĐẦU TIÊN; ⚠ phải GHI LẠI và phân tích bài học trước, rồi mới biết cần cập nhật kế hoạch nào.
-
C (họp kiểm soát thay đổi) — ⚠ để xét YÊU CẦU THAY ĐỔI; ⚠ chưa có yêu cầu thay đổi nào ở đây.
-
D (thực hiện các thay đổi đã duyệt) — ⚠ chưa có thay đổi nào được duyệt.
Ghi nhớ
⚠ Đối chiếu — bài học kinh nghiệm nay lên MƯỜI HAI câu qua bảy lô: ⚠ #25757/#25761 lô 180, ⚠ #25896, #25911 lô 183, ⚠ #25964 lô 184, ⚠ #25999, #26006 lô 185, ⚠ #26055, #26058 lô 186, ⚠ #26126 lô 187, ⚠ #26141 ở lô này, ⚠ và câu này. ⚠ Chủ đề được hỏi dày thứ hai của bộ đề, chỉ sau bên liên quan.
⚠ Vì sao "chủ đề LẶP LẠI" là chi tiết quan trọng: | Ý nghĩa | Nội dung | |---|---| | ⚠ Nhiều quản lý dự án nêu CÙNG một vấn đề | ⚠ đó là vấn đề HỆ THỐNG, không phải sự cố riêng lẻ | | ⚠ Vấn đề hệ thống sẽ LẶP LẠI ở giai đoạn sau nếu không sửa | | | ⚠ Và nó có thể ảnh hưởng tới CÁC DỰ ÁN KHÁC của tổ chức | ⚠ liên hệ #26035 lô 186 — tri thức mức tổ chức | | ⚠ Vì thế | ⚠ phải GHI LẠI có hệ thống, không chỉ nghe rồi bỏ qua | | ⚠ Bước tiếp theo sau khi ghi | ⚠ biến bài học thành HÀNH ĐỘNG cụ thể cho giai đoạn hai |
Từ khoá nhận diện:
"tổng kết giai đoạn, chủ đề lặp lại" → ⚠ ghi bài học kinh nghiệm "cập nhật kế hoạch rủi ro" → ⚠ hệ quả có thể có, không phải bước đầu "họp kiểm soát thay đổi" → ⚠ cần có yêu cầu thay đổi trước đã "thực hiện thay đổi đã duyệt" → ⚠ chưa có gì được duyệt
| ⚠ Từ bài học tới cải thiện thật — chuỗi đầy đủ | Bước |
|---|---|
| ⚠ 1. THU THẬP ở buổi tổng kết giai đoạn | ⚠ đã làm |
| ⚠ 2. GHI vào SỔ ĐĂNG KÝ BÀI HỌC | ⚠ CÂU NÀY |
| ⚠ 3. PHÂN TÍCH — tìm chủ đề chung và nguyên nhân gốc | ⚠ liên hệ #26103 lô 187 — phân tích xương cá |
| ⚠ 4. Chuyển thành HÀNH ĐỘNG cho giai đoạn hai | ⚠ có người phụ trách và hạn |
| ⚠ 5. Cập nhật các kế hoạch liên quan nếu cần | ⚠ phương án A nằm ở bước này |
| ⚠ 6. Lưu vào kho tổ chức khi dự án đóng | ⚠ liên hệ #26138 cùng lô |
| ⚠ Điểm đứt gãy phổ biến nhất | ⚠ giữa bước 2 và bước 4 — ghi rồi để đó |
| ⚠ Vì sao tổng kết ở CUỐI GIAI ĐOẠN hiệu quả hơn cuối dự án | Lý do |
|---|---|
| ⚠ Chi tiết còn tươi mới | |
| ⚠ Áp dụng được NGAY cho giai đoạn tiếp theo | ⚠ giá trị lớn nhất |
| ⚠ Người tham gia còn đầy đủ | |
| ⚠ Khối lượng vừa phải, không dồn thành buổi dài | ⚠ liên hệ #26055 lô 186 |
| ⚠ Thường gắn với | ⚠ CỔNG GIAI ĐOẠN — liên hệ #26114 lô 187 |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bài học từ giai đoạn trước có được ghi lại không | | | Có chủ đề nào lặp lại qua nhiều giai đoạn không | ⚠ đó là vấn đề hệ thống cần xử lý ở tầng cao hơn | | Bài học có biến thành hành động cụ thể không | ⚠ có người phụ trách và hạn hoàn thành |
Và điều làm nên khác biệt giữa một buổi tổng kết có ích và một buổi tổng kết hình thức: buổi có ích kết thúc bằng vài dòng ghi lại và một danh sách việc phải làm khác đi ở giai đoạn sau.
- A Herzberg's Theory of Motivation
- B Risk acceptance
- C The utility function
- D The risk-reward ratio
Xem giải thích
Đáp án
C — HÀM HỮU DỤNG (the utility function).
Vì sao đúng
⚠ Hàm hữu dụng là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Mô tả THÁI ĐỘ của một tổ chức hoặc cá nhân đối với rủi ro | | | ⚠ Còn gọi là mức CHỊU ĐỰNG hay KHẨU VỊ rủi ro | ⚠ đúng đáp án | | ⚠ Cho biết tổ chức SẴN SÀNG CHẤP NHẬN bao nhiêu bất định | | | ⚠ Là một YẾU TỐ MÔI TRƯỜNG DOANH NGHIỆP | ⚠ đề nhắc tới điều này | | ⚠ Ba dạng thái độ | ⚠ NGẠI rủi ro, TRUNG LẬP, và TÌM KIẾM rủi ro |
Vì sao các phương án khác sai
-
B (chấp nhận rủi ro — risk acceptance) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất gần: ⚠ nhưng chấp nhận rủi ro là ⚠ MỘT CHIẾN LƯỢC ỨNG PHÓ cho một rủi ro CỤ THỂ, ⚠ không phải THÁI ĐỘ CHUNG của tổ chức ⚠ (liên hệ #25792 lô 181).
-
D (tỷ số rủi ro trên phần thưởng) — ⚠ một CÁCH ĐO cho một quyết định cụ thể, ⚠ không phải thái độ tổng thể.
-
A (Thuyết động lực của Herzberg) — ⚠ về ĐỘNG LỰC làm việc, ⚠ hoàn toàn không liên quan tới rủi ro.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25983 ở lô 185 (ngưỡng — mốc kích hoạt hành động), câu #26072 lô 186 (kế hoạch quản lý rủi ro chứa ngưỡng chịu đựng), câu #26003 lô 185 (điểm rủi ro), và bộ chiến lược ứng phó ở lô 181–182. ⚠ Nhóm rủi ro nay lên MƯỜI BA câu — và đây là câu duy nhất về THÁI ĐỘ với rủi ro.
⚠ BA dạng thái độ với rủi ro: | Dạng | Đặc điểm | Hệ quả cho dự án | |---|---|---| | ⚠ NGẠI RỦI RO (risk-averse) | ⚠ ưu tiên chắc chắn hơn cơ hội lớn | ⚠ dự phòng cao, ít thử nghiệm — liên hệ #25912 lô 183 | | ⚠ TRUNG LẬP (risk-neutral) | ⚠ quyết theo giá trị kỳ vọng thuần tuý | ⚠ dùng EMV làm căn cứ chính | | ⚠ TÌM KIẾM RỦI RO (risk-seeking) | ⚠ chấp nhận bất định cao để đổi lấy lợi ích lớn | ⚠ dám thử công nghệ mới | | ⚠ Vì sao PM phải biết | ⚠ cùng một rủi ro, hai tổ chức khác khẩu vị sẽ chọn hai chiến lược ứng phó khác nhau | | ⚠ Ghi ở đâu | ⚠ KẾ HOẠCH QUẢN LÝ RỦI RO, mục ngưỡng chịu đựng — liên hệ #26072 lô 186 |
Từ khoá nhận diện:
"mức chịu đựng rủi ro của tổ chức" → ⚠ hàm hữu dụng "chiến lược cho một rủi ro cụ thể" → ⚠ chấp nhận, né tránh, giảm nhẹ, chuyển giao "mốc định lượng để hành động" → ⚠ ngưỡng "động lực làm việc" → ⚠ Herzberg — nhóm khái niệm khác hoàn toàn
| ⚠ Ba khái niệm hay lẫn về thái độ rủi ro | Phân biệt |
|---|---|
| ⚠ KHẨU VỊ RỦI RO (appetite) | ⚠ mức bất định tổ chức SẴN SÀNG chấp nhận để theo đuổi mục tiêu |
| ⚠ MỨC CHỊU ĐỰNG (tolerance) | ⚠ mức sai lệch CỤ THỂ chấp nhận được |
| ⚠ NGƯỠNG (threshold) | ⚠ con số ranh giới kích hoạt hành động — liên hệ #25983 lô 185 |
| ⚠ Quan hệ | ⚠ khẩu vị là TRIẾT LÝ, chịu đựng là MỨC ĐỘ, ngưỡng là CON SỐ |
| ⚠ Ví dụ | ⚠ khẩu vị: "chúng ta thận trọng" → chịu đựng: "vượt chi tối đa 5%" → ngưỡng: "CPI dưới 0,95 thì báo cáo" |
| ⚠ Franz cần làm gì với thông tin này | Việc |
|---|---|
| ⚠ Ghi mức chịu đựng vào KẾ HOẠCH QUẢN LÝ RỦI RO | |
| ⚠ Dùng nó để định nghĩa thang xác suất và tác động | ⚠ "tác động cao" với tổ chức này nghĩa là bao nhiêu tiền |
| ⚠ Chọn chiến lược ứng phó phù hợp với khẩu vị | ⚠ tổ chức ngại rủi ro thì nghiêng về né tránh và chuyển giao |
| ⚠ Đặt ngưỡng báo cáo và leo thang | |
| ⚠ Vì sao phải hỏi NHÀ TÀI TRỢ | ⚠ khẩu vị rủi ro là quyết định ở tầm tổ chức, không phải của quản lý dự án |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết khẩu vị rủi ro của tổ chức mình không | | | Kế hoạch rủi ro của bạn có ghi ngưỡng bằng CON SỐ không | ⚠ không có thì mỗi người đánh giá một kiểu | | Chiến lược ứng phó của bạn có khớp với khẩu vị đó không | |
Và lý do phải hỏi câu này ngay từ đầu dự án: cùng một rủi ro, một tổ chức mua bảo hiểm còn tổ chức khác chấp nhận và bỏ qua — và cả hai đều đúng, tuỳ theo họ là ai.
- A A scrum master should have a servant leader mindset. Their role is to ensure the project team has everything they need to be successful, and they ensure that there are no roadblocks preventing project work from being completed.
- B The role of the scrum master is to lead the project team by removing roadblocks and barriers.
- C A scrum master is not a leader on the project. Instead, the scrum master's role is to manage the projects and ensure timely task completion and customer satisfaction.
- D A scrum master should set an example for the project team displaying how tasks and assignments should be completed.
Xem giải thích
Đáp án
A — Scrum Master cần có tư duy LÃNH ĐẠO PHỤC VỤ: bảo đảm đội có mọi thứ cần để thành công, và không còn vật cản nào ngăn công việc.
Vì sao đúng
⚠ Vì sao phương án này đầy đủ nhất: | Thành phần | Nội dung | |---|---| | ⚠ Nêu đúng TƯ DUY: lãnh đạo phục vụ | ⚠ khái niệm nền tảng | | ⚠ Nêu MỤC ĐÍCH: đội có mọi thứ cần để thành công | ⚠ chủ động tạo điều kiện | | ⚠ Nêu HÀNH ĐỘNG: gỡ vật cản | | | ⚠ Bao gồm CẢ ba tầng: tư duy, mục đích, hành động | ⚠ ba phương án còn lại chỉ có một phần hoặc sai hẳn | | ⚠ Định nghĩa | ⚠ lãnh đạo phục vụ đặt NHU CẦU CỦA ĐỘI lên trước, và đo thành công bằng sự trưởng thành của đội |
Vì sao các phương án khác sai
-
B (vai trò của Scrum Master là dẫn dắt đội bằng cách gỡ vật cản và rào cản) — ⚠ phương án gây nhiễu mạnh nhất vì HOÀN TOÀN ĐÚNG về mặt sự việc: ⚠ nhưng nó ⚠ CHỈ NÊU MỘT HÀNH ĐỘNG, không nêu TƯ DUY ⚠ — câu hỏi hỏi về ⚠ PHẨM CHẤT LÃNH ĐẠO, ⚠ và gỡ vật cản chỉ là một biểu hiện của lãnh đạo phục vụ.
-
D (làm gương cho đội về cách hoàn thành công việc) — ⚠ nhầm vai: ⚠ Scrum Master ⚠ KHÔNG phải người làm mẫu công việc kỹ thuật ⚠ (liên hệ #25936 lô 184 — không nhảy vào code thay đội).
-
C (Scrum Master không phải người lãnh đạo, mà quản lý dự án và bảo đảm hoàn thành đúng hạn) — ⚠ SAI HOÀN TOÀN: ⚠ Scrum Master ⚠ LÀ người lãnh đạo — chỉ là lãnh đạo theo cách phục vụ; ⚠ và anh ta không quản lý tiến độ theo kiểu chỉ huy.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25952 ở lô 184 (Carol ghi nhận, lo công cụ, lo lương thưởng, tổ chức ăn mừng → lãnh đạo phục vụ) — ⚠ hai câu cùng khoá, khoá NHẤT QUÁN. ⚠ Xem thêm câu #25922 lô 183 (lãnh đạo agile thừa nhận sai lầm), câu #26030 lô 185 (Rose tin tưởng đội tự tổ chức), và câu #26146/#26173 ở lô này (huấn luyện).
⚠ Đặc điểm của lãnh đạo phục vụ: | Đặc điểm | Biểu hiện trong vai Scrum Master | |---|---| | ⚠ LẮNG NGHE | ⚠ liên hệ #25925 lô 183 — nghe đồng cảm | | ⚠ ĐỒNG CẢM | | | ⚠ CHỮA LÀNH quan hệ trong đội | ⚠ điều phối xung đột — liên hệ bộ sáu câu xung đột | | ⚠ NHẬN THỨC về mình và môi trường | | | ⚠ THUYẾT PHỤC thay vì áp đặt | ⚠ liên hệ #26161 cùng lô — không dùng quyền lực cưỡng chế | | ⚠ PHÁT TRIỂN con người | ⚠ huấn luyện — liên hệ #26173 cùng lô | | ⚠ XÂY DỰNG cộng đồng | | | ⚠ Câu hỏi tự kiểm | ⚠ "đội có làm việc tốt hơn nhờ có mình không, hay chỉ là báo cáo đẹp hơn?" |
Từ khoá nhận diện:
"bảo đảm đội có mọi thứ cần, gỡ vật cản" → ⚠ lãnh đạo phục vụ "chỉ gỡ vật cản" → ⚠ một hành động, chưa phải tư duy "làm gương về cách hoàn thành công việc" → ⚠ sai vai — SM không làm kỹ thuật thay đội "không phải lãnh đạo, chỉ quản lý tiến độ" → ⚠ sai hoàn toàn về vai trò
| ⚠ Ba vai trò phục vụ của Scrum Master | Với ai |
|---|---|
| ⚠ Với ĐỘI PHÁT TRIỂN | ⚠ huấn luyện tự tổ chức, gỡ vật cản, điều phối sự kiện |
| ⚠ Với PRODUCT OWNER | ⚠ giúp quản trị backlog, kỹ thuật xếp ưu tiên |
| ⚠ Với TỔ CHỨC | ⚠ dẫn dắt chuyển đổi agile, giáo dục bên liên quan — liên hệ #26170 cùng lô |
| ⚠ Vai trò khó nhất | ⚠ vai trò thứ ba — và cũng là vai trò ít người làm đủ (liên hệ #26118 cùng lô, agile cục bộ) |
| ⚠ Scrum Master KHÔNG làm gì | Không làm |
|---|---|
| ⚠ KHÔNG phân việc cho đội | ⚠ đội tự kéo việc — liên hệ #26014 lô 185 |
| ⚠ KHÔNG quyết định kỹ thuật thay đội | ⚠ liên hệ #25919 lô 183 |
| ⚠ KHÔNG quyết nội dung backlog | ⚠ đó là product owner — liên hệ #26041 lô 186 |
| ⚠ KHÔNG viết mã thay đội khi thiếu người | ⚠ liên hệ #25936 lô 184 |
| ⚠ KHÔNG đánh giá hiệu suất cá nhân | |
| ⚠ Điều dễ hiểu sai nhất | ⚠ "phục vụ" không có nghĩa là làm mọi việc vặt cho đội — nó nghĩa là gỡ những thứ đội không tự gỡ được |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có tự tổ chức được không | ⚠ thước đo của lãnh đạo phục vụ | | Bạn dành bao nhiêu thời gian gỡ vật cản so với thời gian họp | | | Nếu bạn nghỉ một tuần, đội có chạy được không | ⚠ câu hỏi thẳng thắn nhất |
Và điều phân biệt lãnh đạo phục vụ với lãnh đạo truyền thống, gói trong một câu hỏi: người truyền thống hỏi "đội có làm theo tôi không"; người phục vụ hỏi "đội có cần tôi ít hơn năm ngoái không".
- A Defining scope affects all aspects of the project work.
- B Refer the stakeholder to organizational process assets.
- C The scope must be locked in during the planning stage.
- D Invite the stakeholder to the next team meeting.
Xem giải thích
Đáp án
A — Việc XÁC ĐỊNH PHẠM VI ẢNH HƯỞNG TỚI MỌI MẶT của công việc dự án.
Vì sao đúng
⚠ Vì sao phạm vi ảnh hưởng tới mọi thứ: | Lĩnh vực | Phụ thuộc vào phạm vi thế nào | |---|---| | ⚠ LỊCH TRÌNH | ⚠ không biết làm gì thì không ước lượng được mất bao lâu | | ⚠ CHI PHÍ | ⚠ ngân sách tính từ khối lượng công việc | | ⚠ NGUỒN LỰC | ⚠ cần kỹ năng gì phụ thuộc vào làm gì | | ⚠ CHẤT LƯỢNG | ⚠ tiêu chuẩn áp cho cái gì | | ⚠ RỦI RO | ⚠ rủi ro gắn với công việc cụ thể | | ⚠ MUA SẮM | ⚠ mua gì phụ thuộc vào tự làm phần nào | | ⚠ Kết luận | ⚠ phạm vi là NỀN MÓNG — mọi kế hoạch khác xây trên nó |
Vì sao các phương án khác sai
-
C (phạm vi phải được KHOÁ CỨNG trong giai đoạn lập kế hoạch) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như lý do chính đáng để làm kỹ: ⚠ nhưng ⚠ SAI VỀ NGUYÊN TẮC ⚠ — phạm vi ⚠ CÓ THỂ THAY ĐỔI qua kiểm soát thay đổi ⚠ (liên hệ #26023 lô 185); ⚠ nói "khoá cứng" là hiểu sai quản lý phạm vi.
-
D (mời bên liên quan tới buổi họp đội tiếp theo) — ⚠ né câu hỏi; ⚠ họ hỏi VÌ SAO, không hỏi xin dự họp.
-
B (chỉ họ tới tài sản quy trình của tổ chức) — ⚠ đẩy việc giải thích; ⚠ và tài sản quy trình không trả lời câu hỏi cụ thể này.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #26007 ở lô 185 (Joey viết mô tả phạm vi sản phẩm để chặn trượt phạm vi), câu #26039 lô 186 (phân tích sản phẩm), câu #26017 lô 185 (vì sao cần WBS), và câu #26049 lô 186 (thứ tự lập kế hoạch). ⚠ Nhóm quản lý phạm vi.
⚠ Phạm vi là ĐẦU VÀO của những gì: | Tài liệu | Cần phạm vi để làm gì | |---|---| | ⚠ WBS | ⚠ phân rã phạm vi thành gói công việc — liên hệ #26017 lô 185 | | ⚠ DANH SÁCH HOẠT ĐỘNG | ⚠ từ WBS ra hoạt động — liên hệ #26049 lô 186 | | ⚠ ƯỚC LƯỢNG chi phí và thời lượng | | | ⚠ KẾ HOẠCH NGUỒN LỰC | | | ⚠ SỔ RỦI RO | ⚠ rủi ro của công việc cụ thể | | ⚠ KẾ HOẠCH MUA SẮM | ⚠ make-or-buy — liên hệ #25996 lô 185 | | ⚠ Hệ quả | ⚠ sai phạm vi thì SAI TOÀN BỘ chuỗi kế hoạch phía sau |
Từ khoá nhận diện:
"vì sao phải xác định phạm vi kỹ" → ⚠ vì nó ảnh hưởng tới mọi mặt "phạm vi phải khoá cứng" → ⚠ sai — phạm vi đổi được qua kiểm soát thay đổi "chỉ sang tài liệu khác" → ⚠ né câu hỏi "mời dự họp" → ⚠ không trả lời điều họ hỏi
| ⚠ Trả lời bên liên quan sốt ruột thế nào cho hiệu quả | Cách |
|---|---|
| ⚠ GHI NHẬN sự sốt ruột — họ muốn thấy kết quả, đó là điều tốt | |
| ⚠ Giải thích bằng HẬU QUẢ CỤ THỂ | ⚠ "nếu bắt đầu mà chưa rõ phạm vi, ta có thể xây thứ phải bỏ đi" |
| ⚠ Nêu chi phí thay đổi tăng theo thời gian | ⚠ liên hệ #26062 lô 186 — hai đường cong |
| ⚠ Cho họ mốc cụ thể: bao giờ xong việc lập kế hoạch | ⚠ sốt ruột giảm khi có ngày cụ thể |
| ⚠ Nếu áp lực thật sự lớn | ⚠ cân nhắc cách tiếp cận LAI hoặc THÍCH ỨNG để giao giá trị sớm — liên hệ #26029 lô 185 |
| ⚠ Nhưng cẩn thận: "xác định kỹ" KHÔNG có nghĩa là "khoá cứng" | Lưu ý |
|---|---|
| ⚠ Phạm vi ĐƯỢC PHÉP thay đổi — qua kiểm soát thay đổi | ⚠ liên hệ #26023 lô 185 và #26101 lô 187 |
| ⚠ Trong dự án thích ứng, phạm vi được làm rõ DẦN | ⚠ liên hệ #25994 lô 185 |
| ⚠ Điều phải tránh là phạm vi phình ra mà KHÔNG AI DUYỆT | ⚠ trượt phạm vi — liên hệ #26007 lô 185 |
| ⚠ Ranh giới | ⚠ XÁC ĐỊNH RÕ để biết mình đang ở đâu; KIỂM SOÁT THAY ĐỔI để biết mình đi đâu — hai việc khác nhau |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phạm vi của bạn có đủ rõ để lập WBS không | | | Bên liên quan có hiểu vì sao giai đoạn lập kế hoạch cần thời gian không | | | Bạn có mốc cụ thể cho việc hoàn tất lập kế hoạch không | ⚠ sốt ruột thường đến từ việc không thấy điểm kết |
Và câu trả lời ngắn nhất Gerald có thể đưa: "mỗi giờ chúng ta bỏ ra để làm rõ phạm vi hôm nay tiết kiệm nhiều ngày làm lại về sau — và đó là những ngày anh sẽ phải chờ, chứ không phải tôi."
- A As long as every impediment is recorded in the impediment backlog, they will all get addressed.
- B The product owner is responsible for addressing each impediment.
- C Ask what the status of the impediment is at every daily standup meeting.
- D Ensure that each impediment is assigned an impediment owner who is responsible for addressing it.
Xem giải thích
Đáp án
D — Bảo đảm mỗi vật cản được GÁN MỘT NGƯỜI PHỤ TRÁCH chịu trách nhiệm xử lý nó.
Vì sao đúng
⚠ Vì sao phải có người phụ trách: | Lý do | Nội dung | |---|---| | ⚠ Vật cản KHÔNG CÓ CHỦ thì không ai gỡ | ⚠ "ai cũng lo" nghĩa là không ai lo | | ⚠ Có tên người thì có TRÁCH NHIỆM GIẢI TRÌNH | | | ⚠ Theo dõi được tiến độ gỡ | ⚠ hỏi ai, hỏi cái gì | | ⚠ Người phụ trách KHÔNG nhất thiết là Scrum Master | ⚠ có thể là người ở vị trí gỡ được nhanh nhất | | ⚠ Kèm theo | ⚠ phải có HẠN xử lý, không thì vẫn treo mãi |
Vì sao các phương án khác sai
-
B (ghi mọi vật cản vào NHẬT KÝ VẬT CẢN) — ⚠ phương án gây nhiễu mạnh nhất vì đây là ⚠ thực hành hoàn toàn đúng và thường làm trước: ⚠ nhưng ⚠ GHI LẠI ≠ GIẢI QUYẾT ⚠ — một nhật ký đầy vật cản không có chủ vẫn không gỡ được cái nào; ⚠ gán người phụ trách là bước biến danh sách thành hành động.
-
A (dành thời gian mỗi ngày họp riêng về vật cản) — ⚠ thêm họp; ⚠ vật cản đã được nêu ở họp đứng hằng ngày rồi ⚠ (liên hệ #26093 lô 187).
-
C (leo thang mọi vật cản lên quản lý cấp trên) — ⚠ SAI: ⚠ chỉ leo thang cái đội không tự gỡ được; ⚠ leo thang mọi thứ làm đội mất khả năng tự tổ chức.
Ghi nhớ
⚠ Đối chiếu — nhóm vật cản nay ba câu: ⚠ #26093 lô 187 (nêu vật cản ở họp đứng hằng ngày), ⚠ #26169 ở lô này (gờ giảm tốc KHÔNG phải vật cản — nó là điều kiện cố định), ⚠ và câu này (vật cản phải có chủ). ⚠ Ba câu, ba khoá, nhất quán và bổ sung cho nhau.
⚠ Vòng đời một vật cản: | Bước | Việc | Ai | |---|---|---| | ⚠ 1. PHÁT HIỆN | ⚠ thường ở họp đứng hằng ngày | ⚠ thành viên đội | | ⚠ 2. GHI vào nhật ký vật cản | ⚠ phương án B — cần nhưng chưa đủ | ⚠ Scrum Master | | ⚠ 3. GÁN NGƯỜI PHỤ TRÁCH và hạn | ⚠ CÂU NÀY — bước biến ghi chép thành hành động | ⚠ Scrum Master điều phối | | ⚠ 4. GỠ | ⚠ người phụ trách làm | | | ⚠ 5. LEO THANG nếu quá hạn hoặc ngoài tầm đội | ⚠ phương án C — chỉ dùng cho trường hợp này | | | ⚠ 6. ĐÓNG và ghi bài học nếu có | ⚠ liên hệ #26175 cùng lô | | | ⚠ Chỗ hay đứt gãy nhất | ⚠ giữa bước 2 và bước 3 |
Từ khoá nhận diện:
"bảo đảm vật cản được XỬ LÝ" → ⚠ gán người phụ trách "ghi vào nhật ký" → ⚠ cần thiết nhưng chưa đủ để gỡ "họp riêng mỗi ngày" → ⚠ thêm họp thừa "leo thang MỌI vật cản" → ⚠ quá tay, làm mất tự tổ chức
| ⚠ Nhật ký vật cản nên có cột gì | Cột |
|---|---|
| ⚠ Mô tả vật cản | |
| ⚠ Ngày phát hiện | ⚠ để thấy cái nào treo lâu |
| ⚠ NGƯỜI PHỤ TRÁCH | ⚠ cột quan trọng nhất — câu này hỏi đúng nó |
| ⚠ Hạn xử lý | |
| ⚠ Trạng thái và ghi chú | |
| ⚠ Chỉ số đáng theo dõi | ⚠ TUỔI TRUNG BÌNH của vật cản đang mở — tăng dần là dấu hiệu xấu |
| ⚠ Phân biệt vật cản với ba thứ hay bị nhầm | Phân biệt |
|---|---|
| ⚠ VẬT CẢN (impediment) | ⚠ cái CHẶN công việc, GỠ ĐƯỢC |
| ⚠ ĐIỀU KIỆN CỐ ĐỊNH | ⚠ không gỡ được, phải sống chung — liên hệ #26169 cùng lô |
| ⚠ RỦI RO | ⚠ CHƯA xảy ra — vật cản là đã xảy ra rồi |
| ⚠ VẤN ĐỀ (issue) | ⚠ thuật ngữ dự đoán; "vật cản" là thuật ngữ agile cho cùng ý |
| ⚠ Câu hỏi phân loại nhanh | ⚠ "nếu cái này biến mất, đội có làm việc nhanh hơn không?" — có thì là vật cản |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký vật cản của bạn có cột người phụ trách không | | | Vật cản cũ nhất đang mở bao nhiêu ngày rồi | ⚠ con số này nói nhiều điều | | Có vật cản nào đang chờ mà không ai biết đang chờ ai không | |
Và điều làm nên khác biệt giữa một Scrum Master ghi chép và một Scrum Master gỡ việc: người thứ hai kết thúc mỗi buổi họp đứng với một danh sách tên người, không phải một danh sách vấn đề.
- A Metrics that will be used and the rationale for using them
- B Process for preparing a project scope statement.
- C A process that enables the creation of the WBS from the detailed project scope statement
- D A process that establishes how the scope baseline will be approved and maintained.
Xem giải thích
Đáp án
A — "Các CHỈ SỐ sẽ dùng và LÝ DO dùng chúng" KHÔNG phải là thành phần của kế hoạch quản lý phạm vi.
Vì sao đúng
⚠ Kế hoạch quản lý PHẠM VI gồm gì: | Thành phần | Nội dung | |---|---| | ⚠ Cách CHUẨN BỊ mô tả phạm vi dự án | | | ⚠ Cách LẬP WBS từ mô tả phạm vi chi tiết | ⚠ phương án hợp lệ | | ⚠ Cách DUY TRÌ và PHÊ DUYỆT đường cơ sở phạm vi | ⚠ phương án hợp lệ | | ⚠ Cách NGHIỆM THU chính thức các bàn giao đã hoàn thành | ⚠ phương án hợp lệ | | ⚠ Còn "chỉ số và lý do dùng" | ⚠ thuộc kế hoạch quản lý YÊU CẦU, không phải phạm vi |
Vì sao các phương án khác sai — ba phương án còn lại ĐỀU hợp lệ
- B (cách lập WBS từ mô tả phạm vi chi tiết) — ⚠ THÀNH PHẦN HỢP LỆ.
- C (cách duy trì và phê duyệt đường cơ sở phạm vi) — ⚠ THÀNH PHẦN HỢP LỆ.
- D (cách nghiệm thu chính thức các bàn giao đã hoàn thành) — ⚠ THÀNH PHẦN HỢP LỆ, ⚠ liên hệ #25977 lô 185 (tiêu chí nghiệm thu).
Ghi nhớ về chất lượng câu hỏi
⚠ Đối chiếu quan trọng với câu #26110 ở lô 187: ⚠ câu đó hỏi thành phần của KẾ HOẠCH QUẢN LÝ YÊU CẦU, ⚠ và "các chỉ số sẽ dùng và lý do dùng chúng" LÀ một thành phần HỢP LỆ ở đó. ⚠ Cùng một cụm từ, hai câu, hai kết luận trái ngược — nhưng KHÔNG mâu thuẫn, ⚠ vì đó là hai kế hoạch phụ KHÁC NHAU:
| Kế hoạch | "Chỉ số và lý do dùng" | Vì sao |
|---|---|---|
| ⚠ Kế hoạch quản lý YÊU CẦU | ⚠ CÓ — #26110 lô 187 | ⚠ cần chỉ số cho ma trận truy vết yêu cầu |
| ⚠ Kế hoạch quản lý PHẠM VI | ⚠ KHÔNG — câu này | ⚠ nói về QUY TRÌNH lập và kiểm soát phạm vi |
| ⚠ Bẫy | ⚠ thí sinh nhớ mang máng "hình như có thấy cụm này ở đâu đó" rồi chọn sai | |
| ⚠ Cách nhớ | ⚠ PHẠM VI nói QUY TRÌNH; YÊU CẦU nói CÁCH ĐO và TRUY VẾT |
Ghi nhớ
⚠ Bốn thành phần của kế hoạch quản lý phạm vi — nhớ theo VÒNG ĐỜI: | Thứ tự | Thành phần | |---|---| | ⚠ 1. Chuẩn bị MÔ TẢ PHẠM VI | ⚠ liên hệ bộ sáu câu về bốn mục của mô tả phạm vi | | ⚠ 2. Lập WBS | ⚠ liên hệ #26017 lô 185 | | ⚠ 3. Duy trì và phê duyệt ĐƯỜNG CƠ SỞ | ⚠ liên hệ #26023 lô 185 — đổi phải qua kiểm soát thay đổi | | ⚠ 4. NGHIỆM THU bàn giao | ⚠ liên hệ #25977 lô 185 | | ⚠ Mẹo nhớ | ⚠ MÔ TẢ → PHÂN RÃ → GIỮ → NGHIỆM THU |
Từ khoá nhận diện:
"chỉ số và lý do dùng" → ⚠ kế hoạch quản lý YÊU CẦU, không phải phạm vi "cách lập WBS" → ⚠ kế hoạch quản lý phạm vi "duy trì đường cơ sở phạm vi" → ⚠ kế hoạch quản lý phạm vi "nghiệm thu bàn giao" → ⚠ kế hoạch quản lý phạm vi
| ⚠ Kế hoạch quản lý YÊU CẦU gồm gì — để phân biệt | Thành phần |
|---|---|
| ⚠ Cách lập kế hoạch, theo dõi và báo cáo hoạt động yêu cầu | |
| ⚠ Cách quản lý cấu hình — thay đổi yêu cầu được khởi tạo và duyệt thế nào | |
| ⚠ Quy trình XẾP ƯU TIÊN yêu cầu | ⚠ liên hệ #26149 cùng lô |
| ⚠ CÁC CHỈ SỐ và lý do dùng chúng | ⚠ CHÍNH LÀ #26110 lô 187 |
| ⚠ Cấu trúc TRUY VẾT — thuộc tính nào ghi vào ma trận | ⚠ liên hệ #26095 lô 187 |
| ⚠ Điểm chung | ⚠ kế hoạch yêu cầu nói về ĐO và TRUY VẾT; kế hoạch phạm vi nói về LẬP và GIỮ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có tách kế hoạch phạm vi và kế hoạch yêu cầu không | ⚠ nhiều nơi gộp làm một — chấp nhận được, nhưng thi thì phải phân biệt | | Kế hoạch phạm vi có nói rõ ai nghiệm thu bàn giao không | | | Đường cơ sở phạm vi của bạn thay đổi được qua đường nào | ⚠ phải là kiểm soát thay đổi, không phải sửa lặng lẽ |
Và mẹo phân biệt gọn nhất khi gặp cả hai kế hoạch trong một đề: hỏi "câu này nói về CÔNG VIỆC hay về ĐIỀU KHÁCH HÀNG YÊU CẦU?" — công việc thì là phạm vi, yêu cầu thì là yêu cầu.
- A The inappropriate intrusion of the product owner
- B Too much focus on a given scenario
- C A lack of communication in their daily standup meetings
- D Issues with a focus on the features that users will find valuable
Xem giải thích
Đáp án
D — Persona giúp đội nhìn vấn đề với trọng tâm là NHỮNG TÍNH NĂNG MÀ NGƯỜI DÙNG THẤY CÓ GIÁ TRỊ.
Vì sao đúng
⚠ Persona làm gì: | Tác dụng | Nội dung | |---|---| | ⚠ Là NHÂN VẬT HƯ CẤU đại diện một nhóm người dùng thật | ⚠ có tên, nghề, mục tiêu, nỗi bực | | ⚠ Buộc đội đặt câu hỏi "NGƯỜI NÀY cần gì" | ⚠ thay vì "chúng ta xây được gì" | | ⚠ Kéo trọng tâm về GIÁ TRỊ NGƯỜI DÙNG THẤY | ⚠ đúng đáp án | | ⚠ Giúp xếp ưu tiên backlog | ⚠ tính năng nào phục vụ persona chính thì lên trước | | ⚠ Bản chất | ⚠ công cụ ĐỒNG CẢM — liên hệ #26157 CÙNG LÔ |
Vì sao các phương án khác sai
-
B (giúp đội hiểu người dùng của sản phẩm là ai) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hoàn toàn đúng: ⚠ nhưng đó là ⚠ BƯỚC ĐẦU, chưa phải MỤC ĐÍCH; ⚠ biết họ là ai để làm gì? ⚠ để xây đúng thứ họ thấy có giá trị — ⚠ phương án D đi tới đích, B mới đi nửa đường.
-
A (giúp đội ước lượng chính xác hơn) — ⚠ persona không phải công cụ ước lượng.
-
C (giúp xác định các bên liên quan của dự án) — ⚠ nhầm với PHÂN TÍCH BÊN LIÊN QUAN; ⚠ persona là ĐẠI DIỆN HƯ CẤU, ⚠ bên liên quan là người THẬT ⚠ (liên hệ #26151 cùng lô).
Ghi nhớ
⚠ Đối chiếu — CẶP PERSONA TRONG CÙNG LÔ NÀY: ⚠ câu #26157 hỏi persona là công cụ gì → ĐỒNG CẢM; ⚠ câu này hỏi persona giúp gì → nhìn theo giá trị người dùng. ⚠ Hai câu bổ sung nhau, khoá NHẤT QUÁN. ⚠ Xem thêm câu #26041 lô 186 (product owner đại diện tiếng nói khách hàng) và #26149 cùng lô (xếp ưu tiên tương đối).
⚠ Một persona tốt gồm gì: | Thành phần | Ví dụ | |---|---| | ⚠ TÊN và ảnh | ⚠ "Julie, 34 tuổi" — làm nhân vật có thật trong đầu đội | | ⚠ BỐI CẢNH: nghề, môi trường, mức thạo công nghệ | | | ⚠ MỤC TIÊU: họ muốn đạt được gì | ⚠ phần quan trọng nhất | | ⚠ NỖI BỰC: điều gì đang cản họ | ⚠ nguồn ý tưởng tính năng | | ⚠ HÀNH VI: họ dùng sản phẩm khi nào, ở đâu | | | ⚠ Sai lầm phổ biến | ⚠ bịa persona từ trí tưởng tượng thay vì từ phỏng vấn người dùng thật |
Từ khoá nhận diện:
"persona giúp gì" → ⚠ nhìn theo giá trị người dùng thấy "persona là công cụ gì" → ⚠ đồng cảm — #26157 cùng lô "hiểu người dùng là ai" → ⚠ đúng nhưng mới nửa đường "xác định bên liên quan" → ⚠ nhầm sang phân tích bên liên quan
| ⚠ Persona dùng ở đâu trong dự án thích ứng | Chỗ dùng |
|---|---|
| ⚠ Viết CÂU CHUYỆN NGƯỜI DÙNG | ⚠ "Là Julie, tôi muốn... để..." — persona chính là phần "Là" |
| ⚠ XẾP ƯU TIÊN backlog | ⚠ tính năng phục vụ persona chính lên trước |
| ⚠ Thiết kế giao diện | |
| ⚠ Quyết định phạm vi MVP | ⚠ cái gì persona cần NGAY |
| ⚠ Giải quyết tranh cãi trong đội | ⚠ "Julie có cần cái này không?" thường kết thúc tranh cãi nhanh hơn ý kiến cá nhân |
| ⚠ Giá trị thật | ⚠ biến câu hỏi "ai đúng" thành câu hỏi "người dùng cần gì" |
| ⚠ Persona KHÁC bên liên quan thế nào | Phân biệt |
|---|---|
| ⚠ PERSONA — nhân vật HƯ CẤU đại diện một NHÓM người dùng | ⚠ không mời họp được |
| ⚠ BÊN LIÊN QUAN — người hoặc tổ chức THẬT | ⚠ có tên, ghi vào sổ đăng ký, phải gắn kết |
| ⚠ Giao nhau | ⚠ người dùng cuối vừa là bên liên quan thật vừa là gốc của persona |
| ⚠ Đừng nhầm | ⚠ sổ đăng ký bên liên quan ghi NGƯỜI THẬT, không ghi persona |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Persona của đội bạn dựng từ dữ liệu thật hay từ tưởng tượng | | | Đội có nhắc tên persona trong các buổi họp không | ⚠ có nghĩa là persona đang sống, không nằm trong tài liệu | | Có tính năng nào trong backlog không phục vụ persona nào không | ⚠ câu hỏi này thường lọc ra vài thứ đáng bỏ |
Và câu hỏi ngắn nhất để kiểm tra một persona có ích hay không: nếu bỏ tên và ảnh đi mà đội vẫn quyết như cũ, thì persona đó chưa làm được việc gì.
As a seasoned project manager, you can carefully craft and establish your project's performance measurement baseline to compare real-time values to it. In your current project, you use EVM to evaluate your schedule and cost performance and collect data throughout the project. You are engaged in analyzing the data collected and have graphed the results to determine the status. Based on this information, what can you gather about the performance of your project on week six?
- A The project is behind schedule and over budget.
- B The project is behind schedule and under budget.
- C The project is ahead of schedule and over budget.
- D The project is ahead of schedule and under budget.
Xem giải thích
Đáp án
A — Dự án đang CHẬM TIẾN ĐỘ và VƯỢT CHI PHÍ.
Vì sao đúng
⚠ Đọc đồ thị giá trị thu được — ba đường: | Đường | Ý nghĩa | |---|---| | ⚠ PV (giá trị kế hoạch) | ⚠ giá trị công việc LẼ RA phải hoàn thành tới thời điểm này | | ⚠ EV (giá trị thu được) | ⚠ giá trị công việc THỰC SỰ đã hoàn thành | | ⚠ AC (chi phí thực tế) | ⚠ tiền THỰC SỰ đã chi | | ⚠ Quy tắc đọc | ⚠ EV nằm DƯỚI PV → chậm tiến độ; AC nằm TRÊN EV → vượt chi | | ⚠ Hình trong đề | ⚠ EV thấp nhất, AC cao nhất → CẢ HAI đều xấu → đáp án A |
Vì sao các phương án khác sai
- C (đúng tiến độ nhưng vượt chi) — ⚠ chỉ đúng NỬA: ⚠ đòi EV trùng PV, ⚠ hình không cho thấy vậy.
- B (chậm tiến độ nhưng dưới ngân sách) — ⚠ đòi AC nằm DƯỚI EV, ⚠ ngược với hình.
- D (đúng tiến độ và đúng ngân sách) — ⚠ đòi cả ba đường trùng nhau.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này dựa hoàn toàn vào ĐỒ THỊ trong đề, và ảnh không đọc được ở dạng văn bản. ⚠ Giải thích này vì thế ⚠ dạy CÁCH ĐỌC đồ thị EVM ⚠ để bạn tự suy ra đáp án khi nhìn thấy hình — ⚠ đây là kỹ năng được hỏi lại rất nhiều lần trong bài thi. ⚠ Cùng dạng với các câu #26135, #26139, #26165 ở lô này.
Ghi nhớ
⚠ Đối chiếu — nhóm giá trị thu được nay lên MƯỜI BỐN câu: ⚠ #25985 lô 185 (SPI 0,80 / CPI 2,29), ⚠ #26065 lô 186 (EAC ≈ 842.700), ⚠ #26121 lô 187 (SV = −62.500), ⚠ #26159 ở lô này (PV = BAC khi đã quá hạn), ⚠ #26172 ở lô này (CPI = 0,98), ⚠ và câu này (đọc đồ thị).
⚠ BẢNG ĐỌC NHANH — dấu của SV và CV: | Chỉ số | Công thức | Âm nghĩa là | Dương nghĩa là | |---|---|---|---| | ⚠ SV = EV − PV | | ⚠ CHẬM tiến độ | ⚠ SỚM tiến độ | | ⚠ CV = EV − AC | | ⚠ VƯỢT chi | ⚠ TIẾT KIỆM | | ⚠ SPI = EV ÷ PV | | ⚠ < 1 là chậm | ⚠ > 1 là sớm | | ⚠ CPI = EV ÷ AC | | ⚠ < 1 là vượt chi | ⚠ > 1 là tiết kiệm | | ⚠ Mẹo nhớ | ⚠ EV luôn đứng ĐẦU cả bốn công thức — nhớ được điều này là không bao giờ lẫn dấu |
⚠ Đọc đồ thị theo VỊ TRÍ TƯƠNG ĐỐI — bốn tình huống: | Hình | Kết luận | |---|---| | ⚠ EV dưới PV, AC trên EV | ⚠ CHẬM và VƯỢT CHI — câu này | | ⚠ EV dưới PV, AC dưới EV | ⚠ CHẬM nhưng TIẾT KIỆM — thường vì làm được ít nên chi ít | | ⚠ EV trên PV, AC trên EV | ⚠ SỚM nhưng VƯỢT CHI — đẩy nhanh bằng tiền | | ⚠ EV trên PV, AC dưới EV | ⚠ SỚM và TIẾT KIỆM — hiếm, đáng nghi ngờ số liệu | | ⚠ Trục | ⚠ ngang là THỜI GIAN, dọc là TIỀN — cả ba đường đều tính bằng TIỀN |
Từ khoá nhận diện:
"EV dưới PV" → ⚠ chậm tiến độ "AC trên EV" → ⚠ vượt chi "cả ba đường trùng nhau" → ⚠ đúng kế hoạch cả hai mặt — rất hiếm trong đề "EV cao nhất" → ⚠ sớm và tiết kiệm
| ⚠ Vì sao PM phải đọc được đồ thị này trong vài giây | Lý do |
|---|---|
| ⚠ Đây là hình xuất hiện trong hầu hết báo cáo tình trạng dự án | |
| ⚠ Nó trả lời hai câu hỏi lãnh đạo luôn hỏi cùng lúc | ⚠ "có kịp không" và "có đủ tiền không" |
| ⚠ Nó cho biết XU HƯỚNG, không chỉ trạng thái | ⚠ khoảng cách giữa các đường ĐANG GIÃN hay ĐANG THU HẸP |
| ⚠ Từ đó dự báo được EAC | ⚠ liên hệ #26065 lô 186 |
| ⚠ Điều nhiều người bỏ sót | ⚠ XU HƯỚNG quan trọng hơn con số tại một thời điểm — một dự án CPI 0,9 đang cải thiện tốt hơn một dự án CPI 0,95 đang xấu đi |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo dự án của bạn có đủ ba đường không | ⚠ thiếu EV thì không nói được gì về hiệu suất | | Bạn nhìn con số tại một thời điểm hay nhìn xu hướng | | | SPI và CPI của dự án bạn tháng này so với tháng trước thế nào | |
Và điều giá trị nhất của đồ thị này, gói trong một câu: nó cho bạn thấy dự án đang đi về đâu từ nhiều tháng trước khi hạn chót đến — đủ sớm để còn làm được gì đó.