9

私は、機能の約 75% に特定の要件がない半複雑なソフトウェア ソリューションの時間とコストを見積もっています。クライアントから追加のデータを取得して、可能な限り正確な見積もりを作成したいと考えています。他の製品/テクノロジーとの依存関係が多すぎて定義が不足しているため、開発できなくなる可能性がある部分がまだあります。また、この見積もりを作成するために非常にタイトなスケジュールがあります。

このプロジェクトには他の候補もいます。クライアントは価格+期間（そしておそらく機能も）を期待しており、誰もがオフになることを知っています. それが不可能であることはわかっていますが、それをマーケティング担当者に伝えてください。もう 1 つの問題は、私がクライアントと直接ではなく仲介者と話していることです。私は仲買人だけに信頼を寄せることができますが、決定的なクライアントには信頼できません。これはまったく別の問題です。

このプロジェクトでチームを犠牲にしないために、価格プラン/契約にどの免責事項/情報を入れることができるので、プロジェクトが (コスト/時間/機能の点で) 遅れ始めた場合、何らかの支払いでカバーされます. もちろん、時間に応じてスプリントまたはリリースによって支払われることを望んでいますが、クライアントがこれを納得できるとは思えません。締め切りまでにこの製品を完成させ、素晴らしい製品を作成できると確信していますが、どうすればクライアントに私を信じてもらうことができますか?

質問

このプロジェクトを取得し、同時にデスマーチの状況を回避するにはどうすればよいですか?

どんな提案でも大歓迎です!

編集：結果

最終的に、私たち (私と私の同僚) は、製品を評価するのに少なくとも 1 週間は必要であるとクライアントに確信させました。だから私たちはやった。また、未解決の要件に関する質問を明確にするために、クライアントとの数時間にわたる会議のスロットをプッシュ (および取得) しました。だから私たちはやった。最初の見積もり草案を作成した後に会議が行われたため、完全に誤解されているか、見積もりが曖昧すぎる詳細を指摘するすべての質問があると確信していました. 8 か月のフルタイムの仕事と妥当な賃金を意味するので、プロジェクトが成功することを願っています。約1週間半でわかる。

もちろん、私たちがこの製品を提供する方法は、実際に彼らが望んでいた製品で、彼らが望む場所に正確に到達することも指摘しました. また、価格と時間のみにコミットし、機能性についてはコミットしていません。これは変更される可能性があるためです。私たちは十分に良い印象を与えたと思います。

4

6 に答える 6

13

この経済環境では、多くの企業がわずかな仕事を求めて競争しています。誰かが彼らに非常に甘い入札をするに違いありません。

  1. お届けできず、
  2. でチームを倒す、または
  3. 両方。

合意された価格で納品できない場合、何かを納品して支払いを受けるために、品質を落とし始めます。

あなたの課題は、その事実を見込み客に専門的な方法で提示し、合理的なコストで提供するために一生懸命働くだけでなく、彼らが必要とするものを正確に提供することを彼らに納得させることです. あなたがより詳細に戻ってくるという事実と、あなたがプロジェクトにアプローチする方法 (アジャイルですが、ビジネス上の利点を確実に説明してください) は、彼らが本当に必要としているものを最終的に確実に手に入れるのに役立ちます。

彼らは、必要なソフトウェアを可能な限り低価格で提供したいと考えていることを忘れないでください。

あなたが彼らのニーズに正確に応えてくれること、そしてあなたの価格が妥当であることを彼らに納得させてください.

于 2009-09-02T22:17:55.450 に答える
11

固定価格の開発サービスの世界へようこそ :-)

