Những điều thiết yếu trong quản lý dự án

Chương3
Những điều thiết yếu trong quản lý dự án.


Quản lý dự án là một nhóm các nhiệm vụ phức tạp có liên quan đến
nhau. Những nhiệm vụ liên quan đến phát triển phần mềm nhiều nhất
là:


Lên kế hoạch dự án



Dự toán và lên lịch làm việc



Quản lý tài nguyên



Giám sát dự án



Duyệt và trình bày dự án



“Mổ xẻ” dự án

1.Lên kế hoạch dự án
Việc

lên kế hoạch dự án sẽ kéo dài suốt thời gian thực hiện dự án .

“Bản

kế hoạch” sẽ không bao giờ cố định, bởi vì những thứ trong một
dự án phần mềm điển hình luôn luôn biến đổi.
Kế

hoạch dự án là một văn kiện được viết bởi người quản lý dự án,
được ký duyệt và phê chuẩn bởi đội ngũ phát triển và quản lý cấp cao.
Thực

chất đó là 1 bản giao kèo, cam kết về những gì đội dự định làm
và cách thức làm điều đó. Nó cũng nói lên được dự án được quản lý
như thế nào, và trong một vài trường hợp đặc biệt, thậm chí nó mô tả
các bước làm thế nào và lúc nào tài liệu sẽ được điều chỉnh.


Các thành phần của 1 kế hoạch dự án :
1.

Giới thiệu và giải thích dự án

2.

Tổ chức dự án

3.

Phân tích rủi ro

4.

Phần cứng, phần mềm, và nguồn nhân lực cần thiết

5.

Dự toán chi tiết công việc và nhiệm vụ.

6.

Lịch thực hiện dự án

7.

Giám sát dự án.

Không phải tất cả những điều trên là cần thiết cho mọi dự án hoặc mô hình.
-Dự án theo định hướng kế hoạch : sử dụng tất cả
- Dự án linh hoạt : chỉ dùng một vài phần .




Kế hoạch dự án là một phương tiện rất tốt cho việc bày ra những gì
bạn nghĩ bạn sẽ làm, một bản phác thảo cho biết làm thế nào để dự

án thực hiện được, và bạn lên kế hoạch như thế nào trong việc thực
hiện bản phác thảo đó.



Rắc rối của một kế hoạch dự án là nó cố định. Một khi nó đã được
viết và kí duyệt, quản lý cấp cao sẽ nghĩ rằng dự án sẽ tiến hành
chính xác theo các bước trong kế hoạch. Nhưng thực tế ???


2.Tổ chức dự án
Tổ chức dự án phải trả lời 3 câu hỏi :


Bạn sẽ tổ chức nhóm như thế nào?



Dự án được tổ chức theo Mô hình nào ?



Dự án sẽ chạy trên nền tảng nào?

Nếu bạn làm việc trong một nhóm có kinh nghiệm, tất cả những điều
đó mọi người đều đã nắm vững, vậy thì phần tổ chức dự án có thể là
“Chúng ta sẽ làm theo những gì chúng ta thường làm”.
Tuy nhiên, phần này rất quan trọng cho những dự án mới toanh và
những nhóm thiếu kinh nghiệm, bởi vì phần tổ chức sẽ cho bạn một cái
gì đó để dựa vào khi bạn bắt đầu một dự án thực sự.

3.Phân tích rủi ro
Trong phần phân tích rủi ro, bạn cần phải nghĩ về những nguy cơ, những điều
tồi tệ. Kế hoạch này có thể đổ bể vì những lí do gì? Điều gì tệ nhất có thể xảy
ra? Chúng ta sẽ phải làm gì khi điều đấy thành sự thực?
Đây là một vài rủi ro nên phòng tránh:


Chệch lịch làm việc: một công việc chỉ nên làm trong 3 ngày nhưng đã mất
3 tuần để hoàn thành. Trong một dự án định hướng kế hoạch, đây có thể là
một vấn đề nếu bạn không có các cuộc họp báo cáo tình hình thường
xuyên. Đợi 3 tuần để nói với sếp rằng bạn bị muộn luôn tệ hơn là nói bạn sẽ
bị muộn ngay khi bạn biết điều đó. Trong một dự án linh hoạt thì chuyện
này không thường xảy ra, bởi vì hầu hết những dự án agile có các cuộc họp
báo cáo tính trạng hàng này.




Tỉ lệ lỗi cao: kiểm tra ra rất nhiều lỗi => tiếp tục thêm các tính năng mới hay
dừng lại để chữa lỗi ? Đây có thể là một vấn đề thực trong một dự án mà việc tích
hợp xảy ra theo một kế hoạch định sẵn - mỗi tuần một lần. Với dự án mà tích hợp
xảy ra mỗi ngày, bạn có thể theo kịp với các khuyết tật dễ dàng hơn. Trong cả hai
trường hợp, nếu bạn đang gặp phải một số sai sót cao, tốt nhất là dừng lại, quan
sát và tìm ra nguyên nhân gốc rễ của khiếm khuyết trước khi thêm nhiều chức
năng hơn. Điều này có thể không dễ với quan điểm của nhà quản lý dự án, nhưng
sau đó bạn sẽ phải cảm ơn mình.



Hiểu lầm yêu cầu: nhũng cái ta làm không phải là cái mà khách hàng yêu cầu.
Lỗi kinh điển này là kết quả của việc khách hàng và người phát triển sống ở hai
thế giới khác nhau. Khách hàng thì chỉ hiểu từ góc độ của người sử dụng những
gì anh ta muốn sản phẩm mình làm được. Các nhà phát triển thì hiểu từ góc độ kĩ
thuật là sản phẩm sẽ làm việc như thế nào. Thỉnh thoảng, họ hiểu ý nhau và điều
đó rất tốt; nhưng nhiều khi họ không hiểu ý nhau và đấy là lúc bạn mắc lỗi hiểu
lầm yêu cầu của khách hàng. Cách tốt nhất để tránh trường hợp này là luôn hỏi ý
kiến khách hàng và cho ra mắt sản phẩm của mình thường xuyên khi có thể.




Có quá nhiều yêu cầu: các tính năng mới, các tính năng thay đổi, các tính
năng bị xóa…. những khó khăn không bao giờ kết thúc ? Quá nhiều yêu
cầu có lẽ là lí do lớn nhất của việc chậm kì hạn, tỉ lệ lỗi cao, và dự án thất
bại. Điều này xảy ra khi khách hàng (hoặc chính kế hoạch tiếp thị của
bạn, hoặc do đội ngũ phát triển) liên tục thay đổi yêu cầu khi việc phát
triển đang được tiến hành. Nó dẫn đến phải làm lại một lượng lớn công
việc trong việc lập trình, kiểm tra lại các phác thảo cơ bản, và sự chậm
trễ kéo dài. Quản lý các yêu cầu là việc quan trọng nhất của quản lý dự
án. Trong tiến trình định hướng kế hoạch thường có một hội đồng kiểm
soát sự thay đổi (CCB), họ kiểm tra mỗi yêu cầu mới và quyết định có
nên thêm vào danh sách các tính năng bổ sung hay không. Có thể có một
thành viên trong nhóm phát triển ở CCB, nhưng điều đấy không cần thiết,
và sự nguy hiểm ở đây là CCB sẽ thêm vài tính năng mới mà không hiểu
rõ được toàn bộ lịch trình và nỗ lực phân nhánh. Trong agile, nhóm phát
triển thường nắm được danh sách các yêu cầu được ưu tiên (product
backlog - Scrum), và chỉ điều chỉnh danh sách ở những điểm quan trọng
trong dự án – sau khi lặp lại ở XP, và sau mỗi lần sprint trong Scrum.



