डेवलपर प्रोडक्टिविटी को कैसे मापा जाए: Google, Notion आदि के वास्तविक उदाहरण
(newsletter.pragmaticengineer.com)- Google, LinkedIn, Peloton, Amplitude, Intercom, Notion, Postman आदि 17 टेक कंपनियाँ डेवलपर प्रोडक्टिविटी को कैसे मापती हैं, इसका गहन विश्लेषण
1. 17 टेक कंपनियों के डेवलपर प्रोडक्टिविटी मेट्रिक्स
- डेवलपर प्रोडक्टिविटी को मापना एक जटिल समस्या है, क्योंकि software engineering जैसे knowledge-based काम में "productive" होने का अर्थ ही अस्पष्ट है
- DevProd या DevEx टीम कहलाने वाली टीमें डेवलपर्स को high-quality software आसानी से deploy करने में मदद करती हैं
- इन टीमों को engineering टीमों की प्रोडक्टिविटी और रुकावटों को मापने, और यह ट्रैक करने के लिए कि उनका काम वास्तव में असर डाल रहा है या नहीं, डेवलपर प्रोडक्टिविटी मेट्रिक्स की आवश्यकता होती है
- इन कंपनियों में उपयोग किए जाने वाले डेवलपर प्रोडक्टिविटी मेट्रिक्स
- Ease of Delivery (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Experiment Velocity (Etsy)
- services/apps की stability (DoorDash)
- SPACE metrics (Microsoft)
- engineer per weekly focus time (Uber)
- कंपनी के आकार के आधार पर 4 श्रेणियाँ चुनी गईं
- Google : 100,000 से अधिक कर्मचारी
- LinkedIn : 10,000 से अधिक
- Peloton : 1,000 से अधिक और 10,000 से कम
- scale-ups (100 से अधिक और 1,000 से कम engineers): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice
2. Google का दृष्टिकोण
- Google को अक्सर डेवलपर प्रोडक्टिविटी मापन की best practice के रूप में उद्धृत किया जाता है, लेकिन यह भी कहा जाता है कि Google जितना निवेश अधिकतर कंपनियों के लिए दोहराना संभव नहीं है
- Google की Developer Intelligence टीम डेवलपर प्रोडक्टिविटी को मापने और लीडर्स को insights देने वाली एक विशेष टीम है
- Google का मानना है कि कोई एकल metric प्रोडक्टिविटी को कैप्चर नहीं कर सकता, इसलिए वह इसे Speed, Ease, Quality की तीन dimensions में देखता है
- Speed: code review पूरा होने में कितना समय लगता है?
- Ease: डेवलपर के लिए code review process से गुजरना कितना आसान या कठिन है?
- Quality: code review के माध्यम से मिली feedback की गुणवत्ता कितनी है?
- Google metrics की गणना में qualitative और quantitative दोनों प्रकार के measurements को मिलाता है
3. LinkedIn
- LinkedIn, Microsoft के भीतर स्वतंत्र रूप से संचालित होता है और 10,000 से अधिक कर्मचारियों को रोजगार देता है
- LinkedIn में Developer Insights टीम है, जो डेवलपर प्रोडक्टिविटी और satisfaction को मापती है और बाकी संगठन तक insights पहुँचाती है
- LinkedIn quarterly surveys, real-time feedback system, और system-based metrics का उपयोग करके metrics कैप्चर करता है
- Quarterly survey:
- Developer Insights टीम quarterly surveys के माध्यम से विभिन्न tools, processes और activities में डेवलपर experience का मूल्यांकन करती है
- survey में लगभग 30 प्रश्न होते हैं और डेवलपर लगभग 10 मिनट में जवाब दे सकता है
- surveys एक proprietary platform के माध्यम से दिए जाते हैं, जिसे Developer Insights टीम ने विकसित और प्रबंधित किया है, और real-time feedback व metrics system से एकत्र डेटा के आधार पर survey items को advanced customization और personalization किया जा सकता है
- Real-time feedback system:
- quarterly surveys के बीच feedback इकट्ठा करने के लिए LinkedIn ने एक real-time feedback system विकसित किया, जो डेवलपर के development tools में किए गए events और actions को track करता है और विशेष triggers के आधार पर targeted surveys भेजता है
- यह system smart throttling mechanism का उपयोग करता है ताकि डेवलपर्स पर feedback requests की बौछार न हो
- System-based metrics:
- LinkedIn system data का उपयोग करके metrics की गणना भी करता है, जिससे build time और deployment frequency जैसी चीज़ों के लिए high-precision measurements मिलते हैं
- Developer Insights टीम इस data को इकट्ठा करने और विश्लेषण करने के लिए एक global system maintain करती है, जिसे Developer Insights Hub या iHub कहा जाता है
- इस system के माध्यम से LinkedIn की सभी टीमें अपनी ज़रूरत के अनुसार custom dashboards और metrics बना सकती हैं
- Quarterly survey:
- LinkedIn qualitative और quantitative metrics दोनों पर विचार करता है
- Developer Net User Satisfaction (NSAT): यह मापता है कि LinkedIn के development systems के प्रति डेवलपर्स समग्र रूप से कितने संतुष्ट हैं। इसे quarterly मापा जाता है
- Developer Build Time (P50 और P90): development के दौरान local build पूरा होने की प्रतीक्षा में डेवलपर द्वारा बिताए गए समय को seconds में मापता है
- Code Reviewer Response Time (P50 और P90): code reviewer को author के प्रत्येक code review update का जवाब देने में लगने वाला समय (working hours के आधार पर) मापता है
- Post-Commit CI Speed (P50 और P90): प्रत्येक commit को continuous integration (CI) pipeline से गुजरने में लगने वाला समय minutes में मापता है
- CI Determinism: test flakiness का उल्टा विचार। इसका अर्थ है कि test suite का परिणाम error के बजाय valid result होने की कितनी संभावना है
- Deployment Success Rate: production environment में deployment कितनी बार सफल होता है, इसे मापता है
- Winsorized Means: outlier-heavy metrics में सुधार को पहचानने का तरीका। इसमें सबसे ऊँचे और सबसे नीचे के मानों को बीच के करीब के अंकों से बदलकर गणना की जाती है
- The Developer Experience Index: LinkedIn द्वारा टीमों को दिया जाने वाला एक विशेष metric। यह ऊपर सूचीबद्ध कई metrics पर आधारित composite score है
4. Peloton
- Peloton लगभग 3,000-4,000 कर्मचारियों वाली एक बड़ी कंपनी है, लेकिन LinkedIn से काफी छोटी है
- Peloton का measurement approach पहले डेवलपर experience survey के माध्यम से qualitative insights प्राप्त करने से शुरू हुआ, और बाद में इसे quantitative metrics के साथ इस्तेमाल किया गया
- Peloton Engagement, Velocity, Quality, Stability के चार प्रमुख क्षेत्रों पर ध्यान देकर प्रोडक्टिविटी को मापता है
- Engagement: डेवलपर satisfaction score
- Velocity: सभी नए कर्मचारियों के लिए पहले और 10वें PR तक का समय, lead time, deployment frequency
- Quality: 250 lines से कम वाले PR का अनुपात, line coverage, change failure rate
- Stability: service recovery time
- इन metrics के बड़े हिस्से को मापने वाला डेवलपर experience survey, Peloton की technical support और developer experience टीम द्वारा lead किया जाता है, जो product operations organization का हिस्सा है
- technical support और developer experience टीम survey results का विश्लेषण करने और उन्हें पूरे संगठन के लीडर्स के साथ साझा करने की जिम्मेदारी भी निभाती है
5. Scale-ups और छोटी कंपनियाँ
- Notion, Postman, Amplitude, GoodRx, Intercom, Lattice जैसी कई scale-up कंपनियाँ 100 से 1,000 engineers को रोजगार देती हैं
- ये कंपनियाँ "Moveable Metrics" पर ध्यान केंद्रित करती हैं
- moveable metrics वे metrics हैं जिन्हें डेवलपर प्रोडक्टिविटी टीम अपने काम से सकारात्मक या नकारात्मक रूप से "move" कर सकती है। ये डेवलपर प्रोडक्टिविटी टीम के लिए अपना प्रभाव दिखाने में उपयोगी होते हैं
- सामान्य metrics
- Ease of Delivery (moveable):
- अधिकतर कंपनियाँ यह मापती हैं कि डेवलपर्स को अपना काम करना कितना आसान या कठिन महसूस होता है; यह एक qualitative scale है
- कई DevProd leaders का कहना है कि उनकी टीम का लक्ष्य डेवलपर्स की ज़िंदगी आसान बनाना है, इसलिए वे इस metric को अपने काम का 'north star' मानते हैं
- चूँकि यह metric काफी हद तक बदला जा सकता है, इसलिए प्रभाव दिखाने के लिए भी उपयोगी है
- सैद्धांतिक दृष्टि से यह metric developer experience के मुख्य पहलुओं, जैसे cognitive load और feedback loops, को भी पकड़ता है
- Engagement
- engagement को track किया जाता है, जो यह मापता है कि डेवलपर्स अपने काम के प्रति कितनी रुचि और प्रेरणा महसूस करते हैं
- आमतौर पर HR engagement surveys में engagement मापा जाता है, लेकिन DevProd टीमें भी इसी कारण इस पर ध्यान देती हैं
- डेवलपर engagement और प्रोडक्टिविटी का गहरा संबंध है। जैसा कि कहा जाता है, "खुश डेवलपर ही प्रोडक्टिव डेवलपर होता है", इसलिए engagement को प्रोडक्टिविटी का संकेतक माना जा सकता है
- engagement measurement का असली लाभ यह है कि यह speed पर ज़ोर देने वाले अन्य metrics के साथ संतुलन बना सकता है। software को तेज़ी से deliver करना अच्छा है, लेकिन डेवलपर की खुशी की कीमत पर नहीं
- Time Loss (moveable)
- GoodRx और Postman average time loss पर ध्यान देते हैं
- इसे काम के वातावरण में मौजूद बाधाओं के कारण खोए गए डेवलपर समय के प्रतिशत के रूप में मापा जाता है
- यह metric Ease of Delivery की तरह ही है, क्योंकि यह ऐसा moveable metric देता है जिस पर developer teams के काम का सीधा प्रभाव पड़ सकता है
- इसका बड़ा लाभ यह है कि इसे लागत में बदला जा सकता है, इसलिए business leaders के लिए time loss को समझना आसान होता है
- उदाहरण के लिए, यदि $10 million engineering labor cost वाले संगठन में किसी initiative के जरिए time loss को 20% से 10% तक घटा दिया जाए, तो इससे $1 million की लागत बचत हो सकती है
- Change Failure Rate
- यह DORA (DevOps Research and Assessment) research program के चार प्रमुख metrics में से एक है
- Amplitude और Lattice सहित कई कंपनियाँ इसे top-level metric के रूप में track करती हैं
- DORA टीम change failure rate को इस प्रकार परिभाषित करती है:
"वह प्रतिशत जिसमें production या users के लिए release change के कारण service degradation (जैसे service outage या service impairment) होता है और बाद में remedial action की आवश्यकता पड़ती है (जैसे hotfix, rollback, fix forward, patch)"
- Ease of Delivery (moveable):
6. दिलचस्प निष्कर्ष
- DORA और SPACE metrics का चयनात्मक उपयोग होता है, और सभी कंपनियाँ qualitative व quantitative दोनों तरह के measurements का उपयोग करती हैं
- DORA : DevOps Research and Assessment
- SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
- "focus time" पर बहुत ज़ोर दिया जाता है, और Stripe व Uber ने "पर्याप्त focus time वाले दिनों की संख्या" और "engineer per weekly focus time" जैसे विशिष्ट metrics साझा किए हैं
- कुछ अनोखे metrics
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)
7. अपने metrics कैसे चुनें
- metrics चयन के मार्गदर्शन के लिए Google के Goals, Signals, Metrics (GSM) framework का उपयोग करना उपयोगी है
- पहले उस goal को परिभाषित करें जिसे आप हल करना चाहते हैं, फिर उन signals को खोजें जो बताएँ कि goal हासिल हुआ है, और उसके बाद उपयुक्त metrics चुनें
- Goal की परिभाषा
- Google: "डेवलपर्स को तेज़ी और आसानी से शानदार products deliver करने में सक्षम बनाना।"
- Slack: "हर engineer को seamless development environment देना।"
- Stripe: "software engineering को आसान बनाना।"
- goals से reverse-work करके top-level metrics परिभाषित करना
- डेवलपर्स के लिए software deliver करना कितना आसान है? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
- डेवलपर्स software को कितनी तेज़ी से deliver करते हैं? (Speed): Perceived Delivery Speed, Perceived Productivity
- deliver किए गए software की quality (Quality): Incident frequency, Perceived Software Quality
- Goal की परिभाषा
- यदि आप CTO, VPE, या engineering lead हैं
- सबसे अच्छी सलाह है "समस्या को फिर से फ्रेम करें (reframe the problem)"
- तीन buckets से metrics चुनें
- Business Impact
- अभी इसे बनाने की ज़रूरत क्यों है?
- यह project किस तरह revenue पैदा करता है या business goals को support करता है?
- क्या यह project सुचारु रूप से आगे बढ़ रहा है या इसमें देरी हो रही है?
- System Performance
- क्या engineering systems तेज़ और स्थिर हैं?
- क्या infrastructure सुरक्षित और अच्छी तरह maintain किया गया है?
- क्या users उन services से संतुष्ट हैं जिनका वे उपयोग करते हैं?
- Engineering Efficiency
- Business Impact
- qualitative और quantitative metrics का मिश्रण करके मापन करना सभी कंपनियों में एक सामान्य पैटर्न है
- विभिन्न कंपनियों द्वारा उपयोग किए गए measurement items से प्रेरणा लें
- हर कंपनी की priorities और engineering culture के अनुसार किन चीज़ों को प्राथमिकता से मापा जाता है, इसमें बड़ा अंतर होता है
1 टिप्पणियां
मैं McKinsey पर पिछली पोस्ट से ही इसमें रुचि रखता था, इसलिए इसका संक्षेप और रिमाइंडर के तौर पर आना अच्छा लगा।