Почему PM не может быть успешным QA?

Теоретически PM может быть QA. Потому что PM знает проект досконально и может гарантировать, что все работает так, как должно. Но не практически. Почему?

В некоторых небольших организациях менеджер проекта также носит шляпу менеджера по обеспечению качества. Это противоречивая роль, поскольку эти две роли противоположны друг другу. На практике менеджер по обеспечению качества следует нескольким СОП, чтобы должным образом оценить функциональные возможности программного обеспечения, как задумано, и соответствует общему опыту пользователя. Любые обнаруженные проблемы должным образом документируются и отправляются команде разработчиков для работы. Это повторяется до тех пор, пока продукт не будет готов для конечного пользователя. Другая роль менеджера по контролю качества заключается в ведении записей об известных дефектах и ​​их тестировании.

В то время как PM больше знаком с областью применения продукта. PM как никто другой знает требования к продукту. PM должен правильно оценивать риски и базовые затраты, управлять ресурсами продукта, общаться с заинтересованными сторонами и соблюдать график. И, наконец, возглавить команду QA. Поскольку чем больше цикл повторяется, тем больше вероятность того, что он превысит базовый уровень затрат.

Основное различие между менеджером проекта/продукта или менеджером по обеспечению качества заключается в применении правильного мышления руководителем проекта. Менеджер проекта в шапке QA-менеджера всегда ориентируется на то, чтобы его проект выглядел умнее, даже когда в процессе наблюдаются противоречивые результаты QA.

Я уверен, что многие менеджеры проектов, выполняющие такую ​​двойную роль, подтвердят этот факт в глубине своего сердца, даже если они не будут выражать этого вовне. Это связано с тем, что менеджер проекта хочет быть менеджером проекта, а не менеджером по обеспечению качества. Когда назначенный менеджер проекта выступает в роли менеджера по обеспечению качества, психологически он склонен быть менеджером проекта, а не менеджером по обеспечению качества.

Когда в системе наблюдается сбой функциональности, менеджер по обеспечению качества может легко оценить с помощью надлежащей документации и отчетов, которые ускоряют работу разработчика, где этого может не быть в случае с менеджером проекта. Менеджер проекта может находиться под различным давлением со стороны заинтересованных сторон, крайних сроков проекта и затрат на разработку, которые могут быть превышены для этого.

Это оказывает негативное влияние и может вызвать определенные проблемы, включая, помимо прочего, деморализацию ответственного разработчика. Эти вопросы можно решить по-разному, более правильным образом.

Руководители проектов могут со мной не согласиться, но мелким шрифтом не написано, что каждый случай проекта будет одинаковым и могут применяться одни и те же принципы. Лучше следовать общим процедурам, когда есть менеджер по обеспечению качества, который занимается этими вопросами, а менеджер проекта может сосредоточиться на своих проблемах, чтобы свести к минимуму или смягчить проблемы, которые могут возникнуть позже в проекте.

Вот как члены команды получают пользу от успешного контроля качества: «Лучшее моральное состояние, больше энтузиазма и меньше разочарования».