- Các nhóm lớn xoay quanh chuyên gia khiến năng suất và hiệu quả cộng tác suy giảm mạnh do phụ thuộc nội bộ, lỗi truyền đạt, nút thắt cổ chai và trách nhiệm bị phân tán
- Trong các cuộc họp standup hằng ngày, phần lớn nội dung trở nên không cần thiết hoặc nhàm chán; quy mô đội ngũ tăng lên và mức độ chuyên môn hóa cao hơn dẫn đến đứt gãy giao tiếp và sự thờ ơ
- Đã có nhiều thử nghiệm như tách theo kỹ năng kỹ thuật (frontend/backend), lập feature team tạm thời, sử dụng tư vấn bên ngoài, nhưng cuối cùng việc chuyển sang vai trò tổng quát hơn (generalist) mới mang lại hiệu quả thực tế rõ rệt nhất
- Hợp tác theo nhóm như Mob programming thúc đẩy chia sẻ kiến thức, tính tự chủ, tinh thần trách nhiệm và động lực; đồng thời có lợi hơn cho cách làm việc và phát triển dựa trên kết quả thay vì cố chấp với một lĩnh vực duy nhất
- Tuy vậy, tác dụng phụ của việc tổng quát hóa (suy giảm chuyên môn sâu, rủi ro burnout) cũng tồn tại, và cần liên tục thử nghiệm cùng cải thiện về mặt văn hóa
Vấn đề khi đội ngũ quá lớn
- Các vấn đề bắt đầu ở một nhóm lớn gồm 14 người: phần lớn cuộc trò chuyện trong standup là không cần thiết, việc bỏ sót truyền đạt công việc và các đầu việc không chính thức xảy ra thường xuyên
- Ngay cả khi chuyển sang standup bất đồng bộ (Slack, v.v.), các cuộc trao đổi và cơ hội cộng tác cốt lõi cũng biến mất, rồi dần biến thành những bản báo cáo đơn thuần
Nhiều thử nghiệm phân chia/vận hành khác nhau
- Tách theo kỹ thuật (Task Force): chia thành frontend/backend, nhưng ngay lập tức phát sinh vấn đề phụ thuộc lẫn nhau và thời gian họp tăng thêm vì phải tham gia nhiều standup
- Feature team tạm thời: điều chuyển nhân sự tạm thời theo từng chức năng cần triển khai, nhưng phát sinh vấn đề về bảo trì và quản lý nguồn lực
- Đưa tư vấn bên ngoài vào: dù đội ngũ vốn đã lớn vẫn kém hiệu quả, đồng thời chịu áp lực từ cấp quản lý cao hơn về việc tận dụng nguồn lực
Giải pháp cuối cùng thực sự hiệu quả
- Áp dụng mô hình generalist thay cho specialist
- Không tách biệt vai trò như frontend, backend, QA, DevOps mà cùng chia sẻ toàn bộ bộ kỹ năng xoay quanh một mục tiêu/sản phẩm
- Hiện thực hóa chia sẻ kiến thức, giảm phân tán trách nhiệm, tháo gỡ nút thắt cổ chai, bàn giao nhanh hơn/chất lượng cao hơn
- Tăng cường giao tiếp/tính tự chủ/quyền sở hữu thông qua hợp tác tập thể như Mob programming
Vì sao generalist lại hiệu quả
- Bối cảnh và mục tiêu chung: ngay cả ở lĩnh vực mới, đường cong học tập cũng được làm nhẹ hơn khi dựa trên cùng một sản phẩm/mục tiêu
- Nhu cầu giới hạn: chỉ cần nắm một số công cụ nhất định (CI/CD, v.v.) là đủ; ưu tiên năng suất và khả năng bảo trì hơn là chuyên môn quá sâu
- Đáp ứng đủ 3 yếu tố tạo động lực (tự chủ, thành thạo, mục đích), hỗ trợ tinh thần làm chủ và sự phát triển của cả nhóm
- Văn hóa bình đẳng: quyền truy cập bình đẳng, tự chủ tiếp thu tri thức, phân tán quyền hạn và trách nhiệm, học hỏi tập thể
- 3 yếu tố của trách nhiệm (kiến thức, quyền hạn, trách nhiệm) được xác định rõ ràng, từ đó tạo ra kết quả nhanh và chất lượng cao dựa trên quyền sở hữu
Tác dụng phụ và giới hạn
- Chuyên gia rời đi: việc tổng quát hóa không phù hợp với tất cả mọi người, có thể dẫn tới burnout ở một số cá nhân và tình trạng quá tải nguồn lực
- Thiếu chiều sâu chuyên môn: do phải xử lý nhiều stack theo chiều rộng, mức độ thành thạo sâu trong một lĩnh vực có thể bị cản trở
Kết luận và bài học
- Không có một lời giải áp dụng đồng loạt; văn hóa thử nghiệm và cải tiến mới quan trọng hơn
- Có thể giải quyết các nhược điểm của mô hình specialist (nút thắt cổ chai, đứt gãy giao tiếp, fake work, đứt mạch bối cảnh) bằng generalist và cộng tác tập thể
- Cuối cùng, mô hình tối ưu có thể khác nhau tùy theo mục tiêu, nhân lực, ngân sách và đặc tính sản phẩm
- Cốt lõi là văn hóa thử nghiệm cởi mở, phản hồi và cải tiến liên tục
4 bình luận
Tôi là một người theo hướng generalist, nhưng điều tôi cảm nhận trong công việc thực tế là thế này.
Người hữu ích là generalist, nhưng những người thực sự được công nhận về "giá trị" lại là specialist.
Ngay cả khi học cùng trường đại học, có cùng điểm số, thì thực tế cuối cùng specialist vẫn nhận mức đãi ngộ cao hơn gấp 2~3 lần.
Tôi cũng có suy nghĩ tương tự.
Nhưng theo tôi, xét theo tiêu chuẩn phần mềm, nếu không phải là deep tech ở Mỹ thì specialist có vẻ không thực sự đặc biệt.
Có thể cho mình xin một ví dụ được không! Mình tò mò trên thực tế mức độ “đặc biệt” để được gọi là specialist là đến đâu...
Theo tiêu chí của HR, có vẻ các tập đoàn lớn hoặc doanh nghiệp cỡ vừa thường yêu cầu khoảng 3 năm kinh nghiệm, còn theo tiêu chí của tôi, một “specialist” là người mà từ góc nhìn backend có thể tận dụng LLM để thiết kế kiến trúc sao cho ai cũng có thể dễ dàng sử dụng, đồng thời vẫn tính đến cả tính sẵn sàng cao.
Ví dụ, tôi là một generalist, nhưng với bất kỳ dịch vụ nào trong nước, tôi đều có thể thiết kế cho lưu lượng hơn 100 triệu người dùng theo cách đơn giản đến mức cả học sinh tiểu học cũng hiểu được.
Nhưng rồi vì tôi là generalist nên hồ sơ nộp vào các tập đoàn lớn lại bị loại haha