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

Tìm thấy 718 câu.

Câu 261 Process
A portion of Rowen's latest project, the Tory Project, contains some dangerous work. Her project team members could likely do the work, but the sponsor does not want to accept the risk. In this scenario, which of the following responses could be used as a tool for risk mitigation?
  1. A A vendor proposal
  2. B Project requirements
  3. C A quotation
  4. D A contract
Xem giải thích

Đáp án

D — HỢP ĐỒNG (a contract).

Vì sao đúng

⚠ Vì sao hợp đồng là công cụ giảm nhẹ rủi ro ở đây: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Công việc NGUY HIỂM | ⚠ rủi ro về an toàn, sức khoẻ, trách nhiệm pháp lý | | ⚠ Đội của Rowen LÀM ĐƯỢC nhưng nhà tài trợ KHÔNG MUỐN NHẬN rủi ro | ⚠ quyết định không nằm ở năng lực mà ở khẩu vị rủi ro | | ⚠ Hợp đồng là VĂN BẢN RÀNG BUỘC chuyển trách nhiệm sang bên khác | ⚠ nhà thầu chuyên làm việc nguy hiểm, có bảo hiểm, có quy trình an toàn | | ⚠ Chỉ hợp đồng mới TẠO RA nghĩa vụ pháp lý | ⚠ ba phương án còn lại không làm được điều đó | | ⚠ Kết luận | ⚠ thuê ngoài phần việc nguy hiểm bằng hợp đồng = chuyển giao rủi ro có hiệu lực |

⚠ Lưu ý về từ ngữ: ⚠ đề dùng chữ "risk mitigation" theo nghĩa rộng là "xử lý rủi ro"; theo phân loại chặt của PMBOK, việc dùng hợp đồng để đẩy rủi ro sang bên thứ ba chính xác là CHUYỂN GIAO (transfer) ⚠ — ⚠ cả hai cách gọi đều dẫn tới cùng một đáp án.

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

  • A (đề xuất của nhà cung cấp — vendor proposal) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng đến từ nhà cung cấp và cũng là một bước trong quá trình thuê ngoài, nên nghe rất gần với đáp án: ⚠ nhưng ⚠ đề xuất chỉ là LỜI MỜI CHÀO — nó không ràng buộc ai làm gì ⚠ — ⚠ rủi ro chỉ thật sự chuyển đi vào khoảnh khắc hai bên KÝ HỢP ĐỒNG; ⚠ đề xuất là đầu vào của việc chọn nhà cung cấp, hợp đồng là đầu ra.

  • C (báo giá — quotation) — ⚠ chỉ là con số về giá; ⚠ không tạo nghĩa vụ, không phân định trách nhiệm.

  • B (yêu cầu dự án) — ⚠ mô tả CÁI GÌ cần làm; ⚠ nó không nói ai chịu rủi ro khi làm việc đó.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26693 cùng lô (IPD chia sẻ rủi ro thay vì chuyển giao), ⚠ #26558 lô 196 (loại hợp đồng quyết định ai gánh rủi ro), ⚠ #26718 cùng lô (hai yếu tố bắt buộc của hợp đồng), ⚠ #26607 lô 197 (giá trị tiền tệ kỳ vọng và quyết định giảm nhẹ), ⚠ #26684 cùng lô (thẩm quyền mua sắm).

⚠ BỐN CHIẾN LƯỢC với rủi ro TIÊU CỰC: | Chiến lược | Nội dung | Ví dụ | |---|---|---| | ⚠ NÉ TRÁNH (avoid) | ⚠ bỏ hẳn phần việc hoặc đổi cách làm | ⚠ không làm phần nguy hiểm nữa | | ⚠ CHUYỂN GIAO (transfer) | ⚠ đẩy tác động sang bên thứ ba — ĐÁP ÁN | ⚠ HỢP ĐỒNG, bảo hiểm, bảo lãnh thực hiện | | ⚠ GIẢM NHẸ (mitigate) | ⚠ hạ xác suất hoặc tác động | ⚠ đào tạo an toàn, mua thiết bị bảo hộ | | ⚠ CHẤP NHẬN (accept) | ⚠ chủ động có dự phòng, hoặc bị động | ⚠ để quỹ dự phòng cho tai nạn | | ⚠ Điều quan trọng cần nhớ | ⚠ chuyển giao KHÔNG làm rủi ro biến mất — nó chỉ đổi người gánh, và luôn có PHÍ: giá của nhà thầu chuyên nghiệp đã bao gồm khoản họ tính cho rủi ro đó |

⚠ Loại hợp đồng quyết định rủi ro chuyển đi được bao nhiêu: | Loại | Ai gánh rủi ro chi phí | Dùng khi | |---|---|---| | ⚠ GIÁ CỐ ĐỊNH (fixed price) | ⚠ NHÀ THẦU gánh nhiều nhất | ⚠ phạm vi rõ — hợp với ca của Rowen | | ⚠ HOÀN PHÍ (cost reimbursable) | ⚠ CHỦ ĐẦU TƯ gánh nhiều nhất | ⚠ phạm vi chưa rõ | | ⚠ THỜI GIAN VÀ VẬT TƯ (T&M) | ⚠ chia sẻ, nghiêng về chủ đầu tư | ⚠ việc nhỏ, cần bắt đầu ngay | | ⚠ Với công việc nguy hiểm | ⚠ hợp đồng giá cố định kèm điều khoản BẢO HIỂM TRÁCH NHIỆM và yêu cầu chứng nhận an toàn là cấu hình chuyển giao rủi ro mạnh nhất — liên hệ #26558 lô 196 |

⚠ Điều Rowen KHÔNG chuyển đi được bằng hợp đồng: | Thứ | Vì sao | |---|---| | ⚠ Trách nhiệm cuối cùng với kết quả dự án | ⚠ hợp đồng chuyển việc, không chuyển được trách nhiệm giải trình | | ⚠ Uy tín của tổ chức nếu có tai nạn xảy ra | ⚠ công chúng nhìn vào chủ dự án | | ⚠ Rủi ro tiến độ nếu nhà thầu chậm | ⚠ phạt hợp đồng không mua lại được thời gian | | ⚠ Nghĩa vụ giám sát an toàn tại công trường | ⚠ nhiều nơi luật quy định chủ đầu tư vẫn liên đới | | ⚠ Vì thế | ⚠ ký hợp đồng xong vẫn phải ghi rủi ro vào sổ và tiếp tục theo dõi — chuyển giao là một phản ứng, không phải một dấu chấm hết |

Từ khoá nhận diện:

"thuê bên ngoài làm phần nguy hiểm" → ⚠ HỢP ĐỒNG — chuyển giao rủi ro "đề xuất của nhà cung cấp" → ⚠ chưa ràng buộc, chưa chuyển được gì "báo giá" → ⚠ chỉ là con số "yêu cầu dự án" → ⚠ nói cái gì cần làm, không nói ai chịu rủi ro

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có ghi rõ ai chịu rủi ro nào không | | | Bạn có yêu cầu nhà thầu chứng minh bảo hiểm không | | | Rủi ro đã chuyển giao có còn nằm trong sổ rủi ro của bạn không | ⚠ nó nên còn |

Và điều đáng nhớ về việc mua sự an tâm bằng một chữ ký: hợp đồng chuyển được nghĩa vụ và chuyển được chi phí, nhưng không chuyển được việc bạn sẽ là người đứng ra trả lời nếu có chuyện xảy ra trên công trường của mình.

Câu 262 Process
Sarah uses sprint retrospectives to make her team more effective. The way that she is most likely to do this is
  1. A To reflect on increasing customer value and effectiveness through retrospection and adjustment in behaviors going forward.
  2. B To focus on doing a retrospective only as part of the product planning cycle, not as a specific part of the sprint cycles.
  3. C At the end of every major production release, they assess each member of the team.
  4. D At the beginning of each cycle, she shows the development team a demo of what has been built to date.
Xem giải thích

Đáp án

A — SUY NGẪM ĐỂ TĂNG GIÁ TRỊ CHO KHÁCH HÀNG VÀ TĂNG HIỆU QUẢ, RỒI ĐIỀU CHỈNH HÀNH VI CHO CÁC VÒNG SAU.

Vì sao đúng

⚠ Hai vế của một buổi hồi cứu đúng nghĩa: | Vế | Nội dung | |---|---| | ⚠ SUY NGẪM (inspect) | ⚠ nhìn lại vòng lặp vừa qua: cái gì hiệu quả, cái gì không | | ⚠ ĐIỀU CHỈNH (adapt) | ⚠ thay đổi CÁCH LÀM VIỆC cho vòng tiếp theo | | ⚠ Mục tiêu kép: GIÁ TRỊ cho khách và HIỆU QUẢ của đội | ⚠ cả sản phẩm lẫn quy trình | | ⚠ Diễn ra ở MỌI vòng lặp | ⚠ không phải mỗi cuối dự án | | ⚠ Kết luận | ⚠ hồi cứu là cơ chế cải tiến liên tục được đưa vào nhịp làm việc — đúng như phương án A mô tả |

