Người quản lí dự án phần mềm giỏi phải biết cách tạo ra cân bằng giữa vấn đề kĩ thuật và vấn đề con người.

Chỉ hội tụ vào vấn đề kĩ thuật có thể làm cho mọi người cảm thấy họ tuân theo mệnh lệnh như “người máy”. Trong khi chỉ hội tụ vào vấn đề con người có thể làm cho mọi người bỏ qua nhiệm vụ kĩ thuật và có thể làm việc như họ trong một đảng phái. Cân bằng này rất khó thực hiện tốt vì quản lí con người thường là điều khó nhất trong bất kì dự án phần mềm nào. Điều không may là phần lớn việc đào tạo quản lí dự án phần mềm đang hội tụ vào vấn đề kĩ thuật nhưng ít khi vào vấn đề con người.

Trong khi người phát triển phần mềm được đào tạo để làm các vấn đề kĩ thuật (thiết kế, viết mã v.v.) phần lớn chưa bao giờ nhận được đào tạo nào về cách làm việc trong tổ. Mọi người thường nói “tổ là nhiều hơn một người”, sự kiện là các kĩ năng và công việc và thành phần của tổ là rất quan trọng và phải được quản lí đúng. Việc tạo ra tổ là một điều nhưng giữ và duy trì tổ hiệu quả là vấn đề khác. Trong công ti phần mềm lớn, có nhiều chức năng và nhiều người từ các chức năng khác nhau thường không ở cùng vị trí. Chẳng hạn, người phát triển sẽ làm việc ở toà nhà này, tổ kiểm thử ở toà nhà khác và tổ chất lượng và tổ hỗ trợ có thể ở vị trí khác nữa. Tôi đã thấy rằng tách bạch càng có nhiều, càng nhiều vấn đề nảy sinh ra giữa các tổ. Điều quan trọng, khi có thể là để toàn thể tổ dự án ở gần nhất có thể được. Tôi bao giờ cũng đặt tổ kiểm thử và tổ phát triển ở cùng nhau để tránh vấn đề hiểu lầm hay trao đổi kém. Trao đổi tốt là yếu tố then chốt trong xây dựng quan hệ tổ. Các thành viên tổ phải trao đổi thường xuyên về nhiệm vụ của họ và cho phép họ ra quyết định có thông tin.

Tổ dự án phải chia sẻ cùng viễn kiến, bằng không tổ sẽ nhắm tới các hướng khác nhau. Điều quan trọng lúc bắt đầu dự án, người quản lí dự án phần mềm phải triệu tập một cuộc họp với mọi thành viên tổ để chia sẻ viễn kiến, mục đích và mục tiêu dự án của mình với tổ. Viễn kiến là phát biểu chính xác xác định ra “Cái gì”, “Tại sao”, và “Ai” của mục đích của sản phẩm phần mềm theo quan điểm doanh nghiệp. Chẳng hạn: Ai sẽ mua hay dùng sản phẩm phần mềm này? Phần mềm này sẽ làm gì cho người dùng? Tại sao chúng ta cần xây dựng phần mềm này? Phần mềm này sẽ giải quyết vấn đề gì? Điều quan trọng là làm cho mọi thành viên tổ hiểu các lí do doanh nghiệp của dự án. Nó sẽ tiết kiệm thời gian và nỗ lực trong pha phân tích yêu cầu bằng việc khử bỏ hiểu lầm về sản phẩm phần mềm. Một khi tổ hiểu viễn kiến, người quản lí dự án phải thảo luận về mục đích và mục tiêu dự án. Chẳng hạn: Chuyển giao sản phẩm chất lượng đúng thời gian, trong chi phí và đáp ứng mọi yêu cầu chức năng. Thời gian, chi phí và chất lượng là các mục đích của mọi dự án phần mềm nhưng người quản lí dự án phải soạn thảo chi tiết hơn như các mục tiêu và tìm kiếm sự chấp thuận từ các thành viên tổ. Đào tạo quản lí truyền thống coi người quản lí là ai đó đưa ra mục đích và mục tiêu mà tổ phải tuân theo. Khái niệm này sẽ không có tác dụng trong dự án phần mềm bởi vì điều gì xảy ra nếu các mục đích này là không thoả đáng? Điều gì xảy ra nếu các thành viên tổ không cảm thấy thoải mái với lịch biểu? Điều gì xảy ra nếu họ không tin rằng họ có thể đáp ứng cho các mục đích này? Đó là lí do tại sao người quản lí dự án phải thảo luận những mục đích này với tổ và hỏi ý kiến của họ. Thảo luận về mục đích và mục tiêu là mấu chốt bởi vì tổ phải đồng ý về điều họ phải làm. Họ phải có cơ hội lên tiếng về ý kiến của họ. Nếu tổ cảm thấy rằng người quản lí dự án không nghe ý kiến của họ, điều đó có thể làm hại nghiêm trọng cho tinh thần của tổ và có tác động xấu lên dự án. Trong vài ngày đầu của dự án, tổ hình thành và chứng danh của người quản lí dự án được thiết lập. Nếu tổ không kính trọng người quản lí, điều đó sẽ rất khó thay đổi. Nói cách khác, dự án đã “thất bại” từ đầu.

