Dăm ba điều về lề lối làm việc chốn công sở

10/06/2019 – 10/06/2020

Một năm đi làm là một năm trưởng thành hơn trong công việc. Mình quyết định đánh dấu cột mốc này bằng một bài chia sẻ nhỏ về những kinh nghiệm đã đúc kết được thời gian qua.

Ở vai trò Data scientist, bạn hẳn tưởng tượng mình sẽ được giao một tập dữ liệu chưa được khai phá, tìm đọc paper, thiết lập prototype, đọc thêm paper, lại một prototype khác nữa… Quá hấp dẫn đúng không? Thực tế thì giai đoạn này chỉ chiếm 1/10 tổng thể quỹ thời gian, hoặc ít hơn, hoặc chúng cắt nhỏ rải rác qua nhiều tuần. Phần lớn thời gian bạn dành để trao đổi với người dùng, thiết lập problem statement (đặc tả vấn đề) phù hợp, học hỏi hết mức về domain knowledge (kiến thức ngành, cụ thể dữ liệu được trích xuất nhằm mục đích gì, ý nghĩa tương quan người dùng có thể nghĩ đến…), trình bày phương pháp cho họ bình duyệt v.v… Mặt khác, bạn cần trao đổi với Data/ML engineer để tối ưu code nhằm chịu tải tốt trên pipeline cũng như đạt được latency (độ trễ) theo như khách hàng yêu cầu. Và trên hết, bạn cần phải có một góc nhìn toàn cảnh về dự án, những ai tham gia và tác vụ của họ, thiết lập mối quan hệ tương hỗ này giúp bạn tìm đúng ngay subject matter expert khi gặp phải vấn đề và nhanh chóng giải quyết chúng.

Hẳn bạn lờ mờ đoán được mình muốn nói gì: bài viết này nhằm chia sẻ về quy cách giao tiếp hiệu quả trong một tổ chức. Phong cách làm việc Objective-driven (chú trọng mục tiêu) sẽ chỉ thực sự hữu ích ở quy mô nhóm nhỏ, để bộ máy vận hành trơn tru từ quy mô vừa trở lên, theo mình, Communication-driven (chú trọng giao tiếp) mới là kim chỉ nam đích thực. Ở đây, mình chia chúng thành ba nhóm chính: quy tắc ứng xử chung cho mọi trường hợp, group meeting, và peer-to-peer meeting.

NHÓM QUY TẮC ỨNG XỬ CHUNG CHO MỌI TRƯỜNG HỢP

Không có gì là quá lịch sự. Trước đây có anh bạn cùng lab cho rằng mình viết email quá lịch sự và trịnh trọng. Do đó mình thả lỏng bản thân hơn, và đôi lúc có vẻ hơi mất kiểm soát một chút. Sẽ không may, nếu bạn dùng tiếng Anh, bởi không phải tiếng mẹ đẻ, bạn cảm thấy cảm xúc không được truyền tải đúng mực và có gì đó cộc lốc. Có một quãng, một số tin nhắn công việc mình gửi đã xem nhưng không được trả lời, và mình nhận phản hồi rằng bản thân có vẻ “thách thức” người khác trong công việc. Trong hầu hết các trường hợp, mình hoàn toàn không có ý biểu lộ thái độ này.

Từ đó, mình luôn thêm “please”, “I’m curious, …”, “Correct me if I’m wrong”, trong những cuộc tranh luận, bởi lằn ranh giữa mối bận tâm giải quyết vấn đề thuần túy và cảm giác bị thách thức cách nhau một kẽ tóc. Một hiệu ứng phụ đáng hoan nghênh là câu chữ, cả nói và viết, góp phần điều chỉnh tâm trạng của bạn lại trạng thái trung tính, gạt bỏ đi những bận tâm cá nhân nếu có và trở nên chuyên nghiệp hơn. Cũng đừng quên, ở chiều ngược lại, hãy luôn tiếp nhận mọi ý kiến với cánh tay dang rộng.

Lựa chọn phương pháp giao tiếp phù hợp: liệu một buổi họp ngắn có hiệu quả hơn một chiếc email hay không? Câu trả lời tùy thuộc vào nội dung cần truyền tải. Có bốn phương thức chính mình áp dụng:

• Viết email: khi nội dung trao đổi cần được ghi nhận chính thức với các bên liên quan (xác nhận khách hàng chấp nhận giải pháp đưa ra) và mọi thứ được trình bày trắng đen rõ ràng, không ai chối cãi. Có thể dùng sau group meeting để chốt nội dung và deadline cho action item đã thảo luận.
• Gửi tin nhắn (Skype, Team, Slack): khi thông tin đưa ra không cấp bách, truyền tải ngắn gọn được trong một hai câu.
• Thu xếp cuộc gọi ngắn (Skype, Team, Zoom): vấn đề cấp bách và dễ hơn khi đối thoại  trực tiếp.
• Cuộc gọi nhóm chính thức (conference call): giải quyết vấn đề trong một nhóm. Nên có meeting minute qua email gửi kèm sau đó.

Lưu ý rằng minh bạch thông tin là cần thiết, nhưng cân nhắc khi thông báo ngữ cảnh cho các bên liên quan, bởi chúng có thể gây nên hiểu nhầm không đáng có. Chị A đánh giá hệ thống hoạt động kém, nhưng bạn vẫn đang chờ B có đánh giá độc lập trước khi thông báo cho sếp, cho nên tốt nhất là đợi đến khi có fact (bằng chứng xác đáng) hẵng thông báo chính thức. Biết đâu bạn còn tìm ra một con bug (lỗi) len lỏi đâu đó.

Chúng ta có thể làm mà không có người điều phối: thật vậy, nếu bạn nắm rõ phần việc được giao, bạn chỉ cần đảm bảo chúng hoạt động như kỳ vọng. Nếu vấn đề phát sinh, cập nhật tình hình chung cho nhóm, các nguyên nhân tiềm tàng sẽ dễ dàng loại bỏ và root cause (nguyên nhân gốc rễ) sẽ được bên liên quan giải quyết. Điều này xuất phát từ việc tin tưởng lẫn nhau. Dĩ nhiên, tư duy này áp dụng trong ngữ cảnh nhất định, nhưng nó giúp bạn không lấn sân sang người khác, không bứt rứt khi có vẻ không ai đứng ra điều phối, và quản lý thời gian hiệu quả hơn.

Trình bày vấn đề cụ thể: khi đối mặt một vấn đề, mình thường theo công thức sau để định nghĩa nó một cách chính xác hết mức có thể nhằm nhận được sự hỗ trợ phù hợp từ đồng nghiệp:

• Problem statement: chuyện gì đã xảy ra và nguồn cơn.
• Observation: đánh giá tổng thể và chi tiết.
• Action: đề xuất giải pháp.
• Conclusion: kết luận.

Giả dụ, một sở thú cần cung cấp ba nải chuối mỗi ngày cho chuồng khỉ của mình. Một hôm, người giao hàng chỉ giao hai nải. Bạn có thể báo cáo với cấp trên bằng statement “Thiếu chuối do gói hàng giao thiếu”. Hay, bạn dành thời gian truy vết và nhận ra nải chuối bị mất do chuyển nhầm vào chuồng tê tê (pangolin), do đó báo cáo sẽ như sau:

• Problem statement: chuối cho chuồng khỉ bị gửi nhầm sang tê tê.
• Observation: bọn khỉ đói và la hét, phần chuối gửi nhầm chưa bị động đến.
• Action: chuyển chuối về cho khỉ ăn.
• Conclusion: mọi thứ giải quyết êm xuôi.

Hẳn nhiên, mọi thứ ít khi đơn giản như thế, actions và conclusion có thể thiếu, nhưng hai yếu tố đầu cần có. Khuôn mẫu này giúp bạn làm việc logic hơn cũng như đối tác dễ dàng nắm bắt vấn đề.

Mọi tiếng nói đều quan trọng: trong cuộc họp nhóm ở quy mô vừa (10 người trở lên), bạn có thể nghĩ hãy để senior (cấp trên) nói chuyện và mình góp ý riêng sau. Theo mình, hành vi thụ động trên là nguyên nhân của những cuộc họp thiếu hiệu quả. Một khi bạn tin rằng ý kiến của mình xác đáng và có thể trình bày rành mạch, đừng ngại “unmute your mic”. Và nhớ, hãy luôn khiêm tốn.

