Pourquoi un PM ne peut-il pas être un QA réussi ?

Un PM peut être un QA théoriquement. Parce qu'un chef de projet connaît parfaitement le projet et peut s'assurer que tout fonctionne comme il se doit. Mais pas pratiquement. Pourquoi?

Dans quelques petites organisations, un chef de projet porte également le chapeau d'un responsable de l'assurance qualité. Ce qui est un rôle conflictuel car ces deux rôles sont opposés l'un à l'autre. En pratique, le responsable de l'assurance qualité suit quelques SOP pour évaluer correctement la fonctionnalité du logiciel comme prévu et est à égalité avec l'expérience globale de l'utilisateur. Tout problème trouvé est correctement documenté et envoyé à l'équipe de développement pour qu'il y travaille. Ceci est répété jusqu'à ce que le produit soit prêt pour l'utilisateur final. Les autres rôles d'un responsable de l'assurance qualité consistent à conserver des enregistrements des défauts connus et à les tester.

Alors qu'un PM est plus familier avec la portée du produit. Un PM connaît les exigences du produit comme personne d'autre. Le PM doit évaluer les risques et les coûts de base appropriés, gérer les ressources du produit, communiquer avec les parties prenantes et respecter le calendrier. Et enfin diriger l'équipe QA. Parce que plus le cycle se répète, plus il est susceptible de dépasser le coût de base.

La principale différence entre un chef de projet/produit ou un responsable AQ réside dans l'application du bon état d'esprit par un chef de projet. Un chef de projet portant le chapeau de responsable AQ se concentre toujours sur l'apparence de son projet, même lorsque des résultats d'AQ contradictoires sont observés dans le processus.

Je suis sûr que de nombreux chefs de projet exerçant ce type de double rôle attesteront de ce fait dans leur cœur même s'ils ne s'expriment pas à l'extérieur. C'est parce qu'un chef de projet veut être un chef de projet et non un responsable de l'assurance qualité. Lorsqu'un chef de projet désigné agit en tant que responsable de l'assurance qualité, psychologiquement, il a tendance à être un chef de projet plutôt qu'un responsable de l'assurance qualité.

Lorsqu'une fonctionnalité défaillante est observée dans un système, un responsable de l'assurance qualité peut facilement évaluer avec une documentation et des rapports appropriés qui accélèrent le travail du développeur là où cela pourrait ne pas être le cas avec un chef de projet. Un chef de projet peut être soumis à de nombreuses pressions de la part des parties prenantes, des délais du projet et des coûts de développement qui pourraient être dépassés pour cela.

Cela a un impact négatif et peut causer certains problèmes, y compris, mais sans s'y limiter, la démoralisation du développeur responsable. Ces problèmes peuvent être traités différemment de manière plus appropriée.

Les chefs de projet peuvent être en désaccord avec moi, mais il n'est pas écrit en petits caractères que le cas de chaque projet sera le même et que les mêmes principes peuvent être appliqués. Il est préférable de suivre les procédures générales où il y a un responsable QA pour gérer ces choses et le PM peut se concentrer sur ses préoccupations pour minimiser ou atténuer les problèmes qui pourraient apparaître plus tard sur le projet.

C'est ainsi que les membres de l'équipe bénéficient d'une QA réussie - "Meilleur moral, plus d'enthousiasme et moins de frustration".