# Khi dữ liệu cho thấy quy trình của khách có vấn đề: FDE nên nói với người sở hữu quy trình thế nào

> Người thiết kế bước duyệt đang gây lỗi lại là người bạn cần nhất để sửa nó, nên cách bạn mở lời quyết định họ sẽ cùng bạn sửa hay đứng ra bảo vệ quy trình.

Bản gốc: https://fdetimes.net/vi/bach-khoa/khi-du-lieu-cua-khach-cho-thay-quy-trinh-cua-chinh-ho-sai/

Tuần thứ ba của deployment, bạn chạy một truy vấn trên log và nhận được kết quả không ai muốn nghe. Phần lớn các ngoại lệ mà khách nhờ bạn tự động hóa lại bắt nguồn từ một bước duyệt do chính trưởng nhóm vận hành thiết kế. Sáng thứ Hai, người đó sẽ ngồi đối diện bạn trong buổi họp tiến độ.

Lúc này bạn có hai cách làm sai. Nói vụng thì bạn mất đồng minh quan trọng nhất trong tổ chức của khách. Im lặng thì bạn tự động hóa đúng cái quy trình đang có lỗi, và lỗi sẽ xảy ra nhanh hơn trước.

Kỹ năng nằm giữa hai cách đó nghe có vẻ "mềm" so với viết code. Nhưng nó thường quyết định deployment có tạo ra thay đổi thật hay chỉ để lại một dashboard không ai mở.

## Khách nhờ sửa triệu chứng, còn bạn nhìn thấy nguyên nhân

GSDC Council, khi mô tả các tình huống FDE hay gặp, nhắc một điểm quen thuộc: giải pháp khách yêu cầu có thể không phải là vấn đề thật. Họ nhờ bạn tự động hóa một bước, nhưng chỗ cần sửa có khi nằm ở bước ngay trước nó.

Vì sao FDE hay phát hiện ra điều này trước chính khách hàng? Vinoo Ganesh, khi nói về cách Kepler làm forward deployed engineering, cho rằng việc quan sát người ta làm việc cho ra một loại bằng chứng khác hẳn với việc hỏi họ có thích một tính năng hay không.

Theo một bài phân tích về mô hình của Palantir, FDE ở đó dành phần lớn tuần làm việc, 30–40 giờ, ngồi ngay cạnh các analyst và người vận hành, thường trong một cơ sở bảo mật. Ngồi gần như vậy, bạn sẽ thấy quy trình trên giấy và quy trình thật khác nhau ở đâu.

Nhờ vậy, phát hiện của bạn có cơ sở từ công việc thật chứ không chỉ từ lời kể, dù nó vẫn cần được kiểm chứng. Cái khó là người viết ra quy trình trên giấy vẫn đang tin vào nó.

## Đưa sự kiện ra trước, cách diễn giải để sau

Phương pháp STATE trong cuốn *Crucial Conversations* cho bạn một trình tự rõ ràng. Mọi cuộc nói chuyện nhạy cảm đều nên bắt đầu bằng sự kiện quan sát được. Sau đó bạn kể cách mình diễn giải, nhưng kể nó như một câu chuyện có thể sai, không phải một sự thật không ai được cãi.

Tiếp theo, hãy khiêm tốn hỏi người kia nhìn chuyện này thế nào, và nói rõ rằng bạn muốn nghe quan điểm của họ, kể cả khi nó khác hẳn quan điểm của bạn.

Trình tự này hiệu quả vì sự kiện thì khó cãi, còn kết luận thì ai cũng cãi được. Nhưng nó chỉ đứng vững khi sự kiện của bạn thật sự chắc. Quirk's, trong một bài hướng dẫn cách báo tin xấu, nhấn mạnh rằng tin xấu nào cũng phải có dữ liệu chắc chắn đỡ phía sau, và dữ liệu đó phải dựa trên một phương pháp vững.

