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

Đáp án

C — TỪ ĐIỂN WBS (WBS dictionary).

Vì sao đúng

⚠ Mọi thứ sếp của Leo hỏi đều là trường của từ điển WBS: | Thông tin | Có trong từ điển WBS | |---|---| | ⚠ MÃ ĐỊNH DANH TÀI KHOẢN | ⚠ CÓ — mã kế toán để theo dõi chi phí | | ⚠ TUYÊN BỐ CÔNG VIỆC của gói | ⚠ CÓ — mô tả chi tiết việc phải làm | | ⚠ Thông tin về công ty chịu trách nhiệm | ⚠ CÓ — tổ chức phụ trách | | ⚠ YÊU CẦU CHẤT LƯỢNG | ⚠ CÓ — tiêu chí nghiệm thu | | ⚠ Thông tin về nguồn lực cần | ⚠ CÓ | | ⚠ Kết luận | ⚠ từ điển WBS là tài liệu chi tiết đi kèm từng gói công việc |

⚠ Quan hệ giữa WBS và từ điển WBS: ⚠ WBS là SƠ ĐỒ phân rã — nó chỉ có tên gói và mã số; từ điển WBS là tài liệu MÔ TẢ CHI TIẾT cho từng gói đó ⚠ — ⚠ cả hai cùng với tuyên bố phạm vi tạo thành ĐƯỜNG CƠ SỞ PHẠM VI.

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

• D (WBS) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thông tin được hỏi rõ ràng là về các gói công việc, và WBS chính là nơi chứa các gói công việc đó: ⚠ nhưng ⚠ WBS chỉ là một CẤU TRÚC PHÂN RÃ — nó cho biết công việc được chia thành những gói nào, chứ không mô tả chi tiết từng gói ⚠ — ⚠ mã tài khoản, tuyên bố công việc, yêu cầu chất lượng đều là phần MÔ TẢ, và chúng nằm trong TỪ ĐIỂN; ⚠ cặp WBS và từ điển WBS giống như mục lục và nội dung: một cái cho biết có gì, một cái nói rõ đó là gì.

• A (kế hoạch quản lý dự án) — ⚠ nói về CÁCH quản lý dự án; ⚠ nó không chứa chi tiết từng gói công việc — liên hệ #26735 lô 200.

• B (kế hoạch thực thi) — ⚠ không phải thuật ngữ chuẩn của PMBOK; ⚠ phương án bịa.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26646 lô 198 (WBS chi tiết hoá công việc thuê ngoài), ⚠ #26747 lô 200 (quản lý phạm vi), ⚠ #26735 lô 200 (kế hoạch quản lý dự án), ⚠ #26806 cùng lô (không xác định hết công việc từ đầu), ⚠ #26814 cùng lô (tuyên bố công việc trong mua sắm).

⚠ TỪ ĐIỂN WBS chứa những gì: | Trường | Nội dung | |---|---| | ⚠ Mã định danh tài khoản | ⚠ để nối với hệ thống kế toán — sếp Leo hỏi cái này | | ⚠ Mô tả công việc | ⚠ làm gì, không làm gì | | ⚠ Giả định và ràng buộc | | | ⚠ Tổ chức hoặc người chịu trách nhiệm | | | ⚠ Các mốc thời gian | | | ⚠ Hoạt động tiến độ liên quan | | | ⚠ Nguồn lực cần | | | ⚠ Ước lượng chi phí | | | ⚠ YÊU CẦU CHẤT LƯỢNG và tiêu chí nghiệm thu | | | ⚠ Thông tin hợp đồng nếu thuê ngoài | ⚠ liên hệ #26646 lô 198 | | ⚠ Vì sao nó quan trọng | ⚠ từ điển WBS là nơi biến một cái tên trên sơ đồ thành một việc mà ai đó thật sự làm được — thiếu nó, mỗi người hiểu "gói công việc lắp đặt" theo một kiểu khác nhau |

⚠ ĐƯỜNG CƠ SỞ PHẠM VI gồm ba thứ: | Thành phần | Vai trò | |---|---| | ⚠ TUYÊN BỐ PHẠM VI | ⚠ mô tả phạm vi, sản phẩm, loại trừ, giả định — liên hệ #26747 lô 200 | | ⚠ WBS | ⚠ cấu trúc phân rã công việc thành các gói | | ⚠ TỪ ĐIỂN WBS | ⚠ chi tiết từng gói — ĐÁP ÁN | | ⚠ Điểm cần nhớ | ⚠ ba tài liệu này cùng nhau tạo thành đường cơ sở phạm vi, và mọi thay đổi với chúng đều phải qua kiểm soát thay đổi — liên hệ #26739 lô 200 |

⚠ QUY TẮC 8/80 và các nguyên tắc phân rã: | Nguyên tắc | Nội dung | |---|---| | ⚠ Quy tắc 8/80 | ⚠ mỗi gói công việc nên tốn từ 8 tới 80 giờ công | | ⚠ Quy tắc 100% | ⚠ WBS phải chứa 100% công việc, không thừa không thiếu — liên hệ #26747 lô 200 | | ⚠ Chia tới mức ước lượng và giao được | | | ⚠ Mỗi gói có một người chịu trách nhiệm | | | ⚠ Sai lầm thường gặp | ⚠ chia quá sâu làm WBS thành một danh sách việc vặt và tốn công quản lý hơn cả giá trị nó mang lại — mức chi tiết đúng là mức mà bạn ước lượng được và theo dõi được, không hơn |

Từ khoá nhận diện:

"mã tài khoản, tuyên bố công việc, yêu cầu chất lượng của gói" → ⚠ TỪ ĐIỂN WBS "cấu trúc phân rã công việc thành các gói" → ⚠ WBS "cách quản lý dự án" → ⚠ kế hoạch quản lý dự án "kế hoạch thực thi" → ⚠ thuật ngữ bịa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có từ điển WBS không | ⚠ rất nhiều dự án chỉ có WBS mà bỏ trống phần này | | Mỗi gói công việc có tiêu chí nghiệm thu không | | | Mỗi gói có một người chịu trách nhiệm rõ ràng không | |

Và điều mà một từ điển WBS được viết đầy đủ ngăn chặn: cuộc tranh cãi ở tháng thứ sáu về việc gói công việc này rốt cuộc bao gồm những gì — một cuộc tranh cãi mà không ai thắng được nếu chưa từng có ai chịu viết nó ra.

Đáp án

C — THƯ Ý ĐỊNH (letter of intent).

Vì sao đúng

⚠ Vì sao đây là thư ý định: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Larry ĐÃ QUYẾT ĐỊNH chọn nhà thầu | ⚠ ý định đã rõ ràng | | ⚠ Nhưng quy trình ký hợp đồng mất VÀI TUẦN | ⚠ có độ trễ hành chính | | ⚠ Larry gửi thông báo rằng tổ chức SẴN SÀNG THUÊ họ | ⚠ thể hiện ý định, chưa tạo nghĩa vụ đầy đủ | | ⚠ Dự án đang TRỄ và cần nhà thầu bắt đầu sớm | ⚠ đúng mục đích của thư ý định | | ⚠ Kết luận | ⚠ văn bản thể hiện ý định ký hợp đồng trong khi thủ tục còn đang chạy |

⚠ Thư ý định giúp nhà thầu bắt đầu chuẩn bị: ⚠ bố trí nhân sự, đặt vật tư, từ chối việc khác ⚠ — ⚠ nó cho họ đủ cơ sở để hành động mà không phải chờ hết vài tuần thủ tục.

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

