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

Tìm thấy 720 câu.

Câu 21 People
Sarah is hosting her first meeting with new stakeholders. While her core team engages in a lively debate about a particular strategy's merits and comfortably critiques the project's deliverables, the new stakeholders seem interested but hesitant to join in. After the meeting, Sarah approaches the stakeholders to ask if they feel included. They admit that they are not sure how to best contribute to the team and do not want to come off as authoritarian. This is an opportunity to provide mentoring by
  1. A Encouraging collaborative problem-solving
  2. B Using open and effective communication
  3. C Creating team-building opportunities
  4. D Managing conflicts in a constructive manner
Xem giải thích

Đáp án

C — Tạo cơ hội XÂY DỰNG ĐỘI (creating team-building opportunities).

Vì sao đúng

⚠ Vấn đề thật sự là gì: | Chi tiết trong đề | Suy ra | |---|---| | ⚠ Đội nòng cốt tranh luận sôi nổi, thoải mái phê bình | ⚠ họ đã ở giai đoạn Norming hoặc Performing | | ⚠ Bên liên quan MỚI quan tâm nhưng NGẦN NGẠI tham gia | ⚠ họ vẫn ở giai đoạn Forming | | ⚠ Họ KHÔNG BIẾT cách đóng góp cho phù hợp | ⚠ thiếu hiểu biết về vai trò của mình trong nhóm | | ⚠ Sợ bị coi là ÁP ĐẶT | ⚠ chưa xây được quan hệ nên chưa biết ranh giới | | ⚠ Kết luận | ⚠ đây là vấn đề HOÀ NHẬP NHÓM — cần xây dựng đội, không phải sửa cách giao tiếp hay xử lý xung đột |

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

  • B (dùng giao tiếp cởi mở và hiệu quả) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ giao tiếp trong buổi họp ⚠ đã cởi mở rồi — đội nòng cốt tranh luận rất thoải mái; ⚠ vấn đề không nằm ở chất lượng giao tiếp mà ở ⚠ mức độ hoà nhập của người mới.

  • A (khuyến khích giải quyết vấn đề hợp tác) — ⚠ là kết QUẢ mong muốn, ⚠ nhưng người mới chưa đủ thoải mái để tham gia; ⚠ phải xây quan hệ trước.

  • D (quản lý xung đột một cách xây dựng) — ⚠ KHÔNG có xung đột nào ở đây; ⚠ chỉ có sự dè dặt.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25700 ở lô 179 về giai đoạn Storming và câu #25631 ở lô 177 về năm giai đoạn Tuckman. ⚠ Câu này minh hoạ một tình huống thực tế thường gặp: khi có người MỚI gia nhập, đội quay lại giai đoạn FORMING đối với họ, dù phần còn lại đã ở Performing.

⚠ Vì sao người mới bị "kẹt" ở Forming: | Lý do | Nội dung | |---|---| | ⚠ Chưa biết CHUẨN MỰC không thành văn của nhóm | ⚠ phê bình tới mức nào là chấp nhận được? | | ⚠ Chưa biết VAI TRÒ của mình trong các cuộc thảo luận | | | ⚠ Chưa xây được quan hệ tin cậy với ai | | | ⚠ Sợ tạo ấn tượng xấu ngay lần đầu | ⚠ "không muốn bị coi là áp đặt" | | ⚠ Đội cũ | ⚠ thường không nhận ra vì với họ mọi thứ đã tự nhiên |

⚠ Các hoạt động xây dựng đội phù hợp: | Hoạt động | Nội dung | |---|---| | ⚠ Giới thiệu vai trò và chuyên môn của từng người | | | ⚠ Xây dựng hoặc rà soát HIẾN CHƯƠNG ĐỘI cùng nhau | ⚠ làm rõ chuẩn mực thành văn | | ⚠ Hoạt động phá băng ở đầu buổi họp | | | ⚠ Ghép cặp người mới với thành viên nòng cốt | ⚠ buddy system | | ⚠ Mời phát biểu trực tiếp trong họp | ⚠ "anh/chị nghĩ sao về điểm này?" | | ⚠ Sarah đã làm đúng bước đầu | ⚠ HỎI THẲNG xem họ có thấy được tham gia không |

Từ khoá nhận diện:

"người mới ngần ngại tham gia" → ⚠ team building "đội cãi nhau về vai trò" → ⚠ Storming, cần coaching "hai bên có quan điểm đối lập" → ⚠ quản lý xung đột "thông tin không tới đúng người" → ⚠ giao tiếp

⚠ Develop Team — quy trình liên quan Nội dung
⚠ Thuộc nhóm THỰC HIỆN
⚠ Mục tiêu: nâng năng lực, sự tương tác và môi trường làm việc chung
⚠ Công cụ: đồng địa điểm, giao tiếp ảo, XÂY DỰNG ĐỘI, ghi nhận và khen thưởng, đào tạo
⚠ Đầu ra: đánh giá hiệu suất đội
⚠ Lưu ý ⚠ xây dựng đội là hoạt động LIÊN TỤC, không chỉ làm một lần lúc khởi động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới có biết vai trò của mình trong đội không | | | Chuẩn mực của đội có được viết ra không | ⚠ chuẩn mực ngầm là rào cản lớn nhất với người mới | | Bạn có chủ động mời họ phát biểu không | |

Và điều Sarah làm đúng nhất: hỏi thẳng thay vì phỏng đoán. Rất nhiều quản lý dự án nhìn thấy sự im lặng rồi tự kết luận là "họ không quan tâm" — trong khi sự thật thường ngược lại.

Câu 22 Process
Carlton has been promoted from project manager to director. He is now directly responsible for a team of project managers and indirectly responsible for their direct reports. To ensure that all his employees can work to their full capacity, Carlton schedules weekly check-ins with his project managers and checks that they have the necessary resources, including funding, employees, and technology, to work efficiently and continuously. Which quality management practice does this entail?
  1. A Customer satisfaction
  2. B Continual improvement
  3. C Management responsibility
  4. D Mutually beneficial partnerships
Xem giải thích

Đáp án

C — Management responsibility (trách nhiệm của quản lý).

Vì sao đúng

