時間の見積もりがうまくいかない場合はどうすればよいですか？

ケースの推定時間が3日間だとしましょう。2日目には、ケースが増えており、時間の推定が行われたときにカウントされなかった新しいシナリオがポップアップしていることに気付きます。新しい調査結果は、2日間余分にかかります（合計5日間）。これは、開発者として遅かれ早かれ直面する典型的な問題です。

• プロジェクトリーダーに新しい納期を通知する場合、どの戦略を使用できますか？
• 多くの場合、なぜ質問がありますか？新しい配達時間をどのように動機付けますか？

実際、多くのプロジェクトでは、SDLCの分析と設計にあまり時間をかけていません。

編集： 非常に複雑なプロジェクトでは、分析と設計にどれだけ合理的な時間を費やしても、ビジネスルールが複雑すぎるため、常に驚きがあります。しかし、そのような場合、プロジェクトリーダーは複雑さを認識し、予期しない驚きが生じたときに正しい態度をとる必要があると思います。問題は、複雑さを理解していないプロジェクトリーダーにどのように取り組むかです。

悪いニュースを伝える

問題を早急に提起する必要がありますが、妥当なタイムスケール（数時間以上）でできる場合は、その前に少しの影響評価を行う必要があります。

すべての悪いニュースと同様に、詳細情報を提供するのが最善です（単に「遅れる」のではなく）：

1）スリップしたタスクの修正された推定値/タイムスケール。

2）いくつかの事柄がすでにオーバーランしていることを知っていることを考慮して、あなたが現在考える将来のタスクの修正された推定/タイムスケールは、より長くかかるかもしれません。

3）スリッページが発生した非常に簡単な理由（スピンしないで、真実だけで、言い訳をしているように聞こえないでください）。この場合、「ルールXおよびYに基づいて推定したが、言及されなかったZが含まれるようになった」と述べます。彼はこれを使用して、クライアントへの遅延を説明し、そもそも徹底することの重要性を彼らに教育することができます。

4）可能であれば、物事を軌道に戻すための代替案（通常は範囲を縮小しますが、他のオプションがある場合があります-プロジェクトの他の部分が事前にあり、タスクを移動できる可能性があります）。

スリッページでは、心理的/信頼性への影響が累積的であることを忘れないでください。あなたは1つで逃げることができるかもしれませんが、2つ目のものはずっとタフになり、3つ目はまだタフになります。

それがポイント2が重要である理由です-すでにスリップしたものだけでなく、現在予想されているよりも時間がかかると思われる将来のタスクも修正します。ITでスリップが発生するのは、あなたの間違いから学ばないことは大きな罪です。

悪いニュースを配信する必要がないようにする

ここには2つのシナリオがあります。1つ目は、自分で見積もりをしなかった場合です。その場合、次回の見積もりに関与するためにプッシュする以外にできることはあまりありません。

次に、自分で見積もりを行いました。その場合、より良い見積もりを行う方法を検討する必要があります。私にとっての質問のキーフレーズは、「ビジネスルールが複雑すぎるため、常に驚きがあります」です。

敬意を表して、それが常に起こるのであれば、それは驚きではないはずです。ビジネスルールの半分しか得られない場合は、見積もりでそれを想定し、機能のクリープを考慮に入れる必要があります。

あなたが持っているルールの推定値を増やすことでこれを行うことができます（それは動作しますが、実際に何が起こっているのかをだれにも教育していません）が、推定値で述べる方が良いです彼らが述べたルールの実装には3日間かかりますが、言及されていないが開発およびテスト中に発見される可能性が高いルールについては、さらに3日間の偶発事象を許可する必要があります。」

PMがこれに疑問を呈した場合、あなたは彼にそれが真実であるすべての時間を思い出させる必要があります（例で-例について議論するのは難しいです）また、あなたのものではなく時間通りに配達することは彼の利益になることを穏やかに示唆します保守的になる方が良いですか？

