# Vì sao FDE giỏi tìm cách để khách không cần gọi mình nữa

> Rủi ro lock-in đặc thù của FDE không nằm trong code, mà ở việc khách không tự vận hành được hệ thống.

Bản gốc: https://fdetimes.net/vi/phan-tich/dung-lam-minh-khong-the-thay-the-fde-viet-tai-lieu/

Một người làm nghề được Insight Partners trích lời đặt cho đội mình một mục tiêu nghe như tự hủy: "tự làm mình hết việc, theo đúng nghĩa đen". Trong một nghề được trả lương để ngồi sát khách, đó lại là định nghĩa của việc làm tốt.

Phản xạ của nhiều kỹ sư thì ngược lại. Khi bạn là người duy nhất hiểu pipeline, biết vì sao prompt viết như thế, biết chạy lại eval ra sao, bạn thấy mình có giá. Khách gọi bạn mỗi khi có chuyện, và mỗi cuộc gọi như một lời xác nhận.

Đó chính là cái bẫy. Nếu bạn đang làm FDE hoặc muốn chuyển sang, hiểu sớm vì sao "không thể thay thế" là một rủi ro chứ không phải một thành tích sẽ quyết định cách bạn thiết kế mỗi engagement, và cách bạn kể về nó khi đi phỏng vấn.

## Lock-in của FDE không nằm trong code

Khi nói về lock-in, kỹ sư thường nghĩ đến định dạng dữ liệu độc quyền hay API khó thay.

Cohere chỉ ra một loại khác, đặc thù hơn với nghề này: "Rủi ro lock-in đặc thù hơn của FDE là phụ thuộc vận hành." Cohere xếp nó vào một nhóm riêng, khác hẳn lock-in kỹ thuật, nên việc bạn kiểm tra cũng phải khác: không phải xem code nằm ở đâu, mà xem ai biết vận hành nó.

Hệ quả được Cohere mô tả rất cụ thể: doanh nghiệp có thể sở hữu deployment mà không có năng lực vận hành nó. Thử hình dung: code nằm trong repo của khách, hạ tầng chạy trên cloud của khách, hợp đồng ghi rõ khách là chủ.

Nhưng khi hệ thống trục trặc lúc hai giờ sáng, người duy nhất biết phải làm gì lại đang ngồi ở công ty khác.

**Điểm mấu chốt:** Khách có thể sở hữu hệ thống mà vẫn không tự vận hành được nó.

Điều quan trọng hơn: Cohere không coi đây là cái giá tất yếu của mô hình FDE. "Phụ thuộc vận hành không phải là hệ quả tất yếu của việc làm việc với FDE," Cohere viết, và còn đi xa hơn: sự tham gia sâu của vendor lẽ ra phải làm khách độc lập hơn chứ không phải kém đi.

Nói cách khác, phụ thuộc là kết quả của những quyết định cụ thể trong lúc làm, nên cũng có thể tránh bằng những quyết định khác.

## Thiết kế để rời đi ngay từ ngày đầu

Insight Partners gói lời khuyên của mình trong một câu ngắn: "Giải bài toán khó, rồi rời đi." Theo Insight Partners, mọi engagement nên được thiết kế để kết thúc ngay từ đầu. Khi kết quả đã được chứng minh, quyền sở hữu chuyển sang những đội sẽ sản phẩm hoá và vận hành nó ở quy mô lớn.

Jason Martin của Databricks mô tả mô hình này bằng lời hứa với khách: đưa bài toán khó nhất ra đây, đội của ông sẽ giải, rồi "IP là của bạn, chúng tôi sẽ bàn giao cho bạn".

Lời hứa đó chỉ có nghĩa nếu khách nhận được cả khả năng dùng IP ấy. Bàn giao một repo mà không ai bên khách đọc nổi thì cũng giống trao chìa khóa một chiếc xe mà không ai biết lái.

Đó là lý do Cohere nhấn mạnh thời điểm. Việc xây năng lực cho khách phải chạy suốt engagement, thay vì bị coi là một bài tập bàn giao vào phút cuối. Một buổi training hai tiếng ở tuần cuối khó biến ai thành người vận hành; nhiều tuần làm cùng nhau thì có thể.

## Thử đếm: bao nhiêu việc chỉ mình bạn làm được?

Hãy hình dung một engagement giả định kéo dài 12 tuần. Bạn dựng hệ thống RAG giúp đội xử lý hồ sơ bồi thường của một công ty bảo hiểm trả lời câu hỏi về điều khoản hợp đồng.

Hệ thống có sáu việc vận hành định kỳ: nạp tài liệu mới, chạy lại bộ eval, chỉnh prompt khi chất lượng tụt, theo dõi chi phí, xử lý lỗi khi định dạng tài liệu đổi, và cập nhật danh sách câu hỏi kiểm thử.

Ở phiên bản thứ nhất, bạn tự làm cả sáu việc vì nhanh hơn. Đến tuần 12, chỉ số "số việc chỉ FDE làm được" vẫn là 6 trên 6. Bạn rời đi, ba tuần sau phòng pháp chế đổi mẫu hợp đồng, độ chính xác tụt, và việc đầu tiên khách làm là gọi cho vendor.

Ở phiên bản thứ hai, từ tuần thứ hai bạn yêu cầu khách cử một kỹ sư ngồi cùng. Từ tuần 3, mỗi tuần một việc chuyển từ "FDE làm, khách xem" sang "khách làm, FDE xem", bắt đầu từ việc ít rủi ro như nạp tài liệu và để việc khó nhất, xử lý lỗi khi định dạng đổi, đến tuần 8.

Đến tuần 8, con số còn 0 trên 6, và bốn tuần cuối bạn chủ yếu quan sát, sửa tài liệu vận hành và xử lý những ca khó thật sự.

