Làm việc tổ yêu cầu lập kế hoạch, tổ chức và thời gian để phát triển tổ. Lắp ráp một nhóm người và tuyên bố họ là “tổ” không làm cho họ làm việc cùng nhau được.

Trong nhiều năm, tôi đã thấy các tổ được thành lập theo cách đó. Khi có nhu cầu, người quản lí lựa ra vài người và gọi họ là một “tổ”. Thông thường nhất, những người này được lựa chọn bởi vì họ sẵn có. Họ là những người chỉ mới hoàn thành một dự án và còn chưa được phân công vào dự án khác. Họ có thể là những người bị loại khỏi một dự án vì họ không được cần tới, hay không có kĩ năng đúng, hay họ không hoà hợp được với người khác.

Cách tốt nhất để lựa thành viên tổ là bằng mức độ kĩ năng. Mọi dự án đều nên có cân bằng giữa các thành viên có kinh nghiệm và thành viên ít kinh nghiệm. Người quản lí dự án nên được phép lựa chọn thành viên tổ thay vì lấy ngẫu nhiên bất kì ai sẵn có. Bằng việc làm điều đó, dự án sẽ có kĩ năng cần thiết để làm công việc. Câu hỏi thường được hỏi là: điều gì xảy ra nếu chúng ta không có người với kĩ năng đặc thù nhưng có những người đang sẵn có? Hay “Điều gì xảy ra nếu người quản lí dự án không muốn thuê người mới và yêu cầu bạn dùng những người sẵn có, cho dù họ có thể không có kĩ năng cần thiết?” Câu trả lời của tôi là: “Bạn có muốn bay trên máy bay khi phi công không sẵn có cho nên tiếp viên sẽ lái máy bay đó?”

Có người có kĩ năng là một trong vài yếu tố mấu chốt cho thành công dự án. Yếu tố mấu chốt thứ hai là làm sao làm cho những người này cùng làm việc với nhau như một tổ. Để làm điều đó, dự án phải có mục đích chung để cho các thành viên tổ có thể làm việc hướng tới nó. Điều này yêu cầu viễn kiến, một phát biểu mô tả cho trạng thái tương lai mà các thành viên tổ có thể hiểu và quyết tâm hỗ trợ nó. Nếu dự án không có viễn kiến chung làm sao tổ có thể làm việc cùng nhau hướng tới mục đích được? Khi Apple được thành lập, Steve Jobs đã giải thích viễn kiến của ông ấy cho tổ: “Làm máy tính thành đảm đương được để cho mọi hộ gia đình có thể mua một chiếc.” Viễn kiến của ông ấy là xây dựng công ti máy tính mà có thể cạnh tranh với các công ti máy tính khác như IBM và Digital Equipment, và mục đích của ông ấy là giữ cho giá thành hợp lí để cho mọi gia đình có thể mua nó. Thông điệp này là đơn giản và rõ ràng. Tổ tại Apple hỗ trợ nhiệt tình cho nó và đó là cách Apple tăng trưởng và làm biến đổi toàn bộ ngành công nghiệp máy tính. Vài năm sau, Bill Gates cũng có viễn kiến: “Đưa máy tính cá nhân vào mọi gia đình và chúng tất cả đều chạy phần mềm của Microsoft.” Viễn kiến này cũng là rõ ràng và năng nổ. Ông Gates đã không chỉ muốn bán phần mềm mà ông ấy muốn mọi máy tính dùng phần mềm của ông ấy chứ không của ai khác.

Sau khi tổ hiểu và quyết tâm hỗ trợ cho viễn kiến và mục đích, người quản lí dự án phải làm tài liệu viễn kiến, mục đích, mục tiêu, chủ định, cấu trúc tổ, khách hàng và các thành viên tổ cùng với vai trò, trách nhiệm và thẩm quyền trong kế hoạch dự án. Điều này rất quan trọng để tránh bất kì hiểu lầm nào hay xung đột vai trò về sau. Khi quản lí dự án phần mềm, tôi thường để cho tổ xác định “căn cước” để chia sẻ với phần còn lại của công ti. Các thành viên tổ đi tới một cái tên tổ và chúng tôi chụp tấm hình như một tổ cùng nhau và bổ sung thêm mô tả về tổ để đăng lên tường trong văn phòng của chúng tôi. Hoạt động phụ này đem tới nhiều vui đùa và giúp cho tổ cảm thấy gần nhau hơn. Tôi nhớ một số cái tên như “Quỉ viết mã” – chúng tôi viết mã hay hơn bất kì tổ nào. “Phần mềm thần thoại” – chúng tôi làm cho mọi thứ làm việc v.v. Một số người quản lí gọi điều đó là “trẻ con” nhưng hoạt động này thực tế gióng thẳng hành động của tổ với viễn kiến và mục đích của dự án. Nó là lí do của tổ để tồn tại và giúp tổ cô đọng các ý tưởng này vào một câu ngắn về họ là ai và họ làm gì.

