# Trao bàn phím trước khi rút: cách FDE dạy kỹ sư của khách tự vận hành hệ thống

> Runbook ghi được lệnh cần gõ, còn việc biết phải làm gì trong sự cố đầu tiên sau ngày bạn rời đi thì kỹ sư của khách phải tự luyện khi bạn còn ngồi cạnh.

Bản gốc: https://fdetimes.net/vi/bach-khoa/pair-programming-voi-ky-su-cua-khach-chuyen-giao-nang-luc/

Thử hình dung thứ Sáu này là ngày cuối của bạn ở khách hàng. Pipeline đang chạy, runbook đã viết, buổi demo được khen. Sáu tuần sau, một nhà cung cấp đổi tên cột trong file dữ liệu, pipeline hỏng, và người đầu tiên khách nhắn tin là bạn.

Trên giấy, kịch bản đó vẫn là một lần giao hàng thành công. Thực tế thì khách đã mua một hệ thống mà họ không nuôi nổi.

Ertas AI, khi mô tả cách làm forward deployment, viết rằng mục tiêu không chỉ là dựng pipeline mà còn là chuyển giao kiến thức cần để bảo trì nó, và mức chuyển giao ấy đòi hỏi làm việc cạnh nhau chứ không phải giao tài liệu.

Với bạn, đây là một kỹ năng có thể luyện, và nó quyết định khách có cần gọi lại bạn cho từng lỗi nhỏ hay không. Phần dưới là một kế hoạch bốn tuần, một đoạn hội thoại khi pair và cách đo xem khách đã tự lập chưa.

## Runbook ghi được lệnh, không ghi được phán đoán

Quay lại file bị đổi tên cột. Runbook có thể ghi chính xác schema đầu vào, lệnh chạy lại job và nơi xin quyền truy cập. Đó là sự kiện, nên viết ra, và viết ngay từ đầu engagement.

Nhưng runbook khó trả lời câu hỏi lúc alert kêu giữa đêm: lỗi này có chờ được đến sáng không, chạy lại job có ích gì hay chỉ khiến lỗi lặp lại? Phần phán đoán ấy chỉ hình thành khi kỹ sư của khách tự tay xử lý.

Tandem, một nhà cung cấp viết về bàn giao giữa các FDE, cũng cho rằng phán đoán không truyền qua tài liệu mà được xây lại qua những lần thực hành; đây là quan điểm, chưa phải số đo.

Riêng phần sự kiện thì không được để đến cuối mới ghi. Cũng theo Tandem, khi đổi người dựng hệ thống, ký ức của engagement ra đi cùng người cũ, trừ khi nó đã được lưu ở nơi khác ngay từ đầu.

Trước khi coi một tài liệu là đã bàn giao, hãy áp phép thử mà Len Holgate đưa ra từ năm 2004 khi viết về bàn giao trong tư vấn: nó chỉ có giá trị nếu khách bảo trì được và thu được giá trị từ nó.

Ông cho rằng pair programming và sở hữu code chung giúp code trở thành trách nhiệm của cả đội, nên việc ngồi chung màn hình phục vụ luôn cho phép thử này.

## Code giỏi chưa chắc đã dạy giỏi

Thử hình dung kỹ sư của khách đang bí trước một dòng log, còn bạn thấy lỗi trong mười giây. Khách đang trả tiền cho thời gian của bạn, nên phản xạ tự nhiên là với lấy bàn phím. Ngay lúc đó, người sửa lỗi nhanh nhất phòng lại là người chuyển giao tệ.

Phản xạ ấy không tự mất đi khi bạn code giỏi hơn. Một nghiên cứu về lập trình cặp trình bày tại Software Engineering und Software Management 2018 kết luận rằng kỹ năng chuyển giao kiến thức không tự xuất hiện từ kỹ năng phát triển phần mềm tốt, nhưng nhiều khả năng học được.

Muốn buổi pair hiệu quả, theo nghiên cứu này, chuyên gia vẫn phải chuyển giao kiến thức.

Vì thế, hãy luyện nó như luyện debug. Có ba thói quen nên tập: nói to lý do trước khi gõ, hỏi trước khi trả lời, và giữ tay khỏi bàn phím khi người kia đang bí. Thói quen cuối khó nhất, chính vì mười giây nói trên.

**Điểm mấu chốt:** Bàn giao xong là khi khách tự sửa được hệ thống mà không cần gọi cho bạn.

