Nói “không” với một thiết kế sai mà khách vẫn ngồi lại bàn tiếp

Thử hình dung tuần thứ ba của một pilot. Trưởng phòng vận hành bên khách kéo bạn vào phòng họp: “Cho agent ghi thẳng vào ERP luôn, bỏ bước duyệt đi, tuần sau anh demo cho giám đốc.” Bạn biết đó là sai hướng, và bạn cũng biết người ngồi đối diện chính là người quyết định có gia hạn dự án hay không.

Phản xạ đầu tiên của nhiều kỹ sư là gật đầu cho êm chuyện. Phản xạ thứ hai là cãi cho bằng được về mặt kỹ thuật. Cả hai đều hỏng việc, chỉ theo hai cách khác nhau.

FDE Academy coi việc biết phản đối một cách lịch sự, hoặc mặc cả để mỗi bên nhường một phần, là kỹ năng nhỏ nhưng tạo ra khác biệt lớn cho một FDE.

Lý do khá thực tế: theo họ, thói quen nói “có” với mọi yêu cầu dẫn thẳng tới scope creep và làm trễ hạn của chính cam kết ban đầu. Khách chấp nhận một lời từ chối có lý do, nhưng sẽ khó bỏ qua chuyện bạn trễ hạn.

Câu “không” cũng là việc bạn được thuê để làm

Atomic Object, một công ty tư vấn phần mềm, viết rằng việc của họ là dẫn khách đi trên một con đường khả thi và có kết quả hơn, chứ không phải chiều theo mọi ý khách.

Họ coi việc từ chối là cách bảo vệ ngân sách của khách. Họ cũng cam kết sẽ luôn nói thẳng khi một ràng buộc kỹ thuật khiến yêu cầu gốc không thể thực hiện được.

Tuy vậy, nói thẳng khác với nói cụt. Kantata, một hãng phần mềm cho ngành dịch vụ chuyên nghiệp, nhắc rằng không ai muốn nghe chữ “không” rồi bị bỏ lại với vấn đề vẫn còn nguyên. Một câu “không” trống không còn để quá nhiều chỗ cho khách tự tưởng tượng, và người ta thường tưởng tượng theo hướng xấu: “cậu này lười” hoặc “bên này không làm được”.

Vì thế một câu “không” tốt luôn có ba phần: ràng buộc được nói rõ, lý do được giải thích, và một con đường khác để khách chọn. Phần khó nhất lại nằm trước cả ba phần đó. Bạn phải biết khách thực sự cần gì.

Khách nói “bỏ bước duyệt”, nhưng họ cần gì?

Theo phân tích của techinterview.org, vòng phỏng vấn FDE kiểm tra đúng khả năng này: tìm ra thứ khách thật sự cần, khác với thứ họ yêu cầu.

Trong ví dụ trên, “bỏ bước duyệt” là một giải pháp mà khách tự nghĩ ra. Nhu cầu thật có thể là “giám đốc phải thấy agent tiết kiệm thời gian”, hoặc “đội vận hành đang phàn nàn vì phải bấm duyệt quá nhiều”.

Hai nhu cầu đó dẫn tới hai thiết kế khác nhau, và cả hai đều không đòi hỏi agent ghi thẳng vào hệ thống thật mà không có ai kiểm tra. Khi đã tìm ra nhu cầu thật, bạn không còn phải chọn giữa làm theo và từ chối. Bạn chỉ cần đề xuất một cách khác để đạt cùng mục tiêu.

Kịch bản sáu bước, đi từng câu

Bước 1: xin thời gian. FDE Academy mô tả cách FDE có kinh nghiệm xử lý một yêu cầu bất ngờ: họ xin xác nhận lại rồi phản hồi sau, thay vì hứa ngay tại chỗ. Trong phòng họp, câu đó có thể là: “Anh cho em kiểm tra lại phía ERP, 4 giờ chiều nay em gửi anh phương án.” Có giờ hẹn cụ thể thì khách sẽ không coi đó là né tránh.

Bước 2: hỏi về kết quả, đừng hỏi về tính năng. Đừng hỏi “anh có chắc muốn bỏ duyệt không?”, vì câu đó nghe như đang cãi. Hãy hỏi: “Buổi demo tuần sau, giám đốc cần thấy điều gì thì anh coi là thành công?” Giả sử câu trả lời là “thấy một đơn hàng đi từ email vào hệ thống trong vài giây, không cần ai gõ tay”.

Bước 3: nói thẳng ràng buộc. “Nếu agent ghi thẳng vào ERP, một lần trích xuất sai sẽ thành một đơn hàng sai trong hệ thống thật, và việc dọn lại rơi vào đội của anh.” Câu này nói về rủi ro của khách, không nói về chuyện bạn ngại làm. Atomic Object cũng gợi ý cách tương tự: không gạt bỏ ý tưởng của khách, mà cùng bàn vì sao nó có thể không phải điều người dùng muốn và tìm cách đi vòng.

