Bài 8: Quản lí rủi ro phần mềm

Trong bài này, bạn sẽ được giới thiệu cho vấn đề về rủi ro phần mềm. Rủi ro
có thể được định nghĩa là "Khả năng chịu thiệt hại, tổn thất, hay nguy hiểm."
Cho dù bạn không quen thuộc với định nghĩa hình thức, phần lớn các bạn
đều đã có cảm giác bẩm sinh về rủi ro. Nhiều người trong các bạn nhận biết
về nguy hiểm tiềm năng tràn ngập ngay trong hoạt động thường ngày như bị
thương khi đi qua phố mà không nhìn. Mặc dầu bạn có thể ưa thích không
chú ý vào những hiểm nguy bao quanh bạn, những rủi ro này hình thành nên
nhiều trong các hành vi của bạn.

Tuy nhiên không giống như những hiểm nguy của việc sống hàng ngày, rủi
ro trong Kĩ nghệ phần mềm không được dạy kĩ trong nhiều đại học và
thường chỉ được học khi sinh viên tham gia vào lực lượng lao động. Chương
trình Kĩ nghệ phần mềm nhận diện một số ví dụ điển hình về các mục rủi ro
phần mềm:

• Khan hiếm người

• Lịch biểu và ngân sách không hiện thực
• Phát triển chức năng và tính chất sai
• Phát triển giao diện người dùng sai
• Luồng liên tục những thay đổi yêu cầu
• Thiếu hụt về cấu phần trang bị bên ngoài

Quản lí rủi ro điển hình được bao gồm trong các hoạt động sau:

a) Thẩm định rủi ro (hình dung ra rủi ro là gì và hội tụ vào cái gì)
- làm danh sách tất cả các nguy hiểm tiềm năng sẽ ảnh hưởng tới dự án
- thẩm định xác suất xuất hiện và tổn thất tiềm năng của từng mục được liệt
kê
- xếp hạng các khoản mục (từ nguy hiểm nhiều nhất tới ít nhất)
b) Kiểm soát rủi ro (làm cái gì đó về chúng)
- đưa ra các kĩ thuật và chiến lược để giảm thiểu rủi ro cấp cao nhất
- thực hiện các chiến lược để giải quyết nhân tố rủi ro cấp cao
- điều phối tính hiệu quả của các chiến lược và thay đổi mức rủi ro trong
toàn dự án

Quản lí rủi ro là kĩ năng quan trọng. Bạn phải hiểu rủi ro và biết cách quản lí
chúng. Rủi ro có hai thuộc tính chủ yếu:
Xác suất rủi ro sẽ xuất hiện. Chúng ta có thể dùng tỉ lệ 0 – 100 để mô tả xác
suất của rủi ro.
Rủi ro có xác suất 0 được gọi là không có cơ hội xuất hiện.
Rủi ro với xác suất 100 được gọi là chắc chắn xảy ra (nói cách khác, “vấn
đề””)
Mọi thứ giữa 0 và 100 đều có cơ hội rủi ro sẽ xuất hiện. Rủi ro với xác suất
1 được gọi là có 1 trong 100 cơ hội (1%) xảy ra.

Tác động của rủi ro nếu nó xuất hiện. Chúng ta có thể dùng thang 0 -100 để
mô tả tác động của rủi ro.
Rủi ro với tác động 0 được gọi là không có tác động.
Rủi ro với tác động 100 được gọi là “đình chỉ - show stopper” (cái gì đó
nghiêm trọng tới mức dự án không tiến được).
Mọi thứ giữa 0 và 100 đều là tác động lên dự án nếu nó xuất hiện. Rủi ro với
tác động 1 được gọi là gần như không có tác động lên dự án.

Cách tốt để nghĩ về xác suất và tác động là xét rủi ro một thiên thạch xuyên
qua mái nhà và giết chết cả tổ dự án. Tác động là khổng lồ, với cả tổ dự án
đi toi dự án sẽ phải dừng lại, tuy nhiên xác suất là rất, rất thấp.

Mọi rủi ro đều có thể tạo ra vấn đề, do đó bạn phải có qui trình ra quyết định
hệ thống nhận diện hiệu quả rủi ro, thẩm định xác suất xuất hiện, tác động
nếu nó xuất hiện và giải quyết nó một cách hiệu quả để đạt tới mục đích
nghiệp vụ.

Điều quan trọng cần lưu ý rằng rủi ro xảy ra vào bất kì lúc nào, ở bất kì đâu
cho nên việc nhận diện rủi ro được tiến hành liên tục trong mọi miền nghiệp
vụ với tính rõ ràng và sự tham gia của cấp quản lí thích hợp.

Một khi bạn đã nhận diện rủi ro bạn phải lập kế hoạch để giảm thiểu nó, kế
hoạch nên được đưa vào bản kế hoạch của tổ, và từng hành động giảm nhẹ
nên được đưa vào việc giảm rủi ro liên kết. Hành động phòng ngừa là rẻ hơn
hành động sửa chữa, cho nên cần giải quyết rủi ro trước khi nó biến thành
vấn đề.

Bài này hội tụ vào rủi ro dự án. Rủi ro có thể được định nghĩa là "Khả năng
bị thiệt hại, tổn thất, hay nguy hiểm." Rủi ro là cái gì đó còn CHƯA xảy ra,
do đó nó đòi hỏi việc phòng ngừa.
Rủi ro là cái gì đó mà nếu chúng xảy ra, thì gây ra vấn đề mà có thể là thảm
hoạ cho dự án phần mềm. Mọi dự án đều có rủi ro. Có ba điều mấu chốt cho
quản lí rủi ro:
• Có qui trình quản lí rủi ro được làm tài liệu mà mọi người đều quen thuộc.
• Nhận diện và định lượng rủi ro liên kết với dự án.
• Làm việc với người có ảnh hưởg để hiểu tác động của rủi ro lên dự án và
những đáp ứng được lập kế hoạch để đề cập tới rủi ro.

Bao giờ cũng có nhiều rủi ro về dự án phần mềm hơn là người quản lí dự án
có thể quản lí, cho nên người quản lí dự án phải ưu tiên hoá các rủi ro để cho
phần lớn những rủi ro lớn đều được đề cập tới.
Tư duy công nghiệp hiện thời là viết ra tất cả các rủi ro dự án, nhưng chỉ
quản lí tích cực mười rủi ro hàng đầu. Tức là, làm việc xác định rủi ro nào là
đủ quan trọng cần quản lí, và dành thời gian và nỗ lực quản lí mỗi chúng
thôi.
Nhiều người thường liệt kê các rủi ro, nhưng rồi chẳng làm gì về chúng, cứ
dường như rủi ro sẽ biến đi đơn giản bởi vì chúng đã được liệt kê ra. Trong
nhiều trường hợp, rủi ro ít nhất phải được đề cập tới bởi việc dành nỗ lực
hay thời gian quản lí chúng. Rất ít dự án có thể được hoàn thành mà không
có rủi ro. Cứ cho là bao giờ cũng có rủi ro nào đó, thế thì câu hỏi là bao
nhiêu rủi ro là hợp lí để hoàn thành giá trị của dự án.

Trong khi bản chất của quản lí rủi ro hiệu quả dựa trên cảm giác thông
thường và được sử dung tới mức độ nào đó bởi người quản lí dự án phần
mềm tốt, nhiều kĩ thuật, phương pháp và công cụ hình thức có thể được
dùng để nâng cao khả năng giải quyết rủi ro. Những kĩ thuật và công cụ như
vậy trải rộng từ miền truyền thống như ước lượng chi phí và đảm bảo chất
lượng cho tới miền ít truyền thống hơn như hành vi tổ chức và ác cảm rủi ro
cá nhân.

Nội dung thảo luận

1. Tại sao dự án cần thực hiện quản lí rủi ro?
2. Khác biệt giữa rủi ro và vấn đề là gì?
3. Các kiểu rủi ro dự án phần mềm là gì?
4. “Né tránh rủi ro cũng có thể nghĩa là né tránh cơ hôi” nghĩa là gì?
5. Người quản lí dự án có thể nỗ lực để tránh mọi rủi ro dự án được không?

Bài đọc thêm:

1. L8_Risk_Management.pdf
2. L8_Risk_Management1.pdf
3. L8_Risk_Management_easy.pdf
4. L8_Risk1.pdf
5. L8_Software Risk Factors Table.pdf
Phân công Công việc tổ
Sinh viên sẽ được tổ chức thành các nhóm để chuẩn bị bài trình bày cho lớp.
Phiên trình bày này được tạo ra để thúc đẩy công việc tổ và để thám hiểm
khả năng của sinh viên hiểu thấu các khái niệm cơ bản của bài. Với việc
trình bày này, tổ sẽ hội tụ vào kịch bản sau:
“Là người quản lí dự án của công ti phần mềm bạn đang lãnh đạo một tổ
phát triển phần mềm cho khách hàng ở Mĩ. Dự án này là về xây dựng ứng
dụng tài chính hỗ trợ cho việc sinh ra thu nhập từ nghiệp vụ xuất và nhập
khẩu của khách hàng. Dự án này rất quan trọng với công ti bạn cho nên
người quản lí của bạn muốn chắc chắn rằng tổ của bạn sẽ chuyển giao dự án
đúng hạn, với mọi chức năng được chuyển giao theo lịch biểu. Sau đây là
một số rủi ro:
Khách hàng rất bận và không có thời gian gặp tổ của bạn rất thường xuyên.
Ứng dụng này dùng công nghệ mới mà bạn còn chưa quen thuộc.
Thành viên tổ đều tương đối mới với công ti, nhiều người chỉ vừa mới ra tốt
nghiệp từ đại học và có kinh nghiệm tối thiểu.
Thành viên có kinh nghiệm trong tổ bạn cũng còn hỗ trợ cho các dự án khác
và không thể dành toàn thời ghian cho dự án của bạn được.
Làm tài liệu về những rủi ro này, đưa cả kế hoạch của bạn để giảm bớt
chúng và đảm bảo dự án sẽ thành công.

