घोस्ट इंजीनियर की तलाश: डेवलपर का असली योगदान कैसे देखें

“घोस्ट इंजीनियर”—हर दस डेवलपरों में से एक लगभग कोई उपयोगी काम नहीं करता, बस खुद को बेहद व्यस्त दिखाने का नाटक बखूबी करता है। इसकी असली वजह—साथ में दूसरी नौकरी भी करना, बर्नआउट या केवल कामचोरी—लंबे समय तक मैनेजमेंट की नजर से छिपी रह सकती है। (2024 का Stanford अध्ययन: मूल थ्रेड)

डेवलपरों को अपनी परफॉर्मेंस पर चर्चा पसंद नहीं आती। इस पेशे के लंबे “सुनहरे दौर” के बाद इंडस्ट्री में एक साधारण सवाल पूछना लगभग वर्जित हो गया: क्या इंजीनियरिंग का नतीजा उस पर लगे समय और पैसे के लायक है? लेकिन घोस्ट इंजीनियरों से डेवलपर खुद भी उतने ही परेशान होते हैं—और आम तौर पर समस्या सबसे पहले मैनेजमेंट नहीं, टीम देखती है।

रूस में “चुगली” करने को लंबे समय से बुरा माना जाता है। इसलिए कई लोगों को समस्या पता हो सकती है, फिर भी कोई बोलना नहीं चाहता। दूसरे के झमेले में क्यों पड़ें? बात तभी खुलती है जब सब्र का बाँध पूरी तरह टूट चुका होता है।

लेकिन शायद उन घोस्ट इंजीनियरों को यूँ ही छोड़ देना चाहिए? आखिर कंपनी को थोड़े-से पैसे की कमी तो नहीं पड़ जाएगी।

पर असली पेच यहीं है…

जब मैं कम परफॉर्मेंस कहता हूँ, तो मेरा मतलब यह नहीं कि Alex पूरी मेहनत कर रहा है और Ben से 10% कम काम कर पा रहा है। मेरा मतलब कुछ और है: हर stand-up में पूरी टीम को एक नई दुखभरी कहानी सुननी पड़ती है—दूसरी टीम ने साथ नहीं दिया, ticket अस्पष्ट था, सितारे ठीक नहीं बैठे। लेकिन कल काम पक्का पूरा होगा। कसम से।

बस वह “कल” बीते कल और उससे एक दिन पहले भी आ चुका था—और अब एक परंपरा बन गया है।

टीम ऐसी बातें जल्दी पकड़ लेती है। जो लोग सच में काम का बोझ उठा रहे हैं, वे स्वाभाविक रूप से सोचने लगते हैं: अगर लंबी-चौड़ी कहानियाँ सुनाकर बिना किसी नतीजे के बचा जा सकता है, तो मैं खुद को क्यों थकाऊँ?

लेकिन समस्या दिखना काफी नहीं है। हाथ में आँकड़े और तथ्य न हों तो बातचीत जल्द ही बहस बन जाती है: टीम कहती है, “यह काम नहीं कर रहा”; डेवलपर जवाब देता है, “ये मुझे काम करने ही नहीं देते।” आम तौर पर जाँच तब तक शुरू नहीं होती जब तक सबका धैर्य खत्म न हो जाए और टीम मैनेजर से उस डेवलपर को बदलने को न कहे।

तभी लंबी प्रक्रिया शुरू होती है: तथ्य जुटाना, दोनों पक्षों को सुनना, feedback देना और हालात सुधरने के लिए समय देना। मेरे अनुभव में इसका सबसे आम अंत यह होता है कि घोस्ट किसी नए—और बेहद “खुशनसीब”—नियोक्ता के पास चला जाता है।

समस्या केवल यह नहीं कि एक व्यक्ति कम काम करता है। कंपनी दो बार कीमत चुकाती है: पहले उस काम की जो कभी पूरा नहीं होता, फिर सहकर्मियों और मैनेजरों के उस समय की जो दोबारा जाँचने, खाली जगह भरने और वजह समझने में जाता है। आखिर में कम परफॉर्म करने वाला केवल एक डेवलपर नहीं रहता। पूरी टीम की रफ्तार गिर जाती है।

क्या मैनेजर समस्या को पहले देख सकता है—असामान्यता पकड़ सकता है, संदर्भ पूछ सकता है और टीम का धैर्य खत्म होने तथा कंपनी का समय-पैसा डूबने से पहले जाँच कर सकता है?

