प्रोजेक्ट अवधि का आकलन करते समय स्वीकार्य त्रुटि मार्जिन क्या है?


23

जिस कंपनी में मैं काम करता हूं उसका लक्ष्य 10% अधिकतम त्रुटि मार्जिन है। वे विश्लेषकों से अनुमान लगाते हैं कि अनुमान 10% से कम या अधिक नहीं छूटेगा।

मुझे नहीं पता कि इसके बारे में क्या सोचना है, क्योंकि मुझे इसकी तुलना करने के लिए कुछ भी नहीं मिला।

यदि हम गलत अनुमान लगा रहे हैं, तो कम या ज्यादा के लिए मापने के लिए एक अच्छी आधार रेखा क्या हो सकती है? कितना (% में) आपको लगता है कि याद करना ठीक है?


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

3
क्या आप कह रहे हैं कि यदि आप बहुत ज्यादा खर्च करके यूएनडीईआर के बजट में आते हैं, तो किसी को परेशानी होने वाली है?
पीडीआर

@pdr उन्होंने परिणामों के बारे में कुछ नहीं कहा।
तुलियो एफ


2
मैं स्टीव मैककोनेल की "सॉफ्टवेयर अनुमान" पुस्तक को देखने का सुझाव दूंगा। इसमें वहाँ एक tidbit है कि +/- 10% की सटीकता संभव है - लेकिन केवल अच्छी तरह से नियंत्रित परियोजनाओं पर संभव है। यह जोंस द्वारा 1998 में एक पुस्तक का संदर्भ देता है।

जवाबों:


25

जब तक आप कुछ ऐसा ही अनुमान लगा रहे हैं, जो आपने और आपके सहकर्मियों ने पहले किया है, तो +/- 10% हास्यास्पद आशावादी है। आपके प्रबंधन के पास या तो सॉफ्टवेयर के साथ बहुत अधिक अनुभव नहीं है, या वे सॉफ़्टवेयर सीमा के लिए बड़ी सीमा के बारे में नहीं जानते हैं । उस कागज में कुछ सहायक सामग्री होती है , और बहुत सारे पंडित मिल सकते हैं।

चलो एक विशिष्ट सॉफ्टवेयर परियोजना की तुलना में कहीं अधिक सरल प्रणाली की जांच करते हैं: रूबिक क्यूब। आप अधिकतम 20 चालों में किसी भी स्थिति को हल कर सकते हैं । लेकिन जब से आप अनुमान लगा रहे हैं, आप समाधान देने से पहले केवल कुछ मिनटों के लिए किसी दिए गए घन को देख सकते हैं। क्या आप एक अच्छा अनुमान दे सकते हैं? नहीं, कभी-कभी किसी प्रक्रिया का अनुमान लगाने की प्रक्रिया को करने में अधिक समय लगता है।

एक और सरल प्रणाली: पिनोच्चियो। एक लकड़ी के ऑटोमेटन, जब वह झूठ बोलता है तो उसकी नाक का टुकड़ा बढ़ता है। क्या होता है जब पिनोचियो आराम पर होता है, और फिर कहता है "मेरी नाक बढ़ रही है"? कुछ प्रणालियाँ भविष्यवाणी के लिए उत्तरदायी नहीं हैं, वे अयोग्य हैं।

ये दो समस्याएं बिल्ट-इन अधिकांश सॉफ्टवेयर सिस्टम हैं। जिसकी वजह से, आपको कभी भी अनुमान नहीं मिलेगा + +- 10%।

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


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

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

@ मुझे लगता है कि मुझे उनके बुलबुले को तोड़ना होगा, समस्या यह है कि यह ऊपर से आता है। अगर मैं नहीं कर सकता, तो मुझे दुर्भाग्य से भारी गद्देदार अनुमानों का सहारा लेना पड़ेगा ।
तुलियो एफ

3
रूबिक्स क्यूब सादृश्य केवल तभी काम करता है जब आप उस घन को हल करने के लिए आधे रास्ते को पार कर लेते हैं, ऊपरी प्रबंधन यह तय करता है कि सभी चेहरों पर ठोस रंग भी वेब 1.0 हैं और वे इसके बजाय नोस्कल अजाक्स धारियां चाहते हैं। और फिर उपयोगकर्ता आपको बताते हैं कि वे इसका उपयोग नहीं कर सकते हैं जब तक कि इसका सातवां हिस्सा न हो, इस पर एक बिल्ली की तस्वीर ...
टैकोरो

