Phần lớn các giáo sư đều tập trung vào lí thuyết hàn lâm mà không có thực hành công nghiệp. Đó là lí do tại sao nhiều dự án phần mềm đã liên tục bị vượt quá ngân sách, lâu hơn là mong đợi, và không cung cấp mức độ chất lượng và chức năng mà người dùng mong đợi.
Áp dụng các lí thuyết quản lí dự án hàn lâm vào dự án phần mềm đã không đạt tới thành công bởi vì dự án phần mềm khác về nền tảng với các dự án trong các ngành công nghiệp khác. Những khác biệt này làm cho quản lí dự án phần mềm thành khó hơn quản lí các kiểu dự án khác. Nhiều trong số những khác biệt nền tảng này có liên quan tới ‘tính thấy được’ hay khả năng của người quản lí dự án xác quyết về việc hoàn thành của một nhiệm vụ bằng việc nhìn vào kết quả của nhiệm vụ đó. Việc thiếu tính thấy được mà người quản lí dự án phần mềm có trong các pha khác nhau của dự án phần mềm điển hình tạo ra khó khăn để làm việc quản lí tốt.
Trong lí thuyết hàn lâm, phát triển sản phẩm phần mềm tương tự như xây nhà. Yêu cầu được xây dựng nên, ước lượng về lịch biểu và chi phí được thực hiện rồi công việc kiến trúc, thiết kế và xây dựng có thể bắt đầu. Một vấn đề với điều này là trong khi làm nhà thì có công cụ và kí pháp vật lí để mô tả trực quan nó và hầu hết mọi người đều có thể hiểu được chúng (to thế nào, cao thế nào, rộng thế nào), người làm phần mềm bị giới hạn trong những kí pháp mà họ có thể mô tả sản phẩm cho khách hàng. (Không ai thực sự biết cần bao nhiêu dòng mã, bao nhiêu cấu phần, hay đối tượng hay bao nhiêu giao diện v.v.)
Phần lớn những người quản lí chỉ lệ thuộc vào các biểu đồ mức cao để mô tả những khái niệm này cho khách hàng. Bởi vì khách hàng không thực sự hiểu những biểu đồ này rõ, họ thường đổi ý kiến về điều họ thực sự muốn. Bên cạnh đó, không có chi phí được chấp nhận rõ ràng theo tính năng hay cách đo chi phí theo số dòng mã mà người quản lí có thể dùng làm cơ sở cho việc ước lượng chi phí ban đầu. Với cái nhà, kiến trúc sư có thể tính toán cần bao nhiêu gạch, bao nhiêu xi măng, bao nhiêu gỗ, thanh thép, v.v và đi tới chi phí xây dựng. Tuy nhiên, không có những điều như vậy trong phần mềm.
Tất cả những điều này có nghĩa gì với sinh viên? Nó nghĩa là sinh viên quản lí dự án phần mềm cần hiểu qui trình “lập kế hoạch mơ hồ” này. Họ cần học cách xây dựng bản mẫu cho giao diện người dùng hay dùng các công cụ trực quan như UML theo cách khách hàng của họ có thể hiểu được. Họ cần có kĩ năng kĩ nghệ yêu cầu để cho họ có thể đi từ các yêu cầu mức cao tới kiến trúc chi tiết. Họ cần lập kế hoạch dự án tương ứng với các pha phục vụ như tuyến cơ sở và tiếp tục lập kế hoạch khi mọi sự thay đổi. Điều quan trọng nhất, họ cần học cách thương lượng với khách hàng về lịch biểu, chi phí và chất lượng. Không may là những điều này KHÔNG được dạy trong hầu hết các môn đại học.
Lập kế hoạch dự án phần mềm yêu cầu rằng mọi dự án đều phải bắt đầu bằng bản kế hoạch dự án, điều trả lời cho các câu hỏi: Tổ lập kế hoạch để làm cái gì? Việc đó được diễn ra như thế nào? Ai sẽ làm từng việc? Khi nào từng nhiệm vụ được thực hiện xong? Nó sẽ tốn bao nhiêu? Nếu bản kế hoạch không chứa câu trả lời cho những câu hỏi này, nó không phải là bản kế hoạch tốt. Phần có giá trị nhất của bản kế hoạch là QUI TRÌNH mà mọi thành viên tổ đều phải đi qua để trả lời cho những câu hỏi này. Qui trình đó cung cấp cơ hội lớn cho các thành viên tổ biết lẫn nhau và đạt tới thoả thuận về bản kế hoạch này.
Không may là quan điểm hàn lâm là duy nhất người quản lí dự án tạo ra bản kế hoạch và chỉ đạo các thành viên tổ tuân theo bất kì cái gì người quản lí vạch ra. Nguyên tắc hàn lâm về người quản lí “quản lí” còn thành viên tổ “tuân theo” thực sự không có tác dụng trong dự án phần mềm. Bởi vì bản kế hoạch dự án như vậy mà trả lời cho cho những câu hỏi này không bao giờ được tạo ra, tổ cảm thấy rằng họ đã bị khách hàng trao cho yêu cầu bắt buộc mà họ KHÔNG THỂ thay đổi hay chẳng có liên quan gì tới công việc đáng phải làm. Về căn bản họ KHÔNG có ý tưởng ai sẽ làm từng nhiệm vụ. Bởi vì người quản lí dự án quá bận rộn làm việc trên bản kế hoạch dự án, ‘công việc thực’ không bao giờ được bắt đầu chừng nào người quản lí còn chưa hoàn thành bản kế hoạch này.
Không có sự tham gia sớm sủa của các thành viên tổ, KHÔNG có ý kiến từ các thành viên tổ về cách từng nhiệm vụ được phân công và ai sẽ làm chúng, thì chỉ một biểu đồ cấu trúc mức cao được tạo ra như bản kế hoạch dự án. Quan điểm về tổ là “Làm bất kì cái gì có thể được” thay vì hỗ trợ tích cực cho việc lập kế hoạch dự án. Không hiểu khía cạnh mấu chốt, sẽ có nhiều thay đổi khi tổ khám phá ra “sai lỗi” trong qui trình lập kế hoạch. Khi có thay đổi, bản kế hoạch cũng phải được thay đổi nhưng vì người quản lí đã có thoả thuận với khách hàng, khó mà thay đổi được lịch biểu hay chi phí. Đến cuối cùng, tổ bị mắc kẹt với “bản kế hoạch” có lịch biểu cứng ngắc và chức năng mơ hồ.
Việc tạo ra bản kế hoạch tốt trả lời cho mọi câu hỏi nêu trên yêu cầu nhiều nỗ lực. Ngày nay, trong công nghiệp phần mềm, lập kế hoạch dự án là nỗ lực tổ nơi các thành viên tổ cùng làm việc với nhau để tạo ra bản kế hoạch sơ bộ. Trong thời gian đó, các thành viên tổ sẽ xây dựng một danh sách các yêu cầu mức cao. Họ sẽ lập đại cương, chi tiết nhất có thể được, các nhiệm vụ cần được hoàn thành. Họ sẽ xác định mối quan hệ thích hợp giữa các nhiệm vụ, đưa ra nỗ lực đầu tiên về ai sẽ làm từng việc nào, ước lượng thời hạn cho từng nhiệm vụ, lập lịch biểu cho những nhiệm vụ đó và tạo ra lịch biểu dự án tổng thể.
Trong khi một số thành viên tổ đang làm việc về các chi tiết của những nhiệm vụ này, các thành viên khác của tổ hội tụ vào ước lượng và ngân sách của kế hoạch. Với dự án kích cỡ trung bình, phần lớn công việc có thể được thực hiện trong một tuần, dự án lớn hơn có thể yêu cầu ba tới năm tuần để lập kế hoạch xảy ra nhưng việc lập kế hoạch bao giờ cũng là hoạt động tổ.
Quan điểm hàn lâm KHÔNG phải bao giờ cũng đồng ý với quan điểm này. Có nhiều thảo luận về phần mềm như việc xây nhà, chỉ kiến trúc sư và người quản lí được tham gia vào còn công nhân xây dựng KHÔNG được phép tham gia. Tuy nhiên, như tôi đã nói rằng xây nhà và làm phần mềm là KHÔNG như nhau do “khía cạnh thấy được”. Bạn có thể thấy ngôi nhà đang được xây và biết kích cỡ, chi phí cũng như việc hoàn thành (30% được hoàn thành hay 50% được hoàn thành) nhưng bạn KHÔNG thể thấy được cái gì với phát triển phần mềm.
Thiếu tính thấy được là vấn đề lẫn lộn nhất cho nên một mình người quản lí dự án KHÔNG thể lập kế hoạch dự án được cho nên điều bản chất là CÓ sự tham gia của tổ. Bằng cách làm việc cùng nhau đi tới bản kế hoạch dự án, từng thành viên tổ sẽ thực sự hiểu điều họ cần làm nhiệm vụ nào họ phải hoàn thành trước ngày tháng nào đó, và tổ hợp nhiệm vụ của họ vào một danh sách toàn diện mọi điều cho nên người quản lí có thể dùng danh sách này để thương lượng với khách hàng. Người quản lí dự án phần mềm giỏi nên là người tạo điều kiện, người huấn luyện viên, người lãnh đạo và người thương lượng giỏi. Đây là những kĩ năng phải được dạy trong mọi lớp quản lí dự án phần mềm.
Ngày nay, phần lớn sinh viên trong môn quản lí dự án phần mềm KHÔNG được dạy để làm việc trong tổ và để tạo ra bản kế hoạch dự án theo cách cộng tác như vậy. Tôi tin rằng đào tạo quản lí dự án nên tập trung vào các khía cạnh thực hành này bằng việc cho sinh viên cơ hội để tạo ra ‘bản kế hoạch dự án thực’ bằng cách làm việc trong tổ. Tôi tin rằng mọi môn học quản lí dự án phần mềm cần chứa các bài tập cho phép sinh viên kinh nghiệm như qui trình lập kế hoạch.
Trong đào tạo của chúng tôi ở Carnegie Mellon, phần lớn sinh viên hoàn thành quãng hai tới ba bài tập như vậy trong môn học một học kì và tổ trung bình hoàn thành bản kế hoạch như vậy trong xấp xỉ 10 giờ trọn vẹn. Điều này cho sinh viên kinh nghiệm và thuyết phục có hiệu quả họ rằng bản kế hoạch dự án có thể được thực hiện bằng tổ chỉ trong vài ngày và đây là điều công nghiệp phần mềm thực sự cần.
According to several studies, most software managers have NOT received any FORMAL project management training and many project management courses in university are NOT adequate due to the lack of “practical aspect”. Most professors focus too much on academic theories without any industry practices. That is why so many software projects have continued to be over budget, take longer than expected, and not provide the level of quality and functionality expected by users.
The application of academic project management theories to software projects has not achieved the success because software projects are fundamentally different from projects in other industries. These differences make the management of software projects more difficult than the management of other types of projects. Many of these fundamental differences have to do with the `visibility” or the ability of the project manager to confirm completion of a task by looking at the results of that task. The lack of visibility that the software project manager has into various phases of a typical software project creates difficulty to do a good management job.
In academic theory, the development of a software product is similar to the construction of a house. Requirements are developed, estimates of schedule and cost are made then the architecture, design and construction work can begin. One problem with this is while a house has physically tools and notations to visually describe it and most people can understand them (How big, how tall, and how wide), software people are limited in the notations that they can describe the product to customer. (No one really knows how many line of codes, how many components, or objects or how many interfaces etc.) Most managers only depend on high level diagrams to describe these concepts to the customer. Because customers do not really understand these diagrams well, they often change their minds on what they really want. In addition, there is no well-accepted cost per feature or cost per line of code measure that software managers can use as the basis for early cost estimating. For a house, the architect can calculate how many brick, how much cement, how many woods, steel rods, etc and come up with the cost of construction. However, there is no such thing in software.
What does all of this mean for students? It means that software project management students need to understand the problems of this “fuzzy planning” process. They need to learn how to develop prototypes for user interfaces or use visual tools such as UML in a way that their customers can understand. They need to have requirements engineering skill so they can move from high level requirements to a detailed architecture. They need to plan the project according to phases that serves as the baseline and continue to plan when things change. Most importantly, they need to learn how to negotiate with customer on schedule, costs and quality. Unfortunately these things are NOT taught in most university courses.
Software project planning requires that every project must start with a project plan that answers the questions: What is the team planning to do? How is it going to be done? Who is going to do each task? When will each task be done? How much will it cost? If a plan does not contain answers to these questions, it is not a good plan. The most valuable part of the plan is the PROCESS that every team member go through to answer these questions. That process provides a great opportunity for team members to get to know each other and to reach agreement on the plan. Unfortunately, the academic view is only the project manager creates the plan and directs team members to follow whatever manager comes up with. The academic principle of manager “manages” and team member “follows” really does not work in software project. Because such project plan that answers these questions is never produced, the teams feel that they have been given mandate requirements by the customer that they CAN NOT change or have any thing to do with how the work should be done. Basically they have NO idea on who will do each task. Because project manager is too busy working on the project plan, the `real work” never get started until the manager complete the plan.
Without the team member involvement early, there is NO opinion from team members on how each task is assigned and who will do them, only a high-level structure diagram gets produced as the project plan. The view of the team is “Do whatever possible” rather than actively support the planning of the project. Without understanding the critical aspect, there will be more changes as the team discovers “Flaws” in the planning process. When there are changes, the plan must also be changed but since the manager already have an agreement with the customer, it is difficult to change the schedule or the costs. In the end, the team is stuck with a “plan” with rigid schedule and fuzzy functionalities.
To produce a good project plan that answers all of the questions above requires a lot of efforts. Today, in software industry, project planning is a team effort where team members work together to produce a preliminary plan. During that time, members of the team will develop a list of high level requirements. They will outline, in as much detail as possible, the tasks that need to be accomplished. They will determine the appropriate relationships among the tasks, make a first attempt at who will do each task, estimate the duration of each task, schedule those tasks and produce an overall project schedule. While some members of the team are working on the details of these tasks, other members of the team are focusing on the estimates and budget of the plan. For a medium sized project, most works can be accomplished within a week, larger project may require three to five weeks for the planning to take place but planning is always a teamwork activities.
The academic view does NOT always agree with this view. There are many discussions about software as building a house, only the architect and manager are involved and construction workers are NOT allow to participate. However, as I already mentioned that building a house and building software is NOT the same due to the “visibility aspect”. You can see the house being build and knowing the size, the costs and well as the completion (30% completed or 50% completed) but you can NOT see anything with software development. The lack of visibility is the most confused issue so the project manager alone can NOT plan the project so it is essential to HAVE the team participation. By working together to come up with the project plan, each team member will really understand what they need to do what task they must complete by certain date, and combine their tasks into a comprehensive list of things so manager can use the list to negotiate with customer. A good software project manager should be a facilitator, a coach, a leader and a good negotiator. These are skills that must be taught in every software project management class.
Today, most students in a software project management course are NOT taught to work in team and to produce such as a collaborated project plan. I believe that project management training should focus on these practical aspects by giving students a chance to create a “real project plan” by working in team. I believe that all software project management courses need to contain exercises that allow students to experience such a planning process. In our training at Carnegie Mellon, most students complete about two to three of such exercises in one-semester course and the average team complete such plan in approximately 10 hours fulltime. This gives the students the experience and effectively convinces them that project plan can be done by a team in just a few days and this is what the software industry really needs.
