प्रोग्रामर अपनी गलतियों को याद करता है

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

मुझे तुरंत कहना होगा कि निष्कर्ष काफी हद तक विवादास्पद हैं, लेकिन व्यक्तिगत अनुभव से बार-बार पुष्टि की गई है। इसलिए, मुझे वैकल्पिक दृष्टिकोणों पर चर्चा करने में खुशी होगी।

जैसे ही मैं विचार का वर्णन करता हूं, यह मुझसे चोरी हो जाएगा, या प्रतियोगियों इसे लागू करेंगे

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

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

पहले, सब कुछ पेटेंट होना चाहिए, और उसके बाद ही ..!

मैं आपको एक बार फिर याद दिलाता हूं कि मैं जो कुछ भी लिखता हूं वह अधिकांश आईटी परियोजनाओं पर लागू होता है। हमेशा अपवाद हैं, लेकिन वे बेहद दुर्लभ हैं।

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

जैसे ही मैं सेवा शुरू करता हूं, इच्छुक ग्राहक तुरंत दिखाई देंगे

सभी परियोजना प्रतिभागियों के लिए, सेवा शुरू में दिलचस्प है, वे उनके लिए रहते हैं, वे सांस लेते हैं। जब आप किसी उत्पाद को पोस्ट करते हैं, चाहे वह सेवा हो या कोई गेम, आप उम्मीद करते हैं कि परियोजना में तुरंत नियमित उपयोगकर्ता होंगे। कई अलग-अलग लोग जिन्होंने अपने उत्पादों को एक से अधिक बार लॉन्च करने की कोशिश की, उन्होंने लिखा कि प्राथमिक प्रचार पर काम अक्सर उत्पाद विकास पर काम की जटिलता से अधिक होता है। इसीलिए, उत्पाद को बाज़ार में लाना बहुत ज़रूरी है ताकि पुष्टि करने के लिए या एक नियम के रूप में, प्रारंभिक सिद्धांतों का खंडन किया जा सके और उन्हें ठीक करने के तरीकों की तलाश की जा सके। यदि बाजार पर कोई प्रसिद्ध एनालॉग नहीं हैं, तो आप उपभोक्ताओं से अपने उत्पाद के बारे में गलतफहमी की दोहरी दीवार के पार आ जाएंगे। दिलचस्प है, बड़ी कंपनियों को एक ही समस्या का सामना करना पड़ता है। यदि कंपनी ए के पास सेवा बी में लाखों उपयोगकर्ता हैं और यह सेवा सी लॉन्च करता है, तो भले ही सेवा उपयोगी, प्रासंगिक और मांग में हो, यह सुनिश्चित करने के लिए महत्वपूर्ण प्रयास करना आवश्यक होगा कि इसे उचित लोकप्रियता मिली है, लेकिन ऐसा नहीं हो सकता है। पूर्ण शून्य से शुरू होने पर, कार्य कई बार जटिल होता है। सफलता की बदलती डिग्री के साथ समान कहानियों के उदाहरण: Google Wave, Google Plus, Microsoft Zune, Windows Phone, BB10, Qiwi अंडे, Qiwi: मूवी टिकट, Yandex: धन उगाहने वाले।

पहले कार्यान्वयन से पहले भी, मैं अपने ग्राहकों, उनकी समस्याओं और इच्छाओं को जानता हूं

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

हम तुरंत एक अच्छी सेवा करेंगे, पूरी तरह से काम करने के बाद

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

बड़ी कंपनियों का अनुभव

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

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

इसे पढ़ने वाले सभी को धन्यवाद। अगले लेख में, मैं अंत में बात करूंगा कि निवेश के आवंटन पर निर्णय के बाद क्या हुआ। मैंने यहां पृष्ठभूमि का वर्णन किया है ।

मुझे आपके सवालों के जवाब देने में खुशी होगी, साथ ही ऊपर व्यक्त व्यक्तिगत अनुभव पर भी एक राय मिलेगी।