Bài 7 — Slack/Discord Etiquette cho Tech Teams

Mở đầu — vì sao bài này quan trọng

Nếu bạn làm trong một tech team hiện đại, có một sự thật khó chối cãi: phần lớn giao tiếp hằng ngày của bạn không diễn ra trong phòng họp, không qua email, mà trên Slack hoặc Discord. Một khảo sát nội bộ điển hình ở các công ty phần mềm cho thấy một kỹ sư trung bình gửi và nhận hàng trăm tin nhắn mỗi ngày qua chat. Nghĩa là kênh chat chính là "mặt tiền" thể hiện năng lực giao tiếp của bạn nhiều hơn bất kỳ kênh nào khác.

Vấn đề là gần như không ai được dạy cách dùng chat cho đúng. Người ta cứ nghĩ chat là chỗ "nói chuyện thoải mái", nên viết như đang nhắn tin cho bạn thân: gửi một chữ "hi" rồi ngồi chờ, tag cả một kênh 200 người chỉ để hỏi một câu vặt, viết một dòng suy nghĩ thành mười tin nhắn rời rạc. Những thói quen tưởng nhỏ nhặt đó, khi nhân lên với cả team và cả năm làm việc, gây ra một lượng lãng phí thời gian khổng lồ và làm mòn sự tin cậy giữa mọi người.

Bài học này tập trung riêng vào một thứ: etiquette (phép tắc, quy chuẩn ứng xử) khi giao tiếp trên Slack và Discord trong môi trường tech. Đây không phải chuyện lịch sự hình thức. Chat etiquette tốt là một kỹ năng chuyên môn thực thụ — nó quyết định bạn có làm cho đồng nghiệp mất tập trung không, câu hỏi của bạn có được trả lời nhanh không, và người khác có thấy dễ chịu khi làm việc với bạn không. Ở phạm vi bài này, chúng ta bàn về văn hóa ứng xử trong chat: cách đặt câu hỏi, cách tag người, cách dùng thread, cách phản hồi. Chúng ta sẽ không đi sâu vào chuyện khi nào nên chat thay vì họp (đó là chủ đề của Bài 6 về async-first) hay cách viết một tin nhắn Slack hiệu quả về mặt cấu trúc câu chữ (Bài 45), mà tập trung vào chính bộ quy tắc hành xử — những "luật bất thành văn" giúp bạn trở thành một người mà cả team thích cộng tác cùng.

Khái niệm cốt lõi

Quy tắc vàng số 1: Đừng chỉ chào "hi" rồi im lặng

Đây là quy tắc quan trọng nhất và cũng bị vi phạm nhiều nhất. Kịch bản kinh điển: bạn cần hỏi anh Tuấn — trưởng nhóm backend — một chuyện. Bạn gõ:

> Bạn: Hi anh Tuấn 👋

Rồi bạn... dừng lại. Anh Tuấn thấy tin nhắn, phải bỏ dở việc đang làm để trả lời "ừ em, có gì không?", rồi lại quay ra chờ. Bạn gõ tiếp (mất thêm 30 giây). Anh ấy chờ tiếp. Cứ như vậy, một câu hỏi lẽ ra giải quyết trong một lượt đã tốn ba, bốn lượt qua lại, và quan trọng hơn: anh Tuấn bị kéo ra khỏi trạng thái tập trung (flow) tận hai lần, mỗi lần mất cả chục phút để lấy lại.

Có một website nổi tiếng trong giới lập trình tên là nohello.net ra đời chỉ để nhắc mọi người về đúng chuyện này. Nguyên tắc cực kỳ đơn giản: viết trọn vẹn câu hỏi ngay trong tin nhắn đầu tiên. Thay vì "Hi anh", hãy viết:

> Bạn: Chào anh Tuấn, em đang deploy service payment lên staging thì gặp lỗi 502 ở gateway. Em đã check log thấy timeout khi gọi sang user-service. Anh có biết user-service staging có đang chạy không, hay em cần config lại timeout ở đâu ạ? (không gấp, khi nào rảnh anh trả lời giúp em)

