# Code tuỳ biến FDE để lại ở khách: khi FDE rời đi, ai trả món nợ kỹ thuật?

> Ngày bàn giao, quyền truy cập bị gỡ nhưng code vẫn chạy, và người duy nhất hiểu nó vừa rời khỏi phòng.

Bản gốc: https://fdetimes.net/vi/phan-tich/ai-bao-tri-code-fde-viet-cho-khach-no-ky-thuat/

Trong ca Solenis mà Valletta Software mô tả, ngày bàn giao khép lại bằng một thao tác rất bình thường: quyền truy cập từ xa bị gỡ. Từ hôm đó, một người không có nền tảng kỹ thuật tự vận hành hệ thống một mình.

Chuyện không có gì kịch tính, và vì thế mới cần nhìn kỹ. Mọi dòng code tuỳ biến FDE viết trong thời gian ở khách vẫn chạy sau hôm ấy. Chỉ có người hiểu nó là đã đi.

Nếu bạn đang làm hoặc muốn làm FDE, câu hỏi "ai trả món nợ này" không chỉ là chuyện của ban lãnh đạo.

Nó cho biết công ty bạn vào là công ty sản phẩm hay một hãng tư vấn đội lốt, và bạn sẽ được đánh giá bằng thứ mình đưa về sản phẩm hay bằng thời gian ngồi ở khách.

Câu trả lời ngắn gọn: khi không ai được giao đích danh, người trả thường là khách hàng.

## Dự án hay sản phẩm: ranh giới nằm ở đâu?

Thomas Otter đặt ranh giới rất thẳng. Theo ông, nếu chỉ chăm chăm xây ngay tại một khách hàng và cho riêng khách hàng ấy, thì đó là làm dự án chứ không phải làm sản phẩm. Ông nói thêm rằng một FDE tính phí cho khách thì làm việc cho dự án.

Otter dẫn lời Marty Cagan để chỉ ra hệ quả khi nhân bản cách làm đó. Cagan cảnh báo rằng một công ty chỉ có FDE sẽ nhanh chóng ôm hàng nghìn giải pháp may đo cỡ lớn. Theo Cagan, phải có một vai trò product phía nền tảng thì những gì các FDE học được mới được tổng hợp lại.

David Petersen của Angular Ventures, cũng qua lời Otter, nói gắt hơn: thiếu nỗ lực chuẩn hoá, bạn có lẽ đang tự kể cho mình một câu chuyện đẹp trong lúc lặng lẽ dựng lên một hãng tư vấn.

Chris Degnan, cựu CRO của Snowflake, trên podcast 20VC hồi tháng 5/2026 thì gọi FDE là một người làm dịch vụ chuyên nghiệp được tô vẽ cho sang. Trang Let's Data Science diễn giải mối lo của ông là nợ kỹ thuật và chuyện việc bảo trì rơi vào tay khách hàng.

Các ý kiến này có chung một điểm: chúng không phản đối việc FDE viết code riêng cho khách. Chúng phản đối việc code riêng ấy không có đường quay về sản phẩm.

## Nợ không tự sinh ra, nó bị nuốt im lặng

FDE Academy chỉ ra đúng cơ chế: nợ kỹ thuật thường xuất hiện khi phạm vi phình ra mà được lặng lẽ gánh luôn, không thương lượng lại, không ghi chép. Không ai cố ý tạo nợ cả. Nợ đến từ những lần nói "để em làm luôn cho".

Thử hình dung một tình huống giả định. Sang tuần thứ ba, khách xin thêm một luồng đồng bộ dữ liệu sang hệ thống kế toán cũ. FDE làm xong trong hai buổi tối, khách hài lòng, nhưng việc này không có trong phạm vi, không có tài liệu, và cũng không ai bên product biết nó tồn tại.