## Bốn tuần với một pipeline hóa đơn

Lấy một tình huống giả định: bạn dựng pipeline đọc file hóa đơn từ các nhà cung cấp, và An, kỹ sư của khách, sẽ tiếp quản.

Hướng dẫn bàn giao của GitScrum gợi ý 2-4 tuần chồng lấn giữa hai đội, kết hợp tài liệu và các buổi pair, với đội nhận dẫn dắt ở chặng cuối còn đội rời đi chỉ tư vấn.

Đó là mức tham khảo chứ không phải chuẩn; An chưa từng đụng vào hệ thống này nên bạn chọn mức dài nhất. Trong ví dụ này, đó là bốn tuần chót trước ngày bạn rút, còn phần chuẩn bị đã chạy từ đầu engagement: tên người tiếp quản đã chốt, các quyết định đã nằm trong repo chung.

| Tuần chồng lấn | Ai cầm bàn phím | Việc của bạn | Bằng chứng để đi tiếp |
|---|---|---|---|
| 1 | Bạn, An hỏi và ghi runbook | Nói to lý do của từng quyết định | An giải thích lại luồng dữ liệu bằng lời của mình |
| 2 | An, bạn dẫn | Hỏi thay vì đọc lệnh | An tự sửa một lỗi thật và mở PR |
| 3 | An và đồng đội, An dẫn | Chỉ tư vấn khi được hỏi | Đội của An tự xử lý alert |
| 4 | Đội của khách | Giám sát buổi chạy thử, ghi chép | Đội chạy từ đầu đến cuối và xử lý được lỗi chưa từng gặp |

Tuần 2 là lúc kế hoạch dễ vỡ nhất. Giả sử job lỗi lúc An đang cầm bàn phím, và bạn đã đoán ra nguyên nhân từ dòng log đầu tiên. Đoạn hội thoại nên diễn ra thế này:

```text
An:  Job fail rồi, em restart lại nhé?
Bạn: Trước khi restart, em đoán nó hỏng ở bước nào?
An:  Bước parse. Log báo thiếu cột tax_code.
Bạn: Nếu restart, lần chạy sau khác gì lần này?
An:  Không khác gì, file vẫn vậy. Phải xem file từ đâu ra.
Bạn: Em mở file đi, bàn phím vẫn ở chỗ em.
An:  Nhà cung cấp đổi tên cột. Em thêm mapping và một test cho file này.
Bạn: Ghi vào runbook: triệu chứng, cách kiểm tra, cách sửa. Viết bằng lời của em.
```

Nếu bạn nói thẳng "thêm mapping đi", lỗi được sửa nhanh hơn, nhưng An chỉ học được rằng gặp lỗi thì hỏi bạn. Sau đoạn trên, An đã tự suy luận từ đầu đến cuối, và dòng runbook được viết theo cách nghĩ của chính người sẽ phải mở nó ra khi có sự cố.

## Đếm số lần bạn phải lên tiếng

Cảm giác "An có vẻ nắm rồi" không đủ để rút. Hãy giữ một sổ can thiệp đơn giản: mỗi lần bạn phải chỉ hướng hoặc cầm lại bàn phím, ghi một dòng gồm ngày, tình huống và loại can thiệp.

Giả sử sổ tuần 2 có 14 dòng, trong đó 9 dòng xoay quanh việc có nên chạy lại job hay không. Con số 14 chưa nói nhiều, nhưng con số 9 cho bạn biết tuần 3 phải dạy gì.

Tuần 3 còn 5 dòng; trong buổi chạy thử chỉ còn 1 dòng, là không biết xin quyền truy cập ở đâu. Dòng cuối là khoảng trống về sự kiện, nên bạn bổ sung runbook; nếu nó là khoảng trống về phán đoán, bạn cần thêm một vòng thực hành.

Buổi chạy thử ấy là cửa ải cuối. Ertas ghi thẳng một tiêu chí thành công là đội được khách chỉ định có thể tự vận hành pipeline, và kiểm tra bằng một lần chạy thử có giám sát.

Để buổi thử có giá trị, đừng chỉ chạy luồng suôn sẻ: hãy cố ý gài trên môi trường staging một lỗi đội chưa từng gặp, ví dụ một file hóa đơn bị gửi trùng, rồi xem họ lần ra nguyên nhân thế nào.

