# FDE và consultant khác nhau ở đâu? Hãy nhìn xem ai trả tiền và đoạn code đi về đâu

> Hai người có thể ngồi cùng phòng họp, viết cùng một đoạn code cho khách hàng, nhưng một người đang xây sản phẩm còn người kia đang bán giờ công.

Bản gốc: https://fdetimes.net/vi/bach-khoa/forward-deployed-engineer-vs-professional-services/

Thử hình dung: thứ Ba, tuần thứ ba của đợt triển khai. Khách hàng gửi một yêu cầu nghe rất hợp lý: agent mà bạn dựng cần đọc thêm một loại hóa đơn vận chuyển có định dạng riêng của họ. Bạn viết parser trong hai ngày, chạy được, khách vui.

Câu hỏi thật sự nằm ở chỗ khác: sau hai ngày đó, đoạn code ấy đi đâu? Nếu nó nằm lại trong repo của khách và không ai ở công ty bạn biết đến nó, thì vào tuần đó bạn làm việc của một consultant, dù chức danh có ghi gì đi nữa.

Sự nhầm lẫn giữa hai vai trò không chỉ là chuyện gọi tên. Gergely Orosz, tác giả The Pragmatic Engineer, nhận xét rằng các vị trí FDE ở những phòng lab AI trông rất giống công việc của consultant bên ngoài hoặc system integrator.

Ông còn cảnh báo vai trò này sắp không còn phân biệt được với solutions architect hay consultant. Nếu bạn đang làm hoặc đang muốn vào nghề FDE, biết rõ ranh giới đó giúp bạn làm đúng việc mỗi ngày và chọn đúng nơi để ứng tuyển.

## Hai câu hỏi tách FDE khỏi consultant

Câu hỏi đầu tiên là ai trả tiền cho giờ làm của bạn. Theo một bài so sánh của Webfuse, FDE làm cho một hãng sản phẩm, nơi việc triển khai giúp bán phần mềm và giữ chân khách. Với consultant, thời gian của họ thường chính là sản phẩm được tính tiền cho khách. Còn thời gian của FDE là chi phí do hãng sản phẩm tự gánh.

Hệ quả rất thực tế. Consultant có động cơ hợp lý để công việc kéo dài, vì mỗi giờ đều được trả tiền. Hãng sản phẩm thì muốn mỗi giờ của FDE được dùng càng ít càng tốt cho cùng một kết quả, nên họ muốn việc làm cho khách hôm nay trở thành tính năng dùng lại được cho khách ngày mai.

Câu hỏi thứ hai đi thẳng vào chuyện đó: việc bạn làm cho một khách có quay về sản phẩm không? Một bài viết của người làm nghề trên Substack lập luận rằng thứ phân biệt FDE với "consulting đắt tiền mang chức danh đẹp hơn" chỉ là một quyết định thiết kế bên trong công ty.

Đó là vòng phản hồi: đội FDE làm ra thứ gì đó cho một khách, rồi mang về đội sản phẩm để tổng quát hóa.

**Điểm mấu chốt:** Điều làm nên FDE là việc làm cho khách quay về sản phẩm, chứ không phải chức danh.

## Khác biệt nào hiện ra tại chỗ khách hàng?

Hai mô hình kinh doanh khác nhau kéo theo hai cách làm việc khác nhau. SD Times mô tả FDE giỏi bắt đầu tạo ra giá trị trong vòng vài tuần bằng cách đưa vào những sản phẩm sẵn sàng cho production. Đội FDE cũng nhỏ, thường không quá sáu người, trong khi đội consulting thường đông hơn.

Khẩu vị rủi ro cũng khác. Cũng theo SD Times, consultant có xu hướng chọn giải pháp đã được kiểm chứng thay vì lựa chọn mới nhất. Có thể hiểu được lựa chọn đó: khi giờ làm là thứ được bán cho khách, một công cụ mới gây trục trặc là rủi ro nằm trọn trong hợp đồng.

| Khía cạnh | FDE | Consultant |
|---|---|---|
| Ai trả cho giờ làm | Hãng sản phẩm, coi đó là chi phí | Khách hàng, giờ làm là thứ được bán |
| Việc triển khai phục vụ điều gì | Giúp hãng bán và giữ phần mềm | Chính là dịch vụ được tính tiền |
| Quy mô đội | Nhỏ, thường không quá sáu người | Thường đông hơn |

Dù vậy, đừng biến bảng này thành chuyện ai hơn ai. SD Times cho rằng FDE bổ sung chứ không thay thế consultant truyền thống, lấp vào những chỗ consultant thường không mạnh.

Ranh giới cũng đang mờ đi từ phía các hãng: OpenAI đã lập một pháp nhân riêng là OpenAI Deployment Company và mua Tomoro, một công ty AI ở Anh, làm thương vụ đầu tiên, tức là một bước đi về phía mô hình dịch vụ.

## Ví dụ: một parser hóa đơn, hai số phận

Quay lại parser hóa đơn vận chuyển. Theo cách của consultant, bạn viết parser, viết tài liệu bàn giao, ghi giờ vào timesheet. Công việc tốt, khách nhận đủ, và câu chuyện kết thúc ở đó.

