जीआईएस आवास और सांप्रदायिक सेवाओं पर रिलीज का प्रबंधन - हम अनुभव साझा करते हैं और अंतर्ज्ञान के साथ लड़ते हैं

क्यों एक उड़ान के लिए देर हो रही है और उड़ान नहीं हमेशा एक बुरी चीज नहीं है? गोदी के लिए देर होने का दोष किसे दिया जाए? अग्रिम में हवाई अड्डे पर क्यों आते हैं? क्या ए 380 एस्ट्राखान के लिए उड़ान भर सकता है? अंतर्ज्ञान हमेशा काम क्यों नहीं करता है? आश्चर्य होता है - कभी नहीं हुआ और यहाँ फिर से? लैंडिंग के बाद यात्री पायलट को क्यों मारते हैं?

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

प्रस्तुत? इसलिए, फिलहाल ऐसी परियोजना जीआईएस आवास और सांप्रदायिक सेवा परियोजना है, जिसके बारे में हमने पहले बात की थी और अब हम इसे जारी रखना चाहते हैं।

स्रोत

राइट बंधुओं का पहला अनुभव

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

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

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

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

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

इस लेख में हम दो मुख्य, हमारी राय में, जीआईएस आवास और सांप्रदायिक सेवाओं के पैमाने पर आईटी प्रणालियों में प्रभावी रिलीज प्रक्रिया को रेखांकित करने वाले तरीकों का वर्णन करेंगे:

• कार्यक्षमता के नियमित वितरण की एक योजना का उपयोग,
• छोटा रिलीज चक्र।

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

जब हमने रिलीज प्रबंधन से संबंधित हमारी आंतरिक प्रक्रियाओं का विश्लेषण किया, तो मेरे सिर में एक आधुनिक एयरलाइन के काम के साथ एक जुड़ाव दिखाई दिया।

नियमित रूप से हवाई यातायात

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

स्रोत

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

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

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

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

महत्वपूर्ण बिंदु यह है कि रिलीज की तारीख बाद में नहीं बदलती है। यदि संस्करण कुछ तारीख के लिए योजनाबद्ध है, तो हमें एक केक में तोड़ना चाहिए, लेकिन नियोजित समय का सामना करना पड़ता है।

आगे, हम बताएंगे कि क्यों और क्यों।

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

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

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

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

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

पंजीकरण के बाद एक विमान में सवार होना

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

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

स्रोत

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

यह बुरा क्यों है?

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

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

दुर्भाग्य से, ऐसी परिस्थितियाँ जब कोई बहुत महत्वपूर्ण कार्य होता है और वर्तमान रिलीज़ में इसे जारी करना आवश्यक होता है। लेकिन मुख्य विचार यह है कि ऐसी स्थितियों को आम तौर पर स्वीकार किए जाने वाले अभ्यास और प्रोत्साहित नहीं किया जाना चाहिए, बल्कि एक समस्या के रूप में पहचाना जाता है और "पूर्वव्यापी" माना जाता है।

वीआईपी पैसेंजर की वजह से फ्लाइट की देरी

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

स्रोत

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

रिलीज की प्रक्रिया में, अगर अचानक कुछ काम के लिए निर्धारित समय नहीं है, तो पूरी रिलीज को स्थानांतरित करने के लिए एक महान प्रलोभन भी है - उदाहरण के लिए, एक सप्ताह तक। ऐसा लगता है कि यह एक आसान और अच्छा समाधान है, खासकर यदि यह कार्य मुख्य ग्राहक के नियंत्रण में है।

आइए देखें कि यह सब आखिर किस वजह से होता है।

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

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

इससे क्या होता है? इसके अलावा, यदि कोई आवश्यक दोष या कार्य उत्पन्न होता है, तो ग्राहक इसे किसी विशेष रिलीज के हिस्से के रूप में जारी करने के लिए सहमत नहीं होता है, लेकिन इसके लिए एक विशेष संस्करण या हॉटफिक्स की आवश्यकता होती है। नतीजतन, हमारे पास महत्वपूर्ण अतिरिक्त लागतें हैं।

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

एक बड़ा विमान हमेशा बेहतर क्यों नहीं होता है

एयरलाइन मार्ग पर विभिन्न प्रकार के विमानों का उपयोग कर सकती है: 75-110 यात्रियों के लिए क्षेत्रीय विमान (प्रकार एसएसजे -100 ), या 140-180 यात्रियों के लिए संकीर्ण शरीर वाले विमान (टाइप ए 320 , बोइंग 737 ), या 200-300 यात्रियों के लिए चौड़े शरीर वाले विमान (प्रकार A330) , A340 ) या A380 जैसे राक्षस, 525 से 853 यात्रियों को ले जाने में सक्षम हैं। सरलीकृत रूप से, हम यह मान सकते हैं कि एयरलाइन वांछित प्रकार के विमान का चयन करती है और यात्री की इच्छा के अनुसार एक दिन में जितनी अधिक से अधिक उड़ानें हों, एयरलाइन की इच्छा होती है और अपने लाभ को अधिकतम करने के लिए एक यात्री के परिवहन की लागत को कम करने की एयरलाइन की इच्छा।

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

रिलीज़ प्रक्रिया में लगभग एक ही तर्क संचालित होता है। रिलीज़ संस्करणों के बीच का समय जितना कम होगा, ग्राहक के लिए बेहतर होगा। , . , , . , , .

.

, . , , , , , . , , “” . , , . . , ( , , , , , , ).

1. ( )

, “ , , ” , . , . , . , , — , .

- , . .

—

, . , . , , - , .

- , — , , ( ). , , , . , , . — , (- ) . , , . , , , “” . , , . , . , 1,5-2 , 1,5 , -.

, :
— — , — , — , .
:
— , , . .

, , . .

. , , .. , . , , . .



, . , , , . , !

, — . , , , . , , . . , . , , , . , , . , , .

, , , . , 4 , 2-3. . , .

, , .

. ( — ), .. . , - , , . - , . — , . . , , , . , ( , , , , , , , ..), . , , 2018 2018 , , ASAP . 4-5 ! 5 , 2-3 , 1-1,5 .

, , — .

!

. , ! .

, - , . , , . , , , - , . , , .

, , , , , , . — , .



, - , - . - . , . , , . , , , .

, . . , , - , .

, . , - , , .

, . , :

• , , , ,
• , , ,
• , ..

.

. ? ? ?