Mengapa PM tidak bisa menjadi QA yang sukses?

Seorang PM bisa menjadi QA secara teoritis. Karena seorang PM mengetahui proyek secara menyeluruh dan dapat memastikan semuanya berjalan sebagaimana mestinya. Tapi tidak praktis. Mengapa?

Di beberapa organisasi kecil, seorang manajer Proyek juga memakai topi seorang manajer QA. Yang merupakan peran yang saling bertentangan karena kedua peran ini berlawanan satu sama lain. Dalam praktiknya, manajer QA mengikuti beberapa SOP untuk menilai fungsionalitas pekerjaan perangkat lunak sebagaimana dimaksud dan setara dengan pengalaman pengguna secara keseluruhan. Setiap masalah yang ditemukan didokumentasikan dengan baik dan dikirim ke tim pengembangan untuk dikerjakan. Ini diulang sampai produk siap untuk pengguna akhir. Peran lain dari manajer QA adalah menyimpan catatan cacat yang diketahui dan mengujinya.

Sedangkan seorang PM lebih mengenal ruang lingkup produk. Seorang PM mengetahui persyaratan produk tidak seperti orang lain. PM harus menilai risiko yang tepat dan garis dasar biaya, mengelola sumber daya produk, berkomunikasi dengan pemangku kepentingan, dan mengikuti jadwal. Dan terakhir memimpin tim QA. Karena semakin banyak siklus berulang, semakin besar kemungkinannya melebihi garis dasar biaya.

Perbedaan utama antara Project/ product manager atau QA manager terletak pada penerapan pola pikir yang benar oleh seorang project manager. Seorang manajer proyek yang mengenakan topi manajer QA selalu berfokus pada penampilan proyeknya terlihat lebih pintar bahkan ketika hasil QA yang bertentangan diamati dalam prosesnya.

Saya yakin banyak manajer proyek yang melakukan peran ganda seperti ini akan menjamin fakta ini jauh di lubuk hati mereka meskipun mereka mungkin tidak mengungkapkannya di luar. Ini karena Manajer Proyek ingin menjadi Manajer Proyek, bukan manajer QA. Ketika Manajer Proyek yang ditunjuk bertindak sebagai manajer QA, secara psikologis mereka cenderung menjadi Manajer Proyek daripada manajer QA.

Ketika ada kegagalan fungsionalitas yang diamati dalam sistem, manajer QA dapat dengan mudah menilai dengan dokumentasi dan laporan yang tepat yang mempercepat pekerjaan pengembang di mana hal ini mungkin tidak terjadi pada manajer Proyek. Seorang manajer Proyek dapat berada di bawah banyak tekanan dari para pemangku kepentingan, tenggat waktu proyek dan biaya untuk pengembangan yang mungkin melebihi ini.

Ini memberikan dampak negatif dan dapat menyebabkan masalah tertentu termasuk tetapi tidak terbatas pada demoralisasi pengembang yang bertanggung jawab. Masalah-masalah ini dapat ditangani secara berbeda dengan cara yang lebih tepat.

Manajer proyek dapat tidak setuju dengan saya tetapi tidak tertulis dalam cetakan kecil bahwa setiap kasus proyek akan sama dan prinsip yang sama dapat diterapkan. Lebih baik mengikuti prosedur umum di mana ada manajer QA untuk menangani hal-hal ini dan PM dapat fokus pada kekhawatirannya untuk meminimalkan atau memitigasi masalah yang mungkin muncul nanti di proyek.

Beginilah cara anggota tim mendapat manfaat dari QA yang sukses — “Semangat Lebih Baik, Lebih Banyak Antusiasme, dan Lebih Sedikit Frustrasi”.