Phần lớn những dự án rối như canh hẹ mà tôi từng bị kéo vào đều không phải do mã nguồn tệ. Nguyên nhân là thông tin cần thiết không đến được đúng người, cho tới khi đã quá muộn. Từ khi nhận vai trò trưởng dự án (project lead) ở công ty, tôi bắt đầu ghi lại cách mình muốn điều phối giao tiếp, nếu có ngày ngồi vào ghế CTO. Đây là những ghi chép đó.

Xác định ai cần biết gì

#

Nền móng thì chẳng có gì hào nhoáng: một kế hoạch giao tiếp ghi rõ ai cần được báo, họ cần biết gì, bao lâu báo một lần và qua kênh nào. Tôi sẽ đòi có kế hoạch này ngay từ đầu mỗi dự án, kèm tên người phụ trách cụ thể, vì việc gì cũng giao cho “cả đội” thì rốt cuộc chẳng ai làm. Với các bên liên quan (stakeholder) cũng vậy: tìm ra ai thực sự quan tâm đến dự án, hiểu mỗi người thích được cập nhật theo cách nào, và đừng gửi cho CEO nguyên cái tin cập nhật bạn vừa đăng trong kênh của đội lập trình. Cuối cùng là đặt ra vài quy ước rõ ràng: bao lâu thì nên phản hồi, thế nào mới tính là gấp, kênh nào dùng cho việc gì. Phần lớn cái gọi là “vấn đề giao tiếp” thật ra chỉ là những kỳ vọng chưa ai nói ra thành lời.

Ví dụ về kế hoạch truyền thông cho một dự án phần mềm

#

Đây là kế hoạch tôi sẽ dùng làm điểm xuất phát rồi điều chỉnh dần. Mỗi dòng là một nhóm đối tượng cần được báo, chứ không phải một cuộc họp:

Bên dưới bảng là các quy ước, viết càng đơn giản càng tốt: gấp nghĩa là việc đó đang chặn một lần phát hành hoặc khiến khách hàng bị kẹt, nên hãy gọi điện thay vì nhắn tin; câu hỏi thì đưa vào chat, quyết định thì ghi vào công cụ quản lý công việc; phản hồi trong vòng một ngày làm việc. Với nhật ký quyết định, tôi dùng tài liệu ra quyết định, lưu dưới dạng GitHub Issues để chúng nằm ngay cạnh công việc.

Có hai điều giúp một kế hoạch như thế này thực sự vận hành. Dòng nào cũng có tên một người cụ thể ở cột cuối, và bản cập nhật cho ban lãnh đạo được viết ra chứ không chỉ nói miệng, nên có thể chuyển tiếp cho người khác mà không rơi rớt thông tin nào.

Công cụ và nhịp làm việc

#

Công cụ không quan trọng bằng mức người ta hay cãi nhau về nó. Slack để nhắn tin, Trello để quản lý công việc, Zoom khi cần nhìn mặt nhau mà nói chuyện. Chọn cái hợp với đội mình rồi đi tiếp. Nhịp làm việc mới quan trọng hơn: họp nhanh hằng ngày (daily stand-up) nếu đội làm theo Agile, cập nhật hằng tuần nếu chu kỳ dài hơn, và quan trọng là giữ đúng nhịp đó. Rồi hãy ghi chép lại mọi thứ. Quyết định, thay đổi, đầu việc cần làm (action item), tất cả đều đưa vào Notion hay Jira, như một phần của quy trình chứ không phải chuyện tiện thì làm. Sáu tháng sau, tài liệu là thứ duy nhất còn nhớ chuyện gì đã xảy ra.

Phần “mềm” mới là phần khó

#

Tất cả những gì ở trên chỉ là cơ chế. Việc khó hơn là hỏi cả đội xem cách giao tiếp hiện tại có thực sự hiệu quả không, và thay đổi khi nó không hiệu quả. Rồi còn chuyện đào tạo nữa: mỗi người trong đội đến từ một nền tảng khác nhau, và không phải ai cũng từng làm trong một dự án được vận hành tử tế. Còn phải biết lắng nghe cho đàng hoàng thay vì chỉ ngồi chờ đến lượt mình nói, và xử lý mâu thuẫn từ sớm, khi nó còn nhỏ. Mà chẳng có gì trong số này giải quyết một lần là xong: cách làm hiệu quả ở quý trước có thể lặng lẽ hết tác dụng, nên cứ phải kiểm tra lại thường xuyên.

Làm việc trong một đội phát triển phân tán/bất đồng bộ

#

Nếu đội của bạn làm việc từ xa (remote) hoặc chủ yếu trao đổi bất đồng bộ (async), bài nói này rất đáng để bạn bỏ thời gian ra xem:

Tôi không làm hoàn hảo được hết những điều này, mà cũng chẳng ai làm được. Nhưng nhìn lại thì dự án nào suôn sẻ cũng có phần lớn những thứ trên, còn dự án nào khiến tôi khổ sở thì đều thiếu ít nhất ba thứ.