Người quản lí dự án phần mềm phải thảo luận chi tiết về kế hoạch dự án. Chẳng hạn: Các chức năng được thực hiện, phân công nhiệm vụ cho từng thành viên, thời gian cho các nhiệm vụ này và tìm kiếm cam kết từ các thành viên tổ. Điều này yêu cầu nhiều công việc trước khi có cuộc họp đầu tiên với tổ vì nó thiết lập nên chứng danh của người quản lí. Phần lớn các thành viên tổ sẽ hình thành ý kiến nào đó về “người quản lí dự án” của họ trong cuộc họp này. Phán xét của họ sẽ xác định liệu họ có muốn làm việc cho người này hay không. Qui tắc của tôi là: “Lịch biểu, chức năng, chi phí tất cả đều thương lượng được.” Người quản lí dự án giỏi phải thảo luận kế hoạch này với tổ, lắng nghe mối quan tâm và ý kiến của họ và nếu cần, sẵn lòng thay đổi tương ứng. Người đó phải sẵn lòng quay lại với khách hàng hay người quản lí cấp cao để thảo luận về những thay đổi này và tìm kiếm thoả thuận. Qui tắc khác của tôi là: “Lập kế hoạch dự án là nỗ lực tổ, không phải nỗ lực cá nhân.” Lập kế hoạch không phải là hoạt động một lúc mà liên tục trong toàn dự án với các thành viên tổ cung cấp cái vào. Người quản lí dự án phải lắng nghe một cách cẩn thận, thảo luận và thu lấy thoả thuận từ mọi thành viên tổ, để hoàn thành lần cuối bản kế hoạch dự án.

