डेवलपर प्रोडक्टिविटी मापते समय की जाने वाली गलतियाँ

 (thenewstack.io)
13 पॉइंट द्वारा ironlung 2024-02-21 | 12 टिप्पणियां | WhatsApp पर शेयर करें
  • डेवलपर प्रोडक्टिविटी मापते समय आम तौर पर की जाने वाली गलतियाँ
  • इनपुट मापने की समस्या
    • काम के घंटे जैसे इनपुट या प्रयास पर निर्भर रहने से गलत व्यवहार को बढ़ावा मिलता है
    • उदाहरण के लिए, अगर किसी कंपनी की संस्कृति स्क्रीन के सामने बिताए गए समय को महत्व देती है और उसी के लिए इनाम देती है, तो डेवलपर इसमें बहुत समय लगा सकते हैं, लेकिन काम की गुणवत्ता की गारंटी देना मुश्किल है
    • और भी कठोर माहौल में यह सबसे पहले दफ्तर आना और सबसे आख़िर में निकलना जैसी प्रतिस्पर्धा में बदल सकता है
  • आउटपुट मापने की समस्या
    • code lines या commits की संख्या जैसे सबसे खराब मेट्रिक्स इसी श्रेणी में आते हैं
    • डेवलपर बहुत तेज़ी से बड़ी मात्रा में code lines लिख सकते हैं, इसलिए इसे मापना आसान होता है
    • सभी आउटपुट मेट्रिक्स को संदर्भ के अनुसार समझना चाहिए
  • आउटकम और इम्पैक्ट मापने की समस्या
    • इन दोनों मेट्रिक्स की चुनौती यह समझना है कि DevOps team कितनी जिम्मेदार है
    • बिज़नेस revenue में बढ़ोतरी को मापते समय, इसे केवल डेवलपर्स की जिम्मेदारी मानना असंभव है

संबंधित पढ़ाई

12 टिप्पणियां

 
yangeok 2024-02-26

काफ़ी डराने वाला है। लगता है मैनेजर के नज़रिए और काम करने वाले लोगों के नज़रिए में फ़र्क होगा,,
 
nullvana 2024-02-24

लगता है यह ठीक वही हिस्सा है जहाँ LLM की ज़रूरत है।
 
savvykang 2024-02-22

क्योंकि इस लेख में कोई विकल्प प्रस्तुत नहीं किया गया है, इसलिए जो बात कहना चाही गई है उसका असर कुछ कम हो जाता है। मैं इस दावे से सहमत हूँ कि आउटपुट की मात्रा को परिणाम मापने से बाहर रखा जाना चाहिए, लेकिन इस बात से सहमत नहीं हो सकता कि काम के घंटों को इनपुट मापन से पूरी तरह हटा दिया जाए, क्योंकि यह वास्तविकता से मेल नहीं खाता। आखिरकार, ज्ञान-आधारित काम करते समय भी समय बीतता है, इसलिए मेरा मानना है कि निर्णय लेते समय समय को ज़रूर ध्यान में रखा जाना चाहिए.

मेरा मानना है कि 전체 진행률 = (충족 요구사항 수 / 근무시간) जैसे leading indicators को मापने के बाद डेवलपर productivity पर चर्चा करना समझने में आसान और अधिक प्रभावी होगा.
 
wonderer 2024-02-22

हाल के समय में मैं इस तरह के लेखों को थोड़ा आलोचनात्मक नज़रिए से देखने लगा हूँ, क्योंकि मुझे लगता है कि लोग आखिरकार ऐसे लेख पढ़कर यह निष्कर्ष निकालते हैं कि किसी भी तरह का management न करना ही बेहतर है। किसी भी metric से management किया जाए, अंततः लगभग वही समस्याएँ सामने आती हैं। साथ ही, जब किसी metric का उपयोग लोगों या टीमों के बीच competition या comparison के लिए किया जाता है, तो उसके side effects भी पैदा होते हैं। इसलिए केवल एक metric के आधार पर management नहीं करना चाहिए; एक-दूसरे की कमी पूरी करने वाले metrics को साथ में देखना ज़रूरी है। मेरा मानना है कि metrics का उपयोग इस तरह होना चाहिए कि वे टीम को खुद में सुधार करने में मदद दें।
 
vbmania 2024-02-22

क्या इसे meaningful unit वाले PR की संख्या से मापने के बारे में आपका क्या विचार है?
 
nin12 2024-02-22

वास्तव में, देश की एक बड़ी कंपनी में ऐसी जगहें भी हैं जहाँ प्रदर्शन को लिखी गई code की lines की संख्या से मापा जाता है, हू हू
 
sexycode 2024-02-22

हाहा, मैंने भी यह देखा है.
वह लगातार variable names बदलने वाले commits डाल रहा था.. हा
 
wonderer 2024-02-22

लगता है वहाँ code review होने का माहौल ही नहीं है?
 
sexycode 2024-02-22

lol, code reviewer को भी code review लेना पड़ता है
वे भी एक-दूसरे की ऐसे ही मदद कर रहे थे..
 
ddaemiri 2024-02-27

हाहाहा, अरे बाप रे...
 
bichi 2024-02-22

हेलो हेल वर्ल्ड ;)
 
neidn 2024-02-22

क्या यही वह LOC प्रोडक्टिविटी मापन है जिसके बारे में सिर्फ़ सुनते आए थे, lol