Chi phí của việc bị gián đoạn trong công việc (2023)

• Có quan niệm phổ biến rằng sự gián đoạn (Interruptions) trong khi làm việc gây ảnh hưởng xấu đến năng suất, nhưng con số nổi tiếng 23 phút 15 giây để phục hồi lại có cơ sở không rõ ràng
• Trong bài báo khoa học được trích dẫn rộng rãi, thời gian 23 phút 15 giây thực tế không được nhắc đến
• Nhiều bài blog và bài báo có trích dẫn con số này, nhưng phần lớn trong số đó hoặc trích dẫn sai bài báo khoa học, hoặc dựa trên các cuộc phỏng vấn của Gloria Mark
• Các nghiên cứu cụ thể lại cho thấy thời gian hoàn thành công việc gốc khi bị gián đoạn còn hơi ngắn hơn, trong khi chỉ mức độ căng thẳng tăng lên
• Thiếu nguồn chính thức và rõ ràng, và hiện tại nguồn chủ yếu là các trích dẫn từ phỏng vấn cá nhân

---

Ảnh hưởng của gián đoạn đến năng suất

• Có một nhận định lan truyền rộng rãi rằng khi bị làm phiền hoặc phải chuyển ngữ cảnh trong lúc làm việc thì cần 23 phút 15 giây để quay lại công việc
• Tuy nhiên, tác giả bắt đầu thắc mắc con số này xuất phát từ đâu và đã cố gắng kiểm chứng bài báo gốc thực sự đáng tin cậy
• Dù đã nhiều lần tìm kiếm và đọc các bài báo khoa học, vẫn không thể tìm thấy số 23 hay nội dung nói về 23 phút 15 giây trong bài báo gốc được viện dẫn

Rà soát các bài báo khoa học liên quan

• Bài báo thường được nhắc đến trong các bài blog là The Cost of Interrupted Work: More Speed and Stress
• Bài báo này đưa ra kết quả rằng khi có gián đoạn, thời gian dành cho công việc thực ra lại giảm, trong khi mức căng thẳng mà người làm việc trải nghiệm lại tăng lên
• Trong bài báo không có con số cụ thể hay nội dung nào về thời gian quay lại công việc gốc sau khi hết gián đoạn, và con số 23 cũng không xuất hiện trong phần nội dung
• Ở các bài báo khác, tài liệu tham khảo hay nghiên cứu liên quan, con số này cũng không được mô tả một cách rõ ràng

Phân tích trích dẫn từ blog và truyền thông

• Tác giả đã xem xét thêm tổng cộng 23 bài blog và 5 bài báo khoa học
  • 9 bài đã trích dẫn sai bài báo khoa học, trong đó có 1 bài còn chứa cả câu trích dẫn thực tế không hề tồn tại
  • Chỉ có 2 bài trích dẫn chính xác kết luận thực sự của bài báo đó
  • 9 bài trực tiếp hoặc gián tiếp trích dẫn 3 cuộc phỏng vấn của Gloria Mark
  • 2 bài trích lại phát ngôn trực tiếp của Gloria Mark từ Wall Street Journal
• Cuối cùng, con số 23 phút 15 giây hóa ra là một con số mang tính kinh nghiệm mà Gloria Mark đã nhắc đến trong nhiều cuộc phỏng vấn
• Tuy nhiên, bài báo hay nghiên cứu chính thức nơi con số này xuất hiện lần đầu thì vẫn không thể xác minh rõ ràng

Kết luận và tham khảo

• Con số “mất 23 phút 15 giây sau khi bị gián đoạn” hiện tại mới chỉ dựa trên nguồn phỏng vấn, chưa có cơ sở chính thức được công bố thành bài báo khoa học
• Ngay cả khi rà soát thêm danh sách nhiều bài báo của Gloria Mark, tác giả cũng không tìm thấy con số này
• Nếu ai biết bài báo hay nghiên cứu chính thức có chứa con số này, tác giả mong được cung cấp thêm thông tin

Thông tin khác

• Bài viết có giới thiệu địa chỉ một chủ đề thảo luận trên Reddit về chủ đề liên quan
• Bài viết cũng cung cấp đồ thị tham chiếu và danh sách liên kết của toàn bộ các bài blog và bài báo khoa học được nhắc đến

[GN⁺]

Ý kiến trên Hacker News

