Tuần đầu ở khách hàng, FDE nên viết một trang trước khi dựng prototype

Sáng thứ Hai, bạn ngồi trong phòng họp của khách hàng. Trong tay bạn có quyền truy cập data warehouse, một kênh Slack và một câu yêu cầu ngắn của trưởng bộ phận: “Chúng tôi cần một agent lo phần điều phối đơn hàng.”

Phản xạ tự nhiên của developer là mở laptop ra dựng prototype. Bạn nên kìm phản xạ đó lại vài ngày và mở một trang giấy trắng trước.

Theo một hướng dẫn năm 2026 của Perspective AI về cách FDE làm discovery, tìm hiểu khách hàng là phần lõi trong công việc của FDE chứ không phải việc chuyển sang cho product manager. FDE là người chịu trách nhiệm tìm ra hệ thống thực sự phải làm gì.

Vì vậy, nếu bạn hiểu sai bài toán, cả nhóm rất dễ xây sai theo, và lỗi có thể chỉ lộ ra khi đã tốn nhiều công sức.

Vì sao không chỉ hỏi khách cần gì?

Palantir, nơi khai sinh mô hình FDE, rút ra bài học này từ sớm. Thay vì hỏi khách hàng muốn gì, công ty đưa kỹ sư vào làm việc ngay trong môi trường của khách. Lý do là với những vấn đề phức tạp và mới, khách thường không biết mình cần gì cho đến khi thấy nó chạy.

Phỏng vấn vẫn cần, nhưng phải hỏi đúng cách. Câu “anh chị cần tính năng gì?” chỉ đem về một danh sách mong ước. Câu “lần gần nhất anh chị làm việc này diễn ra thế nào?” mới đem về dữ liệu. Kế hoạch một trang là chỗ để bạn ép mình hỏi loại câu thứ hai.

Tuần 0: trang giấy gồm những gì?

Cũng theo hướng dẫn của Perspective AI, vòng discovery của FDE gồm bốn tuần: tuần 0 dựng nền, tuần 1–2 phỏng vấn khách hàng async trên diện rộng, tuần 3–4 cùng chuyên gia nghiệp vụ của khách thiết kế eval. Tuần 0 diễn ra trước dòng code đầu tiên và phải cho ra hai thứ.

Thứ nhất là bản đồ stakeholder: người bảo trợ phía lãnh đạo, người phụ trách đánh giá kết quả (eval owner), người dùng cuối, đầu mối quản trị hệ thống và người hoài nghi. Thứ hai là phân định rõ ai chấm output của hệ thống và ai là người hưởng lợi từ nó. Hai nhóm này thường không trùng nhau.

Phần còn lại của trang giấy dưới đây là cách tổ chức gợi ý, không đến từ hướng dẫn. Hãy tự giới hạn mình trong một trang: nếu không viết gọn được vào một trang thì bạn chưa biết điều gì quan trọng nhất. Mẫu có thể dùng ngay:

KẾ HOẠCH DISCOVERY — [Khách hàng] — Tuần 0
1. Bài toán, ghi nguyên văn lời khách:
2. Bản đồ stakeholder (ai có thể chặn, làm chậm, mở rộng):
   Người bảo trợ | Eval owner | Người dùng cuối | Quản trị hệ thống | Người hoài nghi
   Ai chấm output? Ai hưởng lợi từ output?
3. Tối đa 3 giả thuyết cần kiểm chứng:
4. Lịch phỏng vấn tuần 1–2 (ai, khi nào, đồng bộ hay async):
5. Định nghĩa thành công:
   [Ai] giảm/tăng [X] từ [Y] xuống/lên [N], đo bằng [cách nào]
6. Câu hỏi còn mở:

Dòng thứ năm khó viết nhất, nên lúc đầu cứ để trống. Bạn chỉ điền nó sau khi đã nói chuyện với người dùng thật.

Người hoài nghi đáng được gặp đầu tiên

Bản đồ stakeholder có một ô hay bị bỏ quên: người hoài nghi. Hướng dẫn của Perspective AI mô tả đó là người trong tổ chức khách hàng nghi ngờ dự án sẽ thành công, và chính họ giúp lộ ra những kiểu thất bại quan trọng.

Đừng tránh người này. Hãy hỏi họ hai câu mà hướng dẫn gợi ý: “Điều gì phải đúng thì việc này mới thực sự chạy được?” và “Những dự án tương tự trong tổ chức này từng thất bại ở đâu?”

Câu trả lời cho bạn biết họ nghĩ dự án sẽ hỏng ở đâu. Trong tuần đầu, đó thường là danh sách rủi ro trung thực nhất bạn có được.

Kịch bản phỏng vấn: hỏi về tuần trước

Với người dùng cuối, hướng dẫn trên khuyên mở đầu bằng câu “Kể tôi nghe lần gần nhất anh/chị làm X”. Câu này khớp với hai nguyên tắc trong The Mom Test, cuốn sách của Rob Fitzpatrick.

Nguyên tắc đầu tiên là nói về cuộc sống của khách chứ không nói về ý tưởng của bạn. Nguyên tắc thứ hai là hỏi về những việc cụ thể đã xảy ra, không hỏi ý kiến chung chung hay dự đoán tương lai.

