Viết cập nhật bất đồng bộ để nhóm phân tán dùng được

Cập nhật bất đồng bộ cho phép mọi người phản hồi ở các thời điểm khác nhau. Tính linh hoạt đó biến mất nếu thông điệp chỉ ghi “nhờ xem giúp” còn tác giả không có mặt để giải thích. Mục tiêu không phải loại bỏ họp. Mục tiêu là phối hợp việc thường lệ mà không buộc mọi người có cùng giờ làm hoặc nhớ một cuộc trò chuyện trước đó.

Viết cho người đọc sau, không chỉ người đang trò chuyện

Mở đầu bằng kết quả đang bàn và giải thích ngắn vì sao người đọc cần hành động. Liên kết trực tiếp đặc tả hiện hành hoặc bằng chứng. Tóm tắt thay đổi liên quan ngay trong thông điệp bằng vài câu ngắn, đủ nghĩa và dễ hiểu, để người nhận không phải đọc mọi tài liệu liên kết mới hiểu yêu cầu.

Tài liệu GitHub mô tả issue là hồ sơ phục vụ lập kế hoạch, thảo luận và theo dõi công việc, có phân công để thể hiện trách nhiệm.[2] Nhóm có thể dùng công cụ khác nhưng nên giữ các chức năng này. Chọn một hồ sơ bền vững cho quyết định, chủ yếu dùng kênh trò chuyện để thu hút chú ý tới hồ sơ đó.

Nêu rõ thỏa thuận phản hồi

Giải thích thông điệp cần thông tin, phê duyệt hay lựa chọn giữa các phương án. Nêu người trả lời và thời hạn theo cách tham chiếu thời gian chung. Tránh “cuối ngày” khi người đọc ở nhiều nơi. Ghi bước tiếp theo nếu hết thời hạn mà chưa có câu trả lời.

Trước khi gửi, kiểm tra xem đồng nghiệp có thể tiếp tục mà không hỏi lại ý bạn hay không.

• Cung cấp mục đích, trạng thái hiện tại và thay đổi đáng kể.
• Liên kết bằng chứng chính thức thay vì ảnh chụp không giải thích.
• Đặt một câu hỏi rõ và nêu người chịu trách nhiệm trả lời.
• Ghi thời hạn phản hồi và hành động khi chưa có trả lời.
• Lưu quyết định cuối cùng ở nơi người đọc sau tìm được.

Ví dụ giả định: màn hình tài khoản có bản dịch

Trong ví dụ giả định về cổng khách hàng, người thiết kế cần duyệt một nhãn tài khoản dài hơn sau khi dịch. Thay vì gửi hai hình không bối cảnh, bản cập nhật nêu màn hình liên quan, giải thích vấn đề trên màn hình hẹp và dẫn tới bản xem trước có cả hai ngôn ngữ.

Yêu cầu đưa ra lựa chọn nhãn ngắn hơn hoặc bố cục sửa đổi và giải thích đánh đổi của từng cách. Người phụ trách sản phẩm có thể quyết định trong ca làm tiếp theo. Đồng nghiệp sau đó ghi lựa chọn và cập nhật tài liệu thiết kế, để người triển khai về sau không suy diễn phê duyệt từ một biểu tượng phản ứng.

Biết khi nào không nên trao đổi bất đồng bộ

Hướng dẫn trực vận hành của Google xác định đường chuyển cấp rõ ràng và quy trình sự cố được định nghĩa là nguồn hỗ trợ quan trọng.[7] Khuyến nghị ở đây là chuyển vấn đề dịch vụ khẩn cấp qua đường liên hệ trực tiếp đã thống nhất, không qua luồng rà soát thường lệ. Chỉ chấp nhận phản hồi chậm khi công việc chịu được sự chậm đó.

Cập nhật bằng văn bản cũng tốn công đọc và có thể kéo dài bất đồng. Chuyển tranh luận phức tạp sang cuộc trao đổi tập trung nếu thêm một tin nhắn không làm rõ hơn. Sau đó ghi lại kết luận. Thử cách làm với một lần bàn giao giữa các địa điểm và hỏi người nhận chi tiết nào còn thiếu khiến họ phải hỏi lại.