Cách Điều Hành Nhóm Kỹ Thuật Async-First
Cẩm nang thực tế để điều hành nhóm kỹ thuật async-first: từ chuẩn mực giao tiếp đến các nghi thức ra quyết định thực sự hiệu quả.
By Ellis Keane · 2026-04-06
Khi điện báo xóa sổ buổi briefing hàng ngày
Năm 1844, Samuel Morse gửi bức điện báo đầu tiên giữa Washington và Baltimore, và trong vòng một thập kỷ, các doanh nghiệp từng dựa vào briefing qua người đưa tin hàng ngày đã bắt đầu vận hành theo cách khác. Không phải vì họ muốn trở thành "telegraph-first" (chẳng ai nói điều đó), mà vì ràng buộc đã thay đổi. Thông tin có thể di chuyển nhanh hơn ngựa, vì vậy các nghi thức được xây dựng xung quanh ngựa dần trở nên không cần thiết.
Sự tương đồng với việc điều hành nhóm kỹ thuật async-first thật đáng lo ngại vì quá trực tiếp. Chúng ta có Slack, Linear, GitHub, Notion và khoảng bảy công cụ khác di chuyển thông tin với tốc độ của webhook – thế nhưng hầu hết các nhóm vẫn tổ chức ngày làm việc của mình xung quanh các nghi thức đồng bộ được thiết kế cho thời điểm bạn phải ở cùng phòng để chia sẻ ngữ cảnh: standup hàng ngày nơi mọi người đọc Jira ticket cho người quản lý vốn đã có cùng bảng đó mở trên màn hình thứ hai; "quick sync" kéo dài 45 phút vì ba người chia sẻ màn hình tuần tự trong khi mọi người khác kiểm tra điện thoại.
Đối với nhóm kỹ thuật nhỏ như chúng tôi – bốn người trải rộng ba múi giờ – nhận ra rằng ràng buộc đã thay đổi là phần dễ. Xây dựng lại các nghi thức mất nhiều thời gian hơn.
Nhóm kỹ thuật async-first thực sự trông như thế nào
Async-first trong kỹ thuật có nghĩa là chế độ giao tiếp mặc định của nhóm là bất đồng bộ. Các quyết định được ghi lại bằng văn bản. Trạng thái hiển thị mà không cần hỏi. Ngữ cảnh được tài liệu hóa ở nơi mọi người có thể tìm thấy theo lịch của họ. Các cuộc họp vẫn diễn ra, nhưng chúng là ngoại lệ bạn chọn tham gia, không phải mặc định bạn phải chọn thoát.
Điều này không có nghĩa là không ai bao giờ nói chuyện theo thời gian thực – điều đó sẽ vô lý và thành thật mà nói, hơi cô đơn. Các buổi đánh giá thiết kế, giải quyết xung đột, phiên brainstorming và các cuộc thảo luận kiến trúc tinh tế nơi bạn cần đọc ngôn ngữ cơ thể và vẽ lên bảng vẫn duy trì đồng bộ – và điều đó ổn. Sự phân biệt là chế độ nào bạn tiếp cận trước khi cần truyền đạt điều gì đó, và đối với hầu hết mọi thứ trong nhóm kỹ thuật, câu trả lời nên là ghi lại thay vì lên lịch cuộc gọi – vì một bình luận Linear được viết tốt lúc 14:00 ở Brooklyn vẫn hoàn toàn dễ đọc lúc 9:00 ở Berlin sáng hôm sau.
Async-first không có nghĩa là async-only. Nó có nghĩa là mặc định của bạn là bất đồng bộ, và bạn cố ý chọn giao tiếp đồng bộ khi tình huống thực sự yêu cầu.
Bốn trụ cột (nghe có vẻ hiển nhiên cho đến khi bạn thử)
Trong năm qua, chúng tôi đã xây dựng Sugarbug với tư cách là nhóm bốn người trải rộng Bờ Đông Hoa Kỳ và Châu Âu, và những thứ thực sự khiến nhóm kỹ thuật async-first của chúng tôi hoạt động không phải là công cụ hay chính sách – mà là thói quen. Đây là bốn thói quen đã bám rễ.
1. Ghi lại quyết định ngay nơi chúng xảy ra
Hầu như không ai làm điều này một cách nhất quán. Một quyết định được đưa ra trong luồng Slack. Ai đó nói "ok đi với phương án B." Và rồi... nó sống ở đó. Trong một luồng thực tế không thể tìm thấy sau ba tuần.
Cách khắc phục không phải là nhật ký quyết định (ít nhất không phải là chính yếu). Cách khắc phục là một chuẩn mực: bất kỳ ai đưa ra quyết định cuối cùng đều viết một câu tóm tắt về những gì đã quyết định và tại sao, trong công cụ nơi công việc tồn tại. Nếu bạn quyết định thay đổi định dạng phản hồi API, bản tóm tắt đó đặt trong Linear issue hoặc mô tả GitHub PR, không phải trong luồng Slack hoặc bản ghi cuộc họp mà không ai xem lại.
Chúng tôi học được điều này theo cách tốn kém: Một PR nằm chờ review ba ngày vì người review không biết chúng tôi đã quyết định sử dụng server-side rendering cho trang đó – quyết định bị chôn vùi trong luồng Slack từ tuần trước, và không ai ghi vào issue. Người review để lại sáu bình luận về các đánh đổi client-side hydration đã được giải quyết rồi, tác giả bực bội, và chúng tôi mất phần lớn một tuần cho cuộc trò chuyện đáng ra chỉ mất mười giây nếu ngữ cảnh được gắn vào công việc ngay từ đầu.
Sau đó, chúng tôi ngừng cố gắng duy trì một tài liệu quyết định riêng biệt (vốn hoạt động khoảng hai tuần trước khi trở thành thêm một thứ không ai cập nhật) và bắt đầu ghi quyết định trực tiếp vào issue. Mười giây nỗ lực, và nó tồn tại vì được gắn với công việc, không nổi lềnh bềnh trong một meta-document không ai kiểm tra.
2. Làm cho trạng thái hiển thị, không phải được báo cáo
Đối với nhóm chúng tôi, cuộc họp cập nhật trạng thái là nghi thức đồng bộ tốn kém nhất – mỗi người kể những gì đã làm hôm qua và sẽ làm hôm nay trong khi mọi người khác nửa nghe nửa không và chờ đến lượt mình. Trong nhóm async-first, trạng thái phải là thứ bạn có thể thấy, không phải thứ ai đó phải nói cho bạn biết.
Điều này có nghĩa là công cụ quản lý dự án của bạn cần thực sự phản ánh thực tế. Nếu một Linear issue ở trạng thái "In Progress", đó phải là vì ai đó đang thực sự làm việc với nó ngay bây giờ, không phải vì họ chuyển nó vào đó hôm thứ Hai và chưa chạm vào kể từ đó. GitHub PR nên có tiêu đề mô tả và issues được liên kết. Các file Figma nên có tên rõ ràng cho biết cái gì đang được thực hiện so với cái gì đã được phê duyệt.
Điều gì làm cho trạng thái hiển thị
- PR được liên kết với issues – Bất kỳ ai cũng có thể thấy code nào ánh xạ với nhiệm vụ nào
- Đặt tên branch rõ ràng –
feat/user-onboarding-flow nói nhiều hơn fix-stuff
- Cập nhật trạng thái issue – Di chuyển ticket khi công việc thực sự di chuyển, không phải trong standup
- Tóm tắt tuần được viết – Một người viết digest, mọi người đọc async
Điều gì giữ trạng thái vô hình
- Chỉ cập nhật bằng lời nói – Thông tin biến mất ngay khi cuộc họp kết thúc
- Cuộc họp trạng thái là hệ thống lưu trữ – Nếu không nói trong standup, nó không xảy ra
- Bảng lỗi thời – Bảng Kanban chưa được chạm vào từ thứ Hai
- Ngữ cảnh bị khóa trong DM – Hai người biết, mọi người khác đoán
3. Xác định cửa sổ phản hồi, không phải thời gian phản hồi
Một trong những lo lắng tinh tế hơn về giao tiếp async là sự chờ đợi không có điểm kết thúc. Bạn gửi tin nhắn và không biết liệu sẽ nhận được phản hồi sau hai mươi phút hay vào chiều hôm sau. Sự không chắc chắn tệ hơn sự trễ thực tế.
Giải pháp không phải là yêu cầu phản hồi nhanh hơn (điều đó chỉ tái tạo lại văn hóa đồng bộ với các bước bổ sung). Đó là đặt ra kỳ vọng rõ ràng về cửa sổ phản hồi cho các loại giao tiếp khác nhau. Đối với nhóm chúng tôi, nó trông đại khái như thế này:
- Tin nhắn Slack trong kênh công khai: Trong vòng 4 giờ làm việc
- PR review: Trong vòng một ngày làm việc
- Bình luận Linear issue: Trong vòng một ngày làm việc
- DM được đánh dấu khẩn cấp: Trong vòng 1 giờ trong giờ làm việc
- Mọi thứ khác: Trong vòng 2 ngày làm việc
Các cửa sổ cụ thể ít quan trọng hơn thực tế là chúng tồn tại và mọi người đã đồng ý. Khi nhịp điệu rõ ràng, sự lo lắng "họ có thấy điều này không?" tan biến, và mọi người ngừng gửi ping theo dõi sau ba mươi phút im lặng.
4. Bảo vệ thời gian đồng bộ cho những gì thực sự cần nó
Điều chúng tôi không mong đợi: các cuộc họp chúng tôi giữ lại trở nên tốt hơn đáng kể. Khi cuộc họp là ngoại lệ thay vì mặc định, mọi người đến đã chuẩn bị và tham gia tích cực vì họ biết đây là cửa sổ duy nhất để cùng nhau giải quyết vấn đề.
Chúng tôi giữ ba loại cuộc họp đồng bộ:
- Đồng bộ nhóm hàng tuần (tối đa 30 phút) – Không phải cập nhật trạng thái, mà là các vấn đề cản trở, mối lo ngại xuyên suốt và các cuộc trò chuyện kiểu "có ai khác nghĩ quyết định kiến trúc này sẽ cắn lại chúng ta không?"
- Đánh giá thiết kế – Một số thứ thực sự cần phản hồi trực quan đồng bộ
- Phiên lập trình theo cặp – Khi hai người bị kẹt, nói chuyện trực tiếp vẫn nhanh hơn trao đổi async
Mọi thứ khác từng là cuộc họp đã trở thành đề xuất bằng văn bản, video Loom, hoặc luồng bình luận trên issue liên quan. Lịch của chúng tôi chuyển từ trông giống trò chơi Tetris sang thứ gì đó một con người thực sự có thể làm việc xung quanh – điều mà, hóa ra, chính là toàn bộ mục đích của việc có lịch.
stat: "3 cuộc họp/tuần" headline: "Giảm từ 12" source: "Lịch thực tế của nhóm chúng tôi sau khi chuyển sang async-first"
Phần không ai cảnh báo bạn
Phần khó của async-first không phải là chuẩn mực giao tiếp hay thiết lập công cụ. Đó là sự điều chỉnh cảm xúc. Khi chúng tôi bỏ standup hàng ngày, một trong những kỹ sư của chúng tôi đề cập đến cảm giác "tội lỗi kỳ lạ" khi bắt đầu làm việc sâu lúc 10 giờ sáng mà không check-in với ai trước. Người khác nói sự im lặng trên Slack trước buổi trưa cảm giác như không ai đang làm việc, mặc dù GitHub hiển thị các commit đổ về mỗi giờ.
Đây là phần bản chất con người của vấn đề, và không có giải pháp ở cấp hệ thống. Điều giúp chúng tôi là thẳng thắn về nó. Chúng tôi nói về thực tế là async đôi khi có thể cảm thấy cô đơn, và hoàn toàn ổn khi gọi điện chỉ vì muốn nói chuyện với con người về vấn đề bạn đang giải quyết. Chuẩn mực không phải là "đừng bao giờ gọi," mà là "đừng yêu cầu cuộc gọi cho những thứ không cần nó."
Một số người trong nhóm thực sự thích tương tác đồng bộ nhiều hơn, và việc đáp ứng điều đó không phải là thất bại của triết lý async-first – đó là nhận ra rằng sở thích giao tiếp mang tính cá nhân, và việc tuân thủ cứng nhắc bất kỳ chế độ nào cũng là dạng rối loạn chức năng riêng của nó.
Phần khó không phải là thiết lập quy trình async. Đó là làm quen với sự im lặng giữa các tin nhắn, và tin tưởng rằng đồng đội của bạn đang làm việc ngay cả khi bạn không thể thấy họ làm. attribution: Ellis Keane
Làm cho nó bám rễ: 30 ngày đầu
Nếu bạn đang chuyển đổi nhóm hiện tại sang mô hình nhóm kỹ thuật async-first, tháng đầu tiên là nơi nó sẽ bén rễ hoặc lặng lẽ sụp đổ trở lại thành "hãy cùng nhảy vào một cuộc gọi nhanh." Đây là những gì hiệu quả với chúng tôi theo dạng timeline sơ bộ:
Tuần 1: Viết ra các chuẩn mực giao tiếp. Theo nghĩa đen – một tài liệu một trang nêu rõ "đây là cách chúng tôi giao tiếp, đây là cửa sổ phản hồi kỳ vọng, đây là những gì đảm bảo cuộc họp." Chia sẻ nó, thảo luận đồng bộ (vâng, có sự mỉa mai), và nhận được sự đồng thuận.
Tuần 2: Hủy hoặc chuyển đổi ba cuộc họp định kỳ. Chọn những cuộc rõ ràng nhất là cập nhật trạng thái được ngụy trang và thay thế bằng định dạng bằng văn bản. Đừng hủy mọi thứ cùng một lúc – mọi người cần tăng dần, không phải nhảy vực.
Tuần 3: Kiểm tra vệ sinh công cụ của bạn. Các Linear issue có thực sự được cập nhật không? Mô tả PR có hữu ích không? Các quyết định có được ghi lại ở nơi công việc diễn ra không? Nếu không, đây là tuần để thiết lập những chuẩn mực đó. Chỉ định ai đó làm "async champion" nhẹ nhàng nhắc nhở khi quyết định xảy ra bằng lời nói nhưng không được ghi lại.
Tuần 4: Retrospective (async, tất nhiên). Gửi một biểu mẫu đơn giản: "Điều gì đang hoạt động? Điều gì không? Bạn nhớ điều gì?" Câu trả lời sẽ làm bạn ngạc nhiên – một số người sẽ thích sự yên tĩnh, những người khác sẽ gặp khó khăn. Điều chỉnh chuẩn mực dựa trên phản hồi thực tế, không phải lý thuyết.
- [x] Viết tài liệu chuẩn mực giao tiếp
- [x] Xác định cửa sổ phản hồi cho từng kênh
- [ ] Hủy hoặc chuyển đổi 3 cuộc họp trạng thái
- [ ] Kiểm tra vệ sinh công cụ (issues, PR, tài liệu quyết định)
- [ ] Chỉ định async champion cho quá trình chuyển đổi
- [ ] Tổ chức async retrospective sau 30 ngày
- [ ] Điều chỉnh chuẩn mực dựa trên phản hồi của nhóm
Khi async-first là lựa chọn sai
Async-first không phù hợp trong một số tình huống phổ biến. Nếu nhóm của bạn là ba người ngồi trong cùng một văn phòng, giao tiếp đồng bộ có lẽ ổn và chi phí chính thức hóa các chuẩn mực async sẽ là giải quyết vấn đề bạn không có. Tương tự, nếu nhóm của bạn đang trong cuộc khủng hoảng thực sự – production sập, một lần ra mắt quan trọng đang cận kề, hoặc bạn đang pivot hướng sản phẩm – đó là lãnh thổ đồng bộ, và giả vờ ngược lại sẽ là giáo điều hơn là thực dụng.
Async-first hoạt động tốt nhất cho các nhóm phân tán theo múi giờ, các nhóm lớn hơn khoảng năm người (nơi sự bùng nổ tổ hợp của phối hợp đồng bộ bắt đầu gây đau), và các nhóm thích ship code hơn là kể lại những gì họ đã ship trong một cuộc họp về những gì họ đã ship. Nếu đó là bạn, khoản đầu tư vào chuẩn mực async sẽ hoàn vốn trong tháng đầu tiên, chủ yếu trong các giờ kỹ thuật được phục hồi từng biến mất vào "tổ hợp công nghiệp họp hành."
Điện báo không loại bỏ cuộc trò chuyện trực tiếp – nó chỉ làm cho chuyến đi đưa tin hàng ngày trở nên không cần thiết. Đó là tất cả những gì async-first làm cho một nhóm kỹ thuật: nó cho nghỉ hưu các nghi thức chỉ tồn tại vì các công cụ chưa kịp bắt kịp, và bảo vệ các cuộc trò chuyện thực sự quan trọng.
Câu hỏi thường gặp
Q: Làm thế nào để xử lý code review trong nhóm kỹ thuật async-first? A: Thiết lập SLA review rõ ràng (của chúng tôi là một ngày làm việc) và để mô tả PR gánh phần lớn công việc – giải thích không chỉ những gì đã thay đổi mà còn tại sao, liên kết issue liên quan và đánh dấu bất cứ điều gì người review nên tập trung vào. Nguyên nhân thất bại async-review lớn nhất là PR nằm chờ ba ngày vì người review cần ngữ cảnh chỉ tồn tại trong đầu ai đó. Ghi lại hoặc trả giá sau.
Q: Sugarbug có hỗ trợ quy trình async-first không? A: Nó giúp với vấn đề cụ thể về ngữ cảnh bị phân mảnh qua các công cụ – quyết định trong Slack, nhiệm vụ trong Linear, bình luận thiết kế trong Figma. Sugarbug kết nối những tín hiệu đó để trạng thái hiển thị mà không cần ai phải kể trong cuộc họp. Đó không phải là cách duy nhất để giải quyết vấn đề đó (bạn cũng có thể rất kỷ luật trong việc cross-link mọi thứ thủ công), nhưng chúng tôi xây dựng nó vì đã chán với phiên bản thủ công.
Q: Sai lầm lớn nhất các nhóm mắc phải khi chuyển sang async-first là gì? A: Xem đây là thay đổi chính sách thay vì thay đổi thói quen. Bạn có thể viết một tài liệu "chuẩn mực giao tiếp" đẹp đẽ, nhưng nếu mọi người không thực sự cập nhật Linear issue hoặc ghi quyết định vào PR, bạn chỉ loại bỏ cuộc họp mà không thay thế luồng thông tin. Các chuẩn mực phải trở thành bộ nhớ cơ bắp, mất khoảng một tháng nhắc nhở nhẹ nhàng, nhất quán.
Q: Làm thế nào để xử lý sự cố production khẩn cấp trong nhóm async-first? A: Bạn không xử lý chúng theo async – đó là toàn bộ điểm của "async-first, không phải async-only." Xác định một con đường leo thang rõ ràng: kênh Slack chuyên dụng hoặc PagerDuty cho các trường hợp khẩn cấp thực sự, với sự hiểu biết rằng mọi thứ khác tuân theo cửa sổ phản hồi bình thường. Sự phân biệt quan trọng là giữa "khẩn cấp" (production sập) và "tôi muốn câu trả lời ngay bây giờ" (thường là thiếu kiên nhẫn, không phải khẩn cấp).
Q: Sugarbug có thể thay thế hoàn toàn các cuộc họp standup không? A: Nó có thể thay thế phần thu thập thông tin – nghi thức "mọi người đã làm gì hôm qua?" – vì ngữ cảnh đó đã chảy qua GitHub, Linear và Slack. Những gì nó không thể thay thế là phần kết nối con người, đó là lý do tại sao chúng tôi vẫn giữ đồng bộ tuần ngắn cho các cuộc trò chuyện được hưởng lợi từ việc ở trong cùng (ảo) phòng.
Nhận trí tuệ tín hiệu được gửi thẳng đến hộp thư của bạn.