Điều chỉnh nhân sự: nhà phát triển có kinh nghiệm nhất của bạn quyết
định tham gia một việc khác trước khi ra mắt sản phẩm ba tuần. Cách tốt
nhất để giảm sự điều chỉnh nhân sự này là :

(1) cho những nhà phát triển một công việc thú vị,
(2) tạo một môi trường làm việc thoải mái thân thiện và
(3) để họ tự làm chủ thời khóa biểu của mình.

Kì lạ ở chỗ, tiền không phải là động lực chính của các nhà phát triển.
Điều đó không có nghĩa là họ không muốn được trả lương hậu hĩnh, mà nó
có nghĩa là trả thêm thêm tiền cho họ để họ làm việc chăm chỉ hơn hoặc
giữ chân họ nhìn chung không hiệu quả. Và nếu, dù cho bạn đã rất cố gắng,
người phát triển giỏi nhất của bạn vẫn rời đi, thì bạn vẫn phải tiếp tục. Tuy
nhiên, đấy không phải là ngày tận thế . Hãy làm giảm ảnh hưởng của việc
mất nhân sự = cách truyền đạt hiểu biết về dự án cho toàn bộ developer
Team . Những nguyên tắc như quyền sở hữu code chung và những kĩ thuật
như lập trình cặp sẽ rất hữu ích.


Một khi bạn đã có danh sách các rủi ro của dự án, bạn cần liên lạc từng người và
nói về hai vấn đề: phòng tránh và xử lý. Đối với mỗi rủi ro, nghĩ về cách bạn tránh
nó. Xác định những kẽ hở trong lịch làm việc, duyệt code, chốt các yêu cầu sớm,
cho ra sản phẩm thường xuyên, yêu cầu lập trình theo cặp để có thể truyền đạt sự
hiểu biết của mình về đoạn code. Sau đó bạn cần nghĩ về những gì bạn sẽ làm nếu
trường hợp xấu nhất xảy ra, đây là phần xử lý. Loại bỏ những đặc tính lỗi khỏi sản
phẩn, dừng làm việc trên các đặc tính mới và tiến hành dò lỗi, điều chỉnh các tính

năng mới ở các sản phẩm sau, và cứ như vậy. Nếu một rủi ro trở thành hiện thực,
bạn sẽ phải làm một điều gì đó vì nó, sẽ tốt hơn khi lên kế hoạch trước việc bạn sẽ
làm gì.
Một khi bạn nói tới phòng tránh và xử lý, bạn sẽ phải có một kế hoạch trình bày
làm sao để xử lý các rủi ro đã biết. Điều này không hoàn toàn giúp bạn tránh khỏi
rắc rối, bởi vì sẽ có giới hạn những rủi ro bạn tránh được; nhưng kinh nghiệm tiếp
xúc với rủi ro bạn nghĩ đến sẽ giúp bạn xử lí tốt những rủi ro mới mà bạn bất ngờ
gặp trong suốt quá trình làm dự án. Nếu dự án của bạn đang sử dụng mô hình lặp ,
đó là một ý kiến tốt để xem lại lỗi của bạn sau mỗi lần lặp lại và xem lỗi nào đã
thay đổi, định hình lại những lỗi mới, và loại bỏ những lỗi nào không có khả năng
xảy ra nữa.


4.Các yêu cầu về tài nguyên


Phần này rất dễ. Có bao nhiêu người bạn cần cho dự án? Họ có cần phải
bắt đầu cùng lúc không, hoặc họ có thể bắt đầu dự án vào những giai
đoạn được đề sẵn không? Có bao nhiêu máy tính mà bạn cần? Bạn sẽ sử
dụng phần mềm nào để phát triển? Môi trường phát triển nào mà bạn
cần? Mọi người có được đào tạo trong môi trường đó không? Những
phần mềm và phần cứng hỗ trợ nào mà bạn cần có? => cần một hệ
thống quản lý cấu hình.