⚠ Đây là "inspect and adapt" — trụ cột của mọi khung agile: ⚠ minh bạch, kiểm tra, thích ứng ⚠ — ⚠ hồi cứu là nơi trụ cột thứ ba được thực hiện với chính CÁCH LÀM VIỆC của đội.

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

  • C (cuối mỗi lần phát hành lớn thì đánh giá TỪNG THÀNH VIÊN) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng nói về việc nhìn lại và cũng nhắc tới một nhịp định kỳ, nghe như một biến thể hợp lý của hồi cứu: ⚠ nhưng ⚠ nó sai ở HAI điểm cùng lúc — nhịp SAI (mỗi lần phát hành thay vì mỗi vòng lặp) và đối tượng SAI (đánh giá CON NGƯỜI thay vì cải tiến QUY TRÌNH) ⚠ — ⚠ đánh giá cá nhân trong một buổi họp chung chính là thứ biến hồi cứu thành phiên toà, liên hệ #26700 cùng lô.

  • B (chỉ hồi cứu trong chu kỳ lập kế hoạch sản phẩm, không gắn với vòng lặp) — ⚠ sai nhịp; ⚠ hồi cứu thuộc về nhịp vòng lặp, đó là lý do nó tạo ra cải tiến nhanh.

  • D (đầu mỗi chu kỳ trình diễn bản demo cho đội phát triển) — ⚠ đó là buổi RÀ SOÁT SPRINT (sprint review) và nó dành cho bên liên quan, không phải hồi cứu; ⚠ hai buổi này khác nhau về mục đích và người tham dự.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26700 cùng lô (hồi cứu là để cải tiến, không phải đổ lỗi), ⚠ #26717 cùng lô (cải tiến liên tục và sự hài lòng của khách hàng), ⚠ #26695 cùng lô (TDD — vòng lặp phản hồi ngắn), ⚠ #26728 cùng lô (tái cấu trúc là một hành động cải tiến), ⚠ #26709 cùng lô (vận tốc — thước đo mà hồi cứu tìm cách cải thiện).

⚠ HAI BUỔI HỌP CUỐI VÒNG LẶP — đừng lẫn: | Tiêu chí | RÀ SOÁT SPRINT (review) | HỒI CỨU (retrospective) | |---|---|---| | ⚠ Nhìn vào | ⚠ SẢN PHẨM | ⚠ CÁCH LÀM VIỆC | | ⚠ Ai dự | ⚠ đội + chủ sản phẩm + BÊN LIÊN QUAN | ⚠ chỉ đội (và scrum master) | | ⚠ Câu hỏi | ⚠ "chúng ta đã làm ra cái gì, có đúng ý không" | ⚠ "chúng ta làm việc với nhau thế nào" | | ⚠ Đầu ra | ⚠ phản hồi, cập nhật tồn đọng sản phẩm | ⚠ HÀNH ĐỘNG CẢI TIẾN cụ thể | | ⚠ Thứ tự | ⚠ trước | ⚠ sau — ĐÁP ÁN nói về buổi này | | ⚠ Lý do tách hai buổi | ⚠ có bên liên quan trong phòng thì đội sẽ không nói thật về những chỗ mình làm chưa tốt — an toàn tâm lý cần một không gian riêng |

⚠ Một buổi hồi cứu hiệu quả trông thế nào: | Bước | Nội dung | |---|---| | ⚠ Mở đầu — đặt bối cảnh và đọc chỉ thị chính | ⚠ liên hệ #26700 cùng lô | | ⚠ Thu thập dữ liệu | ⚠ sự kiện, số liệu, cảm nhận trong vòng lặp vừa qua | | ⚠ Sinh hiểu biết | ⚠ vì sao chuyện đó xảy ra — nhìn vào hệ thống | | ⚠ Quyết định làm gì | ⚠ chọn MỘT hoặc HAI hành động, không phải mười | | ⚠ Kết thúc — chốt người phụ trách và cách kiểm chứng | | | ⚠ Dấu hiệu hồi cứu đang thất bại | ⚠ cùng một vấn đề được nêu ra ở ba vòng liên tiếp mà không có hành động nào thay đổi — khi đó buổi họp đã thành nghi thức, và đội sẽ ngừng nói thật |

⚠ Vì sao "tăng giá trị cho khách hàng" nằm trong mục tiêu của hồi cứu: | Lý do | Nội dung | |---|---| | ⚠ Cải tiến quy trình để làm ra thứ ĐÚNG hơn, không chỉ NHANH hơn | | | ⚠ Đội có thể nhận ra mình đang làm những việc không ai dùng | ⚠ liên hệ #26711 cùng lô — sản phẩm khả dụng tối thiểu | | ⚠ Phản hồi từ buổi rà soát được mang sang buổi hồi cứu | ⚠ hai buổi nối nhau | | ⚠ Hiệu quả của đội cuối cùng cũng quy về giá trị giao được | | | ⚠ Sai lầm phổ biến | ⚠ coi hồi cứu chỉ là chuyện nội bộ của đội — trong khi mọi cải tiến quy trình đều phải trả lời được câu "điều này giúp khách hàng nhận được giá trị nhanh hơn hay tốt hơn ở chỗ nào" |

Từ khoá nhận diện:

"suy ngẫm và điều chỉnh hành vi cho vòng sau" → ⚠ HỒI CỨU "đánh giá từng thành viên" → ⚠ không phải hồi cứu, và phá huỷ hồi cứu "chỉ làm ở chu kỳ sản phẩm" → ⚠ sai nhịp "trình diễn bản demo" → ⚠ rà soát sprint, khác buổi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hành động cải tiến của vòng trước đã làm chưa | ⚠ kiểm tra ở đầu buổi hồi cứu tiếp theo | | Buổi hồi cứu của bạn có bên liên quan ngồi dự không | ⚠ nếu có, đội sẽ không nói thật | | Bạn chọn mấy hành động mỗi buổi | ⚠ mười hành động nghĩa là không hành động nào |

Và điều làm nên khác biệt giữa một đội cải tiến và một đội chỉ họp hồi cứu: không phải chất lượng của cuộc thảo luận, mà là việc vòng lặp sau có thật sự làm khác đi một điều gì đó hay không.

Câu 263 People
You are the project manager of a large, complex technical project for your organization. This project has a budget of $2,500,000 and is due for completion in six months. In a weekly meeting with your project's sponsor, it is brought to your attention that a large portion of the scope will be cut from the project. The work that was to be done was originally going to be provided by a contractor. Your organization and the contractor have already signed the contract. What should you do first?
  1. A Review the contract terms with your procurement office.
  2. B Issue payment for the work provided, but not for the work that has not been completed.
  3. C Tell the contractor to stop all work.
  4. D Tell the procurement office not to issue payment to the contractor.
Xem giải thích

Đáp án

A — RÀ SOÁT CÁC ĐIỀU KHOẢN HỢP ĐỒNG CÙNG PHÒNG MUA SẮM.

Vì sao đúng

⚠ Vì sao đây là việc ĐẦU TIÊN: | Lý do | Nội dung | |---|---| | ⚠ Hợp đồng ĐÃ ĐƯỢC KÝ | ⚠ nó là văn bản ràng buộc pháp lý, không phải kế hoạch nội bộ | | ⚠ Hợp đồng thường có điều khoản CHẤM DỨT và điều khoản BỒI HOÀN | ⚠ phải biết mình được phép làm gì trước khi làm | | ⚠ Phòng mua sắm là bộ phận có chuyên môn pháp lý | ⚠ liên hệ #26684 cùng lô — mô hình tập trung | | ⚠ Hành động sai có thể khiến tổ chức bị kiện vì vi phạm hợp đồng | ⚠ rủi ro lớn hơn nhiều so với việc chậm một ngày | | ⚠ Câu hỏi hỏi "làm gì TRƯỚC" | ⚠ thu thập thông tin đứng trước hành động | | ⚠ Kết luận | ⚠ hiểu nghĩa vụ pháp lý trước, rồi mới quyết định cách xử lý |

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

  • C (bảo nhà thầu dừng toàn bộ công việc) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ dừng ngay nghe rất hợp lý về mặt kinh tế — phạm vi bị cắt thì tiếp tục làm là lãng phí tiền, và nhiều người coi đây là hành động "quyết đoán" đúng đắn: ⚠ nhưng ⚠ lệnh dừng công việc là một hành động PHÁP LÝ, và ai được ra lệnh đó cùng với hậu quả của nó do chính hợp đồng quy định ⚠ — ⚠ ra lệnh dừng sai cách có thể cấu thành vi phạm hợp đồng và khiến tổ chức phải bồi thường toàn bộ giá trị còn lại; ⚠ nó cũng có thể là bước đúng — nhưng chỉ SAU khi đã đọc hợp đồng.

  • D (bảo phòng mua sắm đừng thanh toán cho nhà thầu) — ⚠ giữ tiền của công việc đã làm là vi phạm hợp đồng; ⚠ và nó phá quan hệ với nhà thầu ngay lập tức.

  • B (thanh toán phần đã làm, không trả phần chưa làm) — ⚠ nghe công bằng nhưng vẫn là hành động đơn phương trước khi đọc hợp đồng; ⚠ hợp đồng có thể quy định phí chấm dứt hoặc bồi hoàn chi phí đã cam kết mà bạn vẫn phải trả.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26684 cùng lô (mô hình mua sắm tập trung và phi tập trung), ⚠ #26558 lô 196 (các loại hợp đồng), ⚠ #26718 cùng lô (hai yếu tố bắt buộc của hợp đồng), ⚠ #26703 cùng lô (hợp đồng như công cụ rủi ro), ⚠ #26634 lô 198 (thay đổi phải qua ban kiểm soát thay đổi).

