Khi đội IT của khách coi FDE là mối đe doạ: cách biến họ thành người cùng sở hữu hệ thống

Thử hình dung tuần đầu tiên của bạn ở chỗ khách. Bạn cần quyền đọc vào cơ sở dữ liệu đơn hàng, nhưng ticket gửi đi đã ba ngày mà chưa ai trả lời. Trong buổi họp kỹ thuật, trưởng nhóm IT ngồi khoanh tay và câu nào cũng đáp: “để kiểm tra lại”.

Họ không bất lịch sự. Đặt mình vào chỗ họ: một người lạ được ban lãnh đạo mời vào để làm thứ mà lẽ ra đội họ phải làm.

Palantir ví công việc của Forward Deployed Software Engineer với vai trò CTO một startup: nhóm nhỏ, chịu trách nhiệm từ đầu đến cuối, và thường làm ngay tại chỗ khách. Với phạm vi như vậy, bạn sẽ làm đúng những việc vốn thuộc về đội IT.

Ngay cả khi khách quý bạn, họ vẫn thấy bạn là người ngoài. First Round Review kể rằng General Counsel của một công ty trong Fortune 100 trìu mến gọi đội kỹ sư mà Ironclad cử sang là “The Backpacks”, tức “đội ba lô”. Cái tên nghe thân thiện, nhưng ý của nó là những người đeo ba lô đến rồi cũng sẽ đeo ba lô đi.

Vì sao bạn không làm được việc nếu thiếu họ?

Bạn có thể đi vòng qua đội IT bằng cách nhờ người bảo trợ dự án bên phía lãnh đạo ép họ. Cách đó sẽ phản tác dụng rất nhanh. Một cựu nhà tuyển dụng FDE của Palantir nói với First Round Review rằng thứ bạn phát hiện ở chỗ khách sẽ khác rất xa thứ đã bán trong hợp đồng.

Trưởng bộ phận FDE của OpenAI cũng nói điều tương tự với The Pragmatic Engineer: thứ khách mô tả lúc scoping thường không khớp với dữ liệu và hệ thống thật.

Người biết khoảng cách đó nằm ở đâu, chẳng hạn bảng nào chứa dữ liệu rác hay job nào chạy lúc 2 giờ sáng rồi khoá bảng, gần như luôn là đội IT.

Đẩy họ ra ngoài thì bạn mất đúng nguồn thông tin bạn cần nhất.

Vì thế câu hỏi không phải là làm sao để vượt qua đội IT. Câu hỏi là họ sợ điều gì, và bạn trả lời nỗi sợ đó ra sao.

Đổi câu chuyện: bạn đến để rời đi

Đội IT thường sợ hai điều. Họ sợ bị thay thế, và họ sợ bị bỏ lại với một hệ thống họ không hiểu, đến khi nó hỏng lúc nửa đêm thì người gánh là họ. Hai nỗi sợ này có chung một lời giải.

Một hướng dẫn về bàn giao dự án FDE trên Simpliaxis đặt mục tiêu rất rõ: đội của khách phải vận hành và phát triển tiếp được hệ thống mà không cần liên lạc với bạn.

Bài viết còn lật lại góc nhìn: việc khiến mình trở nên không còn cần thiết không làm giảm giá trị của bạn, mà chính là bằng chứng cho giá trị đó. Một bài trên CIO.com về FDE thời agentic AI cũng khuyên thiết kế sẵn cho việc chuyển giao quyền sở hữu, để đội của khách vận hành và mở rộng được hệ thống.

Khi bạn nói điều này ngay buổi đầu và hành động đúng như vậy, bạn không còn là người đến chiếm chỗ. Bạn trở thành người giúp họ làm chủ một hệ thống mới.

Ví dụ: agent tồn kho và đội IT bốn người

Thử hình dung bạn triển khai một agent trả lời câu hỏi về tồn kho cho một nhà bán lẻ. Agent phải đọc dữ liệu từ hệ thống ERP do một đội IT bốn người quản lý. Có ba việc cần làm theo thứ tự.

Bước một: buổi gặp 30 phút trước khi viết dòng code nào. Đừng mở đầu bằng việc xin quyền. Hãy hỏi về hệ thống thật: “Bảng tồn kho được cập nhật theo lô hay theo thời gian thực? Lần gần nhất số liệu sai là vì sao? Có thứ gì trên hệ thống mà các anh chị không muốn ai chạm vào?” Câu cuối quan trọng nhất, vì nó cho họ quyền vạch ranh giới.

Kết thúc buổi gặp bằng một câu cam kết: “Đến cuối dự án, đội anh chị phải tự sửa và mở rộng được agent này mà không cần gọi cho bên vendor. Lịch làm việc sẽ được thiết kế quanh mục tiêu đó.”

Bước hai: đưa bảo mật vào tuần đầu. Bài trên CIO.com nhấn mạnh rằng quản trị trong agentic AI không thể là một checklist tuân thủ đem ra kiểm ở bước cuối. ElevenLabs viết rằng với đội FDE của họ, bảo mật, quyền kiểm soát dữ liệu và tuân thủ quy định là bắt buộc ngay từ đầu.

