Ngày nay nhiều dự án phần mềm là lớn và làm việc tổ đang trở nên quan trọng hơn để giữ mọi người làm việc cùng nhau. Không may nhiều người quản lí không được đào tạo về làm việc theo tổ cho nên khi dự án gặp vấn đề, họ không biết cách giải quyết nó. Điều đầu tiên người quản lí có thể làm là tạo điều kiện cho cuộc họp nơi mọi người có thể nói với nhau.

Vài năm trước, tôi đã được yêu cầu tiếp quản một dự án lớn trên hai trăm người phát triển bởi vì người quản lí dự án đã rời bỏ việc này. Dự án này được chia thành bốn nhóm chức năng chính nơi họ phải tương tác với nhau để làm cho công việc được thực hiện. Sau vài ngày, tôi thấy rằng mối quan hệ của họ với nhau là không tốt. Từng nhóm đều nhìn nhóm khác như kẻ gây chuyện và cản trở tiến bộ của họ. Để giúp họ xây dựng mối quan hệ hài hoà, tôi triệu tập một cuộc họp tại đó tôi để họ chia thành những tổ nhỏ, với từng tổ bao gồm những người của tất cả bốn nhóm.

Khi họ thành lập tổ, tôi yêu cầu họ tự giới thiệu mình cho nhau. Bên cạnh tên họ và vai trò kĩ thuật, tôi cũng yêu cầu họ nói đôi điều về bản thân họ như sở thích riêng, mối quan tâm hay bất kì cái gì họ muốn chia sẻ. Tôi ngạc nhiên, một số thành viên của bốn nhóm chưa bao giờ gặp gỡ và đó có lẽ là lí do mà họ thấy lỗi ở nhau. Tôi yêu cầu họ nói chuyện với bạn thân trong tổ về mọi vấn đề xoay quanh dự án để xác định xem họ đang có vấn đề kĩ thuật gì, vấn đề khách hàng gì, hay vấn đề cá nhân gì. Sau khi họ thảo luận từng vấn đề trong tổ nhỏ của họ, tôi tụ tập họ lại như một nhóm để cho họ có thể báo cáo về những phát kiến và khuyến nghị của họ.

Một khi họ bắt đầu nói, họ nhận ra họ đã hiểu về trách nhiệm và hoạt động của nhau ít làm sao. Họ phát hiện ra rằng một số vấn đề họ đã trách cứ lẫn nhau vì có những giải thích hợp thức, như yêu cầu mơ hồ, mong đợi không rõ rệt, và ưu tiên từng nhóm có mà nhóm khác lại không nhận biết do dựa trên cái vào họ đã nhận được từ khách hàng. Một số các vấn đề của họ có thể được giải quyết dễ dàng với vài thay đổi đơn giản. Ngay cả một số vấn đề lớn hơn cũng có giải pháp mà có thể mất thời gian lâu hơn nhưng không phải là không thể giải được. Về toàn thể, có thể giải quyết các vấn đề này một  khi họ biết phải làm gì cũng như ai chịu trách nhiệm giải quyết chúng. Thảo luận của họ về nhu cầu của mình đưa họ tới kết luận rõ ràng: Dưới dạng trách nhiệm, họ có nhiều điểm chung, và có thể hoàn thành được nhiều điều bằng việc cộng tác hơn là bằng tranh cãi và trách móc lẫn nhau.

Để kết luận phiên này, tôi yêu cầu họ thảo luận họ sẽ làm gì tiếp sau để cải tiến mối quan hệ của họ. Điều đầu tiên họ đi tới là ở chỗ họ muốn tiếp tục đối thoại của họ qua những cuộc họp đều đặn. Những gợi ý khác bao gồm dành thời gian trong khu vực của nhau như người quan sát, tạo ra wiki để nắm bắt mối quan tâm chung, và cam kết thảo luận các vấn đề thay vì trách móc lẫn nhau.

Cuộc họp này chỉ kéo dài một ngày nhưng hầu hết những người phát triển ra về với cảm nhận tích cực hơn và hiểu biết sâu hơn về ba nhóm kia. Tất nhiên, cuộc họp này cũng chỉ là điểm bắt đầu trong việc giải quyết vấn đề của tổ và cải tiến mối quan hệ của họ. Tuy nhiên, họ đã hoàn thành nhiều điều đơn giản chỉ bằng để thời gian nói và hiểu lẫn nhau.

—-English version—-

Teamwork in large project

Today many software projects are large and teamwork is becoming more important to keep people working together. Unfortunately many managers are not trained in teamwork so when projects encounter problem, they do not know how to solve it. The first thing a manager could do is to facilitate a meeting where people can talk to each others.

Few years ago, I was asked to take over a large project of over two hundreds developers because the project manager had quit the job. The project was divided into four major functional groups where they must interact with each others to get the work done. After several days, I found that their relationships with each other were not good. Each group saw the other as trouble-makers and hindrances to their progress. To help them build harmonious relationships, I called a meeting where I had them divide into small teams, with each team comprising people from all four groups.

As they formed teams, I asked them to introducing themselves to each other. Beside their names and technical roles, I also asked them to say something about themselves such as hobbies, interests or anything that they wanted to share. To my surprise, some members of the four groups had never even met and that was probably the reason that they find fault with each other. I asked them to talk with their team-mates about all issues that revolved around the project to determine whether they are technical issues, customer issues, or personal issues. After they discussed each issue in their small team, I gathered them together as a group so they could report their findings and recommendations.

Once they started talking, they realized how little they had understood about each others’ responsibilities and activities. They discovered that some problems they had blamed each other for had valid explanations, such as ambiguous requirements, unclear expectations, and priorities each group had that the others were unaware of based on the inputs that they received from customers. Some of their problems could be readily resolved with few simple changes. Even some larger problems had solutions that may take longer but were far from impossible. Overall, it was possible to solve these problems once they know what to do as well as who were responsible to solve them. Their discussions of their needs led them to a clear conclusion: In terms of their responsibilities, they had a lot in common, and could accomplish more by collaborating than by arguing and blaming each others.

To conclude the session, I asked them to discuss what they’d like to do next to improve their relationships. The first thing they came up with was that they wanted to continue their conversations through regular meetings. Other suggestions included spending time in each other’s areas as observers, creating a wiki for capturing shared concerns, and committing to discuss issues rather than blaming each others.

The meeting only lasted one day but most developers left with a more positive perception and deeper understanding of the other three functional groups. Of course, the meeting were just a starting point in solving team’s problems and improve their relationship. However, they had accomplished a lot simply by taking the time to talk and understand each others.