Giao tiếp trong công việc

Chào mọi người, mình lại quay lại với series “Biết vậy thì đã…”.

Concept của series này khá đơn giản. Mình thử rồi, hy vọng mọi người biết trước để không phải tự thử sai giống mình.

Bài này không hẳn nói về Technology hay Technical. Nhưng nó lại liên quan đến một thứ mà gần như ngày nào đi làm chúng ta cũng phải dùng đến: giao tiếp.

Nếu nói đơn giản thì giao tiếp là chuyện mình truyền một thông tin nào đó đến người khác. Có thể bằng cách nói chuyện, nhắn tin, viết tài liệu, trình bày, vẽ một cái Diagram, gửi một cái Screenshot... miễn sao người bên kia hiểu được mình đang muốn nói gì. Nghe thì đơn giản. Nhưng đi làm rồi mới thấy, giao tiếp có khi còn khó hơn cả việc code.

Là Software Engineer, chúng ta thường nghĩ công việc của mình là nhận một Problem rồi biến nó thành một thứ chạy được trên hệ thống. Nhưng từ lúc nhận Problem cho đến lúc mọi thứ chạy ổn, gần như bước nào cũng có Communication ở đó.

Mình phải nói chuyện với người trong team, với QA, với PM, với những team khác, đôi khi với cả những người chẳng làm Tech. Và càng làm lâu, mình càng nhận ra một chuyện. Không phải cứ mình nói đúng là người khác sẽ hiểu.

Approach

Có một thứ mình mất khá lâu mới nhận ra, đó là không phải tình huống nào cũng nên giao tiếp theo cùng một cách.

Có những chuyện chỉ cần nhắn một tin là xong. Có những chuyện nên viết thành Document để người khác đọc lúc nào cũng được. Nhưng cũng có những chuyện nếu cứ nhắn qua nhắn lại thì mất cả tiếng, trong khi kéo nhau vào một cuộc Meeting 15 phút là xong.

Mình thường chia khá đơn giản.

Nếu chuyện không gấp, không cần người kia trả lời ngay thì cứ để Asynchronous. Nhắn tin, viết Email, mở Ticket, tạo PR, viết Document hoặc thậm chí quay một đoạn Video giải thích cũng được.

Còn nếu chuyện cần trao đổi qua lại ngay lúc đó thì Meeting hoặc Call sẽ hợp lý hơn.

Quan trọng là chọn đúng cách.

Ví dụ có một câu hỏi nhỏ mà mình có thể viết trong hai dòng thì đừng kéo cả team vào một Meeting.

Ngược lại, nếu hai bên đã nhắn qua lại 30 phút mà vẫn không hiểu nhau thì có lẽ nên Call.

Có những thứ nói bằng miệng rất khó.

Nhưng chỉ cần mở Excalidraw lên, vẽ vài cái Box, vài cái Arrow là mọi người hiểu ngay.

Mình dùng cách này khá nhiều trong công việc.

Nhiều lúc nhìn một cái Diagram còn nhanh hơn nghe mình giải thích 10 phút. 😄

Biết mình đang nói chuyện với ai

Đây có lẽ là một trong những thứ quan trọng nhất.

Trong một Project, mỗi người có một Background khác nhau.

Mình là Developer nên có thể một số thứ với mình là quá bình thường. Nhưng với PM thì chưa chắc. Với Business thì càng chưa chắc.

Ngược lại, có những thứ Business nói với mình là hiển nhiên nhưng mình lại chẳng hiểu gì nếu họ không giải thích thêm.

Vì vậy trước khi giải thích một vấn đề gì đó, mình thường cố nghĩ một chút.

Người này đang cần biết đến đâu?

Họ cần hiểu Concept thôi hay cần hiểu cả Implementation?

Nếu họ chỉ cần biết hệ thống đang gặp vấn đề gì thì không cần giải thích luôn cả Architecture.

Nếu họ phải trực tiếp làm việc với phần đó thì lúc ấy mới cần đi sâu hơn.

Không phải cái gì mình biết cũng cần nói hết.

Có một câu mình khá thích:

Know when to go deep, know when to hold breadth.

Biết lúc nào nên đi sâu, và lúc nào chỉ cần nói ở mức tổng quan.

Biết lúc nào nên hỏi

Khi nghe người khác nói, kiểu gì mình cũng sẽ có lúc nảy ra câu hỏi.

Nhưng không phải câu hỏi nào cũng cần hỏi ngay.

