Một deployment, bốn kiểu người nghe: FDE làm việc với kỹ thuật, nghiệp vụ và lãnh đạo khách hàng thế nào

Thử hình dung một ngày thứ Ba của bạn. Chín giờ sáng, bạn ngồi với CTO của khách hàng để xem API của hệ thống ERP. Giờ trưa, CFO hỏi bạn hệ thống này giúp công ty tiết kiệm được gì. Bốn giờ chiều, một nhân viên kế toán thú nhận là cả tuần nay cô chưa mở công cụ lần nào.

Kịch bản này không hề phóng đại. Stilla viết trong tin tuyển Founding FDE của họ rằng bạn có thể có buổi làm việc với CTO vào buổi sáng, rồi trình bày business case cho CFO ngay bữa trưa.

Palantir cũng mô tả vai trò Forward Deployed Software Engineer là người giữ quan hệ với mọi stakeholder, từ người dùng đang vật lộn với việc hằng ngày đến lãnh đạo ra quyết định.

Với một developer quen nhận ticket từ một product manager duy nhất, đây là cú sốc lớn nhất khi chuyển sang FDE. Không còn ai đứng giữa để dịch hộ bạn. Kỹ năng bạn cần học ở đây chính là việc dịch đó: một vấn đề kỹ thuật, nhiều người nghe, mỗi người cần một câu trả lời khác.

Mỗi nhóm thật ra đang hỏi một câu khác

Bước đầu tiên là thôi coi “khách hàng” là một người. Khách hàng của một FDE thường gồm ít nhất bốn vai, và mỗi vai mang một câu hỏi riêng vào phòng họp.

Đội kỹ thuật, tức CTO hoặc các trưởng nhóm engineering, hỏi hệ thống có chạy ổn trong hạ tầng của họ không. MongoDB gọi vai trò Staff FDE là “đối tác kỹ thuật đáng tin cậy” của các lãnh đạo engineering phía khách hàng. Nghĩa là bạn phải nói chuyện với họ như đồng nghiệp ngang hàng, chứ không phải như người đi bán hàng.

Đội nghiệp vụ, những người làm chủ quy trình, hỏi công cụ này thay đổi công việc hằng ngày của họ ra sao. Lãnh đạo hỏi nó đáng giá đến đâu. Còn người dùng tuyến đầu hỏi một câu đơn giản nhất mà cũng khó trả lời nhất: đổi cách làm thì họ được lợi gì.

Paraform định nghĩa stakeholder management đúng ở chỗ giằng co này: xây quan hệ với lãnh đạo nhưng vẫn giữ đội tuyến đầu đi cùng hướng. Bỏ một đầu thì deployment hỏng ở đầu đó.

Câu này không phải khẩu hiệu. Theo một bài tổng hợp về lịch sử nghề FDE, Palantir ghép cặp người lo kỹ thuật với người lo phía khách hàng chính vì hai mục tiêu đó.

Ví dụ: một trade-off, ba cách trình bày

Thử hình dung bạn deploy một agent đọc hóa đơn nhà cung cấp cho phòng kế toán của một chuỗi bán lẻ. Có một quyết định kỹ thuật phải chốt: agent được tự duyệt hóa đơn khi độ tin cậy vượt một ngưỡng, hay mọi hóa đơn đều phải qua người duyệt.

Ngưỡng cao thì ít sai, nhưng nhiều hóa đơn bị đẩy về cho người làm tay. Ngưỡng thấp thì tự động hóa được nhiều hơn, nhưng rủi ro thanh toán sai tăng lên. Bài toán chỉ có vậy, nhưng mỗi người nghe cần nghe nó theo một cách khác:

Người nghe	Câu họ thật sự hỏi	Cách FDE trình bày
CTO, trưởng nhóm kỹ thuật	Có kiểm soát và truy vết được không?	Precision ở từng ngưỡng trên bộ hóa đơn thật, cách ghi audit log, cách rollback khi agent duyệt sai
Kế toán trưởng (chủ quy trình)	Đội kế toán còn phải xem tay bao nhiêu? Sai thì ai chịu?	Mỗi ngày đội còn xem bao nhiêu hóa đơn, các hóa đơn “nghi ngờ” hiện ra thế nào, ai bấm duyệt cuối
CFO	Có đáng bỏ công không?	Một thước đo đã thống nhất từ trước, ví dụ số ngày đóng sổ cuối tháng, cùng mức rủi ro chấp nhận được

Để ý là bạn không bóp méo sự thật cho ai cả. Cả ba người cùng nhận một trade-off, chỉ khác ở đơn vị đo. Bài viết về lịch sử nghề FDE nói FDE phải kiên nhẫn giải thích trade-off kỹ thuật cho người không làm kỹ thuật. Chữ “kiên nhẫn” quan trọng ở đây, vì thường bạn sẽ phải giải thích đến lần thứ ba.

Để ba cuộc nói chuyện không mỗi cái một hướng, hãy gom chúng vào một tài liệu duy nhất. Bản định nghĩa thành công dài một trang có thể trông như sau:

