タスクが思っているよりもはるかに長くかかる理由を非技術者に説明する方法は？[閉まっている]

ほとんどすべての開発者は、次のようなビジネス側からの質問に答える必要があります。
なぜ、この簡単な問い合わせフォームを追加するのに2日かかるのでしょうか？

開発者がこのタスクを見積もるとき、彼らはそれをステップに分割するかもしれません：

• データベースにいくつかの変更を加える
• DBの変更を最適化して速度を向上させる
• フロントエンドHTMLを追加
• サーバー側のコードを書く
• 検証を追加
• クライアント側のJavaScriptを追加
• 単体テストを使用する
• SEOセットアップが機能していることを確認してください
• 確認メールを実装する
• コードをリファクタリングして最適化して速度を向上させる
• ...

これらは、基本的にタスク全体をHTMLをまとめてデータを保存するためのテーブルを作成するものと見なしている、技術に詳しくない人に説明するのは難しいかもしれません。彼らにとっては、最大で2時間です。

では、なぜ推定値が開発者以外にとって高いのかを説明するより良い方法はありますか？

あなたはあなたの質問でそれをやったばかりです。

タスクを個々のステップに分割し、各ステップの推定値を提供します。これは、すべてのオプションを検討し、（できれば）すべての不測の事態をカバーしたことを示します。

タイムスケールが大きすぎる場合は、クォートをパイントポットに詰め込むのではなく、具体的なデータを使用して、この場合に必要な部分（電子メールの確認など）を議論できます。

これを十分に頻繁に行うと、一見して目を合わせるよりも開発には通常多くのことがあることを教えてくれることを願っています。

タスクをリストすることはほぼ完璧ですが、エンジニアにとって完全に意味のあるタスクは、技術に詳しくない人にとってはほとんど意味がないことに留意してください。たとえば、上記のリストで、「速度のためにDBの変更を最適化する」ことは、コードのプロファイリング、スローポイントの検索、エキスパートによるレビュー、またはコードのスロースルーを含む1つまたは複数の時間のかかるタスクであることを知っています製品に固有の事前定義済みテストのセット。そして、遅すぎるエリアを修正する方法を見つけようとしている間に、机の上で頭を叩くのに数日ではないとしても、おそらく数時間かかるでしょう。

しかし、「最適化」という言葉ではない場合、「DB」という言葉でプロジェクト管理を失う可能性があります。

私は通常、ビジネスの観点からリスクを説明する言葉を使って、BIGステップの観点からプロジェクト管理にこのようなことを表現します。あなたのリストを取って、私が私のプロジェクト管理と話していたら、私はこのようにそれを煮詰めます：

1. まず、このことには2つの部分があります。ユーザーに表示されるWebページと、面倒な作業を行うサーバーです。この機能が機能するには、両方の部分が存在する必要があります。
2. 最初の部分は、ユーザーにとって意味のあるWebページを作成することです（フロントエンドHTMLを追加し、クライアント側javascriptを追加します）。ここで重要なのは、Webページがこの製品の一部のように見えなければならず、サポートするすべてのブラウザーで動作し、洗練されている必要があるということです。これはユーザーが見るものなので、見た目が悪い場合、ユーザーは製品が悪いと思うでしょう。これを開発してからテストするにはX日間かかります。
3. 次に、Webページの下に作業を行うものが必要です。この場合、ここに機能の説明を挿入することを意味します（マップ-データベースにいくつかの変更を行い、サーバー側コードを記述し、電子メールの確認を実装し、検証を追加し、単体テストを使用します）。これを一緒に投げることはできません。コードを開発してからテストすると、すべてのユーザーのデータが破損する危険があります。つまり、この特定の機能を使用していないユーザーであっても、単純な新しいものが製品全体の評判を損なう可能性があることを意味します。私たちの開発プラクティスはこれをカバーします-それが起こらないことを確認するために多くのテストを行います-しかし、それは適切にテストするために時間内に計画しなければならないことを意味します。それにはY日かかります。
4. 当社の製品では速度が大事です。物事がすぐに起こらない場合、ユーザーは製品が良くないと思うでしょう。そのため、これらすべてを書いた後、作業を​​進めて、パフォーマンスの点で標準に達していることを確認する必要があります。これはウェブ関連では大したことです。サイトの動作が遅くなったのを見ると、同じニーズを満たすために別の製品をすぐに使用することになります。通常、この種の作業にはZ日間かかります（速度のためにDBの変更を最適化し、速度のためにコードをリファクタリングし、最適化します）

半日未満の見積もりは避けます。彼らは、あなたが話していることを知っていることを、あるレベルで信頼しなければなりません。そして、彼らが本当に2時間だと本当に思っているなら、SW開発者の生活の中で正確に2時間がどのように見えるかを見て、2時間一緒に座って彼らを招待してください-それからコーディング101クラスをしてください約2時間。問題の解決を開始するためにすべてを考慮する必要があることを正確に示します。

最も重要なのは次のことです。