このプロジェクトに勝利し、同時にデスマーチの状況を回避するためのテクニック:

  • プロジェクトを過小評価しないでください。プロジェクトにかかると思われるものに入札し、うまくいかない可能性があるものに何パーセントかを追加します。
  • 詳細の 75% が欠けている場合、プロジェクトは現在の予想とは大きく異なる可能性があります。定義された作業の概要の中で、いくつかの合理的な詳細な仮定を文書化します。プロジェクトが実際に開始され、詳細が想定と一致しない場合は、変更のコストを交渉する機会があります。その時点で、あなたは自分がどれだけ上回っているか/下回っているかを知り、この見積もりで補おうとするより良い立場にあるかもしれません.
  • SOW (作業明細書) の目標は、プロジェクトについて詳しく知ったときに変更のコストを再交渉する機会が得られるように、十分な詳細を定義することです。これらはできるだけポジティブに書きましょう。プロジェクトを実際に理解している人がSOWを読んだり理解したりする可能性は低いことに注意してください...引用する詳細がほとんど与えられていないという点に基づいています。これは、これがコンサルティング セールスではなく、どちらの当事者も「適切な」ソリューションの構築に真剣に取り組んでいないことを意味します。
  • T&M（タイム・アンド・マテリアル）として契約が取れれば最高です。T&M の目的を実質的に無効にするいくつかの制限がなければ、それを取得できるか、または取得できないとは思えません。あなたの潜在的な顧客は、あなたの能力に関するすべてのリスクを受け入れていると考えています。
  • うまくいけば、あなたは会社でこれを行う最初の人ではありません。歴史的に、プロジェクトがどのように行われてきたか、および典型的な成果率を調べてください。多くのソフトウェア開発グループは、コストよりも大幅に高い時給を請求しています...しかし、彼らの見積もりは実際の時間ではなく、より低くなる傾向があります. 顧客は、実際の見積もりよりも時間/日数について議論することがよくあります。企業は、高い時給を支払うことに慣れている傾向があります。
  • あなたの部門の予想マージン (仕事から得なければならない利益) を計算します。これは、プロジェクトが失敗したときにどれだけの「死の行進」に直面する可能性があるかを理解するのに役立ちます.
  • SOW では、作業を開始する前に、仕様で必要となる詳細レベルを指定します。アジャイルやその他の顧客重視のプロセスは、最適なソリューションを見つけることを目的としたアプローチを採用していますが、固定入札環境でコストを管理するようには設計されていません。要件に対してウォーターフォール アプローチを採用し、アジャイルな方法で構築して、途中で調整できるようにする必要があります。仕様は、SOW と同様に、変更に対して請求する機会を提供します。顧客はこれを好まないでしょうが、要件に関連する負担とリスクは、あなたのチームではなく顧客に課せられます。

これらの交渉を成功させるには、支援的な管理、販売、およびプロジェクト管理チームが必要です。それがなければ、常に「死の行進」を続けることになります。品質、プロセス、テスト、およびその他の項目を無視しても、プロジェクトに十分な時間はありません。

于 2009-09-03T12:25:04.173 に答える
4

あなたが考えるべきだと私が言いたいいくつかのこと：

仮定: 追加できる免責事項はありませんが、要件のギャップを適切な仮定で埋め、文書化する必要があります。重要なことや恐ろしいことは何もありません。スペック/入札のセクションに、あなたが真実であると仮定したことを示す箇条書きのリストがありませんでした (たとえば、ユーザーの詳細は LDAP を使用して取得され、ユーザー管理をカバーする管理画面は作成されません)。 .

これにより、作業の範囲が完全に広がるため、見積もりが明確になりますが、クライアントが大幅に異なるものを持って戻ってきた場合、変更要求を提起してコストを変えることについて話し始めるための公正な根拠があることも意味します. あるいは、交渉中に戻ってきて、この仮定または仮定が真実ではなく、より多くの情報があると言うかもしれません。

範囲外: 仮定の特定のケース - 含めていないものをリストします (たとえば、システム X との統合は存在しません)。繰り返しますが、これにより、後の段階で潜在的に変化するコストについて、完全な範囲と合理的なケースを持つことができます。