1
मुझे एक बार मेरी कंपनी ने दूसरी कंपनी को आउटसोर्स किया था, जिसने मुझे बताया था कि वे अनुमानों के लिए +/- 10% त्रुटि मार्जिन स्वीकार करते हैं, जो कि हास्यास्पद है। उन्हें हर कार्य के लिए पहले से अनुमान लगाने की आवश्यकता होती है और अगर मैं यह कहने की हिम्मत करता हूं कि मैंने इसे अनुमान के भीतर नहीं बनाया है। मैंने अपनी अपेक्षाओं को पूरा करने के लिए अपने निजी समय का उपयोग किया, अंत में उन्होंने हमारे साथ सहयोग को यह कहते हुए समाप्त कर दिया कि मेरे कुछ बगफिक्स विफल हो गए हैं (शायद 50 में से 3), ऐसे लोगों में एक क्रूर मानसिकता होती है और वे कभी भी अपने जैसा व्यवहार नहीं करेंगे; उनके लिए मैं सिर्फ कुछ आउटसोर्स आदमी था। मेरे लिए महान सबक, कभी भी अपने निजी समय का उपयोग न करें।
इवान जी

3

मैं "लक्ष्य त्रुटि मार्जिन" के किसी भी प्रकार के बारे में बहुत संकोच करूंगा क्योंकि यह वास्तव में परियोजना पर निर्भर करता है। यदि आप यह अनुमान लगाने की कोशिश कर रहे हैं कि एक नया सीआरएम सिस्टम स्थापित करने, कॉन्फ़िगर करने और अनुकूलित करने में कितना समय लगने वाला है, जहां कोई भी निश्चित नहीं है कि किस प्रकार के अनुकूलन आवश्यक होने जा रहे हैं और किस तरह की व्यावसायिक प्रक्रिया में बदलाव की आवश्यकता होगी और कंपनी के पास समान बड़ी परियोजनाओं का कोई इतिहास नहीं है, आपकी त्रुटि मार्जिन बहुत बड़ी होनी चाहिए (यानी आप अनुमान लगा सकते हैं कि इसमें 18 महीने +/- 50% लगेंगे और 9-27 महीने लगेंगे)। जैसे-जैसे परियोजना आगे बढ़ती है, विनिर्देशों को स्पष्ट किया जाता है, व्यापार प्रक्रियाओं के बारे में निर्णय लिया जाता है, आपके डेवलपर्स को और अधिक आराम मिलता है, आदि उन त्रुटि मार्जिन को तंग करना चाहिए। यदि आप अनुमान लगाने की कोशिश कर रहे हैं कि जब आप 101 वें बुनियादी ईकॉमर्स साइट का निर्माण करने जा रहे हैं, तो यह कितना लंबा होगा आपको पहले 100 से एक अच्छा इतिहास मिला है, आप अधिक सटीक अनुमान देने में सक्षम होने की उम्मीद करेंगे। अधिकांश परियोजनाएं, हालांकि, बीच में कहीं गिरने वाली हैं।

अब, यदि आप एक सीमा के बजाय एक ही संख्या को उद्धृत कर रहे हैं, तो उत्तर संभवतः सीमा को उद्धृत करना शुरू करना है ताकि अनुमान लगाने वाला व्यक्ति यह निर्दिष्ट कर सके कि वे अपने अनुमान के कितने सटीक होने की उम्मीद करते हैं।


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

1

आपके द्वारा एकत्र किए गए वास्तविक आंकड़ों के आधार पर अच्छा आधार रेखा होगा ।

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

यह वहाँ भी नहीं रोकता है; यह अनुमान लगाने में कि किन कारणों से अनुमान लगाया जा सकता है, आपके भविष्य के अनुमानों की सटीकता में सुधार कर सकते हैं। नोट: वे अभी भी अनुमान हैं , और इस तरह, केवल अनुमान हैं

अनुमान पहले अनुमान के बाद भी समाप्त नहीं होता है; यह कुछ ऐसा है जिसे समायोजित किया जा सकता है क्योंकि परियोजना आगे बढ़ती है क्योंकि अधिक ज्ञान प्राप्त होता है, यह त्रुटि के संभावित मार्जिन को कम करता है जैसा कि आप साथ चलते हैं। संचार के साथ आप जितना अधिक खुले हैं, पहले के आश्चर्य पर चर्चा की जाती है - जिससे लोग कम आश्चर्यचकित हुए और परियोजना या ग्राहकों की अपेक्षाओं में समायोजन करने के लिए अधिक समय दे सकें।


दूसरा, शायद त्रुटि मार्जिन को संभालने का एक बेहतर तरीका त्रुटि के केवल% मार्जिन के बजाय ' विश्वास आंतरिक ' है। आपने एक विलक्षण तिथि के बजाय एक विश्वास अंतराल पर डिलीवरी की अनुमानित तिथि के आधार पर अनुमान लगाया है।

PERT सांख्यिकीय तर्क के आधार पर अनुमान को संभालने के लिए एक रूपरेखा का एक उदाहरण है। उदाहरण के लिए:

"अब मुझे जो पता है उसके आधार पर, हमारे पास 90% आत्मविश्वास का स्तर है जिसे हम 8 महीने में वितरित कर सकते हैं। 10 महीनों में 95% आत्मविश्वास, 2 वर्षों में 99% आत्मविश्वास, आदि"