Rất nhiều các câu hỏi trên thường được giải đáp cho bạn bởi nền tảng
mà bạn đang nhắm tới và miền ứng dụng mà bạn đang làm việc. Đấy là
phần dễ. Câu hỏi về kích thước nhóm, ngày bắt đầu, và các bước của dự
án sẽ gần như không trả lời được cho đến khi bạn bắt đầu ước tính công

việc và lên lịch làm việc.


5.Dự toán công việc và lên lịch làm việc


Bước đầu tiên của việc lên lịch dự án là xem bạn sẽ làm gì và mỗi bước
mất bao lâu. Đây là vấn đề con gà-quả trứng kinh điển. Bạn không thể dự
toán được cho tới khi bạn biết chi tiết những nhiệm vụ trong công việc.
Nhưng quản lý của bạn luôn luôn muốn các dự toán và lịch làm việc trước
khi bạn bắt đầu thực hiện. Hãy từ chối điều đó. Để việc thiết kế của bạn là
ưu tiên hàng đầu một khi bạn đã có vài ý tưởng về các yêu cầu. Nếu bạn
chọn một phần nhỏ của các yêu cầu có ưu tiên cao, và rồi thiết kế một giải
pháp cho điều đó, và bạn có thể ước lượng sự lặp lại đó. Đừng lo rằng
những yêu cầu có thể thay đổi, chúng sẽ thay đổi. Bạn cần biết chi tiết các
đặc tính trong các nhiệm vụ trước khi bạn làm ước toán.



Đừng bao giờ tin ai nói với bạn “cái chức năng đó sẽ mất sáu tháng để
làm”. Đấy là một lời dự đoán không có cơ sở và không thực tế. Bạn không
thể ước tính điều gì lâu đến thế. Điều tốt nhất bạn có thể làm là nói “Tôi đã
từng làm 1 chức năng tương tự trong sáu tháng”.




Bạn phải chia nhỏ công việc của bạn thành các nhiệm vụ với thời hạn
không quá một tuần . Một hay hai ngày là tốt nhất. Tốt nhất là dự tính
chi tiết đến đơn vị người – giờ.



Một khi bạn đã có danh sách các công việc cần làm, bạn có thể bắt
đầu ước lượng khối lượng công việc và ước lượng các thứ khác. Khối
lượng việc luôn cần phải nghĩ đến trước, bởi vì bạn không thể biết
được một công việc sẽ tốn bao nhiêu thời gian cho đến khi bạn biết
được khối lượng việc đó.



Cuối cùng, bạn nên có đúng người – những nhà phát triển, người trực
tiếp phát triển ht – làm tất cả các ước tính cho dự án. Các nhà quản lý
không bao giờ nên làm dự toán phát triển. Ngay cả người quản lý đã
từng làm phát triển trong quá khứ, trừ khi đã tham gia quá sâu vào
công tác phát triển thực sự, không nên làm công việc dự toán phát
triển.


6.Lập lịch – thời gian biểu
Một khi bạn đã có các ước tính về các công việc và nhân lực, bạn có thể tạo thời
gian biểu. Đây là vài việc cần làm :


Phân tích sự phụ thuộc lẫn nhau giữa các nhiệm vụ. Sẽ có vài nhiệm vụ không
thể bắt đầu nếu cái khác chưa làm xong. Có thể có vài nhiệm vụ bắt đầu được
khi những cái khác làm xong được một nửa. Sẽ có vài nhiệm vụ có thể bắt đầu
cùng một lúc.



