दो साल पहले, मैंने सॉफ्टवेयर इंजीनियरों पर डेवलपर बर्नआउट के प्रभाव का अध्ययन किया था, जिसमें पाया गया कि । हाल के महीनों में, मैं विभिन्न संगठनों के लिए सॉफ्टवेयर विकास की धारणाओं पर आगे के शोध पर काम कर रहा हूं, जिसमें यह निष्कर्ष भी शामिल है कि 75% सॉफ्टवेयर इंजीनियरों को और 89% बिजनेस लीडर थे। । 83% बर्नआउट से पीड़ित थे पिछली बार गलत काम की सूचना देने पर प्रतिशोध का सामना करना पड़ा था इस बारे में चिंतित सॉफ्टवेयर की समय पर डिलीवरी Google की DORA टीम ने कई वर्षों तक सॉफ़्टवेयर इंजीनियरों का अपना सर्वेक्षण किया है और माप ढाँचे के मूल लेखकों ने अब SPACE और DevEx सहित अन्य ढाँचे तैयार किए हैं। जबकि मैंने मूल रूप से इन टीमों द्वारा किए गए शोध पर भरोसा किया था, जैसे-जैसे मैंने आगे शोध किया है, खामियां स्पष्ट हो गई हैं। छुट्टियों की अवधि में मैं डॉ. एंड्रयू जेनकिंसन की पुस्तक "व्हाई वी ईट (टू मच): द न्यू साइंस ऑफ एपेटाइट" पढ़ रहा हूं, पुस्तक में डॉ. जेनकिंसन डॉ. एन्सल कीज़ द्वारा सात देशों के अध्ययन के रूप में जाने जाने वाले एक अध्ययन की आलोचना करते हैं। डॉ. जेनकिंसन ने डॉ. कीज़ की सफलता का वर्णन इस प्रकार किया है: “उन्होंने अपने सबसे बड़े प्रतिद्वंद्वी पर तर्क जीत लिया था, उन्हें निर्विवाद तथ्यों के साथ पराजित किया था, उनके त्रुटिपूर्ण तर्क को उजागर किया था। भीड़ की प्रशंसा ने उसे खुशी और उल्लास से भर दिया। उनके जीवन का कार्य सफल हो गया था। उनके शोध के लिए धन आएगा, अपने क्षेत्र में अग्रणी वैज्ञानिक के रूप में उनकी प्रतिष्ठा वर्षों तक सुरक्षित रहेगी। प्रसिद्धि अच्छी थी, लेकिन अब उसने शीर्ष दो वास्तविक पुरस्कार - शक्ति और प्रभाव - हासिल कर लिए हैं। हालाँकि, डॉ. जेनकिंसन कहते हैं: “वह अपने शोध के बारे में बेईमान नहीं थे - यह अनैतिक होता और उन्हें बदनाम किया जाता। तकनीकी रूप से उन्होंने जो प्रस्तुत किया वह सत्य था। लेकिन वह अच्छी तरह जानते थे कि यह पूरा सच नहीं है।” जैसा कि मैंने DORA के अनुसंधान आउटपुट का अध्ययन किया है और बाद में और अधिक विस्तार से काम किया है, इस विवरण और DORA की स्टेट ऑफ़ DevOps रिपोर्ट और उसके बाद SPACE और DevEx ढांचे में अनुसंधान कठोरता के बीच समानताएं स्पष्ट हो गई हैं। डेटा कहां है? सबसे पहले, DORA अनुसंधान व्यक्तिपरक सर्वेक्षणों के उपयोग के माध्यम से कई हजारों डेवलपर्स का नमूना लेकर किया जाता है। यह शोध DORA टीम द्वारा इन-हाउस आयोजित किया जाता है। आमतौर पर, जो लोग आजीविका के लिए इस तरह के शोध करते हैं, वे मार्केट रिसर्च सोसाइटी (एमआरएस) और ब्रिटिश पोलिंग काउंसिल (बीपीसी) जैसे संगठनों में शामिल हो गए हैं ताकि यह सुनिश्चित किया जा सके कि जनता उन संगठनों द्वारा किए गए शोध पर भरोसा कर सके जो सदस्य हैं। उदाहरण के लिए; बीपीसी नियम अपने सदस्यों पर सख्त प्रकटीकरण नियम लागू करते हैं, जिसके लिए उन्हें शोध प्रकाशित होने के 2 कार्य दिवसों के भीतर पूछे गए प्रश्नों के साथ संपूर्ण डेटा तालिकाओं का खुलासा करने की आवश्यकता होती है। यहीं हमारी पहली समस्या है; DORA टीम अपना कच्चा डेटा प्रकाशित नहीं करती है, केवल अपनी स्टेट ऑफ़ DevOps रिपोर्ट प्रकाशित करती है। त्रुटिपूर्ण कार्यप्रणाली Google का DORA अनुसंधान, और टीम सेटिंग्स के भीतर उपयोग किए जाने वाले SPACE और DevEx फ्रेमवर्क, माप बनाने के लिए व्यक्तिपरक सर्वेक्षणों का उपयोग करते हैं। व्यक्तिपरक सर्वेक्षणों का उपयोग करते समय, यह सुनिश्चित करने के लिए कदम उठाना महत्वपूर्ण है कि पूर्वाग्रह काम में न आए। हालाँकि, DORA परिणामों को मापने के लिए चार प्रमुख मेट्रिक्स का उपयोग करता है - परिवर्तन लीड समय, परिनियोजन आवृत्ति, परिवर्तन विफलता दर और पुनर्प्राप्ति का समय (पूर्व में पुनर्प्राप्ति का औसत समय)। ये अनिवार्य रूप से नई सुविधाओं को तैनात करने की गति और मुद्दों को हल करने की गति के उपाय हैं। कल्पना कीजिए कि आपने कुछ लोगों से पूछा, "क्या आपके सहकर्मी बहुत सारी हरी सब्जियाँ खाते हैं?" और "क्या आपके सहकर्मी बहुत अधिक कसरत करते हैं?" जो लोग अपने कार्यस्थल के बारे में बेहतर महसूस करते हैं, उनके दोनों प्रश्नों के उत्तर "हां" में देने की संभावना अधिक होगी - इसका मतलब यह नहीं है कि अधिक हरी सब्जियां खाने से हमेशा जिम में उपस्थिति का स्तर बढ़ जाएगा। हालाँकि कोई सहसंबंध हो सकता है, हमने कोई कारण-और-प्रभाव संबंध नहीं बनाया है। डोरा अनुसंधान का तर्क है कि गति और विश्वसनीयता साथ-साथ चलती हैं, हालांकि, वे ऐसा परिणाम के उपायों के आधार पर करते हैं जो पूरी तरह से गति पर आधारित होते हैं। इसके अलावा, व्यक्तिपरक सर्वेक्षणों का उपयोग उन प्राप्तकर्ताओं को पूर्वाग्रहित कर सकता है जो अपने काम के बारे में बेहतर महसूस करते हैं और दोनों प्रश्नों का उत्तर "हां" में देते हैं। और जबकि जो कंपनियाँ अधिक सक्षम हैं वे अनिवार्य रूप से दोनों कारकों पर अधिक सक्षम हो सकती हैं, इससे कोई कारणात्मक संबंध नहीं बनता है। उदाहरण के लिए; इस बात पर विचार करें कि विमान में सॉफ़्टवेयर की कभी-कभार तैनाती की तुलना में विमानन सॉफ़्टवेयर की विश्वसनीयता को कितना उच्च माना जाता है। या इस बात पर विचार करें कि सॉफ्टवेयर विश्वसनीयता मामले "बुकआउट बनाम टोयोटा" में एक अनपेक्षित त्वरण बग, जिसके कारण मौतें हुईं, पर आंतरिक संचार में टोयोटा ने कैसे स्वीकार किया कि "वास्तव में, फेलसेफ जैसी तकनीक टोयोटा का हिस्सा नहीं है" इंजीनियरिंग प्रभाग का डीएनए"। या इस बात पर विचार करें कि कैसे होराइजन आईटी घोटाले के दौरान - कई आत्महत्याओं के लिए दोषी ठहराया गया और जिसे "ब्रिटेन के इतिहास में न्याय का सबसे व्यापक गर्भपात" के रूप में वर्णित किया गया है, एक गर्भवती महिला सहित गलत तरीके से कैद किए गए लोगों के साथ - सॉफ्टवेयर डेवलपर, फुजित्सु ने एक के उपयोग का बीड़ा उठाया। सॉफ्टवेयर विकसित करने की चुस्त कार्यप्रणाली, अर्थात् । तीव्र अनुप्रयोग विकास त्रुटिपूर्ण मापन परिणाम जैसा कि चर्चा की गई है, DORA अनुसंधान को चार प्रमुख मेट्रिक्स के आधार पर मापा गया है जो प्रदर्शन का मूल्यांकन करने के लिए नए कार्य को तैनात करने और बग को ठीक करने की गति का आकलन करते हैं। हालाँकि, ये मेट्रिक्स केवल उस हद तक मायने रखते हैं कि वे मापने के लिए उपयोगी परिणाम हैं। मैंने किया है और पाया है कि दोनों सहमत हैं कि गति सबसे कम महत्वपूर्ण कारक है। इसके बजाय, जनता डेटा सुरक्षा, डेटा सटीकता और गंभीर बग को रोकने के बारे में सबसे अधिक परवाह करती है। ऐसी परिकल्पना खोजना कठिन है जो चार प्रमुख मेट्रिक्स को इन परिणामों से जोड़ेगी, जिन्हें सॉफ्टवेयर डेवलपर्स और जनता सबसे महत्वपूर्ण कहती है - विशेष रूप से यह देखते हुए कि गंभीर बग को रोकना बग को तुरंत ठीक करने या तेजी से काम करने की तुलना में कम प्राथमिकता है। यहां तक कि डेटा सुरक्षा जैसे अन्य कारकों के लिए भी, यह देखना कठिन है कि ये चार प्रमुख मेट्रिक्स में से किसी से कैसे जुड़ते हैं। सॉफ्टवेयर इंजीनियरों और आम जनता के प्रतिनिधि नमूने (अनुसंधान फर्म सरवेशन के साथ) दोनों पर शोध यहां तक कि व्यावसायिक निर्णय लेने वालों के बीच भी, ऐसा लगता है कि समय पर डिलीवरी तेज डिलीवरी से ज्यादा मायने रखती है। जेएल पार्टनर्स के साथ मेरे द्वारा किए गए शोध के अनुसार, यूके में 98% ऐसे व्यावसायिक निर्णय-निर्माता और संयुक्त राज्य अमेरिका में 96% इस कथन से सहमत हैं कि "सॉफ्टवेयर इंजीनियरिंग टीम का लक्ष्य समय पर उच्च गुणवत्ता वाले सॉफ़्टवेयर वितरित करना है", साथ में यूके में 65% और अमेरिका में 62% दृढ़ता से सहमत हैं। अंत में; सरवेशन के साथ मैंने जो शोध किया, उसमें पाया गया कि सॉफ्टवेयर इंजीनियरों में विश्वास और जनता की विश्वसनीयता की अपेक्षाएं उद्योग से उद्योग में काफी भिन्न हो सकती हैं, जिसका अर्थ है कि इंजीनियरिंग काउंसिल यूके ने जो सुझाव दिया है, उसके पक्ष में एक आकार-फिट-सभी दृष्टिकोण को हतोत्साहित किया जाना चाहिए। : "एक निर्णय लेने का दृष्टिकोण अपनाएं जो जोखिम के अनुरूप हो और उनके संगठन की परिभाषित जोखिम भूख के अनुरूप हो"। जोखिम पर मार्गदर्शन पैसे का अनुगमन करो जैसे डॉ. कीज़ ने अपने शोध में चीनी उद्योग से धन प्राप्त किया - कई जांचों में, यह समझने के लिए कि प्रोत्साहन कहां है, पैसे का पालन करना महत्वपूर्ण है। DORA टीम ने मूल रूप से आईटी बुनियादी ढांचे को स्वचालित करने पर ध्यान केंद्रित करने वाली कंपनी पपेट के लिए स्टेट ऑफ डेवऑप्स रिपोर्ट करना शुरू किया और अब वे यह काम Google क्लाउड के लिए करते हैं। दोनों का इस बात में निहित स्वार्थ है कि डेवलपर्स जल्द से जल्द काम को तैनात करने में सक्षम हों। हालाँकि इसका मतलब यह नहीं है कि यह हमारी सभी समस्याओं का समाधान है। DORA ने प्रक्रिया में अनुभवजन्य मूल्यांकन की एक डिग्री जोड़ने में सॉफ्टवेयर इंजीनियरिंग की दुनिया में योगदान दिया है। हालाँकि, हमें पूरी सच्चाई के लिए भ्रमित करने वाली मार्केटिंग सामग्री से बचना चाहिए और ऐसे शोध में खामियों को पहचानना चाहिए।