Đảm bảo rằng cấp trên biết bạn đang làm gì: bạn được giao một tác vụ cần hoàn thành trong tuần. Vào giữa trưa thứ Sáu, bạn nhắn cấp trên rằng mình cần thêm thời gian. Nếu là một vị sếp tốt, anh/cô ta hẳn bảo “thôi được, nhưng lần sau cho mình biết sớm hơn nhé”; hoặc, chuyện có thể tệ hơn. Tốt nhất nếu bạn có thể cập nhật công việc với cách quãng hợp lý, hay hỏi thẳng cấp trên về việc này: liệu có phiền nếu tôi cc các email công việc, chẳng hạn. Mặc dù quả thật người quản lý chỉ cần nắm mọi việc ở “high-level” (điểm chính yếu, không đi sâu chi tiết), nhưng họ cũng cần biết tiến độ để có thể can thiệp kiệp thời. Với quản lý cấp trung, khi họ có am hiểu về mặt kỹ thuật, bạn có thể hỏi ý nếu họ muốn tham gia vào các group chat trực tiếp, tăng cường visibility (điểm bao quát) cho họ.

Deadline kín kẽ nhưng linh hoạt: thiết lập deadline không dễ, nhưng cũng không quá khó. Quá lạc quan sẽ khiến bạn chìm nghỉm dưới hàng tấn việc, nhưng “under promising and over delivering” không hẳn là tốt, vì mỗi ngày chậm trễ là công ty mất một phần lợi nhuận, chưa kể sẽ tạo tâm lý chai lì nơi bạn. Cách tốt nhất để đánh giá một cách hợp lý là lập WBS (Work Breakdown Structure) cộng với một ít buffer (10-20% tổng thời gian), song song đối chiếu với các dự án khác để thiết lập độ ưu tiên. Dẫu kĩ tính đến đâu, vẫn có khả năng bạn trễ deadline. Dựa trên những gì bạn đã chuẩn bị, hãy trình bày với problem statement để cấp trên hiểu và cùng tìm hướng giải quyết. Họ hẳn sẽ hiểu những khó khăn bạn mắc và đưa ra lời khuyên hữu ích.

Objective-driven: giao tiếp trong công việc đều nhằm một mục đích nhất định. Mình từng thiết lập một cuộc họp dài 1 tiếng, và sau đó quên bẵng hầu hết mọi thứ. Cuối mỗi cuộc trò chuyện, cần xác lập rõ những thỏa thuận và các việc làm tiếp nối (ai, cái gì, lúc nào). Nếu bạn lo rằng mình chưa nắm, hãy chủ động là người lặp lại action item. Ngược lại, nếu muốn ai đó nắm bắt ý của mình, bạn có thể yêu cầu họ làm tương tự.

GROUP MEETING

Thiết lập một group meeting cần chú trọng ba cột mốc: trước, trong, và sau cuộc họp.

Trước cuộc họp, thiết lập OCM (Outlook Calendar Meeting) trước ngày hẹn ít nhất một hôm, đảm bảo các thành viên quan trọng không bận lịch, và quan trọng là nêu rõ nội dung bàn thảo (agenda) được liệt kê theo độ ưu tiên.

Trong cuộc họp, đảm bảo thời lượng cho mỗi item hợp lý, làm rõ vấn đề trực tiếp nếu còn mù mờ. Đảm bảo nội dung gốc được giải quyết thỏa đáng. Bạn sẽ có xu hướng giải quyết mọi thứ trong cuộc họp, nhưng cũng bình tĩnh suy xét nếu một vấn đề cần thảo luận sâu hơn, mở cửa khả năng một buổi họp riêng khác dành cho nó. Bạn có thể rút ngắn cuộc họp, nhưng đừng bao giờ vượt quá giờ hạn định, và hãy luôn xin lỗi nếu “overtime”. Nếu cần rời khỏi cuộc họp sớm, trong trường hợp có người khác đang nói, hãy nhắn tin qua khung chat để mọi người cùng biết. Những thành viên là chủ các item cần chuẩn bị trình bày phần của mình rành mạch, nếu phức tạp quá có thể soạn một slide ngắn để hỗ trợ. Việc này sẽ mất thời gian, nhưng hẳn là đỡ tốn hơn nếu bạn phải kéo dài ra thêm một cuộc họp mới nữa.

