डेवलपर्स के लिए उद्देश्य निर्धारित करने के बावजूद, भले ही उद्देश्य काम न करें [बंद]


84

यह आमतौर पर स्वीकार किया जाता है कि सॉफ़्टवेयर डेवलपर्स के लिए औसत दर्जे का उद्देश्य निर्धारित करना काम नहीं करता है , क्योंकि उद्देश्यों पर बहुत अधिक ध्यान संगठनात्मक लक्ष्यों (तथाकथित " माप शिथिलता ") के लिए व्यवहार काउंटर को जन्म दे सकता है ।

हालांकि, मेरी कंपनी में, हमें सभी कर्मचारियों के लिए उद्देश्य निर्धारित करने की आवश्यकता है, और मानव संसाधन द्वारा उन्हें स्मार्ट बनाने के लिए प्रोत्साहित किया जाता है । अतीत में, मेरे साथी प्रथम-स्तरीय प्रबंधक (टीम लीड) और मैंने कई तरीकों की कोशिश की है:

  1. मापने योग्य उद्देश्य निर्धारित करें जो सामान्य नौकरी के लिए अतिरिक्त हैं, जैसे "प्रौद्योगिकी X पर प्रशिक्षण करें", "कोड Y के टुकड़े के लिए प्रलेखन बनाएं जिसे कोई नहीं समझता है" और इसी तरह। जब वार्षिक प्रदर्शन मूल्यांकन की बात आती है, तो रेट डेवलपर्स लिखित उद्देश्यों पर नहीं, बल्कि उनके सामान्य काम के अनमोल मूल्य के बारे में मेरी राय पर, क्योंकि वास्तव में कंपनी की परवाह है।
  2. "कार्य प्रबंधन प्रणाली द्वारा दर्ज" के रूप में किए गए "दिनों के काम", "कीड़े की संख्या", "जारी किए गए उत्पादन की संख्या" जैसे बहुत विशिष्ट उद्देश्यों को निर्धारित करें। इसने बेहतर "अंक" हासिल करने के लिए, बगों के फुलाए हुए अनुमानों और गलत वर्गीकरण का नेतृत्व किया। दिलचस्प बात यह है कि इस प्रणाली पर अत्यधिक स्कोरिंग करने वाले डेवलपर्स को भी यह पसंद नहीं आया, क्योंकि टीम के भीतर आंतरिक विश्वास क्षतिग्रस्त हो गया था और उन्हें हमेशा ऐसा नहीं लगता था कि वे अपने उच्च स्थान के हकदार थे।
  3. अस्पष्ट उद्देश्यों को सेट करें जो "अपने सामान्य काम को अच्छी तरह से करें"। जब वार्षिक मूल्यांकन की बात आती है, तो उनकी रेटिंग उद्देश्यों के खिलाफ प्रदर्शन को दर्शाती है, लेकिन उद्देश्य स्वयं औसत दर्जे का या प्राप्त करने योग्य नहीं है, जो कि पर आधारित है।

इनमें से कोई भी आदर्श नहीं है। यदि आप सॉफ्टवेयर डेवलपर्स के लिए अपनी प्रभावशीलता के खिलाफ सबूत के बावजूद सार्थक, औसत दर्जे का उद्देश्य बनाने की एक समान स्थिति में हैं, तो आपके लिए किस दृष्टिकोण ने सबसे अच्छा काम किया है?


संबंधित प्रश्न मैंने पाया कि समान बिंदु को काफी संबोधित नहीं करते हैं:


अद्यतन (१otes नवंबर २०० ९): मेरे प्रश्न के लिए १० अपवोट्स हैं, और उच्चतम-रेटेड उत्तरों में केवल ४ अपवोट्स हैं (जिनमें से प्रत्येक में से एक भी शामिल है)। मुझे लगता है कि यह हमें कुछ बताता है: शायद जोएल और अन्य सही हैं, और स्टैकओवरफ्लो का संयुक्त ज्ञान डेवलपर्स के लिए किसी भी बाध्यकारी, औसत दर्जे के उद्देश्यों के साथ नहीं आ सकता है जो उनके वास्तविक (अचूक) मूल्य को प्रतिकूल रूप से प्रभावित किए बिना प्राप्त नहीं किया जा सकता है। काम। यद्यपि कोशिश करने के लिए धन्यवाद!


16
मैं मुंबई पद्धति को पसंद करता हूं: "उर मोस्ट बेस्ट।"
रॉबर्ट एस।

