理想的な世界では、バグの少ない期限に間に合うことが望ましいです。しかし、より好まれ/受け入れられるあなたの経験から：

1. 期限に間に合いますが、開発者が物事に突入するため、多くのバグがあります
2. 開発者はコードの記述が非常に厳密であるため、バグは少なくなりますが、期限には間に合いません

この質問への答えは、クライアントだけでなくビジネス目標にも大きく依存します。

エンタープライズ：

市場で十分に定着している企業レベルのクライアントと取引している場合、柔軟性が低く、変化に迅速に適応できません。したがって、ほとんどの場合、安定性は絶対的な要件です。研究開発と新しい業種への参入には例外があります。場合によっては、より速く終了します。

これらのタイプのクライアントは一般的に、優れたソフトウェアの開発には時間がかかり、目標を達成するためにあなたと協力することを理解しています。

スタートアップ：

新しいスタートアップの場合、ルールは大きく異なります。スタートアップとして、あなたが構築している製品があなたのマーケティング調査が予測したように本当に必要を満たすかどうかすぐに知る必要があります。スタートアップにとって、プロトタイプをできるだけ早く市場に出すことは、製品が進むべき方向について多くの貴重なフィードバックを集めることができます。

また、マーケットリーダーとしての地位を確立し、競争で飽和状態になる前に新しい業種で貴重な市場シェアを獲得するのに役立ちます。

スタートアップは小さく、柔軟で、変化に迅速に適応できるため、このモデルは彼らにとって最適です。

要約すると、考慮すべき他の要因がありますが、主なアイデアは、すべてのプロジェクトが異なり、品質と市場投入までの目標が異なるということです。ある方法を別の方法よりも選択する機会費用の徹底的な分析を含む効果的なビジネス戦略を決定するのは、経営幹部の責任です。

または... 3.必須ではない機能をカットする

技術的なキャンディーやクライアントが要求するキャンディー機能のために、納期に間に合わず、本質的に大きなバグが発生することがあります。それはKISSとYAGNIの原則が適用されます。

この本の「リワーク」から引用すると、ソフトウェアの必須/コア/エピセンターは、ビジネスが機能するために必要なものです。ホットドッグスタンドがトッピングのないホットドッグスタンドになることができるように、カットできないものはホットドッグ。

再交渉

習得するのが最も難しいことの1つは、クライアントを満足させる方法であり、私の経験では、これはより小さな製品の反復でより簡単に達成できます。

時々、締め切りにより、ソフトウェアが初日から大量の生産レベルで動作することが要求されます。マネージャー/クライアントは、ソフトウェアに実際に必要なものを常に把握しているわけではありません（ほとんどの場合）。そのため、必須ではない機能をカットし、品質を維持してください。最終的には、本番環境がどれほど重要かによって異なりますが、追加機能をカットして品質を提供するようにしてください。「リワーク」から再度引用：

後で行うことは、より良いことも意味します

...そして、より少ないバグで期限を守る

さて、あなたはこの方法でそれを組み立てることができます：あなたはすぐに品質にお金を払いたいですか？そもそもそれをうまく行うために時間をかけるか、後ですべての問題を修正するために時間を費やしてください。この機能開発後のバグ修正フェーズは、既存のコードがすでに配置されており、おそらく十分に高品質ではないため、リスクが高く、ハッキングソリューションが発生しやすいため、より高価になる可能性があると主張します。

期限に間に合い、既知の問題のリストを提示します。

人々はバグを見つけることを嫌いますが、前もって言われた場合、彼らははるかに寛大になる傾向があります。

これは状況に完全に依存します。

考慮すべき多くの要因があります。

1. パッチの展開はどれくらい簡単ですか？
2. 基本的な簡易バージョンをリリースしてから、新しい（エッジケース）機能に時間をかけてパッチを適用することは可能ですか？
3. そのような製品のクライアント業界の一般的な文化は何ですか？彼らは一度限りの完全なリリースを期待しているのでしょうか、それとも最初のリリース時にバグのある進化するシステムのアイデアに慣れていますか？
4. 期限を延期するのではなく、バグのある初期バージョンがもたらすビジネスへのリスクはどれくらいですか？

