Việc xong ở tay mình chưa chắc đã xong với cả đội

Có một kiểu hoàn thành rất dễ nhận ra trong công việc: phần của mình đã xong.

Tài liệu đã gửi. Báo cáo đã lên. Thiết kế đã bàn giao. Một đầu việc được đánh dấu hoàn tất. Người phụ trách có thể đã làm rất nhanh, rất cẩn thận và hoàn toàn đúng với yêu cầu ban đầu. Nhìn vào phần việc đó, chẳng có gì đáng phàn nàn.

Nhưng kết quả mà cả nhóm chờ đợi đôi khi vẫn chưa đến.

Một người khác chưa biết bản nào là bản cuối. Một quyết định chưa có người nhận. Một thông tin quan trọng nằm trong tin nhắn cũ. Có người đã hoàn tất phần mình, nhưng người tiếp theo chưa thể bắt đầu. Không ai nhất thiết làm sai; công việc chỉ đang đứng giữa hai chiếc bàn.

Điều tôi muốn giữ lại từ nghịch lý này là: việc xong ở tay mình chưa chắc đã xong với cả đội.

Năng suất cá nhân rất đáng trân trọng. Tuy vậy, nếu chỉ nhìn vào tốc độ từng người, chúng ta có thể bỏ sót thứ quyết định công việc có thật sự đi đến đích hay không: cách nó được chuyển từ người này sang người khác, từ bước này sang bước tiếp theo.

Mỗi người có một chiếc đồng hồ riêng

Khi tự làm một việc, mình thường biết rất rõ lúc nào bắt đầu và lúc nào kết thúc. Mình thấy được phần khó nhất, những lần sửa, những đoạn phải tập trung và cả cảm giác nhẹ nhõm khi bấm nút gửi.

Người nhận lại sống với một chiếc đồng hồ khác.

Với họ, công việc có thể chỉ bắt đầu khi đầu ra đủ rõ để sử dụng. Một bản trình bày hoàn thành lúc chiều muộn nhưng thiếu số liệu nguồn vẫn chưa phải đầu vào sẵn sàng cho người thuyết trình. Một thiết kế gửi đúng hạn nhưng chưa xác định kích thước xuất bản vẫn cần thêm một vòng hỏi đáp. Một báo cáo đủ biểu đồ nhưng chưa nói chỉ số nào đáng chú ý có thể khiến người ra quyết định phải tự tìm lại vấn đề.

Những ví dụ này chỉ là tình huống minh họa, không phải câu chuyện của một nhóm cụ thể.

Nếu nhìn từ người làm, việc đã xong. Nếu nhìn từ người nhận, việc còn dang dở. Cả hai nhận định đều có lý trong phạm vi của mình.

Rắc rối xuất hiện khi tổ chức chỉ dùng một trong hai góc nhìn để đánh giá toàn bộ quá trình. Khi ấy, người giao việc có thể nghĩ mình đã nói đủ; người nhận có thể nghĩ mình chưa được cung cấp đủ; và cuộc trao đổi dần chuyển từ giải quyết công việc sang giải thích xem ai đã làm đúng.

Có lẽ nên phân biệt hai thời điểm: hoàn thành phần việc và đầu ra được người tiếp theo tiếp nhận để sử dụng. Chúng có thể trùng nhau, nhưng không mặc định là một.

Khoảng chờ thường không có tên

Một bảng công việc có thể rất đầy đủ: người phụ trách, hạn chót, trạng thái, mức ưu tiên. Nhưng có một thứ ít khi được ghi rõ: thời gian một đầu việc nằm giữa hai trạng thái.

Khoảng chờ ấy thường không thuộc riêng ai, nên cũng khó xuất hiện trong thành tích cá nhân. Nó không phải lúc nào cũng được tính là thời gian làm việc, dù vẫn kéo dài thời gian để tạo ra kết quả.

Nếu một nhóm muốn biết vì sao công việc chậm, câu hỏi “Ai đang làm chậm?” có thể chưa phải điểm bắt đầu tốt nhất. Tôi nghiêng về câu hỏi khác: “Việc đang đứng ở đâu, và cần điều kiện gì để đi tiếp?”

Hai câu hỏi dẫn tới hai cách cư xử khác nhau. Câu đầu dễ khiến mọi người phòng thủ. Câu sau buộc mình nhìn vào trạng thái của công việc, thông tin còn thiếu và quyết định cần được đưa ra.

