# Khi FDE đổi người giữa dự án: bàn giao niềm tin của khách, không chỉ bàn giao repo

> Code có thể chuyển trong một buổi chiều, nhưng khách hàng chỉ tin người mới khi người đó tự chứng minh được mình, và việc bàn giao phải được thiết kế quanh điều này.

Bản gốc: https://fdetimes.net/vi/bach-khoa/ban-giao-quan-he-khach-hang-khi-fde-doi-nguoi/

Thử hình dung một tình huống. Bạn đang ở tuần thứ sáu của một dự án tích hợp dữ liệu thì công ty điều bạn sang một khách hàng khác. Bạn đẩy code lên, viết một file README dài và gửi lời chào trong kênh Slack chung. Ba tuần sau, người kế nhiệm hỏi khách những câu bạn đã hỏi từ tuần đầu tiên.

Bài viết về runbook bàn giao FDE của Tandem mô tả đúng kiểu thất bại này. Dự án không sụp. Nó chỉ lặng lẽ khởi động lại, trong khi khách vẫn tin mình đã đi được nửa đường. Với khách, cảm giác lúc đó là tiền và thời gian của họ vừa bị tính hai lần.

Bạn không phải lúc nào cũng chọn được thời điểm mình rời một dự án. Vì vậy kỹ năng cần có không phải là tránh việc đổi người, mà là bàn giao sao cho khách không thấy mình bị đẩy lùi về vạch xuất phát. Vế khó nhất của việc này không nằm trong code.

## Vì sao tài liệu dài không cứu được bạn?

Phản xạ đầu tiên của kỹ sư là viết thật nhiều. Nhưng Tandem chỉ ra một điểm yếu: tài liệu bàn giao chỉ là ảnh chụp tại một thời điểm, và khi người viết đã đi thì không ai kiểm chứng được nó nữa. Một tuần sau, nửa số dòng trong đó có thể đã sai mà người mới không biết là nửa nào.

Họ đề xuất làm khác: thứ được bàn giao là một đường dẫn tới bản ghi tài khoản luôn được cập nhật, cộng với một phần delta ngắn. Đường dẫn ở đây trỏ tới bảng ticket, bản ghi tài khoản, repo, tức những nơi vẫn được cập nhật sau khi bạn rời đi. Delta là phần mà chỉ trong đầu bạn mới có.

Handbook của PostHog đặt ra yêu cầu tương tự cho mọi thông tin mà người khác sẽ cần tìm lại. Thông tin phải nằm trong một sản phẩm bàn giao bền vững, đừng để trong tin nhắn Slack riêng hay một thread mà sau này không ai lần lại được. Việc còn phải làm tiếp thì ghi thành task rõ ràng, đừng giấu trong các đoạn văn xuôi.

## Ai thật sự sở hữu mối quan hệ?

Trước khi viết delta, bạn cần biết mình đang bàn giao cái gì. Theo handbook của PostHog, FDE chịu trách nhiệm về kết quả kỹ thuật, còn quan hệ thương mại vẫn thuộc về sales và CS. Khi phần kỹ thuật hoàn tất, FDE trả quan hệ lại cho người phụ trách tài khoản và ghi lại đã xây gì, vì sao xây như thế.

Quy tắc đó nói về lúc kết thúc dự án, nhưng nó gợi ra một điều hữu ích cho cả lúc đổi người giữa chừng: người phụ trách tài khoản vẫn là người giữ quan hệ thương mại suốt quá trình.

Vì thế bàn giao giữa dự án thường có ba bên chứ không phải hai: bạn, người kế nhiệm và người phụ trách tài khoản. Nếu người đó vắng mặt, khách dễ nghe hai phiên bản khác nhau về việc ai đang lo cho họ.

## Một bản delta trông như thế nào?

Quay lại ví dụ giả định. Lan là FDE đang tích hợp hệ thống quản lý kho của một công ty logistics vào sản phẩm của mình. Minh sẽ nhận dự án từ thứ Hai tuần sau. Bản bàn giao của Lan có hai phần.

Phần đường dẫn chỉ có vài dòng: bảng ticket của tài khoản, bản ghi tài khoản trong CRM do CS quản lý, repo và trang ghi lại các quyết định kỹ thuật. Lan không chép lại nội dung của những chỗ đó, vì chép lại tức là tạo thêm một ảnh chụp sẽ sớm lỗi thời.

Phần delta theo đúng gợi ý của Rocketlane cho bàn giao giữa các CSM: ghi cam kết, vướng mắc và rủi ro. Cuối cùng là task.

| Mục | Ví dụ trong delta của Lan |
|---|---|
| Cam kết đã hứa | Đã hứa với trưởng nhóm vận hành sẽ có bản đồng bộ tồn kho chạy thử trước cuối tháng |
| Vướng mắc | Bên IT của khách chưa cấp quyền đọc bảng đơn trả hàng, người cần nhắc là quản trị viên hệ thống |
| Rủi ro | Trưởng nhóm vận hành từng bị một nhà cung cấp cũ trễ hạn nên rất nhạy cảm với việc lùi lịch |
| Task tiếp theo | Ba ticket đã tạo, mỗi ticket có người nhận và ngày hạn |

Dòng "rủi ro" quan trọng nhất trong bảng. Code không bao giờ cho Minh biết rằng người dùng chính rất sợ bị trễ hạn, nhưng chính chi tiết đó quyết định Minh nên mở lời thế nào trong cuộc gọi đầu tiên.

