Delta và Echo: vì sao Palantir giao việc triển khai cho hai vai, và cách một FDE tự đóng cả hai

Tuần đầu ở site khách hàng, bạn thường nhận ba yêu cầu mâu thuẫn nhau ngay trong buổi họp đầu tiên. Trưởng phòng vận hành muốn một dashboard, kế toán muốn xuất file Excel, còn đội IT chỉ dặn một câu: đừng đụng vào database. Bạn vừa muốn mở laptop code ngay, vừa muốn hỏi thêm mười câu nữa.

Palantir không bắt một người chịu cả hai lực kéo đó. Họ tách công việc triển khai thành hai vai riêng, có tên riêng: Echo và Delta.

Nếu đội bạn không đặt sẵn một người làm Echo bên cạnh, bạn sẽ là cả Echo lẫn Delta. Khi đó, người làm tốt là người biết mình đang ở chế độ nào.

Hai người, hai kiểu giỏi khác nhau

Theo các mô tả về mô hình của Palantir, Echo là analyst ngồi cùng khách hàng và có chuyên môn ngành thật sự. Họ lo discovery cho use case, lo adoption và giữ quan hệ với khách. Echo thường xuất thân từ chính ngành của khách hàng, và theo một phân tích bên ngoài, người làm Echo (còn gọi là Deployment Strategist) thường không phải kỹ sư phần mềm.

Delta là tên nội bộ của Palantir cho Forward Deployed Engineer. Đây là kỹ sư thiên về thực thi: nhận bài toán từ Echo rồi xây prototype chạy được, càng nhanh càng tốt. Cũng theo phân tích bên ngoài đó, Delta phải qua cùng vòng phỏng vấn kỹ thuật với các kỹ sư và kiến trúc sư làm core product.

Họ không phải “kỹ sư hạng hai” được đem ra site.

Delta khác kỹ sư product (Dev) ở phạm vi công việc. Dev xây một năng lực cho nhiều khách hàng, còn Delta xây nhiều năng lực cho một khách hàng. Hai vai còn khác nhau về cách làm việc. Việc của Echo là discovery: lắng nghe, quan sát và dựng lên bức tranh về thực tế vận hành của khách.

Với Delta, kỹ năng quan trọng là viết code ship được ngay hôm nay, dù yêu cầu vẫn đang đổi và thông tin chưa đầy đủ.

Giá trị nằm ở chỗ bàn giao

Có một câu nói rất thẳng về sự phụ thuộc giữa hai vai: một đội Echo không có Delta chỉ làm được việc quản lý quan hệ, không giao được sản phẩm nào. Chiều ngược lại cũng dễ hình dung. Delta không có Echo thì code nhanh, nhưng code cho một bài toán mà khách không hề có.

Khi bạn tự làm cả hai vai, bản brief đó thường chỉ nằm trong đầu, và chính ở đó nó hỏng. Bạn tưởng mình đã hiểu khách, nhưng thật ra mới nghe một người nói to nhất phòng họp.

Ví dụ: lệnh xuất hàng trễ ở một kho lạnh

Thử hình dung bạn triển khai cho một công ty kho lạnh. Yêu cầu ban đầu là “làm dashboard theo dõi đơn trễ”. Ở chế độ Echo, bạn chưa nói gì về dashboard. Bạn ra kho ngồi cạnh trưởng ca, và cuộc trao đổi có thể diễn ra như sau.

Bạn: Sáng nay có đơn nào trễ không anh? > Trưởng ca: Có ba đơn. Xe tới rồi mà hàng chưa ra khỏi buồng đông. > Bạn: Lúc đó anh biết bằng cách nào? > Trưởng ca: Tài xế gọi điện. Anh mở file Excel của bộ phận điều phối, dò xem đơn đó đã có người soạn chưa. > Bạn: Nếu biết sớm hơn 30 phút thì anh sẽ làm gì khác?

Trưởng ca: Anh rút người từ khu khác qua soạn trước.