⚠ Những gì Carlton làm: | Hành động | Ý nghĩa | |---|---| | ⚠ Họp kiểm tra HÀNG TUẦN với các quản lý dự án | ⚠ theo dõi và hỗ trợ đều đặn | | ⚠ Kiểm tra họ có đủ KINH PHÍ không | | | ⚠ Kiểm tra họ có đủ NHÂN SỰ không | | | ⚠ Kiểm tra họ có đủ CÔNG NGHỆ không | | | ⚠ Mục tiêu: mọi người làm việc HẾT CÔNG SUẤT | | | ⚠ Kết luận | ⚠ đây chính là nguyên tắc "trách nhiệm của quản lý" trong quản lý chất lượng: LÃNH ĐẠO phải cung cấp đủ nguồn lực để đạt chất lượng |

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

  • B (Continual improvement — cải tiến liên tục) — ⚠ là chu trình rà soát và nâng cao quy trình (⚠ PDCA); ⚠ Carlton đang cung cấp nguồn lực, không đang cải tiến quy trình.

  • A (Customer satisfaction — sự hài lòng của khách hàng) — ⚠ hướng ra BÊN NGOÀI; ⚠ Carlton đang làm việc với nội bộ.

  • D (Mutually beneficial partnerships — quan hệ đối tác đôi bên cùng có lợi) — ⚠ nói về quan hệ với NHÀ CUNG CẤP và đối tác, ⚠ không phải quan hệ với nhân viên.

Ghi nhớ

⚠ Năm nguyên tắc quản lý chất lượng hiện đại: | Nguyên tắc | Nội dung | |---|---| | ⚠ Customer satisfaction | ⚠ hiểu, đánh giá, định nghĩa và quản lý kỳ vọng khách hàng | | ⚠ Prevention over inspection | ⚠ phòng ngừa hơn kiểm tra — chất lượng được LẬP KẾ HOẠCH mà có | | ⚠ Continual improvement | ⚠ PDCA, Six Sigma, TQM — cải tiến không ngừng | | ⚠ MANAGEMENT RESPONSIBILITY | ⚠ lãnh đạo phải cung cấp ĐỦ NGUỒN LỰC — CÂU NÀY | | ⚠ Mutually beneficial partnerships with suppliers | ⚠ quan hệ lâu dài với nhà cung cấp, đôi bên cùng lợi |

Từ khoá nhận diện:

"cung cấp đủ nguồn lực cho nhân viên" → ⚠ management responsibility "phòng ngừa hơn kiểm tra" → ⚠ prevention over inspection "PDCA, cải tiến quy trình" → ⚠ continual improvement "quan hệ với nhà cung cấp" → ⚠ mutually beneficial partnerships "hiểu và quản lý kỳ vọng khách hàng" → ⚠ customer satisfaction

⚠ Vì sao "trách nhiệm quản lý" lại thuộc QUẢN LÝ CHẤT LƯỢNG Lý do
⚠ Deming: 85% vấn đề chất lượng do HỆ THỐNG, không do người làm
⚠ Hệ thống là thứ QUẢN LÝ tạo ra và kiểm soát
⚠ Thiếu nguồn lực → người ta buộc phải làm tắt → chất lượng giảm
⚠ Không thể đòi chất lượng cao mà không cấp đủ phương tiện
⚠ Kết luận ⚠ chất lượng bắt đầu từ cấp quản lý, không phải từ người thợ
⚠ Carlton làm đúng ở những điểm nào Điểm
⚠ Kiểm tra ĐỀU ĐẶN, không đợi có sự cố mới hỏi
⚠ Hỏi về NGUỒN LỰC chứ không chỉ hỏi tiến độ
⚠ Bao quát cả ba loại: tiền, người, công nghệ
⚠ Quan tâm tới cả cấp báo cáo gián tiếp
⚠ Có thể bổ sung ⚠ hỏi thêm về TRỞ NGẠI cần gỡ — đó là tinh thần lãnh đạo phục vụ

⚠ Đối chiếu: ⚠ câu #25732 ở lô 179 về lãnh đạo phục vụ và câu #25729 về kéo cả đội vào giải quyết vấn đề. ⚠ Hành vi của Carlton rất gần với lãnh đạo phục vụ — gỡ trở ngại và bảo đảm điều kiện làm việc.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có đủ nguồn lực để làm đúng ngay lần đầu không | | | Bạn hỏi họ về tiến độ hay về trở ngại | ⚠ hai câu hỏi cho hai loại câu trả lời rất khác nhau | | Có yêu cầu chất lượng nào không kèm nguồn lực tương ứng không | |

Và câu của Deming đáng nhớ nhất cho tình huống này: đừng đòi công nhân làm tốt hơn khi hệ thống không cho phép họ làm tốt hơn. Cung cấp phương tiện là trách nhiệm của quản lý, không phải ân huệ.

Câu 23 People
A Project Management Skills Gap Assessment (PM SGA) was recently conducted on an application development start-up business that wants to provide an innovative service for its clients. However, the employees are unsure about presenting the executive team's ideas to their customers, leading to a loss of profit margins from poor customer service. Which of the following type of organization best describes the organization shown above?
  1. A Seat of the pants project management
  2. B Management by memo organization
  3. C Working towards best in class
  4. D The blind leading the blind
Xem giải thích

Đáp án

D — The blind leading the blind (mù dắt mù).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Công ty khởi nghiệp muốn cung cấp dịch vụ ĐỔI MỚI | ⚠ tham vọng cao | | ⚠ Nhân viên KHÔNG CHẮC cách trình bày ý tưởng của ban lãnh đạo cho khách | ⚠ → họ không hiểu rõ chính sản phẩm mình bán | | ⚠ Dịch vụ khách hàng kém khiến MẤT biên lợi nhuận | ⚠ → hậu quả kinh doanh thật | | ⚠ Ban lãnh đạo có ý tưởng nhưng không truyền đạt được xuống dưới | | | ⚠ Kết luận | ⚠ cả người dẫn lẫn người thực hiện đều không rõ đường — đúng nghĩa "mù dắt mù" |

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

  • A (Seat of the pants project management — quản lý theo cảm tính) — ⚠ chỉ tổ chức làm việc KHÔNG CÓ quy trình, ứng biến từng lúc; ⚠ vấn đề ở đây sâu hơn: ⚠ không ai hiểu rõ chính mục tiêu của mình.

  • B (Management by memo organization — quản lý bằng công văn) — ⚠ là tổ chức lãnh đạo chỉ giao tiếp qua văn bản một chiều; ⚠ đề không nói tới cách giao tiếp bằng công văn.

  • C (Working towards best in class — hướng tới nhóm dẫn đầu) — ⚠ là mức TRƯỞNG THÀNH CAO, ⚠ ngược hẳn tình huống.

Ghi nhớ

⚠ Các mức trưởng thành quản lý dự án theo mô hình đánh giá khoảng trống kỹ năng: | Mức | Đặc điểm | |---|---| | ⚠ The blind leading the blind | ⚠ THẤP NHẤT: cả lãnh đạo lẫn nhân viên đều không nắm được phương pháp và mục tiêu | | ⚠ Seat of the pants | ⚠ làm theo cảm tính, không quy trình, phụ thuộc cá nhân giỏi | | ⚠ Management by memo | ⚠ có chỉ đạo nhưng chỉ một chiều bằng văn bản, thiếu tương tác | | ⚠ Working towards best in class | ⚠ CAO NHẤT: có quy trình, đo lường và cải tiến liên tục |