つまり、これに対する白黒の答えはありません。例：組み込みシステムのように、フィールドのデバイスに展開するのが困難で高価なものの場合、待機（可能な場合は期限を再交渉）して、可能な限りバグのない状態にすることをお勧めします。一方、大規模なWebポータルシステム（Webアプリとして記述されている）のようなものは、修正が公開されたときにいつでも簡単にアップグレードできるため、最初は危険なバージョンをリリースする方が合理的です。次に、パッチの問題（およびエッジケースの機能）を取得します。

しかし、結局のところ、私の経験では、これは技術的な決定というよりもビジネス上の決定に近いものでした。期限を逃すことが非常に重要で、バグのある初期バージョンを持たない（またはその逆）状況にある場合-決定を下す際にこれらのことを検討する必要があります。

注：プログラマーとして、もちろん、製品を解き放つ前に可能な限り磨くというアイデアを好みます（つまり、締め切りはまったくありません;））。しかし現実的には、これは現実の世界では不可能です。多くの場合、最初のリリースを削除することは、適切な解決策です。

多くのPMが、スケジュールに間に合わないことをクライアントに伝えることを恐れており、既知のバグが同梱されていると主張しているのを見てきました。彼らがクライアントに伝えるたびに、彼は通常、バグの減少と期限の移動にはるかに興味があることを伝えることができます。納期が絶対に移動できない場合（納税ソフトウェアを使用している場合の納税申告期間の開始など）または移動に非常に費用がかかる他のいくつかに影響しない限り、私は彼らが逃した納期よりもバグを覚えていることを保証しますすべての期限の98％がこれらの基準を満たしていません。

バグに依存すると思います。どのコンピューターでもアプリが起動されるとすぐにアプリがクラッシュするバグを修正するために、リリースを遅らせますか？はい、間違いなく。満月の間にWindows MEでのみ発生するバグを修正する必要がありますか？それはおそらく待つことができます。

重大なバグである場合は、2番手の手をかけることが望ましいです。その理由は、更新プログラムで修正をプッシュする必要がある場合、修正にかかる費用が指数関数的に大きくなるためです。

それほど重要でない更新については、バンドルされた更新をリリースして、そのコストをある程度削減できます。

疑わしい場合は、＃2を使用すると言いますが、そのアプローチで経営陣からの反発を得るのは驚くことではありません。マネージャーは、不必要な重要な更新を引き起こさないことよりも、締め切りを守ることにどれだけ優れているかによって判断される傾向があると思います。

どちらでもない。コードで品質を焼き上げてみませんか？品質の高いコードで期限を守ることができますか？プッシュする機能は少なくなりますが、プロセスに品質が組み込まれていれば、両方を実現できます。

今起こっているのは、ビジネスを後押しし、2つのことについて会話できる、権限のあるチームリーダーまたは開発マネージャーが必要だということです。

1. コードに組み込まれた品質=ビルドごとに2つ少ない機能
2. 本当に必要なものに関して、利害関係者の最も必要な機能に優先順位を付けます。

次に、最も価値の高い機能に集中し、優れた機能を押し出すことができます。

テストに関する限り、それは決して終わりではありません。それは終わったが、決して終わらない。

重大度が高く、より優先度の高いバグに気をつけて打ち上げてください。

多くのバグで締め切りに間に合うと、あなたは業界で貧しくなり、顧客は再びあなたに来ません。顧客と話し合って、2、3日遅れを得ることができます。

最終ユーザーからこれを見ると、誰かが月曜日に何かをすることを約束し、それを使用しようとしてもうまくいかないか、すべてバグがあります。

しかし、「手続き」側を見ると、アプリケーションがより多くのテストとソフトウェアの自然な生活の一部を必要としていることを意味します。

私の最善のアプローチは、物事を彼らが働くべき方法で動作させることです（その主要なモジュールである場合、詳細に注意を払わない場合、フォームでログインする必要がありますが、その後通知を表示しない場合は誰でもピッキングされます）。

これはあなただけが答えられる質問です。それは製品の種類、顧客が誰であるか、顧客が何を要求しているかなどに依存します。単純な「a or b」の答えを出す方法はありません。その完全に状況依存。

しかし、リリース後にバグを修正するコストは、リリース前に修正するよりもはるかに高いことを思い出します。バグを修正するためにリリース後まで待つかどうかを決定するときに、より多くの時間/労力/お金を費やすことになりますので、考慮してください。