Dẫn dắt chuyển đổi từ tất định sang xác suất

Vấn đề không nằm ở công nghệ — nó nằm ở phản xạ

Rất nhiều lãnh đạo dày dạn đang gặp khó với sản phẩm AI, và gần như không ai trong số đó gặp khó vì không hiểu công nghệ. Họ đọc tài liệu, họ dự hội thảo, họ hiểu khái niệm.

Cái vướng nằm ở chỗ khác: hai mươi năm qua đã rèn cho họ một bộ phản xạ, và bộ phản xạ đó đã tốt tới mức không còn được suy nghĩ nữa. "Chưa ổn định thì chưa ra mắt." "Kết quả không nhất quán là lỗi nghiêm trọng." "Đưa tôi cam kết chắc chắn." Những câu đó đã đúng suốt sự nghiệp của họ, và chúng vẫn đúng với phần lớn hệ thống công ty đang vận hành.

Chúng chỉ sai với đúng một loại sản phẩm — và không may, đó là loại sản phẩm sắp quyết định vị thế của công ty.

Vì sao người trẻ có lợi thế ở đây không phải vì họ giỏi hơn. Họ chỉ không có gì phải gỡ bỏ. Đúng như điều đã xảy ra khoảng năm 2010, khi người hiểu rằng giá trị của sản phẩm đến từ hành vi của người dùng với nhau — chứ không từ danh sách tính năng — đã đi trước một quãng rất dài.

Kỹ năng này dành cho người ở phía có nhiều thứ phải gỡ bỏ. Nó không nói kinh nghiệm của bạn là vô dụng — phần lớn kinh nghiệm đó vẫn cực kỳ giá trị. Nó chỉ tách ra phần nào còn dùng được và phần nào đang dẫn bạn đi sai.

Phần kinh nghiệm của bạn VẪN đúng — và nó quan trọng hơn người ta nghĩ

Bắt đầu từ đây, vì phần lớn lời bàn về AI bỏ qua nó và khiến người có kinh nghiệm cảm thấy toàn bộ vốn liếng của mình bị phủ định. Điều đó không đúng.

Phần phải gỡ bỏ hẹp hơn nhiều so với cảm giác ban đầu. Nó chỉ gồm những phản xạ về điều gì được coi là chạy được và điều gì được coi là xong. Mọi thứ khác đều chuyển sang nguyên vẹn.

Bốn phản xạ cần gỡ — và câu thay thế

Phản xạ thứ ba là phản xạ nguy hiểm nhất ở cấp lãnh đạo, vì nó dẫn tới những cam kết công khai không giữ được. Một buổi demo AI là một mẫu cỡ một, và nó thường được chuẩn bị bằng những ca chạy tốt. Thói quen "tôi đã tận mắt thấy nó chạy" — vốn là một cách kiểm tra rất hợp lý suốt hai mươi năm — không còn giá trị chứng minh ở đây.

Dẫn đội qua chuyển đổi — sáu việc cụ thể

• 1. Tự nói ra phản xạ của mình, công khai. "Bản năng của tôi là đòi các bạn đảm bảo nó không sai. Với loại sản phẩm này, đòi hỏi đó không có nghĩa, nên tôi sẽ tập hỏi khác." Một câu như vậy từ người dẫn đầu cho phép cả đội nói thật về những gì họ cũng đang phải gỡ bỏ. Không có bước này, mọi bước sau đều chậm.
• 2. Đổi câu hỏi bạn hỏi trong các buổi rà soát. Đội sẽ chuẩn bị theo đúng thứ bạn hỏi. Hỏi "xong chưa" thì họ báo cáo tiến độ; hỏi "phân phối kết quả ra sao, nhóm ca nào yếu nhất" thì họ đi tìm câu trả lời đó — và đó chính là công việc bạn muốn họ làm.
• 3. Đưa quyết định ngưỡng về đúng chỗ. Đội kỹ thuật không được tự quyết "85% đã đủ chưa". Đó là quyết định về mức rủi ro doanh nghiệp chấp nhận, và nó thuộc về bạn. Nhận lấy nó — đội sẽ thở phào.
• 4. Bảo vệ một tuần dựng bộ eval trước khi cho tối ưu prompt. Nó không tạo ra thứ gì nhìn thấy được, nên nó sẽ bị cắt nếu bạn không bảo vệ. Đây là khoản đầu tư có lợi tức cao nhất trong một dự án AI.
• 5. Đổi cách khen. Nếu bạn vẫn khen người "làm cho nó chạy được", đội sẽ tiếp tục tối ưu cho buổi demo. Hãy khen người tìm ra nhóm ca hệ thống hay sai, và người phát hiện chất lượng đang tụt trước khi khách hàng phát hiện.
• 6. Nói trước về lần sai đầu tiên, bằng số, ngay từ buổi khởi động. Nếu ban lãnh đạo chưa từng nghe rằng hệ thống sẽ sai khoảng 12% số lần, thì ca sai đầu tiên được nêu lên sẽ thành khủng hoảng niềm tin — và dự án thường chết ở đó, chứ không chết vì kỹ thuật.