Hướng dẫn: Bạn có thể muốn xem xét việc dùng bảng với các cột sau:
Số hiệu rủi ro ID
Mô tả rủi ro, kể cả điều tệ nhất sẽ xảy ra nếu rủi ro xuất hiện. Điều rất quan
trọng là mô tả tác động của rủi ro là dưới dạng đo được (thường là thời gian
hay tiền bạc), bằng không thì rất khó xác định được liệu rủi ro có là ưu tiên
cao hay không, và bao nhiêu thời gian, tài nguyên và tiền bạc có thể phải chi
tiêu để làm giảm rủi ro. Chẳng hạn sẽ không đáng dành ra 2 năm và 10 triệu
đô la để làm giảm nhẹ rủi ro mà nếu nó xuất hiện, sẽ tốn cho dự án 3 tháng
và 1 triệu đô la.
Xác suất rủi ro (0 – 100)
Tác động rủi ro (0 – 100)
Tầm quan trọng rủi ro (Nhân Xác suất * Tác động)
Ưu tiên rủi ro. Lưu ý rằng phần lớn rủi ro sẽ ở cấp quan trọng, nhưng có
những lúc mà ưu tiên của rủi ro có thể nâng lên hay hạ xuống bất kể tầm
quan trọng.
Kế hoạch quản lí rủi ro, tài liệu mô tả một hay nhiều cách tiếp cận để quản lí
rủi ro. Lưu ý rằng một số rủi ro có thể có kế hoạch quản lí về:
Điều phối rủi ro (chi phí cho rủi ro có thể còn nhiều hơn tác động của rủi ro,
chẳng hạn).
Bảo hiểm rủi ro. Đây thường là phương tiện hiệu quả thời gian nhất để giải
quyết rủi ro.
Giảm thiểu rủi ro. Điều này nghĩa là dành thời gian, tiền bạc và tài nguyên
để cố gắng ngăn ngừa rủi ro khỏi xảy ra, hay ít nhất cũng làm giảm tác động
của rủi ro nếu nó xuất hiện.

Có 2 bài kiểm tra trên lớp (một bài kiểm tra đa chọn lựa và một bài kiểm tra
đúng/sai).
----------------------------------------
Prof. Vu
Carnegie Mellon University
Một số biện pháp quản lý rủi ro Quản lý (QL) rủi ro là một trong các nội
dung cơ bản của bất kỳ bài giảng hoặc tài liệu nào về QL dự án phần mềm
và kỹ nghệ phần mềm nói chung.

Tầm quan trọng của QL rủi ro được nói rất rõ: tỉ lệ

thành công của các dự án CNTT (theo nghĩa đạt
được yêu cầu chất lượng, đúng hạn và không vượt
chi) rất không cao, chủ yếu do không có hoặc thực
hiện không tốt việc phòng ngừa và xử lý các nguy cơ
dẫn đến thất bại hoặc hạn chế thành công của một
dự án.

Tuy đây là “kiến thức vỡ lòng” của QL dự án CNTT (hay chính vì nó

là “kiến thức vỡ lòng”?) nên trên thực tế việc QL rủi ro đã không
được quan tâm đúng mức. Thất bại của các dự án CNTT vẫn xảy ra
thường xuyên, từ những thất bại mang lại hậu quả có tính khủng
hoảng như “112”, đến hàng loạt đề tài và nhiệm vụ ứng dụng được
nói khéo là “hiệu quả chưa cao”! Tỉ lệ cao thường xuyên gặp của thất
bại và kém hiệu quả này có lẽ đã làm nảy sinh ý nghĩ coi đó là
chuyện “tự nhiên” không tránh khỏi. Thậm chí làm xói mòn uy tín của
việc tin học hóa, cũng như niềm tin vào sự nghiệp này. Đây là nỗi
bức xúc lớn của những người liên quan đến công cuộc tin học hóa
của Việt Nam, đã được nhiều người, trong đó có các chuyên gia về
CNTT đề cập nhiều lần và trên nhiều diễn đàn.

Bài viết này xin đề cập một vài biện pháp nhằm QL được rủi ro khi
triển khai các ứng dụng CNTT tại nước ta.
Xử lý sớm các nguy cơ

Để QL được rủi ro, cần nhận biết các nguy cơ và ước lượng được
thiệt hại nếu nguy cơ xảy ra. Tiếp đến là áp dụng các biện pháp để
giám sát, ngăn ngừa, hoặc tránh né nguy cơ đó (gọi là “phòng ngừa
rủi ro”). Nếu “phòng” mà không “tránh” nổi, rủi ro vẫn xảy ra, thì phải
xử lý hậu quả, theo cách hạn chế thiệt hại ở mức thấp nhất và khôi
phục lại các giá trị bị mất mát nhanh chóng và toàn vẹn nhất có thể.
Việc xử lý này thường gọi là các biện pháp “khắc phục rủi ro”, như là
một vế ứng đối với “phòng ngừa rủi ro”. Ai cũng nói là “phòng hơn
chống”, trên thực tế, “phòng” và “chống” phải bổ sung và hỗ trợ lẫn
nhau mới đảm bảo thành công cho một dự án QL rủi ro, theo nghĩa
sau đây: phòng tốt đi đến chống sớm, cái giá phải trả sẽ nhẹ nhàng
hơn.

Tình huống sau đây khá điển hình: một dự án ứng dụng CNTT khi
gặp phải khó khăn không kết thúc được rất thường bị “khê đọng” -
“bỏ thì thương, vương thì tội” trong một thời gian khá dài, dẫn đến
lãng phí lớn về tài sản và nhân lực. Nhiều khi hệ thống dù không khai
thác được như ý, vẫn phải bảo trì, không có phương án giải quyết
dứt điểm dù thời gian đã qua cả năm bảy năm, không thể rút được
bài học và kinh nghiệm một cách đúng đắn cho việc triển khai các dự
án mới... Không hiếm gặp hiện tượng chuyển từ thái cực này sang
thái cực kia (từ tự phát triển sản phẩm sang giao phó hoàn toàn cho
người khác hoặc mua sản phẩm bán sẵn cả gói mà không chú ý
đúng mức đến nhu cầu và khả năng ứng dụng, từ đặt mục tiêu quá
lớn cho tin học hóa sang xóa bỏ hoặc gác lại việc tin học hóa, từ tập
trung xây dựng một phòng CNTT mạnh sang giải tán đội ngũ chuyên
viên tin học...). Như thế là rủi ro này kéo theo rủi ro khác, và cái sau
còn có nguy cơ lớn hơn cái trước rất nhiều.

Đối với các dự án như trên, nếu có chiến lược và biện pháp QL rủi ro
tốt, có thể khắc phục từ sớm các nguy cơ, hậu quả gây ra và phí tổn
khắc phục cũng nhỏ hơn nhiều. Trong một lần trả lời phỏng vấn trên
VTV mới đây, “Thần đèn xứ Bắc” Đỗ Quốc Khánh - chuyên gia về di
dời công trình và chống lún sụt - đã nói đại ý: nếu các công trình lớn
thường xuyên mời chuyên gia giám sát dự phòng lún sập (chi phí
dưới một triệu đồng) thì sẽ tránh được sự tốn kém gấp nhiều lần khi
phải khắc phục chúng. Điều này cũng đúng cả cho các dự án CNTT.
Chú ý đến khả năng tiếp nhận công nghệ

Các đề tài hoặc nhiệm vụ ứng dụng đến nay vẫn có xu hướng tập
trung cho các đầu tư về trang bị công nghệ, chạy theo các công nghệ
tiên tiến, mà không đánh giá một cách xác đáng về khả năng QL và
tiếp nhận công nghệ đó trên thực tế. Phần lớn các đề tài xây dựng hệ
thống thông tin và cơ sở dữ liệu chỉ đầu tư cho việc phát triển hệ
thống, còn sau khi nghiệm thu thì việc cập nhật thông tin và đưa hệ
thống vào sử dụng là chuyện của người khác, thậm chí của đơn vị
khác. Việc cắt rời các giai đoạn của vòng đời một hệ thống như vậy
sẽ không cho phép đầu tư sớm các biện pháp phòng ngừa rủi ro, đặc
biệt là không quan tâm đến các khía cạnh triển khai chứa đựng rất
nhiều nguy cơ.

QL các thay đổi