Ví dụ Daily hay Stand-up thường chỉ có một khoảng thời gian rất ngắn. Nếu câu hỏi của mình không liên quan trực tiếp đến phần đang nói thì có thể note lại, đợi sau Meeting rồi hỏi riêng.

Vừa đỡ mất thời gian của cả team, vừa không làm câu chuyện đi sang một hướng khác.

Hồi mới đi làm mình khá ngại hỏi.

Sợ người khác nghĩ mình không biết.

Làm lâu rồi mới nhận ra một chuyện khá buồn cười.

Càng làm lâu thì mình càng bớt sợ hỏi.

Vì đôi khi không hỏi mới là thứ làm mình mất nhiều thời gian nhất.

Viết mọi thứ xuống

Khi mình làm một việc đủ lâu, trong đầu sẽ có rất nhiều thứ. Mình biết tại sao hệ thống được thiết kế như vậy. Biết tại sao không chọn cách khác. Biết chỗ nào dễ lỗi. Biết những Edge Case nào từng xảy ra. Nhưng nếu tất cả những thứ đó chỉ nằm trong đầu mình thì người khác làm sao biết được?

Đến lúc KT cho người khác mà không có Document, cả hai bên đều mệt.

Mình phải ngồi giải thích lại từ đầu.

Người nhận cũng phải cố nhớ.

Trong khi nếu có một cái Document tử tế thì họ có thể tự đọc lại bất cứ lúc nào.

Đó là lý do mình khá thích Documentation.

Nó giúp Knowledge không còn nằm trong đầu một người nữa.

Tất nhiên viết Document cũng tốn thời gian.

Nhưng mình nghĩ đó là một khoản đầu tư khá đáng.

Bây giờ mất một tiếng để viết, sau này có thể tiết kiệm được rất nhiều lần giải thích.

Documentation, theo cách mình nhìn, chính là một cách để Scale kiến thức của mình cho những người khác.

Đừng chỉ tin vào ý tưởng của mình

Có ý tưởng của riêng mình là tốt.

Nhưng đừng mặc định rằng mình đúng.

Đôi khi mình nghĩ một Solution rất hay, nhưng chỉ cần nói chuyện với một người khác là nhận ra còn một đống vấn đề mình chưa nghĩ đến.

Có khi mình sai.

Có khi người kia sai.

Cũng có khi mỗi người đúng một nửa.

Và chính những cuộc trao đổi như vậy mới giúp mình tìm ra một Solution tốt hơn.

Không chỉ Technical Design.

Ngay cả cách mình giao tiếp cũng có thể nhận Feedback.

Có thể hỏi thẳng:

“Như nãy giờ mình giải thích vậy bạn có hiểu không?”

Hoặc:

“Có chỗ nào mình nói chưa rõ không?”

Những câu hỏi rất đơn giản, nhưng đôi khi lại giúp mình nhận ra rất nhiều thứ.

Những gì mình rút ra

Đầu tiên, đừng nghĩ người khác phải biết những gì mình biết chỉ vì họ có nhiều năm kinh nghiệm hơn.

Mình làm một việc trong thời gian dài thì đương nhiên mình sẽ hiểu nó sâu hơn.

Mình sống với Problem đó mỗi ngày.

Mình biết Context.

Mình biết những quyết định trước đây.

Nhưng người khác có thể đang tập trung vào một phần việc hoàn toàn khác.

Họ không có cùng Context với mình.

Vì vậy đừng nghĩ:

“Cái này chắc anh ấy biết rồi.”

Chưa chắc.

Có khi họ thực sự không biết.

Và điều đó hoàn toàn bình thường.

Mình là người Ownership của phần việc đó mà.

Nếu cần thì cứ giải thích.

Nếu chưa rõ thì giải thích lại.

Không có gì phải ngại.

Thứ hai, nếu không gấp thì cứ dùng Asynchronous.

Mình còn việc phải làm, người khác cũng còn việc phải làm.

Không nhất thiết chuyện gì cũng phải kéo nhau vào Meeting.

Một Message có đủ Context đôi khi đã giải quyết được vấn đề.

Thứ ba, nếu thật sự gấp thì cũng đừng gọi người khác ngay lập tức nếu chưa cần.

Có thể hỏi trước:

“Bạn có tiện Call 5 phút không?”

Mình nghĩ đây đơn giản là phép lịch sự.

Đặc biệt với Developer.

Đang code mà bị một cuộc gọi chen ngang rất dễ mất Context.