• Có những ngày chỉ một lần chen ngang bất ngờ cũng đủ cắt đứt hẳn dòng suy nghĩ của tôi, rồi sáu tiếng sau đó trôi qua như thể tôi đang nhặt những cái chai rỗng hay mấy món dụng cụ đường sắt chẳng biết có bao giờ dùng đến hay không; nhưng cũng có ngày việc bị chen ngang lại trôi qua mà hầu như không ảnh hưởng gì, và vì đến giờ tôi vẫn không đoán được hôm nào sẽ là kiểu nào nên đang tự hỏi có lẽ mình không nên đăng nhập Slack nữa

  • Với tôi, pair programming cực kỳ hiệu quả trong việc giảm thiểu tác động của sự chen ngang; ở một startup tôi từng làm, chúng tôi pair programming suốt cả ngày mỗi ngày, và việc dừng rồi nối lại gần như không thành vấn đề, khó giải thích lắm, phải tự trải nghiệm mới hiểu
  • Rất đồng cảm, vào những ngày như vậy thì rời khỏi bàn làm việc, đi dạo trong rừng hoặc làm việc nhà lại giúp tôi lấy lại sự tập trung hơn; vào những ngày không hợp để làm việc, chọn nghỉ ngơi hẳn cuối cùng lại dẫn đến năng suất bùng nổ vào hôm sau, đôi bên cùng có lợi
  • Với tôi thì “tính chất” của sự chen ngang quan trọng hơn; những câu hỏi dễ có thể lôi ngay từ trí nhớ ra thì không tốn kém mấy, nhưng khi phải nghĩ sâu hơn hoặc phải kiểm tra code/tài liệu thì cảm giác cực kỳ nặng nề, ngay cả thông báo email hay Teams cũng có thể phá vỡ dòng chảy, vấn đề không phải là có ai đến làm phiền mà là họ chen ngang bằng chủ đề gì; tuy vậy, cứ đang code mà bị chen ngang thì rủi ro sinh bug luôn cao hơn
  • Với tôi, khác biệt nằm ở chỗ có lên kế hoạch công việc trước hay không; nếu tôi đã biết trước từ 10 đến 11 giờ mình sẽ tập trung vào việc gì thì việc quay lại làm tiếp dễ hơn, còn nếu chỉ bắt đầu mà không có kế hoạch thì ngay cả khi không bị tác động bên ngoài tôi cũng dễ bị xao nhãng
  • Tôi nhận ra nó tỉ lệ thuận với việc đêm hôm trước tôi ngủ ngon đến mức nào, và ngược lại thì tỉ lệ nghịch với lượng cà phê tôi đã uống trong tuần trước đó

• Trong mảng báo chí khoa học, vấn đề này rất phổ biến; bài báo thường truyền tải khác với nội dung của paper, thậm chí hoàn toàn ngược lại, và nhiều khi còn chẳng tìm được paper được trích dẫn ngay trong phần thân bài, đôi khi lỗi thuộc về tác giả nhưng phần lớn là do phóng viên khoa học viết theo cách gây hiểu lầm hoặc bóp méo; nguyên tắc cơ bản của tôi là luôn tự dành ít nhất 5 phút lướt qua abstract, phương pháp, và biểu đồ/dữ liệu của paper, như vậy còn hiểu chính xác hơn nhiều so với đọc bài phổ biến khoa học, và càng làm thì càng quen; bản thân tôi cũng phục hồi rất nhanh sau khi bị gián đoạn nếu đang làm TDD một cách nghiêm ngặt, nhưng những việc chỉ diễn ra trong đầu như cân nhắc thiết kế hay phân tích thuật toán phức tạp thì mất rất lâu mới hồi lại được, tôi nghĩ kiểu tổn thất này thực ra có thể đo được và cũng có thể làm thí nghiệm

  • Trong môi trường nơi việc bị làm phiền là chuyện đương nhiên, tôi thay đổi hẳn cách làm việc; nhìn bề ngoài thì có vẻ mất ít thời gian hơn, nhưng thực chất chỉ là đang làm việc theo kiểu chấp nhận bị gián đoạn, tác động có giảm nhưng công việc nói chung chỉ bị phân mảnh ra thôi
  • Tôi tự hỏi liệu một phần hiện tượng LLM (mô hình ngôn ngữ lớn) nói bậy có phải đến từ việc chúng nhầm kiểu đưa tin khoa học này là dữ liệu huấn luyện chất lượng cao hay không
  • Bài viết giải thích rất chi tiết cách những lỗi nhỏ như vậy tích tụ, làm xói mòn lòng tin rồi lan thành vấn đề lớn; ví dụ kiểu đưa tin “nhà khoa học nói rằng” lại khiến người tiêu dùng phải gánh trách nhiệm cho sai sót của phóng viên nhiều hơn là của nhà khoa học, hay những nội dung như “ăn nhiều hotdog gây ung thư” được truyền đi theo hướng giật gân mà bỏ mất bối cảnh nghiên cứu và các con số, vì thế công chúng mất niềm tin do sự lệch nhau giữa nghiên cứu thực tế và câu chuyện trên báo chí; thêm vào đó, số lần được trích dẫn lại quyết định danh tiếng của nhà khoa học, tạo ra động lực để tìm kiếm sự chú ý từ truyền thông, và điều này cũng làm gia tăng méo mó, các paper bình thường thì chẳng thu hút nổi ánh nhìn, đến mức paper của nghiên cứu sinh MIT còn được trích dẫn nhiều hơn; những vấn đề mang tính hệ thống như vậy ngày càng lớn dần như một hiệu ứng tổng hợp, đơn giản hóa mọi lời giải thích có thể tiện thật nhưng thực tế thì thế giới ngày càng phức tạp hơn, và paper vốn là phương tiện giao tiếp giữa các đồng nghiệp với nhau, còn khi cần giao tiếp với công chúng thì phải có các communicator chuyên nghiệp riêng, câu “nếu không giải thích đơn giản được thì tức là bạn không hiểu” cũng là chuyện buồn cười, vì những khái niệm phức tạp vốn dĩ không thể biến thành đơn giản được