Người nhận đọc một lần là nắm hết bối cảnh, có thể trả lời ngay khi họ rảnh, thậm chí trả lời được cả khi họ đang bận và chỉ liếc điện thoại. Bạn tôn trọng thời gian của họ, và bạn cũng nhận được câu trả lời nhanh hơn. Đôi bên cùng thắng.

Quy tắc vàng số 2: Bất đồng bộ là mặc định, đừng đòi hỏi phản hồi tức thì

Chat trông giống nhắn tin thời gian thực, nhưng trong công việc, hãy coi nó như một dạng "email nhanh". Người ta đang code, đang họp, đang ăn trưa. Việc bạn gõ xong không có nghĩa là họ phải trả lời ngay. Một thói quen tốt là thêm dấu hiệu về mức độ khẩn: "(không gấp)", "(cần trước 4h chiều nay)", hoặc "(đang chặn mình, cần gấp)". Điều này giúp người nhận tự sắp xếp thứ tự ưu tiên mà không phải đoán.

Quy tắc vàng số 3: Dùng thread, đừng làm loạn kênh chính

Thread (luồng trả lời) là công cụ mạnh nhất để giữ cho một kênh chat sạch sẽ và dễ theo dõi. Khi trả lời một chủ đề đang có sẵn, hãy trả lời trong thread của nó thay vì gõ thẳng vào kênh chính. Nếu không, mười cuộc hội thoại khác nhau sẽ đan xen vào nhau như tơ vò, và người vào sau không tài nào hiểu nổi ai đang nói với ai. Thread giữ mỗi chủ đề nằm gọn trong một chỗ, và người không quan tâm chủ đề đó không bị làm phiền.

Quy tắc vàng số 4: Tag có chủ đích, đừng tag bừa

@here, @channel, @everyone là những "vũ khí hạng nặng". @channel gửi thông báo cho toàn bộ thành viên kênh — kể cả người đang offline; @here gửi cho mọi người đang online. Nếu kênh có 150 người mà bạn @channel chỉ để hỏi "ai biết mật khẩu wifi tầng 3 không?", bạn vừa làm 150 người rung điện thoại vì một chuyện chẳng liên quan gì đến 148 người trong số đó. Nguyên tắc: chỉ tag đích danh người bạn thực sự cần, và chỉ dùng @channel/@here khi thông tin thật sự khẩn cấp và liên quan đến số đông (ví dụ: "Production đang down, mọi người dừng deploy ngay").

Quy tắc vàng số 5: Định dạng để dễ đọc, đặc biệt với code

Đây là điểm rất "tech". Khi bạn dán một đoạn code hay log lỗi, đừng dán trần vào tin nhắn. Hãy dùng code block (bọc trong dấu backtick ``). Slack và Discord đều hỗ trợ điều này. Code không định dạng bị mất thụt đầu dòng, dấu ngoặc kép biến thành ký tự cong, và gần như không thể đọc. Với biến, tên hàm, tên file — dùng inline code (một dấu backtick). Điều này thể hiện sự chuyên nghiệp và giúp người đọc hiểu ngay đâu là code, đâu là lời văn.

Quy tắc vàng số 6: Đừng nén một suy nghĩ thành nhiều tin nhắn rời

Người quen dùng messenger cá nhân hay có thói quen gõ từng cụm ngắn rồi Enter liên tục: "anh ơi" / "cái task hôm qua" / "em làm xong rồi" / "nhưng mà" / "có 1 chỗ em chưa chắc". Năm lần Enter là năm lần điện thoại người nhận rung lên. Hãy gom lại thành một tin nhắn hoàn chỉnh (dùng Shift+Enter để xuống dòng trong cùng một tin nhắn). Một tin, một thông điệp trọn vẹn.

Tình huống thực tế

Tình huống 1: Cái "hi" tốn 20 phút ở một startup fintech tại TP.HCM

Ở một startup fintech khoảng 40 người tại Quận 1, TP.HCM, có một bạn dev junior tên Minh mới vào. Mỗi khi cần hỏi anh lead, Minh đều mở DM và gõ "Anh ơi em hỏi tí được không ạ?" rồi chờ. Anh lead — vốn phải review PR, họp với product, và tự code — mỗi ngày nhận khoảng năm, sáu cái "hỏi tí" như vậy từ nhiều người.