Tình trạng sau đây rất phố biến: hệ thống vừa nghiệm thu, đã có nhu
cầu nâng cấp hoặc thay đổi. Giải pháp thường được áp dụng là: chia
nhỏ, rút ngắn thời gian dự án. Đây là một chiến thuật có thể hợp lý,
tuy nhiên chỉ là một khía cạnh để đối phó với tình hình. Việc thay đổi
các yêu cầu đối với hệ thống CNTT, môi trường ứng dụng của chúng
và các công cụ thực hiện cần được nhìn nhận và xử lý ở tầm chiến
lược. Do đó, cần phân biệt những thành phần bền vững, có giá trị
khai thác lâu dài, với những công cụ và phương tiện thường biến đổi
nhanh. Thí dụ việc ồ ạt “web hóa”, “portal hóa” các hệ thống thông tin
hiện nay nên được hiểu chỉ là phần nổi, việc xây dựng cơ sở dữ liệu,
cơ sở nội dung mới quyết định hiệu quả các hệ thống đó. Tóm lại, QL
thay đổi là vấn đề chiến lược, chứ không phải chiến thuật. Nó cần
dựa trên quy hoạch ứng dụng tổng thể, dài hơi. Không thể bỏ qua
hoặc xử lý thay đổi kiểu “du kích” và có đến đâu làm đến đấy.

Hiệu quả của các quy định thực tế hàng ngày

Các biện pháp thực tế có thể giảm thiểu đáng kể các nguy cơ cho
các hệ thống thông tin, cũng như khắc phục sớm chúng, có liên quan
rất nhiều đến vấn đề tổ chức và thay đổi nề nếp làm việc.

Hiện nay, gần như tất cả nhân viên đều đã và phải làm việc với máy
tính. Vì thế, các kỹ năng làm việc cơ bản trong môi trường công nghệ
này phải được chuẩn hóa và trở thành chuẩn bắt buộc với mọi người
làm việc. Giống như đi xe gắn máy phải học luật giao thông, có bằng
lái và luôn tuân thủ luật lệ.

Tiếp đến, các quy chế làm việc với máy tính và các tài nguyên trên
máy phải được xây dựng hợp lý và chặt chẽ. “Nội quy” làm việc thời
số hóa này phải được rèn luyện, kiểm tra và áp dụng thường xuyên
đến thành tự giác cho mọi người.

Sau đó, việc giao ban hệ thống và ghi chép biên bản cần được áp
dụng đúng quy định. Các biện pháp xử lý cũng phải được lưu giữ và
giám sát. Các quy định này trên thực tế nhiều nơi đã đặt ra, vấn đề là
chúng phải được áp dụng một cách thực chất, không hình thức, và
phải là công cụ thực sự cho việc giám sát và phát hiện các nguy cơ.

Medals:

Gia nhập: 11/26/2008

Bài viết: 6
Đến từ: HN
Quản lý (QL) rủi ro là một trong các nội dung cơ bản của bất kỳ bài
giảng hoặc tài liệu nào về QL dự án phần mềm và kỹ nghệ phần
mềm nói chung.

Tầm quan trọng của QL rủi ro được nói rất rõ: tỉ lệ thành công của
các dự án CNTT (theo nghĩa đạt được yêu cầu chất lượng, đúng hạn
và không vượt chi) rất không cao, chủ yếu do không có hoặc thực
hiện không tốt việc phòng ngừa và xử lý các nguy cơ dẫn đến thất
bại hoặc hạn chế thành công của một dự án.

Tuy đây là “kiến thức vỡ lòng” của QL dự án CNTT (hay chính vì nó

là “kiến thức vỡ lòng”?) nên trên thực tế việc QL rủi ro đã không
được quan tâm đúng mức. Thất bại của các dự án CNTT vẫn xảy ra
thường xuyên, từ những thất bại mang lại hậu quả có tính khủng
hoảng như “112”, đến hàng loạt đề tài và nhiệm vụ ứng dụng được
nói khéo là “hiệu quả chưa cao”! Tỉ lệ cao thường xuyên gặp của thất
bại và kém hiệu quả này có lẽ đã làm nảy sinh ý nghĩ coi đó là
chuyện “tự nhiên” không tránh khỏi. Thậm chí làm xói mòn uy tín của
việc tin học hóa, cũng như niềm tin vào sự nghiệp này. Đây là nỗi
bức xúc lớn của những người liên quan đến công cuộc tin học hóa
của Việt Nam, đã được nhiều người, trong đó có các chuyên gia về
CNTT đề cập nhiều lần và trên nhiều diễn đàn.

Bài viết này xin đề cập một vài biện pháp nhằm QL được rủi ro khi
triển khai các ứng dụng CNTT tại nước ta.

Xử lý sớm các nguy cơ

Để QL được rủi ro, cần nhận biết các nguy cơ và ước lượng được
thiệt hại nếu nguy cơ xảy ra. Tiếp đến là áp dụng các biện pháp để
giám sát, ngăn ngừa, hoặc tránh né nguy cơ đó (gọi là “phòng ngừa
rủi ro”). Nếu “phòng” mà không “tránh” nổi, rủi ro vẫn xảy ra, thì phải
xử lý hậu quả, theo cách hạn chế thiệt hại ở mức thấp nhất và khôi
phục lại các giá trị bị mất mát nhanh chóng và toàn vẹn nhất có thể.
Việc xử lý này thường gọi là các biện pháp “khắc phục rủi ro”, như là
một vế ứng đối với “phòng ngừa rủi ro”. Ai cũng nói là “phòng hơn
chống”, trên thực tế, “phòng” và “chống” phải bổ sung và hỗ trợ lẫn
nhau mới đảm bảo thành công cho một dự án QL rủi ro, theo nghĩa
sau đây: phòng tốt đi đến chống sớm, cái giá phải trả sẽ nhẹ nhàng
hơn.

Tình huống sau đây khá điển hình: một dự án ứng dụng CNTT khi
gặp phải khó khăn không kết thúc được rất thường bị “khê đọng” -
“bỏ thì thương, vương thì tội” trong một thời gian khá dài, dẫn đến
lãng phí lớn về tài sản và nhân lực. Nhiều khi hệ thống dù không khai
thác được như ý, vẫn phải bảo trì, không có phương án giải quyết
dứt điểm dù thời gian đã qua cả năm bảy năm, không thể rút được
bài học và kinh nghiệm một cách đúng đắn cho việc triển khai các dự
án mới... Không hiếm gặp hiện tượng chuyển từ thái cực này sang
thái cực kia (từ tự phát triển sản phẩm sang giao phó hoàn toàn cho
người khác hoặc mua sản phẩm bán sẵn cả gói mà không chú ý
đúng mức đến nhu cầu và khả năng ứng dụng, từ đặt mục tiêu quá
lớn cho tin học hóa sang xóa bỏ hoặc gác lại việc tin học hóa, từ tập
trung xây dựng một phòng CNTT mạnh sang giải tán đội ngũ chuyên
viên tin học...). Như thế là rủi ro này kéo theo rủi ro khác, và cái sau
còn có nguy cơ lớn hơn cái trước rất nhiều.
Đối với các dự án như trên, nếu có chiến lược và biện pháp QL rủi ro
tốt, có thể khắc phục từ sớm các nguy cơ, hậu quả gây ra và phí tổn
khắc phục cũng nhỏ hơn nhiều. Trong một lần trả lời phỏng vấn trên
VTV mới đây, “Thần đèn xứ Bắc” Đỗ Quốc Khánh - chuyên gia về di
dời công trình và chống lún sụt - đã nói đại ý: nếu các công trình lớn
thường xuyên mời chuyên gia giám sát dự phòng lún sập (chi phí
dưới một triệu đồng) thì sẽ tránh được sự tốn kém gấp nhiều lần khi
phải khắc phục chúng. Điều này cũng đúng cả cho các dự án CNTT.

Chú ý đến khả năng tiếp nhận công nghệ

Các đề tài hoặc nhiệm vụ ứng dụng đến nay vẫn có xu hướng tập
trung cho các đầu tư về trang bị công nghệ, chạy theo các công nghệ
tiên tiến, mà không đánh giá một cách xác đáng về khả năng QL và
tiếp nhận công nghệ đó trên thực tế. Phần lớn các đề tài xây dựng hệ
thống thông tin và cơ sở dữ liệu chỉ đầu tư cho việc phát triển hệ
thống, còn sau khi nghiệm thu thì việc cập nhật thông tin và đưa hệ
thống vào sử dụng là chuyện của người khác, thậm chí của đơn vị
khác. Việc cắt rời các giai đoạn của vòng đời một hệ thống như vậy
sẽ không cho phép đầu tư sớm các biện pháp phòng ngừa rủi ro, đặc
biệt là không quan tâm đến các khía cạnh triển khai chứa đựng rất
nhiều nguy cơ.

QL các thay đổi

