テクニカルサポートを調整する

現在のタスクを実行するときに、仕事のチャットで緊急の問題を解決することに気を取られませんか？ そうではないと思います！

状況を想像してください。あなたはタスクを開始していますが、チャットの通知に気を取られており、ユーザーからの質問に対して緊急に支援を求められます。 そして今、あなたはすでに活発な議論に参加しており、これがバグか機能かを理解しています。

ここで、あなたに加えて、このチャットルームには80人以上の人で構成される開発部門全体があり、各参加者がこれらの議論に関与していると想像してください。

SuperJobでは、理解できない状況でのテクニカルサポートがすぐにSlackでチャットし、それによってすべての参加者を現在の活動からそらしました。 そのため、テスト部門の私たちは、ユーザーからのバグを処理するプロセスを変更しようとしました。



以前は、ユーザーからのバグを処理するプロセスは次のとおりでした。

• ユーザーから受け取ったフィードバックはテクニカルサポートスペシャリストに渡されました。
• テクニカルサポートスペシャリストが詳細を見つけましたが、問題を再現しませんでしたが、すぐにテクニカルサポートプロジェクトのJiraでタスクを開始しました。
• タスクはSlackの別のチャットルームに投入されました（ちなみに、このようなチャットルームは6つありました。応募者、雇用者、およびアプリケーションの各プラットフォームの問題について）。
• チャットで、テスターはこのタスクを引き受け、問題を理解し、ローカライズし、どのように機能するかを理解し始めました。
• 開発者はテスターに​​加えてチャットにも参加し、ディスカッションに積極的に参加しました。
• すべての明確化の後、テスターはタスクを目的の開発プロジェクトに転送し、名前を変更し、説明を修正しました。

最終的に、複数の専門家が1つの問題を一度に議論し、再確認するのに多くの時間が費やされたことが判明しました。 また、タスクの説明では常に問題の本質をすばやく理解できるとは限らなかったため、ユーザーとのテクニカルサポートのやり取りを開いてから、このタスクの編集により多くの時間を費やす必要がありました。

多くの問題はバグではなく、開発者にはまったく届かないはずです。 しかし、同時に、開発者はすでに議論プロセスに関与していたため、タスクの邪魔になりませんでした。

このプロセスを変更し、テクニカルサポートをより独立させる必要があると判断しました。

変更したい最初のことは、テスターに​​よるバグの二重チェックを取り除くことでした。

解決策はこれでした。テスターが作業するワークフローを説明し、わずかに変換して、テクニカルサポートスペシャリストに渡しました。 ユーザーからの問題を処理するとき、彼らはそれを通過しなければなりませんでした。


このワークフローを簡単に説明すると、テクニカルサポートスペシャリストはバグを開始する前に要件を個別に再確認し、必然的にエラーを再現し、タスクを開発プロジェクトに投入します。

状況が再現しない場合、タスクはテクニカルサポートプロジェクトで開始され、次のユーザーが連絡するまで「一時停止」されます。 ユーザーからの新しいリクエストがある場合、技術者は問題を再現するために再試行する必要があり、再現する場合は、タスクを開発プロジェクトに転送します。

繰り返される苦情も再現されない場合、タスクは開発プロジェクトに転送され、問題を再現できなかったという義務的なコメントが付けられます。 おそらくこの状況では、開発者はその部分で問題を見つけて解決できるでしょう。

したがって、単一の呼び出しに多くの時間を費やすことはなく、繰り返し呼び出しが行われる場合にのみ開発者を接続します。

長所：テストスペシャリストの時間を節約できます。また、チャットで質問を見て、説明に関連する開発者の時間も節約できます。

2番目の問題は、 バグ自体の設計でした。
情報価値のない名前、混、とした、そして時々不思議な説明。
例：


解決策：例を通じて、彼らは「何？」の原則を使用して、バグの名前をどのように構成するかを説明しました。 どこ？ いつ？」

たとえば、処理後のタスク名「Trouble from」「サイトのジョブ」はより透明になりました。「ブロードキャストセクションに移動すると、「サイトのジョブ」ブロック内のジョブは表示されません」。 どんな「トラブル」が起こったのか、名前からのみ誰にでも明らかになりました。

説明にテンプレートを使用することに同意しました。 Jiraに追加しました。 バグを作成するときは、プラットフォームに応じて目的のテンプレートを選択し、記入する必要があります。


すべての情報はConfluenceの指示に記録され、いつでもアクセスできます。

長所： Jiraのバグを検索するのが簡単になりました。名前を付けることで、タスクに入らずに本質をすぐに判断できます。 説明は構造化され、開発者にとってより理解しやすくなりました。

すべての3番目の気晴らしは、技術サポートといくつかのチャットルームの存在です 。

解決策：「チャットルームを増やしてください！」


#supportを1つだけチャットし、残りを閉じることにしました。 現在、社内のすべての従業員は発見された問題から解放され、技術サポート担当者のみがそこで答えます。 再チェックを行い、タスクを開始します。

長所：見つかった問題を報告できるエントリポイントが1つあります。

以前は、開発者は何らかのバグを見ることができましたが、どこに報告すればよいかわかりませんでした。 最初に、どのチャットをオフにするかを把握する必要がありました。 それは難しいです...したがって、単純に何も気にせずそのままにしておく人もいました（まあ、または特に意識的な人はテスターに​​投げ捨てられました）。

しかし、もちろん、このアプローチの実装にはいくつかの困難がありました。 たとえば、テクニカルサポートスペシャリストは、問題を常に正しく特定できず、問題がバックエンドかフロントエンドかを判断できません。 このため、間違ったプロジェクトまたは間違ったチームでバグを取得し、タスクをあるセクションから別のセクションに転送する時間を再び失うリスクがあります。
バグの説明と名前にはまだエラーがあります。 したがって、これらの欠点を解消するためにタスクを調べる必要がありますが、その数はそれほど重要ではありません。

すべての革新の後、ワークフローは次のようになります。

• 技術サポートの専門家はより独立しており、テスターがバグを再確認するのを待つ必要はありません。
• ユーザーからのバグはJiraでより早く起動し、より早く開発に取り込むことができます。
• テスターと開発者はタスクから気を散らされません。
• 開発者は、より興味深いトピックについてチャットルームでチャットするようにholivarを手配できるようになりました。

そして、あなたの会社に配置されたユーザーからのバグを扱うプロセスはどうですか？ あなたの例を共有してください:)