Sự trỗi dậy của Kỹ sư triển khai tiền phương (FDE) và bí quyết để thành công

FDE (Forward Deployed Engineer) đang là công việc "hot" nhất trong lĩnh vực AI. Các phòng thí nghiệm, startup và công ty cổ phần tư nhân (PE firms) đều đang tuyển dụng các kỹ sư để làm việc trực tiếp trong quy trình vận hành của khách hàng nhằm giải quyết các vấn đề của họ. Tuy nhiên, hầu như không ai trong số họ thống nhất được những kỹ sư này cần đạt được mục tiêu gì, hay chiến lược thực sự đằng sau việc tuyển dụng này là gì.

Tôi là Vinoo, CEO của Kepler, đơn vị cung cấp hạ tầng tất định (deterministic infrastructure) cho AI. Tôi đã từng ba lần xây dựng các bộ phận kỹ sư triển khai thực địa (forward deployed function) tại ba tổ chức khác nhau trong suốt hơn một thập kỷ qua. Dưới đây là những gì tôi thấy hiệu quả, những gì tôi thấy thất bại và hướng đi mà tôi tin rằng lĩnh vực này sẽ phát triển.

Nơi đầu tiên là Palantir. Tôi bắt đầu ở đó với vai trò phát triển sản phẩm, xây dựng các hệ thống lưu trữ và truy xuất, sau đó được triển khai làm FDE trong các lĩnh vực thương mại, Bộ Quốc phòng (DoD), An ninh Quốc gia (NatSec), y tế, dầu khí. Tôi cũng từng dẫn dắt Dự án Frontline, chương trình luân chuyển đưa các kỹ sư phần mềm của chúng tôi trở thành các kỹ sư triển khai thực địa. Khoảng 250 người đã tham gia chương trình này, và hiện nay rất nhiều người trong số họ đang điều hành các đội ngũ FDE tại các công ty như OpenAI, Anthropic, xAI và Anduril.

Nơi thứ hai là Citadel, nơi tôi điều hành mảng kỹ thuật kinh doanh (business engineering). Khách hàng của chúng tôi là các nhà quản lý danh mục đầu tư, và câu hỏi duy nhất quan trọng là liệu các sản phẩm dữ liệu và phần mềm chúng tôi xây dựng có giúp họ tạo ra lợi nhuận vượt trội (alpha) hay không.

Nơi thứ ba là Kepler, nơi bộ phận triển khai thực địa nằm trong nhóm sản phẩm thay vì nhóm kinh doanh, trong một lĩnh vực mà một câu trả lời sai nhưng nghe có vẻ hợp lý còn tệ hơn là không có câu trả lời nào cả.

Vài tháng trước, a16z đã ra mắt chương trình Forward Deployed Engineer Fellowship và tôi được đề cử là một trong những thành viên, cùng với một vài người tôi từng làm việc chung. Đây là một chương trình tuyệt vời và tôi đã rất thích thú với nhiều cuộc trò chuyện tại đó. Tuần trước, tôi đã tham dự bữa tối đầu tiên dành cho các thành viên tại SF.

Ngồi quanh bàn là các FDE từ Snowflake, Anthropic và một số startup mà tôi từng đọc qua. Trong suốt buổi tối, rõ ràng là tất cả chúng tôi đều đang dùng chung hai từ (forward deployed) để mô tả những công việc gần như chẳng có điểm gì chung. Trong một phần của cuộc trò chuyện, FDE là kỹ sư kinh doanh tham gia vào "cuộc gọi thứ hai"; ở nơi khác, đó lại là một nhân viên kinh doanh có chỉ tiêu (quota) nhưng biết viết Python; và vài ghế bên cạnh, đó lại giống một nhà tư vấn với chiếc laptop và một bản tuyên bố công việc (statement of work), được đưa vào để cung cấp thứ mà sản phẩm hiện tại không làm được.

Vài ngày sau, có người đã nghiêm túc hỏi trong nhóm WhatsApp của chúng tôi rằng đội ngũ FDE của họ nên phân chia phạm vi công việc như thế nào với công ty tư vấn đang làm việc tại tài khoản đó. Đó là một câu hỏi hợp lý, nhưng lại là một câu hỏi kỳ lạ khi phải trả lời, ít nhất là dựa trên niềm tin của tôi về việc thế nào là một FDE.

