Comm. at work: Vài tình huống yes/ no

Hôm trước tôi có hẹn ăn trưa với một đồng nghiệp cũ, làm cùng nhau từ những năm 2014, giờ làm việc ở Duy Tân, cũng gần. Chuyện nhà cửa, con cái linh tinh rồi tôi hỏi bạn ít chuyện công việc. Giờ bạn cũng đã làm quản lý, bạn chia sẻ rằng có một điểm yếu mà phần lớn các team members người Việt đều mắc phải đó là “trình bầy kém”. Tôi gật gù…

Chuyện “trình bầy kém” thì bản thân tôi cũng trải nghiệm nhiều. Nhiều nhất là khi dự án phát sinh vấn đề, có khi PO (Product owner) cả ngày chỉ đi loanh quanh hỏi team các chi tiết khác nhau để cố gắng xào nấu lại thành câu trả lời cho PM phía Nhật bản cũng hết thời gian. Có khi hỏi mãi mà không có câu trả lời nào, phải đi giục giã. Nhiều khi ngược lại, có rất nhiều câu trả lời nhưng chúng không ăn nhập gì với nhau và thậm chí dường như cũng chẳng ăn nhập gì với câu hỏi !!!

Để thấy việc hỏi đáp trong công việc, nhất là khi có vấn đề xảy ra cũng không phải chuyện đơn giản. Cũng biết các team members thường yếu khoản trình bầy nên PO thường được hướng dẫn đặt câu hỏi sao cho người được hỏi dễ trả lời nhất. Trên lý thuyết các câu hỏi đóng là dễ trả lời nhất (chỉ phải trả lời yes/no) và PO phải có khả năng đặt ra chuỗi câu hỏi yes/ no để khám phá các khía cạnh của vấn đề. Đứng trước các vấn đề phức tạp, PO sẽ dùng các câu hỏi dạng đóng tức câu hỏi Yes/No lồng nhau theo chuỗi. Điều này nghĩa là PO phải đảm nhiệm phần khó khăn hơn là hình dung các kịch bản và đặt câu hỏi yes/ no để lần ra kịch bản đúng.

(Kỹ thuật này cũng được coi là hữu hiệu khi thăm dò ý kiến khách hàng. Thay vì đưa cho khách hàng câu hỏi mở, các PO thường được khuyến khích đưa ra các options cụ thể để khách hàng chỉ việc lựa chọn và như thế dễ có được phản hồi nhanh chóng từ khách)

Trên lý thuyết là thế, nhưng thực tế thì sao?

Bài viết sẽ đưa ra hai ví dụ thực tế để bạn đọc cùng thử cảm nhận mức độ challenge trong việc giao tiếp. Ngoài ra, người viết cũng thử đưa ra gợi ý để sửa câu trả lời cũng như cách làm sao để tiến lên với tình huống giao tiếp đang diễn biến mông lung.

Tình huống 1:

Infra: Github has problem. We can not using github action right now. It will effect the release production today. Below is the update status from github

PM: !!! oh… current status means recovered?

Infra: Degraded meaning they know problem.

PM: !!!

Có thể thấy trong ví dụ trên, mặc dù câu hỏi của PM là yes/no question nhưng người được hỏi không trả lời Yes mà cũng chẳng trả lời No 🙂 Với cách trả lời kiểu này, người hỏi sẽ phải đoán xem ý người trả lời là gì. Và phán đoán thì không hay vì ở đây người hỏi cần dựa vào người trả lời nhưng người trả lời lại bắt người hỏi phải đoán và như thế tình huống hỏi đáp với mục tiêu ban đầu là tìm hiểu sự thật (fact – finding) trở thành một tình huống thử thách kiến thức! Thêm nữa là phán đoán thì có thể sai với ý định thật sự của câu trả lời và đó cũng là lúc xuất hiện rủi ro hiểu nhầm, miscommunication.

Ở đây, cách sửa câu trả lời đơn giản nhất là người trả có thể giữ nguyên câu trả lời như trên, nhưng thêm Yes/ No vào đầu câu. Cụ thể với tình huống này, phương án đơn giản nhất sẽ là:

Degraded meaning they know problem. 

—>

