Chiếc bàn lập kế hoạch hôm ấy có nhiều laptop hơn chỗ trống. Người phụ trách sản phẩm mở ghi chép từ khách hàng. Người thiết kế chỉ vào bản mẫu. Hai kỹ sư so sánh các phương án API. QA hỏi chuyện gì xảy ra nếu nhà cung cấp thanh toán bị timeout. Người làm hỗ trợ nhắc nguyên câu khách vẫn lặp lại trong ticket. Lần này, căn phòng không chuyền việc từ bộ phận này sang bộ phận khác; mọi người đang cùng hiểu một kết quả cần tạo ra.
Đó là lời hứa cốt lõi của cross-functional team. Thay vì làm như cuộc chạy tiếp sức dài — bộ phận sản phẩm viết yêu cầu, thiết kế lên bản vẽ, kỹ thuật xây, QA kiểm thử rồi hỗ trợ nhận phần hậu quả — mô hình này đưa đủ năng lực cần thiết lại gần nhau để đi từ vấn đề tới bài học với ít lần bàn giao hơn. Mục tiêu không phải xóa chuyên môn, mà là đặt các chuyên môn đủ gần để quyết định được cải thiện khi công việc vẫn còn dễ uốn.
Bàn giao tốn kém vì ngữ cảnh luôn rơi rớt. Tài liệu yêu cầu không chứa hết mọi cuộc trò chuyện. File thiết kế không kể hết mọi đánh đổi. Ticket không đoán được tất cả edge case. Khi việc đến tay bộ phận tiếp theo, lý do ban đầu có thể chỉ còn một lớp rất mỏng. Làm việc liên chức năng giảm thất thoát ấy bằng cách để câu hỏi xuất hiện ngay lúc ý tưởng đang hình thành.
Một nhóm liên chức năng tốt được tổ chức quanh kết quả, không chỉ quanh backlog. Kết quả có thể là tăng tỷ lệ kích hoạt, giảm thanh toán lỗi, làm onboarding bớt rối hoặc giảm số ticket cho một tính năng khó hiểu. Khi cùng giữ một đích đến, mỗi chuyên môn sẽ đưa ra quyết định tại chỗ tốt hơn: người thiết kế đơn giản hóa luồng, kỹ thuật chọn hướng phù hợp, QA kiểm tra rủi ro quan trọng, bộ phận hỗ trợ xác nhận thay đổi có thật sự giúp người dùng.
Điều đó đòi hỏi quyền làm chủ thật. Nếu chỉ mượn người vào họp còn mọi quyết định vẫn nằm ở nơi khác, “cross-functional” chỉ là nhãn. Nhóm cần quyền ưu tiên trong phạm vi được giao, được tiếp cận dữ liệu đo kết quả và có đường rõ ràng để đưa những đánh đổi vượt thẩm quyền lên cấp phù hợp. Thiếu các điều này, sự liên chức năng chỉ tồn tại trên lời mời họp.
Các nhịp phối hợp nên nhẹ nhưng có mục đích. Buổi xem xét khám phá giúp thống nhất vấn đề. Buổi phản biện thiết kế làm lộ rủi ro sử dụng. Buổi rà soát kỹ thuật phơi ra chi phí kiến trúc. Kiểm tra trước phát hành kéo QA, observability, hỗ trợ và phương án rollback vào cùng một cuộc trao đổi. Đích đến không phải nhiều cuộc họp hơn, mà là ít bất ngờ muộn hơn.
Chiều sâu chuyên môn vẫn rất quan trọng. Làm việc liên chức năng không có nghĩa ai cũng thành người biết rộng nhiều mảng và làm mọi thứ ngang nhau. Người thiết kế vẫn mang nghề thiết kế. Kỹ sư vẫn bảo vệ chất lượng hệ thống. QA vẫn đào sâu các đường hỏng. Người làm sản phẩm vẫn chịu trách nhiệm về giá trị và ưu tiên. Cả nhóm mạnh lên khi mỗi người có nghề rõ ràng, đồng thời đủ tò mò để hiểu nghề ngay bên cạnh.
Bất đồng là bình thường, thậm chí có ích nếu được xử lý tốt. Phía sản phẩm muốn nhanh. Kỹ thuật nhìn thấy technical debt. Phía thiết kế thấy một tương tác gây rối. QA thấy đường lỗi chẳng ai muốn nhắc. Bộ phận hỗ trợ nghe ngôn ngữ từ người dùng trái với giả định nội bộ. Những căng thẳng này không chứng minh nhóm đang hỏng; chúng chính là lý do nhóm tồn tại. Việc cần học là làm cho bất đồng đủ cụ thể, dựa trên bằng chứng và quay về kết quả chung.
Mô hình này có thể thất bại khi trách nhiệm bị làm mờ. Nếu “ai cũng sở hữu mọi thứ”, phần theo dõi khó đôi khi lại chẳng thuộc về ai. Một nhóm lành mạnh nói rõ ai quyết định, ai đưa việc tới đích và ai chịu trách nhiệm vận hành. Kết quả chung không xóa trách nhiệm cá nhân; nó cho mỗi trách nhiệm một bối cảnh tốt hơn.
Nó cũng thất bại khi mọi người quá bận để học. Áp lực giao hàng dễ kéo công việc về một mini-waterfall: sản phẩm viết yêu cầu một mình, thiết kế bàn giao, kỹ thuật mất hút, QA nhận bản build quá muộn. Cách sửa thường không lớn nhưng phải lặp lại: đưa rủi ro lên sớm, cho nhau xem việc còn dang dở, kiểm tra giả định sớm hơn và giữ tín hiệu từ bộ phận hỗ trợ hoặc khách hàng ở gần.
Tôi thích cách làm liên chức năng vì nó tôn trọng cách phần mềm thật sự được làm ra. Một tính năng hữu ích không chỉ là code, thiết kế, roadmap hay ca kiểm thử. Nó là kết quả của nhiều kiểu phán đoán gặp nhau quanh cùng một vấn đề. Để những phán đoán ấy xa nhau quá lâu, sản phẩm sẽ trả giá bằng việc làm lại. Đưa chúng tới gần đủ sớm, nhóm có cơ hội làm ra thứ bình tĩnh hơn và sát nhu cầu hơn.
Độ trưởng thành của một nhóm không nằm ở sơ đồ tổ chức hay cái nhãn “cross-functional”. Nó hiện ra ở những chỗ ngữ cảnh từng bị rơi giữa sản phẩm và thiết kế, thiết kế và kỹ thuật, kỹ thuật và QA, phát hành và hỗ trợ. Mỗi lần một bàn giao trở thành cuộc trao đổi, và mỗi kết quả chung trở thành tiêu chí cho quyết định hằng ngày, khoảng rơi ấy nhỏ đi thêm một chút.