Ngân hàng đề — PMP® Mock Exam Set I Exam
Tìm thấy 720 câu.
- A A not-for-profit entity
- B An example of providing the public with information on the PMP career and certification
- C An example of contributing to the project management knowledge base
- D A breach of the PMP Code of Professional Conduct
Xem giải thích
Đáp án
C — Một ví dụ về việc ĐÓNG GÓP VÀO KHO TRI THỨC quản lý dự án.
Vì sao đúng
⚠ Vì sao đây là đóng góp vào kho tri thức nghề: | Hành động | Ý nghĩa | |---|---| | ⚠ Tạo trang web CÔNG KHAI | ⚠ ai cũng truy cập được | | ⚠ Giải thích công thức, lý thuyết, ứng dụng quản lý dự án | ⚠ nội dung chuyên môn thực chất | | ⚠ Miễn phí, không thu lợi | | | ⚠ Giúp người khác học nghề | | | ⚠ PMI khuyến khích | ⚠ đây là một trong các hoạt động "Giving Back" được tính PDU |
Vì sao các phương án khác sai
-
D (vi phạm Quy tắc Ứng xử Nghề nghiệp PMP) — ⚠ SAI HẲN: ⚠ chia sẻ tri thức chuyên môn công khai là điều PMI ⚠ KHUYẾN KHÍCH, không cấm; ⚠ chỉ vi phạm nếu tiết lộ ⚠ nội dung đề thi thật hoặc dùng sai logo và nhãn hiệu PMI.
-
B (cung cấp thông tin cho công chúng về nghề và chứng chỉ PMP) — ⚠ quá hẹp: ⚠ nội dung là công thức và lý thuyết chuyên môn, ⚠ không phải giới thiệu về chứng chỉ.
-
A (một tổ chức phi lợi nhuận) — ⚠ nhầm HÌNH THỨC PHÁP LÝ với NỘI DUNG hoạt động; ⚠ một trang web cá nhân không phải một pháp nhân.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25757 và #25761 ở lô 180 về thu thập và chia sẻ bài học kinh nghiệm. ⚠ Cùng tinh thần: tri thức chỉ có giá trị khi được chia sẻ.
⚠ Ba loại hoạt động "Giving Back" tính PDU: | Loại | Nội dung | |---|---| | ⚠ Work as a Practitioner | ⚠ hành nghề quản lý dự án — tối đa 8 PDU mỗi chu kỳ | | ⚠ CREATE KNOWLEDGE | ⚠ viết bài, viết blog, làm trang web, thuyết trình, dạy học — CÂU NÀY | | ⚠ Volunteer | ⚠ tình nguyện cho PMI hoặc tổ chức khác | | ⚠ Giới hạn | ⚠ tối đa 25 PDU cho toàn bộ nhóm Giving Back trong chu kỳ 3 năm |
⚠ Yêu cầu PDU để duy trì chứng chỉ PMP: | Mục | Số | |---|---| | ⚠ Tổng PDU mỗi chu kỳ 3 năm | ⚠ 60 | | ⚠ Tối thiểu cho Ways of Working (kỹ thuật) | ⚠ 8 | | ⚠ Tối thiểu cho Power Skills (lãnh đạo) | ⚠ 8 | | ⚠ Tối thiểu cho Business Acumen (chiến lược) | ⚠ 8 | | ⚠ Tối đa từ Giving Back | ⚠ 25 | | ⚠ Liên hệ | ⚠ xem câu #25616 ở lô 177 về PMI Talent Triangle |
Từ khoá nhận diện:
"chia sẻ kiến thức công khai, viết bài, dạy học" → ⚠ đóng góp kho tri thức, tính PDU "tiết lộ nội dung đề thi" → ⚠ VI PHẠM quy tắc ứng xử "dùng logo PMI sai mục đích" → ⚠ vi phạm "cố vấn cho quản lý dự án khác" → ⚠ cũng là giving back
⚠ Bốn giá trị trong Quy tắc Đạo đức của PMI: | Giá trị | Nội dung | |---|---| | ⚠ Responsibility | ⚠ chịu trách nhiệm về quyết định, báo cáo vi phạm | | ⚠ Respect | ⚠ tôn trọng con người và tài sản trí tuệ | | ⚠ Fairness | ⚠ khách quan, tránh xung đột lợi ích | | ⚠ Honesty | ⚠ trung thực trong mọi giao tiếp | | ⚠ Hành động của bạn | ⚠ phù hợp với cả bốn giá trị — đặc biệt là RESPECT khi nâng cao năng lực cộng đồng nghề |
| ⚠ Điều CẦN cẩn thận khi làm trang web như vậy | Lưu ý |
|---|---|
| ⚠ KHÔNG đăng nội dung đề thi thật | ⚠ vi phạm nghiêm trọng nhất |
| ⚠ TÔN TRỌNG bản quyền — trích dẫn nguồn khi dùng tài liệu PMI | |
| ⚠ Không dùng nhãn hiệu PMI theo cách gây hiểu lầm là được PMI bảo trợ | |
| ⚠ Nội dung phải CHÍNH XÁC | ⚠ dạy sai còn hại hơn không dạy |
| ⚠ Nếu tuân thủ | ⚠ đây là hoạt động rất đáng khuyến khích |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nội dung có vi phạm bản quyền hay bảo mật đề thi không | | | Bạn đã ghi nhận hoạt động này để tính PDU chưa | | | Thông tin có được kiểm chứng về mặt chuyên môn không | |
Và tinh thần nghề nghiệp mà PMI đề cao: nghề quản lý dự án phát triển được là nhờ người đi trước chia sẻ lại. Một trang web giải thích công thức EVM miễn phí có giá trị hơn nhiều so với việc giữ kiến thức cho riêng mình.
- A Determine what communication tools can be provided to integrate the new team member.
- B Remove that team member and find someone local.
- C Complain to the product owner.
- D Force that team member to move closer to the rest of the team.
Xem giải thích
Đáp án
A — Xác định các CÔNG CỤ GIAO TIẾP có thể cung cấp để hoà nhập thành viên mới.
Vì sao đúng
⚠ Vì sao đây là hành động đúng: | Lý do | Nội dung | |---|---| | ⚠ Đội đã có VELOCITY ỔN ĐỊNH 68 điểm sau 9 vòng lặp | ⚠ đội đang hoạt động tốt, không cần đảo lộn | | ⚠ Thành viên mới ở NƯỚC KHÁC — vấn đề là KHOẢNG CÁCH | | | ⚠ Vấn đề khoảng cách khắc phục được bằng CÔNG CỤ | | | ⚠ Scrum Master có trách nhiệm GỠ TRỞ NGẠI | ⚠ đây chính là một trở ngại cần gỡ | | ⚠ Kết luận | ⚠ giải quyết vấn đề thay vì loại bỏ người hoặc phàn nàn |
Vì sao các phương án khác sai
-
B (loại thành viên đó và tìm người địa phương) — ⚠ loại bỏ con người, gần như luôn là đáp án SAI; ⚠ và mất luôn năng lực người đó mang lại.
-
D (buộc thành viên đó chuyển đến gần đội) — ⚠ yêu cầu bất hợp lý và vượt thẩm quyền; ⚠ Scrum Master không có quyền buộc ai chuyển chỗ ở.
-
C (phàn nàn với product owner) — ⚠ né tránh trách nhiệm: ⚠ product owner lo backlog, ⚠ không lo việc hoà nhập đội — đó là việc của Scrum Master.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25784 ở lô này về hội nghị truyền hình là công cụ tốt nhất cho đội ảo, câu #25787 về rủi ro niềm tin ban đầu, và câu #25789 về collocated team. ⚠ Bốn câu tạo thành bộ đầy đủ về đội phân tán — câu này là tình huống áp dụng.
⚠ Leslie nên cung cấp những gì: | Công cụ | Mục đích | |---|---| | ⚠ Hội nghị truyền hình có CAMERA | ⚠ giữ giao tiếp phi ngôn ngữ, xây niềm tin | | ⚠ Phần mềm bảng công việc trực tuyến | ⚠ thay cho bảng vật lý mà đội đang dùng | | ⚠ Kênh nhắn tin nhóm | ⚠ thay cho việc quay sang hỏi nhau | | ⚠ Kho tài liệu dùng chung | | | ⚠ Công cụ cộng tác thời gian thực | ⚠ bảng trắng ảo cho các buổi lập kế hoạch | | ⚠ Ngoài công cụ | ⚠ còn phải điều chỉnh GIỜ HỌP cho công bằng và giới thiệu người mới với cả đội |
Từ khoá nhận diện:
"thành viên mới ở xa" → ⚠ cung cấp công cụ để hoà nhập "loại người, buộc chuyển chỗ" → ⚠ luôn là đáp án sai "phàn nàn với người khác" → ⚠ né tránh trách nhiệm "Scrum Master nên làm gì" → ⚠ gỡ trở ngại
| ⚠ Tác động của việc thêm người ở xa vào đội đang ổn định | Tác động |
|---|---|
| ⚠ VELOCITY sẽ GIẢM tạm thời | ⚠ người mới cần thời gian làm quen — điều này BÌNH THƯỜNG |
| ⚠ Đội quay lại giai đoạn FORMING với người mới | ⚠ xem câu #25743 ở lô 180 |
| ⚠ Giao tiếp phải chuyển từ trực tiếp sang có công cụ hỗ trợ | |
| ⚠ Cả đội, không chỉ người mới, phải điều chỉnh | ⚠ điểm hay bị bỏ qua |
| ⚠ Leslie nên | ⚠ báo trước với đội và bên liên quan rằng velocity có thể giảm vài vòng lặp |
| ⚠ Điều nên làm ngoài việc cấp công cụ | Việc |
|---|---|
| ⚠ Giới thiệu người mới với cả đội qua video | |
| ⚠ Ghép cặp với một thành viên kỳ cựu làm người đỡ đầu | ⚠ buddy system |
| ⚠ Rà soát lại hiến chương đội với sự tham gia của người mới | |
| ⚠ Điều chỉnh giờ daily standup cho phù hợp múi giờ | |
| ⚠ Ghi lại quyết định bằng văn bản nhiều hơn trước | ⚠ đội phân tán không nghe lỏm được như đội ngồi cùng chỗ |
| ⚠ Vì sao KHÔNG nên loại người mới | Lý do |
|---|---|
| ⚠ Họ được tuyển vì có năng lực cần thiết | |
| ⚠ Khoảng cách là vấn đề KỸ THUẬT giải quyết được | |
| ⚠ Loại người vì địa lý là phân biệt đối xử | |
| ⚠ Tuyển lại tốn thời gian và chi phí |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới có đủ công cụ để tham gia đầy đủ chưa | | | Giờ họp có công bằng với mọi múi giờ không | | | Đội cũ có điều chỉnh cách làm việc không | ⚠ không chỉ người mới phải thích nghi |
Và tư duy đúng của một Scrum Master: khi có trở ngại, hỏi "gỡ thế nào" chứ không hỏi "bỏ ai". Khoảng cách địa lý là trở ngại có công cụ để gỡ — chỉ cần có người chịu trách nhiệm gỡ nó.
- A Definitive estimate
- B Budget estimate
- C Rough order of magnitude
- D WBS estimate
Xem giải thích
Đáp án
C — Rough order of magnitude (ước lượng thô — ROM).
Vì sao đúng
⚠ Thang độ chính xác — từ kém nhất tới tốt nhất: | Loại | Dải sai số | Độ chính xác | |---|---|---| | ⚠ ROM | ⚠ −25% đến +75% | ⚠ KÉM NHẤT — CÂU NÀY | | ⚠ Budget estimate | ⚠ −10% đến +25% | ⚠ trung bình | | ⚠ Definitive estimate | ⚠ −5% đến +10% | ⚠ CHÍNH XÁC NHẤT |
⚠ Vì sao ROM kém chính xác nhất: | Lý do | Nội dung | |---|---| | ⚠ Lập ở giai đoạn KHỞI TẠO, thông tin rất ít | | | ⚠ Chưa có WBS, chưa phân rã công việc | | | ⚠ Dựa nhiều vào phán đoán chuyên gia và dự án tương tự | | | ⚠ Dải sai số RỘNG NHẤT: tổng cộng 100 điểm phần trăm | ⚠ từ −25% tới +75% |
Vì sao các phương án khác sai
-
A (Definitive estimate) — ⚠ CHÍNH XÁC NHẤT, ⚠ ngược hẳn câu hỏi; ⚠ đây chính là loại Erika cần cho dự án đòi độ chính xác cao.
-
B (Budget estimate) — ⚠ chính xác hơn ROM nhưng kém hơn definitive.
-
D (WBS estimate) — ⚠ KHÔNG phải tên một loại ước lượng; ⚠ WBS là ĐẦU VÀO để lập ước lượng dứt khoát theo phương pháp bottom-up.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25770 ở lô 180 (vừa khởi động → ROM), câu #25613 ở lô 177 (ROM ngoài hành lang) và câu #25647 ở lô 178 (ước lượng dứt khoát cần WBS). ⚠ Bốn câu là bộ đầy đủ nhất về chủ đề này trong toàn bộ ngân hàng đề.
⚠ Erika cần gì cho dự án đòi độ chính xác cao: | Bước | Việc | |---|---| | ⚠ 1. Hoàn thiện WBS tới mức GÓI CÔNG VIỆC | | | ⚠ 2. Lập danh sách hoạt động từ gói công việc | | | ⚠ 3. Ước lượng BOTTOM-UP từng hoạt động | ⚠ phương pháp cho độ chính xác cao nhất | | ⚠ 4. Cộng dồn lên | | | ⚠ 5. Thêm dự phòng dựa trên phân tích rủi ro | | | ⚠ Kết quả | ⚠ definitive estimate, sai số −5% đến +10% | | ⚠ Cái giá | ⚠ TỐN THỜI GIAN và công sức nhất — Erika phải báo trước điều này |
⚠ Bốn kỹ thuật ước lượng và độ chính xác: | Kỹ thuật | Tốc độ | Độ chính xác | |---|---|---| | ⚠ Analogous | ⚠ NHANH nhất | ⚠ THẤP nhất | | ⚠ Parametric | ⚠ nhanh | ⚠ trung bình đến cao, tuỳ chất lượng đơn giá | | ⚠ Three-point | ⚠ trung bình | ⚠ cho ra DẢI, phản ánh bất định | | ⚠ Bottom-up | ⚠ CHẬM nhất | ⚠ CAO nhất | | ⚠ Quy luật | ⚠ độ chính xác tỷ lệ thuận với công sức bỏ ra |
Từ khoá nhận diện:
"kém chính xác nhất" → ⚠ ROM "chính xác nhất" → ⚠ definitive, lập bằng bottom-up "cần ngân sách đáng tin" → ⚠ definitive, cần WBS "nhanh, dựa vào dự án tương tự" → ⚠ analogous
| ⚠ Điều Erika nên nói với quản lý | Nội dung |
|---|---|
| ⚠ "Ước lượng dứt khoát cho sai số −5% đến +10%" | |
| ⚠ "Nhưng nó cần WBS hoàn chỉnh trước" | |
| ⚠ "Việc đó mất khoảng X tuần" | ⚠ nêu rõ cái giá về thời gian |
| ⚠ "Trong lúc chờ, tôi có thể đưa ROM để tham khảo" | ⚠ đáp ứng nhu cầu trước mắt |
| ⚠ Đừng | ⚠ hứa độ chính xác cao mà không có dữ liệu để đạt được nó |
| ⚠ Hình nón bất định — nhắc lại | Nội dung |
|---|---|
| ⚠ Đầu dự án: dải sai số rộng nhất | |
| ⚠ Càng có thông tin, dải càng hẹp | |
| ⚠ Không thể có ước lượng chính xác khi chưa có thông tin | ⚠ đây là quy luật, không phải vấn đề kỹ năng |
| ⚠ Sai lầm của tổ chức | ⚠ đòi độ chính xác của definitive ở thời điểm chỉ có dữ liệu cho ROM |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đủ thông tin cho mức chính xác được yêu cầu không | | | WBS đã hoàn chỉnh chưa | ⚠ điều kiện bắt buộc của definitive | | Bạn đã nói rõ cái giá về thời gian chưa | |
Và điều Erika cần làm rõ ngay từ đầu: độ chính xác cao là thứ MUA được bằng thời gian, không phải bằng nỗ lực. Không có dữ liệu thì không có ước lượng chính xác, dù người làm giỏi tới đâu.
- A Risk register
- B Schedule management plan
- C Release plan
- D Constraints
Xem giải thích
Đáp án
C — Release plan (kế hoạch phát hành). ⚠ Hiện vật này KHÔNG giúp cho việc xây nhà chứa máy bay.
Vì sao đúng
⚠ Vì sao release plan không phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Release plan là hiện vật của cách tiếp cận LINH HOẠT | ⚠ lập kế hoạch cho nhiều đợt PHÁT HÀNH sản phẩm | | ⚠ Dùng cho sản phẩm giao THÀNH NHIỀU ĐỢT tăng dần | ⚠ thường là phần mềm | | ⚠ Xây nhà chứa máy bay là dự án XÂY DỰNG | ⚠ giao MỘT LẦN, vòng đời DỰ ĐOÁN | | ⚠ Không thể "phát hành" nửa cái nhà chứa máy bay | | | ⚠ Kết luận | ⚠ khái niệm phát hành theo đợt không áp dụng được ở đây |
Vì sao các phương án khác sai
⚠ Cả ba phương án còn lại đều CẦN THIẾT cho dự án xây dựng:
-
A (Risk register — sổ đăng ký rủi ro) — ⚠ RẤT cần: ⚠ dự án xây dựng đầy rủi ro về thời tiết, an toàn, vật tư, giấy phép.
-
B (Schedule management plan) — ⚠ RẤT cần: ⚠ dự án xây dựng phụ thuộc nặng vào lịch trình và trình tự thi công.
-
D (Constraints — ràng buộc) — ⚠ RẤT cần: ⚠ giới hạn ngân sách, hạn chót, quy định xây dựng, điều kiện mặt bằng.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25781 ở lô 180 về vòng đời tăng dần và câu #25686 ở lô 179 về vòng đời dự đoán. ⚠ Ba câu cùng làm rõ: chọn hiện vật phải khớp với VÒNG ĐỜI dự án.
⚠ Hiện vật theo từng cách tiếp cận: | Cách tiếp cận | Hiện vật đặc trưng | |---|---| | ⚠ DỰ ĐOÁN | ⚠ WBS, đường cơ sở lịch và chi phí, biểu đồ Gantt, sơ đồ mạng, EVM, kế hoạch quản lý các loại | | ⚠ THÍCH ỨNG | ⚠ product backlog, sprint backlog, RELEASE PLAN, burndown chart, velocity, user story | | ⚠ DÙNG CHUNG cả hai | ⚠ risk register, issue log, stakeholder register, assumption log, ràng buộc, điều lệ | | ⚠ Nguyên tắc | ⚠ hiện vật phải phục vụ cách làm việc thật, không phải để có cho đủ bộ |
Từ khoá nhận diện:
"release plan, sprint backlog, velocity, burndown" → ⚠ hiện vật LINH HOẠT "WBS, Gantt, đường cơ sở, EVM" → ⚠ hiện vật DỰ ĐOÁN "risk register, issue log, ràng buộc" → ⚠ dùng cho MỌI cách tiếp cận "dự án xây dựng" → ⚠ hầu như luôn là vòng đời dự đoán
| ⚠ Release plan chứa gì | Nội dung |
|---|---|
| ⚠ Các đợt phát hành dự kiến và mốc thời gian | |
| ⚠ Tính năng nào vào đợt nào | |
| ⚠ Số vòng lặp cần cho mỗi đợt | |
| ⚠ Dựa trên VELOCITY của đội để dự báo | |
| ⚠ Chỉ có nghĩa khi | ⚠ sản phẩm giao được THÀNH NHIỀU PHẦN dùng được |
| ⚠ Vì sao dự án xây dựng thường dùng vòng đời dự đoán | Lý do |
|---|---|
| ⚠ Chi phí THAY ĐỔI giữa chừng CỰC KỲ cao | ⚠ đã đổ móng thì không đổi thiết kế móng được |
| ⚠ Yêu cầu kỹ thuật và pháp lý rõ ràng từ đầu | |
| ⚠ Ràng buộc vật lý nghiêm ngặt | ⚠ nhiều phụ thuộc BẮT BUỘC — xem câu #25673 |
| ⚠ Không giao được từng phần dùng được | |
| ⚠ Ngoại lệ | ⚠ có dự án xây dựng dùng cách LAI cho phần thiết kế, còn thi công thì dự đoán |
| ⚠ Các hiện vật quan trọng cho dự án xây nhà chứa máy bay | Hiện vật |
|---|---|
| ⚠ Điều lệ dự án | |
| ⚠ WBS và từ điển WBS | |
| ⚠ Kế hoạch quản lý lịch trình và sơ đồ mạng | ⚠ phụ thuộc bắt buộc rất nhiều |
| ⚠ Đường cơ sở chi phí | |
| ⚠ Sổ đăng ký rủi ro | ⚠ thời tiết, an toàn, vật tư |
| ⚠ Kế hoạch quản lý chất lượng | ⚠ tiêu chuẩn xây dựng bắt buộc |
| ⚠ Tài liệu mua sắm và hợp đồng | |
| ⚠ Sổ đăng ký giả định và ràng buộc |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vòng đời dự án của bạn là gì | ⚠ quyết định bộ hiện vật cần dùng | | Sản phẩm có giao được thành nhiều đợt không | ⚠ nếu không thì release plan vô nghĩa | | Bạn có đang tạo hiện vật chỉ vì "phải có" không | |
Và nguyên tắc chọn hiện vật: công cụ phải khớp với cách làm việc. Lập release plan cho một nhà chứa máy bay cũng vô nghĩa như lập WBS chi tiết cho một backlog thay đổi hằng tuần.
- A Hire a trained facilitator to keep the team engaged.
- B Facilitate a team discussion on team engagement.
- C Update the team charter and include a clause not to have phones present in the meeting.
- D Give each team member a specific task with a learning outcome to share.
Xem giải thích
Đáp án
B — Điều phối một cuộc THẢO LUẬN CỦA ĐỘI về sự tham gia (team engagement).
Vì sao đúng
⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Đội TỰ TỔ CHỨC — vấn đề của đội thì đội cùng giải quyết | | | ⚠ Vai trò của Scrum Master là ĐIỀU PHỐI, không phải ra lệnh | ⚠ facilitate, không dictate | | ⚠ Nếu Kevin mất tập trung thì có thể còn người khác cũng vậy | ⚠ thảo luận chung phát hiện được vấn đề rộng hơn | | ⚠ Có thể retrospective đang có vấn đề về CÁCH TỔ CHỨC | ⚠ nhàm chán, quá dài, không dẫn tới hành động nào | | ⚠ Kết luận | ⚠ để đội tự nhận ra và tự đặt ra quy tắc cho mình |
Vì sao các phương án khác sai
-
C (cập nhật hiến chương đội, thêm điều khoản cấm điện thoại) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ đây là ⚠ giải pháp ÁP ĐẶT cho một TRIỆU CHỨNG; ⚠ hiến chương đội phải do ⚠ ĐỘI tự xây, không phải Scrum Master tự thêm điều khoản; ⚠ và ⚠ cấm điện thoại không làm người ta quan tâm hơn — nếu buổi họp nhàm chán thì họ sẽ mất tập trung theo cách khác.
-
A (thuê người điều phối chuyên nghiệp) — ⚠ tốn kém và không cần thiết; ⚠ điều phối retrospective chính là việc của Scrum Master.
-
D (giao mỗi người một nhiệm vụ có kết quả học tập để chia sẻ) — ⚠ biến retrospective thành bài tập; ⚠ và vẫn là giải pháp áp đặt từ trên xuống.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25678 ở lô 178 (đội tự thực thi hiến chương đội), câu #25747 ở lô 180 (hỏi đội muốn xử lý thế nào), và câu #25729 ở lô 179 (kéo cả đội vào giải quyết vấn đề). ⚠ Bốn câu cùng một nguyên tắc bất biến: giải pháp phải đến TỪ đội.
⚠ Retrospective — cách làm cho hiệu quả: | Yếu tố | Nội dung | |---|---| | ⚠ Có KHÔNG GIAN AN TOÀN để nói thật | ⚠ không đổ lỗi, không trách móc | | ⚠ Có CẤU TRÚC rõ ràng | ⚠ cái gì tốt, cái gì chưa tốt, lần sau làm gì khác | | ⚠ Đổi ĐỊNH DẠNG thường xuyên | ⚠ cùng một cách làm 20 lần sẽ nhàm chán | | ⚠ Dẫn tới HÀNH ĐỘNG cụ thể | ⚠ quan trọng nhất | | ⚠ Theo dõi hành động của lần trước | | | ⚠ Nguyên nhân phổ biến khiến người ta mất tập trung | ⚠ retrospective không dẫn tới thay đổi gì — nên họ thấy vô ích |
Từ khoá nhận diện:
"thành viên mất tập trung" → ⚠ thảo luận với đội, tìm nguyên nhân "thêm điều khoản cấm" → ⚠ áp đặt, xử lý triệu chứng "thuê người ngoài" → ⚠ thường không cần thiết "đội tự tổ chức" → ⚠ giải pháp đến từ đội
| ⚠ Nguyên nhân THẬT có thể khiến Kevin mất tập trung | Nguyên nhân |
|---|---|
| ⚠ Retrospective trước không dẫn tới thay đổi nào | ⚠ nguyên nhân phổ biến nhất |
| ⚠ Anh ấy không cảm thấy ý kiến của mình được lắng nghe | |
| ⚠ Có việc gấp bên ngoài | |
| ⚠ Buổi họp quá dài hoặc lặp lại nhàm chán | |
| ⚠ Không cảm thấy an toàn để nói thật | ⚠ liên hệ câu #25787 về niềm tin |
| ⚠ Với mỗi nguyên nhân | ⚠ giải pháp hoàn toàn khác nhau — nên phải HỎI trước |
| ⚠ Cách Ken điều phối cuộc thảo luận | Cách |
|---|---|
| ⚠ Nêu vấn đề CHUNG, không chỉ đích danh Kevin | ⚠ "tôi thấy mức tham gia gần đây có vẻ giảm" |
| ⚠ Hỏi đội: retrospective có đang hữu ích không? | |
| ⚠ Hỏi: chúng ta nên làm gì khác đi? | |
| ⚠ Để ĐỘI đề xuất quy tắc, kể cả quy tắc về điện thoại | ⚠ quy tắc do đội đặt thì đội mới giữ |
| ⚠ Nếu cần: nói chuyện RIÊNG với Kevin sau | |
| ⚠ Đừng | ⚠ chỉ trích Kevin trước cả đội |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retrospective gần nhất có dẫn tới hành động nào không | ⚠ nếu không thì đó là nguyên nhân gốc | | Đội có cảm thấy an toàn để nói thật không | | | Bạn đang áp giải pháp hay đang hỏi đội | |
Và nguyên nhân phổ biến nhất khiến người ta lơ đãng trong retrospective: họ đã nói rồi mà chẳng có gì thay đổi. Sửa được điều đó thì không cần cấm điện thoại.
- A Teaching
- B Counseling
- C Providing feedback
- D Goal setting
Xem giải thích
Đáp án
B — Counseling (tư vấn).
Vì sao đúng
⚠ Phân biệt cố vấn và huấn luyện: | Mục | MENTORING — cố vấn | COACHING — huấn luyện | |---|---|---| | ⚠ Trọng tâm | ⚠ PHÁT TRIỂN CON NGƯỜI và SỰ NGHIỆP | ⚠ nâng HIỆU SUẤT ở một kỹ năng cụ thể | | ⚠ Thời gian | ⚠ DÀI HẠN, nhiều năm | ⚠ NGẮN HẠN, theo mục tiêu cụ thể | | ⚠ Quan hệ | ⚠ người đi trước dẫn dắt người đi sau | ⚠ chuyên gia hướng dẫn kỹ năng | | ⚠ Nội dung | ⚠ TƯ VẤN, chia sẻ kinh nghiệm, định hướng nghề nghiệp | ⚠ phản hồi, đặt mục tiêu, luyện kỹ năng | | ⚠ Đặc trưng riêng | ⚠ COUNSELING — CÂU NÀY | ⚠ teaching, feedback, goal setting |
⚠ Vì sao "counseling" là câu trả lời: | Lý do | Nội dung | |---|---| | ⚠ Cố vấn bàn cả những chuyện NGOÀI kỹ năng công việc | ⚠ định hướng sự nghiệp, cân bằng cuộc sống, quyết định lớn | | ⚠ Người được cố vấn tìm tới để XIN LỜI KHUYÊN | | | ⚠ Quan hệ dựa trên TIN CẬY cá nhân, không chỉ chuyên môn | | | ⚠ Ba phương án kia | ⚠ teaching, providing feedback, goal setting đều có ở CẢ hai — nên không phân biệt được |
Vì sao các phương án khác sai
- A (Teaching — dạy học), C (Providing feedback — đưa phản hồi), D (Goal setting — đặt mục tiêu) — ⚠ cả ba đều là hoạt động của HUẤN LUYỆN, ⚠ và cũng xuất hiện trong cố vấn; ⚠ chúng KHÔNG phải đặc trưng phân biệt.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25625 ở lô 177 về reverse shadowing, câu #25749 ở lô 180 về dành thời gian cho kèm cặp, và câu #25793 ở lô này về đóng góp vào kho tri thức. ⚠ Bốn câu cùng chủ đề phát triển con người trong nghề.
⚠ Ba khái niệm dễ lẫn: | Khái niệm | Nội dung | |---|---| | ⚠ Mentoring | ⚠ quan hệ DÀI HẠN, phát triển toàn diện con người và sự nghiệp | | ⚠ Coaching | ⚠ nâng hiệu suất một kỹ năng cụ thể, có mục tiêu và thời hạn | | ⚠ Training | ⚠ truyền đạt kiến thức và kỹ năng theo chương trình | | ⚠ Mẹo nhớ | ⚠ mentoring lo NGƯỜI, coaching lo KỸ NĂNG, training lo KIẾN THỨC |
Từ khoá nhận diện:
"tư vấn, định hướng sự nghiệp, quan hệ dài hạn" → ⚠ mentoring "nâng hiệu suất một kỹ năng, có mục tiêu cụ thể" → ⚠ coaching "chương trình đào tạo có giáo trình" → ⚠ training "người học làm, chuyên gia đứng kèm" → ⚠ reverse shadowing
| ⚠ Một quan hệ cố vấn tốt gồm gì | Yếu tố |
|---|---|
| ⚠ TỰ NGUYỆN từ cả hai phía | ⚠ ép buộc thì không thành |
| ⚠ TIN CẬY và bảo mật | ⚠ người được cố vấn phải dám nói thật |
| ⚠ Gặp gỡ ĐỀU ĐẶN, không phải ngẫu hứng | |
| ⚠ Người cố vấn LẮNG NGHE nhiều hơn NÓI | |
| ⚠ Không đánh giá hiệu suất | ⚠ cố vấn KHÔNG nên là cấp trên trực tiếp |
| ⚠ Có mục tiêu phát triển rõ ràng nhưng linh hoạt | |
| ⚠ Sai lầm phổ biến | ⚠ biến buổi cố vấn thành buổi giao việc hoặc buổi giảng đạo |
| ⚠ Điều bạn cần điều chỉnh khi chuyển từ coaching sang mentoring | Điều chỉnh |
|---|---|
| ⚠ HỎI nhiều hơn CHỈ DẪN | |
| ⚠ Chia sẻ cả THẤT BẠI của mình, không chỉ thành công | |
| ⚠ Nhìn xa hơn dự án hiện tại | ⚠ con đường sự nghiệp của người đó |
| ⚠ Chấp nhận rằng họ có thể chọn con đường khác bạn | |
| ⚠ Kiên nhẫn — kết quả tính bằng năm, không bằng tuần |
| ⚠ Vì sao mentoring quan trọng với nghề quản lý dự án | Lý do |
|---|---|
| ⚠ Phần lớn năng lực PM là TRI THỨC ẨN | ⚠ kinh nghiệm xử lý tình huống, đọc con người, cảm nhận rủi ro |
| ⚠ Tri thức ẩn chỉ chuyển giao qua TƯƠNG TÁC người với người | ⚠ liên hệ câu #25630 ở lô 177 |
| ⚠ Sách và khoá học không dạy được cách xử lý một nhà tài trợ khó tính | |
| ⚠ Vì thế | ⚠ PMI khuyến khích mentoring như một hoạt động đóng góp cho nghề |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang lo kỹ năng hay lo con người | ⚠ quyết định là coaching hay mentoring | | Quan hệ có đủ tin cậy để nói thật không | | | Bạn có phải cấp trên trực tiếp của họ không | ⚠ nếu có thì khó làm cố vấn thật sự |
Và điểm khác biệt sâu nhất giữa hai vai trò: huấn luyện viên giúp bạn làm tốt hơn việc đang làm, người cố vấn giúp bạn quyết định nên làm việc gì.
- A To make a risk log that is visible on the wall in the team’s area.
- B To deliver a minimum viable product as quickly as possible.
- C To make sure the product is delivered with all features that competitors will include.
- D To complete a comprehensive risk analysis with all stakeholders.
Xem giải thích
Đáp án
B — Giao MỘT SẢN PHẨM KHẢ DỤNG TỐI THIỂU (MVP) càng nhanh càng tốt.
Vì sao đúng
⚠ Vì sao MVP là cách tiếp cận đúng khi cạnh tranh gay gắt: | Lý do | Nội dung | |---|---| | ⚠ Nhiều đối thủ cùng làm sản phẩm tương tự | ⚠ THỜI GIAN RA THỊ TRƯỜNG là yếu tố quyết định | | ⚠ MVP cho phép ra mắt SỚM với chức năng cốt lõi | | | ⚠ Học từ NGƯỜI DÙNG THẬT thay vì phỏng đoán | | | ⚠ Giành chỗ đứng trước khi đối thủ ra mắt | | | ⚠ Giảm rủi ro làm sai thứ thị trường cần | | | ⚠ Kết luận | ⚠ trong thị trường cạnh tranh, ra mắt sớm và học nhanh thắng ra mắt muộn và hoàn hảo |
Vì sao các phương án khác sai
-
C (đảm bảo sản phẩm có ĐỦ MỌI tính năng mà đối thủ có) — ⚠ SAI về chiến lược: ⚠ chạy theo tính năng của đối thủ làm ⚠ kéo dài thời gian ra mắt, ⚠ và sản phẩm chỉ là bản sao không có điểm khác biệt.
-
D (phân tích rủi ro toàn diện với mọi bên liên quan) — ⚠ tốn nhiều THỜI GIAN, ⚠ trong khi thời gian chính là thứ khan hiếm nhất; ⚠ phân tích rủi ro vẫn cần nhưng không phải "cách tiếp cận tốt nhất" ở đây.
-
A (làm sổ rủi ro dán tường) — ⚠ là một thực hành minh bạch tốt, ⚠ nhưng không phải chiến lược sản phẩm.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25781 ở lô 180 về vòng đời tăng dần và câu #25772 về phần mềm chạy được là thước đo tiến độ. ⚠ Ba câu cùng tinh thần: giao sớm, giao thật, học nhanh.
⚠ MVP — Minimum Viable Product: | Đặc điểm | Nội dung | |---|---| | ⚠ MINIMUM — tối thiểu về số tính năng | | | ⚠ VIABLE — nhưng PHẢI dùng được thật | ⚠ không phải bản nháp hay bản demo | | ⚠ Mục đích chính: HỌC, không phải bán | ⚠ kiểm chứng giả định về thị trường | | ⚠ Rút ngắn vòng lặp xây – đo – học | ⚠ build-measure-learn | | ⚠ Sai lầm phổ biến | ⚠ hiểu MVP là "sản phẩm kém chất lượng" — không phải; nó ÍT tính năng nhưng những tính năng có phải chạy TỐT |
Từ khoá nhận diện:
"cạnh tranh gay gắt, cần ra mắt nhanh" → ⚠ MVP "đủ mọi tính năng như đối thủ" → ⚠ chiến lược sai, kéo dài thời gian "phân tích toàn diện trước khi làm" → ⚠ tốn thời gian, hợp với dự án dự đoán hơn "học từ người dùng thật" → ⚠ tinh thần của MVP
| ⚠ Các khái niệm liên quan | Khái niệm |
|---|---|
| ⚠ MVP — Minimum Viable Product | ⚠ ít tính năng nhất mà vẫn dùng được và học được |
| ⚠ MBI — Minimum Business Increment | ⚠ phần nhỏ nhất mang lại GIÁ TRỊ KINH DOANH đo được |
| ⚠ MMF — Minimum Marketable Feature | ⚠ tính năng nhỏ nhất bán được |
| ⚠ Time to market | ⚠ thời gian từ khi bắt đầu tới khi ra thị trường — yếu tố quyết định ở đây |
| ⚠ Lợi thế cạnh tranh của việc ra mắt sớm | Lợi thế |
|---|---|
| ⚠ Chiếm được nhóm người dùng đầu tiên | |
| ⚠ Có PHẢN HỒI THẬT trước đối thủ | |
| ⚠ Có doanh thu sớm để tài trợ cho phát triển tiếp | |
| ⚠ Xây dựng nhận diện thương hiệu trước | |
| ⚠ Rủi ro cần cân nhắc | ⚠ ra mắt với sản phẩm quá thiếu có thể làm mất uy tín — nên chữ VIABLE rất quan trọng |
| ⚠ Joshua nên xác định MVP thế nào | Cách |
|---|---|
| ⚠ Xác định VẤN ĐỀ CỐT LÕI người dùng cần giải quyết | |
| ⚠ Chỉ giữ tính năng phục vụ vấn đề đó | |
| ⚠ Dùng MoSCoW để phân loại | ⚠ chỉ nhóm MUST vào MVP — xem câu #25762 |
| ⚠ Định trước cách ĐO thành công | ⚠ học được gì từ lần ra mắt này |
| ⚠ Lên kế hoạch các đợt bổ sung tiếp theo | ⚠ release plan |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | MVP của bạn có thật sự DÙNG ĐƯỢC không | ⚠ không phải bản demo | | Bạn định học được điều gì từ lần ra mắt này | | | Có tính năng nào trong MVP không phục vụ vấn đề cốt lõi không | |
Và điểm cần khắc trong thị trường cạnh tranh: sản phẩm hoàn hảo ra sau đối thủ sáu tháng thường thua sản phẩm đủ dùng ra trước. MVP không phải làm ẩu — nó là chọn đúng thứ để làm trước.
- A Sprint vision statement
- B Burndown chart
- C Sprint backlog
- D Sprint plan
Xem giải thích
Đáp án
A — Sprint vision statement. ⚠ Đây KHÔNG phải hiện vật chuẩn của Scrum.
Vì sao đúng
⚠ Scrum có gì và không có gì: | Có | Không có | |---|---| | ⚠ Product Goal | ⚠ "Sprint vision statement" | | ⚠ SPRINT GOAL | ⚠ đây mới là thứ định hướng cho sprint | | ⚠ Product Backlog | | | ⚠ Sprint Backlog | | | ⚠ Increment | | | ⚠ Definition of Done | | | ⚠ Kết luận | ⚠ Scrum dùng SPRINT GOAL, không dùng "sprint vision statement" — đây là tên bịa |
Vì sao các phương án khác sai
⚠ Cả ba phương án còn lại đều là thứ có thật và có mẫu dùng được:
-
C (Sprint backlog) — ⚠ là một trong BA hiện vật chính thức của Scrum.
-
D (Sprint plan) — ⚠ kết quả của buổi Sprint Planning, ⚠ hoàn toàn có thể có mẫu chuẩn.
-
B (Burndown chart) — ⚠ công cụ theo dõi phổ biến, ⚠ có mẫu dùng chung được.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25773 ở lô 180 về công cụ quản lý artifact cho nhiều đội Scrum và câu #25790 ở lô này về Definition of Done. ⚠ Ba câu cùng chủ đề hiện vật Scrum.
⚠ Ba hiện vật và ba cam kết của Scrum: | Hiện vật | Cam kết đi kèm | |---|---| | ⚠ Product Backlog | ⚠ PRODUCT GOAL — mục tiêu dài hạn của sản phẩm | | ⚠ Sprint Backlog | ⚠ SPRINT GOAL — mục tiêu duy nhất của sprint này | | ⚠ Increment | ⚠ DEFINITION OF DONE — chuẩn để coi là xong | | ⚠ Mỗi hiện vật | ⚠ có đúng MỘT cam kết, giúp nó minh bạch và đo được |
⚠ Sprint Goal — thứ mà đề nhầm thành "sprint vision": | Đặc điểm | Nội dung | |---|---| | ⚠ MỘT mục tiêu DUY NHẤT cho cả sprint | | | ⚠ Được thống nhất trong buổi Sprint Planning | | | ⚠ Tạo sự gắn kết cho các hạng mục trong sprint | | | ⚠ Cho đội sự linh hoạt về CÁCH đạt mục tiêu | ⚠ nếu phát hiện cách tốt hơn thì đổi được, miễn vẫn đạt Sprint Goal | | ⚠ Không đổi giữa sprint | ⚠ phạm vi có thể thương lượng, nhưng mục tiêu thì giữ |
Từ khoá nhận diện:
"sprint goal" → ⚠ CÓ THẬT, là cam kết của sprint backlog "sprint vision statement" → ⚠ KHÔNG có trong Scrum — tên bịa "product goal" → ⚠ CÓ THẬT, cam kết của product backlog "definition of done" → ⚠ CÓ THẬT, cam kết của increment
| ⚠ Vì sao câu này đáng chú ý | Lý do |
|---|---|
| ⚠ Ba phương án sai đều là thứ CÓ THẬT | ⚠ nên phải nhận ra cái BỊA mới trả lời được |
| ⚠ "Vision" nghe rất hợp lý | ⚠ có product vision, có project vision — nhưng KHÔNG có sprint vision |
| ⚠ Mẹo làm bài | ⚠ thuộc danh sách CHÍNH THỨC ba hiện vật và ba cam kết là loại được ngay |
| ⚠ Vai trò của Tracy trong đề | Vai trò |
|---|---|
| ⚠ "Giữ động lực cho đội và gỡ trở ngại" | ⚠ đây là mô tả của SCRUM MASTER |
| ⚠ Không giao việc, không sở hữu backlog | |
| ⚠ Liên hệ | ⚠ xem câu #25729, #25747, #25794 về vai trò Scrum Master |
| ⚠ Lưu ý về ngân hàng mẫu của PMO | Lưu ý |
|---|---|
| ⚠ Mẫu chuẩn giúp NHẤT QUÁN giữa nhiều đội | ⚠ liên hệ câu #25773 |
| ⚠ Nhưng mẫu không được làm mất tính linh hoạt của đội | |
| ⚠ Scrum cố ý để NHẸ về mặt hiện vật | ⚠ chỉ ba hiện vật bắt buộc |
| ⚠ Cân bằng | ⚠ PMO cấp mẫu để dùng, không ép dùng mọi mẫu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có Sprint Goal rõ ràng cho mỗi sprint không | ⚠ nhiều đội bỏ qua và chỉ có danh sách việc | | Ba hiện vật có minh bạch với mọi người không | | | Ngân hàng mẫu có đang tạo thêm thủ tục thừa không | |
Và điều Sprint Goal mang lại mà một danh sách công việc không có: nó cho đội một lý do để làm việc cùng nhau. Thiếu nó thì sprint chỉ là một túi việc rời rạc tình cờ được làm cùng lúc.
- A Social
- B Esteem
- C Physiological
- D Self-actualization
Xem giải thích
Đáp án
A — Social (nhu cầu xã hội).
Vì sao đúng
⚠ Bóc tách tình huống: | Chi tiết | Suy ra | |---|---| | ⚠ Chuyển sang làm việc từ xa hoàn toàn | ⚠ mất tương tác trực tiếp hằng ngày | | ⚠ Verdora KHÓ THÍCH NGHI với làm việc ảo | | | ⚠ Cô ấy NẢN LÒNG | | | ⚠ Muốn chuyển sang đội GẶP MẶT trực tiếp | ⚠ rõ ràng đang thiếu sự kết nối con người | | ⚠ Kết luận | ⚠ đây là nhu cầu bậc 3 của Maslow — thuộc về một nhóm, có quan hệ, được kết nối |
Vì sao các phương án khác sai
-
B (Esteem — được tôn trọng) — ⚠ là bậc 4: ⚠ nhu cầu được công nhận, có địa vị, tự trọng; ⚠ đề không nói Verdora cảm thấy bị coi thường.
-
C (Physiological — sinh lý) — ⚠ là bậc 1: ⚠ ăn, uống, ngủ; ⚠ hoàn toàn không liên quan.
-
D (Self-actualization — tự thể hiện) — ⚠ là bậc 5: ⚠ phát huy hết tiềm năng; ⚠ đề không nói về việc phát triển bản thân.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25706 ở lô 179 ("affiliation" KHÔNG thuộc Maslow mà thuộc McClelland) và câu #25659 ở lô 178 về Herzberg. ⚠ Ba câu là bộ đầy đủ về các thuyết động lực — và câu này là lần đầu áp dụng Maslow vào tình huống thay vì hỏi lý thuyết.
⚠ Năm bậc Maslow — từ dưới lên: | Bậc | Tên | Nội dung | Trong bối cảnh công việc | |---|---|---|---| | ⚠ 1 | ⚠ Physiological | ⚠ ăn, uống, ngủ, không khí | ⚠ lương đủ sống, điều kiện làm việc cơ bản | | ⚠ 2 | ⚠ Safety | ⚠ an toàn, ổn định | ⚠ hợp đồng ổn định, môi trường an toàn | | ⚠ 3 | ⚠ SOCIAL / Belonging | ⚠ thuộc về nhóm, quan hệ, tình bạn | ⚠ thuộc về một ĐỘI — CÂU NÀY | | ⚠ 4 | ⚠ Esteem | ⚠ được công nhận, có địa vị | ⚠ được ghi nhận thành quả, có tiếng nói | | ⚠ 5 | ⚠ Self-actualization | ⚠ phát huy hết tiềm năng | ⚠ việc thử thách, cơ hội học hỏi |
Từ khoá nhận diện:
"cô đơn, thiếu kết nối, muốn gặp mặt đồng nghiệp" → ⚠ nhu cầu XÃ HỘI, bậc 3 "không được ghi nhận, không có tiếng nói" → ⚠ esteem, bậc 4 "lo mất việc, hợp đồng sắp hết" → ⚠ safety, bậc 2 "muốn việc thử thách hơn" → ⚠ self-actualization, bậc 5 "affiliation" → ⚠ McClelland, KHÔNG phải Maslow
| ⚠ Bạn nên gợi ý gì cho Verdora | Gợi ý |
|---|---|
| ⚠ Tăng tần suất họp có CAMERA | ⚠ thấy mặt nhau tạo cảm giác kết nối |
| ⚠ Tạo thời gian trò chuyện PHI CÔNG VIỆC | ⚠ vài phút đầu mỗi buổi họp, hoặc buổi cà phê ảo |
| ⚠ Ghép cặp làm việc thay vì ai làm việc nấy | |
| ⚠ Tổ chức gặp mặt trực tiếp ĐỊNH KỲ | ⚠ hằng quý hoặc theo mốc dự án |
| ⚠ Kênh trò chuyện phi chính thức cho đội | |
| ⚠ Trước khi cô ấy chuyển đội | ⚠ thử các cách trên đã — vấn đề có thể giải quyết mà không mất người |
| ⚠ Vì sao làm việc từ xa dễ đụng bậc 3 nhất | Lý do |
|---|---|
| ⚠ Mất hoàn toàn tương tác tự phát | ⚠ những cuộc trò chuyện ngoài hành lang |
| ⚠ Mọi giao tiếp đều có mục đích công việc | ⚠ không còn chuyện phiếm |
| ⚠ Không có ngôn ngữ cơ thể và không khí chung | |
| ⚠ Ranh giới công việc và cuộc sống mờ đi | |
| ⚠ Bậc 1 và 2 thường vẫn ổn | ⚠ lương vẫn trả, việc vẫn có — nên vấn đề nằm đúng ở bậc 3 |
| ⚠ Liên hệ với các thuyết khác | Liên hệ |
|---|---|
| ⚠ Herzberg | ⚠ quan hệ đồng nghiệp là yếu tố DUY TRÌ — thiếu thì bất mãn |
| ⚠ McClelland | ⚠ người thiên về AFFILIATION sẽ khổ nhất khi làm việc từ xa |
| ⚠ Tuckman | ⚠ đội phân tán mất nhiều thời gian hơn để qua Forming và Storming |
| ⚠ Bài học chung | ⚠ làm việc từ xa tiết kiệm chi phí nhưng phải ĐẦU TƯ có chủ đích vào kết nối con người |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có thời gian tương tác phi công việc không | | | Có ai đang cảm thấy cô lập mà chưa nói ra không | | | Có kế hoạch gặp mặt trực tiếp định kỳ không | |
Và điều mà nhiều tổ chức bỏ qua khi chuyển sang làm việc từ xa: họ chuyển được công việc nhưng không chuyển được QUAN HỆ. Nhu cầu thuộc về một nhóm không biến mất chỉ vì văn phòng biến mất.
- A Kaizen
- B Just-in-time manufacturing
- C Total productive maintenance
- D Human resource coordination
Xem giải thích
Đáp án
B — Just-in-time manufacturing (sản xuất đúng lúc).
Vì sao đúng
⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Vật tư được giao CHỈ KHI CẦN dùng | ⚠ đúng định nghĩa JIT | | ⚠ Lý do: HẠN CHẾ MẶT BẰNG tại công trường | ⚠ không có chỗ chứa hàng tồn | | ⚠ Kết luận | ⚠ giảm tồn kho xuống mức tối thiểu — nguyên tắc cốt lõi của JIT |
⚠ Just-in-time: | Đặc điểm | Nội dung | |---|---| | ⚠ Xuất phát từ Hệ thống sản xuất Toyota | | | ⚠ Vật tư đến ĐÚNG LÚC cần, không sớm không muộn | | | ⚠ Tồn kho gần bằng KHÔNG | | | ⚠ ƯU: giảm chi phí lưu kho, giảm hư hỏng, giảm vốn đọng, tiết kiệm mặt bằng | | | ⚠ NHƯỢC: RẤT nhạy cảm với gián đoạn chuỗi cung ứng | ⚠ một chuyến hàng trễ là công trường dừng | | ⚠ Điều kiện | ⚠ nhà cung cấp đáng tin và phối hợp chặt chẽ |
Vì sao các phương án khác sai
-
A (Kaizen) — ⚠ là triết lý CẢI TIẾN LIÊN TỤC bằng những thay đổi nhỏ; ⚠ cũng thuộc hệ thống Toyota nhưng nói về cải tiến, không nói về tồn kho.
-
C (Total productive maintenance — TPM) — ⚠ là phương pháp BẢO TRÌ TOÀN DIỆN thiết bị, ⚠ nhằm giảm thời gian dừng máy; ⚠ không liên quan tới giao vật tư.
-
D (Human resource coordination) — ⚠ không phải thuật ngữ chuẩn, ⚠ và đề nói về VẬT TƯ chứ không về nhân sự.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25623 ở lô 177 ⚠ (Gary và trưởng nhóm tranh cãi về việc chờ đủ vật tư). ⚠ Hai câu ⚠ cùng khoá về JIT ⚠ nhưng ⚠ tiếp cận ngược nhau: | Câu | Bối cảnh | Vai trò của JIT | |---|---|---| | ⚠ #25623 (lô 177) | ⚠ trưởng nhóm CHỜ đủ vật tư mới bắt đầu; Gary muốn bắt đầu và nhận vật tư dần | ⚠ JIT là cách nghĩ ĐÚNG của Gary — đáp án B | | ⚠ #25802 (câu này) | ⚠ giám đốc sản xuất yêu cầu giao vật tư đúng lúc cần vì thiếu mặt bằng | ⚠ JIT là cách tiếp cận được mô tả — đáp án B | ⚠ Trùng hợp là cả hai đều là đáp án B. ⚠ Hai khoá KHÔNG mâu thuẫn. ⚠ Và lưu ý câu #25741 ở lô 180 lại nói về việc ⚠ CHỜ đủ vật tư mới bắt đầu (Finish-to-Start) — ⚠ ba câu cho thấy cùng một chủ đề vật tư có thể dẫn tới ba đáp án khác nhau tuỳ trọng tâm câu hỏi.
Từ khoá nhận diện:
"vật tư đến đúng lúc dùng, không tồn kho" → ⚠ JIT "cải tiến nhỏ liên tục" → ⚠ Kaizen "bảo trì thiết bị toàn diện" → ⚠ TPM "hạn chế mặt bằng chứa hàng" → ⚠ lý do điển hình để dùng JIT
⚠ Các khái niệm Lean hay ra thi: | Khái niệm | Nội dung | |---|---| | ⚠ Just-in-Time (JIT) | ⚠ giao đúng lúc, tồn kho tối thiểu | | ⚠ Kaizen | ⚠ cải tiến liên tục bằng thay đổi nhỏ | | ⚠ Kanban | ⚠ hệ thống kéo, trực quan hoá luồng công việc, giới hạn WIP | | ⚠ Muda | ⚠ lãng phí — bảy loại, xem câu #25786 | | ⚠ Poka-yoke | ⚠ chống sai sót — thiết kế để không thể làm sai | | ⚠ Gemba | ⚠ tới tận nơi làm việc để quan sát thực tế | | ⚠ TPM | ⚠ bảo trì toàn diện thiết bị |
| ⚠ Rủi ro của JIT cần quản lý | Rủi ro |
|---|---|
| ⚠ Nhà cung cấp giao trễ là công trường DỪNG | |
| ⚠ Không có đệm để hấp thụ biến động | |
| ⚠ Phụ thuộc nặng vào chất lượng chuỗi cung ứng | |
| ⚠ Chi phí vận chuyển tăng vì nhiều chuyến nhỏ | |
| ⚠ Cách giảm | ⚠ hợp đồng có điều khoản phạt, nhà cung cấp dự phòng, theo dõi sát lịch giao, và ghi rủi ro này vào risk register |
| ⚠ Bối cảnh đề: nhiều bên liên quan phối hợp | Bên liên quan |
|---|---|
| ⚠ Giám đốc sản xuất | ⚠ yêu cầu JIT vì hạn chế mặt bằng |
| ⚠ Nhân sự, phòng CNTT, giám đốc CNTT | ⚠ các bên khác cần phối hợp |
| ⚠ Ý nghĩa | ⚠ JIT đòi PHỐI HỢP CHẶT giữa nhiều bên — không chỉ là quyết định của một người |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuỗi cung ứng có đủ tin cậy cho JIT không | | | Có phương án dự phòng khi hàng trễ không | | | Rủi ro gián đoạn đã vào sổ rủi ro chưa | |
Và đánh đổi cốt lõi của JIT: tiết kiệm mặt bằng và vốn đọng, đổi lấy sự phụ thuộc vào chuỗi cung ứng. Chấp nhận đánh đổi đó thì phải quản lý rủi ro giao hàng chặt hơn nhiều so với bình thường.