Từ khoá nhận diện:

"không ai biết phải làm gì, kể cả người dẫn" → ⚠ blind leading the blind "làm được nhưng không có quy trình" → ⚠ seat of the pants "chỉ đạo bằng văn bản một chiều" → ⚠ management by memo "có quy trình, đo lường, cải tiến" → ⚠ best in class

⚠ Vì sao khởi nghiệp hay rơi vào mức này Lý do
⚠ Tập trung vào SẢN PHẨM, xem nhẹ quy trình
⚠ Lãnh đạo giỏi chuyên môn nhưng chưa quen truyền đạt
⚠ Tăng trưởng nhanh hơn tốc độ xây dựng năng lực
⚠ Không có ai đảm nhiệm vai trò đào tạo nội bộ
⚠ Liên hệ ⚠ xem câu #25611 ở lô 177 về cơ cấu ORGANIC — khởi nghiệp thường ở cơ cấu này, quyền của PM rất thấp và quy trình rất mỏng
⚠ Cách thoát khỏi mức này Bước
⚠ 1. Làm rõ TẦM NHÌN và giá trị sản phẩm bằng văn bản ⚠ để ai cũng nói được cùng một câu chuyện
⚠ 2. Đào tạo nhân viên về chính sản phẩm họ bán
⚠ 3. Xây quy trình tối thiểu: bán hàng, hỗ trợ, phản hồi ⚠ đừng áp quy trình nặng nề cho tổ chức nhỏ
⚠ 4. Tạo kênh phản hồi hai chiều giữa lãnh đạo và nhân viên
⚠ 5. Đo lường: tỷ lệ giữ khách, biên lợi nhuận, phản hồi khách hàng
⚠ Ưu tiên cao nhất ⚠ truyền đạt cho được ý tưởng từ ban lãnh đạo xuống người tiếp xúc khách hàng
⚠ Vì sao vấn đề này biểu hiện ở BIÊN LỢI NHUẬN Cơ chế
⚠ Nhân viên không giải thích được giá trị sản phẩm
⚠ Khách hàng không thấy được lý do trả giá cao
⚠ Phải giảm giá để bán được
⚠ Biên lợi nhuận giảm
⚠ Kết luận ⚠ khoảng trống kỹ năng nội bộ hiện ra thành con số tài chính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhân viên tuyến đầu có nói được giá trị sản phẩm không | ⚠ thử hỏi ngẫu nhiên vài người | | Ý tưởng của lãnh đạo có tới được người thực hiện không | | | Có kênh phản hồi ngược lên không | |

Và điều đáng nói nhất: khoảng trống kỹ năng luôn hiện ra ở nơi tiếp xúc khách hàng trước tiên. Biên lợi nhuận giảm chỉ là triệu chứng — nguyên nhân nằm ở việc không ai truyền đạt được ý tưởng.

Câu 24 Process
Jerome is the project manager of the Pier Construction Project for Lakeside Builders. This project will require strict change control because of government regulations, project deliverable costs, and the approved scope. In regard to project changes, what is provided in the project plan?
  1. A Based on the CCB, a fluid document that is updated as needed
  2. B A method to approve or decline CCB changes
  3. C A guide to all future project decisions
  4. D A project deliverables vision
Xem giải thích

Đáp án

C — Là KIM CHỈ NAM cho mọi quyết định của dự án về sau (a guide to all future project decisions).

Vì sao đúng

⚠ Vai trò của kế hoạch quản lý dự án: | Vai trò | Nội dung | |---|---| | ⚠ Định nghĩa dự án được THỰC HIỆN, GIÁM SÁT và KẾT THÚC thế nào | | | ⚠ Chứa mọi ĐƯỜNG CƠ SỞ | ⚠ phạm vi, lịch, chi phí | | ⚠ Chứa mọi KẾ HOẠCH CON | ⚠ bao gồm change management plan | | ⚠ Là chuẩn để ĐO hiệu suất | | | ⚠ Là căn cứ để quyết định mọi việc về sau | ⚠ kể cả duyệt hay từ chối thay đổi | | ⚠ Với dự án của Jerome | ⚠ có quy định chính phủ và phạm vi đã duyệt, nên kế hoạch càng phải là chuẩn mực không thể tuỳ tiện |

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

  • A (một tài liệu LINH ĐỘNG, cập nhật khi cần theo CCB) — ⚠ SAI về bản chất: ⚠ kế hoạch dự án ⚠ KHÔNG phải tài liệu tuỳ tiện sửa; ⚠ nó chỉ đổi qua kiểm soát thay đổi CHÍNH THỨC, ⚠ và đề nhấn mạnh dự án này cần kiểm soát thay đổi NGHIÊM NGẶT.

  • B (một phương pháp để duyệt hoặc từ chối thay đổi của CCB) — ⚠ đảo ngược quan hệ: ⚠ CCB là bên phê duyệt, ⚠ kế hoạch là căn cứ họ dùng — không phải công cụ để duyệt chính CCB.

  • D (tầm nhìn về các bàn giao của dự án) — ⚠ quá hẹp: ⚠ đó gần với phạm vi sản phẩm, ⚠ không bao quát vai trò của cả kế hoạch.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25695 ở lô 179 về mục đích của điều lệ dự án. ⚠ Hai câu là cặp phân biệt kinh điển: điều lệ CHO PHÉP dự án tồn tại, kế hoạch HƯỚNG DẪN cách thực hiện nó.

⚠ Ba tài liệu nền tảng — phân biệt: | Tài liệu | Trả lời | Ai sở hữu | |---|---|---| | ⚠ Business case | ⚠ VÌ SAO đáng làm | ⚠ nhà tài trợ | | ⚠ Project charter | ⚠ CHO PHÉP làm, ai phụ trách | ⚠ nhà tài trợ ban hành | | ⚠ Project management plan | ⚠ LÀM THẾ NÀO — kim chỉ nam | ⚠ quản lý dự án |

⚠ Kế hoạch quản lý dự án gồm những gì: | Nhóm | Thành phần | |---|---| | ⚠ Các kế hoạch con | ⚠ phạm vi, yêu cầu, lịch, chi phí, chất lượng, nguồn lực, giao tiếp, rủi ro, mua sắm, bên liên quan | | ⚠ Các đường cơ sở | ⚠ phạm vi, lịch trình, chi phí | | ⚠ Các thành phần bổ sung | ⚠ change management plan, configuration management plan, performance measurement baseline, project life cycle, development approach |

Từ khoá nhận diện:

