Ở Ema, người dựng demo cũng là người đưa nó lên production

Bạn vừa demo xong một agent xử lý yêu cầu cấp quyền IT cho nhân viên mới. Cả phòng họp gật đầu, khách đồng ý ký. Sáng thứ Hai, chính bạn là người phải biến bản demo ấy thành hệ thống chạy cho người dùng thật. Đến lúc đó, đường tắt nào bạn đi trong demo cũng sẽ quay lại đòi nợ.

Ở Ema, đây là công việc hằng ngày của Forward Deployed Builder. Tin tuyển dụng chính thức của công ty mô tả người này làm việc ngay bên trong khách hàng và đối tác, và nói rõ đây không phải một vị trí hỗ trợ đứng sau account team.

Một người gộp ba vai account lead, solutions architect và builder, làm on-site theo từng đợt luân phiên ở EMEA và Bắc Mỹ.

Vì thế kỹ năng cốt lõi ở đây không phải là demo cho đẹp. Bạn phải dựng demo như phiên bản số 0 của production, bởi người phải sống với hậu quả của từng quyết định trong demo chính là bạn. Kỹ năng này dùng được cho mọi FDE, kể cả khi công ty bạn tách riêng người bán và người triển khai.

Bốn việc, một người

Bản tin tuyển dụng Ema đăng trên job board của Accel chia công việc thành bốn bước. Đầu tiên, bạn lấy một quy trình nghiệp vụ thật đang rối và thiết kế lại thành một flow agentic gọn trên nền tảng Ema. Sau đó bạn tự tay dựng demo chạy được, một bằng chứng cho thấy giá trị rõ đến mức khách không còn gì để bác bỏ.

Bước thứ ba là chốt hợp đồng. Theo tin tuyển dụng, builder là người khiến khách hết lý do để nghi ngờ giải pháp, và hợp đồng về tay nhờ vậy. Bước cuối là biến hợp đồng đã ký thành một workflow agentic chạy trên production mà khách tin dùng và thực sự áp dụng.

Bối cảnh sản phẩm giải thích vì sao phải gói cả bốn bước vào một người. Ema mô tả sản phẩm của mình là các hệ thống agentic lên kế hoạch và thực thi workflow doanh nghiệp trong HR, IT, tài chính, với hơn 250 tích hợp ứng dụng. Ai cũng có thể vẽ một workflow chạm vào năm hệ thống trên slide. Chạy được thật thì khó hơn nhiều.

Bước thiết kế bắt đầu từ discovery

Thử hình dung khách là một công ty cỡ vừa. Mỗi khi có nhân viên mới, HR gửi email cho quản lý, quản lý trả lời “ok”, IT tự tạo tài khoản trên vài hệ thống khác nhau, và không ai biết yêu cầu đang kẹt ở khâu nào. Đây chính là loại quy trình rối mà tin tuyển dụng nhắc tới.

Muốn thiết kế lại nó, bạn cần làm discovery trước khi viết dòng code nào. Đội Forward Deployment Engineering riêng của Ema mô tả buổi workshop discovery xoay quanh bốn thứ: người ta đang làm việc thế nào, họ khổ ở đâu, dữ liệu chảy đi đâu và cần tích hợp gì.

Đừng bỏ sót mục nào trong bốn mục đó. Rồi thêm một câu nữa, thường mở ra nhiều chuyện nhất: “Lần gần nhất quy trình này hỏng là khi nào?”

Kết quả của buổi đó nên là một bản đặc tả ngắn, đủ cụ thể để dựng được ngay:

flow: cap-quyen-nhan-vien-moi
trigger: HR tạo hồ sơ nhân viên trong hệ thống HR
steps:
  - doc_ho_so: lấy phòng ban, chức danh, ngày bắt đầu
  - de_xuat_quyen: agent đề xuất danh sách quyền theo chức danh
  - xin_duyet: gửi quản lý trực tiếp, chờ phản hồi
  - tao_tai_khoan: gọi API từng hệ thống đích
  - bao_cao: gửi tóm tắt cho HR và nhân viên mới
exceptions:
  - quan_ly_khong_tra_loi_48h: nhắc lại, sau đó chuyển cấp trên
  - chuc_danh_khong_co_mau: dừng, hỏi IT, bổ sung mẫu quyền cho chức danh mới
  - api_loi: thử lại, sau đó mở ticket cho người xử lý

Phần exceptions mới là phần đáng giá. Đường đi suôn sẻ thì khách tự hình dung được. Thứ khách cần thấy là agent xử lý thế nào khi mọi thứ trục trặc.

Demo nào thắng được tranh luận kỹ thuật?

Thử hình dung buổi chốt hợp đồng, và người hỏi khó là trưởng phòng IT của khách: “Nếu quản lý đi nghỉ phép thì sao?”, “Agent có tự cấp quyền admin không?”. Một demo chỉ có đường suôn sẻ sẽ thua ở đúng những câu như thế. Một demo chạy được nhánh quan_ly_khong_tra_loi_48h ngay trước mặt họ thì có câu trả lời sẵn.

Đây cũng là lý do Ema đặt ra yêu cầu kỹ thuật: đủ khả năng viết một ít code và dùng nền tảng agentic để dựng một demo thật, chứ không chỉ nói về nó. Ngưỡng này không đòi bạn phải là kỹ sư hạ tầng. Nó đòi bạn không được giả lập thứ mà sau này bạn không giao được.