Trong khi thực hiện dự án, người quản lí dự án phần mềm phải thường xuyên giám sát tiến bộ để đảm bảo rằng tổ dự án đang làm việc tương ứng. Bản tính con người là tìm kiếm công bằng và điều quan trọng là công bằng với mọi người. Sẽ là không công bằng khi người quản lí thiên về người này hơn người khác trong đề bạt, lương và các thưởng khác. Điều này có thể làm tổn hại cho tinh thần của tổ và tạo ra vấn đề cho dự án. Vài năm trước đây, tôi đã được mời tới một công ti phần mềm nơi nhiều sinh viên của tôi cũng làm việc ở đó. Tôi đã bảo họ rằng tôi có cơ hội để gặp cấp quản lí của họ và hỏi liệu họ muốn tôi nói điều gì đó nhân danh họ không. Tôi nhận được nhiều email tương tự đáp lại cho email này: “Xin bảo họ học là người lãnh đạo chứ đừng là kẻ độc tài. Xin nhắc nhở họ rằng con người không phải là cái gì đó họ có thể vứt bỏ. Khi người quản lí không đối xử công bằng với mọi người, làm sao bất kì ai có thể mong đợi họ làm hết sức mình cho công ti được.”  Những phàn nàn này từ những người phát triển, những người cũng là sinh viên cũ của tôi, đã làm bận lòng tôi nhiều. Sau vài cuộc họp với cấp quản lí, tôi kết luận rằng quản lí cấp cao thực sự đã không biết điều gì xảy ra trong công ti của họ. Họ có thể biết cái gì đó về kinh doanh của họ nhưng gần như không biết gì về con người. Nhiều người quản lí không có kinh nghiệm phần mềm vẫn quản lí dự án phần mềm. Họ không thể quản lí được cái gì đó họ không hiểu. Một cách lí tưởng, họ nên giỏi hơn những người họ quản lí nhưng nhiều người trong số họ tới vị trí của họ từ khu vực kinh doanh và không hiểu phát triển phần mềm chút nào. Là khách, tôi không thể nói nhiều được nhưng đã khuyến cáo rằng họ nên khởi đầu về đào tạo thêm về quản lí. Không may là người quản lí cấp cao bảo tôi: “Về căn bản, mọi vấn đề đều là kĩ thuật. Nếu ông biết điều ông muốn làm và có đủ người kĩ thuật thì không có lí do gì trong việc đào tạo quản lí thêm. Hiển nhiên, chúng tôi không có đủ người kĩ thuật và chúng tôi phải thuê thêm.” Vài tháng sau, tôi thấy quảng cáo rằng công ti đó muốn thuê nhiều người phát triển phần mềm. Đến cuối năm đó, công ti đó nộp đơn phá sản khi họ cạn kiệt mọi vốn.

Một cựu sinh viên về sau giải thích: “Họ không bao giờ thừa nhận vấn đề của họ. Họ giữ việc thuê ngày càng nhiều người phát triển và thêm ngày càng nhiều người trong các dự án muộn làm cho nó thành tồi tệ.” Nhiều người quản lí che giấu sự bất tài của họ bằng việc phàn nàn rằng họ không có đủ người kĩ thuật. Không ai biết cách quản lí con người cho nên thêm nhiều người, thêm nhiều vấn đề. Khi tổ bị cảm thấy dường như cấp quản lí không hỗ trợ cho họ thì điều đó gây hư hại nghiêm trọng cho tổ. Đây là chỗ “vấn đề trách cứ” xảy ra. Khi mọi người bắt đầu trách cứ lẫn nhau, việc làm việc tổ bị tan rã và chìm xuống thấp. Khi các thành viên tổ giận nhau, không ai sẵn lòng làm cái gì và chấm dứt làm việc với nhau. Đây là lí do tại sao nhiều dự án thế đã thất bại. Họ đã không thất bại về vấn đề kĩ thuật mà thất bại về vấn đề con người.”

—-English version—-

People issues

A good software project manager must know how to create a balance between technical issues and people issues. Focusing only on technical issues can make people feel like they follow orders from a “Robot”. Whereas focusing only on people issues can make people ignore technical tasks and may work like they are in a party. This balance very difficult to do well because managing people is often one of the most difficult things in any software project. Unfortunately, most software project management training is focusing on technical issues but seldom on people issues.

While software developers are trained to do technical works (Design, code, test etc.) most never receive any training on how to work in a team. People often say “more than one people is a team”, the fact is the skills and the makeup of the team are very important and must be managed properly. Creating a team is one thing but keeping and maintaining an effective team is a different matter. In large software company, there are many functions and people from different functions often do not locate in the same place. For example, developers will work in one building, test team in another and quality team and supporting team may be located in another place. I have found that the more separation there is, the more problems happen between the teams. It is important, where possible to have the entire project team locate as close as possible. I always place test team and development team together to avoid any misunderstood or miscommunication issues. Good communication is the key factors in building team relationship. Team members must communicate often with regards their tasks and allow them to make informed decisions.

