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ận1. 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.pdf2. L8_Risk_Management1.pdf3. L8_Risk_Management_easy.pdf4. L8_Risk1.pdf5. 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 IDMô 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. VuCarnegie Mellon UniversityMộ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/2008Bài viết: 6Đến từ: HNQuả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.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à ả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 roNhậ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 roXá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 DelphiTươ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ĩaNhó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 giaThườ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ỏiPhiế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 roTrong 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 roCó 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 roCó 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 roCó 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 roRủi ro sau đó được tính giá trị để ước lượng bằng công thức:Risk Exposure = Risk Impact * Risk Probability * Time FrameTiế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 roKiể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 giaoGiả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 địnhTrong 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ỉnhBao 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ậnRủ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