Trong một dự án dài, có những ngày team bắt đầu rất bình thường: standup mười lăm phút, vài task còn dang dở trên board, một blocker vừa xuất hiện trong project channel, một stakeholder hỏi cập nhật, và ai đó nhắc rằng deadline vẫn không tự biến mất. Không khí đó làm mình nghĩ tới Tây Du Ký theo một cách khá công sở. Hành trình thỉnh kinh không chỉ là một câu chuyện phiêu lưu, mà còn giống một project team đi qua rất nhiều chặng bất định.
Nếu bỏ lớp hình ảnh văn học sang một bên, ta thấy một cấu trúc rất quen. Có một mục tiêu dài hạn. Có sponsor và người bảo trợ từ xa. Có người giữ mission. Có người giỏi xử lý khủng hoảng. Có người làm vận hành. Có người giữ hạ tầng. Có những blocker lặp đi lặp lại. Có những lần cần escalation vì team tại chỗ không đủ quyền hoặc đủ thông tin để xử lý tận gốc.
Trong công sở, rất nhiều dự án cũng giống vậy. Một migration lớn, một sản phẩm mới, một chương trình chuyển đổi quy trình, một lần tái cấu trúc nội bộ. Lúc khởi đầu, mọi thứ nghe rất sáng: mục tiêu rõ, kế hoạch có vẻ ổn, ai cũng tin mình sẽ đi đúng đường. Nhưng chỉ vài sprint sau, thực tế bắt đầu hiện ra. Requirement đổi, khách hàng phản hồi khác dự đoán, dependency kẹt, người phụ trách nghỉ phép, bug production kéo cả team ra khỏi roadmap. 81 kiếp nạn trong câu chuyện có thể đọc như những lần thực tế kiểm tra xem team có phối hợp thật hay chỉ có kế hoạch đẹp.
Điều mình thích ở lăng kính project team là nó giúp bớt kỳ vọng rằng một team tốt phải gồm toàn người hoàn hảo. Đường Tăng có vision nhưng yếu trong xử lý khủng hoảng. Ngộ Không giỏi nhưng bốc đồng. Bát Giới làm team bớt căng nhưng dễ nản. Sa Tăng ổn định nhưng ít đột phá. Bạch Long Mã thầm lặng nhưng là nền vận hành. Nhìn vậy, một team thật cũng không khác nhiều: người giỏi kỹ thuật chưa chắc giỏi stakeholder, người giao tiếp tốt chưa chắc xử lý được root cause, người vận hành đều chưa chắc tạo đột phá, người có vision chưa chắc hiểu từng chi tiết triển khai.
Một team bền không phải vì ai cũng tròn. Team bền vì những phần méo của mỗi người được đặt cạnh phần mạnh của người khác một cách hợp lý. Nếu bắt Đường Tăng tự đánh yêu quái, dự án vỡ. Nếu để Ngộ Không tự quyết toàn bộ mission, dự án có thể chạy rất nhanh nhưng lệch. Nếu chỉ có Bát Giới, team có không khí nhưng thiếu lực phá khó. Nếu chỉ có Sa Tăng, team ổn định nhưng thiếu khả năng mở đường. Nếu thiếu Bạch Long Mã, cả nhóm đi chậm hơn nhiều dù ai cũng có ý chí.
Quy trình incident trong tư liệu cũng rất dễ liên tưởng. Blocker xuất hiện, người giữ project bị kẹt, lead engineer nhảy vào hotfix, team mở một thread khẩn, có người hỏi rollback có an toàn hơn không, rồi sự cố được escalation lên người có quyền hơn để xử lý nguyên nhân thật. Ở công ty, chuyện này xảy ra thường xuyên. Một bug không sửa được vì lỗi nằm ở vendor. Một quyết định không chốt được vì thiếu sponsor. Một khách hàng giận không chỉ vì tính năng lỗi, mà vì hợp đồng ban đầu hứa sai. Nếu team chỉ lo đánh nhau với biểu hiện bên ngoài, vấn đề sẽ quay lại dưới hình thức khác.
Escalation tốt không phải là đẩy trách nhiệm lên trên. Nó là biết khi nào vấn đề vượt khỏi quyền hạn hoặc năng lực của team hiện tại. Một engineer giỏi có thể sửa code, nhưng không thể tự thay đổi điều khoản hợp đồng. Một PM giỏi có thể điều phối timeline, nhưng không thể một mình giải quyết conflict chiến lược giữa hai phòng ban. Một support lead có thể xoa dịu khách hàng, nhưng nếu sản phẩm liên tục tạo cùng một lỗi, cần người có quyền thay đổi roadmap. Biết leo thang đúng lúc là một kỹ năng trưởng thành, không phải dấu hiệu yếu.
Mình cũng thấy Tây Du Ký nhắc rằng project dài luôn là quá trình rèn tính cách. Không phải theo nghĩa cao siêu, mà rất đời: người nóng học cách chậm lại, người nản học cách đi tiếp, người giữ vision học cách lắng nghe người thực thi, người thầm lặng học cách tạo giá trị rõ hơn. Một dự án khó không chỉ giao ra sản phẩm. Nó làm lộ cách mỗi người phản ứng khi bị áp lực.
Trong văn phòng, mình thường thấy điều này sau một release khó. Có người bắt đầu biết báo risk trước sprint review thay vì đợi deadline trễ rồi mới nói. Có người học được rằng không nên tự merge lúc mệt. Có người bớt xem stakeholder là người làm phiền, vì hiểu họ cũng chịu áp lực từ phía khác. Có người nhận ra mình không thể chỉ là người nhận task, mà phải hiểu context rộng hơn. Sau mỗi chặng khó, team hoặc lớn lên một chút, hoặc chỉ mệt thêm mà không học được gì. Khác biệt nằm ở việc có nhìn lại đủ bình tĩnh không.
Ghi chép này làm mình nghĩ rằng một project team tốt không cần thần thoại hóa teamwork. Teamwork thật nhiều khi rất lộn xộn: có người than, có người nóng, có người im, có người cứu nguy, có người giữ đồ, có người giữ đường. Điều quan trọng là cả nhóm vẫn còn một hướng chung, vẫn còn cơ chế phối hợp khi blocker xuất hiện, và vẫn còn khả năng học sau mỗi lần vấp. Nếu một team đang đi qua một hành trình dài, câu hỏi đáng giữ không phải là ai hoàn hảo nhất, mà là vai nào đang thiếu, ranh giới nào đang mờ, và sau kiếp nạn gần nhất team đã học được điều gì để chặng sau bớt lặp lại?