Sáu tháng sau bàn giao, hệ thống kế toán nâng cấp và luồng đồng bộ hỏng. Người đang vận hành là một người như chủ hệ thống ở ca Solenis: không chuyên kỹ thuật, không có quyền truy cập của đội cũ, không có tài liệu để đọc. Xét riêng, quyết định nào của FDE cũng hợp lý; cộng lại, chúng thành một món nợ không ai đứng tên.

Giờ nhân lên. Giả sử một đội FDE phục vụ 10 khách, mỗi khách có ba nhánh nhỏ kiểu này, thế là 30 đoạn code chưa ai trong product team từng đọc. Valletta cảnh báo rằng các nhánh tuỳ biến như vậy, đến một lúc nào đó, có thể khiến việc triển khai cho khách mới trở nên bất khả thi.

## Ai được giao việc tổng quát hoá?

Valletta tóm vấn đề vào một câu: không ai sở hữu việc tổng quát hoá. Bài viết cho rằng cam kết cốt lõi của mô hình FDE là đẩy những gì tổng quát hoá được ngược về sản phẩm, và mô hình này chỉ đứng vững khi việc đó có một người chịu trách nhiệm cụ thể.

Antoine Buteau diễn đạt cùng ý theo kiểu khác: công ty forward-deployed không né dịch vụ, mà "tiêu hoá" dịch vụ thành tài sản dùng lại được. Công ty nào không làm được việc đó sẽ trôi dần thành hãng tư vấn.

Sổ tay FDE của PostHog đi theo hướng này khi mô tả các khuôn mẫu lặp lại giữa các engagement trở thành artifact dùng lại, kỹ năng và cải tiến sản phẩm, còn FDE chịu trách nhiệm về kết quả.

Có điều đáng để ý: ngay cả sổ tay của PostHog cũng không nói ai bảo trì code tuỳ biến sau khi engagement kết thúc. Nhiều tổ chức nói rõ phần nào được đưa về sản phẩm, nhưng bỏ ngỏ phần ở lại. Phần ở lại đó mới là món nợ.

Xét cho cùng chỉ có ba khả năng. Product team nhận phần tổng quát hoá được. Khách hàng nhận phần còn lại, theo một thoả thuận bàn giao rõ ràng. Hoặc không ai nhận, và khi đó người gánh thường vẫn là khách hàng, chỉ có điều không được báo trước.

**Điểm mấu chốt:** Code tuỳ biến không ai đứng tên thì thường khách hàng là người gánh.

## Năm cửa mà món nợ đi qua

Nợ không sinh ra ở một thời điểm duy nhất. Trong vòng đời một engagement, nó lọt qua năm cửa, và cửa nào cũng có một việc FDE làm được ngay.

| Thời điểm | Nợ sinh ra thế nào | Việc FDE làm | Ai khuyên |
|---|---|---|---|
| Chọn việc nhận | Làm tích hợp một lần cho khách nằm ngoài tệp khách hàng lý tưởng | Coi đó là việc làm xao nhãng, nêu ra trước khi nhận | Antoine Buteau |
| Giữa engagement | Phạm vi phình ra, được gánh luôn mà không ai nói | Thương lượng lại, ghi chép lại, nêu rõ trade-off | FDE Academy |
| Khi thiết kế | Code dính chặt vào hệ thống của một khách | Thiết kế theo module để tách được phần riêng | FDE Academy |
| Sau mỗi engagement | Phần tổng quát hoá được bị bỏ lại ở khách | Đẩy về sản phẩm, có người được giao đích danh | Valletta Software |
| Bàn giao và sau go-live | Hiểu biết nghiệp vụ ra đi cùng đội, bảo trì không ai thấy | Ghi nghĩa vụ tài liệu và bàn giao vào hợp đồng khi thuê đội bên ngoài; theo dõi bảo trì tuỳ biến cả khi tài khoản đã "live" | Valletta Software, Antoine Buteau |

## Ngày mai bạn làm gì ở khách?