• D (hợp đồng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thông báo này thật sự tạo ra một mức độ ràng buộc nhất định, và trong nhiều hệ thống pháp luật, thư ý định có thể phát sinh nghĩa vụ nếu bên kia đã hành động dựa trên nó: ⚠ nhưng ⚠ đề nói rõ quy trình HỢP ĐỒNG còn đang chạy và chưa hoàn tất ⚠ — ⚠ hợp đồng đòi đủ các yếu tố cấu thành: đề nghị, chấp nhận, đối giá, năng lực, mục đích hợp pháp, liên hệ #26718 lô 199; ⚠ thư ý định thiếu ít nhất một trong số đó, và chính vì vậy nó mới cần được thay bằng hợp đồng thật.

• A (đơn đặt hàng — purchase order) — ⚠ là một hình thức HỢP ĐỒNG ĐƠN PHƯƠNG dùng cho hàng hoá đơn giản; ⚠ nó là một cam kết mua thật, không phải một tuyên bố ý định.

• B (tuyên bố công việc — SOW) — ⚠ mô tả CÔNG VIỆC cần mua; ⚠ nó là một tài liệu kỹ thuật đi kèm hồ sơ mời thầu, không phải một thông báo về ý định.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26718 lô 199 (các yếu tố cấu thành hợp đồng), ⚠ #26684 lô 199 (thẩm quyền mua sắm và tuyên bố công việc), ⚠ #26775 lô 200 (điều khoản hợp đồng), ⚠ #26794 cùng lô (thay đổi hợp đồng trong lúc thực thi), ⚠ #26830 cùng lô (quản lý dự án trong đàm phán hợp đồng).

⚠ CÁC VĂN BẢN trong quá trình mua sắm — theo thứ tự: | Văn bản | Vai trò | |---|---| | ⚠ TUYÊN BỐ CÔNG VIỆC (SOW) | ⚠ mô tả việc cần mua — phương án B | | ⚠ Hồ sơ mời thầu (RFP, RFQ, IFB) | ⚠ mời nhà cung cấp chào giá | | ⚠ Đề xuất hoặc báo giá của nhà cung cấp | ⚠ liên hệ #26703 lô 199 | | ⚠ THƯ Ý ĐỊNH | ⚠ báo rằng sẽ ký hợp đồng — ĐÁP ÁN | | ⚠ HỢP ĐỒNG | ⚠ văn bản ràng buộc đầy đủ — phương án D | | ⚠ Đơn đặt hàng | ⚠ hình thức hợp đồng đơn giản cho hàng hoá — phương án A | | ⚠ Phụ lục sửa đổi | ⚠ khi có thay đổi — liên hệ #26794 cùng lô | | ⚠ Vị trí của thư ý định | ⚠ nó nằm ở khoảng trống giữa quyết định và hợp đồng — một khoảng trống mà mọi tổ chức có thủ tục mua sắm đều có, và là lý do công cụ này tồn tại |

⚠ Rủi ro khi dùng thư ý định: | Rủi ro | Nội dung | |---|---| | ⚠ Nhà thầu bắt đầu làm và phát sinh chi phí | ⚠ nếu hợp đồng cuối cùng không ký thì ai trả | | ⚠ Có thể phát sinh nghĩa vụ pháp lý ngoài dự tính | ⚠ tuỳ hệ thống pháp luật và tuỳ cách viết | | ⚠ Điều khoản chưa được thương lượng xong | ⚠ bên kia có thể hiểu là đã chốt | | ⚠ Vị thế đàm phán yếu đi | ⚠ khó lùi sau khi đã tuyên bố ý định | | ⚠ Cách dùng an toàn | ⚠ ghi RÕ trong thư rằng nó KHÔNG phải hợp đồng, nêu điều kiện để hợp đồng có hiệu lực, giới hạn phạm vi công việc được phép bắt đầu và mức chi phí được bảo đảm nếu hợp đồng không thành — và cho phòng pháp chế xem trước khi gửi |

⚠ Tình huống của Larry — đánh giá: | Yếu tố | Nhận xét | |---|---| | ⚠ Dự án trễ một tuần, còn mười tuần | ⚠ cần hành động nhưng chưa tới mức khủng hoảng | | ⚠ Đã có báo giá và đã chọn nhà thầu | ⚠ quy trình lựa chọn đã làm đúng | | ⚠ Thủ tục hợp đồng mất vài tuần | ⚠ một ràng buộc của tổ chức, không phải lỗi của ai | | ⚠ Thư ý định rút ngắn được độ trễ đó | ⚠ công cụ đúng cho vấn đề đúng | | ⚠ Việc Larry nên làm song song | ⚠ thúc quy trình hợp đồng nội bộ và ghi rủi ro "hợp đồng chưa ký mà công việc đã bắt đầu" vào sổ — vì tới lúc này, một phần rủi ro pháp lý đã chuyển sang phía tổ chức của anh |

Từ khoá nhận diện:

"báo rằng sẽ thuê, hợp đồng còn đang làm thủ tục" → ⚠ THƯ Ý ĐỊNH "văn bản ràng buộc đầy đủ" → ⚠ hợp đồng "mô tả công việc cần mua" → ⚠ tuyên bố công việc "đơn đặt hàng" → ⚠ một hình thức hợp đồng đơn giản, không phải tuyên bố ý định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn mất bao lâu để ký một hợp đồng | ⚠ con số đó phải nằm trong tiến độ của bạn | | Bạn có từng để nhà thầu bắt đầu trước khi ký không | | | Ai được phép ký thư ý định ở tổ chức bạn | ⚠ liên hệ #26684 lô 199 |

Và điều mà một lá thư ý định thật sự phản ánh: không phải sự linh hoạt của người quản lý dự án, mà khoảng cách giữa tốc độ mà dự án cần và tốc độ mà bộ máy mua sắm có thể chạy — và mọi công cụ trong khoảng trống đó đều đi kèm một phần rủi ro cần được ghi lại.

Đáp án

D — XÁC ĐỊNH XEM CÓ AI KHÁC TRONG TỔ CHỨC ĐANG DÙNG DEVOPS VÀ SẴN SÀNG HƯỚNG DẪN CHO ĐỘI HAY KHÔNG.

Vì sao đúng

⚠ Vì sao đây là cách xử lý tốt nhất: | Lý do | Nội dung | |---|---| | ⚠ Dùng TÀI SẢN QUY TRÌNH của tổ chức trước | ⚠ nguồn lực sẵn có, không tốn chi phí | | ⚠ Người nội bộ hiểu bối cảnh và quy ước của tổ chức | ⚠ giá trị hơn một khoá học tổng quát | | ⚠ Nhanh — không cần phê duyệt ngân sách | | | ⚠ Xây được quan hệ giữa các đội | ⚠ có nơi để hỏi về sau | | ⚠ Công cụ do PMO yêu cầu, nên nhiều khả năng đội khác đã dùng | ⚠ suy luận hợp lý từ chính đề bài | | ⚠ Kết luận | ⚠ giải pháp rẻ nhất, nhanh nhất và phù hợp bối cảnh nhất |

⚠ Nguyên tắc: ⚠ khi cần một năng lực mới, hãy tìm bên trong tổ chức TRƯỚC khi tìm ra ngoài ⚠ — ⚠ liên hệ #26800 và #26805 cùng lô, cùng một trình tự tư duy.

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

• C (hỏi ban lãnh đạo xem có video đào tạo nào cho đội dùng không) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng tìm nguồn lực nội bộ, cũng không tốn tiền và cũng là một hành động chủ động hợp lý: ⚠ nhưng ⚠ nó hỏi SAI NGƯỜI — ban lãnh đạo không phải nơi giữ tài liệu đào tạo về một công cụ kỹ thuật ⚠ — ⚠ và video hướng dẫn chung không giải quyết được vấn đề thật: đội cần biết công cụ này được dùng THẾ NÀO TRONG TỔ CHỨC NÀY; ⚠ một buổi hướng dẫn của đồng nghiệp đã dùng thật có giá trị hơn nhiều lần một thư viện video.

• B (tự bỏ tiền túi thuê đơn vị đào tạo) — ⚠ KHÔNG BAO GIỜ đúng; ⚠ chi phí dự án là chi phí của tổ chức, và tự trả tiền tạo tiền lệ nguy hiểm cùng vấn đề về minh bạch.

• A (hỏi đội có muốn dùng Microsoft Project thay thế không) — ⚠ đi ngược yêu cầu của PMO; ⚠ đổi công cụ vì khó học là né tránh vấn đề, và nó phá vỡ tính nhất quán mà PMO đang xây.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26819 cùng lô (phát triển kỹ năng đội trong dự án dài), ⚠ #26820 cùng lô (đánh giá hiệu quả sau đào tạo), ⚠ #26716 lô 199 (đào tạo khi đội thiếu kỹ năng), ⚠ #26783 cùng lô (thiết kế chương trình đào tạo), ⚠ #26719 lô 199 (cố vấn để truyền tri thức).

⚠ THANG PHƯƠNG ÁN khi đội thiếu kỹ năng về một công cụ: | Bậc | Phương án | Chi phí | |---|---|---| | ⚠ 1. Tìm người trong tổ chức đã dùng | ⚠ ĐÁP ÁN | ⚠ gần như bằng không | | ⚠ 2. Tài liệu, video, cộng đồng nội bộ | | ⚠ rất thấp | | ⚠ 3. Ghép cặp với người thạo việc | ⚠ liên hệ #26807 cùng lô | ⚠ thấp | | ⚠ 4. Đào tạo chính thức có ngân sách | ⚠ xin duyệt qua kênh đúng | ⚠ trung bình | | ⚠ 5. Thuê chuyên gia hỗ trợ tại chỗ | | ⚠ cao | | ⚠ Nguyên tắc | ⚠ luôn đi từ bậc thấp lên — và với một công cụ do chính PMO áp dụng cho nhiều dự án thì bậc 1 gần như chắc chắn có sẵn ở đâu đó trong tổ chức |

⚠ Vì sao đường cong học tập là chuyện bình thường: | Thực tế | Nội dung | |---|---| | ⚠ Mọi công cụ mới đều làm năng suất giảm tạm thời | ⚠ điều cần lường trước, không phải điều bất ngờ | | ⚠ Thời gian học phải được đưa vào TIẾN ĐỘ | ⚠ liên hệ #26716 lô 199 | | ⚠ Người ta học nhanh nhất khi làm việc thật | ⚠ không phải khi xem video | | ⚠ Sau giai đoạn đầu, năng suất thường vượt mức cũ | | | ⚠ Sai lầm phổ biến | ⚠ coi việc học chậm là vấn đề của con người thay vì là một giai đoạn cần được hỗ trợ — và phản ứng bằng cách gây áp lực, khiến người ta quay về công cụ cũ trong bí mật |

⚠ Vì sao phương án tự bỏ tiền túi luôn sai: | Vấn đề | Nội dung | |---|---| | ⚠ Chi phí dự án phải minh bạch và qua ngân sách dự án | | | ⚠ Tạo tiền lệ: người quản lý dự án tự gánh chi phí tổ chức | | | ⚠ Che giấu một nhu cầu thật khỏi tổ chức | ⚠ PMO sẽ không biết rằng công cụ họ áp dụng cần đào tạo kèm theo | | ⚠ Có thể vi phạm quy định về xung đột lợi ích | | | ⚠ Cách đúng | ⚠ nếu thật sự cần đào tạo có phí thì lập yêu cầu, nêu tác động và xin ngân sách — việc này còn giúp PMO nhận ra rằng họ cần chuẩn bị đào tạo cho mọi đội chứ không chỉ cho đội của bạn |

Từ khoá nhận diện:

"đội học công cụ mới chậm" → ⚠ TÌM NGƯỜI TRONG TỔ CHỨC đã dùng "hỏi ban lãnh đạo về video đào tạo" → ⚠ sai người, và nội dung chung không giải quyết được vấn đề riêng "tự bỏ tiền túi" → ⚠ không bao giờ đúng "đổi sang công cụ khác" → ⚠ đi ngược yêu cầu của PMO, né tránh vấn đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khi cần một năng lực mới, bạn tìm bên trong tổ chức trước không | | | Thời gian học công cụ mới có nằm trong tiến độ của bạn không | | | PMO có biết rằng công cụ họ áp dụng đang gây khó cho các đội không | |

Và điều mà một buổi hướng dẫn ba mươi phút từ một đồng nghiệp ở đội khác mang lại mà không khoá học nào mang lại được: họ không dạy công cụ đó làm được gì, mà dạy công ty này dùng nó như thế nào — và đó chính xác là thứ đội của bạn đang thiếu.

Đáp án

A — TRIỂN KHAI MÔ HÌNH "CAVES AND COMMONS" CHO ĐỘI DỰ ÁN.

Vì sao đúng

⚠ Mô hình "caves and commons" là gì: | Thành phần | Nội dung | |---|---| | ⚠ COMMONS — không gian chung | ⚠ khu làm việc mở cho cộng tác, trao đổi, giao tiếp thẩm thấu | | ⚠ CAVES — không gian riêng | ⚠ chỗ yên tĩnh để làm việc cần tập trung sâu | | ⚠ Mỗi người TỰ CHỌN theo loại công việc đang làm | ⚠ linh hoạt, không áp một khuôn cho tất cả | | ⚠ Giữ được lợi ích của đội cùng chỗ | ⚠ Brian vẫn ở gần đội, chỉ chuyển chỗ vài giờ mỗi ngày | | ⚠ Kết luận | ⚠ giải quyết nhu cầu của Brian mà không hy sinh sự cộng tác của cả đội |

⚠ Vì sao đây là giải pháp cân bằng nhất: ⚠ nó không buộc cả đội phải im lặng, không đẩy Brian ra khỏi đội, và không phủ nhận nhu cầu chính đáng của anh ⚠ — ⚠ nó thay đổi KHÔNG GIAN thay vì thay đổi con người.

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

• B (đặt giờ yên lặng ba tiếng mỗi ngày cho cả văn phòng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là một giải pháp thật, nhiều tổ chức áp dụng, và nó trực tiếp cho Brian đúng thứ anh xin: ⚠ nhưng ⚠ nó áp một quy tắc cứng lên TOÀN ĐỘI để phục vụ nhu cầu của một người ⚠ — ⚠ ba tiếng mỗi ngày không được trao đổi là một cái giá lớn cho một đội đang làm việc tốt cùng nhau, và nó chặn cả những cuộc hỏi đáp mà lẽ ra chỉ mất ba mươi giây; ⚠ caves and commons đạt được cùng mục tiêu mà không lấy đi gì của ai.

• D (cho Brian làm việc ở nhà) — ⚠ giải quyết được sự yên tĩnh nhưng làm mất SỰ CÙNG CHỖ; ⚠ đề nói rõ đội cùng chỗ và làm việc ăn ý — tách một người ra là phá vỡ điều đó.

• C (giải thích rằng giao tiếp thẩm thấu là thiết yếu) — ⚠ phủ nhận một nhu cầu chính đáng; ⚠ giao tiếp thẩm thấu có giá trị thật, nhưng nó không phải lý do để bác bỏ nhu cầu tập trung sâu.

Ghi nhớ

⚠ Ghi nhớ đối chiếu quan trọng: ⚠ #26851 lô 202 mô tả một tình huống rất gần: cũng về không gian yên tĩnh cho đội, nhưng ở đó phòng yên tĩnh ĐÃ CÓ và đang QUÁ TẢI vì nhiều người cùng cần ⚠ — ⚠ và khoá của câu đó lại chính là GIỜ YÊN LẶNG, tức là phương án nhiễu B của câu này; ⚠ hai khoá KHÔNG mâu thuẫn vì chỗ nghẽn khác nhau: ở đây CHƯA CÓ không gian riêng nào và chỉ một người nêu nhu cầu, nên cần thiết lập caves and commons; còn ở #26851 không gian đã có nhưng không đủ chỗ, nên phải giảm nhu cầu bằng cách biến cả khu làm việc thành nơi tập trung được; ⚠ bài học: luôn xác định THỨ ĐANG THIẾU trước khi chọn giải pháp.

⚠ Đối chiếu: ⚠ #26851 lô 202 (CÂU ĐỐI CHIẾU — cùng chủ đề, khoá khác vì chỗ nghẽn khác), ⚠ #26807 cùng lô (lập trình cặp — hoạt động cần không gian chung), ⚠ #26618 lô 197 (đồng địa điểm — collocation), ⚠ #26674 lô 198 (nhịp độ bền vững), ⚠ #26760 lô 200 (sửa cấu trúc thay vì sửa con người), ⚠ #26790 cùng lô (đội trưởng thành tự tìm cách làm việc).

⚠ GIAO TIẾP THẨM THẤU (osmotic communication): | Đặc điểm | Nội dung | |---|---| | ⚠ Thông tin lan truyền nhờ mọi người ngồi gần nhau | ⚠ nghe lỏm được câu chuyện liên quan tới mình | | ⚠ Câu hỏi được trả lời trong vài giây | ⚠ thay vì qua email và chờ nửa ngày | | ⚠ Người mới học rất nhanh | ⚠ liên hệ #26819 cùng lô | | ⚠ Vấn đề được phát hiện sớm | | | ⚠ Mặt trái ít được nói tới | ⚠ cùng cơ chế khiến thông tin lan nhanh cũng khiến sự phân tâm lan nhanh — và với công việc đòi tập trung sâu như viết mã phức tạp, mỗi lần bị ngắt mạch có thể mất mười lăm phút để lấy lại; đó chính là điều Brian đang mô tả |

⚠ Vì sao nhu cầu của Brian là chính đáng: | Lý do | Nội dung | |---|---| | ⚠ Công việc lập trình cần các khoảng tập trung dài | ⚠ không chia nhỏ được thành các mẩu năm phút | | ⚠ Chi phí của việc bị ngắt mạch rất cao | ⚠ và không nhìn thấy được trên bất kỳ báo cáo nào | | ⚠ Mỗi người có ngưỡng chịu nhiễu khác nhau | ⚠ liên hệ #26782 lô 200 — không áp một khuôn cho tất cả | | ⚠ Anh là lập trình viên kỳ cựu và đã nêu vấn đề rõ ràng | ⚠ đây là phản hồi có giá trị, không phải lời phàn nàn | | ⚠ Việc Felicia nên làm | ⚠ coi đây là một VẬT CẢN cần gỡ, đúng vai trò scrum master — và hỏi xem còn ai trong đội cũng gặp vấn đề tương tự mà chưa nói ra, liên hệ #26769 lô 200 |

⚠ Thiết kế không gian cho đội agile: | Khu vực | Dùng cho | |---|---| | ⚠ Không gian chung (commons) | ⚠ họp đứng, lập trình cặp, thảo luận, bảng trực quan — liên hệ #26714 lô 199 | | ⚠ Không gian riêng (caves) | ⚠ công việc cần tập trung sâu — ĐÁP ÁN | | ⚠ Phòng họp nhỏ | ⚠ trao đổi cần riêng tư — liên hệ #26698 lô 199 | | ⚠ Tường trống | ⚠ cho bảng thông tin trực quan | | ⚠ Nguyên tắc thiết kế | ⚠ không gian phải phục vụ CẢ HAI chế độ làm việc — cộng tác và tập trung; một văn phòng chỉ có một trong hai sẽ luôn làm khó một nửa số công việc mà đội phải làm |

Từ khoá nhận diện:

"cần yên tĩnh trong văn phòng mở" → ⚠ CAVES AND COMMONS "giờ yên lặng cho cả văn phòng" → ⚠ áp quy tắc cứng lên tất cả vì một người "cho làm ở nhà" → ⚠ mất lợi ích của đội cùng chỗ "giải thích rằng giao tiếp thẩm thấu quan trọng" → ⚠ phủ nhận một nhu cầu chính đáng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có chỗ nào để làm việc tập trung không | | | Một người trong đội bị ngắt mạch bao nhiêu lần mỗi ngày | | | Có ai đang chịu đựng mà chưa nói ra không | ⚠ Brian đã nói; những người khác có thể chưa |

Và điều mà mô hình caves and commons thừa nhận, còn các phương án khác thì không: công việc của một đội phần mềm không phải một loại duy nhất — có lúc cần nói chuyện với nhau liên tục, có lúc cần ba tiếng không ai chạm vào, và một không gian tốt phải cho phép cả hai trong cùng một ngày.

Đáp án

C — RỦI RO CÓ XÁC SUẤT 25% GÂY THIỆT HẠI 100.000 ĐÔ.

Vì sao đúng

⚠ Tính giá trị tiền tệ kỳ vọng cho cả bốn phương án: | Phương án | Phép tính | EMV | |---|---|---| | ⚠ A — 2% × 3.000.000 | ⚠ 0,02 × 3.000.000 | ⚠ 60.000 đô | | ⚠ B — 30% × 109.000 | ⚠ 0,30 × 109.000 | ⚠ 32.700 đô | | ⚠ C — 25% × 100.000 | ⚠ 0,25 × 100.000 | ⚠ 25.000 đô — THẤP NHẤT, ĐÁP ÁN | | ⚠ D — 10% × 700.000 | ⚠ 0,10 × 700.000 | ⚠ 70.000 đô | | ⚠ Xếp hạng ưu tiên | ⚠ D (70.000) > A (60.000) > B (32.700) > C (25.000) | |

⚠ EMV = XÁC SUẤT × TÁC ĐỘNG ⚠ — ⚠ và đề nói rõ rủi ro có EMV cao nhất là ưu tiên cao nhất, nên rủi ro có EMV thấp nhất là ưu tiên thấp nhất.

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

• A (2% × 3.000.000 = 60.000 đô) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ xác suất 2% là con số NHỎ NHẤT trong bốn phương án, nên người đọc lướt rất dễ kết luận rằng đây là rủi ro ít đáng lo nhất: ⚠ nhưng ⚠ tác động 3 triệu đô lại LỚN NHẤT, và tích của hai con số cho ra 60.000 — cao thứ hai trong bảng ⚠ — ⚠ đây chính là bài học của EMV: không được xếp hạng rủi ro chỉ bằng xác suất hay chỉ bằng tác động; ⚠ luôn phải nhân hai con số lại rồi mới so.

• B (30% × 109.000 = 32.700 đô) — ⚠ xác suất cao nhất nhưng tác động nhỏ; ⚠ EMV vẫn cao hơn phương án C.

• D (10% × 700.000 = 70.000 đô) — ⚠ cao nhất, tức là ưu tiên cao nhất; ⚠ ngược hoàn toàn với câu hỏi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26607 lô 197 (EMV để quyết định giảm nhẹ), ⚠ #26792 cùng lô (khi nào chấp nhận rủi ro), ⚠ #26777 lô 200 (ghi rủi ro và phản ứng vào sổ), ⚠ #26744 lô 200 (tra sổ khi rủi ro xảy ra), ⚠ #26743 lô 200 (ngưỡng và định nghĩa mức tác động).

⚠ GIÁ TRỊ TIỀN TỆ KỲ VỌNG — cách dùng: | Khía cạnh | Nội dung | |---|---| | ⚠ Công thức | ⚠ EMV = xác suất × tác động | | ⚠ Rủi ro TIÊU CỰC thì EMV mang dấu âm | ⚠ trong bài này đề nói về thiệt hại nên bỏ dấu cho gọn | | ⚠ Cơ hội (rủi ro tích cực) thì EMV dương | | | ⚠ Cộng EMV của mọi rủi ro để tính DỰ PHÒNG SỰ CỐ | ⚠ liên hệ #26744 lô 200 | | ⚠ Dùng trong cây quyết định để so sánh phương án | | | ⚠ Giá trị lớn nhất của EMV | ⚠ nó đưa xác suất và tác động về CÙNG một đơn vị để so sánh được — nếu không có nó, việc xếp hạng giữa "hiếm mà thảm khốc" và "hay xảy ra mà nhẹ" chỉ còn là cảm tính |

⚠ Hạn chế của EMV cần biết: | Hạn chế | Nội dung | |---|---| | ⚠ Không phản ánh RỦI RO THẢM HOẠ | ⚠ một thiệt hại 3 triệu có thể làm phá sản tổ chức, dù EMV chỉ 60.000 | | ⚠ Giả định có thể lặp lại nhiều lần | ⚠ nhưng dự án chỉ chạy MỘT lần | | ⚠ Phụ thuộc hoàn toàn vào chất lượng ước lượng đầu vào | ⚠ xác suất thường là phỏng đoán | | ⚠ Không tính tới khẩu vị rủi ro của tổ chức | ⚠ liên hệ #26743 lô 200 | | ⚠ Vì thế trong thực tế | ⚠ phương án A đáng được chú ý đặc biệt dù EMV chỉ đứng thứ hai — một tổ chức không chịu nổi cú sốc 3 triệu đô sẽ ưu tiên nó cao hơn những gì công thức gợi ý; EMV 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ó |

⚠ Các phương pháp xếp hạng rủi ro: | Phương pháp | Nội dung | |---|---| | ⚠ MA TRẬN XÁC SUẤT – TÁC ĐỘNG | ⚠ định tính, nhanh, dùng cho phần lớn rủi ro | | ⚠ EMV | ⚠ định lượng, so sánh được bằng tiền — CÂU NÀY | | ⚠ Mô phỏng Monte Carlo | ⚠ cho bức tranh phân bố xác suất của cả dự án | | ⚠ Cây quyết định | ⚠ so sánh các phương án có nhiều nhánh | | ⚠ Thứ tự thường dùng | ⚠ phân tích ĐỊNH TÍNH trước để lọc, rồi mới ĐỊNH LƯỢNG cho những rủi ro lọt qua bộ lọc đó — làm định lượng cho mọi rủi ro là tiêu công sức vào những thứ sẽ bị loại ngay |

Từ khoá nhận diện:

"giá trị tiền tệ kỳ vọng" → ⚠ XÁC SUẤT × TÁC ĐỘNG "xác suất nhỏ nhất" → ⚠ KHÔNG đồng nghĩa với ưu tiên thấp nhất "tác động lớn nhất" → ⚠ cũng không đồng nghĩa với ưu tiên cao nhất luôn phải làm → ⚠ nhân cả bốn phương án rồi mới so

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro của bạn xếp hạng theo gì | ⚠ cảm tính hay theo tích số | | Có rủi ro nào tác động thảm hoạ mà bị xếp thấp vì xác suất nhỏ không | | | Quỹ dự phòng sự cố của bạn tính từ đâu | |

Và điều mà một phép nhân đơn giản làm được cho một danh sách rủi ro dài: nó xếp bốn thứ tưởng như không so sánh được vào một hàng duy nhất — và biến một cuộc tranh luận về việc lo cái nào trước thành một bảng mà ai nhìn cũng thấy như nhau.

Đáp án

D — ĐỘI NÊN DÙNG MÔ HÌNH HỢP ĐỒNG LINH HOẠT VÀ ĐIỀU CHỈNH ĐỊNH NGHĨA HOÀN THÀNH CHUNG VỚI KHÁCH HÀNG ĐỂ ĐÁP ỨNG SỞ THÍCH ĐANG THAY ĐỔI CỦA HỌ.

Vì sao đúng

⚠ Vì sao đây là cách tiếp cận agile đúng: | Nguyên tắc agile | Nội dung | |---|---| | ⚠ "Hợp tác với khách hàng hơn là đàm phán hợp đồng" | ⚠ một trong bốn giá trị của Tuyên ngôn Agile | | ⚠ "Chào đón thay đổi, kể cả muộn trong quá trình phát triển" | ⚠ một trong mười hai nguyên tắc | | ⚠ Việc khách nhận ra điều mình thật sự muốn là THÀNH CÔNG của vòng phản hồi | ⚠ không phải thất bại của đội | | ⚠ Định nghĩa hoàn thành CHUNG với khách hàng thì điều chỉnh được | ⚠ liên hệ #26748 lô 200 | | ⚠ Hợp đồng linh hoạt cho phép đổi phạm vi trong khuôn khổ đã thoả thuận | | | ⚠ Kết luận | ⚠ agile được thiết kế chính xác cho tình huống này |

⚠ Đội đã làm ĐÚNG: ⚠ họ trình diễn phần mềm và khách hàng phát hiện ra sự khác biệt giữa điều đã yêu cầu và điều thật sự cần ⚠ — ⚠ phát hiện điều đó sau một vòng lặp rẻ hơn rất nhiều so với phát hiện sau mười tám tháng.

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

• C (nộp ngay yêu cầu thay đổi cho ban kiểm soát để thay đổi của khách được xét nhanh nhất) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có thiện chí, hướng tới việc phục vụ khách hàng nhanh chóng, và cũng tuân thủ quy trình: ⚠ nhưng ⚠ nó áp cơ chế của vòng đời DỰ ĐOÁN vào một dự án agile ⚠ — ⚠ trong agile, thay đổi về nội dung sản phẩm được xử lý qua TỒN ĐỌNG và việc xếp lại ưu tiên, không qua ban kiểm soát thay đổi; ⚠ ban kiểm soát thay đổi dành cho các thay đổi chạm tới đường cơ sở của dự án, không phải cho mỗi lần điều chỉnh một tính năng; ⚠ liên hệ #26803 cùng lô.

• A (thực hiện quy trình kiểm soát thay đổi để khách không thể đưa thay đổi ngoài hợp đồng gốc) — ⚠ dùng quy trình như một RÀO CẢN chống lại khách hàng; ⚠ trái hoàn toàn với giá trị hợp tác của agile.

• B (nói thẳng với khách rằng không được đổi khi vòng lặp đã bắt đầu) — ⚠ nửa đúng nửa sai: ⚠ đúng là không chen thay đổi vào vòng lặp ĐANG chạy, nhưng thay đổi hoàn toàn được đưa vào tồn đọng cho vòng lặp SAU — cách nói này đóng cửa thay vì mở đường.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26914 lô 203 (CÂU TRÙNG NGUYÊN VĂN — cùng khoá đáp án, nhưng chữ cái bị xáo: ở đó đáp án đúng là phương án A chứ không phải D, và hai phương án A và D hoán đổi vị trí cho nhau; đây là bằng chứng rõ ràng rằng bộ đề xáo thứ tự phương án giữa các lần ra đề, nên phải nhớ NỘI DUNG chứ đừng nhớ chữ cái), ⚠ #26748 lô 200 (định nghĩa hoàn thành), ⚠ #26825 cùng lô (tồn đọng phải được xếp lại khi có yêu cầu mới), ⚠ #26806 cùng lô (không xác định hết yêu cầu từ đầu), ⚠ #26784 cùng lô (giải thích agile cho bên liên quan), ⚠ #26788 cùng lô (chọn vòng đời phù hợp).

⚠ Vì sao "đúng yêu cầu" mà vẫn "không đúng ý" là chuyện bình thường: | Nguyên nhân | Nội dung | |---|---| | ⚠ Người ta khó hình dung thứ chưa tồn tại | ⚠ chỉ khi nhìn thấy mới biết mình muốn gì | | ⚠ Yêu cầu viết ra luôn mất mát so với ý định | ⚠ ngôn ngữ không mô tả đủ trải nghiệm | | ⚠ Bối cảnh kinh doanh thay đổi trong lúc làm | | | ⚠ Người viết yêu cầu có thể không phải người dùng thật | | | ⚠ Vì sao agile ra đời | ⚠ đây chính là vấn đề mà vòng lặp ngắn và trình diễn thường xuyên được thiết kế để giải quyết — coi nó là lỗi của khách hàng là hiểu ngược toàn bộ tinh thần của phương pháp |

⚠ HỢP ĐỒNG LINH HOẠT cho dự án agile: | Mô hình | Nội dung | |---|---| | ⚠ Thời gian và vật tư có TRẦN | ⚠ khách trả theo thực tế nhưng có giới hạn tối đa | | ⚠ Giá cố định theo GIA SỐ | ⚠ mỗi vòng lặp là một đơn vị mua | | ⚠ Điều khoản "đổi ngang phạm vi" | ⚠ thêm một tính năng thì bỏ một tính năng tương đương | | ⚠ Chia sẻ tiết kiệm | ⚠ xong sớm thì hai bên cùng hưởng | | ⚠ Chia sẻ rủi ro và lợi ích | ⚠ liên hệ #26693 lô 199 — tinh thần của IPD | | ⚠ Điểm chung | ⚠ mọi mô hình này đều chấp nhận rằng phạm vi chi tiết sẽ thay đổi, và chuyển sự chắc chắn từ PHẠM VI sang NGÂN SÁCH hoặc THỜI GIAN — đó là sự đánh đổi trung thực nhất mà một hợp đồng agile có thể đưa ra |

⚠ Đội của Linda nên làm gì cụ thể: | Bước | Việc | |---|---| | ⚠ Ghi nhận phản hồi của khách như một đầu vào giá trị | ⚠ không phòng thủ, không đổ lỗi | | ⚠ Làm rõ điều khách THẬT SỰ cần | ⚠ hỏi về mục tiêu, không hỏi về giải pháp | | ⚠ Đưa vào tồn đọng và xếp lại ưu tiên với chủ sản phẩm | ⚠ liên hệ #26825 cùng lô | | ⚠ Cập nhật định nghĩa hoàn thành nếu tiêu chí đã đổi | ⚠ ĐÁP ÁN | | ⚠ Nói rõ sự đánh đổi: thêm cái này thì cái gì lùi lại | | | ⚠ Rà lại mô hình hợp đồng nếu nó đang cản trở | ⚠ phần thứ hai của đáp án | | ⚠ Điều quan trọng nhất | ⚠ phần mềm đã làm ra KHÔNG lãng phí — nó là thứ đã giúp khách hàng hiểu ra điều họ cần, và đó là giá trị thật dù nó không đi vào sản phẩm cuối |

Từ khoá nhận diện:

"khách nhận ra thứ mình xin không phải thứ mình muốn" → ⚠ HỢP ĐỒNG LINH HOẠT + điều chỉnh định nghĩa hoàn thành "dùng kiểm soát thay đổi để chặn khách" → ⚠ trái tinh thần hợp tác "nộp yêu cầu thay đổi lên ban kiểm soát" → ⚠ cơ chế của vòng đời dự đoán "không được đổi khi vòng lặp đã bắt đầu" → ⚠ đúng cho vòng lặp hiện tại, sai khi đóng cửa hoàn toàn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn có cho phép thay đổi phạm vi không | | | Khách hàng của bạn thấy sản phẩm bao lâu một lần | ⚠ càng thưa thì bất ngờ càng lớn | | Đội bạn phản ứng thế nào khi khách đổi ý | ⚠ phòng thủ hay tò mò |

Và điều mà buổi trình diễn ấy thật sự mang lại, dù kết quả nghe như một thất bại: khách hàng vừa học được điều mà họ không thể học bằng cách nào khác — và cả hai bên vừa tránh được việc xây tiếp mười một tháng nữa cho một thứ không ai muốn.

Đáp án

A — CÂN NHẮC CÁCH TỐT NHẤT ĐỂ PHÁT TRIỂN KỸ NĂNG CỦA TỪNG THÀNH VIÊN.

Vì sao đúng

⚠ Vì sao đây là bước đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Tổ chức yêu cầu PHÁT TRIỂN ĐỘI | ⚠ đề nói rõ nhiệm vụ được giao | | ⚠ Đội sẽ làm việc cùng nhau ÍT NHẤT HAI NĂM | ⚠ đầu tư dài hạn là xứng đáng | | ⚠ Trình độ RẤT KHÁC NHAU: từ kỳ cựu tới người mới | ⚠ nhu cầu phát triển của mỗi người khác nhau | | ⚠ "Từng thành viên" — cá nhân hoá | ⚠ chi tiết quyết định của đáp án | | ⚠ Còn nhiều dự án tương tự sắp tới | ⚠ năng lực xây được sẽ dùng lại nhiều lần | | ⚠ Kết luận | ⚠ hiểu nhu cầu từng người trước rồi mới chọn hình thức phát triển |

⚠ Vì sao phải cá nhân hoá: ⚠ một lập trình viên kỳ cựu và một người mới cần hai lộ trình hoàn toàn khác nhau ⚠ — ⚠ một khoá đào tạo chung cho cả đội sẽ vừa thừa với người này vừa thiếu với người kia.

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

• C (xác định nên cung cấp khoá đào tạo nào cho đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đào tạo là hình thức phát triển đội quen thuộc nhất và nó cũng nằm trong kế hoạch quản lý nguồn lực: ⚠ nhưng ⚠ nó nhảy thẳng tới một GIẢI PHÁP CỤ THỂ trước khi hiểu NHU CẦU ⚠ — ⚠ và nó áp dụng chung cho cả đội, trong khi đề nhấn mạnh sự khác biệt về trình độ; ⚠ đào tạo chỉ là một trong nhiều hình thức phát triển: kèm cặp, ghép cặp, luân chuyển việc, cố vấn, tự học đều có thể phù hợp hơn với từng người.

• B (lập quy tắc cho phần dự đoán và định nghĩa cho phần agile) — ⚠ là việc về QUY TRÌNH, không phải về phát triển con người; ⚠ nó cần thiết cho dự án lai nhưng không trả lời yêu cầu của tổ chức.

• D (thảo luận quy tắc và chính sách về cơ cấu tổ chức của dự án) — ⚠ cũng là chuyện cơ cấu; ⚠ lạc khỏi chủ đề phát triển đội.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26815 cùng lô (tìm nguồn lực học hỏi trong tổ chức), ⚠ #26820 cùng lô (đo hiệu quả sau khi đào tạo), ⚠ #26716 lô 199 (đào tạo khi đội thiếu kỹ năng), ⚠ #26807 cùng lô (lập trình cặp — hình thức phát triển tại chỗ), ⚠ #26573 lô 196 (kế hoạch phát triển nghề nghiệp).

⚠ CÁC HÌNH THỨC PHÁT TRIỂN ĐỘI — không chỉ có đào tạo: | Hình thức | Phù hợp với | |---|---| | ⚠ Đào tạo chính thức | ⚠ kiến thức mới, chuẩn hoá — phương án C | | ⚠ KÈM CẶP (shadowing) | ⚠ người mới học từ người kỳ cựu — liên hệ #26660 lô 198 | | ⚠ LẬP TRÌNH CẶP | ⚠ học ngay trong lúc làm — liên hệ #26807 cùng lô | | ⚠ CỐ VẤN | ⚠ phát triển nghề nghiệp dài hạn — liên hệ #26719 lô 199 | | ⚠ Luân chuyển công việc | ⚠ mở rộng năng lực, giảm phụ thuộc một người | | ⚠ Giao việc khó có hỗ trợ | ⚠ cách học nhanh nhất với người đã có nền | | ⚠ Cộng đồng thực hành nội bộ | | | ⚠ Cách chọn | ⚠ người mới học nhanh nhất bằng kèm cặp và ghép cặp; người kỳ cựu phát triển tốt nhất khi được DẠY người khác hoặc nhận việc khó — nên một đội có cả hai nhóm cần ít nhất hai chiến lược khác nhau chạy song song |

⚠ Lợi ích kép của việc kỳ cựu dạy người mới: | Cho ai | Lợi ích | |---|---| | ⚠ Người mới | ⚠ học nhanh, hiểu bối cảnh thật của tổ chức | | ⚠ Người kỳ cựu | ⚠ dạy là cách học sâu nhất; đồng thời là sự ghi nhận | | ⚠ Dự án | ⚠ giảm phụ thuộc vào một người, tăng khả năng thay thế | | ⚠ Tổ chức | ⚠ năng lực ở lại sau khi dự án kết thúc — liên hệ #26716 lô 199 | | ⚠ Vì sao nó phù hợp với bối cảnh này | ⚠ đội sẽ ở cùng nhau hai năm và còn nhiều dự án tương tự — không có bối cảnh nào lý tưởng hơn cho một chương trình cố vấn nội bộ, và nó gần như không tốn ngân sách |

⚠ Cân nhắc riêng cho dự án LAI: | Yếu tố | Nội dung | |---|---| | ⚠ Đội cần hiểu CẢ HAI cách làm việc | ⚠ dự đoán và scrum | | ⚠ Người quen waterfall cần học tư duy lặp | | | ⚠ Người quen agile cần hiểu vì sao phần kia phải dự đoán | | | ⚠ Luân chuyển giữa hai phần là cách học tốt | | | ⚠ Lưu ý | ⚠ phương án B về quy tắc cho hai phần vẫn là việc CẦN LÀM cho một dự án lai — nó chỉ không phải câu trả lời cho yêu cầu PHÁT TRIỂN ĐỘI mà tổ chức vừa giao |

Từ khoá nhận diện:

"phát triển đội, trình độ khác nhau, gắn bó lâu dài" → ⚠ CÁ NHÂN HOÁ việc phát triển từng người "chọn khoá đào tạo cho đội" → ⚠ nhảy tới giải pháp trước khi hiểu nhu cầu "lập quy tắc cho hai phần của dự án lai" → ⚠ việc về quy trình, không về con người "cơ cấu tổ chức dự án" → ⚠ lạc chủ đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết mục tiêu phát triển của từng người trong đội không | ⚠ hỏi họ, đừng đoán | | Có ai trong đội đang làm mãi một loại việc không | | | Người kỳ cựu của bạn có ai để dạy không | ⚠ nếu không, bạn đang bỏ phí một nguồn lực và một động lực |

Và điều mà một đội sẽ ở cùng nhau hai năm cho phép người quản lý dự án làm mà một dự án ba tháng không cho phép: đầu tư vào con người với một chân trời đủ dài để thấy kết quả — và đó là loại đầu tư mà rất ít người quản lý dự án có cơ hội thực hiện.

Đáp án

C — ĐÁNH GIÁ XEM VIỆC ĐÀO TẠO ĐÃ TÁC ĐỘNG THẾ NÀO TỚI HIỆU SUẤT CỦA HỌ.

⚠ Ghi nhớ về chất lượng câu hỏi — câu GẦN TRÙNG: ⚠ câu này gần như trùng khớp với #26773 lô 200: ở đó Janice tổ chức đào tạo cho đội về hệ thống báo cáo thời gian và câu hỏi cũng là "sau đào tạo thì làm gì tiếp theo" ⚠ — ⚠ KHOÁ ĐÁP ÁN CỦA HAI CÂU NHẤT QUÁN: đều là theo dõi và đánh giá hiệu quả thật sự của việc đào tạo; ⚠ khác biệt: #26773 nhấn mạnh việc CHỦ ĐỘNG THEO DÕI cách đội dùng hệ thống, còn câu này nhấn mạnh việc ĐÁNH GIÁ TÁC ĐỘNG lên hiệu suất — hai cách diễn đạt của cùng một nguyên tắc; ⚠ lưu ý bộ đề xáo chữ cái: ở #26773 đáp án là phương án A, ở đây là phương án C.

Vì sao đúng

⚠ Vì sao phải đánh giá tác động: | Lý do | Nội dung | |---|---| | ⚠ Đào tạo là ĐẦU VÀO, thay đổi hiệu suất mới là KẾT QUẢ | ⚠ học xong không đồng nghĩa với làm tốt hơn | | ⚠ Đào tạo được thực hiện ĐỂ GIÚP DỰ ÁN | ⚠ nên phải đo bằng thước đo của dự án | | ⚠ Họ đã đi làm lại được MỘT TUẦN | ⚠ đủ thời gian để có dữ liệu ban đầu | | ⚠ Dự án đang chậm ba tuần | ⚠ cần biết khoản đầu tư này có giúp gì không | | ⚠ Nếu chưa hiệu quả thì còn kịp bổ sung | ⚠ kèm cặp, hỗ trợ thêm | | ⚠ Kết luận | ⚠ một can thiệp chưa hoàn tất cho tới khi có bằng chứng nó đã hiệu quả |

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

• D (hỏi chính hai lập trình viên xem họ thấy thế nào) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ hỏi trực tiếp người trong cuộc là hành động tôn trọng và thường được PMI khuyến khích: ⚠ nhưng ⚠ nó thu được CẢM NHẬN chứ không phải BẰNG CHỨNG về hiệu suất ⚠ — ⚠ người vừa đi học thường tự tin hơn thực tế, và câu trả lời gần như luôn là "tốt"; ⚠ nói chuyện với họ là việc nên làm và nên làm SONG SONG, nhưng nó bổ sung cho việc đánh giá chứ không thay thế được; ⚠ đây là mức 1 trong bốn mức đánh giá đào tạo, còn câu hỏi đòi mức 3.

• A (hỏi giảng viên xem họ học thế nào) — ⚠ đo kết quả trong LỚP HỌC, không đo hiệu suất trong CÔNG VIỆC; ⚠ đó là mức 2.

• B (hỏi quản lý của hai người xem họ thế nào) — ⚠ gián tiếp và mơ hồ; ⚠ Denise là người quản lý dự án, cô quan sát công việc của họ trực tiếp hơn ai hết.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26773 lô 200 (CÂU GẦN TRÙNG — cùng khoá), ⚠ #26815 cùng lô (đội học công cụ mới), ⚠ #26819 cùng lô (phát triển kỹ năng từng người), ⚠ #26716 lô 199 (đào tạo khi thiếu kỹ năng), ⚠ #26804 cùng lô (cập nhật tình hình dự án chậm và vượt chi).

⚠ BỐN MỨC ĐÁNH GIÁ ĐÀO TẠO (Kirkpatrick): | Mức | Đo gì | Phương án tương ứng | |---|---|---| | ⚠ 1. PHẢN ỨNG | ⚠ học viên thấy thế nào | ⚠ phương án D — hỏi chính họ | | ⚠ 2. HỌC TẬP | ⚠ có nắm được kiến thức không | ⚠ phương án A — hỏi giảng viên | | ⚠ 3. HÀNH VI và HIỆU SUẤT | ⚠ có làm khác đi trong công việc không | ⚠ ĐÁP ÁN | | ⚠ 4. KẾT QUẢ | ⚠ chỉ số dự án có cải thiện không | ⚠ đích cuối cùng | | ⚠ Điều đáng chú ý | ⚠ ba phương án nhiễu của câu này ánh xạ chính xác vào các mức THẤP HƠN của thang đánh giá — người ra đề dựng chúng một cách rất có chủ ý |

⚠ Denise nên đo những gì cụ thể: | Chỉ số | Nội dung | |---|---| | ⚠ Tốc độ hoàn thành các nhiệm vụ thuộc lĩnh vực đã đào tạo | | | ⚠ Số lỗi hoặc số lần phải làm lại | | | ⚠ Mức độ tự chủ — còn phải hỏi ai không | | | ⚠ Họ có bắt đầu chia sẻ lại cho đội không | ⚠ dấu hiệu nắm chắc nhất — liên hệ #26819 cùng lô | | ⚠ Tác động lên tiến độ chung | ⚠ dự án đang chậm ba tuần — đây là thước đo cuối cùng | | ⚠ Lưu ý về thời gian | ⚠ một tuần là đủ để thấy tín hiệu ban đầu nhưng chưa đủ để kết luận — Denise nên đặt một mốc đánh giá lại sau ba tới bốn tuần, vì hiệu ứng của đào tạo thường lộ rõ khi người ta gặp một tình huống thật sự khó |

⚠ Nếu đánh giá cho thấy chưa hiệu quả: | Nguyên nhân có thể | Cách xử lý | |---|---| | ⚠ Nội dung đào tạo không sát công việc thật | ⚠ bổ sung bằng kèm cặp tại chỗ | | ⚠ Chưa có cơ hội áp dụng | ⚠ giao việc phù hợp để họ thực hành | | ⚠ Thiếu công cụ hoặc quyền truy cập | ⚠ vật cản ngoài kiến thức | | ⚠ Cần thời gian dài hơn | ⚠ kiên nhẫn, đặt mốc đánh giá lại | | ⚠ Điều KHÔNG nên kết luận vội | ⚠ rằng khoản đầu tư đã lãng phí — một tuần là quá sớm để phán xét, và kết luận vội sẽ khiến tổ chức ngần ngại đầu tư cho lần sau |

Từ khoá nhận diện:

"vừa đào tạo xong, làm gì tiếp" → ⚠ ĐÁNH GIÁ TÁC ĐỘNG LÊN HIỆU SUẤT "hỏi học viên thấy thế nào" → ⚠ mức 1, đo cảm nhận "hỏi giảng viên" → ⚠ mức 2, đo kết quả trong lớp "hỏi quản lý của họ" → ⚠ gián tiếp, và bạn quan sát trực tiếp hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá đào tạo gần nhất của bạn được đo ở mức nào | | | Bạn có mốc đánh giá lại sau vài tuần không | | | Người vừa được đào tạo có được giao việc để áp dụng không | ⚠ không có cơ hội áp dụng thì kiến thức mất trong một tháng |

Và điều mà cùng một câu hỏi xuất hiện hai lần trong bộ đề đang muốn khắc sâu: tổ chức một khoá đào tạo là việc dễ và nhìn thấy được; kiểm chứng xem nó có thay đổi được điều gì hay không là việc khó và không ai đòi hỏi — nên nó gần như luôn bị bỏ qua.

Đáp án

A — NGÀY HOÀN THÀNH DỰ KIẾN CÓ THỂ LÀ MỘT CÔNG CỤ TỐT ĐỂ ĐO TIẾN TRIỂN CỦA MỘT DỰ ÁN AGILE.

Vì sao đúng

⚠ Vì sao agile vẫn dự báo ngày hoàn thành: | Lý do | Nội dung | |---|---| | ⚠ Agile dự báo bằng VẬN TỐC và TỒN ĐỌNG | ⚠ liên hệ #26699 lô 199 — phép tính rất đơn giản | | ⚠ Bên liên quan cần biết khi nào có sản phẩm | ⚠ để lập kế hoạch kinh doanh của họ | | ⚠ Dự báo thay đổi theo thời gian là ĐIỀU BÌNH THƯỜNG | ⚠ không phải lý do để bỏ dự báo | | ⚠ Ngày dự kiến giúp phát hiện xu hướng xấu sớm | ⚠ ngày lùi dần là tín hiệu cần xem xét | | ⚠ Từ chối đưa ra ngày làm mất lòng tin của tổ chức | ⚠ và khiến agile bị coi là cách né tránh cam kết | | ⚠ Kết luận | ⚠ agile không bỏ dự báo — nó thay dự báo MỘT LẦN bằng dự báo LIÊN TỤC được cập nhật |

⚠ Sai lầm của McMahon & Tate là một sai lầm rất phổ biến khi mới chuyển sang agile: ⚠ hiểu "chào đón thay đổi" thành "không cam kết gì cả" ⚠ — ⚠ và hậu quả là tổ chức mất niềm tin vào chính cách làm mới.

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

• D (không bao giờ nên dùng ngày dự kiến vì nó sẽ liên tục thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ vế "nó sẽ liên tục thay đổi" là ĐÚNG SỰ THẬT, nên phương án nghe có căn cứ: ⚠ nhưng ⚠ kết luận rút ra từ sự thật đó lại sai ⚠ — ⚠ dự báo thay đổi chính là ĐIỂM MẠNH: nó phản ánh thông tin mới nhất, khác với một ngày cố định từ đầu vốn sai ngay từ tháng thứ hai mà không ai chịu thừa nhận; ⚠ cách xử lý đúng là trình bày dự báo dưới dạng KHOẢNG và cập nhật đều đặn, không phải từ bỏ nó.

• C (không bao giờ nên dùng vì quá khó tính) — ⚠ sai về sự thật; ⚠ phép tính chỉ là tồn đọng chia vận tốc rồi nhân độ dài vòng lặp — liên hệ #26699 lô 199.

• B (tính bằng cách lấy điểm còn lại chia cho vận tốc kỳ vọng tính bằng GIỜ) — ⚠ sai đơn vị; ⚠ vận tốc tính bằng ĐIỂM CÂU CHUYỆN MỖI VÒNG LẶP, không phải bằng giờ — trộn hai đơn vị là lỗi khái niệm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26699 lô 199 (tính thời gian còn lại từ tồn đọng và vận tốc), ⚠ #26709 lô 199 (định nghĩa vận tốc), ⚠ #26784 cùng lô (giải thích agile cho bên liên quan đòi kế hoạch), ⚠ #26806 cùng lô (không xác định hết công việc từ đầu), ⚠ #26729 lô 199 (burndown).

⚠ DỰ BÁO TRONG AGILE — cách làm đúng: | Nguyên tắc | Nội dung | |---|---| | ⚠ Dự báo bằng KHOẢNG, không bằng một điểm | ⚠ "từ 10 tới 14 vòng lặp" thay vì "đúng 12 vòng lặp" | | ⚠ Dùng vận tốc TRUNG BÌNH của vài vòng gần nhất | ⚠ không dùng vòng tốt nhất | | ⚠ Cập nhật sau MỖI vòng lặp | ⚠ và cho bên liên quan thấy sự thay đổi | | ⚠ Nêu rõ GIẢ ĐỊNH kèm theo | ⚠ tồn đọng không tăng, đội không đổi | | ⚠ Phân biệt DỰ BÁO với CAM KẾT | ⚠ điểm quan trọng nhất | | ⚠ Cách trình bày tốt nhất | ⚠ "với vận tốc hiện tại và tồn đọng hiện tại, chúng tôi dự kiến xong trong khoảng tháng Chín tới tháng Mười một; con số này sẽ được cập nhật sau mỗi hai tuần" — nó vừa trung thực vừa hữu ích, và đó là điều mà việc từ chối đưa ra ngày không bao giờ đạt được |

⚠ Vì sao việc từ chối đưa ra ngày lại gây hại: | Hậu quả | Nội dung | |---|---| | ⚠ Bên liên quan không lập kế hoạch được | ⚠ họ có chiến dịch bán hàng, có hợp đồng, có ngân sách | | ⚠ Tổ chức mất niềm tin vào agile | ⚠ coi nó là cách né tránh trách nhiệm | | ⚠ Người ta sẽ tự đoán một ngày | ⚠ và con số họ đoán luôn tệ hơn con số bạn tính | | ⚠ Mất cơ hội phát hiện xu hướng xấu | ⚠ ngày dự kiến lùi dần là tín hiệu sớm nhất | | ⚠ Nhận xét | ⚠ agile không hứa hẹn ít hơn — nó hứa hẹn TRUNG THỰC HƠN, bằng cách nói rõ mức độ chắc chắn của dự báo và cập nhật nó thường xuyên; từ bỏ dự báo là vứt bỏ chính lời hứa đó |

⚠ Ba mức cam kết cần phân biệt: | Mức | Nội dung | |---|---| | ⚠ CAM KẾT vòng lặp | ⚠ đội cam kết mục tiêu của hai tuần tới — mức chắc chắn cao nhất | | ⚠ DỰ BÁO phát hành | ⚠ khoảng thời gian dự kiến cho bản phát hành — mức trung bình | | ⚠ TẦM NHÌN sản phẩm | ⚠ định hướng dài hạn — không có ngày cụ thể | | ⚠ Sai lầm hai chiều | ⚠ coi dự báo phát hành là cam kết cứng thì đội bị ép; từ chối đưa ra dự báo nào thì tổ chức bị mù — cả hai đều là cách hiểu sai về agile, và cách hiểu đúng nằm chính giữa |

Từ khoá nhận diện:

"ngày hoàn thành dự kiến trong agile" → ⚠ VẪN NÊN CÓ, là công cụ đo tiến triển "không bao giờ dùng vì nó sẽ thay đổi" → ⚠ sự thật đúng, kết luận sai "quá khó tính" → ⚠ sai; phép tính rất đơn giản "vận tốc tính bằng giờ" → ⚠ sai đơn vị; vận tốc là điểm mỗi vòng lặp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đưa ra ngày dự kiến cho bên liên quan không | | | Bạn trình bày nó dưới dạng một điểm hay một khoảng | | | Nó có được cập nhật sau mỗi vòng lặp không | |

Và điều mà huấn luyện viên agile nói với Greg thật ra là một lời nhắc về sự trung thực: không đưa ra ngày nào không làm cho dự án bớt bất định — nó chỉ chuyển sự bất định đó sang cho người khác, và họ sẽ xử lý nó bằng cách đoán.

Đáp án

B — TÍNH NĂNG CÓ THỂ TĂNG LÊN VÀ PHẢI ĐƯỢC HỖ TRỢ (lý do ÍT LIÊN QUAN nhất).

Vì sao đúng

⚠ Câu hỏi phủ định — soi từng lý do: | Phương án | Có giải thích được vì sao thay đổi muộn đắt hơn không | |---|---| | ⚠ A — cần làm lại nhiều hơn nếu phải sửa | ⚠ CÓ — lý do trực tiếp nhất | | ⚠ B — TÍNH NĂNG TĂNG LÊN VÀ PHẢI ĐƯỢC HỖ TRỢ | ⚠ KHÔNG — ĐÁP ÁN | | ⚠ C — nhiều mã phải tái cấu trúc hơn | ⚠ CÓ — hệ quả kỹ thuật trực tiếp | | ⚠ D — nhiều bên liên quan bị ảnh hưởng hơn | ⚠ CÓ — càng muộn càng nhiều người đã dựa vào cái cũ |

⚠ Vì sao B lạc đề: ⚠ việc số lượng tính năng tăng lên và phải được hỗ trợ là hệ quả của việc PHẠM VI MỞ RỘNG, không phải hệ quả của việc THAY ĐỔI ĐẾN MUỘN ⚠ — ⚠ một tính năng thêm vào ở tháng đầu cũng phải được hỗ trợ y như tính năng thêm vào ở tháng cuối; chi phí đó không phụ thuộc vào thời điểm; ⚠ ba lý do còn lại đều tăng theo thời gian, còn lý do này thì không.

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

• C (nhiều mã phải tái cấu trúc hơn) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe rất giống phương án A về việc làm lại, và người đọc dễ nghĩ hai phương án trùng nhau nên một trong hai phải là đáp án: ⚠ nhưng ⚠ hai lý do này KHÁC NHAU — làm lại là sửa thứ đã sai, còn tái cấu trúc là điều chỉnh CẤU TRÚC của phần mã vẫn đúng để nó hỗ trợ được thay đổi mới ⚠ — ⚠ và cả hai đều tăng theo thời gian vì càng muộn thì càng nhiều mã đã được xây dựa trên giả định cũ; ⚠ liên hệ #26728 lô 199 để thấy tái cấu trúc là một khái niệm riêng biệt.

• A (cần làm lại nhiều hơn) — ⚠ đúng và là lý do kinh điển nhất; ⚠ nên không phải đáp án của câu phủ định.

• D (nhiều bên liên quan bị ảnh hưởng hơn) — ⚠ cũng đúng; ⚠ càng muộn thì càng nhiều người đã đào tạo, đã tích hợp, đã lập kế hoạch dựa trên phiên bản cũ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26749 lô 200 (làm hạng mục rủi ro cao sớm nhất có thể), ⚠ #26818 cùng lô (khách đổi ý — agile chào đón thay đổi), ⚠ #26728 lô 199 (tái cấu trúc), ⚠ #26740 lô 200 (chi phí sửa lỗi theo thời điểm phát hiện), ⚠ #26793 cùng lô (tích hợp liên tục rút ngắn vòng phản hồi).

⚠ ĐƯỜNG CONG CHI PHÍ THAY ĐỔI — vì sao nó đi lên: | Nguyên nhân | Nội dung | |---|---| | ⚠ Nhiều thứ đã được xây dựa trên giả định cũ | ⚠ mỗi thứ đó có thể phải sửa theo | | ⚠ Cần LÀM LẠI phần đã hoàn thành | ⚠ phương án A | | ⚠ Cần TÁI CẤU TRÚC phần mã liên quan | ⚠ phương án C | | ⚠ Nhiều bên đã tích hợp hoặc đã đào tạo theo bản cũ | ⚠ phương án D | | ⚠ Kiểm thử phải chạy lại trên diện rộng | | | ⚠ Áp lực thời gian ở giai đoạn cuối làm mọi thứ đắt hơn | | | ⚠ Điều agile làm để làm phẳng đường cong này | ⚠ vòng lặp ngắn, tích hợp liên tục, kiểm thử tự động, thiết kế đơn giản, tái cấu trúc thường xuyên — mỗi thực hành đều nhằm giảm lượng thứ phải sửa theo khi có một thay đổi, liên hệ #26793 và #26728 |

⚠ Phân biệt LÀM LẠI và TÁI CẤU TRÚC: | Khái niệm | Nội dung | |---|---| | ⚠ LÀM LẠI (rework) | ⚠ sửa thứ đã SAI hoặc đã lỗi thời — hành vi của sản phẩm thay đổi | | ⚠ TÁI CẤU TRÚC (refactoring) | ⚠ sửa CẤU TRÚC mã mà KHÔNG đổi hành vi — liên hệ #26728 lô 199 | | ⚠ Vì sao cả hai đều tăng theo thời gian | ⚠ càng nhiều mã tồn tại thì càng nhiều chỗ chịu ảnh hưởng của một thay đổi — đây là lý do "thiết kế đơn giản" và "chỉ làm thứ cần ngay" lại là các thực hành tiết kiệm chứ không phải là sự lười biếng |

⚠ Vì sao phương án B thuộc một phạm trù khác: | Vấn đề của phương án B | Nội dung | |---|---| | ⚠ Nó nói về chi phí SỞ HỮU một tính năng | ⚠ hỗ trợ, bảo trì, tài liệu | | ⚠ Chi phí đó KHÔNG phụ thuộc vào việc tính năng được thêm khi nào | ⚠ điểm mấu chốt | | ⚠ Nó là lập luận chống lại việc THÊM tính năng, không phải chống lại việc thêm MUỘN | | | ⚠ Liên hệ khái niệm | ⚠ đây thực chất là lập luận về THẾP VÀNG và về sản phẩm khả dụng tối thiểu — liên hệ #26715 và #26711 lô 199; nó đúng ở chỗ khác nhưng không trả lời câu hỏi của Bruce |

Từ khoá nhận diện:

"tính năng tăng lên và phải hỗ trợ" → ⚠ chi phí SỞ HỮU, không phụ thuộc thời điểm — ĐÁP ÁN của câu phủ định "làm lại, tái cấu trúc, nhiều bên bị ảnh hưởng" → ⚠ đều tăng theo thời gian câu hỏi phủ định → ⚠ tìm lý do KHÔNG gắn với yếu tố thời gian đường cong chi phí thay đổi → ⚠ đi lên vì lượng thứ đã xây trên giả định cũ ngày càng nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Một thay đổi trong dự án bạn hôm nay tốn gấp mấy lần so với tháng đầu | | | Bạn có thực hành nào làm phẳng đường cong đó không | ⚠ kiểm thử tự động, thiết kế đơn giản, tích hợp liên tục | | Phần rủi ro cao nhất của bạn có được làm sớm không | ⚠ liên hệ #26749 lô 200 |

Và điều mà một câu hỏi phủ định khéo léo dạy được cho lớp học của Bruce: không phải mọi chi phí liên quan tới thay đổi đều tăng theo thời gian — và phân biệt được cái nào tăng, cái nào không, chính là thứ giúp bạn biết nên đầu tư vào việc rút ngắn vòng phản hồi hay vào việc kiểm soát phạm vi.