技術者以外の人に、なぜタスクが思っているよりもずっと長くかかるのか説明する方法は？
ほとんどすべての開発者は、次のようなビジネス側からの質問に答える必要があります。
この簡単なお問い合わせフォームを追加するのに2日かかるのはなぜですか？
開発者がこのタスクを推定するとき、彼らはそれをいくつかのステップに分けるかもしれません：
- データベースに変更を加える
- 速度のためにDBの変更を最適化する
- フロントエンドHTMLを追加
- サーバーサイドコードを書く
- 検証を追加
- クライアント側のJavaScriptを追加
- 単体テストを使用する
- sEO設定が機能していることを確認する
- メール確認を実装する
- コードをリファクタリングし、速度を最適化する
- ...
これらは、基本的にタスク全体をいくつかのHTMLを組み合わせてデータを格納するためのテーブルを作成するものと見なす非技術者に説明するのは難しいかもしれません。彼らにとってそれは2時間MAXであるかもしれません。
では、なぜ開発者以外の人にとって推定値が高いのかを説明するより良い方法はありますか？
あなたはあなたの質問でそれをしました。
タスクを個々のステップに分割し、各ステップの見積もりを与えます。これは、すべてのオプションを検討し、（できれば）すべての不測の事態をカバーしたことを示しています。
タイムスケールが大きすぎる場合は、クォートをパイントポットに詰め込もうとするのではなく、具体的なデータを使用して、この場合に不要な部分（電子メールの確認など）について話し合うことができます。
これを頻繁に行うと、一目で目に見えるよりも開発には通常多くのことがあることをうまく説明できます。
タスクをリストアップすることはほぼ完璧ですが、エンジニアにとって完璧な意味を持つタスクは、技術者ではない人にとってはほとんど意味がないことを覚えておいてください。たとえば、上記のリストで、「DBの変更を速度のために最適化する」ことは、コードのプロファイリング、遅いポイントの検索、専門家によるレビュー、またはコードの実行など、1つまたは複数の時間のかかるタスクである可能性があることを知っています。製品に固有の事前定義されたテストのセット。そして、遅すぎる領域を修正する方法を見つけようとしている間、おそらく数日ではないにせよ、数時間頭を机にぶつけます。
しかし、「最適化」という言葉でなければ、「DB」という言葉のプロジェクト管理が失われた可能性があります。
私は通常、このことをプロジェクト管理に大きなステップで表現し、ビジネスの面でリスクを説明する言葉を使用します。リストを見て、プロジェクト管理と話していたら、このように要約します。
- まず、これには2つの部分があります。ユーザーに表示されるWebページと、負荷のかかるサーバーです。この機能を動作させるには、両方のパーツが存在する必要があります。
- 最初の部分は、ユーザーにとって意味のあるWebページを作成することです（フロントエンドHTMLを追加し、クライアント側のJavaScriptを追加します）。ここで重要なのは、Webページがこの製品の一部のように見える必要があり、サポートするすべてのブラウザーで動作する必要があり、洗練されている必要があることです。これはユーザーが目にするものなので、見た目が悪いと、ユーザーは私たちの製品が悪いと思います。これを開発してからテストするには、X日かかります。
- 次に、作業を行うWebページの下にあるものが必要です。この場合、これはここに機能の説明を挿入（データベースに変更を加え、サーバー側のコードを記述し、電子メールの確認を実装し、検証を追加し、単体テストを使用する）を意味します。これを一緒に投げることはできません。コードを開発してテストすると、すべてのユーザーのデータに損害を与えるリスクがあります。つまり、単純な新しいものが、この特定の機能を使用していないユーザーであっても、製品全体の評判を損なう可能性があります。私たちの開発プラクティスはこれをカバーします-私たちはそれが起こらないことを確認するためにたくさんのテストを行います-しかし、それは適切にテストするために時間内に計画しなければならないことを意味します。それにはY日かかります。
- 私たちの製品ではスピードが重要です。物事が速く起こらない場合、ユーザーは製品が良くないと思います。ですから、これらすべてを書いた後、作業を進めて、パフォーマンスの面で同等であることを確認する必要があります。これはWebにおいて大きな問題です。サイトが遅くなると、人々は同じニーズを満たすためにすぐに別の製品に目を向けます。遅いと壊れたの違いを見分けるのは本当に難しいからです。この種の作業には通常Z日かかります（速度を上げるためにDBの変更を最適化し、速度を上げるためにコードをリファクタリングして最適化します）
半日未満の見積もりは避けます。彼らは、あなたが話していることを知っていることを、ある程度、信頼しなければならないでしょう。そして、彼らが本当にそれが2時間だけだと思っているなら、あなたに2時間一緒に座ってもらい、SW開発者の生活の中で2時間がどのように見えるかを正確に説明します-そして、コーディング101クラスをしてください約2時間、問題の解決を開始するために考慮すべきすべてを正確に示すため。
最も重要なことは次のとおりです。
- 顧客の認識と製品の使用法について最も多く話して、あなたは彼らの言語（$$の言語）を話す途中に来ています。重要なのは、コードがお粗末な方法でハッキングされると、最終的にはビジネスを失うことになります-そうでなければこの機能について、その後のいくつかの機能について、開発の慣行が不十分なためにコードを拡張できなくなった場合。
- 一連のイベントを開始します。次の非技術的な質問は、「あなたよりも多くの開発者がいる場合、これはより早く起こりますか？もしそうなら、これを行うのに40時間かかる場合、40人が今日の午後にそれを行うことができますか？」もちろん、答えは「NO！あなたはあなたの心の外にいますか？」です。しかし、それは最良のものではありません。最善の方法は、論理的な一連の手順があることです。事物Bは、事物Aが配置されるまで実行できません（コードを記述していない場合、実際に最適化またはテストすることはできません...）。事AとA 'は一緒に行うことができるので、もし彼らが向こうの賢い人を救うことができれば、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時間の作業になります。
これを顧客に見せて、「これらは、それぞれのコストで実行する必要があることです」と言うことができます。時間ISコストであり、経営陣がコストを理解しているため、「コスト」という言葉を使用します。最後に2つの最適化タスクをドロップする可能性があることを説明しますが、マイナスの影響があります。道路、そしてそれらは総推定値のわずか15％です。
また、1日の時間を現実的に説明するようにしてください。たとえば、テクニカルサポートやデータベースのメンテナンスなどが必要な場合は、それを見積もりに含めます。 「まあ、1日7.5時間のコーディングができる」とは言わないでください。おそらく5か6に近いでしょう。
次に、最も重要なこととして、進捗状況を追跡します。あなたがコーディングの1日あたり5時間を行うことができると言います。その後、月曜日に最初の2つのタスク（私の例では）をノックオフし、3番目のタスクを終了し、4番目のタスクを火曜日に開始する、などのようにできるはずです。このことを示すチェックリストを作成して、水曜日に彼らが来たときにそれらを示し、「金曜日の終わりまでにまだどうするつもりですか」と言うことができるようにします。
私の講演のスライドをご覧ください 危機の防止：効果的なプロジェクトの見積もりと追跡 数年前にOSCONで提出しました。スライド21の「今週の計画」をご覧ください。 サンプル速度チャート もあります。
彼らに尋ねる：
どうしますかどのモジュールを変更しますか？コードは何行ですか？セキュリティへの影響は何ですか？データベーススキーマに変更はありますか？ DBに変更を加えた場合、影響を受けるファイルの数はいくつですか？最後のフォームを追加するのにどれくらい時間がかかりましたか？フォームを追加するための平均（算術平均）は何ですか？一番長かったのは？私はそれが最長よりも1分かかると推定します。最後のN個のフォームを追加するのにかかった時間がわからない場合、この見積もりは1桁の精度でのみ保証されます。