जब मुझे नई तकनीक के लिए सीखने की अवस्था को शामिल करने की आवश्यकता होती है, तो मैं परियोजनाओं का अनुमान कैसे लगा सकता हूँ?


11

कभी-कभी, अनुसंधान और विकास परियोजनाएं होती हैं जहां प्रौद्योगिकी, अवधारणाओं और ग्राहक के बारे में पहले से कुछ भी ज्ञात नहीं है। हालांकि, प्रबंधक को अभी भी समय के अनुमान की आवश्यकता है। उपयोगी अनुमान लगाने के लिए मैं क्या कर सकता हूं?


5
जो भी आपका अनुमान है वह एक ज्ञात तकनीक में होगा और दशमलव को एक स्थान पर ले जाएँ: P
रिग

5
स्टीव मैककोनोल की सॉफ़्टवेयर अनुमान पुस्तिका पढ़ें और समझें कि एक अच्छा अनुमान क्या है। एक अनुमान में अनिश्चितता है - यदि ऐसा नहीं होता, तो यह अनुमान नहीं होगा। यह कहते हुए कि "इसमें तीन महीने से लेकर छह महीने तक का समय लग सकता है, इस पर एक महीना बिताने के बाद मैं इसे कम कर पाऊंगा" यह मुझे स्वीकार्य होना चाहिए।

1
@ मिचेल्ट - महान टिप्पणी। एक बात का अनुमान लगाने के लिए गारंटी दी जाती है कि अधिक तालमेल उन्हें समय के साथ परिष्कृत कर रहा है इसलिए प्रबंधन को काम का एक सटीक सटीक अनुमान मिलता है। उन्हें पेशाब करने की गारंटी वाली एक परियोजना एक ऐसी परियोजना है जो स्थायी रूप से दो सप्ताह पूरी होने से दूर है।
कार्सन 63000

यह वही है जो प्रोटोटाइप के लिए है।

@ Carson63000 मैं उस phrasing में अनिश्चितता के शंकु का एक सरलीकृत संस्करण था । उस दृष्टांत से हटने वाली महत्वपूर्ण बात यह है कि 2-12 महीने का अनुमान का मतलब यह नहीं है कि यह अंत में 7 महीने तक खत्म हो जाता है, बल्कि यह अनुमान 2-12 से 4-12 से 8-12 में परिवर्तित हो सकता है। १०-१२ से १२ तक। यह भी ध्यान दें कि जब मूल अवधारणा की जाती है तो मूल शंकु में १६x की सीमा होती है।

जवाबों:


13

ईमानदारी से, जैसा कि नासिम निकोलस तालेब ने अपनी पुस्तक द ब्लैक स्वान में लिखा है: 'हम सिर्फ भविष्यवाणी नहीं कर सकते'। मुख्य रूप से अज्ञात-अज्ञात के कारण। यह आमतौर पर इस तथ्य को संप्रेषित करने के लिए सबसे अच्छा है, यह तथ्य कि आप अनुमान लगाने के बजाय भविष्यवाणी नहीं कर सकते।

जैसा कि तालेब लिखते हैं: मोटे तौर पर सही होने से बेहतर है, ठीक गलत से। इसलिए इस तथ्य से अवगत होना सुनिश्चित करें कि आपके पास कठिन समय का आकलन है, और एक तर्क के रूप में 'नई तकनीक में सीखने की अवस्था' जैसी चीजों का उपयोग करें। इसका मतलब है कि आपके अनुमान की सीमा बड़ी होगी: 'यह परियोजना 100k और 500k के बीच लागत को पार करेगी।'

इस तरह की बात कहकर, आपको किसी चीज का अनुमान लगाने के लिए कहने से पता चलता है कि चीजें इतनी सरल नहीं हैं।


3
+1: यह एकमात्र सही उत्तर है। अनजान लोगों को गले लगाने के लिए आपको प्रबंधक सिखाएं - यह अनुमान लगाने की तुलना में बहुत आसान है। - इसके अलावा construx.com पर स्टीव मैककोनोल के काम को देखें।
मत्तन्ज

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

2
@ThomasOwens आप सही हैं, आपको इसके लिए अभी नहीं चलना चाहिए। लेकिन मेरे साहसिक बयान की व्याख्या करने का इरादा था: अपने आप को मूर्ख मत बनाओ, या अपने मालिक को मूर्ख मत बनाओ, लेकिन इस तथ्य में खुले रहो कि अनुमान कठिन होने जा रहा है! क्योंकि ईमानदारी से, प्रत्येक प्रबंधक अनुमान लगाने के लिए नहीं कह रहा है कि एक को बनाना कितना कठिन / असंभव है।
मार्टन साइटेमा

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

3

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

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

