Khi tốc độ được đặt lên hàng đầu, giao tiếp là thứ đầu tiên bị phá vỡ

Khi bạn đặt tốc độ và "di chuyển nhanh" (moving fast) làm ưu tiên lớn nhất trong một dự án hay tổ chức, điều đầu tiên bị phá vỡ chính là việc giao tiếp với nhau. Giao tiếp tốn thời gian. Đạt được sự đồng thuận tốn kém và chậm chạp. Trong môi trường áp lực cao, không có thời gian để lên lịch họp, xin ý kiến từ các chuyên gia, hay giải quyết các khác biệt quan trọng. Việc yêu cầu hoàn thành "ngay lập tức" (ASAP) mang một giả định lớn rằng tất cả các bên liên quan đều đã có mặt trong phòng.

Không phải mọi thứ đều cần một cuộc tranh luận. Tôi tin tưởng vào triết lý "cung cấp cho người dùng một cái gì đó để xem họ có quan tâm hay không". Tôi đồng ý rằng cả việc suy nghĩ quá nhiều và suy nghĩ quá ít về một vấn đề đều chứa đựng rủi ro. Tuy nhiên, có hàng chục cách để nhận phản hồi từ người dùng về công việc đang thực hiện mà không cần cam kết quá sâu vào một thiết kế cụ thể. Bằng cách ưu tiên tốc độ hơn giao tiếp, sự hợp tác chéo giữa các bộ phận bị ảnh hưởng và một thiết kế sai lầm có thể được đẩy mạnh một cách mù quáng. Tôi không phải nhà tiên tri, nhưng tôi có thể nói trước rằng bạn đang thiết lập cho tổ chức của mình một cuộc xung đột khi gộp code (merge conflict) lộn xộn trong tương lai giữa các đội nhóm đã đi theo những hướng khác nhau.

Nạn nhân thứ hai: "Hệ thống"

Tôi nghĩ nạn nhân thứ hai của tổ chức là "hệ thống". Khi tốc độ là ưu tiên, không có động lực để cải thiện hoặc đầu tư vào hệ thống dùng chung (ví dụ: hệ thống thiết kế hay codebase) dưới áp lực thời hạn chặt chẽ. Nếu mọi người đều cần di chuyển nhanh, ngay cả một việc đơn giản như đổi tên thư mục cũng có thể gây ra sự chậm trễ lớn. Những người chạy theo tốc độ sẽ tạo một thư mục dự án mới hoặc tách một thành phần Figma ra. Và thư mục tệp mới đó phát triển thành một hệ thống thành phần trùng lặp riêng biệt, hơi khác một chút so với phần còn lại của hệ thống đến mức không tương thích.

Giải quyết các khoảng trống trong hệ thống đòi hỏi các cuộc trò chuyện, nên việc rời bỏ hệ thống khi gặp chút bất tiện, nhân bản và đi theo cách riêng của mình sẽ dễ dàng hơn. Thực chất là ẩn giấu quả bom nợ kỹ thuật (technical debt) cho người xui xẻo kế tiếp phải gánh chịu.

Vai trò của AI trong vấn đề này

Tôi nghĩ AI làm trầm trọng thêm vấn đề này. Tôi tin rằng AI có thể giúp bạn xây dựng nhanh hơn (mặc dù dữ liệu cho thấy điều ngược lại), nhưng tôi cũng tin rằng các Mô hình Ngôn ngữ Lớn (LLM) là công cụ tối thượng trong chuỗi công cụ "Đừng nói chuyện với đồng nghiệp". Tại sao phải nói chuyện với một chuyên gia có thể nói "không" với tôi, khi cỗ máy toàn tri luôn nói "có" ngay ở đây? Tránh va chạm đó không tạo ra sản phẩm tốt hơn nhanh hơn. Nó làm cho các cuộc trò chuyện trong tương lai trở nên khó khăn hơn nhờ chi phí chìm (sunk costs) cao hơn và ý kiến sâu sắc hơn.

Các phần hạ tầng khác bắt đầu bị bào mòn khi di chuyển quá nhanh: tài liệu, bảo mật, hiệu suất, độ tin cậy, và sự hài lòng của nhà phát triển để kể một vài cái. Tôi ủng hộ việc giảm bớt những điều vô bổ, tôi ủng hộ việc giảm bớt sự vất vả. Nhưng tôi cũng ủng hộ việc chậm lại và thực hiện suy nghĩ thực sự của con người trước khi bóp cò... hoặc phóng tên lửa dẫn đường... hay bất kỳ phép so sánh hành động nào phù hợp nhất với tổ chức của bạn.

Chúng ta đều thích dopamine, chúng ta đều thích thấy những ý tưởng mới thành hiện thực, nhưng nhiều dòng code hơn và các hệ thống trùng lặp – những vương quốc nhỏ của riêng chúng ta trong code – không tạo ra sức mạnh ngang. Công việc của Quản lý Kỹ thuật không còn là đẩy các vé (ticket) qua bảng để các giám đốc vỗ tay, mà là giúp tổ chức cùng chèo thuyền theo một hướng. Đó là tập trung không ngừng vào người dùng thay vì số dòng code hay tên mã dự án ngầu lòi.