Pre-mortem trước go-live: buổi họp 30 phút để khách nói ra điều họ đang giấu

Còn hai tuần nữa là go-live. Trong buổi họp steering, từng người báo cáo xong phần mình: tích hợp chạy rồi, eval đạt ngưỡng, đội vận hành đã được đào tạo. Không ai phản đối. Nhưng kinh nghiệm cho bạn biết, một cuộc họp suôn sẻ tới mức đó thường đang có điều bị bỏ qua.

Gary Klein, nhà tâm lý học đã phát triển phương pháp pre-mortem từ khoảng 30 năm trước (tính đến năm 2021), giải thích hiện tượng này khá thẳng.

Trong các cuộc họp như vậy luôn có một áp lực ngầm: không ai muốn nêu nghi ngờ vì sợ làm xáo trộn sự hòa thuận của nhóm. Với FDE thì áp lực còn lớn hơn, vì có hai tổ chức ngồi chung bàn, và chẳng ai muốn là người làm bên kia mất mặt.

Bạn là người đứng giữa hai bên, nên bạn cũng là người hợp nhất để phá sự im lặng đó. Pre-mortem là công cụ rẻ nhất để làm việc này. Nó không đòi bạn có quyền hành gì đặc biệt, chỉ cần bạn biết điều phối một buổi họp.

Một câu hỏi đổi hẳn cách mọi người nói

Hỏi “dự án này có thể sai ở đâu?” thì thường chỉ nhận về những câu trả lời an toàn. Pre-mortem đặt câu hỏi khác.

Theo Klein, người điều phối nói với cả nhóm rằng kế hoạch vừa bàn đã thất bại, rồi để từng người tự viết ra lý do. Bài viết năm 2007 của ông trên Harvard Business Review cũng xoay quanh giả định ấy: dự án đang lên kế hoạch vừa thất bại.

Wikipedia dùng hình ảnh y khoa để so sánh. Một buổi phê bình kế hoạch thông thường hỏi bệnh nhân có thể gặp chuyện gì. Pre-mortem thì coi như bệnh nhân đã chết và hỏi vì sao chết.

Kỹ thuật này dựa trên nghiên cứu về “prospective hindsight” của Mitchell, Russo và Pennington năm 1989, tức là đứng ở một tương lai tưởng tượng rồi nhìn ngược lại.

Chỗ hay nhất nằm ở động cơ của người tham gia. Klein nhận xét rằng khi thất bại được coi là chuyện đã xảy ra, người ta thể hiện sự thông minh của mình qua chất lượng của vấn đề họ nêu ra. Lúc đó, nói ra rủi ro không còn bị xem là thiếu tin tưởng vào dự án, mà là đóng góp.

Diễn tập một buổi 30 phút với khách hàng

Thử hình dung một tình huống. Bạn đang triển khai một agent LLM phân loại hồ sơ bồi thường cho một công ty bảo hiểm. Người tham dự gồm sponsor phía khách, trưởng nhóm vận hành, một kỹ sư IT phụ trách hệ thống lõi, một chuyên viên xử lý hồ sơ và bạn.

Klein cho rằng một buổi như vậy có thể chỉ mất 20-30 phút. Kịch bản dưới đây giữ phần viết riêng và đi từng lượt theo cách của Klein. Hai bước cuối, bỏ phiếu và giao việc, lấy từ bản mẫu của Atlassian và cách làm của đội y tế số chính phủ Anh.

Phút 0-3, mở đầu. Bạn đọc nguyên văn câu đã chuẩn bị: “Hôm nay là ba tháng sau go-live. Dự án đã thất bại: agent bị tắt và nhân viên quay lại làm thủ công. Mỗi người hãy viết ra những lý do khiến chuyện này xảy ra.”

Câu này cần được nói ở thì quá khứ và thật cụ thể. Nếu bạn nói “giả sử có thể thất bại”, hiệu ứng sẽ mất ngay.

Phút 3-8, viết riêng, không trao đổi. Mỗi người tự viết lý do của mình. Bước im lặng này quan trọng, vì nó giúp nhân viên tuyến đầu không bị cuốn theo ý kiến của sponsor.

Đội y tế số của chính phủ Anh làm thêm một bước ở giai đoạn này: chia phòng thành “đội thảm họa” và “đội thành công”. Với năm người, bạn có thể nhờ một hai người viết về kịch bản ngược lại: ba tháng sau, agent thành công, vì sao?

Những câu trả lời như “chuyên viên tin agent vì thấy được lý do phân loại” cho bạn biết điều gì phải giữ nguyên trong scope, đừng cắt khi bị dồn tiến độ.

Phút 8-20, đi từng lượt. Klein khuyên người dẫn dắt nói trước một cách thẳng thắn để làm gương, và mỗi lượt mỗi người chỉ nêu một lý do. Bạn có thể mở màn bằng một điểm yếu của chính mình: “Bộ eval của tôi lấy từ hồ sơ năm ngoái, và quy định phân loại năm nay đã khác.”

