進行中のプロジェクトまたは作業のバグ修正に対して開発者に支払う必要がありますか？
私たちはプロジェクトの開発者グループと協力しています。プロジェクトはまだ進行中（完了していない）であり、これらの開発者は、そもそも有効とは記述されていなかったコードのバグの修正に費やした時間を請求してくれます。進行中の作業のバグ修正ではなく、変更/新しいリクエストがあれば料金を支払う必要があることを理解しています。また、割り当てがライブサイトに展開されると、サポート期間が終了した後に発生する可能性があるバグ修正について責任を負う場合があることも理解しています。
問題は、プロジェクトがまだ進行中であるときに、そのような料金が課されることは適切かということです。
欠陥は、ソフトウェア開発プロセスの予想される結果です。時間と材料の契約については、開発者がバグの修正に費やした時間に対して開発者があなたに請求することを期待します。これは開発者の仕事の通常の部分です。固定入札契約の場合、開発者は欠陥の費用を負担し、その固定費用でシステムのバグを無料で（または契約状態と同じくらい）提供することを期待します。それらを請負業者または従業員としてより直接的に採用している状況の場合、それは同じ時間と材料の推論に該当します。それは仕事の一部であるため、彼らに支払われる必要があります。
率直に言って、この質問は、ソフトウェア開発プロセスについて途方もないレベルの無知を意味します。会社のWebサイトをプロファイルから外し（特に、Webサイトが存在しないため）、ソフトウェア開発プロジェクトの管理に関する本を読むのが賢明な場合があります。
他の人が述べたように、特定の質問に対処するために、バグのないコードとバグの修正が必要な場合は、成果物の受け入れテストを指定し、開発者と固定入札契約を交渉する必要があります。明確に定義された受け入れテストのないプロジェクトに時間をかけるために人々を雇う場合、あなたは偶然に彼らの結果ではなく彼らの時間に対して彼らに支払うことに同意しました。ですから、バグを修正するために開発者にお金を払う必要があります。また、バグを書くために彼らに支払いました。また、プロジェクトに受け入れテストがない場合、誤ってプロジェクトを完了するか、プロジェクトの資金がなくなるか、クライアントがプロジェクトをキャンセルするまで、バグの作成と修正に費用を支払うことになります。どれも組織に反映されません。
契約の条件は何ですか？ユーザー受け入れテストフェーズを指定しましたか？ UATの清算を条件に支払いを行いましたか？
モジュール/ユニット/組織で受け入れられているものはありますか？受信と受信には違いがあることに注意してください。受信済みとは、コードを受け取っており、ユーザー受け入れテストに入っていることを意味します。受理済みとは、UATに合格したことを意味します。
UATの後にバグが見つかった場合、通常は修正の費用を支払う義務があります。 UAT中に検出された場合は、まだ有効なコードを受け取っていないため、支払いマイルストーンは満たされていません。
契約になんらかの承諾条項を盛り込まなかった場合は、バグを修正するために料金を支払う義務があります。
私はここで編集しています-期待どおりに機能するコードの受信を強制する手段がない場合は、ここで契約を破棄します。外部の会社は、契約の条件にあるものを提供することしかできません。契約で「機能」が何であるかが指定されていない場合は、最終的なコンテンツに何が提供されるかについては、彼らの責任のほとんどです。
追加編集＃1：開発作業の「時間と材料」契約を結んでいる場合、新しい関数をコーディングするために支払うことと、新しい関数のバグを修正するために支払うこととの間に機能的な違いはありません。このように考えてください：彼らがあなたに関数のプレビューを提供したからといって、関数が実際に提供されたという意味ではありません。そのため、関数プレビューに欠陥を見つけた可能性がありますが、それは、それらがまだ開発を完了していないことを意味します。バグ修正として表示されるのは、機能の継続的な改良です。
追加編集＃2：固定価格契約からプロジェクトログ/時間単位（別名T＆M）アプローチに正式に移行したかどうかを確認することをお勧めします。一般的に、私はneverを使用して、新しい開発に関してT＆M契約を受け入れるようにクライアントにアドバイスしました。 T＆M契約を許容可能なリスクにするには、変数が多すぎます。
固定価格の世界では、契約で指定された機能の提供を妨げるあらゆる問題を修正する義務があります。したがって、バグ修正はあなたのものではなく、彼らのダイムで行われるでしょう。
T＆Mの世界では、バグ修正などはありません。それは、その時点で生成されたコードの単なる追加の拡張です。
（社説＃2）物事が悪い場合は、悪い契約を捨てることを恐れないでください。脱出ペナルティを支払い、それで終わります。良いお金が悪い後に投げられる状況に入るのは非常に簡単です。悪い開発プロセスを止める。 RFPを作り直し、実際に必要なものを指定します。新しい契約を結ぶ。これは、実際に必要なものを確実に入手するための最良の方法であり、悪い契約を処理する際の多くの頭痛を軽減します。
（私は弁護士ではありません）
それは次第です-あなたは彼らとの契約に何を書いていますか？彼らが給与のある従業員の場合、あなたは何があっても彼らに支払う責任があります。
他の人が答えたように：あなたはあなたの契約があなたが支払うことに同意したと言うそれが何であれあなたは支払うべきです。
現在、契約に問題があり、乗車中と感じているようです。 開発チームに不満がある場合は、問題を解決して機能させるために、明確かつ友好的な方法で開発者にこれを伝える責任があります。続行できます。チームや提供する作業に特定の問題があるようではなく、請求に問題があるようです。友好的な電話や対面会議を行い、それについて質問します。私の経験では、これでほとんどの問題が非常にうまく解決されます。
バグの性質によって異なる場合があります。バグが他の機能での作業を妨げている場合（たとえば、スクリーン1がoldバグが原因でレンダリングに失敗した場合、2つの新しいボタンを追加するにはどうすればよいですか？）バグをコードするのではなく、バグを修正して新しい作業を適切に行わせる。将来的には、最初の契約でこのような状況をより明確に定義する方がよいでしょう。
スペックが明確に定義されていなかったか、彼らが彼らの推定値（あなたが支払う必要はないはず）を吹き飛ばしたかのどちらかだと思います。
見積もりを求めるときは、提供する機能を明確に定義し、それら（開発ショップ）に、製品の動作方法と動作確認のためのテスト方法を明確に定義する必要があります。彼らの仕事は正確に見積もり、納品することです。
製品が期待どおりに動作しない場合（提供されたテストに合格しない場合（つまり、ユーザーがユーザー名とパスワードを入力し、ログインをクリックすると、ユーザーはホームページにリダイレクトされます）、それはあなたの責任ではありません。
ただし、ユーザーが誤ったuname/pwordを入力した場合にどうなるかを定義しておらず、ページがエラーをスローした場合は、「ユーザー名とパスワードを検証する必要があるとは言わなかった」と言う余地があるかもしれません。それぞれの「テストシナリオ」が何を期待するかを書き留めてください。
- あなたが欲しいものを明確に定義する
- 意図したとおりに機能することを確認する方法を明確に定義する
- 納品時に、合意したテストを使用して、意図したとおりに機能することを確認します
事前に十分な情報を提供しないと、結果的にコストがかかります。
プログラマが完璧なコードを書くと想定する方法はありません。
- 通常のソフトウェアプロジェクトのバグの修正には、使用時間全体の少なくとも1/3がかかります。維持段階では、1/3以上。
- バグの修正に多くの時間と費用を費やした後でも、NASAはソフトウェアの問題のためにスペースシャトルを失いました。同じ品質になる前にお金が足りなくなると思います。
- バグを修正する責任を外部のベンダーにアウトソーシングすることは、プロジェクトを失敗させる良い方法です。