Đang nghĩ một vấn đề rồi phải dừng lại nghe điện thoại.

Sau đó quay lại còn phải tự hỏi:

“Ủa, nãy mình đang làm đến đâu nhỉ?”

Đó chính là Context Switching.

Và Context Switching không miễn phí.

Nó làm giảm hiệu suất làm việc.

Tất nhiên nếu hệ thống đang cháy thì thôi.

Cứ gọi. 😂

Thứ tư, hạn chế DM nếu đó là một vấn đề liên quan đến công việc.

DM rất tiện.

Nhưng nó cũng có một vấn đề.

Chỉ có hai người biết chuyện gì đang xảy ra.

Hôm nay mình hỏi anh A.

Ngày mai anh A nghỉ.

Ngày kia người khác gặp đúng vấn đề đó thì lại phải hỏi từ đầu.

Nếu có thể, hãy đưa vấn đề vào một Channel, Ticket hoặc nơi mà những người liên quan đều nhìn thấy.

Biết đâu cuối cùng người trả lời mình lại là một người khác.

Và như thế lại càng tốt.

Knowledge của team thì nên nằm ở chỗ team có thể nhìn thấy, thay vì nằm trong một đoạn Chat riêng giữa hai người.

Thứ năm, dùng từ viết tắt cũng được.

Nếu nói chuyện với người mình làm việc cùng hàng ngày thì ASAP, IMO hay những từ tương tự chẳng có gì lạ.

Nhưng nếu nói chuyện với một người mới thì nên để ý một chút.

Không phải ai cũng hiểu những từ mình đang dùng.

Chỉ cần viết thêm vài chữ đôi khi là đủ.

Không cần phải cố làm cho câu nói trông “pro” hơn.

Cuối cùng, nếu workload quá nhiều thì Delegate.

Đi làm là làm theo Team.

Không phải cái gì mình cũng phải tự ôm.

Tự làm thì đúng là vẫn làm được.

Nhưng nếu hai người cùng làm và công việc xong nhanh hơn thì tại sao không?

Delegate không có nghĩa là mình yếu.

Đôi khi nó chỉ có nghĩa là mình biết cách sử dụng nguồn lực của Team.

See the world as it is

Đây là một ý mình khá thích.

Hãy thử nhìn mọi thứ từ góc của người khác.

Nếu mình là họ thì mình sẽ nghĩ gì?

Nếu mình chưa từng dùng Technology này thì sao?

Nếu tiếng Anh không phải ngôn ngữ mẹ đẻ của mình thì sao?

Nếu mình mới vào Team thì sao?

Từ đó mình sẽ biết mình cần Support họ ở đâu.

Điều này không chỉ giúp Communication tốt hơn.

Nó còn liên quan đến Relationship, Leadership và rất nhiều thứ khác trong Career.

Mỗi người có một Background khác nhau.

Có người là Native Speaker.

Có người không.

Có người đã làm với Technology này nhiều năm.

Có người mới nhìn thấy nó lần đầu.

Vậy nên thay vì ném cho họ một đống thứ rồi bảo:

“Tự xử lý đi.”

Mình có thể giúp họ một chút ngay từ đầu.

Có thể họ vẫn sẽ tự làm được.

Nhưng chưa chắc đó là cách hiệu quả nhất.

English Skills

Phần này dành cho những ai quan tâm đến English.

Không quan tâm thì có thể bỏ qua. 😄

Những gì mình viết ở đây là kinh nghiệm mình rút ra sau một thời gian làm việc trong International Company.

Có thời gian mình làm việc ở Thailand, nơi mình dùng cả tiếng Anh và tiếng Thái.

Sau đó sang Tokyo làm việc.

Lần này thì không còn tiếng Thái nữa.

Tiếng Anh gần như trở thành ngôn ngữ chính trong công việc.

Và mình phải làm việc với rất nhiều người đến từ những quốc gia khác nhau.

Lúc đó mình mới nhận ra một chuyện.

Communication không chỉ là chuyện mình muốn nói gì.

Mà còn là chuyện người đang nghe mình là ai.

Không phải mình cứ nói theo cách mình thích rồi mong người khác tự hiểu.

Thực tế không vận hành như vậy.

Basic Grammar Crash Course

Chúng ta học tiếng Anh rất lâu rồi.

Học từ cấp 1, cấp 2, cấp 3 rồi lên đại học.

Và chắc nhiều người từng nghe câu:

