# Từ bản vá cho một khách đến tính năng chung: FDE phản hồi cho đội product thế nào

> Đoạn code bạn viết vội ở chỗ khách có thể chết cùng dự án đó, hoặc thành tính năng cho hàng trăm khách khác. Kết cục nào xảy ra phụ thuộc vào cách bạn ghi lại và chuyển nó về cho đội product.

Bản gốc: https://fdetimes.net/vi/bach-khoa/tu-giai-phap-mot-khach-den-tinh-nang-san-pham/

Chiều thứ Sáu, bạn vừa vá xong một chỗ ở hệ thống của khách. Hệ thống nguồn của họ xuất ngày tháng theo một định dạng lạ, sản phẩm không đọc được, nên bạn viết một hàm chuyển đổi nhỏ chạy ngay trong môi trường của khách. Khách hài lòng và ticket được đóng.

Rất có thể ba tháng sau, một FDE khác lại viết đúng hàm đó cho một khách khác. Nhiều khả năng người đó cũng không biết bạn đã viết nó, và đội product cũng không biết có vấn đề này. Vậy là cùng một bài toán bị giải hai lần, còn sản phẩm thì không khá lên chút nào.

Muốn tránh kết cục đó, bạn cần thêm một kỹ năng: đưa phát hiện ở hiện trường về cho đội product. CRV mô tả FDE là người ship code thẳng vào môi trường live của khách và mang những bài học đó về core product.

Nửa đầu có khách đòi và có ticket để đóng. Nửa sau thì không ai đòi, nên rất dễ trôi mất nếu bạn không chủ động.

## Vì sao kênh phản hồi tốt nhất lại hay bị lãng phí?

Tandem nhận định không kênh nào mang về cho đội product nhiều thông tin bằng FDE, nhưng phần lớn công ty để phí kênh này. Nguyên nhân họ chỉ ra khá cụ thể: vòng phản hồi gãy vì mất bối cảnh.

Thông tin về đến PM chỉ còn một dòng kiểu "khách muốn hỗ trợ định dạng X", không còn nhắc đến ai cần, vì sao cần hay họ đang chịu thiệt hại gì.

Cách nhìn của Palantir, theo Tandem, ngược hẳn thói quen của nhiều công ty. Ở đó, việc tùy biến cho từng khách không bị coi là chi phí dịch vụ cần cắt giảm. Nó chính là cơ chế product discovery. Nếu nhìn như vậy, mỗi workaround bạn viết là một mẩu dữ liệu cho việc nghiên cứu sản phẩm.

PostHog mô tả cách chia việc đi kèm mô hình đó bằng một hình ảnh dễ nhớ. FDE mở ra một con đường sỏi đến chỗ khách. Sau đó, kỹ sư của đội core product biến con đường sỏi ấy thành xa lộ trải nhựa và tổng quát hóa nó cho những khách khác.

Muốn đội core làm được việc đó, bạn phải giao cho họ một tấm bản đồ đọc được.

**Điểm mấu chốt:** Đội core không tổng quát hóa được thứ họ không hiểu. Việc của FDE là giữ nguyên bối cảnh trên đường chuyển phát hiện về sản phẩm.

## Thay đổi nào được đi đường nhanh?

Không phải phát hiện nào cũng nên thành ticket gửi product, và không phải ticket nào cũng nên chờ roadmap. Handbook nội bộ của Witboost xem FDE là người giúp bằng chứng từ khách đến tay đội phát triển sản phẩm nhanh hơn. Handbook cũng đặt ra tiêu chí rõ ràng cho việc đưa một thay đổi từ hiện trường vào core product.

Có hai tiêu chí. Thay đổi phải dựa trên bằng chứng từ khách, không phải một yêu cầu tính năng mang tính phỏng đoán. Nó cũng phải nhỏ, có ranh giới rõ, làm nhanh và ước lượng được.

Những việc lớn, cắt ngang nhiều phần, gây breaking change hoặc phụ thuộc vào các quyết định sản phẩm rộng hơn thì đi theo quy trình product discovery và release planning thông thường.

Tách hai luồng như vậy bảo vệ cả hai phía. Đội product không bị FDE đẩy những thay đổi kiến trúc vào bằng cửa sau. FDE thì không phải chờ một chu kỳ roadmap chỉ để sửa một hàm parse.

## Một ghi chú phản hồi đi trọn vòng

Quay lại ví dụ định dạng ngày tháng, đây là một tình huống giả định. Thay vì nhắn PM một câu, bạn viết một ghi chú ngắn. Nửa đầu ghi lại chuyện gì xảy ra và bằng chứng nằm ở đâu:

```markdown
## Phản hồi từ hiện trường: parse định dạng ngày
Khách / môi trường: [tên khách], pipeline ingest đơn hàng
Quan sát: ngày tháng không chuẩn làm hỏng cả batch,
thay vì chỉ báo lỗi từng dòng
Bằng chứng: log lỗi, 3 file mẫu đã che dữ liệu nhạy cảm
Người bị ảnh hưởng: đội vận hành của khách
```

Nửa sau cho đội product biết bạn đã làm gì và bạn đề xuất gì:

```markdown
Workaround đang chạy: hàm chuyển đổi trong lớp tùy biến, link commit
Đề xuất: thêm tùy chọn định dạng ngày vào connector chung
Phân loại: đường nhanh (nhỏ, có giới hạn, không breaking)
Câu hỏi mở: có nên cấu hình định dạng ở cấp connector?
```

