テクノロジーの ROI をマネージャーに証明するにはどうすればよいでしょうか?
これを行う方法に関するドキュメントに私が見つけた最も近いものは次のとおりです。
http://www.agilejournal.com/pdf/Finding-ROI-in-Build-Automation.pdf
このドキュメントには数式がありますが、それが単に多くのマーケティングを行っているだけなのか、それとも ROI の計算方法に関する正確な数式なのかはわかりません。
上記の論文では、ビルド ツールの ROI を実際に計算しようとしているのではなく、ANT のような単純なビルド ツールの ROI を計算しようとしていただけです。
彼らは質問の要点、つまり無形の利点には触れていませんが、少なくとも例を見て回ろうとしています。計算式は、ROI を適切なパーセンテージとして取得するためのものです。「ビルド ツールの使用」が株式である場合、投資に対してどのくらいのリターンが得られるでしょうか?
これは、質問自体に欠陥があることをすでに示しています。自動ビルドは、主に品質を向上させるための手段です。通常、生産性の向上は二次的な関心事です。
ただし、これは、お金に座っている人たちと話すときには役に立ちません。
ビルド ツールの効果を分析するために使用するメトリクス:
多くの場合、自動化されたビルド ツールはボトルネックを取り除くだけで採算が取れます。John the Builder だけでなく、すべての開発者がソフトウェアを公開できます。
バグの総コストには正規分布がなく、非常に「パレート」であるため、最後のポイントは重要です (ただし、数値を与えるのが最も難しい)。競争に。
自動化されたビルドを維持するための中心的な議論は、バグの公開はほとんど回避可能であるということです。
見積もりを時間単位で入力する: 現在費やしている時間と、今後費やす予定の時間を見積もります。
見積もりを顧客の苦情に入れる: 現在のバグの数を見積もります。新しいシステムがキャッチしたであろうバグの数を見積もってください。ユーザーによって報告されたバグの割合を調べ、ユーザーに表示されるバグがどれだけ少ないかを文書化します。
時間に追加する: 発見されるバグを修正するのにかかる時間を計算し、それを 1 時間ごとの見積もりに追加します。
数値化できない「販売性」を追加します。
余分な時間で、追加機能を構築します。バグが少なければ、セールス担当者が足を撃つようなデモも少なくなります。これを行うと、ソフトウェアの余分なコピーをいくつ販売できますか?
最後のビットは成功しません。主に最初の 2 つの指標に注意を向けるためです。時間と顧客に見える欠陥。
開発者のツールやプラクティスの ROI を正確に測定する賢明な方法があるとは思えません。それが可能な場所として私が思いつく唯一のことは、生産性と平均品質を測定できる工場環境です。
他の人がしていることと同じことをすることをお勧めします。それは、あなたが望むものをサポートするいくつかの公式を選び、ROI が投資を正当化するのに十分なほど高くなるまで微調整することです。
私のアドバイスは、現在そこにあるものを信用せず、代替案を提供することです.
今ビルドと展開をどのように行うかという問題に重点を置いて、最初にその戦いに勝つことができます。マネージャーは、彼らを悲しませていないものを変更したくないので、何もしなければ問題になることを証明する必要があります.
考慮すべきこと: 悪いビルドによってどれだけの時間と信頼性が失われるか。現在何回ミスを犯しているか; 手動での繰り返しがどのくらい行われるかなど、これらの指標や例を挙げてみてください。
開発者の支持を得ることができれば、議論の強さに彼らの承認を追加することもできます。もう 1 つのポイントは、優れた開発者は優れたツールを使用することを好むため、進歩的な管理は意欲的な開発者に等しいということです。
開発者とマネージャーの心をつかむことができれば、数字が書かれた紙以上のことを意味するかもしれません。