अनुभव और ज्ञान किसी भी मूल्यांकन का आधार है

मैंने लेख पढ़ा " डेडलाइन का आकलन करने में प्रोग्रामर गलत क्यों हैं?" ", जिसके कारण मुझे कुछ आक्रोश हुआ। दुर्भाग्य से, मैं एक टिप्पणी नहीं छोड़ सकता, इसलिए मैंने सैंडबॉक्स में एक लेख लिखने का फैसला किया।

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

इसके समर्थन में, मैं लेखक द्वारा दिए गए कारणों पर विचार करने का प्रस्ताव करता हूं (मूल्यांकन की सटीकता को बेहतर बनाने के लिए प्लस निष्कर्ष):

1. समय साफ और गंदा है । किसी भी उद्योग में, विकास समय को विभिन्न नुकसानों के लिए प्रारंभिक और अंतिम घटनाओं + प्रत्यक्ष कार्य समय + समय पर खर्च किए जाने वाले समय के रूप में परिभाषित किया गया है। प्रारंभिक-अंतिम समय को आंकड़ों का उपयोग करके अनुमान लगाया जा सकता है, सबसे अधिक संभावना है कि यह किसी भी काम के लिए लगभग समान होगा (10-15% का विचलन), काम का समय खुद ही भविष्यवाणी की जा सकती है और होनी चाहिए (लेकिन बाद में और अधिक), विभिन्न नुकसानों के लिए समय सबसे मुश्किल लगता है। लेकिन वास्तव में, यहाँ सब कुछ सरल है। यह समय पूरी तरह से मुख्य कार्य के लिए समय के साथ संबंधित है, लेकिन प्रत्येक संगठन के लिए यह निर्भरता अलग होगी, क्योंकि यह संगठन के संगठनात्मक और तकनीकी स्तर के आधार पर निर्धारित किया जाता है। तदनुसार, कुल समय अनुमान की सटीकता को बढ़ाने के लिए प्रारंभिक-अंतिम समय के लिए अध्ययन की एक श्रृंखला आयोजित करना और कंपनी के संगठनात्मक और तकनीकी स्तर का निर्धारण करना आवश्यक है। निष्कर्ष: मानकीकरण तकनीकों का ज्ञान आवश्यक है।

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

3. शोध । यह कारण केवल अनुभव की कमी या ज्ञान की कमी के कारण उत्पन्न होता है। और इस तरह के कारण की उपस्थिति एक डिजाइन चरण की अनुपस्थिति को इंगित करती है, इसलिए आपको डिज़ाइन निर्णय लेने और कोडिंग प्रक्रिया में शोध करना होगा, स्वाभाविक रूप से यह विकास के समय को बढ़ाता है। और एक डिज़ाइन चरण की कमी डेवलपर के साथ अनुभव की कमी की पुष्टि करती है। निष्कर्ष: अनुभव और योग्यता में सुधार।

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

5. त्रुटियों का सुधार । कोडिंग प्रक्रिया में त्रुटियां डिजाइन चरण में खामियां हैं। सक्षम रूप से डिजाइन करने की क्षमता अनुभव के साथ, या एक अच्छे शैक्षणिक संस्थान में प्राप्त की जा सकती है। निष्कर्ष: आपको डिजाइन अनुभव या एक अच्छी शिक्षा की आवश्यकता है।

6. यौगिक और गैर-मानक कार्य । लेखक का कहना है कि इस तरह के कार्यों का आकलन प्रोग्रामर के आत्मविश्वास पर आधारित है। यह मूल्यांकन में एक बड़ी त्रुटि है। आप यह नहीं जानते हैं कि कार्य को कैसे करना है और श्रमसाध्यता का सही आकलन करना है - घोटाला न करें, भावनाओं और अंतर्ज्ञान पर भरोसा न करें, वे निश्चित रूप से यहां मदद नहीं करेंगे। यह ऐसी स्थितियों के लिए है कि मूल्यांकन के तरीके विकसित किए गए हैं। निष्कर्ष: मूल्यांकन विधियों का ज्ञान आवश्यक है।

7. दबाव के तहत मूल्यांकन । लेकिन यह प्रोग्रामर की समस्या नहीं है। और यहाँ यह विकास का अनुभव नहीं है जो आवश्यक है, लेकिन बातचीत का अनुभव है, लेकिन अभी भी इसकी आवश्यकता है। निष्कर्ष: बातचीत में अनुभव प्राप्त करना आवश्यक है।

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

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