Một kịch bản 20 phút có thể trông như sau:

Mở đầu:  "Kể tôi nghe lần gần nhất anh/chị xếp tuyến cho ca sáng."
Đào sâu: "Bước nào mất nhiều thời gian nhất? Hôm đó mất bao lâu?"
         "Lúc đó anh/chị mở những màn hình hay file nào?"
         "Lần gần nhất có sự cố, anh/chị xử lý ra sao?"
Kết:     "Có điều gì lẽ ra tôi nên hỏi mà chưa hỏi không?"
         "Tôi nên nói chuyện với ai tiếp theo?"

Cả hai câu kết đều lấy từ The Mom Test. Cuốn sách còn coi mục tiêu của mỗi buổi gặp là có được cam kết và bước tiến tiếp theo, chẳng hạn một buổi hẹn nữa hoặc một lời giới thiệu.

Còn những câu như “nghe hay quá” thì bỏ qua: Fitzpatrick gọi lời khen là vàng giả của việc tìm hiểu khách hàng: lấp lánh, gây xao nhãng và vô giá trị.

Về số lượng, hướng dẫn của Perspective AI cho biết một FDE thường thực hiện 15–40 cuộc phỏng vấn async với khách hàng trong hai tuần đầu, trong khi phỏng vấn trực tiếp thường chững lại ở khoảng 8–10 cuộc vì khó xếp lịch.

Hãy coi con số đó là một lời nhắc. Khi bạn không ngồi cạnh người trả lời, kịch bản phải đủ rõ để họ tự trả lời được, nên hãy viết và thử kịch bản thật kỹ trước khi gửi hàng loạt.

Từ một câu trả lời đến một con số có thể sai

Thử hình dung một công ty logistics giả định. Bạn hỏi một điều phối viên về lần gần nhất chị xếp tuyến. Chị kể: “Sáng thứ Hai tuần trước tôi mất khoảng 90 phút. Có hai xe báo hỏng lúc 6 giờ, tôi phải gọi từng tài xế rồi chép tay vào Excel, và ba đơn bị giao trễ.”

Câu này đã đủ nguyên liệu. Người dùng là điều phối viên ca sáng. X là thời gian xếp tuyến. Y là 90 phút, mức hiện tại do chính chị nói ra. Bạn đề xuất N là 30 phút, rồi hỏi lại chị và người hoài nghi xem mức đó có khả thi không.

Dòng thứ năm trên trang giấy giờ sẽ là: “Điều phối viên ca sáng giảm thời gian xếp tuyến từ 90 phút xuống 30 phút, đo bằng log thời gian trên 10 ca liên tiếp.” Câu này có thể sai, và chính vì thế nó hữu ích. Câu “agent giúp điều phối hiệu quả hơn” thì không bao giờ sai, nên cũng chẳng chứng minh được gì.

Khi đã có prototype đầu tiên, hãy đem nó cho chuyên gia nghiệp vụ xem. Hướng dẫn của Perspective AI nhấn mạnh: đừng bắt họ chấm output giả định, hãy đưa output thật. Một bảng tuyến thật cho ca sáng thứ Hai sẽ làm lộ ra những luật ngầm mà không buổi phỏng vấn nào moi ra được.

Ba lỗi khiến trang giấy vô dụng

Lỗi phổ biến nhất là giới thiệu giải pháp trước khi hỏi. Khi bạn mở đầu bằng demo agent, khách sẽ bàn về agent của bạn thay vì kể về công việc của họ. Buổi phỏng vấn đã đi chệch khỏi nguyên tắc đầu tiên của The Mom Test trước khi bạn kịp hỏi câu nào.

Lỗi tiếp theo là ghi lời khen và lời hứa như thể đó là dữ liệu. “Chắc chắn chúng tôi sẽ dùng” là một dự đoán về tương lai. “Tuần trước tôi mất 90 phút” mới là chuyện đã xảy ra. Chỉ loại câu thứ hai được phép đi vào dòng định nghĩa thành công.

Lỗi cuối cùng là chỉ phỏng vấn những người ủng hộ dự án. Một bản đồ stakeholder thiếu ô người hoài nghi chỉ cho bạn thấy những gì bạn muốn thấy. Thử hình dung: rủi ro thật nằm ở phòng pháp chế, đội IT hay một trưởng ca từng chứng kiến ba dự án trước thất bại, và nó chỉ lộ ra đúng lúc bạn chuẩn bị go-live.

Mang trang giấy này đi phỏng vấn xin việc

Nếu JD của một vị trí FDE nhắc đến “customer discovery” hay “scoping”, hãy chuẩn bị sẵn một câu chuyện discovery cụ thể.

Viết nó vào CV theo đúng cấu trúc định nghĩa thành công: bạn đã phỏng vấn ai, phát hiện ra điều gì, chỉ số nào đổi từ Y sang N. Nếu chưa có dự án thật, một kế hoạch discovery một trang làm cho một doanh nghiệp quen biết cũng đáng mang theo.

Code bạn viết ở tuần thứ ba chỉ tốt được bằng trang giấy bạn viết ở tuần 0. Vì thế, hãy viết trang giấy đó trước.