Warum kann ein PM kein erfolgreicher QA sein?

Ein PM kann theoretisch ein QA sein. Weil ein PM das Projekt gründlich kennt und sicherstellen kann, dass alles so funktioniert, wie es sollte. Aber nicht praktisch. Wieso den?

In einigen kleinen Organisationen trägt ein Projektmanager auch den Hut eines QA-Managers. Dies ist eine widersprüchliche Rolle, da diese beiden Rollen einander entgegengesetzt sind. In der Praxis befolgt der QA-Manager nur wenige SOPs, um die Funktionalität der Softwarearbeit wie beabsichtigt richtig zu beurteilen, und entspricht der allgemeinen Benutzererfahrung. Alle gefundenen Probleme werden ordnungsgemäß dokumentiert und zur Bearbeitung an das Entwicklungsteam gesendet. Dies wird wiederholt, bis das Produkt für den Endverbraucher bereit ist. Eine weitere Rolle eines QA-Managers besteht darin, Aufzeichnungen über bekannte Fehler zu führen und diese zu testen.

Während ein PM mit dem Umfang des Produkts besser vertraut ist. Ein PM kennt die Anforderungen an das Produkt wie kein anderer. PM muss die richtigen Risiken und Kostengrundlagen bewerten, Produktressourcen verwalten, mit Stakeholdern kommunizieren und den Zeitplan einhalten. Und schließlich das QA-Team leiten. Denn je öfter sich der Zyklus wiederholt, desto mehr wird er wahrscheinlich die Kostenbasis überschreiten.

Der Hauptunterschied zwischen einem Projekt-/Produktmanager oder einem QA-Manager liegt in der Anwendung der richtigen Denkweise durch einen Projektmanager. Ein Projektmanager, der den Hut eines QA-Managers trägt, konzentriert sich immer darauf, dass das Erscheinungsbild seines Projekts klüger aussieht, selbst wenn im Prozess widersprüchliche QA-Ergebnisse beobachtet werden.

Ich bin mir sicher, dass viele Projektmanager, die diese Art von Doppelrolle ausüben, diese Tatsache tief in ihrem Herzen bekennen werden, auch wenn sie es nach außen vielleicht nicht ausdrücken. Dies liegt daran, dass ein Projektmanager ein Projektmanager und kein QA-Manager sein möchte. Wenn ein designierter Projektmanager als QA-Manager fungiert, ist er psychologisch eher ein Projektmanager als ein QA-Manager.

Wenn in einem System eine fehlerhafte Funktionalität beobachtet wird, kann ein QA-Manager mit der richtigen Dokumentation und Berichten leicht beurteilen, was die Arbeit für Entwickler beschleunigt, wo dies bei einem Projektmanager möglicherweise nicht der Fall ist. Ein Projektmanager kann in vielerlei Hinsicht unter dem Druck von Stakeholdern, Projektfristen und Entwicklungskosten stehen, die dafür möglicherweise übersteigen.

Dies wirkt sich negativ aus und kann bestimmte Probleme verursachen, einschließlich, aber nicht beschränkt auf die Demoralisierung des verantwortlichen Entwicklers. Diese Probleme können anders in geeigneter Weise gehandhabt werden.

Projektmanager können mir widersprechen, aber es steht nicht im Kleingedruckten, dass der Fall jedes Projekts derselbe ist und dieselben Prinzipien angewendet werden können. Es ist besser, die allgemeinen Verfahren zu befolgen, bei denen es einen QA-Manager gibt, der sich um diese Dinge kümmert, und der PM sich auf seine/ihre Bedenken konzentrieren kann, um Probleme zu minimieren oder zu mildern, die später im Projekt auftreten könnten.

So profitieren Teammitglieder von einer erfolgreichen Qualitätssicherung – „Bessere Moral, mehr Enthusiasmus und weniger Frustration“.