यहां ध्यान दें: वे जितना अधिक आत्मविश्वास चाहते हैं, उतना बड़ा अनुमान होगा। जटिलता (उर्फ, आप कितने सटीक हो सकते हैं) के आधार पर, यह 80% और 90% के बीच एक छोटा सा अंतर हो सकता है, या यह बहुत बड़ा हो सकता है!


अंत में - सौभाग्य;) यदि आप कभी सॉफ्टवेयर आकलन में 'अधिकतम त्रुटि मार्जिन' को हल करते हैं, तो आप 'हमारे सभी अनुमान +/- 10%' जैसे कुछ निर्दिष्ट कर सकते हैं, तो बाकी बॉक्स के लिए बॉक्स-ऑफिस मूवी सुनिश्चित करें सॉफ्टवेयर उद्योग में हमें। मैं ऑफिस स्पेस और द मैट्रिक्स: डी के बीच एक क्रॉस की तरह कुछ सोच रहा हूं


1

यह वास्तव में परियोजना के आकार और जटिलता पर बहुत कुछ निर्भर करता है।

यदि आपका प्रोजेक्ट अनुमान 1 सप्ताह का है - 10% उचित है। इसका अर्थ है +/- 1/2 दिन।
यदि यह 1 महीने है 10% अस्थिर है - मेरे अनुभव से यह अनुमान लगाना असंभव है कि आप 1 महीने में क्या खोजेंगे।

एक महीने से अधिक - सभी दांव बंद हैं :)।

ये प्रति डेवलपर हैं - इसलिए 4 डेवलपर टीम 1week == 1 महीने के लिए।

एक 4 डेवलपर टीम के लिए, ज्यादातर अपनी सुविधाओं की एक सूची के साथ आने के लिए अच्छा है जो 1 महीने में किया जा सकता है, और उन सुविधाओं के 10% के भीतर हो सकता है। फिर, अगले महीने के लिए फिर से अनुमान लगाएं।

मैंने यहाँ कुछ भोली धारणाएँ की हैं

  1. सभी डेवलपर्स समानांतर में काम कर सकते हैं।
  2. परीक्षक नहीं माना जाता है - उनके पास परीक्षण के लिए कुछ समय होना चाहिए
  3. सभी डेवलपर्स समान हैं - फ्रंटेंड, बैकएंड, डिजाइनर आदि ...

आपको उन कारकों को शामिल करना होगा .. लेकिन यह सामान्य विचार है।


1

बहुत सारे चर हैं:

  1. प्रोजेक्ट कब तक है?

  2. परियोजना का प्रबंधन कैसे होगा? झरना? चुस्त? जमघट?

मैं प्रश्न झरना से मानूंगा। यदि ऐसा है तो आप मार्जिन के लिए अनुरोध को देखते हुए कुछ प्रतिशत तक विफल होने की उम्मीद कर रहे हैं।

यदि उत्तर कुछ चुस्त कार्यप्रणाली है, विशेष रूप से SCRUM जैसा कुछ है। यह वास्तव में कोई फर्क नहीं पड़ता कि मार्जिन प्रतिशत क्या है। 2 सप्ताह के स्प्रिंट पर त्रुटि का 50% मार्जिन 1 सप्ताह है, 1 सप्ताह के स्प्रिंट पर यह 2.5 दिन है, दोनों सबसे खराब स्थिति हैं। ऐसा इसलिए है क्योंकि हर स्प्रिंट को डिलीवरी की तारीख फिर से अनुमानित की जाती है, और यह कम और कम होने के बजाय समय के साथ अधिक सटीक होगा।

झरने के साथ त्रुटि का 50% मार्जिन या तो नहीं सुना जाता है, लेकिन एक 12 महीने की परियोजना पर जो 6 महीने है, और यह वास्तव में पता नहीं चलता / प्रशंसा करता है कि 10 महीने तक 12 में खराब है।


0

जब मैं सॉफ्टवेयर टीमों का नेतृत्व करता था, लगभग क्रेटेशियस / तृतीयक सीमा के आसपास, हम वास्तव में अनुमान के आधार पर +/- 10% प्राप्त करने के करीब आए। अगर यह मेरी बहुत ही मंद स्मृति है, तो यह लगभग 15/8% था। लेकिन यह इसलिए था क्योंकि हम उन चीजों के लिए अनुमान लगा रहे थे जो हम पहले से ही कर चुके थे : अपेक्षाकृत सरल रीयल-टाइम संचार फर्मवेयर, जो ए से बाइट लेते थे और उन्हें एक ऐसी भाषा का उपयोग करके बी में ले जाते थे, जिससे हम परिचित थे, हमारे द्वारा डिजाइन किए गए एक वास्तविक समय के वातावरण में , कुछ कार्यालयों से दूर लोगों द्वारा घर में डिज़ाइन किए गए हार्डवेयर से बात करना। वस्तुतः वर्षों के लिए उपरोक्त विषय पर बहुत से मामूली संस्करण ।

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


0

आपने शायद 300% बात सही सुनी है?

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

मुझे लगता है कि हम वास्तव में बुरा अनुमान लगा रहे हैं क्योंकि:

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

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

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

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