Khi CTO của khách bác kiến trúc AI, đừng giải thích lại lần nữa

Thử hình dung: bạn đang ở slide thứ tư, sơ đồ kiến trúc trợ lý AI vừa hiện lên, và CTO của khách ngắt lời. “Sao lại thêm một vector database nữa? Đội tôi không ai vận hành nó cả.” Phản xạ của phần lớn kỹ sư là giải thích lại, kỹ hơn, nhiều số liệu hơn.

Chính lúc đó phiên cố vấn bắt đầu hỏng. Người ngồi đối diện không cần bạn thuyết phục giỏi hơn. Họ đang đưa cho bạn một ràng buộc mà sơ đồ của bạn chưa tính tới.

Với FDE, buổi này quan trọng hơn vẻ ngoài của nó. Bài viết của First Round Review về tuyển FDE coi việc sống cùng khách tại chỗ là phần cốt lõi của vai trò này. Bạn ở đó chính là để nghe được những ràng buộc như thế, chứ không phải để bảo vệ slide.

Phản biện là dữ liệu, đừng coi nó là đòn tấn công

Hướng dẫn engineering của Google về xử lý pushback trong code review có một lời khuyên đáng dán lên màn hình: nếu người kia đúng, hãy nói với họ là họ đúng và bỏ qua điểm đó. Nghe đơn giản, nhưng nó đòi bạn dừng lại tự hỏi trước khi phản bác.

Thay “code” bằng “hệ thống của khách”, lời khuyên ấy càng đúng với CTO. Họ biết đội nào trực đêm, hệ thống nào từng sập, quy định nào khiến dữ liệu không được rời khỏi hạ tầng của họ. Bạn mới ở đó vài tuần.

Cũng hướng dẫn đó cảnh báo rằng để mọi người “dọn dẹp sau” là con đường quen thuộc khiến codebase xuống cấp. Ở chỗ khách cũng vậy: một điểm đã nhận là đúng thì sửa ngay trong bản thiết kế, đừng đẩy vào danh sách “làm sau” không ai mở lại.

Đừng để CTO là người đầu tiên đọc bản thiết kế

Trước khi vào phòng, bản thiết kế cần được một người khác đọc trước. Một bài hướng dẫn trên Refactoring English về cách lấy phản hồi cho design doc lập luận rằng sửa một lỗi với một người review sẽ tốt hơn để 10 người cùng vấp phải nó.

Ở chỗ khách, người đọc trước lý tưởng là một kỹ sư phía họ, người bạn đã làm việc cùng vài tuần. Họ có thể chỉ ra những chuyện bạn không tự biết được, chẳng hạn đội nền tảng vừa từ chối một dịch vụ mới. Mỗi lỗi họ bắt được là một câu CTO không phải hỏi.

Một phiên cố vấn, xử lý từng lời phản biện

Giả sử bạn đề xuất một trợ lý giúp nhân viên bồi thường của một công ty bảo hiểm tra cứu hồ sơ. Kiến trúc gồm: kho tài liệu, bước tạo embedding, một vector database, một LLM qua API bên ngoài, và bộ eval chấm câu trả lời. Ba lời phản biện sau đây khá điển hình.

Phản biện một: “Tài liệu bồi thường có dữ liệu cá nhân, không được gửi ra API bên ngoài.” Đây là điểm không cần tranh cãi. Câu trả lời đúng: “Anh nói đúng, tôi chưa tính ràng buộc đó. Tôi sẽ sửa sơ đồ để model chạy trong hạ tầng của bên mình và gửi lại bản mới trước thứ Sáu.”

Phản biện hai: “Thêm vector database là thêm một hệ thống phải trực.” Đừng vội bảo vệ, cũng đừng vội bỏ. Product Talk, khi viết về cách tìm tiếng nói chung với kỹ sư không thích một tính năng, mô tả trường hợp kỹ sư vướng một vấn đề triển khai nhưng lại nói ra như thể phản đối chính tính năng.

Vì thế, hãy đặt một câu hỏi trúng đích: “Đội anh hiện vận hành những kho dữ liệu nào? Nếu dùng lại một trong số đó thì đổi lại mình mất gì?” Theo Product Talk, nhiều khi chỉ cần hỏi là người phản đối tự nhận ra đâu là mối lo thật của mình.

Ở đây, lời phản đối biến thành một tiêu chí thiết kế: chi phí vận hành cho đội của họ.

Phản biện ba: “Sao không fine-tune model trên dữ liệu của chúng tôi cho xong?” Đây là điểm còn tranh cãi thật. Product Talk khuyên khi hai bên bất đồng về hướng đi, đừng cãi về chính hướng đi cho tới khi cả hai cùng bực, mà chuyển sang lý lẽ nằm bên dưới.