Việc thứ sáu là việc cứu nhiều dự án nhất. Lần sai đầu tiên luôn đến. Điều quyết định là nó đến như một điều đã được báo trước, hay như một bất ngờ khó chịu.

Nói về sự không chắc chắn với người bên ngoài

Đây là phần khó nhất về mặt chính trị, và làm sai thì mọi thứ khác đều vô nghĩa.

Về đội kinh doanh — đây là chỗ rò rỉ lớn nhất và ít được chú ý nhất. Họ sẽ hứa điều gì đó với khách hàng, và nếu không ai nói cho họ biết ranh giới, họ sẽ hứa sự hoàn hảo, vì đó là thứ dễ bán nhất. Một trang hướng dẫn cho họ rẻ hơn nhiều so với việc gỡ một lời hứa đã đưa ra.

Xây đội cho thế giới xác suất

Về việc tuyển: đừng tuyển "người biết AI" như một phẩm chất tách rời. Hãy tìm người thoải mái khi không có câu trả lời chắc chắn và vẫn ra được quyết định. Phẩm chất đó dạy được chậm; kiến thức công cụ thì dạy được nhanh.

Và đừng thay cả đội. Phần lớn người trong đội hiện tại chuyển được, nếu được nói rõ phản xạ nào cần gỡ. Điều họ thiếu là một người nói ra điều đó — và đó là việc của bạn.

Tình huống thực tế — một giám đốc sản phẩm 18 năm kinh nghiệm

Bối cảnh: công ty phần mềm logistics, giám đốc sản phẩm có 18 năm kinh nghiệm, dự án đầu tiên dùng AI để dự báo thời gian giao hàng.

Ba tháng đầu, mọi thứ đi sai: ông yêu cầu đội "đảm bảo sai số dưới 10 phút" — đội không cam kết được, nên báo cáo mơ hồ dần. Ông xem demo thấy tốt, hứa với hai khách hàng lớn là quý sau có. Tới lúc chạy thật, sai số ở tuyến nội thành là 8 phút nhưng ở tuyến liên tỉnh là 40 phút. Khách phàn nàn. Ông kết luận công nghệ chưa chín và định dừng dự án.

Điều đã thay đổi tình thế:

• Tách theo nhóm ca thay vì một con số. Hoá ra hệ thống rất tốt ở nội thành (chiếm 71% đơn) và kém ở liên tỉnh. Một con số trung bình đã giấu mất điều đó suốt ba tháng.
• Thu hẹp cam kết. Chỉ hiển thị dự báo cho tuyến nội thành; tuyến liên tỉnh hiển thị khoảng thời gian rộng như cũ. Giá trị vẫn đến với 71% đơn hàng.
• Đổi cách hứa với khách. Từ "dự báo chính xác" sang "dự báo trong khoảng ±10 phút cho đơn nội thành, và chúng tôi hiển thị rõ mức tin cậy".
• Nhận lấy quyết định ngưỡng. Ông tự chốt: sai số trung vị dưới 12 phút ở nội thành là đủ để ra mắt. Đội ngừng báo cáo mơ hồ ngay tuần đó, vì cuối cùng đã có một đích rõ ràng.

Không có gì về mặt công nghệ thay đổi. Cùng mô hình đó, cùng đội đó. Thứ thay đổi là cách đặt câu hỏi, cách cam kết, và việc ai chịu trách nhiệm cho ngưỡng. Và mười tám năm kinh nghiệm của ông không hề mất giá trị — chính kinh nghiệm đó cho ông biết ngay rằng 71% đơn nội thành là đủ để có một sản phẩm đáng bán.

Hiccups thường gặp và cách xử lý

Vì sao vai trò của bạn cần cái này

Definition of done

• Bạn đã tự nói ra phản xạ của mình trước đội, công khai.
• Câu hỏi bạn hỏi trong buổi rà soát đã đổi sang phân phối và nhóm ca.
• Bạn đã nhận lấy quyết định ngưỡng thay vì để đội kỹ thuật tự quyết.
• Bộ eval được bảo vệ khỏi áp lực làm tính năng.
• Ban lãnh đạo và khách hàng đã được nghe trước, bằng số, rằng hệ thống sẽ sai bao nhiêu.
• Đội kinh doanh có một trang ranh giới về điều được hứa và không được hứa.
• Kết quả luôn được tách theo nhóm ca trước khi đưa ra bất kỳ kết luận nào.