Để rõ ràng, tôi không có ý định độc quyền thuật ngữ này; ý nghĩa của các từ ngữ luôn thay đổi, và từ này thay đổi nhanh hơn hầu hết các từ khác. Nhưng điều thú vị là những người trong nhóm này, những chuyên gia hiện tại về FDE, đang mô tả những công việc hoàn toàn khác nhau, với các tuyến báo cáo và động lực khác nhau. Chẳng trách một nửa số bình luận trên bất kỳ video YouTube nào về FDE đều là những câu kiểu như: "Đây chẳng phải là đang phát minh lại nghề tư vấn sao?"

Vì vậy, trong phần còn lại của bài viết này, tôi sẽ kể cho bạn câu chuyện về Dự án Frontline, thông qua lăng kính hẹp của một sai lầm mà tôi đã góp phần tạo ra, cách sai lầm đó biến tôi thành một FDE, và cách nó cuối cùng đã định hình chương trình luân chuyển giúp biến các kỹ sư phần mềm của chúng tôi thành các FDE.

Trước hết, cần một chút bối cảnh. Ngay từ gần như lúc bắt đầu, Palantir đã được chia thành hai bộ phận riêng biệt. Thứ nhất là Phát triển Sản phẩm (PD), bộ phận xây dựng nền tảng. Thứ hai là Phát triển Kinh doanh (BD), mặc dù tên gọi như vậy nhưng nó bao gồm cả những người làm BD kỹ thuật (đã được gọi là FDE) và những người làm việc với khách hàng không thuộc khối kỹ thuật (chúng tôi gọi họ là Embedded Analysts hoặc Deployment Strategists).

Trong phần lớn các tình huống, PD không trực tiếp làm việc với khách hàng; và BD, trong phần lớn các tình huống, không trực tiếp đóng góp vào việc xây dựng nền tảng cốt lõi, tổng quát. PD thường tìm hiểu nhu cầu khách hàng một cách gián tiếp, bằng cách trò chuyện với BD hoặc bằng cách đưa các tính năng đã xây dựng thành công tại thực địa vào sản phẩm cốt lõi. Tuy nhiên, không có quy trình nào cho việc đó cả. Nó vận hành dựa trên các mối quan hệ — ví dụ như FDE nào tình cờ quen biết kỹ sư PD nào đủ thân để nhờ vả. Vì vậy, một thông tin chi tiết tốt từ thực địa có được đưa vào nền tảng hay không (hoặc bị bỏ qua) phụ thuộc vào việc ai là người có mặt trong phòng.

Năm 2013, trong những ngày đầu tại Palantir, tôi có cơ hội làm việc trên một kho lưu trữ giao dịch tên là Phoenix. Kho lưu trữ này được thiết kế bởi một số kỹ sư giỏi nhất mà tôi từng làm việc cùng, và nó có một thiết kế cực kỳ sạch sẽ, được xác định phạm vi cho một tập hợp các trường hợp sử dụng của khách hàng rõ ràng. Tuy nhiên, các trường hợp sử dụng đó đã được truyền đạt lại cho chúng tôi một cách gián tiếp. Chúng tôi biết và hiểu các yêu cầu thiết kế, vốn tập trung vào các yêu cầu thương mại về thời hạn lưu giữ, và có những giải pháp thông minh để phân loại dữ liệu theo cách cho phép lưu trữ một cửa sổ dữ liệu luân phiên. Nó hoạt động chính xác như đã chỉ định trong mọi môi trường mà chúng tôi kiểm soát.

Sau đó, chúng tôi triển khai nó tại một ngân hàng, và dữ liệu tài chính thực tế hóa ra lại có những lỗ hổng mà dữ liệu thử nghiệm của chúng tôi chưa bao giờ gặp phải. Một dấu thời gian (timestamp) trống đã bị đẩy về mốc thời gian gốc (epoch), vì vậy logic lưu giữ đã thực hiện yêu cầu một bucket mười phút cho mỗi cửa sổ giữa ngày 1 tháng 1 năm 1970 và hiện tại. Điều đó dẫn đến khoảng 2,3 triệu keyspace đối với một hệ thống mà Cassandra (công nghệ hỗ trợ) cần khoảng 5 megabyte cho mỗi file handle. Máy chủ đã bị OOM (Out-Of-Memory - hết bộ nhớ) một cách hợp lý và việc khởi động lại nó sẽ cần tới 14 terabyte RAM. Điều này có nghĩa là quy trình này thực sự đã chết ngay từ khi bắt đầu.

