# FDE và kỹ sư triển khai: ranh giới nằm ở dòng code mới đầu tiên

> Hai kỹ sư cùng ngồi ở văn phòng khách hàng, cùng đưa một sản phẩm vào chạy, nhưng chỉ một người được giao viết thứ mà sản phẩm chưa có.

Bản gốc: https://fdetimes.net/vi/bach-khoa/fde-vs-implementation-engineer/

Sang tuần thứ hai của dự án, bảng cấu hình đã điền xong, người dùng đã có tài khoản và dữ liệu mẫu đã nạp vào. Rồi khách hỏi một câu mà không ô nào trên màn hình admin trả lời được. Ai xử lý câu hỏi đó, và xử lý bằng cách nào, cho biết bạn đang làm việc của kỹ sư triển khai hay của FDE.

Hai vai này dễ bị nhầm với nhau, vì cả hai đều ngồi ở khách và đều đưa phần mềm vào chạy.

Nhưng một người làm việc bên trong giới hạn của sản phẩm, còn người kia được trả lương để vượt qua giới hạn đó. Hiểu rõ ranh giới này giúp bạn nhận đúng việc khi đang ở dự án, và ứng tuyển đúng vai khi muốn chuyển nghề.

## Cùng ngồi ở khách, nhưng cầm công cụ khác nhau

Rocketlane, một nền tảng cho đội professional services, mô tả kỹ sư triển khai là người thực thi một playbook đã định sẵn: cấu hình, setup rồi bàn giao. FDE Academy, một trang đào tạo thương mại nên cần đọc có chọn lọc, nói rõ hơn: họ chủ yếu dùng công cụ cấu hình có sẵn của sản phẩm chứ không viết code mới.

TechTarget cũng phân chia như vậy: đội triển khai SaaS cài đặt, cấu hình và tùy biến một sản phẩm lõi, còn FDE xây phần mềm riêng theo nhu cầu của khách.

Ranh giới thực tế được Rocketlane tóm trong một câu: FDE được gọi đến khi playbook không còn đủ. Vậy thứ quyết định ai nhận việc là loại vấn đề cần giải, chứ không phải cấp bậc của người làm. Nếu bài toán nằm gọn trong những gì sản phẩm đã thiết kế sẵn, làm theo playbook là cách nhanh và rẻ nhất.

Khi bài toán nằm ngoài playbook, công việc đổi hẳn tính chất. TechTarget coi FDE là một mô hình phát triển phần mềm chứ không chỉ là một chức danh: kỹ sư gắn với một khách và dành toàn bộ thời gian cho khách đó.

Người làm vai này phải viết được cả prototype nhanh lẫn nền tảng chạy production ở quy mô lớn. SD Times mô tả trình tự: nắm hết nhu cầu và năng lực của khách, rồi tự tay xây giải pháp. Đội cũng nhỏ, thường không quá sáu chuyên gia.

## Một dự án, hai điểm rẽ

Thử hình dung một công ty bán phần mềm quản lý kho, đang triển khai cho một chuỗi bán lẻ. Danh sách yêu cầu sau buổi discovery có bốn dòng. Việc đầu tiên là phân loại từng dòng, trước khi ai mở editor.

| Yêu cầu của khách | Cấu hình được không? | Ai nhận |
|---|---|---|
| Tạo kho theo từng chi nhánh, phân quyền theo vai trò | Có, màn hình admin hỗ trợ sẵn | Kỹ sư triển khai |
| Nạp danh mục hàng hóa ban đầu từ CSV | Có, đã có công cụ import | Kỹ sư triển khai |
| Đồng bộ tồn kho từ ERP cũ, vốn chỉ xuất file định dạng cố định độ rộng, 15 phút một lần | Không, sản phẩm không có connector cho định dạng này | FDE |
| Quy tắc đặt hàng lại theo mùa vụ riêng của chuỗi | Một phần: ngưỡng tối thiểu thì có, logic theo mùa thì không | Cần tách ra |

Hai dòng đầu là việc trong playbook. Làm bằng code thì sai, vì khách sẽ phải bảo trì thứ mà sản phẩm vốn đã làm được. Dòng thứ ba là chỗ playbook không còn đủ, và cũng là ví dụ rõ nhất cho việc FDE viết code mới cho đúng một khách hàng.

Dòng thứ tư là chỗ cần nghĩ kỹ nhất. Cách làm đúng là để kỹ sư triển khai cấu hình phần ngưỡng tối thiểu bằng công cụ có sẵn, còn FDE chỉ viết phần logic mùa vụ mà sản phẩm không có. Một yêu cầu thường chứa cả hai loại việc, và kỹ năng ở đây là tách chúng ra.

## Code mới phải sống được sau khi bạn rời đi

Với dòng thứ ba, phiên bản đầu tiên có thể chỉ vài chục dòng. Đoạn dưới đây là phác thảo minh họa, không lấy từ dự án thật nào:

```python
FIELDS = [("sku", 0, 12), ("warehouse", 12, 18), ("qty", 18, 26)]

def parse_line(line: str) -> dict:
    row = {name: line[start:end].strip() for name, start, end in FIELDS}
    row["qty"] = int(row["qty"] or 0)
    return row

def sync(path: str, client) -> int:
    with open(path, encoding="latin-1") as f:
        rows = [parse_line(l) for l in f if l.strip()]
    # upsert theo (sku, warehouse): chạy lại cùng một file không nhân đôi tồn kho
    client.upsert_stock(rows, key=("sku", "warehouse"))
    return len(rows)
```

