# PostHog tính phí FDE theo mốc bàn giao thay vì theo giờ, và điều kỹ sư nên học từ đó

> Sổ tay công khai của PostHog không giải thích lý do, nhưng quy tắc giá ấy gợi ý khá rõ khách hàng đang trả tiền cho điều gì khi viết code đã rẻ đi.

Bản gốc: https://fdetimes.net/vi/phan-tich/posthog-doi-fde-lam-viec-the-nao/

Sổ tay công khai của PostHog ghi rõ: công việc forward deployed engineering được báo giá theo từng mốc bàn giao, không theo giờ. Cũng trong sổ tay đó có một quy tắc còn cứng hơn: bàn giao nào phình ra gấp đôi phạm vi thì phải làm báo giá mới, không được lặng lẽ kéo dài thêm.

Quyết định này đã lên cả trang /services công khai. Một pull request trên repo posthog.com ghi mức tối thiểu 5 nghìn USD cho mỗi mốc, thay cho dòng cũ gắn phí với khoảng 20% số credit khách mua trong năm đầu. PR mô tả đây là lựa chọn có chủ đích của đội FDE.

PostHog không tự giải thích vì sao. Nhưng ở trang tổng quan, họ viết rằng AI đã giúp con người xây dựng nhanh hơn, nên giá trị đội mang lại là phán đoán, gu và khả năng lập luận.

PostHog không tự nối hai ý ấy với nhau. Nhưng nếu giá trị thật sự nằm ở phán đoán, tính tiền theo giờ khó đứng vững, vì giờ làm việc chỉ đo được khối lượng.

Với một kỹ sư đang làm hoặc muốn làm FDE, đây là mô hình đáng đọc kỹ. Nó cho thấy cách biến phán đoán, thứ vốn khó nhìn thấy, thành những thứ khách hàng ký nhận được: một mốc bàn giao, một báo giá, một chữ ký phê duyệt.

## Vì sao giờ làm việc là thước đo sai?

Trang “How we work” của PostHog nói thẳng: giá trị của một FDE ít nằm ở chuyện họ làm ra được bao nhiêu, mà nhiều hơn ở phán đoán họ đem vào công việc.

Thử hình dung hai FDE cùng nhận một việc. Người thứ nhất viết ba nghìn dòng script trong hai tuần. Người thứ hai bỏ hai ngày đầu hỏi khách hàng, phát hiện hai phần ba số event định chuyển không còn ai dùng, rồi chỉ chuyển phần còn lại trong một tuần.

Tính theo giờ, người thứ nhất kiếm được nhiều hơn. Tính theo mốc bàn giao, người thứ hai thắng, và khách hàng cũng thắng. Cách tính tiền vì thế ép cả đội trả lời câu hỏi “nên làm gì” trước câu hỏi “làm bao nhiêu”.

Lập luận này không chỉ có ở PostHog. IndiaNIC, khi bàn về giá dịch vụ agency nói chung, cho rằng một khi AI rút ngắn số giờ đằng sau một bàn giao, tính tiền theo giờ sẽ phạt người làm nhanh và thưởng người làm chậm.

Phía khách hàng cũng có lý do để ngại. Ghanemzadeh, người viết về giá FDE từ góc độ người hành nghề, mô tả mô hình time-and-materials quen thuộc: công việc không có điểm dừng rõ, và tổng chi phí chỉ lộ ra khi engagement kết thúc.

**Điểm mấu chốt:** Khi viết code đã rẻ, thứ khách hàng trả tiền là phán đoán về việc nên làm gì.

## Một mốc phải hẹp thì giá mới trung thực

Báo giá cố định không phải thuốc chữa mọi thứ. Chính Ghanemzadeh cũng lưu ý rằng giá cố định cho một kết quả cố định chỉ trung thực khi phạm vi đủ hẹp. Đó là lý do đơn vị định giá phải là một mốc bàn giao được định nghĩa rõ, chứ không phải cả một dự án mơ hồ.

