PM が QA として成功できないのはなぜですか?

PM は、理論的には QA になることができます。PM はプロジェクトを完全に理解しており、物事が正常に機能することを保証できるからです。しかし、実際にはそうではありません。なんで？

いくつかの小規模な組織では、プロジェクト マネージャーも QA マネージャーの帽子をかぶっています。これらの 2 つの役割は互いに反対であるため、これは相反する役割です。実際には、QA マネージャーは、ソフトウェアの機能が意図したとおりに機能し、全体的なユーザー エクスペリエンスと同等であるかを適切に評価するために、いくつかの SOP に従います。見つかった問題は適切に文書化され、開発チームに送信されて作業されます。これは、製品がエンドユーザーに提供されるまで繰り返されます。QA マネージャーのその他の役割は、既知の欠陥の記録を維持し、それらをテストすることです。

一方、PM は製品の範囲に精通しています。PM は、他の誰よりも製品の要件を知っています。PM は、適切なリスクとコストのベースラインを評価し、製品リソースを管理し、利害関係者と連絡を取り、スケジュールを守る必要があります。最後に、QA チームを率いてください。サイクルが繰り返されるほど、コストのベースラインを超える可能性が高くなるためです。

プロジェクト/プロダクト マネージャーまたは QA マネージャーの主な違いは、プロジェクト マネージャーによる正しい考え方の適用にあります。QA マネージャーの帽子をかぶったプロジェクト マネージャーは、その過程で相反する QA 結果が観察された場合でも、常に自分のプロジェクトの外観をよりスマートに見せることに重点を置いています。

このような二重の役割を果たしている多くのプロジェクト マネージャーは、表には出さなくても、心の奥底ではこの事実を保証していると思います。これは、プロジェクト マネージャーが QA マネージャーではなく、プロジェクト マネージャーになりたいからです。指定されたプロジェクト マネージャーが QA マネージャーとして行動する場合、心理的には QA マネージャーではなくプロジェクト マネージャーになる傾向があります。

システムに不具合のある機能が見つかった場合、QA マネージャーは適切なドキュメントとレポートを使用して簡単に評価できます。これにより、プロジェクト マネージャーには当てはまらない開発者の作業がスピードアップします。プロジェクト マネージャーは、利害関係者、プロジェクトの締め切り、およびこれを超える可能性のある開発コストから、多くの性質のプレッシャーを受ける可能性があります。

これは悪影響を及ぼし、責任者である開発者の士気をくじくなど、特定の問題を引き起こす可能性があります。これらの問題は、より適切な方法で別の方法で処理できます。

プロジェクト マネージャーは私に同意しないかもしれませんが、すべてのプロジェクトのケースが同じであり、同じ原則を適用できるとは細則には書かれていません。これらのことを処理する QA マネージャーがいる一般的な手順に従うことをお勧めします。PM は、プロジェクトの後半に現れる可能性のある問題を最小限に抑えるか軽減するために、彼/彼女の懸念に集中できます。

これが、チーム メンバーが QA の成功から得られるメリットです。「士気の向上、熱意の向上、フラストレーションの軽減」です。