FDE và software engineer: cùng viết code, nhưng FDE sở hữu kết quả của một khách hàng

Thử hình dung: 2 giờ sáng, pipeline dữ liệu của khách hàng ngừng chạy. Ở team product cũ, bạn sẽ biết tin vào sáng hôm sau qua một ticket đã được support phân loại. Ở vai FDE, người nhận cuộc gọi là bạn, và không có ai đứng giữa.

Paraform, khi mô tả công việc FDE tại Palantir, Runway và Greptile, nói thẳng: không có bàn giao cho implementation team; nếu pipeline của khách hỏng lúc 2 giờ sáng, FDE là người sửa. Đó là khác biệt gọn nhất giữa hai nghề. Code vẫn là code, cùng ngôn ngữ, cùng git, cùng review. Khác nhau ở chỗ code ấy viết cho ai.

Nếu bạn đang có vài năm làm product engineer và muốn chuyển sang FDE, đây là thứ cần hiểu trước khi học bất kỳ công cụ nào. Vì người dùng code thay đổi, cách bạn định nghĩa “xong”, cách bạn chọn giải pháp và cách bạn nói chuyện mỗi ngày đều đổi theo.

Sở hữu một component, hay sở hữu một kết quả?

Aced.io đặt hai vai cạnh nhau: software engineer sở hữu một feature, service hay component, với team và manager đặt hướng đi. FDE sở hữu kết quả cho một khách hàng, với quyền tự quyết mà trang này ví như CTO của một startup áp lên một account duy nhất.

Cùng nguồn, một core SWE hiếm khi tiếp xúc trực tiếp với khách, vì họ ngồi ở product team ship feature cho tất cả mọi người.

Khác biệt này lớn hơn vẻ ngoài. Khi bạn sở hữu component, “xong” nghĩa là test pass và PR được merge; ai dùng nó, dùng ra sao, là việc của người khác. Khi bạn sở hữu kết quả, “xong” nghĩa là khách hàng đã dùng phần mềm để làm được việc họ cần.

Noah Brier, trong newsletter Alephic, mô tả FDE là người ngồi bên trong tổ chức khách hàng để thực sự đưa phần mềm vào vận hành, trái với kỹ sư truyền thống thường ở back-office và nhiều khi được cố ý giấu khỏi khách.

Paraform kể rằng ở Palantir, nơi những kỹ sư này mang tên nội bộ Delta, họ không viết spec rồi chuyển cho product team và ngồi chờ.

Một cuộc hội thoại đổi cách bạn viết code

Lấy một tình huống giả định để thấy kỹ năng này vận hành. Bạn là FDE triển khai một hệ thống agent xử lý chứng từ cho một công ty logistics. Tuần thứ hai, VP vận hành của khách gọi: tỷ lệ chứng từ bị đẩy về cho người duyệt lại vẫn 40%, trong khi họ kỳ vọng 10%.

Phản xạ của product engineer là mở log, tìm bug. Phản xạ của FDE là hỏi trước. Kịch bản có thể như sau:

VP: “Hệ thống chưa chạy được như các anh hứa.”

FDE: “Em xem số liệu rồi, 40% chứng từ bị đẩy về người duyệt. Trong số đó, loại nào gây khó nhất cho team anh?”

VP: “Hóa đơn từ hai nhà cung cấp lớn, format của họ khác hẳn.”

FDE: “Vậy nếu tuần này em xử lý riêng hai format đó và đưa tỷ lệ xuống dưới 20%, team anh có bớt được ca đêm không?”

VP: “Có, đó là thứ bọn tôi cần nhất.”

Để ý điều gì vừa xảy ra. Bạn chưa viết dòng code nào, nhưng đã đổi mục tiêu kỹ thuật: thay vì cải thiện model chung cho mọi loại chứng từ, bạn viết parser riêng cho hai format, một việc product team sẽ không bao giờ ưu tiên vì nó chỉ phục vụ một khách.

