EngThrive: Make It Fast and Easy to Do Great Work
यह शोध पत्र EngThrive को प्रस्तुत करता है, जो माइक्रोसॉफ्ट में विकसित एक बहुआयामी मापन और सुधार प्रणाली है जो वेलबीइंग (wellbeing) को प्राथमिकता देते हुए डेवलपर उत्पादकता को गति (Speed), सुगमता (Ease) और गुणवत्ता (Quality) के इर्द-गिर्द व्यवस्थित करती है, और मेट्रिक्स को वास्तविक परिणामों के साथ संरेखित करने के लिए टेलीमेट्री और सर्वेक्षणों के संयोजन का उपयोग करती है न कि केवल गतिविधि के।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल जहाज के कप्तान हैं। आपका लक्ष्य जहाज को जल्द से जल्द उसके गंतव्य तक पहुँचाना है। वर्षों से, आप सफलता को इस बात से माप रहे थे कि चालक दल ने कितनी बार पहिया घुमाया या पानी की कितनी बाल्टियाँ खाली कीं। आपने सोचा, "जितनी अधिक बाल्टियाँ खाली की गईं = जहाज उतना ही तेज़ चला।"
लेकिन फिर, आपने कुछ अजीब देखा। चालक दल पागलों की तरह पहिया घुमा रहा है और बड़ी तेजी से बाल्टियाँ खाली कर रहा है, फिर भी जहाज की गति नहीं बढ़ रही है। वास्तव में, चालक दल थक चुका है, क्रोधित है और जहाज छोड़कर भागने को तैयार है।
यही वह समस्या है जिसका सामना माइक्रोसॉफ्ट के इंजीनियरिंग लीडर्स ने किया था। उन्हें एहसास हुआ कि "गतिविधि" (जैसे कोड की लाइनें या पुल रिक्वेस्ट) को गिनना यह मापने का एक बुरा तरीका था कि उनके डेवलपर्स वास्तव में कितना शानदार काम कर रहे हैं।
यह पेपर EngThrive को पेश करता है, जो उत्पादकता को मापने का एक नया तरीका है जो सॉफ्टवेयर इंजीनियरिंग को एक फैक्ट्री असेंबली लाइन के बजाय एक जीवित पारिस्थितिकी तंत्र (ecosystem) की तरह मानता है। यहाँ इसका सरल विवरण दिया गया है कि यह कैसे काम करता है।
बड़ी गलती: गलत चीजों को गिनना
पेपर बताता है कि लंबे समय से, कंपनियों ने उत्पादकता को एक एकल संख्या से मापने की कोशिश की, जैसे कि "कोड की लाइनें" (Lines of Code)।
- जाल: यदि आप एक लेखक को शब्दों के आधार पर भुगतान करते हैं, तो वे अधिक भुगतान पाने के लिए लंबे, उबाऊ वाक्य लिखेंगे। यदि आप एक डेवलपर को कोड की लाइन के आधार पर भुगतान करते हैं, तो वे संख्या पूरी करने के लिए अव्यवस्थित, अक्षम कोड लिखेंगे।
- "रिमोट वर्क" विरोधाभास: महामारी के दौरान, माइक्रोसॉफ्ट ने देखा कि डेवलपर्स 20% अधिक कोड सबमिट कर रहे थे। पुराने गणित के अनुसार, हर कोई सुपरस्टार था। लेकिन जब उन्होंने डेवलपर्स से पूछा, "आप कैसा महसूस कर रहे हैं?" तो 7ables% ने कहा कि वे बर्नआउट (थकान/तनाव) का शिकार हैं। जहाज तेज़ चल रहा था, लेकिन चालक दल डूब रहा था।
समाधान: "स्पीड, ईज़, क्वालिटी" ट्रायड (तीन का समूह)
एक संख्या के बजाय, EngThrive एक तीन पैरों वाले स्टूल का उपयोग करता है। यदि एक पैर छोटा है, तो स्टूल गिर जाएगा। आपको खड़ा रहने के लिए तीनों की आवश्यकता है।
- स्पीड (द रेस - गति): यह केवल तेजी से टाइप करने के बारे में नहीं है। यह आइडिया-टू-कस्टमर (विचार से ग्राहक तक) के बारे में है।
- उपमा: इससे कोई फर्क नहीं पड़ता कि आप कार को कितनी तेजी से पेंट करते हैं यदि आपको पेंट आने के लिए तीन सप्ताह तक इंतजार करना पड़ता है या यदि मैनेजर बार-बार रंग बदल देता है। स्पीड का अर्थ है विचार आने से लेकर ग्राहक द्वारा वास्तव में उसका उपयोग करने तक का कुल समय मापना।
- ईज़ (द स्मूथ रोड - सुगमता): यह घर्षण (friction) को मापता है।
- उपमा: कल्पना कीजिए कि आप कार चला रहे हैं। यदि ब्रेक अटक जाते हैं, रेडियो खराब है, और आपको हर रेड लाइट पर कागजी कार्रवाई करनी पड़ती है, तो आप तेज़ नहीं चल पा रहे हैं भले ही इंजन शक्तिशाली हो। "ईज़" यह मापता है कि डेवलपर्स अपने टूल्स से लड़ने, मीटिंग्स का इंतजार करने, या टूटे हुए बिल्ड्स को ठीक करने में कितना समय बिताते हैं, बनाम वास्तव में नई चीजें बनाने में।
- क्वालिटी (द ड्यूरेबिलिटी - गुणवत्ता): यह मापता है कि क्या काम टिकाऊ है।
- उपमा: यदि आप एक दिन में घर बनाते हैं (स्पीड) बिना किसी परेशानी के (ईज़), लेकिन हर बार बारिश होने पर छत टपकती है, तो आपने उत्पादकता नहीं दिखाई है। आपने बस भविष्य के लिए और अधिक काम पैदा कर दिया है। क्वालिटी यह मापती है कि चीजें कितनी बार टूटती हैं और उन्हें ठीक करने में कितना समय लगता है।
द गार्डरेल: "थ्राइविंग" (समृद्धि/उत्कर्ष)
यहाँ चौथा तत्व है जिसे Thriving कहा जाता है। यह कोई लक्ष्य नहीं है जिसे अधिकतम किया जाए; यह एक सुरक्षा गार्डरेल है।
- उपमा: कार के स्पीडोमीटर के बारे में सोचें। आप तेज़ जाने के लिए एक्सीलेटर को पूरा दबा सकते हैं, लेकिन यदि इंजन से धुआं निकलने लगे और ड्राइवर दर्द से चिल्ला रहा हो, तो आपको ब्रेक लगाना होगा।
- यदि कोई बदलाव टीम को तेज़ बनाता है लेकिन उन्हें दुखी (बर्नआउट, बुरे दिन) करता है, तो "थ्राइविंग" मेट्रिक अलार्म बजा देता है। पेपर में पाया गया कि नाखुश डेवलपर्स के उत्पादक न होने की संभावना 25 गुना अधिक होती है और उनके नौकरी छोड़ने की संभावना दोगुनी होती है। आप तेज़ जहाज नहीं बना सकते यदि चालक दल जहाज छोड़ दे।
वे इसे कैसे मापते हैं: "मिक्स्ड मेथड" (मिश्रित विधि)
EngThrive केवल कंप्यूटर लॉग (टेलीमेट्री) को नहीं देखता या केवल लोगों से यह नहीं पूछता कि वे कैसा महसूस करते हैं (सर्वेक्षण)। यह दोनों को जोड़ता है।
- टेलीमेट्री एक फिटनेस ट्रैकर की तरह है: यह बताता है कि क्या हुआ (जैसे: "आपने 4 घंटे मीटिंग में बिताए")।
- सर्वेक्षण व्यक्ति से पूछने जैसा है: "वह कैसा लगा?" (जैसे: "वे मीटिंग्स बेकार और निराशाजनक थीं")।
- साथ मिलकर, वे पूरी कहानी बताते हैं: "हमने 4 घंटे मीटिंग में बिताए, और यह समय की बर्बादी जैसा महसूस हुआ।"
पेपर से वास्तविक दुनिया के उदाहरण
पेपर तीन कहानियाँ साझा करता है कि माइक्रोसॉफ्ट में यह कैसे काम किया:
- "मीटिंग" फिक्स: एक टीम को एहसास हुआ कि डेवलपर्स मीटिंगों में डूब रहे थे। उन्होंने सभी को अधिक "फोकस टाइम" देने का लक्ष्य रखा।
- परिणाम: डेवलपर्स को प्रति सप्ताह 2 अतिरिक्त फोकस घंटे मिले। वे केवल तेज़ काम नहीं कर रहे थे; उन्होंने पुराने, टूटे हुए कोड (टेकीकल डेट) को भी ठीक किया जो उन्हें परेशान कर रहा था। परिणाम? कम "बुरे दिन" और वास्तविक आउटपुट में 13% की वृद्धि।
- "गेमिंग" प्रयोग: एक टीम ने "टाइम टू फर्स्ट पुल रिक्वेस्ट" (एक नया कर्मचारी कितनी जल्दी कोड सबमिट करता है) नामक मेट्रिक को "चीट" करने की कोशिश की, उन्हें पहले दिन ही एक छोटा, आसान कार्य देकर।
- परिणाम: आश्चर्यजनक रूप से, यह काम कर गया! भले ही उन्होंने मेट्रिक को "गेम" किया, लेकिन नए कर्मचारियों ने अधिक आत्मविश्वास महसूस किया, टूल्स को तेज़ी से सीखा, और अगले एक वर्ष में उन्होंने अधिक कोड लिखा। उस "गेम" ने सही व्यवहार को प्रेरित किया।
- "हेल्थ डेज़" प्रयोग: बर्नआउट संकट के दौरान, एक टीम ने सभी को दो अनियोजित छुट्टियां दीं।
- परिणाम: दो दिनों के लिए कोड आउटपुट गिर गया (स्पीड के लिए बुरा)। लेकिन बर्नआउट से राहत महीनों तक रही, और टीम ने केवल दो सप्ताह में सारा छूटा हुआ काम पूरा कर लिया। "थ्राइविंग" गार्डरेल के बिना, लीडर्स छुट्टियों को रद्द कर सकते थे क्योंकि वे पहले दिन "विफलता" के रूप में दिखाई देतीं।
AI के बारे में क्या?
पेपर का तर्क है कि AI केवल एक अन्य उपकरण है, जैसे एक नया हथौड़ा या एक तेज़ कार।
- AI लोगों को तेज़ी से कोड लिखने में मदद कर सकता है (गतिविधि), लेकिन EngThive पूछता है: क्या यह वास्तव में उत्पादों को ग्राहकों तक तेज़ी से पहुँचाता है (स्पीड)? क्या यह काम को कम निराशाजनक बनाता है (ईज़)? क्या यह चीज़ों को कम तोड़ता है (क्वालिटी)?
- यह फ्रेमवर्क AI के लिए भी उतना ही प्रभावी ढंग से काम करता है जितना कि ऑफिस बिल्डिंग, छुट्टियों की नीतियों या मीटिंग नियमों के लिए।
मुख्य निष्कर्ष (Takeaway)
आप किसी इंसान को एक एकल संख्या से नहीं माप सकते। EngThrive एक ऐसा सिस्टम है जो कहता है: "आइए इसे तेज़, आसान और उच्च गुणवत्ता वाला बनाएं ताकि महान काम किया जा सके, और आइए सुनिश्चित करें कि जो लोग काम कर रहे हैं वे इसे करते समय खुश और स्वस्थ भी रहें।"
यह कंपनियों को "आपने कितने लाइन कोड लिखे?" से हटाकर "हमने कितनी वैल्यू बनाई, और इसे बनाने में कैसा महसूस हुआ?" की ओर ले जाता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।