Quản lí dự án phần mềm là tuyển tập các kĩ thuật để quản lí phát triển các kiểu đa dạng sản phẩm phần mềm. Nó bao gồm chọn lựa vòng đời phát triển phần mềm; các phương pháp ước lượng kích cỡ và lịch biểu dự án; tri thức và kĩ năng được cần cho các thành viên tổ; theo dõi và quản lí rủi ro v.v.

Về lí thuyết, người quản lí dự án ra mọi quyết định và làm tài liệu các chọn lựa trong bản kế hoạch dự án. Tuy nhiên, trong thực tại, lập kế hoạch dự án phần mềm thường yêu cầu sự tham gia của các thành viên tổ vì họ cũng có những kĩ năng và kinh nghiệm nào đó. Có nhiều quyết định cần đưa ra trong thời kì lập kế hoạch này với các cách tiếp cận khác nhau tới quản lí dự án. Sau trên 30 năm quản lí dự án phần mềm, tôi tin rằng bằng việc để các thành viên tổ cùng tham gia vào việc lập kế hoạch dự án từ sớm sẽ cho tổ một cảm giác quyền làm chủ và tình đồng chí và dễ dàng thu được cam kết từ họ.

Làm việc tổ không phải bao giờ cũng tới một cách tự nhiên; nó phát triển sau khi các thành viên tổ đi tới biết lẫn nhau và trở nên làm việc thoải mái cùng nhau. Các thành viên tổ không cần phải là những người bạn tốt nhất, nhưng họ quả cần có mối quan hệ chuyên nghiệp hiệu quả để cho làm việc tổ phát triển và cần thời gian để xây dựng mối quan hệ này. Tôi thường cố vấn cho người quản lí dự án để hẳn một ngày mỗi tháng cho các hoạt động tổ bên ngoài công ti, nơi các thành viên có thể thảnh thơi trong môi trường không làm việc và biết lẫn nhau. Các hoạt động này có thể là cắm trại cả tổ, tới thăm công ti khác, chuyến đi tới cuộc hội nghị hay bữa tiệc của tổ nơi họ chơi trò chơi video cùng nhau và thi đấu để được giải thưởng vui đùa v.v. Tổ chơi hay cùng nhau sẽ làm việc tốt cùng nhau.

Quản lí dự án phần mềm hiệu quả là cốt yếu để đạt tới kết quả thành công. Về lí thuyết, người quản lí dự án xây dựng viễn kiến cho dự án và chắc rằng tổ được cam kết làm việc theo viễn kiến đó. Tuy nhiên, trong thực tại điều sẽ tốt hơn là để cả tổ cùng đi tới viễn kiến này cho dự án sau khi cân nhắc cả các vấn đề kĩ thuật lẫn quản lí. Mục đích cho dự cần được đồng ý bởi cả tổ. Trong khi quyết định về các mục đích, mọi yếu tố phải được xem xét, kể cả tài nguyên, lịch biểu, chất lượng, ngân sách v.v. Tổ dự án nên có cơ hội để tranh cãi về các yếu tố này một cách đầy đủ để đi tới kết luận riêng của mình.

Tôi thường cố vấn cho người quản lí dự án đề nghị họ hình dung ra thành công dự án sẽ giống như cái gì. Khi thành viên tổ chia sẻ cách nhìn của họ và thảo luận điều họ muốn đạt tới, họ đang phát triển viễn kiến cho dự án. Bằng việc cho phép mọi thành viên tham gia vào, người quản lí dự án không chỉ có viễn kiến về dự án mà còn có cam kết của tổ để làm cho dự án thành công, bởi vì đó là điều họ muốn. Bằng việc cho từng thành viên tổ cơ hội bày tỏ mối quan tâm của họ, tổ cảm thấy thảnh thơi và sẵn lòng tham gia. Họ càng cảm thấy thoải mái, họ sẽ càng có thể chia sẻ và mở ra trao đổi giữa các thành viên tổ và, xem như kết quả, khuyến khích làm việc tổ.

