PM이 성공적인 QA가 될 수 없는 이유는 무엇입니까?

이론적으로 PM은 QA가 될 수 있습니다. PM은 프로젝트를 철저히 알고 있고 일이 제대로 작동하도록 보장할 수 있기 때문입니다. 그러나 실제로는 아닙니다. 왜요?

소규모 조직에서는 프로젝트 관리자가 QA 관리자의 역할도 합니다. 이 두 역할이 서로 상반되기 때문에 상충되는 역할입니다. 실제로 QA 관리자는 의도한 대로 소프트웨어 작업의 기능을 적절하게 평가하기 위해 몇 가지 SOP를 따르며 전체 사용자 경험과 동등합니다. 발견된 모든 문제는 적절하게 문서화되어 작업을 위해 개발 팀으로 전송됩니다. 이것은 제품이 최종 사용자에게 준비될 때까지 반복됩니다. QA 관리자의 다른 역할은 알려진 결함의 기록을 유지하고 이를 테스트하는 것입니다.

PM은 제품 범위에 더 익숙합니다. PM은 누구보다 제품의 요구 사항을 잘 알고 있습니다. PM은 적절한 위험과 비용 기준선을 평가하고, 제품 리소스를 관리하고, 이해 관계자와 소통하고, 일정을 준수해야 합니다. 그리고 마지막으로 QA 팀을 이끄세요. 주기가 반복될수록 비용 기준선을 초과할 가능성이 높기 때문입니다.

프로젝트/제품 관리자 또는 QA 관리자의 주요 차이점은 프로젝트 관리자가 올바른 사고 방식을 적용하는 데 있습니다. QA 매니저의 모자를 쓴 프로젝트 매니저는 그 과정에서 상충되는 QA 결과가 보여도 항상 자신의 프로젝트가 더 똑똑해 보이도록 집중합니다.

이러한 2중 역할을 수행하는 많은 프로젝트 관리자들이 겉으로는 표현하지 않더라도 속으로는 이 사실을 보증할 것이라고 확신합니다. 이는 프로젝트 관리자가 QA 관리자가 아닌 프로젝트 관리자가 되기를 원하기 때문입니다. 지정된 프로젝트 관리자가 QA 관리자 역할을 하면 심리적으로 QA 관리자가 아닌 프로젝트 관리자가 되는 경향이 있습니다.

시스템에서 결함이 있는 기능이 관찰되면 QA 관리자는 적절한 문서와 보고서를 통해 쉽게 평가하여 프로젝트 관리자의 경우에는 그렇지 않을 수 있는 개발자의 작업 속도를 높일 수 있습니다. 프로젝트 관리자는 이해 관계자, 프로젝트 기한 및 이를 초과할 수 있는 개발 비용의 여러 특성에 시달릴 수 있습니다.

이것은 부정적인 영향을 미치고 책임이 있는 개발자의 사기를 꺾는 것을 포함하되 이에 국한되지 않는 특정 문제를 일으킬 수 있습니다. 이러한 문제는 보다 적절한 방식으로 다르게 처리할 수 있습니다.

프로젝트 관리자는 저에게 동의하지 않을 수 있지만 모든 프로젝트의 사례가 동일하고 동일한 원칙이 적용될 수 있다는 작은 글씨로 쓰여진 것은 아닙니다. 이러한 일을 처리할 QA 관리자가 있는 일반적인 절차를 따르는 것이 좋으며 PM은 프로젝트 후반에 나타날 수 있는 문제를 최소화하거나 완화하기 위해 자신의 우려 사항에 집중할 수 있습니다.

이것이 팀 구성원이 성공적인 QA를 통해 얻는 이점입니다. 즉 , "더 나은 사기, 더 많은 열정 및 덜 좌절감"입니다.