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

Tìm thấy 720 câu.

Câu 311 People
You should understand several management theories for your project management exam and for your role as a project manager. Which theory posits that workers need to be involved with the management process?
  1. A McGregor's Theory of X and Y
  2. B Expectancy Theory
  3. C Ouchi's Theory Z
  4. D Herzberg's Theory of Motivation
Xem giải thích

Đáp án

C — THUYẾT Z CỦA OUCHI.

Vì sao đúng

⚠ Nội dung thuyết Z: | Đặc điểm | Nội dung | |---|---| | ⚠ NGƯỜI LAO ĐỘNG THAM GIA vào quá trình quản lý | ⚠ đúng từ khoá của câu hỏi | | ⚠ Ra quyết định theo ĐỒNG THUẬN | | | ⚠ Việc làm LÂU DÀI, gắn bó với tổ chức | | | ⚠ Quan tâm tới NGƯỜI LAO ĐỘNG như con người toàn diện | | | ⚠ Thăng tiến chậm, luân chuyển nhiều vị trí | | | ⚠ Nguồn gốc | ⚠ William Ouchi mô tả mô hình quản trị kiểu Nhật, kết hợp cách làm Nhật Bản và Mỹ | | ⚠ Kết quả kỳ vọng | ⚠ năng suất cao nhờ LÒNG TRUNG THÀNH và sự tham gia, không nhờ giám sát |

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

  • A (Thuyết X và Y của McGregor) — ⚠ phương án gây nhiễu mạnh nhất vì Thuyết Y cũng nói về việc tin tưởng nhân viên: ⚠ nhưng X và Y là ⚠ GIẢ ĐỊNH CỦA NHÀ QUẢN LÝ về bản chất nhân viên ⚠ (lười cần ép, hay tự giác), ⚠ KHÔNG nói về việc cho nhân viên THAM GIA vào quản lý — ⚠ đó là điểm riêng của Thuyết Z.

  • B (Thuyết kỳ vọng) — ⚠ về động lực qua chuỗi nỗ lực → kết quả → phần thưởng ⚠ (liên hệ #25930 lô 183).

  • D (Thuyết động lực của Herzberg) — ⚠ hai nhóm yếu tố: duy trì và tạo động lực.

Ghi nhớ

⚠ Đối chiếu — Thuyết Z đã xuất hiện HAI LẦN làm phương án NHIỄU trước khi thành khoá đáp án: ⚠ câu #25917 ở lô 183 (quy luật lợi ích giảm dần — Thuyết Z là phương án A sai) ⚠ và câu #25930 (thuyết kỳ vọng Vroom — Thuyết Z là phương án C sai). ⚠ Đây là lần đầu nó là ĐÁP ÁN ĐÚNG. ⚠ Bộ đề có thói quen dùng cùng một tập thuyết cho nhiều câu, luân phiên đổi khoá — thuộc CẢ BỘ là cách duy nhất làm đúng ổn định.

⚠ BẢNG ĐỐI CHIẾU đầy đủ các thuyết động lực và quản trị: | Thuyết | Ý chính | Từ khoá nhận diện | |---|---|---| | ⚠ OUCHI — Thuyết Z | ⚠ người lao động THAM GIA quản lý, gắn bó lâu dài, đồng thuận | ⚠ "tham gia", "kiểu Nhật", "việc làm trọn đời" — CÂU NÀY | | ⚠ McGREGOR — X và Y | ⚠ giả định của quản lý về nhân viên | ⚠ "cần giám sát chặt" hoặc "tự giác" | | ⚠ VROOM — Kỳ vọng | ⚠ nỗ lực → kết quả → phần thưởng đáng giá | ⚠ "được thưởng thì còn cố" | | ⚠ HERZBERG — Hai yếu tố | ⚠ duy trì ngăn bất mãn, tạo động lực mới thúc đẩy | ⚠ "lương không tạo động lực" | | ⚠ MASLOW — Tháp nhu cầu | ⚠ năm bậc từ dưới lên | ⚠ "tự thể hiện", "nhu cầu cơ bản" | | ⚠ McCLELLAND — Nhu cầu đạt được | ⚠ thành tựu / quyền lực / liên kết | ⚠ "thích được ghi nhận thành tích" | | ⚠ Mẹo phân biệt Z với Y | ⚠ Y nói nhân viên TỰ GIÁC; Z nói phải CHO HỌ THAM GIA vào quản lý — một cái nói về bản chất, một cái nói về cơ chế |

Từ khoá nhận diện:

"người lao động tham gia quản lý" → ⚠ Thuyết Z "nhân viên lười hay tự giác" → ⚠ Thuyết X và Y "phần thưởng và kỳ vọng" → ⚠ Vroom "yếu tố duy trì và tạo động lực" → ⚠ Herzberg

⚠ Thuyết Z trong dự án hiện đại Ứng dụng
⚠ Đội TỰ TỔ CHỨC của agile rất gần tinh thần Thuyết Z ⚠ liên hệ #26016 và #26030 lô 185
⚠ Ra quyết định đồng thuận ⚠ liên hệ #26010 lô 185 — bỏ phiếu và ra quyết định nhóm
⚠ Đội ổn định lâu dài thay vì lập rồi giải tán ⚠ liên hệ #26026 lô 185 — MVP không nhằm giải tán đội sớm
⚠ Điểm khác biệt ⚠ Thuyết Z nói về TỔ CHỨC và quan hệ lao động; agile nói về CÁCH LÀM VIỆC — nhưng chúng cùng một triết lý về con người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có được tham gia vào các quyết định ảnh hưởng tới họ không | | | Quyết định trong đội được ra bằng đồng thuận hay bằng mệnh lệnh | | | Người trong đội có gắn bó lâu dài không | ⚠ luân chuyển liên tục thì mọi lý thuyết về gắn kết đều vô nghĩa |

Và điểm chung của mọi thuyết trong bảng trên: không thuyết nào nói rằng cách tăng năng suất là giám sát chặt hơn. Đó cũng là điều đáng nhớ nhất khi đọc cả sáu.

Câu 312 Business Environment
Georgia is the scrum master for Project Olivecakes, which is about to finalize its last deliverable, a new employee social network. Georgia has confirmed all her stakeholders are happy and has worked with the human resources team to ensure the deliverables will be readily available to employees. What should Georgia do next?
  1. A Work with the human resources team to determine what cultural changes are needed.
  2. B Ensure all project documents are properly cataloged.
  3. C Work with the project team to finalize the last deliverables.
  4. D Do nothing. Her project is done.
Xem giải thích

Đáp án

A — LÀM VIỆC với bộ phận nhân sự để xác định những THAY ĐỔI VĂN HOÁ cần thiết.

Vì sao đúng

⚠ Vì sao bàn giao xong chưa phải là hết việc: | Lý do | Nội dung | |---|---| | ⚠ Sản phẩm là một MẠNG XÃ HỘI NỘI BỘ cho nhân viên | ⚠ giá trị chỉ xuất hiện khi người ta THẬT SỰ DÙNG | | ⚠ Bàn giao được cài đặt xong không có nghĩa là được chấp nhận | | | ⚠ Thay đổi hành vi đòi hỏi QUẢN TRỊ THAY ĐỔI TỔ CHỨC | | | ⚠ Georgia đã làm xong phần dễ: bên liên quan hài lòng, sản phẩm sẵn sàng | ⚠ phần khó là để nó được dùng thật | | ⚠ Điểm mấu chốt | ⚠ dự án tạo ra ĐẦU RA; lợi ích chỉ đến khi đầu ra được TIẾP NHẬN và dùng |

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

  • B (bảo đảm mọi tài liệu dự án được lưu trữ đúng cách) — ⚠ phương án gây nhiễu mạnh nhất vì lưu trữ đúng là hoạt động bắt buộc của giai đoạn đóng ⚠ (liên hệ #25927 lô 183): ⚠ nhưng đó là ⚠ việc hành chính, ⚠ trong khi ⚠ việc TẠO RA GIÁ TRỊ ở thời điểm này là bảo đảm sản phẩm được dùng; ⚠ câu hỏi hỏi việc TIẾP THEO có ý nghĩa nhất.

  • C (làm việc với đội để hoàn tất các bàn giao cuối) — ⚠ đề nói bàn giao ĐANG được hoàn tất ⚠ và mọi thứ đã sẵn sàng.

  • D (không làm gì, dự án đã xong) — ⚠ sai hoàn toàn; ⚠ còn cả giai đoạn đóng và việc hiện thực hoá lợi ích.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25927 ở lô 183 (hoạt động của giai đoạn đóng), câu #25999 ở lô 185 (chủ đề buổi họp kết thúc), câu #26006 (vì sao viết bài học), và câu #25896 ở lô 183 (chuyển giao tri thức khó hơn dự tính). ⚠ Nhóm kết thúc dự án — nhưng câu này nhìn từ góc HIỆN THỰC HOÁ LỢI ÍCH, một góc mới.

⚠ Chuỗi từ ĐẦU RA tới LỢI ÍCH: | Bậc | Nội dung | |---|---| | ⚠ ĐẦU RA (output) | ⚠ thứ dự án tạo ra — mạng xã hội nội bộ đã cài đặt xong | | ⚠ KẾT QUẢ (outcome) | ⚠ thay đổi xảy ra — nhân viên thật sự dùng để trao đổi | | ⚠ LỢI ÍCH (benefit) | ⚠ giá trị thu được — gắn kết tốt hơn, thông tin lan 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 rất 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:

"bàn giao xong, bên liên quan hài lòng" → ⚠ kiểm xem nó có được DÙNG không "lưu trữ tài liệu" → ⚠ việc hành chính bắt buộc, nhưng không tạo giá trị mới "dự án đã xong, không cần làm gì" → ⚠ luôn sai "sản phẩm đòi hỏi người ta ĐỔI CÁCH LÀM VIỆC" → ⚠ cần quản trị thay đổi tổ chức

⚠ Quản trị thay đổi tổ chức gồm gì Nội dung
⚠ Truyền thông về VÌ SAO có thay đổi này ⚠ không chỉ nói CÁI GÌ thay đổi
⚠ Đào tạo và hỗ trợ người dùng
⚠ Tìm và nuôi những người dùng TIÊN PHONG ⚠ họ lan toả hiệu quả hơn mọi email từ ban lãnh đạo
⚠ Xử lý sự KHÁNG CỰ ⚠ liên hệ #25890 lô 183 — quản lý phản đối
⚠ Đo mức độ SỬ DỤNG, không chỉ đo mức độ cài đặt
⚠ Vì sao nhân sự là đối tác đúng ⚠ đây là sản phẩm về CON NGƯỜI trong tổ chức — nhân sự nắm văn hoá và các kênh tiếp cận nhân viên
⚠ Georgia vẫn phải làm những việc đóng dự án Việc
⚠ Nghiệm thu chính thức
⚠ Lưu trữ tài liệu ⚠ phương án B — vẫn phải làm, chỉ không phải việc quan trọng nhất lúc này
⚠ Bài học kinh nghiệm ⚠ liên hệ #26006 lô 185
⚠ Chuyển giao cho bộ phận vận hành ⚠ ai duy trì mạng xã hội này sau khi đội giải tán?
⚠ Thứ tự ưu tiên ⚠ việc nào ẢNH HƯỞNG TỚI LỢI ÍCH thì 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 | |---|---| | Dự án gần nhất của bạn có ai đo mức độ SỬ DỤNG sau bàn giao không | | | Có kế hoạch quản trị thay đổi cho người dùng cuối không | | | Ai chịu trách nhiệm về lợi ích sau khi dự án đóng | ⚠ thường không ai — và đó là lý do lợi ích hay bốc hơi |

Và câu hỏi mà Georgia nên đặt ra ngay lúc này: sáu tháng nữa, nếu không ai đăng nhập vào mạng xã hội này, dự án có được coi là thành công không? Câu trả lời quyết định việc cô nên làm tiếp.

Câu 313 Process
Ray is planning for a major annual sporting event in the country. Although Ray has worked on similar events in the past, they have all been relatively minor in comparison. Ray has decided to reach out to other managers to learn about what worked for their events and what they could have done better. The managers provide Ray with a list of contacts and resources for this event and a general sequence of events, including an expected duration and cost estimation. What level of knowledge management best describes the scenario above?
  1. A Tacit
  2. B Project
  3. C Organization
  4. D Individual
Xem giải thích

Đáp án

C — MỨC TỔ CHỨC (organization).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Ray liên hệ với CÁC QUẢN LÝ KHÁC trong tổ chức | ⚠ khai thác tri thức nằm ngoài dự án của mình | | ⚠ Nhận được danh bạ liên hệ và nguồn lực | ⚠ tài sản của tổ chức | | ⚠ Nhận trình tự sự kiện, ước lượng thời lượng và chi phí | ⚠ dữ liệu lịch sử của tổ chức | | ⚠ Kiến thức này KHÔNG thuộc riêng dự án nào | ⚠ nó tồn tại xuyên suốt tổ chức | | ⚠ Kết luận | ⚠ đây là quản lý tri thức ở MỨC TỔ CHỨC — tài sản quy trình của tổ chức |

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

  • A (tri thức ẨN — tacit) — ⚠ phương án gây nhiễu mạnh nhất vì kinh nghiệm của các quản lý đúng là tri thức ẩn: ⚠ nhưng ⚠ ẩn/hiện là phân loại theo TÍNH CHẤT của tri thức, ⚠ không phải theo MỨC ĐỘ; ⚠ câu hỏi hỏi rõ ⚠ "mức độ (level) quản lý tri thức nào" ⚠ — mà mức độ thì có cá nhân, dự án, tổ chức.

  • B (mức dự án) — ⚠ tri thức trong phạm vi MỘT dự án; ⚠ Ray đang lấy từ NHIỀU dự án khác nhau.

  • D (mức cá nhân) — ⚠ tri thức của riêng một người; ⚠ Ray đang tổng hợp từ nhiều người.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26006 ở lô 185 (vì sao viết bài học kinh nghiệm — để giúp đội tương lai), câu #25896 ở lô 183 (chuyển giao tri thức khó hơn dự tính), câu #26011 ở lô 185 (xem kho tri thức của tổ chức), và câu #25944 ở lô 184 (dùng lại định nghĩa vai trò từ dự án tương tự). ⚠ Nhóm quản lý tri thức — và câu này là câu duy nhất hỏi về MỨC ĐỘ.

⚠ BA MỨC quản lý tri thức: | Mức | Nội dung | |---|---| | ⚠ CÁ NHÂN | ⚠ kinh nghiệm, kỹ năng, mạng quan hệ của một người | | ⚠ DỰ ÁN | ⚠ tài liệu, quyết định, bài học trong phạm vi một dự án | | ⚠ TỔ CHỨC | ⚠ tài sản quy trình, mẫu, dữ liệu lịch sử, kho bài học dùng chung — CÂU NÀY | | ⚠ Dòng chảy mong muốn | ⚠ cá nhân → dự án → tổ chức → trở lại các dự án sau | | ⚠ Chỗ đứt gãy phổ biến nhất | ⚠ từ DỰ ÁN lên TỔ CHỨC — bài học viết ra rồi nằm im, không ai đưa vào kho dùng chung |

⚠ Phân loại theo TÍNH CHẤT — chiều thứ hai, đừng nhầm với mức độ: | Loại | Nội dung | |---|---| | ⚠ TRI THỨC HIỆN (explicit) | ⚠ viết ra được: tài liệu, quy trình, số liệu, mẫu | | ⚠ TRI THỨC ẨN (tacit) | ⚠ khó viết ra: kinh nghiệm, trực giác, "biết ai hỏi việc gì" | | ⚠ Cách chuyển giao khác nhau | ⚠ tri thức HIỆN chuyển bằng TÀI LIỆU; tri thức ẨN chuyển bằng TRÒ CHUYỆN, kèm cặp, làm cùng | | ⚠ Ở tình huống này | ⚠ Ray thu được CẢ HAI: danh sách và ước lượng là tri thức hiện, còn "chỗ này chúng tôi đáng lẽ nên làm khác" là tri thức ẩn |

Từ khoá nhận diện:

"học từ các dự án khác trong tổ chức" → ⚠ mức TỔ CHỨC "tài liệu trong dự án này" → ⚠ mức DỰ ÁN "kinh nghiệm riêng của một người" → ⚠ mức CÁ NHÂN "ẩn / hiện" → ⚠ phân loại theo TÍNH CHẤT, không phải theo mức

⚠ Vì sao cách làm của Ray đáng học Lý do
⚠ Anh CHỦ ĐỘNG đi tìm, không đợi ai đưa ⚠ phần lớn tri thức tổ chức nằm im vì không ai đi hỏi
⚠ Hỏi cả cái LÀM ĐƯỢC lẫn cái ĐÁNG LẼ NÊN LÀM KHÁC ⚠ vế thứ hai giá trị hơn
⚠ Thu được cả tri thức ẩn qua trò chuyện trực tiếp ⚠ thứ không có trong tài liệu nào
⚠ Nhận diện đúng khoảng cách: sự kiện lần này LỚN HƠN nhiều ⚠ biết mình chưa biết gì
⚠ Việc nên làm tiếp ⚠ GHI LẠI những gì thu được để đưa vào kho tổ chức — nếu không, tri thức lại chỉ nằm trong đầu Ray

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết ai trong tổ chức đã làm việc tương tự chưa | | | Có kho tri thức dùng chung không, và lần cuối cập nhật là khi nào | | | Tri thức ẩn của người sắp nghỉ hưu có được chuyển giao không | ⚠ rủi ro lớn mà ít tổ chức xử lý |

Và điều Ray làm đúng nhất không nằm ở việc anh thu được gì: anh nhận ra rằng kinh nghiệm với sự kiện nhỏ không tự động dùng được cho sự kiện lớn, và đi tìm người đã làm quy mô đó.

Câu 314 People
In Hector’s team, even trivial decisions are debated, which wastes productivity. What could Hector do to help his team make collective decisions?
  1. A Fist-of-five voting
  2. B Bare fist fighting
  3. C Brainstorming
  4. D Planning poker
Xem giải thích

Đáp án

A — BỎ PHIẾU NẮM TAY NĂM NGÓN (fist-of-five voting).

Vì sao đúng

⚠ Cách bỏ phiếu nắm tay năm ngón hoạt động: | Số ngón | Ý nghĩa | |---|---| | ⚠ NẮM TAY (0 ngón) | ⚠ phản đối hoàn toàn, cần bàn tiếp | | ⚠ 1 ngón | ⚠ có lo ngại lớn | | ⚠ 2 ngón | ⚠ có vài băn khoăn, muốn bàn thêm | | ⚠ 3 ngón | ⚠ ổn, tôi theo | | ⚠ 4 ngón | ⚠ đồng ý, tốt | | ⚠ 5 ngón | ⚠ rất ủng hộ, sẵn sàng dẫn dắt | | ⚠ Quy tắc thường dùng | ⚠ từ 3 ngón trở lên là THÔNG QUA; dưới 3 thì người đó nói lý do | | ⚠ Vì sao giải quyết vấn đề của Hector | ⚠ cho biết NGAY mức đồng thuận của cả nhóm trong vài giây, thay vì tranh luận vòng vo |

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

  • D (planning poker) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là kỹ thuật đồng thuận có dùng "giơ tay": ⚠ nhưng planning poker dùng để ⚠ ƯỚC LƯỢNG KÍCH CỠ công việc, ⚠ không dùng để ra quyết định; ⚠ dùng nhầm cho quyết định vụn vặt thì còn tốn thời gian hơn.

  • C (động não — brainstorming) — ⚠ để SINH RA ý tưởng, ⚠ không phải để CHỌN; ⚠ dùng ở đây sẽ làm cuộc bàn dài thêm.

  • B (đấu tay không) — ⚠ phương án đùa, ⚠ hiển nhiên sai.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26010 ở lô 185 (bỏ phiếu im lặng để giảm tranh cãi), câu #26002 (xếp hạng tuyệt đối), và câu #25992 (xung đột xây dựng). ⚠ Ba câu tạo bộ công cụ ra quyết định nhóm khá đầy đủ — và câu này bổ sung công cụ nhanh nhất cho quyết định NHỎ.

⚠ Chọn công cụ theo LOẠI quyết định: | Loại quyết định | Công cụ phù hợp | |---|---| | ⚠ Nhỏ, cần quyết nhanh | ⚠ nắm tay năm ngón — CÂU NÀY | | ⚠ Xếp ưu tiên nhiều hạng mục | ⚠ xếp hạng tuyệt đối, cho điểm 100, MoSCoW — liên hệ #26002 | | ⚠ Nhóm hay tranh cãi, có người áp đảo | ⚠ bỏ phiếu im lặng — liên hệ #26010 | | ⚠ Ước lượng kích cỡ công việc | ⚠ planning poker | | ⚠ Cần sinh nhiều phương án | ⚠ động não | | ⚠ Quyết định phức tạp nhiều tiêu chí | ⚠ phân tích đa tiêu chí, cây quyết định — liên hệ #26013 lô 185 | | ⚠ Sai lầm của đội Hector | ⚠ dùng cùng một mức thảo luận cho mọi quyết định, bất kể lớn nhỏ |

Từ khoá nhận diện:

"quyết định vụn vặt bị bàn quá lâu" → ⚠ nắm tay năm ngón "ước lượng kích cỡ công việc" → ⚠ planning poker "sinh ý tưởng" → ⚠ động não "có người áp đảo cuộc bàn" → ⚠ bỏ phiếu im lặng

⚠ Vì sao nắm tay năm ngón hiệu quả Lý do
⚠ CỰC NHANH — vài giây là biết cả nhóm nghĩ gì
⚠ Cho thấy MỨC ĐỘ đồng thuận, không chỉ có/không ⚠ khác hẳn bỏ phiếu nhị phân
⚠ Ai chưa thoải mái vẫn có tiếng nói ⚠ giơ 1–2 ngón là được mời giải thích
⚠ Mọi người giơ CÙNG LÚC ⚠ tránh ảnh hưởng lẫn nhau — cùng nguyên lý với bỏ phiếu im lặng
⚠ Điểm quan trọng ⚠ nó tìm SỰ ĐỒNG THUẬN ĐỦ ĐỂ ĐI TIẾP, không tìm sự nhất trí tuyệt đối
⚠ Vấn đề gốc của đội Hector Vấn đề
⚠ Không phân biệt quyết định LỚN và NHỎ
⚠ Có thể do không rõ AI ĐƯỢC QUYẾT việc gì ⚠ thiếu ranh giới thẩm quyền — liên hệ #25958 lô 184
⚠ Hoặc do sợ sai nên ai cũng muốn cả nhóm cùng chịu
⚠ Hoặc do đội mới, chưa có lòng tin
⚠ Giải pháp gốc ⚠ thống nhất trong quy tắc chung: loại quyết định nào cần cả nhóm, loại nào một người quyết là đủ — liên hệ #25970 lô 184

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn mất bao lâu cho một quyết định nhỏ | | | Có thoả thuận nào về việc ai quyết được gì không | | | Sau khi quyết, có ai còn quay lại bàn lại không | ⚠ dấu hiệu đồng thuận chưa thật — liên hệ #25926 lô 183, bất đồng và cam kết |

Và giá trị lớn nhất của một công cụ đơn giản như nắm tay năm ngón: nó biến câu hỏi mơ hồ "mọi người thấy sao?" thành một con số mà ai cũng nhìn thấy cùng lúc — và phần lớn các cuộc tranh luận vụn vặt kết thúc ngay tại đó.

Câu 315 Process
You and the project sponsor are working together to create a project scope statement. The project sponsor has concerns about the demand for safety for the electrical requirements for the project work. The safety concerns should be documented as which one of the following choices?
  1. A Product requirement
  2. B Assumption
  3. C Pure risk
  4. D Cost of quality
Xem giải thích

Đáp án

C — RỦI RO THUẦN (pure risk).

Vì sao đúng

⚠ Vì sao lo ngại an toàn là rủi ro thuần: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro thuần chỉ có KẾT CỤC XẤU hoặc KHÔNG có gì | ⚠ không có mặt tích cực nào | | ⚠ Sự cố điện: có thể gây thương vong, hoả hoạn, kiện tụng | | | ⚠ Không xảy ra thì cũng KHÔNG mang lại lợi ích gì | ⚠ đó là điểm phân biệt cốt lõi | | ⚠ Còn gọi là RỦI RO CÓ THỂ BẢO HIỂM | ⚠ vì chỉ có mặt tổn thất, bảo hiểm định giá được | | ⚠ Đối lập | ⚠ RỦI RO ĐẦU CƠ có cả mặt được và mất — như đầu tư công nghệ mới |

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

  • B (giả định) — ⚠ phương án gây nhiễu mạnh nhất vì cả hai đều được ghi trong tuyên bố phạm vi: ⚠ nhưng ⚠ giả định là điều ta COI NHƯ ĐÚNG mà chưa chứng minh ⚠ ("giả định nhà thầu điện có chứng chỉ hành nghề"); ⚠ ở đây nhà tài trợ đang nêu một ⚠ MỐI LO về điều có thể xảy ra ⚠ — đó là rủi ro.

  • A (yêu cầu sản phẩm) — ⚠ "hệ thống điện phải đạt tiêu chuẩn X" thì mới là yêu cầu; ⚠ còn "tôi lo về an toàn điện" là mối lo, ⚠ cần được ghi vào sổ rủi ro trước, rồi mới sinh ra yêu cầu.

  • D (chi phí chất lượng) — ⚠ các khoản chi để đạt hoặc do không đạt chất lượng ⚠ (liên hệ #25924 lô 183); ⚠ không phải bản thân mối lo.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26003 ở lô 185 (tác động cao nhưng điểm rủi ro thấp vì xác suất thấp), câu #25983 (ngưỡng), câu #25923 ở lô 183 (kỹ thuật nhận diện rủi ro), và câu #25962 ở lô 184 (rủi ro tuân thủ). ⚠ Nhóm rủi ro — và câu này bổ sung phân loại THUẦN/ĐẦU CƠ, chưa từng xuất hiện.

⚠ Hai cách phân loại rủi ro cần phân biệt: | Cách phân loại | Các loại | |---|---| | ⚠ Theo CHIỀU tác động | ⚠ rủi ro TIÊU CỰC (threat) và rủi ro TÍCH CỰC (opportunity) | | ⚠ Theo BẢN CHẤT | ⚠ rủi ro THUẦN (chỉ mất) và rủi ro ĐẦU CƠ (có được có mất) — CÂU NÀY | | ⚠ Quan hệ | ⚠ rủi ro thuần luôn là tiêu cực; rủi ro đầu cơ có cả hai chiều | | ⚠ Ví dụ rủi ro THUẦN | ⚠ tai nạn lao động, hoả hoạn, thiên tai, trộm cắp | | ⚠ Ví dụ rủi ro ĐẦU CƠ | ⚠ dùng công nghệ mới: có thể nhanh hơn nhiều, cũng có thể thất bại hoàn toàn |

Từ khoá nhận diện:

"an toàn, tai nạn, hoả hoạn, thiên tai" → ⚠ rủi ro thuần "công nghệ mới, phương án táo bạo" → ⚠ rủi ro đầu cơ "coi như đúng mà chưa chứng minh" → ⚠ giả định "phải đạt tiêu chuẩn X" → ⚠ yêu cầu

⚠ Ứng phó với rủi ro thuần thế nào Chiến lược
⚠ NÉ TRÁNH — loại bỏ hoàn toàn nguồn rủi ro ⚠ đổi thiết kế để không cần công đoạn nguy hiểm
⚠ GIẢM NHẸ — giảm xác suất hoặc tác động ⚠ đào tạo an toàn, thiết bị bảo hộ — liên hệ #25924 lô 183
⚠ CHUYỂN GIAO — bảo hiểm, thuê ngoài ⚠ rủi ro thuần là loại DỄ BẢO HIỂM NHẤT
⚠ CHẤP NHẬN — có kế hoạch dự phòng
⚠ Với rủi ro AN TOÀN ⚠ chấp nhận thụ động gần như không bao giờ là lựa chọn hợp pháp hay hợp đạo đức
⚠ Nhà tài trợ nêu mối lo — bước tiếp theo là gì Bước
⚠ 1. Ghi vào SỔ ĐĂNG KÝ RỦI RO ⚠ mọi mối lo được nêu đều phải được ghi nhận
⚠ 2. Đánh giá xác suất và tác động
⚠ 3. Xác định chiến lược ứng phó và người chịu trách nhiệm
⚠ 4. Chuyển thành YÊU CẦU cụ thể nếu cần ⚠ "hệ thống điện phải đạt tiêu chuẩn quốc gia và có kiểm định độc lập"
⚠ 5. Đưa vào tuyên bố phạm vi và tiêu chí chấp nhận ⚠ liên hệ #25977 lô 184
⚠ Điểm hay ⚠ một mối lo được xử lý đúng sẽ biến thành một yêu cầu kiểm chứng được — đó là cách rủi ro trở nên vô hại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn có phân biệt rủi ro thuần và đầu cơ không | ⚠ hai loại cần chiến lược khác nhau | | Rủi ro an toàn có được bảo hiểm hoặc chuyển giao không | | | Mối lo của nhà tài trợ có được ghi lại không | ⚠ nếu chỉ nghe rồi quên thì nó sẽ quay lại vào lúc tệ nhất |

Và điều hay bị bỏ qua khi phân loại: rủi ro thuần không bao giờ mang lại lợi ích, nên tiền bỏ ra để phòng nó luôn trông như chi phí thừa — cho tới ngày nó không còn thừa nữa.

Câu 316 Process
You are the project manager of a large construction project. You and your project team are planning a method to control changes during the construction project, and all of you realize that changes often happen in the field—changes that may differ from what the blueprints in the office reflect. The goal of your planning activity is to track actual changes in the field and reflect those changes in the blueprints in the office. You want consistency between what is being constructed and what the blueprints reflect. What is this process called? (Choose the best answer.)
  1. A Project management planning
  2. B Configuration management
  3. C Change assessment
  4. D Scope validation
Xem giải thích

Đáp án

B — QUẢN LÝ CẤU HÌNH (configuration management).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Thay đổi xảy ra TẠI CÔNG TRƯỜNG, khác bản vẽ ở văn phòng | ⚠ lệch giữa thực tế và hồ sơ | | ⚠ Mục tiêu: theo dõi thay đổi thực tế và PHẢN ÁNH vào bản vẽ | ⚠ đồng bộ hồ sơ với thực tế | | ⚠ Muốn NHẤT QUÁN giữa cái đang xây và cái bản vẽ thể hiện | ⚠ đúng định nghĩa quản lý cấu hình | | ⚠ Định nghĩa | ⚠ quản lý cấu hình kiểm soát ĐẶC TÍNH KỸ THUẬT của sản phẩm và các tài liệu mô tả chúng |

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

  • C (đánh giá thay đổi — change assessment) — ⚠ phương án gây nhiễu mạnh nhất vì cũng có chữ "thay đổi": ⚠ nhưng đánh giá thay đổi là bước ⚠ XÉT xem CÓ NÊN duyệt thay đổi hay không; ⚠ ở đây thay đổi ĐÃ XẢY RA rồi, ⚠ vấn đề là làm sao hồ sơ phản ánh đúng thực tế.

  • D (xác nhận phạm vi) — ⚠ khách hàng NGHIỆM THU bàn giao; ⚠ diễn ra ở cuối, không liên quan tới đồng bộ bản vẽ.

  • A (lập kế hoạch quản lý dự án) — ⚠ quá chung chung; ⚠ câu hỏi hỏi tên một QUY TRÌNH cụ thể.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG: ⚠ câu #25966 ở lô 184 ⚠ (bản vẽ tại công trường của kiến trúc sư phải khớp bản vẽ văn phòng sẽ đi vào kho lưu trữ → KẾ HOẠCH QUẢN LÝ CẤU HÌNH). ⚠ Hai câu gần như CÙNG MỘT TÌNH HUỐNG, khoá NHẤT QUÁN. ⚠ Khác biệt duy nhất: #25966 hỏi "KẾ HOẠCH quản lý dự án nào" nên đáp án là "kế hoạch quản lý cấu hình"; câu này hỏi "QUY TRÌNH này gọi là gì" nên đáp án là "quản lý cấu hình". ⚠ Đọc kỹ đề hỏi KẾ HOẠCH hay QUY TRÌNH.

⚠ Bộ câu về quản lý cấu hình đã lên NĂM câu: | Câu | Góc nhìn | |---|---| | ⚠ #25886 (lô 183) | ⚠ HỆ THỐNG quản lý cấu hình — công cụ, sản phẩm | | ⚠ #25894 (lô 183) | ⚠ KIỂM SOÁT PHIÊN BẢN — tài liệu | | ⚠ #25897 (lô 183) | ⚠ khái niệm — đặc tính kỹ thuật | | ⚠ #25966 (lô 184) | ⚠ KẾ HOẠCH quản lý cấu hình | | ⚠ #26038 (lô này) | ⚠ QUY TRÌNH quản lý cấu hình | | ⚠ Năm khoá | ⚠ hoàn toàn nhất quán — bộ đề đang kiểm tra cùng một chủ đề từ năm góc khác nhau | | ⚠ Xem thêm | ⚠ #25840 lô 182 — mức quản lý cấu hình phải PHÙ HỢP, không phải TỐI ĐA |

⚠ Quản lý cấu hình và Kiểm soát thay đổi — bảng phân biệt: | Quản lý CẤU HÌNH | Kiểm soát THAY ĐỔI | |---|---| | ⚠ Nhắm vào ĐẶC TÍNH KỸ THUẬT của sản phẩm | ⚠ Nhắm vào ĐƯỜNG CƠ SỞ của dự án | | ⚠ "Bản nào là bản đúng?" | ⚠ "Có duyệt thay đổi này không?" | | ⚠ Kiểm soát PHIÊN BẢN và TRUY XUẤT | ⚠ Kiểm soát PHẠM VI, LỊCH, CHI PHÍ | | ⚠ Bổ sung nhau | ⚠ duyệt thay đổi xong thì quản lý cấu hình bảo đảm MỌI BẢN SAO đều được cập nhật |

Từ khoá nhận diện:

"bản vẽ, phiên bản, nhất quán giữa thực tế và hồ sơ" → ⚠ quản lý cấu hình "duyệt hay từ chối thay đổi" → ⚠ kiểm soát thay đổi "khách hàng nghiệm thu" → ⚠ xác nhận phạm vi ⚠ Đề hỏi "KẾ HOẠCH nào" → ⚠ kế hoạch quản lý cấu hình; hỏi "QUY TRÌNH này gọi là gì" → quản lý cấu hình

⚠ Bốn hoạt động của quản lý cấu hình Hoạt động
⚠ NHẬN DIỆN cấu hình ⚠ xác định cái gì được kiểm soát: bản vẽ, thông số, tài liệu
⚠ GHI NHẬN TRẠNG THÁI ⚠ phiên bản nào đang có hiệu lực, ai đang dùng bản nào
⚠ KIỂM SOÁT THAY ĐỔI cấu hình ⚠ ai được sửa, ai duyệt
⚠ KIỂM TOÁN cấu hình ⚠ đối chiếu thực tế với hồ sơ — chính là điều đội đang muốn làm
⚠ Trong xây dựng ⚠ kết quả cuối là HỒ SƠ HOÀN CÔNG — bản vẽ phản ánh công trình như nó thật sự được xây
⚠ Vì sao thay đổi tại công trường luôn xảy ra Lý do
⚠ Điều kiện thực địa khác thiết kế ⚠ địa chất, kết cấu cũ, vướng hạ tầng ngầm
⚠ Vật tư theo thiết kế không có sẵn
⚠ Thợ tìm ra cách làm tốt hơn
⚠ Sai sót trong bản vẽ gốc
⚠ Vấn đề KHÔNG phải là thay đổi ⚠ mà là thay đổi KHÔNG ĐƯỢC GHI LẠI — năm năm sau không ai biết công trình thật sự được xây thế nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai đối chiếu thực tế với hồ sơ trước khi lưu trữ không | ⚠ đó chính là kiểm toán cấu hình | | Thay đổi tại hiện trường có kênh nào để báo về không | ⚠ nếu quá phiền thì không ai báo | | Có bao nhiêu bản sao của cùng một tài liệu đang lưu hành | |

Và điều đội của bạn đang phòng ngừa bằng quy trình này: cái giá không phải trả trong lúc thi công, mà trả nhiều năm sau — khi có người mở hồ sơ ra để sửa chữa và phát hiện bản vẽ không khớp với thứ đang đứng trước mặt họ.

Câu 317 Process
You are the project manager for the creation of a new warehouse in Knoxville, Tennessee. You and the project team are creating the scope statement and are evaluating the function, purpose, and activities that will take place within the warehouse to help the project customer gather all of the requirements for the scope. This process is an example of which one of the following?
  1. A Scope change control
  2. B Product analysis
  3. C Expert judgment
  4. D Work breakdown structure creation
Xem giải thích

Đáp án

B — PHÂN TÍCH SẢN PHẨM (product analysis).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Đội phân tích CHỨC NĂNG, MỤC ĐÍCH và HOẠT ĐỘNG diễn ra trong nhà kho | ⚠ đi từ mô tả sản phẩm ra yêu cầu cụ thể | | ⚠ Mục đích: giúp khách hàng thu thập đầy đủ yêu cầu cho phạm vi | | | ⚠ Đang trong quá trình lập TUYÊN BỐ PHẠM VI | ⚠ đúng chỗ phân tích sản phẩm được dùng | | ⚠ Định nghĩa | ⚠ phân tích sản phẩm là kỹ thuật chuyển MÔ TẢ CẤP CAO của sản phẩm thành các BÀN GIAO và YÊU CẦU hữu hình | | ⚠ Các kỹ thuật thuộc nhóm này | ⚠ phân rã sản phẩm, phân tích hệ thống, phân tích yêu cầu, kỹ thuật hệ thống, PHÂN TÍCH GIÁ TRỊ, phân tích chức năng |

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

  • D (lập WBS) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là phân rã: ⚠ nhưng WBS phân rã ⚠ CÔNG VIỆC PHẢI LÀM, ⚠ còn phân tích sản phẩm phân rã ⚠ CHÍNH SẢN PHẨM; ⚠ và WBS diễn ra ⚠ SAU KHI ⚠ tuyên bố phạm vi đã xong (liên hệ #26017 lô 185).

  • C (phán đoán chuyên gia) — ⚠ một kỹ thuật CHUNG dùng ở mọi quy trình; ⚠ quá rộng, không mô tả đúng hoạt động cụ thể ở đây.

  • A (kiểm soát thay đổi phạm vi) — ⚠ diễn ra SAU khi có đường cơ sở; ⚠ ở đây đường cơ sở còn chưa hình thành.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25997 và #26007 ở lô 185 (mô tả phạm vi sản phẩm), câu #26017 (vì sao cần WBS), và câu #26023 (sửa phạm vi khi khách tăng diện tích). ⚠ Nhóm phạm vi — và câu này lấp mảnh còn thiếu: KỸ THUẬT để đi từ mô tả sản phẩm sang yêu cầu.

⚠ Chuỗi từ Ý TƯỞNG tới ĐƯỜNG CƠ SỞ PHẠM VI: | Bước | Nội dung | |---|---| | ⚠ ĐIỀU LỆ DỰ ÁN | ⚠ mô tả sản phẩm ở mức rất cao | | ⚠ THU THẬP YÊU CẦU | ⚠ phỏng vấn, hội thảo, khảo sát, nguyên mẫu | | ⚠ PHÂN TÍCH SẢN PHẨM | ⚠ biến mô tả cấp cao thành yêu cầu và bàn giao cụ thể — CÂU NÀY | | ⚠ TUYÊN BỐ PHẠM VI | ⚠ bốn mục: mô tả sản phẩm, bàn giao, tiêu chí chấp nhận, loại trừ | | ⚠ WBS + TỪ ĐIỂN WBS | ⚠ phân rã CÔNG VIỆC | | ⚠ Kết quả | ⚠ ĐƯỜNG CƠ SỞ PHẠM VI = tuyên bố phạm vi + WBS + từ điển WBS |

⚠ Phân biệt hai kiểu phân rã: | Phân rã SẢN PHẨM | Phân rã CÔNG VIỆC (WBS) | |---|---| | ⚠ "Nhà kho gồm khu nhận hàng, khu lưu trữ, khu xuất hàng" | ⚠ "Thiết kế, xin phép, san nền, đổ móng, dựng khung" | | ⚠ Trả lời: sản phẩm CÓ GÌ | ⚠ Trả lời: phải LÀM GÌ | | ⚠ Thuộc quy trình Xác định phạm vi | ⚠ thuộc quy trình Tạo WBS | | ⚠ Thứ tự | ⚠ phân tích sản phẩm TRƯỚC, WBS SAU |

Từ khoá nhận diện:

"phân tích chức năng, mục đích, hoạt động của sản phẩm" → ⚠ phân tích sản phẩm "phân rã công việc phải làm" → ⚠ WBS "ý kiến người có kinh nghiệm" → ⚠ phán đoán chuyên gia "xét yêu cầu thay đổi phạm vi" → ⚠ kiểm soát thay đổi phạm vi

⚠ Vì sao phân tích chức năng lại giúp thu thập yêu cầu Lý do
⚠ Khách hàng thường mô tả GIẢI PHÁP, không mô tả NHU CẦU ⚠ "tôi cần một nhà kho 5.000 mét vuông"
⚠ Hỏi về HOẠT ĐỘNG sẽ diễn ra sẽ lộ ra yêu cầu thật ⚠ "mỗi ngày bao nhiêu xe tải ra vào?" → yêu cầu về số bến đỗ
⚠ Phát hiện yêu cầu khách hàng chưa nghĩ tới ⚠ thoát hiểm, thông gió, tải trọng sàn
⚠ Tránh bỏ sót dẫn tới thay đổi tốn kém về sau ⚠ liên hệ #26023 lô 185
⚠ Câu hỏi mấu chốt ⚠ "người ta sẽ LÀM GÌ trong toà nhà này?" — trả lời được thì hầu hết yêu cầu tự lộ ra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có hiểu sản phẩm sẽ được DÙNG thế nào không | ⚠ hay chỉ biết nó trông ra sao | | Yêu cầu của bạn đến từ nhu cầu hay từ giải pháp khách hàng tự nghĩ ra | | | Có ai hỏi về các hoạt động vận hành hằng ngày chưa | |

Và giá trị thật của phân tích sản phẩm: nó buộc cả hai bên trả lời câu hỏi "để làm gì" trước khi thống nhất "xây cái gì" — và phần lớn thay đổi phạm vi tốn kém đều bắt nguồn từ việc bỏ qua bước đó.

Câu 318 Process
Francie is the project manager for a water sanitation project, the Trickling Project. She has concluded that there is too much risk in handling certain chemicals, so she is allowing someone else to complete this portion of the project. Francie will outsource the handling of chemicals and installation of filter equipment to a contractor with experience. This is an example of which of the following choices?
  1. A Acceptance
  2. B Mitigation
  3. C Transference
  4. D Avoidance
Xem giải thích

Đáp án

C — CHUYỂN GIAO (transference).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Francie thấy việc xử lý hoá chất quá rủi ro | ⚠ rủi ro đã được nhận diện và đánh giá | | ⚠ Cô để NGƯỜI KHÁC làm phần đó | ⚠ chuyển trách nhiệm sang bên thứ ba | | ⚠ Thuê nhà thầu CÓ KINH NGHIỆM | ⚠ bên tiếp nhận có năng lực xử lý tốt hơn | | ⚠ Rủi ro VẪN CÒN TỒN TẠI | ⚠ điểm phân biệt cốt lõi — chỉ đổi người chịu | | ⚠ Định nghĩa | ⚠ chuyển giao là dời TÁC ĐỘNG và TRÁCH NHIỆM ứng phó sang bên thứ ba |

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

  • D (né tránh) — ⚠ phương án gây nhiễu mạnh nhất vì Francie đúng là "không tự làm việc nguy hiểm": ⚠ nhưng ⚠ né tránh là LOẠI BỎ HOÀN TOÀN rủi ro ⚠ — đổi thiết kế để không cần dùng hoá chất đó nữa; ⚠ ở đây ⚠ công việc VẪN ĐƯỢC LÀM, rủi ro VẪN TỒN TẠI, ⚠ chỉ do người khác gánh.

  • B (giảm nhẹ) — ⚠ giảm XÁC SUẤT hoặc TÁC ĐỘNG ⚠ mà vẫn tự làm: ⚠ mua thiết bị bảo hộ tốt hơn, đào tạo an toàn (liên hệ #25924 lô 183).

  • A (chấp nhận) — ⚠ không hành động gì đặc biệt, ⚠ chỉ chuẩn bị dự phòng.

Ghi nhớ

⚠ Đối chiếu — bộ CHIẾN LƯỢC ỨNG PHÓ RỦI RO đã đủ và nay LẶP LẠI: ⚠ #25792 lô 181 (chấp nhận), ⚠ #25807 lô 181 (chuyển giao), ⚠ #25808 lô 181 (giảm nhẹ), ⚠ #25846 lô 182 (né tránh), ⚠ #25892 lô 183 (leo thang), ⚠ và câu này (chuyển giao — lần thứ HAI). ⚠ Hai câu về chuyển giao có khoá NHẤT QUÁN. ⚠ Câu hỏi phân biệt vẫn là: SAU KHI hành động, rủi ro CÒN CÓ THỂ XẢY RA không?

⚠ BẢNG PHÂN BIỆT năm chiến lược cho rủi ro TIÊU CỰC: | Chiến lược | Rủi ro còn tồn tại? | Ai chịu? | Ví dụ | |---|---|---|---| | ⚠ NÉ TRÁNH | ⚠ KHÔNG — đã loại bỏ | ⚠ không ai | ⚠ đổi thiết kế để không dùng hoá chất | | ⚠ CHUYỂN GIAO | ⚠ CÒN | ⚠ BÊN THỨ BA — CÂU NÀY | ⚠ thuê nhà thầu, mua bảo hiểm | | ⚠ GIẢM NHẸ | ⚠ CÒN, nhưng nhỏ hơn | ⚠ mình | ⚠ đào tạo, thiết bị bảo hộ | | ⚠ CHẤP NHẬN | ⚠ CÒN NGUYÊN | ⚠ mình | ⚠ để dự phòng ngân sách | | ⚠ LEO THANG | ⚠ CÒN | ⚠ cấp cao hơn trong tổ chức | ⚠ vượt thẩm quyền dự án | | ⚠ Câu hỏi phân biệt số một | ⚠ rủi ro còn có thể xảy ra không, và AI sẽ chịu hậu quả |

Từ khoá nhận diện:

"thuê ngoài, mua bảo hiểm, bảo lãnh, bảo hành" → ⚠ chuyển giao "loại bỏ hẳn công việc rủi ro" → ⚠ né tránh "đào tạo, thêm biện pháp phòng ngừa" → ⚠ giảm nhẹ "để dự phòng, không làm gì thêm" → ⚠ chấp nhận "vượt thẩm quyền, báo lên trên" → ⚠ leo thang

⚠ Chuyển giao KHÔNG có nghĩa là hết trách nhiệm Lưu ý
⚠ Rủi ro VỀ AN TOÀN vẫn thuộc trách nhiệm pháp lý của chủ dự án ⚠ ở nhiều nước, không thuê ngoài được nghĩa vụ an toàn lao động
⚠ Vẫn phải GIÁM SÁT nhà thầu ⚠ liên hệ #25887 lô 183 — rà soát hợp đồng nhà cung cấp
⚠ Chuyển giao thường TỐN PHÍ ⚠ nhà thầu tính thêm phần rủi ro vào giá
⚠ Phát sinh RỦI RO MỚI: phụ thuộc nhà thầu
⚠ Nguyên tắc ⚠ chuyển giao dời TÁC ĐỘNG TÀI CHÍNH và VIỆC THỰC HIỆN, không dời được TRÁCH NHIỆM CUỐI CÙNG
⚠ Vì sao chuyển giao là lựa chọn hợp lý ở đây Lý do
⚠ Nhà thầu CÓ KINH NGHIỆM — xác suất sự cố thấp hơn ⚠ vừa chuyển giao vừa giảm nhẹ
⚠ Họ có thiết bị, chứng chỉ, và bảo hiểm chuyên ngành
⚠ Đội của Francie không có năng lực đó ⚠ tự làm sẽ là quyết định tệ nhất
⚠ Việc Francie phải làm thêm ⚠ kiểm chứng chỉ hành nghề, bảo hiểm của nhà thầu, và ghi rõ trách nhiệm trong hợp đồng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro bạn "chuyển giao" có thật sự sang bên kia không | ⚠ kiểm điều khoản hợp đồng, đừng giả định | | Nhà thầu có đủ năng lực và bảo hiểm không | | | Bạn còn giữ trách nhiệm pháp lý nào không | ⚠ với an toàn lao động, câu trả lời gần như luôn là CÓ |

Và điều dễ hiểu sai nhất về chuyển giao rủi ro: bạn mua được sự yên tâm về mặt tài chính, nhưng nếu có tai nạn xảy ra trên công trường của bạn, không hợp đồng nào xoá được cái tên của bạn khỏi bản tin.

Câu 319 Process
You are part of the development team on a project in the second week of a three-week Sprint. The VP of the organization stops by and asks you to include an important, valuable feature he would like to see delivered in the current iteration. What is the best action to take?
  1. A Inform the scrum master, drop a feature of equal size from the sprint backlog, and add the new feature.
  2. B Reject the request. The sprint backlog must remain unchanged during the sprint.
  3. C Inform the product owner to work with the VP to discuss the new feature’s value and priorities.
  4. D Since it is coming from senior management, accept the request and add it to the sprint backlog.
Xem giải thích

Đáp án

C — BÁO PRODUCT OWNER để làm việc với phó tổng về GIÁ TRỊ và ƯU TIÊN của tính năng mới.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ PRODUCT OWNER là NGƯỜI DUY NHẤT quyết nội dung backlog | ⚠ kể cả khi yêu cầu đến từ lãnh đạo cấp cao | | ⚠ Thành viên đội KHÔNG có thẩm quyền nhận thêm việc | ⚠ và cũng không có vị thế để từ chối phó tổng | | ⚠ Không phải từ chối, cũng không phải nhận ngay | ⚠ hướng yêu cầu vào ĐÚNG KÊNH | | ⚠ Sprint backlog thuộc về ĐỘI, chỉ đổi khi đội và PO thoả thuận | | | ⚠ Bảo vệ ai | ⚠ bảo vệ CẢ thành viên (khỏi phải nói không với sếp) LẪN cam kết sprint |

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

  • A (báo Scrum Master, bỏ một hạng mục cùng kích cỡ khỏi sprint backlog rồi thêm tính năng mới) — ⚠ phương án gây nhiễu mạnh nhất vì việc đánh đổi cùng kích cỡ nghe rất hợp lý và đúng nguyên tắc: ⚠ nhưng ⚠ nó BỎ QUA product owner ⚠ — người duy nhất được quyết đánh đổi giá trị; ⚠ và Scrum Master cũng không có thẩm quyền đó; ⚠ cơ chế đánh đổi này ĐÚNG, nhưng phải do PO quyết.

  • D (vì đến từ lãnh đạo cấp cao nên chấp nhận và thêm vào sprint backlog) — ⚠ quyết theo QUYỀN LỰC, không theo giá trị; ⚠ phá vỡ cam kết sprint.

  • B (từ chối, sprint backlog không được đổi trong sprint) — ⚠ quá cứng nhắc: ⚠ sprint backlog CÓ THỂ đổi nếu đội và PO thoả thuận, ⚠ miễn là không phá vỡ MỤC TIÊU SPRINT.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25987 ở lô 185 (bên liên quan xin thêm tính năng cuối dự án → đưa vào backlog vì thay đổi luôn được chào đón), câu #25905 ở lô 183 (hướng phản hồi vào backlog), câu #26012 ở lô 185 (việc ngoài phạm vi có giá trị → dừng và nộp yêu cầu thay đổi), và câu #26015 (đội khác xin mượn người → thương lượng). ⚠ Cả nhóm cùng một nguyên tắc: KHÔNG từ chối, KHÔNG nhận bừa, mà HƯỚNG VÀO ĐÚNG KÊNH.

⚠ Sprint backlog có được đổi giữa sprint không: | Trường hợp | Trả lời | |---|---| | ⚠ Đội phát hiện cần thêm việc kỹ thuật để đạt mục tiêu | ⚠ ĐƯỢC — đội tự điều chỉnh | | ⚠ PO và đội thoả thuận đổi hạng mục, MỤC TIÊU SPRINT KHÔNG ĐỔI | ⚠ ĐƯỢC | | ⚠ Người ngoài đẩy việc vào | ⚠ KHÔNG — phải qua PO | | ⚠ Thay đổi làm hỏng mục tiêu sprint | ⚠ KHÔNG — nếu mục tiêu không còn giá trị thì PO có quyền HUỶ sprint | | ⚠ Nguyên tắc bất biến | ⚠ MỤC TIÊU SPRINT là thứ được bảo vệ, không phải danh sách hạng mục |

Từ khoá nhận diện:

"lãnh đạo cấp cao xin thêm việc giữa sprint" → ⚠ hướng sang product owner "vì sếp yêu cầu nên nhận" → ⚠ quyết theo quyền lực, luôn sai "từ chối, không được đổi gì cả" → ⚠ quá cứng nhắc "tự đánh đổi hạng mục" → ⚠ đúng cơ chế, sai người quyết

⚠ Vì sao KHÔNG để thành viên tự xử Lý do
⚠ Nói "không" với phó tổng là việc rất khó về mặt cá nhân
⚠ Họ không nắm toàn cảnh backlog và giá trị các hạng mục
⚠ Họ không có thẩm quyền đánh đổi phạm vi
⚠ Vai trò bảo vệ ⚠ PO và Scrum Master tồn tại một phần chính là để đội không phải đứng ở vị trí này
⚠ Product owner nên nói gì với phó tổng Cách
⚠ GHI NHẬN giá trị của đề xuất
⚠ Đưa vào backlog và cùng xếp ưu tiên ⚠ liên hệ #25987 lô 185
⚠ Nếu thật sự gấp: nêu rõ ĐÁNH ĐỔI ⚠ "làm cái này thì hạng mục X sang sprint sau — anh chọn cái nào?"
⚠ Không hứa suông là "cố gắng làm cả hai" ⚠ sức chứa là hữu hạn
⚠ Kết quả tốt nhất ⚠ phó tổng tự chọn đánh đổi — khi đó quyết định là của ông ấy, và cam kết cũng vậy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lãnh đạo trong tổ chức bạn có biết đưa yêu cầu qua đâu không | | | Đội có bị người ngoài đẩy việc trực tiếp không | ⚠ dấu hiệu vai trò PO chưa được tôn trọng | | Sprint gần nhất có bị chen việc không | |

Và câu trả lời hay nhất mà thành viên đội có thể nói với phó tổng: "nghe rất hữu ích ạ — để em nối anh với product owner, anh ấy sẽ cùng anh xem nó nên nằm ở đâu." Lịch sự, đúng quy trình, và không ai phải nói "không".

Câu 320 Process
Samantha’s agile development team has just moved to Test-Driven Development. They are focusing on two new areas in their development model. They are most likely
  1. A Development and production smoke tests.
  2. B Writing of automated test scripts for the future release of code and paired programming.
  3. C Creation of unit tests prior to code being written and refactoring code once it is written.
  4. D Manual peer testing and writing of automated test scripts.
Xem giải thích

Đáp án

C — TẠO KIỂM THỬ ĐƠN VỊ TRƯỚC KHI viết mã, và TÁI CẤU TRÚC mã sau khi đã viết xong.

Vì sao đúng

⚠ Chu trình TDD — Đỏ, Xanh, Tái cấu trúc: | Bước | Nội dung | |---|---| | ⚠ ĐỎ — viết một kiểm thử đơn vị TRƯỚC, nó THẤT BẠI | ⚠ vì mã chưa tồn tại | | ⚠ XANH — viết mã TỐI THIỂU để kiểm thử đó qua | ⚠ không viết thừa | | ⚠ TÁI CẤU TRÚC — dọn dẹp mã mà vẫn giữ kiểm thử xanh | | | ⚠ Lặp lại | | | ⚠ Hai điểm mới với đội Samantha | ⚠ viết kiểm thử TRƯỚC (đảo ngược thói quen) và TÁI CẤU TRÚC có kỷ luật | | ⚠ Vì sao tái cấu trúc an toàn | ⚠ bộ kiểm thử là lưới an toàn — sửa mà hỏng thì biết ngay |

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

  • B (viết kịch bản kiểm thử tự động cho bản phát hành sau, và lập trình cặp) — ⚠ phương án gây nhiễu mạnh nhất vì cả hai đều là thực hành XP thật: ⚠ nhưng ⚠ lập trình cặp là thực hành RIÊNG, không thuộc TDD, ⚠ và ⚠ "kiểm thử cho bản phát hành TƯƠNG LAI" đi ngược tinh thần TDD ⚠ — TDD viết kiểm thử cho mã ĐANG viết, ngay bây giờ.

  • A (kiểm thử khói ở môi trường phát triển và sản xuất) — ⚠ kiểm thử khói là kiểm nhanh xem hệ thống có chạy được không; ⚠ không phải TDD.

  • D (kiểm thử chéo thủ công và viết kịch bản tự động) — ⚠ kiểm thử THỦ CÔNG đi ngược hoàn toàn TDD, ⚠ vốn dựa trên kiểm thử tự động.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25986 ở lô 185 (tích hợp liên tục cần đầu tư kiểm thử tự động), câu #26000 (kiểm thử thăm dò bổ sung cho kiểm thử theo kịch bản), câu #25953 ở lô 184 (kiểm thử nằm trong Định nghĩa Hoàn thành), và câu #25967 (phân tích xu hướng lỗi). ⚠ Nhóm thực hành kỹ thuật và chất lượng đã lên năm câu.

⚠ Các thực hành kỹ thuật của XP — đừng gộp làm một: | Thực hành | Nội dung | |---|---| | ⚠ TDD | ⚠ viết kiểm thử trước, mã sau, rồi tái cấu trúc — CÂU NÀY | | ⚠ LẬP TRÌNH CẶP | ⚠ hai người một máy — liên hệ #26019 lô 185 | | ⚠ TÍCH HỢP LIÊN TỤC | ⚠ hợp nhất mã thường xuyên, build và kiểm thử tự động | | ⚠ TÁI CẤU TRÚC | ⚠ cải thiện cấu trúc mã mà không đổi hành vi — là MỘT BƯỚC của TDD | | ⚠ SỞ HỮU MÃ TẬP THỂ | ⚠ ai cũng được sửa mọi phần mã | | ⚠ THIẾT KẾ ĐƠN GIẢN | ⚠ làm đủ cho hôm nay, không thiết kế cho tương lai giả định | | ⚠ Quan hệ | ⚠ chúng HỖ TRỢ nhau nhưng là các thực hành ĐỘC LẬP — TDD dùng được mà không cần lập trình cặp |

Từ khoá nhận diện:

"viết kiểm thử trước khi viết mã" → ⚠ TDD "hai người một máy" → ⚠ lập trình cặp "kiểm nhanh xem hệ thống có chạy không" → ⚠ kiểm thử khói "kiểm thử thủ công" → ⚠ đi ngược TDD

⚠ Lợi ích của TDD Lợi ích
⚠ Buộc phải nghĩ về YÊU CẦU trước khi viết mã ⚠ lợi ích lớn nhất, và ít người nhận ra nhất
⚠ Mọi dòng mã đều có kiểm thử phủ
⚠ Tái cấu trúc AN TOÀN nhờ lưới kiểm thử
⚠ Thiết kế tự nhiên trở nên dễ kiểm thử hơn ⚠ thường cũng là thiết kế tốt hơn
⚠ Kiểm thử trở thành TÀI LIỆU sống về hành vi mong đợi
⚠ Chi phí ⚠ chậm hơn lúc đầu, và đòi hỏi kỷ luật cao — nhiều đội bỏ cuộc ở tuần thứ ba
⚠ TDD hay thất bại vì sao Nguyên nhân
⚠ Viết kiểm thử SAU rồi gọi là TDD ⚠ mất hoàn toàn lợi ích lớn nhất
⚠ Bỏ bước TÁI CẤU TRÚC ⚠ mã ngày càng rối dù kiểm thử vẫn xanh
⚠ Kiểm thử quá gắn với chi tiết cài đặt ⚠ sửa gì cũng hỏng kiểm thử, đội sẽ ghét nó
⚠ Áp lực tiến độ khiến bỏ dần
⚠ Điều kiện thành công ⚠ cần thời gian học và sự kiên nhẫn của cả tổ chức trong vài tháng đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn viết kiểm thử trước hay sau | | | Bước tái cấu trúc có thật sự được làm không | ⚠ hay chỉ dừng ở chỗ kiểm thử xanh | | Mất bao lâu để chạy hết bộ kiểm thử đơn vị | ⚠ quá lâu thì đội sẽ ngừng chạy |

Và điều làm nên sức mạnh thật của TDD, thứ không nằm ở chữ "test" trong tên gọi: viết kiểm thử trước buộc bạn phải trả lời câu hỏi "thế nào là đúng?" trước khi viết một dòng mã nào — và rất nhiều lỗi phần mềm sinh ra chỉ vì không ai đặt câu hỏi đó.