Một khi tổ đồng ý với viễn kiến và mục đích, bước kế tiếp là đề nghị tổ làm ra danh sách các việc cần được thực hiện. Bằng việc cho phép các thành viên tổ chia các yêu cầu thành những nhiệm vụ nhỏ hơn, tổ thực tại đang xây dựng cấu trúc phân việc Work Breakdown Structure (WBS) cho dự án. Tôi thường cố vấn cho người quản lí dự án hỏi: “Bạn nghĩ nhiệm vụ này có đủ nhỏ để làm nó trong 30 giờ không? Nếu không thì bạn có thể chia nó thành nhiệm vụ nhỏ hơn được không?” Bằng việc khuyến khích tổ tham gia, các thành viên tổ cảm thấy rằng họ đóng góp cho dự án và đó là “dự án của họ” mà họ muốn thành công. Đến cuối của việc cộng tác tổ này, người quản lí dự án không chỉ có danh sách của dự án về mọi việc phải được thực hiện mà còn có khả năng phân công các thành viên cho các việc làm. Khi bản thân họ làm việc chia nhỏ, họ cũng giả định nhiệm vụ nào họ muốn làm. Tôi thường nói đùa rằng kĩ thuật này có tên là “Một tên giết hai chim.”.

Sau khi yêu cầu dự án được phân chia thành những nhiệm vụ nhỏ hơn, từng nhiệm vụ có thể được thực hiện bởi một người trong một tuần, mọi điều người quản lí dự án cần là thêm những nhiệm vụ này vào và khớp chúng trong lịch biểu và sẵn sàng thảo luận với khách hàng về thực hiện dự án. Chừng nào người quản lí dự án còn có thể kiểm soát được mong đợi của khách hàng, theo dõi thực hiện nhiệm vụ với lề lỗi nhỏ, dự án sẽ chạy ổn thoả.

—-English version—-

Teamwork in Software project planning

Software project management is the collection of techniques to manage the development of various types of software products. It includes the choice of software development life cycle; methods for estimate project size and schedule; knowledge and skills required for team members; tracking and managing risks etc. In theory, project manager makes all decisions and documents the choices in the project plan. However, in reality, planning a software project often requires the involvement of team members since they also have certain skills and experiences. There are many decisions to be taken during this planning period with different approaches to manage the project. After over 30 years of managing software project, I believe that by having team members participate in project planning early will give the team a sense of ownership and camaraderie and easy to obtain commitment from them.

Teamwork does not always come naturally; it develops after team members get to know each other and become comfortable working together. Team members do not have to be best friends, but they do need to have an effective professional relationship in order for teamwork to thrive and it takes time to build this relationships. I often advise project manager to have a full day of team activities outside the company each month where members can relax in a non-work environment and get to know each other. The activities can be a team picnic, a visit to another company, a trip to a conference or a team party where they play video games together and compete for a fun prize etc. A team that plays well together will work well together.

Effective software project management is critical in achieving a successful result. In theory, the project manager develops a vision for the project and make sure that the team is committed to work according to that vision. However, in reality it would be better to have the team to come up with the vision for the project after consider both technical and management issues. The goals for the project need to be agreed by the entire team. In deciding the goals, all factors must be considered, including resources, schedule, quality, budget etc. The project team should have the opportunity to debate these factors fully to come up with its own conclusions.

I often advise the project manager to ask the team to visualize what project success would be like. As team members share their views and discuss what they want to achieve, they are developing the vision for the project. By allowing all members to participate, the project manager is not only having a vision for the project but also the commitment of the team to make the project successes, because it is what they want. By give each team member an opportunity to express their concerns, the team feels relax and willing to participate. The more comfortable they are, the more they will likely to share and open up communication between team members and, as a result, encourage teamwork.

Once the team agrees with the vision and goals, the next step is asking the team to make a list of the work that needs to be done. By allowing team members to breakdown the requirements into smaller tasks, the team is actually developing the Work Breakdown Structure (WBS) for the project. I often advise the project manager to ask: “Do you think the task is small enough to do it in about 30 hours? If it is not can you break it into smaller task? By encourages the team to participate, team members feel that they contribute to the project and it is “their project” that they want to be successful. By the end of this team collaboration, the project manager not only have the projects list of all the works that must be done but also be able to have assigned team members to jobs. As they do the breakdown themselves, they also assume which tasks that they want to do. I often joke that the technique is called “Kill two birds with one arrow”.

After the project requirements are divided into smaller tasks, each task can be done by one person in one week, all the project manager need is to add these tasks and fit them into a schedule and ready to discuss with customer on execute the project. As long as project manager can manage customer’s expectation, tracks the task implementation with a small margin of error, the project should run smoothly.