संस्थान एल्गोरिदम, डेटा संरचना, OOP सिखाता है। एक अच्छे मामले में, वे डिज़ाइन पैटर्न या मल्टी-थ्रेडेड प्रोग्रामिंग के बारे में बात कर सकते हैं। लेकिन मैंने श्रम लागतों का सही मूल्यांकन कैसे करें, इसके बारे में नहीं सुना।

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

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

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

विरोधी मूल्यांकन पैटर्न

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

एक तिपहिया, लेकिन अप्रिय

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

1. क्या वैधता के लिए ग्राहक को दर्ज किए गए फोन नंबर की आवश्यकता है?
2. यदि ग्राहक को फोन नंबर सत्यापन प्रणाली की आवश्यकता है, तो वह कौन सा संस्करण पसंद करेगा - सस्ता या महंगा?
3. यदि आप फोन नंबरों की जाँच का एक सस्ता संस्करण लागू करते हैं, तो क्या ग्राहक बाद में महंगे स्विच करना चाहेगा?
4. क्या फोन नंबर की जांच के लिए तैयार सिस्टम का उपयोग करना संभव है या, कुछ डिज़ाइन प्रतिबंधों के कारण, आपको अपना खुद का विकास करने की आवश्यकता है?
5. सत्यापन प्रणाली कैसे तैयार की जाएगी?
6. फ़ोन नंबर सत्यापन प्रणाली को प्रोग्राम करने में कितना समय लगता है?

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

"सूजन" का एक और उत्कृष्ट उदाहरण एक प्राथमिक आवश्यकता प्रतीत होगी, लेख में पढ़ें " दो सप्ताह कैसे हैं? "

अनिश्चितता का शंकु

सॉफ्टवेयर विकास - और कई अन्य परियोजनाएं - हजारों समाधानों से युक्त हैं। शोधकर्ताओं ने पाया कि अनिश्चितता के अनुमानित स्तरों में निहित विभिन्न चरणों में परियोजना का अनुमान है। अनिश्चितता का शंकु दिखाता है कि परियोजना की प्रगति के अनुसार अनुमान अधिक सटीक हो जाते हैं। कृपया ध्यान दें कि प्रारंभिक अवधारणा के चरण में (जहां अनुमान अक्सर किए जाते हैं और दायित्वों को बनाया जाता है), त्रुटि 400% (चार सौ प्रतिशत, कार्ल!) हो सकती है। विस्तृत डिजाइन के पूरा होने के बाद प्रतिबद्धता बनाने के लिए यह इष्टतम है।

पौराणिक पुरुष-मास

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

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


प्रोजेक्ट टीम रैंप // इवान एवाज़ोव्स्की, 1850 के साथ सामना करने की कोशिश कर रही है

यदि 8 लोग 10 महीने में एक कार्यक्रम लिख सकते हैं, तो क्या एक महीने में 80 लोग एक ही कार्यक्रम लिख सकते हैं? अत्यधिक कसने की समयसीमा की अक्षमता चरम मामलों में विशेष रूप से स्पष्ट हो जाती है - जैसे कि 1,600 लोग जिन्हें एक दिन में एक कार्यक्रम लिखने की आवश्यकता होती है। फ्रेडरिक ब्रूक्स द्वारा इसी नाम की पुस्तक में इसके बारे में और पढ़ें।

मूल्यांकन पैटर्न

इसलिए, समस्याओं के साथ सब कुछ स्पष्ट है। क्या किया जा सकता है?

सड़न

एक बड़े कार्य का मूल्यांकन करने के बजाय, इसे कई छोटे लोगों में विभाजित करना बेहतर है, उनका मूल्यांकन करें, और प्रारंभिक ग्रेड के योग के रूप में अंतिम ग्रेड प्राप्त करें। इस प्रकार, हम तुरंत एक पत्थर से चार पक्षियों को मार देते हैं:

1. हम काम के दायरे को बेहतर तरीके से समझते हैं। किसी कार्य को विघटित करने के लिए, आपको आवश्यकताओं को पढ़ना होगा। अकथनीय जगहें तुरंत सामने आएंगी। गलत समझ की आवश्यकताओं का जोखिम कम हो जाता है।
2. आवश्यकताओं के अधिक विस्तृत विश्लेषण के विश्लेषण के दौरान, ज्ञान को व्यवस्थित करने की विचार प्रक्रिया स्वचालित रूप से शुरू होती है। यह काम के कुछ हिस्से को भूलने के जोखिम को कम करता है, जैसे कि रिफैक्टरिंग, टेस्ट ऑटोमेशन, या बिछाने और तैनाती के अतिरिक्त प्रयास
3. अपघटन परिणाम का उपयोग परियोजना प्रबंधन के लिए किया जा सकता है, बशर्ते कि दोनों प्रक्रियाओं के लिए एक उपकरण का उपयोग किया गया था (इस मुद्दे पर बाद में और अधिक विस्तार से चर्चा की गई है)।
4. यदि हम अपघटन के दौरान प्राप्त प्रत्येक समस्या के अनुमान की औसत त्रुटि को मापते हैं और इस त्रुटि की कुल अनुमान की त्रुटि से तुलना करते हैं, तो यह पता चलता है कि कुल त्रुटि औसत से कम है। दूसरे शब्दों में, ऐसा मूल्यांकन अधिक सटीक है (वास्तविक श्रम लागत के करीब)। पहली नज़र में, यह कथन काउंटर-सहज ज्ञान युक्त है। यदि हम प्रत्येक विघटित समस्या का मूल्यांकन करने में गलती करते हैं तो अंतिम मूल्यांकन अधिक सटीक कैसे हो सकता है? एक उदाहरण पर विचार करें। एक नया रूप बनाने के लिए आपको इसकी आवश्यकता है: a) बैकएंड पर कोड लिखें, b) लेआउट बनाएं और फ्रंटएंड, c) कोड पर कोड लिखें और परीक्षण करें। टास्क ए का मूल्यांकन 5 घंटे, कार्यों B और C का 3 घंटे प्रत्येक पर किया गया था। कुल स्कोर 11 घंटे था। वास्तव में, बैकएंड 2 घंटे में किया गया था, फॉर्म में 4 लिया गया था, और परीक्षण और फिक्सिंग कीड़े ने एक और 5 लिया। कुल कार्यभार 11 घंटे था। आदर्श माना जाता है। इसके अलावा, कार्य A का मूल्यांकन करने में त्रुटि 3 घंटे है, कार्य B 1 घंटे है, और C 2 घंटे है। औसत त्रुटि 3 घंटे है। तथ्य यह है कि अनुमानों को समझने और उन्हें कम करने की त्रुटियां एक दूसरे को रद्द करती हैं। बैकएंड पर सहेजे गए 3 घंटे के फ्रंट-एंड और परीक्षण चरणों में 1 और 2 घंटे के अंतराल के लिए मुआवजा दिया। वास्तविक श्रम एक यादृच्छिक चर है जो कई कारकों पर निर्भर करता है। यदि आप बीमार हो जाते हैं, तो आपके लिए ध्यान केंद्रित करना मुश्किल होगा और तीन घंटे के बजाय छह लग सकते हैं। या कुछ अनपेक्षित बग सामने आएंगे जिन्हें पूरे दिन खोजा जाना और ठीक करना होगा। या, इसके विपरीत, यह पता चल सकता है कि अपने स्वयं के घटक को लिखने के बजाय, आप किसी मौजूदा का उपयोग कर सकते हैं, आदि। सकारात्मक और नकारात्मक विचलन एक दूसरे को रद्द कर देंगे। इस प्रकार, कुल त्रुटि घट जाएगी।

सुविधाएँ और कार्य

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

एक सदस्य एक विशेषता के लिए जिम्मेदार है। कार्यान्वयन में कोई उसकी मदद कर सकता है, लेकिन एक व्यक्ति परीक्षण में गुजरता है। संशोधन के लिए उन्हें यह कार्य वापस भी किया जा रहा है। टीम के संगठन के आधार पर, यह एक टीम लीडर या सीधे डेवलपर हो सकता है।

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

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