Không phải mọi khoảng chờ đều xấu. Có những khoảng dừng cần thiết để kiểm tra chất lượng, cân nhắc rủi ro hoặc tôn trọng thời gian của người khác. Vấn đề không phải xóa hết chờ đợi, mà là phân biệt chờ có chủ đích với chờ vì không ai biết phải làm gì tiếp.

Bàn giao cũng là một sản phẩm

Chúng ta thường gọi bản báo cáo, bản thiết kế hay đoạn mã là sản phẩm của một công việc. Tôi nghĩ còn một sản phẩm nhỏ hơn nhưng rất quan trọng: cách bàn giao.

Một lần bàn giao tốt không cần dài dòng. Nó chỉ cần giúp người tiếp theo trả lời được vài câu hỏi: Đây là bản nào? Đã hoàn tất phần gì? Điều gì chưa chắc? Tôi cần xem hoặc quyết định điều gì? Nếu có lỗi thì quay lại ai?

Đôi khi chỉ một câu “Đây là bản cuối để duyệt nội dung; hình minh họa vẫn chờ kiểm tra quyền sử dụng” đã hữu ích hơn một tin nhắn “Xong rồi nhé”.

Sự khác biệt không nằm ở độ lịch sự. Nó nằm ở khả năng người nhận hiểu đúng trạng thái mà không phải đoán.

Điều này cũng giải thích vì sao giao việc rõ ràng không đồng nghĩa với viết thật nhiều hướng dẫn. Một bản mô tả dài nhưng không chỉ ra kết quả mong đợi vẫn có thể làm người nhận lúng túng. Ngược lại, một lời nhắn ngắn có đủ mục tiêu, giới hạn và điều kiện hoàn thành đôi khi đã đủ để bắt đầu.

Với những công việc có nhiều người tham gia, tôi thích ý tưởng xem điểm bàn giao như một “hợp đồng nhỏ”: người gửi chịu trách nhiệm về độ rõ của đầu ra; người nhận có quyền nói điều gì còn thiếu; và cả hai thống nhất khi nào việc thực sự chuyển trạng thái.

Đây là một nguyên tắc vận hành để thử, không phải công thức có thể áp dụng máy móc cho mọi đội.

Làm nhanh hơn có thể tạo ra một hàng đợi dài hơn

Một người làm việc rất nhanh thường được xem là lợi thế của nhóm. Phần lớn trường hợp, đúng là như vậy. Nhưng nếu tốc độ ở một khâu tăng lên mà khâu sau không thể tiếp nhận tương ứng, đầu ra có thể tích tụ thành hàng đợi.

Giả sử, chỉ để minh họa, một nhóm có thể chuẩn bị mười đề xuất trong khi mỗi tuần chỉ đủ thời gian xem xét ba đề xuất. Tăng tốc độ chuẩn bị lên gấp đôi không tự động khiến số đề xuất được quyết định tăng gấp đôi. Phần chưa được xử lý có thể nhiều hơn, trong khi người làm vẫn cảm thấy mình đã rất năng suất.

Từ góc nhìn này, một đầu việc được tạo thêm không phải lúc nào cũng là một kết quả được tạo thêm.

Tôi không nghĩ giải pháp là yêu cầu người làm nhanh phải chậm lại cho bằng người khác. Làm vậy vừa phí năng lực, vừa dễ khiến họ mất động lực. Điều đáng thử hơn là nhìn xem khâu sau cần hỗ trợ gì: tiêu chuẩn đầu vào rõ hơn, cách phân loại ưu tiên tốt hơn, một người có quyền chốt, hay đơn giản là giới hạn số việc đang mở cùng lúc.

Có những giai đoạn cần tạo trước nhiều đầu ra để chuẩn bị cho mùa cao điểm. Có những việc có thể làm song song mà không gây ùn tắc. Vì vậy, không nên biến “hàng đợi” thành thứ lúc nào cũng phải loại bỏ.

Nhưng nếu đầu ra cứ tăng mà kết quả cuối không tiến tương ứng, đó là tín hiệu nên nhìn vào dòng chảy chung trước khi tiếp tục khen hoặc thúc ép tốc độ ở một khâu.

Đừng biến phối hợp thành bài kiểm tra xem ai chịu khó hơn

Khi một việc bị kẹt, rất dễ nghe những lời như “chủ động hơn đi”, “chịu khó nhắc lại”, “tự tìm hiểu thêm”. Có lúc những lời đó hoàn toàn đúng. Tinh thần trách nhiệm cá nhân vẫn quan trọng, và một quy trình tốt không thể thay thế sự quan tâm thật sự đến công việc.

