Các yếu tố được xem xét để quản lý rủi ro phần mềm

Các yếu tố rủi ro mà chúng ta cần xem xét trong khi lập kế hoạch cho một dự án phần mềm là gì.

• Đội của bạn đã được đào tạo đầy đủ chưa?
• Đội của bạn có đủ lớn không?
• Bạn có dự phòng trong trường hợp ai đó rời khỏi dự án, và nó sẽ ảnh hưởng đến lịch trình như thế nào?
• Là đội của bạn quá lớn?
• Họ có tài nguyên họ cần không?
• Có thể một đối thủ cạnh tranh mang một sản phẩm ra thị trường trước khi dự án của bạn hoàn thành?
• Bạn có thể đối phó với các yêu cầu thay đổi?
• Bạn có thể đối phó với các dự án trở nên không liên quan?
• Bạn có mua từ quản lý cấp cao?
• Bạn có bất kỳ sự phụ thuộc vào nhà cung cấp hoặc nhà thầu?
• Bạn có đang làm bất cứ điều gì trong nhà mà nhóm của bạn không đủ năng lực không?
• Bạn có ngân sách đủ lớn để đáp ứng chi phí dự án ước tính?
• Bạn có thể đáp ứng chi phí dự án không lường trước?
• Và bất cứ điều gì cụ thể cho trường hợp của bạn :-)

Tôi sẽ thêm vào danh sách của @ Graham:

• Là một số yêu cầu ngoài tầm kiểm soát của bạn (ví dụ: luật về tính thuế bán hàng) và chúng có thể thay đổi không?
• Bạn có đang sử dụng một công cụ lần đầu tiên và bạn tự tin như thế nào công cụ sẽ làm việc cho bạn? (Nó có thể là thương hiệu mới, ví dụ Azure hoặc chỉ mới đối với nhóm của bạn)
• Bạn có dựa vào sự chấp nhận chung của người dùng đối với một sản phẩm khác không (ví dụ: viết ứng dụng iPhone có nghĩa là bạn mong muốn người dùng của mình có iPhone, viết ứng dụng BlackBerry có nghĩa là bạn mong muốn người dùng của mình có BlackBerry, v.v.)
• Bạn có thể khôi phục / tạo lại bất kỳ công việc bị mất hoặc thay đổi sai (không chỉ kiểm soát nguồn mà còn kiểm soát phiên bản cho các tài liệu, email từ khách hàng, v.v.)
• Bạn có công cụ và quy trình cho phép bạn hiểu tiến bộ, thiếu tiến bộ và hồi quy không? Quản lý có hiểu các mốc quan trọng không (tôi đã có các dự án hoàn thành 10%, ban quản lý đã thấy các nguyên mẫu UI và tin rằng công việc đã "gần hoàn thành" rồi gây áp lực để nhanh chóng nhanh chóng từ đó trở đi.)
• Bạn có thử nghiệm (tự động hay không) để chứng minh rằng một bộ thay đổi cụ thể không phá vỡ một số phần khác của ứng dụng? Nếu không có những thử nghiệm như vậy, bạn có thể thực hiện những thay đổi đáng kể như chuyển sang ngôn ngữ hoặc nền tảng khác không?

Tôi muốn thêm vào như sau:

• Bạn có biết nhu cầu của khách hàng của bạn. Nếu không, nhóm thu thập yêu cầu của bạn có xác định đầy đủ những gì khách hàng muốn trong quá khứ và đủ đáp ứng để đảm bảo rằng các thay đổi được lan truyền nhanh nhất có thể cho nhóm phát triển không? Có phải họ thêm mạ vàng theo yêu cầu?
• Có một sản phẩm hiện có mà bạn đang cạnh tranh và bạn đã xác định trước khi thiết kế cách bạn sẽ cạnh tranh với sản phẩm này chưa? Điều này rất quan trọng vì các sản phẩm hiện tại thường xuất hiện với các khía cạnh "Tôi cũng muốn tính năng đó" có thể khiến bạn đi chệch khỏi kế hoạch ban đầu. Nhóm / quản lý / khách hàng mục tiêu của bạn có thể được theo dõi bởi sự cố như vậy không và bạn có thiết lập kế hoạch dự phòng để xử lý vấn đề như vậy không?
• Là thiết kế đề xuất của sản phẩm của bạn có phù hợp với thị trường? Nửa chừng bạn không muốn khám phá ra rằng trong khi nó đáp ứng nhu cầu của khách hàng thì nó lại thiếu những khía cạnh quan trọng để cạnh tranh trong thế giới "mới".

Phát triển nhanh chóng của Steve McConnell chứa một chương về quản lý rủi ro, với một danh sách dài các rủi ro tiềm ẩn. Tôi đã sử dụng nó như một điểm khởi đầu hơn một lần.

Bạn có sự pha trộn đúng đắn của mọi người? Có phải tất cả các nhà phát triển ứng dụng nhà phát triển của bạn trong một dự án tập trung vào dữ liệu? Bạn có cần một nhà thiết kế cơ sở dữ liệu, một người QA hoặc một chuyên gia UI thay vì chỉ thuê những người có cùng kỹ năng không?

Bạn có đủ phần cứng để hỗ trợ dự án? Điều này đặc biệt đúng nếu bạn đang tạo một hệ thống âm lượng lớn hoặc nếu bạn quá rẻ để mua các máy chủ phát triển ngoài các máy chủ sản xuất.

Bạn đã thiết lập sao lưu cơ sở dữ liệu của bạn? Chỉ cần có mã để tạo lại cơ sở dữ liệu là không đủ, bạn cần phải giữ dữ liệu ngay cả trên dev.

Các nhà phát triển của bạn có đang làm việc với một tập dữ liệu nhỏ thay vì một kích thước mà sản xuất sẽ có không? Điều này gần như đảm bảo các vấn đề về hiệu suất sản xuất vì các truy vấn hoạt động tốt trên một tập dữ liệu nhỏ thường không có trên một tập lớn. Tôi đã thấy rất nhiều bản cập nhật sản xuất thất bại phải được khôi phục ngay lập tức do vấn đề đặc biệt này.

Bạn đang xác định phải làm gì trong các trường hợp cạnh và bạn đang thử nghiệm chúng? Chẳng hạn, tôi đã thấy các dự án mà không ai từng xác định điều gì xảy ra với những gì cần có phê duyệt và người phê duyệt nói không.

Bạn sẽ bị buộc phải đưa ra lựa chọn thiết kế xấu để đáp ứng thời hạn không hợp lý?

Trong kế hoạch của bạn cho dự án, bạn có nghĩ rằng mọi người nghỉ phép và những ngày đau ốm, nhận nhiệm vụ bồi thẩm đoàn, nghỉ phép mất vv? Bạn cần lập kế hoạch không chỉ cho những người rời khỏi dự án mà cả thời gian nghỉ hàng ngày mọi người có được.