Làm việc với khách lệch múi giờ: mỗi vòng trao đổi mất một ngày, nên mỗi tin nhắn phải xong việc trong một vòng

Thử hình dung bạn lệch 12 tiếng so với đội dữ liệu của khách. Cuối ngày, bạn nhắn: “Anh chị kiểm tra giúp bảng orders có vấn đề gì không?”. Sáng hôm sau, câu trả lời là: “Vấn đề gì vậy?”. Bạn giải thích, rồi lại chờ thêm một đêm. Hai ngày đã trôi qua mà pipeline vẫn chưa nhúc nhích.

Với FDE, cảnh này rất quen. Khách hàng có thể ở bất cứ đâu, và những lúc bạn kẹt nhất thường là lúc cần khách cấp quyền truy cập, chốt một quyết định về schema hay xác nhận dữ liệu.

Handbook của Common Knowledge nói thẳng rằng vì bất đồng bộ chậm hơn đồng bộ, viết thiếu thông tin có thể khiến cả nhóm mất nhiều ngày.

Kỹ năng cần luyện ở đây không phải là “trả lời nhanh hơn”. Bạn cần ba thứ đi cùng nhau: cập nhật viết đủ để không ai phải hỏi lại, một khung giờ chung nhỏ được giữ cho việc khó, và một bộ quy tắc phản hồi mà cả hai bên đã đồng ý.

Vì sao tin nhắn đầu tiên thường thất bại?

Lúc viết, bạn biết mọi thứ: bạn đã chạy query nào, thấy con số lạ ở đâu, nghi ngờ điều gì. Người đọc thì không biết những điều đó. Nguyên tắc cần nhớ là viết cho người không ở trong đầu bạn suốt cả ngày.

Đội ngũ thoughtbot nhận xét rằng khi tin nhắn được viết lại cho rõ, khách có thể trả lời được việc ngay trong một vòng.

Khi mỗi vòng tốn một ngày, đó là khác biệt giữa xong trong hôm nay và xong vào tuần sau. Vì thế, mục tiêu của mỗi tin nhắn rất cụ thể: người nhận phải trả lời được ngay mà không cần hỏi lại.

Viết lại tin nhắn về bảng orders

Đây là phiên bản thứ hai của tin nhắn ở đầu bài, viết theo năm phần:

Bối cảnh: Pipeline đồng bộ bảng orders sang kho dữ liệu chạy lúc
02:00 UTC hằng ngày. Đêm qua job chạy thành công nhưng số dòng giảm
khoảng một nửa so với hôm trước.

Phát hiện: Các dòng bị thiếu đều có status = 'pending'. Query kiểm tra
và kết quả nằm trong link đính kèm.

Cần anh chị chọn:
  A. Dòng 'pending' bị loại có chủ đích (thay đổi phía hệ thống nguồn)
  B. Đây là lỗi, cần giữ lại dòng 'pending'

Mặc định: Nếu chưa có trả lời trước Thứ Năm 15:00 UTC, phía FDE sẽ
giữ nguyên dữ liệu cũ và tạm dừng job, để dashboard không bị sai.

Trong lúc chờ: Phía FDE viết test đếm số dòng theo status để lần sau
phát hiện ngay.

Mỗi phần trả lời sẵn một câu hỏi lại mà khách có thể đặt ra. Phần bối cảnh trả lời câu “job nào?”. Phần phát hiện trả lời “sao anh biết?”. Phần lựa chọn biến một câu hỏi mở thành một quyết định mà khách có thể trả lời bằng một chữ cái.

Hai phần cuối thường bị bỏ qua nhưng lại quan trọng nhất. Phương án mặc định khiến sự im lặng cũng dẫn tới một kết quả, nên công việc không bị treo. Hạn chót phải ghi rõ thứ, giờ và múi giờ, vì “chiều mai” là chiều của ai thì không ai chắc.

Bàn giao cuối ngày: nơi bối cảnh dễ rơi rớt nhất

Giữa hai múi giờ, bàn giao diễn ra mỗi ngày: bạn dừng tay đúng lúc khách bắt đầu làm. Đó cũng là chỗ bối cảnh rơi rớt nhiều nhất. Khi không có cuộc họp nào để hỏi trạng thái, trạng thái chỉ tồn tại nếu ai đó viết nó ra.

Một bản bàn giao tốt chỉ cần bốn dòng, đặt ở cùng một chỗ mỗi ngày. Tiếp tục ví dụ bảng orders, bản bàn giao tối hôm đó có thể trông như sau:

Bàn giao Thứ Tư, 18:00 UTC+7 (11:00 UTC)

Đã xong: test đếm số dòng theo status cho bảng orders, đã merge.
Đang bị chặn: job đồng bộ orders, chờ anh chị chọn A hoặc B
  (tin nhắn gửi lúc 17:30 UTC+7 trong channel dự án).
Chờ khách quyết định: giữ hay loại dòng 'pending',
  hạn Thứ Năm 15:00 UTC.
