解決できないヘルプデスクチケットを閉じるプロセス
ITヘルプデスクで、いくつかの共通の特徴を持つチケットがある場合があります。
- それらは優先度が低く、ユーザーにとってわずかな不快感です
- テストのために再現するのは非常に難しい
- 自由に使用できるすべてのトラブルシューティングの可能性を使い果たしました
- チケットに何時間も費やしました
幸い、これはチケットのごく一部ですが、実際に発生します。私のアプローチは、これらのチケットを無期限に開いたままにし、最終的には忘れられた土地で苦しむことでした。もっと良い方法はありますか？解決できないチケットをクローズするためのプロセスは何ですか？
情報が不足しているために解決できない問題と、優先度の低い問題の間には、根本的な違いがあります。
再現するための適切な手順が含まれていないために解決できない問題、または既知のデバッグとトラブルシューティングの手法で何も解決されない問題の場合、解決策に最も近いのは、将来のレポート用の追加のインスツルメンテーションの追加です。これらは、できるだけ多く閉じておく必要があります。今後のレポートには、追加の計装またはより適切な再現手順への参照を含める必要があります。
再現可能で解決可能な問題については、優先度が低いという理由だけでこれらをクローズしないでください。カスタマーサービスの観点から見ると、何かが優先されていない既知の問題であり、顧客が初めて問題を発見するよりも、その問題を理解する方がはるかに優れています。さらに、コミュニケーションとディスカッションのために、問題のすべてのインスタンスへのトレーサビリティを向上させます。
優先度の低い問題が「ブラックホール」や「永続的な不平」の状態になることはありません。それらは定期的にトリアージされるべきです。十分な情報がある場合は、テストを記述してこれらの問題にリンクし、時々実行する必要があります（ただし、テストに失敗するため、通常のビルドの一部としてではありません）-テストがエラーまたは成功した場合、状況が変化しましたそしておそらく問題はそれがまだ関連しているかどうかを確認するために再検討されるべきです。また、関連する領域で作業しているシステムチームのさまざまな機能に問題をリンクして、未解決の問題を見つけて、進行中の作業で解決できない問題があるかどうかを確認することもできます。
「修正しない」は、私の意見では、バグレポートに対する無効な応答です。これはバグでも欠陥でもなく、システムは意図したとおりに動作しています（おそらく、ドキュメント、トレーニング、またはその他の何かを変更してユーザーが問題だと思わないようにする必要があります）、現在の知識で再現することはできず、それを経験している人は、十分な詳細を提供できないか、何らかの計装が整っているか、優先順位を下げただけの既知の問題です。
バグが修正されずにクローズされた場合、または積極的に作業せずにオープンのままにされた場合に使用できるステータスと解決策がたくさんあります。
- 放棄された
- 古くなった
- キャンセル
- 再現できません
- 期限切れ
- モニター
- 保留
- 延期
- 情報を待っています
- 直らない
実際にこれらすべてを使用しているかどうかはわかりませんが、検索やレポートから、必要に応じてフィルタリングしたり除外したりできます。通常、お客様の状況では、ユーザーからの詳細情報を待っているか、またはある種の裏付けとなるレポートまたは再現手順を監視して期待しているかに応じて、monitorまたはwaiting on infoに配置します。または他の場所からのログエントリ。その後、数か月後、cannot reproduceで締め切ります。
したがって、反省すべきいくつかの論争の的になっている声明。
「ヘルプデスクは、バグを修正または報告するためのものではありません。製品のユーザーを幸せにするためにあります。」
「開発者はバグを修正するためにそこにいるのではなく、新しいsellable機能を備えたバージョン2を書くためにそこにいます」
「顧客を満足させるためのチケットKPIはありません。マネージャーにボーナスを提供できるようにあります。」
バグを知ることは良いことです。あなたが知らないバグを修正することはできません！しかし、顧客に問題を伝えることはバグであり、彼らを幸せにすることはありません。また、チケットを開いたままにしておくとマネージャーが幸せになり、繰り返す手順のないバグは開発者を爆発させます！