⚠ Trình tự đúng khi phạm vi bị cắt mà hợp đồng đã ký: | Bước | Việc | |---|---| | ⚠ 1. RÀ SOÁT HỢP ĐỒNG với phòng mua sắm | ⚠ ĐÁP ÁN — điều khoản chấm dứt, phí, thông báo | | ⚠ 2. Xác định phương án: chấm dứt toàn bộ, chấm dứt một phần, hay tạm dừng | | | ⚠ 3. Đưa thay đổi qua kiểm soát thay đổi tích hợp | ⚠ cắt phạm vi là một thay đổi chính thức | | ⚠ 4. Thông báo cho nhà thầu ĐÚNG hình thức hợp đồng quy định | ⚠ thường phải bằng văn bản, có thời hạn báo trước | | ⚠ 5. Thanh toán phần đã thực hiện và các khoản theo điều khoản | | | ⚠ 6. Đóng hợp đồng, lưu hồ sơ | ⚠ liên hệ #26689 cùng lô | | ⚠ Sai lầm điển hình | ⚠ làm bước 4 trước bước 1 — gọi cho nhà thầu bảo dừng vì "sếp vừa quyết" là câu chuyện dẫn tới tranh chấp nhiều nhất trong quản lý mua sắm |

⚠ Các điều khoản cần đọc kỹ trong tình huống này: | Điều khoản | Nội dung | |---|---| | ⚠ CHẤM DỨT VÌ TIỆN ÍCH (termination for convenience) | ⚠ chủ đầu tư được dừng không cần lỗi của nhà thầu, nhưng thường phải trả phí | | ⚠ CHẤM DỨT VÌ VI PHẠM (for cause) | ⚠ chỉ áp dụng khi nhà thầu làm sai — không phải ca này | | ⚠ Điều khoản thay đổi phạm vi | ⚠ cho phép điều chỉnh khối lượng theo công thức nào | | ⚠ Thời hạn và hình thức thông báo | ⚠ thiếu bước này thì thông báo vô hiệu | | ⚠ Chi phí đã cam kết của nhà thầu | ⚠ vật tư đã đặt, người đã tuyển — thường vẫn phải bồi hoàn | | ⚠ Nguyên tắc | ⚠ "chúng tôi không cần nữa" không phải là một căn cứ chấm dứt — nó là một quyết định kinh doanh, và hợp đồng quy định cái giá của quyết định đó |

⚠ Vì sao đề nhấn mạnh "hợp đồng ĐÃ ĐƯỢC KÝ": | Ý nghĩa | Nội dung | |---|---| | ⚠ Nghĩa vụ đã phát sinh với bên thứ ba | ⚠ không còn là chuyện nội bộ tổ chức | | ⚠ Quyết định của nhà tài trợ KHÔNG tự động huỷ nghĩa vụ hợp đồng | ⚠ đây là chỗ nhiều người nhầm | | ⚠ Nhà thầu có thể đã bố trí nguồn lực và từ chối việc khác | ⚠ thiệt hại thật của họ là có căn cứ | | ⚠ Bài học | ⚠ mọi thay đổi trong dự án đều rẻ nhất khi còn nằm trên giấy của chính mình; qua một chữ ký với bên ngoài, cái giá của cùng một thay đổi thường nhân lên nhiều lần |

Từ khoá nhận diện:

"hợp đồng đã ký, phạm vi bị cắt" → ⚠ ĐỌC HỢP ĐỒNG với phòng mua sắm TRƯỚC "bảo nhà thầu dừng ngay" → ⚠ hành động pháp lý, không làm trước khi đọc "giữ tiền công việc đã làm" → ⚠ vi phạm hợp đồng "làm gì TRƯỚC" → ⚠ thu thập thông tin luôn đứng trước hành động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết hợp đồng của mình cho phép chấm dứt thế nào không | | | Ai trong tổ chức có quyền ra lệnh dừng công việc cho nhà thầu | | | Nhà thầu của bạn đã cam kết chi phí gì mà bạn chưa biết | |

Và điều đáng nhớ về một quyết định cắt phạm vi được truyền xuống từ cuộc họp với nhà tài trợ: nó thay đổi kế hoạch của bạn ngay lập tức, nhưng nó không thay đổi được một dòng nào trong bản hợp đồng đã ký — và khoảng cách giữa hai điều đó chính là việc bạn phải xử lý.

Câu 264 Business Environment
Kristin is the project manager for a software project. She comes from a cybersecurity background, so she is eager to leverage her knowledge to make her product safe for her clients and her company. She reviews the standard compliance requirement matrix for the software she creates and uses it to create a cybersecurity checklist for the project. How is project compliance being managed?
  1. A Compliance risk
  2. B Compliance audit
  3. C Compliance council
  4. D Compliance documentation
Xem giải thích

Đáp án

D — TÀI LIỆU TUÂN THỦ (compliance documentation).

Vì sao đúng

⚠ Kristin đang làm gì: | Việc | Ý nghĩa | |---|---| | ⚠ Rà soát MA TRẬN YÊU CẦU TUÂN THỦ chuẩn | ⚠ đọc một TÀI LIỆU quy định các yêu cầu bắt buộc | | ⚠ Dùng nó để lập BẢNG KIỂM an ninh mạng cho dự án | ⚠ tạo ra một TÀI LIỆU mới, cụ thể cho dự án | | ⚠ Không kiểm toán, không đánh giá rủi ro, không lập hội đồng | ⚠ loại ba phương án còn lại | | ⚠ Kết luận | ⚠ biến yêu cầu tuân thủ thành văn bản làm việc được = quản lý tuân thủ bằng tài liệu |

⚠ Vì sao bảng kiểm là hình thức tài liệu tuân thủ tốt: ⚠ nó biến một danh sách quy định trừu tượng thành các mục KIỂM ĐƯỢC, GHI LẠI ĐƯỢC và CHỨNG MINH ĐƯỢC ⚠ — ⚠ trong lĩnh vực tuân thủ, việc bạn đã làm đúng mà không có hồ sơ thường bị coi như chưa làm.

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

  • B (kiểm toán tuân thủ — compliance audit) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ kiểm toán cũng dùng bảng kiểm, cũng đối chiếu với chuẩn, nên hai việc trông rất giống nhau trên giấy: ⚠ nhưng ⚠ kiểm toán là hoạt động KIỂM TRA SAU, thường do bên độc lập thực hiện trên công việc đã làm ⚠ — ⚠ Kristin đang CHUẨN BỊ công cụ trước khi làm, không phải đi kiểm ai; ⚠ bảng kiểm cô lập ra hôm nay có thể sẽ được dùng trong một cuộc kiểm toán sau này, nhưng việc tạo ra nó không phải là kiểm toán.

  • A (rủi ro tuân thủ) — ⚠ là việc PHÂN TÍCH khả năng và hậu quả của việc không tuân thủ; ⚠ Kristin không đánh giá xác suất hay tác động.

  • C (hội đồng tuân thủ) — ⚠ là một CƠ CẤU TỔ CHỨC gồm nhiều người; ⚠ đề chỉ nói về một người và một tài liệu.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26690 cùng lô (quản lý cấu hình), ⚠ #26658 lô 198 (cập nhật kế hoạch bảo đảm chất lượng), ⚠ #26697 cùng lô (kiểm soát chất lượng), ⚠ #26667 lô 198 (bảo đảm tài liệu tiếp cận được), ⚠ #26634 lô 198 (quy định mới xuất hiện giữa dự án).

⚠ BỐN CÁCH quản lý tuân thủ trong dự án: | Cách | Nội dung | Khi nào dùng | |---|---|---| | ⚠ TÀI LIỆU TUÂN THỦ | ⚠ ma trận yêu cầu, bảng kiểm, quy trình viết ra — ĐÁP ÁN | ⚠ chuẩn bị và thực thi hằng ngày | | ⚠ KIỂM TOÁN TUÂN THỦ | ⚠ kiểm tra độc lập việc thực hiện | ⚠ định kỳ hoặc theo yêu cầu | | ⚠ RỦI RO TUÂN THỦ | ⚠ đánh giá hậu quả nếu vi phạm | ⚠ khi lập kế hoạch rủi ro | | ⚠ HỘI ĐỒNG TUÂN THỦ | ⚠ cơ cấu ra quyết định về các vấn đề tuân thủ | ⚠ ngành có quy định ngặt: y tế, tài chính, hàng không | | ⚠ Quan hệ giữa bốn cách | ⚠ tài liệu là NỀN — không có nó thì kiểm toán không có căn cứ, đánh giá rủi ro không có mốc, và hội đồng không có gì để xét |

⚠ Bảng kiểm an ninh mạng của Kristin nên có gì: | Mục | Ví dụ | |---|---| | ⚠ Yêu cầu bắt buộc theo chuẩn và theo luật | ⚠ mã hoá dữ liệu, lưu nhật ký truy cập, thời hạn lưu trữ | | ⚠ Ai chịu trách nhiệm cho từng mục | | | ⚠ Bằng chứng cần thu thập | ⚠ ảnh chụp cấu hình, kết quả quét, biên bản rà soát | | ⚠ Thời điểm kiểm trong vòng đời dự án | ⚠ thiết kế, trước khi phát hành, sau khi triển khai | | ⚠ Cách xử lý khi một mục không đạt | | | ⚠ Giá trị lớn nhất | ⚠ bảng kiểm biến kiến thức chuyên môn của riêng Kristin thành thứ mà cả đội dùng được — và thành thứ vẫn còn giá trị sau khi cô chuyển sang dự án khác |

