Ngân hàng đề — PMP Mock Exam Set
Tìm thấy 201 câu.
- A Vendor negotiation
- B Control procurements
- C Control scope
- D Stakeholder management
Xem giải thích
Đáp án
B — Control Procurements (kiểm soát mua sắm).
Vì sao đúng
⚠ Vì sao là Control Procurements: | Lý do | Nội dung | |---|---| | ⚠ Phần công việc bị ảnh hưởng nằm trong HỢP ĐỒNG với nhà cung cấp | | | ⚠ Thay đổi phạm vi kéo theo thay đổi HỢP ĐỒNG | | | ⚠ Control Procurements là quy trình QUẢN LÝ QUAN HỆ MUA SẮM | ⚠ theo dõi thực hiện hợp đồng, xử lý thay đổi và sửa đổi hợp đồng | | ⚠ Mọi sửa đổi hợp đồng đều xử lý ở đây | | | ⚠ Đầu ra bao gồm | ⚠ hợp đồng đã đóng, yêu cầu thay đổi, cập nhật tài liệu mua sắm |
Vì sao các phương án khác sai
-
C (Control Scope) — ⚠ quản lý phạm vi của DỰ ÁN, ⚠ nhưng câu hỏi nói rõ là quản lý ⚠ thay đổi đối với HỢP ĐỒNG; ⚠ đây là phương án gây nhiễu mạnh nhất.
-
A (Vendor negotiation) — ⚠ không phải tên quy trình PMBOK; ⚠ đàm phán là một kỹ thuật, không phải quy trình.
-
D (Stakeholder management) — ⚠ quản lý sự tham gia của bên liên quan, ⚠ không xử lý điều khoản hợp đồng.
Ghi nhớ
⚠ Ba quy trình mua sắm của PMBOK 6: | Quy trình | Nhóm | Việc | |---|---|---| | ⚠ Plan Procurement Management | ⚠ Lập kế hoạch | ⚠ quyết định mua gì, mua thế nào, loại hợp đồng nào | | ⚠ Conduct Procurements | ⚠ Thực hiện | ⚠ mời thầu, chọn nhà cung cấp, KÝ hợp đồng | | ⚠ Control Procurements | ⚠ Giám sát và kiểm soát | ⚠ theo dõi thực hiện, sửa đổi hợp đồng, ĐÓNG hợp đồng | | ⚠ Lưu ý | ⚠ PMBOK 6 đã BỎ quy trình Close Procurements riêng — việc đóng hợp đồng gộp vào Control Procurements |
Từ khoá nhận diện:
"thay đổi ảnh hưởng tới hợp đồng" → ⚠ Control Procurements "chọn nhà cung cấp, ký hợp đồng" → ⚠ Conduct Procurements "tự làm hay đi mua" → ⚠ Plan Procurement Management "đóng hợp đồng, nghiệm thu cuối" → ⚠ Control Procurements (không còn Close Procurements)
| ⚠ Điểm quan trọng về sửa đổi hợp đồng | Nội dung |
|---|---|
| ⚠ Hợp đồng là văn bản PHÁP LÝ | ⚠ không sửa được bằng lời nói hay email tuỳ tiện |
| ⚠ Mọi thay đổi phải qua CONTRACT CHANGE CONTROL SYSTEM | |
| ⚠ Phải có chữ ký của cả hai bên | |
| ⚠ Thay đổi phạm vi thường kéo theo thay đổi GIÁ và THỜI GIAN | |
| ⚠ Nếu bỏ qua thủ tục | ⚠ rất dễ dẫn tới tranh chấp và khiếu nại |
| ⚠ Trình tự đúng khi bên liên quan xin thay đổi ảnh hưởng hợp đồng | Bước |
|---|---|
| ⚠ 1. Ghi nhận yêu cầu thay đổi chính thức | |
| ⚠ 2. Đánh giá tác động tới phạm vi, chi phí, lịch VÀ hợp đồng | |
| ⚠ 3. Đưa qua Perform Integrated Change Control | ⚠ CCB phê duyệt |
| ⚠ 4. Đàm phán sửa đổi hợp đồng với nhà cung cấp | ⚠ thuộc Control Procurements |
| ⚠ 5. Ký phụ lục hợp đồng | |
| ⚠ 6. Cập nhật đường cơ sở và các kế hoạch |
| ⚠ Ba loại hợp đồng và độ nhạy với thay đổi | Loại |
|---|---|
| ⚠ Fixed Price (FP) | ⚠ rủi ro thuộc NHÀ CUNG CẤP; thay đổi phạm vi thường ĐẮT nhất |
| ⚠ Cost Reimbursable (CR) | ⚠ rủi ro thuộc NGƯỜI MUA; dễ điều chỉnh phạm vi hơn |
| ⚠ Time and Material (T&M) | ⚠ linh hoạt nhất, phù hợp việc chưa rõ phạm vi; rủi ro chi phí thuộc người mua |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thay đổi này có chạm vào phần việc đã ký không | ⚠ quyết định có phải sửa hợp đồng không | | Ai có thẩm quyền ký sửa đổi hợp đồng | ⚠ thường KHÔNG phải quản lý dự án | | Đã đánh giá tác động chi phí trước khi hứa gì chưa | |
Và ranh giới cần thuộc: Control Scope giữ phạm vi DỰ ÁN, Control Procurements giữ phạm vi HỢP ĐỒNG. Một thay đổi có thể chạm cả hai, nhưng câu hỏi về hợp đồng luôn dẫn về quy trình mua sắm.
- A Define the cost of the problem; Define the problem’s root cause; Generate a cost estimate for the solution to the problem; Select the best solution for the problem; Implement the selected solution; Test and verify the solution’s effectiveness.
- B Define the problem; Define the problem’s root cause; Generate solutions to the problem; Select the best solution for the problem; Implement the selected solution; Test and verify the solution’s effectiveness.
- C Define the problem; Define the contributing parties; Generate solutions to the problem; Select the best solution for the problem; Implement the selected solution; Test and verify the solution’s effectiveness.
- D Define the problem; Define the problem’s root cause; Generate solutions to the problem; Select the best people to implement the solution; Implement the selected solution; Test and verify the solution’s effectiveness.
Xem giải thích
Đáp án
B — Định nghĩa vấn đề → Tìm nguyên nhân gốc → Sinh ra các giải pháp → Chọn giải pháp tốt nhất → Thực hiện giải pháp đã chọn → Kiểm thử và xác nhận giải pháp.
Vì sao đúng
⚠ Sáu bước giải quyết vấn đề: | Bước | Nội dung | |---|---| | ⚠ 1. Định nghĩa VẤN ĐỀ | ⚠ nói rõ chuyện gì đang xảy ra, không phải nói về chi phí hay về ai gây ra | | ⚠ 2. Tìm NGUYÊN NHÂN GỐC | ⚠ sửa triệu chứng thì vấn đề quay lại | | ⚠ 3. SINH RA các giải pháp | ⚠ nhiều phương án, chưa đánh giá vội | | ⚠ 4. CHỌN giải pháp tốt nhất | | | ⚠ 5. THỰC HIỆN giải pháp đã chọn | | | ⚠ 6. KIỂM THỬ và XÁC NHẬN | ⚠ giải pháp có thật sự giải quyết được không |
Vì sao các phương án khác sai
-
A — ⚠ SAI ngay bước 1: ⚠ "định nghĩa CHI PHÍ của vấn đề" thay vì định nghĩa chính vấn đề; ⚠ chưa hiểu vấn đề thì không tính được chi phí.
-
C — ⚠ SAI ở bước 2: ⚠ "xác định các bên góp phần" thay vì tìm nguyên nhân gốc; ⚠ đi tìm người thay vì tìm nguyên nhân là công thức của văn hoá đổ lỗi.
-
D — ⚠ SAI ở bước 4: ⚠ "chọn NGƯỜI tốt nhất để thực hiện" thay vì chọn GIẢI PHÁP tốt nhất; ⚠ chọn người là việc của bước thực hiện.
Ghi nhớ
Từ khoá nhận diện:
"bước đầu tiên" → ⚠ luôn là ĐỊNH NGHĨA VẤN ĐỀ "bước thứ hai" → ⚠ NGUYÊN NHÂN GỐC, không phải tìm người "bước cuối" → ⚠ KIỂM CHỨNG, không dừng ở thực hiện "phương án nào nhắc tới tiền hoặc người ở bước sai chỗ" → ⚠ loại ngay
| ⚠ Công cụ cho bước tìm nguyên nhân gốc | Công cụ |
|---|---|
| ⚠ Biểu đồ nhân quả (Ishikawa / xương cá) | ⚠ nhóm nguyên nhân theo loại |
| ⚠ Năm câu hỏi Vì sao (5 Whys) | ⚠ hỏi "vì sao" tới khi chạm nguyên nhân gốc |
| ⚠ Phân tích Pareto | ⚠ chọn vấn đề nào đáng truy trước |
| ⚠ Sơ đồ quan hệ nhân quả |
| ⚠ Vì sao bước 6 hay bị bỏ qua nhất | Lý do |
|---|---|
| ⚠ Ai cũng nhẹ nhõm khi đã "làm gì đó" | |
| ⚠ Không ai quay lại kiểm tra kết quả | |
| ⚠ Hậu quả: vấn đề tái diễn sau vài tháng | |
| ⚠ Cách chữa | ⚠ đặt lịch rà soát cụ thể ngay khi triển khai giải pháp |
| ⚠ Sai lầm phổ biến ở bước 1 | Sai lầm |
|---|---|
| ⚠ Mô tả GIẢI PHÁP thay vì mô tả vấn đề | ⚠ "chúng ta cần thêm người" không phải một vấn đề |
| ⚠ Mô tả TRIỆU CHỨNG thay vì vấn đề | |
| ⚠ Đưa NGƯỜI vào phát biểu vấn đề | ⚠ "Tom làm chậm" thay vì "khâu kiểm thử mất gấp đôi thời gian dự kiến" |
| ⚠ Phát biểu vấn đề tốt | ⚠ cụ thể, đo được, không chứa giải pháp, không chứa tên người |
⚠ Đối chiếu: ⚠ câu #25626 ở lô trước về Pareto và Ishikawa. ⚠ Hai công cụ đó phục vụ trực tiếp bước 1 và bước 2 của quy trình này.
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phát biểu vấn đề của bạn có chứa giải pháp không | ⚠ nếu có thì bạn đã nhảy cóc | | Bạn đã hỏi "vì sao" đủ sâu chưa | | | Đã đặt lịch kiểm chứng kết quả chưa | |
Và điều phân biệt người giải quyết vấn đề giỏi: họ chậm ở hai bước đầu và nhanh ở bốn bước sau. Nhảy thẳng vào giải pháp là cách chắc chắn nhất để sửa nhầm thứ.
- A Comparable
- B Direct
- C Parametric
- D Analogous
Xem giải thích
Đáp án
D — Analogous (ước lượng tương tự).
Vì sao đúng
⚠ Dấu hiệu ước lượng tương tự trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ Nhà tài trợ muốn con số NHANH | ⚠ "a quick estimate" | | ⚠ Dựa vào một dự án TƯƠNG TỰ ĐÃ LÀM | ⚠ dự án cũ tốn 250.000 | | ⚠ Điều chỉnh theo cảm nhận về quy mô | ⚠ lớn hơn một chút → 275.000 | | ⚠ Không phân rã công việc, không tính từng phần | | | ⚠ Kết luận | ⚠ đúng định nghĩa analogous estimating — dùng dữ liệu lịch sử và phán đoán chuyên gia |
Vì sao các phương án khác sai
-
C (Parametric) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ước lượng tham số dùng ⚠ quan hệ THỐNG KÊ và ĐƠN GIÁ (⚠ ví dụ 147 đồng mỗi thiết bị × 750 thiết bị); ⚠ Ernesto không dùng đơn giá nào cả, ⚠ chỉ ước chừng "lớn hơn một chút".
-
A (Comparable) — ⚠ không phải thuật ngữ PMBOK; ⚠ nghe rất hợp lý nhưng tên chuẩn là "analogous".
-
B (Direct) — ⚠ không phải một loại ước lượng.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25617 ở lô trước về ước lượng ba điểm (beta) và câu #25647 ở lô này về ước lượng dứt khoát cần WBS. ⚠ Ba câu hợp lại thành bộ đầy đủ bốn kỹ thuật ước lượng.
⚠ Bốn kỹ thuật ước lượng — bảng so sánh: | Kỹ thuật | Cơ sở | Tốc độ | Độ chính xác | |---|---|---|---| | ⚠ Analogous | ⚠ dự án tương tự đã làm + phán đoán chuyên gia | ⚠ NHANH nhất | ⚠ THẤP nhất | | ⚠ Parametric | ⚠ quan hệ thống kê, đơn giá × số lượng | ⚠ nhanh | ⚠ trung bình đến cao | | ⚠ Three-point | ⚠ lạc quan, khả dĩ nhất, bi quan | ⚠ trung bình | ⚠ có tính bất định | | ⚠ Bottom-up | ⚠ cộng từ từng gói công việc của WBS | ⚠ CHẬM nhất | ⚠ CAO nhất |
Từ khoá nhận diện:
"nhanh, dựa vào dự án trước" → ⚠ analogous "đơn giá nhân số lượng" → ⚠ parametric "ba điểm ước lượng" → ⚠ three-point / beta "cộng từ dưới lên theo WBS" → ⚠ bottom-up "top-down" → ⚠ cách gọi khác của analogous
| ⚠ Khi nào dùng analogous là hợp lý | Trường hợp |
|---|---|
| ⚠ Giai đoạn rất sớm, thông tin ít | |
| ⚠ Cần con số ngay để quyết định có làm dự án không | |
| ⚠ Có dự án cũ THẬT SỰ tương tự | ⚠ điều kiện quan trọng nhất |
| ⚠ Chấp nhận được sai số lớn | |
| ⚠ Rủi ro | ⚠ "tương tự" là đánh giá chủ quan — hai dự án nhìn giống nhau có thể khác hẳn về độ phức tạp |
| ⚠ Cách làm analogous cho tốt hơn | Cách |
|---|---|
| ⚠ Chọn dự án tham chiếu có dữ liệu THẬT, không dựa vào trí nhớ | |
| ⚠ Nêu rõ các khác biệt giữa hai dự án | |
| ⚠ Điều chỉnh theo hệ số quy mô có lý giải | ⚠ "lớn hơn 10%" phải nói được lớn hơn ở chỗ nào |
| ⚠ LUÔN kèm dải sai số | ⚠ 275.000 ± bao nhiêu |
| ⚠ Ernesto nên bổ sung | ⚠ nói rõ đây là ước lượng thô và hẹn ngày có con số chi tiết |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án tham chiếu có thật sự tương tự không | ⚠ về quy mô, công nghệ, đội ngũ, môi trường | | Bạn có dữ liệu chi phí thật của dự án cũ không | ⚠ hay chỉ nhớ mang máng | | Con số này sẽ bị dùng làm ngân sách chứ | ⚠ nếu có thì phải cảnh báo trước |
Và rủi ro nghề nghiệp lớn nhất của ước lượng tương tự: nó nghe rất chắc chắn vì dựa trên "kinh nghiệm thật". Hai dự án giống nhau ở bề mặt vẫn có thể chênh nhau gấp đôi về công sức, nên con số 275.000 cần đi kèm chữ "khoảng".
- A HUSTL
- B SIPOC
- C PESTLE
- D GERT
Xem giải thích
Đáp án
B — SIPOC.
Vì sao đúng
⚠ SIPOC là gì: | Chữ | Nghĩa | |---|---| | ⚠ S — Suppliers | ⚠ NHÀ CUNG CẤP: ai cung cấp đầu vào | | ⚠ I — Inputs | ⚠ ĐẦU VÀO: vật tư, thông tin, tài nguyên | | ⚠ P — Process | ⚠ QUY TRÌNH: các bước biến đầu vào thành đầu ra | | ⚠ O — Outputs | ⚠ ĐẦU RA: sản phẩm hoặc dịch vụ tạo ra | | ⚠ C — Customers | ⚠ KHÁCH HÀNG: ai nhận đầu ra | | ⚠ Vì sao khớp đề | ⚠ nhà tài trợ muốn thấy NHÀ CUNG CẤP và KHÁCH HÀNG tương tác thế nào — đúng hai đầu của SIPOC |
Vì sao các phương án khác sai
-
C (PESTLE) — ⚠ là khung phân tích MÔI TRƯỜNG BÊN NGOÀI: ⚠ Political, Economic, Social, Technological, Legal, Environmental; ⚠ không phải lưu đồ quy trình.
-
D (GERT) — ⚠ Graphical Evaluation and Review Technique: ⚠ là kỹ thuật sơ đồ mạng cho phép ⚠ vòng lặp và nhánh có điều kiện; ⚠ dùng cho lịch trình, không mô tả nhà cung cấp và khách hàng.
-
A (HUSTL) — ⚠ không phải thuật ngữ nào cả.
Ghi nhớ
⚠ SIPOC dùng để làm gì: | Công dụng | Nội dung | |---|---| | ⚠ Nhìn TOÀN CẢNH một quy trình trên MỘT trang | | | ⚠ Xác định RANH GIỚI quy trình | ⚠ bắt đầu ở đâu, kết thúc ở đâu | | ⚠ Tìm ra ai là bên liên quan thật sự | ⚠ cả đầu vào lẫn đầu ra | | ⚠ Là bước đầu của dự án cải tiến quy trình | ⚠ rất hay dùng trong Six Sigma, giai đoạn Define | | ⚠ Ưu điểm | ⚠ đơn giản tới mức ai cũng đọc được, kể cả lãnh đạo không rành kỹ thuật |
Từ khoá nhận diện:
"nhà cung cấp, đầu vào, quy trình, đầu ra, khách hàng" → ⚠ SIPOC "chính trị, kinh tế, xã hội, công nghệ, pháp lý, môi trường" → ⚠ PESTLE "sơ đồ mạng có vòng lặp và nhánh điều kiện" → ⚠ GERT "hệ thống và người dùng tương tác" → ⚠ context diagram "điểm mạnh, điểm yếu, cơ hội, thách thức" → ⚠ SWOT
| ⚠ Các khung phân tích hay ra thi | Khung |
|---|---|
| ⚠ SWOT | ⚠ mạnh, yếu, cơ hội, thách thức — hay dùng ở nhận diện rủi ro |
| ⚠ PESTLE | ⚠ sáu yếu tố môi trường bên ngoài |
| ⚠ SIPOC | ⚠ năm thành phần của một quy trình |
| ⚠ RACI | ⚠ ma trận trách nhiệm: làm, chịu trách nhiệm, tham vấn, thông báo |
| ⚠ Power/Interest grid | ⚠ phân loại bên liên quan theo quyền lực và mức quan tâm |
| ⚠ Cách dựng một SIPOC | Bước |
|---|---|
| ⚠ Bắt đầu từ P — vẽ quy trình ở mức 4–7 bước | ⚠ đừng chi tiết quá |
| ⚠ Rồi tới O — quy trình tạo ra cái gì | |
| ⚠ Rồi tới C — ai nhận cái đó | |
| ⚠ Rồi tới I — quy trình cần gì để chạy | |
| ⚠ Cuối cùng S — ai cấp những đầu vào đó | |
| ⚠ Mẹo | ⚠ làm theo thứ tự P-O-C-I-S dù tên viết tắt là SIPOC |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ranh giới quy trình đã rõ chưa | ⚠ SIPOC ép bạn phải nói rõ điểm đầu và điểm cuối | | Bạn đã bỏ sót nhà cung cấp hay khách hàng nào không | ⚠ đây là cách tìm bên liên quan bị quên | | Quy trình có quá nhiều bước trên sơ đồ không | ⚠ quá 7 bước là mất tác dụng tổng quan |
Và lý do SIPOC vẫn sống lâu như vậy: nó buộc cả nhóm thống nhất xem quy trình bắt đầu và kết thúc ở đâu trước khi bàn cải tiến. Rất nhiều dự án cải tiến thất bại chỉ vì mỗi người hiểu ranh giới một kiểu.
- A $147
- B $102
- C $150
- D $83
Xem giải thích
Đáp án
A — 147 mỗi thiết bị.
Vì sao đúng
⚠ Phép tính: | Bước | Phép tính | |---|---| | ⚠ Tổng chi phí | ⚠ 110.250 | | ⚠ Số thiết bị | ⚠ 750 | | ⚠ Đơn giá mỗi thiết bị | ⚠ 110.250 / 750 = 147 | | ⚠ Kiểm tra ngược | ⚠ 147 × 750 = 110.250 ✓ |
⚠ Vì sao gọi là ước lượng tham số: | Đặc điểm | Nội dung | |---|---| | ⚠ Có một ĐƠN GIÁ cho mỗi đơn vị | ⚠ 147 mỗi thiết bị | | ⚠ Nhân với SỐ LƯỢNG | ⚠ 750 thiết bị | | ⚠ Đơn giá đã bao gồm cả NHÂN CÔNG | ⚠ đề nói rõ "labor per fixture" | | ⚠ Công thức chung | ⚠ chi phí = đơn giá × số lượng |
Vì sao các phương án khác sai
-
B (102) — ⚠ 102 × 750 = 76.500, ⚠ không khớp tổng chi phí.
-
C (150) — ⚠ 150 × 750 = 112.500, ⚠ lớn hơn 110.250; ⚠ đây là con số tròn dễ đoán nhầm.
-
D (83) — ⚠ 83 × 750 = 62.250, ⚠ sai xa.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25654 ở lô này về ước lượng tương tự. ⚠ Hai câu là cặp đối chiếu trực tiếp: analogous dựa vào dự án cũ, parametric dựa vào đơn giá — đây là hai kỹ thuật hay bị lẫn nhất.
⚠ Ước lượng tham số — parametric estimating: | Đặc điểm | Nội dung | |---|---| | ⚠ Dựa trên QUAN HỆ THỐNG KÊ giữa dữ liệu lịch sử và biến số | | | ⚠ Cần có ĐƠN GIÁ đáng tin từ dữ liệu quá khứ | | | ⚠ Cần số lượng đo được | | | ⚠ Độ chính xác PHỤ THUỘC vào chất lượng đơn giá | | | ⚠ Ví dụ khác | ⚠ 1.200 đồng mỗi viên gạch, 8 giờ mỗi mét vuông sơn, 15 triệu mỗi trang thiết kế |
Từ khoá nhận diện:
"mỗi đơn vị tốn bao nhiêu, nhân với số lượng" → ⚠ parametric "dự án trước tốn bao nhiêu, cái này lớn hơn chút" → ⚠ analogous "chia tổng cho số lượng" → ⚠ đang tìm tham số đơn giá "cộng từng gói công việc" → ⚠ bottom-up
| ⚠ Khi nào parametric CHÍNH XÁC | Điều kiện |
|---|---|
| ⚠ Đơn giá lấy từ dữ liệu lịch sử ĐÁNG TIN | |
| ⚠ Công việc có tính LẶP LẠI cao | ⚠ 750 thiết bị giống nhau là ví dụ lý tưởng |
| ⚠ Quan hệ tuyến tính giữa số lượng và chi phí | |
| ⚠ Khi nào KHÔNG chính xác | ⚠ công việc sáng tạo, mỗi đơn vị mỗi khác, có hiệu ứng quy mô mạnh |
| ⚠ Bẫy của ước lượng tham số | Bẫy |
|---|---|
| ⚠ Bỏ qua HIỆU ỨNG HỌC TẬP | ⚠ thiết bị thứ 700 lắp nhanh hơn thiết bị thứ 1 |
| ⚠ Bỏ qua chi phí CỐ ĐỊNH | ⚠ thuê giàn giáo không nhân theo số thiết bị |
| ⚠ Dùng đơn giá cũ mà không tính trượt giá | |
| ⚠ Áp đơn giá của bối cảnh khác | ⚠ đơn giá thành thị áp cho vùng xa |
| ⚠ Cách phòng | ⚠ nêu rõ đơn giá lấy từ đâu và giả định gì đi kèm |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đơn giá của bạn lấy từ đâu | ⚠ dữ liệu thật hay ước chừng | | Đơn giá đã bao gồm những gì | ⚠ vật tư, nhân công, vận chuyển, lắp đặt? | | Có chi phí cố định nào không nhân theo số lượng không | |
Và điểm mạnh của kỹ thuật này khi bị chất vấn: bạn có thể GIẢI TRÌNH được con số. "147 mỗi thiết bị, đã gồm nhân công, nhân 750" là câu trả lời kiểm chứng được — khác hẳn với "khoảng 110.000, tôi ước chừng vậy".
- A WBS
- B Code of accounts
- C Requirements tracking matrix
- D WBS dictionary
Xem giải thích
Đáp án
B — Code of accounts (hệ thống mã tài khoản).
Vì sao đúng
⚠ Vì sao cần code of accounts: | Vấn đề trong đề | Giải pháp | |---|---| | ⚠ Nhiều cấu phần GIỐNG HỆT nhau | ⚠ các màn hình tivi lắp khắp toà nhà | | ⚠ Tên gọi không phân biệt được chúng | ⚠ đều là "màn hình tivi" | | ⚠ Cần theo dõi từng cái riêng biệt | | | ⚠ Code of accounts | ⚠ gán MÃ SỐ DUY NHẤT cho mỗi cấu phần và gói công việc của WBS |
⚠ Đặc điểm: | Điều | Nội dung | |---|---| | ⚠ Là hệ thống ĐÁNH SỐ theo cấp bậc | ⚠ ví dụ 1.2.3.1, 1.2.3.2 | | ⚠ Mã phản ánh vị trí trong cây WBS | | | ⚠ Cho phép LIÊN KẾT với hệ thống kế toán của tổ chức | ⚠ theo dõi chi phí theo mã | | ⚠ Là một mục trong WBS dictionary | ⚠ "code of account identifier" | | ⚠ Công dụng | ⚠ truy vết yêu cầu, tổng hợp chi phí, báo cáo tiến độ theo nhánh |
Vì sao các phương án khác sai
-
D (WBS dictionary) — ⚠ MÔ TẢ CHI TIẾT từng gói công việc, ⚠ nhưng bản thân nó không phải cơ chế định danh; ⚠ nó CHỨA mã tài khoản chứ không phải là mã.
-
A (WBS) — ⚠ là cây phân rã công việc, ⚠ chỉ có tên các cấu phần; ⚠ cấu phần trùng tên thì WBS không phân biệt được.
-
C (Requirements tracking matrix) — ⚠ ma trận truy vết yêu cầu: ⚠ liên kết YÊU CẦU với bàn giao, ⚠ không định danh cấu phần WBS.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25619 ở lô trước về từ điển WBS và câu #25627 về planning package. ⚠ Ba câu cùng chủ đề WBS — nên học liền một lượt.
⚠ Bộ ba tài liệu WBS: | Tài liệu | Vai trò | |---|---| | ⚠ WBS | ⚠ cây phân rã, thấy được cấu trúc | | ⚠ WBS dictionary | ⚠ chi tiết từng gói công việc | | ⚠ Code of accounts | ⚠ hệ thống MÃ SỐ định danh duy nhất |
Từ khoá nhận diện:
"định danh duy nhất, theo dõi từng cấu phần" → ⚠ code of accounts "mô tả chi tiết gói công việc" → ⚠ WBS dictionary "yêu cầu này đến từ đâu, đi tới đâu" → ⚠ requirements traceability matrix "điểm quản lý tổng hợp chi phí" → ⚠ control account
| ⚠ Ví dụ một hệ mã tài khoản | Mã |
|---|---|
| ⚠ 1 | ⚠ Dự án lắp đặt hệ thống nghe nhìn |
| ⚠ 1.2 | ⚠ Khu vực sảnh |
| ⚠ 1.2.3 | ⚠ Màn hình hiển thị |
| ⚠ 1.2.3.1 | ⚠ Màn hình sảnh chính |
| ⚠ 1.2.3.2 | ⚠ Màn hình sảnh phụ |
| ⚠ Nhờ mã này | ⚠ hai màn hình cùng loại vẫn theo dõi riêng được |
| ⚠ Lợi ích thực tế | Lợi ích |
|---|---|
| ⚠ Ghép được với hệ thống kế toán | ⚠ chi phí thực tế đổ đúng nhánh |
| ⚠ Tổng hợp báo cáo theo bất kỳ cấp nào | |
| ⚠ Không nhầm lẫn giữa các hạng mục trùng tên | |
| ⚠ Truy vết được yêu cầu tới bàn giao |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ mã của bạn có khớp hệ thống kế toán không | ⚠ lệch nhau thì báo cáo chi phí vô nghĩa | | Mỗi gói công việc có đúng một mã chứ | | | Mã có ổn định khi WBS thay đổi không | ⚠ đánh số lại toàn bộ là cơn ác mộng |
Và lý do nghe nhàm chán nhưng rất quan trọng: không định danh được thì không đo được. Ba mươi màn hình cùng tên mà không có mã thì mọi báo cáo tiến độ và chi phí đều chỉ là ước chừng.
- A It’s the path with the most important activities in the project network diagram.
- B It’s the path that cannot be crashed in the project network diagram.
- C It’s the longest path of activities in the project network diagram.
- D It’s the longest path of duration in the project network diagram.
Xem giải thích
Đáp án
D — Là đường có TỔNG THỜI LƯỢNG DÀI NHẤT trong sơ đồ mạng dự án.
Vì sao đúng
⚠ Định nghĩa chính xác của đường găng: | Điều | Nội dung | |---|---| | ⚠ Là chuỗi hoạt động có TỔNG THỜI LƯỢNG dài nhất | | | ⚠ Quyết định thời gian NGẮN NHẤT có thể hoàn thành dự án | | | ⚠ Các hoạt động trên đó có TOTAL FLOAT bằng 0 | ⚠ hoặc âm nếu dự án đã trễ | | ⚠ Trễ một ngày trên đường găng = trễ cả dự án một ngày | | | ⚠ Một dự án | ⚠ có thể có NHIỀU đường găng cùng lúc — càng nhiều càng rủi ro |
Vì sao các phương án khác sai
-
C (đường có NHIỀU HOẠT ĐỘNG nhất) — ⚠ phương án gây nhiễu MẠNH NHẤT, chỉ khác một chữ: ⚠ đường găng tính theo ⚠ THỜI LƯỢNG, không phải theo SỐ LƯỢNG hoạt động; ⚠ một đường có 3 hoạt động mỗi cái 10 ngày (30 ngày) dài hơn đường có 10 hoạt động mỗi cái 2 ngày (20 ngày).
-
A (đường có các hoạt động QUAN TRỌNG nhất) — ⚠ hiểu sai chữ "critical": ⚠ ở đây "critical" nghĩa là ⚠ quyết định thời hạn, không phải "quan trọng về mặt nghiệp vụ".
-
B (đường KHÔNG THỂ nén được) — ⚠ SAI ngược: ⚠ đường găng chính là đường ⚠ DUY NHẤT đáng nén — nén đường khác không rút ngắn được dự án.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25603 ở lô trước về free float. ⚠ Hai câu cùng thuộc bộ khái niệm phương pháp đường găng.
⚠ Các khái niệm đường găng cần thuộc: | Khái niệm | Nghĩa | |---|---| | ⚠ Total float | ⚠ trễ bao lâu mà KHÔNG ảnh hưởng ngày kết thúc DỰ ÁN | | ⚠ Free float | ⚠ trễ bao lâu mà KHÔNG ảnh hưởng ngày bắt đầu SỚM NHẤT của việc kế tiếp | | ⚠ Đường găng | ⚠ total float = 0 | | ⚠ Near-critical path | ⚠ float rất nhỏ — dễ trở thành đường găng khi có trục trặc | | ⚠ Công thức | ⚠ Total float = LS − ES = LF − EF |
Từ khoá nhận diện:
"đường dài nhất về thời lượng" → ⚠ đường găng "đường nhiều hoạt động nhất" → ⚠ SAI, đây là bẫy "trễ là cả dự án trễ" → ⚠ hoạt động trên đường găng "float bằng 0" → ⚠ đường găng "rút ngắn dự án" → ⚠ chỉ nén được bằng cách tác động vào đường găng
| ⚠ Hai cách nén lịch | Cách |
|---|---|
| ⚠ Crashing | ⚠ thêm NGUỒN LỰC vào đường găng — tăng CHI PHÍ |
| ⚠ Fast tracking | ⚠ chạy SONG SONG các việc vốn nối tiếp — tăng RỦI RO và có thể phải làm lại |
| ⚠ Cả hai | ⚠ chỉ có tác dụng khi áp lên ĐƯỜNG GĂNG |
| ⚠ Cảnh báo | ⚠ nén xong phải TÍNH LẠI đường găng — đường khác có thể trở thành găng |
| ⚠ Nhầm lẫn hay gặp về đường găng | Đính chính |
|---|---|
| ⚠ "Dự án chỉ có một đường găng" | ⚠ có thể có nhiều — rủi ro cao hơn |
| ⚠ "Đường găng cố định suốt dự án" | ⚠ thay đổi khi tiến độ thực tế thay đổi |
| ⚠ "Việc trên đường găng là việc quan trọng nhất" | ⚠ quan trọng về LỊCH, không nhất thiết về giá trị |
| ⚠ "Total float luôn dương" | ⚠ âm khi dự án đã trễ so với hạn ràng buộc |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết đường găng hiện tại của dự án không | ⚠ phải tính lại thường xuyên | | Có đường nào gần thành găng không | ⚠ near-critical cần theo dõi sát | | Nguồn lực có được ưu tiên cho đường găng không | |
Và câu định nghĩa cần thuộc nguyên văn: đường găng là đường DÀI NHẤT VỀ THỜI LƯỢNG, và vì thế nó là thời gian NGẮN NHẤT để hoàn thành dự án. Nghe nghịch lý nhưng đó chính là điểm mấu chốt của phương pháp.
- A Hygiene agents
- B Uniform agents
- C Stability agents
- D Motivating agents
Xem giải thích
Đáp án
A — Hygiene agents (yếu tố duy trì).
Vì sao đúng
⚠ Thuyết Hai Yếu Tố của Herzberg: | Nhóm | Nội dung | Tác dụng | |---|---|---| | ⚠ Hygiene — DUY TRÌ | ⚠ lương, điều kiện làm việc, chính sách công ty, quan hệ với cấp trên, an toàn công việc, địa vị | ⚠ thiếu thì BẤT MÃN; có đủ chỉ hết bất mãn, KHÔNG tạo động lực | | ⚠ Motivator — ĐỘNG VIÊN | ⚠ thành tựu, được ghi nhận, bản thân công việc, trách nhiệm, thăng tiến, phát triển | ⚠ có thì tạo ĐỘNG LỰC thật |
⚠ Áp vào tình huống: | Chi tiết | Suy ra | |---|---| | ⚠ Thành viên CHƯA ĐƯỢC TRẢ LƯƠNG | ⚠ → yếu tố duy trì bị THIẾU | | ⚠ Họ BẤT MÃN với dự án | ⚠ → đúng hệ quả Herzberg dự đoán | | ⚠ Lương | ⚠ là hygiene agent điển hình nhất |
Vì sao các phương án khác sai
-
D (Motivating agents) — ⚠ SAI theo Herzberg: ⚠ tiền lương ⚠ không tạo động lực lâu dài; ⚠ tăng lương chỉ hết bất mãn một thời gian rồi trở thành mức bình thường mới.
-
B (Uniform agents) và C (Stability agents) — ⚠ không phải thuật ngữ trong thuyết Herzberg.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25641 ở lô này về thuyết McClelland. ⚠ Hai câu cùng thuộc bộ thuyết động lực — bảng so sánh đầy đủ nằm ở giải thích của câu đó.
Từ khoá nhận diện:
"lương, điều kiện, chính sách, an toàn công việc" → ⚠ hygiene "thành tựu, ghi nhận, trách nhiệm, thăng tiến" → ⚠ motivator "thiếu thì bất mãn nhưng có cũng không tạo động lực" → ⚠ hygiene "tháp năm bậc" → ⚠ Maslow, KHÔNG phải Herzberg
| ⚠ Điểm cốt lõi Herzberg hay bị hiểu sai | Đính chính |
|---|---|
| ⚠ "Hài lòng" và "bất mãn" KHÔNG phải hai đầu một thang | ⚠ chúng là HAI thang riêng biệt |
| ⚠ Ngược lại của bất mãn là KHÔNG bất mãn | ⚠ không phải là hài lòng |
| ⚠ Sửa yếu tố duy trì chỉ đưa về mức trung tính | |
| ⚠ Muốn có động lực thật | ⚠ phải tác động vào nhóm ĐỘNG VIÊN |
| ⚠ PM nên làm gì trong tình huống này | Bước |
|---|---|
| ⚠ 1. Xử lý NGAY vấn đề lương | ⚠ liên hệ công ty nhà thầu — đây là việc cấp bách |
| ⚠ 2. Minh bạch với đội về tiến trình xử lý | |
| ⚠ 3. ĐỪNG cố bù bằng lời khen hay phần thưởng tinh thần | ⚠ yếu tố duy trì thiếu thì động viên vô tác dụng |
| ⚠ 4. Sau khi ổn định mới bàn tới động lực | |
| ⚠ Nguyên tắc | ⚠ dọn sạch yếu tố duy trì TRƯỚC, xây động lực SAU |
| ⚠ Ứng dụng thực tế cho quản lý dự án | Ứng dụng |
|---|---|
| ⚠ Đừng nghĩ thưởng tiền sẽ giải quyết vấn đề động lực | |
| ⚠ Nhưng lương và điều kiện tệ thì chắc chắn phá động lực | |
| ⚠ Giao việc có ý nghĩa và trao trách nhiệm là động viên thật | |
| ⚠ Ghi nhận công khai, đúng lúc, cụ thể | ⚠ rẻ hơn tiền và bền hơn |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yếu tố duy trì nào đang thiếu trong đội bạn không | ⚠ lương, thiết bị, môi trường, sự rõ ràng về vai trò | | Bạn có đang dùng phần thưởng để chữa vấn đề duy trì không | | | Công việc bạn giao có tạo cảm giác thành tựu không | |
Và bài học nghề nghiệp: không thể động viên một người đang không được trả lương. Herzberg giải thích chính xác vì sao — và đó cũng là lý do việc đầu tiên PM phải làm là gỡ vướng chuyện tiền, không phải tổ chức một buổi gắn kết đội.
- A Iteration burndown chart
- B Forecast chart
- C Agile chart
- D Scrum chart
Xem giải thích
Đáp án
A — Iteration burndown chart (biểu đồ đốt việc theo vòng lặp).
Vì sao đúng
⚠ Burndown chart là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Trục ngang: THỜI GIAN | ⚠ ngày trong vòng lặp, hoặc số vòng lặp | | ⚠ Trục dọc: KHỐI LƯỢNG CÔNG VIỆC CÒN LẠI | ⚠ điểm story, giờ, hoặc số hạng mục | | ⚠ Đường ĐI XUỐNG khi việc được hoàn thành | ⚠ "burn down" — đốt dần | | ⚠ Có đường lý tưởng để so sánh | | | ⚠ Trả lời câu hỏi | ⚠ "còn bao nhiêu việc chưa làm?" — đúng điều Jen cần |
Vì sao các phương án khác sai
- B (Forecast chart), C (Agile chart), D (Scrum chart) — ⚠ cả ba đều KHÔNG phải thuật ngữ có thật trong Agile Practice Guide hay PMBOK; ⚠ đây là các phương án bịa.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Đề nói "product backlog" nhưng đáp án là "ITERATION burndown chart" — có chút lệch. ⚠ Chính xác thì: ⚠ iteration burndown theo dõi công việc còn lại trong VÒNG LẶP hiện tại, ⚠ còn ⚠ release burndown hoặc product burndown mới theo dõi toàn bộ product backlog. ⚠ Ba phương án còn lại đều là tên bịa nên A là lựa chọn duy nhất hợp lệ — giữ nguyên khoá A, ⚠ nhưng người học cần phân biệt hai loại biểu đồ này khi gặp đề chính xác hơn.
⚠ Các biểu đồ theo dõi trong dự án linh hoạt: | Biểu đồ | Theo dõi gì | |---|---| | ⚠ Iteration burndown | ⚠ việc còn lại trong VÒNG LẶP hiện tại | | ⚠ Release / Product burndown | ⚠ việc còn lại trong toàn bộ backlog | | ⚠ Burnup chart | ⚠ việc ĐÃ LÀM đi lên, kèm đường tổng phạm vi — thấy được scope creep | | ⚠ Cumulative flow diagram (CFD) | ⚠ số hạng mục ở từng trạng thái — phát hiện NÚT THẮT | | ⚠ Velocity chart | ⚠ tốc độ hoàn thành qua các vòng lặp |
Từ khoá nhận diện:
"còn bao nhiêu việc chưa làm" → ⚠ burndown "đã làm được bao nhiêu, phạm vi có phình không" → ⚠ burnup "công việc ùn ở khâu nào" → ⚠ cumulative flow diagram "đội làm được bao nhiêu điểm mỗi vòng" → ⚠ velocity
| ⚠ Vì sao nhiều đội thích burnUP hơn burnDOWN | Lý do |
|---|---|
| ⚠ Burndown trộn lẫn hai chuyện | ⚠ việc làm xong và phạm vi thay đổi đều làm đường đi xuống hoặc lên |
| ⚠ Burnup TÁCH RIÊNG hai đường | ⚠ đường hoàn thành và đường tổng phạm vi |
| ⚠ Nhìn burnup thấy ngay scope creep | ⚠ đường tổng phạm vi đi lên |
| ⚠ Burndown vẫn hữu ích | ⚠ đơn giản, dễ đọc trong phạm vi một vòng lặp |
| ⚠ Cách đọc một iteration burndown | Dấu hiệu |
|---|---|
| ⚠ Đường thực tế NẰM TRÊN đường lý tưởng | ⚠ đang chậm |
| ⚠ Đường phẳng nhiều ngày | ⚠ có việc bị kẹt, hoặc hạng mục quá lớn |
| ⚠ Đường đi LÊN | ⚠ có việc mới được thêm vào giữa vòng lặp |
| ⚠ Rơi thẳng đứng ở ngày cuối | ⚠ mọi thứ chỉ xong vào phút chót — dấu hiệu không lành |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang theo dõi vòng lặp hay toàn bộ backlog | ⚠ chọn đúng loại biểu đồ | | Đường có phẳng nhiều ngày liền không | ⚠ hạng mục quá lớn cần chia nhỏ | | Phạm vi có bị thêm giữa vòng lặp không | ⚠ burnup nhìn ra ngay |
Và giá trị lớn nhất của biểu đồ này: nó biến câu hỏi "chúng ta có kịp không?" thành một hình ảnh cả đội cùng nhìn thấy — không cần ai báo cáo, không cần ai phỏng đoán.
- A Cost of compliance
- B Liability costs
- C Cost of conformance to quality
- D Risk mitigation
Xem giải thích
Đáp án
C — Cost of conformance to quality (chi phí phù hợp chất lượng).
Vì sao đúng
⚠ Ba khoản chi trong đề đều là chi phí phù hợp: | Khoản chi | Loại | |---|---| | ⚠ Đào tạo chuyên sâu cho đội | ⚠ PREVENTION — phòng ngừa | | ⚠ Kiểm toán viên chất lượng kiểm tra mọi công việc | ⚠ APPRAISAL — thẩm định | | ⚠ Kiểm thử toàn bộ trước khi đưa vào vận hành | ⚠ APPRAISAL — thẩm định | | ⚠ Cả ba | ⚠ là tiền chi ra để NGĂN lỗi xảy ra hoặc BẮT lỗi trước khi giao — đúng định nghĩa cost of conformance |
Vì sao các phương án khác sai
-
A (Cost of compliance) — ⚠ nghe rất giống nhưng KHÔNG phải thuật ngữ PMBOK; ⚠ thuật ngữ chuẩn là "conformance"; ⚠ đây là phương án gây nhiễu mạnh nhất.
-
B (Liability costs — chi phí trách nhiệm pháp lý) — ⚠ thuộc nhóm KHÔNG phù hợp: ⚠ đó là cái phải trả KHI ĐÃ để lỗi lọt ra ngoài.
-
D (Risk mitigation — giảm nhẹ rủi ro) — ⚠ là một chiến lược ứng phó rủi ro, ⚠ không phải tên gọi của nhóm chi phí này; ⚠ dù về bản chất các hoạt động chất lượng cũng có tác dụng giảm rủi ro.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25628 ở lô này về chi phí KHÔNG phù hợp — ⚠ bỏ kiểm thử khiến lỗi lọt ra vận hành. ⚠ Hai câu là cặp đối lập hoàn chỉnh: câu kia là cái giá của việc CẮT chi phí phù hợp, câu này là chính chi phí đó.
⚠ Bốn nhóm chi phí chất lượng: | Nhánh | Loại | Ví dụ | |---|---|---| | ⚠ CONFORMANCE — phù hợp | ⚠ Prevention | ⚠ đào tạo, tài liệu quy trình, thiết bị tốt, thời gian làm cho đúng | | ⚠ CONFORMANCE — phù hợp | ⚠ Appraisal | ⚠ kiểm thử, kiểm toán, thanh tra, đo lường | | ⚠ NONCONFORMANCE — không phù hợp | ⚠ Internal failure | ⚠ làm lại, phế phẩm, sửa trước khi giao | | ⚠ NONCONFORMANCE — không phù hợp | ⚠ External failure | ⚠ bảo hành, thu hồi, mất uy tín, TRÁCH NHIỆM PHÁP LÝ |
Từ khoá nhận diện:
"đào tạo, kiểm thử, kiểm toán" → ⚠ cost of conformance "làm lại, bảo hành, kiện tụng" → ⚠ cost of nonconformance "ngăn lỗi xảy ra" → ⚠ prevention "phát hiện lỗi" → ⚠ appraisal
| ⚠ Vì sao dự án y tế phải chi mạnh cho chất lượng | Lý do |
|---|---|
| ⚠ Hậu quả lỗi ảnh hưởng SỨC KHOẺ và TÍNH MẠNG | |
| ⚠ Chịu quy định pháp lý nghiêm ngặt | |
| ⚠ Chi phí lỗi bên ngoài CỰC KỲ cao | ⚠ kiện tụng, thu hồi, mất giấy phép |
| ⚠ Vì thế | ⚠ Joan quyết định đúng, và ban lãnh đạo đồng ý chi là hợp lý |
| ⚠ Cân bằng chi phí chất lượng | Nguyên tắc |
|---|---|
| ⚠ Chi phù hợp TĂNG thì chi phí lỗi GIẢM | |
| ⚠ Có một điểm tối ưu — chi thêm nữa không đáng | |
| ⚠ Nhưng ở lĩnh vực rủi ro cao, điểm tối ưu nằm rất xa về phía phòng ngừa | |
| ⚠ Đừng | ⚠ coi chi phí chất lượng là khoản cắt được đầu tiên khi ngân sách căng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang chi bao nhiêu cho phòng ngừa so với sửa lỗi | ⚠ tỷ lệ nghiêng về sửa lỗi là dấu hiệu xấu | | Chi phí chất lượng có nằm trong ngân sách được duyệt không | ⚠ Joan đã làm đúng: xin duyệt trước | | Ngành của bạn có yêu cầu pháp lý nào bắt buộc không | |
Và cách trình bày với lãnh đạo khi xin ngân sách chất lượng: so sánh chi phí phòng ngừa với chi phí một lần lỗi lọt ra ngoài. Trong y tế, con số đó luôn thuyết phục.