• Nguồn gốc ban đầu là cuộc phỏng vấn năm 2006 của Gallup với nhà nghiên cứu Gloria Mark, liên kết, trong đó có nhắc rằng “trung bình mất 23 phút 15 giây để quay lại công việc sau khi bị gián đoạn”, điểm tích cực là 81,9% mọi người vẫn quay lại công việc gốc trong ngày hôm đó, và khoảng thời gian ấy không quá dài

  • Tôi hiểu rằng con số 23 phút này không có nghĩa là thời gian bỏ ra để cố tập trung lại vào việc cũ sau khi bị gián đoạn, mà là thời gian được dùng cho việc chen vào kia hoặc những tác vụ mới cần xử lý ở giữa, nên bản thân khoảng thời gian đó không hẳn là bị lãng phí
  • Đáng tiếc là cuộc phỏng vấn này không phải nguồn sơ cấp thật sự; một tác giả tên Jaro Fietz (oberien) đã tham chiếu cuộc phỏng vấn đó trong sơ đồ của mình, nhưng vẫn chưa tìm ra paper nghiên cứu gốc, nếu ai biết chính xác paper nào thì xin cho biết
  • Nhưng tôi lại thấy tò mò không biết “tin xấu” là gì

• Khi đang giải những vấn đề phức tạp mà bị kéo ra khỏi trạng thái tập trung sâu (flow), tôi thật sự có cảm giác như bị đau về thể xác; dù cố tỏ ra bình thản bên ngoài thì trong đầu, sợi chỉ đang nối mọi ngữ cảnh lại với nhau đã bị cắt đứt, tôi không thể đo mức thiệt hại năng suất bằng con số nhưng tùy bài toán mà nhiều khi phải mất hơn 20 phút mới hồi phục được

  • Tôi có cố giải thích cho ban lãnh đạo cấp cao vì sao việc chuyển quản lý issue của dự án mã nguồn mở từ public GitHub sang private Jira (cần 2FA) lại có hại cho năng suất của developer, nhưng họ không thể đồng cảm; với họ, “trạng thái flow” hay nỗi đau khi bị cắt ngang đột ngột chỉ là chuyện viển vông

• Tôi cảm thấy thứ lãng phí thời gian hơn cả bản thân sự “gián đoạn” do cuộc họp gây ra chính là “sự dự đoán trước” rằng mình sắp bị gián đoạn, nên thành ra mất luôn 30 phút ở mỗi phía

  • Trước đại dịch, lịch làm ở nhà/văn phòng của tôi khá thất thường, và đôi khi nếu đến văn phòng sớm trước một cuộc họp thì khoảng thời gian ở giữa gần như trôi qua vô ích, chẳng thể bắt đầu việc gì cần đào sâu mà chỉ làm mấy việc nghiên cứu đơn giản cho qua; môi trường open office vốn đã nhiều xao nhãng nên khó tập trung, tốt nhất có lẽ là chỉ đến trước cuộc họp 5–10 phút nhưng thực tế thì khó canh như vậy, ngược lại cũng có lúc tôi đang trong trạng thái flow nên lỡ luôn cuộc họp, mà khi ấy thì thông báo trên desktop hay điện thoại thật sự chẳng có tác dụng gì; nếu muốn chắc chắn không bỏ lỡ thì phải đặt báo thức, nhưng tôi lại không hay làm thế
  • Chính những cuộc họp kiểu này mới phá hỏng ngày của tôi; những gián đoạn khác từ đồng nghiệp thì hầu như đều hiệu quả và có ích
  • Tôi cũng rất ghét những cuộc họp bị dời lịch gấp vào phút chót; khi nghĩ rằng mình chỉ còn 30 phút thì chẳng thể bắt đầu việc gì có ý nghĩa, thật sự là lãng phí thời gian
  • Tâm lý sẽ thành kiểu “còn 30 phút nữa là họp rồi, thôi đừng bắt đầu làm việc nghiêm túc”; có người thông minh nào đó lại để các cuộc họp cách nhau 1 tiếng, và thế là cả ngày chẳng làm được gì
  • Với tôi nữa thì cứ có cuộc họp là coi như mất nửa ngày

