Perché un PM non può essere un QA di successo?

Un PM può essere un QA in teoria. Perché un PM conosce a fondo il progetto e può garantire che le cose funzionino come dovrebbero. Ma non praticamente. Come mai?

In poche piccole organizzazioni, un project manager indossa anche il cappello di un QA manager. Che è un ruolo conflittuale in quanto questi due ruoli sono opposti l'uno all'altro. In pratica, il responsabile del controllo qualità segue poche SOP per valutare correttamente la funzionalità del lavoro del software come previsto ed è alla pari con l'esperienza complessiva dell'utente. Qualsiasi problema riscontrato viene adeguatamente documentato e inviato al team di sviluppo su cui lavorare. Questo viene ripetuto finché il prodotto non è pronto per l'utente finale. Altri ruoli di un responsabile del controllo qualità sono la conservazione dei registri dei difetti noti e il test per loro.

Mentre un PM ha più familiarità con l'ambito del prodotto. Un PM conosce i requisiti del prodotto come nessun altro. PM deve valutare i rischi adeguati e la linea di base dei costi, gestire le risorse del prodotto, comunicare con le parti interessate e rispettare i tempi. E infine guida il team QA. Perché più il ciclo si ripete più è probabile che superi la linea di base dei costi.

La principale differenza tra un Project/product manager o un QA manager risiede nell'applicazione della giusta mentalità da parte di un project manager. Un project manager che indossa il cappello di QA manager si concentra sempre sull'aspetto del suo progetto in modo più intelligente anche quando nel processo si osservano risultati di QA contrastanti.

Sono sicuro che molti project manager che svolgono questo tipo di doppio ruolo garantiranno questo fatto nel loro cuore nel profondo anche se potrebbero non esprimersi all'esterno. Questo perché un Project Manager vuole essere un Project Manager non un QA manager. Quando un Project Manager designato agisce come un QA manager, psicologicamente tende ad essere un Project Manager piuttosto che un QA manager.

Quando viene osservata una funzionalità difettosa in un sistema, un responsabile del controllo qualità può facilmente valutare con documentazione e rapporti adeguati che accelerano il lavoro per lo sviluppatore, laddove questo potrebbe non essere il caso di un project manager. Un project manager può essere sottoposto a molte pressioni da parte delle parti interessate, scadenza del progetto e costi per lo sviluppo che potrebbero essere eccessivi per questo.

Ciò ha un impatto negativo e può causare determinati problemi, tra cui, a titolo esemplificativo, la demoralizzazione dello sviluppatore responsabile. Questi problemi possono essere gestiti in modo diverso in modo più corretto.

I project manager possono non essere d'accordo con me, ma non è scritto nella stampa fine che il caso di ogni progetto sarà lo stesso e che si possano applicare gli stessi principi. È meglio seguire le procedure generali in cui c'è un responsabile QA per gestire queste cose e il PM può concentrarsi sulle sue preoccupazioni per minimizzare o mitigare i problemi che potrebbero apparire in seguito nel progetto.

Questo è il modo in cui i membri del team traggono vantaggio da un QA di successo: "Migliore morale, più entusiasmo e meno frustrazione".