Sau cuộc họp, nếu bạn là người chủ trì, nên gửi kèm meeting minute sau đó. Email này gửi cho những người tham gia và cấp trên nếu họ cần được nắm tiến độ. Meeting minute thường gồm:

• Những người tham gia, thời gian cuộc họp.
• Tóm tắt nội dung cuộc họp và điểm thảo luận.
• Danh sách action item, những tác vụ cần thực hiện tiếp theo.

Trước đây mình gửi một email dài như sớ, và hẳn là chẳng ai buồn đọc bởi các điểm mấu chốt không lần ra được. Do đó, kỹ năng tóm tắt thật sự quan trọng. Hãy liệt kê những ý chính, không quá kĩ thuật nhưng đánh đúng trọng tâm, và tóm thành bullet list. Tin mình đi, thường mình dành ít nhất 30 phút để soạn một email như thế; nó đòi hỏi khá nhiều năng lượng từ người viết. Bạn có thể hỏi: “nhưng nếu mình không nói rõ ý A hơn, làm sao anh X thấy được sự phức tạp của vấn đề?”. Cấp trên cũng từng là engineer, nên bạn có thể tin vào năng lực của họ. Nếu thắc mắc, họ sẽ hỏi, và bạn có thể đi sâu vào chi tiết lúc này. Điểm chính yếu là, bạn phải làm người đọc muốn xem qua email của bạn trước đã.

PEER-TO-PEER MEETING

Có hai dạng chính: bạn đồng nghiệp trao đổi cùng nhau và cấp trên-cấp dưới. Những quy tắc ứng xử ở trên bao hàm cả hai.

Thông thường đơn vị làm việc là nhóm hai người trở lên thay vì cá nhân, cho nên quan hệ giữa đồng nghiệp với nhau là tất yếu. Nhớ có hôm, cấp trên hỏi mình về tình hình những người còn lại trong nhóm, mình chỉ kể được vắn tắt và có phần thiếu tự tin. Sau đó anh bảo, em phải làm việc sâu sát với nhau, nên có 1 buổi meeting ít nhất mỗi tuần, có cùng chia sẻ với nhau thì quan hệ mới tốt hơn và đồng nghiệp sẽ sẵn sàng chia sẻ khó khăn của họ với em và ngược lại. Ừa, là vậy đó 😀

Công ty mình có thiết lập những buổi 1-on-1 meeting định kỳ mỗi tuần. Đây là lúc để bạn cùng cấp trên trao đổi tình hình trong tuần, hỏi xin góp ý cũng như đánh giá lẫn nhau. Mình không cảm thấy có chút lo sợ, chỉ xem nó như những buổi meeting khác. Sếp có thể góp ý về cách làm việc của mình tuần qua (coaching) và ngược lại.

Về khía cạnh công việc, cấp trên là người đưa ra định hướng dự án và chỉ đạo những công việc cụ thể cho nhân viên. Ngược lại, cấp dưới cần nắm rõ mình cần làm gì, kỳ vọng ra sao (deliverable, bạn có quyền dí sếp nếu có gì đó mơ hồ), và cập nhật tình hình sâu sát. Để mình lặp lại, bạn cần luôn chủ động bàn bạc công việc và sếp không phải đóng vai người đốc thúc. Hiểu rõ vai trò của nhau, bộ máy sẽ trơn tru và không khí làm việc đỡ căng thẳng hơn.

---

Những gì mình kể là những khuôn mẫu hành vi mà mình rút ra được. Chúng giúp mình đỡ mất thời gian và định hướng tốt trong chốn công sở. Tuyệt vời hơn là độ phổ quát có thể áp dụng cho hầu khắp mọi nơi, như nhà trường, xí nghiệp, câu lạc bộ. Dĩ nhiên là còn nhiều thứ phải học, cho nên mỗi khi gặp một vấn đề mới và giải quyết chúng, bạn nên dành chút thời gian chiêm nghiệm ra giải pháp chung; lần sau gặp lại, bạn đã sẵn có công cụ để giải quyết rồi đó.

Mình cũng không quá lạc quan khi cho rằng những hành vi trên sẽ được chấp nhận ở mọi nơi, nhưng mình tin đây là những tín hiệu cần có để nhận diện một môi trường lao động vì người lao động. Hy vọng bài viết ngắn này sẽ hữu ích cho bạn.