要件の増加に伴うプロジェクト見積もり

与えられた要件セットを使用してプロジェクトの見積もりを作成することは1つのことです。

しかし、ユーザーがその場で突然変更を開始し、すでに定義されているセットに新しい要件を追加し始めるとどうなりますか？そして、プロジェクトが当初計画された時間枠で完了していない理由に腹を立てるほどです。

これらの状況にどう対処すればよいですか？いくつかの方法論とリーディングを提案することは役に立ちます。

要件の変更はスコープの変更でもあることを顧客に明確にし、要件に変更があるたびに見積もりを更新する必要があります。

プロジェクトの見積もりは、理由により見積もりと呼ばれます。彼らは約束ではありません。顧客が約束をしたい場合、それは別の取引です。ここで、凍結された要件を使用して、成功の可能性が高い、はるかに大きな見積もりを提供する必要があります。

ほとんどのプロジェクトの見積もりは、理想的な見積もりよりも20％〜100％（またはそれ以上）高い時間プレミアムの一定レベルのパディングを提供します。見積もりにこのパディングが含まれていることを確認してください。

顧客の可視性を向上させるアジャイル手法が存在するため、顧客は、関与する取り組み、および彼の変更がタイムラインにどのように影響しているかをよりよく理解できます。

要件を更新するときに見積もりを更新する必要があり、クライアントが「完了」として受け入れるものの仕様が定義されています。「私の以前の見積もりは、機能セットX、Yに対するものでした。Zを追加したい場合は、納期を...延長する予定です。」など

あなたはすべき正式通信への影響のスケジュールとコストを必要条件を変更したり、新しいものを追加するとき、顧客と管理に。新しい承認や変更を求める前に、彼らが深く考えるように、正式な承認メカニズムを課すために最善を尽くします。それ以外の場合は、「XYZを追加してほしい」と後で「XYZはABCを意味していると言いましたか？」

あなたのプロジェクトを三角形と考えてください（私のPM仲間が実際に追加の効果のために使用した物理的な三角形を作りました）。エッジは、時間、コスト、スコープと呼ばれます。あなたはクライアントに2つのサイドを制御できると伝えますが、あなた（配信の責任者）は少なくとも1つのサイドを制御する必要があります。

だから、あなたはそれを速くて安価に行うことができます-しかし、あなたはスコープをカットする力を持っている必要があります。

または、より多くの機能を取得できますが、これにはより多くの時間またはより多くのお金がかかります。

詳細については、http：//en.wikipedia.org/wiki/Project_triangleをご覧ください

状況に応じて非常に役立つアジャイル方法論であるスクラムを実装してみることができます。

ウィキペディアから：

スクラムは、一連のプラクティスと事前定義された役割を含むプロセススケルトンです。スクラムの主な役割は次のとおりです。

1. プロセスを維持する「ScrumMaster」（通常はプロジェクトマネージャーの代わり）
2. 利害関係者とビジネスを代表する「製品所有者」
3. 「チーム」は、実際の分析、設計、実装、テストなどを行う約7人の部署からなるグループです。

各「スプリント」の間、通常は2〜4週間（期間はチームによって決定されます）に、チームは出荷される可能性のある製品の増分（たとえば、稼働中およびテスト済みのソフトウェア）を作成します。スプリントに組み込まれる一連の機能は、製品の「バックログ」に由来します。これは、優先順位付けされた、実行される作業の高レベルの要件のセットです。スプリントに入れるバックログ項目は、スプリント計画ミーティング中に決定されます。

それは方法論についてではなく、顧客とのコミュニケーションについてです。

顧客が未完成のプロジェクトに常に新しい機能を追加したいという多くの状況があり、それが全体的なコストと遅延を増加させる理由に驚きました。それらの顧客のコンテキストと性格は異なり、異なるアプローチが必要でしたが、いくつかのガイドラインとアドバイスを分離しようとすることがあります。

• 要件の変更がコストと遅延の両方に影響を与える理由を理解するために必要な一般情報に顧客がアクセスできることを確認してください。言い換えれば、それらのことに関するいくつかの記事を公開し、非技術者がまったく知らないかもしれないことを説明します。

たとえば、ほとんどの人にとって、ごくわずかと考える変更がプロジェクトに大きな影響を与え、非常に費用がかかる可能性があることはまったく奇妙です（私の質問の例を参照）。彼らがいくつかの変更を行うように依頼し、何も説明せずに、彼らが無料または数十ドルでそれを期待したときに彼らが数千ドルを支払わなければならないことを彼らに話すたびに、おそらくあなたはただだと思うでしょう彼らのお金を盗む。これは特に非倫理的なプログラマーやソフトウェア会社が保守不可能な製品を開発しているため（通常の開発者が後で変更するように依頼することはできません）、すべての変更に対して多額の費用を支払うように求めます。

• お客様が求めている特定の変更がコストに影響を与える理由を理解していることを確認してください。そのために、記事へのリンク（前のポイントを参照）を彼女に与えるか、または技術的ではない方法で、要求された変更を行うために何が必要かを要約することができます。

このような説明は、顧客が製品と変更についてよりよく理解できるようになるため、良い考えでもあります。いくつかのケースでは、私の顧客の一部は、彼らが望んだ変更はあまりスマートではなく、他の方法で行うと言って終了しました。提案することもできます。これは一部のお客様から非常に高く評価されており（警告：嫌いな人もいます）、何を話しているかわかっていることを示しています（可能なアプローチについてあまり考えずに、要件をコードに変換するコードモンキーと比べて） 。

• 顧客が本当に確信がない限り、顧客が望むことを何もできないことを確認します。一部の人々にとって、コードを書き始める前に要件を明確にロックすることが唯一の方法です。そうでなければ、それは災害であり、プロジェクトは決して終わりません。他の人にとっては、終了していないプロジェクトを見ないのは良い考えです（一般的に、私の顧客は終了していない製品に非常に早い段階でライブアクセスできるため、コメント/調整を早くすることができます）。

たとえば、「最終的な」要件を送信した後、マイナーな変更（「ホームページの中央ゾーンの境界幅を変更できますか？」 3〜6ピクセル？ "）プロジェクト全体に影響する変更（開発の2か月後、リリースの1週間前）："最後に、ASP.NETは悪い考えだと思います。PHPに切り替えてもらえますか？ " ）。

そのため、その顧客にとって、コードを記述する前にすべての要件をロックする必要がありました。契約書に書いてありました。最終リリース前に変更は受け入れられませんでした。

不思議なことに、私たちは非常に組織化することができたので、それはそれほど悪くはありませんでした：古い要件に従ってプロジェクトがリリースされ、数日後、まったく異なるセットで次のバージョンをゼロから始めました要件の。