# FDE như một dịch vụ: thuê được kỹ sư, nhưng không thuê được vòng phản hồi

> Giờ đã có nơi cho thuê FDE theo từng deal, và chuyện đó buộc mọi kỹ sư hiện trường phải trả lời một câu hỏi khó: công việc của mình có để lại được gì cho lần sau không?

Bản gốc: https://fdetimes.net/vi/phan-tich/fde-as-a-service/

Giờ đã có nơi cho thuê FDE như thuê một tài nguyên cloud. A.Team chào bán những kỹ sư senior đủ sức đứng trước khách, được cử sang ngồi cùng khách hàng của một vendor, mang danh nghĩa vendor đó và lo phần last mile.

Lời chào hàng rất gọn: chốt deal thì đưa một kỹ sư chuyên trách vào, xong việc thì rút người ra.

a16z lại nhìn mô hình FDE từ phía rủi ro. Quỹ này viết rằng cái sai không nằm ở việc làm dịch vụ, mà ở chỗ tự coi mình là SaaS trong khi thực chất là một công ty dịch vụ có kèm nền tảng.

Hai cách nhìn ấy gợi ra một câu hỏi mà người làm FDE nên tự đặt càng sớm càng tốt.

Cùng một công việc, nghĩa là ngồi với khách, nối dữ liệu, sửa cho tới khi chạy được, có thể tạo ra một sản phẩm ngày càng mạnh, nhưng cũng có thể chỉ để lại hàng loạt dự án không ai bảo trì nổi.

Bạn đang đứng ở phía nào sẽ quyết định phần lớn những gì nghề này để lại cho bạn.

## Vì sao "dịch vụ" lại là từ nhạy cảm?

Lý do trước hết nằm ở biên lợi nhuận. Theo N47, các công ty dịch vụ truyền thống có biên lợi nhuận gộp 30-40%, còn công ty phần mềm đạt từ 70-80% trở lên.

Palantir thường được dùng làm bằng chứng rằng hai thứ có thể đi cùng nhau. N47 cho rằng Palantir giữ được biên lợi nhuận gộp trên 80%, tức mức của phần mềm, dù triển khai dày đặc ở hiện trường.

Bài viết của a16z trích một báo cáo của Everest để giải thích lý do: khác với công ty tư vấn, ở Palantir dịch vụ là phương tiện để khách dùng sản phẩm, không phải nguồn doanh thu chính.

Nhưng mô hình này không rẻ. Cơ sở dữ liệu mô hình kinh doanh của Compound dẫn lời một cựu CFO của Palantir: hợp đồng bảy chữ số có thể nuôi được mô hình này, còn tám hay chín chữ số thì chắc chắn được.

Một startup còn đang ký những hợp đồng nhỏ vì thế nên cân nhắc kỹ trước khi chép nguyên cách làm này.

## Sao chép nửa mô hình thì được gì?

Phần dễ bắt chước nhất của Palantir là đưa kỹ sư đến ngồi ở chỗ khách. Phần khó là nền tảng phía sau. a16z cảnh báo rằng nếu chỉ chép phần kỹ sư hiện trường, công ty sẽ kết thúc với hàng nghìn bản triển khai làm riêng, không thể bảo trì hay nâng cấp.

N47 nói cùng ý theo cách khác: nếu không có một nền tảng được thiết kế để ghép nối và dùng lại, các đợt triển khai FDE sẽ thành những dự án tư vấn đắt đỏ. Họ còn dự đoán nhiều công ty thử mô hình FDE sẽ trôi thành công ty tư vấn đội lốt công ty phần mềm.

Còn một cơ chế trôi dạt nữa, nằm ở sơ đồ tổ chức. Theo a16z, khi FDE bị tách khỏi team sản phẩm, công ty mất vòng phản hồi và dần thành một công ty dịch vụ thuần. Kỹ sư vẫn giỏi, khách vẫn hài lòng, nhưng những gì học được ở hiện trường không bao giờ quay về code chung.

## Phép thử thật: lần sau có rẻ hơn không?

Biên lợi nhuận là con số mà CFO quan tâm. Với kỹ sư, có một phép thử dễ dùng hơn, và N47 phát biểu nó rất gọn: mỗi lần triển khai phải giúp các lần sau nhanh hơn và rẻ hơn.

Thử hình dung bạn là FDE của một startup AI bán agent xử lý hóa đơn. Khách đầu tiên dùng một hệ ERP cũ, và bạn mất vài tuần viết connector, chuẩn hóa trường dữ liệu, dựng bộ eval cho các mẫu hóa đơn của họ. Đến khách thứ hai cùng ngành, có hai kịch bản.

Ở kịch bản thứ nhất, connector và bộ eval nằm trong repo của khách A, viết cứng theo tên cột của họ. Khách B lại bắt đầu từ con số không, và công ty về bản chất đang bán giờ công của bạn.

Ở kịch bản thứ hai, bạn đã tách connector thành một module cấu hình được và đưa bộ eval vào nền tảng. Khách B chỉ cần một file mapping mới, còn thời gian của bạn dồn vào phần thực sự khác biệt của họ.

Rocketlane đưa ra một ranh giới hữu ích để phân loại từng thứ bạn viết: nếu một giải pháp chỉ giúp được một khách hàng, đó là customization. Customization không có gì sai, vì khách nào cũng cần một ít. Vấn đề chỉ xuất hiện khi gần như mọi thứ bạn làm đều rơi vào loại này.

