हम व्यापार को समझाते हैं कि हमारे पास ऐसी "अंजीर" रेटिंग क्यों है

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

आप विकास की जटिलता का सटीक आकलन क्यों नहीं दे सकते?
आप सभी काम दो बार तेजी से पूरा क्यों नहीं कर सकते?

एक गंभीर कंपनी में, जिसमें मैंने व्यवसाय की एक नई पंक्ति, कस्टम सॉफ्टवेयर विकास के निर्माण में भाग लिया, मैंने सभी व्यवसायियों को इन सवालों का तुरंत जवाब देने के लिए एक छोटी संगोष्ठी आयोजित की।

आकलन हमेशा एक संभाव्य मात्रा है।

क्योंकि मूल्यांकन हमेशा अनिश्चितता की स्थिति में किया जाता है। इसलिए, एक एकल संख्या कभी भी एक अनुमान नहीं है। मूल्यांकन हमेशा कम से कम दो नंबर का होता है। से ...

फिर आपकी पसंद, किस कीमत पर बेचना है।

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

यदि आप गारंटीकृत लाभ चाहते हैं - एक निराशावादी मूल्यांकन के अनुसार बेचें।

इसके अलावा, RFP प्रोसेसिंग स्टेज पर ग्रेड X / 2 से 2X बहुत अच्छे ग्रेड हैं। क्योंकि, अनिश्चितता।

अनिश्चितता क्या है

मैं एक उदाहरण के साथ समझाने की कोशिश करूंगा। एक डेवलपर के स्थान पर खुद की कल्पना करें, जिसका मूल्यांकन करने की आवश्यकता है। मूल्यांकन हमेशा दिया जाना चाहिए। प्रश्न केवल उनकी अनिश्चितता की सीमा तक है - आत्मविश्वास अंतराल की चौड़ाई।

टेस्ट। क्या आप एक अच्छे मूल्यांकनकर्ता हैं?

निम्नलिखित मानों के लिए ... से ... का अनुमान दें:

सीआईएस में जिन शहरों में मेट्रो है।
एथिल अल्कोहल (° C) का गलनांक।
नीपर नदी की लंबाई (किमी)।
गैलापागोस कछुआ (वर्ष) की अधिकतम जीवन प्रत्याशा।
फिल्म "स्टेलिनग्राद" (मिलियन रूबल) के सीआईएस में पहले सप्ताहांत का कैश डेस्क।

सॉफ्टवेयर विकास में अनिश्चितता कहां से आती है

एक और उदाहरण। एक नए ग्राहक के संपर्क फोन नंबर दर्ज करने के लिए एक सरल कार्य विकसित करने की जटिलता का मूल्यांकन करें।

मैं 20 मिनट के जवाब को सही कहूंगा - गलत। सही उत्तर में दो रेटिंग होनी चाहिए।



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

इस तकनीक के अनुसार गणना किए गए मानव कारक के प्रभाव का एक चार्ट यहां दिया गया है।



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

और आखिरी वाला। समय के बारे में

यहां उसी बारी बोहेम के कानून हैं, जो उन्होंने 80 के दशक के मध्य में प्राप्त किया था।

लागत के दृष्टिकोण से एक इष्टतम है, पहली डिलीवरी के लिए अनुसूची का नेतृत्व समय: टी = 2.5 (एन एच * एम) ^ 1/3।

लागत वक्र धीरे-धीरे बढ़ता है यदि नियोजित अनुसूची इष्टतम से अधिक लंबी हो। इसके लिए आवंटित कार्य में हर समय लगता है।

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

कुछ इस तरह।

गुड लक।