Ngồi cạnh người dùng một ngày: cách FDE quan sát công việc thật để thấy điều khách không kể

Bạn vừa xong buổi scoping với trưởng nhóm vận hành của một công ty logistics. Quy trình được vẽ ra rất gọn: email khiếu nại đến, nhân viên đọc, chọn loại sự cố trong hệ thống, rồi chuyển cho bộ phận phụ trách. Bốn bước, và việc của bạn là dựng một agent tự động hóa chúng.

Bản vẽ ấy hầu như chắc chắn chưa đầy đủ. Không ai nói dối bạn cả. Chỉ là người ta đang kể lại quy trình mà họ nghĩ mình làm. Trên Pragmatic Engineer, trưởng bộ phận FDE của OpenAI nhận xét rằng điều khách mô tả lúc scoping thường không khớp với thực tế dữ liệu và hệ thống tại chỗ.

Với FDE, khoảng cách đó không chỉ là chuyện UX. Nếu agent của bạn được thiết kế theo bản vẽ bốn bước, nó sẽ hỏng đúng ở những chỗ bản vẽ bỏ qua. Bài này hướng dẫn kỹ năng lấp khoảng cách ấy: ngồi cạnh người dùng một ngày và nhìn cho đúng cách.

Vì sao lời kể luôn gọn hơn công việc thật?

Cơ chế đằng sau khá đơn giản. Nielsen Norman Group (NN/g) chỉ ra rằng khi người ta nhớ lại rồi tóm tắt quy trình của mình, lập luận, động cơ và mô hình tư duy bên dưới đều rơi khỏi bản tóm tắt.

Còn lại là các bước, còn lý do thì mất. Vì thế UserTesting mới lưu ý rằng hành vi người dùng tự kể không phải lúc nào cũng trùng với hành động bạn quan sát được.

Khoảng cách này cũng không lấp được bằng cách hỏi kỹ hơn. Theo NN/g, bối cảnh làm việc thật còn làm lộ ra những hành vi mà chính người dùng cũng không để ý mình đang làm, và bạn không thể hỏi ai đó về một thói quen họ không biết là mình có.

Đó là lý do Paraform, khi mô tả nghề FDE, nói có những ràng buộc chỉ hiện ra khi bạn xem một người thật sự dùng phần mềm.

Hệ quả thực tế là FDE phải có mặt ở nơi công việc diễn ra. Một FDE của Palantir kể với Pragmatic Engineer rằng hầu hết các tuần, người này dành vài ngày làm việc ngay tại cơ sở của khách hàng.

Đến với tư cách người học việc, không phải người phỏng vấn

NN/g định nghĩa contextual inquiry là một dạng nghiên cứu thực địa kiểu dân tộc học, kết hợp quan sát sâu với phỏng vấn. Hình ảnh họ dùng để mô tả quan hệ giữa hai bên là thợ cả và người học việc: người thợ cả dạy nghề bằng cách làm, người học việc học bằng cách nhìn.

Nhận vai người học việc, bạn sẽ ngồi đó theo một cách khác hẳn. Người phỏng vấn đặt câu hỏi rồi chờ câu trả lời. Người học việc nhìn tay người thợ, thấy họ ngập ngừng ở đâu, mở thêm cửa sổ nào, rồi mới hỏi “sao anh lại làm thế?”. Người dùng không còn phải trình bày gì cả, họ chỉ cần làm việc như mọi ngày.

Ví dụ: một ngày ở phòng xử lý khiếu nại

Quay lại công ty logistics ở trên. Hãy hình dung bạn ngồi sau lưng chị Lan, nhân viên xử lý khiếu nại, từ 9 giờ sáng. Bạn không hỏi gì cả, chỉ ghi chép theo bốn cột. Dưới đây là một trích đoạn giả định của nhật ký đó:

Thời điểm	Bạn thấy	Câu hỏi để dành	Hệ quả cho thiết kế
9:12	Trước khi chọn loại sự cố, chị mở file Excel trên màn hình thứ hai để tra tên khách	File này là gì, ai cập nhật?	Có một danh sách khách ưu tiên nằm ngoài hệ thống. Agent cần đọc được nó
9:40	Chị copy mã vận đơn sang website của hãng vận chuyển thay vì xem trong hệ thống nội bộ	Sao không xem trạng thái trong hệ thống?	Dữ liệu nội bộ có thể bị trễ, cần kiểm tra xem nó có cập nhật kịp không trước khi agent dùng
10:05	Gặp một email mơ hồ, chị dán vào chat nhóm hỏi đồng nghiệp	Những ca thế này thường ai quyết?	Phải có đường chuyển cho người, không ép agent tự phân loại mọi email
10:30	Chị chọn “Khác” cho email nói về hai sự cố cùng lúc	Một email có nhiều sự cố thì xử lý sao?	Mô hình dữ liệu đang giả định mỗi email chỉ có một nhãn

