Quản lý rủi ro là một hệ thống để xác định, giải quyết và loại bỏ các vấn đề có thể gây hại cho chi phí, tiến độ hoặc thành công kỹ thuật của một dự án hoặc tinh thần của nhóm dự án.
“Các vấn đề của ngày mai là những rủi ro của hôm nay.” Do đó, “rủi ro” được định nghĩa rõ ràng là một vấn đề có thể gây ra một số thiệt hại hoặc đe dọa tiến độ dự án, nhưng chưa xảy ra.
Nếu bạn không chủ động quản lý rủi ro, bạn sẽ phải đối mặt với rủi ro.
Phát triển phần mềmlà một hoạt động có rủi ro cao, và có thể có rủi ro ở bất kỳ giai đoạn nào của quá trình phát triển dự án. Áp dụng phương pháp quản lý rủi ro chủ động có thể làm cho quá trình dự án ổn định hơn, có khả năng theo dõi và kiểm soát dự án cao, và có thể tránh và chuyển giao rủi ro, hoặc giảm thiểu các tác động tiêu cực của rủi ro.
Quản lý rủi ro là quá trình xác định, phân tích, phản ứng và giám sát các rủi ro của dự án. Đây là một hoạt động quản lý rất quan trọng trong quản lý dự án. Việc thực hiện hiệu quả quản lý rủi ro phần mềm là đảm bảo cho việc hoàn thành suôn sẻ phát triển dự án phần mềm.
Việc đạt được quản lý rủi ro phải bao gồm ba yếu tố:
- Một kế hoạch quản lý rủi ro phải được xây dựng trong kế hoạch phát triển dự án;
- Ngân sách dự án phải bao gồm các khoản tiền cần thiết để giải quyết rủi ro;
- Khi đánh giá rủi ro, tác động của rủi ro cũng phải được đưa vào kế hoạch dự án.
Hãy thảo luận về cách chúng ta có thể thực hiện các hành động phòng ngừa để giảm thiểu các rủi ro thường xảy ra trong quá trình phát triển phần mềm.
- Yêu cầu không rõ ràng— Yêu cầu không rõ ràng là những vấn đề thường gặp trong quá trình phát triển phần mềm. Những vấn đề này thường thể hiện ở nhiều khía cạnh như phạm vi yêu cầu không xác định, yêu cầu chưa được tinh chỉnh, mô tả yêu cầu không rõ ràng, yêu cầu bị thiếu và yêu cầu mâu thuẫn. Trong vòng đời của quá trình phát triển phần mềm, sự lãng phí do yêu cầu không rõ ràng là lớn nhất và phải được giải quyết càng sớm càng tốt. Rất khó để xác định nhu cầu của người dùng.
Các hành động phòng ngừa
- Cho phép người dùng tham gia vào phát triển thông qua các cuộc thảo luận và họp ngắn và thường xuyên hơn
- Phát triển và giao tiếp với các bên liên quan bằng cách sử dụng mẫu giao diện người dùng / nguyên mẫu
2. Đối với các dự án có sự phân phối rộng rãi của người dùng và số lượng người dùng lớn, thường rất khó để thu thập yêu cầu của người dùng một cách toàn diện, và các cuộc họp nghiên cứu yêu cầu thường được áp dụng để xác nhận yêu cầu.
Các hành động phòng ngừa
Vài tuần trước cuộc họp, chúng tôi đã khảo sát nhu cầu của người dùng ở các khu vực và phòng ban khác nhau, và sau đó tập hợp đại diện người dùng từ tất cả các khu vực hoặc phòng ban để tổ chức một hội thảo yêu cầu nhằm thu thập yêu cầu thông qua cuộc họp. Phương pháp này phù hợp với những người dùng có kinh nghiệm nhất định về CNTT.
2. Cạm bẫy 80/20 — Khi một quản lý dự án hoặc một nhà phát triển nói rằng 80% nhiệm vụ đã hoàn thành, bạn phải cẩn thận. Bởi vì 20% còn lại có thể mất 80% thời gian, hoặc có thể không bao giờ hoàn thành.
Các dự án phát triển phần mềm thường thiếu tính minh bạch về tiến độ dự án và chất lượng phần mềm. Dự án càng ít minh bạch, càng khó kiểm soát dự án, và càng có khả năng thất bại. Chúng ta có thể nâng cao tính minh bạch của dự án thông qua phát triển lặp, đánh giá kỹ thuật và tích hợp liên tục.
Các hành động phòng ngừa:
- Phát triển lặp lại Sử dụng mô hình phát triển lặp lại, quy trình giao hàng sản phẩm được chia thành nhiều giai đoạn và được giao theo từng phần theo chức năng.
- Đánh giá kỹ thuật là một phần quan trọng trong việc đảm bảo chất lượng phần mềm. Đánh giá kỹ thuật bao gồm kiểm tra mã, đánh giá cuộc họp và đánh giá đồng nghiệp. Đánh giá mã có thể là một đánh giá chéo giữa các nhà phát triển hoặc một đánh giá của các nhà phát triển thông thường bởi các nhà phát triển cao cấp; Đánh giá cuộc họp thường được thực hiện ít nhất một lần mỗi hai tuần, và thời gian của mỗi đánh giá không nên quá dài, điều này là một đảm bảo quan trọng cho sự thành công của dự án.
- Tích hợp liên tục có thể phân tán quy trình tích hợp và đưa vào vận hành quy mô lớn cuối cùng thành tiến độ phát triển hàng tuần và hàng ngày của dự án. Để mọi người trong dự án có thể nắm bắt tiến độ tổng thể hiện tại bất cứ lúc nào, và nhanh chóng tìm ra và giải quyết các vấn đề trong quá trình tích hợp.
3. Đổi mới công nghệlà một hoạt động công nghệ và kinh tế khám phá và sáng tạo. Trong quá trình phát triển, việc giới thiệu công nghệ mới sẽ không thể tránh khỏi việc gặp phải nhiều rủi ro khác nhau. Các biện pháp như phát triển phần mềm hình chữ T, và tạo mẫu với công nghệ mới với các câu chuyện người dùng đột biến.
4. Vấn đề hiệu suất—Do thiếu hiểu biết về thiết kế phần mềm, các vấn đề hiệu suất thường được phát hiện sau khi triển khai hệ thống hoặc sử dụng một hệ thống mới trong một khoảng thời gian. Các vấn đề hiệu suất thường yêu cầu nhiều công việc tối ưu hóa, hoặc thậm chí thiết kế lại một phần hoặc toàn bộ. Cả người dùng và nhà phát triển đều không muốn gặp phải các vấn đề hiệu suất. Nhóm cần nhận thức được vấn đề này, thực hiện kế hoạch và kiểm tra hiệu suất trong suốt quá trình phát triển, và bao gồm các yêu cầu hiệu suất trong các yêu cầu không chức năng.
5. Vấn đề khả năng sử dụngKhả năng sử dụng của phần mềm bao gồm nhiều yếu tố như phần mềm có hiệu quả hay không, dễ học, dễ nhớ, dễ chịu và không dễ mắc lỗi. Thường do khả năng sử dụng kém của phần mềm, người dùng không hài lòng và thậm chí bị loại bỏ bởi thị trường. Trong phát triển dự án, cần chú ý đến các vấn đề khả năng sử dụng để tránh rủi ro về khả năng sử dụng phần mềm.
Cấu trúc phân rã rủi ro
Chúng ta có thể sử dụng cấu trúc phân rã rủi ro để phân loại các rủi ro tiềm ẩn cho các khía cạnh khác nhau:
Cấu trúc phân rã rủi ro là sự phân rã theo cấp bậc của các rủi ro, bắt đầu từ phần tử nút gốc đại diện cho dự án, và đi xuống các danh mục rủi ro khác nhau, và sau đó là các rủi ro ở cấp độ tinh vi hơn.
Ngoài việc trình bày các rủi ro dự án trong một cấu trúc phân rã rủi ro, có thể kết hợp việc sử dụng Chú giải Màu sắc trong việc đại diện cho tác động của rủi ro. Hãy xem ví dụ về cấu trúc phân rã rủi ro dưới đây, một chú giải về Tác động với năm mục đã được thiết lập, đại diện cho năm cấp độ tác động mà các rủi ro có thể có trên dự án với năm mã màu khác nhau.
Dưới đây là một ví dụ về cấu trúc phân rã rủi ro:
(Chỉnh sửa cấu trúc phân rã rủi ro này trực tuyến)
Có nhiều công cụ quản lý rủi ro mà bạn có thể sử dụng trong việc cấu trúc các rủi ro. Ngoài cấu trúc phân rã rủi ro, bạn có thể xem xét việc sử dụngSơ đồ nguyên nhân và kết quảcũng như (còn được gọi là Sơ đồ xương cá).
Kết luận
Rủi ro được xác định và quản lý càng sớm, khả năng tránh rủi ro càng cao, hoặc giảm thiểu tác động của rủi ro khi nó xảy ra. Đặc biệt trong các dự án phức tạp với số lượng lớn người tham gia dự án, sự tham gia rộng rãi và nội dung kỹ thuật cao cần được củng cố.
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.