セールスマネージャー：「なぜ時間の見積もりがそれほど複雑なのですか？」
数日前、営業マネージャーが私にその質問をしました。しかし、現時点では、彼が理解できる答えを知りませんでした。彼はプログラマーではありません！
現在、私は8年以上前の製品に取り組んでいます。誰もアーキテクチャや進化性について考えていませんでした。テストされていないコードの沼が毎日目の前にあります。そのため、時間の見積もりは非常に困難です。
セールスマンにその問題をどのように説明できますか？私の沼地コード問題だけでなく、一般的です！
迷路を通り抜けるのにどのくらい時間がかかるかを尋ねます。特定の迷路や特定のサイズの迷路ではなく、単に「迷路」です。
プログラミングはいくつかの点で似ています。解決する必要のある問題を完全に調査するまでにかかる時間はわかりません。確実に完了できるのは、完成した製品がすでにあるときだけです。
家づくりのアナロジーが思い浮かびます：家を建て直すのにどれくらい時間がかかりますか？家の形、どのような仕事をする必要があるかがわからないうちはわかりません。それはただ絵を描いているのでしょうか、それとも場所を配線し直し、壁をノックアウトし、新しい屋根を貼り付ける必要がありますか？
ただし、インベントリを取得する場合（およびコード行に基づいて、インベントリを取得するための時間をより確実に見積もることができる場合）、実行する必要があることと、実行する必要があることをより具体的にできると思います時間がかかるでしょう。 （これは2つの方法のプロセスです。さまざまな問題を文書化することで、プロジェクトをより深く理解し、プロジェクトを理解することで、問題についてより明確なビューを得ることができます。そのため、状況を分析し、書くのに時間をかけてくださいなぜあなたが何かがあなたが考えるのに時間がかかると思うかについてのあなたの説明。誰かにそれを説明する必要性によって、それはあなたにとってより明確になります。）
（ああ、そして販売マネージャーに思い出させるのを忘れないでください。誰もが壁紙の一部を剥がして始めた人は誰でも知っているので、基本的には砂利または砕いた石膏に接着されているかなりの耐荷重性の壁紙であることがわかります。は、大きな穴ができて、最初に壁を再構築する必要がありました。単純な外観の変更のように見えるものでも、突然、さまざまな新しい問題が明らかになる可能性があります。）
次の理由により、ソフトウェアの見積もりは困難です。
- ソフトウェア開発は不確実性でいっぱいです。
- 多くの場合、見積もりはcommitmentとしてマネージャーによって取得されます。
- 機能を実装するために必要な時間は、人によって非常に異なる場合があります
- 人間は時間でほとんど推定できません。ただし、人間はsizeの観点から簡単に推定できます。
私が使用するソリューション：
Planning Poker速度追跡 と ストーリーポイント ユニットの組み合わせ。
5〜7人の開発者のチームと非常に小さなチームで大規模なプロジェクトに完璧に取り組みます。重要：タスクを割り当てないでください。チームに決めてもらいます。
「ダンノ、なぜ売上予測がそれほど複雑なのですか？市場分析はどうですか？変換率は？」
バスに襲われた同僚を引き継ぐのにどれくらいかかるか彼に尋ねてください。この同僚は、営業リードをフォローアップする前に最初に理解しなければならない不可解な形式でメモを保管していました。
彼が「わからない」と言ったら、ただ笑ってください。
これを、会社が年間販売する予定の製品の予測と比較します。それは明らかに全く同じものではありませんが、うまくいけば、それは全体的に要点を得ます。また、製品の販売方法を理解することがなぜ複雑なのかを彼に尋ねることもできます。
'9人の女性が1か月で赤ちゃんを作ることができない'から始めて、（できればまだ時間どおりに）プロジェクトの状態に戻ります。
彼に言ってください、あなたはネガを文書化することはおそらくできません、そしてまだ届けられていないプロジェクトのタイムラインはネガティブです。発送の準備が整うまではわかりません。
販売ドロイドforcesがタイムラインに入る場合は、 six to eight weeks （うわー、どのようにして、ハイライトされたテキストをクリックできるのか）、それから自分が何に夢中になっているのかを知った後、1週目からそれを修正します。
彼にこれまでと同じようにクロスワードや数独パズルを作成したかどうか尋ねます。特定の未知数が判明した後、ソフトウェア開発には常に改良が必要であることを彼に説明します。理解が深まると、少なくともある程度は、見積もりの正確さが増します。
それが失敗した場合は、「キーを見つけるのにどれくらい時間がかかりますか？」と尋ねます。
（時間ベースの）ソフトウェアの見積もりが難しい理由を把握するには、ソフトウェア開発の性質について考える必要があります。
製造活動と設計作業の違いは、おそらくビジネスの人々が理解する必要がある最も重要な概念です。産業時代には、設計と製造の間に明確な違いがありました。工場で何度でも再現できる設計図を設計しました。
私たちは頭の中で同じモデルをソフトウェア開発プロセスに適用しています。最初に誰かが製品を設計し、その後さまざまな人々が製品を製造する必要があると仮定します。設計フェーズがいつ終了し、製造が始まるかについて考え始めると、これはソフトウェア開発には当てはまらないことに気付くでしょう。製品開発サイクルの次の表現を検討してください。
... => design => (blueprint) => manufacture => (product) => ...
直感は、これを次のようなソフトウェア開発に変換することを教えてくれるでしょう：
... => design => (Interaction design deliverables) => manufacture => (Source Code) => ...
実際にはそれは次のようなものです：
... => design => (Source Code) => manufacture => (Software application) => ...
つまり、ソースコードは製品ではなくデザインです。製造ソフトウェアは完全に自動化されています（ソースのコンパイル）。他の人が私がこれよりはるかによく説明しているので、ジャックリーブスのこのエッセイを読むことをお勧めします。ソフトウェアデザインとは何ですか？
設計と製造の違いは単なる概念的なものではなく、ソフトウェア開発の管理方法に非常に現実的な影響を及ぼします。設計作業は本質的に非常に予測不可能であり、個人に依存していますが、製造ははるかに予測可能でリソースに依存しています。
この考え方から、開発者間の個人の生産性のばらつきは非常に大きく、誰かが特定の時間内にどれだけ生産できるかを予測することは不可能です。これに関するより多くの洞察については、ポール・グラハムによる次のエッセイをチェックしてください：富を作る方法。
「設計！=製造」の考え方には、さらに多くの意味があります。もう1つ重要なことは、すでに利用可能なものを設計しようとはしなかったことです。これにより、開発作業の不確実性が高まります。
これらを、ビジネスの人々が開発者に低い見積もりに圧力をかける多くの理由に加えて、人々が絶対的な測定値を見積もるのに苦労しているという事実と、非常に不正確な見積もりのレシピを自分で入手したという事実。
それでもセールスマネージャーに疑問がある場合は、この記事で問題を解決できる場合があります。
...ソフトウェア開発コミュニティは、何かを見積もるのに非常に貧弱な実績があります。実際、プロジェクトが時間と予算を超えて実行され、当初の計画よりも機能が少ない低品質の製品を提供することは非常に一般的です。
問題の一部は、ソフトウェアの見積もりが非常に難しいことです。実際、個人の生産性の大きな違い、創造的なプロセスの計画が難しいという事実、ソフトウェアが無形であるという事実、そしてプロジェクトの存続期間中に何かが変わる可能性があるという事実-たとえば、範囲、予算、期限、要件-ソフトウェアの見積もりを困難な作業にします。
しかし、私の経験では、見積もりが不十分な主な原因は、さまざまな利害関係者が、見積もりの目的とその見方を知らないことが多いためです。この知識の欠如は、プロジェクトの目標とそれに関連する期待が現実的かどうかを判断する方法がないことを意味します。結果は、プロジェクトへの過剰なリソースの割り当てを引き起こす過大評価、またはより頻繁には、「死の行進」プロジェクトにつながることが多い総過小評価である可能性があります。少なくとも50％のノルム。例：
- スケジュールは、合理的なプロセスによって推定された量の半分未満に圧縮されています
- スタッフは半分以下で、同じサイズと範囲のプロジェクトに参加する必要があります
- 予算とリソースが半分以下である
- 機能、機能、その他の要件は、通常の状況の2倍です。
記事の残りの部分は、このテーマの基本をよりよく理解し、プロジェクトを終わらせないようにしたいプロジェクトマネージャー、開発者、顧客を対象としたソフトウェア見積もりプロセスの紹介です...
8年後のプロジェクトは非常に大規模であることを伝えてください。さて、いくつかの小さな変更を導入すると、それを機能させる前にシステムでさらに多くの変更をトリガーすることができ、それはあなたに依存しません。
1.仕事をする/コードを書く
2。試して
3。次に、変更がシステムの他の機能にどのように影響するかをテストします。
4。システムの動作を修正します。
1と2を見積もることはできますが、それが完了する前に、変更が全体にどのように影響するかはわかりません。それはテストなしでは不可能だからです。また、コードを記述するだけですべてがすぐに機能する場合もあれば、新しい機能を記述するだけでなく、システムに他の多くの変更を加えて意図したとおりに機能させる必要がある場合もあります。
ルービックのキューブ構成を20回以下で解決できることが証明されています（http://www.bbc.co.uk/news/technology-10929159）。
いくつかのルービックキューブを解くのにどれだけ時間がかかるかを尋ねます。
問題のソフトウェアはおそらくルービックキューブよりもはるかに複雑ですが、多くの場合、「それを見ることはできますが、それを手に取っていじることはできません」。
高すぎる見積もりをめったに出さないと思います。恐怖/不本意の下で作業していないことを確認して、長い見積もりを出します。すべての優れた営業担当者は、クライアントの要求に対して高レベルの緊急性を試み、伝えます。あなたの心の中であなたはそれがかかる時間の最小量が何であるかを理解するためにスクランブルしています。
質問がある場合は、問題をすばやく確認して、より適切な見積もりを行うために十分な情報を収集できるようにしてください。また、利用可能な時間を決定できる必要もあります。 2週間の休暇中、10日以内に何かを約束しないでください。
過労部分については、以前のリクエストで優先順位を付け直してほしいと思うものを見つけます。あなたは彼らが前のものに働き続けることを彼らが望んでいるであろう時間の半分以上にショックを受けるでしょう。
与えられた答えのいくつかに同意しなければなりません。プログラミングを迷路を通り抜ける方法と比較することはできません。学習の側面はあるものの、迷路を解決するスキルはあまりないことに同意します。家を建てたり、改築したりすることも、かなり明確なプロセスです。
私がIMOをプログラミングするために思いついた最高のアナロジーは、絵を描くアーティストのようなものです、芸術的な側面があり、より多くの画家がすぐに絵を完成させないため、推定することは不可能です。人々はプログラミングについてエンジニアリングのように考える傾向がありますが、実際にはそれは少し芸術的な職人技のようなものであり、それを見積もるのは難しいです