3 nghi thức họp giúp team nhỏ tránh trễ deadline
Team càng nhỏ, mỗi buổi họp thừa càng đắt — vì không có ai để “họp hộ” khi một người vắng mặt. Nhưng team nhỏ cũng dễ trễ deadline vì thiếu tín hiệu sớm: không ai họp bàn tiến độ cho tới khi đã muộn. Ba nghi thức dưới đây là những gì mình thấy đáng giữ lại, sau khi đã cắt bỏ khá nhiều cuộc họp không cần thiết khác.
1. Daily blocker check-in — 10 phút, chỉ nói về vướng mắc
Không phải standup kiểu “hôm qua làm gì, hôm nay làm gì” — kiểu đó dễ biến thành báo cáo tiến độ chung chung, tốn thời gian mà không đổi được gì. Format mình dùng chỉ có một câu hỏi: “có gì đang chặn bạn không?” Nếu không có, người đó nói “không” và xong trong 15 giây. Nếu có, cả team dành đúng thời gian đó để quyết định ai gỡ vướng, không giải quyết chi tiết ngay tại chỗ (việc đó để sau cuộc họp, giữa những người liên quan).
Lý do nghi thức này quan trọng: hầu hết deadline trễ không phải vì ước lượng sai, mà vì một vướng mắc nhỏ bị im lặng 3-4 ngày trước khi ai đó biết để giúp. Check-in hàng ngày giảm thời gian phát hiện vướng mắc từ “vài ngày” xuống “tối đa 24 giờ”.
2. Weekly scope-cut review — quyết định cắt gì, không phải thêm gì
Cuộc họp tuần phổ biến thường xoay quanh “còn thiếu gì, cần làm thêm gì” — nhưng với deadline cố định, câu hỏi đúng hơn là “nếu tuần này không kịp, phần nào cắt được mà không phá vỡ giá trị cốt lõi?” Mình dành 20-30 phút mỗi tuần để nhìn lại scope còn lại so với thời gian còn lại, và chủ động đánh dấu “nice-to-have” có thể cắt trước khi bị ép cắt trong tuần cuối.
Điểm khác biệt so với review tiến độ thông thường: quyết định cắt được đưa ra sớm, trong trạng thái bình tĩnh, chứ không phải trong hoảng loạn 2 ngày trước hạn — lúc đó quyết định thường tệ hơn nhiều.
3. Single-owner deadline retro — một người chịu trách nhiệm, không phải “cả team cùng rút kinh nghiệm chung chung”
Sau mỗi deadline (kịp hoặc trễ), mình tổ chức một buổi ngắn nhưng có một quy tắc: mỗi nguyên nhân trễ (hoặc suýt trễ) phải gắn với một người chịu trách nhiệm theo dõi hành động khắc phục cụ thể — không phải “cả team rút kinh nghiệm” chung chung rồi quên. Ví dụ: nếu nguyên nhân là ước lượng sai một hạng mục kỹ thuật, người phụ trách kỹ thuật đó ghi lại cụ thể sẽ ước lượng khác đi thế nào lần sau, không phải cả team cùng ký vào một câu “sẽ ước lượng kỹ hơn”.
Nghi thức này hiệu quả vì retro không gắn chủ sở hữu thường tạo ra danh sách hành động không ai thực sự làm. Gắn một người, một hành động cụ thể, dễ theo dõi ở check-in tuần sau. Cách tiếp cận này gần với nguyên tắc Show Progress trong Shape Up của Basecamp — thấy rõ việc gì đang tắc sớm, thay vì chỉ hỏi “tiến độ sao rồi”.
Điểm chung
Cả ba nghi thức đều ngắn, có mục tiêu rõ ràng, và tồn tại để tạo tín hiệu sớm — phát hiện vướng mắc sớm, cắt scope sớm, sửa nguyên nhân sớm — thay vì chỉ để báo cáo. Với team nhỏ, đó là khác biệt giữa việc trễ deadline một cách bất ngờ, và việc thấy nó đến từ xa đủ sớm để xử lý.