Dlaczego PM nie może być udanym QA?

PM teoretycznie może być QA. Ponieważ PM dokładnie zna projekt i może zapewnić, że wszystko działa tak, jak powinno. Ale nie praktycznie. Czemu?

W nielicznych małych organizacjach kierownik projektu nosi również kapelusz kierownika kontroli jakości. Co jest sprzeczną rolą, ponieważ te dwie role są sobie przeciwne. W praktyce kierownik ds. kontroli jakości przestrzega kilku SPO, aby właściwie ocenić funkcjonalność oprogramowania zgodnie z zamierzeniami i jest na równi z ogólnym doświadczeniem użytkownika. Wszelkie wykryte problemy są odpowiednio dokumentowane i przesyłane do zespołu programistów w celu ich rozwiązania. Powtarza się to, aż produkt będzie gotowy dla użytkownika końcowego. Inną rolą kierownika kontroli jakości jest prowadzenie rejestrów znanych defektów i testowanie ich.

Podczas gdy PM jest bardziej zaznajomiony z zakresem produktu. PM zna wymagania produktu jak nikt inny. PM musi ocenić odpowiednie ryzyko i podstawę kosztów, zarządzać zasobami produktu, komunikować się z interesariuszami i trzymać się harmonogramu. I wreszcie poprowadź zespół kontroli jakości. Ponieważ cykl się powtarza, tym bardziej prawdopodobne jest przekroczenie linii bazowej kosztów.

Główna różnica między kierownikiem projektu/produktu a kierownikiem kontroli jakości polega na zastosowaniu właściwego sposobu myślenia przez kierownika projektu. Kierownik projektu w kapeluszu kierownika kontroli jakości zawsze koncentruje się na tym, aby jego projekt wyglądał mądrzej, nawet jeśli w procesie obserwuje się sprzeczne wyniki kontroli jakości.

Jestem pewien, że wielu kierowników projektów pełniących tego rodzaju podwójną rolę poręczy za ten fakt w głębi serca, nawet jeśli nie wyraża tego na zewnątrz. Dzieje się tak dlatego, że kierownik projektu chce być kierownikiem projektu, a nie kierownikiem kontroli jakości. Kiedy wyznaczony kierownik projektu działa jako kierownik ds. kontroli jakości, z psychologicznego punktu widzenia jest raczej kierownikiem projektu niż kierownikiem ds. kontroli jakości.

Gdy w systemie zostanie zauważona wadliwa funkcjonalność, kierownik ds. kontroli jakości może łatwo ocenić za pomocą odpowiedniej dokumentacji i raportów, co przyspiesza pracę programisty, podczas gdy w przypadku kierownika projektu może to nie mieć miejsca. Kierownik projektu może znajdować się pod różnego rodzaju presją ze strony interesariuszy, terminów projektu i kosztów rozwoju, które mogą być w tym przypadku przekraczające.

Ma to negatywny wpływ i może powodować pewne problemy, w tym między innymi demoralizację odpowiedzialnego programisty. Kwestie te można rozwiązać inaczej, w bardziej właściwy sposób.

Kierownicy projektów mogą się ze mną nie zgadzać, ale nie jest napisane drobnym drukiem, że każdy przypadek projektu będzie taki sam i że można zastosować te same zasady. Lepiej postępować zgodnie z ogólnymi procedurami, w których kierownik kontroli jakości zajmuje się tymi sprawami, a kierownik projektu może skupić się na swoich obawach, aby zminimalizować lub złagodzić problemy, które mogą pojawić się później w projekcie.

W ten sposób członkowie zespołu odnoszą korzyści z udanej kontroli jakości — „Lepsze morale, więcej entuzjazmu i mniej frustracji”.