Bắt đầu từ cửa rẻ nhất: ghi chép. Mỗi lần khách xin thêm, ghi một dòng gồm yêu cầu là gì, có thương lượng lại không, chấp nhận trade-off nào. Một dòng như vậy biến khoản nợ vô hình thành một quyết định có người đứng tên.

Tiếp đến là cửa thiết kế. Trước khi viết luồng đồng bộ trong ví dụ trên, hãy tự hỏi: phần nào là chuyện của khách này, phần nào khách sau cũng sẽ cần? Phần thứ hai nên nằm trong một module tách riêng, có giao diện rõ ràng, để product team nhấc ra được mà không phải đào xới hệ thống của khách.

Cuối cùng là bàn giao. Hãy lấy chủ hệ thống ở ca Solenis làm phép thử: một người không chuyên kỹ thuật, không còn quyền truy cập của đội cũ, có tự vận hành được không? Nếu tài liệu của bạn chỉ người viết ra nó mới đọc hiểu, thì bàn giao chưa xong.

## Món nợ này nói gì về sự nghiệp của bạn?

Khi phỏng vấn cho một vị trí FDE, hãy hỏi thẳng ba câu. Ai được giao việc tổng quát hoá phần tuỳ biến về sản phẩm? Có vai trò product phía nền tảng nào tổng hợp những gì FDE học được không? Bảo trì tuỳ biến sau go-live được theo dõi thế nào? Câu trả lời mơ hồ là dấu hiệu bạn sắp làm cho một hãng tư vấn.

Khi đọc mô tả công việc, hãy tìm những cụm như "đưa ngược về sản phẩm" hay "artifact dùng lại được", kiểu cách PostHog mô tả công việc của họ. Một mô tả chỉ nói về sự hài lòng của khách và thời gian có mặt tại chỗ là đang tuyển cho dự án, chưa phải cho sản phẩm.

Trong CV, đừng chỉ liệt kê những gì bạn đã xây cho khách. Hãy kể những phần tuỳ biến bạn đã tách thành module dùng lại, những tính năng sản phẩm bắt nguồn từ một engagement của bạn, và bộ tài liệu bàn giao giúp khách tự vận hành. Đó là bằng chứng bạn làm sản phẩm, không phải làm dịch vụ được tô vẽ.

Code tuỳ biến nào rồi cũng có người giữ. Khác biệt chỉ nằm ở chỗ người đó được chọn từ đầu, hay đến ngày quyền truy cập bị gỡ mới lộ ra.

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

- Mở một sổ phạm vi cho engagement hiện tại: ghi lại mọi yêu cầu phát sinh, kèm quyết định đã thương lượng lại hay chưa và trade-off đã chấp nhận.
- Rà lại code tuỳ biến bạn đã viết, gắn nhãn từng phần là 'tổng quát hoá được' hoặc 'chỉ riêng khách này', rồi gửi danh sách nhãn 'tổng quát hoá được' cho product team.
- Đưa tài liệu bàn giao cho một người không làm kỹ thuật đọc thử, và hỏi họ có tự vận hành hệ thống được không nếu ngày mai bạn mất quyền truy cập.

## Nguồn

- [on the forward deployed engineer (Thomas Otter)](https://thomasotter.substack.com/p/on-the-forward-deployed-engineer)

- [The Forward Deployed AI Engineer Model, and What It Costs](https://vallettasoftware.com/blog/post/forward-deployed-engineer-model)

- [Chris Degnan Critiques Forward-Deployed Engineer Role](https://letsdatascience.com/news/chris-degnan-critiques-forward-deployed-engineer-role-e05975bb)

- [Forward Deployed Company Series 4: How Not to Become Accenture](https://www.antoinebuteau.com/forward-deployed-company-series-4-how-not-to-become-accenture.md)

- [How a Forward Deployed Engineer Manages Enterprise Scope Creep Without Creating Tech Debt](https://fde.academy/blog/forward-deployed-engineer-scope-creep-tech-debt)

- [Forward deployed engineering overview (PostHog Handbook)](https://posthog.com/handbook/forward-deployed-engineering/overview)