"kim chỉ nam cho mọi quyết định" → ⚠ project management plan "cho phép dự án tồn tại" → ⚠ project charter "chỉ đổi qua kiểm soát thay đổi chính thức" → ⚠ đường cơ sở trong kế hoạch "tài liệu sửa tuỳ ý" → ⚠ SAI với kế hoạch quản lý dự án

⚠ Vì sao dự án của Jerome cần kiểm soát chặt Lý do
⚠ Có QUY ĐỊNH CHÍNH PHỦ ⚠ thay đổi tuỳ tiện có thể vi phạm pháp luật
⚠ Chi phí bàn giao lớn ⚠ công trình cầu cảng
⚠ Phạm vi ĐÃ ĐƯỢC PHÊ DUYỆT ⚠ có đường cơ sở thì có kiểm soát thay đổi
⚠ Hệ quả ⚠ kế hoạch dự án ở đây gần như là văn bản pháp lý nội bộ
⚠ Phân biệt "sửa kế hoạch" và "cập nhật tài liệu" Phân biệt
⚠ ĐƯỜNG CƠ SỞ ⚠ chỉ đổi qua kiểm soát thay đổi CHÍNH THỨC
⚠ Tài liệu dự án (issue log, risk register, assumption log) ⚠ cập nhật LIÊN TỤC, không cần CCB
⚠ Nhầm lẫn hay gặp ⚠ tưởng mọi thứ trong kế hoạch đều sửa tự do — chỉ tài liệu dự án mới vậy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch của bạn có đủ các kế hoạch con không | | | Đường cơ sở có được bảo vệ khỏi sửa tuỳ tiện không | | | Khi có quyết định khó, bạn có mở kế hoạch ra tra không | ⚠ nếu không thì nó chỉ là tài liệu để nộp |

Và cách kiểm tra một kế hoạch dự án có thực sự hữu ích: khi gặp tình huống khó, có ai mở nó ra tra không. Kế hoạch viết xong rồi cất tủ thì không phải kim chỉ nam của bất cứ điều gì.

Câu 25 People
Doris is a new scrum master at a major healthcare facility in Florida. She receives an assignment to a scrum team that has been newly formed to develop a software solution that will support the hospital's work. The project team is not familiar with the Scrum methodology. They are resentful because they feel the hospital is forcing them to follow an agile methodology, which they have not had the training to perform. As the new scrum master, what do you do to bring your team together?
  1. A Determine if management will allow for added resources with a scrum skill set to the project team.
  2. B Ask to be reassigned to a project team with resources and skillsets needed to perform the project's work.
  3. C Discuss the issue with the team and ask them what steps they can take to resolve the issue.
  4. D Ask your manager if she can arrange to give the project team scrum training to improve their skill set.
Xem giải thích

Đáp án

C — Bàn bạc vấn đề VỚI ĐỘI và hỏi họ có thể làm những bước gì để giải quyết.

Vì sao đúng

⚠ Vì sao đây là hành động đúng đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Scrum Master là LÃNH ĐẠO PHỤC VỤ, không phải người ra lệnh | | | ⚠ Đội TỰ TỔ CHỨC — họ tham gia vào giải pháp | | | ⚠ Bất mãn được nói ra thì mới xử lý được | ⚠ để im thì nó âm ỉ | | ⚠ Hỏi đội thể hiện SỰ TÔN TRỌNG | ⚠ đối lập với cảm giác "bị ép" mà họ đang có | | ⚠ Nghịch lý cần thấy | ⚠ giải quyết cảm giác bị áp đặt bằng cách ÁP ĐẶT thêm một giải pháp là làm vấn đề tệ hơn |

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

  • D (xin quản lý tổ chức đào tạo Scrum cho đội) — ⚠ phương án gây nhiễu MẠNH NHẤT vì nghe rất hợp lý: ⚠ đội đúng là ⚠ thiếu đào tạo; ⚠ nhưng ⚠ đây lại là một giải pháp ÁP TỪ TRÊN XUỐNG nữa — ⚠ đúng thứ đang khiến họ bất mãn; ⚠ đào tạo rất có thể là kết quả của cuộc trò chuyện ở phương án C, nhưng phải để đội tự nêu ra.

  • A (xin thêm người có kỹ năng Scrum vào đội) — ⚠ không giải quyết gốc; ⚠ đội hiện tại vẫn bất mãn, ⚠ và thêm người lạ có thể làm họ càng thấy bị coi thường.

  • B (xin chuyển sang đội khác) — ⚠ bỏ cuộc; ⚠ đây là đúng loại vấn đề mà Scrum Master sinh ra để xử lý.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25678 ở lô 178 (đội tự thực thi hiến chương đội), câu #25721 ở lô 179 (đội kiểm soát việc lập kế hoạch chi tiết) và câu #25732 (lãnh đạo phục vụ với đội lâu năm). ⚠ Bốn câu cùng một nguyên tắc: trong môi trường thích ứng, giải pháp đến TỪ đội chứ không đến CHO đội.

⚠ Vai trò của Scrum Master: | Việc | Nội dung | |---|---| | ⚠ GỠ TRỞ NGẠI cho đội | ⚠ impediment removal | | ⚠ HUẤN LUYỆN đội về Scrum | ⚠ thay vì chỉ đi xin đào tạo bên ngoài | | ⚠ Bảo vệ đội khỏi can thiệp | | | ⚠ Tạo điều kiện cho các sự kiện Scrum | | | ⚠ Giúp tổ chức hiểu và áp dụng Scrum | | | ⚠ KHÔNG làm | ⚠ giao việc, ra lệnh, quyết thay đội |

Từ khoá nhận diện:

"đội bất mãn, cảm thấy bị ép" → ⚠ nói chuyện với đội TRƯỚC "thiếu kỹ năng" → ⚠ đào tạo là giải pháp, nhưng phải để đội tham gia quyết định "xin chuyển đội khác" → ⚠ hầu như luôn là đáp án SAI "thêm người mới vào" → ⚠ thường không giải quyết vấn đề văn hoá

