要件の増加に伴うプロジェクトの見積もり
与えられた要件セットを使用してプロジェクトの見積もりを行うことは1つのことです。
しかし、ユーザーが突然それらをその場で変更し始め、すでに定義されたセットに新しい要件を追加し始めるとどうなりますか？そして、プロジェクトが当初の計画された時間枠で終了しない理由に気が狂うほどです。
これらの状況にどのように対処する必要がありますか？いくつかの方法論と読み方を提案することは役に立つかもしれません。
要件の変更はスコープの変更でもあることを顧客に明確にし、見積もりの更新を提供する必要があります要件に変更があるたびに
プロジェクトの見積もりは、理由から見積もりと呼ばれます。それらは約束ではありません。顧客が約束をしたいのであれば、それは別の取引です。 frozen要件を使用して、成功の可能性が高い、はるかに大きな見積もりを提供する必要があります。
ほとんどのプロジェクト見積もりでは、理想的な見積もりよりも20％から100％のタイムプレミアム（またはそれ以上）の一定レベルのパディングが提供されます。見積もりにこのパディングが含まれていることを確認してください。
顧客に優れた可視性を提供するアジャイル手法が存在するため、顧客は関連する作業と、顧客の変更がタイムラインにどのように影響しているかをよりよく理解できます。
要件を更新するときに見積もりを更新し、クライアントが「完了」として受け入れるものの仕様を定義する必要があります。 「以前の見積もりは機能セットX、Yでした。Zを追加したい場合は、納期が...だけ延長されると見積もっています。」など
要件を変更したり、新しい要件を追加したりする場合は、正式に伝達する顧客と管理者にスケジュールおよびコストの影響を与える必要があります。 正式な承認メカニズムを課すように最善を尽くして、新しいことや変更を求める前に深く考えてください。それ以外の場合は、「XYZを追加してほしい」と後で「XYZはABCを意味すると言いましたか」と聞き続けます。
あなたのプロジェクトを三角形と考えてください（私のPMの仲間は、実際に彼が追加の効果のために使用した物理的な三角形を作成しました）。エッジはtime、costおよびスコープ。あなたはクライアントに2つの側面を制御できることを伝えますが、あなた（配信の責任者）は少なくとも1つの側面を制御する必要があります。
だから、あなたはそれを速くそして安くすることができます-しかしそれからあなたはスコープを切る力を持たなければなりません。
または、より多くの機能を取得できますが、それにはより多くの時間またはより多くのお金がかかります。
Scrum を実装してみることができます。これは、状況に応じて非常に役立つアジャイル手法です。
ウィキペディアから：
スクラムは、一連のプラクティスと事前定義された役割を含むプロセススケルトンです。スクラムの主な役割は次のとおりです。
- プロセスを維持する「ScrumMaster」（通常はプロジェクトマネージャーの代わりに）
- 利害関係者とビジネスを代表する「プロダクトオーナー」
- 「チーム」は、実際の分析、設計、実装、テストなどを行う約7人の部門横断的なグループです。
各「スプリント」（通常は2〜4週間（長さはチームによって決定されます））の間に、チームは出荷可能な製品の増分を作成します（たとえば、動作中のソフトウェアとテスト済みのソフトウェア）。スプリントに含まれる一連の機能は、製品の「バックログ」から取得されます。これは、実行する作業の高レベルの要件の優先順位付けされたセットです。どのバックログアイテムがスプリントに入るかは、スプリント計画会議で決定されます。
それは方法論ではなく、顧客とのコミュニケーションについてです。
顧客が未完成のプロジェクトに常に新しい機能を追加したいと思う状況がたくさんあり、なぜそれが全体的なコストと遅延を増加させるのか驚いていました。それらの顧客のコンテキストと個性が異なるため、異なるアプローチが必要でしたが、いくつかのガイドラインとアドバイスを分離しようとするかもしれません。
- 顧客が要件の変更がコストと遅延の両方に影響を与える理由を理解するために必要な一般情報にアクセスできるであることを確認します。言い換えれば、技術者でない人がまったく知らないかもしれないことを説明して、それらのことについていくつかの記事を公開してください。
たとえば、ほとんどの人にとって、小さな変更がプロジェクトに大きな影響を与え、非常に費用がかかる可能性があるのはまったく奇妙です（例 私の質問では を参照）。彼らがいくつかの変更を行うように頼んだ場合、そしてあなたが何も説明せずに彼らに言うたびに、彼らはそれを無料または数十ドルで期待したときに数千ドルを支払わなければならないだろうと彼らはおそらくあなたがただだと思うでしょう彼らのお金を盗む。一部の非倫理的なプログラマーやソフトウェア会社は保守不可能な製品を開発しているため（通常の開発者が後で変更するように依頼することはできません）、変更するたびに多額の支払いを要求するため、これは特に当てはまります。
- 顧客が必要な特定の変更がコストに影響を与える理由を理解したであることを確認します。そのために、あなたは彼女にあなたの記事へのリンクを与えることができます（前のポイントを参照）、または単に技術的でない方法で、要求された変更を行うために必要なものを要約することができます。
このような説明は、顧客が製品と変更についてよりよく理解できるようにするためにも良い考えです。いくつかのケースでは、私の顧客の何人かは、彼らが望んでいた変更はあまり賢くはなく、他の方法でそれを行うだろうと言って終了しました。提案することもできます。一部の顧客から高く評価されており（警告：他の人はそれを嫌っています）、何について話しているのかを知っていることを示しています（可能なアプローチについてあまり考えずに、要件をコードに変換するコードモンキーと比較して） 。
- 本当に確信が持てない限り、顧客がやりたいことを何もできないようにします。一部の人々にとって、唯一の方法はコーディングを開始する前に要件を明確にロックするです。それ以外の場合これは災害であり、プロジェクトは決して終了しません。他の人にとっては、未終了のプロジェクトを絶対に見ないことをお勧めします（通常、私の顧客は非常に早い段階で未終了の製品にライブアクセスできるため、コメントや調整も早期に行うことができます）。
たとえば、「最終」要件を送信した後、マイナーな変更（「ホームページの中央ゾーンの境界線の幅を変更できますか？プロジェクト全体に影響を与えた変更（2か月の開発後、リリースの1週間前）：「最後に、ASP.NETは悪い考えだと思います。PHPお願いしますか？ "）。
したがって、その顧客の場合、コードを記述する前にすべての要件をロックする必要がありました。契約書に書かれていました。最終リリースの前に変更は受け入れられませんでした。
最後に、それはそれほど悪くはありませんでした。不思議なことに、非常に整理することができました。古い要件に従ってプロジェクトがリリースされ、数日後、まったく異なるセットで次のバージョンを最初から開始しました。要件の。