外部クライアント向けに開発する場合のユーザー受け入れテストの欠陥分類
私は、私たち（非常に小さなスタートアップ）が外部のクライアント（非常に大きな会社）のために開発している大規模な開発プロジェクトに携わっています。
最近、かなり小さな反復のUATテストから最初の出力を受け取りました。これには、低、中、高の3つのカテゴリにトリアージされた12個の「欠陥」がリストされています。
私たちが抱えている問題は、このリストのすべてを「欠陥」として記録する必要があるかどうかです-彼らが見つけた問題のいくつかは、改良、または「便利なもの」としてより適切に説明され、いくつかは欠陥ではないと私たちは考えますまったく。
クライアントのQAリードは、特定したすべての問題に欠陥としてラベルを付けるのが標準であると述べていますが、これについては少し不快です。関係は良好ですが、これに大きな問題は見られませんが、将来関係が悪化した場合、これらの「欠陥」のリストは私たちにとってコストがかかる可能性があることを懸念しています。
私たちはここで難しいことや個人的に物事を取りすぎることを望んでおらず、特定されたすべての変更を喜んで行いますが、特に私たちの関係には不均一なパワーバランスがあるため、少し心配しています。
私たちはここで妄想していますか？それとも、この分類に同意することで、今後の問題に備えることができるでしょうか。
人々を幸せにするなら、「報告された顧客の問題」または他の何かを言うことができます。こんなに壮大な歴史があり、業界標準の用語なので、「バグ」と言います。まったく新しいバグリストでは、ほぼ100％修正されると予想される場合があります。ただし、リストに追加されるバグが多いほど、修正する予定のバグは少なくなります。実際、ほとんどのバグ追跡ツールでは、重複、機能要求、再現不能、保留、追加のフィードバックの必要性など、さまざまな理由でバグを閉じることができます。
重要なことは、フィードバックとそのフィードバックに対して実行されたアクションをキャプチャすることです。修正するバグと実装する機能を選択できることをお客様に明確に示しています。私たちは、ほとんどのクライアントを最も幸せにするだろうと私たちが考えることに基づいてそれを行いますが、それは私たちの選択です。
これらのバグに関するフィードバックを提供する際は、敬意を払ってください。何かを修正するつもりがない場合は、その理由を伝えてください。特定のバグに対する特定の解決策に取り組む準備ができていないと言ってもよい場合があります。または、バグがこのリリース（またはこの製品）の範囲外であること。または、システムの動作のバグは、改善されたドキュメント（UIまたはドキュメントを微調整して、ユーザーがバグの原因にならないようにするなど）によって「修正」される可能性があります。明らかに、いくつかのバグを修正すると、クライアントは他のバグを修正しないことに対してよりオープンになります。
顧客があなたのソフトウェアの使用に大きな問題を抱えている場合、バグ命名システムは彼らを幸せにしません。彼らがあなたのソフトウェアを愛しているなら、名前も関係ありません。優れたソフトウェアを作成し、クライアントを尊重し、バグカテゴリにとらわれないようにします。
はい、バグ/欠陥/機能/彼らが何を望んでいるのかを知らない/要件のクライアント分類を盲目的に受け入れることによって、トラブルに備えることができます。 Greg Bairが指摘しているように、"あなたは間違っている"が実際のソフトウェアではなく問題である場合があります。
これらは、要件を定義する人がソフトウェアを日常的に使用しないために最も頻繁に発生します。これを軽減するのに役立つ1つのことは、サステイン/サポートチームを介さずに、直接ユーザーフィードバックを取得するためのチャネルを確立することです。
理想的には、チームが欠陥を入力した個人と話をして、詳細を抽出できるようにする機会があります。多くの場合、単に個人と話し、何かがそれが行うことを行う理由を説明することで（要件がそれをしなければならないと言っても）、欠陥を取り戻すことができます。
これを解決する方法があると考えるのは良いことですが、大企業への非常に小さなサプライヤーとして、彼らはほとんど条件を決定していることがわかります。私は長い間このような状況にあり、巨大な多国籍企業でした。私たちは彼らの考え方に沿って行動することを学ぶ必要があります。
最も重要な緩和策は、関係する人々、特に意思決定者との良好な関係を持つことです。そうすれば、あなたは優しく影響を与えることができ、物事が醜くなると、彼らはあなたのために声を上げます。
もちろん、あなたはあなたを保護する良い契約/法的条件を持っていることを確認することができますが、顧客が本当にあなたを好きではないと判断し、人生を困難にする場合、それらはあまり役に立ちません。だからこそ、人間関係はとても重要です。
大企業では、明確に定義されたプロセスが必要です。そうしないと、全員が自分のことをやる必要があり、チームAはチームBの「欠陥」の定義が何であるかを知りません。したがって、チームは他のチームが何について話しているのかを即座に知ることができるように、おそらくかなり厳密な分類システムがあります。
ただし、これは、これらの用語が組織で何らかの意味を持つ必要があるという意味ではありません。実際、彼らにとって優先度が高いからといって、必ずしもあなたにとって優先度が高い必要があるとは限りません（彼らはおそらく巨大な顧客であるため、考えるのは怖いことです）。彼らの目には、それが何かをするときはいつでも予期しない、それは、その予期しないことが設計どおりであるかどうかにかかわらず、欠陥です。また、複雑なソフトウェアを使用している場合、物事がどのように機能するかについて混乱しがちです。私たちのバグ追跡ソフトウェアに「あなたはそれを正しくやっていない」という終わりの理由があったらいいのにと思います。
たとえば、先週の私の会社（私たちはカスタム開発ショップではなく、実際のソフトウェア製品を持っています）で、顧客がアカウント担当者を通じてバグを送信し、それが実際のバグであるかのように振る舞いました。つまり、製品はそうではありませんでした。正しく動作します。製品は設計どおりに機能し、契約どおりに機能することを説明しました。彼らが望んでいたのは機能強化でした。これは、「バグ」や「欠陥」ほど管理上怖いものではありません。
プロジェクトの範囲外の欠陥をしない「修正」することを確認してください。それはあなたがあなたがすべてを無料でやるだろうと思っているうめき声の顧客を得る方法です。
私たちはここで妄想していますか？それとも、この分類に同意することで、今後の問題に備えることができるでしょうか。
これは、クライアント管理のトピック/問題として私には聞こえます。
あなたの開発アプローチは、このタイプのクライアントにとって非常に正しいアジャイル/スクラム手法を使用しているようです。ただし、製品の所有者は、クライアントの本当のニーズと本質的な期待は何か-開発およびスプリント計画に含めるための最優先事項であることをよく知っている可能性があります。
製品の他のイテレーションまたは成果物フェーズにそれらを含めることができるため、すべての中レベルおよび低レベルの欠陥をログに記録するアプローチは重要です。したがって、重要なビジネス要件を製品所有者が明確に理解していることが、考慮すべき重要な要素であるというのが私の前のポイントになります。