Tình trạng sau đây rất phố biến: hệ thống vừa nghiệm thu, đã có nhu
cầu nâng cấp hoặc thay đổi. Giải pháp thường được áp dụng là: chia
nhỏ, rút ngắn thời gian dự án. Đây là một chiến thuật có thể hợp lý,
tuy nhiên chỉ là một khía cạnh để đối phó với tình hình. Việc thay đổi
các yêu cầu đối với hệ thống CNTT, môi trường ứng dụng của chúng
và các công cụ thực hiện cần được nhìn nhận và xử lý ở tầm chiến
lược. Do đó, cần phân biệt những thành phần bền vững, có giá trị
khai thác lâu dài, với những công cụ và phương tiện thường biến đổi
nhanh. Thí dụ việc ồ ạt “web hóa”, “portal hóa” các hệ thống thông tin
hiện nay nên được hiểu chỉ là phần nổi, việc xây dựng cơ sở dữ liệu,
cơ sở nội dung mới quyết định hiệu quả các hệ thống đó. Tóm lại, QL
thay đổi là vấn đề chiến lược, chứ không phải chiến thuật. Nó cần
dựa trên quy hoạch ứng dụng tổng thể, dài hơi. Không thể bỏ qua
hoặc xử lý thay đổi kiểu “du kích” và có đến đâu làm đến đấy.
Hiệu quả của các quy định thực tế hàng ngày

Các biện pháp thực tế có thể giảm thiểu đáng kể các nguy cơ cho
các hệ thống thông tin, cũng như khắc phục sớm chúng, có liên quan
rất nhiều đến vấn đề tổ chức và thay đổi nề nếp làm việc.

Hiện nay, gần như tất cả nhân viên đều đã và phải làm việc với máy
tính. Vì thế, các kỹ năng làm việc cơ bản trong môi trường công nghệ
này phải được chuẩn hóa và trở thành chuẩn bắt buộc với mọi người
làm việc. Giống như đi xe gắn máy phải học luật giao thông, có bằng
lái và luôn tuân thủ luật lệ.

Tiếp đến, các quy chế làm việc với máy tính và các tài nguyên trên
máy phải được xây dựng hợp lý và chặt chẽ. “Nội quy” làm việc thời
số hóa này phải được rèn luyện, kiểm tra và áp dụng thường xuyên
đến thành tự giác cho mọi người.

Sau đó, việc giao ban hệ thống và ghi chép biên bản cần được áp
dụng đúng quy định. Các biện pháp xử lý cũng phải được lưu giữ và
giám sát. Các quy định này trên thực tế nhiều nơi đã đặt ra, vấn đề là
chúng phải được áp dụng một cách thực chất, không hình thức, và
phải là công cụ thực sự cho việc giám sát và phát hiện các nguy cơ.

(ItGateVn)
Quản trị rủi ro trong dự án phần mềm
Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sảbn xuất và kinh
doanh, và dự án phần mềm cũng không ngoại lệ. Tuy nhiên, với đặc
thù riêng của mình, nhận diện và kiểm soát rủi ro trong dự án phần
mềm là điều không đơn giản. Trong thực tế, nhiều dự án phần mềm
đã bỏ qua hoặc kiểm soát rủi ro sơ sài, chiếu lệ dẫn đến kết quả thất
bại, khách hàng phàn nàn về chất lượng hoặc lỗ vốn do chi phí tăng
cao.
Rủi ro trong các dự án phần mềm

Thông thường, "rủi ro" dùng để chỉ một hay nhiều sự việc chưa
nhưng có khả năng xảy ra trong tương lai có tác động đến dự án, và
khi sự việc đó xảy ra thường sẽ gây ảnh hưởng xấu, thậm chí là "tai
nạn" cho dự án, cản trở dự án đạt được mục tiêu của mình. Rủi ro
thường được nhận biết dựa vào một số dấu hiệu báo trước, đôi khi
dựa vào kinh nghiệm của các dự án tương tự trước đây.

Quản lý rủi ro có vai trò khá quan trọng trong toàn bộ tiến trình quản
lý dự án. Trong cả 2 bộ mô hình và tiêu chuẩn nổi tiếng được ứng
dụng nhiều trong dự án phần mềm là CMMi (Capability Maturity
Model Integration) của viện Công nghệ Phần mềm Hoa Kỳ (SEI) và
PMP (Project Management Professional) của viện Quản trị Dự án PMI
(Project Management Institude) đều xem quản lý rủi ro là một trong
những hoạt động cơ bản nhất của quá trình quản trị dự án.

Mặc dù nhận diện và kiểm soát tốt rủi ro có khả năng ảnh hưởng đến
dự án đòi hỏi sự tham gia của nhiều người, tuy nhiên người có vai trò
trực tiếp và quan trọng nhất là trưởng dự án. Do đó, một tiêu chí bắt
buộc của một trưởng dự án giỏi là khả năng kiểm soát tốt rủi ro.

Quy trình quản lý rủi ro

Nhận diện và kiểm soát tốt rủi ro chỉ bằng kỹ năng và kinh nghiệm cá
nhân không chưa đủ, việc kiểm soát rủi ro phải được thực hiện theo
một quy trình chặt chẽ và phù hợp với đặc thù, mục tiêu và ngân sách
của dự án.

Tổng quát, quy trình cơ quản lý rủi ro bao gồm các bước chính được
trình bày ở Hình 1.
Ở mức chi tiết hơn, quy trình quản lý rủi ro bao gồm các bước cùng
với trình tự xử lý và mối quan hệ giữa chúng như trình bày ở Hình 2.

Nhận diện rủi ro

Xác định được chính xác các nguồn có khả năng phát sinh rủi ro là
điều không dễ dàng. Thông thường rủi ro xuất hiện từ các nguồn sau:

• Ngân sách/nguồn tài trợ cho dự án

Hình 1: Quy trình cơ bản quản lý rủi ro

• Thời gian thực hiện dự án

• Thay đổi về phạm vi và yêu cầu dự án

• Khó khăn về kỹ thuật

• Vấn đề liên quan đến nhân lực

• Hợp đồng giữa 2 (hoặc nhiều) bên

• Trong kinh doanh

• Môi trường, luật pháp, chính trị, văn hóa...

Để nhận diện được rủi ro, có nhiều kỹ thuật được áp dụng. Các kỹ
thuật này giúp cho dự án "khoanh vùng" và xác định dấu hiệu xuất
hiện rủi ro, vừa giúp tránh bỏ sót các dấu hiệu, vừa làm tăng kết quả
và độ tin cậy của việc nhận diện các rủi ro. Từng kỹ thuật đều có
những hạn chế riêng, do đó việc kết hợp các kỹ thuật để có kết quả
tốt nhất là cần thiết. Các kỹ thuật được sử dụng rộng rãi bao gồm:

• Xem xét tài liệu

Là cách thức xác định rủi ro cơ bản, đơn giản và thông dụng. Phương
thức này thường bao gồm việc xem xét các tài liệu của dự án như
các kế hoạch, giả định, cam kết với khách hàng, cơ chế thông tin
giữa 2 bên, môi trường dự án, thông tin của các dự án khác trong quá
khứ..., từ đó nhận diện các yếu tố có khả năng gây ra rủi ro cho dự
án.
Hình 2: Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi
ro

• Động não

Đây là kỹ thuật được sử dụng rộng rãi nhất để nhận diện rủi ro và hầu
như bất cứ ai trong đời cũng đã từng sử dụng kỹ thuật này cho nhiều
vấn đề khác nhau trong cuộc sống. Đó là sự đóng góp ý kiến từ nhiều
người khác nhau, từ các chuyên gia đến các thành viên của dự án,
hoặc bất cứ ai có liên quan hoặc có kinh nghiệm về các vấn đề xảy ra
trong dự án. Từ những ý kiến này (có thể nhiều ý trùng nhau), các rủi
ro sẽ được định vị nhanh chóng.

• Kỹ thuật Delphi

Tương tự kỹ thuật "Động não", khác biệt chỉ là các thành viên tham
gia không biết nhau, do đó kỹ thuật này thích hợp nếu các thành viên
ở xa nhau. Ngày nay kỹ thuật Delphi thực hiện dễ hơn trước đây do
sự trợ giúp của email và hệ thống hỗ trợ làm việc từ xa. Do thành
viên là "vô danh" nên kỹ thuật này hạn chế nhược điểm của kỹ thuật
"Động não" là một vài cá nhân (chẳng hạn sếp) sẽ có ảnh hưởng đến
suy nghĩ của các thành viên khác.
• Nhóm danh nghĩa

Nhóm làm việc từ 7-10 người, mỗi thành viên sẽ ghi ý kiến riêng của
mình (thường là 1 rủi ro quan trọng nhất) trên 1 mẫu giấy. Các ý kiến
sau đó được tập hợp và nhóm sẽ phân tích và đánh giá trên từng ý
kiến. Kết quả là rủi ro quan trọng nhất được sắp xếp trên cùng. Kỹ
thuật này không chỉ dùng để nhận biết mà còn để đánh giá rủi ro;
không loại bỏ hoàn toàn những người có ảnh hưởng; được thực hiện
nhanh và ít tốn kém hơn kỹ thuật Delphi

• Hỏi ý kiến chuyên gia

Thường được dùng để hỏi ý kiến cá nhân của những người có nhiều
kinh nghiệm từ các dự án tương tự hoặc các dự án đã hoàn thành
trong quá khứ. Công cụ sử dụng thường là bảng câu hỏi có trả lời
sẵn để chọn lựa, hoặc để trống cho người được hỏi tự ghi ý kiến
hoặc trả lời.