⚠ Cuộc trò chuyện với đội nên diễn ra thế nào Cách
⚠ Thừa nhận cảm giác của họ là CHÍNH ĐÁNG ⚠ "tôi hiểu là các bạn bị đưa vào việc này mà chưa được chuẩn bị"
⚠ Hỏi cụ thể: điều gì đang khó nhất?
⚠ Hỏi: các bạn nghĩ chúng ta nên làm gì? ⚠ đúng phương án C
⚠ Ghi lại và CAM KẾT hành động cụ thể
⚠ Thực hiện đúng cam kết ⚠ có thể chính là xin đào tạo — nhưng lúc này là do đội đề xuất
⚠ Công cụ phù hợp ⚠ retrospective, hoặc buổi xây dựng hiến chương đội
⚠ Vì sao ép agile lên đội chưa sẵn sàng thường thất bại Lý do
⚠ Agile dựa trên TỰ NGUYỆN và tự tổ chức ⚠ ép buộc mâu thuẫn với chính nguyên tắc của nó
⚠ Không có kỹ năng thì nghi thức trở thành hình thức ⚠ họp đứng mà không ai biết vì sao phải họp
⚠ Bất mãn làm giảm chất lượng phản hồi ⚠ retrospective trở nên vô nghĩa
⚠ Cách chuyển đổi đúng ⚠ giải thích LÝ DO, đào tạo, cho thời gian, và cho đội tham gia thiết kế cách làm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có hiểu VÌ SAO tổ chức chọn agile không | ⚠ thiếu vế này là gốc của bất mãn | | Bạn đang mang giải pháp tới hay đang hỏi đội | | | Cam kết đưa ra có được thực hiện không | ⚠ hứa mà không làm là mất niềm tin vĩnh viễn |

Và nghịch lý cần nhớ trong dạng câu này: không thể chữa cảm giác bị áp đặt bằng một giải pháp áp đặt khác. Ngay cả một giải pháp tốt như đào tạo cũng phải đi qua cuộc trò chuyện với đội trước.

Câu 26 Process
Isaac is the scrum master for the Zoo Project, eight iterations into deployment, and $5,000 over a $123,000 budget. Recently Isaac was approached by a team member who asked why there was a task in the backlog to examine project risk. What is Isaac's most likely response?
  1. A Risks should be constantly evaluated during a project's life.
  2. B Risk should not be a task but a process.
  3. C A scrum master must represent their work in the project.
  4. D The product owner requested it.
Xem giải thích

Đáp án

A — Rủi ro cần được ĐÁNH GIÁ LIÊN TỤC trong suốt vòng đời dự án.

Vì sao đúng

⚠ Quản lý rủi ro trong agile: | Điều | Nội dung | |---|---| | ⚠ Rủi ro KHÔNG chỉ đánh giá một lần ở đầu dự án | | | ⚠ Mỗi vòng lặp mang lại THÔNG TIN MỚI | ⚠ rủi ro cũ mất đi, rủi ro mới xuất hiện | | ⚠ Đưa việc rà soát rủi ro vào BACKLOG là cách làm cho nó HIỆN RA | ⚠ việc không nằm trong backlog thì không ai làm | | ⚠ Đội đang ở vòng lặp thứ 8 và vượt chi 5.000/123.000 | ⚠ khoảng 4% — đủ để cần theo dõi rủi ro chi phí | | ⚠ Kết luận | ⚠ có mục rà soát rủi ro trong backlog là hoàn toàn hợp lý |

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

  • B (rủi ro không nên là một việc mà là một quy trình) — ⚠ nghe hàn lâm nhưng SAI trong thực hành agile: ⚠ trong agile, ⚠ việc gì cần làm thì phải hiện ra trong backlog và được ước lượng; ⚠ gọi nó là "quy trình" rồi không đưa vào backlog là cách chắc chắn nhất để nó không bao giờ được làm.

  • D (product owner yêu cầu như vậy) — ⚠ né tránh câu hỏi: ⚠ đây là câu trả lời "vì sếp bảo thế", ⚠ không giải thích được LÝ DO.

  • C (Scrum Master phải thể hiện công việc của mình trong dự án) — ⚠ hiểu sai vai trò: ⚠ mục rà soát rủi ro không phải để Scrum Master chứng minh mình có làm việc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25736 ở lô này — ⚠ bàn giao trễ vì "rủi ro không lường trước", lẽ ra phải theo dõi rủi ro sát hơn. ⚠ Hai câu là hai mặt của cùng một bài học: câu kia là hậu quả khi KHÔNG theo dõi liên tục, câu này là cách làm đúng.

⚠ Quản lý rủi ro trong agile — các công cụ: | Công cụ | Nội dung | |---|---| | ⚠ Đưa mục rà soát rủi ro vào backlog | ⚠ cách của Isaac | | ⚠ RISK-ADJUSTED BACKLOG | ⚠ xếp ưu tiên các hạng mục có rủi ro cao lên TRƯỚC để học sớm | | ⚠ Risk burndown chart | ⚠ theo dõi tổng mức phơi nhiễm rủi ro giảm dần qua các vòng lặp | | ⚠ Rà soát rủi ro trong retrospective | | | ⚠ Spike | ⚠ một hạng mục nghiên cứu ngắn để giảm bất định kỹ thuật | | ⚠ Nguyên tắc chung | ⚠ agile giảm rủi ro bằng cách GIAO SỚM và học nhanh, nhưng vẫn cần quản lý rủi ro tường minh |

Từ khoá nhận diện:

"rủi ro đánh giá suốt vòng đời" → ⚠ Monitor Risks, và trong agile là mỗi vòng lặp "xếp việc rủi ro cao lên trước" → ⚠ risk-adjusted backlog "nghiên cứu ngắn để giảm bất định" → ⚠ spike "biểu đồ rủi ro giảm dần" → ⚠ risk burndown chart

⚠ Vì sao agile GIẢM rủi ro một cách tự nhiên Cơ chế
⚠ Giao hàng SỚM và THƯỜNG XUYÊN → phản hồi sớm
⚠ Vòng lặp ngắn → sai lầm chỉ tốn một vòng lặp
⚠ Ưu tiên hạng mục giá trị cao → nếu dừng giữa chừng vẫn có giá trị
⚠ Minh bạch qua daily standup và biểu đồ
⚠ Nhưng ⚠ giảm tự nhiên KHÔNG có nghĩa là không cần quản lý tường minh
⚠ Về con số trong đề Nội dung
⚠ Vượt chi 5.000 trên ngân sách 123.000 ⚠ khoảng 4,1%
⚠ Ở vòng lặp thứ 8
⚠ Chưa nghiêm trọng nhưng cần theo dõi ⚠ nếu xu hướng tiếp diễn thì cuối dự án sẽ vượt đáng kể
⚠ Đây chính là lý do ⚠ rà soát rủi ro định kỳ là việc đáng nằm trong backlog

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có rà soát rủi ro định kỳ không | ⚠ hay chỉ làm một lần ở đầu dự án | | Việc rà soát có HIỆN RA trong backlog không | ⚠ việc vô hình là việc không được làm | | Rủi ro cao có được đưa lên đầu backlog không | |

Và nguyên tắc thực dụng của agile: nếu một việc quan trọng mà không nằm trong backlog thì nó sẽ không được làm. Đưa rà soát rủi ro vào backlog không phải thừa thủ tục — đó là cách duy nhất đảm bảo nó thật sự xảy ra.

