Một trong những cái đau đớn nhất của việc làm việc theo nhóm, đó là: phải làm cùng 1 chú leader gà con đầu óc rỗng tuếch và quan liêu.
Điều đau đớn thứ hai, đó là khi mình thẳng thắn chỉ ra chỗ sai của hắn, thì những thằng cùng nhóm khác bỏ ngoài tai và quay ra liếm đ’t thằng leader.

Cũng phải công nhận mình chả giỏi giang gì nên mới sa chân vào những cái nhóm làm việc như thế, và cũng chả phải thằng có tinh thần teamwork lắm khi hay chê bai chỉ trích đứa khác. Tự làm mọi thứ 1 mình thì lại thấy workload quá lớn mình không kham nổi. Qua lần này rút ra một vài kinh nghiệm về làm việc nhóm.

Nếu bạn được chọn làm leader:

- Luôn nhớ rằng “you are leading people, not managing them”. Thử đặt mình vào vị trí 1 thằng developer, sẽ rất khó chịu khi bị chú leader không có trình độ chuyên môn mà cứ áp đặt những cách làm rất trâu bò và thiếu mềm dẻo cho mình. “Leader” khác “manager” ở chỗ, leader cần trình độ chuyên môn cao hơn, biết nhiều về chi tiết kĩ thuật hơn, và thực sự xét về mặt quyền lực thì ngang hàng với các thành viên khác, chỉ có thêm trách nhiệm “dẫn đầu đàn” và “điều phối hoạt động” cho toàn nhóm. Mọi quyết định là do đa số trong nhóm cùng nhau nhất trí, chứ không bị áp đặt bởi một ai cả.

- Vấn đề deadline cần được đối xử một cách tế nhị, nhất là đối với một project dính dáng đến phần mềm, ứng dụng web .v.v. Gia công phần mềm nó khác với việc “đánh cho xong bản report” hay “thắt cà vạt trong vòng 30 giây”. Bạn chỉ có thể đặt ra các mốc thời gian dự định mềm dẻo, chứ khó có thể kiểm soát được một hạn định cụ thể cho một dự án dù nhỏ hay to. Trên thực tế, việc cho ra sản phẩm chậm hơn hạn định dự kiến 3 tháng - 6 tháng là chuyện bình thường, và thậm chí đã có thể coi là “best practice”. Đó là do trong quá trình gia công, không thể lường được hết các thay đổi về mặt kĩ thuật, cũng như lỗi chương trình .v.v. Không nhận thức được điều này, và o ép các thành viên cùng nhóm khác phải hoàn thành trước deadline dĩ nhiên sẽ dẫn đến thất bại của dự án.

- Nếu được phép lựa chọn thành viên, thà chọn ít nhưng chất lượng còn hơn chọn nhiều mà thằng nào cũng làng nhàng. Tớ bị rơi vào hoàn cảnh này nhiều lần. Ghét nhất là phải học lớp nào mà thày không cho chọn nhóm, mà chỉ định nhóm cho từng thành viên. Kết quả là vào toàn nhóm ất ơ. Một nhóm có 6 đứa chẳng hạn, thì 3 đứa là “free rider” (cùng nhóm cho lấy lệ, chứ chả đóng góp gì sất!). Cuối cùng thì cả đội chán nản và một mình mình phải è cổ ra làm hết phần của bọn nó, hay nói cách khác là biến thành “servant” chứ chả phải “leader”. Hiện tại đang làm 1 cái project lèm nhèm của 1 đứa châu Phi nó lead. Do không có hiểu biết về chính lĩnh vực của cái dự án, nên nó toàn lôi bạn bè vớ vỉn vào, rồi chia 2 nhóm, 1 nhóm design (trong đó có thằng lít đờ) và 1 nhóm coder cho trang web. Trong khi mấy cha coder è cổ ra đọc documentation và “vừa xây vừa phá vừa sửa”, thì mấy ông designer thiết kế 1 cái logo mà tớ dùng paint tớ còn vẽ được đẹp hơn, rồi dựng ra 1 cái layout cho trang web mà trông như blog của mấy bạn 9x và cứ nghĩ chỉ việc thay image cho cái default theme của drupal là mọi thứ sẽ hiện ra như ý muốn. Nhưng đâu có đơn giản thế! Cuối cùng việc code cái template rồi lại sẽ phải vào tay bọn coder thôi!

