Ngân hàng đề — PMP® Mock Exam Set II Exam
Tìm thấy 718 câu.
- A Critical chain
- B Crashing
- C Fast-tracking
- D Critical Path
Xem giải thích
Đáp án
B — RÚT NGẮN (crashing).
Vì sao đúng
⚠ Nhận diện từ hành động của Donald: | Hành động | Ý nghĩa | |---|---| | ⚠ THÊM NGUỒN LỰC vào đội | ⚠ dấu hiệu số một của rút ngắn | | ⚠ Duyệt làm thêm giờ KHÔNG GIỚI HẠN | ⚠ thêm giờ cũng là thêm nguồn lực | | ⚠ Chấp nhận TỐN THÊM TIỀN | ⚠ đề nói rõ "cần thêm kinh phí" | | ⚠ Chấp nhận nhiều xung đột hơn và tốn thời gian quản lý | ⚠ các tác dụng phụ điển hình của rút ngắn | | ⚠ Kết luận | ⚠ đánh đổi TIỀN lấy THỜI GIAN — định nghĩa chính xác của rút ngắn |
⚠ Đây là cặp đối chiếu trực tiếp với #27090 cùng lô: ⚠ Karwan đổi trình tự công việc mà không thêm gì (chạy song song), còn Donald thêm người và thêm giờ (rút ngắn) ⚠ — ⚠ hai câu nằm cùng một lô và nên được đọc liền nhau.
Vì sao các phương án khác sai
-
C (chạy song song — fast-tracking) — ⚠ phương án gây nhiễu mạnh nhất, vì đây là cặp khái niệm luôn đi đôi vì ⚠ cả hai đều là kỹ thuật nén tiến độ và đều được dùng khi bị ép rút ngắn thời gian: ⚠ nhưng ⚠ chạy song song KHÔNG thêm nguồn lực — nó chỉ sắp xếp lại để các việc chồng lấn nhau ⚠; ⚠ Donald không đụng gì tới trình tự công việc, anh ấy đổ thêm người và thêm giờ vào; ⚠ và chi tiết "cần thêm kinh phí" trong đề là dấu hiệu dứt khoát: chạy song song thường không làm tăng chi phí trực tiếp; ⚠ mẹo nhớ: crashing = thêm TIỀN, fast tracking = thêm RỦI RO.
-
A (chuỗi găng — critical chain) — ⚠ là một phương pháp lập tiến độ dựa trên ràng buộc nguồn lực và các đệm thời gian; ⚠ không phải kỹ thuật nén tiến độ.
-
D (đường găng — critical path) — ⚠ là chuỗi công việc dài nhất quyết định thời gian dự án; ⚠ nó là một khái niệm phân tích, không phải một hành động.
Ghi nhớ
⚠ Đối chiếu: ⚠ #27090 cùng lô (Karwan đổi trình tự — CHẠY SONG SONG, cặp đối chiếu trực tiếp), ⚠ #27018 lô 205 (Celia thêm người — cũng là rút ngắn), ⚠ #26924 lô 203 (thêm người giữa chừng và định luật Brooks), ⚠ #26939 lô 204 (các cách hấp thụ độ trễ).
⚠ Tác dụng phụ của rút ngắn mà chính đề đã liệt kê: | Tác dụng phụ | Nội dung | |---|---| | ⚠ Nhiều xung đột hơn | ⚠ đông người thì va chạm nhiều hơn | | ⚠ Tốn thêm thời gian quản lý | ⚠ số kênh giao tiếp tăng theo n(n−1)/2 | | ⚠ Cần thêm kinh phí | ⚠ lương, làm thêm giờ, thiết bị | | ⚠ Người mới cần thời gian hoà nhập | ⚠ định luật Brooks — liên hệ #26924 lô 203 | | ⚠ Làm thêm giờ kéo dài làm giảm chất lượng | ⚠ và tăng nguy cơ kiệt sức | | ⚠ Điều đáng lo nhất trong tình huống này | ⚠ cụm "làm thêm giờ KHÔNG GIỚI HẠN" — làm thêm giờ vài tuần thì tăng sản lượng, nhưng kéo dài thì năng suất mỗi giờ giảm và tỷ lệ lỗi tăng, tới mức tổng sản lượng có thể thấp hơn cả khi làm giờ bình thường |
⚠ Chỉ rút ngắn được các việc trên ĐƯỜNG GĂNG: | Nguyên tắc | Nội dung | |---|---| | ⚠ Rút ngắn việc KHÔNG nằm trên đường găng là vô ích | ⚠ tốn tiền mà dự án không nhanh hơn | | ⚠ Chọn việc có chi phí rút ngắn THẤP NHẤT trước | ⚠ hiệu quả nhất trên mỗi đồng bỏ ra | | ⚠ Sau mỗi lần rút ngắn phải tính lại đường găng | ⚠ đường găng có thể ĐỔI | | ⚠ Sai lầm hay gặp | ⚠ đổ thêm người vào những chỗ dễ thêm người nhất thay vì những chỗ đang quyết định ngày kết thúc — kết quả là chi phí tăng mà tiến độ không đổi chút nào |
⚠ Chữ "bằng mọi giá" trong đề là một cảnh báo: | Vấn đề | Nội dung | |---|---| | ⚠ Nó loại bỏ việc cân nhắc đánh đổi | | | ⚠ Dễ dẫn tới hy sinh chất lượng | ⚠ liên hệ #27024 lô 205 | | ⚠ Có thể tạo ra chi phí lớn hơn giá trị thu được | | | ⚠ Điều Donald nên làm dù bị ép | ⚠ vẫn phải tính và trình bày CÁI GIÁ của việc rút sáu tuần — vì "bằng mọi giá" là một mệnh lệnh cảm tính, và nhiệm vụ của người quản lý dự án là biến nó thành một con số để lãnh đạo biết mình đang mua gì |
Từ khoá nhận diện:
"thêm người và duyệt làm thêm giờ" → ⚠ RÚT NGẮN (crashing), thêm TIỀN "đổi trình tự cho chạy song song" → ⚠ CHẠY SONG SONG — xem #27090 cùng lô "chuỗi găng" → ⚠ phương pháp lập tiến độ, không phải kỹ thuật nén "đường găng" → ⚠ khái niệm phân tích, không phải hành động
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đang rút ngắn đúng các việc trên đường găng không | | | Bạn có tính lại đường găng sau mỗi lần rút ngắn không | | | Đội bạn đã làm thêm giờ liên tục bao nhiêu tuần rồi | |
Và điều mà "bằng mọi giá" luôn che giấu cho tới khi hoá đơn tới: rằng luôn có một cái giá, và việc không tính nó ra không làm nó biến mất.
- A Hire a translator to attend the virtual meetings and clarify specific topics of discussion.
- B Ask team members who are collocated to attend virtual meetings together.
- C Request for different team members who speak English fluently.
- D Use a different communication technology tool.
Xem giải thích
Đáp án
B — ĐỀ NGHỊ CÁC THÀNH VIÊN CÙNG ĐỊA ĐIỂM DỰ HỌP TRỰC TUYẾN CÙNG NHAU.
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ⚠ — ⚠ dừng ở "…other team members in those areas do speak English fluently based o", tức là "based on…"; ⚠ ý đã rõ: ở mỗi khu vực đều có người thạo tiếng Anh và người không.
Vì sao đúng
⚠ Vì sao giải pháp này khớp với dữ kiện: | Dữ kiện trong đề | Cách giải pháp tận dụng | |---|---| | ⚠ Nhiều thành viên ở CÙNG khu vực địa lý | ⚠ họ ngồi gần nhau được | | ⚠ Họ NÓI CÙNG NGÔN NGỮ với nhau | ⚠ có thể giải thích cho nhau | | ⚠ Một số người thạo tiếng Anh, một số không | ⚠ người thạo giúp người chưa thạo | | ⚠ Không tốn thêm chi phí | ⚠ chỉ cần sắp xếp lại cách dự họp | | ⚠ Kết luận | ⚠ tận dụng chính nguồn lực đã có trong đội thay vì thêm người hay đổi công cụ |
⚠ Ngân sách của dự án cũng là một ràng buộc: ⚠ 469.000 đô và chi phí không được vượt quá 3% đường cơ sở ⚠ — ⚠ nên các phương án tốn tiền như thuê phiên dịch càng khó chấp nhận.
Vì sao các phương án khác sai
-
A (thuê phiên dịch dự các buổi họp trực tuyến) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nhắm thẳng vào rào cản ngôn ngữ và là giải pháp chuyên nghiệp, được dùng thật trong nhiều dự án quốc tế: ⚠ nhưng ⚠ nó tốn kém trong khi dự án bị ràng buộc chi phí chỉ được vượt 3% ⚠; ⚠ và nó bỏ qua một nguồn lực MIỄN PHÍ đã có sẵn: chính các đồng nghiệp cùng khu vực nói được cả hai thứ tiếng; ⚠ thêm nữa, phiên dịch chỉ giúp trong lúc họp, còn đồng nghiệp cùng phòng thì giúp được cả sau buổi họp khi có thắc mắc phát sinh; ⚠ nguyên tắc: thử giải pháp không tốn tiền trước, đặc biệt khi có ràng buộc ngân sách rõ ràng.
-
C (yêu cầu đổi sang người khác thạo tiếng Anh) — ⚠ loại bỏ những người có chuyên môn vì rào cản ngôn ngữ; ⚠ vừa lãng phí vừa gây tổn thương, và đội đã đi được một chặng đường.
-
D (dùng công cụ trao đổi khác) — ⚠ vấn đề nằm ở NGÔN NGỮ, không nằm ở công nghệ; ⚠ đổi công cụ không làm ai hiểu tiếng Anh tốt hơn.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26900 lô 203 (khi nào đội ảo là cần thiết), ⚠ #27057 lô 206 (giữ gắn kết cho đội từ xa), ⚠ #26921 lô 203 (băng thông các kênh giao tiếp), ⚠ #27008 lô 205 (nhiễu trong truyền thông, gồm nhiễu ngữ nghĩa).
⚠ Rào cản ngôn ngữ trong đội đa quốc gia: | Biểu hiện | Nội dung | |---|---| | ⚠ Người ta GẬT ĐẦU dù chưa hiểu | ⚠ ngại thừa nhận, sợ mất mặt | | ⚠ Không đặt câu hỏi làm rõ | | | ⚠ Hiểu được từ nhưng không hiểu ngụ ý | ⚠ thành ngữ, cách nói giảm nhẹ | | ⚠ Công việc làm sai mà không ai biết vì sao | ⚠ đúng tình huống Krista đang gặp | | ⚠ Dấu hiệu Krista đã bỏ lỡ | ⚠ cô ấy TƯỞNG mọi người thạo tiếng Anh — và sự tưởng đó tồn tại được vì không ai nói ra rằng mình không hiểu; đó là lý do vấn đề chỉ lộ ra qua công việc không hoàn thành |
⚠ Các biện pháp khác không tốn tiền: | Biện pháp | Nội dung | |---|---| | ⚠ Gửi chương trình họp và tài liệu TRƯỚC | ⚠ đọc trước dễ hơn nghe trực tiếp | | ⚠ Nói chậm, tránh thành ngữ và tiếng lóng | | | ⚠ Gửi biên bản tóm tắt sau họp bằng văn bản | ⚠ văn bản dễ hiểu hơn lời nói với người học ngoại ngữ | | ⚠ Yêu cầu nhắc lại nhiệm vụ bằng lời của họ | ⚠ kiểm tra hiểu đúng — liên hệ #27017 lô 205 | | ⚠ Dùng hình vẽ và bảng biểu nhiều hơn | | | ⚠ Biện pháp hiệu quả nhất | ⚠ yêu cầu người nhận việc NHẮC LẠI bằng lời của họ — nó phát hiện hiểu nhầm ngay tại chỗ và không làm ai xấu hổ, vì đó là quy trình áp dụng cho tất cả mọi người |
⚠ Vì sao Krista không nên đổi người: | Lý do | Nội dung | |---|---| | ⚠ Họ có chuyên môn cần cho dự án | | | ⚠ Họ hiểu bối cảnh địa phương | | | ⚠ Thay người giữa dự án tốn thời gian hoà nhập | ⚠ liên hệ #26938 lô 204 về đường cong học tập | | ⚠ Tổn hại tinh thần cho cả đội | | | ⚠ Nhận xét | ⚠ rào cản ngôn ngữ là vấn đề của HỆ THỐNG giao tiếp chứ không phải khuyết điểm của cá nhân — và cách một người quản lý phản ứng với nó sẽ được cả đội đa quốc gia quan sát rất kỹ |
Từ khoá nhận diện:
"cùng khu vực, cùng ngôn ngữ, một số thạo tiếng Anh" → ⚠ DỰ HỌP CÙNG NHAU "thuê phiên dịch" → ⚠ tốn kém, bỏ qua nguồn lực miễn phí sẵn có "đổi sang người thạo tiếng Anh" → ⚠ loại bỏ chuyên môn vì rào cản ngôn ngữ "đổi công cụ" → ⚠ vấn đề là ngôn ngữ, không phải công nghệ
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có chắc mọi người trong đội hiểu ngôn ngữ họp không | | | Bạn có yêu cầu người nhận việc nhắc lại nhiệm vụ không | | | Biên bản họp của bạn có được gửi bằng văn bản không | |
Và điều mà một cái gật đầu trong cuộc họp trực tuyến đa quốc gia không bao giờ bảo đảm: rằng người ta đã hiểu — và cách duy nhất để biết chắc là nghe họ nói lại bằng lời của chính mình.
- A Nothing, she does not need them to be involved if they trust her.
- B Practice SAFe and let them see it in action.
- C Send them an email on SAFe.
- D Bring in a SAFe trainer.
Xem giải thích
Đáp án
D — MỜI MỘT CHUYÊN GIA ĐÀO TẠO SAFe (bring in a SAFe trainer).
Vì sao đúng
⚠ Vì sao đào tạo chính quy là lựa chọn đúng ở đây: | Dữ kiện | Ý nghĩa | |---|---| | ⚠ SAFe là một khung PHỨC TẠP | ⚠ nhiều vai trò, nhiều tầng, nhiều nghi thức | | ⚠ Mất VÀI NĂM để dạy họ agile cơ bản | ⚠ bằng chứng rằng cách tự truyền đạt rất chậm | | ⚠ Lãnh đạo cần hiểu để RA QUYẾT ĐỊNH | ⚠ không chỉ để tin tưởng | | ⚠ Chuyên gia bên ngoài có uy tín riêng | ⚠ và có giáo trình đã được kiểm chứng | | ⚠ Kết luận | ⚠ một chủ đề lớn cần được dạy bài bản, không thể truyền đạt dần dần bằng thiện chí |
⚠ Tiếng nói từ bên ngoài có sức nặng riêng: ⚠ cùng một nội dung, nhưng một chuyên gia độc lập nói thường được lãnh đạo tiếp nhận khác với khi nhân viên nội bộ nói ⚠ — ⚠ đó không phải điều dễ chịu nhưng là thực tế của mọi tổ chức.
Vì sao các phương án khác sai
-
B (cứ thực hành SAFe và để họ thấy nó hoạt động) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "cho thấy kết quả thay vì thuyết trình" là một nguyên tắc rất đúng trong agile, và nó đã hiệu quả với Sabrina ở giai đoạn trước: ⚠ nhưng ⚠ SAFe đòi hỏi các quyết định ở CẤP TỔ CHỨC trước khi có thể triển khai: cơ cấu lại đội, lập tàu phát hành, phân bổ ngân sách theo dòng giá trị ⚠ — ⚠ không thể "âm thầm làm rồi cho xem" một thứ cần chính họ phê duyệt để bắt đầu; ⚠ và bài học lịch sử đã rõ: cách tự truyền đạt từng chút một đã mất vài năm cho phần cơ bản, lặp lại nó cho một khung phức tạp hơn nhiều là không hợp lý.
-
C (gửi email về SAFe) — ⚠ kênh băng thông thấp nhất cho chủ đề phức tạp nhất; ⚠ liên hệ #26921 lô 203.
-
A (không cần làm gì vì họ tin cô ấy) — ⚠ lòng tin không thay được sự hiểu biết; ⚠ và khi lãnh đạo phải quyết những việc họ không hiểu, họ sẽ trì hoãn hoặc quyết sai.
Ghi nhớ
⚠ Đối chiếu: ⚠ #27009 lô 205 (chọn hình thức đào tạo theo ràng buộc), ⚠ #26936 lô 204 (giải thích tầm quan trọng của đào tạo), ⚠ #26953 lô 204 (mối lo của lãnh đạo với cách làm lặp), ⚠ #26985 lô 205 (nêu rõ điểm khác biệt so với cách làm cũ).
⚠ Vì sao mở rộng agile ra nhiều đội là bài toán khác hẳn: | Vấn đề mới | Nội dung | |---|---| | ⚠ Phụ thuộc GIỮA các đội | ⚠ đội A chờ đội B | | ⚠ Đồng bộ nhịp làm việc | ⚠ các chặng phải khớp nhau | | ⚠ Ưu tiên ở cấp danh mục, không chỉ cấp đội | | | ⚠ Kiến trúc chung phải được thống nhất | | | ⚠ Ngân sách theo dòng giá trị thay vì theo dự án | ⚠ thay đổi lớn về tài chính | | ⚠ Vì sao lãnh đạo BẮT BUỘC phải hiểu | ⚠ ba vấn đề cuối đều đòi hỏi quyết định ở cấp tổ chức — nên đây không phải chuyện đội tự làm được rồi báo cáo kết quả |
⚠ Đào tạo lãnh đạo cấp cao khác đào tạo đội: | Yếu tố | Lãnh đạo cấp cao | Đội thực hiện | |---|---|---| | ⚠ Thời lượng chấp nhận được | ⚠ nửa ngày tới một ngày | ⚠ vài ngày | | ⚠ Nội dung cần | ⚠ VÌ SAO và họ phải quyết gì | ⚠ LÀM THẾ NÀO | | ⚠ Ngôn ngữ | ⚠ kết quả kinh doanh, dòng giá trị | ⚠ thực hành, công cụ | | ⚠ Sai lầm phổ biến | ⚠ dạy lãnh đạo cùng giáo trình như dạy đội — họ sẽ mất hứng ở nửa giờ đầu, và cơ hội đó thường không có lần thứ hai |
⚠ Sabrina nên chuẩn bị gì trước buổi đào tạo: | Việc | Nội dung | |---|---| | ⚠ Nêu rõ VẤN ĐỀ mà SAFe giải quyết | ⚠ thiếu phối hợp giữa nhiều đội | | ⚠ Chuẩn bị vài ví dụ từ chính tổ chức | ⚠ cụ thể hơn lý thuyết | | ⚠ Làm rõ các quyết định lãnh đạo sẽ phải đưa ra | | | ⚠ Chọn chuyên gia có kinh nghiệm với lãnh đạo | | | ⚠ Lợi thế lớn nhất của Sabrina | ⚠ lãnh đạo đã TIN cô ấy — nên việc cô ấy đề nghị mời chuyên gia sẽ được lắng nghe; lòng tin đó là vốn nên dùng để mở cánh cửa, chứ không phải để thay thế cho việc họ hiểu |
Từ khoá nhận diện:
"đưa lãnh đạo lên kịp về một khung phức tạp" → ⚠ MỜI CHUYÊN GIA ĐÀO TẠO "cứ làm rồi cho họ thấy" → ⚠ không được, vì cần họ quyết TRƯỚC khi bắt đầu "gửi email" → ⚠ băng thông thấp nhất cho chủ đề phức tạp nhất "họ tin mình rồi nên không cần" → ⚠ lòng tin không thay được sự hiểu biết
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lãnh đạo của bạn có hiểu đủ để quyết những gì bạn cần họ quyết không | | | Bạn đang truyền đạt dần dần hay đào tạo bài bản | | | Nội dung dành cho lãnh đạo có khác nội dung dành cho đội không | |
Và lý do một chuyên gia bên ngoài đôi khi cần thiết dù bạn biết nhiều hơn họ về tổ chức mình: không phải vì nội dung khác đi, mà vì tiếng nói từ bên ngoài đi qua được những cánh cửa mà tiếng nói từ bên trong đã gõ nhiều năm.
Henry is a stakeholder for Project L, which is in its tenth week of implementation, has a CPI of 1.1 and an SPI of 1.01. Recently Henry was reviewing project data and found this scatter diagram. What conclusion can he draw from it?
- A Nothing, the distribution is too random.
- B The higher the quality score, the more hours worked.
- C Some larger tasks should be broken down.
- D Only high-quality items were worked on for over 75 hours.
Xem giải thích
Đáp án
A — KHÔNG RÚT RA ĐƯỢC KẾT LUẬN GÌ, PHÂN BỐ QUÁ NGẪU NHIÊN.
Vì sao đúng
⚠ Biểu đồ phân tán dùng để làm gì: | Chức năng | Nội dung | |---|---| | ⚠ Kiểm tra có TƯƠNG QUAN giữa hai biến không | ⚠ đây là toàn bộ mục đích của nó | | ⚠ Các điểm tạo thành xu hướng ⇒ có tương quan | ⚠ đi lên, đi xuống, hoặc cong | | ⚠ Các điểm rải rác ngẫu nhiên ⇒ KHÔNG tương quan | ⚠ trường hợp của đề | | ⚠ Không tương quan là một KẾT LUẬN hợp lệ | ⚠ không phải một thất bại | | ⚠ Kết luận | ⚠ đọc đúng một biểu đồ không có xu hướng nghĩa là KHÔNG kết luận gì về quan hệ hai biến |
⚠ Bối cảnh còn củng cố thêm: ⚠ dự án có CPI 1,1 và SPI 1,01, tức là đang tốt về cả chi phí lẫn tiến độ ⚠ — ⚠ không có dấu hiệu nào cho thấy cần tìm một vấn đề trong dữ liệu.
Vì sao các phương án khác sai
-
B (điểm chất lượng càng cao thì số giờ làm càng nhiều) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là một kết luận nghe rất hợp lý về mặt trực giác: làm kỹ hơn thì mất nhiều giờ hơn, ai cũng thấy đúng: ⚠ nhưng ⚠ đề nói rõ phân bố quá ngẫu nhiên, tức là dữ liệu KHÔNG ỦNG HỘ kết luận đó ⚠; ⚠ đây là cái bẫy nguy hiểm nhất khi đọc dữ liệu: nhìn thấy thứ mình đã tin sẵn trong một đám điểm không có quy luật; ⚠ và ngay cả khi có tương quan thật, tương quan cũng không đồng nghĩa với NHÂN QUẢ — hai sai lầm chồng lên nhau trong cùng một phương án.
-
C (một số công việc lớn nên được chia nhỏ) — ⚠ kết luận về quy mô công việc; ⚠ biểu đồ phân tán về chất lượng và số giờ không nói gì về điều đó.
-
D (chỉ các hạng mục chất lượng cao mới được làm trên 75 giờ) — ⚠ kết luận cụ thể từ dữ liệu không có quy luật; ⚠ và nó tự mâu thuẫn với việc phân bố là ngẫu nhiên.
Ghi nhớ
⚠ Đối chiếu: ⚠ #27011 lô 205 (biểu đồ kiểm soát phân biệt biến thiên thường và bất thường), ⚠ #27024 lô 205 (các công cụ tìm nguyên nhân gốc), ⚠ #26895 lô 203 (phân tích xu hướng), ⚠ #27086 cùng lô (biểu đồ burndown rủi ro).
⚠ Bảy công cụ chất lượng cơ bản và mục đích: | Công cụ | Trả lời câu hỏi | |---|---| | ⚠ BIỂU ĐỒ PHÂN TÁN | ⚠ hai biến có liên quan không — câu này | | ⚠ Biểu đồ nhân quả (xương cá) | ⚠ nguyên nhân có thể có là gì | | ⚠ Biểu đồ Pareto | ⚠ loại vấn đề nào chiếm phần lớn | | ⚠ Biểu đồ kiểm soát | ⚠ quy trình có ổn định không | | ⚠ Biểu đồ tần suất (histogram) | ⚠ dữ liệu phân bố ra sao | | ⚠ Phiếu kiểm tra (check sheet) | ⚠ thu thập dữ liệu có cấu trúc | | ⚠ Lưu đồ (flowchart) | ⚠ quy trình diễn ra thế nào | | ⚠ Mẹo chọn công cụ | ⚠ xác định CÂU HỎI trước rồi mới chọn biểu đồ — chọn biểu đồ trước rồi tìm câu hỏi cho nó là cách nhanh nhất để rút ra kết luận sai |
⚠ Đọc biểu đồ phân tán: | Hình dạng | Ý nghĩa | |---|---| | ⚠ Các điểm đi lên từ trái sang phải | ⚠ tương quan DƯƠNG | | ⚠ Các điểm đi xuống | ⚠ tương quan ÂM | | ⚠ Các điểm bám sát một đường | ⚠ tương quan MẠNH | | ⚠ Các điểm rải rác không quy luật | ⚠ KHÔNG tương quan — đề bài | | ⚠ Cảnh báo bắt buộc | ⚠ tương quan KHÔNG phải nhân quả — hai biến cùng tăng có thể do một biến thứ ba tác động lên cả hai, và đó là sai lầm diễn giải phổ biến nhất trong mọi báo cáo dự án |
⚠ "Không có kết luận" cũng là một phát hiện có giá trị: | Ý nghĩa | Nội dung | |---|---| | ⚠ Loại bỏ một giả thuyết sai | ⚠ số giờ không quyết định chất lượng | | ⚠ Hướng sự tìm kiếm sang biến khác | ⚠ kinh nghiệm, độ phức tạp, công cụ | | ⚠ Ngăn một quyết định dựa trên tương quan giả | | | ⚠ Điều Henry nên làm tiếp | ⚠ nếu vẫn muốn hiểu điều gì ảnh hưởng tới chất lượng thì thử các biến khác, hoặc dùng biểu đồ Pareto để xem loại lỗi nào phổ biến nhất — nhưng tuyệt đối đừng ép một kết luận ra khỏi biểu đồ này |
Từ khoá nhận diện:
"phân bố quá ngẫu nhiên" → ⚠ KHÔNG kết luận được gì về tương quan "càng cao thì càng nhiều" → ⚠ áp một kết luận lên dữ liệu không ủng hộ nó "biểu đồ phân tán" → ⚠ kiểm tra TƯƠNG QUAN giữa hai biến "tương quan" → ⚠ không đồng nghĩa với NHÂN QUẢ
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết luận gần nhất bạn rút ra từ dữ liệu có được dữ liệu ủng hộ không | | | Bạn có chọn công cụ trước hay chọn câu hỏi trước | | | Bạn có nhầm tương quan với nhân quả bao giờ chưa | |
Và điều khó nhất khi đọc dữ liệu, khó hơn cả việc tìm ra quy luật: chấp nhận rằng lần này không có quy luật nào — nhất là khi bạn đã có sẵn một kết luận muốn nó đúng.
- A Agile projects have fixed time, but variable cost and scope.
- B Agile projects have fixed costs and time, but have a variable scope.
- C Agile projects have fixed costs, but variable time and scope.
- D Agile projects have fixed scope and time, but variable costs.
Xem giải thích
Đáp án
B — DỰ ÁN AGILE CỐ ĐỊNH CHI PHÍ VÀ THỜI GIAN, NHƯNG PHẠM VI BIẾN ĐỔI.
Vì sao đúng
⚠ Tam giác ràng buộc bị lật ngược thế nào: | Yếu tố | Dự án dự đoán | Dự án agile | |---|---|---| | ⚠ PHẠM VI | ⚠ CỐ ĐỊNH — chốt từ đầu | ⚠ BIẾN ĐỔI — xếp lại mỗi chặng | | ⚠ THỜI GIAN | ⚠ ước lượng, có thể trượt | ⚠ CỐ ĐỊNH — số chặng đã định | | ⚠ CHI PHÍ | ⚠ ước lượng, có thể trượt | ⚠ CỐ ĐỊNH — đội cố định × số chặng | | ⚠ Kết luận | ⚠ agile cố định hai đỉnh và để mở đỉnh còn lại, đúng ngược với dự đoán |
⚠ Vì sao chi phí trong agile lại cố định được: ⚠ một đội có quy mô ổn định làm việc trong một số chặng xác định thì chi phí gần như tính trước được ⚠ — ⚠ biến số duy nhất còn lại là LÀM ĐƯỢC BAO NHIÊU trong khoảng đó.
Vì sao các phương án khác sai
-
A (cố định thời gian, nhưng chi phí và phạm vi đều biến đổi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó đúng một nửa: thời gian đúng là cố định trong agile, và phạm vi đúng là biến đổi: ⚠ nhưng ⚠ nó để CHI PHÍ biến đổi, mà đó chính là điều agile tránh ⚠ — ⚠ đội cố định làm trong số chặng cố định thì chi phí cũng cố định theo; ⚠ và nếu cả chi phí lẫn phạm vi đều mở thì hợp đồng agile không thể tồn tại: không ai cấp vốn cho một dự án mà cả tiền lẫn nội dung đều không xác định; ⚠ liên hệ #26963 lô 204 và #27082 lô 206: hợp đồng agile cố định TIỀN hoặc THỜI GIAN và để mở NỘI DUNG.
-
C (cố định chi phí, thời gian và phạm vi biến đổi) — ⚠ để thời gian mở là trái với nhịp chặng cố định của agile.
-
D (cố định phạm vi và thời gian, chi phí biến đổi) — ⚠ cố định phạm vi là mô tả dự án DỰ ĐOÁN; ⚠ hoàn toàn ngược với agile.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26963 lô 204 (hợp đồng agile cho phép xếp lại phạm vi), ⚠ #27082 lô 206 (không tính thêm tiền nếu khối lượng không tăng), ⚠ #26981 lô 204 (lập kế hoạch dài hạn theo quý), ⚠ #27123 cùng lô (có thể thêm hạng mục vào tồn đọng bất cứ lúc nào).
⚠ Hệ quả thực tế của việc lật tam giác: | Hệ quả | Nội dung | |---|---| | ⚠ Câu hỏi "bao giờ xong" trả lời được ngay | ⚠ ngày đã cố định | | ⚠ Câu hỏi "hết bao nhiêu tiền" cũng trả lời được | ⚠ ngân sách đã cố định | | ⚠ Câu hỏi "sẽ có những gì" thì trả lời bằng KHOẢNG | ⚠ phần chắc chắn và phần có thể | | ⚠ Ưu tiên trở thành công việc quan trọng nhất | ⚠ vì phần cuối tồn đọng có thể không được làm | | ⚠ Điều bên liên quan phải hiểu | ⚠ họ không mất quyền kiểm soát — họ đổi từ kiểm soát NỘI DUNG sang kiểm soát THỨ TỰ, và quyền thứ hai được thực hiện ở mọi chặng chứ không chỉ một lần lúc ký; liên hệ #26953 lô 204 |
⚠ Vì sao cách này giảm rủi ro: | Lý do | Nội dung | |---|---| | ⚠ Phần giá trị nhất được làm TRƯỚC | ⚠ nếu hết tiền thì phần bị bỏ là phần ít giá trị nhất | | ⚠ Không bao giờ vượt ngân sách | ⚠ vì ngân sách là ràng buộc cứng | | ⚠ Không bao giờ trễ hạn | ⚠ vì ngày là ràng buộc cứng | | ⚠ Có sản phẩm dùng được ở mọi thời điểm | | | ⚠ Đánh đổi phải chấp nhận | ⚠ bạn không biết trước CHÍNH XÁC sẽ nhận được gì — và với một số loại dự án như xây cầu hay tuân thủ quy định, đó là cái giá không chấp nhận được, nên agile không phải lựa chọn cho mọi dự án |
⚠ Nói với bên liên quan quen tư duy dự đoán thế nào: | Nên nói | Không nên nói | |---|---| | ⚠ "Ngày giao và ngân sách là chắc chắn" | ⚠ "phạm vi thì tuỳ" | | ⚠ "Anh chị quyết thứ tự ở mỗi chặng" | ⚠ "chúng tôi sẽ làm được gì hay nấy" | | ⚠ "Phần quan trọng nhất chắc chắn có" | | | ⚠ Đưa lộ trình chia thành phần chắc chắn và phần có thể | ⚠ liên hệ #26981 lô 204 | | ⚠ Điểm mấu chốt khi thuyết phục | ⚠ nhấn mạnh rằng hai thứ họ lo nhất — ngày và tiền — lại chính là hai thứ được BẢO ĐẢM trong agile; đó là góc nhìn ít người trình bày và cũng là góc nhìn thuyết phục nhất |
Từ khoá nhận diện:
"tam giác ràng buộc trong agile" → ⚠ cố định CHI PHÍ và THỜI GIAN, mở PHẠM VI "chi phí biến đổi" → ⚠ trái với đội cố định trong số chặng cố định "thời gian biến đổi" → ⚠ trái với nhịp chặng cố định "phạm vi cố định" → ⚠ đó là dự án DỰ ĐOÁN
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn đang cố định những đỉnh nào | | | Bên liên quan có hiểu đỉnh nào được để mở không | | | Tồn đọng của bạn có được xếp thứ tự theo giá trị không | |
Và điều mà việc lật tam giác ràng buộc thật sự trao đổi: sự chắc chắn về NỘI DUNG lấy sự chắc chắn về NGÀY và TIỀN — và với phần lớn bên liên quan, đó là phép đổi có lợi hơn họ tưởng.
- A During the sprint review, this topic should be addressed.
- B During the retrospective, this topic should be addressed.
- C The next time Francine interrupts during a meeting or conversation, call her out about her behavior in front of her team.
- D Call her in for a one-on-one meeting where you remind her of the team charter and the ground rules and explain to her she will be removed from the team if she continues to violate them.
Xem giải thích
Đáp án
B — NÊU CHỦ ĐỀ NÀY Ở BUỔI HỌP CẢI TIẾN (retrospective).
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ so sánh với #26931 lô 203, nơi một thành viên vi phạm quy tắc ứng xử (đi họp muộn) và khoá đáp án là NHẮC RIÊNG ⚠ — ⚠ ở đây cũng là vi phạm quy tắc trong điều lệ đội nhưng khoá lại là NÊU Ở BUỔI CẢI TIẾN; ⚠ hai khoá KHÔNG mâu thuẫn nếu nhìn kỹ khác biệt: ở #26931 hành vi chỉ ảnh hưởng tới chính người đó và mới xảy ra một tuần, còn ở đây hành vi ngắt lời ảnh hưởng TRỰC TIẾP tới cả đội, đã kéo dài qua bốn chặng và ĐÃ CÓ NHIỀU NGƯỜI PHÀN NÀN ⚠; ⚠ quy tắc rút ra: vi phạm ảnh hưởng tới một người thì xử lý riêng; vi phạm làm hỏng cách cả đội làm việc với nhau thì đưa ra buổi cải tiến — nhưng nêu ở dạng VẤN ĐỀ CHUNG chứ không nêu đích danh.
Vì sao đúng
⚠ Vì sao buổi cải tiến là nơi phù hợp: | Lý do | Nội dung | |---|---| | ⚠ Buổi cải tiến bàn về CÁCH ĐỘI LÀM VIỆC | ⚠ đúng loại vấn đề | | ⚠ Chỉ có đội tham dự | ⚠ an toàn, không có bên liên quan chứng kiến | | ⚠ Quy tắc do CHÍNH ĐỘI đặt ra trong điều lệ | ⚠ nên chính đội nên cùng rà lại | | ⚠ Nhiều người đã phàn nàn | ⚠ đây là vấn đề tập thể, không phải chuyện riêng | | ⚠ Có cơ chế sinh ra HÀNH ĐỘNG cải tiến | ⚠ liên hệ #27031 lô 205 | | ⚠ Kết luận | ⚠ đưa vấn đề về cách làm việc vào đúng diễn đàn đã có sẵn cho nó |
⚠ Cách nêu cho đúng: ⚠ nói về HÀNH VI và tác động của nó, không nêu tên ⚠ — ⚠ "tôi nhận thấy chúng ta hay ngắt lời nhau, ta cùng xem lại quy tắc này được không" hiệu quả hơn nhiều so với việc chỉ đích danh Francine.
Vì sao các phương án khác sai
-
D (gọi riêng và cảnh báo sẽ loại khỏi đội nếu tái phạm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nửa đầu hoàn toàn đúng: gặp riêng và nhắc lại quy tắc chính là cách xử lý chuẩn cho một cá nhân vi phạm — đó là khoá đáp án của #26931 lô 203: ⚠ nhưng ⚠ nửa sau phá hỏng nó: ĐE DOẠ loại khỏi đội cho một hành vi ngắt lời là phản ứng hoàn toàn không tương xứng ⚠; ⚠ và scrum master thường KHÔNG có thẩm quyền loại ai khỏi đội — đó là quyết định của quản lý chức năng; ⚠ đây là dạng bẫy quen thuộc: một phương án đúng nửa đầu rồi thêm một vế quá đà ở cuối, nên phải đọc hết cả câu.
-
C (gọi thẳng tên cô ấy ngay giữa cuộc họp lần tới) — ⚠ làm mất mặt trước tập thể; ⚠ chắc chắn tạo phòng thủ và làm hỏng quan hệ — trái nguyên tắc "khen công khai, góp ý riêng tư".
-
A (nêu ở buổi rà soát chặng) — ⚠ sai diễn đàn; ⚠ buổi rà soát chặng có BÊN LIÊN QUAN tham dự và bàn về SẢN PHẨM, không bàn chuyện nội bộ của đội.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26931 lô 203 (nhắc riêng khi một cá nhân vi phạm quy tắc — đọc kèm ghi chú chất lượng câu hỏi ở trên), ⚠ #27072 lô 206 (mục đích của quy tắc ứng xử), ⚠ #27031 lô 205 (buổi cải tiến phải sinh ra hành động), ⚠ #27023 lô 205 (không đánh giá cá nhân trước mặt bên liên quan).
⚠ Chọn diễn đàn theo loại vấn đề: | Vấn đề | Diễn đàn | |---|---| | ⚠ Hành vi của MỘT người, mới xảy ra | ⚠ trao đổi riêng — #26931 lô 203 | | ⚠ Cách CẢ ĐỘI làm việc với nhau | ⚠ buổi CẢI TIẾN — câu này | | ⚠ Sản phẩm và phản hồi từ bên ngoài | ⚠ buổi rà soát chặng | | ⚠ Vật cản trong ngày | ⚠ họp đứng — #27027 lô 205 | | ⚠ Vấn đề kỷ luật lặp lại nhiều lần | ⚠ phối hợp với quản lý chức năng | | ⚠ Câu hỏi phân biệt | ⚠ "chuyện này ảnh hưởng tới AI" — một người thì xử lý riêng, cả đội thì đưa ra buổi cải tiến, người ngoài thì đưa ra buổi rà soát |
⚠ Nêu vấn đề hành vi trong buổi cải tiến thế nào: | Nên | Không nên | |---|---| | ⚠ Nói về hành vi và tác động, không nêu tên | ⚠ chỉ đích danh ai đó | | ⚠ Nhắc lại quy tắc CẢ ĐỘI đã cùng đặt | ⚠ trình bày như luật của scrum master | | ⚠ Hỏi cả đội muốn xử lý thế nào | ⚠ áp giải pháp xuống | | ⚠ Chốt một hành động cụ thể | ⚠ nêu ra rồi để đó | | ⚠ Ví dụ một hành động cụ thể | ⚠ "từ chặng sau, ai muốn nói thì giơ tay và người điều phối sẽ mời lần lượt" — một quy tắc nhỏ, áp dụng cho tất cả, và không ai bị chỉ mặt |
⚠ Nếu buổi cải tiến không giải quyết được: | Bước tiếp theo | Nội dung | |---|---| | ⚠ Gặp riêng Francine, nói về tác động cụ thể | ⚠ liên hệ #26931 lô 203 | | ⚠ Cô ấy có thể không nhận ra mình đang làm vậy | ⚠ rất thường gặp | | ⚠ Nếu lặp lại, phối hợp với quản lý chức năng | | | ⚠ Điều nên giả định trước tiên | ⚠ phần lớn người hay ngắt lời không cố ý thiếu tôn trọng — họ hào hứng hoặc quen nhịp trò chuyện khác; nên bắt đầu bằng việc cho họ biết thay vì bằng việc cảnh cáo |
Từ khoá nhận diện:
"hành vi ảnh hưởng cả đội, nhiều người phàn nàn" → ⚠ buổi CẢI TIẾN "hành vi của một người, mới xảy ra" → ⚠ nhắc RIÊNG (xem #26931 lô 203) "đe doạ loại khỏi đội" → ⚠ không tương xứng, và sai thẩm quyền "gọi tên giữa cuộc họp" → ⚠ làm mất mặt trước tập thể
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc ứng xử của đội bạn có được rà lại trong buổi cải tiến không | | | Bạn nêu vấn đề hành vi ở dạng chung hay đích danh | | | Buổi cải tiến gần nhất có sinh ra hành động nào không | |
Và điều quyết định nên đưa một vấn đề hành vi ra chỗ đông người hay nói riêng: không phải mức độ nghiêm trọng của nó, mà việc nó đang làm hỏng công việc của một người hay của tất cả mọi người.
- A Work with the stakeholder to change their ideas to be in compliance.
- B Accept the stakeholder’s suggestions.
- C Ask the legal team how risky the suggestion is.
- D Report the stakeholder to Creation Corporation’s legal team.
Xem giải thích
Đáp án
A — LÀM VIỆC CÙNG BÊN LIÊN QUAN ĐỂ ĐIỀU CHỈNH Ý TƯỞNG CỦA HỌ CHO TUÂN THỦ PHÁP LUẬT.
Vì sao đúng
⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Việc trái luật là ranh giới KHÔNG thể thương lượng | ⚠ không có phương án chấp nhận | | ⚠ Nhưng bên liên quan có NHU CẦU thật đằng sau đề xuất | ⚠ nhu cầu đó vẫn có thể đáp ứng được | | ⚠ Có thể họ KHÔNG BIẾT quy định địa phương | ⚠ đề nói chính Victoria mới là người rành | | ⚠ Cùng nhau tìm cách hợp pháp giữ được quan hệ | | | ⚠ Kết luận | ⚠ giữ nguyên tắc mà không phá quan hệ — đó là bản chất của việc xử lý ràng buộc tuân thủ |
⚠ Điểm mấu chốt: ⚠ phân biệt giữa YÊU CẦU cụ thể và NHU CẦU đằng sau nó ⚠ — ⚠ yêu cầu có thể trái luật, nhưng nhu cầu thì thường có nhiều cách đáp ứng khác nhau.
Vì sao các phương án khác sai
-
C (hỏi bộ phận pháp chế xem đề xuất đó rủi ro tới đâu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ tham vấn pháp chế là hành động chuyên nghiệp và trong nhiều tình huống pháp lý phức tạp thì đó đúng là bước cần làm: ⚠ nhưng ⚠ đề nói rõ Victoria ĐÃ BIẾT đề xuất trái luật — nên câu hỏi không còn là "có trái luật không" mà là "làm gì tiếp" ⚠; ⚠ và cách diễn đạt "rủi ro tới đâu" ngụ ý rằng nếu rủi ro thấp thì có thể làm — đó là cách tư duy sai với một ranh giới pháp lý; ⚠ tuân thủ không phải thứ được cân nhắc theo mức rủi ro như các rủi ro thông thường; liên hệ #27059 lô 206.
-
D (báo cáo bên liên quan lên bộ phận pháp chế của công ty) — ⚠ leo thang quá mức cho một đề xuất được đưa ra trong giai đoạn lập kế hoạch; ⚠ họ có thể chỉ đơn giản là không biết quy định, và biến họ thành đối tượng bị báo cáo sẽ phá huỷ quan hệ.
-
B (chấp nhận đề xuất của bên liên quan) — ⚠ vi phạm pháp luật; ⚠ đây là phương án duy nhất sai hoàn toàn về mặt đạo đức nghề nghiệp.
Ghi nhớ
⚠ Đối chiếu: ⚠ #27059 lô 206 (rủi ro tuân thủ và cách xử lý khác biệt), ⚠ #26983 lô 205 (quy tắc đạo đức PMI), ⚠ #26913 lô 203 (bên liên quan có ý kiến trái chiều vẫn phải được thu hút), ⚠ #26936 lô 204 (giải thích thay vì từ chối thẳng).
⚠ Chuyển từ LẬP TRƯỜNG sang NHU CẦU: | Cách hỏi | Kết quả | |---|---| | ⚠ "Anh chị muốn có tính năng X" | ⚠ lập trường — có thể trái luật | | ⚠ "Tính năng X giải quyết vấn đề gì cho anh chị" | ⚠ NHU CẦU — thường có nhiều cách đáp ứng | | ⚠ Vì sao câu hỏi thứ hai mở ra lối thoát | ⚠ một lập trường thì chỉ có thể chấp nhận hoặc từ chối; còn một nhu cầu thì luôn có ít nhất vài cách khác nhau để thoả mãn, và trong đó thường có cách hợp pháp |
⚠ Victoria nên tiến hành thế nào: | Bước | Nội dung | |---|---| | ⚠ 1. Cảm ơn và ghi nhận đề xuất | ⚠ họ đang muốn dự án tốt hơn | | ⚠ 2. Giải thích quy định pháp lý một cách cụ thể | ⚠ họ có thể thật sự không biết | | ⚠ 3. Hỏi nhu cầu thật đằng sau đề xuất | | | ⚠ 4. Cùng tìm phương án hợp pháp | | | ⚠ 5. Tham vấn pháp chế nếu vùng xám | ⚠ lúc này mới cần | | ⚠ 6. GHI LẠI cuộc trao đổi và kết luận | ⚠ quan trọng với chuyện pháp lý | | ⚠ Điều tuyệt đối không làm | ⚠ im lặng và hy vọng đề xuất đó tự biến mất — nếu nó quay lại ở giai đoạn thực hiện thì lúc đó việc từ chối sẽ khó hơn nhiều và tốn kém hơn nhiều |
⚠ Vì sao tuân thủ không được xử lý như rủi ro thông thường: | Rủi ro thông thường | Rủi ro tuân thủ | |---|---| | ⚠ Cân nhắc chi phí ứng phó với tác động | ⚠ phải xử lý bất kể chi phí | | ⚠ Có thể CHẤP NHẬN nếu nhỏ | ⚠ gần như không bao giờ chấp nhận được | | ⚠ Hậu quả giới hạn trong dự án | ⚠ hậu quả có thể lan ra cả tổ chức | | ⚠ Nguyên tắc | ⚠ với ranh giới pháp lý, câu hỏi duy nhất là "làm cách nào cho đúng luật", không bao giờ là "vi phạm này rủi ro tới đâu" |
Từ khoá nhận diện:
"đề xuất trái luật địa phương" → ⚠ LÀM VIỆC CÙNG HỌ để điều chỉnh cho hợp pháp "hỏi pháp chế xem rủi ro tới đâu" → ⚠ đã biết là trái luật rồi, và tuân thủ không cân theo mức rủi ro "báo cáo bên liên quan" → ⚠ leo thang quá mức, họ có thể chỉ không biết "chấp nhận đề xuất" → ⚠ vi phạm pháp luật, sai hoàn toàn
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn chịu những quy định địa phương nào | | | Bên liên quan của bạn có biết các quy định đó không | | | Bạn có hỏi nhu cầu đằng sau mỗi yêu cầu không | |
Và điều mà việc hỏi "đề xuất này nhằm giải quyết vấn đề gì" mở ra, mà việc từ chối thẳng thì đóng lại: khả năng tìm ra một cách khác vừa hợp pháp vừa đáp ứng đúng điều họ thật sự cần.
- A Tacit knowledge
- B Interactive knowledge
- C Transitive knowledge
- D Collaborative knowledge
Xem giải thích
Đáp án
A — TRI THỨC ẨN (tacit knowledge).
Vì sao đúng
⚠ Vì sao đây là tri thức ẩn: | Đặc điểm | Nội dung | |---|---| | ⚠ Đội biết phải làm gì mà không cần tra tài liệu | ⚠ không ai viết nó ra | | ⚠ Hình thành từ KINH NGHIỆM chung theo thời gian | ⚠ "đã ngồi chung khá lâu" | | ⚠ Khó diễn đạt thành văn bản | ⚠ "gọi ai, nói gì, làm thế nào" | | ⚠ Truyền được bằng cách CÙNG LÀM, cùng trải nghiệm | | | ⚠ Kết luận | ⚠ tri thức ẩn = thứ người ta biết mà không nhận ra là mình biết |
⚠ Rủi ro của tri thức ẩn: ⚠ nó biến mất khi người ta rời đi hoặc khi đội bị tách ra ⚠ — ⚠ và không ai nhận ra khoảng trống cho tới lần đầu tiên cần tới nó; liên hệ #26920 lô 203.
Vì sao các phương án khác sai
- B (tri thức tương tác) và C (tri thức chuyển tiếp) và D (tri thức cộng tác) — ⚠ cả ba đều là THUẬT NGỮ BỊA ⚠; ⚠ phương án B là cái gây nhiễu mạnh nhất vì "tương tác" gợi tới việc đội trao đổi với nhau, mà tri thức này đúng là hình thành qua tương tác ⚠ — ⚠ nhưng phân loại tri thức chuẩn chỉ có hai loại: ẨN (tacit) và HIỆN (explicit); ⚠ đây là dạng bẫy quen thuộc: đặt một thuật ngữ thật giữa ba từ ghép nghe hợp lý, và cả ba từ ghép đó đều mô tả đúng hiện tượng nhưng không phải tên gọi của nó.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26920 lô 203 (tri thức mức cá nhân và tri thức ẩn), ⚠ #26948 lô 204 (lập trình đôi truyền tri thức ẩn), ⚠ #27044 lô 206 (quan sát chủ động để học tri thức ẩn), ⚠ #27060 lô 206 (dùng người kỳ cựu làm cố vấn).
⚠ HAI LOẠI tri thức, bảng đối chiếu: | Tri thức HIỆN (explicit) | Tri thức ẨN (tacit) | |---|---| | ⚠ Viết ra được: tài liệu, quy trình, mã nguồn | ⚠ nằm trong đầu người ta — ĐÁP ÁN | | ⚠ Dễ chia sẻ, dễ lưu trữ | ⚠ khó diễn đạt thành lời | | ⚠ Truyền bằng cách ĐỌC | ⚠ truyền bằng cách CÙNG LÀM | | ⚠ Ví dụ: sổ tay vận hành | ⚠ ví dụ: biết gọi ai khi máy lạnh hỏng | | ⚠ Tỷ lệ trong một tổ chức | ⚠ phần lớn tri thức thật sự có giá trị là tri thức ẨN — và đó cũng là phần không xuất hiện trong bất kỳ kho tài liệu nào |
⚠ Vì sao đội ngồi chung tạo ra nhiều tri thức ẩn: | Cơ chế | Nội dung | |---|---| | ⚠ Quan sát lẫn nhau hằng ngày | ⚠ liên hệ #27044 lô 206 | | ⚠ Trò chuyện tình cờ, không có mục đích | ⚠ liên hệ #27057 lô 206 | | ⚠ Cùng trải qua các sự cố | ⚠ kinh nghiệm chung | | ⚠ Hình thành thói quen và quy ước ngầm | | | ⚠ Mặt trái | ⚠ đội càng gắn bó lâu thì tri thức ẩn càng nhiều, và người mới gia nhập càng khó hoà nhập — họ thiếu đúng phần tri thức mà không ai nghĩ tới việc giải thích, vì với cả đội thì nó quá hiển nhiên |
⚠ Biến tri thức ẩn thành hiện, khi nào và bằng cách nào: | Cách | Nội dung | |---|---| | ⚠ Viết sổ tay ngắn cho các tình huống hay gặp | ⚠ "máy lạnh hỏng thì gọi số này" | | ⚠ Lập danh mục kiểm tra | ⚠ liên hệ #27021 lô 205 | | ⚠ Ghép người mới với người cũ | ⚠ truyền phần không viết được | | ⚠ Phỏng vấn bàn giao trước khi ai đó nghỉ | ⚠ liên hệ #26920 lô 203 | | ⚠ Ranh giới thực dụng | ⚠ không phải mọi tri thức ẩn đều đáng viết ra — chỉ nên hiện hoá phần mà việc mất nó sẽ gây tổn thất thật; cố ghi lại tất cả sẽ tạo ra một kho tài liệu không ai đọc |
Từ khoá nhận diện:
"ai cũng biết phải làm gì mà không ai viết ra" → ⚠ TRI THỨC ẨN "tri thức tương tác / chuyển tiếp / cộng tác" → ⚠ cả ba đều là THUẬT NGỮ BỊA "tri thức hiện" → ⚠ viết ra được: tài liệu, quy trình "chỉ có hai loại" → ⚠ ẩn và hiện, không có loại thứ ba
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới trong đội bạn mất bao lâu để biết những việc "ai cũng biết" | | | Có tri thức ẩn nào mà mất đi sẽ gây tổn thất thật không | | | Bạn có phỏng vấn bàn giao khi có người nghỉ không | |
Và điều làm cho tri thức ẩn vừa quý vừa nguy hiểm: nó là thứ khiến một đội làm việc trơn tru tới mức không ai nhận ra nó tồn tại — cho tới ngày đội đó không còn ngồi cùng nhau nữa.
- A Ezra will personally sign off on all changes.
- B The project team can accept or reject any change.
- C Agile allows projects to respond to changes by adjusting the backlog rapidly.
- D Tell the developer to get back to work and leave project management to Ezra.
Xem giải thích
Đáp án
C — AGILE CHO PHÉP DỰ ÁN ĐÁP ỨNG THAY ĐỔI BẰNG CÁCH ĐIỀU CHỈNH TỒN ĐỌNG MỘT CÁCH NHANH CHÓNG.
Vì sao đúng
⚠ Vì sao đây là câu trả lời đúng: | Lý do | Nội dung | |---|---| | ⚠ Phạm vi CHƯA CHỐT là ĐẶC ĐIỂM của agile, không phải lỗi | ⚠ cần giải thích chứ không cần trấn an suông | | ⚠ Tồn đọng được xếp lại ở MỖI chặng | ⚠ cơ chế đáp ứng thay đổi | | ⚠ Đội mới bắt đầu chặng đầu tiên | ⚠ hoàn toàn bình thường ở giai đoạn này | | ⚠ Đây là đội phát triển MỚI | ⚠ họ chưa quen cách làm agile | | ⚠ Kết luận | ⚠ giáo dục về cách làm việc thay vì né tránh mối lo |
⚠ Mối lo của lập trình viên là chính đáng: ⚠ với người quen dự án dự đoán, phạm vi chưa chốt nghe như dự án chưa sẵn sàng ⚠ — ⚠ Ezra cần giải thích rằng trong agile, thứ được chốt là MỤC TIÊU CHẶNG chứ không phải toàn bộ phạm vi; liên hệ #27097 cùng lô.
Vì sao các phương án khác sai
-
B (đội dự án có thể chấp nhận hoặc từ chối bất kỳ thay đổi nào) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như trao quyền cho đội, mà trao quyền cho đội là giá trị agile — nên nó có vẻ đúng tinh thần: ⚠ nhưng ⚠ nó sai về VAI TRÒ: nội dung tồn đọng thuộc thẩm quyền CHỦ SẢN PHẨM, không phải của đội phát triển ⚠; ⚠ đội quyết định CÁCH LÀM và khối lượng nhận vào mỗi chặng, còn LÀM GÌ là quyền của chủ sản phẩm; ⚠ liên hệ #26961 và #26969 lô 204: đây là ranh giới vai trò bị vi phạm nhiều nhất trong các đội mới chuyển sang agile.
-
A (Ezra sẽ đích thân duyệt mọi thay đổi) — ⚠ scrum master không có thẩm quyền đó; ⚠ và nó biến anh ấy thành một nút thắt.
-
D (bảo lập trình viên quay lại làm việc, chuyện quản lý để Ezra lo) — ⚠ gạt bỏ một câu hỏi chính đáng; ⚠ trái hoàn toàn với vai trò lãnh đạo phụng sự và sẽ khiến đội thôi đặt câu hỏi.
Ghi nhớ
⚠ Đối chiếu: ⚠ #27097 cùng lô (tam giác ràng buộc: phạm vi biến đổi), ⚠ #27123 cùng lô (có thể thêm hạng mục vào tồn đọng bất cứ lúc nào), ⚠ #26969 lô 204 (thẩm quyền của chủ sản phẩm với tồn đọng), ⚠ #26985 lô 205 (điều lệ agile nêu rõ điểm khác biệt).
⚠ Ai quyết gì trong scrum, bảng ranh giới: | Quyết định | Thuộc về ai | |---|---| | ⚠ LÀM GÌ và theo thứ tự nào | ⚠ CHỦ SẢN PHẨM | | ⚠ LÀM THẾ NÀO về mặt kỹ thuật | ⚠ ĐỘI PHÁT TRIỂN | | ⚠ Nhận bao nhiêu việc vào một chặng | ⚠ ĐỘI PHÁT TRIỂN | | ⚠ Sản phẩm có được chấp nhận không | ⚠ CHỦ SẢN PHẨM | | ⚠ Quy trình có được tuân thủ không | ⚠ SCRUM MASTER | | ⚠ Ranh giới bị vi phạm nhiều nhất | ⚠ chủ sản phẩm can thiệp vào CÁCH LÀM, hoặc đội tự quyết BỎ một hạng mục — cả hai đều phá vỡ sự cân bằng mà ba vai trò này được thiết kế để tạo ra |
⚠ Ezra nên giải thích thêm những gì: | Nội dung | Vì sao hữu ích cho một đội mới | |---|---| | ⚠ Mục tiêu CHẶNG được chốt trong chặng | ⚠ có sự ổn định, chỉ là ở quy mô nhỏ hơn | | ⚠ Việc đang làm trong chặng không bị chèn ngang | ⚠ liên hệ #27022 lô 205 | | ⚠ Phạm vi tổng thể được làm rõ DẦN | ⚠ lập kế hoạch theo lớp sóng — #26869 lô 202 | | ⚠ Có lộ trình dài hạn theo quý | ⚠ liên hệ #26981 lô 204 | | ⚠ Điều trấn an nhất với người quen dự đoán | ⚠ rằng họ VẪN CÓ một khoảng thời gian ổn định để làm việc — chỉ là nó dài hai tuần chứ không dài sáu tháng; hiểu điều này thường làm mối lo tan đi ngay |
⚠ Vì sao đội mới hay lo về phạm vi chưa chốt: | Nỗi lo | Thực tế | |---|---| | ⚠ "Sẽ bị đổi yêu cầu giữa chừng" | ⚠ trong chặng thì không đổi | | ⚠ "Làm rồi lại bỏ đi" | ⚠ mỗi chặng đều bàn giao thứ dùng được | | ⚠ "Không biết dự án bao giờ xong" | ⚠ ngày kết thúc CỐ ĐỊNH — #27097 cùng lô | | ⚠ "Không ai chịu trách nhiệm về phạm vi" | ⚠ chủ sản phẩm chịu trách nhiệm | | ⚠ Nhận xét | ⚠ việc lập trình viên chủ động nêu mối lo ngay chặng đầu là dấu hiệu tốt — anh ấy đang cố hiểu cách làm việc mới thay vì âm thầm hoài nghi, và phản ứng của Ezra sẽ quyết định anh ấy còn hỏi nữa hay không |
Từ khoá nhận diện:
"lo phạm vi chưa chốt trong dự án agile" → ⚠ GIẢI THÍCH cơ chế điều chỉnh tồn đọng "đội có thể chấp nhận hoặc từ chối thay đổi" → ⚠ sai vai trò, đó là quyền chủ sản phẩm "scrum master duyệt mọi thay đổi" → ⚠ không có thẩm quyền, lại tạo nút thắt "quay lại làm việc đi" → ⚠ gạt bỏ câu hỏi chính đáng
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có hiểu ai quyết gì không | | | Việc trong chặng của bạn có bị chèn ngang không | | | Người mới trong đội có dám hỏi những câu cơ bản không | |
Và điều mà một câu hỏi từ người mới trong đội đáng được đối xử như thế nào: như một cơ hội để giải thích, chứ không phải một dấu hiệu rằng họ chưa hiểu chuyện — vì cách bạn trả lời sẽ quyết định họ có hỏi câu tiếp theo hay không.
- A Creating a project status report
- B The creation of a secured project repository that only certain stakeholders are allowed access to
- C Hosting a project status meeting
- D Sending e-mails to certain project stakeholders
Xem giải thích
Đáp án
C — TỔ CHỨC MỘT CUỘC HỌP TÌNH TRẠNG DỰ ÁN.
Vì sao đúng
⚠ Truyền thông TƯƠNG TÁC là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Trao đổi HAI CHIỀU theo thời gian thực | ⚠ đặc điểm quyết định | | ⚠ Nhiều bên cùng tham gia đồng thời | | | ⚠ Có phản hồi ngay lập tức | ⚠ hỏi được, làm rõ được ngay | | ⚠ Ví dụ: họp, gọi điện, gọi video, trò chuyện trực tiếp | | | ⚠ Kết luận | ⚠ cuộc họp là ví dụ điển hình nhất của truyền thông tương tác |
⚠ Vì sao tương tác quan trọng với bên liên quan: ⚠ nó là cách duy nhất xác nhận được rằng họ đã HIỂU, không chỉ đã NHẬN thông tin ⚠ — ⚠ liên hệ #27008 lô 205 về vòng phản hồi trong mô hình truyền thông.
Vì sao các phương án khác sai
-
A (lập báo cáo tình trạng dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cả hai đều mang cụm "tình trạng dự án" và cả hai đều là công cụ truyền thông chuẩn — chỉ khác một từ: ⚠ nhưng ⚠ báo cáo là truyền thông ĐẨY: một chiều, người gửi chủ động gửi tới người nhận ⚠; ⚠ cuộc họp là TƯƠNG TÁC: hai chiều, có phản hồi tức thì; ⚠ liên hệ #26926 lô 203: đây là bộ ba khái niệm đẩy – kéo – tương tác, và câu hỏi đang hỏi đúng một trong ba.
-
D (gửi email cho một số bên liên quan) — ⚠ truyền thông ĐẨY; ⚠ một chiều, không có phản hồi tức thì.
-
B (tạo một kho tài liệu bảo mật cho một số bên liên quan truy cập) — ⚠ truyền thông KÉO; ⚠ người nhận tự vào lấy khi cần — liên hệ #26926 lô 203.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26926 lô 203 (ba phương pháp truyền thông: đẩy, kéo, tương tác), ⚠ #27045 lô 205 (nhu cầu truyền thông chính thức), ⚠ #27122 cùng lô (nhu cầu truyền thông phi chính thức), ⚠ #27131 cùng lô (nhu cầu truyền thông nội bộ), ⚠ #26997 lô 205 (báo cáo định kỳ).
⚠ BA PHƯƠNG PHÁP truyền thông, bảng đối chiếu: | Phương pháp | Chiều | Ví dụ | |---|---|---| | ⚠ TƯƠNG TÁC | ⚠ hai chiều, thời gian thực | ⚠ họp, gọi điện, gọi video — ĐÁP ÁN | | ⚠ ĐẨY (push) | ⚠ một chiều, gửi tới người nhận | ⚠ email, báo cáo, bản tin, thư | | ⚠ KÉO (pull) | ⚠ một chiều, người nhận tự lấy | ⚠ cổng thông tin, wiki, kho tài liệu | | ⚠ Cách chọn | ⚠ thông tin càng quan trọng và càng cần xác nhận đã hiểu thì càng phải dùng TƯƠNG TÁC; thông tin nhiều và ít khẩn thì dùng KÉO; thông báo cần đến tay đúng người thì dùng ĐẨY |
⚠ Khi nào bắt buộc phải dùng tương tác: | Tình huống | Vì sao | |---|---| | ⚠ Thông tin phức tạp, dễ hiểu nhầm | ⚠ cần hỏi lại ngay | | ⚠ Chủ đề nhạy cảm hoặc tin xấu | ⚠ cần đọc phản ứng của người nghe | | ⚠ Cần ra quyết định ngay | | | ⚠ Cần xây dựng quan hệ | ⚠ liên hệ #26921 lô 203 | | ⚠ Có bất đồng cần giải quyết | | | ⚠ Cái giá của tương tác | ⚠ tốn thời gian của nhiều người cùng lúc — nên nó là phương pháp ĐẮT NHẤT trong ba loại, và chỉ nên dùng khi thật sự cần vòng phản hồi tức thì |
⚠ Một cuộc họp tương tác hiệu quả cần gì: | Yếu tố | Nội dung | |---|---| | ⚠ Chương trình họp gửi trước | ⚠ liên hệ #27050 lô 206 | | ⚠ Đúng người tham dự, không thừa | | | ⚠ Thời gian có giới hạn | | | ⚠ Có người điều phối | ⚠ liên hệ #27034 lô 206 | | ⚠ Kết thúc bằng quyết định và hành động | | | ⚠ Dấu hiệu cuộc họp không cần là tương tác | ⚠ nếu suốt buổi chỉ có một người nói và không ai hỏi gì thì đó thực chất là truyền thông ĐẨY được tổ chức dưới hình thức cuộc họp — và một email sẽ làm điều đó rẻ hơn nhiều |
Từ khoá nhận diện:
"tổ chức cuộc họp" → ⚠ truyền thông TƯƠNG TÁC "lập báo cáo" → ⚠ truyền thông ĐẨY, một chiều "gửi email" → ⚠ truyền thông ĐẨY "kho tài liệu để họ tự truy cập" → ⚠ truyền thông KÉO
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cuộc họp gần nhất của bạn có ai hỏi gì không | | | Bạn có dùng tương tác cho những thứ đáng lẽ chỉ cần một email không | | | Tin xấu gần nhất bạn báo bằng phương pháp nào | |
Và điều duy nhất mà truyền thông tương tác làm được, còn hai phương pháp kia thì không: cho bạn biết ngay tại chỗ rằng người nghe đã hiểu điều bạn nói hay chưa.