しかし、肝心なのは、特定の要因（この場合は機能クリープ）のために常に過小評価している場合は、それを推定値に含めることです。

時間ベースの推定値は、将来についての推測であり、長期的には常に失敗します。勝てない無意味な戦いです。

数日で推定を停止し、代わりに相対推定の使用を開始します。以下に簡単な例を示します。

1. 各タスクに番号を割り当てます。最も難しいタスクは10で、最も簡単なタスクは1です。
2. プログラミングを開始してタスクを完了します。
3. 1週間後、作業を​​停止し、完了したすべてのタスクの数を合計します。あなたが14で終わるとしましょう。それはあなたの毎週の速度です。

来週、このプロセスをもう一度繰り返します。あなたのベロシティは変わるだろうが、それほど大きくはないだろう。これで数週間後、あなたのベロシティはかなり安定するはずです。それが私たちが目指していることです。これで、自信を持って計画を立てることができます。速度に応じたタスクを選択すると、PMが約束どおりに完了することが確実になります。それがあなたのプロジェクトリーダーに取り組むべき方法です。

推定値が間違っているのを確認したら、すぐにアラームベルを上げる必要があります。配達を予定している人に遅延について知らせます。

可能であれば、チームメイトに助けを求めてください。可能な限り高品質のソフトウェアを提供するようにしてください。

ショートカットは最終的にはより多くの害を及ぼす可能性が高いため、関係者全員がこれを知っている必要があります。または少なくとも彼らにそれを説明することが可能であるべきです。

これは非常に頻繁に発生するため、経験豊富なプロジェクト管理者がその大部分を成し遂げることはありません。正直に言って、楽観的に新しい見積もりをしないでください。あなたがそれを見るとき、それはもっと長くかかります、と言ってください。毎日「もう少し時間が必要だ」と言わないでください。

あなたはマネージャーに説明する必要があります：そもそも見積もりが間違っていたのでしょうか、それとも不利な状況（1日でバグを探している）が遅延の理由でしたか？最初のケースでは、推定プロセスに何か問題があります。楽観的すぎるか、素朴すぎる可能性があります。2番目のケースでは、バッファがプロジェクト計画に含まれることが望まれます。

（特に！）見積もりが過度に楽観的であったという事実を含め、関連する利害関係者に常に進捗状況を知らせておいてください。彼らは満足しませんが、プロジェクトが実際にどこにあるかを知っており、それに応じて計画することができます。

理想的には、機能のリストはMoSCoWedである必要があります-Must、Should、Could、Wo n't。

オーバーランに向かうときは、Coulds、次にShouldsをカットします。予定通りに出荷できるように機能をカットします。通常、プロジェクトは単独では存在せず、リリース日を過ぎると、下流のプロジェクトもスケジュールを超過することになります。

理想的には、〜60％のMustのみが必要です。それらをカットする必要がある場合、非常に深刻な問題（非常に深刻なオーバーラン）に陥り、その場合はコーナーをカットする必要があります。

リリース後、コーナーを切って作った混乱をきれいにするために十分な時間を与えてください！

プロジェクトの見積もりはギャンブルであり、単純明快です。リスクのない報酬はありません。

マネージャーがこれを理解していない場合、それは私が説明する最初のものです。

問題は、誰がリスクをカバーするのか？

固定価格契約を結んでいる場合は、リスクをカバーしています。

時間と材料の場合、彼はリスクをカバーしています。

したがって、推定する際には、推測していることを理解することが重要であり、推定がどれほど不確実で、誰がリスクをカバーしているかを把握する必要があります。

最善の戦略は絶えずあなたの見積もりを洗練することだと思います。私は言っています、あなたの質問はどういうわけか見当違いです。

Dan Northの「意図的な発見の紹介」を読んで、問題と領域に対するあなたの無知が最大レベルにあるときに正確に予測を行うことに等しいと、結論を導き出しました。それに直面すると、特に不明な場合は特に、不確実なものを予測することはできません。