• Sử dụng phiếu kiểm tra hoặc bảng câu hỏi

Phiếu kiểm tra hoặc bảng câu hỏi thường đúc kết kinh nghiệm từ các
dự án quá khứ đặc biệt và các dự án tương tự, trong đó liệt kê những
rủi ro thường hay gặp nhất. Phiếu này giúp cho dự án nhanh chóng
xác định rủi ro có thể xảy đến cho dự án.

Kỹ thuật này có thể tham khảo các kinh nghiệm từ bên ngoài, một
trong những tham khảo tốt theo cách này là sử dụng bảng phân loại
và liệt kê các rủi ro thường gặp của viện Kỹ thuật Phần mềm Hoa Kỳ
(SEI Taxonomy-Based Risk Identification) có thể tải về miễn phí tại
http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.h
tml.

• Sử dụng biểu đồ

Sử dụng nhiều dạng biểu đồ khác nhau để phân tích và xác định rủi
ro, chẳng hạn biểu đồ xương cá (còn gọi là biểu đồ nhân quả) được
sử dụng để chỉ sự liên quan và ảnh hưởng của các yếu tố rủi ro khác
nhau, từ đó xác định rủi ro có thể ảnh hưởng đến dự án. Biểu đồ quy
trình cho thấy sự nối tiếp trong chuỗi các sự kiện, từ đó xác định các
yếu tố có thể gây rủi ro cho dự án. Hình 3 là một ví dụ về việc sử
dụng biểu đồ xương cá để định vị các rủi ro.

Phân tích và phân loại rủi ro

Trong thực tế, những rủi ro có thể xảy ra trong một dự án là khá
nhiều, và việc giải quyết hết tất cả các rủi ro là không cần thiết, cũng
như sẽ làm phá sản ngân sách của dự án.

Thông thường người ta áp dụng nguyên tắc 20/80 để xác định và giải
quyết những rủi ro quan trọng, những nguyên nhân gốc có ảnh
hưởng lớn nhất đến sự thành công của dự án, trong chừng mực cân
nhắc cẩn thận ngân sách dự án cũng như một số yếu tố đặc biệt
khác. Điều này dẫn đến việc dự án phải phân tích để chọn ra những
rủi ro cần giải quyết đó. Có nhiều kỹ thuật phân tích rủi ro được sử
dụng, kỹ thuật thường được sử dụng bao gồm các phân tích chính
sau:

• Phân tích khả năng xuất hiện của rủi ro

Có 4 mức để đo lường khả năng xuất hiện của rủi ro, mỗi mức độ
được gán với một giá trị số (tùy dự án) để có thể ước lượng sự quan
trọng của nó.
• 6 - Thường xuyên: Khả năng xuất hiện rủi ro rất cao, xuất hiện trong
hầu hết dự án

• 4 - Hay xảy ra: Khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều
dự án

• 2 - Đôi khi: Khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở một
số ít dự án

• 1 - Hiếm khi: Khả năng xuất hiện thấp, chỉ xuất hiện trong những
điều kiện nhất định.

Hình 3: Ví dụ đơn giản dùng sơ đồ xương cá định vị rủi ro

• Phân tích mức tác động của rủi ro

Có 4 mức để đo lường mức tác động của rủi ro, mỗi mức độ được
gán với một giá trị số (tùy dự án) để có thể ước lượng sự tác động
của nó.

• 8 - Trầm trọng: Có khả năng rất cao làm dự án thất bại

• 6 - Quan trọng: Gây khó khăn lớn và làm dự án không đạt được các
mục tiêu

• 2 - Vừa phải: Gây khó khăn cho dự án, ảnh hưởng việc đạt các mục
tiêu của dự án

• 1 - Không đáng kể: Gây khó khăn không đáng kể.

• Phân tích thời điểm xuất hiện rủi ro

Có 4 mức để ước lượng thời điểm rủi ro xuất hiện, mỗi mức được
gán với một giá trị số (tùy dự án) để có thể ước lượng sự tác động
của nó.

• 6 - Ngay lập tức: Rủi ro xuất hiện gần như tức khắc

• 4 - Rất gần: Rủi ro sẽ xuất hiện trong thời điểm rất gần thời điểm
phân tích

• 2 - Sắp xảy ra: Rủi ro sẽ xuất hiện trong tương lai gần

• 1 - Rất lâu: Rủi ro sẽ xuất hiện trong tương lai xa hoặc chưa định
được.

• Ghi chú: Các giá trị số cho trên chỉ mang tính tham khảo và minh
họa, giá trị của chúng được định tùy tổ chức, tùy dự án.

• Ước lượng và phân hạng các rủi ro

Rủi ro sau đó được tính giá trị để ước lượng bằng công thức:

Risk Exposure = Risk Impact * Risk Probability * Time Frame

Tiếp theo rủi ro được phân hạng từ cao đến thấp dựa theo các giá trị
Risk Exposure tính toán được. Tùy theo tổ chức và đặc thù từng dự
án, trưởng dự án (hoặc người được phân công) sẽ xác định những
rủi ro nào cần đưa vào kiểm soát, với các mức ưu tiên khác nhau.
Hình 4: Một số chiến lược và minh họa các phương pháp đối phó rủi
ro thường gặp

Kiểm soát rủi ro

Kiểm soát rủi ro bắt đầu với việc chọn lựa chiến lược và phương
pháp đối phó rủi ro. Có nhiều chiến lược và phương pháp đối phó
khác nhau, tùy theo tình huống dự án, môi trường và đặc thù của
từng rủi ro. Trong thực tế, các chiến lược phổ biến nhất bao gồm
(Hình 4):

• Tránh né

Dùng "đường đi khác" để né tránh rủi ro, đường đi mới có thể không
có rủi ro, có rủi ro nhẹ hơn, hoặc chi phí đối phó rủi ro thấp hơn.
Chẳng hạn:

• Thay đổi phương pháp, công cụ thực hiện, thay đổi con người

• Thương lượng với khách hàng (hoặc nội bộ) để thay đổi mục tiêu.

• Chuyển giao

Giảm thiểu rủi ro bằng cách chia sẻ tác hại khi chúng xảy ra. Chẳng
hạn:
• Đề nghị với khách hàng chấp nhận và chia sẻ rủi ro (tăng thời gian,
chi phí...)

• Báo cáo ban lãnh đạo để chấp nhận tác động và chi phí đối phó rủi
ro

• Mua bảo hiểm để chia sẻ chi phí khi rủi ro xảy ra.

• Giảm nhẹ

Thực thi các biện pháp để giảm thiểu khả năng xảy ra rủi ro hoặc
giảm thiểu tác động và chi phí khắc phục rủi ro nếu nó xảy ra. Chẳng
hạn:

• Cảnh báo và triệt tiêu các yếu tố làm cho rủi ro xuất hiện

• Điều chỉnh các yếu tố có liên quan theo dây chuyền để rủi ro xảy ra
sẽ ít có tác động

• Chấp nhận

Đành chấp nhận "sống chung" với rủi ro trong trường hợp chi phí loại
bỏ, phòng tránh, làm nhẹ rủi ro quá lớn (lớn hơn chi phí khắc phục
tác hại), hoặc tác hại của rủi ro nếu xảy ra là nhỏ hay cực kỳ thấp. Kế
hoạch đối phó có thể là:

• Thu thập hoặc mua thông tin để có kế hoạch kiểm soát tốt hơn

• Lập kế hoạch khắc phục tác hại khi rủi ro xảy ra.

Sử dụng Cây quyết định

Trong một số trường hợp phức tạp, thường rất khó xác định rủi ro
nào nên đặt ưu tiên cao để kiểm soát, hoặc nên chọn chiến lược kiểm
soát nào phù hợp nhất nên người ta thường sử dụng kỹ thuật hỗ trợ
ra quyết định thông dụng trong quản lý là Cây quyết định để tính toán
giá trị đạt được hoặc thiệt hại xảy ra khi thực hiện một hành động nào
đó.

Cây quyết định là một biểu đồ dạng cây có nhiều nút, mỗi nút có
nhiều nhánh rẽ, mỗi nhánh sẽ trả lời câu hỏi "làm" hay "không làm",
hoặc là một khả năng để một tình huống xuất hiện với một xác suất
nào đó. Các giá trị cuối cùng của các nhánh sẽ giúp xác định xem nên
chọn phương án nào cho giá trị tốt nhất. Hình 5 là một Cây quyết định
đơn giản để tính toán giá trị đạt được theo các phương án khác nhau,
giúp chọn lựa phương án tốt nhất, theo đó phương án Y cuối cùng đã
được chọn do giá trị trả về là lớn nhất.

Giám sát và điều chỉnh

Bao gồm hoạt động giám sát để bảo đảm các chiến lược đối phó rủi
ro được lên kế hoạch và thực thi chặt chẽ. Việc giám sát cũng nhằm
mục đích điều chỉnh các chiến lược hoặc kế hoạch đối phó nếu chúng
tỏ ra không hiệu quả, không khả thi, ngốn quá nhiều ngân sách, hoặc
để đáp ứng với rủi ro mới xuất hiện, hoặc sự biến tướng của rủi ro đã
được nhận diện trước đó.