समूहों में मूल्यांकन, पोकर योजना

प्रोग्रामर काम की मात्रा के बारे में बहुत आशावादी हैं। विभिन्न स्रोतों के अनुसार, 20-30% की सीमा में अक्सर मूल्यांकन का अंतर होता है। हालाँकि, समूहों में त्रुटि कम हो जाती है। यह विभिन्न दृष्टिकोणों और स्वभाव का मूल्यांकन करने के कारण बेहतर विश्लेषण के कारण है।
एजाइल की बढ़ती लोकप्रियता के साथ सबसे आम अभ्यास " पोकर योजना " का अभ्यास है। हालांकि, दो समस्याएं समूह मूल्यांकन से जुड़ी हैं:

1. सामाजिक दबाव
2. समय की लागत

सामाजिक दबाव

लगभग किसी भी समूह में, प्रतिभागियों का अनुभव और व्यक्तिगत प्रभावशीलता अलग-अलग होगी। यदि टीम के पास एक मजबूत टीम / टेक है - लीड / लीड प्रोग्रामर, अन्य सदस्य असहज महसूस कर सकते हैं और जानबूझकर ग्रेड को कम कर सकते हैं: "ठीक है, वास्या यह कैसे कर सकता है, लेकिन क्या मैं बदतर हूं? मैं भी ऐसा कर सकता हूं! ” कारण अलग-अलग हो सकते हैं: वास्तव में इससे बेहतर प्रतीत होने की इच्छा, प्रतिस्पर्धा या सिर्फ अनुरूपता है। परिणाम एक है: एक समूह मूल्यांकन अपने सभी फायदे खो देता है और व्यक्तिगत हो जाता है। टिम्लिड निशान देता है, और बाकी लोग केवल उसे स्वीकार करते हैं।

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

कई मुख्य सिफारिशें हैं:

1. अधिकांश रेटिंग को कम करके आंका जाता है। दो रेटिंग के बीच चयन नहीं कर सकते? जो बड़ा है, उसे ले लो।
2. मूल्यांकन के बारे में निश्चित नहीं है - कार्ड को फेंक दें "?" या एक महान रेटिंग। शायद लगभग कभी नहीं किया जाता है।
3. हमेशा योजना और तथ्य की तुलना करें। यदि आप जानते हैं कि आप दो बार फिट नहीं होते हैं, तो आप जो सोचते हैं उससे दो गुना अधिक अनुमान दें। ओवरस्टेट करना शुरू कर दिया? अपने दिमाग में डेढ़ से गुणा करें। कुछ पुनरावृत्तियों के बाद, आपके ग्रेड की गुणवत्ता में काफी सुधार होना चाहिए।

समय की लागत

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

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

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

निर्भरता लेआउट, गैंट चार्ट

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

1. DB तालिका
2. बैकएंड कोड
3. फ्रंटेंड कोड

इस क्रम में कार्य करना तकनीकी दृष्टि से सबसे आसान है। हालांकि, वास्तव में अलग-अलग विशेषज्ञताओं हैं। एक फ्रंट-एंड विशेषज्ञ को पहले मुक्त करने के लिए निर्धारित किया जा सकता है। निष्क्रिय होने के बजाय, मॉक या हार्डकोड डेटा के साथ सर्वर अनुरोध को बदलकर यूआई विकसित करना शुरू करना अधिक तर्कसंगत है। फिर जब तक एपीआई तैयार हो जाता है, तब तक यह केवल कॉल को एक वास्तविक विधि ... सिद्धांत में कोड को बदलने के लिए रहता है। व्यवहार में, समानता का अधिकतम स्तर निम्नानुसार प्राप्त किया जा सकता है:

1. सबसे पहले हम एपीआई विनिर्देश पर सहमत होने के लिए जल्दी से आगे बढ़ते हैं
2. फिर जो हाथ में है, उसके आधार पर डेटा को पीछे या सामने की तरफ हार्डकोड करें।
3. उसी समय, हम डेटाबेस, बैकएंड और फ्रंट-एंड करते हैं। डेटाबेस और बैकएंड एक दूसरे को आंशिक रूप से ब्लॉक करते हैं, लेकिन अक्सर इन दक्षताओं को एक व्यक्ति में जोड़ा जाता है और काम वास्तव में क्रमिक रूप से चला जाता है: पहले एक डेटाबेस, फिर एक बैकेंड
4. हम सब कुछ इकट्ठा करते हैं और परीक्षण करते हैं
5. हम बग्स को ठीक करते हैं और फिर से परीक्षण करते हैं

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

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

व्यवसाय प्रक्रियाओं को स्वचालित करने के कार्यों में, आमतौर पर कई बड़े लॉकिंग नोड्स के साथ संबंधित कार्यों के कई लंबे "सांप" प्राप्त होते हैं। सबसे अधिक, प्रारंभिक योजना संसाधन उपयोग और / या कैलेंडर के संदर्भ में बहुत लंबे समय तक प्रभावी नहीं है। श्रम लागत के आकलन का संशोधन तेजी से होगा - विकल्प नहीं। इसलिए, आकलन सबसे अधिक आशावादी है। हमें वापस विघटन के लिए जाना है, उन श्रृंखलाओं की तलाश करें जो बहुत लंबी हैं और समानता की डिग्री बढ़ाने के लिए अतिरिक्त "कांटे" जोड़ते हैं। इस प्रकार, कुल श्रम लागत में वृद्धि के कारण (अधिक लोग एक परियोजना पर एक साथ काम कर रहे हैं), परियोजना की कैलेंडर अवधि कम हो जाती है। "पौराणिक पुरुष-महीना" याद है? यह संभावना नहीं है कि एक योजना 30% से अधिक सिकुड़ जाएगी। बजट और सहमत होने की समय सीमा के लिए, योजना की कई बार समीक्षा की जा सकती है। प्रक्रिया को तेज और आसान बनाने के लिए कई तरकीबें हैं।

टास्क लॉक

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

महत्वपूर्ण पथ, आगे जोखिम

. , ( ), , , , . , , , , , , . , .

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

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

स्वीकृति मानदंड, परीक्षण मामले

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

परियोजना प्रबंधन

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

समय ट्रैकिंग उर्फ ​​टाइम ट्रैकिंग

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

निष्कर्ष

1. मूल्यांकन कठिन है
2. अपघटन आपको आवश्यकताओं में अंतराल खोजने और मूल्यांकन की गुणवत्ता में सुधार करने की अनुमति देता है
3. समूह स्कोर व्यक्तिगत की तुलना में अधिक सटीक हैं, पोकर का उपयोग करें
4. ब्लॉकर्स, परीक्षण के मामले और औपचारिक स्वीकृति मानदंड संचार में सुधार करते हैं, जिससे परियोजना की सफलता की संभावना बढ़ जाती है
5. आपको प्रोजेक्ट के महत्वपूर्ण पथ पर सबसे जोखिम भरे कार्यों के साथ शुरू करने की आवश्यकता है
6. मूल्यांकन एक बार की कार्रवाई नहीं है, लेकिन परियोजना प्रबंधन से अविभाज्य प्रक्रिया है
7. काम के समय को ध्यान में रखे बिना, परियोजना की स्थिति को अद्यतन रखना और अपने अनुमानों को समायोजित करना असंभव है

परियोजना मूल्यांकन के बारे में अधिक जानना चाहते हैं?

स्टीव मैककोनेल की पुस्तक " एक सॉफ्टवेयर परियोजना की लागत कितनी है " और इस विषय पर अन्य लेख हैबे पर पढ़ें :

1. habr.com/ru/company/infopulse/blog/170777
2. habr.com/ru/post/308494
3. habr.com/ru/company/ruswizards/blog/151029
4. habr.com/ru/company/mindbox/blog/321270
5. habr.com/ru/post/307820