## Cuộc gọi mà người mới phải cầm lái

Tài liệu chỉ chuyển được thông tin. Bài của Tandem viết rằng quan hệ được chuyển giao bằng niềm tin tự kiếm được, chứ không bằng runbook. Vì thế họ khuyên giới thiệu người kế nhiệm qua đúng một cuộc gọi, trong đó người nhận dẫn dắt còn người rời đi chỉ quan sát.

Thoạt nghe thì ngược đời, vì người cũ mới là người khách quen. Nhưng nếu Lan nói suốt cuộc gọi, khách sẽ tiếp tục coi Lan là đầu mối và nhắn riêng cho Lan sau đó. Khi Minh tự nhắc lại đúng cam kết cuối tháng, khách thấy người mới đã nắm việc. Niềm tin bắt đầu được xây từ khoảnh khắc đó.

Một kịch bản mở đầu cho Minh có thể như sau:

> **Lan:** "Từ tuần sau Minh sẽ phụ trách phần tích hợp.

Mình chuyển sang dự án khác, còn chị Hà bên CS vẫn là đầu mối về hợp đồng như trước."
>
> **Minh:** "Em đã đọc lại toàn bộ ticket.
>
> Theo em hiểu thì mục tiêu là bản đồng bộ tồn kho chạy thử trước cuối tháng, và đang vướng quyền đọc bảng đơn trả hàng.

Anh chị xem em hiểu vậy có đúng không ạ?"

Câu của Lan làm đúng điều Rocketlane khuyên: báo cho khách lý do có thay đổi. Còn câu hỏi xác nhận của Minh thì biến delta thành thứ khách được kiểm chứng tại chỗ, đúng chỗ mà tài liệu một mình không làm được.

## Các bước tự làm

Bắt đầu bằng việc báo cho khách sớm. ClientSuccess khuyên giới thiệu người mới càng sớm càng tốt để đỡ nhầm lẫn về sau, vì cách bàn giao sẽ định hình cả quan hệ lâu dài. Một tuần báo trước tốt hơn một email gửi vào ngày cuối.

Tiếp theo, người rời đi tự viết delta. Rocketlane nhấn mạnh tài liệu phải do chính người bàn giao chuẩn bị. Sau đó dọn Slack DM và chuyển mọi lời hứa sang ticket. Rồi tổ chức cuộc gọi ba bên với người mới cầm lái. Cuối cùng, xác nhận với người phụ trách tài khoản rằng họ biết ai đang lo phần kỹ thuật.

**Điểm mấu chốt:** Tài liệu chuyển được thông tin, nhưng niềm tin thì người mới phải tự kiếm lấy trước mặt khách.

## Những lỗi hay gặp

Lỗi phổ biến nhất là coi việc bàn giao xong khi code đã merge. Kế đến là người cũ ôm cuộc gọi giới thiệu vì ngại im lặng, khiến người mới trông như trợ lý. Khó thấy hơn cả là khi người cũ vẫn trả lời tin nhắn riêng của khách sau khi đã chuyển đi, nên quan hệ không bao giờ thật sự đổi chủ.

Còn một lỗi nữa là bỏ quên người phụ trách tài khoản. FDE dễ coi bàn giao là chuyện giữa hai kỹ sư với nhau, trong khi người giữ quan hệ thương mại cần biết đầu tiên.

## Kỹ năng này thể hiện thế nào trong hồ sơ?

Nên chuẩn bị sẵn một câu chuyện cụ thể phòng khi vòng phỏng vấn hỏi bạn từng rời một khách hàng giữa chừng ra sao: bạn đã viết delta thế nào, ai dẫn cuộc gọi, và dự án có giữ được lịch không.

Trong CV, một dòng như "bàn giao tài khoản giữa dự án cho người kế nhiệm mà không lùi mốc đã cam kết" cho thấy bạn hiểu phần việc ít ai dạy.

Khi đọc mô tả công việc, để ý những cụm như "ownership", "handover" hay "làm việc cùng CS". Những cụm đó gợi ý công ty có tách bạch việc kỹ thuật với quan hệ thương mại hay không. Bạn nên hỏi thẳng chuyện này ở vòng phỏng vấn.

Một dự án được bàn giao tốt thì khách gần như không nhận ra có đổi người. Họ chỉ thấy mốc cuối tháng vẫn còn nguyên.

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

- Chọn một dự án bạn đang làm và viết thử delta bàn giao theo bốn mục: cam kết đã hứa, vướng mắc, rủi ro, task tiếp theo. Mỗi mục tối đa năm dòng.
- Rà lại Slack DM của bạn với khách trong hai tuần gần nhất, rồi chuyển mọi quyết định hay lời hứa nằm trong đó sang ticket hoặc bản ghi tài khoản.
- Tập kịch bản mở đầu cuộc gọi giới thiệu với một đồng nghiệp: bạn đóng vai người nhận và nói trước trong năm phút đầu.

## Nguồn

- [FDE handoffs: keeping an engagement alive when the builder changes](https://usetandem.ai/blog/fde-handoff-runbook)

- [Working with customers - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/working-with-customers)

- [Working with sales and CS - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/working-with-sales-and-cs)

- [Transitioning clients between CSMs](https://www.rocketlane.com/blogs/transitioning-clients-between-csms)

- [How Customer Success Teams Should Navigate the Complexities of Customer Handoffs](https://clientsuccess.com/blog/customer-success-teams-navigate-complexities-customer-handoffs/)