Nguyên nhân gốc rễ ở đây không phải là thiếu nghiên cứu người dùng như bạn có thể đoán. Chúng tôi có thông số kỹ thuật, chúng tôi hiểu trường hợp sử dụng của mình và chúng tôi đã đọc rất nhiều về cách các tổ chức như thế này lưu trữ dữ liệu của họ. Điều chúng tôi chưa bao giờ làm là đứng ngay tại tòa nhà đó trong khi hệ thống chạy với dữ liệu thực tế của họ. Điều này có nghĩa là không ai phía chúng tôi chịu trách nhiệm cho khoảng cách giữa thiết kế và thực tế hàng ngày. Mọi thứ chúng tôi biết về ngân hàng đó đều được truyền đạt gián tiếp bởi những người có thiện chí, những người mà dữ liệu xấu chỉ là một điều bình thường.

Đó là cách tôi trở thành một FDE, một cách mô tả hào phóng cho những gì thực sự đã xảy ra. Khi Phoenix được triển khai trên khắp đội ngũ thương mại của Palantir, tôi thấy mình phải bay đi để sửa chữa những gì chúng tôi đã cung cấp, và điều đó lần đầu tiên đưa tôi đến trước những người dùng thực sự của mình. Trong trường hợp này, người dùng chính là các FDE của Palantir, điều đó thật may mắn cho tôi, vì họ có thể nói cho tôi biết điều gì sai bằng ngôn ngữ mà tôi đã biết. Tôi bắt đầu xây dựng và mở rộng các hệ thống để phục vụ những gì họ đang cố gắng thực hiện.

Vì vậy, đây cũng là câu chuyện về cách tôi học tư duy FDE một cách bản năng thay vì lý thuyết.

Đây là nơi phiên bản thông thường của câu chuyện này kết thúc, với một bài học về việc chú ý đến người dùng của bạn. Phoenix đã trở thành một thứ thú vị hơn thế. Nó trở thành một nền tảng, và các FDE của Palantir bắt đầu xây dựng trên nền tảng đó trong các lĩnh vực an ninh mạng, KYC, AML và một danh sách dài các trường hợp sử dụng mà chưa ai từng xác định phạm vi. Cuối cùng, chúng tôi (Phát triển Sản phẩm) phải suy nghĩ về cách mở rộng nền tảng Phoenix để hỗ trợ tất cả các trường hợp sử dụng này.

Lúc đó tôi không nhận ra, nhưng chu kỳ lặp lại đó chính là toàn bộ ý tưởng. Một FDE giải quyết các vấn đề của khách hàng để thu thập thông tin chi tiết, từ đó định hình những gì cần được xây dựng tiếp theo. Vai trò này là một phần mở rộng của nhóm sản phẩm.

Thực tế là không ai trong số này có tư duy của đại đa số các FDE mà bạn thấy ngày nay. Thuật ngữ này đã bị chiếm dụng để có nghĩa gần giống như "một người làm điều gì đó liên quan mơ hồ đến khách hàng", đó là lý do tại sao bạn thấy các bài đăng tuyển dụng cho một nhà nghiên cứu cổ phiếu triển khai thực địa, hoặc một kỹ sư kinh doanh triển khai thực địa. Bản năng đằng sau việc chiếm dụng này là đúng, ngay cả khi các chức danh nghe có vẻ ngớ ngẩn, bởi vì khách hàng hiện nay quan trọng hơn so với năm năm trước, và họ quan trọng vì một lý do cụ thể.

Những quả thấp đã được hái hết. Những vấn đề có thể được giải quyết bằng một sản phẩm được thiết kế tốt bán giống hệt nhau cho một nghìn công ty phần lớn đã được giải quyết. Những gì còn lại là công việc nằm bên trong các bức tường, trong các quy trình làm việc lộn xộn, không được ghi chép lại và gần như không thể suy luận từ bên ngoài. Đó là lý do tại sao mọi người đột nhiên trở thành "triển khai thực địa". Bạn không thể suy luận từ một cuộc gọi tìm hiểu nhu cầu xem một công ty cụ thể chốt sổ sách như thế nào, và phần vấn đề chống lại sự suy luận đó chính là phần còn lại.