アジャイル方法論はこの問題を解決し、プロジェクトの寿命をいくつかの部分に分割し（スプリント、スクラム）、毎週見積もりを繰り返します（ストーリーのサイジング）。毎週、あなたが問題について知っていることは洗練され、推定も洗練されています。

私にとって、推定値は真でも偽でもあり得ません。それは、次第に洗練されていきます。見積もりはコミットメントではありません。それが推定と呼ばれる理由です。

遅れたとき（そして、問題が同じであるため「事前に配達するリスク」もあるとき）にできる最善の方法は、エスカレーションして、できるだけ早く顧客に事実を報告することです。リスク管理と呼ばれます。フィードバックを早く送信すればするほど、カウンターミスはより効果的になります。通常、すべてを提供できないという証拠がある場合は、顧客と話をして、コミットメントの70％だけを提供できることを伝え、彼女にとってよりビジネス価値があるものを最初に展開するように彼女に決定させることを意味します。

私はそれについてここに書いた間違った推定、助けて！遅刻だ！フィーチャーをカットしてウォーターフォールを止めましょう！

それは経験に基づいた推測であるため、推定値と呼ばれます。それは未来の絶対的な説明ではなく、ソフトウェアの見積もりをそのように扱う人々に私は少しの忍耐しかありません。最終的に、多くのことは予想よりも長くかかりますが、まれに1桁以上の時間がかかる場合があります。これは、世界で最も優れたプログラマーでも起こります。マネージャーはどうしてそれがあなたに起こらないと期待できますか？マネージャーがそれを理解していない場合、マネージャーはあまり経験がありません。彼女がスケジュールのプレッシャーをかけるためにそれを理解しないふりをするなら、彼女は不合理です。

最良のアプローチは最も明白です。機能が予想よりも長くかかることが明確にわかったら、すぐにマネージャーと話し合ってください。多くの場合、問題とマネージャーの両方を解決する方法があります。つまり、機能の速度が低下している部分は、比較的重要ではないか、より迅速な進歩を可能にする方法で変更するのが簡単です。ただし、どのような場合でも、2番目の楽観的な見積もりにいじめられないでください。

すべてのチームに知らせて、解決策を見つけてください。優先度の高いものから低いものまで、3つのソリューションをお勧めします。

a。一時的なホットフィックスまたはクイックアラウンドを見つけてみてください

b。あなたがそれをすることができる仕事は、最善を尽くします。仕事の素晴らしい部分をクライアントに見せた後、彼らに助けを求めてください：私たちはこれを行うことができますが、いくつかの問題があり、それはあなたの仕事の生産性を低下させるかもしれません...ドロップまたはカットできる機能。

彼らの問題に対する代替アプローチを提案するのは良いアイデアかもしれません。

c。残業

オプション：

• カット機能
• カット品質（バグ修正は後ほど残します）
• 生産性を高める
  • ブロッカーを見つけて削除する
  • 休憩/休憩
  • 個人/睡眠時間を短縮
  • 労働力を増やす
  • より良いツールを入手
  • トレーニング
  • モチベーションを高める
    • 無料の食事
    • [約束]昇給/昇進/休暇/ボーナス/など。
    • 脅威
    • 労働条件の改善（より良いハードウェア、家具など）
    • 環境を変える-コーヒーショップで働くか、チーム全体を涼しい場所に移動する-マウンテンロッジまたは湖の家？

これはよくある問題です:)

より単純なアプローチの1つは、予期しない問題が常に発生するため、推定にバッファーを追加することです。バッファのサイズは、チームのサイズと、技術と問題自体の不確実性に依存します。

より大きなチームには、病気になる可能性のある人が多く、「すべて」を知っている人が少なくなります。

新しいテクノロジーは、あなたがすでに知っているテクノロジーよりも常に危険です。

そして、予定日に終了しないことがわかったら、利害関係者と早めに連絡してください。たぶん、顧客/利害関係者と話し合った後に、優先順位を付け直したり、特定の機能を遅らせたりできます。