Kinh nghiệm quản lý dự án

phần mềm

Tác giả: John Vũ

Người dịch và biên tập: Ngô Trung Việt

Hà Nội, 12/2012

Nguồn tư liệu: John Vu, Carnegie Mellon University http://www.science-technology.vn

i

Mục lục

1. Quản lí dự án phần mềm ...................................... 1

Quản lí dự án-1 ........................................................................ 1 Quản lí dự án-2 ........................................................................ 3 Quản lí dự án-3 ........................................................................ 5 Quản lí dự án và quản trị văn phòng ........................................ 7 Quản lí dự án phần mềm-1 ...................................................... 9 Quản lí dự án phần mềm-2 .................................................... 14 Quản lí dự án phần mềm-3 .................................................... 17 Quản lí dự án phần mềm-4 .................................................... 20 Mục đích của quản lí dự án phần mềm .................................. 23 Phương pháp quản lí dự án mới ............................................ 25 Thành công của dự án phần mềm ......................................... 31 Dự án phần mềm thành công ................................................. 34 Vấn đề với dự án phần mềm .................................................. 35 Vấn đề với dự án phần mềm lớn ........................................... 39 Thất bại dự án ........................................................................ 41 Cách giúp cho một dự án thất bại. ......................................... 43 Tránh thất bại dự án phần mềm ............................................. 45 Cách ngăn ngừa thất bại dự án ............................................. 47 Công việc dự án sớm ............................................................. 50

2. Người quản lí dự án ............................................ 53

Người quản lí dự án-1 ............................................................ 53 Người quản lí dự án-2 ............................................................ 55 Người quản lí dự án-3 ............................................................ 58 Người quản lí dự án hiệu quả ................................................ 61 Người quản lí dự án kém nhất ............................................... 63 Người quản lí dự án giỏi nhất ................................................ 67

ii

Chất lượng của người quản lí dự án ...................................... 68 Kĩ năng của người quản lí dự án-1 ........................................ 70 Kĩ năng của người quản lí dự án-2 ........................................ 73 Lời khuyên cho người quản lí dự án-1 ................................... 76 Lời khuyên cho người quản lí dự án-2 ................................... 87 Lời khuyên cho người quản lí dự án-3 ................................... 89 Đào tạo người quản lí dự án .................................................. 94 Ưu tiên của người quản lí dự án phần mềm .......................... 97 Người quản lí dự án trong miền mới .................................... 101 Phụ nữ trong quản lí dự án .................................................. 102 Kinh nghiệm quản lí dự án ................................................... 106 Lãnh đạo kĩ thuật .................................................................. 109

3. Tổ dự án ............................................................. 113

Kĩ năng con người ................................................................ 113 Làm việc theo tổ ................................................................... 115 Làm việc theo tổ và làm việc theo nhóm .............................. 118 Làm việc trong tổ dự án lớn ................................................. 121 Làm việc tổ của dự án .......................................................... 123 Làm việc tổ trong lập kế hoạch dự án phần mềm ................ 125 Lập kế hoạch làm việc tổ ...................................................... 127 Cách động viên tổ................................................................. 130 Làm việc nhóm và làm việc tổ .............................................. 133 Tương tác với các thành viên tổ .......................................... 136 Công nhân có kĩ năng cho công việc dự án ......................... 138

4. Quản lí dự án theo kế hoạch ............................ 143

Vòng đời phát triển phần mềm và Vòng đời quản lí dự án .. 143 Qui trình cho dự án phần mềm ............................................ 145 Qui trình đơn giản cho dự án nhỏ ........................................ 151 Lập kế hoạch dự án phần mềm-1 ........................................ 155 Lập kế hoạch dự án phần mềm-2 ........................................ 159 Lập kế hoạch dự án phần mềm: Qui trình "mười bước" ...... 164 Qui trình lập kế hoạch dự án ................................................ 167 Ước lượng dự án-1 .............................................................. 170 Ước lượng dự án-2 .............................................................. 173 Ước lượng dự án-3 .............................................................. 176 Ước lượng dự án-4 .............................................................. 178 Kiến trúc hệ thống ................................................................ 179

iii

Vòng đời kiểm thử ................................................................ 182 Cách đo ................................................................................ 184 Cách đo và độ đo ................................................................. 186 Quản lí rủi ro-1 ...................................................................... 187 Quản lí rủi ro-2 ...................................................................... 192 Chất lượng phần mềm-1 ...................................................... 194 Chất lượng phần mềm-2 ...................................................... 196 Chất lượng phần mềm-3 ...................................................... 199 Chất lượng phần mềm-4 ...................................................... 204 Chất lượng phần mềm-5 ...................................................... 206 Chất lượng phần mềm-6 ...................................................... 207 Cải tiến chất lượng phần mềm ............................................. 208 Đảm bảo chất lượng phần mềm .......................................... 210 Kiểm điểm phần mềm .......................................................... 213 Kiểm thử chất lượng............................................................. 216 Kiểm thử chấp nhận của người dùng................................... 220 Trắc nghiệm và kiểm nghiệm ............................................... 222 Thoả mãn của khách hàng ................................................... 224 Khi nào khách hàng phần mềm xây nhà .............................. 226 Nói chuyện với khách hàng .................................................. 228 Một khảo cứu về dự án phần mềm ...................................... 230

5. Phương pháp quản lí Agile .............................. 233

Agile ...................................................................................... 233 Dự án Agile ........................................................................... 235 Một số sự kiện về cách tiếp cận Agile .................................. 237 Quản lí dự án Agile............................................................... 240 Người kiểm thử trong dự án Agile ........................................ 243 Phát triển phần mềm Agile ................................................... 245 Một số sự kiện về cách tiếp cận Agile .................................. 249 Agile và kích cỡ dự án.......................................................... 251 Người quản lí dự án trong môi trường Agile ........................ 253 Người kiểm thử trong dự án Agile ........................................ 255 SCRUM ................................................................................ 257

6. Dự án Capstone ................................................. 263

Dự án Capstone ................................................................... 263 Hướng dẫn dự án Capstone - phần 1 .................................. 266 Hướng dẫn dự án Capstone - phần 2 .................................. 272

iv

Hướng dẫn dự án Capstone - phần 3 .................................. 275 Hướng dẫn dự án Capstone - phần 4 .................................. 280 Một số vấn đề trong dự án Capstone ................................... 285 Học trong dự án Capstone ................................................... 288 Đối thoại về làm việc tổ ........................................................ 292

1

1. Quản lí dự án phần mềm

Quản lí dự án-1

Quản lí dự án phần mềm là việc khó: Là người quản lí dự

án, bạn phải lấy được yêu cầu từ khách hàng, lịch biểu kế

hoạch, tài nguyên và thiết kế tất cả các đường găng, các cột

mốc, các hạn chót để chắc chắn rằng bạn đáp ứng yêu cầu cũng

như tạo ra các kiểm thử nội bộ, kiểm thử chấp nhận. Bạn cũng

ban hành các chỉ dẫn, thiết lập các giao thức thông tin, báo cáo

trạng thái, họp và giải quyết lỗi, vấn đề, tình huống khẩn

trương và mọi tài liệu. Tuy nhiên, sau nhiều năm quản lí cả các

dự án nhỏ và lớn, tôi có thể nói rằng nhân tố quan trọng nhất

đem dự án tới thành công là "vấn đề con người."

Theo kinh nghiệm riêng của tôi, phần lớn các dự án phần

mềm không bao giờ đi theo đúng kế hoạch bởi vì khách hàng

bao giờ cũng thay đổi các yêu cầu nhưng không bao giờ thay

đổi lịch biểu hay chi phí. Họ bao giờ cũng phàn nàn rằng dự án

phần mềm bị chậm, đắt và không cung cấp cho họ điều họ

muốn. Tuy nhiên, phần lớn dự án tôi quản lí bao giờ cũng

thành công đầy đủ, tới mức độ nào đó, bởi vì những yếu tố

"con người" trong những dự án đó. Đó là lí do tại sao tôi nghĩ

2

con người là khía cạnh quan trọng nhất của tất cả các dự án

phần mềm.

Khi dự án lâm vào vấn đề nghiêm trọng, phương pháp

hay công cụ quản lí tốt nhất sẽ không có ích bởi vì chúng

không được thiết kế để giải quyết loại vấn đề này. (Không công

cụ nào có thể sửa chữa được phàn nàn của khách hàng và

phương pháp quản lí được dạy trong đại học không bao quát

các vấn đề về thay đổi yêu cầu - Bao nhiêu giáo sư đã từng

thay đổi bài tập lớn cho học sinh?) Chỉ những người tận tuỵ,

cam kết, có tính đổi mới cao với năng lực, kinh nghiệm và tri

thức của họ mới có thể giúp bạn giải quyết được những vấn đề

này.

Tôi không nói rằng chỉ người giỏi mới làm cho các dự án

phần mềm thành công nhưng không có con người giỏi thì dự án

không thể được thực hiện. Tôi đã thấy nhiều nhân viên làm

việc cần mẫn để sửa chữa vấn đề không đòi hỏi bao nhiêu ngày

trong tuần hay bao nhiêu giờ trong ngày, nếu cần thì từ 14 tới

16 giờ là chuyện thường. Họ sẽ thảo luận về điều được cần tới

và điều có thể được thực hiện để giúp cho người quản lí dự án

của họ tránh thất bại. Một số người có thể làm việc nhiều tuần

để sửa hệ thống quan trọng nhất khi nó bị hỏng. Nhiều người ít

ngủ hay không ngủ chút nào mà không phàn nàn gì. Cho nên

để đảm bảo thành công, người quản lí phải hỏi câu hỏi: Tôi

phải tìm những người như thế ở đâu đây?

Câu trả lời là ở trong hành vi của bạn bởi vì chính nhân

viên giỏi sẽ tìm người quản lí xứng đáng để làm việc cùng chứ

không theo cách khác. Phần lớn các bài giảng về quản lí không

bao giờ đề cập tới việc khen thưởng hành vi tốt đẹp bạn muốn

được lặp lại bởi vì phương pháp của người quản lí ít ảnh hưởng

tới nhân viên và hành vi của họ. (Phần lớn các giáo sư chẳng

bao giờ làm việc trong công nghiệp hay đòi có người làm việc

cho họ để cho họ ra lệnh chứ không phải là khen thưởng hay

3

thừa nhận) cho nên họ dạy rằng bạn là ông chủ và có quyền đòi

hỏi nhân viên làm việc cần mẫn hơn và nhiều hơn thay vì hiểu

rằng việc bó buộc đó không đem tới hành vi tốt nhất của nhân

viên.

Để là người quản lí giỏi, đặc biệt là người quản lí phần

mềm bạn phải hỏi:

1) Tôi có phải cảm ơn những người làm việc tốt không?

2) Cá nhân tôi có nên viết bức thư ngắn hay email "cám ơn"

mọi người về hiệu năng của họ không?

3) Tôi có nên áp dụng hiệu năng của nhân viên làm cơ sở

cho đề bạt không?

4) Cá nhân tôi có nên thừa nhận công khai hiệu năng tốt của

mọi người không?

5) Tôi có nên tổ chức họp tôn vinh sự thành công của các

nhân viên không?

6) Tôi có phải yêu cầu chủ tịch công ti thưởng cho những

người có hiệu năng tốt không?

Nếu câu trả lời là KHÔNG thì tốt hơn cả là bạn hãy học

những điều này thật nhanh bởi vì người nhân viên tốt bao giờ

cũng có cơ hội chọn lựa nơi làm việc tốt và những người quản

lý giỏi.

Quản lí dự án-2

Một người viết cho tôi: “Tôi làm việc cho một công ti

chế tạo nhỏ với vài trăm nhân viên. Làm sao tôi áp dụng kĩ

thuật quản lí dự án cho môi trường cơ xưởng được?"

4

Đáp: Quản lí dự án là nguyên lí doanh nghiệp được dùng

trong nhiều ngành công nghiệp và công ti. Để áp dụng kĩ thuật

quản lí dự án trong công ti của bạn, bạn có thể bắt đầu với vài

điều cơ bản như quản lí thời gian, cộng tác làm việc tổ, làm tài

liệu và trao đổi.

Bạn có thể khuyến khích tổ dự án của bạn làm tài liệu

thời gian của họ từng ngày. Điều đó sẽ giúp họ thấy cách thời

gian của họ được dùng; mất bao nhiêu thời gian để hoàn thành

những nhiệm vụ nào đó. Điều này cũng sẽ giúp cho bạn ước

lượng thời gian phân bổ cho nhiệm vụ và dự án tương lai. Bạn

có thể thúc đẩy nhiều cộng tác và làm việc tổ giữa các thành

viên tổ. Đừng cho phép họ làm việc ở chỗ cô lập mà để họ làm

việc trong các nhóm nhỏ nơi họ có thể học được lẫn nhau.

Trong phần lớn các cơ xưởng, công việc được phân công dựa

trên kĩ năng và kinh nghiệm. Đào tạo là không chính thức và

thường được truyền từ công nhân có kinh nghiệm sang công

nhân ít kinh nghiệm hơn. Điều đơn giản và dễ dàng cho người

này có thể là lẫn lộn và khó với người khác. Bằng việc để mọi

người cùng làm việc và quan sát lẫn nhau, họ có thể học nhanh

hơn và trao đổi ý tưởng nhanh hơn giữa bản thân họ.

Bạn nên bắt đầu tạo ra và làm tài liệu cho qui trình trong

toàn công ti dựa trên thực hành tốt nhất. Để những công nhân

có kinh nghiệm nhất giải thích điều họ làm và cách họ làm nó

cho bạn để cho bạn có thể làm tài liệu chúng thay vì để tri thức

bị giữ trong đầu của ai đó. Điều quan trọng là thiết lập tài liệu

dự án chính thức với mục đích, mục tiêu, cách đo và qui trình

giám sát rõ ràng trước khi công việc bắt đầu. Điều then chốt

của quản lí dự án là đảm bảo mọi người trong dự án đều rõ

ràng về vai trò, trách nhiệm của họ và điều phải làm trong dự

án để cho công việc của họ có thể được nhất quán hơn. Một khi

dự án được bắt đầu, bạn cần họp hàng tuần với khách hàng và

thành viên tổ để chia sẻ thông tin về tiến bộ và giải quyết bất kì

vấn đề nào. Ích lợi của những cuộc họp này sẽ giúp cho công

5

nhân hiểu cách dự án tiến triển, liệu nó có đáp ứng lịch biểu

hay không và liệu có những vấn đề không được giải quyết

không.

Ngay cả ở mức cơ sở của nó, quản lí dự án có thể dường

như tràn đầy quá mức, đó là vì đấy là lần đầu tiên bạn làm nó

theo cách mới, không cùng cách như công ti vận hành. Chừng

nào bạn giải thích rõ ràng cho mọi người về ích lợi của quản lí

dự án như cách tốt hơn để quản lí và làm mọi sự rõ ràng, khách

quan, và đo được với các vai trò, trách nhiệm được xác định rõ,

tôi nghĩ mọi người sẽ thích nó.

Quản lí dự án-3

Nhiều người quản lí dự án bận rộn với những điều tầm

thường như họp công ti và công việc giấy tờ và thường không

giám sát tiến bộ dự án. Họ dựa chủ yếu vào các báo cáo tình

trạng từ các thuộc cấp thay vì quan sát cá nhân. Đây là chỗ

“những ngạc nhiên” xuất hiện vì họ không biết điều gì xảy ra

trong dự án của họ. Nhiều thành viên tổ dự án không biết báo

cáo tin xấu cho nên họ che giấu chúng mãi cho tới khi họ

không thể giấu thêm được nữa. Đến lúc đó đã quá trễ để làm

được gì.

Ba mươi năm qua, khi tôi làm việc ở Hewlett Packard

(HP), công ti này đã yêu cầu mọi người quản lí phải tự cá nhân

mình đi tới dự án và nói chuyện với các thành viên tổ quãng

hai lần một ngày. Phương pháp này có tên là “Quản lí bằng đi

quanh” tại đó người quản lí phải đi tới chỗ làm việc một cách

ngẫu nhiên, để kiểm tra công việc đang tiếp diễn. Người chủ

công ti, ông David Packard tin rằng cách tốt nhất cho những

người quản lí để biết về các dự án của họ là bằng việc kiểm

điểm ngẫu nhiên công việc trên cơ sở hàng ngày. Vào lúc đó,

6

tôi còn ngần ngại mãi cho tới khi tôi rời khỏi HP để sang làm

việc cho GE thì tôi mới nhận ra trí huệ của ông Packard. Kể từ

đó và trong cả nghề nghiệp của tôi, tôi bao giờ cũng tuân theo

thực hành này và thấy thông tin có giá trị bởi việc làm điều đó.

Bằng việc gặp ngẫu nhiên với các thành viên tổ trên cơ

sở hàng ngày, tôi xây dựng mối quan hệ tốt với họ. Một khi tin

cậy được xây dựng, tôi nhận được thông tin chính xác về dự án.

Các thành viên tổ có thể nói cho tôi về bất kì cái gì họ muốn

mà không lo lắng về liệu tôi có thích nó hay không. Điều đó

cũng làm cho việc của tôi như người quản lí được hiệu quả hơn

vì tôi có thể nhanh chóng ra quyết định dựa trên điều tôi biết.

Nếu có "vấn đề nhạy cảm" mà thành viên tổ không muốn thảo

luận ở chỗ làm việc, họ có thể tới văn phòng của tôi để thảo

luận ở chỗ riêng tư. Phần lớn các vấn đề nhạy cảm đều là vấn

đề cá nhân thay vì kĩ thuật. Bằng việc hiểu điều đó, tôi có thể

giải quyết nó nhanh chóng nhất có thể được cho nên nó sẽ

không tràn sang toàn thể dự án.

Vấn đề cá nhân thường xảy ra khi các thành viên tổ

không đồng ý về cái gì đó và nó gây ra xúc động. Trong trường

hợp đó, điều quan trọng nhất là nhận diện tất cả các sự kiện để

xác định nguyên nhân của xung đột. Khi các thành viên tổ bất

đồng, họ muốn người khác về phe với họ và không có giải

pháp nhanh chóng; điều đó có thể leo thang thành vấn đề

nghiêm trọng. Đây là chỗ "kĩ năng lắng nghe" của người quản

lí là quan trọng. Kĩ thuật của tôi là lắng nghe các luận cứ của

họ ở chỗ riêng tư, không ở trước tổ. Bằng việc lắng nghe cẩn

thận mà không có bình luận nào, tôi cho phép họ giảm bớt giận

dữ và bình tĩnh lại. Khi cả hai bên đều bình tĩnh, sẽ dễ thảo

luận về một giải pháp cho cả đôi bên. Nhiều người quản lí dự

án không thích giải quyết xung đột cá nhân. Tuy nhiên, thỉnh

thoảng xung đột là điều tốt. Đặc biệt nếu nó mở ra cái gì đó cần

được giải quyết. Nó có thể "đánh thức" các thành viên tổ nếu

họ không đủ tích cực trong công việc dự án. Lấy thông tin từ

7

thảo luận xung đột có thể làm cho các thành viên tổ nghĩ nhiều

hơn về các vấn đề liên quan tới dự án.

Mọi công ti đều yêu cầu tổ dự án báo cáo về tình trạng dự

án dựa trên cơ sở hàng tuần. Báo cáo trạng thái hàng tuần là tài

liệu về tiến bộ của dự án và nó có ích cho người quản lí cấp cao

theo dõi tiến bộ liệu cái gì đó đi sai không. Tuy nhiên, nếu bạn

thực hành "đi vòng quanh" hàng ngày và giải quyết vấn đề

ngay lập tức, ít nhất bạn không có mấy trong báo cáo tuần. Nó

cũng có nghĩa là dự án tiến triển êm thấm.

Chính trách nhiệm của người quản lí dự án là lãnh đạo.

Nếu họ không quản lí và giúp đỡ tổ đạt được kết quả mong đợi,

họ không làm việc của họ. Người quản lí dự án phải chắc chắn

rằng họ biết cái gì được cần, khi nào thì tham gia, khi nào thì

lắng nghe, khi nào thì có hành động, và quản lí tích cực mọi

thứ trong dự án. Trong hầu hết các công tí, khi dự án thất bại,

họ đuổi người quản lí dự án.

Quản lí dự án và quản trị văn phòng

Một sinh viên mới tốt nghiệp viết cho tôi: “Em làm việc

trong một công ti nơi người quản lí dự án có chứng chỉ quản lí

trưng ra trong văn phòng họ nhưng họ không quản lí cái gì cả.

Họ dành nhiều thời gian vào họp hành, viết đề án, kiểm điểm

chi tiêu và ngân sách, và viết báo cáo hàng tháng. Họ hiếm khi

gặp người phát triển nhưng vẫn yêu cầu báo cáo về các hoạt

động hàng tuần để cho họ có thể báo cáo cho ông chủ của họ.

Khi chúng em nêu ra mối quan tâm, họ bảo chúng em rằng họ

biết quản lí dự án vì bằng chứng là chứng chỉ của họ. Em bị lẫn

lộn về kiểu quản lí dự án này. Thầy có gợi ý gì?"

8

Đáp: Có khác biệt giữa biết và làm. Người quản lí dự án

giỏi có cả tri thức và kĩ năng để quản lí dự án. Tri thức tới từ

việc học nhưng kĩ năng tới từ kinh nghiệm thực tế trong thực

hiện nó. Người quản lí dự án giỏi có kinh nghiệm trong lập kế

hoạch, ước lượng, giữ cân bằng các sức ép khác nhau, làm việc

với khách hàng, quản lí thay đổi, và loại bỏ chướng ngại cho tổ

dự án của họ. Có thể là người quản lí của bạn có đào tạo như

bằng chứng về chứng chỉ của họ nhưng chưa bao giờ thực hiện

nó trong dự án thực. Nếu họ chỉ hội tụ vào việc tạo ra báo cáo

hiện trạng, đệ trình ngân sách, kiểm tra chi tiêu, kiểm điểm chi

phí, và làm bài trình bày mà chỉ là các hoạt động hành chính thì

họ là người quản trị văn phòng, không phải là người quản lí dự

án.

Người quản lí dự án giỏi hiểu vòng đời dự án và theo dõi

cẩn thận qui trình để quản lí dự án. Họ phân tích ích lợi mà dự

án đặc biệt sẽ đem lại cho công ti trước khi cam kết với bất kì

chi tiêu nào. Trong dự án, nếu mọi sự thay đổi và trở nên rõ

ràng rằng ích lợi không còn khả thi, họ cắt bỏ dự án cho nên

không tiền nào bị phí hoài.

Người quản lí dự án giỏi biết rằng người phát triển cho

dự án cần hiểu vai trò và trách nhiệm của họ để cho họ phân

công nhiệm vụ cho từng người tương ứng. Không có vai trò và

trách nhiệm rõ ràng, không ai biết họ được giả định làm gì.

Trong trường hợp đó, họ sẽ đổ lỗi cho nhau khi cái gì đó đi sai

và dự án có thể không hoàn thành thành công.

Người quản lí dự án giỏi biết cách phân chia dự án thành

các nhiệm vụ nhỏ hơn cho từng pha bằng việc dùng kĩ thuật

Cấu trúc phân việc Work Breakdown Structure (WBS). Từng

pha được kiểm điểm cẩn thận và báo cáo để cho người quản lí

cấp cao có thể quyết định. Chẳng hạn, dự án có đúng hạn

không, trong ước lượng chi phí không? Rủi ro có chấp nhận

được không? Phân chia dự án thành các pha, và phân tích mọi

9

rủi ro và ích lợi trước khi tiếp tục là cách tiếp cận khác mà cho

phép người quản lí dự án quản lí dự án được tốt hơn.

Người quản lí dự án giỏi bao giờ cũng hội tụ vào kết quả

cuối cùng hay sản phẩm thậm chí trước khi dự án bắt đầu. Họ

có viễn kiến về sản phẩm cuối sẽ là gì. Họ hiểu rõ yêu cầu của

họ, và phát triển kế hoạch đạt tới được mà sẽ làm cho dự án dễ

quản lí. Họ thường xuyên học khi nào quản lí dự án. Nếu họ

phạm sai lầm, họ học từ nó để cho họ không phạm cùng sai lầm

hai lần. Khả năng học từ sai lầm làm giầu có cho kinh nghiệm

của họ cũng như kĩ năng quản lí của họ.

Về căn bản, kinh nghiệm và kĩ năng thực sự phân biệt

một người quản trị văn phòng với người quản lí dự án. Cũng

như khác biệt giữa người có thể đọc bản đồ trong văn phòng và

người dùng bản đồ để du hành khoảng cách xa và đã làm nhiều

chuyến đi.

Quản lí dự án phần mềm-1

Tuần trước, tôi có cuộc họp với vài sinh viên thuộc

chương trình thạc sĩ về quản trị kinh doanh (MBA). Họ hỏi tôi

tại sao nhiều dự án phần mềm thất bại và liệu người quản lí

doanh nghiệp tốt nghiệp từ chương trình MBA có thể quản lí

dự án phần mềm được không. Trước khi trả lời họ, tôi hỏi ý

kiến của họ. Họ tin rằng vì họ được đào tạo về quản lí, họ có

thể quản lí mọi thứ và đó là điều họ được dạy trong trường kinh

doanh. Tôi KHÔNG đồng ý với quản điểm đó nên sau đây là

thảo luận của tôi về quản lí dự án phần mềm:

Có nhiều lí do cho dự án phần mềm thất bại nhưng lí do

hiển nhiên nhất là người quản lí dự án không có kinh nghiệm

hay kĩ năng quản lí dự án. Nhiều người quản lí dự án hứa với

10

khách hàng bất kì cái gì chỉ để làm hài lòng họ mà không thực

sự biết sẽ mất bao nhiêu thời gian và cần bao nhiêu nỗ lực. Họ

chấp nhận “lịch biểu phi thực tế” từ khách hàng rồi buộc tổ dự

án phải tuân theo. Tất nhiên, đây là công thức cho thất bại bởi

vì việc cần sáu tháng nhưng khách hàng chỉ cho bạn ba tháng

thì bạn không thể hoàn thành được nó bằng làm việc cần cù

hơn. Nhiều người quản lí không lập kế hoạch mà nhảy ngay

vào viết mã để chứng minh cho người quản lí cấp cao rằng họ

"rất tích cực”. Không lập kế hoạch cẩn thận, họ sẽ bỏ lỡ nhiều

điều quan trọng và họ phải "làm lại từ đầu" cho chúng. Việc

thiếu lập kế hoạch này làm tốn nhiều tiền cho công ti khi dự án

phải chi tiêu nhiều hơn nó đáng phải chi tiêu.

Câu hỏi của tôi là: Chương trình MBA có dạy ước lượng

phần mềm và lập kế hoạch phần mềm không?

Bởi vì nhiều người quản lí dự án không biết cách ước

lượng lịch biểu, họ “lập lịch ngược” từ hạn chót đã cho và hi

vọng mọi sự sẽ tốt. Chẳng hạn dự án bắt đầu từ tháng giêng và

khách hàng cho họ sáu tháng thì bản kế hoạch sẽ trông như thế

này: Tháng sáu: Chuyển giao phần mềm, Tháng năm: Kiểm thử

phần mềm; Tháng ba và bốn: Viết mã; Tháng hai: Thiết kế và

tháng giêng: Xây dựng tổ. Họ thêm ngày vào bản kế hoạch mà

không biết gì về cách ước lượng thời gian cần cho từng pha.

Thỉnh thoảng họ dùng kĩ thuật “lạc quan” từ các sách giáo khoa

kinh doanh hàn lâm như ước chi phí bằng việc dùng công thức:

Chi phí = Kích cỡ x độ phức tạp/năng suất. Đây là lí thuyết

đúng nhưng KHÔNG THỂ cáp dụng được vào "dự án thực"

bởi vì nó có ba nhân tố không biết: Kích cỡ, độ phức tạp và

năng suất. Trong lớp học, các giáo sư cho sinh viên những

nhân tố đó để tính chi phí nhưng trong thực tế, đặc biệt lúc bắt

đầu dự án, khó mà ước lượng kích cỡ hay độ phức tạp của mã.

Trong bất kì biến cố nào, mọi ước lượng chi phí đều có may rủi

tiềm năng, không được kiểm điểm và điều chỉnh, công ti có thể

11

đi tới ước lượng thấp cho phí và mất tiền. Điều này xảy ra

nhiều trong công nghiệp ngày nay.

Câu hỏi của tôi là: Chương trình MBA có dạy lập lịch

phần mềm và điều chỉnh ước lượng chi phí không?

Nhiều người quản lí dự án KHÔNG biết cách thu được

yêu cầu từ khách hàng. Họ tin điều khách hàng nói cho họ là

"đủ tốt”. Không trắc nghiệp hay tuân theo phương pháp phân

tích yêu cầu để nhận diện điều khách hàng thực sự cần, họ sẽ

làm việc với các yêu cầu được cho. Tất nhiên, khách hàng thay

đổi ý của họ và thường thêm nhiều chức năng vào yêu cầu của

họ. Những điều này gây ra nhiều thay đổi trong dự án và đến

lượt nó, gây ra nhiều việc làm lại, nhiều thời gian, và cuối cùng

làm chậm trễ dự án. Dự án phần mềm KHÔNG chỉ là lập trình

mà đi tới giải pháp cho vấn đề doanh nghiệp. Để hiểu các yêu

cầu phần mềm, người quản lí phải hiểu yêu cầu doanh nghiệp,

các yêu cầu hệ thống, yêu cầu phần cứng bởi vì các yêu cầu

phần mềm vận hành trên ba mức này.

Câu hỏi của tôi là: Chương trình MBA có dạy việc phát

triển yêu cầu, vấn đề người dùng, vấn đề phần cứng, trắc

nghiệm và kiểm nghiệm yêu cầu không? Nó có các kĩ thuật mô

hình hoá bằng việc dùng công cụ phần mềm không?

Nhiều người quản lí dự án không được đào tạo về ước

lượng tài nguyên như số người được cần tới, kĩ năng được cần

tới của họ, cho nên họ lất bất kì ai sẵn có vào làm việc cho dự

án. Khi dự án có người sai với kĩ năng hạn chế, năng suất sẽ bị

ảnh hưởng. Nhiều người quản lí không biết cách thuê và giữ

người then chốt, họ không biết về tất cả những kĩ năng cần để

phát triển phần mềm nhưng nghĩ về những người phần mềm là

những người lập trình. Không có tri thức kĩ thuật chi tiết về

kiến trúc, thiết kế, phần cứng và giao diện hệ thống, họ có thể

phân công người sai cho các nhiệm vụ mà những người này

không đủ phẩm chất và kết quả có thể là thảm hoạ. Không có

12

hồ sơ về con người với tri thức chuyên gia nào đó được cần để

thực hiện công việc dự án sẽ thất bại.

Sai lầm thông thường khác là nhiều người quản lí không

cho đủ thời gian cần thiết cho các thành viên tổ học về dự án

trước khi họ bắt đầu. Học về các yêu cầu của dự án đòi hỏi thời

gian và nên được xem xét trong kế hoạch dự án. Nhiều công ti

có nhiều dự án yêu cầu kĩ năng tương tự cho nên họ dịch

chuyển người then chốt của mình từ dự án này sang dự án khác

dựa trên ưu tiên giữa các dự án. Kĩ thuật quản lí "luân chuyển

người" này là phí hoài năng suất quí giá bởi vì các thành viên

tổ mất thời gian để làm quen với dự án họ được phân công.

Thực hành này cũng làm nảy sinh một dự án phải dừng làm

việc tạm thời cho tới khi thành viên tổ quay lại từ dự án khác.

Điều này đặc biệt mấu chốt khi một kĩ năng then chốt cần được

tham gia vào và điều đó làm chậm lịch biểu dự án và đóng góp

thêm vào việc làm mòn mỏi nhân viên vì mọi người phải làm

quá nhiều thứ trong một thời kì kéo dài.

Nhiều người quản lí bận rộn thế và họ không theo dõi

điều người của họ làm từng ngày. Họ không biết về hoạt động

của nhân viên để cho họ có thể thúc bẩy các kĩ năng nhân viên

cho có năng suất. Họ phân công người làm việc trên các nhiệm

vụ tương ứng theo lịch biểu; chừng nào họ còn đáp ứng được

lịch biểu thì không có vấn đề gì. Tuy nhiên, có các thành viên

có thể hoàn tất nhiệm vụ 5 ngày trong 2 ngày và người khác có

thể không hoàn thành được nhiệm vụ 3 ngày trong ít nhất 10

ngày do kĩ năng của họ và việc phân công. Không kiểm điểm

các hoạt động trên cơ sở hàng ngày hay hàng tuần, người quản

lí không biết ai cần giúp đỡ và ai không cần giúp đỡ cho tới khi

vấn đề nảy sinh. Hiểu biết về phân phối công việc, về phân

công nhiệm vụ và tri thức về kĩ năng là mấu chốt trong mọi dự

án phần mềm.

13

Câu hỏi của tôi là: Chương trình MBA có dạy qui trình

phát triển phần mềm, đào tạo kĩ năng, nhận diện kĩ năng và

phân công công việc không?

Điều gì sẽ xảy ra khi cái gì đó xấu xuất hiện trong dự án

phần mềm? Không có đào tạo đúng, nhiều người quản lí trở

nên giận dữ, thay vì lãnh đạo và hỗ trợ tổ dự án, họ làm nản

lòng nhân viên bởi yêu cầu rằng nhân viên phải làm những điều

nào đó hay buộc tội nhân viên không làm việc chăm chỉ hơn.

Điều này sẽ thêm sức ép cho môi trường làm việc linh động và

làm giảm năng suất hay thành viên tổ, đến lượt mình sẽ làm

chậm trễ dự án thêm nữa. Khi họ thấy rằng gần tới hạn chuyển

giao nhưng tổ của họ vẫn còn đang viết mã, họ ra lệnh cho

nhân viên bỏ qua vài thứ như kiểm điểm hay kiểm thử để tiết

kiệm thời gian. Thiếu kiểm thử, phần mềm sẽ có nhiều lỗi rồi

công ti phải sửa các lỗi này. Điều này sẽ yêu cầu nhiều thời

gian hơn, nhiều nỗ lực hơn, nhiều tiền hơn và nhiều chậm trễ

hơn. Tất nhiên, khách hàng KHÔNG hài lòng và có thể không

muốn làm kinh doanh với công ti trong tương lai. Khi các vấn

đề nảy xảy ra, nhiều người quản lí buộc tổ làm việc nhiều giờ

hơn trong một thời gian kéo dài để sửa lỗi của lịch biểu không

thực tế cho nên nhiều thành viên tổ rời khỏi dự án trước khi dự

án được hoàn thành.

Câu hỏi của tôi là: Chương trình MBA có dạy cách quản

lí người kĩ thuật không? Cách phối hợp công việc tổ? Cách

nuôi dưỡng tổ thay vì lạm dụng họ?

Chúng ta có thể làm gì để tránh những sai lầm này?

Câu trả lời hiển nhiên là: Cung cấp đào tạo tốt hơn cho

người quản lí phần mềm nhưng riêng một mình đào tạo có đủ

không? Liệu có thể cho ai đó KHÔNG có tri thức phần mềm

làm quản lí dự án phần mềm không? Liệu có thể cho một người

kinh doanh tốt nghiệp MBA quản lí dự án phần mềm không?

14

Người quản lí được đào tạo về doanh nghiệp có thể quản lí

được mọi thứ không?

Tôi tin người quản lí phần mềm tốt PHẢI có cả kinh

nghiệm kĩ thuật và doanh nghiệp. Họ phải làm việc trong phát

triển phần mềm trong nhiều năm để họ hiểu mọi hoạt động bên

trong một dự án. Họ phải nhận được đào tạo về ước lượng thời

gian, nỗ lực và lập lịch biểu và thực tế thực hiện những việc

này trong các dự án thực để cải tiến kĩ năng của họ. Họ phải

hiểu rằng lập kế hoạch không bao giờ đứng yên nhưng thường

xuyên phải được cập nhật vì mọi sự luôn thay đổi. Người quản

lí tốt bao giờ cũng học cách thương lượng với khách hàng và

không bao giờ phạm sai lầm uỷ nhiệm "ngày tháng lịch biểu

không thực”. Bởi vì những yêu cầu này, người quản lí phần

mềm GIỎI là rất khó tìm ra và đó là lí do tại sao nhiều công ti

phần mềm toàn cầu sẵn lòng trả lương cao cho họ.

Quản lí dự án phần mềm-2

Chìa khoá cho thành công của bất kì dự án phần mềm

nào là thiết lập các yêu cầu tốt. Từ những yêu cầu này, người

quản lí dự án có thể đặt ra mục đích, chiều hướng, và trao đổi

chúng với thành viên tổ. Điều quan trọng là cả người dùng và

người phát triển đều hiểu rõ ràng các yêu cầu cũng như mong

đợi. Tất nhiên, người quản lí dự án phải chắc chắn rằng các yêu

cầu là đầy đủ, đúng đắn, chính xác, nhất quán, kiểm thử được

và theo dõi dấu vết được.

Trong công việc phần mềm, lập kế hoạch dự án là rất

quan trọng vì nó là cơ sở để quản lí dự án. Khả năng của người

quản lí dự án kiểm soát và quản lí dự án phụ thuộc cao độ và sự

chính xác của kế hoạch. Bản kế hoạch dự án tốt phải bao gồm

ước lượng dự án, lịch biểu, tài nguyên, yêu cầu kĩ năng, công

15

nghệ then chốt và quản lí rủi ro. Bản kế hoạch cũng phải bao

gồm cách quản lí cấu hình, đảm bảo chất lượng được áp dụng

và cách tiến độ được theo dõi. Lập kế hoạch dự án là kĩ năng

yêu cầu nhiều kinh nghiệm. Bạn có thể học về lập kế hoạch dự

án trong lớp hay đọc sách nhưng bạn sẽ cần thực hành nó trong

nhiều năm trước khi bạn có thể phát triển kĩ năng để tạo ra bản

kế hoạch chính xác. Trong lập kế hoạch, ước lượng dự án có lẽ

là kĩ năng khó làm chủ nhất cho nên tôi gợi ý rằng bạn giữ dấu

vết của mọi ước lượng bạn làm trong sổ tay, kiểm điểm lại

khác biệt giữa điều bạn đã ước lượng và điều thực tế xảy ra và

dùng chúng để cải tiến kĩ năng ước lượng của bạn.

Vì yêu cầu thay đổi thường xuyên, bạn cũng cần kiểm

soát các thay đổi tương ứng theo qui trình kiểm soát thay đổi và

gặp gỡ với người dùng để đặt ưu tiên cho những thay đổi này.

Là người quản lí dự án, bạn nên lựa chọn vòng đời phát triển

đưa ra tăng dần và “đông cứng yêu cầu” trước khi bắt đầu các

pha thiết kế và thực hiện và trì hoãn thay đổi tương lai cho bản

đưa ra tiếp. Bằng việc dựng tăng dần phần mềm, bạn có thể

đưa ra sản phẩm dựa trên ưu tiên của người dùng và tránh phản

ứng vào phút chót với thay đổi yêu cầu.

Dự án không có người quản lí có kĩ năng giống như

giương buồm đi ra đại dương không có thuyền trưởng. Người

quản lí dự án có kĩ năng biết cách kiểm soát dự án và phải có

quyền quyết định đối với mọi tài nguyên được cần để thực hiện

dự án. Người quản lí cũng cần biết cách làm việc với khách

hàng để làm sáng tỏ yêu cầu và hiểu mong đợi của họ. Khách

hàng khác nhau có các mong đợi khác nhau. Một số muốn chất

lượng nhưng số khác có thể muốn nhiều chức năng hơn, một số

sẽ chăm lo tới lịch biểu nhưng một số lại chỉ quan tâm tới chi

phí. Làm sao ưu tiên hoá các mong đợi khác nhau và giữ cân

bằng các quan điểm khác nhau là kĩ năng của người quản lí dự

án. Đó là lí do tại sao bên cạnh kĩ năng kĩ thuật và quản lí,

16

người quản lí giỏi cũng phải có kĩ năng thương lượng và trao

đổi.

Người quản lí dự án giỏi biết cách đưa tổ vào hoạt động

ra quyết định. Bằng việc để các thành viên tổ tham gia vào việc

lập kế hoạch và theo dõi dự án, tổ sẽ cảm thấy rằng họ có cái gì

đó để nói và ít nhất quyết định nào đó về dự án của họ và cam

kết làm cho dự án thành công hơn. Một trong những yếu tố

then chốt trong dự án phần mềm là kĩ năng của các thành viên

tổ dự án. Người quản lí dự án giỏi bao giờ cũng biết cách thuê,

đào tạo và phát triển các thành viên tổ giỏi nhất có thể được.

Không may là ngày nay nhiều người quản lí dự án chỉ tập trung

vào số người được cần chứ không phải là kĩ năng được cần.

Đây là sai lầm lớn bởi vì KHÔNG phải tất cả những người phát

triển đều như nhau. Nhiều người quản lí KHÔNG biết cách lựa

chọn, phỏng vấn và đào tạo thành viên tổ mà lấy bất kì ai sẵn

có. Người quản lí dự án giỏi cũng tương tự như "huấn luyện

viên tổ thể thao". Người đó lựa chọn thành viên cẩn thận, cung

cấp đào tạo, phân công cho họ các vai trò, trách nhiệm và đánh

giá hiệu năng công việc của họ, kể cả hành vi và công việc tổ

của họ. Người quản lí giỏi cũng phát triển chương trình đào tạo

dự án và bản kế hoạch con đường nghề nghiệp cho tổ bởi vì

người đó biết nguyên tắc: “Chăm sóc cho người của bạn trước

thì họ sẽ chăm sóc cho bạn.” Nhân tiện, nếu tổ thể thao bị thua,

họ không sa thải cầu thủ mà sa thải huấn luyện viên. Cùng điều

đó xảy ra trong phần mềm, nếu dự án thất bại, họ không sa thải

người phát triển mà sa thải người quản lí dự án.

Quản lí dự án phần mềm cũng là nhận diện và quản lí rủi

ro liên kết với dự án. Mọi dự án đều có rủi ro cho nên hoạt

động nhận diện rủi ro và tác động của chúng sẽ dẫn tới việc lập

kế hoạch dự án thấu đáo hơn. Nhận diện rõ ràng các yếu tố rủi

ro, xác suất xuất hiện của chúng, tác động của chúng lên dự án,

và có kế hoạch giảm nhẹ những rủi ro này là cực kì quan trọng

cho thành công của dự án. Người quản lí dự án giỏi bao giờ

17

cũng giám sát mọi hành động bên trong dự án. Bởi vì thông tin

trạng thái là cốt yếu cho việc kiểm soát dự án và chung cuộc

đảm bảo thành công dự án, việc thu thập thông tin trên cơ sở

hàng ngày là rất quan trọng. Với những dự án nhỏ, người quản

lí có thể kiểm điểm các hoạt động bằng nhiều phương pháp và

công cụ nhưng dự án lớn có thể yêu cầu một số công cụ và cơ

chế tự động hoá. Điều cũng quan trọng là cất giữ các thông tin

này để dùng trong lập kế hoạch dự án và nỗ lực phát triển

tương lai.

Phần lớn những người quản lí dự án thành công đều đã

quản lí nhiều dự án trước khi họ trở nên thành công. Như tôi đã

nhắc tới trước đây, việc quản lí dự án cần thời gian và bạn

KHÔNG thể vội vàng về nó được. Về căn bản có lẽ phải mất

năm tới bẩy năm và kinh nghiệm trong nhiều dự án để phát

triển kĩ năng này. "Công thức bí mật" của tôi để là người quản

lí dự án giỏi là học từ sai lầm quá khứ và quản lí dự án theo

cách nhất quán. Thành công yêu cầu làm việc cần mẫn về các

kĩ năng kĩ thuật, quản lí và "kĩ năng mềm" và phần lớn trong

tất cả mọi việc là đối xử với thành viên tổ của bạn một cách

kính trọng và trung thực. Phải chắc họ biết điều đang diễn ra,

cách họ khớp vào, trao đổi với họ thường xuyên để khử bỏ mọi

lẫn lộn, và đảm bảo tính lặp lại được. Người quản lí càng chia

sẻ thông tin và trao đổi với các thành viên tổ tốt thì dự án càng

có thể tốt hơn.

Quản lí dự án phần mềm-3

Vài năm trước đây khi tôi dạy quản lí dự án phần mềm ở

châu Á, tôi thấy rằng có lẫn lộn giữa "quản lí dự án" và "quản lí

dự án phần mềm". Một số đại học đã dùng sách "Quản lí dự

án" được viết cho công nghiệp xây dựng và các công nghiệp

18

khác nhưng không cho phần mềm. Chẳng hạn, khi họ ước

lượng nỗ lực, nhiều người bắt đầu với 5% trong pha quan niệm

và khởi đầu, 10% trong pha kiến trúc và thiết kế, 75% trong

pha thực hiện, và rồi 10% về bảo hành. Điều này là đúng cho

công nghiệp xây dựng. Bạn không cần nhiều người khi làm

việc với người chủ để hiểu nhu cầu yêu cầu. Lập kế hoạch xây

dựng chủ yếu là công việc hậu cần và quản trị. Bạn không cần

nhiều người trong pha kiến trúc và thiết kế. Kiến trúc sư thiết

kế ra việc xây dựng với một tổ nhỏ và khi bản kế hoach kiến

trúc được hoàn thành, nó không bao giờ thay đổi. Nỗ lực chính

xảy ra trong pha xây dựng khi bạn cần nhiều công nhân để xây

nhà. Sẽ có nỗ lực nhỏ nào đó trong pha bảo trì (Sơn và trang

hoàng làm đẹp).

Trong dự án phần mềm, pha quan trọng nhất là hai pha

đầu. Lập kế hoạch là mấu chốt và kiến trúc cùng thiết kế là bản

chất. Vì yêu cầu phần mềm thường thay đổi, thường muộn

trong dự án; các thành viên tổ phải tham gia sớm vào hiểu nhu

cầu doanh nghiệp, phân tích và trắc nghiệm các yêu cầu để làm

giảm rủi ro của thay đổi yêu cầu. Nỗ lực được cần tới phải ít

nhất là 20% trong pha yêu cầu, 20% trong pha lập kế hoạch, và

20% trong pha kiến trúc và thiết kế. Bằng việc có ít nhất 60%

thành viên tổ tham gia vào trong dự án từ sớm, tổ có thể làm

việc với khách hàng để thu thập yêu cầu rồi chia các yêu cầu

thành các cấu phần nhỏ hơn nơi họ có thể ước lượng chính xác

hơn. Biết nỗ lực và thời gian cần để thực hiện, họ có thể lập kế

hoạch dự án tương ứng. Tổ tổ chức các cấu phần này tương

ứng theo kiến trúc để cho đến cuối chúng tất cả khớp đúng. Chỉ

khi những việc này được làm xong tổ mới có thể thiết kế từng

cấu phần về chi tiết hơn. Bằng việc làm hầu hết công việc sớm

hơn và chắc rằng các yêu cầu là được tính tới; việc xây dựng và

kiểm thử sẽ dễ dàng hơn. Dự án phần mềm không thất bại vì

người lập trình không thể viết mã được; nó thường thất bại vì

yêu cầu kém, lập kế hoạch kém, và quản lí dự án kém.

19

Bởi vì lẫn lộn về "quản lí dự án" và "quản lí dự án phần

mềm", một số người quản lí không chú ý đủ tới các pha sớm

của phát triển phần mềm làm phát sinh nhiều thất bại. Ở một số

nước, quản lí dự án phần mềm không được dạy trong chương

trình đại học nên sinh viên không hiểu khái niệm và vòng đời

quản lí dự án phần mềm. Phần lớn các lớp quản lí dự án được

dạy trong trường kinh doanh nơi sinh viên không có tri thức về

phát triển phần mềm. Không có tri thức đúng về phần mềm,

không có đào tạo dự án phần mềm đúng, nhiều người quản lí đi

theo phương pháp thông dụng về "Viết mã & Sửa lỗi". Phương

pháp này bỏ qua yêu cầu và thiết kế để thiên về cách đơn giản

viết mã trước rồi sửa lỗi sau. Lập kế hoạch dự án được thực

hiện bởi người quản lí dự án mà không có việc tham gia của

các thành viên tổ. Không có tri thức đúng về phần mềm, ước

lượng dự án được dựa trên lịch biểu do khách hàng đưa cho

mặc dù khách hàng thực sự không biết phải mất bao lâu để

hoàn thành dự án. Bản kế hoạch dự án được dựa trên ngân sách

do người quản lí cấp mà không có ước lượng đúng. Khi nó

được chấp thuận, nó không bao giờ được cập nhật cho dù yêu

cầu đã thay đổi. Tổ dành hầu hết nỗ lực vào viết mã và sửa lỗi.

Họ sửa càng nhiều lỗi họ thêm vào, họ càng phải sửa nó lần

nữa. Vòng viết mã và sửa cứ liên tục cho tới cuối. Kết quả là,

dự án phần mềm tốn kém, không đáp ứng lịch biểu, và thường

có chất lượng kém. Không may, phương pháp này vẫn được

dùng ở nhiều chỗ.

Một số sinh viên hỏi tôi: “Tại sao dự án phần mềm khác

với dự án không phần mềm?" Điều đó là đơn giản, dự án phần

mềm giải quyết với "công việc trí tuệ" trong khi các dự án khác

giải quyết "công việc vật lí". Bạn có thể nhìn vào công việc vật

lí như xây nhà và biết bao nhiêu phần của nó đã được hoàn

thành. Chẳng hạn, 10% hay 50% nhưng khó làm được điều đó

với sản phẩm vẫn còn nằm trong đầu của người phát triển.

Người quản lí xây dựng tốt biết sẽ mất bao lâu để xây nhà,

20

người đó có thể tính toán kích cỡ, vật tư, và nỗ lực lao động.

Khó tính toán kích cỡ và nỗ lực của dự án phần mềm, đặc biệt

trong các pha sớm. Đó là lí do tại sao cần cách tiếp cận và

phương pháp khác để quản lí dự án phần mềm.

Tôi thường hỏi sinh viên: “Người không làm phần mềm

(như sinh viên trường kinh doanh) có thể quản lí dự án phần

mềm không?" Tôi đã viết về chủ đề này vài lần trong blog của

tôi. Tôi thường dùng nó như chủ điểm để thảo luận trong lớp

quản lí dự án phần mềm của tôi và nó bao giờ cũng tạo ra thảo

luận thú vị trong các sinh viên.

Câu hỏi của tôi với bạn: Bạn làm gì trong dự án phần

mềm của bạn? Tôi chắc rằng bạn không lập kế hoạch cho thất

bại, nhưng nếu bạn đã thất bại trước đây, có lẽ đây là lúc bạn

học thêm về quản lí dự án phần mềm hay lấy môn đào tạo

chuyên nghiệp về chủ đề này.

Quản lí dự án phần mềm-4

Viễn kiến dự án là chiều hướng của dự án. Nó là “la bàn”

hướng dẫn tổ đi tới theo cùng một hướng. Viễn kiến phải được

trao đổi cho các thành viên tổ vào lúc bắt đầu của dự án để cho

tổ cái nhìn về dự án và cách họ phải làm việc cùng nhau để đạt

tới viễn kiến đó.

Một số người quản lí dự án đưa ra viễn kiến cho tổ rồi

chuyển sang các hoạt động khác. Trong trường hợp đó, tổ có

thể mất cái nhìn về viễn kiến bởi vì họ bao giờ cũng bận rộn

với công việc riêng của họ. Người quản lí dự án giỏi sẽ không

để bất kì cái gì làm sao lãng họ khỏi viễn kiến bởi vì nếu họ trở

nên bị sao lãng, dự án có thể không thành công như được mong

đợi. Thành viên tổ làm việc tốt nhất khi họ có mọi thông tin họ

21

cần để làm nhiệm vụ của họ nhưng họ cũng cần thông tin về

cách các nhiệm vụ của họ khớp vào trong viễn kiến của dự án.

Có khả năng đặt các nhiệm vụ của họ vào trong hoàn cảnh lớn

hơn cung cấp động cơ và giúp cho các thành viên ra quyết định

tốt hơn.

Một số người quản lí không biết cách lập kế hoạch dự án

hay tạo ra viễn kiến. Họ thậm chí không biết cách dự án nên

được thực hiện thế nào cho nên họ không muốn chia sẻ kế

hoạch của họ với bất kì ai. Họ cảm thấy bất an về vị trí của họ

cho nên họ thường che giấu đằng sau“bận việc” và né tránh nói

chuyện với các thành viên tổ. Khi thành viên tổ hỏi, họ bao giờ

cũng tìm cớ rằng họ bận thế và không có thời gian. Cái cớ

thường được dùng nhất là “phải đi họp với những người quản lí

khác” cho nên việc dự họp trở thành công việc hàng ngày của

họ. Những người quản lí này không tin cậy vào tổ của họ

nhưng coi họ là "thuộc cấp" thay vì là người có khả năng làm

công việc. Khi mọi người thiếu viễn kiến hay thông tin, họ lấp

vào lỗ hổng bằng niềm tin riêng của họ và thỉnh thoảng cả tin

đồn. Tin đồn cho thông tin sai và thường tốn nhiều thời gian để

sửa nó.

Người quản lí dự án cần biết về trạng thái hay tiến bộ của

dự án để cho họ có thể báo cáo với người quản lí cao hơn.

Không có viễn kiến hay kế hoạch dự án để giám sát, nhiều

người dựa vào các cuộc họp với cá nhân nơi từng thành viên

báo cáo cho họ thay vì họp tổ. Trong trường hợp này, các thành

viên chỉ cung cấp một phần thông tin mà người quản lí cần

biết. Nhiều vấn đề quan trọng vẫn còn bị ẩn kín trong cuộc họp

trạng thái này. Chẳng hạn, thành viên tổ có thể ngần ngại thừa

nhận rằng họ có vấn đề, hay đối diện với khó khăn, hay nói về

thông tin mà người quản lí dự án cần biết. Không có bức tranh

rõ ràng về dự án, những người quản lí này không thể ra quyết

định tốt được. Thỉnh thoảng, họ không muốn báo cáo tình trạng

22

xấu cho nên họ để mọi sự xảy ra và khi nó thành tồi tệ nhất, họ

đổ lỗi cho người của họ.

Người quản lí dự án giỏi bao giờ cũng giám sát các hoạt

động để đảm bảo rằng mọi hành động được thực hiện để đạt tới

viễn kiến. Người đó thu thập và đánh giá dữ liệu theo lịch biểu

và ngân sách để nhận diện rủi ro và đáp ứng với chúng nhanh

chóng. Người đó có cuộc họp hàng tuần với tổ để chia sẻ tiến

bộ và giữ cho mọi người tập trung vào nhiệm vụ được phân

công của họ. Người đó biết rằng dự án phần mềm thường có

vấn đề; thành viên tổ bao giờ cũng đối diện với các chướng

ngại như giải quyết với thay đổi; không có đủ thời gian cho các

nhiệm vụ v.v. Do đó, người đó phải huỷ bỏ mọi sao lãng để giữ

cho tổ tập trung vào điều họ làm.

Người quản lí dự án giỏi không làm việc một mình mà

bao giờ cũng đưa tổ vào các hoạt động dự án. Lúc bắt đầu dự

án, người đó đưa tổ vào thảo luận về các mục tiêu của dự án.

Người đó đòi hỏi các thành viên tổ cho ý kiến của họ để có

được gợi ý tốt nhất. Bằng việc đưa tổ tham gia vào sớm; người

đó tạo ra ý thức về làm việc tổ, điều cho phép các thành viên

cảm thấy rằng gợi ý của họ là quan trọng. Khi các thành viên tổ

cảm thấy họ là quan trọng, họ làm việc chăm chỉ để đạt tới viễn

kiến điều đưa họ vượt qua các chướng ngại và phấn đấu vì

thành công.

Một số người quản lí dự án coi bản thân họ là "ông chủ"

và quản lí dự án là về việc ra mệnh lệnh. Đây là sai lầm. Khi họ

ra lệnh cho thành viên tổ làm cái gì đó, họ không cho người đó

cơ hội để nghĩ về cái gì cần làm và làm nó thế nào. Trong

trường hợp này, các thành viên tổ bị giới hạn làm đích xác như

người quản lí bảo họ làm. Họ sẽ phát triển thói quen chỉ chờ

đợi chỉ dẫn và trở thành phản ứng thay vì tích cực. Họ không

thể phân tích các nhiệm vụ hay học cái gì mới và đó là lí do tại

sao nhiều dự án bị trễ. Chúng bị trễ vì các thành viên tổ chờ đợi

23

người quản lí bảo họ điều phải làm và không có chỉ đạo, không

cái gì sẽ xảy ra. Người quản lí giỏi không cho mệnh lệnh mà

cho chỉ dẫn. Cho chỉ dẫn không phải là bảo ai đó điều phải làm,

mà bảo họ đích xác điều người đó muốn được làm. Trong

trường hợp này, thành viên tổ phải nghĩ về cách làm nó. Thay

vì một cách máy móc chỉ làm nhiệm vụ, thành viên tổ sẽ phải

nghĩ về qui trình, thủ tục và mọi chi tiết về cách làm nó. Trong

trường hợp này, họ phải học nghĩ và tích cực hơn trong cải tiến

kĩ năng của họ. Các thành viên tổ giỏi bao giờ cũng nghĩ khi họ

được trao chỉ dẫn. Họ bao giờ cũng nhận diện các cách khác

nhau để làm nhiệm vụ và cân nhắc cách nào là tốt hơn. Khi các

thành viên tổ đi tới giải pháp của họ, họ cảm thấy thoải mái.

Điều đó khuyến khích họ học nhiều hơn và điều đó nâng cao

lòng tin của họ vào điều họ làm. Nếu cái gì đó xảy ra cho công

việc của họ, họ sẽ tự tin bảo vệ bản thân họ. Cho chỉ dẫn là giải

pháp tốt nhất có tác dụng tốt cho hầu hết những người phát

triển phần mềm.

Mục đích của quản lí dự án phần mềm

Phần lớn các kĩ sư phần mềm đều muốn dự án của mình

thành công nhưng lại không biết cách tiến hành. Một phương

pháp tôi dạy cho họ là xác định mục đích ưu tiên ở ngay lúc bắt

đầu dự án và liên tục kiểm điểm sự tiến triển theo mục đích này

trong thời gian điều hành dự án.

Về căn bản, dự án phần mềm có ba mục đích chính:

Chuyển giao sản phẩm đúng thời gian, hoàn thành mọi chức

năng được yêu cầu, và có ít lỗi (chất lượng cao). Theo kinh

nghiệm của tôi, khó mà đáp ứng được cả ba mục đích này nên

tôi khuyên mọi người hãy lựa chọn một mục đích có ưu tiên

cao nhất để làm theo đó. Điều này sẽ giúp cho họ tập trung thay

24

vì dành quá nhiều nỗ lực vào cái gì đó mà họ không thể kiểm

soát nổi. Hoàn tất điều khách hàng coi là quan trọng nhất chính

là sự thành công cho dự án và để làm điều đó, người quản lí

phải hỏi khách hàng xem ưu tiên cao nhất là gì.

Nhiều người không đồng ý với tôi rằng họ cần phải có

một ưu tiên cao nhất nên tôi giải thích điều này trong thí dụ

đơn giản sau: Giả định rằng còn ba tuần trước ngày chuyển

giao theo lịch biểu nhưng dự án vẫn còn nhiều lỗi và chức năng

cuối cùng chưa hoàn thành. Bạn sẽ làm gì? Nếu bạn quyết định

chuyển giao phần mềm theo đúng ngày tháng quy định, bạn có

cho rằng khách hàng sẽ hài lòng với sản phẩm chưa hoàn thành

và số lỗi lầm còn nhiều không? Nếu bạn chọn chuyển giao sản

phẩm khi các chức năng được hoàn thành, bạn có cho rằng

khách hàng sẽ hài lòng khi sản phẩm bị chậm trễ mặc dầu nó

đáp ứng tất cả các chức năng? Nếu bạn quyết định kéo dài

thêm vài tuần nữa để sửa mọi lỗi lầm và chức năng vậy bạn có

cho rằng khách hàng sẽ hài lòng nếu việc chuyển giao bị chậm

trễ cho dù sản phẩm có chất lượng cao?

Mục đích chính về sự thành công của dự án phần mềm là

do sự cảm nhận của khách hàng cho nên bạn cần phải hỏi

khách hàng. Việc nói chuyện với khách hàng rất quan trọng

trong các dự án phần mềm và bạn phải hỏi họ: Có cần sửa tất

cả các lỗi lầm không, hay chỉ sửa những lỗi chủ chốt nhất trước

ngày chuyển giao? Mọi chức năng được đề nghị có cần được

hoàn thành không hay chỉ những chức năng quan trọng nhất

mới cần được thực hiện trước ngày chuyển giao? Và ngày

chuyển giao có phụ thuộc vào những chức năng đặc biệt đó

không? Khi các ưu tiên còn chưa rõ ràng, bạn phải đặt câu hỏi -

bởi vì khi ưu tiên của dự án thay đổi thì mọi sự đều thay đổi.

Chìa khoá thành công của dự án là nhận ra mục đích nào có ưu

tiên cao nhất theo quan điểm của khách hàng.

25

Phần lớn các giáo sư đại học chỉ dạy sinh viên rằng nhân

tố thành công là chất lượng cao và tập trung vào việc dạy nhiều

về kiểm thử. Mặc dầu chất lượng quan trọng nhưng tôi nghĩ

thành công dự án chỉ dựa vào chất lượng mà thôi là không

đúng. Ngày nay chúng ta đang sống trong một thị trường cạnh

tranh cao độ, đôi khi có sản phẩn trên thị trường trước nhất lại

là ưu thế chiến lược (Chẳng hạn Microsoft chọn chiến lược này

bởi vì khi họ đưa sản phẩm mới vào thị trường, họ muốn chiếm

toàn bộ thị trường để không ai có thể tạo ra sản phẩm tương tự

hay cạnh tranh với họ, mặc dầu sản phẩm vẫn còn nhiều lỗi lầm

nhưng họ sửa sau).

Trong nền kinh tế thị trường, khách hàng sẽ mua sản

phẩm đầu tiên có trên thị trường bởi vì họ muốn sử dụng công

nghệ mới nhất. Chừng nào mà sản phẩm làm được cái gì đó tốt,

họ sẽ hài lòng. Chừng nào mà khiếm khuyết chưa đến nỗi nào

thì họ vẫn có thể chấp nhận được.

Kết luận của tôi về sự thành công của dự án phần mềm là

khả năng biết hỏi khách hàng mục đích nào là ưu tiên cao nhất

rồi làm kế hoạch để đạt tới nó.

Phương pháp quản lí dự án mới

Có nhiều nghiên cứu chỉ ra rằng phần lớn các dự án phần

mềm thất bại KHÔNG phải bởi vì vấn đề công nghệ mà bởi

vấn đề quản lí. Điều không may, giải pháp điển hình là thay thế

người quản lí dự án này bằng người quản lí khác và hi vọng

rằng mọi sự sẽ tốt hơn. Cách nhìn chung là ở chỗ người quản lí

chịu trách nhiệm cho mọi thứ. Nếu người quản lí mới được cần

tới, công ti sẽ đặt họ vào chỗ đó nhưng nhiều dự án vẫn hỏng

gợi ý rằng KHÔNG người quản lí nào biết phải làm gì hay

nguyên nhân có thể là cái gì đó khác.

26

Cho dù người phát triển phần mềm và công việc của họ

là khác với công nhân lao động và công việc chế tạo của họ,

phương pháp quản lí truyền thống ngày nay vẫn dựa trên các

nguyên lí từ công việc trong ngành xây dựng được Frederick

Taylor phát minh thế kỉ thứ 19. Phương pháp của Taylor đã

được thiết kế cho các công nhân không có giáo dục, phần lớn là

những người lao động xây dựng xưởng máy, nhà cửa hay làm

việc trong dây chuyền lắp ráp chế tạo. Phương pháp này tương

đối đơn giản nơi người quản lí ra lệnh và công nhân tuân theo

mệnh lệnh làm các nhiệm vụ thủ công của họ. Loại công việc

lao động này và công việc phần mềm ngày nay là rất khác

nhau, nhưng hầu hết các đại học vẫn dạy các nguyên tắc chỉ

huy và kiểm soát của Taylor. Đó là lí do tại sao những người

quản lí không có hiệu quả trong kiểm soát chi phí, lịch biểu,

chất lượng dự án và dự án bị thất bại.

Vấn đề là ở chỗ với đào tạo hiện tại, người quản lí phần

mềm KHÔNG biết người phát triển đang làm gì và làm sao thu

được trạng thái dự án cho nên họ nói chung bị trách vì những

lỗi lầm khi vấn đề thực là với phương pháp quản lí hay đào tạo

người quản lí chứ KHÔNG phải là người quản lí. Câu trả lời

thực KHÔNG phải là thay thế người quản lí, mà THAY

phương pháp quản lí. Tuy nhiên, người quản lí dự án không

biết thay đổi cái gì và ngần ngại thay đổi phương pháp mới

KHÔNG được dạy trong trường.

Vấn đề chính với phương pháp quản lí hiện thời là ở chỗ

những người phát triển và người quản lí có các cách nhìn khác

nhau về thành công. Nghiên cứu của Carnegie Mellon thấy

rằng những người phát triển coi dự án là thành công nếu công

việc có tính thách thức kĩ thuật để họ tiếp tục "hoàn thiện nó"

dù dự án có đáp ứng các mục tiêu chi phí hay lịch biểu không.

Người quản lí coi dự án là thành công nếu họ đáp ứng các mục

đích chi phí và lịch biểu mà không xem xét tới bản chất công

việc kĩ thuật. Sự khác biệt này trong cách nhìn đã có tác động

27

sâu sắc lên việc quản lí dự án. Chẳng hạn, khi người quản lí dự

án yêu cầu các thành viên tổ để mắt tới nhiệm vụ hay cột mốc.

Các thành viên tổ bao giờ cũng cho câu trả lời mơ hồ như “Tôi

làm gần xong nhưng chưa xong” hay “Việc đã gần xong rồi,

hoàn thành quãng 90%.” Khi công nhân tri thức biết điều đã

xảy ra, họ thà tập trung vào "hoàn thiện mã" hay "cải tiến thiết

kế" hơn là giữ lịch biểu bởi vì đó KHÔNG phải là vấn đề của

họ. Đến lúc người quản lí dự án thấy ra rằng dự án bị chậm thì

đã khó sửa rồi. Lịch biểu trượt điển hình xảy ra trước rồi đến

chi phí quá mức và cuối cùng là vấn đề chất lượng vì người

phát triển xô vào sửa lỗi và đưa thêm vào nhiều lỗi hơn. Cuối

cùng, người quản lí cấp cao không còn chọn lựa nào ngoài việc

cắt bỏ dự án hay tìm ai đó để thay thế người quản lí dự án.

Trong nghiên cứu của tôi ở Carnegie Mellon, tôi đã phỏng vấn

hàng trăm người quản lí dự án và họ tất cả đều bảo tôi rằng họ

KHÔNG biết phải làm gì ngoài tập trung vào sửa chữa vấn đề

nhiều nhất có thể được rồi đợi ai đó khác cắt bỏ dự án và đổ lỗi

cho khó khăn kĩ thuật chứ không về bản thân họ.

Dự án phần mềm khó quản lí nhưng lí do chẳng liên quan

gì tới công nghệ cả. Đó thực tế là công việc tri thức có bao hàm

công nhân tri thức và quản lí công nhân tri thức, bạn sẽ cần

người quản lí tri thức và một kiểu phương pháp quản lí khác.

Trong xem xét cách quản lí công việc tri thức, vài năm trước,

tác giả Peter Drucker đã kết luận rằng người quản lí không thể

quản lí thực sự công việc tri thức được, người công nhân tri

thức phải quản lí bản thân họ. Để làm điều đó, công nhân tri

thức phải được đào tạo trong các vai trò, trách nhiệm và thẩm

quyền đặc biệt và họ phải được đảm nhiệm để tạo ra kế hoạch

riêng của họ, thương lượng cam kết riêng của họ, và đáp ứng

những cam kết này bằng sản phẩm chất lượng. Công việc của

người quản lí KHÔNG còn là chỉ huy và kiểm soát tổ làm việc

tri thức mà là LÃNH ĐẠO, ĐỘNG VIÊN, HỖ TRỢ và HUẤN

LUYỆN họ.

28

Trong thực hành công nghiệp hiện thời, tổ phần mềm bao

giờ cũng làm việc theo cách này. Thay vì vật lộn để đáp ứng

lịch biểu không hợp lí, họ bây giờ có thể thương lượng lịch

biểu riêng của mình với cấp quản lí. Tổ sẽ chịu trách nhiệm về

công việc của họ, họ biết tình trạng dự án, và họ thu thập dữ

liệu để bảo vệ ước lượng của mình. Khi họ thấy có vấn đề, họ

giải quyết chúng trong các cuộc họp tổ giữa các thành viên tổ

và nếu họ không thể giải quyết được thì họ sẽ nhờ sự giúp đỡ

của cấp quản lí. Ngày nay, nhiều công ti đã dùng nguyên tắc

này trong dự án hệ thông tin của họ và kết quả rất có ý nghĩa.

Không may là nhiều đại học không chấp thuận điều đó. Lí do

đơn giản, nhiều giáo sư KHÔNG có kinh nghiệm làm việc thực

tế để dạy loại kĩ thuật này.

Chìa khoá của kĩ thuật này là các vai trò, trách nhiệm và

thẩm quyền được xác định rõ lúc bắt đầu dự án. Cấu trúc dự án

phải được thiết lập tương ứng với nơi có Ban quyết định, bao

gồm vài người quản lí cấp cao để ra quyết định về dự án kể cả

ngân sách, lịch biểu toàn thể và bất kì quyết định nào ảnh

hưởng tới kết quả của dự án, cũng như cung cấp tài nguyên cần

thiết để tiến hành dự án. Vai trò của người quản lí dự án là

hướng dẫn, huấn luyện, khuyến khích và động viên tổ đạt tới

mục tiêu xác định: hoàn thành thành công dự án. Người đó chịu

trách nhiệm về lập kế hoạch tổng thể, tổ chức, thực hiện dự án

bằng cách làm việc trong CỘNG TÁC với các thành viên tổ để

tạo ra môi trường làm việc năng suất để đảm bảo rằng dự án

được chuyển giao đúng thời gian, trong ngân sách, và với chất

lượng được yêu cầu. Người quản lí doanh nghiệp đại diện cho

khách hàng và nhóm người dùng và chịu trách nhiệm xác định

yêu cầu dự án và mọi thay đổi cần thiết. Trong cộng tác với

người quản lí dự án, người quản lí doanh nghiệp tham gia vào

lập kế hoạch và giám sát các nhiệm vụ khác nhau cần sự tham

gia của người đó, như hiểu và tạo ra yêu cầu, cũng như kiểm

nghiệm và chấp thuận sản phẩm của tổ dự án. Người kiến trúc

29

hệ thống là một chuyên gia thiết kế và thiết lập kiến trúc cho

dự án. Người đó chịu trách nhiệm duy trì phạm vi của dự án

tuân thủ với các yêu cầu đã được thiết lập. Tổ dự án bao gồm

người quản lí dự án, người quản lí doanh nghiệp, kiến trúc sư

hệ thống và mọi thành viên được phân công cho dự án. Tổ dự

án chịu trách nhiệm về kết quả của dự án, tức là sản phẩm hay

dịch vụ được chuyển giao. Thành viên tổ là một cá nhân tham

gia vào trong dự án và là một phần của tổ bên trong cấu trúc

của dự án. Thành viên tổ có nhiệm vụ hay vai trò được phân

công cho người đó và đảm nhiệm hoàn thành việc phân công

đó. Hơn nữa, các thành viên tổ phải đo, theo dõi, và báo cáo về

việc làm của họ. Trong kiểu cấu trúc tổ chức này, toàn thể tổ

dự án có thể tham gia tích cực để làm cho dự án thành công.

Khi tổ tri thức có quản lí, đào tạo và hỗ trợ thích hợp, họ

có thể làm việc tốt và nhất quán đáp ứng các cam kết chi phí và

lịch biểu của họ bằng sản phẩm chất lượng cao. Theo Peter

Drucker các nguyên tắc quản lí cho công việc tri thức là khác

với các nguyên tắc cho kĩ nghệ truyền thống. Các nguyên tắc

này là:

1. Tin cậy công nhân tri thức. Cấp quản lí phải tin cậy vào

công nhân tri thức và tổ tự quản lí họ.

2. Đào tạo tổ đáng tin cậy. Tổ làm việc tri thức phải được

đào tạo để cho họ sẵn lòng và có khả năng tự quản.

3. Dựa vào sự kiện và dữ liệu. Hệ thống quản lí phải dựa

vào sự kiện và dữ liệu để ra quyết định thay vì quyền

lực và địa vị.

4. Chất lượng quản lí. Chất lượng phải là ưu tiên cao nhất

của tổ chức.

Khi công nhân tri thức đã được đào tạo và biết cách tự

quản mình, họ có kế hoạch chi tiết cho công việc của mình và

biết trạng thái của mình một cách chính xác. Họ cũng cảm thấy

30

có trách nhiệm quản lí các vấn đề riêng của mình và khi cần

giúp đỡ, họ có thể yêu cầu tổ hay người quản lí của họ. Tất

nhiên, không phương pháp nào có thể xoá bỏ được vấn đề

nhưng với kiểm điểm đủ, những hành động phòng ngừa nào đó

có thể được thực hiện sớm cho nên vấn đề có thể được tránh

hay được giải quyết nhanh chóng. Nguyên tắc then chốt của

phương pháp này là chia công việc dự án thành nhiều nhiệm vụ

nhỏ cho dễ quản lí. Thay vì dựa vào các cột mốc mà có thể

cách nhau vài tháng, dự án nên được chia thành các bản đưa ra

tăng dần nhỏ hơn, mỗi bản đưa ra với chuyển giao nào đó và

trong thời hạn ngắn, có thể một tuần hay hai tuần. Theo

phương pháp này, các nhiệm vụ chi tiết, cách đo chính xác, và

quyền làm chủ là cốt yếu để cho công nhân tri thức có thể tự

quản mình tương ứng theo vai trò, trách nhiệm và thẩm quyền

của họ.

Để bắt đầu, chúng ta cần đào tạo người phát triển cách tự

quản bản thân mình dựa trên các nguyên tắc và phương pháp

mới. Nhiều vấn đề có thể được tránh nếu người phát triển biết

phải làm gì, làm thế nào và khi nào làm nó. Với các dự án phần

mềm, qui trình được xác định tốt là điều bản chất. Quản lí dự

án phải được chia thành vấn đề chi tiết, và mọi bước đều phải

được thực hiện tương ứng và đúng đắn. Như tôi làm việc trong

doanh nghiệp hàng không, tôi biết rằng trước mỗi chuyến bay,

phi công bao giờ cũng kiểm tra chuẩn bị bay bằng việc tuân

theo danh sách kiểm chi tiết. Điều đó có thể được áp dụng cho

dự án phần mềm nơi những người phát triển phải xây dựng

danh sách kiểm riêng của họ và tuân theo chúng tương ứng để

cho họ biết mọi bước họ phải làm. Khi họ làm điều đó nhiều

lần, họ có thể tiếp tục cải tiến danh sách kiểm riêng của mình.

Loại tự kiểm này thực tế là điều công nhân tri thức biết cách tự

quản mình và đảm bảo rằng mọi bước đều được thực hiện

đúng.

31

Hơn bao giờ hết, tôi mạnh mẽ tin rằng chúng ta cần cung

cấp loại phương pháp này trong mọi phát triển hệ thông tin và

phần mềm. Thất bại của các dự án phát triển tốn nhiều thời

gian và tiền bạc, nó cũng tạo ra vấn đề chất lượng lớn cho

ngành công nghiệp. Trong thế giới cạnh tranh cao này của toàn

cầu hoá, không nước nào có thể đảm đương được với kiểu thất

bại dự án này. Bằng việc làm chậm đào tạo hay từ chối chấp

nhận các thực hành tốt nhất trong đào tạo đại học sẽ làm hại về

mặt kĩ thuật cho các sinh viên có năng lực và làm hỏng việc

phát triển công nhân tri thức, người là nhân tố then chốt trong

việc tăng trưởng nền kinh tế và thịnh vượng quốc gia.

Thành công của dự án phần mềm

Ba nhân tố mấu chốt quan trọng có thể xác định sự thành

công của dự án phần mềm: Con người, Qui trình và Công cụ.

Dự án phần mềm cần các qui trình để hoàn thành công

việc phát triển và cần công cụ để hỗ trợ cho những qui trình

này nhưng chính con người thực hiện công việc bằng cách tuân

theo các qui trình này và dùng các công cụ này. Do đó, con

người chịu trách nhiệm cho thành công hay thất bại của dự án.

Là người quản lí dự án, bạn phải luôn lưu tâm tới nhân tố

con người. Phần lớn các vấn đề trong dự án phần mềm là vấn

đề con người chứ không phải là vấn đề kĩ thuật. Trong 40 năm

quản lí dự án phần mềm của mình, tôi chưa bao giờ thấy dự án

thất bại bởi vì các kĩ sư không thể lập trình hay thiết kế, họ tất

cả đều được huấn luyện làm điều đó, nhưng bị thất bại bởi vì

ước lượng sai, thay đổi trong yêu cầu, hay không có lịch biểu

được lập tốt.

32

Tôi tin vai trò của người quản lí dự án KHÔNG phải là

làm cho mọi người làm việc mà TẠO KHẢ NĂNG cho mọi

người làm việc. Người quản lí tốt sẽ thuê người đúng; làm cho

họ thoả mãn nên họ không muốn ra đi, và hỗ trợ họ trong việc

tạo ra môi trường làm việc ưa thích để cho họ có thể làm hết

sức mình. Khi một nhóm người chia sẻ cùng một mục đích và

hình thành nên tổ có động cơ cao, toàn thể môi trường làm việc

sẽ thay đổi. Trong một tổ, tương tác là mọi điều và đó là lí do

tại sao mọi người thích làm việc với nhau, hỗ trợ nhau, và gắn

mọi nỗ lực vào công việc để vượt qua chướng ngại.

Hành vi của một người được xác định bởi niềm tin và giá

trị. Niềm tin được hình thành từ kinh nghiệm có trước và thông

tin nhận được. Giá trị là điều từng cá nhân coi là quan trọng.

Niềm tin được tổ hợp với các giá trị dẫn lái hành động của từng

cá nhân. Chẳng hạn, người kĩ sư có thể không thích kiểm điểm

mã chương trình bởi vì người đó có thể bị đánh giá xấu trong

con mắt bạn bè vì việc kiểm điểm có thể làm lộ ra nhiều lỗi của

anh ta. Có lẽ vài năm trước, anh ta có thể đã có kinh nghiệm

xấu trong kiểm điểm mã.

Để ảnh hưởng tới hành vi của một cá nhân, người quản lí

tốt phải hiểu các giá trị và niềm tin gây ra hành vi của người ta

và rồi nếu cần, giúp đỡ sửa chữa lại các niềm tin dựa trên thông

tin sai. Người quản lí tốt phải giúp cho mọi người hiểu các ưu

tiên bằng việc thiết lập mục đích dự án và trao đổi chúng một

cách rõ ràng cho tổ dự án.

Theo kinh nghiệm của tôi, các mục đích đơn giản và

được viết rõ ra có nhiều khả năng thu được thành tựu. Người

quản lí phải để cho tổ dự án biết điều mình muốn từ họ, cách

mình đo nó, và vào lúc nào. Điều quan trọng là các mục đích là

đạt được, điều đó có nghĩa là chúng ở trong phạm vi kiểm soát

của tổ, bằng không họ coi các mục đích là không thể được và

chẳng làm gì về nó cả. Phải có một cách thức khách quan để

33

kiểm chứng việc đạt được mục đích. Bằng không tổ sẽ không

có cách nào biết được nó thực tế đã đạt tới chúng hay chưa.

Tôi đã thấy nhiều người phạm phải sai lầm bằng việc đặt

mục đích được phát biểu trong thời tương lai và để cho mọi

người nghĩ họ đang suy nghĩ ước muốn. Chẳng hạn, với mục

đích "tôi sẽ làm việc nhiều hơn," tôi có thể coi mục đích này

được đạt tới cho dù không tiến hành hành động nào, bởi vì tôi

có thể ngồi trong ghế tự bảo mình rằng "tôi sẽ làm việc nhiều

hơn." Lưu ý rằng bởi vì thời tương lai, phát biểu này là đúng

bởi vì nó không xảy ra hôm nay.

Tuy nhiên, nếu mục đích là "Do yêu cầu của khách hàng

và vấn đề nghiệp vụ, mọi người phải làm việc 10 giờ một ngày,

ba lần một tuần cho tới khi dự án được thực hiện xong " thế thì

mọi người không thể bỏ qua nó được và cố gắng làm cho nó

đúng. Mục đích cũng cần có ngày tháng để có hiệu lực.

Ví dụ:

Giảm lỗi chương trình 20% trước 1/07/ 2008.

Tăng việc lập kế hoạch chính xác thêm 10% khi so với

dữ liệu năm ngoái vào tháng 7/2007.

Tăng năng suất lập trình (số dòng mã lệnh trên 40 giờ)

lên 10% mỗi năm từ bây giờ trở đi.

Hãy chắc chắn giữ cân bằng giữa con người, qui trình và

công cụ. Nếu bạn không thể giúp được cho mọi người làm việc

như một tổ và làm hết sức họ thì bạn sẽ không thành công và

dự án của bạn sẽ thất bại.

34

Dự án phần mềm thành công

Một sinh viên hỏi tôi: Làm sao thầy biết liệu dự án phần

mềm là thành công hay không? Nếu phần mềm chạy tốt, nó có

là thành công không? Nếu mã qua được mọi kiểm thử nó có là

thành công không?

Đáp: Dự án phần mềm thành công nếu nó được chuyển

giao cho khách hàng đúng thời gian, trong chi phí, có mọi chức

năng được khách hàng yêu cầu, có lỗi thấp, và nó cung cấp giá

trị cho khách hàng. Thời gian và chi phí có liên quan với nhau.

Thời gian tổ dành cho dự án cũng là phần lớn của chi phí. Phần

khác là chi phí lao động và nếu dự án cần nhiều người hơn nó

đã được lập kế hoạch điều đó sẽ tốn chi phí nhiều hơn. Nếu dự

án chậm (cần nhiều thời gian hơn) nó sẽ tốn phí nhiều hơn. Tất

nhiên hoặc khách hàng sẽ phải trả nhiều hơn hoặc công ti sẽ

phải chi thêm tiền phụ thêm.

Phần mềm phải có mọi chức năng mà khách hàng yêu

cầu trong đặc tả yêu cầu phần mềm (SRS) và hơn nữa bởi vì có

nhiều "chức năng suy dẫn" mà tổ sẽ thêm vào cho các chức

năng được yêu cầu để làm cho sản phẩm cuối cùng làm việc tốt

hơn. Tất nhiên, có thể tốn phí nhiều hơn khi tổ phải chi thêm

thời gian phụ cho chúng. Không phần mềm nào "không lỗi"

nhưng có khác biệt rõ ràng giữa phần mềm làm việc được, với

ít lỗi có thể được sửa và phần mềm có nhiều lỗi phải mất nhiều

thời gian và nỗ lực hơn và có thể vô dụng. Ngay cả phần mềm

được chuyển giao "đúng thời gian, trong chi phí" thực tế không

được kết thúc khi nó được chuyển giao cho khách hàng và

chính khách hàng sẽ phải tìm ra chức năng bị thiếu và gửi nó

trả lại để sửa.

Vấn đề mấu chốt là: Khách hàng có dùng nó không? Nó

tạo ra bao nhiêu giá trị trong kinh doanh của khách hàng? Nó

giúp cho khách hàng giải quyết vấn đề được bao nhiêu? Nhiều

35

người phần mềm KHÔNG quan tâm về vấn đề giá trị bởi vì

điều này không được làm tài liệu trong SRS cho nên nó "không

phải là vấn đề của chúng ta". Tổ phần mềm tạo ra nó, và nó

làm việc, cho nên nếu họ không dùng nó, thế thì đó là vấn đề

của họ, không phải của chúng ta. Đây KHÔNG phải là cách tốt

để đạt tới sự hài lòng của khách hàng bởi vì tổ phần mềm cần

hiểu tại sao phần mềm không được dùng? Có thể nó quá khó

dùng không được? Vậy đó là vấn đề về tính dùng được. Có lẽ

cách khách hàng làm tài liệu yêu cầu là KHÔNG tốt cho nên

phần mềm không thể giải quyết được vấn đề. Vậy thì đó là vấn

đề khêu gợi yêu cầu làm kém. Dù bất kì lí do nào, nếu phần

mềm KHÔNG được dùng, nó không có giá trị và nếu bạn là

người phát triển phần mềm chuyên nghiệp, bạn sẽ thấy lí do và

đề nghị giải pháp để chắc chắn rằng khách hàng sẽ thoả mãn

toàn bộ. Nếu khách hàng hài lòng, thử đoán xem họ sẽ trao dự

án tiếp cho ai?

Vấn đề với dự án phần mềm

Theo nghiên cứu mới nhất về công nghiệp phần mềm Mĩ,

nhiều dự án phần mềm vẫn thất bại với tỉ lệ cao mặc cho nhiều

nỗ lực cải tiến. Nghiên cứu này thấy nhiều lí do cho thất bại

phần mềm, sau đây là năm lí do hàng đầu mà nghiên cứu này

nhận diện ra:

Đa số người phát triển phần mềm không tính tới thời gian

hiểu nhu cầu khách hàng. Họ không được đào tạo để trắc

nghiệm các yêu cầu với khách hàng mà vội vàng qua ngay pha

lập kế hoạch và thiết kế để sang viết mã. Thái độ “Mã trước, và

hỏi câu hỏi sau" là nguyên nhân số một cho nhiều thất bại dự

án. Cuối cùng, khi phần mềm được đưa ra, người phát triển

mới thấy ra là điều họ làm không phải là điều khách hàng

36

muốn và họ phải sửa lại nó và điều đó tốn nhiều thời gian và

tiền bạc.

Đa số những người quản lí dự án không có kĩ năng để

ước lượng tài nguyên, thời gian, kích cỡ và phạm vi dự án.

Phần lớn những người quản lí hoặc ước lượng thấp nỗ lực hoặc

ước lượng tất nhưng lại đặt kế hoạch theo lịch biểu được khách

hàng trao cho họ. Họ quản lí dự án theo lịch biểu không hiện

thực và làm cho dự án bị chậm. Bởi vì sức ép lịch biểu, nhiều

người quản lí yêu cầu người phát triển bỏ qua kiểm thử để đáp

ứng lịch cho nên sản phẩm phần mềm cuối cùng đầy lỗi, điều

này làm cho công ti tốn kém nhiều tiền bạc và thời gian hơn để

sửa chữa.

Đa số các thành viên tổ dự án không được đào tạo trong

qui trình hay phương pháp phần mềm, họ không biết cách kiểm

soát thay đổi với phần mềm, mất kiểm soát phiên bản phần

mềm tạo ra các vấn đề lớn về tích hợp và kiểm thử, điều đến

lượt lại tạo ra sản phẩm chất lượng thấp và chi phí nhiều hơn

để sửa chữa.

Khi dự án bị trục trặc, người quản lí quyết định thêm

người để “tăng tốc mọi sự” để đáp ứng thời gian theo lịch biểu.

Điều này tạo ra thêm vấn đề, lẫn lộn, và gây ra sản phẩm chất

lượng kém, điều gây chậm trễ và cuối cùng tốn kém nhiều hơn.

Nhiều giờ làm việc lâu tạo ra căng thẳng lớn cho thành

viên tổ phần mềm. Nhiều người trong số họ bỏ qua vài bước

trong qui trình phát triển như kiểm thử, kiểm điểm để đáp ứng

lịch biểu, điều gây ra sản phẩm lỗi cao. Trong tình huống bị

căng thẳng, các thành viên tổ sẽ tranh cãi lẫn nhau, oán trách

nhau, và thế rồi giữ thông tin cho riêng mình thay vì chia sẻ.

Thiếu thông tin tạo ra lẫn lộn, dư thừa, lỗi, điều lại gây ra nhiều

vấn đề cá nhân cho dự án phần mềm. Bởi vì thất vọng, nhiều

người rời bỏ công ti làm cho việc đổi người cao, điều là bổ

sung thêm vấn đề cho dự án phần mềm.

37

Nghiên cứu này kết luận rằng tất cả các vấn đề trên đều

được gây ra bởi việc đào tạo phần mềm kém ở nhà trường. Sau

khi kiểm điểm lại giáo trình của nhiều đại học, tổ nghiên cứu

lưu ý rằng đa số sinh viên không được dạy về kỉ luật kĩ nghệ

phần mềm bản chất như kĩ nghệ yêu cầu, quản lí dự án, lập kế

hoạch dự án, phương pháp và qui trình phần mềm, và làm việc

theo tổ. Đào tạo hàn lâm hiện thời tập trung phần lớn vào ngôn

ngữ lập trình, điều chỉ là một phần nhỏ của qui trình phát triển

phần mềm. Trong nhiều năm, công nghiệp phần mềm đã phàn

nàn về thiếu đào tạo môn này trong đại học nhưng vấn đề vẫn

còn chưa được giải quyết. Sự kiện là đào tạo các môn kĩ nghệ

phần mềm yêu cầu kinh nghiệm công nghiệp nào đó mà nhiều

giáo sư hàn lâm không có cho nên họ bỏ qua nó. Sự kiện khác

là lĩnh vực phần mềm đã thay đổi nhanh thế và thật khó cho

các giáo sư theo kịp với những thay đổi này. Nhiều đại học

không muốn mạo hiểm danh tiếng của mình bằng việc chấp

thuận cái gì đó mới mà họ không cảm thấy thoải mái. Để đổi từ

khoa học máy tính sang kĩ nghệ phần mềm yêu cầu thay đổi

sâu sắc về lập kế hoạch phương pháp dạy và các bài học, điều

đại học không thể đảm đương được. Như với bất kì thay đổi

nào, dù xứng đáng đến đâu, bao giờ cũng bị chống lại.

Ngày nay, phần lớn các dự án phần mềm đều lớn và phức

tạp. Sản phẩm phần mềm hiếm khi có thể được phát triển bằng

tổ vài người. Các phương pháp hiện thời yêu cầu tổ phát triển

được tổ chức theo cách sử dụng hiệu quả kĩ năng của mọi

người. Có một số vai trò, trách nhiệm cho các thành viên tổ và

họ phải được tổ chức tương ứng với tri thức, kĩ năng và kinh

nghiêm như người quản lí dự án, người phân tích nghiệp vụ,

chuyên viên mạng, người kiểm thử, người phát triển, đảm bảo

chất lượng, chuyên gia cấu hình v.v. Trong dự án lớn, trao đổi

là mấu chốt cho nên khách hàng, người dùng, thành viên tổ

phải làm việc cùng nhau và trao đổi với nhau trên cơ sở thường

xuyên. Tuy nhiên làm việc tổ lại không được dạy trong các

38

chương trình hàn lâm truyền thống và trong các trường hàn lâm

truyền thống, bất kì cộng tác nào giữa các sinh viên đều bị coi

là "gian lận" cho nên nhiều sinh viên vẫn gặp khó khăn trong

làm việc cùng nhau.

Toàn cầu hoá bắt đầu làm thay đổi điều đó, khi các công

ti có thể thuê người từ bất kì đâu và không nhất thiết phải thuê

người trong biên giới nước họ. Với sự thiếu hụt người làm

phần mềm trong ngành công nghiệp đang bành trướng nhanh

này, nhiều công ti toàn cầu bắt đầu thuê người làm phần mềm

và đưa họ vào công việc ở nước họ hay mở các tiện nghi ở

nước cung cấp dư thừa về công nhân phần mềm. Mỗi năm, Mĩ

phải đưa vào trên 80,000 công nhân phần mềm, phần lớn từ Ấn

Độ qua chương trình thị thực đặc biệt H1B. Nhiều nước châu

Âu đang làm cùng điều đó với các công nhân có đủ tư cách từ

Nga, và Đông Âu. Tuy nhiên, vấn đề nền tảng vẫn còn là liệu

những người làm phần mềm này có tri thức và kĩ năng đúng

không?

Cuộc khủng hoảng tài chính bắt đầu làm thay đổi rằng,

khi công ti chậm thuê người do ngân sách bị hạn chế, họ có

nhiều thời gian để lựa người có kĩ năng đúng và đào tạo đúng.

Thay vì thuê người có bằng cấp ở đại học, nhiều công ti đang

áp dụng kĩ thuật phỏng vấn theo kịch bản để nhận diện công

nhân có tri thức và kĩ năng đúng. Thay vì đi sang bất kì nước

nào, họ nhận diện các nước có chương trình đào tạo tốt, đặc

biệt chương trình đào tạo đang hiện hành cùng nhu cầu của họ.

Theo nhiều người quản lí phần mềm, cuộc khủng hoảng tài

chính này là việc chạy không ổn trong thời hạn ngắn nhưng

việc lấy nhân viên là đầu tư dài hạn cho nên các công ti phải

lập kế hoạch cho tương lai bằng việc nhận diện công nhân tri

thức, người có khả năng tạo ra nhiều cơ hội hơn, nhiều sản

phẩm tốt hơn cho doanh nghiệp của họ.

39

Vấn đề với dự án phần mềm lớn

Khi nhiều dự án phần mềm đang ngày càng lớn hơn và

phức tạp hơn, kĩ năng và kinh nghiệm của người quản lí càng

trở nên quan trọng hơn. Bên cạnh các công ti lớn, nhiều dự án

của chính phủ cũng trở nên lớn hơn với hàng triệu dòng mã và

trị giá từ hàng chục tới hàng trăm triệu đô la. Các loại dự án

này sẽ có tác động khổng lồ lên tổ chức và các cơ quan chính

phủ, do đó về bản chất chúng yêu cầu người quản lí dự án phải

có kinh nghiệm nhiều trong làm việc với các dự án lớn tương

tự. Hơn nữa, chúng phải kiểm tra cả tính đáng tin và chất lượng

của người quản lí một cách chặt chẽ. Người quản lí dự án phải

có chứng chỉ chuyên nghiệp và phải làm việc trong lĩnh vực

phần mềm trong một thời gian nào đó.

Vì nhiều dự án lớn thường xô vào đáp ứng hạn chót thời

gian cố định, việc đáp ứng các mục tiêu mấu chốt quan trọng

hay khi ngân sách sẵn có rất nhiều phải phải chi tiêu, tổ chức

thường bỏ qua quá trình tiến hoá rồi chấm dứt với những vấn

đề chính về phí tiền bạc, thời gian và ít đạt tới giá trị. Một trong

những cớ cho việc thiếu kinh nghiệm của người quản lí dự án

là ở chỗ những người quản lí dự án cũ không hiểu công nghệ

mới hay phương pháp mới. Câu hỏi của tôi là: Tại sao tổ chức

muốn làm việc trên những dự án rất lớn dùng các công nghệ và

phương pháp mới mà chỉ vài người mới thực sự hiểu được?

Khi tôi kiểm điểm qua hàng trăm dự án lớn thất bại, nhiều dự

án trong số đó là ở trong các cơ quan chính phủ Mĩ, tôi thấy

rằng các dự án thất bại thường bị quản lí bởi những người

không có kinh nghiệm về quản lí các dự án lớn với công nghệ

và phương pháp mới mà họ chưa bao giờ dùng trước đây.

Nhiều dự án hội tụ vào phần cứng nhiều hơn, đặc biệt công

nghệ phần cứng mới nhất nhưng ít chú ý tới phần mềm. Đến

cuối họ đem về tất cả những phần cứng tốt nhất nhưng không

có phần mềm để chạy. Vì phải mất thời gian nhiều hơn để xây

40

dựng phần mềm, thường vài năm do đó nhiều phần cứng cuối

cùng trở nên lạc hậu và mục tiêu không đạt được. Với người

quản lí dự án không có kinh nghiệm, phần cứng dễ hiểu còn

phần mềm khó hơn, cho nên họ bao giờ cũng bắt đầu dự án với

phần cứng, đặc biệt khi có ngân sách cho nên họ bắt đầu bằng

công nghệ tốt nhất mà họ có thể gây ấn tượng cho ông chủ của

mình và phạm cùng sai lầm như người khác đã phạm phải.

Nhiều nghiên cứu về thất bại dự án phần mềm lớn đã thấy rằng

87% các dự án thất bại vì phần mềm chứ KHÔNG vì phần

cứng trừ vài tổ chức đang chú ý tới phần mềm và kinh nghiệm

của người quản lí dự án phần mềm.

Tôi tin rằng chìa khoá cho thành công của bất kì dự án

nào, đặc biệt dự án lớn, là có người đúng với kĩ năng đúng

trong việc đúng. Là người quản lí một công ti lớn, khi thuê

người quản lí các dự án lớn, tôi thường hỏi những câu hỏi sau:

“Có thành viên tổ dự án nào đã xây dựng cái gì lớn thế này

không?” “Có thành viên tổ dự án nào dùng phương pháp hay

công nghệ này trên dự án lớn thế này không?” “Có thành viên

tổ dự án nào đã tham gia vào thất bại của dự án lớn không?"

“Thành viên tổ có các kĩ năng về lập kế hoạch, kiến trúc, yêu

cầu và thiết kế không?” "Có ai đã nghĩ về kế hoạch dự phòng

trong trường hợp thất bại không?”

Tôi tin để biết liệu tổ dự án có đủ kinh nghiệm để đảm

bảo làm việc trong dự án lớn, tổ chức phải hỏi các câu hỏi này

với mọi vị trí chính trong dự án. Họ phải kiểm về các chi tiết

chất lượng, kinh nghiệm để đảm bảo rằng tổ có thể giải quyết

dự án vì họ đang trao cho những người này cái gì đó rất quan

trọng để thực hiện. Tổ chức phải yêu cầu mô tả từ từng thành

viên tổ về điều người đó làm khi mọi sự đi sai hay ưu tiên bị

thay đổi. Việc hỏi này nên kiểm lại cách thành viên có thể phân

bổ nhiệm vụ và phân bố khối lượng công việc. Mọi ứng cử

viên nên được hỏi về kinh nghiệm của người đó với các dự án

lớn. Làm sao dự án lớn có ứng cử viên làm việc trên đó? Dự án

41

lớn yêu cầu các kĩ năng xác định về lập kế hoạch, lập lịch biểu,

kiến trúc, thiết kế và giám sát. Những người quản lí dự án

thành công nên biết rằng có sức ép khổng lồ để làm mọi thứ

trong một lịch biểu cố định, để đáp ứng các mục tiêu then chốt,

và đạt tới thành công đặc biệt nếu dự án sẽ kéo dài vài năm.

Có việc đào tạo quản lí dự án nhưng phần lớn không

chuẩn bị cho người quản lí dự án về dự án lớn với những vấn

đề duy nhất của nó. Dự án lớn yêu cầu đào tạo đặc biệt với kịch

bản và thực hành thực tế. Bạn không thể chỉ học trong lớp và

coi rằng bạn đủ phẩm chất cho chức vụ đó. Tôi không chắc

người quản lí dự án "có chứng chỉ" ngụ ý gì nếu đích thân bạn

KHÔNG thực tế quản lí dự án. Theo quan điểm của tôi, người

quản lí dự án lớn phải có kinh nghiệm trong các dự án nhỏ và

vừa rồi nhận đào tạo đặc biệt về cách quản lí dự án lớn, đào tạo

này nên bao gồm về các kĩ năng qui trình, quyền lãnh đạo và

trao đổi bởi vì người quản lí phải biết người của mình đang làm

gì và tại sao. Khi họ không thể hiểu được người của họ đang

nói gì, hay hiểu công nghệ và phương pháp trong dự án thì họ

bị rủi ro. Vì phần lớn các dự án tương lai đều sẽ lớn, đặc biệt

với dự án chính phủ. Đào tạo đặc biệt về quản lí dự án cho dự

án lớn là mấu chốt.

Thất bại dự án

Một người phát triển phần mềm viết cho tôi: “Tôi đã làm

việc trên vài dự án; chúng tất cả đều thất bại và lỡ lịch biểu.

Khách hàng rất bực mình và người chủ công ti doạ đuổi mọi

người phát triển. Tôi không biết tại sao chúng thất bại hay phải

làm gì nhưng việc làm của tôi không còn được an ninh. Tôi

hiện thời đang coi sóc một việc khác. Xin thầy lời khuyên.”

42

Đáp: Dự án thường thất bại bởi nhiều nguyên nhân, phần

lớn do "lỗi con người" chứ không "lỗi kĩ thuật". Dự án là hoạt

động tổ, được quản lí bởi người quản lí dự án, để đạt tới tập các

mục đích và mục tiêu, bên trong một thời kì thời gian. Người

quản lí dự án phân công vai trò và trách nhiệm cho từng thành

viên tổ cũng như tập các nhiệm vụ cần được hoàn thành tương

ứng theo lịch biểu.

Tuy nhiên, dự án phần mềm thường thất bại khi tập các

nhiệm vụ này thay đổi nhưng thời gian không được cho. Chẳng

hạn, người phát triển được phân công 10 nhiệm vụ phải được

hoàn thành trong 10 ngày. Sau ba ngày, anh ta nhận được thêm

4 nhiệm vụ nữa nhưng anh ta vẫn phải hoàn thành tất cả các

nhiệm vụ của mình trong bẩy ngày còn lại. Đến ngày thứ năm,

anh ta được bảo rằng ba nhiệm vụ mà anh ta đã hoàn thành cần

thay đổi cho nên anh ta phải làm lại từ đầu ba nhiệm vụ nữa

trong năm ngày còn lại. Tất nhiên, anh ta không thể hoàn thành

được mọi nhiệm vụ này trong thời gian ngắn và dự án không

thể được hoàn thành đúng thời gian.

Vì các thành viên khác của tổ cần nhiệm vụ của anh ta

được hoàn thành để bắt đầu công việc của họ, nếu anh ta không

thể đưa cho họ nhiệm vụ đã hoàn thành của mình, họ không thể

bắt đầu nhiệm vụ của họ được. Bởi vì sự liên thuộc trong các

nhiệm vụ dự án, thành viên tổ chậm nhất có thể làm chậm lại

toàn bộ tổ dự án. Người quản lí dự án phải giám sát mọi hoạt

động và báo cáo tiến bộ cho người quản lí cấp cao cũng như

chia sẻ thông tin với các thành viên tổ. Nó giúp cho các thành

viên tổ được thông tin về hoạt động của nhau cũng như hiệu

năng của họ có thể nằm ở đâu dưới dạng điều được mong đợi

từ họ. Nó cung cấp cơ hội cho kiểm điểm và nếu cần, phân

công lại công việc và ưu tiên để làm cho dự án chạy hiệu quả

hơn. Dự án phải không trở thành không thể quản lí được.

Người quản lí dự án giỏi có thể định nghĩa lại mục đích của nó

là cái gì đó hiện thực đạt tới được trong những ràng buộc của

43

vấn đề thời gian thực. Người quản lí dự án kém không biết phải

làm gì cho nên dễ dàng đổ trách nhiệm cho người phát triển.

Câu hỏi của tôi là, nếu đội bóng thua trận đấu, bạn nghĩ

người chủ đuổi huấn luyện viên hay toàn đội bóng? Cùng câu

hỏi đó nên được hỏi cho dự án phần mềm. Nếu người chủ

thông minh, ông ấy sẽ đuổi người quản lí dự án, không đuổi

người phát triển. Mặc dầu dự án là công việc tổ nhưng trách

nhiệm phải thuộc vào người quản lí, không vào người phát

triển. Là người phát triển, bạn nên tiếp tục cải tiến kĩ năng của

bạn, học nhiều nhất có thể được. Với thiếu hụt công nhân có kĩ

năng hiện thời, bạn không nên lo lắng quá nhiều.

Cách giúp cho một dự án thất bại.

Một người quản lí dự án hỏi tôi: “Dự án phần mềm của

tôi không chạy tốt, tổ của tôi mệt mỏi và nản chí. Tôi phải làm

gì?”

Đáp: Không dự án phần mềm nào là hoàn hảo. Mọi dự án

đều có vấn đề. Là người quản lí dự án, bạn phải động viên tổ

của mình ngay cả khi dự án KHÔNG tiến triển tốt. Thứ nhất,

bạn phải báo cho tổ của bạn biết rằng hiện trạng là KHÔNG

tốt. Không có gì tồi hơn khi dự án không thực hiện tốt nhưng

người quản lí vẫn khăng khăng rằng nó là tốt. Bạn phải nói SỰ

THỰC nhưng có thể thêm chút khôi hài cho nó để cho tổ có thể

cười chút ít. Chẳng hạn: “Tôi biết rằng dự án là tệ cho nên câu

hỏi là ai muốn mua một sản phẩm kém? Chúng ta có thể bán nó

bằng nửa giá được không?” Thứ hai, bạn có thể yêu cầu tổ của

bạn hình dung về kết cục của dự án bằng việc cho phép họ nghĩ

tích cực về kết quả tốt hơn. Bạn có thể yêu cầu từng người nghĩ

về một kịch bản “Cái gì xảy ra nếu yêu cầu không thay đổi thì

…” “Cái gì xảy ra nếu chúng ta có đủ thời gian để làm thiết kế

44

tốt hơn …” rồi với tổ của bạn cùng nhau hình dung kết cục của

dự án. Cái gì sẽ có vẻ giống vậy? Làm sao cảm thấy thành

công? Bạn đã hoàn thành cái gì? Làm sao bạn đã đi tới đó?

Làm sao bạn biết bạn ở đó? Khi nào tổ của bạn cảm thấy mệt

mỏi hay nản chí, thường khó thấy kết thúc hạnh phúc. Là người

quản lí, bạn có thể giúp họ bằng việc cho hi vọng rằng kết quả

sẽ tốt hơn.

Nhiều vấn đề thường tới từ mệt mỏi vì người làm phần

mềm thường làm việc thời gian dài. Trong trường hợp đó, bạn

có thể cho tổ của mình nghỉ giải lao bằng việc có một ngày hội

thảo xây dựng tổ thay vì làm việc dự án. Thỉnh thoảng chuyến

đi dã ngoại một ngày ngoài thành phố có thể cho tổ của bạn "tư

duy tươi tắn" nhìn vào dự án cũ. Tốt hơn cả nếu bạn có thể mời

một diễn giả bên ngoài tới và nói với tổ về chủ đề khác và để

cho tổ nghỉ ngơi bộ óc của họ một chút. Với dự án lớn bao giờ

cũng có thay đổi. Thỉnh thoảng mọi người chuyển sang dự án

khác và thỉnh thoảng yêu cầu thay đổi. Là người quản lí dự án,

bạn phải kiểm điểm tài liệu kế hoạch dự án, làm các điều chỉnh

bằng việc xem lại những mong đợi, điều chỉnh mục đích và

phân công lại người cho các vai trò và trách nhiệm mới. Đôi

khi chút ít thay đổi có thể nạp lại năng lượng cho tổ, loại bỏ

một số vấn đề và thất vọng.

Ngay cả khi dự án thất bại hay bị huỷ bỏ bạn KHÔNG

nên cay đắng. Dễ dàng cho người quản lí dự án đổ lỗi tại cái gì

đó hay ai đó nhưng làm điều đó bạn đang tạo ra "môi trường

xấu" và có thể đánh mất sự kính trọng của tổ. Ai muốn làm

việc với người quản lí đổ lỗi cho người của họ? Bạn phải chấp

nhận trách nhiệm và rồi kết nối lại với tổ bằng việc chỉ ra cho

họ rằng bạn chăm nom. Bạn phải dùng mọi thất bại như "bài

học rút ra". Dễ dàng làm cho họ tham gia lại nếu bạn chỉ cho

họ rằng có cơ hội khác, dự án khác và bạn muốn họ làm việc

nữa cho bạn. Bạn có thể nói rằng “Là một tổ, tất cả chúng ta

đều học được từ bài học này” và chúng ta sẽ KHÔNG phạm sai

45

lầm này lần nữa. Khi tổ của bạn bị nản chí, ĐỪNG né tránh họ.

Thay vì thế, cố gắng chủ động và xem cái gì có thể làm lại và

KHÔNG sợ hỏi các ý tưởng mới từ tổ của bạn về cách làm nó

tốt hơn lần sau. Bạn sẽ ngạc nhiên bao nhiêu ý tưởng họ có thể

đem tới để làm khác biệt lớn cho lần sau.

Tránh thất bại dự án phần mềm

Một sinh viên hỏi: Tại sao nhiều dự án phần mềm thế bao

giờ cũng trễ hay thất bại? Nếu kĩ nghệ yêu cầu là quan trọng thì

tại sao nó KHÔNG được dạy trong trường? Tại sao nó thậm chí

KHÔNG được dạy trong môn quản lí dự án?

Đáp: Lí do then chốt mà phần lớn dự án phần mềm bị

chậm là vì thay đổi trong yêu cầu phần mềm và ước lượng dự

án sai. Lí do khách hàng giữ thay đổi yêu cầu vì việc thu thập

kém các yêu cầu trước khi bắt đầu dự án. Nhiều người quản lí

dự án phần mềm cũng không coi tính hợp thức của yêu cầu của

khách hàng là một phần việc làm của họ và chấp nhận các yêu

cầu mà không phân tích thêm. Lí do khác có thể gây ra vấn đề

lịch biểu là người phát triển muốn “hoàn thiện” bất kì cái gì họ

làm. Nhiều người thêm các mã phụ không phải là một phần của

yêu cầu gốc để làm cho nó “tốt hơn” mà không xét với tác

động lên dự án. Nhiều người viết mã và viết lại mã của họ

nhiều lần cho tới khi họ cảm thấy thoả mãn với nó. Những điều

này tiêu tốn nhiều thời gian và nỗ lực và làm cho dự án bị trễ.

Kĩ nghệ yêu cầu chủ yếu được dạy trong trường có

chương trình Kĩ nghệ phần mềm. Bởi vì đào tạo quản lí dự án

thường bắt đầu với đặc tả yêu cầu phần mềm (SRS) đã được

làm tài liệu cho nên thu được yêu cầu KHÔNG thuộc phạm vi

của chúng. Đào tạo khoa học tính toán giả định rằng khách

hàng sẽ viết yêu cầu cho nên người phát triển phần mềm sẽ bắt

46

đầu công việc của họ với các yêu cầu phần mềm đã có tại chỗ.

Lúc bắt đầu của dự án, có danh sách các yêu cầu với ngân sách

tương ứng (chi phí), con người (tài nguyên), và lịch biểu (thời

gian). Do đó bất kì thay đổi nào về yêu cầu mà không thay đổi

về chi phí, tài nguyên và thời gian đều sẽ ảnh hưởng tới dự án.

Không may, nếu các yêu cầu KHÔNG được xác định tốt,

khách hàng sẽ phải thêm hay thay đổi yêu cầu sau khi dự án bắt

đầu nhưng họ thường KHÔNG cho phép thay đổi trong chi phí,

thời gian hay tài nguyên. Nhiều người quản lí dự án phần mềm

không biết cách thương lượng trong thay đổi yêu cầu và chấp

nhận nó mà không nghĩ về rủi ro cho dự án.

Người quản lí dự án giỏi có thể tránh được thay đổi yêu

cầu bởi:

Đưa khách hàng và người dùng tham gia sớm vào trong

dự án.

Phân tích kĩ lưỡng các yêu cầu trong lúc bắt đầu dự án

để chắc chắn chúng đầy đủ, được làm tài liệu tốt và đáp

ứng nhu cầu của khách hàng.

Thiết lập tổ cho Ban kiểm soát thay đổi (CCB) để đánh

giá rủi ro của việc thực hiện thay đổi trước khi chấp

nhận chúng.

Đưa mọi khác hàng tham gia vào mọi pha của dự án

(đặc biệt trong pha lập kế hoạch).

Đưa ra tăng dần phần mềm. Dừng các yêu cầu thêm hay

trì hoãn thực hiện chúng cho tới lần đưa ra tiếp.

Dùng cách tiếp cận Agile (nếu dự án nhỏ) như SCRUM.

Danh mục sản phẩm (phạm vi) là động và sẽ thay đổi trong

toàn bộ vòng đời phát triển phần mềm chừng nào khách hàng

còn cảm thấy rằng những thay đổi đó là quan trọng và chấp

nhận trách nhiệm về chúng bằng việc cho phép thêm thời gian.

47

Cách ngăn ngừa thất bại dự án

Một người quản lí dự án hỏi tôi: “Dự án của tôi đang bị

trục trặc, chúng tôi bị tụt sau lịch. Một số thành viên tổ bỏ dự

án và người chủ công ti không hài lòng. Tôi không muốn thấy

dự án của tôi thất bại. Tôi có thể làm gì trong tình huống này?

Xin thầy giúp đỡ."

Đáp: Phần lớn các dự án đều bị trục trặc khi chúng tụt

sau lịch hay tiêu quá ngân sách. Chúng sẽ không hoàn thành

thành công nếu không có nỗ lực nào đó và quyết tâm của tổ dự

án. Tuy nhiên, người phải giành lại kiểm soát và cứu nó khỏi

thất bại là người quản lí dự án.

Là người quản lí dự án, bạn phải kiểm điểm mọi nhiệm

vụ để xác định đúng chỗ dự án đang ở có liên quan tới lịch biểu

và ngân sách thực tại. Bạn phải nói cho các thành viên tổ và

giải thích cho họ rằng bạn muốn biết tiến bộ nào đã được làm

tới giờ và cái gì đã xảy ra. Đây KHÔNG phải là lúc đổ lỗi bất

kì ai mà bạn phải giải thích rõ ràng rằng bạn muốn giành lại

kiểm soát bằng việc biết chỗ bắt đầu tuyến cơ sở mới. Theo

cách đó tổ không cảm thấy bị đe doạ, mất tự tin, hay hoảng sợ

về việc lỡ lịch biểu. Phải làm rõ ràng cho tổ rằng có vấn đề và

chúng phải được giải quyết. Nhiều người quản lí thiếu kinh

nghiệm thường che giấu sai lầm của họ bằng việc đổ lỗi cho ai

đó hay cái gì đó. Điều đó sẽ làm cho vấn đề tồi tệ nhất và

không giải quyết được gì cả. Bạn phải chấp nhận sự kiện là nếu

bất kì cái gì xảy ra trong dự án, đó chính là lỗi của người quản

lí dự án. Không thành vấn đề nếu lịch biểu sai. Không thành

vấn đề nếu ngân sách là không đủ. Vì người quản lí dự án lập

kế hoạch cho dự án, ước lượng lịch biểu và ngân sách và quản

lí tổ, chính trách nhiệm của người quản lí là về điều xảy ra cho

48

dự án. Bất kể điều gì xảy ra, bạn phải chấp nhận rằng bạn phạm

sai lầm trước và sẵn lòng sửa nó. Bằng việc làm điều đó các

thành viên tổ sẽ cảm thấy thoải mái rằng không ai sẽ bị quở

trách và vẫn còn ở lại với dự án. Thỉnh thoảng nguyên nhân

của vấn đề không phải ở thời gian hay ngân sách mà ở con

người và kĩ năng. Trước khi bạn có thể sửa được vấn đề này, tổ

phải biết rằng bạn dự định làm dự án này thành công và bạn sẽ

làm bất kì cái gì cần thiết để sửa vấn đề. Nếu tổ không cảm

thấy một cách mạnh mẽ rằng nó có thể được sửa, dự án chắc

chắn sẽ thất bại.

Chính vai trò của người quản lí dự án là nhắc nhở thành

viên tổ về viễn kiến dự án và động viên thành viên tổ hiểu ích

lợi của dự án được hoàn thành, cho họ như các cá nhân cũng

như cho cả công ti. Không dự án nào là hoàn hảo, mọi dự án

đều có vấn đề nào đó. Bằng việc giải quyết những vấn đề này,

tổ sẽ học cái gì đó mới. Kinh nghiệm không tới từ việc học từ

sách vở hay theo bài giảng mà trong làm việc thực tế trên dự án

và giải quyết vấn đề dự án. Khi mà các thành viên tổ đồng ý và

quyết tâm hoàn thành dự án, bạn có thể bắt đầu giải quyết

những vấn đề này. Tất nhiên, bạn không thể làm điều đó bằng

riêng bản thân bạn. Đừng là anh hùng. Bạn phải kiểm điểm mọi

vấn đề và xác định cách giải quyết chúng. Bạn phải đi tới giải

pháp rồi đi tới gặp người chủ công ti và thảo luận với ông ấy về

giải pháp đề nghị của bạn. Phải trung thực và rõ ràng về điều

bạn muốn làm nhưng để người chủ công ti ra quyết định.

Không người chủ nào muốn thấy dự án thất bại cho nên ông ấy

phải giúp bạn. Nếu đấy là vấn đề lịch biểu, người chủ phải thảo

luận với khách hàng và yêu cầu lịch biểu mới. Nếu đấy là vấn

đề ngân sách thì người chủ phải quyết định tăng ngân sách.

Nếu đấy là con người và kĩ năng thì người chủ có thể muốn

xem liệu bạn có thể thuê người mới hay chuyển một số người

trong công ti sang hỗ trợ cho dự án của bạn.

49

Có những hỗ trợ này, bạn có thể lập kế hoạch lại cho dự

án của bạn. Bạn phải không dùng bản kế hoạch dự án cũ vì nó

không còn hợp thức nữa. Điều quan trong phải nhấn mạnh lại

mục đích doanh nghiệp, viễn kiến của dự án được hoàn thành

cho mọi thành viên tổ và khách hàng. Bản kế hoạch dự án mới

của bạn là việc lập kế hoạch cách đi từ nơi bạn bây giờ đang ở

tới dự án được hoàn thành và thành công. Bạn phải đảm bảo

rằng thành viên tổ biết tới tầm quan trọng của từng nhiệm vụ

mà họ phải hoàn thành vì bạn bắt đầu quản lí dự án bằng lịch

biểu mới, ngân sách mới và các thành viên tổ mới.

Ngay cả điều đó không có nghĩa là bạn đã hoàn toàn sửa

mọi vấn đề. Có thể là một số yếu tố gây ra vấn đề vẫn còn tồn

tại cho nên đừng cảm thấy lạc quan vội. Bạn phải vẫn còn bình

thản và hội tụ vào việc làm cho dự án tiến triển một cách hiệu

quả. Bạn phải đặt ra các cuộc kiểm điểm hàng tuần để kiểm

tiến bộ một cách năng nổ. Làm lại cấu trúc phân việc của bạn

thành các nhiệm vụ nhỏ hơn để dễ kiểm soát và phân công

những nhiệm vụ này cho tổ của bạn và phải chắc rằng từng

người làm việc tương ứng. Đừng để bất kì ai cảm thấy không

thoải mái. Bạn phải khuyến khích họ bằng việc trao đổi thường

xuyên với nhiều ca ngợi hơn. Thái độ tích cực của bạn được

cần vào lúc này. Duy trì kế hoạch của bạn và lãnh đạo tổ dự án

với lòng biết ơn và đánh giá cao. Nhớ rằng tài chính và lịch

biểu có thể thay đổi trong tiến trình dự án nhưng thành viên tổ

là nhân tố then chốt để làm cho dự án thành công hay thất bại.

Cách duy nhất để thu được kiểm soát dự án là đối xử mọi thứ

như cơ hội và nhắc nhở mọi người về viễn kiến của dự án, rồi

đi tới việc hoàn thành thành công đó.

50

Công việc dự án sớm

Ngay cả ngày nay số lượng dự án phần mềm thất bại vẫn

còn cao. Bằng cách nào đó người quản lí phần mềm liên tục xô

vào các dự án mà thậm chí không nghĩ tại sao dự án quá khứ đã

thất bại. Theo một nghiên cứu công nghiệp, đa số người quản lí

dự án không nhận được đào tạo thích hợp hay không biết cách

lập kế hoạch dự án. Nhiều người quản lí dự án lẫn lộn kế hoạch

dự án với lịch biểu dự án. Lịch biểu chỉ là phần nhỏ của kế

hoạch dự án; nó thường lấy dạng các nhiệm vụ hoàn thành

trong đúng khoảng thời gian. Bản kế hoạch dự án là bản lộ

trình cung cấp hướng dẫn về ưu tiên của các hoạt động, phạm

vi của công việc, vòng đời, phương pháp và công cụ được

dùng. Nó nhận diện khách hàng, người dùng, chiến lược doanh

nghiệp, chất lượng, rủi ro, và cách thức theo đó chi phí dự án

và con người sẽ được quản lí.

Phần lớn các dự án thất bại do yêu cầu lập kém. Đây là

vấn đề số một gây ra thay đổi phạm vi, điều đưa tới nhiều thời

gian và ngân sách cần để hoàn thành dự án. Đó là lí do tại sao

việc của kĩ sư yêu cầu hay người phân tích doanh nghiệp là

quan trọng nhưng ít công ti có vai trò này và ít trường dạy về kĩ

năng này. Nhiều công ti mong đợi rằng người quản lí dự án

phải có trách nhiệm cho yêu cầu của dự án và đây là sai lầm

lớn. Yêu cầu và mối quan hệ khách hàng đòi hỏi kĩ năng khác

và nhiều nỗ lực và người quản lí dự án bận rộn không thể quản

lí thích hợp dự án và khách hàng cùng lúc được. Đây cũng là

chỗ một số sách quản lí dự án không đề cập tới. Yêu cầu kém

hay yêu cầu được xác định nghèo nàn sẽ dẫn tới kế hoạch dự án

kém. Vì kế hoạch dự án phản ánh công việc, tài nguyên, ngân

sách và thời gian cần để thoả mãn các yêu cầu, dễ dàng thấy

tầm quan trọng của việc có được yêu cầu và dự án đúng.

Kĩ sư yêu cầu được đào tạo để làm việc với khách hàng

và đảm bảo thoả thuận từ mọi khách hàng trước khi lập kế

51

hoạch dự án. Kĩ sư yêu cầu làm việc với khách hàng để thu

thập nhu cầu của họ, hiểu vấn đề của họ và làm tài liệu chúng

trong bản đặc tả yêu cầu. Khách hàng phải kiểm điểm các tài

liệu yêu cầu và chấp thuận trước pha lập kế hoạch dự án. Kĩ sư

yêu cầu làm việc với người quản lí dự án để dịch các yêu cầu

thành phát biểu phạm vi dự án, cũng như các cấu phần chính

mà sẽ thoả mãn cho phạm vi. Có vài phần tử bản chất mà cần

được đưa vào trong định nghĩa dự án:

Mô tả về vấn đề doanh nghiệp và giải pháp cho vấn đề đó

Mô tả về ích lợi của dự án (hoàn cảnh doanh nghiệp)

Định nghĩa về viễn kiến, mục đích, phạm vi và ngân sách

dự án

Danh sách các vật chuyển giao chính mà, khi được chuyển

giao cho khách hàng sẽ hoàn toàn thoả mãn các yêu cầu của

dự án

Ngày chuyển giao được cam kết của dự án

Định nghĩa dự án là phần thứ nhất của việc lập kế hoạch

nơi tổ dự án sẽ được tham gia vào việc chia các yêu cầu này

thành các cấu phần nhỏ hơn. Cấu trúc phân việc - Work

Breakdown Structure (WBS) là nền tảng của kế hoạch dự án.

Nó là cấu trúc logic có phân cấp biểu diễn cho mọi công việc

cần để tạo ra mọi vật chuyển giao dự án.

Bằng việc dành nhiều nỗ lực vào lúc bắt đầu, dự án có

thể tránh được những thay đổi yêu cầu không cần thiết và

người quản lí dự án có thể tổ chức dự án có cơ hội tốt hơn cho

thành công.

52

53

2. Người quản lí dự án

Người quản lí dự án-1

Tôi có một người bạn vừa được đề bạt làm người quản lí

dự án phần mềm. Anh ấy sung sướng bởi vì sau nhiều năm làm

người lập trình, cuối cùng anh ấy cũng đạt được chức vụ mà

anh ấy hằng mong muốn. Tuy nhiên, anh lại lo lắng bởi vì anh

ấy không được huấn luyện gì và anh ấy hỏi xin lời khuyên. Đây

là điều tôi viết cho anh ấy:

Là người quản lí dự án, ưu tiên của bạn là thoả mãn các

yêu cầu của khách hàng và hướng dẫn tổ dự án đạt tới thành

công. Trách nhiệm mới của bạn bao gồm việc giải quyết các

vấn đề, thiết lập mục đích cho dự án và cung cấp các hướng

dẫn kĩ thuật thích đáng.

Vì bạn chưa được luấn luyện đối với vị trí này, bạn có thể

thiếu những kĩ năng nào đó trong công việc mới của mình. Kĩ

năng kĩ thuật có lẽ là một nhân tố để bạn được chọn làm quản lí

nhưng bạn sẽ cần các kĩ năng bổ sung khác để có hiệu quả đầy

đủ. Hãy nhìn một cách trung thực vào những điểm mạnh và

yếu của mình và làm kế hoạch để cải thiện mọi điểm yếu.

54

Bạn cần sự giúp đỡ trong cách đối xử quan hệ giữa con

người, giải quyết xung đột và chuẩn bị xử trí các tình huống từ

việc thuê người tới sa thải nhân viên và thương lượng với

khách hàng. Là người lãnh đạo dự án, bạn sẽ có trách nhiệm

điều phối công việc của những người khác, lập kế hoạch và

theo dõi tiến độ, và tiến hành hành động sửa chữa khi mọi sự đi

không đúng.

Bạn nên tham gia khoá đào tạo về quản lí dự án, và bắt

đầu đọc các sách và bài báo về quản lí dự án. Khả năng của bạn

trong việc lập các ưu tiên, tổ chức các buổi họp có hiệu quả, và

trao đổi ý kiến rõ ràng sẽ tác động tới khả năng của bạn như

một người quản lí. Việc thừa nhận và khen thưởng cho thành

tích của các thành viên tổ của bạn cũng là cách quan trọng làm

cho họ được động viên. Việc thừa nhận có thể biến thiên từ

những việc tượng trưng (lời cám ơn) cho tới vật chất (quà tặng,

tiền, thưởng). Bằng việc dành ra một chút ý nghĩ và tiền bạc

trong chương trình thừa nhận và khen thưởng, bạn có thể thu

được nhiều sự hợp tác từ các thành viên tổ.

Là người quản lí mới, bạn phải lập mục đích cho dự án.

Các mục đích phải được đo lường để cho bạn có thể chọn lựa

vài cách đo đơn giản sẽ chỉ ra liệu bạn đang có tiến triển hướng

tới đích đó không. Chẳng hạn, nếu bạn thấy rằng dự án thường

bị chậm bởi vì thay đổi yêu cầu, bạn có thể đặt mục đích cải

thiện sự ổn định yêu cầu khoảng 50% trong vòng sáu tháng.

Bạn bắt đầu đếm số các yêu cầu thay đổi qua từng tuần hay

tháng, hiểu được ai yêu cầu những thay đổi này và có hành

động kiểm soát chúng. Điều này có thể khiến cho bạn sửa đổi

qui trình xây dựng yêu cầu và cách bạn tương tác với khách

hàng. Có hai lí do chính để cải tiến qui trình của bạn: sửa chữa

vấn đề, và ngăn ngừa vấn đề. Bạn phải theo dõi sát các rủi ro

đã biết hay dự đoán trước đối với thành công của dự án của

bạn. Bạn phải phân tích điểm mạnh và yếu của qui trình hiện

đang được dùng, và rủi ro đối diện với dự án của bạn. Việc đặt

55

ra các mục đích đo lường sẽ đem sự hội tụ vào nỗ lực cải tiến

của bạn. Hãy giữ các mục đích là ưu tiên, và điều phối tiến độ

với nhóm một cách đều đặn. Nhớ rằng mục tiêu của bạn là để

cải tiến sự thành công kĩ thuật và nghiệp vụ mà dự án và công

ti của bạn nhắm đạt tới.

Là người quản lí phần mềm mới, việc lãnh đạo của bạn là

quan trọng cho tổ dự án hướng tới thành công dự án. Với sức

ép hàng ngày, có thể bạn khó giữ cho dự án tiến theo hướng

bạn muốn nhưng bạn phải bình tĩnh bởi vì bạn không thể làm

mọi thứ ngay một lúc được cho nên bạn cần lựa chọn vài điều

thích hợp cho tình huống và bắt đầu làm việc. Bạn nên nhớ

rằng bạn chịu trách nhiệm cho việc làm nhiều hơn là việc hoàn

thành dự án đúng thời gian và theo ngân sách. Bạn phải lãnh

đạo nhân viên kĩ thuật trong tổ cùng nhau chia sẻ và cam kết về

chất lượng; khuyến khích môi trường làm việc theo tổ; thúc

đẩy và thưởng cho việc ứng dụng các thực hành kĩ nghệ phần

mềm; và giữ cân bằng nhu cầu của khách hàng, công ti, thành

viên tổ và bản thân bạn.

Người quản lí dự án-2

Hàng nghìn năm trước đây, triết gia Hi Lạp Socrates đã

dạy học trò của ông ấy: "Tự biết mình". Ngày nay, tôi muốn

dùng cùng cách tiếp cận đó trong kĩ nghệ phần mềm bằng việc

gợi ý rằng người quản lí dự án phần mềm:

1) Biết mục đích dự án của bạn.

Với mọi dự án phần mềm, bạn phải đặt ưu tiên bởi vì bạn

không thể hoàn tất mọi thứ ngay một lúc. Không có ưu

tiên bạn sẽ không có khả năng hội tụ và đạt tới cái gì. Bạn

nên có khả năng phát biểu mục đích dự án trong một câu

56

kiểu như "Lịch biểu là ưu tiên số một" hay "Chức năng là

quan trọng nhất". Nếu bạn không thể nêu được điều đó,

cơ hội đạt tới thành công của bạn sẽ không lớn.

2) Biết thành viên tổ của bạn

Thành viên tổ của bạn là điều quan trọng nhất mà bạn có

và hiệu năng của họ sẽ làm cho dự án của bạn thành công

hay thất bại. Bạn phải chăm nom tới họ và đảm bảo tổ

hoạt động như một đơn vị thống nhất chứ không phải như

tập hợp các cá nhân. Việc trao đổi tổ là then chốt nên bạn

phải đầu tư thời gian vào việc thúc đẩy tin cậy và đảm

bảo rằng mọi người đều biết điều họ phải làm để đạt tới

mục đích.

3) Biết khách hàng của bạn

Bạn phải trao đổi với khách hàng trên cơ sở đều đặn

(hàng ngày, hàng tuần). Họ sẽ cho bạn biết cái gì là quan

trọng với họ và mặc dầu họ sẽ đổi ý thường xuyên nhưng

bạn phải xây dựng mối quan hệ tốt với họ bởi vì sự thoả

mãn của họ sẽ là bản chất cho thành công của bạn.

4) Biết qui trình của bạn

Nhiều người thích viết mã trước rồi hỏi câu hỏi sau. Đó

là lí do tại sao họ cần huấn luyện kĩ nghệ phần mềm bởi

vì nếu bạn viết mã mà không hiểu rõ yêu cầu thì sẽ rất

khó thay đổi một khi việc đã bắt đầu. Cho nên điều quan

trọng là quyết định chính xác cách bạn sẽ định làm bằng

việc lập kế hoạch mọi thứ tương ứng với qui trình và hiểu

rằng người kĩ sư phần mềm giỏi bao giờ cũng tuân theo

qui trình để làm việc hiệu quả. Bằng việc tuân theo qui

trình bạn sẽ:

Xây dựng niềm tin vào bản thân mình rằng bạn

đang tuân theo bản lộ trình có kỉ luật.

57

Có kế hoạch dự phòng trong sự cố điều gì đó đi

sai

Phát sinh bầu không khí có kỉ luật trong môi

trường làm việc.

5) Biết nhiệm vụ của bạn

Ngày nay phần lớn các yêu cầu phần mềm đều phức tạp

nên người quản lí dự án phải phân rã chúng thành các

nhiệm vụ nhỏ hơn để tổ thực hiện chúng tương ứng. Việc

phân rã và tổ chức các nhiệm vụ này là điều kiến trúc

phần mềm là gì. Các thành viên tổ phải chú ý tới cách

từng nhiệm vụ khớp với sản phẩm toàn thể. Thiếu cách

tiếp cận hệ thống này bạn đi tới hàng trăm mảnh khác

nhau mà không thể tích hợp lại được.

6) Biết thay đổi của bạn

Chúng ta sống trong thế giới đang thay đổi. Khi dự án

tiến triển mọi thứ chung cuộc sẽ thay đổi. Khách hàng sẽ

đi tới những ý tưởng mới hay tổ của bạn có thể lâm vào

những vấn đề nào đó trong thực hiện. Thay đổi phải được

kiểm soát nếu bạn muốn thành công. Bạn cần xây dựng

kế hoạch linh hoạt hấp thu được các thay đổi khi chúng

tới nhưng bạn phải không chịu nhún với bất kì sức ép

nào. Nếu bạn quá linh hoạt dự án của bạn sẽ ở ngoài kiểm

soát như ngựa không có người cưỡi, nhưng nếu bạn quá

cứng nhắc dự án của bạn sẽ vỡ như thuỷ tinh lúc thay đổi

xảy ra. Bạn phải ước tính mọi thay đổi để nhận diện các

tác động và xác định ưu tiên, thay đổi nào phải được thực

hiện trước và thay đổi nào có thể chờ đợi và thảo luận kế

hoạch của bạn với khách hàng.

7) Biết kiểm thử của bạn

58

Đừng trông đợi mọi sự làm việc hoàn hảo nên bạn phải

kiểm thử mọi thứ sớm nhất có thể được. Mọi người đều

phạm sai lầm cho nên kiểm thử là cách tốt nhất để tìm ra

và khử bỏ lỗi. Ngay khi bạn nhận được yêu cầu, chuẩn bị

trường hợp kiểm thử bằng việc tự hỏi mình "Mình kiểm

thử cái này thế nào đây?" Nếu bạn không thể đi tới trường

hợp kiểm thử thì hoặc là bạn không hiểu yêu cầu hoặc là

yêu cầu không được khách hàng xác định rõ. Trong

trường hợp đó, hãy hỏi khách hàng họ thích kiểm thử nó

như thế nào?

8) Biết giới hạn của bạn

Thành công là việc chuyển giao sản phẩm đã hoàn thành

cho khách hàng, họ được thoả mãn với kết quả. Để làm

điều đó bạn phải linh hoạt. Đừng bị khoá chặt vào trong

lịch biểu cứng nhắc mà thương lượng với khách hàng về

khuôn khổ thời gian khả thi. Đừng bị mù quáng bởi

phương pháp hay công cụ bởi vì chúng được thiết kế ra

để hỗ trợ cho bạn chứ không giải quyết vấn đề của bạn.

Bạn phải dùng tất cả các công cụ và người có sẵn cho bạn

nhưng chú ý tới điều khách hàng muốn và điều chỉnh ưu

tiên của bạn cùng kế hoạch của bạn cho phù hợp với hoàn

cảnh.

Người quản lí dự án-3

Quản lí dự án phần mềm là khó bởi vì yêu cầu và công

nghệ bao giờ cũng thay đổi và phần lớn những người quản lí

không được đào tạo chính thức nào về cách quản lí dự án phần

mềm. Những người quản lí có kinh nghiệm biết cách dành thời

gian từ lúc bắt đầu dự án để gặp gỡ với khách hàng để hiểu nhu

cầu của họ và mong đợi của họ. Một số khách hàng coi lịch

59

biểu là quan trọng khi những khách hàng khác coi chất lượng là

quan trọng hơn. Với việc biết yếu tố nào là quan trọng, họ có

thể lập kế hoạch dự án tương ứng.

Người quản lí thiếu kinh nghiệm có xu hướng kết thúc

việc lập kế hoạch nhanh chóng để cho họ có thể viết mã. Đó là

lí do tại sao nhiều người trong số họ không thành công bởi vì

họ không biết đích xác điều khách hàng muốn.

Người quản lí có kinh nghiệm biết cách cân bằng các yếu

tố mấu chốt của dự án như các mục tiêu chức năng, ngân sách,

lịch biểu và chất lượng. Bằng việc xem xét cẩn thận từng yếu

tố với kế hoạch dự án; họ có thể thương lượng với khách hàng

về những thay đổi trong lịch biểu, chi phí và tài nguyên.

Thương lượng là một trong những kĩ năng quan trọng nhất của

người quản lí dự án nhưng hiếm khi được dạy trong trường.

Người quản lí có kinh nghiệm biết cách làm việc với khách

hàng và thương lượng về điều thực tế có thể đạt tới được. Họ

bao giờ cũng lập kế hoạch, thương lượng, cân đối, hỏi và nghe

bởi vì họ biết họ càng dành nhiều thời gian cho lập kế hoạch,

họ càng mất ít thời gian phải giải quyết vấn đề về sau.

Người quản lí thiếu kinh nghiệm thích viết mã, nhưng

không thích lập kế hoạch.

Người quản lí có kinh nghiệm bao giờ cũng phân rã công

việc dự án thành những nhiệm vụ nhỏ hơn để cho họ có thể ước

lượng được chính xác hơn. Họ kiểm các ước lượng của mình

với thành viên tổ, hỏi ý kiến của họ, hợp nhất dữ liệu trước khi

lập kế hoạch lịch biểu. Họ cũng dùng danh sách kiểm và trang

tính lập kế hoạch cho những nhiệm vụ này, những điều bao

quát tất cả các bước cần thiết.

Người quản lí thiếu kinh nghiệm không biết cách phân rã

hay ước lượng, họ chỉ đoán hay tuân theo bất kì lịch biểu nào

60

khách hàng đưa cho họ. Không có thời gian đúng và lịch biểu

không hợp lí, họ không bao giờ hoàn thành dự án đúng hạn.

KHÔNG có dự án nào hoàn hảo. Gần như mọi dự án đều

có vấn đề, trong kiểm điểm kĩ thuật hay kiểm thử; sẽ có lỗi hay

các vấn đề khác phải được làm lại. Người quản lí có kinh

nghiệm biết cách lập kế hoạch để làm lại bằng việc đặt ra một

số thời gian phụ trong toàn thể kế hoạch dự án để cho tổ dự án

sẽ có đủ thời gian sửa chữa vấn đề và không vội vàng vào các

hoạt động khác.

Người quản lí thiếu kinh nghiệm không biết cách lập kế

hoạch để làm lại, họ giả định mọi sự đều tốt cho tới khi cái gì

đó xảy ra, họ hoảng hốt. Vì họ không biết cách kiểm soát vấn

đề, vấn đề sẽ kiểm soát họ.

Người quản lí có kinh nghiệm hiểu tầm quan trọng của

đào tạo. Họ xác định các thành viên tổ cần bao nhiêu thời gian

để cải tiến kĩ năng của mình và chuẩn bị thời gian và ngân sách

cho họ. Họ hiểu rằng tổ có kĩ năng cao là nhân tố then chốt cho

thành công và sẵn lòng đầu tư cho người của họ.

Người quản lí thiếu kinh nghiệm không đánh giá được

giá trị của đào tạo. Họ coi nó là "tốn kém" cho nên họ không

gửi tổ của họ đi đào tạo bổ sung. Ngay cả người giỏi nhất cũng

sẽ cần đào tạo và không có đào tạo, kĩ năng của họ có thể trở

nên lạc hậu vì họ không theo kịp những thay đổi công nghệ.

Không dự án nào có thể thành công với "người thiếu kĩ năng”.

Theo nghiên cứu mới nhất, chỉ 23% dự án phần mềm

được hoàn thành đúng thời gian, theo ngân sách với mọi chức

năng được yêu cầu. 77% dự án phần mềm bị chậm, vượt quá

ngân sách với ít chức năng hơn và cần nhiều thời gian hơn,

nhiều tiền hơn để sửa chữa vấn đề.

Trong 35 năm làm việc trong công nghiệp của mình, tôi

chưa bao giờ thấy một dự án thất bại bởi vì tổ dự án không thể

61

viết được mã mà tôi đã thấy bao nhiêu dự án thất bại vì người

quản lí không có kĩ năng được cần tới để quản lí dự án.

Người quản lí dự án hiệu quả

Một người quản lí phần mềm viết cho tôi: “Sau bốn năm

làm việc như người phát triển phần mềm, em được đề bạt làm

người quản lí dự án. Công ti cử em theo lớp học quản lí dự án

hai tuần để cải tiến kĩ năng của em. Em cũng học nhiều từ blog

của thầy. Em muốn là người quản lí dự án phần mềm giỏi nhất.

Thầy có lời khuyên phụ nào không?"

Đáp: Là người quản lí dự án mới, bạn sẽ thu được nhiều

kĩ năng và kinh nghiệm hơn với thời gian làm quản lí dự án

phần mềm. Cấp quản lí của bạn đã nhận ra bạn là người phát

triển giỏi và đã thưởng cho bạn vị trí mới. Công ti cũng đã đầu

tư vào bạn bằng việc cử bạn đi dự khoá đào tạo. Bây giờ bạn

cần chứng minh khả năng lãnh đạo của bạn đặc biệt trong quản

lí dự án phần mềm với báo cáo đúng về tiến độ và thành công

của dự án.

Để trở thành người quản lí dự án phần mềm hiệu quả, bạn

phải tập trung vào mục đích và hạn chót của dự án của bạn, hỗ

trợ cho tổ của bạn, và làm việc tốt với mọi người hỗ trợ cho dự

án và khách hàng. Với mọi dự án, bạn cần đặt ra viễn kiến hay

chiều hướng cho tổ tuân theo. Bằng việc có viễn kiến, bạn biết

đích xác mục đích và chủ định của bạn và cấp quản lí mong đợi

gì từ bạn. Và chừng nào bạn còn giữ trao đổi rằng viễn kiến đã

không thay đổi, bạn sẽ thành công. Nếu bạn có thể chuyển giao

kết quả mong muốn, cấp quản lí sẽ nghĩ về bạn như người quản

lí dự án hiệu quả.

62

Từng dự án đều có lịch biểu. Thỉnh thoảng nó được

khách hàng đặt ra, thỉnh thoảng do cấp quản lí. Bạn cần hiểu rõ

ràng về lịch biểu và lí do tại sao họ đặt ngày tháng đó. Bằng

việc hiểu lí do; bạn sẽ biết liệu nó là ngày tháng cố định mà

không thể được thay đổi hay là ngày tháng tuỳ tiện mà bạn có

thể thương lượng. Bạn phải làm việc với tổ dự án của bạn để đi

tới ước lượng thoả đáng mà tổ của bạn sẽ hỗ trợ. Từ những ước

lượng này, bạn có thể bắt đầu thương lượng với cấp quản lí về

lịch biểu. Nếu lịch biểu là ngày tháng cố định và có khác biệt

lớn giữa ước lượng của bạn và lịch biểu này, bạn phải hỏi xin

thêm người hay giảm chức năng dự án. Tất nhiên, nếu đó là

ngày tháng linh động thì bạn có thể xin thêm thời gian. Một số

người quản lí dự án không coi trọng lịch biểu hay không bao

giờ để ý tới nó và đó là lí do tại sao nhiều người không chuyển

giao dự án của họ đúng thời gian. Đừng cho phép bản thân bạn

lâm vào tình huống đó. Coi lịch biểu là quan trọng và phải chắc

rằng bạn không bao giờ bỏ lỡ hạn chót. Bằng việc làm điều đó,

cấp quản lí sẽ nghĩ về bạn như người quản lí có kĩ năng có giá

trị, đáng tin.

Mọi dự án đều có ngân sách. Ngân sách là công cụ kiểm

soát để đo tính hiệu quả của nỗ lực quản lí. Ngân sách thường

được theo dõi bởi người chủ công ti để nhận diện rủi ro và lợi

nhuận. Phải chắc rằng bạn ước lượng ngân sách của bạn đúng

đắn và cẩn thận với chi tiêu của bạn. Là người quản lí dự án,

bạn phải giám sát và kiểm soát ngân sách của bạn một cách cẩn

thận trong khi dự án đang thực hiện.

Tổ phần mềm thường có xung đột giữa các thành viên. Lí

do là nhiều người phát triển chưa bao giờ nhận được đào tạo về

tổ hay biết cách làm việc trong tổ. Lúc bắt đầu dự án, phải chắc

rằng bạn dành thời gian để xây dựng tổ và phân công vai trò,

trách nhiệm cho từng thành viên một cách rõ ràng và hợp lí để

tránh mọi xung đột về sau. Mỗi ngày, dành thời gian cùng tổ để

nói chuyện với họ và khuyến khích họ về công việc của họ.

63

Bằng việc làm việc với tổ trên cơ sở hàng ngày, bạn có thể

nhận diện các vấn đề và giải quyết chúng trước khi chúng trở

thành không thể giải quyết được. Khả năng của bạn để giải

quyết các xung đột có thể là thuộc tính quan trọng nhất cho

việc quản lí dự án thành công. Bạn chắc chắn muốn được biết

tới như người quản lí hiệu quả. Bạn không muốn để cho quản lí

cấp cao phải bước vào để giải quyết xung đột cá nhân cho bạn.

Người quản lí dự án kém nhất

Tuần trước, một sinh viên hỏi tôi: “Thầy đã dạy chúng

em cách thành công trong quản lí dự án phần mềm nhưng

không nhắc gì tới những điều làm cho dự án thất bại? Những

điều gì chúng em phải tránh? Những điều gì người quản lí dự

án không bao giờ nên làm? Làm sao chúng em biết người quản

lí dự án giỏi từ người quản lí dự án "kém nhất"?"

Sau khi nghĩ một chốc, tôi đi tới một danh sách những

điều sẽ ĐẢM BẢO THẤT BẠI cho bất kì dự án phần mềm nào

và người quản lí dự án "kém nhất" sẽ làm gì:

1. Bỏ qua lập kế hoạch dự án: Lập kế hoạch dự án phần mềm

là khó. Nó cần nỗ lực để ước lượng nhiều điều trong khi

bạn có thể viết mã thay vào đó. Bên cạnh đó, mọi sự bao

giờ cũng thay đổi và bạn đằng nào cũng phải lập kế hoạch

lại. Sao phí thời gian vào lập kế hoạch dự án khi bạn có thể

viết mã và kết thúc dự án nhanh hơn.

2. Bỏ qua ước lượng: Ước lượng thời gian, công sức và chi

phí cho dự án phần mềm cần thời gian. Sao bận tâm làm nó

khi khách hàng đã cho bạn ngày cuối cùng phải chuyển

giao phần mềm. Cứ nhận ngày đó và lập kế hoạch mọi thứ

lùi lại từ ngày đó tới hôm nay và chuyển giao phần mềm rồi

bạn có kế hoạch dự án. Chừng nào ngày chuyển giao phần

64

mềm vẫn là cùng ngày khách hàng muốn thì bạn thành

công.

3. Bỏ qua gặp gỡ khách hàng: Khách hàng không biết họ

muốn gì, họ không hiểu phần mềm. Họ bao giờ cũng đòi

hỏi nhiều thứ và làm chậm dự án. Người quản lí dự án đã

có lịch biểu do khách hàng cho, nên tại sao phải gặp khách

hàng nữa? Bạn càng gặp họ, họ sẽ càng bảo bạn cách làm

việc của bạn và phí thời gian của bạn.

4. Bỏ qua xây dựng tổ: Bạn chưa bao giờ có đủ thời gian cho

dự án. Sao bận tâm tới luyện tập xây dựng tổ? Cứ chọn các

thành viên tổ là bạn bè của bạn, bạn biết họ rồi và họ biết

bạn cho nên mọi người có thể làm việc cùng nhau. Nếu bạn

của bạn có khó khăn thì thêm nhiều bạn nữa về sau bởi vì

bạn bè bao giờ cũng làm việc cùng nhau.

5. Bỏ qua đào tạo: Sao lo nghĩ về đào tạo dự án? Đằng nào thì

mọi người bao giờ cũng giúp đỡ lẫn nhau. Nếu người này

có khó khăn người khác sẽ giúp. Họ tất cả đều có bằng đại

học điều có nghĩa là họ có kĩ năng và không cần đào tạo

thêm. Đào tạo là tốn kém và lấy đi thời gian khỏi "công

việc thực". Chúng ta phải tiết kiệm tiền và kết thúc dự án.

6. Bỏ qua họp tổ: Họp tổ là phí thời gian, các thành viên tổ có

thể hỏi các câu hỏi mà bạn có thể không có khả năng trả

lời. Việc của tổ là viết mã, không phải hỏi các câu hỏi.

Người quản lí dự án phải không khuyến khích các thành

viên tổ hỏi câu hỏi. Không họp, tổ có nhiều thời gian hơn

để làm việc bởi vì việc của họ là làm việc, không làm bận

tâm người quản lí dự án.

7. Bỏ qua nghỉ giải lao: Phần lớn dự án phần mềm là khó và

yêu cầu giờ làm việc lâu. Việc của người quản lí dự án là

chắc chắn rằng tổ làm việc chăm chỉ. Không có thời gian để

phí hoài. Thời gian giải lao sẽ cho tổ thời gian để thảnh thơi

và không tập trung vào công việc. Mọi người có thể tán gẫu

về những điều không có liên quan tới dự án và quên mất

65

điều họ được cho là phải làm. Nghỉ cuối tuần cũng làm cho

tân trí họ xa khỏi dự án cho nên có thể cần buộc họ làm

việc cả ngày nghỉ cuối tuần để cho mọi sự được thực hiện

và là "người quản lí hiệu quả”.

8. Bỏ qua báo cáo với người quản lí: Tại sao bận tâm tới kiểm

tra tiến độ và báo cáo tình trạng dự án cho người quản lí

cấp cao? Đừng nói cho họ cái gì làm cho họ lo lắng. Người

quản lí cấp cao có nhiều thứ phải làm hơn là lo nghĩ về dự

án này. Điều đó không phải là việc của họ mà là của tôi. Cứ

bảo họ mọi sự đều tốt, chúng ta đang có tiến bộ thì họ sẽ

sung sướng. Đằng nào thì chẳng ai thích tin xấu cả.

9. Bỏ qua kiểm điểm với khách hàng: Khách hàng không nên

can thiệp vào dự án. Không có lí do gì để nói cho họ cái gì

chừng nào dự án còn chưa hoàn tất. Nếu họ hỏi, cứ bảo họ

mọi sự đều tốt. Người quản lí dự án giỏi nên dùng thời gian

để làm cho việc được thực hiện và không cho phép khách

hàng được tham gia vào. Họ phải "tin cậy" người quản lí dự

án làm "điều đúng" chứ.

10. Bỏ qua qui trình thay đổi: Kiểm soát thay đổi làm cho

khách hàng không hài lòng. Chúng ta nên cho phép khách

hàng thay đổi mọi lúc. Càng thay đổi nhiều, họ càng hài

lòng hơn và sự thoả mãn của khách hàng là "điều đúng" cần

làm. Chúng ta có thể khử bỏ quản lí cấu hình phần mềm và

tiết kiệm tiền cho dự án. Chúng ta nên khử bỏ ban thay đổi

và làm tài liệu thay đổi để giảm "quan liêu". Sau rốt chúng

ta nên làm kiểu "Agile- mau lẹ" hơn.

11. Bỏ qua kiểm điểm chất lượng: Chất lượng nên là một phần

của điều tổ làm. Đảm bảo chất lượng không tăng thêm giá

trị cho dự án, chúng làm cho người phát triển bị bận tâm và

làm chậm công việc dự án. Chúng ta không nên phí thời

gian vào kiểm điểm chất lượng. Nếu chúng ta bỏ qua kiểm

điểm chất lượng, chúng ta có thể tiết kiệm nhiều tiền. Nếu

phần mềm có lỗi, chúng ta có thể sửa chúng về sau.

66

12. Bỏ qua kiểm điểm nhân sự: Mọi người bao giờ cũng di

chuyển cho nên việc đổi cán bộ là chuyện bình thường. Nếu

thành viên tổ ra đi, cứ để họ đi và thuê người khác. Có

nhiều người cần việc làm. Không ai là "không thể thay

được”.

13. Bỏ qua quản lí rủi ro: Mọi thứ có thể xảy ra SẼ xảy ra. Tại

sao bận tâm về những điều bạn không thể kiểm soát được.

Không dự án nào là hoàn hảo, nếu nó xảy ra thế thì dự án sẽ

giải quyết nó. Nếu chúng ta không thể giải quyết được nó,

người quản lí cấp cao sẽ phải sửa nó. Đó là việc của họ. Dự

án phải không lo nghĩ quá nhiều về rủi ro.

14. Bỏ qua giám sát tiến độ: Nếu bạn KHÔNG kiểm tra tiến độ,

bạn không phát hiện ra rằng dự án bị trượt. Ít sức ép và ít

căng thẳng cho người quản lí dự án.

15. Bỏ qua lo nghĩ: Nếu dự án có vấn đề kĩ thuật, người quản lí

dự án có thể đổ cho người lãnh đạo kĩ thuật. Có thể việc sa

thải người lãnh đạo kĩ thuật sẽ làm cho tổ hoảng sợ và làm

việc cần mẫn hơn. Nếu dự án có nhiều lỗi, người quản lí dự

án phải trách những người phát triển và đe doạ họ bởi "sa

thải" thì họ sẽ phải sửa lỗi. "Người quản lí hiệu quả" nên có

khả năng làm điều đó.

16. Nếu dự án thất bại, có nhiều dự án khác. Vì tôi có quan hệ

với người chủ công ti, việc làm của tôi bao giờ cũng an

toàn.

Về căn bản, tuân theo “logic” trên tôi sẽ ĐẢM BẢO rằng

dự án phần mềm, hay bất kì dự án nào SẼ THẤT BẠI. Là một

qui tắc "thông minh", nếu bạn gặp kiểu người quản lí này,

chuẩn bị bản lí lịch của bạn nhanh chóng đi tìm việc làm khác

nếu không bạn sẽ học "THÓI QUEN XẤU". Bảo đảo đấy!

67

Người quản lí dự án giỏi nhất

Người quản lí dự án phần mềm giỏi nhất là những người

nhất quán chuyển giao dự án đúng thời gian, trong ngân sách,

và đáp ứng yêu cầu của khách hàng. Những người này tất cả

đều có vài đặc trưng chung:

Họ biết cách giảm nhẹ rủi ro bằng việc dự ứng trong

công việc hàng ngày. Họ dự kiến vấn đề và giải quyết chúng

trước khi các vấn đề này có thể gây nguy hiểm cho ngân sách

và lịch biểu dự án. Họ phân tích vấn đề một cách cẩn thận và

hành động ngay khi họ thấy cái gì đó có thể đi sai.

Họ biết cách tổ chức công việc của mình một cách có

phương pháp. Họ bao giờ cũng đặt viễn kiến cho dự án và có

khả năng duy trì hội tụ vào viễn kiến để ưu tiên hoá công việc

một cách tương ứng. Trong mọi dự án, có nhiều điều cần làm

và khó kiểm soát mọi thứ. Bằng việc có viễn kiến rõ ràng họ có

thể nhận diện nhiệm vụ nào là quan trọng hơn và lập ưu tiên

chúng cho tổ để cho họ có thể làm cho mọi thứ được thực hiện

theo cách có trật tự.

Họ biết cách trao đổi một cách có hiệu quả với mọi

người. Họ thường gặp gỡ khách hàng, người dùng, người quản

lí và tổ dự án riêng của họ để thông báo cho họ điều họ cần. Họ

biết cách thương lượng và thuyết phục khách hàng và người

quản lí. Họ biết cách lắng nghe người dùng để hiểu nhu cầu của

họ. Họ biết cách động viên các thành viên tổ, những người

đang làm công việc. Họ cũng có khả năng chứng tỏ tự tin của

họ với khách hàng và người quản lí trong các cuộc họp ngân

sách và lịch biểu.

Họ biết cách chia sẻ thông tin bằng việc dùng hiệu quả e-

mail, các cuộc họp và báo cáo tình trạng để chia sẻ ý tưởng của

họ, làm cho các quyết định được thực hiện và giải quyết vấn

đề. Họ cũng hiểu rằng họ cần thảo luận dự án của họ trong

68

hoàn cảnh của bất kì cái gì là quan trọng nhất cho người của

họ.

Họ dứt khoát khi họ dựa trên người khác để thành công.

Họ biết điều mọi người muốn và làm việc hướng tới lợi ích

chung. Họ hiểu mối quan tâm của khách hàng về dự án, và đề

cập tới chúng một cách tương ứng. Họ hiểu điều người quản lí

muốn và bảo đảm rằng công việc được thực thi hiệu quả và

hiệu lực nhất có thể được. Họ hiểu điều các thành viên tổ cần

và quản lí họ một cách công bằng và kiên nhẫn.

Họ là người thực chứng. Họ biết khi nào phải thay đổi để

làm cho sự việc được thực hiện với tài nguyên sẵn có và khi

nào vẫn còn lại với kế hoạch. Họ linh động về cái gì đó nhưng

kiên định về các nguyên tắc nào đó. Họ chịu trách nhiệm cho

hành động riêng của họ và sẵn lòng làm bất kì cái gì để làm cho

dự án tiến lên trước. Họ là người năng nổ và tận hưởng thách

thức của việc là người quản lí dự án phần mềm.

Chất lượng của người quản lí dự án

Tôi nhận được một email hỏi về điều tôi đã viết về người

quản lí dự án phần mềm. Người này đã viết “Người quản lí dự

án phải có kĩ thuật như thế nào? Em mới tốt nghiệp trong khoa

học máy tính và đã hoàn thành lớp quản lí dự án. Em có đủ

phẩm chất để làm việc như người quản lí dự án phần mềm

không? Nếu không thì tại sao?"

Câu trả lời của tôi là: Tôi không “định phẩm” mọi người

theo việc làm của họ, đó là việc của bất kì ai muốn thuê bạn.

Theo ý kiến tôi, bằng cấp về khoa học máy tính chỉ có nghĩa là

bạn có một số nền tảng kĩ thuật nhưng chưa có kinh nghiệm

làm việc nào, có thể ý tưởng tốt là bắt đầu việc làm đầu tiên

69

của bạn như người quản lí dự án phần mềm. Vấn đề KHÔNG

phải là về kiếm được việc của người quản lí mà là bạn CÓ THỂ

LÀM TỐT THẾ NÀO việc này.

Người quản lí dự án phần mềm phải biết cách lập kế

hoạch dự án, ước lượng nỗ lực và thời gian cần để hoàn thành

dự án. Kĩ năng này đòi hỏi nhiều thực hành và nhiều năm kinh

nghiệm. Người quản lí dự án phải hiểu cách khêu gợi yêu cầu

và kĩ thuật phân tích, kĩ năng này cũng yêu cầu nhiều thực

hành và kinh nghiệm. Cho dù tổ của bạn đang thu thập yêu cầu

cùng khách hàng, bạn vẫn phải biết rõ họ làm tốt việc đó thế

nào và họ ưu tiên hoá chúng thấu đáo đến đâu. Là người quản lí

dự án, bạn cần hiểu giải pháp kĩ thuật mà tổ của bạn sẽ dùng để

giải quyết vấn đề. Nếu bạn không biết kĩ thuật rất giỏi, làm sao

bạn biết rằng nó có thể giải quyết được vấn đề? Làm sao bạn có

thể biết khi nào vấn đề được giải quyết? Là người quản lí dự

án, bạn phải quen thuộc với kiến trúc hệ thống mà tổ của bạn

đang làm việc với, nếu bạn không biết kiết trúc rõ, bạn không

thể hiểu được các rủi ro kĩ thuật. Không biết về rủi ro, bạn

không thể ngăn ngừa chúng xảy ra. Quản lí dự án là quản lí rủi

ro, nếu bạn không thể làm giảm nhẹ rủi ro, bạn không thể quản

lí được dự án tốt. Là người quản lí dự án, bạn phải có tri thức

về thiết kế, nhưng không hiểu về kiến trúc, bạn thậm chí không

biết câu hỏi nào để hỏi về thiết kế. Không kiểm điểm thấu đáo

thiết kế, bạn không biết liệu tổ của bạn đã làm việc tốt trong

giải quyết vấn đề hay không. Cho nên mọi thứ có thể chấm dứt

trong viết mã, vì bạn có bằng khoa học máy tính, bạn biết cái gì

đó về viết mã nhưng nếu kiến trúc và thiết kế không thật tốt,

bạn có cho rằng viết mã có thể giải quyết được vấn đề không?

Về căn bản, người quản lí dự án phần mềm tốt phải hiểu

cách tổ thu thập và phân loại các yêu cầu; cách hỏi liệu thiết kế

đã được thực hiện chưa; cách đánh giá các rủi ro kĩ thuật cũng

như rủi ro lịch biểu; cách thiết lập hệ thống quản lí cấu hình để

quản lí thay đổi; cách đo hiệu quả chất lượng qui trình, chất

70

lượng sản phẩm; cách giám sát và theo dõi tiến độ. Người quản

lí dự án phải biết cách tiến hành kiểm điểm để đảm bảo chất

lượng của dự án. Có nhiều vấn đề kĩ thuật trong mọi dự án

phần mềm yêu cầu kĩ năng kĩ thuật mạnh và kinh nghiệm để

quản lí chúng. Bên cạnh đó, bạn phải chứng tỏ kĩ năng của

mình với tổ dự án. Họ tìm ở bạn việc cho họ chỉ đạo, lãnh đạo

họ và giúp họ hoàn thành công việc của họ tương ứng. Là

người lãnh đạo của họ, bạn phải có khả năng tổ chức mọi hoạt

động của dự án để cho chúng có thể xảy ra liên hoàn không

gián đoạn.

Là sinh viên mới tốt nghiệp, sao bạn cần vội làm gì? Bạn

có nhiều thời gian để học và bạn cần để thời gian giúp bạn xây

dựng kĩ năng và tri thức của mình. Tôi cho rằng bạn nên trở

thành người quản lí dự án "tốt nhất" trong năm năm kể từ bây

giờ hơn là trở thành người quản lí dự án “không thoả đáng”

hôm nay.

Kĩ năng của người quản lí dự án-1

Tôi nhận được một email người gửi viết: “Tôi thích bài

nói của thầy về phẩm chất người quản lí dự án nhưng thầy có

thể nói sâu thêm về loại kĩ năng nào người quản lí dự án phải

có không. Tôi đã làm việc như người phát triển phần mềm

trong ba năm và muốn biết kĩ năng nào hay môn học đào tạo

nào tôi cần trước khi xin việc làm người quản lí dự án phần

mềm.”

Câu trả lời của tôi là: “Không có cái thay thế cho kinh

nghiệm dự án, người quản lí dự án phần mềm phải có nhiều

năm làm việc như người phát triển phần mềm trước khi trở

thành người quản lí tốt. Theo ý kiến riêng của tôi, ba năm có

thể KHÔNG đủ để có phẩm chất là người quản lí dự án phần

71

mềm "tốt". Để bắt đầu, tôi gợi ý rằng bạn nên học đào tạo trong

các khu vực sau:

1) Quản lí dự án phần mềm.

2) Kĩ thuật ước lượng phần mềm.

3) Quản lí rủi ro.

4) Kĩ nghệ yêu cầu.

5) Giám định chính thức và kiểm điểm ngang quyền.

6) Kĩ năng mềm (kĩ năng con người, kĩ năng trao đổi, kĩ

năng trình bày, kĩ năng viết v.v).

7) Kĩ năng thương lượng và quản lí hợp đồng.

Bạn sẽ cần các kĩ năng đặc biệt sau (tri thức cùng kinh

nghiệm) để thực hiện việc quản lí hiệu quả:

1) Kĩ năng trong kĩ thuật quyết định. Không phải tất cả các dự

án đều như nhau, tuỳ theo kích cỡ, độ phức tạp và khu vực

miền ứng dụng, bạn có thể chọn các kĩ thuật ước lượng

khác nhau. Phẩm chất tối thiểu: Bạn phải biết vài kĩ thuật

ước lượng và thực hiện từng kĩ thuật ít nhất một lần.

2) Kĩ năng trong vòng đời phát triển (Thác đổ, xoáy ốc, và

Agile v..) Tuỳ theo kiểu dự án bạn sẽ chọn các vòng đời

khác nhau. Phẩm chất tối thiểu: Bạn phải có kinh nghiệm

với từng vòng đời ít nhất một lần.

3) Kĩ năng lập kế hoạch dự án. Phẩm chất tối thiểu: Bạn phải

có kinh nghiệm trong việc viết ít nhất ba kế hoạch dự án

cho các kiểu dự án khác nhau (như, nhỏ, vừa và lớn).

4) Kĩ năng trong quản lí rủi ro: Bạn phải biết cách nhận diện

rủi ro dự án, tính xác suất xuất hiện, và biết cách theo dõi

và giảm nhẹ rủi ro. Phẩm chất tối thiểu: Bạn phải làm việc

như người lãnh đạo tổ rủi ro trợ giúp cho người quản lí dự

án trong theo dõi và giảm nhẹ rủi ro ít nhất trong một dự

án.

72

5) Kĩ năng trong quản lí thay đổi và quản lí cấu hình: Bạn phải

biết cách kiểm soát và quản lí các thay đổi. Phẩm chất tối

thiểu: Thực hiện các hoạt động quản lí cấu hình trong ít

nhất hai dự án. Thực hiện kiểm soát thay đổi trong ít nhất

ba dự án.

6) Kĩ năng trong giữ cân bằng tài nguyên, lịch biểu và chất

lượng: Bạn phải biết cách điều chỉnh và tiến hành bù trừ

trên ba góc nhìn này để giữ cho dự án còn ổn định. Phẩm

chất tối thiểu: Hỗ trợ người quản lí dự án như một phụ tá

trong ít nhất một dự án.

7) Kĩ năng trong giám sát và theo dõi tiến độ: Biết một số

phương pháp theo dõi như Quản lí giá trị thu được, theo dõi

tiến độ, v.v. Phẩm chất tối thiểu: Làm việc như phụ tá cho

người quản lí dự án trên ít nhất một dự án.

8) Kĩ năng trong tuyển cán bộ và lập ngân sách: Bạn phải có

kinh nghiệm trong nhận diện và thu nhận tài nguyên nhân

lực (cán bộ) và ngân sách (tài chính) trong ít nhất một dự

án. Phẩm chất tối thiểu: Hành động như người phụ tá cho

người quản lí dự án trong ít nhất một dự án.

9) Kĩ năng trong ra quyết định, kể cả cộng tác, kèm cặp và

huấn luyện. Phẩm chất tối thiểu: Bạn phải làm việc như

một phụ tá cho người quản lí dự án trong ít nhất một dự án.

Bên cạnh những đào tạo và kĩ năng này, bạn phải có cả kĩ

năng viết và nói nữa.

Như bạn có thể thấy rằng phải mất thời gian và kinh

nghiệm để trở thành người quản lí dự án "giỏi nhất". Thực tế,

tôi viết các yêu cầu này dựa trên nhiều "mô tả việc" cho người

quản lí dự án phần mềm trong công nghiệp phần mềm và sửa

đổi nó cho người phát triển như bạn. Tôi muốn thấy rằng bạn

trở thành người quản lí dự án phần mềm "GIỎI NHẤT" thay gì

chỉ là người quản lí dự án "TRUNG BÌNH”.

73

Theo ý kiến tôi, người quản lí dự án là vai trò tới cùng

với nhiều trách nhiệm và công việc khó khăn cho nên xin xem

xét nó một cách nghiêm chỉnh. Bạn đừng bao giờ lẫn lộn "vai

trò" và "chức danh”. Ba năm trong phát triển phần mềm có thể

KHÔNG đủ, bạn vẫn cần thêm vài năm nữa để học thêm nhiều

thứ để là người quản lí phần mềm "GIỎI NHẤT” cho nên xin

tiếp tục học tập rồi cơ hội của bạn sẽ tới khi bạn đã sẵn sàng.

Kĩ năng của người quản lí dự án-2

Bởi vì công nghệ thay đổi rất nhanh chóng, các nhà

chuyên nghiệp phần mềm muốn thành công phải liên tục cải

tiến kĩ năng của họ. Trong số họ, người quản lí dự án phần

mềm cần đào tạo thích hợp hơn vì dự án phần mềm đang trở

nên ngày càng lớn và phức tạp hơn. Mục đích của mọi dự án

phần mềm là chuyển giao sản phẩm đúng thời gian, trong ngân

sách, đáp ứng các chức năng được yêu cầu và chất lượng như

được khách hàng xác định.

Người quản lí dự án phần mềm phải biết cách làm việc

với khách hàng để hiểu nhu cầu doanh nghiệp của họ; họ phải

có kĩ năng trong phát triển kế hoạch dự án và phân công gói

công việc cho các thành viên tổ. Họ phải có kĩ năng trao đổi để

thảo luận, giải thích và báo cáo trạng thái cho khách hàng,

người quản lí. Họ phải biết cách quản lí các hoạt động hàng

ngày, theo dõi tiến bộ, giám sát hiệu năng, và giải quyết với các

rủi ro dự án. Có nhiều điều mà người quản lí dự án phần mềm

phải học để đảm bảo rằng dự án sẽ thành công.

Điều thứ nhất người quản lí dự án phần mềm phải học là

cách làm việc với khách hàng. Có nhiều kiểu khách hàng: Một

số người dễ làm việc với khách hàng và một số thì không. Một

số không biết cách giải thích rõ các yêu cầu và một số thậm chí

74

còn không biết họ muốn gì. Không hiểu rõ ràng các yêu cầu, sẽ

không thể nào bắt đầu được dự án. Đó là lí do tại sao người

quản lí dự án phần mềm phải có kĩ năng trao đổi tốt như nghe

tích cực và biết cách hỏi các câu hỏi để thu được yêu cầu. Có

vài kĩ thuật để làm điều này như đề nghị khách hàng kể chuyện

về cách họ muốn dùng hệ thống (như, chuyện người dùng, kịch

bản người dùng v.v.). Kĩ thuật khác là xây dựng bản mẫu và để

khách hàng dùng nó và đưa ra phản hồi để thu được yêu cầu

đúng v.v.

Điều thứ hai người quản lí phần mềm phải học là giải

quyết với thay đổi. Vì khách hàng thường yêu cầu thay đổi,

người quản lí dự án phần mềm phải biết cách giải quyết nó một

cách thích hợp. Người quản lí không có kinh nghiệm sẽ chấp

nhận mọi thay đổi và chịu hậu quả về chi phí cao, trễ lịch và

sản phẩm chất lượng kém.

Người quản lí dự án phần mềm có kinh nghiệm sẽ thương

lượng thay đổi bằng việc cho khách hàng thông tin phụ về tác

động của thay đổi và để cho họ quyết định. Tôi thường khuyên

sinh viên đáp ứng: “Chúng tôi có thể làm thay đổi đó nhưng

chúng tôi cần ông hoặc để trễ thay đổi tới lần đưa ra sau; hoặc

cho chúng tôi nhiều thời gian hơn, nhiều tài nguyên hơn để

thực hiện thay đổi. Ông có thể cần xoá bớt yêu cầu tương

đương khác để chúng tôi có thể hội tụ vào thay đổi mới. Chúng

tôi cần quyết định của ông sớm để cho chúng tôi có thể bắt đầu

ngay. Ông có thể cho chúng tôi quyết định của ông vào ngày

hôm sau được không?” Câu trả lời đơn giản đó sẽ buộc khách

hàng phải nghĩ về tác động và việc bù trừ vì họ phải quyết

định. Phần lớn các lần, họ bỏ các yêu cầu thay đổi vì họ không

muốn ra quyết định khó khăn.

Điều thứ ba người quản lí phần mềm phải học là kĩ năng

xây dựng tổ, bao gồm cách phát triển tổ có động cơ mà sẽ làm

việc hợp tác với nhau. Có một tổ mạnh và có quyết tâm sẽ cho

75

người quản lí dự án phần mềm tin tưởng bám theo kế hoạch khi

kế hoạch là đúng, thay đổi kế hoạch khi nó sai; và được chuẩn

bị để ra quyết định đúng khi cần. Điều đó yêu cầu khả năng

lãnh đạo của người quản lí dự án phần mềm để hướng dẫn tổ

hoàn thành mục đích dự án. Không có làm việc tổ và hợp tác

bởi cả tổ hay từng thành viên trong tổ, dự án không thể thành

công. Người quản lí dự án phần mềm thiếu kinh nghiệm

thường bắt đầu dự án bằng cách tự mình làm việc trên bản kế

hoạch rồi phân công nhiệm vụ cho các thành viên tổ và giám

sát tiến bộ của tổ. Người quản lí dự án phần mềm có kinh

nghiệm bao giờ cũng bắt đầu với việc xây dựng tổ bằng việc

đem tổ tới cùng nhau thảo luận về mục tiêu của dự án. Khi mọi

người trong tổ cảm thấy thoải mái với các mục tiêu thì người

quản lí có thể thảo luận với tổ về cách tiếp cận tốt nhất cho dự

án. Bằng việc để cho các thành viên tổ tham gia vào trong việc

ra quyết định, tổ cảm thấy rằng họ được cam kết với dự án; họ

cảm thấy rằng đây là dự án của họ, không phải là dự án của

người quản lí. Bằng việc có thảo luận dự án sớm, người quản lí

dự án phần mềm tìm vài giải pháp trước khi lựa chọn giải pháp

tốt nhất. Thông tin được thảo luận cùng tổ bao giờ cũng dẫn tới

quyết định tốt hơn và phân công tổ tốt hơn.

Bởi vì hoạt động lập kế hoạch dự án dựa trên quyết định

tập thể, tổ cảm thấy rằng họ tham gia vào lập kế hoạch của dự

án. Bằng việc cho phép các thành viên tổ nói lên ý kiến của họ,

bằng việc để họ giúp phát triển bản kế hoạch, bằng việc để họ

ước lượng công việc mà họ phải làm, dự án có công việc tổ

được cam kết, điều đưa tổ vượt qua các khác biệt cá nhân và cố

gắng vì thành công của dự án.

Vài năm trước, một sinh viên viết cho tôi: “Khi tôi học

lớp quản lí dự án phần mềm của thầy, tôi tự hỏi mình: “Sao

mình cần học môn này? Có lẽ mình chẳng bao giờ dùng nó vì

mình chỉ muốn viết mã, không muốn quản lí dự án.” Say khi

tốt nghiệp, tôi đã làm việc như người phát triển phần mềm

76

trong ba năm rồi được đề bạt làm người quản lí dự án phần

mềm. Vào lúc đó, thái độ của tôi thay đổi và tôi muốn chức vụ

đó. Đột nhiên tôi nhận ra rằng tôi đã không biết cách quản lí dự

án vì tôi đã không chú ý mấy trong lớp. May mắn là tôi vẫn còn

tài liệu lớp của thầy, bộ slide bài giảng của thầy và phân công

đọc thêm. Tôi để ra hai tuần ôn tập lại mọi thứ rồi áp dụng vào

dự án. Bởi vì nó là dự án nhỏ, mặc dù tôi phạm phải vài sai lầm

nhưng chúng không mấu chốt. Dự án hoàn thành thành công.

Tôi trở lại và ôn lại tài liệu của thầy lần nữa và thấy rằng hầu

hết các sai lầm tôi phạm phải đều đã được nhắc tới ở đó cho

nên tôi học cách cải tiến kĩ năng của tôi. Bây giờ sau vài dự án

thành công, tôi biết giáo dục đại có có giá trị làm sao đối với

tôi. Tôi muốn nói với mọi sinh viên rằng không cái gì các bạn

học là phí hoài cả; sớm hay muộn bạn sẽ cần nó. Học tập chăm

chỉ và giữ tài liệu trường học của bạn vì bạn chưa bao giờ biết

khi nào bạn sẽ cần chúng.”

Có kĩ năng để làm việc với khách hàng, giải quyết với

các thay đổi và xây dựng tổ mạnh là các kĩ năng nền tảng mà

mọi người quản lí dự án phần mềm phải có để quản lí thành

công dự án phần mềm.

Lời khuyên cho người quản lí dự án-1

Sau đây là đối thoại giữa người quản lí cấp cao (SM)

người đưa ra lời khuyên cho người quản lí dự án phần mềm

(PM)

SM: Anh có biết cách giữ việc làm của mình trong cuộc

khủng hoảng tài chính này khi nhiều công ti đang giảm người

không?

77

PM: Ông chủ của tôi sẽ giữ tôi nếu dự án của tôi có tác

dụng tốt. Tuy nhiên tôi không biết tại sao một số dự án thành

công và số khác thất bại. Tôi đoán đó là vấn đề may mắn. Nếu

tôi may, tôi có thể giữ được việc của mình.

SM: Các dự án hầu hết thất bại là do thiếu lập kế hoạch

và quản lí chứ không phải là do may mắn. Phần lớn mọi người

bỏ qua việc lập kế hoạch và nhảy vào viết mã cứ nghĩ rằng họ

sẽ làm tốt bởi vì họ tin "phần mềm là mã”. Nhiều người thậm

chí không để thời gian xác định họ phải giải quyết vấn đề gì.

Anh không thể dựa vào may mắn để giữ việc của mình được.

PM: Vậy tôi phải làm gì để đảm bảo dự án thành công?

SM: Có qui trình phần mềm mà mọi người quản lí phần

mềm phải tuân theo. Viết mã là điều dễ làm nhất vì hầu hết mọi

người đều được đào tạo viết mã nhưng không được đào tạo về

qui trình phần mềm. Công việc phần mềm còn nhiều hơn viết

mã; thực tế pha viết mã chỉ chiếm khoảng 20% của tổng công

sức. Đừng phạm phải sai lầm như người khác bằng việc để quá

nhiều công sức vào viết mã; điều đó sẽ làm phí thời gian của

bạn, để lại cho bạn nhiều vấn đề.

PM: Qui trình phần mềm là gì?

SM: Qui trình phần mềm là tập các bước bạn phải tuân

theo. Là người quản lí dự án bạn cần:

Đánh giá nhu cầu nghiệp vụ của khách hàng.

Xác định các yêu cầu và trắc nghiệm với khách hàng

và người dùng.

Xây dựng tổ dự án tốt.

Nhận diện qui trình chuẩn và cách đo phần mềm.

Tạo ra bản kế hoạch dự án với các ước lượng.

Thương lượng với khách hàng

Đào tạo tổ dự án và quản lí họ tương ứng.

78

PM: Anh ngụ ý gì bởi "đánh giá nhu cầu nghiệp vụ của

khách hàng"?

SM: Để bắt đầu, bạn cần nhìn vào nhu cầu nghiệp vụ của

khách hàng. Dự án chỉ thành công khi nhu cầu của khách hàng

và người dùng được đáp ứng. Đây là điều quan trọng nhất cho

các dự án của bạn bởi vì nhu cầu của họ chỉ đạo quá trình phát

triển của bạn sẽ là cái gì. Bạn phải hiểu vấn đề của họ trước khi

bạn có thể đi tới giải pháp. Bên cạnh đó, bạn cần biết khách

hàng của mình (người trả tiền cho sản phẩm) và người dùng

(người dùng sản phẩm) và thảo luận mọi điều với họ, xây dựng

mối quan hệ với họ và để họ biết rằng bạn ở đó để hỗ trợ cho

họ. Bạn phải nhớ rằng họ là người chung cuộc sẽ trả tiền cho

công sức của bạn và hỗ trợ bạn nếu mọi sự không trôi chảy.

PM: Vâng. Giả sử tôi có quan hệ tốt với họ và hiểu nhu

cầu của họ, tiếp đó là gì?

SM: Xác định yêu cầu cho dự án. Cái vào cho qui trình

này nên tới từ khách hàng, người dùng, người phân tích hệ

thống và người quản lí. Bắt đầu bằng việc hiểu đầy đủ mọi điều

bạn phải làm kể cả những điều bạn phải chuyển giao cho họ.

Nhiều người nghĩ chuyển giao duy nhất là sản phẩm phần mềm

hay mã. Điều đó là không đúng, có nhiều điều hơn như tài liệu

yêu cầu, tài liệu kiến trúc, tài liệu giao diện người dùng, tài liệu

thiết kế, trường hợp kiểm thử v.v. Tất cả những điều này yêu

cầu nhiều công việc cho nên điều tốt nhất cần làm là hỏi khách

hàng của bạn những thứ gì họ cần và họ mong đợi chúng khi

nào? Trao đổi là mấu chốt trong pha sớm của dự án. Đây là chỗ

bạn phải dành ít nhất 20% nỗ lực để có được yêu cầu đúng.

PM: Anh có cho rằng 20% là quá nhiều không. Nó gần

như bằng công sức viết mã.

79

SM: Tôi muốn dành nhiều thời gian cho pha yêu cầu hơn

bất kì pha nào khác. Yêu cầu chỉ đạo mọi thứ, yêu cầu sai

nghĩa là thất bại dự án. Đây là lúc bạn phải đầu tư nhiều công

sức để hiểu điều khách hàng muốn và điều họ mong đợi.

Không nắm được yêu cầu là nhân tố thông thường nhất trong

thất bại dự án. Phần lớn mọi người dành ít hơn 5% công sức

trong yêu cầu nhưng lại nhiều hơn 50% công sức cho viết mã

và đó là lí do tại sao nhiều dự án thế đã thất bại. Nếu họ không

hiểu yêu cầu, họ sẽ xây dựng sản phẩm sai và rồi phải sửa nó

với chi phí tốn hơn và làm cho khách hàng rất bực bởi vì họ

không có được cái họ muốn theo cách đúng hạn.

PM: Vâng, tôi nghĩ tôi hiểu quan điểm của anh vậy thì

cái gì tiếp?

SM: Bước tiếp là xây dựng tổ dự án tốt. Tôi thích việc

“Xây dựng” và bởi vì phải mất thời gian xây dựng tổ tốt. Bạn

phải hiểu tri thức và kĩ năng của tổ mình để cho bạn có phân

công công việc tương ứng cho họ. Bạn cần xây dựng tổ tốt với

các vai trò và trách nhiệm được xác định rõ ràng để cho mọi

người đều đảm nhiệm. Luôn lưu tâm, mọi dự án mới đều là cơ

hội mới để cải tiến mọi thứ và bao giờ cũng có cơ hội thành

công tốt hơn khi mọi người hiểu điều họ được giả định sẽ làm.

PM: Điều đó toàn là tốt thôi, nhưng làm sao anh tìm ra

thời gian để hoàn thành tất cả những điều này? Tôi chỉ là một

người và với đủ mọi thứ hiện tại đã làm tôi bận bịu hết thời

gian rồi.

SM: Xây dựng tổ dự án tốt là nhân tố then chốt cho thành

công dự án. Lựa đúng người thông thạo và có tâm trí đủ cởi mở

để làm việc cùng nhau bao giờ cũng là thách thức nhưng đó là

việc của người quản lí dự án và bạn phải lựa chọn cẩn thận.

Mọi người trong tổ phải có năng lực kĩ thuật, kiên nhẫn, có kĩ

năng làm việc tổ tốt, và có đủ kinh nghiệm để vận hành thành

80

công. Bên cạnh những trách nhiệm trên, tổ này sẽ thực hiện các

nghĩa vụ sau:

Hiểu nhu cầu của khách hàng.

Thiết lập mục đích, chiến lược và kế hoạch hành

động.

Cung cấp ước lượng chi phí cho nhiệm vụ của họ.

Đào tạo và hỗ trợ người khác.

Cải tiến qui trình của họ bằng việc dùng các điều tra

thoả mãn của khách hàng.

Bên cạnh tri thức chuyên gia của họ, bạn cần hỗ trợ và

cam kết của họ để giúp bạn trong kiểm nghiệm yêu cầu. Tôi sẽ

dành nhiều công sức vào việc xây dựng tổ bởi vì tổ tốt nghĩa là

bạn có cơ hội thành công tốt hơn.

PM: Anh nhắc tới "Nhận diện qui trình chuẩn và độ đo.”

Chúng ta làm điều đó thế nào?

SM: Bạn phải nhận diện qui trình chuẩn mà tổ của bạn

phải tuân theo và tập các độ đo phần mềm. Qui trình chuẩn phụ

thuộc vào yêu cầu của khách hàng dù chúng được xác định tốt

và được làm tài liệu hay chúng vẫn còn thay đổi, cho nên bạn

có thể lựa các phương pháp và qui trình thích hợp tương ứng.

Bạn có thể lựa vòng đời thác đổ, vòng đời gia tăng đưa ra, hay

bạn có thể muốn lựa phương pháp mau lẹ. Từng vòng đời đều

yêu cầu qui trình khác nhau. Là người quản lí dự án, bạn phải

biết bạn đang ở đâu và bạn đang làm tốt đến đâu trong toàn bộ

qui trình. Bạn phải chứng tỏ được quyền lãnh đạo và kĩ năng

quản lí của mình cho ông chủ của mình để họ biết họ sẽ thu

được gì với tiền họ bỏ ra. Để có an ninh nghề nghiệp của bạn,

bạn cần độ đo để chứng minh cho cấp quản lí rằng bạn đang

quản lí dự án và có dữ liệu để chứng minh về nó. Độ đo giúp

bạn tìm cái gì sai và cách sửa nó. Để tôi cho bạn một ví dụ, thử

81

nghĩ về dự án phần mềm như bệnh nhân ở bệnh viện. Không

bác sĩ nào sẽ chữa cho bệnh nhân mà không biết mọi triệu

chứng. Tương tự vậy, làm sao bạn quản lí được dự án mà

không biết các vấn đề của dự án? Độ đo thu thập dữ liệu cho

bạn vì bạn cần biết tình trạng của dự án để có hành động sửa

chữa. Tuy nhiên, độ đo phải không có tính đe doạ cho tổ. Đừng

dùng chúng để đánh giá, phán xét cá nhân; chỉ dùng độ đo cho

cải tiến qui trình và giám sát liên tục dự án của bạn. Bằng

không, tổ chỉ báo cáo điều họ nghĩ bạn muốn thấy và điều đó là

vô dụng. Bạn phải yêu cầu dữ liệu trung thực, chính xác, và

nhất quán từ tổ.

PM: Tổ chức của tôi có nhiều vấn đề phần mềm mà có lẽ

có thể có lợi từ độ đo. Nhưng làm sao tôi yêu cầu họ ước lượng

và thu thập dữ liệu khi họ rất bận rộn làm việc cho dự án? Ông

chủ của tôi nhấn mạnh vào việc dự án phải làm đúng thời gian

và trong phạm vi ngân sách nào đó.

SM: Làm sao bạn biết lịch biểu đã cho là đúng nếu bạn

không ước lượng công việc của bạn? Là người quản lí dự án,

bạn phải chia nhỏ các yêu cầu thành nhiều nhiệm vụ và phân

công chúng cho thành viên tổ. Từng thành viên đều phải ước

lượng sẽ mất bao lâu thời gian để hoàn thành nhiệm vụ được

phân công và báo cáo cho bạn. Bạn có thể tổ hợp tất cả những

ước lượng này vào trong ước lượng lịch biểu dự án và so sánh

với lịch biểu đã cho. Nếu ước lượng của bạn sánh đúng với lịch

biểu đã cho, thế thì nó là hoàn hảo nhưng phần lớn thời gian

chúng lại không sánh đúng cho nên bạn phải thương lượng với

người quản lí và khách hàng của mình về ngày giao hàng.

PM: Anh nói về loại thương lượng nào vậy?

SM: Bằng việc biết dự án phải chuyển giao cái gì cho

khách hàng và nhu cầu nào cần được thực hiện, kể cả về

khoảng thời gian cần để hoàn thành mọi nhiệm vụ, bạn có thể

xác định được liệu bạn có thể đáp ứng ngày chuyển giao của

82

khách hàng hay không. Nếu có khác biệt lớn thì bạn phải

thương lượng về ngày chuyển giao với khách hàng bằng hoặc

là yêu cầu thêm thời gian, thêm tài nguyên hay thay đổi khối

lượng công việc của dự án. Thương lượng là kĩ năng quan

trọng cho mọi người quản lí dự án, điều không được dạy trong

hầu hết các môn học kĩ thuật nhưng lại là kĩ năng bản chất của

mọi người quản lí dự án. Bạn phải hiểu rằng phần lớn khách

hàng chỉ đoán chừng ngày giao hàng vì họ không biết đích xác

sẽ mất bao lâu cho nên họ lựa ngày xấp xỉ cho tiện. Đây là cơ

hội cho bạn giải thích cho họ cách bạn đi tới thời gian được yêu

cầu dựa trên ước lượng của bạn và đạt tới thoả thuận lẫn nhau

về ngày chuyển giao cuối cùng. Tuy nhiên, với một số khách

hàng, ngày chuyển giao là quan trọng nhất vì nó có liên quan

tới các doanh nghiệp khác cho nên điều mấu chốt là khách

hàng và người quản lí dự án đồng ý về ngày tháng hợp lí cho cả

hai bên. Bởi vì hầu hết khách hàng không hiểu về phần mềm và

hoạt động dự án, họ có mong đợi cao cho nên điều quan trọng

là có nhiều cuộc họp để thảo luận về điều có thể được làm và

điều không thể được làm. Là người quản lí dự án, bạn không

muốn lâm vào những tình huống mà nhu cầu và mong đợi

không sánh đúng. Chẳng hạn, khách hàng nghĩ tổ có thể làm dự

án trong 6 tháng khi dự án có thể mất cả năm cho nên kĩ năng

trao đổi và thương lượng là cực kì quan trọng.

SM: Thương lượng là kĩ năng quan trọng nhất của người

quản lí phần mềm. Nhưng không may, rất ít chương trình đào

tạo cung cấp loại đào tạo này. Trong thương lượng, có ba nhân

tố người quản lí dự án nên thảo luận: Khối lượng công việc

(Chức năng hay phạm vi), tài nguyên (người) và lịch biểu

(Ngày tháng). Nếu ước lượng lịch biểu của bạn và ngày chuyển

giao của khách hàng không sánh đúng, bạn có thể yêu cầu

khách hàng cho bạn thêm thời gian bằng việc thay đổi ngày

chuyển giao. Bạn có thể thương lượng lấy thêm người cho dự

án và bạn phải làm điều này từ lúc bắt đầu dự án. Nhiều người

83

có kĩ năng đúng có thể tăng tốc cho dự án, nhiều người có thể

làm giảm tải việc của thành viên tổ. Tuy nhiên, thêm nhiều

người vào giữa chừng dự án khi mọi sự không làm việc tốt có

thể là thảm hoạ. Nhiều người sẽ làm vỡ công việc dự án, điều

đã bị căng thẳng rồi. Nhiều người hơn nghĩa là nhiều trao đổi

hơn và làm tăng độ phức tạp của tính động của tổ. Người mới

không quen thuộc với công việc dự án cần thời gian để học,

điều đó có nghĩa là những người đang làm việc phải dành thời

gian đào tạo người mới và mất thời gian quí giá của họ dành

cho công việc của họ. Vì các nhiệm vụ trong dự án phần mềm

thường sẽ phụ thuộc vào nhiệm vụ của người khác, thất bại của

một người có thể làm thiệt hại lớn cho tiến triển dự án. Qui tắc

của tôi là không bao giờ thêm người giữa chừng dự án đặc biệt

khi dự án đang bị trục trặc.

PM: Điều đó là thú vị đấy. Phần lớn những người quản lí

sẽ thêm người cho dự án khi mọi sự không trôi chảy. Anh nói

điều đối lập.

SM: Đó là lí do tại sao nhiều dự án phần mềm thất bại.

Dường như là những người quản lí này không có kinh nghiệm

trong quản lí dự án phần mềm. Dự án phần mềm KHÔNG phải

là dự án xây dựng. Trong dự án xây dựng như xây nhà, thêm

nhiều người sẽ giúp tăng tốc nó nhưng trong dự án phần mềm

điều đó sẽ KHÔNG giúp gì mà tạo ra thêm vấn đề. Từ kinh

nghiệm của tôi, điều quan trọng là thương lượng về người phụ

ngay từ đầu dự án khi bạn cần đáp ứng lịch biểu của khách

hàng.

PM: Vâng, vậy người quản lí dự án có thể thương lượng

cái gì khác nữa?

SM: Người quản lí dự án cũng có thể yêu cầu giảm khối

lượng công việc (chức năng) bởi vì ít việc hơn nghĩa là bạn có

thể hoàn thành các yêu cầu trong thời gian cho phép để dự án

có thể được hoàn thành thành công như mong đợi. Tuy nhiên,

84

nếu sản phẩm phần mềm không có tất cả chức năng như được

yêu cầu, người dùng có thể không hài lòng. Cách tốt nhất là hỏi

người dùng mức ưu tiên để xác định chức năng nào bạn có thể

làm trước và cái nào có thể để trễ vào thời gian muộn hơn bằng

việc dùng cách tiếp cận đưa ra dần dần. Ngày nay, phần lớn

phần mềm đều lớn và phức tạp nên rất khó làm mọi thứ ngay

một lúc cho nên điều quan trọng là xây dựng phần mềm theo

các bước tăng nhỏ. Bạn cần làm việc chặt chẽ với khách hàng

để có được ưu tiên của họ và chốt cứng yêu cầu cho từng bước

trước khi bắt đầu thiết kế. Đây là chỗ phương pháp mau lẹ rất

phù hợp cho việc quản lí dự án tốt hơn. Bạn chia dự án lớn

thành nhiều mảnh nhỏ và thực hiện từng mảnh như một dự án

nhỏ. Khi cả hai bên có thoả thuận vững chắc về lịch chuyển

giao thì người quản lí dự án có thể bắt đầu phân công cho các

thành viên tổ theo vai trò và trách nhiệm của họ. Trong dự án

phần mềm, không ai làm việc một mình mà bao giờ cũng trong

tổ. Công việc tổ KHÔNG phải là nhóm người làm việc trong

cô lập, mỗi người làm việc riêng của mình mà là nỗ lực hợp tác

của tất cả thành viên của tổ để đạt tới mục đích chung. Đây là

chỗ việc xây dựng tổ là bản chất; người quản lí dự án phải trao

đổi và cung cấp sự lãnh đạo trong việc xây dựng tổ.

PM: Đó là đòi hỏi quá nhiều với người quản lí dự án.

SM: Bạn nghĩ người quản lí dự án phần mềm thành công

phải làm gì? Họ phải dựa vào may mắn hay kĩ năng của mình?

Bạn có muốn tăng cơ hội thành công và giữ việc của mình hay

để mọi sự xảy ra cho bạn? Quản lí dự án là kĩ năng cần được

đào tạo để có tri thức cơ bản rồi áp dụng nó vào dự án thực để

cải tiến kĩ năng của bạn. Không may, ngày nay nhiều công ti bổ

nhiệm người kĩ thuật giỏi vào làm người quản lí dự án mà

không có đào tạo nào. Đây là sai lầm lớn vì nhiều người sẽ thất

bại và họ mất người kĩ thuật giỏi và thu được người quản lí tồi.

Nếu bạn muốn thành công, bạn phải đào tạo người quản lí dự

án phần mềm. Có đào tạo về quản lí dự án nhưng nhiều người

85

KHÔNG được đào tạo về quản lí dự án phần mềm cho nên bạn

phải phân biệt họ. Phần mềm là duy nhất và yêu cầu giảng viên

có nhiều kinh nghiệm, không có kinh nghiệm tất cả mọi điều

bạn thu được là mớ lí thuyết mà có thể chẳng ích gì cho nghề

nghiệp của bạn. Xây dựng tổ và thương lượng là hai kĩ năng

nhưng có nhiều kĩ năng nữa như trao đổi. Để đảm bảo tổ hiểu

yêu cầu và mục đích, người quản lí dự án phải thường xuyên

trao đổi với tổ. Trao đổi là theo cả hai chiều cho nên tổ cũng

phải để người quản lí dự án biết mọi điều về nhiệm vụ của họ

và ý kiến của họ. Điều quan trọng là có báo cáo tiến độ hàng

tuần mô tả cách dự án đang thực hiện, và nhiệm vụ nào đã

được đạt tới.

PM: Đó là nhiều thứ và nhiều dữ liệu tôi phải thu thập.

SM: Có các công cụ giúp bạn thu thập dữ liệu phân tích

về dự án của bạn. Các công cụ này sẽ giúp bạn phân tích độ

phức tạp của phần mềm, kiểm trạng thái dự án, đánh giá tác

động của thay đổi đã cho, và nhận diện vi phạm chuẩn. Dữ liệu

này sẽ giúp bạn trong pha kiểm nghiệm và cung cấp dữ liệu

khách quan cho quản lí dự án phần mềm. Người quản lí phần

mềm tốt phải biết các công cụ này và nếu cần thì học một một

học ngắn về cách dùng các công cụ này.

PM: Nhưng điều gì xảy ra nếu tôi có thể tìm ra một công

cụ đích xác khớp với mọi yêu cầu của tôi?

SM: Có thể không có công cụ thoả mãn cho mọi thứ. Bạn

phải xác định qui trình chuẩn cho phần mềm và lập kế hoạch về

cách các công cụ này có thể khớp với từng qui trình cũng như

điều gì cần được thực hiện trong từng pha như kiến trúc, thiết

kế, kiểm nghiệm, tích hợp, đào tạo v.v. Có các công cụ cho

từng pha như công cụ kiến trúc, công cụ thiết kế, và công cụ để

thu thập độ đo, công cụ để kiểm thử cho nên bạn phải quyết

định bạn muốn mua cái nào. Chính tại điểm này bạn phải ra

quyết định cơ bản liên quan tới dự án của mình và bạn cần bao

86

nhiêu công cụ bởi vì bạn sẽ cần làm ngân sách cho chúng. Đó

là lí do tại sao người quản lí phần mềm cũng cần hiểu về tài

chính và làm ngân sách và những điều này cũng phải được dạy

trong môn học quản lí dự án phần mềm.

PM: Tại sao người kĩ thuật cần biết qui trình doanh

nghiệp như tài chính và làm ngân sách?

SM: Bạn là người quản lí dự án và đó là việc của người

quản lí. Ai khác sẽ làm điều đó cho bạn? Giả sử ông chủ của

bạn cho bạn một ngân sách và số đó chỉ được một nửa điều bạn

cần, bạn có thể hoàn thành dự án này một cách thành công

được không? Nhiều người quản lí dự án phần mềm thụ động và

không biết cách thương lượng, không biết hỏi cái gì, không biết

ước lượng kích cỡ, phạm vi, tài nguyên, ngân sách và công cụ.

Họ cần đào tạo bằng không họ sẽ không bao giờ thành công

trong nghề của mình. Một công ti không đầu tư vào đào tạo sẽ

không tồn tại lâu trong môi trường cạnh tranh này.

PM: Anh nhấn mạnh quá nhiều vào đào tạo. Anh nghĩ

đào tạo là quan trọng thế sao?

SM: Vâng, nó là điều quan trọng nhất và là đầu tư tốt

nhất mà công ti có thể làm. Tôi nghĩ điểm yếu chính của nhiều

công ti là họ không hiểu bản chất của phần mềm. Họ không có

vấn đề trong chi tiêu tiền về phần cứng nhưng rất keo kiệt trong

đào tạo cho người của họ. Đào tạo cung cấp tri thức và kĩ năng

và phải được coi là quá trình tiếp diễn. Đào tạo không bao giờ

nên dừng lại vì công nghệ thanh đổi nhanh chóng. Hơn bao giờ

hết, trong thời khủng hoảng kinh tế khi mọi sự đều chậm, đây

là lúc cho bạn nhận đào tạo và thời gian cho đào tạo người của

bạn về những kĩ năng mà họ sẽ cần khi mọi sự trở lại bình

thường.

PM: Tôi đoán rằng đó là mọi thứ chúng tôi có được hôm

nay. Nhưng tôi đánh giá cao lời khuyên của anh và tôi xin phép

87

đi với cam kết cải tiến kĩ năng của tôi. Tôi hiểu rằng tôi không

thể phụ thuộc vào may mắn mà vào kĩ năng của tôi trong thời

không chắc chắn này. Quản lí dự án yêu cầu hiểu biết sâu sắc

về cách phần mềm phải được lập kế hoạch và ước lượng.

Người quản lí dự án tốt phải biết cách thương lượng với khách

hàng và biết cách xây dựng tổ. Không có cách nào là tốt nhất

cho người quản lí phần mềm mà không có đào tạo thêm.

Lời khuyên cho người quản lí dự án-2

Người quản lí dự án giỏi phải có cả kĩ năng kĩ thuật và kĩ

năng trao đổi. Đạt tới đúng mức của những kĩ năng này yêu cầu

nhiều năm thực hành và kinh nghiệm. Để bắt đầu, người quản

lí dự án cần tạo ra môi trường làm việc tốt cho tổ bằng việc

động viên nhiều trao đổi giữa các thành viên tổ. Người quản lí

dự án nên giải thích cho tổ về viễn tượng của dự án hay 'bức

tranh lớn' và cách họ có thể giúp đạt tới viễn tượng đó. Xây

dựng tổ là rất quan trọng nơi mối quan hệ giữa các thành viên

tổ còn chưa chín muồi, đặc biệt vào lúc bắt đầu dự án. Người

quản lí có kinh nghiệm biết rằng xây dựng tổ cần thời gian cho

nên chính việc làm của họ là tạo điều kiện và động viên việc

xây dựng tổ sớm nhất có thể được khi tổ được hình thành. Khi

tổ được thành lập tốt, công việc của tổ bắt đầu vì nó áp dụng

vào các thực hành trong toàn bộ cuộc đời của dự án. Không tổ

nào là hoàn hảo, do đó bao giờ cũng có vấn đề nhưng người

quản lí có kinh nghiệm bao giờ cũng nhằm tới những chuẩn

nào đó của công việc tổ để được hoàn thành. Nơi có những chỉ

báo về vấn đề với tổ, nó cần được nhận ra như rủi ro chính cho

dự án và người quản lí phải giải quyết nó ngay lập tức.

Nhiều người tin là những người quản lí phải ra mọi quyết

định và tổ phải tuân theo bất kì điều gì họ quyết định cho tổ

88

làm. Đây là sai lầm lớn bởi vì không ai bao giờ cũng đúng và

không có sự tham gia của tổ, dự án sẽ KHÔNG thành công.

Người quản lí có kinh nghiệm hiểu điều này và bao giờ cũng để

tổ biết tại sao các quyết định được đưa ra, không chỉ chúng là

gì cũng như không chỉ nhận diện bất kì vấn đề nào trong dự án

rồi mới yêu cầu tổ giúp giải quyết chúng. Phần lớn mọi người

đáp ứng tích cực để được thông tin hay để được hỏi ý kiến. Có

một số “Kĩ thuật quản lí” được giới hàn lâm biện hộ rằng

'người quản lí quản lí' còn thành viên tổ 'làm' hay 'người quản lí

chỉ đạo' và thành viên tổ 'hành động. Đây là cách sai để xây

dựng tổ hiệu năng cao và có thể làm nảy sinh lỗ hổng trao đổi,

chính là điều đối lập với thực hành quản lí dự án tốt nhất.

Người quản lí dự án giỏi KHÔNG chỉ hiểu khái niệm

quản lí dự án, mà còn cung cấp quyền lãnh đạo hiệu quả.

Quyền lãnh đạo khó mà định nghĩa, nhưng dễ dàng chú ý tới

khi thiếu nó. Quyền lãnh đạo hiệu quả bao gồm trao đổi cởi mở

và uỷ quyền hiệu quả. Không ai có thể làm được mọi thứ cho

nên điều quan trọng là phân chia công việc thành nhiều nhiệm

vụ nhỏ và phân công cho các thành viên tổ các nhiệm vụ mà họ

có thể làm việc tốt bởi vì công việc quản lí là để “tạo điều kiện

chứ KHÔNG ra lệnh”. Người lãnh đạo giỏi không bao giờ nên

là người độc đoán và đây là nguyên tắc rất quan trọng vì nhiều

người không có kinh nghiệm hay lẫn lộn giữa quyền lực và

động cơ. Tất nhiên, người quản lí dự án chịu trách nhiệm về dự

án và phải ra quyết định nào đó nhưng KHÔNG phải là tất cả.

Bằng việc đưa cả tổ cùng tham gia vào những quyết định nào

đó nhưng được chuẩn bị để đưa ra những quyết định gay go,

người quản lí có kinh nghiệm có thể giải quyết hiệu quả với các

vấn đề và tình huống xấu. Người quản lí giỏi kính trọng các

thành viên tổ và hỗ trợ cho họ bất kì khi nào họ cần. Bằng việc

cởi mở và trung thực với tổ mặc cho bất kì vấn đề nào hay sự

thách thức nào, người quản lí sẽ thu được sự kính trọng của họ.

89

Một trong những trách nhiệm quan trọng nhất của người

quản lí dự án là quản lí mong đợi của khách hàng và của người

dùng, và xây dựng một tập các mục đích cho dự án. Hiểu và

làm việc hướng tới một tập mục đích rõ ràng là nhân tố quan

trọng nhất của làm việc theo tổ. Do đó, điều này phải là một

trong những mục đích quan trọng nhất và là trách nhiệm của

người quản lí dự án. Người quản lí dự án phải động viên việc

trao đổi cởi mở giữa các thành viên để chắc rằng họ hiểu trách

nhiệm của mình cũng như cách họ đóng góp cho mong đợi

tổng thể. Kĩ năng trao đổi cá nhân tốt cũng là điều bản chất nếu

tổ đang trên đà tiến bộ có hiệu quả và hiệu lực. Có nhiều dạng

trao đổi, nhưng cái quan trọng nhất, và đôi khi ít được thực

hành nhất, là lắng nghe. Thiếu việc chăm chú và chú ý tới kĩ

năng và qui trình trao đổi có thể gây ra các rủi ro chính và vấn

đề cho dự án mà các kết quả của chúng thường được đo dưới

dạng chậm trễ và việc làm thêm.

Một số sinh viên nói với tôi rằng họ không phải là người

quản lí dự án, ít nhất cũng chưa là, cho nên việc thảo luận về

chủ đề này dường như quá trừu tượng với họ. Câu trả lời của

tôi là nếu bạn không học nó bây giờ thì khi nào bạn mới học?

Bạn đợi cho tới khi bạn trở thành người quản lí dự án rồi học

các kĩ thuật quản lí sao? Được chuẩn bị khi bạn vẫn còn trong

trường học sẽ cho bạn cơ hội tốt hơn để là người quản lí giỏi

bất kì khi nào cơ hội tới và một số cơ hội có thể tới sớm hơn

bạn tưởng.

Lời khuyên cho người quản lí dự án-3

Một người phát triển phần mềm hỏi tôi: “Mất bao lâu để

là người quản lí dự án phần mềm? Tôi có cần theo khoá đào tạo

90

là người quản lí dự án phần mềm không? Người không làm

phần mềm có thể quản lí được dự án phần mềm không?”

Tôi đã viết nhiều bài báo về quản lí dự án phần mềm và

tôi bao giờ cũng tin rằng chỉ người phát triển phần mềm mới có

thể quản lí có hiệu quả dự án phần mềm. Không ai hiểu được

tầm quan trọng của yêu cầu phần mềm, kiến trúc hệ thống, thiết

kế và môi trường phát triển nhiều hơn người phát triển phần

mềm cho nên người quản lí dự án phần mềm tốt hiển nhiên

phải bắt đầu bằng kinh nghiệm trong phát triển phần mềm đầu

tiên. Điều này KHÔNG định nói rằng người không làm phần

mềm không thể quản lí được dự án phần mềm nhưng không có

nền tảng tốt trong phần mềm, họ có thể KHÔNG HIỆU QUẢ.

Trong nhiều năm, tôi đã biện minh quan điểm này với các giáo

sư từ các trường quản trị kinh doanh và tôi không muốn có

tranh luận khác. Lời khuyên của tôi không dựa trên bất kì

nghiên cứu lí thuyết hay hàn lâm nào mà dựa trên 40 năm làm

việc trong công nghiệp.

Người quản lí dự án phần mềm tốt phải biết cách ước

lượng nỗ lực – mất bao lâu để hoàn thành dự án và bạn cần bao

nhiêu người cho dự án. Bạn không thể đoán mò được mà phải

chia dự án thành các nhiệm vụ nhỏ và ước lượng thời gian cần

để hoàn thành các nhiệm vụ này. Điều này yêu cầu rằng bạn

hiểu phần mềm để chia nó thành các nhiệm vụ rồi ước lượng

nỗ lực cho từng nhiệm vụ. Bạn phải biết cách ước lượng giờ

dành cho từng nhiệm vụ để cho bạn có thể đi tới thời gian tổng

thể cần có cho dự án rồi dùng điều đó để kiểm điểm với quản lí

cấp cao hay khách hàng. Bạn phải biết cách thương lượng về

lịch biểu tương ứng. Nếu bạn cần năm tháng nhưng khách hàng

tin rằng điều đó có thể được làm trong ba tháng thì bạn sẽ làm

gì? Cái gì sẽ xảy ra nếu người quản lí cấp cao của bạn đồng ý

với khách hàng rằng ba tháng là lịch biểu tốt? Bạn sẽ làm gì -

đồng ý với lịch biểu mà không thể nào được thực hiện hay bác

bỏ nó?

91

Có nhiều tài liệu mà người quản lí phần mềm phải làm.

Bản kế hoạch dự án, lịch biểu, nhiều báo cáo tình trạng, nhiều

thời gian biểu cho thành viên tổ, và tuỳ theo phương pháp luận

nào đó, bạn có thể cần điền vào nhiều biểu mẫu và tài liệu.

Những việc giấy tờ này sẽ chiếm hầu hết thời gian của bạn

nhưng bạn chỉ có 10 giờ làm việc một ngày cho nên bạn sẽ làm

gì? Tôi không biết một số người quản lí dự án có rất hạnh phúc

để làm việc trên tài liệu không bởi vì họ không phải quản lí dự

án nhưng việc của bạn là quản lí dự án hay để điền vào các

công việc giấy tờ?

Người quản lí dự án làm gì cả ngày? Họ cũng phải thuê

người, dựng tổ dự án, xác định vai trò, trách nhiệm, phân công

việc cho thành viên tổ, dõi vết tiến bộ, báo cáo trạng thái cho

người quản lí cấp cao và nhiều điều nữa? Tất nhiên, người

quản lí dự án phải làm tất cả những điều đó và cũng phải giải

quyết các vấn đề trong các thành viên tổ, tạo ra môi trường nơi

mọi người sẽ được động viên và hạnh phúc. Tổ hạnh phúc là tổ

có năng suất cho nên bên cạnh việc quản lí dự án, bạn cũng cần

lập kế hoạch và tham gia vào các hoạt động xã hội để giữ động

cơ của tổ như các sự kiện xây dựng tổ, thưởng cho thành công

tổ, cám ơn tổ vì làm các việc tốt. Người quản lí dự án phần

mềm bao giờ cũng trao đổi và giữ cho tổ được thông báo về

tình trạng dự án. Họ không chỉ biết khía cạnh kĩ thuật mà họ

cũng phải biết cách là người quản lí tốt nữa.

Người quản lí dự án phần mềm giỏi phải biết cách lập kế

hoạch, quản lí, phối hợp, giám sát, quản trị và hỗ trợ. Họ phải

biết cách lập kế hoạch chi tiết, dự kiến vấn đề và khử bỏ chúng

trước khi chúng xuất hiện. Họ phải giám sát thường xuyên để

cho họ biết ngay khi mọi sự đi sai. Khi vấn đề xuất hiện, họ

phải biết cách giải quyết chúng ngay lập tức, họ phải đề cập tới

các xung đột cá nhân, giải quyết các vấn đề kĩ thuật và giữ cho

người quản lí cấp cao được thông tin về cách dự án đang tiến

triển, cũng như giữ cho khách hàng thoả mãn. Họ ra quyết

92

định, đạt tới nhất trí khi họ có thể, ra lệnh khi họ phải làm, và

vẫn giữ cho dự án tiến triển tương ứng. Về căn bản họ phải làm

nhiều điều và làm chúng cho tốt.

Vậy sau khi đọc những điều này, bạn còn vẫn muốn là

người quản lí dự án không?

Bạn học là người quản lí dự án tốt thế nào? Tất nhiên,

bạn cần theo khoá đào tạo về quản lí dự án phần mềm nhưng

cẩn thận đấy, có nhiều môn "quản lí dự án" nhưng chúng

không phải là môn "quản lí dự án phần mềm”. Có khác biệt

giữa hai môn này. Ngay cả với môn “quản lí dự án phần mềm”

một số người chỉ dạy bạn cách dùng công cụ lập kế hoạch như

Microsoft Project. Một kĩ năng tốt nên học nhưng bạn chỉ biết

cách dùng công cụ mà không biết các quản lí dự án phần mềm.

Một số môn dạy khía cạnh quản trị của quản lí dự án như lập

kế hoạch, báo cáo, và phương pháp làm ngân sách nhưng họ có

thể không dạy bạn cách quản lí dự án phần mềm. Một số môn

cũng có chất lượng, nhưng mục tiêu chính là để làm cho bạn

qua được kì thi vào lúc cuối rồi cho bạn chứng chỉ nhưng họ có

thể không dạy bạn cách quản lí dự án phần mềm. Và tất nhiên,

có các môn học có dạy cho bạn cách quản lí dự án phần mềm.

Đó là lí do tại sao bạn phải cẩn thận trong lựa chọn môn đúng

và đào tạo đúng.

Sau khi hoàn thành mọi đào tạo, bạn sẽ làm gì? một số

trong các bạn có thể nghĩ rằng quản lí các dự án nhỏ sẽ là bước

tiếp. Ai sẽ cho bạn cơ hội đó? Có được chứng chỉ không phải là

đảm bảo để được thăng chức lên thành người quản lí dự án.

Tuy nhiên, giả sử rằng bạn có cơ hội để quản lí dự án nhỏ thì

bạn có thể thấy ra rằng bạn không cần tất cả các điều quản lí dự

án hình thức mà bạn đã học ở lớp. Phần lớn các dự án nhỏ

không yêu cầu lập kế hoạch và kiểm soát hình thức như được

dạy trong lớp, bạn làm tốt. Nhưng sau vài dự án nhỏ thành

công bây giờ người quản lí cho bạn các dự án lớn hơn để quản

93

lí. Đột nhiên điều bạn làm tốt trong dự án nhỏ có thể không làm

việc tốt trong dự án lớn hơn rồi bạn có những vấn đề chính chờ

đợi. Tăng tỉ lệ là khó nhất trong quản lí dự án phần mềm. Đây

là lí do tại sao nhiều người quản lí dự án thành công với các dự

án nhỏ lại thất bại trong dự án lớn.

Tôi tin chẳng cái gì tốt hơn kinh nghiệm về dự án phần

mềm. Bạn sẽ thu được kinh nghiệm có giá trị hơn nhiều bằng

việc đi từ người phát triển lên lãnh đạo tổ rồi tới lãnh đạo tổ

trong dự án nhỏ tới dự án lớn hơn. Bạn học bằng việc thực

hành từ lãnh đạo tổ 4 tới 6 người tới tổ 10 tới 20 người và cuối

cùng tới dự án 50 tới 100 người. Bạn sẽ học đích xác cách nó

làm việc mà không có trách nhiệm quản lí dự án. Cách tiếp cận

“học qua hành” này là kinh nghiệm tuyệt vời cho người muốn

trở thành người quản lí dự án. Sau khi thu được kinh nghiệm

thì bạn chuyển từ người lãnh đạo tổ lên người quản lí dự án cho

dự án nhỏ rồi cuối cùng tới dự án lớn hơn. Trong thời gian

chuyển tiếp này, bạn có thể theo nhiều khoá đào tạo cần thiết

nhưng bao giờ cũng nhớ trong đầu rằng bạn vẫn học và để thời

gian làm việc cho bạn. Đừng vội, nếu cần 5 hay 8 năm thì để

nó là vậy bởi vì bạn muốn là “người quản lí dự án phần mềm

tốt nhất”.

Nhiều người phát triển bảo tôi: “Trong trường hợp đó, tôi

dứt khoát không muốn là người quản lí dự án." Đây là kiểu

phản ứng từ sinh viên và người phát triển sau khi họ nói với tôi

về thăng tiến nghề nghiệp nhưng câu hỏi của tôi là: “Trong

trường hợp đó bạn sẽ làm gì? Bạn nghĩ bạn có thể cứ ở mãi là

người phát triển phần mềm không? Nếu bạn không tiến bộ

trong nghề nghiệp của mình thì bạn sẽ lo nghĩ nhiều về cuộc

sống của bạn vì người mới tới và họ muốn lấy việc của bạn.

Trong thế giới thay đổi nhanh chóng này, không tiến bộ nghĩa

là vẫn còn ở sau và bị ở sau nghĩa là bạn có thể bị xoá bỏ. Thái

độ đúng sẽ là “Đây là cơ hội lớn và với lời khuyên đúng, tôi

nghĩ tôi có thể làm điều đó và đây là việc dành cho tôi." Đây là

94

những người sẽ làm mọi sự xảy ra, tạo ra khác biệt và quản lí

dự án tốt hơn những người khác và phần thưởng của họ sẽ là vô

tận.

Nhân tiện, người quản lí dự án phần mềm tốt có thể làm

được lương giữa $ 150,000 tới $ 250,00 đô la một năm cộng

với tiền thưởng như tuỳ chọn cổ phần.

Đào tạo người quản lí dự án

Ngày nay nhiều dự án phần mềm thất bại bởi vì người

quản lí dự án không được huấn luyện, hay họ được huấn luyện

bởi những người không có kinh nghiệm quản lí dự án . Sau đây

là vài lời khuyên có thể có ích cho bạn:

1) Hiểu tiêu chí thành công của dự án.

Vào lúc bắt đầu dự án, bạn phải hỏi khách hàng họ hiểu

thế nào là dự án này thành công. Bạn cần biết tiêu chí nào, như

lịch biểu, chi phí, hay chức năng là quan trọng nhất với họ. Một

số khách hàng muốn có sản phẩm trên thị trường trước hết để

chiếm thị phần, trong trường hợp đó lịch biểu là rất quan trọng.

Một số khách hàng muốn sản phẩm chất lượng cao do khối

lượng lớn của công việc và tính đúng đắn của công việc vận

hành của họ. Trong trường hợp đó chất lượng là quan trọng

nhất. Hãy nhớ rằng chính khách hàng mới xác định ra thành

công dự án của bạn và bạn phải hỏi họ.

2) Xác định tiêu chí đưa ra sản phẩm.

Ngay từ đầu trong dự án, bạn phải quyết định tiêu chí nào

sẽ xác định ra liệu sản phẩm này có sẵn sàng đưa ra cho khách

hàng không. Bạn có thể muốn đặt tiêu chí đưa ra là chức năng

đặc biệt nào đó phải được cài đặt đầy đủ, số lỗi phải giảm

xuống ít hơn hay những chỉ báo khác chứng tỏ rằng dự án đã

95

đạt tới mục đích của nó. Dù bạn chọn tiêu chí nào, nó cũng nên

thực tế, đo được và khớp với điều khách hàng muốn.

3) Trung thực

Đừng hứa hẹn điều bạn không thể thực hiện được. Trung

thực với khách hàng và các thành viên tổ và nói cho họ cái gì

có thể đạt tới được một cách thực tế. Họ có thể không thích

điều bạn đề nghị nhưng bạn cần thuyết phục họ rằng bạn đang

cố hết sức để đáp ứng nhu cầu của họ.

4) Lập kế hoạch hoạt động.

Là người quản lí dự án bạn phải viết ra mọi hoạt động

cần được thực hiện trong bản kế hoạch dự án. Bạn phải tuân

theo qui trình lập kế hoạch để ước lượng phải mất bao nhiêu

thời gian, tốn chi phí bao nhiêu, cần bao nhiêu người, đặt ưu

tiên thế nào và làm sao thương lượng được với khách hàng v.v.

Thời gian bạn dành cho việc xác định cái gì được cần để quản

lí dự án sẽ làm giảm số vấn đề bạn phải giải quyết về sau trong

dự án

5) Phân rã các yêu cầu thành nhiệm vụ.

Yêu cầu của khách hàng thường là lớn, phức tạp và khó

ước lượng cho nên bạn phải chia các yêu cầu này thành nhiều

nhiệm vụ nhỏ để giúp cho bạn ước lượng chúng chính xác, và

xác định hoạt động nào bạn phải làm và hoạt động nào bạn có

thể đã không nghĩ tới.

6) Để thời gian cho huấn luyện

Mọi dự án mới đều là thách thức và mọi thành viên tổ để

phải có kĩ năng cần thiết để làm việc. Bạn phải dành thời gian

sớm trong dự án để cho các thành viên tổ tham gia vào việc

huấn luyện sao cho họ có thể có hiệu quả. Sự hội tụ mấu chốt

của huấn luyện là vào việc loại bỏ lỗ hổng giữa kĩ năng hiện

thời của từng thành viên tổ và kĩ năng cần để thực hiện công

96

việc dự án. Mặc dầu ngân sách huấn luyện bao giờ cũng bị hạn

chế, bạn phải thuyết phục cấp quản lí rằng những kĩ năng này

là chủ chốt, nếu không được thực hiện có hiệu quả thì có thể

gây nguy cơ cho hiệu năng thành công của dự án.

7) Điều phối tiến độ

Người quản lí dự án phải biết cái gì là điều quan trọng

nhất trong dự án và điều phối chúng trên cơ sở hàng ngày hay

hàng tuần để đảm bảo rằng chúng đang tiến triển tương ứng.

Bạn phải tự hỏi mình: Dự án đang tiến triển theo lịch như

thế nào? Dự án đang tiến triển theo ngân sách thế nào? Loại rủi

ro nào đã được nhận diện và làm sao quản lí được chúng? Vấn

đề gì mới đã nảy sinh và làm sao quản lí được chúng? Việc trao

đổi của dự án với khách hàng như thế nào rồi?

Chất lượng tiến triển như thế nào theo dự án? Các thành

viên tổ cần dành bao nhiêu thời gian cho dự án? Bao nhiêu lỗi

đã được chữa trong tuần này và tuần tới? Tôi phải dự bao nhiêu

cuộc họp?

Như bạn có thể thấy, làm người quản lí dự án bạn phải

hỏi những câu hỏi đó bởi vì nếu bạn không có câu trả lời thì

mọi sự có thế thoát ra ngoài kiểm soát và bạn không thể khắc

phục được nó.

8) Kế hoạch làm lại sau kiểm thử.

Mọi sản phẩm phần mềm đều có lỗi. Sau kiểm thử, bạn

sẽ thấy lỗi và bạn phải sửa chúng trước khi chuyển giao cho

khách hàng. Loại việc làm lại này (Sửa lỗi) thường không có

trong bản kế hoạch dự án gốc của bạn bởi vì bạn không biết

mình phạm phải bao nhiêu lỗi ở lúc bắt đầu dự án. Bạn sẽ cần

thời gian và người cho loại việc này. Điều này sẽ tác động tới

lịch biểu gốc và chi phí gốc của bạn cho nên bạn phải thảo luận

97

điều đó với cả khách hàng và thành viên tổ trong phạm vi lịch

biểu chuyển giao và ngân sách.

9) Liên tục cải tiến qui trình.

Thành viên tổ bao giờ cũng bận rộn với công việc dự án

của mình nhưng nếu bạn muốn xây dựng phần mềm với ít lỗi

hơn, bạn phải đầu tư thời gian cho việc cải tiến qui trình và khử

bỏ nguyên nhân của lỗi. Bạn phải để ra một số thời gian trong

lịch biểu bận rộn của mình cho việc cải tiến bởi vì những thay

đổi này sẽ giúp dự án tiếp của bạn thành công hơn. Đó là lí do

tại sao tôi chưa bao giờ phân công cho thành viên tổ của mình

cả 100% thời gian của họ để làm việc trên dự án mà để ra

khoảng 20% để làm việc cải tiến qui trình.

Ưu tiên của người quản lí dự án phần mềm

Phần lớn những người quản lí dự án được đào tạo để hội

tụ vào lịch biểu nhưng theo kinh nghiệm của tôi, có lẽ điều

quan trọng nhất là về đặt ưu tiên dự án. Trong khi lịch biểu có

thể là quan trọng nhưng không có hiểu biết về ưu tiên, bạn có

thể KHÔNG có khả năng đạt tới hạn thời gian lịch biểu. Tôi đã

thấy nhiều người quản lí dự án chỉ hội tụ vào lịch biểu nhưng

bỏ qua nhu cầu của tổ dự án riêng của họ và đến cuối, họ đáp

ứng lịch biểu nhưng sản phẩm phần mềm của họ đầy lỗi và

KHÔNG có mọi chức năng mà khách hàng yêu cầu.

Người quản lí dự án có kinh nghiệm hiểu các ưu tiên dự

án và bao giờ cũng hành động tương ứng với chúng. Ưu tiên

thứ nhất là hội tụ vào tổ dự án hay "đối nội". Lí do là đơn giản,

chính tổ dự án làm mọi công việc và thành công hay thất bại

của dự án phụ thuộc vào tổ. Điều tổ dự án cần là chỉ đạo và

hướng dẫn cho nên điều quan trọng là người quản lí dự án trao

98

đổi về mục đích và chiều hướng dự án rõ ràng lúc bắt đầu dự

án và thường xuyên nhắc nhở họ trong các cuộc họp tổ hàng

tuần. Người quản lí dự án phải giám sát các hoạt động của tổ

trên cơ sở hàng ngày để chắc rằng không có xung đột giữa các

thành viên tổ. Nếu có xung đột người quản lí dự án phải giải

quyết chúng nhanh chóng nhất có thể được. Dù người được đào

tạo tốt thế nào cho làm việc tổ, bao giờ cũng có xung đột giữa

các thành viên tổ. Một số xung đột thuộc kiểu cá tính (cá tính

năng nổ hay thụ động), một số do vai trò và trách nhiệm (một

số người có xu hướng can thiệp vào công việc của người khác)

và một số vấn đề chung như không có tài nguyên thích hợp

(người hay công cụ) hay không có đủ hướng dẫn kĩ thuật để

làm công việc. Người quản lí dự án phải làm rõ ràng cho tổ

rằng người đó có đó để giúp họ, để hỗ trợ cho họ và bao giờ

cũng sẵn có cho họ. Việc của người quản lí dự án là phối hợp

các hoạt động, hướng dẫn tổ đạt tới mục đích dự án. Về cơ bản,

người quản lí dự án làm việc vì tổ và KHÔNG vì điều ngược

lại.

Ưu tiên thứ hai là thoả mãn khách hàng của bạn hay “đối

ngoại”. Người quản lí dự án có kinh nghiệm hiểu rằng họ

không phát triển phần mềm mà thực tế đó là việc làm của tổ dự

án. Cách duy nhất để thoả mãn khách hàng là tạo ra môi trường

cho phép tổ dự án đáp ứng nhu cầu của khách hàng. Về cơ bản,

ưu tiên này là tương tự với ưu tiên thứ nhất, nhấn mạnh rằng

việc làm của người quản lí dự án là giúp cho tổ làm công việc

của họ một cách hiệu quả và hiệu lực để đạt tới thoả mãn của

khách hàng. Điều tổ cần là thời gian thích hợp để làm công

việc của họ cho nên người quản lí dự án phải biết mất bao lâu

để hoàn thành dự án bằng việc có ước lượng tốt (lịch biểu và

nỗ lực) và thương lượng với khách hàng về lịch biểu hợp lí.

Câu hỏi là làm sao có ước lượng tốt? Tất nhiên, người quản lí

dự án phải biết cách ước lượng thời gian và nỗ lực hoặc bằng

việc theo các khoá đào tạo hoặc bằng kinh nghiệm. Tuy nhiên,

99

điều cũng quan trọng là người quản lí dự án làm việc với tổ dự

án về những ước lượng này. Bằng việc để tổ tham gia vào nỗ

lực ước lượng, người quản lí có thể tránh được vấn đề ra lệnh

cho họ tuân theo cái gì đó mà họ không có đóng góp nào cả.

Bằng việc để tổ tham gia vào, người quản lí tạo ra môi trường

làm việc cùng nhau nơi kết quả là nỗ lực tập thể. Chỉ bằng việc

có các ước lượng tốt, người quản lí dự án có thể thương lượng

một cách tự tin với khách hàng về khung thời gian hợp lí mà cả

hai bên sẽ đồng ý. Lịch biểu hợp lí không đảm bảo dự án thành

công nhưng nó làm giảm nhiều rủi ro dự án vì vấn đề số một

của hầu hết các dự án phần mềm là lịch biểu không hợp lí.

Ưu tiên thứ ba là hội tụ vào việc riêng của bạn hay "đối

mình". Ưu tiên này là về đam mê, động cơ, tri thức và kĩ năng

của bản thân người quản lí dự án. Là người quản lí dự án, bạn

có trách nhiệm với tổ của bạn, với công ti của bạn, và với

khách hàng của bạn cho nên bạn phải biết bản thân mình và

những điểm mạnh điểm yếu của mình. Bạn phải cung cấp sự

lãnh đạo cho tổ của bạn. Bạn phải hiểu công ti của bạn, và bạn

phải biết cách xây dựng mối quan hệ với khách hàng. Tất nhiên

điều đó là KHÔNG dễ nhưng là người quản lí dự án, bạn phải

đạt tới mọi điều về chúng trước khi bạn có thể đi lên bước tiếp.

Tôi đã thấy nhiều người quản lí dự án lấy "lối tắt" bằng việc

tập trung vào làm vừa lòng quản lí cấp cao, tham dự các cuộc

họp quản lí, dành nhiều thời gian hơn với những người quản lí

cấp cao để được họ nhận ra và hi vọng rằng họ sẽ được lựa

chọn khi thời điểm thăng cấp đến. Đó KHÔNG phải là nước đi

tốt bởi vì nó xung đột với các ưu tiên khác. Làm tường minh

bất kì cái gì bạn có thể làm để làm hài lòng người quản lí riêng

của bạn nên có ưu tiên thấp nhất. Người quản lí cấp cao hơn

của bạn sẽ hài lòng nếu bạn thành công tại dự án của bạn và đạt

được cả hài lòng của khách hàng và kính trọng của tổ của bạn.

Bạn phải hoàn thành trách nhiệm của mình với việc làm của

mình bằng việc hội tụ vào hỗ trợ cho tổ của bạn và cho khách

100

hàng của bạn chứ KHÔNG hội tụ năng lượng của bạn vào thoả

mãn những người trên bạn vì thăng tiến riêng của bạn.

Ưu tiên thứ tư là hội tụ vào chia sẻ và thúc đẩy tri thức và

kĩ năng. Mặc dầu từng cá nhân phải chịu trách nhiệm về học

tập liên tục của họ, việc học cá nhân một mình không thể giúp

cho dự án hay công ti được. Để có tính cạnh tranh, công ti tốt

phải cung cấp cơ hội cho mọi người để học và cải tiến tri thức

kĩ thuật. Công nghệ thay đổi thường xuyên và công ti tốt phải

có tài năng và kĩ năng để canh tân. Mọi người phải được động

viên để hỏi các câu hỏi, sai lầm được nhận ra như một phần của

việc học và đó là cách tốt nhất để tăng trưởng công ti. Là người

quản lí dự án, bạn phải hội tụ vào việc động viên người của bạn

liên tục học tập bằng việc cung cấp đào tạo phụ và theo dõi để

chắc chắn rằng các mục đích được đáp ứng. Mọi thành viên tổ

được khuyến khích có kế hoạch học tập cá nhân riêng của họ.

Khả năng của công ti để cải tiến là tỉ lệ trực tiếp với khả năng

học tập của nó. Một công ti không thể học được thì không thể

cải tiến được và công ti không thể cải tiến được thì không thể

tăng trưởng và không thể cạnh tranh được.

Ưu tiên thứ năm là tập trung vào đào tạo người thay thế

bạn. Khi bạn tiến lên trong nghề nghiệp là người quản lí dự án

bạn cũng phải khuyến khích ai đó thay thế bạn. Bạn thành

công, quả thực việc tiến lên của bạn vào vị trí tốt hơn thực sự

phụ thuộc vào việc có ai đó đó dự phòng cho bạn, hỗ trợ bạn,

và không cái gì tốt hơn là đào tạo người thay thế bạn khi bạn

chuẩn bị đi lên vị trí cao hơn tiếp đó. Thành công của bạn trong

quản lí dự án, thành công của bạn trong thoả mãn của khách

hàng, thành công của bạn trong việc thu được sự kính trọng của

các thành viên tổ, thành công của bạn trong thúc đẩy học tập

liên tục sẽ làm cho bạn được chú ý và cơ hội sẽ tới nhưng bạn

phải được sẵn sàng và không cái gì là tốt hơn việc hiểu và hoàn

thành mọi ưu tiên.

101

Người quản lí dự án trong miền mới

Một người quản lí dự án viết cho tôi: “Người quản lí dự

án chuyển từ miền này sang miền khác có dễ dàng không? Tôi

là người quản lí ở một công ti phần mềm nhưng muốn chuyển

sang công ti tài chính. Tôi cần gì để thành công ở miền mới?"

Đáp: Nguyên lí của quản lí dự án là như nhau, bất kể

miền. Bạn bao giờ cũng phải lập kế hoạch công việc của bạn,

theo dõi khác biệt của điều thực tế thực hiện và điều bạn đã lập

kế hoạch, và có hành động sửa chữa nếu có khác biệt lớn. Điều

quan trọng nhất là học nhiều nhất có thể được về ngành công

nghiệp và miền bạn muốn làm việc. Hiểu khách hàng của họ và

nhu cầu và kiểu dự án nào bạn có thể được phân công. Bạn có

thể cần kiểm điểm kĩ năng riêng của bạn để nhận diện điều bạn

có và tri thức và kĩ năng nào bạn cần học. Nếu bạn đã từng làm

việc cho một công ti trong một thời gian điều thông thường là

bạn biết làm gì trong công ti đó nhưng không hoàn toàn chắc

điều gì đang xảy ra trong thế giới bên ngoài. Bạn có thể cần bắt

đầu nghiên cứu thị trường, tìm xem liệu có công nghệ hay công

cụ nào bạn cần biết không.

Nhớ rằng vị trí tiếp của bạn như người quản lí dự án sẽ

quản lí dự án mà có nội dung chủ đề bạn không có kinh nghiệm

trước. Cho dù bạn có năng lực của người quản lí dự án thành

công nhưng bạn cũng cần thời gian để học về miền mới. Ngay

khi bạn bắt đầu việc làm mới, bạn phải làm quen với các đồng

nghiệp, những người có thể giúp bạn ở vị trí mới của bạn. Bạn

cần sẵn lòng đưa thêm nỗ lực phụ vào và đảm bảo từng nhiệm

vụ được thực hiện tương ứng và chúng là điều công ti mới đang

tìm kiếm khi thuê bạn. Thời gian mau chậm bạn cần để điều

chỉnh với việc làm mới biến thiên từ người nọ sang người kia.

102

Trong khi một số người có thể khớp ngay lập tức nhưng với

nhiều người, có thể mất thời gian lâu hơn chút ít. Mọi điều bạn

có thể làm là cố gắng hết sức, và làm việc của bạn theo cách tốt

nhất bạn biết làm ra sao. Nếu bạn không biết cái gì đó, hỏi các

câu hỏi. Bạn là mới và tốt hơn cả là làm cái gì đó đúng ngay

lần đầu tiên hơn là phải là lại nó. Làm quen với tổ mới của bạn

và mối quan tâm của họ là gì. Dành thời gian cùng họ để học

cách mọi sự làm việc trong công ti mới. Bạn cũng cần biết

người quản lí của bạn, người có quyền cho bạn công việc và

hiểu mong đợi của người đó về bạn. Giữ thái độ tích cực và

tâm trí cởi mở, bạn sẽ làm tốt.

Phụ nữ trong quản lí dự án

Ts. Linda Hamilton là tác giả của một nghiên cứu về vai

trò của phụ nữ trong quản lí dự án phần mềm. Cô ấy đã tới

thăm 250 tổ chức công nghệ thông tin, phỏng vấn trên 700

người quản lí và thu thập hơn 4000 dữ liệu dự án phần mềm.

Tuần trước, cô ấy tới thăm CMU và trình bày cho lớp của tôi

về nghiên cứu của cô ấy.

Cô ấy nói: “Đàn ông và đàn bà là khác nhau nên họ quản

lí dự án khác nhau cho dù tất cả họ đều theo nguyên lí của quản

lí dự án phần mềm. Kĩ năng kĩ thuật không khác mấy nhưng

chính tài năng bản chất của phụ nữ giúp cho họ trở thành người

quản lí tốt hơn đàn ông. Ngày nay phần mềm vẫn là ngành

công nghiệp do đàn ông chi phối trong vai trò người phát triển,

người kiểm thử và người quản lí dự án. Nhưng điều đó đang

thay đổi khi nhiều phụ nữ bây giờ đang học về khoa học máy

tính, kĩ nghệ phần mềm, và quản lí hệ thông tin.

Tôi hỏi: “Tài năng tự nhiên nào của phụ nữ làm cho cô ấy

là người quản lí tốt hơn đàn ông?”

103

Cô ấy giải thích: “Phụ nữ giỏi trong trao đổi. Họ thích

nói chuyện với mọi người và sẽ chia sẻ thông tin cởi mở với

mọi người trong tổ của cô ấy. Việc nghiêng tự nhiên này về nói

chuyện giúp cho họ làm việc tốt hơn nhiều, khi là người quản lí

dự án phần mềm. Bởi vì phụ nữ tiến hành nói chuyện không

chính thức đều đặn với tổ dự án, điều đó làm cho cô ấy dễ dàng

nhận diện mối quan tâm hay vấn đề mà có thể ẩn kín nếu

không được thảo luận cởi mở. Việc chăm sóc tự nhiên của phụ

nữ làm cho rất có thể là cô ấy sẽ giải quyết sự việc trước khi nó

trở thành vấn đề. Trao đổi tốt không chỉ là về nói mà còn về

báo cáo hiệu quả với quản lí cấp cao và người chủ công ti.

Trong nghiên cứu của tôi, tôi thấy rằng phần lớn phụ nữ viết tốt

hơn đàn ông và báo cáo trạng thái của họ là tuyệt vời. Trong

phỏng vấn của tôi với người quản lí cấp cao, phần lớn đồng ý

với phát hiện của tôi. Phần mềm là chủ đề kĩ thuật cao và rất

phức tạp. Chúng là khó giải thích trong việc viết. Làm sao bạn

làm cái gì đó phức tạp thành cái gì đó đơn giản và dễ hiểu? Nó

yêu cầu tài năng trong việc viết và đây là chỗ phụ nữ làm tốt.

Tôi đã phân tích hàng nghìn báo cáo dự án và thấy rằng phần

lớn người nữ quản lí dự án không dùng các ngôn từ phức tạp

hay biệt ngữ như đàn ông. Phần lớn viết dưới dạng đơn giản, rõ

ràng và bằng cách nào đó làm cho vấn đề phức tạp dường như

không phức tạp. Nhiều người chủ công ti chú ‎ý và đó là một lí

do, nhiều phụ nữ được đề bạt lên mức cao hơn trong công ti.”

Tôi nói: “Điều đó thật thú vị, tôi chưa bao giờ nghĩ về

điều đó. Vì bạn đã nhắc tới nó, tôi cũng thấy rằng sinh viên nữ

viết bài báo và đoạn văn tốt hơn nam.”

Cô ấy mỉm cười: “Trao đổi tốt cũng khuyến khích tổ dự

án. Bằng việc thường xuyên nói với riêng các thành viên tổ và

thông cảm với mối bận tâm của họ, người nữ quản lí dự án có

thể xây dựng tổ có động cơ những người sẵn lòng làm việc

chăm chỉ và hỗ trợ cho mục đích dự án. Tổ có động cơ mạnh

bao giờ cũng có ưu thế khi phát triển phần mềm phức tạp. Đàn

104

ông có thể động viên tổ nhưng thường dưới dạng chỉ huy, kiểm

soát và rất trực tiếp. Tài của người nữ quản lí dự án là linh hoạt

và bằng cách nào đó vô nỗ lực. Họ biết khi nào thì ca ngợi và

khi nào giữ yên tĩnh. Khi tôi hỏi những người phát triển về

người nào họ muốn làm việc cùng? Quãng 67% ưa thích làm

việc cho người nữ quản lí dự án. Tuy nhiên, vì 31% chưa bao

giờ làm việc cho người nữ quản lí, họ nói rằng họ đã không

biết. Về tổng thể, nếu được cho cơ hội, phần lớn có lẽ sẽ làm

việc cho phụ nữ. Một nhân tố quan trọng mà tôi thấy là phụ nữ

thường ngăn cản các thành viên tổ khỏi cạnh tranh lẫn nhau.

Ngược lại, người quản lí nam ưa thích để các thành viên cạnh

tranh. Điều đó không phải là cách tốt để xây dựng tổ. Phụ nữ

cũng giỏi làm lắng dịu xung đột giữa các thành viên tổ tốt hơn

đàn ông. Khi dự án đang dưới sức ép, phụ nữ bình tĩnh hơn đàn

ông. Họ dựa nhiều vào tổ để giải quyết vấn đề bằng việc động

viên và ca ngợi khi đàn ông thường la lối, và đe doạ họ. Từ

nghiên cứu của tôi, trao đổi, kĩ năng liên con người và xây

dựng tổ là những khu vực mà phụ nữ xuất sắc trong các công ti

phần mềm.”

Tôi hỏi: “Có cái gì khác không?"

Cô ấy nói: “Tất nhiên, sẽ có những điều mới mà tôi có

thể làm cho các bạn ngạc nhiên. Khi tôi trình bày chúng, nhiều

người chủ công ti choáng. Tất cả chúng ta đều biết rằng đa số

dự án phần mềm bị chuyển giao chậm và tốn phí nhiều hơn. Đã

có nhiều nghiên cứu về điều đó. Nhưng điều tôi thấy là người

nữ quản lí dự án tốt nhất bằng cách nào đó động viên dự án

vượt quá mong đợi. Các dự án thành công là những dự án

chuyển giao đúng thời gian, trong ngân sách và đáp ứng các

yêu cầu. Nhưng có nhiều dự án được chuyển giao sớm, dưới

ngân sách và vượt quá mong đợi của khách hàng. Sự kiện thú

vị nhất là 72% các dự án này đã được quản lí bởi phụ nữ.”

105

Tôi ngạc nhiên: “Điều đó thật đáng ngạc nhiên. Tôi

không biết điều đó.”

Ts Linda mỉm cười: “Thầy không một mình đâu, nhiều

người cũng đã ngạc nhiên rồi. Có nhiều người đã tiến hành

khảo cứu về thất bại dự án nhưng không nhiều người chú ý tới

dự án thành công. Thậm chí không ai đã từng hỏi người quản lí

dự án là ai nhưng tôi đã làm và thấy rằng người nữ quản lí dự

án vượt hơn người nam quản lí dự án ở các dự án tương tự. Họ

có ít dự án thất bại hơn; nhiều dự án được chuyển giao đáp ứng

hay vượt quá mong đợi, tỉ lệ tốt hơn của việc đáp ứng lịch biểu

và ngân sách dự án. Hầu hết trong tất cả, trong dữ liệu được thu

thập, các dự án được phụ nữ quản lí thường là khó khăn hơn,

dựa trên nỗ lực tài nguyên được yêu cầu.”

Cô ấy tiếp tục: “Có những dữ liệu này, tôi đã nghiên cứu

thêm bằng phỏng vấn những phụ nữ thành công. Điều tôi thấy

cũng được đóng góp cho tài năng tự nhiên của phụ nữ. Phần

lớn phụ nữ có thể làm nhiều hơn một việc vào cùng lúc. Khả

năng làm đa nhiệm cho họ ưu thế khi phải quản lí thay đổi và

rủi ro. Đây là khu vực đàn ông không thể sánh được. Đàn ông

theo bản chất là có suy nghĩ tuyến tính; họ làm nhiều thứ theo

cách logic, từng bước một. Họ làm một điều, kết thúc nó rồi

chuyển sang điều tiếp. Phụ nữ có thể làm nhiều điều một lúc.

Họ có thể đặt ưu tiên, quản lí thay đổi yêu cầu, tính toán ngân

sách, và trao đổi với tổ của họ mà không bị sao lãng. Họ hiểu

cách làm việc tổ và họ tận dụng tài năng của tổ của họ để làm

công việc. Họ là những người trao đổi giỏi hơn, cộng tác hơn

và có kĩ năng đa nhiệm để quản lí dự án tốt hơn đàn ông. Đây

là lí do tại sao trong vài năm qua, nhiều đàn bà đã được đề bạt

vào các vị trí cao hơn và nhiều công ti đang tìm thuê nhiều phụ

nữ tốt nghiệp trong công nghệ thông tin. Không may chúng tôi

không có đủ phụ nữ học trong khu vực này. Một người chủ

công ti phần mềm lớn bảo tôi rằng ông ấy có thể thuê hàng

nghìn người trong họ, nếu ông ấy có thể tìm thấy họ.”

106

Cô ấy mỉm cười và hỏi tôi: “Thầy có bao nhiêu nữ trong

lớp kĩ nghệ phần mềm năm nay?”

Tôi trả lời: “Tôi có 65 trong 250 sinh viên.”

Cô ấy bình luận: “Điều đó là quá ít, thậm chí không được

một nửa. Làm sao chúng tôi có được nhiều nữ hơn trong lĩnh

vực này? Triển vọng việc làm là tốt, cơ hội thăng tiến là lớn, và

lương tuyệt vời. Tại sao học kinh doanh, tài chính, ngân hàng,

và giáo dục khi nhưng khu vực này đã đạt tới điểm bão hoà của

việc cung quá nhiều và ít cầu hơn?

Kinh nghiệm quản lí dự án

Thưa giáo sư,

Khi tốt nghiệp em bao giờ cũng nghĩ rằng em có thể viết

mã cho cả phần còn lại của nghề nghiệp của em. Điều đó diễn

ra tới năm thứ ba thì em nhận ra rằng em có thể làm được nhiều

hơn chỉ là viết mã và học môn của thầy ở CMU đã mở ra cơ

hội mới cho em. Khi công ti của em có mở ra việc của người

quản lí dự án, em đã xin làm và được làm mà không có khó

khăn gì. Em đã làm việc như người quản lí dự án trong năm

năm và bức thư ngắn này là về những điều em đã học được như

người quản lí dự án. Vì thầy thường đề nghị người đã tốt

nghiệp đang đi làm chia sẻ kinh nghiệm với sinh viên hiện thời,

em hi vọng rằng bức thư của em có thể ích lợi cho một số sinh

viên những người một ngày nào đó sẽ quản lí dự án phần mềm.

Điều đầu tiên tôi đã học được như người quản lí dự án là

lựa chọn thành viên tổ một cách cẩn thận. Khi tôi lần đầu tiên

trở thành người quản lí, tôi sung sướng khi ai đó muốn làm

việc cho tôi. Tôi đã học được về sau rằng không phải tất cả mọi

107

người đều chân thành và có ý định tốt. Nếu họ không làm việc

tốt với người khác, thì điều đó sẽ làm tổn hại cho toàn thể dự

án. Làm việc tổ là phức tạp và năng suất có liên quan nhiều tới

làm việc tổ. Có các thành viên tổ tranh cãi nhau thực sự làm

tổn hại năng suất cho mọi người. Bạn cần rất cẩn thận với

những người có thói quen xấu đó; cho dù họ có kĩ năng trong

lĩnh vực của họ. Không đáng có người có kĩ năng mà đi tranh

cãi với nhau suốt mọi lúc. Bạn cũng phải cẩn thận với những

người nói quá nhiều nhưng làm thì ít. Họ thích nói về bản thân

họ và những điều khác hơn là thực tế làm công việc. Mặc dầu

dường như là họ không có ý đồ xấu nhưng họ thường làm sao

lãng tổ.

Là người quản lí dự án, bạn sẽ rất bận rộn. Bạn sẽ không

có nhiều thời gian cho bất kì cái gì khác vì bạn sẽ có những

nhiệm vụ nhỏ thêm vào và lấy đi thời gian quí giá của bạn. Đó

là lí do tại sao quản lí thời gian là kĩ năng quan trọng phải có.

Bạn phải có cuốn sổ nhỏ mang theo người mọi lúc để ghi chép

và giữ lịch biểu. Tôi biết nhiều người có lịch đấy nhưng hiếm

khi theo nó bởi vì nó thay đổi thường xuyên. Điều đó là đúng,

nhưng không có lịch bạn sẽ bị lạc. Bạn cần có cuốn sổ để nhắc

bạn về các thứ cần làm. Bạn sẽ không nhớ được mọi thứ đâu.

Vấn đề là nó sẽ giúp bạn nghĩ về điều bạn làm với thời gian của

bạn. Tôi thường đi làm sớm buổi sáng trong khi cả tổ của tôi

còn chưa tới cho nên tôi không bị sao lãng. Tôi cũng tổ chức

nhiệm vụ của tôi cho ngày đó và chắc chắn tôi sẽ kết thúc tất cả

chúng trước khi rời khỏi công việc vì tôi không muốn đem việc

về nhà.

Mọi dự án đều duy nhất và mọi dự án sẽ có vấn đề. Điều

quan trọng là được chuẩn bị cho nó vì các thành viên tổ sẽ

tranh cãi, một số người có thể rời bỏ dự án và các vấn đề khác

sẽ kéo đến, và là người quản lí dự án bạn phải giải quyết nó

trước khi nó trở thành vấn đề lớn. Bạn sẽ cần vẫn còn bình thản

để nhìn vấn đề rõ ràng và không để các ý kiến khác che mờ

108

phán xét của bạn. Bạn phải học cách nhìn vào mọi thứ từ cảnh

quan của người khác và có thông cảm khi giải quyết với các

vấn đề có tính tình cảm. Bạn đừng áp đặt quyết định của bạn

lên người khác, khi cần; bạn phải bắt đầu với thảo luận tổ và

học cách lắng nghe mối quan tâm của họ. Cho dù bạn là người

quản lí dự án nhưng tốt hơn cả là bạn đưa tổ vào việc ra quyết

định. Điều đó sẽ làm cho tổ cảm thấy thoải mái với bạn và

quyết định của tổ là tốt hơn quyết định của một cá nhân.

Một số người tin người quản lí dự án là vị trí cao nhưng

với tôi nó chỉ là vai trò mà bạn giữ trong nghề của bạn. Vai trò

sẽ thay đổi với thời gian cho nên bạn cần khiêm tốn. Bạn sẽ

gặp nhiều người giỏi hơn bạn và một số sẽ có nhiều kĩ năng

hơn bạn. Bạn phải trung thực và không giả vờ biết mọi thứ khi

bạn không biết. Bạn có thể sai cho nên bạn phải học lắng nghe

và đánh giá cao những người có thể giúp bạn. Mọi người sẽ

kính trọng những người có thể thừa nhận khi họ sai hơn là ai đó

cứ khăng khăng rằng họ bao giờ cũng đúng. Đừng để cho bản

ngã của bạn lôi bạn vào biện luận với tổ của bạn. Bạn phải học

tin cậy vào tổ của bạn, và tổ của bạn sẽ có khả năng tin cậy

bạn. Cách tốt nhất để xây dựng tin cậy với tổ của bạn là thực tế

tin cậy vào họ trước. Trao cho các thành viên tổ trách nhiệm

quan trọng, để cho họ biết rằng bạn tin cậy vào họ, và họ có thể

sẽ tin cậy vào bạn.

Quản lí dự án là thách thức lớn và không phải mọi người

có thể là người quản lí dự án được. Bạn phải bắt đầu bằng kĩ

năng kĩ thuật và học thật nhiều hết sức trước khi bước lên quản

lí dự án. Không có kĩ năng kĩ thuật tốt bạn sẽ không bao giờ trở

thành người quản lí dự án giỏi. Không ai muốn làm việc cho

người quản lí bất tài. Nếu bạn muốn là người quản lí giỏi bạn

cần quan sát cách người quản lí giỏi làm việc. Mọi công ti đều

có một số người quản lí giỏi cho nên bạn phải tìm họ và học từ

họ.

109

Cho dù bạn bận rộn nhưng bạn phải dành thời gian cho tổ

của bạn. Nếu thành viên tổ muốn gặp bạn, người đó có thể có

cái gì đó để nói với bạn. Điều đó sẽ trở thành quan trọng hơn

khi dự án của bạn phát triển. Thỉnh thoảng các thành viên tổ có

thể dự đoán một vấn đề trước khi nó xảy ra và bạn cần kiểu

thông tin này. Lắng nghe là kĩ năng mà ít người có và bạn cần

học kĩ năng này. Phần lớn các đào tạo về kĩ năng mềm đều hội

tụ vào kĩ năng trình bày và kĩ năng trao đổi mà bỏ qua kĩ năng

lắng nghe, đó là sai lầm lớn. Bạn có thể nói hùng hồn, bạn có

thể là người trình bày hay nhưng không lắng nghe tốt, bạn sẽ

không đi xa. Xin nhận lời khuyên của tôi, khiêm tốn và lắng

nghe kĩ thì bạn sẽ thành công. Nếu bạn chỉ có thể có một kĩ

năng mềm, bạn nên học cách lắng nghe bởi vì không lắng nghe

người khác, dễ dàng trở nên thiên vị với ý tưởng riêng của bạn

thì bạn có thể trở thành kẻ độc đoán và trong trường hợp đó

không ai muốn làm việc cho bạn.

Tôi hi vọng bức thư ngắn này có thể giúp cho ai đó trong

các bạn. Tôi không nhắc tới khía cạnh kĩ thuật vì đó là cái gì đó

bạn có thể học từ lớp hay từ sách vở nhưng những kĩ năng

mềm này là điều tôi đã học trong năm năm làm quản lí dự án

phần mềm.

Lãnh đạo kĩ thuật

Lãnh đạo kĩ thuật là một kĩ năng KHÔNG được dạy

trong đại học. Nó là một trong những kĩ năng bạn phát triển chỉ

theo thời gian và kinh nghiệm. Thứ nhất, bạn cần có nhiều kinh

nghiệm trong phát triển phần mềm, từ thu lấy yêu cầu tới đưa

ra sản phẩm cuối cùng cho khách hàng để cho bạn biết tất cả

những khó khăn và chướng ngại của dự án phần mềm. Thứ hai,

bạn cần có khả năng loại bỏ những chướng ngại đó cho tổ của

110

mình và cho phép họ thành công. Là người lãnh đạo tổ của họ,

mục đích của bạn nên là tạo ra môi trường làm việc tốt cho tổ

của mình và cho phép họ làm điều bạn muốn họ làm và thành

công. Điều này không dễ vì nhiều người lẫn lộn giữa là người

lãnh đạo tổ và là người công bố thành công. Nguyên tắc của

người lãnh đạo tổ là bạn đặt ra chiều hướng kĩ thuật đúng, cung

cấp đào tạo hay chỉ dẫn cho tổ để họ có thể làm nó thành công

bởi vì thành công của họ là thành công của bạn.

Là người lãnh đạo tổ nghĩa là dành vài giờ một ngày,

hàng ngày như vậy, sau giờ làm việc, giữ cho mình bắt kịp với

thay đổi công nghệ, đọc những bài blog mới nhất, học những

công nghệ mới nhất, thử những công cụ mới nhất, nghiên cứu

các trường hợp điển hình mới nhất để cho bạn có thể cải tiến kĩ

năng kĩ thuật của mình và là người lãnh đạo tổ tốt hơn. Là

người lãnh đạo tổ, bạn phải tự hỏi mình công nghệ này đem tới

giá trị nào cho doanh nghiệp? Bao nhiêu người sẽ muốn dùng

nó? Đây là công nghệ mới hay chỉ là khái niệm? Nó tăng qui

mô thế nào? Nó vận hành ra sao? Nó có thể được thực hiện tốt

hơn không? Còn nhiều vấn đề hơn chỉ phát triển phần mềm

nhưng bạn cần thu nhận nhiều tri thức kĩ thuật để bạn có thể

giúp cho tổ mình thành công. Lãnh đạo kĩ thuật KHÔNG phải

là việc dành cho mọi người mà chỉ một vài người yêu thích

công nghệ và mọi thứ liên quan tới nó. Điều tệ nhất là dù bạn

có đọc nhiều đến đâu và học nhiều đến đâu, bạn vẫn cảm thấy

bạn không biết đủ vì công nghệ thay đổi nhanh chóng.

Bên cạnh tri thức kĩ thuật, trao đổi cũng là kĩ năng quan

trọng khác của người lãnh đạo tổ. Trong phát triển phần mềm,

trao đổi nghĩa là có khả năng chia sẻ thông tin với thành viên tổ

và hướng dẫn họ dùng nó tương ứng. Người lãnh đạo tổ tốt

phải có khả năng trao đổi về tình trạng dự án lên quản lí cấp

trên cũng như trao đổi nó cho mọi thành viên tổ với nhiều chi

tiết để cho họ có thể hành động theo nó. Kĩ năng trao đổi không

chỉ là giải thích tình trạng dự án cho người quản lí mà còn làm

111

cho họ hiểu và ủng hộ dự án. Đồng thời, tổ phải có khả năng

lấy yêu cầu nghiệp vụ, vấn đề hay ý tưởng mới, và giải thích

cho các thành viên tổ để làm cho họ cam kết thực hiện nó.

Lãnh đạo kĩ thuật là kĩ năng quan trọng trong quản lí tổ

những người kĩ thuật. Thay vì ra lệnh bạn đang lãnh đạo bằng

nêu gương để động viên tổ. Mục đích của bạn là gây hứng khởi

cho các thành viên làm điều bạn muốn họ làm. Đó là lí do tại

sao người lãnh đạo kĩ thuật lớn phải là người động viên vì bạn

lãnh đạo bằng nêu gương chứ không bằng quyền lực. Chẳng

hạn bạn thấy một thành viên tổ dường như không tham dự và

mời người đó ra uống cà phê và hỏi họ vấn đề là gì. Bạn sẽ

huấn luyện người đó, giúp người đó và động viên người đó

bằng giải thích viễn kiến của bạn và loại bỏ chướng ngại người

đó đang đối diện. Trong các cuộc họp tổ, bạn có thể động viên

tổ bằng việc giải quyết các vấn đề kĩ thuật, hay lãnh đạo mọi

người theo chiều hướng đúng cho giải pháp. Không có người

động viên nào cho một tổ gồm những người kĩ thuật trình độ

cao tốt hơn là có người lãnh đạo để giải quyết vấn đề kĩ thuật

khó, và cho phép họ học điều đó để làm cho dự án thành công.

Tất nhiên, bạn phải có đam mê trong mọi thứ bạn làm và

đam mê không thể là giả được. Nếu bạn có đam mê về việc làm

của mình, không thành vấn đề bạn đang làm gì, mọi người sẽ

thừa nhận điều đó.

112

113

3. Tổ dự án

Kĩ năng con người

Hầu hết dự án phần mềm thành công đều có hai yếu tố

quan trọng: Người quản lí dự án phần mềm giỏi và tổ có kĩ

năng cao trong miền họ đang làm việc. Về cơ bản, đây tất cả

đều là về con người và kĩ năng của họ. Qua 40 năm làm việc

trong công nghiệp phần mềm, tôi chưa bao giờ gặp một dự án

phần mềm thất bại vì vấn đề kĩ thuật nhưng tôi đã thấy nhiều

thất bại do "vấn đề con người" và đây là một khu vực những

người hàn lâm không biết rõ. Hầu hết các trường chỉ hội tụ vào

vấn đề kĩ thuật mà chưa bao giờ chuẩn bị cho sinh viên giải

quyết với "vấn đề con người”.

Ý tưởng rằng người kĩ thuật chỉ làm việc với máy tính là

hoàn toàn sai. Nhiều sinh viên nghĩ chừng nào họ còn có thể

viết được mã, họ có thể vẫn làm việc tốt, điều đó là sai. Ngay

khi sinh viên vào công nghiệp, họ sẽ thấy rằng họ sẽ dành đến

nửa thời gian gian để nói với người khác: thu lấy yêu cầu từ

người dùng, thảo luận về thiết kế, kiểm điểm cách tích hợp,

tranh cãi về ai sẽ thực hiện chức năng nào, phân tích mô đun

nào sẽ làm điều gì, và ai sẽ quản lí giao diện v.v. Họ sẽ biết

rằng mọi người đều có tình cảm và cách họ tương tác với mọi

114

người sẽ xác định cách họ có thể làm cho dự án thành công hay

không. Mọi người đều muốn được đối xử một cách kính trọng,

một cách nhã nhặn và nếu họ hiểu rằng nếu họ muốn dược đối

xử tốt thì họ phải đối xử với người khác cũng hệt như vậy.

Chung cuộc, họ sẽ biết rằng khi mọi người làm việc vất vả mà

không có nghỉ ngơi, họ sẽ tạo ra khiếm khuyết. Khi mọi người

quá bị căng thẳng, họ sẽ không nghĩ được rõ ràng và sẽ phạm

nhiều sai lầm hơn. Khi mọi người cảm thấy không thoải mái họ

sẽ dễ dàng tức giận và nếu họ ra đi trước khi dự án kết thúc, dự

án sẽ không đáp ứng được lịch biểu.

Người có kĩ năng cao có thể vượt qua các vấn đề kĩ thuật

và làm cho dự án thành công nhưng họ KHÔNG thể vượt qua

được việc quản lí kém. Quản lí kém phá huỷ mọi thứ. Nếu

người quản lí ước lượng thiếu về lịch biểu, mọi người sẽ

KHÔNG có đủ thời gian để làm việc tốt và chất lượng sẽ bị

ảnh hưởng. Nếu người quản lí KHÔNG biết cách quản lí mọi

người, tổ dự án sẽ có xung đột với nhau và dự án sẽ thất bại.

Nếu người quản lí không đối xử với mọi người một cách công

bằng, tổ sẽ KHÔNG làm việc với nhau tốt và tranh cãi trong

các thành viên tổ sẽ xảy ra v.v... Câu hỏi của tôi là bao nhiêu

người quản lí dự án được đào tạo về quản lí con người? Bao

nhiêu việc đào tạo dự án đã hội tụ vào "vấn đề con người"?

Bao nhiêu chương trình đại học có môn học về "kĩ năng con

người" hay "kĩ năng mềm"? Nếu trường không dạy bạn thì bạn

phải tìm cách khác để học thêm về kĩ năng này.

Người quản lí dự án giỏi thừa nhận tài năng của tổ mình

và hiểu rằng thành công của dự án phụ thuộc vào nỗ lực của

người của họ. Họ biết về rủi ro dự án và cách giảm nhẹ chúng.

Mọi dự án phần mềm đều có rủi ro nhưng người quản lí kém

KHÔNG biết về chúng hay không biết cách ngăn cản chúng.

Bởi vì rủi ro có thể xuất hiện ở bất kì đâu và bất kì lúc nào,

người quản lí kém thường sợ rồi trách mọi người của mình chứ

không hiểu trạng thái của dự án của họ. Khi mọi người bị đối

115

xử không công bằng, họ bực bội, căng thẳng và năng suất sẽ

giảm.

Các công ti thành công hiểu vấn đề con người cho nên họ

rất cẩn thận trong việc thuê người và chỉ chọn những người có

thể thành công trong môi trường làm việc của họ. Trong phỏng

vấn việc làm, họ sẽ hội tụ nhiều vào câu hỏi làm việc tổ và kĩ

năng con người hơn là câu hỏi kĩ thuật. Họ hiểu rằng phần lớn

sinh viên tốt nghiệp đều có nền tảng giáo dục kĩ thuật tốt cho

nên họ không hỏi về câu hỏi kĩ thuật. Họ biết rằng, nếu cần có

thể đào tạo lại mọi người về kĩ thuật. Nhưng họ sẽ cẩn thận với

cá tính, thái độ, hành vi bởi vì những đặc trưng này là khó thay

đổi. Các công ti thành công nhất có đầu tư vào đào tạo, không

chỉ kĩ thuật mà còn cả cách làm việc tổ và “kĩ năng con người”.

Mọi người trong các công ti này đều hiểu rằng việc làm của họ

không chỉ là chuyển giao sản phẩm mà còn là liên tục xây dựng

năng lực và làm việc cùng nhau để đạt tới mục đích chung:

Làm cho công ti thành công hơn.

Mọi công ti đều cần người hiểu việc của mình và biết

cách áp dụng kĩ năng của họ để xây dựng sản phẩm phần mềm.

Mọi công ti đều cần người quản lí có hiểu biết, những người

hiểu cách quản lí cả dự án và con người, người biết đủ về

doanh nghiệp để ra quyết định đúng.

Làm việc theo tổ

Trong cuộc họp cựu sinh viên tháng mười một, nhiều cựu

sinh viên tới gặp tôi. Khi họ kể cho tôi về việc làm và công

việc của họ, tôi hỏi họ về “Làm việc theo tổ”. Họ bảo tôi rằng

họ đã làm việc trong tổ xây dựng phần mềm nhưng khi tôi hỏi

thêm các câu hỏi, dường như là họ đã làm việc “trong nhóm”

mà KHÔNG “trong tổ”.

116

Tôi hỏi: “Mọi ngày, khi các bạn đi làm các bạn có biết

người khác trong tổ của bạn đang làm cái gì không?”, “Phần

nào của chương trình là của người đang ngồi cạnh bạn làm?”,

“Người yên tĩnh trong tổ của bạn đóng góp gì cho dự án? Ông

chủ của bạn đang làm việc cho bao nhiêu dự án?” Phần lớn

trong họ không thể trả lời được những câu hỏi này cho dù họ đã

làm việc cùng nhau trong cùng dự án.

Là một tổ, điều quan trọng là chia sẻ thông tin và điều

quan trọng là biết các thành viên khác của tổ đang làm gì và họ

cảm thấy thế nào về việc họ đang làm nó. Điều quan trọng là để

cho mọi người biết bạn đang làm gì là liệu bạn có cần giúp đỡ

hay không. Chúng ta học khi chúng ta làm việc cùng nhau vì

chúng ta vừa dạy lẫn nhau và vừa học lẫn nhau. Đó là điều

“làm việc trong tổ” nghĩa là gì. Đây có lẽ là mục đích quan

trọng nhất của "Làm theo tổ" khi mọi người thảo luận điều mọi

người khác trong nhóm đang làm việc bất kể tới vị trí và kinh

nghiệm của họ.

Tôi khuyên rằng mọi sáng, tổ để ra cuộc họp nửa giờ để

từng người nói ra điều họ đang làm vào lúc đó và họ cảm thấy

thế nào khi họ làm điều đó. Về căn bản đó là cách biết công

việc của nhau, điều có thể đưa tới nhiều chi tiết hơn và giúp

nhận diện vấn đề, nếu có, bên trong tổ. Khi thảo luận này diễn

ra, mọi người cảm thấy dễ dàng nói về vấn đề với nhau. Điều

đó cũng có nghĩa nếu ai đó phát triển cái gì đó tốt, tất cả chúng

ta đều biết về nó. Khi ai đó tự hào về cái gì đó mà họ đã làm thì

bằng việc thảo luận điều đó cho họ cảm giác là họ được đánh

giá cao. Và nếu ai đó gặp vấn đề, tổ có thể động viên hay gợi ý

vài ý tưởng trong cuộc họp này.

Mặc dầu các sách giáo khoa đa dạng được viết về qui

cách chỗ làm việc, tôi nghĩ không ai thích làm việc ở chỗ mà

họ KHÔNG thể nói được lẫn nhau và vấn đề phải báo cáo lên

mỗi người quản lí và KHÔNG được chia sẻ với bất kì ai khác.

117

“Làm việc theo tổ” ở chỗ làm việc có thể KHÔNG là cùng điều

như làm việc với bạn bè. Bạn KHÔNG cần đi xem phim, hát

“Karaoke”, hay chơi trò chơi máy tính nhưng bạn quả cần một

tổ nơi mọi người thấy thoải mái nói ra khi họ có vấn đề và cần

giúp đỡ và biết họ sẽ được giúp đỡ mà KHÔNG "bị cười". Bạn

không cần chia sẻ cuộc sống cá nhân với các thành viên tổ

nhưng nếu bạn có vấn đề cá nhân bạn nên có khả năng nói điều

đó và để mọi người có thông cảm. Về căn bản “Làm việc theo

tổ” ở chỗ làm việc là "Mọi người làm việc cùng nhau và hoà

hợp”.

Làm việc theo tổ cũng là chỗ để học kĩ năng mới. Khi

bạn không biết cái gì đó, bạn phải hỏi và sẽ có ai đó biết rõ hơn

bạn giúp bạn. Trong làm việc theo tổ, mọi người trong nhóm

đem tới những kinh nghiệm khác nhau và có cái gì đó để dạy

lẫn nhau. Với những người có kinh nghiệm, đây là cơ hội để

giúp đỡ và bầy tỏ quyền lãnh đạo và sự thân thiện của bạn. Họ

cũng có cơ hội để thực hành việc giải thích cái gì đó cho tổ của

mình và điều này làm phát triển kĩ năng trao đổi tốt hơn. Bằng

việc dạy cho ai đó, họ cũng sẽ làm lợi cho bản thân mình bởi vì

dạy cũng là cơ hội để kiểm điểm điều họ biết. Bằng việc chia

sẻ thông tin mọi ngày, tổ có cơ hội bước lùi lại không hội tụ

vào nhiệm vụ đặc thù để xem "bức tranh lớn". Mọi người có

thể tìm ra các thành viên tổ đang làm gì và làm sao điều đó có

liên quan tới điều họ đang làm, cho nên mọi người đều có ý

tưởng tốt hơn về điều họ đang đóng góp cho dự án. Bằng việc

chia sẻ và làm việc cùng nhau, tổ có thể đánh giá bất kì quyết

định nào đã được đưa ra và hành động mọi người cần thực hiện

sau khi cuộc họp được thực hiện.

Ngày nay “làm việc theo tổ” KHÔNG được cổ vũ trong

một số trường học nhưng điều đó đang thay đổi. Sinh viên

KHÔNG phải đợi tới lúc đi làm để xây dựng tổ. Tôi tin sinh

viên nên hình thành các tổ và chia sẻ thông tin với người khác

ngày nay.

118

Làm việc theo tổ và làm việc theo nhóm

Có khác biệt giữa "Làm việc theo tổ" và "Làm việc theo

nhóm". Là người quản lí phần mềm, việc của bạn là quản lí

mọi người và đảm bảo rằng họ "làm việc với nhau" để làm ra

sản phẩm đầy đủ theo thời gian, trong chi phí và có chất lượng

cao. Vì hầu hết các dự án phần mềm đều yêu cầu "làm việc

theo tổ", chính việc của bạn là hình dung ra liệu bạn có "nhóm"

hay "tổ", và tạo ra môi trường nơi họ có thể làm việc hiệu quả.

Tất nhiên, mọi người nói về tầm quan trọng của "làm việc theo

tổ" nhưng làm sao điều đó xảy ra được nếu họ chưa bao giờ

làm việc trong một tổ? Làm sao bạn có thể làm cho mọi người

làm việc cùng nhau nếu họ được đào tạo ở trường rằng công

việc cá nhân được coi là "tốt" còn làm việc theo tổ được coi là

"gian lận”? Làm việc theo tổ giống cái gì? Làm sao bạn biết

liệu đó là một tổ hay không? Ta hãy nhìn vào những tình huống

sau để hiểu khác biệt giữa “làm việc theo tổ” và “làm việc theo

nhóm”:

A là kĩ sư phần mềm và B là kĩ sư phần cứng, tất cả họ

đều tốt nghiệp từ cùng một đại học và làm việc cho cùng một

công ti. Họ thường gặp nhau để nói về trò chơi máy tính, âm

nhạc, và phim mà cả hai đều thích. Họ có là mọt tổ không? -

Không, họ KHÔNG là một tổ bởi vì họ làm việc trong nhóm

khác nhau. Hoạt động của họ trong công ti không có liên quan

với nhau và công việc của họ không yêu cầu họ làm việc cùng

nhau.

C và D cả hai đều là kĩ sư phần mềm, tất cả họ đều tốt

nghiệp từ cùng một đại học và làm việc cho cùng một công ti

nhưng trong các dự án khác nhau. Bởi vì cả hai dự án của họ

đang dùng công nghệ mới có tên XYZ, mỗi lần họ gặp nhau họ

119

đều nói về công nghệ này. Họ có là một tổ không? - Không, họ

KHÔNG là một tổ bởi vì họ làm việc trong các dự án khác

nhau. Họ đang nói với nhau về công nghệ mới trên cơ sở bạn

bè riêng, không như được yêu cầu.

E và F làm việc cho cùng công ti, trong cùng nhóm phần

mềm. Từng người đều có trách nhiệm phân biệt cho các khu

vực chức năng khác nhau. E hội tụ vào hệ phục vụ mạng còn F

chịu trách nhiệm về ứng dụng phần mềm. Họ gặp nhau đều đặn

trên cơ sở thông tin cho nhau về lịch biểu bảo trì mạng. Họ

phối hợp với nhau trên cơ sở sao lưu hàng ngày, cập nhật phần

mềm và an ninh. Họ có là một tổ không? - Không, họ KHÔNG

là một tổ bởi vì họ có việc làm khác nhau, làm việc ở các khu

vực khác nhau và không cần E và F cùng làm việc để đạt tới

cái gì chung. Họ chỉ phải "phối hợp" với nhau để đảm bảo mọi

sự làm việc tương ứng.

G và H cả hai đều là các kĩ sư phần mềm, họ làm việc

trên một dự án rất lớn với hàng trăm kĩ sư. Bởi vì nó quá lớn,

người quản lí chia dự án này thành nhiều nhóm nhỏ. Họ không

biết nhau vì họ làm việc trong các nhóm khác nhau nhưng họ

biết rằng một ngày nào đó, họ sẽ phải phối hợp các chức năng

với nhau khi họ tích hợp công việc của mình vào sản phẩm

cuối cùng. Họ có phải là một tổ không? - Không, dự án của họ

quá lớn và họ thậm chí không biết nhau. Tuy nhiên nhóm của

họ bên trong dự án lớn có thể vận hành như “tổ cộng tác”.

X và Y và sáu người khác làm việc trên một dự án phát

triển phần mềm. Họ có những kĩ năng khác nhau nhưng tất cả

đều cần để xây dựng sản phẩm phần mềm. Họ cam kết cùng

nhau với cùng mục đích dự án và làm việc rất chặt chẽ để

chuyển giao phần mềm trong việc lặp bốn tuần vì họ dùng

Scrum – phương pháp mau lẹ agile. Họ chia sẻ các mục đích,

họ đảm nhiệm lẫn nhau, và nếu họ không làm việc cùng nhau,

không chia sẻ thông tin với nhau, không giúp đỡ lẫn nhau, và

120

không học lẫn nhau, họ sẽ KHÔNG thành công và dự án có thể

thất bại. Họ có là tổ không? – Có, dứt khoát họ là một tổ và

làm việc tổ là quan trọng cho họ để thành công cùng nhau.

Vậy nên, là người quản lí phần mềm, làm sao bạn tổ chức

mọi người làm việc như một tổ? Sau đây là vài lời khuyên:

1) Bạn phải thiết lập mục đích dự án và đảm bảo rằng mọi

người làm việc cho dự án đều cam kết đạt tới mục đích

đó, cũng như các thành viên cam kết lẫn với nhau để giúp

nhau và chia sẻ việc đảm nhiệm.

2) Bạn phải kiểm tra các kĩ năng cần để làm công việc và

phân công người làm việc tương ứng theo kĩ năng và kinh

nghiệm của họ. Mọi người phải hiểu vai trò, trách nhiệm

và đảm nhiệm của mình.

3) Bạn phải phân tích công việc vì một số công việc một

người có thể hoàn thành từ đầu tới cuối nhưng một số

công việc đòi hỏi nhiều người làm việc cùng nhau và tích

hợp để tạo ra sản phẩm tập thể cuối cùng cố kết vì công

việc của họ tuỳ thuộc vào công việc của người khác.

4) Bạn phải họp đều đặn để thảo luận tình trạng dự án, kiểm

điểm công việc, và nhận diện các vấn đề và rủi ro trong

các thành viên tổ. Họ cũng cần chia sẻ điều đã được hoàn

thành và điều còn chưa và liệu có cần ai giúp gì thêm

không.

5) Bạn phải thiết lập hệ thống giám sát nơi người cấp cao

hay người có kinh nghiệm có thể giúp đào tạo và hỗ trợ

người khác.

Xây dựng tổ không xảy ra một cách ngẫu nhiên đâu. Nó

phải được lập kế hoạch và được đào tạo và việc của bạn như

người quản lí sẽ làm khác biệt giữa người quản "tổ" hay người

quản lí "nhóm". Như nhiều người trong các bạn có thể thấy sự

121

khác biệt giữa thể thao theo tổ như bóng đá, và thể thao cá

nhân như tennis. Không đội bóng nào thắng được gì nếu cầu

thủ chỉ muốn đá vào bóng. Là môn thể thao tổ, bóng đá bao giờ

cũng cần một huấn luyện viên người cung cấp chiến lược, kế

hoạch, và huấn luyện người của họ để phối hợp bởi vì tất cả họ

đều chia sẻ một mục đích chung: Thắng trận đấu. Cùng điều đó

có thể được áp dụng cho dự án phần mềm.

Làm việc trong tổ dự án lớn

Ngày nay nhiều dự án phần mềm là lớn và làm việc tổ

đang trở nên quan trọng hơn để giữ mọi người làm việc cùng

nhau. Không may nhiều người quản lí không được đào tạo về

làm việc theo tổ cho nên khi dự án gặp vấn đề, họ không biết

cách giải quyết nó. Điều đầu tiên người quản lí có thể làm là

tạo điều kiện cho cuộc họp nơi mọi người có thể nói với nhau.

Vài năm trước, tôi đã được yêu cầu tiếp quản một dự án

lớn trên hai trăm người phát triển bởi vì người quản lí dự án đã

rời bỏ việc này. Dự án này được chia thành bốn nhóm chức

năng chính nơi họ phải tương tác với nhau để làm cho công

việc được thực hiện. Sau vài ngày, tôi thấy rằng mối quan hệ

của họ với nhau là không tốt. Từng nhóm đều nhìn nhóm khác

như kẻ gây chuyện và cản trở tiến bộ của họ. Để giúp họ xây

dựng mối quan hệ hài hoà, tôi triệu tập một cuộc họp tại đó tôi

để họ chia thành những tổ nhỏ, với từng tổ bao gồm những

người của tất cả bốn nhóm.

Khi họ thành lập tổ, tôi yêu cầu họ tự giới thiệu mình cho

nhau. Bên cạnh tên họ và vai trò kĩ thuật, tôi cũng yêu cầu họ

nói đôi điều về bản thân họ như sở thích riêng, mối quan tâm

hay bất kì cái gì họ muốn chia sẻ. Tôi ngạc nhiên, một số thành

viên của bốn nhóm chưa bao giờ gặp gỡ và đó có lẽ là lí do mà

122

họ thấy lỗi ở nhau. Tôi yêu cầu họ nói chuyện với bạn thân

trong tổ về mọi vấn đề xoay quanh dự án để xác định xem họ

đang có vấn đề kĩ thuật gì, vấn đề khách hàng gì, hay vấn đề cá

nhân gì. Sau khi họ thảo luận từng vấn đề trong tổ nhỏ của họ,

tôi tụ tập họ lại như một nhóm để cho họ có thể báo cáo về

những phát kiến và khuyến nghị của họ.

Một khi họ bắt đầu nói, họ nhận ra họ đã hiểu về trách

nhiệm và hoạt động của nhau ít làm sao. Họ phát hiện ra rằng

một số vấn đề họ đã trách cứ lẫn nhau vì có những giải thích

hợp thức, như yêu cầu mơ hồ, mong đợi không rõ rệt, và ưu

tiên từng nhóm có mà nhóm khác lại không nhận biết do dựa

trên cái vào họ đã nhận được từ khách hàng. Một số các vấn đề

của họ có thể được giải quyết dễ dàng với vài thay đổi đơn

giản. Ngay cả một số vấn đề lớn hơn cũng có giải pháp mà có

thể mất thời gian lâu hơn nhưng không phải là không thể giải

được. Về toàn thể, có thể giải quyết các vấn đề này một khi họ

biết phải làm gì cũng như ai chịu trách nhiệm giải quyết chúng.

Thảo luận của họ về nhu cầu của mình đưa họ tới kết luận rõ

ràng: Dưới dạng trách nhiệm, họ có nhiều điểm chung, và có

thể hoàn thành được nhiều điều bằng việc cộng tác hơn là bằng

tranh cãi và trách móc lẫn nhau.

Để kết luận phiên này, tôi yêu cầu họ thảo luận họ sẽ làm

gì tiếp sau để cải tiến mối quan hệ của họ. Điều đầu tiên họ đi

tới là ở chỗ họ muốn tiếp tục đối thoại của họ qua những cuộc

họp đều đặn. Những gợi ý khác bao gồm dành thời gian trong

khu vực của nhau như người quan sát, tạo ra wiki để nắm bắt

mối quan tâm chung, và cam kết thảo luận các vấn đề thay vì

trách móc lẫn nhau.

Cuộc họp này chỉ kéo dài một ngày nhưng hầu hết những

người phát triển ra về với cảm nhận tích cực hơn và hiểu biết

sâu hơn về ba nhóm kia. Tất nhiên, cuộc họp này cũng chỉ là

điểm bắt đầu trong việc giải quyết vấn đề của tổ và cải tiến mối

123

quan hệ của họ. Tuy nhiên, họ đã hoàn thành nhiều điều đơn

giản chỉ bằng để thời gian nói và hiểu lẫn nhau.

Làm việc tổ của dự án

Người phát triển phần mềm thường phàn nàn về người

thiết kế: “Chúng tôi đã viết mã rồi thêm mã nữa nhưng bằng

cách nào đó chẳng cái gì làm việc. Chung cuộc chúng tôi thấy

rằng người thiết kế đã làm nó sai và phí thời gian của chúng

tôi.” Người kiểm thử thường phàn nàn về người phát triển:

“Chúng tôi đã kiểm thử và rồi nhiều kiểm thử nữa và tìm ra lỗi

rồi lại nhiều lỗi hơn. Chung cuộc chúng tôi thấy là người phát

triển thậm chí đã không kiểm thử mã riêng của họ mà để cho

chúng tôi làm mọi kiểm thử cho họ.”

Một số người làm phần mềm không làm việc của họ mà

đẩy nó sang pha tiếp để cho ai đó phải giải quyết nó. Mối quan

hệ căng thẳng giữa người thiết kế và người phát triển và người

kiểm thử là do việc phân tách bởi nhóm "chức năng" thay vì tổ

chức dự án thành tổ "qui trình" với các vai trò và trách nhiệm

được xác định.

Một số người quản lí dự án không biết cách xây dựng tổ

hiệu quả. Họ dựa trên các chức năng tổ chức hiện có như nhóm

phát triển, nhóm kiểm thử, nhóm thiết kế và tổ chức dự án của

họ theo cùng cách. Trong trường hợp này, từng chức năng hoàn

toàn bị tách rời. Người phát triển không tham gia vào công việc

thiết kế hay nói chuyện với người thiết kế mà đợi cho tới khi

thiết kế được làm xong và được trao cho họ để viết mã. Người

kiểm thử không tham gia vào công việc phát triển hay nói

chuyện với người phát triển mà đợi cho tới khi viết mã được

làm xong và được trao cho họ kiểm thử. Việc đẩy công việc

124

sang pha chức năng sau tạo ra sự không hài lòng và thất vọng

trong dự án phần mềm.

Có những cách để giảm căng thẳng này bằng việc làm

những thay đổi trong cách dự án được cấu trúc. Người quản lí

dự án phải nhấn mạnh vào làm việc tổ và tạo điều kiện trao đổi

trong các thành viên tổ. Người quản lí dự án phải xác định vai

trò, trách nhiệm cho các thành viên tổ nơi công việc của họ

được tích hợp. Chẳng hạn, người thiết kế chịu trách nhiệm về

thiết kế phần mềm nhưng phải khuyến khích người phát triển

cùng tham gia vào kiểm điểm thiết kế để hiểu cách thiết kế

được cấu trúc. Bằng việc hiểu thiết kế rõ, người phát triển có

thể viết mã của họ tốt hơn và nếu cần cung cấp phản hồi cho

người thiết kế trong khi kiểm điểm thiết kế. Cùng điều này

cũng có thể áp dụng được cho những người phát triển và người

kiểm thử để tránh hiểu lầm và lẫn lộn. Toàn bộ tổ dự án phải

làm việc cùng nhau hướng tới mục đích chung và mọi thành

viên đều phải tuân theo qui trình được xác định. Chính việc của

người quản lí dự án là tạo ra điều kiện làm việc thuận lợi cho tổ

bằng việc loại bỏ các chướng ngại và xung đột trong các thành

viên.

Nền tảng của tổ dự án là tin cậy. Mọi người phải cảm

thấy thoải mái thảo luận về quan điểm của họ và nhận phản

hồi. Dự án phải có họp tổ thường xuyên nơi các thành viên có

thể chia sẻ ý kiến của họ và đề nghị sự hỗ trợ từ người khác.

Người quản lí dự án phải chắc mọi người nhận ra những điểm

mạnh và điểm yếu của họ. Dự án tốt được tạo nên từ những cá

nhân có kĩ năng bổ sung cho nhau chứ không phải là các anh

hùng cá nhân. Mọi thành viên tổ đều phải đặt tổ lên đầu. Người

quản lí dự án phải chắc mọi thành viên hiểu cách đóng góp của

họ là có giá trị nhưng thành công tổng thể bao giờ cũng là

thành tựu của tổ.

125

Dự án phần mềm là công việc làm theo tổ. Không có lãnh

đạo dự án mạnh, dự án sẽ không thành công. Tổ chức dự án

tương ứng theo qui trình với các vai trò, trách nhiệm được xác

định rõ và các kiểm điểm nơi toàn tổ có thể tham gia vào là

cách tốt nhất để tránh "hồ nghi và đấu tranh nội bộ”.

Làm việc tổ trong lập kế hoạch dự án phần mềm

Quản lí dự án phần mềm là tuyển tập các kĩ thuật để quản

lí phát triển các kiểu đa dạng sản phẩm phần mềm. Nó bao gồm

chọn lựa vòng đời phát triển phần mềm; các phương pháp ước

lượng kích cỡ và lịch biểu dự án; tri thức và kĩ năng được cần

cho các thành viên tổ; theo dõi và quản lí rủi ro v.v. Về lí

thuyết, người quản lí dự án ra mọi quyết định và làm tài liệu

các chọn lựa trong bản kế hoạch dự án. Tuy nhiên, trong thực

tại, lập kế hoạch dự án phần mềm thường yêu cầu sự tham gia

của các thành viên tổ vì họ cũng có những kĩ năng và kinh

nghiệm nào đó. Có nhiều quyết định cần đưa ra trong thời kì

lập kế hoạch này với các cách tiếp cận khác nhau tới quản lí dự

án. Sau trên 30 năm quản lí dự án phần mềm, tôi tin rằng bằng

việc để các thành viên tổ cùng tham gia vào việc lập kế hoạch

dự án từ sớm sẽ cho tổ một cảm giác quyền làm chủ và tình

đồng chí và dễ dàng thu được cam kết từ họ.

Làm việc tổ không phải bao giờ cũng tới một cách tự

nhiên; nó phát triển sau khi các thành viên tổ đi tới biết lẫn

nhau và trở nên làm việc thoải mái cùng nhau. Các thành viên

tổ không cần phải là những người bạn tốt nhất, nhưng họ quả

cần có mối quan hệ chuyên nghiệp hiệu quả để cho làm việc tổ

phát triển và cần thời gian để xây dựng mối quan hệ này. Tôi

thường cố vấn cho người quản lí dự án để hẳn một ngày mỗi

tháng cho các hoạt động tổ bên ngoài công ti, nơi các thành

126

viên có thể thảnh thơi trong môi trường không làm việc và biết

lẫn nhau. Các hoạt động này có thể là cắm trại cả tổ, tới thăm

công ti khác, chuyến đi tới cuộc hội nghị hay bữa tiệc của tổ

nơi họ chơi trò chơi video cùng nhau và thi đấu để được giải

thưởng vui đùa v.v. Tổ chơi hay cùng nhau sẽ làm việc tốt cùng

nhau.

Quản lí dự án phần mềm hiệu quả là cốt yếu để đạt tới

kết quả thành công. Về lí thuyết, người quản lí dự án xây dựng

viễn kiến cho dự án và chắc rằng tổ được cam kết làm việc theo

viễn kiến đó. Tuy nhiên, trong thực tại điều sẽ tốt hơn là để cả

tổ cùng đi tới viễn kiến này cho dự án sau khi cân nhắc cả các

vấn đề kĩ thuật lẫn quản lí. Mục đích cho dự cần được đồng ý

bởi cả tổ. Trong khi quyết định về các mục đích, mọi yếu tố

phải được xem xét, kể cả tài nguyên, lịch biểu, chất lượng,

ngân sách v.v. Tổ dự án nên có cơ hội để tranh cãi về các yếu

tố này một cách đầy đủ để đi tới kết luận riêng của mình.

Tôi thường cố vấn cho người quản lí dự án đề nghị họ

hình dung ra thành công dự án sẽ giống như cái gì. Khi thành

viên tổ chia sẻ cách nhìn của họ và thảo luận điều họ muốn đạt

tới, họ đang phát triển viễn kiến cho dự án. Bằng việc cho phép

mọi thành viên tham gia vào, người quản lí dự án không chỉ có

viễn kiến về dự án mà còn có cam kết của tổ để làm cho dự án

thành công, bởi vì đó là điều họ muốn. Bằng việc cho từng

thành viên tổ cơ hội bày tỏ mối quan tâm của họ, tổ cảm thấy

thảnh thơi và sẵn lòng tham gia. Họ càng cảm thấy thoải mái,

họ sẽ càng có thể chia sẻ và mở ra trao đổi giữa các thành viên

tổ và, xem như kết quả, khuyến khích làm việc tổ.

Một khi tổ đồng ý với viễn kiến và mục đích, bước kế

tiếp là đề nghị tổ làm ra danh sách các việc cần được thực hiện.

Bằng việc cho phép các thành viên tổ chia các yêu cầu thành

những nhiệm vụ nhỏ hơn, tổ thực tại đang xây dựng cấu trúc

phân việc Work Breakdown Structure (WBS) cho dự án. Tôi

127

thường cố vấn cho người quản lí dự án hỏi: “Bạn nghĩ nhiệm

vụ này có đủ nhỏ để làm nó trong 30 giờ không? Nếu không thì

bạn có thể chia nó thành nhiệm vụ nhỏ hơn được không?" Bằng

việc khuyến khích tổ tham gia, các thành viên tổ cảm thấy rằng

họ đóng góp cho dự án và đó là "dự án của họ" mà họ muốn

thành công. Đến cuối của việc cộng tác tổ này, người quản lí

dự án không chỉ có danh sách của dự án về mọi việc phải được

thực hiện mà còn có khả năng phân công các thành viên cho

các việc làm. Khi bản thân họ làm việc chia nhỏ, họ cũng giả

định nhiệm vụ nào họ muốn làm. Tôi thường nói đùa rằng kĩ

thuật này có tên là "Một tên giết hai chim."

Sau khi yêu cầu dự án được phân chia thành những

nhiệm vụ nhỏ hơn, từng nhiệm vụ có thể được thực hiện bởi

một người trong một tuần, mọi điều người quản lí dự án cần là

thêm những nhiệm vụ này vào và khớp chúng trong lịch biểu

và sẵn sàng thảo luận với khách hàng về thực hiện dự án.

Chừng nào người quản lí dự án còn có thể kiểm soát được

mong đợi của khách hàng, theo dõi thực hiện nhiệm vụ với lề

lỗi nhỏ, dự án sẽ chạy ổn thoả.

Lập kế hoạch làm việc tổ

Làm việc tổ yêu cầu lập kế hoạch, tổ chức và thời gian để

phát triển tổ. Lắp ráp một nhóm người và tuyên bố họ là "tổ"

không làm cho họ làm việc cùng nhau được. Trong nhiều năm,

tôi đã thấy các tổ được thành lập theo cách đó. Khi có nhu cầu,

người quản lí lựa ra vài người và gọi họ là một "tổ". Thông

thường nhất, những người này được lựa chọn bởi vì họ sẵn có.

Họ là những người chỉ mới hoàn thành một dự án và còn chưa

được phân công vào dự án khác. Họ có thể là những người bị

128

loại khỏi một dự án vì họ không được cần tới, hay không có kĩ

năng đúng, hay họ không hoà hợp được với người khác.

Cách tốt nhất để lựa thành viên tổ là bằng mức độ kĩ

năng. Mọi dự án đều nên có cân bằng giữa các thành viên có

kinh nghiệm và thành viên ít kinh nghiệm. Người quản lí dự án

nên được phép lựa chọn thành viên tổ thay vì lấy ngẫu nhiên

bất kì ai sẵn có. Bằng việc làm điều đó, dự án sẽ có kĩ năng cần

thiết để làm công việc. Câu hỏi thường được hỏi là: điều gì xảy

ra nếu chúng ta không có người với kĩ năng đặc thù nhưng có

những người đang sẵn có? Hay “Điều gì xảy ra nếu người quản

lí dự án không muốn thuê người mới và yêu cầu bạn dùng

những người sẵn có, cho dù họ có thể không có kĩ năng cần

thiết?" Câu trả lời của tôi là: “Bạn có muốn bay trên máy bay

khi phi công không sẵn có cho nên tiếp viên sẽ lái máy bay

đó?”

Có người có kĩ năng là một trong vài yếu tố mấu chốt cho

thành công dự án. Yếu tố mấu chốt thứ hai là làm sao làm cho

những người này cùng làm việc với nhau như một tổ. Để làm

điều đó, dự án phải có mục đích chung để cho các thành viên tổ

có thể làm việc hướng tới nó. Điều này yêu cầu viễn kiến, một

phát biểu mô tả cho trạng thái tương lai mà các thành viên tổ có

thể hiểu và quyết tâm hỗ trợ nó. Nếu dự án không có viễn kiến

chung làm sao tổ có thể làm việc cùng nhau hướng tới mục

đích được? Khi Apple được thành lập, Steve Jobs đã giải thích

viễn kiến của ông ấy cho tổ: “Làm máy tính thành đảm đương

được để cho mọi hộ gia đình có thể mua một chiếc.” Viễn kiến

của ông ấy là xây dựng công ti máy tính mà có thể cạnh tranh

với các công ti máy tính khác như IBM và Digital Equipment,

và mục đích của ông ấy là giữ cho giá thành hợp lí để cho mọi

gia đình có thể mua nó. Thông điệp này là đơn giản và rõ ràng.

Tổ tại Apple hỗ trợ nhiệt tình cho nó và đó là cách Apple tăng

trưởng và làm biến đổi toàn bộ ngành công nghiệp máy tính.

Vài năm sau, Bill Gates cũng có viễn kiến: “Đưa máy tính cá

129

nhân vào mọi gia đình và chúng tất cả đều chạy phần mềm của

Microsoft.” Viễn kiến này cũng là rõ ràng và năng nổ. Ông

Gates đã không chỉ muốn bán phần mềm mà ông ấy muốn mọi

máy tính dùng phần mềm của ông ấy chứ không của ai khác.

Sau khi tổ hiểu và quyết tâm hỗ trợ cho viễn kiến và mục

đích, người quản lí dự án phải làm tài liệu viễn kiến, mục đích,

mục tiêu, chủ định, cấu trúc tổ, khách hàng và các thành viên tổ

cùng với vai trò, trách nhiệm và thẩm quyền trong kế hoạch dự

án. Điều này rất quan trọng để tránh bất kì hiểu lầm nào hay

xung đột vai trò về sau. Khi quản lí dự án phần mềm, tôi

thường để cho tổ xác định "căn cước" để chia sẻ với phần còn

lại của công ti. Các thành viên tổ đi tới một cái tên tổ và chúng

tôi chụp tấm hình như một tổ cùng nhau và bổ sung thêm mô tả

về tổ để đăng lên tường trong văn phòng của chúng tôi. Hoạt

động phụ này đem tới nhiều vui đùa và giúp cho tổ cảm thấy

gần nhau hơn. Tôi nhớ một số cái tên như “Quỉ viết mã” –

chúng tôi viết mã hay hơn bất kì tổ nào. “Phần mềm thần thoại”

– chúng tôi làm cho mọi thứ làm việc v.v. Một số người quản lí

gọi điều đó là "trẻ con" nhưng hoạt động này thực tế gióng

thẳng hành động của tổ với viễn kiến và mục đích của dự án.

Nó là lí do của tổ để tồn tại và giúp tổ cô đọng các ý tưởng này

vào một câu ngắn về họ là ai và họ làm gì.

Làm việc tổ yêu cầu vai trò và trách nhiệm rõ ràng. Nó

xác định công việc được phân công cho các thành viên tổ, và

liệt kê các mong đợi giữa các thành viên tổ. Nó phục vụ như

bản hướng dẫn khi tổ xây dựng sản phẩm phần mềm. Sau khi

giải thích viễn kiến và mục đích của dự án cho tổ, tôi bao giờ

cũng hỏi ý kiến họ về điều họ cảm thấy sẽ là quan trọng với họ.

Tôi viết những điều này ra rồi yêu cầu họ giải thích nó nghĩa là

gì. Sau khi tôi có gợi ý của mọi người, chúng tôi thảo luận các

ý tưởng này rồi tôi yêu cầu tổ chọn ra năm tới mười nguyên tắc

làm "nguyên tắc vận hành" để tổ tuân theo. Nhớ rằng đây là qui

tắc của họ, đây là điều họ chọn để tuân theo, và chúng không

130

tới từ người quản lí. Chẳng hạn: Bao giờ cũng đi họp tổ đúng

giờ. Bao giờ cũng hội tụ vào mục tiêu của cuộc họp tổ, không

nói về các chủ đề không liên quan. Chúng tôi làm việc như một

tổ, không như một cá nhân. Chúng tôi chia sẻ thông tin tự do

giữa các thành viên. Chúng tôi yêu cầu giúp đỡ khi cần và

chúng tôi sẵn lòng giúp đỡ khi được yêu cầu. Không ai có tri

thức đầy đủ về dự án, từng người trong chúng tôi đóng góp

phần chung ít hay nhiều. Sửa qui trình, không sửa người.

Chúng tôi chia sẻ cùng đích tới và đi tới đó cùng lúc.

Bằng việc có viễn kiến, mục đích, chủ định của tổ, căn

cước, vai trò và trách nhiệm, và qui tắc của tổ, tổ dự án sẵn

sàng làm việc cùng nhau.

Cách động viên tổ

Một người quản lí dự án hỏi tôi: “Là người quản lí dự án

mới được đề bạt, tôi muốn biết cách động viên tổ của tôi vì tôi

đồng ý với thầy rằng thành công của tôi phụ thuộc vào việc tổ

của tôi làm việc tốt thế nào.” Sau đây là lời khuyên của tôi:

Chúc mừng việc đề bạt của bạn, có nhiều cách bạn có thể

cải tiến việc đề bạt của mình, có nhiều cách bạn có thể chứng

minh hiệu năng tổ của mình. Sau đây là vài điều tôi đã dùng và

tôi hi vọng chúng có thể có ích cho bạn.

Bạn cần biết rằng các thành viên tổ của bạn chỉ làm việc

tốt nếu họ hiểu điều họ cần làm và tại sao. Bởi lí do này, tôi gợi

ý rằng lúc bắt đầu dự án, bạn để cho tổ của mình thảo luận

cùng nhau về tầm nhìn dự án, các mục tiêu, phân công trong tổ

và lịch biểu. Phải chắc rằng tổ của bạn hiểu rõ chúng và dự án

là mấu chốt cho thành công của công ti như thế nào. Tôi chắc

một số thành viên có thể có những câu hỏi về lịch biểu hay vai

131

trò của họ. Bạn cần giải thích cho họ về mong đợi của bạn và

sự sẵn lòng làm việc với họ theo nhiệm vụ được phân công;

bạn sẽ thu được sự tin cậy của họ và cam kết của họ.

Sau khi tổ gặp gỡ, thu xếp gặp gỡ cá nhân với từng thành

viên tổ để cho bạn có thể thảo luận về phân công cá nhân của

họ, điều bạn cần từ họ để giúp đỡ bạn trong dựa án này. Phải

đảm bảo họ có "Mô tả việc" rõ ràng và họ biết bạn sẽ đo hiệu

năng của họ thế nào trong dự án. Hỏi họ cách họ thích được

quản lí, cái gì động viên họ và làm sao bạn có thể hỗ trợ họ

trong các vai trò của họ. Đây thực sự là về xây dựng mối quan

hệ với họ, vì từng thành viên có thể có các mục đích khác nhau

và mục tiêu nghề nghiệp khác nhau. Bạn cần biết họ rõ để bạn

có thể hỗ trợ họ.

Dự án phần mềm bao giờ cũng có sức ép đặc biệt theo

lịch biểu. Tuy nhiên, bạn cần cho họ thời gian làm việc tốt nhất

theo khả năng của họ. Nếu sức ép tăng lên, bạn cần cho họ

nhiều thời gian hơn là ít bởi vì đó là việc của bạn để bảo vệ họ.

Tôi biết làm điều này là gian nan lắm, nhưng nếu bạn đặt sức

ép lên họ, hiệu năng của họ sẽ bị giảm, thay vì cải tiến và dự án

của bạn sẽ bị rắc rối. Tất nhiên, bạn cần đo hiệu năng của họ

một cách đều đặn. Là người quản lí, bạn phải gặp họ theo cách

cá nhân từng tuần để thảo luận những thành tựu của họ, các vấn

đề đang là gì và làm sao họ có thể cải tiến được. Bạn cần nói

cởi mở với họ, ngẫu nhiên và giữ thái độ xây dựng mọi lúc.

ĐỪNG BAO GIỜ biểu lộ giận dữ của bạn hay buộc tội bất kì

ai, điều đó không bao giờ có tác dụng trong bất kì tình huống

nào. Là người quản lí, bạn cần tích cực, tái khẳng định và hỗ

trợ họ vào mọi lúc, cho dù dự án có bị trễ. Qui tắc vàng là:

“Thành công của bạn phụ thuộc vào hiệu năng của họ, công

việc của bạn là hỗ trợ và KHÔNG thêm gánh nặng cho việc

của họ.”

132

Bởi vì dự án phần mềm bao giờ cũng có vấn đề với thay

đổi nên bạn phải xây dựng “Bộ đệm” trong lịch biểu của mình

để bảo vệ tổ. Là người quản lí bạn phải học cách thương lượng

với người quản lí cấp cao hay khách hàng về thời gian được

phép. Giả sử rằng bạn ước lượng dự án cần mười tháng thì bạn

sẽ cần thêm quãng 20% bộ đệm vào dự án để cho bạn thương

lượng khoảng thời gian 12 tháng để cho phép những thay đổi

không chắc chắn hay trong trường hợp đổi nhân viên hay cần

thêm thời gian cho đào tạo tri thức và kĩ năng. Đây thực sự là

việc giảm nhẹ rủi ro mà người quản lí dự án phải biết.

Nhiều người quản lí quá bận rộn và bao giờ cũng bị dưới

sức ép lớn tới mức họ quên mất ca ngợi thành công của tổ. Mọi

lúc tổ chuyển giao một sản phẩm có chất lượng, hoàn thành

một nhiệm vụ khó khăn đúng thời gian, bạn phải chúc mừng

họ. Bạn phải làm điều đó như một tổ, không như cá nhân cho

nên bạn xây dựng tinh thần tổ để mọi người làm việc như một

tổ. Bạn phải thưởng cho tổ bằng việc cho tổ đi ăn cùng nhau, đi

xem biểu diễn, liên hoan và cho phép họ tham gia hoạt động xã

hội để cho tình bạn mới có thể được hình thành. Tổ của bạn

càng có mối ràng buộc mạnh với nhau, họ càng có thể làm việc

cùng nhau như một đơn vị cố kết và đạt tới mục tiêu bạn đã đặt

ra. Tất nhiên, có vài người làm việc chăm chỉ và xứng đáng

thưởng thêm nhưng bạn KHÔNG muốn tạo ra "bầu không khí

cạnh tranh" giữa các thành viên tổ. Tôi thưởng cho tổ của tôi

bằng việc cho họ thời gian nghỉ. Chẳng hạn, nếu một người

làm việc chăm chỉ, tôi cho họ nghỉ ngày thứ sáu để cho họ có

thể có kì nghỉ cuối tuần dài, điều này sẽ tăng cường động cơ

của họ và làm tăng hiệu quả của họ. Loại thưởng này là tích

cực và không tạo ra đối thủ trong các thành viên tổ bởi vì mọi

người đều hiểu rằng khi bạn làm việc chăm chỉ, bạn xứng đáng

có thời gian nghỉ nào đó. Khi thành viên tổ bao giờ cũng giúp

đỡ lẫn nhau, họ không thấy đe doạ nào về loại phần thưởng

này. ĐỪNG BAO GIỜ thảo luận việc lên lương hay thưởng

133

với tổ, điều đó sẽ tạo ra vấn đề. Điều đó KHÔNG phải là việc

của người quản lí dự án mà của quản lí cấp cao hay người chủ

công ti.

Trong công ti phần mềm điển hình, khi một tổ hoàn thành

dự án, các thành viên tổ được phân công sang các dự án khác

ngay. Điều này có thể phá vỡ mối quan hệ của tổ đặc biệt nếu

tổ thành công cho nên tôi khuyến cáo rằng nếu có thể được,

công ti phải giữ tổ không bị động chạm nhiều nhất có thể được.

Công thức của tôi là 70% của tổ phải được giữ cùng nhau với

30% các thành viên tổ là mới cho mọi dự án mới. Trong trường

hợp này, các thành viên tổ có thể đào tạo các thành viên mới

hay có cơ hội để xây dựng tổ tương ứng. Phải có điểm ngắt

giữa các dự án cho nên thành viên tổ có thể nghỉ ngơi và học

những điều mới. Công thức của tôi là cho mọi thành viên tổ

thành công từ 2 tới 4 tuần trong lớp đào tạo. Không có thời kì

nghỉ, các thành viên tổ sẽ mang sức ép của họ vào dự án tiếp và

thực tế bạn "làm mòn mỏi" tổ tốt nhất mà bạn có. Cho nên là

người quản lí dự án, bạn cần giúp cho tổ “bắt đầu tươi mới”

bằng việc cho họ khoảng thời gian nghỉ ở cuối dự án và thưởng

cho họ bằng việc để họ cải tiến kĩ năng của mình trong đào tạo.

Tôi hi vọng rằng việc chia sẻ với các bạn một số kinh

nghiệm của tôi; bạn sẽ có khả năng cải tiến hiệu năng của tổ

bạn và cơ hội thành công của bạn.

Làm việc nhóm và làm việc tổ

Làm việc tổ là cái gì đó nhiều người nói tới nhưng rất

khó đạt tới trong dự án phần mềm. Lí do mà mọi người không

làm việc tốt trong tổ vì khác biệt trong ý kiến và mục đích. Tôi

đã thấy nhiều thành viên tổ đấu tranh chống lại nhau vì họ bảo

134

vệ ý kiến riêng của họ hay tin rằng họ là đúng và mọi người

khác là sai.

Mọi người sẽ làm việc cùng nhau như một NHÓM nếu

có những vai trò, trách nhiệm và thẩm quyền được xác định rõ.

Chẳng hạn trong dự án phần mềm bạn có các vai trò như người

quản lí dự án, người lãnh đạo kĩ thuật, người thiết kế phần

mềm, người lập trình, người kiểm thử, chuyên viên đảm bảo

chất lượng v.v. Chừng nào mọi người còn tuân theo các qui tắc,

hiểu vai trò và trách nhiệm của họ thì nhóm làm việc được.

Điều đó nghĩa là mọi người đang làm điều được mong đợi về

từng vai trò đó, nhưng không cái gì vượt ra ngoài. Cách tiếp

cận này có tác dụng tốt trong nhà máy, trong dây chuyền lắp

ráp, trong công việc thủ công khi qui trình được xác định rõ và

thấy được cao. Trong phần mềm thỉnh thoảng nó không làm

việc tốt. Lí do là vai trò và trách nhiệm tạo ra "biên giới nhân

tạo" giữa các thành viên nhóm. Chẳng hạn, người lập trình viết

mã và "quẳng" sang cho người kiểm thử kiểm thử chúng. Cách

nhìn của họ là "chúng tôi hoàn thành việc của mình như được

yêu cầu và để người khác làm việc của họ.” Cách tiếp cận

LÀM VIỆC NHÓM này cho phép mọi người duy trì cách nhìn

RIÊNG của họ, vị trí RIÊNG của họ mà không có nhiều tương

tác. Nó giúp tránh các xung đột giữa các thành viên và cho

phép họ ở lại BÊN TRONG kĩ năng giới hạn riêng của họ mà

không cần làm cái gì bên ngoài vai trò của họ.

Mọi người sẽ làm việc với nhau như một TỔ khi họ phụ

thuộc vào kĩ năng và tri thức của nhau để tạo ra cái gì đó là

ngoại lệ và bên ngoài năng lực cá nhân của họ. Điều này bao

gồm nhiều học tập, hiểu biết, thương lượng, thách thức và tin

cậy vào sức mạnh của mọi người lẫn nhau. Trong loại CÔNG

VIỆC TỔ này, mọi người có thể thu được ích lợi lớn. Chẳng

hạn: Người lập trình tin cậy vào đảm bảo chất lượng kiểm điểm

công việc của họ để xác định vấn đề để cho họ có thể sửa chữa

chúng sớm hơn làm nảy sinh sản phẩm chất lượng cao. Không

135

có đào tạo đúng, không có trao đổi đúng, không có quản lí

đúng, làm việc tổ sẽ KHÔNG xảy ra. Làm việc tổ là khó bởi vì

các thành viên tổ phải giải thích cho người khác điều họ làm và

tại sao. Đồng thời, họ phải sẵn lòng nghe các gợi ý và sẵn lòng

thay đổi cách họ làm mọi thứ. Điều đó nghĩa là mọi thành viên

tổ đều phải có mối quan tâm lớn tới người khác và cách họ làm

việc của họ bằng tâm trí cởi mở, thái độ cởi mở, để cho họ có

thể cải tiến.

Lúc bắt đầu dự án, các thành viên tổ không biết lẫn nhau.

Họ tới từ các nền tảng đa dạng, với các kĩ năng và kinh nghiệm

khác nhau và họ cũng có những thiên kiến nào đó. Họ cần thời

gian để hiểu lẫn nhau, xây dựng mối quan hệ và cuối cùng tin

cậy lẫn nhau. Đó là lí do tại sao đào tạo làm việc tổ vào lúc bắt

đầu dự án là quan trọng thế. Tôi biết nhiều người quản lí

thường bỏ qua việc đào tạo này để tiết kiệm tiền. Đó là sai lầm

lớn vì họ sẽ phải giải quyết với xung đột cá nhân, vấn đề và

tranh đấu giữa các thành viên trong dự án về sau. Làm việc tổ

đặc biệt khó cho những người đã từng làm việc trong LÀM

VIỆC NHÓM một thời gian lâu, bởi vì có xu hướng quay trở

lại cách làm cũ với mọi sự. Chẳng hạn, người lãnh đạo kĩ thuật

có xu hướng nói với những người khác điều phải làm thay vì

lắng nghe họ. Người lập trình không quan tâm tới cách người

kiểm thử kiểm công việc của họ nhưng sẽ nổi giận khi người

kiểm thử tìm ra nhiều lỗi.

Khi nhiều người hơn muốn dùng cách tiếp cận Agile, lời

báo trước của tôi là cách tiếp cận này yêu cầu mọi người từ

những kinh nghiệp khác nhau làm việc cùng nhau như một TỔ.

Bằng việc tạo ra tổ “tự tổ chức”, mọi người phải làm việc cùng

nhau bởi vì những rào chắn cá nhân như vai trò, trách nhiệm

mất đi. Không có đào tạo cách làm việc tổ, cách tiếp cận này sẽ

THẤT BẠI. Vì phải mất thời gian cho tổ làm việc cùng nhau,

người quản lí cấp cao phải hội tụ vào việc có đào tạo cho mọi

dự án Agile. Đào tạo kĩ thuật cho phương pháp Agile là

136

KHÔNG đủ. Đào tạo LÀM VIỆC THEO TỔ phải là ưu tiên

thứ nhất nếu bạn muốn thành công.

Các thực hành Agile như lập kế hoạch đưa ra tăng dần,

lập kế hoạch chặng nước rút, và họp hàng ngày cung cấp thời

gian cho tổ làm việc cùng nhau và xây dựng quan hệ lẫn nhau.

Họp hàng ngày giúp các thành viên tổ nhận diện các cơ hội

tiềm năng mà họ có thể tương tác lẫn nhau. Chặng nước rút và

lập kế hoạch đưa ra cung cấp nhiều cơ hội có cấu trúc cho công

việc tổ. Qua “hoạt động nội quan”, các thành viên tổ có thể

kiểm điểm về công việc của họ và cung cấp phản hồi cho nhau

cho nên cùng nhau tổ có thể liên tục cải tiến. Tổ đánh giá kết

quả từ sản phẩm của chặng nước rút để xác định liệu làm việc

theo tổ thêm có thể tạo ra kết quả tốt hơn không. Mọi chặng

nước rút sẽ cho tổ cảm giác về hoàn thành và động viên tổ về

giá trị của làm việc theo tổ. Điều đó bao giờ cũng là điều kì

diệu khi người phát triển, người chủ sản phẩm, thầy scrum,

người kiểm thử cùng nhau xây dựng để tạo ra cái gì đó có chất

lượng cao, đúng thời gian và trong chi phí. Đó là lí do tại sao

đào tạo LÀM VIỆC THEO TỔ có lẽ là quan trọng nhất trong

phần mềm vì nó xác định thành công hay thất bại của dự án.

Tương tác với các thành viên tổ

Người phát triển phần mềm bao giờ cũng tương tác với

những người khác như thành viên tổ, người lãnh đạo tổ, người

quản lí dự án, người dùng và khách hàng. Trong công nghiệp

phần mềm, kĩ năng trao đổi là rất quan trọng. Người phát triển

phải có năng lực tương tác với mọi người theo cách kính trọng

quyền và ý kiến của người khác trong khi vẫn bảo vệ quyền

riêng của bạn. Tuần trước, một cựu sinh viên phàn nàn với tôi

rằng cho dù cô ấy làm việc rất chăm chỉ nhưng ai đó khác vẫn

137

thường cướp công của cô ấy. Sau khi hỏi cô ấy vài câu hỏi chi

tiết về tình huống, tôi bảo cô ấy rằng cho dù cô ấy rất giỏi trong

thiết kế, viết mã, và kiểm thử nhưng không thể để tình trạng

trao đổi kém của cô ấy với tổ cô ấy và người quản lí của cô ấy

được. Bởi vì cô ấy hiếm khi nói ra cái gì nên ai đó khác trong

tổ cô ấy lợi dụng điều đó và cướp công cô ấy. Cô ấy thừa nhận

rằng cô ấy thường ngồi yên tĩnh và ưa thích làm việc một mình

bởi vì cô ấy nhút nhát. Là một người châu Á, cô ấy được dạy

phải lễ phép và kính trọng cho nên trong cuộc họp tổ, cô ấy

hiếm khi nói với bất kì ai vì cô ấy không biết nói gì.

Tôi bảo cô ấy: “Khi bạn bắt đầu làm việc trong công

nghiệp phần mềm, kĩ năng kĩ thuật chiếm 70% và kĩ năng mềm

chiếm 30% của tổng kĩ năng của bạn. Sau vài năm, kĩ năng

mềm chiếm 50% các kĩ năng của bạn rồi khi bạn đạt tới vị trí

cao hơn như người quản lí dự án hay giám đốc thì kĩ năng mềm

là 70%. Bạn cần hiểu rằng các thành viên tổ sẽ đánh giá bạn

theo cách bạn tương tác với họ. Bạn phải đổi cách nghĩ và thái

độ của bạn vì bạn có quyền được nghe và ý kiến của bạn được

xem xét. Nếu bạn sợ nói ra, tự hỏi mình “Điều tồi tệ nhất có thể

xảy ra là gì nếu mình nói ra ý kiến của mình?” Trong thế giới

cạnh tranh này, có những người sẽ lợi dụng người khác và bạn

không muốn là nạn nhân của họ. Bạn không phải tranh đấu với

họ nhưng bạn phải sẵn lòng diễn đạt ý kiến và cảm giác của

bạn bằng việc nói cái gì đó cho người quản lí của bạn kiểu như

“Tôi đã làm loại việc này, tôi đã hoàn thành điều đó trong lịch

biểu và tôi muốn ông biết” hay “Vì tôi đã làm việc này và tôi

muốn thảo luận thêm với ông về phân công việc tiếp.” Trong

làm việc tổ, bạn có thể yêu cầu sự giúp đỡ nếu bạn cần hay sẵn

lòng giúp ai đó nhưng có thể có lúc bạn cũng phải nói "Không"

với ai đó nhưng bạn có thể nói theo cách thức tế nhị kiểu như

“Tôi muốn giúp anh, nhưng tôi đã có việc mà tôi phải làm cho

xong.”

138

Cô ấy dường như cảm thấy thoải mái với lời khuyên của

tôi, cho nên tôi tiếp tục: “Khi người khác nhận ra rằng bạn có

cái gì đó muốn nói, họ sẽ nghe. Khi bạn có ý tưởng và gợi ý

quan trọng mà mọi người sẽ được lợi bởi việc nghe điều bạn

phải nói cho họ thì họ sẽ đối xử với bạn với nhiều kính trọng

hơn. Bạn phải đi từng bước dần dần để cải tiến kĩ năng trao đổi

của bạn, đặc biệt trong khu vực bạn gặp khó khăn. Điều quan

trọng là lắng nghe cẩn thận khi người khác nói nữa. Đừng ngắt

lời họ ngay cả khi bạn muốn nói cái gì đó mà đợi cho tới khi họ

kết thúc ý nghĩ của họ. Nếu bạn không đồng ý với ý kiến của

họ, đừng tranh cãi mà ghi lại và chờ đợi đến lượt bạn nói. Khi

bạn có cơ hội nói, đừng nói quá nhanh mà nói một cách lễ phép

và rõ ràng. Dùng lời đơn giản và dễ hiểu và tránh các từ kĩ

thuật mà mọi người có thể không biết. Trong khi nói, đừng có

vẻ quá hùng hổ mà diễn đạt tình cảm của bạn một cách bình

thản và rõ ràng. Tránh đọc bản ghi chép của bạn mà nhìn vào

mọi người trong phòng. Điều này sẽ giúp cho người khác cảm

thấy thoải mái với bạn. Tự tin về điều bạn nói và làm cho tổ

của bạn và người quản lí của bạn biết rằng bạn muốn được đối

xử bình đẳng và không người nào có thể lợi dụng được.

Công nhân có kĩ năng cho công việc dự án

Mục tiêu then chốt của mọi dự án phần mềm là đáp ứng

nhu cầu của khách hàng. Điều khách hàng muốn là tổ dự án

chuyển giao sản phẩm tương ứng theo lịch biểu, trong chi phí,

và có chất lượng cao. Tuy nhiên, điều quan trọng nhất với

nhiều người quản lí dự án là lịch biểu dự án. Lí do là đơn giản:

nếu dự án không đáp ứng lịch biểu, người quản lí cấp cao biết

về điều đó và người quản lí dự án sẽ bị đánh giá là thất bại hay

không có năng lực. Trong hầu hết các doanh nghiệp, người

quản lí cấp cao bao giờ cũng muốn biết liệu dự án có tiến triển

139

không và liệu nó có kết thúc đúng thời gian không. Nếu dự án

bị chậm, điều đó có nghĩa là sẽ có chi phí thêm cho công ti.

Chi phí là yếu tố quan trọng khác trong dự án phần mềm.

Người quản lí dự án giỏi bao giờ cũng làm cái gì đó về vấn đề

chi phí khi họ thấy chúng, không phải ở cuối khi không ai còn

có thể làm được cái gì. Nếu khách hàng muốn thay đổi thì

người quản lí dự án phải tính toán nó có thể tốn chi phí bao

nhiêu và thương lượng với khách hàng trước khi đồng ý với bất

kì công việc thêm nào. Thay đổi cũng sẽ tác động lên lịch biểu,

cho nên sẽ là khôn ngoan để yêu cầu thêm thời gian để thực

hiện chúng nữa. Tuy nhiên, ít người quản lí dự án biết cách

thương lượng và thậm chí còn sợ đương đầu với khách hàng.

Đó là lí do tại sao với thay đổi, dự án thường lâm vào vấn đề

với cả chi phí và lịch biểu và người quản lí cấp cao bao giờ

cũng giận dữ với người quản lí dự án. Để tránh điều này, tôi

khuyến cáo rằng người quản lí dự án nên theo các lớp học về kĩ

năng thương lượng để cho họ có thể thảo luận với khách hàng

về yêu cầu thêm trong khi thực hiện dự án.

Trong khi chi phí và lịch biểu là quan trọng, sản phẩm

phần mềm phải làm việc được. Nếu dự án kết thúc theo lịch và

trong chi phí nhưng sản phẩm không làm việc thì đó là thảm

hoạ. Theo định nghĩa, chất lượng nghĩa là sản phẩm thoả mãn

yêu cầu chức năng và vận hành không có hay có lỗi tối thiếu.

Tất nhiên, người quản lí dự án là thành công nếu người đó có

thể chuyển giao sản phẩm chất lượng đúng thời gian và trong

chi phí nhưng ngày nay ít công ti có thể nhất quán làm điều

này. Câu hỏi là được cho chọn lựa, mọi người sẽ chọn cái gì? -

Chuyển giao sản phẩm chất lượng nhưng chậm hay sản phẩm

chất lượng thấp nhưng đúng thời gian?

Với người quản lí dự án, câu trả lời có lẽ là “Sản phẩm

chất lượng kém nhưng đáp ứng lịch biểu.” Với người phát

triển, câu trả lời có lẽ là: “Sản phẩm chất lượng cao nhưng nó

140

bị chậm.” Với người chủ doanh nghiệp thì câu trả lời có lẽ là:

“Chừng nào không tốn phí cho tôi thêm, thì không thành vấn

đề.” Khách hàng thì sao? Câu trả lời có lẽ sẽ là: “Tôi muốn nó

nhanh, tôi muốn chất lượng, tôi muốn tất cả các tính năng mà

tôi đã đòi hỏi và hoàn thành tương ứng theo lịch biểu. Nếu

KHÔNG, thì có nhiều công ti phần mềm trên khắp thế giới.

Nhiều công ti trong số họ đã chứng tỏ năng lực làm công việc

chất lượng theo lịch biểu, trong chi phí và họ đang tìm thêm cơ

hội kinh doanh. Tôi có thể cần nói chuyện với họ."

Nếu bạn là người chủ công ti ước muốn của bạn sẽ là gì?

Bạn có muốn xây dựng sản phẩm chất lượng, đúng thời gian,

trong chi phí không? Bạn có muốn khách hàng được thoả mãn

không? Bạn có muốn tăng trưởng công ti của bạn không? Cách

DUY NHẤT để làm điều đó là thuê người phát triển phần mềm

và người quản lí dự án có kĩ năng. Câu hỏi là bạn tìm họ ở đâu?

Tất nhiên, bạn quảng cáo trên báo chí hay trực tuyến về những

người có kĩ năng nhưng làm sao bạn biết các ứng cử viên là

người phát triển có kĩ năng? Mọi người xin việc làm đều làm

hết sức bằng việc nói rằng họ có bằng cấp mà bạn cần và kĩ

năng mà bạn muốn. Bạn có cho rằng mười lăm phút phỏng vấn

sẽ cho phép bạn tìm ra người có kĩ năng đúng không? Nếu câu

trả lời là “Có” thì bạn là lạc quan đấy vì theo nghiên cứu gần

đây, cơ hội kiếm được người đúng là ngẫu nhiên như mua vé

xổ số vậy. Thuê người cũng rất tốn kém, phải tốm tiền để

quảng cáo, mất thời gian kiểm mọi lí lịch và đơn xin việc.

Trong hàng trăm lí lịch, bạn có thể tìm được vài ứng cử viên có

phẩm chất. Cũng mất thời gian để phỏng vấn họ và lựa chọn

họ. Đây là cách thông thường để thuê người và mọi công ti đều

làm điều đó.

Tuy nhiên, các công ti phần mềm hàng đầu có cách tốt

hơn. Các công ti như Microsoft, Google, Oracle, Intel và IBM

hiếm khi quảng cáo cho việc còn để mở. Họ bao giờ cũng cộng

tác với các đại học hàng đầu được lựa chọn để thiết kế ra

141

chương trình đào tạo đáp ứng cho nhu cầu của họ. Mỗi mùa hè,

họ thuê hàng trăm nghìn sinh viên làm việc trong công ti của

họ để cho họ có thể quan sát và chọn lọc những sinh viên giỏi

nhất mà họ muốn thuê. Bằng việc làm điều đó, họ hoàn toàn

biết về đào tạo đại học, tri thức và kĩ năng của sinh viên để cho

họ có thể đảm bảo có kĩ năng họ cần cho công ti của họ. “Thực

tập mùa hè” là cách tốt nhất để có được công nhân tốt và nó có

tác dụng tốt cho mọi người. Sinh viên có được kinh nghiệm họ

cần. Công ti có được công nhân "chi phí thấp" để làm công

việc thực và cơ hội để quan sát họ. Các đại học nhận được cái

vào từ công nghiệp về kĩ năng nào họ phải hội tụ vào để cho họ

có thể cải tiến chương trình đào tạo của họ. Bằng cộng tác với

công nghiệp, trường học có cơ hội tốt hơn để có sinh viên tốt

nghiệp của họ làm việc với các công ti này ngay lập tức. Một

cách điển hình, sinh viên trong năm thứ ba và thứ tư được đưa

vào công ti trong mùa hè. Họ được trao công việc và được

người quản lí quan sát và nếu họ được chọn, phần lớn trong họ

nhận được "đề nghị việc làm” trước khi họ trở về trường. Bằng

việc làm điều đó, công ti có thể tiết kiệm nhiều thời gian, nỗ

lực và chi phí của việc thuê công nhân và sinh viên tốt nghiệp

để có công nhân có kĩ năng cao và có động cơ để làm tăng

trưởng công ti.

142

143

4. Quản lí dự án theo kế hoạch

Vòng đời phát triển phần mềm và Vòng đời quản lí dự án

Có khác biệt giữa "Vòng đời phát triển phần mềm" và

"Vòng đời quản lí dự án". The Vòng đời phát triển phần mềm

là tập các hoạt động có liên quan để tạo ra sản phẩm hay dịch

vụ. Vòng đời quản lí dự án giải quyết với phạm vi lớn hơn

nhiều so với dự án như hiểu nhu cầu khách hàng, thiết lập môi

trường dự án, đảm bảo dự án được gióng thẳng với chiến lược

và mục đích công ti, lập kế hoạch và ngân sách, ra quyết định

mua hay dựng, thực hiện dự án, quản lí và kiểm soát dự án, và

báo cáo tình trạng cho cấp quản lí và khách hàng v.v.

Vòng đời quản lí dự án bao gồm năm pha: Pha khởi đầu,

Thực hiện, Kiểm soát và Đóng. Không thành vấn đề kiểu vòng

đời phát triển dự án nào (Thác đổ, xoáy ốc, đưa ra tăng dần

v.v.) bạn vẫn áp dụng cùng năm pha này cho việc quản lí dự

án.

1. Pha khởi đầu: Trong pha này, người quản lí dự án phải làm

việc cùng khách hàng để xác định nhu cầu. Đây có thể là

vấn đề doanh nghiệp hay cơ hội kinh doanh. Người quản lí

144

dự án phải phân tích nhu cầu với giải pháp để xác định liệu

nó là có thể được hay không. Điều đó bao gồm các vấn đề

kĩ thuật (chúng ta có thể làm dự án này không?) và biện

minh doanh nghiệp (chúng ta có nên làm dự án này không?

Nó có hiệu quả chi phí không?). Nếu giải pháp được chấp

thuận, người quản lí dự án phải thiết lập môi trường dự án,

thu lấy ngân sách, thuê thành viên tổ, và làm tài liệu yêu

cầu v.v. trước khi chuyển vào pha lập kế hoạch.

2. Pha lập kế hoạch: Trong pha này, các yêu cầu dự án được

phân tích chi tiết và chia ra thành các nhiệm vụ nhỏ hơn

(Cấu trúc phân việc). Thành viên tổ được phân công cho

các vai trò và trách nhiệm và cho mọi công việc cần được

thực hiện. Bản kế hoạch dự án được tạo ra để làm tài liệu

cho mọi hoạt động, nhiệm vụ, sự phụ thuộc và khuôn khổ

thời gian. Người quản lí dự án ước lượng chi phí cho lao

động, trang thiết bị và chi phí vật tư thành ngân sách dự án.

Ngân sách này được dùng để giám sát và kiểm soát chi tiêu

chi phí trong khi thực hiện dự án. Người quản lí dự án cũng

ước lượng thời gian để hoàn thành mọi nhiệm vụ và chuẩn

bị lịch biểu cùng các thành viên tổ. Cùng nhau, họ nhận

diện và cố gắng giải quyết với mọi rủi ro có thể tạo ra vấn

đề cho dự án. Họ cũng phát triển bản kế hoạch chất lượng;

cung cấp mục tiêu chất lượng, đảm bảo chất lượng và kiểm

soát cách đo cùng với danh sách các tiêu chí cần được đáp

ứng. Khi mọi thứ được thực hiện, người quản lí dự án thiết

lập kế hoạch trao đổi mô tả thông tin được cần và lịch

chuyển giao để giữ cho khách hàng và cấp quản lí được

thông tin.

3. Pha thực hiện: Trong pha này, bản kế hoạch dự án được

thực hiện. (Đây là chỗ vòng đời phát triển phần mềm bắt

đầu với những người phát triển thực hiện thiết kế, viết mã,

kiểm thử v.v.). Những hoạt động này liên tục được giám sát

và điều chỉnh khi cần. Người quản lí dự án sẽ dành hầu hết

145

thời gian của họ theo dõi các hoạt động theo kế hoạch để

chắc chắn dự án đang tiến triển tương ứng.

4. Pha kiểm soát: Trong pha này, người quản lí dự án duy trì

kiểm soát chiều hướng của dự án bằng việc đo hiệu năng

của hoạt động dự án. Có các báo cáo tình trạng hàng tuần

và kiểm điểm theo cột mốc được nhận diện trong kế hoạch

dự án nơi người quản lí dự án có thể giám sát tiến bộ dự án.

Báo cáo trạng thái được hội tụ vào chi phí, lịch biểu và chất

lượng công việc. Một khi mọi nhiệm vụ đã được thực hiện,

phần mềm cuối cùng có thể được tạo ra và khi khách hàng

chấp nhận sản phẩm cuối cùng, dự án sẵn sàng cho việc

đóng lại.

5. Pha đóng: Trong pha này, hoạt động chính là: chuyển giao

sản phẩm cuối cho khách hàng; cung cấp tài liệu cho doanh

nghiệp; và trao đổi việc đóng dự án với cấp quản lí và

khách hàng. Người quản lí dự án cũng tiến hạnh kiểm điểm

hậu dự án để cân nhắc cái gì diễn ra tốt và cái gì không.

Qua bài học này, người quản lí và thành viên tổ dự án cả

tiến kĩ năng và kinh nghiệm của họ, điều có ích cho dự án

tương lai.

Qui trình cho dự án phần mềm

Tuần trước, một người bạn có sở hữu một công ti phần

mềm gọi điện thoại cho tôi: “Sau khi làm việc cho một công ti

phần mềm trong sáu năm, tôi bắt đầu công ti riêng của tôi. Tôi

tuyển những sinh viên tốt nghiệp hàng đầu và trả lương hậu

cho họ, tôi có một số khách hàng và công ti của tôi phát triển

nhanh chóng. Tuy nhiên, hiện thời chúng tôi có vấn đề với lỗi

nhiều và trượt lịch biểu. Nếu những vấn đề này tiếp tục, công ti

của tôi sẽ lâm vào rắc rối. Là người chủ, tôi thường dành hầu

146

hết thời gian của mình với khách hàng để đưa vào việc kinh

doanh mới cho nên làm sao tôi có thể sửa được những vấn đề

này và tiếp tục phát triển công ti của tôi?"

Tôi nói với ông ấy: “Ông không thể bỏ qua các vấn đề

bằng việc dành thời gian cho khách hàng và để mọi người làm

việc mà không có giám sát nào. Việc sửa lỗi yêu cầu phần lớn

thời gian của người phát triển và có lẽ nó là lí do chính cho

việc trượt lịch biểu. Điều khẩn thiết cần làm bây giờ là hội tụ

vào việc tìm và sửa lỗi. Tôi nghĩ ông cần tiến hành kiểm điểm

thường xuyên hơn để nhận diện và sửa chúng sớm nhất có thể

được. Trong các cuộc kiểm điểm này, ông phải để mọi người

phát triển và người kiểm thử tới và biết cách lỗi đã bị phạm

phải thế nào và làm sao sửa được chúng."

Ông ta hỏi: “Sao lại mọi người? Tôi không để người

không làm việc trong cùng dự án tham dự họp kiểm điểm được.

Điều đó là phí thời gian.”

Tôi giải thích: “Về căn bản, những người phát triển trong

dự án đều có kiểm điểm giữa họ để tìm và sửa lỗi. Đây là

những lỗi 'không biết" với người phát triển khác, người đã

không tham dự buổi kiểm điểm và họ có thể phạm phải cùng

sai lầm lần nữa. Lí do cho "kiểm điểm dành riêng" là người

phát triển không muốn người khác tìm ra lỗi của họ. Tuy nhiên,

là người chủ công ti, ông phải coi kiểm điểm như quá trình học

tập cho nên mọi lỗi được tìm ra đều là cơ hội học tập. Người

phát triển càng biết nhiều về nguyên nhân của lỗi, càng dễ

tránh phạm phải chúng.

Ông ấy dường như thoả mãn: “Được, tôi có thể bắt đầu

bằng kiểm điểm và để mọi người phát triển tới và học. Tôi có

thể làm cái gì khác?"

Tôi tiếp tục: “Dự án phần mềm điển hình bắt đầu với ít

người, rồi khi nó tiến triển, ông thêm người cho nó. Phần lớn

147

các môn quản lí dự án bao giờ cũng dạy cách tiếp cận dần dần

và nó có tác dụng tốt với doanh nghiệp xây dựng. Ông chỉ cần

vài nhà kiến trúc lúc ban đầu nhưng khi các pha kiến trúc và

thiết kế được thực hiện rồi, công ti đem nhiều công nhân vào

xây dựng. Tuy nhiên, với dự án phần mềm cách tiếp cận này

không có tác dụng tốt. Sẽ là tốt hơn nếu ông có thể bắt đầu với

đầy đủ cán bộ từ đầu."

Ông ấy ngạc nhiên: “Sao chúng tôi cần nhiều người hơn

ngay từ những pha đầu? Điều đó sẽ tốn nhiều tiền hơn.”

Tôi giải thích: “Đó là lí do tại sao nhiều dự án phần mềm

có vấn đề. Ông bắt đầu chỉ với ít người làm việc với yêu cầu

của khách hàng và rồi họ hiểu điều gì phải làm. Rồi họ bắt đầu

kiến trúc và thiết kế hệ thống. Vì họ làm việc trên dự án từ đầu,

họ hoà hợp tốt. Khi ông thêm nhiều người vào dự án về sau,

người mới không có thời gian để biết lẫn nhau hay hình thành

cách làm việc tổ hiệu quả. Xung đột cá nhân có thể xảy ra trong

thời gian này. Người mới không có thời gian hiểu yêu cầu

nhưng họ phải thiết kế và viết mã ngay lập tức."

"Họ có thể không biết cách tích hợp công việc của họ với

kiến trúc hệ thống. Họ có thể không hiểu chức năng chi tiết của

hệ thống nhưng họ phải làm cho việc của mình được thực hiện

trong lịch biểu bị giới hạn. Đây là chỗ nhiều sai lầm bị phạm

phải. Người mới được mong đợi hình dung ra mọi thứ theo

cách riêng của họ trong thời gian rất ngắn. Tất nhiên, họ có

những câu hỏi và họ phải hỏi người khác, nhưng người có đó

từ lúc bắt đầu để giúp. Điều này có thể làm gián đoạn công việc

dự án bởi vì thời gian để dạy người mới về dự án bao giờ cũng

mất lâu hơn mong đợi, cho nên dự án có thể bị chậm. Do sức

ép lịch biểu, mọi người phải vội vàng làm cho việc của mình

được thực hiện và nhiều lỗi bị phạm phải."

148

Ông ấy gật đầu: “Tôi chưa bao giờ nghĩ về điều đó, ông

có thể đúng. Có những vấn đề giữa người mới và người cũ, họ

tranh cãi mọi lúc. Tôi cần làm gì khác?"

Tôi bảo ông ấy: “Vòng đời phần mềm truyền thống là

cách tiếp cận tuần tự giống như dây chuyền lắp ráp trong công

nghiệp. Trước hết, kĩ sư yêu cầu làm việc với khách hàng để

làm tài liệu cho tất cả các yêu cầu. Kiến trúc sư hệ thống sẽ

hình dung ra cách hệ thống làm việc dựa trên các yêu cầu này.

Thế rồi người phát triển sẽ thiết kế và rồi viết mã. Tiếp đó,

người kiểm thử sẽ kiểm thử chúng. Sau khi tất cả kiểm thử đã

được hoàn thành, sản phẩm phần mềm được đưa ra cho khách

hàng. Chúng ta hãy nhìn lại cách tiếp cận này. Kĩ sư yêu cầu

chỉ quan tâm tới điều khách hàng cần và hội tụ vào việc làm tài

liệu cho chúng. Kiến trúc sư đặt mọi thứ dựa trên tài liệu yêu

cầu và thiết kế hệ thống. Người phát triển hội tụ phần lớn vào

viết mã dựa trên thiết kế. Người kiểm thử không chăm nom tới

cách toàn thể hệ thống được thiết kế mà chỉ vào các trường hợp

kiểm thử, nơi kiểm xem mã có qua được kiểm thử hay không.

Điều gì sẽ xảy ra khi yêu cầu sai? Điều gì sẽ xảy ra nếu thiết kế

bị thiếu chức năng nào đó? Điều gì sẽ xảy ra khi người kiểm

thử kiểm vào các mã mà không được làm tài liệu trong tài liệu

yêu cầu? Điều gì sẽ xảy ra nếu có những chức năng mới được

thêm vào trong các phút cuối. Nếu người kiểm thử không biết

về chức năng mới, họ không thể kiểm thử được nó. Đó là lí do

cho cách tiếp cận kiểu dây chuyền lắp ráp này thực sự không

có tác dụng tốt với phần mềm. Vòng đời thác đổ là tốt cho

giảng dạy, nó dễ hiểu nhưng nó không có tác dụng tốt trong

công nghiệp.

Bạn tôi ngần ngại một chốc: “Đó là điều chúng tôi vẫn

làm sao? Ông gợi ý gì để chúng tôi làm khác đi?”

Tôi giải thích: “Đó là lí do tại sao đào tạo kĩ nghệ phần

mềm yêu cầu rằng công ti phải xác định qui trình phát triển tích

149

hợp đầy đủ mọi thành viên tổ sớm nhất có thể được. Qui trình

được xác định không phải là một hoạt động theo chuỗi mà là

tăng dần với mọi vai trò được tích hợp đầy đủ. Nó rất quan

trọng để bắt đầu với đầy đủ cán bộ hay ít nhất với đa số người

lúc ban đầu. Người quản lí dự án phải thảo luận về vai trò,

trách nhiệm của từng thành viên tổ và điều từng người cần làm

để thành công. Đào tạo làm việc theo tổ lúc bắt đầu sẽ tạo ra

một số các thảo luận, nơi các thành viên tổ có thể nói về điều

họ cần từ nhau. Rồi tổ trình bày nhu cầu của họ, quan điểm của

họ với người quản lí dự án. Sau vài tuần đầu trong dự án, tổ có

thể đi tới qui trình mà mọi người đều biết nhiệm vụ của họ là

gì, và cách để làm việc với chúng. Thông tin này nên được làm

tài liệu như một phần của qui trình tổ dự án nơi mọi người đều

biết ưu tiên dự án là gì, và cách ra quyết định để thoả mãn nhu

cầu dự án.

Bạn tôi hỏi: “Sao ông cần vài tuần đầu để xây dựng dự

án? Có quá nhiều không?"

Tôi trả lời: “Làm việc theo tổ là hoạt động quan trọng

nhất trong dự án phần mềm. Ông không thể mong đợi rằng

những người không biết lẫn nhau sẽ hài hoà với nhau trong vài

ngày. Họ cần thời gian để biết lẫn nhau và đi tới qui trình được

xác định mà mọi người sẽ đồng ý tuân theo. Thay vì qui trình

tuần tự, ông nên yêu cầu tổ phát triển một qui trình song hành

để xây dựng phần mềm. Chẳng hạn, kiến trúc sư xác địnhg kiến

trúc tổng thể của sản phẩm phần mềm, xác định các tính năng

cho từng bản đưa ra và tiến hành kiểm điểm ban đầu nơi mọi

thành viên tổ cần phải tham dự. Đây là lúc mọi người nên thực

sự học về khía cạnh kĩ thuật và hỏi các câu hỏi nếu cần. Sau

kiểm điểm ban đầu, nhóm những người phát triển sẽ bắt đầu

thiết kế ngay lập tức khi nhóm khác làm việc trên kiểm thử hệ

thống. Sau thiết kế, tổ phải tiến hành kiểm điểm thiết kế cùng

với toàn tổ và nhóm kiểm thử phải chắc chắn rằng kiểm thử hệ

thống của họ sẽ làm việc tốt với thiết kế này. Nếu mọi sự tốt

150

lành, thì tổ có thể bắt đầu thiết kế chi tiết và thực hiện, đồng

thời nhóm kiểm thử sẽ làm việc trên việc phát triển các kiểm

thử chức năng. Mọi pha đều phải có kiểm điểm với sự tham dự

của toàn tổ để chắc chắn họ phối hợp các hoạt động của mình

và công việc của họ được tích hợp đầy đủ. Đến lúc mã được

viết ra và kiểm thử (đơn vị được kiểm thử), mọi người sẽ sẵn

sàng cho kiểm điểm mã. Mọi mã đều phải trải qua kiểm điểm

trước khi được đưa vào hệ thống quản lí cấu hình. Sau khi mã

được kiểm, người kiểm thử sẽ bắt đầu kiểm và bất kì lỗi nào

được nhận diện đều phải được sửa theo qui trình thay đổi. Về

căn bản, mọi thứ trong dự án đều phải tuân theo qui trình song

hành được xác định tốt và người quản lí dự án phải dùng độ đo

để trắc nghiệm mọi thứ. Lịch biểu dự án nên được dõi vết theo

ước lượng gốc, mọi yêu cầu đều phải được quản lí, cũng như

mọi lỗi. Bằng việc để mọi người tham gia sớm và giúp xác

định qui trình, các thành viên tổ hiểu công việc của họ và

những cột mốc chính. Họ biết điều họ cần làm từng tuần và trắc

nghiệm công việc của họ lẫn nhau. Trong nỗ lực cộng tác này,

các thành viên tổ có thể lưu ý khi vấn đề xuất hiện và có hành

động sửa chữa thay vì chờ đợi cho tới pha sau. Nếu tổ tuân theo

qui trình được xác định tốt, họ có thể cải tiến cách họ giải

quyết các lỗi và việc trượt lịch, và cuối cùng mọi dự án sẽ được

cải tiến.

Bạn tôi nói: “Vậy ông nghĩ làm việc tổ và qui trình là

nhân tố mấu chốt cho cải tiến dự án à?”

Tôi bảo ông ấy: “Vâng, dứt khoát rồi. Qui trình phần

mềm có thể có vẻ đơn giản nhưng chúng biểu thị cho thay đổi

mạnh mẽ trong cách mọi người làm công việc của họ. Với làm

việc theo tổ, mọi người nhận ra rằng công việc của họ là nỗ lực

cộng tác nơi mọi thứ đều phải được tích hợp. Đây là chìa khoá

cho thành công của mọi công việc phát triển, không ai làm việc

một mình. Với kỉ luật kĩ nghệ phần mềm, họ sẽ biết phải làm gì

và làm gì tiếp. Có kỉ luật là bước đầu tiên để phát triển công ti

151

của ông. Bên cạnh những qui trình kĩ thuật này, ông có thể cải

tiến qui trình quản lí của ông nữa. Chừng nào chưa có qui trình

phát triển được được xác định tốt, sẽ khó mà biết ai đang làm

gì hay ai là tốt và ai không tốt. Qui trình được xác định tốt cho

phép người quản lí dự án hiểu công việc phát triển và vai trò,

trách nhiệm của từng thành viên tổ. Điều này cho người quản lí

cơ hội làm việc với những người có công việc không chấp chấp

nhận được, và thưởng cho những người hoàn thành công việc

xuất sắc.

Qui trình đơn giản cho dự án nhỏ

Hôm qua, một sinh viên đã tốt nghiệp vài năm trước tới

gặp tôi. Anh ta nói: “Em đã đi làm cho một công ti phần mềm

lớn trong vài năm, bây giờ em muốn bắt đầu công ti riêng của

em. Em có đủ kinh nghiệm và một số tiền mà em đã tiết kiệm

trong những năm qua. Em cũng có một vài người phát triển

người sẵn lòng làm việc cho em. Em lập kế hoạch bắt đầu công

ti của em bằng việc làm các dự án nhỏ và dần dần phát triển

công ti. Em cần lời khuyên của thầy để thiết lập qui trình tốt để

phát triển phần mềm có chất lượng với chi phí thấp nhất có thể

được. Vì em chỉ có "vốn giới hạn", em không muốn phí hoài

nói. Thầy nghĩ điều đó có thể được thực hiện không?”

Sau khi suy nghĩ một chốc, tôi bảo anh ta: “Điều tốt là

bắt đầu từ các dự án nhỏ. Nếu bạn có người phát triển có kĩ

năng, bạn có cơ hội tốt hơn để thành công và xây dựng danh

tiếng cho công ti của bạn. Bắt đầu từ những cái nhỏ cũng có thể

tiết kiệm được tiền bạc bởi vì nếu bạn phạm sai lầm nó sẽ

không là thảm hoạ và bạn có thể phục hồi được. Phần lớn mọi

người thường bắt đầu công ti bằng việc hội tụ vào khía cạnh kĩ

thuật. Đó KHÔNG phải là ý tưởng hay. Là người chủ công ti,

152

bạn phải hội tụ vào khách hàng đầu tiên. Ưu tiên của bạn phải

bắt đầu với việc có khách hàng và hiểu yêu cầu của họ. Đây là

việc của bạn bởi vì không hiểu nhu cầu của khách hàng và

không đáp ứng mong đợi của khách hàng là nguyên nhân chính

cho thất bại doanh nghiệp. Bạn phải tiếp xúc với khách hàng,

thu được yêu cầu, phân tích và làm tài liệu chúng cẩn thận. Bạn

phải trắc nghiệm với khách hàng để chắc rằng bạn hiểu rõ yêu

cầu và mong đợi của họ. Khách hàng phải chấp thuận tài liệu

yêu cầu trước khi bạn bắt đầu làm bất kì việc nào. Trong khi có

nhiều công cụ làm yêu cầu có tính thương mại bán sẵn trên thị

trường, để tiết kiệm tiền, tôi gợi ý rằng bạn dùng Microsoft

Word hay Excel cho việc làm tài liệu yêu cầu của bạn.”

Anh ta đồng ý: “Điều đó là dễ dàng, phần lớn các máy

tính đều tới với Window 7 và Microsoft Office nạp sẵn cho

nêm em sẽ không phải chi thêm tiền phụ.”

Tôi tiếp tục: “Nếu khách hàng chấp thuận yêu cầu và kí

hợp đồng thì bạn có thể bắt đầu dự án. Với những dự án nhỏ

bạn nên dùng cách tiếp cận phát triển Agile bởi vì nó ít rủi ro

hơn các phương pháp khác. Bạn có thể tránh rủi ro của thay đổi

yêu cầu thường xuyên điều thường xảy ra trong công nghiệp.”

Anh ta gật đầu: “Một ý hay là dùng cách tiếp cận Agile,

em biết “Phương pháp Scrum.”

Tôi bảo anh ta: “Trong trường hợp đó, bạn phải chia yêu

cầu thành những nhiệm vụ nhỏ hơn dùng kĩ thuật Cấu trúc

phân việc (WBS). Bạn cần ước lượng công việc cần được thực

hiện, phân công chúng cho người phát triển của bạn và xác

định ngày chuyển giao. Với cách tiếp cận Agile dùng Scrum,

bạn phải xác định công việc được yêu cầu cho từng đợt nước

rút Sprint (2-4 tuần). Bạn có thể dùng Microsoft’s Excel để lập

kế hoạch công việc và làm tài liệu cho mọi nhiệm vụ. Nếu bạn

có dự án lớn hơn, bạn có thể dùng công cụ "Project" của

Microsoft. Điều này sẽ cho phép bạn làm một số việc lập kế

153

hoạch lại trong trường hợp thay đổi yêu cầu hay nếu khách

hàng quyết định thay đổi một số chức năng vào phút chót. Bạn

cũng có thể dùng công cụ “Bugzilla” để theo dõi và ghi lại các

lỗi, những nâng cao, hay thay đổi yêu cầu. Bugzilla là chọn lựa

phổ biến trong những người phát triển phần mềm và nó dễ

dùng với đào tạo tối thiểu.

Anh ta đồng ý: “Em có thể kiếm những công cụ này và

để cho người phát triển của em bắt đầu dùng chúng.”

Tôi tiếp tục: “Làm việc tổ trong Agile là rất quan trọng.

Trước khi bắt đầu dự án bạn phải đào tạo mọi người phát triển

về cách làm việc trong tổ. Cho dù họ có thể đã biết "Scrum”,

bạn vẫn cần nhắc nhở họ về cách tiếp cận này và vai trò của họ

để chắc không có hiểu lầm nào. Với dự án Scrum, có ba vai trò:

Người chủ sản phẩm là người chịu trách nhiệm cho khía cạnh

doanh nghiệp của dự án và ra quyết định về sản phẩm. Thầy

Scrum người quản lí qui trình phát triển, giúp người phát triển

làm việc cùng nhau, tạo điều kiện họp và theo dõi tiến độ và

vấn đề. Tổ phát triển người xây dựng ra sản phẩm bằng làm

việc cùng nhau để đạt tới mục đích của dự án. Vì dự án của bạn

là nhỏ, bạn nên giả định giữ cả vai trò người chủ sản phẩm và

thầy Scrum.”

Anh ta gật đầu: “Vâng, em không thể đảm đương được

việc có nhiều người chừng nào em còn chưa thể phát triển công

ti lên. Gợi ý của thầy rất hợp lí.”

Tôi tiếp tục: “Điều quan trọng là thiết lập việc tách bạch

môi trường phát triển, môi trường kiểm thử, và môi trường sản

xuất sớm để tránh việc trộn lẫn công việc. Đây là khái niệm

đơn giản nhưng tôi đã thấy nhiều công ti nhỏ phạm sai lầm và

trộn lẫn công việc của họ với những phiên bản sai, phần mềm

đã kiểm thử để cùng phần mềm chưa kiểm thử, cho nên tôi

nghĩa đáng nhắc bạn. Bạn phải thiết lập hệ thống kiểm soát

nguồn để tạo điều kiện cho qui trình phát triển và lưu trữ mọi

154

công việc đầy đủ. Quản lí cấu hình phần mềm là quan trọng bởi

vì là công ti nhỏ, bạn có thể không có qui trình kiểm soát mạnh

và những người được chỉ định để thực hiện vai trò quản lí cấu

hình. Mọi người phát triển phải hiểu cơ sở về làm sao "Kiểm

vào" công việc của họ và "Kiểm ra" khi chúng được thực hiện

để tránh dư thừa, khi nào họ làm thay đổi cho phần mềm.

Trong khi có một số công cụ sẵn có, bạn vẫn có thể dùng

phương pháp thủ công bằng việc để những người phát triển gõ

vào tình trạng số hiệu nhiệm vụ như “Mở”, “Đóng” và “Đã

phân công” để cho mọi người có thể theo dõi thay đổi một cách

dễ dàng. Để tiết kiệm tiền, bạn có thể xem xét dùng công cụ

"nguồn mở" như CVS cho quản lí cấu hình. Là công ti nhỏ, bạn

không cần phải mua những công cụ đắt tiền nhưng ĐỪNG

BAO GIỜ thử tiết kiệm tiền bằng việc giảm đào tạo. Để thành

công bạn phải hội tụ vào việc cải tiến kĩ năng của những người

phát triển của bạn bằng những đào tạo phụ vì công nghệ

thường xuyên thay đổi.”

Anh ta nói: “Em bao giờ cũng nhớ việc dạy của thầy từ

nhiều năm trước, học liên tục là chìa khoá cho thành công

trong khu vực này.”

Tôi kết luận: “Tôi vui là bạn nhớ điều đó. Phần còn lại

của qui trình phát triển là đơn giản. Với từng dự án, bạn sẽ có

cuộc họp hàng ngày để phân công công việc cho người phát

triển vì bạn xây dựng phần mềm trên cơ sở hàng ngày. Bạn sẽ

có những người phát triển viết mã, thực hiện kiểm thử đơn vị,

tạo ra trường hợp kiểm thử và các kiểm thử tự động để chạy

mọi đêm sau khi phần mềm được dựng ban ngày và kiểm tra

các lỗi. Là thầy Scrum, bạn phải giám sát tiến độ trên cơ sở

hàng ngày, kiểm tra các lỗi và để chúng được sửa và phải chắc

mọi người đang làm nhiệm vụ được phân công của họ một cách

tương ứng. Nếu bạn kiểm soát qui trình phát triển đơn giản này

tốt thì bạn có thể mong đợi sản phẩm chất lượng cao. Bạn

KHÔNG cần mua nhiều công cụ, bạn KHÔNG cần chi tiền vào

155

bất kì cái gì phụ thêm, yếu tố quan trọng là có qui trình đơn

giản mà mọi người hiểu và cam kết tuân theo nó cho công việc

của họ. Một qui trình có chất lượng KHÔNG phải phức tạp,

hay tinh vi mà nó phải được mọi người phát triển hiểu. Chìa

khoá để thành công trong cách tiếp cận Agile KHÔNG phải là

kĩ thuật mà là làm việc tổ và trao đổi. Bạn phải động viên mọi

người thảo luận vấn đề, hỗ trợ lẫn nhau và sẵn lòng giải quyết

vấn đề khi chúng tới. Tổ phải có mục đích chung, biết vai trò

và trách nhiệm của họ và tuân theo qui trình chất lượng và đạo

đức để hỗ trợ cho công ti đạt tới việc thoả mãn khách hàng.

Lập kế hoạch dự án phần mềm-1

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

156

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

157

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

158

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

159

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.

Lập kế hoạch dự án phần mềm-2

Một người phát triển phần mềm tới gặp tôi: “Tôi được đề

bạt làm quản lí một dự án nhỏ. Ông chủ của tôi bảo tôi hội tụ

vào viết mã chứ KHÔNG lập kế hoạch bởi vì lập kế hoạch là

phí thời gian. Viết mã sẽ cho tổ nhiều thời gian hơn để hoàn

160

thành dự án. Câu hỏi của tôi là làm sao lập kế hoạch cho dự án

mà không phí thời gian và vẫn đạt tới thành công?”

Tôi bảo anh ta: “Tôi biết một số người quản lí thích để

người của họ viết mã sớm nhất có thể được. Họ tin “Phần mềm

là mã” cho nên viết mã nghĩa là người của họ đang làm việc.

Đó là sai lầm lớn bởi vì họ không hiểu giá trị của lập kế hoạch.

Lập kế hoạch dự án là bản lộ trình về cách quản lí dự án và đạt

tới mục đích. Không có lập kế hoạch bạn chỉ phản ứng với bất

kì cái gì xảy ra và không bao giờ có khả năng kiểm soát dự án

của bạn. Dự án thành công khi nó đáp ứng nhu cầu của khách

hàng. Bạn KHÔNG BAO GIỜ nên viết mã trước khi bạn thực

sự hiểu khách hàng cần cái gì. Cách tốt nhất để làm điều này là

bằng tiến hành phỏng vấn khách hàng để hiểu “NHU CẦU

THỰC”. Khách hàng thường nói nhiều thứ, một số thứ là "nhu

cầu" nhưng một số thứ chỉ là "ước ao" mà có thể không quan

trọng, Bạn phải tìm ra cái gì là "nhu cầu thực" mà bạn phải làm

và cái gì là "ước ao" mà bạn có thể làm nó nếu bạn có thời

gian.”

Anh ta dường như ngạc nhiên: “Tôi đã không biết phỏng

vấn khách hàng là một phần của lập kế hoạch dự án?”

Tôi giải thích: “Vâng, lập kế hoạch bao giờ cũng bắt đầu

với hiểu nhu cầu của khách hàng. Không có hiểu biết này, bạn

không thể lập kế hoạch cho bất kì cái gì và điều đó là phí thời

gian. Một khi bạn có mọi nhu cầu hay yêu cầu từ khách hàng

thì bước tiếp là ưu tiên hoá chúng. Bạn phải liệt kê mọi yêu cầu

từ những khoản mục quan trọng nhất tới ít quan trọng nhất rồi

thẩm tra danh sách này với khách hàng để chắc chắn họ đồng ý

với bạn. Từ danh sách được ưu tiên hoá, bước tiếp là phát triển

một tập các mục đích có thể đo được cho từng khoản mục.

Điều này sẽ giúp bạn giám sát tiến độ dự án khi từng lúc một

mục đích được đạt tới. Một khi bạn đã thiết lập một tập các

mục đích, bạn có thể làm tài liệu chúng trong kế hoạch dự án."

161

Anh ta bình luận: “Vậy lập kế hoạch dự án là về làm tài

liệu mục đích dự án. Tôi cần làm gì khác nữa?”

Tôi giải thích: “Thành công của bạn là đạt tới những mục

đích này nhưng lập kế hoạch còn nhiều hơn điều đó. Bước tiếp

là dùng những mục đích này để xác định danh sách các mục

bạn phải làm để đáp ứng các mục đích đó. Một khoản mục có

thể là một chức năng, một tính năng, một vật chuyển giao, hay

một tài liệu v.v. Bằng việc có những khoản mục này được xác

định rõ ràng bạn có thể ước lượng bạn cần hoàn thành chúng

trong bao lâu. Điều này về căn bản là kĩ thuật Cấu trúc phân

việc (WBS) chia nhỏ các yêu cầu thành nhiều khoản mục mà

có thể ánh xạ vào trong mục đích của dự án. Với từng khoản

mục, bạn phải nhận diện mọi nhiệm vụ cần được thực hiện để

hoàn thành khoản mục này. Một khoản mục cần vài nhiệm vụ,

một nhiệm vụ là khối lượng công việc có thể được phân công

cho một người trong một thời kì thời gian. Bạn phải ước lượng

khối lượng nỗ lực (giờ hay ngày) cần để hoàn thành nhiệm vụ

này và cần bao nhiêu người phát triển để thực hiện mọi nhiệm

vụ này. Nếu bạn biết khối lượng nỗ lực cho từng nhiệm vụ và

số nhiệm việc cần hoàn thành một khoản mục thì bạn có thể

tính được mọi nỗ lực cần cho khoản mục đó. Cuối cùng, bạn có

thể tính tổng nỗ lực cần cho mọi khoản mục để cho đến cuối,

bạn có nỗ lực hay thời gian chính xác để hoàn thành toàn thể

dự án.”

Anh ta lắc đầu: “Điều đó có vẻ khó và nhiều việc.”

Tôi tiếp tục: “Lập kế hoạch dự án là về ước lượng khối

lượng công việc và thời gian cần để hoàn thành dự án. Để làm

cho điều đó được dễ dàng hơn, bạn có thể dùng phần mềm như

Microsoft “Project” mà tổ chức công việc của bạn. Bạn có thể

đặt vào đó tất cả các khoản mục, nhiệm vụ, thời hạn và tài

nguyên được cần để hoàn thành dự án. Với mọi dự án, khách

hàng sẽ cho người quản lí dự án một lịch biểu thời gian mà họ

162

nghĩ là hợp lí. Đây là thời gian bạn phải so sánh với ước lượng

lịch biểu riêng của mình và ngày chuyển giao được yêu cầu của

khách hàng. Nếu có khác biệt, thì bạn phải thương lượng về

lịch biểu ngay lập tức. Nếu bạn KHÔNG lập kế hoạch, bạn

không bao giờ biết liệu lịch biểu của khách hàng có là đúng

hay không. Đó là lí do tại sao tôi nghĩ lập kế hoạch dự án là rất

quan trọng và không bao giờ được nhảy qua.

Anh ta lưỡng lự: “Nhưng điều gì xảy ra nếu khách hàng

không đồng ý với lịch biểu của tôi?”

Tôi giải thích: “Là người quản lí dự án, bạn phải biết

cách thương lượng. Bạn có ba tuỳ chọn: Đòi thêm thời gian để

hoàn thành dự án dựa trên ước lượng riêng của bạn. Đòi thêm

người (tài nguyên) để làm việc cho dự án. Đòi khách hàng rút

bớt chức năng hay yêu cầu (phạm vi). Bạn phải chỉ cho khách

hàng qui trình về cách bạn đi tới ước lượng của bạn bằng việc

dùng Cấu trúc phân việc (WBS) và mục đích dự án chi tiết,

khoản mục, nhiệm vụ, nỗ lực v.v. Điều này cũng chỉ cho khách

hàng rằng bạn biết cách lập kế hoạch và cách quản lí dự án.

Theo kinh nghiệm của riêng tôi, khách hàng sẽ bị ấn tượng với

năng lực của bạn. Hầu hết mọi lần, khách hàng chỉ "phỏng

đoán" lịch biểu mà không biết chi tiết cho nên có qui trình

logic để chia nhỏ mọi sự mà bạn phải làm sẽ cho khách hàng

tin tưởng hơn vào kĩ năng của bạn. Họ có thể đồng ý với bạn

hay nếu không họ sẽ thương lượng tuỳ chọn nào đó."

Anh ta gật đầu: “Bây giờ thì tôi hiểu, vậy lập kế hoạch là

đi tới một ước lượng logic để thương lượng lại với khách

hàng.”

Tôi bảo anh ta: “Chính xác, nhưng nó còn nhiều hơn chỉ

là ước lượng. Nó cũng giúp bạn xây dựng tổ dự án của bạn.

Bằng việc hiểu mọi nhiệm vụ về chi tiết, bạn biết kiểu kĩ năng

nào bạn sẽ cần cho nên bạn có thể nhận diện những người nào

đó với tri thức chuyên gia nào đó cho tổ của bạn. Tri thức và kĩ

163

năng của tổ dự án sẽ xác định thành công hay thất bại của dự

án cho nên bạn phải chọn các thành viên tổ một cách cẩn thận.

Bạn phải mô tả vai trò và trách nhiệm của từng thành viên trên

kế hoạch dự án để tránh bất kì xung đột cá nhân nào trong các

thành viên tổ.

Anh ta hỏi: “Còn gì khác mà tôi phải làm không?”

Tôi giải thích: “Bước tiếp là nhận diện mọi rủi ro bạn có

thể gặp phải trong dự án. Quản lí rủi ro là phần quan trọng của

quản lí dự án phần mềm. Bạn phải nhận diện nhiều nhất có thể

được về các rủi ro cho dự án của bạn. Rủi ro thông thường nhất

là ước lượng thời gian của bạn có thể quá lạc quan. Cho dù bạn

có thể làm hết sức mình nhưng không có nhiều kinh nghiệm,

bạn có thể không ước lượng đúng. Trong trường hợp đó, bạn có

thể cần sự giúp đỡ từ các thành viên tổ. Bạn có thể yêu cầu họ

cung cấp cái vào sau khi bạn phân công nhiệm vụ cho họ. Thu

thập mọi thông tin từ họ và so sánh với ước lượng riêng của

bạn thì bạn có thể có ý tưởng nào đó về ước lượng lịch biểu của

bạn chính xác thế nào. Rủi ro khác có thể là khách hàng đổi ý

thường xuyên sau khi dự án bắt đầu và thêm nhiều yêu cầu.

Trong trường hợp đó bạn phải lập kế hoạch lại ước lượng và

thương lượng lại để thêm thời gian. Một khi bạn nhận diện ra

rủi ro, bạn phải tìm giải pháp để ngăn cản chúng xảy ra hay làm

giảm tác động của chúng tới dự án. Bạn phải viết ra điều bạn sẽ

làm nếu rủi ro xuất hiện, và điều bạn sẽ làm để ngăn ngừa nó

khỏi xuất hiện. Bạn phải thảo luận với tổ về mọi rủi ro và kiểm

điểm chúng trên cơ sở đều đặn, bổ sung thêm những rủi ro mới

khi chúng xuất hiện trong cuộc đời của dự án. Nhớ lấy, khi rủi

ro bị bỏ qua chúng không đi mất đâu. Bạn cũng phải cập nhật

bản kế hoạch của mình, mọi sự bao giờ cũng thay đổi trong dự

án phần mềm. Khi dự án bắt đầu, bạn phải giám sát tiến bộ của

mình theo kế hoạch và nếu mọi sự không xảy ra như đã lập kế

hoạch thì bạn phải có hành động sửa chữa chúng. Đó là điều

người quản lí dự án phần mềm tốt phải làm.

164

Lập kế hoạch dự án phần mềm: Qui trình "mười bước"

Một số người quản lí dự án phần mềm (PM) không biết

cách xây dựng bản kế hoạch dự án. Họ thậm chí không lập kế

hoạch mà chỉ dùng lịch biểu được khách hàng trao cho họ. Họ

không xây dựng viễn kiến cho dự án hay ước lượng nỗ lực dự

án. Logic của họ là yêu cầu bao giờ cũng thay đổi, sao bận tâm

tới lập kế hoạch cho cái gì đó mà sẽ thay đổi? Họ không hiểu

mục đích hay ích lợi của bản kế hoạch dự án.

Bản kế hoạch dự án là tài liệu được dùng để trao đổi

thông tin giữa người quản lí dự án với tổ dự án và khách hàng.

Bước thứ nhất trong xây dựng kế hoạch dự án là đặt chiều

hướng cho dự án. Khi dự án bắt đầu, tổ không biết phải làm gì;

họ cần "la bàn" để hướng dẫn họ. Viễn kiến dự án là la bàn chỉ

cho họ về chiều hướng được người quản lí dự án lập ra. Viễn

kiến này giải thích cho họ thành công sẽ là gì; dự án sẽ giải

quyết vấn đề gì cho khách hàng; mục đích và mục tiêu là gì và

mong đợi của khách hàng là gì. Viễn kiến giữ cho nỗ lực của tổ

được gióng thẳng với yêu cầu của khách hàng và mục tiêu dự

án.

Bước thứ hai là mô tả vấn đề mà dự án được dự định giải

quyết. Các thành viên tổ cần hiểu vấn đề, cũng như giải pháp

thành công có thể là gì. Họ cần biết về khách hàng và người

dùng. Dự án có thể có một khách hàng hay nhiều khách hàng

với các yêu cầu khác nhau. Trong trường hợp này, tổ cần biết

cách giữ cân bằng nhiều yêu cầu khác nhau và vẫn đáp ứng

được như cầu của khách hàng.

Bước thứ ba là mô tả sản phẩm phần mềm. Cách tốt nhất

để làm điều này là dùng Biểu đồ hoàn cảnh, trong đó người

165

quản lí dự án xác định cách phần mềm tương tác với khách

hàng hay người dùng, và cách thông tin chảy bên trong và

ngoài hệ thống. Biểu đồ này sẽ cho tổ một tổng quan về phần

mềm.

Bước thứ tư là mô tả chức năng mức cao của sản phẩm

phần mềm. Người quản lí dự án phải mô tả từng chức năng dựa

trên các yêu cầu của khách hàng. Nếu phần mềm là lớn và phức

tạp, một số chức năng có thể được chia thành các chức năng

con cho dễ mô tả. Điều quan trọng là người quản lí dự án kiểm

nghiệm các yêu cầu chức năng này với khách hàng để đảm bảo

rằng chúng là chính xác điều khách hàng cần.

Bước thứ năm là chia nhỏ các yêu cầu chức năng này

thành các nhiệm vụ nhỏ hơn (Cấu trúc phân việc - Work

Breakdown Structure) và liệt kê những nhiệm vụ này để cho

các thành viên tổ có thể thấy mọi nhiệm vụ mà họ phải làm. Vì

các yêu cầu thường xuyên thay đổi do nhu cầu phụ thêm, thông

tin mới, hay thỉnh thoảng khách hàng quyết định thay đổi yêu

cầu. Những thay đổi này sẽ ảnh hưởng tới mọi thứ trong dự án.

Do đó dự án cần có bản kế hoạch để đảm bảo rằng chỉ các yêu

cầu đúng là được thực hiện. Bằng việc giữ danh sách hiện thời

của mọi nhiệm vụ, thành viên tổ biết nhiệm vụ nào đã bị thay

đổi hay sửa đổi, và cách chúng tác động tới công việc của họ.

Khi dự án bắt đầu, các thành viên tổ không biết mọi thông tin

mà khách hàng muốn cho nên họ dựa hầu hết trên danh sách

các nhiệm vụ này. Điều quan trọng là giữ cho danh sách này

được cập nhật dựa trên thông tin phụ thêm. Bản kế hoạch dự án

sẽ xác định cách giải quyết với các thay đổi, cách thay đổi sẽ

được kiểm điểm, và cách danh sách các nhiệm vụ sẽ được cập

nhật để đảm bảo rằng dự án sẽ đáp ứng nhu cầu của khách

hàng.

Bước thứ sáu là xác định vai trò, trách nhiệm của từng

thành viên tổ và phân công cho họ các nhiệm vụ dựa trên kĩ

166

năng và kinh nghiệm của họ. Bằng việc nhận diện các thành

viên tổ qua kĩ năng, người quản lí dự án sẽ biết kĩ năng nào sẵn

có cho nhiệm vụ nào và kĩ năng nào được cần. Người quản lí

dự án có thể nhận diện các thành viên tổ có những kĩ năng này,

nếu không người đó có thể phải đi thuê người phụ với kĩ năng

đặc biệt để hoàn thành dự án. Điều này là quan trọng bởi vì

một số người quản lí dự án thường dựa vào số người sẵn có cho

dự án thay vì kĩ năng của họ. Họ lấy cán bộ cho dự án theo số

người được cần chứ không theo kĩ năng được cần. Chẳng hạn,

nếu dự án cần 10 người thì họ thuê 10 người bất kể tới kĩ năng

của họ. Đây là một trong các lí do mà nhiều dự án thất bại.

Người quản lí dự án có kinh nghiệm bao giờ cũng lấy cán bộ

cho dự án dựa trên kĩ năng chứ không trên số người được cần.

Trong bước này, người quản lí dự án cũng nhận diện phần

cứng, phần mềm, và trang thiết bị được cần cho dự án và cách

chúng sẽ được thu nhận.

Bước thứ bẩy là ước lượng nỗ lực được cần để hoàn

thành các nhiệm vụ này. Điều được khuyến cáo là người quản

lí dự án làm việc cùng các thành viên tổ mà đã được phân công

cho các nhiệm vụ để đi tới một ước lượng cho công việc của

họ. Người quản lí dự án phải lấy từng nhiệm vụ và đặt chúng

vào trật tự theo đó chúng sẽ được thực hiện rồi tóm tắt chúng

trong thời gian được ước lượng toàn thể cần để hoàn thành mọi

nhiệm vụ. Bằng việc dùng thông tin này, người quản lí dự án

có thể thương lượng với khách hàng về lịch biểu dự án. Lịch

biểu dự án nên căn cứ trên thoả thuận dựa trên lịch biểu mong

đợi của khách hàng và tóm tắt về thời gian được ước lượng

được cần để hoàn thành mọi nhiệm vụ. Người quản lí dự án có

thể yêu cầu thay đổi lịch biểu nếu có khác biệt lớn về thời gian

được lên lịch và thời gian được ước lượng; hay yêu cầu nhiều

người hơn, hay yêu cầu giảm chức năng. Một khi thương lượng

này được hoàn thành, người quản lí dự án sẽ cập nhật danh

sách các nhiệm vụ và phân ngày tháng để bắt đầu và hoàn

167

thành từng nhiệm vụ cũng như cập nhật ngân sách của dự án

(tiền được cấp cho dự án).

Bước thứ tám là lập kế hoạch về chất lượng sản phẩm.

Chất lượng không tự xảy ra; nó cần được xây dựng nên. Người

quản lí dự án cần nhận diện chuẩn chất lượng theo đó dự án sẽ

được đo và cách các thành viên tổ sẽ đo chúng. Chẳng hạn,

chất lượng có thể được xác định như việc đáp ứng mọi yêu cầu

của khách hàng; có ít lỗi (không quá 1 lỗi trên mười nghìn

dòng mã); đáp ứng chi phí và lịch biểu v.v. Chất lượng phải

được xác định rõ ràng và được kiểm điểm với cả khách hàng và

người quản lí cấp cao để đảm bảo rằng dự án đang tạo ra sản

phẩm chất lượng.

Bước thứ chín là quản lí rủi ro. Vì không phải mọi thứ

xảy ra bên trong dự án phần mềm đều được biết hết, mọi sự có

thể xảy ra bất ngờ vì chúng không thể được dự đoán. Những

điều bất định là rủi ro và chúng phải được quản lí. Người quản

lí dự án cần nhận diện rủi ro dự án, khả năng xuất hiện của

chúng, cách giảm nhẹ chúng và cách trao đổi về chúng cho các

thành viên tổ, nếu chúng xuất hiện.

Bước thứ mười là xác định tài liệu dự án. Tuỳ theo độ

phức tạp và yêu cầu của khách hàng, dự án có thể được yêu cầu

cung cấp tài liệu hỗ trợ như một phần của vật chuyển giao của

dự án. Tài liệu bao gồm tài liệu sử dụng của người dùng, trợ

giúp trực tuyến, tài liệu cài đặt, v.v.

Qui trình lập kế hoạch dự án

Theo báo cáo công nghiệp mới, vấn đề chính trong phát

triển phần mềm là việc thiếu kĩ năng quản lí dự án. Báo cáo

này thấy rằng chỉ 28% người quản lí dự án phần mềm nhận

168

được đào tạo đúng. Phần còn lại 72% được đề bạt mà không có

đào tạo hay chỉ ít đào tạo. Điều đó có thể là lí do tại sao nhiều

dự án phần mềm đã thất bại.

Không có đào tạo đúng, dự án phần mềm thất bại khi cái

gì đó xảy ra và người quản lí dự án không biết phải làm gì.

Không thu được yêu cầu của khách hàng thích hợp là một yếu

tố; không ước lượng được lịch biểu là yếu tố khác. Không biết

cách giải quyết với sức ép là yếu tố khác. Thỉnh thoảng, dưới

sức ép từ khách hàng để đáp ứng lịch biểu, người quản lí dự án

ra lệnh cho tổ bỏ qua kiểm thử và chuyển giao phần mềm

không được kiểm thử chỉ để đáp ứng đòi hỏi. Với sản phẩm

chất lượng kém, dự án phải sửa mọi lỗi sau khi chuyển giao

cho khách hàng và điều đó còn tốn kém hơn nếu chúng được

sửa trong quá trình phát triển.

Các công ti phần mềm hiểu rằng có qui trình được xác

định tốt là chìa khoá cho chất lượng phần mềm tốt hơn và tránh

việc làm lại tốn kém. Chìa khoá cho dự án thành công là ở lập

kế hoạch. Có nhiều phương pháp và kĩ thuật để lập kế hoạch dự

án phần mềm nhưng nền tảng chính là người quản lí dự án phải

tuân theo qui trình được xác định cho lập kế hoạch dự án.

Trong các dự án lớn, lập kế hoạch là rất mấu chốt. Người quản

lí dự án phải tuân theo một qui trình để xác định viễn kiến và

mục đích cho dự án; lập phạm vi của dự án; và chia các yêu

cầu thành những nhiệm vụ nhỏ hơn để ước lượng nỗ lực, tài

nguyên, chi phí và thời gian. Ngay cả trong các dự án nhỏ, lập

kế hoạch cũng quan trọng. Người quản lí dự án phải tuân theo

qui trình để tổ chức và ưu tiên hoá các nhiệm vụ cần đưa ra

trong từng pha.

Bằng việc tuân theo qui trình, người quản lí dự án sẽ có

khả năng lập kế hoạch mọi dự án một cách nhất quán. Nó giúp

cho người quản lí dự án tổ chức các hoạt động tương ứng.

Chẳng hạn, họ phải làm cho mục đích dự án là đạt tới được

169

bằng việc ưu tiên hoá các công việc được thực hiện trên từng

đưa ra để cho tổ có thể duy trì hội tụ vào những điều đặc biệt.

Bằng việc đưa khách hàng và người dùng tham gia cùng tổ

trong pha sớm của dự án, cùng rủi ro, và ích lợi để cho mọi

người có thể hiểu vấn đề trong dự án. Bằng việc chia sẻ thông

tin, điều đó thúc đẩy hiểu biết tốt hơn về dự án. Qui trình này

cũng giúp cho người quản lí đặt các mục đích ngắn hạn và dài

hạn, điều cần được thực hiện bây giờ và điều có thể được thực

hiện về sau.

Nhiều người coi qui trình là "hoạt động quan liêu" để làm

tài liệu mọi thứ. Đó là quan niệm sai vì họ không hiểu rằng qui

trình là cách tổ chức làm việc dựa trên một tập các ưu tiên, một

trình tự các sự việc, và bản lộ trình nơi người quản lí dự án có

thể giải thích các hoạt động để thực hiện để cho mọi người có

thể hiểu được. Qui trình được xác định của dự án đòi hỏi rằng

khách hàng, người dùng, và tổ dự án kiểm điểm các yêu cầu và

thẩm tra mục tiêu doanh nghiệp của dự án. Nếu cần, nó yêu cầu

tổ xây dựng bản mẫu để làm sáng tỏ nhu cầu của khách hàng

và giữ cho thành viên tổ trên con đường đúng. Nó yêu cầu dự

án có vài cột mốc hành động được nhỏ. Một cách lí tưởng, mỗi

cột mốc không quá bốn tuần để đảm bảo tiến bộ được thực

hiện. Điều này là mấu chốt cho người dùng, người muốn có

những vật chuyển giao ngắn hạn trong thời gian ngắn. Nó cũng

cung cấp cơ hội cho khôi phục nhanh hơn nếu dự án bắt đầu

lâm vào trục trặc.

Dự án tuân theo qui trình được xác định phải công bố kế

hoạch dự án, lịch biểu, cột mốc và phân phối thông tin trạng

thái đều đặn theo hầu hết mọi cách có thể truy nhập được. Họ

có thể dùng e-mail, tin nhắn, wiki, hay trang dự án trên website

để cho nhiều người biết tới tiến độ dự án. Nó cũng tăng cơ hội

bắt được vấn đề tiềm năng mà người quản lí dự án có thể bỏ lỡ.

Một vấn đề chung thường xảy ra trong lập kế hoạch là khi dự

án có hạn chót được lên lịch từ khách hàng mà không hiện thực

170

dựa trên ước lượng dự án. Bằng việc có qui trình tại chỗ với sự

kiện và dữ liệu, dễ dàng tiếp xúc với khách hàng để thương

lượng về hạn chót đã lập lịch (đổi lịch biểu) hay đòi hỏi công

nhân thêm (tăng chi phí) hay giảm chức năng của dự án (đổi

phạm vi).

Quản lí rủi ro là phần quan trọng thường bị bỏ qua trong

lập kế hoạch dự án. Bằng việc tuân theo một qui trình xác định,

người quản lí dự án có thể nhận diện nhiều rủi ro cho dự án và

được chuẩn bị nếu cái gì đó xấu xảy ra. Chẳng hạn: Ước lượng

thời gian và chi phí là quá lạc quan; xác định không rõ ràng vai

trò và trách nhiệm; nhu cầu của khách hàng không được hiểu

rõ; khách hàng cứ thêm các yêu cầu mới sau khi dự án đã bắt

đầu v.v. Những rủi ro này có thể được dõi vết và giảm nhẹ khi

cần.

Ích lợi của việc tuân theo qui trình lập kế hoạch dự án là

nhiều. Khách hàng sẽ đánh giá tốt mức độ cao của công việc

mà công ti tạo ra cho họ, do vậy đưa tới kinh doanh mới và lợi

nhuận nhiều hơn. Bằng việc có qui trình được xác định tốt,

điều đó sẽ cho phép cấp quản lí nhìn vào qui trình để cải tiến

nó và điều chỉnh nó để thích ứng với thay đổi doanh nghiệp khi

công ti tăng trưởng. Ích lợi quan trọng nhất là ở chỗ người quản

lí dự án không phải giải quyết cùng vấn đề mà thay vì vậy hội

tụ vững chắc vào việc tạo ra chỗ làm việc tốt nhất có thể được.

Ước lượng dự án-1

Ước lượng dự án là một trong những nhân tố chính xác

định thành công hay thất bại của dự án nhưng rất ít người biết

cách làm nó đúng đắn hay đưa nỗ lực nào đó vào điều đó.

Nhiều người quản lí phần mềm nói với tôi rằng họ KHÔNG

ước lượng dự án của mình bởi vì nhiều thứ đằng nào cũng thay

171

đổi. Những người khác bảo tôi rằng cho dù họ có ước lượng,

khách hành của họ có thể không đồng ý với ước lượng của họ

hay đổi ý cho nên tại sao phải phí thời gian. Đây là sai lầm

chính bởi vì trong trường hợp đó, người quản lí dự án cho phép

khách hàng áp chế lịch biểu và ngân sách của dự án đối với họ.

Làm sao bạn thích làm việc trong dự án khi bạn biết rằng lịch

biểu là không hợp lí và bạn không có đủ người để làm việc đó?

Làm sao bạn thích làm việc trong dự án mà bạn biết rằng nó sẽ

không đáp ứng được lịch biểu và chức năng? Làm sao bạn

thích làm việc trong dự án mà bạn biết rằng nó sẽ bị chậm cho

dù bạn phải làm việc rất vất vả để đáp ứng lịch biểu? Tôi đã

thấy rằng khi dự án bị chậm với chi phí cao nhất và ít chức

năng, nhiều người quản lí dự án sẽ quở trách về yêu cầu kém,

hay trách móc khách hàng đổi ý thường xuyên. Rất ít người

quản lí dự án chịu thừa nhận rằng họ không biết cách ước

lượng và phải mất bao nhiêu thời gian để hoàn thành dự án

(Lịch biểu), dự án sẽ cần bao nhiêu người để làm việc (Tài

nguyên), và nó tốn bao nhiêu (Ngân sách).

Quan điểm của tôi là ước lượng sẽ cho phép người quản

lí dự án nhận diện rủi ro mà có thể ngăn cản dự án đạt được

mục đích của nó. Ước lượng sẽ KHÔNG tạo ra yêu cầu tốt

hơn. Nó sẽ KHÔNG làm cho khách hàng thôi đổi ý. Nó có thể

KHÔNG đổi lịch biểu. Nó có thể KHÔNG cho bạn nhiều

người hơn hay nhiều ngân sách hơn nhưng nó SẼ tạo ra đánh

giá chính xác về rủi ro có trong dự án. Ước lượng SẼ cho bạn

khả năng biết dự án sẽ thành công hay không. Bằng việc có

những ước lượng này (Lịch biểu, tài nguyên, ngân sách), người

quản lí dự án có thể thiết lập mong đợi ĐÚNG ĐẮN với khách

hàng cho nên một thoả thuận HỢP LÍ có thể được đạt tới.

Người quản lí dự án giỏi nên biết cách thương lượng với khách

hàng về các rủi ro mấu chốt trong những tình huống nào đó.

Để tôi cho bạn một ví dụ: Khách hàng yêu cầu một dự án

có 10 chức năng cần được hoàn thành trong 4 tháng với ngân

172

sách dành cho 5 người phát triển phần mềm. Ước lượng của

bạn lên tới 6 tháng mới hoàn thành dự án này với chức năng và

tài nguyên đã cho. Bạn có thể hỏi khách hàng liệu có thể kéo

dài lịch biểu từ 4 tới 6 tháng không. Nếu câu trả lời là KHÔNG

thì bạn có thể cho khách hàng biết là với ngân sách hiện thời

cho 5 người, bạn có thể KHÔNG có khả năng thực hiện điều

đó trong vòng 4 tháng được yêu cầu nhưng nếu khách hàng có

thể tăng ngân sách từ 5 tới 7 người phần mềm, thì bạn có thể

đáp ứng ngày tháng đã yêu cầu. Nếu câu trả lời là KHÔNG thì

yêu cầu cuối cùng của bạn sẽ là bạn sẽ hoàn thành dự án với 5

người trong 4 tháng nhưng chỉ thực hiện 6 chức năng thay vì

10 chức năng. Về căn bản, có ba nhân tố (lịch biểu, tài nguyên

và chức năng) hay tổ hợp của ba nhân tố này mà bạn có thể đưa

ra thương lượng. Rất có thể là bạn sẽ kết thúc với 6 người, 5

tháng và 8 chức năng sau khi thương lượng dồn dập. Ít nhất

điều đó cũng là tốt hơn điều bạn được trao ngay chỗ bắt đầu.

Thương lượng là kĩ năng mấu chốt của người quản lí dự

án giỏi nhưng nó KHÔNG được dạy trong trường. Tất nhiên,

trước khi bạn học cách thương lượng, bạn phải biết cách ước

lượng bởi vì không có ước lượng, bạn không thể đi tới chiến

lược thương lượng được. Ước lượng nên được coi như phần

mấu chốt để làm giảm nhẹ nhiều rủi ro có thể tác động vào dự

án. Khi ước lượng được thừa nhận về giá trị của nó, khách

hàng và người quản lí cấp cao rất có thể sẽ chấp nhận điều đó

bằng việc yêu cầu người quản lí dự án có kĩ năng này.

Mô hình trưởng thành năng lực của SEI (CMMI) gợi ý

rằng trưởng thành của một tổ chức dựa trên qui trình được thiết

lập rõ và được thực hiện có hiệu quả. Một phát biểu rõ ràng về

chính sách ước lượng được hỗ trợ bởi một qui trình ước lượng

được xác định rõ là nhân tố chính trong việc đạt tới xếp hạng

CMMI mức 3. (Nếu tổ chức của bạn được đánh giá xếp hạng ở

mức trưởng thành cao hơn nhưng qui trình ước lượng của bạn

KHÔNG tốt tại chỗ thì bạn có thể phải yêu cầu người đánh giá

173

CMMI xem liệu người đó có nghiêm chỉnh trong nghề của

mình hay chỉ "lừa" đánh giá để lấy tiền). Ước lượng chính xác

yêu cầu nhiều dữ liệu lịch sử và những dữ liệu này chỉ có thể

được thu thập nếu được cấp quản lí thừa nhận rằng đó là nhân

tố quan trọng trong việc xác định qui trình dự án.

Ước lượng dự án-2

Nhiều dự án phần mềm có vấn đề bởi vì lịch biểu khách

hàng đặt cho họ. Bởi vì người quản lí dự án không biết cách

ước lượng thời gian cần để hoàn thành dự án cho nên họ đồng

ý với bất kì ngày tháng nào khách hàng đặt ra. Không may,

phần lớn các khách hàng cũng không biết dự án có thể được

thực hiện trong bao lâu cho nên họ đặt một ngày tháng tuỳ tiện

mà họ thích. Đó là lí do tại sao dự án ở vị thế xấu vì ngày tháng

bị đặt dựa trên phỏng đoán chứ KHÔNG dựa vào thời gian cần

thiết.

Nhiều người quản lí dự án cũng không biết cách lập kế

hoạch cho công việc của họ. Họ vội vàng cho dự án bắt đầu

bằng việc ra lệnh cho tổ dự án xô vào thiết kế và bắt đầu viết

mã bởi vì với họ phần mềm là mã. Chẳng mấy chốc mọi người

có thể viết mã nhanh hơn họ có thể hoàn thành dự án. Một số

người quản lí dự án muốn chứng tỏ "tiến độ của họ" cho người

quản lí cấp cao bằng việc cho tổ viết mã và kiểm thử sớm nhất

có thể được bởi vì người quản lí cấp cao chỉ thấy tiến độ khi dự

án đi vào pha kiểm thử, vì điều đó có nghĩa là dự án gần hoàn

thành và sẵn sàng cho chuyển giao. Điều này sẽ đưa dự án vào

tình huống sinh lỗi vì công việc được thực hiện vội vàng để

sang pha kiểm thử.

Nhiều người phát triển không biết cái gì tốt hơn. Họ chi

tuân theo chỉ đạo của người quản lí dự án bởi vì họ thích viết

174

mã. Tất nhiên, họ biết về các pha khác trong vòng đời nhưng

phần lớn các trường nhấn mạnh vào viết mã cho nên họ làm

điều họ đã học giỏi nhất bằng việc làm pha viết mã. Tôi đã thấy

nhiều người phát triển đổ xô qua yêu cầu, thiết kế trong vài

ngày để họ có thể viết mã. Một số người thậm chí còn nói:

“Viết mã trước, hỏi câu hỏi sau.” Kết quả là sản phẩm phần

mềm với nhiều lỗi và có thể không có được điều khách hàng

cần.

Tất nhiên khách hàng không hài lòng và nhiều người yêu

cầu: “Đó KHÔNG phải là điều tôi muốn. Thay đổi nó đi nếu

không tôi sẽ không trả tiền.” Người quản lí cấp cao muốn đạt

tới sự thoả mãn của khách hàng sẽ gây sức ép lên người phát

triển: “Trở về và đổi mã của các anh theo điều khách hàng

muốn nhưng chóng chóng lên vì không còn nhiều thời gian

đâu.” Dưới loại sức ép này, mọi người sẽ trách móc ai đó khác.

Kịch bản này thường xảy ra trong mọi công ti nhưng ít

người biết phải làm gì bởi vì mọi người đều trách ai đó khác.

Là người phát triển, bạn có thể biết rằng lịch biểu là không hợp

lí và nói với người quản lí dự án “Lịch biểu đó dường như

không đúng.” Tuy nhiên, người quản lí có thể nói “Lịch biểu

đó tới từ khách hàng. Anh không hiểu về sự hài lòng của khách

hàng sao? KHÔNG phải việc của anh đi bảo khách hàng rằng

họ là sai.” Cho nên bạn lắc đầu và trở lại viết mã bởi vì đó

KHÔNG phải là lỗi của bạn. Tất nhiên người quản lí cũng có

cùng cảm giác không thoải mái nhưng đó cũng KHÔNG phải

là lỗi của người đó bởi vì người đó đã không đặt ra ngày tháng.

Khách hàng cũng có cùng cảm giác nhưng người đó nghĩ, đó

KHÔNG phải là lỗi của mình vì người đó đã đặt ngày tháng

tuỳ tiện nhưng tổ đằng nào cũng đã chấp nhận nó rồi. Khi

không ai chịu trách nhiệm về bất kì cái gì thì dự án sẽ thất bại.

Khi điều đó xảy ra, sẽ có tổn thất vì khách hàng sẽ KHÔNG

chấp nhận sản phẩm và sẽ KHÔNG trả tiền. Người quản lí sẽ

KHÔNG tự sa thải mình cho nên người dễ nhất chịu trách móc

175

là người ở vị trí thấp nhất: người phát triển. Mọi người sẽ nói

rằng đó là lỗi của người phát triển vì anh ta không hoàn thành

dự án tương ứng theo điều khách hàng yêu cầu. Là người phát

triển, bạn là cái bung xung cho mọi thứ.

Cho nên bạn phải làm gì? Khi bạn mua máy MP3, điện

thoại di động, hay laptop bạn có thương lượng về giá, đúng

không? Cho nên tại sao bạn không học cách thương lượng lịch

biểu? Tại sao bạn chấp nhận nó mà không hỏi gì? Điều bạn cần

là chuẩn bị cho thương lượng. Khi người quản lí nói ngày

chuyển giao là sáu tháng, bạn phải bảo họ: “Để tôi kiểm lại

xem liệu tôi có thể làm được điều đó trong lịch biểu mà ông

yêu cầu không.” Cho dù bạn biết lịch biểu đó là không hợp lí,

ĐỪNG tranh cãi vào lúc đó bởi vì bạn CHƯA chuẩn bị để

thuyết phục họ. Bạn cần thời gian để đi tới lịch biểu logic và

hợp lí bằng việc kiểm điểm lịch đã cho với tổ. Năm hay mười

người là tốt hơn một người cho nên cùng với tổ, bạn làm ra kế

hoạch dự án với mọi việc được chia ra tới mức chi tiết về bao

nhiêu chức năng, bao nhiêu nhiệm vụ, cũng như nỗ lực được

cần tới để hoàn thành toàn thể dự án và thời gian kết thúc

chúng. Bây giờ, bạn có thể tới người quản lí như một tổ và bảo

họ lịch biểu là gì. Như một tổ, bạn chỉ cho người quản lí thấy

bản kế hoạch dự án với mọi công việc và thuyết phục người

quản lí rằng tổ biết điều họ đang nói tới.

Nếu bạn có thể chỉ ra cho người quản lí cách bạn đi tới

lịch biểu mới hoặc là ông ấy đồng ý với bạn hoặc là ông ấy

phản đối nó bằng kế hoạch khác. Về căn bản, cả bạn và người

quản lí bắt đầu thương lượng trên cách thức logic và hợp lí để

giải quyết vấn đề này. Nếu dự án cần tám tháng và KHÔNG

phải sáu tháng, điều cuối cùng người quản lí muốn là đồng ý

với lịch biểu sáu tháng bởi vì nó sẽ thất bại. Người quản lí sẽ

phải trở lại với khách hàng và báo cho người đó biết về lịch

biểu mới. Không người quản lí nào muốn dự án thất bại nếu

người đó biết rằng người đó có thể mất việc của mình. Không

176

người quản lí nào muốn thấy người của họ bảo họ: “Tôi đã bảo

ông rằng cần tám tháng nhưng ông đã không chịu nghe.” Cho

nên đến lượt người quản lí thuyết phục khách hàng và rất có

thể là ông ấy sẽ đề nghị bạn đi cùng ông ấy bởi vì đó là công

việc của bạn và bạn biết tất cả chi tiết. Đây là cơ hội của bạn để

chứng tỏ cho khách hàng về năng lực ước lượng của bạn và kĩ

năng thương lượng của bạn. Nếu họ đồng ý với bạn và dự án

hoá ra thành công, mọi người sẽ biết về bạn và đó là cơ hội của

bạn có được cái nhìn tốt trước quản lí cấp cao và khách hàng.

Tất nhiên, bạn phải học nhiều về ước lượng dự án và

cách thương lượng và trao đổi. Không may, phần lớn các

trường KHÔNG dạy những kĩ năng này cho nên bạn cần tự học

chúng. Có nhiều bài báo tuyệt vời trên internet về những chủ

đề này cho nên xin tìm chúng đi. Khi bạn có thể đi tới lịch biểu

hợp lí, khi bạn có thể thương lượng với khách hàng thì bạn sẵn

sàng bước sang vai trò tiếp: Vị trí quản lí dự án.

Ước lượng dự án-3

Một người phát triển viết cho tôi: “Làm sao chúng tôi

ước lượng được lịch biểu cho dự án? Chúng tôi nên dùng kĩ

thuật nào? Người quản lí của tôi không muốn chúng tôi trượt

lịch biểu vì điều đó sẽ làm cho khách hàng giận. Xin thầy giúp

đỡ.”

Đáp: Rất khó ước lượng lịch biểu dự án (dự án sẽ mất

bao lâu) vì lúc bắt đầu dự án phần mềm, có nhiều điều bạn

không biết và mọi sự cũng sẽ thay đổi trong quá trình dự án.

Phần lớn các dự án đều nhận được lịch biểu từ khách

hàng nhưng nhiều người quản lí dự án chưa bao giờ hỏi làm

sao khách hàng ước lượng được thời gian cho dự án (lịch biểu).

177

Nếu họ hỏi thì họ sẽ thấy ra rằng phần lớn khách hàng cũng

không biết cho nên họ chỉ đoán chừng. Nếu phải mất sáu tháng

để hoàn thành dự án nhưng khách hàng đoán rằng nó có thể

được làm trong ba tháng thì tất nhiên dự án sẽ trượt lịch. Câu

hỏi của tôi là tại sao bạn chấp nhận một phỏng đoán? Tại sao

bạn tuân theo lịch biểu không hợp lí? Tại sao bạn đồng ý với

cái gì đó mà bạn không biết và khách hàng của bạn cũng không

biết?

Có nhiều kĩ thuật khoa học và công cụ phần mềm cho

ước lượng dự án. Có nhiều sách được viết ra về ước lượng dự

án nữa. Tuy nhiên, có một kĩ thuật đơn giản mà tôi thường

dùng. (Đây là cách không khoa học và tôi chắc nhiều người

không đồng ý với tôi. Tuy nhiên nó là thực hành). Tôi khuyến

cáo rằng những người phát triển nên ước lượng nỗ lực (dự án

sẽ cần bao nhiêu công việc) thay cho lịch biểu (thời gian).

Bạn bắt đầu bằng việc phân rã các yêu cầu dự án thành

các nhiệm vụ nhỏ hơn (cấu trúc phân việc) cho tới khi bạn nhận

được nhiệm vụ mà một người có thể làm trong vòng một tuần.

(Thường phải có ít nhất 6 tới 8 mức của phân rã.) Chẳng hạn,

nếu dự án có ba chức năng. Chức năng số một được phân rã

thành ba nhiệm vụ; chức năng số hai được phân rã thành năm

nhiệm vụ; và chức năng số ba được phân rã thành sáu nhiệm

vụ. Tổng của tất cả các nhiệm vụ là: 3+ 5+ 6 = 14 nhiệm vụ.

Giả sử rằng tất cả các nhiệm vụ này có thể được thực hiện đồng

thời và từng nhiệm vụ có thể được thực hiện bởi một người vậy

thì bạn cần 14 người (nỗ lực). Cho nên bằng việc có 14 người,

bạn có thể hoàn thành dự án trong vòng một tuần (thời hạn).

Tất nhiên, đây chỉ là ước lượng đơn giản vì thời gian để

hoàn thành nhiệm vụ là tuỳ thuộc vào kĩ năng của người thực

hiện nhiệm vụ và không phải mọi nhiệm vụ đều có thể được

thực hiện cùng lúc. Tuy nhiên bằng việc có ước lượng nỗ lực

bạn có cái gì đó để thương lượng với khách hàng. Bạn có thể

178

nói rằng nếu tôi có một người, thì phải mất 14 tuần, nếu tôi có

2 người thì có thể mất 7 tuần vân vân. Dùng những con số này

để thương lượng về nỗ lực để đi tới cái gì đó hợp lí.

Tôi thường thêm 20% “lót phụ” vào trong con số. (Vâng,

đó là "thủ đoạn" nhưng nó có tác dụng). Cho nên thay vì yêu

cầu 14 tuần tôi sẽ yêu cầu 17 tuần để cho dự án cái gì đó để

thương lượng. Nhớ rằng nỗ lực về công việc được thực hiện là

không đổi (giả sử yêu cầu là không đổi) trong khi thời gian cần

để làm công việc này là tuỳ thuộc vào kĩ năng của người làm

nó cho nên phần thêm 20% sẽ giảm rủi ro và cho dự án sự

thuận tiện nào đó và ít căng thẳng hơn. Tôi hi vọng điều đó có

ích.

Ước lượng dự án-4

Một người phát triển phần mềm viết cho tôi: “Tại sao ước

lượng dự án phần mềm thường sai? Tại sao nhiều dự án phần

mềm không đáp ứng lịch biểu? Ai nên đặt ra lịch biểu cho dự

án?"

Đáp: Ước lượng dự án phần mềm thường không chính

xác bởi vì người phát triển có khó khăn với việc ước lượng thời

gian được cần để hoàn thành nhiệm vụ của họ. Phần lớn các lí

thuyết ước lượng đều giả định rằng người phát triển sẽ dành

100% thời gian làm việc nhưng thực ra có nhiều hoạt động

thường chen vào với việc phát triển mà không được tính tới.

Chẳng hạn họp tổ, thảo luận nhóm, và các hoạt động

khác của công ti. Những hoạt động bên ngoài này là không thể

dự kiến được. Bên cạnh việc viết mã, người phát triển phải gặp

gỡ khách hàng để lấy yêu cầu, thiết kế, kiểm thử, viết tài liệu

dự án, tham gia vào các buổi kiểm điểm v.v. Tất cả những hoạt

179

động này là khó ước lượng. Cho dù người quản lí có yêu cầu

người phát triển tham gia vào những hoạt động này trong ước

lượng của họ, cũng không dễ làm. Làm sao bạn ước lượng

được thời gian cho việc thảo luận tổ? Bạn có thể ước lượng

được bao nhiêu thời gian là cần để kiểm thử mã phần mềm? Có

thể là vài phút nếu mã làm việc tốt và qua mọi kiểm thử hay có

thể vài ngày mới nhận diện và gỡ lỗi được nếu phần mềm

không làm việc tốt.

Nhiều lịch biểu dự án được trao cho người quản lí dự án

từ khách hàng. Bạn đã bao giờ hỏi liệu người phát triển có gặp

khó khăn gì trong ước lượng thời gian của họ không mà làm

sao khách hàng có thể đi tới lịch biểu giao cho họ được? Khách

hàng có thể có lí do chính đáng cho lịch biểu vì họ cần sản

phẩm phần mềm vào lúc đó, trong trường hợp đó họ phải thảo

luận với người quản lí dự án để đi tới bản kế hoạch hợp lí hài

hoà với việc phát triển và giảm bớt rủi ro chứ.

Lịch biểu dự án nên được dựa trên ước lượng tốt nhất từ

tổ dự án và thương lượng với khách hàng để đi tới lịch biểu

hợp lí mà cả tổ dự án và khách hàng có thể đồng ý. Ngay cả với

điều đó xảy ra, người quản lí dự án vẫn phải giám sát lịch biểu

đã lập kế hoạch và việc thực hiện thực tại để kiểm về bất kì

biến thiên lớn này và có hành động sửa chữa để đảm bảo dự án

sẽ không bị lỡ lịch biểu đã thoả thuận.

Kiến trúc hệ thống

Theo nhiều nghiên cứu, dự án phần mềm càng lớn, cơ hội

thành công sẽ càng ít bởi vì độ phức tạp vượt quá khả năng của

người phát triển để hiểu nó. Chìa khoá cho thành công phụ

thuộc vào khả năng của kiến trúc sư hệ thống phân rã các yêu

cầu thành các nhiệm vụ nhỏ hơn để cho những người phát triển

180

có thể hiểu và có khả năng thực hiện chúng. Khi người phát

triển đã hoàn thành, những việc này có thể được tích hợp vào

trong hệ thống lớn tương ứng với kiến trúc đã xác định.

Kiến trúc tốt phải làm chi tiết mọi giao diện, chức năng,

và cơ chế kiểm soát tách biệt để cho nó có thể linh hoạt, dễ

dàng thay đổi. Nếu được thực hiện đúng, nó cho phép người

phát triển tập trung vào nhiệm vụ riêng mà không cần hội tụ

vào giao diện, luồng dữ liệu, và các chức năng hệ thống khác.

Nếu được làm tài liệu tốt, nó giảm nhu cầu điều phối giữa các

chức năng tổ khác nhau (người phát triển, người kiểm thử, đảm

bảo chất lượng, quản lí cầu hình) nhưng nếu được thực hiện

kém, nó sẽ là những biện luận không bao giờ dứt, lẫn lộn, và

nhiều vấn đề tích hợp.

Kiến trúc chảy từ yêu cầu tới đặc tả chức năng. Do đó,

yêu cầu phải đúng đắn, đầy đủ và không mơ hồ. Yêu cầu được

xác định kém sẽ dẫn tới kiến trúc kém và kiến trúc kém sẽ làm

tăng vấn đề trong các dự án lớn. Thu lấy yêu cầu là trách nhiệm

then chốt của kiến trúc sư hệ thống. Người đó phải làm việc với

đại diện khách hàng như người quản lí kinh doanh để nhận diện

nhu cầu và mục đích của hệ thống. Kiến trúc sư hệ thống là

giao diện giữa người dùng và người phát triển bởi vì người

dùng không biết cách giải thích nhu cầu của mình theo cách

người phát triển hiểu, và người phát triển không biết về qui

trình nghiệp vụ để hỏi câu hỏi đúng. Để giảm rủi ro trong dự án

lớn, kiến trúc sư hệ thống phải xây dựng bản mẫu để kiểm

nghiệm các yêu cầu với khách hàng. Làm bản mẫu là qui trình

xây dựng “mô hình hệ thống” bởi vì nó chuyển các yêu cầu vô

hình thành mô hình làm việc hữu hình nhưng bị giới hạn của hệ

thông tin mong muốn. Kiến trúc sư hệ thống trao đổi với người

phát triển bằng việc xác định các mô tả “hộp đen” về các nhiệm

vụ. Hộp đen là các thực thể trừu tượng có thể được hiểu, và

được thực hiện một cách độc lập với phần còn lại của hệ thống.

Qui trình xây dựng mô hình hộp đen được gọi là “trừu tượng

181

hoá”. Trừu tượng hoá được dùng để đơn giản hoá thiết kế của

hệ thống phức tạp bằng việc giảm bớt số chi tiết phải được xét

tới. Về căn bản, kiến trúc sư giải thích cho người phát triển cái

gì cần thực hiện, nhưng không nói về làm sao thực hiện nó.

Người phát triển phải hội tụ vào xây dựng phần mềm tin

cậy được và không có lỗi. Để giảm thiếu số lỗi, họ phải tuân

theo qui trình được xác định bằng việc dùng các thực hành và

công cụ tốt nhất có thể giúp cho họ tìm ra các lỗi sớm trong

kiểm điểm và kiểm thử. Người phát triển cũng cần đo công

việc của họ để đảm bảo chất lượng phần mềm. Bằng việc có

cách đo, người phát triển có phản hồi hữu dụng về công việc

của mình và cung cấp tái đảm bảo cho kiến trúc sư hệ thống,

người quản lí dự án và người dùng rằng phần mềm có chất

lượng cao.

Phát triển dự án lớn có chất lượng là không dễ dàng. Nó

yêu cầu kỉ luật mạnh, làm việc tổ và nhiều phối hợp. Nó cũng

yêu cầu sự hỗ trợ quản lí mạnh trong việc hiểu công việc gian

nan và cho người phát triển nhiều thời gian hơn để thiết kế và

kiểm thử công việc của họ. Phần lớn các dự án lớn đều rất phức

tạp cho nên yếu tố then chốt là kiến trúc tốt và quản lí dự án

chắc. Những kĩ năng này khó tìm được bởi vì đào tạo ngày nay

vẫn hội tụ vào khía cạnh lập trình chứ KHÔNG vào khía cạnh

thiết kế và khía cạnh quản lí. Rất ít trường dạy kiến trúc, thiết

kế và quản lí dự án mà chỉ dạy ngôn ngữ lập trình và đó là lí do

tại sao nhiều công ti thành công với các dự án nhỏ nhưng

KHÔNG thành công với các dự án lớn. Kiến trúc phần mềm và

hệ thống là khó dạy vì nó yêu cầu nhiều kinh nghiệm trong thế

giới thực. Bạn không thể học được nó từ sách vở hay theo lớp

học mà phải thực nghiệm nó trong thế giới thực, đặc biệt trong

các dự án lớn. Cách tốt nhất để học về kiến trúc là trở thành

phụ tá cho kiến trúc sư hệ thống, việc “đào tạo trong công

việc” này sẽ là tốt cho người phát triển có vài năm kinh

nghiệm. Một khi bạn kinh nghiệm điều đó và có tri thức cơ sở

182

nào đó về nó thì bạn có thể lấy vài lớp học để làm mạnh thêm

tri thức của bạn và học thêm về các phong cách khác, các cách

tiếp cận khác. Chỉ khi bạn đã làm chủ những kĩ thuật này thì

bạn mới có thể xin vào làm chức vụ kiến trúc sư. Nhớ rằng

người phát triển xây dựng công việc của họ dựa trên kiến trúc

và chính kiến trúc xác định liệu dự án có thành công hay

không.

Vòng đời kiểm thử

Nhiều người trong các bạn đã hỏi tôi về kiểm thử và mối

quan hệ của nó với vòng đời phát triển phần mềm. Về căn bản

kiểm thử tuân theo vòng đời tương ứng với mọi pha của vòng

đời phát triển.

Trong pha lập kế hoạch dự án, người quản lí dự án phải

quyết định những cái gì được kiểm thử dựa trên bản Đặc tả yêu

cầu phần mềm Software Requirements Specification (SRS).

Đây là lúc người lãnh đạo kiểm thử và người quản lí dự án làm

việc cùng nhau để tạo ra bản kế hoạch kiểm thử phần mềm

Software Test Plan (STP) mô tả cho phạm vi, khuôn khổ kiểm

thử, phương pháp kiểm thử, lịch biểu kiểm thử, chức năng

được kiểm thử hay không kiểm thử, kiểu kiểm thử nào cần

được thực hiện ở các pha khác nhau của vòng đời, môi trường

cho kiểm thử, và phân công cho từng người kiểm thử.

Trong pha yêu cầu, thành viên tổ kiểm thử phải kiểm thử

bản đặc tả yêu cầu kiểm thử (SRS) và bản kế hoạch kiểm thử

phần mềm (STP) để chắc chắn rằng họ hiểu các yêu cầu và

điều gì cần được kiểm thử. Họ sẽ thêm nhiều chi tiết vào bản

kế hoạch kiểm thử phần mềm để chắc chắn rằng họ đã bao quát

mọi chức năng phải được kiểm thử. Sau khi được hoàn thành,

bản kế hoạch kiểm thử được sửa đổi sẽ được gửi cho tổ phát

183

triển kiểm điểm để đảm bảo tính đúng đắn, tính đầy đủ của bản

kế hoạch này. Cả hai tổ sẽ thảo luận thông tin liên quan tới lịch

biểu dự án và phối hợp các hoạt động phát triển với hoạt động

kiểm thử. Điều này là quan trọng vì cả người phát triển và

người kiểm thử phải làm việc cùng nhau trên các trường hợp

kiểm thử, dữ liệu kiểm thử, kịch đoạn kiểm thử cũng như kiểm

thử phụ để đảm bảo rằng sản phẩm cuối cùng sẽ đáp ứng yêu

cầu của khách hàng. Bản kế hoạch kiểm thử phần mềm được

sửa đổi cũng sẽ được gửi tới khách hàng để kiểm điểm và chấp

thuận. Một khi được chấp thuận, nó có nghĩa là nếu mọi kiểm

thử đều qua được, sản phẩm phần mềm đáp ứng yêu cầu của

khách hàng.

Trong pha thiết kế phần mềm, khi người phát triển đưa

nhiều chi tiết vào trong thiết kế, người kiểm thử phải làm việc

cùng người phát triển để bổ sung thêm chi tiết cho bản kế

hoạch kiểm thử và trường hợp kiểm thử. Họ phải xác định

kiểm thử nào có thể được tự động hoá và kiểm thử nào phải

được thực hiện thủ công. Đây cũng là lúc để nhận diện mọi vấn

đề rủi ro và lập kế hoạch giảm nhẹ chúng. Tổ kiểm thử phải

xác định dữ liệu kiểm thử cho từng trường hợp kiểm thử, dựng

kịch đoạn kiểm thử cho mọi kiểm thử tự động và sửa lại lịch

biểu kiểm thử, nếu cần.

Trong pha viết mã, khi người phát triển làm việc trên mã

của họ và chuẩn bị kiểm thử của họ (kiểm thử đơn vị và kiểm

thử chức năng), người kiểm thử cũng phải hoàn thành mọi

trường hợp kiểm thử của họ, các kịch đoạn kiểm thử, bộ dẫn lái

kiểm thử và các kiểm thử phụ khác được yêu cầu trong bản đặc

tả yêu cầu phần mềm (SRS) chẳng hạn, kiểm thử an ninh, kiểm

thử găng, kiểm thử khói và kiểm thử hiệu năng v.v..

Trong pha kiểm thử, sau khi người phát triển hoàn thành

kiểm thử đơn vị và kiểm thử chức năng của họ, tổ kiểm thử

phải thực hiện mọi kiểm thử còn lại kể cả trường hợp kiểm thử

184

găng và kiểm thử hiệu năng, mọi kết quả đều phải được làm tài

liệu như số lỗi, số các kiểm thử qua được hay không qua được,

tình trạng của lỗi, nếu cần người kiểm thử cũng phải sửa đổi lại

các trường hợp kiểm thử hay thêm các trường hợp kiểm thử

mới (Nếu có thay đổi yêu cầu hay thay đổi mã) và kiểm thử lại

các trường hợp kiểm thử và thực hiện kiểm thử rà lại. Tổ kiểm

thử cũng phải chuẩn bị cho kiểm thử chấp phận được tiến hành

trong môi trường của khách hàng cũng như bất kì cái gì phải

được trắc nghiệm.

Sau khi dự án được hoàn thành, tổ kiểm thử phải đánh

giá mọi hoạt động kiểm thử, qui trình và kế hoạch kiểm thử cho

cải tiến tương lai. Trong pha này, tổ kiểm thử sẽ phân tích qui

trình kiểm thử của mình và làm tài liệu những điều tốt và

những điều xấu. Họ phải chắc chắn rằng nếu họ phạm bất kì sai

lầm nào, nó sẽ không lặp lại trong dự án tương lai. Không dự

án nào là hoàn hảo, không kiểm thử nào là hoàn hảo cho nên

bao giờ cũng có cơ hội cho cải tiến và họ càng có thể cải tiến

nhiều, họ sẽ càng làm tốt hơn lần sau. Kiểm thử là chức năng

quan trọng của bất kì tổ chức phần mềm tốt nào và có tổ kiểm

thử tốt hơn, người ta có thể mong đợi sản phẩm chất lượng tốt

hơn.

Cách đo

Tôi nhận được một email từ một sinh viên: “Tại sao

chúng ta phải đo công việc của mình? Đo là khó và phí thời

gian vì nó không cung cấp cho tôi giá trị. Nếu chúng ta có lỗi,

chúng ta có thể sửa chúng về sau bất kể chúng có bao nhiêu.

Tôi không biết tại sao chúng ta cần đo?"

Câu trả lời của tôi: Chúng ta dùng việc đo hàng ngày và

chúng ta thường quên mất giá trị chúng cung cấp cho chúng ta.

185

Khi bạn đi xe máy, bạn có xem đồng hồ chỉ xăng để chắc rằng

bạn có đủ xăng trên chặng đường lái đi xa không? Trong khi

tuân theo công thức nấu bếp, bạn có đo khối lượng các chất

liệu như muối trước khi thêm vào thức ăn không? Bạn có kiểm

thời gian bằng việc nhìn vào đồng hồ không? Đấy là những

cách đo bạn dùng mọi lúc. Không có khác biệt trong điều bạn

làm trong cuộc sống hàng ngày và dự án phần mềm: Bạn đo

tiến bộ của mình để cho bạn biết bạn làm tốt đến đâu và nếu có

vấn đề thì bạn phải sửa chúng. Tôi không biết tại sao nhiều

người không chú ý tới việc đo khi nó là một phần lớn trong

cuộc sống hàng ngày của họ?

Nếu bạn không nhìn vào đồng hồ đo xăng khi lái xe máy

thì điều gì là hoàn cảnh khi bạn chạy hết xăng? Bạn có tiếp tục

đi được không nếu đồng hồ xăng chỉ cho bạn là bạn không có

đủ xăng trong xe máy? Tưởng tượng rằng bạn nấu cái gì đó và

cứ đổ muối vào trong nó mà không đo gì cả? Mười hay hai

mươi thìa muối là tốt hơn hay chỉ hai thìa thôi? Tôi chắc chắn

trong trường hợp đó, bạn có thể phải uống nhiều nước sau đó vì

thức ăn của bạn có quá nhiều muối trong đó.

Nếu bạn nghĩ việc đo là khó và phí thời gian thì bạn sẽ

KHÔNG đi tới bác sĩ bởi vì bạn nghĩ ông ấy có thể tìm ra cái gì

đó sai với thân thể bạn? Bạn sẽ KHÔNG nhìn vào đồng hồ bởi

vì nó có thể cho bạn biết rằng bạn bị muộn giờ lên lớp? Bạn sẽ

KHÔNG kiểm xem mình có bao nhiêu tiền khi bạn mời bạn gái

đi xem phim? Bạn bao giờ cũng đo cái gì đó phải không? Bởi

vì bạn cần điều đó để ra quyết định đúng. Nếu bạn không có đủ

xăng thì bạn phải tới trạm xăng để rót đầy bình trước khi vào

cuộc hành trình. Nếu bạn không có đủ tiền thì bạn có thể đi ra

ngân hàng để rút tiền hay vay của bạn bè mình trước khi tới

nhà bạn gái để mời cô ấy đi xem phim. Cách đo là chỉ báo cho

bạn biết tình huống nơi bạn có thể có hành động đúng đắn.

186

Có chương trình đo cho dự án của bạn là quan trọng. Nó

giúp cho bạn kiểm được tiến bộ của mình, nó cho bạn biết bạn

đang làm tốt hay tồi cho nên bạn có thể sửa chữa nó trước khi

quá muộn. Tất nhiên, nếu bạn có lỗi thì bạn phải sửa chúng

nhưng điều gì sẽ xảy ra nếu bạn KHÔNG có đủ thời gian bởi vì

bạn không đo thời gian? Điều gì sẽ xảy ra khi bạn không sửa

một lỗi từ sớm và nó tích luỹ qua thời gian từ một lỗi thành

một trăm lỗi? Bao nhiêu người trong các bạn đi trong rừng

không có la bàn? Bao nhiêu người trong các bạn đi không có

bản đồ? Bạn đã bao giờ nghe thấy nói “Nếu bạn không biết bạn

đang ở đâu, bản đồ sẽ không ích gì.” Cách đo là những điều

giúp cho bạn quản lí dự án của mình vì chúng cho bạn biết khi

nào bạn phải lấy hành động sửa chữa. Không ai muốn bị lạc và

không ai muốn nhận được phần mềm đầy lỗi.

Cách đo và độ đo

Tôi nhận được một email người gửi viết: “Cái gì là khác

biệt giữa cách đo và độ đo và có bao nhiêu cách đo hay độ đo

phần mềm?"

Đáp: Theo định nghĩa cách đo là một chuẩn hay một đơn

vị đo chẳng hạn: Số các lỗi, số các dòng mã nguồn (SLOC). Độ

đo là một chỉ báo được tính toán dựa trên hai hay nhiều cách

đo. Chẳng hạn, số lỗi trên một nghìn dòng mã (KSLOC). Như

bạn có thể thấy hai hay nhiều cách đo tạo nên một độ đo và hai

hay nhiều độ đo cung cấp cho bạn thông tin. Chẳng hạn, 10 lỗi

trên một nghìn dòng mã là tốt hơn 40 lỗi trên một nghìn dòng

mã.

Có nhiều cách đo và độ đo, có lẽ có hàng trăm nhưng có

vài cách đo thông dụng trong dự án phần mềm như kích cỡ, nỗ

lực và chất lượng. Kích cỡ là khối lượng phần mềm mà dự án

187

phát triển như số dòng mã nguồn (SLOC). Kích cỡ cũng có thể

được đo bằng điểm chức năng hay số các chức năng. Dòng mã

là đơn giản, dễ dùng nhưng từng dự án phải xác định rõ ràng

cách đếm chúng một cách nhất quán. Chẳng hạn số trình biên

dịch cho khi nó dịch một chương trình. Điểm chức năng là tốt

hơn trong một số ứng dụng vì số này nhất quán qua các ngôn

ngữ và dễ đếm kích cỡ của dự án vào pha sớm ngay cả trước

khi viết mã.

Nỗ lực là khối lượng công việc mà một người được yêu

cầu thực hiện một nhiệm vụ. Chẳng hạn, số người-giờ dành cho

pha của phần mềm. Ví dụ, một dự án có một người làm việc

trong năm ngày để hoàn thành một hoạt động thiết kế có nỗ lực

là 40 người-giờ. Nếu nó có hai người làm việc năm ngày để

hoàn thành hoạt động thiết kế thì nỗ lực sẽ là 80 người- giờ.

Chất lượng có vài định nghĩa, tuỳ thuộc vào kiểu dự án

và tuỳ theo khách hàng hay người quản lí dự án. Một số người

coi chất lượng là số các lỗi trong sản phẩm, càng nhiều lỗi thì

chất lượng càng kém. Chẳng hạn số lỗi được tìm ra trong từng

pha, hay số lỗi trong từng nghìn dòng mã. Những người khác

định nghĩa chất lượng là việc dễ dùng sản phẩm thế nào, người

dùng càng dễ dùng sản phẩm thì chất lượng càng tốt. Bởi vì

từng người nhìn chất lượng một cách khác nhau, điều rất quan

trọng là làm sáng tỏ định nghĩa này bằng việc làm tài liệu sớm

trong kế hoạch dự án về điều bạn ngụ ý bởi chất lượng.

Quản lí rủi ro-1

Quản lí rủi ro đóng vai trò then chốt trong xác định thành

công của dự án phần mềm. Phần lớn việc quản lí dự án bao

gồm xác định rủi ro, lập kế hoạch biện pháp phòng ngừa, giám

sát rủi ro, và giải quyết với thay đổi. Bằng việc hiểu quản lí rủi

188

ro, người quản lí dự án có thể tránh và giảm tác động của rủi

ro, cung cấp ước lượng lịch biểu và ngân sách tốt hơn và chung

cuộc làm tăng sự thoả mãn của khách hàng.

Quản lí rủi ro bao gồm việc nhận diện rủi ro, thẩm định

hậu quả của rủi ro, xác định giải pháp, và lấy hành động. Cùng

với những bước này, trao đổi liên tục và theo dõi rủi ro giúp

cho người quản lí dự án vẫn ở trên ngọn các thay đổi. Để nhận

diện rủi ro, người quản lí có thể xem xét các vấn đề dự án điển

hình như rủi ro kĩ thuật, rủi ro nhân sự và rủi ro ước lượng. Bên

cạnh rủi ro chung có thể có các rủi ro đặc thù duy nhất cho dự

án. Bất kì dữ liệu lịch sử hay bài học rút ra từ dự án tương tự

đều có thể có ích trong nhận diện các rủi ro duy nhất này. Bảng

rủi ro có thể hữu dụng trong việc thẩm định các rủi ro có khả

năng xuất hiện thế nào và tác động sẽ lớn đến đâu. Dựa trên

thông tin này, kế hoạch có thể được thực hiện để giảm nhẹ và

giải quyết rủi ro. Rủi ro có thể xuất hiện hay rủi ro sẽ gây ra tác

độnglớn nên được quan sát chặt chẽ và đề cập sớm nhất có thể

được. Rủi ro càng được giảm nhẹ sớm, tác động càng đỡ bị phí

tổn.

Ước lượng rủi ro là thông thường trong dự án phần mềm

bởi vì khó dự đoán chính xác việc phát triển sẽ mất bao lâu.

Người quản lí dự án có thể theo dõi tiến độ thực tế qua lịch

biểu để xác định liệu dự án có đúng mục tiêu không. Rất

thường là thay đổi trong yêu cầu sẽ xuất hiện và vấn đề với

việc phát triển cũng sẽ nảy sinh. Những thay đổi này là một

phần của quản lí rủi ro bởi vì chúng đặt ra căng thẳng cho lịch

biểu và đưa dự án vào rủi ro không hoàn thành được đúng hạn.

Để giải quyết với những thay đổi không tránh khỏi, qui trình

kiểm soát thay đổi cần có tại chỗ. Việc này đảm bảo rằng các

thay đổi được giám sát cẩn thận và những người có liên quan

không mất cái nhìn về mục đích chính.

189

Kĩ năng thương lượng giữ một phần then chốt trong khả

năng của người quản lí dự án giải quyết các thay đổi. Người

quản lí dự án phải cân bằng sự thoả mãn của nhân viên và sự

thoả mãn của khách hàng bằng việc xem xét cả hai khi đánh giá

thay đổi yêu cầu và lịch biểu. Thay đổi có thể được đề cập tới

bằng việc điều chỉnh tài nguyên, thời gian, chi phí hay chức

năng. Điều này yêu cầu mặc cả với khách hàng và có lẽ cả với

nhân viên để xác định giải pháp tốt nhất. Ưu tiên cũng phải

được xác định để phát triển và cập nhật bản kế hoạch hiện thực.

Trong dự án phần mềm người quản lí dự án đương đầu

với thay đổi và vấn đề bởi vì bản chất phức tạp của phát triển

phần mềm họ có thể dùng kĩ năng quản lí rủi ro để ngăn ngừa

vấn đề và giải quyết chúng. Điều này bao gồm nhận diện rủi ro,

thẩm định chúng, xác định giải pháp, lấy hành động và thường

xuyên giám sát dự án. Qui trình quản lí rủi ro này cũng với ước

lượng tốt và kĩ năng thương lượng tạo khả năng cho người

quản lí dự án giải quyết với những thay đổi không tránh khỏi

xảy tới trên đường.

Rủi ro xảy ra trong mọi lĩnh vực, không chỉ phần mềm.

Đây là ba ví dụ minh hoạ cho vấn đề liên kết với rủi ro.

1) Công nghiệp xây dựng: Rủi ro phụ thuộc

Dự án xây dựng thường bao gồm nhiều nhà thầu chuyên

môn những người làm việc cùng nhau để xây nhà mới. Thời

gian của nhà thầu thường phụ thuộc vào các công nhân khác

điều có thể tạo ra rủi ro nếu như có nút thắt cổ chai. Nếu mọi

người làm nền móng không hoàn thành, bạn không thể xây

được tường và cột, bạn không thể đặt mái. Những phụ thuộc

này nên được xác định sớm nhất có thể được và được giám sát

để điều chỉnh lịch biểu khi cần thiết.

2) Công nghiệp ô tô: Rủi ro thay đổi thị trường

190

Tin tức gần đây đã chỉ ra thay đổi thị trường đã tác động

thế nào lên các dự án của ngành công nghiệp ô tô. Mặc dầu xe

lớn đã từng phổ biến trong những năm gần đây; nhu cầu về xe

hơi có hiệu quả nhiên liệu đã tăng lên. Những rủi ro này đặc

biệt khó dự báo nhưng chúng có thể có tác động khổng lồ và

nên được giám sát và đề cập nếu có thể được.

3) Nghiên cứu và phát triển thuốc : Rủi ro thực nghiệm

Thực hiện qui trình quản lí rủi ro là thách thức với nghiên

cứu và phát triển thuốc vì có mức độ phức tạp và bất định cao.

Nỗ lực có thể được đưa ra các bằng chứng về khái niệm mà có

thể được dùng hay không được dùng. Những nỗ lực này có thể

là khó dự báo và dễ dàng làm thay đổi chi phí và lịch biểu.

Ví dụ về bảng rủi ro cho dự án phần mềm.

Rủi ro Phân loại

Xác suất

Tác động

Lưu ý

1 Ước lượng kích cỡ có thể thấp

Rủi ro dự án

55% Găng Ước lượng kích cỡ có thể cần được điều chỉnh.

2 Ngân quĩ có thể bị giảm đi 15%

Rủi ro khách hàng

40% Lớn Chức năng có thể cần được giảm bớt dựa trên danh sách ưu tiên.

3 Dự án phức tạp

Rủi ro công nghệ

45% Găng Phần phức tạp của phần mềm có thể mất nhiều thời gian để hình dung ra. Điều này có thể làm nảy sinh việc điều chỉnh lịch biểu.

4 Học công nghệ mới

Rủi ro công nghệ

85% Găng Người phát triển sẽ học công nghệ mới mà sẽ làm chậm tiến độ lúc khởi đầu.

191

5 Nhiều người có liên quan tham gia

Rủi ro khách hàng

35% Lớn Sẽ khó làm hài lòng mọi người có liên quan và các yêu cầu có thể thăng giáng lớn.

6 Nhu cầu thị trường có thể thay đổi

Rủi ro tác động doanh nghiệp

25% Lớn Nhu cầu về phần mềm quản lí dự án nào đó có thể thay đổi sớm. Điều này có thể làm nảy sinh các yêu cầu chức năng khác.

7 Thay đổi cán bộ

Rủi ro con người

15% Lớn Việc thay đổi cán bộ là không cao vào từng lúc nhưng nó là rủi ro phải được giám sát.

8 Thay đổi phạm vi

Rủi ro ước lượng

75% Găng Bởi vì có nhiều người có liên quan tham gia nên rủi ro thay đổi phạm vi là cao. Qui trình thay đổi tốt có thể giúp giải quyết rủi ro này.

9 Phụ thuộc bên ngoài vào chuyển giao phần cứng

Rủi ro tác động doanh nghiệp

30% Găng Có phụ thuộc phần cứng là găng cho dự án này. Nếu có chậm trễ trong chuyển giao, lịch biểu sẽ phải được điều chỉnh.

10 Phần khoán ngoài của dự án

Rủi ro dự án

35% Lớn Dự án được khoán ngoài cho nên rủi ro được liệt kê dưới thấp sẽ nhân lên trong thẩm định rủi ro..

192

Quản lí rủi ro-2

Ngày nay, phần lớn các dự án phần mềm đều lớn và phức

tạp hơn, do đó chúng nhiều rủi ro hơn trước đây. Người quản lí

dự án phải để thời gian quản lí các rủi ro dự án bởi vì đó là yếu

tố then chốt trong xác định thành công của dự án. Để quản lí

rủi ro, người quản lí phải nhận diện mọi rủi ro, lập kế hoạch

phòng ngừa, giám sát rủi ro, và quản lí thay đổi. Bằng việc hiểu

quản lí rủi ro, người quản lí dự án có thể tránh và giảm bớt tác

động của rủi ro, cung cấp ước lượng lịch biểu và ngân sách tốt

hơn và đạt tới thoả mãn của khách hàng.

Quản lí rủi ro cũng bao hàm trao đổi liên tục về rủi ro với

tổ dự án và giám sát mọi rủi ro đã được nhận diện để duy trì vị

thế ở trên bất kì cái gì có thể xảy ra trong dự án. Để nhận diện

rủi ro, người quản lí có thể xem xét các vấn đề dự án phần

mềm điển hình như rủi ro kĩ thuật, rủi ro nhân sự và rủi ro ước

lượng. Bên cạnh các rủi ro chung có thể có những rủi ro đặc

biệt duy nhất cho dự án. Bất kì dữ liệu nào từ dự án tương tự

cũng đều có thể có ích trong việc nhận diện các rủi ro duy nhất

này. Dựa trên thông tin này, các kế hoạch có thể được thực

hiện để giải quyết các rủi ro. Phần lớn các dự án phần mềm đều

có những rủi ro sau đây: ước lượng kích cỡ, giới hạn ngân

sách, thực hiện công nghệ mới, sự tham gia của khách hàng bị

giới hạn, thị trường thay đổi, thay đổi cán bộ, thay đổi phạm vi,

các vấn đề phụ thuộc phần cứng, các vấn đề phụ thuộc mạng,

vấn đề kĩ năng của tổ dự án, và vấn đề cách làm việc tổ. Người

quản lí dự án phải xác định các rủi ro có thể xuất hiện hay các

rủi ro sẽ gây ra tác động lớn và giám sát chúng một cách cẩn

thận và giải quyết sớm nhất có thể được. Rủi ro được giảm nhẹ

càng sớm, tác động của nó càng đỡ tốn kém.

Ước lượng rủi ro là rất thông thường trong dự án phẩn

mềm bởi vì khó mà dự đoán chính xác việc phát triển sẽ mất

193

bao lâu. Người quản lí dự án phải liên tục theo dõi tiến độ thực

tế theo lịch biểu để xác định liệu dự án có tiến triển tương ứng

tới mục tiêu không. Trong hầu hết các dự án phần mềm, thay

đổi trong yêu cầu thường xuất hiện và can nhiễu vào tiến trình

phát triển và chúng phải là một phần của quản lí rủi ro bởi vì

chúng tác động lên lịch biểu và đưa dự án vào rủi ro không

hoàn thành được đúng thời gian. Để giải quyết với những yêu

cầu thay đổi, qui trình kiểm soát thay đổi phải được thiết lập để

đảm bảo rằng các thay đổi được giám sát, ưu tiên hoá cho nên

tổ có thể làm việc với chúng tương ứng. Thỉnh thoảng, khách

hàng muốn những thay đổi này được thực hiện ngay lập tức

nhưng không muốn thay đổi lịch biểu. Đây là chỗ kĩ năng

thương lượng của người quản lí dự án sẽ trở nên quan trọng.

Người quản lí dự án giỏi biết cách thương lượng với khách

hàng về những thay đổi và vẫn đạt tới sự thoả mãn của khách

hàng bởi vì cách người đó thảo luận và thương lượng về thay

đổi sẽ xác định ra kết quả của dự án.

Người quản lí dự án giỏi phải giữ cân bằng lịch biểu làm

việc của tổ với yêu cầu của khách hàng bằng việc xem xét cả

hai điều này khi đánh giá thay đổi. Người quản lí dự án có thể

đề cập tới yêu cầu thay đổi bằng việc điều chỉnh tài nguyên,

thời gian, chi phí hay chức năng và thảo luận với tổ để đi tới

giải pháp hợp lí nhất. Nhiều người quản lí dự án thiếu kinh

nghiệm không biết cách thương lượng nhưng vội vàng đồng ý

với khách hàng và ra lệnh cho tổ làm cái gì đó không hợp lí gây

tác động lên năng suất, chịu nhiều khiếm khuyết hơn và phá

huỷ cách làm việc tổ. Điều đó thường chấm dứt sự thoả mãn

của khách hàng bởi vì yêu cầu thay đổi đã được đồng ý trong

một thời gian ngắn nhưng khi sản phẩm bị muộn, đầy lỗi, thì

khách hàng sẽ rất không hài lòng trong thời gian dài.

Mọi dự án phần mềm đều có yêu cầu thay đổi nhưng

người quản lí dự án phần mềm biết cách giải quyết các vấn đề

thay đổi bằng việc dùng kĩ năng quản lí rủi ro để ngăn ngừa

194

chúng hay làm giảm tác động của chúng. Điều này bao gồm

việc nhận diện rủi ro thay đổi, đánh giá chúng, xác định giải

pháp, lấy hành động và thường xuyên giám sát dự án về tác

động. Tôi mạnh mẽ tin tưởng rằng quản lí rủi ro cùng với ước

lượng tốt và kĩ năng thương lượng là những kĩ năng tối thiểu

được tất cả những người quản lí dự án phần mềm cần tới.

Chất lượng phần mềm-1

Tôi nhận được một email hỏi: “Ai chịu trách nhiệm về

chất lượng phần mềm? Điều đó phải thuộc về người đảm bảo

chất lượng phần mềm bởi vì đó là việc của họ hay thuộc về

người kiểm thử, người phải kiểm tra chất lượng? Làm sao tôi

đo được chất lượng của sản phẩm phần mềm?"

Câu trả lời của tôi: “Lỗi là một cách đo chất lượng của

sản phẩm nhưng còn có nhiều cách đo hơn. Về căn bản, yêu

cầu phần mềm là nền tảng từ đó chất lượng được đo. Nếu sản

phẩm cuối không đáp ứng yêu cầu thì nó không phải là sản

phẩm có chất lượng. Mọi dự án đều phải tuân theo một qui

trình được xác định hay một tập các tiêu chí hướng dẫn các

hoạt động phần mềm. Nếu qui trình này không được tuân thủ,

việc phát triển cũng không có chất lượng cao. Cũng có một tập

các yêu cầu 'không tường minh" thường không được nhắc tới

(như tính bảo trì được, hiệu năng, tính dùng được, tính đổi qui

mô được v.v.). Nếu phần mềm chỉ tuân theo yêu cầu "tường

minh" của nó mà không đáp ứng yêu cầu "không tường minh"

thì chất lượng phần mềm cũng không rất tốt.

Vấn đề về chất lượng phần mềm vẫn còn với việc ai là

người chịu trách nhiệm cho chất phần mềm? Ai chịu trách

nhiệm lập mục đích chất lượng? Không có câu trả lời đúng,

chất lượng phần mềm có thể bị thoả hiệp.

195

Đảm bảo chất lượng phần mềm (SQA) chỉ có thể kiểm

điểm dự án để đảm bảo qui trình phát triển là được tuân theo và

những kiểm thử nào đó là được tiến hành đúng nhưng họ không

thể chịu trách nhiệm cho chất lượng phần mềm được. Người

kiểm thử phần mềm chịu trách nhiệm cho kiểm thử phần mềm

để đảm bảo rằng nó đáp ứng yêu cầu và chạy tương ứng nhưng

họ không chịu trách nhiệm cho chất lượng phần mềm. Thực tế

người quản lí dự án và tổ phát triển, người thực hiện phần mềm

chịu trách nhiệm cho chất lượng phần mềm. Người quản lí dự

án phải lập ra mục đích chất lượng cho cả các yêu cầu "tường

minh" như phải đáp ứng yêu cầu và ít khiếm khuyết và yêu cầu

"không tường minh" như hiệu năng, tính sử dụng được và tính

đổi qui mô được v.v. Để đảm bảo rằng phần mềm sẽ được thực

hiện đúng, người quản lí dự án phải nhận diện một số các kiểm

điểm trong toàn thể dự án và làm tài liệu chúng trong kế hoạch

dự án.

Các thành viên SQA sẽ kiểm điểm dự án bằng việc tuân

theo bản kế hoạch dự án do người quản lí dự án xác định. SQA

sẽ gặp người quản lí dự án xấp xỉ một tuần trước phiên kiểm

điểm theo lịch để thảo luận về ngày tháng thực tế, vật phẩm

cần được kiểm điểm, các thành viên tổ dự án mà SQA có thể

tiếp xúc để nêu câu hỏi. SQA phải chuẩn bị danh sách kiểm và

kiểm điểm các vật phẩm trước ngày kiểm điểm.

Trong khi kiểm điểm, SQA phải kiểm điểm hoạt động

của tổ dự án bằng việc kiểm tra vật phẩm công việc kết quả

theo qui trình liên kết được xác định trong bản kế hoạch dự án

và danh sách kiểm. Kết quả sẽ được ghi lại để xác định sự tuân

thủ và được báo cáo cho người quản lí dự án. Người quản lí dự

án phải giải quyết bất kì vấn đề không tuân thủ nào theo cách

đúng hạn (trong một hay hai tuần). Vấn đề không tuân thủ

không được giải quyết mau lẹ sẽ được đưa lên người quản lí

SQA và người quản lí phần mềm để giải quyết tình huống này

cùng người quản lí dự án. Nếu họ không thể giải quyết được

196

vấn đề thì nó phải đưa lên giám đốc phần mềm hay người quản

lí sản phẩm, người phải giải quyết tối hậu cho vấn đề để đảm

bảo sản phẩm có chất lượng.

Chất lượng phần mềm-2

Một số trong các bạn hỏi tôi về khác biệt giữa Đảm bảo

chất lượng phần mềm (SQA), Kiểm soát chất lượng phần mềm

(SQC) và Kiểm thử phần mềm. Về cơ bản, SQA hội tụ vào các

vấn đề có liên quan tới qui trình tạo ra sản phẩm phần mềm.

SQC hội tụ vào vấn đề có liên quan tới sản phẩm phần mềm.

Kiểm thử là phương pháp của SQC để chắc rằng sản phẩm làm

việc như mong đợi.

Thỉnh thoảng, mọi người lẫn lộn SQA với Kiểm thử và

coi SQA như tổ chức kiểm thử, điều này là KHÔNG đúng.

Chuẩn IEEE 12207-2008 nói rằng “Mục đích của Đảm bào

chất lượng phần mềm (SQA) là cung cấp đảm bảo rằng sản

phẩm công việc và qui trình tuân thủ theo kế hoạch đã xác định

trước.” Chuẩn này cũng nói rằng qui trình SQA phải được phối

hợp với các hoạt động dự án có liên quan như qui trình trắc

nghiệm, kiểm nghiệm, kiểm điểm và kiểm định để nhận diện

việc không tuân thủ. Nó ngụ ý rằng SQA đảm bảo rằng sản

phẩm và qui trình tuân thủ theo kế hoạch dự án và chuẩn của tổ

chức. Chuẩn này yêu cầu SQA đảm bảo rằng những qui trình

này được làm tài liệu, được tuân theo và nhất quán với chính

sách của công ti. Sản phẩm hoàn toàn thoả mãn các yêu cầu và

được chấp nhận cho người dùng. Chẳng hạn: SQA kiểm điểm

yêu cầu, kiến trúc và thiết kế dự án để đảm bảo rằng chúng

được làm tài liệu tương ứng và các thành viên tổ dự án tuân

theo qui trình của tổ chức để phát triển phần mềm. SQC và

197

Kiểm thử thực hiện chương trình phần mềm để chắc rằng nó

làm việc và đáp ứng yêu cầu.

Qui trình SQA có thể được mô tả như sau:

1. Xác định kế hoạch đảm bảo chất lượng để nhận diện

điều cần làm đảm bảo chất lượng.

2. Hỗ trợ người quản lí dự án xác định các chuẩn, hướng

dẫn và các kĩ thuật khác cho dự án

3. Đảm bảo kiểm soát chất lượng một cách hệ thống cho

các qui trình và sản phẩm như kiểm điểm, giám định,

kiểm định cũng như quản lí/kiểm soát cấu hình, đưa ra

sản xuất, kiểm soát dự án, hợp đồng và quản lí nhà cung

cấp, kiểm soát tài liệu, bảo trì, sao lưu và phục hồi, và

an ninh.

4. Duy trì bản ghi chất lượng để theo dõi vấn đề.

5. Phân tích và báo cáo về vấn đề chất lượng cho cấp quản

lí.

6. Duy trì và cải tiến chất lượng sản phẩm.

Bởi vì SQA bao giờ cũng kiểm tra về bất kì sự không

tuân thủ nào và một số người phát triển không thích bị giám

sát, thường có xung đột giữa họ. Một số người phát triển coi

SQA giống như "cảnh sát" và không bày tỏ mấy kính trọng với

công việc của họ. Điều này hầu hết là do thiếu đào tạo về chất

lượng cho người phát triển và sự kiện là nhiều SQA KHÔNG

được đào tạo tốt và KHÔNG có đủ kinh nghiệm đáng đòi hỏi

kính trọng. Tôi đã thấy nhiều người làm việc như SQA chỉ có

kinh nghiệm phần mềm hạn chế. Nhiều người quản lí KHÔNG

coi SQA là quan trọng và thường phân công người mới, người

không có nhiều kinh nghiệm vào việc này. Một số người quản

lí thậm chí còn bảo tôi: “Nếu họ KHÔNG thể phát triển phần

mềm tốt, chúng tôi xếp họ làm việc như SQA”. Đây là sai lầm

198

rất lớn và đó là lí do tại sao nhiều SQA không thành công mấy

trong việc của họ. Đó là lí do tại sao nhiều phần mềm có khiếm

khuyết.

SQA thành công nhất thường bắt nguồn từ nhóm lãnh

đạo kĩ thuật, chính là người phát triển có kinh nghiệm. Những

người này thường lãnh đạo các dự án, giải quyết các vấn đề kĩ

thuật, và cung cấp đào tạo cho người phát triển mới. Họ biết rõ

về phát triển phần mềm, biết rõ qui trình phát triển, và họ được

người phát triển kính trọng. Những người này rất có tính dự

ứng trong hướng dẫn, đào tạo và xác định qui trình cho nên đề

bạt họ vào SQA là tiến bộ tự nhiên trong nghề nghiệp của họ.

Nhiều người quản lí biện minh rằng vì họ là chủ yếu kĩ thuật,

họ được cần để làm việc trong dự án nhưng luận cứ của tôi là

mọi dự án đều cần ai đó để đảm bảo chất lượng và đầu tư vào

SQA là bản chất cho thành công của dự án.

Theo kinh nghiệm của tôi, thay vì kiểm tra sự không tuân

thủ và đòi hỏi hành động sửa chữa, người SQA dự ứng phải

thiết lập môi trường thúc đẩy chất lượng và bao quát vòng đời

đầy đủ của việc phát triển từ quan niệm tới hoàn thành. SQA

phải trao đổi tầm quan trọng của tuân thủ qui trình để tạo ra sản

phẩm chất lượng và đào tạo người phát triển tuân theo qui trình

tương ứng. Thay vì đơn thuần xác nhận tuân thủ theo kế hoạch,

QA phải đảm bảo rằng người phát triển hiểu mọi bước cần thiết

để tạo ra sản phẩm chính xác, đầy đủ và chất lượng cao. Về cơ

bản người SQA dự ứng là người thầy, người thầy kèm, huấn

luyện viên, và người hướng dẫn để giúp cho người phát triển

chuyển giao chất lượng sản phẩm và liên tục cải tiến cách họ

phát triển phần mềm.

199

Chất lượng phần mềm-3

Có câu hỏi về ai chịu trách nhiệm về chất lượng phần

mềm nhưng ít người có thể trả lời được nó. Nếu bạn hỏi mười

người, bạn có thể có mười hai câu trả lời khác nhau bởi vì một

số người có thể có nhiều câu trả lời. Tại sao khó trả lời cho một

câu hỏi đơn giản như thế này? Chúng ta hãy hỏi những người

đang làm việc trong công nghiệp phần mềm: Một số người lập

trình tin đảm bảo chất lượng (QA) là trách nhiệm về chất

lượng, bởi vì họ có từ "chất lượng" ở tiêu đề. Người đảm bảo

chất lượng tin người kiểm thử chịu trách nhiệm về chất lượng

vì việc làm của họ là kiểm tra về chất lượng. Người kiểm thử

tin người phát triển chịu trách nhiệm về chất lượng vì họ xây

dựng phần mềm. Người phát triển tin kiến trúc sư chịu trách

nhiệm về chất lượng vì họ chỉ thực hiện điều kiến trúc sư thiết

kế cho phần mềm. Kiến trúc sư tin kĩ sư yêu cầu chịu trách

nhiệm về chất lượng vì người đó cung cấp thông tin cho kiến

trúc sư. Thông tin sai dẫn tới thiết kế sai. Kĩ sư yêu cầu tin

khách hàng chịu trách nhiệm về chất lượng vì họ nói cho kĩ sư

yêu cầu điều họ muốn. Nếu họ không giải thích rõ ràng điều họ

muốn, đó là vấn đề của họ. Khách hàng tin người quản lí dự án

chịu trách nhiệm về chất lượng vì người đó chịu trách nhiệm

cho toàn thể sản phẩm phần mềm. Người quản lí dự án tin các

giáo sư chịu trách nhiệm về chất lượng vì họ dạy phát triển

phần mềm. Nếu họ không dạy về chất lượng thì không ai biết

về nó. Về cơ bản, không ai muốn chịu trách nhiệm về chất

lượng phần mềm.

Vấn đề chính là sự không tin cậy giữa các nhóm chức

năng và vai trò cùng trách nhiệm không rõ ràng trong toàn thể

qui trình phát triển. Mọi người chỉ hội tụ vào việc làm của họ,

và điều họ phải làm bên trong khu vực giới hạn của họ. Bất kì

cái gì bên ngoài khu vực của họ KHÔNG phải là mối quan tâm

của họ. Không ai biết nhóm khác đang làm gì. Không ai muốn

200

chịu trách nhiệm về sản phẩm cuối cùng. Không ai quan tâm về

chất lượng phần mềm. Phần lớn không hiểu khái niệm qui trình

phần mềm hay để thời gian để hiểu toàn thể việc phát triển

phần mềm. Họ chỉ chăm nom về điều họ làm theo cách hạn

chế. Sinh viên được dạy về lập trình cho nên họ biết cách viết

mã và kiểm thử. Họ có thể học về vòng đời phần mềm nhưng

nó chỉ là khái niệm mơ hồ chừng nào họ còn chưa thực sự thực

hiện cái gì đó qua toàn thể vòng đời. Ngay cả sau vài năm làm

việc, một số người đã học về kiến trúc rồi họ chỉ tập trung vào

những khu vực đó. Khi mọi người được đề bạt làm người quản

lí, họ học cách quản lí dự án bởi vì thiết kế, viết mã và kiểm

thử là những thứ của quá khứ và việc làm của ai đó khác. Rất ít

người quan tâm về toàn thể qui trình phần mềm hay bức tranh

lớn hơn của phát triển phần mềm. Với họ chất lượng là khái

niệm, không phải là trách nhiệm.

Khi vấn đề chất lượng xảy ra, tình huống điển hình có thể

xảy ra giống thế này trong kịch bản sau:

“Người phát triển giải thích: “Vấn đề chất lượng được

gây ra bởi các đặc tả yêu cầu phần mềm kém, đó là lỗi của kĩ

sư yêu cầu.” Kĩ sư yêu cầu không đồng ý: “Không đấy không

phải do tôi, đấy là do khách hàng cứ đổi ý hoài và người kiểm

thử không kiểm điểm những thay đổi cho nên lỗi không được

phát hiện ra.” Người kiểm thử phản đối: “Người làm cấu hình

chưa bao giờ nói cho tôi cái gì về thay đổi cả, chúng không

được làm tài liệu. Đấy là lỗi của người quản lí cấu hình.”

Người kiểm thử khác than: “Điều đó thật đáng thất vọng.

Không ai đánh giá cao điều chúng tôi làm, họ không biết rằng

chúng tôi làm việc vất vả.” Kĩ sư yêu cầu nhảy vào: “Người

kiểm thử là vấn đề, tôi không có ý tưởng về họ làm gì, họ

không có kĩ năng, nhiều người chỉ mới tốt nghiệp từ trường ra

mà không có kinh nghiệm.” Người kiểm thử phàn nàn: “Đấy là

lỗi của người phát triển, họ xây dựng mã, họ phải sửa chúng

cho nên chất lượng là lỗi của người phát triển.” Người phát

201

triển tranh cãi: “Chúng tôi chỉ viết mã điều kiến trúc sư thiết kế

ra, nếu thiết kế kém thì đó là lỗi của kiến trúc sư không phải

chúng tôi.” Kiến trúc sư giận dữ: “Chất lượng là điều các anh

xây dựng trong mã, không phải điều tôi thiết kế trên giấy.

Người đảm bảo chất lượng phải kiểm mã cho nên chất lượng là

trách nhiệm của họ.” Người đảm bảo chất lượng phản đối: “Tôi

chưa bao giờ kiểm điểm mã cả, tôi chỉ kiểm tra tài liệu. Người

kiểm thử kiểm mã cho nên trách nhiệm phải ở họ.” Người kiểm

thử buộc tội: “Chất lượng là việc của anh, chức danh của anh là

“Đảm bảo chất lượng” anh là vấn đề, anh lười thì có.” Người

quản lí dự án bước vào: “Thế là đủ rồi, tôi không muốn bất kì

biện luận nào trong tổ của tôi. Chúng ta có một tổ tốt ở đây.

Vấn đề chất lượng tới từ ai đó bên ngoài dự án, không phải

chúng ta. Chúng ta phải đi tới gốc rễ của vấn đề chính là ở

khách hàng.” Tất nhiên, việc trách móc tiếp tục và vấn đề chất

lượng phần mềm sẽ không bao giờ được giải quyết.

Câu hỏi là ai nên chịu trách nhiệm về chất lượng? Trong

phát triển phần mềm, kiểm thử được dùng để nhận diện lỗi và

ngăn ngừa chúng khỏi lọt vào sản phẩm cuối cùng. Việc kiểm

thử KHÔNG tạo ra chất lượng và tổ kiểm thử KHÔNG chịu

trách nhiệm về chất lượng. Việc kiểm thử chỉ cung cấp thông

tin về chất lượng để cho nó có thể được cải tiến. Về cơ bản, tổ

kiểm thử giúp tổ phát triển cải tiến chất lượng vì họ càng phát

hiện lỗi sớm, tổ phát triển càng sửa chúng sớm. Tổ kiểm thử

KHÔNG thay đổi chất lượng phần mềm, họ chỉ cung cấp kết

quả kiểm thử cho tổ phát triển. Tuỳ tổ phát triển ra quyết định

về cách giải quyết với các lỗi như sửa chúng hay bỏ qua chúng.

Để đảm bảo chất lượng và chắc chắn lỗi được sửa, có

nhóm thứ hai tên là đảm bảo chất lượng phần mềm (SQA).

Công việc của SQA là kiểm tra và chắc các lỗi đã được sửa và

người phát triển tuân theo qui trình phần mềm. SQA hỗ trợ cho

cải tiến chất lượng nhưng KHÔNG chịu trách nhiệm về chất

lượng. Giống như người kiểm thử SQA chỉ cung cấp thông tin

202

về chất lượng để cho nó có thể được cải tiến. SQA thu thập

thông tin về qui trình và sản phẩm rồi chuyển điều này cho

người phát triển và người quản lí để họ có thể sửa lỗi. Vậy

SQA giúp giảm bớt các thể nghiệm của lỗi trong sản phẩm khi

nó được dùng. SQA không thay đổi chất lượng mà chỉ chắc

chắn nguồn của lỗi bị khử bỏ. Chính những người thực tế thực

hiện thiết kế và dựng sản phẩm là người thực tế CÓ THỂ cải

tiến chất lượng.

Người phát triển dựng mã tương ứng theo thiết kế và yêu

cầu. Họ CHỊU trách nhiệm về chất lượng của mã của họ và

phải tiến hành kiểm thử đơn vị riêng của họ để kiềm tra các lỗi.

Nếu họ làm việc kém, lỗi sẽ xảy ra. Khi người kiểm thử thấy

lỗi, họ sẽ thông báo cho người phát triển để sửa chúng. Người

phát triển PHẢI sửa các lỗi này vì họ CHỊU trách nhiệm về

chất lượng của mã. SQA cũng phải tham gia để chắc rằng

chúng được sửa tương ứng bằng việc để cho người quản lí dự

án biết điều sẽ xảy ra cho chất lượng nếu lỗi không được sửa.

Tuy nhiên, nếu thiết kế không đầy đủ hay thiếu thuộc tính

chất lượng thì kiến trúc sư cũng chịu trách nhiệm về chất

lượng. Công việc của kiến trúc sư là kiểm điểm yêu cầu của

khách hàng một cách thấu đáo và đưa ra các thuộc tính chất

lượng bổ sung để đảm bảo thiết kế là tốt cho nên người phát

triển có thể thực hiện chúng. Không may là kiến trúc sư phần

mềm hiếm khi được dạy trong trường ngày nay. Nhược điểm

then chốt trong đào tạo hiện tại là thiếu tri thức và kĩ năng về

một khu vực rất quan trọng trong phát triển phần mềm: Đào tạo

về kiến trúc. Chức năng bị thiếu này là nguyên nhân chính gây

ra trong chất lượng của phát triển phần mềm.

Tất nhiên, kiến trúc sư thiết kế phần mềm dựa trên đặc tả

yêu cầu phần mềm của kĩ sư yêu cầu. Nếu kĩ sư yêu cầu

KHÔNG làm tốt việc của họ trong khi làm việc với khách

hàng, hiểu nhu cầu của họ và làm tài liệu chúng một cách kĩ

203

lưỡng thì đó cũng là lỗi của họ. Không may là cũng giống như

kiến trúc, kĩ nghệ yêu cầu hiếm khi được dạy trong trường.

Nhược điểm then chốt trong đào tạo hiện thời là thiếu tri thức

và kĩ năng trong khu vực quan trọng này của phát triển phần

mềm: Đào tạo kĩ nghệ yêu cầu. Chức năng thiếu này cũng là

nguyên nhân chính trong chất lượng của phát triển phần mềm.

Người quản lí dự án chung cuộc chịu trách nhiệm cho

toàn thể dự án VÀ chất lượng của sản phẩm. Người quản lí

phải đảm bảo rằng qui trình được tuân theo, mọi lỗi phải được

sửa trước khi đưa ra cho khách hàng cũng như các yêu cầu

được làm tài liệu tốt theo nhu cầu của khách hàng. Kiến trúc

phần mềm được thiết kế với thuộc tính chất lượng đầy đủ. Về

căn bản người quản lí dự án chịu trách nhiệm cho mọi thứ

trong dự án. Điều không may là giống như kiến trúc và kĩ nghệ

yêu cầu, quản lí dự án cũng hiếm khi được dạy trong trường.

Nhược điểm then chốt trong đào tạo hiện thời là thiếu tri thức

và kĩ năng trong khu vực quan trọng này của phát triển phần

mềm: đào tạo về quản lí dự án phần mềm. Chức năng thiếu này

có lẽ là yếu tố mấu chốt nhất trong chất lượng của phát triển

phần mềm.

Nếu bạn nhìn vào chất lượng bạn sẽ thấy rằng vấn đề

chính là thiếu hiểu biết về qui trình phần mềm và việc phân vai

trò, trách nhiệm và thẩm quyền. Phân chia phát triển phần mềm

hiện thời được chia thành các nhóm chức năng. Từng nhóm

vận hành độc lập với nhau. Không ai biết nhóm khác đang làm

gì. Không ai chịu trách nhiệm cho toàn thể qui trình. Mọi người

chỉ tập trung vào việc làm của họ, và điều họ phải làm trong

khu vực giới hạn của họ. Bất kì cái gì bên ngoài khu vực của

họ KHÔNG phải là mối quan tâm của họ. Không ai muốn chịu

trách nhiệm cho sản phẩm cuối cùng. Điều không may là qui

trình phần mềm hiếm khi được dạy trong trường. Nhược điểm

then chốt trong đào tạo hiện thời là thiếu tri thức và kĩ năng

trong CÁI NHÌN TOÀN BỘ về phát triển phần mềm: Đào tạo

204

qui trình phần mềm. Chức năng thiếu này có lẽ là lí do cho sau

bao nhiêu năm, chất lượng của phát triển phần mềm đã

KHÔNG được cải thiện.

Sinh viên phần mềm phải hiểu rằng lộ trình để xây dựng

sản phẩm phần mềm chất lượng cao là qui trình phần mềm. Qui

trình phần mềm phải được xác định sớm và được chấp nhận để

đáp ứng cho nhu cầu của kĩ sư phần mềm khi họ tiến hành phát

triển sản phẩm phần mềm. Qui trình phần mềm cung cấp khuôn

khổ cho các hoạt động quản lí mà có thể rất dễ dàng mất kiểm

soát. Các kiểu dự án khác nhau yêu cầu qui trình phần mềm

khác nhau. Sản phẩm làm việc của kĩ sư phần mềm như

chương trình, tài liệu và dữ liệu được tạo ra như hệ quả của

hoạt động được xác định bởi qui trình phần mềm.

Đây có phải là lúc để nhìn vào những tri thức và kĩ năng

này để sửa hệ thống giáo dục không? Đây có phải là lúc để hội

tụ vào chất lượng và giảm chi phí không? Đây có phải là lúc

nhìn vào đào tạo hiện thời và hỏi câu hỏi đúng không? Đây có

phải là lúc cho công ti phần mềm học về qui trình phần mềm

không? Đây có phải là lúc cho công nghiệp phần mềm hiểu

mối quan hệ giữa qui trình và chất lượng không? Những chỉ

báo tốt nhất về qui trình phần mềm đã làm việc tốt đến đâu là

chất lượng, thời gian và chi phí của sản phẩm phần mềm.

Chất lượng phần mềm-4

Một sinh viên hỏi: “Chất lượng phần mềm là gì? Bạn em

bảo em chất lượng nghĩa là phần mềm không có lỗi nhưng thầy

giáo của em nói chất lượng là đạt tới sự thoả mãn của khách

hàng. Ai đúng?"

205

Đáp: Có nhiều định nghĩa về chất lượng phần mềm tuỳ

the các cách nhìn khác nhau. Từ cách nhìn của khách hàng,

chất lượng có thể được xác định là việc đáp ứng nhu cầu của họ

và đạt tới thoả mãn của họ. Từ cách nhìn của người phát triển,

chất lượng có thể được định nghĩa là phần mềm được thiết kế

tốt thế nào và sản phẩm tuân thủ tốt thế nào theo thiết kế đó

(Đáp ứng yêu cầu đặc tả chức năng). Từ cách nhìn của người

quản lí dự án, chất lượng có thể được xác định là đáp ứng các

mục đích của dự án như chi phí, lịch biểu và yêu cầu của khách

hàng. Từ cách nhìn của người chủ công ti, chất lượng được dựa

trên khách hàng sẵn lòng trả bao nhiêu tiền cho sản phẩm. Từ

cách nhìn hàn lâm hay cách nhìn của các giáo sư, chất lượng có

thể được xác định như qui trình hiệu quả tạo ra sản phẩm mà

không có lỗi nào và cung cấp giá trị đo được cho những người

tạo ra sản phẩm và người dùng nó. Tôi chắc là còn nhiều định

nghĩa nữa.

Bởi vì có nhiều định nghĩa, mọi người đều đúng theo góc

nhìn của họ. Nếu sản phẩm phần mềm đầy lỗi, thì không ai sẽ

mua nó (góc nhìn của người chủ công ti). Nếu phần mềm

không đáp ứng nhu cầu của người dùng hay không thực hiện

tương ứng, thì khách hàng sẽ không hài lòng và có thể không

muốn làm kinh doanh với công ti thêm nữa (cách nhìn của

khách hàng). Nếu phần mềm mất quá lâu mới dựng xong,

không đáp ứng lịch biểu, vượt quá ước lượng chi phí, với nhiều

lỗi thì việc làm của người quản lí dự án có thể thành vấn đề

nghiêm trọng (góc nhìn của người quản lí dự án). Nếu phần

mềm không được thiết kế tốt, đầy vấn đề và không đáp ứng đặc

tả thiết kế thì người phát triển sẽ phải chữa chúng, hay làm lại

nó. Trong trường hợp đó họ có thể không có khả năng để giữ

việc làm lâu (cách nhìn của người phát triển). Nếu phần mềm

không được phát triển theo qui trình được xác định, đầy lỗi và

không cung cấp giá trị đo được cho người dùng thì có thể

chương trình đào tạo là không tốt (góc nhìn hàn lâm). Tuy

206

nhiên, không lỗi chỉ là "ước muốn", không thể có không lỗi

được dù bạn kiểm thử bao nhiêu lần cho phần mềm. Không ai

có thể đảm bảo rằng phần mềm không có lỗi.

Chất lượng phần mềm-5

Một sinh viên hỏi: "Kế hoạch chất lượng là gì? Khi nào

bạn xây dựng kế hoạch phát triển? Ai nên chịu trách nhiệm cho

chất lượng?"

Đáp: Kế hoạch chất lượng mô tả cách việc quản lí chất

lượng sẽ được áp dụng cho dự án và xác nhận bất kì chuẩn, thủ

tục, kĩ thuật chất lượng nào sẽ được dùng trong dự án. Kế

hoạch chất lượng phải được phát triển ngay từ đầu dự án. Nó

có thể là một bản kế hoạch tách rời hay là một phần của kế

hoạch dự án, tuỳ theo kiểu dự án. Chất lượng phải là một phần

của qui trình phát triển phần mềm, không phải là cái gì đó được

đo ở cuối. Mọi người trong dự án nên có trách nhiệm về chất

lượng, kể cả người quản lí dự án, người phát triển, người kiểm

thử, đảm bảo chất lượng v.v.

Chất lượng thường được xác định tuỳ theo miền. Trong

hoàn cảnh của phần mềm hay hệ thông tin, chất lượng là chức

năng và cấu trúc của sản phẩm phần mềm. Chất lượng chức

năng dựa trên việc sản phẩm tuân thủ tốt tới đâu theo thiết kế

đã cho, dựa trên các đặc tả yêu cầu phần mềm. Chất lượng cấu

trúc dựa trên thuộc tính chất lượng mà thường không được xác

định rõ ràng bởi khách hàng nhưng người phát triển phần mềm

giỏi phải thêm vào cho sản phẩm như hiệu năng, tính dùng

được, tính kiểm thử được, tính bảo trì được v.v. Sản phẩm cuối

cùng có thể đáp ứng mọi yêu cầu nhưng nếu nó chạy rất chậm

hay khó dùng thì nó vẫn bị coi là sản phẩm có chất lượng

không tốt vì nó không đáp ứng cho các yêu cầu chất lượng cấu

207

trúc. Các yêu cầu chức năng có thể được đo qua việc kiểm thử

nhưng chất lượng cấu trúc chỉ có thể được đo qua phân tích mã

nguồn và kiến trúc và thiết kế của nó.

Chất lượng phần mềm-6

Một người mới tốt nghiệp viết cho tôi: “Em chỉ mới làm

việc như người phát triển phần mềm được ba tháng. Người

quản lí dự án coi lịch biểu là quan trọng nhất nhưng không chú

ý tới chất lượng. Chúng em thường dừng kiểm thử khi lịch đến

hạn. Qui tắc của công ti là “Nó là đủ tốt rồi.” Thầy nghĩ gì về

qui tắc "đủ tốt"? Xin thầy lời khuyên."

Đáp: Để tôi bắt đầu bằng một câu chuyện ngắn: Một

người xây nhà giỏi dạy con mình về thương mại. Qui tắc của

ông ấy là đơn giản: “Xây từng ngôi nhà dường như ông xây nó

cho bản thân ông.” Sau nhiều năm, ông ấy cho phép con trai

bắt đầu xây nhà theo cách riêng của anh ta mà không có giám

sát của ông ấy. Ông ấy bảo anh thanh niên: “Con đã học mọi

thứ từ bố nên bây giờ con có thể tự mình làm nó. Bố sẽ để con

xây ngôi nhà mới không có bố. Bố sẽ gặp con khi nhà hoàn

thành, nhưng nhớ lấy, xây nó dường như con xây nó cho bản

thân con.”

Người con hình dung rằng không có bố theo dõi, anh ta

có thể làm cái gì đó anh ta thích. Anh ta nghĩ: “Mình làm nó

"đủ tốt" thôi bằng việc thay đổi các thứ vì chẳng ai sẽ bao giờ

biết.” Thế là anh ta mua gỗ rẻ để làm vật tư cho khung nhà, xi

măng mác thấp, và vật tư chất lượng thấp hơn bố anh ta đã

dùng. Vì trả ít tiền hơn cho vật tư chất lượng thấp, anh ta có thể

làm được nhiều tiền cho bản thân mình.

208

Khi ngôi nhà được hoàn thành, người bố tới xem ngôi

nhà đã xong. Trên bề mặt, mọi thứ dường như sánh đúng theo

thiết kế của ngôi nhà. Người bố nhận xét: “Tốt đấy, bố sung

sướng là con đã học được cách xây nhà rất tốt. Bây giờ, bố có

tin vui cho con. Con đã xây ngôi nhà này cho con và gia đình

con. Nó là món quà của bố cho con vì công việc con đã thực

hiện cùng bố trong nhiều năm. Bây giờ con có thể chuyển tới

sống trong ngôi nhà này.”

Tôi không biết liệu công ti của bạn xây dựng phần mềm

cho khách hàng bên ngoài hay để dùng nội bộ. Kiểm thử được

thiết kế để bắt lỗi, nếu bạn không kiểm thử thì có thể là phần

mềm của bạn sẽ có lỗi. Nếu phần mềm có lỗi, ai đó sẽ phải sửa

nó. Người dùng sẽ không dung thứ cho phần mềm còn khiếm

khuyết. Sửa lỗi tốn tiền và thời gian cho nên ý tưởng “đủ tốt” là

ý tưởng xấu và rất vô trách nhiệm. Làm mọi thứ trong vội vàng

để đáp ứng lịch biểu là cách quản lí xấu. Không có những điều

như phần mềm "đủ tốt".

Cải tiến chất lượng phần mềm

Có nhiều cách để đánh giá chất lượng phần mềm như nó

đáp ứng các yêu cầu tốt thế nào, nó hữu dụng cho người dùng

thế nào, và số lỗi được tìm ra khi kiểm thử. Tuy nhiên, với

nhiều người phát triển, chất lượng thường là điều cuối cùng họ

kiểm trước khi đưa ra cho khách hàng. Phần lớn việc kiểm chất

lượng được thực hiện trong pha kiểm thử và điều đó thường là

quá trễ. Bạn càng nhận diện lỗi sớm, càng dễ và càng đỡ tốn

phí cho sửa lỗi. Theo nhiều khảo cứu, mỗi lần một lỗi lọt sang

pha tiếp, nó tăng độ phức tạp lên theo thừa số 5 và tăng chi phí

sửa lên thừa số 10. Chẳng hạn, một lỗi tốn $10 để sửa trong

pha thiết kết, $100 để sửa trong pha viết mã và $1000 để sửa

209

trong pha kiểm thử và $10,000 để sửa sau khi đưa ra cho khách

hàng.

Vì yêu cầu sai có thể làm tăng độ phức tạp trong thiết kế

và viết mã lên nhiều lần, bằng việc giám sát chất lượng trong

toàn bộ qui trình phát triển, người quản lí dự án có thể quyết

định liệu có tiếp tục phát triển hay thay vì thế thiết kế lại và sửa

lỗi. Thỉnh thoảng tốt hơn cả là bắt đầu lại dự án thay vì tiếp tục

sửa lỗi vì phần mềm quá phức tạp và khó thay đổi. Trong các

pha phát triển phần mềm, người quản lí dự án phải có khả năng

theo dõi các lỗi trong từng pha để phán xét chất lượng của phần

mềm vào mọi lúc được cho. Đến cuối từng pha, người quản lí

dự án phải đánh giá cả chất lượng và tính đầy đủ để xác định

liệu dự án có nên chuyển sang pha tiếp hay không. Cách tốt

nhất là dùng danh sách kiểm ở cuối từng pha vòng đời.

Khi một lỗi được tìm ra, người quản lí dự án phải ghi lại

nó trong sổ kí sự lỗi. Nó sẽ được cho một con số để cho phép

nó được tham chiếu tới từ lúc tạo ra cho tới lúc giải quyết. Điều

quan trọng là lỗi được cho một kiểu ưu tiên nào đó phản ánh độ

nghiêm trọng của nó. Ưu tiên này sẽ xác định khi nào nó cần

được sửa và liệu lỗi này có là đủ nghiêm trọng tác động tới lịch

biểu không. Từng lỗi đều nên được phân công cho một người

phát triển và sau khi nó được sửa, đảm bảo chất lượng phải

chắc rằng nó được kiểm thử đầy đủ và được ghi lại trong sổ sự

kí lỗi (mở, đóng). Một yếu tố phẩm chất quan trọng khác là tỉ lệ

theo đó lỗi này được tìm ra. Điển hình tỉ lệ tìm ra cao được

mong đợi trong các pha phát triển sớm, tỉ lệ này nên giảm đi

qua thời gian khi nhiều lỗi trong chúng đã được sửa.

Người quản lí dự án cũng phải đánh giá nguyên nhân của

lỗi để xác định chức năng hay mô đun nào của phần mềm có

nhiều lỗi nhất. Bằng việc biết các khu vực sinh lỗi này, người

quản lí có hành động như tăng nhiều kiểm thử hơn trong những

khu vực nào đó của mã; thiết kế lại chức năng hay mô đun; hay

210

phân công những người có kinh nghiệm hơn để làm việc trên

các khu vực sinh lỗi.

Các công ti theo dõi lỗi và tổ chức chúng dựa trên độ

nghiêm trọng, ưu tiên và các tiêu chí khác có thể cải tiến đáng

kể chất lượng của họ. Bằng việc thường xuyên đánh giá về chất

lượng vào bất kì lúc nào trong vòng đời phát triển, họ có thể cải

tiến chất lượng và giảm lỗi với niềm tin lớn, biết rõ rằng mọi

nỗ lực đã được được thực hiện để tìm và sửa lỗi.

Đảm bảo chất lượng phần mềm

Khi dự án phần mềm trở nên lớn hơn và phức tạp hơn,

vai trò của Đảm bảo chất lượng phần mềm - Software Quality

Assurance (SQA) trở nên gay gắt hơn. Ngay cả ngày nay, các

phương pháp để đảm bảo chất lượng phần mềm vẫn thường

không được nhiều người quản lí dự án hiểu rõ. Đảm bảo chất

lượng phần mềm yêu cầu rằng tri thức và kỉ luật kĩ nghệ phải

được áp dụng trong MỌI pha của vòng đời phát triển, KHÔNG

phải là những pha cuối cùng của kiểm thử hay đưa ra như nhiều

người vẫn hiểu lầm. Người kĩ sư đảm bảo chất lượng phần

mềm được yêu cầu có nhiều năm phát triển phần mềm và tri

thức miền đủ để đánh giá tính đầy đủ và tính đúng đắn của yêu

cầu hệ thống, và họ phải có khả năng xác định liệu thiết kế có

tổ hợp mọi yêu cầu một cách chính xác không. Cuối cùng,

người kĩ sư SQA chịu trách nhiệm về quản lí thông báo liệu sản

phẩm phần mềm có tin cậy không và có đáp ứng chuẩn chất

lượng không. Với loại công việc này, người kĩ sư SQA phải là

người có kinh nghiệm nhất trong tổ chức. Họ phải làm việc như

người phát triển phần mềm trong nhiều năm và đi lên người

lãnh đạo kĩ thuật hay kiến trúc sư và thực hiện công việc này

trong nhiều năm trước khi trở thành kĩ sư SQA.

211

Cuốn “Sổ tay của Đảm bảo chất lượng phần mềm,” định

nghĩa SQA là: "Tập các hoạt động có hệ thống cung cấp bằng

chứng về khả năng của qui trình phần mềm tạo ra sản phẩm

phần mềm khớp với việc sử dụng. Do đó hội tụ của SQA là

giám sát liên tục trong toàn thể vòng đời phát triển phần mềm

để đảm bảo chất lượng của sản phẩm được chuyển giao. Điều

này yêu cầu giám sát cả qui trình và sản phẩm. Trong đảm bảo

qui trình, SQA cung cấp việc quản lí với phản hồi khách quan

liên quan tới tuân thủ các kế hoạch, thủ tục, chuẩn và phân tích

đã được chấp thuận. Các hoạt động đảm bảo sản phẩm hội tụ

vào mức độ thay đổi của chất lượng sản phẩm bên trong từng

pha của vòng đời, như yêu cầu, thiết kế, viết mã và kế hoạch

kiểm thử. Mục tiêu là nhận diện và khử bỏ khiếm khuyết trong

toàn bộ vòng đời sớm nhất có thể được, do vậy giảm chi phí

kiểm thử và bảo trì.

Viện các kĩ sư điện và điện tử (IEEE) định nghĩa chất

lượng là "mức độ mà hệ thống, cấu phần, hay qui trình đáp ứng

cho các yêu cầu xác định, và nhu cầu hay mong đợi của khách

hàng hay người dùng." Trong khi định nghĩa này dường như rõ

ràng và không mơ hồ, nhiều người quản lí phần mềm vẫn phàn

nàn rằng chất lượng là "khó định nghĩa, không thể đo được,

khó nhận ra” và do đó bỏ qua nó. Sau đây là định nghĩa chi tiết

khác về chất lượng phần mềm như được định nghĩa trong “Sổ

tay của Đảm bảo chất lượng phần mềm” chuẩn.

Tính đúng đắn: mức độ mà dự án hoàn thành các đặc tả của

nó.

Tính hiệu quả: dùng tài nguyên trong thực hiện và lưu giữ.

Tính linh hoạt: dễ làm thay đổi được yêu cầu do thay đổi

trong môi trường vận hành.

Tính toàn vẹn: bảo vệ dự án khỏi truy nhập không được

phép.

212

Tính liên tác: nỗ lực được yêu cầu để tích hợp hệ thống vào

hệ thống khác.

Tính bảo trì: nỗ lực được yêu cầu để định vị và sửa lỗi

trong dự án trong môi trường vận hành của nó.

Tính khả chuyển: nỗ lực được yêu cầu để truyền dự án từ

môi trường này sang môi trường khác.

Tính tin cậy: khả năng không hỏng.

Tính tái dụng: dễ dùng lại phần mềm trong hoàn cảnh khác.

Tính kiểm thử được: dễ dàng kiểm thử dự án để đảm bảo

rằng nó không lỗi và đáp ứng đặc tả.

Tính khả dụng: dễ dùng phần mềm.

Tất nhiên, trong một thế giới hoàn hảo tất cả những tiêu

chí này sẽ được đáp ứng, nhưng trong thực tế việc bù trừ là một

phần của mọi dự án phát triển. Thường phần mềm hiệu quả

nhất lại không khả chuyển, vì tính khả chuyển sẽ yêu cầu mã

phụ thêm, làm giảm tính hiệu quả. Tính khả dụng là chủ quan

và thay đổi tuỳ theo kinh nghiệm của người dùng. Khi dùng

các tiêu chí này để xác định mục tiêu đảm bảo của hệ thống

phần mềm, mục đích và việc dùng hệ thống phải được tính tới.

Trong thế giới thực của phát triển phần mềm, tiêu chí về chất

lượng được nhận diện và áp dụng cho mức độ khác biệt xem

như kết quả của các quyết định bù trừ.

Với toàn cầu hoá, khi nhiều công ti làm kinh doanh qua

các biên giới quốc gia, yêu cầu về chất lượng sản phẩm đang

trở nên quan trọng hơn. Thực tế đã chứng minh rằng việc có

SQA là đảm bảo rằng có kỉ luật và kiểm soát trong qui trình

phát triển phần mềm thông qua đánh giá độc lập do đó SQA sẽ

xác định liệu một sản phẩm sẽ được chấp nhận ở chỗ nào đó

hay không. Có hai mô hình phổ biến để kiểm điểm và đảm bảo

chất lượng phần mềm: ISO 9000 và CMMI. Tổ chức tiêu chuẩn

quốc tế (ISO 9000) cung cấp một cách để thu được việc uỷ

nhiệm bên ngoài cho hệ thống quản lí chất lượng. Nhiều công

213

ti đã dùng ứng dụng của ISO cho phần mềm, nhưng vấn đề là ở

chỗ nó hội tụ phần lớn vào thủ tục thay vì qui trình. Mô hình

kia là Tích hợp mô hình trưởng thành năng lực (CMMI) của

Viện kĩ sư phần mềm hội tụ trên cơ sở rằng chất lượng của sản

phẩm phần mềm chủ yếu được xác định bởi chất lượng của qui

trình phát triển và bảo trì phần mềm được dùng để xây dựng

nó.

Đảm bảo chất lượng là mấu chốt cho mọi doanh nghiệp

tương lai. Có SQA có kinh nghiệm là bản chất cho doanh

nghiệp nhưng ngay cả ngày nay, nhiều công ti phần mềm hiếm

khi đầu tư đủ ngân quĩ để thực hiện công việc SQA. Một số

người tin họ có thể tránh được nó nhiều nhất có thể được. Thái

độ “cắt giảm chi phí” và có sản phẩm chất lượng kém là không

thể chấp nhận được trong thế giới cạnh tranh cao. Nhiều công ti

sẽ KHÔNG sống sót lâu được vì nhiều khách hàng đang đòi

hỏi sản phẩm chất lượng tốt hơn với an toàn và tin cậy tốt nhất.

Kiểm điểm phần mềm

Mọi người phát triển phần mềm đều muốn dự án của họ

được đúng thời gian, trong ngân sách và có chất lượng cao.

Vậy mà nhiều dự án tiếp tục bị chậm, chi phí cao, chất lượng

thấp, với ít chức năng hơn được yêu cầu. Có nhiều lí do nhưng

hiển nhiên nhất là số lượng lỗi cao cần phải được loại bỏ. Lỗi

được tạo ra trong toàn thể vòng đời dự án nhưng thường được

tìm thấy khi kiểm thử. Vào lúc này, dự án gần hoàn thành cho

nên người phát triển vội vàng sửa chúng nhanh chóng nhất có

thể được. Vấn đề là khi bạn sửa lỗi vội vàng, bạn có thể chèn

thêm lỗi khác điều đòi hỏi thêm kiểm thử. Nhiều kiểm thử làm

cho dự án chậm và tốn thêm.

214

Theo nghiên cứu của Ts. Barry Boehm tại đại học Nam

California (USC) chi phí để sửa lỗi là quãng 65% tổng chi phí

dự án. Do đó, để cải tiến chất lượng và chi phí của dự án phần

mềm, người quản lí phải giải quyết vấn đề lỗi. Cách tốt nhất để

loại bỏ lỗi là dùng kiểm điểm phần mềm hay kĩ thuật giám định

sớm trong vòng đời. Ts. Barry Boehm thấy rằng về trung bình,

tốn $1 để loại bỏ lỗi ở cuối pha yêu cầu, sẽ tốn $10 ở pha thiết

kế, $100 trong pha viết mã, $1000 trong pha kiểm thử, và trên

$10,000 khi người dùng tìm ra lỗi.

Theo Watt Humphrey thuộc Viện kĩ nghệ phần mềm

(SEI) tại Carnegie Mellon, người phát triển trung bình có thể

lập trình quãng 300 dòng mã một ngày nhưng tạo ra 100 lỗi cứ

mỗi 1000 dòng mã. Việc tìm và chữa yêu cầu xấp xỉ 4 tới 10

giờ cho mỗi lỗi cho nên với mỗi 8 giờ viết mã, có thể cần thêm

20 tới 30 giờ để kiểm thử, phát hiện và loại bỏ lỗi. Đó là lí do

tại sao nhiều dự án phần mềm bị chậm và tốn phí thêm.

Kiểm điểm phần mềm không mới nhưng không được

dùng thường xuyên như nó đáng phải vậy. Lí do là đơn giản:

Nhiều người phát triển không muốn người khác biết về lỗi của

họ, họ có xu hướng kiểm điểm công việc của mình bên trong

nhóm nhỏ các bạn bè rồi che giấu các lỗi để cho họ có thể sửa

chúng về sau. Tuy nhiên, dự án phần mềm bao giờ cũng bận

rộn với nhiều hoạt động cho nên người phát triển không có thời

gian để sửa các lỗi của họ. Đôi khi họ quên các lỗi cho nên các

lỗi cứ tiếp tục chuyển từ pha này sang pha khác cho tới thời

gian kiểm thử những người kiểm thử mới có thể tìm ra chúng.

Có những người quản lí dự án coi phát triển phần mềm là viết

mã và bất kì "hoạt động không viết mã' nào cũng đều là phí

thời gian. Họ tin kiểm thử là nơi mọi người nhận diện và sửa

lỗi cho nên họ không cổ vũ cho kiểm điểm phần mềm. Họ

không biết rằng sửa lỗi xuất hiện về sau làm tốn kém thêm và

mất thời gian thêm cho dự án, càng nhiều lỗi, càng tốn tiền loại

bỏ chúng.

215

Nếu người phát triển phạm sai lầm nhưng người kiểm thử

tìm được chúng về sau trong khi kiểm thử, người phát triển

không bao giờ biết tại sao và khi nào họ đã phạm phải những

sai lầm đó. Kiểm điểm phần mềm được thiết kế để tiến hành ở

cuối pha phát triển để cho người phát triển biết đích xác họ đã

làm gì. Chẳng hạn, kiểm điểm yêu cầu thường để trắc nghiệp

tính đầy đủ của nhu cầu của khách hàng; kiểm điểm kiến trúc

được dùng để kiểm nghiệm thuộc tính chất lượng liên kết với

hệ thống phần mềm; kiểm điểm thiết kế được dự định để chỉ ra

rằng thiết kế là đầy đủ tới mức kĩ lưỡng nào đó. Kiểm điểm mã

là để trắc nghiệm rằng chương trình tuân theo thiết kế logic và

không sai lầm viết mã nào bị phạm phải.

Kiểm điểm phần mềm điển hình bao gồm sáu bước:

1) Bước lập kế hoạch bao gồm nhận diện tài liệu cần

kiểm điểm, lựa chọn người kiểm điểm và thu xếp nơi

họp và thời gian họp,

2) Bước đào tạo bao gồm đào tạo tất cả những người

kiểm điểm và vai trò và trách nhiệm của họ.

3) Bước chuẩn bị bao gồm cho phép có thời gian cho

từng người kiểm điểm kiểm điểm lại tài liệu và nhận

diện lỗi tiềm năng.

4) Bước kiểm điểm bao gồm nơi họp để tổ tụ tập thảo

luận lỗi được tìm thấy. Mục đích của kiểm điểm là đi

tới thoả thuận về những lỗi đã được tìm ra nhưng

không sửa chúng trong khi kiểm điểm. Người lãnh

đạo kiểm điểm hướng dẫn hoạt động này và yêu cầu

người kiểm điểm, những người đã kiểm điểm tài liệu

này trong pha chuẩn bị, thảo luận về tài liệu này theo

cách hệ thống. Lỗi được tìm ra được ghi lại.

5) Bước sửa chữa bao gồm việc để thời gian cho tác giả

của tài liệu bị lỗi để sửa chúng và

216

6) Bước theo dõi nơi người quản lí dự án hay đảm bảo

chất lượng trắc nghiệm rằng mọi lỗi đã được sửa và

không lỗi phụ đã được đưa vào.

Bằng việc sửa lỗi ở cuối từng pha phát triển, người phát

triển học về những sai lầm của mình cho nên họ không phạm

phải chúng lần nữa. Bằng việc không cho phép lỗi truyền sang

pha sau, người quản lí dự án có thể được đảm bảo rằng họ

không phải sửa nhiều lỗi vào cuối dự án khi thời gian đang

căng thẳng. Bằng loại bỏ hầu hết lỗi sớm sủa, người kiểm thử

có thể hội tụ nhiều hơn vào các khía cạnh khác của sản phẩm

phần mềm như chức năng và thuộc tính chất lượng thay vì

nhận diện lỗi. Bằng hiểu ích lợi của kiểm điểm phần mềm để

cải tiến lịch biểu dự án, chi phí và chất lượng, người quản lí dự

án phải động viên nhiều cuộc kiểm điểm phần mềm và đạt tới

thành công hơn.

Kiểm thử chất lượng

Trong quá khứ khi phần mềm còn nhỏ, chỉ vài trăm dòng

mã, thì kiểm thử là tương đối dễ dàng. Là người phát triển phần

mềm, điều tôi đã làm là phải chắc rằng thuật toán đúng và phân

tích kết cấu chương trình để chắc chắn nó được biên dịch đúng.

Nếu tôi có lỗi, tôi sửa chúng rồi biên dịch lại cho nên kiểm thử

không thành vấn đề. Tuy nhiên, khi kích cỡ phần mềm trở nên

lớn hơn, tôi bắt đầu thấy rằng tôi bị nhiều lỗi sau khi đưa ra cho

khách hàng (một lỗi là stack bị tràn) cho nên tôi bắt đầu cẩn

thận hơn về kiểm thử. Tôi bắt đầu viết các trường hợp kiểm thử

để chắc chắn rằng chương trình chạy đúng và đáp ứng nhu cầu

với dữ liệu vào và dữ liệu ra (kiểm thử hộp đen). Cuối cùng,

nhiều chương trình tôi đã viết đã được tích hợp với các chương

trình khác cho nên là một tổ chúng tôi đã phân chia công việc

217

của mình thành các chức năng và tính năng tách bạch dựa trên

phương pháp phân tích cấu trúc nhưng chúng tôi vẫn làm việc

một cách độc lập, chỉ thảo luận với nhau khi cần. Từng người

vẫn làm kiểm thử riêng và chúng tôi tin tưởng rằng mọi thứ

phải làm việc theo cách chúng tôi nghĩ, nhưng đến cuối cùng

nó lại không làm việc tốt. Có quá nhiều lỗi trong sản phẩm cuối

cùng của chúng tôi cho nên người quản lí của tôi quyết định

thành lập nhóm kiểm thử bao gồm nhiều người lập trình mới

tuyển, người được trao cho việc kiểm tra lại phần mềm để chắc

chắn chúng làm việc được trước khi chúng được đưa ra. Là

người phát triển phần mềm, chúng tôi chỉ phải tập trung hầu

hết vào thiết kế và viết mã. Chúng tôi đã kiểm thử mã riêng của

mình và không lo nghĩ nhiều về phần còn lại của phần mềm

cuối cùng. Cho nên tổ của chúng tôi bao gồm hai nhóm, nhóm

người phát triển và nhóm kiểm thử và quan niệm này đã được

chấp nhận trong nhiều công ti phần mềm và nó vẫn là cách

thức nhiều công ti vận hành ngày nay.

Bây giờ nhìn lại sao nhiều năm, ngạc nhiên lớn nhất của

tôi là làm sao nhiều người vẫn tin rằng bạn có thể "kiểm thử

chất lượng” trong sản phẩm phần mềm. Ngày nay phần lớn các

phần mềm đều rất lớn và phức tạp, nhiều dự án của tôi có

khoảng 5 tới 20 triệu dòng lệnh và không thể nào kiểm thử hết

mọi thứ cho nên thay vì hội tụ vào kiểm thử, chúng tôi hội tụ

vào cách tiếp cận có kỉ luật để “xây dựng trong chất lượng” khi

chúng tôi làm việc. Điều này cũng là khác biệt chính giữa đào

tạo kĩ nghệ phần mềm và khoa học máy tính. Với kĩ nghệ phần

mềm, bạn phải hội tụ vào qui trình tạo ra sản phẩm và “xây

dựng chất lượng trong qui trình” cho nên sản phẩm cuối sẽ có

chất lượng. Tất nhiên, không ai hoàn hảo cho nên bạn phải dựa

vào người khác để hỗ trợ cho bạn và nhận diện sai lầm của bạn

để cho bạn có thể sửa nó. Do đó, kiểm điểm phần mềm, giám

định mã, lập trình cặp, suy nghĩ theo pha, và rút ra bài học

218

được áp dụng để đảm bảo rằng chúng ta sẽ có sản phẩm chất

lượng.

Khi sinh viên tới lớp của tôi tại CMU, nhiều người có

thái độ “Sao lại chú ý tới lỗi khi đằng nào chúng ta cũng có thể

sửa được nó” hay “Viết mã trước, sửa lỗi sau” cho nên tôi kể

cho họ một kịch bản: “Giả sử rằng bạn đang bay trong máy bay

và bạn nghe phi công nói rằng anh ta gặp lỗi phần mềm trong

hệ thống điều khiển và phải “khởi động lại” hệ thống. Khởi

động lại hệ thống sẽ mất bao nhiêu thời gian? Chỉ mười hay hai

mươi phút và điều đó có nghĩa là máy bay sẽ không có nguồn

trong thời gian đó và tất nhiên sẽ rơi” và tôi hỏi: “Bạn có thực

sự quan tâm tới lỗi phần mềm hay không?” Khi cả lớp cười to,

tôi nói thêm: “Tôi chắc chắn điều đó tuỳ thuộc vào quan điểm

của bạn, bạn có lẽ quan tâm nếu bạn đang ở trên máy bay và

không quan tâm nếu bạn đang ở trên mặt đất. Cho nên vấn đề

thực là liệu lỗi có vấn đề theo nghĩa lí thuyết không nhưng liệu

nó có là vấn đề cho bạn không. Để tôi cho bạn ví dụ khác, bạn

là người chủ của một công ti phần mềm và bạn có hàng trăm

người lập trình làm việc cho bạn. Nếu khách hàng thấy lỗi phần

mềm trong sản phẩm của bạn thì bạn phải sửa nó. Chi phí để

phát hiện, phục hồi, báo cáo, sửa chữa, phân phối lại và chi phí

cài đặt lại cho mọi lỗi trung bình sẽ là quãng $ 4000 cho từng

lỗi và có hàng trăm hay hàng nghìn lỗi cho sản phẩm bạn bán.

Bạn có thực sự quan tâm không? Bạn bán phần mềm đó được

bao nhiêu và bạn phải chi bao nhiêu tiền để sửa lỗi? Bất kể

nguyên nhân của chúng, chi phí lỗi đều rất đắt, nếu bạn phải trả

chi phí này, bạn sẽ thực sự quan tâm về lỗi. Câu hỏi của tôi là,

là người chủ công ti phần mềm, bạn vẫn thuê những người

không quan tâm về lỗi sao?

Theo nghiên cứu của giáo sư Watt Humphrey tại

Carnegie Mellon, người phát triển phần mềm có kinh nghiệm

đưa vào một lỗi cứ trong mỗi 10 dòng mã. Trong khi các con

số này thay đổi lớn từ người phát triển phần mềm này sang

219

người phát triển khác, và họ đưa vào mọi thứ lỗi, thậm chí cả

những lỗi được tìm thấy trong kiểm điểm hay bởi trình biên

dịch, vẫn có nhiều lỗi. Tuy nhiên, nhiều người phát triển phần

mềm tin rằng trình biên dịch sẽ tìm ra mọi lỗi. Không may có

nhiều lỗi gõ vào mà trình biên dịch lại không tìm ra. Chẳng

hạn, trong C, gõ “=“ thay cho “= =“ có thể tạo ra phép gán thay

vì phép so sánh. Mặc dầu trình biên dịch có thể tìm ra 90% lỗi

nhưng còn 10% kia thì sao? Nhiều người tin rằng 10% kia có

thể được thực hiện bằng kiểm thử. Tuy nhiên, nhiều chương

trình sẽ chạy ngay cả khi chúng có lỗi. Thực tế, chúng có thể

có nhiều lỗi và vẫn qua được nhiều kiểm thử. Ngay cả để tìm ra

số phần trăm lỗi lớn trong một chương trình, chúng ta vẫn phải

kiểm thử gần như tất cả các con đường và điều kiện logic. Và

để tìm ra tất cả các lỗi trong ngay cả chương trình nhỏ, chúng

ta sẽ phải cho chạy kiểm thử vét cạn mà có thể tốn kém và yêu

cầu nhiều nỗ lực.

Ngày nay hầu hết những người phát triển phần mềm dành

nhiều thời gian cố gắng làm cho phần mềm của họ làm việc rồi

dành nhiều thời gian hơn để chữa lỗi và các vấn đề được báo

cáo. Đây là vấn đề chính cho doanh nghiệp nhưng nhiều người

quản lí phần mềm không được huấn luyện để giải quyết điều

này. Họ chỉ hội tụ vào lịch biểu, cách chuyển giao bên trong

ngày tháng nào đó nhưng không biết nhiều về kinh doanh tài

chính. Tất nhiên người quản lí cấp cao biết nhưng họ quá bận

quản lí công ti và không chú ý tới dự án cho nên những người

cuối cùng thực sự quan tâm là khách hàng. Tất nhiên khách

hàng có chọn lựa và khi họ không thoả mãn với chất lượng, họ

làm kinh doanh với ai đó khác.

Tôi cũng thấy rằng hầu hết những người phát triển phần

mềm không được đào tạo trong việc nhận diện và sửa lỗi an

ninh. Lỗi an ninh là bất kì lỗi thiết kế nào cho phép các hắc

khách, kẻ phạm tội, hay kẻ khủng bố thu được quyền truy nhập

hay dùng hệ thống phần mềm. Vì nhiều trong số các lỗi này

220

không gây ra vấn đề chức năng, hay lỗi khi chạy, chúng sẽ qua

mọi kiểm thử chức năng nhưng phần mềm vẫn có những mong

manh an ninh tiềm năng mà có thể tạo ra vấn đề trong tương

lai.

Quan điểm của tôi là để đảm bảo chất lượng, chúng ta

phải xây dựng chất lượng trong cách chúng ta làm việc và rằng

lỗi là vấn đề nghiêm chỉnh yêu cầu sự chú ý lớn từ mọi người.

Cách tốt nhất để ngăn cản lỗi là đào tạo tốt hơn và đào tạo nên

bắt đầu sớm nhất có thể được trong mọi đại học và nên được

nhấn mạnh trong mọi lớp tính toán.

Kiểm thử chấp nhận của người dùng

Một người kiểm thử viết cho tôi: “Tại sao chúng tôi phải

tiến hành kiểm thử chấp nhận của người dùng (UAT) khi chúng

tôi đã kiểm thử phần mềm nhiều lần để chắc rằng nó không có

lỗi? Có cần UAT không?"

Đáp: Ngày nay khách hàng mong đợi các công ti phần

mềm chuyển giao phần mềm chất lượng với chi phí thấp nhất

và thời gian ngắn nhất để đáp ứng cho nhu cầu doanh nghiệp

của họ. Tuy nhiên nhiều công ti phần mềm chỉ hội tụ vào khía

cạnh chức năng qua vài phép kiểm thử như kiểm thử đơn vị,

kiểm thử tích hợp, kiểm thử hệ thống v.v. trong môi trường

phát triển của họ, ít để ý tới cách phần mềm sẽ làm việc trong

môi trường người dùng. Nhiều lần, phần mềm đáp ứng các yêu

cầu chức năng nhưng thất bại trong kiểm thử chấp nhận của

người dùng vì môi trường kiểm thử không tương hợp.

Kiểm thử chấp nhận của người dùng (UAT) giúp cho

người dùng đảm bảo với bản thân họ rằng phần mềm đáp ứng

nhu cầu của họ và vận hành tốt trong môi trường của họ. Nó

221

được thiết kế để tìm ra liệu phần mềm có đáp ứng cho tiêu chí

chấp nhận và có sẵn sàng cho sử dụng không. UAT nhận diện

phần mềm tuân thủ thế nào với các yêu cầu doanh nghiệp khi

nó vận hành trong môi trường doanh nghiệp thực.

UAT bao gồm sự tham gia từ người dùng và là khác với

kiểm thử hệ thống, điều được thực hiện bởi người phát triển và

người kiểm thử. Bởi vì người dùng đóng vai trò then chốt trong

UAT, điều quan trọng là xác định tiêu chí chấp nhận với người

dùng trong các pha sớm của vòng đời phần mềm. Người phân

tích doanh nghiệp hay kĩ sư yêu cầu, người có tri thức về qui

trình doanh nghiệp phải giúp đỡ trong thiết kế yêu cầu thích

hợp, điều tạo nên cơ sở cho người kiểm thử để tạo ra các

trường hợp kiểm thử. UAT nên được thực hiện trong môi

trường mô phỏng cho môi trường sản xuất hay được đặt vào

việc sử dụng thực trong thế giới của ứng dụng phần mềm.

Trong UAT phần lớn các lỗi kĩ thuật phải đã được sửa

xong rồi trong các qui trình kiểm thử đa dạng (kiểm thử đơn vị,

kiểm thử tích hợp, kiểm thử hệ thống) do người kiểm thử tiến

hành. Tính chức năng là khía cạnh dùng được của phần mềm

này là khía cạnh then chốt cần được kiểm thử kĩ lưỡng trong

UAT. Tổ kiểm thử phải phát triển các kịch bản kiểm thử cho

UAT. Bản kế hoạch UAT hiệu quả làm chi tiết ra các khu vực

then chốt phải được thiết kế và các trường hợp kiểm thử chấp

nhận của người dùng phải được chuẩn bị để kiểm thử phần

mềm. Bất kì lỗi nào được tìm thấy trong UAT đều phải được

giải quyết sớm nhất có thể được. Về căn bản UAT giúp cho dự

án để đảm bảo rằng phần mềm thực hiện các qui trình nghiệp

vụ được dự định, và đáp ứng các yêu cầu của người dùng trong

các môi trường đa dạng. Nó là kiểm thử cuối cùng trong vòng

đời phát triển phần mềm và cần thiết nhất để chứng minh rằng

phần mềm đáp ứng yêu cầu của khách hàng.

222

Trắc nghiệm và kiểm nghiệm

Tôi nhận được một email mà người gửi viết: “Khác biệt

giữa trắc nghiệm (Verification) và kiểm nghiệm (Validation)

(V&V) là gì và có bao nhiêu kĩ thuật V&V?"

Câu trả lời của tôi: Nhiều sinh viên lẫn lộn về thuật ngữ

trắc nghiệm và kiểm nghiệm bởi vì chúng thường được dùng

đổi lẫn cho nhau trong một số sách giáo khoa. Tuy nhiên, có

khác biệt về nghĩa của chúng. Theo Bảng từ chuẩn IEEE về

thuật ngữ kĩ nghệ phần mềm, trắc nghiệm được định nghĩa là

"Qui trình đánh giá hệ thống hay cấu phần để xác định liệu sản

phẩm của pha phát triển đã nêu có thoả mãn các điều kiện được

áp đặt lúc bắt đầu pha đó không." Kiểm nghiệm được định

nghĩa là "Qui trình đánh giá một hệ thống hay cấu phần trong

hay cuối qui trình phát triển để xác định liệu nó có thoả mãn

các yêu cầu đặc biệt không." Về căn bản, trắc nghiệm chứng tỏ

liệu cái ra của pha có tuân thủ theo cái vào của pha không, tuy

nhiên nó không phát hiện lỗi nếu cái vào là không đúng. Bởi vì

phụ thuộc một mình vào trắc nghiệm là KHÔNG đủ, cho nên

kiểm nghiệm là cần để kiểm tra các vấn đề với đặc tả yêu cầu

để chứng minh rằng hệ thống làm việc đúng tương ứng.

Có vài kĩ thuật trắc nghiệm nhưng phần lớn rơi vào hai

khu vực chính: Kiểm thử động và kiểm thử tĩnh.

Kiểm thử động bao gồm việc thực hiện hệ thống hay cấu

phần. Về căn bản, một số các trường hợp kiểm thử được chọn

ra, tại đó từng trường hợp kiểm thử đều có chứa dữ liệu kiểm

thử. Những trường hợp kiểm thử này được dùng để xác định

kết quả kiểm thử ra. Kiểm thử động có thể được phân chia

thêm thành ba loại - kiểm thử chức năng, kiểm thử cấu trúc, và

kiểm thử ngẫu nhiên.

Kiểm thử chức năng bao gồm nhận diện và kiểm thử tất

cả các chức năng của hệ thống như đã được xác định trong yêu

223

cầu. Dạng này của kiểm thử là ví dụ về kiểm thử hộp đen vì nó

không bao gồm tri thức về thực hiện hệ thống.

Kiểm thử cấu trúc bao gồm kiểm thử có tri thức đầy đủ

về thực hiện hệ thống (kiểm thử hộp trắng). Nó dùng thông tin

từ cấu trúc nội bộ của hệ thống để làm ra kiểm thử để kiểm vận

hành của từng cấu phần riêng lẻ. Kiểm thử chức năng và cấu

trúc cả hai đều chứa các trường hợp kiểm thử mà sẽ kiểm đặc

trưng đặc thù của hệ thống.

Kiểm thử ngẫu nhiên - Kiểm thử chọn tự do các trường

hợp kiểm thử trong tập mọi trường hợp kiểm thử có thể có.

Việc dùng cái vào được xác định ngẫu nhiên có thể phát hiện ra

lỗi không được các kĩ thuật kiểm thử hệ thống khác phát hiện

ra.

Kiểm thử tĩnh là kiểm thử không chứa việc thực hiện hệ

thống hay cấu phần. Một số có thể được thực hiện một cách thủ

công trong khi các kiểm thử khác được tự động hoá. Kiểm thử

tĩnh có thể được phân chia thêm thành các kĩ thuật phân tích

tính nhất quán và kĩ thuật đo tính chất chương trình.

Kĩ thuật về tính nhất quán - Các kĩ thuật được dùng để

đảm bảo tính chất chương trình như đúng cú pháp, tương ứng

đúng tham biến giữa các thủ thục, đúng định kiểu, và dịch đúng

yêu cầu và đặc tả.

Kĩ thuật đo - Kĩ thuật đo các tính chất như việc sinh lỗi,

tính hiểu được, và có cấu trúc tốt.

Có một vài kĩ thuật kiểm nghiệm như phương pháp hình

thức, cách tiêm lỗi (phần cứng và phần mềm), phân tích rủi ro

và phân tích phụ thuộc. Kiểm nghiệm thường xảy ra ở cuối chu

kì phát triển, và nhìn vào hệ thống đầy đủ để trắc nghiệm, hội

tụ vào các hệ con nhỏ hơn.

224

Phương pháp hình thức - Phương pháp hình thức dùng các

kĩ thuật toán học và logic để diễn đạt, nghiên cứu, và phân

tích đặc tả, thiết kế, tài liệu, và hành vi của cả phần cứng và

phần mềm.

Tiêm lỗi - Tiêm lỗi là việc kích hoạt có chủ định các lỗi

hoặc bởi phương tiện phần cứng hay phần mềm để quan sát

vận hành hệ thống trong điều kiện có lỗi.

Phân tích tính phụ thuộc - Phân tích tính phụ thuộc bao

gồm nhận diện những nguy cơ và rồi đề đạt giải pháp làm

giảm rủi ro của nguy cơ xuất hiện.

Phân tích rủi ro – qui trình nhận diện các hậu quả có thể

của từng nguy cơ và xác suất xuất hiện của chúng.

Thoả mãn của khách hàng

Tôi nhận được một email người gửi viết: “Công ti tôi yêu

cầu rằng dự án phần mềm phải đạt tới thoả mãn của khách

hàng. Tuy nhiên, khách hàng của tôi rất không có lí. Anh ta yêu

cầu điều không thể được như mọi thứ đều phải được làm với

chất lượng cao và chuyển giao đúng thời gian hay cái gì khác.

Làm sao chúng tôi có thể đạt tới điều này được? Tổ của chúng

tôi gồm hầu hết là người mới tốt nghiệp và đây là việc làm đầu

tiên của chúng tôi cho nên chúng tôi sợ hãi và bị lẫn lộn.

Chúng tôi không biết cách đạt tới sự thoả mãn của khách hàng.

Xin cho lời khuyên.”

Câu trả lời của tôi: Khách hàng của bạn KHÔNG yêu cầu

"điều không thể được" như bạn nghĩ đâu. Nếu bạn là khách

hàng, bạn muốn gì? Bạn không muốn sản phẩm phần mềm chất

lượng tốt đúng thời gian và với đủ mọi chức năng như yêu cầu

sao? KHÔNG phải là "không có lí" để yêu cầu điều gì đó như

225

vậy. Khi bạn bắt đầu dự án mới, điều rất quan trọng là hiểu

mong đợi của khách hàng bởi vì nếu bạn đáp ứng cho mong

đợi đó, bạn sẽ đạt tới thoả mãn của khách hàng. Điều khách

hàng muốn là được lắng nghe bởi vì họ có vấn đề nào đó phải

được giải quyết. Là tổ phát triển, bạn phải tự hỏi mình: Mình

đã nói chuyện với khách hàng và hiểu cái gì là nhu cầu của

khách hàng không? Mình đã trao đổi rõ ràng với khách hàng về

ngày tháng chuyển giao, và mọi chức năng sẽ được xây dựng

không? Khách hàng có đồng ý với đề nghị của chúng ta không?

Những vấn đề chính giữa khách hàng và tổ phát triển phần lớn

là trao đổi và mong đợi. Nhiều tổ dự án đã không dành thời

gian cho việc thảo luận với khách hàng để hiểu yêu cầu. Họ vội

vàng bắt đầu làm việc trên dự án với mà không thoả thuận rõ

ràng cho nên họ KHÔNG biết cách làm cho khách hàng hài

lòng. Khi mọi sự đi sai, họ bắt đầu trách khách hàng. Nếu họ

trao đổi rõ ràng về mục tiêu dự án, nếu họ hiểu nhu cầu khách

hàng là gì, nếu họ có thoả thuận về chất lượng, thời gian, chi

phí và chức năng thì khi họ hoàn thành thoả thuận khách hàng

phải được hài lòng.

Về căn bản, để đạt tới thoả mãn khách hàng, bạn phải hội

tụ vào cả sản phẩm và qui trình. Sản phẩm nói tới giải pháp, kết

quả, sản phẩm phần mềm. Khách hàng muốn nó làm việc đúng,

đáp ứng nhu cầu của họ, giải quyết vấn đề của họ và tất nhiên

làm nó có chất lượng. Nhưng một mình sản phẩm kĩ thuật có

thể không giữ được khách hàng hài lòng chừng nào bạn còn

chưa hội tụ vào qui trình. Qui trình nói tới cách khách hàng

cảm thấy họ đã được đối xử thế nào. Đây là khía cạnh "yếu tố

con người" và nó rất quan trọng. Đó là lí do tại sao bên cạnh kĩ

năng kĩ thuật, tổ phần mềm cũng phải có "kĩ năng mềm", khả

năng lắng nghe, trao đổi, thảo luận, thương lượng và xây dựng

mối quan hệ tốt hơn với khách hàng.

Thỉnh thoảng, chuyển giao giải pháp chất lượng tốt có thể

không hiệu quả bằng giải pháp chất lượng tốt đi kèm với sự

226

thân thiện và kính trọng. Nếu bạn biết cách đầu tư vào quan hệ,

bạn sẽ đi xa trong việc đạt tới sự hài lòng của khách hàng. Mọi

khách hàng sẽ đánh giá cao cách họ được đối xử. Nói cách

khác, việc nhấn mạnh vào khía cạnh "yếu tố con người" có thể

cho bạn cách tốt hơn trong việc cung cấp giải pháp kĩ thuật và

xin đừng quên ai trả tiền cho công việc của bạn.

Khi nào khách hàng phần mềm xây nhà

Một sinh viên chuyển cho tôi một bức thư khôi hài từ

"khách hàng" muốn xây nhà:

Thưa ông Kiến trúc sư:

Xin ông thiết kế ngôi nhà cho tôi. Tôi không chắc tôi cần

gì nhưng tôi muốn có nó sớm. Tôi muốn ông bắt đầu vào thiết

kế ngôi nhà của tôi sớm nhất có thể được. Yêu cầu của tôi là

đơn giản: Ngôi nhà phải có từ 2 tới 15 phòng ngủ vì tôi không

biết liệu chỉ bản thân tôi và vợ tôi sẽ sống ở đó hay có thể họ

hàng tôi cũng muốn chuyển tới. Xin chắc chắn cho bản kế

hoạch có nhiều phòng như thế. Nếu họ hàng tôi không chuyển

đến thì chúng tôi có thể xoá bỏ các phòng đó. Nếu nhiều người

muốn chuyển tới thì chúng tôi có thể thêm nhiều phòng ngủ khi

cần.

Tôi chưa chắc chắn về phong cách ngôi nhà. Tôi muốn có

"phong cách cổ điển" nhưng vợ tôi muốn "phong cách hiện

đại" cho nên xin ông kiến trúc sư là ngôi nhà có cả hai phong

cách, trong trường hợp chúng tôi đổi ý về sau. Tôi biết rằng mẹ

vợ tôi thích nhà "phong cách đồng quê" cho nên có thể là ông

kiến trúc cả cái đó nữa. Thỉnh thoảng mẹ vợ tôi có ảnh hưởng

227

tới vợ tôi. Nếu hai người trong họ ra quyết định cùng nhau thì

chúng tôi có thể bắt đầu xây dựng bất kì cái gì họ muốn.

Khi ông hoàn thành bản kế hoạch thiết kế ngôi nhà, xin

gửi nó cho tôi để tôi có thể có quyết định cuối cùng về điều tôi

muốn. Cũng vậy, đem cho tôi chi phí về từng phòng, từng tầng

để cho tôi có thể chọn lựa điều tôi muốn. Vào lúc này, nhà có

thể một tầng hoặc năm tầng vì tôi còn chưa định ý trong trí của

tôi. Tuy nhiên, tôi không muốn chi nhiều tiền cho ngôi nhà vì

nó quá đắt thì tôi có thể không muốn xây nó. Tôi đã có một

ngôi nhà mà tôi đang sống bây giờ. Nếu ngôi nhà mới không

tốt hơn ngôi nhà hiện thời của tôi thì tôi sẽ không muốn nó đâu.

Là kiến trúc sư, ông phải chắc rằng ngôi nhà mới là có chất

lượng cao hơn ngôi nhà cũ của tôi.

Khi ông thiết kế ngôi nhà của tôi, xin hiểu cho rằng tôi

muốn giữ cho chi phí thấp nhất có thể được. Điều đó nghĩa là

ông phải đưa vào mọi chi phí vào từ gạch, gỗ, xi măng, và thép

thanh để tôi có thể kiểm được chúng. Phải được chuẩn bị để

giải thích mọi chi phí một cách chi tiết. Xin chắc cho rằng mọi

chi phí và lao động đều được bao hàm trong bản kế hoạch của

ngôi nhà vì tôi không muốn trả thêm tiền.

Để đảm bảo rằng ông xây ngôi nhà đúng cho toàn bộ gia

đình tôi, phải chắc rằng ông liên hệ cả với họ hàng tôi nữa.

Điều này bao gồm cả mẹ vợ nữa vì bà ấy thường có linh cảmc

mạnh về cách chúng tôi sống. Phải chắc rằng ông tuân theo các

yêu cầu của tôi và ra quyết định đúng vì tôi có thể thay đổi thiết

kế mà ông đã làm vì tôi là khách hàng.

Vào lúc này, xin đừng làm tôi bận rộn về chi tiết vì tôi

bận lắm. Việc của ông là kiến trúc ngôi nhà và nếu tôi thích nó,

ông có thể xây nó. Tôi vẫn không chắc về việc chọn mầu sắc

của ngôi nhà. Tôi biết rằng vợ tôi thích mầu vàng nhưng tôi ưa

mầu lam. Chúng ta có thể thảo luận về mầu sắc sau khi ông

hoàn thành bản kế hoạch. Ưu tiên của ông là thiết kế đặc tả chi

228

tiết. Một khi tôi chấp thuận những kế hoạch này, tôi sẽ mong

đợi ngôi nhà được xây dựng trong vòng một tuần vì tôi muốn

có bữa tiệc lớn vào cuối tháng và tôi muốn làm nó trong ngôi

nhà mới.

Khi ông thiết kế ngôi nhà này, ông nên biết rằng về sau

tôi có thể muốn bán nó cho ai đó khác. Do đó ngôi nhà nên có

sức hấp dẫn cho nhiều người mua tiềm năng. Xin chắc cho rằng

những người có thể mua ngôi nhà này cũng thích nó nữa. Tôi

không muốn nhà của tôi kém hấp dẫn hơn các ngôi nhà khác

trên cùng phố. Xin nhìn vào vài ngôi nhà hàng xóm của tôi và

chắc chắn rằng nhà tôi sẽ tốt hơn chúng.

Xin thiết kế bản kế hoạch kiến trúc sớm nhất có thể được

nhưng đừng dành quá nhiều thời gian cho nó vì tôi không chắc

liệu tôi có thực sự muốn xây ngôi nhà không. Nhân tiện, vợ tôi

có thể bất đồng với nhiều chỉ dẫn tôi đã nêu cho ông trong thư

này. Trách nhiệm của ông như người kiến trúc sư là giải quyết

những khác biệt này. Tôi đã thử trong quá khứ để thuyết phục

cô ấy nhưng không thành công mấy. Nếu ông không thể đảm

nhiệm được trách nhiệm này, tôi sẽ phải tìm kiến trúc sư khác.

“Khách hàng phần mềm”

Nói chuyện với khách hàng

Có niềm tin chung trong những người phát triển phần

mềm rằng họ phải viết mã sớm nhất có thể được vì không có

đủ thời gian cho các hoạt động khác. Đó là lí do tại sao nhiều

người bắt đầu viết mã ngay khi họ nhận được đặc tả yêu cầu

mà không dành thời gian để hiểu nhu cầu của khách hàng.

Không ai hỏi khách hàng về mong đợi của họ hay nhu cầu của

họ. Phần lớn những người phát triển đều bỏ qua pha kiến trúc;

229

dành ít thời gian trong thiết kế, chỉ vẽ vài biểu đồ như biểu đồ

luồng dữ liệu rồi nhảy vào viết mã. Nếu họ không hiểu cái gì

đó, họ sẽ đoán cái gì được cần và vội vàng làm cho dự án được

thực hiện để đáp ứng lịch biểu.

Kết quả thường là sản phẩm phần mềm không làm việc

như mong đợi và họ phải làm lại để có được điều khách hàng

muốn. Tình huống này làm tốn kém cho công ti về thời gian,

nỗ lực và nhiều tiền. Ngày nay ít đại học dạy môn yêu cầu, và

cho dù họ dạy, ít người phát triển sẽ theo nó. Lí do trong những

người phát triển là nói chuyện với khách hàng mất thời gian và

họ không có thời gian. Một người phát triển bảo tôi: “Khó mà

hiểu được khách hàng muốn gì vì họ đổi ý thường xuyên.” Một

người quản lí dự án giải thích: “Chúng tôi không thể nói

chuyện được với khách hàng; họ sẽ đòi nhiều thứ hơn và làm

phí thời gian của chúng tôi.” Khi tôi hỏi: “Điều gì xảy ra nếu

đặc tả yêu cầu không rõ ràng? Làm sao bạn biết phải làm gì

nếu bạn không muốn hỏi?" Câu trả lời thông thường là:

“Chúng tôi đoán họ muốn gì. Nếu chúng tôi giỏi đoán, chúng

tôi sẽ ổn nhưng nếu không thì chúng tôi phải sửa nó về sau.”

Tất nhiên, phần lớn thời gian họ sẽ tạo ra cái gì đó mà

khách hàng không muốn và điều đó nghĩa là nhiều việc làm lại

hơn, tốn kém hơn cho công ti. Tôi có thể hiểu tại sao những

người phát triển ngần ngại nói chuyện với khách hàng; phần

lớn không được đào tạo và không biết hỏi cái gì cho nên họ

nghĩ khách hàng sẽ hỏi nhiều hơn và không bao giờ được thoả

mãn. Nhưng tôi không thể hiểu được tại sao người quản lí

không nói chuyện với khách hàng nếu dự án tiếp tục có tỉ lệ

phải làm lại cao? Chừng nào chúng ta chưa thiết lập được đối

thoại tốt giữa người phát triển và khách hàng, việc phát triển

phần mềm chỉ là công việc đoán mò và dự án tốn kém.

Có nhu cầu khẩn thiết để dạy môn kĩ nghệ yêu cầu trong

chương trình đại học để cho sinh viên có thể học cách thảo luận

230

yêu cầu với khách hàng, xác định nhu cầu của họ, lập ưu tiên

và giảm vấn đề làm lại. Sinh viên nên học việc đưa ra tăng dần

mỗi lần thêm chức chức năng qua thời gian. Sinh viên nên học

nói chuyện với khách hàng bằng cách hỏi câu hỏi về chức năng

và cách khách hàng sẽ dùng sản phẩm của họ. Một khi người

phát triển bắt đầu nói với khách hàng, họ sẽ học được nhiều

điều về cách khách hàng làm công việc của họ và điều họ thực

sự cần. Khách hàng có thể giúp đỡ giải thích và làm sáng tỏ

chức năng được viết trong đặc tả v.v. Khi cả hai bên tham gia

vào thảo luận về phải mất bao lâu để phát triển dự án, họ có thể

trao đổi ý tưởng, phát triển các giải pháp tốt hơn và đồng ý về

lịch biểu tốt hơn cho dự án.

Một khảo cứu về dự án phần mềm

Có một khảo cứu công nghiệp được công bố tháng trước

về tại sao nhiều dự án phần mềm thất bại ở các nước đang phát

triển. Khảo cứu này liệt kê ra mười yếu tố thất bại chung nhất:

1) Lịch biểu dự án không hiện thực;

2) Ước lượng không chính xác về công nhân được cần;

3) Yêu cầu được xác định kém;

4) Báo cáo không chính xác về tình trạng dự án;

5) Rủi ro không được quản lí;

6) Trao đổi kém giữa khách hàng, người phát triển và người

dùng;

7) Kĩ năng làm việc tổ bị giới hạn trong các công nhân;

8) Thiếu qui trình được xác định;

9) Thiếu cách đo và độ đo;

10) Kĩ năng hỗ trợ dự án kém như, quản lí cấu hình và đảm

bảo chất lượng.

231

Từ danh sách này, sáu yếu tố thất bại then chốt thuộc vào

kĩ năng của cấp quản lí dự án. (Lập kế hoạch, ước lượng, giám

sát, báo cáo, và quản lí rủi ro). Khảo cứu này đã phỏng vấn trên

tám trăm người quản lí dự án phần mềm ở bẩy nước và thấy

rằng 78% đã không hiểu rõ ràng mục đích doanh nghiệp. 96%

đã không có viễn kiến cho dự án; 87% đã không hiểu lí do của

dự án và 78% đã không biết cách đối phó với thay đổi hay rủi

ro. Mối bận tâm then chốt duy nhất trong những người quản lí

này là chuyển giao phần mềm tương với ngân quĩ được phân

phối trong phát biểu dự án. Khảo cứu này kết luận rằng hầu hết

những người quản lí dự án chỉ theo dõi chi tiêu của họ và quan

tâm nhiều tới vấn đề tiền bạc hơn là vấn đề kĩ thuật điều có lẽ

bắt nguồn từ đào tạo kế toán hơn là đào tạo quản lí dự án.

Tất cả những yếu tố thất bại này đều chỉ ra một nhu cầu

khẩn thiết để cải tiến kĩ năng quản lí dự án phần mềm.

Khảo cứu này cũng nâng một cách nghiêm chỉnh mối

quan tâm tới rủi ro của việc khoán ngoài các dự án phần mềm

vì gần đây nhiều công ti đang khoán ngoài toàn bộ dự án cho

các nước đang phát triển thay vì chỉ phần viết mã và kiểm thử.

Nó nhận diện các điểm yếu then chốt của đào tạo hiện tại ở các

nước này vì hội tụ quá hẹp vào lập trình và công cụ hỗ trợ

nhưng thiếu các mức cao như cách nhìn qui trình phần mềm và

kiến trúc hệ thống. Nó thấy rằng đa số tổ dự án đã không tuân

theo qui trình nào khi phát triển phần mềm. Họ đã tạo ra nhiều

lỗi điều làm cho việc tích hợp thành khó và kéo dài thời gian

kiểm thử, điều cũng cần thời gian kéo dài để hoàn thành dự án.

Khảo cứu này thấy rằng đào tạo hàn lâm hiện thời có giá

trị cho thành đạt cá nhân mà làm nảy sinh các thành viên tổ

không hợp tác được với nhau hay làm việc như một tổ. Mọi

người đều muốn là "anh hùng" điều làm tăng rủi ro cho dự án.

Nó cũng nhận diện rằng việc thay người trong các thành viên tổ

là vấn đề nghiêm trọng trong dự án (Thay thành viên tổ ở Ấn

232

Độ là 32% và ở Trung Quốc là 28%). Khảo cứu này gợi ý rằng

các công ti phần mềm phải cải tiến kĩ năng làm việc tổ và làm

mạnh kĩ năng mềm của sinh viên để cải tiến năng lực toàn thể

của lực lượng lao động của họ.

233

5. Phương pháp quản lí Agile

Agile

Câu hỏi: Ý kiến của thầy về lập trình Agile (mau lẹ) là

gì? Tôi có một tổ muốn thực hiện nó, nhưng họ gần như là theo

cách tiếp cận "viết mã & cho chạy". Thầy có biết tôi có thể tìm

được ở đâu trong ngành công nghiệp này ví dụ tốt về việc dùng

nó thành công không, cũng như kiểu sản phẩm nào là phù hợp

nhất với nó?

Trả lời: Agile là phương pháp luận thiết kế phần lớn dành

cho nhóm ứng dụng Web, những người lập trình trong JAVA

nhưng đã trở thành luồng chính về sau do sự bùng nổ của

Internet và Blog. Đây là ý kiến cá nhân của tôi về lập trình

Agile:

Phương pháp này là tuyệt hảo cho dự án nhỏ từ hai tới

tám người làm việc cùng nhau và thường xuyên trao đổi với

nhau. Khía cạnh then chốt của lập trình Agile là từng người

làm nhiều điều từ giao tiếp với khách hàng, thu nhận yêu cầu,

làm kiến trúc cho tới thiết kế, viết mã, và đưa ra, điều thực sự

là kĩ năng của Kĩ sư phần mềm chứ KHÔNG PHẢI là người

lập trình máy tính (người chỉ tập trung chủ yếu vào lập trình).

Phương pháp Agile có thể không có tác dụng tốt trong môi

234

trường yêu cầu dự án lớn hay nỗ lực tích hợp lớn, điển hình có

sự tham gia của hàng trăm người làm việc cùng nhau.

Vì hội tụ của phương pháp Agile là vào các dự án nhỏ và

trong khuôn khổ thời gian ngắn, phương pháp này yêu cầu có

những cá nhân tài năng, người sẵn lòng và có khả năng thuộc

vào loại những nhà tổng quát, có thể làm việc xuyên qua miền

rộng các bước của vòng đời truyền thống. Agile yêu cầu các cá

nhân đa kĩ năng, người có động cơ cá nhân, biết nghiên cứu, có

tính phân tích, sáng tạo, và có các kĩ năng liên con người rất

cao để hiểu vấn đề của khách hàng. Họ cũng phải là những

thành viên tổ rất có kỉ luật và là những kĩ sư phần mềm có kĩ

năng để đưa ra sản phẩm trong khoảng thời gian được phép.

(Đây là điều Kĩ nghệ phần mềm tất cả là gì, hiểu toàn bộ qui

trình phát triển và có khả năng làm việc trong tổ. Tuy nhiên,

nhiều lớp học về AGILE đã không dạy điều này mà chỉ tập

trung vào khía cạnh lập trình, điều tôi cho là sai lầm).

Tôi đã nghe nói về những trường hợp người quản lí ra

lệnh cho mọi người dùng phương pháp Agile trong các dự án

nghiệp vụ phức tạp. Vấn để tổng quát của đổi qui mô và dịch

chuyển bị bỏ lại cho người phần mềm làm theo bất kì cái gì họ

thấy khớp. Đó không phải là tình huống tốt bất kể việc phương

pháp luận tốt thế nào. Thiếu hiểu biết về dùng phương pháp

nào áp dụng vào môi trường nào thực sự tạo cho phương pháp

này thành cái tên xấu.

Cũng vậy, như với các phương pháp luận trong quá khứ,

nếu phương pháp Agile được quảng cáo đủ để bắt đầu thuyết

phục các nhà quản lí rằng nó có thể làm cho các dự án được

hoàn thành nhanh hơn và rẻ hơn thì nhóm doanh nghiệp tư vấn

về Agile tất yếu sẽ nhảy xổ vào hỗ trợ cho mối quan tâm đó.

Điều này có lẽ là không tránh khỏi nhưng nó quả có tác động

tới việc tạo ra cái búa lớn hơn - ngành công nghiệp con tư vấn

235

về Agile - cái sẽ đi tìm những cái đinh sinh lời về tài chính để

đóng.

Tôi tin rằng Agile là một trong những kĩ thuật tốt được

tìm ra, nó được thiết kế để làm việc trong môi trường rất nhỏ,

không then chốt (trang Web, trạm web) nơi mọi sự phải xảy ra

rất nhanh chóng và nếu mọi thứ không làm việc thì bạn bắt đầu

lại toàn bộ vì viết mã là nhanh và rẻ. Tuy nhiên, tôi nghĩ chúng

ta nên rất cẩn thận về Agile trong các dự án lớn nơi kỉ luật là

quan trọng và tài liệu là then chốt (Hãy hình dung hệ thống tài

chính và kế toán mà không có tài liệu). Sau khi kiểm điểm kĩ

càng nhiều dự án, lớn và nhỏ trong công nghiệp, tôi không

được thuyết phục rằng Agile có miền kinh nghiệm được cần tới

để làm cho việc sử dụng nó có hiệu quả trong mọi môi trường.

Nói riêng tôi không nghĩ nó có thể được dùng trong các dự án

lớn và trong môi trường nghiệp vụ điển hình.

Dự án Agile

Thay đổi yêu cầu là một trong những vấn đề chính trong

hầu hết các dự án phần mềm. Để giảm thiểu vấn đề này, tổ phát

triển phần mềm phải hội tụ vào làm việc với người dùng để

phát triển yêu cầu rõ ràng và chính xác. Tuy nhiên, khi người

dùng không biết họ muốn gì, hay thường đổi ý thì tổ phát triển

có thể chấp thuận cách tiếp cận gia tăng bằng việc xác định

điều người dùng có thể giải thích được vào lúc đó rồi ưu tiên

hoá chúng thành nhiều bản đưa ra với bản họ đã biết được thực

hiện trước nhất.

Cách tiếp cận này được gọi là “Cách tiếp cận Agile” bao

gồm nhiều cách phát triển phần mềm. Một trong những cách

phổ biến nhất là “Scrum”, chia hoạt động phát triển thành

nhiều nỗ lực nhỏ, từng nỗ lực kéo dài từ 2 tới 4 tuần có tên là

236

"Sprint- Nước rút". Với từng nước rút, nhu cầu của người dùng

được ưu tiên hoá thành "Tồn đọng nước rút- Sprint backlog"

(Yêu cầu đối với một nước rút đặc biệt) nơi tổ có thể tập trung

vào làm việc về nhu cầu của người dùng mà không phải lo lắng

về các yêu cầu khác. Bằng việc xây dựng tăng dần phần mềm

tương ứng theo ưu tiên của người dùng, tổ tiếp tục chuyển giao

phần mềm làm việc thoả mãn cho người dùng thay vì chuyển

giao mọi thứ một lần như với vòng đời thác đổ. Bằng việc đưa

ra một mảnh phần mềm mỗi lúc, người dùng không phải chờ

đợi lâu mà có thể dùng vài tính năng mỗi vài tuần và có thể đo

được tiến bộ của tổ tương ứng. Với từng việc đưa ra, tổ cũng

suy nghĩ về điều gì có tác dụng và điều gì không và tiếp tục cải

tiến cách họ làm việc cùng nhau.

Trước khi dự án mau lẹ bắt đầu, cả tổ phát triển và người

dùng phải đồng ý về cách qui trình này sẽ được thực hiện. Vai

trò, trách nhiệm và đảm nhiệm phải được xác định và phân

công để đảm bảo rằng người quản lí, người dùng và tổ dự án

hiểu họ được giả định làm gì. Theo cách tiếp cận mau lẹ, trao

đổi là yếu tố quan trọng nhất cho nên người dùng phải phân

công ai đó làm việc cùng tổ dự án để phối hợp các yêu cầu và

ưu tiên trên cơ sở hàng ngày. Đại diện này làm việc cùng

“Thầy Scrum” của tổ dự án để xácđịnh "tồn đọng" cho từng

nước rút Sprint. Đại diện của người dùng cũng phải có khả

năng trả lời nhanh chóng mọi câu hỏi đặt ra cho tổ và lập ưu

tiên mới, nếu cần. Nếu với bất kì lí do nào, người dùng bận rộn

và không thể tham gia được vào giao tiếp hàng ngày với tổ,

tính mau lẹ sẽ KHÔNG có tác dụng.

Thầy Scrum chịu trách nhiệm cho mọi dự án trong việc

phối hợp các hoạt động với người dùng, đảm bảo rằng mọi

người đều tuân theo qui trình agile tương ứng với vai trò, trách

nhiệm của họ và thúc đẩy công việc tổ trong các thành viên tổ.

Như đã đăng trước đây trong blog của tôi, cách tiếp cận Agile

có tác dụng tốt cho các dự án nhỏ (4 tới 10 người) và mọi

237

người trong tổ đều phải nhận được việc đào tạo agile để cho họ

có thể làm việc tương ứng. Tuy nhiên, xung đột giữa mọi người

trong tổ có xảy ra. Chính công việc của Thầy Scrum là giải

quyết những vấn đề này nhanh chóng và hiệu quả. Thầy Scrum

phải có kĩ năng giải quyết xung đột tổ bởi vì với cách làm mau

lẹ, thời gian là cốt yếu (2 tới 4 tuần cho từng nước rút), cho dù

với một người "khó làm việc", toàn tổ cũng có thể bị tác động.

Thầy Scrum cũng làm việc để loại bỏ bất kì chướng ngại nào

được báo cáo trong cuộc họp hàng ngày và bảo vệ tổ khỏi bất

kì việc ngắt quãng nào từ bên ngoài bởi vì công việc mau lẹ là

rất dồn dập.

Có vài công cụ thương mại sẵn có trên thị trường cho dự

án mau lẹ nhưng có những phương án như phần mềm nguồn

mở nữa. Tôi thích dùng ba công cụ "tự do" này:

Wiki: Công cụ này có thể được cả người dùng và tổ dự án

dùng để trao đổi và cộng tác trên mọi vấn đề có liên quan

tới dự án.

Geeklog: Dùng công cụ này các thành viên dự án có thể

thảo luận vấn đề lẫn với nhau. Công cụ này sẽ có giá trị cho

các thành viên dự án để thảo luận về các vấn đề có liên

quan tới các dự án khác nhau.

CVS: Nó là công cụ cấu hình nguồn mở để kiểm soát phiên

bản đưa ra.

Bugzilla: Tổ dự án có thể dùng công cụ này để dõi vết

khiếm khuyết và lấy các báo cáo đa dạng về khiếm khuyết.

Một số sự kiện về cách tiếp cận Agile

Một sinh viên hỏi tôi: “Nếu Agile là cách tiếp cận tốt để

phát triển phần mềm thì tại sao chúng ta phải học cách tiếp cận

khác?”

238

Câu trả lời của tôi: Agile là cách tiếp cận tốt tới phát triển

phần mềm, đặc biệt khi dự án là nhỏ và yêu cầu KHÔNG được

hiểu rõ. Tuy nhiên, Agile KHÔNG là giải pháp cho mọi thứ.

Có những phương pháp khác nhau cho các kiểu dự án khác

nhau. Nhân tiện, Agile chỉ có tác dụng nếu những điều kiện

nhất định tồn tại.

Thứ nhất, Agile yêu cầu mọi thành viên tổ nhận được đào

tạo về cách tiếp cận này (Scrum, lập trình cực đoan, Crystal

v.v.). Không có đào tạo đúng, Agile sẽ KHÔNG có tác dụng.

Tôi đã thấy nhiều sinh viên hiểu lầm Agile như cách thức

không kỉ luật để làm bất kì cái gì họ muốn như “viết mã trước,

hỏi câu hỏi sau”. Điều này là KHÔNG chấp nhận được bởi vì

Agile là về việc làm cho công việc được thực hiện tương ứng,

điều có nghĩa là các thành viên tổ phải tuân theo những qui tắc

và qui trình nào đó. Chẳng hạn, với Scrum, dự án được chia

thành các chu kì nhỏ được gọi là “Sprint - nước rút” (quãng 2

tới 4 tuần) nơi tổ hội tụ vào những chức năng nào đó mà họ

phải phát triển và kiểm thử bên trong thời gian xác định

đó. Qui trình lặp, tăng dần được làm tài liệu tốt và phải được

tuân theo. Có vài bài báo nói rằng với Agile bạn KHÔNG cần

tuân theo qui trình. Điều đó là SAI. Sự kiện là bạn bao giờ

cũng tuân theo "qui trình được xác định" dù bạn dùng Scrum,

Crystal hay lập trình cực đoan. Có khác biệt giữa Agile và

vòng đời thác đổ truyền thống, nơi phương pháp truyền thống

yêu cầu nhiều tài liệu nhưng với Agile, những tài liệu này đang

bị rút gọn tới tối thiểu. Tuy nhiên, điều đó KHÔNG có nghĩa là

Agile KHÔNG có tài liệu. Bởi vì dự án Agile là nhỏ chạy từ 3

tới 8 người, những người phát triển có thể trao đổi với nhau

thường xuyên cho nên họ KHÔNG cần nhiều công việc giấy

tờ. Điều này KHÔNG phải là trường hợp cho dự án kiểu thác

đổ có tám tới ba trăm người nơi các thành viên tổ cần những tài

liệu nào đó để chia sẻ thông tin.

239

Thứ hai, Agile yêu cầu sự tham gia của khách hàng hay

đại diện của khách hàng. Không có sự tham gia này, Agile sẽ

KHÔNG có tác dụng. Việc chuyển giao tăng dần chức năng

làm việc yêu cầu rằng khách hàng và người dùng phải tham gia

tích cực trong toàn dự án. Họ phải giải thích mọi thay đổi họ

muốn có theo cách thức rõ ràng và chính xác. Họ phải đặt ưu

tiên và đồng ý cho từng việc đưa ra sản phẩm. Họ phải tham

gia vào mọi cuộc kiểm điểm then chốt và ra quyết định tương

ứng. Về căn bản, họ phải là một phần của tổ.

Thứ ba, Agile yêu cầu mức độ kĩ năng kĩ thuật nào đó.

Không có tổ có kĩ năng cao, Agile sẽ KHÔNG có tác dụng. Nó

cần những người phát triển có kinh nghiệm và có kỉ luật để

hướng dẫn tiến hoá kĩ thuật của hệ thống từ khái niệm tới thực

hiện đầy đủ. Nó yêu cầu người phát triển có kĩ thuật, người có

thể cân bằng nhu cầu tạo ra chức năng phần mềm trong thời

gian ngắn tương ứng với kiến trúc được xác định tốt. Nó cần

những người phát triển có thể cung cấp hướng dẫn dần thiết để

đảm bảo hệ thống có thể được mở rộng qua thời gian với chức

năng phụ và đạt tới mức độ mong muốn về hiệu năng và tính

đổi qui mô được.

Thứ tư, Agile yêu cầu làm việc tổ giữa những người phát

triển. Không có những kĩ năng mềm này, Agile sẽ KHÔNG có

tác dụng. Về căn bản, làm việc tổ là trái tim của Agile bởi vì

thời gian ngắn và yêu cầu KHÔNG được xác định rõ. Nó

KHÔNG cho phép các thành viên tổ tranh cãi với nhau. Với

cách tiếp cận này, không có những điều như "công việc của

tôi" hay “công việc của bạn” mà chỉ có “công việc của chúng

ta”. Các cá nhân sẽ phải giữ nhiều vai và giả định giữ vài trách

nhiệm và sẵn sàng giúp đỡ người khác khi cần. Họ phải chia sẻ

tri thức kĩ thuật để cho mọi thành viên tổ sẽ có khả năng tham

gia vào công việc chung. Để làm điều đó, nó yêu cầu người

lãnh đạo kĩ thuật hay Scrum Master để giám sát các hoạt động

và động viên tổ. Phải có tương tác cộng tác cao độ giữa các

240

thành viên tổ để đáp ứng yêu cầu của khách hàng. Với toàn thể

tổ cùng cam kết với mục đích dự án, các thành viên tổ đã hoàn

thành nhiệm vụ của mình phải giúp cho người còn chưa hoàn

thành để cho dự án có thể kết thúc đúng thời gian.

Quản lí dự án Agile

Phần lớn đào tạo về quản lí dự án đều hội tụ vào dự án

lớn tập trung theo cách tiếp cận "vòng đời thác đổ”. Khi nhiều

công ti dùng phương pháp agile, người quản lí dự án phải được

đào tạo lại để bắt kịp với thay đổi công nghệ và phương pháp

để cho họ có thể hiệu quả hơn. Sau đây là một số gợi ý:

Vì phần lớn các dự án agile đều nhỏ (3 tới 9 người), điều

quan trọng là giữ cho các nhiệm vụ dự án nhỏ (8 tới 20 giờ) để

cho các thành viên tổ có thể hoàn thành nhiệm vụ của họ nhanh

hơn. Về mặt truyền thống, người quản lí dự án được đào tạo để

chia các yêu cầu thành các nhiệm vụ từ một tới bốn tuần; điều

này sẽ KHÔNG có tác dụng tốt với phương pháp agile. Qui tắc

của tôi là “nhiệm vụ dự án lớn hơn được ước lượng trong một

tuần, nhiệm vụ dự án nhỏ hơn (Agile) nên được ước lượng theo

giờ.”

Bởi vì bạn có kích cỡ nhiệm vụ nhỏ hơn, bạn phải lập kế

hoạch để thực hiện cột mốc nào đó chỉ trong một tuần mỗi lúc.

Người quản lí dự án phải theo dõi tất cả các công việc bên

trong chiều dài một tuần để cho họ biết điều họ đã làm được

trong một tuần. Nếu họ không làm tiến bộ tốt, đây là dấu hiệu

cảnh báo rằng dự án có thể KHÔNG được hoàn thành đúng

thời gian. Thành viên tổ phải theo dõi tiến bộ của mình, nơi họ

bắt đầu từ đầu tuần và nơi họ tới lúc cuối. Về căn bản từng

người phải có nhiều nhiệm vụ được hoàn thành trong một tuần,

241

nếu họ kết thúc họ phải đánh giá lại công việc của mình hay

ước lượng của mình.

Bất kì nhiệm vụ nào cũng phải có một định nghĩa về "làm

xong”. Nhiều người phần mềm vẫn còn tranh cãi về "làm

xong" là gì. Qui tắc của tôi là “Làm xong là đã sẵn sàng được

được ra cho người dùng." Điều đó nghĩa là việc viết mã phải

được thực hiện bao gồm mọi kiểm thử mà không còn lỗi. Khi

bạn hoàn thành cái gì đó nó phải được hoàn thành, nó KHÔNG

THỂ được hoàn thành bộ phận. Vì nó sẵn sàng để đưa ra, nó

phải được kiểm thử đầy đủ để cho người dùng có thể dùng

ngay được nó. Tất nhiên, đôi khi, một thành viên tổ KHÔNG

thể kiểm thử được công việc của họ chừng nào những người

khác còn chưa làm xong phần của họ. Nhưng thành viên tổ nên

làm công việc của mình được thực hiện xong nhiều nhất có thể

được.

Về truyền thống, người quản lí dự án phân công nhiệm

vụ cho các thành viên tổ và theo dõi họ tương ứng. Phương

pháp Agile hội tụ nhiều hơn vào công việc tổ cho nên người

quản lí dự án phải làm việc với tổ để xác định cái gì cần được

thực hiện để hoàn thành nhiệm vụ trong một tuần hay để sang

cột mốc khác. Để dự án agile thành công, các thành viên tổ

phải có đủ kinh nghiệm để cho họ có thể đóng góp cho công

việc toàn thể. Thảo luận tổ về cái gì có thể được thực hiện,

nhiệm vụ nào nên được thực hiện và cái gì có thể được hoàn

thành để tiến sang cột mốc tiếp nên được động viên. Càng

nhiều thảo luận, các thành viên tổ các tham gia vào trong dự

án, càng có tự tin rằng dự án sẽ hoàn thành đúng lịch biểu.

Bởi vì các dự án agile là nhỏ, điều quan trọng là hội tụ

nhiều vào chức năng hơn vào kiến trúc. Về truyền thống trong

các dự án lớn, người quản lí dự án tổ chức công việc bằng kiến

trúc và nhiều nhiệm vụ hội tụ vào tầng kiến trúc. Với phương

pháp agile, bạn nên chia các nhiệm vụ xuyên qua kiến trúc để

242

cho bạn có thể hoàn thành một tính năng hay chức năng vào

mỗi lúc, cho dù bạn không hoàn thành tầng kiến trúc. Cách tiếp

cận này dường như phản trực giác với lí thuyết phần mềm,

nhưng tôi thấy nó nhanh hơn và cho phép bạn kết thúc sản

phẩm sớm hơn.

Thay vì tạo ra lịch biểu đầy đủ trước thời gian, tôi thích

dùng cách tiếp cận lặp bằng viế thiết lập lịch biểu một tuần vào

mỗi lúc, nơi các thành viên tổ đều tham gia để cho tôi biết họ

có thể hoàn thành được cái gì vào tuần đó. Một khi họ đã đạt

tới một cột mốc, đó là lúc ước lượng và lập kế hoạch sang cột

mốc tiếp. Việc cả tổ tham gia vào ước lượng lịch biểu là tốt

hơn nhiều so với ước lượng riêng của các cá nhân. Tôi đòi hỏi

từng thành viên tổ phải đưa ra ước lượng riêng của họ và dùng

cách tiếp cận “Delphi băng rộng” hay cách tiếp cận trung bình

để đi tới lịch biểu toàn thể. Khi bạn cho phép mọi người tạo ra

ước lượng riêng của họ, họ có xu hướng theo dõi mình, đi theo

mình, và cố gắng làm cho nó được hoàn thành thành công bởi

vì ước lượng của họ là một phần công việc của họ.

Bởi vì các dự án agile đều nhỏ, bạn phải tích hợp các

công việc liên tục, không thành vấn đề bạn đang làm cái gì

(mã, kiểm thử, tài liệu, kế hoạch). Bạn phải có người làm quản

lí cấu hình phần mềm để giúp thiết lập cấu hình và phiên bản

đúng cho phần mềm của bạn vì công việc thường xuyên thay

đổi. Khi phiên bản cuối cùng được kiểm đưa vào, và tôi biết

trạng thái nó tới trong nó và tôi không phải nghĩ về nó.

Ai đó hỏi tôi, nếu agile là hoạt động toàn tổ, có thực sự

cần người quản lí dự án không? Câu trả lời của tôi là dứt khoát

“Có”. Tuy nhiên, vai trò của người quản lí dự án trong phương

pháp agile mang nhiều tính người lãnh đạo và thầy kèm chứ

KHÔNG kiểm soát như được dạy trong hầu hết các giáo trình

quản lí dự án. Bạn càng cung cấp nhiều hướng dẫn và hỗ trợ

cho tổ, họ sẽ càng có kết quả hơn. Bạn càng thực hành cách

243

tiếp cận cộng tác này, bạn càng linh hoạt hơn như một người

quản lí dự án, điều làm cho bạn thành người quản lí giỏi hơn.

Bạn KHÔNG ra lệnh cho họ, bạn KHÔNG chỉ đạo họ, bạn

KHÔNG chỉ huy họ, bạn KHÔNG đe doạ họ mà bạn là người

hướng dẫn họ, ai đó mà họ tin cậy và ai đó giúp cho họ làm

công việc của họ. Về căn bản, bạn là người lãnh đạo của họ và

người lãnh đạo KHÔNG phải là ai đó có thẩm quyền trên họ

mà là ai đó họ sẵn lòng đi theo.

Dự án agile thành công có hai yếu tố then chốt: Người

lãnh đạo là người quản lí dự án và tổ có kinh nghiệm và có kỉ

luật. Không có hai yếu tố này, nó sẽ là khó. Câu hỏi của tôi là

“Là người quản lí dự án, bạn có sẵn lòng thay đổi để trở thành

người lãnh đạo giỏi hơn không?” và “Là thành viên tổ, bạn có

đủ kinh nghiệm và kỉ luật để áp dụng phương pháp agile vào

công việc của bạn không?”

Người kiểm thử trong dự án Agile

Tôi nhận được một email người gửi viết: “Ai đó bảo tôi

rằng trong phương pháp Agile, KHÔNG có việc làm cho người

kiểm thử. Là người kiểm thử, tôi lo lắng về tương lai của mình

vì công ti của tôi sớm có kế hoạch dùng phương pháp Agile

(Scrum). Xin thầy lời khuyên.”

Câu trả lời của tôi: “Cách tiếp cận Agile có tác dụng tốt

cho dự án nhỏ (3 tới 8 người). Khi tới việc kiểm thử, bản thân

tổ phát triển làm việc kiểm thử riêng của mình. Không có phân

biệt giữa người phát triển và người kiểm thử vì các thành viên

thường chuyển đổi vai trò. Nói cách khác, với cách tiếp cận

Agile "người phát triển" và "người kiểm thử" là một phần của

tổ phát triển. Chẳng hạn với Lập trình cực đoan, có cách tiếp

cận có tên là “Lập trình cặp đôi” nơi hai người cùng làm việc

244

với nhau trong một nhiệm vụ. Người này đóng vai trò của

“người phát triển” (hay người dẫn lái) còn người kia đóng vai

trò "người kiểm thử" (hay người quan sát). Họ quan sát công

việc của nhau, học từ nhau, kiểm điểm mã của nhau, và đưa ra

phản hồi cho nhau. Người phát triển học kĩ năng kiểm thử từ

người kiểm thử và người kiểm thử cũng học kĩ năng viết mã từ

người phát triển. Chung cuộc họ chuyển đổi vai trò khi họ tiếp

tục làm việc với nhau. Tuy nhiên, điều đó KHÔNG có nghĩa là

việc làm của người kiểm thử bị khử bỏ. Là người kiểm thử, bạn

sẽ được đưa vào trong tổ phát triển nơi bạn cũng sẽ học lập

trình và làm việc như người phát triển nữa.

Tôi biết rằng đây là khác biệt so với cách tiếp cận thác đổ

nơi người phát triển chỉ kiểm thử mã riêng của họ (kiểm thử

đơn vị) rồi đưa nó cho người kiểm thử để làm các kiểm thử

thêm (trắc nghiệm và kiểm nghiệm). Trừ phi công ti của bạn

CHỈ hội tụ vào dự án nhỏ, sẽ có các dự án lớn hơn nữa (có thể

20, hay 50, hay 200 người) cho nên vẫn sẽ có nhu cầu về tổ

kiểm thử độc lập. Dự án lớn thường phức tạp, găng, với nhiều

khó khăn kĩ thuật cho một người được giữ nhiều vai trò. Các

dự án lớn cũng yêu cầu những tri thức chuyên gia nào đó và

yêu cầu người có kinh nghiệm, người có chuyên môn nào đó

cho nên bạn KHÔNG nên lo lắng rằng việc kiểm thử sẽ mai

một đi sớm.

Với hầu hết các dự án lớn, tổ phát triển sẽ hội tụ vào yêu

cầu, kiến trúc, thiết kế, viết mã và kiểm thử đơn vị. Tổ kiểm

thử làm việc song song với các hoạt động phát triển nhưng hội

tụ vào các vấn đề riêng mà thường khó cho tổ phát triển tìm ra

và cung cấp phản hồi cho tổ phát triển. Kiểu kiểm thử này là

tương tự với cách tiếp cận "lập trình cặp đôi" trong Agile

nhưng tổ kiểm thử có kinh nghiệm và được đào tạo để thực

hiện những kiểm thử nào đó (trắc nghiệm và kiểm nghiệm) để

đảm bảo chất lượng là "có sẵn". Chẳng hạn, tổ kiểm thử sẽ hội

tụ vào vấn đề tích hợp (kiểm thử tích hợp) để đảm bảo rằng

245

giải pháp của tổ phát triển sẽ làm việc tốt với hệ thống hiện có

hay giải pháp được thực hiện bởi tổ phát triển khác. Với hệ

thống phức tạp, tổ kiểm thử có thể hội tụ vào vấn đề an ninh

(kiểm thử an ninh) và chắc chắn rằng nó được thiết kế tốt và

khớp với hệ thống hiện thời. Trong hầu hết các dự án lớn, có

vài tổ phát triển, từng tổ tập trung vào chức năng nào đó hay

khu vực đặc biệt, nhưng phải có một tổ kiểm thử độc lập để

giám sát mọi thứ và chắc chắn rằng hệ thống phát triển sẽ làm

việc (kiểm thử trắc nghiệm và kiểm nghiệm).

Trừ phi bạn thực sự thích làm việc mãi mãi là người kiểm

thử, tôi tin việc học kĩ năng mới, tri thức mới là tiến bộ tự

nhiên trong nghề phần mềm. Tôi sẽ KHÔNG ngần ngại học về

Agile và chuẩn bị làm việc trong các vai trò mới như người lập

trình, người phát triển, hay thậm chí Thầy Scrum. Bạn càng có

nhiều tri thức, việc làm của bạn càng an ninh hơn. ĐỪNG lo về

chiều hướng của công ti chuyển sang Agile mà hội tụ vào điều

bạn có thể học và điều bạn có thể làm để cải tiến nghề nghiệp

của mình. Bạn muốn là nhà chuyên nghiệp phần mềm giỏi

nhất, vai trò và trách nhiệm nào không thành vấn đề.”

Phát triển phần mềm Agile

Agile là cách tiếp cận phát triển phần mềm trong đó tổ

xây dựng phần mềm trong vài lần lặp ngắn, thay vì mọi thứ đi

từ bắt đầu tới kết thúc. Agile cung cấp ích lợi như linh hoạt, dễ

thay đổi, chất lượng tốt, ít rủi ro và thoả mãn khách hàng tốt

hơn nhưng có "tiền điều kiện" mà tổ chức phải có để đạt tới

những ích lợi này.

Agile yêu cầu sự tham gia của khách hàng trong mọi khía

cạnh của dự án. Nếu khách hàng bận rộn và không thể tham gia

được thì Agile sẽ KHÔNG có tác dụng. Một trong các phương

246

pháp phổ biến nhất trong Agile là “Scrum”. Phương pháp này

định nghĩa ba vai trò then chốt: “Người chủ sản phẩm” người

đại diện cho khách hàng và chịu trách nhiệm viết yêu cầu và ưu

tiên hoá chúng trong “tồn dư sản phẩm”. "Thầy Scrum," người

hướng dẫn và giúp đỡ tổ dự án vượt qua các chướng ngại và

giữ cho họ hội tụ vào những điều họ phải làm. Tổ dự án, một

nhóm “tự tổ chức” làm mọi điều một cách hiệu quả nhất để đạt

tới kết quả. Dùng cách tiếp cận Agile là thay đổi chính trong tổ

chức với cấu trúc phân cấp và mọi người thường nhận được

"chỉ đạo" từ ông chủ. Đó là lí do tại sao tôi mạnh mẽ khuyến

cáo rằng trước khi vào từng dự án, tổ phải nhận được đào tạo

Agile "chính thức" để chắc rằng sẽ KHÔNG có hiểu lầm nào

hay quan niệm lầm nào về cách tiếp cận này. Không có đào tạo

đúng, Agile có thể bị DÙNG SAI vì một số người lập trình coi

nó là “Làm bất kì điều gì bạn muốn,” “Mã trước, hỏi câu hỏi

sau,” “Không tài liệu, không qui trình.”

Agile bao gồm một số thực hành mà hình thành nên nền

tảng cho tổ chức muốn tuân theo cách tiếp cận này.

1) Tổ Agile phải xác định cho bản thân họ cách họ sẽ làm

việc (thiết lập qui trình) và cách họ sẽ làm công việc (phát

triển sản phẩm). Tổ Agile phải hiểu giá trị của dự án. Giá

trị có thể được mô tả là “Linh hoạt”, “Chất lượng”, “Dễ

thay đổi”, “Tự học, tổ học” v.v. Trong cách tiếp cận

Agile, tổ đi qua “các giai đoạn phát triển tổ” khi họ thực

hiện công việc của họ. Kết quả của phát triển tổ là bản

thân tổ, và không phải là kĩ năng và năng lực mà các cá

nhân học. Làm việc tổ là bản chất trong Agile, không có

nó, Agile sẽ KHÔNG có tác dụng.

2) Lúc bắt đầu dự án, người chủ sản phẩm chuẩn bị một

danh sách các yêu cầu của khách hàng hay “Tồn dư sản

phẩm”, danh sách các tính năng được sắp ưu tiên bởi giá

trị được chuyển giao cho khách hàng. Với từng lần lặp

247

(Sprint - chặng nước rút), một số trong những khoản mục

đó trong tồn dư sản phẩm được lựa ra và đưa vào trong

“Sprint Backlog - Tồn dư nước rút”, danh sách những

điều cần được làm trong từng chặng nước rút Sprint.

Trong cách tiếp cận Agile, thay đổi là bình thường và

được đưa vào trong tồn dư sản phẩm bởi người chủ sản

phẩm vì khách hàng liên tục cung cấp phản hồi hay thêm

nhiều tính năng. Tổ tiếp tục công việc trong vài lần lặp

(Sprint) cho tới khi họ hoàn thành tồn dư sản phẩm.

3) Agile dùng các thời kì thời gian ngắn hay “Sprint”

(phương pháp Scrum) điển hình quãng 2 tới 4 tuần, để

chuyển giao cái gì đó cho khách hàng. Từng “Sprint”

được tổ chức để cho tổ thực tế hoàn thành một mảnh của

sản phẩm toàn bộ. Ngay khi mảnh này của sản phẩm có

thể được chuyển giao, nhiều giá trị hơn có thể được thu

lấy. Tính linh hoạt này giúp khách hàng có cái gì đó

nhanh chóng để dùng, tổ cũng nhận phản hồi ngay lập

tức, và giảm rủi ro dự án.

4) Mọi “Sprint” đều được cai quản bởi “phạm vi được xác

định” trong tồn dư nước rút Sprint. Tổ ước lượng nỗ lực

và chi phí của từng Sprint và điều phối với người chủ sản

phẩm. Cách tiếp cận Agile dùng "chu kì học" tường minh

(tức là, lập kế hoạch, làm, kiểm tra, hành động) hay (Lập

kế hoạch, hành động, suy nghĩ, học) để cho tổ thường

xuyên học, cải tiến và sẵn sàng điều chỉnh khớp theo thay

đổi. Sau từng lần lặp (Sprint), tổ sẽ kiểm điểm công việc

riêng của họ hay “nội quan-quan sát bên trong” để nhận

diện công việc nào, cái gì không có tác dụng để cải tiến

qui trình riêng của họ để cho họ có thể làm nó tốt hơn lần

sau. Đó là lí do tại sao dự án Agile thường có chất lượng

cao.

248

5) Tổ Agile phải có phương tiện trao đổi hiệu quả giữa các

thành viên tổ và khách hàng. Để đạt tới điều đó, tổ cần

trao đổi giữa con người thay vì bất kì cách nào khác như

email, thư, văn bản hay tài liệu. Mặc dầu một số người

nói rằng Agile cũng có thể được thực hiện trong phát

triển toàn cầu, có các thành viên tổ ở nhiều chỗ hay ở

nhiều nước. Theo kinh nghiệm của tôi, tôi thấy điều đó

khá khó. Không có trao đổi tốt, tổ có thể phí thời gian về

thông tin, các thành viên có thể hiểu lầm nhau, dự án có

thể có nhiều lỗi hay phải làm lại. Không có trao đổi mặt

đối mặt điều đó có thể làm chậm phát triển dự án, khó

xây dựng tin cậy giữa các thành viên tổ, khó xây dựng tổ,

và có thể KHÔNG có khả năng gióng thẳng cảm nhận về

thực tại. Khuyến cáo cá nhân của tôi là đối với cách tiếp

cận Agile, cách tốt nhất là để mọi thành viên tổ ở cùng

một chỗ nơi họ có thể làm việc cùng nhau, hỗ trợ lẫn

nhau, và chia sẻ thông tin một cách tự do.

6) Bằng kiểm thử mọi thứ, bằng việc tạo ra các trường hợp

kiểm thử để kiểm tra mọi công việc, tổ có thể đạt tới mức

chất lượng cực kì cao. Khả năng này để ngăn cản khiếm

khuyết là rất quan trọng trong Agile bởi vì “chất lượng là

KHÔNG thương lượng được”. Trong cách tiếp cận này,

loại bỏ khiếm khuyết là kiểu làm việc duy nhất được coi

là ưu tiên so với bất kì tính năng /chức năng/sản xuất mới.

Nếu kết quả cuối cùng được mong muốn là làm cực đại

chất lượng, thì loại bỏ khiếm khuyết là điều quan trọng

nhất. Tổ có nghĩa vụ đạo đức để kiểm tra một cách hiệu

quả công việc của họ bằng bất kì phương tiện nào họ có

thể làm bằng việc dùng công cụ, cơ chế phản hồi đa dạng,

tự động hoá để chắc họ có sản phẩm chất lượng cao nhất

có thể được.

7) Mọi thành viên tổ Agile đều phải nhận trách nhiệm "phát

quang con đường” hay loại bỏ chướng ngại ngăn cản

249

công việc được thực hiện một cách hiệu quả. “Phát quang

con đường” KHÔNG chỉ có nghĩa là mưu kế cách thức,

sửa nhanh vấn đề, mà thay vì thế là để thời gian nhìn vào

chướng ngại và làm tốt nhất có thể được để loại bỏ nó

vĩnh viễn để cho nó không bao giờ chắn đường lần nữa.

Trong cách tiếp cận Agile, người dẫn qui trình (thầy

Scrum) là người chịu trách nhiệm theo dõi chướng ngại

và đảm bảo rằng con đường được phát quang. Phát quan

con đường đôi khi là công việc đau đớn làm phơi bày

những điều mọi người thà không giải quyết. Kết quả là,

điều mấu chốt là mọi người xây dựng năng lực của họ để

chân thực và làm việc để phát triển tin cậy lẫn nhau.

Một số sự kiện về cách tiếp cận Agile

Một sinh viên hỏi tôi: “Nếu Agile là cách tiếp cận tốt để

phát triển phần mềm thì tại sao chúng ta phải học cách tiếp cận

khác?”

Câu trả lời của tôi: Agile là cách tiếp cận tốt tới phát triển

phần mềm, đặc biệt khi dự án là nhỏ và yêu cầu KHÔNG được

hiểu rõ. Tuy nhiên, Agile KHÔNG là giải pháp cho mọi thứ.

Có những phương pháp khác nhau cho các kiểu dự án khác

nhau. Nhân tiện, Agile chỉ có tác dụng nếu những điều kiện

nhất định tồn tại.

Thứ nhất, Agile yêu cầu mọi thành viên tổ nhận được đào

tạo về cách tiếp cận này (Scrum, lập trình cực đoan, Crystal

v.v.). Không có đào tạo đúng, Agile sẽ KHÔNG có tác dụng.

Tôi đã thấy nhiều sinh viên hiểu lầm Agile như cách thức

không kỉ luật để làm bất kì cái gì họ muốn như “viết mã trước,

hỏi câu hỏi sau”. Điều này là KHÔNG chấp nhận được bởi vì

Agile là về việc làm cho công việc được thực hiện tương ứng,

250

điều có nghĩa là các thành viên tổ phải tuân theo những qui tắc

và qui trình nào đó. Chẳng hạn, với Scrum, dự án được chia

thành các chu kì nhỏ được gọi là “Sprint - nước rút” (quãng 2

tới 4 tuần) nơi tổ hội tụ vào những chức năng nào đó mà họ

phải phát triển và kiểm thử bên trong thời gian xác định

đó. Qui trình lặp, tăng dần được làm tài liệu tốt và phải được

tuân theo. Có vài bài báo nói rằng với Agile bạn KHÔNG cần

tuân theo qui trình. Điều đó là SAI. Sự kiện là bạn bao giờ

cũng tuân theo "qui trình được xác định" dù bạn dùng Scrum,

Crystal hay lập trình cực đoan. Có khác biệt giữa Agile và

vòng đời thác đổ truyền thống, nơi phương pháp truyền thống

yêu cầu nhiều tài liệu nhưng với Agile, những tài liệu này đang

bị rút gọn tới tối thiểu. Tuy nhiên, điều đó KHÔNG có nghĩa là

Agile KHÔNG có tài liệu. Bởi vì dự án Agile là nhỏ chạy từ 3

tới 8 người, những người phát triển có thể trao đổi với nhau

thường xuyên cho nên họ KHÔNG cần nhiều công việc giấy

tờ. Điều này KHÔNG phải là trường hợp cho dự án kiểu thác

đổ có tám tới ba trăm người nơi các thành viên tổ cần những tài

liệu nào đó để chia sẻ thông tin.

Thứ hai, Agile yêu cầu sự tham gia của khách hàng hay

đại diện của khách hàng. Không có sự tham gia này, Agile sẽ

KHÔNG có tác dụng. Việc chuyển giao tăng dần chức năng

làm việc yêu cầu rằng khách hàng và người dùng phải tham gia

tích cực trong toàn dự án. Họ phải giải thích mọi thay đổi họ

muốn có theo cách thức rõ ràng và chính xác. Họ phải đặt ưu

tiên và đồng ý cho từng việc đưa ra sản phẩm. Họ phải tham

gia vào mọi cuộc kiểm điểm then chốt và ra quyết định tương

ứng. Về căn bản, họ phải là một phần của tổ.

Thứ ba, Agile yêu cầu mức độ kĩ năng kĩ thuật nào đó.

Không có tổ có kĩ năng cao, Agile sẽ KHÔNG có tác dụng. Nó

cần những người phát triển có kinh nghiệm và có kỉ luật để

hướng dẫn tiến hoá kĩ thuật của hệ thống từ khái niệm tới thực

hiện đầy đủ. Nó yêu cầu người phát triển có kĩ thuật, người có

251

thể cân bằng nhu cầu tạo ra chức năng phần mềm trong thời

gian ngắn tương ứng với kiến trúc được xác định tốt. Nó cần

những người phát triển có thể cung cấp hướng dẫn dần thiết để

đảm bảo hệ thống có thể được mở rộng qua thời gian với chức

năng phụ và đạt tới mức độ mong muốn về hiệu năng và tính

đổi qui mô được.

Thứ tư, Agile yêu cầu làm việc tổ giữa những người phát

triển. Không có những kĩ năng mềm này, Agile sẽ KHÔNG có

tác dụng. Về căn bản, làm việc tổ là trái tim của Agile bởi vì

thời gian ngắn và yêu cầu KHÔNG được xác định rõ. Nó

KHÔNG cho phép các thành viên tổ tranh cãi với nhau. Với

cách tiếp cận này, không có những điều như "công việc của

tôi" hay “công việc của bạn” mà chỉ có “công việc của chúng

ta”. Các cá nhân sẽ phải giữ nhiều vai và giả định giữ vài trách

nhiệm và sẵn sàng giúp đỡ người khác khi cần. Họ phải chia sẻ

tri thức kĩ thuật để cho mọi thành viên tổ sẽ có khả năng tham

gia vào công việc chung. Để làm điều đó, nó yêu cầu người

lãnh đạo kĩ thuật hay Scrum Master để giám sát các hoạt động

và động viên tổ. Phải có tương tác cộng tác cao độ giữa các

thành viên tổ để đáp ứng yêu cầu của khách hàng. Với toàn thể

tổ cùng cam kết với mục đích dự án, các thành viên tổ đã hoàn

thành nhiệm vụ của mình phải giúp cho người còn chưa hoàn

thành để cho dự án có thể kết thúc đúng thời gian.

Agile và kích cỡ dự án

Một người lập trình viết cho tôi: “Tuần trước em tham dự

một xê mi na Agile trong đó nhà tư vấn giải thích rằng Agile có

thể được áp dụng cho bất kì kích cỡ nào của các dự án. Ông ấy

cung cấp đào tạo đặc biệt này cho công ti của em. Em nhớ rằng

252

thầy viết “Agile chỉ tốt cho dự án nhỏ.” Em thấy lẫn lộn, xin

thầy giúp.”

Đáp: Theo kinh nghiệm riêng của tôi, các qui trình Agile

dường như có tác dụng tốt nhất với tổ nhỏ những người làm

việc trên dự án nhỏ. Tôi đã quản lí nhiều dự án Agile với các

kích cỡ khác nhau và tôi có thành công tốt hơn với Agile trong

các dự án nhỏ (ít hơn 10 người). Ken Beck, tác giả của Lập

trình cực đoan (EP) cũng viết trong cuốn sách nổi tiếng của

ông ấy: “Kích cỡ rõ ràng thành vấn đề, bạn có lẽ không cho

chạy được dự án XP với hàng trăm người lập trình. Cũng

không được với năm mươi người. Không được với hai mươi

người, có lẽ. Mười dứt khoát là có thể làm được.”

Sức mạnh của Agile là ở điều phối tốt hơn, quan hệ tốt

hơn, trao đổi tốt hơn và tri thức được chia sẻ. Bằng việc đặt

Agile vào dự án kích cỡ lớn hơn, bạn làm loãng những điểm

mạnh này và làm cho khó xây dựng sản phẩm chất lượng. Có

các cách tiếp cận khác như phương pháp xoáy ốc và dẫn lái

theo kế hoạch được thiết kế cho các dự án lớn. Những phương

pháp này yêu cầu các vai trò, trách nhiệm được xác định rõ và

tài liệu nghiêm ngặt để điều phối các hoạt động ngang qua các

nhóm lớn. Bạn cần hiểu rằng từng cách tiếp cận được thiết kế

cho kiểu dự án nào đó. Agile là tốt cho dự án nhỏ mà không có

yêu cầu tốt hay các yêu cầu thường xuyên thay đổi. Các qui

trình Agile yêu cầu chu kì lặp ngắn để cho khách hàng có thể

có phần mềm nhanh chóng nhất có thể được vì bạn không phải

chuyển giao mọi thứ một lúc. Tuy nhiên, Agile cần quan hệ

làm việc tốt với khách hàng và người dùng để có được phản hồi

nhanh chóng và ưu tiên về điều cần làm tiếp. Nó cũng yêu cầu

rằng các thành viên tổ có kinh nghiệm và có thể được tự tổ

chức để làm việc hướng tới mục đích chung.

Tôi không tin vào cách tiếp cận "một cỡ khớp cho tất cả."

Có các nhà tư vấn đưa ra hứa hẹn mà họ không thể giữ lời

253

được. Một số người chỉ muốn làm tiền và sẽ làm bất kì cái gì

để được trả tiền. Họ không quan tâm về liệu bạn học được cái

gì đó đúng hay không. Tôi đã thấy nhiều xê mi na và khoá đào

tạo mà nhà tư vấn sẽ dạy cho khách hàng cách qua kì thi nào đó

để được chứng chỉ nhưng không về cách thực hiện nó cho

đúng. Kết quả là người lập trình có chứng chỉ nhưng không có

kĩ năng. Kiểu đào tạo này là phổ biến cho những người chỉ

muốn mảnh giấy để trưng trong văn phòng của họ nhưng

không chăm nom về tri thức hay kĩ năng của họ. Nếu bạn phải

trả tiền cho ai đó dạy bạn cái gì đó, phải chắc bạn tìm người tư

vấn giỏi có nhiều năm kinh nghiệm làm việc và thực sự chăm

nom rằng khách hàng của họ sẽ có khả năng có việc làm tốt sau

khi đào tạo. Đó là tiền bạc của bạn và kĩ năng của bạn cho nên

phải cực kì để ý tới những người hứa quá nhiều.

Người quản lí dự án trong môi trường Agile

Ngày nay phương pháp luận Agile như Lập trình cực

đoan (XP), Scrum, Crystal, v.v., đang trở thành phổ biến hơn vì

công nghiệp yêu cầu rằng việc phát triển phần mềm phải được

thực hiện nhanh chóng và có tính đáp ứng với thay đổi. Để

cạnh tranh trong nền kinh tế toàn cầu, các công ti phần mềm

phải chuyển nhanh để cung cấp giải pháp cho khách hàng.

Cách tiếp cận Agile dựng tăng dần có thể chuyển giao

phần mềm nhanh hơn cách tiếp cận dẫn lái theo kế hoạch

truyền thống, điều tuân theo trật tự trình tự các pha vòng đời.

Việc dịch chuyển này trong cách tiếp cận cũng thay đổi cách

quản lí dự án truyền thống từ lập kế hoạch và kiểm soát sang

tạo điều kiện và cộng tác. Cách tiếp cận Agile tuỳ thuộc chủ

yếu vào kĩ năng của tổ dự án, đó là việc tự tổ chức để phát triển

phần mềm mà không có chỉ huy của người quản lí. Cách tiếp

254

cận này cũng dẫn tới việc dịch chuyển trong cấu trúc tổ chức

và kĩ năng của những người làm việc ở đó. Với một công ti đã

có uy tín với những người có kĩ năng cao, dễ dàng chấp nhận

Agile nhưng với công ti kém trưởng thành hơn không có lực

lượng lao động có kĩ năng, việc chuyển có thể là thảm hoạ và

đó là lí do tại sao nhiều dự án Agile thất bại thế.

Với Agile không có vai trò của người quản lí. Điều này

làm cho những người quản lí bị lẫn lộn liệu họ có được cần tới

hay không. Họ phải hiểu rằng vai trò mới của họ là hướng dẫn

tổ đáp ứng với thay đổi vì tổ phải ra quyết định thay vì được

bảo phải làm gì. Nó cũng có nghĩa là nhiều trách nhiệm cá

nhân hơn đối với các thành viên tổ, và nhiều kĩ năng tạo điều

kiện được yêu cầu đối với người quản lí dự án. Phương pháp

Agile phổ biến nhất có hai vai trò cá nhân then chốt mà người

quản lí dự án có thể làm: Người chủ sản phẩm là người làm

việc chặt chẽ với khách hàng để quyết định cái gì sẽ được dựng

và theo trật tự nào. Người chủ sản phẩm xác định tính năng của

sản phẩm, chọn khi nào phần mềm sẽ được đưa ra và điều

chỉnh các tính năng và ưu tiên khi cần. Thầy Scrum là người

làm việc chặt chẽ với tổ để đảm bảo rằng tổ làm việc cùng nhau

và có năng suất. Thầy Scrum tạo điều kiện cho các hoạt động

tổ và tạo khả năng cộng tác ngang qua mọi vai trò và chức

năng, loại bỏ rào chắn khỏi các can nhiễu bên ngoài, đảm bảo

rằng qui trình được tuân theo như hội ý hàng ngày, kiểm điểm

chặng nước rút, và lập kế hoạch chặng nước rút.

Phần lớn những người quản lí dự án truyền thống không

thấy thoải mái với những vai trò này khi chuyển sang Agile

nhưng cuối cùng nhiều người nhận ra rằng họ thực hiện vai trò

nào không thành vấn đề, chính trách nhiệm của họ là xây dựng

tổ dự án mà có thể chuyển giao sản phẩm chất lượng với thời

gian nhanh hơn. Tất nhiên, không phải mọi người đều sẵn lòng

làm dịch chuyển này nhưng với những người sẵn lòng, họ sẽ

255

thấy cả qui trình và kĩ năng mới họ đã học được là việc trao

giải thưởng và xứng đáng với nỗ lực bỏ ra.

Người kiểm thử trong dự án Agile

Tôi nhận được một email người gửi viết: “Ai đó bảo tôi

rằng trong phương pháp Agile, KHÔNG có việc làm cho người

kiểm thử. Là người kiểm thử, tôi lo lắng về tương lai của mình

vì công ti của tôi sớm có kế hoạch dùng phương pháp Agile

(Scrum). Xin thầy lời khuyên.”

Câu trả lời của tôi: “Cách tiếp cận Agile có tác dụng tốt

cho dự án nhỏ (3 tới 8 người). Khi tới việc kiểm thử, bản thân

tổ phát triển làm việc kiểm thử riêng của mình. Không có phân

biệt giữa người phát triển và người kiểm thử vì các thành viên

thường chuyển đổi vai trò. Nói cách khác, với cách tiếp cận

Agile "người phát triển" và "người kiểm thử" là một phần của

tổ phát triển. Chẳng hạn với Lập trình cực đoan, có cách tiếp

cận có tên là “Lập trình cặp đôi” nơi hai người cùng làm việc

với nhau trong một nhiệm vụ. Người này đóng vai trò của

“người phát triển” (hay người dẫn lái) còn người kia đóng vai

trò "người kiểm thử" (hay người quan sát). Họ quan sát công

việc của nhau, học từ nhau, kiểm điểm mã của nhau, và đưa ra

phản hồi cho nhau. Người phát triển học kĩ năng kiểm thử từ

người kiểm thử và người kiểm thử cũng học kĩ năng viết mã từ

người phát triển. Chung cuộc họ chuyển đổi vai trò khi họ tiếp

tục làm việc với nhau. Tuy nhiên, điều đó KHÔNG có nghĩa là

việc làm của người kiểm thử bị khử bỏ. Là người kiểm thử, bạn

sẽ được đưa vào trong tổ phát triển nơi bạn cũng sẽ học lập

trình và làm việc như người phát triển nữa.

Tôi biết rằng đây là khác biệt so với cách tiếp cận thác đổ

nơi người phát triển chỉ kiểm thử mã riêng của họ (kiểm thử

256

đơn vị) rồi đưa nó cho người kiểm thử để làm các kiểm thử

thêm (trắc nghiệm và kiểm nghiệm). Trừ phi công ti của bạn

CHỈ hội tụ vào dự án nhỏ, sẽ có các dự án lớn hơn nữa (có thể

20, hay 50, hay 200 người) cho nên vẫn sẽ có nhu cầu về tổ

kiểm thử độc lập. Dự án lớn thường phức tạp, găng, với nhiều

khó khăn kĩ thuật cho một người được giữ nhiều vai trò. Các

dự án lớn cũng yêu cầu những tri thức chuyên gia nào đó và

yêu cầu người có kinh nghiệm, người có chuyên môn nào đó

cho nên bạn KHÔNG nên lo lắng rằng việc kiểm thử sẽ mai

một đi sớm.

Với hầu hết các dự án lớn, tổ phát triển sẽ hội tụ vào yêu

cầu, kiến trúc, thiết kế, viết mã và kiểm thử đơn vị. Tổ kiểm

thử làm việc song song với các hoạt động phát triển nhưng hội

tụ vào các vấn đề riêng mà thường khó cho tổ phát triển tìm ra

và cung cấp phản hồi cho tổ phát triển. Kiểu kiểm thử này là

tương tự với cách tiếp cận "lập trình cặp đôi" trong Agile

nhưng tổ kiểm thử có kinh nghiệm và được đào tạo để thực

hiện những kiểm thử nào đó (trắc nghiệm và kiểm nghiệm) để

đảm bảo chất lượng là "có sẵn". Chẳng hạn, tổ kiểm thử sẽ hội

tụ vào vấn đề tích hợp (kiểm thử tích hợp) để đảm bảo rằng

giải pháp của tổ phát triển sẽ làm việc tốt với hệ thống hiện có

hay giải pháp được thực hiện bởi tổ phát triển khác. Với hệ

thống phức tạp, tổ kiểm thử có thể hội tụ vào vấn đề an ninh

(kiểm thử an ninh) và chắc chắn rằng nó được thiết kế tốt và

khớp với hệ thống hiện thời. Trong hầu hết các dự án lớn, có

vài tổ phát triển, từng tổ tập trung vào chức năng nào đó hay

khu vực đặc biệt, nhưng phải có một tổ kiểm thử độc lập để

giám sát mọi thứ và chắc chắn rằng hệ thống phát triển sẽ làm

việc (kiểm thử trắc nghiệm và kiểm nghiệm).

Trừ phi bạn thực sự thích làm việc mãi mãi là người kiểm

thử, tôi tin việc học kĩ năng mới, tri thức mới là tiến bộ tự

nhiên trong nghề phần mềm. Tôi sẽ KHÔNG ngần ngại học về

Agile và chuẩn bị làm việc trong các vai trò mới như người lập

257

trình, người phát triển, hay thậm chí Thầy Scrum. Bạn càng có

nhiều tri thức, việc làm của bạn càng an ninh hơn. ĐỪNG lo về

chiều hướng của công ti chuyển sang Agile mà hội tụ vào điều

bạn có thể học và điều bạn có thể làm để cải tiến nghề nghiệp

của mình. Bạn muốn là nhà chuyên nghiệp phần mềm giỏi

nhất, vai trò và trách nhiệm nào không thành vấn đề.”

SCRUM

Agile là qui trình phát triển phần mềm "hướng theo tổ"

được thiết kế cho dự án nhỏ nơi yêu cầu không ổn định và liên

tục thay đổi. Để làm công việc mau lẹ, sự tham gia của khách

hàng được yêu cầu và tổ sẽ hội tụ vào các hoạt động chứ không

chỉ kết quả bởi vì hoạt động chất lượng sẽ tạo ra kết quả chất

lượng. Chương trình khoa học máy tính truyền thống nhấn

mạnh vào cái ra hay kết quả (sản phẩm) nhưng không nhấn

mạnh mấy tới hoạt động (qui trình) tạo ra kết quả. Trong lớp,

sinh viên tập trung hầu hết vào kết quả đúng nhưng không

được dạy về qui trình phát triển phần mềm. Đây là một trong

các vấn đề của đào tạo ngôn ngữ lập trình nơi sinh viên có thể

làm bất kì cái gì họ muốn chừng nào họ còn đi tới câu trả lời

đúng. Tương phản lại, đào tạo kĩ nghệ phần mềm hội tụ nhiều

vào kỉ luật xây dựng phần mềm tương ứng với qui trình đã xác

định. Một trong các phương pháp được dạy là phương pháp

mau lẹ - agile.

Có vài phương pháp trong agile nhưng phổ biến nhất là

“Scrum” một qui trình được xác định để giám sát và kiểm soát

các hoạt động phát triển phần mềm. Khía cạnh then chốt của

Scrum là vai trò, trách nhiệm và tính đảm nhiệm của mọi người

trong tổ như sau:

258

Người chủ sản phẩm chịu trách nhiệm cho những điều

sau:

Xác định tính năng của sản phẩm;

Quyết định về ngày đưa ra và nội dung;

Ưu tiên hoá các tính năng tương ứng với nhu cầu của

khách hàng;

Điều chỉnh các tính năng và ưu tiên cứ sau 30 ngày, khi

cần; và

Chấp nhận hay bác bỏ kết quả công việc.

Người chủ Scrum là người lãnh đạo tổ làm việc chặt chẽ

với người chủ sản phẩm. Người chủ Scrum:

Đảm bảo rằng tổ hoạt động và có năng suất đầy đủ;

Tạo khả năng cho hợp tác chặt chẽ qua tất cả các vai trò

và chức năng;

Che chắn cho tổ khỏi bị can nhiễu bên ngoài; và

Đảm bảo rằng qui trình được tuân theo,

Tổ:

xuyên chéo chức năng, với các thành viên có kinh

nghiệm;

lựa chọn mục đích việc chạy nước rút (Sprint) và xác

định kết quả công việc;

có quyền tự tổ chức bên trong biên giới của hướng dẫn để

đạt tới mục đích của Sprint;

đề mô kết quả công việc cho người chủ sản phẩm.

Dự án phần mềm Scrum được quản lí bằng việc duy trì

đơn hàng chưa làm xong của sản phẩm (danh sách yêu cầu) và

các rủi ro. Đơn hàng chưa xong của sản phẩm là phát biểu về

công việc mà dự án phải thực hiện. Rủi ro là những điều nhận

diện ra trong đơn hàng sản phẩm chưa làm xong mà tổ phải

giảm nhẹ. Scrum cho phép tổ dự án xác định khi nào hệ thống

259

là "đủ tốt" để được đưa ra cho khách hàng. Với Scrum, mọi dự

án tiến triển qua một chuỗi lặp, thường có chiều dài bốn tuần,

có tên là “Sprints - chạy nước rút” (thời hạn ngắn). Ở lúc bắt

đầu của từng đợt chạy nước rút - Sprint, cuộc họp lập kế hoạch

Sprint được tổ chức trong đó người chủ sản phẩm lập ưu tiên

hoá đơn hàng chưa hoàn thành và tổ lựa ra các nhiệm vụ họ có

thể hoàn thành bên trong việc chạy nước rút đó. Những nhiệm

vụ này rồi được chuyển từ đơn hàng sản phẩm chưa xong sang

Sprint chưa xong. Mỗi ngày cuộc họp hàng ngày có tên là chạy

nước rút hàng ngày - Daily Scrum - đều được tổ chức, để nhận

diện hoạt động nào đã được hoàn thành và hoạt động nào

không phải được hoàn thành vào ngày đó. Loại họp này tạo ra

việc thấy được công việc của từng cá nhân để tạo điều kiện cho

chia sẻ tri thức, giảm nhiệm vụ trùng lặp, và đảm bảo rằng

công việc của họ được hoàn toàn tích hợp. Đến cuối của từng

việc chạy nước rút - Sprint, tiến hành đề mô chức năng đã hoàn

thành tại cuộc họp kiểm điểm chạy nước rút Sprint. Bằng việc

có nhiều phần chạy nước rút, tổ dự án có thể xây dựng phần

mềm trong thời hạn ngắn tăng dần với sự linh hoạt và mau lẹ

(Agile).

Qui trình Scrum bao gồm bốn hoạt động: Lập kế hoạch

chạy nước rút - Sprint, Scrum hàng ngày, Kiểm điểm việc chạy

nước rút Sprint, và Hồi tưởng việc chạy nước rút Sprint.

1) Lập kế hoạch chạy nước rút Sprint

Chuẩn bị cho chạy nước rút bắt đầu khi Người chủ sản

phẩm xây dựng kế hoạch sản phẩm. Người chủ sản phẩm phải

có tầm nhìn về sản phẩm và có khả năng chia nhỏ sản phẩm

thành những mảnh nhỏ tương ứng với bản kế hoạch có nhiều

lần đưa ra, mỗi lần tập trung vào tính năng nào đó. Người chủ

sản phẩm chuẩn bị phần đơn hàng chưa thực hiện của sản

phẩm, danh sách các tính năng được khách hàng ưu tiên.

260

Scrum bắt đầu với người chủ sản phẩm kiểm điểm lại

tầm nhìn, kế hoạch, lịch biểu đưa ra, và đơn hàng chưa thực

hiện của sản phẩm cùng tổ. Tổ kiểm điểm lại các ước lượng về

tính năng theo các phần đơn hàng chưa thực hiện của sản phẩm

và quyết định bao nhiêu công việc nó có thể nhận trong việc

chạy nước rút dựa trên kích cỡ tổ, giờ sẵn có, và mức độ tri

thức chuyên gia của tổ. Tổ kéo các khoản mục từ đơn hàng

chưa thực hiện của sản phẩm mà họ có thể làm trong phạm vi

nước rút ba mươi ngày vào trong đơn hàng chưa thực hiện của

kì nước rút này rồi người chủ Scrum lãnh đạo tổ trong phiên

lập kế hoạch để chia các tính năng này thành các nhiệm vụ

nước rút. Đây là những hoạt động phát triển đặc biệt được yêu

cầu để thực hiện một tính năng cho đợt nước rút.

2) Scrum hàng ngày

Một khi lập kế hoạch được hoàn tất, Sprint bắt đầu vòng

lặp của nó. Từng ngày người chủ Scrum lãnh đạo tổ trong cuộc

họp Scrum hàng ngày. Scrum hàng ngày là cuộc họp ngắn

được thiết kế để làm sáng tỏ trạng thái của Scrum. Từng thành

viên tổ đáp ứng cho ba câu hỏi: 1) Bạn đã làm gì kể từ cuộc

họp Scrum trước? 2) Bạn lập kế hoạch làm gì hôm nay? 3) Có

chướng ngại nào ngăn cản bạn thực hiện công việc bạn lên kế

hoạch làm hôm nay không? Mục đích là để có được trạng thái

của dự án, khám phá ra vấn đề mới, đề cập tới nhu cầu cá nhân

của thành viên tổ, và điều chỉnh kế hoạch theo thời gian thực

theo nhu cầu của ngày.

3) Hồi tưởng về đợt chạy nước rút

Cuộc họp này được tổ tham dự cùng người chủ Scrum,

và người chủ sản phẩm. Cuộc họp này bắt đầu với tất cả các

thành viên tổ đều trả lời cho hai câu hỏi: 1) Cái gì diễn ra tốt

trong kì chạy nước rút vừa rồi? 2) Cái gì có thể được cải tiến

trong việc chạy nước rút vừa rồi? Người chủ Scrum làm tài liệu

về câu trả lời của tổ dưới dạng tóm tắt, và tổ ưu tiên hoá thứ tự

261

nó muốn nói tới về cải tiến tiềm năng. Người chủ Scrum tạo

điều kiện thuận tiện cho việc tìm kiếm của tổ để cải tiến các cơ

hội cho các qui trình Scrum, nhận diện hành động có thể được

bổ sung cho việc chạy nước rút tiếp để cải tiến.

4) Họp kiểm điểm chạy nước rút

Họp kiểm điểm được tổ chức ở cuối kì chạy nước rút.

Phần đầu là đề mô cho người chủ sản phẩm về mã đã được phát

triển trong kì chạy nước rút. Người chủ sản phẩm cũng mời

khách hàng tới dự và xác định tính năng nào trên đơn hàng

chưa thực hiện của sản phẩm đã được hoàn thành trong đợt

chạy nước rút Sprint này. Khách hàng, người chủ sản phẩm,

người chủ Scrum cũng thảo luận về cách đặt ưu tiên lại cho

đơn hàng chưa thực hiện của sản phẩm cho lần chạy nước rút

tiếp. Thế rồi mục đích cho sprint tiếp được xác định và thảo

luận về cách tổ sẽ làm việc cùng nhau trong kì chạy nước rút

tiếp. Sau cuộc họp kiểm điểm này, qui trình lại bắt đầu với việc

chạy nước rút khác cho tới khi tất cả các tính năng đã được

thực hiện để hoàn thành sản phẩm.

262

263

6. Dự án Capstone

Dự án Capstone

Dự án Capstone là nơi tri thức hàn lâm gặp gỡ với thực

tại công nghiệp. Mục đích của capstone là áp dụng tri thức thu

được trong trường và biến nó thành kĩ năng đáp ứng cho nhu

cầu công nghiệp. Dự án Capstone là cách sinh viên chứng minh

rằng chúng ta đã đáp ứng cho mục đích này. Về căn bản, dự án

Capstone là dự án hàn lâm trong đó sinh viên có xấp xỉ sáu

tháng để hoàn thành trong năm cuối ở trường. Nó là bước cuối

cùng trong quá trình bằng cấp nơi sinh viên làm việc trong tổ

trong một dự án do khách hàng trao, thường là một công ti

phần mềm. Kết quả của dự án Capstone phải được trình bày

dưới dạng báo cáo viết trước cả khách hàng và các thầy trong

khoa.

Tuần trước một sinh viên tới tôi và phàn nàn về dự án

capstone của anh ta. Tổ của anh ta đang phát triển một website

cho khách hàng và anh ta đã làm việc vất vả để làm cho

website trông xinh xắn. Anh ta đưa nhiều công trình nghệ thuật

với những bức ảnh đẹp vào nhưng khách hàng và bạn trong tổ

không quan tâm gì mấy. Anh ta nói: “Em đã làm việc vất vả và

để nhiều thời gian nhưng tổ không đánh giá cao nỗ lực của em

264

chút nào. Khách hàng không chú ý tới công việc của em và

chẳng bao giờ ca ngợi em trong cuộc kiểm điểm nên em rất thất

vọng.”

Tôi hỏi: “Yêu cầu của khách hàng là gì cho website đó?

Ảnh đẹp có phải là yêu cầu không? Hoạt hình nghệ thuật có là

nhu cầu không? Khách hàng có bảo bạn đưa chúng vào không?

Tổ có phân công nhiệm vụ đó cho bạn không?"

Anh ta dường như ngạc nhiên: “Không nó không phải là

yêu cầu, tổ đã không đòi hỏi em làm điều đó nhưng em đã

quyết định đằng nào cũng phải làm nó. Nó sẽ làm cho website

đẹp hơn chứ.”

Tôi giải thích: “Có các yêu cầu khác mà tổ đang làm việc

nhưng bạn đã dành thời gian cho cái gì đó khác. Cái gì đó thậm

chí không có trong đặc tả yêu cầu. Bạn đang làm cái gì đó thêm

và trong con mắt của các thành viên của tổ bạn, bạn đang phí

nhiều thời gian vì bạn có thể làm cái gì đó hữu dụng hơn cho

tổ. Bạn nên thảo luận với tổ của bạn về phân công việc của bạn

thay vì làm cái gì đó vì bạn thích làm. Điều then chốt của làm

việc tổ là viễn kiến chung, trách nhiệm và lịch biểu chung.

Người lãnh đạo tổ quyết định nhiệm vụ nào đi với thành viên

nào và từng người phải thực hiện nhiệm vụ của họ tương ứng

với lịch biểu. Trong trường hợp của bạn, bạn đang làm cái gì

đó theo cách riêng của bạn và không tuân theo nhiệm vụ được

phân công. Bạn không nói với tổ của bạn mà tự đặt ra nhiệm vụ

riêng của bạn, bạn muốn đòi công lao riêng của bạn, bạn muốn

là anh hùng. Về căn bản bạn không phải là một phần của tổ và

phí tài nguyên tổ vào nhiệm vụ không cần thiết. Bằng việc tự

mình xem xét mình là trường hợp đặc biệt, bạn muốn làm việc

một mình. Điều đó là không chấp nhận được trong môi trường

tổ.”

265

Anh ta nói: “Nhưng em nghĩ điều đó sẽ làm cho dự án

capstone thành công. Không có ảnh của em, website trông xấu

và không hấp dẫn chút nào.”

Tôi giải thích: “Đó là cái gì đó để khách hàng đánh giá

chứ. Không phải việc của bạn. Với dự án phần mềm, tập trung

là vào đáp ứng nhu cầu của khách hàng. Dự án capstone được

thiết kế cho sinh viên học về môi trường làm việc thực. Trong

dự án capstone, điều đầu tiên bạn học là làm việc tổ cho nên

nghĩ rằng bằng cách làm việc một mình, tạo ra cái gì đó lớn lao

không có tác dụng ở đây. Điều bạn có thể coi là xinh xắn cho

bạn nhưng không thế cho khách hàng, ông ấy có thể không

quan tâm tới liệu nó đẹp hay không. Ông ấy chỉ quan tâm liệu

nó làm việc không, liệu nó có đáp ứng nhu cầu của ông ấy

không. Đó là lí do tại sao trong cuộc kiểm điểm, ông ấy không

bao giờ chú ý tới ảnh nghệ thuật của bạn. Bạn chỉ có vài tháng

còn lại trước khi tốt nghiệp, bạn phải học nhiều về làm việc tổ

bởi vì trong công việc thực, đặc biệt trong công nghiệp phần

mềm, không ai làm việc một mình. Tổ bao giờ cũng làm việc

theo nhất trí, bằng việc chia sẻ tải việc, bằng việc chia sẻ trách

nhiệm. Trong công việc tổ không có cá nhân, không có anh

hùng, chỉ có tổ. Hoặc tổ thành công hoặc tổ thất bại. Vì bạn vẫn

trong trường, bạn có thể phạm sai lầm và tôi thà để bạn phạm

sai lầm trong trường hơn là trong việc làm của bạn. Đó là lí do

tại sao chúng ta có Capstone."

Anh ta nghĩ một chốc nhưng hỏi: "Nếu em tin rằng ảnh

và đồ hoạ của em có thể giúp cho website trông hay hơn, làm

sao em thuyết phục được tổ rằng em làm cái gì đó tốt cho họ?"

Tôi giải thích: “Trong trường hợp đó, em nên nói chuyện

với khách hàng về quan điểm của em với website, nó đại diện

cho cái gì, hình ảnh nó biểu lộ về công ti và xem họ nghĩ gì.

Khách hàng sẽ quyết định liệu ảnh nghệ thuật của em là cần

hay không. Chính khách hàng ra quyết định cuối cùng. Nếu

266

ông ấy đồng ý thì đó là yêu cầu mới. Nếu ông ấy không quan

tâm, bạn phải dừng lại và làm nhiệm vụ được phân công của

bạn. Trong làm việc tổ, điều tốt nhất là thảo luận với tổ và xin

phép thay vì cứ làm cái gì đó mà không có nhất trí của tổ.”

Hướng dẫn dự án Capstone - phần 1

Nhiều sinh viên đã viết cho tôi hỏi xin giúp đỡ về dự án

Capstone của họ. Vì đây là dự án "thực" đầu tiên, nhiều người

lo lắng và không chắc về phải làm gì. Dựa trên yêu cầu của họ,

tôi đã viết bản hướng dẫn tóm tắt cho dự án Capstone dựa trên

điều tôi đã dạy ở Carnegie Mellon (mỗi trường có thể khác) mà

một số trong các bạn có thể thấy nó là hữu dụng:

Dự án Capstone được thiết kế để giúp cho sinh viên kinh

nghiệm việc phát triển phần mềm "thế giới thực". Qua vài

tháng tiếp, tổ của bạn sẽ thiết kế và xây dựng sản phẩm phần

mềm bằng việc dùng tri thức bạn đã học trong ba năm quá khứ

trong trường. Đây là cơ hội cho bạn áp dụng tri thức của bạn và

chuyển nó thành kĩ năng "thực". Bằng việc tuân theo hướng

dẫn này, bạn sẽ học các kinh nghiệm có giá trị trong làm việc

tổ, giải quyết vấn đề, qui trình phần mềm, và quản lí dự án.

Đây là những kĩ năng mà công nghiệp phần mềm cần và mong

đợi người tốt nghiệp biết.

Ngày nay phát triển phần mềm vẫn còn có vấn đề. Nhiều

dự án không đáp ứng lịch biểu của chúng. Ngay cả khi được

chuyển giao, nhiều sản phẩm phần mềm chưa bao giờ được

dùng vì chất lượng thấp. Điều đáng quan tâm là các dự án này

không thất bại bởi vì các lí do kĩ thuật mà chúng thất bại do

quản lí dự án kém và làm việc tổ không hiệu quả. Nói cách

khác, chúng thất bại do các lí do có liên quan tới "qui trình"

hơn là "công nghệ". Đó là lí do tại sao trong các dự án

267

Capstone, điều quan trọng nhất mà sinh viên phải học là "làm

việc tổ" và "qui trình" như lập kế hoạch, quản lí và thực hiện

dự án phần mềm.

Phát triển phần mềm là hoạt động phức tạp. Mặc dầu các

ngôn ngữ lập trình và công cụ cho phép người phát triển viết

nhiều mã nhanh hơn, nhưng viết mã chỉ đại diện cho một phần

nhỏ của hoạt động phát triển phần mềm. Học về phát triển phần

mềm hiệu quả, tổ của bạn phải tuân theo cách tiếp cận vòng đời

phần mềm và tạo ra một loạt các tài liệu. Tổ của bạn được yêu

cầu đệ trình các báo cáo pha dự án được viết ra trong toàn thể

dự án capstone. Các báo cáo này được dùng để làm tài liệu cho

tiến bộ của tổ và để nhận diện các vấn đề mà tổ tìm ra. Các báo

cáo này là công cụ có giá trị cho quản lí dự án và tự đánh giá

của tổ. Chúng cũng cung cấp cho giáo sư của bạn các thông tin

họ cần để đánh giá hiệu năng của tổ và cung cấp hướng dẫn

cho tổ trong dự án Capstone project.

Trước khi bạn bắt đầu, có vài điều bạn cần biết: Bạn phải

KHÔNG BAO GIỜ nhảy vào viết mã như bạn nghĩ bạn có thể

làm. Đây là vấn đề thông thường trong các sinh viên. Nhiều

người nghĩ họ đã biết về giải pháp cho nên họ bắt đầu viết mã

ngay. Đó là lí do tại sao nhiều dự án Capstone thất bại. Xin nhớ

cho rằng dự án Capstone KHÔNG phải là phân công nhiệm vụ

trong lớp lập trình. Bạn không học về Java, PHP, hay C++ ở

đây. Bạn đã học chúng trong các năm trước và không cần lặp

lại ở đây. Dự án Capstone là về thực hiện vòng đời phát triển

phần mềm. Nó sẽ giúp bạn hiểu mọi bước cần thiết để xây

dựng chất lượng của sản phẩm phần mềm. Xin nhớ cho rằng

viết mã chiếm ít hơn 20% của mọi công việc được cần tới trong

dự án phần mềm điển hình. Không dự án nào đã bao giờ thất

bại vì viết mã nhưng bởi vì mọi người KHÔNG tuân theo qui

trình. Cho nên bạn phải học về qui trình phần mềm và không

bỏ qua bất kì bước nào. Một khi bạn học mọi bước này, bạn

268

cũng phát triển kĩ năng phát triển riêng của bạn và do đó không

có vấn đề gì khi làm việc trong công nghiệp phần mềm.

Phần lớn các dự án Capstone được trao cho bạn bởi các

công ti bên ngoài (khách hàng) trong cộng tác với đại học của

bạn. Về truyền thống, khách hàng cho đại học của bạn bản đặc

tả yêu cầu phần mềm (SRS) cho dự án Capstone. Phần lớn thời

gian, yêu cầu là mông lung và không được xác định rõ (Tất

nhiên, nó là được dự định cho bạn học về phân tích yêu cầu).

Như một tổ, bạn phải kiểm điểm yêu cầu một cách cẩn thận để

nhận diện từng cấu phần hệ thống và chức năng. Tổ của bạn

phải hiểu điều khách hàng (công ti phần mềm bên ngoài) muốn

tổ thực hiện. Tất nhiên, bạn phải biết cái gì đó về khách hàng.

Bước đầu tiên là tổ viết ra phát biểu ngắn mô tả công việc của

khách hàng của bạn và cách họ vận hành như họ là ai, họ làm

gì v.v. (Bạn học về kinh doanh của họ). Sau đó, bạn phải phỏng

vấn khách hàng để hiểu sản phẩm và dịch vụ của họ. Bạn muốn

biết cách họ làm công việc, cách họ giải quyết thông tin, cách

họ phát triển phần mềm (bạn học về qui trình công việc của

họ). Bạn phải kiểm điểm công nghệ họ dùng để hiểu nhu cầu

của họ và các lí do tại sao họ muốn tổ của bạn làm việc trên dự

án này. Bằng việc hỏi họ, thảo luận với họ tổ của bạn sẽ biết

nhiều thêm về qui trình của khách hàng và yêu cầu của họ (Xin

ôn lại tài liệu của lớp kĩ nghệ yêu cầu).

Một khi tổ của bạn biết lí do và yêu cầu của khách hàng,

bạn có thể bắt đầu viết ra phát biểu viễn kiến mô tả dự án

capstone bằng những cấu phần hệ thống riêng mà tổ bạn phải

phát triển để đáp ứng cho nhu cầu của khách hàng. Bạn có thể

không có khả năng đáp ứng được tất cả mọi yêu cầu mà khách

hàng đã trao cho đại học của bạn, cho nên giới hạn viễn kiến

của bạn vào các cấu phần khả thi và hữu dụng. (Đây là "thủ

đoạn" thông thường trong các dự án Capstone, vì khách hàng

bao giờ cũng đòi hỏi nhiều cho nên bạn phải áp dụng kĩ năng

phân tích và thương lượng ở đây - Đây là chỗ bạn cũng học kĩ

269

năng mềm: Kĩ năng thương lượng). Bạn phải giải thích cho

khách hàng của bạn rằng tổ của bạn muốn nhận diện vấn đề,

hay nhu cầu mà dự án Capstone của bạn sẽ giải quyết cho

khách hàng. Bạn phải nhận diện khách hàng và người dùng của

hệ thống được đề nghị và cách sản phẩm mà tổ bạn dựng có thể

giúp cho họ. (Đây là phần mấu chốt của mọi dự án phần mềm.

Tổ của bạn phải có khả năng thuyết phục khách hàng xác định

phạm vi của dự án và giới hạn các yêu cầu vào cái gì đó mà tổ

của bạn có thể thực hiện được trong thời gian hợp lí. Kĩ năng

thương thảo của bạn là rất quan trọng ở đây).

Vì khách hàng có thể không quen thuộc với điều bạn đề

nghị (họ bao giờ cũng nói rằng họ không hiểu thuật ngữ kĩ

thuật), tổ của bạn phải tạo ra tập các biểu đồ use case trường

hợp sử dụng (chỉ ra các tác nhân, qui trình, biên hệ thống) cho

hệ thống. Phải chắc đưa vào các chức năng quản trị bản chất

trong biểu đồ của bạn. Viết lời dẫn tóm tắt cho từng use case

với việc giải thích use case đó. Chỉ ra mức ưu tiên của các use

case như # 1 cho use case bản chất đối với vận hành hệ thống;

# 2 cho use case là không bản chất với vận hành hệ thống

nhưng sẽ tăng thêm giá trị đáng kể cho người dùng hệ thống;

và # 3 cho use case sẽ thêm một số giá trị nhỏ cho người dùng

hệ thống. Mô tả vắn tắt mọi tác nhân (người dùng, hệ thống

hay tổ chức) những người tương tác với hệ thống của bạn, như

được chỉ ra trong biểu đồ của bạn. Đừng giả định rằng nghĩa

của bất kì use case, tác nhân, hay chức năng nào bị bỏ qua cho

khách hàng của bạn; mô tả của bạn phải rất rõ ràng và không

nhập nhằng. (Xin ôn lại tài liệu lớp yêu cầu về chỉ dẫn cách

thực hiện điều đó).

Bằng việc dùng các kịch bản use-case, tổ của bạn sẽ hiểu

nhiều hơn về các yêu cầu chức năng của dự án Capstone. Nó

cũng làm cho mọi cấu phần được đề nghị thành thấy được

nhiều hơn đối với khách hàng của bạn khi bạn thương lượng và

thảo luận với họ về phạm vi của dự án. (Cái gì cần giữ và cái gì

270

không cần giữ trong thương lượng). Tổ phải kiểm điểm phạm

vi và độ phức tạp của hệ thống được đề nghị của bạn và ước

lượng công việc tham gia vào đó. (Đây là chỗ công việc tổ

thành rất mấu chốt vì bạn thảo luận với từng thành viên tổ về

thời gian và nỗ lực cần dành ra để hoàn thành các nhiệm vụ

này. Nhớ rằng đây chỉ là ước lượng sơ khởi, mọi người đều có

ý kiến riêng của họ, tổ phải học cách cộng tác để đi tới ước

lượng hợp lí.)

Từng thành viên tổ phải ước lượng nỗ lực được cần tới

(theo man-hours), để hoàn thành các pha phân tích yêu cầu và

thiết kế của dự án. Họ phải giải thích cách ước lượng của họ

được suy ra cho các thành viên tổ khác để cho cùng nhau họ có

thể đi tới ước lượng toàn thể của cả tổ. (Có thể làm ước lượng

trung bình ở đây, nếu một nửa tổ đi tới 100 man-hours và nửa

kia ước lượng 200 man-hours thì bạn có thể đồng ý điều chỉnh

ước lượng tổng thể là 150 giờ).

Từng thành viên tổ phải ước lượng nỗ lực được cần tới

(theo man-hours), để làm các pha xây dựng và kiểm thử của dự

án. Họ có thể ước lượng nỗ lực để thực hiện điểm use case cho

cả # 1 (ưu tiên cao) và # 2 (ưu tiên trung bình) nhưng không

thể làm cho # 3 vì điều này nên có tính thương lượng với khách

hàng hay liệu họ có muốn tổ làm điều đó không. Dùng thông

tin này để ước lượng nỗ lực toàn bộ được yêu cầu để hoàn

thành cả hai kiểu use case. Thành viên tổ phải giải thích được

cách họ làm ước lượng. (Nhớ rằng bạn phải xem xét tới các

ước lượng từ từng thành viên tổ rồi thảo luận để có sự thoả

thuận của tổ về ước lượng toàn thể. Bạn sẽ học nhiều về làm

việc tổ trong hoạt động này.)

Từng thành viên tổ phải ước lượng "hoạt động nỗ lực hỗ

trợ" được yêu cầu cho việc quản lí dự án, họp, viết, kiểm điểm,

báo cáo, làm tài liệu, viết mã và kiểm điểm thiết kế, tích hợp và

kiểm thử mức hệ thống, các kĩ năng học và kĩ năng phát triển

271

khác như học công nghệ mới, hoạt động đảm bảo chất lượng

QA và các qui trình khác hay các vấn đề quản lí qui trình có

liên quan tới dự án của bạn hay tổ của bạn. (Đây là lí do tại sao

nhiều dự án phần mềm thất bại bởi vì nhiều người quản lí dự án

quên tính tới những nỗ lực hỗ trợ này vì họ chỉ làm ước lượng

về khía cạnh kĩ thuật mà không có khía cạnh hỗ trợ. Đó là lí do

tại sao nhiều dự án đã không đáp ứng lịch biểu.)

Tổ phải trình bày phân tích yêu cầu và các ước lượng dự

án (Đây vẫn là ước lượng sơ khởi vì phạm vi vẫn còn đang

được thương lượng với khách hàng). Bạn phải làm tài liệu cho

những hoạt động này và có khả năng giải thích cho khách hàng

và giáo sư của bạn trong bài trình bày dưới dạng họ có thể hiểu

được. Bạn phải nói rõ ràng và biện minh cho bất kì giả định

nào bạn đã làm trong ước lượng của bạn. Dựa trên ước lượng

nỗ lực của bạn (theo Man-hours), bạn phải giải thích chính xác

trường hợp sử dụng use case nào mà tổ của bạn sẽ thực hiện

cho dự án này cũng như ước lượng về tổng nỗ lực công việc

theo thời gian lịch biểu nhà trường. Tất nhiên bạn phải giải

thích các lí do của bạn tại sao tổ của bạn ra quyết định đó (Hoạt

động này sẽ giúp cho bạn học kĩ năng trình bày, kĩ năng thương

lượng, kĩ năng cộng tác, và kĩ năng lắng nghe – những kĩ năng

mềm này là bản chất trong công nghiệp phần mềm). Tất nhiên

khách hàng có thể không đồng ý (Họ bao giờ cũng làm điều đó

trong mọi dự án Capstone vì họ muốn thấy thêm về kĩ năng

mềm của bạn. Bạn cần thuyết phục họ bằng việc có các lập

luận rõ ràng và logic như ưu tiên, ích lợi và lịch biểu. Đến cuối,

phần lớn thời gian khách hàng đồng ý để cho bạn thực hiện mọi

# 1 (ưu tiên cao) và # 2 (ưu tiên vừa) vì lịch biểu nhà trường

cho phép.)

Đây là pha đầu của Capstone thường mất ít nhất một

tháng (4 tuần) để hoàn thành. Nó yêu cầu tri thức về phân tích

yêu cầu, biểu đồ trường hợp sử dụng use case, ước lượng, vòng

đời phát triển phần mềm, lập kế hoạch dự án và kĩ năng mềm.

272

Hướng dẫn dự án Capstone - phần 2

Capstone là dự án "thực" được công ti trong công nghiệp

trao cho sinh viên đại học khi họ ở năm cuối trong trường. Mục

đích chính là để giúp cho sinh viên học mọi kĩ năng họ cần làm

tốt khi họ làm việc trong công nghiệp phần mềm. Trong những

kĩ năng này, làm việc tổ là kĩ năng quan trọng nhất. Mọi dự án

trong công nghiệp đều là công việc tổ cho nên làm sao sinh

viên học được cách làm việc cùng nhau là rất quan trọng cho

thành công của họ về sau trong cuộc sống.

Một trong những hoạt động đầu tiên trong dự án

Capstone là kĩ năng kiểm điểm của từng thành viên để nhận

diện cách từng người có thể đóng góp tốt nhất cho dự án. Cùng

nhau tổ phải xác định vai trò, trách nhiệm cho từng thành viên

tổ. Trong khi không ai trong tổ là "ông chủ", vai trò của người

quản lí dự án được cần tới để phối hợp, lập kế hoạch, và theo

dõi dấu vết các hoạt động của tổ. Người quản lí dự án (PM) giữ

cho tổ được hội tụ và đảm bảo rằng công việc được thực hiện

đúng thời gian. PM phải kiểm điểm công việc của từng thành

viên, để chắc rằng họ đáp ứng yêu cầu và chất lượng. PM làm

việc chặt chẽ với mọi thành viên tổ để giám sát các hoạt động

của tổ và đảm bảo rằng các cuộc họp của tổ là hiệu quả và hiệu

lực. PM cũng xác định, thu thập và phân tích độ đo dự án để

chắc chất lượng và hiệu năng của dự án đáp ứng mong đợi của

khách hàng. PM phải chắc rằng mọi phần mềm được tổ phát

triển đều được kiểm thử kĩ lưỡng và được làm tài liệu. Đây là

vai trò quan trọng nhất trong dự án Capstone cho nên tổ phải

lựa chọn người có kĩ năng nhất cho vai trò này (Lưu ý: Đôi khi

vai trò này có thể được quay vòng cho từng pha phát triển cho

nên mọi người sẽ có cơ hội để làm nó).

273

Bên cạnh người quản lí dự án PM, có các vai trò khác mà

các thành viên tổ cũng phải nhận diện như người quản lí cấu

hình (SCM), người đảm bảo chất lượng phần mềm (SQA),

người quản lí kiểm thử v.v.. Vì có nhiều pha phát triển, các

thành viên tổ có thể lần lượt chuyển các vai trò cho nhau qua

từng pha. Chẳng hạn, thành viên này giả định giữ vai trò SQA

trong pha thiết kế rồi chuyển cho người khác làm SQA trong

pha tiếp (Lưu ý: Đây là bài tập tốt trong làm việc tổ, sinh viên

phải làm việc cùng nhau và chia sẻ trách nhiệm. Cách họ làm

việc cùng nhau, cách họ phân phối công việc trong tổ sẽ xác

định liệu dự án Capstone sẽ thành công hay không). Thỉnh

thoảng, sinh viên không đồng ý lẫn nhau thì giáo sư phải bước

vào và phân công vai trò cho từng thành viên. Trong trường

hợp đó, điều đó rõ ràng là một chỉ báo rằng mọi thành viên đã

không học được về làm việc tổ và điều đó có thể là rủi ro

chính. Giáo sư phải nhắc nhở sinh viên về quyết tâm của họ với

làm việc theo tổ. Thỉnh thoảng, có những kĩ năng mà tổ cần

nhưng không có. Trong trường hợp đó giáo sư có thể phân

công cho các thành viên tổ học những kĩ năng này. (Chẳng hạn,

tổ quyết định dùng cách tiếp cận mau lẹ agile nhưng họ không

có kĩ năng của thầy Scrum cho nên ai đó phải học kĩ năng này

để thực hiện vai trò này.)

Tổ phải quyết định về số giờ mà họ phải làm việc cùng

nhau như một tổ. Bởi vì các thành viên có thể có những giới

hạn nào đó (một số có thể không có khả năng làm việc vào

ngày nào đó, giờ nào đó, bởi vì có giờ trên lớp, hỗ trợ gia đình,

hay các vấn đề khác liên quan tới tính sẵn có của họ). PM phải

làm việc cùng tổ để tạo ra "lịch biểu tổ" để đặt ra thời gian mà

tổ làm việc cùng nhau. Các thành viên tổ phải "đi làm" đúng

giờ. Thỉnh thoảng việc vắng mặt trong công việc tổ là vấn đề.

PM và tổ phải nhắc nhở các thành viên vắng mặt về cam kết

với dự án. Nếu điều đó tiếp tục, PM phải báo cáo cho giáo sư.

Trong trường hợp đó, sinh viên vắng mặt phải bị quản chế. Nếu

274

vi phạm việc quản chế, sinh viên đó phải bị yêu cầu ra khỏi dự

án (Điều này nghĩa là thất bại của lớp này. Không sinh viên nào

có thể tốt nghiệp mà không hoàn thành dự án Capstone).

Trong các năm học, sinh viên làm việc trong tổ cho nên

họ nên hiểu cách làm việc tổ. Tuy nhiên, dự án Capstone là lần

đầu tiên nhiều người làm việc trên dự án "thực" cho nên điều

quan trọng với họ là học cách xây dựng tổ hiệu quả. Thuộc vào

một tổ là kết quả của phần tình cảm nhiều hơn bản thân bạn.

Sinh viên phải học cách gạt sang bên bản ngã cá nhân của họ,

quyền lợi riêng của họ, và làm việc hướng tới mục đích chung.

Trong dự án Capstone, mọi thành viên phải đóng góp cho

thành công của dự án. Họ phải tạo ra kết quả. Lúc bắt đầu dự

án Capstone, giáo sư đặt những mong đợi và mục đích nào đó

cho tổ nhưng từng thành viên cần hiểu tại sao họ phải làm việc

như một tổ chứ không như cá nhân. Họ phải hiểu rằng đây là

đào tạo cuối cùng của họ có tổ hợp mọi tri thức mà họ đã học

trong ba năm trước và áp dụng vào dự án "thực". Đây là cơ hội

cho họ học để chuyển tri thức hàn lâm thành kĩ năng "thực".

Do đó, họ phải hiểu tầm quan trọng của hoạt động này và quyết

tâm hoàn thành nó.

Sau khi các thành viên tổ đã đồng ý về vai trò và trách

nhiệm của họ, tổ phải đánh giá tính khả thi về năng lực của nó

để xây dựng sản phẩm phần mềm. Tổ có thể hoàn thành được

dự án trong lịch biểu năm học của trường không? Dự án có thể

thành công không? Có rủi ro hay khó khăn nào của dự án? Các

thành viên tổ phải tự hỏi họ: “Chúng ta có người đúng trong dự

án này không?" Các thành viên tổ có tri thức và kĩ năng để

hoàn thành dự án này không? Nếu không, tổ đi đâu để có được

sự giúp đỡ mà nó cần? Tổ có cảm thấy nó có sự hỗ trợ được

cần tới để hoàn thành mục đích của nó không? Tổ có viễn kiến

rõ ràng về sản phẩm và kế hoạch để hoàn thành dự án không?

Tổ có xác định được mục đích của dự án, kết quả của nó, thời

gian của nó không? Nó đo thế nào cho cả kết quả công việc của

275

nó và qui trình tổ đi theo để hoàn thành nhiệm vụ của họ? Các

thành viên tổ có hiểu vai trò và trách nhiệm của họ rõ không?

Mối quan hệ và tính đảm nhiệm của tổ có được mọi thành viên

hiểu không? Có qui trình được xác định để cho các thành viên

tổ có thể tuân theo một cách nhất quán không? Các thành viên

tổ có giữ tính đảm nhiệm lẫn nhau, quyết tâm và kết quả cho

thời gian dự án không? Tổ có thiết lập các qui tắc ứng xử trong

khu vực như giải quyết xung đột, ra quyết định và quản lí họp

không? Các thành viên tổ có rõ ràng về ưu tiên của các nhiệm

vụ của họ không? Các thành viên tổ có trao đổi rõ ràng và

trung thực với nhau không? Các thành viên tổ có cảm thấy

trách nhiệm và tính đảm nhiệm cho thành tựu của tổ không?

Nếu tổ là trung thực với nhau và có câu trả lời tích cực

cho những câu hỏi này thì họ có thể bắt đầu dự án Capstone.

Nếu họ vẫn có vấn đề hay câu hỏi thì họ phải thảo luận với

giáo sư để xin hướng dẫn đúng. Bất kì vấn đề nào không giải

quyết trước khi dự án bắt đầu có thể trở thành rủi ro và tác

động lên thành công của dự án.

Hướng dẫn dự án Capstone - phần 3

Trong dự án Capstone, người quản lí dự án (PM) phải giữ

dấu vết về cách các thành viên tổ dành thời gian của họ cho dự

án. Theo dõi thời gian là hoạt động quan trọng để giám sát

trách nhiệm cá nhân với dự án. Việc ghi thời gian cho phép PM

so sánh thời gian thực tế so với thời gian được lập kế hoạch của

từng thành viên. PM phải tóm tắt thời gian hàng tuần cho từng

thành viên và cho tổ để tìm ra tổ thực sự làm việc bao nhiêu

thời gian trên dự án. Bằng việc làm điều đó, PM có thể nhận

diện đóng góp của từng cá nhân cho công việc dự án trong từng

276

pha. (Lưu ý: người quản lí dự án phải báo cáo tính toán thời

gian cho giáo sư.)

Trước từng pha phát triển, PM phải chia sẻ thông tin với

các thành viên tổ liên quan tới số giờ thực tế mà họ dành cho

nhiệm vụ của họ. Dùng dữ liệu này, thành viên tổ có thể ước

lượng số giờ họ sẽ cần để hoàn thành nhiệm vụ tiếp. PM phải

phân công cho từng thành viên tổ một số nhiệm vụ để làm cũng

như ngày hoàn thành được mong đợi. Điều quan trọng là phân

công người dự phòng trong trường hợp một người không có

khả năng hoàn thành nhiệm vụ tương ứng. Bắt đầu từng pha

cũng là lúc chuyển vai trò và phân công cho nên mọi thành

viên đều có cơ hội thực hiện những vai trò nào đó. (Lưu ý: Nhớ

rằng vai trò tới cùng trách nhiệm và họ phải hoàn thành chúng.)

Tổ cũng phải định nghĩa tập các độ đo để đo tiến bộ của

tổ, năng suất và tính hiệu quả. Với từng độ đo, tổ phải chỉ ra

cách họ thu thập dữ liệu, ghi dữ liệu, và cách họ dùng những

dữ liệu này để ra quyết định. Tập các độ đo phải bao gồm cách

đo chất lượng sản phẩm (lỗi và tỉ lệ lỗi), trạng thái và tiến độ

dự án (ước lượng kích cỡ và nỗ lực so với thực tế), chất lượng

qui trình (khối lượng việc làm lại, cột mốc được thực hiện và bị

lỡ). Tổ phải phát triển một danh sách các rủi ro vì chúng là đe

doạ nghiêm trọng cho dự án như thiếu lịch biểu, thay đổi với

dự án v.v. Với từng dự án, tổ phải cung cấp một mô tả, và khả

năng có thể xuất hiện (thấp, vừa, cao), và chiến lược giảm thiểu

rủi ro. Quản lí rủi ro là kĩ năng quan trọng mà tổ phải học. (Lưu

ý: Rủi ro thông thường nhất trong dự án Capstone là thay đổi

trong yêu cầu. Trong dự án khách hàng thường làm điều đó để

xem cách tổ phản ứng. Tổ phải dự đoán những thay đổi này và

có kế hoạch giải quyết nó.)

Một khi khách hàng chấp thuận đề nghị của tổ về phạm

vi mới, tổ có thể bắt đầu dự án. Điều đầu tiên cần làm là sửa lại

bản đặc tả yêu cầu phần mềm (SRS) với phạm vi đã được chấp

277

thuận (Khử bỏ các yêu cầu ưu tiên thấp không cần thiết mà

khách hàng đã đồng ý hay thêm yêu cầu mới mà khách hàng đã

yêu cầu tổ đưa vào). Dự án Capstone bắt đầu với SRS mới làm

cơ sở cho mọi hoạt động dự án. Tổ cũng phải sửa lại và hiệu

chỉnh các biểu đồ trường hợp sử dụng use case và lời dẫn mà

họ đã làm trước đó và rót đầy những chi tiết còn thiếu và chỉ ra

mọi tiền điều kiện, hậu điều kiện và các bộ lẩy cò cho từng use

case.

Để nhận diện mọi nhiệm vụ phải được hoàn thành cho

từng pha, tổ phải phân rã công việc dự án thành một số các

nhiệm vụ và phân công chúng cho từng thành viên. Từ những

nhiệm vụ này, thành viên tổ có thể ước lượng nỗ lực của họ

(cần bao lâu để hoàn thành chúng) và tổ hợp vào lịch dự án

tổng thể. Vì không phải mọi nhiệm vụ đều có thể được làm

cùng lúc, một số nhiệm vụ phụ thuộc vào cái ra từ các nhiệm

vụ khác, tổ phải nhận diện sự phụ thuộc giữa các nhiệm vụ và

xây dựng trình tự có thứ tự các hoạt động thực hiện nhiệm vụ.

(Lưu ý: Đây là bài tập lặp, tổ không nên tìm sự hoàn hảo mà

chỉ cần biết từng nhiệm vụ trong đủ chi tiết để cho PM có thể

theo dõi và báo cáo về tiến độ của họ.)

Việc phân rã công việc (cấu trúc phân việc) thường phụ

thuộc vào phương pháp mà tổ dùng nhưng tổ phải thực tế về

việc xác định các nhiệm vụ này. Chẳng hạn một nhiệm vụ lớn

như "Phân tích vấn đề" hay “Thiết kế chức năng” là không thực

tế vì nó không đủ chi tiết cho ước lượng hay theo dõi. Chia

thành nhiệm vụ quá nhỏ có thể thành phân mảnh quá cũng

không có ích. Cách tốt nhất là cân nhắc một nhiệm vụ như cái

gì đó có thể hoàn thành trong vòng 32 giờ (Man-week) là cách

tốt nhất để xác định một nhiệm vụ, vì nó dễ cho theo dõi và đo.

Khi làm việc về lịch biểu toàn thể, tổ cũng phải xem xét các

nhiệm vụ liên quan tới các hoạt động hỗ trợ như SQA, SCM,

quản lí thay đổi cũng như bao gồm mọi nhiệm vụ liên quan tới

việc học công nghệ mới, quản trị máy phục vụ, công cụ mới

278

v.v.. Những nhiệm vụ hỗ trợ này thường bị quên mất hay

không được tính tới trong lịch biểu toàn thể và đó là lí do tại

sao nhiều dự án phần mềm bị chậm, lỡ lịch và chúng bị ước

lượng thấp.

Khi phân rã được hoàn thành, người quản lí kiểm thử và

thành viên tổ phải bắt đầu xây dựng một tập các trường hợp

kiểm thử cho phần mềm. Phải có tối thiếu một trường hợp kiểm

thử cho từng use case. Nhiều use case có thể yêu cầu nhiều

trường hợp kiểm thử. (Lưu ý: Trường hợp kiểm thử nên được

thực hiện ở cuối pha phân tích yêu cầu và đầu pha thiết kế để

nhận diện bất kì yêu cầu nào bị bỏ sót hay còn mơ hồ. Nếu bạn

không thể kiểm thử được cái gì đó điều đó nghĩa là yêu cầu của

bạn không rõ ràng hay kiểm thử được. Trong trường hợp đó tổ

nên quay lại và đề nghị khách hàng kiểm nghiệm. Mọi trường

hợp kiểm thử đều phải dùng một khuôn mẫu tương tự: với từng

trường hợp đều phải có mục đích kiểm thử, dữ liệu kiểm thử,

kết quả mong đợi, và ngày trường hợp kiểm thử được cho chạy

(và cho lại kết quả xác định) và tên của thành viên tổ tiến hành

kiểm thử).

Bên cạnh các chức năng được mô tả trong SRS, tổ phải

nhận diện các yêu cầu phi chức năng (thuộc tính chất lượng)

như an ninh, hiệu năng, tính truy nhập được, tính dễ dùng, tính

dễ học, tính bảo trì được, v.v.) vì sản phẩm phải thoả mãn các

ràng buộc vận hành thực tế (các cấu phần hệ điều hành, cơ sở

dữ liệu, phần cứng và phần mềm). PM phải chỉ ra cách những

yêu cầu phi chức năng này có thể được đáp ứng và bất kì hỗ trợ

bảo trì nào mà sản phẩm cần sau khi đưa ra cho khách hàng.

(Lưu ý: Đây là hoạt động nhiều tổ capstone không đạt tới. Mặc

dầu khách hàng không yêu cầu điều đó nhưng tổ dự án phải

thực hiện nó vì đó là mấu chốt cho vận hành và nó sẽ vượt quá

mong đợi của khách hàng và cho ấn tượng tích cực hơn cho tổ.)

279

Khi cả các nhiệm vụ chức năng và phi chức năng (thuộc

tính chất lượng) được thực hiện, tổ có thể bắt đầu làm việc trên

bản mẫu, hay hiển thị màn hình điều sẽ biểu diễn cách "nhìn và

cảm" của sản phẩm phần mềm như hiển thị menu chính của

mọi chức năng mà người dùng sẽ thấy khi đăng nhập. Tài liệu

thiết kế phải chỉ ra ít nhất vài trường hợp sử dụng use case khác

biệt (khác hơn đăng nhập/đăng xuất) trong chiều sâu đầy đủ.

Tổ phải kiểm điểm và biện minh bất kì vấn đề thiết kế nào hay

quyết định thiết kế còn chưa rõ vào lúc này. Nếu cần, PM phải

triệu tập cuộc họp với khách hàng để thẩm tra lại các yêu cầu.

(Lưu ý: Đây là lần đầu tiên khách hàng thấy việc biểu diễn thực

tế của công việc của tổ. Bản mẫu là quan trọng cần để thẩm tra

khái niệm vận hành mà tổ có. Sau khi kiểm điểm bản mẫu,

khách hàng thường đổi một số yêu cầu cho nên tổ phải được

chuẩn bị và không bị thất vọng. Chấp nhận thay đổi ở pha sớm

hơn là tốt hơn nhiều so với pha muộn hơn.)

Nếu có thay đổi, tổ phải quay lại cập nhật bản đặc tả yêu

cầu phần mềm (SRS) với những thay đổi mới cũng như mọi

use case và tài liệu bị ảnh hưởng. (Lưu ý: Nhiều dự án

Capstone không làm điều này và thường gặp khó khăn trong

pha kiểm thử và bảo trì về sau. Chính các thực hành rất tốt là

cập nhật mọi tài liệu ngay khi thay đổi xảy ra. Tổ phải làm việc

cùng nhau để vẽ ra các biểu đồ lớp chi tiết hay biểu đồ thực

thể-quan hệ. Họ phải chỉ ra mọi lớp, quan hệ, thuộc tính. Có

thể dùng kí pháp UML vì nó rất phổ biến trong hầu hết các dự

án toàn cầu. Tổ có thể tạo ra từ điển dữ liệu cho mọi thuộc tính

trong mô hình của bạn. Các mục từ phải được làm chi tiết,

chính xác và không nhập nhằng. Lưu tâm rằng các khái niệm

và thuộc tính bạn đang làm việc có các nghĩa hiển nhiên cho

bạn nhưng có thể không hiển nhiên cho người dùng.)

280

Hướng dẫn dự án Capstone - phần 4

Trong pha thiết kế và xây dựng, tổ phải đưa mọi nỗ lực

vào hoàn thành dự án trong hạn thời gian lịch biểu. Dùng danh

sách dãy các nhiệm vụ, các thành viên tổ có thể thiết kế và thực

hiện có trật tự các nhiệm vụ được phân công của họ tương ứng.

Điều được khuyến cáo là họ thực hiện các yếu tố giao diện

người dùng đồ hoạ (GUI) và các use case chủ yếu trước vì

chúng là hữu ích cho việc biểu diễn bản mẫu cho khách hàng

(Lưu ý: Vì từng dự án là khác nhau, chi tiết về bản mẫu có thể

cũng thay đổi. Giáo sư thường cho chỉ dẫn riêng trong những

dự án này.)

Với từng nhiệm vụ được thực hiện, người quản lí dự án

(PM) phải phân công trách nhiệm cho các thành viên tổ để

hoàn thành trong thời gian đã được lên lịch. Tổ phải tiến hành

các cuộc kiểm điểm thiết kế, kiểm điểm mã, và kiểm điểm kế

hoạch kiểm thử mọi lúc họ hoàn thành một chức năng chính để

chắc rằng mọi sự xảy ra theo trật tự và với chất lượng cao.

Ngay cả hai pha này (thiết kế và viết mã) cần được hiểu rõ bởi

các thành viên tổ, điều quan trọng là tổ phối hợp nhiệm vụ của

họ theo cách có nghĩa. PM phải không bao giờ cho phép bất kì

thành viên nào né tránh công việc này hay hoàn thành dự án

Capstone mà không có cơ hội phát triển kĩ năng này. (Lưu ý:

Một số thành viên không thích thiết kế hay viết mã cho nên họ

thường tình nguyện làm các hoạt động hỗ trợ như SQA, SCM

hay làm tài liệu.)

Các hoạt động thiết kế, viết mã và kiểm thử được yêu cầu

với mọi thành viên cho nên PM phải giám sát thời gian hàng

tuần dành cho từng thành viên và theo dõi thời gian của họ

dành cho từng hoạt động. Mục đích là để nhận diện bất kì thời

gian bất thường hay không mong đợi mà từng cá nhân đóng

góp cho công việc của toàn tổ. Các pha này thường là khu vực

có nhiều thứ xảy ra bất ngờ cho nên điều mấu chốt là giám sát

281

các hoạt động một cách cẩn thận. PM cũng phải kiểm tra bất kì

thay đổi nào với kế hoạch dự án gốc liên quan tới tính khả thi,

khó khăn và rủi ro của dự án về bất kì độ lệch nào khỏi kế

hoạch dự án (thực tế so với ước lượng).

Tổ nên có các cuộc họp hàng tuần để kiểm điểm lại tiến

độ của nó và ước lượng chi phí về chất lượng (COQ) như số

phần trăm nỗ lực trong pha này. COQ biếu thị cho chi phí đã

xảy ra do thiếu chất lượng và những chi phí đã xảy ra trong

việc đạt tới chất lượng. (Lưu ý: Chi phí của việc đạt tới chất

lượng và chi phí do thiếu chất lượng có mối quan hệ nghịch

đảo với nhau: khi đầu tư vào đạt tới chất lượng tăng lên, chi phí

do thiếu chất lượng giảm đi.) COQ chỉ báo mọi nỗ lực được

dành cho việc ngăn ngừa lỗi, nhận diện lỗi, và sửa lỗi. (Lưu ý:

Ngăn ngừa lỗi bao gồm nỗ lực để ngăn cản các khiếm khuyết

khỏi đưa vào dự án. Ngăn ngừa lỗi bao gồm mọi nỗ lực để

giám định thiết kế hay thảo duyệt mã, lập trình cặp đôi, tuân

theo chuẩn lập trình, huấn luyện tổ, thu thập và phân tích các

độ đo. Nhận diện lỗi bao gồm mọi nỗ lực để khám phá chất

lượng của công việc dự án. Nó bao gồm mọi hoạt động như

kiểm thử, kiểm thử của người dùng, phân tích căn nguyên v.v.

Sửa lỗi bao gồm mọi nỗ lực để giải quyết việc sửa chữa vấn đề

trong dự án. Sửa lỗi có thể bao gồm nỗ lực làm lại và kiểm thử

lại thiết kế, viết mã hay làm tài liệu.)

Chất lượng là rất quan trọng cho phát triển phần mềm

cho nên tổ phải tuân theo qui trình dành cho các hoạt động thiết

kế, viết mã và kiểm thử. Bất kì vấn đề nào trong cách tổ tuân

theo qui trình hay bất kì cái gì làm tổ xa với qui trình đều phải

được nhận diện để cho tổ có thể học từ những sai lầm. (Lưu ý:

Đây là lúc sinh viên học về cách làm việc tổ và ích lợi của việc

tuân theo qui trình. Trong các phân công trong lớp lập trình,

sinh viên hiếm khi có cơ hội để kiểm điểm lại toàn bộ qui trình

phát triển phần mềm và nhận diện vấn đề xảy ra ở đâu.) Bằng

282

việc thực hiện những pha này, sinh viên áp dụng tri thức của họ

và biến nó thành kĩ năng.

Mọi dự án phần mềm đều có rủi ro. Nếu tổ đã nhận diện

ra các rủi ro đó và có kế hoạch giảm nhẹ chúng ngay từ đầu dự

án thì đây là lúc họ nên kiểm điểm và cập nhật kế hoạch rủi ro

của họ để xem có cảnh báo sớm nào đã xuất hiện không. Tổ có

thể thảo luận về cách rủi ro xảy ra hay không xảy ra cũng như

cách giải quyết chúng. PM phải có họp hàng tuần với tổ để

nhận diện có vấn đề lớn nào không như chất lượng, kĩ thuật,

thành viên tổ, rủi ro và vấn đề môi trường phát triển, v.v. điều

tổ đã gặp phải trong khi hoàn thành pha này. (Lưu ý: Những

cuộc họp này là thời gian học cho các thành viên để học về vấn

đề thường xảy ra trong dự án phần mềm. Khi họ học chúng, họ

cũng học cách giải quyết chúng.)

Trong các cuộc họp hàng tuần, các thành viên tổ phải

nhận diện chức năng nào đã được thực hiện đầy đủ hay một

phần, và cái gì còn chưa đầy đủ. Họ cũng phải giải thích mọi

sai lệch khỏi kế hoạch gốc và tại sao họ đã ra quyết định khác

đi. Họ phải thảo luận bất kì công việc không đầy đủ nào và tại

sao chúng không đầy đủ. PM cần làm tài liệu cho bất kì thay

đổi nào mà tổ đã làm cho kế hoạch của họ, các yêu cầu, thiết

kế, hay kế hoạch thực hiện như các chức năng, use case, hay

yêu cầu phi chức năng mà tổ đã hoặc thêm vào, bỏ đi, hay thay

đổi so với bản kế hoạch đề nghị gốc. Tổ phải ước lượng cách

chất lượng toàn thể của sản phẩm cuối cùng được nâng cao hay

giảm đi như kết quả của những thay đổi này.

Sau khi viết mã được hoàn thành, mọi trường hợp kiểm

thử phải được thực hiện để đảm bảo rằng phần mềm đáp ứng

yêu cầu. Ngày kiểm thử và người cho chạy kiểm thử phải được

ghi lại. Người quản lí kiểm thử cũng phải báo cáo mọi trường

hợp kiểm thử thất bại. Riêng từng thành viên có thể giữ trách

nhiệm về báo cáo không chính xác về kết quả kiểm thử. Với

283

từng lỗi đã biết vẫn còn trong sản phẩm, người quản lí kiểm

thử phải cung cấp mô tả ngắn gọn, đặt tỉ lệ nghiêm trọng của

nó (thấp, vừa, cao) và mô tả giải pháp của nó và ước lượng nỗ

lực được cần để sửa nó. Người quản lí kiểm thử phải phân tích

những lỗi này để tìm ra liệu chúng có là kết quả của phân tích

yêu cầu không đầy đủ, hay thiết kế, viết mã, lập kế hoạch dự

án, hay bất kì nguyên nhân nào. Báo cáo này phải trung thực,

đầy đủ, chính xác và dựa trên phương pháp tốt nhất mà tổ có

thể thực hiện. (Lưu ý: Các lỗi không được báo cáo được tìm ra

trong kiểm điểm của các thầy trong khoa phản ánh sự nghèo

nàn làm việc của tổ và sẽ được lấy làm bằng chứng cho việc

quản lí tổ không đầy đủ hay không thích hợp.)

Người quản lí kiểm thử phải tạo ra báo cáo cuối cùng dựa

trên kiểm thử chấp nhận chính thức với cán bộ của khách hàng.

Báo cáo này phải mô tả các trường hợp về tính dùng được, kịch

bản kiểm thử hay kịch đoạn kiểm thử, chủ đề, hoàn cảnh, cái ra

và kết quả. Tổ phải kiểm điểm các kết quả từ kiểm thử chấp

nhận và so sánh các kiểm thử đã được tiến hành trước đây bởi

tổ (kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống,

kiểm thử rà lại) để tìm ra liệu có lỗi nào thoát ra khỏi kiểm thử

của họ không.

Vào ngày cuối cùng của dự án Capstone, tổ sẽ họp cùng

giáo sư để kiểm điểm lại mọi thứ họ đã học trong dự án. Các

khoản mục tổ phải được chuẩn bị để thảo luận bao gồm: đánh

giá cuối cùng về chất lượng toàn diện (làm việc tổ và qui trình),

tóm tắt về mọi độ đo và tính hữu dụng của chúng, và thành tựu

toàn diện. Các thành viên tổ phải được chuẩn bị để thảo luận về

tính hiệu quả và chất lượng của qui trình của tổ của bạn, việc

trao đổi, quản lí, và vật chuyển giao cuối cùng. Họ phải có

bằng chứng để hỗ trợ cho vai trò, trách nhiệm của họ trong dự

án. Khi tổ chuẩn bị cho việc kiểm điểm này, cân nhắc hai câu

hỏi: "Bạn (như một tổ và như cá nhân) đã thực sự học được gì

284

trong dự án Capstone này?" và "Bài học nào bạn sẽ khuyên cho

tổ dự án tương lai?"

Trong toàn bộ dự án Capstone, tổ phải làm tài liệu các

hoạt động của họ trong báo cáo. Báo cáo này phải có tóm tắt

dành cho giáo sư và cho khách hàng. Nó nói cho họ bằng mô tả

chính xác mọi hoạt động trong dự án cũng như tiến bộ của dự

án trong từng pha. Bài tóm tắt nên trình bày thành tựu của tổ,

kết luận của nó, các khuyến nghị, và vấn đề gặp phải. Báo cáo

phải có chất lượng cao nhất: đầy đủ, đúng giờ, được viết tốt,

được trình bày tốt và rõ ràng. Không có cớ nào cho bất kì cái gì

kém hơn.

Báo cáo của tổ phản ánh nỗ lực và tiến bộ của tổ trong dự

án. Báo cáo tốt là kết quả của cách làm việc tổ tốt, có qui trình,

chú ý tới chi tiết, và hiệu năng tốt về công việc được yêu cầu.

Sẽ khó che giấu hành vi tổ kém hiệu quả, thiếu qui trình, hay

công việc chất lượng kém bằng báo cáo lớn lao. Bất kì báo cáo

sai lạc và không chính xác sẽ bị phạt. Đừng cố làm giáo sư và

khách hàng hiểu sai bằng báo cáo không đề cập tới vấn đề của

tổ, thiếu tiến bộ hay các vấn đề quan trọng khác mà có thể làm

giảm đi việc hoàn thành thành công của dự án của bạn. (Lưu ý:

Đừng làm giáo sư hiểu sai và nói với thầy điều bạn nghĩ thầy

muốn nghe. Nhiều tổ Capstone không chuyển giao được sản

phẩm chất lượng nhưng đã tạo ra báo cáo hay với hi vọng rằng

họ sẽ nhận được điểm tốt. Đó là gian lận vì họ đã không học gì.

Xin nhớ cho rằng dự án Capstone được thiết kế cho sinh viên

học về dự án "thực" trong công nghiệp. Nếu tổ có vấn đề, bạn

phải làm tài liệu chúng để trong kiểm điểm cuối cùng, giáo sư

và tổ có thể thảo luận và tìm ra giải pháp. Đó là học tập cho

nên không có lí do gì để che giấu mọi sự với giáo sư.)

Báo cáo của bạn phải đầy đủ và chuyển vào việc cho

điểm. Các giáo sư sẽ cho điểm điều được cho và điều được viết

ở đó. Chính trách nhiệm của tổ là đảm bảo rằng tài liệu trong

285

báo cáo được tổ chức tốt, rõ ràng và đã được kiểm điểm kĩ

lưỡng về chất lượng. (Lưu ý: Nhiều sinh viên không biết rằng

viết là kĩ năng mấu chốt và được người quản lí thuê người đánh

giá cao). Báo cáo phải có chất lượng cao nhất có thể được. Một

báo cáo được chuẩn bị tốt, viết tốt, làm tài liệu tốt phản ánh rõ

tổ của bạn và gây ấn tượng tốt cho các giáo sư và khách hàng.

Công việc không đầy đủ, hay được chuẩn bị kém gây ấn tượng

rất xấu. Là một tổ, các bạn phải có lòng tự hào trong công việc

của mình và biến nó thành báo cáo phản ánh chính xác công

việc khó khăn và nỗ lực các bạn đã đưa vào trong dự án của

mình. Đừng bao giờ làm công việc "đủ tốt" bởi vì nếu giáo sư

của bạn không thích điều đó, thì người chủ lao động tương lai

của bạn cũng không thích. (Lưu ý: Về truyền thống, công ti cho

đại học dự án capstone cũng là công ti thường thuê sinh viên.

Theo nhiều nghiên cứu đại học, trên 90% các thành viên dự án

capstone được thuê bởi những công ti đó vì họ đã biết kĩ năng

của sinh viên qua dự án này. Không cần làm đơn xin việc hay

phỏng vấn vì chúng là không cần thiết. Người quản lí của công

ti phân công dự án Capstone thường là người sẽ quyết định

thuê sinh viên. Tất nhiên, trong toàn dự án, họ giám sát hiệu

năng của sinh viên dựa trên thời gian sinh viên dành ra và chất

lượng công việc của họ đã làm.)

Một số vấn đề trong dự án Capstone

Không phải tất cả các dự án capstone đều hoàn thành

thành công. Vài dự án gặp khó khăn với các vấn đề kĩ thuật

nhưng hầu hết đều có khó khăn với làm việc tổ vì một số thành

viên không muốn làm việc như một tổ. Nhiều sinh viên ưa

thích làm việc độc lập và không thấy ích lợi của làm việc tổ.

Với họ, làm việc tổ là hoạt động "bề ngoài" không đem lại ích

lợi. Thay vì làm việc cùng nhau, các thành viên tổ chia công

286

việc ra rồi từng người làm nó một cách độc lập theo cách riêng

của mình và hi vọng rằng dự án sẽ thành công. Cho dù từng

thành viên làm xong việc riêng của mình, họ thường thất bại

không tích hợp được nỗ lực của họ thành kết quả cố kết và dự

án capstone không hoàn thành như được lập kế hoạch.

Vấn đề có thể được dõi về việc thiếu hiểu biết về mục

đích của dự án capstone. Theo định nghĩa, tổ là một nhóm

người làm việc cùng hướng tới "mục đích chung". Nếu tổ

không rõ ràng về mục đích hay không hiểu tại sao họ phải làm

việc cùng nhau thì họ bị lẫn lộn. Không có hiểu biết rõ ràng về

mục đích, tổ trở nên làm việc chệch choạc, giận dữ, họ thường

đổ lỗi cho nhau; phê phán nhau về điều họ làm.

Khi điều đó xảy ra, giáo sư phải bước vào và làm sáng tỏ

mục đích của dự án capstone. Điều quan trọng là giải thích cho

tổ rằng dự án capstone được thiết kế để "mô phỏng" dự án

trong công nghiệp, do đó nó phức tạp hơn nhiệm vụ có thể

được phân công cho cá nhân. Để giải quyết các vấn đề phức

tạp, làm việc tổ là cần phải có. Tổ có thể phát triển giải pháp tốt

hơn cho các vấn đề khó. Làm việc tổ cũng là một phần của quá

trình học tập nơi các thành viên học kĩ năng mềm và cách làm

việc trong tổ.

Ngay cả sau khi giải thích điều đó cho tổ, điều quan trọng

là thẩm tra hiểu biết của họ. Giáo sư có thể yêu cầu thành viên

tổ giải thích cách nhìn của họ về mục đích tổng thể theo lời

riêng của họ và điều họ mong đợi học từ nó? Sau khi mọi thành

viên bày tỏ cách nhìn của họ, giáo sư có thể yêu cầu tổ mô tả

mục đích hay viễn kiến chung cho dự án. Viễn kiến cần có cái

gì đó có thể gây kích động cho tổ. Nó phải chứa những thách

thức cũng như cơ hội cho họ. Chẳng hạn, “Dự án sẽ giống cái

gì khi bạn hoàn thành nó?”, “Thành công sẽ giống cái gì?”,

“Làm sao bạn biết rằng bạn thành công?”, “Làm sao người

khác biết?” Khi các thành viên tổ có thể mô tả rõ ràng mục

287

đích chung hay đồng ý về viễn kiến thì tổ có thể tiến sang bước

tiếp.

Lãnh đạo là mấu chốt trong dự án capstone. Không có

nó, các thành viên tổ sẽ quay về theo cách riêng của họ để làm

mọi sự. Một số người sẽ làm nhiều hết mức có thể để chứng tỏ

bản thân mình là "anh hùng". Một số người sẽ không làm gì cả

và dựa vào người khác để làm công việc cho họ. Một số người

sẽ đòi hỏi nhiều công việc hơn trong khi số khác sẽ ngồi yên

tĩnh. Một số người sẽ làm chút ít nhưng sẽ phàn nàn về bao

nhiêu việc họ phải làm. Một số người sẽ bận rộn làm cái gì đó

khác, bên ngoài công việc dự án rồi phàn nàn rằng họ không có

đủ thời gian.

Nếu điều đó xảy ra, giáo sư phải bước vào và hỗ trợ cho

người lãnh đạo tổ về cách giữ cho tổ hội tụ vào mục đích của

dự án và cách phân chia công việc tương ứng theo vai trò, trách

nhiệm. Vì người lãnh đạo tổ thường được tổ lựa chọn, người đó

phải học về việc lãnh đạo. Nhiều sinh viên không hiểu khác

biệt giữa việc lãnh đạo và quản lí cho nên người lãnh đạo tổ

thường hành động như người đó có quyền và ra lệnh cho tổ làm

cái này cái nọ. Điều quan trọng cần lưu ý là việc của người

quản lí thường là hội tụ vào cấu trúc nhưng việc của người lãnh

đạo tổ là vào con người. Người quản lí dựa trên kiểm soát và

duy trì trật tự nhưng người lãnh đạo gây hứng khởi về tin cậy

và quan hệ.

Trách nhiệm cho tính hiệu quả của nhóm không phải chỉ

phụ thuộc vào người lãnh đạo mà được chia sẻ chung cho cả

nhóm. Quyết định cuối cùng không do người lãnh đạo tổ đưa ra

mà cũng được chia sẻ bởi cả nhóm. Người lãnh đạo tổ chỉ tạo

điều kiệm và trao đổi thông tin với tổ và hiểu nhu cầu và tình

cảm của các thành viên. Người lãnh đạo tổ phải có cuộc họp

với các thành viên tổ trên cơ sở hàng tuần để đảm bảo rằng họ

biết họ được giả định làm gì. Người lãnh đạo tổ phải yêu cầu

288

có phản hồi từ họ để nhận diện các vấn đề chính, và các cơ hội

cải tiến.

Trong một tổ hiệu quả, từng thành viên hiểu tầm quan

trọng của việc làm của mình và cách nó tác động vào tính hiệu

quả của người khác và nỗ lực tổng thể của tổ. Không có vai trò

và trách nhiệm được xác định rõ, nó sẽ tạo ra lẫn lộn. Thỉnh

thoảng, các thành viên được yêu cầu làm việc về một nhiệm vụ

mà không được nói về vai trò của họ đóng góp thế nào cho kết

quả mong muốn, công việc của họ tác động thế nào tới khả

năng của người khác làm việc của họ. Việc hiểu mục đích và

cách công việc được phân chia giúp cho sự cộng tác, làm tăng

quyết tâm và chất lượng.

Khi xung đột xảy ra giữa các thành viên, người lãnh đạo

tổ phải lắng nghe quan điểm của từng thành viên trước khi có

bất kì hành động nào. Bằng việc lắng nghe cẩn thận, người đó

có thể hạ thấp căng thẳng tình cảm của thành viên tổ và cho

phép người đó bình tĩnh lại. Đây là chỗ người lãnh đạo tổ phát

triển kĩ năng lắng nghe bằng việc nghe cẩn thận và không ngắt

lời để cho thành viên có thể diễn đạt quan điểm của họ một

cách đầy đủ. Điều cũng quan trọng là giữ cho vấn đề tách bạch

khỏi con người để cho chúng có thể được giải quyết mà không

làm tổn thương con người. Bằng việc lắng nghe cẩn thận,

người lãnh đạo tổ hội tủ vào việc thúc đẩy hiểu biết tốt, đảm

bảo trao đổi thích hợp và tạo điều kiện cho tương tác hiệu quả

sẽ thành công.

Học trong dự án Capstone

Một sinh viên viết cho tôi: “Dự án Capstone của em

không tiến triển tốt. Chúng em phí thời gian vào tranh cãi lẫn

nhau; tiến bộ của chúng em rất chậm và em thấy thất vọng. Em

289

không chắc liệu em có cần Capstone chút nào không. Em

không thấy ích lợi gì trong hoạt động này. Xin thầy lời

khuyên.”

Đáp: Capstone là dự án trường học cuối cùng trước khi

tốt nghiệp nơi bạn thực hành điều bạn đã học trong ba năm qua

để phát triển kĩ năng của bạn và nhân cách của bạn. Trong dự

án Capstone, bạn học cách làm việc trong tổ cũng như giải

quyết một số vấn đề kĩ thuật. Bạn học về thu nhận yêu cầu;

phân tích nhu cầu của khách hàng; thương lượng với khách

hàng; lập ưu tiên cho công việc; phân phối nhiệm vụ trong các

thành viên tổ. Bạn cũng học lập kế hoạch dự án; chia nhỏ công

việc lớn thành những nhiệm vụ nhỏ hơn; xác định nỗ lực, thời

gian và lịch biểu; kiến trúc hệ thông tin, thiết kế rồi xây dựng

sản phẩm phần mềm thực tại cho khách hàng.

Có nhiều điều bạn sẽ học trong dự án Capstone nếu bạn

chú ý. Bạn học cách trình bày khái niệm cho khách hàng; cách

xây dựng tổ dự án; cách động viên tổ; cách thương lượng ưu

tiên yêu cầu; cách quản lí thay đổi trong dự án. Nhiều điều sẽ

xảy ra trong thời gian này và tác động lên tiến bộ của dự án.

Bạn phải học cách giải quyết chúng để duy trì đà dự án. Điều

bạn học và bạn học được bao nhiêu trong Capstone sẽ xác định

ra kĩ năng tương lai của bạn cũng như nhân cách chuyên

nghiệp của bạn.

Chẳng hạn, cái gì sẽ xảy ra nếu thành viên tổ bị ốm và

không thể tham gia được trong nhiều tuần? Tổ có thể tái tổ

chức lại công việc của họ để tiếp quản công việc của anh ta để

giữ cho dự án tiếp diễn được không?

Điều gì sẽ xảy ra nếu hai thành viên tổ bị ốm cùng lúc?

Điều này tất yếu sẽ làm chậm dự án lại. Các thành viên tổ nên

làm gì? Bằng việc học cách giải quyết vấn đề này, bạn phát

triển kĩ năng tổ chức và quản lí. Điều gì sẽ xảy ra nếu một

thành viên tổ không tham gia đầy đủ với tổ? Thành viên này

290

thường đi muộn, bỏ họp tổ, phàn nàn về công việc, và chỉ trích

người khác vì không chia sẻ thông tin? Làm sao bạn giải quyết

được với thành viên như vậy? Bằng việc học cách giải quyết

với những người khó khăn, bạn phát triển kĩ năng lãnh đạo của

bạn.

Điều gì sẽ xảy ra nếu bạn ước lượng rằng dự án cần mười

tuần để hoàn thành nhưng khách hàng chỉ cho bạn sáu tuần?

Bạn có chấp nhận thời hạn của khách hàng không? Bạn có bỏ

qua vài hoạt động để làm cho dự án đáp ứng lịch biểu không?

Bạn có phá huỷ chất lượng bằng việc bỏ qua pha kiểm thử

không? Bạn có bỏ thiết kế và bắt đầu viết mã không? Bằng việc

học cách giải quyết với lịch biểu rất chặt, bạn phát triển kĩ năng

thương lượng.

Điều gì sẽ xảy ra nếu đến cuối từng pha, kết quả được

đánh giá so với kế hoạch và nó không sánh đúng kế hoạch?

Đây là chỗ bạn học rằng hiếm khi có được kết quả đáp ứng

chính xác với bản gốc đã lập kế hoạch. Hoặc là bạn ước lượng

sai hay các biến cố bất ngờ xảy ra mà yêu cầu tổ đi chệch khỏi

kế hoạch. Đây là chỗ bạn học cách theo dõi tiến bộ và cải tiến

kĩ năng lập kế hoạch của bạn.

Điều gì sẽ xảy ra nếu tổ không rõ ràng về liệu dự án là

bản mẫu hay sản phẩm làm việc? Khách hàng mong đợi nhận

được sản phẩm phần mềm, trong khi tổ dự án giả định rằng họ

xây dựng bản mẫu. Làm sao bạn giải quyết được mong đợi

khác biệt này? Đây là chỗ bạn học cách cải tiến kĩ năng phân

tích yêu cầu và kĩ năng đặc tả của bạn.

Điều gì sẽ xảy ra nếu tổ cân nhắc rằng dự án được làm

xong nhưng khách hàng không đồng ý. "Làm xong" có nghĩa gì

với bạn? Triệu chứng của "Chín mươi phần trăm dự án đã được

làm xong nhưng mười phần trăm cuối cùng có thể mất nhiều

tháng để hoàn thành” là rất thông thường. Đây là chỗ bạn học

về các biên giới của dự án và cải tiến kĩ năng lập kế hoạch dự

291

án của bạn để cho dự án có thể được đóng, một khi nó đã đạt

tới những biên giới này.

Xin nhớ cho rằng Capstone là thời gian dành cho bạn học

và phát triển kĩ năng của bạn: Bạn đã dành vài năm thu nhận tri

thức, bây giờ là lúc áp dụng nó vào "tình huống thực". Đây

cũng là lúc xây dựng kĩ năng mềm của bạn vì chúng là một

phần nhân cách của bạn. Bạn có còn bình thản dưới tình huống

căng thẳng không? Bạn có chấp nhận sai lầm của bạn không,

hay bạn đổ lỗi cho ai đó? Bạn có sẵn lòng chấp nhận vai trò của

bạn và chịu trách nhiệm cho điều bạn làm không? Có nhiều

điều bạn có thể hỏi bản thân mình trong dự án Capstone. Câu

trả lời của bạn và thái độ của bạn sẽ xác định nhân cách chuyên

nghiệp tương lai của bạn. Khi bạn có tri thức sâu và đạo đức

chuyên môn mạnh thì bạn có thể tiến lên nghề nghiệp tốt hơn,

vị trí tốt hơn. Chỉ với thái độ đạo đức và chuyên nghiệp, bạn có

thể làm những điều tốt cho công ti của bạn và cho xã hội. Bạn

cần những kĩ năng và kinh nghiệm này để làm bản thân mình

tiến bộ trong thế giới thay đổi nhanh chóng này. Điều thông

thường là bạn sẽ phạm phải sai lầm, nhưng tôi thà thấy rằng

bạn phạm sai lầm ở trường nơi bạn có thể học từ nó hơn là

phạm sai lầm ở công ti nơi việc làm của bạn tuỳ thuộc vào bạn

thực hiện tốt đến đâu.

Capstone là thời gian nơi bạn xây dựng nền tảng mạnh cả

trong kĩ năng kĩ thuật và nhân cách. Theo ý kiến tôi, nhân cách

là quan trọng hơn kĩ năng của bạn. Một kĩ năng kĩ thuật tốt mà

không có nhân cách mạnh, không có đạo đức mạnh sẽ là thảm

hoạ cho bất kì công ti nào và cho xã hội. Chúng ta đã thấy

nhiều ví dụ về những người vô đạo đức trong công nghiệp tài

chính và ngân hàng trong vài năm qua. Cho tới giờ khu vực

công nghệ vẫn còn thuần khiết và tôi mong ước nó sẽ duy trì

theo cách đó.

292

Capstone cho phép bạn làm việc với nhiều người vì bạn

có nhiều điều để học từ nhau để phát triển nhân cách của bạn.

Cách bạn hành động; cách bạn giải quyết với sức ép; cách bạn

cộng tác; cách bạn chia sẻ thông tin; và cách bạn giúp đỡ lẫn

nhau sẽ hình thành nên nhân cách chuyên nghiệp của bạn. Đây

là lúc bạn học nhiều về kĩ năng mềm. Bạn phải học cách nói rõ

ràng, trôi chảy nhưng cũng trung thực. Đừng bao giờ hứa hẹn

điều bạn không thể giữ được. Đừng bao giờ dùng thông tin sai

để có được điều bạn muốn. Nói chân lí một cách yên tĩnh và

đừng bao giờ làm cái gì ngược lại lương tâm bạn. Bạn học khi

nào nói ra ý kiến của bạn và khi nào giữ yên tĩnh. Nhớ rằng sự

hài hoà của tổ là quan trọng và chia sẻ mục đích chung là chiều

hướng. Đừng hành động như anh hùng; đừng kiêu căng vì

không ai có thể thành công mà không có người khác. Bạn đang

làm việc trong tổ và tổ là quan trọng hơn cá nhân.

Thường có mối lo âu liên quan tới liệu kết quả tốt nào có

thể được tạo ra trong Capstone chút nào không. Chừng nào tổ

còn tạo ra công việc tốt bằng việc chuyển giao phần mềm làm

việc tốt và qua được mọi kiểm thử; khách hàng sẽ chấp nhận nó

như một sản phẩm làm việc. Sau rốt, đây là dự án trường học

và các thành viên tổ là sinh viên. Không ai mong đợi hoàn hảo

ở đây. Đừng lo nghĩ quá nhiều về kết quả chừng nào bạn đã

làm hết sức của bạn.

Đối thoại về làm việc tổ

Hôm qua một sinh viên tới gặp tôi. Anh ta là học sinh

giỏi, một trong những người giỏi nhất lớp. Anh ta nói: “Em

cảm thấy không thoải mái với tổ dự án Capstone. Một số thành

viên lười, một số không thông minh, và một số không tới cuộc

293

họp tổ đúng giờ. Tất cả họ đều lấy cớ cho hành động của họ.

Em phải làm hầu hết các việc và em không thích điều đó.”

Tôi giải thích: “Tôi không ngạc nhiên. Có hai mục tiêu

then chốt trong dự án Capstone: Áp dụng điều em đã học vào

dự án thực và học cách làm việc trong tổ. Có kĩ năng kĩ thuật là

không đủ. Em cũng cần học cách làm việc cùng người khác

nữa. Tôi đã từng quan sát tiến bộ của tổ của em và tôi biết rằng

một số thành viên tổ đã không làm mấy nhưng họ đã bỏ phiếu

cho em là người lãnh đạo tổ và em phải học làm người lãnh

đạo. Người lãnh đạo không bỏ chạy khi đối diện với khó

khăn.”

Anh ta nói: “Nhưng em không muốn làm người lãnh đạo.

Tại sao thầy không cho em công việc nào đó mà bản thân em

có thể tự làm được. Em không bận tâm tới công việc khó khăn

nhưng em không muốn làm việc trong tổ.”

Tôi bảo anh ta: “Dự án capstone không được thiết kế cho

mọi người làm việc một mình. En đang học cách làm việc

trong tổ. Mọi tổ đều cần thời gian để hình thành và để các

thành viên tổ đi tới biết lẫn nhau. Em cần thời gian để xây dựng

mối quan hệ và thảo luận với nhau để phát triển hiểu biết chung

về mục đích dự án. Là người lãnh đạo tổ em phải xây dựng

chương trình nghị sự và khung thời gian cho các hoạt động của

tổ và phải chắc rằng mọi người có cơ hội tham gia. Em phải đặt

ra các qui tắc và quyết định thời gian và nơi chốn để họp và

phải chắc các thành viên tổ sẽ tuân theo. Khi tổ thiếu hội tụ và

chiều hướng vì điều đó họ lẫn lộn và không biết phải làm gì. Là

người lãnh đạo, em phải làm rõ mục đích, nhiệm vụ, và kết quả

của dự án rồi phân công các vai trò riêng cho các cá nhân...”

Anh ta lắc đầu: “Em không muốn làm việc với tổ này. En

không thích một số người trong họ. Liệu em có thể chuyển

sang tổ khác để cho em chỉ là thành viên tổ và làm việc kĩ thuật

không?”

294

Tôi hỏi: “Chúng ta hãy nhìn vào tình huống này một chút

ít nữa. Giả sử rằng em đi làm cho một công ti phần mềm. Em

có thể nói với người quản lí là em không thích người này hay

người kia cho nên họ phải tìm ai đó mà em hoà hợp để làm việc

cùng em không? Em có thể yêu cầu họ cho em cái gì đó mà em

muốn làm không? Em có thể bảo công ti rằng em không thích

dự án này cho nên họ phải tìm cho em dự án khác không? Khi

làm việc trong công nghiệp, em không có chọn lựa đâu. Hoặc

em hoà hợp với mọi người hoặc em bị đuổi việc. Không công ti

nào sẽ chịu được người với nhu cầu như vậy. Là sinh viên, em

phải học cách đối phó với những điều không dễ chịu nào đó

bây giờ để cho em không phải nếm cay đắng về sau.”

Anh ta yên lặng một chốc: “Nhưng phần lớn các thành

viên tổ đều không giỏi về kĩ thuật. Họ chỉ là sinh viên trung

bình và em muốn dự án của em thành công.”

Tôi bảo anh ta: “Đây không phải là dự án của em, nó là

dự án của họ nữa. Cho nên em nghĩ rằng em là giỏi về kĩ thuật

và họ không giỏi. Nếu em bắt đầu so sánh bản thân mình với

người khác, em sẽ trở nên kiêu ngạo hay cay đắng vì sẽ có ai

đó kém hơn em hay giỏi hơn em. Em cần học nhiều về khiêm

tốn vì đó là điều duy nhất có thể bảo vệ em trong thời đại thay

đổi này. Em có thể học giỏi trong lớp nhưng với tôi dường như

là em đã không học được gì mấy về cuộc sống. Em vẫn phải

học nhiêu và đây là cơ hội tốt cho em học. Capstone là bài học

thứ nhất của em trong nhiều bài học mà em sẽ học trong cuộc

đời. Tốt hơn cả em nên học nó bây giờ nếu không thì sẽ thành

quá trễ.”

Anh ta cãi: “Nhưng tổ không làm việc tốt. Họ cũng

không hoà hợp lẫn nhau. Em không phải là người duy nhất.”

Tôi giải thích: “Thỉnh thoảng tổ thấy khó làm việc cùng

nhau nếu không có đủ thông tin hay ý tưởng để thảo luận. Em

cần bắt đầu việc thảo luận bằng cách giải thích viễn kiến của

295

em về dự án, mục đích của em và điều gì em muốn thấy như

kết quả của dự án này. Em có thể xem xét một miền các khả

năng bằng cách hỏi “Cái gì xảy ra nếu” hay 'Cái gì khác” để

cho em có thể đưa các thành viên tổ vào tham gia trong việc

tìm giải pháp. Em phải đề nghị họ đi tới một số ý tưởng tốt

hơn. Nếu các ý tưởng không được thảo luận đầy đủ, tổ có thể

không hiểu tiềm năng của mình và trở nên nhiều tính biện luận

hơn. Em cần liệt kê ra mọi ý tưởng mới khi họ gợi ý và đảm

bảo tất cả những ý tưởng đó đều được thảo luận sâu để cho tổ

có thể chọn lựa cái tốt nhất để bắt đầu. Điều quan trọng nhất là

để mọi người biết lẫn nhau và bắt đầu làm việc như một tổ.”

Anh ta ngần ngại: “Nhưng một số thành viên không tới

họp đúng giờ. Một số thậm chí không nói với nhau.”

Tôi giải thích: “Là người lãnh đạo tổ, em đặt ra qui tắc.

Chẳng hạn, bất kì ai tới cuộc họp muộn phả trả tiền phạt.

Thành viên tới chậm năm phút phải mua đồ uống cho cả tổ.

Quá mười lăm phút phải mua thức ăn và quá nửa giờ phải mua

bữa tối cho các thành viên tổ. Nếu tổ đồng ý với qui tắc này thì

em có thể làm cho nó có hiệu lực. Em phải lập khung thời gian

mà mọi thành viên tổ đồng ý cho từng cuộc họp. Em có thể đề

nghị từng thành viên trình bày báo cáo tiến bộ về điều họ đã

làm kể từ cuộc họp trước. Họ phải thảo luận những khó khăn

mà họ đã trải qua để cho mọi người biết về tiến bộ của nhau.

Nhớ rằng nỗ lực và kết quả của toàn tổ dựa vào tính hiệu quả

và hiệu lực của từng thành viên tổ.”

Anh ta hỏi: “Em phải làm gì khi các thành viên dường

như không tham gia vào thảo luận.”

Tôi giải thích: “Một số người có thể yên tĩnh bởi vì họ

chỉ nghe. Em có thể hỏi ý kiến họ và cố biết tại sao họ im lặng?

Nếu cần, em có thể nói với từng cá nhân ở chỗ riêng tư để nhận

diện liệu có lí do cho việc thiếu tham gia không. Em phải để

cho họ biết rằng là người lãnh đạo tổ, em đánh giá cao đóng

296

góp của từng thành viên với tổ và khuyến khích họ tham gia

nhiều hơn."

Anh ta tranh luận: “Nhưng điều gì xảy ra nếu các thành

viên tổ bất đồng với nhau?

Tôi giải thích: “Điều này là hoàn toàn bình thường trong

làm việc tổ. Em phải đặt ra các qui tắc rằng các thành viên tổ

phải tôn trọng ý tưởng của người khác. Họ phải lắng nghe lẫn

nhau và cung cấp những ý kiến bình luận tích cực và xây dựng

về ý tưởng của người khác. Khi bất đồng họ phải nêu ý tưởng

một cách lịch sự và tránh đương đầu. Là người lãnh đạo, em

phải nhắc nhở các thành viên tổ rằng làm việc trong tổ nghĩa là

thương lượng cần xuất hiện và đây là "kĩ năng mềm" mà mọi

người cần học. Sinh viên bao giờ cũng phàn nàn rằng họ không

được dạy "kĩ năng mềm" ở trường. Đây là cơ hội để học tập,

nếu họ không học bây giờ thì họ sẽ học khi nào?"

Anh ta dường như đồng ý: “Tuy nhiên, trong họp các

thành viên tổ thường nói về các việc khác, như tán gẫu và

không thảo luận làm việc tổ, em không thể bảo họ im được.”

Tôi nói với anh ta: “Làm việc tổ cũng là hoạt động xã

hội. Em phải cho phép một thời gian ngắn để cười hay nói

chuyện, nhưng rồi nhắc tổ về khung thời gian và các nhiệm vụ

cần được hoàn thành trong phiên đó. Em có thể để cho tổ biết

rằng nếu họ kết thúc cuộc họp đúng giờ, làm cho công việc của

họ được thực hiện đúng giờ, thì họ có thể dành nhiều thời gian

hơn cho nói chuyện, có thể ở quán cà phê về sau. Em phải để

cho tổ có cơ hội biết lẫn nhau và xây dựng mối quan hệ.”

“Trong dự án Capstone, em học nhiều điều nhưng điều

quan trọng nhất là học kĩ năng mềm như cách làm việc trong

tổ, cách thương lượng lịch biểu, cách trao đổi, cách lắng nghe,

cách giải quyết xung đột, em cũng học kĩ năng trình bày, kĩ

năng lãnh đạo, kĩ năng quan hệ. Dự án Capstone thực sự là

297

"Học 'kĩ năng mềm' bằng việc thực tế làm nó.” Tổ cần biết rằng

đây là năm cuối của họ ở trường, trong vài tháng nữa họ sẽ tốt

nghiệp và phải đi tìm việc làm. Có cả kĩ năng kĩ thuật và kĩ

năng mềm sẽ là điều có giá trị làm phân biệt họ với người

khác."