# Ngày làm việc của FDE chạy theo standup của khách, không chỉ của công ty bạn

> FDE giỏi triage những gì khách gửi từ tối hôm trước rồi mới bước vào standup của khách, để cuộc họp đó chốt được việc đáng làm nhất trong ngày.

Bản gốc: https://fdetimes.net/vi/bach-khoa/mot-ngay-cua-fde/

Thử hình dung: 8 giờ 40 sáng thứ Hai, bạn vừa ngồi vào bàn trong văn phòng khách hàng. Slack bên khách có bốn tin nhắn gửi từ tối Chủ nhật, Jira của họ có thêm một ticket mới. 9 giờ là standup của đội kỹ thuật bên khách, còn standup của công ty bạn tận 10 giờ mới bắt đầu.

Kỹ sư quen làm sản phẩm thường xem cuộc họp 9 giờ là "việc của khách", còn cuộc họp 10 giờ mới là việc chính. FDE thì nghĩ ngược lại: Paraform nhận xét phần lớn forward deployed engineer làm việc theo lịch của khách chứ không theo lịch công ty họ.

FDE Academy cũng viết rằng FDE được cử sang làm cùng đội khách sẽ dự cả standup của khách, và chính ở cuộc họp đó ưu tiên trong ngày mới thật sự rõ.

Nếu bạn là dev đang muốn chuyển sang FDE, đây có lẽ là thói quen khó đổi nhất, vì nó đảo ngược cách bạn quyết định làm gì trước. Ngồi đủ các cuộc họp thì chưa đủ. Thứ cần rèn là ba thói quen nhỏ: triage trước standup, nghe ra blocker trong standup, và biến lời khách nói thành task.

## Khoảng trống cần lấp nằm trong lịch của khách

PostHog định nghĩa FDE là người được đưa vào đội của khách để lấp khoảng trống giữa những gì sản phẩm làm được và những gì khách thật sự cần, đôi khi làm việc ngay tại văn phòng khách. Khoảng trống này hiếm khi xuất hiện trong backlog của công ty bạn.

Nó thường lộ ra ở standup bên khách, chẳng hạn khi một kỹ sư data than rằng pipeline đang đứng vì chưa được cấp quyền đọc một bảng.

Thời gian ở chỗ khách cũng nhiều hơn bạn nghĩ. Một tin tuyển Forward Deployed Software Engineer mảng chính phủ Mỹ của Palantir yêu cầu ứng viên có mặt tại site khách 4-5 ngày mỗi tuần, và mô tả công việc là làm trực tiếp với khách, thường là ngay tại chỗ, để hiểu và giải quyết vấn đề của họ.

PostHog thì cho biết FDE họp rất nhiều, làm nhiều việc trực tiếp với khách và thường phải đi công tác 20-50% thời gian. Khi phần lớn tuần làm việc diễn ra trong tòa nhà của khách, nhịp làm việc của họ cũng thành nhịp của bạn.

Tuần làm việc mẫu mà Paraform mô tả thể hiện rõ điều này. Thứ Hai, FDE dự standup của khách và đặt ưu tiên cả tuần quanh những gì đang chặn họ; thứ Ba mới tập trung build trong môi trường của khách, trên dữ liệu thật và trong các ràng buộc deployment của họ.

**Điểm mấu chốt:** Standup của khách không phải buổi để bạn báo cáo. Đó là nơi bạn tìm ra việc đáng làm nhất trong ngày.

## Trước 9 giờ: vào họp với câu trả lời

FDE Academy lưu ý rằng khách thường báo vấn đề không đồng bộ, nên những việc này cần được triage trước khi ngày làm việc bắt đầu, và xem triage là kỹ năng cho thấy rõ FDE nào giỏi. Nếu bạn phụ trách nhiều account cùng lúc, việc này càng khó, vì bạn phải tự quyết định chỗ nào cần để ý trước.

