# Champion nội bộ: tìm, thử và nuôi người bảo vệ dự án khi bạn vắng mặt

> Người khen demo của bạn nhiều nhất thường không phải là người sẽ đứng lên bảo vệ nó khi ngân sách bị cắt, và có một phép thử đơn giản để biết ai là ai.

Bản gốc: https://fdetimes.net/vi/bach-khoa/nguoi-ung-ho-noi-bo-champion-tai-khach-hang/

Cuộc họp quyết định số phận pilot của bạn hầu như luôn diễn ra khi bạn vắng mặt. Đó là buổi giao ban của ban điều hành bên khách, nơi có người hỏi cái agent kia có đáng làm tiếp không. Câu trả lời phụ thuộc vào một chuyện: trong phòng có ai lên tiếng thay bạn hay không.

Ở mảng này, kỹ năng code không cứu được bạn. Integration có thể sạch, eval có thể đẹp, nhưng nếu không ai bên khách chịu bảo vệ dự án khi ngân sách bị siết hoặc một phòng ban khác phản đối, công sức của bạn dừng lại ở bản demo.

Người làm việc đó gọi là champion nội bộ. Tìm, thử và nuôi champion là một kỹ năng học được, giống như debug: có giả thuyết, có phép thử, có dấu hiệu sai.

## Người thích bạn chưa chắc là champion

Một champion hội đủ ba thứ: tin rằng giải pháp nên thành công, có ảnh hưởng thật, và với tới được người ra quyết định, như cách UserGems mô tả. Nhưng đặc điểm định nghĩa, theo Spotlight.ai, là họ đặt uy tín nghề nghiệp của chính mình vào thành công của dự án. Thiếu điều đó, bạn chỉ có một người dễ chịu.

Ranh giới quan trọng nhất vì thế nằm giữa champion và supporter. Khi dự án dính vào chính trị nội bộ, supporter im lặng, còn champion lao vào bảo vệ nó. Ở giai đoạn demo, hai nhóm này trông giống hệt nhau.

## Tìm ở đâu: dưới chân, không phải trên đỉnh

Bản năng của nhiều kỹ sư là tìm người có chức danh to nhất. Thực tế, sự ủng hộ của một đồng nghiệp được nể trọng nhiều khi nặng ký hơn cả một cuộc gặp với lãnh đạo cấp C, vì người đó mở đường tới những stakeholder mà sơ đồ tổ chức không cho bạn thấy, điều UserGems cũng nhấn mạnh.

Chỗ nên tìm đầu tiên là end-user: xác định họ sớm và bạn sẽ thấy những người có thể thành người ủng hộ mạnh nhất, lời khuyên mà Close.com vốn viết cho dân bán hàng. FDE còn có lợi thế hơn: bạn ngồi cạnh end-user hằng ngày, thấy ai bị quy trình cũ hành hạ và ai được cả nhóm hỏi ý kiến.

Trong mô hình FDE của Tryolabs, tuần đầu là để chui vào môi trường thật của khách: vẽ bản đồ hệ thống và kéo các bên liên quan về cùng một hướng. Hãy làm hai việc đó song song. Khi lần theo một luồng dữ liệu, bạn sẽ gặp đúng những người vận hành nó, và đó là danh sách ứng viên đầu tiên.

## Ví dụ: hai ứng viên ở một công ty logistics

Thử hình dung bạn đang triển khai một agent hỗ trợ điều phối xe cho ca đêm. Ứng viên thứ nhất là Minh, trưởng nhóm IT, luôn trả lời Slack trong năm phút và khen demo trước mặt mọi người. Ứng viên thứ hai là Hà, trưởng ca điều phối, hỏi toàn câu khó, nhưng điều phối viên nào gặp ca rắc rối cũng chạy sang hỏi cô.

Nuôi champion là quan hệ hai chiều: bạn đối xử với họ như đồng nghiệp, như chuyên gia, và trao giá trị trước khi đòi hỏi, đúng tinh thần Close.com mô tả. Vì thế bước đầu tiên với Hà không phải là xin gì cả. Bạn sửa giúp cô cái báo cáo bàn giao ca mà cô vẫn phải ghép tay mỗi sáng.

Hai tuần sau, khi đã có số liệu chạy thử, mới đến phép thử. Cách thực dụng nhất là nhờ ứng viên mở cửa tới người nắm ngân sách và xem điều đó có xảy ra không. Kịch bản có thể như sau.

> **Bạn:** Tuần sau mình có số liệu hai tuần chạy ca đêm. Chị nghĩ anh giám đốc vận hành có nên xem trước buổi review quý không?
>
> **Hà:** Nên. Thứ Năm anh ấy họp với các trưởng ca, để chị xin mười lăm phút. Chị nói phần vận hành, em lo phần kỹ thuật.