Cả hai phiên bản giao cùng một hệ thống chạy được. Chỉ phiên bản thứ hai giao được năng lực. Con số 6 trên 6 hay 0 trên 6 là thứ bạn có thể theo dõi hằng tuần, viết vào status report, và cho khách thấy họ đang tiến gần đến lúc không cần bạn.

## Rời khách không có nghĩa là rời bài toán

Có một nỗi lo hợp lý: nếu khách không cần mình nữa thì giá trị của FDE nằm ở đâu? Rajkumar Irudayaraj của Alteryx trả lời bằng cách đổi hướng câu hỏi. Theo ông, FDE nên là "một vòng học liên tục cho công ty", không phải "chiếc nạng vĩnh viễn cho khách hàng".

Giá trị không biến mất khi bạn rời khách, nó chuyển sang chỗ khác. Mỗi lần bạn phải tự viết một đoạn code vá vì sản phẩm thiếu tính năng, đó là một tín hiệu cho đội sản phẩm.

Handbook FDE của PostHog yêu cầu đưa những chỗ sản phẩm còn thiếu như vậy về đội sở hữu kèm context tốt, vì context tốt giúp sửa nhanh hơn và khách tiếp theo sẽ không bao giờ gặp lại vấn đề đó.

Quay lại ví dụ bảo hiểm. Nếu lỗi khi mẫu hợp đồng đổi định dạng cứ phải sửa tay, thì việc đúng không phải là dạy khách sửa tay mãi, mà là viết ticket cho đội sở hữu phần nạp tài liệu: tài liệu nào hỏng, hỏng ra sao, ảnh hưởng thế nào.

Khi sản phẩm tự xử lý được, việc vận hành thứ năm trong danh sách biến mất với mọi khách hàng, không chỉ khách này.

## Hai cách làm cùng một engagement

Nhìn hai cách làm cạnh nhau, khác biệt nằm ở những quyết định nhỏ, không phải ở tay nghề.

| Khía cạnh | FDE "không thể thay thế" | FDE khiến khách không cần mình |
|---|---|---|
| Ai vận hành hệ thống | Chỉ FDE biết chạy eval, sửa prompt, xử lý sự cố | Kỹ sư phía khách làm, FDE quan sát và sửa tài liệu |
| Thời điểm xây năng lực | Một buổi bàn giao ở tuần cuối | Suốt engagement, mỗi tuần chuyển một việc |
| Thứ khách sở hữu khi kết thúc | Deployment và IP, nhưng không có năng lực vận hành | Deployment, IP và đội biết vận hành |
| Chỗ sản phẩm còn thiếu | Vá tay tại chỗ, chỉ khách này được lợi | Về đội sở hữu kèm context, khách sau không gặp lại |
| Dấu hiệu thành công | Khách gọi FDE mỗi khi có chuyện | Khách không còn cần gọi |

Cột trái không sai về mặt kỹ thuật: hệ thống vẫn chạy, khách vẫn hài lòng trong ngắn hạn. Nhưng mỗi ô bên trái là một khoản nợ, mà người trả là bạn, đồng nghiệp tiếp theo của bạn, hoặc chính khách hàng vào lúc tệ nhất.

## Câu chuyện nên kể khi đi phỏng vấn

Nếu bạn đang chuẩn bị chuyển sang FDE, hãy tìm trong kinh nghiệm hiện tại một lần bạn đã khiến người khác không cần mình nữa.

Có thể là lần bạn viết runbook để đội on-call tự xử lý một loại sự cố, hoặc lần bạn dạy đội khác tự chạy pipeline dữ liệu bạn dựng.

Một câu chuyện như vậy thuyết phục hơn nhiều so với kiểu "chỉ mình tôi sửa được".

Trên CV, hãy viết kết quả chuyển giao bằng con số cụ thể thay vì chỉ ghi "triển khai hệ thống X". Một dòng kiểu "chuyển toàn bộ 6 việc vận hành cho đội 2 kỹ sư của khách, khách tự chạy eval từ tuần 8" cho người tuyển dụng thấy bạn hiểu engagement kết thúc như thế nào.

Khi đọc tin tuyển dụng, để ý những từ như handover, enablement hay làm việc với đội sản phẩm: chúng gợi ý công ty đó nghĩ về FDE theo hướng nào.

Còn nếu bạn đã là FDE, việc đầu tiên nên làm ở khách tiếp theo là ghi danh sách việc vận hành ngay trong tuần đầu và hỏi khách ai sẽ nhận từng việc. Câu hỏi đó nghe như bạn đang tính chuyện ra đi. Thật ra nó cho khách thấy bạn tính đến ngày họ tự đứng được.

Thước đo đáng theo đuổi không phải số lần khách gọi bạn, mà là việc bạn để lại một đội biết tự làm.

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

- Liệt kê mọi việc vận hành định kỳ của hệ thống bạn đang triển khai, đánh dấu những việc mà chỉ bạn làm được.
- Chọn một việc trong danh sách đó và để một kỹ sư phía khách tự làm trong tuần này, bạn chỉ ngồi xem.
- Viết lại một chỗ sản phẩm còn thiếu mà bạn gặp ở khách thành ticket cho đội sở hữu, kèm bối cảnh, cách tái hiện và tác động.

## Nguồn

- [Demystifying the forward deployed engineer](https://www.insightpartners.com/ideas/forward-deployed-engineers/)

- [Why forward-deployed engineers should build capability, not dependency](https://cohere.com/blog/forward-deployed-engineers-capability-building)

- [Working with product engineering - Handbook](https://posthog.com/handbook/forward-deployed-engineering/working-with-product-engineering.md)