Ngân hàng đề — PMP® Mock Exam Set II Exam
Tìm thấy 718 câu.
- A Constructing key performance indicators
- B Mapping stakeholders
- C Identifying needs
- D Formalizing objectives
Xem giải thích
Đáp án
C — NHẬN DIỆN NHU CẦU (identifying needs).
Vì sao đúng
⚠ Zymon đã làm gì: | Bước | Nội dung | |---|---| | ⚠ Nghiên cứu KỲ VỌNG của khách hàng hiện tại | ⚠ họ chỉ nhận đơn từ 100 tấn trở lên | | ⚠ Đối chiếu với NĂNG LỰC thật của công ty | ⚠ chỉ sản xuất khoảng 45 tấn mỗi tháng | | ⚠ Phát hiện khoảng cách giữa nhu cầu và năng lực | ⚠ đây là nguyên nhân gốc của các lô hàng bị chậm | | ⚠ Tìm khách hàng có nhu cầu KHỚP với năng lực | ⚠ nhận diện nhu cầu mà công ty đáp ứng được | | ⚠ Kết luận | ⚠ anh không tăng tốc sản xuất — anh tìm ĐÚNG nhu cầu để phục vụ |
⚠ Vì sao đây là cách tạo giá trị: ⚠ giá trị chỉ xuất hiện khi năng lực của bên cung gặp đúng nhu cầu của bên cầu ⚠ — ⚠ cố phục vụ một nhu cầu vượt quá năng lực thì tạo ra chậm trễ cho khách và áp lực cho đội, chứ không tạo ra giá trị cho ai.
Vì sao các phương án khác sai
-
D (chính thức hoá mục tiêu — formalizing objectives) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ việc Zymon làm rõ được con số 100 tấn và 45 tấn trông rất giống việc định lượng mục tiêu: ⚠ nhưng ⚠ chính thức hoá mục tiêu là biến ý định thành mục tiêu có thể đo và cam kết — nó xảy ra SAU khi đã biết mình phục vụ ai ⚠ — ⚠ Zymon vẫn đang ở bước TÌM HIỂU: khách nào cần gì, ta làm được gì; ⚠ thứ tự luôn là: hiểu nhu cầu → chọn nhu cầu để phục vụ → đặt mục tiêu → đo bằng chỉ số.
-
A (xây dựng chỉ số hiệu năng chính) — ⚠ là bước ĐO, đến sau; ⚠ liên hệ #26713 cùng lô.
-
B (lập bản đồ bên liên quan) — ⚠ là phân loại và xếp nhóm những người có liên quan; ⚠ Zymon không phân loại ai, anh đang tìm sự phù hợp giữa nhu cầu và năng lực.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26713 cùng lô (KPI — bước đo, đến sau), ⚠ #26724 cùng lô (chọn theo trường hợp kinh doanh), ⚠ #26715 cùng lô (giá trị do khách hàng xác định), ⚠ #26711 cùng lô (tập trung vào hạng mục lõi), ⚠ #26687 cùng lô (lập bản đồ bên liên quan — phương án nhiễu B).
⚠ CHUỖI TẠO GIÁ TRỊ — Zymon đang ở đâu: | Bước | Việc | Câu hỏi | |---|---|---| | ⚠ 1. NHẬN DIỆN NHU CẦU | ⚠ hiểu ai cần gì và ta làm được gì — ĐÁP ÁN | ⚠ "vấn đề thật là gì" | | ⚠ 2. Chính thức hoá mục tiêu | ⚠ biến nhu cầu thành mục tiêu đo được | ⚠ "ta cam kết đạt gì" | | ⚠ 3. Xây dựng KPI | ⚠ định nghĩa cách đo thành công | ⚠ "đo bằng gì" | | ⚠ 4. Thực hiện và giao giá trị | | ⚠ "đã đạt chưa" | | ⚠ 5. Đo lợi ích thực tế | ⚠ sau khi bàn giao | ⚠ "có tạo ra giá trị thật không" | | ⚠ Sai lầm phổ biến nhất | ⚠ nhảy thẳng vào bước 3 và bước 4 — tổ chức có rất nhiều chỉ số đẹp cho một nhu cầu chưa từng được hiểu đúng |
⚠ Vì sao giải pháp của Zymon tốt hơn việc cố tăng sản lượng: | Phương án | Đánh giá | |---|---| | ⚠ Ép sản xuất từ 45 lên 100 tấn | ⚠ cần đầu tư lớn, mất nhiều tháng, rủi ro cao | | ⚠ Gom nhiều tháng để đủ một lô 100 tấn | ⚠ khách phải chờ hơn hai tháng — chính là sự chậm trễ hiện tại | | ⚠ TÌM KHÁCH NHẬN ĐƠN NHỎ HƠN | ⚠ ĐÁP ÁN — dùng đúng năng lực đang có, giao được ngay | | ⚠ Giữ nguyên và xin lỗi khách | ⚠ không giải quyết gì | | ⚠ Nhận xét | ⚠ đây là ví dụ đẹp của việc thay đổi ĐỊNH NGHĨA BÀI TOÁN thay vì cố giải một bài toán sai — và nó thường là bước đi tạo ra nhiều giá trị nhất trong toàn bộ dự án |
⚠ Nhận diện nhu cầu — công cụ thường dùng: | Công cụ | Nội dung | |---|---| | ⚠ Phỏng vấn và khảo sát khách hàng | ⚠ Zymon đã làm điều này | | ⚠ Phân tích tài liệu và dữ liệu bán hàng | | | ⚠ Phân tích khoảng cách (gap analysis) | ⚠ so hiện trạng với mong muốn — 45 so với 100 tấn | | ⚠ Phân tích nguyên nhân gốc | ⚠ vì sao lô hàng bị chậm | | ⚠ Bản đồ hành trình khách hàng | | | ⚠ Điều đáng lưu ý | ⚠ các lô hàng chậm là TRIỆU CHỨNG; nhu cầu không khớp năng lực mới là BỆNH — và Zymon đã đi từ triệu chứng về tới bệnh trước khi đưa ra giải pháp, đó chính là điều làm anh khác với người chỉ hứa giao hàng nhanh hơn |
Từ khoá nhận diện:
"tìm hiểu khách cần gì, đối chiếu với năng lực" → ⚠ NHẬN DIỆN NHU CẦU "biến nhu cầu thành mục tiêu đo được" → ⚠ chính thức hoá mục tiêu, bước sau "xây chỉ số đo" → ⚠ KPI, bước sau nữa "phân loại người liên quan" → ⚠ lập bản đồ bên liên quan, khác chủ đề
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết nhu cầu thật đằng sau yêu cầu của khách không | ⚠ hỏi "để làm gì" ba lần | | Năng lực thật của đội bạn là bao nhiêu | ⚠ đo, đừng ước theo mong muốn | | Có khách hàng nào bạn đang phục vụ mà lẽ ra không nên không | |
Và điều mà Zymon nhận ra sau vài lô hàng chậm: vấn đề không phải là công ty sản xuất quá chậm, mà là công ty đang bán cho những người cần nhiều hơn thứ mình làm ra được — và cách sửa nhanh nhất không nằm ở nhà máy, mà nằm ở danh sách khách hàng.
- A The requirement that will shorten the schedule.
- B The requirement stipulated by a stakeholder with more experience.
- C The requirement that will generate the most ROI.
- D The requirement that is most aligned to the project's business case.
Xem giải thích
Đáp án
D — YÊU CẦU BÁM SÁT NHẤT VỚI TRƯỜNG HỢP KINH DOANH CỦA DỰ ÁN.
Vì sao đúng
⚠ Vì sao trường hợp kinh doanh là trọng tài đúng: | Lý do | Nội dung | |---|---| | ⚠ Trường hợp kinh doanh là LÝ DO dự án tồn tại | ⚠ mọi yêu cầu phải phục vụ nó | | ⚠ Nó chứa mục tiêu, lợi ích kỳ vọng và tiêu chí thành công | ⚠ có sẵn thước đo để so sánh | | ⚠ Nó là tài liệu ĐÃ ĐƯỢC PHÊ DUYỆT | ⚠ quyết định dựa trên nó thì bảo vệ được trước mọi bên | | ⚠ Nó khách quan, không phụ thuộc ý kiến cá nhân | ⚠ loại bỏ tranh cãi về uy tín và kinh nghiệm | | ⚠ Kết luận | ⚠ khi hai yêu cầu xung đột, hỏi "cái nào phục vụ mục đích của dự án tốt hơn" |
⚠ Bối cảnh làm cho đáp án càng đúng: ⚠ dự án đã đi được nửa giai đoạn thứ ba trong năm giai đoạn ⚠ — ⚠ quyết định lúc này ảnh hưởng tới phần còn lại, nên nó phải dựa trên tài liệu định hướng chứ không dựa trên cảm tính hay áp lực của người nào.
Vì sao các phương án khác sai
-
C (yêu cầu tạo ra ROI cao nhất) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ ROI là một tiêu chí khách quan, định lượng, và nghe rất "chuyên nghiệp" — nhiều người coi nó là câu trả lời an toàn cho mọi quyết định: ⚠ nhưng ⚠ ROI chỉ là MỘT PHẦN của trường hợp kinh doanh ⚠ — ⚠ một dự án có thể tồn tại vì lý do tuân thủ pháp luật, vì an toàn, vì chiến lược dài hạn hay vì uy tín, và trong những trường hợp đó yêu cầu có ROI cao nhất chưa chắc là yêu cầu đúng; ⚠ trường hợp kinh doanh bao gồm ROI và nhiều hơn thế; ⚠ liên hệ #26707 cùng lô.
-
A (yêu cầu rút ngắn tiến độ) — ⚠ lấy MỘT ràng buộc làm tiêu chí duy nhất; ⚠ nhanh hơn không đồng nghĩa với giá trị hơn.
-
B (yêu cầu do bên liên quan NHIỀU KINH NGHIỆM HƠN đề xuất) — ⚠ quyết định theo UY TÍN CÁ NHÂN thay vì theo dữ liệu; ⚠ đây là dạng phương án gần như luôn sai trong đề PMP.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26707 cùng lô (ROI — một phần của trường hợp kinh doanh), ⚠ #26713 cùng lô (KPI và tiêu chí thành công), ⚠ #26723 cùng lô (nhận diện nhu cầu), ⚠ #26710 cùng lô (ban kiểm soát thay đổi xét theo giá trị), ⚠ #26652 lô 198 (giai đoạn trước khi dự án bắt đầu).
⚠ TRƯỜNG HỢP KINH DOANH chứa gì: | Mục | Nội dung | |---|---| | ⚠ Nhu cầu kinh doanh | ⚠ vấn đề hoặc cơ hội — liên hệ #26723 cùng lô | | ⚠ Phân tích tình huống | ⚠ các phương án đã cân nhắc và lý do chọn | | ⚠ Lợi ích kỳ vọng | ⚠ định lượng và định tính | | ⚠ Phân tích tài chính | ⚠ ROI, NPV, thời gian hoàn vốn — phương án C chỉ là phần này | | ⚠ Rủi ro chính và giả định | | | ⚠ Tiêu chí thành công | | | ⚠ Vì sao nó là tài liệu quan trọng nhất mà ít người đọc | ⚠ nó được viết trước khi dự án bắt đầu rồi cất đi — trong khi nó chính là thứ trả lời được phần lớn các câu hỏi khó xuất hiện ở giữa dự án, đúng như tình huống của Liza |
⚠ Liza nên xử lý xung đột yêu cầu theo trình tự nào: | Bước | Việc | |---|---| | ⚠ 1. Xác nhận hai yêu cầu THẬT SỰ xung đột | ⚠ đôi khi chúng chỉ mâu thuẫn ở cách diễn đạt | | ⚠ 2. Đọc lại trường hợp kinh doanh và hiến chương | ⚠ ĐÁP ÁN — tìm tiêu chí đã được duyệt | | ⚠ 3. Phân tích tác động của từng phương án | ⚠ chi phí, tiến độ, rủi ro, lợi ích | | ⚠ 4. Trao đổi với các bên liên quan chủ chốt | ⚠ có thể có phương án thứ ba — liên hệ #26722 cùng lô | | ⚠ 5. Đưa qua kiểm soát thay đổi nếu ảnh hưởng đường cơ sở | ⚠ liên hệ #26710 cùng lô | | ⚠ 6. Ghi lại quyết định và LÝ DO | ⚠ để sáu tháng sau không ai phải đoán | | ⚠ Điều quan trọng nhất | ⚠ quyết định phải có CĂN CỨ VIẾT RA — bên bị từ chối cần thấy rằng mình thua một tiêu chí khách quan, không phải thua một người |
⚠ Vì sao "người có kinh nghiệm hơn thì đúng hơn" là bẫy: | Vấn đề | Nội dung | |---|---| | ⚠ Kinh nghiệm không thay thế được dữ liệu về DỰ ÁN NÀY | | | ⚠ Nó tạo tiền lệ: ai có chức vụ cao hơn thì thắng | ⚠ các yêu cầu sau sẽ được quyết theo cách đó | | ⚠ Bên liên quan ít kinh nghiệm hơn có thể đại diện người dùng thật | | | ⚠ Nó không giải thích được VÌ SAO — chỉ giải thích được AI | | | ⚠ Ghi nhớ cho đề thi | ⚠ mọi phương án dạng "theo ý người quan trọng hơn", "theo cảm nhận của quản lý dự án", "theo người nói to nhất" đều gần như chắc chắn sai — PMI luôn chọn quyết định dựa trên dữ liệu và trên tài liệu đã được phê duyệt |
Từ khoá nhận diện:
"hai yêu cầu xung đột, dựa vào đâu để chọn" → ⚠ TRƯỜNG HỢP KINH DOANH "ROI cao nhất" → ⚠ chỉ một phần của trường hợp kinh doanh "người kinh nghiệm hơn đề xuất" → ⚠ quyết theo uy tín, gần như luôn sai "cái nào nhanh hơn" → ⚠ một ràng buộc, không phải tiêu chí giá trị
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đọc trường hợp kinh doanh của dự án mình chưa | ⚠ rất nhiều người quản lý dự án chưa từng mở nó ra | | Quyết định gần nhất của bạn dựa trên tài liệu nào | | | Khi từ chối một yêu cầu, bạn giải thích bằng tiêu chí hay bằng thẩm quyền | |
Và điều mà một tài liệu viết từ trước khi dự án bắt đầu vẫn còn làm được ở giữa giai đoạn thứ ba: nó trả lời giúp bạn câu hỏi mà không bên liên quan nào chịu nhường nhau — không phải bằng quyền lực, mà bằng lý do khiến tất cả họ có mặt ở đây ngay từ đầu.
- A Stop monitoring the issues as they have not impacted the project yet.
- B Apply the appropriate response once the risks begin to impact the project.
- C Take immediate action as outlined in the risk register.
- D Have the product owner monitor the risks.
Xem giải thích
Đáp án
B — ÁP DỤNG PHẢN ỨNG PHÙ HỢP KHI CÁC RỦI RO BẮT ĐẦU TÁC ĐỘNG TỚI DỰ ÁN.
Vì sao đúng
⚠ Trạng thái hiện tại của các rủi ro trong đề: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Đã được NHẬN DIỆN sớm và ghi vào sổ | ⚠ công việc nhận diện đã làm đúng | | ⚠ Leslie ĐANG THEO DÕI SÁT | ⚠ giám sát rủi ro đang chạy | | ⚠ CHƯA rủi ro nào tác động tới dự án | ⚠ chưa xảy ra, chưa kích hoạt | | ⚠ Rủi ro là sự kiện BẤT ĐỊNH | ⚠ chưa xảy ra thì chưa cần dùng phản ứng | | ⚠ Kết luận | ⚠ tiếp tục theo dõi, và triển khai phản ứng đã chuẩn bị đúng lúc rủi ro bắt đầu hiện thực hoá |
⚠ Đây chính là bản chất của KẾ HOẠCH DỰ PHÒNG: ⚠ chuẩn bị trước, kích hoạt khi có TÍN HIỆU KÍCH HOẠT (risk trigger) ⚠ — ⚠ hành động quá sớm là tiêu nguồn lực cho một chuyện có thể không bao giờ xảy ra; hành động quá muộn là mất cơ hội xử lý.
Vì sao các phương án khác sai
-
C (hành động ngay theo những gì đã ghi trong sổ đăng ký rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe rất chủ động và có kỷ luật, đúng kiểu "phòng bệnh hơn chữa bệnh", và sổ đăng ký rủi ro đúng là nơi ghi phản ứng: ⚠ nhưng ⚠ nó tiêu tiền và thời gian cho các sự kiện CHƯA XẢY RA và có thể KHÔNG BAO GIỜ xảy ra ⚠ — ⚠ phần lớn rủi ro trong sổ sẽ không hiện thực hoá, đó là lý do người ta phân biệt phản ứng CHỦ ĐỘNG với phản ứng DỰ PHÒNG; ⚠ ngoại lệ: các phản ứng dạng GIẢM NHẸ và NÉ TRÁNH thì có thể phải làm trước — nhưng đề không nói các rủi ro này thuộc loại đó, và đề cũng không nói có gì thay đổi để cần hành động ngay.
-
A (ngừng theo dõi vì chưa có gì xảy ra) — ⚠ sai hoàn toàn; ⚠ rủi ro chưa xảy ra không có nghĩa là đã biến mất, và xác suất có thể thay đổi theo giai đoạn dự án.
-
D (giao cho chủ sản phẩm theo dõi) — ⚠ đẩy trách nhiệm sai người; ⚠ chủ sản phẩm lo giá trị và tồn đọng, còn theo dõi rủi ro là việc của cả đội với scrum master hỗ trợ.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26536 lô 196 và ⚠ #26628 lô 197 (tín hiệu kích hoạt rủi ro), ⚠ #26659 lô 198 (báo cáo rủi ro), ⚠ #26607 lô 197 (giá trị tiền tệ kỳ vọng và quyết định giảm nhẹ), ⚠ #26703 cùng lô (chuyển giao rủi ro bằng hợp đồng).
⚠ VÒNG ĐỜI của một rủi ro: | Giai đoạn | Việc làm | |---|---| | ⚠ NHẬN DIỆN | ⚠ ghi vào sổ đăng ký rủi ro | | ⚠ PHÂN TÍCH | ⚠ xác suất và tác động, xếp thứ tự ưu tiên | | ⚠ LẬP PHẢN ỨNG | ⚠ chọn chiến lược, ghi rõ tín hiệu kích hoạt và chủ rủi ro | | ⚠ GIÁM SÁT | ⚠ TRẠNG THÁI HIỆN TẠI CỦA LESLIE — theo dõi tín hiệu | | ⚠ TRIỂN KHAI PHẢN ỨNG | ⚠ ĐÁP ÁN — khi tín hiệu xuất hiện | | ⚠ ĐÓNG rủi ro | ⚠ khi đã xảy ra và xử lý xong, hoặc khi không còn khả năng xảy ra | | ⚠ Điểm hay bị bỏ | ⚠ bước ĐÓNG — sổ rủi ro không bao giờ được dọn sẽ phình ra tới mức không ai đọc, và khi đó việc giám sát chỉ còn là hình thức |
⚠ Phản ứng nào làm TRƯỚC, phản ứng nào ĐỢI tín hiệu: | Loại phản ứng | Thời điểm | |---|---| | ⚠ NÉ TRÁNH | ⚠ LÀM TRƯỚC — đổi kế hoạch để rủi ro không còn khả năng xảy ra | | ⚠ GIẢM NHẸ | ⚠ LÀM TRƯỚC — hạ xác suất hoặc tác động | | ⚠ CHUYỂN GIAO | ⚠ LÀM TRƯỚC — mua bảo hiểm, ký hợp đồng | | ⚠ KẾ HOẠCH DỰ PHÒNG | ⚠ CHUẨN BỊ trước, KÍCH HOẠT khi có tín hiệu — ĐÁP ÁN | | ⚠ CHẤP NHẬN BỊ ĐỘNG | ⚠ không làm gì, xử lý khi xảy ra | | ⚠ Vì sao câu này chọn nhóm dự phòng | ⚠ đề nói Leslie đang THEO DÕI các rủi ro chứ không nói còn hành động phòng ngừa nào chưa làm — bối cảnh là giám sát, nên câu trả lời thuộc về việc chờ tín hiệu |
⚠ Leslie nên làm gì trong khi chờ: | Việc | Nội dung | |---|---| | ⚠ Rà lại TÍN HIỆU KÍCH HOẠT có còn phù hợp không | ⚠ dự án đã sang vòng lặp thứ chín, bối cảnh có thể đã đổi | | ⚠ Đánh giá lại xác suất và tác động | ⚠ rủi ro không phải hằng số | | ⚠ Xác nhận mỗi rủi ro đều có CHỦ RỦI RO | ⚠ người theo dõi và người quyết định kích hoạt | | ⚠ Kiểm tra quỹ dự phòng còn đủ không | | | ⚠ Đưa rủi ro vào cuộc trò chuyện hằng ngày của đội | ⚠ một dòng trong buổi họp đứng là đủ | | ⚠ Cảnh báo | ⚠ rủi ro theo dõi lâu mà không xảy ra dễ tạo cảm giác an toàn giả — và đó thường là lúc người ta ngừng nhìn, ngay trước khi nó xảy ra thật |
Từ khoá nhận diện:
"rủi ro đã nhận diện nhưng chưa tác động" → ⚠ TIẾP TỤC THEO DÕI, phản ứng khi bắt đầu tác động "hành động ngay theo sổ rủi ro" → ⚠ tiêu nguồn lực cho việc chưa xảy ra "ngừng theo dõi" → ⚠ luôn sai "giao cho chủ sản phẩm" → ⚠ sai người chịu trách nhiệm
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi rủi ro trong sổ của bạn có tín hiệu kích hoạt cụ thể không | ⚠ "khi nào thì ta biết nó đang xảy ra" | | Mỗi rủi ro có một người chịu trách nhiệm không | | | Lần cuối bạn cập nhật sổ rủi ro là khi nào | |
Và điều làm nên giá trị của một kế hoạch dự phòng chưa được dùng tới: nó không tốn gì cho tới ngày cần, và vào đúng ngày đó, nó là khác biệt giữa một phản ứng bình tĩnh và một cuộc chạy chữa.
- A This is acceptable. Lessons learned are intended to be documented at project completion, and Marc did not do anything outside the process.
- B Lessons learned should only be documented at project completion. Marc is on the right track.
- C It is fine this time as the customers are happy with the project results.
- D Lessons learned are documented during the project as well as at project completion. Marc must improve on this in the future.
Xem giải thích
Đáp án
D — BÀI HỌC KINH NGHIỆM PHẢI ĐƯỢC GHI TRONG SUỐT DỰ ÁN CHỨ KHÔNG CHỈ Ở LÚC KẾT THÚC; MARC CẦN CẢI THIỆN ĐIỀU NÀY.
Vì sao đúng
⚠ Vì sao ghi trong suốt dự án mới đúng: | Lý do | Nội dung | |---|---| | ⚠ Sổ bài học (lessons learned register) là tài liệu SỐNG | ⚠ cập nhật liên tục, không phải sản phẩm cuối | | ⚠ Bài học ghi muộn thì mất chi tiết | ⚠ sau nhiều tháng chỉ còn nhớ kết luận, không còn nhớ bối cảnh | | ⚠ Bài học ghi sớm dùng được NGAY trong chính dự án đó | ⚠ giai đoạn sau học từ giai đoạn trước | | ⚠ Người rời dự án giữa chừng mang theo hiểu biết của họ | ⚠ không ghi lúc đó là mất vĩnh viễn | | ⚠ Marc có "nhiều thách thức" — đó là kho bài học quý nhất | ⚠ và phần lớn đã bị mất chi tiết | | ⚠ Kết luận | ⚠ ghi lúc kết thúc là tốt hơn không ghi, nhưng vẫn là làm chưa đúng quy trình |
⚠ Vai trò của bạn trong đề là quản lý PMO đang KIỂM TOÁN quy trình: ⚠ nhiệm vụ là chỉ ra sai lệch so với quy trình chuẩn một cách xây dựng, không phải phủ nhận kết quả tốt của Marc ⚠ — ⚠ dự án thành công và quy trình chưa đúng là hai chuyện có thể cùng tồn tại.
Vì sao các phương án khác sai
-
A (chấp nhận được, bài học vốn được ghi lúc kết thúc, Marc không làm sai gì) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó phản ánh đúng THỰC TẾ ở rất nhiều tổ chức, nơi bài học chỉ được viết trong buổi tổng kết cuối cùng — nên nó "nghe quen tai": ⚠ nhưng ⚠ thực tế phổ biến không phải là quy trình đúng ⚠ — ⚠ PMBOK nói rõ sổ bài học được tạo SỚM và cập nhật SUỐT vòng đời, rồi mới chuyển thành kho bài học của tổ chức khi đóng dự án; ⚠ và với vai trò kiểm toán quy trình, chấp nhận sai lệch là bỏ đúng nhiệm vụ của mình.
-
B (chỉ nên ghi lúc kết thúc, Marc đang đi đúng hướng) — ⚠ khẳng định sai một cách rõ ràng hơn cả phương án A.
-
C (lần này bỏ qua vì khách hàng hài lòng) — ⚠ lấy KẾT QUẢ để biện minh cho QUY TRÌNH; ⚠ nếu áp dụng nhất quán thì mọi quy trình đều có thể bỏ qua khi may mắn.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26689 cùng lô (lưu trữ khi đóng dự án), ⚠ #26661 lô 198 (dữ liệu lịch sử để ước lượng), ⚠ #26704 cùng lô (hồi cứu — cơ chế agile để làm đúng việc này), ⚠ #26719 cùng lô (truyền tri thức qua cố vấn), ⚠ #26639 lô 198 (học từ lỗi thoát ra ngoài).
⚠ SỔ BÀI HỌC và KHO BÀI HỌC — hai thứ khác nhau: | Tiêu chí | SỔ BÀI HỌC (register) | KHO BÀI HỌC (repository) | |---|---|---| | ⚠ Thuộc về | ⚠ một dự án cụ thể | ⚠ cả tổ chức | | ⚠ Khi nào lập | ⚠ SỚM, ngay đầu dự án | ⚠ tích luỹ qua nhiều dự án | | ⚠ Cập nhật | ⚠ LIÊN TỤC suốt dự án — điều Marc đã bỏ qua | ⚠ mỗi khi một dự án đóng | | ⚠ Ai dùng | ⚠ chính đội đó, ngay trong dự án | ⚠ các dự án tương lai — liên hệ #26661 lô 198 | | ⚠ Quan hệ | ⚠ sổ bài học được chuyển vào kho bài học ở bước đóng dự án — nên sổ nghèo nàn thì kho cũng nghèo nàn | |
⚠ Khi nào nên ghi bài học trong suốt dự án: | Thời điểm | Nội dung | |---|---| | ⚠ Cuối mỗi giai đoạn hoặc mỗi mốc | ⚠ nhịp tự nhiên nhất | | ⚠ Sau mỗi sự cố hoặc vấn đề lớn | ⚠ lúc chi tiết còn tươi mới | | ⚠ Khi một rủi ro xảy ra và được xử lý | ⚠ liên hệ #26725 cùng lô | | ⚠ Khi một thành viên rời dự án | ⚠ phỏng vấn ngắn trước khi họ đi | | ⚠ Sau mỗi vòng lặp trong dự án agile | ⚠ hồi cứu chính là cơ chế này — liên hệ #26704 cùng lô | | ⚠ Mẹo thực dụng | ⚠ giữ một mục cố định "bài học" trong biên bản họp hằng tuần — mất một phút mỗi tuần, và nó thay thế được cả buổi cố nhớ lại vào cuối dự án |
⚠ Cách góp ý với Marc cho hiệu quả: | Nên | Không nên | |---|---| | ⚠ Ghi nhận kết quả tốt trước | ⚠ mở đầu bằng lỗi quy trình | | ⚠ Chỉ rõ quy trình chuẩn nói gì | ⚠ nói chung chung "làm chưa đúng" | | ⚠ Giải thích VÌ SAO thời điểm ghi lại quan trọng | ⚠ chỉ viện dẫn quy định | | ⚠ Gợi ý cách làm cụ thể cho lần sau | ⚠ để anh tự nghĩ ra | | ⚠ Hỏi vì sao lần này không làm được | ⚠ giả định là do lười | | ⚠ Lý do nên hỏi vế cuối | ⚠ "nhiều thách thức trong dự án" có thể chính là lý do — khi liên tục chữa cháy thì việc ghi chép luôn là thứ bị bỏ đầu tiên, và đó là vấn đề của hệ thống chứ không của riêng Marc |
Từ khoá nhận diện:
"chỉ ghi bài học lúc kết thúc" → ⚠ CHƯA ĐÚNG — phải ghi suốt dự án "khách hàng hài lòng nên bỏ qua" → ⚠ lấy kết quả biện minh cho quy trình "sổ bài học" → ⚠ tài liệu sống của một dự án "kho bài học" → ⚠ tài sản quy trình của tổ chức
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có sổ bài học đang được cập nhật không | | | Lần cuối bạn thêm một dòng vào đó là khi nào | | | Bạn có đọc bài học của dự án trước khi bắt đầu dự án này không | ⚠ nếu không ai đọc thì việc ghi cũng vô nghĩa |
Và điều mà một sổ bài học chỉ được viết vào ngày cuối cùng đã đánh mất: không phải các kết luận — chúng vẫn còn — mà là những chi tiết đã khiến các kết luận ấy trở nên hữu ích cho người chưa từng ở trong hoàn cảnh đó.
- A Better quality
- B Visible progress
- C Ability to steer and influence the project
- D Work-life balance
Xem giải thích
Đáp án
D — CÂN BẰNG CÔNG VIỆC – CUỘC SỐNG (work-life balance).
Vì sao đúng
⚠ Câu hỏi phủ định: nhóm này là ai và họ quan tâm gì: | Phương án | Nhà phân phối có quan tâm không | |---|---| | ⚠ A — chất lượng tốt hơn | ⚠ CÓ — sản phẩm tốt thì dễ bán, ít bảo hành, ít khiếu nại | | ⚠ B — tiến trình rõ ràng nhìn thấy được | ⚠ CÓ — họ cần biết khi nào có hàng để lên kế hoạch kinh doanh | | ⚠ C — khả năng góp ý và tác động lên dự án | ⚠ CÓ — họ hiểu thị trường, muốn ảnh hưởng tới tính năng và bao bì | | ⚠ D — CÂN BẰNG CÔNG VIỆC – CUỘC SỐNG | ⚠ KHÔNG — ĐÁP ÁN |
⚠ Vì sao D lạc loài: ⚠ cân bằng công việc – cuộc sống là mối quan tâm của ĐỘI DỰ ÁN, tức là bên liên quan NỘI BỘ ⚠ — ⚠ nhà phân phối là bên liên quan BÊN NGOÀI, họ quan tâm tới sản phẩm và tới việc bán được hàng, không quan tâm giờ làm việc của đội bạn; ⚠ liên hệ #26674 lô 198, nơi cân bằng nhịp độ là mối quan tâm của chính đội.
Vì sao các phương án khác sai
-
C (khả năng góp ý và tác động lên dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nhiều người cho rằng nhà phân phối chỉ là bên mua đi bán lại, không có tiếng nói gì trong việc phát triển sản phẩm: ⚠ nhưng ⚠ đại lý bán hàng nắm phản hồi trực tiếp từ người mua và thường có ảnh hưởng thật tới bao bì, giá, tính năng và thời điểm ra mắt ⚠ — ⚠ và đề nói rõ bạn mang sản phẩm tới hội chợ để giới thiệu với chính họ, tức là bạn đang tìm sự ủng hộ của họ; ⚠ một bên liên quan đủ quan trọng để bạn đi hội chợ gặp thì chắc chắn có nhu cầu được lắng nghe.
-
A (chất lượng tốt hơn) — ⚠ mối quan tâm hàng đầu; ⚠ đề còn nói rõ dự án sinh ra vì người dùng không hài lòng với thiết bị hiện tại.
-
B (tiến trình rõ ràng) — ⚠ họ cần biết lịch để chuẩn bị kho, quảng cáo, đội bán hàng.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26674 lô 198 (nhịp độ bền vững — mối quan tâm nội bộ), ⚠ #26687 cùng lô (phân loại bên liên quan), ⚠ #26645 lô 198 (chiến lược theo từng nhóm bên liên quan), ⚠ #26641 lô 198 (mỗi nhóm cần kiểu thông tin khác nhau), ⚠ #26731 cùng lô (khi nào bắt đầu quản lý bên liên quan).
⚠ MỐI QUAN TÂM theo từng nhóm bên liên quan: | Nhóm | Quan tâm điển hình | |---|---| | ⚠ ĐỘI DỰ ÁN | ⚠ khối lượng công việc, nhịp độ bền vững, phát triển nghề nghiệp, sự ghi nhận — bao gồm CÂN BẰNG CÔNG VIỆC – CUỘC SỐNG | | ⚠ NHÀ TÀI TRỢ | ⚠ lợi ích kinh doanh, ngân sách, rủi ro lớn | | ⚠ KHÁCH HÀNG / NGƯỜI DÙNG CUỐI | ⚠ sản phẩm giải quyết được vấn đề của họ, dễ dùng, giá hợp lý | | ⚠ NHÀ PHÂN PHỐI / ĐẠI LÝ | ⚠ chất lượng, thời điểm có hàng, biên lợi nhuận, hỗ trợ bán hàng, được góp ý — CÂU NÀY | | ⚠ CƠ QUAN QUẢN LÝ | ⚠ tuân thủ quy định, an toàn | | ⚠ Nguyên tắc phân tích | ⚠ hỏi "nhóm này ĐƯỢC gì và MẤT gì từ dự án" — mối quan tâm của họ luôn nằm trong câu trả lời, và những gì không nằm trong đó thì không phải mối quan tâm của họ |
⚠ Vì sao nhà phân phối là nhóm đáng đầu tư công sức: | Lý do | Nội dung | |---|---| | ⚠ Họ đứng giữa sản phẩm và người mua | ⚠ họ quyết định sản phẩm được trưng bày và giới thiệu thế nào | | ⚠ Họ nắm dữ liệu thị trường thật | ⚠ biết đối thủ đang làm gì, khách hỏi gì | | ⚠ Họ có thể là kênh phản hồi nhanh nhất sau khi ra mắt | | | ⚠ Sự thờ ơ của họ đủ để một sản phẩm tốt thất bại | ⚠ có hàng mà không ai bán thì không bán được | | ⚠ Việc nên làm ở hội chợ | ⚠ không chỉ giới thiệu sản phẩm mà còn LẮNG NGHE — đây là cơ hội thu thập yêu cầu từ một nhóm hiểu thị trường, và nó rẻ hơn nhiều so với việc phát hiện ra vấn đề sau khi đã sản xuất hàng loạt |
⚠ Mẹo làm câu hỏi phủ định về mối quan tâm: | Bước | Nội dung | |---|---| | ⚠ 1. Xác định nhóm được hỏi là NỘI BỘ hay BÊN NGOÀI | ⚠ ở đây là bên ngoài | | ⚠ 2. Loại các phương án thuộc phạm trù của nhóm kia | ⚠ cân bằng công việc – cuộc sống là mối quan tâm nội bộ | | ⚠ 3. Kiểm lại các phương án còn lại đều hợp lý không | | | ⚠ Dấu hiệu của đáp án đúng trong câu phủ định | ⚠ nó thường thuộc một PHẠM TRÙ khác hẳn ba phương án còn lại, chứ không phải sai một chút về mức độ — liên hệ #26696 cùng lô, nơi "thẩm quyền" lạc loài giữa ba năng lực cá nhân |
Từ khoá nhận diện:
"cân bằng công việc – cuộc sống" → ⚠ mối quan tâm của ĐỘI, không phải của bên ngoài "chất lượng, tiến trình, được góp ý" → ⚠ mối quan tâm điển hình của đối tác kinh doanh câu hỏi phủ định → ⚠ tìm phương án LẠC PHẠM TRÙ "đại lý bán hàng" → ⚠ bên liên quan bên ngoài, có ảnh hưởng thật tới thành công thương mại
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết mối quan tâm THẬT của từng nhóm bên liên quan không | ⚠ hỏi họ, đừng giả định | | Có nhóm nào bạn đang giao tiếp bằng ngôn ngữ của nhóm khác không | | | Kênh phản hồi từ người bán hàng về đội dự án là gì | |
Và điều mà một gian hàng ở hội chợ đáng giá hơn cả việc trưng bày sản phẩm: nó cho bạn nửa ngày ngồi nghe những người sẽ phải thuyết phục khách mua nói về thứ bạn vừa làm ra — thông tin mà không bản khảo sát nào mua được.
- A One that he should request in a totally separate project.
- B Acceptable, but it will delay the team by an entire sprint.
- C Appropriate for an agile project, where good design is important to the ability to maintain software.
- D Only appropriate once the project is nearing completion.
Xem giải thích
Đáp án
C — PHÙ HỢP VỚI MỘT DỰ ÁN AGILE, nơi thiết kế tốt là điều kiện để duy trì được phần mềm.
Vì sao đúng
⚠ Vì sao tái cấu trúc thường xuyên là thực hành đúng: | Lý do | Nội dung | |---|---| | ⚠ Nguyên tắc agile: "chú ý liên tục tới sự xuất sắc kỹ thuật và thiết kế tốt làm tăng sự linh hoạt" | ⚠ một trong 12 nguyên tắc của Tuyên ngôn Agile | | ⚠ Tái cấu trúc là dọn cấu trúc mã mà KHÔNG đổi hành vi | ⚠ không phải làm lại, không phải thêm tính năng | | ⚠ Nó là bước thứ ba của vòng lặp TDD | ⚠ liên hệ #26695 cùng lô — đỏ, xanh, tái cấu trúc | | ⚠ Làm đều đặn mỗi sprint thì chi phí nhỏ và đều | ⚠ để dồn lại thì thành một dự án riêng | | ⚠ Kết luận | ⚠ yêu cầu của Thomas là hợp lý và nên được ủng hộ |
⚠ Lập luận kinh tế đằng sau: ⚠ mã khó đọc làm mọi thay đổi về sau chậm hơn — nợ kỹ thuật tính lãi bằng thời gian của đội ⚠ — ⚠ tái cấu trúc là khoản trả góp đều đặn cho món nợ đó.
Vì sao các phương án khác sai
-
B (chấp nhận được nhưng sẽ làm đội trễ nguyên một sprint) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó thừa nhận tái cấu trúc là việc nên làm, nên nghe như một câu trả lời cân bằng và thực tế: ⚠ nhưng ⚠ Thomas xin dành MỘT PHẦN thời gian trong mỗi sprint, không xin cả một sprint ⚠ — ⚠ tái cấu trúc liên tục được làm XEN KẼ với việc phát triển tính năng, thường ngay khi đang sửa chính đoạn mã đó; ⚠ con số "trễ nguyên một sprint" là suy diễn sai về quy mô của việc anh đề xuất.
-
A (nên đề nghị làm thành một dự án riêng) — ⚠ tách tái cấu trúc thành dự án riêng là dấu hiệu nợ kỹ thuật đã tích luỹ quá lâu; ⚠ nó đắt hơn nhiều, khó xin duyệt và không tạo giá trị nhìn thấy được cho bên liên quan.
-
D (chỉ phù hợp khi dự án gần kết thúc) — ⚠ ngược hoàn toàn; ⚠ tái cấu trúc cuối dự án là lúc rủi ro cao nhất và lợi ích thấp nhất, vì không còn thời gian để hưởng lợi từ nó.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26695 cùng lô (TDD — tái cấu trúc là bước thứ ba), ⚠ #26639 lô 198 (lỗi lọt ra ngoài), ⚠ #26711 cùng lô (giữ phạm vi tối thiểu, không làm thừa), ⚠ #26704 cùng lô (hồi cứu — nơi đội đề xuất cải tiến kỹ thuật), ⚠ #26651 lô 198 (định nghĩa hoàn thành nên bao gồm chất lượng mã).
⚠ NỢ KỸ THUẬT — vì sao phải trả đều: | Đặc điểm | Nội dung | |---|---| | ⚠ Sinh ra từ các quyết định nhanh, tạm thời | ⚠ đôi khi là lựa chọn có ý thức và hợp lý | | ⚠ "Lãi" của nó là THỜI GIAN | ⚠ mỗi thay đổi sau đều chậm hơn một chút | | ⚠ Tích luỹ âm thầm, không hiện trên báo cáo nào | ⚠ cho tới khi vận tốc bắt đầu giảm | | ⚠ Trả đều thì rẻ, trả dồn thì rất đắt | ⚠ giống hệt nợ tài chính | | ⚠ Có thể ghi vào tồn đọng như một hạng mục | ⚠ để nó nhìn thấy được và xếp ưu tiên được | | ⚠ Dấu hiệu nợ kỹ thuật đang quá tải | ⚠ ước lượng cho các tính năng đơn giản ngày càng cao, lỗi hồi quy xuất hiện nhiều, và không ai muốn đụng vào một mô-đun nào đó — đó là lúc phương án A trở thành lựa chọn duy nhất còn lại, và đó là điều Thomas đang cố tránh |
⚠ Tái cấu trúc — làm đúng cách: | Nguyên tắc | Nội dung | |---|---| | ⚠ Phải có KIỂM THỬ tự động bảo vệ | ⚠ không có lưới an toàn thì tái cấu trúc là sửa mù — liên hệ #26695 cùng lô | | ⚠ Từng bước nhỏ, giữ mã luôn chạy được | | | ⚠ KHÔNG đổi hành vi | ⚠ đổi hành vi là làm tính năng, không phải tái cấu trúc | | ⚠ Ưu tiên chỗ sắp phải sửa tiếp | ⚠ dọn nơi bạn sắp làm việc, không dọn nơi không ai đụng tới | | ⚠ Đưa vào định nghĩa hoàn thành | ⚠ để nó là một phần của công việc, không phải việc thêm | | ⚠ Cách trình bày với bên liên quan | ⚠ đừng gọi nó là "dọn dẹp mã" — hãy nói về việc GIỮ TỐC ĐỘ GIAO HÀNG trong các tháng tới; đó là điều bên liên quan quan tâm và cũng là điều tái cấu trúc thật sự mang lại |
⚠ Ranh giới cần giữ: | Việc | Đánh giá | |---|---| | ⚠ Dành một phần mỗi sprint để dọn mã đang làm việc cùng | ⚠ ĐÚNG — đáp án | | ⚠ Viết lại toàn bộ hệ thống vì không thích thiết kế cũ | ⚠ SAI — đó là dự án mới trá hình | | ⚠ Tái cấu trúc mà không có kiểm thử | ⚠ RỦI RO CAO | | ⚠ Gộp tái cấu trúc với việc thêm tính năng trong cùng một thay đổi | ⚠ khó rà soát, khó tìm nguyên nhân khi hỏng | | ⚠ Ghi nhớ | ⚠ tái cấu trúc là kỷ luật, không phải sở thích — nó luôn phải trả lời được câu hỏi "việc này giúp chúng ta giao hàng nhanh hơn hoặc an toàn hơn ở chỗ nào" |
Từ khoá nhận diện:
"dành một phần mỗi sprint để tái cấu trúc" → ⚠ PHÙ HỢP với dự án agile "tách thành dự án riêng" → ⚠ dấu hiệu nợ kỹ thuật đã quá muộn "trễ nguyên một sprint" → ⚠ hiểu sai quy mô của đề xuất "chỉ làm khi gần xong" → ⚠ ngược với nguyên tắc agile
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vận tốc của đội bạn có đang giảm dần không | ⚠ đó là triệu chứng nợ kỹ thuật kinh điển | | Có mô-đun nào không ai muốn đụng vào không | | | Định nghĩa hoàn thành của bạn có nói gì về chất lượng mã không | |
Và điều mà mười phần trăm thời gian mỗi sprint dành cho việc dọn dẹp thật sự mua được: quyền vẫn giao được tính năng với tốc độ hôm nay vào tháng thứ mười tám — thứ mà mọi đội đều muốn, và rất ít đội chịu trả giá đều đặn để có.
- A The number of test scripts that have been run.
- B The amount of project work that is left to be completed.
- C When team members' vacations can be scheduled.
- D The number of members leaving the project.
Xem giải thích
Đáp án
B — KHỐI LƯỢNG CÔNG VIỆC DỰ ÁN CÒN LẠI PHẢI HOÀN THÀNH.
Vì sao đúng
⚠ Biểu đồ burndown là gì: | Yếu tố | Nội dung | |---|---| | ⚠ Trục ngang | ⚠ thời gian: ngày trong sprint, hoặc số vòng lặp | | ⚠ Trục dọc | ⚠ CÔNG VIỆC CÒN LẠI: điểm câu chuyện hoặc giờ | | ⚠ Đường thực tế | ⚠ đi xuống khi công việc được hoàn thành | | ⚠ Đường lý tưởng | ⚠ đường thẳng từ tổng ban đầu về 0 | | ⚠ Điểm chạm 0 | ⚠ thời điểm dự kiến hoàn thành | | ⚠ Kết luận | ⚠ "burn down" nghĩa là đốt dần khối lượng còn lại — tên gọi đã nói hết |
⚠ Giá trị thật của biểu đồ: ⚠ so đường thực tế với đường lý tưởng cho biết đội đang đi trước hay đi sau, và ĐỘ DỐC cho biết tốc độ thật ⚠ — ⚠ một đường phẳng nằm ngang mấy ngày liền là tín hiệu có vật cản mà chưa ai nói ra.
Vì sao các phương án khác sai
-
A (số kịch bản kiểm thử đã chạy) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đó cũng là một con số tăng giảm theo thời gian và cũng hay được vẽ thành biểu đồ trên bảng của đội: ⚠ nhưng ⚠ burndown đo CÔNG VIỆC CÒN LẠI của cả sprint, không đo riêng hoạt động kiểm thử ⚠ — ⚠ và nó đo phần CHƯA LÀM chứ không đo phần ĐÃ LÀM; ⚠ biểu đồ đo phần đã xong có tên riêng là burnup.
-
C (khi nào thành viên có thể nghỉ phép) — ⚠ không liên quan; ⚠ đó là việc của lịch nguồn lực.
-
D (số người rời dự án) — ⚠ cũng không liên quan; ⚠ phương án loại nhanh.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26714 cùng lô (bảng thông tin trực quan — burndown là một ví dụ), ⚠ #26709 cùng lô (vận tốc), ⚠ #26699 cùng lô (dùng vận tốc và tồn đọng để dự báo), ⚠ #26713 cùng lô (KPI), ⚠ #26561 lô 196 (các thước đo agile).
⚠ BURNDOWN và BURNUP — hai biểu đồ anh em: | Tiêu chí | BURNDOWN | BURNUP | |---|---|---| | ⚠ Đường chính đi | ⚠ XUỐNG — công việc còn lại | ⚠ LÊN — công việc đã xong | | ⚠ Có đường tổng phạm vi không | ⚠ KHÔNG | ⚠ CÓ — đường trần riêng | | ⚠ Thấy được phạm vi tăng thêm không | ⚠ KHÓ — đường bị đội lên trông như đội làm chậm | ⚠ RÕ — đường trần dịch lên | | ⚠ Đơn giản để đọc | ⚠ rất đơn giản — ĐÁP ÁN của câu này | ⚠ cần đọc hai đường | | ⚠ Vì sao nhiều đội chuyển sang burnup | ⚠ burndown không phân biệt được "đội làm chậm" với "phạm vi được thêm vào" — và sự nhầm lẫn đó thường khiến đội bị trách oan |
⚠ Đọc một biểu đồ burndown như thế nào: | Hình dạng | Ý nghĩa | |---|---| | ⚠ Bám sát đường lý tưởng | ⚠ đúng nhịp | | ⚠ Nằm trên đường lý tưởng | ⚠ chậm hơn kế hoạch | | ⚠ Nằm dưới | ⚠ nhanh hơn — hoặc ước lượng đã quá rộng rãi | | ⚠ PHẲNG nhiều ngày rồi rơi dốc đứng | ⚠ công việc chỉ được đánh dấu xong vào phút chót — dấu hiệu hạng mục quá lớn hoặc định nghĩa hoàn thành bị hiểu lỏng | | ⚠ ĐI LÊN | ⚠ có việc mới được thêm vào giữa sprint | | ⚠ Điều cần nhớ | ⚠ biểu đồ là để ĐỘI tự điều chỉnh, không phải để quản lý chấm điểm đội — một biểu đồ bị dùng để phán xét sẽ nhanh chóng trở thành một biểu đồ được làm đẹp |
⚠ Vì sao Gordon treo nó lên tường: | Lý do | Nội dung | |---|---| | ⚠ Ai cũng thấy tình trạng mà không cần hỏi | ⚠ liên hệ #26714 cùng lô | | ⚠ Đội tự nhận ra khi bị chậm | ⚠ và tự điều chỉnh trong buổi họp đứng | | ⚠ Vật cản lộ ra dưới dạng đường phẳng | | | ⚠ Bên liên quan đi ngang cũng nắm được | ⚠ giảm số cuộc họp báo cáo tình hình | | ⚠ Điều kiện để nó có tác dụng | ⚠ phải được cập nhật hằng ngày và phải phản ánh sự thật — một biểu đồ cũ ba ngày còn tệ hơn không có biểu đồ nào, vì nó khiến người ta yên tâm dựa trên thông tin sai |
Từ khoá nhận diện:
"công việc CÒN LẠI, đường đi xuống" → ⚠ BURNDOWN "công việc ĐÃ XONG, có đường trần phạm vi" → ⚠ burnup "số kịch bản kiểm thử" → ⚠ một thước đo khác, không phải burndown "lịch nghỉ phép, số người rời đi" → ⚠ không liên quan
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biểu đồ của bạn được cập nhật lần cuối khi nào | | | Nó có phẳng mấy ngày rồi rơi dốc đứng không | ⚠ nếu có, hạng mục của bạn đang quá lớn | | Có ai ngoài đội dùng nó để đánh giá đội không | |
Và điều mà một đường kẻ đi xuống trên tường làm được mà một bảng tiến độ chi tiết không làm được: bất kỳ ai đi ngang qua, kể cả người không biết gì về dự án, đều hiểu ngay trong hai giây rằng mọi thứ đang ổn hay đang không ổn.
- A Strictness or leniency error
- B Recency error
- C Central tendency error
- D Personal Bias
Xem giải thích
Đáp án
B — LỖI GẦN ĐÂY (recency error).
Vì sao đúng
⚠ Tình huống khớp chính xác với định nghĩa: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Leroy vốn có phán đoán và tư cách XUẤT SẮC | ⚠ một lịch sử dài các hành vi tốt | | ⚠ Trước khi dự án khởi động, ông là người ỦNG HỘ mạnh nhất của Jenny | ⚠ thêm bằng chứng tích cực | | ⚠ Vừa xảy ra MỘT sự việc rất tệ | ⚠ tính sai rồi cố chấp bảo vệ cái sai | | ⚠ Jenny đang cân nhắc đề nghị loại ông khỏi dự án | ⚠ một quyết định lớn dựa trên sự việc mới nhất | | ⚠ Nguy cơ | ⚠ để sự việc GẦN NHẤT lấn át toàn bộ lịch sử trước đó — đó chính là lỗi gần đây |
⚠ Chính hành động của Jenny cho thấy cô ý thức được điều này: ⚠ cô quyết định đi xem lại các dự án TRƯỚC ĐÂY của Leroy ⚠ — ⚠ đó là cách chuẩn để chống lỗi gần đây: mở rộng khung thời gian đánh giá.
Vì sao các phương án khác sai
-
D (thiên kiến cá nhân — personal bias) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là một khái niệm rộng và gần như bao trùm mọi loại sai lệch trong đánh giá, nên luôn nghe "không sai": ⚠ nhưng ⚠ chính vì quá rộng nên nó không mô tả được cơ chế cụ thể ở đây ⚠ — ⚠ thiên kiến cá nhân là để cảm tình hoặc ác cảm với một người ảnh hưởng tới đánh giá, còn ở đây vấn đề nằm ở THỜI ĐIỂM của bằng chứng, không phải ở cảm xúc của Jenny với Leroy; ⚠ đề còn nói Jenny "ngạc nhiên", tức là cô không có ác cảm sẵn; ⚠ khi một phương án cụ thể mô tả đúng cơ chế thì nó luôn thắng phương án chung chung.
-
A (lỗi khắt khe hoặc dễ dãi) — ⚠ là việc đánh giá mọi người đều quá cao hoặc đều quá thấp một cách hệ thống; ⚠ không phải vấn đề ở đây.
-
C (lỗi thiên về mức trung bình) — ⚠ là việc cho mọi người điểm giữa để tránh phải giải thích; ⚠ trái ngược với tình huống, nơi Jenny đang cân nhắc một hành động cực đoan.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26696 cùng lô (trí tuệ cảm xúc), ⚠ #26700 cùng lô (chỉ thị chính của hồi cứu — giả định thiện chí), ⚠ #26675 lô 198 (tách vấn đề khỏi con người), ⚠ #26721 cùng lô (bên liên quan quyền lực cao), ⚠ #26687 cùng lô (phân loại bên liên quan).
⚠ CÁC LỖI ĐÁNH GIÁ thường gặp: | Lỗi | Nội dung | |---|---| | ⚠ LỖI GẦN ĐÂY (recency) | ⚠ sự việc mới nhất lấn át cả quá trình dài — ĐÁP ÁN | | ⚠ HIỆU ỨNG HÀO QUANG (halo) | ⚠ giỏi một mặt nên được cho là giỏi mọi mặt | | ⚠ HIỆU ỨNG SỪNG (horn) | ⚠ kém một mặt nên bị cho là kém mọi mặt | | ⚠ LỖI KHẮT KHE / DỄ DÃI | ⚠ chấm ai cũng thấp hoặc ai cũng cao | | ⚠ LỖI TRUNG BÌNH (central tendency) | ⚠ cho ai cũng điểm giữa để khỏi phải giải thích | | ⚠ THIÊN KIẾN TƯƠNG ĐỒNG (similarity) | ⚠ đánh giá cao người giống mình | | ⚠ THIÊN KIẾN XÁC NHẬN (confirmation) | ⚠ chỉ nhìn thấy bằng chứng ủng hộ điều mình đã tin | | ⚠ Cách chống chung cho mọi lỗi | ⚠ dùng BẰNG CHỨNG CỤ THỂ trải trên MỘT KHOẢNG THỜI GIAN DÀI, và ghi lại sự việc ngay khi chúng xảy ra thay vì cố nhớ lại lúc đánh giá |
⚠ Jenny nên làm gì với chính tình huống Leroy: | Bước | Việc | |---|---| | ⚠ Rà lại toàn bộ lịch sử hợp tác | ⚠ cô đang làm — đúng cách chống lỗi gần đây | | ⚠ Tách VẤN ĐỀ khỏi CON NGƯỜI | ⚠ vấn đề là con số người dùng sai, không phải Leroy — liên hệ #26675 lô 198 | | ⚠ Trao đổi riêng với Leroy | ⚠ cho ông một lối ra không mất thể diện — liên hệ #26698 cùng lô | | ⚠ Dùng DỮ LIỆU để giải quyết bất đồng về con số | ⚠ đưa cách tính ra cho bên thứ ba kiểm chứng | | ⚠ Chỉ cân nhắc loại khỏi dự án nếu hành vi lặp lại | ⚠ một lần chưa thành mô thức | | ⚠ Điều đáng cân nhắc nhất | ⚠ một người vốn xuất sắc bỗng cố chấp bảo vệ một sai lầm thường đang chịu áp lực nào đó mà người ngoài chưa thấy — hỏi vì sao thường hữu ích hơn nhiều so với hỏi có nên loại bỏ hay không |
⚠ Vì sao lỗi gần đây đặc biệt nguy hiểm trong dự án: | Lý do | Nội dung | |---|---| | ⚠ Dự án dài, đánh giá lại thường vào cuối | ⚠ ba tháng cuối lấn át chín tháng đầu | | ⚠ Sự cố luôn nhớ lâu hơn thành công đều đặn | | | ⚠ Quyết định về con người khó đảo ngược | ⚠ loại một người khỏi dự án thì quan hệ đã hỏng | | ⚠ Nó cũng chạy theo chiều ngược lại | ⚠ một thành công phút chót có thể xoá sạch cả năm làm việc kém | | ⚠ Biện pháp thực tế | ⚠ ghi nhật ký sự việc — vài dòng mỗi tháng về đóng góp và vấn đề của từng người; nó tốn rất ít và nó là thứ duy nhất chống lại được trí nhớ của chính bạn |
Từ khoá nhận diện:
"sự việc mới nhất lấn át cả quá trình" → ⚠ LỖI GẦN ĐÂY "thiên kiến cá nhân" → ⚠ quá rộng, thua phương án cụ thể "chấm ai cũng cao hoặc cũng thấp" → ⚠ lỗi dễ dãi hoặc khắt khe "cho ai cũng điểm giữa" → ⚠ lỗi trung bình
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đánh giá gần nhất của bạn về một người dựa trên bao nhiêu tháng | | | Bạn có ghi lại sự việc khi chúng xảy ra không | | | Nếu người đó làm điều tương tự hồi đầu dự án, bạn có phản ứng giống vậy không | ⚠ câu hỏi này lộ ra lỗi gần đây rất nhanh |
Và điều mà Jenny làm đúng ngay cả khi chưa biết tên gọi của cái bẫy: cô dừng lại trước khi quyết định về một con người, và đi tìm bằng chứng từ những tháng mà cô không còn nhớ rõ — đó là toàn bộ cách chữa cho lỗi này.
- A At the beginning of the project, to understand stakeholder needs early on, when stakeholders are most likely to accept the change.
- B Near the end of the project, the finished product is ready to be released and utilized.
- C At any time throughout the project, stakeholder engagement is not necessary since the plan is available for everyone to see.
- D An engagement plan is unnecessary as this is a highly visible project, and everyone knows what is taking place.
Xem giải thích
Đáp án
A — TỪ ĐẦU DỰ ÁN, để hiểu nhu cầu của bên liên quan sớm, khi họ còn dễ chấp nhận thay đổi nhất.
Vì sao đúng
⚠ Vì sao càng sớm càng tốt: | Lý do | Nội dung | |---|---| | ⚠ Nhận diện bên liên quan là quy trình thuộc nhóm KHỞI ĐỘNG | ⚠ cùng nhóm với việc lập hiến chương dự án | | ⚠ Ảnh hưởng của bên liên quan CAO NHẤT ở đầu dự án | ⚠ và chi phí thay đổi THẤP NHẤT ở đó | | ⚠ Yêu cầu thu thập sớm thì rẻ | ⚠ phát hiện muộn thì phải làm lại | | ⚠ Người được tham gia sớm ít phản đối về sau | ⚠ họ thấy mình là một phần của quyết định | | ⚠ Dự án lớn và rất nổi bật như trong đề | ⚠ càng nhiều bên liên quan thì càng phải bắt đầu sớm | | ⚠ Kết luận | ⚠ quản lý bên liên quan là hoạt động chạy suốt dự án, bắt đầu ngay từ ngày đầu |
⚠ Đường cong kinh điển: ⚠ KHẢ NĂNG ẢNH HƯỞNG của bên liên quan giảm dần theo thời gian, còn CHI PHÍ THAY ĐỔI tăng dần ⚠ — ⚠ hai đường cắt nhau rất sớm, và mọi giá trị của việc tham gia đều nằm ở phía bên trái điểm cắt đó.
Vì sao các phương án khác sai
-
C (bất cứ lúc nào cũng được, vì kế hoạch đã công khai cho mọi người xem) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó viện dẫn tính minh bạch — một giá trị thật — và nghe như đội đang làm điều đúng khi công khai kế hoạch: ⚠ nhưng ⚠ để tài liệu ở chỗ ai cũng xem được KHÔNG PHẢI là quản lý bên liên quan ⚠ — ⚠ sự gắn kết là hoạt động HAI CHIỀU và CHỦ ĐỘNG: hiểu nhu cầu, trao đổi, điều chỉnh; ⚠ giả định rằng người ta sẽ tự đọc kế hoạch là giả định sai trong mọi tổ chức; ⚠ liên hệ #26721 cùng lô.
-
B (gần cuối dự án khi sản phẩm sẵn sàng) — ⚠ muộn nhất có thể; ⚠ mọi yêu cầu phát hiện lúc đó đều đắt, và bên liên quan bị hỏi ý kiến sau khi mọi thứ đã quyết sẽ phản đối mạnh nhất.
-
D (không cần kế hoạch gắn kết vì dự án nổi bật, ai cũng biết) — ⚠ nhầm sự CHÚ Ý với sự HIỂU BIẾT; ⚠ dự án càng nổi bật thì càng nhiều người có ý kiến, và càng cần kế hoạch giao tiếp chặt chẽ.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26687 cùng lô (mô hình nổi bật để phân loại), ⚠ #26721 cùng lô (bên liên quan quyền lực cao bị bỏ sót), ⚠ #26727 cùng lô (mối quan tâm theo nhóm), ⚠ #26645 lô 198 (chiến lược gắn kết), ⚠ #26642 lô 198 (hiểu lầm đã ăn sâu thì rất tốn công sửa).
⚠ BỐN QUY TRÌNH quản lý bên liên quan: | Quy trình | Nhóm | Nội dung | |---|---|---| | ⚠ NHẬN DIỆN BÊN LIÊN QUAN | ⚠ KHỞI ĐỘNG — sớm nhất | ⚠ ai có liên quan, quyền lực và quan tâm ra sao | | ⚠ LẬP KẾ HOẠCH GẮN KẾT | ⚠ Lập kế hoạch | ⚠ chiến lược cho từng nhóm | | ⚠ QUẢN LÝ SỰ GẮN KẾT | ⚠ Thực thi | ⚠ trao đổi, thương lượng, xử lý mối lo | | ⚠ GIÁM SÁT SỰ GẮN KẾT | ⚠ Giám sát và kiểm soát | ⚠ kiểm xem chiến lược có hiệu quả không, cập nhật lại | | ⚠ Điều đáng chú ý | ⚠ nhận diện bên liên quan nằm ở nhóm KHỞI ĐỘNG cùng với hiến chương — nghĩa là PMBOK coi việc biết ai liên quan quan trọng ngang với việc chính thức hoá dự án; và sổ đăng ký bên liên quan phải được cập nhật suốt vòng đời, vì người mới xuất hiện liên tục |
⚠ Chi phí của việc bắt đầu muộn: | Hậu quả | Nội dung | |---|---| | ⚠ Yêu cầu quan trọng bị phát hiện muộn | ⚠ phải làm lại phần đã hoàn thành | | ⚠ Bên liên quan cảm thấy bị bỏ ngoài cuộc | ⚠ và họ phản đối bằng cách trì hoãn phê duyệt | | ⚠ Sự phản đối cứng lại thành lập trường | ⚠ liên hệ #26642 lô 198 — hiểu lầm ăn sâu rất khó gỡ | | ⚠ Mất cơ hội biến họ thành người ủng hộ | | | ⚠ Rủi ro chính trị xuất hiện vào lúc dự án dễ tổn thương nhất | | | ⚠ Quy tắc thực dụng | ⚠ một giờ trò chuyện ở tuần đầu tiên thường tiết kiệm được nhiều ngày ở tháng cuối cùng — và đó là khoản đầu tư có tỉ suất cao nhất mà một người quản lý dự án thực hiện được |
⚠ Việc cần làm ngay ở đầu dự án: | Việc | Nội dung | |---|---| | ⚠ Lập SỔ ĐĂNG KÝ BÊN LIÊN QUAN | ⚠ tên, vai trò, quyền lực, quan tâm, kỳ vọng | | ⚠ Phân loại theo mô hình phù hợp | ⚠ liên hệ #26687 cùng lô | | ⚠ Xác định mức gắn kết HIỆN TẠI và MONG MUỐN | ⚠ ma trận tham gia: không biết → phản đối → trung lập → ủng hộ → dẫn dắt | | ⚠ Lập kế hoạch giao tiếp cho từng nhóm | ⚠ liên hệ #26641 lô 198 | | ⚠ Gặp trực tiếp các bên có quyền lực cao | ⚠ trước khi họ phải đi hỏi bạn — liên hệ #26721 cùng lô | | ⚠ Nhắc nhở | ⚠ sổ đăng ký bên liên quan là tài liệu SỐNG; người ta đổi vai trò, đổi công ty, đổi thái độ — một bản lập ở tuần đầu rồi không bao giờ mở lại sẽ sai trong vòng vài tháng |
Từ khoá nhận diện:
"khi nào bắt đầu quản lý bên liên quan" → ⚠ NGAY TỪ ĐẦU DỰ ÁN "kế hoạch đã công khai nên không cần gắn kết" → ⚠ minh bạch không thay thế được đối thoại hai chiều "gần cuối, khi sản phẩm sẵn sàng" → ⚠ muộn nhất, đắt nhất "dự án nổi bật nên ai cũng biết" → ⚠ nhầm sự chú ý với sự hiểu biết
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký bên liên quan của bạn lập lúc nào và cập nhật lần cuối khi nào | | | Có ai quan trọng mà bạn chưa từng nói chuyện trực tiếp không | | | Bạn biết kỳ vọng của họ từ đâu | ⚠ từ chính họ, hay từ suy đoán của bạn |
Và điều mà việc gõ cửa từng người trong tuần đầu tiên đổi lấy được: quyền được nghe những mối lo lắng lúc chúng còn là câu hỏi, thay vì gặp lại chúng ở tháng thứ tám dưới dạng một lá thư phản đối gửi cho nhà tài trợ.
- A Functional manager
- B Support person
- C Coordinator and expeditor
- D Project manager with complete authority
Xem giải thích
Đáp án
C — NGƯỜI ĐIỀU PHỐI VÀ ĐÔN ĐỐC (coordinator and expediter).
Vì sao đúng
⚠ Đặc điểm của ma trận yếu: | Đặc điểm | Nội dung | |---|---| | ⚠ QUẢN LÝ CHỨC NĂNG giữ quyền lực chính | ⚠ họ nắm ngân sách và nhân sự | | ⚠ Quản lý dự án có thẩm quyền THẤP hoặc RẤT THẤP | ⚠ không ra lệnh được cho thành viên | | ⚠ Vai trò thực chất là ĐIỀU PHỐI công việc và THÚC ĐẨY tiến độ | ⚠ ĐÁP ÁN | | ⚠ Thường làm bán thời gian, không chuyên trách | | | ⚠ Ngân sách do quản lý chức năng kiểm soát | | | ⚠ Kết luận | ⚠ Marty phải làm việc bằng ẢNH HƯỞNG và QUAN HỆ, không bằng mệnh lệnh |
⚠ Hai vai trò trong ma trận yếu, khác nhau một chút: ⚠ NGƯỜI ĐÔN ĐỐC (expediter) chủ yếu là đầu mối liên lạc và thúc tiến độ, gần như không có quyền quyết định; NGƯỜI ĐIỀU PHỐI (coordinator) có chút thẩm quyền ra quyết định và thường báo cáo cho cấp cao hơn ⚠ — ⚠ đề gộp cả hai vào một phương án vì cả hai đều là vai trò đặc trưng của ma trận yếu.
Vì sao các phương án khác sai
-
B (người hỗ trợ — support person) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó phản ánh đúng cảm giác thực tế của rất nhiều người quản lý dự án trong ma trận yếu: ít quyền, nhiều việc, chủ yếu là hỗ trợ người khác: ⚠ nhưng ⚠ "người hỗ trợ" không phải THUẬT NGỮ mô tả vai trò quản lý dự án trong bảng phân loại cơ cấu tổ chức của PMBOK ⚠ — ⚠ thuật ngữ chuẩn là điều phối viên và người đôn đốc; ⚠ đây là dạng bẫy dùng một từ mô tả đúng cảm nhận nhưng sai thuật ngữ.
-
D (quản lý dự án có toàn quyền) — ⚠ đó là ma trận MẠNH hoặc tổ chức theo DỰ ÁN; ⚠ ngược hoàn toàn với đề.
-
A (quản lý chức năng) — ⚠ là một vai trò KHÁC, chính là người nắm quyền mà Marty phải thương lượng cùng.
Ghi nhớ
⚠ Đối chiếu: ⚠ #26680 lô 198 (bị rút nguồn lực trong ma trận yếu), ⚠ #26513 lô 196 (các loại cơ cấu tổ chức), ⚠ #26685 cùng lô (thương lượng nguồn lực dùng chung), ⚠ #26533 lô 196 (thoả thuận nguồn lực), ⚠ #26702 cùng lô (làm việc với bộ phận khác không thuộc quyền mình).
⚠ CÁC CƠ CẤU TỔ CHỨC — bảng đầy đủ: | Cơ cấu | Thẩm quyền của quản lý dự án | Vai trò | Ai nắm ngân sách | |---|---|---|---| | ⚠ CHỨC NĂNG | ⚠ rất thấp hoặc không có | ⚠ điều phối bán thời gian, nếu có | ⚠ quản lý chức năng | | ⚠ MA TRẬN YẾU | ⚠ thấp | ⚠ ĐIỀU PHỐI VIÊN / NGƯỜI ĐÔN ĐỐC — ĐÁP ÁN | ⚠ quản lý chức năng | | ⚠ MA TRẬN CÂN BẰNG | ⚠ trung bình | ⚠ quản lý dự án toàn thời gian | ⚠ chia sẻ | | ⚠ MA TRẬN MẠNH | ⚠ cao | ⚠ quản lý dự án toàn thời gian, có đội hỗ trợ | ⚠ quản lý dự án | | ⚠ THEO DỰ ÁN (projectized) | ⚠ gần như toàn quyền | ⚠ quản lý dự án là người đứng đầu | ⚠ quản lý dự án | | ⚠ Cách nhớ nhanh | ⚠ đọc theo thang từ trên xuống dưới: quyền của quản lý dự án tăng dần, quyền của quản lý chức năng giảm dần — biết mình đang ở bậc nào thì biết mình có công cụ gì trong tay |
⚠ Marty làm việc thế nào trong ma trận yếu: | Công cụ | Nội dung | |---|---| | ⚠ QUAN HỆ với quản lý chức năng | ⚠ xây trước khi cần — liên hệ #26680 lô 198 | | ⚠ Thoả thuận nguồn lực bằng văn bản | ⚠ ai, bao nhiêu phần trăm thời gian, trong bao lâu | | ⚠ Quyền lực CHUYÊN GIA và THAM CHIẾU | ⚠ người ta nghe vì tin bạn, không vì bạn có chức | | ⚠ Sự hậu thuẫn của nhà tài trợ | ⚠ kênh leo thang khi thương lượng bế tắc | | ⚠ Dữ liệu và tác động cụ thể | ⚠ thay cho mệnh lệnh: "thiếu người này thì trễ ba tuần" | | ⚠ Kỹ năng quan trọng nhất | ⚠ thương lượng — trong ma trận yếu, gần như mọi thứ bạn cần đều phải xin từ một người không có nghĩa vụ phải cho bạn, và điều đó khiến kỹ năng đàm phán trở thành công cụ hằng ngày chứ không phải công cụ dịp đặc biệt; liên hệ #26678 lô 198 |
⚠ Marty cần chú ý gì với các nhóm nguồn lực khác nhau: | Nhóm | Lưu ý | |---|---| | ⚠ Kỹ sư phần mềm, quản trị CSDL, kỹ sư hệ thống | ⚠ ba bộ phận chức năng khác nhau, ba cuộc thương lượng khác nhau | | ⚠ Nguồn lực kỹ thuật phân phối phần mềm | ⚠ có thể thuộc bộ phận vận hành — liên hệ #26702 cùng lô | | ⚠ Nhu cầu xuất hiện theo giai đoạn | ⚠ nói trước lịch cần người, đừng đợi tới lúc cần | | ⚠ Rủi ro lớn nhất cần ghi vào sổ | ⚠ "nguồn lực bị rút giữa chừng" — trong ma trận yếu đây gần như là điều chắc chắn xảy ra ít nhất một lần, và có kế hoạch dự phòng cho nó là việc phải làm ngay từ đầu, liên hệ #26725 cùng lô |
Từ khoá nhận diện:
"ma trận yếu" → ⚠ quản lý dự án là ĐIỀU PHỐI VIÊN / NGƯỜI ĐÔN ĐỐC "ma trận mạnh / theo dự án" → ⚠ quản lý dự án có thẩm quyền cao "người hỗ trợ" → ⚠ không phải thuật ngữ chuẩn "quản lý chức năng" → ⚠ vai trò khác, chính là người nắm quyền nguồn lực
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn thuộc cơ cấu nào | ⚠ hỏi: ai quyết định người nào làm dự án của bạn | | Bạn có thoả thuận nguồn lực bằng văn bản không | | | Bạn dựa vào quyền lực nào để công việc được làm | ⚠ chức vụ, chuyên môn, hay quan hệ |
Và điều mà một người quản lý dự án trong ma trận yếu buộc phải học sớm hơn đồng nghiệp ở nơi khác: cách khiến người ta muốn giúp mình — vì khi không có quyền ra lệnh, đó là công cụ duy nhất còn lại, và cũng là công cụ hiệu quả nhất ở bất kỳ cơ cấu nào.