Bài của Quirk's còn nhắc một điểm dễ quên: tin xấu hiếm khi xấu hoàn toàn, và nhiều khách hàng chỉ cần điều chỉnh chiến lược để phát huy điểm mạnh của mình. Vì thế, cạnh sự kiện xấu, hãy luôn nêu cả phần đang chạy tốt.

**Điểm mấu chốt:** Hãy đưa sự kiện ra trước, rồi mới nói cách bạn hiểu chúng.

## Một buổi họp, đi qua từng câu

Thử hình dung một công ty phân phối nhờ bạn xây agent tự đối chiếu hóa đơn với đơn đặt hàng (PO). Sau bốn tuần, giả sử log cho thấy 1.200 hóa đơn, trong đó 310 hóa đơn rơi vào hàng chờ xử lý tay.

Bạn lần theo từng hóa đơn và thấy 248 trong số 310 hóa đơn đó có PO được lập sau khi hàng đã về kho. Vì vậy agent không có gì để đối chiếu.

Bước "nhận hàng trước, lập PO sau" do trưởng nhóm vận hành đặt ra để giao hàng nhanh hơn. Đây là một kịch bản năm câu bạn có thể dùng.

**Nêu sự kiện:** "Trong bốn tuần qua có 310 hóa đơn phải xử lý tay. Với 248 hóa đơn trong số đó, thời điểm lập PO muộn hơn thời điểm nhận hàng. Tôi có mang theo mười hóa đơn cụ thể để anh xem."

**Nói điểm đang chạy tốt:** "Nhưng 890 hóa đơn còn lại đã khớp tự động, nghĩa là phần đối chiếu đang chạy được."

**Kể giả thuyết:** "Có thể việc lập PO sau là lý do chính khiến số hóa đơn xử lý tay không giảm. Nhưng tôi chưa biết bối cảnh vì sao bước này được đặt ra như vậy."

**Hỏi và mời phản biện:** "Anh nhìn mấy con số này thế nào? Nếu có chỗ tôi đọc sai, ví dụ có những trường hợp hàng gấp bắt buộc phải làm thế, tôi rất muốn biết."

**Đề xuất một bước thử nhỏ:** "Nếu anh thấy hợp lý, mình thử hai tuần với một nhóm nhà cung cấp: lập PO tạm trước khi nhận hàng. Hết hai tuần, mình so số hóa đơn phải xử lý tay của nhóm đó với bốn tuần vừa rồi."

Để ý rằng trong cả kịch bản không có câu "quy trình của anh sai". Người nghe tự đi đến kết luận đó, hoặc chỉ cho bạn thấy một ngoại lệ chính đáng mà log không ghi lại. Kết cục nào cũng có lợi cho bạn.

## Trước buổi họp: kiểm chứng như thể chắc chắn sẽ bị bác bỏ

Bước chuẩn bị bắt đầu từ phương pháp chứ chưa phải lời lẽ. Hãy kiểm tra lại cách bạn đếm: khung thời gian, nguồn timestamp, những bản ghi bị loại ra. Người sở hữu quy trình sẽ tấn công đúng mắt xích yếu nhất.

Tiếp theo, chọn vài trường hợp và đi xem tận mắt, đúng với tinh thần Ganesh mô tả: quan sát công việc cho ra loại bằng chứng mà truy vấn không cho được. Mười hóa đơn thật có sức thuyết phục hơn một biểu đồ.

Sau đó, hãy chuẩn bị sẵn một hành động. Natalie Meurer, khi nói về "bí mật bẩn" của forward deployed engineering, cho rằng một ứng dụng vận hành hữu ích phải giúp người ta hành động dựa trên dữ liệu, chứ không chỉ để nhìn dữ liệu.

Trong ví dụ trên, đó chính là câu cuối của kịch bản: một đợt thử hai tuần, có phạm vi hẹp và có con số để so sánh khi kết thúc.

## Những cách khiến cuộc nói chuyện hỏng

Lỗi phổ biến nhất là mở đầu bằng kết luận. Câu đầu tiên đã là phán xét thì người nghe sẽ dùng phần còn lại của buổi họp để phản bác, thay vì đọc số liệu cùng bạn.

