Từ solutions engineer sang FDE: đưa bản demo lúc chào bán thành code chạy production

Thử hình dung: hợp đồng vừa được ký. Bản demo bạn dựng trong vòng bán hàng đã thuyết phục được khách, và giờ khách muốn nó chạy thật, trên dữ liệu thật, cho người dùng thật. Ba tháng sau, nếu hệ thống sập lúc 2 giờ sáng thì ai phải dậy xử lý?

Bài so sánh hai vai trò trên Scaler trả lời thẳng: người đó là FDE, không phải solutions engineer (SE). Khác biệt giữa hai nghề nằm gần như trọn trong câu trả lời ấy.

SE làm việc trong chu kỳ bán hàng để chứng minh sản phẩm có thể chạy cho khách, còn FDE được cử thẳng vào bài toán của khách để bảo đảm sản phẩm thực sự chạy trong production.

Nếu bạn là SE muốn sang FDE, phần lớn kỹ năng của bạn vẫn dùng được: hiểu khách, nói chuyện kỹ thuật, dựng nhanh. Thứ bạn phải học thêm là một cách nghĩ khác hẳn. Nhiệm vụ không còn là làm khách tin, mà là gánh hậu quả khi bản demo gặp đời thực.

Khác nhau ở chữ “có thể” và chữ “đang”

Paraform mô tả cách chia việc rất gọn: SE bán tầm nhìn, FDE xây nó, customer engineer bảo trì nó. SE làm việc chủ yếu ở giai đoạn trước bán hàng, còn FDE nhận việc từ đúng chỗ SE dừng lại. Hai vai trò nối tiếp nhau trên cùng một khách hàng, nhưng thước đo thành công thì khác hẳn.

Hapy viết rằng một chatbot demo có thể dựng trong một tuần. Phần khó là làm cho workflow đó chạy ổn định bên trong một tổ chức thật. Kunal Ganglani gọi khoảng cách giữa “demo chạy được” và “đã deploy production ở chỗ khách” là cực lớn, còn Hapy đặt tên cho vùng ở giữa: FDE là người sở hữu “khúc giữa lộn xộn” đó.

Thêm một chi tiết mà SE hay bỏ qua: FDE viết code production, nhưng không viết cho core product. Code của bạn là code riêng cho từng khách, như connector, pipeline, logic nghiệp vụ, chạy trong môi trường của họ. Vì thế bạn cần đủ kỷ luật engineering để nó sống được lâu, mà vẫn không biến nó thành một bản fork của sản phẩm.

Đi hết một bản demo tới production

Lấy một ví dụ giả định. Bạn từng demo cho một chuỗi bán lẻ một chatbot trả lời câu hỏi về chính sách đổi trả. Demo dùng một file CSV xuất tay từ hệ thống đơn hàng, hai mươi câu hỏi soạn sẵn, và chạy trên laptop của bạn; khách gật đầu, và giờ bạn là FDE của dự án.

Bước đầu tiên không phải là viết code. Bạn ngồi viết ra mọi thứ bản demo đã âm thầm giả định, rồi với mỗi giả định ghi xem production đòi hỏi gì và ai sở hữu nó. Bảng dưới là một phần của danh sách đó.

Demo đã giả định	Production đòi hỏi	Ai sở hữu
Dữ liệu là file CSV tĩnh	Đọc trực tiếp từ hệ thống đơn hàng, có lịch đồng bộ và cảnh báo khi dữ liệu cũ	FDE, cùng đội IT của khách
Câu hỏi đã soạn sẵn	Câu hỏi lạ, sai chính tả, hỏi ngoài phạm vi, kèm cách trả lời “không biết”	FDE, cùng người phụ trách nghiệp vụ
API luôn trả lời	Timeout, retry, fallback khi dịch vụ chậm hoặc sập	FDE
Một người dùng là bạn	Phân quyền, log truy vết, dữ liệu khách không rời khỏi môi trường của họ	FDE, cùng đội bảo mật
Có người ngồi cạnh sửa lỗi	Runbook, cảnh báo, người trực khi hệ thống lỗi lúc 2 giờ sáng	FDE

Cột cuối mới là chỗ cú chuyển nghề lộ ra. Trong demo, cột này để trống vì chẳng có gì cần sở hữu. Trong production, ô nào còn trống là một sự cố đang chờ xảy ra.

Hãy nhìn dòng thứ ba ở dạng code. Phiên bản demo thường chỉ có một dòng gọi thẳng API. Phiên bản production cần trả lời được câu hỏi: khi phía sau chậm hoặc chết, người dùng thấy gì và người trực đọc được gì?

import logging, time
import requests

log = logging.getLogger("returns_bot")
MAX_ATTEMPTS = 3

def get_order(order_id: str) -> dict | None:
    # Phiên bản demo: return requests.get(f"{API}/orders/{order_id}").json()
    for attempt in range(MAX_ATTEMPTS):
        try:
            r = requests.get(f"{API}/orders/{order_id}", timeout=5)
            r.raise_for_status()
            return r.json()
        except requests.RequestException as e:
            log.warning("order_api_fail order=%s attempt=%d err=%s", order_id, attempt, e)
            if attempt < MAX_ATTEMPTS - 1:  # không chờ thêm sau lần thử cuối
                time.sleep(2 ** attempt)
    log.error("order_api_down order=%s", order_id)
    return None  # Tầng trên trả lời: "Hệ thống đơn hàng đang bận, vui lòng thử lại sau"

