3.7 डेवलपर अनुभव सर्वेक्षण और DevEx मेट्रिक्स

अवलोकन और प्रेरणा

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

डेवलपर अनुभव (DevEx) वह व्यापक, अधिक हाल की फ़्रेमिंग है जो उसी मूल विचार के इर्द-गिर्द उभरी है जिसे SPACE ने औपचारिक बनाया: इंजीनियरों का वास्तविक, दिन-प्रतिदिन का काम पूरा करने का अनुभव, घर्षण, टूलिंग, संज्ञानात्मक भार, फ़ीडबैक लूप, स्वयं एक मापने योग्य, सुधारने योग्य चीज़ है, केवल एक नरम सांस्कृतिक चिंता नहीं। DevEx शोध, विशेष रूप से Abi Noda, Margaret-Anne Storey, Nicole Forsgren, और Michaela Greiler द्वारा प्रस्तावित फ्रेमवर्क, इस अनुभव को तीन आयामों के इर्द-गिर्द व्यवस्थित करता है: फ़ीडबैक लूप, संज्ञानात्मक भार, और फ़्लो स्थिति, जो इस भाग द्वारा पहले से गहराई से कवर किए गए SPACE आयामों पर बारीकी से मैप करते हैं और उनका विस्तार करते हैं।

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

प्रमुख सिद्धांत

सर्वेक्षण डिज़ाइन गुणवत्ता सर्वेक्षण लंबाई या परिष्कार से कहीं अधिक डेटा विश्वसनीयता निर्धारित करती है। एक संक्षिप्त, अच्छी तरह-डिज़ाइन किया गया सर्वेक्षण हर बार एक लंबे, बुरी तरह-डिज़ाइन किए गए सर्वेक्षण को हरा देता है।
प्रतिक्रिया दर स्वयं एक संकेत है, केवल एक डेटा-संग्रह मेट्रिक नहीं; एक गिरती दर अक्सर प्रक्रिया में क्षरित विश्वास का संकेत देती है।
जहाँ भी संभव हो सर्वेक्षण डेटा को वस्तुनिष्ठ इंस्ट्रूमेंटेशन के साथ जोड़ें, विषय 1.5 के इंस्ट्रूमेंटेशन सिद्धांत का पालन करते हुए; सर्वेक्षण डेटा का उपयोग विशेष रूप से उसके लिए करें जिसे वस्तुनिष्ठ डेटा कैप्चर नहीं कर सकता।
उत्तरदाताओं के साथ लूप बंद करें। एक सर्वेक्षण जो कभी दृश्यमान रूप से किसी परिवर्तन की ओर नहीं ले जाता वह लोगों को इसे गंभीरता से लेना बंद करना सिखाता है।
DevEx और SPACE एक ही अंतर्निहित चिंता की पूरक फ़्रेमिंग हैं, चुनने के लिए प्रतिस्पर्धी फ्रेमवर्क नहीं।

सिफ़ारिशें

स्पष्टता के लिए प्रश्न डिज़ाइन करें और अग्रणी या दोहरी-नली वाली शब्दावली से बचें

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

सुसंगत प्रतिक्रिया पैमानों का उपयोग करें और व्यापक रोलआउट से पहले नए प्रश्नों को पायलट करें

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

प्रतिक्रिया दर को अपने आप में एक निदानात्मक संकेत मानें

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

सर्वेक्षण डेटा को वस्तुनिष्ठ DevEx इंस्ट्रूमेंटेशन के साथ जोड़ें

जहाँ वे मौजूद हैं वहाँ व्यक्तिपरक सर्वेक्षण प्रतिक्रियाओं को वस्तुनिष्ठ संकेतों के साथ जोड़ें: बिल्ड समय, टेस्ट सूट रन समय, स्थानीय विकास वातावरण सेटअप समय, और विषय 3.6 से फ़्लो-समय और रुकावट डेटा। “हमारा बिल्ड बहुत धीमा है” कहने वाली एक सर्वेक्षण प्रतिक्रिया वास्तविक मापे गए बिल्ड समय प्रवृत्ति के साथ जोड़ी जाने पर कहीं अधिक कार्रवाई योग्य हो जाती है, और यह संयोजन उन मामलों को पकड़ता है जहाँ धारणा और वस्तुनिष्ठ वास्तविकता किसी भी दिशा में भिन्न होती हैं, जो अपने आप में जाँच के योग्य है।

लूप बंद करें: परिणाम और दृश्यमान अनुवर्ती कार्रवाई प्रकाशित करें

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

समझौते: लाभ और हानि

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

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

अपनी टीम के साथ चर्चा करने के प्रश्न