Theo cách của FDE, phần code vẫn y hệt, nhưng bạn làm thêm 15 phút sau khi xong. Bạn viết một ghi chú ngắn gửi đội sản phẩm, đại ý như sau:

```text
Khách: [tên khách], ngành logistics
Yêu cầu: agent đọc hóa đơn vận chuyển định dạng riêng
Đã làm: parser riêng, chạy production từ [ngày]
Vì sao sản phẩm không làm được: chưa có cách khai báo định dạng tài liệu tùy biến
Đề xuất tổng quát: cấu hình định dạng thay vì viết code cho mỗi khách
Câu hỏi cho PM: các khách khác có gặp vấn đề này không?
```

Thử hình dung đến đợt triển khai thứ ba, đồng nghiệp ở một khách khác cũng viết một parser tương tự và cũng gửi ghi chú. Lúc này PM có hai tín hiệu độc lập thay vì một lời phàn nàn mơ hồ.

Đến khách thứ tư, có thể bạn chỉ cần cấu hình chứ không phải viết code nữa. Giờ làm của bạn đã trở thành tính năng, và đó chính là lý do hãng sẵn sàng gánh chi phí cho bạn.

## Tự làm như thế nào

Mỗi khi nhận một yêu cầu tùy biến, hãy tự hỏi ba câu trước khi mở editor. Thứ này có lên production trong vài tuần không, hay sẽ nằm mãi ở bản demo? Phần nào chỉ đúng cho riêng khách này, phần nào có thể đúng cho khách khác? Ai trong đội sản phẩm cần biết chuyện này?

Sau đó, tách code thành hai lớp ngay từ đầu: phần chỉ dành cho khách, và phần có thể tổng quát. Cách tách này giúp đội sản phẩm dễ nhặt lại hơn nhiều so với một khối code trộn lẫn tên trường, đường dẫn và logic của riêng khách. Cuối cùng, gửi ghi chú phản hồi ngay trong tuần, khi chi tiết còn nhớ rõ.

## Những lỗi khiến FDE trượt thành consultant

Lỗi phổ biến nhất là không bao giờ đóng vòng phản hồi. Bạn bận, khách gấp, ghi chú bị hoãn mãi, và sau sáu tháng bạn có một đống parser riêng mà không ai ở trụ sở biết. Bạn vừa tốn chi phí như FDE, vừa tạo giá trị như consultant.

Một lỗi khác là thận trọng theo quán tính. Chọn giải pháp đã kiểm chứng là hợp lý trong mô hình dịch vụ, nhưng lời khuyên cho bạn là đừng mặc định như vậy: hãy cân từng lựa chọn công nghệ theo việc nó có giúp lên production trong vài tuần và đưa được bài học về sản phẩm hay không.

Cũng đừng để phạm vi phình ra mà không hỏi lại ai trả tiền, vì yêu cầu nào cũng có vẻ chính đáng khi bạn đang ngồi cạnh khách.

## Tin tuyển dụng và CV cũng trả lời hai câu hỏi đó

Khi đọc một mô tả công việc FDE, hãy tìm xem có nhắc đến việc làm cùng đội sản phẩm, đưa phản hồi về roadmap, hay chỉ toàn những từ như "bàn giao", "theo phạm vi hợp đồng", "tính giờ". Kiểu sau thường là consulting đổi tên. Điều đó không xấu, nhưng bạn nên biết mình đang nhận việc gì.

Trong CV, đừng chỉ viết "triển khai giải pháp cho khách hàng X". Hãy viết mỗi gạch đầu dòng theo công thức ba phần: bạn làm gì cho khách, lên production sau bao lâu, và đội sản phẩm học được gì từ đó. Nên đầu tư nhiều nhất vào phần cuối, vì đó là chỗ bạn cho thấy mình đã đóng được vòng phản hồi, thứ tách FDE khỏi consulting.

Lần tới khi viết xong một đoạn code cho khách, trước khi commit hãy hỏi: đoạn code này có cơ hội quay về sản phẩm không? Câu trả lời cho bạn biết hôm đó mình đang làm FDE hay consultant.

**Thử ngay tuần này:**

- Chọn một yêu cầu tùy biến gần đây của khách và viết ghi chú phản hồi sản phẩm 6 dòng theo mẫu trong bài, rồi gửi cho một PM
- Mở 3 tin tuyển FDE và đánh dấu xem tin nào nhắc đến việc phản hồi cho sản phẩm, quy mô đội và thời gian đưa lên production
- Viết lại một gạch đầu dòng trong CV theo công thức ba phần: làm gì cho khách, lên production sau bao lâu, sản phẩm học được gì

## Nguồn

- [The Pulse: Forward deployed engineering heats up again](https://blog.pragmaticengineer.com/the-pulse-forward-deployed-engineering-heats-up-again/)

- [Forward-Deployed Engineers vs. Implementation Consultants: The Crucial Distinctions](https://sdtimes.com/software-engineering/forward-deployed-engineers-vs-implementation-consultants-the-crucial-distinctions/)

- [Forward Deployed Engineer vs Technical Consultant](https://www.webfuse.com/blog/forward-deployed-engineer-vs-technical-consultant)

- [The Difference Between a Forward Deployed Engineer and a Consultant With a Better Title Is One Design Decision](https://shivanathd.substack.com/p/the-difference-between-a-forward)