これは少し哲学的な質問です。私は自分のソフトウェアに小さな機能を追加しています。これはほとんどのユーザーが使用すると思いますが、ソフトウェアを使用する回数はおそらく10％にすぎません。言い換えれば、ソフトウェアは3か月間それがなくても問題ありませんでしたが、4〜5人のユーザーがそれを要求しており、私はそれがそこにあるべきであることに同意します。
問題は、私が使用しているプラットフォームの制限（そしておそらく私の脳の制限）のために、「私ができる最善のこと」にはまだいくつかの重要ではないが顕著なバグがあることです-コード化された機能が使用可能であるとしましょうしかし、場合によっては「少し不安定」です。
何をすべきか？90％ある機能は、本当に「何もないよりはまし」なのだろうか？修正できないバグレポートがいくつか届くと思います。それらについて顧客に何を伝えればよいでしょうか。未回答の機能リクエストまたは未回答のバグレポートを使用する必要がありますか？
人々が問題があることをあなたが知っていることを知っていることを確認してください。バグがあること。そして、フィードバックを提供する簡単な方法を提供します。
そもそもこの機能を提案した「4人または5人のユーザー」との「クローズドベータ」はどうでしょうか。
未回答の機能リクエストとバグレポートは常にあります。出荷しますが、「既知の問題」と可能な場合の回避策を記載したreadmeを含めます。
あなたはあなたのユーザーの観点からこれを考える必要があります-それはより少ない欲求不満を引き起こしますか？バギーコードは通常、不足している機能よりもイライラします。
完璧主義者は「やらないでください」と答えるかもしれません。
ビジネスマンは「やる」と答えるかもしれません。
バランスがどこにあるかはあなた次第だと思います。バグが重大ではない場合、私はそこに機能を配置する方向に動いています。ほとんどのユーザーは、あなたと同じようにあなたのソフトウェアを見ることはありません。あなたは職人/芸術家です。つまり、普通の人よりも批判的です。
機能をリクエストした4〜5人にベータ版を入手する方法はありますか？次に、フィードバックを受け取ったら、どの決定を下すかが明確になる場合があります。
奇抜さを正確に文書化して出荷します。
ユーザーがあなたの奇抜さのドキュメントを見て理解する可能性が高いことを確認してください。
この機能をリクエストしたユーザーと決定について話し合うこともできます。市場調査を行ってください。
現在修正できないからといって、将来修正できないという意味ではありません。物事は変わります。
あなたが今持っているものを「ベータ版」としてラベル付けし、それを求めた人々にそれを送ってください。それがどれだけうまく機能するかについて彼らのフィードバックを得て、彼らが不満を言うものは何でも修正してください、そしてあなたはそれをより大きなユーザーのグループに展開する準備ができているはずです。
早期に出荷し、頻繁に出荷し、定期的にリファクタリングします。
つまり、出荷を止めさせないでください。ただし、問題の修正をあきらめないでください。
奇抜さを解決できないことは、コードベースに問題があることを示しています。機能を追加するよりもリファクタリングに多くの時間を費やしてください。
私はそれがあなたの基準に依存すると思います。私にとって、バグのあるコードは本番環境に対応していないため、出荷しないでください。ユーザーが特定の条件下で何を期待できるかを知ることができるように、既知の問題リストを含むベータ版を入手できますか？彼らは新しい機能を使用することの利点を得るだけでなく、それが完璧ではないことも知っています（それは彼ら自身のリスクを使用してください）。これにより、機能を要求した4〜5人の顧客がしばらくの間満足できるようになり、バグを修正して（可能であれば）後で大衆向けに本番環境にリリースするための時間を増やすことができます。
あなたの状況に応じていくつかの考え。
依存します。バグ、それらの重大度、およびそれらを修正するのにどれだけの労力がかかると思うかについて。締め切りに、そしてあなたがそれをどれだけ伸ばすことができると思うか。コードの残りの部分と、クライアントがそれを使ってできること。
バグが原因で死亡したり、ユーザーのファイルが失われたりする可能性がある場合は、出荷しないでください。
バグによってアプリケーション自体がクラッシュする可能性がある場合は、警告（readmeなど）を付けて出荷します。クラッシュにより、この正確なアプリケーションで編集中のユーザーのファイルが破損する可能性がある場合は、アプリケーションを起動するたびに警告を表示し、最初にファイルをバックアップするようにユーザーに通知します。
バグがBSODを引き起こす可能性がある場合は、出荷先に十分注意してください。
コーダーが既知の問題をテストに提供することはもちろん、顧客にリリースすることも期待していません。
気をつけてください、私はバグのゼロトレランスを信じています。興味深いことに、すべてのバグを取り除くことに熱心なのは通常、開発者/テスターであることがわかります。バグを受け入れる意思があるのは、多くの場合、プロジェクトマネージャーや顧客です。
コードをリリースする必要がある場合は、認識しているすべての機能/バグを文書化し、それぞれを修正することを約束します。
作業しているプラットフォームの制限についてもっと情報を投稿してみませんか。おそらく、ここにいる賢い人たちがバグリストを削除するのを手伝ってくれるでしょう。
需要が機能する機能ではなく、今すぐ機能を求める場合。発送させていただく場合がございます。
ただし、この状況では：
他に何も壊れないのなら、出荷してみませんか？あなたは顧客との良好な関係を持っているように思われるので、この機能を必要とする人は、それが完全にそこになくても喜んでそれを手に入れるでしょう、そしてそれを望まない人は気にしません。さらに、次のリリースでそれを改善するためにたくさんのフィードバックを得るでしょう！
あなたが答える必要がある重要な質問は、あなたが思いついたデザインを考えれば、あなたの機能が実際のビジネスニーズを解決するかどうかです。次に、実装を設計に一致させるだけです。「バグ」を、機能の意図された動作（設計でカバーする必要がある）の一部ではないと定義することで、バグではないものにします。
これは、非常に現実的なパスの選択に要約されます。バグは、意図した動作と設計の一部ではなく、正しく機能しないものですか？それとも、意図した動作に従って動作しない場合にのみバグですか？
私は後者をしっかりと信じています。バグとは、意図したとおりに機能しないものです。実装は設計をキャプチャする必要があり、それはビジネスニーズをキャプチャする必要があります。設計でカバーされなかった別のビジネスニーズに対処するために実装が使用される場合、実装ではなく、設計に問題があります。したがって、それはバグではありません。
前者の態度は、私の経験ではプログラマーの間で断然最も一般的です。これは、ユーザーがソフトウェアの問題を表示する方法でもあります。ただし、ソフトウェア開発の観点からは、このビューを採用することはお勧めできません。これは、ビジネスニーズに合わせてソリューションを再設計するのではなく、バグではなく設計上の欠陥を修正するためです。
ユーザーのためにバグのあるソフトウェアをインストールしなければならない人からのもの - その機能を有効にして出荷しないでください。
文書化するかどうかは問題ではありません。エンド ユーザーは最初にそのバグに遭遇したときにそのことを忘れてしまい、そのバグは彼らの仕事を遂行できなくなる重大なものになります。