タスク/プロジェクトの複雑さを見積もるときに、上司（または同僚）をより注意深くするにはどうすればよいですか？
私はソフトウェア開発者で、小さな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暦週よりもはるかに長くかかります。特に、他のタスクのバランスをとる必要がある場合、チームとやり取りする、顧客を待つ、またはメールで何時間も書く必要がある場合。この場合、上司に「開発時間のx時間、クライアントの処理にy時間、初期サポートのz時間である100時間」と伝えます。これは、コードだけでなく、時間も含めていることを示すのに役立ちます。
重要-見積もりはあなたの主な問題ではないと思います。外部と内部のコミュニケーションが重要だと思います。機能Xが非常に重要である場合、お客様は最初にそれを伝えているはずです。機能Xのリクエストが届いたとき、プロジェクトマネージャーは「範囲外ですが、現在の時間を再割り当てしたり、予算を拡大したりできます」と言っているはずです。
内部的にはコミュニケーションをとる必要があります。そうすることで、「遅すぎる」前に、予算やスケジュールが上回っていることを上層部が認識できるようになります。タスクがあなたに渡されているときは、そのタスクに取り組む必要がある時間（時間単位）と時間（カレンダーなど）を知っている必要があります。タスクがこれらの制約内に収まらない場合は、それらを認識させる必要があります-「機能AとBは、Cを行う必要があります。これは、XとYのどちらにも時間を残しません」.
驚くことはありません-プロジェクトに沿ってコミュニケーションを取り戻す必要もあります。良いものは必ず報告してください。ただし、予想よりも時間がかかっている場合は、すぐに伝えてください。プロジェクト全体の50％は、次のように言う責任があります。
「機能Xは予想よりも時間がかかっています。機能Yに到達できない場合があります」.
期日については、次のことを責任を負うものではありません。
「時間切れになったので、機能Yはしませんでした」
個人的な想い出-マネージャーがまだプログラマーであり続けたいと思っているとき、そして誰もが顧客を喜ばせたいと思っているとき、これはすべて本当に難しいかもしれません。
良いことをして知らせてください。
他の人の問題を修正する必要がある場合は、以前に話した内容に耳を傾けなかったため、または経験が浅すぎて、彼らが言っていることを理解できないため、他の人や上司が、予期されたときに理由が何であったかを知るようにしてください。時間枠を逃し、どのような計画の失敗が発生したか。そして、あなたの同僚が過ちから学ぶことに対して完全に抵抗していなければ、状況はおそらく時間とともに良くなるでしょう。