一つに統合し、原文のリンクをすべて残して、何人が遭ったかが見えるようにします。
複数のチャネルから機能の要望、バグ、不満、重複に関する情報を集め、重複を取り除いて優先順位を付けます。
機能要望・バグの仕分け
機能の要望、バグの報告、使い勝手への不満、そして重複した報告。あちこちから届く声をVelros AIがまとめて仕分け、同じ内容は一つに束ねます。
オンラインの一人創業者にとって報告は、Intercom・Discord・Slack・メール・課題トラッカーから同時に入り、同じバグが複数のチャネルで重複して報告され、何から直すかを毎回また見返すことになります。急ぎのバグが機能要望に埋もれたりその逆が起きたりして、返答のないまま消える報告が溜まります。散らばった報告は、再現も優先順位の判断も難しくします。
こうした要請が、こう処理されます。
実際に入ってくる仕事を集め、それぞれの段階で何を基準に判断するのかまで続けて残します。
-
報告の統合収集
複数チャネルの機能要望・バグ・不満を一つのキューに集め、原文のリンクをひも付けます。
判断 チャネルが違っても同じ症状・要望はまとめる候補と見る。重複を一つに減らすため。 -
種類の分類
機能要望・バグ・使い勝手の不満でラベルを付け、再現の可能性を表示します。
判断 バグと要望をまず分ける。処理の経路と急ぎ度が違うため。 -
重複の統合・再現メモ
同じ件を統合し、再現手順のメモと要望の整理の下書きを作ります。
判断 同じ機能・症状を一つに統合しつつ、原文のリンクを残して、誰がいつ要望したかを追えるようにする。 -
優先順位の候補の整理
頻度・影響の信号で順位の候補を付けて人に上げます。
判断 順位は候補まで。実際の優先順位の確定は人へ渡す。 -
報告の追跡カード
報告・種類・状態・次のアクションを載せたカードを作り、未解決として追跡します。
判断 終結の条件(修正・反映・明示的な保留)を付けて、返答のないまま消えないようにする。
あいまいなら、優先順位を断定しません。
現場で実際に引っかかる例外を、あらかじめ決めておきます。ルールが通らない場面を無理に処理せず、根拠とともに人へ渡します。
バグを主のケースとして開き、機能要望は別のケースに分けて、両方を生かします。
無理にラベルを確定せず、人の確認が必要として残しつつ、再現できたらすぐにバグとして上げます。
ロードマップと優先順位は、人が決めます。
お金・契約・個人情報・ブランドがかかる実行は下書きまでにとどめ、送信と確定は人の承認を経てから動きます。
-
公開ロードマップへの反映
対外的な約束になり撤回しにくいため、人が確定します。
-
報告者へ送る対外的な返答
ブランドの声がにじむ文面なので、人が承認してから送信します。
-
優先順位の確定
何から直すかは、コードではなく人が決めます。
-
バグの深刻度・緊急対応の判断
リソースの配分が絡む判断なので、人の役目です。
-
機能要望の受け入れ・辞退の通知
関係に影響するため、人が確認します。
何で確かめるか
どれだけ早く分類して統合できたかで見ます。
報告の受付から種類の分類までにかかった時間を、導入の前後で実測します。
同じ件として統合された報告の割合を、導入の前後で測定します。
返答のないまま残った報告の数を、導入の前後で測ります。
報告に含まれるユーザーの氏名・連絡先・スクリーンショット内の個人情報を扱うことがあるため、必要な範囲でのみ保管し、対外的な公開や課題の登録の際に個人情報が露出しないように整理します。
人が自分で抱えていた仕事が減ります。
散らばった確認と繰り返しの返信を先に整理して上げれば、スタッフは確認と例外の処理に集中でき、人は大事な判断だけを見ます。
運用診断確認が人のところに積み上がります。
報告が複数のチャネルに散らばって重複し、何から先に直すかを人が毎回また見直します。
処理の準備ができた状態で上がってきます。
報告が一つのキューに集まって仕分け・統合まで用意され、人は優先順位の判断と例外だけを処理します。
この業務を任せる前に、よく聞かれること
機能要望・バグの仕分けについて、実際に最初に確認されることを集めました。
重複した報告はどうまとめますか。
同じ機能・症状の報告を一つに統合し、原文のリンクを残して、誰がいつ要望したかを追えるようにします。
優先順位をVelrosが決めますか。
頻度・影響の信号で候補の順位を付けるだけで、実際の優先順位の確定は人が行います。
報告者へ直接答えますか。
整理と返答の下書きまでで、対外的な返答の送信は人が確認してから実行します。