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

Đáp án

D — TÀI SẢN QUY TRÌNH TỔ CHỨC (Organizational Process Assets).

Vì sao đúng

⚠ Vì sao tài sản quy trình là nguồn chính: | Lý do | Nội dung | |---|---| | ⚠ Tổ chức thường ĐÃ CÓ bộ quy tắc ứng xử | ⚠ Samantha điều chỉnh cho dự án, không viết lại từ đầu | | ⚠ Tài sản quy trình gồm chính sách, mẫu tài liệu, hướng dẫn | ⚠ đúng loại thứ cần cho việc này | | ⚠ Bảo đảm NHẤT QUÁN với phần còn lại của tổ chức | ⚠ một dự án không nên có bộ giá trị riêng trái với tổ chức | | ⚠ Dự án phi lợi nhuận quốc tế | ⚠ các tổ chức loại này gần như luôn có quy tắc ứng xử sẵn | | ⚠ Bài học từ các dự án trước cũng nằm ở đây | ⚠ liên hệ #26511 lô 195 | | ⚠ Kết luận | ⚠ dùng lại thứ tổ chức đã có, thay vì đi tìm nguồn bên ngoài |

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

• B (YẾU TỐ MÔI TRƯỜNG DOANH NGHIỆP — EEF) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ văn hoá tổ chức, luật pháp và chuẩn mực ngành ĐỀU ảnh hưởng tới bộ quy tắc ứng xử, nên nó không sai hoàn toàn: ⚠ nhưng ⚠ EEF là ĐIỀU KIỆN dự án phải chịu, còn OPA là THỨ DÙNG ĐƯỢC ⚠ — Samantha cần một mẫu và một chính sách để dựa vào, và đó là tài sản quy trình; ⚠ câu hỏi phân định: cái này GIỚI HẠN tôi hay GIÚP tôi? — giúp thì OPA; ⚠ liên hệ #26511 lô 195.

• A (bệnh viện thú y địa phương chuyên về bệnh hiếm) — ⚠ nguồn chuyên môn KỸ THUẬT về nội dung dự án, không phải về quy tắc ứng xử.

• C (một hội bảo vệ động vật địa phương) — ⚠ cũng là nguồn bên ngoài và chỉ mang tính địa phương; ⚠ dự án của Samantha là quốc tế.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26511 lô 195 (WBS không phải tài sản quy trình — bảng phân biệt OPA và EEF), ⚠ #26487 lô 195 (thoả ước lao động là EEF), ⚠ #26593 cùng lô (tri thức cấp dự án), ⚠ #26570 lô 196 (tài liệu tuân thủ về ứng xử), ⚠ #26582 lô 196 (quản trị dự án).

⚠ TÀI SẢN QUY TRÌNH và YẾU TỐ MÔI TRƯỜNG — bảng chốt: | | Tài sản quy trình (OPA) | Yếu tố môi trường (EEF) | |---|---|---| | ⚠ Bản chất | ⚠ thứ dự án DÙNG ĐƯỢC | ⚠ điều kiện dự án PHẢI CHỊU | | ⚠ Ví dụ | ⚠ mẫu tài liệu, quy trình, chính sách, bài học, CSDL lịch sử | ⚠ luật, văn hoá tổ chức, điều kiện thị trường, hạ tầng, PMIS | | ⚠ Đổi được không | ⚠ có thể bổ sung và cải tiến | ⚠ thường không | | ⚠ Với câu này | ⚠ quy tắc ứng xử của tổ chức, mẫu tài liệu — ĐÁP ÁN | ⚠ luật pháp các nước, chuẩn mực văn hoá | | ⚠ Câu hỏi phân định | ⚠ "cái này GIÚP tôi hay GIỚI HẠN tôi?" | |

⚠ BỘ QUY TẮC ỨNG XỬ của dự án nên có gì: | Nội dung | Chi tiết | |---|---| | ⚠ Giá trị cốt lõi và chuẩn mực hành vi | ⚠ trung thực, tôn trọng, công bằng, trách nhiệm — bốn giá trị của PMI | | ⚠ Quy định về xung đột lợi ích | ⚠ đặc biệt quan trọng với tổ chức phi lợi nhuận nhận tài trợ | | ⚠ Quy định về quà tặng và tiếp đãi | | | ⚠ Cách xử lý bất đồng và khiếu nại | ⚠ liên hệ #26570 lô 196 | | ⚠ Tôn trọng khác biệt văn hoá | ⚠ liên hệ #26316 lô 191 — dự án quốc tế | | ⚠ Bảo mật thông tin | | | ⚠ Nguồn để dựng | ⚠ quy tắc ứng xử của TỔ CHỨC (OPA) là nền, cộng với Quy tắc Đạo đức và Ứng xử Nghề nghiệp của PMI, rồi điều chỉnh cho bối cảnh cụ thể — không ai nên viết một bộ quy tắc ứng xử từ trang trắng |

⚠ Vì sao dự án QUỐC TẾ cần bộ quy tắc rõ ràng hơn: | Lý do | Nội dung | |---|---| | ⚠ Chuẩn mực hành vi khác nhau giữa các nền văn hoá | ⚠ điều bình thường ở nơi này có thể không chấp nhận được ở nơi khác | | ⚠ Khung pháp lý khác nhau giữa các nước | | | ⚠ Chuyên gia đến từ nhiều tổ chức khác nhau | ⚠ mỗi người mang theo chuẩn mực của nơi mình | | ⚠ Tổ chức phi lợi nhuận chịu giám sát cao về minh bạch | ⚠ nhà tài trợ và công chúng đều theo dõi | | ⚠ Điều quan trọng nhất khi soạn | ⚠ viết ra những thứ tưởng là hiển nhiên — vì "hiển nhiên" là khái niệm phụ thuộc hoàn toàn vào nơi người ta lớn lên |

Từ khoá nhận diện:

"dựng quy tắc ứng xử cho dự án" → ⚠ TÀI SẢN QUY TRÌNH TỔ CHỨC "yếu tố môi trường doanh nghiệp" → ⚠ điều kiện phải chịu, không phải thứ dùng được "chuyên gia bên ngoài về nội dung dự án" → ⚠ nguồn chuyên môn kỹ thuật, không phải về ứng xử câu hỏi phân định OPA và EEF → ⚠ giúp tôi hay giới hạn tôi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có bộ quy tắc ứng xử không, và đội bạn có đọc chưa | | | Dự án bạn có quy định gì về xung đột lợi ích không | | | Với đội đa văn hoá, bạn có viết ra những chuẩn mực "hiển nhiên" không | |

Và lý do việc bắt đầu từ tài sản của tổ chức luôn tốt hơn việc tự viết: một bộ quy tắc ứng xử riêng cho dự án mà khác với của tổ chức sẽ đặt mọi người vào thế phải chọn giữa hai bộ luật — và đó là tình huống tệ hơn cả việc không có bộ nào.

Đáp án

B — CHỈ bên liên quan sang CHỦ SẢN PHẨM để thêm các hạng mục đó.

Vì sao đúng

⚠ Vì sao đây là hành động đúng của scrum master: | Lý do | Nội dung | |---|---| | ⚠ CHỦ SẢN PHẨM sở hữu backlog | ⚠ chỉ họ mới quyết thêm gì và theo thứ tự nào | | ⚠ Scrum master KHÔNG quyết nội dung sản phẩm | ⚠ anh lo TIẾN TRÌNH, không lo nội dung | | ⚠ Chỉ đúng người giữ được vai trò rõ ràng cho cả đội | ⚠ liên hệ #26569 lô 196 — ai quyết cái gì | | ⚠ Bên liên quan học được kênh đúng cho lần sau | ⚠ liên hệ #26514 lô 195 — chỉ tới nguồn thay vì trả lời thay | | ⚠ Yêu cầu vẫn được xử lý, không bị bỏ | | | ⚠ Kết luận | ⚠ định tuyến đúng người, không tự nhận việc của người khác |

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