The project team must share the same vision, otherwise the team will head in different directions. It is important at the beginning of the project, software project manager must call for a meeting with all team members to share his project vision, goals and objectives with the team. The vision is a concise statement that defines the “What”, “Why”, and “Who” of the end of the software product from a business point of view. For example: Who will buy or use this software product? What will the software do for its users? Why do we need to build this software? What problems that this software will solve? It is important for all team members to understand of the business reasons of the project. It will save time and effort during requirements analysis phase by eliminating misunderstanding about the software product. Once the team understand the vision, project manager must discuss the project goals and objectives. For example: Deliver quality product on time, within costs, and meet all functional requirements. Time, cost, and quality are goals of every software project but project manager must elaborate more detail as objectives and seek approval from team members. Traditional management trainings consider managers as someone to issue goals and objectives that team members must follow. This concept will not work in software project because what happens if these goals are unreasonable? What happens if team members do not feel comfortable with the schedule? What happens if they do not believe that they could meet these goals? That is why project manager must discuss these goals with the team and asking them for their opinions. The discussion about goals and objectives is critical because the team must agree to what they have to do. They should have a chance to voice their opinions. If the team feels that the project manager does not listen to their opinions, it could severely damaging the team spirit and has bad affect on the project.  During the first few days of the project, the team is forming and the credential of the project manager is being established. If the team does not respect the manager, it will be very difficult to change. In other word, the project is already “Failed” from the beginning.

Software project manager must discuss in detail about the project plan. For example: The functions to be implemented, the tasks assign to each members, the time for these tasks and seeks commitment from team members. This require a lot of works prior to the first meeting with the team as it establishes the credentials of the manager. Most team member will form some opinions about their “project manager” at this meeting. Their judgments will determine whether they want to work for this person or not. My rule is: “schedule, functions, cost are all negotiable”. A good project manager must discuss the plan with the team, listen to their concerns and opinions and if needed, willing to change accordingly. He must be willing to go back to the customer or senior managers to discuss these changes and seeks an agreement. Another rule of mine is: “Project planning is a team efforts, not individual”. Planning is not a one-time activity but continue throughout the project with team members provide inputs. Project manager must listen careful, discuss and get agreement from all team members, to finalize the project plan.

During the project execution, software project manager must constantly monitor the progress to make sure that project team is working accordingly. Human nature is to seek fairness and it is important to be fair with everybody. It is unfair when managers favor one person over the others in promotion, salary, and other rewards. This could hurt the team’s spirit and create problem to the project. Few years ago, I was invited to a software company where many of my students also worked there. I told them that I had a chance to meet with their management and asked if they want me to say something on their behalf. I received several unexpected emails similar to this email: “Please tell them to learn to be leaders rather than dictators. Please remind them that people are not something they can discard. When managers do not treat people fairly, how can anyone expect them to give their best to the company”.  These complains from developers who were also my former students bothered me a lot. After several meetings with the management, I concluded that senior management really did not know what happened in their company. They may know something about their business but almost nothing about people. Many managers who had no software experience were managing software projects. They cannot manage something that they do not understand. Ideally, they should be better than the people that they managed but most of them come to their positions from the business areas and do not understand software development at all. As a guest, I could not say much but recommended that they initiate more software management trainings. Unfortunately, a senior manager told me: “Basically, all problems are technical. If you know what you want to do and have enough technical people there is no reason in more management trainings. Obviously, we do not have enough technical people and we must hire more”. Few months later, I saw advertise that the company wanted to hire more software developers. By the end of the year, that company filed bankruptcy when they exhausted all their capitals.

One former student later explained: “They never recognized their problems. They kept hiring more and more developers and adding more people in late projects made it worst. Many managers hided their incompetents by complaining that they did not have enough technical people. No one know how to manage people so more people, more problems. When the team felt as though management did not support them then it severely damaged the team. This was where the “Blaming issue” happens. When people started blaming each others, the teamwork disintegrated and sinked low. When team members were angry at each others, nobody was willing to do anything and stopped working together. This was why so many projects failed. They did not fail of technical issue but people issue”.