現場で見つけたことを、製品の開発チームへどう返しますか

1 回の報告ではなく往復の仕組み

お客様先にいると、製品の足りない所が毎日見えます。それを思い付いたときにチャットで個別に頼むと、製品のチームには前後の分からない頼みが散らばって届き、どれも後回しになりがちです。

だから流れを 1 本に決めます。

5 まで回ると、お客様は「言えば届く」と分かり、製品のチームは現場の声を数で比べられます。

何社で何回かを数える

製品のチームは、何十もの頼みを比べて優先を決めます。比べる手がかりになるのが数です。「1 社で 1 回」と「5 社で毎週」では重みがまるで違います。似た話が別のお客様から出たら、新しく書かずに同じ項目へ件数を足します。チームの全員が同じ置き場を使うと、自分の担当では 1 件でも、全体では多いと分かります。

業務の言葉ではなく再現の手順と影響で書く

お客様の言葉そのままの「承認が回らない」では、製品のチームには何が起きているか分かりません。製品の言葉に直し、再現の手順と影響で書きます。

• 再現の手順どの設定で、何を入れて、何をすると、どうなるか
• 期待していたこと本来どうなってほしいか
• 影響だれが、どれくらいの頻度で、どれだけ困るか。手での回避はあるか

お客様の名前や社内の情報は、製品のチームに要らなければ書きません。

優先を決めるのは製品の側

現場にいると、目の前のお客様の困りごとがいちばん大事に見えます。でも製品のチームは、全部のお客様と製品の向きを見て決めます。自分の役目は、判断に要る材料を正しく渡すことで、順番を押し通すことではありません。急ぎの物は、なぜ急ぐのかを影響で示し、定期の場で話します。

返事をお客様に返す

製品のチームから「やる、いつ」「やらない、理由」の返事が来たら、お客様に返します。やらないと決まった物も、理由とそれまでの手当てを添えて伝えます。返事のない頼みが増えると、お客様は声を上げるのをやめてしまいます。

自分で直すか待つかの線

お客様を待たせられないときに、自分で製品のコードを直したくなることがあります。どこまで現場で直してよいかを、チームで先に線を引いておきます。たとえば、設定や外の作り込みで手当てできる物は現場で、製品の芯に触る物は製品のチームのレビューを通す、とします。現場で直した物も、置き場には書いて製品のチームに知らせます。

トレードオフ

仕組みを決めて定期の場で渡すと、比べやすく漏れにくいですが、急ぎの物が次の場まで待たされます。個別に頼めば速いですが、声の大きい現場の頼みばかりが通ります。普段は仕組みで回し、急ぎだけを別の道で渡す、と道を 2 つに分けて決めておきます。