# Muốn sang FDE? Hãy nhận một việc chưa ai viết spec ở công ty hiện tại

> Bằng chứng rằng bạn xử lý được bài toán mơ hồ có thể bắt đầu từ chính hàng đợi support của công ty bạn đang làm, trước cả khi bạn gửi đơn đầu tiên.

Bản gốc: https://fdetimes.net/vi/bach-khoa/lay-kinh-nghiem-fde-ngay-tai-cong-viec-hien-tai/

Bạn đọc một mô tả công việc FDE: làm việc trực tiếp với khách hàng, nhận bài toán chưa có spec, tự quyết phải xây gì. Rồi bạn nhìn lại CV của mình: ba năm viết API theo ticket mà PM đã chia sẵn. Khoảng trống ấy có thật, nhưng lấp nó không đòi hỏi bạn phải nghỉ việc trước.

Theo fde.academy, một vấn đề mơ hồ, không có spec rõ ràng, chính là việc của FDE. Vậy thì kinh nghiệm xử lý sự mơ hồ có giá trị ở bất kỳ đâu nó xảy ra, kể cả trong công ty bạn đang làm.

Lời khuyên đi kèm cũng rất cụ thể: trước khi nộp đơn, hãy xung phong nhận một sáng kiến có phạm vi còn lỏng lẻo ở chỗ làm hiện tại. Phần dưới đây đi qua cách chọn việc, cách làm, và cách biến kết quả thành thứ người phỏng vấn có thể nhìn thấy.

## Vì sao sự mơ hồ là thứ bạn cần đi tìm?

Phần lớn kỹ sư được huấn luyện để né sự mơ hồ: yêu cầu chưa rõ thì hỏi lại PM, chưa có acceptance criteria thì chưa bắt đầu. Đó là thói quen tốt trong một team sản phẩm.

Nhưng FDE được trả lương chính vì làm điều ngược lại: bước vào chỗ chưa ai định nghĩa, tự tìm ra vấn đề thật rồi làm đến khi có thứ người dùng dùng được.

Lộ trình từ backend sang FDE mà Scaler mô tả bắt đầu ngay trong công ty hiện tại: tìm việc FDE hoặc việc gần với deployment ở đó trước. MindStudio thì chỉ ra nguồn gốc của phán đoán FDE: đến đủ gần khách hàng và quy trình thật để hiểu vì sao một trường dữ liệu bị thiếu lại quan trọng.

Cả hai cùng trỏ về một chỗ. Kinh nghiệm FDE nằm ở nơi code gặp người dùng, và công ty nào cũng có nơi đó.

**Điểm mấu chốt:** Kinh nghiệm FDE bắt đầu từ một việc mơ hồ bạn dám nhận, không phải từ chức danh mới.

## Một ví dụ: cái trường bị thiếu trong file import

Thử hình dung bạn là backend engineer ở một công ty phần mềm quản lý kho cho doanh nghiệp. Tuần nào team support cũng chuyển sang vài ticket ghi đúng một câu: "khách import file lỗi". Không team nào sở hữu vấn đề này, nên mỗi lần lại có một người vá tay cho qua.

MindStudio khuyên nên bắt đầu từ đúng loại việc này: một vấn đề cụ thể, cứ lặp đi lặp lại trong công việc hiện tại. Ticket import lỗi khớp gần như hoàn toàn: mơ hồ vì chưa ai biết "lỗi" là lỗi gì, nhỏ vì chỉ xoay quanh một luồng, và chạm vào người dùng thật.

Bước đầu tiên không phải mở code mà là ngồi cạnh người support. Đây là kịch bản hỏi chuyện bạn có thể dùng gần như nguyên văn:

> **Bạn:** Lần gần nhất khách báo lỗi import, chị làm gì đầu tiên?
>
> **Support:** Mở file của khách, so với file mẫu, xem cột nào sai.
>
> **Bạn:** Thường sai ở cột nào nhất?
>
> **Support:** Cột mã kho.

Khách xuất từ hệ thống cũ không có cột đó, thế là cả file bị từ chối.
>
> **Bạn:** Khi bị từ chối, khách làm gì tiếp?
>
> **Support:** Gọi cho bên em, hoặc tự gõ tay từng dòng.

Ba câu hỏi đó biến "import lỗi" thành một vấn đề cụ thể: một trường bắt buộc mà dữ liệu thật của khách không có. Đó chính là kiểu hiểu biết về một trường dữ liệu bị thiếu đã nói ở trên, và bạn không thể có nó nếu chỉ đọc ticket.

Giờ đến quyết định kỹ thuật. Bạn có thể cho phép trường đó trống và gán kho mặc định, hoặc làm một màn hình để khách tự ghép cột. Thay vì tự chọn, bạn mang hai phương án đến trưởng nhóm vận hành và nói bằng ngôn ngữ của họ:

> "Cách một sửa trong hai ngày nhưng hàng có thể vào nhầm kho. Cách hai mất hai tuần, khách tự chọn kho và không phải gọi support nữa. Anh chị chấp nhận rủi ro nào hơn?"