Phía FDE làm tiếp: nếu chọn B, sửa điều kiện lọc và chạy lại job;
  nếu chọn A, cập nhật tài liệu schema.

Để ý rằng dòng “đang bị chặn” nói rõ bị chặn bởi ai và trỏ về đúng tin nhắn cần trả lời. Dòng cuối cho khách thấy câu trả lời của họ sẽ được dùng thế nào, nên họ có lý do để trả lời sớm.

Phép thử rất đơn giản: khách đọc xong mà không phải hỏi gì. Làm được vậy đều đặn, người ở múi giờ bên kia không còn bị thiệt về thông tin chỉ vì lệch giờ với bạn.

Khung giờ chung: nhỏ, được bảo vệ, và công bằng

Văn bản không giải quyết được mọi thứ. Đàm phán lại phạm vi, báo tin xấu hay chốt một quyết định kiến trúc vẫn cần nói chuyện trực tiếp. May là kể cả khi lệch nhiều giờ, thường vẫn tìm được 30-60 phút trùng nhau, thứ nhiều nhóm gọi là “core hours”, dành cho video call hoặc stand-up.

Bí quyết là dùng khung giờ ấy đúng việc. Đừng phí nó vào cập nhật trạng thái, vì phần đó đã có văn bản lo. Hãy giữ nó cho những việc mà viết qua lại sẽ tốn nhiều vòng.

Còn một điểm FDE hay quên: quy ước múi giờ phải nói rõ ai đang phải họp quá sớm hoặc quá muộn. Nếu bạn luôn là người họp lúc 22:00, hãy ghi điều đó ra và luân phiên khi có thể. Một FDE kiệt sức sau ba tháng sẽ không còn giúp được khách.

Quy tắc phản hồi: viết ra trước khi cần đến

Phần lớn căng thẳng khi làm lệch múi giờ đến từ những kỳ vọng không ai nói ra. Mốc 24 giờ là điểm khởi đầu hợp lý cho thỏa thuận với khách: Common Knowledge đặt mặc định phản hồi bình luận trong 24 giờ từ Thứ Hai đến Thứ Năm, và Doist cũng kỳ vọng mọi người trả lời trong 24 giờ.

Vế còn lại quan trọng không kém: đừng bao giờ đòi người khác trả lời ngay, trừ khi đó là trường hợp khẩn cấp thật sự. Vì thế sự cố production cần một kênh riêng, chẳng hạn số điện thoại hay một channel cảnh báo, kèm định nghĩa rõ thế nào là “khẩn cấp”.

Loại việc	Kênh	Thời hạn phản hồi
Câu hỏi, quyết định thường	Tin nhắn viết theo năm phần	Trong 24 giờ làm việc
Trạng thái hằng ngày	Bản bàn giao cuối ngày	Đọc đầu ngày của bên kia
Quyết định khó, tin xấu	Khung giờ chung 30-60 phút	Lần họp chung gần nhất
Production sập	Kênh khẩn cấp riêng	Ngay lập tức

Những lỗi hay gặp

Lỗi phổ biến nhất là câu hỏi mở không có phương án mặc định, vì nó buộc công việc phải chờ. Lỗi thứ hai là ghi giờ mà không ghi múi giờ, hoặc dùng “mai”, “cuối tuần” mà không có ngày cụ thể.

Lỗi thứ ba là dùng khung giờ chung để đọc lại trạng thái, trong khi những quyết định thật sự cần nói lại bị dồn sang tin nhắn.

Lỗi cuối cùng khó thấy hơn: coi mọi tin nhắn là khẩn cấp. Khi mọi thứ đều gấp, khách sẽ thôi tin vào chữ “gấp”, và đến lúc production sập thật thì không ai phản ứng kịp.

Bài tập: đếm số vòng bạn đang đánh mất

Mở lại năm tin nhắn gần nhất bạn gửi khách hoặc đồng nghiệp ở múi giờ khác. Đánh dấu những tin mà câu trả lời đầu tiên là một câu hỏi lại, rồi viết lại tin tệ nhất theo năm phần ở trên.

So hai phiên bản cạnh nhau và tự hỏi: nếu gửi bản mới, bạn tiết kiệm được mấy vòng? Con số đó chính là số ngày bạn đã mất mà không hề hay biết.

Biến kỹ năng này thành bằng chứng khi đi xin việc

Đừng chỉ ghi “giao tiếp tốt” trong CV.

Hãy mô tả việc cụ thể: bạn đã đặt quy tắc phản hồi, khung giờ chung và mẫu bàn giao với một khách lệch bao nhiêu giờ, và quyết định bị chặn được gỡ nhanh hơn ra sao. Khi phỏng vấn, cặp tin nhắn trước và sau từ bài tập trên là thứ bằng chứng dễ kể nhất.

Lần tới khi định bấm gửi một câu hỏi lúc cuối ngày, hãy đọc lại nó bằng con mắt của người sẽ mở tin nhắn khi bạn đã ngủ. Nếu họ phải hỏi lại, bạn vừa mất một ngày mà chưa biết.