मिश्रित चुस्त - व्यावसायिक अनुप्रयोगों को लागू करते समय झरना दृष्टिकोण (उर्फ चंचल की तरह)

आधुनिक आईटी तकनीकों की दुनिया में, जब Google Play और Appstore से रोज़ाना कई एप्लिकेशन अपडेट के बारे में सूचित करते हैं, तो ईआरपी सिस्टम "परियोजना 9 (आशावादी) से लेकर 12 महीने (यथार्थवादी) तक के कार्यान्वयन के लिए प्रोजेक्ट टीम से सुनना बहुत आम है। इसके अलावा, अधिक जटिल परियोजनाएं हैं। जिन कंपनियों में मेरे दोस्त ने काम किया उनमें से एक में, प्रक्रियाओं के डिजाइन बनाने और हस्ताक्षर करने का केवल चरण 6 महीने तक चला। डिजाइन दस्तावेज़ की मात्रा काफी प्रभावशाली निकली और मुद्रित रूप में, बहुत अच्छी तरह से प्राचीन चीन के एक योद्धा के जीवन को बचा सकती थी (वे कहते हैं कि उन्होंने अपने कवच के लिए सामग्री के रूप में कागज का इस्तेमाल किया था)। प्राचीन चीन के दिन बीत चुके हैं, लेकिन आज कागज का यह ढेर बचता है, यदि जीवन नहीं है, तो सिस्टम को संचालन में लाने के चरण में कम से कम सलाहकारों के तंत्रिका तंत्र। लेकिन एक डिज़ाइन डॉक्यूमेंट जो नहीं बचाता है, वह प्रोजेक्ट के लॉन्च के समय में एक बदलाव है और वाणिज्यिक संचालन के समय तक सिस्टम की गुणवत्ता के साथ समस्याएं हैं। आइए यह पता लगाने की कोशिश करें कि ऐसा क्यों हो रहा है और क्या यह किसी भी तरह से संभव है।

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

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


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

हम इससे आगे बढ़े:



इसके लिए:



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

मिश्रित दृष्टिकोण का उपयोग करके मंगल में नमूना परियोजना

परियोजना की मुख्य विशेषताएं:

• प्रारंभ से लॉन्च तक 5 अवधि (22 सप्ताह)
• पूर्ण परियोजना टीम - 40 लोग (व्यावसायिक उपयोगकर्ता और आईटी सलाहकार, डेवलपर)
• परियोजना टीम के भीतर 4 कार्यात्मक टीमें - वित्त, खरीद, रसद और बिक्री, गुणवत्ता नियंत्रण विभाग
• पहली कोशिश में 93% सफल स्क्रिप्ट के साथ व्यापार परीक्षण के 4 चक्र। 5 पूर्णकालिक कार्यशालाएँ

पूर्व-परियोजना चरण में, हमने अनुमान लगाया कि हम 30 सप्ताह में परियोजना करेंगे। वास्तव में, चंचल दृष्टिकोण का उपयोग करते हुए, हमने 22 सप्ताह में सब कुछ किया। लॉन्च के बाद 4 महीने के ऑपरेशन के लिए, हमें व्यवसाय से 1 परिवर्तन अनुरोध प्राप्त हुआ।

मुख्य सफलता कारक

आंतरिक आईटी टीमें। जितनी जल्दी हो सके, प्रमुख आईटी टीमों के साथ व्यवस्था करें जो कार्यान्वयन में शामिल होंगे। एक बाहरी ठेकेदार के साथ बातचीत में संलग्न करने के लिए प्रबंधन समर्थन का समर्थन करें।

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

कुछ अक्सर पूछे जाने वाले प्रश्न

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

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

प्रश्न 2: क्या होगा यदि व्यावसायिक उपयोगकर्ता प्रत्येक स्प्रिंट की समीक्षा और योजना के दौरान लगातार नई आवश्यकताओं को जोड़ते हैं?

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

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