Tìm xem chu kì nhiệm vụ của bạn là gì. Ngoài 8 tiếng mỗi ngày, có bao nhiêu
tiếng đội ngũ phát triển của bạn thực sự làm việc? Bạn cần nhớ đọc thư, tham
gia họp, duyệt code, nghỉ ngơi, đi tắm, toàn bộ đều ăn vào thời gian. Bạn không
thể giả sử một nhiệm vụ một giờ sẽ xong trong một ngày. Thực tế, ngoài 8 tiếng
mỗi ngày, 2 hoặc 4 tiếng sẽ ngốn vào các việc khác, vậy chu kì nhiệm vụ có thể
thấp như 4 tiếng một ngày. Chu kì nhiệm vụ có thể dựa trên văn hóa doanh
nghiệp, vậy bạn cần tìm hiểu xem bạn có những gì trước khi bắt đầu lên lịch.




Nghỉ cuối tuần, nghỉ lễ, các ngày ốm, đào tạo, và thêm những mối
nới lỏng vào khi bạn lên lịch trình. Nếu người phát triển có kinh
nghiệm của bạn có công việc ở một phần quan trọng trong dự án của
bạn thì bạn cần phải biết rằng vị ấy sẽ nghỉ lễ ba tuần vào tháng
năm.



Bạn không thể lên lịch cho một lập trình viên làm hai nhiệm vụ
trong cùng một lúc. Hầu hết các mô hình ptpm không cho bạn làm
điều này, nhưng lại cho phép ghi đè lên nó. Đừng làm vậy. Có thể
bạn muốn làm thế để kịp thời hạn - hãy chống lại điều đó. Chỉ đổi
thời khóa biểu khi bạn chắc chắn sẽ lỡ hạn.


Dùng phần mềm lập kế hoạch dự án ?


Với những dự án nhỏ, có thể dùng excel



Với nhựng dự án lớn => nên dùng. Ví dụ Fast Track Scheduling, hoặc Merlin

Ưu điểm chính mà phần mềm quản lý dự án có thể làm mà bảng tính không thể
là theo dõi phụ thuộc, biết điều gì đó về sự phụ thuộc vào dự án có thể giúp quản
lý của những người làm việc trên những gì, và khi nào.



Lịch trình của Spolsky liệt kê bảy cột sau trong mỗi lịch trình:


• Tên tính năng



• Nhiệm vụ trong các tính năng



• Các ưu tiên của công tác



• Các ước tính gốc (trong người-giờ)



• Những Ước tính hiện tại (trong người-giờ)



• Thời gian đã làm việc trên từng nhiệm vụ (trong người-giờ)



• Thời gian còn lại cho từng nhiệm vụ (còn trong người-giờ)


7.Giám sát dự án


Giám sát dự án là theo dõi những gì xảy ra khi bạn đã có một lịch trình. Một
khi dự án của bạn bắt đầu, nhu cầu quản lý công việc sẽ nảy sinh. Làm thế
nào điều này xảy ra phụ thuộc vào quá trình bạn đang sử dụng. Nhưng bất kể
quá trình nào, bạn cần quản lý tiến độ, quản lý các nhà phát triển, quản lý
chính các quá trình , và trên tất cả, quản lý chính quản lý của bạn.



Là 1 kỹ thuật rất quan trọng của nhà quản lý để đảm bảo dự án đúng tiến độ.



Hãy đối xử với các nhà phát triển của bạn như con người, không phải tài
nguyên. Hỗ trợ nhóm của bạn và giữ cho nhóm cách ly khỏi phiền nhiễu là
ưu tiên số một !.

8.Duyệt và trình bày tình hình


Đánh giá hiện trạng và trình bày hiện trạng là một phần tất yếu của bất kỳ dự án.
Các dự án càng lớn , càng có nhiều đánh giá chính thức.



Hãy nhớ rằng báo cáo tình trạng không khắc phục vấn đề, và nói chung quản lý
không thích nghe về các vấn đề , khó khăn. Khi bạn đưa ra một báo cáo tình trạng
dự án chỉ nói với họ dự án của bạn là gì và sẽ đi đến đâu trong khoảng thời gian
trước khi báo cáo tình trạng tiếp theo. Đừng bao biện và không bào chữa; Thành
thật nói về vấn đề này và bạn đang ở đâu trong lịch trình.