Một cái bẫy khác là nói khi bạn chưa có lòng tin của họ. Ganesh mô tả cách FDE dùng những bản sửa nhỏ, thành công để giành được lòng tin và quyền tiếp cận các vấn đề sâu hơn. Nếu tuần đầu tiên bạn đã chỉ ra lỗi trong quy trình của người khác, bạn đang tiêu số vốn mình chưa kịp có.

Cũng đừng bất ngờ đưa phát hiện ra trước mặt cấp trên của họ. Nên nói riêng với người sở hữu quy trình trước, để họ có cơ hội phản biện và cùng bạn trình bày lên trên.

Cuối cùng, đừng chỉ mang theo dashboard mà không có đề xuất. Buổi họp khi đó dễ dừng lại ở một cái gật đầu, rồi không có gì thay đổi.

## Biến kỹ năng thành bằng chứng khi đi xin việc

Khi chuẩn bị phỏng vấn FDE, hãy sẵn sàng cho một câu hỏi kiểu: "Kể về một lần bạn phải nói điều khách không muốn nghe." Một câu trả lời tốt có bốn phần: dữ liệu bạn tìm thấy, cách bạn kiểm chứng, người bạn thuyết phục, và thay đổi đo được sau đó.

Khi đọc JD, hãy để ý những dòng nói về làm việc với stakeholder phía khách hay tìm hiểu quy trình vận hành của họ. Đó là chỗ câu chuyện này nên xuất hiện trong CV, viết bằng số liệu chứ không bằng tính từ.

Bài tập tuần này: lấy con số đáng lo nhất trong dự án bạn đang làm, rồi viết kịch bản năm câu theo mẫu ở trên. Đọc nó cho một đồng nghiệp nghe và hỏi họ: câu nào nghe như đang buộc tội?

Người sở hữu quy trình không cần bạn chứng minh họ sai. Họ cần thấy rằng sửa quy trình cùng bạn ít rủi ro hơn là tiếp tục bảo vệ nó.

**Thử ngay tuần này:**

- Chọn một con số đáng lo trong deployment bạn đang làm, lấy 10 bản ghi cụ thể đằng sau nó và tự kiểm tra xem phương pháp đếm có đứng vững không.
- Viết sẵn ba câu mở đầu cho buổi nói chuyện: một câu chỉ có sự kiện, một câu là giả thuyết bắt đầu bằng 'có thể', một câu hỏi người sở hữu quy trình nhìn chuyện này thế nào.
- Thêm vào CV một dòng theo mẫu: phát hiện gì từ dữ liệu, đã thống nhất với ai, quy trình thay đổi ra sao, kết quả đo được.

## Nguồn

- [Researchers, it's OK to give bad news (and here's how to do it)](https://www.quirks.com/articles/researchers-it-s-ok-to-give-bad-news-and-here-s-how-to-do-it)

- [Crucial Conversations' STATE Method: 5 Essential Skills](https://www.shortform.com/blog/crucial-conversations-state/)

- [Think Like a Forward Deployed Engineer: 5 Real-World Scenarios](https://www.gsdcouncil.org/blogs/think-like-a-forward-deployed-engineer-real-world-scenarios)

- [How Forward Deployed Engineering is done at Kepler (Vinoo Ganesh, AI Engineer World's Fair 2026)](https://ai.engineer/talks/1OMHGsUZiqA-forward-deployed-engineering-is-done-kepler)

- [Palantir's Forward-Deployed Engineering Playbook: The Original Model Anthropic and OpenAI Are Copying](https://getperspective.ai/blog/palantir-forward-deployed-engineering-playbook-anthropic-openai-copying)

- [The Dirty Secret of Forward Deployed Engineering (Natalie Meurer, AI Engineer World's Fair 2026)](https://www.ai.engineer/talks/Byv311hdoHE-dirty-secret-forward-deployed-engineering)