Sau đó, có thể chuyên viên xử lý hồ sơ sẽ nói rằng nhân viên không tin agent nên kiểm tra lại toàn bộ, và thế là chẳng tiết kiệm được thời gian. Kỹ sư IT có thể nhắc rằng hệ thống lõi giới hạn số lượt gọi API vào giờ cao điểm. Những điều như vậy hiếm khi được nói ra trong một buổi họp steering bình thường.

Phút 20-25, bỏ phiếu. Danh sách thường dài hơn khả năng xử lý của bạn. Đội y tế số Anh cho mọi người dán chấm bỏ phiếu chọn ba rủi ro và ba cơ hội lớn nhất. Bạn làm tương tự: ba rủi ro thành việc cần sửa, ba cơ hội thành những điều cần bảo vệ trong kế hoạch go-live.

Phút 25-30, giao việc. Mỗi rủi ro trong top ba phải có một người chịu trách nhiệm và một hạn xử lý. Trong tình huống bảo hiểm, ví dụ có thể như sau: bạn bổ sung 200 hồ sơ theo quy định mới vào eval trước thứ Sáu.

Trưởng nhóm vận hành chọn hai nhân viên chạy thử song song trong một tuần. Kỹ sư IT xác nhận giới hạn API, còn bạn thêm hàng đợi.

Bản mẫu có sẵn, nhưng phải chỉnh cho bối cảnh khách hàng

Với dự án lớn và nhiều bên, Team Playbook của Atlassian có bản dài hơn dùng được ngay: 3-11 người, khoảng 60 phút, có bước brainstorm im lặng, bỏ phiếu chọn rủi ro hàng đầu và giao việc kèm người chịu trách nhiệm cùng hạn chót.

Ở phía khách hàng, bạn cần chỉnh thêm hai điểm. Một là mời đúng người dùng thật, vì sponsor hiếm khi biết agent sẽ hỏng ở đâu trong công việc hằng ngày. Hai là tổ chức buổi này sớm, khoảng hai tuần trước go-live, để còn thời gian sửa; họp một ngày trước go-live thì chỉ làm mọi người thêm lo.

Bài học từ đội y tế số Anh cho thấy giá trị nằm ở hành động. Colin Pattinson viết rằng buổi họp làm lộ ra những rủi ro không ai ngờ tới, và đội đã kịp xử lý vài rủi ro trong số đó. Theo ông, pre-mortem buộc bạn đối mặt với vấn đề trước khi nó phá hỏng dự án về sau.

Những lỗi biến pre-mortem thành buổi than phiền

Lỗi phổ biến nhất là nói “có thể thất bại” thay vì “đã thất bại”. Chỉ một chữ thôi, nhưng người nghe sẽ quay về tâm thế phòng thủ, và bạn lại nhận về những câu trả lời an toàn.

Lỗi thứ hai là để người có chức vụ cao nhất nói trước bằng một lý do vô hại, kiểu “có thể chúng ta thiếu thời gian”.

Klein muốn người dẫn dắt nói trước để cả phòng dám nói thẳng theo. Một lý do vô hại ở lượt đầu lại ra tín hiệu ngược: ở đây chỉ nên nói nhẹ. Vì thế, hãy thống nhất trước với sponsor rằng lý do đầu tiên phải là một điều thật sự khó chịu, hoặc bạn tự nói trước.

Lỗi thứ ba là kết thúc buổi họp với 30 rủi ro mà không có ai chịu trách nhiệm. Một danh sách không có người và hạn xử lý chỉ ghi lại nỗi lo của mọi người. Lỗi cuối cùng là chỉ mời đội của bạn. Khi đó, bạn chỉ nghe được những rủi ro mà bạn đã biết sẵn.

Biến buổi họp thành bằng chứng trong CV

Nếu mô tả công việc FDE bạn nhắm tới nhắc đến làm việc với stakeholder hay quản lý rủi ro, một buổi pre-mortem bạn từng điều phối là bằng chứng tốt cho năng lực đó. Nhưng chỉ khi bạn kể được nó đã thay đổi điều gì.

Lấy lại tình huống bảo hiểm. Dòng CV yếu sẽ là “Tổ chức pre-mortem trước go-live”.

Dòng CV mạnh ghi rõ ai tham gia, phát hiện gì và đã sửa gì: “Điều phối pre-mortem với 4 người phía khách hai tuần trước go-live; phát hiện eval lệch quy định mới và giới hạn API giờ cao điểm của hệ thống lõi, xử lý cả hai trước ngày chạy.”

Trong phỏng vấn, câu hỏi “kể về một lần bạn ngăn được sự cố” là chỗ để kể chi tiết. Hãy nói câu mở đầu bạn đã dùng, lý do của chuyên viên xử lý hồ sơ mà sponsor chưa từng nghe, và việc chạy thử song song sau đó.

Người phỏng vấn muốn thấy bạn chủ động tìm ra vấn đề, chứ không chỉ chữa cháy sau khi nó xảy ra.

Lần tới khi một buổi họp steering diễn ra suôn sẻ đáng ngờ, bạn không cần tranh cãi với ai. Chỉ cần hỏi cả phòng: nếu ba tháng nữa agent đã bị tắt, mọi người nghĩ vì sao?