Có một hôm anh lead thử đo lại: từ lúc Minh gõ "anh ơi" đến lúc thực sự biết câu hỏi là gì, trung bình mất 12 phút (vì hai bên không online cùng lúc), và mỗi lần bị ngắt như vậy anh mất thêm khoảng 10 phút để lấy lại mạch code. Nhân lên, chỉ riêng cái "nghi thức chào hỏi" đó ngốn của team gần một giờ đồng hồ mỗi ngày.

Diễn giải: Anh lead không mắng Minh. Anh ghim (pin) link nohello.net vào kênh team và giải thích quy tắc trong buổi standup. Chỉ sau một tuần, Minh và mọi người chuyển sang viết trọn câu hỏi ngay từ đầu. Thời gian phản hồi trung bình cho các câu hỏi giảm rõ rệt, và anh lead không còn bị ngắt mạch vô cớ.

Bài học: Vấn đề không nằm ở việc Minh lười hay thiếu tôn trọng — bạn ấy chỉ đơn giản mang thói quen nhắn tin cá nhân vào công việc. Etiquette là thứ có thể dạy và học rất nhanh, chỉ cần ai đó nói ra thành luật rõ ràng.

Tình huống 2: Cú @channel lúc 11 giờ đêm

Một công ty product làm về logistics, team engineering có kênh #eng-general với 120 thành viên trải khắp Hà Nội, Đà Nẵng và cả vài bạn remote ở Singapore. Một bạn dev, đang loay hoay fix bug lúc 11 giờ đêm, cần biết ai đã sửa file config CI gần đây. Bạn ấy gõ @channel ai vừa đổi file ci config vậy ta?.

Kết quả: 120 người nhận thông báo. Vài chục điện thoại rung giữa đêm. Sáng hôm sau, kênh đầy những tin bực bội: "để @here thôi cũng được mà", "mình đâu liên quan gì đâu". Người thực sự sửa file đó thì... đang ngủ, sáng ra mới thấy.

Diễn giải: Đúng ra bạn dev nên dùng git blame để tìm chính xác ai đã sửa file (đây là công cụ có sẵn), rồi DM hoặc tag đích danh người đó với một câu hỏi trọn vẹn. Nếu không biết dùng git blame, thì tối thiểu cũng nên hỏi trong kênh mà không tag ai, hoặc chỉ @here nếu thật sự cần người online. @channel chỉ dành cho những thông báo mà cả 120 người đều cần biết ngay.

Bài học: Mỗi lần tag toàn kênh, hãy tự hỏi: "Có bao nhiêu người trong số này thật sự cần bị làm phiền vì tin này?" Nếu câu trả lời là "một hoặc hai người", thì đừng dùng @channel.

Tình huống 3: Kênh support biến thành mớ hỗn độn vì không dùng thread

Một team platform (khoảng 25 kỹ sư) có kênh #platform-support để các team khác vào hỏi khi gặp sự cố hạ tầng. Ban đầu mọi người trả lời thẳng vào kênh chính. Vào giờ cao điểm, có ba, bốn sự cố được hỏi cùng lúc, và các câu trả lời đan xen nhau. Có lần một bạn nhận nhầm hướng dẫn khắc phục của sự cố khác, suýt xóa nhầm một database staging.

Diễn giải: Team platform ra một quy ước cứng: mỗi yêu cầu hỗ trợ là một tin nhắn gốc, mọi trao đổi liên quan phải nằm trong thread của tin nhắn đó. Họ còn thêm quy ước dùng emoji làm trạng thái: 👀 nghĩa là "đã có người nhận xử lý", ✅ nghĩa là "đã giải quyết xong". Nhìn lướt qua kênh là biết ngay việc nào đang mở, việc nào đã đóng, việc nào chưa ai đụng tới.