⚠ Vì sao tuân thủ đáng được coi là một hạng mục quản lý riêng: | Lý do | Nội dung | |---|---| | ⚠ Hậu quả của vi phạm là phi tuyến | ⚠ phạt tiền, đình chỉ, mất giấy phép — không tỉ lệ với mức độ sai | | ⚠ Yêu cầu tuân thủ thường KHÔNG thương lượng được | ⚠ khác với yêu cầu chức năng thông thường | | ⚠ Chúng có thể thay đổi giữa chừng dự án | ⚠ liên hệ #26634 lô 198 | | ⚠ Chi phí sửa vào cuối rất cao | ⚠ bảo mật gắn từ đầu rẻ hơn vá vào lúc sắp phát hành | | ⚠ Vì thế | ⚠ việc Kristin làm bảng kiểm ngay từ đầu chính là hình thức phòng ngừa rẻ nhất — một chi phí NGĂN NGỪA theo phân loại chi phí chất lượng, liên hệ #26679 lô 198 |

Từ khoá nhận diện:

"lập ma trận, bảng kiểm, quy trình viết ra" → ⚠ TÀI LIỆU TUÂN THỦ "kiểm tra độc lập việc đã làm" → ⚠ kiểm toán tuân thủ "đánh giá hậu quả nếu vi phạm" → ⚠ rủi ro tuân thủ "một nhóm người ra quyết định" → ⚠ hội đồng tuân thủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có danh sách yêu cầu tuân thủ viết ra không | | | Bạn có bằng chứng cho từng mục không | ⚠ "chúng tôi có làm" không đủ khi bị hỏi | | Ai kiểm tra bảng kiểm đó và vào lúc nào | |

Và điều mà một bảng kiểm được lập trước khi viết dòng mã đầu tiên thật sự mua được: quyền không phải quay lại sửa vào tuần cuối, khi mọi thứ đã gắn chặt vào nhau và không còn ai đủ thời gian để làm cho đúng.

Câu 265 Business Environment
To determine the value of his project at Kord Enterprises, Kevin calculated the ratio of expected profits the company would receive to the expected project costs. The calculation he used was
  1. A Net Present Value
  2. B Return on Investment
  3. C Net Investment Value
  4. D Return on Income
Xem giải thích

Đáp án

B — TỈ SUẤT HOÀN VỐN (Return on Investment, ROI).

Vì sao đúng

⚠ Đề mô tả đúng công thức: | Yếu tố trong đề | Công thức | |---|---| | ⚠ "TỈ LỆ giữa lợi nhuận kỳ vọng và chi phí kỳ vọng" | ⚠ một PHÉP CHIA, ra một tỉ lệ phần trăm | | ⚠ ROI = (lợi ích − chi phí) ÷ chi phí | ⚠ hoặc lợi nhuận ròng ÷ vốn đầu tư | | ⚠ Kết quả là con số KHÔNG có đơn vị tiền | ⚠ đó là dấu hiệu của một tỉ số | | ⚠ Kết luận | ⚠ "tỉ lệ lợi nhuận trên chi phí" chính là định nghĩa của ROI |

⚠ Mẹo phân biệt cả nhóm chỉ số tài chính: ⚠ hỏi kết quả ra ĐƠN VỊ GÌ ⚠ — ⚠ ra PHẦN TRĂM hoặc TỈ SỐ thì là ROI hoặc BCR; ra SỐ TIỀN thì là NPV hoặc EMV; ra THỜI GIAN thì là thời gian hoàn vốn.

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

  • A (giá trị hiện tại ròng — NPV) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là chỉ số so sánh lợi ích với chi phí, và cũng là công cụ chọn dự án hàng đầu, nên rất dễ chọn theo phản xạ: ⚠ nhưng ⚠ NPV là một HIỆU SỐ TIỀN sau khi chiết khấu dòng tiền về hiện tại, không phải một TỈ LỆ ⚠ — ⚠ NPV trả lời "dự án tạo thêm bao nhiêu ĐÔ LA giá trị", còn ROI trả lời "mỗi đồng bỏ ra sinh ra bao nhiêu PHẦN TRĂM"; ⚠ đề nói rõ chữ "tỉ lệ" (ratio), nên đáp án phải là chỉ số dạng tỉ số.

  • C (net investment value) — ⚠ thuật ngữ bịa, ghép chữ từ NPV.

  • D (return on income) — ⚠ cũng là thuật ngữ bịa, đánh vào việc nhớ mang máng chữ "return on".

Ghi nhớ

⚠ Đối chiếu: ⚠ #26691 cùng lô (so sánh chi phí thuê và mua), ⚠ #26614 lô 197 (thời gian hoàn vốn), ⚠ #26607 lô 197 (giá trị tiền tệ kỳ vọng), ⚠ #26724 cùng lô (chọn yêu cầu theo trường hợp kinh doanh, không chỉ theo ROI), ⚠ #26723 cùng lô (cách dự án tạo ra giá trị).

⚠ CÁC CHỈ SỐ CHỌN DỰ ÁN — bảng phân biệt theo ĐƠN VỊ: | Chỉ số | Đơn vị | Nghĩa | Chọn khi | |---|---|---|---| | ⚠ ROI | ⚠ phần trăm | ⚠ lợi nhuận ÷ chi phí — ĐÁP ÁN | ⚠ CAO hơn thì tốt hơn | | ⚠ NPV | ⚠ tiền | ⚠ giá trị hiện tại của dòng tiền ròng | ⚠ DƯƠNG và cao hơn thì tốt hơn | | ⚠ IRR | ⚠ phần trăm | ⚠ tỉ suất làm NPV bằng 0 | ⚠ CAO hơn thì tốt hơn | | ⚠ BCR | ⚠ tỉ số | ⚠ lợi ích ÷ chi phí | ⚠ LỚN HƠN 1 là đáng làm | | ⚠ Thời gian hoàn vốn | ⚠ thời gian | ⚠ bao lâu thu hồi được vốn | ⚠ NGẮN hơn thì tốt hơn — liên hệ #26614 lô 197 | | ⚠ Bẫy hay gặp trong đề | ⚠ thời gian hoàn vốn là chỉ số duy nhất mà con số NHỎ hơn lại tốt hơn — đọc nhanh rất dễ chọn ngược |

⚠ Ưu và nhược của ROI: | Ưu | Nhược | |---|---| | ⚠ Dễ hiểu, dễ so sánh giữa các dự án khác quy mô | ⚠ KHÔNG tính tới giá trị thời gian của tiền | | ⚠ Nói được hiệu quả trên mỗi đồng vốn | ⚠ không cho biết quy mô tuyệt đối của lợi ích | | ⚠ Quen thuộc với lãnh đạo phi kỹ thuật | ⚠ dễ bị bóp méo bằng cách chọn khoảng thời gian có lợi | | ⚠ Ví dụ về nhược điểm quan trọng nhất | ⚠ một dự án ROI 200% trên vốn 10.000 đô sinh lời 20.000; một dự án ROI 30% trên vốn 2 triệu sinh lời 600.000 — ROI chọn cái thứ nhất, NPV chọn cái thứ hai, và với một tổ chức có vốn thì cái thứ hai thường mới là quyết định đúng |

⚠ Vì sao PMI muốn người quản lý dự án hiểu các chỉ số này: | Lý do | Nội dung | |---|---| | ⚠ Dự án được chọn dựa trên TRƯỜNG HỢP KINH DOANH | ⚠ liên hệ #26724 cùng lô | | ⚠ Bạn phải bảo vệ được dự án của mình khi ngân sách bị cắt | | | ⚠ Khi phạm vi thay đổi, lợi ích kỳ vọng cũng thay đổi | ⚠ và ai đó phải tính lại | | ⚠ Ngôn ngữ của nhà tài trợ là ngôn ngữ tài chính | | | ⚠ Ghi nhớ | ⚠ người quản lý dự án không cần là chuyên gia tài chính, nhưng phải đọc được trường hợp kinh doanh của chính dự án mình — vì đó là tài liệu quyết định dự án còn tồn tại hay không |

Từ khoá nhận diện:

"tỉ lệ lợi nhuận trên chi phí" → ⚠ ROI "giá trị hiện tại, chiết khấu dòng tiền" → ⚠ NPV, đơn vị TIỀN "bao lâu thu hồi vốn" → ⚠ thời gian hoàn vốn, nhỏ hơn là tốt hơn "net investment value", "return on income" → ⚠ thuật ngữ bịa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết ROI kỳ vọng của dự án mình không | | | Con số đó dựa trên giả định nào | | | Nếu dự án chậm sáu tháng, ROI còn lại bao nhiêu | ⚠ câu hỏi này thường chưa ai tính |

Và điều mà một tỉ lệ phần trăm gọn gàng dễ khiến người ta quên: nó chỉ đúng bằng chất lượng của con số lợi nhuận kỳ vọng nằm ở tử số — và đó thường là con số ít được kiểm chứng nhất trong toàn bộ trường hợp kinh doanh.

Câu 266 Process
Thelma is the project manager for Project Keystone, which recently completed a major milestone. This project has stakeholders eager for a deliverable to be put into production as soon as they are ready. They understand that there may be some limited functionality, but the sooner they can begin using the deliverables of the project, the sooner they will be able to recoup costs and capture opportunities. After inspecting the work, Thelma and the project sponsor have determined a deliverable is of quality and can be passed onto the business for use. What additional steps should Thelma take?
  1. A Do nothing. The deliverable is complete.
  2. B Closeout all tasks related to the deliverable.
  3. C Ensure there is appropriate documentation for the deliverables.
  4. D Perform quality control.
Xem giải thích

Đáp án