Aced.io nói thẳng rằng FDE không nói chuyện được với VP của khách là thiếu một nửa công việc. Và như kịch bản trên cho thấy, chính nửa giao tiếp ấy quyết định code nào đáng viết.

Nhưng việc chưa kết thúc ở khách hàng. Paraform liệt kê một trách nhiệm điển hình của FDE tại các startup AI là đưa bài học từ deployment về cho product team gần như theo thời gian thực. Parser riêng kia là dữ liệu: nếu khách thứ ba cũng gặp cùng nhà cung cấp, product team có lý do để generalize.

Bạn vừa là người sửa cho một khách, vừa là tai mắt của sản phẩm.

Làm thế nào để tập khi bạn còn ở team product

Bạn không cần đổi việc để bắt đầu luyện. Hãy bắt đầu từ cách bạn định nghĩa “xong”. Mỗi khi nhận một task, tự hỏi ai là người dùng cụ thể và họ làm được gì sau khi bạn merge; nếu không trả lời được, bạn đang ở tư duy component, và đó là thói quen cần phá trước tiên.

Tiếp đó, tìm cơ hội nghe người dùng cuối mô tả vấn đề bằng ngôn ngữ của họ. Câu hỏi “loại nào gây khó nhất” trong kịch bản trên không học được từ tài liệu; nó hình thành khi bạn đã nghe đủ nhiều người nói “hóa đơn của nhà cung cấp X” thay vì “precision thấp ở class Y”.

Rồi tập đóng vòng phản hồi. Mỗi lần bạn làm một fix dành riêng cho một tình huống, ghi lại lý do và gửi cho người sở hữu roadmap. Đó chính là cách FDE mang bài học từ hiện trường về cho product team, và trong CV, một dòng như “đề xuất generalize X sau khi triển khai cho Y” nói nhiều hơn bất kỳ framework nào bạn liệt kê.

Khi đọc job description, tìm những cụm như “own customer outcomes”, “embedded with customers”, “no handoff”. Chúng khớp với vai trò FDE như Paraform mô tả: sở hữu kết quả sau bán hàng, không chuyển giao cho implementation team.

Nếu JD chỉ ghi chung chung kiểu “làm việc với khách hàng khi cần”, đừng vội kết luận; hãy hỏi trong buổi phỏng vấn ai chịu trách nhiệm khi hệ thống của khách hỏng sau go-live.

Ba cái bẫy người chuyển ngành hay rơi vào

Bẫy quen thuộc nhất là mang tư duy “generalize trước” sang account. Product engineer được huấn luyện để tránh code chỉ dùng một lần; ở FDE, code chỉ dùng cho một khách đôi khi là câu trả lời đúng, miễn bạn ghi rõ và báo về product team.

Bẫy kín hơn là chờ. Thói quen viết spec rồi đợi team khác làm rất khó bỏ, nhưng như Paraform mô tả Delta của Palantir, chờ không phải một lựa chọn. Khi Aced.io ví FDE như CTO của một account, hàm ý là không còn ai phía trên để bạn đợi quyết định thay.

Bẫy cuối cùng là coi giao tiếp với khách là việc phụ, làm sau khi code xong. Thứ tự đúng ngược lại, như kịch bản ở trên cho thấy: không có cuộc gọi với VP, bạn đã bỏ hai tuần tinh chỉnh model chung mà không chạm vào thứ khách cần.

Một PR cũ, viết lại cho một khách

Chọn một PR bạn đã merge gần đây. Viết lại mô tả của nó như thể bạn là FDE cho một khách duy nhất: nêu tên (giả định) người dùng, kết quả họ cần, điều bạn sẽ làm nếu nó hỏng lúc 2 giờ sáng, và một câu bạn sẽ gửi về product team sau khi xong.

Đặt cạnh mô tả gốc, bạn sẽ thấy rõ phần nào của nghề mình chưa từng phải nghĩ tới.

Code không đổi. Người dùng nó đổi, và cả nghề đổi theo.