3
बहुत सारे टूटे हुए लिंक।
crh225

लिंक टूटे हुए हैं
रोड्रिगो लेइटे

जवाबों:


21

किस दृष्टिकोण ने आपके लिए सबसे अच्छा काम किया है?

केवल एक उद्देश्य: एक कोड निरीक्षण / सहकर्मी की समीक्षा करें, मेरे साथ समीक्षक के रूप में, बगैर किसी कीड़े को ढूंढे या किसी अन्य आलोचना के, जो मुझे आपसे कुछ नया करने के लिए कह रहा है।

टिप्पणियाँ:

  • मैं नई हायर की क्षमता को जल्दी से समाप्त करने की क्षमता नहीं माप रहा था, और उन्हें प्रोत्साहित नहीं करता था: मैं चाहता था कि लोग अच्छी तरह से खत्म करना सीखें (क्योंकि अगर यह अच्छी तरह से समाप्त नहीं हुआ है, तो यह समाप्त नहीं हुआ है)
  • लोगों ने सीखा कि मैंने एक कोड समीक्षा में क्या देखा: तो यह एक सीखने का अवसर और गुणवत्ता नियंत्रण उपाय है, न कि केवल एक प्रबंधन उद्देश्य
  • मेरी टिप्पणियों में दो श्रेणियां होंगी:
    1. यह एक बग है: चेक करने से पहले आपको इसे ठीक करना होगा
    2. एक सुझाव के रूप में, मैंने ऐसा किया है
  • थोड़ी देर के बाद, किसी व्यक्ति के कोड की मेरी समीक्षा किसी भी "आइटम को ठीक करना" ढूंढना बंद कर देगी (जिस बिंदु पर मुझे उनके काम की समीक्षा करने की आवश्यकता नहीं होगी)।

धन्यवाद, मुझे यह पसंद है। जब मैं उनके कोड की समीक्षा करता हूं, तो मैं आमतौर पर चर नामकरण और कोड शैली जैसी गैर-जरूरी-लेकिन-की-लंबी-लंबी-महत्वपूर्ण-महत्वपूर्ण चीजों के बारे में बहुत अधिक गुदा हूं। इस तरह एक उद्देश्य उन्हें मेरी लाइनों के साथ और अधिक तेज़ी से सोचने के लिए प्रोत्साहित कर सकता है!
पॉल स्टीफेंसन

6
मुझे भी यह पसंद है, लेकिन यह विकास के एक निखरे हुए स्वरूप को जन्म दे सकता है, जहाँ हर कोई केवल निष्पक्ष रूप से सर्वोत्तम कोड के संभावित खर्च पर आपको खुश करने की कोशिश कर रहा है। आपके अपने दृष्टिकोण में कितने दोष हैं जो आपने वर्षों में तय किए हैं, आप कितने अनुमान लगाते हैं कि आप इस्त्री करेंगे?
एड गुनेस

1
मेरे लिए, परिवर्तनीय नामकरण और कोड शैली दूसरी श्रेणी में हैं; अगर शैली वास्तव में बहुत खराब है, उदाहरण के लिए, बहुत सारे अंतर उद्देश्यों के लिए एक चर का पुन: उपयोग करना, तो मैं कह सकता हूं "आपको इसे फिर से बनाना होगा क्योंकि यह मेरे लिए समीक्षा करने के लिए बहुत जटिल है, मैं 'निरीक्षण द्वारा' क्या यह सही है नहीं देख सकता" ।
क्रिस डब्ल्यूडब्ल्यू

हे, जाहिर है मुझे पता है कि क्या उद्देश्यपूर्ण है :-)। लेकिन हाँ, वे अधिक उपयोगी सामान करने के बजाय मेरे पागल विचित्र को प्रसन्न करने में समय बिता सकते हैं। मुझे लगता है कि नए डेवलपर्स के लिए यह बेहतर होगा कि वह अनुभवी पुराने हाथों की तुलना में बेहतर हो।
पॉल स्टीफेंसन

@ हेड: यह "ब्लिंकर्ड" और "मुझे खुश करने की कोशिश" के बारे में सच है, लेकिन उनके कोड को, निश्चित रूप से, क्यूए के ब्लैक बॉक्स सिस्टम परीक्षण को भी पास करना था। और, मेरा निर्णय यह है कि क्या मैं उनके कोड को बनाए रख सकता हूं या नहीं, यदि आवश्यक हो तो काफी उद्देश्यपूर्ण (न केवल व्यक्तिपरक) उपाय है, है ना?
क्रिस