**Điểm mấu chốt:** Kỹ sư hiện trường giỏi không chỉ giải bài toán của khách mà còn làm bài toán đó rẻ hơn cho người đến sau.

## Ba mô hình, ba số phận cho công việc của bạn

Có ba cách vận hành rất khác nhau, dù cả ba đều có thể đăng tin tuyển với cùng chức danh FDE.

| Khía cạnh | FDE kéo khách dùng sản phẩm | FDE cho thuê theo deal | FDE trôi thành tư vấn |
|---|---|---|---|
| Dịch vụ để làm gì | Để khách dùng sản phẩm, không phải nguồn thu chính | Thêm năng lực triển khai khi chốt deal, không tăng headcount cố định | Thành nguồn thu thực tế, dù công ty vẫn tự nhận là SaaS |
| Ai giữ kiến thức sau dự án | Nền tảng và team sản phẩm | Vendor, nếu có quy trình thu lại; kỹ sư rút ra khi dự án xong | Nằm trong từng bản triển khai riêng |
| Vòng phản hồi về sản phẩm | Là lý do tồn tại của mô hình | Phụ thuộc cách vendor dùng kỹ sư thuê | Bị cắt khi FDE tách khỏi team sản phẩm |
| Rủi ro chính | Cần hợp đồng đủ lớn để gánh chi phí | Kiến thức đi theo người khi họ rời đi | Hàng nghìn bản triển khai không nâng cấp được |

Cột giữa là chỗ cần đọc kỹ nhất. Mô hình của A.Team giải quyết một vấn đề có thật: vendor không muốn nuôi đội triển khai cố định khi pipeline deal lên xuống thất thường.

Nhưng khi kỹ sư bước ra lúc dự án kết thúc, câu hỏi ai mang bài học về sản phẩm được đẩy hết sang vendor. Thuê được người làm last mile không có nghĩa là thuê được vòng phản hồi.

Rocketlane cũng lưu ý rằng không có một cách duy nhất để tổ chức công việc FDE. Mô hình cho thuê có thể hoạt động tốt nếu vendor xem kỹ sư thuê là nguồn đầu vào cho roadmap. Nếu không, nó dễ thành con đường ngắn nhất dẫn tới cột thứ ba.

## Với kỹ sư, điều này thay đổi cách làm việc ra sao?

Nếu bạn đang là FDE, hãy coi tỷ lệ code dùng lại được là chỉ số của chính mình.

Cuối mỗi đợt triển khai, tự hỏi thứ gì nên về nền tảng, thứ gì là customization chính đáng, và thứ gì bạn đã viết vội cho riêng một khách trong khi lẽ ra nên làm thành dạng dùng chung.

Câu hỏi thứ ba khó trả lời nhất, nhưng cũng giúp bạn tiến bộ nhanh nhất.

Nếu bạn làm FDE cho thuê hoặc ở một công ty nhỏ chưa có nền tảng chín, kỷ luật này càng quan trọng. Bạn rời dự án sớm hơn người khác, nên tài liệu bàn giao, module tách sạch và ghi chú gửi team sản phẩm là thứ duy nhất chứng minh bạn đã để lại gì ngoài một hệ thống đang chạy.

Khi đi phỏng vấn, đừng chỉ hỏi bạn sẽ ngồi ở chỗ khách bao lâu. Hãy hỏi FDE báo cáo cho ai, bài học từ hiện trường được đưa vào roadmap theo cách nào, và có ví dụ nào về một tính năng ra đời từ một đợt triển khai không.

Một công ty trả lời mơ hồ những câu này nhiều khả năng đang ở cột thứ ba của bảng trên.

Trong CV, hãy cho thấy công việc của bạn cộng dồn qua từng khách. Đừng chỉ viết "triển khai cho khách X".

Hãy viết rằng bạn biến connector làm cho khách đầu tiên thành module mà các đợt triển khai sau dùng lại, hoặc rằng một yêu cầu bạn mang về đã thành tính năng.

Những dòng như vậy chứng minh đúng phép thử "lần sau rẻ hơn" mà N47 đặt ra.

Khi FDE đã có thể được thuê theo từng deal như một nguồn lực, sự có mặt ở chỗ khách không còn là lợi thế riêng của ai. Thứ còn lại để phân biệt bạn là bằng chứng rằng sau mỗi lần bạn đến, lần triển khai kế tiếp của cả công ty đều nhẹ hơn.

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

- Liệt kê ba thứ bạn đã code cho khách gần nhất, rồi đánh dấu thứ nào chỉ một khách dùng được và thứ nào có thể đưa về sản phẩm.
- Chọn một thứ có thể dùng lại, viết một đề xuất ngắn gửi team sản phẩm, trong đó nêu khách nào khác sẽ cần nó.
- Khi đọc tin tuyển FDE, hỏi nhà tuyển dụng: bài học từ hiện trường được đưa về roadmap sản phẩm qua kênh nào?

## Nguồn

- [The Palantirization of everything](https://www.a16z.com/the-palantirization-of-everything)

- [The Forward Deployed Engineer dilemma](https://www.n47.com/insights/the-forward-deployed-engineer-dilemma)

- [Forward Deployed Engineer | Compound Business Model Database](https://businessmodels.compound.vc/model/forward-deployed-engineer)

- [Hire Forward Deployed Engineers On Demand | A.Team Deployed](https://www.a.team/hire-forward-deployed-engineers)

- [Forward Deployed Engineering: Finding the Model That Fits](https://rocketlane.com/blogs/forward-deployed-engineering-models)