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

Tìm thấy 720 câu.

Câu 331 Process
The way that Christine’s team completes frequent releases of their product without introducing many new bugs is most likely
  1. A Using continuous integration, which includes automated testing as part of the software building process, to ensure basic functionality still works properly.
  2. B With a full regression test done by the delivery team
  3. C Due to paired programming
  4. D Using a few manual testers focused on just core functionality for each release.
Xem giải thích

Đáp án

A — Nhờ TÍCH HỢP LIÊN TỤC, trong đó có KIỂM THỬ TỰ ĐỘNG là một phần của quá trình build, để bảo đảm chức năng cơ bản vẫn chạy đúng.

Vì sao đúng

⚠ Vì sao CI cho phép phát hành thường xuyên mà ít lỗi: | Lý do | Nội dung | |---|---| | ⚠ Mỗi lần đưa mã lên đều BUILD và CHẠY KIỂM THỬ TỰ ĐỘNG | | | ⚠ Lỗi hồi quy bị bắt trong VÀI PHÚT, không phải vài tuần | ⚠ đó chính là điều giữ cho lỗi mới không lọt ra | | ⚠ Mã luôn ở trạng thái phát hành được | | | ⚠ Kiểm thử chạy ĐỀU ĐẶN, không phụ thuộc vào việc ai nhớ chạy | | | ⚠ Chìa khoá | ⚠ TỰ ĐỘNG — con người không thể kiểm thử thủ công đủ nhanh cho nhịp phát hành thường xuyên |

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

  • B (kiểm thử hồi quy đầy đủ do đội bàn giao thực hiện) — ⚠ phương án gây nhiễu mạnh nhất vì kiểm thử hồi quy đúng là thứ ngăn lỗi mới: ⚠ nhưng ⚠ kiểm thử hồi quy ĐẦY ĐỦ làm THỦ CÔNG thì quá chậm ⚠ để phát hành thường xuyên; ⚠ đó chính là nút thắt mà CI sinh ra để phá bỏ.

  • D (vài người kiểm thử thủ công chỉ tập trung vào chức năng cốt lõi) — ⚠ phủ quá hẹp và không lặp lại được; ⚠ lỗi ngoài phần cốt lõi sẽ lọt.

  • C (nhờ lập trình cặp) — ⚠ cải thiện chất lượng mã, ⚠ nhưng ⚠ không tự động bắt được lỗi hồi quy ⚠ khi phát hành.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG: ⚠ câu #25986 ở lô 185 ⚠ (đội mới dùng tích hợp liên tục → tác động là tốn thêm thời gian dựng kiểm thử tự động). ⚠ Hai câu cùng chủ đề CI, khoá NHẤT QUÁN và BỔ SUNG nhau: ⚠ #25986 nói CHI PHÍ phải bỏ ra, câu này nói LỢI ÍCH thu được. ⚠ Xem thêm câu #26042 ở lô này (TDD), câu #26000 lô 185 (kiểm thử thăm dò), và câu #25953 lô 184 (kiểm thử trong Định nghĩa Hoàn thành).

⚠ Kim tự tháp kiểm thử — vì sao tự động hoá phải theo tầng: | Tầng | Số lượng | Tốc độ | |---|---|---| | ⚠ KIỂM THỬ ĐƠN VỊ | ⚠ NHIỀU NHẤT | ⚠ nhanh nhất, mili giây — liên hệ #26042 | | ⚠ KIỂM THỬ TÍCH HỢP | ⚠ ít hơn | ⚠ chậm hơn | | ⚠ KIỂM THỬ ĐẦU-CUỐI | ⚠ ÍT NHẤT | ⚠ chậm nhất, dễ chập chờn | | ⚠ KIỂM THỬ THĂM DÒ thủ công | ⚠ theo phiên có mục tiêu | ⚠ bổ sung, không thay thế — liên hệ #26000 | | ⚠ Kim tự tháp ngược | ⚠ nhiều kiểm thử đầu-cuối, ít kiểm thử đơn vị — build chậm, hay hỏng vặt, đội mất niềm tin |

Từ khoá nhận diện:

"phát hành thường xuyên mà ít lỗi mới" → ⚠ CI với kiểm thử tự động "kiểm thử hồi quy đầy đủ thủ công" → ⚠ quá chậm cho nhịp phát hành thường xuyên "vài người kiểm thủ công phần cốt lõi" → ⚠ phủ quá hẹp "lập trình cặp" → ⚠ cải thiện chất lượng lúc VIẾT, không bắt lỗi lúc PHÁT HÀNH

⚠ Chuỗi thực hành hỗ trợ nhau Thực hành
⚠ TDD tạo ra bộ kiểm thử đơn vị ⚠ nguyên liệu cho CI — liên hệ #26042
⚠ CI chạy bộ kiểm thử đó mỗi lần build ⚠ CÂU NÀY
⚠ Giao hàng liên tục biến build xanh thành bản phát hành được
⚠ Kiểm thử thăm dò tìm thứ tự động không thấy ⚠ liên hệ #26000 lô 185
⚠ Kết quả tổng hợp ⚠ phát hành thường xuyên VÀ an toàn — không phải chọn một trong hai
⚠ Vì sao "phát hành thường xuyên" lại AN TOÀN HƠN phát hành hiếm Nghịch lý
⚠ Mỗi lần phát hành chứa ÍT thay đổi hơn ⚠ có sự cố thì dễ tìm nguyên nhân
⚠ Quay lui dễ hơn nhiều
⚠ Đội làm việc phát hành thường xuyên nên thành thạo ⚠ phát hành hiếm thì mỗi lần đều là sự kiện căng thẳng
⚠ Phản hồi từ người dùng tới sớm ⚠ liên hệ #25984 lô 185 — bàn giao tăng dần
⚠ Điều kiện ⚠ chỉ đúng KHI có lưới kiểm thử tự động — không có nó thì phát hành thường xuyên là phát tán lỗi thường xuyên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ kiểm thử của bạn chạy mất bao lâu | ⚠ quá 10 phút là đội bắt đầu bỏ qua | | Bạn phát hành bao lâu một lần | | | Lỗi hồi quy gần nhất được phát hiện bởi ai | ⚠ máy hay khách hàng |

Và điều đội của Christine đã đầu tư mà người ngoài không nhìn thấy: khả năng phát hành thường xuyên không đến từ việc họ viết mã cẩn thận hơn, mà từ việc họ đã bỏ công xây một cỗ máy kiểm tra hộ mình mỗi ngày.

Câu 332 Business Environment
Eddie is working on an internet marketing company's latest campaign. His clients are trying to grow organic traffic to their site, but this growth is secondary to their primary goal to get users to subscribe to a premium account. Eddie recognizes this and suggests that one measure of his company's success might be the ratio of premium accounts to its services' cost. How is the project manager delivering project value?
  1. A Constructing key performance indicators
  2. B Identifying needs
  3. C Formalizing objectives
  4. D Mapping stakeholders
Xem giải thích

Đáp án

A — XÂY DỰNG CHỈ SỐ HIỆU SUẤT CHÍNH (key performance indicators, KPI).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Eddie đề xuất một THƯỚC ĐO cụ thể | ⚠ tỷ lệ tài khoản trả phí trên chi phí dịch vụ | | ⚠ Thước đo đó gắn với MỤC TIÊU CHÍNH của khách hàng | ⚠ tăng tài khoản trả phí, không phải tăng lưu lượng | | ⚠ Đo được, tính được, theo dõi được theo thời gian | ⚠ đúng đặc tính của một KPI | | ⚠ Anh phân biệt được mục tiêu CHÍNH và mục tiêu PHỤ | ⚠ lưu lượng tự nhiên chỉ là thứ yếu | | ⚠ Giá trị mang lại | ⚠ định nghĩa THÀNH CÔNG bằng con số, thay vì bằng cảm nhận |

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

  • C (chính thức hoá mục tiêu) — ⚠ phương án gây nhiễu mạnh nhất vì Eddie đúng là đang làm rõ mục tiêu: ⚠ nhưng ⚠ chính thức hoá mục tiêu là VIẾT RA ĐÍCH ĐẾN ⚠ ("tăng 20% tài khoản trả phí trong sáu tháng"), ⚠ còn Eddie đang đề xuất CÁCH ĐO ⚠ — đó là KPI, một bước sau.

  • B (nhận diện nhu cầu) — ⚠ nhu cầu đã được nhận diện rồi: ⚠ đề nói rõ khách hàng muốn tăng tài khoản trả phí.

  • D (lập bản đồ bên liên quan) — ⚠ phân loại bên liên quan theo quyền lực và quan tâm; ⚠ không liên quan tới việc đo giá trị.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26034 ở lô này (bàn giao xong vẫn cần bảo đảm sản phẩm được dùng), câu #26029 lô 185 (giao giá trị nhanh và phải đo được), câu #25912 lô 183 (PO cần biết lợi nhuận kỳ vọng của cả dự án), và câu #25920 (đường cong chi phí). ⚠ Nhóm giá trị kinh doanh.

⚠ Chuỗi từ NHU CẦU tới ĐO LƯỜNG: | Bước | Nội dung | |---|---| | ⚠ NHẬN DIỆN NHU CẦU | ⚠ khách hàng muốn nhiều tài khoản trả phí hơn | | ⚠ CHÍNH THỨC HOÁ MỤC TIÊU | ⚠ "tăng 20% tài khoản trả phí trong sáu tháng" | | ⚠ XÂY DỰNG KPI | ⚠ tỷ lệ tài khoản trả phí trên chi phí — CÂU NÀY | | ⚠ ĐO và BÁO CÁO | | | ⚠ ĐIỀU CHỈNH dựa trên số liệu | | | ⚠ Bỏ bước KPI | ⚠ thì có mục tiêu mà không biết mình đã tới chưa |

⚠ Một KPI tốt có đặc điểm gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Gắn trực tiếp với MỤC TIÊU KINH DOANH | ⚠ không đo thứ dễ đo mà đo thứ quan trọng | | ⚠ ĐO ĐƯỢC bằng dữ liệu có sẵn | | | ⚠ Có NGƯỠNG rõ ràng để biết tốt hay xấu | ⚠ liên hệ #25983 lô 185 — ngưỡng | | ⚠ Người đọc HIỂU ĐƯỢC và tin được | | | ⚠ Không dễ bị "làm đẹp" bằng cách gian lận | | | ⚠ Số lượng | ⚠ ÍT thôi — mười KPI thì không cái nào là "chính" nữa |

Từ khoá nhận diện:

"đề xuất một thước đo thành công" → ⚠ xây dựng KPI "viết ra đích đến cụ thể" → ⚠ chính thức hoá mục tiêu "tìm hiểu khách hàng cần gì" → ⚠ nhận diện nhu cầu "ai là bên liên quan, quyền lực ra sao" → ⚠ lập bản đồ bên liên quan

⚠ Điều Eddie làm đúng nhất Điểm tốt
⚠ Phân biệt mục tiêu CHÍNH và mục tiêu PHỤ ⚠ lưu lượng tự nhiên chỉ có ý nghĩa nếu chuyển thành tài khoản trả phí
⚠ Đo TỶ LỆ chứ không đo con số tuyệt đối ⚠ tỷ lệ trên chi phí cho biết HIỆU QUẢ, không chỉ quy mô
⚠ Gắn thước đo với thứ khách hàng THẬT SỰ quan tâm
⚠ Vì sao đo lưu lượng là bẫy ⚠ lưu lượng tăng mà không ai đăng ký trả phí thì chiến dịch đã thất bại, dù biểu đồ rất đẹp
⚠ Chỉ số PHÙ PHIẾM và chỉ số THẬT Phân biệt
⚠ PHÙ PHIẾM: lượt xem trang, số người theo dõi, lưu lượng ⚠ luôn tăng, khó giảm, không gắn với doanh thu
⚠ THẬT: tỷ lệ chuyển đổi, doanh thu trên khách hàng, chi phí thu hút khách ⚠ gắn trực tiếp với kết quả kinh doanh
⚠ Cách kiểm tra ⚠ "nếu chỉ số này tăng gấp đôi, có thay đổi quyết định gì không?" — không thì đó là chỉ số phù phiếm
⚠ Ở tình huống này ⚠ lưu lượng tự nhiên là chỉ số dễ trở thành phù phiếm; tỷ lệ trả phí trên chi phí thì không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có KPI nào không | ⚠ hay chỉ đo tiến độ và chi phí | | KPI đó có gắn với mục tiêu kinh doanh không | | | Nếu KPI tốt lên, có ai ra quyết định khác đi không | ⚠ không thì nó chỉ để trưng bày |

Và điều làm nên khác biệt giữa một dự án hoàn thành và một dự án thành công: cái thứ nhất đo bằng phạm vi, thời gian, chi phí; cái thứ hai đo bằng một con số mà khách hàng thật sự quan tâm — và ai đó phải chủ động đề xuất con số ấy.

Câu 333 Process
Jessica has been managing many projects for her organization and is exemplary in her execution. She relentlessly stresses the importance of collecting and documenting lessons learned throughout the project lifecycle to ensure continuous learning and improvement and contribute to the organization's knowledge management system. Her colleague, Adam, finds that his weekly meetings are all spent tackling complex feature development issues, and there is little attention or time spent on lessons learned. Adam seeks advice from Jessica to ensure lessons learned gathering does not get missed in such a situation. What is the most appropriate recommendation?
  1. A Avoid issues during meetings as they will go away with time.
  2. B Record the minutes of the meeting.
  3. C Discontinue updating meetings but schedule meetings with individual team members.
  4. D Add a lessons-learned agenda item.
Xem giải thích

Đáp án

D — THÊM MỘT MỤC "BÀI HỌC KINH NGHIỆM" VÀO CHƯƠNG TRÌNH HỌP.

Vì sao đúng

⚠ Vì sao giải pháp đơn giản này hiệu quả: | Lý do | Nội dung | |---|---| | ⚠ Việc gì có trong chương trình họp thì được làm | ⚠ việc gì không có thì bị bỏ, dù ai cũng biết là quan trọng | | ⚠ Không cần thêm buổi họp mới | ⚠ tận dụng nhịp đã có | | ⚠ Thu bài học LIÊN TỤC, không dồn tới cuối dự án | ⚠ đúng điều Jessica vẫn nhấn mạnh | | ⚠ Chi phí gần như bằng không | ⚠ năm tới mười phút mỗi tuần | | ⚠ Vấn đề của Adam | ⚠ không phải thiếu ý thức, mà là thiếu CƠ CHẾ — và cơ chế đơn giản nhất là một dòng trong chương trình họp |

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

  • B (ghi biên bản cuộc họp) — ⚠ phương án gây nhiễu mạnh nhất vì biên bản đúng là có ghi lại nội dung: ⚠ nhưng ⚠ biên bản ghi VẤN ĐỀ và QUYẾT ĐỊNH, không ghi BÀI HỌC; ⚠ hai thứ khác nhau — bài học là ⚠ điều RÚT RA để lần sau làm khác đi, ⚠ và nó chỉ xuất hiện khi có người hỏi thẳng.

  • C (bỏ họp cập nhật, chuyển sang gặp riêng từng thành viên) — ⚠ thay đổi lớn không cần thiết, ⚠ và mất luôn không gian thảo luận chung.

  • A (né các vấn đề trong buổi họp vì rồi chúng sẽ tự hết) — ⚠ sai hoàn toàn; ⚠ vấn đề không tự biến mất.

Ghi nhớ

⚠ Đối chiếu — bài học kinh nghiệm đã lên BẢY câu qua bốn lô: ⚠ #25757/#25761 lô 180, ⚠ #25896, #25911 lô 183, ⚠ #25964 lô 184, ⚠ #25999, #26006 lô 185, ⚠ và câu này. ⚠ Câu #26006 hỏi VÌ SAO phải viết bài học; câu này hỏi LÀM THẾ NÀO để không bỏ sót — hai câu bổ sung nhau trực tiếp.

⚠ Vì sao bài học hay bị bỏ quên: | Nguyên nhân | Nội dung | |---|---| | ⚠ Không có chỗ cố định trong nhịp làm việc | ⚠ đúng vấn đề của Adam, và giải pháp của câu này | | ⚠ Việc gấp luôn lấn át việc quan trọng | | | ⚠ Không ai chịu trách nhiệm cụ thể | | | ⚠ Dồn tới cuối dự án thì đã quên hết chi tiết | | | ⚠ Ghi rồi không ai đọc nên đội mất động lực | ⚠ liên hệ #26006 lô 185 | | ⚠ Cách chữa gốc | ⚠ biến nó thành THÓI QUEN có nhịp, không phải một sự kiện cuối dự án |

Từ khoá nhận diện:

"bài học bị bỏ quên trong họp" → ⚠ thêm mục vào chương trình họp "ghi biên bản" → ⚠ ghi vấn đề và quyết định, không phải bài học "bỏ họp chung, gặp riêng" → ⚠ thay đổi lớn không cần thiết "vấn đề sẽ tự hết" → ⚠ luôn sai

⚠ Hỏi gì trong mục bài học năm phút mỗi tuần Câu hỏi
⚠ "Tuần này có gì làm khác đi thì tốt hơn không?"
⚠ "Có gì hiệu quả bất ngờ mà nên lặp lại không?" ⚠ đừng chỉ hỏi cái sai
⚠ "Có giả định nào hoá ra không đúng không?"
⚠ "Nếu bắt đầu lại tuần này, ta sẽ làm gì khác?"
⚠ Ai ghi ⚠ luân phiên, để không ai thấy đó là việc của riêng mình
⚠ Ghi vào đâu ⚠ SỔ ĐĂNG KÝ BÀI HỌC — tài liệu sống, cập nhật liên tục, không phải báo cáo cuối dự án
⚠ Phân biệt ba tài liệu hay lẫn Tài liệu
⚠ BIÊN BẢN HỌP ⚠ ai nói gì, quyết định gì, ai làm gì tiếp
⚠ NHẬT KÝ VẤN ĐỀ ⚠ vấn đề đang mở, người phụ trách, hạn xử lý
⚠ SỔ ĐĂNG KÝ BÀI HỌC ⚠ điều rút ra để LẦN SAU làm khác — CÂU NÀY
⚠ Điểm khác biệt cốt lõi ⚠ hai tài liệu đầu phục vụ DỰ ÁN NÀY; sổ bài học phục vụ DỰ ÁN SAU
⚠ Trong agile thì việc này nằm ở đâu Nơi
⚠ RETROSPECTIVE cuối mỗi sprint ⚠ chính là cơ chế thu bài học có nhịp
⚠ Đó là lý do agile ít gặp vấn đề của Adam ⚠ việc rút bài học đã được đóng khung thành một sự kiện bắt buộc
⚠ Bài học cho dự án dự đoán ⚠ mượn ý tưởng đó — đặt một nhịp cố định thay vì trông chờ vào ý thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chương trình họp tuần của bạn có mục bài học không | | | Sổ bài học của dự án cập nhật lần cuối khi nào | | | Có bài học nào đã dẫn tới thay đổi cách làm chưa | ⚠ liên hệ #26006 lô 185 |

Và điều lời khuyên của Jessica dạy về mọi việc quan trọng nhưng không khẩn cấp: cách duy nhất để nó không bị bỏ quên là cho nó một chỗ cố định trong lịch, chứ không phải nhắc nhau rằng nó quan trọng.

Câu 334 People
Martina is the project manager of a large software deployment project for French Logistics, a project which will replace all employees' computer operating systems. The majority of employees are in favor of this change, but there are some who are not. Part of Martina's plan, which she accomplished, was to complete a stakeholder analysis. Through the analysis, Martina and her team learned that some of the stakeholders were not aware of the change in the company's approved computer operating system. How should these stakeholders be classified?
  1. A Unaware
  2. B Uninformed
  3. C Lacking
  4. D Target for positive
Xem giải thích

Đáp án

A — KHÔNG BIẾT (unaware).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Một số bên liên quan CHƯA BIẾT có việc đổi hệ điều hành | ⚠ họ chưa nhận thức được về dự án hoặc tác động của nó | | ⚠ Đó chính xác là định nghĩa mức KHÔNG BIẾT | | | ⚠ Phát hiện qua PHÂN TÍCH BÊN LIÊN QUAN | ⚠ đúng mục đích của việc phân tích | | ⚠ Định nghĩa chuẩn | ⚠ "unaware" — chưa nhận thức được về dự án, tác động tiềm tàng của nó, hoặc cả hai | | ⚠ Vì sao quan trọng | ⚠ người không biết thì không thể ủng hộ, và khi biết muộn thường trở thành người phản đối |

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

  • B (chưa được thông tin — uninformed) — ⚠ phương án gây nhiễu mạnh nhất vì nghĩa tiếng Việt gần như giống hệt: ⚠ nhưng ⚠ "uninformed" KHÔNG phải thuật ngữ chuẩn ⚠ trong ma trận đánh giá mức gắn kết bên liên quan; ⚠ thuật ngữ chính xác là ⚠ UNAWARE.

  • C (thiếu — lacking) và D (mục tiêu để chuyển thành tích cực) — ⚠ KHÔNG phải thuật ngữ chuẩn; ⚠ hai phương án bịa.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25961 ở lô 184 (Ethel chưa gắn kết bên liên quan đầy đủ) — ⚠ câu đó đã liệt kê ĐỦ NĂM MỨC gắn kết, và câu này hỏi trực tiếp về mức đầu tiên. ⚠ Xem thêm câu #26046 ở lô này (bỏ sót bên liên quan), câu #26044 (đầu vào của quản lý gắn kết), và câu #25949 lô 184 (ma trận quyền lực – quan tâm).

⚠ NĂM MỨC GẮN KẾT bên liên quan: | Mức | Nội dung | |---|---| | ⚠ KHÔNG BIẾT (unaware) | ⚠ chưa biết dự án tồn tại hoặc tác động của nó — CÂU NÀY | | ⚠ CHỐNG ĐỐI (resistant) | ⚠ biết và phản đối thay đổi | | ⚠ TRUNG LẬP (neutral) | ⚠ biết nhưng không ủng hộ cũng không phản đối | | ⚠ ỦNG HỘ (supportive) | ⚠ biết và ủng hộ | | ⚠ DẪN DẮT (leading) | ⚠ chủ động tham gia bảo đảm dự án thành công | | ⚠ Công cụ | ⚠ ma trận đánh giá mức gắn kết — ghi mức HIỆN TẠI (C) và mức MONG MUỐN (D) cho từng bên | | ⚠ Mục đích | ⚠ thấy KHOẢNG CÁCH để lập chiến lược thu hẹp |

