💪🏼 🥚 ♂️ प्रेक्षक प्रभाव 👉🏿 👩🏿‍🎓 👝

यह पता लगाने के लिए कि क्या सूप नमकीन है, बस इसमें दो इलेक्ट्रोड गिराएं, और फिर उन पर वर्तमान डालें। यदि क्लोरीन की गंध दिखाई देती है, तो सूप पहले से ही नमकीन है :)

भौतिकी में, "पर्यवेक्षक प्रभाव" के रूप में एक ऐसी चीज है: यदि किसी सिस्टम पर एक अवलोकन किया जाता है, तो यह उसके व्यवहार में बदलाव करता है। यह प्रभाव विकास टीमों के काम के संगठन में बहुत दिलचस्प है (और वास्तव में किसी भी उत्पादन प्रक्रियाओं में)। जैसे ही हम किसी भी मीट्रिक को गिनना शुरू करते हैं, हम टीम और उसके व्यक्तिगत सदस्यों के व्यवहार में बदलाव करते हैं।

"कोई नुकसान नहीं"

प्रबंधन के दृष्टिकोण से, संख्यात्मक रूप से मापने के लिए (एक मीट्रिक परिचय), विचार, पहली नज़र में, बहुत मजबूत है। हम सटीक डेटा प्राप्त करते हैं और उनके आधार पर हम आवश्यक कार्रवाई करते हैं। लेकिन, दुर्भाग्य से, सब कुछ इतना सरल नहीं है: जैसे ही हम मीट्रिक का परिचय देते हैं, टीम का व्यवहार बदलना शुरू हो जाता है। टीम और उसके प्रत्येक सदस्य हमारे द्वारा पेश किए गए मीट्रिक के अनुकूल होने लगते हैं।

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

और फिर भी, विरोधाभासी रूप से, यह एक बहुत सटीक मीट्रिक है। एक टीम में दो प्रोग्रामर समान अवधि के लिए लगभग समान पंक्तियों को ठीक करते हैं। बेशक, आपको बहुत सारे सम्मेलनों (समान कार्यों, कोडिंग मानकों की उपलब्धता, उदाहरण के लिए, विधि की अधिकतम लंबाई, दोहराव की अनुपस्थिति, रीफैक्टरिंग, और इसी तरह) की आवश्यकता है, लेकिन फिर भी मीट्रिक काफी सटीक है ... आप इसे प्रदर्शन के अनुमान के रूप में उपयोग नहीं करते हैं।

आप हमारे उत्पाद में दोषों की संख्या को कम करने की कोशिश कर सकते हैं, जिसके लिए विचार करें कि प्रत्येक डेवलपर ने कितने बग बनाए। हम बोनस के साथ सर्वश्रेष्ठ डेवलपर्स को पुरस्कृत करेंगे, और सबसे खराब डेवलपर्स के लिए प्रतिबंध लागू होंगे। सब कुछ सरल और पारदर्शी है। लेकिन वास्तव में यह अलग तरीके से निकलेगा: डेवलपर्स प्रत्येक बग के लिए परीक्षकों के साथ बहस करेंगे, कार्यों को करने की पहल और अनिच्छा के परिणामस्वरूप एक जोखिम और जोखिम से बचने की इच्छा होगी ("कम काम, कम कीड़े")। जूलिया नेचवा द्वारा लिखित " इस विषय पर एक बहुत अच्छा विषय है: " वे एक प्रोग्रामर के साथ एक परीक्षक की तरह रहते हैं ।

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

क्या करें?

विश्लेषण करें कि माप टीम और उसके व्यक्तिगत सदस्यों के व्यवहार को कैसे प्रभावित कर सकता है। इसके अलावा, विश्लेषण को मुख्य रूप से गैर-स्पष्ट पहलुओं के बारे में किया जाना चाहिए जो तुरंत प्रकट नहीं हो सकते हैं। विचार करें कि कौन से मैट्रिक्स चर्चा के आधार के रूप में कार्य कर सकते हैं, उदाहरण के लिए, रेट्रोस्पेक्टिव में, यदि आप स्क्रैम का उपयोग करते हैं। हो सकता है कि किसी को वास्तव में आपके माप की आवश्यकता न हो और आप मापें, केवल इसलिए कि आप माप सकते हैं?

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

किसी भी अन्य नवाचारों की तरह, मेट्रिक्स की शुरुआत करते समय, डेमिंग चक्र: प्लान-डू-चेक-एक्ट का उपयोग करना बहुत अच्छा है, ताकि आपके पास टीम से प्रतिक्रिया प्राप्त करने और यदि आवश्यक हो तो बदलाव करने का अवसर हो।

प्रेक्षक प्रभाव

"कोई नुकसान नहीं"

क्या करें?

स्वादिष्ट लिंक

More articles: