Cùng một việc nhưng phải họp đi họp lại nhiều lần: Lý giải nguyên nhân cốt lõi
Có những đầu việc tưởng như đã được thống nhất, nhưng chỉ ít ngày sau lại phải họp lại. Không phải vì ai làm sai hoàn toàn, mà vì mỗi người đang hiểu “xong” theo một cách khác nhau.
Mỗi cuộc họp bổ sung thêm một góc nhìn, một yêu cầu mới, hoặc một điều chỉnh nhỏ. Công việc cứ thế bị kéo dài qua nhiều vòng họp, trong khi không ai thực sự có thể chốt lại rằng: việc này bao giờ thì hoàn thành.
Khi cùng một việc phải họp đi họp lại nhiều lần, đó không phải là dấu hiệu của sự cẩn thận, mà là dấu hiệu cho thấy tiêu chuẩn hoàn thành chưa từng được xác định rõ ràng ngay từ đầu.
Hiện tượng vòng lặp “họp bản nháp” – Khi không ai dám nói “thế là xong”
Trước khi đào sâu, hãy nhận diện kiểu họp mà chúng ta đang nói đến.
Cuộc họp “bản nháp” (draft meeting) vs cuộc họp “chốt” (final meeting)
Hãy tưởng tượng bạn viết một báo cáo. Bạn có hai lựa chọn:
- Viết bản nháp: Bạn viết ra ý tưởng, gửi cho mọi người xem, nhận góp ý, rồi sửa, rồi lại gửi, cứ thế lặp lại.
- Viết bản chốt: Bạn ngồi lại với nhóm, thống nhất dàn ý, tiêu chí, và phong cách trước khi viết. Sau đó bạn viết một bản hoàn chỉnh đáp ứng đúng những tiêu chí đó, và gửi đi như bản cuối cùng.
Trong quản lý dự án, đa số các cuộc họp của chúng ta là “họp bản nháp”. Chúng ta gặp nhau, thảo luận về một việc, nhưng thay vì đưa ra một quyết định ràng buộc (“Làm theo cách A. Xong.”), chúng ta lại kết thúc bằng những câu mơ hồ: “Cứ làm thử đi rồi xem sao”, “Tạm thế đã, mai bàn tiếp”, hay “Ừ, được đấy, nhưng có lẽ nên xem xét thêm…”.
Dấu hiệu nhận biết bạn đang trong vòng lặp họp lại
Làm sao để biết bạn đang trong vòng luẩn quẩn này?
- Câu cửa miệng sau họp: “Để em làm thử rồi anh xem sau.” – Đây không phải là giao việc, mà là lời hứa về một cuộc họp tiềm năng trong tương lai.
- Trao đổi riêng tái diễn: Ngay sau khi họp xong, mọi người lại nhắn tin, gọi điện riêng để “làm rõ thêm” chính điều vừa bàn. Điều này chứng tỏ cuộc họp chung đã thất bại trong việc tạo ra sự rõ ràng.
- Tiến độ ì ạch vì “chờ họp”: Công việc bị treo với lý do “Chờ họp lại với bên X để rõ hơn yêu cầu.” Họp không còn là công cụ thúc đẩy, mà là vật cản.
Khi bạn thấy những dấu hiệu này, vấn đề không nằm ở nội dung công việc. Nó nằm ở cách thức chúng ta giao việc và ra quyết định.
Nguyên nhân 1: Không có “tiêu chí hoàn thành” cụ thể ngay từ lúc giao việc
Đây là lỗi gốc đầu tiên và phổ biến nhất. Hãy nhớ lại lần cuối bạn giao một việc. Bạn đã nói gì?
“Lan ơi, em làm cái banner cho sự kiện ra mắt sản phẩm nhé.”
“Dũng này, anh viết content cho trang giới thiệu công ty đi.”
Nghe có vẻ ổn. Nhưng hãy nhìn kỹ: Bạn đã giao một hành động (làm banner, viết content), chứ không giao một kết quả với tiêu chuẩn rõ ràng.
Hậu quả của việc giao việc mơ hồ
Khi Lan nhận nhiệm vụ “làm banner”, trong đầu cô ấy sẽ lập tức xuất hiện một loạt câu hỏi không lời đáp:
- Banner kích thước bao nhiêu?
- Phong cách màu sắc thế nào? Có theo brand guideline không?
- Cần những thông tin gì trên đó? Logo, slogan, ngày giờ, hashtag?
- “Xong” nghĩa là gửi file PSD, file JPG, hay cả hai?
Vì không có đáp án, Lan buộc phải đoán. Cô ấy sẽ làm theo cách hiểu, kinh nghiệm và sở thích cá nhân. Và khi mang bản thiết kế đến cho bạn xem, xác suất cao là nó sẽ không trúng ý bạn. Thế là bạn nói: “Ồ, không phải thế. Anh muốn nó phải thế này cơ…” Và thế là một cuộc họp “sửa sai” được triệu tập.
Bài học: Một nhiệm vụ không có “Definition of Done” (Định nghĩa Hoàn thành) rõ ràng thì gần như chắc chắn sẽ phải làm lại. Họp lặp ở đây không giải quyết vấn đề phức tạp; nó chỉ là công cụ để phát hiện ra sự mơ hồ mà đáng lẽ phải được làm rõ từ đầu.
Nếu team bạn thường họp để hỏi thông tin, xem ngay: Vì sao đã họp nhưng bạn vẫn không biết ai đang làm việc gì?
Nguyên nhân 2: Mỗi bên hiểu “xong” theo một cách khác nhau (và không có chuẩn chung để đối chiếu)
Ngay cả khi bạn nghĩ mình đã nói rõ, sự “rõ ràng” của bạn chưa chắc đã giống với sự “rõ ràng” của người khác. Trong một dự án, mỗi vai trò có một cách hiểu khác về việc hoàn thành.
Hãy lấy ví dụ về một task “Sửa lỗi đăng nhập”:
- Với Developer: “Xong” = Code đã sửa, commit lên repository, không báo lỗi khi chạy local.
- Với Tester: “Xong” = Lỗi đã không còn tái hiện, đã test trên 3 trình duyệt và 2 thiết bị di động.
- Với Product Owner (PO): “Xong” = Người dùng có thể đăng nhập thành công, trải nghiệm mượt mà, và giao diện không bị vỡ.
Bạn thấy vấn đề chưa? Nếu không có một checklist chung được thống nhất, Developer có thể báo “xong” khi hoàn thành tiêu chí của anh ấy, nhưng Tester và PO sẽ nói “chưa xong” vì tiêu chí của họ chưa được đáp ứng. Điều này dẫn đến tình huống:
Developer: “Em fix xong lỗi đăng nhập rồi anh.”
Tester: “Nhưng em test thấy button bị lệch trên mobile.”
PO: “Và tốc độ load sau khi login vẫn còn chậm.”
Developer: “??? Mấy cái đó có trong yêu cầu đâu?”
Và thế là, thay vì một email báo cáo hoàn thành, bạn lại nhận được một lịch mời họp “Để thống nhất lại về việc sửa lỗi đăng nhập.”
Bạn đang họp lặp vì công việc phức tạp, hay đơn giản là vì bạn chưa biết… khi nào thì không nên họp? Sự khác biệt giữa một điều phối giỏi và một người chỉ biết lên lịch họp nằm ở câu trả lời này. Tìm hiểu ngay trong bài viết chuyên sâu: “Khi nào thì thực sự cần họp?“.
Nguyên nhân 3: Quyết định trong họp không được “gắn chặt” vào đầu việc
Giả sử bạn đã có một cuộc họp khá tốt. Mọi người đã thống nhất: “Banner sẽ có nền xanh dương, chữ trắng, kích thước 1200x630px, có logo góc trái.”
Bạn ghi chép điều này vào sổ tay hoặc một file biên bản cuộc họp chung có tên “Biên bản họp ngày 10/10”.
Nhưng điều gì xảy ra ba ngày sau, khi Lan mở task “Làm banner” trên hệ thống quản lý công việc? Task đó vẫn chỉ có dòng mô tả cũ: “Làm banner cho sự kiện ra mắt.” Những thống nhất quan trọng trong cuộc họp đã bị tách rời khỏi chính công việc cần thực hiện.
Chúng nằm trong một tài liệu khác, ở một nơi khác. Để nhớ lại, Lan phải đi tìm biên bản, lục lại đoạn chat, hoặc… hỏi lại bạn. Và nếu cô ấy nhớ nhầm (ví dụ: nhớ thành kích thước 1000x500px), thì sản phẩm sẽ sai, và lại dẫn đến một cuộc họp sửa chữa.
Hệ thống lý tưởng phải làm được điều này: Mọi thảo luận, ý kiến đóng góp, file đính kèm tham khảo, và QUYẾT ĐỊNH CUỐI CÙNG phải được lưu lại ngay trên chính task đó, trong phần comment hoặc description. Task phải là “nguồn sự thật duy nhất” về mọi thứ liên quan đến nó.
Khám phá toàn bộ phương pháp Chấm dứt tình trạng “mạnh ai nấy chạy”: Gắn kết đội ngũ vào một mục tiêu duy nhất.
Nguyên nhân 4: Thay đổi yêu cầu “lén lút” và không được quản lý
Dự án là một thực thể sống, thay đổi là điều bình thường. Vấn đề không nằm ở việc có thay đổi, mà nằm ở cách thay đổi đó được ghi nhận và truyền đạt.
Hãy xem tình huống này:
Sau khi giao task “Viết content trang giới thiệu”, bạn nhận được tin nhắn từ giám đốc marketing: “Nhớ thêm một đoạn về giải thưởng công ty mới nhận được vào cuối bài nhé.”
Bạn chuyển tiếp tin nhắn đó cho Dũng – người viết content.
Điều gì xảy ra?
- Yêu cầu thay đổi này không được cập nhật vào mô tả chính thức của task. Task vẫn giữ nguyên: “Viết content trang giới thiệu.”
- Một tuần sau, Dũng gửi bài. Bạn đọc và thấy thiếu đoạn về giải thưởng. Bạn hỏi: “Sao không có phần giải thưởng?” Dũng ngơ ngác: “Phần nào ạ? Anh có nói đâu?”
Lúc này, sự hiểu lầm đã xảy ra. Bạn nghĩ Dũng cẩu thả. Dũng nghĩ bạn thay đổi liên tục. Và giải pháp “nhanh nhất” là… họp lại để “làm rõ” (mà thực chất là để đổ lỗi và tranh cãi).
Thay đổi được thông báo qua kênh không chính thức (tin nhắn riêng, email rời rạc, nói miệng) mà không được chính thức hóa vào task gốc chính là “kẻ giết người” thầm lặng, tạo ra vô số cuộc họp lặp không cần thiết.
Nếu bạn cần giải pháp giảm họp hành mà vẫn chạy dự án hiệu quả, hãy xem: Làm cách nào giảm họp hành mà không làm đứt gãy dự án?
Kết luận: Phá vỡ vòng lặp bằng cách định nghĩa “Xong” trước khi bắt đầu
Vậy, câu trả lời cho “Vì sao cùng một việc nhưng phải họp đi họp lại nhiều lần?” thật ra rất rõ ràng:
Chúng ta họp lại vì lần họp đầu tiên (và cách giao việc ban đầu) đã thất bại trong việc tạo ra một điểm kết thúc rõ ràng, được mọi người đồng thuận và ghi nhận.
Họp lặp là “chi phí phát sinh” cho việc thiếu chuẩn bị, thiếu tiêu chuẩn, và thiếu một hệ thống lưu trữ quyết định minh bạch.
Để thoát khỏi vòng luẩn quẩn này, bạn cần chuyển đổi từ văn hóa “họp để sửa sai” sang văn hóa “thống nhất rõ rồi hãy làm”. Hãy thực hiện ba bước đơn giản nhưng cực kỳ mạnh mẽ:
- Bước 1. Tạo “Định nghĩa Hoàn thành” cho MỖI task quan trọng: Trước khi giao việc, hãy cùng người thực hiện và các bên liên quan lập một checklist nhỏ, cụ thể, có thể kiểm chứng được. *”Banner được coi là xong khi: (1) Kích thước 1200x630px, (2) File PSD + JPG, (3) Có đủ logo, tên sự kiện, ngày giờ, (4) Được PO và Trưởng phòng Marketing duyệt.”
- Bước 2. Biến task thành “nguồn sự thật duy nhất”: Sử dụng phần mềm quản lý công việc để gắn chặt mọi thứ vào task. Mọi thảo luận, file tham khảo, và đặc biệt là QUYẾT ĐỊNH CUỐI CÙNG (“Làm theo phương án A”) phải được ghi lại ngay trong comment hoặc description của task đó. Đừng để thông tin bị chìm trong biên bản họp chung.
- Bước 3. Quản lý thay đổi một cách chính thức: Bất kỳ yêu cầu thay đổi nào sau khi task đã được giao, phải được xử lý như một “phiên bản mới”. Cập nhật trực tiếp vào mô tả task (và ghi chú rõ “CẬP NHẬT NGÀY 12/10: Thêm yêu cầu…”), hoặc tạo một task con mới liên kết với task gốc. Tuyệt đối không để thay đổi tồn tại dưới dạng tin nhắn riêng lẻ.
Khi bạn thực hiện được điều này, cuộc họp đầu tiên sẽ trở thành cuộc họp để chốt tiêu chuẩn. Và những lần trao đổi sau đó sẽ chỉ là việc đối chiếu kết quả với tiêu chuẩn đã thống nhất (“Anh check xem banner đã đủ 4 điều kiện trong Định nghĩa Hoàn thành chưa?”). Nếu đủ, công việc được đóng lại. Nếu không đủ, bạn biết chính xác cần sửa cái gì, mà không cần phải mở một cuộc họp mới toanh.
Bạn sẽ họp ít hơn, nhưng mỗi cuộc họp sẽ có trọng lượng và giá trị gấp bội. Đó mới là dấu hiệu của một điều phối dự án thực sự chuyên nghiệp.
Bạn có hình dung được một ngày làm việc mà không có những cuộc họp ‘sửa sai’ lặp đi lặp lại này không? Một ngày mà mọi yêu cầu đều rõ ràng từ đầu, tiến độ được cập nhật tức thì, và bạn có thể tin tưởng rằng ‘xong’ nghĩa là thực sự hoàn thành?
Điều đó hoàn toàn khả thi khi bạn có một hệ thống quản lý công việc đủ thông minh để ‘ép’ bạn và team làm việc có kỷ luật hơn ngay từ khâu giao việc. Optimi Work không chỉ là một phần mềm, đó là một phương pháp giúp bạn xây dựng văn hóa ‘rõ ràng ngay từ đầu’.
Hãy bắt đầu sự thay đổi bằng một buổi TRẢI NGHIỆM DEMO MIỄN PHÍ. Chúng tôi sẽ chỉ cho bạn thấy cách cụ thể.
Để hiểu toàn diện về chiến lược giúp team bạn thoát khỏi “bẫy” họp hành liên miên, hãy xem bản đồ tổng thể: Chiến lược “Họp không cần họp”: Giảm tải họp hành cho điều phối dự án từ gốc rễ.