09/11/2013 – Blogs of Prof. John Vu, Carnegie Mellon University
– This article is translated into Vietnamese by Ngo Trung Viet with the English
originals followed.
Một người quản lí mới viết cho tôi: “Tôi là người lãnh đạo tổ vừa
mới được cử làm quản lí một dự án mới. Tôi muốn là người quản lí dự án thành
công và bắt đầu dự án theo cách tốt nhất có thể được. Tôi có thể dùng kĩ năng
nào từ người lãnh đạo tổ trong việc làm mới này và tôi cần cải tiến cái gì
khác?”
Đáp: Có khác biệt giữa người lãnh đạo tổ và người quản lí dự án.
Người lãnh đạo tổ chịu trách nhiệm về khía cạnh kĩ thuật của dự án bằng việc
cung cấp việc lãnh đạo cho một tổ nhỏ (ba tới bẩy người) để thực hiện các chức
năng nào đó của dự án. Người lãnh đạo tổ động viên các thành viên tổ làm việc
hướng tới thành công dự án. Người quản lí dự án chịu trách nhiệm cho toàn thể dự
án, cả về khía cạnh kĩ thuật VÀ quản lí. Người quản lí dự án kiểm soát và quản
lí nhiều tổ bên trong dự án để hoàn thành mục đích của dự án. Là người quản lí
dự án mới, bạn cần có đào tạo thêm và kinh nghiệm để thành công. Nếu công ti của
bạn không cung cấp đào tạo thì bạn cần lấy đào tạo riêng cho bạn bởi vì người
quản lí phần mềm KHÔNG phải là cái gì đó bạn có thể học trong việc làm hay bằng
đọc sách.
Để bắt đầu dự án phần mềm, bạn cần biết khách hàng và người dùng
của bạn là ai. Khách hàng là người trả tiền cho dự án; người dùng là người dùng
sản phẩm của bạn. Khách hàng quan tâm tới lịch biểu; người dùng quan tâm tới
tính năng và chất lượng của sản phẩm. Là người quản lí dự án, bạn cần nói chuyện
với cả khách hàng và người dùng để tìm ra đích xác điều họ mong đợi từ dự án và
nhu cầu của họ là gì. Nếu có nhiều khách hàng và người dùng thì bạn cần nói
chuyện với tất cả họ vì họ có thể có những cách nhìn và mong đợi khác nhau và bạn
cần biết tất cả các quan điểm của họ.
Từ những quan điểm này, bạn phải tổ chức các mong đợi và yêu cầu
đó thành một danh sách ưu tiên những điều cần làm vì bạn không thể làm mọi thứ
một lúc được. Bạn cần thẩm tra danh sách ưu tiên này với cả người quản lí của bạn
VÀ khách hàng để chắc rằng họ đồng ý với nó. Một khi được chấp thuận, danh sách
ưu tiên này sẽ là yêu cầu sơ bộ cho dự án của bạn. Bạn phải dùng Cấu trúc phân
việc (WBS) để chia từng yêu cầu thành nhiều chức năng và từng chức năng thành
nhiều nhiệm vụ nhỏ hơn. Bạn phải ước lượng thời gian để hoàn thành những nhiệm
vụ này tương ứng với ưu tiên và sự phụ thuộc. Bằng việc thêm thời gian để hoàn
thành những nhiệm vụ này cùng nhau, bạn đi tới “lịch biểu dự kiến” cho dự án. Bạn
cần xác định liệu lịch biểu dự kiến của bạn có sánh đúng với mong đợi lịch biểu
của khách hàng không. Nếu không, bạn sẽ cần thảo luận với người quản lí của bạn
và khách hàng để đi tới lịch biểu thoả đáng. Từ danh sách các nhiệm vụ ưu tiên,
bạn cần ước lượng số người mà bạn cần để thực hiện chúng. Có người thiết kế,
người phát triển, người kiểm thử, nhân sự hỗ trợ như người quản lí cấu hình, đảm
bảo chất lượng v.v. Bạn cũng cần quyết định về phương pháp và công cụ nào để
dùng cho dự án của bạn.
Bằng việc đạt tới bước này, bạn phải biết: Ai là khách hàng và
người dùng; mục đích của dự án là gì; nhiệm vụ nào là ưu tiên và nhiệm vụ nào
không; nó mất bao nhiêu thời gian; và bạn cần bao nhiêu người để thực hiện dự
án; bạn cần phương pháp và công cụ nào cho dự án. Tất cả các khoản mục này đều
phải được làm tài liệu trong bản kế hoạch dự án sơ bộ.
Sai lầm chung mà những người kĩ thuật thường phạm phải là hội tụ
ngay vào mỗi chức năng chi tiết. Đó KHÔNG phải là cách tốt nhất để bắt đầu một
dự án phần mềm. Điều quan trọng cho bạn là hiểu toàn bộ hoàn cảnh dự án và lí
do tại sao khách hàng cần dự án này. Nói cách khác, cách tốt nhất để bắt đầu dự
án là hiểu chỗ bạn được giả định sẽ kết thúc. Dự án này được giả định hoàn
thành cái gì mà sẽ đem lại ích lợi cho khách hàng và công ti của bạn. Điều đó
nghĩa là bạn phải lấy bản kế hoạch dự án và kiểm điểm cùng khách hàng để đi tới
thoả thuận về lịch biểu, tài nguyên, công cụ, phương pháp, cũng như bất kì rủi ro
nào liên kết với dự án. Khách hàng càng biết nhiều về kế hoạch của bạn, họ càng
tin tưởng hơn vào bạn và dễ dàng hơn trong thương lượng với họ về tài nguyên dự
án và lịch biểu (tức là bạn cần bao nhiêu người để thực hiện dự án; nó sẽ mất
bao nhiêu thời gian; nó sẽ tốn bao nhiêu v.v.). Phần lớn các khách hàng thường
đặt lịch biểu không hiện thực lên dự án vì họ không có ý tưởng nào về lịch biểu
cho nên họ chỉ đoán chừng. Điều quan trọng cho bạn là chỉ ra cho họ phân việc của
bạn, ước lượng của bạn và kế hoạch của bạn về dự án vì trong thảo luận, bạn có
thể phải thu gọn phạm vi hay tăng thời gian hoàn thành. Không có bản kế hoạch dự
án tốt mà nhận diện rõ ràng khối lượng thời gian được cần để hoàn thành từng
nhiệm vụ và số người được cần cho nhiệm vụ, bạn không thể thuyết phục được
khách hàng hỗ trợ cho bạn.
Thương lượng dự án là kĩ năng mấu chốt mà người quản lí dự án phải
làm. Để làm cho dự án bắt đầu theo cách tốt nhất có thể, bạn sẽ cần thương lượng
lịch biểu với khách hàng để đi tới cái gì đó hợp lí, bằng không dự án sẽ thất bại.
Có thay đổi phạm vi dự án (giảm chức năng) hay thay đổi lịch biểu (nhiều thời
gian hơn hay ít thời gian hơn); hay thêm hay giảm số người v.v. Bạn có thể
không có được điều bạn muốn và khách hàng có thể không có được điều họ muốn
nhưng có thảo luận để đi tới thoả thuận nào đó trước khi bắt đầu dự án sẽ giúp
cho cả hai bên tránh được nhiều vấn đề về sau.
Thương lượng dự án là khi bạn có thể thực sự phát triển hiểu biết
rõ ràng về mục tiêu dự án và mong đợi của khách hàng. Bằng thảo luận và thương
lượng, bạn sẽ có khả năng nhận biết về bất kì rủi ro hay vấn đề tiềm năng mà bạn
có thể đương đầu về sau nữa. Quản lí rủi ro là khía cạnh nền tảng của việc quản
lí dự án tốt. Bằng việc biết các rủi ro, bạn có thể tránh được chúng, thay đổi chúng,
hay làm giảm bớt tác động của chúng lên dự án của bạn. Đây là lúc để khách hàng
biết về rủi ro của dự án cho nên cùng nhau bạn và khách hàng đi tới bản kế hoạch
quản lí rủi ro.
Sau khi có thoả thuận với khách hàng, bạn có thể thay đổi bản kế
hoạch của bạn tương ứng. Thế và chỉ thế bạn mới xác định được ai phải ở trong tổ
dự án của bạn, liệu bạn có người đã làm việc cùng bạn trước đây hay bạn có thể
thuê người mới phụ thêm. Bạn cần thảo luận với tổ dự án về hiểu biết của bạn về
mục tiêu dự án, trao đổi với họ về điều bạn đã được yêu cầu làm, và thảo luận với
họ về bất kì nhu cầu đào tạo nào để làm cho dự án bắt đầu theo cách tốt nhất có
thể được. Đây là lúc bạn chia sẻ với tổ về viễn kiến của bạn, mục đích của dự
án và cách bạn giám sát tiến độ dự án. Tổ phải hiểu đầy đủ và quyết tâm hỗ trợ
bạn. Cuộc họp tổ này là nền tảng mấu chốt cho việc tiến sang bước tiếp, nơi tổ
sẽ bắt đầu làm việc trên chi tiết dự á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.
______________________________________
—English version—
Starting a new project
A new manager wrote to me: “I was a team leader who just gets
promoted to manage a new project. I want to be a successful project manager and
start the project in the best way possible. What skills from team leader can I
use in this new job and what else do I need to improve?”
Answer: There is a difference between a team leader and a
project manager. Team leader is responsible for the technical aspect of a
project by provide leadership to a small team (Three to seven people) to
implement some functions of the project. Team leader motivates team members to
work toward the project success. Project manager is responsible for the entire
project, both technical AND management aspects. Project manager controls and
manages several teams within the project to accomplish the project’s goals. As
a new project manager, you need additional training and experiences to be
successful. If your company does not provide training then you need to take
training on your own because software project manager is NOT something that you
can learn on the job or by reading a book.
To start a software project, you need to know who your customers
and users are. Customers are people who pay for the project; users are people
who use your product. Customers are concerned with the schedule and cost of the
project; users are concerned with the features and quality of the product. As
project manager, you need to talk with both customers and users to find out
exactly what they expect from the project and what their needs are. If there
are several customers and users than you need to talk to all of them since they
may have differing views and expectations and you need to know all of their
viewpoints.
From these viewpoints, you must organize them into a priority
list of thing to do because you cannot do everything at once. You need to
verify this priority list with both your manager AND customers to make sure
that they agree with it. Once approved, the priority list will be the
preliminary requirements for your project. You must use the Work Breakdown
Structure (WBS) to break each requirement into several functions and each
function is broken down into several smaller tasks. You must estimate the time
needed to implement each task according to the priority and dependency. By
adding the time to complete these tasks together, you come up with a “tentative
schedule” for the project. You need to determine whether your tentative
schedule matches customer’s schedule expectations. If not, you will need to
discuss with your manager and customers to come up with a reasonable schedule.
From the list of priority tasks, you need to estimate the number of people that
you need to implement them. There are designer, developers, testers, support
personnel such as configuration manager, quality assurance etc. You also need
to make decisions on which method and tools to use for your project.
By reaching this step, you must know: Who the customers and
users are; what the project goals are; which tasks are priority and which are
not; how long it may take; and how many people you need to do the project; what
method and tools that you need for the project. All of these items must be
documented in a preliminary project plan.
The common mistake that technical people often make is focusing
on the detailed functions right away. That is NOT the best way to start a
software project. It is important for you to understand the entire project
context and the reason why the customers need this project. In other words, the
best way to start the project is to understand where you are supposed to
finish. What is this project supposed to accomplish that will benefit the
customers and your company. That means you should take the project plan and
review with your customers to come up with an agreements about schedule,
resources, tools, methods as well as any risks associated with the project. The
more the customers know about your plan, the better confident they will have on
you and it is easier to negotiate with them on project resources and schedule
(i.e., how many people you need to implement the project; how long it will
take; how much it will cost etc.). Most customers often place unrealistic
schedule on the project because they have no idea about schedule so they just
guess. It is important for you to show them your work breakdown, your estimates
and your plan of the project because during the discussion, you may have to
reducing the scope or increasing the time for completion. Without a good
project plan that have clearly identify the amount of time needed to complete
each task and the numbers of people needed to do the tasks, you cannot convince
the customers to support you.
Project negotiation is a critical skill that project managers
must do. To get the project starting in the best possible way, you will need to
negotiate the schedule with customers to come up with something reasonable, else
the project will fail. It is possible to change the scope of the project
(reducing functionality) or change schedule (more time or less time); or adding
or reducing number of people etc. You may not get what you want and the
customers may not get what they want also but having a discussion to come up
with some agreements before starting the project will help both sides avoid a
lot of problems later.
Project negotiation is the time when you can really developing a
clear understanding of the project’s objectives and customers’ expectations. By
discussion and negotiation, you will be able to aware of any potential risks or
problems you might encounter later too. Risk management is a fundamental aspect
of a good project management. By knowing the risks, you can avoid them, change
them, or lessen their impact on your project. This is the time to let customers
know about project risks so together you and customers can come up with a risk
management plan.
After having an agreement with customers, you can modify your
project plan accordingly. Then and only then you will determine who should be
on your project team whether you have people that have worked with you
previously or you may have to hire additional new people. You need to discuss
with the project team about your understanding of the project’s objectives,
communicate with them on what you have been asked to do, and discuss with them
about any training needs to get the project start in the best way possible.
This is the time where you share with the team about your vision for the
project, the goals of the project and how do you monitor the progress of the
project. The team must fully understands and commit to support you. This team
meeting is the critical foundation of moving on to the next step, where the team
will begin to work on the detail the project.
________________________________________
Đọc thêm về Tủ Sách Vietnam Carenet TẠI ĐÂY
Đọc thêm các bài viết về Khởi Nghiệp TẠI ĐÂY
Đọc thêm các bài viết về Lập Dự Án TẠI ĐÂY
Đọc thêm các bài viết về Quản lý Dự Án TẠI ĐÂY
Đọc thêm các bài viết về Kỷ Nguyên 4.0 TẠI ĐÂY