Nhưng nếu lần nào cũng phải có một người nhớ để nhắc, một người biết ai cần hỏi, một người tự tìm đúng phiên bản tài liệu, thì sự trôi chảy ấy đang phụ thuộc quá nhiều vào trí nhớ và quan hệ cá nhân.

Một hệ thống làm việc nên giúp cả người mới lẫn người cũ hiểu đường đi của công việc. Nó không nên chỉ hoạt động khi có một vài người luôn sẵn lòng cứu mọi tình huống.

Tôi cũng không thích cách nghĩ rằng mọi vấn đề phối hợp đều có thể giải quyết bằng thêm một cuộc họp. Một cuộc họp có thể giúp làm rõ bất đồng; nhưng nếu cuộc họp kết thúc mà vẫn không ai biết người chịu trách nhiệm cho bước tiếp theo là ai, thì chúng ta chỉ chuyển khoảng chờ từ chỗ này sang chỗ khác.

Sự thấu hiểu trong quản trị, theo cách tôi nhìn nhận, không chỉ là thông cảm khi ai đó gặp khó. Nó còn là đặt câu hỏi xem cách tổ chức công việc có đang tạo ra khó khăn không cần thiết cho họ hay không.

Đôi khi điều tử tế nhất với đồng đội là nói rõ một quyết định. Đôi khi là từ chối nhận thêm việc chưa có mục tiêu. Đôi khi là chấp nhận một khoảng thời gian kiểm tra hợp lý thay vì đòi mọi thứ phải xong ngay.

Một câu hỏi khác khi nhìn vào năng suất

Nếu chỉ đo mỗi người hoàn thành bao nhiêu việc, ta sẽ thấy phần hoạt động của họ. Điều đó hữu ích, nhưng chưa đủ để hiểu khả năng tạo kết quả chung.

Tôi muốn nhìn thêm ba lớp, không phải để làm một bảng chấm điểm mới, mà để hỏi đúng vấn đề.

Lớp đầu tiên là việc có được làm đúng không. Một đầu ra nhanh nhưng phải sửa nhiều lần vì hiểu sai yêu cầu có thể khiến cả nhóm mất thêm thời gian. Ở đây, chất lượng không chỉ là đẹp hay đúng kỹ thuật, mà còn là phù hợp với việc người nhận thực sự cần làm.

Lớp thứ hai là việc có đi tiếp được không. Sau khi bàn giao, người tiếp theo có đủ thông tin, quyền truy cập và quyền quyết định để hành động chưa? Nếu chưa, đầu ra có thể vẫn nằm im dù người gửi đã hoàn thành.

Lớp thứ ba là việc có đi đến kết quả cần thiết không. Một báo cáo được gửi không tự động tạo ra quyết định. Một quyết định được ghi nhận không tự động trở thành thay đổi đã thực hiện. Và một thay đổi đã thực hiện cũng cần được kiểm tra xem có giải quyết đúng vấn đề ban đầu hay không.

Ba lớp này không nhằm phủ nhận thành tích cá nhân. Ngược lại, chúng giúp công sức cá nhân có cơ hội biến thành giá trị thực sự.

Có thể đo một vài tín hiệu như số lần yêu cầu bổ sung thông tin, số việc bị trả lại, thời gian chờ phê duyệt hoặc tỷ lệ việc cần mở lại. Nhưng những chỉ số ấy cũng dễ bị dùng sai nếu thiếu bối cảnh. Một nhóm xử lý việc khó, rủi ro cao có thể cần nhiều vòng kiểm tra hơn một nhóm làm việc lặp lại. Không nên biến ít lần sửa thành mục tiêu bằng mọi giá.

Thử sửa một điểm bàn giao trước khi sửa cả quy trình

Nếu muốn ứng dụng suy nghĩ này, tôi sẽ không bắt đầu bằng một bộ quy trình mới hay phần mềm quản lý công việc mới.

Tôi sẽ chọn một loại việc hay phải hỏi đi hỏi lại, rồi quan sát đúng một vòng từ lúc giao đến lúc kết quả được sử dụng. Không cần khảo sát toàn bộ tổ chức. Chỉ cần đủ rõ để nhìn thấy các bước mà mọi người đang phải tự đoán.