Làm việc tổ yêu cầu vai trò và trách nhiệm rõ ràng. Nó xác định công việc được phân công cho các thành viên tổ, và liệt kê các mong đợi giữa các thành viên tổ. Nó phục vụ như bản hướng dẫn khi tổ xây dựng sản phẩm phần mềm. Sau khi giải thích viễn kiến và mục đích của dự án cho tổ, tôi bao giờ cũng hỏi ý kiến họ về điều họ cảm thấy sẽ là quan trọng với họ. Tôi viết những điều này ra rồi yêu cầu họ giải thích nó nghĩa là gì. Sau khi tôi có gợi ý của mọi người, chúng tôi thảo luận các ý tưởng này rồi tôi yêu cầu tổ chọn ra năm tới mười nguyên tắc làm “nguyên tắc vận hành” để tổ tuân theo. Nhớ rằng đây là qui tắc của họ, đây là điều họ chọn để tuân theo, và chúng không tới từ người quản lí. Chẳng hạn: Bao giờ cũng đi họp tổ đúng giờ. Bao giờ cũng hội tụ vào mục tiêu của cuộc họp tổ, không nói về các chủ đề không liên quan. Chúng tôi làm việc như một tổ, không như một cá nhân. Chúng tôi chia sẻ thông tin tự do giữa các thành viên. Chúng tôi yêu cầu giúp đỡ khi cần và chúng tôi sẵn lòng giúp đỡ khi được yêu cầu. Không ai có tri thức đầy đủ về dự án, từng người trong chúng tôi đóng góp phần chung ít hay nhiều. Sửa qui trình, không sửa người. Chúng tôi chia sẻ cùng đích tới và đi tới đó cùng lúc.

Bằng việc có viễn kiến, mục đích, chủ định của tổ, căn cước, vai trò và trách nhiệm, và qui tắc của tổ, tổ dự án sẵn sàng làm việc cùng nhau.

—-English version—-

Teamwork planning

Teamwork requires planning, organizing and time to develop the team. Assembling a group of people and declaring them “a team” does not make them working together. For years, I have seen teams formed that way. When there is a need, managers select a few people and called them a “Team”. Most often, these people are selected because they are available. They are people who just complete a project and have not been assigned to another. They may be people who are removed from a project because they are not needed, or do not have the right skills, or they do not get along with others.

The best way to select team members is by skill level. Every project should have a balance between experience and lesser experience members. Project manager should be allowed to select team members rather than just randomly pick anyone available. By doing that, the project will have the necessary skills to do the work. The question often asked are: what if we do not have the people with a particular skills but have people who are available? Or “What if managers do not want to hire new people and make you use the available people, even they may not have the needed skills? My answer is: “Do you want to fly in an airplane when the pilot is not available so the stewardess will fly that plane?”

Having skilled people is only one of several critical factors for the project success. The second critical factor is how to make these people work together as a team. To do that, the project must have a common goal so team members can work toward it. This require a vision, a statement that describe the future state that team members can understand and commit to support it. If the project does not have a shared vision how can the team work together toward a goal? When Apple was established, Steve Jobs explained his vision to his team: “Make computer affordable so every household can buy one.” His vision was to build a computer company that can compete with other computer companies such as IBM and Digital Equipment, and his goal is to keep the price reasonable so every household can buy it. The message was simple and clear. The team at Apple enthusiastically supported it and that is how Apple grew and transformed the entire computer industry. Few years later, Bill Gates also had a vision: “To put a personal computer in every home and they all run on Microsoft software.” This vision is also clear and aggressive. Mr. Gates did not just want to sell software but he want every computer to use his software and nobody else.

After the team understand and commit to support the vision and goal. Project manager must document the vision, goals, objectives, purpose, team structure, customers and team members with roles, responsibilities and authority into the project plan. This is very important to avoid any misunderstanding or roles conflict later. When managing software project, I often let the team define an “identity” to share with the rest of the company. Team members come up with a team name and we take a picture as a team together then add a description of the team to post on the wall in our office. This extra activity brings more fun and help the team feel close to each others. I remember some of the names such as “The Coding Monster” – we code better than any team. “Magic software” – we make everything work. Etc. Some managers called it “Childish” but this activity actually aligns the team’s actions with the project vision and goal. It is the team’s reason to exist and helps the team pull these ideas into a short sentence about who they are and what they do.

Teamwork requires clear roles and responsibilities. It specifies the team member’s assigned works, and list expectations between the team members. It serves as a guidance as the team builds the software product. After explaining the project vision and goal for the team, I always ask for their opinions about what they feel will be important to them. I write these things down then ask them explain what it means. After we have everyone’s suggestions, we discuss these ideas then I ask the team to select five to ten principles as the “operating rules” for the team to follow. Remember that this is their rules, this is what they choose to follow, and they do not come from a manager. For example: Always go to team meeting on time. Always focus on the objective of the team meeting, not talking about unrelated subjects. We work as a team, not as an individual. We share information freely among members. We ask for help when needed and we are willing to help when asked. Nobody has complete knowledge about a subject, each of us contributes a greater or lesser share. Fix the process, not the people. We share the same destination and arrive there at the same time.

By having vision, goals, team’s purpose, identity, roles and responsibilities, and team rules, the project team is ready to go to work together.