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

Đáp án

A — KHEN NGỢI đội vì ý tưởng đó và ĐỀ XUẤT nó với CHỦ SẢN PHẨM.

Vì sao đúng

⚠ Vì sao đây là phản ứng đúng: | Lý do | Nội dung | |---|---| | ⚠ Phát hành sớm để hiện thực hoá lợi ích MỘT PHẦN là nguyên tắc cốt lõi của agile | ⚠ giao giá trị sớm và liên tục | | ⚠ Ý tưởng đến từ ĐỘI — cần được GHI NHẬN | ⚠ liên hệ #26520 lô 195 | | ⚠ Nhưng quyết định PHÁT HÀNH thuộc về CHỦ SẢN PHẨM | ⚠ ai quyết cái gì — liên hệ #26604 lô 197 | | ⚠ Jim không tự quyết, cũng không bỏ qua | ⚠ anh chuyển ý tưởng tới đúng người | | ⚠ Dự án mới bắt đầu lập kế hoạch | ⚠ thời điểm lý tưởng để tính chuyện phát hành theo giai đoạn | | ⚠ Kết luận | ⚠ vừa ghi nhận đội, vừa tôn trọng ranh giới vai trò |

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

• B (để đội trình bày ý tưởng ở buổi họp đứng kế tiếp) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có vẻ tôn trọng đội và dùng một nghi thức có sẵn: ⚠ nhưng ⚠ HỌP ĐỨNG dùng để ĐỒNG BỘ công việc hằng ngày và nêu vật cản, không phải nơi bàn quyết định chiến lược phát hành ⚠ — ⚠ nó chỉ có 15 phút và người quyết (chủ sản phẩm) có thể không dự; ⚠ liên hệ #26506 lô 195.

• C (định nghĩa lại dự án chỉ còn phát hành sớm, phần còn lại thành một dự án theo dõi) — ⚠ thay đổi phạm vi và cấu trúc dự án rất lớn; ⚠ vượt xa thẩm quyền của Jim và không ai yêu cầu điều đó.

• D (nói với đội rằng phải hoàn thành toàn bộ dự án trước khi phát hành gì) — ⚠ TRÁI với nguyên tắc agile; ⚠ và nó dập tắt một ý tưởng tốt, dạy đội rằng đề xuất là vô ích.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26604 lô 197 (chỉ bên liên quan sang chủ sản phẩm), ⚠ #26622 lô 197 (scrum master làm cho vấn đề hiện ra), ⚠ #26569 lô 196 (ai quyết cái gì trong agile), ⚠ #26581 lô 196 (lộ trình theo quý), ⚠ #26520 lô 195 (ghi nhận thành tích).

⚠ PHÁT HÀNH THEO GIAI ĐOẠN — vì sao có giá trị: | Lợi ích | Nội dung | |---|---| | ⚠ HIỆN THỰC HOÁ LỢI ÍCH SỚM | ⚠ tổ chức bắt đầu thu về trước khi dự án xong — liên hệ #26614 lô 197 về thời gian hoàn vốn | | ⚠ Nhận PHẢN HỒI THẬT từ người dùng thật | ⚠ giá trị lớn nhất, và không có cách nào khác để có được | | ⚠ Giảm rủi ro của một lần phát hành lớn | ⚠ liên hệ #26510 lô 195 — chiến lược big bang | | ⚠ Tăng động lực cho đội | ⚠ thấy sản phẩm được dùng thật | | ⚠ Chứng minh giá trị cho bên liên quan sớm | ⚠ giúp bảo vệ ngân sách cho phần còn lại | | ⚠ Điều cần cân nhắc | ⚠ phát hành sớm cũng tạo ra chi phí: hỗ trợ, vận hành, tương thích ngược, và có thể cả đào tạo người dùng — đó là lý do chủ sản phẩm mới là người quyết, vì chỉ họ nhìn được cả hai phía của phép tính |

⚠ Vai trò của Jim trong tình huống này: | Việc Jim LÀM | Việc Jim KHÔNG làm | |---|---| | ⚠ Ghi nhận và khuyến khích đội đề xuất | ⚠ tự quyết định phát hành hay không | | ⚠ Chuyển ý tưởng tới đúng người có thẩm quyền | ⚠ thay đổi cấu trúc dự án | | ⚠ Giúp đội trình bày ý tưởng cho thuyết phục | ⚠ dập tắt ý tưởng vì nó không nằm trong kế hoạch | | ⚠ Theo dõi để ý tưởng không bị rơi mất | | | ⚠ Vì sao việc GHI NHẬN quan trọng ngang việc chuyển tiếp | ⚠ đây là dự án MỚI BẮT ĐẦU — cách Jim phản ứng với đề xuất đầu tiên của đội sẽ quyết định họ có tiếp tục đề xuất trong mười một vòng lặp còn lại hay không |

⚠ Chủ sản phẩm sẽ cân nhắc gì: | Yếu tố | Nội dung | |---|---| | ⚠ Phần phát hành sớm có tạo ra giá trị ĐỘC LẬP không | ⚠ hay phải chờ phần sau mới dùng được | | ⚠ Chi phí vận hành và hỗ trợ phát sinh | | | ⚠ Ảnh hưởng tới tiến độ phần còn lại | ⚠ đội sẽ bị chia sẻ thời gian cho việc hỗ trợ | | ⚠ Bên liên quan có sẵn sàng tiếp nhận không | ⚠ liên hệ #26490 lô 195 — đội vận hành | | ⚠ Rủi ro về uy tín nếu bản đầu chưa hoàn thiện | | | ⚠ Nhận xét | ⚠ đây là một quyết định đánh đổi thật, không phải một lựa chọn hiển nhiên — và đó chính là lý do nó phải được đưa lên đúng người thay vì được quyết ở một buổi họp đứng |

Từ khoá nhận diện:

"đội đề xuất phát hành sớm" → ⚠ KHEN ĐỘI và ĐỀ XUẤT VỚI CHỦ SẢN PHẨM "đưa ra họp đứng" → ⚠ họp đứng để đồng bộ công việc, không bàn chiến lược phát hành "định nghĩa lại dự án" → ⚠ vượt thẩm quyền, thay đổi lớn không ai yêu cầu "phải xong hết mới phát hành" → ⚠ trái nguyên tắc agile

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có thể phát hành từng phần không | ⚠ và ai đã hỏi câu đó chưa | | Đề xuất gần nhất của đội được xử lý thế nào | | | Đội bạn có biết đưa ý tưởng cho ai không | |

Và điều mà cách Jim phản ứng hôm nay quyết định cho cả mười hai vòng lặp phía trước: một đội đưa ra đề xuất tốt ngay ở giai đoạn lập kế hoạch là một đội đang suy nghĩ chứ không chỉ đang chờ việc — và thứ duy nhất có thể dập tắt điều đó là cách người quản lý đón nhận đề xuất đầu tiên.

Đáp án

A — Khi tìm hiểu CÁCH LÀM VIỆC TỐT NHẤT VỚI TỪNG NGƯỜI.

Vì sao đúng

⚠ Vì sao đây là mục đích chính của đánh giá tính cách: | Lý do | Nội dung | |---|---| | ⚠ Nó cho biết mỗi người XỬ LÝ THÔNG TIN và RA QUYẾT ĐỊNH thế nào | ⚠ hướng nội hay hướng ngoại, thiên về dữ liệu hay thiên về con người | | ⚠ Nó giúp điều chỉnh cách TƯƠNG TÁC với từng người | ⚠ ai cần thời gian suy nghĩ, ai cần bàn ngay | | ⚠ Kết quả được CHIA SẺ VỚI CẢ ĐỘI | ⚠ nên mọi người đều hiểu nhau hơn, không chỉ Jennifer | | ⚠ Nó giảm hiểu lầm do khác biệt phong cách | ⚠ rất nhiều xung đột bắt nguồn từ đây | | ⚠ Đây là mục đích rộng nhất, bao trùm ba phương án kia | | | ⚠ Kết luận | ⚠ hiểu cách làm việc với nhau là ứng dụng nền tảng, các ứng dụng khác đều xuất phát từ đó |

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

