Mệt Mỏi Thông Báo Là Thật – Tắt Kênh Không Giải Quyết Được
Mệt mỏi thông báo không phải về số lượng – đó là lỗi định tuyến tín hiệu khiến nhóm mất nhiều giờ mỗi tuần. Đây là nguyên nhân và điều thực sự hiệu quả.
By Ellis Keane · 2026-03-29
Lời khuyên phổ biến nhất để đối phó với mệt mỏi thông báo về cơ bản là chọn không nhận thông tin. Bật Không Làm Phiền. Tắt tiếng các kênh không "liên quan trực tiếp" đến công việc của bạn (chúc may mắn khi quyết định đó là những kênh nào). Gộp hộp thư đến thành hai lần kiểm tra mỗi ngày, và nếu bạn đặc biệt kỷ luật, hãy xóa Slack khỏi điện thoại vào cuối tuần. Đó là những lời khuyên hợp lý, thiện chí – và về cơ bản chúng hiểu sai vấn đề.
Mệt mỏi thông báo không phải về số lượng. Đó là về khoảng cách giữa những gì thông báo cho bạn biết và những gì bạn thực sự cần biết.
Mệt Mỏi Thông Báo Thực Sự Là Gì
Thuật ngữ này được dùng lỏng lẻo – thường là cách nói tắt của "tôi nhận quá nhiều ping" – nhưng mệt mỏi thông báo là điều gì đó cụ thể hơn và tinh vi hơn so với tình trạng quá tải thông tin đơn giản. Đó là sự xói mòn dần dần khả năng của bạn trong việc phân biệt tín hiệu quan trọng với nhiễu, không phải do số lượng thông báo bạn nhận được, mà do các công cụ của bạn trình bày mọi cập nhật với cùng một mức độ khẩn cấp – cùng một huy hiệu đỏ nhỏ, cùng một kiểu ngắt quãng – dù đó là vấn đề chặn quan trọng trên thời hạn ra mắt hay chỉ là ai đó phản ứng với tin nhắn bằng emoji giơ ngón cái.
Kết quả là bạn phát triển thói quen bỏ qua mọi thứ, vì não bộ của bạn đã học được (khá hợp lý, thực sự) rằng hầu hết những thứ đòi hỏi sự chú ý của bạn thực sự không xứng đáng với điều đó. Và một khi thói quen đó hình thành, các tín hiệu quan trọng bị chôn vùi cùng với nhiễu – không phải vì bạn không chú ý, mà vì chú ý đến mọi thứ về mặt chức năng tương đương với không chú ý đến bất cứ điều gì.
Theo kinh nghiệm của chúng tôi, quá tải thông báo thực sự không phải về số lượng thô – mà về tỷ lệ tín hiệu-trên-nhiễu. Một nhóm nhận 40 thông báo mỗi ngày với 35 trong số đó có liên quan có trải nghiệm hoàn toàn khác so với một nhóm nhận cùng 40 thông báo nhưng chỉ có 4 quan trọng và 36 còn lại là những thay đổi trạng thái về những thứ họ đã ngừng quan tâm từ nhiều tuần trước.
Huyền Thoại: Đây Là Vấn Đề Kỷ Luật
Có một ý tưởng phổ biến – và bạn sẽ thấy nó trong hầu hết mọi blog năng suất và hướng dẫn sức khỏe nơi làm việc – rằng mệt mỏi thông báo là điều bạn giải quyết bằng thói quen cá nhân tốt hơn: đặt ranh giới, cấu hình tùy chọn thông báo, tạo các khối "thời gian tập trung" chuyên dụng và sử dụng các tính năng hộp thư ưu tiên mà nhiều công cụ hiện đã có (thường là tính năng cao cấp bạn cần nâng cấp để dùng).
Những chiến thuật này không phải vô ích – tắt tiếng một kênh bạn thực sự không bao giờ đọc là hoàn toàn hợp lý, và lên lịch các khối tập trung là thực tế. Nhưng đóng khung mệt mỏi thông báo như một vấn đề kỷ luật đặt gánh nặng lên người nhận thông báo, trong khi nguồn gốc thực sự của vấn đề là các hệ thống gửi chúng.
Hãy nghĩ thế này: nếu một chuông báo cháy phát ra 200 lần một ngày, bạn sẽ không bảo lính cứu hỏa thực hành vệ sinh chuông báo tốt hơn. Bạn sẽ hỏi tại sao hệ thống báo động không thể phân biệt giữa đám cháy thật và ai đó nướng bánh mì bị cháy. Đó là tình huống mà hầu hết người lao động tri thức đang gặp phải – các hệ thống họ phụ thuộc không có khái niệm về tầm quan trọng, sự liên quan hoặc ngữ cảnh. Tin nhắn Slack về kế hoạch bữa trưa và tin nhắn Slack về sự cố production đến với cách trình bày giống hệt nhau – và đó là cách mệt mỏi thông báo Slack xâm nhập, một ping không thể phân biệt được mỗi lần một cái. Thông báo GitHub về một PR đã hợp nhất mà bạn là tác giả và thông báo GitHub về một bình luận trên một kho lưu trữ bạn đã đánh dấu sao một lần ba năm trước chiếm cùng một hộp thư đến, được tạo kiểu giống nhau, đòi hỏi sự chú ý như nhau.
"Nếu một chuông báo cháy phát ra 200 lần một ngày, bạn sẽ không bảo lính cứu hỏa thực hành vệ sinh chuông báo tốt hơn. Bạn sẽ hỏi tại sao hệ thống báo động không thể phân biệt giữa đám cháy thật và ai đó nướng bánh mì bị cháy." – Ellis Keane
Cách đóng khung theo kỷ luật cũng có một sự tàn nhẫn tinh tế: nếu mệt mỏi thông báo là vấn đề thói quen, thì những người chịu đựng nó phải có thói quen xấu. Chúng tôi không nghĩ điều đó đúng, và quan trọng hơn, nó không khớp với những gì chúng tôi đã quan sát. Những người kỷ luật nhất, có tổ chức nhất trong nhóm của chúng tôi vẫn bị choáng ngợp khi các công cụ của họ không thể nói với họ điều gì quan trọng.
Cơ Chế: Lỗi Định Tuyến Tín Hiệu
Mệt mỏi thông báo về cơ bản là lỗi định tuyến tín hiệu. Chúng tôi chưa giải quyết hoàn toàn điều này (để rõ ràng), nhưng mô hình đủ nhất quán để chúng tôi tự tin vào chẩn đoán.
Mỗi thông báo đại diện cho một tín hiệu – điều gì đó đã thay đổi ở đâu đó mà một hệ thống nào đó nghĩ bạn nên biết. Vấn đề là các hệ thống tạo ra những tín hiệu này hầu như không có ngữ cảnh về bạn: bạn đang làm gì ngay bây giờ, ưu tiên của bạn trong tuần này là gì, bạn đang tích cực tham gia vào những cuộc trò chuyện nào so với những cuộc mà bạn được gắn thẻ cách đây nhiều tháng vì lịch sự. Không có ngữ cảnh đó, lựa chọn duy nhất các hệ thống này có là gửi mọi thứ và để bạn tự phân loại.
Và bạn không thể phân loại hiệu quả – không ở quy mô lớn, và chắc chắn không phải hàng chục lần mỗi ngày trong khi vẫn phải làm công việc thực sự của mình. Việc phân loại tự nó trở thành một phần đáng kể trong ngày làm việc của bạn.
Hãy để tôi đưa ra một ví dụ cụ thể. Giả sử bạn là product manager trong nhóm mười hai người, và ngăn xếp điển hình của bạn bao gồm một trình theo dõi dự án, một nền tảng code, một ứng dụng nhắn tin, một công cụ thiết kế và tài liệu. Vào một buổi sáng thứ Ba bình thường, bạn có thể nhận: bốn thông báo từ trình theo dõi nhiệm vụ (hai thay đổi trạng thái trên các vấn đề bạn đang theo dõi, một bình luận mới, một lần giao việc), sáu thông báo nền tảng code (một yêu cầu đánh giá PR, hai PR đã hợp nhất trên các kho bạn đã đăng ký, ba cảnh báo tự động), mười một tin nhắn trên ba kênh (hai liên quan trực tiếp đến sprint hiện tại của bạn, bốn từ một kênh về dự án bạn đã hoàn thành tháng trước, năm chỉ là phản ứng emoji), hai bình luận thiết kế (một trên tệp bạn sở hữu, một trên tệp bạn được gắn thẻ để tham khảo) và cập nhật trang tài liệu.
Đó là hai mươi ba thông báo trước 10 giờ sáng. Có thể ba trong số đó yêu cầu sự chú ý của bạn. Nhưng việc tìm ra ba cái nào tốn cùng một lượng nỗ lực nhận thức như xử lý cả hai mươi ba, bởi vì mỗi cái đến với cùng mức độ chi tiết "ai đó đã làm gì đó ở đâu đó". Và đây là buổi sáng nhẹ nhàng – chúng tôi đã nói chuyện với các nhóm nơi con số gần 60 trước bữa trưa.
Mệt Mỏi Thông Báo Thực Sự Tốn Gì
Hình phạt chuyển đổi ngữ cảnh thay đổi theo loại nhiệm vụ và độ sâu của sự gián đoạn, nhưng chi phí tập trung lại đủ thực tế để hiển thị trong kết quả hàng ngày – ngay cả ước tính thận trọng cũng cho thấy vài phút mỗi lần gián đoạn, và điều đó tích lũy nhanh chóng khi bạn bị kéo ra khỏi sự tập trung hàng chục lần mỗi ngày. Hầu hết mọi người không gộp thông báo của họ vào các phiên phân loại tập trung (huy hiệu đỏ đang ở đó) – điều đó có nghĩa là họ đang trả chi phí chuyển đổi theo phản ứng, trên năm mô hình tinh thần khác nhau, suốt cả ngày.
Mệt mỏi thông báo không phải do quá nhiều thông báo – mà do các hệ thống không thể phân biệt giữa vấn đề chặn và phản ứng giơ ngón cái. Gánh nặng phân loại rơi vào con người vì các công cụ tạo ra tín hiệu không có ngữ cảnh về điều gì quan trọng với bạn ngay bây giờ.
Chúng tôi đã cố gắng mô hình hóa điều này trong nội bộ – một phần vì tò mò, một phần vì chúng tôi muốn ngừng cuộc tranh luận "chúng ta có thực sự tốn nhiều thời gian vào việc phân loại không?" mỗi lần retrospective – và toán học trở nên đáng chán nản nhanh chóng. Ba đợt phân loại mỗi ngày ở 15 phút mỗi đợt, cộng với thời gian tập trung lại, đặt bạn vào hơn một giờ mỗi ngày cho công việc meta của việc cập nhật thông tin. Trong một năm, đó là nhiều tuần làm việc không phải để đưa ra quyết định hay xây dựng, mà cho hành động sơ bộ là tìm ra những gì đã xảy ra trong khi bạn đang làm việc khác.
Khi có quá nhiều thông báo tại nơi làm việc cạnh tranh cho cùng một sự chú ý có hạn, mệt mỏi thông báo cũng làm giảm chất lượng quyết định. Một product manager vừa xử lý hai mươi ba thông báo không ở cùng trạng thái nhận thức như người nhận được ba cập nhật có ngữ cảnh, đã được phân loại sẵn – cùng thông tin về mặt lý thuyết, nhưng người đầu tiên phải làm việc nhiều hơn đáng kể để trích xuất nó, và công việc trích xuất đó có chi phí không xuất hiện trên bất kỳ bảng thời gian nào.
Những Gì Thực Sự Giảm Mệt Mỏi Thông Báo
Các phương pháp duy nhất chúng tôi thấy đáng tin cậy giảm mệt mỏi thông báo là chuyển công việc phân loại từ con người sang hệ thống – phân loại trước, chỉ gửi những gì quan trọng. Chúng tôi cũng chưa hoàn toàn giải quyết được điều này (thành thật mà nói), nhưng hướng đi thì rõ ràng.
Phần khó là "điều gì quan trọng" mang tính ngữ cảnh sâu sắc. Thông báo hợp nhất PR quan trọng rất nhiều nếu nó đang chặn mục tiêu sprint của bạn và hoàn toàn không quan trọng nếu đó là cập nhật phụ thuộc trên một thư viện bạn không chạm vào. Hệ thống thực hiện phân loại cần hiểu không chỉ những gì đã xảy ra, mà còn bạn là ai, bạn đang làm gì, và sự kiện này liên quan đến ưu tiên hiện tại của bạn như thế nào.
Chúng tôi đã tìm thấy ba phương pháp tạo ra sự khác biệt, mặc dù không có phương pháp nào là viên đạn bạc và mỗi phương pháp đều có sự đánh đổi mà chúng tôi vẫn đang giải quyết:
Hợp nhất thay vì nhân lên. Thay vì nhận các thông báo riêng biệt từ mỗi công cụ, hãy hợp nhất các tín hiệu thành một luồng duy nhất nơi chúng có thể được xếp hạng, nhóm và lọc với đầy đủ ngữ cảnh. Một bản tóm tắt có ngữ cảnh nói với bạn "đây là ba điều cần sự chú ý của bạn sáng nay, và đây là lý do" có giá trị hơn năm mươi thông báo thô trên năm ứng dụng. Chúng tôi đã thử nghiệm điều này trong nội bộ, và sự khác biệt rất rõ ràng – không phải vì thông tin thay đổi, mà vì công việc nhận thức để trích xuất nó giảm xuống gần như bằng không. Điều khó là hợp nhất chỉ hoạt động nếu hệ thống tiêu thụ các tín hiệu thực sự hiểu chúng, và đó là vấn đề kỹ thuật khó hơn trông thấy.
Suy luận ưu tiên, không chỉ cài đặt ưu tiên. Hầu hết các công cụ cho phép bạn cấu hình tùy chọn thông báo – tắt tiếng kênh này, chỉ nhận cảnh báo cho các lần đề cập, loại đó – nhưng đây là các quy tắc tĩnh không thể thích nghi với ngữ cảnh thay đổi. Điều hiệu quả trong sprint trước không nhất thiết hiệu quả trong sprint này. Phương pháp hữu ích hơn là suy luận ưu tiên động: một hệ thống hiểu các ưu tiên hiện tại của bạn và hiển thị tín hiệu phù hợp, ngay cả khi những ưu tiên đó thay đổi từ tuần này sang tuần khác. Chúng tôi thực sự không chắc chắn các quy tắc tĩnh có thể đưa bạn đi xa đến đâu trước khi bạn cần thứ gì đó thông minh hơn – câu trả lời trung thực có lẽ là "xa hơn hầu hết các nhóm thử, nhưng chưa đủ xa."
Ngữ cảnh đa công cụ. Đây là (chúng tôi nghĩ) phần bị đánh giá thấp nhất, và cũng là khó xây dựng nhất. Lý do các thông báo từ các công cụ riêng lẻ ồn ào như vậy là mỗi công cụ chỉ thấy phần riêng của mình trong công việc của bạn. Ứng dụng nhắn tin của bạn không biết về bảng sprint của bạn, nền tảng code của bạn không biết về vòng phản hồi thiết kế của bạn, và lịch của bạn không biết rằng cuộc họp nó sắp nhắc bạn đã thực sự bị hủy qua một thread hai mươi phút trước. Khi các tín hiệu từ các công cụ khác nhau được kết nối thành một lớp ngữ cảnh duy nhất – đó là những gì chúng tôi đang xây dựng với Sugarbug đồ thị tri thức – hệ thống có thể hiểu các mối quan hệ mà các công cụ riêng lẻ không thể, và sử dụng những mối quan hệ đó để quyết định điều gì thực sự xứng đáng với sự chú ý của bạn.
Một điều bạn có thể làm ngay hôm nay, không cần công cụ mới nào. Yêu cầu nhóm của bạn áp dụng quy ước tiền tố nghiêm ngặt cho tin nhắn: [ACTION] cho những thứ yêu cầu phản hồi, [FYI] cho thông tin, [BLOCKED] cho các chặn. Đây là phương pháp thủ công, không hoàn hảo và sẽ sụp đổ trong khoảng ba tuần theo kinh nghiệm của chúng tôi – nhưng nó chứng minh khái niệm. Khi ngay cả một tín hiệu liên quan thô sơ được đính kèm với thông báo, mọi người phân loại nhanh hơn. Mục tiêu là để các hệ thống thực hiện phân loại này tự động, nhưng phiên bản thủ công dạy nhóm của bạn cảm giác "định tuyến tín hiệu" trong thực tế là như thế nào.
Ngừng phân loại nhiễu và bắt đầu thấy tín hiệu. Sugarbug kết nối các công cụ của bạn và hiển thị những gì thực sự quan trọng.
Q: Sugarbug có giúp giảm mệt mỏi thông báo không? A: Có. Sugarbug kết nối các công cụ làm việc của bạn vào một đồ thị tri thức duy nhất, có nghĩa là nó có thể hiểu các mối quan hệ giữa các sự kiện trên toàn bộ quy trình của bạn. Thay vì chuyển tiếp mọi thông báo thô, Sugarbug hiển thị các tín hiệu có ngữ cảnh – những thứ thực sự cần sự chú ý của bạn dựa trên những gì bạn đang làm ngay bây giờ, không chỉ những gì đã xảy ra ở đâu đó. Đây không phải là bộ tổng hợp thông báo; đây là một lớp ngữ cảnh thực hiện công việc phân loại cho bạn.
Q: Sugarbug quyết định thông báo nào quan trọng như thế nào? A: Sugarbug xây dựng đồ thị tri thức sống về công việc của bạn – kết nối các nhiệm vụ, cuộc trò chuyện, con người và quyết định trên tất cả các công cụ tích hợp của bạn. Khi một tín hiệu mới đến, Sugarbug đánh giá nó với ngữ cảnh hiện tại của bạn: bạn đang ở sprint nào, nhiệm vụ nào được giao cho bạn, bạn đang tích cực tham gia vào cuộc trò chuyện nào. Các tín hiệu có liên quan về mặt ngữ cảnh được hiển thị; phần còn lại được ghi lại trong đồ thị nhưng không làm gián đoạn bạn. Chúng tôi vẫn đang tinh chỉnh mức độ lọc tích cực (quá tích cực và bạn bỏ lỡ mọi thứ, quá dễ dãi và bạn trở lại điểm xuất phát), nhưng kết quả ban đầu rất hứa hẹn.
Q: Mệt mỏi thông báo có giống với mệt mỏi cảnh báo không? A: Chúng liên quan nhưng không giống nhau. Mệt mỏi cảnh báo thường đề cập đến sự mất nhạy cảm với các cảnh báo vận hành quan trọng – phổ biến trong bối cảnh chăm sóc sức khỏe, DevOps và bảo mật, nơi bỏ lỡ cảnh báo có thể có hậu quả nghiêm trọng. Mệt mỏi thông báo rộng hơn và áp dụng cho tiếng ồn tín hiệu hàng ngày mà người lao động tri thức trải nghiệm trên các công cụ cộng tác. Cả hai đều có cùng cơ chế cốt lõi: khi mọi thứ đòi hỏi sự chú ý, không có gì nhận được nó.
Q: Điều đầu tiên tôi nên thử nếu mệt mỏi thông báo đang giết chết năng suất của tôi là gì? A: Trước khi đầu tư vào bất kỳ công cụ nào, hãy thử điều này: trong một tuần, hãy theo dõi mọi thông báo bạn nhận được và đánh dấu từng cái là "cần sự chú ý của tôi" hoặc "không cần". Hầu hết mọi người thấy rằng ít hơn 15% thông báo của họ thuộc loại đầu tiên. Tỷ lệ đó là đường cơ sở tín hiệu-trên-nhiễu của bạn, và biết nó là bước đầu tiên để khắc phục nó – dù bạn sử dụng Sugarbug, bộ lọc tùy chỉnh, hay chỉ đơn giản là cắt giảm đăng ký không thương tiếc.
---
Nếu mệt mỏi thông báo đang khiến nhóm của bạn mất nhiều giờ mỗi tuần – và nếu bạn đang sử dụng nhiều hơn một vài công cụ, điều đó thường xảy ra – đó là vấn đề chúng tôi đã xây dựng Sugarbug để giải quyết. Không phải bằng cách thêm một lớp thông báo khác lên trên, mà bằng cách kết nối các công cụ bạn đã sử dụng và hiển thị những gì thực sự quan trọng.