# Họp rà soát cuối dự án: cách FDE xếp mọi việc còn dang dở vào ba giỏ

> Buổi họp cuối mà chỉ chốt được câu "mọi thứ ổn" thì khách hàng tiếp theo sẽ vấp lại đúng lỗi cũ.

Bản gốc: https://fdetimes.net/vi/bach-khoa/retrospective-cuoi-engagement-voi-khach-hang-fde/

Tuần cuối của một deployment luôn kín lịch: bàn giao tài khoản, thu hồi quyền truy cập, gửi tài liệu. Buổi rà soát cuối dự án thường bị dồn vào nửa tiếng cuối cùng và kết thúc bằng một câu "mọi thứ ổn". Vài tháng sau, khách hàng tiếp theo vấp đúng chỗ cũ, và không ai nhớ lần trước đã xử lý thế nào.

Sổ tay nội bộ (handbook) của PostHog mô tả FDE là những người gặp các chỗ chưa ổn của sản phẩm dưới tải thật của khách trước bất kỳ ai khác. Họ cũng nói rõ rằng bối cảnh lấy từ hiện trường giúp sửa lỗi nhanh hơn cho những khách đến sau.

Vậy nên buổi họp cuối không phải thủ tục. Đó là lần duy nhất bạn chắc chắn có đủ người trong phòng để biến những va chạm ấy thành việc có người phụ trách, trước khi bạn chuyển sang dự án khác và kiến thức đi theo bạn.

## Mọi mục đều phải vào một trong ba giỏ

Mọi thứ còn dang dở khi dự án đóng lại đều thuộc đúng một trong ba giỏ. **Bài học** là điều thay đổi cách bạn làm lần sau. **Nợ còn lại** là việc khách hoặc đội bạn còn phải làm, có người phụ trách và có hạn. **Việc giao cho đội product** là vấn đề chỉ đội product mới sửa được.

Trước khi xếp giỏ, hãy lọc ra một loại mục không thuộc về buổi họp kỹ thuật này: yêu cầu thương mại, như khách muốn thêm phần việc mới. Ở PostHog, quan hệ thương mại với khách thuộc về TAE, TAM hoặc CSM của khách đó, không thuộc về FDE. Nói rõ điều này ngay đầu buổi họp, ghi các yêu cầu đó lại rồi chuyển thẳng cho họ.

Với những mục còn lại, câu hỏi để phân loại là: nếu khách hàng tiếp theo gặp lại chuyện này, ai sẽ phải sửa? Nếu câu trả lời là đội sở hữu tính năng đó, PostHog có quy tắc rõ ràng. Khi một engagement bị chặn bởi thứ chỉ đội product sửa được, FDE giao việc cho đội đó chứ không vá lách quanh nó.

Quy tắc này là để chống lại một rủi ro cụ thể. Tandem tóm tắt lời phê bình của Marty Cagan về mô hình FDE: nguy cơ là trôi dần thành làm phần mềm may đo riêng cho từng khách. Mô hình chỉ hiệu quả khi những gì học được ở hiện trường quay về sản phẩm chung, thay vì đọng lại thành code viết riêng.

Dù mục nào rơi vào giỏ nào, cả buổi họp cần chung một điều kiện: không đổ lỗi. Chương về văn hóa postmortem trong sách SRE của Google viết rằng bạn không "sửa" được con người, nhưng sửa được hệ thống và quy trình.

Khách hàng cũng phải có mặt: một hướng dẫn về đóng engagement nhấn mạnh rằng buổi rút bài học diễn ra cùng khách, không phải buổi retro riêng của đội bạn.

## Thử hình dung một deployment analytics

Hãy hình dung bạn vừa xong một deployment theo dõi event cho một ứng dụng thương mại điện tử. Trước buổi họp, bạn gom ticket, tin nhắn và ghi chú lại thành một danh sách thô gồm sáu mục. Bảng dưới đây là cách xếp chúng vào giỏ, kèm một mục bị lọc ra trước khi xếp.