Mục tiêu của triage là để khi vào standup, bạn đã nói được "đã xem, giả thuyết là thế này, ETA là thế kia" thay vì hỏi "chuyện gì vậy?". Dưới đây là một ví dụ giả định với khách hàng làm logistics, bắt đầu từ mục gấp nhất:

```
TRIAGE — Thứ Hai, trước standup khách (9:00)
Nguồn: Slack khách (4), Jira khách (1)

[P0] Báo cáo tồn kho sáng nay trống
Ảnh hưởng: đội vận hành không chốt được đơn trong buổi sáng
Giả thuyết: job ETL đêm qua lỗi khi đọc bảng mới
Việc tiếp: xem log job, báo ETA ngay trong standup
```

Hai mục còn lại nhẹ hơn, kèm một câu hỏi cần khách quyết định:

```
[P1] Muốn thêm cột "kho nguồn" vào dashboard
Ảnh hưởng: tiện hơn, nhưng không chặn ai
Việc tiếp: hỏi trong standup xem ai dùng, dùng để quyết định gì
[P2] Hỏi cách export CSV
Việc tiếp: gửi link tài liệu, không cần đưa vào standup

Cần khách quyết định: ai duyệt quyền đọc bảng mới?
```

Thứ tự ưu tiên dựa trên ba câu hỏi: có ai đang bị chặn không, người bị chặn là ai, và cần ai ra quyết định để gỡ. Thứ tự tin nhắn đến hay giọng điệu gấp gáp của người gửi không phải là tiêu chí xếp hạng.

## Trong standup: dịch lời khách thành task

Theo Blockchain Council, khi gặp khách, việc của FDE là biến những yêu cầu kiểu "chúng tôi cần nhìn rõ rủi ro hơn" thành task kỹ thuật cụ thể. Standup là nơi những câu như vậy xuất hiện nhiều nhất, thường lẫn giữa hai lượt cập nhật tiến độ, và rất dễ bị bỏ qua.

Tiếp tục ví dụ giả định trên, cuộc trao đổi có thể diễn ra thế này:

```
Trưởng phòng vận hành: Tuần này phòng vận hành cần nhìn rõ rủi ro giao trễ hơn. FDE: Hiện anh đang theo dõi rủi ro ở đâu? Trưởng phòng: File Excel, chiều thứ Sáu có người cập nhật tay. FDE: Nếu thấy sớm hơn thì anh sẽ làm gì khác: đổi xe, báo khách hay đổi kho? Trưởng phòng: Đổi kho xuất.

FDE: Phải biết trễ trước bao lâu thì mới kịp đổi kho? Trưởng phòng: Ít nhất 24 tiếng.

→ Task: cảnh báo các đơn có nguy cơ trễ trước ít nhất 24 giờ, nhóm theo kho
→ Người nhận: trưởng ca từng kho
→ Xong khi: trưởng ca nhận được cảnh báo trước giờ chốt đơn
```

Cả đoạn chỉ mất chừng một phút. Bạn không thiết kế giải pháp ngay trong standup, chỉ hỏi đủ để biết ai sẽ hành động, hành động gì và cần biết trước bao lâu. Phần còn lại để dành cho một cuộc nói chuyện 15 phút ngay sau đó, rồi gửi lại task bằng văn bản để khách xác nhận.

## Standup nội bộ vẫn cần, nhưng đổi vai

Lịch của khách đi trước không có nghĩa là bỏ standup của công ty bạn. Ở cuộc họp nội bộ, bạn mang blocker của khách về và nói rõ cần gì từ đội product hay platform.

Blockchain Council mô tả nhịp làm việc của FDE là một vòng lặp gồm triage, discovery, build, test, train, document, rồi lặp lại. Nếu áp vào một ngày, vòng lặp đó bắt đầu bằng bản triage trước 9 giờ, tiếp theo là discovery ngay trong standup, sau đó mới tới lúc mở editor.