Chỉ cung cấp tin tức tốt là thường có hại cho uy tín của bạn; một cái gì đó sẽ đi
sai tại một số điểm, do đó, sẽ là tốt nhất nếu thoát ra khỏi chúng ngay. Bạn phải
truyền đạt tin xấu về dự án ngay khi có thể. Đó là cách tốt nhất để giảm thiểu các
vấn đề và nhận được sự hỗ trợ để tìm ra giải pháp.


Các lỗi




Chắc chắn, bạn sẽ đưa các lỗi vào chương trình của bạn. Lỗi không

tự xuất hiện; nhà phát triển đặt chúng ở đó. Là một nhà phát triển,
mục tiêu của bạn là :


Đưa càng ít lỗi càng tốt vào mã bạn viết.



Loại bỏ càng nhiều lỗi càng tốt trước khi phát hành mã.

Bug là không thể tránh khỏi.

Mục

tiêu của bạn là phát hành với ít lỗi nhất có thể và làm cho những
lỗi đó không thực sự ảnh hưởng đến sản phẩm hoặc hiệu quả của nó.


Các loại lỗi
1.

Fatal: Sản phẩm bị lỗi, hoặc một phần nền tảng của chức năng không hoạt
động.

2.

Sereval: Một mảnh chính của chức năng không hoạt động, và khách hàng
cũng không có cách nào để thực hiện.

3.

Serious: Một mảnh chức năng không hoạt động, nhưng có một cách giải quyết
cho nó mà khách hàng có thể thực hiện.

4.

Annoying: Một khiếm khuyết nhỏ hoặc lỗi trong tài liệu mà có thể làm phiền
người sử dụng, nhưng không ảnh hưởng đến cách các chương trình hoạt động.

5.

New Feature Request: Đây không phải là một khiếm khuyết, nhưng có yêu
cầu mới đối với các sản phẩm .


9.Sự mổ xẻ
Hầu hết các đội phát triển sẽ làm một “khám nghiệm tử thi” sau mỗi dự án. Mổ xẻ là cơ
hội để phản ánh về dự án mới hoàn thành và trả lời một số câu hỏi, như:


Cái gì đã đúng? Lịch trình của dự án đã làm việc theo cách chúng ta mong đợi? Dự
án đã thực hiện tất cả các tính năng cần thiết cho khách hàng?



Điều gì đã xảy ra? Tại sao dự án có rất nhiều lỗi? Tại sao chúng ta cần phải làm việc
tuần 60 giờ cho những tháng cuối cùng của dự án?



Những vấn đề nào đã phát sinh trong suốt quá trình? Những phần nào đã có vấn đề?



Những gì chúng ta cần phải sửa chữa trong thời gian tới? Những gì chúng ta cần làm
để khắc phục quá trình làm việc của dự án, thói quen làm việc, hoặc môi trường cho
các dự án tiếp theo?



Ai chịu trách nhiệm đối với các bản sửa lỗi? Ai đó phải chịu trách nhiệm về những
thay đổi tiến trình của dự án; đó là ai? (Đừng dành nó cho người quản lý; các nhóm
phát triển nên làm chủ tiến trình này.)


Kết luận


Vậy ta sẽ kết thúc ở đâu đây? Chúng ta đã đi qua những phần quan
trọng trong quản lý dự án và đã giới thiệu vài cách khác của quản lý
dự án. Phần quan trọng nhất là các nhà phát triển nên làm chủ tiến
trình làm việc và các nhà quản lý nên ủng hộ và lắng nghe các nhà
phát triển – đặc biệt lúc lịch trình và ước tính đang được thực hiện –
và hãy trở thành trung gian giữa các nhà phát triển và thế giới. Nếu
bạn có thể làm việc trong một công ty có những điều trên, hãy hạnh
phúc, vì bạn sẽ có thể viết ra những đoạn code tuyệt vời.