một lần họp action meeting

“Khi chúng ta đi làm thì ngoài thời gian làm việc ra thì họp hành là thứ chiếm nhiều thời gian nhất” là một nhận định phổ biến và cũng là thực tế mà nhiều người làm việc trong các lĩnh vực khác nhau cảm nhận được.

Nhiều bạn trẻ không thích họp hành. Không chỉ họp hành, những thứ như viết báo cáo, viết operation note (ghi chú vận hành), viết tài liệu kỹ thuật … thoạt đầu với các bạn đều là các công việc giấy tờ/ thủ tục/ paper work, đều ngại và chỉ làm vì bị bắt phải làm.

Đã thế đợt này công ty tăng cường quản lý, yêu cầu phải họp buổi sáng rồi cuối ngày lại họp tổng kết tình hình. Member phải tự cập nhật trạng thái công việc lên Slack … Manager thì phải check (kiểm tra) tiến độ, hỏi han có khó khăn gì, có giữ được lịch trình cam kết không? …

📍 Tình hình mới như kiểu đặt ra một mục tiêu kép cho các Manager:

• .vừa phải nhanh chóng đối ứng để team thích nghi với các yêu cầu nâng cao về báo cáo, giải trình, tạo tài liệu vận hành, lưu vết/ lưu evidence …. trong công việc,
• . vừa phải giữ quy trình làm việc tương đối ổn định để tăng năng suất của team!

Không muốn gia tăng áp lực họp hành lên member nên nhiều khi dù liên tiếp có các yêu cầu đột xuất từ trên áp xuống phải rà soát abcd, giải trình lại xyz,… nhưng Manager cũng cố gắng tự tìm hiểu trước rồi giải quyết nhanh gọn với một vài thành viên, tránh việc gì cũng yêu cầu cả team họp đột xuất.

Trong bối cảnh đó, vào một ngày nọ, ở dự án của A.
Lúc này đã sắp hết Sprint, chỉ còn một ngày là kết thúc, chuẩn bị lên kế hoạch cho các tác vụ tiếp theo.

💢 Trong buổi họp sáng khi xác nhận công việc thì xẩy ra tình huống hơi toang. Sau một hồi trao đổi với Dev. team, QA, PM kết luận là task X đang được thực thi sai so với yêu cầu. Trên file quản lý chung task X đã đánh dấu Done nhưng khi PM kiểm tra lại phiên bản QA đã test cho X thì lại không đúng như mong đợi của PM!

💢 Thêm kha khá nữa lời qua tiếng lại của team thì Manager nghe cũng dần nắm được đại khái vấn đề:

• .Task X có bối cảnh là một lỗi (bug) do chính PM tự phát hiện ra,
• .PM đã chụp lại ảnh và mô tả hiện tượng bug trên Slack, sau đó
• . PM yêu cầu QA phụ trách tạo task sửa (fix) bug, task này chính là task X.

theo phân công, QA chịu trách nhiệm phát hiện bug và tạo task fix bug, trong đó mô tả hiện tượng cũng như mong muốn sửa bug rồi giao cho Dev. team. Vì thế yêu cầu tạo task của PM đối với QA trong trường hợp này cũng là hợp lý.

Tiếp theo PM và team (gồm Dev. và QA) cũng trực tiếp cùng nhau so lại yêu cầu ghi trong task với hệ thống (đã được fix bug) rồi cả mô tả hiện tượng trên Slack của PM. Thêm nhiều ý kiến/ nhận xét và bầu không khí cũng trở nên căng thẳng hơn. Hồi sau thì các ý kiến phản bác lẫn nhau lúc đầu cũng dần hội tụ về 2 điểm chính:

• .Dev. đã làm đúng theo mô tả task X mà QA tạo, điều này là chắc chắn, có điều,
• . khả năng cao là trong nội dung task thì QA đã mô tả sai yêu cầu từ PM (hiểu lầm)

💢 Việc để mis-communication (hiểu lầm) phát sinh là một điều hết sức không mong muốn và thông thường sẽ có rất nhiều thứ mà Manager yêu cầu team phải ngồi lại họp để cùng phân tích, mổ xẻ, thống nhất nguyên nhân và cách xử trí …

Tuy nhiên, lần này thì deadline đã cận kề, ưu tiên lớn nhất vẫn là giữ được tiến độ đã cam kết. PM nêu rõ quan điểm task X phải quay lại trạng thái To do và yêu cầu team làm lại.

Dev. team nói sẽ cần thời gian tương đương làm mới và như thế không xong được trong Sprint (còn có 1 ngày).

Tình hình càng căng thẳng khi PM khẳng định không thể lùi được vì đã đến hạn đóng gói cho khách hàng test, yêu cầu team làm thêm giờ (OT) để giải quyết vấn đề.

Căng thẳng leo thang khi PM và Dev. team tiếp tục phản bác lẫn nhau về kế hoạch tiếp theo.