No, Degraded meaning they know problem. 

.Phương án sửa có tâm hơn một chút sẽ là nhắc lại một phần của câu hỏi:

Degraded meaning they know problem. 

—>

No, current status is not recovered yet. Degraded meaning they know problem. 

Tình huống 2:

PO: Giả sử sau này bên đó mà muốn chạy trên infra khác Dejavu ở Gitlab server thì bạn ý nghĩ là cần phải change cái Docker Image hoặc nội dung của Docker Image, nếu thế thì phải đối ứng ra sao?

Infra: Tùy từng trường hợp sẽ có giải pháp khác nhau. Deploy lên server, deploy lên aws batch…

PO: cái Docker image phải change hoặc sửa nội dung như bạn ý nghĩ là đúng rồi đúng ko?

Infra: Sẽ sửa lại CI config, sửa lại sang Dockerfile khác cùng script khác.

Với câu trả lời như trên, người hỏi sẽ lại phải tiếp tục phải đoán ít nhiều 🙂

Vậy giả sử ở vào tình huống tương tự như trên, khi người trả lời vẫn kiên quyết không trả lời Yes/ No cho dễ hiểu thì người hỏi lúc này có thể làm gì để tiếp tục tiến lên? Có hai phương hướng chủ yếu.

.Một là tiếp tục hỏi lại để xác nhận:

VD: Câu trả lời của bạn có phải là “Đúng, phải thay Docker image/ sửa nội dung của Docker image” đúng ko? Bạn xác nhận giúp nhé.

.Hai là phải thay đổi hẳn sang cách hỏi khác, thay đổi cách tiếp cận, chẳng hạn như đi vào hỏi một trường hợp cụ thể:

VD: Vậy giả sử như về sau bạn ấy muốn chạy trên infra abcd thì bạn ấy cần sửa lại cụ thể ở những file nào và như thế nào? bạn có thể cung cấp một cái ví dụ sửa trực quan luôn được không?

Và dù chọn cách nào, cuối cùng đừng quên tìm cách góp ý trực tiếp với bạn kia về cách trả lời mình mong muốn, có thể gợi ý khéo bằng link đến bài viết này chẳng hạn 😉

Tất nhiên, cái gì một khi đã quen thì khó sửa. Bạn có thể comment một hai lần với người trả lời, nhờ họ trả lời rõ Yes/ No nhưng cũng không hy vọng mọi thứ sẽ cải thiện được ngay, vì thế hãy kiên nhẫn 🙂

Thực ra có thể tôi hiểu được phần nào lý do các bạn không trả lời trực tiếp vào câu hỏi yes/no. Trong cuộc sống hằng ngày, có những câu hỏi trực tiếp “…. tôi nói vậy có đúng không?” và nhiều người chọn phương án trả lời mềm dẻo, không đưa ra kết luận đúng sai mà chỉ cung cấp thêm thông tin tham khảo để người hỏi tự hiểu ra. Trong cuộc sống thì cách xử lý đó được đánh giá là khôn ngoan, mềm dẻo, tránh được tranh luận, vừa tránh làm người đặt câu hỏi bẽ mặt vừa không làm xấu đi mối quan hệ.

Tuy nhiên công việc không phải là cuộc sống. Công việc có những ưu tiên của nó và sự trung thực với khách hàng, sự cấp thiết cần đánh giá đúng tình hình phải được đặt lên hàng đầu khi xảy ra vấn đề. Cuộc sống không có SLO (Service level objective), SLA (Service level agreement) còn công việc thì có. Cách trả lời gián tiếp có thể là khôn ngoan trong cuộc sống nhưng lại có thể tạo thêm “khổ” trong công việc. Do đó ta không thể áp dụng máy móc cách trả lời trong công việc như trong cuộc sống.

Bonus thêm một tình huống cuối bài, bạn thử tự sửa câu trả lời xem sao

(cũng khá dễ nhỉ 🙂 )

PO:  Có phải kết quả trong show output sẽ được thực thi ngay vào giờ họ setting trong schedule của …. ko?

Member: Kết quả trong show output không liên quan đến schedule ạ

Cảm ơn bạn đã đọc bài và hẹn gặp lại !