14

व्यक्तिगत रूप से मैं दो प्रकार के उद्देश्य निर्धारित करने का प्रयास करता हूं:

  • व्यवसाय-केंद्रित उद्देश्य (यही कारण है कि हम सभी के बाद भुगतान कर रहे हैं)। उदाहरण के लिए, "1 जून 2009 तक पूरा प्रोजेक्ट एक्स")। इन उद्देश्यों को अक्सर टीम के कई सदस्यों में साझा किया जाता है (और वे इसके बारे में जानते हैं)। टीम परियोजना को जल्द लाकर या आवश्यक कार्यक्षमता को पार करके उद्देश्य को पार कर सकती है। व्यक्ति अधिक कार्यक्षमता उत्पन्न करके, उनके विरूद्ध कम बग या टीम के अन्य सदस्यों को कोचिंग या समर्थन देकर उद्देश्य को पार कर सकते हैं।

  • उदाहरण के लिए, व्यक्तिगत विकास के उद्देश्य, एक ऐसी परियोजना को पूरा करने के लिए जिसमें एक प्रौद्योगिकी शामिल है जिसे डेवलपर अपने कौशल सेट में जोड़ना चाहता है, उपयोगकर्ता के डोमेन को बेहतर ढंग से समझना, नेतृत्व अनुभव प्राप्त करना आदि।

मुझे लगता है कि यह महत्वपूर्ण है कि:

  • उद्देश्य स्मार्ट हैं
  • उद्देश्य व्यापार की जरूरतों के साथ गठबंधन कर रहे हैं
  • आप उद्देश्यों में "सामान्य कार्य" शामिल करते हैं, वास्तव में ये सबसे महत्वपूर्ण उद्देश्य हैं!
  • कर्मचारी के पास आपके द्वारा निर्धारित उद्देश्यों को पार करने का कुछ अवसर होता है

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


9

यह सब इस तथ्य पर उबलता है कि "प्रथम स्तर का प्रबंधन", और अधिकांश कोई भी प्रबंधन अपने कर्मचारियों को नहीं जानता है। वास्तविक योजना और विकास के लिए वास्तविक दिन का हिस्सा होने के बजाय, स्मार्ट जैसी चीजें पॉप अप होती हैं। यदि प्रबंधकों को उन लोगों के साथ अधिक समय बिताना था जो वास्तविक कार्य करते हैं, तो इसमें से किसी की भी आवश्यकता नहीं होगी।

व्यक्तिगत रूप से, मैं एक फुर्तीले वातावरण में काम करना पसंद करता हूं जहां यह स्पष्ट है कि डेवलपर्स उत्पादकता और गुणवत्ता जागरूकता के मामले में कौन प्रदर्शन करता है। एक सच्चे चुस्त दृष्टिकोण की आवश्यकता है कि न केवल डेवलपर्स, बल्कि डिजाइनर, परीक्षक, ग्राहकों और उत्पाद प्रबंधकों को इस प्रक्रिया में शामिल किया गया है। यह स्वाभाविक रूप से प्रबंधकों के दृष्टिकोण से बेहतर अंतर्दृष्टि की ओर जाता है।


1
मैं मूल रूप से एक टीम का नेतृत्व कर रहा हूं, और मैं वास्तविक दिन से लेकर दिन की योजना और विकास तक का हिस्सा हूं। मुझे यह भी लगता है कि प्रत्येक डेवलपर का प्रदर्शन स्तर "स्पष्ट" है, लेकिन यह मेरे व्यक्तिपरक राय है और यह उद्देश्यों के साथ फिट नहीं है, इसलिए वे व्यर्थ हो जाते हैं। बल्कि मैं उन्हें पूरी तरह से अनदेखा कर सकता था!
पॉल स्टीफेंसन

मुद्दा यह है कि आपको यहां कोई वैज्ञानिक माप नहीं मिल सकता है, इस प्रकार यह करने की कोशिश की जा रही है कि आप बर्बाद हैं और आपको अपना समय कहीं और बिताना चाहिए। martinfowler.com/bliki/CannotMeasureProductivity.html के पास इसके बारे में एक टुकड़ा है।
मार्टिन विकमैन

8