Thấy đã hết giờ họp, Manager lúc đó lên tiếng hỏi Dev. team trước tiên có thể tập trung toàn lực giải quyết task X theo yêu cầu của PM, chấp nhận dừng toàn bộ các task khác được không? Đến đây Dev. team cân nhắc và nói có thể tập trung toàn bộ nhân lực vào task X được nếu như requirement (Yêu cầu) được làm rõ và được chốt! Nghe thế Manager hơi bất ngờ vì cả nhóm trao đổi tập trung từ sáng đến giờ nhưng hoá ra vẫn chưa thống nhất cụ thể được là làm thế nào mới đúng yêu cầu của PM!

🎯 Dù thế, đến giờ ngẫm lại thì A. thấy có vẻ câu hỏi nêu trên đã góp phần thay đổi tình hình. Với câu hỏi này Dev. team đã suy nghĩ và đưa ra Điều kiện để tiến lên thay vì dừng lại ở Lý do không giữ được lịch.

Trước tình hình phức tạp nhưng cũng nhận thấy cơ hội để giải quyết, Manager quyết định yêu cầu team vào phòng họp luôn để cùng tháo gỡ điểm nghẽn trước mắt: làm rõ Yêu cầu lại lần nữa cho task X. Vốn có kinh nghiệm điều phối nhiều cuộc thảo luận quan trọng, Manager yêu cầu team sử dụng bảng vẽ để cùng làm rõ.

May thay, vào phòng họp rồi thì Tech lead Dev. chủ động liệt kê các case (trường hợp xử lý) lên bảng, xác nhận vấn đề và cách giải quyết mà PM hình dung. PM và QA ngồi xem và tham gia ý kiến vào hình vẽ của Dev.. Manager hối thúc PM và QA cùng lên bảng, cầm bút và bổ sung, xác nhận trực tiếp lên hình vẽ của Dev.

Với đà teamwork như vậy, sau khoảng 20 phút họp thì Dev. trả lời Manager là đã làm rõ được yêu cầu mới từ PM cho task X. PM sau đó cũng chấp nhận ý kiến của Manager là sẽ tạo task X’ mới, bỏ task cũ.

📍 Điểm nghẽn đã được cởi bỏ nhưng mục đích giữ deadline thì vẫn còn bỏ ngỏ. Manager hỏi lại Dev. với tình hình mới nhất thì toàn bộ Dev. team có tập trung giải quyết task X’ trong ngày (theo lịch ban đầu) được hay không? Dev. trả lời sẽ cố gắng nhưng cũng chưa chắc chắn 100%, vẫn có rủi ro lùi lịch (delay). Đến đây, Manager tung nốt quân bài cuối: Đề xuất làm thêm giờ có giới hạn, nghĩa là nhờ team OT thêm 1 tiếng trong ngày (nếu vẫn không xong thì có thể về), trước khi về thì nhờ team cố gắng hết mức có thể. Kết quả là Dev. team đồng ý tất cả Dev. OT 1 tiếng, còn QA thì tuỳ tình hình mà quyết định.

Cuộc họp kết thúc lúc tầm 10:25, lúc Manager về chỗ thì thấy cả Dev. team đã vào việc, pair cùng nhau xử lý task X’ luôn.

📍Đến 11 giờ, Dev. team đã revert lại hệ thống ở phiên bản cũ (có bug mà PM đã phát hiện) theo yêu cầu của PM, tức là bỏ phần đã làm sai yêu cầu đi. QA cũng đã tạo task X’ mới, xác nhận lại lần nữa với PM để đảm bảo mô tả lần này đã đúng, sau đó tự cập nhật vào file quản lý chung.

📍Đến quãng 14 giờ, Manager ra hỏi han thì QA nói đang test rồi, tức là bên Dev. đã làm xong task X’ theo yêu cầu mới và đẩy lên môi trường test. Về cơ bản Dev. đã tìm được cách xử lý chính xác yêu cầu mới và hoàn thành trước mấy tiếng so với hình dung ban đầu, cuối ngày cũng không cần phải OT gì cả, task hoàn thành và Sprint hầu như không bị ảnh hưởng gì.

Bài học mà Manager rút ra ở đây là khi có sự tập trung và huy động được sự quyết tâm của team thì Productivity tốt hơn. Và đôi khi để làm được điều đó thì một cuộc họp là cần thiết.

🧩 Khi cần hướng mọi người đồng tâm hiệp lực, nếu có thể giữ cho cuộc họp ngắn gọn và đi thẳng vào đối diện trực tiếp với vấn đề thì bản thân việc họp hành không phải là vấn đề. Không những thế một cuộc họp “tốt” còn có thể trở thành chìa khoá (key event) để giải quyết hiệu quả sự cố phát sinh trong dự án.

Hẹn gặp lại các bạn ở tình huống tiếp theo 🎭