C — BẢO ĐẢM CÓ TÀI LIỆU PHÙ HỢP CHO CÁC SẢN PHẨM BÀN GIAO.

Vì sao đúng

⚠ Bối cảnh: bàn giao SỚM từng phần: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Bên liên quan muốn đưa sản phẩm vào dùng NGAY khi sẵn sàng | ⚠ giao theo gia số, thu hồi vốn sớm | | ⚠ Họ chấp nhận chức năng còn hạn chế | ⚠ đúng tinh thần sản phẩm khả dụng tối thiểu | | ⚠ Thelma và nhà tài trợ ĐÃ kiểm tra và ĐÃ chấp nhận chất lượng | ⚠ bước kiểm soát chất lượng và nghiệm thu đã xong | | ⚠ Sản phẩm sắp chuyển sang BỘ PHẬN NGHIỆP VỤ để dùng thật | ⚠ người dùng không phải người làm ra nó | | ⚠ Thứ còn thiếu | ⚠ TÀI LIỆU: hướng dẫn sử dụng, giới hạn chức năng hiện có, quy trình hỗ trợ và bảo trì |

⚠ Vì sao tài liệu là bước bắt buộc khi bàn giao sớm: ⚠ sản phẩm giao ở trạng thái chức năng hạn chế mà không nói rõ nó làm được gì và chưa làm được gì thì người dùng sẽ tự suy đoán ⚠ — ⚠ và mọi lời phàn nàn sau đó sẽ được hiểu là lỗi sản phẩm, chứ không phải là phạm vi đã thoả thuận.

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

  • B (đóng toàn bộ các công việc liên quan tới sản phẩm này) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đóng gọn từng phần khi hoàn thành nghe rất kỷ luật, và việc đóng giai đoạn đúng là có thật trong PMBOK: ⚠ nhưng ⚠ đây mới là MỘT sản phẩm trong một dự án đang chạy, và sản phẩm giao sớm với chức năng hạn chế thường CÒN CÔNG VIỆC PHÍA SAU — bổ sung tính năng, hỗ trợ người dùng, sửa lỗi phát sinh ⚠ — ⚠ đóng hết công việc lúc này là cắt mất phần chăm sóc đúng vào lúc sản phẩm bắt đầu tiếp xúc với người dùng thật.

  • D (thực hiện kiểm soát chất lượng) — ⚠ đề đã nói rõ Thelma và nhà tài trợ ĐÃ kiểm tra và kết luận đạt chất lượng; ⚠ làm lại là lặp bước đã xong.

  • A (không cần làm gì) — ⚠ bỏ qua toàn bộ nghĩa vụ bàn giao; ⚠ trong đề PMP, phương án "không làm gì" gần như luôn sai khi vẫn còn một bước hợp lý để làm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26686 cùng lô (xác nhận phạm vi — bước ngay trước), ⚠ #26689 cùng lô (lưu trữ khi đóng dự án), ⚠ #26711 cùng lô (sản phẩm khả dụng tối thiểu), ⚠ #26667 lô 198 (bảo đảm tài liệu tiếp cận được), ⚠ #26651 lô 198 (định nghĩa hoàn thành).

⚠ BÀN GIAO SỚM TỪNG PHẦN — cần gì đi kèm: | Việc | Nội dung | |---|---| | ⚠ Tài liệu hướng dẫn sử dụng | ⚠ ĐÁP ÁN — người dùng nghiệp vụ cần biết dùng thế nào | | ⚠ Nói rõ chức năng CÓ và chức năng CHƯA CÓ | ⚠ quản lý kỳ vọng ngay từ ngày đầu | | ⚠ Quy trình hỗ trợ: gặp ai khi có vấn đề | | | ⚠ Kế hoạch chuyển giao cho bộ phận vận hành | ⚠ ai bảo trì sau khi dự án kết thúc | | ⚠ Kênh thu nhận phản hồi từ người dùng thật | ⚠ đây là nguồn thông tin quý nhất cho các gia số sau | | ⚠ Ghi nhận việc bàn giao vào hồ sơ dự án | | | ⚠ Lợi ích kép của việc bàn giao sớm | ⚠ vừa thu hồi vốn sớm, vừa nhận được phản hồi thật sớm — nhưng cả hai lợi ích chỉ hiện thực hoá khi người dùng dùng được, và tài liệu chính là thứ quyết định điều đó |

⚠ Vì sao "chức năng hạn chế" làm cho tài liệu càng quan trọng hơn: | Rủi ro | Nội dung | |---|---| | ⚠ Người dùng thử một chức năng chưa có rồi kết luận sản phẩm hỏng | ⚠ niềm tin mất rất nhanh ở lần tiếp xúc đầu tiên | | ⚠ Bộ phận hỗ trợ nhận yêu cầu về những thứ chưa nằm trong phạm vi | ⚠ tốn nguồn lực vô ích | | ⚠ Cách làm tạm thời bị người dùng biến thành thói quen | ⚠ sau này rất khó gỡ | | ⚠ Không ai biết phiên bản nào đang chạy ở đâu | ⚠ liên hệ #26690 cùng lô — quản lý cấu hình | | ⚠ Cách phòng ngừa rẻ nhất | ⚠ một trang giấy nói rõ "phiên bản này làm được A, B; chưa làm được C, D; dự kiến có C vào tháng sau; gặp ai khi vướng" — nó ngăn được phần lớn các hiểu lầm ở trên |

⚠ Bàn giao sớm khác đóng dự án ở chỗ nào: | Tiêu chí | Bàn giao gia số | Đóng dự án | |---|---|---| | ⚠ Dự án | ⚠ vẫn đang chạy | ⚠ kết thúc | | ⚠ Công việc liên quan | ⚠ còn tiếp tục | ⚠ đóng hết | | ⚠ Đội | ⚠ vẫn làm việc | ⚠ giải phóng | | ⚠ Việc cần làm | ⚠ TÀI LIỆU và chuyển giao — ĐÁP ÁN | ⚠ lưu trữ, bài học, nghiệm thu cuối | | ⚠ Điểm dễ nhầm | ⚠ cả hai đều có chữ "bàn giao", nhưng một bên là trao một phần cho người dùng trong khi vẫn làm tiếp, còn một bên là khép lại toàn bộ — phương án B nhầm hai chuyện này với nhau |

Từ khoá nhận diện:

"giao sớm từng phần, chức năng hạn chế" → ⚠ BẢO ĐẢM CÓ TÀI LIỆU "đóng hết công việc liên quan" → ⚠ nhầm bàn giao gia số với đóng dự án "làm kiểm soát chất lượng" → ⚠ đã làm rồi theo đề "không cần làm gì" → ⚠ gần như luôn sai trong đề PMP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sản phẩm bạn vừa giao có tài liệu đi kèm không | | | Người dùng có biết chức năng nào CHƯA có không | | | Ai nhận phản hồi từ người dùng thật, và phản hồi đó đi về đâu | |

Và điều mà một trang tài liệu đi kèm bản giao sớm thật sự bảo vệ: không phải đội dự án khỏi lời phàn nàn, mà là chính sản phẩm khỏi bị đánh giá bằng những gì nó chưa bao giờ hứa sẽ làm được.

Câu 267 People
Angela is a scrum master for her organization and she is working with the development team and the product owner to plan out the amount of work the team can take into the next sprint. The development team believes it can complete, as in previous sprints, 30 user story points. You quickly review the past iterations and see that the team has indeed, on average, completed 30 user story points per iteration. What term describes the 30 user stories per iteration for this team?
  1. A Kanban completion
  2. B RAG Rating Green
  3. C Deliverables
  4. D Velocity
Xem giải thích

Đáp án

D — VẬN TỐC (velocity).

Vì sao đúng

⚠ Định nghĩa khớp từng chữ với đề: | Yếu tố trong đề | Ý nghĩa | |---|---| | ⚠ "30 điểm câu chuyện MỖI VÒNG LẶP" | ⚠ khối lượng công việc hoàn thành trên một đơn vị thời gian | | ⚠ "TRUNG BÌNH qua các vòng lặp đã qua" | ⚠ vận tốc là số trung bình, không phải số của một vòng | | ⚠ Dùng để dự báo vòng lặp tới nhận được bao nhiêu | ⚠ đúng công dụng của vận tốc | | ⚠ Kết luận | ⚠ vận tốc = số điểm HOÀN THÀNH trung bình mỗi vòng lặp |

⚠ Chữ "hoàn thành" là điều kiện quan trọng: ⚠ chỉ những hạng mục đạt ĐỊNH NGHĨA HOÀN THÀNH mới được tính vào vận tốc ⚠ — ⚠ làm xong 90% không được tính điểm nào, và chính quy tắc nghiêm khắc đó mới làm cho vận tốc có giá trị dự báo.

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

  • C (sản phẩm bàn giao — deliverables) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đội đúng là hoàn thành các hạng mục và các hạng mục đó đúng là sản phẩm bàn giao, nên câu trả lời nghe không sai: ⚠ nhưng ⚠ "sản phẩm bàn giao" là tên của THỨ được tạo ra, còn câu hỏi hỏi tên của CON SỐ 30 điểm mỗi vòng — đó là một THƯỚC ĐO TỐC ĐỘ ⚠ — ⚠ đọc kỹ: đề hỏi "thuật ngữ nào mô tả 30 điểm mỗi vòng lặp", tức là hỏi tên của tỉ lệ, không phải tên của kết quả.

  • A (Kanban completion) — ⚠ không phải thuật ngữ chuẩn; ⚠ Kanban dùng thông lượng (throughput) và thời gian chu kỳ, không dùng "completion".

  • B (RAG Rating Green) — ⚠ cách đánh giá tình trạng bằng màu đỏ/vàng/xanh; ⚠ định tính, không phải con số đo tốc độ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26699 cùng lô (dùng vận tốc để dự báo thời gian còn lại), ⚠ #26729 cùng lô (biểu đồ burndown), ⚠ #26714 cùng lô (bảng thông tin trực quan), ⚠ #26561 lô 196 (thông lượng và các thước đo agile), ⚠ #26720 cùng lô (xếp ưu tiên tồn đọng).

