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

Tìm thấy 718 câu.

Câu 301 Process
As the Grand Bay Project project manager, one of Faye's required roles is to create a risk management plan. Of the following, which response will not be part of Faye's risk management plan?
  1. A Methodology
  2. B Technical assessment board compliance
  3. C Roles and responsibilities
  4. D Risk categories
Xem giải thích

Đáp án

B — TUÂN THỦ HỘI ĐỒNG THẨM ĐỊNH KỸ THUẬT (technical assessment board compliance).

Vì sao đúng

⚠ Câu hỏi phủ định — soi từng phương án: | Phương án | Có thuộc kế hoạch quản lý rủi ro không | |---|---| | ⚠ A — phương pháp luận (methodology) | ⚠ CÓ — dùng cách tiếp cận, công cụ và nguồn dữ liệu nào | | ⚠ B — TUÂN THỦ HỘI ĐỒNG THẨM ĐỊNH KỸ THUẬT | ⚠ KHÔNG — ĐÁP ÁN, đây không phải thành phần chuẩn | | ⚠ C — vai trò và trách nhiệm | ⚠ CÓ — ai làm gì trong hoạt động quản lý rủi ro | | ⚠ D — phân loại rủi ro (risk categories) | ⚠ CÓ — cấu trúc phân rã rủi ro (RBS) |

