「いつ完成するの？」と答える方法

私たちは皆それを持っています、あいまいなコードと奇妙な予期しない機能によって修正と修正を行うことが難しいことが判明した問題。ゆっくりと、パターン、エラー、間違いを見つけようとして、論理的に作業を進めます。このプロセスには時間がかかり、問題はクライアントによって簡単に理解されないことがよくあります。

特にクライアントがソフトウェア開発の固有の複雑さを理解していない場合、「いつ完了するのですか」という質問に対してどのように答えますか？

あなたは質問に正直に答えます。

あなたはそれが難しい問題であり、解決策は明白ではなく、解決するのにどれくらい時間がかかるかわからないことを彼らに伝えます。[時間枠]ごとに進捗状況を更新することを約束します。そうすることで、彼らはあなたがそれに取り組んでいることを認識し、もちろん実際に更新を送信します。

開発者は、複雑な問題を小さな問題に分解し、個別に解決することでアプローチします。

理想的な世界では、この問題を解決することは、複雑な問題になりAと、あなたは、与えられた時間内に、できるようになる、小さな問題の短いリストにそれを分解するためにA ₁にA _nは、それぞれが時間を評価するために与えられた、単純です最初の複雑な問題を解決するのに必要な時間は次のとおりです。

Dは分解自体のプロセスです。

現実の世界では、唯一の問題は、t（D）が実際に小さな問題の解決に費やす時間よりも大きくなることです。つまり、このレベルの問題の分解を実現するには、実際に問題自体を解決する必要があります。

あなたはまだすることができます：

• 指定されたタスク（問題の解決）を小さなチャンクに分離します。各チャンクは依然として複雑な問題です。

• 各チャンクの予想時間と対応するリスクを評価します。

  たとえば、タスク1には約が必要です。5時間ですが、ブロックされるリスクが高いため、顧客への期待として12時間を与えてください。

• 依存関係と、それらが時間に与える影響を評価します。

  たとえば、タスク19には2時間必要ですが、リスクは非常に低いため、確かに2時間と言えます。1.ではない3.しかし、タスク19はタスク24に依存しています。タスク24は、別のアプローチを使用してタスク19のコードを完全に書き直す必要があるような方法でタスク19に影響を与える可能性があります。

• これらすべての詳細を顧客に伝えます。合計を与えないでください。

最後のポイントは重要です。合計を与える場合、たとえば192時間とすると、顧客はそれが非常に正確なメトリックであると信じており、費やす時間は、たとえば189〜195時間です。

代わりに、あなたが詳細を与えるなら、

• 気にされるお客様は、それが192時間ではないことを理解します。評価中に決定されたリスクを考えると、すべてがうまくいかない場合は192時間です。すべてがさらに悪化した場合も238時間です。すべて問題なければ、85時間です。

• 気にされないお客様は、必ずお答えを読ませていただくわけではありません。彼が望んでいるのは、後であなたを責めることができるようにするための数字だけです。彼は決して読まない非常に詳細な答えを与えることにより、彼はそれが再びかかる時間を尋ねることができないことを知っています：あなたはすでにそれに答えました。合計を計算するための答えを読んでいないので、彼は後であなたを責めることもできません。

ホフスタッターの法則を含めることを忘れないでください。ホフスタッターの法則を考慮に入れても、予想よりも常に時間がかかります。

通常、私はCPM / PERTから変更された式を使用します。それは次のようなものです：

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

（私はすべての空想的な数学の書式設定を行う方法がわかりません。誰かがそのためにこれを編集したい場合は、自由に感じてください。）

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

プロジェクトの進行状況によって、大幅に異なる可能性があることを強調します。数日ごとにプロジェクトを再評価する場合、毎週の更新を提供することもできます。それはイライラするクライアントを満足させるのに大いに役立ちます。:)

あいまいなタイムラインを非技術ユーザーに説明するのは難しいです。これは、プロジェクトのクリエイティブフェーズでも、厄介なバグを追跡する場合でも当てはまります。どちらの場合も、従来の「作業をより細かい部分に分解する」ことも機能しません。

元のタスクは後者のケースに焦点を当てているので、それについて詳しく説明しましょう。タイムラインを提供できない場合は、何を試すか、いつ戻ってくるかをユーザーに伝えます。自分で課したタイムラインの中間点に到達したら、短くて正直な電子メール更新を提供します。締め切りの少なくとも1時間前に正式な返答をしてください。今、あなたは信頼性を持っています。問題が解決しない場合、あなたはいくつかの光を放っています。時間の無駄に思えるかもしれませんが、そうではありません。

未知の障害や予期せぬ驚きを説明することはできないため、自信を持って推定することは困難です。アイデア：

• 範囲を試してみてください- 「私は必ずそれが少なくともN日（例えば3）にかかりますが、可能性がある 4Nの数だけ取ります。」
• 見積もりの​​見積もりと防御において、より多くの上級エンジニアのサポートを求めます。
• 短い反復（アジャイル/スクラムスタイル）で作業して、ビジネス価値を追加する（信頼と信頼を得る）最小限のコードを生成し、繰り返します。
• 古典的なGetting to Yes（http://www.amazon.com/gp/aw/d/0143118757）のような本から交渉スキルを学ぶ。

新規開発、特にアジャイル開発の場合：

「完成するのは、追加するものが何もないときではなく、取り除くものが残っていないときです。」-アントワーヌドサンテグジュパー

システムの深いドメイン知識を持つ開発者がほとんどまたはまったくいない、非常に複雑で非常に複雑なシステムでエラーを再現することがほぼ不可能である場合の修正の労力と時間を見積もる場合、唯一の正しい答えは「いつ修正されるか」です。

通常、私は彼らに真実を語るだけです。今はわからないことを伝えます。1週間でもっとよくわかるかもしれません。それから、紙にフィットして、それが直感に基づく推測であることを示すことができるのと同じくらい多くの波線のあるボールパークを彼らに渡します。彼らがあなたに固執し始めたら、すべての文を「それは可能です...」で始めてくださいまたはそのようなもの。

パーソナルソフトウェアプロセス（PSP）は、見積もりの​​改善に重点を置いています。これは、統制のとれたタスクのロギングによって実現されます。これは、典型的なタスクに関する実際のデータが得られるので、本質的に、推定の「経験」の部分をいくらか「加速」します。もちろん、この職業には依然として多くの問題に対する独自の解決策が必要ですが、私の経験では、PSPを使用した後の推定値はより優れています。