📊 ❔ ⛹🏿 एजाइल कस्टम वेब डेवलपमेंट 🌓 🙎🏿 🌤️

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

ग्राहक की आंखों के माध्यम से चुस्त और झरना

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

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

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

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

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

परियोजना की शर्तों और लागत के लिए , जब एक लचीली विधि के अनुसार काम करते हैं, तो न तो ठेकेदार और न ही ग्राहक को पता होता है कि परियोजना कब समाप्त होगी और इसमें कितना पैसा लगेगा। हालांकि, कैस्केड मॉडल के साथ, यह अक्सर उसी तरह से निकलता है :)

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

एक आविष्कार के रूप में वेबसाइट

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

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

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

आपकी समस्याएं ग्राहक की समस्याएं हैं

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

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

- यह क्या है? मुझे इसकी बिल्कुल भी जरूरत नहीं है!
- तो हमने टीके पर सब कुछ किया, आपने इस पर हस्ताक्षर किए।
- क्या तुम मुझसे मजाक कर रहे हो? आपकी पक्षी भाषा के 100 पृष्ठ हैं, मैंने इसे मास्टर नहीं किया है, मुझे आपकी व्यावसायिकता की आशा है।
- ठीक है, फिर से, पैसे का भुगतान करें।
- यहां एक और है, मैंने इतने पैसे का भुगतान किया, इसे मुफ्त में फिर से करें।
- हम नहीं जीते।
"और हम तब तक भुगतान नहीं करेंगे जब तक हम इसे फिर से नहीं करेंगे।"

स्थिति गतिरोधपूर्ण है, प्रत्येक पक्ष खुद को सही मानता है; यहां तक कि अगर डेवलपर को झुकना पड़ता है (जैसा कि आमतौर पर होता है), ग्राहक भी खो देगा: समय, एक वफादार साथी। चंचलता नाटकीय रूप से ऐसी समस्याओं के जोखिम को कम करती है।

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

आलसी ग्राहक - चंचल शत्रु

"आलसी" शब्द से मेरा तात्पर्य न केवल इतना है और न ही इतना स्वाभाविक आलस्य। एक आदर्श ग्राहक वह है जो:

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

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

अन्य बातों के अलावा, आलसी ग्राहक बहुत शर्मीले होते हैं। अपने अनुभव से मैं आश्वस्त था कि:

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

क्या आप इससे सहमत हैं? और कल्पना करें कि आप ग्राहक से यह सब कह रहे हैं, और उसकी स्थिति से इस सूची को देखें। निष्कर्ष आप बना देंगे: बहुत ही अव्यवसायिक लोग इस कंपनी में काम करते हैं। ग्राहक बस आपकी कंपनी के साथ काम करने से डरता है और उस पर जाएगा जहां "ऐसी कोई बात नहीं है", हालांकि वहां सब कुछ समान है, केवल एजाइल इसे पेश नहीं करता है।

हमारा अनुभव

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

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

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

चंचल पतले धब्बे

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

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

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

एजाइल कस्टम वेब डेवलपमेंट