仮定と範囲外は、物事が通過して言及されたが実際にはフォローアップされていない場合、または第2フェーズまで待つことができると彼らが言うものに特に適用されます. これらは多くの場合、クライアントがメイン プロジェクトの一部として行われていると信じていることですが、プロジェクト チームはそうではありません。

あなたが定義した仮定と範囲からの完全性と洞察が、最終的なクライアントにも自信を与えるのに役立つことを願っています.

不測の事態: 難しい問題ですが、次の 2 つの方法で不測の事態を追加する必要があります。

(1) 特定のリスクについて。何かがあなたの見積もりよりも長くかかることを意味するかもしれないことについては、それが起こる可能性によって重み付けされたそれをカバーする量を入れてください. これらすべてを合計すると、それがリスクの偶発性になります。

(2) たわごとは偶発的に起こる - IT プロジェクトでは予測できないたわごとが起こります。これをカバーするために 10% から 20% を追加します。

営業担当者とクライアントから不測の事態を隠すかどうかは、あなたの関係次第ですが、それが削除された場合、彼らはそれが何を意味するのかを理解する必要があります (本質的に、あなたはやり過ぎます)。

労力とコストの関係を理解する: 技術者としてのあなたの役割は、入手した情報に基づいて労力を見積もることです。次に、それを仮定、不測の事態のレベルなどとともに、それを金銭的価値に変換できる営業チームに伝える必要があります。それらをオンにして明確にすることは、コストを削減したい場合でも、努力は変わらないということです.

クライアントにコストを書き留める正当な理由はたくさんありますが (関係を構築するため、後で再利用できるものになるためなど)、スコープが変わらない限り、努力は変わらないことを人々は理解する必要があります。同じ - 削減は利益から生じます。

于 2009-09-03T12:55:15.807 に答える
4

編集：

中間業者の状況に対処する。お客様への礼儀として、入札とともにリスクのリストを提出するのが最善の方法だと思います。彼らのプロジェクトの限界について彼らに警告するようなものです。これには前もっての作業が必要ですが、プロジェクトを勝ち取るのに役立つと思います。

あなたには2つの選択肢があります

最善の推測を行い、見積もりを 2 倍または 3 倍にします (競合他社もおそらく同じことをしています)。

このような仕事に入札することはできないことを顧客に説明し、固定見積もりを提供する他のすべての人がおそらく完全に真実ではないことを伝えます.

結局のところ、その仕事でお金を稼ぐことができなければ、それをしようとしても意味がありません。

個人的には、後者の方が好みです。顧客との率直で正直なコミュニケーションは、これまでのビッド トリックよりも先に進みます。

于 2009-09-02T22:15:12.520 に答える
1

私はあなたのためのいくつかのヒントがあるかもしれないブログ記事を持っています:

http://pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html

ここにある他のポスターの1つに良い点があります。仕事を得るために低価格を提供する人が常にいるでしょう. 開発者は後で苦労します (つまり、クライアントを満足させるために多くの無料作業を行わなければなりません)。

一部のクライアントは、なんらかの対価を支払わずに IT プロジェクトを安価に行うことはできないと考える前に、この経験を積む必要があります。

LM

于 2009-09-03T23:15:45.617 に答える
0

リアリズムを求めてください。約束しすぎないようにして、それを強調してください。

多くの顧客は、約束どおりに提供できなかった非現実的な提案者によって焼かれました.

仕様スプリントの必要性を強調します。機能の大当たりではなく、コア機能と提供へのコミットメントに焦点を当てていることを伝えます。コア機能を提供するための主要な開発フェーズを提供します。

アジャイル アプローチの力と安全性を伝えます。良識あるものを見る能力を顧客に与えます。

要するに: 現実的で真剣に見えるように努力してください (競合他社よりも)。最終的に真剣な顧客にとって最も重要なことは、価格ではなく、製品が時間と予算内に届けられるという自信です.

于 2009-09-02T22:35:52.573 に答える