Hỏi Minh cùng câu đó, bạn nhận được: "Anh ấy bận lắm, để mình xem đã." Đó chính là ranh giới Spotlight.ai vạch ra: champion thật tạo điều kiện tiếp cận, supporter thì xin lỗi vì không làm được. Minh vẫn hữu ích cho quyền truy cập hệ thống, nhưng người bạn cần đầu tư là Hà.

**Điểm mấu chốt:** Đừng đo champion bằng độ nhiệt tình, hãy đo bằng những cánh cửa họ chịu mở cho bạn.

## Champion cần một người đỡ phía trên

Tìm được Hà chưa phải là xong. Các champion triển khai thường cho rằng ban lãnh đạo hỗ trợ rất ít cho việc áp dụng cách làm mới, theo một nghiên cứu của Construction Industry Institute. Một champion đơn độc sẽ kiệt sức, hoặc bị cấp trên gạt đi trong lần cắt giảm đầu tiên.

Phó chủ tịch phụ trách Forward-Deployed Engineering của Salesforce nói rằng muốn có cam kết thật, bạn phải đưa cuộc trao đổi lên đúng cấp. Champion và executive sponsor là hai vai khác nhau: một người kéo từ dưới lên, một người che chắn từ trên xuống. Vì thế yêu cầu đầu tiên bạn nhờ champion nên là gặp được người sponsor đó.

## Đừng để champion biến thành người truyền giáo

Có một rủi ro ngược chiều. Một nghiên cứu tình huống năm 2005 tại hội nghị AMCIS cảnh báo rằng sự dịch chuyển tinh vi từ vai champion sang vai người truyền giáo có thể gây hại cho kết quả kinh doanh, nhất là khi người đó là một executive. Họ tiếp tục bảo vệ một hệ thống đã không còn phù hợp.

Cách phòng là giữ champion trung thực. Hãy đưa cho Hà cả những con số xấu, những ca agent sai, để cô bảo vệ dự án bằng dữ liệu chứ không bằng niềm tin.

Cách bền hơn nữa là nhân một người thành một nhóm. Tryolabs ghi rõ "baseline chỉ số adoption và một nhóm champion nội bộ đã được đào tạo" là sản phẩm bàn giao của giai đoạn adoption. Một nhóm có số liệu bền hơn một cá nhân có nhiệt huyết.

## Những lỗi khiến bạn mất champion

Lỗi phổ biến nhất là nhầm người trả lời nhanh với người có ảnh hưởng, như trường hợp Minh. Lỗi thứ hai là đòi trước khi cho: nhờ champion xin họp với giám đốc ngay tuần đầu, khi bạn chưa giải quyết được việc gì cho họ.

Lỗi thứ ba là để champion một mình gánh dự án mà không có sponsor. Lỗi cuối cùng là bàn giao cho một người duy nhất. Khi người đó chuyển việc, dự án mồ côi.

Khi đọc JD của các vị trí FDE, những cụm như "stakeholder management" hay "drive adoption" thường chỉ đúng kỹ năng này. Hãy chuẩn bị sẵn một câu chuyện cụ thể cho CV và buổi phỏng vấn: bạn nhận ra ai là champion thế nào, phép thử nào xác nhận điều đó, và nhóm champion bạn để lại sau bàn giao làm được gì khi không còn bạn ở đó.

Code của bạn chạy trên server của khách. Còn dự án của bạn sống được hay không lại nằm trong đầu một người bên khách, đúng vào lúc bạn không có mặt trong phòng họp.

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

- Vẽ sơ đồ stakeholder của dự án hiện tại, đánh dấu từng người theo ba tiêu chí: tin vào giải pháp, có ảnh hưởng, tiếp cận được người quyết định.
- Chọn một end-user đang khó chịu nhất với quy trình cũ và sửa giúp họ một việc nhỏ trước khi nhờ vả bất cứ điều gì.
- Với ứng viên champion mạnh nhất, đề nghị họ cùng bạn trình bày số liệu pilot cho người nắm ngân sách, và ghi lại họ phản hồi thế nào.

## Nguồn

- [The Champion Problem: How to Identify a Real Advocate in an Enterprise Deal](https://www.spotlight.ai/post/the-champion-problem-how-to-identify-a-real-advocate-in-an-enterprise-deal)

- [How to identify internal champions to win more deals in B2B](https://www.usergems.com/blog/how-to-identify-internal-champions)

- [How to Identify Internal Champions to Close More Deals in B2B](https://close.com/blog/internal-champion-army)

- [Forward Deployed Engineers | Tryolabs](https://tryolabs.com/services/forward-deployed-engineers)

- [Salesforce+ Scaling Adaptability: Engineering Leaders Build What's Next](https://www.salesforce.com/plus/experience/dreamforce_2025/series/agentforce_at_dreamforce_2025/episode/episode-s1e49)

- [From Salvation to Damnation: A Case Study on the Role of a System Sponsor in Strategic Downfall](https://aisel.aisnet.org/amcis2005/362)

- [The Role of Executive Support in Implementation Champion Success](https://www.construction-institute.org/the-role-of-executive-support-in-implementation-champion-success)