Khi tổ trưởng không tin AI: cách FDE gỡ kháng cự trong một dự án thí điểm

Thử hình dung bạn đang ở tuần thứ ba của một dự án thí điểm. Biểu đồ mức sử dụng bắt đầu đi xuống. Tổ trưởng ca vẫn đăng nhập nhưng bỏ qua gần hết gợi ý của mô hình. Trong buổi họp đầu ca, một kiểm viên hỏi thẳng: “Cái này dùng để chấm điểm tụi em à?”

Cảnh này không hiếm. Khảo sát năm 2026 của PwC và Manufacturing Institute cho thấy 62% nhân viên tuyến đầu hoài nghi AI, chỉ 24% nói họ thấy hào hứng. Nghĩa là nhiều khả năng người dùng thật của bạn bắt đầu với thái độ nghi ngờ, kể cả khi ban giám đốc đã ký hợp đồng.

Với FDE, đây là việc của chính mình chứ không phải của phòng nhân sự. Salesforce mô tả FDE là người làm việc sát khách hàng để gỡ các nút thắt và đẩy nhanh việc áp dụng AI. Nếu người dùng thật không tin công cụ, đó cũng là một nút thắt, và việc gỡ nó thuộc phần việc của FDE.

Lời phản đối nào cũng có một nỗi lo cụ thể

Lỗi đầu tiên của kỹ sư là coi sự kháng cự là tiếng ồn, chuyện tâm lý cần chờ cho qua. Thật ra nó là dữ liệu. Prosci, một tổ chức chuyên về quản trị thay đổi, nhận định rằng với nhân viên và quản lý tuyến đầu, sự hoài nghi lớn lên khi họ không nhìn thấy AI ra quyết định như thế nào.

Còn một nỗi sợ khác khó nói ra hơn. Theo ITPro, khi nhân viên coi AI là công cụ để giám sát mình, họ thôi gắn bó và tìm cách lách nó. Khi đó vòng lặp cải tiến cũng dừng: không ai sửa gợi ý sai thì mô hình không học thêm được gì từ hiện trường.

Vì vậy, khi nghe một câu phản đối, việc đầu tiên là dịch nó ra nỗi lo thật. Bảng dưới đây là cách dịch bạn có thể mang theo khi xuống hiện trường.

Người dùng nói	Nỗi lo thật	FDE nên làm gì
“Máy này dùng để chấm điểm tụi em à?”	Bị giám sát	Tách log sửa lỗi khỏi báo cáo hiệu suất cá nhân, và nói rõ điều đó
“Nó đoán bừa thôi”	Không hiểu máy quyết định thế nào	Hiển thị lý do và độ tin cậy của từng gợi ý
“Máy sai thì ai chịu?”	Phải gánh lỗi thay máy	Để con người là người duyệt cuối cùng
“Rồi sau này cần mấy người?”	Mất việc	Nói chuyện này trước tiên, đừng để đến cuối

Dòng cuối cùng quan trọng nhất. MindStudio khuyên rằng nỗi lo mất việc là điều cần xử lý đầu tiên. Nếu bạn né nó, mọi buổi đào tạo sau đó chỉ là nói cho có.

Một dự án thí điểm được cứu như thế nào

Lấy một ví dụ giả định: một nhà máy linh kiện điện tử cho tổ QC 12 kiểm viên dùng thử mô hình đọc ảnh và gợi ý loại lỗi. Tuần đầu ai cũng tò mò. Sang tuần thứ ba, tỷ lệ gợi ý được bấm “chấp nhận” giảm mạnh.

Thời điểm này không ngẫu nhiên. Dữ liệu hành vi của Worklytics, một công ty bán công cụ phân tích, thường cho thấy mức sử dụng công cụ AI tụt rõ sau tuần thứ ba, khi cảm giác mới lạ hết và ma sát thật xuất hiện.

Đây là số liệu của nhà cung cấp, nên hãy coi nó là lời nhắc có mặt ở xưởng vào tuần đó, đừng ngồi văn phòng xem dashboard.

Bước đầu tiên là ngồi cùng ca với tổ trưởng, chứ không ngồi cùng ban giám đốc. Trong khảo sát của PwC, 45% người được hỏi nói sáng kiến AI ở công ty họ thất bại một phần vì lãnh đạo tuyến đầu không được tham gia đủ. Một cuộc nói chuyện có thể diễn ra như sau:

FDE: Anh thấy gợi ý của máy sai nhiều nhất ở loại lỗi nào?

Tổ trưởng: Vết xước với bụi bám. Nó gọi bụi là xước, mà xước là phải hủy hàng.

FDE: Nếu máy cho anh xem nó đang nhìn vào chỗ nào trên ảnh, anh có thấy dễ quyết hơn không?

Tổ trưởng: Có.

Mà mấy lần cả tổ sửa, có ai đếm không? Có tính vào điểm của từng người không?

