हमारे स्टार्टअप के पहले वर्ष में 9 बड़ी गलतियाँ

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

1. शुक्रवार को अपडेट लॉन्च।

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

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

खुद के लिए, हमने एक सख्त नियम विकसित किया है: यदि हमने गुरुवार दोपहर से पहले इसे भरने का प्रबंधन नहीं किया, तो हमने अगले सप्ताह तक लॉन्च स्थगित कर दिया।

2. समय में डोमेन का नवीनीकरण नहीं किया गया था।

हमारा सिस्टम कई अलग-अलग डोमेन का उपयोग करता है। उनमें से एक ग्रंथों की विशिष्टता की जांच करने के लिए एक प्रणाली है (लेखक द्वारा लिखे गए सभी ग्रंथों को ग्राहक को भेजे जाने से पहले विशिष्टता के लिए जाँच की जाती है)।

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

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

3. परीक्षण नई सुविधाएँ एक कार्य प्रणाली पर रहते हैं।

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

एक सरल और बहुत ही महत्वपूर्ण नियम को मेरे सारे जीवन में अंकित किया गया है: डालने से पहले परीक्षण करने और फिर से परीक्षण करने के लिए! और ऐसे समय में महत्वपूर्ण तकनीकी परिवर्तन करें जब टीम के सभी सदस्य काम कर रहे हों।

4. बड़े पैमाने पर संचालन के साथ सावधान रहें।

सेवा की शुरुआत में, लेखकों को रॉयल्टी का भुगतान करने के लिए ऑपरेशन के दौरान, दो बार भुगतान किया गया था। नतीजतन, मुझे लेखकों को निजी संदेशों में पैसे वापस करने के लिए कहना पड़ा। लगता है - बहुत अच्छा नहीं है। सभी लेकिन एक कॉपीराइटर ने पैसे वापस कर दिए।

नतीजतन, नियम का जन्म हुआ: हमेशा "पे" बटन पर क्लिक करने से पहले डेटा का एक चयनात्मक सामंजस्य स्थापित करें।

5. मास स्पैम।

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

निष्कर्ष: किसी भी मेलिंग से पहले, आपको पहले अपने कई मेलबॉक्सेस सहित 10 ईमेल पर एक परीक्षण करना होगा।

6. एक ही समय में कई प्रोजेक्ट काम करते हैं।

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

अब मैं एक सामान्य बात कहूंगा: एक साथ कई गंभीर परियोजनाओं को विकसित करना असंभव है। बलों के फैलाव ने अनिवार्य रूप से सभी परियोजनाओं की विकास दर में कमी का कारण बना। अब हमारे पास कई अनावश्यक डोमेन और दो बड़े प्रोजेक्ट हैं जिन्हें हम एक ही समय में विकसित करने का प्रयास कर रहे हैं।

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

7. जटिल कार्यों और विकल्पों का विकास जिनकी वास्तव में आवश्यकता नहीं है।

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

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

8. रिहाई में देरी।

यदि हम अनावश्यक सुविधाओं को पूर्ण किए बिना एक्सचेंज के मुफ्त संस्करण का बीटा संस्करण तुरंत लॉन्च करते हैं तो हम कई महीनों को बचा सकते हैं।

निष्कर्ष: कोडिंग की शुरुआत के बाद जनता को (लोगों का एक सीमित घेरा) जल्द से जल्द एक नया विकास दिखाएं। इसे अभी भी कच्चा होने दें, लेकिन हम शुरुआत में ही विकास के सही वेक्टर के बारे में जानेंगे।

9. रूपांतरण लागतों को छोड़कर विज्ञापन खरीदना।

कुछ विज्ञापन काफी प्रभावी थे, लेकिन इसमें निवेश किया गया अधिकांश पैसा बर्बाद हो गया। इस क्षेत्र की गलतियाँ इस प्रकार हैं:

- प्रासंगिक विज्ञापन पर पैसा खो गया था, जिसने रूपांतरण नहीं दिया (पहली बार में हमने केवल रूपांतरण लेखा प्रणाली स्थापित करने की जहमत नहीं उठाई)।
- फीडबर्नर ग्राहकों की संख्या (यह रेटिंग धोखा हो सकता है) पर ध्यान देने के साथ ब्लॉग पोस्ट खरीदना।
- उन ब्लॉगर्स से पोस्ट खरीदना, जिन्होंने हमारी सेवा का उपयोग नहीं किया (ऐसे पोस्ट दिलचस्प और विज्ञापन नहीं थे, वास्तविक उपयोगकर्ताओं के पोस्ट का पूरी तरह से अलग प्रभाव पड़ता है)
- Searchengines.ru फोरम पर संलग्न विषय ने बहुत कम ट्रैफ़िक दिया और भुगतान भी नहीं किया।

नतीजतन, कुछ महीने पहले, कुछ समय के लिए, हमने खरीदे गए विज्ञापन को छोड़ने का फैसला किया और इससे विकास प्रभावित नहीं हुआ, जो मुख्य रूप से वायरल कारकों के कारण होता है।

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

अद्यतन: और आपके स्टार्टअप पर काम करते समय क्या गलतियाँ हुईं? मैं आपको टिप्पणियों में अपना अनुभव साझा करने के लिए आमंत्रित करता हूं!