上司は私の時間の見積もりを信じていません...アドバイス/バックアップ？
私は新興ソフトウェア会社で働いています-3人の開発者、CEOを含む15人未満の従業員。私たちは、Windows Mobile、.NET CF、およびハンドヘルドアプリケーションから収集した情報を当社のWebサイトとの間でやり取りすることのみを扱っています。私のディレクターと私はまだ始まっていない緊急のプロジェクトについて話し合ったところですが、もし私たちが非常に強力で影響力のある見込みのあるクライアントの納期に間に合わなければならないとしたら、それはまもなく始まるでしょう。
彼は次のように私にプロジェクトを説明し続けました：
- 新しいプロジェクトは主に、クライアントが1回のセッションで複数の土壌サンプルを実行できるようにする.NET CFアプリで構成されます。
- ユーザーがサンプリングしている領域は、適切なサイズと縮尺の地図に表示する必要があります。
- マップは、ユーザーが設定したサイズ（エーカー単位）のグリッドの正方形に動的に分割する必要があります。
- 各グリッドスクエアで、ユーザーはノートを取り、オンボードレシーバーからリアルタイムGPSを介して個々のポイントにマークを付けることができます。
- さらに、現在の位置を与えられたグリッドの四角形をユーザーに示すのに役立つ機能が存在する必要があります。
- 収集されたすべての情報は、お客様のハンドヘルドデバイス（弊社が提供するデバイス）でいつでも簡単に取得して非常にユーザーフレンドリーな方法で読み取る必要があります。
- 収集されたすべての情報は、ActiveSync、ワイヤレス、または所有物を通じて、ハンドヘルドデバイスと同様のインターフェイスで表示/編集できるWebサイトに簡単に送信できます。
その説明を念頭に置いて、（かなり迅速にではありますが）考え直しました。現在のスタッフの規模、限られた予算、限られたリソースでは、このような作業には約9〜18か月かかると予測しました。私がレフトフィールドでオフになっている場合、私を許してください、私は最近のCSの卒業生であり、「現実の」世界にはかなり新しいです。しかし、プロジェクトは現在、設計責任者の頭の中でしか実現されておらず、設計ドキュメントや仕様はありません。ここで私の質問は、私は本当にどれくらい離れているのですか？繰り返しになりますが、私のディレクター（ソフトウェアやITに関する知識はまったくありませんが、土壌のサンプリングに関する限り専門家です）は、プロジェクトの期間を約3か月にしました。
現在、GPSとGISの残りのニーズに対応するためにサポートされていないSDKを使用しており、ESRI製品は範囲外にあることを覚えておいてください。私たちの他のアプリの現在の機能は足を踏み出し、地図上にエリア、ポリライン、プロットポイントを描画するための機能をすでに備えています。
私はここで混乱/恐れているだけで、完全に間違っているのか、それとも私が正しいが自信がないのかと思っています。あらゆるアドバイスをいただければ幸いです。ありがとう！
これに逆向きにアプローチしたい場合があります。
現実的な期限を確認します（たとえば、5〜6か月で納品しても大丈夫ですか？）。この例のすべての＃は、この＃に多少関係しています。
その期限に基づいて達成する必要があるタスクのマイルストーンを設定します。例えば。要件の収集およびSDK /ハードウェアなどのスキル/経験の構築に1か月...アクティブな開発に2か月。テストのための2か月。これらすべての複雑さに起因する予期しないがらくたのための1か月。
これは最初のパスに適した細分性ですが、次に、サブタスクを使用して、計画まで2〜3日の細分性を持つものに細かく調整する必要があります。最初の月にいくつかの初期コーディングタスクを割り当てる必要があります。
次に、マイルストーンが欠落していることがわかった場合は要件または機能セットを選択します。 3か月が経過するかなり前に、コーディングのペースと見積もりの正確さを判断することができるため、前に挙げたこの「コーディング作業を最初に行う」必要があることに注意してください。
基本的に、私はこれを（通常のプロジェクト管理アプローチとは多少逆に）投稿で強調したように見える「MUST DELIVER BY」の観点から実行しています。例えば。厳しい期限までに配達しないことはオプションではありません。
あなたは混乱し恐れているのは当然です。始める前に、別の仕事を見つけるオプションが常にあることを忘れないでください。とは言ったが：
あなたのボスが納期を早めたいという熱意は、単にビジネスの必要性を反映しているだけです。彼が来年初めに製品を顧客に約束できない場合、彼はあなたが契約に勝たないか、または販売をするか、または何でもないことを知っています。その状況の現実もあなたに関係します-あなたの雇用主が新しいビジネスを勝ち取らなければ、とにかくあなたが新しい仕事を見つける必要があるのはそう長くはかかりません。したがって、最初のレッスンは、あなたの上司が実際の必要性を表現していること、そしてそれはyourの必要性と彼の必要性です。
この状況でのすべてのプロジェクトは次のようになります。優勝したサプライヤは、最もクレイジーなタイムスケールを受け入れ、人員配置の見積もりを最も低くするサプライヤです。 3か月後、顧客が光沢のある新しいソフトウェアがシュリンクラップされた箱で配送されることを期待している場合、ベンダー運が良ければは言うことができます。
「まあ、私たちはいくつかの問題に遭遇したので準備ができていませんが、ここにあなたが要求したものの50％を実行するものがあります。あと数か月で！」
50％の機能で顧客が次の3か月間足を踏み入れるのに十分である場合、おそらく部分的なソリューションについてスタッフをトレーニングすると、おそらく訴訟をしばらく控えるでしょう。その後、コアを50％修正し、さらに30％の新機能を追加するバージョンを提供できる場合、それらは必要なものを取得する方法の80％です。はい、あなたはすでに3か月遅れていますが、彼らが別のベンダーに切り替えた場合、何かを得るまでに少なくとも6か月かかります。あと3か月でプロジェクトの最後の20％を磨くことができますか？...
...等々。
これが実際に起こることです!!
上司がそれを認めない場合、彼はばかであるか、または（可能性が高い）顧客と定期的に連絡を取り、契約に署名するように説得するために必要な非現実的な楽観的な気持ちを維持する必要があります。
楽観的になる余裕はありません。プロジェクトが段階的に提供されるように計画します。今すぐ特定を開始（）最初の3か月のお客様にとって、機能の50％が重要です。 neverが提供される機能の10％を鉛筆で書き始めます。このプロセスに顧客をできる限り関与させる-これは顧客の期待を管理するのに役立ち、現実が希望や夢と完全に一致しなくても完全にショックを受けることはありません。
そして幸運！
現在は使用されていませんが、ここで説明するように、見積もりにExcelを使用するのが好きです。
http://www.joelonsoftware.com/articles/fog0000000245.html
あなたはそれぞれの主要なタスクを取り、あなたが見積もりを出すことができるまでそれを分解し、次にそれを見積もります。これを行うことで、アプリケーションを設計することを強制され、関係者が気付かなかった多くの部分が関係している可能性があるため、関係者は関係者が何を関係しているかを知ることができます。
次に、実際にかかった時間を追跡し、元の見積もりがずれている理由を確認できます。
では、最初のポイントとして、土壌サンプルはどのように収集されますか？それらはデータベースまたはxmlファイルに保存されますか？次に、UIの動作を設計し、見積もりを行うことができます。多言語サポートが必要な場合は、別のサブタスクとしてそれを用意し、さらに数時間をかけてください。
最初のスタブは数回手直しする必要があるかもしれませんが、これを約1〜2日で行うことができ、どのくらいの時間がかかるかについて大まかなアイデアを得て、データを表示できます。
SDKがサポートされていない、またはトレーニングが不足しているために時間がかかりすぎるタスクがある場合、開発者が開発するパーツを開発するために、そのパーツが必要なときに、より良いSDKを入手するか、請負業者を雇うことを決定できます。できません。
しかし、このようにして彼らは彼らの予算とタイムラインを決定する方法を彼らに与えます。
プロジェクトをできるだけ多くの詳細なタスクに分解します。
次に、各タスクを個別に見積もります。それらを合計し、時間予算を与えます（通常、man.month単位= 1人が1か月で達成できる作業量）。見積もりには、文書化、統合、およびテストを含めます。また、休日、他のプロジェクトのサポートなどをカバーするためのバッファを考慮に入れます。
最後に、合計見積もりをリソース数で割ると、まともなETA（到着予定時刻）になります。
結果を同僚と比較し、必要に応じて平均/再評価できます。
私は一年でそれを目撃するでしょう。
位置認識アプリケーションは最先端の開発です。そのエッジに立つことのすべてのリスクがここに当てはまります。
少なくとも2つの異なるアプリケーション（おそらく3つ）と、いくつかのバックグラウンドジョブでデータをクリーンアップし、追加の分析とレポートを実行しています。
プロトタイプを開発するのに1か月かかるでしょう。ライブハードウェアが望ましいが、少なくともシミュレーターが望ましい。テクノロジーに関する多くの決定を行う必要があります。
プロトタイプが完成したら、反復を開始して機能と隔週のデモを開発できます。信頼できる見積もりを出すまでに数か月かかるでしょう。
上司が持っているのはアイデアです。彼が必要とするものは、プロジェクトの完全な分析です。解決しようとしている問題は何か、アプリケーションの機能セットは何か。あなた（および他の開発者）は本当に彼と一緒に座って、greatの長さで、彼が念頭に置いていることについて話し合う必要があります。経験則としては、キーボード時間の1時間ごとに、少なくとも10時間のディスカッションが先行する必要があります。マネージャーはそのようなものです-彼らは自分のアイデアについて2分の簡単な説明をしてから、正確な見積もりをすぐに求めます-それも可能です（NOT！）。
元の投稿の2番目のコメントが示すように、プロジェクトの最初から最後まで完全なシステム分析を実行する必要があります。ボスがあなたにできるようにそれをできるだけ詳細にします-そしてPush深い詳細レベルのために-そしてピースを配置し、それらに見積もりを割り当てます。合計に少なくとも1.5の「スコッティファクター」を追加すると、理想的な状況でどれだけ時間がかかるかがおおまかにわかります。
常に機能のクリープや要件の変更によって長時間の負担が加わらなくても、予測できないことはあります。
ここで重要なのは詳細です。上司は全体像を考えているが、プロジェクトを作るのは詳細であることを理解する必要があります。そして、詳細がすべての人が見たり、選んだり、再配置したり、修正したりするためにわかりやすいようにレイアウトされていない場合は、noプロジェクトが提供されます。あなたは上司との戦いをする必要があります-マネージャーは絶対にhate詳細-彼らは手を振って「それを大事にする」と言い、奇跡が起こることを期待します。それは「ヒーロー」症候群と呼ばれます-いくつかの貧しい愚か者が介入し、何ヶ月にもわたって16時間を費やし、ほとんど機能しないプロジェクトの粗悪なバージョンを提供し、上司は「参照、実行できます」と言います。
これを当てにして-上司に自由に見せてください-私はこれまで31年以上ソフトウェア設計を行っており、上記のガイドラインで動作しないプロジェクトに出くわしていません。少なくとも1つは成功しました。 ！
おそらくコミュニケーションの誤りがあります。
多分彼は彼の要件が何であるかを誤解しています。多分あなたは彼の要件が何であるかを誤解しています。立場について議論しないでください。自分を正しく証明する代わりに、彼をよりよく理解してください。
このような問題を解決するためにアジャイルが存在します。
説明されている状況は、特にソフトウェア開発の定義と計画段階で非常に一般的であり、その処理方法を学ぶことは非常に重要です。新しいものを作るとき、あいまいであるのはしばしば解決策だけではありませんが、問題のステートメント自体は明確性に欠け、再定義を必要とします。
基本的に、シナリオは次の3つのうち少なくとも1つを意味します。
上司は彼が何を話しているのかを知りませんし、現実的な期待も持ちません。
あなたは何をしているのか、十分に賢くないか、単なる怠惰なのか分からない。
あなたとあなたの上司は、問題が何であるか、解決策が何であるか、またはおそらく両方について、まったく異なる考えを持っています。
最初の2つの影響が実際に不快であるかどうかを確認することは難しくありません。上司が下手な無能な夢想家であると同時に、上司がビジネスの現実に気づいていない怠惰で無能な技術者であるという考えを採用するという立場をとる可能性がある場合、自然に状況から抜け出すのは非常に簡単です。
したがって、良好な関係を維持し、会社を継続させるための作業をある程度進めるのに役立つ唯一の健全な方法は、3番目のオプションのようです。通常、あなたの1人は次のように言います。これらの違いがどこにあるのかを確認し、共通の理解を得ることができました。」.
最終的には、問題の理解と提案された解決策の両方が正しくないことが判明する可能性があります。目標を達成し、売り上げを現金化するための期限に間に合わせる必要があることが判明する場合があります。たった60％のシンプルなソリューションを使用して、バージョン2でそれをさらに80％に拡張します。最初の100％のスコープを尊重し、価値は低くなりますが、簡単に犠牲にできる開発時間を節約する機能を含めるのではなく、.
小規模な新興企業では、誰も防御することができません。新しい仕事を取り入れるのは十分に困難であり、誰もが状況に応じて問題を解決することに非常に機知に富む必要があります。したがって、あなたと上司は、問題を再定式化して現実的な解決策を模索し、プロジェクトについて単一の賢明な方法に同意するまで、同じように固執する必要があります。
見積もりが9〜18か月の場合、24〜36か月近くなります。これは、私が携わったすべてのビジネス環境における開発の性質です。その過程で、必然的に仕様が変更され、スコープがクリープされます。必要な情報とリソースが遅れます。不測の事態が発生します。たぶん、これまでのキャリアの中で取り組んできたすべてのプロジェクトにうんざりしているだけかもしれません。 =）
プロジェクトの説明から、私は3人の開発者が最も理想的な状況下で3か月ですべてを完了することができるとは信じていません。特に、開発中にそれを追加すると、会議、既存の本番アプリのサポート、カスタマーサポート、アドホックレポートなど、他のことに時間の一部が費やされます。
それは、経営陣に提示するために（目に見える）具体的なものを持つことを常に助けます。スプレッドシート（またはMSプロジェクトのエクスポート）をお勧めします。すべてのタスクがこのプロジェクトに含まれ、チャンクに分割されます。合計すると、許容可能な見積もりが得られます。
彼らはあなたのドキュメントを見て、それを見ることができるはずです（ちょっと）、このコンポーネントのプロトタイプを開発するのに1か月、テストに3か月かかる、などです。
また、最良、予想、および最悪のケースの見積もりを提供することも役立ちます。
ここにいる私たちの誰もがあなたより正確な推測をするのに十分な情報を持っているとは思えません。とはいえ、あなたがレフトフィールドにいるとは思わない。すべてが完璧に進んでいるとすれば、チームが3か月でひどい仕事をするかもしれません。考えられるすべての世界で最高の状態であっても、3か月でそれを実現できなかった可能性があります。
見積もりの理由は、監督に尋ねてください。考慮していないものを発見したり、考慮していないものを追加したりできる場合があります。
あなたはあなたの見積もりにこだわっていると彼に言ってください、しかしこのようにそれを説明してみてください。現在、不確実性が非常に高く、推定値は12か月-25％または+ 50％です。状況が明確になると、見積もりが変更され、エラーのマージンが減少します。政治的に役立つ場合は、マージンを拡大して、上司に-75％または+ 150％であることを伝えます。それから3か月ありますが、2.5年もそうです。
あなたが却下された場合、とにかく最善を尽くしてください、そしてそれは何らかの方法で（できればあまり痛くない）学習経験になります。
提案されたアプリはナプキンのアイデアにすぎないため、上司もアプリも完全なアイデアを持っているとは限りません。推定値について議論するのではなく、推定値をテストするためだけに、いくつかのスパイクを実行する必要がありますが、それはオプションですか？
ダスティンが言ったように、これは確かにアジャイルプロセスの教科書の例のように見えます。このプロジェクトのリスクを最小限に抑えるために、毎月程度のバージョンを展開することを選択できます。顧客が製品に満足している場合、それは完璧ですが、開発中にプロジェクトをキャンセルした場合、会社はXか月の作業を失い、18か月すべてを失いました。
その説明を念頭に置いて、（かなり迅速にではありますが）考え直しました。現在のスタッフの規模、限られた予算、限られたリソースでは、このような作業には約9〜18か月かかると予測しました。
そのようなオフカフ推定を与えることは本当に悪い考えです、なぜなら彼らは通常間違っているからです。 The Pragmatic Programmer には、いくつかのヒントがあります。
私はあなたに最も関連があると思いますあなたが見積もりを求められたときに何を言うべきかについての彼らの提案です。 「折り返しご連絡いたします。」要件について考え、実行する必要があることとすでに実行されている可能性があることを正確に理解し、最終的なシステムのモデルを（紙面または頭の中で）構築し、実行する必要がある作業に関連する時間を費やす必要があります。過去に行った同様のプロジェクト、リソースの利用可能性の分析など。
スローダウンし、時間をかけて、勤勉になってください。誰にも絶対的な見積もりを行ったことはありません。
機会があれば、 [〜＃〜] cocomo [〜＃〜] や [〜＃〜] slim [などの推定のパラメトリックな方法も見てください。 〜＃〜] （パトナムモデル）。これらは履歴データベースを使用しますが、適切な基本情報とかなり正確なパラメーターがあれば、通常は適切な推定値が得られます。別のオプションは、チームの他のメンバーに相談して、何らかの形式の Wideband Delphi推定 を実行することです。
私がレフトフィールドでオフになっている場合、私を許してください、私は最近のCSの卒業生であり、「現実の」世界にはかなり新しいです。
見積もりには時間がかかります。見積もりを改善する最良の方法は、すべてのプロジェクトのログを保持することです。ログの開始時に、プロジェクトのサイズ、範囲、および必要な作業に関する見積もりを記録します。プロジェクト全体を通して、何が起こるかを追跡します。最後に、最終的なサイズ、範囲、および作業を記録します。十分な時間と練習をすれば、見積もりをより良くすることができます。
また、コースやリーディングの量はあなたが推定でより良くなるのに役立ちません。 PSPとプローブの方法論について読んだ後、プロセス管理とプロジェクト管理に関する多くのコースを受講しました。ソフトウェア工学の経済学を勉強しました。私も Steve McConnellのソフトウェア推定に関する本 を読みました。私は多くの優れたテクニックと戦略を学びましたが、見積もりを行ってから見積もりを実行し、間違いを犯し、それらから学ぶことほど優れているものはありません。
見積もりには練習が必要なので、こんな大規模なタスクを見積もりさせられていることに驚いています。あなたはおそらくプロジェクトレベルでの作業経験がほとんどないため、自分で見積もることができるかどうかはわかりません。私があなたのマネージャーまたはリーダーである場合、私はあなたに見積もりに関与してもらいますが、プロジェクト全体を見積もりません。
しかし、プロジェクトは現在、設計責任者の頭の中でしか実現されておらず、設計ドキュメントや仕様はありません。
これは問題があります。見積もりは、プロジェクトの理解から直接得られます。見積もりを開始するためにも、何らかの要件、仕様、または最終目標が必要です。また、誰かの頭の中にあるものを推定することもできません。個人的には、すべてが書き留められていない限り、見積もりを行いません。私の見積もりは文書化されたものに対応し、文書の内容が変更された場合、私の見積もりも変更されます。
紙の証跡を持つことも常に良い考えです。それは、適切な人々が常に責任を負うことを保証するのに役立ちます。これは、見積もりからプロジェクトの死後まで、どの決定でもかまいません。
ここで私の質問は、私は本当にどれくらい離れているのですか？繰り返しになりますが、私のディレクター（ソフトウェアやITに関する知識はまったくありませんが、土壌のサンプリングに関する限り専門家です）は、プロジェクトの期間を約3か月にしました。
ソフトウェア開発者として、少なくともソフトウェア開発タスクに関しては、ソフトウェアの経験がない人よりもおそらくあなたはより優れた評価者です。引用を忘れてしまいましたが、バリーベームやワッツハンフリーが言ったと思いますが、エンジニアリングタスクの最高の推定者がエンジニア自身であるということでした。エンジニアリングタスクを計画するとき、エンジニアはすべてのステップで関与する必要があるものです。