Ngân hàng đề — PMP® Mock Exam Set I Exam
Tìm thấy 720 câu.
- A Revise quality metrics.
- B Perform a quality audit.
- C Train the project team in quality principles.
- D Submit a change request.
Xem giải thích
Đáp án
B — Thực hiện một cuộc KIỂM TOÁN CHẤT LƯỢNG (quality audit).
Vì sao đúng
⚠ Kiểm toán chất lượng là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Rà soát CÓ CẤU TRÚC và ĐỘC LẬP | | | ⚠ Kiểm tra hoạt động dự án có tuân theo chính sách và quy trình không | | | ⚠ Xác nhận các phép đo và báo cáo có ĐÚNG và ĐÁNG TIN không | ⚠ đúng điều Natasha nghi ngờ | | ⚠ Phát hiện thực hành tốt và thực hành chưa đạt | | | ⚠ Là công cụ của quy trình Manage Quality | | | ⚠ Kết luận | ⚠ muốn biết báo cáo có hợp lệ không thì phải kiểm tra chính quy trình tạo ra chúng |
Vì sao các phương án khác sai
-
A (sửa lại các thước đo chất lượng) — ⚠ HÀNH ĐỘNG khi chưa biết vấn đề nằm ở đâu; ⚠ thước đo có thể vẫn đúng, chỉ có cách thu thập dữ liệu sai.
-
C (đào tạo đội về nguyên tắc chất lượng) — ⚠ có thể cần NHƯNG chỉ sau khi biết nguyên nhân; ⚠ vấn đề có thể do quy trình chứ không do kiến thức.
-
D (nộp yêu cầu thay đổi) — ⚠ quá sớm: ⚠ chưa biết cần thay đổi gì.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25636 ở lô 178 (phân biệt QA với QC), câu #25823 ở lô 181 (xác minh phiên bản báo cáo trước khi hành động), và câu #25845 ở lô này (đánh giá trước khi hành động). ⚠ Bốn câu cùng một nguyên tắc: xác minh nguyên nhân trước khi sửa.
⚠ Kiểm toán chất lượng kiểm tra những gì: | Nội dung | Chi tiết | |---|---| | ⚠ Quy trình có được tuân thủ không | | | ⚠ Dữ liệu có được thu thập đúng cách không | ⚠ nguồn nghi ngờ chính của Natasha | | ⚠ Thước đo có phản ánh đúng thứ cần đo không | | | ⚠ Có thực hành tốt nào đáng nhân rộng không | | | ⚠ Có khoảng trống hoặc thiếu sót nào không | | | ⚠ Đầu ra | ⚠ yêu cầu thay đổi, cập nhật tài liệu, và bài học kinh nghiệm |
Từ khoá nhận diện:
"nghi ngờ tính hợp lệ của báo cáo" → ⚠ kiểm toán chất lượng "kiểm tra QUY TRÌNH có đúng không" → ⚠ Manage Quality / QA "kiểm tra SẢN PHẨM có đạt không" → ⚠ Control Quality / QC "sửa ngay khi chưa biết nguyên nhân" → ⚠ thường là đáp án sai
⚠ Phân biệt kiểm toán chất lượng với các hoạt động khác: | Hoạt động | Đối tượng | |---|---| | ⚠ Quality AUDIT | ⚠ QUY TRÌNH và HỆ THỐNG chất lượng — CÂU NÀY | | ⚠ Quality CONTROL / inspection | ⚠ SẢN PHẨM và bàn giao cụ thể | | ⚠ Process analysis | ⚠ tìm cơ hội cải tiến quy trình | | ⚠ Design for X | ⚠ tối ưu một khía cạnh khi thiết kế | | ⚠ Kiểm toán thường do | ⚠ bên ĐỘC LẬP thực hiện — có thể là PMO, bộ phận chất lượng, hoặc bên ngoài |
| ⚠ Vì sao Natasha phải làm việc này TRƯỚC khi trình lãnh đạo | Lý do |
|---|---|
| ⚠ Trình bày số liệu sai làm mất uy tín nghiêm trọng | |
| ⚠ Quyết định của lãnh đạo dựa trên số liệu đó | |
| ⚠ Sai số liệu chất lượng có thể dẫn tới sai lầm về sản phẩm | ⚠ dự án SẢN XUẤT — hậu quả vật lý |
| ⚠ Còn một tuần — đủ thời gian để kiểm toán | |
| ⚠ Nguyên tắc nghề nghiệp | ⚠ giá trị TRUNG THỰC trong Quy tắc Đạo đức PMI — không trình bày thông tin mình nghi ngờ là sai |
| ⚠ Sau kiểm toán, tuỳ kết quả mà làm gì | Kết quả |
|---|---|
| ⚠ Nếu báo cáo ĐÚNG: trình bày với sự tự tin | |
| ⚠ Nếu dữ liệu thu thập sai: sửa quy trình thu thập | |
| ⚠ Nếu thước đo sai: sửa thước đo | ⚠ phương án A trở nên đúng ở bước này |
| ⚠ Nếu do thiếu kiến thức: đào tạo đội | ⚠ phương án C ở bước này |
| ⚠ Nếu cần đổi đường cơ sở: nộp yêu cầu thay đổi | ⚠ phương án D ở bước này |
| ⚠ Nhận xét | ⚠ ba phương án sai đều có thể ĐÚNG — nhưng chỉ SAU khi kiểm toán |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tin vào số liệu mình sắp trình bày không | | | Dữ liệu được thu thập thế nào và bởi ai | | | Có bên độc lập nào kiểm tra được không | |
Và nguyên tắc nghề nghiệp đơn giản: đừng bao giờ trình bày số liệu mà chính bạn không tin. Một tuần đủ để kiểm chứng, và uy tín mất đi thì không mua lại được.
- A Scrum-Kanban
- B Scrum-XP
- C Scrum-Traditional
- D Scrum-DSDM
Xem giải thích
Đáp án
B — Scrum-XP.
Vì sao đúng
⚠ Vì sao Scrum-XP phù hợp: | Nhu cầu của Deborah | XP đáp ứng thế nào | |---|---| | ⚠ LẬP TRÌNH CẶP — paired programming | ⚠ đây là một thực hành CỐT LÕI của XP | | ⚠ QUẢN TRỊ KỸ THUẬT tốt hơn | ⚠ XP là khung tập trung mạnh nhất vào KỸ THUẬT | | ⚠ Đội đã rất thành thạo agile | ⚠ đủ trưởng thành để áp dụng thực hành kỹ thuật nghiêm ngặt | | ⚠ Kết luận | ⚠ Scrum lo QUẢN LÝ, XP lo KỸ THUẬT — kết hợp là mô hình rất phổ biến |
⚠ Các thực hành cốt lõi của XP — Extreme Programming: | Thực hành | Nội dung | |---|---| | ⚠ Pair programming | ⚠ hai người cùng viết mã — điều Deborah muốn | | ⚠ Test-Driven Development (TDD) | ⚠ viết kiểm thử trước, viết mã sau | | ⚠ Continuous integration | ⚠ tích hợp liên tục nhiều lần mỗi ngày | | ⚠ Refactoring | ⚠ cải thiện cấu trúc mã mà không đổi hành vi | | ⚠ Simple design | ⚠ thiết kế đơn giản nhất có thể | | ⚠ Collective code ownership | ⚠ cả đội cùng sở hữu mã | | ⚠ Coding standards | ⚠ chuẩn viết mã chung | | ⚠ Sustainable pace | ⚠ nhịp làm việc bền vững | | ⚠ On-site customer | ⚠ khách hàng ngồi cùng đội | | ⚠ Small releases | ⚠ phát hành nhỏ và thường xuyên |
Vì sao các phương án khác sai
-
A (Scrum-Kanban / Scrumban) — ⚠ là kết hợp có thật và phổ biến, ⚠ nhưng Kanban tập trung vào ⚠ DÒNG CHẢY công việc và giới hạn WIP, ⚠ KHÔNG có thực hành kỹ thuật nào như lập trình cặp.
-
D (Scrum-DSDM) — ⚠ DSDM là khung agile có thật (Dynamic Systems Development Method), ⚠ nhưng nó tập trung vào ⚠ quản trị dự án và ràng buộc kinh doanh, ⚠ không phải thực hành kỹ thuật.
-
C (Scrum-Traditional) — ⚠ là cách tiếp cận LAI, ⚠ không giải quyết nhu cầu về thực hành kỹ thuật.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25786 ở lô 181 (lập trình cặp tạo giá trị, đừng cắt) và câu #25838 ở lô này (scrum of scrums cho nhiều đội). ⚠ Ba câu cùng chủ đề mở rộng và bổ sung cho Scrum.
⚠ Vì sao Scrum cần bổ sung thực hành kỹ thuật: | Lý do | Nội dung | |---|---| | ⚠ Scrum là KHUNG QUẢN LÝ, cố ý để trống phần kỹ thuật | | | ⚠ Scrum nói AI làm gì và KHI NÀO, không nói LÀM THẾ NÀO | | | ⚠ Không có thực hành kỹ thuật tốt thì NỢ KỸ THUẬT tích tụ | | | ⚠ Velocity giảm dần vì mã ngày càng khó sửa | | | ⚠ Vì thế | ⚠ rất nhiều đội kết hợp Scrum với XP — mô hình phổ biến nhất trong thực tế |
Từ khoá nhận diện:
"lập trình cặp, TDD, tích hợp liên tục, refactoring" → ⚠ XP "giới hạn WIP, trực quan hoá dòng chảy, hệ thống kéo" → ⚠ Kanban "sprint, product owner, scrum master, backlog" → ⚠ Scrum "quản trị và ràng buộc kinh doanh" → ⚠ DSDM
⚠ Các khung agile phổ biến — bảng so sánh: | Khung | Tập trung vào | |---|---| | ⚠ Scrum | ⚠ QUẢN LÝ: vai trò, sự kiện, hiện vật | | ⚠ XP | ⚠ KỸ THUẬT: cách viết mã và kiểm thử | | ⚠ Kanban | ⚠ DÒNG CHẢY: trực quan hoá, giới hạn WIP | | ⚠ Lean | ⚠ LOẠI BỎ LÃNG PHÍ, tối ưu toàn hệ thống | | ⚠ DSDM | ⚠ quản trị dự án và ràng buộc kinh doanh | | ⚠ Crystal | ⚠ điều chỉnh theo quy mô và mức nghiêm trọng của dự án | | ⚠ Kết hợp phổ biến | ⚠ Scrum + XP (kỹ thuật), Scrum + Kanban (dòng chảy) |
| ⚠ Điều kiện để áp dụng XP thành công | Điều kiện |
|---|---|
| ⚠ Đội có kỹ năng kỹ thuật TỐT | ⚠ đề nói đội của Deborah rất thành thạo |
| ⚠ Cam kết với chất lượng mã | |
| ⚠ Tổ chức chấp nhận chi phí ngắn hạn của lập trình cặp | ⚠ hai người một máy — nhưng bù lại chất lượng cao hơn |
| ⚠ Có hạ tầng kiểm thử và tích hợp tự động | |
| ⚠ Không phù hợp khi | ⚠ đội thiếu kỹ năng hoặc tổ chức đo năng suất bằng số dòng mã trên đầu người |
| ⚠ Lợi ích của lập trình cặp | Lợi ích |
|---|---|
| ⚠ Bắt lỗi NGAY khi viết | ⚠ chi phí phòng ngừa — rẻ nhất |
| ⚠ Chia sẻ tri thức liên tục | ⚠ giảm rủi ro "chỉ một người biết" |
| ⚠ Thiết kế tốt hơn nhờ hai góc nhìn | |
| ⚠ Đào tạo người mới nhanh hơn | ⚠ liên hệ câu #25625 về reverse shadowing |
| ⚠ Chi phí | ⚠ hai người cho một việc — nhưng nghiên cứu cho thấy tổng chi phí thường không tăng nhờ ít lỗi hơn |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có thực hành kỹ thuật nào để giữ chất lượng mã không | | | Nợ kỹ thuật có đang tích tụ không | ⚠ velocity giảm dần là dấu hiệu | | Tổ chức có hiểu vì sao hai người ngồi một máy không | |
Và cách tóm gọn mối quan hệ giữa hai khung: Scrum cho bạn nhịp và vai trò, XP cho bạn cách giữ cho mã không mục nát. Thiếu vế thứ hai thì vài chục sprint sau, nhịp nào cũng chậm lại.
- A No one; the project manager has autonomy on the project in this structure
- B Project team members
- C Project champions
- D Functional managers
Xem giải thích
Đáp án
D — Functional managers (các quản lý chức năng).
Vì sao đúng
⚠ Vì sao quản lý chức năng phải duyệt trong ma trận YẾU: | Lý do | Nội dung | |---|---| | ⚠ Trong ma trận YẾU, QUYỀN của PM rất THẤP | | | ⚠ Nhân sự thuộc về CÁC PHÒNG BAN, không thuộc dự án | | | ⚠ Quản lý chức năng KIỂM SOÁT thời gian của nhân viên mình | | | ⚠ Không có sự đồng ý của họ thì không phân người vào dự án được | | | ⚠ Đề nói rõ mục đích | ⚠ "để nguồn lực được CHÍNH THỨC phân công vào công việc dự án" — đúng thẩm quyền của quản lý chức năng |
Vì sao các phương án khác sai
-
A (không ai cả, PM tự quyết trong cơ cấu này) — ⚠ SAI HẲN: ⚠ trong ma trận YẾU, PM có quyền THẤP NHẤT trong các cơ cấu ma trận; ⚠ tự quyết là điều PM ít làm được nhất ở đây.
-
B (thành viên đội dự án) — ⚠ họ THỰC HIỆN lịch, không PHÊ DUYỆT nó; ⚠ và họ cũng không có quyền cam kết thời gian của chính mình.
-
C (project champions — người ủng hộ dự án) — ⚠ là người ủng hộ và vận động cho dự án, ⚠ nhưng không có thẩm quyền chính thức phân bổ nguồn lực.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25662 ở lô 178 (đội báo cáo cho Jack và Jack giữ ngân sách → quyền PM thấp), câu #25691 ở lô 179 (không có điều lệ nên quản lý chức năng không nhả người), và câu #25611 ở lô 177 (cơ cấu organic). ⚠ Bốn câu cùng chủ đề cơ cấu tổ chức và quyền của PM.
⚠ Bảng quyền của PM theo cơ cấu — nhắc lại: | Cơ cấu | Quyền của PM | Ai kiểm soát nguồn lực | |---|---|---| | ⚠ Functional | ⚠ rất ít | ⚠ quản lý chức năng | | ⚠ WEAK matrix | ⚠ THẤP | ⚠ QUẢN LÝ CHỨC NĂNG — CÂU NÀY | | ⚠ Balanced matrix | ⚠ thấp đến trung bình | ⚠ chia sẻ | | ⚠ Strong matrix | ⚠ trung bình đến cao | ⚠ quản lý dự án | | ⚠ Project-oriented | ⚠ cao tới toàn quyền | ⚠ quản lý dự án |
Từ khoá nhận diện:
"ma trận yếu" → ⚠ quản lý chức năng nắm quyền về người và tiền "phân công chính thức nguồn lực" → ⚠ cần sự phê duyệt của người kiểm soát nguồn lực đó "PM tự quyết" → ⚠ SAI trong ma trận yếu "project champion" → ⚠ người ủng hộ, không có thẩm quyền chính thức
| ⚠ Trong ma trận yếu, PM nên làm gì | Cách |
|---|---|
| ⚠ XÂY QUAN HỆ tốt với các quản lý chức năng | ⚠ họ là người quyết định thành bại của bạn |
| ⚠ Trình bày nhu cầu nguồn lực SỚM và RÕ RÀNG | |
| ⚠ Ghi cam kết nguồn lực thành VĂN BẢN | |
| ⚠ Dựa vào ĐIỀU LỆ DỰ ÁN làm cơ sở chính danh | ⚠ xem câu #25691 ở lô 179 |
| ⚠ Dùng expert power và referent power | ⚠ không có quyền chức vụ thì dùng quyền chuyên môn và uy tín |
| ⚠ Nhờ nhà tài trợ khi vượt thẩm quyền |
| ⚠ Vai trò của project champion | Vai trò |
|---|---|
| ⚠ Người ủng hộ mạnh mẽ cho dự án trong tổ chức | |
| ⚠ Vận động sự ủng hộ và tháo gỡ rào cản chính trị | |
| ⚠ Thường là người có ảnh hưởng, không nhất thiết có thẩm quyền | |
| ⚠ Khác nhà tài trợ | ⚠ nhà tài trợ CÓ thẩm quyền chính thức và cấp nguồn lực; champion chỉ có ẢNH HƯỞNG |
| ⚠ Vì sao lịch trình cần được duyệt | Lý do |
|---|---|
| ⚠ Lịch trình là CAM KẾT về thời gian của nhiều người | |
| ⚠ Người cam kết phải là người có quyền cam kết | |
| ⚠ Duyệt xong thì lịch trở thành ĐƯỜNG CƠ SỞ | ⚠ và được bảo vệ bởi kiểm soát thay đổi |
| ⚠ Không được duyệt | ⚠ thì lịch chỉ là mong muốn của PM |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai thật sự kiểm soát thời gian của thành viên đội bạn | | | Cam kết nguồn lực có bằng văn bản không | | | Bạn có quan hệ tốt với các quản lý chức năng không | ⚠ trong ma trận yếu, đây là kỹ năng quan trọng nhất |
Và thực tế của nghề quản lý dự án trong ma trận yếu: bạn chịu trách nhiệm về kết quả nhưng không kiểm soát nguồn lực. Cách duy nhất để sống được là xây quan hệ và làm mọi cam kết thành văn bản.
- A Stakeholder analysis
- B Scope verification
- C PMIS
- D Change control boards
Xem giải thích
Đáp án
C — PMIS (Project Management Information System — hệ thống thông tin quản lý dự án).
Vì sao đúng
⚠ PMIS là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Hệ thống công cụ và kỹ thuật để THU THẬP, TÍCH HỢP và PHỔ BIẾN thông tin dự án | | | ⚠ Bao gồm phần mềm lập lịch, hệ thống ủy quyền công việc, hệ thống thu thập dữ liệu, giao diện web | | | ⚠ Là một phần của EEF — yếu tố môi trường doanh nghiệp | | | ⚠ Được dùng ở HẦU HẾT các quy trình THỰC HIỆN và KIỂM SOÁT | | | ⚠ Vì sao giúp nhiều nhất khi thực hiện | ⚠ giai đoạn thực hiện tạo ra khối lượng dữ liệu lớn nhất và cần điều phối nhiều nhất |
Vì sao các phương án khác sai
-
D (Change control boards — hội đồng kiểm soát thay đổi) — ⚠ CCB hoạt động trong nhóm GIÁM SÁT VÀ KIỂM SOÁT, ⚠ không phải công cụ của việc thực hiện.
-
B (Scope verification) — ⚠ thuộc nhóm GIÁM SÁT VÀ KIỂM SOÁT (nay gọi là Validate Scope); ⚠ diễn ra khi nghiệm thu, không phải trong lúc làm.
-
A (Stakeholder analysis) — ⚠ chủ yếu diễn ra ở giai đoạn KHỞI TẠO và LẬP KẾ HOẠCH; ⚠ có cập nhật trong thực hiện nhưng không phải công cụ chính.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25773 ở lô 180 (công cụ quản lý artifact cho nhiều đội), câu #25760 (hệ thống lưu trữ tài liệu), và câu #25824 ở lô 181 (đặc điểm hệ thống lưu trữ hiệu quả). ⚠ Bốn câu cùng chủ đề hệ thống thông tin dự án.
⚠ PMIS gồm những gì: | Thành phần | Ví dụ | |---|---| | ⚠ Công cụ LẬP LỊCH | ⚠ phần mềm quản lý lịch trình, biểu đồ Gantt, sơ đồ mạng | | ⚠ Hệ thống UỶ QUYỀN CÔNG VIỆC | ⚠ work authorization system — ai được phép bắt đầu việc gì, khi nào | | ⚠ Hệ thống QUẢN LÝ CẤU HÌNH | ⚠ kiểm soát phiên bản tài liệu và sản phẩm | | ⚠ Hệ thống THU THẬP và PHÂN PHỐI thông tin | | | ⚠ Giao diện tới các hệ thống tự động khác | ⚠ kế toán, nhân sự, mua sắm | | ⚠ Kho lưu trữ dữ liệu và tài liệu | | | ⚠ Lưu ý | ⚠ PMIS là EEF, tức là thứ TỔ CHỨC cung cấp — PM dùng chứ không tự xây từ đầu |
Từ khoá nhận diện:
"hệ thống thông tin dùng trong thực hiện dự án" → ⚠ PMIS "phê duyệt yêu cầu thay đổi" → ⚠ CCB, thuộc giám sát và kiểm soát "khách hàng nghiệm thu bàn giao" → ⚠ Validate Scope, thuộc giám sát và kiểm soát "phân tích bên liên quan" → ⚠ chủ yếu ở khởi tạo và lập kế hoạch
⚠ PMIS được dùng ở những quy trình nào: | Quy trình | Vai trò của PMIS | |---|---| | ⚠ Direct and Manage Project Work | ⚠ uỷ quyền công việc, theo dõi tiến độ, thu thập dữ liệu | | ⚠ Manage Communications | ⚠ phân phối thông tin tới bên liên quan | | ⚠ Monitor and Control Project Work | ⚠ tổng hợp dữ liệu thành thông tin và báo cáo | | ⚠ Control Schedule / Costs / Resources | ⚠ so sánh thực tế với đường cơ sở | | ⚠ Kết luận | ⚠ PMIS là xương sống thông tin của cả giai đoạn thực hiện và kiểm soát |
| ⚠ Vì sao giai đoạn THỰC HIỆN cần PMIS nhất | Lý do |
|---|---|
| ⚠ Phần lớn NGÂN SÁCH và NGUỒN LỰC được tiêu ở đây | |
| ⚠ Nhiều người cùng làm việc song song | |
| ⚠ Dữ liệu hiệu suất phát sinh liên tục | |
| ⚠ Cần điều phối và phân phối thông tin cho nhiều bên | |
| ⚠ Không có PMIS | ⚠ PM phải tổng hợp thủ công — chậm, dễ sai, và không kịp thời |
| ⚠ PMIS và work authorization system | Quan hệ |
|---|---|
| ⚠ Work authorization system là MỘT PHẦN của PMIS | |
| ⚠ Nó kiểm soát AI được bắt đầu việc gì và KHI NÀO | |
| ⚠ Ngăn công việc được làm sai thứ tự hoặc chưa được phép | |
| ⚠ Đặc biệt quan trọng với | ⚠ dự án lớn nhiều nhà thầu — xem câu #25845 ở lô này |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có PMIS không hay mọi thứ làm thủ công | | | Dữ liệu hiệu suất có được thu thập tự động không | | | Thông tin có tới đúng người đúng lúc không | |
Và vai trò thực sự của PMIS: nó biến hàng nghìn mẩu dữ liệu rời rạc của giai đoạn thực hiện thành thông tin có thể ra quyết định. Không có nó, PM dành phần lớn thời gian để tổng hợp thay vì để quản lý.
- A Secure a compliance manager on the project team to handle the documentation.
- B Hire a knowledge manager.
- C Obtain a knowledge management system.
- D Assign clear roles on the team for managing documentation.
Xem giải thích
Đáp án
D — Gán VAI TRÒ RÕ RÀNG trong đội cho việc quản lý tài liệu.
Vì sao đúng
⚠ Vì sao gán vai trò là giải pháp đúng: | Lý do | Nội dung | |---|---| | ⚠ Yêu cầu tuân thủ đòi thông tin CHÍNH XÁC và LIÊN TỤC | ⚠ vật tư, kết quả, thời gian bỏ ra | | ⚠ Việc ghi chép diễn ra ở MỌI phần của dự án | ⚠ không thể dồn cho một người ngoài | | ⚠ Rõ ai chịu trách nhiệm ghi gì thì không sót và không trùng | | | ⚠ Là giải pháp trong tầm thẩm quyền của PM | ⚠ không cần xin thêm ngân sách hay nhân sự | | ⚠ Kết luận | ⚠ phân vai rõ ràng giải quyết gốc vấn đề mà không tăng chi phí |
Vì sao các phương án khác sai
-
A (tuyển một quản lý tuân thủ vào đội) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ có vẻ hợp lý, ⚠ nhưng tốn thêm nguồn lực và tạo NÚT THẮT — một người không thể ghi chép thay cả đội; ⚠ và người ngoài không nắm được chi tiết công việc thực tế.
-
B (thuê một quản lý tri thức) — ⚠ nhầm lĩnh vực: ⚠ quản lý tri thức lo việc chia sẻ và tái sử dụng tri thức, ⚠ không lo tuân thủ hồ sơ.
-
C (mua hệ thống quản lý tri thức) — ⚠ công cụ không thay được việc phân vai: ⚠ có hệ thống mà không rõ ai nhập liệu thì vẫn thiếu dữ liệu.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25843 ở lô này (xác định vai trò và trách nhiệm là một yếu tố quản trị dự án) và câu #25810 ở lô 181 (ma trận RACI). ⚠ Ba câu cùng khẳng định: phân vai rõ ràng là công cụ rẻ nhất và hiệu quả nhất.
⚠ Vì sao dự án có vốn nhà nước đòi hồ sơ chặt | Lý do: | Lý do | Nội dung | |---|---| | ⚠ Tiền công phải giải trình được | | | ⚠ Chịu KIỂM TOÁN từ cơ quan quản lý | | | ⚠ Có yêu cầu pháp lý về lưu trữ hồ sơ | | | ⚠ Hồ sơ thiếu có thể dẫn tới bị thu hồi kinh phí | | | ⚠ Vì thế | ⚠ việc ghi chép không phải thủ tục thừa mà là YÊU CẦU BẮT BUỘC của dự án |
Từ khoá nhận diện:
"nhiều yêu cầu tuân thủ và hồ sơ" → ⚠ phân vai rõ ai ghi chép cái gì "tuyển thêm người chuyên trách" → ⚠ tạo nút thắt, tốn nguồn lực "mua công cụ" → ⚠ công cụ không thay được phân vai "quản lý tri thức" → ⚠ khác với quản lý hồ sơ tuân thủ
| ⚠ Isabella nên phân vai thế nào | Cách |
|---|---|
| ⚠ Xác định CHÍNH XÁC hồ sơ nào bắt buộc theo quy định | ⚠ bước đầu tiên |
| ⚠ Ánh xạ từng loại hồ sơ vào người GẦN nguồn dữ liệu nhất | ⚠ ai làm việc đó thì người đó ghi |
| ⚠ Dùng RACI để làm rõ ai làm, ai chịu trách nhiệm cuối | |
| ⚠ Đưa việc ghi chép vào ĐỊNH NGHĨA HOÀN THÀNH của công việc | ⚠ để không bị coi là việc phụ |
| ⚠ Tính thời gian ghi chép vào ước lượng công việc | ⚠ nếu không thì nó sẽ bị bỏ khi bận |
| ⚠ Rà soát định kỳ xem hồ sơ có đầy đủ không | |
| ⚠ Isabella chưa từng làm loại này | ⚠ nên cũng cần tham vấn chuyên gia hoặc PMO về danh mục hồ sơ bắt buộc |
| ⚠ Rủi ro nếu không phân vai rõ | Rủi ro |
|---|---|
| ⚠ "Tôi tưởng anh ghi" — hồ sơ thiếu | |
| ⚠ Ghi trùng, dữ liệu mâu thuẫn | |
| ⚠ Phát hiện thiếu khi bị kiểm toán thì đã muộn | |
| ⚠ Dữ liệu ghi lại sau trí nhớ thì không chính xác | |
| ⚠ Với dự án 12 tháng | ⚠ thiếu hồ sơ tích luỹ dần và rất khó khôi phục về sau |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có danh mục hồ sơ bắt buộc chưa | | | Mỗi loại hồ sơ có đúng một người chịu trách nhiệm không | | | Thời gian ghi chép có nằm trong ước lượng công việc không | |
Và nguyên tắc chung cho mọi yêu cầu tuân thủ: việc ghi chép phải nằm ngay tại nơi công việc diễn ra. Giao cho một người ngoài ghi hộ là cách chắc chắn nhất để có hồ sơ vừa muộn vừa sai.
- A Put together a comprehensive training deck on agile.
- B Remove members of the team who do not know agile.
- C Reach out to Acme's learning and development team for help.
- D Evaluate the knowledge level of the team.
Xem giải thích
Đáp án
D — ĐÁNH GIÁ mức độ hiểu biết của đội.
Vì sao đúng
⚠ Vì sao đánh giá trước là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Đội có mức hiểu biết KHÔNG ĐỒNG ĐỀU | ⚠ một số biết agile, một số chưa | | ⚠ Chưa biết chính xác ai thiếu gì | | | ⚠ Đào tạo cần ĐÚNG NỘI DUNG và ĐÚNG MỨC | ⚠ quá cơ bản thì người biết rồi chán; quá nâng cao thì người mới không theo kịp | | ⚠ Có thể tận dụng người ĐÃ BIẾT để kèm người chưa biết | | | ⚠ Kết luận | ⚠ biết khoảng trống ở đâu rồi mới thiết kế cách lấp |
Vì sao các phương án khác sai
-
A (soạn một bộ tài liệu đào tạo toàn diện về agile) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ hành động HỢP LÝ nhưng ⚠ làm trước khi biết đội cần gì; ⚠ và "toàn diện" thường nghĩa là quá nhiều với người này, quá ít với người kia.
-
C (nhờ bộ phận đào tạo của công ty) — ⚠ cũng là bước SAU khi đã biết nhu cầu; ⚠ nhờ giúp mà không nói rõ cần gì thì họ cũng không giúp đúng được.
-
B (loại những người chưa biết agile khỏi đội) — ⚠ SAI HẲN: ⚠ loại người vì thiếu kiến thức có thể học được; ⚠ và ⚠ loại bỏ con người gần như luôn là đáp án sai trong đề PMP.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25747 ở lô 180 (đội bất mãn vì bị ép dùng Scrum → hỏi đội trước), câu #25849 ở lô này (đánh giá lợi ích trước khi chuyển sang lai), và câu #25850 (đo hiệu quả đào tạo bằng hiệu suất). ⚠ Bốn câu cùng chủ đề chuyển đổi sang agile — và cùng một nguyên tắc: hiểu tình hình trước, hành động sau.
⚠ Đánh giá khoảng trống kỹ năng gồm những gì: | Bước | Việc | |---|---| | ⚠ Xác định kỹ năng CẦN CÓ | ⚠ agile đòi hỏi gì ở đội này | | ⚠ Đánh giá kỹ năng HIỆN CÓ của từng người | ⚠ khảo sát, phỏng vấn, quan sát | | ⚠ Tìm KHOẢNG TRỐNG | | | ⚠ Thiết kế cách lấp: đào tạo, kèm cặp, tự học, thực hành | | | ⚠ Đo kết quả sau đó | ⚠ xem câu #25850 | | ⚠ Công cụ | ⚠ ma trận kỹ năng — skills matrix, liệt kê người theo hàng và kỹ năng theo cột |
Từ khoá nhận diện:
"đội có mức hiểu biết không đồng đều" → ⚠ đánh giá trước "soạn tài liệu toàn diện" → ⚠ hành động trước khi biết nhu cầu "loại người chưa biết" → ⚠ luôn là đáp án sai "nhờ bộ phận khác" → ⚠ được, nhưng sau khi đã xác định nhu cầu
| ⚠ Alex có thể tận dụng gì | Nguồn lực |
|---|---|
| ⚠ Người ĐÃ CÓ kinh nghiệm agile trong đội | ⚠ họ có thể kèm người mới |
| ⚠ Chính bản thân Alex là Scrum Master | ⚠ huấn luyện đội là việc CỦA anh ấy |
| ⚠ Học qua thực hành trong các sprint đầu | ⚠ agile học tốt nhất bằng cách làm |
| ⚠ Bộ phận đào tạo của công ty | ⚠ cho phần cần đào tạo bài bản |
| ⚠ Tổ chức VỪA MỚI áp dụng agile | ⚠ nên nhiều khả năng chưa có chương trình đào tạo sẵn — càng cần đánh giá để biết xin gì |
| ⚠ Vai trò huấn luyện của Scrum Master | Vai trò |
|---|---|
| ⚠ Huấn luyện ĐỘI về Scrum và agile | ⚠ trách nhiệm chính thức của vai trò này |
| ⚠ Huấn luyện PRODUCT OWNER về cách quản lý backlog | |
| ⚠ Giúp TỔ CHỨC hiểu và áp dụng Scrum | |
| ⚠ Vì thế | ⚠ Alex không nên đẩy hết việc đào tạo sang bộ phận khác |
| ⚠ Lưu ý khi đội có mức hiểu biết chênh lệch | Lưu ý |
|---|---|
| ⚠ Người biết rồi dễ CHÁN nếu bị bắt học lại từ đầu | |
| ⚠ Người mới dễ NGẠI hỏi trước mặt người giỏi | |
| ⚠ Ghép cặp là cách cân bằng tốt | ⚠ người biết kèm người chưa biết |
| ⚠ Đừng | ⚠ đào tạo đồng loạt cùng một nội dung cho mọi người |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết chính xác ai thiếu kỹ năng gì không | | | Có tận dụng được người đã biết trong đội không | | | Kế hoạch đào tạo có phân hoá theo mức không | |
Và sai lầm phổ biến khi tổ chức mới áp dụng agile: mua một khoá đào tạo giống nhau cho tất cả. Đánh giá trước tốn vài giờ nhưng tiết kiệm được cả một khoản đào tạo sai đối tượng.
- A Assess the company's culture and systems.
- B Determine the client's culture and existing systems.
- C Confirm the project scope statement.
- D Review the business case.
Xem giải thích
Đáp án
C — XÁC NHẬN tuyên bố phạm vi dự án (confirm the project scope statement).
Vì sao đúng
⚠ Bóc tách vấn đề: | Chi tiết | Suy ra | |---|---| | ⚠ Khách hàng nói bàn giao KHÔNG khớp với thoả thuận ban đầu | ⚠ hai bên hiểu khác nhau về phạm vi | | ⚠ Đội tin rằng họ đã đáp ứng mọi yêu cầu trong hợp đồng | ⚠ đội đọc hợp đồng theo cách của mình | | ⚠ PMO kết luận: đội KHÔNG thực hiện Validate Scope | ⚠ manh mối quyết định | | ⚠ Kết luận | ⚠ lẽ ra phải xác nhận rõ tuyên bố phạm vi VỚI KHÁCH HÀNG, và nghiệm thu từng bàn giao trong suốt dự án |
⚠ Validate Scope là gì và vì sao bỏ qua nó lại nguy hiểm: | Điều | Nội dung | |---|---| | ⚠ Là quy trình KHÁCH HÀNG chính thức CHẤP NHẬN bàn giao | | | ⚠ Diễn ra ĐỊNH KỲ suốt dự án, không phải một lần ở cuối | | | ⚠ Bắt sớm sự hiểu nhầm về phạm vi | | | ⚠ Tạo bằng chứng chấp nhận bằng văn bản | | | ⚠ Bỏ qua nó | ⚠ mọi hiểu nhầm dồn tới cuối dự án — đúng tình huống này |
Vì sao các phương án khác sai
-
D (rà soát business case) — ⚠ business case nói VÌ SAO làm dự án, ⚠ không mô tả chi tiết bàn giao.
-
A (đánh giá văn hoá và hệ thống của công ty mình) và B (tìm hiểu văn hoá và hệ thống của khách hàng) — ⚠ có thể hữu ích để hiểu bối cảnh, ⚠ nhưng ⚠ không giải quyết vấn đề gốc là phạm vi chưa được xác nhận chung.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25666 ở lô 178 (Control Quality rồi Validate Scope), câu #25591 ở lô 177, và câu #25835 ở lô này (hiểu nhầm về việc dự án là gì). ⚠ Bốn câu cùng một bài học: phạm vi phải được hiểu GIỐNG NHAU bởi cả hai bên, và phải được xác nhận bằng văn bản.
⚠ Tuyên bố phạm vi dự án gồm gì: | Mục | Nội dung | |---|---| | ⚠ Mô tả phạm vi SẢN PHẨM | ⚠ đặc tính và chức năng | | ⚠ BÀN GIAO | ⚠ danh sách cụ thể những gì sẽ giao | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ thế nào là đạt — mục quan trọng nhất để tránh tranh cãi | | ⚠ LOẠI TRỪ — exclusions | ⚠ cái gì KHÔNG thuộc dự án — mục hay bị bỏ nhất | | ⚠ Ràng buộc và giả định | | | ⚠ Không có tiêu chí chấp nhận rõ ràng | ⚠ thì "đạt yêu cầu" thành chuyện tranh cãi |
Từ khoá nhận diện:
"khách nói khác với thoả thuận ban đầu" → ⚠ phạm vi chưa được xác nhận chung "đội tin mình đã làm đúng hợp đồng" → ⚠ hai bên đọc hợp đồng khác nhau "không thực hiện Validate Scope" → ⚠ thiếu bước nghiệm thu định kỳ "cái gì KHÔNG thuộc dự án" → ⚠ exclusions — phần quan trọng của scope statement
| ⚠ Lẽ ra dự án nên làm gì | Việc |
|---|---|
| ⚠ Viết TUYÊN BỐ PHẠM VI chi tiết, có tiêu chí chấp nhận | |
| ⚠ Được khách hàng KÝ XÁC NHẬN | |
| ⚠ Thực hiện VALIDATE SCOPE ở mỗi bàn giao lớn | ⚠ không đợi tới cuối |
| ⚠ Ghi lại mọi lần chấp nhận bằng văn bản | |
| ⚠ Đưa mọi thay đổi qua kiểm soát thay đổi | |
| ⚠ Nếu làm vậy | ⚠ hiểu nhầm sẽ lộ ra ở bàn giao ĐẦU TIÊN, không phải ở cuối dự án |
| ⚠ Vì sao "làm đúng hợp đồng" chưa đủ | Lý do |
|---|---|
| ⚠ Hợp đồng thường viết ở mức khá cao | |
| ⚠ Ngôn ngữ hợp đồng có thể hiểu theo nhiều cách | |
| ⚠ Kỳ vọng của khách hàng vượt ra ngoài chữ nghĩa hợp đồng | ⚠ xem câu #25835 — cùng bài học |
| ⚠ Vì thế | ⚠ nghiệm thu ĐỊNH KỲ là cách duy nhất để phát hiện lệch sớm |
| ⚠ Bây giờ phải làm gì | Bước |
|---|---|
| ⚠ Đối chiếu cụ thể từng bàn giao với tuyên bố phạm vi và hợp đồng | |
| ⚠ Xác định phần nào thật sự thiếu, phần nào là kỳ vọng ngoài phạm vi | |
| ⚠ Nếu thiếu thật: sửa chữa | |
| ⚠ Nếu ngoài phạm vi: đàm phán như một yêu cầu thay đổi | |
| ⚠ Ghi bài học kinh nghiệm |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyên bố phạm vi của bạn có tiêu chí chấp nhận rõ không | | | Khách hàng đã ký xác nhận phạm vi chưa | | | Bạn có nghiệm thu định kỳ hay đợi tới cuối | ⚠ đợi tới cuối là công thức của tranh chấp |
Và bài học đắt nhất của tình huống này: làm đúng hợp đồng nhưng khách không hài lòng vẫn là thất bại. Nghiệm thu định kỳ tốn vài giờ mỗi lần và tiết kiệm được cả một cuộc tranh chấp.
- A To cancel the poll.
- B The project management office requires this poll.
- C State regulations require the poll.
- D A comfortable working environment helps the team work better.
Xem giải thích
Đáp án
D — Một MÔI TRƯỜNG LÀM VIỆC THOẢI MÁI giúp đội làm việc tốt hơn.
Vì sao đúng
⚠ Vì sao khảo sát phong cách làm việc là việc đáng làm: | Lý do | Nội dung | |---|---| | ⚠ Hiểu cách mỗi người làm việc hiệu quả nhất | | | ⚠ Bố trí môi trường và cách phối hợp phù hợp | | | ⚠ Môi trường phù hợp → năng suất và chất lượng cao hơn | | | ⚠ Giảm xung đột do khác biệt phong cách | | | ⚠ Thực hiện ngay sau buổi khởi động — đúng thời điểm | ⚠ giai đoạn Forming, khi đội đang hình thành | | ⚠ Kết luận | ⚠ đây là hoạt động của quy trình Develop Team, có cơ sở rõ ràng |
Vì sao các phương án khác sai
-
B (PMO yêu cầu làm khảo sát này) và C (quy định của nhà nước yêu cầu) — ⚠ đổ trách nhiệm cho quy định thay vì giải thích LÝ DO; ⚠ và không có căn cứ nào trong đề.
-
A (huỷ cuộc khảo sát) — ⚠ bỏ cuộc trước một câu hỏi hoàn toàn hợp lý; ⚠ Roger nên GIẢI THÍCH chứ không rút lui.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25771 ở lô 180 (đánh giá tính cách để đội phối hợp tốt hơn) và câu #25743 (tạo cơ hội xây dựng đội). ⚠ Ba câu cùng chủ đề hiểu con người để đội làm việc tốt hơn.
⚠ Môi trường làm việc ảnh hưởng tới hiệu suất thế nào: | Yếu tố | Ảnh hưởng | |---|---| | ⚠ Không gian vật lý | ⚠ ngồi cùng chỗ hay phân tán, yên tĩnh hay ồn ào | | ⚠ Nhịp làm việc | ⚠ có người tập trung tốt buổi sáng, người buổi chiều | | ⚠ Cách giao tiếp ưa thích | ⚠ nói trực tiếp hay viết trước rồi bàn | | ⚠ Mức độ tự chủ mong muốn | | | ⚠ Cách nhận phản hồi | ⚠ công khai hay riêng tư | | ⚠ Biết những điều này | ⚠ giúp PM bố trí công việc và cách làm việc phù hợp |
Từ khoá nhận diện:
"khảo sát phong cách làm việc" → ⚠ để tạo môi trường phù hợp, nâng hiệu suất "vì quy định bắt buộc" → ⚠ né tránh việc giải thích lý do "huỷ đi" → ⚠ bỏ cuộc, luôn sai "buổi khởi động vừa xong" → ⚠ đúng thời điểm để làm việc này
| ⚠ Roger nên trả lời ban chỉ đạo thế nào | Cách |
|---|---|
| ⚠ Nêu MỤC ĐÍCH: hiểu đội để bố trí cách làm việc hiệu quả | |
| ⚠ Nêu LỢI ÍCH: giảm xung đột, tăng năng suất, giữ người | |
| ⚠ Nêu CHI PHÍ nhỏ: chỉ mất một buổi ngắn | |
| ⚠ Nêu thời điểm: đầu dự án là lúc rẻ nhất để làm | |
| ⚠ Đừng | ⚠ viện dẫn quy định để tránh phải giải thích |
| ⚠ Các công cụ của quy trình Develop Team | Công cụ |
|---|---|
| ⚠ Colocation | ⚠ ngồi cùng chỗ |
| ⚠ Virtual teams và công nghệ giao tiếp | |
| ⚠ Recognition and rewards | ⚠ ghi nhận và khen thưởng |
| ⚠ Training | ⚠ đào tạo |
| ⚠ Individual and team assessments | ⚠ ĐÁNH GIÁ CÁ NHÂN VÀ ĐỘI — CÂU NÀY |
| ⚠ Team-building activities | |
| ⚠ Interpersonal and team skills | ⚠ quản lý xung đột, tạo ảnh hưởng, tạo động lực |
| ⚠ Đầu ra | ⚠ đánh giá hiệu suất đội và cập nhật các tài liệu liên quan |
| ⚠ Vì sao làm SỚM lại quan trọng | Lý do |
|---|---|
| ⚠ Đội đang ở giai đoạn FORMING | ⚠ chuẩn mực chưa hình thành, dễ điều chỉnh |
| ⚠ Rút ngắn giai đoạn Storming | ⚠ hiểu nhau sớm thì ít va chạm hơn |
| ⚠ Chi phí thay đổi cách làm việc thấp nhất ở đầu dự án | |
| ⚠ Liên hệ | ⚠ xem câu #25700 ở lô 179 về giai đoạn Storming |
| ⚠ Lưu ý khi làm khảo sát kiểu này | Lưu ý |
|---|---|
| ⚠ Nói rõ MỤC ĐÍCH với đội trước khi khảo sát | |
| ⚠ Kết quả dùng để HỖ TRỢ, không để đánh giá xếp loại | |
| ⚠ Bảo mật thông tin cá nhân | |
| ⚠ Phải THẬT SỰ dùng kết quả | ⚠ khảo sát mà không thay đổi gì thì lần sau không ai trả lời thật |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết cách làm việc hiệu quả nhất của từng thành viên không | | | Kết quả khảo sát có dẫn tới thay đổi cụ thể không | | | Đội có hiểu vì sao bạn làm khảo sát không | |
Và câu trả lời gọn nhất cho ban chỉ đạo: nửa buổi tìm hiểu đội bây giờ rẻ hơn nhiều so với vài tháng xử lý xung đột sau này.
- A Controlling
- B Regulatory
- C Primary
- D Supportive
Xem giải thích
Đáp án
A — Controlling PMO (PMO kiểm soát).
Vì sao đúng
⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ PMO CƯỠNG CHẾ việc tuân thủ | ⚠ có sự BẮT BUỘC — dấu hiệu quyết định | | ⚠ Nhưng BẠN vẫn là người DẪN DẮT nỗ lực tuân thủ trong dự án | ⚠ PMO không trực tiếp quản lý dự án | | ⚠ Kết luận | ⚠ có cưỡng chế nhưng không trực tiếp quản lý = CONTROLLING, mức kiểm soát TRUNG BÌNH |
Vì sao các phương án khác sai
-
D (Supportive) — ⚠ chỉ CUNG CẤP mẫu biểu, đào tạo, tài nguyên, ⚠ KHÔNG cưỡng chế; ⚠ đề nói rõ có sự cưỡng chế nên không phải supportive.
-
B (Regulatory) và C (Primary) — ⚠ KHÔNG phải loại PMO nào của PMBOK; ⚠ PMBOK chỉ có BA loại.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là câu THỨ BA trong bộ đề về các loại PMO. ⚠ Bảng đối chiếu: | Câu | Lô | Bối cảnh | Khoá | Chữ cái | |---|---|---|---|---| | ⚠ #25601 | ⚠ 177 | ⚠ PMO kiểm soát | ⚠ controlling | ⚠ — | | ⚠ #25644 | ⚠ 178 | ⚠ cấp mẫu biểu VÀ yêu cầu tuân thủ cách dùng | ⚠ controlling | ⚠ B | | ⚠ #25861 | ⚠ 182 | ⚠ cưỡng chế tuân thủ nhưng PM tự dẫn dắt | ⚠ controlling | ⚠ A | ⚠ Ba khoá đều là "controlling" và đều ĐÚNG — không mâu thuẫn. ⚠ Chữ cái đã xáo giữa các câu. ⚠ Bộ đề nhấn rất mạnh vào loại PMO này, có lẽ vì nó là mức trung gian dễ nhầm với hai mức còn lại.
⚠ Ba loại PMO — bảng phân biệt: | Loại | Vai trò | Mức kiểm soát | Nhận ra bằng | |---|---|---|---| | ⚠ Supportive | ⚠ cung cấp mẫu, đào tạo, bài học, tài nguyên | ⚠ THẤP | ⚠ "cung cấp", "hỗ trợ", "tuỳ bạn dùng" | | ⚠ Controlling | ⚠ cung cấp VÀ YÊU CẦU TUÂN THỦ | ⚠ TRUNG BÌNH | ⚠ "bắt buộc", "cưỡng chế", "phải theo" — CÂU NÀY | | ⚠ Directive | ⚠ TRỰC TIẾP quản lý dự án, PM thuộc PMO | ⚠ CAO | ⚠ "PMO cử người quản lý", "PM báo cáo cho PMO" |
Từ khoá nhận diện:
"cưỡng chế, bắt buộc tuân thủ" → ⚠ CONTROLLING "cung cấp, tuỳ bạn dùng" → ⚠ SUPPORTIVE "PMO trực tiếp quản lý dự án" → ⚠ DIRECTIVE "PM vẫn là người dẫn dắt dự án" → ⚠ loại trừ DIRECTIVE
| ⚠ Vì sao PMO kiểm soát tuân thủ trong ngành ngân hàng | Lý do |
|---|---|
| ⚠ Ngành ngân hàng chịu QUY ĐỊNH PHÁP LÝ nghiêm ngặt | |
| ⚠ Vi phạm tuân thủ có thể bị PHẠT NẶNG hoặc mất giấy phép | |
| ⚠ Cần NHẤT QUÁN giữa mọi dự án của tổ chức | |
| ⚠ Bị KIỂM TOÁN từ cơ quan quản lý | |
| ⚠ Vì thế | ⚠ PMO kiểm soát là lựa chọn hợp lý cho ngành này |
| ⚠ Ưu và nhược của controlling PMO | Điều |
|---|---|
| ⚠ ƯU: dữ liệu các dự án SO SÁNH được với nhau | |
| ⚠ ƯU: chất lượng quản trị đồng đều | |
| ⚠ ƯU: giảm rủi ro tuân thủ cho tổ chức | |
| ⚠ NHƯỢC: có thể nặng thủ tục với dự án nhỏ | |
| ⚠ NHƯỢC: PM cảm thấy bị bó | |
| ⚠ Cách dung hoà | ⚠ cho phép TAILORING theo quy mô — xem câu #25840 ở lô này |
| ⚠ Vai trò của bạn trong bối cảnh này | Vai trò |
|---|---|
| ⚠ DẪN DẮT nỗ lực tuân thủ trong dự án của mình | ⚠ PMO đặt chuẩn, bạn thực hiện |
| ⚠ Đảm bảo đội hiểu và làm theo yêu cầu tuân thủ | |
| ⚠ Phân vai rõ ai chịu trách nhiệm hồ sơ nào | ⚠ xem câu #25857 ở lô này — cùng bài toán |
| ⚠ Báo cáo tình trạng tuân thủ cho PMO | |
| ⚠ Nếu quy trình quá nặng | ⚠ đề xuất tailoring với PMO, đừng tự ý bỏ qua |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | PMO của bạn thuộc loại nào | ⚠ quyết định mức tự chủ bạn có | | Yêu cầu tuân thủ có phù hợp quy mô dự án không | | | Bạn có được phép điều chỉnh quy trình không | ⚠ hỏi rõ thay vì tự ý bỏ |
Và từ khoá duy nhất cần bắt trong mọi câu hỏi về PMO: có CƯỠNG CHẾ hay không, và PMO có TRỰC TIẾP quản lý dự án hay không. Hai câu hỏi đó phân biệt được cả ba loại.
- A Guarantee more time off at the end of the projects.
- B Tell everyone they are lucky to have a job.
- C Search for more resources to add to the ARK Project or try to adjust the timeline.
- D Offer a bonus to the team working on both projects.
Xem giải thích
Đáp án
C — TÌM THÊM NGUỒN LỰC để bổ sung cho dự án ARK, hoặc tìm cách ĐIỀU CHỈNH LỊCH TRÌNH.
Vì sao đúng
⚠ Bóc tách vấn đề: | Chi tiết | Vấn đề | |---|---| | ⚠ Cùng một đội làm HAI dự án song song | | | ⚠ Hai dự án cùng hạn trong CÙNG MỘT TUẦN | ⚠ đỉnh nhu cầu nguồn lực chồng lên nhau | | ⚠ Đội kêu QUÁ TẢI và mất thời gian nghỉ | ⚠ dấu hiệu vượt năng lực thật | | ⚠ Hai hướng giải quyết gốc | ⚠ TĂNG năng lực (thêm người) hoặc GIẢM nhu cầu (giãn lịch) |
⚠ Vì sao đây là giải pháp đúng: | Lý do | Nội dung | |---|---| | ⚠ Giải quyết NGUYÊN NHÂN, không chỉ triệu chứng | | | ⚠ Hai phương án đều nằm trong tầm xử lý của PM | | | ⚠ Quá tải kéo dài dẫn tới LỖI và LÀM LẠI | ⚠ xem câu #25612 ở lô 177 | | ⚠ Kết luận | ⚠ phải sửa bài toán nguồn lực, không thể bù bằng lời hứa hay tiền |
Vì sao các phương án khác sai
-
A (hứa cho nghỉ bù nhiều hơn sau khi xong dự án) — ⚠ hoãn vấn đề: ⚠ đội vẫn quá tải NGAY BÂY GIỜ, ⚠ và chất lượng công việc vẫn bị ảnh hưởng.
-
D (thưởng tiền cho đội làm hai dự án) — ⚠ tiền không giải quyết vấn đề NĂNG LỰC: ⚠ theo Herzberg, tiền là yếu tố DUY TRÌ, ⚠ và người kiệt sức vẫn kiệt sức dù được thưởng.
-
B (bảo mọi người may mắn vì còn có việc) — ⚠ thái độ thiếu tôn trọng, ⚠ vi phạm giá trị RESPECT trong Quy tắc Đạo đức PMI.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25612 ở lô 177 (làm quá sức dẫn tới LÀM LẠI), câu #25720 ở lô 179 (lịch nguồn lực), và câu #25847 ở lô này (các PM đồng cấp phối hợp chia sẻ nguồn lực). ⚠ Bốn câu cùng chủ đề quản lý nguồn lực trong tổ chức ma trận.
⚠ Vì sao ma trận CÂN BẰNG dễ gặp vấn đề này | Lý do: | Lý do | Nội dung | |---|---| | ⚠ Nhân sự làm nhiều dự án cùng lúc là chuyện BÌNH THƯỜNG | | | ⚠ Không ai có toàn quyền quyết định ưu tiên | ⚠ quyền chia sẻ giữa PM và quản lý chức năng | | ⚠ Mỗi PM chỉ nhìn thấy dự án của mình | | | ⚠ Hệ quả | ⚠ tổng tải của một người có thể vượt 100% mà không ai phát hiện cho tới khi họ kêu |
Từ khoá nhận diện:
"đội quá tải, làm nhiều dự án" → ⚠ tăng năng lực hoặc giảm nhu cầu "hứa nghỉ bù sau" → ⚠ hoãn vấn đề, không giải quyết "thưởng tiền" → ⚠ yếu tố duy trì, không giải quyết quá tải "may mắn vì còn có việc" → ⚠ thiếu tôn trọng, luôn sai
| ⚠ Các phương án cụ thể Eddie có thể xem xét | Phương án |
|---|---|
| ⚠ Thêm người vào dự án ARK | ⚠ cần thương lượng với quản lý chức năng |
| ⚠ Dời hạn một trong hai dự án | ⚠ cần nhà tài trợ đồng ý |
| ⚠ Giảm phạm vi một dự án | ⚠ qua kiểm soát thay đổi |
| ⚠ San bằng nguồn lực — resource levelling | ⚠ chấp nhận lịch dài hơn để tải đều hơn |
| ⚠ Phối hợp với PM của dự án MOC | ⚠ giao tiếp NGANG — xem câu #25847 |
| ⚠ Leo thang lên quản lý chức năng hoặc PMO | ⚠ nếu vượt thẩm quyền |
| ⚠ Vì sao "lịch trình không bị nén" vẫn có vấn đề | Lý do |
|---|---|
| ⚠ Lập kế hoạch nguồn lực chỉ tính TỔNG giờ, không tính CƯỜNG ĐỘ | |
| ⚠ Không tính THỜI GIAN NGHỈ và thời gian phục hồi | |
| ⚠ Không tính chi phí CHUYỂN NGỮ CẢNH giữa hai dự án | ⚠ task switching là lãng phí — xem câu #25786 ở lô 181 |
| ⚠ Bài học | ⚠ kế hoạch "hợp lệ trên giấy" vẫn có thể không bền vững trên thực tế |
| ⚠ Hậu quả nếu bỏ qua lời kêu ca | Hậu quả |
|---|---|
| ⚠ Chất lượng giảm, số lỗi tăng, phải làm lại | |
| ⚠ Kiệt sức và nghỉ việc | ⚠ mất tri thức, tốn chi phí tuyển mới |
| ⚠ Cả HAI dự án cùng trễ thay vì một | |
| ⚠ Mất niềm tin vào quản lý dự án |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổng tải của mỗi người trên MỌI dự án là bao nhiêu | ⚠ không chỉ nhìn dự án của mình | | Kế hoạch có tính thời gian nghỉ và chuyển ngữ cảnh không | | | Bạn có trao đổi với PM của dự án kia không | |
Và điều lời kêu ca của đội đang nói: kế hoạch đúng về mặt số học vẫn có thể sai về mặt con người. Giờ công cộng lại vừa đủ không có nghĩa là người ta làm được bền vững.