क्या हमने कभी व्यापक रूप से रोल आउट करने से पहले एक नए सर्वेक्षण प्रश्न को एक छोटे समूह के साथ पायलट किया है, या नए प्रश्न सीधे पूर्ण सर्वेक्षण में जाते हैं? पायलट चरण को छोड़ना एक सामान्य तरीक़ा है जिससे अस्पष्ट या दोहरी-नली वाले प्रश्न किसी के शब्दावली को अस्पष्ट नोटिस करने से पहले एक पूर्ण डेटासेट को भ्रष्ट कर देते हैं।
पिछले कई सर्वेक्षण चक्रों में हमारी प्रतिक्रिया दर ने क्या किया है, और यदि गिरावट हुई तो क्या हमने इसकी जाँच की है? इस प्रवृत्ति को गुज़रते हुए नोट करने के लिए एक डेटा-संग्रह उपद्रव की बजाय चर्चा करने योग्य एक वास्तविक संकेत मानें।
क्या हम सर्वेक्षण डेटा को किसी वस्तुनिष्ठ इंस्ट्रूमेंटेशन के साथ जोड़ते हैं, या हमारी रिपोर्टिंग में व्यक्तिपरक धारणा पूरी तरह अपने दम पर खड़ी है? कम से कम एक ऐसी जगह की पहचान करें जहाँ एक सर्वेक्षण प्रश्न को वस्तुनिष्ठ डेटा, बिल्ड समय, डिप्लॉयमेंट फ़्रीक्वेंसी, के साथ जोड़ना परिणाम को अधिक कार्रवाई योग्य बना सकता है।
हमारे पिछले सर्वेक्षण चक्र के प्रत्यक्ष, दृश्यमान परिणाम के रूप में हमने कौन-सी ठोस कार्रवाई की है, और क्या हमने वह कार्रवाई उत्तरदाताओं को वापस संप्रेषित की? यदि ईमानदार उत्तर है “कुछ भी दृश्यमान नहीं,” तो वह अंतर संभवतः पहले से उपकरण में विश्वास को क्षरित कर रहा है, चाहे यह अभी तक प्रतिक्रिया दर में दिखा हो या नहीं।
क्या हमारे किसी वर्तमान सर्वेक्षण प्रश्न में अग्रणी या दोहरी-नली वाली शब्दावली है, और क्या हम नोटिस करेंगे यदि ऐसा था? एक समूह अभ्यास के रूप में अपने वास्तविक वर्तमान प्रश्नों की इस विशिष्ट परीक्षण के विरुद्ध समीक्षा करें।
जब दोनों असहमत लगते हैं तो हमारा DevEx या SPACE सर्वेक्षण डेटा वस्तुनिष्ठ संकेतों की तुलना में कैसा है, और वह असहमति हमें क्या बताती है? एक ऐसा मामला जहाँ धारणा और वस्तुनिष्ठ डेटा भिन्न होते हैं वह अक्सर एक ऐसे मामले से अधिक निदानात्मक रूप से मूल्यवान होता है जहाँ वे सहमत होते हैं, क्योंकि अंतर स्वयं सूचनात्मक है।

क्षेत्र दृष्टिकोण

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

छोटा व्यवसाय। एक संक्षिप्त, अनुकूलित प्रश्न सेट के साथ एक मुफ़्त या कम-लागत सर्वेक्षण उपकरण, चौथाई-वार्षिक रूप से चलाया गया, समर्पित सर्वेक्षण-डिज़ाइन विशेषज्ञता की आवश्यकता के बिना यहाँ अधिकांश मूल्य कैप्चर करता है। परिष्कार पर लूप-बंद-करने के अनुशासन को प्राथमिकता दें; यहाँ तक कि एक छोटी टीम भी एक संक्षिप्त सर्वेक्षण जो उजागर करता है उस पर दृश्यमान रूप से कार्य करने से लाभान्वित होती है।

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

सरकार। प्रतिक्रिया दर और विश्वास उन संगठनों में विशेष रूप से नाज़ुक हैं जहाँ स्टाफ़ पहले से इस बारे में सतर्क हो सकता है कि डेटा का आंतरिक रूप से कैसे उपयोग किया जाता है। पारदर्शी अनामिता गारंटी और दृश्यमान अनुवर्ती कार्रवाई में विशेष रूप से अति-निवेश करें उस विश्वास को बनाने के लिए जो एक ऐसे संदर्भ में एक ईमानदार प्रतिक्रिया दर को प्राप्त करने योग्य बनाता है जहाँ डेटा उपयोग के बारे में संशयवाद पहले से एक विशिष्ट निजी-क्षेत्र सेटिंग से अधिक चल रहा हो सकता है।

उदाहरण

एंटरप्राइज़। एक सॉफ़्टवेयर कंपनी के प्रारंभिक DevEx सर्वेक्षण में एक प्रश्न शामिल था जो इंजीनियरों से “टूलिंग और प्रक्रिया के साथ संतुष्टि” को रेट करने के लिए कहता था, एक दोहरी-नली वाला प्रश्न जिसने दो बहुत अलग चिंताओं को मिला दिया। जब संयुक्त स्कोर औसत दर्जे का वापस आया, तो नेतृत्व यह नहीं बता सका कि समस्या टूलिंग थी, प्रक्रिया थी, या दोनों, और प्रारंभिक उपचार प्रयासों ने दो चौथाइयों के लिए ग़लत क्षेत्र को लक्षित किया। एक बाद के संशोधन में प्रश्न को विभाजित करने से उजागर हुआ कि टूलिंग स्कोर वास्तव में मज़बूत था और प्रक्रिया स्कोर ख़राब था, निवेश को एक बोझिल रिलीज़-स्वीकृति प्रक्रिया को सरल बनाने की ओर पुनर्निर्देशित करते हुए, जिसने एक चौथाई के भीतर एक मापने योग्य संतुष्टि सुधार उत्पन्न किया, पहले के टूलिंग-केंद्रित प्रयास के विपरीत जिसने बहुत कम प्रभाव दिखाया था।