Điều đó có nghĩa là "chén thánh" đã lặng lẽ di chuyển. Trong một thời gian dài, đó là chuyển động có thể lặp lại, cùng một sản phẩm SaaS được bán theo cùng một cách lặp đi lặp lại; và đó vẫn là tham vọng đúng đắn nếu những gì bạn bán là token, byte hoặc thứ gì đó vật lý. Đối với tất cả những người khác, giá trị đã chuyển sang tùy chỉnh, sang chặng cuối (last mile), sang 20% quy trình làm việc mà không sản phẩm nào có thể dự đoán trước và quyết định liệu 80% còn lại có được sử dụng hay không. Trở thành người triển khai thực địa đã trở thành đồng nghĩa với việc giải quyết chặng cuối đó.

Nhưng giải quyết nó chỉ là một nửa mục đích của vai trò này. Vấn đề chặng cuối mà bạn giải quyết tại một khách hàng chính là tín hiệu cho bạn biết phần nào trong nền tảng của bạn cần trở nên tổng quát hóa. Một bộ phận FDE giải quyết các chặng cuối mà không bao giờ gửi tín hiệu đó về nhà là một nhóm dịch vụ/tư vấn với một chức danh nghe kêu hơn.

Tôi cho rằng công việc của bạn với tư cách là một FDE là thu thập các danh từ và động từ. Hãy cùng phân tích điều đó.

Dành một tuần bên trong một công ty và bạn sẽ nhận thấy rằng cùng một khái niệm thường có ít nhất bốn tên gọi khác nhau. Bộ phận kinh doanh gọi là khách hàng, bộ phận vận hành gọi là client, bộ phận tài chính ghi sổ là thực thể thanh toán, bộ phận kỹ thuật viết là org_id, và mọi đường nối giữa các nhóm đó đều ẩn chứa một sự dịch thuật bị phá vỡ ngay khi ai đó thay đổi định nghĩa. Những cái tên đó là bề mặt và bên dưới chúng là mô hình vận hành. Nghĩa là, bạn thực sự có thể suy luận cách một công ty hoạt động bằng cách học các danh từ và động từ của họ.

Danh từ là những gì mọi người trong doanh nghiệp coi là thực tế. Nó thường là một "thứ gì đó". Một vị thế, hoặc một giao dịch, hoặc một đối tác. Thông thường, trên cơ sở từng nhóm, có một vài đối tượng mà toàn bộ hoạt động xoay quanh, và không ai trong số chúng được định nghĩa theo cách sách giáo khoa định nghĩa. Đó là vì hai công ty sẽ mô tả một vị thế giống hệt nhau trên slide và hoàn toàn khác nhau trong mã nguồn. Đó không phải là lỗi, đó chỉ là điều làm cho các công ty trở nên độc đáo. Ý tôi là nếu mọi công ty đều có cùng một tập hợp danh từ, thì bạn thực sự chỉ cần một công ty mà thôi.

Động từ là cách các danh từ di chuyển. Những thứ như cách một giao dịch được ghi sổ, hoặc điều gì phải đúng trước khi sổ sách có thể đóng, hoặc ai là người ký duyệt một ngoại lệ vào lúc 11 giờ đêm và điều gì xảy ra khi người đó đi nghỉ.

Hầu như không có điều nào trong số này được viết ra — nó được sống. Đó là hệ thống vận hành mà qua đó một tổ chức tồn tại. Đó là văn hóa. Nó sống trong đầu của sáu người đã ở đó đủ lâu để không còn nhận ra nó nữa, và trong một bảng tính mà ai đó đã xây dựng từ bốn năm trước mà cả nhóm hiện đang lặng lẽ phụ thuộc vào. Đó là lý do tại sao nó đáng giá đến vậy, và đó cũng là lý do tại sao bạn không thể hỏi để có được nó.

Thông thường, những người nắm giữ kiến thức này không biết họ đang sở hữu nó. Tại một trong những startup cuối cùng của tôi, chúng tôi đã dành gần một năm để cố gắng chuyển khách hàng từ CSV sang Parquet, và một kỹ sư chất lượng dữ liệu đã chặn nó mỗi lần. Chúng tôi không bao giờ hiểu tại sao và lý do luôn thay đổi, nhưng luôn là một biến thể của "parquet tệ hơn", "nó không hoạt động", "nó không có ý nghĩa với tôi", v.v. Chúng tôi đã sử dụng lập luận giảm lưu trữ của khách hàng, lập luận tối thiểu hóa tính toán, lập luận tối ưu hóa đường ống... và không có gì lay chuyển được cô ấy, bởi vì không có gì trong số đó liên quan đến vấn đề thực tế.

