एक प्रधानमंत्री एक सफल QA क्यों नहीं हो सकता?

एक पीएम सैद्धांतिक रूप से क्यूए हो सकता है। क्योंकि एक पीएम परियोजना को अच्छी तरह से जानता है और चीजों को उस तरह से काम करने का आश्वासन दे सकता है जिस तरह से इसे करना चाहिए। लेकिन व्यावहारिक रूप से नहीं। क्यों?

कुछ छोटे संगठनों में, एक प्रोजेक्ट मैनेजर भी QA मैनेजर की टोपी पहनता है। जो एक परस्पर विरोधी भूमिका है क्योंकि ये दोनों भूमिकाएँ एक दूसरे के विपरीत हैं। व्यवहार में, क्यूए प्रबंधक कुछ एसओपी का पालन करता है ताकि सॉफ़्टवेयर कार्य की कार्यक्षमता का ठीक से मूल्यांकन किया जा सके और समग्र उपयोगकर्ता अनुभव के बराबर हो। पाई गई किसी भी समस्या को ठीक से प्रलेखित किया जाता है और विकास दल को काम करने के लिए भेजा जाता है। यह तब तक दोहराया जाता है जब तक कि उत्पाद एंड-यूज़र के लिए तैयार न हो जाए। क्यूए प्रबंधक की अन्य भूमिका ज्ञात दोषों के रिकॉर्ड को बनाए रखना और उनके लिए परीक्षण करना है।

जबकि एक पीएम उत्पाद के दायरे से ज्यादा परिचित होता है। एक पीएम उत्पाद की आवश्यकताओं को जानता है जैसे कोई और नहीं। पीएम को उचित जोखिम और लागत आधार रेखा का आकलन करना है, उत्पाद संसाधनों का प्रबंधन करना है, हितधारकों के साथ संवाद करना है और शेड्यूल में रहना है। और अंत में क्यूए टीम का नेतृत्व करें। क्योंकि चक्र जितना अधिक दोहराता है, लागत आधार रेखा से अधिक होने की संभावना उतनी ही अधिक होती है।

एक परियोजना/उत्पाद प्रबंधक या क्यूए प्रबंधक के बीच मुख्य अंतर एक परियोजना प्रबंधक द्वारा सही मानसिकता के अनुप्रयोग में निहित है। QA प्रबंधक की टोपी पहनने वाला एक प्रोजेक्ट मैनेजर हमेशा अपने प्रोजेक्ट की उपस्थिति पर ध्यान केंद्रित करता है, भले ही इस प्रक्रिया में परस्पर विरोधी QA परिणाम देखे गए हों।

मुझे यकीन है कि इस प्रकार की दोहरी भूमिका निभाने वाले कई परियोजना प्रबंधक अपने दिल की गहराई में इस तथ्य की पुष्टि करेंगे, भले ही वे बाहर व्यक्त न करें। ऐसा इसलिए है क्योंकि एक प्रोजेक्ट मैनेजर एक QA मैनेजर नहीं बल्कि एक प्रोजेक्ट मैनेजर बनना चाहता है। जब एक नामित परियोजना प्रबंधक क्यूए प्रबंधक के रूप में कार्य करता है, तो मनोवैज्ञानिक रूप से वे क्यूए प्रबंधक के बजाय एक परियोजना प्रबंधक बन जाते हैं।

जब किसी सिस्टम में विफल कार्यक्षमता देखी जाती है, तो एक QA प्रबंधक आसानी से उचित दस्तावेज़ीकरण और रिपोर्ट के साथ मूल्यांकन कर सकता है जो डेवलपर के लिए काम को गति देता है, जहां प्रोजेक्ट मैनेजर के मामले में ऐसा नहीं हो सकता है। एक परियोजना प्रबंधक हितधारकों, परियोजना की समय सीमा और विकास के लिए लागत के दबाव के कई प्रकार के दबाव में हो सकता है जो इसके लिए अधिक हो सकता है।

यह एक नकारात्मक प्रभाव डालता है और कुछ मुद्दों का कारण बन सकता है, जिसमें जिम्मेदार डेवलपर को हतोत्साहित करने तक सीमित नहीं है। इन मुद्दों को अलग तरीके से अधिक उचित तरीके से संभाला जा सकता है।

प्रोजेक्ट मैनेजर मुझसे असहमत हो सकते हैं लेकिन फाइन प्रिंट में यह नहीं लिखा है कि हर प्रोजेक्ट का मामला एक जैसा होगा और उसी सिद्धांत को लागू किया जा सकता है। सामान्य प्रक्रियाओं का पालन करना बेहतर होता है जहां इन चीजों को संभालने के लिए क्यूए प्रबंधक होता है और पीएम परियोजना पर बाद में दिखाई देने वाले मुद्दों को कम करने या कम करने के लिए अपनी चिंताओं पर ध्यान केंद्रित कर सकते हैं।

एक सफल क्यूए - "बेहतर मनोबल, अधिक उत्साह, और कम निराशा" से टीम के सदस्यों को इस तरह लाभ होता है।