- Gạch đầu dòng cuối cùng, và cũng là quan trọng nhất: Nếu không có trình độ kĩ thuật bằng bọn cùng nhóm, thì nên tập cách lắng nghe. Xét cho cùng thì nếu trình độ không bằng bọn khác thì cũng khó mà có thể đảm đương làm leader được, vì nói chả ai nghe. Nếu muốn người khác nghe mình, thì phải nghe người khác nói trước đã. Hồi trước tớ đọc trong Rich dad Poor dad, có ví dụ về ông Ford. Tớ cũng chả nhớ rõ chi tiết lắm, nhưng đại loại là có người chê Henry Ford (sáng lập ra hãng xe ô tô Ford) là giàu thì có giàu thật, nhưng trình độ văn hóa chưa quá lớp 3. Thế là Ford mới thách người kia hỏi bất cứ câu gì ông cũng trả lời được. Và khi được hỏi về lĩnh vực nào, Ford liền mời cố vấn của mình về vấn đề đó ra giải đáp đâu ra đấy. Tóm lại là, leader giỏi không hoàn toàn đòi hỏi trình độ kĩ thuật phải cao hơn người khác. Mà cái quan trọng là biết chọn người giỏi làm việc cùng mình, và biết nghe ý kiến của người ta, chứ không phải lúc nào cũng coi mình là nhất, và mọi người phải theo ý mình. Chả ai muốn bị một thằng dốt hơn mình giật dây cả.

Còn nếu bạn không phải (hoặc không muốn) làm leader, sau đây có lẽ là vài lời khuyên cho bạn khi phải làm việc theo nhóm:

- Biết nói “không” khi cần thiết. Nếu bạn được mời vào làm cùng một project hứa hẹn lương lậu các thứ rất hấp dẫn đến mấy, nhưng nhìn vào đội hình các team mates mà khấp khểnh, thì nên cân nhắc kĩ trước khi đồng ý. Đến lúc “sa chân vào vũng lầy” không rút ra được, thì bạn sẽ bị dằn vặt vì đã để mình phí thời gian vào nhưng thứ vô ích và vì cảm giác mình bị kẻ khác lợi dụng.

- Biết thẳng thắn đưa ra ý kiến của mình và chả phải sợ bố con thằng nào cả. Nếu bạn gặp leader giỏi, ý kiến của bạn tức khắc được trân trọng dù đúng hay sai. Còn nếu gặp leader tồi, thì lại càng phải thẳng thắn, vì càng thẳng thắn thì cơ hội bị “đá đít” ra khỏi group càng cao. Và khi bị đá đít ra rồi thì bạn rảnh tay để làm việc khác mà không lo gì về trách nhiệm đối với group cũ cả. Hơn nữa thẳng thắn là đức tính tốt, còn “nói lươn nói lẹo”, ba phải cho vừa lòng kẻ khác thì là một biểu hiện của sự hèn nhát.

- Luôn có tinh thần học hỏi người giỏi hơn, và giúp đỡ người kém hơn. Sẽ chả phải hay ho gì nếu bạn chỉ ngồi một chỗ và than trời vì group của bạn toàn thằng kém hơn mình. Tốt nhất là nên xắn tay lên và giúp đỡ họ giỏi hơn bằng mọi cách có thể. Còn nếu bạn là “chú gà con xấu xí” trong nhóm, thì cũng chả việc gì phải mất tự tin. Nếu bạn không tỏ ra kiêu kì và bảo thủ, người giỏi hơn sẽ sẵn lòng chỉ dạy cho bạn. Nếu biết tiếp thu những cái giỏi và lọc ra những cái sai thì chả mấy chốc mà bạn giỏi bằng hoặc hơn người ta.