काफी अनुभव हो तो कुछ खास व्यवहारिक पैटर्न से ऐसी स्थितियाँ पहले ही पहचानी जा सकती हैं:

• हर सफलता का श्रेय मेरा; हर असफलता आपकी गलती।
• काम शुरू होने से पहले ही उसके असफल होने के बहाने तैयार।
• योग्यता की कमी को जरूरत से ज्यादा बोलकर ढकना।
• समय के साथ खास तौर पर मैनेजर को “दोषी” ठहराया जाना।
• जो व्यक्ति सचमुच संघर्ष कर रहा हो, उसके उलट सीधा feedback मिलने के बाद भी व्यवहार में सुधार न आना।

लेकिन शक को एक डिजिटल निशान भी चाहिए।

आइए इंजीनियरिंग परफॉर्मेंस मापने के सबसे आम साधनों को देखें और समझें कि क्या वे घोस्ट को उजागर कर सकते हैं।

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

सॉफ्टवेयर इंजीनियरिंग को ही आँकने के लिए—पूरे बिजनेस या प्रोडक्ट को नहीं—मैं एक सरल त्रयी इस्तेमाल करता हूँ: गति, गुणवत्ता और मात्रा। DORA metrics गति बताते हैं; tests और defects गुणवत्ता बताते हैं। मात्रा कठिन है। इसी क्षेत्र पर सबसे कम काम हुआ है—और हम जिन घोस्ट को खोज रहे हैं, वे अक्सर यहीं छिपते हैं।

DORA: गति और release की विश्वसनीयता

DORA दिखाता है कि कोई टीम बदलावों को production तक कितनी जल्दी और भरोसेमंद तरीके से पहुँचाती है। मौजूदा मॉडल पाँच metrics इस्तेमाल करता है: commit से production तक का समय, deployment की आवृत्ति, विफलता पैदा करने वाले deployments का प्रतिशत, recovery का समय और बिना योजना के दोबारा किए गए काम का हिस्सा।

यह delivery process का अच्छा माप है, लेकिन व्यक्तिगत योगदान का नहीं। अगर एक व्यक्ति तीन लोगों का काम कर रहा हो और दूसरा टीम के कुल नतीजे के पीछे छिपा हो, तो DORA आपको नहीं बताएगा।

ये metrics KPI के लिए भी कमाल की सुविधाजनक हैं। जिस कंपनी में मैं काम करता था, वहाँ हम 2018 से इन्हें खूब “दुह” रहे थे—हर dashboard को सफलतापूर्वक हरा रखते हुए सभी को खुश रखा। मौजूदा DORA मॉडल।

Tests और defects: काम कितना अच्छा हुआ

तरीके अच्छी तरह स्थापित हैं और व्यवहार में काम करते हैं। Code review, tests और static analysis से गुणवत्ता नियंत्रित होती है; defects और incidents से उसके परिणाम देखे जाते हैं।

लेकिन ये संकेत मात्रा के बारे में कुछ नहीं बताते। एक छोटा-सा बेदाग patch सारे indicators को हरा कर देगा—और घोस्ट अदृश्य ही रहेगा।

Jira और story points: कितने tickets बंद हुए

Jira बंद tickets और story points दिखाता है, मगर अनुमान टीम खुद बनाती है। एक ही काम को 3 points या 13 points माना जा सकता है, 5 tickets में बाँटा जा सकता है या 1 में समेटा जा सकता है।

Story points planning में उपयोगी हैं, लेकिन व्यक्तिगत योगदान मापने के लिए भरोसेमंद नहीं। Points लक्ष्य बनते ही लोग काम की जगह points को optimize करने लगते हैं।

ये भी बड़े सुविधाजनक KPI हैं। केवल quality gates पार करने के लिए data भरा जाता है और tickets इधर-उधर किए जाते हैं। ढेर सारा बेकार manual काम।

Commits और कोड की पंक्तियाँ: संदर्भ के बिना तथ्य

Git टीम के अनुमान पर निर्भर नहीं है, इसलिए commits और lines गिनने का मन होता है। लेकिन पाँच commits एक छोटा patch हो सकते हैं, जबकि एक squash commit में पूरे हफ्ते का काम हो सकता है।

Formatting, generated code, copy करना और code को इधर-उधर ले जाना—सब line count बढ़ाते हैं, जबकि कोई मुश्किल fix केवल दस पंक्तियों का हो सकता है।

Swarmia, LinearB और Waydev: पूरा engineering system एक जगह