Vậy hãy mang đến một trang mô tả luồng dữ liệu: agent chỉ có quyền đọc (read-only) vào ba bảng nào, log nằm ở đâu, prompt có chứa dữ liệu khách hay không.

Để đội bảo mật gạch chỗ nào cũng được. Một thay đổi bị yêu cầu ở tuần đầu chỉ tốn vài giờ, còn nếu nó đến ở tuần cuối thì có thể chặn luôn ngày go-live.

Bước ba: cùng thiết kế và cùng code. Hướng dẫn trên Simpliaxis đưa ra ba việc cụ thể: mời kỹ sư của khách vào các quyết định thiết kế, pair programming với họ khi build, và giải thích lý do của bạn trong lúc làm. ElevenLabs mô tả FDE của họ làm việc sát cánh với đội kỹ thuật của khách, ngay trong hạ tầng của khách.

Ở ví dụ tồn kho, việc này có nghĩa là một nhật ký quyết định (decision log) nằm trong repo chung, cộng với hai buổi pair mỗi tuần, mỗi buổi với một người khác trong đội bốn người. Một mục trong nhật ký có thể ngắn như sau:

QĐ-03: Cache kết quả truy vấn tồn kho 15 phút
Lý do: không gọi thẳng vào ERP mỗi lần agent trả lời
Phương án đã loại: đọc trực tiếp bảng tồn kho theo thời gian thực
Người cùng quyết: [tên kỹ sư của khách]
Muốn đổi thì sửa ở: file cấu hình cache, đội IT tự làm được

Dòng “người cùng quyết” là chi tiết đáng giá nhất. Nó biến quyết định của bạn thành quyết định chung, và cho người đọc sau này biết nên hỏi ai khi bạn đã rời đi.

Hướng dẫn trên Simpliaxis giải thích vì sao cách này hiệu quả: kỹ sư build cùng đội của khách thì bàn giao liên tục suốt dự án, nên lần chuyển giao cuối cùng chỉ còn rất nhỏ. Đến tuần cuối, sẽ không còn buổi “đào tạo bàn giao” nào kéo dài ba ngày nữa.

Câu chữ nào làm đội IT dịu lại?

Phần lớn sự đề phòng bắt đầu từ cách bạn mở lời. Bạn vẫn xin được đúng thứ mình cần, chỉ cần đổi cách nói:

Thay vì nói	Hãy nói
“Cho quyền admin vào ERP để làm nhanh hơn.”	“Chỉ cần quyền read-only vào ba bảng này. Anh chị xem có bảng nào nên loại ra không?”
“Phần này để tôi lo, các anh chị không cần bận tâm.”	“Mình pair phần này nhé, vì sau này đội anh chị sẽ là người sửa nó.”
“Demo cho lãnh đạo vào thứ Sáu.”	“Thứ Năm chạy thử cùng đội IT trước, thứ Sáu đội anh chị cùng trình bày.”
“Bảo mật để giai đoạn sau.”	“Đây là sơ đồ luồng dữ liệu, mời đội bảo mật xem trước khi build.”

Năm lỗi khiến đồng minh quay sang chặn bạn

Lỗi phổ biến nhất là đi đường tắt qua người bảo trợ dự án mỗi khi IT chậm trả lời. Bạn thắng được một ticket nhưng mất cả đội. Lỗi thứ hai là xin quyền rộng hơn mức cần, vì việc đó xác nhận đúng nỗi sợ của đội bảo mật.

Lỗi thứ ba là demo cho lãnh đạo mà không mời đội IT, khiến họ biết tin về hệ thống chạy trên hạ tầng của chính mình qua người khác.

Lỗi thứ tư là viết code mà chỉ mình bạn hiểu: không có decision log, không có runbook, mọi thứ nằm trong đầu bạn. Lỗi thứ năm là để bảo mật đến cuối, đúng thứ mà cả CIO.com lẫn ElevenLabs đều cảnh báo.

Kỹ năng này lên CV thế nào?

Khi đọc mô tả công việc FDE, hãy để ý những cụm như “work side-by-side with technical teams” hay “handoff”, “enablement”. Nếu chúng xuất hiện, đó là dấu hiệu công ty quan tâm đến việc bàn giao cho khách chứ không chỉ việc build.

Khi đi phỏng vấn, hãy chuẩn bị sẵn một câu chuyện về lần bạn kéo một đội đang dè chừng vào cùng làm. Kể cụ thể bạn đã hỏi gì ở buổi gặp đầu, mời bảo mật vào lúc nào và pair với ai.

Trên CV, hãy viết về kết quả của việc bàn giao: đội của khách có bao nhiêu kỹ sư, bao lâu sau khi bạn rời đi thì họ tự vận hành được, và họ đã tự thêm tính năng nào.

Những con số đó phải là số thật của bạn. Chúng bám sát đúng mục tiêu mà các hướng dẫn về bàn giao FDE đặt ra: đội của khách tự vận hành và mở rộng được hệ thống mà không cần bạn.

Thước đo cuối cùng khá đơn giản. Hệ thống vẫn chạy sau ngày bạn đeo ba lô rời đi, và người đang sửa nó chính là trưởng nhóm từng khoanh tay trong buổi họp đầu tiên.