Có thể thử một mẫu bàn giao rất ngắn: “Đã hoàn tất phần nào?”, “Còn điều gì chưa được xác nhận?”, “Ai nhận bước tiếp theo và cần phản hồi gì?”. Sau một khoảng thời gian phù hợp, xem số lần phải hỏi lại có giảm không, người nhận có bắt đầu sớm hơn không, và có phát sinh bất tiện mới nào không.

Nếu không thấy cải thiện, cũng cần chấp nhận khả năng giả thuyết ban đầu sai. Có thể vấn đề thật nằm ở năng lực chuyên môn, sự thay đổi ưu tiên hoặc một quyết định chiến lược chưa rõ. Một mẫu bàn giao tốt không thể giải quyết tất cả.

Điều quan trọng là giữ việc thử nghiệm đủ nhỏ để không biến một vấn đề đơn giản thành thêm một lớp hành chính.

Trong tài liệu về phối hợp quy trình, n8n nhấn mạnh việc theo dõi trạng thái, các điểm chuyển giao và xử lý ngoại lệ khi nhiều bước phụ thuộc nhau. Atlassian Team Playbook cũng đề xuất làm rõ vai trò, trách nhiệm và những phần việc chưa có người nhận. Tôi xem đó là hai gợi ý tham khảo cho cách tổ chức công việc, không phải bằng chứng rằng một phương pháp sẽ luôn giúp mọi nhóm nhanh hơn.

Không phải mọi việc đều cần thêm quy trình

Có một ranh giới tôi nghĩ rất dễ vượt qua khi bắt đầu thích tư duy hệ thống: thấy chỗ nào chưa rõ là muốn thêm quy tắc vào chỗ đó.

Nhưng không phải sự linh hoạt nào cũng là lộn xộn. Với một nhóm nhỏ, làm việc thường xuyên cùng nhau và hiểu rất rõ ngữ cảnh, một cuộc trao đổi trực tiếp có thể tốt hơn một biểu mẫu. Với công việc sáng tạo đang ở giai đoạn khám phá, chốt quá sớm tiêu chuẩn đầu ra có thể làm mất những ý tưởng đáng thử.

Quy trình chỉ có ích khi chi phí làm rõ thấp hơn chi phí hiểu lầm mà nó giúp tránh. Nếu để bàn giao một việc hai phút mà phải điền một biểu mẫu mười phút, chúng ta có thể đang tạo thêm nút thắt dưới danh nghĩa giải quyết nút thắt.

Tôi cũng không muốn dùng lập luận “cả đội chưa tiến” để phủ nhận đóng góp của một cá nhân. Có những người làm tốt phần của mình trong khi quyền quyết định nằm ngoài phạm vi họ kiểm soát. Đánh giá công bằng cần tách phần họ có thể tác động khỏi phần phụ thuộc vào hệ thống.

Vì vậy, thay vì đòi mọi người phải chịu trách nhiệm cho mọi thứ, có lẽ nên làm rõ hai loại trách nhiệm: trách nhiệm hoàn thành phần mình và trách nhiệm giúp đầu ra có thể tiếp tục được sử dụng. Loại thứ hai không nhất thiết bắt một người phải gánh cả quy trình; nó đòi hỏi một cách phối hợp minh bạch hơn.

Đi nhanh cùng nhau là một năng lực khác

Một người giỏi có thể hoàn thành việc khó trong thời gian ngắn. Một tập thể giỏi còn cần biết làm sao để kết quả của người này không trở thành câu hỏi chưa được trả lời của người khác.

Tôi nghĩ đây là một sự thay đổi nhỏ nhưng đáng giữ trong cách nhìn về năng suất: đừng chỉ hỏi hôm nay mỗi người làm được bao nhiêu; hãy hỏi công việc đã đi thêm được bao xa đến kết quả cuối, và còn mắc ở đoạn nào.

Có khi câu trả lời là cần người làm nhanh hơn. Có khi là cần một quyết định rõ hơn. Có khi chỉ là cần nói cho nhau biết đâu là bản cuối, điều gì chưa chắc và ai sẽ tiếp tục.

Không phải lúc nào cả nhóm cũng cần thêm năng lực thực thi. Đôi khi cả nhóm chỉ cần bớt để công việc rơi vào khoảng trống giữa những người đều đang cố gắng.

Hoàn thành phần mình là trách nhiệm. Giúp công việc có thể đi tiếp là một phần của phối hợp. Và kết quả chung cần cả hai.