- Đừng ôm đồm trách nhiệm, chỉ cần làm tốt phận sự của mình và giúp đỡ người khác đúng mức. Nếu công việc của bạn được giao là “code cái template”, thì cứ code cho tốt cái đã. Còn nếu các thành viên khác không chịu làm việc, thì cũng chả việc gì phải lo lắng để mà làm hết các phần việc khác cho bọn nó. Chuyện thất bại là chuyện bình thường, và chả có gì đáng xấu hổ cả khi bạn đã cố gắng hết sức cho phần việc của mình. Tớ thì tớ thường hay lo bọn cùng nhóm nó không chịu làm việc, kéo điểm của mình xuống. Nên cuối cùng toàn là tớ lo việc type cái report, làm cái powerpoint và viết sẵn cái script cho bọn kia nó đọc lúc presentation. Nhưng từ giờ nhất định chả phải coi nặng chuyện điểm chác nữa, chỉ làm phần việc của mình, thời gian còn lại để làm việc khác có ích hơn.

Còn đây là một vài lời khuyên chung cho cả leader lẫn thành viên bình thường:

- Chỉ nên nêu ý kiến khi mình thật sự có kiến thức về những cái mình định nói. Nếu ba hoa bốc phét về một vấn đề mà mình không biết chắc thì sẽ làm giảm uy tín của bản thân, sau này nói chả ai muốn nghe nữa.

- Luôn có tinh thần tích cực khi tham gia. Không nên bàn lùi hay quá bi quan về tiến độ của dự án.

- Trong đầu luôn phải tính toán cả những trường hợp xấu nhất (thất bại). Nếu bạn chưa lo xong các vấn đề nền tảng thì đừng nghĩ ngay tới việc quảng cáo cho sản phẩm khi thực sự chưa làm ra được nó. Và đừng quá nghiêm khắc khi kế hoạch của bạn thất bại, mà nên nhìn lại vấn đề một cách tích cực, đưa ra nhận xét và rút ra bài học.

- Tìm và thống nhất phong cách làm việc phù hợp nhất. Ví dụ như nếu các thành viên nhà ở xa nhau, hay không thể xếp lịch cho meeting được, thì nên tìm phương cách khác để communicate với nhau, ví dụ như sử dụng bulletin board, instant messenger .v.v. Có rất nhiều web app hỗ trợ project management miễn phí. Không phải cứ lúc nào cũng mặc vest và dắt díu nhau đi họp một cách formal là tỏ ra chuyên nghiệp. Chuyên nghiệp hay không là ở năng suất, không phải do hình thức.

- Và lời khuyên cuối cùng: tốt nhất hãy làm sao để bạn có thể hoàn thành công việc một mình, hoặc cùng lắm thì chỉ cần group nhỏ (dưới 4 người). Nếu bạn đang chuyên về flash chẳng hạn, thì hãy cố mở rộng sang web designing bằng XHTML/CSS, rồi theming in Drupal, Joomla, Wordpress .v.v. và cố master ít nhất 1 ngôn ngữ lập trình web nữa. Tất nhiên làm việc được một mình là trường hợp lí tưởng, còn không thì cùng làm với vài ba người thân cận nhất mà bạn tin tưởng được. Càng cho thêm các thành viên mà độ tin cậy chưa cao thì rủi ro của dự án lại càng lớn.

Tớ kết lại bài viết này bằng câu sau, trích trong bài phỏng vấn với Steve McConnell khi nói về software engineering, ý nghĩa thì cũng quá rõ ràng rồi nhỉ

a quarter of the projects are canceled before they’re completed and another 50 percent are completed over budget or behind schedule. And 25 percent are completed on time and on schedule, but the piece that’s always missing from those surveys is how much of the original functionality was delivered in that 25 percent that was on time and on budget.