Đoạn code không có gì cao siêu. Cái khác nằm ở cách nghĩ: mỗi dòng log được viết cho một người sẽ đọc nó lúc nửa đêm, và người đó rất có thể chính là bạn.

Buổi bàn giao là nơi giả định ẩn mình

Bảng giả định ở trên dễ viết khi chính bạn dựng demo. Nhưng nếu bạn là FDE nhận dự án từ một SE khác, nhiều giả định sẽ không nằm trong slide hay repo nào cả. Chúng nằm trong trí nhớ của người đã ngồi demo, và một buổi bàn giao trôi chảy thường là dấu hiệu chúng chưa được nói ra.

Một mẹo thực dụng: đừng để SE trình bày lại bản demo, vì họ sẽ lặp lại đúng đường đi đẹp nhất. Hãy hỏi những câu buộc họ kể phần hậu trường. Dữ liệu nào đã được làm sạch tay trước buổi demo? Câu hỏi nào của khách từng làm demo trả lời sai? Có điều gì đã hứa miệng mà không nằm trong hợp đồng?

Câu trả lời ngập ngừng, hoặc kiểu “cái đó chắc chạy thôi”, chính là dòng tiếp theo cho bảng giả định. Ghi chúng lại ngay trong buổi bàn giao rẻ hơn nhiều so với phát hiện chúng ở sự cố đầu tiên.

Các bước để tự làm với dự án của mình

Hãy bắt đầu bằng danh sách giả định như bảng trên, viết ngay trong tuần đầu sau khi ký hợp đồng và rà lại cùng khách. Tiếp theo, chạy bản demo trên một mẫu dữ liệu và câu hỏi thật của khách, rồi ghi lại chỗ nó gãy trước khi hứa bất cứ mốc thời gian nào. Danh sách chỗ gãy đó chính là backlog đầu tiên của bạn.

Sau đó, viết runbook trước khi go-live, không phải sau sự cố đầu tiên. Runbook trả lời ba câu: cảnh báo nào báo cho ai, kiểm tra gì trước, và tắt tính năng bằng cách nào mà không làm hỏng phần còn lại. Nếu bạn không viết nổi runbook thì hệ thống chưa sẵn sàng.

Bước cuối hay bị quên nhất. Hapy coi việc đưa các pattern ngược về đội product, để việc làm một lần cho một khách trở thành năng lực dùng lại được, là nhiệm vụ cốt lõi của FDE. Mỗi khi bạn viết lần thứ hai cùng một connector cho khách thứ hai, hãy mở ticket cho đội product.

Những lỗi SE hay mắc ở năm đầu

Lỗi đầu tiên là bản năng demo: giấu các góc khó để buổi trình bày trôi chảy. Ở vai FDE, góc khó phải được lôi ra sớm nhất có thể, vì giấu nó đi chỉ dời sự cố sang lúc tốn kém hơn. Bạn sẽ thấy mình phải nói “chỗ này chưa chạy được” với khách nhiều hơn hẳn so với hồi làm SE.

Lỗi thứ hai là sửa thẳng vào core product cho nhanh, hoặc ngược lại, viết code riêng cho khách cẩu thả vì nghĩ đó “chỉ là tích hợp”. Code riêng cho khách vẫn là code production, vẫn cần test, log và review. Cái khác chỉ là phạm vi, không phải chất lượng.

Lỗi thứ ba sâu hơn và nằm ở chính bạn. Paraform cảnh báo rằng một SE demo xuất sắc có thể hoàn toàn không muốn viết code production sáu tháng liền. Kỹ năng demo không chứng minh được bạn có hứng thú với việc đó, nên hãy thử nó trước khi nộp đơn.

Chứng minh kỹ năng này khi đi xin việc

Tin tuyển Forward Deployed Software Engineer của Palantir mô tả việc là làm trực tiếp với khách để nhanh chóng hiểu những vấn đề lớn nhất của họ, rồi thiết kế và triển khai giải pháp. Tin đó cũng nhấn mạnh làm trong nhóm nhỏ, ít giám sát, và sở hữu end-to-end những dự án có rủi ro cao.

Khi đọc tin tuyển FDE, hãy tìm đúng những chữ như “own”, “end-to-end”, “implement”: đó là tín hiệu công ty cần người gánh production chứ không chỉ người trình bày. Trên CV, đừng chỉ viết “dựng demo giúp chốt hợp đồng”.

Hãy viết về một hệ thống bạn vẫn chịu trách nhiệm sau khi bàn giao: nó chạy trên dữ liệu gì, bạn xử lý sự cố nào, bạn đã đưa pattern nào về cho đội product.

Khi phỏng vấn, hỏi ngược lại ai sẽ được gọi khi hệ thống của khách lỗi. Câu trả lời sẽ cho bạn biết vị trí đó là FDE thật hay SE mang tên mới.

Bài tập: đặt bản demo gần nhất lên bàn mổ

Lấy bản demo gần nhất bạn từng trình bày và dựng bảng giả định như ở trên, với ít nhất mười dòng và cột “ai sở hữu” không được để trống. Sau đó chọn ô khó nhất và viết phần code hoặc runbook cho nó. Nếu làm xong mà bạn thấy hứng thú hơn cả lúc dựng demo, bạn đã có câu trả lời cho câu hỏi chuyển nghề.