• 顧客の認識と製品の使用について最もよく話して購入すると、彼らの言語（$$の言語）を話そうとしています。要点は、コードが見苦しい方法で一緒にハッキングされた場合、最終的にビジネスを失うことですこの機能については、その後の貧弱な開発慣行によりコードの拡張が不可能になった後続の機能について。
• イベントのシーケンスを設定します。次の非技術的な質問は、「あなたよりも多くの開発者がいる場合、これはもっと早く起こりますか？そうであれば、これを行うのに40時間かかるなら、40人が今日の午後に実現できますか？」もちろん、答えは「NO！あなたはあなたの心の外ですか??」です。しかし、それは最高のものではありません。最良の方法は、ここに論理的な一連の手順があることです。Thing Bは、Aが実行されるまで実行できません（コードを作成していない場合、実際に最適化またはテストすることはできません...）。ただし、AとA 'の両方を一緒に行うことができるので、彼らがあの賢い人をspareしまないなら、1週間から4日間に時間を削ることができ、素晴らしいテストサポートを保証できるなら、おそらく3日。そこ'
• リスクに焦点を合わせ、現時点でいくつかのリスクに価値があると言われるように準備してください。それは、ビジネスの人が大金を支払われることです-どのリスクが取る価値があるかを考え出します。たとえば、短期間にばかげた数のサーバーを準備するのに十分な現金を手に入れているために、市場投入の速度がパフォーマンスの低下に重きを置いている場合、ステップ4（コード/データベースの最適化）。それは彼らの権利です-その決定に固有のリスクを説明するのはあなたの仕事です。
• ただし、これらの人々を信頼していない場合は、書面で確認してください-対立する必要はなく、単に「ここで私が話し合ったと思うこと、私がしていないことはここにあります。リスクがあります。同意しない場合はお知らせください...連絡がなければ、これが正しい方法だと思います」製品管理が短期的なメモリ損失の中心になり得ることを考えると、これは誰にとっても非常に役立ちます。

「5ポンドの袋に10ポンド（がらくた）は収まらない」ということわざがあります。あなたの仕事は、タスクが10ポンドであり、5ポンドの時間枠でそれを要求していることを示すことです。

不足しているのは時間の見積もりだけです。各タスクに時間の見積もりを入れ、これらすべてがあなたが提供する見積もりにどのように加算されるかを示します。4時間を超える見積もりを許可しないでください。「1日」または「10時間」と言うタスクがある場合、それをより小さなサブタスクに分割します。

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

これで、費用の明細書が作成されました。合計で最大27時間の作業になります。

これを顧客に見せて、「これらは、それぞれの費用で行わなければならないことです」と言うことができます。時間はコストであり、経営陣はコストを理解しているため、「コスト」という言葉を使用します。最後に2つの最適化タスクを削除することもできますが、それらは将来的にはマイナスの効果があり、合計見積もりの​​15％にすぎないことを説明します。

また、あなたの時間/日が何であるかを現実的に説明してください。たとえば、テクニカルサポートの実行、データベースの保守などが必要な場合は、それを見積もりに反映します。おそらくできないので、「1日7.5時間、良いコーディングができる」と言ってはいけません。おそらく5または6に近いでしょう。

次に、最も重要なこととして、進捗状況を追跡します。1日5時間のコーディングができるとしましょう。その後、月曜日に最初の2つのタスク（この例では）をノックオフし、火曜日に3番目を完了して4番目を開始できるようになります。これを示すチェックリストを作成して、水曜日に来て、「金曜日の終わりまでにどうするつもりですか」と言うことができるようにします。

私の講演のスライドを参照してください。数年前にOSCONで行った「危機の防止：プロジェクトの見積もりと追跡」。スライド21「週の計画」をご覧ください。サンプル速度チャートもあります。

彼らに尋ねる：

どうしますか？どのモジュールを変更しますか？コードの行数は？セキュリティへの影響は何ですか？データベーススキーマに変更はありますか？DBに変更を加えた場合、影響を受けるファイルの数は？最後のフォームを追加するのにどれくらい時間がかかりましたか？フォームを追加するための平均（算術平均）とは何ですか？最長は何でしたか？私はそれが最長よりも1分かかると推定します。最後のN個のフォームを追加するのにかかった時間がわからない場合、この推定値は1桁の精度しか保証されません。

彼らのソフトウェアは、10,000の異なる部品を備えた100トンの機械のようなものであり、その多くは複雑な方法で接続されていると説明するように言うことができます。この機械に1インチの部品をはめ込むには多少のエンジニアリングが必要であるため、機械を破損させませんが、より良い答えは次のとおりです。

より優れたコードアーキテクチャがあれば、このようなタスクは簡単になりますか？その答えは、ほとんどのソフトウェアチームは優れたアーキテクトではないということです（単に、大量の汎用のアーキテクチュアルテンプレートを蓄積していないか、すべての問題を十分に予測できる問題領域のマスターではないため） 、彼らは見積りや約束をすることに自信を持っていない。

20世紀に大規模な建物を構築するための優れたアーキテクチャとエンジニアリングを蓄積するのにかかったように、ソフトウェアエンジニアリングのツールはまだ主流になっていません。それらは開発されています。新しい考え方が必要です。wiki.hackerspaces.org/Hacking_with_the_TaoのZen Codeを参照してください。