“Học tiếng Anh bao nhiêu năm mà cuối cùng có dùng đâu.”

Theo mình, thứ còn thiếu đôi khi không phải kiến thức.

Mà là một môi trường để mình sử dụng nó.

Ở đây mình không định dạy Grammar.

Chỉ muốn chia sẻ một vài thứ mình gặp khá thường xuyên khi đi làm.

Biết từng này chắc chắn chưa đủ để trở thành English Master.

Nhưng theo kinh nghiệm của mình thì nó đã đủ dùng trong rất nhiều tình huống.

Ví dụ khi muốn nói về một sự thật hoặc một việc thường xuyên xảy ra, Present Simple là đủ.

“I assume this service can handle a thousand requests per second.”

Hoặc:

“Normally, Redis works as a cache for the system.”

Khi muốn nói mình đang làm gì thì dùng Present Continuous.

“I’m currently investigating our system.”

Hoặc:

“I’m checking that part.”

Khi nói về một việc đã xảy ra thì dùng Past Simple.

“I told PM about our system limitations.”

Hoặc:

“I saw him at the cafeteria.”

Khi nói về một việc sẽ làm thì dùng Future.

“Our team will deploy the new update next week.”

Hoặc:

“I will inform the QA team about our new logic change.”

Present Perfect thì ban đầu có vẻ hơi khó, nhưng đi làm lại gặp khá thường xuyên.

Ví dụ:

“I have read your design documentation.”

Hoặc:

“I have released a new update since yesterday.”

Còn If thì dân code chắc quá quen rồi.

“If we encounter any technical challenges, we will address them promptly.”

Nó cũng giống như một cái if trong code thôi.

Can, Could, May, Might thì thường dùng khi nói về khả năng hoặc đề nghị một cách mềm hơn.

“I might not know much about this context. Could you explain it to me?”

Hoặc:

“Could you kindly check our inquiry policies?”

Còn nếu muốn xin phép ai đó thì có thể dùng:

“Would you mind if I...?”

Ví dụ:

“Would you mind if I released our latest change this evening?”

Hoặc:

“Would you mind if I applied a circuit breaker for this API call?”

Đại khái là vậy.

Không cần phải biến mỗi câu nói thành một bài Grammar.

Đi làm rồi, mục tiêu cuối cùng vẫn là:

Người kia hiểu mình đang nói gì.

Just Speaking

Có một thứ mà mình nghĩ quan trọng hơn việc biết thật nhiều Grammar.

Đó là dám nói.

Có thể mình nói chưa hay.

Có thể Accent chưa tốt.

Có thể Grammar đôi lúc sai.

Nhưng nếu không nói thì chắc chắn không tiến bộ.

Cứ Try.

Sai thì sửa.

Lần sau thử lại.

Mình từng có những giai đoạn Speaking khá tệ.

Nhưng càng dùng nhiều thì càng tự tin hơn.

Điều thay đổi không phải là một ngày đẹp trời mình tự nhiên nói tiếng Anh như Native Speaker.

Mà là mình không còn quá sợ việc nói sai.

Những gì mình rút ra về English

Từ vựng tất nhiên rất quan trọng.

Biết càng nhiều thì càng có nhiều cách diễn đạt.

Nhưng không cần lúc nào cũng phải dùng những từ thật khó.

Trong công việc, đôi khi một câu đơn giản lại tốt hơn một câu rất “Advanced” nhưng người nghe phải ngồi đoán.

Tech cũng vậy.

Những cụm như Memory Usage hay Upstream Service xuất hiện hàng ngày.

Không cần phải cố thay chúng bằng những từ nghe “xịn” hơn.

Nói sao cho người kia hiểu là được.

Một thứ khác mình thấy khá hữu ích là nói chậm lại.

Không ai đánh giá mình chuyên nghiệp hơn vì mình nói nhanh.

Nói chậm một chút giúp mình có thời gian nghĩ.

Có thể dừng lại lấy hơi.

Có thể nói:

“Give me a moment to think.”

Hoặc:

“Hmm... How can I say this?”

Không sao cả.

“I think” cũng vậy.

Mình từng thấy nhiều nội dung nói rằng không nên dùng “I think” quá nhiều.

Nhưng thực tế đi làm mình nghe nó gần như mỗi ngày.

Native Speaker cũng dùng.

Non Native Speaker cũng dùng.

Vậy nên nếu đó là cụm từ mình quen dùng thì cứ dùng.

Biết thêm cách diễn đạt khác thì càng tốt.

