プラスは多かれ少なかれ明らかです：
- 開発者は、ユーザーの問題に関する情報を収集するための良い方法を手に入れます。
- ユーザーは既知のバグのリストを使用して、自分で問題を解決できます。 多くの場合、これはより高速な方法であることが判明し、テクニカルサポートサービスの負荷が軽減されます。
- バグトラッカーは、多くの場合、問題に関する情報を見つける別の場所です。 つまり ユーザーにエラーがあり、自分で問題を解決したい場合は、フォーラムを見てバグ追跡ツールを検索する必要があります。 ユーザー向けのフォーラムのみ、またはバグトラッカーのみを残す場合は、さらに改善されます。 同様の問題を探すのは1か所だけにする必要があります。
- ユーザーが製品のエラーを見つけて、バグトラッカーに入力したとします。 彼が電子メールで書いて、24時間以内に応答を受け取らなかった場合、開発者はすでに死亡しているか、サービスが望まれることを多く残しています:-)しかし、バグがデータベースに入った場合、この事実は開発者が少なくとも何らかの形で反応することを義務付けません。 バグトラッカーにバグが存在するからといって、開発者がそれを認識したり修正しようとしているわけではありません。修正しないコメントで5年後には閉じるかもしれません。 多くのユーザーは、バグトラッカーで直接質問することを恥ずかしく思います。結局のところ、これは「パブリック」な場所です。
つまり バグトラッカーでバグレポートを見ると、ユーザーは次のように思うかもしれません。- 開発者がバグレポートを閉じなかった場合、問題を認識します。 エラーはすぐに修正されます。
- 開発者は単に問題に関する情報を蓄積します。 開発者がこのエラーを修正するかどうか、いつ不明か。
- 開発者はこのエラーをX年間知っていますが、まだ修正されていません。 おそらく、彼らはそれをまったく修正しようとしておらず、それについて議論する時間を無駄にしないでください。
- このような悪い現象があります-ユーザーが直接入力したバグを修正するタスクを開発者に与えること。 もちろん、これにより管理者の生活は簡素化されます（開発者をどうするかを考えたり、バグを「ハング」させて落ち着いて座ったりする必要はありません）が、製品の品質に悪影響を及ぼします。 この特定の小さな問題を修正する誘惑が大きすぎて、この原因や他の多数の同様の問題を理解して排除しようとするのではありません。
- バグレポートと変更リクエストの2種類のタスクを実行します。
- ユーザーがエラーを見つけた場合、ユーザーは単にバグレポートを作成します。 さらに、すべてのエラーを登録する必要があり、ユーザーに重複を避けるために同様の問題を探すことを強制します-これは非常に悪い考えです：
- これはユーザーにとって無礼です。 彼はグリッチを見つけ、可能な限り迅速に（少なくとも電子メールで）便利な方法で彼から情報を取得する代わりに、登録、類似のものの検索、フォームへの記入などを強制されます。
- ユーザーは、これが同じグリッチであり、他のグリッチの同様の兆候ではないことを知ることができません。
- すべての問題が記録されるわけではないため、開発者は（部分的に）問題の重要性に関する情報を失います。
つまり、バグレポートは抽象的なエラーに関するメッセージではなく、この特定のユーザーのエラーの発現に関するメッセージです。
- ユーザーがバグレポートを送信した後、会社の代表者は、問題がいつ修正され、何が予定されているかを（個人的に）通知する必要があります。 答えのないバグレポートは、アイデア自体の信頼性を大きく損ないます。
- 会社が最終的にエラーを修正することを決定したとき、バグレポートに関連付ける必要がある変更要求などの個別のタスクを作成する必要があります。 エラーの修正にコードの修正だけでなく、ドキュメント、ウェブサイトなどの更新も含まれる場合、いくつかの変更要求が必要です。 個別の変更要求を作成することの重要性は、開発者の問題修正を「ハング」させる可能性が、不必要な思考なしに除外されるという事実にもあります。
システムでこれができない場合は、ユーザーとの通信のみ（バグレポートのみを送信）または内部開発のみ（変更要求のみを送信）のいずれかでバグトラッカーを使用することをお勧めしますが、1つのヒープにすべて干渉することはありません。