タスク/プロジェクトの複雑さを見積もるときに、上司（または同僚）をより注意深くするにはどうすればよいですか？

私はソフトウェア開発者で、小さなWeb開発会社で働いています。なかなか時間がかかるとミドルマネージャーから聞かれるのはよくあるテーマのようで、見積もりを出すと高すぎると思います。それがより技術的なマネージャーまたは別の開発者である場合、彼らは通常、自分自身の見積も​​りをすでに心に留めており、より速く実行できると考えているため、独自の方法でそれを実装しようとします。

ただし、他の開発者が見積りよりも大幅に多くの時間を費やしてしまう傾向があります。彼らは予算の半分を経て、実装計画では適切に対応できないビジネス上のニーズがあることを認識します。たいていの場合、私の計画はこの必要性に対処するはずでしたが、「あなたはそれを必要としない」機能として肩をすくめられました。

さらに悪いことに、彼らがこの壁にぶつかったとき、彼らは通常、彼らが自分たちが描いたコーナーから抜け出すのを手伝うために私のところに来ますが、私の一日にはほんの数時間しかありません。

最良の場合：これらの中断は、自分の開発作業に割り当てた時間に割り込んだため、他のプロジェクトが遅れたり、「Xを実行できる唯一の人」であるため、残業しなければなりません。

最悪の場合：私は自分でタスク/プロジェクトを引き継ぐ必要があり、その時点では予算に「私の」やり方でそれを行う時間は残っていません。彼らが始めた方法で彼らが始めたものを終わらせなければならないので、「会社はこれ以上お金を失うことはありません」。「私の」ハッキーコードになるので、これはいつも私に噛み付きます。それが壊れると、なぜそれがそのように作成されたのか、人々は私に尋ねます（結局のところ、誰が実際にそれを作成したのかわかりません）。

ですから私の質問は次のとおりです。物事が想像しているほど単純ではなく、クライアントのニーズに対する理解を再評価する必要があるときに、これらの同僚がどのように理解できるようにすることができますか？

[既存の]技術的負債に対処するための経営陣の説得に関するこの同様の質問とは異なり、私の質問は、それが最初から起こらないようにするために、チームが技術的負債を負おうとする前に[積極的に]実現するのを助けるための戦略を求めています。これら2つは密接に関係していますが、私の考えでは明らかに異なります。他の質問の答えは、将来の機能の見積もりにリファクタリング時間を追加することを提案しています。他の開発者（したがってマネージャー）が、将来の機能は実際よりも時間がかからないといつも考えている場合、これは決して機能しません。また、私の見積もりがより現実的であると彼らに納得させることができません。

毎日新しい見積もりを出すか、以前の見積もりに悩まされているので、この質問が大好きです。

答えは、あなたが話しているプロジェクト/タスクの大きさによって異なります。見積もりを処理するための本と方法があります。100万人の予算を持つ50人の開発チームのプロジェクトの見積もりは、小規模な「80時間のプロジェクト」での作業とは異なるアプローチを取ります。

• "ボトムアップ"見積もり-タスクを細かく分割できるほど、見積もりは良くなります。小さいパーツを個別に推定できます。これには、欠落している関数を特定できるという利点があります。ウェブサイトのモックアップを渡され、見積もりを求められたとします。ページ数ではなく、機能の数で行ってください。たとえば、ショッピングカートは「1ページ」の場合がありますが、10の異なる機能で構成できます。

• 「3ポイント」推定は、範囲として3つの推定を行うことを意味します。その後、「xxx機能の複雑度に応じて、40〜80時間」で応答できます。これは、見積もりにリスクを導入する良い方法です。チームの他のメンバーから推定値を取得することもお勧めです。誰かが50時間、他の誰かが100時間と言った場合、その違いについて話し合うことができます。

• 予算を満たす/期待値を設定する-予算が100時間であることがわかっていて、それが200時間のプロジェクトだと思われる場合は、コミットする前に期待値を設定するのに役立ちます。「あなたが求めたものはすべて200時間のプロジェクトです。feature-xを制限すると、100時間でそれが可能になります。」

• 開発時間vs.テスト時間vs.プロジェクト時間vs.カレンダー時間-これらはすべて異なり、もしあなたが1つのチームであるなら、それらすべてを混ぜ合わせるのは簡単です。要件の把握に8時間、開発時間の72時間を費やす必要がある場合、プロジェクトを完了するのに2暦週よりもはるかに長くかかります。特に、他のタスクのバランスをとる必要がある場合、チームとやり取りする、顧客を待つ、またはメールで何時間も書く必要がある場合。この場合、上司に「100時間、つまり開発時間のx時間、クライアントの処理にy時間、初期サポートのz時間」と伝えます。これは、コードだけでなく、時間も含めていることを示すのに役立ちます。

重要-見積もりはあなたの主な問題ではないと思います。外部と内部のコミュニケーションが重要だと思います。機能Xが非常に重要である場合、お客様は最初にそれを伝えたはずです。機能Xのリクエストが届いたとき、プロジェクトマネージャーは「範囲外ですが、現在の時間を再割り当てしたり、予算を拡大したりできます」と言っているはずです。

内部的にはコミュニケーションをとる必要があります。そうすることで、「遅すぎる」前に予算やスケジュールが上回っていることを上層部が認識できるようになります。タスクがあなたに渡されているとき、そのタスクに取り組む必要がある時間（時間単位）と時間（カレンダーなど）を知っている必要があります。タスクがこれらの制約内に収まらない場合は、それらを認識させる必要があります-「機能AとBは、Cを行う必要があります。これは、XとYのどちらにも時間を残しません」。

驚きはありません-プロジェクトに沿ってコミュニケーションを取り戻す必要もあります。良いものは必ず報告してください。ただし、予想よりも時間がかかっている場合は、すぐに伝えてください。プロジェクト全体の50％は、次のように言う責任があります。

「機能Xは予想よりも時間がかかっています。機能Yに到達できない可能性があります」。

期日については、次のことを言う責任はありません。

「時間切れになったので、機能Yはしませんでした」

個人的な想い-マネージャーがまだプログラマーであり続けたいと思っているとき、そして誰もが顧客を喜ばせたいと思っているとき、これはすべて本当に難しいかもしれません。

善を行い、それを知らせてください。

他の人の問題を修正する必要がある場合は、以前に話した内容に耳を傾けなかったため、または経験が浅すぎて何を言っているのか理解できないため、他の人と上司が、予期したときに理由が何であったかを確実に知るようにしてください。時間枠を逃し、どのような計画の失敗があったか。そして、あなたの同僚が過ちから学ぶことに対して完全に抵抗していなければ、状況はおそらく時間とともに良くなるでしょう。