Swarmia, LinearB और Waydev Git, issue trackers और CI/CD को साथ लाते हैं। मैनेजर DORA metrics, review queues, बदलाव का lead time और survey results देख सकते हैं।

ये engineering system की उपयोगी तस्वीर देते हैं—और अक्सर दिखाते हैं कि समस्या व्यक्ति में नहीं, process में है। मगर किसी डेवलपर के काम की मात्रा को तुलना योग्य पैमाने पर मापना वह मुख्य सवाल नहीं है जिसका ये platforms जवाब देना चाहते हैं। Swarmia, LinearB, Waydev।

GitClear: code noise हटाने के बाद क्या बचता है

GitClear जोड़े, एक जगह से दूसरी जगह ले जाए गए और copy किए गए code में फर्क करता है, generated files को हटाता है और यह भी देखता है कि नया code बाद में दोबारा लिखा या delete किया गया था या नहीं।

इससे Diff Delta बनता है—codebase में बचे सार्थक बदलावों के लिए GitClear की अपनी इकाई। Copy किया हुआ या जल्दी फेंक दिया गया code, production में लगातार चलने वाले छोटे लेकिन ठोस बदलाव से कम वजन रखता है। Diff Delta कैसे काम करता है।

Diff Delta यह नहीं बताता कि कितना काम करना पड़ा। वह बताता है कि noise और rework के बाद कितना सार्थक बदलाव बचा। GitClear की ताकत code के टिकाऊपन और गुणवत्ता मापने तथा AI के असर का विश्लेषण करने में है।

अब हम थोड़ा करीब हैं। सेवा benchmarks प्रकाशित करती है, लेकिन Diff Delta अपनी ही इकाई है: सही तुलना और methodology की समझ के बिना 10,000 जैसा आँकड़ा बहुत कम बताता है। “100% सामान्य है” जैसा कोई साफ आधार नहीं है। Diff Delta benchmarks।

BlueOptima: यही सवाल enterprise स्तर पर

मैं BlueOptima को प्रत्यक्ष अनुभव से जानता हूँ। मैंने 2019 में इस platform के साथ काम शुरू किया था। उसी अनुभव ने मुझे अपना product बनाने की प्रेरणा दी।

Coding Effort algorithm static metrics के एक समूह से source code के हर बदलाव का विश्लेषण करता है, उसके आकार, जटिलता और बाकी code से संबंध को ध्यान में रखता है, फिर नतीजे को घंटों में व्यक्त करता है।

इससे अलग-अलग teams और technology stacks के डेवलपरों की तुलना हो सकती है, global benchmark से भी। मेरे लिए यह पहला विश्वसनीय प्रयास था जो “इस डेवलपर ने कितनी lines लिखीं?” की जगह “इन बदलावों के पीछे कितना वास्तविक काम है?” का जवाब देता था। BlueOptima की methodology, global benchmark।

मेरे मामले में ये enterprise क्षमताएँ पाने के लिए काफी भारी rollout करना पड़ा: बंद network environment के अंदर agent deploy करना था, कीमत ऊँची थी और नतीजों की व्याख्या के लिए विशेषज्ञ चाहिए थे।

हजारों डेवलपर वाली कंपनी के लिए यह उचित हो सकता है। Startup या छोटी टीम के लिए शायद नहीं। यही अंतर बाद में DevGhost बनने की वजहों में से एक बना।

वही पैमाना, tender के बिना

जब मैंने DevGhost बनाया, तब मेरा लक्ष्य हर कल्पनीय engineering metric से भरा एक और all-in-one platform बनाना नहीं था।

मैं BlueOptima वाला ही जवाब चाहता था—बदलावों के पीछे कितना वास्तविक काम है—लेकिन ऐसे रूप में जिसे startup का मालिक या छोटी टीम tender, लंबे rollout या consultants की टीम के बिना इस्तेमाल कर सके।

तरीका सीधा है: DevGhost बदलावों का ही विश्लेषण करता है—क्या जोड़ा, हटाया और फिर से व्यवस्थित किया गया, और नतीजे को बनाना व जाँचना कितना कठिन था। Formatting, code moves, बड़े पैमाने पर automated replacements और generated code को वास्तविक काम से अलग किया जाता है।

नतीजा equivalent hours में दिया गया effort estimate है: codebase जानने वाले और AI के बिना काम करने वाले mid-level developer को वही code लिखने में कितना समय लगता। यह keyboard पर बिताया असली समय नहीं, न code की गुणवत्ता या business value का आकलन है। यह बदलावों की तुलना करने का साझा पैमाना है। DevGhost की methodology के बारे में और जानें।