| Mục | Giỏ | Người phụ trách | Bước tiếp |
|---|---|---|---|
| Job đồng bộ sang data warehouse chậm vì chạy cùng giờ cao điểm của khách | Nợ còn lại | Data engineer phía khách | Dời lịch job, có hạn chót |
| SDK mất event khi người dùng offline lâu | Giao cho đội product | Đội sở hữu SDK | Mở issue đủ bốn ý |
| Đoạn code tạm lách qua lỗi SDK ở trên | Nợ còn lại | FDE | Gắn link vào issue, ghi ngày gỡ bỏ |
| Script đổi tên event cũ sang tên mới | Bài học, thành công cụ | FDE | Đưa vào repo nội bộ thành mẫu dùng lại |
| Mất nhiều ngày chờ cấp quyền truy cập | Bài học | Đội FDE | Xin quyền ngay từ buổi kickoff |
| Khách muốn thêm dashboard tùy biến | Lọc ra trước: yêu cầu thương mại | CSM hoặc TAM | Chuyển cho người giữ quan hệ thương mại |

Hãy nhìn kỹ ba dòng trong bảng. Đoạn code lách lỗi không bị giấu đi: nó được ghi thành nợ và gắn vào issue product, để khi đội SDK sửa xong thì có người nhớ gỡ nó ra.

Script đổi tên event trở thành tài sản. PostHog coi việc xây reference implementation, ví dụ và công cụ nội bộ giúp các engagement sau nhanh hơn là một phần công việc của FDE.

Dòng cuối là mục bị lọc ra từ đầu. Khi khách mở lời về phần việc mới trong buổi rà soát, câu trả lời đúng là ghi lại rồi chuyển cho người giữ quan hệ thương mại, chứ không hứa ngay tại bàn.

Với mục giao cho đội product, PostHog yêu cầu báo cho đúng đội sở hữu và mở issue nêu rõ cái gì hỏng, ai gặp, nó chặn việc gì và cách tái hiện. Một mẫu bạn có thể chép dùng ngay:

```markdown
Tiêu đề: SDK mất event khi thiết bị offline lâu

Cái gì hỏng: event ghi lúc offline không được gửi lên sau khi có mạng lại
Ai gặp: khách thương mại điện tử, ứng dụng mobile, người dùng ở vùng sóng yếu
Chặn việc gì: báo cáo funnel thanh toán thiếu dữ liệu, khách chưa tin số liệu
Cách tái hiện: bật chế độ máy bay, thao tác vài màn hình, chờ lâu, bật mạng, kiểm tra event
Workaround hiện tại: đoạn code lách lỗi trong repo của khách (link), cần gỡ sau khi sửa
```

## Chạy buổi họp từng bước

Trước buổi họp, gửi bảng nháp cho khách để họ bổ sung. Không ai muốn nghe danh sách lỗi lần đầu ngay giữa cuộc họp. Trong buổi họp, đi qua từng mục, chốt giỏ, rồi chốt người phụ trách bằng tên người cụ thể, không ghi "đội bên kia".

Bước khó nhất là ưu tiên. Sách SRE của Google đặt một câu hỏi cho mọi buổi rà soát: kế hoạch hành động có hợp lý không, và các lỗi cần sửa có được xếp đúng mức ưu tiên không. Một issue product được đánh dấu "thấp" trong khi nó chặn báo cáo chính của khách nghĩa là buổi họp đã thất bại một nửa.

**Điểm mấu chốt:** Một bài học không có ai đọc lại cũng như chưa từng được rút ra.

Sau buổi họp, lưu kết quả vào kho chung. Google khuyên đặt postmortem ở nơi tập trung để người khác tìm thấy và học theo, và nói thẳng rằng postmortem không được rà soát thì coi như chưa từng tồn tại. Hướng dẫn đóng engagement nói tương tự: lưu ở nơi đội sẽ tìm thấy vào lần sau.

Việc cuối cùng: cùng hướng dẫn đó nhắc rằng đóng dự án không chỉ là gửi hóa đơn, và mối quan hệ với khách cần được bàn giao có chủ đích dù engagement đã khép lại. Hãy giới thiệu khách với người sẽ tiếp tục phụ trách họ, ngay trong email tổng kết.

## Những lỗi khiến buổi họp vô ích

