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

Đáp án

B — HÌNH THÀNH (Forming).

Vì sao đúng

⚠ Các dấu hiệu trong đề đều thuộc giai đoạn hình thành: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Đội cũ đã bị XÁO TRỘN, một nửa chuyển đi | ⚠ đội mới về bản chất, dù người quản lý vẫn cũ | | ⚠ Phần lớn là NHÂN VIÊN MỚI | ⚠ chưa từng làm việc với nhau | | ⚠ Có sự NGƯỢNG NGẬP giữa các thành viên | ⚠ dấu hiệu kinh điển của giai đoạn hình thành | | ⚠ Đang LÀM QUEN và ổn định vào vai trò mới | ⚠ đúng nội dung của giai đoạn này | | ⚠ Kết luận | ⚠ thay đổi thành phần đội đưa đội quay lại từ đầu, bất kể kinh nghiệm cá nhân của từng người |

⚠ Bài học quan trọng nhất của câu này: ⚠ các giai đoạn Tuckman thuộc về ĐỘI, không thuộc về từng cá nhân ⚠ — ⚠ một nhóm toàn người dày dạn vẫn phải đi qua giai đoạn hình thành khi họ mới ghép lại với nhau.

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

• C (Hiệu suất — Performing) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ người quản lý là một người dày dạn và các thành viên đều là nhân viên thật của tổ chức, nên dễ nghĩ rằng một đội gồm người có kinh nghiệm sẽ vào việc ngay: ⚠ nhưng ⚠ hiệu suất đòi LÒNG TIN và các quy tắc chung đã hình thành qua thời gian làm việc cùng nhau ⚠ — ⚠ đề nói rõ có sự ngượng ngập và mọi người đang làm quen, tức là chưa có gì trong số đó; ⚠ so sánh với #26790 lô 201, nơi đội đã ở cùng nhau lâu và tự chủ hoàn toàn — đó mới là hiệu suất.

• A (Mixed Norming) và D (Hybrid Storming) — ⚠ cả hai đều là thuật ngữ BỊA; ⚠ mô hình Tuckman chỉ có năm giai đoạn: hình thành, sóng gió, ổn định, hiệu suất, giải thể.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26855 cùng lô (CÂU CẶP — giai đoạn sóng gió), ⚠ #26790 lô 201 (giai đoạn hiệu suất), ⚠ #26683 lô 199 (việc cần làm ở giai đoạn hình thành), ⚠ #26832 lô 201 (đội mới cần gặp mặt để xây lòng tin), ⚠ #26759 lô 200 (quy tắc ứng xử cho đội mới).

⚠ NĂM GIAI ĐOẠN TUCKMAN — nhắc lại: | Giai đoạn | Đặc điểm | Việc của người dẫn dắt | |---|---|---| | ⚠ HÌNH THÀNH | ⚠ lịch sự, dè dặt, ngượng ngập — ĐÁP ÁN | ⚠ định hướng, giới thiệu, làm rõ vai trò | | ⚠ SÓNG GIÓ | ⚠ va chạm, xung đột cá tính — #26855 cùng lô | ⚠ hoà giải, nhắc quy tắc | | ⚠ ỔN ĐỊNH | ⚠ hình thành chuẩn chung, bắt đầu tin nhau | ⚠ củng cố, lùi lại | | ⚠ HIỆU SUẤT | ⚠ tự tổ chức — #26790 lô 201 | ⚠ trao quyền, gỡ vật cản | | ⚠ GIẢI THỂ | ⚠ kết thúc, chia tay | ⚠ ghi nhận, tổng kết | | ⚠ Điều ít người nhớ | ⚠ các giai đoạn KHÔNG một chiều — thêm hay bớt người đều có thể đưa đội lùi lại, và đó chính xác là điều đã xảy ra với đội trong đề |

⚠ Việc người quản lý nên làm ngay: | Việc | Nội dung | |---|---| | ⚠ Tổ chức buổi làm quen tử tế | ⚠ liên hệ #26683 lô 199 — giới thiệu trước mọi thứ khác | | ⚠ Làm rõ vai trò và kỳ vọng của từng người | ⚠ giảm sự mơ hồ, thứ nuôi dưỡng ngượng ngập | | ⚠ Cùng xây quy tắc ứng xử | ⚠ liên hệ #26759 lô 200 | | ⚠ Chấp nhận rằng năng suất sẽ thấp trong giai đoạn đầu | ⚠ và nói điều đó với cấp trên | | ⚠ Chuẩn bị tinh thần cho giai đoạn sóng gió sắp tới | ⚠ liên hệ #26855 cùng lô | | ⚠ Sai lầm phổ biến của người quản lý dày dạn | ⚠ giả định rằng vì MÌNH đã có kinh nghiệm nên đội sẽ vào guồng ngay — trong khi mối quan hệ giữa các thành viên mới là thứ quyết định, và nó phải được xây lại từ đầu |

Từ khoá nhận diện:

"đội bị xáo trộn, người mới, còn ngượng ngập" → ⚠ HÌNH THÀNH "va chạm về cá tính, mâu thuẫn" → ⚠ sóng gió (#26855 cùng lô) "tự chủ, tin nhau hoàn toàn" → ⚠ hiệu suất (#26790 lô 201) "Mixed Norming", "Hybrid Storming" → ⚠ thuật ngữ bịa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai mới trong ba tháng gần đây không | ⚠ nếu có, đội có thể đã lùi một giai đoạn | | Bạn đang lãnh đạo theo giai đoạn nào | | | Mọi người trong đội có biết vai trò của nhau không | |

Và điều mà một người quản lý dày dạn dễ quên nhất khi nhận một đội mới: kinh nghiệm của anh không rút ngắn được giai đoạn hình thành — nó chỉ giúp anh nhận ra mình đang ở trong đó và ngừng bực bội vì đội chưa chạy nhanh như đội cũ.

Đáp án

B — MỘT BÁO CÁO SAI LỆCH CHI PHÍ (cost variance report).

Vì sao đúng

⚠ Vì sao đây là hình thức truyền đạt phù hợp nhất: | Lý do | Nội dung | |---|---| | ⚠ Thành phố tăng PHÍ đấu nối | ⚠ đây là một thay đổi về CHI PHÍ | | ⚠ Nó tạo ra SAI LỆCH so với đường cơ sở chi phí | ⚠ đúng thứ mà báo cáo sai lệch dùng để ghi nhận | | ⚠ Báo cáo sai lệch là kênh CHÍNH THỨC và CÓ SỐ LIỆU | ⚠ để lại dấu vết, đưa vào hệ thống giám sát | | ⚠ Dự án ở tháng thứ năm trong mười hai tháng | ⚠ còn thời gian điều chỉnh nếu được ghi nhận sớm | | ⚠ Kết luận | ⚠ một thay đổi chi phí được xử lý bằng công cụ chi phí, không bằng một cuộc trò chuyện |

⚠ Chi tiết quan trọng: đây là thay đổi do YẾU TỐ BÊN NGOÀI ⚠ — ⚠ thành phố tăng phí là điều dự án không kiểm soát được, nên việc cần làm là ghi nhận tác động và đưa vào quy trình, chứ không phải tìm ai để trách; liên hệ #26870 cùng lô.

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

• D (một bản ghi nhớ gửi ban lãnh đạo về khoản phí) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thông báo cho cấp trên về một khoản chi phí phát sinh là việc đúng và cần làm: ⚠ nhưng ⚠ bản ghi nhớ là hình thức KHÔNG CHÍNH THỨC và thường KHÔNG CÓ SỐ LIỆU về tác động ⚠ — ⚠ nó không đi vào hệ thống giám sát chi phí, không cập nhật dự báo và không tạo cơ sở cho một yêu cầu thay đổi; ⚠ báo cáo sai lệch làm được tất cả những điều đó, và bản ghi nhớ có thể đi kèm nó chứ không thay thế được.

• A (một buổi trình bày trang trọng) — ⚠ quá nặng nề cho một thay đổi chi phí đơn lẻ; ⚠ tốn thời gian của nhiều người mà không thêm giá trị.

• C (bản ghi nhớ từ nhà thầu gửi ban lãnh đạo) — ⚠ sai kênh; ⚠ nhà thầu báo cho Virginia, và Virginia là người báo cáo lên trên — bỏ qua người quản lý dự án sẽ phá vỡ luồng thông tin.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26870 cùng lô (thay đổi do sự kiện bên ngoài), ⚠ #26804 lô 201 (cập nhật ngân sách và báo bên liên quan), ⚠ #26875 cùng lô (cập nhật đường cơ sở chi phí), ⚠ #26812 lô 201 (đo sai lệch bằng chỉ số), ⚠ #26826 lô 201 (kế hoạch quản lý giao tiếp quy định hình thức báo cáo).

⚠ Chọn hình thức truyền đạt theo nội dung: | Nội dung | Hình thức phù hợp | |---|---| | ⚠ Sai lệch chi phí hoặc tiến độ | ⚠ BÁO CÁO SAI LỆCH — ĐÁP ÁN | | ⚠ Tình trạng định kỳ | ⚠ báo cáo tình trạng theo mẫu | | ⚠ Quyết định lớn cần thảo luận | ⚠ cuộc họp | | ⚠ Thông tin cho nhiều bên, cần lưu vết | ⚠ email hoặc cổng thông tin | | ⚠ Kết quả cuối dự án cho lãnh đạo và cổ đông | ⚠ trình bày — liên hệ #26770 lô 200 | | ⚠ Nguyên tắc | ⚠ hình thức phải khớp với việc thông tin đó sẽ ĐI ĐÂU TIẾP: một sai lệch chi phí cần đi vào hệ thống giám sát và có thể sinh ra yêu cầu thay đổi, nên nó cần một báo cáo có số liệu chứ không phải một lời nhắn |

⚠ Virginia nên đưa gì vào báo cáo: | Nội dung | Chi tiết | |---|---| | ⚠ Mức phí cũ và mức phí mới | ⚠ con số cụ thể | | ⚠ Tác động lên tổng chi phí dự án | ⚠ và lên dự báo khi hoàn thành | | ⚠ Nguyên nhân: quyết định của chính quyền thành phố | ⚠ yếu tố bên ngoài, không kiểm soát được | | ⚠ Phương án xử lý | ⚠ dùng quỹ dự phòng, xin bổ sung, hay điều chỉnh phạm vi | | ⚠ Việc cần quyết định và ai quyết | | | ⚠ Bước tiếp theo sau báo cáo | ⚠ nếu vượt ngưỡng thì lập yêu cầu thay đổi để cập nhật đường cơ sở chi phí, liên hệ #26875 cùng lô — báo cáo là để ghi nhận, yêu cầu thay đổi mới là để sửa kế hoạch |

⚠ Vì sao ghi nhận sớm lại quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Dự án mới ở tháng thứ năm | ⚠ còn bảy tháng để hấp thụ hoặc bù đắp | | ⚠ Có thể còn nhiều khoản phí khác cùng loại | ⚠ một lần tăng phí thường báo hiệu chính sách đã đổi | | ⚠ Quỹ dự phòng cần được theo dõi khi bị dùng | | | ⚠ Nhận xét | ⚠ nhà thầu báo cho Virginia là hành vi đúng — điều đó cho thấy kênh thông tin giữa họ đang hoạt động tốt, và việc của cô bây giờ là bảo đảm thông tin đó tiếp tục đi đúng đường lên phía trên |

Từ khoá nhận diện:

"chi phí thay đổi so với kế hoạch" → ⚠ BÁO CÁO SAI LỆCH CHI PHÍ "bản ghi nhớ" → ⚠ không chính thức, thiếu số liệu, không vào hệ thống giám sát "buổi trình bày trang trọng" → ⚠ quá nặng cho một thay đổi đơn lẻ "nhà thầu báo thẳng lên lãnh đạo" → ⚠ sai kênh, bỏ qua người quản lý dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sai lệch chi phí trong dự án bạn được ghi nhận ở đâu | | | Ngưỡng nào thì phải lập yêu cầu thay đổi | | | Nhà thầu của bạn báo tin xấu cho ai đầu tiên | |

Và điều mà một báo cáo sai lệch làm được mà một lời nhắn không làm được: nó biến một khoản phí tăng thành một con số nằm trong hệ thống — nơi nó được cộng dồn, được theo dõi và được nhìn thấy cùng với mọi khoản khác vào cuối quý.

Đáp án

C — SÓNG GIÓ (Storming).

Vì sao đúng

⚠ Ba dấu hiệu trong đề đều thuộc giai đoạn sóng gió: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ XUNG ĐỘT CÁ TÍNH giữa các thành viên | ⚠ dấu hiệu đặc trưng nhất của sóng gió | | ⚠ Trễ họp, không tôn trọng giờ giấc | ⚠ chưa hình thành chuẩn mực chung | | ⚠ Dự án bị CHẬM vì các vấn đề đó | ⚠ năng suất giảm — đặc điểm của giai đoạn này | | ⚠ Đã làm việc SÁU THÁNG | ⚠ đủ lâu để qua giai đoạn hình thành, chưa đủ để ổn định | | ⚠ Kết luận | ⚠ đội đang ở giữa giai đoạn khó khăn nhất của mô hình Tuckman |

⚠ Vì sao sáu tháng vẫn còn ở sóng gió là chuyện bình thường: ⚠ thời gian ở mỗi giai đoạn không cố định ⚠ — ⚠ một đội có thể mắc kẹt ở sóng gió rất lâu nếu không ai chủ động can thiệp.

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

• A (Ổn định — Norming) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ sáu tháng nghe như đủ dài để một đội đã ổn định, và nhiều người tính giai đoạn theo THỜI GIAN thay vì theo HÀNH VI: ⚠ nhưng ⚠ ổn định nghĩa là các chuẩn chung đã hình thành và mọi người bắt đầu tin nhau ⚠ — ⚠ đội này vẫn xung đột về cá tính và chưa giữ nổi giờ họp, tức là chưa có chuẩn nào cả; ⚠ giai đoạn được xác định bằng HÀNH VI QUAN SÁT ĐƯỢC, không bằng số tháng đã trôi qua.

• B (Hình thành) — ⚠ giai đoạn lịch sự và dè dặt; ⚠ liên hệ #26853 cùng lô — ở đó mới là hình thành.

• D (Hiệu suất) — ⚠ đội tự vận hành và tin nhau; ⚠ ngược hoàn toàn với mô tả.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26853 cùng lô (CÂU CẶP — giai đoạn hình thành), ⚠ #26790 lô 201 (giai đoạn hiệu suất), ⚠ #26750 lô 200 (xử lý xung đột bằng cộng tác), ⚠ #26859 cùng lô (gặp riêng một thành viên đang có vấn đề), ⚠ #26759 lô 200 (quy tắc ứng xử).

⚠ Người quản lý nên làm gì ở giai đoạn SÓNG GIÓ: | Việc | Nội dung | |---|---| | ⚠ Thừa nhận rằng đây là giai đoạn BÌNH THƯỜNG | ⚠ không phải dấu hiệu đội hỏng | | ⚠ Xây hoặc nhắc lại QUY TẮC ỨNG XỬ | ⚠ liên hệ #26759 lô 200 — giờ họp là ví dụ điển hình | | ⚠ Xử lý xung đột bằng CỘNG TÁC, không né tránh | ⚠ liên hệ #26750 lô 200 | | ⚠ Làm rõ vai trò và ranh giới trách nhiệm | ⚠ phần lớn xung đột cá tính thật ra là xung đột về vai trò | | ⚠ Gặp riêng những người liên quan trực tiếp | ⚠ liên hệ #26859 cùng lô | | ⚠ Tách xung đột NHIỆM VỤ khỏi xung đột QUAN HỆ | ⚠ liên hệ #26675 lô 198 | | ⚠ Điều tệ nhất có thể làm | ⚠ NÉ TRÁNH và hy vọng nó tự qua — sóng gió không tự hết; một đội bị bỏ mặc ở giai đoạn này sẽ ở lại đó tới hết dự án |

⚠ Phân biệt xung đột lành mạnh và xung đột phá hoại: | Loại | Dấu hiệu | Xử lý | |---|---|---| | ⚠ Xung đột NHIỆM VỤ | ⚠ tranh luận về cách làm, về giải pháp | ⚠ LÀNH MẠNH — khuyến khích | | ⚠ Xung đột QUY TRÌNH | ⚠ bất đồng về ai làm gì, làm thế nào | ⚠ làm rõ vai trò là giải quyết được | | ⚠ Xung đột QUAN HỆ | ⚠ cá tính, cảm xúc cá nhân — CA NÀY | ⚠ có hại nhất, cần can thiệp sớm | | ⚠ Nhận xét về đội trong đề | ⚠ đề nói rõ là "xung đột cá tính", tức là loại nguy hiểm nhất — nhưng rất thường thì phía sau một xung đột cá tính lại là một xung đột về vai trò chưa được làm rõ, và đó là nơi nên bắt đầu tìm |

⚠ Nhận diện giai đoạn qua HÀNH VI, không qua thời gian: | Câu hỏi | Giai đoạn | |---|---| | ⚠ Mọi người còn dè dặt, lịch sự với nhau không | ⚠ hình thành | | ⚠ Có va chạm công khai về cách làm hoặc cá tính không | ⚠ SÓNG GIÓ — câu này | | ⚠ Đã có các quy ước chung và mọi người giữ chúng chưa | ⚠ ổn định | | ⚠ Đội tự vận hành khi bạn vắng mặt không | ⚠ hiệu suất | | ⚠ Mẹo làm bài | ⚠ bỏ qua số tháng trong đề — nó luôn là thông tin gây nhiễu; chỉ đọc phần mô tả hành vi |

Từ khoá nhận diện:

"xung đột cá tính, trễ họp, năng suất giảm" → ⚠ SÓNG GIÓ "ngượng ngập, đang làm quen" → ⚠ hình thành (#26853 cùng lô) "đã có chuẩn chung, bắt đầu trơn tru" → ⚠ ổn định "sáu tháng rồi nên chắc đã ổn định" → ⚠ giai đoạn xác định bằng hành vi, không bằng thời gian

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có xung đột nào chưa được xử lý không | | | Nó là xung đột về nhiệm vụ, quy trình hay quan hệ | | | Bạn đang can thiệp hay đang chờ nó tự qua | |

Và điều mà giai đoạn sóng gió thật sự là: không phải dấu hiệu đội đã chọn sai người, mà là hoá đơn phải trả cho việc chưa ai ngồi xuống thoả thuận cách làm việc với nhau — và hoá đơn đó vẫn còn trả được ở tháng thứ sáu.

Đáp án

D — KIỂM SOÁT THAY ĐỔI KÉM HIỆU QUẢ (ineffective change control).

Vì sao đúng

⚠ Vì sao đây là vấn đề về kiểm soát thay đổi: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Thành viên TỰ Ý thêm lỗ thông gió | ⚠ thêm việc ngoài phạm vi mà không xin phép | | ⚠ Kế hoạch dự án KHÔNG yêu cầu việc này | ⚠ rõ ràng nằm ngoài phạm vi đã duyệt | | ⚠ Không qua bất kỳ quy trình phê duyệt nào | ⚠ đúng định nghĩa của kiểm soát thay đổi thất bại | | ⚠ Việc thêm vào có thể HỢP LÝ về kỹ thuật | ⚠ các chuyên gia trong đội đồng tình | | ⚠ Kết luận | ⚠ thay đổi ĐÚNG về kỹ thuật vẫn là thay đổi KHÔNG ĐƯỢC KIỂM SOÁT |

⚠ Câu này đối chiếu trực tiếp với #26746 lô 200: ⚠ ở đó James cũng tự thêm cải tiến và câu hỏi là "người quản lý nên làm gì trước tiên"; ở đây câu hỏi là "đây là ví dụ của cái gì" ⚠ — ⚠ hai câu cùng một tình huống, hỏi từ hai góc, và khoá hoàn toàn nhất quán.

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

• C (thay đổi tạo thêm giá trị — value-added change) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ các chuyên gia trong đội ĐỒNG Ý rằng việc thêm lỗ thông gió là đúng, nên nó thật sự có thể tạo thêm giá trị: ⚠ nhưng ⚠ giá trị của một thay đổi và tính hợp lệ của quy trình là hai chuyện tách biệt ⚠ — ⚠ câu hỏi hỏi tình huống này là ví dụ của cái gì, và điều nổi bật nhất là một thay đổi đã được thực hiện mà không ai phê duyệt; ⚠ nếu chấp nhận lập luận "có giá trị nên không sao" thì mọi người sẽ tự quyết mọi thứ, và đó chính là cách một dự án mất kiểm soát phạm vi; ⚠ liên hệ #26746 lô 200.

• A (đội tự dẫn dắt — self-led teams) — ⚠ tự dẫn dắt nghĩa là đội tự quyết CÁCH LÀM, không phải tự quyết LÀM GÌ; ⚠ liên hệ #26809 lô 201.

• B (kiểm soát chi phí) — ⚠ việc thêm có tốn tiền, nhưng đó là hệ quả; ⚠ nguyên nhân nằm ở quy trình thay đổi.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26746 lô 200 (CÂU ĐỐI CHIẾU — cùng tình huống, hỏi bước xử lý), ⚠ #26715 lô 199 (thếp vàng — làm thêm ngoài phạm vi), ⚠ #26872 cùng lô (mọi thay đổi qua quy trình chính thức), ⚠ #26843 cùng lô (hệ thống kiểm soát thay đổi), ⚠ #26866 cùng lô (việc phát sinh phải qua ban kiểm soát thay đổi).

⚠ Vì sao "thay đổi tốt" vẫn phải qua quy trình: | Lý do | Nội dung | |---|---| | ⚠ Chưa ai đánh giá TÁC ĐỘNG đầy đủ | ⚠ chi phí vật tư, giờ công, ảnh hưởng tới việc khác | | ⚠ Khách hàng chưa đồng ý trả tiền cho nó | ⚠ công việc ngoài phạm vi thường không được thanh toán | | ⚠ Có thể ảnh hưởng tới bảo hành và trách nhiệm | ⚠ với công trình nhà ở, việc tự ý sửa kết cấu là vấn đề pháp lý thật | | ⚠ Tạo tiền lệ: lần sau sẽ có người làm nhiều hơn | | | ⚠ Không ai biết nó đã được làm | ⚠ hồ sơ hoàn công không khớp thực tế | | ⚠ Nguyên tắc | ⚠ kiểm soát thay đổi không tồn tại để CẤM thay đổi mà để bảo đảm mọi thay đổi đều ĐƯỢC NHÌN THẤY và ĐƯỢC CHỌN — một thay đổi tốt bị thực hiện lén vẫn làm hỏng cả hai điều đó |

⚠ Frank nên xử lý thế nào: | Bước | Việc | |---|---| | ⚠ Hỏi thành viên về CƠ SỞ của quyết định | ⚠ liên hệ #26746 lô 200 | | ⚠ Đánh giá tác động thật của việc đã làm | | | ⚠ Hợp thức hoá bằng một yêu cầu thay đổi | ⚠ nếu giữ lại thì phải có hồ sơ | | ⚠ Nhắc lại quy trình với cả đội | ⚠ không chỉ với một người | | ⚠ Ghi nhận thiện chí và chuyên môn | ⚠ hướng nó vào đúng kênh thay vì dập tắt | | ⚠ Điều tinh tế | ⚠ các chuyên gia trong đội đều đồng ý rằng việc đó là cần — nghĩa là quy trình lập kế hoạch đã BỎ SÓT một yêu cầu kỹ thuật; đó mới là bài học đáng ghi lại, chứ không phải chuyện một người làm sai thủ tục |

Từ khoá nhận diện:

"tự ý thêm việc ngoài kế hoạch" → ⚠ KIỂM SOÁT THAY ĐỔI KÉM HIỆU QUẢ "nhưng nó tạo thêm giá trị" → ⚠ giá trị và tính hợp lệ của quy trình là hai chuyện khác nhau "đội tự dẫn dắt" → ⚠ tự quyết CÁCH LÀM, không tự quyết LÀM GÌ "kiểm soát chi phí" → ⚠ hệ quả, không phải nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có việc nào trong dự án bạn đang được làm mà không truy được về một yêu cầu không | | | Đội bạn có biết ngưỡng nào cần xin phép không | | | Khi ai đó làm thêm việc tốt, bạn phản ứng thế nào | ⚠ phản ứng đó quyết định lần sau họ có nói với bạn trước hay không |

Và điều mà một cặp lỗ thông gió được thêm vào với thiện chí đặt ra cho Frank: không phải câu hỏi có nên giữ chúng lại hay không, mà là vì sao chúng không có trong kế hoạch ngay từ đầu — và ai khác trong dự án cũng đang lặng lẽ sửa những thiếu sót tương tự.

Đáp án

A — KHÔNG PHẢI THỨ MÀ KHÁCH HÀNG THẬT SỰ MUỐN.

Vì sao đúng

⚠ VỰC ĐÁNH GIÁ (gulf of evaluation) là gì: | Khái niệm | Nội dung | |---|---| | ⚠ Khoảng cách giữa Ý ĐỊNH của người dùng và thứ HỌ NHẬN ĐƯỢC | ⚠ họ nhìn sản phẩm và không thấy điều mình mong đợi | | ⚠ Người dùng khó diễn đạt điều mình thật sự cần | ⚠ cho tới khi nhìn thấy một thứ cụ thể | | ⚠ Đội xây đúng những gì được yêu cầu | ⚠ nhưng yêu cầu không phản ánh đúng nhu cầu | | ⚠ Kết luận | ⚠ bản phát hành đầu tiên gần như chắc chắn lệch khỏi điều khách thật sự muốn |

⚠ Đây chính là lý do tồn tại của các vòng lặp ngắn: ⚠ agile chấp nhận rằng vực đánh giá LUÔN có, nên giải pháp không phải cố lấy yêu cầu chuẩn hơn mà là cho khách xem sản phẩm sớm và thường xuyên ⚠ — ⚠ liên hệ #26818 lô 201.

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

• B (không phải thứ mà lập trình viên thật sự muốn xây) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng nói về một khoảng cách giữa ý định và kết quả, chỉ khác chủ thể: ⚠ nhưng ⚠ vực đánh giá là khái niệm về NGƯỜI DÙNG diễn giải sản phẩm, không phải về sở thích của người xây ⚠ — ⚠ và mong muốn của lập trình viên không phải thước đo của dự án; ⚠ khái niệm anh em của nó là "vực thực thi" (gulf of execution): khoảng cách giữa điều người dùng muốn làm và cách hệ thống cho phép họ làm — cả hai đều xoay quanh người dùng.

• C (không phải thứ lập trình viên thật sự đã bàn giao) — ⚠ câu này gần như vô nghĩa về mặt logic.

• D (không phải thứ scrum master thật sự hiểu) — ⚠ scrum master không phải người định nghĩa sản phẩm; ⚠ liên hệ #26809 lô 201.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26818 lô 201 (khách nhận ra thứ mình xin không phải thứ mình muốn), ⚠ #26824 lô 201 (bắt đầu từ bản mẫu để rút ngắn khoảng cách này), ⚠ #26878 cùng lô (kiểm thử nghiệm thu xác nhận đúng ý khách), ⚠ #26837 cùng lô (điểm chạm thường xuyên với bên liên quan), ⚠ #26806 lô 201 (không xác định hết yêu cầu từ đầu).

⚠ Các cách rút ngắn vực đánh giá: | Cách | Nội dung | |---|---| | ⚠ Vòng lặp NGẮN với sản phẩm chạy được | ⚠ cách hiệu quả nhất — cho khách thấy thay vì mô tả | | ⚠ Bản mẫu và khung giao diện sớm | ⚠ liên hệ #26824 lô 201 — rẻ hơn nhiều so với xây thật | | ⚠ Tiêu chí nghiệm thu viết cùng khách hàng | ⚠ liên hệ #26878 cùng lô | | ⚠ Trình diễn ở mỗi buổi rà soát | | | ⚠ Cho người dùng thật dùng thử sớm | ⚠ không chỉ người đại diện | | ⚠ Điều KHÔNG hiệu quả | ⚠ cố viết tài liệu yêu cầu chi tiết hơn — nếu người ta chưa hình dung được thứ mình muốn thì thêm mười trang mô tả cũng không giúp họ hình dung ra |

⚠ Vì sao bản phát hành ĐẦU TIÊN đặc biệt dễ lệch: | Lý do | Nội dung | |---|---| | ⚠ Khách chưa có gì để đối chiếu | ⚠ mọi yêu cầu đều dựa trên tưởng tượng | | ⚠ Đội chưa hiểu bối cảnh nghiệp vụ đủ sâu | | | ⚠ Các giả định ngầm chưa được nói ra | | | ⚠ Người phát biểu yêu cầu có thể không phải người dùng thật | | | ⚠ Cách nhìn đúng | ⚠ bản phát hành đầu tiên nên được coi là một CÔNG CỤ HỌC TẬP chứ không phải sản phẩm cuối — kỳ vọng nó đúng ngay từ đầu là kỳ vọng sai, và nó dẫn tới sự thất vọng không cần thiết cho cả hai phía |

Từ khoá nhận diện:

"vực đánh giá" → ⚠ sản phẩm KHÔNG phải thứ khách hàng thật sự muốn "vực thực thi" → ⚠ khoảng cách giữa điều người dùng muốn làm và cách hệ thống cho phép "lập trình viên muốn xây gì" → ⚠ không liên quan tới khái niệm này cách chữa → ⚠ cho khách THẤY sớm, không phải viết yêu cầu kỹ hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khách hàng của bạn thấy sản phẩm thật lần đầu vào lúc nào | | | Người phát biểu yêu cầu có phải người dùng thật không | | | Bản phát hành đầu tiên của bạn có được coi là công cụ học tập không | |

Và điều mà khái niệm vực đánh giá dạy cho một đội đang thất vọng vì làm đúng yêu cầu mà khách vẫn không hài lòng: khoảng cách đó không phải lỗi của ai — nó là đặc tính của việc con người mô tả những thứ chưa tồn tại, và cách duy nhất thu hẹp nó là cho họ nhìn thấy sớm hơn.

Đáp án

C — HỢP ĐỒNG THỜI GIAN VÀ VẬT TƯ KIỂU AGILE (agile time and materials contract).

Vì sao đúng

⚠ Vì sao hợp đồng thời gian và vật tư cho phép dừng bất cứ lúc nào: | Đặc điểm | Nội dung | |---|---| | ⚠ Khách trả theo CÔNG SỨC THỰC TẾ đã bỏ ra | ⚠ không trả cho một phạm vi cố định | | ⚠ Không có cam kết về một sản phẩm cuối cụ thể | ⚠ nên dừng lại không vi phạm gì | | ⚠ Dừng ở cuối một vòng lặp là điểm cắt tự nhiên | ⚠ phần đã làm vẫn có giá trị | | ⚠ Khách chỉ trả cho những gì đã nhận | ⚠ rất phù hợp với mô hình giao gia số | | ⚠ Kết luận | ⚠ cấu trúc thanh toán theo thực tế chính là thứ cho phép chấm dứt linh hoạt |

⚠ Bối cảnh trong đề rất đúng tinh thần agile: ⚠ đại diện phía nghiệp vụ thấy KHÔNG CÒN GIÁ TRỊ để tiếp tục sau mười vòng lặp ⚠ — ⚠ dừng đúng lúc là một quyết định tốt, không phải một thất bại; liên hệ #26711 lô 199 về việc chỉ làm phần lõi.

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

• D (hợp đồng chấm dứt sớm kiểu agile) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ tên gọi của nó mô tả CHÍNH XÁC điều câu hỏi đang hỏi, nên nó nghe như đáp án hiển nhiên: ⚠ nhưng ⚠ "agile early termination contract" KHÔNG phải một loại hợp đồng có tên trong chuẩn nào ⚠ — ⚠ đây là thuật ngữ được bịa ra bằng cách diễn giải chính câu hỏi thành một cái tên; ⚠ cùng dạng bẫy với "Future Visualization" ở #26758 lô 200; ⚠ điều CÓ THẬT là ĐIỀU KHOẢN chấm dứt sớm, và nó có thể được đưa vào nhiều loại hợp đồng — nhưng bản thân nó không phải một loại hợp đồng.

• A (agile phased development contract) và B (agile iteration contract) — ⚠ cả hai cũng là tên bịa; ⚠ chúng ghép từ agile với các khái niệm quen thuộc để nghe có vẻ hợp lệ.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26818 lô 201 (hợp đồng linh hoạt cho dự án agile), ⚠ #26850 cùng lô (nguồn đơn nhất và nguồn duy nhất), ⚠ #26558 lô 196 (các loại hợp đồng và phân chia rủi ro), ⚠ #26705 lô 199 (điều khoản chấm dứt), ⚠ #26758 lô 200 (thuật ngữ bịa được diễn giải từ câu hỏi).

⚠ CÁC MÔ HÌNH HỢP ĐỒNG cho dự án agile: | Mô hình | Cách hoạt động | |---|---| | ⚠ THỜI GIAN VÀ VẬT TƯ (có hoặc không có trần) | ⚠ trả theo thực tế, dừng lúc nào cũng được — ĐÁP ÁN | | ⚠ Giá cố định theo từng 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 | | ⚠ Điều khoản CHẤM DỨT SỚM | ⚠ có thật, nhưng là một ĐIỀU KHOẢN chứ không phải một loại hợp đồng | | ⚠ Chia sẻ tiết kiệm hoặc chia sẻ rủi ro | ⚠ liên hệ #26693 lô 199 — tinh thần IPD | | ⚠ Điểm chung | ⚠ mọi mô hình agile đều chuyển sự chắc chắn từ PHẠM VI sang NGÂN SÁCH hoặc THỜI GIAN — vì phạm vi chi tiết là thứ được kỳ vọng sẽ thay đổi |

⚠ Vì sao khả năng dừng sớm lại có giá trị: | Lợi ích | Nội dung | |---|---| | ⚠ Khách không bị buộc trả tiền cho phần không còn cần | | | ⚠ Nguồn lực được giải phóng sang việc có giá trị hơn | | | ⚠ Giảm rủi ro cho khách khi bắt đầu dự án | ⚠ nên họ dễ đồng ý khởi động hơn | | ⚠ Tạo áp lực lành mạnh: nhà cung cấp phải liên tục chứng minh giá trị | | | ⚠ Điều nhà cung cấp cần cân nhắc | ⚠ đổi lại, họ mất sự chắc chắn về doanh thu — nên hợp đồng dạng này thường đi kèm thời hạn báo trước và thanh toán cho công việc đang dở, và đó là những điều khoản cần thương lượng kỹ, liên hệ #26678 lô 198 |

⚠ Nhận diện thuật ngữ bịa trong câu hỏi về hợp đồng: | Dấu hiệu | Ví dụ trong câu này | |---|---| | ⚠ Tên là bản diễn giải trực tiếp của câu hỏi | ⚠ "agile early termination contract" | | ⚠ Ghép chữ "agile" với một khái niệm quen thuộc | ⚠ "agile phased development", "agile iteration" | | ⚠ Không xuất hiện trong bất kỳ chuẩn nào | | | ⚠ Cách xử lý | ⚠ tìm phương án nêu tên một loại hợp đồng CÓ THẬT trong quản lý mua sắm — thời gian và vật tư, giá cố định, hoàn phí là ba họ chính, và mọi thứ khác đều nên bị nghi ngờ |

Từ khoá nhận diện:

"khách có thể chấm dứt bất cứ lúc nào" → ⚠ HỢP ĐỒNG THỜI GIAN VÀ VẬT TƯ "agile early termination contract" → ⚠ thuật ngữ bịa; chấm dứt sớm là ĐIỀU KHOẢN, không phải loại hợp đồng "agile phased / agile iteration contract" → ⚠ cũng là tên bịa ba họ hợp đồng có thật → ⚠ thời gian và vật tư, giá cố định, hoàn phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn cho phép dừng ở đâu | | | Nếu dừng, ai trả cho phần đang làm dở | | | Khách hàng của bạn có được đánh giá lại giá trị định kỳ không | |

Và điều mà một hợp đồng cho phép dừng bất cứ lúc nào thật sự trao cho cả hai bên: quyền được thành thật về giá trị ở mỗi vòng lặp — thay vì cùng nhau tiếp tục một dự án mà cả hai đều biết là đã hết ý nghĩa, chỉ vì hợp đồng nói rằng phải làm cho xong.

Đáp án

B — GẶP RIÊNG SAM ĐỂ HỎI XEM MỌI THỨ CÓ ỔN KHÔNG.

Vì sao đúng

⚠ Vì sao đây là bước đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Chất lượng công việc GIẢM nhưng vẫn chấp nhận được | ⚠ giai đoạn sớm — còn kịp can thiệp nhẹ nhàng | | ⚠ Sam ÍT THAM GIA hơn trong các buổi họp | ⚠ hai dấu hiệu cùng lúc, không phải ngẫu nhiên | | ⚠ Sara CHƯA BIẾT nguyên nhân | ⚠ phải hỏi mới biết | | ⚠ Nguyên nhân có thể ở ngoài công việc | ⚠ sức khoẻ, gia đình, kiệt sức, mâu thuẫn trong đội | | ⚠ Gặp RIÊNG bảo vệ thể diện của Sam | ⚠ và tạo không gian để anh nói thật | | ⚠ Kết luận | ⚠ quan tâm trước, kết luận sau — và làm điều đó một cách riêng tư |

⚠ Nguyên tắc: khen công khai, góp ý riêng tư ⚠ — ⚠ và với một dấu hiệu mới chớm như thế này thì thậm chí chưa cần góp ý gì, chỉ cần hỏi thăm.

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

• A (không làm gì, chất lượng vẫn chấp nhận được) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ về mặt kỹ thuật thì đúng: công việc vẫn đạt chuẩn, chưa có tác động nào tới dự án, và can thiệp sớm có thể bị coi là soi mói: ⚠ nhưng ⚠ hai dấu hiệu XUẤT HIỆN CÙNG LÚC là một mô thức, không phải một biến động ngẫu nhiên ⚠ — ⚠ và một cuộc hỏi thăm năm phút gần như không có rủi ro gì, trong khi việc chờ tới lúc chất lượng không còn chấp nhận được sẽ khiến cuộc trò chuyện khó hơn nhiều; ⚠ quản lý con người là công việc phòng ngừa, không phải công việc chữa cháy.

• C (báo cho quản lý của Sam về chất lượng giảm) — ⚠ leo thang khi chưa nói chuyện với chính đương sự; ⚠ phá huỷ lòng tin ngay lập tức.

• D (nhắc cả đội trước mặt mọi người về việc tham gia họp) — ⚠ phê bình gián tiếp trước tập thể; ⚠ ai cũng biết đang nói về ai, và nó vừa không hiệu quả vừa làm Sam mất mặt.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26698 lô 199 (huấn luyện một–một), ⚠ #26846 cùng lô (giám sát mức gắn kết của đội), ⚠ #26833 cùng lô (lắng nghe chủ động), ⚠ #26674 lô 198 (nhịp độ bền vững và nguy cơ kiệt sức), ⚠ #26855 cùng lô (xung đột trong đội có thể là nguyên nhân).

⚠ Các nguyên nhân có thể và cách xử lý tương ứng: | Nguyên nhân | Cách xử lý | |---|---| | ⚠ Vấn đề cá nhân ngoài công việc | ⚠ hỗ trợ, linh hoạt về thời gian, giữ kín | | ⚠ Kiệt sức vì làm quá nhiều | ⚠ giảm tải — liên hệ #26674 lô 198 | | ⚠ Mâu thuẫn với người khác trong đội | ⚠ liên hệ #26855 cùng lô | | ⚠ Mất động lực, thấy công việc vô nghĩa | ⚠ liên hệ #26864 cùng lô — dùng đúng thế mạnh của họ | | ⚠ Đang tìm việc mới | ⚠ cần biết sớm để chuẩn bị chuyển giao | | ⚠ Không rõ kỳ vọng hoặc thấy bị đánh giá thấp | | | ⚠ Vì sao phải HỎI chứ không ĐOÁN | ⚠ sáu nguyên nhân trên dẫn tới sáu phản ứng hoàn toàn khác nhau — và bốn trong số đó sẽ trở nên tệ hơn nếu Sara xử lý theo hướng kỷ luật thay vì hướng hỗ trợ |

⚠ Cách mở đầu cuộc trò chuyện: | Nên | Không nên | |---|---| | ⚠ "Tôi thấy dạo này có vẻ khác, mọi thứ ổn chứ" | ⚠ "Chất lượng công việc của anh đang giảm" | | ⚠ Nêu quan sát cụ thể, không phán xét | ⚠ đưa ra kết luận về nguyên nhân | | ⚠ Để im lặng cho họ có thời gian trả lời | ⚠ lấp đầy khoảng lặng bằng lời của mình | | ⚠ Hỏi xem họ cần gì | ⚠ đưa giải pháp ngay | | ⚠ Điều quan trọng nhất | ⚠ vào cuộc trò chuyện với sự TÒ MÒ chứ không với một kết luận có sẵn — nếu Sara đã tin rằng Sam đang lười thì mọi câu cô hỏi đều sẽ nghe như một lời buộc tội |

⚠ Vì sao can thiệp sớm lại quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề còn nhỏ và còn dễ nói | | | ⚠ Chưa ảnh hưởng tới dự án nên chưa có áp lực | ⚠ cuộc trò chuyện dễ hơn nhiều | | ⚠ Cho thấy người quản lý có để ý tới đội | ⚠ giá trị này lan ra cả đội, không chỉ tới Sam | | ⚠ Nếu là dấu hiệu sắp nghỉ việc thì còn kịp chuẩn bị | | | ⚠ Nhận xét | ⚠ việc Sara nhận ra hai dấu hiệu ở một người trong một đội đang bận rộn là điều đáng ghi nhận — phần lớn vấn đề về con người chỉ được phát hiện khi đã quá muộn để làm gì đó nhẹ nhàng |

Từ khoá nhận diện:

"chất lượng giảm nhẹ và ít tham gia hơn" → ⚠ GẶP RIÊNG hỏi thăm "vẫn chấp nhận được nên không làm gì" → ⚠ bỏ qua một mô thức đang hình thành "báo cho quản lý của họ" → ⚠ leo thang trước khi nói với đương sự "nhắc cả đội" → ⚠ phê bình gián tiếp trước tập thể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có nhận ra khi ai đó trong đội thay đổi không | | | Lần cuối bạn hỏi thăm một thành viên mà không vì công việc là khi nào | | | Đội bạn có tin rằng nói ra khó khăn là an toàn không | |

Và điều mà một cuộc trò chuyện năm phút có thể phát hiện: một vấn đề mà Sam không biết phải bắt đầu nói ra thế nào — và trong phần lớn trường hợp, việc có người hỏi đã là một nửa của giải pháp.

Đáp án

B — TÍNH CÁCH (personality).

Vì sao đúng

⚠ Vì sao vấn đề nằm ở tính cách của Demetrius: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Anh có quan điểm CỨNG RẮN về ưu tiên dự án | ⚠ không mở với ý kiến khác | | ⚠ Anh nói người khác "không biết chuyện gì đang xảy ra" | ⚠ hạ thấp đồng nghiệp | | ⚠ Anh chê người khác "quá rụt rè" | ⚠ quy vấn đề về người khác | | ⚠ Bên liên quan THẤY KHÓ nêu ý tưởng khác với anh | ⚠ tác động thật lên dự án | | ⚠ Người quản lý cũ phải dặn riêng trước khi nghỉ | ⚠ đây là vấn đề đã tồn tại lâu | | ⚠ Kết luận | ⚠ cách hành xử của một cá nhân đang chi phối luồng ý tưởng của cả dự án |

⚠ Điều đáng chú ý: ⚠ Demetrius có tri thức tổ chức thật và sự tự tin thật — vấn đề không phải năng lực mà là cách năng lực đó được thể hiện ⚠ — ⚠ liên hệ #26760 lô 200, nơi một chuyên gia nói nhiều làm nhóm mất tiếng nói.

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

• A (ưu tiên của dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đề mở đầu bằng việc Demetrius có "quan điểm cứng rắn về ưu tiên của dự án", nên chủ đề bề mặt đúng là ưu tiên: ⚠ nhưng ⚠ không ai trong đề nói rằng các ưu tiên đó SAI ⚠ — ⚠ vấn đề là không ai dám đề xuất ý tưởng khác, tức là vấn đề nằm ở CÁCH TRAO ĐỔI chứ không ở NỘI DUNG ưu tiên; ⚠ nếu chỉ sửa danh sách ưu tiên thì tình trạng vẫn lặp lại ở lần tiếp theo.

• C (khác biệt văn hoá) — ⚠ đề không nhắc tới yếu tố văn hoá nào; ⚠ liên hệ #26681 lô 198, nơi khác biệt văn hoá mới thật sự là nguyên nhân.

• D (môi trường đội) — ⚠ môi trường đội là HỆ QUẢ; ⚠ nó xấu đi vì cách hành xử của một người, nên đó chưa phải nguyên nhân gốc.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bị CẮT CỤT ở cuối ("…if they differ from ideas that Demetrius adv…") ⚠ — ⚠ ý còn dở là "khác với những ý tưởng mà Demetrius ủng hộ"; ⚠ khoá được giữ nguyên vì phần đề còn lại đã mô tả rõ mô thức hành vi.

⚠ Đối chiếu: ⚠ #26760 lô 200 (một người nói át trong hội thảo — sửa cấu trúc thay vì sửa người), ⚠ #26772 lô 201 (kiểu tính cách D trong DiSC), ⚠ #26852 cùng lô (gặp riêng từng bên liên quan), ⚠ #26855 cùng lô (xung đột quan hệ), ⚠ #26688 lô 199 (viết thầm để chống hiệu ứng neo).

⚠ Tanya nên xử lý thế nào: | Bước | Việc | |---|---| | ⚠ Tự quan sát trước khi kết luận | ⚠ cô mới nhận dự án, và lời dặn của người tiền nhiệm là một góc nhìn chứ chưa phải sự thật | | ⚠ Gặp riêng các bên liên quan để nghe | ⚠ liên hệ #26852 cùng lô — họ đã chủ động chia sẻ | | ⚠ Thay đổi CẤU TRÚC các buổi thảo luận | ⚠ viết thầm, vòng tròn — liên hệ #26688 lô 199 và #26760 lô 200 | | ⚠ Gặp riêng Demetrius, nêu quan sát cụ thể | ⚠ không quy chụp về tính cách, nói về TÁC ĐỘNG của hành vi | | ⚠ Tận dụng thế mạnh thật của anh | ⚠ tri thức tổ chức là tài sản — liên hệ #26864 cùng lô | | ⚠ Cách nói hiệu quả nhất với Demetrius | ⚠ "kinh nghiệm của anh rất quý, nhưng khi anh nêu quan điểm đầu tiên thì người khác thôi đề xuất — tôi muốn nghe cả hai" — nói về HÀNH VI và TÁC ĐỘNG, không nói về con người anh |

⚠ Vì sao sửa CẤU TRÚC hiệu quả hơn sửa CON NGƯỜI: | Lý do | Nội dung | |---|---| | ⚠ Không ai bị nhắm tới nên không có phản kháng | ⚠ liên hệ #26760 lô 200 | | ⚠ Có tác dụng ngay ở buổi họp tiếp theo | | | ⚠ Giúp cả những người rụt rè khác, không chỉ vấn đề với một người | | | ⚠ Không cần Demetrius phải thay đổi tính cách | ⚠ điều gần như không xảy ra trong một dự án | | ⚠ Kết hợp tốt nhất | ⚠ đổi cấu trúc buổi họp TRƯỚC, rồi mới gặp riêng nếu vấn đề vẫn còn — làm ngược thứ tự thường dẫn tới một cuộc trò chuyện căng thẳng mà chưa cần thiết |

Từ khoá nhận diện:

"một người áp đặt, người khác ngại nêu ý kiến khác" → ⚠ TÍNH CÁCH "ưu tiên dự án" → ⚠ chủ đề bề mặt, không phải nguyên nhân "môi trường đội" → ⚠ hệ quả, không phải nguyên nhân gốc "khác biệt văn hoá" → ⚠ không có căn cứ trong đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong đội bạn có ai mà người khác ngại phản đối không | | | Ý tưởng cuối cùng được chọn có phải luôn của cùng một người không | | | Buổi họp của bạn có cấu trúc chống hiệu ứng neo không | |

Và điều mà một người có tri thức và sự tự tin hiếm khi nhận ra về chính mình: sự chắc chắn của họ không thuyết phục người khác đồng ý — nó chỉ khiến người khác thôi nói ra điều họ đang nghĩ, và cả hai bên đều ghi nhận sự im lặng đó là sự đồng thuận.

Đáp án

C — ĐỊNH NGHĨA SẴN SÀNG (definition of ready).

Vì sao đúng

⚠ Vì sao đây là nơi đúng để ghi quy tắc mới: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ "Mọi phụ thuộc phải được đáp ứng TRƯỚC KHI hạng mục được nhận vào vòng lặp" | ⚠ điều kiện để BẮT ĐẦU — đúng định nghĩa sẵn sàng | | ⚠ Đội quyết định điều này trong buổi hồi cứu | ⚠ một cải tiến quy trình, thuộc về đội | | ⚠ Vấn đề là bị KẸT giữa chừng vì phụ thuộc bên ngoài | ⚠ cách chữa là chặn từ cửa vào | | ⚠ Kết luận | ⚠ định nghĩa sẵn sàng là bộ lọc ở đầu vào của vòng lặp |

⚠ Cặp khái niệm cần nhớ: ⚠ ĐỊNH NGHĨA SẴN SÀNG là điều kiện để hạng mục ĐƯỢC VÀO vòng lặp; ĐỊNH NGHĨA HOÀN THÀNH là điều kiện để nó ĐƯỢC RA ⚠ — ⚠ liên hệ #26748 lô 200.

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

• B (tiêu chí nghiệm thu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ tiêu chí nghiệm thu cũng là một bộ điều kiện gắn với từng hạng mục, nên nghe rất gần: ⚠ nhưng ⚠ tiêu chí nghiệm thu mô tả hạng mục phải LÀM ĐƯỢC GÌ để khách chấp nhận — nó nói về KẾT QUẢ ⚠ — ⚠ còn quy tắc trong đề nói về ĐIỀU KIỆN ĐỂ BẮT ĐẦU, và nó áp cho MỌI hạng mục chứ không riêng hạng mục nào; ⚠ thứ áp cho mọi hạng mục thì thuộc về định nghĩa sẵn sàng hoặc định nghĩa hoàn thành, không thuộc tiêu chí nghiệm thu.

• A (tồn đọng vòng lặp) — ⚠ là DANH SÁCH công việc của vòng lặp; ⚠ nó chứa hạng mục chứ không chứa quy tắc.

• D (definition of nearly done) — ⚠ thuật ngữ BỊA; ⚠ và bản thân khái niệm "gần xong" đi ngược tinh thần nhị phân của định nghĩa hoàn thành.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26748 lô 200 (định nghĩa hoàn thành), ⚠ #26841 cùng lô (vận tốc sụt vì một hạng mục bị kẹt), ⚠ #26834 cùng lô (cải tiến liên tục qua hồi cứu), ⚠ #26789 lô 201 (tinh chỉnh tồn đọng), ⚠ #26765 lô 200 (chia nhỏ hạng mục).

⚠ BA BỘ TIÊU CHÍ trong agile — bảng phân biệt: | Tiêu chí | Áp cho | Trả lời câu hỏi | |---|---|---| | ⚠ ĐỊNH NGHĨA SẴN SÀNG | ⚠ MỌI hạng mục, trước khi vào vòng lặp — ĐÁP ÁN | ⚠ "đã đủ điều kiện để bắt đầu chưa" | | ⚠ TIÊU CHÍ NGHIỆM THU | ⚠ RIÊNG từng hạng mục | ⚠ "hạng mục này phải làm được gì" | | ⚠ ĐỊNH NGHĨA HOÀN THÀNH | ⚠ MỌI hạng mục, trước khi coi là xong | ⚠ "đã đủ điều kiện để kết thúc chưa" | | ⚠ Cách nhớ | ⚠ hai định nghĩa là bộ lọc ở CỬA VÀO và CỬA RA, áp chung cho tất cả; tiêu chí nghiệm thu là nội dung riêng của từng hạng mục |

⚠ ĐỊNH NGHĨA SẴN SÀNG thường gồm những gì: | Điều kiện | Nội dung | |---|---| | ⚠ Hạng mục được mô tả rõ ràng | ⚠ đội hiểu phải làm gì | | ⚠ Có TIÊU CHÍ NGHIỆM THU | ⚠ hai khái niệm nối vào nhau ở đây | | ⚠ Đã được ƯỚC LƯỢNG | | | ⚠ Đủ NHỎ để vừa một vòng lặp | ⚠ liên hệ #26765 lô 200 | | ⚠ Mọi PHỤ THUỘC đã được giải quyết | ⚠ điều đội trong đề vừa thêm vào | | ⚠ Có sẵn dữ liệu, môi trường, quyền truy cập cần thiết | | | ⚠ Giá trị lớn nhất | ⚠ nó ngăn đội cam kết một thứ mà họ không kiểm soát được — và đó chính xác là vấn đề đã làm họ bị kẹt nhiều lần trong vòng lặp vừa qua |

⚠ Rủi ro nếu định nghĩa sẵn sàng quá chặt: | Rủi ro | Nội dung | |---|---| | ⚠ Không hạng mục nào đủ điều kiện để bắt đầu | ⚠ đội đứng hình chờ | | ⚠ Biến thành một cổng phê duyệt nặng nề | ⚠ đi ngược tinh thần agile | | ⚠ Đẩy công việc chuẩn bị lên quá sớm | ⚠ trái với nguyên tắc đúng lúc — liên hệ #26847 cùng lô | | ⚠ Cân bằng đúng | ⚠ định nghĩa sẵn sàng nên đủ chặt để đội không bị kẹt, và đủ lỏng để công việc vẫn chảy — nó cũng nên được rà lại trong hồi cứu như mọi quy ước khác |

Từ khoá nhận diện:

"điều kiện để hạng mục ĐƯỢC NHẬN vào vòng lặp" → ⚠ ĐỊNH NGHĨA SẴN SÀNG "điều kiện để coi là XONG" → ⚠ định nghĩa hoàn thành "hạng mục này phải làm được gì" → ⚠ tiêu chí nghiệm thu "definition of nearly done" → ⚠ thuật ngữ bịa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có định nghĩa sẵn sàng không | | | Có hạng mục nào từng bị kẹt vì phụ thuộc chưa xong không | | | Định nghĩa của bạn có bị coi là một cổng phê duyệt không | |

Và điều mà một quy tắc do chính đội đặt ra trong buổi hồi cứu thể hiện: họ đã ngừng chịu đựng việc bị kẹt như một điều không tránh được, và bắt đầu coi nó là thứ có thể chặn từ cửa vào.

Đáp án

A — CẬP NHẬT NHẬT KÝ THAY ĐỔI (change log).

Vì sao đúng

⚠ Vì sao đây là việc đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Nhật ký thay đổi ghi MỌI yêu cầu và KẾT QUẢ của nó | ⚠ kể cả yêu cầu bị TỪ CHỐI | | ⚠ Quyết định vừa được đưa ra, phải ghi ngay | ⚠ để không ai phải đoán về sau | | ⚠ Đây là việc NHANH và không phụ thuộc gì khác | ⚠ làm trước rồi mới tính tiếp | | ⚠ Nó tạo cơ sở cho mọi bước tiếp theo | ⚠ có hồ sơ thì việc leo thang mới có căn cứ | | ⚠ Kết luận | ⚠ ghi nhận quyết định là bước đầu tiên, tìm phương án là bước sau |

⚠ Vì sao phải ghi cả yêu cầu bị từ chối: ⚠ để về sau biết được vấn đề đã từng được nêu, ai quyết định và vì sao ⚠ — ⚠ nếu tiến độ trễ vì thiếu vật liệu, hồ sơ này chính là bằng chứng rằng Austin đã cảnh báo trước.

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

• D (tìm một cách khắc phục tạm) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là hành động thực chất nhất: yêu cầu bị từ chối thì phải tìm cách khác, và Austin đang lo về tiến độ: ⚠ nhưng ⚠ câu hỏi hỏi việc làm ĐẦU TIÊN, và ghi nhật ký mất một phút trong khi tìm phương án mất nhiều ngày ⚠ — ⚠ quan trọng hơn: nếu không ghi lại quyết định từ chối thì ba tháng sau, khi dự án trễ, sẽ không ai nhớ rằng đã từng có một yêu cầu bị bác; ⚠ tìm cách khắc phục chắc chắn phải làm, chỉ là không phải việc đầu tiên.

• B (báo cho nhà tài trợ) — ⚠ cần thiết nếu tác động lớn, nhưng nên làm SAU khi đã ghi nhận và đánh giá được tác động; ⚠ báo cáo tay không thì nhà tài trợ cũng không quyết được gì.

• C (tìm nhà cung cấp khác để làm việc đó) — ⚠ một phương án cụ thể trong nhiều phương án; ⚠ chưa phân tích thì chưa nên chọn.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26843 cùng lô (hệ thống theo dõi yêu cầu thay đổi), ⚠ #26836 cùng lô (kế hoạch quản lý thay đổi), ⚠ #26801 lô 201 (ghi lại yêu cầu thay đổi ngay khi nhận), ⚠ #26866 cùng lô (đưa việc phát sinh ra ban kiểm soát thay đổi), ⚠ #26875 cùng lô (cập nhật đường cơ sở sau khi duyệt).

⚠ NHẬT KÝ THAY ĐỔI ghi những gì: | Trường | Nội dung | |---|---| | ⚠ Mã số và mô tả yêu cầu | | | ⚠ Người đề xuất và ngày đề xuất | | | ⚠ Tác động được đánh giá | ⚠ chi phí, tiến độ, phạm vi, rủi ro | | ⚠ QUYẾT ĐỊNH: duyệt, từ chối, hoãn | ⚠ trường quan trọng nhất trong tình huống này | | ⚠ LÝ DO của quyết định | ⚠ thứ mà ba tháng sau không ai còn nhớ | | ⚠ Ngày quyết định và người quyết định | | | ⚠ Hành động tiếp theo | | | ⚠ Vì sao trường LÝ DO quan trọng nhất | ⚠ một yêu cầu bị từ chối mà không ghi lý do sẽ được nộp lại sau vài tháng bởi người khác — và cả chu trình lặp lại từ đầu |

⚠ Austin nên làm gì sau khi cập nhật nhật ký: | Bước | Việc | |---|---| | ⚠ Đánh giá tác động thật của việc bị từ chối | ⚠ tiến độ trễ bao lâu, chi phí thêm bao nhiêu | | ⚠ Tìm hiểu LÝ DO bị từ chối | ⚠ có thể mở ra một phương án khác được chấp nhận | | ⚠ Tìm các phương án thay thế | ⚠ phương án C và D thuộc bước này | | ⚠ Cập nhật sổ rủi ro và tiến độ | | | ⚠ Báo cáo cho nhà tài trợ nếu tác động vượt ngưỡng | ⚠ phương án B thuộc bước này | | ⚠ Điểm đáng lưu ý | ⚠ việc chờ vài ngày mới có quyết định cũng là một dữ liệu — nếu ban kiểm soát thay đổi thường xuyên chậm thì đó là một vấn đề quy trình đáng đưa vào hồi cứu, liên hệ #26836 cùng lô về nhịp họp của ban |

Từ khoá nhận diện:

"yêu cầu thay đổi bị từ chối" → ⚠ CẬP NHẬT NHẬT KÝ THAY ĐỔI trước "tìm cách khắc phục" → ⚠ cần thiết nhưng không phải việc đầu tiên "báo nhà tài trợ" → ⚠ sau khi đã có đánh giá tác động nguyên tắc → ⚠ ghi nhận MỌI yêu cầu và MỌI quyết định, kể cả từ chối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhật ký thay đổi của bạn có ghi các yêu cầu bị từ chối không | | | Nó có ghi LÝ DO của quyết định không | | | Một yêu cầu mất trung bình bao lâu để có quyết định | |

Và điều mà một dòng ghi chép ngay sau khi nhận tin từ chối bảo vệ: không phải Austin, mà là cả tổ chức — vì sáu tháng nữa, khi có người hỏi vì sao dự án dùng loại vật liệu này, câu trả lời vẫn còn ở đó cùng với tên người đã quyết định.