⚠ Vì sao B lạc loài: ⚠ "hội đồng thẩm định kỹ thuật" không phải là một cơ cấu chuẩn trong PMBOK, và việc tuân thủ một hội đồng như vậy thuộc về QUẢN TRỊ hoặc TUÂN THỦ, không phải nội dung của kế hoạch rủi ro ⚠ — ⚠ kế hoạch quản lý rủi ro nói về CÁCH tổ chức hoạt động rủi ro, không nói về việc phải xin phép hội đồng nào.

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

  • D (phân loại rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nhiều người nghĩ danh mục các loại rủi ro nằm trong SỔ ĐĂNG KÝ rủi ro chứ không nằm trong kế hoạch: ⚠ nhưng ⚠ KHUNG phân loại — cấu trúc phân rã rủi ro, ví dụ kỹ thuật, bên ngoài, tổ chức, quản lý dự án — được định nghĩa TRƯỚC trong kế hoạch ⚠ — ⚠ sổ đăng ký chứa các rủi ro CỤ THỂ, còn kế hoạch chứa hệ thống phân loại để xếp chúng vào; ⚠ đây lại là cặp phân biệt KẾ HOẠCH nói cách làm / TÀI LIỆU chứa dữ liệu, liên hệ #26777 cùng lô.

  • A (phương pháp luận) — ⚠ là thành phần đầu tiên của kế hoạch quản lý rủi ro; ⚠ thuộc.

  • C (vai trò và trách nhiệm) — ⚠ cũng là thành phần chuẩn; ⚠ ai là chủ rủi ro, ai phân tích, ai duyệt.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26744 cùng lô (tra sổ đăng ký rủi ro khi rủi ro xảy ra), ⚠ #26777 cùng lô (cập nhật sổ đăng ký chứ không phải kế hoạch), ⚠ #26781 cùng lô (họp lập kế hoạch là kỹ thuật để lập kế hoạch rủi ro), ⚠ #26725 lô 199 (giám sát rủi ro chưa xảy ra), ⚠ #26659 lô 198 (báo cáo rủi ro).

⚠ KẾ HOẠCH QUẢN LÝ RỦI RO chứa gì: | Thành phần | Nội dung | |---|---| | ⚠ PHƯƠNG PHÁP LUẬN | ⚠ cách tiếp cận, công cụ, nguồn dữ liệu — phương án A | | ⚠ VAI TRÒ VÀ TRÁCH NHIỆM | ⚠ ai dẫn dắt, ai hỗ trợ, ai là chủ rủi ro — phương án C | | ⚠ NGÂN SÁCH cho hoạt động rủi ro | ⚠ và cách dùng quỹ dự phòng | | ⚠ THỜI ĐIỂM và TẦN SUẤT | ⚠ bao lâu rà soát rủi ro một lần | | ⚠ PHÂN LOẠI RỦI RO (RBS) | ⚠ phương án D | | ⚠ ĐỊNH NGHĨA xác suất và tác động | ⚠ "cao" nghĩa là bao nhiêu phần trăm, bao nhiêu tiền | | ⚠ MA TRẬN xác suất và tác động | | | ⚠ KHẨU VỊ và NGƯỠNG CHỊU RỦI RO của bên liên quan | | | ⚠ Định dạng BÁO CÁO và cách theo dõi | | | ⚠ Điểm cần nhớ | ⚠ toàn bộ là các quyết định về CÁCH LÀM, được đưa ra TRƯỚC khi biết rủi ro cụ thể nào sẽ xuất hiện — đó là lý do nó là "kế hoạch" chứ không phải "danh sách" |

⚠ Vì sao định nghĩa xác suất và tác động phải viết ra: | Vấn đề nếu không có | Nội dung | |---|---| | ⚠ "Tác động cao" mỗi người hiểu một kiểu | ⚠ với người này là 10.000 đô, với người kia là một triệu | | ⚠ Xếp hạng rủi ro trở nên tuỳ tiện | | | ⚠ Không so sánh được rủi ro giữa các dự án | | | ⚠ Cách làm đúng | ⚠ quy đổi thành thang cụ thể: tác động rất cao là trên 10% ngân sách, cao là 5–10%, và cứ thế — khi đó hai người khác nhau đánh giá cùng một rủi ro sẽ ra kết quả gần nhau |

⚠ Nhận diện phương án bịa trong câu hỏi phủ định: | Dấu hiệu | Nội dung | |---|---| | ⚠ Tên nghe rất "chính thức" nhưng không có trong PMBOK | ⚠ "hội đồng thẩm định kỹ thuật" — câu này | | ⚠ Thuộc một phạm trù khác hẳn ba phương án còn lại | ⚠ ba cái kia là nội dung kế hoạch, cái này là một tổ chức | | ⚠ Ghép các từ quen thuộc theo cách mới | | | ⚠ Các thuật ngữ bịa đã gặp trong bộ đề này | ⚠ "ma trận tác động giao tiếp", "risk assurance", "coupled vision", "requirements scoping", "halo power", "net investment value", "return on income" — và nay là "technical assessment board compliance" |

Từ khoá nhận diện:

"hội đồng thẩm định kỹ thuật" → ⚠ KHÔNG phải thành phần của kế hoạch rủi ro "phương pháp luận, vai trò, phân loại rủi ro" → ⚠ đều thuộc kế hoạch "danh sách rủi ro cụ thể" → ⚠ thuộc SỔ ĐĂNG KÝ, không phải kế hoạch câu phủ định → ⚠ tìm phương án lạc phạm trù

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch rủi ro của bạn có định nghĩa "tác động cao" bằng con số không | | | Mỗi rủi ro trong sổ có chủ rủi ro không | | | Bạn rà soát rủi ro bao lâu một lần, và điều đó có được ghi ra không | |

Và điều mà một kế hoạch quản lý rủi ro tốt quyết định trước cả khi rủi ro đầu tiên xuất hiện: ai sẽ nhìn, nhìn vào lúc nào, và bao nhiêu thì đủ lớn để phải hành động — ba câu hỏi mà không ai muốn phải trả lời lần đầu ngay giữa một sự cố.

Câu 302 Process
Quinten is the project manager for a project at Service Corporation that is on budget but two weeks behind schedule. This project has a tight deadline, and project costs can be no greater than three percent of the planned budget. Recently a project team member communicated that a particular risk they had identified in project planning has occurred. What should Quinten do next?
  1. A Inform the steering committee.
  2. B Refer to the risk register.
  3. C Tell the team member to address the risk.
  4. D Apply the management reserve.
Xem giải thích

Đáp án

B — TRA SỔ ĐĂNG KÝ RỦI RO.

Vì sao đúng

⚠ Vì sao đây là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro này ĐÃ ĐƯỢC NHẬN DIỆN trong lúc lập kế hoạch | ⚠ nghĩa là đã có phản ứng được chuẩn bị sẵn | | ⚠ Sổ đăng ký rủi ro chứa PHẢN ỨNG ĐÃ DUYỆT, chủ rủi ro và quỹ dự phòng | ⚠ mọi thứ Quinten cần đều nằm ở đó | | ⚠ Dùng lại kế hoạch đã có nhanh hơn nghĩ ra cách mới | ⚠ đó chính là lý do người ta lập kế hoạch rủi ro | | ⚠ Ràng buộc rất chặt: chỉ được vượt 3% ngân sách, hạn gấp | ⚠ không có chỗ cho phản ứng ngẫu hứng | | ⚠ Kết luận | ⚠ rủi ro đã lường trước thì phản ứng đã có sẵn — việc đầu tiên là lấy nó ra |

⚠ Đây là cặp bổ sung của #26725 lô 199: ⚠ ở đó rủi ro CHƯA xảy ra nên câu trả lời là tiếp tục theo dõi; ở đây rủi ro ĐÃ xảy ra nên câu trả lời là lấy phản ứng đã chuẩn bị ra dùng ⚠ — ⚠ hai câu cùng một khung tư duy, chỉ khác thời điểm.

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

  • D (dùng quỹ dự phòng quản lý — management reserve) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ rủi ro xảy ra thì cần tiền, và dự phòng đúng là nguồn tiền dành cho tình huống này: ⚠ nhưng ⚠ QUỸ DỰ PHÒNG QUẢN LÝ dành cho rủi ro KHÔNG BIẾT TRƯỚC, còn rủi ro này ĐÃ được nhận diện nên nó thuộc về QUỸ DỰ PHÒNG SỰ CỐ (contingency reserve) ⚠ — ⚠ hai quỹ khác nhau về mục đích, về mức thẩm quyền sử dụng và về việc có nằm trong đường cơ sở chi phí hay không; ⚠ và dù dùng quỹ nào thì vẫn phải tra sổ trước để biết cần bao nhiêu.

  • C (bảo thành viên đó tự xử lý rủi ro) — ⚠ đẩy trách nhiệm; ⚠ mỗi rủi ro có CHỦ RỦI RO được chỉ định trong sổ, có thể không phải người vừa báo tin.

  • A (báo ban chỉ đạo) — ⚠ có thể cần, nhưng KHÔNG phải bước đầu tiên; ⚠ báo cáo mà chưa biết tác động và chưa biết mình có sẵn phản ứng gì là báo cáo nửa vời.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26725 lô 199 (CÂU BỔ SUNG — rủi ro chưa xảy ra thì tiếp tục theo dõi), ⚠ #26536 lô 196 và ⚠ #26628 lô 197 (tín hiệu kích hoạt rủi ro), ⚠ #26743 cùng lô (kế hoạch quản lý rủi ro), ⚠ #26777 cùng lô (cập nhật sổ đăng ký với phản ứng mới), ⚠ #26764 cùng lô (đánh giá và lập kế hoạch giảm nhẹ).

⚠ Trình tự khi một rủi ro đã nhận diện xảy ra: | Bước | Việc | |---|---| | ⚠ 1. TRA SỔ ĐĂNG KÝ RỦI RO | ⚠ ĐÁP ÁN — phản ứng đã duyệt là gì, ai là chủ rủi ro | | ⚠ 2. Kích hoạt phản ứng đã lập | ⚠ kế hoạch dự phòng, hoặc phản ứng chính | | ⚠ 3. Đánh giá tác động THỰC TẾ | ⚠ có thể khác dự kiến ban đầu | | ⚠ 4. Dùng QUỸ DỰ PHÒNG SỰ CỐ nếu cần | ⚠ quỹ này đã nằm trong đường cơ sở chi phí | | ⚠ 5. Ghi vào SỔ VẤN ĐỀ | ⚠ rủi ro đã xảy ra thì thành VẤN ĐỀ — liên hệ #26668 lô 198 | | ⚠ 6. Thông báo cho bên liên quan theo kế hoạch giao tiếp | ⚠ phương án A thuộc bước này | | ⚠ 7. Đóng rủi ro trong sổ và ghi bài học | | | ⚠ Nguyên tắc | ⚠ không nghĩ ra phản ứng mới khi đã có phản ứng được duyệt — trừ khi tình huống thực tế khác hẳn dự kiến, và khi đó thì phải qua kiểm soát thay đổi |

⚠ HAI QUỸ DỰ PHÒNG — bảng phân biệt: | Tiêu chí | DỰ PHÒNG SỰ CỐ (contingency) | DỰ PHÒNG QUẢN LÝ (management) | |---|---|---| | ⚠ Dành cho | ⚠ rủi ro ĐÃ NHẬN DIỆN — ca này | ⚠ rủi ro KHÔNG lường trước được | | ⚠ Nằm trong đường cơ sở chi phí | ⚠ CÓ | ⚠ KHÔNG — nằm ngoài, thuộc ngân sách dự án | | ⚠ Ai được dùng | ⚠ quản lý dự án | ⚠ thường phải xin cấp trên hoặc nhà tài trợ | | ⚠ Tính bằng | ⚠ phân tích rủi ro cụ thể, EMV | ⚠ tỉ lệ phần trăm của dự án | | ⚠ Ràng buộc của Quinten | ⚠ chi phí không được vượt quá 3% ngân sách kế hoạch — con số đó cho thấy dư địa rất hẹp, nên việc biết chính xác phản ứng đã lập tốn bao nhiêu càng quan trọng | |

⚠ Bối cảnh của Quinten và ý nghĩa của nó: | Yếu tố | Ý nghĩa | |---|---| | ⚠ ĐÚNG ngân sách nhưng CHẬM hai tuần | ⚠ dư địa về tiền còn, dư địa về thời gian đã hết | | ⚠ Hạn chót rất chặt | ⚠ phản ứng phải nhanh | | ⚠ Trần chi phí 3% | ⚠ giới hạn cứng cho mọi phương án | | ⚠ Hệ quả cho lựa chọn phản ứng | ⚠ nếu phản ứng đã lập trong sổ tốn nhiều thời gian hơn mức cho phép, Quinten phải quay lại phân tích phương án khác — nhưng anh chỉ biết được điều đó SAU KHI đọc sổ, chứ không phải trước |

Từ khoá nhận diện:

"rủi ro đã nhận diện nay xảy ra" → ⚠ TRA SỔ ĐĂNG KÝ RỦI RO trước "rủi ro chưa xảy ra" → ⚠ tiếp tục theo dõi (#26725 lô 199) "quỹ dự phòng quản lý" → ⚠ cho rủi ro KHÔNG lường trước "báo ban chỉ đạo" → ⚠ bước sau, sau khi đã biết tác động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký rủi ro của bạn có phản ứng cụ thể cho từng rủi ro không | ⚠ hay chỉ có mô tả rủi ro | | Bạn có biết quỹ dự phòng sự cố của mình còn bao nhiêu không | | | Khi rủi ro xảy ra, ai là người được thông báo đầu tiên trong đội bạn | |

Và điều mà một sổ đăng ký rủi ro được viết tử tế trả lại vào đúng ngày cần: vài phút để tìm ra việc phải làm, thay vì một cuộc họp khẩn để phát minh lại thứ mà chính bạn đã nghĩ ra từ nhiều tháng trước.

Câu 303 People
Zach has a project that introduces new technology to a business unit. The goal of the project is the adoption of new technology. To achieve this, Zach creates a guiding coalition consisting of a small group of supportive stakeholders whose collective efforts can significantly impact the project. Which of the following is not a responsibility of this group?
  1. A To reduce resistance to change.
  2. B To provide counsel to leadership and the project team.
  3. C To provide support, guidance, and oversight of project progress.
  4. D To exert influence at key moments to support adoption.
Xem giải thích

Đáp án

C — CUNG CẤP SỰ HỖ TRỢ, HƯỚNG DẪN VÀ GIÁM SÁT TIẾN ĐỘ DỰ ÁN.

Vì sao đúng

⚠ Câu hỏi phủ định — liên minh dẫn dắt làm gì và không làm gì: | Phương án | Có phải trách nhiệm của liên minh dẫn dắt không | |---|---| | ⚠ A — giảm sức đề kháng với thay đổi | ⚠ CÓ — đây là lý do tồn tại của nhóm | | ⚠ B — tư vấn cho lãnh đạo và đội dự án | ⚠ CÓ — họ là tiếng nói của người bị ảnh hưởng | | ⚠ C — HỖ TRỢ, HƯỚNG DẪN VÀ GIÁM SÁT TIẾN ĐỘ DỰ ÁN | ⚠ KHÔNG — ĐÁP ÁN | | ⚠ D — tạo ảnh hưởng vào các thời điểm then chốt để thúc đẩy việc tiếp nhận | ⚠ CÓ — đúng mô tả về "liên minh" |

⚠ Vì sao C sai: ⚠ "giám sát tiến độ dự án" là chức năng của BAN CHỈ ĐẠO hoặc nhà tài trợ, không phải của liên minh dẫn dắt ⚠ — ⚠ liên minh dẫn dắt là nhóm ẢNH HƯỞNG, không phải nhóm QUẢN TRỊ; ⚠ họ giúp thay đổi được chấp nhận, không theo dõi xem dự án có đúng tiến độ hay không.

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

  • B (tư vấn cho lãnh đạo và đội dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có vẻ chồng lấn với phương án C — cả hai đều nói về việc "cố vấn" và "hướng dẫn": ⚠ nhưng ⚠ tư vấn là chia sẻ GÓC NHÌN từ phía những người sẽ dùng công nghệ mới, còn giám sát tiến độ là quyền QUẢN TRỊ dự án ⚠ — ⚠ cái đầu là đóng góp thông tin, cái sau là kiểm soát; ⚠ chi tiết quyết định trong phương án C là chữ "GIÁM SÁT TIẾN ĐỘ" — một chức năng quản trị mà một nhóm bên liên quan ủng hộ không có.

  • A (giảm sức đề kháng với thay đổi) — ⚠ đúng là nhiệm vụ trung tâm; ⚠ dự án của Zach có mục tiêu là việc TIẾP NHẬN công nghệ mới.

  • D (tạo ảnh hưởng vào thời điểm then chốt) — ⚠ cũng đúng; ⚠ đó là giá trị chính của một liên minh có sức nặng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26739 cùng lô (quản lý thay đổi tổ chức khác kiểm soát thay đổi dự án), ⚠ #26687 lô 199 (phân loại bên liên quan), ⚠ #26731 lô 199 (gắn kết bên liên quan từ đầu), ⚠ #26645 lô 198 (giữ bên liên quan gắn kết), ⚠ #26719 lô 199 (cố vấn như công cụ thay đổi tổ chức).

⚠ LIÊN MINH DẪN DẮT (guiding coalition) — khái niệm của Kotter: | Đặc điểm | Nội dung | |---|---| | ⚠ Nhóm NHỎ các bên liên quan có ảnh hưởng | ⚠ đúng như mô tả trong đề | | ⚠ Có uy tín trong tổ chức | ⚠ người khác nghe họ | | ⚠ Ủng hộ thay đổi một cách chân thành | ⚠ không phải bị chỉ định cho có | | ⚠ Đại diện cho các bộ phận bị ảnh hưởng | ⚠ nói được tiếng nói của người dùng | | ⚠ Nhiệm vụ: lan truyền, thuyết phục, gỡ đề kháng | | | ⚠ Điều họ KHÔNG làm | ⚠ quản trị dự án, duyệt ngân sách, giám sát tiến độ — những việc đó thuộc nhà tài trợ và ban chỉ đạo |

⚠ Phân biệt ba nhóm hay bị lẫn: | Nhóm | Vai trò | |---|---| | ⚠ LIÊN MINH DẪN DẮT | ⚠ ẢNH HƯỞNG — giúp thay đổi được chấp nhận | | ⚠ BAN CHỈ ĐẠO / ban điều hành dự án | ⚠ QUẢN TRỊ — giám sát tiến độ, quyết định lớn | | ⚠ BAN KIỂM SOÁT THAY ĐỔI | ⚠ PHÊ DUYỆT các yêu cầu thay đổi — liên hệ #26710 lô 199 | | ⚠ Cách phân biệt nhanh | ⚠ hỏi "nhóm này có QUYỀN QUYẾT ĐỊNH gì với dự án không": có quyền thì là quản trị; chỉ có sức ảnh hưởng thì là liên minh dẫn dắt |

⚠ Vì sao dự án của Zach cần một liên minh: | Lý do | Nội dung | |---|---| | ⚠ Mục tiêu dự án là SỰ TIẾP NHẬN, không phải việc cài đặt xong | ⚠ công nghệ được triển khai mà không ai dùng thì dự án thất bại | | ⚠ Người ta tin đồng nghiệp hơn tin thông báo từ trên xuống | | | ⚠ Đề kháng thường ngầm chứ không công khai | ⚠ liên minh nghe được thứ mà quản lý dự án không nghe được | | ⚠ Cần người ủng hộ đúng vào các thời điểm quyết định | ⚠ phương án D | | ⚠ Cách chọn thành viên liên minh | ⚠ không chọn theo chức vụ mà chọn theo ẢNH HƯỞNG THẬT — người mà đồng nghiệp hay hỏi ý kiến thường có sức nặng lớn hơn nhiều so với chức danh của họ |

Từ khoá nhận diện:

"giám sát tiến độ dự án" → ⚠ việc của ban chỉ đạo, KHÔNG phải liên minh dẫn dắt "giảm đề kháng, tạo ảnh hưởng, tư vấn" → ⚠ đúng là việc của liên minh "liên minh dẫn dắt" → ⚠ nhóm ẢNH HƯỞNG, không có quyền quản trị câu phủ định → ⚠ tìm phương án nói về QUYỀN thay vì về ẢNH HƯỞNG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án thay đổi của bạn có nhóm ủng hộ nào không | | | Họ được chọn theo chức vụ hay theo ảnh hưởng thật | | | Họ có biết rõ vai trò của mình không | ⚠ một liên minh không được nói rõ nhiệm vụ sẽ tưởng mình là ban giám sát |

Và điều quyết định một dự án công nghệ mới thành công hay chỉ hoàn thành: không phải là ngày hệ thống được bật lên, mà là ngày những người vốn hoài nghi bắt đầu tự nói với đồng nghiệp rằng cách làm mới này thật ra tốt hơn.

Câu 304 Process
James is a very creative individual and has decided to enhance a product's features during the development phase, which he was assigned to, knowing it will not negatively impact the project. However, he did not consult Mandy, his project manager, on the changes ahead of implementing them. What should Mandy do first now that her team member has added enhancement to a product without impacting time, cost, and quality?
  1. A Ask the team member why they feel additional enhancement(s) are required.
  2. B Confirm that the customer is willing to incur this added expense.
  3. C Consult the business team to assess the value of the improvement.
  4. D Discuss with the team member how they know there is no time, cost, or quality impact.
Xem giải thích

Đáp án

D — TRAO ĐỔI VỚI THÀNH VIÊN ĐÓ XEM LÀM CÁCH NÀO ANH BIẾT ĐƯỢC RẰNG KHÔNG CÓ TÁC ĐỘNG NÀO TỚI THỜI GIAN, CHI PHÍ HAY CHẤT LƯỢNG.

Vì sao đúng

⚠ Vì sao đây là việc đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ "Biết rằng sẽ không ảnh hưởng" là một GIẢ ĐỊNH của James | ⚠ chưa có phân tích tác động nào được làm | | ⚠ Người thực hiện thường không nhìn thấy tác động ở nơi khác | ⚠ tích hợp, kiểm thử, tài liệu, bảo trì, đào tạo người dùng | | ⚠ Mandy cần DỮ LIỆU trước khi quyết định làm gì tiếp | ⚠ giữ lại hay hoàn nguyên | | ⚠ Câu hỏi mở, không buộc tội | ⚠ giữ được quan hệ và vẫn làm rõ được sự thật | | ⚠ Đây là THẾP VÀNG — làm thêm ngoài phạm vi | ⚠ liên hệ #26715 lô 199 | | ⚠ Kết luận | ⚠ kiểm chứng giả định trước, xử lý quy trình sau |

⚠ Vấn đề thật sự ở đây không phải là bản thân cải tiến mà là VIỆC BỎ QUA QUY TRÌNH: ⚠ mọi thay đổi phải qua kiểm soát thay đổi, kể cả thay đổi tốt ⚠ — ⚠ liên hệ #26739 cùng lô.

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

  • A (hỏi vì sao anh ấy thấy cần thêm cải tiến) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là một câu hỏi mở, cũng không buộc tội, và cũng hướng tới việc hiểu thành viên — nghe rất giống đáp án: ⚠ nhưng ⚠ nó hỏi về ĐỘNG CƠ, còn đáp án hỏi về BẰNG CHỨNG ⚠ — ⚠ động cơ của James đã rõ: anh sáng tạo và muốn sản phẩm tốt hơn; thứ chưa rõ và có rủi ro thật là CƠ SỞ cho khẳng định "không ảnh hưởng gì"; ⚠ trong tình huống có rủi ro kỹ thuật, kiểm chứng sự kiện đứng trước tìm hiểu động cơ.

  • B (xác nhận khách hàng chịu trả thêm chi phí này) — ⚠ giả định trước rằng có chi phí phát sinh và khách phải trả; ⚠ chưa phân tích thì chưa biết, và công việc ngoài phạm vi thường không thể tính tiền khách.

  • C (hỏi bộ phận nghiệp vụ đánh giá giá trị của cải tiến) — ⚠ bước sau, có thể cần; ⚠ nhưng đánh giá giá trị mà chưa biết chi phí và rủi ro thì chỉ có một nửa bức tranh.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26715 lô 199 (thếp vàng — làm thêm không ai yêu cầu), ⚠ #26739 cùng lô (mọi thay đổi phải qua kiểm soát thay đổi tích hợp), ⚠ #26761 cùng lô (thay đổi được duyệt mới được thực hiện), ⚠ #26711 lô 199 (giữ phạm vi tối thiểu), ⚠ #26773 cùng lô (theo dõi sau khi can thiệp).

⚠ Vì sao "không ảnh hưởng gì" hiếm khi đúng: | Tác động ẩn | Nội dung | |---|---| | ⚠ Kiểm thử | ⚠ tính năng mới cần được kiểm, kể cả khi mã viết nhanh | | ⚠ Tài liệu | ⚠ hướng dẫn sử dụng phải cập nhật — liên hệ #26708 lô 199 | | ⚠ Bảo trì lâu dài | ⚠ mỗi tính năng đều phải nuôi trong nhiều năm | | ⚠ Tích hợp với các phần khác | ⚠ có thể phá thứ đang chạy | | ⚠ Kỳ vọng của khách hàng | ⚠ thấy rồi thì sẽ mong có ở mọi phiên bản sau | | ⚠ Bề mặt rủi ro bảo mật | ⚠ mỗi đoạn mã mới là một khả năng mới để sai | | ⚠ Nhận xét | ⚠ thời gian viết mã thường chỉ là phần nhỏ nhất trong tổng chi phí của một tính năng — đó chính là điều mà một lập trình viên sáng tạo dễ đánh giá thấp nhất |

⚠ Mandy nên xử lý theo trình tự nào: | Bước | Việc | |---|---| | ⚠ 1. Hỏi về CƠ SỞ của khẳng định "không ảnh hưởng" | ⚠ ĐÁP ÁN | | ⚠ 2. Tự đánh giá tác động thật | ⚠ kiểm thử, tài liệu, tích hợp, bảo trì | | ⚠ 3. Quyết định giữ lại hay hoàn nguyên | ⚠ nếu giữ thì phải qua yêu cầu thay đổi chính thức | | ⚠ 4. Nói rõ QUY TRÌNH với James và cả đội | ⚠ thay đổi tốt vẫn phải xin duyệt | | ⚠ 5. Ghi nhận thiện chí và tinh thần sáng tạo | ⚠ đừng dập tắt nó — hãy hướng nó vào đúng kênh | | ⚠ Cách nói với James | ⚠ "ý tưởng của anh có thể rất tốt, nhưng cách để nó thật sự được đưa vào sản phẩm là qua yêu cầu thay đổi — làm vậy thì nó được ghi nhận, được kiểm thử, và không bị ai gỡ bỏ ở lần dọn dẹp tới" |

⚠ THẾP VÀNG — vì sao nó là vấn đề dù xuất phát từ thiện chí: | Vấn đề | Nội dung | |---|---| | ⚠ Công việc ngoài phạm vi không được nghiệm thu | ⚠ và thường không được trả tiền | | ⚠ Không ai kiểm chứng nó có được kiểm thử đủ không | | | ⚠ Phá vỡ nguyên tắc mọi thay đổi phải qua duyệt | ⚠ nếu chấp nhận lần này thì lần sau sẽ có người làm nhiều hơn | | ⚠ Có thể mâu thuẫn với yêu cầu tuân thủ | ⚠ liên hệ #26706 lô 199 | | ⚠ Ranh giới cần phân biệt | ⚠ THẾP VÀNG là đội tự thêm; PHÌNH PHẠM VI là yêu cầu từ bên ngoài lọt vào không qua duyệt — cả hai đều là thay đổi không được kiểm soát, và cả hai đều nguy hiểm nhất khi chúng vô hại về mặt kỹ thuật, vì khi đó không ai thấy lý do để phản đối |

Từ khoá nhận diện:

"tự thêm cải tiến, tin rằng không ảnh hưởng gì" → ⚠ HỎI VỀ CƠ SỞ của khẳng định đó "hỏi vì sao anh ấy làm" → ⚠ hỏi động cơ, không phải bằng chứng "thếp vàng" → ⚠ làm thêm ngoài phạm vi, luôn phải qua kiểm soát thay đổi nguyên tắc nền → ⚠ thay đổi TỐT vẫn là thay đổi, và vẫn phải được duyệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có biết thay đổi nào cần duyệt và thay đổi nào không không | ⚠ ngưỡng phải được nói rõ | | Có tính năng nào trong sản phẩm mà không ai nhớ ai đã yêu cầu không | | | Bạn phản ứng thế nào khi ai đó làm nhiều hơn mức được giao | ⚠ phản ứng đó quyết định lần sau họ có nói với bạn trước hay không |

Và điều tinh tế nhất trong tình huống của Mandy: cách cô hỏi câu đầu tiên sẽ quyết định lần sau James mang ý tưởng tới bàn của cô trước — hay lặng lẽ làm rồi không nói với ai cả.

Câu 305 Process
One of Krishna's project team members has asked him to define the meaning of project scope management. Of the following choices, which response is a project scope management characteristic?
  1. A It lists the functional managers who are assigned to the project.
  2. B To ensure the project includes all the required work, and only the required work, to finish the project successfully.
  3. C It defines each project's requirements within the company.
  4. D It defines the baseline for project acceptance.
Xem giải thích

Đáp án

B — BẢO ĐẢM DỰ ÁN BAO GỒM TẤT CẢ CÔNG VIỆC CẦN THIẾT, VÀ CHỈ CÔNG VIỆC CẦN THIẾT, ĐỂ HOÀN THÀNH DỰ ÁN THÀNH CÔNG.

Vì sao đúng

⚠ Đây là định nghĩa chuẩn của PMBOK, và nó có HAI vế: | Vế | Ý nghĩa | Bảo vệ khỏi điều gì | |---|---|---| | ⚠ "TẤT CẢ công việc cần thiết" | ⚠ không được thiếu | ⚠ bỏ sót yêu cầu, giao thiếu | | ⚠ "và CHỈ công việc cần thiết" | ⚠ không được thừa | ⚠ thếp vàng và phình phạm vi — liên hệ #26746 cùng lô | | ⚠ Vì sao vế thứ hai quan trọng ngang vế thứ nhất | ⚠ làm thừa cũng tiêu tiền, tiêu thời gian và tạo rủi ro y như làm thiếu — nhưng nó khó phát hiện hơn nhiều vì trông giống sự tận tâm |

⚠ Mẹo nhớ: ⚠ quản lý phạm vi là việc vẽ một đường ranh giới rõ ràng quanh dự án ⚠ — ⚠ mọi thứ bên trong phải được làm, mọi thứ bên ngoài không được làm, và bất kỳ ai muốn dịch đường ranh giới đó đều phải đi qua kiểm soát thay đổi.

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

  • D (định nghĩa đường cơ sở để nghiệm thu dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đường cơ sở phạm vi thật sự LÀ căn cứ để nghiệm thu, nên phát biểu này không sai về nội dung: ⚠ nhưng ⚠ nó chỉ mô tả MỘT ĐẦU RA của quản lý phạm vi chứ không mô tả bản chất của lĩnh vực này ⚠ — ⚠ câu hỏi hỏi "đặc trưng của quản lý phạm vi", tức là hỏi định nghĩa, không hỏi một sản phẩm cụ thể của nó; ⚠ và nghiệm thu là việc của XÁC NHẬN PHẠM VI, một quy trình bên trong lĩnh vực này, liên hệ #26686 lô 199.

  • A (liệt kê các quản lý chức năng được phân công) — ⚠ thuộc quản lý NGUỒN LỰC; ⚠ không liên quan phạm vi.

  • C (định nghĩa yêu cầu của MỌI dự án trong công ty) — ⚠ phạm vi là chuyện của TỪNG dự án; ⚠ chuẩn hoá toàn công ty là việc của văn phòng quản lý dự án hoặc OPM — liên hệ #26719 lô 199.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26686 lô 199 (xác nhận phạm vi), ⚠ #26746 cùng lô (thếp vàng vi phạm vế "chỉ công việc cần thiết"), ⚠ #26761 cùng lô (thay đổi phạm vi đã duyệt), ⚠ #26774 cùng lô (cân bằng thời gian, chi phí, phạm vi), ⚠ #26711 lô 199 (sản phẩm khả dụng tối thiểu).

⚠ SÁU QUY TRÌNH của quản lý phạm vi: | Quy trình | Nội dung | |---|---| | ⚠ LẬP KẾ HOẠCH QUẢN LÝ PHẠM VI | ⚠ cách xác định, xác nhận và kiểm soát phạm vi | | ⚠ THU THẬP YÊU CẦU | ⚠ phỏng vấn, hội thảo, khảo sát — liên hệ #26769 cùng lô | | ⚠ XÁC ĐỊNH PHẠM VI | ⚠ viết TUYÊN BỐ PHẠM VI, nêu rõ cả cái ngoài phạm vi | | ⚠ TẠO WBS | ⚠ chia nhỏ tới mức quản lý được — liên hệ #26646 lô 198 | | ⚠ XÁC NHẬN PHẠM VI | ⚠ khách hàng nghiệm thu — liên hệ #26686 lô 199 | | ⚠ KIỂM SOÁT PHẠM VI | ⚠ theo dõi và quản lý thay đổi phạm vi | | ⚠ Phân biệt hai loại phạm vi | ⚠ PHẠM VI SẢN PHẨM là các tính năng và đặc tính của sản phẩm; PHẠM VI DỰ ÁN là công việc phải làm để tạo ra sản phẩm đó — đề thi rất hay hỏi bạn phân biệt hai khái niệm này |

⚠ Vì sao vế "CHỈ công việc cần thiết" hay bị bỏ quên: | Lý do | Nội dung | |---|---| | ⚠ Làm thêm trông giống sự tận tâm | ⚠ khó phản đối về mặt cảm xúc | | ⚠ Không ai phàn nàn khi nhận được nhiều hơn | ⚠ ít nhất là lúc đầu | | ⚠ Tác động rải rác và khó quy trách nhiệm | ⚠ trễ vài ngày ở đây, vượt chi một ít ở kia | | ⚠ Đội thường tự hào về phần làm thêm | | | ⚠ Hậu quả tích luỹ | ⚠ một dự án chết vì phình phạm vi hiếm khi có một lần phình lớn — nó có ba mươi lần phình nhỏ mà mỗi lần đều có vẻ hợp lý, liên hệ #26715 lô 199 |

⚠ Ghi cả những gì NGOÀI phạm vi: | Việc | Vì sao | |---|---| | ⚠ Tuyên bố phạm vi nên có mục "loại trừ" | ⚠ nói rõ cái gì dự án KHÔNG làm | | ⚠ Nó ngăn được giả định ngầm của bên liên quan | ⚠ thứ không nói ra thường bị mặc định là có | | ⚠ Là căn cứ để từ chối yêu cầu ngoài phạm vi | ⚠ từ chối bằng tài liệu, không bằng ý kiến cá nhân | | ⚠ Kinh nghiệm thực tế | ⚠ mục "ngoài phạm vi" thường là mục cứu bạn nhiều nhất trong toàn bộ tuyên bố phạm vi — và nó chỉ mất mười lăm phút để viết |

Từ khoá nhận diện:

"tất cả và CHỈ công việc cần thiết" → ⚠ định nghĩa quản lý phạm vi "căn cứ nghiệm thu" → ⚠ một đầu ra, không phải định nghĩa "phân công quản lý chức năng" → ⚠ quản lý nguồn lực "yêu cầu của mọi dự án trong công ty" → ⚠ chuẩn hoá tổ chức, không phải phạm vi dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyên bố phạm vi của bạn có mục loại trừ không | | | Có công việc nào đội đang làm mà không truy được về một yêu cầu không | | | Lần gần nhất bạn từ chối một yêu cầu, bạn dựa vào tài liệu nào | |

Và điều mà một câu định nghĩa tưởng chừng khô khan gói lại được: hai cách để một dự án thất bại — giao thiếu thứ người ta cần và giao thừa thứ người ta không cần — cùng nằm gọn trong sáu chữ "tất cả và chỉ công việc cần thiết".

Câu 306 Process
Regina is a developer on an agile project in its fifth iteration and has a velocity of twenty-eight story points. The team is new to agile, but they learn the process quickly and deliver value as anticipated. During the daily scrum, Regina asked Thomas, another developer, whether a specific task could be marked as completed or not. She needs the task completed to move forward with another task she wants to work on achieving. What information would help resolve this dispute?
  1. A Project's velocity
  2. B Sprint backlog
  3. C Definition of done
  4. D Product owner
Xem giải thích

Đáp án

C — ĐỊNH NGHĨA HOÀN THÀNH (definition of done).

Vì sao đúng

⚠ Vì sao đây là thứ giải quyết được tranh cãi: | Lý do | Nội dung | |---|---| | ⚠ Regina và Thomas đang bất đồng về việc một nhiệm vụ ĐÃ XONG hay CHƯA | ⚠ đúng câu hỏi mà định nghĩa hoàn thành trả lời | | ⚠ Định nghĩa hoàn thành là bảng kiểm KHÁCH QUAN của cả đội | ⚠ không phụ thuộc ý kiến từng người | | ⚠ Đội MỚI với agile | ⚠ rất hay gặp bất đồng kiểu này vì chưa quen dùng chuẩn chung | | ⚠ Regina cần nhiệm vụ đó xong để làm tiếp việc của mình | ⚠ câu trả lời phải rõ ràng và nhanh | | ⚠ Kết luận | ⚠ đối chiếu nhiệm vụ với bảng kiểm — hoặc đủ mọi mục, hoặc chưa xong |

⚠ Định nghĩa hoàn thành tồn tại chính là để tránh cuộc trò chuyện này: ⚠ "xong" là từ mà mỗi người hiểu một kiểu — có người coi là viết xong mã, có người coi là đã kiểm thử, có người coi là đã triển khai ⚠ — ⚠ một bảng kiểm chung biến một từ mơ hồ thành một danh sách kiểm được.

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

  • B (tồn đọng sprint) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ tồn đọng sprint đúng là nơi ghi các nhiệm vụ và trạng thái của chúng, nên nó là nơi người ta nhìn vào đầu tiên: ⚠ nhưng ⚠ tồn đọng cho biết nhiệm vụ ĐANG ĐƯỢC ĐÁNH DẤU ở trạng thái nào, chứ không cho biết trạng thái đó có ĐÚNG hay không ⚠ — ⚠ và tranh cãi ở đây chính là về việc có được phép đánh dấu xong hay chưa; ⚠ tồn đọng ghi lại kết luận, định nghĩa hoàn thành cung cấp tiêu chí để đi tới kết luận đó.

  • A (vận tốc của dự án) — ⚠ là thước đo tốc độ của cả đội qua nhiều vòng lặp; ⚠ không nói gì về một nhiệm vụ cụ thể.

  • D (chủ sản phẩm) — ⚠ chủ sản phẩm quyết định nghiệm thu HẠNG MỤC TỒN ĐỌNG theo tiêu chí nghiệm thu; ⚠ nhưng ở đây là một NHIỆM VỤ kỹ thuật bên trong, và đội có chuẩn chung để tự trả lời mà không cần leo lên.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26651 lô 198 (định nghĩa hoàn thành tránh bất ngờ phút chót), ⚠ #26740 cùng lô (rà soát mã nằm trong định nghĩa hoàn thành), ⚠ #26741 cùng lô (làm lại vì định nghĩa hoàn thành lỏng lẻo), ⚠ #26713 lô 199 (phân biệt KPI, định nghĩa hoàn thành, tiêu chí nghiệm thu), ⚠ #26729 lô 199 (biểu đồ burndown chỉ tính hạng mục thật sự xong).

⚠ ĐỊNH NGHĨA HOÀN THÀNH — một ví dụ điển hình: | Mục | Nội dung | |---|---| | ⚠ Mã đã được viết và chạy được | | | ⚠ Kiểm thử đơn vị đã viết và tất cả đều xanh | ⚠ liên hệ #26695 lô 199 | | ⚠ Đã qua RÀ SOÁT MÃ | ⚠ liên hệ #26740 cùng lô | | ⚠ Đã tích hợp vào nhánh chính, build thành công | | | ⚠ Tài liệu đã cập nhật | | | ⚠ Đã triển khai lên môi trường kiểm thử | | | ⚠ Chủ sản phẩm đã xem và chấp nhận | | | ⚠ Tính chất quan trọng nhất | ⚠ nó áp cho MỌI hạng mục như nhau, và nó là nhị phân — chưa đủ một mục thì chưa xong, không có "xong 90%" |

⚠ Ba tiêu chí hay bị lẫn trong agile: | Khái niệm | Áp cho | Ai đặt | |---|---|---| | ⚠ ĐỊNH NGHĨA HOÀN THÀNH | ⚠ MỌI hạng mục, giống nhau — ĐÁP ÁN | ⚠ cả đội thống nhất | | ⚠ TIÊU CHÍ NGHIỆM THU | ⚠ RIÊNG từng câu chuyện người dùng | ⚠ chủ sản phẩm | | ⚠ ĐỊNH NGHĨA SẴN SÀNG (ready) | ⚠ hạng mục đủ rõ để đưa vào sprint | ⚠ đội và chủ sản phẩm | | ⚠ Cách nhớ | ⚠ "hoàn thành" là chuẩn CHUNG về chất lượng công việc; "nghiệm thu" là chuẩn RIÊNG về nội dung của từng hạng mục; "sẵn sàng" là điều kiện để bắt đầu |

⚠ Đội mới với agile nên làm gì sau tình huống này: | Việc | Nội dung | |---|---| | ⚠ Đối chiếu nhiệm vụ đang tranh cãi với bảng kiểm ngay | ⚠ giải quyết vấn đề trước mắt | | ⚠ Nếu chưa có định nghĩa hoàn thành thì lập ngay | ⚠ đây là dấu hiệu thiếu nó | | ⚠ Treo nó ở nơi ai cũng thấy | ⚠ liên hệ #26714 lô 199 — bảng thông tin trực quan | | ⚠ Rà lại trong buổi hồi cứu | ⚠ liên hệ #26704 lô 199 | | ⚠ Siết dần khi đội trưởng thành | ⚠ thêm mục khi năng lực cho phép | | ⚠ Dấu hiệu định nghĩa hoàn thành đang quá lỏng | ⚠ các hạng mục "đã xong" lại quay về ở vòng lặp sau — đó chính là hiện tượng mà #26741 cùng lô đang mô tả, và hai câu này là hai mặt của cùng một vấn đề |

Từ khoá nhận diện:

"tranh cãi xong hay chưa xong" → ⚠ ĐỊNH NGHĨA HOÀN THÀNH "tồn đọng sprint" → ⚠ ghi trạng thái, không cung cấp tiêu chí "vận tốc" → ⚠ thước đo của cả đội, không của một nhiệm vụ "tiêu chí nghiệm thu" → ⚠ riêng từng câu chuyện, do chủ sản phẩm đặt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có định nghĩa hoàn thành viết ra không | ⚠ và mọi người có nhớ nó không | | Có hạng mục nào đã đánh dấu xong rồi quay lại không | | | Định nghĩa của bạn có mục nào chỉ tồn tại trên giấy không | |

Và điều mà một bảng kiểm dán trên tường giải quyết được mà không cuộc tranh luận nào giải quyết nổi: hai người đều đúng theo định nghĩa riêng của mình — cho tới khi cả đội đồng ý dùng chung một định nghĩa duy nhất.

Câu 307 Process
At Iceberg Lounge, Rebecca and the relevant stakeholders have identified a few features and user stories in her project that are high-risk. What is the best way for her to deal with these in an agile approach?
  1. A Work on the risky user stories and features as early in the project as possible to confirm that the technological approach is sound.
  2. B Work on these items after the first few sprints, when an architectural spike has been scheduled.
  3. C Work on one high-risk user story per sprint to minimize the risk to each iteration.
  4. D Remove these user stories and features from the sprint plan and place them in the backlog until other factors can reduce the amount of risk.
Xem giải thích

Đáp án

A — LÀM CÁC CÂU CHUYỆN VÀ TÍNH NĂNG RỦI RO CAO CÀNG SỚM CÀNG TỐT ĐỂ XÁC NHẬN HƯỚNG TIẾP CẬN KỸ THUẬT LÀ ĐÚNG.

Vì sao đúng

⚠ Nguyên tắc "thất bại nhanh" trong agile: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro cao thường đi kèm ĐỘ BẤT ĐỊNH cao | ⚠ cần thông tin để giảm bất định, và thông tin chỉ có khi bắt tay làm | | ⚠ Làm sớm thì còn NHIỀU THỜI GIAN để xoay xở | ⚠ phát hiện ở vòng lặp 2 khác hẳn phát hiện ở vòng lặp 9 | | ⚠ Nếu hướng kỹ thuật sai, biết sớm là tiết kiệm lớn nhất | ⚠ có thể đổi hướng, hoặc dừng dự án khi chưa tốn nhiều | | ⚠ Mỗi vòng lặp giảm được rủi ro là một vòng lặp có giá trị | | | ⚠ Kết luận | ⚠ agile xếp ưu tiên theo GIÁ TRỊ và RỦI RO — hạng mục rủi ro cao được kéo lên đầu chính vì lý do này |

⚠ Mâu thuẫn biểu kiến cần hiểu đúng: ⚠ agile ưu tiên giá trị cao trước, nhưng RỦI RO CAO cũng được kéo lên đầu — vì việc gỡ bỏ một điều bất định lớn CHÍNH LÀ một dạng giá trị, ⚠ nó biến một dự án không dự báo được thành một dự án dự báo được.

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

  • B (làm sau vài sprint đầu, khi đã lên lịch một spike kiến trúc) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ spike kiến trúc là công cụ agile hoàn toàn hợp lệ để khám phá vấn đề kỹ thuật khó, nên nó nghe rất chuyên nghiệp: ⚠ nhưng ⚠ nó vẫn HOÃN việc đối mặt với rủi ro thêm vài sprint ⚠ — ⚠ spike có thể là hình thức của việc làm sớm, nhưng chỉ khi nó diễn ra NGAY, không phải sau vài vòng lặp; ⚠ mọi phương án chứa chữ "sau khi..." đều đang đi ngược nguyên tắc giảm rủi ro sớm.

  • C (mỗi sprint làm một câu chuyện rủi ro cao để giảm rủi ro cho từng vòng lặp) — ⚠ rải rủi ro ra cả dự án; ⚠ nghe như quản trị rủi ro nhưng thực tế là kéo dài thời gian sống chung với bất định.

  • D (bỏ khỏi kế hoạch sprint, để trong tồn đọng cho tới khi rủi ro giảm) — ⚠ rủi ro KHÔNG tự giảm khi chờ đợi; ⚠ nó chỉ giảm khi bạn làm gì đó — và đây là phương án nguy hiểm nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26744 cùng lô (xử lý rủi ro đã xảy ra), ⚠ #26764 cùng lô (đánh giá và lập kế hoạch giảm nhẹ), ⚠ #26725 lô 199 (giám sát rủi ro chưa xảy ra), ⚠ #26643 lô 198 (phân tích tiền tử thi), ⚠ #26768 cùng lô (vòng đời gia số để giao giá trị sớm).

⚠ XẾP ƯU TIÊN TỒN ĐỌNG trong agile — các trục: | Trục | Nội dung | |---|---| | ⚠ GIÁ TRỊ KINH DOANH | ⚠ hạng mục mang lại nhiều giá trị nhất | | ⚠ RỦI RO và BẤT ĐỊNH | ⚠ hạng mục gỡ được bất định lớn — CÂU NÀY | | ⚠ PHỤ THUỘC | ⚠ thứ cần cho các hạng mục khác | | ⚠ CHI PHÍ VÀ CÔNG SỨC | ⚠ liên hệ #26715 lô 199 — ma trận giá trị và công sức | | ⚠ Thời điểm cần dùng | ⚠ ràng buộc bên ngoài, hạn pháp lý | | ⚠ Công thức thường dùng | ⚠ nhiều đội xếp theo "giá trị chia cho công sức, cộng thêm điểm rủi ro" — nhưng dù dùng công thức nào thì hạng mục có thể GIẾT DỰ ÁN cũng phải được chạm tới sớm nhất |

⚠ SPIKE — công cụ đúng, dùng đúng chỗ: | Đặc điểm | Nội dung | |---|---| | ⚠ Là một hạng mục nghiên cứu có THỜI LƯỢNG GIỚI HẠN | ⚠ ví dụ: hai ngày để trả lời một câu hỏi kỹ thuật | | ⚠ Đầu ra là TRI THỨC, không phải tính năng | | | ⚠ Dùng khi không thể ước lượng vì chưa hiểu vấn đề | | | ⚠ Nên làm NGAY khi rủi ro được nhận diện | ⚠ chỗ mà phương án B đi sai | | ⚠ Cảnh báo | ⚠ spike không có giới hạn thời gian sẽ biến thành một dự án nghiên cứu không hồi kết — luôn đặt hạn và luôn định nghĩa trước câu hỏi cần trả lời |

⚠ Vì sao "chờ cho rủi ro giảm" là ảo tưởng: | Lý do | Nội dung | |---|---| | ⚠ Rủi ro kỹ thuật chỉ giảm khi ta THỬ | ⚠ thời gian trôi qua không mang lại thông tin nào | | ⚠ Càng để lâu càng nhiều thứ được xây dựa trên giả định chưa kiểm chứng | ⚠ nếu giả định sai thì phần phải làm lại càng lớn | | ⚠ Dư địa xoay xở thu hẹp dần theo thời gian | | | ⚠ Áp lực cuối dự án khiến quyết định tệ hơn | | | ⚠ Câu hỏi kiểm tra hữu ích | ⚠ "nếu điều này hoá ra không làm được, khi nào là muộn nhất mà chúng ta vẫn còn cứu được dự án" — trả lời được câu đó thì bạn biết ngay hạng mục ấy phải nằm ở vòng lặp nào |

Từ khoá nhận diện:

"câu chuyện rủi ro cao trong agile" → ⚠ LÀM SỚM NHẤT CÓ THỂ "sau vài sprint mới làm" → ⚠ vẫn là hoãn, dù có tên gọi chuyên nghiệp "rải mỗi sprint một cái" → ⚠ kéo dài thời gian sống với bất định "chờ rủi ro tự giảm" → ⚠ rủi ro không tự giảm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạng mục rủi ro cao nhất của bạn nằm ở vòng lặp thứ mấy | | | Có giả định kỹ thuật nào chưa được kiểm chứng mà nhiều thứ đang dựa vào không | | | Nếu giả định đó sai, bạn mất bao nhiêu công việc đã làm | |

Và điều mà việc kéo phần đáng sợ nhất lên đầu dự án đổi lấy: vài tuần đầu khó khăn hơn, để đổi lấy việc không phải khám phá vào tháng thứ tám rằng toàn bộ những gì đã xây đều dựa trên một điều không đúng.

Câu 308 People
Susan is a young project manager who has inherited a team that is not working to its potential. The team is reserved both with her and with each other. This behavior has been observed by others when Susan is not present. The previous project manager was eager to hand off the project to Susan without much insight into team dynamics. Susan knows that several team members have reputations for enthusiasm and teamwork, but those traits are not being expressed within the team. What is the best way for Susan to determine the source of the conflict and resolve it?
  1. A Collaborate. Get the team members talking and work on resolutions.
  2. B Smooth things over by presenting everything calmly and hope it approves.
  3. C Forcefulness. As a young PM, Susan needs to show them who the boss is.
  4. D Avoidance. There is no conflict if no one is fighting.
Xem giải thích

Đáp án

A — CỘNG TÁC: đưa các thành viên nói chuyện với nhau và cùng tìm hướng giải quyết.

Vì sao đúng

⚠ Vì sao cộng tác là cách đúng ở đây: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Susan CHƯA BIẾT nguồn gốc của vấn đề | ⚠ cần thông tin, mà thông tin chỉ có từ chính đội | | ⚠ Đội DÈ DẶT chứ không đối đầu | ⚠ chưa có tối hậu thư nào, cửa vẫn còn mở | | ⚠ Các thành viên vốn nổi tiếng nhiệt tình và hợp tác | ⚠ vấn đề nằm ở môi trường, không ở con người | | ⚠ Người quản lý trước bàn giao mà không nói gì về động lực đội | ⚠ có thể chính người đó là một phần của nguyên nhân | | ⚠ Không có áp lực thời gian gấp gáp trong đề | ⚠ có thời gian cho cách bền vững nhất | | ⚠ Kết luận | ⚠ cộng tác vừa tìm ra nguyên nhân, vừa tự nó xây lại lòng tin |

⚠ Đây là câu ĐỐI CHIẾU trực tiếp với #26736 cùng lô: ⚠ ở đó cộng tác đã được thử và thất bại, có tối hậu thư và việc gấp, nên đáp án là CHỈ ĐẠO; ở đây chưa thử gì cả và không ai từ chối hợp tác, nên đáp án là CỘNG TÁC ⚠ — ⚠ hai câu cùng bộ khung, khác nhau ở việc đề đã mô tả những gì ĐÃ ĐƯỢC THỬ.

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

  • B (xoa dịu: trình bày mọi thứ thật nhẹ nhàng và hy vọng ổn thoả) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ với một đội đang dè dặt và một người quản lý mới, việc giữ không khí êm ả nghe như bước đi khôn ngoan để không làm mọi thứ tệ hơn: ⚠ nhưng ⚠ xoa dịu che đi triệu chứng mà không chạm tới nguyên nhân ⚠ — ⚠ và chữ "hy vọng" trong chính phương án đã tự tố cáo: nó không phải một chiến lược; ⚠ với một đội đã im lặng sẵn, thêm một lớp êm dịu nữa chỉ khiến vấn đề chìm sâu hơn.

  • C (ép buộc: là người quản lý trẻ, Susan cần cho họ thấy ai là sếp) — ⚠ sai cả về cách lẫn về lý do; ⚠ dùng quyền lực để chứng minh vị thế cá nhân là cách nhanh nhất phá huỷ lòng tin của một đội vốn đã khép kín.

  • D (né tránh: không ai cãi nhau thì không có xung đột) — ⚠ nhầm sự IM LẶNG với sự HOÀ THUẬN; ⚠ chính sự im lặng mới là triệu chứng đáng lo nhất ở đây.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26736 cùng lô (CÂU ĐỐI CHIẾU — cùng chủ đề, khoá là ÉP BUỘC vì tình huống đã khác), ⚠ #26675 lô 198 (xung đột xây dựng), ⚠ #26537 lô 196 (năm rối loạn của Lencioni), ⚠ #26677 lô 198 (tiếp quản một đội từ người khác), ⚠ #26769 cùng lô (thu thập ý kiến để cải thiện giao tiếp trong đội).

⚠ Vì sao im lặng nguy hiểm hơn cãi vã: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Đội dè dặt với nhau VÀ với người quản lý | ⚠ thiếu an toàn tâm lý | | ⚠ Hành vi đó tồn tại cả khi Susan không có mặt | ⚠ nguyên nhân không phải là cô — nó có từ trước | | ⚠ Người vốn nhiệt tình nay không còn thể hiện | ⚠ họ đã học được rằng ở đây nhiệt tình không an toàn | | ⚠ Người quản lý cũ bàn giao vội, không nói gì về đội | ⚠ chi tiết đáng ngờ nhất trong toàn bộ đề | | ⚠ Chẩn đoán khả dĩ nhất | ⚠ đội đã trải qua điều gì đó dưới thời người quản lý trước — và họ đang chờ xem người mới có khác không trước khi mở lời |

⚠ Susan nên bắt đầu thế nào: | Bước | Việc | |---|---| | ⚠ Gặp RIÊNG từng người trước | ⚠ an toàn hơn cho họ khi nói ra — liên hệ #26769 cùng lô | | ⚠ Hỏi mở, nghe nhiều hơn nói | ⚠ "trước đây mọi việc diễn ra thế nào" thay vì "có vấn đề gì" | | ⚠ Tìm mô thức chung giữa các câu chuyện | | | ⚠ Tạo dịp cho đội nói chuyện với nhau | ⚠ hội thảo, hồi cứu, xây quy tắc ứng xử chung — liên hệ #26759 cùng lô | | ⚠ Chứng minh bằng HÀNH ĐỘNG rằng nói thật là an toàn | ⚠ lần đầu ai đó nói thẳng, phản ứng của Susan quyết định mọi thứ về sau | | ⚠ Điều cần kiên nhẫn | ⚠ lòng tin mất nhanh và xây lại chậm — sẽ mất vài vòng lặp trước khi đội thật sự mở lời, và điều tệ nhất Susan có thể làm là ép họ cởi mở theo lịch của cô |

⚠ Năm cách xử lý xung đột — nhắc lại thang hiệu quả: | Cách | Độ bền của giải pháp | |---|---| | ⚠ CỘNG TÁC | ⚠ bền nhất — cả hai bên cùng thắng, nguyên nhân được xử lý — ĐÁP ÁN | | ⚠ THOẢ HIỆP | ⚠ tạm ổn, không ai hoàn toàn hài lòng | | ⚠ XOA DỊU | ⚠ ngắn hạn, vấn đề quay lại | | ⚠ ÉP BUỘC | ⚠ nhanh nhất, kém bền nhất — nhưng đôi khi cần thiết, #26736 cùng lô | | ⚠ NÉ TRÁNH | ⚠ không giải quyết gì, chỉ hoãn | | ⚠ Cách trả lời dạng câu này trong đề | ⚠ mặc định là CỘNG TÁC; chỉ chuyển sang cách khác khi đề nêu rõ có ràng buộc thời gian gấp, có bên từ chối hợp tác, hoặc cộng tác đã được thử và thất bại |

Từ khoá nhận diện:

"đội im lặng, chưa rõ nguyên nhân, còn thời gian" → ⚠ CỘNG TÁC "đã thử nói chuyện, có tối hậu thư, việc gấp" → ⚠ ép buộc (#26736 cùng lô) "hy vọng mọi thứ tự ổn" → ⚠ xoa dịu, không phải chiến lược "không ai cãi nhau nên không có xung đột" → ⚠ nhầm im lặng với hoà thuận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong buổi họp gần nhất, có ai không nói gì suốt buổi không | | | Lần cuối có người trong đội phản đối ý kiến của bạn là khi nào | ⚠ chưa bao giờ là một câu trả lời đáng lo | | Bạn phản ứng thế nào lần gần nhất ai đó báo tin xấu | |

Và điều mà Susan sẽ khám phá ra khi cuối cùng cũng có người chịu mở lời: đội này không thiếu năng lượng — họ chỉ đã học được từ một người quản lý trước rằng thể hiện nó ra không đem lại điều gì tốt đẹp.

Câu 309 People
Mac anticipates a critical failure of the systems supporting a major data migration initiative. Although the risk has the potential to affect all stakeholders, only a couple of employees have enough knowledge of the systems to determine a fix. The employees ask Mac to have some time to work through potential solutions before bringing the stakeholders into the discussion. Mac identifies the minimum number of stakeholders he thinks should be contacted, as he understands the concern but knows that his stakeholders prefer to be kept informed. What type of communication would be best for Mac to use in this scenario?
  1. A Mass communication
  2. B Interpersonal communication
  3. C Small group communication
  4. D Public communication
Xem giải thích

Đáp án

C — GIAO TIẾP NHÓM NHỎ (small group communication).

Vì sao đúng

⚠ Vì sao đây là loại giao tiếp phù hợp: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Mac xác định SỐ LƯỢNG TỐI THIỂU bên liên quan cần liên hệ | ⚠ một nhóm nhỏ, có chọn lọc | | ⚠ Chỉ vài nhân viên đủ hiểu biết để tìm cách khắc phục | ⚠ nhóm chuyên môn hẹp | | ⚠ Cần thảo luận hai chiều, có phản hồi | ⚠ không phải thông báo một chiều | | ⚠ Nhưng bên liên quan vẫn muốn được thông tin | ⚠ nên không thể im lặng hoàn toàn | | ⚠ Kết luận | ⚠ nhóm nhỏ là điểm cân bằng: đủ người để quyết định, đủ ít để làm việc được |

⚠ Bối cảnh cân bằng hai nhu cầu trái chiều: ⚠ các kỹ sư cần không gian để làm việc trước khi bị chất vấn; bên liên quan cần được biết vì họ ghét bị bất ngờ ⚠ — ⚠ giao tiếp nhóm nhỏ là cách duy nhất thoả mãn cả hai mà không làm hỏng bên nào.

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

  • B (giao tiếp liên cá nhân — interpersonal) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cuộc trao đổi với vài kỹ sư đúng là mang tính cá nhân và trực tiếp, nên nó nghe rất khớp: ⚠ nhưng ⚠ giao tiếp liên cá nhân là giao tiếp MỘT–MỘT ⚠ — ⚠ ở đây Mac cần làm việc với một NHÓM: vài kỹ sư cộng với số bên liên quan tối thiểu; ⚠ chi tiết quyết định là chữ "số lượng tối thiểu bên liên quan", tức là nhiều hơn một người.

  • A (giao tiếp đại chúng — mass communication) — ⚠ gửi tới toàn bộ tổ chức; ⚠ trái hẳn với ý định giới hạn số người biết của Mac.

  • D (giao tiếp công chúng — public communication) — ⚠ hướng ra bên ngoài tổ chức; ⚠ hoàn toàn không phù hợp với một sự cố kỹ thuật chưa có lời giải.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26733 cùng lô (tìm nguyên nhân bên liên quan không nhận được tin), ⚠ #26641 lô 198 (mỗi bên liên quan một sở thích giao tiếp), ⚠ #26692 lô 199 (chọn kênh giàu cho nội dung phức tạp), ⚠ #26721 lô 199 (bên liên quan quyền lực cao đòi thông tin), ⚠ #26780 cùng lô (truyền thông với bên liên quan hoài nghi).

⚠ CÁC LOẠI GIAO TIẾP theo quy mô: | Loại | Quy mô | Ví dụ | |---|---|---| | ⚠ LIÊN CÁ NHÂN | ⚠ hai người | ⚠ gặp riêng, gọi điện — liên hệ #26698 lô 199 | | ⚠ NHÓM NHỎ | ⚠ ba tới khoảng mười người | ⚠ họp đội, họp xử lý sự cố — ĐÁP ÁN | | ⚠ CÔNG CHÚNG | ⚠ một người nói cho một đám đông | ⚠ thuyết trình, hội nghị | | ⚠ ĐẠI CHÚNG | ⚠ rất lớn, ẩn danh | ⚠ thông cáo báo chí, email toàn công ty | | ⚠ MẠNG LƯỚI / XÃ HỘI | ⚠ nhiều chiều, không tập trung | ⚠ diễn đàn nội bộ, mạng xã hội | | ⚠ Nguyên tắc chọn | ⚠ càng ít người thì càng dễ có đối thoại thật; càng nhiều người thì càng phải một chiều — chọn quy mô nhỏ nhất vẫn đủ để ra được quyết định cần ra |

⚠ Mac nên nói gì trong nhóm nhỏ đó: | Nội dung | Nội dung chi tiết | |---|---| | ⚠ Nêu rõ rủi ro đã được nhận diện | ⚠ không giấu, không thổi phồng | | ⚠ Nói rõ đội đang làm gì | ⚠ có người đang tìm giải pháp | | ⚠ Nói rõ CHƯA có kết luận | ⚠ quản lý kỳ vọng ngay từ đầu | | ⚠ Hẹn thời điểm cập nhật tiếp theo | ⚠ quan trọng nhất — nó ngăn được các cuộc gọi hỏi thăm liên tục | | ⚠ Đề nghị điều cần họ hỗ trợ, nếu có | | | ⚠ Vì sao không chờ tới khi có giải pháp | ⚠ bên liên quan phát hiện ra một rủi ro lớn bị giấu sẽ mất lòng tin nhiều hơn nhiều so với việc nghe một tin xấu chưa có lời giải — và trong đề đã nói rõ họ thích được thông tin |

⚠ Cân bằng giữa minh bạch và tạo hoảng loạn: | Nguy cơ nếu nói với QUÁ NHIỀU người | Nguy cơ nếu nói với QUÁ ÍT | |---|---| | ⚠ Tin đồn lan trước khi có sự thật | ⚠ bị coi là che giấu khi lộ ra | | ⚠ Các kỹ sư bị chất vấn liên tục, không còn thời gian làm việc | ⚠ người có quyền quyết định không kịp chuẩn bị | | ⚠ Bên liên quan hành động dựa trên thông tin chưa chín | ⚠ mất lòng tin lâu dài | | ⚠ Cách Mac chọn | ⚠ báo cho SỐ TỐI THIỂU cần biết, kèm cam kết cập nhật — đó là lựa chọn nghiêng về minh bạch mà vẫn bảo vệ được không gian làm việc của đội kỹ thuật |

Từ khoá nhận diện:

"số ít bên liên quan cần thiết, có thảo luận" → ⚠ GIAO TIẾP NHÓM NHỎ "một–một" → ⚠ giao tiếp liên cá nhân "toàn tổ chức" → ⚠ giao tiếp đại chúng "ra ngoài tổ chức" → ⚠ giao tiếp công chúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khi có sự cố, bạn quyết định ai được biết dựa trên gì | | | Bạn có hẹn thời điểm cập nhật tiếp theo không | ⚠ thiếu điều này thì mọi người sẽ tự đi hỏi | | Đội kỹ thuật của bạn có được bảo vệ khỏi việc bị chất vấn liên tục không | |

Và điều mà một cuộc trao đổi đúng người, đúng quy mô mang lại trong một sự cố: đội kỹ thuật có được vài giờ yên tĩnh để làm việc, và bên liên quan có được thứ họ cần nhất — không phải giải pháp, mà là sự chắc chắn rằng có người đang xử lý và mình sẽ được biết.

Câu 310 Process
Abdul's latest project for the Platinum Corporation is behind schedule. With the approval of corporate management, he has decided to crash the critical path. What does crashing the critical path add more of? (Choose the best response.)
  1. A Documentation
  2. B Time
  3. C Cost
  4. D Risk
Xem giải thích

Đáp án

C — CHI PHÍ (cost).

Vì sao đúng

⚠ RÚT NGẮN (crashing) là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Thêm NGUỒN LỰC vào các hoạt động trên ĐƯỜNG GĂNG | ⚠ thêm người, làm thêm giờ, thuê ngoài, mua thiết bị tốt hơn | | ⚠ Mục tiêu: rút ngắn thời gian | | | ⚠ Cái giá TRỰC TIẾP và CHẮC CHẮN: TIỀN | ⚠ ĐÁP ÁN | | ⚠ Chỉ có tác dụng trên đường găng | ⚠ rút ngắn hoạt động không găng thì không rút được tổng thời gian | | ⚠ Nguyên tắc thực hành | ⚠ rút ngắn hoạt động nào có chi phí tăng thêm THẤP NHẤT cho mỗi ngày tiết kiệm được |

⚠ Câu hỏi nói rõ "chọn phương án ĐÚNG NHẤT" — đó là gợi ý rằng có phương án gần đúng: ⚠ rút ngắn CÓ làm tăng rủi ro một chút (người mới cần thời gian hoà nhập, làm thêm giờ dễ sinh lỗi), nhưng RỦI RO là hệ quả đặc trưng của CHẠY SONG SONG, còn CHI PHÍ mới là hệ quả định nghĩa của rút ngắn.

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

  • D (rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thêm người vội vàng và làm thêm giờ thật sự có làm tăng rủi ro, nên phát biểu không sai hoàn toàn: ⚠ nhưng ⚠ rủi ro là hệ quả PHỤ của rút ngắn và là hệ quả CHÍNH của chạy song song (fast-tracking) ⚠ — ⚠ chạy song song không tốn thêm tiền nhưng làm tăng rủi ro phải làm lại; rút ngắn tốn thêm tiền một cách chắc chắn; ⚠ đề yêu cầu chọn phương án ĐÚNG NHẤT, nên phải chọn hệ quả định nghĩa chứ không phải hệ quả phụ.

  • B (thời gian) — ⚠ ngược hoàn toàn; ⚠ mục đích của rút ngắn là GIẢM thời gian.

  • A (tài liệu) — ⚠ không liên quan; ⚠ phương án loại nhanh.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26712 lô 199 (san bằng nguồn lực làm tiến độ dài ra), ⚠ #26563 lô 196 (fast-tracking), ⚠ #26776 cùng lô (quan hệ logic giữa các hoạt động), ⚠ #26749 cùng lô (xử lý rủi ro sớm), ⚠ #26691 lô 199 (so sánh chi phí các phương án).

⚠ BỐN KỸ THUẬT động tới tiến độ — bảng tổng hợp: | Kỹ thuật | Thời gian | Cái giá | |---|---|---| | ⚠ RÚT NGẮN (crashing) | ⚠ NGẮN LẠI | ⚠ CHI PHÍ tăng — ĐÁP ÁN | | ⚠ CHẠY SONG SONG (fast-tracking) | ⚠ NGẮN LẠI | ⚠ RỦI RO tăng, khả năng phải làm lại | | ⚠ SAN BẰNG NGUỒN LỰC (leveling) | ⚠ DÀI RA | ⚠ trễ hạn — liên hệ #26712 lô 199 | | ⚠ LÀM MƯỢT (smoothing) | ⚠ giữ nguyên | ⚠ ăn hết thời gian dự trữ | | ⚠ Cách nhớ cặp đầu | ⚠ crashing trả bằng TIỀN, fast-tracking trả bằng RỦI RO — đó là cách phân biệt duy nhất bạn cần cho đề thi |

⚠ Vì sao rút ngắn không phải lúc nào cũng hiệu quả: | Giới hạn | Nội dung | |---|---| | ⚠ QUY LUẬT LỢI ÍCH GIẢM DẦN | ⚠ gấp đôi người không làm công việc nhanh gấp đôi | | ⚠ Định luật Brooks | ⚠ thêm người vào một dự án phần mềm đang trễ sẽ làm nó trễ thêm | | ⚠ Có việc không chia nhỏ được | ⚠ chín phụ nữ không sinh được một em bé trong một tháng | | ⚠ Người mới cần thời gian hoà nhập | ⚠ và lấy mất thời gian của người cũ để hướng dẫn | | ⚠ Làm thêm giờ kéo dài làm giảm năng suất và chất lượng | ⚠ liên hệ #26674 lô 198 — nhịp độ bền vững | | ⚠ Vì thế | ⚠ rút ngắn hiệu quả nhất với các công việc CHIA NHỎ ĐƯỢC và ÍT PHỤ THUỘC vào tri thức riêng của một người — biết trước điều này giúp bạn không hứa với nhà tài trợ một điều mà việc thêm người không thể mua được |

⚠ Quy trình rút ngắn có kỷ luật: | Bước | Việc | |---|---| | ⚠ 1. Xác định ĐƯỜNG GĂNG | ⚠ chỉ rút ngắn ở đó mới có tác dụng | | ⚠ 2. Tính CHI PHÍ TĂNG THÊM cho mỗi ngày tiết kiệm | ⚠ của từng hoạt động | | ⚠ 3. Rút ngắn hoạt động có tỉ lệ rẻ nhất trước | | | ⚠ 4. Tính lại đường găng | ⚠ rút ngắn có thể tạo ra một đường găng MỚI | | ⚠ 5. Lặp cho tới khi đạt mục tiêu hoặc hết ngân sách | | | ⚠ 6. Đưa thay đổi qua kiểm soát thay đổi | ⚠ liên hệ #26739 cùng lô | | ⚠ Bước hay bị bỏ | ⚠ bước 4 — sau khi rút ngắn, một chuỗi hoạt động khác có thể trở thành đường găng, và tiền bỏ thêm vào chuỗi cũ từ đó không mua được ngày nào nữa |

Từ khoá nhận diện:

"rút ngắn đường găng / crashing" → ⚠ tăng CHI PHÍ "chạy song song / fast-tracking" → ⚠ tăng RỦI RO "san bằng nguồn lực" → ⚠ tăng THỜI GIAN "chọn phương án đúng nhất" → ⚠ tìm hệ quả ĐỊNH NGHĨA, không phải hệ quả phụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết đường găng của dự án mình không | ⚠ rút ngắn ở nơi khác là tiêu tiền vô ích | | Chi phí cho mỗi ngày rút ngắn được là bao nhiêu | | | Sau khi rút ngắn, bạn có tính lại đường găng không | |

Và điều mà một quyết định rút ngắn được phê duyệt từ cấp trên thật sự có nghĩa: tổ chức vừa đồng ý mua thời gian bằng tiền — và việc của Abdul là bảo đảm rằng mỗi đồng chi thêm thật sự đổi được một ngày, chứ không chỉ đổi được cảm giác đang làm gì đó.