Jira के बिना इंजीनियरिंग मेट्रिक्स
Jira के बिना भी जरूरी चीजें मापी जा सकती हैं। Git, CI और अपनी टीम के मौजूदा टूल्स से इंजीनियरिंग स्वास्थ्य ट्रैक करना सीखें।
By Ellis Keane · 2026-03-23
सबसे अच्छी इंजीनियरिंग विज़िबिलिटी पाने वाली छोटी टीमें अक्सर वही होती हैं जिन्होंने Jira के चाहे हुए मेट्रिक्स के पीछे भागना बंद कर दिया।
मुझे पता है, यह महज़ विरोध के लिए विरोध जैसा लगता है – और सच कहूँ तो शायद थोड़ा वैसा है भी। लेकिन मैंने करीब तीन साल तक ईमानदारी से स्प्रिंट बोर्ड मेंटेन किए, बैकलॉग रिफाइन किए, और उन टिकटों पर एस्टीमेट अपडेट किए जो उस सुबह Jira खोलने से पहले ही आधे हो चुके थे। हर दो हफ्ते हम एक कमरे में बैठते (ठीक है, Zoom था – 2023 की बात है) और एक वेलोसिटी चार्ट घूरते जो हमें वो सब कुछ नहीं बताता था जो हम आपस में बात करके पहले से जानते थे। Jira के बिना इंजीनियरिंग मेट्रिक्स कुछ ऐसा नहीं था जिसे मैंने ढूंढा। यह तब हुआ जब मैंने यह नाटक करना बंद कर दिया कि वेलोसिटी चार्ट मुझे कुछ काम का बता रहे हैं।
अगर आपकी टीम इतनी छोटी है कि एक मेज पर बैठ सके, तो आपको शायद Jira की जरूरत नहीं है यह जानने के लिए कि आप कैसे कर रहे हैं। आपको उन टूल्स से बेहतर सिग्नल चाहिए जो आप पहले से इस्तेमाल कर रहे हैं।
यह "Jira बुरा है" वाला लेख नहीं है। Jira उन संगठनों के लिए एक बढ़िया टूल है जिन्हें Jira-जैसे ट्रैकिंग की जरूरत है (और एक निश्चित स्केल पर वाकई में जरूरत होती है)। लेकिन अगर आप 10 से 40 लोगों की स्टार्टअप में इंजीनियरिंग मैनेजर हैं और केवल वेलोसिटी चार्ट बनाने के लिए Jira के लिए पैसे दे रहे हैं, तो यह थोड़ा ऐसे ही है जैसे लंच गर्म करने के लिए इंडस्ट्रियल ओवन खरीदना।
"केवल वेलोसिटी चार्ट बनाने के लिए Jira के लिए पैसे देना थोड़ा ऐसे ही है जैसे लंच गर्म करने के लिए इंडस्ट्रियल ओवन खरीदना।" attribution: Chris Calo
Jira मेट्रिक्स वास्तव में क्या मापते हैं
सीधे बात करें: ज्यादातर Jira मेट्रिक्स इंजीनियरिंग आउटपुट नहीं, बल्कि Jira के उपयोग को मापते हैं। स्टोरी पॉइंट्स टीम की स्टोरी पॉइंट एस्टीमेट करने की क्षमता मापते हैं। वेलोसिटी मापती है कि टीम कितनी लगातार स्प्रिंट को लगभग एक ही क्षमता तक भरती है। बर्नडाउन चार्ट मापते हैं कि गुरुवार की दोपहर को किसी ने बोर्ड पर टिकट खींचना याद किया या नहीं।
इनमें से कोई भी बिल्कुल बेकार नहीं है। लेकिन ये प्रोसेस मेट्रिक्स हैं जो डेवलपर प्रोडक्टिविटी मेट्रिक्स के रूप में छिपे हैं – और इन दोनों के बीच की खाई में ही इंजीनियरिंग मैनेजर भटक जाते हैं।
मैं खुद वो EM रहा हूँ जो एक स्टेकहोल्डर मीटिंग से पहले लगभग एक घंटा Jira डेटा को एक स्लाइड डेक में ढालने में बिताता था जो दिखाती थी "हम सही रास्ते पर हैं।" स्टेकहोल्डर सिर हिलाता, पिछले मंगलवार के लॉगिन बग के बारे में एक सवाल पूछता, और मीटिंग खत्म हो जाती। वो घंटा स्लाइड डेक के लिए था। असली जवाब था "इंजीनियर से पूछो।"
अगर आपके मेट्रिक्स उस काम से ज्यादा मेंटेनेंस मांगते हैं जो वे मापते हैं, तो मेट्रिक्स ही समस्या हैं।
Git से साइकल टाइम, टिकट बोर्ड से नहीं
छोटी प्रोडक्ट टीमों के लिए, साइकल टाइम आमतौर पर सबसे ज्यादा सिग्नल वाला मेट्रिक है जिसे आप ट्रैक कर सकते हैं। यह पहले कमिट से प्रोडक्शन डिप्लॉय तक की अवधि मापता है, और आप इसे पूरी तरह अपनी Git हिस्ट्री और CI पाइपलाइन से निकाल सकते हैं – टिकट बोर्ड की जरूरत नहीं।
कॉम्पोनेंट:
- पहला कमिट टाइमस्टैम्प किसी ब्रांच या PR पर
- PR मर्ज टाइमस्टैम्प
- डिप्लॉय टाइमस्टैम्प (आपके CI/CD से – GitHub Actions, CircleCI, या जो भी आप चला रहे हैं)
1 और 3 के बीच का डेल्टा आपका साइकल टाइम है। इसे सेगमेंट में तोड़ें – कोडिंग टाइम (1 से PR ओपन), रिव्यू टाइम (PR ओपन से मर्ज), और डिप्लॉय क्यू (मर्ज से प्रोडक्शन) – और आपके पास एक डायग्नोस्टिक होगा जो बताएगा कि काम वास्तव में कहाँ रुकता है।
जब मैंने पहली बार हमारी टीम के लिए यह किया, तो नंबर सच में चौंकाने वाले थे। मैंने मान लिया था कि रिव्यू टाइम हमारी बॉटलनेक है (सभी हमेशा यही मानते हैं, है ना?)। पता चला कि हमारी कोडिंग-टू-PR फेज ठीक थी, रिव्यू ठीक थे, और हम मर्ज से डिप्लॉय के बीच औसतन दो दिन गंवा रहे थे क्योंकि हमारा स्टेजिंग एनवायरनमेंट अस्थिर था और किसी ने इसे ठीक करने को प्रायोरिटी नहीं दी थी। वेलोसिटी चार्ट ने यह कभी नहीं दिखाया होता।
इसे कैसे मापें
अगर आप GitHub पर हैं, तो CLI से यह डेटा निकाल सकते हैं:
```bash
पिछले 30 दिनों की मर्ज की गई PRs लाएं
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
डिप्लॉय टाइमस्टैम्प के लिए, ज्यादातर CI सिस्टम API या वेबहुक के जरिए यह एक्सपोज़ करते हैं। PR मर्ज SHA को डिप्लॉय इवेंट से मैप करें, और आपके पास फेज के अनुसार साइकल टाइम होगा।
टिप: अगर आपका CI डिप्लॉय टाइमस्टैम्प साफ तरीके से एक्सपोज़ नहीं करता, तो एक बेहद आसान तरीका है एक Slack बॉट जो कमिट SHA के साथ #deploys चैनल में पोस्ट करता है। आपको टाइमस्टैम्प, एक ह्यूमन-रीडेबल लॉग और – साइड इफेक्ट के रूप में – एक चैनल मिलता है जो बताता है कि आप कितनी बार शिप करते हैं।
कोड रिव्यू थ्रूपुट
रिव्यू थ्रूपुट – प्रति इंजीनियर प्रति सप्ताह रिव्यू की गई PRs की संख्या, और PR खुलने से पहली रिव्यू तक का मीडियन टाइम – किसी भी स्प्रिंट मेट्रिक से ज्यादा टीम हेल्थ के बारे में बताता है। इसे अक्सर कम आंका जाता है।
क्यों? क्योंकि रिव्यू व्यवहार एक लीडिंग इंडिकेटर है। जब रिव्यू टाइम बढ़ता है, तो इसका आमतौर पर मतलब होता है कि इंजीनियर ओवरलोडेड हैं, बहुत ज्यादा कॉन्टेक्स्ट स्विचिंग कर रहे हैं, या – और यह असहज वाला है – एक-दूसरे के कोड से बच रहे हैं। इनमें से कोई भी बात दो हफ्ते बाद मिस्ड डेडलाइन के रूप में सामने आने से पहले जानने लायक है।
GitHub अपनी API के जरिए यह डेटा देता है। मुख्य फील्ड हैं PR पर createdAt और पहले रिव्यू इवेंट पर submittedAt।
जो नंबर मैं देखता हूँ वह है पहली रिव्यू तक मीडियन घंटे। कई छोटी टीमों में हमारे अनुभव से, स्वस्थ रिव्यू कैडेंस आमतौर पर लगभग 8 घंटे से नीचे रहती है। जब यह लगातार एक दिन से ज्यादा हो जाए, तो कुछ स्ट्रक्चरल बदल गया है – और जो भी है, Jira में अदृश्य है।
मीटिंग-टू-डिसीजन अनुपात
यह एक पारंपरिक इंजीनियरिंग मेट्रिक नहीं है, और मुझे स्पष्ट होना चाहिए: यह एक मोटी हेयुरिस्टिक है, KPI नहीं। लेकिन छोटी टीमों के लिए, मुझे यह हैरानी की हद तक खुलासा करने वाली लगती है।
इस हफ्ते आपकी टीम की मीटिंग गिनें। उनसे निकले ठोस फैसले गिनें (न कि "हमें X देखना चाहिए" – असली फैसले जिनके ओनर हों और नेक्स्ट स्टेप्स हों)। बाद वाले को पहले वाले से भाग दें।
अगर आधे से कम मीटिंग में कोई फैसला हुआ, तो यह पूछना उचित है कि क्या वे मीटिंग अपना समय सही कर रही हैं। कुछ मीटिंग रिस्क कम करने या कॉन्टेक्स्ट शेयर करने के लिए होती हैं, और यह सही है – हर चीज को रेज़ोल्यूशन के साथ खत्म होने की जरूरत नहीं। लेकिन जब आप इसे अनौपचारिक रूप से भी ट्रैक करना शुरू करते हैं (मैंने सचमुच अपनी नोटबुक में काउंट रखा था), तो आपको समझ आने लगता है कि कौन सी मीटिंग प्रोडक्टिव हैं और कौन सी केवल ऐसे रिचुअल हैं जिन पर किसी ने सवाल नहीं उठाया।
मैंने करीब एक महीने यह ट्रैक किया, और इसने किसी भी प्रोडक्टिविटी आर्टिकल से ज्यादा मेरी मीटिंग शेड्यूलिंग बदल दी। जब आप देख सकते हैं कि आपके सोमवार के स्टैंडअप ने तीन हफ्तों में ठीक शून्य फैसले दिए हैं, तो उसे कैंसिल करना रेडिकल नहीं लगता।
Jira के बिना इंजीनियरिंग मेट्रिक्स: एक हल्का-फुल्का डैशबोर्ड
आपको इसके लिए BI टूल की जरूरत नहीं। एक Notion पेज, Google Sheet, या चार नंबरों वाला एक साप्ताहिक Slack पोस्ट काफी है:
- मीडियन साइकल टाइम (Git/CI से) – क्या हम तेज़ या धीरे शिप कर रहे हैं?
- पहली रिव्यू तक मीडियन टाइम (GitHub से) – क्या टीम तुरंत रिव्यू कर रही है?
- डिप्लॉय फ्रीक्वेंसी (CI या #deploys चैनल से) – हम कितनी बार शिप कर रहे हैं?
- मीटिंग-टू-डिसीजन अनुपात (मैन्युअल काउंट) – क्या हमारी मीटिंग अपना समय सार्थक कर रही हैं?
चार नंबर, सभी मौजूदा टूल्स से निकाले जा सकते हैं, किसी के लिए भी Jira बोर्ड मेंटेन करने की जरूरत नहीं। हर हफ्ते अपडेट करें। अगर कोई नंबर दो हफ्ते लगातार गलत दिशा में जाए, तो जाँच करें। अगर स्थिर रहे, तो छोड़ दें।
मकसद सर्विलांस सिस्टम बनाना नहीं है (कृपया ऐसा मत करें – आपके इंजीनियर आपसे नफ़रत करेंगे, और उनका ऐसा करना सही होगा)। इंजीनियरिंग टीम विज़िबिलिटी काम से ही आनी चाहिए, लोगों से काम के बारे में रिपोर्ट मांगने से नहीं।
सबसे अच्छे इंजीनियरिंग मेट्रिक्स कम लागत में कलेक्ट होते हैं, मैनिपुलेट करना मुश्किल होता है, और कुछ ऐसा बताते हैं जिस पर आप एक्शन ले सकते हैं। स्टोरी पॉइंट्स तीनों मामलों में विफल हैं।
जब आपको वास्तव में टिकट बोर्ड की जरूरत होती है
मैंने कहा था यह "Jira बुरा है" लेख नहीं है, और मेरा यही मतलब था। कुछ ऐसी वैध परिस्थितियाँ हैं जहाँ प्रोजेक्ट मैनेजमेंट टूल के बिना मेट्रिक्स ट्रैक करना वास्तव में गैरजिम्मेदाराना हो जाता है:
- कम्प्लायंस-हेवी इंडस्ट्री जहाँ टास्क स्टेटस पर ऑडिट ट्रेल कानूनन जरूरी हैं
- बड़े इंजीनियरिंग ऑर्ग जहाँ क्रॉस-टीम डिपेंडेंसी अनौपचारिक समन्वय को अव्यावहारिक बना देती हैं
- डेडिकेटेड प्रोजेक्ट मैनेजमेंट फंक्शन वाले संगठन जिन्हें टीमों में एक canonical सत्य स्रोत चाहिए
अगर यह आपकी स्थिति है, तो Jira (या Linear, या Shortcut) सही विकल्प है। मेरा तर्क यह है कि छोटी टीमों के लिए केवल मेट्रिक्स के लिए एक भारी टूल मेंटेन करना एक बुरा ट्रेडऑफ है। आप अंततः टूल के काम के मॉडल के लिए ऑप्टिमाइज़ करते हैं, न कि अपनी टीम के असली काम के लिए।
और सच में? Jira इस्तेमाल करने वाली टीमें भी अपने बोर्ड डेटा को ऊपर बताए Git-बेस्ड मेट्रिक्स से सप्लीमेंट करके फायदा उठाएंगी। Jira बताता है कि लोग क्या कहते हैं कि वे कर रहे हैं। Git बताता है कि वे वास्तव में क्या कर रहे हैं। दोनों उपयोगी हैं, लेकिन केवल एक स्टेटस-अपडेट थिएटर से मुक्त है।
अगर आपकी स्टार्टअप में मेट्रिक्स का सवाल बार-बार उठता है, तो एक महीने के लिए चार-नंबर डैशबोर्ड आजमाएं। Jira के बिना इंजीनियरिंग मेट्रिक्स सेफ्टी नेट के बिना काम करने जैसा लग सकता है – लेकिन जब आप देखते हैं कि आपकी Git हिस्ट्री और CI पाइपलाइन में कितना सिग्नल है, तो आप सोचेंगे कि टिकट बोर्ड क्या जोड़ रहा था।
कस्टम स्क्रिप्ट या Jira बोर्ड के बिना – साइकल टाइम, रुकी हुई PRs और रिव्यू बॉटलनेक अपने आप सामने लाएं।
Q: क्या प्रोजेक्ट मैनेजमेंट टूल के बिना सार्थक इंजीनियरिंग मेट्रिक्स मिल सकते हैं? A: हाँ। साइकल टाइम (पहला कमिट से डिप्लॉय), रिव्यू थ्रूपुट और डिप्लॉय फ्रीक्वेंसी – ये सभी आपकी Git हिस्ट्री और CI पाइपलाइन में हैं। लगभग 40 से कम इंजीनियरों वाली टीमों के लिए ये आमतौर पर किसी भी टिकट बोर्ड से तेज़ और मैनिपुलेट करना मुश्किल होते हैं – और इनके सटीक रहने के लिए किसी को बोर्ड पर कार्ड खींचने की जरूरत नहीं।
Q: क्या Sugarbug इंजीनियरिंग मेट्रिक्स अपने आप दिखाता है? A: Sugarbug GitHub, Linear, Slack और कैलेंडर से जुड़कर आपकी टीम की एक्टिविटी का नॉलेज ग्राफ़ बनाता है। यह पैटर्न जैसे रुकी हुई PRs, रिव्यू बॉटलनेक और अनसुलझे फैसलों को फ़्लैग करता है – जो GitHub API के खिलाफ कस्टम स्क्रिप्ट लिखे और मेंटेन किए बिना यहाँ बताए कई सिग्नल कवर करता है।
Q: मेट्रिक्स के लिए Jira बंद करने की सहमति कैसे मिलेगी? A: इसे विद्रोह नहीं, एक प्रयोग के रूप में पेश करें। चार हफ्तों तक Git-बेस्ड मेट्रिक्स को मौजूदा Jira डैशबोर्ड के साथ चलाएं, फिर तुलना करें कि किन नंबरों ने असली बदलाव लाए। अगर Git मेट्रिक्स ज्यादा एक्शनेबल साबित हों (और हमारे अनुभव में, वे होते हैं), तो केस खुद बन जाता है।
Q: प्रोसेस मेट्रिक्स और परफॉर्मेंस मेट्रिक्स में क्या अंतर है? A: प्रोसेस मेट्रिक्स (स्टोरी पॉइंट्स, वेलोसिटी, बर्नडाउन) मापते हैं कि टीम वर्कफ़्लो कितनी नियमित रूप से फॉलो करती है। परफॉर्मेंस मेट्रिक्स (साइकल टाइम, डिप्लॉय फ्रीक्वेंसी, रिव्यू थ्रूपुट) मापते हैं कि टीम वास्तव में क्या और कितनी तेज़ी से डिलीवर करती है। छोटी टीमें लगभग हमेशा बाद वाले से ज्यादा सिग्नल पाती हैं, क्योंकि परफॉर्मेंस मेट्रिक्स मैन्युअल स्टेटस अपडेट से नहीं बल्कि काम से ही निकलते हैं।