08/07/2013 – Blogs of Prof. John Vu, Carnegie Mellon University
– This article is translated into Vietnamese by Ngo Trung Viet with the English
originals followed.
Theo nhiều nghiên cứu, phần lớn những người quản lí phần mềm đã
KHÔNg nhận được đào tạo về quản lí dự án CHÍNH THỨC và nhiều giáo trình quản lí
dự án tại đại học KHÔNG thích hợp do thiếu “khía cạnh thực hành”. 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.
______________________________________
Giáo sư John Vu, một người Mỹ gốc Việt, là một nhà khoa học nổi
tiếng nước Mỹ thuộc trong Top 10 những người sáng tạo nhất thế giới. Ông từng
là Phó Chủ tịch của Boeing. Sau khi rời Boeing, GS John Vu hiện là viện trưởng
Viện Công Nghệ Sinh Học ÐH Carnegie Mellon. Ông là dịch giả/tác giả bộ sách
Hành Trình về Phương Ðông, Ðường Mây Qua Xứ Tuyết, Ngọc Sáng Hoa Sen, Trên Ðỉnh
Tuyết Sơn,… và cuốn mới nhất 2016 là Khởi Hành.
______________________________________
—-Enlish version—-
Software Project Plan
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.
________________________________________