🫥 "Đi họp về tay không" – và bài học từ những cuộc họp trống rỗng

Chào mọi người, lại là Taiyang với những câu chuyện dở khóc dở cười trong ngành IT mà mình nghĩ chắc ai làm nghề cũng từng va phải một vài lần ^^.
Chủ đề hôm nay mình muốn chia sẻ liên quan đến việc đi họp với khách hàng cả tiếng đồng hồ, nhưng rốt cuộc… chẳng mang được output gì về cho team offshore.

Hình dung như kiểu:


❌ Ủa… họp xong rồi mà mình vẫn chưa rõ khách muốn gì???
❌ Cứ tưởng hôm nay chốt xong, ai ngờ nói vòng vòng cả buổi, cuối cùng vẫn chưa biết expected requirement của khách hàng???
❌ Nội dung thì cứ trôi tuột từ tai này sang tai kia, mà đến khi kết thúc cũng không có recap, không rõ action tiếp theo là gì, stakeholder nào phụ trách ra sao???

Có những ngày mình cảm thấy cực kỳ stress và vật vã với những buổi họp kéo dài cả tiếng đồng hồ, nhưng không mang được một thông tin nào rõ ràng về cho team. Và tệ nhất là: chính mình là người control buổi họp, nhưng cũng không chắc đã hiểu khách muốn gì.

 

💥 Lúc đó mình mới nhận ra: vấn đề không hẳn nằm ở khách nói mơ hồ, mà nằm ở cách mình điều phối và dẫn dắt cuộc họp.

 

🎭 Có phải vì là BrSE non-tech nên chỉ cần ngồi nghe và truyền đạt lại cho PM, thế là xong?

Thú thật, hồi đầu mình từng nghĩ vậy. Vì không có background kỹ thuật, mình cho rằng mình không thể phân tích hay tư vấn sâu như PM hoặc technical leader.
Nên mình chọn “無難な選択 / phương án an toàn”: chỉ cần nghe khách nói gì, dịch lại cho team, coi như hết trách nhiệm.

Nhưng thực tế cho thấy, cách làm đó giống như đi họp mà… thả trôi con thuyền theo dòng nước.
Khách nói tới đâu thì mình theo tới đó, requirement càng lúc càng mở rộng, còn dự án thì không có định hướng rõ ràng.

👉 Kết quả:

  • Mình đi họp nhiều nhưng càng họp càng mông lung

  • Dev ngồi chờ input mà không biết bắt đầu coding từ đâu

  • QA test nhầm vì rule cuối cùng chưa bao giờ được chốt rõ ràng

 

🎯 Làm BRSE, muốn họp có output thì phải làm chủ được luồng họp.

Dưới đây là một vài tips giúp mình cải thiện:

  1. Soạn trước Agenda – và gửi cho khách/team
    → Giúp cuộc họp có “xương sống”
    → Dù khách lan man, mình vẫn kéo về được đúng chủ đề

  2. Ghi chú real-time + recap ngay trong họp
    → Không đợi đến cuối buổi mới recap, mà nên confirm ngay từng điểm đang bàn luận.

    Mình thường dùng 2 mẫu dưới đây để chốt ý lại với khách hàng.
    「〇〇について、△△と認識しておりますが、あっていますでしょうか。」
    (Về vấn đề 〇〇, tôi đang hiểu là △△, không biết có đúng không ạ?)

 

Hoặc:

先ほどのご説明をもとに、内容をまとめました。
ご認識に誤りがないか、ご確認をお願いいたします。
(Tôi đã tóm tắt lại nội dung base trên phần giải thích vừa rồi, nhờ anh xem giúp tôi có hiểu sai chỗ nào không?)

 

  1. Luôn có slide hoặc file chia sẻ màn hình
    → Không để họp chỉ là “nói miệng”
    → Note trực tiếp vào đó, giúp cả team cùng thấy và tránh việc quên hoặc hiểu sai

  2. Chốt rõ ràng Deliverable
    → Ai làm gì? Deadline nào? Input nào?
    → Nếu không có deliverable thì buổi họp đó coi như… trắng tay

 

📚 Checklist “Đi họp để có kết quả”

Trước khi họp:

  • Soạn agenda các đầu mục confirm dưới dạng gạch đầu dòng

  • Xác định mục tiêu: “Buổi này cần chốt nội dung A, B,... ”

  • Chuẩn bị sẵn Q&A lists, các vấn đề còn lấn cấn & mơ hồ

  • Nếu nội dung confirm có logic phức tạp chồng chéo, hãy vẽ dưới dạng hình sơ đồ matrix hoặc hình ảnh dễ hình dung.

Trong khi họp:

  • Share màn hình để các bên dễ theo dõi

  • Recap miệng cho từng phần, confirm ngay tại chỗ

  • Note real-time nhanh bằng keyword, tuyệt đối tránh việc "để đấy note sau" lại quên đấy.

Sau khi họp:

  • Gửi recap/meeting note trong ngày

  • Đính kèm action list: ai phụ trách task nào, deadline cụ thể

  • Follow up thường xuyên với người chịu trách nhiệm

 

🚨 Đi họp không phải để ngồi nghe cho xong
Đi họp là để:

  • Làm rõ điều chưa rõ

  • Chốt điều còn mơ hồ

  • Và ra quyết định cụ thể

Nếu không chuẩn bị – không dẫn dắt – không ghi lại, thì:
💸 Bạn đã mất 1 giờ để thu về… 0 đồng giá trị.

 

🌐 Chia sẻ tình huống thực tế của tuôi ^^

Họp chốt rule tính phí – nhưng lại hiểu sai expected vì quên confirm recap

Có lần họp với khách để chốt rule tính phí dịch vụ. Họ nói rất nhiều, vòng vo: “nếu company A thì công thức này, còn company B thì công thức khác”…
Lúc nghe thì mình cũng gật gù liên tục, nghĩ là đã hiểu hết, nên… không recap lại rule cuối cùng.

👉 Kết quả: team mất 1 tuần code + test, sau đó khách reject toàn bộ vì sai expected.

Thực ra, dự án chạy theo mô hình B2B, nên có nhiều công ty tham gia. Nhưng logic chỉ đơn giản:

  • Nếu công ty thuộc đối tượng dùng hợp đồng X → tính theo công thức A

  • Ngược lại → tính theo công thức B

Chỉ vậy thôi, nhưng team đã mất 1 tuần cho một sai sót nhỏ.

Sau lần đó, mình rút ra bài học: phải recap ngay trong họp.
Ví dụ:
「今回の料金計算について、基本ルールはAで、特例がBという認識ですが、よろしいでしょうか？」
(Về việc tính phí lần này, tôi hiểu rule cơ bản là A, và trường hợp ngoại lệ là B, có đúng không ạ?)

 

👉 Sau những lần “lạc trôi” cùng dòng suy nghĩ của khách, mình mới thấm rằng BrSE – dù non-tech – vẫn phải giữ vai trò người cầm lái, đưa cuộc họp quay lại đúng quỹ đạo của dự án. Không chỉ lắng nghe mà còn cần biết chắt lọc, hệ thống hóa và định hướng cuộc họp theo một barem chuẩn chỉnh và rõ ràng.

Cuối cùng, làm BrSE non-tech không phải là “chỉ nghe rồi nhắn lại”, mà là biết biến thông tin rời rạc thành cầu nối vững chắc giữa khách hàng và team. Và đó mới chính là giá trị thực sự của vai trò này.

 

#ITstorytelling #chuyệnngànhIT #BrSEsharing