Câu 27 People
Millie's current project is a software development project expected to last 24 weeks. Recently Millie noticed that one of the stakeholders allotted time for senior developers to mentor others on the team. What is the most likely reason for this?
  1. A To help ensure the team has appropriate skills.
  2. B To inflate the project's budget.
  3. C The stakeholder does not trust younger team members.
  4. D The stakeholder is a mentor.
Xem giải thích

Đáp án

A — Để đảm bảo đội có đủ KỸ NĂNG phù hợp.

Vì sao đúng

⚠ Vì sao dành thời gian cho việc kèm cặp: | Lý do | Nội dung | |---|---| | ⚠ Dự án kéo dài 24 tuần | ⚠ đủ dài để việc đầu tư vào kỹ năng sinh lợi | | ⚠ Kèm cặp là cách chuyển giao TRI THỨC ẨN | ⚠ thứ không viết ra tài liệu được | | ⚠ Nâng năng lực đội → chất lượng tốt hơn, ít lỗi hơn | | | ⚠ Giảm rủi ro "chỉ một người biết" | ⚠ key person dependency | | ⚠ Thuộc quy trình | ⚠ Develop Team — phát triển đội dự án |

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

  • C (bên liên quan không tin tưởng thành viên trẻ) — ⚠ diễn giải TIÊU CỰC và không có căn cứ trong đề.

  • B (để thổi phồng ngân sách dự án) — ⚠ cáo buộc không có cơ sở; ⚠ đề không nêu dấu hiệu nào về việc này.

  • D (bên liên quan là một người kèm cặp) — ⚠ không giải thích được LÝ DO của quyết định.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25625 ở lô 177 về reverse shadowing và câu #25630 về tri thức ẩn. ⚠ Ba câu cùng chủ đề chuyển giao tri thức trong đội.

⚠ Vì sao đầu tư vào kỹ năng lại là quyết định tốt: | Lợi ích | Nội dung | |---|---| | ⚠ CHẤT LƯỢNG tốt hơn | ⚠ người có kỹ năng làm ít lỗi hơn — chi phí phòng ngừa | | ⚠ NĂNG SUẤT tăng về sau | ⚠ mất vài giờ đầu, tiết kiệm nhiều ngày sau | | ⚠ Giảm PHỤ THUỘC vào một cá nhân | | | ⚠ ĐỘNG LỰC tăng | ⚠ cơ hội phát triển là yếu tố ĐỘNG VIÊN theo Herzberg | | ⚠ Giữ chân nhân sự | | | ⚠ Chi phí | ⚠ thời gian của người kỳ cựu — đó là lý do phải được LÊN LỊCH chính thức, không làm tranh thủ |

Từ khoá nhận diện:

"dành thời gian cho kèm cặp" → ⚠ phát triển kỹ năng đội, quy trình Develop Team "kinh nghiệm khó viết thành tài liệu" → ⚠ tri thức ẩn "người học làm, chuyên gia đứng kèm" → ⚠ reverse shadowing "chỉ một người biết làm việc này" → ⚠ rủi ro phụ thuộc nhân sự chủ chốt

⚠ Các công cụ của Develop Team Công cụ
⚠ Colocation — ngồi cùng chỗ
⚠ Virtual teams — công nghệ cho đội phân tán
⚠ Communication technology
⚠ Interpersonal and team skills ⚠ quản lý xung đột, tạo ảnh hưởng, tạo động lực, đàm phán, xây dựng đội
⚠ Recognition and rewards
⚠ TRAINING ⚠ bao gồm kèm cặp và cố vấn — CÂU NÀY
⚠ Individual and team assessments
⚠ Meetings
⚠ Điều cần lưu ý khi lên lịch kèm cặp Lưu ý
⚠ Phải TÍNH VÀO lịch trình, không làm ngoài giờ
⚠ Người kỳ cựu giảm năng suất tạm thời ⚠ phải chấp nhận đánh đổi ngắn hạn
⚠ Ghép cặp phù hợp về tính cách và chuyên môn
⚠ Đo kết quả: người được kèm có làm độc lập được chưa
⚠ Sai lầm ⚠ giao kèm cặp mà không giảm khối lượng của người kèm — kết quả là cả hai đều chậm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có khoảng trống kỹ năng nào không | | | Có việc nào chỉ một người làm được không | ⚠ đó là rủi ro dự án | | Thời gian kèm cặp đã nằm trong lịch chưa | |

Và cách nhìn đúng về khoản thời gian này: kèm cặp không phải chi phí, đó là khoản đầu tư có kỳ hoàn vốn ngắn. Với dự án 24 tuần, vài giờ mỗi tuần thường hoàn vốn trong một tháng.

Câu 28 Process
You are a scrum consultant for the NightLight Company, and you are coaching a new scrum team on scrum and agile project management. After the first sprint, the agile project team must demonstrate the potentially shippable product increment to the project stakeholders. Which listed agile meeting would be appropriate to conduct this demo?
  1. A Retrospective meeting
  2. B Daily standup meeting
  3. C Sprint review
  4. D Deliverables meeting
Xem giải thích

Đáp án

C — Sprint review (buổi rà soát sprint).

Vì sao đúng

⚠ Sprint review là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Diễn ra ở CUỐI mỗi sprint | | | ⚠ Đội TRÌNH DIỄN increment có thể bàn giao được | ⚠ đúng chữ "potentially shippable product increment" | | ⚠ BÊN LIÊN QUAN tham dự và cho phản hồi | | | ⚠ Product owner chấp nhận hoặc từ chối hạng mục | ⚠ tương đương Validate Scope | | ⚠ Backlog được sắp lại ưu tiên dựa trên phản hồi | | | ⚠ Thời lượng | ⚠ tối đa 4 giờ cho sprint một tháng |

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

  • A (Retrospective — buổi nhìn lại) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ retrospective diễn ra ⚠ SAU sprint review, ⚠ nhưng nó bàn về ⚠ CÁCH LÀM VIỆC của đội chứ không trình diễn sản phẩm; ⚠ và ⚠ chỉ có đội tham dự, không có bên liên quan.

  • B (Daily standup) — ⚠ họp NGẮN hằng ngày, tối đa 15 phút, ⚠ để đội đồng bộ công việc trong ngày; ⚠ không phải nơi trình diễn.

  • D (Deliverables meeting) — ⚠ không phải sự kiện Scrum nào cả.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25674 ở lô 178 — ⚠ Validate Scope và Control Scope lặp lại mỗi vòng lặp cho product owner. ⚠ Sprint review chính là nơi hai quy trình đó diễn ra trong Scrum.

