プロジェクトに入札するための最良のアプローチ
基本的には常に同じパターンを好転させるプロジェクトがあります。しかし、私たちが通常行っていることとは絶対に逆のプロジェクトがある場合があります。現在、入札して潜在的な顧客にこの入札を行うことはより困難になっています。より難しいケースでは、時々見えるものがあります 非常に 実行するのが難しく、どれだけの時間がかかるかわからないだけです...また、プロジェクトを取得することは絶対にないことを承知の上で、これに入札する時間をできるだけ少なくしたいと考えています。
だから、私の質問は;
- あなたはあなたの時間を何に基づいていますか？
- 考慮すべき要素は何ですか（基本情報が表示されないため、少し難しいと思います）。
- 役立つツールはありますか？
すべてをまとめるために、それを行うためのより良い方法はありますか？はいの場合、この方法は何ですか？
プロジェクトの入札（私はあなたが話していることだと思います）は常に困難です。以下の手順を実行しようとすると、良い場所になります。
- 要件の完全なセットがあることを確認してください。明らかに、ここではクライアントからの入力が必要であり、これらの要件を承認するためにもクライアントが必要になります。
- 要件が決まったら、可能な限り小さい部分に分解してみてください。これにより、各ピースの実装にかかる時間を簡単に見積もることができます。これらの部分の合計を、開発にかかる時間のベースとして使用します（パディングを自分に与えます）
- クライアントが新しい要件を持って来たら（彼らはそうするでしょう）、次の開発サイクルでそれらに対処しようとします。私は開発に段階的なアプローチを使用するのが好きです。これにより、追加のものを検討する前に、合意した元の機能をクライアントに承認させることができます。
プロジェクトに入札する時間を最小限に抑えることを心配している場合は、プロジェクトが失敗したり、予想よりも時間がかかったりするリスクがあります。入札を失う可能性は十分にありますが、それはおそらく良いことです。私は、クライアントからプロジェクトを取得するよりも、彼らが何を望んでいるのかを教えてくれないプロジェクトを取得したくありません。
要件が複雑またはあいまいであるために問題を解決する方法が正確にわからない場合は特に、入札プロセス中に必要な労力を見積もることは常に困難です。
要件があいまいな場合は、明確でない領域を特定し、質問のリストをクライアントに送信して説明を求めるようにします。
プロジェクトが複雑で、問題を解決する最善の方法が100％わからないことが問題である場合は、最初のx週間をプロジェクトの要件の評価に費やすことに基づいて、プロジェクトに入札する傾向があります。可能な解決策のプロトタイピング。特に仕事が複雑な場合は、クライアントにこの時間の支払いを依頼するのは不合理ではありません。私は、すべての未知数を特定し、ギャップを解決するために必要な時間を見積もり、クライアントにプロセスのその部分の確実な見積もりを提供します。
それに加えて、プロジェクト全体が悲観的な仮定を立てるのにかかる時間を見積もり、クライアントの予算に応じて30％〜100％を追加します。私は彼らにこれを提供します大まかな予想される総努力の見積もりですが、努力は明確で合意された範囲、アーキテクチャ、および実装計画に到達することを条件としていることを明確にします。
特にプロジェクトが複雑で、関連する専門知識がある場合は、ほとんどのクライアントがこの種のアプローチを高く評価すると思います。
固定入札プロジェクトを実行しているように聞こえますが、あなたとあなたの同僚はこれまで一度も行ったことがありません。あなたの状況では、プロジェクトに入札することすらしないことをお勧めします。あなたの会社がコスト見積もりの完全なミスを吸収し（少なくとも100％のオーバーランを考えてください）そして運営を続けるための財政力を持っていないなら、逃げてください。長期間の弁護士が1時間あたり300ドルで互いに怒鳴るのを避けるために契約書を作成するために必要な精度、クライアントが微妙にしないようにするための要件（範囲を制限するため）に必要な詳細ゴールポストを仕上げ、納品の成功を構成するものの詳細、保証の懸念（短いほど良い）は困難です。大規模で経験豊富な企業は、これで常に失敗します。私が固定入札プロジェクトを行うのを見る唯一の理由は、プロジェクトが完了した後に続く複数年のサポート契約のニンジンです。その余分な収入の流れがなければ、リスク/報酬はサプライヤーのために調整されません。統計によると、ソフトウェアプロジェクトの60％が失敗し（または今週の数が何であれ）、固定入札では修正されず、リスクをサプライヤー/開発者に転嫁するだけでも問題は解決しないという理由があります。あなたはまだ考えを変えようとしていて、要件が現実世界のニーズを満たしていないことを見つけます、そして今、誰が変更の費用を負担するのか、そしてあなたが全体を費やすことをいとわないのかどうかについての戦いがありますあなたのクライアントが変更の費用を負担することを確実にするために戦う契約、あなたはこれでお金を失うでしょう。さらに、経験から、固定入札はクライアントにも害を及ぼし、最終的にはビジネスニーズではなく契約の要件を満たすソフトウェアになります。固定入札のITエンゲージメントは、電子メールシステムの実装などに任せてください。ソフトウェアを構築するよりもはるかに予測可能です。
あなたは固定価格の数値を取得する方法を理解することにかなり集中していますが、時間と材料、コストプラスなどの他の契約タイプについて考えることをお勧めします。これらを顧客に喜ばせる方法は、進行状況を確認し、段階的な支払いを行うことができるように、途中で特定のマイルストーンと成果物を提案することです。