• D (làm việc với bên liên quan để hiểu nhu cầu đằng sau và cách nó đóng góp cho dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ tìm hiểu nhu cầu gốc là một thực hành xuất sắc, và trong nhiều câu hỏi khác nó chính là đáp án: ⚠ nhưng ⚠ đó là việc của CHỦ SẢN PHẨM ⚠ — người sở hữu giá trị sản phẩm; ⚠ scrum master làm việc đó là lấn sang vai trò khác, và tạo ra một kênh song song khiến bên liên quan lần sau lại tới gặp anh; ⚠ Sterling có thể GIÚP tổ chức cuộc trò chuyện đó, nhưng người dẫn phải là chủ sản phẩm.

• C (hỏi đội xem họ thấy các câu chuyện đó có hữu ích không) — ⚠ đội quyết CÁCH LÀM, không quyết LÀM GÌ; ⚠ liên hệ #26542 lô 196.

• A (nói rằng dự án đã bắt đầu nên không thêm việc được) — ⚠ TRÁI với bản chất agile: ⚠ backlog vốn để tiến hoá; ⚠ và yêu cầu này rất có giá trị — cho phép khách hàng thanh toán trực tuyến.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26569 lô 196 (ai quyết cái gì trong agile), ⚠ #26542 lô 196 (chủ sản phẩm thương lượng với đội), ⚠ #26514 lô 195 (scrum master chỉ tới nguồn), ⚠ #26490 lô 195 (định nghĩa hoàn thành), ⚠ #26608 cùng lô (bên liên quan không thuyết phục được chủ sản phẩm).

⚠ VAI TRÒ trong Scrum — ai làm gì với backlog: | Vai trò | Với backlog sản phẩm | |---|---| | ⚠ CHỦ SẢN PHẨM | ⚠ SỞ HỮU: quyết nội dung, thứ tự, và quyết cả việc từ chối | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ ước lượng, làm rõ, chọn bao nhiêu việc cho sprint | | ⚠ SCRUM MASTER | ⚠ bảo đảm backlog rõ ràng và quy trình được tôn trọng — KHÔNG quyết nội dung | | ⚠ BÊN LIÊN QUAN | ⚠ ĐỀ XUẤT, thuyết phục chủ sản phẩm — không tự thêm | | ⚠ Vì sao ranh giới này quan trọng | ⚠ nếu ai cũng thêm được vào backlog thì nó không còn là một danh sách có thứ tự ưu tiên — nó thành một hộp thư; và một backlog không có người sở hữu duy nhất sẽ nhanh chóng trở thành thứ không ai tin |

⚠ Việc Sterling NÊN làm ngoài việc chỉ đường: | Việc | Nội dung | |---|---| | ⚠ GIỚI THIỆU trực tiếp, không chỉ nói "anh gặp chị X" | ⚠ giảm ma sát cho bên liên quan | | ⚠ Giải thích quy trình backlog hoạt động ra sao | ⚠ để lần sau họ tự đi đúng đường | | ⚠ Đề nghị tổ chức buổi làm rõ nếu cần | ⚠ đó là vai trò TIẾN TRÌNH, hoàn toàn phù hợp | | ⚠ Bảo đảm yêu cầu không bị rơi mất | ⚠ theo dõi cho tới khi nó vào backlog hoặc bị từ chối có lý do | | ⚠ Ranh giới cần giữ | ⚠ Sterling GIÚP cuộc trò chuyện xảy ra, nhưng không THAY chủ sản phẩm nói chuyện — khác biệt này quyết định vai trò của anh có bền vững hay không |

⚠ Vì sao yêu cầu này đáng được xử lý nghiêm túc: | Khía cạnh | Nội dung | |---|---| | ⚠ Cho phép khách hàng thanh toán trực tuyến | ⚠ giá trị kinh doanh rõ ràng | | ⚠ Đến từ một bên liên quan, tức là có nhu cầu thật | | | ⚠ Backlog vốn được thiết kế để đón những yêu cầu như thế | ⚠ đó là ưu thế của agile so với phạm vi chốt cứng | | ⚠ Nhưng | ⚠ "đưa vào backlog" KHÔNG có nghĩa là "sẽ làm" — nó nghĩa là sẽ được xếp ưu tiên cùng mọi thứ khác; đó chính là lý do việc này phải qua chủ sản phẩm, người duy nhất nhìn được toàn bộ bức tranh giá trị |

Từ khoá nhận diện:

"bên liên quan xin thêm hạng mục vào backlog" → ⚠ CHỈ SANG CHỦ SẢN PHẨM "scrum master tự tìm hiểu nhu cầu" → ⚠ lấn vai trò của chủ sản phẩm "hỏi đội xem có hữu ích không" → ⚠ đội quyết CÁCH LÀM, không quyết LÀM GÌ "dự án đã bắt đầu nên không thêm được" → ⚠ trái bản chất agile

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ở dự án bạn, ai được thêm việc vào backlog | ⚠ nhiều hơn một người là dấu hiệu vấn đề | | Bên liên quan có biết kênh đúng để đề xuất không | | | Yêu cầu bị từ chối có được trả lời kèm lý do không | ⚠ không trả lời thì lần sau họ sẽ đi đường vòng |

Và lý do một scrum master tốt hay nói "để tôi giới thiệu anh với chị ấy" thay vì tự giải quyết: mỗi lần anh ta xử lý thay một việc không thuộc vai trò mình, anh ta vừa giúp được một người vừa làm mờ đi một ranh giới mà cả đội đang dựa vào để biết phải hỏi ai.

Đáp án

D — TRI THỨC ẨN (tacit knowledge).

⚠ Đối chiếu — họ câu về QUẢN LÝ TRI THỨC nay đã bốn câu, chú ý ĐỀ HỎI TRỤC NÀO: ⚠ #26455 lô 194 (ẩn) và #26458 lô 194 (hiện) hỏi DẠNG THỨC; #26555 lô 196 và #26593 cùng lô hỏi CẤP ĐỘ (cấp dự án) ⚠ — ⚠ câu này hỏi "LOẠI tri thức", tức là hỏi DẠNG THỨC, nên đáp án nằm ở trục ẩn/hiện; ⚠ bốn khoá hoàn toàn nhất quán, chỉ khác trục phân loại mà đề hỏi.

Vì sao đúng

⚠ Vì sao đây là tri thức ẩn: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Wesley muốn mọi người CHIA SẺ KINH NGHIỆM của mình | ⚠ kinh nghiệm cá nhân là tri thức ẩn điển hình | | ⚠ Anh cần GẶP TRỰC TIẾP mới làm được | ⚠ tri thức ẩn cần tương tác, không truyền qua tài liệu | | ⚠ Anh phải XÂY LÒNG TIN trước | ⚠ người ta chỉ chia sẻ kinh nghiệm khi thấy an toàn — dấu hiệu mạnh nhất của tri thức ẩn | | ⚠ Các buổi Zoom trước KHÔNG làm được điều này | ⚠ băng thông thấp hơn, khó xây lòng tin hơn | | ⚠ Đề nói mỗi người đều có kinh nghiệm LIÊN QUAN | ⚠ tri thức đang nằm rải trong đầu từng người | | ⚠ Kết luận | ⚠ thứ Wesley đang tìm cách khơi ra không nằm trong bất kỳ tệp tin nào |

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

• C (TRI THỨC HIỆN) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đây là vế còn lại của cùng một cặp phân loại, nên luôn là lựa chọn cuối cùng phải cân nhắc: ⚠ nhưng ⚠ tri thức hiện là thứ ĐÃ ĐƯỢC MÃ HOÁ thành tài liệu và truyền được qua email ⚠ — nếu là tri thức hiện thì Wesley chỉ cần gửi tệp, không cần bay tới gặp nhau và không cần xây lòng tin; ⚠ so sánh trực tiếp với #26458 lô 194, nơi Otto gửi trước chương trình họp và mô hình 3D — đó mới là tri thức hiện.

• A (tri thức TỔ CHỨC) — ⚠ là phân loại theo PHẠM VI, không phải theo DẠNG THỨC; ⚠ lạc trục.

• B (tri thức DỰ ÁN) — ⚠ cũng theo phạm vi; ⚠ đúng cấp độ của tình huống nhưng sai trục với câu hỏi — đề hỏi "LOẠI tri thức nào", tức hỏi dạng thức.

⚠ Kỹ thuật làm bài cho họ câu này: ⚠ đọc kỹ đề hỏi "CẤP ĐỘ" hay "LOẠI/DẠNG" ⚠ — ⚠ hỏi CẤP ĐỘ thì chọn trong cá nhân / dự án / tổ chức; ⚠ hỏi LOẠI hoặc DẠNG THỨC thì chọn trong ẩn / hiện; ⚠ hai phương án lạc trục luôn có mặt để bẫy người không đọc kỹ động từ của câu hỏi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26455/#26458 lô 194 (cặp câu ẩn và hiện), ⚠ #26555 lô 196 và ⚠ #26593 cùng lô (cấp độ tri thức), ⚠ #26588 cùng lô (cố vấn truyền tri thức ẩn), ⚠ #26589 cùng lô (ghép cặp để chuyển giao tri thức ẩn).

⚠ TRI THỨC ẨN và TRI THỨC HIỆN — bảng chốt: | | Tri thức ẩn (tacit) | Tri thức hiện (explicit) | |---|---|---| | ⚠ Nằm ở đâu | ⚠ trong ĐẦU người | ⚠ trong TÀI LIỆU | | ⚠ Gồm gì | ⚠ kinh nghiệm, trực giác, phán đoán, hiểu biết về con người | ⚠ số liệu, quy trình, chính sách, bản vẽ | | ⚠ Chuyển giao bằng | ⚠ trò chuyện, làm cùng, kèm cặp, ghép cặp | ⚠ đọc, tra cứu, sao chép tệp | | ⚠ Điều kiện tiên quyết | ⚠ LÒNG TIN — người ta phải muốn chia sẻ | ⚠ chỉ cần quyền truy cập | | ⚠ Mất khi nào | ⚠ khi người đó rời tổ chức | ⚠ khi không ai cập nhật | | ⚠ Trong câu này | ⚠ kinh nghiệm của từng thành viên — ĐÁP ÁN | ⚠ tài liệu dự án Wesley đã gửi qua Zoom |

⚠ Vì sao Wesley cần GẶP TRỰC TIẾP mới khơi được tri thức ẩn: | Lý do | Nội dung | |---|---| | ⚠ Lòng tin xây nhanh hơn nhiều khi gặp mặt | ⚠ liên hệ #26554 lô 196 | | ⚠ Có cận ngôn ngữ và phi ngôn ngữ đầy đủ | ⚠ liên hệ #26505 lô 195 | | ⚠ Trò chuyện bên lề mới là nơi kinh nghiệm được kể ra | ⚠ không phải trong phần chính thức của buổi họp | | ⚠ Người ta ngại kể chuyện của mình trước một màn hình đầy ô vuông | | | ⚠ Lời khuyên thực dụng | ⚠ với đội phân tán, một lần gặp mặt ở đầu dự án là khoản đầu tư có tỉ suất cao nhất — nó tạo ra vốn lòng tin đủ dùng cho nhiều tháng làm việc từ xa sau đó |

⚠ Cách khơi tri thức ẩn trong buổi gặp: | Cách | Nội dung | |---|---| | ⚠ Hỏi về TÌNH HUỐNG CỤ THỂ đã trải qua | ⚠ "lần trước gặp việc tương tự, điều gì làm anh bất ngờ nhất?" | | ⚠ Kể chuyện thay vì trình bày | ⚠ câu chuyện chở được ngữ cảnh, danh sách gạch đầu dòng thì không | | ⚠ Người dẫn dắt kể trước, kể cả thất bại của mình | ⚠ làm gương về sự cởi mở | | ⚠ Nhóm nhỏ trước, cả nhóm sau | ⚠ liên hệ #26600 cùng lô | | ⚠ GHI LẠI những gì nghe được | ⚠ biến một phần tri thức ẩn thành hiện — đó là mục đích cuối cùng | | ⚠ Điều không nên làm | ⚠ yêu cầu mọi người "viết ra kinh nghiệm của mình" — họ sẽ viết ra những điều chung chung, vì tri thức ẩn không tự chuyển thành câu chữ theo yêu cầu |

Từ khoá nhận diện:

"chia sẻ kinh nghiệm, cần lòng tin, cần gặp trực tiếp" → ⚠ TRI THỨC ẨN "tài liệu, slide, mô hình gửi trước" → ⚠ tri thức hiện — #26458 lô 194 "tri thức tổ chức / dự án" → ⚠ phân loại theo PHẠM VI, lạc trục nếu đề hỏi LOẠI mẹo đọc đề → ⚠ hỏi CẤP ĐỘ hay hỏi LOẠI — hai trục hoàn toàn khác nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có dịp nào để kể chuyện nghề cho nhau không | | | Bạn có ghi lại những gì nghe được không | ⚠ đó là cách duy nhất tri thức ẩn không biến mất cùng con người | | Nếu đội bạn chỉ gặp nhau qua màn hình, ai là người ít được nghe nhất | |

Và điều mà Wesley hiểu đúng khi tổ chức buổi gặp trực tiếp đầu tiên: kinh nghiệm quý nhất trong đội anh không nằm ở chỗ nào để lấy ra — nó nằm trong đầu những người chỉ kể nó ra khi họ tin rằng người nghe sẽ không dùng nó để đánh giá mình.

Đáp án

C — QUẢN LÝ RỦI RO (managing risk).

Vì sao đúng

⚠ Vì sao khoảng trống thật là quản lý rủi ro: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Các bản phát hành THẤT BẠI vì "rủi ro CHƯA TỪNG BIẾT" | ⚠ đề nói thẳng: vấn đề nằm ở việc không NHẬN DIỆN được rủi ro trước | | ⚠ Mỗi lần thất bại vì một LÝ DO KHÁC | ⚠ nên danh sách kiểm không giải quyết được — nó chỉ chặn thứ đã từng xảy ra | | ⚠ Owen chỉ GHI LẠI sau sự việc rồi đưa vào danh sách kiểm | ⚠ phản ứng, không phòng ngừa | | ⚠ Đội rất giỏi tài liệu và bảo đảm chất lượng | ⚠ nên đây KHÔNG phải khoảng trống về chất lượng | | ⚠ Không ai NHẬN DIỆN rủi ro TRƯỚC khi nó xảy ra | ⚠ đó là năng lực còn thiếu | | ⚠ Kết luận | ⚠ danh sách kiểm nhìn về QUÁ KHỨ; quản lý rủi ro nhìn về TƯƠNG LAI |

⚠ Điểm mấu chốt: ⚠ một danh sách kiểm chỉ chứa những thứ ĐÃ TỪNG HỎNG ⚠ — ⚠ nó không bao giờ bắt được một rủi ro chưa từng xảy ra lần nào, và đó chính xác là loại rủi ro đang giết chết các bản phát hành của Owen.

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

• B (QUẢN LÝ CHẤT LƯỢNG) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chính nhân viên đã XIN đào tạo về bảo đảm chất lượng, nên nó có vẻ là câu trả lời hiển nhiên: ⚠ nhưng ⚠ đề nói rõ đội "XUẤT SẮC về tài liệu và bảo đảm chất lượng" ⚠ — ⚠ họ không thiếu năng lực chất lượng, họ thiếu năng lực nhìn trước; ⚠ đây là bẫy kinh điển: nhân viên tự chẩn đoán sai, và người quản lý giỏi phải nhận ra triệu chứng không trùng với nguyên nhân.

• A (quản lý bên liên quan) — ⚠ đề không mô tả vấn đề nào với bên liên quan.

• D (quản lý chi phí) — ⚠ cũng không được nhắc tới; ⚠ thất bại ở đây là về kỹ thuật và phát hành, không về ngân sách.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26493 lô 195 (rủi ro phải rà soát liên tục), ⚠ #26551 lô 196 (tác nhân kích hoạt), ⚠ #26584 cùng lô (đặc điểm của rủi ro — hướng về tương lai), ⚠ #26602 cùng lô (đầu ra của giám sát rủi ro), ⚠ #26525 lô 195 (chi phí chất lượng).

⚠ DANH SÁCH KIỂM và QUẢN LÝ RỦI RO — vì sao không thay thế nhau: | | Danh sách kiểm | Quản lý rủi ro | |---|---|---| | ⚠ Nhìn về | ⚠ QUÁ KHỨ — những gì đã từng hỏng | ⚠ TƯƠNG LAI — những gì CÓ THỂ hỏng | | ⚠ Bắt được | ⚠ lỗi lặp lại | ⚠ cả lỗi chưa từng xảy ra | | ⚠ Cách xây | ⚠ tích luỹ từ sự cố | ⚠ động não, phỏng vấn, phân tích có cấu trúc | | ⚠ Điểm mù | ⚠ mọi thứ mới — đúng vấn đề của Owen | ⚠ vẫn có, nhưng nhỏ hơn nhiều | | ⚠ Xu hướng theo thời gian | ⚠ DÀI RA MÃI, và ngày càng ít người đọc kỹ | ⚠ được rà soát và làm mới liên tục | | ⚠ Nhận xét | ⚠ danh sách kiểm rất hữu ích và không nên bỏ — nhưng nó là công cụ CHẤT LƯỢNG, không phải công cụ RỦI RO; nhầm hai thứ này là đúng sai lầm mà Owen đang mắc | |

⚠ Đội của Owen nên học gì cụ thể: | Kỹ năng | Nội dung | |---|---| | ⚠ NHẬN DIỆN rủi ro có cấu trúc | ⚠ động não, Delphi, phỏng vấn, phân tích giả định, SWOT — liên hệ #26406 lô 193 | | ⚠ Dùng CẤU TRÚC PHÂN RÃ RỦI RO | ⚠ rà theo từng nhóm nguồn gốc để không bỏ sót cả một loại — liên hệ #26584 cùng lô | | ⚠ Phân tích ĐỊNH TÍNH và ĐỊNH LƯỢNG | ⚠ liên hệ #26516 lô 195 và #26607 cùng lô | | ⚠ Đặt TÁC NHÂN KÍCH HOẠT | ⚠ liên hệ #26551 lô 196 | | ⚠ RÀ SOÁT rủi ro định kỳ, không chỉ ở đầu dự án | ⚠ liên hệ #26493 lô 195 | | ⚠ Phân tích GIẢ ĐỊNH | ⚠ rất nhiều "rủi ro chưa biết" thực ra là một giả định chưa ai kiểm chứng | | ⚠ Việc rẻ nhất và hiệu quả nhất để bắt đầu | ⚠ một buổi PHÂN TÍCH TIỀN TỬ THI (pre-mortem): tưởng tượng bản phát hành tới đã thất bại và hỏi "vì sao?" — kỹ thuật này khơi ra được đúng loại rủi ro mà danh sách kiểm không bao giờ chứa |

⚠ Vì sao danh sách kiểm quá dài lại là một dấu hiệu xấu: | Vấn đề | Nội dung | |---|---| | ⚠ Tốn nhiều thời gian rà soát | ⚠ đề nói rõ điều này | | ⚠ Người ta bắt đầu tích cho xong | ⚠ danh sách càng dài, mức độ chú ý cho mỗi mục càng giảm | | ⚠ Nó tạo CẢM GIÁC AN TOÀN SAI | ⚠ "đã rà hết danh sách" nghe như đã kiểm soát mọi thứ | | ⚠ Nó không bao giờ chứa thứ sắp làm hỏng lần sau | | | ⚠ Cách chữa | ⚠ rút gọn danh sách kiểm về những mục thật sự quan trọng, và BỔ SUNG một buổi nhận diện rủi ro cho mỗi chu kỳ — kiểm tra quá khứ và dự đoán tương lai là hai việc khác nhau, cần hai công cụ khác nhau |

Từ khoá nhận diện:

"thất bại vì rủi ro chưa từng biết, mỗi lần một lý do khác" → ⚠ thiếu năng lực QUẢN LÝ RỦI RO "đội xuất sắc về chất lượng và tài liệu" → ⚠ loại bỏ phương án chất lượng "danh sách kiểm ngày càng dài" → ⚠ công cụ nhìn về quá khứ, không bắt được cái mới nhân viên tự xin đào tạo về X → ⚠ kiểm lại xem X có đúng là khoảng trống thật không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sự cố gần nhất của bạn có nằm trong danh sách kiểm không | ⚠ nếu không, danh sách kiểm không phải công cụ bạn cần | | Bạn có buổi nhận diện rủi ro nào cho mỗi chu kỳ không | | | Danh sách kiểm của bạn dài bao nhiêu, và có ai đọc hết không | |

Và bài học mà Owen chưa rút ra sau ba lần thất bại liên tiếp: anh đang xây một danh sách rất công phu về những cách mà dự án đã từng hỏng — trong khi thứ làm hỏng bản phát hành tới sẽ là một cách chưa ai từng nghĩ tới, và không có bao nhiêu dòng trong danh sách đó thay đổi được điều ấy.

Đáp án

B — GIẢM NHẸ (mitigate).

Vì sao đúng

⚠ Vì sao giảm nhẹ là chiến lược phù hợp: | Yếu tố | Số liệu và ý nghĩa | |---|---| | ⚠ Xác suất 0,80 | ⚠ RẤT CAO — gần như chắc chắn xảy ra | | ⚠ Tác động 54.000 đô | ⚠ trên ngân sách 125.000 đô, tức là hơn 43% ngân sách | | ⚠ Giá trị tiền tệ kỳ vọng: 0,80 × 54.000 | ⚠ 43.200 đô — chiếm 34,6% ngân sách dự án | | ⚠ Đề nói rõ: xác suất cao VÀ tác động nghiêm trọng | ⚠ ô nguy hiểm nhất trên ma trận | | ⚠ Không thể CHẤP NHẬN với mức phơi nhiễm này | | | ⚠ Giảm nhẹ hạ được xác suất hoặc tác động | ⚠ chiến lược khả thi và chủ động nhất | | ⚠ Kết luận | ⚠ rủi ro lớn thì phải hành động, và giảm nhẹ là hành động trong tầm tay dự án |

⚠ Số học đáng nhớ: ⚠ 43.200 trên 125.000 nghĩa là hơn một phần ba ngân sách đang bị đe doạ bởi MỘT rủi ro duy nhất ⚠ — ⚠ với mức đó, việc bỏ tiền để giảm nhẹ gần như chắc chắn có lãi.

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

• C (CHUYỂN GIAO — transfer) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chuyển giao cũng là chiến lược cho rủi ro lớn, và bảo hiểm là cách xử lý hợp lệ: ⚠ nhưng ⚠ chuyển giao chỉ khả thi khi có bên thứ ba SẴN SÀNG nhận ⚠ — với rủi ro xác suất 0,80, không công ty bảo hiểm nào nhận với giá hợp lý, và không nhà thầu nào ký hợp đồng gánh nó; ⚠ chuyển giao hợp với rủi ro XÁC SUẤT THẤP – TÁC ĐỘNG LỚN, ngược hẳn với tình huống này.

• A (CHẤP NHẬN) — ⚠ hoàn toàn không phù hợp với mức phơi nhiễm 34,6% ngân sách; ⚠ chấp nhận dành cho rủi ro nhỏ — liên hệ #26545 lô 196.

• D (HUỶ dự án Sky) — ⚠ phản ứng cực đoan; ⚠ và không phải thẩm quyền của scrum master — liên hệ #26585 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26494 lô 195 (né tránh — bảng năm chiến lược), ⚠ #26545 lô 196 (chấp nhận khi rủi ro nhỏ), ⚠ #26547 lô 196 (chiến lược cho cơ hội), ⚠ #26548 lô 196 (EMV và dự phòng), ⚠ #26516 lô 195 (phân tích định tính).

⚠ CHỌN CHIẾN LƯỢC theo XÁC SUẤT và TÁC ĐỘNG: | | Tác động THẤP | Tác động CAO | |---|---|---| | ⚠ Xác suất THẤP | ⚠ CHẤP NHẬN — danh sách theo dõi | ⚠ CHUYỂN GIAO — bảo hiểm hợp lý về giá | | ⚠ Xác suất CAO | ⚠ GIẢM NHẸ nhẹ nhàng, hoặc chấp nhận có dự phòng | ⚠ GIẢM NHẸ mạnh, hoặc NÉ TRÁNH — CÂU NÀY | | ⚠ Vì sao chuyển giao không hợp với ô góc dưới bên phải | ⚠ bên nhận rủi ro cũng tính toán — họ sẽ đòi phí gần bằng chính tác động, nên chuyển giao mất ý nghĩa kinh tế | | | ⚠ Khi nào chọn NÉ TRÁNH thay vì giảm nhẹ | ⚠ khi có thể đổi kế hoạch để loại bỏ HẲN nguyên nhân; nếu không loại bỏ được thì giảm nhẹ là lựa chọn còn lại — liên hệ #26494 lô 195 | |

⚠ GIẢM NHẸ trong thực tế nghĩa là gì: | Hướng | Ví dụ | |---|---| | ⚠ Giảm XÁC SUẤT | ⚠ thử nghiệm sớm, làm nguyên mẫu, đào tạo đội, dùng công nghệ đã kiểm chứng | | ⚠ Giảm TÁC ĐỘNG | ⚠ thiết kế dự phòng, chia nhỏ để hỏng cục bộ, chuẩn bị kế hoạch khôi phục | | ⚠ Cả hai | ⚠ thường là kết hợp — và đó là cách dùng hiệu quả nhất | | ⚠ Sau khi giảm nhẹ | ⚠ luôn còn RỦI RO TỒN DƯ và có thể sinh RỦI RO THỨ CẤP — phải ghi lại cả hai; liên hệ #26462 lô 194 và #26564 lô 196 | | ⚠ Câu hỏi kinh tế | ⚠ chi phí giảm nhẹ phải NHỎ HƠN mức giảm được của EMV — ở đây EMV là 43.200, nên khoản chi vài nghìn đô để hạ xác suất từ 0,80 xuống 0,30 là rất đáng |

⚠ Vì sao đây là câu về ĐỌC SỐ LIỆU chứ không chỉ về thuật ngữ: | Bước | Nội dung | |---|---| | ⚠ 1. Tính EMV: 0,80 × 54.000 = 43.200 | | | ⚠ 2. So với ngân sách: 43.200 / 125.000 ≈ 34,6% | | | ⚠ 3. Kết luận: mức phơi nhiễm QUÁ LỚN để chấp nhận | | | ⚠ 4. Xét từng chiến lược theo tính khả thi | ⚠ chuyển giao không khả thi vì xác suất quá cao | | ⚠ 5. Còn lại giảm nhẹ (hoặc né tránh nếu đổi được kế hoạch) | | | ⚠ Thói quen tốt | ⚠ luôn quy tác động về TỈ LỆ PHẦN TRĂM NGÂN SÁCH — con số 54.000 tự nó không nói lên gì; 43% ngân sách thì nói rất nhiều |

Từ khoá nhận diện:

"xác suất cao + tác động nghiêm trọng" → ⚠ GIẢM NHẸ (hoặc né tránh nếu loại bỏ được nguyên nhân) "xác suất thấp + tác động lớn" → ⚠ chuyển giao — bảo hiểm còn hợp lý về giá "xác suất thấp + tác động nhỏ" → ⚠ chấp nhận, danh sách theo dõi "huỷ dự án" → ⚠ vượt thẩm quyền và cực đoan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro lớn nhất của bạn chiếm bao nhiêu phần trăm ngân sách theo EMV | | | Chi phí giảm nhẹ có nhỏ hơn mức EMV giảm được không | | | Bạn có ghi lại rủi ro tồn dư sau khi giảm nhẹ không | |

Và điều mà phép nhân đơn giản 0,80 × 54.000 làm được cho cuộc thảo luận về rủi ro: nó biến một cảm giác lo lắng thành một con số mà mọi người có thể cùng nhìn vào — và một khi con số đó nằm cạnh ngân sách, không ai còn tranh cãi rằng có nên hành động hay không.

Đáp án

A — GIỮ CHO BÊN LIÊN QUAN NÀY ĐƯỢC THÔNG TIN về tiến độ.

Vì sao đúng

⚠ Định vị bên liên quan này trên lưới quyền lực – quan tâm: | Yếu tố | Bằng chứng trong đề | Kết luận | |---|---|---| | ⚠ Mức QUAN TÂM | ⚠ dự ĐỀU ĐẶN mọi buổi rà soát sprint | ⚠ CAO | | ⚠ Mức QUYỀN LỰC | ⚠ KHÔNG thuyết phục nổi chủ sản phẩm thêm hạng mục vào backlog | ⚠ THẤP | | ⚠ Ô tương ứng | ⚠ quan tâm CAO + quyền lực THẤP | ⚠ GIỮ CHO ĐƯỢC THÔNG TIN | | ⚠ Cách thực hiện | ⚠ cung cấp thông tin đầy đủ, thường xuyên, nhưng không trao thêm quyền quyết | | | ⚠ Kết luận | ⚠ họ bực vì cảm thấy không được lắng nghe — thông tin đầy đủ giải quyết được phần lớn điều đó |

⚠ Chi tiết quyết định: ⚠ việc "không thuyết phục được chủ sản phẩm" chính là bằng chứng về QUYỀN LỰC THẤP ⚠ — ⚠ người có quyền lực cao sẽ tác động được tới backlog; ⚠ đề cài dữ kiện này rất khéo, và nó là chìa khoá để chọn đúng ô.

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

• C (mời bên liên quan này dự MỌI cuộc họp dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ họ đang quan tâm cao và đang bực bội, nên "cho họ tham gia nhiều hơn" nghe như cách xoa dịu tự nhiên: ⚠ nhưng ⚠ đó là hành xử của ô QUẢN LÝ CHẶT CHẼ, dành cho người quyền lực CAO + quan tâm CAO ⚠ — ⚠ mời họ vào mọi buổi họp tốn thời gian của cả đội, và không giải quyết vấn đề gốc là các đề xuất của họ không được ưu tiên; ⚠ liên hệ #26486 lô 195.

• B (giao một thành viên đội chuyên cập nhật cho họ) — ⚠ lãng phí nguồn lực đội cho một bên liên quan quyền lực thấp; ⚠ và tạo ra một kênh riêng không cần thiết.

• D (không làm gì, chủ sản phẩm sẽ lo) — ⚠ bỏ mặc; ⚠ scrum master có vai trò gỡ vướng mắc, và một bên liên quan bực bội là vướng mắc thật.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26486 lô 195 (lưới quyền lực – quan tâm: giữ cho hài lòng), ⚠ #26604 cùng lô (bên liên quan xin thêm hạng mục — chỉ sang chủ sản phẩm), ⚠ #26596 cùng lô (kế hoạch giao tiếp), ⚠ #26436 lô 194 (ưu tiên theo tác động), ⚠ #26477 lô 194 (gắn kết bên liên quan).

⚠ LƯỚI QUYỀN LỰC – QUAN TÂM — bảng chốt: | | Quan tâm THẤP | Quan tâm CAO | |---|---|---| | ⚠ Quyền lực CAO | ⚠ GIỮ CHO HÀI LÒNG — #26486 lô 195 | ⚠ QUẢN LÝ CHẶT CHẼ | | ⚠ Quyền lực THẤP | ⚠ GIÁM SÁT — nỗ lực tối thiểu | ⚠ GIỮ CHO ĐƯỢC THÔNG TIN — CÂU NÀY | | ⚠ Mẹo nhớ | ⚠ QUYỀN LỰC quyết định mức CẨN THẬN; QUAN TÂM quyết định LƯỢNG thông tin | | | ⚠ Cặp dễ lẫn nhất | ⚠ "giữ cho HÀI LÒNG" (quyền lực cao) và "giữ cho ĐƯỢC THÔNG TIN" (quan tâm cao) — hai cụm nghe rất giống trong tiếng Việt; bám vào trục QUYỀN LỰC để phân biệt | |

⚠ "Giữ cho được thông tin" trong thực tế nghĩa là gì: | Việc NÊN làm | Việc KHÔNG nên làm | |---|---| | ⚠ Gửi cập nhật đầy đủ và đều đặn | ⚠ trao quyền quyết định họ không có | | ⚠ Giải thích VÌ SAO các hạng mục được xếp thứ tự như vậy | ⚠ phớt lờ đề xuất của họ mà không giải thích | | ⚠ Cho họ dự các buổi phù hợp — như rà soát sprint | ⚠ mời vào mọi cuộc họp | | ⚠ Ghi nhận đề xuất của họ vào backlog dù chưa ưu tiên | ⚠ để đề xuất rơi vào im lặng | | ⚠ Kết nối họ với chủ sản phẩm để trao đổi trực tiếp | ⚠ để scrum master thành người trung gian mãi | | ⚠ Điều thường thật sự chữa được sự bực bội | ⚠ không phải việc được thêm việc vào backlog, mà là việc HIỂU VÌ SAO nó chưa được ưu tiên — người ta chấp nhận một câu "không" có lý do dễ hơn nhiều so với một sự im lặng |

⚠ Vì sao Xavier nên xử lý thay vì để chủ sản phẩm lo: | Lý do | Nội dung | |---|---| | ⚠ Scrum master gỡ VƯỚNG MẮC cho đội và cho tiến trình | ⚠ một bên liên quan bực bội có thể trở thành vướng mắc thật | | ⚠ Anh là người quan sát được mô hình lặp lại qua nhiều sprint | ⚠ đề nói anh đã rà lại các lần trước | | ⚠ Anh có thể cải thiện QUY TRÌNH giao tiếp | ⚠ đó đúng là phạm vi của anh | | ⚠ Nhưng ranh giới vẫn giữ | ⚠ anh KHÔNG quyết backlog và không hứa thay chủ sản phẩm — anh chỉ bảo đảm bên liên quan được thông tin đầy đủ và được kết nối đúng người; liên hệ #26604 cùng lô |

Từ khoá nhận diện:

"quan tâm CAO nhưng không tác động được tới quyết định" → ⚠ GIỮ CHO ĐƯỢC THÔNG TIN "quyền lực cao, quan tâm thấp" → ⚠ giữ cho hài lòng — #26486 lô 195 "mời dự mọi cuộc họp" → ⚠ hành xử của ô quản lý chặt chẽ, không đúng ô này bằng chứng về quyền lực → ⚠ họ có tác động được tới quyết định hay không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có vẽ lưới quyền lực – quan tâm cho dự án chưa | | | Có bên liên quan nào đang bực bội mà bạn chưa hỏi vì sao không | | | Đề xuất bị từ chối ở dự án bạn có được trả lời kèm lý do không | |

Và điều mà một bên liên quan dự đều mọi buổi họp nhưng không bao giờ được ưu tiên đang thật sự nói: họ không đòi quyền quyết định — họ chỉ muốn biết rằng có ai đó đã thật sự cân nhắc đề xuất của mình trước khi xếp nó xuống cuối.

Đáp án

B — CHÍNH TRỊ VÀ CẤU TRÚC QUYỀN LỰC (politics and power structures).

⚠ Đối chiếu bắt buộc — đây là câu THỨ TƯ trong một họ dùng CÙNG BỐN PHƯƠNG ÁN: ⚠ #26286 lô 191, #26382 lô 191, #26418 lô 193 và câu này đều hỏi "khía cạnh nào của phán đoán chuyên gia được dùng khi sửa quy tắc gắn kết bên liên quan", với cùng bộ phương án ⚠ — ⚠ bốn khoá KHÁC NHAU và cả bốn đều đúng, vì bối cảnh khác nhau: ⚠ #26286 → ĐẶC ĐIỂM CỦA BÊN LIÊN QUAN; ⚠ #26382 → KỸ THUẬT PHÂN TÍCH VÀ ĐÁNH GIÁ; ⚠ #26418 → MÔI TRƯỜNG VÀ VĂN HOÁ CỦA TỔ CHỨC; ⚠ #26609 (câu này) → CHÍNH TRỊ VÀ CẤU TRÚC QUYỀN LỰC. ⚠ Hash MD5 không bắt được vì đề bài khác hẳn nhau; các khoá KHÔNG mâu thuẫn — chúng là bốn lát cắt của cùng một quy trình. ⚠ Cách làm bài: đọc kỹ xem đề nhấn vào ĐIỀU GÌ là căn cứ để sửa quy tắc.

Vì sao đúng

⚠ Vì sao đây là chính trị và cấu trúc quyền lực: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Nhà tài trợ hiện tại SẮP RỜI ĐI | ⚠ cấu trúc quyền lực sắp thay đổi | | ⚠ Một trong các bên liên quan sẽ THÀNH nhà tài trợ mới | ⚠ quyền lực sắp chuyển sang tay ai đó | | ⚠ Quản lý dự án phân tích Mark ỦNG HỘ, Steve có thể CHẶN | ⚠ đánh giá lập trường chính trị của từng người | | ⚠ Anh CHỐT quy tắc TRƯỚC KHI nhà tài trợ cũ rời đi | ⚠ tận dụng cửa sổ quyền lực còn mở — hành động chính trị điển hình | | ⚠ Mục đích: bảo vệ các buổi rà soát khỏi bị huỷ về sau | ⚠ dùng quy tắc chính thức để ràng buộc người kế nhiệm | | ⚠ Kết luận | ⚠ toàn bộ tình huống xoay quanh AI SẼ CÓ QUYỀN và họ sẽ dùng nó thế nào |

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

• A (ĐẶC ĐIỂM CỦA BÊN LIÊN QUAN) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ quản lý dự án ĐANG phân tích đặc điểm của Mark và Steve — người này ủng hộ, người kia phản đối: ⚠ nhưng ⚠ điều anh dựa vào để RA QUYẾT ĐỊNH không phải tính cách của họ, mà là VIỆC AI SẼ NẮM QUYỀN ⚠ — ⚠ nếu Steve chỉ là một bên liên quan bình thường thì thái độ của anh ta không đáng để sửa quy tắc; vấn đề nằm ở chỗ anh ta SẮP CÓ QUYỀN CHẶN; ⚠ so sánh với #26286 lô 191, nơi đề nhấn vào chính đặc điểm và nhu cầu của bên liên quan.

• D (KỸ THUẬT PHÂN TÍCH VÀ ĐÁNH GIÁ) — ⚠ là khía cạnh về việc dùng công cụ phân tích có cấu trúc; ⚠ đề không mô tả công cụ nào — liên hệ #26382 lô 191.

• C (QUẢN LÝ YÊU CẦU) — ⚠ hoàn toàn lạc lĩnh vực; ⚠ đề không nói gì về yêu cầu sản phẩm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26286, #26382 lô 191 và ⚠ #26418 lô 193 (ba câu còn lại trong họ), ⚠ #26486 lô 195 (lưới quyền lực – quan tâm), ⚠ #26489 lô 196 (các loại quyền lực), ⚠ #26608 cùng lô (bên liên quan quyền lực thấp).

⚠ BỐN KHÍA CẠNH của phán đoán chuyên gia khi lập kế hoạch gắn kết bên liên quan: | Khía cạnh | Dùng khi đề nhấn vào | Câu tham chiếu | |---|---|---| | ⚠ ĐẶC ĐIỂM CỦA BÊN LIÊN QUAN | ⚠ nhu cầu, kỳ vọng, tính cách, mối quan tâm của từng người | ⚠ #26286 lô 191 | | ⚠ KỸ THUẬT PHÂN TÍCH VÀ ĐÁNH GIÁ | ⚠ dùng công cụ có cấu trúc: lưới, ma trận, mô hình phân loại | ⚠ #26382 lô 191 | | ⚠ MÔI TRƯỜNG VÀ VĂN HOÁ TỔ CHỨC | ⚠ chuẩn mực, thói quen, cách làm việc của tổ chức | ⚠ #26418 lô 193 | | ⚠ CHÍNH TRỊ VÀ CẤU TRÚC QUYỀN LỰC | ⚠ AI có quyền, quyền đang chuyển đi đâu, ai chặn được cái gì | ⚠ CÂU NÀY | | ⚠ Cách phân biệt nhanh | ⚠ hỏi: đề đang nói về CON NGƯỜI, về CÔNG CỤ, về VĂN HOÁ, hay về QUYỀN LỰC? — mỗi câu trong họ này nhấn vào đúng một thứ | |

⚠ Vì sao đọc được CHÍNH TRỊ là kỹ năng thật của quản lý dự án: | Lý do | Nội dung | |---|---| | ⚠ Quyền lực trong tổ chức luôn dịch chuyển | ⚠ người rời đi, người được thăng chức, cơ cấu đổi | | ⚠ Một dự án tốt vẫn có thể bị dừng vì lý do chính trị | | | ⚠ Biết trước ai sẽ có quyền giúp chuẩn bị sớm | ⚠ đúng điều quản lý dự án trong đề đang làm | | ⚠ Chính trị KHÔNG đồng nghĩa với thủ đoạn | ⚠ đọc hiểu cấu trúc quyền lực là kỹ năng chuyên môn chính đáng | | ⚠ Ranh giới đạo đức | ⚠ dùng hiểu biết về quyền lực để BẢO VỆ thực hành tốt cho dự án là chính đáng; dùng nó để che giấu thông tin hoặc thao túng thì không — và ranh giới nằm ở chỗ bạn có sẵn sàng giải thích công khai lý do của mình hay không |

⚠ Việc quản lý dự án làm ở đây có hợp lý không: | Góc nhìn | Nội dung | |---|---| | ⚠ Hợp lý | ⚠ các buổi rà soát hai tuần một lần đang giúp gỡ vướng mắc thật — đó là giá trị cho dự án, không phải sở thích cá nhân | | ⚠ Hợp lý | ⚠ chính thức hoá một thực hành tốt trong khi còn được phê duyệt là quản trị tốt | | ⚠ Cần cẩn trọng | ⚠ nếu anh chỉ nhằm ràng buộc người kế nhiệm mà không nghe quan điểm của Steve, đó là né tránh một cuộc trò chuyện cần có | | ⚠ Việc nên làm thêm | ⚠ trao đổi trực tiếp với Steve để hiểu VÌ SAO anh ta coi các buổi đó là lãng phí — rất có thể có một vấn đề thật về cách tổ chức các buổi ấy; liên hệ #26598 cùng lô |

Từ khoá nhận diện:

"ai sắp có quyền, ai có thể chặn" → ⚠ CHÍNH TRỊ VÀ CẤU TRÚC QUYỀN LỰC "nhu cầu và tính cách của từng bên liên quan" → ⚠ đặc điểm của bên liên quan "dùng lưới, ma trận, mô hình phân loại" → ⚠ kỹ thuật phân tích và đánh giá "chuẩn mực và thói quen của tổ chức" → ⚠ môi trường và văn hoá tổ chức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết quyền lực trong tổ chức mình đang dịch chuyển về đâu không | | | Thực hành tốt nào của dự án bạn sẽ biến mất nếu người ủng hộ nó rời đi | | | Bạn có ghi chúng thành quy tắc chính thức chưa | |

Và điều mà quản lý dự án trong tình huống này hiểu rất rõ: một thực hành tốt chỉ tồn tại nhờ thiện chí của một người là một thực hành đang đếm ngược — và cửa sổ để biến nó thành quy tắc luôn hẹp hơn ta tưởng.

Đáp án

D — Thông tin giữa KHÁCH HÀNG và NHÀ CUNG CẤP mang tính HỢP ĐỒNG và BẢO MẬT.

Vì sao đúng

⚠ PRIVITY (quan hệ hợp đồng riêng) là gì: | Khía cạnh | Nội dung | |---|---| | ⚠ Nguyên tắc pháp lý về QUAN HỆ HỢP ĐỒNG | ⚠ chỉ các bên KÝ hợp đồng mới có quyền và nghĩa vụ theo hợp đồng đó | | ⚠ Trong quản lý dự án: thông tin trao đổi mang tính hợp đồng và BẢO MẬT | ⚠ đúng nội dung phương án D | | ⚠ Bên thứ ba KHÔNG có quyền với hợp đồng đó | ⚠ kể cả khi họ bị ảnh hưởng | | ⚠ Đề đặt nó cạnh QUYỀN SỞ HỮU TRÍ TUỆ | ⚠ hai điều khoản bảo vệ thông tin và tài sản vô hình, thường đi cùng nhau | | ⚠ Kết luận | ⚠ phương án duy nhất nêu đúng cả hai yếu tố: HỢP ĐỒNG và BẢO MẬT |

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

• C (thông tin nghề nghiệp về giao dịch giữa khách hàng và nhà cung cấp) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng nói về thông tin giữa hai bên đúng, chỉ khác một chữ ở phần mô tả: ⚠ nhưng ⚠ nó thiếu HAI yếu tố cốt lõi: tính RÀNG BUỘC HỢP ĐỒNG và tính BẢO MẬT ⚠ — ⚠ "thông tin nghề nghiệp về việc bán hàng" là một mô tả chung chung, ⚠ và chính hai yếu tố bị thiếu đó mới là bản chất của privity; ⚠ đây là kiểu nhiễu gần đúng nhưng thiếu phần định nghĩa.

• A (quan hệ giữa quản lý dự án và một nhà cung cấp ĐÃ BIẾT) — ⚠ privity là quan hệ giữa CÁC BÊN KÝ HỢP ĐỒNG, không phải giữa cá nhân quản lý dự án với ai đó.

• B (quan hệ giữa quản lý dự án và một nhà cung cấp CHƯA BIẾT) — ⚠ càng sai: ⚠ không có hợp đồng thì không có privity.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26558 lô 196 (các loại hợp đồng), ⚠ #26565 lô 196 (trần cho hợp đồng T&M), ⚠ #26583 cùng lô (đóng hợp đồng), ⚠ #26531 lô 195 (tài liệu mời thầu), ⚠ #26556 lô 196 (tiêu chí chấp nhận vật tư).

⚠ PRIVITY — ý nghĩa thực tế với quản lý dự án: | Tình huống | Hệ quả của privity | |---|---| | ⚠ Bạn ký hợp đồng với nhà thầu chính, nhà thầu chính thuê thầu phụ | ⚠ bạn KHÔNG có quan hệ hợp đồng với thầu phụ — không chỉ đạo trực tiếp được họ | | ⚠ Thầu phụ làm hỏng việc | ⚠ bạn khiếu nại với NHÀ THẦU CHÍNH, không khiếu nại thầu phụ | | ⚠ Thông tin trong hợp đồng | ⚠ BẢO MẬT — không chia sẻ với bên thứ ba | | ⚠ Bạn muốn đổi cách thầu phụ làm việc | ⚠ phải đi qua nhà thầu chính | | ⚠ Sai lầm thực tế phổ biến | ⚠ quản lý dự án ra lệnh trực tiếp cho nhân sự của thầu phụ — việc này vừa vi phạm quan hệ hợp đồng, vừa có thể tạo ra trách nhiệm pháp lý không mong muốn cho tổ chức của bạn |

⚠ Các điều khoản hợp đồng liên quan tới thông tin: | Điều khoản | Nội dung | |---|---| | ⚠ PRIVITY | ⚠ chỉ các bên ký mới có quyền và nghĩa vụ — CÂU NÀY | | ⚠ QUYỀN SỞ HỮU TRÍ TUỆ | ⚠ ai sở hữu thiết kế, mã nguồn, tài liệu tạo ra | | ⚠ BẢO MẬT (NDA) | ⚠ thông tin nào không được tiết lộ và trong bao lâu | | ⚠ Bồi thường (indemnification) | ⚠ ai gánh trách nhiệm khi có thiệt hại cho bên thứ ba | | ⚠ Chấm dứt hợp đồng | ⚠ điều kiện và hậu quả | | ⚠ Vì sao quản lý dự án cần biết | ⚠ bạn không cần là luật sư, nhưng phải nhận ra KHI NÀO cần gọi luật sư — và biết mình được nói gì với ai là kiến thức tối thiểu để không tạo ra vấn đề pháp lý trong lúc làm việc bình thường |

⚠ Với dự án của Diego — lắp đặt thiết bị điện trong môi trường sản xuất: | Rủi ro | Nội dung | |---|---| | ⚠ Thông tin về nhà máy khách hàng là nhạy cảm | ⚠ sơ đồ điện, quy trình sản xuất, an ninh | | ⚠ Thiết kế và giải pháp có thể là tài sản trí tuệ | ⚠ của Diego hoặc của khách hàng — hợp đồng phải nói rõ | | ⚠ Có thể có nhiều nhà thầu cùng làm tại một công trường | ⚠ và privity giới hạn ai được nói chuyện với ai về cái gì | | ⚠ Việc Diego nên làm | ⚠ bảo đảm cả ĐỘI hiểu ranh giới này — vi phạm bảo mật thường không đến từ ý đồ xấu mà đến từ một câu chuyện vô tình trong bữa trưa với một nhà thầu khác |

Từ khoá nhận diện:

"privity" → ⚠ thông tin giữa khách hàng và nhà cung cấp, mang tính HỢP ĐỒNG và BẢO MẬT "chỉ các bên ký hợp đồng mới có quyền" → ⚠ nguyên tắc nền của privity "quan hệ giữa quản lý dự án và nhà cung cấp" → ⚠ sai chủ thể — privity là giữa CÁC BÊN KÝ "thông tin nghề nghiệp về giao dịch" → ⚠ thiếu hai yếu tố định nghĩa: hợp đồng và bảo mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có quan hệ hợp đồng trực tiếp với ai trong chuỗi nhà thầu của mình | | | Đội bạn có biết thông tin nào là bảo mật theo hợp đồng không | | | Bạn có bao giờ chỉ đạo trực tiếp nhân sự của thầu phụ không | ⚠ nếu có, hãy kiểm lại hợp đồng |

Và lý do khái niệm privity đáng nhớ dù nghe rất pháp lý: nó nhắc rằng trong một dự án có nhiều bên, việc bạn NÓI CHUYỆN ĐƯỢC với ai không có nghĩa là bạn CÓ QUYỀN yêu cầu họ điều gì — và nhầm hai điều đó là cách một cuộc trao đổi thân thiện biến thành một tranh chấp hợp đồng.

Đáp án

A — Đội thiết kế báo lý do trong buổi họp sáng; Joe làm việc với họ để CÙNG xác định hành động khắc phục; rồi Joe báo cho bên liên quan cả LÝ DO lẫn HÀNH ĐỘNG KHẮC PHỤC, TRỰC TIẾP.

Vì sao đúng

⚠ Ba yếu tố làm phương án này đúng: | Yếu tố | Nội dung | |---|---| | ⚠ HIỂU NGUYÊN NHÂN trước khi báo cáo | ⚠ báo cáo không có nguyên nhân chỉ gây hoang mang | | ⚠ CÙNG đội tìm hành động khắc phục | ⚠ không đổ lỗi, không tự quyết thay họ | | ⚠ Báo cả LÝ DO và GIẢI PHÁP cùng lúc | ⚠ tin xấu đi kèm phương án là tin có thể xử lý được | | ⚠ Báo TRỰC TIẾP, không qua email | ⚠ tin xấu cần kênh giàu — liên hệ #26598 cùng lô | | ⚠ Trung thực, không giấu và không trì hoãn | | | ⚠ Kết luận | ⚠ phương án duy nhất làm đủ cả bốn: hiểu, cùng giải quyết, minh bạch, đúng kênh |

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

• D (bàn với đội thiết kế, xác định hành động khắc phục, rồi báo bên liên quan qua EMAIL) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó gần như trùng khớp với đáp án — cũng tìm nguyên nhân, cũng cùng đội, cũng có hành động khắc phục: ⚠ nhưng ⚠ nó khác ở KÊNH: email thay vì trực tiếp ⚠ — ⚠ tin xấu qua email mất toàn bộ cận ngôn ngữ và phi ngôn ngữ, không cho phép hỏi lại ngay, và rất dễ bị đọc thành lạnh lùng hoặc né tránh; ⚠ và nó chỉ báo HÀNH ĐỘNG KHẮC PHỤC mà không báo LÝ DO — bên liên quan sẽ hỏi lại, và lúc đó cuộc trao đổi bắt đầu bằng sự nghi ngờ; ⚠ liên hệ #26505 lô 195.

• C (báo bên liên quan rằng dự án trễ TRƯỚC, rồi mới đi tìm lý do) — ⚠ báo cáo khi chưa có thông tin gì; ⚠ bên liên quan sẽ hỏi "vì sao" và "sẽ làm gì" — hai câu Joe chưa trả lời được; ⚠ nó gây hoang mang mà không giải quyết gì.

• B (tìm hành động khắc phục nhưng báo rằng mọi thứ vẫn đúng kế hoạch) — ⚠ NÓI DỐI; ⚠ vi phạm nguyên tắc trung thực của quy tắc ứng xử PMI, và khi sự thật lộ ra thì mất toàn bộ uy tín — liên hệ #26570 lô 196.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26518 lô 195 (báo nhà tài trợ ngay khi có tin ảnh hưởng lớn), ⚠ #26598 cùng lô (chọn kênh theo độ khó của thông điệp), ⚠ #26505 lô 195 (cận ngôn ngữ), ⚠ #26537 lô 196 (không đổ lỗi), ⚠ #26476 lô 194 (giao tiếp với bên liên quan).

⚠ BÁO TIN XẤU — bốn nguyên tắc: | Nguyên tắc | Nội dung | |---|---| | ⚠ SỚM | ⚠ càng muộn càng mất niềm tin; bên liên quan chịu được tin xấu, không chịu được bất ngờ | | ⚠ ĐẦY ĐỦ: chuyện gì, vì sao, đang làm gì | ⚠ ba phần, thiếu phần nào cũng sinh câu hỏi | | ⚠ ĐÚNG KÊNH: trực tiếp cho tin quan trọng | ⚠ email cho tin đơn giản cần lưu vết | | ⚠ KHÔNG ĐỔ LỖI cho một cá nhân hay một đội | ⚠ trình bày như vấn đề của dự án, không phải lỗi của ai | | ⚠ Thứ tự trình bày hiệu quả | ⚠ tình hình → tác động → nguyên nhân → hành động đang làm → điều cần bên liên quan quyết (nếu có) |

⚠ Vì sao KHÔNG nên nêu đích danh "lỗi của đội thiết kế" với bên liên quan: | Lý do | Nội dung | |---|---| | ⚠ Bên liên quan quan tâm tới TÁC ĐỘNG và GIẢI PHÁP | ⚠ không quan tâm ai gây ra | | ⚠ Đổ lỗi công khai phá vỡ lòng tin trong đội | ⚠ liên hệ #26537 lô 196 | | ⚠ Nguyên nhân thường phức tạp hơn "một đội làm chậm" | ⚠ có thể do yêu cầu đổi, do phụ thuộc, do thiếu người | | ⚠ Quản lý dự án chịu trách nhiệm cuối cùng về tiến độ | | | ⚠ Cách nói đúng | ⚠ "phần thiết kế mất nhiều thời gian hơn dự kiến vì lý do X, và đây là cách chúng tôi bù lại" — nêu NGUYÊN NHÂN mà không biến nó thành lời buộc tội |

⚠ Vì sao buổi HỌP SÁNG là nơi thông tin nên xuất hiện: | Lý do | Nội dung | |---|---| | ⚠ Đó là nơi vấn đề được nêu theo nhịp hằng ngày | ⚠ liên hệ #26506 lô 195 — họp đứng | | ⚠ Cả đội cùng nghe, không có kênh riêng | | | ⚠ Joe biết sớm nhất có thể | ⚠ càng sớm càng nhiều lựa chọn | | ⚠ Điều đáng chú ý trong đề | ⚠ thông tin đến từ chính đội thiết kế chứ không phải do Joe phát hiện ra — đó là dấu hiệu của một đội có lòng tin, và Joe phản ứng thế nào lúc này sẽ quyết định lần sau họ có báo sớm nữa hay không |

Từ khoá nhận diện:

"nghe lý do, cùng tìm giải pháp, báo trực tiếp cả hai" → ⚠ ĐÚNG ĐỦ BỐN YẾU TỐ "báo qua email" → ⚠ sai kênh cho tin xấu quan trọng "báo trễ trước rồi mới tìm hiểu" → ⚠ gây hoang mang mà chưa trả lời được gì "nói mọi thứ vẫn đúng kế hoạch" → ⚠ nói dối, vi phạm nguyên tắc trung thực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tin xấu gần nhất bạn báo bằng kênh nào | | | Bạn có báo kèm nguyên nhân và hành động khắc phục không | | | Đội bạn có báo tin xấu cho bạn sớm không | ⚠ nếu không, hãy xem lại phản ứng của mình lần trước |

Và điều quyết định bên liên quan sẽ tin hay nghi ngờ bạn ở lần trễ hạn tiếp theo: không phải là dự án có trễ hay không — mà là lần này họ nghe tin từ bạn hay nghe từ người khác.

Đáp án

C — XÁC ĐỊNH việc chuyển đổi sẽ đòi hỏi những gì và cần chuẩn bị gì cho thay đổi đó.

⚠ Đối chiếu — câu GẦN TRÙNG với #26496 lô 195: ⚠ cùng tình huống một quản lý dự án giàu kinh nghiệm thác nước đứng trước việc tổ chức chuyển sang agile ⚠ — ⚠ ở #26496, đề hỏi anh nên AM HIỂU điều gì, đáp án là agile nói chung; ⚠ ở câu này, đề hỏi anh PHẢI LÀM GÌ để chuẩn bị, đáp án là xác định việc chuyển đổi đòi hỏi gì. ⚠ Hash MD5 không bắt được; hai khoá NHẤT QUÁN — một câu về KIẾN THỨC cần có, một câu về HÀNH ĐỘNG cần làm.

Vì sao đúng

⚠ Vì sao đây là bước chuẩn bị đúng: | Lý do | Nội dung | |---|---| | ⚠ Phải HIỂU quy mô thay đổi trước khi hành động | ⚠ chẩn đoán trước, kê đơn sau — nguyên tắc lặp lại khắp đề PMP | | ⚠ Chuyển đổi ảnh hưởng tới nhiều thứ, không chỉ kiến thức cá nhân | ⚠ vai trò, quy trình, công cụ, cách đo, quan hệ với bên liên quan | | ⚠ Nó dẫn tới một KẾ HOẠCH chuẩn bị cụ thể | ⚠ thay vì một phản ứng chung chung | | ⚠ Quyết định đã được tổ chức đưa ra | ⚠ việc của anh là chuẩn bị, không phải tranh luận lại | | ⚠ Nó giữ được kinh nghiệm sáu năm của anh | ⚠ thay vì vứt bỏ nó | | ⚠ Kết luận | ⚠ cách tiếp cận có phương pháp với một thay đổi lớn |

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

• A (thích nghi với tư duy agile) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó ĐÚNG về hướng — tư duy agile chính là thứ khó thay đổi nhất, và #26496 lô 195 cũng chỉ về đó: ⚠ nhưng ⚠ nó QUÁ CHUNG CHUNG để là một hành động chuẩn bị ⚠ — ⚠ "thích nghi với tư duy agile" là KẾT QUẢ mong muốn, không phải BƯỚC ĐI; ⚠ đề hỏi anh PHẢI LÀM GÌ, và phương án C nêu một việc cụ thể dẫn tới chính kết quả mà A mô tả.

• B (dừng tất cả dự án cho tới khi hiểu đầy đủ agile, kể cả đi học) — ⚠ phản ứng cực đoan và bất khả thi; ⚠ dự án không dừng được vì một người cần đi học; ⚠ và học agile không đòi phải dừng công việc.

• D (nói với quản lý về thay đổi này vì mình đã thành công với thác nước) — ⚠ kháng cự thay đổi bằng thành tích quá khứ; ⚠ tổ chức đã quyết, và thành công cũ không phải lý lẽ để miễn trừ — liên hệ #26541 lô 196.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26496 lô 195 (câu gần trùng — học agile nói chung), ⚠ #26541 lô 196 (vì sao người ta kháng cự thay đổi), ⚠ #26504 lô 195 (mô hình ADKAR), ⚠ #26586 cùng lô (trình bày agile cho lãnh đạo), ⚠ #26510 lô 195 (chọn phương pháp theo bối cảnh).

⚠ Việc chuyển đổi sang agile đòi hỏi những gì — thứ mà anh cần xác định: | Lĩnh vực | Cần thay đổi gì | |---|---| | ⚠ TƯ DUY | ⚠ từ kiểm soát kế hoạch sang thích ứng liên tục — khó nhất | | ⚠ VAI TRÒ | ⚠ quản lý dự án trở thành người phục vụ; xuất hiện chủ sản phẩm và scrum master | | ⚠ QUY TRÌNH | ⚠ vòng lặp, nghi thức, cách xử lý thay đổi | | ⚠ CÔNG CỤ | ⚠ backlog và bảng công việc thay cho sơ đồ Gantt chi tiết | | ⚠ CÁCH ĐO | ⚠ giá trị đã giao và tốc độ thay cho phần trăm hoàn thành kế hoạch | | ⚠ QUAN HỆ BÊN LIÊN QUAN | ⚠ họ phải tham gia thường xuyên hơn, không chỉ ở đầu và cuối | | ⚠ HỢP ĐỒNG và QUẢN TRỊ | ⚠ phạm vi linh hoạt đòi loại hợp đồng khác — liên hệ #26558 lô 196 | | ⚠ Việc anh nên làm | ⚠ lập một danh sách khoảng trống cho từng lĩnh vực trên, rồi ưu tiên — đó chính là "xác định việc chuyển đổi đòi hỏi gì", và nó biến một nỗi lo mơ hồ thành một kế hoạch làm được |

⚠ Vì sao kinh nghiệm thác nước KHÔNG bị vứt bỏ: | Kỹ năng vẫn có giá trị | Nội dung | |---|---| | ⚠ Quản lý bên liên quan | ⚠ agile còn cần nhiều hơn | | ⚠ Quản lý rủi ro | ⚠ nguyên lý không đổi, chỉ đổi nhịp | | ⚠ Hợp đồng và mua sắm | ⚠ vẫn cần, và cần điều chỉnh khéo hơn | | ⚠ Quản trị và báo cáo cho lãnh đạo | ⚠ liên hệ #26586 cùng lô | | ⚠ Ước lượng và tài chính dự án | | | ⚠ Thứ phải buông bỏ | ⚠ cảm giác an toàn mà một bản kế hoạch chi tiết dài hạn mang lại — đó là mất mát thật, và thừa nhận nó thẳng thắn giúp việc chuyển đổi dễ hơn nhiều so với việc giả vờ rằng không mất gì; liên hệ #26463 lô 194 |

⚠ Áp mô hình ADKAR vào chính bản thân anh: | Giai đoạn | Câu hỏi của anh | |---|---| | ⚠ NHẬN THỨC | ⚠ vì sao tổ chức chuyển sang agile — anh cần hiểu lý do, không chỉ nghe lệnh | | ⚠ MONG MUỐN | ⚠ anh được gì từ thay đổi này — kỹ năng mới, thị trường lao động rộng hơn | | ⚠ KIẾN THỨC | ⚠ học agile nói chung — chính là #26496 lô 195 | | ⚠ KHẢ NĂNG | ⚠ thực hành ở quy mô nhỏ, có người kèm cặp | | ⚠ CỦNG CỐ | ⚠ duy trì cách làm mới khi áp lực khiến muốn quay lại thói quen cũ | | ⚠ Nhận xét | ⚠ quản lý dự án thường áp ADKAR cho người khác mà quên áp cho chính mình — nhưng người dẫn dắt thay đổi mà chưa tự đi qua năm bước đó thì rất khó thuyết phục được ai; liên hệ #26504 lô 195 |

Từ khoá nhận diện:

"phải làm gì để chuẩn bị cho chuyển đổi" → ⚠ XÁC ĐỊNH việc chuyển đổi đòi hỏi gì "thích nghi với tư duy agile" → ⚠ kết quả mong muốn, không phải bước hành động "dừng mọi dự án để đi học" → ⚠ cực đoan và bất khả thi "tôi đã thành công với cách cũ" → ⚠ kháng cự bằng thành tích quá khứ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có danh sách cụ thể những gì cần đổi khi tổ chức thay đổi cách làm không | | | Kỹ năng nào của bạn vẫn giữ nguyên giá trị | ⚠ danh sách này thường dài hơn ta tưởng | | Bạn đang ở giai đoạn nào của ADKAR với thay đổi hiện tại | |

Và điều mà một quản lý dự án sáu năm thành công với thác nước cần nghe nhất khi tổ chức đổi hướng: không phải là cách làm cũ của anh đã sai, mà là bối cảnh đã đổi — và người giỏi nhất trong một bối cảnh thường là người có nhiều thứ phải buông bỏ nhất khi bối cảnh ấy thay đổi.