साइट बनाने के लिए दृष्टिकोणों की तुलना: डिजाइन, संक्षिप्त और फुर्तीली

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

बस मामले में, हम शर्तों पर सहमत होंगे:

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

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

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

मैं बहुत आभारी रहूंगा अगर कोई मुझसे बहस करेगा, अपने विचार साझा करेगा। इसके लिए, मैं वास्तव में लिख रहा हूं। यदि यह किसी को लगता है कि मैं डिजाइनिंग के लिए हूं - तो यह आपको प्रतीत नहीं होता है।

डिज़ाइन

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

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

आकर्षण आते हैं

1. आइए विचारों की जाँच करें। यहां बताया गया है, ग्राहक को साइट के बारे में एक विचार है। इसे कैसे व्यवहार में लाना है, इसे कैसे समझें: क्या डिज़ाइन होना चाहिए, क्या कार्यात्मक समाधान लागू करना चाहिए, आगंतुक को क्या बताना चाहिए, इसकी लागत कितनी होगी और समय लगेगा, क्या इसके लिए संसाधन हैं, क्या यह ग्राहक की संगठनात्मक संरचना के दृष्टिकोण से वास्तविक है? कोई रास्ता नहीं, अगर डिजाइन करने के लिए नहीं।
2. समाधान चुनने की क्षमता प्रदान करता है । हमने साइट को डिज़ाइन किया है, हम संभावित वास्तुशिल्प, कार्यात्मक और डिज़ाइन समाधान देखते हैं और यह चुन सकते हैं कि उपलब्ध संसाधनों के आधार पर कैसे और क्या करना है।
3. कार्यक्षमता बढ़ाता है। डिजाइनिंग साइट को किसी अन्य व्यक्तिपरक विचारों / इच्छाओं के बजाय मध्य एशिया और संदर्भ की जरूरतों के अनुरूप समस्याओं को हल करने के उद्देश्य से बनाती है।
4. एक ठेकेदार चुनने के लिए एक अच्छा उपकरण देता है। ठेकेदार को विभिन्न तरीकों से सिफारिशों, पोर्टफोलियो, व्यक्तिगत भावना, अंतर्ज्ञान के अनुसार चुना जा सकता है। लेकिन परियोजना, जिसमें आप देख सकते हैं और इसके कार्यान्वयन का मूल्यांकन कर सकते हैं, "मूल्य / गुणवत्ता" की कसौटी पर एक टेंडर रखने के लिए एक उत्कृष्ट उपकरण है।
5. यह लागत और समय का आकलन करने का अवसर प्रदान करता है। मुझे लगता है कि टिप्पणी करने की कोई आवश्यकता नहीं है। एक परियोजना है - सबसे सटीक मूल्यांकन है। अन्य तरीकों की तुलना में।
6. अंततः, यह संसाधनों और समय की बचत करता है। डिजाइनिंग से निर्णयों की सटीकता बढ़ जाती है, और इसलिए, त्रुटियों के जोखिम को कम करता है, जो हमेशा साइट के विकास और इससे जुड़ी हर चीज के लिए अतिरिक्त लागत का कारण बनता है।

विपक्ष

1. टीके से अधिक महंगा और लंबा है। आमतौर पर कम से कम 50 हजार रूबल, अगर ईमानदारी से किया जाए।
2. सीखने की जरूरत है । अच्छी तरह से डिजाइन करने के लिए, आपको साहित्य का एक गुच्छा फावड़ा करने की आवश्यकता है, दर्जनों परियोजनाओं पर शंकु का एक गुच्छा भरें और ऐसा करने की क्षमता रखें।
3. प्रत्येक डेवलपर यह नहीं समझता है कि किसी परियोजना पर कैसे काम किया जाए। पर्याप्त ज्ञान, अनुभव नहीं, संक्षिप्त में भी।

संक्षिप्त

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

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

प्रक्रिया अक्सर इस तरह दिखती है: उन्होंने ग्राहक के साथ बात की, आवश्यकताओं को आकर्षित किया, संरचना को आकर्षित किया, वर्णित किया कि अनुभागों में क्या होगा, सीएमएस चुना।

आकर्षण आते हैं

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

विपक्ष

1. बिना सोचे-समझे। बहुत कम जानकारी, विश्लेषण, समाधान का आधारहीन विकल्प। यह गलतियों, अतिरिक्त धन, समय बर्बाद करने या एक बुरी साइट को चलाने की आवश्यकता पर जोर देता है, क्योंकि "मालिक मांग कर रहे हैं", "यह समय", आदि।
2. यह संसाधनों और समय का सही आकलन करने की अनुमति नहीं देता है। क्योंकि पर्याप्त विवरण और समझ नहीं है (पैराग्राफ 1 देखें)।
3. पेशेवरों में पैरा 3 देखें।

चुस्त

चंचल एक लचीली प्रक्रिया नियंत्रण है जो एक विशिष्ट कार्य और समय सीमा के साथ छोटे खंडों को तोड़ता है, जिसके परिणाम से हमें कुछ काम करने को मिलता है।

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

आकर्षण आते हैं

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

विपक्ष

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

निष्कर्ष

तो, उपरोक्त तरीकों की प्रयोज्यता के बारे में मेरी व्यक्तिगत राय।

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

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

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

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

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

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