Có lần tôi dẫn dắt một dự án đang bị chậm tiến độ. Tôi biết kiến trúc hệ thống có vấn đề. Tôi biết chúng tôi sẽ trễ hạn. Vậy mà tôi cứ ngồi chờ ai đó hỏi đến.
Ba tuần sau mới có người hỏi. Đến lúc đó thì mọi chuyện đã thành thảm họa.
Bài học tôi rút ra là: nếu cứ đợi người khác hỏi rồi mới nói, họ sẽ mặc định là mọi thứ vẫn ổn, cho đến khi mọi thứ không còn ổn nữa. Lúc đó họ sẽ thắc mắc sao bạn không nói sớm hơn.
Chỉ biết phản hồi thì có gì sai?#
Hầu hết mọi người giao tiếp theo kiểu bị động. Có người gửi email thì trả lời. Có người hỏi tiến độ thì cập nhật. Có người báo lỗi thì sửa.
Nghe thì có vẻ hiệu quả. Bạn chẳng bao giờ làm mất thời gian của ai bằng những thông tin thừa.
Nhưng đồng thời, bạn cũng đang tập cho mọi người xung quanh thói quen phải chạy theo bạn mới có thông tin. Quản lý phải hỏi thì mới biết dự án đang thế nào. Các đội khác phải tự đi kiểm tra xem thay đổi của bạn có ảnh hưởng đến họ không. Ban lãnh đạo phải đào bới mới biết có rủi ro gì.
Nhiều kỹ sư giỏi tôi từng làm cùng mắc kẹt đúng ở chỗ này. Họ xây nên những hệ thống rất tốt nhưng chẳng ai biết, cho đến khi có thứ gì đó hỏng. Họ giải được những bài toán khó, nhưng chỉ sau khi đã có người phàn nàn.
Tôi từng chứng kiến một lập trình viên cấp cao (senior) bỏ ra hai tuần để tái cấu trúc mã (refactor) một hệ thống thanh toán quan trọng. Mã viết rất đẹp. Thời gian xử lý giảm một nửa. Vậy mà chẳng ai biết, mãi sáu tháng sau mới có người tình cờ phát hiện ra trong lúc đang gỡ lỗi một chỗ khác. Bao nhiêu công sức, không ai nhìn thấy.
Trong khi đó, một kỹ sư khác cùng đội thì cứ đưa được thứ gì lên môi trường production là gửi ngay một tin cập nhật ngắn: “Đã giảm độ trễ (latency) của API 200ms, cách làm như sau.” Năm câu, có khi kèm một cái biểu đồ. Ai cũng biết người đó đang làm gì. Bạn đoán xem ai được thăng chức?
Khác biệt không nằm ở kỹ năng. Mà nằm ở thời điểm lên tiếng.
Chuyện gì thực sự xảy ra khi bạn im lặng#
Để tôi nói cụ thể “chờ người ta hỏi” trông như thế nào ngoài thực tế.
Bạn đã làm ba ngày cho một đầu việc ước tính hai ngày, và bạn biết mình còn cần thêm ba ngày nữa. Bạn sẽ nói ngay bây giờ, hay đợi đến buổi họp nhanh hằng ngày (standup) sáng mai khi có người hỏi?
Nếu bạn đợi, chuyện sẽ diễn ra thế này: quản lý của bạn đã lên kế hoạch với giả định là hôm nay bạn xong. Đội QA đã xếp lịch kiểm thử vào ngày mai. Quản lý sản phẩm (product manager) đã hứa với khách hàng là thứ Sáu sẽ phát hành. Giờ thì ai cũng cuống cuồng xoay xở lại, chỉ vì bạn không bỏ ra 30 giây để nói một câu “Việc này đang lâu hơn dự kiến.”
Hoặc thế này: bạn đang thay đổi cách hệ thống xác thực hoạt động. Bạn biết ứng dụng di động đang ngầm giả định token có một định dạng nhất định. Bạn nhắn cho đội làm ứng dụng di động ngay, hay đợi xem họ có tự phát hiện ra không?
Nếu bạn đợi, tuần sau họ triển khai ứng dụng. Ứng dụng lỗi ngay trên môi trường production. Họ mất hàng giờ gỡ lỗi, rồi cuối cùng lần ra thay đổi của bạn. Thế là bạn thành người làm sập hệ thống production mà không báo trước cho ai.
Chuyện kiểu này xảy ra suốt. Và lần nào cũng là vì có người biết mà không nói.
Thay vào đó nên làm gì#
Hãy cho mọi người biết trước khi họ phải hỏi. Không phải chuyện gì cũng nói, chỉ những gì họ cần biết.
Dưới đây là những tình huống mà tôi đã học được là nên chủ động lên tiếng trước:
Khi tiến độ bị trượt. Bạn ước tính năm ngày, giờ đã qua ba ngày mà mới xong chừng 30%. Nhắn ngay lúc đó: “Việc này lâu hơn mình nghĩ. Giờ ước chừng 8-10 ngày chứ không phải 5. Bạn muốn mình thu hẹp phạm vi hay lùi hạn chót?”
Đừng đợi buổi họp nhanh. Đừng đợi ai hỏi. Biết lúc nào thì báo lúc đó.
Khi bạn ra quyết định kỹ thuật. Bạn chọn Postgres thay vì MySQL. Bạn dùng REST thay vì GraphQL. Bạn thêm một trường (field) bắt buộc mới vào API.
Lúc quyết định thì có vẻ chỉ là chuyện trong phạm vi của bạn, nhưng thực ra đang có người khác phụ thuộc vào những quyết định đó. Hãy gửi một tin nhắn ngắn: “Báo trước nhé, mình sẽ đổi endpoint người dùng để bắt buộc xác thực email. Thứ Năm này triển khai lên production. Có gì ảnh hưởng bên bạn thì báo mình nhé.”
Khi bạn phát hiện rủi ro. Cơ sở dữ liệu đang phình to nhanh hơn dự kiến. API chậm dần khi tải tăng cao. Tính năng mới chạy được, nhưng mã lộn xộn và sẽ khó bảo trì.
Đừng đợi đến khi nó thành vấn đề. Hãy lên tiếng khi vẫn còn thời gian xử lý: “Mình để ý thời gian phản hồi của endpoint tìm kiếm đang tăng dần. Chưa gấp, nhưng chắc sprint tới mình nên tính chuyện thêm bộ nhớ đệm (cache).”
Cập nhật định kỳ. Thứ Sáu nào tôi cũng gửi email cho các bên liên quan (stakeholder). Mất chừng 10 phút. Ba gạch đầu dòng: tuần này đã phát hành được gì, tuần sau sẽ làm gì, và có điều gì tôi đang lo.
Hầu hết các tuần đều nhàm chán. Mà mục đích chính là vậy. Nhàm chán nghĩa là không có bất ngờ. Và khi thực sự có chuyện, họ đã nắm được bối cảnh vì tôi vẫn đều đặn cập nhật cho họ.
Vì sao người ta không làm vậy#
Lý do nào tôi cũng từng nghe qua, vì chính tôi cũng đã dùng gần hết.
“Tôi không muốn làm phiền mọi người.” Bạn không làm phiền họ đâu. Bạn đang giúp họ khỏi phải đi làm phiền bạn. Quản lý của bạn thà đọc một tin cập nhật hai câu, còn hơn phải xếp lịch họp chỉ để hỏi xem tình hình thế nào.
“Lỡ tôi nói sai thì sao?” Thì gửi thêm một tin nữa. “Cập nhật: việc mình bảo mất 8 ngày hóa ra chỉ mất 6, tiến độ đã về lại đúng kế hoạch.” Chẳng ai giận vì tin tốt cả.
“Tôi không muốn trông như người không biết mình đang làm gì.” Vấn đề là thế này: trễ hạn mà không báo trước mới khiến bạn trông như không biết mình đang làm gì. Còn báo sớm chuyện chậm tiến độ khiến bạn trông như người biết quản lý rủi ro.
“Tôi bận quá.” Bạn không bận đến mức không gửi nổi một email ba câu. Còn nếu bạn nghĩ mình bận đến thế thật, thì bạn càng không có thời gian để dọn mớ hỗn độn xảy ra khi không gửi.
Lý do thật sự khiến người ta không lên tiếng sớm là vì nó khiến mình thấy khó chịu. Im lặng rồi cầu mong mọi chuyện ổn thỏa thì dễ hơn. Nhưng hy vọng không phải là kế hoạch, và im lặng không phải là chuyên nghiệp.
Khi nào chỉ cần phản hồi#
Bạn không thể báo trước mọi thứ. Có những tình huống cần phản ứng ngay, chứ không phải cảnh báo trước.
Khi hệ thống gặp sự cố, hãy xử lý trước đã. Vẫn gửi cập nhật về những gì bạn đang làm, nhưng đừng đợi viết xong một bản phân tích sau sự cố (post-mortem) hoàn hảo rồi mới cầm máu.
Khi ai đó đang bị kẹt vì chờ bạn rà soát mã (code review), cứ rà soát luôn đi. Họ không cần bản cập nhật hằng tuần của bạn, họ cần bạn gỡ kẹt cho họ trong vòng một tiếng tới.
Khi có câu hỏi gấp trên Slack, hãy trả lời. Đừng bắt người ta đợi đến bản tóm tắt thứ Sáu.
Nguyên tắc chung: nhu cầu tức thời thì phản hồi ngay, còn lại thì chủ động báo trước.
Trong thực tế thì thế nào#
Đây là những gì đã thay đổi khi tôi bắt đầu làm điều này thường xuyên:
Ít họp hơn. Khi mọi người đã biết chuyện gì đang diễn ra, họ không cần xếp lịch họp để hỏi nữa. Lịch họp của tôi từ hơn 25 tiếng mỗi tuần giảm xuống còn chừng 15 tiếng.
Ít bất ngờ hơn. Khi bạn cảnh báo sớm, vấn đề không còn mang cảm giác của một vấn đề nữa, mà giống một việc bạn đang kiểm soát. Chẳng ai hoảng hốt vì một rủi ro bạn đã báo từ hai tuần trước.
Được tin tưởng hơn. Đây là thay đổi lớn nhất. Khi bạn đều đặn cho mọi người biết tình hình mà họ không cần phải hỏi, họ bắt đầu tin là bạn sẽ lo liệu được. Và thế là họ giao cho bạn nhiều trách nhiệm hơn, nhiều việc thú vị hơn.
Còn vụ thăng chức tôi kể lúc nãy? Một phần là nhờ làm tốt. Nhưng phần lớn hơn là nhờ người đó đảm bảo đúng người biết đến những việc mình làm tốt, mà không phải đào bới mới thấy.
Bắt đầu từ đâu#
Chọn một việc bạn đang làm trong tuần này. Trước khi có ai hỏi đến, hãy gửi một tin cập nhật ngắn.
Có thể gửi cho quản lý: “Phần tái cấu trúc API đang tiến triển tốt. Xong khoảng một nửa rồi, vẫn kịp cuối tuần.”
Có thể gửi cho đội khác: “Mình vừa đổi cách xử lý phiên đăng nhập (session) của người dùng. Chắc không ảnh hưởng gì bên bạn, nhưng nếu thấy phần xác thực có gì lạ thì báo mình nhé.”
Có thể gửi cho đội mình: “Đã sửa xong lỗi trên production. Nguyên nhân gốc là tranh chấp dữ liệu (race condition) ở tầng bộ nhớ đệm. Mình đã thêm kiểm thử để lỗi này không lặp lại nữa.”
Hai ba câu thôi. Rồi bấm gửi.
Xem chuyện gì xảy ra. Thường sẽ là một trong hai khả năng:
- Họ thấy trân trọng, còn bạn thì bớt lo vì không phải ôm thông tin một mình
- Họ không trả lời, cũng chẳng sao, vì giờ họ đã biết và bạn không cần bận tâm nữa
Làm vài lần như vậy là nó thành phản xạ. Xong việc gì thì báo cho những người liên quan. Thấy vấn đề thì lên tiếng. Ra quyết định thì chia sẻ.
Sau vài tuần, người ta thôi hỏi bạn tình hình thế nào, vì họ đã biết cả rồi. Và đó là lúc mọi thứ bắt đầu dễ thở hơn.