Câu nên nói: “Đây là một quyết định lớn. Tôi sẽ ghi thành open issue, viết rõ lý lẽ của cả hai hướng, rồi mình chốt khi đội anh cùng review.” Phép thử cho open issue rất đơn giản: người muốn fine-tune đọc đoạn bạn viết về quan điểm của họ thì vẫn gật đầu.

Đằng sau mỗi câu phản đối là một nỗi lo khác

Câu bạn nghe	Điều thường nằm phía sau	Nên trả lời thế nào
“Không được gửi dữ liệu ra ngoài”	Ràng buộc pháp lý hoặc bảo mật bạn chưa biết	Nhận ngay, sửa thiết kế, hẹn ngày gửi bản mới
“Đội tôi không vận hành nổi”	Chi phí vận hành, người trực đêm	Hỏi về hạ tầng hiện có, đưa vận hành thành tiêu chí
“Sao không làm cách X?”	Một hướng họ đã cân nhắc hoặc rất tin	Ghi open issue, trình bày công bằng cả hai hướng
“Hay đấy, làm luôn đi”	Hứng thú, chưa chắc đã sẵn sàng	Kiểm tra dữ liệu, người và quy trình trước khi hứa

Dòng cuối dễ bị bỏ qua nhất, vì nó không giống một lời phản đối. Nhưng một CTO gật đầu nhiệt tình chưa chắc có dữ liệu sạch hay đội ngũ để vận hành thứ bạn vừa vẽ.

Khi giải thích lần thứ ba vẫn không ăn thua

Ví dụ rõ nhất về giới hạn của lý lẽ không đến từ một CTO. Vinoo Ganesh kể rằng ở Kepler, người phản đối là một kỹ sư data quality: chị chặn việc chuyển dữ liệu từ CSV sang Parquet suốt khoảng một năm. Giải thích đi giải thích lại về lợi ích kỹ thuật vẫn không gỡ được sự phản đối của chị.

Ràng buộc thật nằm ở cách chị làm việc. Chị kiểm tra dữ liệu bằng cách mở thẳng file CSV ra xem, còn với Parquet, chị không có trình đọc nào mở được tương tự. Thứ gỡ nút thắt là một viewer giữ lại khả năng xem dữ liệu của chị, và chỉ vài ngày sau, việc chuyển đổi đã chạy được.

Một năm tranh luận không bằng vài ngày sửa đúng chỗ. Chức danh khác nhau, nhưng cơ chế thì đáng mang vào phòng họp với CTO: lời phản đối lặp đi lặp lại thường đang bảo vệ một thói quen hay một rủi ro mà slide của bạn không chạm tới.

Bài trên LeadDev về xây đồng thuận với người phản đối khuyên tìm ra nỗi lo sâu hơn và xử lý ở đúng tầng đó, thay vì sa vào tranh cãi bất tận. Câu hỏi đáng đặt là “Điều gì sẽ khiến anh yên tâm?”, chứ đừng tìm cách nói hay hơn.

Những lỗi khiến phiên cố vấn đổ vỡ

Lỗi phổ biến nhất là coi buổi trình bày như buổi bán hàng, cố đi hết slide trong khi CTO đã nêu một ràng buộc làm sập nửa kiến trúc.

Lỗi thứ hai là chốt mọi tranh cãi ngay tại bàn, khiến những người vắng mặt thấy mình bị gạt ra rồi phản đối về sau. Lỗi thứ ba là hứa thay đổi mà không hẹn ngày gửi bản mới, nên lời “anh nói đúng” nghe như phép lịch sự.

Về sự nghiệp, kỹ năng này dễ chứng minh hơn bạn nghĩ. Nếu tin tuyển dụng FDE nhắc đến việc làm cố vấn kỹ thuật cho lãnh đạo phía khách, đó là tín hiệu nên chuẩn bị sẵn một câu chuyện về lần khách phản đối thiết kế của bạn.

Câu chuyện ấy nên có ba phần: bạn đề xuất gì, họ chỉ ra điều gì bạn đã bỏ sót, và thiết kế cuối cùng tốt hơn ra sao.

Bài tập cho buổi gặp CTO tiếp theo

Trước buổi họp, chép bảng bốn dòng ở trên ra một tờ giấy. Với mỗi dòng, viết câu phản biện bạn đoán CTO sẽ nói về chính kiến trúc của bạn, cùng cách bạn định trả lời: nhận và hẹn ngày, hỏi tiếp, hay ghi open issue.

Sau buổi họp, đánh dấu những câu bạn đoán trúng và những câu làm bạn bất ngờ. Lần tới, hãy mang chính những câu bất ngờ đó đi hỏi người đọc trước.

Người được CTO mời quay lại không phải là người thắng mọi tranh luận, mà là người rời phòng với bản thiết kế khác đi vì đã nghe.