मापने योग्य उद्देश्य जो मैंने अब तक देखे हैं:

  • एक प्रमाण पत्र परीक्षा पास करें
  • अनुसंधान प्रौद्योगिकी एक्स और इसके बारे में एक प्रस्तुति पकड़ो
  • बिल्ड ब्रेकिंग परिवर्तनों की संख्या
  • आंतरिक ज्ञान प्रबंधन पर लिखे गए विकि लेखों की संख्या

कैसे अपने डेवलपर्स से सीधे पूछें कि क्या उनके पास व्यक्तिगत विकास के लिए कुछ विचार हैं जो तब उद्देश्यों के लिए इस्तेमाल किए जा सकते हैं?


1
बिल्ड को तोड़ने के अलावा सभी मेरे दृष्टिकोण 1 हैं: क्या होता है कि अच्छे डेवलपर्स का कहना है कि "मैं उस महत्वपूर्ण परियोजना को करने में बहुत व्यस्त था जो आपने मुझसे काम करने के लिए कहा था, इसलिए मैंने प्रस्तुति नहीं की या लेख नहीं लिखा"। मैं उन्हें इसके लिए दंडित नहीं कर सकता, इसलिए उद्देश्य निरर्थक हो जाते हैं।
पॉल स्टीफेंसन

1
ditto पॉल ने क्या कहा, और मुझे विकी लेख लिखने के रूप में कुछ के साथ समस्या होगी - क्या वे कोई अच्छे थे? वे अभी भी वहाँ हैं? संपादन योगदान के बारे में क्या? क्या इसके लिए उनके पास भी समय नहीं था?
अन्नकूट

8

डेवलपर्स के लिए उद्देश्य निर्धारित करने के बावजूद, भले ही वे काम न करें

यदि आपके डेवलपर्स काम नहीं करते हैं, तो शायद कुछ उद्देश्य सिर्फ वही हैं जो उन्हें कुछ प्रोत्साहन देने की आवश्यकता है? ;-)


3
हास्य के लिए +1: मुझे आश्चर्य है कि अगर यह अस्पष्ट था, लेकिन केवल तभी निर्णय लिया गया जब आप जानबूझकर गलत समझ गए थे :-)
पॉल स्टीफेंसन

2
ध्यान दें कि किसी ने शीर्षक बदल दिया है "भले ही वे (उद्देश्य) काम न करें"। मैंने तब से इसे कस लिया है, "हालांकि उद्देश्य काम नहीं करते हैं"। बस इस जवाब से भ्रमित किसी के लिए टिप्पणी जोड़ने!
पॉल स्टीफेंसन

7

"सुनिश्चित करें कि आपके कोड का कम से कम n% एक उपयुक्त इकाई परीक्षण द्वारा परीक्षण किया गया है" इसे साबित करने के लिए एक कवरेज टूल का उपयोग करें, और परीक्षण गुणवत्ता के लिए किसी और की समीक्षा करें।


1
"व्यायाम" को परिभाषित करें। यदि आपका बस कवरेज टूल्स का उपयोग कर रहा है, तो कोड को प्राप्त करना आसान है बिना वास्तव में इसका अभ्यास किए।
केंट बूआगार्ट

@Kent, मेरा मतलब था == निष्पादित करना। क्या आप इस बात का विस्तार कर सकते हैं कि निष्पादन कैसे नहीं हो रहा है और मैं ख़ुशी से अपने सुझाव को अपडेट करूंगा
एड गुनेस

ज़रूर। बस एक इकाई परीक्षण लिखें जो आपकी विधि को कॉल करता है लेकिन कॉल के परिणामों के बारे में कोई दावा नहीं करता है। आपने कोड निष्पादित किया है - इस प्रकार उच्च कोड कवरेज की उपज - वास्तव में यह साबित करने के बिना कार्यात्मक रूप से सही है।
कैंट बूगार्ट

धन्यवाद, ऐसा कुछ काम करने योग्य हो सकता है, क्योंकि इकाई परीक्षण उनके विकास और रखरखाव के काम का अभिन्न अंग बन जाएगा। उद्देश्य को पूरा करने के लिए वैधता इकाई परीक्षण लिखने वाले लोगों के साथ समस्या हो सकती है, जब वे अधिक उपयोगी कार्य कर सकते हैं, हालांकि।
पॉल स्टीफेंसन

सहमत हूँ, वहाँ हमेशा किसी भी विशिष्ट माप के खेल के तरीके होने जा रहे हैं, जो ओपी बिंदु को मजबूत करता है।
एड गुनेस

4