Kết quả giám sát có thể được báo cáo định kỳ đến tất cả những
người có liên quan, đến quản lý cấp cao, hoặc đến khách hàng nếu
cần thiết.

Trong thực tế, do các yếu tố liên quan đến dự án thay đổi liên tục,
chu trình quản lý rủi ro không đi theo đường thẳng mà được lặp lại và
điều chỉnh liên tục giữa các chặng. Các rủi ro liên tục được điều chỉnh
hoặc nhận diện mới, do đó các chiến lược và kế hoạch đối phó cũng
luôn được thay đổi để bảo đảm chúng khả thi và có hiệu quả.

Kết luận

Rủi ro là một yếu tố tồn tại trong mọi dự án phần mềm. Một người
quản trị dự án giỏi phải là người không ngạc nhiên và có khả năng xử
lý bất kỳ sự kiện nào xảy ra có thể gây bất lợi cho dự án, điều đó
đồng nghĩa với việc các rủi ro ảnh hưởng đến dự án phải được "thấy
trước", cùng với các kế hoạch để giảm thiểu khả năng xuất hiện cũng
như tác hại khi chúng xuất hiện. Quy trình kiểm soát chặt chẽ, kinh
nghiệm chuyên gia kết hợp với kỹ thuật nhận diện và kiểm soát rủi ro
là những yếu tố quan trọng nhất để kiểm soát tốt rủi ro xảy ra trong
dự án.

Ngô Văn Toàn

Quản trị rủi ro trong dự án phần mềm

Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sản xuất và kinh doanh, và
dự án phần mềm cũng không ngoại lệ. Tuy nhiên, với đặc thù riêng của
mình, nhận diện và kiểm soát rủi ro trong dự án phầm mềm là không đơn
giản. Trong thực tế, nhiều dự án phần mềm đã bỏ qua hoặc kiểm soát rủi ro
sơ sài, chiếu lệ dẫn đến kết quả thất bại, khách hàng phàn nàn về chất lượng,
hoặc lỗ vốn do chi phí tăng cao.
Rủi ro trong các dự án phần mềm

Thông thường, "rủi ro" dùng để chỉ một hay nhiều sự việc chưa nhưng có khả
năng xảy ra trong tương lai có tác động đến dự án, và khi sự việc đó xảy ra
thường sẽ gây ảnh hưởng xấu, thậm chí là "tai nạn" cho dự án, cản trở dự án
đạt được mục tiêu của mình. Rủi ro thường được nhận biết dựa vào một số
dấu hiệu báo trước, đôi khi dựa vào kinh nghiệm của dự án tương tự trước
đây.
Quản lý rủi ro có vai trò khá quan trọng trong toàn bộ tiến trình quản lý dự
án. Trong cả hai mô hình và tiêu chuẩn nổi tiếng được ứng dụng nhiều trong
dự án phần mềm là CMMi (Capability Maturity Model Intergra-tion) của
viện Công nghệ phần mềm Hoa Kỳ (SEI) và PMP (Project Mangement
Professional) của viện Quản trị dự án PMI (Project Management Institute)
đều xem quản lý rủi ro là một trong những hoạt động cơ bản nhất của quá
trình quản trị dự án.
Mặc dù nhận diện và kiểm soát tốt rủi ro có khả năng ảnh hưởng đến dự án
đòi hỏi sự tham gia của nhiều người, tuy nhiên người có vai trò trực tiếp và
quan trọng nhất là trưởng dự án. Do đó, một tiêu chí bắt buộc của một trưởng
dự án giỏi là khả năng kiểm soát tốt rủi ro.
Quy trình quản lý rủi ro
Nhận diện và kiểm soát tốt rủi ro chỉ bằng kỹ năng và kinh nghiệm cá nhận
không chưa đủ, việc khiểm soát rủi ro phải được thực hiện theo một quy trình
chặt chẽ và phù hợp với đặc thù, mục tiêu và ngân sách của dự án.
Tổng quát, quy trình cơ bản quản lý rủi ro bao gồm các bước chính được
trình bày ở hình 1.
Ở mức chi tiết hơn, quy trình quản lý rủi ro bao gồm các bước cùng với trình
tự xử lý và mối quan hệ giữa chúng như trình bày ở hình 2.
Hình 2: Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi
ro.

Nhận diện rủi ro

Xác định được chính xác các nguồn có khả năng phát sinh rủi ro là điều
không dễ dàng. Thông thường, rủi ro xuất hiện từ các nguồn sau:
- Ngân sách/nguồn tài trợ cho dự án
- Thời gian thực hiện dự án
- Thay đổi về phạm vi và yêu cầu của dự án
- Khó khăn về kỹ thuật
- Vấn đề liên quan đến nhân lực
- Hợp đồng giữa 2 (hoặc nhiều) bên trong kinh doanh
- Môi trường, luật pháp, chính trị, văn hóa...
Để nhận diện được rủi ro, có nhiều kỹ thuật được áp dụng. Các kỹ thuật này
giúp cho dự án "khoanh vùng" và xác định dấu hiệu rui ro, vừa giúp tránh bỏ
sót các dấu hiệu vừa làm tăng kết quả và độ tin cậy của việc nhận diện các
rủi ro. Từng kỹ thuật đều có những hạn chế riêng, do đó việc kết hợp các kỹ
thuật để có kết quả tốt nhất là cần thiết. Các kỹ thuật được sử dụng rộng rãi
bao gồm:
Xem xét tài liệu
Là cách thức xác định rủi ro cơ bản, đơn giản và thông dụng. Phương pháp
này thường bao gồm việc xem xét các tài liệu của dự án như các kế hoạch,
giả định, cam kết với khách hàng, cơ chế thông tin giữa 2 bên, môi trường dự
án, thông tin của các dự án khác trong quá khứ... từ đó nhận diện các yếu tố
có khả năng gây ra rủi ro cho dự án.
Động não
Đây là kỹ thuật được sử dụng rộng rãi nhất để nhận diện rủi ro và hầu như
bất cứ ai trong đời cũng đã từng sử dụng kỹ thuật này cho nhiều vấn đề khác
nhau trong cuộc sống. Đó là sự đóng góp ý kiến từ nhiều người khác nhau, từ
các chuyên gia đến các thành viên của dự án, hoặc bất cứ ai có liên quan
hoặc có kinh nghiệm về các vấn đề xảy ra trong dự án. Từ những ý kiến này
(có thể trùng nhau), các rủi ro sẽ được định vị nhanh chóng.
Kỹ thuật Delphi
Tương tự kỹ thuật "Động não", khác biệt chỉ là các thành viên tham gia
không biết nhau, do đó kỹ thuật này thích hợp nếu các thành viên ở xa nhau.
Ngày nay kỹ thuật Delphi thực hiện dễ hơn trước đây do sự trợ giúp của
email và hệ thống hỗ trợ làm việc từ xa. Do thành viên là "vô danh" nên kỹ
thuật này hạn chế nhược điểm của kỹ thuật "Động não" là một vài cá nhân
(chẳng hạn sếp) sẽ có ảnh hưởng đến suy nghĩ của các thành viên khác.
Nhóm danh nghĩa
Nhóm làm việc từ 7-10 người, mỗi thành viên sẽ ghi ý kiến riêng của mình
(thường là 1 rủi ro quan trọng nhất) trên 1 mẫu giấy. Các ý kiến sau đó được
tập hợp và nhóm sẽ phân tích và đánh giá trên từng ý kiến. Kết quả là rủi ro
quan trọng nhất được sắp xếp trên cùng. Kỹ thuật này không chỉ dùng để
nhận biết mà còn để đánh giá rủi ro; không loại bỏ hoàn toàn những người có
ảnh hưởng; được thực hiện nhanh và ít tốn kém hơn kỹ thuật Delphi.
Hỏi ý kiến chuyên gia
Thường được dùng để hỏi ý kiến cá nhân của những người có nhiều kinh
nghiệm từ các dự án tương tự hoặc các dự án đã hoàn thành trong quá khứ.
Công cụ sử dụng thường là bảng câu hỏi có trả lời sẵn để chọn lựa, hoặc để
trống cho người được hỏi tự ghi ý kiến hoặc trả lời.
Sử dụng phiếu kiểm tra hoặc bảng câu hỏi
Phiếu kiểm tra hoặc bảng câu hỏi thường đúc kết kinh nghiệm từ các dự án
quá khứ đặc biệt hoặc các dự án tương tự, trong đó liệt kê các rủi ro thương
hay gặp nhất. Phiếu này giúp cho dự án nhanh chóng xác định rủi ro có thể
xảy đến cho dự án.
Kỹ thuật này có thể tham khảo các kinh nghiệm từ bên ngoài, một trong
những tham khảo tốt theo cách này là sử dụng bảng phân loại và liệt kê các
rủi ro thường gặp của Viện Kỹ thuật phần mềm Hoa Kỳ (SEI Taxonomy-
based Risk Identification) có thể tải về miễn phí tại
http://sei.cmu.edu/publications/documents/93.reports/93.tr.006.html.
Sử dụng biểu đồ
Sử dụng nhiều dạng biểu đồ khác nhau để phân tích và xác định rủi ro, chẳng
hạn biểu đồ xương cá (còn gọi là biểu đồ nhân quả) được sử dụng để chỉ sự
liên quan và nahr hưởng của các yếu tố rủi ro khác nhau, từ đó có thể xác
định rủi ro có thể ảnh hưởng đến dự án.