Lỗi phổ biến nhất là biến buổi họp thành phiên xét xử, kiểu "ai làm chậm quyền truy cập". Khi đó khách sẽ giữ im lặng, và bạn mất đúng những chuyện đáng học nhất. Lỗi thứ hai là chỉ họp nội bộ, không mời khách, nên giỏ "nợ còn lại" không có người phía khách nhận việc.

Lỗi thứ ba khó thấy hơn: âm thầm vá lách quanh lỗi sản phẩm vì như thế nhanh hơn mở issue. Mỗi đoạn vá như vậy là một mẩu code may đo đúng theo kiểu Cagan cảnh báo.

PostHog viết rằng mục đích của việc đưa vấn đề của khách về là để roadmap tốt hơn. Đoạn vá chỉ nằm trong repo của khách thì không cải thiện được roadmap nào.

Lỗi cuối cùng là issue mơ hồ, chỉ có một dòng "SDK có lỗi offline". Đội product không tái hiện được thì sẽ không xếp lịch sửa. Bốn ý trong mẫu ở trên chính là thứ biến chuyện bạn chứng kiến ở hiện trường thành việc đội khác làm được.

Kỹ năng này cũng nên có trong CV của bạn. PostHog mô tả việc đưa bài học về sản phẩm và xây công cụ dùng lại là một phần của vai trò FDE, nên đó là thứ đáng thể hiện thay vì chỉ ghi "triển khai cho khách X".

Hãy viết rõ bạn đã mở bao nhiêu issue cho đội product, issue nào đã được sửa, và công cụ nào bạn tạo ra đang được các dự án sau dùng lại. Khi đọc mô tả công việc, hãy để ý xem có nhắc đến feedback loop với đội product hay không: đó là một dấu hiệu cho thấy công ty có coi trọng việc này.

## Bài tập: bạn xếp sáu mục này thế nào?

Thử hình dung bạn vừa đóng một deployment agent trả lời khách hàng. Danh sách thô có sáu mục. Một: API của sản phẩm timeout khi nạp tài liệu lớn. Hai: đoạn code chia nhỏ file để lách lỗi đó. Ba: đội IT của khách chưa tắt các tài khoản thử nghiệm.

Bốn: bộ eval bạn viết để chấm câu trả lời của agent. Năm: dự án mất hai tuần vì không ai biết người nào bên khách duyệt dữ liệu. Sáu: khách hỏi giá để mở rộng sang thêm phòng ban. Hãy tự xếp trước, rồi mới đọc đáp án bên dưới.

Đáp án: mục sáu bị lọc ra trước và chuyển cho CSM hoặc TAM. Mục một giao cho đội product, kèm issue đủ bốn ý. Mục hai là nợ của FDE, gắn link vào issue đó. Mục ba là nợ của người cụ thể phía khách, có hạn chót.

Mục bốn là bài học thành công cụ, đưa vào repo nội bộ. Mục năm là bài học: lần sau hỏi tên người duyệt dữ liệu ngay từ kickoff. Nếu bạn xếp sai mục hai, hãy đọc lại vì sao đoạn vá không được giấu đi.

Dự án thực sự đóng lại khi khách hàng tiếp theo không phải trả lại cái giá mà khách này đã trả.

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

- Mở lại dự án gần nhất bạn đã làm, liệt kê mọi workaround và ticket còn mở, rồi xếp từng mục vào ba giỏ.
- Chọn một lỗi sản phẩm bạn từng phải lách qua và viết lại thành issue đủ bốn ý theo mẫu, gửi cho đội phụ trách phần đó.
- Thêm vào CV một dòng mô tả cụ thể việc bạn đã đưa bài học từ khách về đội product hoặc thành công cụ dùng lại được.

## Nguồn

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

- [Forward deployed engineering overview - Handbook](https://posthog.com/handbook/forward-deployed-engineering/overview)

- [How FDE teams work with product and engineering (without broken telephone) | Tandem](https://usetandem.ai/blog/fde-product-engineering-feedback-loop)

- [Chapter 15 - Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/)

- [Engagement Closeout & Post-Implementation Review](https://ferdinebi.github.io/software-engineering-with-ai/maintenance-retainer/engagement-closeout/)