時間の見積もりがうまくいかない場合はどうすればよいですか？
ケースの推定所要時間を3日としましょう。 2日目には、ケースが増加しており、時間の見積もりが行われたときにカウントされなかった新しいシナリオがポップアップ表示されています。新しい発見は2日余分につながります（合計5日）。これは、遅かれ早かれ開発者として直面する典型的な問題です。
- プロジェクトリーダーに新しい配達時刻を通知するときに使用できる戦略はどれですか。
- なぜあなたはなぜ質問を受けるのですか？新しい配達時間をどのように動機づけますか？
実際、多くのプロジェクトでは、SDLC中に分析と設計にあまり時間をかけていません。
編集：非常に複雑なプロジェクトでは、分析と設計にかなりの時間を費やしても、ビジネスルールが複雑すぎるため、常に驚きがあります。ただし、そのような場合、プロジェクトリーダーは複雑さを認識し、予期しない驚きが生じたときに適切な態度を持つ必要があると思います。問題は、複雑さを理解していないプロジェクトリーダーにどのように取り組むかです。
悪いニュースの配信
迅速に問題を提起する必要がありますが、妥当なタイムスケール（数時間以上）で実施できる場合は、影響を評価する前に少し評価する必要があります。
すべての悪いニュースと同様に、（「遅れそうだ」と単にぼやけるのではなく）詳細な情報を提供するのが最善です。
1）ずれたタスクの見積もり/タイムスケールを修正しました。
2）将来のタスクの見積もり/タイムスケールが改訂されました。これは、いくつかのものが既に実行されていることを知っていることを踏まえると、さらに時間がかかる可能性があります。
3）スリッページが発生した非常に短い理由（スピンしないでください。真実ですが、言い訳をしているようには聞こえません）。この場合、「ルールXとYに基づいて推定しましたが、今では言及されなかったZが含まれています」と述べています。彼はこれをクライアントに遅延を説明し、そもそも徹底することの重要性を彼らに教育するのに使用できるかもしれません。
4）物事を軌道に戻すための可能な代替案（通常は範囲を縮小しますが、他のオプションがある場合があります-プロジェクトの他の部分は前倒しであり、タスクを移動できる可能性があります）。
スリッページで心理的/信頼性への影響は累積的であることを忘れないでください。あなたは1つでうまくいくかもしれませんが、2番目のものはもっと厳しいでしょう、そして3番目はまだもっと厳しいでしょう。
これがポイント2が重要な理由です。既にずれているものだけでなく、最初に予想したよりも時間がかかると思われる将来のタスクも修正してください。 ITでスリップが発生し、ミスから学ばないことは大きな罪です。
悪いニュースを配信しなければならないのを防ぐ
ここには2つのシナリオがあります。最初に、自分で見積もりを行っていません。その場合、次回の見積もりに関与するためにプッシュ以外にできることは多くありません。
次に、自分で見積もりを行いました。この場合、より良い見積もりを行う方法を検討する必要があります。私にとっての質問のキーフレーズは「ビジネスルールが複雑すぎるため、常に驚きがあります」。
に関してはそれが常に発生する場合、それは驚きではありません。ビジネスルールの半分しか得られない場合は、それを見積もりで想定し、機能のクリープを考慮する必要があります。
持っているルールの推定値を増やすことでこれを行うこともできます（機能しますが、実際に何が起こっているかについて誰にも教育していません）。ただし、「歴史的に、得られるルールは単純化されたバージョンです。彼らが本当に望んでいることのことです。彼らが述べたルールの実装には3日かかりますが、言及されていないが、開発やテスト中に発見される可能性があるルールについては、さらに3日間の偶発的な事態を許容する必要があります。」
PMがこれに疑問を投げかける場合は、それが真実であるすべての時間を彼に思い出させる必要があります（例を挙げて-例を論じるのは難しい））また、時間通りに提供することは彼の利益になることを優しく示唆する必要がありますあなたのものと同様に、保守的である方がいいのではないですか？
しかし、結論としては、特定の要因（この場合はフィーチャークリープ）のために常に過小評価している場合は、それを見積もりに含めます。
時間ベースの推定は将来についての推測であり、長期的には常に失敗します。勝てない無意味な戦いだ。
数日で推定を停止し、代わりに相対推定を使用して開始します。以下に簡単な例を示します。
- 各タスクに番号を割り当てます。最も難しいタスクは10で、最も簡単なタスクは1です。
- プログラミングを開始して、タスクを完了します。
- 1週間後、作業を停止し、完了したすべてのタスクの数を合計します。最終的に14になるとしましょう。これが毎週の速度です。
来週、このプロセスをもう一度繰り返します。あなたのベロシティは変わると思いますが、それほどではありません。これで数週間後、あなたの速度はかなり安定しているはずであり、それが私たちが目指していることです。これで、自信を持って計画を立てることができます。自分の速度に合わせてタスクを選択し、PMは、約束どおりに完了すると確信できます。これが、プロジェクトリーダーに取り組む方法です。
見積もりが間違っていることがわかったらすぐに警報ベルを上げる必要があります。配達を期待している人に遅れについて知らせてください。
可能であれば、チームメイトに助けを求めてください。可能な限り高品質のソフトウェアを配信するようにしてください。
ショートカットはおそらく最終的にはもっと害を及ぼす可能性が高く、関係者全員がこれを知っている必要があります。または、少なくとも彼らにそれを説明することが可能である必要があります。
これは非常に頻繁に発生するため、経験豊富なプロジェクト管理者が対処することはほとんどありません。正直に言って、楽観的に考えすぎないようにしてください。あなたがそれがもっと長くかかるのを見たとき、それを言ってください。毎日「もう少し時間が必要」と言ってはいけません。
マネージャーに説明する必要があります。そもそも見積もりが間違っていたのでしょうか、それとも遅延の理由が悪い状況（バグを探すのに1日かかった）でしたか。最初のケースでは、推定プロセスに何か問題があり、楽観的またはナイーブすぎる可能性があります。 2番目のケースでは、うまくいけばプロジェクト計画に含まれたバッファのケースです。
プロジェクトの見積もりはギャンブルであり、単純明快です。リスクがなければ報酬はありません。
マネージャーがこれを理解していない場合、それは私が最初に説明することです。
問題は、誰がリスクをカバーするかです。
固定価格の契約をしている場合は、リスクをカバーしています。
時間と材料の場合、彼はリスクをカバーしています。
したがって、推定するときは、推測していることを理解することが重要であり、推定がどれほど不確実であり、誰がリスクをカバーしているかを理解する必要があります。
見積りが過度に楽観的であったという事実（特に！）を含め、関連する利害関係者に常に進捗状況を知らせてください。彼らは喜ばないでしょうが、彼らはプロジェクトが実際にどこに立っているかを知っており、それに応じて計画することができます。
理想的には、機能のリストはMoSCoWedである必要があります。
あなたがオーバーランに向かっているとき、Couldsをカットし、次にShouldsをカットします。予定どおりに出荷できるように機能をカットします。通常、プロジェクトは孤立して存在せず、リリース日を過ぎると、ダウンストリームプロジェクトもスケジュールを超過することになります。
理想的には、約60％のマストのみが存在します。あなたがそれらを切り取らなければならない場合、あなたは非常に深刻な問題に直面しています（非常に深刻なオーバーランを持っています）。
リリース後は、十分に時間をかけて、手抜きによる混乱を解消してください。
最善の戦略は、見積もりを常に洗練することです。私の言うとおり、あなたの質問はどこか間違っている。
リーディング 故意の発見の紹介 ダンノース筆者は、開始フェーズに推定の労力をかけることは、問題とドメインについての無知が最大レベルにあるときに正確に予測を行うことに等しいという結論に達しました。それに直面して、特にそれがまだ不明である場合は、不確かなことを予測することはできません。
アジャイル手法は、この問題を解決してプロジェクトの寿命をいくつかの部分（スプリントではスクラム）に分割し、毎週見積もり（サイジングストーリー）を繰り返します。毎週、問題についてあなたが知っていること、そして見積もりも洗練されています。
私にとって、推定は真または偽にはなり得ません。これは、段階的に洗練することができます。見積もりは約束ではありません。それが推定と呼ばれる理由です。
遅刻した場合（および問題が同じであるという理由で「事前に配信するリスク」がある場合、見積りが間違っている場合）にできる最善のことは、エスカレーションして、できるだけ早く顧客にその事実を伝えることです。それはリスク管理と呼ばれています。フィードバックを早く送信するほど、対抗手段はより効果的になります。通常、つまり、すべてを提供できないという証拠がある場合は、お客様と話して、約束の70％だけを提供できることを伝え、より多くのビジネスがあるかどうかを彼女に判断させます。最初に展開する必要があります。
私はそれについてここに書きました 間違った見積もり、助けて！遅れました！機能をカットしてウォーターフォールを停止してください！
推測に基づいているため、見積もりと呼ばれます。これは間違いのない未来の説明ではなく、ソフトウェアの見積もりをそのように扱う人々にはほとんど忍耐力がありません。最終的に、多くのことは予想よりも時間がかかりますが、まれに、桁違いに時間がかかる場合があります。これは、世界で最も優秀なプログラマーでも起こります。マネージャーがあなたにそれが起こらないことをどのように期待できますか？上司がそれを理解していないと、彼女はあまり経験がありません。彼女がスケジュールのプレッシャーをかけるためにそれを理解しないふりをするならば、彼女は無理です。
最善のアプローチは最も明白です。機能が予想よりも長くかかることが明確にわかったら、すぐにマネージャーと話し合ってください。多くの場合、問題とマネージャーの両方を解決する方法がいくつかあります。つまり、物事を遅くしている機能の部分は、比較的重要ではないか、より迅速な進歩を可能にする方法で変更するのが簡単かもしれません。ただし、どのような場合でも、2番目の楽観的な見積もりにいじめられることはありません。
すべてのチームにそれを知らせて、解決策を見つけてください。優先度の高いものから低いものの3つのソリューションをお勧めします。
a。一時的なホットフィックス、またはクイックアラウンドを見つけるようにしてください
b。あなたができる仕事、最善を尽くしてください。仕事の優れた部分をクライアントに示した後、クライアントに助けを求めます。これは可能ですが、問題があり、作業の生産性が低下する可能性があります...不要なリクエストがあるかどうか尋ねることができます/ドロップ、または削減できる機能。
彼らの問題に対する代替アプローチを提案するのは良い考えかもしれません。
c。残業
オプション：
- カットフィーチャー
- 品質をカットします（バグ修正は後で残します）
- 生産性を高める
- ブロッカーを見つけて削除する
- 休憩/休憩
- 個人/睡眠時間を削減
- 労働力を増やす
- より良いツールを入手する
- トレーニング
- やる気を高める
- 無料の食事
- [約束]昇給/昇進/休暇/ボーナス/など。
- 脅威
- 労働条件を改善する（より良いハードウェア、家具など）
- 環境を変える-コーヒーショップで働くか、チーム全体をクールな場所に移動します-山小屋か湖の家ですか？
これはよくある問題です:)
より簡単なアプローチの1つは、予期しない問題が常に発生するため、実行する推定にバッファを追加することです。バッファーのサイズは、チームのサイズと、テクノロジーと問題自体の不確実性によって異なります。
チームが大きくなると、病気になる可能性のある人が多くなり、「すべて」を知っている人が少なくなります。
新しいテクノロジーは、すでに知っているテクノロジーよりも常にリスクが高くなります。
また、予定日までに完了しないことがわかった場合は、関係者と早めに連絡してください。おそらく、顧客/利害関係者と話し合った後で、項目の優先順位を付けたり、特定の機能を遅らせたりすることができます。