Ghi chú này trả lời trước những câu đội product sẽ hỏi. Bằng chứng nằm ở log và file mẫu, không phải ở trí nhớ của bạn. Workaround có link commit để kỹ sư core đọc được cách bạn đã đi qua con đường sỏi. Dòng phân loại cho thấy bạn đã tự đối chiếu với tiêu chí.

Giờ thử đổi tình huống. Giả sử khách yêu cầu thay đổi cách sản phẩm lưu dữ liệu của nhiều tenant. Bạn vẫn viết ghi chú với cùng cấu trúc, nhưng ở dòng phân loại thì ghi rõ "cần discovery". Lý do là thay đổi này cắt ngang và phụ thuộc vào một quyết định sản phẩm lớn hơn.

Biết nói "việc này không phải của đường nhanh" cũng là dấu hiệu trưởng thành của một FDE.

## Tự dựng vòng phản hồi trong năm bước

Bước đầu tiên là ghi nhận ngay tại chỗ. Mỗi khi viết một workaround hay nghe khách phàn nàn về cùng một chỗ lần thứ hai, hãy mở ghi chú trong ngày, khi log và ngữ cảnh còn nguyên. Tandem cho rằng khi việc ghi nhận đã thành một phần cấu trúc làm việc, độ trễ từ lúc quan sát đến lúc có ticket product nên chỉ tính bằng ngày.

Bước thứ hai là gắn bằng chứng. Lưu đoạn log lỗi, chép vài file mẫu đã che dữ liệu nhạy cảm, ghi rõ ai bên khách bị ảnh hưởng và link đến commit của workaround. Một phép thử đơn giản: một kỹ sư core chưa từng gặp khách đọc xong có tự tái hiện được lỗi không.

Bước thứ ba là tự phân loại. Đặt ghi chú cạnh hai tiêu chí ở trên và trả lời từng câu: có bằng chứng thật chưa, phạm vi có gói gọn trong một chỗ không, có làm vỡ hành vi hiện có không. Chỉ cần một câu trả lời nghiêng về phía "lớn" là ghi "cần discovery", kèm một dòng giải thích vì sao.

Bước thứ tư là mang các ghi chú vào buổi debrief. CRV khuyên tổ chức những buổi debrief có cấu trúc, đều đặn giữa FDE và PM để thông tin từ hiện trường liên tục chảy về. Một buổi debrief có sẵn ba ghi chú viết tốt sẽ hiệu quả hơn nhiều so với một buổi kể chuyện theo trí nhớ.

Bước thứ năm là đo. CRV cũng khuyên theo dõi tỉ lệ giữa việc làm riêng cho khách và việc đã được tổng quát hóa. Nếu sau nhiều tháng tỉ lệ đó vẫn gần như toàn việc làm riêng, vòng phản hồi của bạn đang gãy ở đâu đó, dù từng dự án riêng lẻ trông vẫn thành công.

## Những lỗi khiến phản hồi chết giữa đường

Lỗi phổ biến nhất là chuyển lời khách nguyên văn thành yêu cầu tính năng. "Khách muốn nút export" là một phỏng đoán. "Đội vận hành mất nửa ngày mỗi tuần copy dữ liệu sang bảng tính, đây là file họ dùng" mới là bằng chứng. Tiêu chí của Witboost loại câu thứ nhất ngay từ cửa.

Lỗi thứ hai là cố đẩy một thay đổi lớn qua đường nhanh vì khách đang gấp. Áp lực của khách là có thật, nhưng một breaking change lọt vào core product sẽ thành vấn đề của mọi khách khác. Lỗi thứ ba thì ngược lại: không gửi gì cả vì nghĩ "chuyện nhỏ, chỉ khách này gặp".

Bạn không thể biết chỉ một khách gặp hay không cho đến khi đội product đặt nó cạnh các phản hồi khác.

Với developer Việt Nam muốn chuyển sang FDE, đây là kỹ năng rất đáng thể hiện trong CV. Thay vì chỉ ghi "tùy biến hệ thống cho khách hàng", hãy ghi bạn đã đưa bao nhiêu thay đổi từ dự án khách vào sản phẩm chung, và nhờ đó sản phẩm đỡ được bao nhiêu workaround cho các khách sau.

Khi đọc JD, hãy để ý những cụm như "feedback loop" hay "work closely with product". Gặp những cụm đó, bạn nên chuẩn bị sẵn một ghi chú phản hồi thật mình từng viết để kể khi phỏng vấn: bạn thấy gì, gửi gì về và đội product đã làm gì với nó.

Một FDE giỏi vẫn làm khách hài lòng ngay hôm thứ Sáu. Điểm khác biệt là đến khách thứ hai, sản phẩm đã tự xử lý được vấn đề đó và không còn ai phải viết lại hàm ấy.

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

- Chọn một workaround bạn đã viết cho khách gần đây và viết lại thành ghi chú phản hồi theo mẫu trong bài: bằng chứng, workaround, phạm vi, đề xuất phân loại.
- Liệt kê việc của bạn trong tháng qua thành hai cột, làm riêng cho khách và đã được đưa vào sản phẩm chung, rồi tính tỉ lệ.
- Xin PM 30 phút debrief định kỳ, mang theo ba ghi chú phản hồi đã viết sẵn.

## Nguồn

- [Forward-Deployed Engineering (Witboost handbook)](https://handbook.agilelab.it/Witboost_ProductDevelopment_ForwardDeployedEngineering.html)

- [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)

- [How FDE teams work with product and engineering (without broken telephone)](https://usetandem.ai/blog/fde-product-engineering-feedback-loop)

- [Forward Deployed Engineer: When This Role Makes Sense](https://www.crv.com/content/forward-deployed-engineer)