私はウェブ開発に比較的慣れていないため、まだ多くの大規模プロジェクトの見積もりを出す必要はありませんでした（私の最後の大規模プロジェクトは、厳密な期限や予算なしで1時間単位で支払われました）。
クライアントから、Webサイト（php / mysqlバックエンド）の別の開発者コードに無数の変更を提供するためのコストと時間の見積もりを提供するように求められています。
これを分析して推定する方法について誰かがアドバイスやリンクを提供できますか？コードは恐ろしいもので（ウェブサイトは何年も前に元々はインドにアウトソーシングされていました）、突然ハードルにぶつかり、私の見積もりを水から吹き飛ばしてしまうかどうかはわかりません。
回答:
最初から値段をつけてはいけないと思います。プロジェクトについて誰かがあなたに話しかけたら、クライアントが何を望んでいるのか、それがどれだけの費用がかかるのかを理解するのに十分な仕事を無料ですべきです。それ以上でも以下でもない。
非常に簡潔な提案を彼らに与えますが、彼らが何を望んでいて何を提供するかを説明する何かを彼らに与えます。必要に応じて範囲を指定することもできます。これは「誠意のある見積もり」であると言うこともできますが、最終的な金額は費やした時間に基づいていると言えます。
フリーランサーとしての私の経験から、これを行うには3つの主なステップがあります。
仕事を始めるために50％の頭金を要求する
ファイルを引き渡す前に最終的な支払いを求めます
進行中の作業、またはおそらく時間の経過とともにポップアップする作業について、時間のブロックを求めます
幸運を！
ask for 50% downpayment to begin work...えっと、それは少し高いのではないですか？私はむしろ20％と言うだろう
アジャイルに行こう！特にベルトの下での経験が少ない場合は、全体を推定しないでください。
その定義による推定は常に間違っていることを忘れないでください、そうでなければそれは数と呼ばれるでしょう！クライアントもこれを理解することは非常に重要です！
増分配信を行う必要があります。ユーザーストーリーに優先順位を付け、最初の反復で配信するストーリーを選択するようにクライアントに伝えます。各イテレーションは2週間以下、3週間以下にする必要があります。ユーザーストーリーが終了したら（そのサブタスクはすべて閉じられます）、クライアントに通知し、次のユーザーストーリーの作業中に確認するよう依頼します。
事前に充電する必要はありません。繰り返しごとに充電できます。
幸せなコーディング！
あなたは関連技術に不慣れであり、作業する必要がある既存の低品質のコードベースに慣れていないため、見積もりは双方向である程度異なる可能性があります。しかし、後者の理由についてクライアントに知らせてください:-P
最初に、クライアントが要求した無数の変更/機能をリストします。要件ごとに、コードのレビューを少し行い、それを実装してテストする方法について調査します。見積もりを出す前に、この時間を無駄なく投資する必要があります。
次に、推定用に3つの列を作成します-最良の場合（25％の確率）、平均の場合（50％）、最悪の場合（75％）。最初の段落で述べた2つの理由により、最悪の場合の見積もりを選択できます。その後、20％のバッファ時間を追加することもできます。たとえば、特定の要件の場合、最良のケースの推定は2日、平均のケースは4日、最悪のケースは5日です。20％のバッファー時間を追加すると、推定は6日になります。
3番目に、推定の固定点ではなく、範囲を指定しないでください。上記の例では、見積もりが4〜6日であることをクライアントに通知できます。クライアントは、変更のリスト全体の見積もりを要求する場合があります。その場合、すべての要件の範囲の最小値と最大値を合計できます。次に、5〜6.5か月の範囲で最終的な見積もりを提供します。これには次の利点があります。1つの要件の見積もりを超える可能性がありますが、別の要件を早期に完了する可能性があります。合計すると、それらは互いに相殺され、最終的な見積もりは保留されます。
4番目に、各ユーザーの要件を完了して段階的に提供するときに、各要件の以前の見積もりを確認します。これは継続的なプロセスであり、プロジェクトを進めて経験が増えるにつれて、見積もりを調整/調整する必要があります。洗練された見積もりと最初の見積もりの違いが手に負えないことがわかった場合は、すぐにクライアントと一緒に問題について話し合います。
これらのことは、Steve McConnellの著書「Software Estimation：Demystifying the Black Art」から学びました。私は彼に感謝しています。
推定作業時間に基づいて合計を見積もり、想定を明確にし、必要な時間がさらに追加されるという事実を明確にすることができます。このようにすると、（おそらくない）下に行くと、先に出てきます。
既存のコードの品質がクライアントに明確であることを確認してください。それらが妥当である場合は、柔軟性に対応する必要があります。そうでない場合は、立ち去る準備をしてください。
私が始めたとき、私はこの状況にありましたが、残念ながら当時はStack Exchangeは存在しませんでした。私は固定価格を引用し、2か月で取り引きを保釈しなければなりませんでした。配達できなかったので、私はお金を失い、橋を焼きました。
同様の業界がそれをどのように行うかに注目してください。建築家は、最初に物件を見ない限り、ガレージの拡張について正確な見積もりを出すことはできません。
初回は調査費用を請求してください。コードは、現在の状況を詳しく調べないと、正確な見積もりを出すことができない状態であることを説明します。信念の印として、彼らが最後に何かを得ることを確認してください。彼らが同じ仕事をしなければならないことを保存するために、彼らが選択した場合に彼らが別の開発者に提供できるいくつかのドキュメントです。
そして、実際の開発作業を取得することが重要である場合は、実際の開発作業のために来た場合、最終的な請求書から50％または100％も請求することを伝えます。あなたは失うことはできません、そして人々はそれを無料で何かを得たいと思っています。