Một nghịch lý cần hiểu, không cần sửa
Trong phần lớn tổ chức, người phản đối cách làm mới mạnh nhất là kỹ sư giỏi nhất. Điều này dễ bị đọc sai thành "chống thay đổi" hoặc "sợ bị thay thế". Thường thì không phải.
Lý do thật: người đó giỏi vì họ đã nội hoá một tiêu chuẩn cao, và tiêu chuẩn đó được định nghĩa bởi tính tất định. Họ tự hào vì hệ thống của họ không sai. Họ đã dành mười năm học cách làm cho code làm đúng một việc, mọi lần. Bây giờ bạn đề nghị phát hành một thứ sai 8% số lần — và với họ, điều đó nghe như bạn đang đề nghị hạ tiêu chuẩn.
Và ở mức nào đó, họ có một điểm đúng mà bạn cần nghe: rất nhiều sản phẩm AI được phát hành với chất lượng tệ và không có đường xử lý khi sai. Sự phản kháng của họ thường đang chỉ vào một rủi ro thật.
Ba dạng phản kháng, ba cách xử lý khác nhau
Đừng xử lý cả ba như một. Phân biệt trước:
| Dạng | Nghe như | Nó thật sự là gì | Làm gì |
|---|---|---|---|
| Bảo vệ tiêu chuẩn | "Không thể phát hành thứ sai được" | Một quan tâm đúng, diễn đạt sai | Cho họ sở hữu phần chặn sai âm thầm |
| Thiếu mô hình tư duy | "Đằng nào nó cũng không tin được" | Chưa có khung để đánh giá chất lượng xác suất | Đào tạo đọc kết quả |
| Lo mất giá trị bản thân | "Rồi ai cần kỹ sư nữa" | Một nỗi lo thật về nghề | Nói thẳng, và cho việc cụ thể |
Chuyển tiêu chuẩn cao thành tài sản
Người giỏi nhất của bạn quan tâm đến đúng đắn. Đó chính là năng lực cần cho ba việc quan trọng nhất trong dự án:
- Phép kiểm tự động chặn sai âm thầm.
tiền hàng + thuế = tổng, kiểm tra tính hợp lệ của MST, phát hiện giá trị ngoài khoảng. Đây là việc đòi đúng tư duy của một kỹ sư giỏi, và nó là lớp bảo vệ quan trọng nhất của hệ thống. - Thiết kế đường xử lý khi sai. Ba làn, hàng chờ, cách hoàn tác.
- Cơ chế phát hiện trôi chất lượng. Chạy bộ ca theo lịch, cảnh báo, tự chuyển về chế độ người duyệt.
Câu nói cụ thể có tác dụng: "Anh đúng là chúng ta không thể phát hành một thứ sai âm thầm. Tôi muốn anh phụ trách việc đảm bảo sai âm thầm bằng không. Còn tỉ lệ sai có người bắt được thì tôi chịu trách nhiệm về ngưỡng."
Câu đó làm ba việc: thừa nhận họ đúng, giao họ phần họ giỏi, và giữ lại quyết định ngưỡng cho người đúng vai — bạn.
Điều không nên làm
| Đừng | Vì sao |
|---|---|
| Nói "phải chấp nhận AI thôi" | Không phải lập luận, và nó đẩy họ sang phía đối lập |
| Đưa họ ra khỏi dự án AI | Bạn vừa mất người có tiêu chuẩn cao nhất ở đúng chỗ cần nhất |
| Cho một người trẻ hơn dẫn dắt để "vượt qua" họ | Biến một cuộc tranh luận kỹ thuật thành một xung đột về địa vị |
| Bỏ qua và làm tới | Sự phản kháng chuyển vào ngầm, và nó sẽ xuất hiện ở khâu review |
Nói thẳng về nỗi lo nghề nghiệp
Với dạng phản kháng thứ ba, tránh nói vòng. Điều nên nói:
> "Việc viết từng dòng code sẽ bớt đi. Việc thiết kế hệ thống chịu được một thành phần không đáng tin sẽ nhiều lên — và đó là việc khó hơn, không dễ hơn. Tôi muốn anh ở phía đó."
Câu này đúng và nó kiểm chứng được: xây một hệ thống đáng tin quanh một mô hình không đáng tin thật sự khó hơn xây một hệ thống tất định, vì bạn không thể dựa vào tính đúng đắn của thành phần lõi.
Khi phản kháng là đúng
Cuối cùng, một khả năng cần để ngỏ: đôi khi họ đúng và bạn sai. Nếu tính năng chạm tiền, chạm quyền truy cập, hoặc thực hiện hành động không hoàn tác được, thì "không nên giao cho hệ thống xác suất quyết định một mình" là một kết luận đúng, không phải một sự phản kháng cần vượt qua.
Phép thử: hỏi họ "nếu nó sai 1 lần trong 1.000, hậu quả cụ thể là gì?" Nếu câu trả lời là một thiệt hại không sửa được, họ đúng — và bạn nên đổi thiết kế, không đổi người.
Làm ngay
Xác định người phản kháng mạnh nhất trong đội và phân loại theo ba dạng ở bảng đầu. Nếu là dạng một, giao họ phụ trách việc chặn sai âm thầm trong tuần này — và nói câu ở phần trên, gần như nguyên văn.