Thử hình dung một khách hàng muốn chuyển dữ liệu analytics từ công cụ cũ sang PostHog. Mốc viết yếu sẽ ghi “hỗ trợ migration”. Mốc viết tốt sẽ ghi: event của ba ứng dụng chính chảy vào PostHog, năm dashboard quan trọng nhất khớp số liệu với hệ thống cũ, xong trong khoảng ba tuần.

Câu thứ hai đo được, có giới hạn và kiểm tra được, nên mới báo giá được. Khi khách hàng đọc nó, họ hoặc gật đầu, hoặc nói “thực ra dashboard doanh thu mới là thứ chúng tôi cần”. Câu trả lời nào cũng có ích, vì sai lệch lộ ra trước khi có ai viết dòng code nào.

Sổ tay PostHog còn khuyến khích FDE chia sẻ sớm cả những việc chưa hoàn hảo để đồng nghiệp góp ý về hướng đi. Với một mốc bàn giao, lời khuyên thực tế là đưa bản nháp mô tả mốc cho một đồng nghiệp đọc trước khi gửi khách: phán đoán sai ở bước này đắt hơn mọi bước sau.

## Phạm vi phình ra thì làm gì?

Quay lại ví dụ migration. Giữa tuần thứ hai, khách hàng hỏi thêm: tiện thể đồng bộ luôn dữ liệu sang data warehouse được không? Với nhiều kỹ sư, phản xạ tự nhiên là gật đầu cho vui lòng khách.

Quy tắc của PostHog chặn đúng phản xạ đó: một bàn giao phình gấp đôi phạm vi phải thành một báo giá mới, không được làm thêm cho qua. Quy tắc này bảo vệ cả hai phía. FDE không bị kéo vào một dự án không có điểm dừng, còn khách hàng nhận được một quyết định rõ ràng thay vì một hóa đơn bất ngờ.

Kỹ năng ẩn sau quy tắc này là biết nói “được, nhưng đó là một mốc khác” mà không làm hỏng quan hệ. Bạn có thể luyện nó ngay từ bây giờ, với chính các team nội bộ hay nhờ bạn làm thêm việc.

## “Xong” nghĩa là có người phía khách hàng ký

Theo trang “Working with customers” của PostHog, một mốc chỉ xong khi bàn giao đã được ship và được một người có tên cụ thể phía khách hàng phê duyệt. Không phải “khách có vẻ hài lòng”, không phải “hết giờ”, mà là một con người cụ thể chịu trách nhiệm nói “đạt”.

Trong ví dụ migration, người đó có thể là trưởng nhóm data của khách hàng, người mở năm dashboard và xác nhận số liệu khớp. Điều này buộc bạn xác định ngay từ đầu ai sẽ ký, và họ sẽ kiểm tra bằng tiêu chí nào.

Lời khuyên đi kèm: viết tài liệu sao cho người phê duyệt tự kiểm tra được mà không cần bạn ngồi cạnh. Nếu chỉ FDE hiểu script chạy thế nào, chữ ký đó khó mà có được.

## Thứ ở lại sau mỗi mốc

Một mốc bàn giao có thể khép lại một hóa đơn, nhưng PostHog không muốn bài học khép lại theo. Sổ tay yêu cầu FDE biến những gì xây cho một khách hàng, nếu có ích cho người khác, thành ví dụ, template hoặc cải tiến sản phẩm.

Trang tổng quan nói thêm rằng các khuôn mẫu lặp lại qua nhiều engagement sẽ thành tài sản dùng lại và cải tiến sản phẩm.

DataCamp gọi đúng tên kỹ năng ở đây: product judgment là quyết định phần nào may đo cho một khách hàng, phần nào thuộc về sản phẩm lõi. Chọn sai thì để lại đống code một lần không ai bảo trì nổi. Cũng theo DataCamp, FDE giỏi mang bài học từ hiện trường về cho đội product engineering để nền tảng tốt lên cho mọi người.

Trong ví dụ migration, script viết cho khách hàng thứ nhất, nếu được làm sạch, có thể thành template cho khách hàng thứ mười. Đó cũng là một phán đoán: phần nào đủ chung để đầu tư, phần nào nên để lại như một lần may đo.

