web-dev-qa-db-ja.com

他人のコードを変更するコストの見積もり

私はWeb開発に比較的慣れておらず、まだ多くの大規模プロジェクトの見積もりを提供する必要はありませんでした(私の最後の大規模プロジェクトは、厳密な期限や予算なしで1時間ごとに支払われました)。

クライアントは、Webサイト(php/mysqlバックエンド)の別の開発者コードに無数の変更を提供するためのコストと時間の見積もりを提供するように私に求めています。

誰かがこれを分析して推定する方法についてアドバイスやリンクを提供できますか?コードはひどいものであり(ウェブサイトはもともと何年も前にインドにアウトソーシングされていました)、突然ハードルにぶつかって見積もりを水から吹き飛ばすかどうかを知るのは難しいです。

8
nmford

最初から値段をつけてはいけないと思います。プロジェクトについて誰かがあなたに話しかけたら、クライアントが何を望んでいるのか、それがどれだけの費用がかかるのかを理解するのに十分な仕事を無料ですべきです。それ以上でもそれ以下でもありません。

非常に簡潔な提案を彼らに与えますが、彼らが何を望んでいて、何を提供するかを説明する何かを彼らに与えます。必要に応じて範囲を指定することもできます。これは「誠意のある見積もり」であると言うこともできますが、最終的な金額は費やした時間に基づいていると言えます。

フリーランサーとしての私の経験から、これを行うには3つの主なステップがあります。

  1. 仕事を始めるために50%の頭金を要求する

  2. ファイルを渡す前に最終的な支払いを要求する

  3. 進行中の作業または時間の経過とともにポップアップする可能性のある作業のために時間のブロックを要求します

幸運を!

4
appoll

あなたは関連技術に不慣れであり、作業する必要がある既存の低品質のコードベースに慣れていないため、見積もりは双方向である程度異なる可能性があります。しかし、後者の理由についてクライアントに知らせてください:-P

最初に、クライアントが要求した無数の変更/機能をリストします。要件ごとに、コードのレビューを少し行い、それを実装してテストする方法について調査します。見積もりを出す前に、この時間を返品せずに投資する必要があります。

次に、推定用に3つの列を作成します-最良の場合(25%の確率)、平均の場合(50%)、最悪の場合(75%)。最初の段落で述べた2つの理由から、最悪の場合の見積もりを選択できます。その後、20%のバッファ時間を追加することもできます。たとえば、特定の要件の場合、ベストケースの見積もりは2日、平均ケースは4日、ワーストケースは5日です。 20%のバッファー時間を追加すると、推定は6日になります。

第三に、推定の固定点ではなく、範囲を指定します。上記の例では、見積もりが4〜6日であることをクライアントに伝えることができます。クライアントは、変更のリスト全体の見積もりを要求する場合があります。その場合、すべての要件の範囲の最小値と最大値を合計できます。次に、5〜6.5か月などの範囲の最終見積もりを提供します。これには次の利点があります。ある要件の見積もりを超える可能性がありますが、別の要件を早期に完了する可能性があります。合計すると、それらは互いに相殺され、最終的な見積もりは保留されます。

第4に、各ユーザー要件を完了して段階的に提供するときに、各要件の以前の見積もりを確認します。これは継続的なプロセスであり、プロジェクトを進めて経験が増えるにつれて、見積もりを調整/調整する必要があります。洗練された見積もりと最初の見積もりの​​違いが手に負えないことがわかった場合は、すぐにクライアントの側に座って問題について話し合ってください。

私はスティーブマコネルの本「ソフトウェア推定:ブラックアートの謎を解く」からこれらのことを学びました。私は彼に感謝しています。

時給を尋ねます。請求する前に、多くの時間を費やさないでください。

1
ddyer

アジャイルに行こう!特にベルトの下での経験が少ない場合は、束全体を推定しないでください。

  • クライアントと話して、実装/配信する必要があるものを確認します。
  • すべての機能/作業単位について、ユーザーストーリー(非技術的な部分、適切な説明を書く)を作成し、それを1つ以上のサブタスク(技術的な部分)に分割します
  • すべてのユーザーストーリーを推定する

その定義による推定は常に間違っていることを忘れないでください、そうでなければそれは数と呼ばれるでしょう!クライアントがこれも理解することは非常に重要です!

増分配信を行う必要があります。ユーザーストーリーに優先順位を付け、最初のイテレーションで配信するストーリーを選択するようにクライアントに伝えます。各反復は2週間以内で、3週間以内である必要があります。ユーザーストーリーが終了したら(すべてのサブタスクが閉じられている)、クライアントに通知し、次のユーザーストーリーで作業しているときに確認するように依頼します。

事前に請求する必要はありません。各反復後に請求できます。

幸せなコーディング!

1
šljaker

同様の業界がどのようにそれを行っているかに注目してください。建築家は、最初に物件を見ない限り、ガレージの拡張について正確な見積もりを出すことはできません。

あなたの最初の時間のために彼らに調査料金を請求してください。コードは、現在の状況を詳しく調べないと、正確な見積もりを出すことができない状態であることを説明します。同じ作業をしなくて済むように、信頼の印として、必要に応じて別の開発者に提供できるドキュメントを、最後に必ず入手してください。

そして、実際の開発作業を取得することが重要である場合は、実際の開発作業のために来た場合、最終的な請求書の50%または100%を請求することを伝えます。あなたは失うことはできません、そして人々は無料で何かを手に入れるのが好きです。

0
pdr

見積もり作業時間に基づいて合計を見積もることができ、仮定と、必要な追加時間が追加されることを明確にします。このように、あなたが(ありそうもない)下に行くならば、あなたは前に出てきます。

既存のコードの品質がクライアントに明確であることを確認してください。それらが合理的である場合、それらは柔軟性に適応する必要があります。そうでない場合は、立ち去る準備をしてください。

私が始めたとき、私はこの状況にありました、そして、残念ながら、StackExchangeはその時存在しませんでした。私は固定価格を見積もり、2か月で取引を保釈しなければなりませんでした。配達できなかったので、お金を失い、橋を燃やしました。

0
Robin