# 10 phút với lãnh đạo khách hàng: biến kết quả pilot thành một quyết định được ký

> Pilot của bạn có thể chạy rất tốt, nhưng nếu phút đầu tiên của buổi họp chỉ dùng để kể kiến trúc, nhiều khả năng bạn sẽ không có buổi thứ hai.

Bản gốc: https://fdetimes.net/vi/bach-khoa/trinh-bay-ket-qua-cho-lanh-dao-khach-10-phut/

Thử hình dung bạn vừa xong sáu tuần pilot ở một công ty logistics. Agent đọc chứng từ chạy ổn, bộ eval xanh, đội vận hành đã quen dùng. Rồi lịch họp gửi tới: giám đốc vận hành dành cho bạn 10 phút vào chiều thứ Năm.

Kết cục của sáu tuần làm việc nằm trong 10 phút đó. Pilot có thể lên production, cũng có thể nằm mãi trong một thư mục chia sẻ. Will Larson, người viết blog Irrational Exuberance, nhận xét rằng lãnh đạo thường chốt luôn trong buổi họp, và bạn hiếm khi có thêm một lần để bàn lại trước khi quyết định được đưa ra.

Vì vậy, đây không phải kỹ năng mềm có cũng được, không có cũng chẳng sao. Code của bạn chỉ tạo ra giá trị khi có người phía khách hàng ký cho nó chạy thật. Bài này hướng dẫn cách dựng 10 phút đó, từng phút một.

## Lãnh đạo không duyệt kết quả, họ duyệt đề xuất

Kỹ sư quen kể chuyện theo thứ tự thời gian: bài toán là gì, đã thử những gì, gặp lỗi gì, cuối cùng ra con số nào. Đến phút thứ tám mới hỏi xin quyết định. Lúc đó người nghe đã đọc điện thoại từ lâu.

Larson khuyên làm ngược lại. Theo ông, cách sắp xếp rõ ràng nhất luôn là nói ý tổng quát trước, rồi mới đến từng ý chi tiết bên dưới. Đây là Pyramid Principle của Barbara Minto, còn đoạn mở đầu thì dựng theo SCQA: Situation, Complication, Question, Answer.

Nancy Duarte, chuyên gia về thuyết trình, cũng khuyên tương tự: mở đầu bằng phát hiện và khuyến nghị, và nói ngay từ đầu bạn sẽ dùng thời gian cuộc họp ra sao.

Larson còn chỉ ra một điểm dễ bị bỏ qua. Bạn không thể tạo đồng thuận trong phòng nếu không có một đề xuất để mọi người cùng đứng sau. Nếu bạn chỉ mang tới một vấn đề, cả phòng sẽ tranh luận. Nếu bạn mang tới một đề xuất, họ sẽ chỉnh sửa nó rồi ký.

**Điểm mấu chốt:** Lãnh đạo không ký vào kết quả kỹ thuật, họ ký vào một đề xuất rõ ràng.

## Kịch bản 10 phút, viết ra từng câu

Quay lại ví dụ giả định ở trên. Pilot xử lý 2.000 chứng từ hải quan. Agent tự hoàn tất 1.640 chứng từ, tức 82%, còn 360 chứng từ được chuyển cho người kiểm.

Thời gian xử lý trung bình mỗi chứng từ giảm từ 9 phút xuống 2 phút. Quyết định bạn cần là cho agent quyền ghi vào ERP production ở một kho, kèm một người phía khách làm chủ quy trình kiểm duyệt.

**Phút 0–1, đề xuất và luật chơi.** "Em đề nghị anh duyệt hôm nay hai việc: cho agent ghi vào ERP ở kho Bình Dương, và giao trưởng nhóm chứng từ làm chủ quy trình kiểm duyệt trong 8 tuần. Em trình bày 6 phút, 4 phút còn lại dành cho câu hỏi của anh." Duarte cho rằng khi người nghe biết trước sẽ có phần hỏi đáp, họ dễ để bạn trình bày hết các ý chính mà không ngắt lời.

**Phút 1–3, SCQA.** Situation: đội chứng từ đang nhập tay toàn bộ. Complication: mùa cao điểm sắp tới mà không tuyển thêm người kịp. Question: có nên đưa agent vào vận hành thật trước cao điểm không? Answer: nên, với hai điều kiện vừa nêu.

**Phút 3–6, ba bằng chứng, mỗi bằng chứng một câu.** Agent tự xử lý 82% chứng từ. Chứng từ nào chưa vượt ngưỡng tin cậy thì không được ghi vào ERP khi chưa qua người kiểm. Những lỗi đã gặp trong pilot đều đã có cách chặn, chi tiết nằm ở phụ lục.

**Phút 6–7, các phương án và cái giá của việc chờ.** Phương án A là triển khai ngay ở một kho. Phương án B là chạy pilot thêm 4 tuần, nghĩa là bước vào cao điểm vẫn với quy trình nhập tay. Bạn nói rõ mình khuyến nghị phương án nào và vì sao.

**Phút 7–10, hỏi đáp và chốt.** Câu cuối cùng nhắc lại đúng đề xuất ở phút đầu, rồi bạn dừng lại chờ câu trả lời.

Phần khó nhất là chuyển ngôn ngữ kỹ thuật thành ngôn ngữ ra quyết định:

| Câu kỹ sư hay nói | Câu lãnh đạo cần nghe |
|---|---|
| F1 của bước trích xuất đạt mức cao | 82% chứng từ không cần người chạm vào |
| Có fallback human-in-the-loop | Chứng từ chưa chắc chắn luôn có người duyệt trước khi vào ERP |
| Cần thêm quyền truy cập hệ thống | Cần anh duyệt quyền ghi ở một kho trong 8 tuần |
| Anh thấy kết quả thế nào ạ? | Anh có duyệt phương án A hôm nay không? |

## Việc thật sự diễn ra trước buổi họp

Vì không có lần thứ hai, phần lớn công việc phải xong trước khi bước vào phòng. Larson gọi việc thống nhất với các bên liên quan trước buổi trình bày là nemawashi.

Trong ví dụ trên, bạn cần gặp riêng đội bảo mật IT về quyền ghi vào ERP, và gặp trưởng nhóm chứng từ để chắc rằng người này đồng ý nhận vai chủ quy trình.

Nếu một người trong phòng nghe đề xuất lần đầu ở buổi họp chính, rủi ro rất lớn là câu trả lời sẽ thành "để tuần sau bàn tiếp".

Sau đó mới đến deck. Duarte khuyên đặt một trang tóm tắt ngắn các ý chính lên đầu, phần còn lại chỉ để làm phụ lục. Sơ đồ kiến trúc, bảng eval, danh sách lỗi đều chuyển ra phụ lục và chỉ mở khi có người hỏi.

Để biết trang tóm tắt đã đủ gọn chưa, hãy dùng mẹo của Duarte: tưởng tượng cả slot của bạn bị cắt còn 5 phút. Thứ còn lại sau khi cắt chính là bài trình bày.

Kiger viết trên LeadDev rằng việc chắt lọc suy nghĩ như vậy còn buộc bạn hiểu rõ bài toán hơn. Nếu bạn chưa viết được câu đề xuất trong một dòng, rất có thể bạn chưa hiểu dự án đủ sâu.

## Buổi họp chưa xong khi bạn rời phòng

Kiger nhấn mạnh rằng những điểm quan trọng phải được nhắc lại, và việc gì cũng cần dọn nền từ trước rồi bám tiếp sau buổi họp. Ngay trong ngày, hãy gửi một email ngắn chốt lại quyết định, người chịu trách nhiệm, phạm vi và mốc kiểm tra tiếp theo.

Email này biến một cái gật đầu trong phòng họp thành một cam kết có văn bản mà cả đội khách hàng có thể dựa vào.

Còn nếu câu trả lời là "chưa" hoặc "để tuần sau", đừng rời phòng khi chưa hỏi rõ họ cần thêm điều gì để duyệt và cần gặp thêm ai. Khi đó, email chốt lại ghi đúng những điều kiện ấy cùng ngày bạn quay lại với câu trả lời.

## Những lỗi khiến 10 phút trôi qua vô ích

Lỗi phổ biến nhất là mở đầu bằng kiến trúc. Lãnh đạo cần đúng thông tin họ dùng để quyết định, vì như Kiger viết, thời gian và sự chú ý của họ có hạn. Lỗi thứ hai là đem vấn đề vào phòng mà không có đề xuất, khiến buổi họp thành một cuộc brainstorm không có kết quả.

Lỗi tiếp theo khó nhận ra hơn: dồn quá nhiều con số. Ba bằng chứng có sức nặng hơn mười hai chỉ số, vì người nghe còn nhớ được chúng. Cuối cùng là xin quyết định một cách mơ hồ. "Anh thấy sao" không phải một quyết định. "Anh có duyệt phương án A không" mới là một quyết định.

## Bài tập trong tuần

Lấy một việc kỹ thuật bạn đã làm xong trong quý này, chẳng hạn một lần migration hay một tính năng mới, rồi viết lại thành kịch bản 10 phút theo đúng khung trên. Câu đầu tiên phải trả lời được câu hỏi: ai cần duyệt việc gì, và trước ngày nào.

Kịch bản đó cũng là thứ bạn nên mang vào phỏng vấn nếu đang nhắm tới vai FDE. Khi được hỏi về một dự án đã làm, hãy mở bằng quyết định mà kết quả của bạn đã giúp ai đó đưa ra, rồi mới đến kỹ thuật. Trong CV, thay dòng "kỹ năng giao tiếp tốt" bằng đúng một câu như vậy.

Kết quả sáu tuần pilot vẫn giữ nguyên dù bạn trình bày ra sao. Thứ quyết định nó có lên production hay không là câu đầu tiên bạn nói trong phòng họp.

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

- Viết câu đề xuất cho dự án bạn đang làm, gói trong một dòng, gồm việc cần duyệt, người chịu trách nhiệm và mốc thời gian.
- Tự bấm giờ và trình bày dự án đó trong 5 phút, rồi gạch mọi slide bạn không kịp dùng tới.
- Liệt kê những người có thể phản đối đề xuất và hẹn gặp riêng từng người trước buổi họp chính.

## Nguồn

- [How to present to executives (Will Larson, Irrational Exuberance)](https://lethain.com/present-to-executives/)

- [How to effectively present to senior executives (Nancy Duarte)](https://www.duarte.com/blog/how-to-effectively-present-to-senior-executives/)

- [How to communicate with an executive audience (Kiger, LeadDev)](https://leaddev.com/communication/how-communicate-with-executive-audience)