Bước 4: đưa phương án. Theo Kantata, đưa ra các phương án giúp hai bên có điểm gặp nhau, và khách thấy mình vẫn được quyền chọn. Một bảng ngắn gửi kèm email chiều hôm đó có thể trông thế này (đây là ví dụ minh hoạ):

Phương án	Khách nhận được	Cái giá
A. Ghi thẳng vào ERP, bỏ duyệt	Demo nhanh nhất	Dữ liệu sai lọt vào hệ thống thật, khó rút lại
B. Agent ghi vào hàng chờ, duyệt bằng một cú bấm	Demo vẫn thấy được tốc độ	Thêm một thao tác nhỏ cho người duyệt
C. Tự động hoàn toàn cho loại đơn agent đã làm đúng ổn định, loại còn lại qua duyệt	Một phần tự động thật	Cần thêm thời gian đo độ chính xác, lịch bị lùi

Bạn vẫn để phương án A trong bảng. Khi được đặt cạnh cái giá của nó, khách thường tự loại nó đi, và họ thấy đó là quyết định của chính họ.

Bước 5: đồng ý có điều kiện. Nếu khách chọn C, câu trả lời theo cách FDE Academy gợi ý là “Được, và đây là ảnh hưởng của nó tới timeline hiện tại.” Hãy nói rõ hạng mục nào phải lùi lại, đừng âm thầm làm thêm buổi tối để giữ lịch cũ.

Bước 6: ghi lại. Kantata khuyên đưa những yêu cầu bị hoãn vào RAID log (Risks, Actions, Issues, Decisions) để tra lại sau này. Ghi một dòng như “Tự động ghi ERP không qua duyệt: hoãn, xem lại khi độ chính xác của loại đơn X đã được đo” sẽ biến câu “không” thành câu “chưa phải bây giờ”. Như vậy khách biết yêu cầu của họ không bị bỏ quên.

Những cách nói “không” làm hỏng quan hệ

Lỗi phổ biến nhất là hứa ngay trong phòng họp, vì sợ im lặng thì trông thiếu năng lực. Một câu “để em xác nhận rồi báo lại” luôn rẻ hơn một lời hứa mà sau đó bạn phải rút lại.

Lỗi thứ hai là từ chối trống không, kiểu “cái này không làm được đâu anh”. Khách mất phương án, còn bạn mất uy tín. Lỗi ngược lại cũng tai hại không kém: nói vòng vo về ràng buộc vì ngại va chạm, để rồi khách nghĩ là vẫn làm được và kế hoạch cứ thế đi tiếp.

Lỗi thứ ba là coi mỗi lần từ chối là chuyện riêng của một dự án. Sổ tay FDE của PostHog mô tả cách những mẫu hình lặp lại qua nhiều lần triển khai được biến thành công cụ dùng lại, kỹ năng chung và cải tiến cho sản phẩm.

Nếu khách thứ ba liên tiếp đòi bỏ bước duyệt, có thể chính bước duyệt đang quá nặng nề, và đội sản phẩm cần biết chuyện đó.

Cách cho nhà tuyển dụng thấy kỹ năng này

Với developer Việt Nam muốn chuyển sang FDE, kỹ năng này khó chứng minh bằng một dòng “giao tiếp tốt” trong CV. Hãy chuẩn bị sẵn một câu chuyện thật: yêu cầu ban đầu là gì, nhu cầu thật bạn tìm ra là gì, bạn đưa những phương án nào, và kết quả ra sao.

Trong CV, một dòng như “đề xuất phương án thay thế cho yêu cầu X, giữ đúng lịch bàn giao ban đầu” có sức nặng hơn nhiều so với những tính từ chung chung về kỹ năng mềm.

Khi phỏng vấn, đừng kể chuyện bạn đã thắng khách thế nào. Hãy kể lúc bạn hiểu ra khách thật sự cần gì, vì đó chính là khả năng mà vòng phỏng vấn FDE muốn kiểm tra.

Bài tập: sửa lại đoạn hội thoại này

Đây là một đoạn hội thoại giả định. Khách: “Bên anh muốn chatbot trả lời khách hàng mà không cần dẫn nguồn tài liệu, nhìn cho gọn.” FDE: “Dạ được anh, em làm luôn trong tuần này.”

Hãy viết lại câu trả lời của FDE theo sáu bước ở trên: một câu xin thời gian có giờ hẹn, một câu hỏi về kết quả khách muốn thấy, một câu nói rõ rủi ro mà chính khách sẽ gánh, một bảng ba phương án kèm cái giá, một câu đồng ý có điều kiện và một dòng RAID log.

Nếu bản viết lại của bạn không có chữ “không” nào mà khách vẫn hiểu vì sao phương án gốc bị hoãn, bạn đã làm đúng.

Atomic Object nói việc của người tư vấn là dẫn khách tới một con đường khả thi hơn. Một FDE gật đầu với mọi yêu cầu đã tự bỏ đi đúng phần việc đó.