इस तकनीक के साथ, मॉडलिंग टूल के आउटपुट को आम तौर पर मान्य किया जाता है क्योंकि उन्हें कई संगठनों में कई वर्षों में पिछले सॉफ्टवेयर प्रोजेक्ट का अनुमान लगाने के लिए सफलतापूर्वक उपयोग किया गया है। हालांकि, आउटपुट केवल टूल के इनपुट के रूप में अच्छा है।

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

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


3

विकास समय से प्रमुख प्रशिक्षण और अनुसंधान समय को अलग करें। खुश अंत है कि कई उप परियोजनाओं में परियोजना को तोड़ो। सुनिश्चित करें कि आप प्रशिक्षण के बाद अवधारणा का प्रमाण बनाएं।

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


1

निर्भर करता है, मैंने ज्यादातर समय एफपीए ( फंक्शन प्वाइंट एनालिसिस ) का इस्तेमाल किया , लेकिन हम इस "एंटरप्रीज़ी वेब डेवलपमेंट" में थे, मेरा मतलब है, आप जानते हैं, फोर्ब्स 500 वेब कंपनियां हैं।

वहां कार्य को हमेशा दो भागों में विभाजित किया जा सकता है: एक, जो कि एफपीए को अच्छी तरह से फिट बैठता है: आपके पास इनपुट इंटरफेस, आउटपुट इंटरफेस, आंतरिक तार्किक फाइलें (उर्फ डेटाबेस टेबल / निर्यात किए जाने वाले प्रकार) हैं, और आपके पास ये जटिल, अज्ञात सिस्टम हैं। ।

आसान संस्करण में, जटिल कार्य एक घटक है जो पहले से ही लिखा गया है, यह इसके साथ इंटरफेस करने के लिए बस कठिन और अज्ञात है।

हार्ड संस्करण है जब इसे लिखने की आवश्यकता होती है, तो पायलट-आधारित अनुमान, COCOMO, जो भी हो।

दो बातें, हालांकि, महत्व की:

  1. आपके संगठन के लिए हर तरह की आकलन प्रणाली का अंशांकन समय होना चाहिए। आप कभी भी अकेले विकसित नहीं होते हैं, कम से कम आपके कोड के लिए एक ग्राहक इंतजार कर रहा है (या आप इस बारे में बहुत हताश नहीं होंगे, अपने खुद के लिए कोड लिखना)। सवाल यह नहीं है कि "यह कितनी तेजी से विकसित किया जा सकता है?", लेकिन "यह कितनी तेजी से आप सभी के साथ विकसित किया जा सकता है?"

  2. एक बार मेरे पास एक मैनेजर था जिसने उस ब्लैक स्वान उपन्यास को पढ़ा और उसके बारे में उन्मत्त था। वह हमें बता रहा था कि यह अनुमान लगाना असंभव है, और मैं अपने सामान्य सटीक -10% अनुमानों पर लगातार काम कर रहा था ...


-2

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

क्षमा करें जो बिल्कुल भी मदद नहीं करता है।


-4

परिचित तकनीक का उपयोग करके एक समान परियोजना करने में कितना समय लगेगा, इसका अनुमान लगाएं। 4. से गुणा करें। कुछ सीखने का समय जोड़ें।

यदि अनुमान बहुत छोटा है, तो आप अनुभवहीन और अभिमानी दिखेंगे। यदि अनुमान बहुत बड़ा है तो आप अज्ञानी और अक्षम दिखेंगे। सोच के चुनें।


4
क्यों 4? 5 क्यों नहीं? 10? 33.3? ... क्या आपके उत्तर के पीछे विज्ञान है या आप केवल एक यादृच्छिक संख्या चुन रहे हैं? अपने उत्तर में इसे शामिल करना इसे और अधिक उपयोगी बना सकता है।
ब्रायन ओकली

संबंधित नोट पर, बड़ी संख्या में शर्मीली न हों। मेरे सहकर्मी ने एक बार 935 (नौ-तीन-पांच) दिनों में कुछ मॉड्यूल की बहाली का अनुमान लगाया था। बॉस ने कहा कि हमारे पास इतना नहीं है और 60 दिनों का आदेश दिया । सहकर्मी ने 60 में जो संभव था वह किया। परिणाम काफी परेशानी भरा था लेकिन इसके लिए उन्हें कभी दोषी नहीं ठहराया गया । स्वीकार करना होगा कि 60-दिन के संस्करण, हालांकि, परेशानी के कारण, हमें एक बहुत ही महत्वपूर्ण ग्राहक प्राप्त करने की अनुमति दी - यानी बॉस के पुश ने बहुत अच्छा व्यवसायिक अर्थ दिया। अंत में BTW हम उस मॉड्यूल को आकार में लाने में कामयाब रहे, लेकिन ऐसा कई सालों बाद हुआ और इसके लिए किए गए प्रयास 935 अनुमान के साथ बॉलपार्क में अधिक थे
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.