| Khía cạnh | Nếu tính theo giờ (kịch bản đối chiếu) | Mô hình FDE của PostHog |
|---|---|---|
| Đơn vị định giá | Số giờ làm việc | Từng mốc bàn giao, có mức tối thiểu |
| Chi phí với khách | Chỉ biết tổng khi engagement kết thúc | Biết trước cho từng mốc |
| Khi AI giúp làm nhanh hơn | Người làm nhanh bị thiệt | Giá gắn với bàn giao, không với số giờ |
| Khi phạm vi phình | Dễ kéo dài thêm giờ | Phình gấp đôi thì báo giá mới |
| Điểm kết thúc | Dễ gắn với lúc hết giờ hoặc hết ngân sách | Đã ship, người có tên phía khách hàng duyệt |
| Thứ để lại | Không có yêu cầu riêng | Ví dụ, template, cải tiến sản phẩm |

Cột giữa là kịch bản suy từ logic tính giờ để đối chiếu, không mô tả một công ty cụ thể nào. Đọc ngang từng dòng, cột bên phải luôn buộc kỹ sư quyết định sớm hơn và công khai hơn. Phán đoán vốn không đo trực tiếp được, nên đây là cách gián tiếp để một tổ chức nhìn thấy nó.

## Mượn chính tín hiệu của PostHog khi đi phỏng vấn và viết CV

Sổ tay PostHog cho bạn sẵn một bộ tín hiệu để đối chiếu: báo giá theo mốc bàn giao, báo giá mới khi phạm vi phình, người có tên phía khách hàng duyệt, và bài học được biến thành tài sản dùng lại. Khi đọc mô tả một vai trò FDE ở bất kỳ đâu, hãy tìm dấu vết của những cơ chế ấy.

Ở buổi phỏng vấn, mượn đúng quy tắc của PostHog để hỏi: khi một bàn giao phình gấp đôi phạm vi, đội làm báo giá mới hay lặng lẽ kéo dài? Hỏi thêm ai phía khách hàng là người ký nghiệm thu, và phần việc nào của bạn sẽ được biến thành template cho engagement sau.

Trong CV, viết theo đúng vòng đời của một mốc. Bạn đã chốt kết quả kiểm tra được nào trước khi làm, đã nói “đó là một mốc khác” lúc nào, ai phía khách hàng đã phê duyệt, và thứ bạn để lại giúp lần sau nhanh hơn ra sao.

Còn nếu bạn đã là FDE, bài tập rẻ nhất là bắt đầu mọi việc bằng nửa trang định nghĩa “xong” và kết thúc bằng một chữ ký phía khách hàng. Khi tốc độ viết code không còn phân biệt được kỹ sư này với kỹ sư khác, hai thói quen đó mới là thứ người ta trả tiền.

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

- Lấy một việc bạn đang làm cho khách hàng hoặc team khác, viết lại thành mô tả nửa trang gồm kết quả kiểm tra được, mốc thời gian sơ bộ và định nghĩa “xong”, rồi gửi người nhận xác nhận.
- Chọn một bàn giao gần đây và xác định ai là người có tên phía nhận đã phê duyệt nó; nếu không có ai, việc đó chưa thật sự xong. Sau đó tách một phần thành template dùng lại được.
- Sửa một gạch đầu dòng trong CV từ dạng “đã xây X” sang dạng “bàn giao X, được [vai trò phía khách hàng] phê duyệt, giúp đạt kết quả Y”.

## Nguồn

- [How forward deployed engineers work - Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work.md)

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

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

- [Rework the /services page around forward deployed engineering by leo-posthog · Pull Request #20649 · PostHog/posthog.com](https://github.com/PostHog/posthog.com/pull/20649)

- [What Is a Forward Deployed Engineer? Role, Skills, and Why It Matters](https://www.datacamp.com/blog/what-is-forward-deployed-engineer)

- [Why Agency Pricing Is Shifting From Hours to Outcomes in the AI Era (IndiaNIC)](https://www.indianic.com/resources/agency-pricing-hours-vs-outcomes-ai-era)

- [Forward Deployed Engineering at $200/Hour](https://ghanemzadeh.substack.com/p/forward-deployed-engineering-at-200hour)