Bạn gửi “xem giúp mình nhé” trước khi hết ca. Khi quay lại, đồng nghiệp hỏi “xem bản nào?” và công việc đứng yên thêm một vòng. Giao tiếp khi làm việc khác múi giờ thường vướng ở những chi tiết nhỏ như vậy: thiếu đường dẫn, thiếu quyết định cần đưa ra hoặc một chữ “chiều nay” mà mỗi người hiểu theo lịch của mình. Một tin nhắn tốt giúp người nhận bắt tay vào việc ngay cả khi người gửi đã ngoại tuyến.
Không phải mọi trao đổi đều cần dài. Điều cần giữ là đủ bối cảnh, đủ rõ về việc cần làm và đủ dấu vết để người tiếp theo biết quyết định mới nhất. Bài viết dùng tình huống duyệt ảnh bìa và bàn giao yêu cầu khách hàng để bạn thử sửa cách nhắn trong công việc hằng ngày. Đây là những mẫu luyện tập; thay tên tệp, thời hạn và người phụ trách bằng thông tin thật của nhóm trước khi dùng.
Mục lục
Đổi mục tiêu từ “đã gửi” sang “người nhận có thể làm gì”
Tin nhắn đã gửi không đồng nghĩa công việc đã được bàn giao. Hãy tưởng tượng người nhận mở nó mà không thể hỏi bạn trong vài giờ. Họ có biết đang làm cho bài nào, phiên bản nào mới nhất và cần phản hồi điều gì không? Nếu câu trả lời còn phụ thuộc vào trí nhớ của hai người, bổ sung thông tin trước khi kết thúc ca.
GitLab mô tả cộng tác bất đồng bộ là cách làm việc không phụ thuộc vào sự hiện diện đồng thời của người khác. Với nhóm nội dung hoặc hỗ trợ, bạn có thể bắt đầu rất nhỏ: để đường dẫn bản đang xử lý ngay trong yêu cầu, ghi phần đã chốt và tách phần đang chờ quyết định. Không cần đưa cả lịch sử dự án vào mỗi tin nhắn.
Ví dụ “ảnh bìa ổn chưa?” khiến người nhận phải tìm bài và đoán tiêu chí. Viết “Nhờ duyệt cách xuống dòng của cover-B-v2 cho bài Negombo; màu và logo đã chốt ở lượt trước” thu hẹp đúng việc cần xem. Nếu chỉ cần một quyết định, đừng đưa thêm nhiều câu hỏi phụ không ảnh hưởng đến lượt duyệt này.
Viết bốn phần đủ để tiếp tục một việc
Phần đầu là bối cảnh: công việc đang ở đâu và vì sao cần phản hồi. Phần thứ hai là tài liệu đúng phiên bản. Phần thứ ba là hành động hoặc quyết định cần người nhận thực hiện. Phần cuối là thời hạn và cách xử lý nếu chưa có phản hồi. Bạn có thể viết thành một đoạn ngắn; không bắt buộc biến mọi tin nhắn thành biểu mẫu.
Thử mẫu này: “Bản B đã sửa tiêu đề để đọc rõ trên điện thoại. Tệp cover-B-v2 ở thư mục dùng chung, quyền xem đã kiểm tra. Nhờ Mai duyệt cách xuống dòng trước 14:00 giờ Colombo ngày đã thống nhất. Nếu chưa có xác nhận, mình giữ bài ở bản nháp và tiếp tục phần nội dung.” Mẫu nói rõ hành động dự phòng, không ngầm coi im lặng là đồng ý đăng.
Nếu có nhiều người trong nhóm, chỉ định một người chịu trách nhiệm quyết định cuối cùng theo phân công thực tế. Gắn tên cả nhóm không giúp ai biết phải trả lời. Bạn vẫn có thể mời người khác góp ý, nhưng cần phân biệt “góp ý chuyên môn” với “duyệt để thực hiện”. Điều này hữu ích khi một thiết kế nhận nhiều ý kiến khác nhau ở các thời điểm khác nhau.
Ghi thời gian để hai người hiểu cùng một mốc
“Sáng mai”, “cuối ngày” và “trước giờ nghỉ” chỉ rõ với người đang ở cùng lịch làm việc. Trong trao đổi khác múi giờ, ghi ngày và nơi dùng làm mốc, chẳng hạn giờ Colombo hoặc giờ của nhóm đã thống nhất. Nếu dùng lịch điện tử, xem phần múi giờ của sự kiện trước khi gửi; đừng chỉ nhìn con số trên ảnh chụp lịch của người khác.
Bạn không cần tự nhẩm mọi chênh lệch giờ trong đầu. Dùng công cụ lịch hoặc đồng hồ của thiết bị, kiểm tra ngày ở cả hai đầu rồi xác nhận mốc quan trọng bằng chữ. Với nơi có thay đổi giờ theo mùa, tránh giữ một phép quy đổi cố định cho cả năm. Khi một hạn chót có thể ảnh hưởng lịch đăng, hãy kiểm tra lại thời gian thực tế cho ngày đó.
Mốc phản hồi cũng phải phù hợp với lịch làm của người nhận. Một yêu cầu bình thường gửi lúc họ đang nghỉ không tự nhiên trở thành việc khẩn. Nhóm nên thống nhất giờ có thể phối hợp và kênh dùng cho sự cố thật sự. Với việc không khẩn, ghi thời hạn hợp lý và chuẩn bị phần mình có thể tiếp tục trong lúc chờ.
Giữ một nơi lưu quyết định mới nhất
Khi góp ý nằm trong chat riêng, tệp ở email và quyết định cuối trong cuộc gọi, người vào sau phải ghép nhiều mảnh mới hiểu dự án. Chọn một nơi lưu tiến độ mà nhóm đang dùng: trang dự án, ticket hoặc tài liệu chung. Tin nhắn chỉ cần dẫn người nhận về đúng mục ở đó, kèm thay đổi vừa xảy ra.
Nguyên tắc giao tiếp của GitLab coi trọng việc ghi lại kết luận của trao đổi ngoài tài liệu. Bạn có thể áp dụng sau một cuộc gọi ngắn: ghi quyết định, người thực hiện và phần còn mở ngay dưới yêu cầu ban đầu. Tránh chỉ viết “đã thống nhất” vì người không dự cuộc gọi không biết nội dung thống nhất là gì.
Đặt tên phiên bản cũng cần có ý nghĩa. “final”, “final-new” rồi “final-new-2” dễ làm người duyệt nhầm. Dùng cách nhóm đã thống nhất, có số phiên bản hoặc ngày phù hợp; khi gửi bản mới, nói bản nào được thay thế. Với tệp có quyền truy cập hạn chế, kiểm tra quyền của đúng người nhận, giữ dữ liệu riêng ở kênh được phép thay vì mở công khai cho tiện.
Chuyển sang cuộc gọi khi nhắn tiếp không còn hiệu quả
Bất đồng bộ không có nghĩa tránh mọi cuộc họp. Một vấn đề mơ hồ, nhiều cách hiểu hoặc cần thảo luận cảm nhận thiết kế có thể được gỡ nhanh bằng cuộc gọi ngắn. Trước khi mời, viết câu hỏi cần giải quyết và gửi tài liệu liên quan để thời gian gặp nhau tập trung vào quyết định, không dùng phần lớn buổi gọi để tìm tệp.
Sau cuộc gọi, ghi lại kết quả tại nơi theo dõi chung. Ví dụ: “Chọn bản B, giữ ảnh hiện tại, Linh sửa xuống dòng; Mai duyệt lần cuối. Chưa đăng cho đến khi có xác nhận.” Câu này giúp ca sau biết cả việc đã chốt lẫn giới hạn thực hiện. Nếu cuộc gọi không giải quyết được điểm vướng, ghi rõ còn cần thông tin nào, đừng đánh dấu hoàn tất chỉ vì cuộc họp đã kết thúc.
Với yêu cầu khách hàng, thông tin bàn giao còn phải có lời hẹn đã gửi cho khách. Bài xử lý khiếu nại bằng bước giải quyết rõ có một mẫu tách sự kiện khỏi điều chưa biết. Dùng cùng cách đó để đồng nghiệp nhận việc hiểu phần nào đã kiểm tra và phần nào cần tiếp tục.
Một lượt bàn giao cuối ca có thể viết thế nào?
Thử tình huống bạn đang chờ duyệt bản mở đầu, trong khi người tiếp nhận làm ca sau. Thay vì “bài còn dở, xem giúp”, viết: “Bài trà Ceylon đã có bản nội dung v3 và ba ảnh. Còn chờ duyệt đoạn phân biệt nhãn sản phẩm ở mục hai. Bình luận cần xem nằm ngay tại đoạn đó. Sau khi duyệt, cập nhật đoạn rồi xem lại trên điện thoại; phần lịch đăng giữ theo kế hoạch đã chốt.” Mỗi câu gắn với một việc có thể kiểm tra.
Nếu công việc bị chặn, nói thẳng điều kiện để tiếp tục. “Chờ nguồn xác nhận thành phần món ăn” hữu ích hơn “đang nghiên cứu”. Có thể ghi việc khác mình đã làm trong lúc chờ, nhưng đừng dùng một danh sách dài để che điểm nghẽn. Người nhận cần biết nơi tác động của họ sẽ làm công việc tiến lên.
Thử cải thiện một tin nhắn ngay trong ca tới
Chọn một yêu cầu hay bị hỏi lại, đọc nó như người không có bối cảnh và bổ sung đúng phần đang thiếu. Không cần thay toàn bộ cách làm của nhóm trong một ngày. Sau một vòng bàn giao, xem người nhận còn phải hỏi điều gì; câu hỏi đó thường chỉ ra chi tiết cần thêm ở lần sau.
Kỹ năng này cũng tạo ra một ví dụ tốt khi bạn trình bày kinh nghiệm bằng STAR: nêu vấn đề bàn giao, hành động bạn thực hiện và kết quả thật quan sát được. Giữ trọng tâm ở cách làm giúp đồng nghiệp tiếp tục công việc. Một tin nhắn có chất lượng không nhất thiết dài hơn, nhưng người đọc phải tốn ít công đoán hơn.