Đến đây bài toán đã đổi. Khách không thiếu dashboard. Thứ họ thiếu là cảnh báo sớm khi một đơn sắp tới giờ xe đến mà chưa có người soạn. Bạn chuyển nó thành brief:

BRIEF BÀN GIAO — Kho lạnh, ca sáng
1. Người dùng: trưởng ca, đứng ở sàn kho, chỉ có điện thoại
2. Điểm nghẽn: xe đã tới, hàng chưa ra khỏi buồng đông
3. Họ đang xoay xở thế nào: tài xế gọi, dò file Excel điều phối
4. Quyết định họ muốn ra sớm hơn: rút người sang soạn đơn
5.

Prototype tối thiểu và ràng buộc:
   cảnh báo khi đơn còn <30 phút tới giờ xe mà chưa có người soạn;
   chỉ đọc dữ liệu, không ghi vào database của IT

Bây giờ bạn đổi sang chế độ Delta. Brief đã chốt người dùng, thời điểm và ràng buộc, nên bạn không cần làm giao diện đẹp. Một job đọc file điều phối mỗi năm phút rồi gửi tin nhắn cho trưởng ca là đủ để thử trong một ca làm việc.

Brief cũng loại luôn yêu cầu xuất Excel của kế toán ra khỏi vòng này, và bạn ghi nó lại cho vòng sau.

Tự làm cả hai vai: các bước cụ thể

Bước đầu tiên là tách thời gian. Hãy dành riêng những khoảng trong ngày chỉ để quan sát và hỏi, đồng thời cấm mình đề xuất giải pháp trong lúc đó. Khi ở chế độ Echo, câu hỏi tốt nhất xoay quanh chỗ người dùng bị kẹt và cách họ đang tự xoay xở, không xoay quanh tính năng.

Bước thứ hai là viết brief ra giấy trước khi code, dù người đọc duy nhất là chính bạn. Nếu không điền được mục “quyết định họ muốn ra sớm hơn”, tức là bạn chưa xong việc của Echo. Khi đã điền đủ, đặt cho mình hạn chót ngắn để có prototype, vì Delta phải ship trong lúc thông tin còn thiếu.

Bước thứ ba là đem prototype trở lại sàn kho và quay về chế độ Echo. Xem người dùng có thật sự dùng nó không, đó là phần adoption mà Palantir giao cho Echo. Sau đó cập nhật brief cho vòng tiếp theo.

Ba cái bẫy hay gặp

Bẫy phổ biến nhất với người có nền kỹ thuật là bỏ qua Echo. Bạn nghe “dashboard” là dựng dashboard luôn, rồi hai tuần sau mới biết người dùng chính đứng ở sàn kho và không bao giờ mở máy tính. Bẫy ngược lại là ở chế độ Echo quá lâu: họp hết buổi này đến buổi khác, quan hệ rất tốt mà không ship được gì.

Bẫy thứ ba khó thấy hơn: làm Delta bằng tư duy của Dev. Bạn bắt đầu tổng quát hóa cảnh báo cho mọi kho, mọi loại đơn, trong khi việc của Delta là giải nhiều bài toán cho đúng một khách hàng này.

Lời khuyên ở đây là ghi lại những chỗ bạn thấy có thể dùng chung, rồi để dành cho phía product, thay vì tự tổng quát hóa ngay giữa đợt triển khai.

Thể hiện cả hai vai trong CV

Khi đọc JD, hãy để ý xem công ty tuyển riêng “Deployment Strategist” hay muốn một FDE kiêm luôn discovery. Nếu là vế sau, đừng chỉ ghi stack trong CV. Hãy viết theo mạch: đã quan sát ai, brief chốt bài toán gì, ship cái gì sau bao nhiêu ngày. Viết như vậy, người tuyển sẽ thấy bạn làm được cả việc của Echo lẫn Delta.

Palantir cần hai người cho việc này vì mỗi chế độ đòi một kiểu chú ý khác nhau. Nếu bạn phải tự làm cả hai, việc cần luyện là nhận ra mình đang đội chiếc mũ nào trước khi bước vào phòng họp.