Bạn có thể tập theo trình tự này ngay ở công việc hiện tại. Mỗi sáng, đọc hết các yêu cầu gửi đến từ tối hôm trước và viết bản triage ba mức. Vào họp, nói P0 trước, kèm giả thuyết và ETA, rồi nghe ra những câu mơ hồ và hỏi tiếp cho tới khi biết người nào sẽ làm gì khác đi.

Sau họp, gửi task bằng văn bản. Cuối ngày, đối chiếu lại xem việc bạn đã làm có khớp với blocker sáng nay không.

## Năm lỗi thường gặp

Lỗi đầu tiên là dự standup của khách như một khán giả: ngồi nghe, ghi chép, nhưng không nhận việc gì. Khách sẽ nhanh chóng coi bạn là người bên ngoài. Lỗi thứ hai là mang lịch công ty bạn vào phòng họp của khách, ví dụ báo cáo tiến độ sprint nội bộ trong khi họ chỉ muốn biết bao giờ báo cáo tồn kho chạy lại.

Lỗi thứ ba là triage theo thứ tự tin nhắn đến hoặc theo người hối nhiều nhất. Lỗi thứ tư là gỡ lỗi ngay trong standup, làm cuộc họp 15 phút kéo dài thành 45 phút và tốn thời gian của cả đội khách.

Lỗi thứ năm khó thấy nhất: hiểu yêu cầu trong đầu nhưng không viết lại cho khách xác nhận, để rồi đến thứ Sáu mới phát hiện hai bên hiểu khác nhau.

## Thể hiện điều này trong CV thế nào?

Khi đọc JD FDE, hãy để ý các cụm như "on-site", "% travel" hay "embedded with customer teams". Chúng cho bạn biết lịch của bạn sẽ thuộc về ai. Số ngày ở site khách ghi trong JD là cách nhanh nhất để hình dung một tuần làm việc thật của vị trí đó.

Trong CV, thay vì ghi "phối hợp với stakeholder", hãy viết cụ thể: bạn dự họp hằng ngày với đội nào của khách hoặc người dùng nội bộ, triage loại yêu cầu gì, và một yêu cầu mơ hồ đã được bạn đổi thành tính năng nào. Hãy chuẩn bị để được hỏi sâu về đúng câu chuyện đó, nên chọn câu chuyện bạn kể được từng chi tiết.

Dự họp thì ai cũng làm được. Thứ đáng luyện là rời phòng họp của khách với đúng việc cần làm trong tay.

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

- Ba buổi sáng trong tuần này, trước standup đầu tiên, dành 15 phút viết bản triage theo template P0/P1/P2 cho các tin nhắn và ticket gửi đến từ tối hôm trước.
- Chọn một yêu cầu mơ hồ gần đây của product owner hoặc khách, hỏi lại bằng chuỗi câu hỏi 'hôm nay xem ở đâu, thấy sớm hơn thì làm gì khác, cần biết trước bao lâu', rồi viết ra task có tiêu chí hoàn thành.
- Viết lại một dòng trong CV, nêu cụ thể bạn từng làm việc theo nhịp của người dùng hoặc khách hàng: dự họp của ai, triage cái gì, kết quả ra sao.

## Nguồn

- [What is a forward deployed engineer? A complete guide (Paraform)](https://www.paraform.com/insights/what-is-a-forward-deployed-engineer)

- [A Day in the Life of a Forward Deployed Engineer: What the Work Actually Looks Like (FDE Academy)](https://fde.academy/blog/day-in-the-life-of-a-forward-deployed-engineer)

- [A Day in the Life of a Forward Deployed Engineer: Real-World Tasks and Challenges (Blockchain Council)](https://www.blockchain-council.org/ai/day-in-the-life-forward-deployed-engineer/)

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

- [Forward Deployed Software Engineer - US Government (Palantir, Lever)](https://jobs.lever.co/palantir/18a21bae-84ff-4f08-904b-10eb7511f65f)