Ghost% उस अनुमान की तुलना mid-level developer से अपेक्षित output से करता है और यह भी ध्यान रखता है कि व्यक्ति का कितना समय वास्तव में development में जाता है। 100% का नतीजा सामान्य स्तर के बराबर है। कम नतीजा वजह जाँचने का संकेत है; अधिक नतीजा अध्ययन करने और संभवतः best practice बनाने लायक है।

Benchmark जानबूझकर AI के बिना काम मानता है। DevGhost यह तय नहीं करता कि code का कोई हिस्सा इंसान ने लिखा, Copilot ने या autonomous agent ने। वह अंतिम बदलावों का मूल्यांकन करता है: AI के बिना mid-level developer को उन्हें बनाने और जाँचने में कितना प्रयास लगता।

इसलिए AI का असर metric के भीतर गायब नहीं होता, बल्कि दिखाई देता है। अगर किसी अवधि में डेवलपर ऐसा परिणाम बनाता और जाँचता है जिसमें पहले दो या तीन गुना प्रयास लगता, तो Ghost% उसे दिखाता है। Formatting, bulk generation और दूसरे code noise को वही असर पैदा नहीं करना चाहिए।

फैसला करने वाले का फैसला कौन करेगा?

सबसे साफ सवाल है: मशीन के बनाए अनुमान पर भरोसा क्यों करें? छोटा जवाब है—उस पर आँख बंद करके भरोसा नहीं करना चाहिए।

काम की कठिनाई का आकलन स्वभाव से व्यक्तिपरक है। हमने कई अनुभवी डेवलपरों से एक ही बदलावों का अनुमान लगवाया—और साफ तौर पर अलग-अलग आँकड़े मिले। हर व्यक्ति की रफ्तार, अनुभव और कठिनाई की समझ अलग है।

DevGhost भी गलत हो सकता है। उसकी बढ़त किसी पूर्ण सत्य तक पहुँच में नहीं है। बढ़त यह है कि हर बदलाव को एक ही पैमाने पर आँका जाता है—बिना पक्षपात, थकान या लेखक के बारे में पहले से बनी राय के।

इसीलिए Ghost% एक संकेत है, फैसला नहीं। कम नतीजा कमजोर योगदान बता सकता है, लेकिन team lead की जिम्मेदारियाँ, architecture का काम, mentoring, incidents या blockers भी उसकी वजह हो सकते हैं।

आँकड़ा बताता है कि सवाल कहाँ पूछना है। जवाब अब भी मैनेजर को ही खोजना होगा—लेकिन अब केवल intuition नहीं, एक स्वतंत्र second opinion भी साथ है।

“मुझे पहले से पता है कि मेरी टीम में कौन कैसा काम करता है”

DevGhost का एक ग्राहक तेजी से बढ़ती AI कंपनी का engineering leader है। शुरू में वह engineering performance मापने के विचार को लेकर ही संशय में था। उसकी बात सरल थी: अच्छा technical leader बिना dashboard के जानता है कि कौन कैसा काम कर रहा है।

हमने उस repository का इतिहास देखा जिसे वह अच्छी तरह जानता था। तीन डेवलपरों को लेकर पहले से संदेह था: उनके tickets धीरे बढ़ रहे थे, मगर वे अलग service पर थे, इसलिए बाकी टीम से तुलना कठिन थी। DevGhost ने लगभग छह महीने तक तीनों के नतीजे लगातार कम दिखाए।

बाद में जब वे डेवलपर कंपनी छोड़ने लगे, तब पता चला कि उस पूरे समय वे अपने products भी बना रहे थे। DevGhost वजह नहीं जान सकता था। उसने केवल वह चीज दिखाई जो commit count, pull requests और Slack की रोजमर्रा की बातचीत नहीं दिखा पाई: उनका काम अपेक्षा से स्पष्ट रूप से कम था।

लेकिन विश्लेषण firing list नहीं बना। दो अन्य डेवलपरों के लिए कम नतीजे से ठोस feedback देना, कारण समझना और performance सुधारना संभव हुआ। दोनों टीम में बने रहे।

जिन डेवलपरों को वह मजबूत मानता था, वे भी ठीक वहीं दिखे जहाँ उसे उम्मीद थी। अब केवल यह नहीं दिख रहा था कि कौन आगे है, बल्कि यह भी कि वह कितनी निरंतरता से आगे है।

