Why, what, how: tách một FDE engagement thành ba câu hỏi trước khi viết code
Databricks neo mỗi FDE engagement vào OKR chung với khách trước khi bắt tay xây, và một tấm brief một trang chia ba tầng giúp bạn khoá phần "what" theo cách tương tự.
Lỗi ở 'how' lộ ra trong log, còn lỗi ở 'why' và 'what' chỉ lộ ra khi bạn chủ động kiểm tra.
Đồ hoạ: FDE Times
Tóm tắt nhanh
- Câu 'chúng tôi cần một agent' mới là một đáp án cho 'how'. FDE phải hỏi ngược lên 'why' và 'what' trước khi mở IDE.
- Databricks neo engagement vào OKR chung với khách. OKR chính là cách khoá phần 'what' trước khi bắt tay vào xây.
- FDE trực tiếp xây phần 'how', còn 'why' và 'what' thường làm chung với Account Executive và Engagement Manager. Làm chung không có nghĩa là FDE được bỏ qua hai tầng này.
Sáng thứ Hai, buổi kickoff với khách hàng. Phó giám đốc vận hành mở đầu bằng một câu rất quen: “Chúng tôi cần một AI agent trả lời khách hàng.” Bạn là FDE trong phòng, và phản xạ đầu tiên của bạn có lẽ là tính xem dùng model nào, lấy dữ liệu từ đâu, deploy lên hạ tầng gì.
Phản xạ đó đúng hướng nhưng sai thời điểm. Câu của khách mới là một đáp án cho câu hỏi “how”, trong khi chưa ai trong phòng trả lời hai câu đứng trước nó: vì sao phải thay đổi, và thay đổi thế nào thì gọi là thành công.
Kỹ năng cần rèn ở đây là tách mỗi engagement thành ba câu hỏi why, what, how. Bạn cần biết rõ câu nào mình trả lời, câu nào mình trả lời cùng người khác, và không viết dòng code đầu tiên khi hai câu đầu còn để trống.
Ba câu hỏi này khác nhau ở đâu?
“Why” là lý do kinh doanh: khách đang mất gì, hoặc đang bỏ lỡ cơ hội gì. “What” là kết quả đo được, tức con số mà cả hai bên đồng ý dùng để chấm dự án. “How” là hệ thống bạn xây: pipeline, model, agent, tích hợp, và cách vận hành sau khi go-live.
Ba tầng này cần tách ra vì mỗi tầng hỏng theo một kiểu. Hỏng “why” thì bạn làm đẹp một thứ không ai cần. Hỏng “what” thì dự án không bao giờ kết thúc, vì chẳng ai biết thế nào là xong. Hỏng “how” thì ít nhất bạn còn thấy được lỗi trong log.
Why/what/how không phải thuật ngữ chính thức của công ty nào, chỉ là một cách chia việc cho dễ nghĩ. Tuy vậy, cách Databricks mô tả tổ chức Forward Deployed Engineering ra mắt tháng 6/2026 cho thấy logic này khá rõ.
Databricks khoá “what” bằng OKR
Trong bài giới thiệu, Databricks kể rằng yêu cầu của khách đã chuyển từ chuyện pipeline hay migration sang các bài toán kinh doanh. Sứ mệnh được nêu là đẩy nhanh kết quả kinh doanh cho khách hàng bằng AI.
Pulse 2.0 mô tả cùng xu hướng đó: khách hàng rời bỏ kiểu consulting làm xong rồi bàn giao, để chuyển sang những đội kỹ sư làm việc ngay bên trong tổ chức của họ và chịu trách nhiệm về kết quả đo được. Đó là phần “why” của cả mô hình.
Phần “what” được ghi thẳng ra: engagement được neo vào kết quả kinh doanh của khách thông qua OKR chung. Trước đó, mảng professional services của Databricks đã thay những SOW cứng nhắc bằng cách làm việc theo OKR, cộng tác liên tục với khách.
Jason Martin, VP phụ trách FDE ở Databricks, nói với một hội thảo của Insight Partners rằng công việc này không thể xoay quanh giờ công và số người, mà phải xoay quanh kết quả.
Phần “how” thuộc về FDE. Theo Databricks, việc của FDE là lấy nền tảng ở dạng thô và dựng nó thành một giải pháp kinh doanh chạy thật trong môi trường của khách. Khi nền tảng chưa làm được điều khách cần, FDE làm việc trực tiếp với R&D để mở rộng nó.
Vậy ai trả lời “why” và “what”? Không phải một mình FDE. Bài tổng hợp hội thảo của Insight Partners mô tả pre-sales và post-sales ở Databricks giờ đã hoà thành một luồng công việc. Tin tuyển Manager FDE của công ty yêu cầu phối hợp với Account Executive, Engagement Manager và lãnh đạo Field Engineering để định vị và triển khai chương trình.
Partner bổ sung độ rộng chuyên môn, nhưng Databricks không nói họ sở hữu “why” hay “what”.
Ví dụ: “chúng tôi cần một chatbot”
Hãy quay lại buổi kickoff, giờ đặt vào bối cảnh giả định là một công ty bán lẻ điện máy ở Việt Nam. Bạn không phản bác ý tưởng agent. Bạn hỏi ngược lên trên.
“Hiện giờ chuyện gì đang làm anh đau đầu nhất ở bộ phận chăm sóc khách hàng?” Giả sử câu trả lời là tổng đài quá tải mỗi mùa khuyến mãi, khách chờ lâu rồi bỏ đơn. Đó là “why”. Câu tiếp theo: “Nếu sáu tháng nữa dự án thành công, anh sẽ nhìn vào con số nào trên dashboard?” Câu trả lời cho câu này sẽ thành “what”.
Sau buổi họp, bạn viết một trang brief như sau và gửi cho cả khách lẫn Account Executive:
| Tầng | Nội dung (giả định) | Ai xác nhận |
|---|---|---|
| Why | Mùa khuyến mãi tổng đài quá tải, khách bỏ đơn vì phải chờ | Phó giám đốc vận hành |
| What (Objective) | Khách được trả lời nhanh, không phải tăng nhân sự tổng đài | Khách + AE/Engagement Manager |
| What (Key Results) | Thời gian chờ trung vị giảm X%; Y% câu hỏi về đơn hàng được tự xử lý; tỉ lệ khách chuyển sang gặp người thật không tăng | Hai bên ký |
| How | Agent đọc hệ thống đơn hàng, chuyển cho người thật khi không chắc chắn, có eval set dựng từ log tổng đài | FDE |
Hãy để ý ba điều. Các con số X, Y được để trống có chủ đích, vì chúng phải do khách điền chứ không phải do bạn. Dòng “How” nhắc đến eval set, vì Key Result chỉ có ý nghĩa khi bạn đo được nó. Thêm nữa, sau khi viết xong “what”, có thể “how” sẽ không còn là chatbot.
Biết đâu cách hiệu quả nhất lại là tự động gửi tin nhắn cập nhật trạng thái đơn hàng.
Tự làm trong năm bước
Bước một: ghi lại nguyên văn yêu cầu của khách và gắn nhãn cho nó. Gần như lúc nào nó cũng là một “how”. Bước hai: hỏi ngược lên “why” bằng các câu về nỗi đau và chi phí của việc giữ nguyên hiện trạng, đừng hỏi về công nghệ.
Bước ba: chuyển “why” thành một Objective cùng 2-3 Key Result có số đo và có mốc thời gian. Bước bốn: xác định ai ký vào từng tầng. Nếu tổ chức của bạn có AE hay Engagement Manager, hãy kéo họ vào ngay lúc này, đừng đợi đến khi có tranh cãi.
Bước năm: chỉ bắt đầu thiết kế “how” khi đã có chữ ký cho “what”. Trong lúc xây, nếu thấy nền tảng thiếu một năng lực cần thiết, hãy ghi lại thành yêu cầu gửi đội sản phẩm. Đừng âm thầm vá cho xong.
Những lỗi hay gặp
Lỗi phổ biến nhất là viết “what” thành output: “triển khai agent”, “hoàn thành migration”. Đó là việc bạn làm, không phải kết quả khách nhận được. Phép thử đơn giản: nếu dự án có thể “xong” mà khách vẫn không khá lên chút nào, thì bạn mới viết output.
Lỗi thứ hai là để “why” nằm trong đầu một người, thường là người bán được hợp đồng. Khi người đó chuyển việc, cả đội không còn biết mình đang tối ưu cho điều gì. Lỗi thứ ba là coi chuyện làm chung với đội sales là việc của người khác.
Như lời CTO mảng Consumer & Community Banking của JPMorgan Chase giải thích, họ không cần thêm consultant mà cần kỹ sư xây được những thứ chưa tồn tại. Nhưng muốn xây đúng thứ đó, kỹ sư vẫn phải hiểu vì sao người ta cần nó.
CV của bạn có nói được tầng “what”?
Với một developer Việt Nam muốn chuyển sang FDE, kỹ năng này thể hiện rõ nhất trong CV và trong buổi phỏng vấn. Khi đọc job description, hãy để ý các cụm như “business outcomes”, “OKR”, “partner with Account Executives”. Đó là tín hiệu công ty chờ bạn nói chuyện được ở cả ba tầng.
Mỗi dự án trong CV nên có một câu “để đạt…” đi sau câu “đã xây…”. Khi phỏng vấn, nếu được hỏi về một dự án cũ, hãy kể theo đúng thứ tự why, what, how thay vì mở đầu bằng stack công nghệ.
Bài tập tuần này: lấy ticket lớn nhất bạn đang làm và thử viết ba dòng why, what, how cho nó. Nếu dòng “what” mất hơn mười phút mà vẫn chưa ra một con số, thì việc bạn nên làm tiếp theo là đi hỏi người đã giao ticket đó, chưa phải lúc viết code.
5 nguồn
- Databricks Launches Forward Deployed Engineering Organization To Accelerate AI Outcomes · 2026-06-14
- Forward Deployed Engineering: Delivering Business Outcomes with AI · 2026-06-11
- Demystifying the forward deployed engineer · 2026-07-14
- Manager, Forward Deployed Engineering - Databricks
- Agile and Flexible Services Deployment with OKR Centric Delivery · 2026-02-03