ソフトウェアリスク管理で考慮すべき要素

ソフトウェアプロジェクトを計画する際に考慮する必要があるリスク要因は何ですか。

• あなたのチームは十分に訓練されていますか？
• あなたのチームは十分な大きさですか？
• 誰かがプロジェクトを辞めた場合の不測の事態はありますか？それはスケジュールにどのように影響しますか？
• チームが大きすぎませんか？
• 彼らは必要なリソースを持っていますか？
• プロジェクトが完了する前に、競合他社が製品を市場に出す可能性はありますか？
• 変更された要件に対応できますか？
• 関係のなくなったプロジェクトに対処できますか？
• 上級管理職から賛同を得ていますか？
• サプライヤーや請負業者に依存していますか？
• あなたのチームが十分な能力を持っていない社内で何かをしていますか？
• 見積もりプロジェクトコストに見合うだけの予算はありますか？
• 予期しないプロジェクトコストに対応できますか？
• そして、あなたの状況に固有の何か:-)

@Grahamのリストに追加します。

• いくつかの要件（たとえば、消費税の計算に関する法律）が制御不能であり、変更される可能性がありますか？
• 初めてツールを使用していますか。ツールがうまく機能することについてどの程度自信がありますか。（Azureなど、まったく新しいものか、チームにとっては新しいものです）
• 他の製品のユーザーによる一般的な承認に依存していますか（たとえば、iPhoneアプリを作成すると、ユーザーはiPhoneを持っていることが期待され、BlackBerryアプリを作成すると、ユーザーはBlackBerriesを持っていることが期待されます）。
• 失われた、または誤って変更された作業を復元/再作成できますか（ソース管理だけでなく、ドキュメントのバージョン管理、クライアントからの電子メールなど）
• 進捗状況、進捗状況の欠如、および回帰を理解できるツールとプロセスはありますか？経営陣はマイルストーンを理解していますか（10％完了した時点で、経営陣がUIプロトタイプを見たプロジェクトがあり、作業は「ほぼ完了」していて、それ以降急いで急いでいるようにプレッシャーがかかっていると信じていました。）
• 特定の変更セットがアプリケーションの他の部分に影響を与えていないことを実証するためのテスト（自動化されているかどうか）はありますか？そのようなテストがなければ、別の言語またはプラットフォームへの移植などの重要な変更を加えることができますか？

以下を追加します。

• あなたの顧客のニーズを知っていますか？そうでない場合、要件収集チームは、顧客が過去に何を望んでいるかを適切に判断し、変更が開発チームに可能な限り迅速に伝達されるように十分に応答していますか？彼らは要件に金メッキを追加していますか？
• 競合する既存の製品はありますか？また、この製品とどのように競合するかを設計する前に決定しましたか？既存の製品には「私もその機能が欲しい」という側面があり、当初の計画から逸脱する可能性があるため、これは重要です。あなたのチーム/経営陣/ターゲットの顧客は、そのような出来事によってサイドトラックされることができますか、そしてあなたはそのような問題を処理するために準備された緊急時対応計画を持っていますか？
• あなたの製品の提案されたデザインは市場に関連していますか？途中で、それが顧客のニーズを満たす一方で、「新しい」世界で競争するための重要な側面に欠けていることを発見したくありません。

Steve McConnellのRapid Developmentには、リスク管理に関する章があり、潜在的なリスクの有用な長いリストが含まれています。私はそれを出発点として複数回使用しました。

適切な組み合わせの人がいますか？すべての開発者アプリケーション開発者はデータ中心のプロジェクトに参加していますか？同じスキルの組み合わせを持つ人だけを雇うのではなく、データベース設計者、QA担当者、またはUIスペシャリストが必要ですか？

プロジェクトをサポートするのに十分なハードウェアがありますか？これは、大量のシステムを作成している場合、または本番サーバーに加えて開発サーバーを購入するのが安すぎる場合に特に当てはまります。

データベースのバックアップを設定しましたか？データベースを再作成するためのコードを用意するだけでは十分ではなく、開発者でもデータを保持する必要があります。

開発者は、プロダクションのサイズではなく、小さなデータセットを使用していますか？小規模なデータセットで適切に機能するクエリは、大規模なセットでは機能しないことが多いため、これにより本番パフォーマンスの問題がほぼ保証されます。この特定の問題のためにすぐにロールバックする必要があった、失敗したプロダクションアップデートの多くを見てきました。

エッジケースで何をすべきかを定義し、それらをテストしていますか？たとえば、承認が必要とされるものに何が起こるかを誰も定義しておらず、承認者が「いいえ」と言っているプロジェクトを見たことがあります。

無理な締め切りに間に合わせるために、悪い設計の選択を強いられますか？

プロジェクトの計画では、人々が休暇や病気の日をとったり、陪審員の義務を負ったり、死別休暇を取ったりすることを考えましたか？あなたはプロジェクトを去る人々のためだけでなく、人々が得る毎日の休暇のために計画を立てる必要があります。