ऑनलाइन स्टोर विकसित करते समय लक्ष्य निर्धारित करना, या अनावश्यक परियोजना का आदेश कैसे नहीं

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

संदर्भ की शर्तें किसको बनानी चाहिए?

हां, तकनीकी कार्य बहुत सारे मुद्दों को हल करता है, लेकिन अधिकांश ग्राहक यह नहीं जानते हैं कि यह क्या है और क्या नहीं जानना चाहते हैं। और अगर वे चाहते हैं, तो वे बहुत कम ही इसे सही ढंग से कम या ज्यादा कर सकते हैं। तो यह कौन करे?

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

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

तो, फिर भी, आपको ठेकेदार के साथ मिलकर अपने ऑनलाइन स्टोर के विकास के लिए संदर्भ की शर्तों को खींचने की जरूरत है, अधिमानतः लगभग एक ही टेबल पर।

स्टोर की संरचना पर किसे सोचना चाहिए

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

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

एक में सभी तीन बिंदु: यदि आप ठेकेदार को ऑनलाइन स्टोर की संरचना के विकास को छोड़ देते हैं, तो ग्राहक को पूरी तरह से अनुचित कार्यान्वयन विकल्प मिल सकता है, जो कि फिर से मुश्किल / लंबा / महंगा है। और कलाकार सही है।

उत्पाद भुगतान प्रणाली

टाइम्स द्वारा जाने, अधिक से अधिक ग्राहक स्टोर में Yandex.Money, WebMoney, VISA / MasterCard, आदि के माध्यम से भुगतान की संभावना देखना चाहते हैं ...

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

• डेवलपर (निष्पादक) के लिए कोई फर्क नहीं पड़ता कि आपसे ट्रांसफर के लिए कितना प्रतिशत वसूला जाएगा;
• एक अज्ञानी डेवलपर आगे पहुंच सकता है, भुगतान ट्रैक कर सकता है, रसीदें ट्रैक कर सकता है और, सबसे खराब स्थिति में, अपना पैसा प्राप्त कर सकता है;
• यहां तक ​​कि भुगतान प्रणाली के साथ ठेकेदार, ठेकेदार खुद के लिए व्यवस्था कर सकता है, जैसे, नौकरशाही से आपको बचा रहा है;
• एक प्रणाली का चयन किया जा सकता है जो एक महीने में "झुक जाएगा";

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

उत्पाद बिक्री चक्र - सभी उत्पाद समान नहीं बेचे जाते हैं

मान लीजिए कि आपका ऑनलाइन स्टोर तैयार है और यह काम करता है। और ग्राहक खरीदारी कैसे करेगा?

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

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

मुख्य पृष्ठ ala "पोर्टल" पर बहुत सी जानकारी

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

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

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