• D (khi GIAO TIẾP với đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hiểu tính cách ĐÚNG LÀ giúp giao tiếp hiệu quả hơn, và đó là ứng dụng được nhắc tới nhiều nhất: ⚠ nhưng ⚠ giao tiếp chỉ là MỘT PHẦN của việc làm việc cùng nhau ⚠ — ⚠ hiểu tính cách còn giúp phân công việc, xử lý xung đột, ra quyết định, xây dựng đội; ⚠ đây là quan hệ bộ phận – tổng thể, và đề hỏi tình huống HỮU ÍCH NHẤT, tức hỏi cái bao trùm.

• C (khi KHEN NGỢI một thành viên) — ⚠ cũng là một ứng dụng có thật: ⚠ có người thích khen công khai, có người ngại; ⚠ liên hệ #26520 lô 195; ⚠ nhưng phạm vi rất hẹp.

• B (khi HOÀN THIỆN DANH SÁCH CÔNG VIỆC của dự án) — ⚠ danh sách công việc do PHẠM VI quyết định, không do tính cách; ⚠ tính cách có thể ảnh hưởng tới việc PHÂN CÔNG, nhưng không tới nội dung công việc.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26387 lô 193 (chỉ số tính cách), ⚠ #26568 lô 196 (tính sáng tạo), ⚠ #26365 lô 192 (chỉ số cảm xúc), ⚠ #26600 lô 197 (mời người ít nói phát biểu), ⚠ #26641 cùng lô (điều chỉnh giao tiếp theo từng người).

⚠ ĐÁNH GIÁ TÍNH CÁCH giúp gì cho một đội: | Ứng dụng | Nội dung | |---|---| | ⚠ Hiểu cách làm việc tốt nhất với từng người | ⚠ ứng dụng nền — CÂU NÀY | | ⚠ Điều chỉnh cách giao tiếp | ⚠ phương án D — một phần của ứng dụng trên | | ⚠ Phân công việc hợp với thế mạnh | | | ⚠ Hiểu vì sao có xung đột và xử lý đúng cách | ⚠ liên hệ #26635 cùng lô | | ⚠ Ghi nhận theo cách người đó thấy có ý nghĩa | ⚠ phương án C | | ⚠ Xây dựng đội cân bằng về phong cách | ⚠ liên hệ #26447 lô 194 — giá trị của đa dạng | | ⚠ Điều KHÔNG được dùng nó để làm | ⚠ DÁN NHÃN hay loại trừ người — "anh ta là kiểu hướng nội nên không hợp làm việc với khách hàng" là cách dùng sai và có thể gây hại thật |

⚠ Vì sao CHIA SẺ kết quả với cả đội lại quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Hiểu nhau là việc HAI CHIỀU | ⚠ không chỉ Jennifer cần hiểu đội | | ⚠ Nó tạo ngôn ngữ chung để nói về khác biệt | ⚠ "tôi cần thời gian nghĩ trước khi họp" trở thành câu bình thường | | ⚠ Nó bình thường hoá sự khác biệt | ⚠ thay vì coi người khác mình là khó tính | | ⚠ Nó giảm quy kết động cơ xấu | ⚠ "anh ấy im lặng vì hướng nội" thay vì "anh ấy không quan tâm" | | ⚠ Điều kiện để làm đúng | ⚠ việc tham gia phải TỰ NGUYỆN và kết quả được dùng để HIỂU nhau, không để đánh giá — nếu đội cảm thấy nó ảnh hưởng tới đánh giá hiệu suất, họ sẽ trả lời theo cách họ nghĩ là đúng thay vì theo cách họ thật sự là |

⚠ Giới hạn của các bài đánh giá tính cách: | Giới hạn | Nội dung | |---|---| | ⚠ Nó mô tả XU HƯỚNG, không phải định mệnh | ⚠ người ta hành xử khác nhau trong các bối cảnh khác nhau | | ⚠ Kết quả có thể thay đổi theo thời gian và hoàn cảnh | | | ⚠ Không dự đoán được hiệu suất công việc | | | ⚠ Dễ bị dùng để dán nhãn | ⚠ rủi ro lớn nhất | | ⚠ Cách dùng lành mạnh | ⚠ coi nó là điểm KHỞI ĐẦU của một cuộc trò chuyện, không phải kết luận về một con người — giá trị thật nằm ở việc đội nói chuyện với nhau về cách mỗi người làm việc, và bài đánh giá chỉ là cái cớ để cuộc trò chuyện đó bắt đầu |

Từ khoá nhận diện:

"đánh giá tính cách hữu ích nhất khi nào" → ⚠ HIỂU CÁCH LÀM VIỆC TỐT NHẤT VỚI TỪNG NGƯỜI "khi giao tiếp" → ⚠ một phần của ứng dụng trên, phạm vi hẹp hơn "khi khen ngợi" → ⚠ ứng dụng có thật nhưng rất hẹp "khi lập danh sách công việc" → ⚠ do phạm vi quyết định, không do tính cách

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết ai trong đội cần thời gian suy nghĩ trước khi phát biểu không | | | Đội bạn có ngôn ngữ chung để nói về khác biệt phong cách không | | | Có ai đang bị dán nhãn dựa trên một bài đánh giá không | |

Và giá trị thật của một bài đánh giá tính cách được chia sẻ trong đội: không phải là mỗi người biết mình thuộc loại nào, mà là từ hôm đó trở đi, khác biệt giữa hai người trở thành một điều để hiểu thay vì một điều để chịu đựng.

Đáp án

D — Các CÔNG VIỆC nhằm ngăn ngừa thất bại đã KHÔNG ĐƯỢC GIAO cho ai.

Vì sao đúng

⚠ Vì sao đây là nguyên nhân: | Việc Emma ĐÃ làm | Việc Emma KHÔNG làm | |---|---| | ⚠ Tổ chức hồi cứu sau sự cố | ⚠ GIAO việc cho người cụ thể | | ⚠ Xác định nguyên nhân thất bại | ⚠ đặt HẠN hoàn thành | | ⚠ Thu thập phản hồi từ đội | ⚠ THEO DÕI việc thực hiện | | ⚠ Nhận diện rủi ro và lập ứng phó | | | ⚠ Ghi lại tài liệu và bổ sung nhận định của mình | | | ⚠ Gửi thông tin cho các bên liên quan | | | ⚠ Kết luận | ⚠ cô làm đúng gần như mọi bước, chỉ thiếu bước biến PHÂN TÍCH thành HÀNH ĐỘNG — và đó là bước duy nhất thật sự thay đổi kết quả |

⚠ Bằng chứng trong đề: ⚠ cô "phác thảo các công việc trong tương lai có thể cải thiện kết quả" — nhưng không có dòng nào nói rằng chúng được GIAO cho ai ⚠ — ⚠ một danh sách việc không có chủ sở hữu là một danh sách sẽ không được làm; ⚠ liên hệ #26536 lô 196.

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

• B (kết quả phân tích không được truyền đạt) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ truyền thông kém là nguyên nhân rất phổ biến của các vấn đề lặp lại: ⚠ nhưng ⚠ đề nói RÕ rằng cô ĐÃ soạn thông tin và GỬI cho nhiều bên liên quan ⚠ — ⚠ truyền đạt đã được làm, và làm tốt; ⚠ đây là bẫy chọn một nguyên nhân hợp lý mà đề đã loại trừ ngay trong câu chữ.

• A (chưa hoàn thành phân tích rủi ro) — ⚠ đề nói cô đã làm việc với đội qua NHẬN DIỆN RỦI RO và LẬP ỨNG PHÓ; ⚠ phân tích đã có.

• C (điều lệ dự án không được cập nhật) — ⚠ điều lệ không phải nơi ghi các hành động khắc phục sau một sự cố phát hành; ⚠ và nó hiếm khi được cập nhật sau khi ký — liên hệ #26662 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26597 lô 197 (hồi cứu phải ra hành động cụ thể), ⚠ #26536 lô 196 (mỗi rủi ro phải có chủ sở hữu), ⚠ #26546 lô 196 (quy trình xử lý vấn đề), ⚠ #26658 cùng lô (lỗi lặp lại là vấn đề quy trình), ⚠ #26606 lô 197 (Owen ghi tài liệu nhưng không thay đổi được gì).

⚠ Đối chiếu đặc biệt với #26606 lô 197: ⚠ hai câu này là một cặp về cùng một căn bệnh ⚠ — ⚠ ở #26606, Owen ghi chép rất kỹ sau mỗi thất bại nhưng vẫn thất bại vì thiếu năng lực NHẬN DIỆN rủi ro mới; ⚠ ở đây, Emma phân tích rất kỹ nhưng vẫn thất bại vì thiếu bước GIAO VIỆC. ⚠ Cả hai đều là ví dụ về việc tài liệu hoá thay thế cho hành động — và cả hai đều cho ra cùng một kết quả: sự cố lặp lại.

⚠ VÌ SAO HÀNH ĐỘNG PHẢI CÓ CHỦ SỞ HỮU: | Thành phần bắt buộc | Nội dung | |---|---| | ⚠ AI làm | ⚠ một CÁI TÊN, không phải một phòng ban — liên hệ #26498 lô 195 | | ⚠ LÀM GÌ | ⚠ cụ thể, kiểm chứng được | | ⚠ KHI NÀO xong | ⚠ có hạn | | ⚠ AI theo dõi | ⚠ và theo dõi ở đâu | | ⚠ Kiểm tra ở buổi tiếp theo | ⚠ nếu không kiểm thì hạn cũng vô nghĩa | | ⚠ Quy tắc thực dụng | ⚠ một hành động không có bốn thành phần trên thì chưa phải hành động — nó chỉ là một ý tưởng tốt được ghi lại |

⚠ Vì sao HỒI CỨU thất bại — các kiểu phổ biến: | Kiểu thất bại | Nội dung | |---|---| | ⚠ Không ra được hành động nào | ⚠ chỉ than phiền rồi giải tán | | ⚠ Ra hành động nhưng KHÔNG GIAO cho ai | ⚠ trường hợp của Emma — CÂU NÀY | | ⚠ Giao rồi nhưng không ai theo dõi | ⚠ hạn trôi qua và không ai nhắc | | ⚠ Ra quá nhiều hành động | ⚠ mười việc thì không việc nào được làm; một tới ba việc thì làm được | | ⚠ Truy tìm thủ phạm thay vì phân tích hệ thống | ⚠ liên hệ #26597 lô 197 | | ⚠ Cách kiểm chứng hồi cứu có hiệu quả không | ⚠ mở đầu buổi hồi cứu tiếp theo bằng việc rà lại các hành động của lần trước — nếu chúng chưa làm thì không có lý do gì để bàn thêm hành động mới |

⚠ Emma nên làm gì khác đi ở lần sau: | Việc | Nội dung | |---|---| | ⚠ Kết thúc buổi bằng danh sách HÀNH ĐỘNG có tên người và hạn | ⚠ tối đa ba việc | | ⚠ Đưa các hành động đó vào backlog hoặc kế hoạch | ⚠ để chúng cạnh tranh ưu tiên như mọi việc khác — liên hệ #26622 lô 197 | | ⚠ Rà lại chúng ở đầu buổi hồi cứu sau | | | ⚠ Báo cáo bên liên quan cả hành động lẫn tiến độ của chúng | ⚠ không chỉ báo cáo phân tích | | ⚠ Điều đáng ghi nhận ở Emma | ⚠ cô làm rất tốt phần khó nhất: tạo được không khí để đội nói thật và làm dịu căng thẳng sau một sự cố — thứ cô thiếu chỉ là bước cuối cùng, và đó là bước dễ nhất trong toàn bộ quy trình |

Từ khoá nhận diện:

"phân tích đầy đủ nhưng sự cố lặp lại" → ⚠ HÀNH ĐỘNG KHÔNG ĐƯỢC GIAO CHO AI "không truyền đạt kết quả" → ⚠ đề đã nói rõ là ĐÃ truyền đạt "chưa phân tích rủi ro" → ⚠ đề đã nói rõ là ĐÃ làm quy tắc nền → ⚠ hành động cần AI, LÀM GÌ, KHI NÀO, AI THEO DÕI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hành động từ buổi hồi cứu trước của bạn đã làm chưa | | | Mỗi hành động có một cái tên người kèm theo không | | | Buổi hồi cứu của bạn ra bao nhiêu hành động | ⚠ quá năm thì gần như chắc chắn không việc nào xong |

Và điều mà một buổi hồi cứu công phu nhưng không ai được giao việc thật sự tạo ra: một cảm giác rất thoả mãn rằng vấn đề đã được xử lý — và đó chính là thứ nguy hiểm nhất, vì nó khiến không ai còn thấy cần làm gì thêm.

Đáp án

D — ĐỘ TRỄ (lag).

Vì sao đúng

⚠ Vì sao đây là độ trễ: | Đặc điểm | Nội dung | |---|---| | ⚠ Đó là THỜI GIAN CHỜ BẮT BUỘC giữa hai hoạt động | ⚠ bê tông phải đông cứng trước khi dựng khung | | ⚠ Không ai LÀM VIỆC gì trong 36 giờ đó | ⚠ đó là điểm phân biệt với một hoạt động | | ⚠ Nó LÀM CHẬM hoạt động kế tiếp | ⚠ đúng nghĩa của lag | | ⚠ Nguyên nhân là quy luật vật lý, không phải lựa chọn | ⚠ phụ thuộc BẮT BUỘC — liên hệ #26465 lô 194 | | ⚠ Kết luận | ⚠ thời gian chờ chèn vào giữa hai hoạt động phụ thuộc = độ trễ |

⚠ Cách ghi trong lịch: ⚠ "Đổ bê tông → Dựng khung, quan hệ Kết thúc–Bắt đầu, độ trễ 36 giờ" ⚠ — ⚠ KHÔNG tạo một hoạt động giả tên là "chờ bê tông khô", vì hoạt động phải có người làm và tiêu tốn nguồn lực.

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

• A (ĐỘ SỚM — lead) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ lead và lag luôn được dạy cùng nhau và rất dễ đảo: ⚠ nhưng ⚠ ĐỘ SỚM là thời gian TĂNG TỐC — cho phép hoạt động sau bắt đầu TRƯỚC khi hoạt động trước kết thúc ⚠ — ví dụ bắt đầu sơn khi mới xây xong 80% tường; ⚠ mẹo nhớ: LEAD kéo lịch NGẮN LẠI, LAG đẩy lịch DÀI RA; ⚠ liên hệ #26563 lô 196 — độ sớm chính là cơ chế của fast-tracking.

• C (DỰ TRỮ — slack/float) — ⚠ là khoảng thời gian một hoạt động có thể HOÃN mà không ảnh hưởng gì; ⚠ nó là một thuộc tính TÍNH RA ĐƯỢC của lịch, không phải thứ ta chèn vào; ⚠ liên hệ #26545 lô 196.

• B ("delay") — ⚠ KHÔNG phải thuật ngữ chuẩn trong lập lịch; ⚠ trong đời thường nó nghĩa là "trễ", mang nghĩa tiêu cực; ⚠ độ trễ ở đây là thời gian chờ ĐÃ ĐƯỢC LẬP KẾ HOẠCH, hoàn toàn khác với việc bị trễ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26465 lô 194 (bốn loại phụ thuộc), ⚠ #26563 lô 196 (fast-tracking dùng độ sớm), ⚠ #26545 lô 196 (dự trữ tự do và toàn phần), ⚠ #26629 lô 197 (đường găng), ⚠ #26657 cùng lô (đổi quan hệ giữa các công việc).

⚠ ĐỘ SỚM và ĐỘ TRỄ — bảng phân biệt: | | ĐỘ SỚM (lead) | ĐỘ TRỄ (lag) | |---|---|---| | ⚠ Tác dụng lên lịch | ⚠ RÚT NGẮN | ⚠ KÉO DÀI | | ⚠ Nghĩa là | ⚠ hoạt động sau bắt đầu SỚM hơn | ⚠ hoạt động sau bắt đầu MUỘN hơn | | ⚠ Ví dụ | ⚠ bắt đầu sơn khi xây xong 80% tường | ⚠ chờ bê tông đông 36 giờ — CÂU NÀY | | ⚠ Ghi trong lịch | ⚠ FS − 3 ngày | ⚠ FS + 36 giờ | | ⚠ Rủi ro | ⚠ có thể phải làm lại nếu phần trước đổi | ⚠ không có rủi ro thêm, chỉ tốn thời gian | | ⚠ Mẹo nhớ | ⚠ LEAD nghe như "dẫn trước"; LAG nghe như "tụt lại" — và cả hai đều là CÓ CHỦ Ý, không phải sự cố | |

⚠ Vì sao KHÔNG nên tạo một "hoạt động chờ": | Lý do | Nội dung | |---|---| | ⚠ Hoạt động phải có NGƯỜI LÀM và tiêu tốn nguồn lực | ⚠ thời gian chờ thì không | | ⚠ Nó làm sai lệch báo cáo nguồn lực | ⚠ trông như có việc đang được làm | | ⚠ Nó làm sai lệch số liệu về khối lượng công việc | | | ⚠ Độ trễ là thuộc tính của QUAN HỆ, không phải của một hoạt động | | | ⚠ Ngoại lệ | ⚠ nếu thời gian chờ RẤT DÀI và cần theo dõi riêng (ví dụ chờ giấy phép sáu tháng), một số tổ chức vẫn tạo hoạt động — nhưng khi đó nên gọi đúng tên là "theo dõi giấy phép" và có người phụ trách thật |

⚠ Bốn loại QUAN HỆ giữa các hoạt động — nơi độ trễ được gắn vào: | Quan hệ | Nghĩa | Ví dụ | |---|---|---| | ⚠ Kết thúc – Bắt đầu (FS) | ⚠ A xong thì B mới bắt đầu | ⚠ phổ biến nhất; câu này là FS + 36 giờ | | ⚠ Bắt đầu – Bắt đầu (SS) | ⚠ A bắt đầu thì B mới bắt đầu | ⚠ thường dùng với độ trễ: đổ bê tông rồi 2 giờ sau bắt đầu làm phẳng | | ⚠ Kết thúc – Kết thúc (FF) | ⚠ A xong thì B mới xong được | ⚠ viết tài liệu xong thì rà soát mới xong | | ⚠ Bắt đầu – Kết thúc (SF) | ⚠ A bắt đầu thì B mới kết thúc | ⚠ rất hiếm; ca trực mới bắt đầu thì ca cũ mới kết thúc | | ⚠ Ghi nhớ | ⚠ độ sớm và độ trễ gắn được vào BẤT KỲ loại quan hệ nào — chúng là tham số của quan hệ, không phải một loại quan hệ riêng | |

⚠ Tác động của độ trễ 36 giờ lên dự án của Jerome: | Khía cạnh | Nội dung | |---|---| | ⚠ Nếu việc dựng khung nằm trên ĐƯỜNG GĂNG | ⚠ cả dự án lùi 36 giờ — liên hệ #26629 lô 197 | | ⚠ Nếu nó có dự trữ đủ lớn | ⚠ không ảnh hưởng ngày kết thúc — liên hệ #26545 lô 196 | | ⚠ Nguồn lực có thể chuyển sang việc khác trong 36 giờ đó | ⚠ đó là điều nên làm ngay | | ⚠ Độ ẩm là YẾU TỐ BÊN NGOÀI | ⚠ nên đây cũng là một rủi ro đáng ghi vào sổ cho các lần đổ bê tông sau | | ⚠ Việc Jerome nên làm | ⚠ cập nhật lịch với độ trễ, tính lại đường găng, và ghi rủi ro "thời tiết ảnh hưởng thời gian đông cứng" — vì nếu độ ẩm còn cao thì các lần đổ tiếp theo cũng sẽ trễ, và một lần là sự cố nhưng ba lần là một mô hình |

Từ khoá nhận diện:

"thời gian CHỜ bắt buộc giữa hai hoạt động" → ⚠ ĐỘ TRỄ (lag) "cho hoạt động sau bắt đầu sớm hơn" → ⚠ độ sớm (lead) "hoãn được bao lâu mà không ảnh hưởng" → ⚠ dự trữ (float/slack) "delay" → ⚠ không phải thuật ngữ lập lịch chuẩn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch của bạn có độ trễ nào được ghi rõ không | ⚠ hay được giấu trong một hoạt động "chờ" | | Các độ trễ đó có nằm trên đường găng không | | | Nguồn lực có việc gì làm trong thời gian chờ không | |

Và lý do một khái niệm nhỏ như độ trễ vẫn đáng được ghi đúng trong lịch: nó là khoảng thời gian duy nhất trong dự án mà không ai có thể làm nhanh hơn bằng nỗ lực — và nếu nó không hiện ra trên lịch, sẽ luôn có người tưởng rằng có thể.

Đáp án

B — Quản lý dự án chịu trách nhiệm BẢO ĐẢM các hiện vật dự án TRUY CẬP ĐƯỢC với mọi bên có thể cần tới chúng.

Vì sao đúng

⚠ Vì sao đây là mô tả đúng trách nhiệm: | Lý do | Nội dung | |---|---| | ⚠ Quản lý dự án KHÔNG tự tạo ra mọi hiện vật | ⚠ đội, nhà cung cấp, bên liên quan đều đóng góp | | ⚠ Nhưng chịu trách nhiệm về việc chúng ĐƯỢC LƯU và TÌM LẠI ĐƯỢC | ⚠ đó là vai trò tích hợp | | ⚠ "Mọi bên CÓ THỂ cần" gồm cả người trong tương lai | ⚠ dự án sau, kiểm toán, vận hành — liên hệ #26619 lô 197 | | ⚠ Lưu trữ là một bước của việc ĐÓNG DỰ ÁN | ⚠ liên hệ #26583 lô 197 | | ⚠ Truy cập được còn gồm cả quyền truy cập đúng người | ⚠ có kiểm soát, không phải mở cho tất cả | | ⚠ Kết luận | ⚠ trách nhiệm là về KHẢ NĂNG TIẾP CẬN, không phải về việc tự viết ra mọi thứ |

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

• D (quản lý dự án chịu trách nhiệm CẬP NHẬT mọi hiện vật) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ quản lý dự án quả thật cập nhật rất nhiều tài liệu và có trách nhiệm về tính chính xác của chúng: ⚠ nhưng ⚠ "MỌI hiện vật" là quá rộng ⚠ — ⚠ nhiều hiện vật do người khác sở hữu và cập nhật: backlog do chủ sản phẩm, tài liệu kỹ thuật do đội, hồ sơ nhà cung cấp do nhà cung cấp; ⚠ quản lý dự án bảo đảm chúng ĐƯỢC cập nhật, không phải tự tay cập nhật tất cả.

• A (chịu trách nhiệm SOẠN mọi hiện vật) — ⚠ còn rộng hơn D và càng sai; ⚠ đội và bên liên quan là người tạo ra phần lớn nội dung.

• C (chịu trách nhiệm GỬI hiện vật cập nhật cho MỌI bên liên quan) — ⚠ đẩy thông tin cho tất cả là cách làm tệ: ⚠ mỗi bên liên quan có nhu cầu khác nhau — liên hệ #26477 lô 194; ⚠ và nó biến quản lý dự án thành nút cổ chai phân phối tài liệu.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26583 lô 197 (đóng dự án — lưu trữ hồ sơ), ⚠ #26619 lô 197 (tìm tài liệu mua sắm khi đồng nghiệp đi vắng), ⚠ #26637 cùng lô (đội quản lý dự án ghi lại quyết định phạm vi), ⚠ #26543 lô 196 (người mới tiếp quản tra tài liệu), ⚠ #26661 cùng lô (sổ bài học kinh nghiệm).

⚠ LƯU TRỮ HIỆN VẬT DỰ ÁN — làm sao cho đúng: | Nguyên tắc | Nội dung | |---|---| | ⚠ Một NƠI LƯU DUY NHẤT, ai cũng biết ở đâu | ⚠ không phải thư mục cá nhân — liên hệ #26619 lô 197 | | ⚠ CẤU TRÚC thư mục chuẩn của tổ chức | ⚠ để người ngoài dự án cũng tìm được | | ⚠ Quy ước ĐẶT TÊN và ĐÁNH PHIÊN BẢN | | | ⚠ QUYỀN TRUY CẬP phù hợp | ⚠ truy cập được KHÔNG có nghĩa là ai cũng xem được mọi thứ — liên hệ #26610 lô 197 về bảo mật hợp đồng | | ⚠ Thời hạn LƯU GIỮ theo quy định | ⚠ đặc biệt với hồ sơ pháp lý và tài chính | | ⚠ Chỉ mục hoặc bản đồ tài liệu | ⚠ một trang nói rõ cái gì nằm ở đâu | | ⚠ Phép thử duy nhất có ý nghĩa | ⚠ một người hoàn toàn mới, sau ba năm, có tìm được tài liệu họ cần không — nếu câu trả lời phụ thuộc vào việc hỏi ai đó thì việc lưu trữ chưa hoàn thành |

⚠ AI SỞ HỮU hiện vật nào: | Hiện vật | Người sở hữu | |---|---| | ⚠ Điều lệ dự án | ⚠ nhà tài trợ ký, quản lý dự án soạn | | ⚠ Kế hoạch quản lý dự án và đường cơ sở | ⚠ quản lý dự án | | ⚠ Backlog sản phẩm | ⚠ CHỦ SẢN PHẨM — liên hệ #26604 lô 197 | | ⚠ Tài liệu kỹ thuật, thiết kế | ⚠ đội thực hiện | | ⚠ Hồ sơ hợp đồng và nghiệm thu | ⚠ mua sắm và quản lý dự án | | ⚠ Sổ bài học kinh nghiệm | ⚠ cả đội đóng góp — liên hệ #26661 cùng lô | | ⚠ Vai trò tích hợp của quản lý dự án | ⚠ họ không sở hữu mọi thứ nhưng chịu trách nhiệm về việc TOÀN BỘ hồ sơ đầy đủ, nhất quán và tìm lại được — đó là nghĩa của từ "tích hợp" trong lĩnh vực Quản lý tích hợp |

⚠ Vì sao việc này quan trọng hơn vẻ ngoài của nó: | Ai sẽ cần tới hồ sơ | Vì sao | |---|---| | ⚠ Dự án tương lai | ⚠ ước lượng tương tự, bài học — liên hệ #26616 lô 197 | | ⚠ Đội VẬN HÀNH | ⚠ họ phải sống cùng sản phẩm — liên hệ #26490 lô 195 | | ⚠ Kiểm toán nội bộ và bên ngoài | ⚠ có thể nhiều năm sau — liên hệ #26634 cùng lô | | ⚠ Pháp chế khi có tranh chấp | ⚠ liên hệ #26583 lô 197 | | ⚠ Người kế nhiệm quản lý dự án | ⚠ liên hệ #26543 lô 196 | | ⚠ Nhận xét | ⚠ hầu hết những người này KHÔNG có mặt lúc dự án diễn ra — nên tiêu chuẩn không phải "đội hiện tại tìm được" mà là "người chưa từng tham gia tìm được" |

Từ khoá nhận diện:

"trách nhiệm của quản lý dự án với hiện vật" → ⚠ BẢO ĐẢM TRUY CẬP ĐƯỢC với mọi bên cần "soạn mọi hiện vật" → ⚠ quá rộng, đội và bên liên quan tạo ra phần lớn "cập nhật mọi hiện vật" → ⚠ cũng quá rộng, nhiều hiện vật do người khác sở hữu "gửi cho mọi bên liên quan" → ⚠ đẩy thông tin bừa bãi, biến mình thành nút cổ chai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hồ sơ dự án của bạn lưu ở đâu | ⚠ và người ngoài đội có tìm được không | | Có tài liệu quan trọng nào chỉ nằm trên máy cá nhân không | | | Sau ba năm, ai sẽ tìm lại được chúng | |

Và điều mà Courtney nên mang theo từ bài học đầu tiên này: giá trị của một hồ sơ dự án không nằm ở việc nó đầy đủ tới đâu, mà ở việc người sẽ cần tới nó — một người mà bạn chưa từng gặp — có tìm được nó hay không.

Đáp án

C — SỔ VẤN ĐỀ (issue log).

Vì sao đúng

⚠ Vì sao đây là sổ vấn đề chứ không phải sổ rủi ro: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Thiết bị ĐÃ BỊ LỖI | ⚠ đã xảy ra, không còn là bất định | | ⚠ Nhà sản xuất ĐÃ BÁO ba tháng mới có hàng thay | ⚠ sự thật đã xác nhận | | ⚠ Đề dùng chính chữ "hiện đang có một VẤN ĐỀ" | ⚠ tín hiệu trực tiếp | | ⚠ Xác suất bằng 100% | ⚠ tiêu chí phân định rủi ro và vấn đề — liên hệ #26584 lô 197 | | ⚠ Cần có chủ sở hữu, hạn, và hành động khắc phục | ⚠ đúng cấu trúc của một mục trong sổ vấn đề | | ⚠ Kết luận | ⚠ đã xảy ra thì ghi sổ VẤN ĐỀ, không ghi sổ rủi ro |

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

• B (SỔ ĐĂNG KÝ RỦI RO) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ rất có thể rủi ro "thiết bị lỗi hoặc giao hàng chậm" ĐÃ nằm trong sổ rủi ro từ trước: ⚠ nhưng ⚠ khi rủi ro XẢY RA, nó được ĐÓNG ở sổ rủi ro và MỞ ở sổ vấn đề ⚠ — ⚠ sổ rủi ro cũng cần cập nhật, nhưng câu hỏi hỏi tài liệu nào cần cập nhật TIẾP THEO, và ưu tiên là ghi nhận vấn đề đang tồn tại; ⚠ liên hệ #26498 lô 195.

• A (sổ đăng ký BÀI HỌC KINH NGHIỆM) — ⚠ ghi điều đã HỌC ĐƯỢC sau khi xử lý; ⚠ hiện chưa có bài học nào — vấn đề còn chưa được giải quyết; ⚠ liên hệ #26661 cùng lô.

• D (KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG) — ⚠ có thể cần cập nhật về sau nếu phân tích cho thấy quy trình nghiệm thu thiết bị có lỗ hổng; ⚠ nhưng đó là bước sau — liên hệ #26556 lô 196.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26498 lô 195 (sổ vấn đề so với sổ rủi ro — bảng phân biệt đầy đủ), ⚠ #26584 lô 197 (đặc điểm của rủi ro), ⚠ #26394/#26396 lô 193 (vấn đề so với rủi ro), ⚠ #26546 lô 196 (quy trình xử lý vấn đề), ⚠ #26659 cùng lô (báo cáo rủi ro).

⚠ TRÌNH TỰ đầy đủ khi một rủi ro trở thành vấn đề: | Bước | Nội dung | |---|---| | ⚠ 1. GHI vào SỔ VẤN ĐỀ | ⚠ mô tả, mức nghiêm trọng, chủ sở hữu, hạn — ĐÁP ÁN | | ⚠ 2. ĐÓNG mục tương ứng ở sổ rủi ro | ⚠ ghi rõ nó đã xảy ra | | ⚠ 3. Kích hoạt kế hoạch ứng phó nếu đã có | ⚠ liên hệ #26628 lô 197 | | ⚠ 4. Đánh giá tác động lên tiến độ và chi phí | ⚠ ba tháng là con số rất lớn | | ⚠ 5. Tìm phương án: nhà cung cấp khác, thiết bị thay thế, đổi thứ tự công việc | ⚠ liên hệ #26657 cùng lô | | ⚠ 6. Nộp yêu cầu thay đổi nếu ảnh hưởng đường cơ sở | ⚠ liên hệ #26631 lô 197 | | ⚠ 7. Báo cáo bên liên quan | | | ⚠ 8. Ghi bài học kinh nghiệm sau khi xử lý xong | ⚠ phương án A thuộc bước này | | ⚠ Vì sao bước 1 đứng đầu | ⚠ ghi lại là điều kiện để mọi bước sau có chỗ bám — một vấn đề không được ghi sẽ được xử lý bởi bất kỳ ai nhớ tới nó, tức là thường không ai cả |

⚠ SỔ VẤN ĐỀ — mục này nên ghi gì: | Trường | Nội dung cụ thể | |---|---| | ⚠ Mô tả | ⚠ thiết bị mạng X bị lỗi; nhà sản xuất báo 3 tháng mới có hàng thay | | ⚠ Mức nghiêm trọng | ⚠ CAO — có thể chặn việc lắp đặt hạ tầng mạng | | ⚠ Chủ sở hữu | ⚠ một cái tên cụ thể | | ⚠ Hạn xử lý | | | ⚠ Hành động đang làm | ⚠ tìm nhà cung cấp thay thế, xem thiết bị tương đương | | ⚠ Tác động | ⚠ lên tiến độ, lên ngày chuyển trụ sở | | ⚠ Chi tiết đáng chú ý trong đề | ⚠ dự án có yêu cầu BẢO MẬT nghiêm ngặt — mạng công cộng không được thấy mạng nội bộ; nên thiết bị thay thế không thể chọn bừa mà phải đáp ứng đúng yêu cầu bảo mật, và điều đó thu hẹp đáng kể danh sách phương án |

⚠ Vì sao ba tháng là một vấn đề nghiêm trọng ở đây: | Lý do | Nội dung | |---|---| | ⚠ Công ty SẮP CHUYỂN tới khuôn viên mới | ⚠ có một ngày cứng không dời được | | ⚠ Hạ tầng mạng là điều kiện để mọi thứ khác hoạt động | ⚠ nhiều việc phụ thuộc vào nó | | ⚠ Rất có thể nằm trên ĐƯỜNG GĂNG | ⚠ liên hệ #26629 lô 197 | | ⚠ Yêu cầu bảo mật giới hạn phương án thay thế | | | ⚠ Việc cần làm ngay | ⚠ đánh giá xem việc này có nằm trên đường găng không — nếu có thì đây không chỉ là một mục trong sổ vấn đề mà là thứ cần leo thang lên nhà tài trợ ngay hôm nay; liên hệ #26484 lô 195 về ưu tiên vấn đề theo mức nghiêm trọng |

Từ khoá nhận diện:

"đã xảy ra, đã xác nhận" → ⚠ SỔ VẤN ĐỀ "có thể xảy ra" → ⚠ sổ đăng ký rủi ro "điều đã học được sau khi xử lý" → ⚠ sổ bài học kinh nghiệm chuyển hoá → ⚠ rủi ro XẢY RA thì đóng ở sổ rủi ro và mở ở sổ vấn đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ vấn đề của bạn có mục nào thực ra vẫn là rủi ro không | | | Mỗi vấn đề có chủ sở hữu và hạn không | | | Vấn đề nghiêm trọng nhất của bạn có nằm trên đường găng không | |

Và lý do bước đầu tiên luôn là ghi vào sổ chứ không phải đi tìm giải pháp: một vấn đề chưa được ghi lại chỉ tồn tại trong đầu người vừa nghe tin — và trong ba tháng tới sẽ có rất nhiều dịp để người đó bận đi mất.

Đáp án

D — Theo khuyến nghị của các phương pháp agile, một ĐỘI GIAO HÀNG nên gồm 12 NGƯỜI TRỞ XUỐNG.

Vì sao đúng

⚠ Vì sao đội agile được giữ nhỏ: | Lý do | Nội dung | |---|---| | ⚠ Số KÊNH GIAO TIẾP tăng theo n(n−1)/2 | ⚠ 10 người → 45 kênh; 20 người → 190 kênh — liên hệ #26294 lô 191 | | ⚠ Đội nhỏ ra quyết định nhanh hơn | ⚠ ít người phải đồng thuận | | ⚠ Ai cũng biết ai đang làm gì | ⚠ giao tiếp thẩm thấu hoạt động được | | ⚠ Trách nhiệm cá nhân rõ ràng hơn | ⚠ khó trốn trong một đội nhỏ | | ⚠ Scrum khuyến nghị 10 người trở xuống; các khung khác nói 12 | ⚠ con số hơi khác nhau, nguyên tắc thì giống | | ⚠ Kết luận | ⚠ quy mô nhỏ là một LỰA CHỌN THIẾT KẾ, không phải một hạn chế |

⚠ Với dự án LỚN thì làm sao: ⚠ KHÔNG phóng to một đội — mà chia thành NHIỀU ĐỘI NHỎ và phối hợp giữa chúng ⚠ — ⚠ đó chính là điều Mikal chưa biết, và là nội dung của các khung mở rộng quy mô như SAFe, LeSS, Nexus.

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

• A (phương pháp agile cần các vai trò RẤT CHUYÊN BIỆT) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ agile có ba vai trò được đặt tên rõ ràng, nên nghe như đề cao sự chuyên biệt: ⚠ nhưng ⚠ agile khuyến khích đội ĐA KỸ NĂNG, tức là NGƯỢC LẠI ⚠ — ⚠ thành viên nên làm được nhiều loại việc để đội không bị chặn khi một người vắng; ⚠ chính vì đa kỹ năng nên đội mới nhỏ được.

• C (mỗi phòng ban chỉ chọn một người) — ⚠ đó là cách lập đội theo cơ cấu tổ chức, không phải theo nhu cầu công việc; ⚠ và nó tạo ra một đội gồm các đại diện thay vì một đội làm việc.

• B (khó tìm người vì agile còn quá mới) — ⚠ SAI VỀ SỰ THẬT: ⚠ Tuyên ngôn Agile ra đời từ năm 2001; ⚠ và đó cũng không phải lý do quy mô đội.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26294 lô 191 (công thức số kênh giao tiếp), ⚠ #26454 lô 194 (định luật Brooks — thêm người làm chậm lại), ⚠ #26618 lô 197 (cùng chỗ và cùng chỗ ảo), ⚠ #26472 lô 194 (mở rộng quy mô quản lý dự án), ⚠ #26575 lô 196 (phối hợp giữa nhiều đội).

⚠ VÌ SAO ĐỘI NHỎ HIỆU QUẢ HƠN — bằng số: | Số người | Số kênh giao tiếp n(n−1)/2 | |---|---| | ⚠ 5 người | ⚠ 10 kênh | | ⚠ 7 người | ⚠ 21 kênh | | ⚠ 10 người | ⚠ 45 kênh | | ⚠ 15 người | ⚠ 105 kênh | | ⚠ 20 người | ⚠ 190 kênh | | ⚠ Ý nghĩa | ⚠ gấp đôi số người thì số kênh tăng gần GẤP BỐN — đó là lý do toán học đằng sau việc giữ đội nhỏ, và cũng là lý do định luật Brooks đúng: thêm người vào một đội đang trễ làm nó trễ thêm; liên hệ #26454 lô 194 |

⚠ ĐỘI ĐA KỸ NĂNG — nguyên tắc đi kèm quy mô nhỏ: | Khía cạnh | Nội dung | |---|---| | ⚠ Đội phải có ĐỦ mọi kỹ năng để giao được sản phẩm | ⚠ không phụ thuộc vào phòng ban khác cho việc thường ngày | | ⚠ Thành viên nên làm được NHIỀU loại việc | ⚠ không phải chuyên gia hẹp | | ⚠ Điều này cho phép đội nhỏ mà vẫn tự chủ | | | ⚠ Nó cũng giảm điểm hỏng đơn lẻ | ⚠ một người vắng không chặn cả đội | | ⚠ Cách xây dựng | ⚠ ghép cặp và luân phiên công việc để kỹ năng lan ra — liên hệ #26589 lô 197 và #26660 cùng lô về shadowing |

⚠ Dự án LỚN thì tổ chức thế nào: | Cách | Nội dung | |---|---| | ⚠ Chia thành NHIỀU ĐỘI NHỎ, mỗi đội tự giao được một phần giá trị | ⚠ không chia theo chuyên môn kỹ thuật | | ⚠ Phối hợp qua các cơ chế liên đội | ⚠ họp đại diện các đội, lộ trình chung | | ⚠ Quản lý PHỤ THUỘC giữa các đội | ⚠ liên hệ #26622 lô 197 | | ⚠ Dùng khung mở rộng quy mô nếu cần | ⚠ SAFe, LeSS, Nexus | | ⚠ Điều Mikal cần hiểu | ⚠ quy mô nhỏ của đội KHÔNG có nghĩa dự án nhỏ — nó có nghĩa dự án lớn được chia thành nhiều đơn vị đủ nhỏ để mỗi đơn vị còn giữ được tốc độ; đó là một quyết định về hiệu quả, không phải về nguồn lực |

Từ khoá nhận diện:

"đội agile nhỏ" → ⚠ KHUYẾN NGHỊ 12 NGƯỜI TRỞ XUỐNG "vai trò chuyên biệt" → ⚠ ngược lại — agile khuyến khích đội ĐA KỸ NĂNG "mỗi phòng ban một người" → ⚠ lập đội theo cơ cấu, không theo nhu cầu công việc "agile còn mới nên khó tìm người" → ⚠ sai sự thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có bao nhiêu người | ⚠ trên 12 thì hãy tính số kênh giao tiếp | | Đội có đủ kỹ năng để tự giao sản phẩm không | ⚠ hay phải chờ phòng ban khác | | Có việc nào chỉ một người làm được không | |

Và điều mà con số 12 thật sự bảo vệ: không phải ngân sách, mà là khả năng của một nhóm người biết được nhau đang làm gì mà không cần một cuộc họp — và khả năng đó biến mất nhanh hơn nhiều so với ta tưởng khi đội lớn lên.

Đáp án

A — DÙNG CÁC MỐI QUAN HỆ của mình để khai thông công việc.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu đề bị CỤT — nó kết thúc ở "part of him wants to utilize his contacts to" mà không có phần còn lại và không có dấu hỏi ⚠ — ⚠ vẫn trả lời được vì bối cảnh và bốn phương án đã đủ rõ; ⚠ cùng loại lỗi với #26465 lô 194 và #26437 lô 194, ⚠ tiếp tục xác nhận mật độ lỗi biên tập cao của bộ Set II.

Vì sao đúng

⚠ Vì sao Fred nên dùng quan hệ của mình: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Đội MỚI và THIẾU KINH NGHIỆM | ⚠ họ chưa có mạng lưới quan hệ trong tổ chức | | ⚠ Họ đã LÀM HẾT SỨC nhưng vẫn bị chặn | ⚠ đây không phải vấn đề nỗ lực | | ⚠ Bị chặn ở các CỬA GÁC nội bộ | ⚠ rào cản về tổ chức và quan hệ, không phải về kỹ thuật | | ⚠ Dự án đã TRỄ BA TUẦN | ⚠ không còn thời gian để đội tự học cách vượt qua | | ⚠ Fred CÓ nhà tài trợ mạnh và quan hệ với lãnh đạo | ⚠ đó chính là tài nguyên anh được giao để dùng | | ⚠ Kết luận | ⚠ GỠ VẬT CẢN cho đội là công việc trung tâm của người dẫn dắt |

⚠ Vì sao đây không phải "làm hộ": ⚠ đội không thiếu kỹ năng chuyên môn — họ thiếu QUYỀN TIẾP CẬN ⚠ — ⚠ và quyền tiếp cận là thứ không thể học được bằng cách cố gắng thêm; nó chỉ có được qua thời gian hoặc qua người đã có nó.

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

• B (để đội tự tìm cách xử lý) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ để đội tự giải quyết là cách phát triển năng lực và đúng tinh thần trao quyền: ⚠ nhưng ⚠ trao quyền chỉ có ý nghĩa khi đội CÓ KHẢ NĂNG giải quyết ⚠ — ⚠ ở đây họ đã cố và thất bại vì thiếu quan hệ, thứ không thể tự có trong ba tuần; ⚠ để họ tiếp tục vật lộn là biến việc phát triển năng lực thành sự bỏ mặc; ⚠ liên hệ #26546 lô 196 — trao quyền khác bỏ mặc.

• C (cân nhắc thay người trong đội) — ⚠ chẩn đoán hoàn toàn sai: ⚠ đề nói rõ đội làm việc chăm chỉ và cố hết sức; ⚠ vấn đề nằm ở rào cản tổ chức, không ở con người.

• D (thêm thời gian vào lịch dự án) — ⚠ chấp nhận hậu quả mà không xử lý nguyên nhân; ⚠ nếu cửa gác vẫn chặn thì thêm bao nhiêu thời gian cũng vẫn trễ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26475 lô 194 (lãnh đạo phục vụ gỡ vật cản), ⚠ #26621 lô 197 (tắc nghẽn ở phòng mua sắm), ⚠ #26489 lô 196 (các loại quyền lực), ⚠ #26622 lô 197 (scrum master làm cho vật cản hiện ra), ⚠ #26546 lô 196 (trao quyền khác bỏ mặc).

⚠ GỠ VẬT CẢN — việc trung tâm của người dẫn dắt: | Loại vật cản | Ai gỡ được | |---|---| | ⚠ Kỹ thuật trong phạm vi đội | ⚠ ĐỘI tự gỡ — đây là chỗ nên để họ tự làm | | ⚠ Thiếu thông tin từ phòng ban khác | ⚠ quản lý dự án, qua quan hệ — CÂU NÀY | | ⚠ Thiếu nguồn lực hoặc thẩm quyền | ⚠ quản lý dự án hoặc nhà tài trợ | | ⚠ Xung đột giữa các phòng ban | ⚠ nhà tài trợ hoặc lãnh đạo | | ⚠ Quy trình tổ chức gây tắc nghẽn | ⚠ cần thay đổi ở cấp tổ chức — liên hệ #26621 lô 197 | | ⚠ Nguyên tắc phân định | ⚠ để đội tự gỡ những gì họ CÓ THỂ gỡ; đích thân gỡ những gì đòi QUYỀN LỰC hoặc QUAN HỆ mà chỉ bạn có — nhầm lẫn ở đây theo cả hai chiều đều gây hại |

⚠ Fred nên làm gì cụ thể — và làm sao để đội vẫn học được: | Việc | Nội dung | |---|---| | ⚠ Dùng quan hệ để khai thông NGAY | ⚠ dự án đã trễ ba tuần, không còn thời gian | | ⚠ ĐƯA THÀNH VIÊN ĐỘI ĐI CÙNG | ⚠ để họ được giới thiệu và xây quan hệ của chính mình | | ⚠ Giải thích cho đội VÌ SAO cửa gác đó tồn tại | ⚠ hiểu hệ thống là bước đầu để tự vượt qua nó lần sau | | ⚠ Ghi vật cản vào SỔ VẤN ĐỀ | ⚠ nếu lặp lại thì đó là vấn đề quy trình cần leo thang — liên hệ #26621 lô 197 | | ⚠ Dần chuyển giao quan hệ cho đội | ⚠ mục tiêu là đội không cần anh nữa | | ⚠ Cách giải quyết trọn vẹn nhất | ⚠ anh KHÔNG phải chọn giữa "gỡ hộ" và "để đội tự học" — anh gỡ NGAY để cứu tiến độ, và mang đội theo để lần sau họ tự làm được; đó là cách một người cố vấn khác với một người làm thay |

⚠ Vì sao đội mới cần được "mượn" quan hệ: | Lý do | Nội dung | |---|---| | ⚠ Quan hệ trong tổ chức cần THỜI GIAN để xây | ⚠ không thể có trong vài tuần | | ⚠ Cửa gác thường phản ứng theo mức độ quen biết | ⚠ đó là thực tế của mọi tổ chức, không phải điều xấu | | ⚠ Người mới không biết ai thật sự ra quyết định | ⚠ liên hệ #26609 lô 197 — chính trị và cấu trúc quyền lực | | ⚠ Fred được giao nhiệm vụ KÈM CẶP họ về cách tổ chức vận hành | ⚠ đề nói rõ điều này — nên việc dẫn họ đi chính là làm đúng nhiệm vụ | | ⚠ Nhận xét | ⚠ nhiệm vụ được giao cho Fred là dạy đội cách tổ chức vận hành — và không có cách nào dạy điều đó hiệu quả hơn việc dẫn họ đi cùng khi mình gỡ một vật cản thật |

Từ khoá nhận diện:

"đội mới bị chặn ở cửa gác nội bộ, đã cố hết sức" → ⚠ DÙNG QUAN HỆ ĐỂ KHAI THÔNG "để đội tự tìm cách" → ⚠ trao quyền khi họ KHÔNG có khả năng là bỏ mặc "thay người trong đội" → ⚠ chẩn đoán sai — họ chăm chỉ, vấn đề là rào cản tổ chức "thêm thời gian" → ⚠ chấp nhận hậu quả, không xử lý nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn đang bị chặn ở đâu | ⚠ và họ có gỡ được không nếu cố thêm | | Bạn có mang đội theo khi đi gỡ vật cản không | | | Vật cản đó có lặp lại không | ⚠ lặp lại thì đó là vấn đề quy trình, cần leo thang |

Và ranh giới mà Fred đang phân vân thật ra không phải một lựa chọn nhị phân: anh có thể dùng quan hệ của mình để mở cửa hôm nay VÀ đứng cạnh khi đội bước qua nó — điều mà một người chỉ chọn một trong hai vế sẽ không bao giờ làm được.

Đáp án

A — CÓ MỘT KẾ HOẠCH QUẢN LÝ DỰ ÁN CHI TIẾT — đây là tiêu chí KHÔNG nên cân nhắc khi chọn dự án thí điểm agile.

Vì sao đúng

⚠ Vì sao tiêu chí này đi ngược mục đích thí điểm: | Lý do | Nội dung | |---|---| | ⚠ Agile KHÔNG dựa trên kế hoạch chi tiết từ đầu | ⚠ nó dùng lập kế hoạch theo làn sóng cuộn — liên hệ #26535 lô 196 | | ⚠ Một dự án đã có kế hoạch chi tiết là dự án đã cam kết theo cách DỰ ĐOÁN | ⚠ đổi sang agile giữa chừng là lãng phí công sức đã bỏ | | ⚠ Nó sẽ không cho thấy được ưu thế thật của agile | ⚠ khả năng thích ứng | | ⚠ Ba tiêu chí còn lại đều là tiêu chí THẬT của một dự án thí điểm tốt | | | ⚠ Kết luận | ⚠ câu hỏi phủ định — chọn tiêu chí thuộc về phương pháp mà thí điểm đang muốn thay thế |

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

• B (TÍNH HIỂN THỊ CAO — high visibility) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chọn một dự án được nhiều người theo dõi cho lần thí điểm đầu tiên nghe rất mạo hiểm — thất bại sẽ rất lộ: ⚠ nhưng ⚠ đó ĐÚNG LÀ một tiêu chí được khuyến nghị ⚠ — ⚠ thí điểm phải đủ nổi bật để kết quả có sức thuyết phục; một dự án không ai để ý thì dù thành công cũng không thay đổi được gì trong tổ chức; ⚠ liên hệ #26586 lô 197 — thuyết phục lãnh đạo cần bằng chứng họ nhìn thấy.

• C (NHU CẦU KINH DOANH THẬT) — ⚠ tiêu chí thật và quan trọng: ⚠ một dự án giả lập không tạo được áp lực và cam kết thật.

• D (lịch từ BA tới SÁU THÁNG) — ⚠ tiêu chí thật: ⚠ đủ dài để đi qua vài vòng lặp và thấy được xu hướng, đủ ngắn để có kết quả trước khi tổ chức mất kiên nhẫn.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26612 lô 197 (xác định việc chuyển đổi sang agile đòi hỏi gì), ⚠ #26496 lô 195 (học agile nói chung), ⚠ #26586 lô 197 (trình bày agile cho lãnh đạo), ⚠ #26510 lô 195 (chọn phương pháp theo mức bất định), ⚠ #26645 cùng lô (giáo dục bên liên quan về agile).

⚠ TIÊU CHÍ chọn dự án THÍ ĐIỂM agile: | Tiêu chí | Vì sao | |---|---| | ⚠ NHU CẦU KINH DOANH THẬT | ⚠ tạo cam kết thật từ mọi phía — phương án C | | ⚠ TÍNH HIỂN THỊ CAO | ⚠ kết quả có sức thuyết phục với tổ chức — phương án B | | ⚠ Thời lượng 3–6 THÁNG | ⚠ đủ vòng lặp để thấy xu hướng, đủ nhanh để giữ được sự chú ý — phương án D | | ⚠ Yêu cầu chưa hoàn toàn rõ, có bất định | ⚠ đúng nơi agile phát huy — liên hệ #26510 lô 195 | | ⚠ Bên liên quan SẴN SÀNG tham gia thường xuyên | ⚠ điều kiện sống còn — liên hệ #26617 lô 197 | | ⚠ Đội đủ nhỏ và có thể dành phần lớn thời gian | ⚠ liên hệ #26669 cùng lô | | ⚠ Rủi ro thất bại chấp nhận được | ⚠ không chọn dự án mà thất bại là thảm hoạ | | ⚠ Tiêu chí KHÔNG nên có | ⚠ "đã có kế hoạch chi tiết" — đó là đặc điểm của dự án dự đoán, và chọn nó cho thí điểm agile là tự đặt bẫy cho chính mình |

⚠ Vì sao TÍNH HIỂN THỊ CAO là con dao hai lưỡi nhưng vẫn đáng chọn: | Rủi ro | Lợi ích | |---|---| | ⚠ Thất bại sẽ rất lộ liễu | ⚠ thành công cũng rất thuyết phục | | ⚠ Áp lực lên đội lớn hơn | ⚠ nhưng cũng nhận được nhiều hỗ trợ hơn | | ⚠ Ít chỗ để sai | ⚠ buộc phải làm nghiêm túc | | ⚠ Cân bằng đúng | ⚠ chọn dự án ĐỦ QUAN TRỌNG để kết quả có ý nghĩa, nhưng KHÔNG PHẢI dự án mà thất bại là thảm hoạ — một dự án vô hình dù thành công cũng không thuyết phục được ai, và đó là cách phần lớn các cuộc thí điểm agile chết một cách lặng lẽ |

⚠ Bối cảnh tổ chức MỆNH LỆNH VÀ KIỂM SOÁT làm mọi thứ khó hơn: | Thách thức | Nội dung | |---|---| | ⚠ Quản lý quen ra lệnh, khó chấp nhận đội tự tổ chức | ⚠ liên hệ #26567 lô 196 — Thuyết X và Y | | ⚠ Kỳ vọng về kế hoạch chi tiết và báo cáo phần trăm | | | ⚠ Đội chưa quen tự ra quyết định | ⚠ cần thời gian và an toàn tâm lý | | ⚠ Bên liên quan chưa quen tham gia liên tục | ⚠ liên hệ #26645 cùng lô | | ⚠ Việc Matthew nên chuẩn bị | ⚠ thoả thuận TRƯỚC với lãnh đạo về cách đo thành công của thí điểm — nếu họ vẫn đo bằng "bám sát kế hoạch ban đầu" thì thí điểm sẽ bị đánh giá là thất bại ngay cả khi nó thành công theo tiêu chí agile; liên hệ #26586 lô 197 |

Từ khoá nhận diện:

"đã có kế hoạch quản lý dự án chi tiết" → ⚠ KHÔNG phải tiêu chí chọn thí điểm agile "tính hiển thị cao" → ⚠ tiêu chí THẬT — kết quả phải thuyết phục được tổ chức "nhu cầu kinh doanh thật" → ⚠ tiêu chí thật "3–6 tháng" → ⚠ tiêu chí thật — đủ dài để thấy xu hướng, đủ ngắn để giữ sự chú ý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nếu tổ chức bạn thí điểm agile, dự án nào phù hợp nhất | | | Lãnh đạo sẽ đo thành công của thí điểm bằng gì | ⚠ thoả thuận trước, không để tới lúc tổng kết | | Bên liên quan có sẵn sàng tham gia thường xuyên không | |

Và lý do một dự án đã có kế hoạch chi tiết là lựa chọn tệ nhất cho thí điểm agile: bạn sẽ dành toàn bộ thời gian để chứng minh rằng agile bám sát được một kế hoạch mà agile vốn không được thiết kế để bám sát — và dù kết quả ra sao, không ai học được điều gì đúng từ nó.

Đáp án

D — BÁO NGAY cho quản lý bộ phận dịch vụ ứng dụng rằng thông tin họ nhận được cho cuộc họp báo cáo lãnh đạo là SAI, và bạn sẽ cung cấp thông tin đúng sau khi báo cáo được cập nhật.

Vì sao đúng

⚠ Vì sao đây là hành động ưu tiên: | Lý do | Nội dung | |---|---| | ⚠ Thông tin SAI đang trên đường tới LÃNH ĐẠO CẤP CAO | ⚠ hậu quả lan ra ngoài dự án — ưu tiên cao nhất | | ⚠ Ngăn một quyết định sai dựa trên dữ liệu sai | ⚠ đó mới là rủi ro thật | | ⚠ TRUNG THỰC là nguyên tắc không thương lượng | ⚠ liên hệ #26570 lô 196 — quy tắc ứng xử PMI | | ⚠ Báo SỚM cho người sẽ trình bày | ⚠ để họ không bị bất ngờ trước lãnh đạo | | ⚠ Kèm cam kết cung cấp số đúng | ⚠ không chỉ báo tin xấu mà kèm giải pháp — liên hệ #26611 lô 197 | | ⚠ Kết luận | ⚠ chặn sai sót ở chỗ nó sắp gây hậu quả lớn nhất, càng sớm càng tốt |

⚠ Nguyên tắc ưu tiên: ⚠ khi một sai sót đang trên đường tới bên ngoài dự án, việc CHẶN nó luôn đứng trước việc TÌM HIỂU NGUYÊN NHÂN ⚠ — ⚠ cả hai đều phải làm, nhưng thứ tự quan trọng vì một trong hai có hạn chót.

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

• B (tìm hiểu thêm vì sao thành viên nhập sai dữ liệu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ tìm hiểu nguyên nhân gốc là thực hành đúng, và trong rất nhiều câu khác nó chính là đáp án: ⚠ nhưng ⚠ nó không có tính KHẨN CẤP ⚠ — ⚠ cuộc họp lãnh đạo đang tới, và mỗi phút chậm là một phút thông tin sai tiến gần hơn tới một quyết định; ⚠ việc tìm hiểu nguyên nhân là bước THỨ HAI và chắc chắn phải làm — nhưng làm sau khi đã chặn được thiệt hại.

• C (bảo đội cập nhật lại và sẽ đưa thông tin mới ở cuộc họp lãnh đạo KẾ TIẾP) — ⚠ để thông tin sai được trình bày ở cuộc họp NÀY; ⚠ chấp nhận một báo cáo sai lên lãnh đạo là điều không thể chấp nhận.

• A (nói với thành viên rằng hành vi đó không chấp nhận được) — ⚠ quy kết ngay khi chưa biết nguyên nhân; ⚠ thành viên đã CHỦ ĐỘNG tới báo — đó là hành vi đáng khuyến khích, không đáng khiển trách; ⚠ liên hệ #26597 lô 197.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26611 lô 197 (báo tin xấu kèm nguyên nhân và giải pháp), ⚠ #26518 lô 195 (thông tin ảnh hưởng lớn thì báo ngay), ⚠ #26570 lô 196 (quy tắc ứng xử PMI — trung thực), ⚠ #26484 lô 195 (ưu tiên theo mức nghiêm trọng), ⚠ #26665 cùng lô (phân tích phải dẫn tới hành động).

⚠ TRÌNH TỰ đầy đủ — cả bốn phương án đều có chỗ của nó: | Bước | Nội dung | |---|---| | ⚠ 1. BÁO NGAY cho người sắp trình bày số liệu sai | ⚠ phương án D — chặn thiệt hại lớn nhất | | ⚠ 2. Cập nhật báo cáo với số liệu đúng | ⚠ phương án C thuộc bước này | | ⚠ 3. TÌM HIỂU vì sao dữ liệu bị nhập sai | ⚠ phương án B — bước thứ hai, chắc chắn phải làm | | ⚠ 4. Sửa nguyên nhân gốc | ⚠ có thể là công cụ khó dùng, quy trình chưa rõ, hoặc thiếu đào tạo | | ⚠ 5. Ghi vào sổ vấn đề và bài học kinh nghiệm | | | ⚠ Vì sao thứ tự là vậy | ⚠ bước 1 có HẠN CHÓT do cuộc họp lãnh đạo áp đặt; các bước còn lại thì không — khi một việc có hạn và các việc khác không, việc có hạn luôn đứng trước |

⚠ Vì sao KHÔNG nên bắt đầu bằng việc quy trách nhiệm: | Lý do | Nội dung | |---|---| | ⚠ Thành viên đã CHỦ ĐỘNG tới báo sai sót | ⚠ hành vi đáng khuyến khích nhất trong mọi đội | | ⚠ Nguyên nhân có thể là hệ thống, không phải cá nhân | ⚠ công cụ khó dùng, trạng thái không rõ nghĩa, quy trình chưa được dạy | | ⚠ Phản ứng trách móc sẽ khiến lần sau không ai báo | ⚠ liên hệ #26578 lô 196 — số liệu trung thực phụ thuộc vào lòng tin | | ⚠ Và khi đó bạn mất luôn khả năng phát hiện sớm | | | ⚠ Điều nên nói với thành viên | ⚠ "cảm ơn vì đã báo — giờ ta sửa số trước đã, rồi xem vì sao nó bị nhập sai để lần sau tránh" — câu này vừa xử lý được việc, vừa giữ được người sẽ báo cho bạn lần tới |

⚠ Cách báo cho quản lý bộ phận: | Việc | Nội dung | |---|---| | ⚠ Báo NGAY, trực tiếp, không qua email | ⚠ liên hệ #26611 lô 197 — tin xấu cần kênh giàu | | ⚠ Nói rõ số nào sai và sai theo hướng nào | | | ⚠ Nêu thời điểm sẽ có số đúng | ⚠ cam kết cụ thể, không nói "sẽ sớm thôi" | | ⚠ KHÔNG nêu đích danh người nhập sai | ⚠ trình bày như một vấn đề của quy trình — liên hệ #26611 lô 197 | | ⚠ Đề nghị họ hoãn phần đó trong báo cáo nếu chưa kịp | | | ⚠ Điều quan trọng nhất | ⚠ để người quản lý bộ phận có lựa chọn — nếu họ biết trước, họ có thể điều chỉnh bài trình bày; nếu họ biết sau, họ sẽ phải đính chính trước mặt lãnh đạo, và đó là tình huống không ai muốn ở vào |

Từ khoá nhận diện:

"thông tin sai sắp lên báo cáo lãnh đạo" → ⚠ BÁO NGAY CHO NGƯỜI SẮP TRÌNH BÀY "tìm hiểu vì sao nhập sai" → ⚠ đúng và cần thiết, nhưng là bước THỨ HAI "sẽ sửa ở cuộc họp kế tiếp" → ⚠ chấp nhận để thông tin sai lên lãnh đạo lần này "nói hành vi đó không chấp nhận được" → ⚠ quy kết khi chưa biết nguyên nhân, và trừng phạt người vừa báo tin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số liệu báo cáo của bạn có được kiểm chứng trước khi lên cấp trên không | | | Khi ai đó báo sai sót của chính họ, phản ứng đầu tiên của bạn là gì | | | Công cụ ghi nhận tiến độ của bạn có dễ nhập đúng không | ⚠ rất nhiều dữ liệu sai bắt nguồn từ một giao diện khó hiểu |

Và điều đáng ghi nhận nhất trong tình huống này lại nằm ở chỗ ít ai để ý: một thành viên đã tự tìm tới để nói rằng số liệu của chính mình sai — và cách bạn phản ứng trong năm phút tới sẽ quyết định liệu người tiếp theo có làm như vậy hay không.