Từ khoá nhận diện:

"chưa biết có dự án hoặc thay đổi" → ⚠ KHÔNG BIẾT (unaware) "biết và phản đối" → ⚠ chống đối "biết nhưng không quan tâm" → ⚠ trung lập "chủ động thúc đẩy dự án" → ⚠ dẫn dắt ⚠ Phương án nghe hợp lý nhưng không phải thuật ngữ chuẩn → ⚠ thường là phương án bịa

⚠ Xử lý bên liên quan ở mức KHÔNG BIẾT thế nào Cách
⚠ THÔNG BÁO là việc đầu tiên và cấp thiết ⚠ họ không thể có ý kiến về thứ họ chưa biết
⚠ Giải thích VÌ SAO có thay đổi, không chỉ nói CÁI GÌ đổi ⚠ liên hệ #26034 cùng lô — quản trị thay đổi tổ chức
⚠ Nêu rõ thay đổi ảnh hưởng tới CÔNG VIỆC CỦA HỌ ra sao
⚠ Cho họ kênh để đặt câu hỏi và nêu lo ngại
⚠ Đo lại mức gắn kết sau khi thông báo ⚠ họ có thể chuyển sang ủng hộ, cũng có thể chuyển sang chống đối
⚠ Rủi ro nếu để lâu ⚠ biết muộn gần như luôn sinh ra chống đối — người ta phản ứng với việc BỊ BỎ QUA nhiều hơn với chính thay đổi
⚠ Bối cảnh cụ thể: đổi hệ điều hành toàn công ty Lưu ý
⚠ Ảnh hưởng tới MỌI nhân viên ⚠ nên danh sách bên liên quan rất rộng
⚠ Phần lớn ủng hộ, một số không ⚠ Martina đã nắm được điều này qua phân tích
⚠ Người chưa biết là nhóm RỦI RO NHẤT ⚠ họ sẽ phát hiện vào ngày máy tính của họ bị đổi
⚠ Việc cần làm ngay ⚠ truyền thông rộng, kèm lịch trình cụ thể và kênh hỗ trợ
⚠ Liên hệ ⚠ #26034 — thay đổi công nghệ chỉ tạo ra lợi ích khi người ta chấp nhận nó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ma trận mức gắn kết không | ⚠ hay chỉ có danh sách tên và số điện thoại | | Có ai bị ảnh hưởng mà chưa được thông báo không | | | Mức gắn kết được rà lại bao lâu một lần | ⚠ nó thay đổi theo giai đoạn dự án |

Và lý do mức "không biết" luôn đứng đầu bảng: mọi mức khác đều là một dạng phản ứng có thông tin. Người không biết gì thì không phản ứng gì cả — cho tới lúc quá muộn để làm gì khác ngoài phản đối.

Câu 335 People
Vera is the project manager for the Sharpie Project. She had 19 stakeholders and has added 3 project team members. Compared to before, how many more communication channels does Vera now have?
  1. A 60
  2. B 231
  3. C 171
  4. D 1
Xem giải thích

Đáp án

A — 60 KÊNH.

Vì sao đúng

⚠ Công thức và phép tính: | Bước | Phép tính | |---|---| | ⚠ Công thức số kênh giao tiếp | ⚠ n × (n − 1) ÷ 2 | | ⚠ TRƯỚC: 19 người | ⚠ 19 × 18 ÷ 2 = 171 kênh | | ⚠ SAU: 19 + 3 = 22 người | ⚠ 22 × 21 ÷ 2 = 231 kênh | | ⚠ TĂNG THÊM | ⚠ 231 − 171 = 60 kênh | | ⚠ Bẫy chính | ⚠ đề hỏi "TĂNG THÊM BAO NHIÊU", không hỏi "tổng bao nhiêu" |

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

  • B (231) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ đó là ⚠ TỔNG số kênh SAU khi thêm người, ⚠ không phải phần tăng thêm; ⚠ ai tính đúng công thức nhưng đọc lướt câu hỏi sẽ chọn phương án này.

  • C (171) — ⚠ tổng số kênh TRƯỚC khi thêm người.

  • D (1) — ⚠ không có cơ sở nào.

Ghi nhớ về chất lượng câu hỏi

⚠ Có MÂU THUẪN về cách đếm giữa câu này và câu #25620 ở lô 177: | Câu | Đề bài | Cách đếm để ra khoá đáp án | |---|---|---| | ⚠ #25620 (lô 177) | ⚠ "18 bên liên quan" | ⚠ phải TÍNH THÊM quản lý dự án thành 19 → 171 kênh | | ⚠ #26057 (câu này) | ⚠ "19 bên liên quan" + 3 thành viên | ⚠ KHÔNG tính Vera → 22 người → 60 kênh tăng thêm | | ⚠ Nếu tính CẢ Vera ở câu này | ⚠ trước 20 người = 190, sau 23 người = 253, tăng 63 — KHÔNG có trong bộ phương án | | ⚠ Kết luận | ⚠ hai câu dùng HAI QUY ƯỚC ĐẾM KHÁC NHAU | | ⚠ Xử lý | ⚠ GIỮ NGUYÊN cả hai khoá — trong mỗi câu, chỉ có MỘT cách đếm cho ra đáp án nằm trong bộ phương án | | ⚠ Mẹo khi đi thi | ⚠ tính cả hai cách rồi xem cách nào cho ra con số CÓ trong bộ phương án — đó là quy ước đề đang dùng |

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25620 ở lô 177 (tính kênh giao tiếp, phải tính cả PM), câu #25942 lô 184 (ràng buộc giao tiếp — dự án đa quốc gia), và bộ bảy câu giao tiếp ở lô 184. ⚠ Nhóm giao tiếp.

⚠ Bảng tra nhanh số kênh giao tiếp: | Số người | Số kênh | |---|---| | ⚠ 5 | ⚠ 10 | | ⚠ 10 | ⚠ 45 | | ⚠ 15 | ⚠ 105 | | ⚠ 19 | ⚠ 171 | | ⚠ 20 | ⚠ 190 | | ⚠ 22 | ⚠ 231 | | ⚠ 30 | ⚠ 435 | | ⚠ Quy luật | ⚠ số kênh tăng theo BÌNH PHƯƠNG số người — thêm 3 người vào nhóm 19 đã sinh thêm 60 kênh |

Từ khoá nhận diện:

"tăng thêm bao nhiêu kênh" → ⚠ tính hiệu số, không lấy tổng "có bao nhiêu kênh" → ⚠ lấy tổng "n(n−1)/2" → ⚠ công thức duy nhất cần thuộc ⚠ Con số bằng đúng tổng trước hoặc tổng sau → ⚠ là phương án bẫy dành cho người đọc lướt

⚠ Ý nghĩa thực tiễn của con số 60 Ý nghĩa
⚠ Thêm 3 người mà sinh thêm 60 mối quan hệ giao tiếp ⚠ chi phí phối hợp tăng rất nhanh
⚠ Đó là lý do đội agile giữ quy mô NHỎ ⚠ thường 5–9 người
⚠ Và là lý do thêm người vào dự án trễ lại làm nó trễ thêm ⚠ liên hệ #25917 lô 183 — quy luật lợi ích giảm dần và định luật Brooks
⚠ Cách quản lý ⚠ chia nhóm nhỏ, có kênh chính thức rõ ràng, đừng để mọi người phải nói với mọi người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 19 × 18 ÷ 2 = 171 | ⚠ kiểm lại | | 22 × 21 ÷ 2 = 231 | ⚠ kiểm lại | | 231 − 171 = 60 | ⚠ và nhớ đây mới là câu trả lời |

