プロジェクトに含まれるすべてのリスクを確実に取り除く方法はありますか? 作業しているプロジェクトのタイプ (つまり、Web サイト、クライアント/サーバーなど) によって異なりますか?
8 に答える
間違いなく絶対確実な方法はありません。本全体がこのトピックについて書かれています。そして本といえば、私はこれをお勧めします:
Steve McConnell によるソフトウェア プロジェクト サバイバル ガイド (私は知っていますが、くだらないイメージです)
「[リスク] は、[あなたが] 取り組んでいるプロジェクトの種類によって異なりますか?」
そのとおり。ソフトウェア プロジェクトには普遍的なリスクがいくつかありますが (経営陣のコミットメントの欠如、コミュニケーション不足など)、リスクの「プロファイル」は状況によって異なります。たとえば、ビデオゲーム プロジェクトのリスクは、企業のサプライ チェーン管理プロジェクトのリスクとは大きく異なります。
企業開発のリスクは、経営陣のサポートと洗練度、チーム構造、プロジェクトの規模、クライアント向けか社内向けか、プラットフォームの選択、統合のレベルなどによって異なります。
リスクが異なるという事実こそが、「ドメインでの経験不足」が普遍的なリスクである理由の 1 つです。
さまざまなコンテキストのリスク プロファイルは、学術論文の一般的な主題です (調査を行い、いくつかの数値を計算し、出版クレジットを取得します...)。これらは通常、読むのに夢中になるものではありませんが、プロジェクト計画を作成する際に検討する価値は十分にあります。
リスク管理に関する優れた短い本は、DeMarco と Lister による" Waltzing with Bears " です。
確実な方法はありません。最も危険なリスクは、予測できないリスクです。
残念なことに、これは、開発者が楽観主義者になりがちであるという事実によって悪化します。プログラマーに「最も可能性の高い見積もり」を求めると、「最良の見積もり」を求めた場合と同じ答えが得られる傾向があります。私の経験では、あなたができる最善の方法は、良い人を獲得し、楽観的にならないように頼んだ後でも、予期しない回り道をいくつか含めるように言った後でも、常に彼らの見積もりが低いと想定することです.
そして何よりも、見積もりが高すぎて、それを下げる必要があることを決してプログラマーに伝えないでください。帽子から見積もりを引き出したい場合はそうしてください。ただし、帽子から引き出したという事実について正直に言ってください。値を下げるように圧力をかけたときに、「これはプログラマーの見積もりだ」というふりをするのは危険で不誠実です。
ソフトウェア開発プロセスの危険性に関するその他の洞察については、Fred Brooks によるThe Mythical Man-Monthを強くお勧めします。
リスク管理は大きなトピックであり、おそらくスタックオーバーフローに関する回答では正当化できないトピックです。あなたの最善の策は、ソフトウェア プロジェクト管理に関する優れた本を手に入れて (ソフトウェア プロジェクト サバイバル ガイドの推奨事項は良い本です)、そこから先に進むことです。
開発の終盤を忘れないでください。
本番環境へのリリース
ソフトウェア開発に関するあらゆるリスクは、その目的に照らして評価する必要があると主張することもできます (ソフトウェアの本番環境へのリリースを成功させる、つまり「クライアントにサービスを提供する」)。
そのソフトウェアの監視と保守はそれ自体が危険な操作であるため、それだけでは十分ではありませんが、これは良いガイドラインです。
たとえば、NASA (「リリース」が最も重要です!) には、ソフトウェア品質モデルの定義があります。IBM には、このトピックに関する優れた一連の記事があります。
他のすべての回答と本の推奨事項は正しいです。
そのプロジェクトの「リスク」の独自の定義をより適切に確立するために、プロジェクトとは何か(「リリース」)の答えの中心に置きたかっただけです。
経験。ソフトウェアの開発とリリースを実践することで、構造化された分析では不可能な方法でリスクを予測して軽減することができます。
私はこの記事がとても気に入りました:ソフトウェア設計におけるリスク分析(PDF) を参照してください。リスク分析についての概要を説明していますが、絶対確実な方法はないと思います。実際には環境によって異なります。 .
主なリスクには次のようなものがあります: プログラマーは何を構築する必要があるか、どのように構築する必要があるかを知っていますか? アジャイルやエクストリームなどの一部の開発方法論は、これらのリスクに正面から取り組みます。実際に何かをできるだけ早く構築し、その後、優先度の高いビジネス目標を一度に 1 つずつ追求して、機能するシステムを進化させます。