# Dự án trễ một tuần, eval thấp hơn mức đã hứa: cách báo tin xấu cho khách

> Khách hiếm khi nổi giận vì một con số xấu. Họ nổi giận khi bị bất ngờ, và khi người báo tin đến họp mà không mang theo phương án nào.

Bản gốc: https://fdetimes.net/vi/bach-khoa/bao-tin-xau-cho-khach-khi-du-an-tre-hoac-eval-khong-dat/

Thử hình dung: chiều thứ Năm, bạn vừa chạy xong bộ eval cuối cùng trước buổi demo thứ Hai. Agent phân loại ticket hỗ trợ đạt 81%, trong khi slide kickoff ba tuần trước ghi rõ mục tiêu 90%. Khách chưa biết gì. Người quản lý phía khách đã mời cả sếp của họ dự buổi demo.

Ai làm FDE đủ lâu cũng sẽ gặp cảnh này, khi thì là một con số eval hụt, khi thì là một tuần trễ hạn. Phần kỹ thuật thường sửa được. Niềm tin của khách còn hay mất phụ thuộc nhiều hơn vào cách bạn báo tin trong mấy ngày trước buổi demo.

Lý do khá đơn giản. Dự án nào cũng có trục trặc, nên khách không đánh giá bạn qua chuyện có trục trặc hay không. Họ đánh giá bạn qua chuyện họ biết tin lúc nào, nghe theo cách nào và rời cuộc họp với kế hoạch gì.

## Vì sao bị bất ngờ còn tệ hơn chính tin xấu?

Atomic Object, một công ty phần mềm làm dịch vụ cho khách hàng, rút ra từ kinh nghiệm của mình rằng phản ứng tệ nhất xảy ra khi tin xấu ập đến mà người nghe không hề được báo trước.

Con số 81% không phá hỏng quan hệ. Nhưng nếu khách nghe con số đó lần đầu ngay trong buổi demo, trước mặt sếp họ, thì quan hệ có thể hỏng thật.

Vì thế việc báo tin xấu bắt đầu từ trước khi có tin xấu. Leslie John, giáo sư tại Harvard Business School, khuyên ngay từ đầu quan hệ hãy nói rõ rằng bạn đứng về phía khách, đồng thời chuẩn bị cho họ tinh thần rằng về sau có thể có tin không vui.

Với FDE, điều đó có nghĩa là ngay buổi kickoff đã nói với khách rằng 90% là mục tiêu, và tuần nào bạn cũng sẽ báo khoảng cách còn lại.

Scott Logic, một công ty tư vấn công nghệ, có một cách diễn đạt nên học thuộc: mọi ước lượng chỉ là một ảnh chụp tại thời điểm đó, nó sẽ thay đổi, và bạn sẽ cập nhật thường xuyên. Khi khách đã quen với những bản cập nhật kiểu này, con số 81% chỉ là một bản cập nhật nữa, không phải một cú sốc.

## Mở đầu bằng phát hiện, không bằng lời xin lỗi

Phản xạ tự nhiên là xin lỗi trước rồi giải thích sau. Handbook về FDE của PostHog đi theo hướng khác: khi trao đổi với khách, hãy mở đầu bằng điều bạn đã tìm ra và việc bạn đề xuất làm.

Đừng mở đầu bằng chuyện bạn vừa làm xong một bản báo cáo. "Em gửi anh báo cáo eval tuần này" là một câu vô ích. "Agent đạt 81%, chưa tới 90%, và em đề xuất thế này" thì đi thẳng vào vấn đề.

Atomic Object khuyên trình bày tin xấu rõ ràng, không viện cớ, có dữ liệu và hình ảnh minh họa đi kèm, đồng thời đến cuộc họp với các giải pháp đã chuẩn bị sẵn để khách thấy bạn thật sự quan tâm chứ không đến tay không.

Harvard Program on Negotiation bổ sung một ý: hãy trình bày tin xấu theo hướng xây dựng, chỉ ra điều gì vẫn làm được.

**Điểm mấu chốt:** Khách tha thứ cho một con số xấu, nhưng khó tha thứ cho việc bị bất ngờ.

## Ví dụ từ đầu đến cuối: 81% thay vì 90%

Quay lại tình huống agent phân loại ticket. Trước khi viết email, hãy mổ xẻ con số. Giả sử bộ test có 200 ticket: 81% nghĩa là 162 ticket đúng, 38 ticket sai. Gom lỗi theo nhóm thì thấy 30 trong 38 lỗi rơi vào hai loại ticket là hoàn tiền và tranh chấp hóa đơn, tổng cộng 40 ticket.

Đến đây bài toán đã khác. Bỏ hai loại đó ra, còn 160 ticket với 8 lỗi, tức độ chính xác 95% trên 80% số ticket. Bạn không chỉ có tin xấu nữa: bạn có tin xấu, kèm một phần lớn phạm vi đã vượt mục tiêu và một vùng hẹp cần xử lý thêm.

Email gửi khách vào sáng thứ Sáu, trước buổi demo, có thể viết như sau:

> **Tiêu đề: Kết quả eval trước demo — 81% tổng thể, 95% trên 6/8 loại ticket**
>
> Chào anh Minh, kết quả eval cuối cùng là 81%, thấp hơn mục tiêu 90% hai bên đã thống nhất. Nguyên nhân tập trung ở hai loại ticket: hoàn tiền và tranh chấp hóa đơn chiếm 30 trên 38 lỗi (biểu đồ đính kèm).