Không dòng nào trong bảng có mặt trong bản vẽ bốn bước. Vậy mà dòng nào cũng đủ sức làm agent hỏng trong tuần đầu chạy production. Điều đáng chú ý là chị Lan không hề giấu những chi tiết này. Với chị, chúng chỉ là “cách làm việc” bình thường, chẳng có gì đáng kể.

Đến giờ nghỉ, bạn đem cột câu hỏi ra hỏi. Tới đây mới là phần phỏng vấn, và nó bám vào những gì vừa xảy ra chứ không dựa vào trí nhớ chung chung.

Các bước để tự làm

Chuẩn bị. Hãy xin quan sát một ngày làm việc bình thường, đừng xin một buổi demo. Nói rõ là bạn đến để học cách họ làm, không phải để đánh giá họ. Mang theo mẫu nhật ký bốn cột như trên.

Quan sát cả việc thường lẫn ngoại lệ. Thư viện kiến thức của AI Engineer về FDE khuyên nên quan sát công việc thường ngày song song với những ngoại lệ gây hậu quả thật và những cách xoay xở không chính thức. Việc thường cho bạn biết cái happy path. Ngoại lệ và đường tắt thì cho bạn biết hệ thống thật đang thiếu gì.

Xin ví dụ khi câu chuyện nghe quá trơn tru. Cũng nguồn đó gợi ý: khi một quy trình được kể quá suôn sẻ, hãy xin một ví dụ gần đây. Câu hỏi thực tế có thể là: “Lần gần nhất chị gặp ca kiểu này là khi nào? Chị mở lại cho em xem được không?” Ví dụ cụ thể kéo người ta từ quy trình lý tưởng về đúng việc đã xảy ra.

Đối chiếu lại với scoping. Tối hôm đó, đặt nhật ký cạnh tài liệu scoping. Mỗi chỗ lệch nhau là một câu hỏi cần đem đến người ra quyết định, hoặc một thay đổi trong thiết kế.

Những lỗi khiến buổi quan sát thành vô ích

Lỗi phổ biến nhất là hỏi chen ngang. AI Engineer lưu ý rằng câu hỏi đặt ra giữa lúc người dùng đang làm sẽ làm thay đổi hành vi của họ. Bị hỏi “sao chị mở file đó?”, chị Lan có thể bắt đầu làm “đúng quy trình” cho bạn xem. Vì thế hãy ghi lại thời điểm rồi để dành câu hỏi.

Lỗi thứ hai khó tránh hơn với kỹ sư: thấy người dùng loay hoay là muốn giúp ngay. Cũng nguồn đó cảnh báo rằng khi bạn trở thành trợ lý kỹ thuật cho người dùng, bạn có thể che mất chính những khó khăn mình đến để tìm.

Ba phút chị Lan vật lộn với website hãng vận chuyển là dữ liệu quý. Nếu bạn chỉ cho chị phím tắt, dữ liệu đó biến mất.

Lỗi thứ ba là chỉ quan sát trưởng nhóm. Người đứng ra scoping thường không phải người ngày nào cũng làm việc đó. Hãy xin ngồi cạnh người dùng cuối, càng gần tuyến đầu càng tốt.

Kỹ năng này đi vào CV thế nào?

Khi đọc mô tả tuyển dụng FDE, hãy để ý những cụm như làm việc tại chỗ với khách hàng, hay làm việc trực tiếp với người dùng cuối. Paraform mô tả vòng phản hồi giữa FDE và người dùng cuối là gặp mặt trực tiếp. Kỹ năng quan sát chính là thứ những dòng tuyển dụng ấy đang ngầm đòi hỏi.

Trong CV hoặc buổi phỏng vấn, đừng viết “giỏi giao tiếp với khách hàng”. Hãy kể một chuỗi cụ thể: bạn quan sát ai, trong bao lâu, phát hiện cách xoay xở không chính thức nào, và thiết kế đã thay đổi ra sao vì phát hiện đó.

Một câu chuyện như vậy cho nhà tuyển dụng thấy bạn biết tìm ra yêu cầu thật, chứ không chỉ biết làm theo yêu cầu được giao.

Bản vẽ bốn bước trong buổi scoping vẫn có ích, vì nó là giả thuyết đầu tiên của bạn. Một ngày ngồi cạnh chị Lan là cách để kiểm chứng giả thuyết ấy, trước khi code của bạn phải kiểm chứng nó trên production.