Tay poker hàng đầu dạy FDE trả lời câu "chắc chạy được không?"

Một người chơi poker ở đẳng cấp hàng đầu thế giới suốt hai thập kỷ viết sách về cách ra quyết định. Câu đáng nhớ nhất trong phần giới thiệu sách của nhà xuất bản không phải bí quyết thắng mà là một lời thừa nhận: quyết định tốt nhất cũng không phải lần nào cũng mang lại kết quả tốt nhất.

Với một FDE, câu đó gần như là mô tả công việc.

Bạn ngồi ở chỗ khách, dữ liệu thiếu, hệ thống cũ chưa ai vẽ sơ đồ, vậy mà khách vẫn hỏi “bao giờ xong, có chạy được không”. Thinking in Bets không phải sách kỹ thuật, nhưng nó luyện cho bạn một kỹ năng mà ít engineer được dạy: nói thật về sự bất định mà khách vẫn tin bạn.

Ai viết, và cuốn sách cược vào điều gì?

Tên đầy đủ của sách là Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts, do Portfolio, một imprint của Penguin Random House, xuất bản. Bản bìa cứng và ebook ra ngày 6/2/2018, bản bìa mềm ngày 7/5/2019. Sách viết cho độc giả phổ thông và từng lọt danh sách bán chạy toàn quốc ở Mỹ.

Annie Duke không chỉ là dân poker. Bà từng nhận học bổng của National Science Foundation để học tâm lý học nhận thức tại University of Pennsylvania. Năm 2014, bà đồng sáng lập Alliance for Decision Education. Vì thế cuốn sách vừa có kinh nghiệm bàn chơi, vừa có nền tâm lý học.

Luận điểm gốc khá gọn. Mọi quyết định đều chịu hai nguồn bất định: may rủi mà bạn không điều khiển được, và thông tin bị che khuất khỏi tầm nhìn. Duke cho rằng mỗi lần quyết định là ta đặt cược thứ mình coi trọng, không chỉ tiền. Với FDE, thứ đặt cược là thời gian của khách, uy tín của bạn và niềm tin vào sản phẩm.

Ý thứ nhất: kết quả tốt chưa chứng minh được gì

Duke đặt tên cho một lỗi là “resulting”: xu hướng đánh đồng chất lượng một quyết định với chất lượng kết quả của nó. Kết quả tốt có khi chỉ là may, và khi đó bạn không học được gì.

Thử hình dung một nhóm đưa pipeline lên môi trường của khách mà không thử trên dữ liệu thật, rồi buổi demo vẫn trôi chảy. Cả nhóm kết luận quy trình ổn. Theo cách nhìn của Duke, đó là resulting: lần sau dữ liệu bẩn hơn, quy trình ấy sẽ sập.

Trường hợp ngược lại cũng dễ khiến bạn rút sai bài học. Giả sử nhóm đã thử kỹ trên dữ liệu thật và có sẵn kế hoạch rollback, rồi API của bên thứ ba sập đúng ngày go-live. Quyết định vẫn đúng với những gì nhóm biết lúc đó; thứ hỏng là phần may rủi nằm ngoài tầm tay.

Đừng vứt bỏ cả quy trình chỉ vì một kết quả xấu.

Ở buổi retro tới, hãy kẻ hai cột: điều cả nhóm biết vào lúc quyết định, và điều thuộc về may rủi. Chỉ cột đầu mới cho bạn bài học.

Ý thứ hai: nói bằng xác suất, đừng hứa

Duke nhắc rằng rất ít chuyện có khả năng xảy ra 0% hay 100%. Bà coi việc thể hiện đúng mức hiểu biết của mình là một phần của quy trình quyết định tốt. Mức hiểu biết đó thường là “chưa chắc”, và nói ra điều này không có gì đáng xấu hổ.

Một phép tính nhỏ cho thấy cách nói này có ích ra sao. Thay vì hứa “agent sẽ cắt 30% thời gian xử lý ticket”, hãy viết “70% khả năng đạt mức giảm 30% trong sáu tuần”.

Nếu bạn đưa ra 10 ước tính như vậy, khoảng 7 cái phải đạt. Cả 10 đều đạt nghĩa là bạn đang quá dè dặt. Chỉ 4 cái đạt nghĩa là bạn đang quá tự tin.

Khách cũng nhận được thứ để lên kế hoạch. Còn 30% khả năng trượt thì họ biết phải chuẩn bị phương án dự phòng, thay vì bị bất ngờ ở tuần thứ sáu. Một file log ghi các ước tính qua nhiều dự án sẽ dần cho thấy con số của bạn đáng tin đến đâu.

Ý thứ ba: tìm người hỏi vặn trước khi gặp khách

Duke đề xuất lập “decision group”, một nhóm nhỏ giúp các niềm tin nằm sau quyết định được nói ra rõ ràng cho mọi thành viên. FDE thường làm việc một mình ở chỗ khách, nên rất dễ đem một giả định chưa ai kiểm tra vào phòng họp.

Cách làm đơn giản: trước mỗi báo cáo tuần, nhờ một FDE khác hoặc người bên đội product hỏi bạn “vì sao 70 mà không phải 50?”. Nếu bạn không trả lời được, con số đó chưa sẵn sàng để đưa cho khách.

Ai nên đọc, và đọc thế nào?

Cuốn sách hợp nhất với FDE đang phải viết báo cáo tiến độ cho khách, và với software engineer đang muốn chuyển sang FDE, vì đây là lỗ hổng mà nghề SWE ít khi buộc bạn lấp. Đừng tìm ở đây công thức eval hay kỹ thuật thống kê; giá trị của nó với FDE nằm ở tư duy giúp bạn dùng các công cụ đó một cách trung thực.

Hãy đọc trước dự án tiếp theo. Đọc xong mỗi ý, áp ngay vào một quyết định thật của tuần đó. Về sự nghiệp, khi phỏng vấn mà bị hỏi về một dự án thất bại, hãy tách rõ phần quyết định với phần may rủi.

Cách trả lời đó cho người phỏng vấn thấy bạn biết rút bài học đúng chỗ, thay vì đổ lỗi hay tự khen. Trên CV, một dòng như “đưa ra dự báo xác suất cho tiến độ deployment và theo dõi độ chính xác qua các dự án” sẽ có sức nặng hơn nếu bạn ghi đúng số dự án mình đã thực sự theo dõi.

Khách không trả tiền để bạn lúc nào cũng đúng. Họ trả tiền để bạn nói rõ mình đang cược vào điều gì, và cơ hội thắng là bao nhiêu.