मेरे पास उन थर्ड-पार्टी नियंत्रणों का उपयोग करने वाले प्रोग्रामिंग कार्यों पर अनुमान लगाने के लिए प्रबंधन के साथ एक कठिन समय है, जिनके साथ मुझे कोई पूर्व अनुभव नहीं है।
मैं निश्चित रूप से समझता हूं कि वे अनुमान क्यों चाहते हैं, लेकिन मुझे लगता है कि मेरे द्वारा दिया गया कोई भी अनुमान या तो a) बहुत छोटा होगा और मुझे बुरा या b) बहुत लंबा और मुझे बुरा लगेगा।
मैं उन्हें अपनी पीठ से हटाने के लिए प्रबंधन को क्या अनुमान या उत्तर दे सकता हूं ताकि मैं अपना काम जारी रख सकूं!
जवाबों:
सबसे अच्छा उत्तर जो आप दे सकते हैं, वह है कि आप एक त्वरित प्रोटोटाइप को दस्तक देने के लिए समय मांगें, ताकि आप अधिक सटीक अनुमान दे सकें। एक उपकरण या एक समस्या के साथ कुछ अनुभव के बिना , आपके द्वारा दिया गया कोई भी अनुमान अनिवार्य रूप से अर्थहीन है।
एक तरफ के रूप में, बहुत लंबे समय तक एक अनुमान देने के साथ बहुत कम समस्या है। अप्रत्याशित समस्याएं होती हैं, प्राथमिकताएं बदलती हैं, और आवश्यकताएं "अपडेट" होती हैं। यहां तक कि अगर आप अपने द्वारा मांगे गए सभी समय का उपयोग नहीं करते हैं, तो आपके पास अधिक परीक्षण समय होगा, या "जल्दी" जारी कर सकते हैं।
मैं हमेशा अपने अनुमानों में बहुत अधिक आशावादी रहा हूं, और यह आपके जीवन में बहुत तनाव डाल सकता है, खासकर जब आप अनुभव और आत्मविश्वास के बिना एक युवा प्रोग्रामर होते हैं जो मालिकों को असुविधाजनक सच्चाई बताने के लिए आत्मविश्वास रखते हैं।
मैं तुम्हें एक रहस्य पर दूँगा। यहां तक कि अगर आप उस तकनीक के विशेषज्ञ थे, तो आपका अनुमान अत्यधिक गलत होने की संभावना है। यह कुछ ऐसा करते समय जानवर की प्रकृति है जो स्वाभाविक रूप से अनुसंधान और विकास कार्य है। दुर्भाग्य से प्रबंधन अक्सर एक निर्माण मॉडल लागू करने और सटीक अनुमानों की मांग करने की कोशिश करता है। मेरी बात को समझने के लिए, निम्नलिखित दो प्रयासों का सही आकलन करने में कठिनाई पर विचार करें:
ए) एक और 11K छतरियों का निर्माण करें जो पिछले महीने के 2K के समान ही हैं। बी) एक नई तरह की छतरी डिजाइन करना और पहले एक का निर्माण करना।
सॉफ्टवेयर विकास बी है, लेकिन वे ए अनुमान मानते हुए पूछ रहे हैं।
आप जो सबसे अच्छा कर सकते हैं वह कार्य को सबसे छोटे टुकड़ों में तोड़ना संभव है (प्रत्येक दिन 1/2 से अधिक नहीं) और फिर आपके साथ आने वाले अंतिम नंबर को तिगुना करें। (स्पोलस्की विधि)
वैकल्पिक रूप से, स्टीव मैककोनेल के पास सॉफ्टवेयर इंजीनियरिंग के इस पहलू पर एक पूरी पुस्तक (यकीनन कई) है। http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
स्टीव मैककोनेल (और अन्य) अनिश्चितता के शंकु के बारे में बात करते हैं । मूल रूप से आप एक अनुमान प्रदान करते हैं जो कुछ इस तरह दिखता है:
यह कार्य 3 और 9 सप्ताह के बीच होगा जिसमें 4 सप्ताह सबसे अधिक होने की संभावना है।
जैसे-जैसे परियोजना आगे बढ़ेगी आप अपने अनुमान को निखार सकते हैं। जैसा कि आप अधिक काम करते हैं और आवश्यक प्रयास को बेहतर ढंग से समझते हैं आप अपने अनुमान को अधिक सटीक होने के लिए परिष्कृत कर सकते हैं।
यह मेरे लिए काम कर रहा है, लेकिन इस प्रक्रिया को समझने के लिए परियोजना में अन्य हितधारकों को प्राप्त करने के लिए कुछ प्रयास की आवश्यकता हो सकती है।
आप एक अनुमान और एक विश्वास स्तर दोनों देने पर विचार करना चाह सकते हैं, अर्थात, यह ५०/५० है कि इसमें ३-६ महीने या ६- ९ महीने या and५% मौका ९ महीने और ९ ०% होने की संभावना है जो आप होंगे एक साल में किया।
एक और बात जिस पर आप विचार करना चाहते हैं, वह है " भीड़ की समझदारी " दृष्टिकोण का उपयोग करना । चारों ओर जाएं और 25-50 लोगों से पूछें कि उन्हें कितना समय लगता है और उनके अनुमानों को औसत करेगा। माइक कोहन की योजना पोकर है, मुझे लगता है कि यह बहुत ही समान है, हालांकि सिर्फ एक डेवलपर के साथ योजना बनाना मुश्किल है।
अपने अनुमान को तोड़ें:
रास्ते में अनुमान और कुछ मील के पत्थर को समायोजित करने की पेशकश करें। कोई भी अज्ञात अज्ञात ज्ञात हो जाएगा, ज्ञात अज्ञात ज्ञात हो जाना चाहिए जैसा कि आप अनुभव प्राप्त करते हैं, और आपके द्वारा ज्ञात ज्ञात का अनुमान प्रगति पर आधारित किया जा सकता है। आप एक प्रारंभिक अनुमान लगा सकते हैं, फिर अनुमान लगा सकते हैं जब आपने लगभग 25% किया, फिर 50% पर, फिर 85% पर। प्रत्येक मील के पत्थर पर आपका अनुमान वास्तविक समय पर कार्य करना शुरू कर देगा।
मैं अपने अनुमानों के लिए एक निश्चित लेबलिंग प्रणाली का उपयोग करता हूं ... क्लास ए, क्लास बी और क्लास सी।
कक्षा सी का अनुमान सबसे पहले उन्हें मिलता है। अज्ञात रूप से इसे खुले तौर पर प्लस या माइनस 50% बताया गया है। यदि वे चाहते हैं कि मैं उन्हें कक्षा बी देना जारी रखूं, तो मुझे शोध के लिए धन की आवश्यकता है।
वर्ग बी प्लस या माइनस 25% है। कभी-कभी यह काफी अच्छा होता है और वे मुझे पैसे देते हैं। यदि नहीं, तो कम पैसे और अधिक शोध।
क्लास ए प्लस या माइनस 10% है, फाइनल और गो या नो गो। यदि यह एक जाना है और मैं अनुमान से बहुत दूर भटकता हूं तो मैं अक्सर और जल्दी स्वीकार करता हूं।
मुझे लगता है कि यदि आप उस वाक्यांश को हटाते हैं जो "3 पार्टी नियंत्रणों का उपयोग कर रहा है जो मेरे पास कोई पूर्व अनुभव नहीं है", तो आपके पास आपकी बड़ी समस्या का बेहतर विवरण हो सकता है।
यदि "फुर्तीली" ने हमें कुछ भी सिखाया है, तो यह है कि, अगर प्रबंधन आपसे उम्मीद करता है कि चल रहे आधार पर, इस तरह से परियोजनाओं का अनुमान लगाने के लिए, और यदि आप कहते हैं कि यह "बुरा लगेगा" तो आप इसे प्रदान नहीं कर सकते क्योंकि आपके पास नहीं है पर्याप्त जानकारी, आप राजमार्ग पर विफल हैं।
सबसे बड़ी समस्या उन मुद्दों की होने वाली है जिन पर आपका कोई नियंत्रण नहीं है, और जिन्हें आपने अभी तक पहचाना नहीं है। आपने कितनी बार पीछे मुड़कर देखा और खुद से कहा "ठीक है, मैंने अपने अनुमान को बटन पर ठीक से मारा - तीसरी कोशिश के बाद, जब मुझे लगा कि ... और मुझे संस्करण की आवश्यकता है ... और यह कि dba चालू होगा एक सप्ताह के लिए छुट्टी और कि प्रोजेक्ट मैनेजर को एक सप्ताह के लिए ... और मेरी पत्नी के गर्भवती होने और ... "की आवश्यकता होगी।
मैं यह कहने की वास्तविक कोशिश करूंगा, "मैं महत्वपूर्ण जोखिम कारकों की पहचान कर सकता हूं और xx दिनों में उन्हें जांचने के लिए डिलिवरेबल्स की एक चेकलिस्ट के साथ आ सकता हूं। उस समय मैं आपको एक और वृद्धिशील अनुमान दूंगा।"
और यह वास्तव में अच्छा होगा यदि आप सुझाव दे सकते हैं कि उन्हें "कृपया आग्रह करना चाहिए कि मैं भविष्य में आपको उस प्रकार का विश्वसनीय अनुमान देने की कोशिश नहीं करूंगा। यदि मैं कोशिश करता हूं तो मुझे आग दें।"
(ओवरस्टेटेड, लेकिन केवल थोड़ा सा।)
अनुमान लगाने की कोशिश भी मत करो। ऐसा कोई तरीका नहीं है कि आपका अनुमान सही होगा। यह सब सिर्फ एक अनुमान के बाद है।
मैं इसके बजाय यह सलाह दूंगा कि आप फीचर को छोटे टुकड़ों में विभाजित करें (1-2 दिन से अधिक नहीं), और इन टुकड़ों को ग्राहक / प्रबंधक के लिए काम, पूर्ण, परीक्षण योग्य और मूल्यवान कोड के रूप में वितरित करने का प्रयास करें। इस तरह वह दिन-प्रतिदिन के आधार पर आपके लिए अपनी प्रगति देखेगा। इसका मतलब यह भी है कि वह वास्तव में एक बार संतुष्ट होकर विकास को रोकने का फैसला कर सकता है और इसे पूरा मान सकता है, भले ही वह सभी लक्ष्यों तक नहीं पहुंच पाया हो।
इस दृष्टिकोण के बारे में अधिक जानकारी के लिए चुस्त प्रथाओं "रिलीज प्लानिंग" और "Iteration Planning" पर एक नजर डालें।
ध्यान रखें यदि आप बड़े समय का अनुमान लगाते हैं, लेकिन इसे समय के अनुसार बनाते हैं, तो यह अनुमान लगाने और विस्तार के लिए पूछने की तुलना में बेहतर लगता है।
मैं एक प्रोटोटाइप का मजाक उड़ाने की कोशिश करूंगा ताकि आपके पास उस समय का बेहतर विचार हो। अपने प्रबंधन के साथ ईमानदार रहें ताकि वे सीखने की अवस्था में अप्रत्याशित देरी के लिए बजट बना सकें।
संपादित करें: आप यह भी देख सकते हैं कि क्या आप अधिक "पुनरावृत्त" समय सीमा प्राप्त कर सकते हैं। "प्रैग्मैटिक थिंकिंग एंड लर्निंग" में, एंडी हंट एक अच्छा बिंदु बनाता है कि लोग परियोजना के अंत के करीब परियोजना विशेषज्ञ हैं और बहुत शुरुआत में कम से कम जानकार हैं। यह बहुत शुरुआत में अपने डिजाइन और समय का आकलन करने के लिए बहुत मायने नहीं रखता है, जब हर कोई परियोजना के बारे में कम से कम जानकार है। यदि आप समय सीमा को "पुनरावृति" करते हैं और समस्या को हल करते हैं, तो आपको अधिक सफलता मिलेगी।
बहुत सटीक अनुमान आत्म-ज्ञान है। यदि आपने बहुत सारे कोड लिखे हैं, यदि आपको बहुत सारे एपीआई सीखने हैं, तो आपको सवालों का अहसास होने लगता है:
उस के दौरान, आपको इस तरह की चीजों की समझ होनी चाहिए:
इन सभी बातों के आधार पर, आप यह समझ पाएंगे कि कोई चीज़ कितनी देर तक चलेगी और आपकी मान्यताओं को बताने में सक्षम होगी ("मान लिया गया है कि एपीआई है ...") यहां तक कि अधूरी अधूरी जानकारी के कारण भी।
यह अनुमान लगाने के लिए कि आपको एक बेहतर अनुमान लगाने के लिए पर्याप्त सीखने के लिए कितनी देर चाहिए, उदाहरण के लिए, "मुझे नहीं पता: मैंने इसके साथ कभी भी ऐसा नहीं किया है। यह संभवत: मुझे यहां अपना अनुमान लगाने के लिए काम करने के लिए देगा। आपको इसके बारे में जानने की आवश्यकता है जो मुझे पता होना चाहिए कि इससे पहले कि मैं आपको अपनी परियोजना को समाप्त करने के लिए इसका उपयोग करने के लिए एक अच्छा अनुमान दे सकूं । "
प्रोग्रामिंग करते समय मैंने हमेशा वही लिया है जो मैंने सोचा था कि यह मुझे ले जाएगा और एक अनुमान प्रदान करने के लिए इसे 3 से गुणा करेगा। अगर मुझे लगता है कि मैं 1 सप्ताह में एक नौकरी कर सकता हूं, तो मैं ग्राहक को बताता हूं कि इसमें 3 लगेगा - अगर मुझे लगता है कि यह वास्तव में मुझे 3 सप्ताह लगेगा तो मैं ग्राहक को 9 सप्ताह बताता हूं।
ऐसा करने से मैंने अपने आप को "वादा के तहत, ओवर डिलीवर" के लिए सेट किया - यदि आप सफलतापूर्वक ऐसा कर सकते हैं तो आपका जीवन बहुत बेहतर होगा और आपके ग्राहक बेहद खुश होंगे।
अपने मामले में आप निश्चित रूप से कम से कम कुछ समझ प्राप्त करना चाहेंगे कि आप अनुमान लगाने से पहले क्या डाइविंग कर रहे हैं। हो सकता है कि आपको अनुमान प्रदान करने में कितना समय लगने वाला हो, आपको एक अनुमान प्रदान करने की आवश्यकता है। 3 से गुणा करने से ग्राहक खुश रहते हैं।
इसे उन चीजों में तोड़ दें जिनके साथ आपको कुछ अनुभव है। इसे काट देने का कार्य आपको एक बेहतर विचार देगा कि आप क्या जानते हैं और क्या नहीं जानते हैं।
एक बार टुकड़े काफी छोटे होते हैं कि उन्हें एकल परिभाषित कार्यों के रूप में देखा जा सकता है, उनमें से कुछ पूरी तरह से गैर-अनुमान्य होंगे। उन लोगों के लिए, या तो पहले प्रोटोटाइप, या बस अपने आप को टुकड़ा के आकार के आधार पर समय की कुछ उचित मात्रा में छोड़ दें। यदि आप पा रहे हैं कि आपको 2-4 सप्ताह के काम से बड़ा न के बराबर टुकड़े मिल गए हैं, तो पहले उन्हें काटकर वापस जाएं।
अंततः आप कुछ बहुत ही अजीब तकनीकी समाधानों के लिए उतरेंगे (जो आपको लगता है कि काम करना चाहिए, लेकिन निश्चित रूप से नहीं पता है), और एक बार काम करने के लिए उस सामान को वापस करने के लिए बहुत सारा काम करना होगा। लापता डिजाइन के कुछ टुकड़े होंगे, जिसके लिए कुछ प्रसिद्ध पुस्तकालय या प्रारंभिक संस्करण के लिए एक बहुत ही सरल एल्गोरिथ्म चुनना सबसे अच्छा है।
यदि आप कार्यों को तोड़ नहीं सकते हैं, तो आपको किसी ऐसे व्यक्ति को पर्याप्त अनुभव के साथ काम पर रखना चाहिए जो आपके अनुभव की कमी के कारण आपको अन्य तरीकों से भी परेशान कर सकता है। यदि आप किसी को नौकरी पर नहीं रख सकते हैं, तो आपको बस एक यादृच्छिक रूप से लंबी अवधि (6 महीने से 2 साल) के लिए मोलभाव करना चाहिए, और सीधे एक गंदे प्रोटोटाइप में सिर करना चाहिए (जब तक कि आप अपने आप को यह जानने के लिए पर्याप्त अनुभव देने में कामयाब रहे कि क्या सही है और क्या है गलत)। लेकिन, यदि आप इसे खत्म कर रहे हैं, तो यह महत्वपूर्ण है कि आप खुद को न समझें और सोचें कि आप इसे सही तरीके से कर रहे हैं। प्रोटोटाइप को फेंकने के लिए थे। उम्मीद है कि एक बार प्रोटोटाइप की उल्टी गिनती पूरी हो जाने के बाद, आप इसे वास्तविक बनाने के लिए तैयार हैं।
पॉल।
आप सिर्फ एक बाहरी संख्या का अनुमान लगाते हैं और तुरंत मूल्यांकन करते हैं, उन्हें बताएं कि भविष्य की जानकारी आपके अनुमानों को प्रभावित कर सकती है, लेकिन आप उन्हें अद्यतित रखेंगे।
जैसा कि आप मूल्यांकन करते हैं, उन्हें सूचित करें - या तो वेब या साप्ताहिक अपडेट पर प्रकाशित एक दस्तावेज़ के माध्यम से, लेकिन हमेशा एक अद्यतन "अनुमानित समाप्ति तिथि", और एक्सटेंशन के लिए कारण (यदि कोई हो) शामिल करें।
अधिकांश प्रबंधकों को यह समझना चाहिए कि - अंतिम तिथियां पूछकर, वे वास्तव में कह रहे हैं "हमें कुछ विचार दें कि हम अपने कार्यक्रम की योजना कैसे बना सकते हैं" और "बस हमेशा के लिए न लें"।
यदि आप एक या दो बार से अधिक विस्तार कर रहे हैं, तो अपने नए ज्ञान के आधार पर अपने पूरे शेड्यूल का पुनर्मूल्यांकन करें जो आप अनुमान लगाने पर चूसते हैं।
RB ने कहा, जब मैं खुद को इस स्थिति में पाता हूं तो मुझे लगता है कि मुझे उन उपकरणों के साथ कितना समय लगेगा जिनसे मैं परिचित हूं, और फिर कुछ सीखने की अवस्था में बनाने के लिए उस अनुमान को दोगुना कर दूंगा।
महत्वपूर्ण हिस्सा प्रबंधन को सूचित कर रहा है कि अनुमान एक अनुमान है , अगर वे अधिक सटीक अनुमान के लिए दबाते हैं या यदि वे - प्रिय भगवान को कोशिश करते हैं - तो आप एक समय सीमा बेचते हैं (निश्चित रूप से यह केवल 2 दिन ले जाएगा स्टारशिप बनाने के लिए एंटरप्राइज, आप अच्छे हैं आप) अपनी वस्तुओं पर क्लिक करें , अपने अनुमान या इस तथ्य से समझौता न करें कि यह अविश्वसनीय है।
यदि प्रबंधन आपको ओवरराइड करता है और कार्य को टाइमबॉक्स करता है जैसे "ठीक है, तो इसे 2 दिनों में किया जाना है", फिर से उन्हें बताएं कि यह उनका अनुमान है, जो आपके अपने जैसा ही विश्वसनीय है।
यह सब लिखित रूप में प्राप्त करें।
मैं अपनी नौकरी में अनुमान के साथ बहुत कुछ करता हूं और यह एक वास्तविक चुनौती है। मेरी सबसे बड़ी चुनौतियों में से एक यह अनुमान लगाना है कि किसी कार्य को पूरा करने के लिए एक अलग डेवलपर को कितना समय लगेगा, यह जानने के लिए कि डेवलपर कितना कुशल होगा।
जबकि आप "प्रारंभिक वादा, ओवर डिलीवर" विधि के साथ कुछ प्रारंभिक सफलता देख सकते हैं, आप पाएंगे कि समय के साथ आप अन्य लोगों द्वारा भी नाराज होंगे, जो "ओवर वादा" के तहत "विचार के तहत" स्कूल का पालन करेंगे। सटीकता की कमी आपको किसी भी तरह से काटने के लिए वापस आ जाएगी। सटीकता बहुत अनुभव से बंधी हुई है और तकनीक के साथ अज्ञात की संख्या को सीमित करती है।
एक चीज जो मैं सुझाऊंगा, वह यह है कि आपका अनुमान किस तरह के बजट के खिलाफ काम करेगा। यदि आपके पास एक छोटा बजट है, तो अपरिचित तकनीक के साथ पागल न हों और जो आप जानते हैं उसके साथ रहें। यदि आपका बजट थोड़ा अधिक लचीला है, तो आप थोड़ा सा प्रयोग कर सकते हैं।
यह भी पहचानें कि कुछ कार्य होंगे जहाँ आप प्रदान कर सकते हैं एक जंगली गधा अनुमान (WAG) है। इन के लिए आपको अपने अनुमान के लिए न्यूनतम समय निर्धारित करना चाहिए और यह स्पष्ट करना चाहिए कि आपको पता नहीं है कि अधिकतम क्या है। अक्सर इस तरह के अनुमान प्रबंधन द्वारा कुछ सुविधाओं / रीक को काटे जाने के लिए पर्याप्त कारण होते हैं।
यह एक अपरिहार्य कौशल है जो परियोजना प्रबंधक और प्रोग्रामर दोनों के पास हो सकता है (और निश्चित रूप से मास्टर हो सकता है!), मुझे एक लेख मिला, सॉफ्टवेयर डेवलपमेंट टास्क का अनुमान लगाया (थोड़ा सा) आसान , जो मुझे प्रोजेक्ट के कार्यों के लिए बेहतर अनुमान लगाने में मदद करने की उम्मीद है।
उपरोक्त सभी प्रतिक्रियाओं ने अनुमान के साथ आने के बारे में बहुत कुछ कवर किया है।
एक बात मैं जोर दूंगा कि आप अपने अनुमान पर नज़र रखें (एक छोटा एक्सेल स्प्रेडशीट एक ला जोएल, या यहां तक कि एक नोटपैड दस्तावेज़ अगर यह बहुत सरल है), और हर दिन के अंत में इसे सबसे सटीक आंकड़ों पर अपडेट करें जो आप अब प्रदान कर सकते हैं । यदि आप अपने आकाओं को यह वापस पारित करने के लिए यह रखने के लिए तिथि आप कैसे चीजें प्रगति कर रहे हैं, और अधिक महत्वपूर्ण बात आप के लिए एक अच्छा लग रहा है मिल जाएगा के बारे में एक बेहतर विचार देता है की जरूरत नहीं है यहां तक कि अगर क्यों काम प्रगति के रूप में अपने अनुमान में परिवर्तन ।
ऐसा करने से आपको भविष्य में अनुमान लगाने में बेहतर होगा, इस विशिष्ट तकनीक और अन्य के लिए जो आपने पहले इस्तेमाल नहीं की हैं, बस इसलिए कि यह आपको कुछ स्तरों पर ध्यान देने की आवश्यकता है जब आपकी अपेक्षाएं नियमित अंतराल पर बदलती हैं, और बाहर काम करें, ऐसा क्यों हुआ ।
यह अनुमान लगाना कि किसी चीज को कब तक लेना आपकी नौकरी का हिस्सा है। जब तक यह एक समय सीमा के बजाय एक अनुमान के रूप में समझा जाता है तो आपको चिंता करने के लिए कुछ भी नहीं होना चाहिए। कोड लिखने वाले व्यक्ति की तुलना में अनुमान प्रदान करने के लिए कोई बेहतर स्थान नहीं है। यदि आप एक अच्छा अनुमान नहीं दे सकते हैं, तो आपको अपने बुरे अनुमान से जुड़े जोखिम के बारे में प्रबंधन को अवगत कराने की आवश्यकता है ताकि वे इस बात पर पुनर्विचार कर सकें कि क्या यह इन अज्ञात 3 पार्टी नियंत्रणों के खिलाफ प्रोग्रामिंग पर जोखिम लेने के लायक है।
यह एक बहुत ही सामान्य स्थिति है: अज्ञात से निपटने की आवश्यकता। इससे निपटने का एक उपयोगी तरीका यह है कि वास्तविक प्रोग्रामिंग कार्यों के अलावा, आपको कुछ सीखना है - और प्रबंधन को इसके बारे में पता होना चाहिए।
जब आप इस तरह की स्थिति में होते हैं, तो परियोजना अचानक आरएंडडी परियोजना बन जाती है और सामान्य से अधिक समय आपको बुरा नहीं लगेगा, क्योंकि आप सीख रहे हैं और कार्यक्रम तैयार कर रहे हैं। मैं नहीं जानता कि आप कितनी तेजी से सीख रहे हैं या आपको किन संसाधनों से जुड़ी समस्याओं से जूझना पड़ सकता है (स्टैक ओवरफ्लो आपके पास मौजूद विकल्पों में से एक है)।
मैं कहूंगा कि आपको हमेशा की तरह अनुमान लगाना चाहिए और फिर या तो 1.5 से गुणा करना चाहिए (यदि आप एक तेज शिक्षार्थी हैं और आपके सवालों को हल करने के लिए संसाधनों तक पहुंच है) या 2.5 तक यदि आप एक औसत शिक्षार्थी हैं और केवल अपने आप पर निर्भर हैं।
आशा है कि ये आपकी मदद करेगा!
प्रबंधनीय टुकड़ों में कार्य को विभाजित करने के लिए अपने सबसे कठिन प्रयास करें। कुछ किस्मत के साथ विशिष्ट कार्य हैं जो तीसरे पक्ष के घटक से संबंधित हैं और अन्य जो कम युग्मित हैं (और इसलिए अनुमान लगाना आसान है)। प्रबंधन को अनुमानित विभाजन दें और इंगित करें कि सबसे अनिश्चित अनुमान कहाँ रहते हैं।
मैं इस बात से पूरी तरह सहमत हूं कि जिसने भी आसपास घूमने और कुछ को प्रोटोटाइप बनाने का सुझाव दिया। प्रोटोटाइप गतिविधि के लिए एक निश्चित समयावधि निर्धारित करें। ("मुझे अपने अनुमान के इस हिस्से को बेहतर बनाने के लिए पहले दो दिन चाहिए।")
क्या आप एक सीमा दे सकते हैं? 40-60 घंटे, ऐसा कुछ?
छोटे कार्य जितने कठिन होते हैं, उतने ही कठिन होते हैं, अगर आप उन्हें समूह में रख सकते हैं तो आपके पास परियोजना के अंत में शेष राशि के रूप में थोड़ा अधिक "ढलान" होगा।
एक गाइड के रूप में आपके पास किसी भी क्षेत्र को देखें और उपयोग करें। "पिछली बार एक फीचर बनाने की आवश्यकता थी जिसने डेटाबेस को बदल दिया जो मुझे एक्स ले गया"। सौभाग्य।