新しいテクノロジーの学習曲線を含める必要がある場合、どのようにプロジェクトを見積もることができますか？

技術、概念、およびクライアントについて事前に何も知られていない研究開発プロジェクトがある場合があります。ただし、マネージャーにはまだ時間の見積もりが必要です。有用な見積もりを作成するにはどうすればよいですか？

正直なところ、Nassim Nicholas Talebが彼の著書The Black Swanで次のように書いています。主に不明-不明のためです。一般に、推定値を伝えるのではなく、このまさに事実、つまり予測できないという事実を伝えることが最善です。

Talebが書いているように、正確に間違っているよりも、広く正しい方が良いです。そのため、推定に苦労しているという事実を伝え、「新技術の学習曲線」などを議論の1つとして使用してください。これは、見積もりの​​範囲が大きくなることを意味します。「このプロジェクトの費用は10万から50万です。」

そのようなことを言うことによって、何かを推定するように頼む人は、物事がそれほど単純ではないことを理解します。

絶対に最初に必要なことは、スコープの概念です。具体的であればあるほど良いのですが、あらゆる形式の要件を使用して初期見積もりを作成できます。顧客の要件、ビジョンと範囲、概念のドキュメントを早い段階で使用できます。要件と動作環境がより明確になり始めると、推定値は改善されます。クライアント（特にクライアントと開発中の組織との間のインターフェース）、作業を実行するチーム、使用するテクノロジー、システムアーキテクチャ、および詳細な設計をより深く理解することは、すべてより正確な見積もりに役立ちます。これは、不確実性のコーンに現れています。

SLIMやCOCOMOなどのパラメトリックモデリングツールを使用している場合（Basicはコストドライバーを考慮していないため、IntermediateまたはAdvancedのみ）、技術の不慣れさに対する調整要素が必要です。例として、COCOMOには多数のコストドライバーがあります。これには、システムの開発に使用されている言語とツールだけでなく、ターゲットプラットフォームに精通しているものも含まれます。SLIMは、開発チームの全体的な経験も考慮します。これには、使用されているツールとテクノロジーの考慮事項が含まれている必要があります。

この手法を使用すると、多くの組織で長年にわたって以前のソフトウェアプロジェクトを推定するために使用されているため、モデリングツールの出力は通常検証されます。ただし、出力はツールへの入力と同じくらい良いだけです。

推定にパラメトリックモデルを使用していない場合、推定値を作成するときにこれらの要因を単純に考慮する必要があります。これは判断の呼び出しになりますが、ドキュメントの読み取り、新しい開発環境のセットアップ、ターゲットプラットフォームまたはターゲット言語を使用したサンプルアプリケーションの開発などのアクティビティを検討できます。

これらの例では、タスクごとに推定値を分類し、専門家の判断を使用してそれをバックアップできるようにする必要があります。履歴データやその他の具体的な証拠があり、推定の基礎になることを願っています。それ以外の場合は、より困難な戦いになります。

主要なトレーニング時間と研究時間を開発時間から分離します。プロジェクトを、ハッピーエンドのある複数のサブプロジェクトに分割します。トレーニング後に概念実証を作成してください。

テクノロジーに慣れていない場合、実際の開発時間に近づくことはありません。これをプロジェクトの開始時にリスクとして上げ、見積もりをgeneしみなく行います。これは、あなたとあなたのチームが精通していないコア技術に適用されます。

依存しますが、私はほとんどの場合FPA（Function Point Analysis）を使用していましたが、私たちはこの「エンタープライズWeb開発」に没頭していました。つまり、Forbes 500 Web企業です。

そこでは、タスクを常に2つの部分に分割できます。1つはFPAに非常によく適合します。入力インターフェイス、出力インターフェイス、内部論理ファイル（別名データベーステーブル/エクスポートするタイプ）があり、これらの複雑で未知のシステムがあります。

簡単なバージョンでは、複雑なタスクはすでに作成されたコンポーネントであり、それとのインターフェースを取るのは難しく、不明です。

ハードバージョンは、作成する必要がある場合で、パイロットベースの見積もり、COCOMOなどです。

ただし、次の2つのことが重要です。

1. あらゆる種類の推定システムには、組織のキャリブレーション時間が必要です。少なくともあなたのコードを待っている顧客がいるだけで、単独で開発することはありません（または、あなた自身のためにコードを書くことで、これにそれほど必死にならないでしょう）。問題は、「どれだけ速く開発できるか？」ではなく、「どれだけ早く開発できますか？」です。

2. かつて私はそのブラックスワンの小説を読んで、それについてマニアックなマネージャーを持っていました。彼は推定することは不可能であると私たちに言っていました、そして私は執-10に+ -10％までの私の通常の正確な推定をしていました...

私はその記述にある程度定期的に適合するプロジェクトを行っていますが、まだこれを理解していません！ありがたいことに、私が働いている場所では、無駄な時間制限がなく、必要なことを行う自由が与えられています。プロジェクトは常に成功するとは限りません。それは、非常に多くの未知の部分を備えた作業の一部にすぎません。しかし、会社は毎回知識を獲得します。

申し訳ありませんが、まったく役に立ちません。

おなじみの技術を使用して同様のプロジェクトを実行するのにかかる時間を見積もります。4を掛けます。学習時間を追加します。

見積もりが短すぎる場合は、素朴でand慢に見えます。見積もりが大きすぎる場合は、無知で無能に見えます。賢明に選択してください。