## Việc bàn giao bắt đầu từ ngày chốt phạm vi

Khi thống nhất phạm vi, hãy đưa tiêu chí tự vận hành vào kế hoạch và xin tên cụ thể của những người sẽ tiếp quản, kèm thời gian họ thật sự có. Sau đó lưu quyết định, giả định và lý do vào repo chung ngay khi chúng phát sinh, để ký ức của engagement vẫn còn đó sau khi bạn rời đi.

Đến giai đoạn giữa, hãy giữ lại các sự cố thật cho kỹ sư của khách thay vì lặng lẽ sửa lúc họ vắng mặt. Mỗi tuần đọc lại sổ can thiệp và quyết định dạy gì tiếp. Chỉ bước sang chặng khách dẫn khi bằng chứng của chặng trước đã có.

## Bốn cách làm hỏng một lần bàn giao

Sửa lỗi kiểu anh hùng là cái bẫy dễ mắc nhất. Thử hình dung bạn vá xong trong đêm, sáng hôm sau khách vui, nhưng cơ hội học của An đã mất. Để việc chuyển giao dồn vào những ngày cuối cũng hỏng không kém, vì đội khách chỉ còn kịp nghe thuyết trình chứ không kịp làm.

Dạy đúng một người là rủi ro âm thầm hơn. Nếu An nghỉ việc, khách quay về điểm xuất phát, nên hãy luân phiên để ít nhất hai người từng tự xử lý sự cố, đúng tinh thần sở hữu code chung mà Holgate nhắc đến.

Cái bẫy còn lại là lấy buổi demo làm bằng chứng bàn giao. Demo chỉ chứng minh hệ thống chạy được, chưa chứng minh khách nuôi được nó.

## Biến nó thành bằng chứng trong hồ sơ của bạn

Kỹ năng này khó thấy trên CV nếu bạn chỉ viết "bàn giao hệ thống". Hãy nêu ai đã tiếp quản, họ đã tự xử lý việc gì, và thước đo nào cho thấy điều đó; sổ can thiệp cho bạn số thật để viết, kể cả khi nó không đẹp như ví dụ trên.

Khi đọc JD FDE, hãy để ý họ có nhắc đến knowledge transfer hay enablement không, và khi phỏng vấn thì hỏi khách của họ thường tự vận hành sau bao lâu. Câu trả lời cho bạn biết công ty đo thành công bằng năng lực để lại, hay chỉ bằng lần ship.

## Bài tập cho tuần này

Chọn một đồng nghiệp ít quen với một phần code của bạn, rồi pair 60 phút để họ sửa một lỗi thật. Bạn không chạm bàn phím, và mỗi lần buột miệng đưa đáp án thay vì đặt câu hỏi, hãy ghi một dòng vào sổ.

Cuối buổi, nhờ họ tự viết mục runbook cho lỗi đó, rồi đọc xem còn thiếu gì. Lần đầu bạn sẽ thấy khó chịu vì mọi thứ chậm hẳn đi. Sự chậm đó nên diễn ra khi bạn còn ngồi cạnh họ, vì sau ngày bạn rút, đội của khách sẽ phải tự xoay xở một mình.

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

- Mở hệ thống bạn đang phụ trách và viết ra năm quyết định bạn vẫn làm theo kinh nghiệm mà chưa tài liệu nào ghi lại.
- Hỏi khách hoặc quản lý một câu: tên người nào sẽ vận hành hệ thống này sau khi bạn rút, và lịch của họ đã có chỗ cho việc đó chưa?
- Thêm vào CV một dòng về một lần bàn giao, ghi rõ ai đã tiếp quản và bằng chứng nào cho thấy họ tự chạy được.

## Nguồn

- [Forward Deployment for Enterprise AI: What It Is and How to Build a Practice](https://www.ertas.ai/blog/forward-deployment-enterprise-ai-data-prep)

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

- [How hand overs become hand offs](https://lenholgate.com/blog/2004/09/how-hand-overs-become-hand-offs.html)

- [On knowledge transfer skill in pair programming (Software Engineering und Software Management 2018)](https://dl.gi.de/items/93104327-a47c-4d39-8b03-5f1f0f6f6b18/full)

- [Project Handoff Best Practices (GitScrum Docs)](https://docs.gitscrum.com/en/best-practices/project-handoff-best-practices)