Khi khách nói “đội mình tự build được”: FDE nên đổi câu hỏi, đừng cãi

Thử hình dung bạn đang ở tuần đầu của một deployment. Trong buổi họp, trưởng nhóm data engineering của khách mở laptop và cho cả phòng xem bản demo anh viết cuối tuần: gọi thẳng LLM API, tóm tắt ticket hỗ trợ khá gọn. Rồi anh hỏi: “Cái này đội mình tự build được, sao phải mua?”

Đây là lúc nhiều FDE trả lời sai. Có người lao vào bảo vệ sản phẩm từng tính năng một, có người lôi số liệu ra để chứng minh khách đang ảo tưởng. Cách nào cũng có thể thắng cuộc tranh luận, nhưng cái giá là mất người quan trọng nhất của dự án.

Trớ trêu là chính cách FDE làm việc dễ gợi ra câu hỏi này. PostHog mô tả FDE là người ngồi trong đội của khách và dựng prototype nhanh, chấp nhận thô.

Khách thấy một thứ chạy được sau vài ngày thì nghĩ “mình cũng làm được” là chuyện tự nhiên. Người đang hỏi bạn lại rất có thể là người sẽ vận hành hệ thống sau khi bạn rời đi.

Vì sao nên mở đầu bằng chữ “đúng”?

Câu “tự build được” hiếm khi chỉ là chuyện kỹ thuật. Trong đó có niềm tự hào nghề nghiệp, nỗi lo bị khóa vào một nhà cung cấp, và đôi khi là áp lực từ cấp trên muốn đội nội bộ làm được nhiều hơn. Phản bác thẳng chỉ chạm vào lớp ngoài cùng.

Vì thế câu trả lời tốt nhất thường bắt đầu bằng một lời công nhận thật lòng: đúng, đội anh build được bản này.

Theo nhận xét của nhóm chuyên gia trong một bài viết của Gong, quyết định nên build hay nên mua thường sai ở đúng một chỗ: người ta tưởng prototype dựng nhanh đã là một năng lực hoàn chỉnh.

Bạn công nhận cái prototype, nhưng không công nhận rằng prototype là đích đến.

Bước tiếp theo là đổi câu hỏi. Theo Gong, câu nên hỏi thay cho “mình có build được không?” là lợi thế khác biệt thực sự nằm ở đâu. Câu thứ hai: khi cơn hào hứng với prototype qua đi, đội có còn muốn sở hữu lớp đó không.

Các nhà nghiên cứu của MIT Sloan đưa ra một quy tắc cùng hướng: khi cần đi nhanh thì mua sẵn, hoặc mua rồi phát triển thêm trên đó; chỉ tự build ở chỗ tạo ra lợi thế cạnh tranh khác biệt.

Chi phí thật nằm ở năm thứ hai

Một bản demo cuối tuần chưa tốn chi phí vận hành, vì chưa ai vận hành nó. MIT Sloan định nghĩa “build” là tổ chức tự phát triển, tự chạy và tự bảo trì model của mình. Bản demo mới làm xong vế đầu. Hai vế sau mới là phần tốn công.

Hãy biến hai vế đó thành câu hỏi cụ thể cho trường hợp tóm tắt ticket. Về vận hành: ticket chứa thông tin cá nhân của khách hàng, vậy ai quyết định dữ liệu nào được gửi ra ngoài, và ai trực khi hệ thống lỗi lúc hai giờ sáng?

Về bảo trì: khi nhà cung cấp model đổi phiên bản và chất lượng tóm tắt tụt, ai phát hiện, ai sửa prompt, ai chạy lại bộ eval?

Bạn không cần trả lời thay khách. Mục tiêu là để trưởng nhóm kia tự thấy danh sách công việc nằm sau bản demo của mình, rồi tự quyết đội anh muốn ôm phần nào. Gong kết luận rằng điều quyết định là đội có thành thật với chính mình về chuyện sở hữu hay không.

Một kịch bản hội thoại để dùng ngay

Dưới đây là một kịch bản mẫu, bạn chỉnh lại cho hợp giọng mình.

Khách: Cái này đội mình tự build được, sao phải mua?

FDE: Đúng, bản demo của anh chạy tốt, và đội anh hoàn toàn đủ sức làm.

Em muốn hỏi khác một chút: sau sáu tháng, anh muốn đội mình sở hữu những phần nào?

Khách: Ý em là sao?

FDE: Ví dụ khi đổi model thì ai chạy lại eval, ai duyệt dữ liệu nào được gửi ra ngoài, ai trực khi có sự cố.