सरकार। एक राष्ट्रीय डिजिटल एजेंसी के पहले DevEx सर्वेक्षण की प्रतिक्रिया दर 30% से कम थी, और एक आंतरिक समीक्षा ने पाया कि स्टाफ़ व्यापक रूप से मानता था, जैसा कि सही निकला, कि व्यक्तिगत प्रबंधक देख सकते थे कि किसने जवाब दिया था और किसने नहीं, भले ही समग्र परिणाम गुमनाम होने वाले थे। एजेंसी सत्यापित अनामिता के साथ एक वास्तव में स्वतंत्र, तीसरे-पक्ष सर्वेक्षण प्लेटफ़ॉर्म पर चली गई, स्पष्ट रूप से और बार-बार परिवर्तन को संप्रेषित किया, और जवाब में लिए गए तीन ठोस कार्रवाइयों के साथ पिछले चक्र के परिणामों का एक स्पष्ट सारांश प्रकाशित किया। दो चक्रों के भीतर प्रतिक्रिया दर 70% से ऊपर बढ़ गई, और एजेंसी के नेतृत्व ने विशेष रूप से वास्तविक अनामिता और दृश्यमान अनुवर्ती कार्रवाई के संयोजन को उस कारण के रूप में श्रेय दिया जिसने उपकरण में विश्वास को बहाल किया।

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

स्तर 1, आरंभ: सर्वेक्षण प्रश्न तदर्थ और अनपायलट किए गए हैं, प्रतिक्रिया दर को एक संकेत के रूप में ट्रैक नहीं किया जाता, और परिणाम शायद ही कभी दृश्यमान कार्रवाई की ओर ले जाते हैं।
स्तर 2, विकास: कुछ सर्वेक्षण डिज़ाइन अनुशासन मौजूद है, लेकिन पायलटिंग असंगत है और उत्तरदाताओं के साथ लूप विश्वसनीय रूप से बंद नहीं होता।
स्तर 3, मानकीकरण: रोलआउट से पहले प्रश्नों को पायलट किया जाता है, प्रतिक्रिया दर को ट्रैक और जाँच की जाती है जब यह गिरती है, और परिणाम लगातार कम से कम एक ठोस अनुवर्ती कार्रवाई के साथ प्रकाशित किए जाते हैं।
स्तर 4, प्रबंधन: सर्वेक्षण डेटा को व्यवस्थित रूप से वस्तुनिष्ठ इंस्ट्रूमेंटेशन के साथ जोड़ा जाता है, और दोनों के बीच विचलन को एक निदानात्मक संकेत के रूप में सक्रिय रूप से जाँचा जाता है।
स्तर 5, संयोजन: संगठन के पास लगातार उच्च प्रतिक्रिया दरों, हर चक्र से प्रदर्शन योग्य दृश्यमान कार्रवाई, और डेटा को भ्रष्ट करने से पहले बुरी तरह डिज़ाइन किए गए प्रश्नों को पकड़ने और ठीक करने का एक ट्रैक रिकॉर्ड के साथ एक परिपक्व, विश्वसनीय, बहु-वर्षीय सर्वेक्षण कार्यक्रम है।

चर्चा के लिए विचार

क्या हमारे उपकरण में किसी वर्तमान सर्वेक्षण प्रश्न ने कभी किसी उत्तरदाता को भ्रमित या गुमराह किया है?
सर्वेक्षण डेटा के प्रत्यक्ष परिणाम के रूप में हमने अंतिम बार कौन-सी ठोस कार्रवाई की थी?
हमें कैसे पता चलेगा यदि हमारी अनामिता गारंटी टूट गई हो, यहाँ तक कि दुर्घटनावश भी?
हमारा सर्वेक्षण डेटा वस्तुनिष्ठ इंस्ट्रूमेंटेशन से कहाँ सहमत या असहमत है, और यह हमें क्या बताता है?
हमारी वर्तमान प्रतिक्रिया दर को दोगुना करने के लिए क्या लगेगा?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

Noda, Abi, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity,” ACM Queue (2023): फ़ीडबैक लूप, संज्ञानात्मक भार, और फ़्लो स्थिति का DevEx फ्रेमवर्क।
Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021)।
Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century, by Jeff Lawson (डेवलपर अनुभव में संगठनात्मक निवेश)।
Designing and Conducting Survey Research: A Comprehensive Guide, by Louis M. Rea and Richard A. Parker (DevEx उपकरणों पर लागू सामान्य सर्वेक्षण-डिज़ाइन कार्यप्रणाली)।