⚠ CÁC THƯỚC ĐO AGILE — đừng lẫn: | Thước đo | Đo gì | Khung nào | |---|---|---| | ⚠ VẬN TỐC (velocity) | ⚠ điểm hoàn thành mỗi vòng lặp — ĐÁP ÁN | ⚠ Scrum | | ⚠ THÔNG LƯỢNG (throughput) | ⚠ số hạng mục hoàn thành mỗi đơn vị thời gian | ⚠ Kanban | | ⚠ THỜI GIAN CHU KỲ (cycle time) | ⚠ từ lúc bắt đầu làm tới lúc xong một hạng mục | ⚠ Kanban | | ⚠ THỜI GIAN CHỜ (lead time) | ⚠ từ lúc yêu cầu xuất hiện tới lúc giao được | ⚠ Kanban | | ⚠ Burndown / burnup | ⚠ công việc còn lại / đã xong theo thời gian | ⚠ cả hai — liên hệ #26729 cùng lô | | ⚠ Điểm chung cần nhớ | ⚠ tất cả đều là thước đo của ĐỘI để đội tự điều chỉnh — không phải thước đo hiệu suất cá nhân, và dùng chúng để so sánh giữa các đội là cách nhanh nhất phá hỏng chúng |

⚠ Vận tốc dùng đúng và dùng sai: | Dùng ĐÚNG | Dùng SAI | |---|---| | ⚠ Dự báo thời gian còn lại | ⚠ so sánh đội này với đội khác | | ⚠ Quyết định nhận bao nhiêu việc cho vòng tới | ⚠ đặt chỉ tiêu vận tốc phải tăng | | ⚠ Nhận ra xu hướng giảm để tìm nguyên nhân | ⚠ đánh giá thành tích cá nhân | | ⚠ Trao đổi với bên liên quan về năng lực thật | ⚠ hứa với khách hàng như một cam kết cứng | | ⚠ Vì sao ép tăng vận tốc luôn thất bại | ⚠ điểm là đơn vị TƯƠNG ĐỐI do chính đội đặt ra — ép tăng thì đội chỉ cần ước lượng cao hơn, con số đẹp lên mà không có thêm giá trị nào được giao; đó gọi là lạm phát điểm |

⚠ Vì sao đề nói "đúng như các vòng trước, trung bình 30 điểm": | Ý nghĩa | Nội dung | |---|---| | ⚠ Vận tốc đã ỔN ĐỊNH | ⚠ dự báo dựa trên nó đáng tin | | ⚠ Đội tự đề xuất con số, không bị áp | ⚠ đúng tinh thần tự tổ chức | | ⚠ Angela chỉ kiểm chứng bằng dữ liệu quá khứ | ⚠ vai trò scrum master: đưa dữ liệu, không ra lệnh | | ⚠ Điều nên làm thêm | ⚠ hỏi vòng lặp này có gì khác thường không — nghỉ lễ, người vắng, việc kỹ thuật khó hơn; vận tốc trung bình là điểm khởi đầu của cuộc thảo luận, không phải kết luận của nó |

Từ khoá nhận diện:

"điểm hoàn thành trung bình mỗi vòng lặp" → ⚠ VẬN TỐC "số hạng mục hoàn thành mỗi tuần" → ⚠ thông lượng, thuộc Kanban "đỏ vàng xanh" → ⚠ RAG, đánh giá định tính "sản phẩm bàn giao" → ⚠ tên của kết quả, không phải tên của thước đo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vận tốc của đội bạn tính trên bao nhiêu vòng lặp | | | Có hạng mục nào làm gần xong được tính điểm không | ⚠ nếu có, vận tốc của bạn đang nói dối | | Có ai ngoài đội dùng vận tốc để đánh giá đội không | |

Và điều mà một con số vận tốc ổn định thật sự đem lại: không phải sự đảm bảo rằng đội sẽ nhanh, mà là khả năng nói với bên liên quan một điều trung thực về thời gian — thứ có giá trị hơn nhiều so với một lời hứa lạc quan.

Câu 268 Process
Given your extensive experience in your organization's project environment as a project manager, your expertise is called on to consult with developing a new change control board at an aerospace company. You know that projects in the organization have consistently been over budget, which has caused stress for management, stakeholders, and the project manager. You suspect that the initial project budgets have been set too low and that contingency reserves are lacking. You believe that a change control board is needed to review all change requests associated with projects that their project management office will be executing. What is the most appropriate selection of board members to include when reviewing who should be selected to be on the change control board?
  1. A Customers, project managers, project team members
  2. B Subject matter experts and management
  3. C The finance department and stakeholders
  4. D Senior project managers
Xem giải thích

Đáp án

A — KHÁCH HÀNG, CÁC QUẢN LÝ DỰ ÁN VÀ THÀNH VIÊN ĐỘI DỰ ÁN.

Vì sao đúng

⚠ Vì sao thành phần này là hợp lý nhất: | Thành phần | Đóng góp gì | |---|---| | ⚠ KHÁCH HÀNG | ⚠ biết thay đổi có còn phục vụ nhu cầu thật không, và ai trả tiền cho nó | | ⚠ QUẢN LÝ DỰ ÁN | ⚠ biết tác động lên phạm vi, tiến độ, chi phí, rủi ro | | ⚠ THÀNH VIÊN ĐỘI DỰ ÁN | ⚠ biết tác động KỸ THUẬT thật sự của thay đổi | | ⚠ Bao phủ đủ ba góc nhìn: giá trị, ràng buộc, khả thi | ⚠ đó là ba câu hỏi mà mọi yêu cầu thay đổi đều phải trả lời | | ⚠ Kết luận | ⚠ ban kiểm soát thay đổi cần ĐA DẠNG góc nhìn, không cần đồng nhất chức vụ |

⚠ Bối cảnh của đề còn ủng hộ đáp án này: ⚠ vấn đề của tổ chức là ngân sách ban đầu bị đặt QUÁ THẤP và thiếu quỹ dự phòng ⚠ — ⚠ chính khách hàng và đội kỹ thuật là hai nhóm nhìn ra sớm nhất rằng một yêu cầu thay đổi thật sự tốn bao nhiêu.

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

  • B (chuyên gia lĩnh vực và ban lãnh đạo) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chuyên gia và lãnh đạo đúng là hai nhóm rất hay có mặt trong ban kiểm soát thay đổi ngoài đời thật, và họ có thẩm quyền phê duyệt: ⚠ nhưng ⚠ nó THIẾU tiếng nói của KHÁCH HÀNG — người trả tiền và người dùng kết quả ⚠ — ⚠ một ban chỉ gồm chuyên gia và lãnh đạo dễ duyệt những thay đổi hợp lý về kỹ thuật nhưng không ai cần; ⚠ so ba phương án còn lại, chỉ phương án A có đủ cả bên nhận giá trị lẫn bên thực hiện.

  • C (phòng tài chính và bên liên quan) — ⚠ thiếu người hiểu tác động kỹ thuật và tác động lên tiến độ; ⚠ tài chính nhìn được chi phí nhưng không nhìn được tính khả thi.

  • D (chỉ các quản lý dự án cấp cao) — ⚠ quá đồng nhất; ⚠ mất góc nhìn khách hàng và góc nhìn kỹ thuật, dễ thành nơi ra quyết định theo kinh nghiệm chung chung.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bài trong bộ nguồn bị CẮT CỤT ở cuối ("What is the most appropriate selection of board members to include ") ⚠ — ⚠ câu đầy đủ hỏi nên chọn những ai vào ban kiểm soát thay đổi; ⚠ khoá đáp án được giữ nguyên vì bốn phương án đủ để phục dựng ý định của đề; ⚠ cũng lưu ý: thành phần ban kiểm soát thay đổi trong thực tế do TỔ CHỨC quy định và thay đổi theo từng nơi — câu này hỏi phương án ĐA DẠNG NHẤT về góc nhìn, chứ không hỏi một danh sách chuẩn duy nhất.

⚠ Đối chiếu: ⚠ #26634 lô 198 (đưa quy định mới ra ban kiểm soát thay đổi), ⚠ #26690 cùng lô (quản lý cấu hình và duyệt thay đổi), ⚠ #26705 cùng lô (thay đổi phạm vi khi đã ký hợp đồng), ⚠ #26724 cùng lô (chọn giữa hai yêu cầu xung đột), ⚠ #26687 cùng lô (phân loại bên liên quan).