Không có một chữ "nullable" hay "schema" nào. Người nghe được chọn giữa hai hệ quả mà họ hiểu, còn bạn được luyện đúng kỹ năng mà Scaler xếp vào nhóm cần tập từ bây giờ: giải thích quyết định kỹ thuật cho người không làm kỹ thuật.

## Tự làm: sáu bước, từ ticket đến CV

Bước một là đi tìm, đừng chờ được giao. Hàng đợi support, kênh chat của team vận hành, những file Excel mà phòng kinh doanh tự duy trì: ở đâu người ta lặp lại một thao tác thủ công vì phần mềm không đáp ứng, ở đó có vấn đề đáng nhận.

Bước hai là đến gần người dùng, như buổi ngồi cạnh support ở trên. Bước ba là tự viết spec: một câu mô tả vấn đề và kết quả mong đợi, mang đến quản lý để xin nhận việc trong một khoảng thời gian cố định. Bạn đang viết spec cho một thứ chưa có spec, và đó chính là bài tập.

Bước bốn là trình bày phương án cho người ra quyết định không làm kỹ thuật. Bước năm là triển khai phương án được chọn, đo một con số trước và sau, chẳng hạn số ticket cùng loại mỗi tuần, rồi gói tất cả vào một artifact. Bước sáu là viết lại CV quanh những gì bạn vừa làm.

## Biến công việc thành bằng chứng

Artifact là thứ chứng minh bạn làm được việc của FDE, chứ không chỉ nói về nó. Với ví dụ trên, đó có thể là một tài liệu một trang: vấn đề ban đầu mơ hồ ra sao, bạn hỏi ai, phát hiện gì, chọn phương án nào và vì sao, kết quả đo được.

Kèm theo đó là ảnh chụp màn hình hoặc đoạn demo ngắn, đã xoá dữ liệu nhạy cảm. Con số do chính bạn đo sẽ là xương sống của câu chuyện khi ngồi phỏng vấn.

Với CV, hướng dẫn của Scaler là làm nổi bật mọi lúc bạn đối mặt với sự mơ hồ thật sự và nói chuyện trực tiếp với người không phải kỹ sư. Sự khác biệt hiện rõ khi đặt hai cách viết cạnh nhau:

Cột bên phải không nói bạn giỏi hơn. Nó kể cùng một khối việc nhưng đặt sự mơ hồ và những người không phải kỹ sư lên trước, đúng hai thứ mà lời khuyên viết CV ở trên bảo bạn làm nổi bật.

## Những cái bẫy hay gặp

Bẫy phổ biến nhất là chọn việc quá lớn. "Thiết kế lại toàn bộ luồng onboarding khách hàng" nghe ấn tượng nhưng dễ kéo dài, vướng chính trị nội bộ và không cho bạn một kết quả gọn để kể. Một vấn đề lặp lại, giới hạn trong một luồng, là đủ.

Bẫy thứ hai là giải quyết vấn đề mơ hồ mà không gặp ai. Nếu bạn đọc log, đoán nguyên nhân rồi sửa, bạn đã luyện debug chứ chưa luyện kỹ năng FDE. Phần quý nhất của ví dụ trên là ba câu hỏi với người support, chứ không phải đoạn code.

Bẫy thứ ba là làm xong mà không để lại dấu vết. Sáu tháng sau, khi ngồi phỏng vấn, bạn sẽ không nhớ con số, không nhớ ai đã nói gì. Hãy viết tài liệu một trang ngay trong tuần hoàn thành việc, khi mọi chi tiết còn mới.

Cái bẫy cuối cùng tinh tế hơn: lấn sang việc của team khác mà không báo. Chủ động nhận việc mơ hồ khác với tự ý sửa hệ thống của người khác. Một tin nhắn ngắn cho team sở hữu code, kèm lời mời họ review, giúp họ đứng về phía bạn, và đó cũng là kỹ năng quản lý stakeholder mà FDE cần mỗi ngày.

## Bài tập cho tuần này

Chọn đúng một vấn đề bạn đã thấy bị báo lại ít nhất hai lần trong tháng qua. Viết ra một câu mô tả vấn đề như bạn hiểu hôm nay, rồi sau buổi nói chuyện đầu tiên với người gặp nó, viết lại câu đó.

Hai câu càng khác nhau, bạn càng thấy rõ phần việc một FDE làm mỗi ngày: biến điều người ta than phiền thành vấn đề có thể giải.

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

- Mở hàng đợi support hoặc kênh chat nội bộ, ghi lại ba vấn đề bị báo đi báo lại mà chưa team nào nhận
- Xin 30 phút ngồi cạnh một người support hoặc vận hành khi họ xử lý đúng vấn đề đó, chỉ hỏi và ghi chép
- Viết lại một dòng CV theo cấu trúc: tình huống mơ hồ, người không phải kỹ sư bạn làm việc cùng, artifact bạn để lại

## Nguồn

- [am i ready to become a forward deployed engineer](https://fde.academy/blog/am-i-ready-to-become-a-forward-deployed-engineer)

- [Backend Engineer to Forward Deployed Engineer: The Fastest Path](https://www.scaler.com/topics/backend-engineer-to-forward-deployed-engineer/)

- [how to become forward deployed engineer](https://www.mindstudio.ai/blog/how-to-become-forward-deployed-engineer/)