Đoạn này chạy được trong một buổi chiều, và đó là phần prototype. TechTarget chỉ nói FDE phải viết được thứ có thể mở rộng và triển khai production. Với đoạn sync này, phần production nghĩa là: chạy lại không làm sai dữ liệu, có log khi một dòng không parse được, có cảnh báo khi file 15 phút không về.

Đoạn code chỉ có một dòng ghi chú, đặt ngay cạnh khóa upsert, chỗ dễ sai nhất. Lý do là người tiếp quản sẽ cần biết vì sao code được viết như vậy.

## Ba câu hỏi trước khi viết dòng code đầu tiên

Câu đầu tiên là sản phẩm có công cụ nào làm được việc này không, kể cả khi làm không đẹp. Hãy hỏi kỹ sư triển khai hoặc đọc tài liệu cấu hình trước. Nếu câu trả lời là có, thì code của bạn chỉ là một khoản nợ bảo trì mới.

Câu thứ hai là phần nào cấu hình được và phần nào thì không. Như dòng thứ tư ở trên cho thấy, câu trả lời thường là "một phần". Bạn hãy viết ra ranh giới ấy bằng một câu và gửi cho cả hai phía trước khi bắt tay vào làm.

Câu thứ ba là ai sẽ chạy đoạn code này sau khi bạn rời dự án. Kỹ sư triển khai kết thúc bằng bàn giao, và FDE cũng phải bàn giao, chỉ là thứ được bàn giao là code chứ không phải màn hình cấu hình. Nếu bạn chưa trả lời được câu này thì nên dừng ở prototype.

## Những lỗi hay gặp ở cả hai phía

Một lỗi hay gặp ở phía FDE là viết code cho thứ cấu hình được, chỉ vì viết code nhanh hơn đọc tài liệu sản phẩm. Kết quả là khách có hai cơ chế cùng làm một việc, và cơ chế do bạn viết dễ hỏng ở lần nâng cấp sản phẩm kế tiếp.

Lỗi ngược lại thuộc về phía triển khai: cố ép công cụ cấu hình vào một bài toán mà nó không được thiết kế để giải. Khi bạn thấy mình phải chồng ba bốn workaround lên nhau để giả lập một connector, đó là dấu hiệu playbook không còn đủ và đến lúc gọi FDE.

**Điểm mấu chốt:** Code viết ở khách chỉ đáng giá khi đã chứng minh được rằng cấu hình không làm nổi.

Lỗi thứ ba là coi code ở khách là thứ viết xong rồi bỏ đó. FDE gắn với một khách hàng, nhưng code sẽ còn chạy rất lâu sau khi bạn chuyển sang dự án khác.

## Đọc JD để biết bạn đang ứng tuyển vai nào

Tin tuyển Forward Deployed Software Engineer của Palantir là ví dụ dễ đọc. Mục công việc ghi rõ việc phát triển ứng dụng tùy biến theo nhu cầu khách. Mục yêu cầu đòi một người code giỏi, thành thạo Python, Java, C++, TypeScript/JavaScript hoặc ngôn ngữ tương tự. FDE Academy cũng nói vai FDE cần năng lực kỹ sư phần mềm đầy đủ.

So tin đó với tin Deployment Strategist, vai không viết code cùng nhóm ở Palantir, bạn sẽ thấy động từ đổi hẳn. Trọng tâm ở đây là trình bày kết quả và định phạm vi cho các dự án mới ở những ngành và thị trường mới, không phải xây phần mềm.

Khi đọc bất kỳ JD nào, hãy đếm động từ: build và develop nghiêng về FDE, configure nghiêng về kỹ sư triển khai, còn scope là động từ của vai strategist như Deployment Strategist.

CV cũng nên được viết theo đúng ranh giới đó. Một dòng như "triển khai sản phẩm cho 5 khách" không cho nhà tuyển dụng biết bạn có viết code hay không. Hãy viết theo mẫu: yêu cầu nào nằm ngoài khả năng của sản phẩm, bạn đã viết gì, và nó đang chạy production ở đâu.

Nếu bạn đang làm kỹ sư triển khai và muốn chuyển sang FDE, con đường ngắn nhất thường không phải là xin chức danh mới. Hãy để ý lần tới playbook không còn đủ, giơ tay nhận phần việc đó, và viết code sao cho người khác tiếp quản được.

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

- Lấy danh sách yêu cầu của một dự án gần đây, gắn nhãn từng dòng là 'cấu hình được' hoặc 'cần code mới', kèm một câu lý do.
- Mở hai JD, một FDE và một implementation hoặc deployment, rồi gạch chân mọi động từ: build/develop, configure hay scope.
- Viết lại một gạch đầu dòng trong CV theo mẫu: yêu cầu nào sản phẩm không đáp ứng được, bạn đã viết gì, nó chạy ở đâu.

## Nguồn

- [When should you adopt the forward-deployed model?](https://www.techtarget.com/searchapparchitecture/tip/When-should-you-adopt-the-forward-deployed-model)

- [Forward deployed engineers vs. software engineers: What PS leaders need to know in 2026](https://rocketlane.com/blogs/forward-deployed-engineer-vs-software-engineer)

- [Forward deployed engineer vs implementation engineer](https://fde.academy/blog/forward-deployed-engineer-vs-implementation-engineer)

- [Forward-Deployed Engineers vs. Implementation Consultants: The Crucial Distinctions](https://sdtimes.com/software-engineering/forward-deployed-engineers-vs-implementation-consultants-the-crucial-distinctions/)

- [Forward Deployed Software Engineer (Palantir, Lever)](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0)

- [Deployment Strategist (Palantir, Lever)](https://jobs.lever.co/palantir/4e99e055-96c7-497e-8099-3318e1ce0626)