बेशक, एक उदाहरण method की accuracy साबित नहीं करता। ग्राहक को इस बात ने चौंकाया कि पूरी तस्वीर उन बातों से कितनी अच्छी तरह मेल खाती थी जो पहले केवल अंदाज से पता थीं—और कुछ मामलों में पीछे मुड़कर देखने पर ही साफ हुई थीं।

अगर एक डेवलपर तीन लोगों जितना output दे तो?

घोस्ट की तलाश इस कहानी का सबसे ध्यान खींचने वाला हिस्सा है। लेकिन chart का ऊपरी हिस्सा शायद अधिक उपयोगी हो।

अगर कोई डेवलपर लगातार औसत से कई गुना output देता है, तो यह जानना चाहिए कि वह ऐसा कैसे करता है।

आज सवाल यह नहीं रहा कि डेवलपर AI इस्तेमाल करता है या नहीं—कई लोगों के लिए यह काम का सामान्य हिस्सा है। सवाल यह है कि वह agents को अतिरिक्त delivery capacity में कितनी कुशलता से बदलता है।

एक व्यक्ति autocomplete तक रुक जाता है। दूसरा agents को सही context देना, स्पष्ट नियम बनाना, कई tasks parallel चलाना और नतीजों की सावधानी से समीक्षा करना जानता है। इसलिए AI तक एक जैसी पहुँच भी productivity में बिल्कुल अलग बढ़त दे सकती है।

ऊँचा Ghost% उन डेवलपरों को पहचानने में मदद करता है जिनका इंसान-agent तालमेल पहले से अच्छा नतीजा दे रहा है—और यह समझने में कि बाकी टीम कौन-सी practices अपना सकती है।

अगर ऊँचे नतीजे की पुष्टि काम की गुणवत्ता और मैनेजर के आकलन से भी हो, तो ऐसे डेवलपर को महत्व देना, बनाए रखना और promotion के लिए सोचना चाहिए। उसकी practices को सीखकर पूरी टीम में फैलाना चाहिए।

पैमाने को हथियार मत बनाइए

हर metric का एक ही हश्र होता है: देर-सबेर कोई उसे KPI बनाने की कोशिश करता है। Ghost% इसके लिए नहीं बना।

Ghost% को team KPI बनाइए और लोग काम को उसके हिसाब से optimize करने लगेंगे। Leaderboard प्रकाशित कीजिए और भरोसा खत्म हो जाएगा। Score को नौकरी से निकालने का button बनाइए और गलतियाँ तय हैं।

मैं चार नियम तय करूँगा:

• एक माप या छोटी अवधि से निष्कर्ष न निकालें।
• व्यक्ति की भूमिका, development में लगने वाले समय का हिस्सा और code के बाहर का काम ध्यान में रखें।
• नतीजा डेवलपर को दिखाएँ और संदर्भ समझाने का मौका दें।
• रोज़गार संबंधी फैसले के लिए केवल Ghost% को आधार न बनाएँ।

अगर कम नतीजा लगातार बना रहे, तो मैनेजर को पहले वजह जाँचनी चाहिए। हो सकता है व्यक्ति सच में काम पूरा नहीं कर पा रहा हो। या वह architecture पर काम कर रहा हो, दूसरों के incidents संभाल रहा हो या team process में अटका हो।

अगर समस्या की पुष्टि हो, तो सुधार की स्पष्ट योजना और तय अवधि के बाद दोबारा आकलन होना चाहिए।

Metrics को नकारने से लोगों का मूल्यांकन खत्म नहीं होता। बस उसकी जगह अंदाज, stand-up में सुनाई गई कहानियाँ और मैनेजर की निजी पसंद रह जाती हैं।

गति, गुणवत्ता और मात्रा के लिए अलग साधन चाहिए। DORA दिखाता है कि बदलाव production तक कैसे पहुँचते हैं। Tests और defects गुणवत्ता दिखाते हैं। DevGhost code changes के पीछे लगे काम का अनुमान जोड़ता है।

इनमें से कोई metric मैनेजर की जगह फैसला नहीं ले सकता।

आँकड़े का मूल्य फैसला सुनाने में नहीं है। उसका मूल्य कठिन बातचीत को पहले—और तथ्यों के आधार पर—शुरू कराने में है।

आप डेवलपरों के काम की मात्रा कैसे आँकते हैं, और उपयोगी पारदर्शिता तथा निगरानी के बीच सीमा कहाँ खींचते हैं?