⚠ Năm sự kiện của Scrum: | Sự kiện | Thời điểm | Ai dự | Mục đích | |---|---|---|---| | ⚠ Sprint | ⚠ khung chứa mọi sự kiện khác | | ⚠ 1–4 tuần | | ⚠ Sprint planning | ⚠ ĐẦU sprint | ⚠ đội + PO + SM | ⚠ quyết làm gì và làm thế nào | | ⚠ Daily Scrum | ⚠ hằng ngày, 15 phút | ⚠ đội phát triển | ⚠ đồng bộ và phát hiện trở ngại | | ⚠ Sprint review | ⚠ CUỐI sprint | ⚠ đội + PO + SM + BÊN LIÊN QUAN | ⚠ trình diễn increment, lấy phản hồi — CÂU NÀY | | ⚠ Sprint retrospective | ⚠ SAU sprint review | ⚠ CHỈ đội + SM (+PO) | ⚠ cải tiến CÁCH LÀM VIỆC |

Từ khoá nhận diện:

"trình diễn sản phẩm cho bên liên quan" → ⚠ sprint review "nhìn lại cách làm việc để cải tiến" → ⚠ retrospective "đồng bộ 15 phút mỗi ngày" → ⚠ daily standup "quyết định làm gì trong sprint tới" → ⚠ sprint planning

⚠ Sprint review và retrospective — khác nhau ở đâu Khác biệt
⚠ Sprint review bàn về SẢN PHẨM ⚠ retrospective bàn về QUY TRÌNH
⚠ Sprint review có BÊN LIÊN QUAN ⚠ retrospective chỉ có đội
⚠ Sprint review hướng RA NGOÀI ⚠ retrospective hướng VÀO TRONG
⚠ Đầu ra: backlog được cập nhật ⚠ đầu ra: hành động cải tiến quy trình
⚠ Bẫy thi hay gặp nhất ⚠ đảo hai buổi này cho nhau
⚠ "Potentially shippable increment" nghĩa là gì Nghĩa
⚠ Phần sản phẩm ĐÃ HOÀN THIỆN theo định nghĩa DONE
⚠ CÓ THỂ phát hành được nếu muốn
⚠ Không nhất thiết PHẢI phát hành ⚠ quyết định phát hành thuộc về product owner
⚠ Điều kiện ⚠ đã kiểm thử, đã tích hợp, đạt Definition of Done
⚠ Sai lầm hay gặp ở sprint review Sai lầm
⚠ Biến nó thành buổi thuyết trình slide ⚠ phải trình diễn PHẦN MỀM CHẠY THẬT
⚠ Không mời bên liên quan ⚠ mất hết ý nghĩa của buổi này
⚠ Trình diễn thứ chưa DONE
⚠ Không cập nhật backlog sau khi nhận phản hồi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan có dự sprint review không | | | Bạn trình diễn sản phẩm chạy thật hay trình bày slide | | | Phản hồi có dẫn tới thay đổi backlog không | ⚠ nếu không thì buổi họp chỉ là hình thức |

Và giá trị cốt lõi của buổi này: nó biến "chúng tôi báo cáo là đã xong" thành "mời anh chị xem nó chạy". Đó là cơ chế kiểm chứng mạnh nhất mà Scrum có.

Câu 29 Process
Sara is a scrum master for Project Lexicon, which just completed its initial planning and is ready to begin the project work. To ensure the team knows who will be doing what, Sara has called a meeting to review some critical pieces of project documentation. What is Sara most likely to discuss?
  1. A Which stakeholders are most important.
  2. B The team's reporting structure.
  3. C The team's roles and responsibilities.
  4. D The project's schedule.
Xem giải thích

Đáp án

C — VAI TRÒ và TRÁCH NHIỆM của đội (roles and responsibilities).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ "để đảm bảo đội biết AI SẼ LÀM GÌ" | ⚠ → đúng định nghĩa vai trò và trách nhiệm | | ⚠ Vừa xong lập kế hoạch ban đầu, sắp bắt đầu công việc | ⚠ → thời điểm cần làm rõ phân vai | | ⚠ Công cụ phù hợp | ⚠ ma trận RACI hoặc team charter |

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

  • B (cơ cấu báo cáo của đội) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ cơ cấu báo cáo nói ⚠ AI BÁO CÁO CHO AI, ⚠ khác với ⚠ AI LÀM GÌ; ⚠ và trong Scrum, đội TỰ TỔ CHỨC nên cơ cấu báo cáo phẳng.

  • D (lịch trình dự án) — ⚠ nói KHI NÀO làm, ⚠ không nói AI làm.

  • A (bên liên quan nào quan trọng nhất) — ⚠ thuộc phân tích bên liên quan, ⚠ không trả lời câu hỏi ai làm gì trong đội.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25700 ở lô 179 về giai đoạn Storming — ⚠ ở đó đội cãi nhau đúng về "ai làm gì". ⚠ Làm rõ vai trò từ đầu chính là cách rút ngắn giai đoạn Storming.

⚠ Ma trận RACI — công cụ phân vai kinh điển: | Chữ | Nghĩa | Quy tắc | |---|---|---| | ⚠ R — Responsible | ⚠ người LÀM công việc | ⚠ có thể có NHIỀU người | | ⚠ A — Accountable | ⚠ người CHỊU TRÁCH NHIỆM cuối cùng | ⚠ CHỈ MỘT người cho mỗi công việc | | ⚠ C — Consulted | ⚠ người được THAM VẤN, giao tiếp hai chiều | | | ⚠ I — Informed | ⚠ người được THÔNG BÁO, giao tiếp một chiều | | | ⚠ Quy tắc vàng | ⚠ mỗi hàng phải có ĐÚNG MỘT chữ A và ÍT NHẤT MỘT chữ R |

Từ khoá nhận diện:

"ai làm gì" → ⚠ roles and responsibilities, RACI "ai báo cáo cho ai" → ⚠ cơ cấu tổ chức / reporting structure "khi nào làm" → ⚠ lịch trình "chỉ một người chịu trách nhiệm cuối cùng" → ⚠ chữ A trong RACI

⚠ Vai trò trong Scrum — Sara nên làm rõ những gì Vai trò
⚠ PRODUCT OWNER ⚠ sở hữu backlog, quyết LÀM GÌ và THỨ TỰ ưu tiên
⚠ SCRUM MASTER ⚠ gỡ trở ngại, bảo vệ quy trình, huấn luyện — KHÔNG giao việc
⚠ DEVELOPMENT TEAM ⚠ quyết LÀM THẾ NÀO, tự phân công, tự ước lượng
⚠ Ba vai trò này ⚠ hay bị lẫn nhất trong đội mới — nên phải làm rõ trước khi bắt đầu
⚠ Vì sao làm rõ vai trò SỚM lại quan trọng Lý do
⚠ Ngăn xung đột về thẩm quyền ⚠ giảm giai đoạn Storming
⚠ Ngăn công việc bị BỎ SÓT ⚠ "tôi tưởng anh làm"
⚠ Ngăn công việc bị LÀM TRÙNG
⚠ Cho phép ra quyết định nhanh ⚠ biết ai có quyền quyết
⚠ Chi phí nếu bỏ qua ⚠ mỗi tranh cãi về vai trò tốn nhiều thời gian hơn một buổi họp làm rõ
⚠ Các tài liệu chứa thông tin vai trò Tài liệu
⚠ Resource management plan ⚠ vai trò, trách nhiệm, thẩm quyền, năng lực
⚠ RACI / RAM ⚠ ma trận gán trách nhiệm
⚠ Team charter ⚠ quy tắc làm việc chung, do đội tự tạo
⚠ Project charter ⚠ thẩm quyền của quản lý dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi công việc có đúng một người chịu trách nhiệm cuối cùng không | | | Có công việc nào không ai nhận không | | | Đội có hiểu ranh giới giữa Scrum Master và Product Owner không | |

Và bài học rẻ nhất trong quản lý đội: một buổi làm rõ vai trò ở đầu dự án tiết kiệm nhiều tuần tranh cãi về sau. Sara đang làm đúng thời điểm.

Câu 30 People
Mohammed is a project manager at Fantastic Faucets. Lately, he has been getting a lot of customer complaints about one of the company's best-selling faucets, which is manufactured in their own plant. The faucets are rusting after less than a year of use. To identify the cause of the problem, which tool should Mohammed and his team use?
  1. A Ishikawa diagram
  2. B Statistical sampling
  3. C Experimental design
  4. D Flowchart
Xem giải thích

Đáp án

A — Ishikawa diagram (biểu đồ xương cá, tức biểu đồ nhân quả).

Vì sao đúng

⚠ Vì sao Ishikawa phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Đề hỏi TÌM NGUYÊN NHÂN của vấn đề | ⚠ "identify the cause of the problem" | | ⚠ Vòi nước bị gỉ sau chưa tới một năm | ⚠ có thể do nhiều nguyên nhân khác nhau | | ⚠ Cần quy trình có cấu trúc để không bỏ sót nhóm nguyên nhân nào | | | ⚠ Là công cụ tập thể — cả đội cùng làm | | | ⚠ Kết luận | ⚠ Ishikawa là công cụ chuẩn cho phân tích nguyên nhân gốc |

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

  • D (Flowchart — lưu đồ) — ⚠ vẽ các bước của quy trình, ⚠ hữu ích để hiểu quy trình sản xuất nhưng ⚠ không phải công cụ truy nguyên nhân.

  • B (Statistical sampling — lấy mẫu thống kê) — ⚠ dùng để ĐO tỷ lệ lỗi trên một mẫu, ⚠ trả lời "bao nhiêu" chứ không trả lời "vì sao".

  • C (Experimental design — thiết kế thực nghiệm) — ⚠ dùng để THỬ NGHIỆM các phương án và tìm cấu hình tối ưu; ⚠ có thể dùng ở bước SAU, khi đã có giả thuyết cần kiểm chứng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25664 ở lô 178 và câu #25626 ở lô 177 — ⚠ cả hai đều về Ishikawa và Pareto. ⚠ Đây là công cụ được hỏi nhiều nhất trong nhóm bảy công cụ chất lượng.

⚠ Sáu nhóm nguyên nhân 6M — áp vào bài toán vòi nước gỉ: | Nhóm | Nguyên nhân có thể | |---|---| | ⚠ Material — VẬT LIỆU | ⚠ hợp kim sai, lớp mạ mỏng, đổi nhà cung cấp nguyên liệu | | ⚠ Machine — MÁY MÓC | ⚠ bể mạ hỏng, thiết bị chưa hiệu chuẩn | | ⚠ Method — PHƯƠNG PHÁP | ⚠ thời gian mạ không đủ, quy trình xử lý bề mặt sai | | ⚠ Man — CON NGƯỜI | ⚠ công nhân mới chưa được đào tạo | | ⚠ Measurement — ĐO LƯỜNG | ⚠ không kiểm tra độ dày lớp mạ | | ⚠ Environment — MÔI TRƯỜNG | ⚠ độ ẩm nhà xưởng, hoặc điều kiện sử dụng của khách | | ⚠ Nhờ khung này | ⚠ đội không bỏ sót nhóm nguyên nhân nào, kể cả nhóm ít ai nghĩ tới như đo lường |

Từ khoá nhận diện:

"tìm nguyên nhân của vấn đề" → ⚠ Ishikawa / cause-and-effect "loại lỗi nào nhiều nhất" → ⚠ Pareto "kiểm tra một mẫu để suy ra cả lô" → ⚠ statistical sampling "thử nhiều cấu hình tìm phương án tốt nhất" → ⚠ design of experiments "vẽ các bước quy trình" → ⚠ flowchart

⚠ Trình tự đầy đủ Mohammed nên làm Bước
⚠ 1. Thu thập DỮ LIỆU khiếu nại ⚠ check sheet — bao nhiêu, loại nào, lô nào
⚠ 2. Xếp hạng bằng PARETO nếu có nhiều loại lỗi
⚠ 3. Vẽ ISHIKAWA cho lỗi gỉ ⚠ bước của câu này
⚠ 4. Hỏi 5 WHYS cho các nhánh khả nghi
⚠ 5. KIỂM CHỨNG giả thuyết bằng dữ liệu hoặc thực nghiệm ⚠ lúc này mới dùng design of experiments
⚠ 6. Hành động khắc phục và theo dõi bằng CONTROL CHART
⚠ Lưu ý quan trọng Lưu ý
⚠ Ishikawa sinh ra GIẢ THUYẾT, không sinh ra KẾT LUẬN
⚠ Phải kiểm chứng bằng dữ liệu trước khi sửa
⚠ Sửa nhầm nguyên nhân thì lỗi quay lại
⚠ Đây là chi phí lỗi BÊN NGOÀI ⚠ khách hàng đã phát hiện — loại đắt nhất trong bốn nhóm chi phí chất lượng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vấn đề đã được mô tả đủ cụ thể chưa | ⚠ "gỉ sau dưới một năm" — cụ thể, tốt | | Có nhóm nguyên nhân nào bị bỏ qua không | ⚠ rà theo 6M | | Giả thuyết đã được kiểm chứng chưa | |

Và điều làm nên giá trị của công cụ đơn giản này: nó buộc cả nhóm nghĩ tới những nhóm nguyên nhân không ai tự nhiên nghĩ tới. Với vòi nước gỉ, ai cũng nghĩ tới vật liệu — ít ai nghĩ tới khâu đo lường.