Vấn đề: Đóng sổ cuối tháng chậm vì nhập và đối chiếu hóa đơn thủ công
Quy trình hiện tại: (do chính nhân viên kế toán mô tả, không phải do quản lý kể lại)
Thước đo thành công: ... (con số mà CFO đã đồng ý)
Người quyết định: ...   Champion: ...   Người dùng cuối: ...
Trade-off đã chốt: ngưỡng tự duyệt = ..., lý do ..., người ký: ...
Ngoài phạm vi giai đoạn này: ...

Năm bước để tự làm

Bước một là lập bản đồ bốn vai bằng tên người thật, ngay trong tuần đầu tiên. Bước hai là chạy discovery với cả hai phía. Stilla yêu cầu FDE làm việc với cả đội kỹ thuật lẫn stakeholder nghiệp vụ để biết chính xác khách hàng muốn gì. Nếu chỉ hỏi CTO, bạn sẽ có một kiến trúc đẹp đặt trên một quy trình bạn không hiểu.

Bước ba là vẽ quy trình và chốt thước đo trước khi viết code. Paraform mô tả việc này là chạy các buổi discovery, vẽ lại workflow của tổ chức và định nghĩa thành công trông như thế nào trước khi triển khai. Paraform gọi đây là value scoping: xác định những kết quả đo được, đủ để chứng minh deployment đáng làm, trước khi cam kết nguồn lực engineering.

Bước bốn là dùng working session thay cho slide. Stilla viết rằng FDE dẫn các buổi làm việc thực hành với stakeholder nghiệp vụ và lãnh đạo để thống nhất mục tiêu. Hãy mở dữ liệu thật của họ ra và chỉnh ngưỡng ngay trước mặt họ. Một quyết định họ tự tay chốt sẽ bền hơn nhiều so với một quyết định bạn đề xuất qua email.

Bước năm là chăm lo khâu đưa vào sử dụng. Stilla mô tả phần việc này rất thẳng: coach các champion, rồi đi tìm từng người dùng đang bị kẹt cho đến khi use case của họ chạy được. Việc này thường cần có mặt trực tiếp, nên MongoDB ghi rõ ứng viên phải sẵn sàng đi công tác đến site khách hàng tới 30% thời gian.

Những lỗi khiến deployment chết lặng lẽ

Lỗi phổ biến nhất là chỉ nói chuyện với người giống mình. Developer thường thấy dễ chịu khi ngồi với CTO và né buổi gặp với phòng kế toán. Kết quả là hệ thống chạy đúng nhưng không ai dùng.

Lỗi thứ hai ngược lại: chỉ bám lãnh đạo. Có chữ ký của giám đốc không có nghĩa là có người dùng. Đó là lý do Paraform đặt việc giữ đội tuyến đầu đi cùng hướng ngay trong định nghĩa stakeholder management. Lý lẽ rất dễ thấy: sau ngày go-live, những người mở công cụ mỗi ngày là họ, không phải giám đốc.

Lỗi thứ ba là để thước đo thành công trôi nổi. Nếu CFO chưa đồng ý con số nào trước khi bạn code, đến buổi review bạn sẽ bị chấm bằng một con số khác. Lỗi thứ tư là nói thuật ngữ với người không làm kỹ thuật.

“Precision 0,97” chẳng có nghĩa gì với kế toán trưởng, còn “mỗi ngày đội chị còn xem khoảng chừng này hóa đơn” thì có.

Còn một lỗi tinh vi hơn: nhầm vai của mình. Paraform phân biệt deployment strategist, người hoạt động như product manager cho vấn đề của khách hàng, với FDE là người thực thi kỹ thuật. Nếu đội bạn có người làm vai strategist, hãy phối hợp với họ, đừng tranh việc. Nếu không có, bạn phải tự làm cả phần đó.

Đưa kỹ năng này vào CV và buổi phỏng vấn

Khi đọc job description FDE, hãy tìm các cụm như “executives”, “business stakeholders”, “champions” hay “on-site”. Chúng cho biết bạn sẽ dành bao nhiêu thời gian bên ngoài editor. Nếu một JD mang nhãn FDE mà gần như không nhắc đến những cụm này, hãy hỏi thẳng trong phỏng vấn xem bạn sẽ gặp khách hàng nhiều đến đâu.

Trong CV, đừng chỉ ghi “xây module đối soát”. Hãy ghi bạn đã làm việc với phòng nào, cùng họ chốt thước đo gì, và bao nhiêu người thật sự dùng công cụ. Nhiều developer Việt Nam làm outsourcing hoặc dự án nội bộ ngân hàng đã từng ngồi với khách hàng nghiệp vụ mà không coi đó là kinh nghiệm.

Bài tập trong tuần

Lấy một quyết định kỹ thuật gần nhất của nhóm bạn, có thể là chọn cache, đổi lịch đồng bộ dữ liệu hay đặt một ngưỡng nào đó. Viết ba đoạn giải thích, mỗi đoạn tối đa ba câu, cho ba người nghe trong bảng ở trên. Sau đó nhờ một người không làm kỹ thuật đọc thử đoạn dành cho lãnh đạo.

Nếu họ hỏi lại “vậy rốt cuộc là tốt hay xấu”, bạn biết mình cần viết lại chỗ nào.

Code giúp hệ thống chạy đúng. Còn việc từng người phía khách hàng có tiếp tục dùng nó hay không thì phụ thuộc vào cách bạn làm việc với họ.