Bài học: Thread không chỉ giúp kênh gọn gàng, mà còn ngăn ngừa lỗi nghiêm trọng do nhầm lẫn ngữ cảnh. Kết hợp thread với emoji-trạng-thái tạo ra một hệ thống theo dõi công việc nhẹ nhàng mà cực kỳ hiệu quả, không cần thêm công cụ nào.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng ngay mỗi khi định gửi một tin nhắn trong team chat:

• Trước khi gõ, tự hỏi: "Đây có nên là một câu hỏi không?" Nhiều khi bạn có thể tự tìm câu trả lời trong docs, trong tin nhắn cũ (dùng chức năng search), hoặc bằng git blame. Tự tìm trước thể hiện sự chủ động và tiết kiệm thời gian cho cả hai.

• Tag đúng người, đúng liều lượng. Tag đích danh người bạn cần. Tránh @channel/@here trừ khi thật sự khẩn và liên quan số đông.

Mẹo vàng — Tự viết một "channel guideline" ngắn. Nhiều team hiệu quả có một tin nhắn ghim ở đầu mỗi kênh, nêu 4-5 quy tắc: dùng thread, viết full câu hỏi, ý nghĩa các emoji, khi nào được @channel. Đây là cách rẻ nhất để cả team đồng bộ hành xử. Bạn không cần là quản lý mới làm được điều này — chỉ cần đề xuất trong buổi retro là đủ.

Mẹo — Tôn trọng "quyền được ngắt kết nối". Đừng mong người khác trả lời ngoài giờ làm việc, và cũng đừng tự tạo áp lực phải luôn online. Một team lành mạnh coi việc offline sau giờ làm là bình thường. Nếu bạn buộc phải gửi tin ngoài giờ, hãy dùng chức năng "schedule send" (hẹn giờ gửi) của Slack để tin đến vào sáng hôm sau.

Bài tập thực hành

• Viết lại một tin nhắn "hi-only". Nghĩ về lần gần nhất bạn (hoặc ai đó) mở đầu bằng "hi, hỏi tí được không?". Viết lại nó thành một tin nhắn trọn vẹn theo nguyên tắc nohello: có bối cảnh, việc đã thử, câu hỏi cụ thể, và ghi chú mức độ khẩn.

• Kiểm toán lịch sử tag của bạn. Vào Slack/Discord, tìm những lần gần nhất bạn dùng @channel hoặc @here. Với mỗi lần, tự đánh giá: có thật sự cần làm phiền cả kênh không? Nếu không, lẽ ra bạn nên tag ai?

• Soạn một channel guideline mẫu. Viết một đoạn 5 dòng quy tắc chat cho một kênh giả định #backend-team gồm 30 người. Bao gồm ít nhất: quy tắc dùng thread, quy tắc viết full câu hỏi, và quy ước ý nghĩa của hai emoji trạng thái do bạn tự chọn.

Chat là kênh giao tiếp bạn dùng nhiều nhất trong tech team, nên cách bạn ứng xử trên đó ảnh hưởng trực tiếp đến hiệu suất và mối quan hệ của cả nhóm. Sáu quy tắc vàng cần khắc cốt ghi tâm: (1) viết trọn câu hỏi ngay từ đầu, đừng chỉ "hi" rồi chờ; (2) coi chat là bất đồng bộ, đừng đòi phản hồi tức thì; (3) dùng thread để giữ kênh gọn gàng; (4) tag có chủ đích, dè chừng @channel`; (5) định dạng code và log cho dễ đọc; (6) gom một thông điệp vào một tin nhắn. Những quy tắc này không phải chuyện lịch sự hình thức — chúng là biểu hiện của sự tôn trọng thời gian và sự tập trung của người khác, và là dấu hiệu rõ ràng của một kỹ sư chuyên nghiệp. Điều tuyệt vời là etiquette có thể học và dạy rất nhanh: chỉ cần một tin nhắn ghim, một buổi standup nhắc nhở, hay một link nohello.net, cả team có thể thay đổi thói quen chỉ trong một tuần. Hãy bắt đầu từ chính bạn, và bạn sẽ sớm thấy các cuộc trao đổi trong team trở nên nhanh gọn và dễ chịu hơn hẳn.