Sau đó, chúng tôi đã cử một trong những FDE của mình vào và quan sát kỹ sư chất lượng dữ liệu này làm việc. Cô ấy tải các tệp CSV từ S3 xuống máy tính xách tay Windows, nhấp đúp để mở chúng và kiểm tra các hàng bằng mắt thường. Đó là quy trình kiểm tra chất lượng dữ liệu. Parquet không có trình xem gốc vào thời điểm đó, vì vậy những gì chúng tôi đề xuất sẽ lấy đi công cụ kiểm tra chất lượng dữ liệu duy nhất mà cô ấy có và không đưa lại cho cô ấy bất cứ thứ gì. Cô ấy không phải là người khó tính, cô ấy chỉ đang bảo vệ thứ duy nhất cho phép cô ấy làm công việc của mình.

Chúng tôi đã xây dựng một trình xem Parquet vào đêm đó, cô ấy đã phê duyệt việc di chuyển hai ngày sau đó, và thời gian thực thi đường ống đã giảm từ khoảng mười bảy giờ xuống còn hai giờ. Cô ấy sẽ không bao giờ nói bất kỳ điều nào trong số này trong một cuộc phỏng vấn. Từ vị trí của cô ấy, lý do là hiển nhiên và không đáng để đề cập.

Việc hiểu và xác định hệ thống vận hành, hay các danh từ và động từ của nhà phân tích này đã cho phép chúng tôi không chỉ hiểu vấn đề mà còn xây dựng một giải pháp mà sau đó chúng tôi có thể cung cấp cho hàng loạt khách hàng gặp vấn đề tương tự.

Hiểu các danh từ và động từ giúp bối cảnh hóa các vấn đề, nhưng đầu ra cần phải là một sản phẩm thay vì chỉ là một khách hàng hài lòng.

Các danh từ và động từ cho bạn biết vấn đề thực sự là gì. Chúng không cho bạn biết phải làm gì với nó; và đây là nơi hầu hết các bộ phận FDE lặng lẽ đi sai hướng, bởi vì giải quyết vấn đề trước mắt rất thỏa mãn và dễ hiểu, và ai đó sẽ cảm ơn bạn vì điều đó ngay trong tuần đó.

Giữ cho khách hàng hài lòng là một công việc thực sự và là một công việc tốt. Nó thuộc về các kiến trúc sư giải pháp (solutions architects), những người được đánh giá đúng đắn về điều đó. Kỹ sư triển khai thực địa ở đó để biến những gì thực địa dạy cho bạn thành thứ mà mọi khách hàng tương lai đều nhận được. Một sự tham gia của FDE kết thúc với một tài khoản vui vẻ và không có gì thay đổi ở thượng nguồn đã thất bại ở mục đích duy nhất mà vai trò này tồn tại. Bạn đã có bối cảnh và bạn đã tiêu tốn nó tại chỗ.

Tôi đã học được điều đó một cách đắt giá. Trong một trường hợp, một khách hàng cần một công việc lưu giữ dữ liệu, vì vậy tôi đã chắp vá một tập lệnh groovy có tên là "vinoo.groovy" để giúp họ tạm thời — một buổi chiều làm việc không bao giờ có ý định tồn tại qua tuần đó. Một năm sau, nó đang chạy trên một khách hàng với gần một trăm nghìn người, với tên của tôi gắn liền với nó. Nó trở thành một câu chuyện nực cười đến mức nhóm của tôi bắt đầu gọi tôi là vinoo.groovy. Chúng tôi đã khắc phục được vấn đề, nhưng không bao giờ biến bản sửa lỗi đó thành một sản phẩm — vì vậy chúng tôi đã dành nhiều năm để duy trì một bản hack lẽ ra phải chết ngay lập tức. Mọi lối tắt bạn cung cấp đều trở thành thứ bạn sở hữu. Kỷ luật là biết bản sửa lỗi nào thuộc về nền tảng và bản sửa lỗi nào bạn cố tình vứt bỏ ngay khi chúng đã hoàn thành công việc của mình.