Phần nào là lợi thế riêng của công ty thì đội anh nên giữ. Phần nào chỉ là hạ tầng chung thì mình dựng trên nền tảng, đội anh khỏi phải gánh.

Khách: Phần riêng của bọn anh là cách phân loại ticket và đẩy cho đúng người.

FDE: Vậy đội anh build đúng phần đó, em làm cùng.

Mình chốt luôn ai bên anh sẽ chịu trách nhiệm sau khi em rời dự án nhé.

Kịch bản có ba nhịp: công nhận, chuyển sang câu hỏi sở hữu, rồi trao lại cho khách một phần việc thật. Câu cuối không phải phép lịch sự. Đó là kế hoạch bàn giao, được đặt sẵn từ tuần đầu.

Vẽ bản đồ ai build gì

Sau buổi nói chuyện, hãy biến thỏa thuận thành một bảng mà cả hai bên cùng nhìn, như bảng so sánh ở đầu bài. Mỗi thành phần ghi rõ ai build, ai vận hành sau bàn giao và rủi ro nếu nó hỏng. Cột rủi ro quan trọng nhất, vì nó chỉ ra phần nào bắt buộc phải có một người sở hữu có tên rõ ràng.

Nguyên tắc chia bám theo quy tắc của MIT Sloan. Cách phân loại và chuyển ticket là lợi thế khác biệt của khách, nên đội khách build và giữ. Kết nối dữ liệu, eval và kiểm soát truy cập là hạ tầng chung, nên dựng trên nền tảng để đi nhanh.

Một việc rủi ro thấp như báo cáo nội bộ hằng tuần là chỗ an toàn để đội khách tự làm và tự học. Hỏng thì chậm vài ngày, không ai thiệt hại thật.

Đừng mong bảng của khách này giống khách kia. Rocketlane nhận xét rằng với FDE không có mô hình nào dùng chung cho mọi nơi, và bản đồ sở hữu cũng vậy. a16z thì lưu ý rằng khách không muốn thấy mình mắc kẹt trong một dự án tư vấn kéo dài. Một bảng có sẵn tên người vận hành cho họ thấy trước ngày bạn rút đi.

Những lỗi hay gặp

Lỗi phổ biến nhất là dùng số liệu như vũ khí. Theo báo cáo của MIT được Fortune đưa tin, 95% dự án thử nghiệm AI tạo sinh trong doanh nghiệp thất bại. Mua công cụ từ nhà cung cấp chuyên biệt và hợp tác thành công khoảng 67% số lần, còn các dự án tự build có tỷ lệ thành công chỉ bằng một phần ba so với mua.

Menlo Ventures cũng ghi nhận 76% use case AI hiện được mua thay vì tự build, vì giải pháp làm sẵn lên production nhanh hơn và cho thấy giá trị sớm hơn. Những con số này đáng biết.

Nhưng đem chúng ra đè một kỹ sư vừa khoe demo chỉ khiến anh phòng thủ hơn, nên hãy giữ chúng để tự nhắc mình vì sao câu hỏi sở hữu đáng được hỏi.

Lỗi ngược lại cũng hay gặp: để giữ lòng khách, FDE hứa viết riêng mọi thứ. Kết quả là một hệ thống không ai bảo trì nổi và một dự án không có hồi kết, đúng điều a16z nói khách không muốn. Rồi còn chuyện thỏa thuận xong mà không chốt tên người sở hữu, nên khi bạn rời đi, mọi thứ trôi dần.

Có một lỗi ít ai để ý: chỉ coi câu “tự build” là phản đối cần gỡ. Nếu nhiều khách cùng muốn tự build một lớp, đó là tín hiệu nên mang về cho đội product.

Biến kỹ năng này thành lợi thế khi đi xin việc

Trong CV, đừng viết “giao tiếp tốt”. Hãy kể cụ thể bạn đã biến một lần phản đối “tự build” thành bản đồ sở hữu chung: đội khách giữ phần nào, phần nào dựng trên nền tảng, và ai vận hành sau bàn giao.

Khi phỏng vấn, chuẩn bị sẵn câu chuyện đó theo dạng tình huống, hành động, kết quả. Một câu chuyện có tên người sở hữu và một bảng phân việc rõ ràng thuyết phục hơn mọi tính từ tự nhận.

Lần tới khi có người mở laptop và nói “đội mình làm được”, bạn không cần thắng cuộc tranh luận đó. Thứ bạn cần mang về là một đồng minh, người sẽ còn vận hành hệ thống rất lâu sau khi bạn rời dự án.