• Với tư cách quản lý, thành thật mà nói tôi xem phần lớn những sự làm phiền lặp đi lặp lại gây khó chịu là “thái độ không tự nỗ lực”; vai trò của tôi không chỉ là đưa ra chiến lược và ưu tiên mà còn là gỡ nút thắt khi developer bị kẹt, nhưng có người thậm chí không tự tìm những thứ cơ bản như “nếu cần tài khoản database thì hỏi người phụ trách hạ tầng” hay “xem git để biết ai viết API này” mà hỏi thẳng ngay

  • Ở góc độ developer senior tôi cũng đồng cảm; rất nhiều khi chỉ cần tự bỏ ra 2–3 phút là biết được mà họ lại hỏi tôi trong 15 giây, còn khi junior hỏi câu sâu thì tôi sẵn sàng cùng nghĩ 15–30 phút, nhưng trước đó tôi luôn hỏi lại xem họ đã thử tìm kiếm hay tự nỗ lực thế nào rồi; vậy mà nếu cứ lặp đi lặp lại cùng một kiểu hỏi thì thật sự mệt mỏi, nghe câu trả lời còn thấy có khi chính họ cũng đã biết rồi, dường như chỉ muốn ai đó làm hộ, nên rất hao mòn
  • Tôi coi những lúc như vậy là thời gian để “dạy cách câu cá”, đồng thời cũng hỏi xem họ đã tự điều tra và thử những gì; nếu việc đó cứ lặp lại thì phải nói thẳng trong buổi 1:1, còn nếu xuất hiện đồng thời ở nhiều người thì có thể không còn là vấn đề cá nhân nữa mà là vấn đề gốc rễ của cả tổ chức hoặc quy trình tài liệu hóa, nhất là trong các tổ chức phức tạp hay đội ngũ lớn thì tình huống này rất hay xảy ra
  • Nếu yêu cầu đến từ ngay trong team của tôi thì tôi lại cho rằng đó là một phần công việc chứ không hẳn là “gián đoạn” thật, vì định hướng và sắp xếp ưu tiên vốn đâu thể không phải là việc chính

• Thật thú vị khi sự thật là rất nhiều người chỉ nhìn tiêu đề hoặc bài báo rồi phản ứng, hoặc thậm chí còn bình luận khi chưa đọc, lại đang trớ trêu chứng minh ngay chính “luận điểm của bài viết” trong thời gian thực

  • Có vẻ như rất nhiều người đọc mỗi bình luận thôi mà vẫn tham gia thảo luận là chuyện thường gặp; tôi cũng có lúc chưa đọc bài mà xem bình luận trước để quyết định có đọc hay không, nhưng ít nhất nếu định để lại ý kiến ở các bình luận đầu thì tôi luôn đọc bài gốc trước

• Nếu thật sự “23 phút” là một giá trị cố định thì nhiều nghề quan trọng khác nhau như bác sĩ hẳn đã không thể tồn tại, nghĩa là tác động của việc chen ngang không thể được tóm gọn bằng một con số duy nhất

  • Tôi nghĩ đó là giá trị trung bình, và trên thực tế có việc chỉ mất 5 giây, có việc lại mất 2 tiếng; ngay từ đầu câu trích dẫn chính xác cũng không cụ thể đến mức ấy nên việc cứ nhấn vào một giá trị đơn lẻ 23 phút là kết luận quá vội
  • Hoặc cũng có thể công việc bị gián đoạn cứ ngày càng bị đẩy lùi về ưu tiên thấp hơn nên rốt cuộc không được xử lý nữa

• Nội dung này có trong trang 44 của cuốn sách ‘Multitasking in the Digital Age’ của Gloria Mark, liên kết

• Nỗ lực tìm nguồn thật kỹ và ghi chép cẩn thận như vậy thật đáng nể; tôi thường phải trách sinh viên vì các em trích dẫn tài liệu tham khảo hay nguyên bản mà không tìm hiểu cẩn thận, hoặc nhầm lẫn một cách diễn giải sai thành suy nghĩ của chính mình, đọc chủ động là một quá trình trong đó người đọc tự bổ sung suy nghĩ và diễn giải của mình khi đọc