मुझे लगता है कि सामने वाले बहुत विशिष्ट लक्ष्य, यानी, SMART (हो सकता है कि हम वास्तव में उसी स्थान पर काम करते हों), व्यवहार में एक अच्छे विचार की तरह लगता है, लेकिन यह अधिकांश टीमों के लिए बहुत व्यावहारिक नहीं है।

समस्या वास्तव में हमारे वृद्धिशील लक्ष्यों में परिवर्तन है। व्यवसाय में परिवर्तन होता है और डेवलपर्स के रूप में हमें उचित और उचित समय सीमा में प्रतिक्रिया और प्रतिक्रिया करने की आवश्यकता होती है।

संगठन में अपनी टीम या समूह के उद्देश्य के साथ टाई करने वाले लक्ष्यों पर विचार करें। यदि यह एक उद्देश्य - एक स्थूल उद्देश्य - आपकी टीम को वित्त पोषित नहीं किया जाएगा। सामूहिक लक्ष्य रखें जो आपकी पूरी टीम में मौजूद हों और जो व्यवसाय में संरेखित हों। लोगों को जिम्मेदारी दें और लोगों को जवाबदेह ठहराएं। उनकी सफलताओं और असफलताओं का जश्न मनाएं (यदि हम कभी-कभी विफल नहीं होते हैं तो हम संभवत: कोशिश नहीं कर रहे हैं और यही आप लोगों से चाहते हैं)। HTH


3

हमारे पास कई मैट्रिक्स हैं जो प्रोग्रामर के रूप में एकत्र किए जाते हैं, जैसे काम करते हैं:

  • एसएलओसी की संख्या बदल गई / जोड़ी गई
  • प्रक्रिया के विभिन्न चरणों में त्रुटियों / कीड़ों की संख्या (सहकर्मी की समीक्षा के बाद, सहकर्मी की समीक्षा, पोस्ट रिलीज़)
  • परिवर्तन अनुरोधों को पूरा / अस्वीकार किया गया
  • औपचारिक दस्तावेज़ (सॉफ़्टवेयर संस्करण विवरण, डिज़ाइन डॉक्स, आदि)

ये सभी tangibles हैं जो मुझे प्रबंधन और सॉफ्टवेयर गुणवत्ता आश्वासन के लिए प्रस्तुतियों में उपयोगी लगते हैं। लेकिन मैंने उन्हें कभी भी लोगों के प्रदर्शन के वास्तविक मूल्यांकन में बहुत उपयोगी नहीं पाया - जो आपके द्वारा सूचीबद्ध लिंक के कई बिंदुओं से बना है। मैंने पाया है कि जोएल के अंक यहाँ मान्य हैं - मैट्रिक्स कभी भी एक अच्छे टीम वातावरण को बढ़ावा नहीं देते हैं।

दुर्भाग्य से, हम सभी एक ऐसी दुनिया में रहते हैं, जहां मीट्रिक दूसरों (प्रबंधन, गुणवत्ता आश्वासन, ठेकेदारों से बाहर, आदि) की आवश्यकता होती है। मैंने पाया है कि एक बैलेंसिंग एक्ट की आवश्यकता है - उन मेट्रिक्स को प्रदान करना, लेकिन इन्टैंगिबल्स के साक्ष्य भी प्रदान करना - अमूर्त होना जो प्रत्येक प्रोग्रामर ने पूरा किया है जो आवश्यक रूप से ट्रैक नहीं किया गया है। उदाहरण के लिए, मेरे पास एक प्रोग्रामर था जिसने विरासत कोड की जांच में एक बड़ी राशि खर्च की जिसे कोई और नहीं छूना चाहता था। भले ही उस समय के लिए उनकी मीट्रिक कम थी, लेकिन यह प्रयास अमूल्य था।

इस तरह की चीजों को शामिल करने का एकमात्र तरीका एक अतिरिक्त अमूर्त श्रेणी के निर्माण के लिए धक्का देना और इसे अन्य मैट्रिक्स के साथ समान वजन देना है। आमतौर पर यह एक विशेष प्रोग्रामर के लिए संतुलन को स्विंग करने के लिए पर्याप्त है।


2

समस्याओं में से एक यह प्रतीत होगा कि एक विभाग / विभाग के रूप में आईटी संगठनों के पास औसत दर्जे का रणनीतिक लक्ष्य नहीं है। यदि उन्होंने ऐसा किया तो व्यक्तियों के लिए लक्ष्य निर्धारित करना आसान होगा।

उदाहरण के लिए, यदि उठाए गए समस्या टिकटों की संख्या को कम करने के लिए एक विभागीय पहल थी, तो, आप सॉफ्टवेयर से संबंधित टिकटों की संख्या के आधार पर एक व्यक्ति के लक्ष्यों को निर्धारित कर सकते हैं जिसे वे देखते हैं।

चूंकि सॉफ्टवेयर विकास बड़े पैमाने पर एक कोलाबेरेटिव है, इसलिए यह टीम स्तर पर लक्ष्य निर्धारित करने के लिए और अधिक समझदार होगा, और फिर टीम में योगदान के अनुसार व्यक्तियों को रेट करेगा।


1
टीम स्तर पर केवल लक्ष्य निर्धारित करने के लिए +1। प्रत्येक समस्या टिकट को एक व्यक्ति पर पिन करना डिमोटिविंग है, टीम भावना को नष्ट कर देता है और अक्सर वास्तविक स्थिति का एक तिरछा और गलत माप देता है, खासकर यदि संभावना समस्या टिकटों की संख्या काफी कम है (जैसे प्रति डेवलपर लगभग एक)।
पॉल स्टीफेंसन

1

एक उद्देश्य जो मुझे पसंद है वह है:

प्रोजेक्ट क्लाइंट से किसी प्रोजेक्ट में आपकी भागीदारी की सकारात्मक समीक्षा।

यह मदद करता है क्योंकि ग्राहकों (आंतरिक या बाहरी) से कुछ सकारात्मक प्रतिक्रिया प्राप्त करना हमेशा अच्छा होता है। यह मुश्किल नहीं है, इसकी प्रासंगिकता है और यह एक आसान है, लेकिन सूची में अर्थहीन टिक नहीं है।


क्या होगा अगर आप पूरे साल एक ही प्रोजेक्ट पर काम करते हैं जो ग्राहकों को नहीं भेजा गया है? 0 समीक्षाएँ। यदि आप किसी सामान्य वेबसाइट पर काम करते हैं जिसमें ग्राहकों की कोई सूची नहीं है?
jmucchiello

1
दोनों मामलों में आप अभी भी एक ऐसी परियोजना पर काम कर रहे हैं जिसमें ग्राहक हैं, चाहे वह आंतरिक हो या न हो। आप क्लाइंट के साथ अपनी भागीदारी की समीक्षा करने का अनुरोध कर रहे हैं, न कि परियोजना की समीक्षा करने के लिए।
नेट

1

व्यक्तिगत विकास को किस तरह से किया जा रहा है, इसका निर्धारण करना मेरे विचार में एक महत्वपूर्ण बिंदु है। डेवलपर्स के पास खुद को कमजोरियों का पता लगाने के लिए दूसरों पर प्रतिक्रिया देने के साथ विश्लेषण करना है जो कि सुधार हो सकता है और फिर इसे मापने का एक तरीका खोजने का एक तरीका हो सकता है। उदाहरण के लिए, मुझे लग सकता है कि मैंने शायद ही कभी दस्तावेज़ों को पूरा किया हो और इसलिए अपने उद्देश्यों पर मैं वर्ष के लिए यह कह सकता हूं कि मैं इसे सुधारना चाहता हूं और यह कि मेरे द्वारा उत्पादित प्रलेखन की मात्रा एक उपाय हो सकती है। यह काम कर सकता है या यह निर्भर करता है कि मैं वास्तव में इसका पालन कैसे करता हूं। एक ओर इस बात के लिए वैध चिंताएं हो सकती हैं कि मैं अपने काम में सुधार कैसे करूं और क्या उचित तरीके से देखा जा सकता है, जबकि एक निष्क्रिय आक्रामक या बचकाना दृश्य यह होगा कि अगर यह नहीं है, तो दस्तावेज़ीकरण का एक पहाड़ तैयार करना होगा।

एक प्रभावी डेवलपर को परिभाषित करना इसका एक और तत्व है। क्या यह वह व्यक्ति है जो बग को ठीक करता है? क्या नया काम जल्दी होता है? क्या नया काम परीक्षण और प्रलेखन के साथ पूरा होता है, भले ही यह जल्दी नहीं हुआ हो? "यह निर्भर करता है" के बाद से आप क्या प्रभावी बुला रहे हैं, मानक प्रतिक्रिया यहां स्पष्ट की जानी चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.