Sáu loại còn lại đạt 95%.
>
> Có ba phương án. (A) Demo và go-live cho sáu loại đạt chuẩn, hai loại kia vẫn do nhân viên xử lý. (B) Lùi demo một tuần để bổ sung dữ liệu gán nhãn cho hai loại khó.

(C) Go-live cả tám loại, nhưng ticket hoàn tiền và hóa đơn phải qua người duyệt.
>
> Em đề xuất phương án A. Đây là kết quả tại thời điểm hôm nay, em sẽ gửi bản cập nhật cho hai loại còn lại vào thứ Sáu tuần sau. Anh cho em 15 phút chiều nay để chốt phương án trước buổi thứ Hai nhé.

Mỗi phần trong email đều có lý do. Tiêu đề nêu luôn phát hiện. Biểu đồ là dữ liệu, không phải lời biện hộ. Ba phương án cho khách quyền chọn.

Khuyến nghị cho khách biết bạn nghĩ gì, còn cuộc gọi 15 phút biến phương án thành quyết định. Atomic Object nhắc rằng đã chịu áp lực báo tin xấu và bàn phương án thì đừng để cuộc trao đổi kết thúc mà chưa có hướng đi tiếp.

## Khi trễ một tuần, câu hỏi đầu tiên là trễ vì đâu

Trễ hạn có hai loại, và cách báo cho mỗi loại khác nhau. Loại thứ nhất là bạn ước lượng sai hoặc gặp sự cố kỹ thuật. Atomic Object cho rằng với trễ tiến độ, phương án tốt nhất thường là kiểm soát phạm vi bằng cách cắt bớt một phần.

Loại thứ hai là phạm vi phình ra. Thử hình dung bạn hứa tích hợp ba hệ thống, giữa chừng khách xin thêm hai hệ thống nữa, và bạn gật đầu cho êm chuyện. Handbook của PostHog nói thẳng: một hạng mục phình gấp đôi phạm vi là một báo giá mới, không phải một lần gia hạn ngầm.

Khi báo trễ, hãy tách bạch phần đã cam kết với phần phát sinh, rồi đề xuất giao đúng hạn ba hệ thống đã hứa, đưa hai hệ thống mới sang giai đoạn sau.

Cách phòng tốt nhất vẫn nằm ở đầu dự án. PostHog khuyên nên chốt phạm vi nhỏ, vì mở rộng một phạm vi chặt rẻ hơn nhiều so với gỡ lại một phạm vi lỏng. Phạm vi càng chặt thì càng ít tin xấu phải báo.

## Năm bước, và những lỗi hay gặp

Quy trình gói lại như sau. Cảnh báo rủi ro ngay khi nó xuất hiện. Phân tích con số cho đến khi tìm ra phần còn đạt chuẩn. Viết thông điệp mở đầu bằng phát hiện, có dữ liệu đi kèm. Đưa ra hai đến ba phương án và một khuyến nghị. Kết thúc bằng một quyết định cùng ngày cập nhật tiếp theo.

Còn một lỗi tinh vi hơn: tô hồng. Trình bày theo hướng tích cực nghĩa là chỉ ra con đường vẫn còn mở, chứ không phải giấu con số 81% sau con số 95%.

Scott Logic nhấn mạnh rằng giao tiếp là nền tảng của niềm tin. Vì thế, một bản tô hồng mà khách tự phát hiện ra sẽ làm hao chính thứ niềm tin bạn đang cố giữ.

## Biến kỹ năng này thành lợi thế khi đi phỏng vấn

Nếu nhà tuyển dụng hỏi về một lần bạn phải báo tin không vui cho khách hoặc stakeholder, đừng kể chung chung. Hãy chuẩn bị sẵn một câu chuyện có thật, kể theo đúng cấu trúc phát hiện, dữ liệu, phương án, quyết định, kết quả.

Trong CV, thay vì ghi "giao tiếp tốt với khách hàng", hãy viết kiểu "đề xuất thu hẹp phạm vi go-live khi eval chưa đạt mục tiêu, giữ đúng lịch bàn giao".

Đừng tập nó lần đầu trước mặt khách thật.

Một tin xấu được báo sớm, có dữ liệu và có hướng đi thường kết thúc bằng câu "ok, làm theo phương án A". Còn nếu giấu thêm vài ngày, cùng tin đó có thể kết thúc bằng một cuộc họp không có bạn tham dự.

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

- Chọn một rủi ro có thật trong dự án hiện tại và gửi khách một dòng cảnh báo sớm, kèm ngày bạn sẽ cập nhật lại.
- Lấy kết quả eval gần nhất, gom các lỗi theo nhóm và tính lại độ chính xác cho phần phạm vi còn lại sau khi bỏ hai nhóm lỗi nhiều nhất.
- Viết sẵn bản nháp email báo tin xấu theo năm phần trong bài cho tình huống bạn sợ nhất, rồi nhờ một đồng nghiệp đóng vai khách đọc thử.

## Nguồn

- [How forward deployed engineers work - Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)

- [Problems Happen; How Do You Deliver the Bad News to Clients?](https://spin.atomicobject.com/deliver-bad-news/)

- [Delivering Bad News in Negotiation](https://www.pon.harvard.edu/daily/negotiation-training-daily/dear-negotiation-coach-breaking-bad-news-nb)

- [How to deliver a difficult message](https://blog.scottlogic.com/2020/08/04/how-to-deliver-a-difficult-message.html)