Nhưng đừng vì sợ nói không “hay” mà cuối cùng chẳng dám nói gì.

“Actually” cũng là một từ rất hay gặp.

Nhưng đôi khi nó chỉ là một từ nối.

Nếu mình thấy mình đang dùng nó quá nhiều thì có thể thử dừng lại một chút thay vì cố nhét nó vào câu.

Một chuyện nữa là từ viết tắt.

Dùng thì không có gì sai.

Nhưng hãy nhớ rằng không phải ai cũng biết những từ mình biết.

Trước khi gửi một Message, chỉ cần nghĩ một giây:

“Người này có hiểu từ này không?”

Thế là đủ.

Nhắn tin cũng là một cách tốt để luyện Grammar.

Vì mình có thời gian suy nghĩ.

Viết xong có thể đọc lại.

Xem câu có dễ hiểu không.

Xem Tense có đúng không.

Xem người kia đọc vào có hiểu mình muốn gì không.

Cứ làm nhiều thì tự nhiên sẽ quen.

Một cách học khác mà mình khá thích là quan sát cách người khác nói.

Có những người mình làm việc cùng lâu, họ có những cụm từ rất đặc trưng.

Họ hay mở đầu câu thế nào.

Khi không chắc thì nói gì.

Khi đồng ý thì nói gì.

Khi muốn từ chối thì nói thế nào.

Mình cứ nghe rồi học theo.

Nói thẳng ra là:

Học lỏm. 😂

Không có gì xấu hổ cả.

Ngôn ngữ vốn là thứ mình học từ người khác mà.

Và quan trọng nhất vẫn là:

Dùng thường xuyên.

Try.

Error.

Retry.

Đừng chờ đến lúc Grammar hoàn hảo mới bắt đầu nói.

Cứ nói trước.

Sai thì sửa.

Một thời gian sau tự nhiên sẽ thấy mình tự tin hơn.

Wrap-up

Vậy là hết một bài khá dài về một thứ nghe có vẻ không liên quan lắm đến Tech:

Communication.

Càng đi làm lâu mình càng thấy đây là một thứ rất khó tránh.

Tùy công ty, tùy Team, tùy Project mà chúng ta sẽ phải làm việc với rất nhiều người khác nhau.

Có Cross-team.

Có Team Member.

Có Junior.

Có PM.

Có QA.

Có Business.

Có Customer.

Và mỗi người lại có một cách giao tiếp khác nhau.

Mục tiêu cuối cùng vẫn là làm sao để công việc được bàn giao và triển khai một cách trơn tru nhất có thể.

Mình cũng không nghĩ rằng sau bài này mọi vấn đề Communication sẽ biến mất.

Không đâu.

Vấn đề chắc chắn vẫn đến.

Chỉ là nó nặng hay nhẹ còn tùy vào Project, Team và những người mình làm việc cùng.

😅

Những gì mình chia sẻ trong bài này đến từ việc mình từng làm việc với khá nhiều người, đến từ những Background rất khác nhau.

British.

Italian.

Spanish.

Indonesian.

Indian.

Japanese.

Vietnamese.

Và còn nhiều người khác nữa.

Làm việc với nhiều người như vậy mới thấy một chuyện khá thú vị.

Mình học rất nhiều thứ, nhưng đôi khi để giao tiếp tốt hơn thì lại phải biết “lùi” xuống.

Nó quay lại với một câu mình khá thích:

See the world as it is.

Không phải ai cũng sử dụng tiếng Anh như First Language.

Có người dùng tiếng Anh là ngôn ngữ thứ hai.

Có người là ngôn ngữ thứ ba.

Có người nói rất giỏi.

Có người chỉ vừa đủ dùng.

Vậy nên đôi khi mục tiêu không phải là:

“Mình phải nói tiếng Anh thật hay.”

Mà là:

“Làm sao để người kia hiểu đúng điều mình muốn nói?”

Đó mới là Communication.

Nếu phải chọn giữa một câu tiếng Anh rất đẹp nhưng người nghe không hiểu, và một câu tiếng Anh đơn giản nhưng hai bên hiểu nhau ngay...

Mình chọn cái thứ hai.

The most effective result của Communication.

Chắc bài này đến đây là vừa.

Cảm ơn mọi người đã đọc đến cuối.

Hẹn gặp lại ở bài tiếp theo.

Chúc mọi người luôn vui vẻ và hạnh phúc. 🙇‍♂️