Và bài học thực tế đằng sau một phép tính đơn giản: mỗi lần bạn thêm người vào dự án, bạn không chỉ thêm một người — bạn thêm một mối quan hệ với từng người đã có sẵn ở đó.

Câu 336 People
Nick is the scrum master for Project W. The project is in its fifth iteration, has a velocity of 85 story points, and is on budget. Recently a stakeholder approached Nick to ask when Project W’s lessons learned will be documented. How is Nick most likely to respond?
  1. A Lessons learned are documented at daily standups.
  2. B Lessons learned are constantly documented and reviewed in retrospectives.
  3. C Agile projects do not collect lessons learned.
  4. D Lessons learned are documented in the closing phase.
Xem giải thích

Đáp án

B — Bài học kinh nghiệm được ghi nhận LIÊN TỤC và được rà soát trong các buổi RETROSPECTIVE.

Vì sao đúng

⚠ Cách agile thu bài học: | Đặc điểm | Nội dung | |---|---| | ⚠ RETROSPECTIVE diễn ra CUỐI MỖI SPRINT | ⚠ nhịp cố định, không thể bỏ | | ⚠ Bài học được rút ra và ÁP DỤNG NGAY ở sprint sau | ⚠ khác hẳn việc lưu lại cho dự án tương lai | | ⚠ Không đợi tới cuối dự án | ⚠ lúc đó đã quên chi tiết và không còn cơ hội cải thiện | | ⚠ Thu thập liên tục trong suốt sprint, tổng hợp ở retrospective | | | ⚠ Đây chính là | ⚠ CẢI TIẾN LIÊN TỤC được đóng khung thành một sự kiện bắt buộc — liên hệ #26018 lô 185 |

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

  • D (bài học được ghi ở giai đoạn kết thúc) — ⚠ phương án gây nhiễu mạnh nhất vì đó là cách làm ĐÚNG trong dự án DỰ ĐOÁN ⚠ (liên hệ #25911 lô 183): ⚠ nhưng trong agile ⚠ đợi tới cuối là mất hoàn toàn cơ hội cải thiện ngay trong dự án; ⚠ đây là câu về dự án AGILE.

  • A (bài học được ghi ở các buổi standup hằng ngày) — ⚠ SAI BUỔI HỌP: ⚠ daily scrum 15 phút chỉ để đồng bộ và nêu vật cản ⚠ (liên hệ #25921 lô 183).

  • C (dự án agile không thu bài học) — ⚠ sai hoàn toàn; ⚠ agile thu bài học THƯỜNG XUYÊN HƠN dự án dự đoán.

Ghi nhớ

⚠ Đối chiếu — bài học kinh nghiệm nay lên TÁM câu qua bốn lô: ⚠ #25757/#25761 lô 180, ⚠ #25896, #25911 lô 183, ⚠ #25964 lô 184, ⚠ #25999, #26006 lô 185, ⚠ #26055 ở lô này (thêm mục vào chương trình họp), ⚠ và câu này. ⚠ #26055 và câu này là cặp đối chiếu đẹp: Adam trong dự án dự đoán phải TỰ TẠO nhịp bằng cách thêm mục vào chương trình họp, còn agile đã có nhịp đó sẵn dưới tên RETROSPECTIVE.

⚠ So sánh cách thu bài học: | | Dự đoán | Agile | |---|---|---| | ⚠ Thời điểm | ⚠ chủ yếu ở giai đoạn KẾT THÚC | ⚠ cuối MỖI SPRINT | | ⚠ Mục đích chính | ⚠ cho DỰ ÁN SAU | ⚠ cho SPRINT SAU — và cả dự án sau | | ⚠ Cơ chế | ⚠ phải chủ động tạo — liên hệ #26055 | ⚠ là sự kiện BẮT BUỘC của khung | | ⚠ Rủi ro | ⚠ bị bỏ quên vì không có nhịp | ⚠ trở thành thủ tục hình thức nếu không ai hành động sau đó | | ⚠ Điểm chung | ⚠ cả hai đều vô ích nếu bài học không dẫn tới THAY ĐỔI HÀNH VI |

Từ khoá nhận diện:

"bài học trong dự án agile" → ⚠ retrospective, liên tục "bài học ở giai đoạn kết thúc" → ⚠ đúng với dự đoán, sai với agile "ở daily standup" → ⚠ sai buổi họp "agile không thu bài học" → ⚠ sai hoàn toàn

⚠ Retrospective hiệu quả cần gì Yêu cầu
⚠ AN TOÀN TÂM LÝ để nói thật ⚠ liên hệ #25992 lô 185
⚠ Kết thúc bằng HÀNH ĐỘNG cụ thể, có người phụ trách ⚠ không phải danh sách than phiền
⚠ Số hành động ÍT — một hoặc hai, làm cho xong ⚠ mười cải tiến thì không cái nào được làm
⚠ Kiểm lại hành động của retrospective TRƯỚC ⚠ bước hay bị bỏ nhất, và làm mất niềm tin nhanh nhất
⚠ Đổi hình thức định kỳ ⚠ cùng một khuôn mãi thì ai cũng chán — liên hệ #25968 lô 184
⚠ Không phải là ⚠ buổi tìm người có lỗi
⚠ Nick nên nói gì thêm với bên liên quan Nội dung
⚠ Mời họ xem kết quả cải tiến, không phải biên bản retrospective ⚠ retrospective là buổi RIÊNG của đội — liên hệ #26022 lô 185
⚠ Nêu ví dụ cải tiến đã áp dụng và kết quả ⚠ thuyết phục hơn mọi lời giải thích về quy trình
⚠ Nói rõ bài học vẫn được tổng hợp cho tổ chức khi dự án đóng ⚠ agile không bỏ bước đó, chỉ không đợi tới đó
⚠ Vì sao bên liên quan hỏi ⚠ có thể họ quen dự án dự đoán và đang lo bước này bị bỏ — một cơ hội giáo dục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retrospective của đội bạn kết thúc bằng gì | ⚠ hành động cụ thể hay danh sách cảm xúc | | Hành động từ retrospective trước đã làm chưa | | | Có bài học nào được chia sẻ ra ngoài đội chưa | ⚠ liên hệ #26035 cùng lô — tri thức mức tổ chức |

Và điều làm nên sức mạnh của retrospective so với báo cáo bài học cuối dự án: bạn không viết cho một đội tương lai mà bạn chưa từng gặp — bạn viết cho chính mình, hai tuần nữa.

Câu 337 People
Ashley's team is focused on the goal of eliminating waste in their software project. They can best do this through
  1. A Gold plating, minimal requirement defects, and assigning the team to only one project at a time.
  2. B Minimizing required approvals, immediate testing of code, and a collocated team.
  3. C Distributed teams, providing the minimal features required, and a high rate of quality.
  4. D Having requirements waiting for the developer, minimal requirement defects, and a collocated team.
Xem giải thích

Đáp án

B — GIẢM TỐI THIỂU SỐ LẦN PHÊ DUYỆT, KIỂM THỬ MÃ NGAY LẬP TỨC, và ĐỘI NGỒI CHUNG.

Vì sao đúng

⚠ Ba yếu tố và loại lãng phí chúng loại bỏ: | Yếu tố | Loại lãng phí bị loại | |---|---| | ⚠ Giảm số lần phê duyệt | ⚠ CHỜ ĐỢI — thứ lãng phí lớn nhất trong phần lớn quy trình | | ⚠ Kiểm thử mã NGAY | ⚠ KHUYẾT TẬT và VIỆC LÀM DỞ — bắt lỗi khi còn rẻ | | ⚠ Đội NGỒI CHUNG | ⚠ BÀN GIAO và VẬN CHUYỂN THÔNG TIN — liên hệ #25885 lô 183 | | ⚠ Cả ba đều là | ⚠ thực hành LEAN chuẩn mực |

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

  • D (yêu cầu đã chờ sẵn cho lập trình viên, ít lỗi yêu cầu, đội ngồi chung) — ⚠ phương án gây nhiễu mạnh nhất vì hai vế sau đều tốt: ⚠ nhưng vế đầu ⚠ "yêu cầu ĐANG CHỜ lập trình viên" CHÍNH LÀ LÃNG PHÍ TỒN KHO ⚠ — công việc nằm chờ là vốn bị đóng băng, chưa tạo giá trị nào (liên hệ #26059 và giới hạn WIP ở #25940 lô 184).

  • A (mạ vàng, ít lỗi yêu cầu, mỗi người chỉ làm một dự án) — ⚠ MẠ VÀNG là lãng phí điển hình ⚠ (liên hệ #25975 lô 184) — làm thứ không ai yêu cầu.

  • C (đội phân tán, cung cấp tối thiểu tính năng cần thiết, chất lượng cao) — ⚠ ĐỘI PHÂN TÁN làm TĂNG lãng phí giao tiếp ⚠ (liên hệ #25942 lô 184).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25940 ở lô 184 (giới hạn WIP — giảm việc dở dang), câu #25885 lô 183 (lý do bố trí đội ngồi chung), câu #25975 (mạ vàng), và câu #26053 ở lô này (tích hợp liên tục). ⚠ Nhóm lean và loại bỏ lãng phí.

⚠ BẢY LOẠI LÃNG PHÍ trong phát triển phần mềm: | Lãng phí | Ví dụ | |---|---| | ⚠ CÔNG VIỆC LÀM DỞ (tồn kho) | ⚠ yêu cầu chờ sẵn, mã viết xong chưa tích hợp — bẫy của phương án D | | ⚠ TÍNH NĂNG THỪA | ⚠ mạ vàng — bẫy của phương án A | | ⚠ HỌC LẠI | ⚠ tri thức mất đi rồi phải tìm lại | | ⚠ BÀN GIAO (chuyển giao) | ⚠ mỗi lần chuyển việc giữa người là mất thông tin | | ⚠ CHUYỂN ĐỔI NHIỆM VỤ | ⚠ một người làm nhiều dự án cùng lúc | | ⚠ CHỜ ĐỢI | ⚠ chờ phê duyệt, chờ môi trường, chờ quyết định | | ⚠ KHUYẾT TẬT | ⚠ lỗi phải sửa, càng phát hiện muộn càng đắt | | ⚠ Nguyên tắc lean | ⚠ tối ưu hoá TOÀN BỘ DÒNG CHẢY, không tối ưu từng khâu riêng lẻ |

Từ khoá nhận diện:

"giảm phê duyệt, kiểm thử ngay, ngồi chung" → ⚠ loại bỏ lãng phí "yêu cầu chờ sẵn cho lập trình viên" → ⚠ lãng phí TỒN KHO, không phải hiệu quả "mạ vàng" → ⚠ lãng phí tính năng thừa "đội phân tán" → ⚠ tăng lãng phí giao tiếp

⚠ Vì sao "có sẵn việc để làm" nghe hay mà lại là lãng phí Giải thích
⚠ Yêu cầu phân tích xong nằm chờ sẽ LẠC HẬU dần ⚠ thị trường và nhu cầu thay đổi
⚠ Công sức phân tích đã bỏ ra nhưng CHƯA thu về giá trị nào
⚠ Che giấu nút thắt thật ở khâu phát triển
⚠ Tạo cảm giác bận rộn giả
⚠ Cách nhìn đúng ⚠ mục tiêu không phải giữ cho mọi người bận, mà là giữ cho CÔNG VIỆC CHẢY
⚠ Công cụ ⚠ giới hạn WIP chính là để chống loại lãng phí này — liên hệ #25940 lô 184
⚠ Vì sao giảm phê duyệt lại quan trọng nhất Lý do
⚠ Thời gian CHỜ thường chiếm phần lớn thời gian chu kỳ ⚠ công việc thật có khi chỉ vài giờ, chờ duyệt mất vài tuần
⚠ Mỗi lớp phê duyệt thêm vào là thêm một hàng đợi
⚠ Phê duyệt hiếm khi bắt được lỗi mà kiểm thử không bắt được
⚠ Nhưng cẩn thận ⚠ có những phê duyệt BẮT BUỘC về pháp lý hoặc an toàn — không bỏ được (liên hệ #26048 cùng lô)
⚠ Cách làm đúng ⚠ giữ phê duyệt CẦN THIẾT, bỏ phê duyệt theo thói quen — và hỏi mỗi lớp duyệt đang chặn được rủi ro gì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Một hạng mục của bạn dành bao nhiêu phần trăm thời gian để CHỜ | ⚠ đo thử một lần, con số thường gây sốc | | Có bao nhiêu lớp phê duyệt, và mỗi lớp chặn được rủi ro gì | | | Có bao nhiêu công việc đang nằm dở | ⚠ đó là vốn bị đóng băng |

Và cách nhận ra lãng phí lớn nhất trong quy trình của bạn: vẽ dòng thời gian của một hạng mục từ lúc được đề xuất tới lúc lên sản xuất, rồi tô màu những khoảng KHÔNG AI LÀM GÌ. Phần tô màu thường chiếm hơn một nửa.

Câu 338 Process
As a PMP candidate, you should recognize the different methods an organization can use to select projects. Benefits comparison is the most common approach to select projects, but constrained optimization, a more specialized approach to project selection, is also used by organizations. Which one of the following is an example of constrained optimization?
  1. A Benefit/cost ratios
  2. B Future value
  3. C Net present value
  4. D Linear programming
Xem giải thích

Đáp án

D — QUY HOẠCH TUYẾN TÍNH (linear programming).

Vì sao đúng

⚠ Tối ưu hoá có ràng buộc là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Dùng MÔ HÌNH TOÁN HỌC để chọn dự án | | | ⚠ TỐI ĐA HOÁ một mục tiêu trong điều kiện có RÀNG BUỘC | ⚠ ngân sách, nhân lực, thời gian | | ⚠ Quy hoạch tuyến tính là ví dụ điển hình nhất | | | ⚠ Các phương pháp khác cùng nhóm | ⚠ quy hoạch phi tuyến, quy hoạch số nguyên, quy hoạch động, thuật toán đa mục tiêu | | ⚠ Ứng dụng | ⚠ "với 10 tỷ ngân sách và 50 kỹ sư, chọn tổ hợp dự án nào cho lợi nhuận cao nhất" |

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

  • C (giá trị hiện tại ròng — NPV) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là công cụ tài chính để chọn dự án: ⚠ nhưng NPV thuộc nhóm ⚠ SO SÁNH LỢI ÍCH (benefit measurement), ⚠ không phải tối ưu hoá có ràng buộc; ⚠ nó ĐÁNH GIÁ từng dự án riêng lẻ, không tìm TỔ HỢP tối ưu dưới ràng buộc.

  • A (tỷ số lợi ích trên chi phí) và B (giá trị tương lai) — ⚠ cũng thuộc nhóm SO SÁNH LỢI ÍCH.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26013 ở lô 185 (cây quyết định cho make-or-buy), câu #26045 ở lô này (Monte Carlo), câu #25995 lô 185 (siêu dự án, chương trình, danh mục), và câu #25907 lô 183 (điểm hoà vốn make-or-buy). ⚠ Nhóm phân tích định lượng và lựa chọn dự án.

⚠ HAI NHÓM phương pháp lựa chọn dự án: | Nhóm | Phương pháp | Đặc điểm | |---|---|---| | ⚠ SO SÁNH LỢI ÍCH | ⚠ NPV, IRR, ROI, thời gian hoàn vốn, tỷ số lợi ích/chi phí, giá trị tương lai, mô hình cho điểm | ⚠ ĐÁNH GIÁ từng dự án — PHỔ BIẾN NHẤT | | ⚠ TỐI ƯU HOÁ CÓ RÀNG BUỘC | ⚠ quy hoạch tuyến tính, phi tuyến, số nguyên, động, đa mục tiêu — CÂU NÀY | ⚠ chọn TỔ HỢP dự án tốt nhất dưới ràng buộc — chuyên sâu, ít dùng hơn | | ⚠ Mẹo nhận diện | ⚠ có chữ "QUY HOẠCH" (programming) hoặc "thuật toán" thì gần như chắc chắn là tối ưu hoá có ràng buộc | | ⚠ Bẫy ngôn ngữ | ⚠ "programming" ở đây nghĩa là LẬP QUY HOẠCH TOÁN HỌC, không phải lập trình máy tính |

⚠ Các chỉ số của nhóm SO SÁNH LỢI ÍCH — cách đọc: | Chỉ số | Chọn dự án nào | |---|---| | ⚠ NPV | ⚠ CAO hơn thì tốt hơn; NPV âm thì không nên làm | | ⚠ IRR | ⚠ CAO hơn thì tốt hơn | | ⚠ Thời gian hoàn vốn | ⚠ NGẮN hơn thì tốt hơn | | ⚠ Tỷ số lợi ích/chi phí | ⚠ CAO hơn thì tốt hơn; dưới 1 thì lỗ | | ⚠ Chi phí cơ hội | ⚠ giá trị của phương án TỐT NHẤT bị bỏ qua — liên hệ #25668 lô 178 | | ⚠ Bẫy hay gặp | ⚠ thời gian hoàn vốn NGẮN là tốt, ngược chiều với các chỉ số còn lại |

Từ khoá nhận diện:

"quy hoạch tuyến tính, thuật toán, tối ưu tổ hợp" → ⚠ tối ưu hoá có ràng buộc "NPV, IRR, ROI, hoàn vốn" → ⚠ so sánh lợi ích "chọn tổ hợp dự án dưới ngân sách giới hạn" → ⚠ tối ưu hoá có ràng buộc "dự án này có đáng đầu tư không" → ⚠ so sánh lợi ích

⚠ Khi nào tổ chức cần tối ưu hoá có ràng buộc Trường hợp
⚠ Có RẤT NHIỀU dự án ứng viên
⚠ Ràng buộc rõ ràng và định lượng được ⚠ ngân sách, số kỹ sư, dây chuyền sản xuất
⚠ Các dự án phụ thuộc lẫn nhau ⚠ làm A thì phải làm B, hoặc A và C loại trừ nhau
⚠ Quyết định đáng giá đủ lớn để bỏ công mô hình hoá
⚠ Thực tế ⚠ phần lớn tổ chức dùng mô hình cho điểm đơn giản hơn — và điều đó chấp nhận được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn chọn dự án dựa trên gì | ⚠ con số hay quan hệ | | Có ràng buộc nào đang bị bỏ qua khi duyệt danh mục không | ⚠ thường là năng lực nhân sự | | Các dự án đã duyệt cộng lại có vượt năng lực thật không | ⚠ liên hệ #25935 lô 184 — hai PM tranh nhau một người |

Và lý do việc chọn dự án quan trọng hơn việc thực hiện dự án: thực hiện xuất sắc một dự án đáng lẽ không nên làm vẫn là lãng phí toàn bộ nguồn lực — chỉ là lãng phí một cách chuyên nghiệp.

Câu 339 People
In your agile team meeting, one of your co-workers, Bruno, claims he learned how to correct a piece of code through osmotic communication. What does Bruno mean by osmotic communication?
  1. A He got a book and read about the solution.
  2. B He searched for the solution on Google
  3. C He had a dream about the solution
  4. D In the agile team’s common area, he overheard a conversation in which the solution was discussed.
Xem giải thích

Đáp án

D — Trong KHÔNG GIAN CHUNG của đội agile, anh NGHE ĐƯỢC một cuộc trao đổi bàn về giải pháp đó.

Vì sao đúng

⚠ Giao tiếp thẩm thấu là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Thông tin lan tới người ta mà không cần ai chủ động truyền đạt | ⚠ giống như thẩm thấu qua màng | | ⚠ Xảy ra khi đội NGỒI CHUNG một không gian | ⚠ liên hệ #25885 lô 183 — lý do bố trí ngồi chung | | ⚠ Nghe được cuộc trò chuyện của người khác, tiếp thu điều hữu ích | | | ⚠ Không tốn thời gian họp, không tốn tài liệu | | | ⚠ Thuật ngữ | ⚠ do Alistair Cockburn đưa ra, là một trong các lợi ích chính của việc bố trí đội ngồi chung |

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

  • B (tìm giải pháp trên mạng) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là cách học thụ động và phổ biến: ⚠ nhưng đó là ⚠ TÌM KIẾM CHỦ ĐỘNG, ⚠ không phải thẩm thấu — thẩm thấu là thông tin tự tới với bạn.

  • A (đọc sách) — ⚠ cũng là học chủ động.

  • C (nằm mơ thấy giải pháp) — ⚠ phương án đùa, ⚠ hiển nhiên sai.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25885 ở lô 183 (lý do bố trí đội ngồi chung), câu #26059 ở lô này (đội ngồi chung loại bỏ lãng phí giao tiếp), câu #25954 lô 184 (giao tiếp trực tiếp hiệu quả nhất), và câu #25979 lô 185 (hai trục mật độ và tương tác). ⚠ Nhóm giao tiếp trong agile — và câu này là câu duy nhất về THẨM THẤU.

⚠ Lợi ích của việc đội ngồi chung: | Lợi ích | Nội dung | |---|---| | ⚠ GIAO TIẾP THẨM THẤU | ⚠ thông tin lan tự nhiên — CÂU NÀY | | ⚠ Giải đáp thắc mắc TỨC THÌ | ⚠ không phải chờ email hay lịch họp | | ⚠ Xây dựng lòng tin và quan hệ nhanh hơn | | | ⚠ Dùng được bảng vẽ và không gian chung | ⚠ liên hệ #25979 lô 185 — kênh hiệu quả nhất | | ⚠ Phát hiện vấn đề sớm nhờ nhìn thấy nhau làm việc | | | ⚠ Đánh đổi | ⚠ ồn ào, khó tập trung sâu — nên cần cả không gian YÊN TĨNH cho công việc cần tập trung |

Từ khoá nhận diện:

"nghe được trong không gian chung" → ⚠ giao tiếp thẩm thấu "tự tìm trên mạng, đọc sách" → ⚠ học chủ động, không phải thẩm thấu "đội ngồi chung" → ⚠ điều kiện để thẩm thấu xảy ra "phòng tác chiến, không gian mở của đội" → ⚠ thiết kế để tối đa hoá thẩm thấu

⚠ Đội phân tán làm sao có thẩm thấu Cách
⚠ Kênh trò chuyện MỞ, không dùng tin nhắn riêng cho việc chung ⚠ cách thay thế gần nhất
⚠ Phòng họp ảo mở suốt ngày làm việc
⚠ Ghi lại các buổi trao đổi kỹ thuật cho người khác múi giờ
⚠ Bảng thông tin điện tử ai cũng nhìn thấy
⚠ Sự thật cần chấp nhận ⚠ không cách nào thay thế được hoàn toàn — đó là một trong những cái giá thật của làm việc phân tán
⚠ Liên hệ ⚠ #25942 lô 184 — vị trí địa lý là RÀNG BUỘC giao tiếp
⚠ Mặt trái của thẩm thấu Mặt trái
⚠ Thông tin SAI cũng lan nhanh y như thông tin đúng
⚠ Gây phân tâm cho người cần tập trung sâu
⚠ Người vắng mặt bỏ lỡ thông tin mà không ai biết là họ đã lỡ ⚠ rủi ro thật với người làm từ xa xen kẽ
⚠ Cách bù ⚠ quyết định quan trọng phải được GHI LẠI ở kênh chính thức, dù đã bàn miệng — liên hệ #25949 lô 184

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có không gian chung không | | | Người làm từ xa có bỏ lỡ thông tin quan trọng không | | | Quyết định bàn miệng có được ghi lại ở đâu không | |

Và giá trị mà giao tiếp thẩm thấu tạo ra, thứ không xuất hiện trên bất kỳ báo cáo nào: Bruno sửa được đoạn mã đó mà không tốn của ai một phút họp nào — và không ai từng lập kế hoạch để chuyện đó xảy ra.

Câu 340 People
Stakeholder identification is a process that should start as early as possible in the project and should continue through the project closure. This activity ensures that stakeholders are engaged and managed throughout the entire project life cycle. When does a stakeholder exert the most influence over a project?
  1. A At the project’s start
  2. B During the project’s closing phase
  3. C During the project’s planning phase
  4. D During the project’s execution
Xem giải thích

Đáp án

A — Ở ĐẦU DỰ ÁN.

Vì sao đúng

⚠ Vì sao ảnh hưởng của bên liên quan lớn nhất ở đầu: | Lý do | Nội dung | |---|---| | ⚠ Đầu dự án CHƯA có gì được quyết cứng | ⚠ mọi lựa chọn còn mở | | ⚠ Chi phí thay đổi ở giai đoạn này THẤP NHẤT | ⚠ chỉ tốn giấy mực, chưa tốn thi công | | ⚠ Yêu cầu, phạm vi, cách tiếp cận đều đang được định hình | | | ⚠ Càng về sau, ảnh hưởng càng GIẢM và chi phí thay đổi càng TĂNG | ⚠ hai đường cong đi ngược chiều nhau | | ⚠ Hệ quả thực tiễn | ⚠ phải NHẬN DIỆN và GẮN KẾT bên liên quan sớm nhất có thể — liên hệ #26046 cùng lô |

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

  • C (giai đoạn lập kế hoạch) — ⚠ phương án gây nhiễu mạnh nhất vì lập kế hoạch cũng rất sớm và cũng là lúc bên liên quan đóng góp nhiều: ⚠ nhưng ⚠ ảnh hưởng LỚN NHẤT là ở KHỞI TẠO ⚠ — khi còn quyết định được cả việc CÓ LÀM DỰ ÁN NÀY HAY KHÔNG; ⚠ tới lập kế hoạch thì mục tiêu và điều lệ đã chốt.

  • D (giai đoạn thực hiện) và B (giai đoạn kết thúc) — ⚠ càng về sau ảnh hưởng càng nhỏ; ⚠ ở giai đoạn kết thúc, gần như mọi thứ đã được quyết và đã tiêu tiền.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26046 ở lô này (bỏ sót bên liên quan → liên hệ ngay), câu #26056 (mức gắn kết KHÔNG BIẾT), câu #25961 lô 184 (Ethel chưa gắn kết đủ), và câu #26047 ở lô này (vực đánh giá sau ba tháng). ⚠ Nhóm bên liên quan đã lên chín câu qua bốn lô.

⚠ HAI ĐƯỜNG CONG kinh điển của quản lý dự án: | Đường cong | Xu hướng | |---|---| | ⚠ ẢNH HƯỞNG của bên liên quan | ⚠ CAO nhất ở đầu, GIẢM dần về cuối | | ⚠ CHI PHÍ THAY ĐỔI | ⚠ THẤP nhất ở đầu, TĂNG mạnh về cuối | | ⚠ Hai đường CẮT NHAU ở đâu đó giữa dự án | | | ⚠ Bài học rút ra | ⚠ thời điểm tốt nhất để bên liên quan lên tiếng là lúc họ chưa thấy gì cụ thể — và đó cũng là lúc khó lấy được ý kiến của họ nhất | | ⚠ Nghịch lý | ⚠ người ta chỉ có ý kiến mạnh khi nhìn thấy sản phẩm — nhưng lúc đó thì sửa đã rất đắt | | ⚠ Cách agile giải quyết | ⚠ cho họ thấy sản phẩm THẬT sớm và thường xuyên, để ý kiến tới lúc còn sửa được — liên hệ #25984 lô 185 |

Từ khoá nhận diện:

"ảnh hưởng lớn nhất" → ⚠ đầu dự án "chi phí thay đổi thấp nhất" → ⚠ cũng ở đầu dự án "chi phí thay đổi cao nhất" → ⚠ cuối dự án ⚠ Hai đường cong này ngược chiều nhau → ⚠ nhớ một cái là suy ra cái kia

⚠ Hệ quả thực tiễn của đường cong này Hệ quả
⚠ Nhận diện bên liên quan phải làm CÀNG SỚM CÀNG TỐT ⚠ liên hệ #26046 — bỏ sót là lỗi nghiêm trọng
⚠ Đầu tư nhiều thời gian vào thu thập yêu cầu ban đầu
⚠ Nhưng phải RÀ LẠI liên tục — danh sách bên liên quan thay đổi
⚠ Với dự án dài, dùng cách tiếp cận thích ứng để giữ cửa sổ ảnh hưởng mở lâu hơn ⚠ liên hệ #25974 lô 184
⚠ Sai lầm phổ biến ⚠ hỏi ý kiến bên liên quan lần đầu ở buổi nghiệm thu — lúc đó họ chỉ còn quyền nói CÓ hoặc KHÔNG
⚠ Vì sao bên liên quan hay im lặng ở đầu Nguyên nhân
⚠ Chưa hình dung được sản phẩm sẽ ra sao
⚠ Bận việc chính, thấy dự án còn xa
⚠ Không được mời đúng cách hoặc chưa biết dự án tồn tại ⚠ liên hệ #26056 — mức KHÔNG BIẾT
⚠ Cách kéo họ vào sớm ⚠ dùng nguyên mẫu, bản phác thảo, kịch bản sử dụng — thứ cụ thể để họ có gì mà phản ứng
⚠ Liên hệ ⚠ #25972 lô 184 — nguyên mẫu để kiểm chứng ý tưởng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan chính của bạn đã tham gia từ giai đoạn nào | | | Bạn có thứ gì CỤ THỂ để họ phản hồi ngay từ đầu không | | | Có ai đưa ra yêu cầu lớn ở giai đoạn muộn không | ⚠ dấu hiệu họ chưa được gắn kết từ đầu |

Và điều đường cong này giải thích về gần như mọi dự án thất bại: không phải người ta không có ý kiến — mà là họ có ý kiến vào đúng lúc không ai còn đủ tiền để làm gì với ý kiến đó.