⚠ BAN KIỂM SOÁT THAY ĐỔI — nguyên tắc lập: | Nguyên tắc | Nội dung | |---|---| | ⚠ Đủ THẨM QUYỀN để quyết | ⚠ ban không quyết được thì chỉ làm chậm mọi thứ | | ⚠ Đủ ĐA DẠNG góc nhìn | ⚠ nghiệp vụ, kỹ thuật, tài chính, khách hàng — ĐÁP ÁN | | ⚠ Đủ NHỎ để họp được thường xuyên | ⚠ ban hai mươi người sẽ không bao giờ đủ mặt | | ⚠ Có quy chế rõ: ngưỡng nào cần ban duyệt, ngưỡng nào không | ⚠ không phải mọi thay đổi đều phải lên ban | | ⚠ Có nhịp họp cố định và kênh xử lý khẩn | | | ⚠ Sai lầm phổ biến | ⚠ lập ban rồi không định ngưỡng — mọi thay đổi nhỏ đều phải chờ, đội mất tốc độ, và người ta bắt đầu tìm cách lách ban |

⚠ Ban kiểm soát thay đổi xét gì cho mỗi yêu cầu: | Câu hỏi | Ai trả lời được | |---|---| | ⚠ Thay đổi này phục vụ mục tiêu kinh doanh nào | ⚠ KHÁCH HÀNG | | ⚠ Nó tốn bao nhiêu tiền và bao nhiêu thời gian | ⚠ QUẢN LÝ DỰ ÁN | | ⚠ Có làm được về mặt kỹ thuật không, rủi ro gì | ⚠ ĐỘI DỰ ÁN | | ⚠ Tác động lên các đường cơ sở và lên các dự án khác | ⚠ quản lý dự án và văn phòng quản lý dự án | | ⚠ Vì sao ba nhóm trong đáp án A đủ | ⚠ chúng phủ đúng ba câu hỏi đầu — và ba câu hỏi đó quyết định phần lớn các yêu cầu thay đổi trong thực tế |

⚠ Vấn đề gốc của tổ chức trong đề — ban kiểm soát thay đổi có chữa được không: | Vấn đề | Ban có giúp không | |---|---| | ⚠ Ngân sách ban đầu đặt quá thấp | ⚠ KHÔNG — đó là vấn đề của khâu ước lượng | | ⚠ Thiếu quỹ dự phòng | ⚠ KHÔNG — đó là vấn đề của khâu lập kế hoạch rủi ro | | ⚠ Thay đổi được duyệt tuỳ tiện làm trôi ngân sách | ⚠ CÓ — đây là chỗ ban phát huy tác dụng | | ⚠ Lời khuyên cho vai trò tư vấn của bạn | ⚠ lập ban kiểm soát thay đổi là việc đúng, nhưng nếu nguyên nhân gốc là ước lượng thấp và thiếu dự phòng thì ban sẽ chỉ làm cho việc vượt ngân sách trở nên có hồ sơ hơn, chứ không làm nó biến mất — cần nói rõ điều này với tổ chức |

Từ khoá nhận diện:

"thành phần ban kiểm soát thay đổi" → ⚠ ĐA DẠNG góc nhìn: khách hàng + quản lý dự án + đội "chỉ lãnh đạo và chuyên gia" → ⚠ thiếu tiếng nói khách hàng "chỉ tài chính" → ⚠ thiếu góc nhìn kỹ thuật "chỉ quản lý dự án cấp cao" → ⚠ quá đồng nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ban kiểm soát thay đổi của bạn có ai đại diện người dùng không | | | Ngưỡng nào bạn được tự duyệt mà không cần lên ban | | | Ban họp bao lâu một lần, và một yêu cầu chờ trung bình mấy ngày | |

Và điều quyết định một ban kiểm soát thay đổi hữu ích hay chỉ là một tầng thủ tục: không phải chức vụ của những người ngồi trong đó, mà là việc mỗi câu hỏi quan trọng về một thay đổi đều có ít nhất một người trong phòng trả lời được.

Câu 269 Process
How does Margaret ensure that only a minimum viable product is produced within her team?
  1. A

    Her team always delays the correction of bugs until the next sprint.
  2. B She has an architect focused exclusively on simplification who approves the design of every item.
  3. C She involves the product owner to regularly narrow focus to the core items only, not the extra 60 percent of features that never get used.
  4. D She focuses only on the primary features that are used, which is typically 60% of what is built in every app.
Xem giải thích

Đáp án

C — CÔ ĐƯA CHỦ SẢN PHẨM VÀO CUỘC ĐỂ THƯỜNG XUYÊN THU HẸP TRỌNG TÂM VỀ CÁC HẠNG MỤC LÕI, thay vì 60% tính năng không bao giờ được dùng tới.

Vì sao đúng

⚠ Vì sao đây là cách giữ được sản phẩm khả dụng tối thiểu: | Lý do | Nội dung | |---|---| | ⚠ CHỦ SẢN PHẨM là người có quyền quyết định tồn đọng | ⚠ giữ MVP là quyết định về NỘI DUNG, không phải về kỹ thuật | | ⚠ "THƯỜNG XUYÊN thu hẹp" — việc lặp lại, không làm một lần | ⚠ phạm vi luôn có xu hướng phình ra | | ⚠ Tập trung vào hạng mục LÕI, thứ thật sự được dùng | ⚠ đó chính là định nghĩa của MVP | | ⚠ Loại bỏ tính năng ít dùng là quyết định có căn cứ | ⚠ dựa trên giá trị, không dựa trên sở thích | | ⚠ Kết luận | ⚠ MVP được giữ bằng một cuộc trò chuyện liên tục về giá trị, do đúng người phụ trách |

⚠ Con số "60% tính năng không dùng tới" nhắc tới khảo sát kinh điển của Standish Group ⚠ — ⚠ phần lớn tính năng trong phần mềm hiếm khi hoặc không bao giờ được sử dụng; ⚠ MVP tồn tại chính là để tránh xây trước cái phần đó.

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

  • D (cô chỉ tập trung vào các tính năng chính, thường là 60% những gì được xây trong mọi ứng dụng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó dùng lại đúng con số 60% và nghe gần như giống hệt đáp án nếu đọc lướt: ⚠ nhưng ⚠ nó ĐẢO NGƯỢC ý nghĩa của con số — 60% là phần KHÔNG được dùng, không phải phần chính ⚠ — ⚠ và nó mô tả Margaret tự quyết một mình, bỏ qua vai trò của chủ sản phẩm; ⚠ đây là dạng bẫy dùng lại số liệu của đáp án đúng nhưng gắn sai nghĩa, đọc kỹ từng chữ mới thấy.

  • B (một kiến trúc sư chuyên trách đơn giản hoá, duyệt thiết kế của MỌI hạng mục) — ⚠ tạo NÚT THẮT CỔ CHAI và một cấp phê duyệt tập trung; ⚠ trái với tinh thần đội tự tổ chức, và đơn giản hoá kỹ thuật không phải là thu hẹp phạm vi.

  • A (luôn hoãn sửa lỗi sang vòng lặp sau) — ⚠ tích luỹ nợ kỹ thuật; ⚠ hoàn toàn không liên quan tới MVP, và vi phạm định nghĩa hoàn thành.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26715 cùng lô (sơn cả bề mặt không ai nhìn thấy — giá trị thấp, công sức cao), ⚠ #26720 cùng lô (xếp ưu tiên tồn đọng), ⚠ #26708 cùng lô (bàn giao sớm với chức năng hạn chế), ⚠ #26704 cùng lô (hồi cứu hướng tới giá trị cho khách), ⚠ #26723 cùng lô (nhận diện nhu cầu thật).

⚠ SẢN PHẨM KHẢ DỤNG TỐI THIỂU (MVP) — hiểu cho đúng: | Điều đúng | Điều hiểu nhầm | |---|---| | ⚠ Phiên bản NHỎ NHẤT vẫn mang lại giá trị và học được từ người dùng | ⚠ "phiên bản làm cẩu thả cho nhanh" | | ⚠ Ít TÍNH NĂNG nhưng các tính năng đó phải HOÀN CHỈNH | ⚠ "mọi tính năng đều làm dở dang một nửa" | | ⚠ Mục đích: kiểm chứng giả định về nhu cầu | ⚠ "mục đích: giao hàng sớm cho xong" | | ⚠ Chất lượng KHÔNG được cắt | ⚠ "cắt kiểm thử để kịp" | | ⚠ Nguyên tắc cốt lõi | ⚠ cắt PHẠM VI, không cắt CHẤT LƯỢNG — liên hệ #26708 cùng lô, sản phẩm giao sớm vẫn phải đạt chuẩn chất lượng trước khi đưa vào dùng |

⚠ Vai trò của chủ sản phẩm trong việc giữ MVP: | Việc | Nội dung | |---|---| | ⚠ Sở hữu và sắp xếp thứ tự tồn đọng sản phẩm | ⚠ quyền quyết định thuộc về một người, không phải hội đồng | | ⚠ Nói KHÔNG với yêu cầu không đủ giá trị | ⚠ đây là phần khó nhất của vai trò | | ⚠ Trả lời câu hỏi "nếu bỏ cái này thì mất gì" | | | ⚠ Bảo vệ quyết định trước các bên liên quan | | | ⚠ Cập nhật ưu tiên khi có dữ liệu thật từ người dùng | ⚠ liên hệ #26717 cùng lô | | ⚠ Vì sao phải là chủ sản phẩm chứ không phải scrum master | ⚠ scrum master giữ QUY TRÌNH, chủ sản phẩm giữ GIÁ TRỊ — Margaret làm đúng khi kéo chủ sản phẩm vào thay vì tự quyết cắt gì |

⚠ Công cụ giúp thu hẹp về hạng mục lõi: | Công cụ | Cách dùng | |---|---| | ⚠ MoSCoW | ⚠ bắt buộc có / nên có / có thì tốt / lần này không — liên hệ #26720 cùng lô | | ⚠ Ma trận giá trị và công sức | ⚠ làm trước ô giá trị cao – công sức thấp — liên hệ #26715 cùng lô | | ⚠ Bản đồ hành trình câu chuyện người dùng | ⚠ vạch lát cắt mỏng nhất chạy được từ đầu tới cuối | | ⚠ Dữ liệu sử dụng thật từ bản đã phát hành | ⚠ bằng chứng mạnh nhất để bỏ một tính năng | | ⚠ Câu hỏi kiểm tra hữu ích nhất | ⚠ "nếu bỏ hạng mục này, có ai không dùng được sản phẩm không" — hạng mục nào trả lời KHÔNG thì nó chưa thuộc về MVP |

Từ khoá nhận diện:

"chủ sản phẩm thu hẹp về hạng mục lõi" → ⚠ cách giữ MVP đúng "60% tính năng không được dùng" → ⚠ đọc kỹ: là phần BỎ, không phải phần chính "một kiến trúc sư duyệt mọi thiết kế" → ⚠ nút thắt cổ chai, trái đội tự tổ chức "hoãn sửa lỗi sang vòng sau" → ⚠ nợ kỹ thuật, không liên quan MVP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng gần nhất bạn xây có bao nhiêu người dùng | ⚠ đo thật, đừng đoán | | Chủ sản phẩm của bạn đã nói KHÔNG lần gần nhất là khi nào | ⚠ chưa bao giờ nói không nghĩa là chưa xếp ưu tiên | | Có hạng mục nào trong tồn đọng nằm đó quá sáu tháng không | ⚠ nó nên bị xoá, không phải bị hoãn |

Và điều mà việc thu hẹp phạm vi thường xuyên thật sự bảo vệ: không phải ngân sách, mà là thời gian của đội — thứ duy nhất bạn không thể mua thêm, và thứ mà mỗi tính năng không ai dùng đều lấy đi một phần.

Câu 270 Process
Glenna has been informed by her management team that she must flatten her project through resource-leveling. If Glenna's team members can only contribute 28 hours per week, what is the likely outcome of her project schedule?
  1. A The critical path of the project will change.
  2. B The project schedule time will decrease.
  3. C The project schedule time will increase.
  4. D Glenna, as the project manager, will have to use the critical chain method.
Xem giải thích

Đáp án

C — THỜI GIAN CỦA TIẾN ĐỘ SẼ TĂNG LÊN.

Vì sao đúng

⚠ Vì sao san bằng nguồn lực kéo dài tiến độ: | Lý do | Nội dung | |---|---| | ⚠ San bằng nguồn lực (resource leveling) đặt GIỚI HẠN cứng về nguồn lực | ⚠ ở đây: 28 giờ mỗi tuần cho mỗi người | | ⚠ Công việc vượt giới hạn phải DỜI sang sau | ⚠ không thể làm song song như kế hoạch ban đầu | | ⚠ Ngày bắt đầu và ngày kết thúc của hoạt động bị đẩy ra | | | ⚠ Hệ quả gần như luôn xảy ra: TIẾN ĐỘ DÀI RA | ⚠ đây là đặc điểm định nghĩa của kỹ thuật này | | ⚠ Kết luận | ⚠ san bằng đổi THỜI GIAN lấy sự ỔN ĐỊNH của nhu cầu nguồn lực |

⚠ 28 giờ mỗi tuần là con số nói lên tất cả: ⚠ so với 40 giờ tiêu chuẩn, mỗi người chỉ còn 70% năng lực ⚠ — ⚠ cùng khối lượng công việc chia cho ít giờ hơn mỗi tuần thì bắt buộc phải kéo dài thêm tuần.

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

  • A (đường găng của dự án sẽ thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ san bằng nguồn lực THẬT SỰ có thể làm đường găng đổi, và nhiều tài liệu nhắc tới điều này như một hệ quả đặc trưng: ⚠ nhưng ⚠ đó là hệ quả CÓ THỂ xảy ra, còn việc tiến độ dài ra là hệ quả GẦN NHƯ CHẮC CHẮN ⚠ — ⚠ câu hỏi hỏi "kết quả CÓ KHẢ NĂNG NHẤT", nên phải chọn hệ quả chắc chắn hơn; ⚠ ghi nhớ: san bằng có thể đổi đường găng, nhưng luôn kéo dài hoặc giữ nguyên tổng thời gian, không bao giờ rút ngắn.

  • B (thời gian tiến độ sẽ GIẢM) — ⚠ ngược hoàn toàn; ⚠ muốn giảm thời gian thì phải dùng rút ngắn (crashing) hoặc chạy song song (fast-tracking).

  • D (Glenna sẽ phải dùng phương pháp chuỗi găng) — ⚠ chuỗi găng là một PHƯƠNG PHÁP KHÁC, đặt các bộ đệm thời gian quanh ràng buộc nguồn lực; ⚠ nó là một lựa chọn có thể cân nhắc, không phải hệ quả bắt buộc của việc san bằng.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26563 lô 196 (fast-tracking và crashing — hai cách rút ngắn), ⚠ #26701 cùng lô (quan hệ logic giữa các hoạt động), ⚠ #26685 cùng lô (nguồn lực dùng chung), ⚠ #26653 lô 198 (mức sẵn có của nguồn lực), ⚠ #26674 lô 198 (nhịp độ bền vững).

⚠ SAN BẰNG và LÀM MƯỢT — hai kỹ thuật tối ưu nguồn lực: | Tiêu chí | SAN BẰNG (leveling) | LÀM MƯỢT (smoothing) | |---|---|---| | ⚠ Ràng buộc | ⚠ giới hạn nguồn lực là CỨNG | ⚠ ngày kết thúc là CỨNG | | ⚠ Được phép đổi | ⚠ NGÀY KẾT THÚC — tiến độ dài ra | ⚠ chỉ dùng thời gian dự trữ (float) | | ⚠ Ảnh hưởng đường găng | ⚠ CÓ THỂ đổi | ⚠ KHÔNG đổi | | ⚠ Dùng khi | ⚠ nguồn lực có hạn cứng — CA NÀY | ⚠ muốn dàn đều mà không trễ hạn | | ⚠ Cách nhớ | ⚠ hỏi "cái gì KHÔNG được phép đổi": nguồn lực → san bằng; ngày kết thúc → làm mượt | |

⚠ Bốn kỹ thuật động tới tiến độ — bảng tổng hợp: | Kỹ thuật | Tác dụng lên thời gian | Cái giá | |---|---|---| | ⚠ SAN BẰNG NGUỒN LỰC | ⚠ DÀI RA — ĐÁP ÁN | ⚠ trễ hạn, nhưng nhu cầu nguồn lực khả thi | | ⚠ LÀM MƯỢT NGUỒN LỰC | ⚠ giữ nguyên | ⚠ ăn hết thời gian dự trữ, dự án mong manh hơn | | ⚠ RÚT NGẮN (crashing) | ⚠ NGẮN LẠI | ⚠ TỐN THÊM TIỀN — thêm người, làm thêm giờ | | ⚠ CHẠY SONG SONG (fast-tracking) | ⚠ NGẮN LẠI | ⚠ TĂNG RỦI RO và khả năng phải làm lại | | ⚠ Nghịch lý mà Glenna phải nói với ban lãnh đạo | ⚠ họ yêu cầu "làm phẳng" tiến độ, nhưng cái giá của việc làm phẳng chính là thời gian — và tốt nhất là nói rõ con số đó trước khi làm, chứ không phải khi đã trễ |

⚠ Glenna nên trình bày với ban lãnh đạo thế nào: | Việc | Nội dung | |---|---| | ⚠ Đưa con số cụ thể | ⚠ "với 28 giờ/tuần, dự án dài thêm X tuần" | | ⚠ Nêu các phương án đánh đổi | ⚠ chấp nhận trễ, thêm người, hay cắt phạm vi | | ⚠ Chỉ ra hoạt động nào bị ảnh hưởng nặng nhất | ⚠ thường là các hoạt động cần nhiều người cùng lúc | | ⚠ Cập nhật đường cơ sở sau khi có quyết định | ⚠ thay đổi phải qua kiểm soát thay đổi — liên hệ #26710 cùng lô | | ⚠ Điều KHÔNG nên làm | ⚠ im lặng san bằng rồi hy vọng bù lại được về sau — tiến độ trễ được phát hiện muộn luôn đắt hơn tiến độ trễ được báo trước |

Từ khoá nhận diện:

"giới hạn số giờ mỗi tuần, san bằng nguồn lực" → ⚠ TIẾN ĐỘ DÀI RA "đường găng có thể đổi" → ⚠ có thể, nhưng không chắc chắn bằng "làm mượt nguồn lực" → ⚠ không đổi ngày kết thúc, chỉ dùng dự trữ "rút ngắn / chạy song song" → ⚠ hai cách duy nhất làm tiến độ NGẮN lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiến độ của bạn giả định mỗi người làm bao nhiêu giờ mỗi tuần | ⚠ nếu là 40, nó đang lạc quan | | Có ai trong kế hoạch bị phân hơn 100% năng lực không | | | Khi phải san bằng, bạn báo lại ngày kết thúc mới bằng cách nào | |

Và điều mà một yêu cầu nghe rất vô hại như "hãy làm phẳng tiến độ" thật sự chứa đựng: một quyết định về ngày kết thúc mà người yêu cầu thường chưa nhận ra mình vừa đưa ra — việc của Glenna là biến nó thành một con số trước khi nó thành một bất ngờ.