Khía cạnh	Demo để vứt đi	Demo là phiên bản số 0
Dữ liệu	Hồ sơ mẫu tự gõ tay	Một hồ sơ thật đã ẩn danh từ hệ thống HR của khách
Tích hợp	Màn hình giả trông như đã gọi API	Gọi thật ít nhất một hệ thống đích, phần còn lại ghi rõ là giả lập
Ngoại lệ	Không có	Chạy được ít nhất một nhánh trước mặt khách
Sau ngày ký	Viết lại từ đầu	Mở rộng từ chính bản đặc tả đã demo

Cột bên phải tốn thêm vài ngày. Đổi lại, khi bạn ở lại triển khai, những gì đã hứa trong phòng họp đều có sẵn một đoạn code đứng sau.

Từ bản thiết kế đến SLO

Sau ngày ký, đừng để bản đặc tả nằm yên trong thư mục demo. Đội FDE của Ema viết và duy trì một design doc cho mỗi “AI Employee”, dẫn dắt việc triển khai từ bản thiết kế cho tới SLO. Đó là một thói quen nên học: tài liệu không dừng ở sơ đồ, nó kết thúc bằng những con số mà khách có thể kiểm tra.

Với flow cấp quyền ở trên, một design doc tối thiểu có thể trông như sau. Các ngưỡng trong đó chỉ là ví dụ minh hoạ; con số thật bạn chốt cùng khách trước ngày go-live.

ai_employee: cap-quyen-nhan-vien-moi
pham_vi:
  trong: hệ thống HR (chỉ đọc), email, 2 hệ thống đích có API
  chua_gom: hệ thống tài chính (giai đoạn 2)
quyen_cua_agent:
  - chỉ tạo tài khoản với quyền thường theo mẫu chức danh
  - quyền admin luôn cần IT duyệt, agent không tự cấp
ngoai_le: giữ nguyên 3 nhánh trong đặc tả đã demo
slo:
  tu_dong_hoan_tat: ">= 80% yêu cầu xong mà không cần người can thiệp"
  thoi_gian: "95% nhân viên mới có đủ tài khoản trong 1 ngày làm việc"
  muc_su_dung: ">= 90% yêu cầu cấp quyền đi qua flow thay vì email"
do_luong:
  nguon: log của flow, đối chiếu hộp thư IT mỗi tuần
  danh_gia: 4 tuần sau go-live

Chú ý dòng quyền admin: câu hỏi khó trong buổi chốt hợp đồng giờ thành một ràng buộc viết ra giấy. Mỗi SLO cũng có đủ ba thứ: ngưỡng, nơi đo và thời điểm đánh giá.

Chữ quan trọng trong mô tả bước cuối của Ema là “adopts”, tức khách thực sự dùng. Một workflow chạy được nhưng HR vẫn quay về gửi email thì chưa phải production. Đó là lý do dòng muc_su_dung nằm trong SLO, ngang hàng với các chỉ số kỹ thuật.

Những cái bẫy tự giăng cho mình

Lỗi dễ mắc nhất là hứa trong lúc chốt hợp đồng những thứ demo chưa chứng minh. Khi một người vừa bán vừa triển khai, mỗi câu “cái đó làm được” là một ticket bạn sẽ phải tự làm. Nguyên tắc an toàn: chỉ hứa những gì đã chạy, còn lại ghi vào phạm vi giai đoạn sau.

Lỗi thứ hai là bỏ qua người dùng cuối trong discovery. Bạn nói chuyện với người mua, nhưng người phải đổi thói quen là nhân viên HR và quản lý. Nếu họ không có mặt trong workshop, phần “khách tin dùng” sẽ khó ngay từ đầu.

Lỗi thứ ba là dựng tích hợp giả mà không ghi rõ là giả. Lúc đó khách không phân biệt được đâu là thật, và đến ngày go-live bạn mới phát hiện API của hệ thống đích cần một quy trình cấp quyền mất nhiều tuần.

Cho thấy kỹ năng này trên CV thế nào?

Khi đọc tin tuyển dụng FDE ở bất kỳ đâu, hãy tìm những cụm như “embed”, “on-site”, “not a support role” hay mô tả đi trọn từ demo đến production.

Chúng cho bạn biết vị trí đó cần một người làm hết chuỗi, không phải một kỹ sư pre-sales. Tin của Ema cũng không ghi số năm kinh nghiệm cố định, nên thứ bạn mang ra chứng minh là sản phẩm đã làm.

Trên CV, đừng ghi “xây dựng demo AI”. Hãy kể một dự án theo đúng bốn bước: quy trình rối ban đầu là gì, demo chạy nhánh ngoại lệ nào, ai đã đồng ý dựa trên demo đó, và sau khi chạy thật thì SLO đạt bao nhiêu.

Nếu ứng tuyển vào một vai trò kiểu này, bạn nên chuẩn bị sẵn một câu chuyện về khoảng cách giữa demo và production: lần bạn phải tự trả món nợ của chính demo mình dựng, và bạn đã sửa nó thế nào.

Ema đòi một demo thật chứ không phải lời nói về demo, và đòi chính người dựng nó ở lại cho tới khi khách tin dùng. Ở một vai trò như thế, demo đẹp mới là nửa đầu; nửa còn lại là nó vẫn chạy sau ngày ký hợp đồng.