新しいテクノロジーの学習曲線を含める必要がある場合、プロジェクトをどのように見積もることができますか？
時には、技術、コンセプト、クライアントについて事前に何も知られていない研究開発プロジェクトが存在します。ただし、マネージャーはまだ時間の見積もりが必要です。有用な見積もりを作成するにはどうすればよいですか？
正直なところ、ナシム・ニコラス・タレブが彼の本 『ブラック・スワン』に書いているように、「私たちはただ予測することはできません」。主に未知の未知数によるものです。概算ではなく、予測できないという事実そのものを伝えるのが最も一般的です。
タレブが書いているように：正確に間違っているよりも、広く正しいほうが良いです。したがって、見積もりが難しいという事実を伝え、「新しい技術で曲線を学習する」などを引数の1つとして使用してください。これは、見積もりの範囲が大きくなることを意味します。「このプロジェクトの費用は10万から50万の間です。」
そんなことを言うと、何かを見積もるように頼むと、それほど単純ではないことがわかります。
最初に必要なのは、スコープについてのアイデアです。より具体的であるほど良いですが、あらゆる形式の要件を使用して初期推定値を作成できます。顧客の要件、ビジョンと範囲、およびコンセプトドキュメントを早い段階で使用できます。要件と動作環境がより明確になり始めると、見積もりは改善されます。クライアント（特にクライアントと開発組織間のインターフェース）、作業を実行するチーム、使用するテクノロジー、システムアーキテクチャ、および詳細な設計についての理解が深まると、より正確な見積もりが得られます。これは不確実性のコーンに表示されます。
SLIMやCOCOMOなどのパラメトリックモデリングツールを使用している場合（Basicではコストドライバーが考慮されないため、中級または上級のみ）、テクノロジーの不慣れに対する調整要素が必要です。例として、COCOMOには 多数のコストドライバー があり、ターゲットプラットフォームやシステムの開発に使用されている言語やツールに精通しているものを特に含みます。 SLIMは、開発チームの全体的な経験も考慮に入れます。これには、使用されているツールとテクノロジーの考慮事項が含まれます。
この手法を使用すると、モデリングツールの出力は、多くの組織で長年にわたって以前のソフトウェアプロジェクトを推定するために正常に使用されているため、通常は検証されます。ただし、出力はツールへの入力と同じくらい良好です。
推定にパラメトリックモデルを使用していない場合は、推定を作成するときにこれらの要素を単純に考慮する必要があります。これは判断を促すものになりますが、ドキュメントの読み取り、新しい開発環境のセットアップ、ターゲットプラットフォームまたはターゲット言語を使用したサンプルアプリケーションの開発などのアクティビティを検討できます。
このような場合は、見積もりをタスクごとに分類し、専門家の判断でバックアップする必要があります。うまくいけば、あなたの推定の基礎となる履歴データと他の具体的な証拠があります。そうでなければ、それはより困難な戦いです。
主要なトレーニングと研究の時間を開発時間から分離します。プロジェクトをハッピーエンドのある複数のサブプロジェクトに分割します。トレーニング後に概念実証を作成してください。
テクノロジーに不慣れな場合、実際の開発時間に近づくことは決してありません。プロジェクトの最初にこれをリスクとして上げ、見積もりに寛大にしてください。これは、あなたやあなたのチームが慣れていないコアテクノロジーに適用されます。
場合によっては、FPA（ Function Point Analysis ）を使用することがほとんどでしたが、私たちはこの「エンタープライズWeb開発」に携わっていました。つまり、Forbes 500のWeb企業です。
タスクは常に2つの部分に分割できます。1つはFPAに非常によく適合します。入力インターフェース、出力インターフェース、内部論理ファイル（別名、データベーステーブル/エクスポートするタイプ）があり、これらの複雑で未知のシステムがあります。 。
簡単なバージョンでは、複雑なタスクはすでに記述されたコンポーネントであり、それとやり取りするのは困難で未知です。
ハードバージョンは、それを記述する必要がある場合であり、パイロットベースの推定、COCOMOなどです。
ただし、2つの重要な点があります。
あらゆる種類の推定システムには、組織の調整時間が必要です。あなたは一人で開発することは決してなく、少なくともあなたのコードを待っている顧客がいます（またはあなたは自分自身のためにコードを書いて、これについてそれほど必死ではないでしょう）。問題は「どれだけ早く開発できるか」ではなく、「みんなでどれだけ速く開発できるか」です。
かつて私はそのブラックスワンの小説を読んで、それについて熱狂的であったマネージャーがいました。彼は見積もることが不可能であると私たちに言っていました、そして私はいつもの正確な+ -10％見積もりを執拗に行っていました...