Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners
यह अध्ययन व्यावहारिक सर्वेक्षणों और साक्षात्कारों के माध्यम से आवश्यकताओं के इंजीनियरों (requirements engineers) के सत्रह अवांछनीय गुणों को पहचानता है और उन्हें वर्गीकृत करता है—जो संचार, डोमेन ज्ञान, व्यक्तित्व और तकनीकी कौशल तक विस्तृत हैं—और पेशेवरों को उनके सहयोगात्मक अभ्यासों पर विचार करने और उनमें सुधार करने में मदद करने के लिए वैचारिक मानचित्र प्रदान करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि एक रिक्वायरमेंट्स इंजीनियर (Requirements Engineer) दो बहुत अलग समूहों के बीच खड़ा एक अनुवादक (translator) है: वे लोग जिनके पास एक समस्या है (हितधारक/stakeholders) और वे लोग जो उसका समाधान बनाते हैं (सॉफ्टवेयर टीम)। उनका काम पहले समूह के अस्पष्ट सपनों और जरूरतों को दूसरे समूह के लिए स्पष्ट, चरण-दर-चरण निर्देशों में बदलना है।
यह शोध पत्र एक "क्या न करें का यूजर मैनुअल" की तरह है। जबकि कई अध्ययन हमें बताते हैं कि एक महान अनुवादक कैसे बनता है, इस शोध ने एक अलग सवाल पूछा: "कौन सी विशिष्ट बुरी आदतें या लक्षण एक रिक्वायरमेंट्स इंजीनियर को उनके काम में विफल बनाते हैं?"
यहाँ उनके निष्कर्षों का सरल उपमाओं (analogies) का उपयोग करके विवरण दिया गया है:
जांच: विशेषज्ञों से पूछना
शोधकर्ताओं ने केवल अनुमान नहीं लगाया; वे बाहर गए और ब्राजील के 18 अनुभवी सॉफ्टवेयर पेशेवरों (जैसे प्रोजेक्ट मैनेजर और इंजीनियर) से बात की। उन्होंने इन विशेषज्ञों से एक रिक्वायरमेंट्स इंजीनियर को उनके काम में बेकार बनाने वाली शीर्ष पांच चीजों की सूची बनाने को कहा।
फिर उन्होंने इन 11 विशेषज्ञों का साक्षात्कार लिया ताकि पूरी कहानी समझ सकें: यह बुरा क्यों है? यह कैसे प्रकट होता है?
परिणाम: "बुरे लक्षणों" का मानचित्र
विशेषज्ञों ने 17 विशिष्ट बुरे लक्षणों की पहचान की। शोधकर्ताओं ने इन लक्षणों को चार मुख्य "बाल्टियों" या श्रेणियों में व्यवस्थित किया, जिससे एक दृश्य मानचित्र (पेपर में चित्र 1) बना जो दिखाता है कि वे एक-दूसरे से कैसे जुड़ते हैं।
इन चार बाल्टियों को एक पुल के ढहने के चार तरीकों के रूप में सोचें:
संचार संबंधी मुद्दे (टूटा हुआ वॉकी-टॉकी)
- समस्या: यह सबसे आम शिकायत थी। यह केवल बात करने के बारे में नहीं है; यह इस बारे में है कि वे कैसे बात करते हैं।
- उपमा: कल्पना कीजिए कि एक टीम एक घर बनाने की कोशिश कर रही है, लेकिन ब्लूप्रिंट संभालने वाला व्यक्ति पहेलियों में बोलता है, कभी फोन नहीं उठाता, या स्पष्टीकरण मांगने पर गुस्सा हो जाता है।
- मुख्य बुरे लक्षण: "संबंधों में कठिनाई" (काम करने में कठिन होना) और "संचार की कमी" (जानकारी साझा न करना)। पेपर नोट करता है कि यदि आप सही प्रश्न पूछना नहीं जानते हैं, तो आप अपने संबंधों और अपने संचार दोनों को तोड़ देते हैं।
डोमेन ज्ञान की कमी (विदेशी शहर में पर्यटक)
- समस्या: इंजीनियर उस व्यवसाय को नहीं समझता जिसके लिए वह काम कर रहा है।
- उपमा: कल्पना कीजिए कि एक शेफ को पारंपरिक इतालवी भोजन पकाने के लिए काम पर रखा गया है, लेकिन उसे पता ही नहीं है कि पास्ता क्या होता है या रेस्तरां कैसे काम करता है। वह कुछ स्वादिष्ट बना सकता है, लेकिन वह वह नहीं है जो ग्राहक ने ऑर्डर किया था।
- मुख्य बुरा लक्षण: "व्यावसायिक ज्ञान की कमी।" यदि इंजीनियर कंपनी के लक्ष्यों को नहीं समझता है, तो वह ग्राहक की जरूरतों को सही ढंग से अनुवादित नहीं कर सकता।
तकनीकी ज्ञान की कमी (बिना मानचित्र के ड्राइवर)
- समस्या: इंजीनियर को सॉफ्टवेयर की दुनिया के उपकरणों या नियमों का ज्ञान नहीं है।
- उपमा: यह एक टूर गाइड की तरह है जिसे उस देश की भाषा नहीं पता जहाँ वह जा रहा है या वहां की स्थानीय ट्रेनें कैसे चलती हैं। वे टीम का प्रभावी ढंग से मार्गदर्शन नहीं कर सकते क्योंकि वे इलाके को नहीं समझते।
- मुख्य बुरा लक्षण: सॉफ्टवेयर आवश्यकताओं के लिए आवश्यक विशिष्ट प्रथाओं या दस्तावेजों के बारे में जानकारी न होना।
व्यक्तित्व (तूफान का बादल)
- समस्या: इंजीनियर कैसे सोचता है, महसूस करता है और व्यवहार करता है।
- उपमा: एक ऐसे टीम सदस्य की कल्पना करें जो एक "तूफान के बादल" की तरह है—हमेशा बदलाव के प्रति प्रतिरोधी, नकारात्मक, या बातचीत करने में असंभव। भले ही वे तकनीकी चीजें जानते हों, उनका रवैया टीम के मूड को खराब कर देता है।
- मुख्य बुरा लक्षण: पेपर में "प्रभावशाली" (संभवतः अहंकारी या दिखावा करने वाला) जैसे लक्षणों का उल्लेख है, या एक कठोर व्यक्तित्व जो नए विचारों का विरोध करता है।
मुख्य निष्कर्ष
पेपर निष्कर्ष निकालता है कि एक अच्छा रिक्वायरमेंट्स इंजीनियर होना केवल स्मार्ट होने या कोड जानने के बारे में नहीं है। यह मुख्य रूप से इस बारे में है कि आप लोगों के साथ कैसे जुड़ते हैं।
- यह केवल "अच्छा बनाम बुरा" नहीं है: शोधकर्ताओं ने पाया कि होना "बुरा" केवल "अच्छे" का उल्टा नहीं है। उदाहरण के लिए, एक "अच्छा" इंजीनियर सक्रिय (proactive) होता है और अच्छी तरह से बातचीत करता है। एक "बुरा" इंजीनियर केवल "निष्क्रिय" नहीं होता; वह बदलाव के प्रति सक्रिय रूप से प्रतिरोधी या शत्रुतापूर्ण भी हो सकता है। ये व्यवहार के अलग-अलग आयाम हैं, न कि एक साधारण स्विच।
- एक प्रणालीगत मुद्दा: बुरे लक्षण केवल व्यक्तिगत दोष नहीं हैं; वे पूरे टीम की नींव में दरार की तरह हैं। यदि अनुवादक (इंजीनियर) संवाद नहीं कर सकता या व्यवसाय को नहीं समझ सकता, तो पूरा प्रोजेक्ट (घर) ढहने के जोखिम पर होता है।
संक्षेप में: यदि आप एक सफल सॉफ्टवेयर प्रोजेक्ट चाहते हैं, तो आपको एक ऐसे रिक्वायरमेंट्स इंजीनियर की आवश्यकता है जो एक बेहतरीन श्रोता हो, व्यवसाय की समझ रखता हो, तकनीकी नियमों को जानता हो, और जिसका व्यक्तित्व टीम को मिलकर काम करने में मदद करे, न कि उन्हें तोड़ने में।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।