FDE: Lần sửa nào cũng được ghi lại để dạy lại mô hình, nhưng không gắn với tên ai trong báo cáo hiệu suất. Chuyện này sẽ ghi rõ trong tài liệu dự án, anh cứ kiểm tra.

Từ cuộc nói chuyện đó, bạn rút ra năm thay đổi, trong đó ba thay đổi đầu đến thẳng từ lời tổ trưởng. Thay đổi thứ nhất là giao diện: hiển thị vùng ảnh mô hình dựa vào, mức độ tin cậy, và vài ca tương tự trong quá khứ.

Thay đổi thứ hai là quyền quyết định: kiểm viên là người bấm xác nhận hoặc sửa, và mỗi lần sửa trở thành dữ liệu huấn luyện. Thay đổi thứ ba là cam kết bằng văn bản rằng log sửa lỗi không đi vào báo cáo hiệu suất cá nhân.

Ba thay đổi này cũng là lý lẽ bạn mang lên ban giám đốc: niềm tin được xây bằng sự minh bạch và giám sát của con người, đúng như Prosci mô tả, và khi con người duyệt song song với AI thì ai chịu trách nhiệm đều rõ ràng.

Thay đổi thứ tư là cách đo. Có người dùng công cụ chưa có nghĩa là dự án thí điểm thành công. Với tổ QC, chỉ số đúng hơn là thời gian kiểm tra mỗi lô hàng, số lỗi lọt qua khâu kiểm, và tỷ lệ lần sửa của kiểm viên được đưa vào mô hình mới.

Thay đổi thứ năm là chỉ định một người cụ thể chịu trách nhiệm lắng nghe phản hồi của tuyến đầu trong 90 ngày đầu và thật sự xử lý nó. Hãy ghi tên người đó vào kế hoạch, kèm lịch họp mỗi tuần với tổ trưởng.

Người dùng phải thấy ý kiến của mình biến thành bản cập nhật, nếu không họ sẽ thôi góp ý.

Muốn mở rộng thì bắt đầu từ người đồng nghiệp

Khi tổ đầu tiên đã ổn, đừng vội mở rộng cho cả nhà máy. Worklytics đề xuất xây một mạng lưới “champion” giữa các đồng nghiệp với nhau: tìm những người có ảnh hưởng tự nhiên trong từng nhóm và đào tạo họ kỹ hơn trước khi triển khai rộng.

Ca đêm sẽ nghe một kiểm viên cùng ca kể lại kinh nghiệm dễ hơn là nghe một kỹ sư từ bên ngoài đến.

Phần việc còn lại nằm ở công ty của chính bạn. Salesforce cho biết đội FDE của họ đưa mọi thông tin thu được ở tuyến đầu ngược về đội sản phẩm và kỹ sư. Chuyện bụi bị nhận nhầm là vết xước là một bug của mô hình. Còn nỗi lo “có tính điểm không” là yêu cầu cho thiết kế sản phẩm, đáng được ghi thành ticket.

Những sai lầm làm dự án thí điểm chết dần

Sai lầm phổ biến nhất là chỉ demo cho sếp rồi coi như người dùng đã đồng ý. Kế đến là giấu cách mô hình hoạt động vì nghĩ người dùng “không cần biết”. Rồi để log sử dụng âm thầm biến thành bảng xếp hạng nhân viên, đúng nỗi sợ bị giám sát mà ITPro mô tả.

Hai sai lầm còn lại khó thấy hơn. Đó là báo cáo số lượt dùng như thể đó là giá trị tạo ra. Và đó là thu phản hồi rồi để đó, không ai chịu trách nhiệm xử lý. Cả năm sai lầm đều có cùng gốc: coi người dùng tuyến đầu là người nhận sản phẩm, trong khi họ thật ra là những người cùng thiết kế nó.

Nếu bạn đang chuẩn bị chuyển sang FDE, hãy để ý trong mô tả công việc những cụm như “user adoption”, “change management” hay “work with frontline teams”.

Trong CV, một dòng như “sau khi phỏng vấn người dùng cuối, thêm phần giải thích cho từng gợi ý của mô hình, tỷ lệ chấp nhận tăng từ X lên Y” có sức nặng hơn ba dòng liệt kê framework.

Khi phỏng vấn, hãy chuẩn bị kể một lần bạn bị người dùng phản đối và bạn đã thay đổi điều gì sau đó.

Giám đốc FDE của Salesforce từng cảnh báo rằng nếu không có FDE, hàng nghìn khách hàng có thể bị kẹt mãi ở giai đoạn thí điểm. Ở tổ QC trong ví dụ, thứ kéo dự án ra khỏi vũng lầy đó không phải một mô hình giỏi hơn, mà là một người chịu xuống xưởng hỏi tổ trưởng xem anh ấy đang lo điều gì.