Hình 3: Ví dụ đơn giản dùng sơ đồ xương cá định vị rủi ro

Biểu đồ quy trình cho thấy sự nối tiếp trong chuỗi các sự kiện, từ đó xác định
các yếu tố có thể gây rủi ro cho dự án. Hình 3 là một ví dụ về việc sử dụng
biểu đồ xương cá để định vị các rủi ro.
Phân tích và phân loại rủi ro
Trong thực tế, những rủi ro có thể xáy ra trong một dự án là khá nhiều, và
việc giải quyết hết tất cả các rủi ro là không cần thiết, cũng như sẽ làm phá
sản ngân sách của dự án.
Thông thường người ta áp dụng nguyên tắc 20/80 để xác định và giải quyết
những rủi ro quan trọng, những nguyên nhân gốc có ảnh hưởng lớn nhất đến
sự thành công của dự án, trong chừng mực cân nhắc cẩn thận ngân sách dự
án cũng như một số yếu tố đặc biệt khác. Điều này dẫn đến việc dự án phải
phân tích đê chọn ra những rủi ro cần giải quyết đó. Có nhiều kỹ thuật phân
tích rủi ro được sử dụng, kỹ thuật thường được sử dụng bao gồm các phân
tích chính sau:
Phân tích khả năng xuất hiện của rủi ro
Có 4 mức để đo lường khả năng xuất hiện của rủi ro, mỗi mức độ được gắn
với một giá trị số (tùy dự án) để có thể ước lượng sự quan trọng của nó.

• 6-thương xuyên: Khả năng xuất hiện rủi ro rất cao, xuất hiện trong hầu
hết dự án.
• 4-hay xảy ra: Khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều dự
 án.
• 2-đôi khi: Khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở một số
ít dự án.
• 1-hiếm khi: Khả năng xuất hiện thấp, chỉ xuất hiện trong những điều
kiện nhất định.

Phân tích mức tác động của rủi ro

Có 4 mức để đo lường mức tác động của rủi ro, mỗi mức độ được gắn với 1
giá trị số (tùy dự án) để có thể ước lượng sự tác động của nó.

• 8- trầm trọng: Có khả năng rất cao làm dự án thất bại.

• 6- quan trọng: Gây khó khăn lớn và làm dự án không đạt được các
mục tiêu.
• 2- vừa phải: Gây khó khăn cho dự án, ảnh hưởng việc đạt mục tiêu của
dự án.
• 1- không đáng kể: Gây khó khăn không đáng kể.

Phân tích thời điểm xuất hiện rủi ro

Có 4 mức để ước lượng thời điểm rủi ro xuất hiện, mỗi mức được gắn với
một giá trị số (tùy dự án) để có thể ước lượng sự tác động của nó.

• 6- ngay lập tức: Rủi ro xuất hiện gần như tức khắc.
• 4- rất gần: Rủi ro sẽ xuất hiện trong thời điểm rất gần thời điểm phân
tích.
• 2- sắp xảy ra: Rủi ro sẽ xuất hiện trong tương lai gần.
• 1- rất lâu: Rủi ro sẽ xuất hiện trong tương lai xa hoặc chưa định được.

Ghi chú: Các giá trị số cho trên chỉ mang tính tham khảo và minh họa, giá trị
của chúng được định tùy tổ chức, tùy dự án.
Ước lượng và phân hạng các rủi ro
Rủi ro sau đó được tính giá trị để ước lượng bằng công thức:
Risk Exposure = Risk Impact * Risk Probability * Time Frame
Tiếp theo rủi ro được phân hạng từ cao đến thấp dựa theo các giá trị Risk
Exposure tính toán được. Tùy theo tổ chức và đặc thù từng dự án, trưởng dự
án (hoặc người được phân công) sẽ xác định những rủi ro nào cần đưa vào
kiểm soát, với các mức ưu tiên khác nhau.
 
Kiểm soát rủi ro
Kiểm soát rủi ro bắt đầu với việc chọn lựa chiến lược và phương pháp đối
phó rủi ro. Có nhiều chiến lược và phương pháp đối phó khác nhau, tùy theo
tình huống dự án, môi trường và đặc thù của từng rủi ro. Trong thực tế, các
chiến lược phổ biến nhất bao gồm (Hình 4):

Hình 4: Một số chiến lược và minh họa các phương pháp đối phó rủi ro
thường gặp

Tránh né
Dùng "đường đi khác" để né tránh rủi ro, đường đi mới có thể không có rủi
ro, có rủi ro nhẹ hơn, hoặc chi phí đối phó thấp hơn. Chẳng hạn:

• Thay đổi phương pháp, công cụ thực hiện, thay đổi con người.
• Thương lượng với khách hàng (hoặc nội bộ) để thay đổi mục tiêu.

Chuyển giao
Giảm thiểu rủi ro bằng cách chia sẻ tác hại khi chúng xảy ra. Chẳng hạn:

• Đề nghị với khách hàng chấp nhận và chia sẻ rủi ro (tăng thời gian, chi
phí,...)
• Báo cáo ban lãnh đạo để chấp nhận tác động và chi phí đối với rủi ro.
• Mua bảo hiểm để chia sẽ chi phí khi rủi ro xảy ra.

Giảm nhẹ
Thực thi các biện pháp để giảm thiểu khả năng xảy ra rủi ro hoặc giảm thiểu
tác động và chi phí khắc phục rủi ro nếu có xảy ra. Chẳng hạn:
 • Cảnh báo và triệt tiêu các yếu tố làm rủi ro xuất hiện.
• Điều chỉnh các yếu tố có liên quan theo dây chuyền để rủi ro xảy ra sẽ
ít có tác động.

Chấp nhận
Đành chấp nhận "sống chung" với rủi ro trong trường hợp chi phí loại bỏ,
phòng tránh, làm nhẹ rủi ro quá lớn (lớn hơn chi phí khắc phục tác hại), hoặc
tác hại của rủi ro nếu xảy ra là nhỏ hay cực kỳ thấp. Kế hoạch đối phó có thể
là:

• Thu thập hoặc mua thông tin để có kế hoạch kiểm soát tốt hơn.
• Lập kế hoạch khắc phục tác hại khi rủi ro xảy ra.

Sử dụng Cây quyết định

Trong một số trường hợp phức tạp, thường rất khó xác định rủi ro nào nên
đặt ưu tiên cao để kiểm soát, hoặc nên chọn chiến lược kiểm soát nào phù
hợp nhất nên người ta thường sử dụng kỹ thuật hỗ trợ ra quyết định thông
dụng trong quản lý là Cây quyết định để tính toán giá trị đạt được hoặc thiệt
hại xảy ra khi thực hiện một hành động nào đó.

Cây quyết định là một dạng biểu đồ có dạng cây nhiều nút, mỗi nút có nhiều
nhánh rẽ, mỗi nhánh sẽ trả lời câu hỏi "làm" hay "không làm", hoặc là một
khả năng để một tình huống xuất hiện với một xác suất nào đó. Các giá trị
cuối cùng của các nhánh sẽ giúp xác định xem nên chọn phương án nào cho
giá trị tốt nhất. Hình 5 là một Cây quyết định đơn giản để tính toán giá trị đạt
được theo các phương án khác nhau, giúp chọn lựa phương án tốt nhất, theo
đó phương án Y cuối cùng đã được chọn do giá trị trả về là lớn nhất.
Giám sát và điều chỉnh
Bao gồm hoạt động giám sát để bảo đảm các chiến lược đối phó rủi ro đươck
lên kế hoạch và thực thi chặc chẽ. Việc giám sát cũng nhằm mục đích điều
chỉnh các chiến lược hoặc kế hoạch đối phó nếu chúng tỏ ra không hiệu quả,
không khả thi, ngốn quá nhiều ngân sách, hoặc để đáp ứng với rủi ro mới
xuất hiện, hoặc sự biến tướng của rủi ro đã được nhận diện trước đó.
Kết quả giám sát có thể được báo cáo định kỳ đến tất cả những người có liên
quan, đến quản lý cấp cao, hoặc đến khách hàng nếu cần thiết.
Trong thực tế, do các yếu tố liên quan đến dự án thay đổi liên tục, chu trình
quản lý rủi ro không đi theo đường thẳng mà được lặp lại và điều chỉnh liên
tục giữa các chặng. Các rủi ro liên tục được điều chỉnh hoặc nhận diện mới,
do đó các chiến lược và kế hoạch đối phó cũng luôn được thay đổi để đảm
bảo chúng khả thi và có hiệu quả.
Kết luận
Rủi ro là một yếu tố tồn tại trong mọi dự án phần mềm. Một người quản lý
dự án giỏi phải là người không ngạc nhiên và có khả năng xử lý bất kỳ sự
kiện nào xảy ra có thể gây bất lợi cho dự án, điều đó đồng nghĩa với việc các
rủi ro ảnh hưởng đến dự án phải được "thấy trước", cùng với các kế hoạch để
giảm thiểu khả năng xuất hiện cũng như tác hại khi chúng xuất hiện. Quy
trình kiểm soát chặt chẽ, kinh nghiệm chuyên gia kết hợp với kỹ thuật nhận
diện và kiểm soát rủi ro là những yếu tố quan trọng nhất để kiểm soát tốt rủi
ro xảy ra trong dự án.
(Ngô Văn Toàn - TGVT)

Quản lý (QL) rủi ro là một trong các nội dung cơ bản của bất kỳ bài giảng
hoặc tài liệu nào về QL dự án phần mềm và kỹ nghệ phần mềm nói chung.

Tầm quan trọng của QL rủi ro được nói rất rõ: tỉ lệ thành công của các dự án
CNTT (theo nghĩa đạt được yêu cầu chất lượng, đúng hạn và không vượt
chi) rất không cao, chủ yếu do không có hoặc thực hiện không tốt việc
phòng ngừa và xử lý các nguy cơ dẫn đến thất bại hoặc hạn chế thành công
của một dự án.

Tuy đây là “kiến thức vỡ lòng” của QL dự án CNTT (hay chính vì nó là

“kiến thức vỡ lòng”?) nên trên thực tế việc QL rủi ro đã không được quan
tâm đúng mức. Thất bại của các dự án CNTT vẫn xảy ra thường xuyên, từ
những thất bại mang lại hậu quả có tính khủng hoảng như “112”, đến hàng
loạt đề tài và nhiệm vụ ứng dụng được nói khéo là “hiệu quả chưa cao”! Tỉ
lệ cao thường xuyên gặp của thất bại và kém hiệu quả này có lẽ đã làm nảy
sinh ý nghĩ coi đó là chuyện “tự nhiên” không tránh khỏi. Thậm chí làm xói
mòn uy tín của việc tin học hóa, cũng như niềm tin vào sự nghiệp này. Đây
là nỗi bức xúc lớn của những người liên quan đến công cuộc tin học hóa của
Việt Nam, đã được nhiều người, trong đó có các chuyên gia về CNTT đề cập
nhiều lần và trên nhiều diễn đàn.
Bài viết này xin đề cập một vài biện pháp nhằm QL được rủi ro khi triển
khai các ứng dụng CNTT tại nước ta.

Xử lý sớm các nguy cơ

Để QL được rủi ro, cần nhận biết các nguy cơ và ước lượng được thiệt hại
nếu nguy cơ xảy ra. Tiếp đến là áp dụng các biện pháp để giám sát, ngăn
ngừa, hoặc tránh né nguy cơ đó (gọi là “phòng ngừa rủi ro”). Nếu “phòng”
mà không “tránh” nổi, rủi ro vẫn xảy ra, thì phải xử lý hậu quả, theo cách
hạn chế thiệt hại ở mức thấp nhất và khôi phục lại các giá trị bị mất mát
nhanh chóng và toàn vẹn nhất có thể. Việc xử lý này thường gọi là các biện
pháp “khắc phục rủi ro”, như là một vế ứng đối với “phòng ngừa rủi ro”. Ai
cũng nói là “phòng hơn chống”, trên thực tế, “phòng” và “chống” phải bổ
sung và hỗ trợ lẫn nhau mới đảm bảo thành công cho một dự án QL rủi ro,
theo nghĩa sau đây: phòng tốt đi đến chống sớm, cái giá phải trả sẽ nhẹ
nhàng hơn.

Tình huống sau đây khá điển hình: một dự án ứng dụng CNTT khi gặp phải
khó khăn không kết thúc được rất thường bị “khê đọng” - “bỏ thì thương,
vương thì tội” trong một thời gian khá dài, dẫn đến lãng phí lớn về tài sản và
nhân lực. Nhiều khi hệ thống dù không khai thác được như ý, vẫn phải bảo
trì, không có phương án giải quyết dứt điểm dù thời gian đã qua cả năm bảy
năm, không thể rút được bài học và kinh nghiệm một cách đúng đắn cho
việc triển khai các dự án mới... Không hiếm gặp hiện tượng chuyển từ thái
cực này sang thái cực kia (từ tự phát triển sản phẩm sang giao phó hoàn toàn
cho người khác hoặc mua sản phẩm bán sẵn cả gói mà không chú ý đúng
mức đến nhu cầu và khả năng ứng dụng, từ đặt mục tiêu quá lớn cho tin học
hóa sang xóa bỏ hoặc gác lại việc tin học hóa, từ tập trung xây dựng một
phòng CNTT mạnh sang giải tán đội ngũ chuyên viên tin học...). Như thế là
rủi ro này kéo theo rủi ro khác, và cái sau còn có nguy cơ lớn hơn cái trước
rất nhiều.

Đối với các dự án như trên, nếu có chiến lược và biện pháp QL rủi ro tốt, có
thể khắc phục từ sớm các nguy cơ, hậu quả gây ra và phí tổn khắc phục cũng
nhỏ hơn nhiều. Trong một lần trả lời phỏng vấn trên VTV mới đây, “Thần
đèn xứ Bắc” Đỗ Quốc Khánh - chuyên gia về di dời công trình và chống lún
sụt - đã nói đại ý: nếu các công trình lớn thường xuyên mời chuyên gia giám
sát dự phòng lún sập (chi phí dưới một triệu đồng) thì sẽ tránh được sự tốn
kém gấp nhiều lần khi phải khắc phục chúng. Điều này cũng đúng cả cho
các dự án CNTT.

Chú ý đến khả năng tiếp nhận công nghệ

Các đề tài hoặc nhiệm vụ ứng dụng đến nay vẫn có xu hướng tập trung cho
các đầu tư về trang bị công nghệ, chạy theo các công nghệ tiên tiến, mà
không đánh giá một cách xác đáng về khả năng QL và tiếp nhận công nghệ
đó trên thực tế. Phần lớn các đề tài xây dựng hệ thống thông tin và cơ sở dữ
liệu chỉ đầu tư cho việc phát triển hệ thống, còn sau khi nghiệm thu thì việc
cập nhật thông tin và đưa hệ thống vào sử dụng là chuyện của người khác,
thậm chí của đơn vị khác. Việc cắt rời các giai đoạn của vòng đời một hệ
thống như vậy sẽ không cho phép đầu tư sớm các biện pháp phòng ngừa rủi
ro, đặc biệt là không quan tâm đến các khía cạnh triển khai chứa đựng rất
nhiều nguy cơ.

QL các thay đổi

Tình trạng sau đây rất phố biến: hệ thống vừa nghiệm thu, đã có nhu cầu
nâng cấp hoặc thay đổi. Giải pháp thường được áp dụng là: chia nhỏ, rút
ngắn thời gian dự án. Đây là một chiến thuật có thể hợp lý, tuy nhiên chỉ là
một khía cạnh để đối phó với tình hình. Việc thay đổi các yêu cầu đối với hệ
thống CNTT, môi trường ứng dụng của chúng và các công cụ thực hiện cần
được nhìn nhận và xử lý ở tầm chiến lược. Do đó, cần phân biệt những thành
phần bền vững, có giá trị khai thác lâu dài, với những công cụ và phương
tiện thường biến đổi nhanh. Thí dụ việc ồ ạt “web hóa”, “portal hóa” các hệ
thống thông tin hiện nay nên được hiểu chỉ là phần nổi, việc xây dựng cơ sở
dữ liệu, cơ sở nội dung mới quyết định hiệu quả các hệ thống đó. Tóm lại,
QL thay đổi là vấn đề chiến lược, chứ không phải chiến thuật. Nó cần dựa
trên quy hoạch ứng dụng tổng thể, dài hơi. Không thể bỏ qua hoặc xử lý thay
đổi kiểu “du kích” và có đến đâu làm đến đấy.

Hiệu quả của các quy định thực tế hàng ngày

Các biện pháp thực tế có thể giảm thiểu đáng kể các nguy cơ cho các hệ
thống thông tin, cũng như khắc phục sớm chúng, có liên quan rất nhiều đến
vấn đề tổ chức và thay đổi nề nếp làm việc.

Hiện nay, gần như tất cả nhân viên đều đã và phải làm việc với máy tính. Vì
thế, các kỹ năng làm việc cơ bản trong môi trường công nghệ này phải được
chuẩn hóa và trở thành chuẩn bắt buộc với mọi người làm việc. Giống như
đi xe gắn máy phải học luật giao thông, có bằng lái và luôn tuân thủ luật lệ.

Tiếp đến, các quy chế làm việc với máy tính và các tài nguyên trên máy phải
được xây dựng hợp lý và chặt chẽ. “Nội quy” làm việc thời số hóa này phải
được rèn luyện, kiểm tra và áp dụng thường xuyên đến thành tự giác cho
mọi người.

Sau đó, việc giao ban hệ thống và ghi chép biên bản cần được áp dụng đúng
quy định. Các biện pháp xử lý cũng phải được lưu giữ và giám sát. Các quy
định này trên thực tế nhiều nơi đã đặt ra, vấn đề là chúng phải được áp dụng
một cách thực chất, không hình thức, và phải là công cụ thực sự cho việc
giám sát và phát hiện các nguy cơ.

Theo PCWorld