हम डेडलाइन को क्यों बाधित करना जारी रखेंगे

स्पष्ट चीजों को बार-बार लिखे जाने की आवश्यकता है। ताकि वे लोगों की नजर में अपना सबूत न खो दें। ताकि वास्तविकता के उत्पीड़न से प्रेरित लोग स्पष्ट को महत्वहीन न कह सकें। ताकि वे स्पष्ट चीजों की उपेक्षा का औचित्य साबित करने के लिए सरल छद्म तर्क के साथ नहीं आ सके। स्पष्ट चीजें माफ नहीं करती हैं। और परियोजना की योजना कोई अपवाद नहीं है।


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

समस्या का बयान

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

साइड व्यू

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

दो प्रक्रियाएँ

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

समय की अटकलें

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

समय की पाबंदी की जीत

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

क्या करें?

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